From xen-devel-bounces@lists.xen.org Fri Feb 01 00:06:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 00: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 1U148Q-0002Ay-Vf; Fri, 01 Feb 2013 00:05:38 +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 1U148P-0002At-5s
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 00:05:37 +0000
Received: from [85.158.139.211:20379] by server-12.bemta-5.messagelabs.com id
	39/9B-20195-0D60B015; Fri, 01 Feb 2013 00:05:36 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1359677134!20164801!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk3ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22874 invoked from network); 1 Feb 2013 00:05:35 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 00:05:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1105WtP008093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 00:05:33 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
	r1105Wcm013656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 00:05:32 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
	r1105VX6025032; Thu, 31 Jan 2013 18:05:31 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 16:05:31 -0800
Date: Thu, 31 Jan 2013 16:05:30 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130131160530.6ce89e64@mantra.us.oracle.com>
In-Reply-To: <20130124164434.GK20551@ocelot.phlegethon.org>
References: <20130111180356.2eedfb82@mantra.us.oracle.com>
	<20130124164434.GK20551@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 11/16]: PVH xen: some misc changes like
 mtrr, intr, msi.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013 16:44:34 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:03 -0800 on 11 Jan (1357927436), Mukesh Rathor wrote:
> > diff -r 0a38c610f26b -r 33fc5356ad7c xen/arch/x86/time.c
> > --- a/xen/arch/x86/time.c	Fri Jan 11 16:34:17 2013 -0800
> > +++ b/xen/arch/x86/time.c	Fri Jan 11 16:35:48 2013 -0800
> > @@ -1923,7 +1923,7 @@ void tsc_set_info(struct domain *d,
> >          break;
> >      }
> >      d->arch.incarnation = incarnation + 1;
> > -    if ( is_hvm_domain(d) )
> > +    if ( is_hvm_or_pvh_domain(d) )
> >          hvm_set_rdtsc_exiting(d, d->arch.vtsc);
> >  }
> 
> The pvh vmexit handler in the last patch crashes the guest if it gets
> an RDTSC interception vmexit, so presumably either something should be
> added there or we need to make sure that d->arch.vtsc is never set on
> a PVH domain. 

Fixed. For now, making sure vtsc is not set for PVH. But, I added an
action item for Phase II to investigate and add support for it. At
first glance, staring at tsc code for couple hours, I'm still clueless.


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 Feb 01 00:06:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 00: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 1U148Q-0002Ay-Vf; Fri, 01 Feb 2013 00:05:38 +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 1U148P-0002At-5s
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 00:05:37 +0000
Received: from [85.158.139.211:20379] by server-12.bemta-5.messagelabs.com id
	39/9B-20195-0D60B015; Fri, 01 Feb 2013 00:05:36 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1359677134!20164801!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk3ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22874 invoked from network); 1 Feb 2013 00:05:35 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 00:05:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1105WtP008093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 00:05:33 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
	r1105Wcm013656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 00:05:32 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
	r1105VX6025032; Thu, 31 Jan 2013 18:05:31 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 16:05:31 -0800
Date: Thu, 31 Jan 2013 16:05:30 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130131160530.6ce89e64@mantra.us.oracle.com>
In-Reply-To: <20130124164434.GK20551@ocelot.phlegethon.org>
References: <20130111180356.2eedfb82@mantra.us.oracle.com>
	<20130124164434.GK20551@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 11/16]: PVH xen: some misc changes like
 mtrr, intr, msi.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013 16:44:34 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:03 -0800 on 11 Jan (1357927436), Mukesh Rathor wrote:
> > diff -r 0a38c610f26b -r 33fc5356ad7c xen/arch/x86/time.c
> > --- a/xen/arch/x86/time.c	Fri Jan 11 16:34:17 2013 -0800
> > +++ b/xen/arch/x86/time.c	Fri Jan 11 16:35:48 2013 -0800
> > @@ -1923,7 +1923,7 @@ void tsc_set_info(struct domain *d,
> >          break;
> >      }
> >      d->arch.incarnation = incarnation + 1;
> > -    if ( is_hvm_domain(d) )
> > +    if ( is_hvm_or_pvh_domain(d) )
> >          hvm_set_rdtsc_exiting(d, d->arch.vtsc);
> >  }
> 
> The pvh vmexit handler in the last patch crashes the guest if it gets
> an RDTSC interception vmexit, so presumably either something should be
> added there or we need to make sure that d->arch.vtsc is never set on
> a PVH domain. 

Fixed. For now, making sure vtsc is not set for PVH. But, I added an
action item for Phase II to investigate and add support for it. At
first glance, staring at tsc code for couple hours, I'm still clueless.


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 Feb 01 02:24:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:24: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 1U16I0-0002OO-PJ; Fri, 01 Feb 2013 02:23:40 +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 1U16Hz-00026p-KQ
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 02:23:39 +0000
Received: from [85.158.137.99:2289] by server-15.bemta-3.messagelabs.com id
	8E/CC-25405-A272B015; Fri, 01 Feb 2013 02:23:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1359685416!19460686!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk3ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23796 invoked from network); 1 Feb 2013 02:23:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 02:23:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r112NWcj005087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:23: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
	r112NVSW012033
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:23:32 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
	r112NV2M023858; Thu, 31 Jan 2013 20:23:31 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:23:31 -0800
Date: Thu, 31 Jan 2013 18:23:29 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20130131182329.2cb3a225@mantra.us.oracle.com>
In-Reply-To: <5107B6FC02000078000BA589@nat28.tlf.novell.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.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: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 29 Jan 2013 10:48:12 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On xen side I added the ifdef:
> > 
> > #if __XEN_INTERFACE_VERSION__ < 0x00040300
> >     unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames,
> > # ents) */
> > #else
> >     union {
> >         struct {
> >             /* GDT (machine frames, # ents) */
> >             unsigned long gdt_frames[16], gdt_ents;
> >         } pv;
> >         struct {
> >             /* PVH: GDTR addr and size */
> >             unsigned long gdtaddr, gdtsz;
> >         } pvh;
> >     } u;
> > #endif
> > 
> > but it doesn't matter on linux side, so up to you.
> 
> But I'd still prefer for this to go away again - you could simply use
> gdt_frames[0] for gdtaddr and gdt_ents for the (normalized)
> gdtsz.

That was my patch version 1 during linux patch review. Then the reviewer
suggested to make it a union.

> And if you nevertheless go the union route, call it "gdt" instead
> of "u" and drop the gdt/gdt_ prefixes from the member names
> (yes, I know, grepping and cscoping for such member is more
> difficult, but I continue to see more advantage in avoiding the
> redundancy).

That was my patch version 2, where I called it gdt and another reviewer
suggested to change to u. So I changed it to u.

It's gone thru enough iterations that I'd like to leave as is. Thank
you in advance for your compromise in helping us mortals grep/cscope 
to learn code.

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 Feb 01 02:24:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:24: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 1U16I0-0002OO-PJ; Fri, 01 Feb 2013 02:23:40 +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 1U16Hz-00026p-KQ
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 02:23:39 +0000
Received: from [85.158.137.99:2289] by server-15.bemta-3.messagelabs.com id
	8E/CC-25405-A272B015; Fri, 01 Feb 2013 02:23:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1359685416!19460686!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk3ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23796 invoked from network); 1 Feb 2013 02:23:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 02:23:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r112NWcj005087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:23: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
	r112NVSW012033
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:23:32 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
	r112NV2M023858; Thu, 31 Jan 2013 20:23:31 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:23:31 -0800
Date: Thu, 31 Jan 2013 18:23:29 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20130131182329.2cb3a225@mantra.us.oracle.com>
In-Reply-To: <5107B6FC02000078000BA589@nat28.tlf.novell.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.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: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 29 Jan 2013 10:48:12 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On xen side I added the ifdef:
> > 
> > #if __XEN_INTERFACE_VERSION__ < 0x00040300
> >     unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames,
> > # ents) */
> > #else
> >     union {
> >         struct {
> >             /* GDT (machine frames, # ents) */
> >             unsigned long gdt_frames[16], gdt_ents;
> >         } pv;
> >         struct {
> >             /* PVH: GDTR addr and size */
> >             unsigned long gdtaddr, gdtsz;
> >         } pvh;
> >     } u;
> > #endif
> > 
> > but it doesn't matter on linux side, so up to you.
> 
> But I'd still prefer for this to go away again - you could simply use
> gdt_frames[0] for gdtaddr and gdt_ents for the (normalized)
> gdtsz.

That was my patch version 1 during linux patch review. Then the reviewer
suggested to make it a union.

> And if you nevertheless go the union route, call it "gdt" instead
> of "u" and drop the gdt/gdt_ prefixes from the member names
> (yes, I know, grepping and cscoping for such member is more
> difficult, but I continue to see more advantage in avoiding the
> redundancy).

That was my patch version 2, where I called it gdt and another reviewer
suggested to change to u. So I changed it to u.

It's gone thru enough iterations that I'd like to leave as is. Thank
you in advance for your compromise in helping us mortals grep/cscope 
to learn code.

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 Feb 01 02:30:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:30: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 1U16Oa-0005b3-N3; Fri, 01 Feb 2013 02:30:28 +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 1U16OZ-0005F3-5K
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:30:27 +0000
Received: from [85.158.139.211:47510] by server-5.bemta-5.messagelabs.com id
	54/D3-11945-2C82B015; Fri, 01 Feb 2013 02:30:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1359685823!20552496!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDcxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16541 invoked from network); 1 Feb 2013 02:30:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 02:30:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r112UIbf009111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:30:18 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
	r112UHKU005573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:30:17 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
	r112UHcW003166; Thu, 31 Jan 2013 20:30:17 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:30:16 -0800
Date: Thu, 31 Jan 2013 18:30:15 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.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>, Ian Campbell
	<Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20130131183015.13bc2bff@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: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
allocate pfns for grant table pages instead of kmalloc. This also
simplifies add to physmap on the xen side a bit.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

---
 drivers/xen/grant-table.c |   37 ++++++++++++++++++++++++++-----------
 1 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..d731f39 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1138,27 +1139,41 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+static int xlated_setup_gnttab_pages(int numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,
+			numpages, rc);
+		return -ENOMEM;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	return rc;
+}
+
 int gnttab_resume(void)
 {
-	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
+	unsigned int rc, max_nr_gframes;
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages(max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
-- 
1.7.2.3


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 02:30:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:30: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 1U16Oa-0005b3-N3; Fri, 01 Feb 2013 02:30:28 +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 1U16OZ-0005F3-5K
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:30:27 +0000
Received: from [85.158.139.211:47510] by server-5.bemta-5.messagelabs.com id
	54/D3-11945-2C82B015; Fri, 01 Feb 2013 02:30:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1359685823!20552496!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDcxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16541 invoked from network); 1 Feb 2013 02:30:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 02:30:25 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r112UIbf009111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:30:18 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
	r112UHKU005573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:30:17 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
	r112UHcW003166; Thu, 31 Jan 2013 20:30:17 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:30:16 -0800
Date: Thu, 31 Jan 2013 18:30:15 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.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>, Ian Campbell
	<Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20130131183015.13bc2bff@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: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
allocate pfns for grant table pages instead of kmalloc. This also
simplifies add to physmap on the xen side a bit.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

---
 drivers/xen/grant-table.c |   37 ++++++++++++++++++++++++++-----------
 1 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..d731f39 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1138,27 +1139,41 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+static int xlated_setup_gnttab_pages(int numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,
+			numpages, rc);
+		return -ENOMEM;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	return rc;
+}
+
 int gnttab_resume(void)
 {
-	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
+	unsigned int rc, max_nr_gframes;
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages(max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
-- 
1.7.2.3


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 02:38:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:38: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 1U16WO-0006Lt-UY; Fri, 01 Feb 2013 02:38:32 +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 1U16WN-0006Lo-Bm
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:38:31 +0000
Received: from [85.158.143.99:4833] by server-3.bemta-4.messagelabs.com id
	43/C1-08920-6AA2B015; Fri, 01 Feb 2013 02:38:30 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1359686308!23975881!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk3ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14805 invoked from network); 1 Feb 2013 02:38:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 02:38:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r112cR52017558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:38:28 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
	r112cQxu000572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:38:27 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
	r112cPQG005711; Thu, 31 Jan 2013 20:38:26 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:38:25 -0800
Date: Thu, 31 Jan 2013 18:38:24 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130131183824.3af5e6a0@mantra.us.oracle.com>
In-Reply-To: <20130124171815.GM20551@ocelot.phlegethon.org>
References: <20130111180944.4ff10c8f@mantra.us.oracle.com>
	<20130124171815.GM20551@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 13/16]: PVH xen: introduce
 p2m_map_foreign
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013 17:18:15 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:09 -0800 on 11 Jan (1357927784), Mukesh Rathor wrote:
> > @@ -584,6 +584,11 @@ guest_physmap_add_entry(struct domain *d
> >          {
> >              ASSERT(mfn_valid(omfn));
> >              set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
> > +
> > +            /* Because PVH domU uses kmalloc for grant pfn, we
> > need to save
> > +             * and restore the old mfn */
> > +             if (is_pvh_domain(d) && p2m_is_grant(t))
> > +                 free_domheap_page(mfn_to_page(omfn));
> 
> I think you'll need to explain this in more detail.  The comment
> assumes that the guest is running linux, which is worrying.  And in
> any case you can't just free_domheap_page() the guest's memory!  What
> if another domain has a reference to it?

Ok, I fixed linux side so instead of kmalloc it uses ballooning to
get pfn space for the grant table. That means there should not be 
an omfn here. If there is, I think I should just fail the operation, 
ie, guest_physmap_add_entry(), right?

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 Feb 01 02:38:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:38: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 1U16WO-0006Lt-UY; Fri, 01 Feb 2013 02:38:32 +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 1U16WN-0006Lo-Bm
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:38:31 +0000
Received: from [85.158.143.99:4833] by server-3.bemta-4.messagelabs.com id
	43/C1-08920-6AA2B015; Fri, 01 Feb 2013 02:38:30 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1359686308!23975881!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk3ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14805 invoked from network); 1 Feb 2013 02:38:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 02:38:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r112cR52017558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:38:28 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
	r112cQxu000572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:38:27 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
	r112cPQG005711; Thu, 31 Jan 2013 20:38:26 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:38:25 -0800
Date: Thu, 31 Jan 2013 18:38:24 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130131183824.3af5e6a0@mantra.us.oracle.com>
In-Reply-To: <20130124171815.GM20551@ocelot.phlegethon.org>
References: <20130111180944.4ff10c8f@mantra.us.oracle.com>
	<20130124171815.GM20551@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 13/16]: PVH xen: introduce
 p2m_map_foreign
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013 17:18:15 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:09 -0800 on 11 Jan (1357927784), Mukesh Rathor wrote:
> > @@ -584,6 +584,11 @@ guest_physmap_add_entry(struct domain *d
> >          {
> >              ASSERT(mfn_valid(omfn));
> >              set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
> > +
> > +            /* Because PVH domU uses kmalloc for grant pfn, we
> > need to save
> > +             * and restore the old mfn */
> > +             if (is_pvh_domain(d) && p2m_is_grant(t))
> > +                 free_domheap_page(mfn_to_page(omfn));
> 
> I think you'll need to explain this in more detail.  The comment
> assumes that the guest is running linux, which is worrying.  And in
> any case you can't just free_domheap_page() the guest's memory!  What
> if another domain has a reference to it?

Ok, I fixed linux side so instead of kmalloc it uses ballooning to
get pfn space for the grant table. That means there should not be 
an omfn here. If there is, I think I should just fail the operation, 
ie, guest_physmap_add_entry(), right?

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 Feb 01 02:41:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:41: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 1U16ZH-0006SO-Id; Fri, 01 Feb 2013 02:41: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 1U16ZG-0006SI-Ne
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:41:31 +0000
Received: from [85.158.137.99:62730] by server-14.bemta-3.messagelabs.com id
	2A/54-23533-55B2B015; Fri, 01 Feb 2013 02:41:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1359686484!16290108!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMDQw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18119 invoked from network); 1 Feb 2013 02:41:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 02:41:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1047109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 02:41: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.297.1; Fri, 1 Feb 2013 02:41:24 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U16ZA-0000Uc-1r;
	Fri, 01 Feb 2013 02:41:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U16Z9-0003ae-GO;
	Fri, 01 Feb 2013 02:41:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15401-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Feb 2013 02:41:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15401: 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 15401 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             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-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 02:41:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:41: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 1U16ZH-0006SO-Id; Fri, 01 Feb 2013 02:41: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 1U16ZG-0006SI-Ne
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:41:31 +0000
Received: from [85.158.137.99:62730] by server-14.bemta-3.messagelabs.com id
	2A/54-23533-55B2B015; Fri, 01 Feb 2013 02:41:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1359686484!16290108!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMDQw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18119 invoked from network); 1 Feb 2013 02:41:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 02:41:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1047109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 02:41: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.297.1; Fri, 1 Feb 2013 02:41:24 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U16ZA-0000Uc-1r;
	Fri, 01 Feb 2013 02:41:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U16Z9-0003ae-GO;
	Fri, 01 Feb 2013 02:41:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15401-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Feb 2013 02:41:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15401: 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 15401 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             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-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 02:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:45: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 1U16cc-0006bc-85; Fri, 01 Feb 2013 02:44:58 +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 1U16ca-0006bS-Lg
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:44:56 +0000
Received: from [85.158.138.51:26471] by server-10.bemta-3.messagelabs.com id
	C2/4A-10609-72C2B015; Fri, 01 Feb 2013 02:44:55 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1359686693!21631027!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDcxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7551 invoked from network); 1 Feb 2013 02:44:55 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 02:44:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r112im9j019735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:44: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
	r112imcE022135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:44:48 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
	r112ilFx008720; Thu, 31 Jan 2013 20:44:47 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:44:47 -0800
Date: Thu, 31 Jan 2013 18:44:46 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130131184446.654a2289@mantra.us.oracle.com>
In-Reply-To: <20130131183015.13bc2bff@mantra.us.oracle.com>
References: <20130131183015.13bc2bff@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: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
 table 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

On Thu, 31 Jan 2013 18:30:15 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
> allocate pfns for grant table pages instead of kmalloc. This also
> simplifies add to physmap on the xen side a bit.

Looking at it again, I realized rc should be signed in gnttab_resume().
Below again. Thanks.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..7a630bb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1138,27 +1139,42 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+static int xlated_setup_gnttab_pages(int numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,
+			numpages, rc);
+		return -ENOMEM;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	return rc;
+}
+
 int gnttab_resume(void)
 {
+	int rc;
 	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages(max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);




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

From xen-devel-bounces@lists.xen.org Fri Feb 01 02:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 02:45: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 1U16cc-0006bc-85; Fri, 01 Feb 2013 02:44:58 +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 1U16ca-0006bS-Lg
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 02:44:56 +0000
Received: from [85.158.138.51:26471] by server-10.bemta-3.messagelabs.com id
	C2/4A-10609-72C2B015; Fri, 01 Feb 2013 02:44:55 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1359686693!21631027!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDcxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7551 invoked from network); 1 Feb 2013 02:44:55 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 02:44:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r112im9j019735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 02:44: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
	r112imcE022135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 02:44:48 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
	r112ilFx008720; Thu, 31 Jan 2013 20:44:47 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 31 Jan 2013 18:44:47 -0800
Date: Thu, 31 Jan 2013 18:44:46 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130131184446.654a2289@mantra.us.oracle.com>
In-Reply-To: <20130131183015.13bc2bff@mantra.us.oracle.com>
References: <20130131183015.13bc2bff@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: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
 table 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

On Thu, 31 Jan 2013 18:30:15 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
> allocate pfns for grant table pages instead of kmalloc. This also
> simplifies add to physmap on the xen side a bit.

Looking at it again, I realized rc should be signed in gnttab_resume().
Below again. Thanks.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..7a630bb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1138,27 +1139,42 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+static int xlated_setup_gnttab_pages(int numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,
+			numpages, rc);
+		return -ENOMEM;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	return rc;
+}
+
 int gnttab_resume(void)
 {
+	int rc;
 	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages(max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);




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

From xen-devel-bounces@lists.xen.org Fri Feb 01 06:54:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 06:54: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 1U1AVn-0007tx-V4; Fri, 01 Feb 2013 06:54:11 +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 1U1AVl-0007ts-Ex
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 06:54:09 +0000
Received: from [85.158.143.35:38475] by server-3.bemta-4.messagelabs.com id
	98/37-08920-0966B015; Fri, 01 Feb 2013 06:54:08 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359701642!5187797!1
X-Originating-IP: [209.85.216.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4381 invoked from network); 1 Feb 2013 06:54:04 -0000
Received: from mail-qc0-f181.google.com (HELO mail-qc0-f181.google.com)
	(209.85.216.181)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 06:54:04 -0000
Received: by mail-qc0-f181.google.com with SMTP id x40so1645203qcp.12
	for <xen-devel@lists.xen.org>; Thu, 31 Jan 2013 22:54:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=BDpidav56cZNPJVKQN/fGUelKeshBdKSey++ZEZUHd0=;
	b=Oxy+GVvyR/LZtdNi4mjS2MITMTXwN+urIvmKy66K/phmEqPLpB32J81dlltXgO/05k
	UGlsn0ZtQnSfWZTOVjg04/BQU07lMlgB2XUH2q06d0L6+kaD0Ehivjk7EnI7yYfBAft1
	BsBDFuQtgV6ftGcgb9iZ6K7CzxEt9PGwoIAkQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=BDpidav56cZNPJVKQN/fGUelKeshBdKSey++ZEZUHd0=;
	b=k21bSOnj86j4o1dYbGJFT1dKJRh8jk1+teq4cWgiIb9+stKMBR8dQCprGlsd3Gk5oQ
	tGOpTKBTv5LoEw77MAFkMuUIKIWsY2VhqRpT824UbepbmfVSz9wYshl1untcvAu5CH5A
	310y5yrGCflT3biwowtBGtUHe3bdN0U28cSByNVkR9Rz3nN3/cZPnfWevdJof/aop7ba
	fLyP06CBXVWvdrYaa50Jit9q7wdsHERDTp7pOuKTzuoOu0MU5Ql/UsKVFAXz4N0Wv65U
	SLfLa/U+bSVKImWRPNiT1PVxlp9iBK9IglTmNp3v+7rqdQvsjnr7U/0jAM5Imi8Iytks
	/O3A==
X-Received: by 10.224.180.212 with SMTP id bv20mr11608711qab.6.1359701642305; 
	Thu, 31 Jan 2013 22:54:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 31 Jan 2013 22:53:46 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1359655545.23229.101.camel@zion.uk.xensource.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
	<1359655545.23229.101.camel@zion.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 1 Feb 2013 10:53:46 +0400
X-Google-Sender-Auth: CRde26e4sBFyBIY7J29kfBCuRXg
Message-ID: <CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Gm-Message-State: ALoCoQmKhHpJc2Kg1sd+G9Kr224CK+lGK/9lW8Y/9gualqBIes6tyyFdpBRg1Et1fXKn1vOUt/H8
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback disk I/O limit 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

Sorry,

diff -NruabBEp xen_blkback_limit.orig/blkback.c xen_blkback_limit.new//blkback.c
--- xen_blkback_limit.orig/blkback.c 2012-12-04 13:03:58.000000000 +0400
+++ xen_blkback_limit.new//blkback.c 2013-01-28 08:11:30.000000000 +0400
@@ -211,10 +211,18 @@ static void print_stats(blkif_t *blkif)
  blkif->st_pk_req = 0;
 }

+static void refill_iops(blkif_t *blkif)
+{
+ blkif->reqtime = jiffies + msecs_to_jiffies(1000);
+ blkif->reqcount = 0;
+}
+
 int blkif_schedule(void *arg)
 {
  blkif_t *blkif = arg;
  struct vbd *vbd = &blkif->vbd;
+ int     ret = 0;
+ struct timeval cur_time;

  blkif_get(blkif);

@@ -237,10 +245,22 @@ int blkif_schedule(void *arg)
  blkif->waiting_reqs = 0;
  smp_mb(); /* clear flag *before* checking for work */

- if (do_block_io_op(blkif))
+ ret = do_block_io_op(blkif);
+ if (ret)
  blkif->waiting_reqs = 1;
  unplug_queue(blkif);

+ if (blkif->reqrate) {
+ if (2 == ret && (blkif->reqtime > jiffies)) {
+ jiffies_to_timeval(jiffies, &cur_time);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(blkif->reqtime - jiffies);
+ }
+ if (time_after(jiffies, blkif->reqtime))
+ refill_iops(blkif);
+ }
+
  if (log_stats && time_after(jiffies, blkif->st_print))
  print_stats(blkif);
  }
@@ -394,10 +414,19 @@ static int _do_block_io_op(blkif_t *blki
  rp = blk_rings->common.sring->req_prod;
  rmb(); /* Ensure we see queued requests up to 'rp'. */

+ if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
+ return (rc != rp) ? 2 : 0;
+ }
+
  while (rc != rp) {
  if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
  break;

+ if (blkif->reqrate) {
+ if (blkif->reqcount >= blkif->reqrate)
+ return 2;
+ }
+
  if (kthread_should_stop())
  return 1;

@@ -434,8 +463,8 @@ static int _do_block_io_op(blkif_t *blki

  /* Apply all sanity checks to /private copy/ of request. */
  barrier();
-
  dispatch_rw_block_io(blkif, &req, pending_req);
+ blkif->reqcount++;
  break;
  case BLKIF_OP_DISCARD:
  blk_rings->common.req_cons = rc;
@@ -452,7 +481,7 @@ static int _do_block_io_op(blkif_t *blki
  break;
  default:
  /* A good sign something is wrong: sleep for a while to
- * avoid excessive CPU consumption by a bad guest. */
+ * avoid excessive CPU consumption by a bad guest.*/
  msleep(1);
  blk_rings->common.req_cons = rc;
  barrier();
@@ -501,6 +530,7 @@ static void dispatch_rw_block_io(blkif_t
  uint32_t flags;
  int ret, i;
  int operation;
+ struct timeval cur_time;

  switch (req->operation) {
  case BLKIF_OP_READ:
@@ -658,6 +688,7 @@ static void dispatch_rw_block_io(blkif_t
  else
  blkif->st_wr_sect += preq.nr_sects;

+ jiffies_to_timeval(jiffies, &cur_time);
  return;

  fail_flush:
diff -NruabBEp xen_blkback_limit.orig/common.h xen_blkback_limit.new//common.h
--- xen_blkback_limit.orig/common.h 2012-12-04 13:03:58.000000000 +0400
+++ xen_blkback_limit.new//common.h 2013-01-28 08:09:35.000000000 +0400
@@ -82,6 +82,11 @@ typedef struct blkif_st {
  unsigned int        waiting_reqs;
  struct request_queue *plug;

+ /* qos information */
+ unsigned long   reqtime;
+ int    reqcount;
+ int    reqrate;
+
  /* statistics */
  unsigned long       st_print;
  int                 st_rd_req;
@@ -106,6 +111,8 @@ struct backend_info
  unsigned major;
  unsigned minor;
  char *mode;
+ /* qos information */
+ struct xenbus_watch reqrate_watch;
 };

 blkif_t *blkif_alloc(domid_t domid);
diff -NruabBEp xen_blkback_limit.orig/xenbus.c xen_blkback_limit.new//xenbus.c
--- xen_blkback_limit.orig/xenbus.c 2012-12-04 13:03:58.000000000 +0400
+++ xen_blkback_limit.new//xenbus.c 2013-01-28 08:22:26.000000000 +0400
@@ -120,6 +120,79 @@ static void update_blkif_status(blkif_t
  } \
  static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)

+static ssize_t
+show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+ ssize_t ret = -ENODEV;
+ struct xenbus_device *dev;
+ struct backend_info *be;
+
+ if (!get_device(_dev))
+ return ret;
+
+ dev = to_xenbus_device(_dev);
+ be = dev_get_drvdata(&dev->dev);
+
+ if (be != NULL)
+ ret = sprintf(buf, "%d\n", be->blkif->reqrate);
+
+ put_device(_dev);
+
+ return ret;
+}
+
+static ssize_t
+store_reqrate(struct device *_dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int value;
+ struct xenbus_device *dev;
+ struct backend_info *be;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (!get_device(_dev))
+ return -ENODEV;
+
+ if (sscanf(buf, "%d", &value) != 1)
+ return -EINVAL;
+
+ dev = to_xenbus_device(_dev);
+ be = dev_get_drvdata(&dev->dev);
+
+ if (be != NULL)
+ be->blkif->reqrate = value;
+
+ put_device(_dev);
+
+ return size;
+}
+static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
+ store_reqrate);
+
+static ssize_t
+show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+ ssize_t ret = -ENODEV;
+ struct xenbus_device *dev;
+ struct backend_info *be;
+
+ if (!get_device(_dev))
+ return ret;
+
+ dev = to_xenbus_device(_dev);
+ be = dev_get_drvdata(&dev->dev);
+
+ if (be != NULL)
+ ret = sprintf(buf, "%d\n", be->blkif->reqcount);
+
+ put_device(_dev);
+
+ return ret;
+}
+static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
+
 VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
 VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
 VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
@@ -146,6 +219,17 @@ static const struct attribute_group vbds
  .attrs = vbdstat_attrs,
 };

+static struct attribute *vbdreq_attrs[] = {
+ &dev_attr_reqrate.attr,
+ &dev_attr_reqcount.attr,
+ NULL
+};
+
+static const struct attribute_group vbdreq_group = {
+ .name = "qos",
+ .attrs = vbdreq_attrs,
+};
+
 VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
 VBD_SHOW(mode, "%s\n", be->mode);

@@ -165,8 +249,13 @@ int xenvbd_sysfs_addif(struct xenbus_dev
  if (error)
  goto fail3;

+ error = sysfs_create_group(&dev->dev.kobj, &vbdreq_group);
+ if (error)
+ goto fail4;
+
  return 0;

+fail4:  sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
 fail3: sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
 fail2: device_remove_file(&dev->dev, &dev_attr_mode);
 fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -175,6 +264,7 @@ fail1: device_remove_file(&dev->dev, &de

 void xenvbd_sysfs_delif(struct xenbus_device *dev)
 {
+ sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
  sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
  device_remove_file(&dev->dev, &dev_attr_mode);
  device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -201,6 +291,12 @@ static int blkback_remove(struct xenbus_
  be->cdrom_watch.node = NULL;
  }

+ if (be->reqrate_watch.node) {
+ unregister_xenbus_watch(&be->reqrate_watch);
+ kfree(be->reqrate_watch.node);
+ be->reqrate_watch.node = NULL;
+ }
+
  if (be->blkif) {
  blkif_disconnect(be->blkif);
  vbd_free(&be->blkif->vbd);
@@ -338,6 +434,7 @@ static void backend_changed(struct xenbu
  struct xenbus_device *dev = be->dev;
  int cdrom = 0;
  char *device_type;
+ char name[TASK_COMM_LEN];

  DPRINTK("");

@@ -376,6 +473,21 @@ static void backend_changed(struct xenbu
  kfree(device_type);
  }

+ /* gather information about QoS policy for this device. */
+ err = blkback_name(be->blkif, name);
+ if (err) {
+ xenbus_dev_error(be->dev, err, "get blkback dev name");
+ return;
+ }
+
+ err = xenbus_gather(XBT_NIL, dev->otherend,
+ "reqrate", "%d", &be->blkif->reqrate,
+ NULL);
+ if (err)
+ DPRINTK("%s xenbus_gather(reqrate) error", name);
+
+ be->blkif->reqtime = jiffies;
+
  if (be->major == 0 && be->minor == 0) {
  /* Front end dir is a number, which is used as the handle. */

@@ -482,6 +594,30 @@ static void frontend_changed(struct xenb

 /* ** Connection ** */

+static void reqrate_changed(struct xenbus_watch *watch,
+ const char **vec, unsigned int len)
+{
+ struct backend_info *be = container_of(watch, struct backend_info,
+ reqrate_watch);
+ int err;
+ char name[TASK_COMM_LEN];
+
+ err = blkback_name(be->blkif, name);
+ if (err) {
+ xenbus_dev_error(be->dev, err, "get blkback dev name");
+ return;
+ }
+
+ err = xenbus_gather(XBT_NIL, be->dev->otherend,
+ "reqrate",  "%d",
+ &be->blkif->reqrate, NULL);
+ if (err) {
+ DPRINTK("%s xenbus_gather(reqrate) error", name);
+ } else {
+ if (be->blkif->reqrate <= 0)
+ be->blkif->reqrate = 0;
+ }
+}

 /**
  * Write the physical details regarding the block device to the store, and
@@ -542,6 +678,21 @@ again:
  xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
  dev->nodename);

+ if (be->reqrate_watch.node) {
+ unregister_xenbus_watch(&be->reqrate_watch);
+ kfree(be->reqrate_watch.node);
+ be->reqrate_watch.node = NULL;
+ }
+
+ err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
+ &be->reqrate_watch,
+ reqrate_changed);
+ if (err) {
+ xenbus_dev_fatal(dev, err, "%s: watching reqrate",
+ dev->nodename);
+ goto abort;
+ }
+
  return;
  abort:
  xenbus_transaction_end(xbt, 1);

2013/1/31 Wei Liu <wei.liu2@citrix.com>:
> On Thu, 2013-01-31 at 05:14 +0000, Vasiliy Tolstov wrote:
>> Sorry forget to send patch
>> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
>> Patch for kernel 3.6.9, but if that needed i can rebase it to current
>> git Linus tree.
>
> Can you inline your patch in your email so that developer can comment on
> it.
>
>
> Wei.
>



-- 
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 Feb 01 06:54:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 06:54: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 1U1AVn-0007tx-V4; Fri, 01 Feb 2013 06:54:11 +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 1U1AVl-0007ts-Ex
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 06:54:09 +0000
Received: from [85.158.143.35:38475] by server-3.bemta-4.messagelabs.com id
	98/37-08920-0966B015; Fri, 01 Feb 2013 06:54:08 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359701642!5187797!1
X-Originating-IP: [209.85.216.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4381 invoked from network); 1 Feb 2013 06:54:04 -0000
Received: from mail-qc0-f181.google.com (HELO mail-qc0-f181.google.com)
	(209.85.216.181)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 06:54:04 -0000
Received: by mail-qc0-f181.google.com with SMTP id x40so1645203qcp.12
	for <xen-devel@lists.xen.org>; Thu, 31 Jan 2013 22:54:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=BDpidav56cZNPJVKQN/fGUelKeshBdKSey++ZEZUHd0=;
	b=Oxy+GVvyR/LZtdNi4mjS2MITMTXwN+urIvmKy66K/phmEqPLpB32J81dlltXgO/05k
	UGlsn0ZtQnSfWZTOVjg04/BQU07lMlgB2XUH2q06d0L6+kaD0Ehivjk7EnI7yYfBAft1
	BsBDFuQtgV6ftGcgb9iZ6K7CzxEt9PGwoIAkQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=BDpidav56cZNPJVKQN/fGUelKeshBdKSey++ZEZUHd0=;
	b=k21bSOnj86j4o1dYbGJFT1dKJRh8jk1+teq4cWgiIb9+stKMBR8dQCprGlsd3Gk5oQ
	tGOpTKBTv5LoEw77MAFkMuUIKIWsY2VhqRpT824UbepbmfVSz9wYshl1untcvAu5CH5A
	310y5yrGCflT3biwowtBGtUHe3bdN0U28cSByNVkR9Rz3nN3/cZPnfWevdJof/aop7ba
	fLyP06CBXVWvdrYaa50Jit9q7wdsHERDTp7pOuKTzuoOu0MU5Ql/UsKVFAXz4N0Wv65U
	SLfLa/U+bSVKImWRPNiT1PVxlp9iBK9IglTmNp3v+7rqdQvsjnr7U/0jAM5Imi8Iytks
	/O3A==
X-Received: by 10.224.180.212 with SMTP id bv20mr11608711qab.6.1359701642305; 
	Thu, 31 Jan 2013 22:54:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 31 Jan 2013 22:53:46 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1359655545.23229.101.camel@zion.uk.xensource.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
	<1359655545.23229.101.camel@zion.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 1 Feb 2013 10:53:46 +0400
X-Google-Sender-Auth: CRde26e4sBFyBIY7J29kfBCuRXg
Message-ID: <CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Gm-Message-State: ALoCoQmKhHpJc2Kg1sd+G9Kr224CK+lGK/9lW8Y/9gualqBIes6tyyFdpBRg1Et1fXKn1vOUt/H8
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback disk I/O limit 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

Sorry,

diff -NruabBEp xen_blkback_limit.orig/blkback.c xen_blkback_limit.new//blkback.c
--- xen_blkback_limit.orig/blkback.c 2012-12-04 13:03:58.000000000 +0400
+++ xen_blkback_limit.new//blkback.c 2013-01-28 08:11:30.000000000 +0400
@@ -211,10 +211,18 @@ static void print_stats(blkif_t *blkif)
  blkif->st_pk_req = 0;
 }

+static void refill_iops(blkif_t *blkif)
+{
+ blkif->reqtime = jiffies + msecs_to_jiffies(1000);
+ blkif->reqcount = 0;
+}
+
 int blkif_schedule(void *arg)
 {
  blkif_t *blkif = arg;
  struct vbd *vbd = &blkif->vbd;
+ int     ret = 0;
+ struct timeval cur_time;

  blkif_get(blkif);

@@ -237,10 +245,22 @@ int blkif_schedule(void *arg)
  blkif->waiting_reqs = 0;
  smp_mb(); /* clear flag *before* checking for work */

- if (do_block_io_op(blkif))
+ ret = do_block_io_op(blkif);
+ if (ret)
  blkif->waiting_reqs = 1;
  unplug_queue(blkif);

+ if (blkif->reqrate) {
+ if (2 == ret && (blkif->reqtime > jiffies)) {
+ jiffies_to_timeval(jiffies, &cur_time);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(blkif->reqtime - jiffies);
+ }
+ if (time_after(jiffies, blkif->reqtime))
+ refill_iops(blkif);
+ }
+
  if (log_stats && time_after(jiffies, blkif->st_print))
  print_stats(blkif);
  }
@@ -394,10 +414,19 @@ static int _do_block_io_op(blkif_t *blki
  rp = blk_rings->common.sring->req_prod;
  rmb(); /* Ensure we see queued requests up to 'rp'. */

+ if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
+ return (rc != rp) ? 2 : 0;
+ }
+
  while (rc != rp) {
  if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
  break;

+ if (blkif->reqrate) {
+ if (blkif->reqcount >= blkif->reqrate)
+ return 2;
+ }
+
  if (kthread_should_stop())
  return 1;

@@ -434,8 +463,8 @@ static int _do_block_io_op(blkif_t *blki

  /* Apply all sanity checks to /private copy/ of request. */
  barrier();
-
  dispatch_rw_block_io(blkif, &req, pending_req);
+ blkif->reqcount++;
  break;
  case BLKIF_OP_DISCARD:
  blk_rings->common.req_cons = rc;
@@ -452,7 +481,7 @@ static int _do_block_io_op(blkif_t *blki
  break;
  default:
  /* A good sign something is wrong: sleep for a while to
- * avoid excessive CPU consumption by a bad guest. */
+ * avoid excessive CPU consumption by a bad guest.*/
  msleep(1);
  blk_rings->common.req_cons = rc;
  barrier();
@@ -501,6 +530,7 @@ static void dispatch_rw_block_io(blkif_t
  uint32_t flags;
  int ret, i;
  int operation;
+ struct timeval cur_time;

  switch (req->operation) {
  case BLKIF_OP_READ:
@@ -658,6 +688,7 @@ static void dispatch_rw_block_io(blkif_t
  else
  blkif->st_wr_sect += preq.nr_sects;

+ jiffies_to_timeval(jiffies, &cur_time);
  return;

  fail_flush:
diff -NruabBEp xen_blkback_limit.orig/common.h xen_blkback_limit.new//common.h
--- xen_blkback_limit.orig/common.h 2012-12-04 13:03:58.000000000 +0400
+++ xen_blkback_limit.new//common.h 2013-01-28 08:09:35.000000000 +0400
@@ -82,6 +82,11 @@ typedef struct blkif_st {
  unsigned int        waiting_reqs;
  struct request_queue *plug;

+ /* qos information */
+ unsigned long   reqtime;
+ int    reqcount;
+ int    reqrate;
+
  /* statistics */
  unsigned long       st_print;
  int                 st_rd_req;
@@ -106,6 +111,8 @@ struct backend_info
  unsigned major;
  unsigned minor;
  char *mode;
+ /* qos information */
+ struct xenbus_watch reqrate_watch;
 };

 blkif_t *blkif_alloc(domid_t domid);
diff -NruabBEp xen_blkback_limit.orig/xenbus.c xen_blkback_limit.new//xenbus.c
--- xen_blkback_limit.orig/xenbus.c 2012-12-04 13:03:58.000000000 +0400
+++ xen_blkback_limit.new//xenbus.c 2013-01-28 08:22:26.000000000 +0400
@@ -120,6 +120,79 @@ static void update_blkif_status(blkif_t
  } \
  static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)

+static ssize_t
+show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+ ssize_t ret = -ENODEV;
+ struct xenbus_device *dev;
+ struct backend_info *be;
+
+ if (!get_device(_dev))
+ return ret;
+
+ dev = to_xenbus_device(_dev);
+ be = dev_get_drvdata(&dev->dev);
+
+ if (be != NULL)
+ ret = sprintf(buf, "%d\n", be->blkif->reqrate);
+
+ put_device(_dev);
+
+ return ret;
+}
+
+static ssize_t
+store_reqrate(struct device *_dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int value;
+ struct xenbus_device *dev;
+ struct backend_info *be;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (!get_device(_dev))
+ return -ENODEV;
+
+ if (sscanf(buf, "%d", &value) != 1)
+ return -EINVAL;
+
+ dev = to_xenbus_device(_dev);
+ be = dev_get_drvdata(&dev->dev);
+
+ if (be != NULL)
+ be->blkif->reqrate = value;
+
+ put_device(_dev);
+
+ return size;
+}
+static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
+ store_reqrate);
+
+static ssize_t
+show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+ ssize_t ret = -ENODEV;
+ struct xenbus_device *dev;
+ struct backend_info *be;
+
+ if (!get_device(_dev))
+ return ret;
+
+ dev = to_xenbus_device(_dev);
+ be = dev_get_drvdata(&dev->dev);
+
+ if (be != NULL)
+ ret = sprintf(buf, "%d\n", be->blkif->reqcount);
+
+ put_device(_dev);
+
+ return ret;
+}
+static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
+
 VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
 VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
 VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
@@ -146,6 +219,17 @@ static const struct attribute_group vbds
  .attrs = vbdstat_attrs,
 };

+static struct attribute *vbdreq_attrs[] = {
+ &dev_attr_reqrate.attr,
+ &dev_attr_reqcount.attr,
+ NULL
+};
+
+static const struct attribute_group vbdreq_group = {
+ .name = "qos",
+ .attrs = vbdreq_attrs,
+};
+
 VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
 VBD_SHOW(mode, "%s\n", be->mode);

@@ -165,8 +249,13 @@ int xenvbd_sysfs_addif(struct xenbus_dev
  if (error)
  goto fail3;

+ error = sysfs_create_group(&dev->dev.kobj, &vbdreq_group);
+ if (error)
+ goto fail4;
+
  return 0;

+fail4:  sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
 fail3: sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
 fail2: device_remove_file(&dev->dev, &dev_attr_mode);
 fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -175,6 +264,7 @@ fail1: device_remove_file(&dev->dev, &de

 void xenvbd_sysfs_delif(struct xenbus_device *dev)
 {
+ sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
  sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
  device_remove_file(&dev->dev, &dev_attr_mode);
  device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -201,6 +291,12 @@ static int blkback_remove(struct xenbus_
  be->cdrom_watch.node = NULL;
  }

+ if (be->reqrate_watch.node) {
+ unregister_xenbus_watch(&be->reqrate_watch);
+ kfree(be->reqrate_watch.node);
+ be->reqrate_watch.node = NULL;
+ }
+
  if (be->blkif) {
  blkif_disconnect(be->blkif);
  vbd_free(&be->blkif->vbd);
@@ -338,6 +434,7 @@ static void backend_changed(struct xenbu
  struct xenbus_device *dev = be->dev;
  int cdrom = 0;
  char *device_type;
+ char name[TASK_COMM_LEN];

  DPRINTK("");

@@ -376,6 +473,21 @@ static void backend_changed(struct xenbu
  kfree(device_type);
  }

+ /* gather information about QoS policy for this device. */
+ err = blkback_name(be->blkif, name);
+ if (err) {
+ xenbus_dev_error(be->dev, err, "get blkback dev name");
+ return;
+ }
+
+ err = xenbus_gather(XBT_NIL, dev->otherend,
+ "reqrate", "%d", &be->blkif->reqrate,
+ NULL);
+ if (err)
+ DPRINTK("%s xenbus_gather(reqrate) error", name);
+
+ be->blkif->reqtime = jiffies;
+
  if (be->major == 0 && be->minor == 0) {
  /* Front end dir is a number, which is used as the handle. */

@@ -482,6 +594,30 @@ static void frontend_changed(struct xenb

 /* ** Connection ** */

+static void reqrate_changed(struct xenbus_watch *watch,
+ const char **vec, unsigned int len)
+{
+ struct backend_info *be = container_of(watch, struct backend_info,
+ reqrate_watch);
+ int err;
+ char name[TASK_COMM_LEN];
+
+ err = blkback_name(be->blkif, name);
+ if (err) {
+ xenbus_dev_error(be->dev, err, "get blkback dev name");
+ return;
+ }
+
+ err = xenbus_gather(XBT_NIL, be->dev->otherend,
+ "reqrate",  "%d",
+ &be->blkif->reqrate, NULL);
+ if (err) {
+ DPRINTK("%s xenbus_gather(reqrate) error", name);
+ } else {
+ if (be->blkif->reqrate <= 0)
+ be->blkif->reqrate = 0;
+ }
+}

 /**
  * Write the physical details regarding the block device to the store, and
@@ -542,6 +678,21 @@ again:
  xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
  dev->nodename);

+ if (be->reqrate_watch.node) {
+ unregister_xenbus_watch(&be->reqrate_watch);
+ kfree(be->reqrate_watch.node);
+ be->reqrate_watch.node = NULL;
+ }
+
+ err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
+ &be->reqrate_watch,
+ reqrate_changed);
+ if (err) {
+ xenbus_dev_fatal(dev, err, "%s: watching reqrate",
+ dev->nodename);
+ goto abort;
+ }
+
  return;
  abort:
  xenbus_transaction_end(xbt, 1);

2013/1/31 Wei Liu <wei.liu2@citrix.com>:
> On Thu, 2013-01-31 at 05:14 +0000, Vasiliy Tolstov wrote:
>> Sorry forget to send patch
>> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
>> Patch for kernel 3.6.9, but if that needed i can rebase it to current
>> git Linus tree.
>
> Can you inline your patch in your email so that developer can comment on
> it.
>
>
> Wei.
>



-- 
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 Feb 01 10:13:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 10: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 1U1Dby-0002nY-AN; Fri, 01 Feb 2013 10:12:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U1Dbw-0002nQ-Sl; Fri, 01 Feb 2013 10:12:45 +0000
Received: from [85.158.143.35:45163] by server-3.bemta-4.messagelabs.com id
	1F/75-08920-C159B015; Fri, 01 Feb 2013 10:12:44 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1359713142!13347088!1
X-Originating-IP: [209.85.212.179]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26586 invoked from network); 1 Feb 2013 10:05:46 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 10:05:46 -0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so370915wid.12
	for <multiple recipients>; Fri, 01 Feb 2013 02:05:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=4BGPjfra0VX/mv+hjsIIPbwONDtwdbZqVQPmBkL6hUQ=;
	b=IMCiPp6JkRL3pZysMnsqTP5rYH+/YE8PpEswYnKB3t+xAexHykBh8SK0XpCEX0Zh8E
	/osb2rEfaTRGn93Lp41PG25y7hT32l9tK+3lxeCjza6wfkwj5fivfKtzQSB0bjPJVW8z
	IuVeTCqndT0OFEt3ZVPHVp+MpRiIO6XuetWrn5W4r2d/Jou5R/5K5yd0t98i84uiO2EY
	hRf0qd7U8fje52zK4S++G4oSZZlsoz+TtJqgnlrAIfy8Gb7ZShutxZxXWHlSSHTRyDxt
	F8J5X2+RSRFhCFh7Qnr/5RmyBobNafcYCtJa4wQAq7wfhtB6DSypMkVIlysflhsQozyc
	w9Tw==
MIME-Version: 1.0
X-Received: by 10.194.76.7 with SMTP id g7mr20550532wjw.50.1359713140241; Fri,
	01 Feb 2013 02:05:40 -0800 (PST)
Received: by 10.227.203.18 with HTTP; Fri, 1 Feb 2013 02:05:40 -0800 (PST)
Date: Fri, 1 Feb 2013 11:05:40 +0100
Message-ID: <CAMCOOJu3WcmDw8D3hcMoSdqwZSk2D7j2xrEwd7AoV=rU-rvTKw@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: xen-users <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xenstore stubdom on Xen 4.2.1 (XSM/FLASK 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: multipart/mixed; boundary="===============5996116348571867208=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5996116348571867208==
Content-Type: multipart/alternative; boundary=047d7beba202b8732d04d4a6e213

--047d7beba202b8732d04d4a6e213
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I am trying to get a xenstore/oxenstore (oxenstore is mirage based) stubdom
to get to work on Xen 4.2.1.

I know that I need to set XSM/FLASK rules and so I have compiled 4.2.1 with
XSM and FLASK.

I already talked with Daniel de Graaf (on the mailinglists) and Steven
Maresca on IRC about this thing. Daniel already wrote a XSM/FLASK ruleset
in this thread:
http://lists.xen.org/archives/html/xen-devel/2013-01/msg00956.html

So he said that this rule is incompatible with 4.2.1 and only works on 4.3
unstable. I know that there are more or less just sysctl hypercalls are
support in XSM/FLASK on 4.2.1 and no domctl hypercalls.

Is it possible to write a ruleset (or modifying the existing one) so that
it is compatible with 4.2.1?

Hope that someone could help me.

Best Regards

--047d7beba202b8732d04d4a6e213
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Hello all,<br><br>I am trying to get a=
 xenstore/oxenstore (oxenstore is mirage based) stubdom to get to work on X=
en 4.2.1.<br><br>I know that I need to set XSM/FLASK rules and so I have co=
mpiled 4.2.1 with XSM and FLASK.<br>
<br></div>I already talked with Daniel de Graaf (on the mailinglists) and S=
teven Maresca on IRC about this thing. Daniel already wrote a XSM/FLASK rul=
eset in this thread: <a href=3D"http://lists.xen.org/archives/html/xen-deve=
l/2013-01/msg00956.html">http://lists.xen.org/archives/html/xen-devel/2013-=
01/msg00956.html</a><br>
<br></div>So he said that this rule is incompatible with 4.2.1 and only wor=
ks on 4.3 unstable. I know that there are more or less just sysctl hypercal=
ls are support in XSM/FLASK on 4.2.1 and no domctl hypercalls.<br><br></div=
>
Is it possible to write a ruleset (or modifying the existing one) so that i=
t is compatible with 4.2.1?<br><br></div>Hope that someone could help me.<b=
r><br>Best Regards<br></div>

--047d7beba202b8732d04d4a6e213--


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

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

--===============5996116348571867208==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 10:13:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 10: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 1U1Dby-0002nY-AN; Fri, 01 Feb 2013 10:12:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U1Dbw-0002nQ-Sl; Fri, 01 Feb 2013 10:12:45 +0000
Received: from [85.158.143.35:45163] by server-3.bemta-4.messagelabs.com id
	1F/75-08920-C159B015; Fri, 01 Feb 2013 10:12:44 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1359713142!13347088!1
X-Originating-IP: [209.85.212.179]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26586 invoked from network); 1 Feb 2013 10:05:46 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 10:05:46 -0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so370915wid.12
	for <multiple recipients>; Fri, 01 Feb 2013 02:05:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=4BGPjfra0VX/mv+hjsIIPbwONDtwdbZqVQPmBkL6hUQ=;
	b=IMCiPp6JkRL3pZysMnsqTP5rYH+/YE8PpEswYnKB3t+xAexHykBh8SK0XpCEX0Zh8E
	/osb2rEfaTRGn93Lp41PG25y7hT32l9tK+3lxeCjza6wfkwj5fivfKtzQSB0bjPJVW8z
	IuVeTCqndT0OFEt3ZVPHVp+MpRiIO6XuetWrn5W4r2d/Jou5R/5K5yd0t98i84uiO2EY
	hRf0qd7U8fje52zK4S++G4oSZZlsoz+TtJqgnlrAIfy8Gb7ZShutxZxXWHlSSHTRyDxt
	F8J5X2+RSRFhCFh7Qnr/5RmyBobNafcYCtJa4wQAq7wfhtB6DSypMkVIlysflhsQozyc
	w9Tw==
MIME-Version: 1.0
X-Received: by 10.194.76.7 with SMTP id g7mr20550532wjw.50.1359713140241; Fri,
	01 Feb 2013 02:05:40 -0800 (PST)
Received: by 10.227.203.18 with HTTP; Fri, 1 Feb 2013 02:05:40 -0800 (PST)
Date: Fri, 1 Feb 2013 11:05:40 +0100
Message-ID: <CAMCOOJu3WcmDw8D3hcMoSdqwZSk2D7j2xrEwd7AoV=rU-rvTKw@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: xen-users <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] xenstore stubdom on Xen 4.2.1 (XSM/FLASK 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: multipart/mixed; boundary="===============5996116348571867208=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5996116348571867208==
Content-Type: multipart/alternative; boundary=047d7beba202b8732d04d4a6e213

--047d7beba202b8732d04d4a6e213
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I am trying to get a xenstore/oxenstore (oxenstore is mirage based) stubdom
to get to work on Xen 4.2.1.

I know that I need to set XSM/FLASK rules and so I have compiled 4.2.1 with
XSM and FLASK.

I already talked with Daniel de Graaf (on the mailinglists) and Steven
Maresca on IRC about this thing. Daniel already wrote a XSM/FLASK ruleset
in this thread:
http://lists.xen.org/archives/html/xen-devel/2013-01/msg00956.html

So he said that this rule is incompatible with 4.2.1 and only works on 4.3
unstable. I know that there are more or less just sysctl hypercalls are
support in XSM/FLASK on 4.2.1 and no domctl hypercalls.

Is it possible to write a ruleset (or modifying the existing one) so that
it is compatible with 4.2.1?

Hope that someone could help me.

Best Regards

--047d7beba202b8732d04d4a6e213
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Hello all,<br><br>I am trying to get a=
 xenstore/oxenstore (oxenstore is mirage based) stubdom to get to work on X=
en 4.2.1.<br><br>I know that I need to set XSM/FLASK rules and so I have co=
mpiled 4.2.1 with XSM and FLASK.<br>
<br></div>I already talked with Daniel de Graaf (on the mailinglists) and S=
teven Maresca on IRC about this thing. Daniel already wrote a XSM/FLASK rul=
eset in this thread: <a href=3D"http://lists.xen.org/archives/html/xen-deve=
l/2013-01/msg00956.html">http://lists.xen.org/archives/html/xen-devel/2013-=
01/msg00956.html</a><br>
<br></div>So he said that this rule is incompatible with 4.2.1 and only wor=
ks on 4.3 unstable. I know that there are more or less just sysctl hypercal=
ls are support in XSM/FLASK on 4.2.1 and no domctl hypercalls.<br><br></div=
>
Is it possible to write a ruleset (or modifying the existing one) so that i=
t is compatible with 4.2.1?<br><br></div>Hope that someone could help me.<b=
r><br>Best Regards<br></div>

--047d7beba202b8732d04d4a6e213--


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

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

--===============5996116348571867208==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 11:00:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:00: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 1U1ELo-0004Ko-0Y; Fri, 01 Feb 2013 11:00:08 +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 1U1ELm-0004Kj-Bs
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:00:06 +0000
Received: from [85.158.143.99:43176] by server-3.bemta-4.messagelabs.com id
	A6/5F-08920-530AB015; Fri, 01 Feb 2013 11:00:05 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359716403!17510192!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7244 invoked from network); 1 Feb 2013 11:00:04 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:00:04 -0000
Received: by mail-qa0-f45.google.com with SMTP id g10so210441qah.4
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:00:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to
	:content-type; bh=O0UI6EmkJMlKCy1f9WvZcE/TnPlZW9F/pFjcfHw0/KE=;
	b=UNkTOUCn7QpnSEdYE1vbNh+5DwEJNTyFx4yCskxvujYfZhvyrW2L/g2geukOgrkAOs
	kVVZ3id2Mv7/NMR0OjyWhVMjkUtFq54EhxkvsG2bSXOccIGrj27UEbS107pWdAyox09O
	31VPR6OowXOi6NdUPuy1Wa4XkBmWWnCgWcYQ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=O0UI6EmkJMlKCy1f9WvZcE/TnPlZW9F/pFjcfHw0/KE=;
	b=Q759XSBsZQmu++5sA7WdePMQtpoT63e5pgcxHmrTCEVjdRrzqV/kS0WM3fE+GCtTij
	qBZzcv81BHWyLSXzNXVerktrGVhnKRPcmy1ljO7fDmJOXWfJhJquLpxRVBfC76zFtPdB
	UsDS+0mGLFrFDNMVNg7vZBJJ5Tk77+xz0OIV5qnGgo/Pz4bNHBCyIv8/TefJX4sa863Q
	y5QbXE9RRmB60iM6o17/BAXjX5jm0lOkBBPuDKaHFXqZpvsKm4kKyryKCGQ5FXIglTdr
	d5h0gLv2h8TB47OhQkqOYWAF8Ix/i2Mu7QcwQzbFfLvD57HlD1/9rC7dOWYXGw2QHk1S
	vNSw==
X-Received: by 10.224.180.212 with SMTP id bv20mr12212372qab.6.1359716402971; 
	Fri, 01 Feb 2013 03:00:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Fri, 1 Feb 2013 02:59:46 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 1 Feb 2013 14:59:46 +0400
X-Google-Sender-Auth: sP6bxRpC-pmOSZR_cfV5qfj7Lzw
Message-ID: <CACaajQuePBZ5SqhvG1oG0GO46g_2T3Tj_pX1LbxSHJ2pW15BsA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQmXG8tff4lu+MGwFkjVquG3P32oizBUxc2m2Xa1Vm8+jiK2ZcOSdTUxki5Ke9U/osWD7Bz+
Subject: Re: [Xen-devel] blkback disk I/O limit 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

2013/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> Sorry forget to send patch
> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
> Patch for kernel 3.6.9, but if that needed i can rebase it to current
> git Linus tree.

Patch based on work andrew.xu (
http://xen.1045712.n5.nabble.com/VM-disk-I-O-limit-patch-td4509813.html
)

--
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

2013/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> Sorry forget to send patch
> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
> Patch for kernel 3.6.9, but if that needed i can rebase it to current
> git Linus tree.
>
> 2013/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
>> Hello. For own needs i'm write simple blkback disk i/o limit patch,
>> that can limit disk i/o based on iops. I need xen based iops shaper
>> because of own storage architecture.
>> Our storages node provide disks via scst over infiniband network.
>> On xen nodes we via srp attach this disks. Each xen connects to 2
>> storages in same time and multipath provide failover.
>>
>> Each disk contains LVM (not CLVM), for each virtual machine we create
>> PV disk. And via device mapper raid1 we create disk, used for domU. In
>> this case if one node failed VM works fine with one disk in raid1.
>>
>> All works greate, but in this setup we can't use cgroups and dm-ioband.
>> Some times ago CFQ disk scheduler top working with BIO devices and
>> provide control only on buttom layer. (In our case we can use CFQ only
>> on srp disk, and shape i/o only for all clients on xen node).
>> dm-ioband work's unstable when the some domU have massive i/o (our
>> tests says that if domU have ext4 and have 20000 iops sometimes dom0
>> crashed, or disk coccupted. And with dm-ioband if one storage node
>> down sometimes we miss some data from disk. And dm-ioband can't
>> provide on the fly control of iops.
>>
>> This patch tryes to solve own problems. May someone from xen team look
>> at it and says how code looks? What i need to change/rewrite? May be
>> sometime this can be used in main linux xen tree... (i hope).
>> This patch is only for phy devices. For blktap devices i speak with
>> Thanos Makatos (author of blktap3) and may be in future this
>> functionality may be added to blktap3..
>>
>> Thank You.
>>
>> --
>> Vasiliy Tolstov,
>> Clodo.ru
>> e-mail: v.tolstov@selfip.ru
>> jabber: vase@selfip.ru
>
>
>
> --
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.tolstov@selfip.ru
> jabber: vase@selfip.ru



-- 
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 Feb 01 11:00:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:00: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 1U1ELo-0004Ko-0Y; Fri, 01 Feb 2013 11:00:08 +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 1U1ELm-0004Kj-Bs
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:00:06 +0000
Received: from [85.158.143.99:43176] by server-3.bemta-4.messagelabs.com id
	A6/5F-08920-530AB015; Fri, 01 Feb 2013 11:00:05 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359716403!17510192!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7244 invoked from network); 1 Feb 2013 11:00:04 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:00:04 -0000
Received: by mail-qa0-f45.google.com with SMTP id g10so210441qah.4
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:00:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to
	:content-type; bh=O0UI6EmkJMlKCy1f9WvZcE/TnPlZW9F/pFjcfHw0/KE=;
	b=UNkTOUCn7QpnSEdYE1vbNh+5DwEJNTyFx4yCskxvujYfZhvyrW2L/g2geukOgrkAOs
	kVVZ3id2Mv7/NMR0OjyWhVMjkUtFq54EhxkvsG2bSXOccIGrj27UEbS107pWdAyox09O
	31VPR6OowXOi6NdUPuy1Wa4XkBmWWnCgWcYQ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to
	:content-type:x-gm-message-state;
	bh=O0UI6EmkJMlKCy1f9WvZcE/TnPlZW9F/pFjcfHw0/KE=;
	b=Q759XSBsZQmu++5sA7WdePMQtpoT63e5pgcxHmrTCEVjdRrzqV/kS0WM3fE+GCtTij
	qBZzcv81BHWyLSXzNXVerktrGVhnKRPcmy1ljO7fDmJOXWfJhJquLpxRVBfC76zFtPdB
	UsDS+0mGLFrFDNMVNg7vZBJJ5Tk77+xz0OIV5qnGgo/Pz4bNHBCyIv8/TefJX4sa863Q
	y5QbXE9RRmB60iM6o17/BAXjX5jm0lOkBBPuDKaHFXqZpvsKm4kKyryKCGQ5FXIglTdr
	d5h0gLv2h8TB47OhQkqOYWAF8Ix/i2Mu7QcwQzbFfLvD57HlD1/9rC7dOWYXGw2QHk1S
	vNSw==
X-Received: by 10.224.180.212 with SMTP id bv20mr12212372qab.6.1359716402971; 
	Fri, 01 Feb 2013 03:00:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Fri, 1 Feb 2013 02:59:46 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 1 Feb 2013 14:59:46 +0400
X-Google-Sender-Auth: sP6bxRpC-pmOSZR_cfV5qfj7Lzw
Message-ID: <CACaajQuePBZ5SqhvG1oG0GO46g_2T3Tj_pX1LbxSHJ2pW15BsA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQmXG8tff4lu+MGwFkjVquG3P32oizBUxc2m2Xa1Vm8+jiK2ZcOSdTUxki5Ke9U/osWD7Bz+
Subject: Re: [Xen-devel] blkback disk I/O limit 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

2013/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> Sorry forget to send patch
> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
> Patch for kernel 3.6.9, but if that needed i can rebase it to current
> git Linus tree.

Patch based on work andrew.xu (
http://xen.1045712.n5.nabble.com/VM-disk-I-O-limit-patch-td4509813.html
)

--
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

2013/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> Sorry forget to send patch
> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
> Patch for kernel 3.6.9, but if that needed i can rebase it to current
> git Linus tree.
>
> 2013/1/31 Vasiliy Tolstov <v.tolstov@selfip.ru>:
>> Hello. For own needs i'm write simple blkback disk i/o limit patch,
>> that can limit disk i/o based on iops. I need xen based iops shaper
>> because of own storage architecture.
>> Our storages node provide disks via scst over infiniband network.
>> On xen nodes we via srp attach this disks. Each xen connects to 2
>> storages in same time and multipath provide failover.
>>
>> Each disk contains LVM (not CLVM), for each virtual machine we create
>> PV disk. And via device mapper raid1 we create disk, used for domU. In
>> this case if one node failed VM works fine with one disk in raid1.
>>
>> All works greate, but in this setup we can't use cgroups and dm-ioband.
>> Some times ago CFQ disk scheduler top working with BIO devices and
>> provide control only on buttom layer. (In our case we can use CFQ only
>> on srp disk, and shape i/o only for all clients on xen node).
>> dm-ioband work's unstable when the some domU have massive i/o (our
>> tests says that if domU have ext4 and have 20000 iops sometimes dom0
>> crashed, or disk coccupted. And with dm-ioband if one storage node
>> down sometimes we miss some data from disk. And dm-ioband can't
>> provide on the fly control of iops.
>>
>> This patch tryes to solve own problems. May someone from xen team look
>> at it and says how code looks? What i need to change/rewrite? May be
>> sometime this can be used in main linux xen tree... (i hope).
>> This patch is only for phy devices. For blktap devices i speak with
>> Thanos Makatos (author of blktap3) and may be in future this
>> functionality may be added to blktap3..
>>
>> Thank You.
>>
>> --
>> Vasiliy Tolstov,
>> Clodo.ru
>> e-mail: v.tolstov@selfip.ru
>> jabber: vase@selfip.ru
>
>
>
> --
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.tolstov@selfip.ru
> jabber: vase@selfip.ru



-- 
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 Feb 01 11:04:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPP-0004TI-ME; Fri, 01 Feb 2013 11:03:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPO-0004TB-6s
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:50 +0000
Received: from [85.158.138.51:36294] by server-3.bemta-3.messagelabs.com id
	9B/0B-31070-511AB015; Fri, 01 Feb 2013 11:03:49 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359716628!28383282!1
X-Originating-IP: [209.85.214.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7865 invoked from network); 1 Feb 2013 11:03:48 -0000
Received: from mail-bk0-f44.google.com (HELO mail-bk0-f44.google.com)
	(209.85.214.44)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:48 -0000
Received: by mail-bk0-f44.google.com with SMTP id j4so1763544bkw.3
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:content-type:mime-version
	:content-transfer-encoding:subject:message-id:user-agent:date:from
	:to:cc; bh=EwiH6WEcE5pLPyKbsyKh1C+1q0qq6R6dFxtO8p3xQ+4=;
	b=mw6bojkGM9IYpnD2V5WTamfaHVCMsNHsx80WRrc10GWcR43g5PR1i+31CDOMfXmhr1
	XgSdus58Lc5gSDaiZtqdJi1DX1bPMAACvHQWhuUu03v9SHSxyDOGYhfGRGvRYtMAVPvs
	H2tBEtFboRMKsL6JFUyMLwAVd1JLonYrZCwmo8fgumXl0KmtykV/96ODCg5uZexY3cMj
	3+1/RLND70Gk0OMCav5X6dPFiVDF6s7GNvZKmbrQy2mKzywZVFMup+3XP2WFWPEgxlte
	9G15zndsCNTWcswdmXDKErl+u+SwzGMRXmKRt0aL7y0tqAH65wRsQ5kYZKHIu0tEn97X
	iDHA==
X-Received: by 10.204.9.12 with SMTP id j12mr3242942bkj.89.1359716627951;
	Fri, 01 Feb 2013 03:03:47 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.45
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:47 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:10 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Everyone,

V3 of the NUMA aware scheduling series. It is nothing more than v2 with all
the review comments I got, addressed... Or so I think. :-)

I added a new patch in the series (#3), for dealing with the suboptimal SMT
load balancing in credit there, instead than within what now is patch #4.

I ran the following benchmarks (again):

 * SpecJBB is all about throughput, so pinning is likely the ideal solution.

 * Sysbench-memory is the time it takes for writing a fixed amount of memory
   (and then it is the throughput that is measured). What we expect is
   locality to be important, but at the same time the potential imbalances
   due to pinning could have a say in it.

 * LMBench-proc is the time it takes for a process to fork a fixed amount of
   children. This is much more about latency than throughput, with locality
   of memory accesses playing a smaller role and, again, imbalances due to
   pinning being a potential issue.

Summarizing, we expect pinning to win on throughput biased benchmarks (SpecJBB
and Sysbench), while not having any affinity should be better when latency is
important, especially under (over)load (i.e., on LMBench). NUMA aware
scheduling tries to get the best out of the two approaches: take advantage of
locality, but in a flexible way. Therefore, it would be nice for it to sit in
the middle:
 - not as bad as no-affinity (or, if you prefer, almost as good as pinning)
   when looking at SpecJBB and Sysbench results;
 - not as bad as pinning (or, if you prefer, almost as good as no-affinity)
   when looking at LMBench results.

On a 2 nodes, 16 cores system, where I can have from 2 to 10 VMs (2 vCPUs,
960MB RAM each) executing the benchmarks concurrently, here's what I get:

 ----------------------------------------------------
 | SpecJBB2005, throughput (the higher the better)  |
 ----------------------------------------------------
 | #VMs | No affinity |  Pinning  | NUMA scheduling |
 |    2 |  43318.613  | 49715.158 |    49822.545    |
 |    6 |  29587.838  | 33560.944 |    33739.412    |
 |   10 |  19223.962  | 21860.794 |    20089.602    |
 ----------------------------------------------------
 | Sysbench memory, throughput (the higher the better)
 ----------------------------------------------------
 | #VMs | No affinity |  Pinning  | NUMA scheduling |
 |    2 |  469.37667  | 534.03167 |    555.09500    |
 |    6 |  411.45056  | 437.02333 |    463.53389    |
 |   10 |  292.79400  | 309.63800 |    305.55167    |
 ----------------------------------------------------
 | LMBench proc, latency (the lower the better)     |
 ----------------------------------------------------
 | #VMs | No affinity |  Pinning  | NUMA scheduling |
 ----------------------------------------------------
 |    2 |  788.06613  | 753.78508 |    750.07010    |
 |    6 |  986.44955  | 1076.7447 |    900.21504    |
 |   10 |  1211.2434  | 1371.6014 |    1285.5947    |
 ----------------------------------------------------

Which, reasoning in terms of %-performances increase/decrease, means NUMA aware
scheduling does as follows, as compared to no-affinity at all and to pinning:

     ----------------------------------
     | SpecJBB2005 (throughput)       |
     ----------------------------------
     | #VMs | No affinity |  Pinning  |
     |    2 |   +13.05%   |  +0.21%   |
     |    6 |   +12.30%   |  +0.53%   |
     |   10 |    +4.31%   |  -8.82%   |
     ----------------------------------
     | Sysbench memory (throughput)   |
     ----------------------------------
     | #VMs | No affinity |  Pinning  |
     |    2 |   +15.44%   |  +3.79%   |
     |    6 |   +11.24%   |  +5.72%   |
     |   10 |    +4.18%   |  -1.34%   |
     ----------------------------------
     | LMBench proc (latency)         | NOTICE: -x.xx% = GOOD here
     ----------------------------------
     | #VMs | No affinity |  Pinning  |
     ----------------------------------
     |    2 |    -5.66%   |  -0.50%   |
     |    6 |    -9.58%   | -19.61%   |
     |   10 |    +5.78%   |  -6.69%   |
     ----------------------------------

So, not bad at all. :-) In particular, when not in overload, NUMA scheduling is
the absolute best of all the three, even when it was expectable for one of the
other approaches to win. In fact, if looking at the 2 and 6 VMs cases, it beats
(although by a very small amount in the SpecJBB case) pinning in both the
throughput biased benchmarks, as well as it beats no-affinity on LMBench.  Of
course it does a lot better than no-pinning on throughput and than pinning on
latency (exp. with 6 VMs), but that was expected.

Regarding the overloaded case, NUMA scheduling scores "in the middle", i.e.,
better than no-affinity but worse than pinning on throughput benchs, and the
vice-versa on the latency bench, as it was expectable and intended, and this is
fine as it is right what we expected from it. It must be noticed, however, that
the benefits are not as huge as in the non-overloaded case. I chased the reason
and found out that our load-balancing approach --in particular the fact we rely
on tickling idle pCPUs to come pick up new work by themselves-- couples
particularly bad with the new concept of node affinity. I spent some time
looking for a simple "fix" for this, but it does not seem amendable to me, so
I'll prepare a patch, using a completely different approach, and send it
separately from this series (hopefully on top of it, in case this will have hit
the repo at that time :-D). For now, I really think we can be happy with the
performance figures this series enables... After all, I'm overloading the box
by 20% (without counting Dom0 vCPUs!) and still seeing improvements, although
perhaps not as huge as they could have been. Thoughts?

Here are the patches included in the series. I '*'-ed ones already received one
or more acks during previous rounds. Of course, I retained these Ack-s only for
the patches that have not been touched, or only underwent minor cluenups. Of
course, feel free to re-review everything, whatever your Ack is there or not!

 * [ 1/11] xen, libxc: rename xenctl_cpumap to xenctl_bitmap
 * [ 2/11] xen, libxc: introduce node maps and masks
   [ 3/11] xen: sched_credit: when picking, make sure we get an idle one, if any
   [ 4/11] xen: sched_credit: let the scheduler know about node-affinity
 * [ 5/11] xen: allow for explicitly specifying node-affinity
 * [ 6/11] libxc: allow for explicitly specifying node-affinity
 * [ 7/11] libxl: allow for explicitly specifying node-affinity
   [ 8/11] libxl: optimize the calculation of how many VCPUs can run on a candidate
 * [ 9/11] libxl: automatic placement deals with node-affinity
 * [10/11] xl: add node-affinity to the output of `xl list`
   [11/11] docs: rearrange and update NUMA placement documentation

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 Fri Feb 01 11:04:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPP-0004TI-ME; Fri, 01 Feb 2013 11:03:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPO-0004TB-6s
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:50 +0000
Received: from [85.158.138.51:36294] by server-3.bemta-3.messagelabs.com id
	9B/0B-31070-511AB015; Fri, 01 Feb 2013 11:03:49 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359716628!28383282!1
X-Originating-IP: [209.85.214.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7865 invoked from network); 1 Feb 2013 11:03:48 -0000
Received: from mail-bk0-f44.google.com (HELO mail-bk0-f44.google.com)
	(209.85.214.44)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:48 -0000
Received: by mail-bk0-f44.google.com with SMTP id j4so1763544bkw.3
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:content-type:mime-version
	:content-transfer-encoding:subject:message-id:user-agent:date:from
	:to:cc; bh=EwiH6WEcE5pLPyKbsyKh1C+1q0qq6R6dFxtO8p3xQ+4=;
	b=mw6bojkGM9IYpnD2V5WTamfaHVCMsNHsx80WRrc10GWcR43g5PR1i+31CDOMfXmhr1
	XgSdus58Lc5gSDaiZtqdJi1DX1bPMAACvHQWhuUu03v9SHSxyDOGYhfGRGvRYtMAVPvs
	H2tBEtFboRMKsL6JFUyMLwAVd1JLonYrZCwmo8fgumXl0KmtykV/96ODCg5uZexY3cMj
	3+1/RLND70Gk0OMCav5X6dPFiVDF6s7GNvZKmbrQy2mKzywZVFMup+3XP2WFWPEgxlte
	9G15zndsCNTWcswdmXDKErl+u+SwzGMRXmKRt0aL7y0tqAH65wRsQ5kYZKHIu0tEn97X
	iDHA==
X-Received: by 10.204.9.12 with SMTP id j12mr3242942bkj.89.1359716627951;
	Fri, 01 Feb 2013 03:03:47 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.45
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:47 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:10 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Everyone,

V3 of the NUMA aware scheduling series. It is nothing more than v2 with all
the review comments I got, addressed... Or so I think. :-)

I added a new patch in the series (#3), for dealing with the suboptimal SMT
load balancing in credit there, instead than within what now is patch #4.

I ran the following benchmarks (again):

 * SpecJBB is all about throughput, so pinning is likely the ideal solution.

 * Sysbench-memory is the time it takes for writing a fixed amount of memory
   (and then it is the throughput that is measured). What we expect is
   locality to be important, but at the same time the potential imbalances
   due to pinning could have a say in it.

 * LMBench-proc is the time it takes for a process to fork a fixed amount of
   children. This is much more about latency than throughput, with locality
   of memory accesses playing a smaller role and, again, imbalances due to
   pinning being a potential issue.

Summarizing, we expect pinning to win on throughput biased benchmarks (SpecJBB
and Sysbench), while not having any affinity should be better when latency is
important, especially under (over)load (i.e., on LMBench). NUMA aware
scheduling tries to get the best out of the two approaches: take advantage of
locality, but in a flexible way. Therefore, it would be nice for it to sit in
the middle:
 - not as bad as no-affinity (or, if you prefer, almost as good as pinning)
   when looking at SpecJBB and Sysbench results;
 - not as bad as pinning (or, if you prefer, almost as good as no-affinity)
   when looking at LMBench results.

On a 2 nodes, 16 cores system, where I can have from 2 to 10 VMs (2 vCPUs,
960MB RAM each) executing the benchmarks concurrently, here's what I get:

 ----------------------------------------------------
 | SpecJBB2005, throughput (the higher the better)  |
 ----------------------------------------------------
 | #VMs | No affinity |  Pinning  | NUMA scheduling |
 |    2 |  43318.613  | 49715.158 |    49822.545    |
 |    6 |  29587.838  | 33560.944 |    33739.412    |
 |   10 |  19223.962  | 21860.794 |    20089.602    |
 ----------------------------------------------------
 | Sysbench memory, throughput (the higher the better)
 ----------------------------------------------------
 | #VMs | No affinity |  Pinning  | NUMA scheduling |
 |    2 |  469.37667  | 534.03167 |    555.09500    |
 |    6 |  411.45056  | 437.02333 |    463.53389    |
 |   10 |  292.79400  | 309.63800 |    305.55167    |
 ----------------------------------------------------
 | LMBench proc, latency (the lower the better)     |
 ----------------------------------------------------
 | #VMs | No affinity |  Pinning  | NUMA scheduling |
 ----------------------------------------------------
 |    2 |  788.06613  | 753.78508 |    750.07010    |
 |    6 |  986.44955  | 1076.7447 |    900.21504    |
 |   10 |  1211.2434  | 1371.6014 |    1285.5947    |
 ----------------------------------------------------

Which, reasoning in terms of %-performances increase/decrease, means NUMA aware
scheduling does as follows, as compared to no-affinity at all and to pinning:

     ----------------------------------
     | SpecJBB2005 (throughput)       |
     ----------------------------------
     | #VMs | No affinity |  Pinning  |
     |    2 |   +13.05%   |  +0.21%   |
     |    6 |   +12.30%   |  +0.53%   |
     |   10 |    +4.31%   |  -8.82%   |
     ----------------------------------
     | Sysbench memory (throughput)   |
     ----------------------------------
     | #VMs | No affinity |  Pinning  |
     |    2 |   +15.44%   |  +3.79%   |
     |    6 |   +11.24%   |  +5.72%   |
     |   10 |    +4.18%   |  -1.34%   |
     ----------------------------------
     | LMBench proc (latency)         | NOTICE: -x.xx% = GOOD here
     ----------------------------------
     | #VMs | No affinity |  Pinning  |
     ----------------------------------
     |    2 |    -5.66%   |  -0.50%   |
     |    6 |    -9.58%   | -19.61%   |
     |   10 |    +5.78%   |  -6.69%   |
     ----------------------------------

So, not bad at all. :-) In particular, when not in overload, NUMA scheduling is
the absolute best of all the three, even when it was expectable for one of the
other approaches to win. In fact, if looking at the 2 and 6 VMs cases, it beats
(although by a very small amount in the SpecJBB case) pinning in both the
throughput biased benchmarks, as well as it beats no-affinity on LMBench.  Of
course it does a lot better than no-pinning on throughput and than pinning on
latency (exp. with 6 VMs), but that was expected.

Regarding the overloaded case, NUMA scheduling scores "in the middle", i.e.,
better than no-affinity but worse than pinning on throughput benchs, and the
vice-versa on the latency bench, as it was expectable and intended, and this is
fine as it is right what we expected from it. It must be noticed, however, that
the benefits are not as huge as in the non-overloaded case. I chased the reason
and found out that our load-balancing approach --in particular the fact we rely
on tickling idle pCPUs to come pick up new work by themselves-- couples
particularly bad with the new concept of node affinity. I spent some time
looking for a simple "fix" for this, but it does not seem amendable to me, so
I'll prepare a patch, using a completely different approach, and send it
separately from this series (hopefully on top of it, in case this will have hit
the repo at that time :-D). For now, I really think we can be happy with the
performance figures this series enables... After all, I'm overloading the box
by 20% (without counting Dom0 vCPUs!) and still seeing improvements, although
perhaps not as huge as they could have been. Thoughts?

Here are the patches included in the series. I '*'-ed ones already received one
or more acks during previous rounds. Of course, I retained these Ack-s only for
the patches that have not been touched, or only underwent minor cluenups. Of
course, feel free to re-review everything, whatever your Ack is there or not!

 * [ 1/11] xen, libxc: rename xenctl_cpumap to xenctl_bitmap
 * [ 2/11] xen, libxc: introduce node maps and masks
   [ 3/11] xen: sched_credit: when picking, make sure we get an idle one, if any
   [ 4/11] xen: sched_credit: let the scheduler know about node-affinity
 * [ 5/11] xen: allow for explicitly specifying node-affinity
 * [ 6/11] libxc: allow for explicitly specifying node-affinity
 * [ 7/11] libxl: allow for explicitly specifying node-affinity
   [ 8/11] libxl: optimize the calculation of how many VCPUs can run on a candidate
 * [ 9/11] libxl: automatic placement deals with node-affinity
 * [10/11] xl: add node-affinity to the output of `xl list`
   [11/11] docs: rearrange and update NUMA placement documentation

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 Fri Feb 01 11:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPT-0004Tp-EX; Fri, 01 Feb 2013 11:03:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPR-0004TV-Sw
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:54 +0000
Received: from [85.158.138.51:32863] by server-2.bemta-3.messagelabs.com id
	F8/28-25961-911AB015; Fri, 01 Feb 2013 11:03:53 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359716632!28776483!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27768 invoked from network); 1 Feb 2013 11:03:52 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:52 -0000
Received: by mail-bk0-f45.google.com with SMTP id i18so1774780bkv.32
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=hiCTyqLaWkstY3zW8wndI3r4j8l1RsbQUIe9CjxdLvA=;
	b=DrPbYdtUZXDcmfdPnCGLYAJNSelfKHqFLdSJnYrj9gX6UQew49Hu/S1jWkaXxKbOIg
	iA3iPd2erx4OFmTJafociUmBNFIogkHP8Gv1GuCFKNukONo3wfhZRYbN+UJhMNhSWO0o
	/7P1IUTsUWk+NHeviQQ05hGsHCI8yg/N2W7is9Rxj28IY4ppajA/W8ClL6ekDSyrWr5I
	cUzBmyhhTEGoV+YvFBNAQHACV88AM0Yy3dI/foWf3e0r8GKLdqtLbolRbJVShnC7iqYK
	fpAHX4QXg9y+jF0jDw+7xsHZdFlAHukunELo0Gns/4yjEAN3LW3EIrz78RFe9f45WV42
	tHaA==
X-Received: by 10.204.146.91 with SMTP id g27mr2838400bkv.124.1359716631869;
	Fri, 01 Feb 2013 03:03:51 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.50
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b23b011a72475699c4c8cfd4b52002da35ca622
Message-Id: <7b23b011a72475699c4c.1359716472@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:12 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 02 of 11 v3] xen, libxc: introduce xc_nodemap_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

And its handling functions, following suit from xc_cpumap_t.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
---
Changes from v2:
 * Discriminating between statically allocated nodemask_t and
   dynamically allocated nodemask_var_t is not really necesssary,
   given the maximum number of nodes won't ever grow that much,
   so killed that hunk, as suggested during review.

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
@@ -54,6 +54,11 @@ int xc_get_cpumap_size(xc_interface *xch
     return (xc_get_max_cpus(xch) + 7) / 8;
 }
 
+int xc_get_nodemap_size(xc_interface *xch)
+{
+    return (xc_get_max_nodes(xch) + 7) / 8;
+}
+
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
 {
     int sz;
@@ -64,6 +69,16 @@ xc_cpumap_t xc_cpumap_alloc(xc_interface
     return calloc(1, sz);
 }
 
+xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
+{
+    int sz;
+
+    sz = xc_get_nodemap_size(xch);
+    if (sz == 0)
+        return NULL;
+    return calloc(1, sz);
+}
+
 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,12 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
 /* allocate a cpumap */
 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/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -117,6 +117,20 @@ int xenctl_bitmap_to_cpumask(cpumask_var
     return err;
 }
 
+int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap,
+                              const nodemask_t *nodemask)
+{
+    return bitmap_to_xenctl_bitmap(xenctl_nodemap, cpumask_bits(nodemask),
+                                   MAX_NUMNODES);
+}
+
+int xenctl_bitmap_to_nodemask(nodemask_t *nodemask,
+                              const struct xenctl_bitmap *xenctl_nodemap)
+{
+    return xenctl_bitmap_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 Fri Feb 01 11:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPT-0004Tp-EX; Fri, 01 Feb 2013 11:03:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPR-0004TV-Sw
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:54 +0000
Received: from [85.158.138.51:32863] by server-2.bemta-3.messagelabs.com id
	F8/28-25961-911AB015; Fri, 01 Feb 2013 11:03:53 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359716632!28776483!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27768 invoked from network); 1 Feb 2013 11:03:52 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:52 -0000
Received: by mail-bk0-f45.google.com with SMTP id i18so1774780bkv.32
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=hiCTyqLaWkstY3zW8wndI3r4j8l1RsbQUIe9CjxdLvA=;
	b=DrPbYdtUZXDcmfdPnCGLYAJNSelfKHqFLdSJnYrj9gX6UQew49Hu/S1jWkaXxKbOIg
	iA3iPd2erx4OFmTJafociUmBNFIogkHP8Gv1GuCFKNukONo3wfhZRYbN+UJhMNhSWO0o
	/7P1IUTsUWk+NHeviQQ05hGsHCI8yg/N2W7is9Rxj28IY4ppajA/W8ClL6ekDSyrWr5I
	cUzBmyhhTEGoV+YvFBNAQHACV88AM0Yy3dI/foWf3e0r8GKLdqtLbolRbJVShnC7iqYK
	fpAHX4QXg9y+jF0jDw+7xsHZdFlAHukunELo0Gns/4yjEAN3LW3EIrz78RFe9f45WV42
	tHaA==
X-Received: by 10.204.146.91 with SMTP id g27mr2838400bkv.124.1359716631869;
	Fri, 01 Feb 2013 03:03:51 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.50
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b23b011a72475699c4c8cfd4b52002da35ca622
Message-Id: <7b23b011a72475699c4c.1359716472@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:12 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 02 of 11 v3] xen, libxc: introduce xc_nodemap_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

And its handling functions, following suit from xc_cpumap_t.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
---
Changes from v2:
 * Discriminating between statically allocated nodemask_t and
   dynamically allocated nodemask_var_t is not really necesssary,
   given the maximum number of nodes won't ever grow that much,
   so killed that hunk, as suggested during review.

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
@@ -54,6 +54,11 @@ int xc_get_cpumap_size(xc_interface *xch
     return (xc_get_max_cpus(xch) + 7) / 8;
 }
 
+int xc_get_nodemap_size(xc_interface *xch)
+{
+    return (xc_get_max_nodes(xch) + 7) / 8;
+}
+
 xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
 {
     int sz;
@@ -64,6 +69,16 @@ xc_cpumap_t xc_cpumap_alloc(xc_interface
     return calloc(1, sz);
 }
 
+xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
+{
+    int sz;
+
+    sz = xc_get_nodemap_size(xch);
+    if (sz == 0)
+        return NULL;
+    return calloc(1, sz);
+}
+
 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,12 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
 /* allocate a cpumap */
 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/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -117,6 +117,20 @@ int xenctl_bitmap_to_cpumask(cpumask_var
     return err;
 }
 
+int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap,
+                              const nodemask_t *nodemask)
+{
+    return bitmap_to_xenctl_bitmap(xenctl_nodemap, cpumask_bits(nodemask),
+                                   MAX_NUMNODES);
+}
+
+int xenctl_bitmap_to_nodemask(nodemask_t *nodemask,
+                              const struct xenctl_bitmap *xenctl_nodemap)
+{
+    return xenctl_bitmap_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 Fri Feb 01 11:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPW-0004UW-24; Fri, 01 Feb 2013 11:03: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 1U1EPU-0004Tt-2R
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:56 +0000
Received: from [85.158.143.35:5643] by server-1.bemta-4.messagelabs.com id
	3F/AC-08839-B11AB015; Fri, 01 Feb 2013 11:03:55 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1359716633!5219021!1
X-Originating-IP: [209.85.214.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21638 invoked from network); 1 Feb 2013 11:03:54 -0000
Received: from mail-bk0-f50.google.com (HELO mail-bk0-f50.google.com)
	(209.85.214.50)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:54 -0000
Received: by mail-bk0-f50.google.com with SMTP id jg9so1767168bkc.9
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=QiysZrp1bxJPf7jyEx5+tna9Xa1HM0PxulXDOButMu0=;
	b=pzKx/XTVHMrfgZRyA+npAlLl5AuSSZmqovRqEe6RrtGESaOWvT/OVS3IxPINNbX5eT
	mC7AFFsK6tL2UGs8CvJqwRDKZeAsUtE6FHHPwrd+o1zfTuYuFUYixVxfs6S1yJ8eGsyg
	GsMbXDDeePMlGkNs8S88zyCBwK2sHaB/n+g19mfRpdy0cM4aiNuHUrybw7SEgxavhGs2
	r+x2lxiET0DAwM1kGWOgWxZeIjO7EIx6CyU11IPhquwFNJOG972w3ondPSOyT9URE6wq
	2AUbfJ2GNQrCcK9exviLILAUQ7x4q27jA5jPFijMsdPOH1nXD8iWHcvQ+eFDSRzvwvt8
	Vwdw==
X-Received: by 10.204.145.195 with SMTP id e3mr3287788bkv.27.1359716633627;
	Fri, 01 Feb 2013 03:03:53 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.51
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 45d2f5dc459ce84ca7eef529e12f322dac06aa90
Message-Id: <45d2f5dc459ce84ca7ee.1359716473@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:13 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 03 of 11 v3] xen: sched_credit: when picking,
 make sure we get an idle one, if any
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 pcpu picking algorithm treats two threads of a SMT core the same.
More specifically, if one is idle and the other one is busy, they both
will be assigned a weight of 1. Therefore, when picking begins, if the
first target pcpu is the busy thread (and if there are no other idle
pcpu than its sibling), that will never change.

This change fixes this by ensuring that, before entering the core of
the picking algorithm, the target pcpu is an idle one (if there is an
idle pcpu at all, of course).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -526,6 +526,18 @@ static int
     if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
         cpumask_set_cpu(cpu, &idlers);
     cpumask_and(&cpus, &cpus, &idlers);
+
+    /*
+     * It is important that cpu points to an idle processor, if a suitable
+     * one exists (and we can use cpus to check and, possibly, choose a new
+     * CPU, as we just &&-ed it with idlers). In fact, if we are on SMT, and
+     * cpu points to a busy thread with an idle sibling, both the threads
+     * will be considered the same, from the "idleness" calculation point
+     * of view", preventing vcpu from being moved to the thread that is
+     * actually idle.
+     */
+    if ( !cpumask_empty(&cpus) && !cpumask_test_cpu(cpu, &cpus) )
+        cpu = cpumask_cycle(cpu, &cpus);
     cpumask_clear_cpu(cpu, &cpus);
 
     while ( !cpumask_empty(&cpus) )

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPW-0004UW-24; Fri, 01 Feb 2013 11:03: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 1U1EPU-0004Tt-2R
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:56 +0000
Received: from [85.158.143.35:5643] by server-1.bemta-4.messagelabs.com id
	3F/AC-08839-B11AB015; Fri, 01 Feb 2013 11:03:55 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1359716633!5219021!1
X-Originating-IP: [209.85.214.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21638 invoked from network); 1 Feb 2013 11:03:54 -0000
Received: from mail-bk0-f50.google.com (HELO mail-bk0-f50.google.com)
	(209.85.214.50)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:54 -0000
Received: by mail-bk0-f50.google.com with SMTP id jg9so1767168bkc.9
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=QiysZrp1bxJPf7jyEx5+tna9Xa1HM0PxulXDOButMu0=;
	b=pzKx/XTVHMrfgZRyA+npAlLl5AuSSZmqovRqEe6RrtGESaOWvT/OVS3IxPINNbX5eT
	mC7AFFsK6tL2UGs8CvJqwRDKZeAsUtE6FHHPwrd+o1zfTuYuFUYixVxfs6S1yJ8eGsyg
	GsMbXDDeePMlGkNs8S88zyCBwK2sHaB/n+g19mfRpdy0cM4aiNuHUrybw7SEgxavhGs2
	r+x2lxiET0DAwM1kGWOgWxZeIjO7EIx6CyU11IPhquwFNJOG972w3ondPSOyT9URE6wq
	2AUbfJ2GNQrCcK9exviLILAUQ7x4q27jA5jPFijMsdPOH1nXD8iWHcvQ+eFDSRzvwvt8
	Vwdw==
X-Received: by 10.204.145.195 with SMTP id e3mr3287788bkv.27.1359716633627;
	Fri, 01 Feb 2013 03:03:53 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.51
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 45d2f5dc459ce84ca7eef529e12f322dac06aa90
Message-Id: <45d2f5dc459ce84ca7ee.1359716473@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:13 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 03 of 11 v3] xen: sched_credit: when picking,
 make sure we get an idle one, if any
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 pcpu picking algorithm treats two threads of a SMT core the same.
More specifically, if one is idle and the other one is busy, they both
will be assigned a weight of 1. Therefore, when picking begins, if the
first target pcpu is the busy thread (and if there are no other idle
pcpu than its sibling), that will never change.

This change fixes this by ensuring that, before entering the core of
the picking algorithm, the target pcpu is an idle one (if there is an
idle pcpu at all, of course).

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

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
@@ -526,6 +526,18 @@ static int
     if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
         cpumask_set_cpu(cpu, &idlers);
     cpumask_and(&cpus, &cpus, &idlers);
+
+    /*
+     * It is important that cpu points to an idle processor, if a suitable
+     * one exists (and we can use cpus to check and, possibly, choose a new
+     * CPU, as we just &&-ed it with idlers). In fact, if we are on SMT, and
+     * cpu points to a busy thread with an idle sibling, both the threads
+     * will be considered the same, from the "idleness" calculation point
+     * of view", preventing vcpu from being moved to the thread that is
+     * actually idle.
+     */
+    if ( !cpumask_empty(&cpus) && !cpumask_test_cpu(cpu, &cpus) )
+        cpu = cpumask_cycle(cpu, &cpus);
     cpumask_clear_cpu(cpu, &cpus);
 
     while ( !cpumask_empty(&cpus) )

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPT-0004Ti-1b; Fri, 01 Feb 2013 11:03:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPR-0004TT-HO
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:53 +0000
Received: from [193.109.254.147:18737] by server-16.bemta-14.messagelabs.com
	id D7/57-25906-811AB015; Fri, 01 Feb 2013 11:03:52 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359716631!9748469!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6441 invoked from network); 1 Feb 2013 11:03:51 -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;
	1 Feb 2013 11:03:51 -0000
Received: by mail-bk0-f43.google.com with SMTP id jm19so1762552bkc.16
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=R/0SHFkWhd75ENA5Ba17aTeyV48eekImljCPBaXEK0I=;
	b=yjCvrFYgpf7B2tq3bFbQtjEBDvcEN+yBAQR8FcXpK22x27agSxfocAxbexb1HsetH/
	8ybf/rE78ryzTQ0f75s7KhssMr2lQICZiYZECJb9x8ww3DGxthv9C8xHQmHDnPexYPLb
	ugt6Y4SAXlE+rQftglvgVFEKcxr9iwJgrcI3E8AGj1eSib982ZfI1hhmp07wFFX6N4F7
	kiQuM3pVjipm52VgEdGSFf5Q6566KPf2iUEfEycYN64ulT43Q5BI5NO9kn1iLbRWYsvG
	GBfDfpBs6FnBHaYb+USaRDkJCwcr6H+x4F04W+EaLiZBtuyvs+iafHJw7noK1e1qjgqu
	4qOw==
X-Received: by 10.204.9.21 with SMTP id j21mr3186371bkj.32.1359716630173;
	Fri, 01 Feb 2013 03:03:50 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.48
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d90e489ae2382cc9d5996471d86e10166130edd2
Message-Id: <d90e489ae2382cc9d599.1359716471@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:11 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 01 of 11 v3] xen,
	libxc: rename xenctl_cpumap to xenctl_bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

More specifically:
 1. replaces xenctl_cpumap with xenctl_bitmap
 2. provides bitmap_to_xenctl_bitmap and the reverse;
 3. re-implement cpumask_to_xenctl_bitmap with
    bitmap_to_xenctl_bitmap and the reverse;

Other than #3, no functional changes. Interface only slightly
afected.

This is in preparation of introducing NUMA node-affinity maps.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
---
Changes since v2:
 * Took care of tools/tests/mce-test/tools/xen-mceinj.c which
   hass been forgotten there, as requested during review.

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/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
@@ -161,7 +161,7 @@ static int inject_cmci(xc_interface *xc_
 
     mc.u.mc_inject_v2.flags |= XEN_MC_INJECT_CPU_BROADCAST;
     mc.u.mc_inject_v2.flags |= XEN_MC_INJECT_TYPE_CMCI;
-    mc.u.mc_inject_v2.cpumap.nr_cpus = nr_cpus;
+    mc.u.mc_inject_v2.cpumap.nr_elems = nr_cpus;
 
     return xc_mca_op(xc_handle, &mc);
 }
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1454,8 +1454,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
             cpumap = &cpu_online_map;
         else
         {
-            ret = xenctl_cpumap_to_cpumask(&cmv,
-                                           &op->u.mc_inject_v2.cpumap);
+            ret = xenctl_bitmap_to_cpumask(&cmv, &op->u.mc_inject_v2.cpumap);
             if ( ret )
                 break;
             cpumap = cmv;
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
@@ -336,7 +336,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
     {
         uint32_t cpu;
         uint64_t idletime, now = NOW();
-        struct xenctl_cpumap ctlmap;
+        struct xenctl_bitmap ctlmap;
         cpumask_var_t cpumap;
         XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
         XEN_GUEST_HANDLE(uint64) idletimes;
@@ -345,11 +345,11 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
         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 */
-        if ( (ret = xenctl_cpumap_to_cpumask(&cpumap, &ctlmap)) != 0 )
+        if ( (ret = xenctl_bitmap_to_cpumask(&cpumap, &ctlmap)) != 0 )
             goto out;
         guest_from_compat_handle(idletimes, op->u.getidletime.idletime);
 
@@ -368,7 +368,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
 
         op->u.getidletime.now = now;
         if ( ret == 0 )
-            ret = cpumask_to_xenctl_cpumap(&ctlmap, cpumap);
+            ret = cpumask_to_xenctl_bitmap(&ctlmap, cpumap);
         free_cpumask_var(cpumap);
 
         if ( ret == 0 && __copy_field_to_guest(u_xenpf_op, op, u.getidletime) )
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -493,7 +493,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
         op->cpupool_id = c->cpupool_id;
         op->sched_id = c->sched->sched_id;
         op->n_dom = c->n_dom;
-        ret = cpumask_to_xenctl_cpumap(&op->cpumap, c->cpu_valid);
+        ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
         cpupool_put(c);
     }
     break;
@@ -588,7 +588,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
 
     case XEN_SYSCTL_CPUPOOL_OP_FREEINFO:
     {
-        ret = cpumask_to_xenctl_cpumap(
+        ret = cpumask_to_xenctl_bitmap(
             &op->cpumap, &cpupool_free_cpus);
     }
     break;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -32,28 +32,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_bitmap(struct xenctl_bitmap *xenctl_bitmap,
+                            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_bitmap->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_bitmap->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_bitmap->bitmap, i, &zero, 1) )
             err = -EFAULT;
 
     xfree(bytemap);
@@ -61,36 +62,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_bitmap_to_bitmap(unsigned long *bitmap,
+                            const struct xenctl_bitmap *xenctl_bitmap,
+                            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_bitmap->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_bitmap->bitmap, copy_bytes) )
             err = -EFAULT;
-        if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes == copy_bytes) )
-            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7));
+        if ( (xenctl_bitmap->nr_elems & 7) && (guest_bytes == copy_bytes) )
+            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_bitmap->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_bitmap(struct xenctl_bitmap *xenctl_cpumap,
+                             const cpumask_t *cpumask)
+{
+    return bitmap_to_xenctl_bitmap(xenctl_cpumap, cpumask_bits(cpumask),
+                                   nr_cpu_ids);
+}
+
+int xenctl_bitmap_to_cpumask(cpumask_var_t *cpumask,
+                             const struct xenctl_bitmap *xenctl_cpumap)
+{
+    int err = 0;
+
+    if ( alloc_cpumask_var(cpumask) ) {
+        err = xenctl_bitmap_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;
 }
 
@@ -539,7 +562,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
         {
             cpumask_var_t new_affinity;
 
-            ret = xenctl_cpumap_to_cpumask(
+            ret = xenctl_bitmap_to_cpumask(
                 &new_affinity, &op->u.vcpuaffinity.cpumap);
             if ( !ret )
             {
@@ -549,7 +572,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
         }
         else
         {
-            ret = cpumask_to_xenctl_cpumap(
+            ret = cpumask_to_xenctl_bitmap(
                 &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
         }
     }
diff --git a/xen/common/trace.c b/xen/common/trace.c
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -384,7 +384,7 @@ int tb_control(xen_sysctl_tbuf_op_t *tbc
     {
         cpumask_var_t mask;
 
-        rc = xenctl_cpumap_to_cpumask(&mask, &tbc->cpu_mask);
+        rc = xenctl_bitmap_to_cpumask(&mask, &tbc->cpu_mask);
         if ( !rc )
         {
             cpumask_copy(&tb_cpu_mask, mask);
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_bitmap 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
@@ -284,7 +284,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_bitmap 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,7 +71,7 @@ struct xen_sysctl_tbuf_op {
 #define XEN_SYSCTL_TBUFOP_disable      5
     uint32_t cmd;
     /* IN/OUT variables */
-    struct xenctl_cpumap cpu_mask;
+    struct xenctl_bitmap cpu_mask;
     uint32_t             evt_mask;
     /* OUT variables */
     uint64_aligned_t buffer_mfn;
@@ -532,7 +532,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_bitmap 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
@@ -851,9 +851,9 @@ typedef uint8_t xen_domain_handle_t[16];
 #endif
 
 #ifndef __ASSEMBLY__
-struct xenctl_cpumap {
+struct xenctl_bitmap {
     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_bitmap;
+int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
+int xenctl_bitmap_to_cpumask(cpumask_var_t *, const struct xenctl_bitmap *);
 
 #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_bitmap			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 Fri Feb 01 11:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPT-0004Ti-1b; Fri, 01 Feb 2013 11:03:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPR-0004TT-HO
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:03:53 +0000
Received: from [193.109.254.147:18737] by server-16.bemta-14.messagelabs.com
	id D7/57-25906-811AB015; Fri, 01 Feb 2013 11:03:52 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359716631!9748469!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6441 invoked from network); 1 Feb 2013 11:03:51 -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;
	1 Feb 2013 11:03:51 -0000
Received: by mail-bk0-f43.google.com with SMTP id jm19so1762552bkc.16
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=R/0SHFkWhd75ENA5Ba17aTeyV48eekImljCPBaXEK0I=;
	b=yjCvrFYgpf7B2tq3bFbQtjEBDvcEN+yBAQR8FcXpK22x27agSxfocAxbexb1HsetH/
	8ybf/rE78ryzTQ0f75s7KhssMr2lQICZiYZECJb9x8ww3DGxthv9C8xHQmHDnPexYPLb
	ugt6Y4SAXlE+rQftglvgVFEKcxr9iwJgrcI3E8AGj1eSib982ZfI1hhmp07wFFX6N4F7
	kiQuM3pVjipm52VgEdGSFf5Q6566KPf2iUEfEycYN64ulT43Q5BI5NO9kn1iLbRWYsvG
	GBfDfpBs6FnBHaYb+USaRDkJCwcr6H+x4F04W+EaLiZBtuyvs+iafHJw7noK1e1qjgqu
	4qOw==
X-Received: by 10.204.9.21 with SMTP id j21mr3186371bkj.32.1359716630173;
	Fri, 01 Feb 2013 03:03:50 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.48
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d90e489ae2382cc9d5996471d86e10166130edd2
Message-Id: <d90e489ae2382cc9d599.1359716471@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:11 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 01 of 11 v3] xen,
	libxc: rename xenctl_cpumap to xenctl_bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

More specifically:
 1. replaces xenctl_cpumap with xenctl_bitmap
 2. provides bitmap_to_xenctl_bitmap and the reverse;
 3. re-implement cpumask_to_xenctl_bitmap with
    bitmap_to_xenctl_bitmap and the reverse;

Other than #3, no functional changes. Interface only slightly
afected.

This is in preparation of introducing NUMA node-affinity maps.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
---
Changes since v2:
 * Took care of tools/tests/mce-test/tools/xen-mceinj.c which
   hass been forgotten there, as requested during review.

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/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
@@ -161,7 +161,7 @@ static int inject_cmci(xc_interface *xc_
 
     mc.u.mc_inject_v2.flags |= XEN_MC_INJECT_CPU_BROADCAST;
     mc.u.mc_inject_v2.flags |= XEN_MC_INJECT_TYPE_CMCI;
-    mc.u.mc_inject_v2.cpumap.nr_cpus = nr_cpus;
+    mc.u.mc_inject_v2.cpumap.nr_elems = nr_cpus;
 
     return xc_mca_op(xc_handle, &mc);
 }
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1454,8 +1454,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
             cpumap = &cpu_online_map;
         else
         {
-            ret = xenctl_cpumap_to_cpumask(&cmv,
-                                           &op->u.mc_inject_v2.cpumap);
+            ret = xenctl_bitmap_to_cpumask(&cmv, &op->u.mc_inject_v2.cpumap);
             if ( ret )
                 break;
             cpumap = cmv;
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
@@ -336,7 +336,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
     {
         uint32_t cpu;
         uint64_t idletime, now = NOW();
-        struct xenctl_cpumap ctlmap;
+        struct xenctl_bitmap ctlmap;
         cpumask_var_t cpumap;
         XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
         XEN_GUEST_HANDLE(uint64) idletimes;
@@ -345,11 +345,11 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
         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 */
-        if ( (ret = xenctl_cpumap_to_cpumask(&cpumap, &ctlmap)) != 0 )
+        if ( (ret = xenctl_bitmap_to_cpumask(&cpumap, &ctlmap)) != 0 )
             goto out;
         guest_from_compat_handle(idletimes, op->u.getidletime.idletime);
 
@@ -368,7 +368,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PA
 
         op->u.getidletime.now = now;
         if ( ret == 0 )
-            ret = cpumask_to_xenctl_cpumap(&ctlmap, cpumap);
+            ret = cpumask_to_xenctl_bitmap(&ctlmap, cpumap);
         free_cpumask_var(cpumap);
 
         if ( ret == 0 && __copy_field_to_guest(u_xenpf_op, op, u.getidletime) )
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -493,7 +493,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
         op->cpupool_id = c->cpupool_id;
         op->sched_id = c->sched->sched_id;
         op->n_dom = c->n_dom;
-        ret = cpumask_to_xenctl_cpumap(&op->cpumap, c->cpu_valid);
+        ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
         cpupool_put(c);
     }
     break;
@@ -588,7 +588,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
 
     case XEN_SYSCTL_CPUPOOL_OP_FREEINFO:
     {
-        ret = cpumask_to_xenctl_cpumap(
+        ret = cpumask_to_xenctl_bitmap(
             &op->cpumap, &cpupool_free_cpus);
     }
     break;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -32,28 +32,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_bitmap(struct xenctl_bitmap *xenctl_bitmap,
+                            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_bitmap->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_bitmap->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_bitmap->bitmap, i, &zero, 1) )
             err = -EFAULT;
 
     xfree(bytemap);
@@ -61,36 +62,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_bitmap_to_bitmap(unsigned long *bitmap,
+                            const struct xenctl_bitmap *xenctl_bitmap,
+                            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_bitmap->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_bitmap->bitmap, copy_bytes) )
             err = -EFAULT;
-        if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes == copy_bytes) )
-            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7));
+        if ( (xenctl_bitmap->nr_elems & 7) && (guest_bytes == copy_bytes) )
+            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_bitmap->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_bitmap(struct xenctl_bitmap *xenctl_cpumap,
+                             const cpumask_t *cpumask)
+{
+    return bitmap_to_xenctl_bitmap(xenctl_cpumap, cpumask_bits(cpumask),
+                                   nr_cpu_ids);
+}
+
+int xenctl_bitmap_to_cpumask(cpumask_var_t *cpumask,
+                             const struct xenctl_bitmap *xenctl_cpumap)
+{
+    int err = 0;
+
+    if ( alloc_cpumask_var(cpumask) ) {
+        err = xenctl_bitmap_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;
 }
 
@@ -539,7 +562,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
         {
             cpumask_var_t new_affinity;
 
-            ret = xenctl_cpumap_to_cpumask(
+            ret = xenctl_bitmap_to_cpumask(
                 &new_affinity, &op->u.vcpuaffinity.cpumap);
             if ( !ret )
             {
@@ -549,7 +572,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
         }
         else
         {
-            ret = cpumask_to_xenctl_cpumap(
+            ret = cpumask_to_xenctl_bitmap(
                 &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
         }
     }
diff --git a/xen/common/trace.c b/xen/common/trace.c
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -384,7 +384,7 @@ int tb_control(xen_sysctl_tbuf_op_t *tbc
     {
         cpumask_var_t mask;
 
-        rc = xenctl_cpumap_to_cpumask(&mask, &tbc->cpu_mask);
+        rc = xenctl_bitmap_to_cpumask(&mask, &tbc->cpu_mask);
         if ( !rc )
         {
             cpumask_copy(&tb_cpu_mask, mask);
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_bitmap 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
@@ -284,7 +284,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_bitmap 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,7 +71,7 @@ struct xen_sysctl_tbuf_op {
 #define XEN_SYSCTL_TBUFOP_disable      5
     uint32_t cmd;
     /* IN/OUT variables */
-    struct xenctl_cpumap cpu_mask;
+    struct xenctl_bitmap cpu_mask;
     uint32_t             evt_mask;
     /* OUT variables */
     uint64_aligned_t buffer_mfn;
@@ -532,7 +532,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_bitmap 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
@@ -851,9 +851,9 @@ typedef uint8_t xen_domain_handle_t[16];
 #endif
 
 #ifndef __ASSEMBLY__
-struct xenctl_cpumap {
+struct xenctl_bitmap {
     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_bitmap;
+int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
+int xenctl_bitmap_to_cpumask(cpumask_var_t *, const struct xenctl_bitmap *);
 
 #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_bitmap			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 Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPb-0004Vz-Gh; Fri, 01 Feb 2013 11:04:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPY-0004V4-Mq
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:01 +0000
Received: from [85.158.138.51:37266] by server-14.bemta-3.messagelabs.com id
	FC/F6-23533-F11AB015; Fri, 01 Feb 2013 11:03:59 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1359716638!21687788!1
X-Originating-IP: [209.85.214.53]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8802 invoked from network); 1 Feb 2013 11:03:58 -0000
Received: from mail-bk0-f53.google.com (HELO mail-bk0-f53.google.com)
	(209.85.214.53)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:58 -0000
Received: by mail-bk0-f53.google.com with SMTP id j10so1800198bkw.12
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=KxoFKHG21wAo9YNjuaU1i1COGnhQsKS4ov+1qzz+hOk=;
	b=hqQrpmpAFTZ+uHzxVYALAZ9FBHRqATaUrbdimSHLYUViH1f5AAUVluc7lyzy86d5Or
	I4kSQLOZF3vb1ot22imIqQwTHHFUibwDa9weLR/gpK5Cj3Bk3hr4w3Xswr7tDPO3Z0BN
	LIpKvph/fGWNh0dzPvHM0UNlzwt10MQgbK40tP7cbntRElxjCpaFDKM1rWlqYmPFITou
	mEKXjfPMQj/Q0FeeQRZr0QNGKq66iAp0aEEX1tzXLDyI9B/CJqK1J+3g8VfXhbAjkR5W
	WrpgtFKo/MNSRHn1VEtS2LJZwkHh1F9L8l9aPltRKMC7DqZC58ovYTQt6mbnn6J7a4oc
	wWAQ==
X-Received: by 10.204.147.145 with SMTP id l17mr3227283bkv.100.1359716637952; 
	Fri, 01 Feb 2013 03:03:57 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.56
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7ad5cdfea9c033b89415e0c15084de414a1d6f5f
Message-Id: <7ad5cdfea9c033b89415.1359716475@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:15 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 05 of 11 v3] xen: allow for explicitly
	specifying 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

Make it possible to pass the node-affinity of a domain to the hypervisor
from the upper layers, instead of always being computed automatically.

Note that this also required generalizing the Flask hooks for setting
and getting the affinity, so that they now deal with both vcpu and
node affinity.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
Changes from v2:
 * reworked as needed after the merge of Daniel's IS_PRIV work;
 * xen.te taken care of, as requested during review.

Changes from v1:
 * added the missing dummy hook for nodeaffinity;
 * let the permission renaming affect flask policies too.

diff --git a/tools/flask/policy/policy/mls b/tools/flask/policy/policy/mls
--- a/tools/flask/policy/policy/mls
+++ b/tools/flask/policy/policy/mls
@@ -70,11 +70,11 @@ mlsconstrain domain transition
 	(( h1 dom h2 ) and (( l1 eq l2 ) or (t1 == mls_priv)));
 
 # all the domain "read" ops
-mlsconstrain domain { getvcpuaffinity getdomaininfo getvcpuinfo getvcpucontext getaddrsize getextvcpucontext }
+mlsconstrain domain { getaffinity getdomaininfo getvcpuinfo getvcpucontext getaddrsize getextvcpucontext }
 	((l1 dom l2) or (t1 == mls_priv));
 
 # all the domain "write" ops
-mlsconstrain domain { setvcpucontext pause unpause resume create max_vcpus destroy setvcpuaffinity scheduler setdomainmaxmem setdomainhandle setdebugging hypercall settime set_target shutdown setaddrsize trigger setextvcpucontext }
+mlsconstrain domain { setvcpucontext pause unpause resume create max_vcpus destroy setaffinity scheduler setdomainmaxmem setdomainhandle setdebugging hypercall settime set_target shutdown setaddrsize trigger setextvcpucontext }
 	((l1 eq l2) or (t1 == mls_priv));
 
 # This is incomplete - similar constraints must be written for all classes
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -48,7 +48,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity setvcpuaffinity };
+			getaffinity setaffinity };
 	allow $1 $2:domain2 { set_cpuid settsc setscheduler };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
@@ -77,9 +77,9 @@ define(`create_domain_build_label', `
 # manage_domain(priv, target)
 #   Allow managing a running domain
 define(`manage_domain', `
-	allow $1 $2:domain { getdomaininfo getvcpuinfo getvcpuaffinity
+	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
 			getaddrsize pause unpause trigger shutdown destroy
-			setvcpuaffinity setdomainmaxmem getscheduler };
+			setaffinity setdomainmaxmem getscheduler };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -62,7 +62,7 @@ allow dom0_t security_t:security { check
 	compute_member load_policy compute_relabel compute_user setenforce
 	setbool setsecparam add_ocontext del_ocontext };
 
-allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
+allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getaffinity };
 allow dom0_t dom0_t:resource { add remove };
 
 admin_device(dom0_t, device_t)
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->auto_node_affinity = 1;
 
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
@@ -362,11 +363,26 @@ void domain_update_node_affinity(struct 
         cpumask_or(cpumask, cpumask, online_affinity);
     }
 
-    for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
-            node_set(node, nodemask);
+    if ( d->auto_node_affinity )
+    {
+        /* Node-affinity is automaically computed from all vcpu-affinities */
+        for_each_online_node ( node )
+            if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
+                node_set(node, nodemask);
 
-    d->node_affinity = nodemask;
+        d->node_affinity = nodemask;
+    }
+    else
+    {
+        /* Node-affinity is provided by someone else, just filter out cpus
+         * that are either offline or not in the affinity of any vcpus. */
+        for_each_node_mask ( node, d->node_affinity )
+            if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) )
+                node_clear(node, d->node_affinity);
+    }
+
+    sched_set_node_affinity(d, &d->node_affinity);
+
     spin_unlock(&d->node_affinity_lock);
 
     free_cpumask_var(online_affinity);
@@ -374,6 +390,36 @@ void domain_update_node_affinity(struct 
 }
 
 
+int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
+{
+    /* Being affine with no nodes is just wrong */
+    if ( nodes_empty(*affinity) )
+        return -EINVAL;
+
+    spin_lock(&d->node_affinity_lock);
+
+    /*
+     * Being/becoming explicitly affine to all nodes is not particularly
+     * useful. Let's take it as the `reset node affinity` command.
+     */
+    if ( nodes_full(*affinity) )
+    {
+        d->auto_node_affinity = 1;
+        goto out;
+    }
+
+    d->auto_node_affinity = 0;
+    d->node_affinity = *affinity;
+
+out:
+    spin_unlock(&d->node_affinity_lock);
+
+    domain_update_node_affinity(d);
+
+    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
@@ -559,6 +559,26 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
     }
     break;
 
+    case XEN_DOMCTL_setnodeaffinity:
+    case XEN_DOMCTL_getnodeaffinity:
+    {
+        if ( op->cmd == XEN_DOMCTL_setnodeaffinity )
+        {
+            nodemask_t new_affinity;
+
+            ret = xenctl_bitmap_to_nodemask(&new_affinity,
+                                            &op->u.nodeaffinity.nodemap);
+            if ( !ret )
+                ret = domain_set_node_affinity(d, &new_affinity);
+        }
+        else
+        {
+            ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap,
+                                            &d->node_affinity);
+        }
+    }
+    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/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -259,17 +259,46 @@ static inline void
     list_del_init(&svc->runq_elem);
 }
 
+/*
+ * Translates node-affinity mask into a cpumask, so that we can use it during
+ * actual scheduling. That of course will contain all the cpus from all the
+ * set nodes in the original node-affinity mask.
+ *
+ * Note that any serialization needed to access mask safely is complete
+ * responsibility of the caller of this function/hook.
+ */
+static void csched_set_node_affinity(
+    const struct scheduler *ops,
+    struct domain *d,
+    nodemask_t *mask)
+{
+    struct csched_dom *sdom;
+    int node;
+
+    /* Skip idle domain since it doesn't even have a node_affinity_cpumask */
+    if ( unlikely(is_idle_domain(d)) )
+        return;
+
+    sdom = CSCHED_DOM(d);
+    cpumask_clear(sdom->node_affinity_cpumask);
+    for_each_node_mask( node, *mask )
+        cpumask_or(sdom->node_affinity_cpumask, sdom->node_affinity_cpumask,
+                   &node_to_cpumask(node));
+}
+
 #define for_each_csched_balance_step(step) \
     for ( (step) = 0; (step) <= CSCHED_BALANCE_CPU_AFFINITY; (step)++ )
 
 
 /*
  * vcpu-affinity balancing is always necessary and must never be skipped.
- * OTOH, if a domain has affinity with all the nodes, we can tell the caller
- * that he can safely skip the node-affinity balancing step.
+ * OTOH, if a domain's node-affinity is automatically computed (or if the
+ * domain has affinity with all the nodes, we can tell the caller that he
+ * can safely skip the node-affinity balancing step.
  */
 #define __vcpu_has_valuable_node_affinity(vc) \
-    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
+    ( !(cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) \
+        || vc->domain->auto_node_affinity == 1) )
 
 static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
 {
@@ -1889,6 +1918,8 @@ const struct scheduler sched_credit_def 
     .adjust         = csched_dom_cntl,
     .adjust_global  = csched_sys_cntl,
 
+    .set_node_affinity  = csched_set_node_affinity,
+
     .pick_cpu       = csched_cpu_pick,
     .do_schedule    = csched_schedule,
 
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -590,6 +590,11 @@ int cpu_disable_scheduler(unsigned int c
     return ret;
 }
 
+void sched_set_node_affinity(struct domain *d, nodemask_t *mask)
+{
+    SCHED_OP(DOM2OP(d), set_node_affinity, d, mask);
+}
+
 int vcpu_set_affinity(struct vcpu *v, const cpumask_t *affinity)
 {
     cpumask_t online_affinity;
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
@@ -279,6 +279,16 @@ typedef struct xen_domctl_getvcpuinfo xe
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
 
 
+/* Get/set the NUMA node(s) with which the guest has affinity with. */
+/* XEN_DOMCTL_setnodeaffinity */
+/* XEN_DOMCTL_getnodeaffinity */
+struct xen_domctl_nodeaffinity {
+    struct xenctl_bitmap nodemap;/* IN */
+};
+typedef struct xen_domctl_nodeaffinity xen_domctl_nodeaffinity_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_nodeaffinity_t);
+
+
 /* Get/set which physical cpus a vcpu can execute on. */
 /* XEN_DOMCTL_setvcpuaffinity */
 /* XEN_DOMCTL_getvcpuaffinity */
@@ -907,6 +917,8 @@ struct xen_domctl {
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_set_broken_page_p2m           67
+#define XEN_DOMCTL_setnodeaffinity               68
+#define XEN_DOMCTL_getnodeaffinity               69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -920,6 +932,7 @@ struct xen_domctl {
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
         struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
         struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
+        struct xen_domctl_nodeaffinity      nodeaffinity;
         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:
  *
@@ -50,6 +51,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
@@ -292,6 +294,14 @@ static inline int __cycle_node(int n, co
 
 #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-if.h b/xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h
+++ b/xen/include/xen/sched-if.h
@@ -184,6 +184,8 @@ struct scheduler {
                                     struct xen_domctl_scheduler_op *);
     int          (*adjust_global)  (const struct scheduler *,
                                     struct xen_sysctl_scheduler_op *);
+    void         (*set_node_affinity) (const struct scheduler *,
+                                       struct domain *, nodemask_t *);
     void         (*dump_settings)  (const struct scheduler *);
     void         (*dump_cpu_state) (const struct scheduler *, int);
 
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
@@ -359,8 +359,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 auto_node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
 };
@@ -429,6 +433,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(
@@ -549,6 +554,7 @@ void sched_destroy_domain(struct domain 
 int sched_move_domain(struct domain *d, struct cpupool *c);
 long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
 long sched_adjust_global(struct xen_sysctl_scheduler_op *);
+void sched_set_node_affinity(struct domain *, nodemask_t *);
 int  sched_id(void);
 void sched_tick_suspend(void);
 void sched_tick_resume(void);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -611,10 +611,10 @@ static int flask_domctl(struct domain *d
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 
     case XEN_DOMCTL_setvcpuaffinity:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETAFFINITY);
 
     case XEN_DOMCTL_getvcpuaffinity:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETAFFINITY);
 
     case XEN_DOMCTL_resumedomain:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -103,10 +103,10 @@ class domain
     max_vcpus
 # XEN_DOMCTL_destroydomain
     destroy
-# XEN_DOMCTL_setvcpuaffinity
-    setvcpuaffinity
-# XEN_DOMCTL_getvcpuaffinity
-    getvcpuaffinity
+# XEN_DOMCTL_setaffinity
+    setaffinity
+# XEN_DOMCTL_getaffinity
+    getaffinity
 # XEN_DOMCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_getinfo
     getscheduler
 # XEN_DOMCTL_getdomaininfo, XEN_SYSCTL_getdomaininfolist

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPb-0004Vz-Gh; Fri, 01 Feb 2013 11:04:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPY-0004V4-Mq
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:01 +0000
Received: from [85.158.138.51:37266] by server-14.bemta-3.messagelabs.com id
	FC/F6-23533-F11AB015; Fri, 01 Feb 2013 11:03:59 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1359716638!21687788!1
X-Originating-IP: [209.85.214.53]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8802 invoked from network); 1 Feb 2013 11:03:58 -0000
Received: from mail-bk0-f53.google.com (HELO mail-bk0-f53.google.com)
	(209.85.214.53)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:58 -0000
Received: by mail-bk0-f53.google.com with SMTP id j10so1800198bkw.12
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=KxoFKHG21wAo9YNjuaU1i1COGnhQsKS4ov+1qzz+hOk=;
	b=hqQrpmpAFTZ+uHzxVYALAZ9FBHRqATaUrbdimSHLYUViH1f5AAUVluc7lyzy86d5Or
	I4kSQLOZF3vb1ot22imIqQwTHHFUibwDa9weLR/gpK5Cj3Bk3hr4w3Xswr7tDPO3Z0BN
	LIpKvph/fGWNh0dzPvHM0UNlzwt10MQgbK40tP7cbntRElxjCpaFDKM1rWlqYmPFITou
	mEKXjfPMQj/Q0FeeQRZr0QNGKq66iAp0aEEX1tzXLDyI9B/CJqK1J+3g8VfXhbAjkR5W
	WrpgtFKo/MNSRHn1VEtS2LJZwkHh1F9L8l9aPltRKMC7DqZC58ovYTQt6mbnn6J7a4oc
	wWAQ==
X-Received: by 10.204.147.145 with SMTP id l17mr3227283bkv.100.1359716637952; 
	Fri, 01 Feb 2013 03:03:57 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.56
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7ad5cdfea9c033b89415e0c15084de414a1d6f5f
Message-Id: <7ad5cdfea9c033b89415.1359716475@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:15 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 05 of 11 v3] xen: allow for explicitly
	specifying 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

Make it possible to pass the node-affinity of a domain to the hypervisor
from the upper layers, instead of always being computed automatically.

Note that this also required generalizing the Flask hooks for setting
and getting the affinity, so that they now deal with both vcpu and
node affinity.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
Changes from v2:
 * reworked as needed after the merge of Daniel's IS_PRIV work;
 * xen.te taken care of, as requested during review.

Changes from v1:
 * added the missing dummy hook for nodeaffinity;
 * let the permission renaming affect flask policies too.

diff --git a/tools/flask/policy/policy/mls b/tools/flask/policy/policy/mls
--- a/tools/flask/policy/policy/mls
+++ b/tools/flask/policy/policy/mls
@@ -70,11 +70,11 @@ mlsconstrain domain transition
 	(( h1 dom h2 ) and (( l1 eq l2 ) or (t1 == mls_priv)));
 
 # all the domain "read" ops
-mlsconstrain domain { getvcpuaffinity getdomaininfo getvcpuinfo getvcpucontext getaddrsize getextvcpucontext }
+mlsconstrain domain { getaffinity getdomaininfo getvcpuinfo getvcpucontext getaddrsize getextvcpucontext }
 	((l1 dom l2) or (t1 == mls_priv));
 
 # all the domain "write" ops
-mlsconstrain domain { setvcpucontext pause unpause resume create max_vcpus destroy setvcpuaffinity scheduler setdomainmaxmem setdomainhandle setdebugging hypercall settime set_target shutdown setaddrsize trigger setextvcpucontext }
+mlsconstrain domain { setvcpucontext pause unpause resume create max_vcpus destroy setaffinity scheduler setdomainmaxmem setdomainhandle setdebugging hypercall settime set_target shutdown setaddrsize trigger setextvcpucontext }
 	((l1 eq l2) or (t1 == mls_priv));
 
 # This is incomplete - similar constraints must be written for all classes
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -48,7 +48,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			getscheduler getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity setvcpuaffinity };
+			getaffinity setaffinity };
 	allow $1 $2:domain2 { set_cpuid settsc setscheduler };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
@@ -77,9 +77,9 @@ define(`create_domain_build_label', `
 # manage_domain(priv, target)
 #   Allow managing a running domain
 define(`manage_domain', `
-	allow $1 $2:domain { getdomaininfo getvcpuinfo getvcpuaffinity
+	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
 			getaddrsize pause unpause trigger shutdown destroy
-			setvcpuaffinity setdomainmaxmem getscheduler };
+			setaffinity setdomainmaxmem getscheduler };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -62,7 +62,7 @@ allow dom0_t security_t:security { check
 	compute_member load_policy compute_relabel compute_user setenforce
 	setbool setsecparam add_ocontext del_ocontext };
 
-allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
+allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getaffinity };
 allow dom0_t dom0_t:resource { add remove };
 
 admin_device(dom0_t, device_t)
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->auto_node_affinity = 1;
 
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
@@ -362,11 +363,26 @@ void domain_update_node_affinity(struct 
         cpumask_or(cpumask, cpumask, online_affinity);
     }
 
-    for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
-            node_set(node, nodemask);
+    if ( d->auto_node_affinity )
+    {
+        /* Node-affinity is automaically computed from all vcpu-affinities */
+        for_each_online_node ( node )
+            if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
+                node_set(node, nodemask);
 
-    d->node_affinity = nodemask;
+        d->node_affinity = nodemask;
+    }
+    else
+    {
+        /* Node-affinity is provided by someone else, just filter out cpus
+         * that are either offline or not in the affinity of any vcpus. */
+        for_each_node_mask ( node, d->node_affinity )
+            if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) )
+                node_clear(node, d->node_affinity);
+    }
+
+    sched_set_node_affinity(d, &d->node_affinity);
+
     spin_unlock(&d->node_affinity_lock);
 
     free_cpumask_var(online_affinity);
@@ -374,6 +390,36 @@ void domain_update_node_affinity(struct 
 }
 
 
+int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
+{
+    /* Being affine with no nodes is just wrong */
+    if ( nodes_empty(*affinity) )
+        return -EINVAL;
+
+    spin_lock(&d->node_affinity_lock);
+
+    /*
+     * Being/becoming explicitly affine to all nodes is not particularly
+     * useful. Let's take it as the `reset node affinity` command.
+     */
+    if ( nodes_full(*affinity) )
+    {
+        d->auto_node_affinity = 1;
+        goto out;
+    }
+
+    d->auto_node_affinity = 0;
+    d->node_affinity = *affinity;
+
+out:
+    spin_unlock(&d->node_affinity_lock);
+
+    domain_update_node_affinity(d);
+
+    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
@@ -559,6 +559,26 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
     }
     break;
 
+    case XEN_DOMCTL_setnodeaffinity:
+    case XEN_DOMCTL_getnodeaffinity:
+    {
+        if ( op->cmd == XEN_DOMCTL_setnodeaffinity )
+        {
+            nodemask_t new_affinity;
+
+            ret = xenctl_bitmap_to_nodemask(&new_affinity,
+                                            &op->u.nodeaffinity.nodemap);
+            if ( !ret )
+                ret = domain_set_node_affinity(d, &new_affinity);
+        }
+        else
+        {
+            ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap,
+                                            &d->node_affinity);
+        }
+    }
+    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/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -259,17 +259,46 @@ static inline void
     list_del_init(&svc->runq_elem);
 }
 
+/*
+ * Translates node-affinity mask into a cpumask, so that we can use it during
+ * actual scheduling. That of course will contain all the cpus from all the
+ * set nodes in the original node-affinity mask.
+ *
+ * Note that any serialization needed to access mask safely is complete
+ * responsibility of the caller of this function/hook.
+ */
+static void csched_set_node_affinity(
+    const struct scheduler *ops,
+    struct domain *d,
+    nodemask_t *mask)
+{
+    struct csched_dom *sdom;
+    int node;
+
+    /* Skip idle domain since it doesn't even have a node_affinity_cpumask */
+    if ( unlikely(is_idle_domain(d)) )
+        return;
+
+    sdom = CSCHED_DOM(d);
+    cpumask_clear(sdom->node_affinity_cpumask);
+    for_each_node_mask( node, *mask )
+        cpumask_or(sdom->node_affinity_cpumask, sdom->node_affinity_cpumask,
+                   &node_to_cpumask(node));
+}
+
 #define for_each_csched_balance_step(step) \
     for ( (step) = 0; (step) <= CSCHED_BALANCE_CPU_AFFINITY; (step)++ )
 
 
 /*
  * vcpu-affinity balancing is always necessary and must never be skipped.
- * OTOH, if a domain has affinity with all the nodes, we can tell the caller
- * that he can safely skip the node-affinity balancing step.
+ * OTOH, if a domain's node-affinity is automatically computed (or if the
+ * domain has affinity with all the nodes, we can tell the caller that he
+ * can safely skip the node-affinity balancing step.
  */
 #define __vcpu_has_valuable_node_affinity(vc) \
-    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
+    ( !(cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) \
+        || vc->domain->auto_node_affinity == 1) )
 
 static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
 {
@@ -1889,6 +1918,8 @@ const struct scheduler sched_credit_def 
     .adjust         = csched_dom_cntl,
     .adjust_global  = csched_sys_cntl,
 
+    .set_node_affinity  = csched_set_node_affinity,
+
     .pick_cpu       = csched_cpu_pick,
     .do_schedule    = csched_schedule,
 
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -590,6 +590,11 @@ int cpu_disable_scheduler(unsigned int c
     return ret;
 }
 
+void sched_set_node_affinity(struct domain *d, nodemask_t *mask)
+{
+    SCHED_OP(DOM2OP(d), set_node_affinity, d, mask);
+}
+
 int vcpu_set_affinity(struct vcpu *v, const cpumask_t *affinity)
 {
     cpumask_t online_affinity;
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
@@ -279,6 +279,16 @@ typedef struct xen_domctl_getvcpuinfo xe
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
 
 
+/* Get/set the NUMA node(s) with which the guest has affinity with. */
+/* XEN_DOMCTL_setnodeaffinity */
+/* XEN_DOMCTL_getnodeaffinity */
+struct xen_domctl_nodeaffinity {
+    struct xenctl_bitmap nodemap;/* IN */
+};
+typedef struct xen_domctl_nodeaffinity xen_domctl_nodeaffinity_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_nodeaffinity_t);
+
+
 /* Get/set which physical cpus a vcpu can execute on. */
 /* XEN_DOMCTL_setvcpuaffinity */
 /* XEN_DOMCTL_getvcpuaffinity */
@@ -907,6 +917,8 @@ struct xen_domctl {
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_set_broken_page_p2m           67
+#define XEN_DOMCTL_setnodeaffinity               68
+#define XEN_DOMCTL_getnodeaffinity               69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -920,6 +932,7 @@ struct xen_domctl {
         struct xen_domctl_getpageframeinfo  getpageframeinfo;
         struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
         struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
+        struct xen_domctl_nodeaffinity      nodeaffinity;
         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:
  *
@@ -50,6 +51,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
@@ -292,6 +294,14 @@ static inline int __cycle_node(int n, co
 
 #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-if.h b/xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h
+++ b/xen/include/xen/sched-if.h
@@ -184,6 +184,8 @@ struct scheduler {
                                     struct xen_domctl_scheduler_op *);
     int          (*adjust_global)  (const struct scheduler *,
                                     struct xen_sysctl_scheduler_op *);
+    void         (*set_node_affinity) (const struct scheduler *,
+                                       struct domain *, nodemask_t *);
     void         (*dump_settings)  (const struct scheduler *);
     void         (*dump_cpu_state) (const struct scheduler *, int);
 
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
@@ -359,8 +359,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 auto_node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
 };
@@ -429,6 +433,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(
@@ -549,6 +554,7 @@ void sched_destroy_domain(struct domain 
 int sched_move_domain(struct domain *d, struct cpupool *c);
 long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
 long sched_adjust_global(struct xen_sysctl_scheduler_op *);
+void sched_set_node_affinity(struct domain *, nodemask_t *);
 int  sched_id(void);
 void sched_tick_suspend(void);
 void sched_tick_resume(void);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -611,10 +611,10 @@ static int flask_domctl(struct domain *d
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 
     case XEN_DOMCTL_setvcpuaffinity:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETAFFINITY);
 
     case XEN_DOMCTL_getvcpuaffinity:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETAFFINITY);
 
     case XEN_DOMCTL_resumedomain:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -103,10 +103,10 @@ class domain
     max_vcpus
 # XEN_DOMCTL_destroydomain
     destroy
-# XEN_DOMCTL_setvcpuaffinity
-    setvcpuaffinity
-# XEN_DOMCTL_getvcpuaffinity
-    getvcpuaffinity
+# XEN_DOMCTL_setaffinity
+    setaffinity
+# XEN_DOMCTL_getaffinity
+    getaffinity
 # XEN_DOMCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_getinfo
     getscheduler
 # XEN_DOMCTL_getdomaininfo, XEN_SYSCTL_getdomaininfolist

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPc-0004Wm-HK; Fri, 01 Feb 2013 11:04:04 +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 1U1EPa-0004VY-T1
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:03 +0000
Received: from [85.158.143.99:7611] by server-2.bemta-4.messagelabs.com id
	99/1A-01597-121AB015; Fri, 01 Feb 2013 11:04:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359716640!20803527!1
X-Originating-IP: [209.85.214.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 698 invoked from network); 1 Feb 2013 11:04:01 -0000
Received: from mail-bk0-f42.google.com (HELO mail-bk0-f42.google.com)
	(209.85.214.42)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:01 -0000
Received: by mail-bk0-f42.google.com with SMTP id jk7so1802078bkc.1
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=hnVzGf2t5EPbRF7aJQGx0giMUn6gtXay/S0O8H4g/1E=;
	b=uUxTInxD+BrOxkrKE2r0xmTjs+pt0ddQWkO5qOjcztnuRnKeNRYlq3QFKShjMcjAhJ
	THD0ilYjEJ5v2+vVuARi7EY6R7o1DLL/758y7/xu+L2cek5DrnkTlTWjEUU1R1pAatdj
	yTnYPtnDzmM+LJC4Fj/rjlIOMFl6FvSnlaIdLbl9qhxacV1o1YNF7TvMgRAjWLUWs1WY
	2R1BjUYcLlQdCdDaT9zDhXTY8y91VdXAXYI3yoRXcJPJF7r3YkjQKjd0hAZZU+bOWemO
	QR4+rBZglY6EHlkRaObdGxUe1nFKy50+9r18YQvHg6wl3Bf7EiT093iHyO7Pngr0NNat
	aXuQ==
X-Received: by 10.204.152.71 with SMTP id f7mr3153844bkw.72.1359716639783;
	Fri, 01 Feb 2013 03:03:59 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.58
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e4538bb30679cb37afee61e04a656c2e4e66f285
Message-Id: <e4538bb30679cb37afee.1359716476@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:16 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 06 of 11 v3] libxc: allow for explicitly
 specifying 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

By providing the proper get/set interface and wiring them
to the new domctl-s from the previous commit.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

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,83 @@ int xc_domain_shutdown(xc_interface *xch
 }
 
 
+int xc_domain_node_setaffinity(xc_interface *xch,
+                               uint32_t domid,
+                               xc_nodemap_t nodemap)
+{
+    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 setnodeaffinity domctl hypercall");
+        goto out;
+    }
+
+    domctl.cmd = XEN_DOMCTL_setnodeaffinity;
+    domctl.domain = (domid_t)domid;
+
+    memcpy(local, nodemap, nodesize);
+    set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local);
+    domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8;
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_buffer_free(xch, local);
+
+ out:
+    return ret;
+}
+
+int xc_domain_node_getaffinity(xc_interface *xch,
+                               uint32_t domid,
+                               xc_nodemap_t nodemap)
+{
+    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 getnodeaffinity domctl hypercall");
+        goto out;
+    }
+
+    domctl.cmd = XEN_DOMCTL_getnodeaffinity;
+    domctl.domain = (domid_t)domid;
+
+    set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local);
+    domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8;
+
+    ret = do_domctl(xch, &domctl);
+
+    memcpy(nodemap, local, nodesize);
+
+    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
@@ -521,6 +521,32 @@ int xc_watchdog(xc_interface *xch,
 		uint32_t id,
 		uint32_t timeout);
 
+/**
+ * This function explicitly sets the host NUMA nodes the domain will
+ * have affinity with.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id one wants to set the affinity of.
+ * @parm nodemap the map of the affine nodes.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_node_setaffinity(xc_interface *xch,
+                               uint32_t domind,
+                               xc_nodemap_t nodemap);
+
+/**
+ * This function retrieves the host NUMA nodes the domain has
+ * affinity with.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id one wants to get the node affinity of.
+ * @parm nodemap the map of the affine nodes.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_node_getaffinity(xc_interface *xch,
+                               uint32_t domind,
+                               xc_nodemap_t nodemap);
+
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPc-0004Wm-HK; Fri, 01 Feb 2013 11:04:04 +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 1U1EPa-0004VY-T1
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:03 +0000
Received: from [85.158.143.99:7611] by server-2.bemta-4.messagelabs.com id
	99/1A-01597-121AB015; Fri, 01 Feb 2013 11:04:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359716640!20803527!1
X-Originating-IP: [209.85.214.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 698 invoked from network); 1 Feb 2013 11:04:01 -0000
Received: from mail-bk0-f42.google.com (HELO mail-bk0-f42.google.com)
	(209.85.214.42)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:01 -0000
Received: by mail-bk0-f42.google.com with SMTP id jk7so1802078bkc.1
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=hnVzGf2t5EPbRF7aJQGx0giMUn6gtXay/S0O8H4g/1E=;
	b=uUxTInxD+BrOxkrKE2r0xmTjs+pt0ddQWkO5qOjcztnuRnKeNRYlq3QFKShjMcjAhJ
	THD0ilYjEJ5v2+vVuARi7EY6R7o1DLL/758y7/xu+L2cek5DrnkTlTWjEUU1R1pAatdj
	yTnYPtnDzmM+LJC4Fj/rjlIOMFl6FvSnlaIdLbl9qhxacV1o1YNF7TvMgRAjWLUWs1WY
	2R1BjUYcLlQdCdDaT9zDhXTY8y91VdXAXYI3yoRXcJPJF7r3YkjQKjd0hAZZU+bOWemO
	QR4+rBZglY6EHlkRaObdGxUe1nFKy50+9r18YQvHg6wl3Bf7EiT093iHyO7Pngr0NNat
	aXuQ==
X-Received: by 10.204.152.71 with SMTP id f7mr3153844bkw.72.1359716639783;
	Fri, 01 Feb 2013 03:03:59 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.58
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e4538bb30679cb37afee61e04a656c2e4e66f285
Message-Id: <e4538bb30679cb37afee.1359716476@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:16 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 06 of 11 v3] libxc: allow for explicitly
 specifying 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

By providing the proper get/set interface and wiring them
to the new domctl-s from the previous commit.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

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,83 @@ int xc_domain_shutdown(xc_interface *xch
 }
 
 
+int xc_domain_node_setaffinity(xc_interface *xch,
+                               uint32_t domid,
+                               xc_nodemap_t nodemap)
+{
+    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 setnodeaffinity domctl hypercall");
+        goto out;
+    }
+
+    domctl.cmd = XEN_DOMCTL_setnodeaffinity;
+    domctl.domain = (domid_t)domid;
+
+    memcpy(local, nodemap, nodesize);
+    set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local);
+    domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8;
+
+    ret = do_domctl(xch, &domctl);
+
+    xc_hypercall_buffer_free(xch, local);
+
+ out:
+    return ret;
+}
+
+int xc_domain_node_getaffinity(xc_interface *xch,
+                               uint32_t domid,
+                               xc_nodemap_t nodemap)
+{
+    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 getnodeaffinity domctl hypercall");
+        goto out;
+    }
+
+    domctl.cmd = XEN_DOMCTL_getnodeaffinity;
+    domctl.domain = (domid_t)domid;
+
+    set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local);
+    domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8;
+
+    ret = do_domctl(xch, &domctl);
+
+    memcpy(nodemap, local, nodesize);
+
+    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
@@ -521,6 +521,32 @@ int xc_watchdog(xc_interface *xch,
 		uint32_t id,
 		uint32_t timeout);
 
+/**
+ * This function explicitly sets the host NUMA nodes the domain will
+ * have affinity with.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id one wants to set the affinity of.
+ * @parm nodemap the map of the affine nodes.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_node_setaffinity(xc_interface *xch,
+                               uint32_t domind,
+                               xc_nodemap_t nodemap);
+
+/**
+ * This function retrieves the host NUMA nodes the domain has
+ * affinity with.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id one wants to get the node affinity of.
+ * @parm nodemap the map of the affine nodes.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_node_getaffinity(xc_interface *xch,
+                               uint32_t domind,
+                               xc_nodemap_t nodemap);
+
 int xc_vcpu_setaffinity(xc_interface *xch,
                         uint32_t domid,
                         int vcpu,

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPc-0004WX-3A; Fri, 01 Feb 2013 11:04:04 +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 1U1EPa-0004VY-4H
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:02 +0000
Received: from [85.158.143.99:7552] by server-2.bemta-4.messagelabs.com id
	15/1A-01597-121AB015; Fri, 01 Feb 2013 11:04:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359716636!20683235!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2718 invoked from network); 1 Feb 2013 11:03:59 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:59 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so1746383bkc.7
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=8JJE/HOnLL2CozH4ei+vYA2HYHweTJ5ae5xEflZ+Sls=;
	b=FOumnPFpDy7l1M1jb/8BKDNqD2KJGRIInFy0OZdC9lgwwmnzLIPB+/kNIpLLK3kHRJ
	Deo1wS64m0abdQvejENqcDergyi1Fc/ZlpGIA91pJfgNpnsBPXeIt5FBB7Ma34mlVJZE
	X0pkPMm8a4gLPpDyRwCLnA/603FdK+L8otskpZ64ValdDBfDGUqoXzMTG06cyWz0RjrX
	wENBs8rJ5diZTfbGzk/62KPXxnaN0SOyOitCSN+ykSuC7eCkjCio8G9XA6ynETFgWK15
	jrmAMecJI8/h9a34/dKgQTfLbd4BVTXha/mSRqLOGC8HnEWPLPb2kI4ckqH0/Rd55zGi
	6kzA==
X-Received: by 10.204.8.15 with SMTP id f15mr3318347bkf.88.1359716636003;
	Fri, 01 Feb 2013 03:03:56 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.53
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b30913e753c4f0a23960aeed0d7f203ed3c6dcc
Message-Id: <7b30913e753c4f0a2396.1359716474@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:14 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 04 of 11 v3] xen: 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

As vcpu-affinity tells where VCPUs must run, node-affinity tells
where they should or, better, prefer. While respecting vcpu-affinity
remains mandatory, node-affinity is not that strict, it only expresses
a preference, although honouring it is almost always true that will
bring significant performances benefit (especially as compared to
not having any affinity at all).

This change modifies the VCPU load balancing algorithm (for the
credit scheduler only), introducing a two steps logic.
During the first step, we use the node-affinity mask. The aim is
giving precedence to the CPUs where it is known to be preferable
for the domain to run. If that fails in finding a valid PCPU, the
node-affinity is just ignored and, in the second step, we fall
back to using cpu-affinity only.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v2:
 * for_each_csched_balance_step() now is defined as a regular, and
   easier to understand, 0...n for() loop, instead of a going backwards
   one, as that wasn't really needed;
 * checking whether or not a CSCHED_BALANCE_NODE_AFFINITY balancing
   set is useful or not now happens outside of csched_balance_cpumask(),
   i.e., closer to the actual loop, making the logic a lot more evident
   and easy to understand, as requested during review;
 * while reworking __runq_tickle(), handling of idle pcpu has been brought
   outside from the balancing loop, as requested during review;
 * __csched_vcpu_is_migrateable() was just wrong, so it has been removed;
 * the suboptimal handling of SMT in _csched_cpu_pick() has been moved
   to a separate patch (i.e., the previous patch in the series);
 * moved the CPU mask needed for balancing within `csched_pcpu', as
   suggested during review. This way it is not only more close to
   other per-PCPU data (potential cache related benefits), but it is
   also only allocated for the PCPUs credit is in charge of.

Changes from v1:
 * CPU masks variables moved off from the stack, as requested during
   review. As per the comments in the code, having them in the private
   (per-scheduler instance) struct could have been enough, but it would be
   racy (again, see comments). For that reason, use a global bunch of
   them of (via per_cpu());
 * George suggested a different load balancing logic during v1's review. I
   think he was right and then I changed the old implementation in a way
   that resembles exactly that. I rewrote most of this patch to introduce
   a more sensible and effective noda-affinity handling logic.

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
@@ -111,6 +111,12 @@
 
 
 /*
+ * Node Balancing
+ */
+#define CSCHED_BALANCE_NODE_AFFINITY    0
+#define CSCHED_BALANCE_CPU_AFFINITY     1
+
+/*
  * Boot parameters
  */
 static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
@@ -125,9 +131,20 @@ struct csched_pcpu {
     struct timer ticker;
     unsigned int tick;
     unsigned int idle_bias;
+    /* Store this here to avoid having too many cpumask_var_t-s on stack */
+    cpumask_var_t balance_mask;
 };
 
 /*
+ * Convenience macro for accessing the per-PCPU cpumask we need for
+ * implementing the two steps (vcpu and node affinity) balancing logic.
+ * It is stored in csched_pcpu so that serialization is not an issue,
+ * as there is a csched_pcpu for each PCPU and we always hold the
+ * runqueue spin-lock when using this.
+ */
+#define csched_balance_mask (CSCHED_PCPU(smp_processor_id())->balance_mask)
+
+/*
  * Virtual CPU
  */
 struct csched_vcpu {
@@ -159,6 +176,9 @@ struct csched_dom {
     struct list_head active_vcpu;
     struct list_head active_sdom_elem;
     struct domain *dom;
+    /* cpumask translated from the domain's node-affinity.
+     * Basically, the CPUs we prefer to be scheduled on. */
+    cpumask_var_t node_affinity_cpumask;
     uint16_t active_vcpu_count;
     uint16_t weight;
     uint16_t cap;
@@ -239,6 +259,43 @@ static inline void
     list_del_init(&svc->runq_elem);
 }
 
+#define for_each_csched_balance_step(step) \
+    for ( (step) = 0; (step) <= CSCHED_BALANCE_CPU_AFFINITY; (step)++ )
+
+
+/*
+ * vcpu-affinity balancing is always necessary and must never be skipped.
+ * OTOH, if a domain has affinity with all the nodes, we can tell the caller
+ * that he can safely skip the node-affinity balancing step.
+ */
+#define __vcpu_has_valuable_node_affinity(vc) \
+    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
+
+static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
+{
+    if ( step == CSCHED_BALANCE_NODE_AFFINITY
+         && !__vcpu_has_valuable_node_affinity(vc) )
+        return 1;
+    return 0;
+}
+
+/*
+ * Each csched-balance step uses its own cpumask. This function determines
+ * which one (given the step) and copies it in mask. For the node-affinity
+ * balancing step, the pcpus that are not part of vc's vcpu-affinity are
+ * filtered out from the result, to avoid running a vcpu where it would
+ * like, but is not allowed to!
+ */
+static void
+csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
+{
+    if ( step == CSCHED_BALANCE_NODE_AFFINITY )
+        cpumask_and(mask, CSCHED_DOM(vc->domain)->node_affinity_cpumask,
+                    vc->cpu_affinity);
+    else /* step == CSCHED_BALANCE_CPU_AFFINITY */
+        cpumask_copy(mask, vc->cpu_affinity);
+}
+
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
@@ -266,12 +323,12 @@ static inline void
     struct csched_vcpu * const cur = CSCHED_VCPU(curr_on_cpu(cpu));
     struct csched_private *prv = CSCHED_PRIV(per_cpu(scheduler, cpu));
     cpumask_t mask, idle_mask;
-    int idlers_empty;
+    int balance_step, idlers_empty;
 
     ASSERT(cur);
     cpumask_clear(&mask);
+    idlers_empty = cpumask_empty(prv->idlers);
 
-    idlers_empty = cpumask_empty(prv->idlers);
 
     /*
      * If the pcpu is idle, or there are no idlers and the new
@@ -291,41 +348,67 @@ static inline void
     }
     else if ( !idlers_empty )
     {
-        /* Check whether or not there are idlers that can run new */
-        cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
+        /* Node and vcpu-affinity balancing loop */
+        for_each_csched_balance_step( balance_step )
+        {
+            int new_idlers_empty;
 
-        /*
-         * If there are no suitable idlers for new, and it's higher
-         * priority than cur, ask the scheduler to migrate cur away.
-         * We have to act like this (instead of just waking some of
-         * the idlers suitable for cur) because cur is running.
-         *
-         * If there are suitable idlers for new, no matter priorities,
-         * leave cur alone (as it is running and is, likely, cache-hot)
-         * and wake some of them (which is waking up and so is, likely,
-         * cache cold anyway).
-         */
-        if ( cpumask_empty(&idle_mask) && new->pri > cur->pri )
-        {
-            SCHED_STAT_CRANK(tickle_idlers_none);
-            SCHED_VCPU_STAT_CRANK(cur, kicked_away);
-            SCHED_VCPU_STAT_CRANK(cur, migrate_r);
-            SCHED_STAT_CRANK(migrate_kicked_away);
-            set_bit(_VPF_migrating, &cur->vcpu->pause_flags);
-            cpumask_set_cpu(cpu, &mask);
-        }
-        else if ( !cpumask_empty(&idle_mask) )
-        {
-            /* Which of the idlers suitable for new shall we wake up? */
-            SCHED_STAT_CRANK(tickle_idlers_some);
-            if ( opt_tickle_one_idle )
+            /* For vcpus with no node-affinity, consider vcpu-affinity only */
+            if ( csched_balance_step_skippable( balance_step, new->vcpu) )
+                continue;
+
+            /* Are there idlers suitable for new (for this balance step)? */
+            csched_balance_cpumask(new->vcpu, balance_step,
+                                   csched_balance_mask);
+            cpumask_and(&idle_mask, prv->idlers, csched_balance_mask);
+            new_idlers_empty = cpumask_empty(&idle_mask);
+
+            /*
+             * Let's not be too harsh! If there aren't idlers suitable
+             * for new in its node-affinity mask, make sure we check its
+             * vcpu-affinity as well, before taking final decisions.
+             */
+            if ( new_idlers_empty
+                 && balance_step == CSCHED_BALANCE_NODE_AFFINITY )
+                continue;
+
+            /*
+             * If there are no suitable idlers for new, and it's higher
+             * priority than cur, ask the scheduler to migrate cur away.
+             * We have to act like this (instead of just waking some of
+             * the idlers suitable for cur) because cur is running.
+             *
+             * If there are suitable idlers for new, no matter priorities,
+             * leave cur alone (as it is running and is, likely, cache-hot)
+             * and wake some of them (which is waking up and so is, likely,
+             * cache cold anyway).
+             */
+            if ( new_idlers_empty && new->pri > cur->pri )
             {
-                this_cpu(last_tickle_cpu) =
-                    cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask);
-                cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
+                SCHED_STAT_CRANK(tickle_idlers_none);
+                SCHED_VCPU_STAT_CRANK(cur, kicked_away);
+                SCHED_VCPU_STAT_CRANK(cur, migrate_r);
+                SCHED_STAT_CRANK(migrate_kicked_away);
+                set_bit(_VPF_migrating, &cur->vcpu->pause_flags);
+                cpumask_set_cpu(cpu, &mask);
             }
-            else
-                cpumask_or(&mask, &mask, &idle_mask);
+            else if ( !new_idlers_empty )
+            {
+                /* Which of the idlers suitable for new shall we wake up? */
+                SCHED_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);
+            }
+
+            /* Did we find anyone? */
+            if ( !cpumask_empty(&mask) )
+                break;
         }
     }
 
@@ -370,6 +453,7 @@ csched_free_pdata(const struct scheduler
 
     spin_unlock_irqrestore(&prv->lock, flags);
 
+    free_cpumask_var(spc->balance_mask);
     xfree(spc);
 }
 
@@ -385,6 +469,12 @@ csched_alloc_pdata(const struct schedule
     if ( spc == NULL )
         return NULL;
 
+    if ( !alloc_cpumask_var(&spc->balance_mask) )
+    {
+        xfree(spc);
+        return NULL;
+    }
+
     spin_lock_irqsave(&prv->lock, flags);
 
     /* Initialize/update system-wide config */
@@ -475,15 +565,16 @@ 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
-     * peer PCPU. Only pick up work that's allowed to run on our CPU.
+     * peer PCPU. Only pick up work that prefers and/or is allowed to run
+     * on our CPU.
      */
     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
@@ -493,97 +584,110 @@ static int
     cpumask_t idlers;
     cpumask_t *online;
     struct csched_pcpu *spc = NULL;
-    int cpu;
+    int cpu = vc->processor;
+    int balance_step;
 
-    /*
-     * Pick from online CPUs in VCPU's affinity mask, giving a
-     * preference to its current processor if it's in there.
-     */
     online = cpupool_scheduler_cpumask(vc->domain->cpupool);
-    cpumask_and(&cpus, online, vc->cpu_affinity);
-    cpu = cpumask_test_cpu(vc->processor, &cpus)
-            ? vc->processor
-            : cpumask_cycle(vc->processor, &cpus);
-    ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
+    for_each_csched_balance_step( balance_step )
+    {
+        if ( csched_balance_step_skippable( balance_step, vc) )
+            continue;
 
-    /*
-     * Try to find an idle processor within the above constraints.
-     *
-     * In multi-core and multi-threaded CPUs, not all idle execution
-     * vehicles are equal!
-     *
-     * We give preference to the idle execution vehicle with the most
-     * idling neighbours in its grouping. This distributes work across
-     * distinct cores first and guarantees we don't do something stupid
-     * like run two VCPUs on co-hyperthreads while there are idle cores
-     * or sockets.
-     *
-     * Notice that, when computing the "idleness" of cpu, we may want to
-     * discount vc. That is, iff vc is the currently running and the only
-     * runnable vcpu on cpu, we add cpu to the idlers.
-     */
-    cpumask_and(&idlers, &cpu_online_map, CSCHED_PRIV(ops)->idlers);
-    if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
-        cpumask_set_cpu(cpu, &idlers);
-    cpumask_and(&cpus, &cpus, &idlers);
+        /* Pick an online CPU from the proper affinity mask */
+        csched_balance_cpumask(vc, balance_step, &cpus);
+        cpumask_and(&cpus, &cpus, online);
 
-    /*
-     * It is important that cpu points to an idle processor, if a suitable
-     * one exists (and we can use cpus to check and, possibly, choose a new
-     * CPU, as we just &&-ed it with idlers). In fact, if we are on SMT, and
-     * cpu points to a busy thread with an idle sibling, both the threads
-     * will be considered the same, from the "idleness" calculation point
-     * of view", preventing vcpu from being moved to the thread that is
-     * actually idle.
-     */
-    if ( !cpumask_empty(&cpus) && !cpumask_test_cpu(cpu, &cpus) )
-        cpu = cpumask_cycle(cpu, &cpus);
-    cpumask_clear_cpu(cpu, &cpus);
+        /* If present, prefer vc's current processor */
+        cpu = cpumask_test_cpu(vc->processor, &cpus)
+                ? vc->processor
+                : cpumask_cycle(vc->processor, &cpus);
+        ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
 
-    while ( !cpumask_empty(&cpus) )
-    {
-        cpumask_t cpu_idlers;
-        cpumask_t nxt_idlers;
-        int nxt, weight_cpu, weight_nxt;
-        int migrate_factor;
+        /*
+         * Try to find an idle processor within the above constraints.
+         *
+         * In multi-core and multi-threaded CPUs, not all idle execution
+         * vehicles are equal!
+         *
+         * We give preference to the idle execution vehicle with the most
+         * idling neighbours in its grouping. This distributes work across
+         * distinct cores first and guarantees we don't do something stupid
+         * like run two VCPUs on co-hyperthreads while there are idle cores
+         * or sockets.
+         *
+         * Notice that, when computing the "idleness" of cpu, we may want to
+         * discount vc. That is, iff vc is the currently running and the only
+         * runnable vcpu on cpu, we add cpu to the idlers.
+         */
+        cpumask_and(&idlers, &cpu_online_map, CSCHED_PRIV(ops)->idlers);
+        if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
+            cpumask_set_cpu(cpu, &idlers);
+        cpumask_and(&cpus, &cpus, &idlers);
 
-        nxt = cpumask_cycle(cpu, &cpus);
+        /*
+         * It is important that cpu points to an idle processor, if a suitable
+         * one exists (and we can use cpus to check and, possibly, choose a new
+         * CPU, as we just &&-ed it with idlers). In fact, if we are on SMT, and
+         * cpu points to a busy thread with an idle sibling, both the threads
+         * will be considered the same, from the "idleness" calculation point
+         * of view", preventing vcpu from being moved to the thread that is
+         * actually idle.
+         */
+        if ( !cpumask_empty(&cpus) && !cpumask_test_cpu(cpu, &cpus) )
+            cpu = cpumask_cycle(cpu, &cpus);
+        cpumask_clear_cpu(cpu, &cpus);
 
-        if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
+        while ( !cpumask_empty(&cpus) )
         {
-            /* We're on the same socket, so check the busy-ness of threads.
-             * Migrate if # of idlers is less at all */
-            ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
-            migrate_factor = 1;
-            cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_sibling_mask, cpu));
-            cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_sibling_mask, nxt));
-        }
-        else
-        {
-            /* We're on different sockets, so check the busy-ness of cores.
-             * Migrate only if the other core is twice as idle */
-            ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
-            migrate_factor = 2;
-            cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_core_mask, cpu));
-            cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_core_mask, nxt));
+            cpumask_t cpu_idlers;
+            cpumask_t nxt_idlers;
+            int nxt, weight_cpu, weight_nxt;
+            int migrate_factor;
+
+            nxt = cpumask_cycle(cpu, &cpus);
+
+            if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
+            {
+                /* We're on the same socket, so check the busy-ness of threads.
+                 * Migrate if # of idlers is less at all */
+                ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
+                migrate_factor = 1;
+                cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_sibling_mask,
+                            cpu));
+                cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_sibling_mask,
+                            nxt));
+            }
+            else
+            {
+                /* We're on different sockets, so check the busy-ness of cores.
+                 * Migrate only if the other core is twice as idle */
+                ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
+                migrate_factor = 2;
+                cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_core_mask, cpu));
+                cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_core_mask, nxt));
+            }
+
+            weight_cpu = cpumask_weight(&cpu_idlers);
+            weight_nxt = cpumask_weight(&nxt_idlers);
+            /* smt_power_savings: consolidate work rather than spreading it */
+            if ( sched_smt_power_savings ?
+                 weight_cpu > weight_nxt :
+                 weight_cpu * migrate_factor < weight_nxt )
+            {
+                cpumask_and(&nxt_idlers, &cpus, &nxt_idlers);
+                spc = CSCHED_PCPU(nxt);
+                cpu = cpumask_cycle(spc->idle_bias, &nxt_idlers);
+                cpumask_andnot(&cpus, &cpus, per_cpu(cpu_sibling_mask, cpu));
+            }
+            else
+            {
+                cpumask_andnot(&cpus, &cpus, &nxt_idlers);
+            }
         }
 
-        weight_cpu = cpumask_weight(&cpu_idlers);
-        weight_nxt = cpumask_weight(&nxt_idlers);
-        /* smt_power_savings: consolidate work rather than spreading it */
-        if ( sched_smt_power_savings ?
-             weight_cpu > weight_nxt :
-             weight_cpu * migrate_factor < weight_nxt )
-        {
-            cpumask_and(&nxt_idlers, &cpus, &nxt_idlers);
-            spc = CSCHED_PCPU(nxt);
-            cpu = cpumask_cycle(spc->idle_bias, &nxt_idlers);
-            cpumask_andnot(&cpus, &cpus, per_cpu(cpu_sibling_mask, cpu));
-        }
-        else
-        {
-            cpumask_andnot(&cpus, &cpus, &nxt_idlers);
-        }
+        /* Stop if cpu is idle */
+        if ( cpumask_test_cpu(cpu, &idlers) )
+            break;
     }
 
     if ( commit && spc )
@@ -925,6 +1029,13 @@ csched_alloc_domdata(const struct schedu
     if ( sdom == NULL )
         return NULL;
 
+    if ( !alloc_cpumask_var(&sdom->node_affinity_cpumask) )
+    {
+        xfree(sdom);
+        return NULL;
+    }
+    cpumask_setall(sdom->node_affinity_cpumask);
+
     /* Initialize credit and weight */
     INIT_LIST_HEAD(&sdom->active_vcpu);
     sdom->active_vcpu_count = 0;
@@ -956,6 +1067,9 @@ csched_dom_init(const struct scheduler *
 static void
 csched_free_domdata(const struct scheduler *ops, void *data)
 {
+    struct csched_dom *sdom = data;
+
+    free_cpumask_var(sdom->node_affinity_cpumask);
     xfree(data);
 }
 
@@ -1252,7 +1366,7 @@ csched_tick(void *_cpu)
 }
 
 static struct csched_vcpu *
-csched_runq_steal(int peer_cpu, int cpu, int pri)
+csched_runq_steal(int peer_cpu, int cpu, int pri, int balance_step)
 {
     const struct csched_pcpu * const peer_pcpu = CSCHED_PCPU(peer_cpu);
     const struct vcpu * const peer_vcpu = curr_on_cpu(peer_cpu);
@@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,
             if ( speer->pri <= pri )
                 break;
 
-            /* Is this VCPU is runnable on our PCPU? */
+            /* Is this VCPU runnable on our PCPU? */
             vc = speer->vcpu;
             BUG_ON( is_idle_vcpu(vc) );
 
-            if (__csched_vcpu_is_migrateable(vc, cpu))
+            /*
+             * If the vcpu has no valuable node-affinity, skip this vcpu.
+             * In fact, what we want is to check if we have any node-affine
+             * work to steal, before starting to look at vcpu-affine work.
+             */
+            if ( balance_step == CSCHED_BALANCE_NODE_AFFINITY
+                 && !__vcpu_has_valuable_node_affinity(vc) )
+                continue;
+
+            csched_balance_cpumask(vc, balance_step, csched_balance_mask);
+            if ( __csched_vcpu_is_migrateable(vc, cpu, csched_balance_mask) )
             {
                 /* We got a candidate. Grab it! */
                 TRACE_3D(TRC_CSCHED_STOLEN_VCPU, peer_cpu,
@@ -1307,7 +1431,8 @@ csched_load_balance(struct csched_privat
     struct csched_vcpu *speer;
     cpumask_t workers;
     cpumask_t *online;
-    int peer_cpu;
+    int peer_cpu, peer_node, bstep;
+    int node = cpu_to_node(cpu);
 
     BUG_ON( cpu != snext->vcpu->processor );
     online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
@@ -1324,42 +1449,68 @@ csched_load_balance(struct csched_privat
         SCHED_STAT_CRANK(load_balance_other);
 
     /*
-     * Peek at non-idling CPUs in the system, starting with our
-     * immediate neighbour.
+     * Let's look around for work to steal, taking both vcpu-affinity
+     * and node-affinity into account. More specifically, we check all
+     * the non-idle CPUs' runq, looking for:
+     *  1. any node-affine work to steal first,
+     *  2. if not finding anything, any vcpu-affine work to steal.
      */
-    cpumask_andnot(&workers, online, prv->idlers);
-    cpumask_clear_cpu(cpu, &workers);
-    peer_cpu = cpu;
+    for_each_csched_balance_step( bstep )
+    {
+        /*
+         * We peek at the non-idling CPUs in a node-wise fashion. In fact,
+         * it is more likely that we find some node-affine work on our same
+         * node, not to mention that migrating vcpus within the same node
+         * could well expected to be cheaper than across-nodes (memory
+         * stays local, there might be some node-wide cache[s], etc.).
+         */
+        peer_node = node;
+        do
+        {
+            /* Find out what the !idle are in this node */
+            cpumask_andnot(&workers, online, prv->idlers);
+            cpumask_and(&workers, &workers, &node_to_cpumask(peer_node));
+            cpumask_clear_cpu(cpu, &workers);
 
-    while ( !cpumask_empty(&workers) )
-    {
-        peer_cpu = cpumask_cycle(peer_cpu, &workers);
-        cpumask_clear_cpu(peer_cpu, &workers);
+            if ( cpumask_empty(&workers) )
+                goto next_node;
 
-        /*
-         * Get ahold of the scheduler lock for this peer CPU.
-         *
-         * Note: We don't spin on this lock but simply try it. Spinning could
-         * cause a deadlock if the peer CPU is also load balancing and trying
-         * to lock this CPU.
-         */
-        if ( !pcpu_schedule_trylock(peer_cpu) )
-        {
-            SCHED_STAT_CRANK(steal_trylock_failed);
-            continue;
-        }
+            peer_cpu = cpumask_first(&workers);
+            do
+            {
+                /*
+                 * Get ahold of the scheduler lock for this peer CPU.
+                 *
+                 * Note: We don't spin on this lock but simply try it. Spinning
+                 * could cause a deadlock if the peer CPU is also load
+                 * balancing and trying to lock this CPU.
+                 */
+                if ( !pcpu_schedule_trylock(peer_cpu) )
+                {
+                    SCHED_STAT_CRANK(steal_trylock_failed);
+                    peer_cpu = cpumask_cycle(peer_cpu, &workers);
+                    continue;
+                }
 
-        /*
-         * Any work over there to steal?
-         */
-        speer = cpumask_test_cpu(peer_cpu, online) ?
-            csched_runq_steal(peer_cpu, cpu, snext->pri) : NULL;
-        pcpu_schedule_unlock(peer_cpu);
-        if ( speer != NULL )
-        {
-            *stolen = 1;
-            return speer;
-        }
+                /* Any work over there to steal? */
+                speer = cpumask_test_cpu(peer_cpu, online) ?
+                    csched_runq_steal(peer_cpu, cpu, snext->pri, bstep) : NULL;
+                pcpu_schedule_unlock(peer_cpu);
+
+                /* As soon as one vcpu is found, balancing ends */
+                if ( speer != NULL )
+                {
+                    *stolen = 1;
+                    return speer;
+                }
+
+                peer_cpu = cpumask_cycle(peer_cpu, &workers);
+
+            } while( peer_cpu != cpumask_first(&workers) );
+
+ next_node:
+            peer_node = cycle_node(peer_node, node_online_map);
+        } while( peer_node != node );
     }
 
  out:
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
@@ -41,6 +41,8 @@
  * int last_node(mask)			Number highest set bit, or MAX_NUMNODES
  * int first_unset_node(mask)		First node not set in mask, or 
  *					MAX_NUMNODES.
+ * int cycle_node(node, mask)		Next node cycling from 'node', or
+ *					MAX_NUMNODES
  *
  * nodemask_t nodemask_of_node(node)	Return nodemask with bit 'node' set
  * NODE_MASK_ALL			Initializer - all bits set
@@ -254,6 +256,16 @@ static inline int __first_unset_node(con
 			find_first_zero_bit(maskp->bits, MAX_NUMNODES));
 }
 
+#define cycle_node(n, src) __cycle_node((n), &(src), MAX_NUMNODES)
+static inline int __cycle_node(int n, const nodemask_t *maskp, int nbits)
+{
+    int nxt = __next_node(n, maskp, nbits);
+
+    if (nxt == nbits)
+        nxt = __first_node(maskp, nbits);
+    return nxt;
+}
+
 #define NODE_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(MAX_NUMNODES)
 
 #if MAX_NUMNODES <= BITS_PER_LONG

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPc-0004WX-3A; Fri, 01 Feb 2013 11:04:04 +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 1U1EPa-0004VY-4H
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:02 +0000
Received: from [85.158.143.99:7552] by server-2.bemta-4.messagelabs.com id
	15/1A-01597-121AB015; Fri, 01 Feb 2013 11:04:01 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359716636!20683235!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2718 invoked from network); 1 Feb 2013 11:03:59 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:03:59 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so1746383bkc.7
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=8JJE/HOnLL2CozH4ei+vYA2HYHweTJ5ae5xEflZ+Sls=;
	b=FOumnPFpDy7l1M1jb/8BKDNqD2KJGRIInFy0OZdC9lgwwmnzLIPB+/kNIpLLK3kHRJ
	Deo1wS64m0abdQvejENqcDergyi1Fc/ZlpGIA91pJfgNpnsBPXeIt5FBB7Ma34mlVJZE
	X0pkPMm8a4gLPpDyRwCLnA/603FdK+L8otskpZ64ValdDBfDGUqoXzMTG06cyWz0RjrX
	wENBs8rJ5diZTfbGzk/62KPXxnaN0SOyOitCSN+ykSuC7eCkjCio8G9XA6ynETFgWK15
	jrmAMecJI8/h9a34/dKgQTfLbd4BVTXha/mSRqLOGC8HnEWPLPb2kI4ckqH0/Rd55zGi
	6kzA==
X-Received: by 10.204.8.15 with SMTP id f15mr3318347bkf.88.1359716636003;
	Fri, 01 Feb 2013 03:03:56 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.53
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:03:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7b30913e753c4f0a23960aeed0d7f203ed3c6dcc
Message-Id: <7b30913e753c4f0a2396.1359716474@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:14 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 04 of 11 v3] xen: 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

As vcpu-affinity tells where VCPUs must run, node-affinity tells
where they should or, better, prefer. While respecting vcpu-affinity
remains mandatory, node-affinity is not that strict, it only expresses
a preference, although honouring it is almost always true that will
bring significant performances benefit (especially as compared to
not having any affinity at all).

This change modifies the VCPU load balancing algorithm (for the
credit scheduler only), introducing a two steps logic.
During the first step, we use the node-affinity mask. The aim is
giving precedence to the CPUs where it is known to be preferable
for the domain to run. If that fails in finding a valid PCPU, the
node-affinity is just ignored and, in the second step, we fall
back to using cpu-affinity only.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v2:
 * for_each_csched_balance_step() now is defined as a regular, and
   easier to understand, 0...n for() loop, instead of a going backwards
   one, as that wasn't really needed;
 * checking whether or not a CSCHED_BALANCE_NODE_AFFINITY balancing
   set is useful or not now happens outside of csched_balance_cpumask(),
   i.e., closer to the actual loop, making the logic a lot more evident
   and easy to understand, as requested during review;
 * while reworking __runq_tickle(), handling of idle pcpu has been brought
   outside from the balancing loop, as requested during review;
 * __csched_vcpu_is_migrateable() was just wrong, so it has been removed;
 * the suboptimal handling of SMT in _csched_cpu_pick() has been moved
   to a separate patch (i.e., the previous patch in the series);
 * moved the CPU mask needed for balancing within `csched_pcpu', as
   suggested during review. This way it is not only more close to
   other per-PCPU data (potential cache related benefits), but it is
   also only allocated for the PCPUs credit is in charge of.

Changes from v1:
 * CPU masks variables moved off from the stack, as requested during
   review. As per the comments in the code, having them in the private
   (per-scheduler instance) struct could have been enough, but it would be
   racy (again, see comments). For that reason, use a global bunch of
   them of (via per_cpu());
 * George suggested a different load balancing logic during v1's review. I
   think he was right and then I changed the old implementation in a way
   that resembles exactly that. I rewrote most of this patch to introduce
   a more sensible and effective noda-affinity handling logic.

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
@@ -111,6 +111,12 @@
 
 
 /*
+ * Node Balancing
+ */
+#define CSCHED_BALANCE_NODE_AFFINITY    0
+#define CSCHED_BALANCE_CPU_AFFINITY     1
+
+/*
  * Boot parameters
  */
 static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
@@ -125,9 +131,20 @@ struct csched_pcpu {
     struct timer ticker;
     unsigned int tick;
     unsigned int idle_bias;
+    /* Store this here to avoid having too many cpumask_var_t-s on stack */
+    cpumask_var_t balance_mask;
 };
 
 /*
+ * Convenience macro for accessing the per-PCPU cpumask we need for
+ * implementing the two steps (vcpu and node affinity) balancing logic.
+ * It is stored in csched_pcpu so that serialization is not an issue,
+ * as there is a csched_pcpu for each PCPU and we always hold the
+ * runqueue spin-lock when using this.
+ */
+#define csched_balance_mask (CSCHED_PCPU(smp_processor_id())->balance_mask)
+
+/*
  * Virtual CPU
  */
 struct csched_vcpu {
@@ -159,6 +176,9 @@ struct csched_dom {
     struct list_head active_vcpu;
     struct list_head active_sdom_elem;
     struct domain *dom;
+    /* cpumask translated from the domain's node-affinity.
+     * Basically, the CPUs we prefer to be scheduled on. */
+    cpumask_var_t node_affinity_cpumask;
     uint16_t active_vcpu_count;
     uint16_t weight;
     uint16_t cap;
@@ -239,6 +259,43 @@ static inline void
     list_del_init(&svc->runq_elem);
 }
 
+#define for_each_csched_balance_step(step) \
+    for ( (step) = 0; (step) <= CSCHED_BALANCE_CPU_AFFINITY; (step)++ )
+
+
+/*
+ * vcpu-affinity balancing is always necessary and must never be skipped.
+ * OTOH, if a domain has affinity with all the nodes, we can tell the caller
+ * that he can safely skip the node-affinity balancing step.
+ */
+#define __vcpu_has_valuable_node_affinity(vc) \
+    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
+
+static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
+{
+    if ( step == CSCHED_BALANCE_NODE_AFFINITY
+         && !__vcpu_has_valuable_node_affinity(vc) )
+        return 1;
+    return 0;
+}
+
+/*
+ * Each csched-balance step uses its own cpumask. This function determines
+ * which one (given the step) and copies it in mask. For the node-affinity
+ * balancing step, the pcpus that are not part of vc's vcpu-affinity are
+ * filtered out from the result, to avoid running a vcpu where it would
+ * like, but is not allowed to!
+ */
+static void
+csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
+{
+    if ( step == CSCHED_BALANCE_NODE_AFFINITY )
+        cpumask_and(mask, CSCHED_DOM(vc->domain)->node_affinity_cpumask,
+                    vc->cpu_affinity);
+    else /* step == CSCHED_BALANCE_CPU_AFFINITY */
+        cpumask_copy(mask, vc->cpu_affinity);
+}
+
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
@@ -266,12 +323,12 @@ static inline void
     struct csched_vcpu * const cur = CSCHED_VCPU(curr_on_cpu(cpu));
     struct csched_private *prv = CSCHED_PRIV(per_cpu(scheduler, cpu));
     cpumask_t mask, idle_mask;
-    int idlers_empty;
+    int balance_step, idlers_empty;
 
     ASSERT(cur);
     cpumask_clear(&mask);
+    idlers_empty = cpumask_empty(prv->idlers);
 
-    idlers_empty = cpumask_empty(prv->idlers);
 
     /*
      * If the pcpu is idle, or there are no idlers and the new
@@ -291,41 +348,67 @@ static inline void
     }
     else if ( !idlers_empty )
     {
-        /* Check whether or not there are idlers that can run new */
-        cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
+        /* Node and vcpu-affinity balancing loop */
+        for_each_csched_balance_step( balance_step )
+        {
+            int new_idlers_empty;
 
-        /*
-         * If there are no suitable idlers for new, and it's higher
-         * priority than cur, ask the scheduler to migrate cur away.
-         * We have to act like this (instead of just waking some of
-         * the idlers suitable for cur) because cur is running.
-         *
-         * If there are suitable idlers for new, no matter priorities,
-         * leave cur alone (as it is running and is, likely, cache-hot)
-         * and wake some of them (which is waking up and so is, likely,
-         * cache cold anyway).
-         */
-        if ( cpumask_empty(&idle_mask) && new->pri > cur->pri )
-        {
-            SCHED_STAT_CRANK(tickle_idlers_none);
-            SCHED_VCPU_STAT_CRANK(cur, kicked_away);
-            SCHED_VCPU_STAT_CRANK(cur, migrate_r);
-            SCHED_STAT_CRANK(migrate_kicked_away);
-            set_bit(_VPF_migrating, &cur->vcpu->pause_flags);
-            cpumask_set_cpu(cpu, &mask);
-        }
-        else if ( !cpumask_empty(&idle_mask) )
-        {
-            /* Which of the idlers suitable for new shall we wake up? */
-            SCHED_STAT_CRANK(tickle_idlers_some);
-            if ( opt_tickle_one_idle )
+            /* For vcpus with no node-affinity, consider vcpu-affinity only */
+            if ( csched_balance_step_skippable( balance_step, new->vcpu) )
+                continue;
+
+            /* Are there idlers suitable for new (for this balance step)? */
+            csched_balance_cpumask(new->vcpu, balance_step,
+                                   csched_balance_mask);
+            cpumask_and(&idle_mask, prv->idlers, csched_balance_mask);
+            new_idlers_empty = cpumask_empty(&idle_mask);
+
+            /*
+             * Let's not be too harsh! If there aren't idlers suitable
+             * for new in its node-affinity mask, make sure we check its
+             * vcpu-affinity as well, before taking final decisions.
+             */
+            if ( new_idlers_empty
+                 && balance_step == CSCHED_BALANCE_NODE_AFFINITY )
+                continue;
+
+            /*
+             * If there are no suitable idlers for new, and it's higher
+             * priority than cur, ask the scheduler to migrate cur away.
+             * We have to act like this (instead of just waking some of
+             * the idlers suitable for cur) because cur is running.
+             *
+             * If there are suitable idlers for new, no matter priorities,
+             * leave cur alone (as it is running and is, likely, cache-hot)
+             * and wake some of them (which is waking up and so is, likely,
+             * cache cold anyway).
+             */
+            if ( new_idlers_empty && new->pri > cur->pri )
             {
-                this_cpu(last_tickle_cpu) =
-                    cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask);
-                cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
+                SCHED_STAT_CRANK(tickle_idlers_none);
+                SCHED_VCPU_STAT_CRANK(cur, kicked_away);
+                SCHED_VCPU_STAT_CRANK(cur, migrate_r);
+                SCHED_STAT_CRANK(migrate_kicked_away);
+                set_bit(_VPF_migrating, &cur->vcpu->pause_flags);
+                cpumask_set_cpu(cpu, &mask);
             }
-            else
-                cpumask_or(&mask, &mask, &idle_mask);
+            else if ( !new_idlers_empty )
+            {
+                /* Which of the idlers suitable for new shall we wake up? */
+                SCHED_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);
+            }
+
+            /* Did we find anyone? */
+            if ( !cpumask_empty(&mask) )
+                break;
         }
     }
 
@@ -370,6 +453,7 @@ csched_free_pdata(const struct scheduler
 
     spin_unlock_irqrestore(&prv->lock, flags);
 
+    free_cpumask_var(spc->balance_mask);
     xfree(spc);
 }
 
@@ -385,6 +469,12 @@ csched_alloc_pdata(const struct schedule
     if ( spc == NULL )
         return NULL;
 
+    if ( !alloc_cpumask_var(&spc->balance_mask) )
+    {
+        xfree(spc);
+        return NULL;
+    }
+
     spin_lock_irqsave(&prv->lock, flags);
 
     /* Initialize/update system-wide config */
@@ -475,15 +565,16 @@ 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
-     * peer PCPU. Only pick up work that's allowed to run on our CPU.
+     * peer PCPU. Only pick up work that prefers and/or is allowed to run
+     * on our CPU.
      */
     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
@@ -493,97 +584,110 @@ static int
     cpumask_t idlers;
     cpumask_t *online;
     struct csched_pcpu *spc = NULL;
-    int cpu;
+    int cpu = vc->processor;
+    int balance_step;
 
-    /*
-     * Pick from online CPUs in VCPU's affinity mask, giving a
-     * preference to its current processor if it's in there.
-     */
     online = cpupool_scheduler_cpumask(vc->domain->cpupool);
-    cpumask_and(&cpus, online, vc->cpu_affinity);
-    cpu = cpumask_test_cpu(vc->processor, &cpus)
-            ? vc->processor
-            : cpumask_cycle(vc->processor, &cpus);
-    ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
+    for_each_csched_balance_step( balance_step )
+    {
+        if ( csched_balance_step_skippable( balance_step, vc) )
+            continue;
 
-    /*
-     * Try to find an idle processor within the above constraints.
-     *
-     * In multi-core and multi-threaded CPUs, not all idle execution
-     * vehicles are equal!
-     *
-     * We give preference to the idle execution vehicle with the most
-     * idling neighbours in its grouping. This distributes work across
-     * distinct cores first and guarantees we don't do something stupid
-     * like run two VCPUs on co-hyperthreads while there are idle cores
-     * or sockets.
-     *
-     * Notice that, when computing the "idleness" of cpu, we may want to
-     * discount vc. That is, iff vc is the currently running and the only
-     * runnable vcpu on cpu, we add cpu to the idlers.
-     */
-    cpumask_and(&idlers, &cpu_online_map, CSCHED_PRIV(ops)->idlers);
-    if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
-        cpumask_set_cpu(cpu, &idlers);
-    cpumask_and(&cpus, &cpus, &idlers);
+        /* Pick an online CPU from the proper affinity mask */
+        csched_balance_cpumask(vc, balance_step, &cpus);
+        cpumask_and(&cpus, &cpus, online);
 
-    /*
-     * It is important that cpu points to an idle processor, if a suitable
-     * one exists (and we can use cpus to check and, possibly, choose a new
-     * CPU, as we just &&-ed it with idlers). In fact, if we are on SMT, and
-     * cpu points to a busy thread with an idle sibling, both the threads
-     * will be considered the same, from the "idleness" calculation point
-     * of view", preventing vcpu from being moved to the thread that is
-     * actually idle.
-     */
-    if ( !cpumask_empty(&cpus) && !cpumask_test_cpu(cpu, &cpus) )
-        cpu = cpumask_cycle(cpu, &cpus);
-    cpumask_clear_cpu(cpu, &cpus);
+        /* If present, prefer vc's current processor */
+        cpu = cpumask_test_cpu(vc->processor, &cpus)
+                ? vc->processor
+                : cpumask_cycle(vc->processor, &cpus);
+        ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
 
-    while ( !cpumask_empty(&cpus) )
-    {
-        cpumask_t cpu_idlers;
-        cpumask_t nxt_idlers;
-        int nxt, weight_cpu, weight_nxt;
-        int migrate_factor;
+        /*
+         * Try to find an idle processor within the above constraints.
+         *
+         * In multi-core and multi-threaded CPUs, not all idle execution
+         * vehicles are equal!
+         *
+         * We give preference to the idle execution vehicle with the most
+         * idling neighbours in its grouping. This distributes work across
+         * distinct cores first and guarantees we don't do something stupid
+         * like run two VCPUs on co-hyperthreads while there are idle cores
+         * or sockets.
+         *
+         * Notice that, when computing the "idleness" of cpu, we may want to
+         * discount vc. That is, iff vc is the currently running and the only
+         * runnable vcpu on cpu, we add cpu to the idlers.
+         */
+        cpumask_and(&idlers, &cpu_online_map, CSCHED_PRIV(ops)->idlers);
+        if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
+            cpumask_set_cpu(cpu, &idlers);
+        cpumask_and(&cpus, &cpus, &idlers);
 
-        nxt = cpumask_cycle(cpu, &cpus);
+        /*
+         * It is important that cpu points to an idle processor, if a suitable
+         * one exists (and we can use cpus to check and, possibly, choose a new
+         * CPU, as we just &&-ed it with idlers). In fact, if we are on SMT, and
+         * cpu points to a busy thread with an idle sibling, both the threads
+         * will be considered the same, from the "idleness" calculation point
+         * of view", preventing vcpu from being moved to the thread that is
+         * actually idle.
+         */
+        if ( !cpumask_empty(&cpus) && !cpumask_test_cpu(cpu, &cpus) )
+            cpu = cpumask_cycle(cpu, &cpus);
+        cpumask_clear_cpu(cpu, &cpus);
 
-        if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
+        while ( !cpumask_empty(&cpus) )
         {
-            /* We're on the same socket, so check the busy-ness of threads.
-             * Migrate if # of idlers is less at all */
-            ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
-            migrate_factor = 1;
-            cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_sibling_mask, cpu));
-            cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_sibling_mask, nxt));
-        }
-        else
-        {
-            /* We're on different sockets, so check the busy-ness of cores.
-             * Migrate only if the other core is twice as idle */
-            ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
-            migrate_factor = 2;
-            cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_core_mask, cpu));
-            cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_core_mask, nxt));
+            cpumask_t cpu_idlers;
+            cpumask_t nxt_idlers;
+            int nxt, weight_cpu, weight_nxt;
+            int migrate_factor;
+
+            nxt = cpumask_cycle(cpu, &cpus);
+
+            if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
+            {
+                /* We're on the same socket, so check the busy-ness of threads.
+                 * Migrate if # of idlers is less at all */
+                ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
+                migrate_factor = 1;
+                cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_sibling_mask,
+                            cpu));
+                cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_sibling_mask,
+                            nxt));
+            }
+            else
+            {
+                /* We're on different sockets, so check the busy-ness of cores.
+                 * Migrate only if the other core is twice as idle */
+                ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
+                migrate_factor = 2;
+                cpumask_and(&cpu_idlers, &idlers, per_cpu(cpu_core_mask, cpu));
+                cpumask_and(&nxt_idlers, &idlers, per_cpu(cpu_core_mask, nxt));
+            }
+
+            weight_cpu = cpumask_weight(&cpu_idlers);
+            weight_nxt = cpumask_weight(&nxt_idlers);
+            /* smt_power_savings: consolidate work rather than spreading it */
+            if ( sched_smt_power_savings ?
+                 weight_cpu > weight_nxt :
+                 weight_cpu * migrate_factor < weight_nxt )
+            {
+                cpumask_and(&nxt_idlers, &cpus, &nxt_idlers);
+                spc = CSCHED_PCPU(nxt);
+                cpu = cpumask_cycle(spc->idle_bias, &nxt_idlers);
+                cpumask_andnot(&cpus, &cpus, per_cpu(cpu_sibling_mask, cpu));
+            }
+            else
+            {
+                cpumask_andnot(&cpus, &cpus, &nxt_idlers);
+            }
         }
 
-        weight_cpu = cpumask_weight(&cpu_idlers);
-        weight_nxt = cpumask_weight(&nxt_idlers);
-        /* smt_power_savings: consolidate work rather than spreading it */
-        if ( sched_smt_power_savings ?
-             weight_cpu > weight_nxt :
-             weight_cpu * migrate_factor < weight_nxt )
-        {
-            cpumask_and(&nxt_idlers, &cpus, &nxt_idlers);
-            spc = CSCHED_PCPU(nxt);
-            cpu = cpumask_cycle(spc->idle_bias, &nxt_idlers);
-            cpumask_andnot(&cpus, &cpus, per_cpu(cpu_sibling_mask, cpu));
-        }
-        else
-        {
-            cpumask_andnot(&cpus, &cpus, &nxt_idlers);
-        }
+        /* Stop if cpu is idle */
+        if ( cpumask_test_cpu(cpu, &idlers) )
+            break;
     }
 
     if ( commit && spc )
@@ -925,6 +1029,13 @@ csched_alloc_domdata(const struct schedu
     if ( sdom == NULL )
         return NULL;
 
+    if ( !alloc_cpumask_var(&sdom->node_affinity_cpumask) )
+    {
+        xfree(sdom);
+        return NULL;
+    }
+    cpumask_setall(sdom->node_affinity_cpumask);
+
     /* Initialize credit and weight */
     INIT_LIST_HEAD(&sdom->active_vcpu);
     sdom->active_vcpu_count = 0;
@@ -956,6 +1067,9 @@ csched_dom_init(const struct scheduler *
 static void
 csched_free_domdata(const struct scheduler *ops, void *data)
 {
+    struct csched_dom *sdom = data;
+
+    free_cpumask_var(sdom->node_affinity_cpumask);
     xfree(data);
 }
 
@@ -1252,7 +1366,7 @@ csched_tick(void *_cpu)
 }
 
 static struct csched_vcpu *
-csched_runq_steal(int peer_cpu, int cpu, int pri)
+csched_runq_steal(int peer_cpu, int cpu, int pri, int balance_step)
 {
     const struct csched_pcpu * const peer_pcpu = CSCHED_PCPU(peer_cpu);
     const struct vcpu * const peer_vcpu = curr_on_cpu(peer_cpu);
@@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,
             if ( speer->pri <= pri )
                 break;
 
-            /* Is this VCPU is runnable on our PCPU? */
+            /* Is this VCPU runnable on our PCPU? */
             vc = speer->vcpu;
             BUG_ON( is_idle_vcpu(vc) );
 
-            if (__csched_vcpu_is_migrateable(vc, cpu))
+            /*
+             * If the vcpu has no valuable node-affinity, skip this vcpu.
+             * In fact, what we want is to check if we have any node-affine
+             * work to steal, before starting to look at vcpu-affine work.
+             */
+            if ( balance_step == CSCHED_BALANCE_NODE_AFFINITY
+                 && !__vcpu_has_valuable_node_affinity(vc) )
+                continue;
+
+            csched_balance_cpumask(vc, balance_step, csched_balance_mask);
+            if ( __csched_vcpu_is_migrateable(vc, cpu, csched_balance_mask) )
             {
                 /* We got a candidate. Grab it! */
                 TRACE_3D(TRC_CSCHED_STOLEN_VCPU, peer_cpu,
@@ -1307,7 +1431,8 @@ csched_load_balance(struct csched_privat
     struct csched_vcpu *speer;
     cpumask_t workers;
     cpumask_t *online;
-    int peer_cpu;
+    int peer_cpu, peer_node, bstep;
+    int node = cpu_to_node(cpu);
 
     BUG_ON( cpu != snext->vcpu->processor );
     online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
@@ -1324,42 +1449,68 @@ csched_load_balance(struct csched_privat
         SCHED_STAT_CRANK(load_balance_other);
 
     /*
-     * Peek at non-idling CPUs in the system, starting with our
-     * immediate neighbour.
+     * Let's look around for work to steal, taking both vcpu-affinity
+     * and node-affinity into account. More specifically, we check all
+     * the non-idle CPUs' runq, looking for:
+     *  1. any node-affine work to steal first,
+     *  2. if not finding anything, any vcpu-affine work to steal.
      */
-    cpumask_andnot(&workers, online, prv->idlers);
-    cpumask_clear_cpu(cpu, &workers);
-    peer_cpu = cpu;
+    for_each_csched_balance_step( bstep )
+    {
+        /*
+         * We peek at the non-idling CPUs in a node-wise fashion. In fact,
+         * it is more likely that we find some node-affine work on our same
+         * node, not to mention that migrating vcpus within the same node
+         * could well expected to be cheaper than across-nodes (memory
+         * stays local, there might be some node-wide cache[s], etc.).
+         */
+        peer_node = node;
+        do
+        {
+            /* Find out what the !idle are in this node */
+            cpumask_andnot(&workers, online, prv->idlers);
+            cpumask_and(&workers, &workers, &node_to_cpumask(peer_node));
+            cpumask_clear_cpu(cpu, &workers);
 
-    while ( !cpumask_empty(&workers) )
-    {
-        peer_cpu = cpumask_cycle(peer_cpu, &workers);
-        cpumask_clear_cpu(peer_cpu, &workers);
+            if ( cpumask_empty(&workers) )
+                goto next_node;
 
-        /*
-         * Get ahold of the scheduler lock for this peer CPU.
-         *
-         * Note: We don't spin on this lock but simply try it. Spinning could
-         * cause a deadlock if the peer CPU is also load balancing and trying
-         * to lock this CPU.
-         */
-        if ( !pcpu_schedule_trylock(peer_cpu) )
-        {
-            SCHED_STAT_CRANK(steal_trylock_failed);
-            continue;
-        }
+            peer_cpu = cpumask_first(&workers);
+            do
+            {
+                /*
+                 * Get ahold of the scheduler lock for this peer CPU.
+                 *
+                 * Note: We don't spin on this lock but simply try it. Spinning
+                 * could cause a deadlock if the peer CPU is also load
+                 * balancing and trying to lock this CPU.
+                 */
+                if ( !pcpu_schedule_trylock(peer_cpu) )
+                {
+                    SCHED_STAT_CRANK(steal_trylock_failed);
+                    peer_cpu = cpumask_cycle(peer_cpu, &workers);
+                    continue;
+                }
 
-        /*
-         * Any work over there to steal?
-         */
-        speer = cpumask_test_cpu(peer_cpu, online) ?
-            csched_runq_steal(peer_cpu, cpu, snext->pri) : NULL;
-        pcpu_schedule_unlock(peer_cpu);
-        if ( speer != NULL )
-        {
-            *stolen = 1;
-            return speer;
-        }
+                /* Any work over there to steal? */
+                speer = cpumask_test_cpu(peer_cpu, online) ?
+                    csched_runq_steal(peer_cpu, cpu, snext->pri, bstep) : NULL;
+                pcpu_schedule_unlock(peer_cpu);
+
+                /* As soon as one vcpu is found, balancing ends */
+                if ( speer != NULL )
+                {
+                    *stolen = 1;
+                    return speer;
+                }
+
+                peer_cpu = cpumask_cycle(peer_cpu, &workers);
+
+            } while( peer_cpu != cpumask_first(&workers) );
+
+ next_node:
+            peer_node = cycle_node(peer_node, node_online_map);
+        } while( peer_node != node );
     }
 
  out:
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
@@ -41,6 +41,8 @@
  * int last_node(mask)			Number highest set bit, or MAX_NUMNODES
  * int first_unset_node(mask)		First node not set in mask, or 
  *					MAX_NUMNODES.
+ * int cycle_node(node, mask)		Next node cycling from 'node', or
+ *					MAX_NUMNODES
  *
  * nodemask_t nodemask_of_node(node)	Return nodemask with bit 'node' set
  * NODE_MASK_ALL			Initializer - all bits set
@@ -254,6 +256,16 @@ static inline int __first_unset_node(con
 			find_first_zero_bit(maskp->bits, MAX_NUMNODES));
 }
 
+#define cycle_node(n, src) __cycle_node((n), &(src), MAX_NUMNODES)
+static inline int __cycle_node(int n, const nodemask_t *maskp, int nbits)
+{
+    int nxt = __next_node(n, maskp, nbits);
+
+    if (nxt == nbits)
+        nxt = __first_node(maskp, nbits);
+    return nxt;
+}
+
 #define NODE_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(MAX_NUMNODES)
 
 #if MAX_NUMNODES <= BITS_PER_LONG

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPe-0004Xv-5u; Fri, 01 Feb 2013 11:04:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPc-0004Wg-Q6
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:05 +0000
Received: from [85.158.137.99:9286] by server-11.bemta-3.messagelabs.com id
	AF/DE-10249-421AB015; Fri, 01 Feb 2013 11:04:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1359716641!14755331!1
X-Originating-IP: [209.85.214.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25539 invoked from network); 1 Feb 2013 11:04:02 -0000
Received: from mail-bk0-f50.google.com (HELO mail-bk0-f50.google.com)
	(209.85.214.50)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:02 -0000
Received: by mail-bk0-f50.google.com with SMTP id jg9so1767218bkc.9
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=Y14a8BwAN6Wm41lBytgTTJIBFUPUDbdqFJ1R43r7Y/s=;
	b=GRKToWj0Fv3TIX+kXvOawAY4aby6AcKluJkspLGxgktu7mIVyBx2LCIRzkglGt9GPw
	zacsW2eOMnv05pW4GJB5PwEvYyVa6BIMDhpgTots8OF2HY+svH5q0WfNERR3OKJVCnTe
	yI2J4aqcoONvZgD6tVxpaOwZF5zaWr+r42knJKtGI5GwpnAIV/+ddnwVWyeUuvYKHgdL
	b2Yksn2kOapUJo1ZCfbCSwMFUBlE/i5XN5MuguGgkvbBpgE3XaH8AXReR7B7PQJQc5hy
	g1NHhL0qUbAgMlI5onZUk+qEPRsp1SoDBGFRM2KJ3vP0ZRR0Jp0iQp8xch9TdX2qNhQX
	HOTw==
X-Received: by 10.204.147.217 with SMTP id m25mr3244664bkv.17.1359716641671;
	Fri, 01 Feb 2013 03:04:01 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.59
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 01689b3f7939895e949af22fcfa07f01316c6dd3
Message-Id: <01689b3f7939895e949a.1359716477@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:17 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 07 of 11 v3] libxl: allow for explicitly
 specifying 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

By introducing a nodemap in libxl_domain_build_info and
providing the get/set methods to deal with it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4161,6 +4161,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
     return rc;
 }
 
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap)
+{
+    if (xc_domain_node_setaffinity(ctx->xch, domid, nodemap->map)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap)
+{
+    if (xc_domain_node_getaffinity(ctx->xch, domid, nodemap->map)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting node affinity");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *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
@@ -266,6 +266,10 @@
 #endif
 #endif
 
+/* For the 'nodemap' field (of libxl_bitmap type) in
+ * libxl_domain_build_info, containing the node-affinity of the domain. */
+#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
+
 /* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be
  * called from within libxl itself. Callers outside libxl, who
  * do not #include libxl_internal.h, are fine. */
@@ -861,6 +865,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
                            libxl_bitmap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
                                unsigned int max_vcpus, libxl_bitmap *cpumap);
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap);
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *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
@@ -184,6 +184,12 @@ int libxl__domain_build_info_setdefault(
 
     libxl_defbool_setdefault(&b_info->numa_placement, true);
 
+    if (!b_info->nodemap.size) {
+        if (libxl_node_bitmap_alloc(CTX, &b_info->nodemap, 0))
+            return ERROR_FAIL;
+        libxl_bitmap_set_any(&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
@@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         if (rc)
             return rc;
     }
+    libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
 
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
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
@@ -261,6 +261,7 @@ libxl_domain_build_info = Struct("domain
     ("max_vcpus",       integer),
     ("avail_vcpus",     libxl_bitmap),
     ("cpumap",          libxl_bitmap),
+    ("nodemap",         libxl_bitmap),
     ("numa_placement",  libxl_defbool),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPe-0004Xv-5u; Fri, 01 Feb 2013 11:04:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPc-0004Wg-Q6
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:05 +0000
Received: from [85.158.137.99:9286] by server-11.bemta-3.messagelabs.com id
	AF/DE-10249-421AB015; Fri, 01 Feb 2013 11:04:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1359716641!14755331!1
X-Originating-IP: [209.85.214.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25539 invoked from network); 1 Feb 2013 11:04:02 -0000
Received: from mail-bk0-f50.google.com (HELO mail-bk0-f50.google.com)
	(209.85.214.50)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:02 -0000
Received: by mail-bk0-f50.google.com with SMTP id jg9so1767218bkc.9
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=Y14a8BwAN6Wm41lBytgTTJIBFUPUDbdqFJ1R43r7Y/s=;
	b=GRKToWj0Fv3TIX+kXvOawAY4aby6AcKluJkspLGxgktu7mIVyBx2LCIRzkglGt9GPw
	zacsW2eOMnv05pW4GJB5PwEvYyVa6BIMDhpgTots8OF2HY+svH5q0WfNERR3OKJVCnTe
	yI2J4aqcoONvZgD6tVxpaOwZF5zaWr+r42knJKtGI5GwpnAIV/+ddnwVWyeUuvYKHgdL
	b2Yksn2kOapUJo1ZCfbCSwMFUBlE/i5XN5MuguGgkvbBpgE3XaH8AXReR7B7PQJQc5hy
	g1NHhL0qUbAgMlI5onZUk+qEPRsp1SoDBGFRM2KJ3vP0ZRR0Jp0iQp8xch9TdX2qNhQX
	HOTw==
X-Received: by 10.204.147.217 with SMTP id m25mr3244664bkv.17.1359716641671;
	Fri, 01 Feb 2013 03:04:01 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.03.59
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 01689b3f7939895e949af22fcfa07f01316c6dd3
Message-Id: <01689b3f7939895e949a.1359716477@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:17 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 07 of 11 v3] libxl: allow for explicitly
 specifying 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

By introducing a nodemap in libxl_domain_build_info and
providing the get/set methods to deal with it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4161,6 +4161,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
     return rc;
 }
 
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap)
+{
+    if (xc_domain_node_setaffinity(ctx->xch, domid, nodemap->map)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap)
+{
+    if (xc_domain_node_getaffinity(ctx->xch, domid, nodemap->map)) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting node affinity");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *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
@@ -266,6 +266,10 @@
 #endif
 #endif
 
+/* For the 'nodemap' field (of libxl_bitmap type) in
+ * libxl_domain_build_info, containing the node-affinity of the domain. */
+#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
+
 /* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be
  * called from within libxl itself. Callers outside libxl, who
  * do not #include libxl_internal.h, are fine. */
@@ -861,6 +865,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
                            libxl_bitmap *cpumap);
 int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
                                unsigned int max_vcpus, libxl_bitmap *cpumap);
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap);
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
+                                  libxl_bitmap *nodemap);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *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
@@ -184,6 +184,12 @@ int libxl__domain_build_info_setdefault(
 
     libxl_defbool_setdefault(&b_info->numa_placement, true);
 
+    if (!b_info->nodemap.size) {
+        if (libxl_node_bitmap_alloc(CTX, &b_info->nodemap, 0))
+            return ERROR_FAIL;
+        libxl_bitmap_set_any(&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
@@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         if (rc)
             return rc;
     }
+    libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap);
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
 
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
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
@@ -261,6 +261,7 @@ libxl_domain_build_info = Struct("domain
     ("max_vcpus",       integer),
     ("avail_vcpus",     libxl_bitmap),
     ("cpumap",          libxl_bitmap),
+    ("nodemap",         libxl_bitmap),
     ("numa_placement",  libxl_defbool),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPg-0004Z5-IX; Fri, 01 Feb 2013 11:04:08 +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 1U1EPf-0004VY-5y
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:07 +0000
Received: from [85.158.143.99:7887] by server-2.bemta-4.messagelabs.com id
	EC/3A-01597-621AB015; Fri, 01 Feb 2013 11:04:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359716645!20803544!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3041 invoked from network); 1 Feb 2013 11:04:05 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:05 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so1773202bkc.21
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=LYKC/5rh9JvTX1JJyy5UU5tAdtxWdwKWZrQ2kDwzDNQ=;
	b=xCIpAktMxVOg/BPS03IVWc+SRpLTfQuvs9aYf8jlQ64vknUlLMa47YSsijA+Wvkf0e
	K/IJ8QFUVc4B7JHHdysPD9N678NasoEUmfmTXZQPxZonVLsRerbgARbpG1EBayzx6UWI
	m6H7VL53gXeEkQF6k7rHzESU2YQ9tzRllwk5c+DoI8O7dY3h1waH+6NPFE9lvoDjUGDP
	jpjmVEk1JGwXoCq8U/UP20ge4AFyV/59no9CtATkzPjQ37GbaygWKaYyTFbACYH94+m8
	xI7UWknwm2jU+aqSTNpfVCp76sDjacBn3WjO5W8Qc0hVir4reommNSW7mecPYmvKGyCN
	ughw==
X-Received: by 10.204.8.212 with SMTP id i20mr3311354bki.14.1359716645332;
	Fri, 01 Feb 2013 03:04:05 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.03
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 37b7938421dcc7b12259edbed62715428197d5a6
Message-Id: <37b7938421dcc7b12259.1359716479@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:19 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 09 of 11 v3] libxl: automatic placement deals
 with 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

Which basically means the following two things:
 1) during domain creation, it is the node-affinity of
    the domain --rather than the vcpu-affinities of its
    VCPUs-- that is affected by automatic placement;
 2) during automatic placement, when counting how many
    VCPUs are already "bound" to a placement candidate
    (as part of the process of choosing the best
    candidate), both vcpu-affinity and node-affinity
    are considered.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

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
@@ -133,13 +133,13 @@ static int numa_place_domain(libxl__gc *
 {
     int found;
     libxl__numa_candidate candidate;
-    libxl_bitmap candidate_nodemap;
+    libxl_bitmap cpupool_nodemap;
     libxl_cpupoolinfo cpupool_info;
     int i, cpupool, rc = 0;
     uint32_t memkb;
 
     libxl__numa_candidate_init(&candidate);
-    libxl_bitmap_init(&candidate_nodemap);
+    libxl_bitmap_init(&cpupool_nodemap);
 
     /*
      * Extract the cpumap from the cpupool the domain belong to. In fact,
@@ -156,7 +156,7 @@ static int numa_place_domain(libxl__gc *
     rc = libxl_domain_need_memory(CTX, info, &memkb);
     if (rc)
         goto out;
-    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap, 0)) {
+    if (libxl_node_bitmap_alloc(CTX, &cpupool_nodemap, 0)) {
         rc = ERROR_FAIL;
         goto out;
     }
@@ -174,17 +174,19 @@ static int numa_place_domain(libxl__gc *
     if (found == 0)
         goto out;
 
-    /* Map the candidate's node map to the domain's info->cpumap */
-    libxl__numa_candidate_get_nodemap(gc, &candidate, &candidate_nodemap);
-    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
+    /* Map the candidate's node map to the domain's info->nodemap */
+    libxl__numa_candidate_get_nodemap(gc, &candidate, &info->nodemap);
+
+    /* Avoid trying to set the affinity to nodes that might be in the
+     * candidate's nodemap but out of our cpupool. */
+    rc = libxl_cpumap_to_nodemap(CTX, &cpupool_info.cpumap,
+                                 &cpupool_nodemap);
     if (rc)
         goto out;
 
-    /* Avoid trying to set the affinity to cpus that might be in the
-     * nodemap but not in our cpupool. */
-    libxl_for_each_set_bit(i, info->cpumap) {
-        if (!libxl_bitmap_test(&cpupool_info.cpumap, i))
-            libxl_bitmap_reset(&info->cpumap, i);
+    libxl_for_each_set_bit(i, info->nodemap) {
+        if (!libxl_bitmap_test(&cpupool_nodemap, i))
+            libxl_bitmap_reset(&info->nodemap, i);
     }
 
     LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
@@ -193,7 +195,7 @@ static int numa_place_domain(libxl__gc *
 
  out:
     libxl__numa_candidate_dispose(&candidate);
-    libxl_bitmap_dispose(&candidate_nodemap);
+    libxl_bitmap_dispose(&cpupool_nodemap);
     libxl_cpupoolinfo_dispose(&cpupool_info);
     return rc;
 }
@@ -211,10 +213,10 @@ int libxl__build_pre(libxl__gc *gc, uint
     /*
      * Check if the domain has any CPU affinity. If not, try to build
      * up one. In case numa_place_domain() find at least a suitable
-     * candidate, it will affect info->cpumap accordingly; if it
+     * candidate, it will affect info->nodemap accordingly; if it
      * does not, it just leaves it as it is. This means (unless
      * some weird error manifests) the subsequent call to
-     * libxl_set_vcpuaffinity_all() will do the actual placement,
+     * libxl_domain_set_nodeaffinity() will do the actual placement,
      * whatever that turns out to be.
      */
     if (libxl_defbool_val(info->numa_placement)) {
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -184,7 +184,7 @@ static int nr_vcpus_on_nodes(libxl__gc *
                              int vcpus_on_node[])
 {
     libxl_dominfo *dinfo = NULL;
-    libxl_bitmap nodes_counted;
+    libxl_bitmap dom_nodemap, nodes_counted;
     int nr_doms, nr_cpus;
     int i, j, k;
 
@@ -197,6 +197,12 @@ static int nr_vcpus_on_nodes(libxl__gc *
         return ERROR_FAIL;
     }
 
+    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap, 0) < 0) {
+        libxl_bitmap_dispose(&nodes_counted);
+        libxl_dominfo_list_free(dinfo, nr_doms);
+        return ERROR_FAIL;
+    }
+
     for (i = 0; i < nr_doms; i++) {
         libxl_vcpuinfo *vinfo;
         int nr_dom_vcpus;
@@ -205,14 +211,21 @@ static int nr_vcpus_on_nodes(libxl__gc *
         if (vinfo == NULL)
             continue;
 
+        /* Retrieve the domain's node-affinity map */
+        libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
+
         for (j = 0; j < nr_dom_vcpus; j++) {
-            /* For each vcpu of each domain, increment the elements of
-             * the array corresponding to the nodes where the vcpu runs */
+            /*
+             * For each vcpu of each domain, it must have both vcpu-affinity
+             * and node-affinity to (a pcpu belonging to) a certain node to
+             * cause an increment in the corresponding element of the array.
+             */
             libxl_bitmap_set_none(&nodes_counted);
             libxl_for_each_set_bit(k, vinfo[j].cpumap) {
                 int node = tinfo[k].node;
 
                 if (libxl_bitmap_test(suitable_cpumap, k) &&
+                    libxl_bitmap_test(&dom_nodemap, node) &&
                     !libxl_bitmap_test(&nodes_counted, node)) {
                     libxl_bitmap_set(&nodes_counted, node);
                     vcpus_on_node[node]++;
@@ -223,6 +236,7 @@ static int nr_vcpus_on_nodes(libxl__gc *
         libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
     }
 
+    libxl_bitmap_dispose(&dom_nodemap);
     libxl_bitmap_dispose(&nodes_counted);
     libxl_dominfo_list_free(dinfo, nr_doms);
     return 0;

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EPg-0004Z5-IX; Fri, 01 Feb 2013 11:04:08 +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 1U1EPf-0004VY-5y
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:07 +0000
Received: from [85.158.143.99:7887] by server-2.bemta-4.messagelabs.com id
	EC/3A-01597-621AB015; Fri, 01 Feb 2013 11:04:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359716645!20803544!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3041 invoked from network); 1 Feb 2013 11:04:05 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:05 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so1773202bkc.21
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=LYKC/5rh9JvTX1JJyy5UU5tAdtxWdwKWZrQ2kDwzDNQ=;
	b=xCIpAktMxVOg/BPS03IVWc+SRpLTfQuvs9aYf8jlQ64vknUlLMa47YSsijA+Wvkf0e
	K/IJ8QFUVc4B7JHHdysPD9N678NasoEUmfmTXZQPxZonVLsRerbgARbpG1EBayzx6UWI
	m6H7VL53gXeEkQF6k7rHzESU2YQ9tzRllwk5c+DoI8O7dY3h1waH+6NPFE9lvoDjUGDP
	jpjmVEk1JGwXoCq8U/UP20ge4AFyV/59no9CtATkzPjQ37GbaygWKaYyTFbACYH94+m8
	xI7UWknwm2jU+aqSTNpfVCp76sDjacBn3WjO5W8Qc0hVir4reommNSW7mecPYmvKGyCN
	ughw==
X-Received: by 10.204.8.212 with SMTP id i20mr3311354bki.14.1359716645332;
	Fri, 01 Feb 2013 03:04:05 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.03
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 37b7938421dcc7b12259edbed62715428197d5a6
Message-Id: <37b7938421dcc7b12259.1359716479@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:19 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 09 of 11 v3] libxl: automatic placement deals
 with 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

Which basically means the following two things:
 1) during domain creation, it is the node-affinity of
    the domain --rather than the vcpu-affinities of its
    VCPUs-- that is affected by automatic placement;
 2) during automatic placement, when counting how many
    VCPUs are already "bound" to a placement candidate
    (as part of the process of choosing the best
    candidate), both vcpu-affinity and node-affinity
    are considered.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

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
@@ -133,13 +133,13 @@ static int numa_place_domain(libxl__gc *
 {
     int found;
     libxl__numa_candidate candidate;
-    libxl_bitmap candidate_nodemap;
+    libxl_bitmap cpupool_nodemap;
     libxl_cpupoolinfo cpupool_info;
     int i, cpupool, rc = 0;
     uint32_t memkb;
 
     libxl__numa_candidate_init(&candidate);
-    libxl_bitmap_init(&candidate_nodemap);
+    libxl_bitmap_init(&cpupool_nodemap);
 
     /*
      * Extract the cpumap from the cpupool the domain belong to. In fact,
@@ -156,7 +156,7 @@ static int numa_place_domain(libxl__gc *
     rc = libxl_domain_need_memory(CTX, info, &memkb);
     if (rc)
         goto out;
-    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap, 0)) {
+    if (libxl_node_bitmap_alloc(CTX, &cpupool_nodemap, 0)) {
         rc = ERROR_FAIL;
         goto out;
     }
@@ -174,17 +174,19 @@ static int numa_place_domain(libxl__gc *
     if (found == 0)
         goto out;
 
-    /* Map the candidate's node map to the domain's info->cpumap */
-    libxl__numa_candidate_get_nodemap(gc, &candidate, &candidate_nodemap);
-    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
+    /* Map the candidate's node map to the domain's info->nodemap */
+    libxl__numa_candidate_get_nodemap(gc, &candidate, &info->nodemap);
+
+    /* Avoid trying to set the affinity to nodes that might be in the
+     * candidate's nodemap but out of our cpupool. */
+    rc = libxl_cpumap_to_nodemap(CTX, &cpupool_info.cpumap,
+                                 &cpupool_nodemap);
     if (rc)
         goto out;
 
-    /* Avoid trying to set the affinity to cpus that might be in the
-     * nodemap but not in our cpupool. */
-    libxl_for_each_set_bit(i, info->cpumap) {
-        if (!libxl_bitmap_test(&cpupool_info.cpumap, i))
-            libxl_bitmap_reset(&info->cpumap, i);
+    libxl_for_each_set_bit(i, info->nodemap) {
+        if (!libxl_bitmap_test(&cpupool_nodemap, i))
+            libxl_bitmap_reset(&info->nodemap, i);
     }
 
     LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
@@ -193,7 +195,7 @@ static int numa_place_domain(libxl__gc *
 
  out:
     libxl__numa_candidate_dispose(&candidate);
-    libxl_bitmap_dispose(&candidate_nodemap);
+    libxl_bitmap_dispose(&cpupool_nodemap);
     libxl_cpupoolinfo_dispose(&cpupool_info);
     return rc;
 }
@@ -211,10 +213,10 @@ int libxl__build_pre(libxl__gc *gc, uint
     /*
      * Check if the domain has any CPU affinity. If not, try to build
      * up one. In case numa_place_domain() find at least a suitable
-     * candidate, it will affect info->cpumap accordingly; if it
+     * candidate, it will affect info->nodemap accordingly; if it
      * does not, it just leaves it as it is. This means (unless
      * some weird error manifests) the subsequent call to
-     * libxl_set_vcpuaffinity_all() will do the actual placement,
+     * libxl_domain_set_nodeaffinity() will do the actual placement,
      * whatever that turns out to be.
      */
     if (libxl_defbool_val(info->numa_placement)) {
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -184,7 +184,7 @@ static int nr_vcpus_on_nodes(libxl__gc *
                              int vcpus_on_node[])
 {
     libxl_dominfo *dinfo = NULL;
-    libxl_bitmap nodes_counted;
+    libxl_bitmap dom_nodemap, nodes_counted;
     int nr_doms, nr_cpus;
     int i, j, k;
 
@@ -197,6 +197,12 @@ static int nr_vcpus_on_nodes(libxl__gc *
         return ERROR_FAIL;
     }
 
+    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap, 0) < 0) {
+        libxl_bitmap_dispose(&nodes_counted);
+        libxl_dominfo_list_free(dinfo, nr_doms);
+        return ERROR_FAIL;
+    }
+
     for (i = 0; i < nr_doms; i++) {
         libxl_vcpuinfo *vinfo;
         int nr_dom_vcpus;
@@ -205,14 +211,21 @@ static int nr_vcpus_on_nodes(libxl__gc *
         if (vinfo == NULL)
             continue;
 
+        /* Retrieve the domain's node-affinity map */
+        libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
+
         for (j = 0; j < nr_dom_vcpus; j++) {
-            /* For each vcpu of each domain, increment the elements of
-             * the array corresponding to the nodes where the vcpu runs */
+            /*
+             * For each vcpu of each domain, it must have both vcpu-affinity
+             * and node-affinity to (a pcpu belonging to) a certain node to
+             * cause an increment in the corresponding element of the array.
+             */
             libxl_bitmap_set_none(&nodes_counted);
             libxl_for_each_set_bit(k, vinfo[j].cpumap) {
                 int node = tinfo[k].node;
 
                 if (libxl_bitmap_test(suitable_cpumap, k) &&
+                    libxl_bitmap_test(&dom_nodemap, node) &&
                     !libxl_bitmap_test(&nodes_counted, node)) {
                     libxl_bitmap_set(&nodes_counted, node);
                     vcpus_on_node[node]++;
@@ -223,6 +236,7 @@ static int nr_vcpus_on_nodes(libxl__gc *
         libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
     }
 
+    libxl_bitmap_dispose(&dom_nodemap);
     libxl_bitmap_dispose(&nodes_counted);
     libxl_dominfo_list_free(dinfo, nr_doms);
     return 0;

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPs-0004hA-2v; Fri, 01 Feb 2013 11:04:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPp-0004fg-Pv
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:18 +0000
Received: from [85.158.138.51:43801] by server-10.bemta-3.messagelabs.com id
	0C/F3-10609-131AB015; Fri, 01 Feb 2013 11:04:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1359716643!28797218!1
X-Originating-IP: [209.85.214.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3177 invoked from network); 1 Feb 2013 11:04:04 -0000
Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com)
	(209.85.214.47)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:04 -0000
Received: by mail-bk0-f47.google.com with SMTP id jc3so1767763bkc.34
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=nmv3z0TaYtSDdt0+eARdEYFQVMq5M01AiXPMdzmp88Y=;
	b=EyTyGvrO3Q1HU+ON6R9Z/9toQdDixF5oBWCWWN+nrfl6xZgSaaw9mBiyNTelTvm8SH
	t4nrsCA4KcCrWm3ngt/mbnYetyCDVSzJ+ci7HZuc8DpXS7fggCgkV7iBlx2a0oVKOYP3
	yIvvVeW/VdrPyJzgjJLYx9vlpMjnnWaawy2bNfp8ysrlWpTVsnc7nYAdaOhX4o0d7sDh
	FHPiE6AM1YBwPRX94E0xp/YOW0r4qbWaNToajHdCtqH9YNUPNwFYCfvdiVOzeXZBbFdx
	89OU6GNqoDWnhCv/1L27QlSHsC+EgngoCuNwDFyStj87AqQXVBB0fhF2gXhsL+FWThnJ
	Nyyw==
X-Received: by 10.204.150.205 with SMTP id z13mr3244730bkv.16.1359716643374;
	Fri, 01 Feb 2013 03:04:03 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.01
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4e5a5f4ba12771415995918187a601f6ea951fdb
Message-Id: <4e5a5f4ba12771415995.1359716478@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:18 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 08 of 11 v3] libxl: optimize the calculation of
 how many VCPUs can run on a candidate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 choosing the best NUMA placement candidate, we need to figure out
how many VCPUs are runnable on each of them. That requires going through
all the VCPUs of all the domains and check their affinities.

With this change, instead of doing the above for each candidate, we
do it once for all, populating an array while counting. This way, when
we later are evaluating candidates, all we need is summing up the right
elements of the array itself.

This reduces the complexity of the overall algorithm, as it moves a
potentially expensive operation (for_each_vcpu_of_each_domain {})
outside from the core placement loop, so that it is performed only
once instead of (potentially) tens or hundreds of times. More
specifically, we go from a worst case computation time complaxity of:

 O(2^n_nodes) * O(n_domains*n_domain_vcpus)

To, with this change:

 O(n_domains*n_domains_vcpus) + O(2^n_nodes) = O(2^n_nodes)

(with n_nodes<=16, otherwise the algorithm suggests partitioning with
cpupools and does not even start.)

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v2:
 * in nr_vcpus_on_nodes(), vcpu_nodemap renamed to something more
   sensible, as suggested during review.

diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -165,22 +165,34 @@ static uint32_t nodemap_to_free_memkb(li
     return free_memkb;
 }
 
-/* Retrieve the number of vcpus able to run on the cpus of the nodes
- * that are part of the nodemap. */
-static int nodemap_to_nr_vcpus(libxl__gc *gc, libxl_cputopology *tinfo,
+/* Retrieve the number of vcpus able to run on the nodes in nodemap */
+static int nodemap_to_nr_vcpus(libxl__gc *gc, int vcpus_on_node[],
                                const libxl_bitmap *nodemap)
 {
+    int i, nr_vcpus = 0;
+
+    libxl_for_each_set_bit(i, *nodemap)
+        nr_vcpus += vcpus_on_node[i];
+
+    return nr_vcpus;
+}
+
+/* Number of vcpus able to run on the cpus of the various nodes
+ * (reported by filling the array vcpus_on_node[]). */
+static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
+                             const libxl_bitmap *suitable_cpumap,
+                             int vcpus_on_node[])
+{
     libxl_dominfo *dinfo = NULL;
-    libxl_bitmap vcpu_nodemap;
+    libxl_bitmap nodes_counted;
     int nr_doms, nr_cpus;
-    int nr_vcpus = 0;
     int i, j, k;
 
     dinfo = libxl_list_domain(CTX, &nr_doms);
     if (dinfo == NULL)
         return ERROR_FAIL;
 
-    if (libxl_node_bitmap_alloc(CTX, &vcpu_nodemap, 0) < 0) {
+    if (libxl_node_bitmap_alloc(CTX, &nodes_counted, 0) < 0) {
         libxl_dominfo_list_free(dinfo, nr_doms);
         return ERROR_FAIL;
     }
@@ -193,19 +205,17 @@ static int nodemap_to_nr_vcpus(libxl__gc
         if (vinfo == NULL)
             continue;
 
-        /* For each vcpu of each domain ... */
         for (j = 0; j < nr_dom_vcpus; j++) {
+            /* For each vcpu of each domain, increment the elements of
+             * the array corresponding to the nodes where the vcpu runs */
+            libxl_bitmap_set_none(&nodes_counted);
+            libxl_for_each_set_bit(k, vinfo[j].cpumap) {
+                int node = tinfo[k].node;
 
-            /* Build up a map telling on which nodes the vcpu is runnable on */
-            libxl_bitmap_set_none(&vcpu_nodemap);
-            libxl_for_each_set_bit(k, vinfo[j].cpumap)
-                libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node);
-
-            /* And check if that map has any intersection with our nodemap */
-            libxl_for_each_set_bit(k, vcpu_nodemap) {
-                if (libxl_bitmap_test(nodemap, k)) {
-                    nr_vcpus++;
-                    break;
+                if (libxl_bitmap_test(suitable_cpumap, k) &&
+                    !libxl_bitmap_test(&nodes_counted, node)) {
+                    libxl_bitmap_set(&nodes_counted, node);
+                    vcpus_on_node[node]++;
                 }
             }
         }
@@ -213,9 +223,9 @@ static int nodemap_to_nr_vcpus(libxl__gc
         libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
     }
 
-    libxl_bitmap_dispose(&vcpu_nodemap);
+    libxl_bitmap_dispose(&nodes_counted);
     libxl_dominfo_list_free(dinfo, nr_doms);
-    return nr_vcpus;
+    return 0;
 }
 
 /*
@@ -270,7 +280,7 @@ int libxl__get_numa_candidate(libxl__gc 
     libxl_numainfo *ninfo = NULL;
     int nr_nodes = 0, nr_suit_nodes, nr_cpus = 0;
     libxl_bitmap suitable_nodemap, nodemap;
-    int rc = 0;
+    int *vcpus_on_node, rc = 0;
 
     libxl_bitmap_init(&nodemap);
     libxl_bitmap_init(&suitable_nodemap);
@@ -281,6 +291,8 @@ int libxl__get_numa_candidate(libxl__gc 
     if (ninfo == NULL)
         return ERROR_FAIL;
 
+    GCNEW_ARRAY(vcpus_on_node, nr_nodes);
+
     /*
      * The good thing about this solution is that it is based on heuristics
      * (implemented in numa_cmpf() ), but we at least can evaluate it on
@@ -330,6 +342,19 @@ int libxl__get_numa_candidate(libxl__gc 
         goto out;
 
     /*
+     * Later on, we will try to figure out how many vcpus are runnable on
+     * each candidate (as a part of choosing the best one of them). That
+     * requires going through all the vcpus of all the domains and check
+     * their affinities. So, instead of doing that for each candidate,
+     * let's count here the number of vcpus runnable on each node, so that
+     * all we have to do later is summing up the right elements of the
+     * vcpus_on_node array.
+     */
+    rc = nr_vcpus_on_nodes(gc, tinfo, suitable_cpumap, vcpus_on_node);
+    if (rc)
+        goto out;
+
+    /*
      * If the minimum number of NUMA nodes is not explicitly specified
      * (i.e., min_nodes == 0), we try to figure out a sensible number of nodes
      * from where to start generating candidates, if possible (or just start
@@ -414,7 +439,8 @@ int libxl__get_numa_candidate(libxl__gc 
              * current best one (if any).
              */
             libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
-            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
+            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, vcpus_on_node,
+                                                    &nodemap);
             new_cndt.free_memkb = nodes_free_memkb;
             new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
             new_cndt.nr_cpus = nodes_cpus;

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPs-0004hA-2v; Fri, 01 Feb 2013 11:04:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPp-0004fg-Pv
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:18 +0000
Received: from [85.158.138.51:43801] by server-10.bemta-3.messagelabs.com id
	0C/F3-10609-131AB015; Fri, 01 Feb 2013 11:04:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1359716643!28797218!1
X-Originating-IP: [209.85.214.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3177 invoked from network); 1 Feb 2013 11:04:04 -0000
Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com)
	(209.85.214.47)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:04 -0000
Received: by mail-bk0-f47.google.com with SMTP id jc3so1767763bkc.34
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=nmv3z0TaYtSDdt0+eARdEYFQVMq5M01AiXPMdzmp88Y=;
	b=EyTyGvrO3Q1HU+ON6R9Z/9toQdDixF5oBWCWWN+nrfl6xZgSaaw9mBiyNTelTvm8SH
	t4nrsCA4KcCrWm3ngt/mbnYetyCDVSzJ+ci7HZuc8DpXS7fggCgkV7iBlx2a0oVKOYP3
	yIvvVeW/VdrPyJzgjJLYx9vlpMjnnWaawy2bNfp8ysrlWpTVsnc7nYAdaOhX4o0d7sDh
	FHPiE6AM1YBwPRX94E0xp/YOW0r4qbWaNToajHdCtqH9YNUPNwFYCfvdiVOzeXZBbFdx
	89OU6GNqoDWnhCv/1L27QlSHsC+EgngoCuNwDFyStj87AqQXVBB0fhF2gXhsL+FWThnJ
	Nyyw==
X-Received: by 10.204.150.205 with SMTP id z13mr3244730bkv.16.1359716643374;
	Fri, 01 Feb 2013 03:04:03 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.01
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4e5a5f4ba12771415995918187a601f6ea951fdb
Message-Id: <4e5a5f4ba12771415995.1359716478@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:18 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 08 of 11 v3] libxl: optimize the calculation of
 how many VCPUs can run on a candidate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 choosing the best NUMA placement candidate, we need to figure out
how many VCPUs are runnable on each of them. That requires going through
all the VCPUs of all the domains and check their affinities.

With this change, instead of doing the above for each candidate, we
do it once for all, populating an array while counting. This way, when
we later are evaluating candidates, all we need is summing up the right
elements of the array itself.

This reduces the complexity of the overall algorithm, as it moves a
potentially expensive operation (for_each_vcpu_of_each_domain {})
outside from the core placement loop, so that it is performed only
once instead of (potentially) tens or hundreds of times. More
specifically, we go from a worst case computation time complaxity of:

 O(2^n_nodes) * O(n_domains*n_domain_vcpus)

To, with this change:

 O(n_domains*n_domains_vcpus) + O(2^n_nodes) = O(2^n_nodes)

(with n_nodes<=16, otherwise the algorithm suggests partitioning with
cpupools and does not even start.)

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v2:
 * in nr_vcpus_on_nodes(), vcpu_nodemap renamed to something more
   sensible, as suggested during review.

diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -165,22 +165,34 @@ static uint32_t nodemap_to_free_memkb(li
     return free_memkb;
 }
 
-/* Retrieve the number of vcpus able to run on the cpus of the nodes
- * that are part of the nodemap. */
-static int nodemap_to_nr_vcpus(libxl__gc *gc, libxl_cputopology *tinfo,
+/* Retrieve the number of vcpus able to run on the nodes in nodemap */
+static int nodemap_to_nr_vcpus(libxl__gc *gc, int vcpus_on_node[],
                                const libxl_bitmap *nodemap)
 {
+    int i, nr_vcpus = 0;
+
+    libxl_for_each_set_bit(i, *nodemap)
+        nr_vcpus += vcpus_on_node[i];
+
+    return nr_vcpus;
+}
+
+/* Number of vcpus able to run on the cpus of the various nodes
+ * (reported by filling the array vcpus_on_node[]). */
+static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
+                             const libxl_bitmap *suitable_cpumap,
+                             int vcpus_on_node[])
+{
     libxl_dominfo *dinfo = NULL;
-    libxl_bitmap vcpu_nodemap;
+    libxl_bitmap nodes_counted;
     int nr_doms, nr_cpus;
-    int nr_vcpus = 0;
     int i, j, k;
 
     dinfo = libxl_list_domain(CTX, &nr_doms);
     if (dinfo == NULL)
         return ERROR_FAIL;
 
-    if (libxl_node_bitmap_alloc(CTX, &vcpu_nodemap, 0) < 0) {
+    if (libxl_node_bitmap_alloc(CTX, &nodes_counted, 0) < 0) {
         libxl_dominfo_list_free(dinfo, nr_doms);
         return ERROR_FAIL;
     }
@@ -193,19 +205,17 @@ static int nodemap_to_nr_vcpus(libxl__gc
         if (vinfo == NULL)
             continue;
 
-        /* For each vcpu of each domain ... */
         for (j = 0; j < nr_dom_vcpus; j++) {
+            /* For each vcpu of each domain, increment the elements of
+             * the array corresponding to the nodes where the vcpu runs */
+            libxl_bitmap_set_none(&nodes_counted);
+            libxl_for_each_set_bit(k, vinfo[j].cpumap) {
+                int node = tinfo[k].node;
 
-            /* Build up a map telling on which nodes the vcpu is runnable on */
-            libxl_bitmap_set_none(&vcpu_nodemap);
-            libxl_for_each_set_bit(k, vinfo[j].cpumap)
-                libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node);
-
-            /* And check if that map has any intersection with our nodemap */
-            libxl_for_each_set_bit(k, vcpu_nodemap) {
-                if (libxl_bitmap_test(nodemap, k)) {
-                    nr_vcpus++;
-                    break;
+                if (libxl_bitmap_test(suitable_cpumap, k) &&
+                    !libxl_bitmap_test(&nodes_counted, node)) {
+                    libxl_bitmap_set(&nodes_counted, node);
+                    vcpus_on_node[node]++;
                 }
             }
         }
@@ -213,9 +223,9 @@ static int nodemap_to_nr_vcpus(libxl__gc
         libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
     }
 
-    libxl_bitmap_dispose(&vcpu_nodemap);
+    libxl_bitmap_dispose(&nodes_counted);
     libxl_dominfo_list_free(dinfo, nr_doms);
-    return nr_vcpus;
+    return 0;
 }
 
 /*
@@ -270,7 +280,7 @@ int libxl__get_numa_candidate(libxl__gc 
     libxl_numainfo *ninfo = NULL;
     int nr_nodes = 0, nr_suit_nodes, nr_cpus = 0;
     libxl_bitmap suitable_nodemap, nodemap;
-    int rc = 0;
+    int *vcpus_on_node, rc = 0;
 
     libxl_bitmap_init(&nodemap);
     libxl_bitmap_init(&suitable_nodemap);
@@ -281,6 +291,8 @@ int libxl__get_numa_candidate(libxl__gc 
     if (ninfo == NULL)
         return ERROR_FAIL;
 
+    GCNEW_ARRAY(vcpus_on_node, nr_nodes);
+
     /*
      * The good thing about this solution is that it is based on heuristics
      * (implemented in numa_cmpf() ), but we at least can evaluate it on
@@ -330,6 +342,19 @@ int libxl__get_numa_candidate(libxl__gc 
         goto out;
 
     /*
+     * Later on, we will try to figure out how many vcpus are runnable on
+     * each candidate (as a part of choosing the best one of them). That
+     * requires going through all the vcpus of all the domains and check
+     * their affinities. So, instead of doing that for each candidate,
+     * let's count here the number of vcpus runnable on each node, so that
+     * all we have to do later is summing up the right elements of the
+     * vcpus_on_node array.
+     */
+    rc = nr_vcpus_on_nodes(gc, tinfo, suitable_cpumap, vcpus_on_node);
+    if (rc)
+        goto out;
+
+    /*
      * If the minimum number of NUMA nodes is not explicitly specified
      * (i.e., min_nodes == 0), we try to figure out a sensible number of nodes
      * from where to start generating candidates, if possible (or just start
@@ -414,7 +439,8 @@ int libxl__get_numa_candidate(libxl__gc 
              * current best one (if any).
              */
             libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
-            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
+            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, vcpus_on_node,
+                                                    &nodemap);
             new_cndt.free_memkb = nodes_free_memkb;
             new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
             new_cndt.nr_cpus = nodes_cpus;

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPs-0004hX-Gz; Fri, 01 Feb 2013 11:04:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPq-0004fg-Ef
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:18 +0000
Received: from [85.158.137.99:16374] by server-10.bemta-3.messagelabs.com id
	AF/F3-10609-131AB015; Fri, 01 Feb 2013 11:04:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1359716649!14358026!1
X-Originating-IP: [209.85.214.41]
X-SpamReason: No, hits=1.3 required=7.0 tests=BODY_RANDOM_LONG,
	GUARANTEED_100_PERCENT
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32095 invoked from network); 1 Feb 2013 11:04:13 -0000
Received: from mail-bk0-f41.google.com (HELO mail-bk0-f41.google.com)
	(209.85.214.41)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:13 -0000
Received: by mail-bk0-f41.google.com with SMTP id q16so1767938bkw.14
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=amDHtFEGYyrivBsQZckRid/pjqV8jvgi01UwEzjimqk=;
	b=DsriuzdyAC3qltOz0BuZ2ja9trXJETT4EXRtxxVsfMU+PvkuLu0gVAMdZuBzv4Apan
	P1o7sOlmAzEBwL+yMbL8Z4FGYjhHTUs6xloO0YMR2owyiyha1zufqDon2FTIk1RqCY/R
	Xwv+obnhIYDHhc8Ho8/9au4IdJddPTAIfW+b89CmOJL91c1jQTxo9YGgThYfyuoa4pjp
	b48uMZDrUrPJoJL5sdaIBvt9X5c0rwejh3HuSKEFi2oZgJHuHZoS3ajg/BQ9ZWBxScGP
	Z5zC8OFBEfTZiFQ/HjkaaVFg1Zd88KHbYnIjkciihnKdHAzwU9DuoKdNOBQQSQFRXkRF
	02xw==
X-Received: by 10.204.127.11 with SMTP id e11mr3261977bks.0.1359716649553;
	Fri, 01 Feb 2013 03:04:09 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.07
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f05ac3f656309bc71d431beeae7fbb2bbcdbd300
Message-Id: <f05ac3f656309bc71d43.1359716481@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:21 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 11 of 11 v3] docs: rearrange and update 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

To include the new concept of NUMA aware scheduling and
describe its impact.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
--- a/docs/misc/xl-numa-placement.markdown
+++ b/docs/misc/xl-numa-placement.markdown
@@ -14,22 +14,67 @@ the memory directly attached to the set 
 
 The Xen hypervisor deals with NUMA machines by assigning to each domain
 a "node affinity", i.e., a set of NUMA nodes of the host from which they
-get their memory allocated.
+get their memory allocated. Also, even if the node affinity of a domain
+is allowed to change on-line, it is very important to "place" the domain
+correctly when it is fist created, as the most of its memory is allocated
+at that time and can not (for now) be moved easily.
 
 NUMA awareness becomes very important as soon as many domains start
 running memory-intensive workloads on a shared host. In fact, the cost
 of accessing non node-local memory locations is very high, and the
 performance degradation is likely to be noticeable.
 
-## Guest Placement in xl ##
+For more information, have a look at the [Xen NUMA Introduction][numa_intro]
+page on the Wiki.
+
+### Placing via pinning and cpupools ###
+
+The simplest way of placing a domain on a NUMA node is statically pinning
+the domain's vCPUs to the pCPUs of the node. This goes under the name of
+CPU affinity and can be set through the "cpus=" option in the config file
+(more about this below). Another option is to pool together the pCPUs
+spanning the node and put the domain in such a cpupool with the "pool="
+config option (as documented in our [Wiki][cpupools_howto]).
+
+In both the above cases, the domain will not be able to execute outside
+the specified set of pCPUs for any reasons, even if all those pCPUs are
+busy doing something else while there are others, idle, pCPUs.
+
+So, when doing this, local memory accesses are 100% guaranteed, but that
+may come at he cost of some load imbalances.
+
+### NUMA aware scheduling ###
+
+If the credit scheduler is in use, the concept of node affinity defined
+above does not only apply to memory. In fact, starting from Xen 4.3, the
+scheduler always tries to run the domain's vCPUs on one of the nodes in
+its node affinity. Only if that turns out to be impossible, it will just
+pick any free pCPU.
+
+This is, therefore, something more flexible than CPU affinity, as a domain
+can still run everywhere, it just prefers some nodes rather than others.
+Locality of access is less guaranteed than in the pinning case, but that
+comes along with better chances to exploit all the host resources (e.g.,
+the pCPUs).
+
+In fact, if all the pCPUs in a domain's node affinity are busy, it is
+possible for the domain to run outside of there, but it is very likely that
+slower execution (due to remote memory accesses) is still better than no
+execution at all, as it would happen with pinning. For this reason, NUMA
+aware scheduling has the potential of bringing substantial performances
+benefits, although this will depend on the workload.
+
+## Guest placement in xl ##
 
 If using xl for creating and managing guests, it is very easy to ask for
 both manual or automatic placement of them across the host's NUMA nodes.
 
-Note that xm/xend does the very same thing, the only differences residing
-in the details of the heuristics adopted for the placement (see below).
+Note that xm/xend does a very similar thing, the only differences being
+the details of the heuristics adopted for automatic placement (see below),
+and the lack of support (in both xm/xend and the Xen versions where that\
+was the default toolstack) for NUMA aware scheduling.
 
-### Manual Guest Placement with xl ###
+### Placing the guest manually ###
 
 Thanks to the "cpus=" option, it is possible to specify where a domain
 should be created and scheduled on, directly in its config file. This
@@ -41,14 +86,19 @@ This is very simple and effective, but r
 administrator to explicitly specify affinities for each and every domain,
 or Xen won't be able to guarantee the locality for their memory accesses.
 
-It is also possible to deal with NUMA by partitioning the system using
-cpupools. Again, this could be "The Right Answer" for many needs and
-occasions, but has to be carefully considered and setup by hand.
+Notice that this also pins the domain's vCPUs to the specified set of
+pCPUs, so it not only sets the domain's node affinity (its memory will
+come from the nodes to which the pCPUs belong), but at the same time
+forces the vCPUs of the domain to be scheduled on those same pCPUs.
 
-### Automatic Guest Placement with xl ###
+### Placing the guest automatically ###
 
 If no "cpus=" option is specified in the config file, libxl tries
 to figure out on its own on which node(s) the domain could fit best.
+If it finds one (some), the domain's node affinity get set to there,
+and both memory allocations and NUMA aware scheduling (for the credit
+scheduler and starting from Xen 4.3) will comply with it.
+
 It is worthwhile noting that optimally fitting a set of VMs on the NUMA
 nodes of an host is an incarnation of the Bin Packing Problem. In fact,
 the various VMs with different memory sizes are the items to be packed,
@@ -81,7 +131,7 @@ largest amounts of free memory helps kee
 small, and maximizes the probability of being able to put more domains
 there.
 
-## Guest Placement within libxl ##
+## Guest placement in libxl ##
 
 xl achieves automatic NUMA placement because that is what libxl does
 by default. No API is provided (yet) for modifying the behaviour of
@@ -93,15 +143,34 @@ any placement from happening:
     libxl_defbool_set(&domain_build_info->numa_placement, false);
 
 Also, if `numa_placement` is set to `true`, the domain must not
-have any cpu affinity (i.e., `domain_build_info->cpumap` must
+have any CPU affinity (i.e., `domain_build_info->cpumap` must
 have all its bits set, as it is by default), or domain creation
 will fail returning `ERROR_INVAL`.
 
+Starting from Xen 4.3, in case automatic placement happens (and is
+successful), it will affect the domain's node affinity and _not_ its
+CPU affinity. Namely, the domain's vCPUs will not be pinned to any
+pCPU on the host, but the memory from the domain will come from the
+selected node(s) and the NUMA aware scheduling (if the credit scheduler
+is in use) will try to keep the domain there as much as possible.
+
 Besides than that, looking and/or tweaking the placement algorithm
 search "Automatic NUMA placement" in libxl\_internal.h.
 
 Note this may change in future versions of Xen/libxl.
 
+## Xen < 4.3 ##
+
+As NUMA aware scheduling is a new feature of Xen 4.3, things are a little
+bit different for earlier version of Xen. If no "cpus=" option is specified
+and Xen 4.2 is in use, the automatic placement algorithm still runs, but
+the results is used to _pin_ the vCPUs of the domain to the output node(s).
+This is consistent with what was happening with xm/xend, which were also
+affecting the domain's CPU affinity.
+
+On a version of Xen earlier than 4.2, there is not automatic placement at
+all in xl or libxl, and hence no node or CPU affinity being affected.
+
 ## Limitations ##
 
 Analyzing various possible placement solutions is what makes the
@@ -109,3 +178,6 @@ algorithm flexible and quite effective. 
 it won't scale well to systems with arbitrary number of nodes.
 For this reason, automatic placement is disabled (with a warning)
 if it is requested on a host with more than 16 NUMA nodes.
+
+[numa_intro]: http://wiki.xen.org/wiki/Xen_NUMA_Introduction
+[cpupools_howto]: http://wiki.xen.org/wiki/Cpupools_Howto

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:04: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 1U1EPs-0004hX-Gz; Fri, 01 Feb 2013 11:04:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1U1EPq-0004fg-Ef
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:18 +0000
Received: from [85.158.137.99:16374] by server-10.bemta-3.messagelabs.com id
	AF/F3-10609-131AB015; Fri, 01 Feb 2013 11:04:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1359716649!14358026!1
X-Originating-IP: [209.85.214.41]
X-SpamReason: No, hits=1.3 required=7.0 tests=BODY_RANDOM_LONG,
	GUARANTEED_100_PERCENT
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32095 invoked from network); 1 Feb 2013 11:04:13 -0000
Received: from mail-bk0-f41.google.com (HELO mail-bk0-f41.google.com)
	(209.85.214.41)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:13 -0000
Received: by mail-bk0-f41.google.com with SMTP id q16so1767938bkw.14
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=amDHtFEGYyrivBsQZckRid/pjqV8jvgi01UwEzjimqk=;
	b=DsriuzdyAC3qltOz0BuZ2ja9trXJETT4EXRtxxVsfMU+PvkuLu0gVAMdZuBzv4Apan
	P1o7sOlmAzEBwL+yMbL8Z4FGYjhHTUs6xloO0YMR2owyiyha1zufqDon2FTIk1RqCY/R
	Xwv+obnhIYDHhc8Ho8/9au4IdJddPTAIfW+b89CmOJL91c1jQTxo9YGgThYfyuoa4pjp
	b48uMZDrUrPJoJL5sdaIBvt9X5c0rwejh3HuSKEFi2oZgJHuHZoS3ajg/BQ9ZWBxScGP
	Z5zC8OFBEfTZiFQ/HjkaaVFg1Zd88KHbYnIjkciihnKdHAzwU9DuoKdNOBQQSQFRXkRF
	02xw==
X-Received: by 10.204.127.11 with SMTP id e11mr3261977bks.0.1359716649553;
	Fri, 01 Feb 2013 03:04:09 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.07
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f05ac3f656309bc71d431beeae7fbb2bbcdbd300
Message-Id: <f05ac3f656309bc71d43.1359716481@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:21 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 11 of 11 v3] docs: rearrange and update 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

To include the new concept of NUMA aware scheduling and
describe its impact.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
--- a/docs/misc/xl-numa-placement.markdown
+++ b/docs/misc/xl-numa-placement.markdown
@@ -14,22 +14,67 @@ the memory directly attached to the set 
 
 The Xen hypervisor deals with NUMA machines by assigning to each domain
 a "node affinity", i.e., a set of NUMA nodes of the host from which they
-get their memory allocated.
+get their memory allocated. Also, even if the node affinity of a domain
+is allowed to change on-line, it is very important to "place" the domain
+correctly when it is fist created, as the most of its memory is allocated
+at that time and can not (for now) be moved easily.
 
 NUMA awareness becomes very important as soon as many domains start
 running memory-intensive workloads on a shared host. In fact, the cost
 of accessing non node-local memory locations is very high, and the
 performance degradation is likely to be noticeable.
 
-## Guest Placement in xl ##
+For more information, have a look at the [Xen NUMA Introduction][numa_intro]
+page on the Wiki.
+
+### Placing via pinning and cpupools ###
+
+The simplest way of placing a domain on a NUMA node is statically pinning
+the domain's vCPUs to the pCPUs of the node. This goes under the name of
+CPU affinity and can be set through the "cpus=" option in the config file
+(more about this below). Another option is to pool together the pCPUs
+spanning the node and put the domain in such a cpupool with the "pool="
+config option (as documented in our [Wiki][cpupools_howto]).
+
+In both the above cases, the domain will not be able to execute outside
+the specified set of pCPUs for any reasons, even if all those pCPUs are
+busy doing something else while there are others, idle, pCPUs.
+
+So, when doing this, local memory accesses are 100% guaranteed, but that
+may come at he cost of some load imbalances.
+
+### NUMA aware scheduling ###
+
+If the credit scheduler is in use, the concept of node affinity defined
+above does not only apply to memory. In fact, starting from Xen 4.3, the
+scheduler always tries to run the domain's vCPUs on one of the nodes in
+its node affinity. Only if that turns out to be impossible, it will just
+pick any free pCPU.
+
+This is, therefore, something more flexible than CPU affinity, as a domain
+can still run everywhere, it just prefers some nodes rather than others.
+Locality of access is less guaranteed than in the pinning case, but that
+comes along with better chances to exploit all the host resources (e.g.,
+the pCPUs).
+
+In fact, if all the pCPUs in a domain's node affinity are busy, it is
+possible for the domain to run outside of there, but it is very likely that
+slower execution (due to remote memory accesses) is still better than no
+execution at all, as it would happen with pinning. For this reason, NUMA
+aware scheduling has the potential of bringing substantial performances
+benefits, although this will depend on the workload.
+
+## Guest placement in xl ##
 
 If using xl for creating and managing guests, it is very easy to ask for
 both manual or automatic placement of them across the host's NUMA nodes.
 
-Note that xm/xend does the very same thing, the only differences residing
-in the details of the heuristics adopted for the placement (see below).
+Note that xm/xend does a very similar thing, the only differences being
+the details of the heuristics adopted for automatic placement (see below),
+and the lack of support (in both xm/xend and the Xen versions where that\
+was the default toolstack) for NUMA aware scheduling.
 
-### Manual Guest Placement with xl ###
+### Placing the guest manually ###
 
 Thanks to the "cpus=" option, it is possible to specify where a domain
 should be created and scheduled on, directly in its config file. This
@@ -41,14 +86,19 @@ This is very simple and effective, but r
 administrator to explicitly specify affinities for each and every domain,
 or Xen won't be able to guarantee the locality for their memory accesses.
 
-It is also possible to deal with NUMA by partitioning the system using
-cpupools. Again, this could be "The Right Answer" for many needs and
-occasions, but has to be carefully considered and setup by hand.
+Notice that this also pins the domain's vCPUs to the specified set of
+pCPUs, so it not only sets the domain's node affinity (its memory will
+come from the nodes to which the pCPUs belong), but at the same time
+forces the vCPUs of the domain to be scheduled on those same pCPUs.
 
-### Automatic Guest Placement with xl ###
+### Placing the guest automatically ###
 
 If no "cpus=" option is specified in the config file, libxl tries
 to figure out on its own on which node(s) the domain could fit best.
+If it finds one (some), the domain's node affinity get set to there,
+and both memory allocations and NUMA aware scheduling (for the credit
+scheduler and starting from Xen 4.3) will comply with it.
+
 It is worthwhile noting that optimally fitting a set of VMs on the NUMA
 nodes of an host is an incarnation of the Bin Packing Problem. In fact,
 the various VMs with different memory sizes are the items to be packed,
@@ -81,7 +131,7 @@ largest amounts of free memory helps kee
 small, and maximizes the probability of being able to put more domains
 there.
 
-## Guest Placement within libxl ##
+## Guest placement in libxl ##
 
 xl achieves automatic NUMA placement because that is what libxl does
 by default. No API is provided (yet) for modifying the behaviour of
@@ -93,15 +143,34 @@ any placement from happening:
     libxl_defbool_set(&domain_build_info->numa_placement, false);
 
 Also, if `numa_placement` is set to `true`, the domain must not
-have any cpu affinity (i.e., `domain_build_info->cpumap` must
+have any CPU affinity (i.e., `domain_build_info->cpumap` must
 have all its bits set, as it is by default), or domain creation
 will fail returning `ERROR_INVAL`.
 
+Starting from Xen 4.3, in case automatic placement happens (and is
+successful), it will affect the domain's node affinity and _not_ its
+CPU affinity. Namely, the domain's vCPUs will not be pinned to any
+pCPU on the host, but the memory from the domain will come from the
+selected node(s) and the NUMA aware scheduling (if the credit scheduler
+is in use) will try to keep the domain there as much as possible.
+
 Besides than that, looking and/or tweaking the placement algorithm
 search "Automatic NUMA placement" in libxl\_internal.h.
 
 Note this may change in future versions of Xen/libxl.
 
+## Xen < 4.3 ##
+
+As NUMA aware scheduling is a new feature of Xen 4.3, things are a little
+bit different for earlier version of Xen. If no "cpus=" option is specified
+and Xen 4.2 is in use, the automatic placement algorithm still runs, but
+the results is used to _pin_ the vCPUs of the domain to the output node(s).
+This is consistent with what was happening with xm/xend, which were also
+affecting the domain's CPU affinity.
+
+On a version of Xen earlier than 4.2, there is not automatic placement at
+all in xl or libxl, and hence no node or CPU affinity being affected.
+
 ## Limitations ##
 
 Analyzing various possible placement solutions is what makes the
@@ -109,3 +178,6 @@ algorithm flexible and quite effective. 
 it won't scale well to systems with arbitrary number of nodes.
 For this reason, automatic placement is disabled (with a warning)
 if it is requested on a host with more than 16 NUMA nodes.
+
+[numa_intro]: http://wiki.xen.org/wiki/Xen_NUMA_Introduction
+[cpupools_howto]: http://wiki.xen.org/wiki/Cpupools_Howto

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EQ0-0004mh-7b; Fri, 01 Feb 2013 11:04:28 +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 1U1EPy-0004lG-8u
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:26 +0000
Received: from [85.158.139.83:18016] by server-15.bemta-5.messagelabs.com id
	73/6F-18914-931AB015; Fri, 01 Feb 2013 11:04:25 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1359716647!30390995!1
X-Originating-IP: [209.85.214.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20425 invoked from network); 1 Feb 2013 11:04:07 -0000
Received: from mail-bk0-f41.google.com (HELO mail-bk0-f41.google.com)
	(209.85.214.41)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:07 -0000
Received: by mail-bk0-f41.google.com with SMTP id q16so1778096bkw.28
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=4YcDt+GxlE5d+Wi5TzphU1EE1RgSIuFmQPipTGh4fGQ=;
	b=n8Vm+lz88h1TCdRNAV3NhfvMXR5KfrECPkBT0HzVU6QTa8BWS0IF7qDyK/T3qxSQUB
	19IGZHfWBswrQ2iWC9j1ukh8MKpAg4AYs5nRXvxqwaadxupJ/lliztxis4Y76xkst6A4
	0ZYDc8lo+oRShcwjQD11GgpZJjRyC5akwwGjEtcxoUFrQgzpXq+8uDyWGLOeI1/8P/sZ
	t7OX0xCvhS5Vf7QgrwmIkXGObQmidysuubizpN3SLtpsrERLk40oMd19pOE1X5Tb8mup
	moYSB91TaepzAUMiN59HiYJuoYGLPNE+VBSqnJztr/C9N4vM7fonidEFg23j47mfFdVW
	CcUA==
X-Received: by 10.205.120.15 with SMTP id fw15mr3208960bkc.108.1359716647194; 
	Fri, 01 Feb 2013 03:04:07 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.05
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4730a7efc2a8e76db29c85af3fe1267d664b1734
Message-Id: <4730a7efc2a8e76db29c.1359716480@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:20 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 10 of 11 v3] xl: add node-affinity to the output
	of `xl 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

Node-affinity is now something that is under (some) control of the
user, so show it upon request as part of the output of `xl list'
by the `-n' option.

Re the patch, the print_bitmap() related hunk is _mostly_ code motion,
although there is a very minor change in the code, basically to allow
using the function for printing both cpu and node bitmaps (as, in case
all bits are sets, it used to print "any cpu", which doesn't fit the
nodemap case).

This is how the output of `xl list', with various combination of
options, will look like after this change:

 http://pastebin.com/68kUuwyE

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
---
Changes from v1:
 * print_{cpu,node}map() functions added instead of 'state variable'-izing
   print_bitmap().

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
@@ -3014,14 +3014,95 @@ out:
     }
 }
 
-static void list_domains(int verbose, int context, const libxl_dominfo *info, int nb_domain)
+/* If map is not full, prints it and returns 0. Returns 1 otherwise. */
+static int print_bitmap(uint8_t *map, int maplen, FILE *stream)
+{
+    int i;
+    uint8_t pmap = 0, bitmask = 0;
+    int firstset = 0, state = 0;
+
+    for (i = 0; i < maplen; i++) {
+        if (i % 8 == 0) {
+            pmap = *map++;
+            bitmask = 1;
+        } else bitmask <<= 1;
+
+        switch (state) {
+        case 0:
+        case 2:
+            if ((pmap & bitmask) != 0) {
+                firstset = i;
+                state++;
+            }
+            continue;
+        case 1:
+        case 3:
+            if ((pmap & bitmask) == 0) {
+                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+                if (i - 1 > firstset)
+                    fprintf(stream, "-%d", i - 1);
+                state = 2;
+            }
+            continue;
+        }
+    }
+    switch (state) {
+        case 0:
+            fprintf(stream, "none");
+            break;
+        case 2:
+            break;
+        case 1:
+            if (firstset == 0)
+                return 1;
+        case 3:
+            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+            if (i - 1 > firstset)
+                fprintf(stream, "-%d", i - 1);
+            break;
+    }
+
+    return 0;
+}
+
+static void print_cpumap(uint8_t *map, int maplen, FILE *stream)
+{
+    if (print_bitmap(map, maplen, stream))
+        fprintf(stream, "any cpu");
+}
+
+static void print_nodemap(uint8_t *map, int maplen, FILE *stream)
+{
+    if (print_bitmap(map, maplen, stream))
+        fprintf(stream, "any node");
+}
+
+static void list_domains(int verbose, int context, int numa, const libxl_dominfo *info, int nb_domain)
 {
     int i;
     static const char shutdown_reason_letters[]= "-rscw";
+    libxl_bitmap nodemap;
+    libxl_physinfo physinfo;
+
+    libxl_bitmap_init(&nodemap);
+    libxl_physinfo_init(&physinfo);
 
     printf("Name                                        ID   Mem VCPUs\tState\tTime(s)");
     if (verbose) printf("   UUID                            Reason-Code\tSecurity Label");
     if (context && !verbose) printf("   Security Label");
+    if (numa) {
+        if (libxl_node_bitmap_alloc(ctx, &nodemap, 0)) {
+            fprintf(stderr, "libxl_node_bitmap_alloc_failed.\n");
+            exit(1);
+        }
+        if (libxl_get_physinfo(ctx, &physinfo) != 0) {
+            fprintf(stderr, "libxl_physinfo failed.\n");
+            libxl_bitmap_dispose(&nodemap);
+            exit(1);
+        }
+
+        printf(" NODE Affinity");
+    }
     printf("\n");
     for (i = 0; i < nb_domain; i++) {
         char *domname;
@@ -3055,14 +3136,23 @@ static void list_domains(int verbose, in
             rc = libxl_flask_sid_to_context(ctx, info[i].ssidref, &buf,
                                             &size);
             if (rc < 0)
-                printf("  -");
+                printf("                -");
             else {
-                printf("  %s", buf);
+                printf(" %16s", buf);
                 free(buf);
             }
         }
+        if (numa) {
+            libxl_domain_get_nodeaffinity(ctx, info[i].domid, &nodemap);
+
+            putchar(' ');
+            print_nodemap(nodemap.map, physinfo.nr_nodes, stdout);
+        }
         putchar('\n');
     }
+
+    libxl_bitmap_dispose(&nodemap);
+    libxl_physinfo_dispose(&physinfo);
 }
 
 static void list_vm(void)
@@ -3922,10 +4012,12 @@ int main_list(int argc, char **argv)
     int opt, verbose = 0;
     int context = 0;
     int details = 0;
+    int numa = 0;
     static struct option opts[] = {
         {"long", 0, 0, 'l'},
         {"verbose", 0, 0, 'v'},
         {"context", 0, 0, 'Z'},
+        {"numa", 0, 0, 'n'},
         COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
@@ -3934,7 +4026,7 @@ int main_list(int argc, char **argv)
     libxl_dominfo *info, *info_free=0;
     int nb_domain, rc;
 
-    SWITCH_FOREACH_OPT(opt, "lvhZ", opts, "list", 0) {
+    SWITCH_FOREACH_OPT(opt, "lvhZn", opts, "list", 0) {
     case 'l':
         details = 1;
         break;
@@ -3944,6 +4036,9 @@ int main_list(int argc, char **argv)
     case 'Z':
         context = 1;
         break;
+    case 'n':
+        numa = 1;
+        break;
     }
 
     if (optind >= argc) {
@@ -3975,7 +4070,7 @@ int main_list(int argc, char **argv)
     if (details)
         list_domains_details(info, nb_domain);
     else
-        list_domains(verbose, context, info, nb_domain);
+        list_domains(verbose, context, numa, info, nb_domain);
 
     if (info_free)
         libxl_dominfo_list_free(info, nb_domain);
@@ -4224,56 +4319,6 @@ int main_button_press(int argc, char **a
     return 0;
 }
 
-static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
-{
-    int i;
-    uint8_t pmap = 0, bitmask = 0;
-    int firstset = 0, state = 0;
-
-    for (i = 0; i < maplen; i++) {
-        if (i % 8 == 0) {
-            pmap = *map++;
-            bitmask = 1;
-        } else bitmask <<= 1;
-
-        switch (state) {
-        case 0:
-        case 2:
-            if ((pmap & bitmask) != 0) {
-                firstset = i;
-                state++;
-            }
-            continue;
-        case 1:
-        case 3:
-            if ((pmap & bitmask) == 0) {
-                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-                if (i - 1 > firstset)
-                    fprintf(stream, "-%d", i - 1);
-                state = 2;
-            }
-            continue;
-        }
-    }
-    switch (state) {
-        case 0:
-            fprintf(stream, "none");
-            break;
-        case 2:
-            break;
-        case 1:
-            if (firstset == 0) {
-                fprintf(stream, "any cpu");
-                break;
-            }
-        case 3:
-            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-            if (i - 1 > firstset)
-                fprintf(stream, "-%d", i - 1);
-            break;
-    }
-}
-
 static void print_vcpuinfo(uint32_t tdomid,
                            const libxl_vcpuinfo *vcpuinfo,
                            uint32_t nr_cpus)
@@ -4297,7 +4342,7 @@ static void print_vcpuinfo(uint32_t tdom
     /*      TIM */
     printf("%9.1f  ", ((float)vcpuinfo->vcpu_time / 1e9));
     /* CPU AFFINITY */
-    print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout);
+    print_cpumap(vcpuinfo->cpumap.map, nr_cpus, stdout);
     printf("\n");
 }
 
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
@@ -50,7 +50,8 @@ struct cmd_spec cmd_table[] = {
       "[options] [Domain]\n",
       "-l, --long              Output all VM details\n"
       "-v, --verbose           Prints out UUIDs and security context\n"
-      "-Z, --context           Prints out security context"
+      "-Z, --context           Prints out security context\n"
+      "-n, --numa              Prints out NUMA node affinity"
     },
     { "destroy",
       &main_destroy, 0, 1,

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:04:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EQ0-0004mh-7b; Fri, 01 Feb 2013 11:04:28 +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 1U1EPy-0004lG-8u
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:04:26 +0000
Received: from [85.158.139.83:18016] by server-15.bemta-5.messagelabs.com id
	73/6F-18914-931AB015; Fri, 01 Feb 2013 11:04:25 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1359716647!30390995!1
X-Originating-IP: [209.85.214.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20425 invoked from network); 1 Feb 2013 11:04:07 -0000
Received: from mail-bk0-f41.google.com (HELO mail-bk0-f41.google.com)
	(209.85.214.41)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:04:07 -0000
Received: by mail-bk0-f41.google.com with SMTP id q16so1778096bkw.28
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 03:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=4YcDt+GxlE5d+Wi5TzphU1EE1RgSIuFmQPipTGh4fGQ=;
	b=n8Vm+lz88h1TCdRNAV3NhfvMXR5KfrECPkBT0HzVU6QTa8BWS0IF7qDyK/T3qxSQUB
	19IGZHfWBswrQ2iWC9j1ukh8MKpAg4AYs5nRXvxqwaadxupJ/lliztxis4Y76xkst6A4
	0ZYDc8lo+oRShcwjQD11GgpZJjRyC5akwwGjEtcxoUFrQgzpXq+8uDyWGLOeI1/8P/sZ
	t7OX0xCvhS5Vf7QgrwmIkXGObQmidysuubizpN3SLtpsrERLk40oMd19pOE1X5Tb8mup
	moYSB91TaepzAUMiN59HiYJuoYGLPNE+VBSqnJztr/C9N4vM7fonidEFg23j47mfFdVW
	CcUA==
X-Received: by 10.205.120.15 with SMTP id fw15mr3208960bkc.108.1359716647194; 
	Fri, 01 Feb 2013 03:04:07 -0800 (PST)
Received: from [127.0.1.1] (ip-143-60.sn1.eutelia.it. [62.94.143.60])
	by mx.google.com with ESMTPS id s10sm2768104bkt.10.2013.02.01.03.04.05
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 03:04:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4730a7efc2a8e76db29c85af3fe1267d664b1734
Message-Id: <4730a7efc2a8e76db29c.1359716480@Solace>
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 01 Feb 2013 12:01:20 +0100
From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH 10 of 11 v3] xl: add node-affinity to the output
	of `xl 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

Node-affinity is now something that is under (some) control of the
user, so show it upon request as part of the output of `xl list'
by the `-n' option.

Re the patch, the print_bitmap() related hunk is _mostly_ code motion,
although there is a very minor change in the code, basically to allow
using the function for printing both cpu and node bitmaps (as, in case
all bits are sets, it used to print "any cpu", which doesn't fit the
nodemap case).

This is how the output of `xl list', with various combination of
options, will look like after this change:

 http://pastebin.com/68kUuwyE

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
---
Changes from v1:
 * print_{cpu,node}map() functions added instead of 'state variable'-izing
   print_bitmap().

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
@@ -3014,14 +3014,95 @@ out:
     }
 }
 
-static void list_domains(int verbose, int context, const libxl_dominfo *info, int nb_domain)
+/* If map is not full, prints it and returns 0. Returns 1 otherwise. */
+static int print_bitmap(uint8_t *map, int maplen, FILE *stream)
+{
+    int i;
+    uint8_t pmap = 0, bitmask = 0;
+    int firstset = 0, state = 0;
+
+    for (i = 0; i < maplen; i++) {
+        if (i % 8 == 0) {
+            pmap = *map++;
+            bitmask = 1;
+        } else bitmask <<= 1;
+
+        switch (state) {
+        case 0:
+        case 2:
+            if ((pmap & bitmask) != 0) {
+                firstset = i;
+                state++;
+            }
+            continue;
+        case 1:
+        case 3:
+            if ((pmap & bitmask) == 0) {
+                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+                if (i - 1 > firstset)
+                    fprintf(stream, "-%d", i - 1);
+                state = 2;
+            }
+            continue;
+        }
+    }
+    switch (state) {
+        case 0:
+            fprintf(stream, "none");
+            break;
+        case 2:
+            break;
+        case 1:
+            if (firstset == 0)
+                return 1;
+        case 3:
+            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+            if (i - 1 > firstset)
+                fprintf(stream, "-%d", i - 1);
+            break;
+    }
+
+    return 0;
+}
+
+static void print_cpumap(uint8_t *map, int maplen, FILE *stream)
+{
+    if (print_bitmap(map, maplen, stream))
+        fprintf(stream, "any cpu");
+}
+
+static void print_nodemap(uint8_t *map, int maplen, FILE *stream)
+{
+    if (print_bitmap(map, maplen, stream))
+        fprintf(stream, "any node");
+}
+
+static void list_domains(int verbose, int context, int numa, const libxl_dominfo *info, int nb_domain)
 {
     int i;
     static const char shutdown_reason_letters[]= "-rscw";
+    libxl_bitmap nodemap;
+    libxl_physinfo physinfo;
+
+    libxl_bitmap_init(&nodemap);
+    libxl_physinfo_init(&physinfo);
 
     printf("Name                                        ID   Mem VCPUs\tState\tTime(s)");
     if (verbose) printf("   UUID                            Reason-Code\tSecurity Label");
     if (context && !verbose) printf("   Security Label");
+    if (numa) {
+        if (libxl_node_bitmap_alloc(ctx, &nodemap, 0)) {
+            fprintf(stderr, "libxl_node_bitmap_alloc_failed.\n");
+            exit(1);
+        }
+        if (libxl_get_physinfo(ctx, &physinfo) != 0) {
+            fprintf(stderr, "libxl_physinfo failed.\n");
+            libxl_bitmap_dispose(&nodemap);
+            exit(1);
+        }
+
+        printf(" NODE Affinity");
+    }
     printf("\n");
     for (i = 0; i < nb_domain; i++) {
         char *domname;
@@ -3055,14 +3136,23 @@ static void list_domains(int verbose, in
             rc = libxl_flask_sid_to_context(ctx, info[i].ssidref, &buf,
                                             &size);
             if (rc < 0)
-                printf("  -");
+                printf("                -");
             else {
-                printf("  %s", buf);
+                printf(" %16s", buf);
                 free(buf);
             }
         }
+        if (numa) {
+            libxl_domain_get_nodeaffinity(ctx, info[i].domid, &nodemap);
+
+            putchar(' ');
+            print_nodemap(nodemap.map, physinfo.nr_nodes, stdout);
+        }
         putchar('\n');
     }
+
+    libxl_bitmap_dispose(&nodemap);
+    libxl_physinfo_dispose(&physinfo);
 }
 
 static void list_vm(void)
@@ -3922,10 +4012,12 @@ int main_list(int argc, char **argv)
     int opt, verbose = 0;
     int context = 0;
     int details = 0;
+    int numa = 0;
     static struct option opts[] = {
         {"long", 0, 0, 'l'},
         {"verbose", 0, 0, 'v'},
         {"context", 0, 0, 'Z'},
+        {"numa", 0, 0, 'n'},
         COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
@@ -3934,7 +4026,7 @@ int main_list(int argc, char **argv)
     libxl_dominfo *info, *info_free=0;
     int nb_domain, rc;
 
-    SWITCH_FOREACH_OPT(opt, "lvhZ", opts, "list", 0) {
+    SWITCH_FOREACH_OPT(opt, "lvhZn", opts, "list", 0) {
     case 'l':
         details = 1;
         break;
@@ -3944,6 +4036,9 @@ int main_list(int argc, char **argv)
     case 'Z':
         context = 1;
         break;
+    case 'n':
+        numa = 1;
+        break;
     }
 
     if (optind >= argc) {
@@ -3975,7 +4070,7 @@ int main_list(int argc, char **argv)
     if (details)
         list_domains_details(info, nb_domain);
     else
-        list_domains(verbose, context, info, nb_domain);
+        list_domains(verbose, context, numa, info, nb_domain);
 
     if (info_free)
         libxl_dominfo_list_free(info, nb_domain);
@@ -4224,56 +4319,6 @@ int main_button_press(int argc, char **a
     return 0;
 }
 
-static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
-{
-    int i;
-    uint8_t pmap = 0, bitmask = 0;
-    int firstset = 0, state = 0;
-
-    for (i = 0; i < maplen; i++) {
-        if (i % 8 == 0) {
-            pmap = *map++;
-            bitmask = 1;
-        } else bitmask <<= 1;
-
-        switch (state) {
-        case 0:
-        case 2:
-            if ((pmap & bitmask) != 0) {
-                firstset = i;
-                state++;
-            }
-            continue;
-        case 1:
-        case 3:
-            if ((pmap & bitmask) == 0) {
-                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-                if (i - 1 > firstset)
-                    fprintf(stream, "-%d", i - 1);
-                state = 2;
-            }
-            continue;
-        }
-    }
-    switch (state) {
-        case 0:
-            fprintf(stream, "none");
-            break;
-        case 2:
-            break;
-        case 1:
-            if (firstset == 0) {
-                fprintf(stream, "any cpu");
-                break;
-            }
-        case 3:
-            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-            if (i - 1 > firstset)
-                fprintf(stream, "-%d", i - 1);
-            break;
-    }
-}
-
 static void print_vcpuinfo(uint32_t tdomid,
                            const libxl_vcpuinfo *vcpuinfo,
                            uint32_t nr_cpus)
@@ -4297,7 +4342,7 @@ static void print_vcpuinfo(uint32_t tdom
     /*      TIM */
     printf("%9.1f  ", ((float)vcpuinfo->vcpu_time / 1e9));
     /* CPU AFFINITY */
-    print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout);
+    print_cpumap(vcpuinfo->cpumap.map, nr_cpus, stdout);
     printf("\n");
 }
 
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
@@ -50,7 +50,8 @@ struct cmd_spec cmd_table[] = {
       "[options] [Domain]\n",
       "-l, --long              Output all VM details\n"
       "-v, --verbose           Prints out UUIDs and security context\n"
-      "-Z, --context           Prints out security context"
+      "-Z, --context           Prints out security context\n"
+      "-n, --numa              Prints out NUMA node affinity"
     },
     { "destroy",
       &main_destroy, 0, 1,

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:06:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:06: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 1U1ERi-0005gc-QK; Fri, 01 Feb 2013 11:06:14 +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 1U1ERh-0005gC-UN
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:06:14 +0000
Received: from [85.158.139.211:47138] by server-14.bemta-5.messagelabs.com id
	2D/ED-06967-5A1AB015; Fri, 01 Feb 2013 11:06:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1359716769!20235603!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27255 invoked from network); 1 Feb 2013 11:06:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:06:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5935555"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:06:08 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:06:08 -0500
Message-ID: <510BA19F.6010900@citrix.com>
Date: Fri, 1 Feb 2013 11:06:07 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> Four things are fixed:
>  a) the test result of globaly masked event;
>  b) make the per-cpu selector L1 to be consistent with description in
>     __xen_evtchn_do_upcall's comment;
>  c) the test result of L1 selector;
>  d) add KERN_DEBUG in printk.

It's hard to pick out the correctness fixes with all the cosmetic
KERN_DEBUG fixes in the same patch.

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   34 +++++++++++++++++-----------------
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..2c94aad 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
[...]
> +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +					     ? "" : " l1-clear",

This looks backwards now.

> +			       sync_test_bit(i, sh->evtchn_mask)
>  					     ? "" : " globally-masked",
>  			       sync_test_bit(i, cpu_evtchn)
>  					     ? "" : " locally-masked");

David


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:06:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:06: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 1U1ERi-0005gc-QK; Fri, 01 Feb 2013 11:06:14 +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 1U1ERh-0005gC-UN
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:06:14 +0000
Received: from [85.158.139.211:47138] by server-14.bemta-5.messagelabs.com id
	2D/ED-06967-5A1AB015; Fri, 01 Feb 2013 11:06:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1359716769!20235603!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27255 invoked from network); 1 Feb 2013 11:06:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:06:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5935555"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:06:08 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:06:08 -0500
Message-ID: <510BA19F.6010900@citrix.com>
Date: Fri, 1 Feb 2013 11:06:07 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> Four things are fixed:
>  a) the test result of globaly masked event;
>  b) make the per-cpu selector L1 to be consistent with description in
>     __xen_evtchn_do_upcall's comment;
>  c) the test result of L1 selector;
>  d) add KERN_DEBUG in printk.

It's hard to pick out the correctness fixes with all the cosmetic
KERN_DEBUG fixes in the same patch.

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   34 +++++++++++++++++-----------------
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..2c94aad 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
[...]
> +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +					     ? "" : " l1-clear",

This looks backwards now.

> +			       sync_test_bit(i, sh->evtchn_mask)
>  					     ? "" : " globally-masked",
>  			       sync_test_bit(i, cpu_evtchn)
>  					     ? "" : " locally-masked");

David


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:15:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:15: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 1U1EaO-0006UP-Tp; Fri, 01 Feb 2013 11:15:12 +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 1U1EaN-0006UK-Ez
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:15:11 +0000
Received: from [85.158.138.51:6986] by server-9.bemta-3.messagelabs.com id
	10/B9-09484-EB3AB015; Fri, 01 Feb 2013 11:15:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359717302!28778887!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22681 invoked from network); 1 Feb 2013 11:15:04 -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;
	1 Feb 2013 11:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5644274"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:15:02 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:15:01 -0500
Message-ID: <510BA3B4.4010104@citrix.com>
Date: Fri, 1 Feb 2013 11:15:00 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/13] xen: fix evtchn_unbind_from_user
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> It is possible the port was allocated but the irq was not. Take care of this
> case.

I think the port should be closed when the evtchn_bind_to_user() fails
otherwise the evtchn driver is leaving the event channel in an
inconsistent state.

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/evtchn.c |   12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index b1f60a0..d2bbea1 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -277,7 +277,17 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
>  {
>  	int irq = irq_from_evtchn(port);
>  
> -	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> +	/* It is possible that the port was allocated but the irq was
> +	 * not */
> +	if (irq >= 0) {
> +		unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> +	} else {
> +		struct evtchn_close close;
> +		close.port = port;
> +		if (port != 0 && /* port 0 is never used */
> +		    HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> +			BUG();
> +	}
>  
>  	set_port_user(port, NULL);
>  }


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:15:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:15: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 1U1EaO-0006UP-Tp; Fri, 01 Feb 2013 11:15:12 +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 1U1EaN-0006UK-Ez
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:15:11 +0000
Received: from [85.158.138.51:6986] by server-9.bemta-3.messagelabs.com id
	10/B9-09484-EB3AB015; Fri, 01 Feb 2013 11:15:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359717302!28778887!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22681 invoked from network); 1 Feb 2013 11:15:04 -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;
	1 Feb 2013 11:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5644274"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:15:02 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:15:01 -0500
Message-ID: <510BA3B4.4010104@citrix.com>
Date: Fri, 1 Feb 2013 11:15:00 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/13] xen: fix evtchn_unbind_from_user
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> It is possible the port was allocated but the irq was not. Take care of this
> case.

I think the port should be closed when the evtchn_bind_to_user() fails
otherwise the evtchn driver is leaving the event channel in an
inconsistent state.

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/evtchn.c |   12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index b1f60a0..d2bbea1 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -277,7 +277,17 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
>  {
>  	int irq = irq_from_evtchn(port);
>  
> -	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> +	/* It is possible that the port was allocated but the irq was
> +	 * not */
> +	if (irq >= 0) {
> +		unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> +	} else {
> +		struct evtchn_close close;
> +		close.port = port;
> +		if (port != 0 && /* port 0 is never used */
> +		    HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> +			BUG();
> +	}
>  
>  	set_port_user(port, NULL);
>  }


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:20:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:20: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 1U1Eev-0006eR-SJ; Fri, 01 Feb 2013 11:19:53 +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 1U1Eeu-0006eJ-0G
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:19:52 +0000
Received: from [193.109.254.147:40419] by server-8.bemta-14.messagelabs.com id
	BC/20-17325-6D4AB015; Fri, 01 Feb 2013 11:19:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1359717589!9218554!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26256 invoked from network); 1 Feb 2013 11:19:50 -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;
	1 Feb 2013 11:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5644679"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:19:48 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:19:48 -0500
Message-ID: <510BA4D3.9010505@citrix.com>
Date: Fri, 1 Feb 2013 11:19:47 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> It is possible that the call to xen_allocate_irq_dynamic() returns negative
> number other than -1.

Yes, this ultimately calls__irq_alloc_descs() which returns -ve error codes.

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Cc: stable@vger.kernel.org perhaps?

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:20:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:20: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 1U1Eev-0006eR-SJ; Fri, 01 Feb 2013 11:19:53 +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 1U1Eeu-0006eJ-0G
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:19:52 +0000
Received: from [193.109.254.147:40419] by server-8.bemta-14.messagelabs.com id
	BC/20-17325-6D4AB015; Fri, 01 Feb 2013 11:19:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1359717589!9218554!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26256 invoked from network); 1 Feb 2013 11:19:50 -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;
	1 Feb 2013 11:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5644679"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:19:48 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:19:48 -0500
Message-ID: <510BA4D3.9010505@citrix.com>
Date: Fri, 1 Feb 2013 11:19:47 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> It is possible that the call to xen_allocate_irq_dynamic() returns negative
> number other than -1.

Yes, this ultimately calls__irq_alloc_descs() which returns -ve error codes.

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Cc: stable@vger.kernel.org perhaps?

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:26:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:26: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 1U1ElP-0006ry-Pi; Fri, 01 Feb 2013 11:26: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 1U1ElO-0006rt-52
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:26:34 +0000
Received: from [193.109.254.147:46650] by server-8.bemta-14.messagelabs.com id
	41/F7-17325-966AB015; Fri, 01 Feb 2013 11:26:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1359717987!3350466!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13833 invoked from network); 1 Feb 2013 11:26:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:26:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1061409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 11:26: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.297.1; Fri, 1 Feb 2013
	11:26:27 +0000
Message-ID: <1359717986.9063.30.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 1 Feb 2013 11:26:26 +0000
In-Reply-To: <1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-31 at 14:46 +0000, Wei Liu wrote:
> It is possible that the call to xen_allocate_irq_dynamic() returns negative
> number other than -1.

Hopefully this means it always returns -ERRNO, rather than a mixture of
-ERRNO and literal -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 Feb 01 11:26:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:26: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 1U1ElP-0006ry-Pi; Fri, 01 Feb 2013 11:26: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 1U1ElO-0006rt-52
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:26:34 +0000
Received: from [193.109.254.147:46650] by server-8.bemta-14.messagelabs.com id
	41/F7-17325-966AB015; Fri, 01 Feb 2013 11:26:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1359717987!3350466!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13833 invoked from network); 1 Feb 2013 11:26:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:26:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1061409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 11:26: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.297.1; Fri, 1 Feb 2013
	11:26:27 +0000
Message-ID: <1359717986.9063.30.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 1 Feb 2013 11:26:26 +0000
In-Reply-To: <1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-31 at 14:46 +0000, Wei Liu wrote:
> It is possible that the call to xen_allocate_irq_dynamic() returns negative
> number other than -1.

Hopefully this means it always returns -ERRNO, rather than a mixture of
-ERRNO and literal -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 Feb 01 11:29:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EoN-00070B-Hi; Fri, 01 Feb 2013 11:29: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 1U1EoK-0006zq-Va
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:29:38 +0000
Received: from [85.158.143.99:30180] by server-1.bemta-4.messagelabs.com id
	90/82-08839-027AB015; Fri, 01 Feb 2013 11:29:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1359718174!30423622!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31140 invoked from network); 1 Feb 2013 11:29:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5938329"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:29:34 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:29:33 -0500
Message-ID: <510BA71C.7030303@citrix.com>
Date: Fri, 1 Feb 2013 11:29:32 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-9-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-9-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/13] xen: dynamically allocate
	cpu_evtchn_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:47, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 4820a52..30ca620 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
[...]
> +	for_each_possible_cpu(cpu) {
> +		void *p;
> +		unsigned int nr = nr_event_channels / BITS_PER_LONG;
> +
> +		p = kzalloc_node(sizeof(unsigned long) * nr,
> +				 GFP_KERNEL,
> +				 cpu_to_node(cpu));
> +		if (!p)
> +			p = kzalloc(sizeof(unsigned long) * nr,
> +				    GFP_KERNEL);

kzalloc_node() will fallback to allocating from other nodes, no need to
try as well.

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:29:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1EoN-00070B-Hi; Fri, 01 Feb 2013 11:29: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 1U1EoK-0006zq-Va
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:29:38 +0000
Received: from [85.158.143.99:30180] by server-1.bemta-4.messagelabs.com id
	90/82-08839-027AB015; Fri, 01 Feb 2013 11:29:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1359718174!30423622!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31140 invoked from network); 1 Feb 2013 11:29:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5938329"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:29:34 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:29:33 -0500
Message-ID: <510BA71C.7030303@citrix.com>
Date: Fri, 1 Feb 2013 11:29:32 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-9-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-9-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/13] xen: dynamically allocate
	cpu_evtchn_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:47, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 4820a52..30ca620 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
[...]
> +	for_each_possible_cpu(cpu) {
> +		void *p;
> +		unsigned int nr = nr_event_channels / BITS_PER_LONG;
> +
> +		p = kzalloc_node(sizeof(unsigned long) * nr,
> +				 GFP_KERNEL,
> +				 cpu_to_node(cpu));
> +		if (!p)
> +			p = kzalloc(sizeof(unsigned long) * nr,
> +				    GFP_KERNEL);

kzalloc_node() will fallback to allocating from other nodes, no need to
try as well.

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:32:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 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 1U1EqT-00079U-5M; Fri, 01 Feb 2013 11:31: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 1U1EqS-00078x-3w
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:31:48 +0000
Received: from [85.158.137.99:2305] by server-13.bemta-3.messagelabs.com id
	88/E5-20653-E97AB015; Fri, 01 Feb 2013 11:31:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1359718289!18478006!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2811 invoked from network); 1 Feb 2013 11:31:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:31:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5645417"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:31:29 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:31:28 -0500
Message-ID: <510BA78F.1040204@citrix.com>
Date: Fri, 1 Feb 2013 11:31:27 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-13-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 12/13] xen: register 3-level 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 31/01/13 14:47, Wei Liu wrote:
> 3-level event channel is registered in
>  a) xen_init_IRQ(), when the guest is fresh started;
>  b) xen_vcpu_restore(), when the guest is restored.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  arch/x86/xen/enlighten.c |   13 +++++++++++++
>  drivers/xen/events.c     |   11 ++++++++++-
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index bc893e7..919c7ed 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
[...]
> +
> +	rc = xen_event_channel_register_nlevel(3);
> +	if (!rc) {
> +		printk(KERN_INFO "Register 3-level event channel succeeded.\n");
> +		xen_set_event_channel_nlevel(3);
> +	} else {
> +		printk(KERN_INFO "Register 3-level event channel failed with %d.\n"
> +		       "Fall back to default 2-level event channel.\n",
> +		       rc);
> +		xen_set_event_channel_nlevel(2);
> +	}

You should have a function for this, instead of copy-and-paste in two
different places.

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:32:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 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 1U1EqT-00079U-5M; Fri, 01 Feb 2013 11:31: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 1U1EqS-00078x-3w
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:31:48 +0000
Received: from [85.158.137.99:2305] by server-13.bemta-3.messagelabs.com id
	88/E5-20653-E97AB015; Fri, 01 Feb 2013 11:31:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1359718289!18478006!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2811 invoked from network); 1 Feb 2013 11:31:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:31:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5645417"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:31:29 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:31:28 -0500
Message-ID: <510BA78F.1040204@citrix.com>
Date: Fri, 1 Feb 2013 11:31:27 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-13-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 12/13] xen: register 3-level 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 31/01/13 14:47, Wei Liu wrote:
> 3-level event channel is registered in
>  a) xen_init_IRQ(), when the guest is fresh started;
>  b) xen_vcpu_restore(), when the guest is restored.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  arch/x86/xen/enlighten.c |   13 +++++++++++++
>  drivers/xen/events.c     |   11 ++++++++++-
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index bc893e7..919c7ed 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
[...]
> +
> +	rc = xen_event_channel_register_nlevel(3);
> +	if (!rc) {
> +		printk(KERN_INFO "Register 3-level event channel succeeded.\n");
> +		xen_set_event_channel_nlevel(3);
> +	} else {
> +		printk(KERN_INFO "Register 3-level event channel failed with %d.\n"
> +		       "Fall back to default 2-level event channel.\n",
> +		       rc);
> +		xen_set_event_channel_nlevel(2);
> +	}

You should have a function for this, instead of copy-and-paste in two
different places.

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:37:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:37: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 1U1Ew3-0007S6-SH; Fri, 01 Feb 2013 11:37: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 1U1Ew2-0007Rv-LW
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:37:34 +0000
Received: from [85.158.143.35:36845] by server-2.bemta-4.messagelabs.com id
	64/2C-01597-DF8AB015; Fri, 01 Feb 2013 11:37:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1359718521!5224139!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9942 invoked from network); 1 Feb 2013 11:35:23 -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;
	1 Feb 2013 11:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5645716"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:35:21 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:35:21 -0500
Message-ID: <510BA877.40200@citrix.com>
Date: Fri, 1 Feb 2013 11:35:19 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-6-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-6-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/13] xen: introduce test_and_set_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 93a3648..0fae3f9 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -345,6 +345,12 @@ static inline int test_evtchn(int port)
>  	return sync_test_bit(port, &s->evtchn_pending[0]);
>  }
>  
> +static inline int test_and_set_mask(int port)

This name is too generic.  Suggest test_and_set_evtchn_mask() or similar.

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:37:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:37: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 1U1Ew3-0007S6-SH; Fri, 01 Feb 2013 11:37: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 1U1Ew2-0007Rv-LW
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 11:37:34 +0000
Received: from [85.158.143.35:36845] by server-2.bemta-4.messagelabs.com id
	64/2C-01597-DF8AB015; Fri, 01 Feb 2013 11:37:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1359718521!5224139!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9942 invoked from network); 1 Feb 2013 11:35:23 -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;
	1 Feb 2013 11:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5645716"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 11:35:21 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Fri, 1 Feb 2013
	06:35:21 -0500
Message-ID: <510BA877.40200@citrix.com>
Date: Fri, 1 Feb 2013 11:35:19 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-6-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-6-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/13] xen: introduce test_and_set_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 31/01/13 14:46, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 93a3648..0fae3f9 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -345,6 +345,12 @@ static inline int test_evtchn(int port)
>  	return sync_test_bit(port, &s->evtchn_pending[0]);
>  }
>  
> +static inline int test_and_set_mask(int port)

This name is too generic.  Suggest test_and_set_evtchn_mask() or similar.

David

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:44:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:44: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 1U1F2p-0007p0-Qc; Fri, 01 Feb 2013 11: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.Jackson@eu.citrix.com>) id 1U1F2o-0007ov-9N
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 11:44:34 +0000
Received: from [85.158.137.99:64291] by server-4.bemta-3.messagelabs.com id
	9B/2D-12802-1AAAB015; Fri, 01 Feb 2013 11:44:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1359719070!16360526!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28247 invoked from network); 1 Feb 2013 11:44:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:44:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1062043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 11:44: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.297.1; Fri, 1 Feb 2013 11:44:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U1F2k-0003Bk-8O; Fri, 01 Feb 2013 11:44:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U1F2k-00027w-1v;
	Fri, 01 Feb 2013 11:44:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20747.43677.802351.664975@mariner.uk.xensource.com>
Date: Fri, 1 Feb 2013 11:44:29 +0000
To: Keir Fraser <keir.xen@gmail.com>,
    Jan Beulich <JBeulich@suse.com>
In-Reply-To: <osstest-15401-mainreport@xen.org>
References: <osstest-15401-mainreport@xen.org>
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] [xen-unstable test] 15401: 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

xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
> flight 15401 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179

With some handholding, I managed to get the bisector to work on this.
It found that the original "good" version is unreliable: it built Xen
5af4f2ab06f3 and in two recent tests on the same host, of the same
build, it failed once and passed once.

Under the circumstances it's not clear that the current staging is any
worse than non-staging.  I think we should push the revision reported
in this test (which was otherwise OK according to the tester) to
non-staging, with a manual "hg push".

> version targeted for testing:
>  xen                  d1bf3b21f783

I'm not sure how to do this with hg and have to go catch a train so I
don't have time to look it up, but presumably there's some rune of the
form "hg push -r d1bf3b21f783 ssh://xenbits/xen-unstable.hg"

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 Feb 01 11:44:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:44: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 1U1F2p-0007p0-Qc; Fri, 01 Feb 2013 11: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.Jackson@eu.citrix.com>) id 1U1F2o-0007ov-9N
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 11:44:34 +0000
Received: from [85.158.137.99:64291] by server-4.bemta-3.messagelabs.com id
	9B/2D-12802-1AAAB015; Fri, 01 Feb 2013 11:44:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1359719070!16360526!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28247 invoked from network); 1 Feb 2013 11:44:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:44:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1062043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 11:44: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.297.1; Fri, 1 Feb 2013 11:44:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U1F2k-0003Bk-8O; Fri, 01 Feb 2013 11:44:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U1F2k-00027w-1v;
	Fri, 01 Feb 2013 11:44:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20747.43677.802351.664975@mariner.uk.xensource.com>
Date: Fri, 1 Feb 2013 11:44:29 +0000
To: Keir Fraser <keir.xen@gmail.com>,
    Jan Beulich <JBeulich@suse.com>
In-Reply-To: <osstest-15401-mainreport@xen.org>
References: <osstest-15401-mainreport@xen.org>
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] [xen-unstable test] 15401: 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

xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
> flight 15401 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179

With some handholding, I managed to get the bisector to work on this.
It found that the original "good" version is unreliable: it built Xen
5af4f2ab06f3 and in two recent tests on the same host, of the same
build, it failed once and passed once.

Under the circumstances it's not clear that the current staging is any
worse than non-staging.  I think we should push the revision reported
in this test (which was otherwise OK according to the tester) to
non-staging, with a manual "hg push".

> version targeted for testing:
>  xen                  d1bf3b21f783

I'm not sure how to do this with hg and have to go catch a train so I
don't have time to look it up, but presumably there's some rune of the
form "hg push -r d1bf3b21f783 ssh://xenbits/xen-unstable.hg"

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 Feb 01 11:52:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:52: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 1U1FAM-000834-5R; Fri, 01 Feb 2013 11:52:22 +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 1U1FAL-00082z-6G
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 11:52:21 +0000
Received: from [85.158.138.51:9836] by server-12.bemta-3.messagelabs.com id
	88/8C-05889-47CAB015; Fri, 01 Feb 2013 11:52:20 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1359719530!30547083!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23854 invoked from network); 1 Feb 2013 11:52:10 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 11:52:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 37CCE400476;
	Fri,  1 Feb 2013 12:52:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id HX7Layh72-su; Fri,  1 Feb 2013 12:52:09 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 122CF4002A6;
	Fri,  1 Feb 2013 12:52:08 +0100 (CET)
Message-ID: <510BAC65.7080505@tiscali.it>
Date: Fri, 01 Feb 2013 12:52:05 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <50F036FA.9090500@tiscali.it>
	<alpine.DEB.2.02.1301141244460.4978@kaball.uk.xensource.com>
	<50F41548.1010508@tiscali.it>
	<alpine.DEB.2.02.1301141818360.4978@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1301141818360.4978@kaball.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v3] tools/libxl: Improve videoram setting
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="===============4723474397795133221=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4723474397795133221==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030207080204060503070104"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030207080204060503070104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 14/01/2013 19:21, Stefano Stabellini ha scritto:
> I did a quick test and it seems that it should be possible to change=20
> the amount of videoram for stdvga too using the same command line=20
> option, however at the moment it just errors out. Therefore I am OK=20
> with this patch only taking care of Cirrus for the moment.=20
I found details about stdvga on qemu upstream:
http://xenbits.xen.org/gitweb/?p=3Dstaging/qemu-upstream-unstable.git;a=3D=
blob_plain;f=3Ddocs/specs/standard-vga.txt;hb=3DHEAD

It seems that stdvga memory by default is 16 mb, while xen reserves only =

8 mb by default and doen't logs any error.
For cirrus, increasing memory seems to be correct and without error with =

my patch.
WIth both cirrus and stdvga under qemu upstream with xen the performance =

are really poor even if I increase video memory, respect to qemu-only=20
and qemu-kvm (without xen).
Qxl is definitely not working under xen and conversely is ok on qemu-kvm =

and qemu-only.

It seem that xen need change and/or fix to have full working emulated=20
vga on qemu upstream.
At the moment all emulated vgas have problems with xen that aren't=20
present without xen.

The performance differences are noticeable (in some case very big) with=20
xen and without xen using resolution > 1024x768.

Probably the first link explain the change/fix necessary in xen about=20
vga (probably in hvmloader).
I tried to do that more times failing but unfortunately I do not have=20
sufficient knowledge about this.
Can someone help me please?

I think this is important, years ago the minimal resolution used on=20
desktop was 1024x768, and no problem with actual vga setting but now=20
minimal resolution seems increased to up 1366x768 and many people are=20
using even higher resolutions.
http://www.screenresolution.org/year-2013/


--------------ms030207080204060503070104
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwMTExNTIwNVowIwYJKoZIhvcNAQkEMRYEFJuI0wRP6lS8m0RKsbJTmJbK
lhphMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAeQqrVjCNWyT1kslwnN4nxxTR
sj1AIqfUGSyTWfuFHwqXq2bYsnRYcD28bqU2JueUw8ANxJihzmaXTqEt3/LbpzaW6086NEmf
R0epYwAgiwXf30ooTSXAJarR2O3sN2KtZgKFTdIbK7INTYTp5FkTO5j17dwRCUWygMCw7H4E
b54JmLIKaSBblsVHrtHlJuV4Q0ILRSVlXylVMSHFSV2fU0/N5+jUOMQymB65pOrBm6aEOdgU
wupS1FoqEoLA8pfz6s4EIfAH4Is/rI8ggHvotrzGZpnhv83VtPA8B0zf0cPlir7ZOfrQe+Sd
TtDO2EAYF76xJqEix0pz4NWC4qXuOQAAAAAAAA==
--------------ms030207080204060503070104--


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

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

--===============4723474397795133221==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 11:52:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11:52: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 1U1FAM-000834-5R; Fri, 01 Feb 2013 11:52:22 +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 1U1FAL-00082z-6G
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 11:52:21 +0000
Received: from [85.158.138.51:9836] by server-12.bemta-3.messagelabs.com id
	88/8C-05889-47CAB015; Fri, 01 Feb 2013 11:52:20 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1359719530!30547083!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23854 invoked from network); 1 Feb 2013 11:52:10 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 11:52:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 37CCE400476;
	Fri,  1 Feb 2013 12:52:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id HX7Layh72-su; Fri,  1 Feb 2013 12:52:09 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 122CF4002A6;
	Fri,  1 Feb 2013 12:52:08 +0100 (CET)
Message-ID: <510BAC65.7080505@tiscali.it>
Date: Fri, 01 Feb 2013 12:52:05 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <50F036FA.9090500@tiscali.it>
	<alpine.DEB.2.02.1301141244460.4978@kaball.uk.xensource.com>
	<50F41548.1010508@tiscali.it>
	<alpine.DEB.2.02.1301141818360.4978@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1301141818360.4978@kaball.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v3] tools/libxl: Improve videoram setting
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="===============4723474397795133221=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4723474397795133221==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030207080204060503070104"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030207080204060503070104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 14/01/2013 19:21, Stefano Stabellini ha scritto:
> I did a quick test and it seems that it should be possible to change=20
> the amount of videoram for stdvga too using the same command line=20
> option, however at the moment it just errors out. Therefore I am OK=20
> with this patch only taking care of Cirrus for the moment.=20
I found details about stdvga on qemu upstream:
http://xenbits.xen.org/gitweb/?p=3Dstaging/qemu-upstream-unstable.git;a=3D=
blob_plain;f=3Ddocs/specs/standard-vga.txt;hb=3DHEAD

It seems that stdvga memory by default is 16 mb, while xen reserves only =

8 mb by default and doen't logs any error.
For cirrus, increasing memory seems to be correct and without error with =

my patch.
WIth both cirrus and stdvga under qemu upstream with xen the performance =

are really poor even if I increase video memory, respect to qemu-only=20
and qemu-kvm (without xen).
Qxl is definitely not working under xen and conversely is ok on qemu-kvm =

and qemu-only.

It seem that xen need change and/or fix to have full working emulated=20
vga on qemu upstream.
At the moment all emulated vgas have problems with xen that aren't=20
present without xen.

The performance differences are noticeable (in some case very big) with=20
xen and without xen using resolution > 1024x768.

Probably the first link explain the change/fix necessary in xen about=20
vga (probably in hvmloader).
I tried to do that more times failing but unfortunately I do not have=20
sufficient knowledge about this.
Can someone help me please?

I think this is important, years ago the minimal resolution used on=20
desktop was 1024x768, and no problem with actual vga setting but now=20
minimal resolution seems increased to up 1366x768 and many people are=20
using even higher resolutions.
http://www.screenresolution.org/year-2013/


--------------ms030207080204060503070104
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwMTExNTIwNVowIwYJKoZIhvcNAQkEMRYEFJuI0wRP6lS8m0RKsbJTmJbK
lhphMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAeQqrVjCNWyT1kslwnN4nxxTR
sj1AIqfUGSyTWfuFHwqXq2bYsnRYcD28bqU2JueUw8ANxJihzmaXTqEt3/LbpzaW6086NEmf
R0epYwAgiwXf30ooTSXAJarR2O3sN2KtZgKFTdIbK7INTYTp5FkTO5j17dwRCUWygMCw7H4E
b54JmLIKaSBblsVHrtHlJuV4Q0ILRSVlXylVMSHFSV2fU0/N5+jUOMQymB65pOrBm6aEOdgU
wupS1FoqEoLA8pfz6s4EIfAH4Is/rI8ggHvotrzGZpnhv83VtPA8B0zf0cPlir7ZOfrQe+Sd
TtDO2EAYF76xJqEix0pz4NWC4qXuOQAAAAAAAA==
--------------ms030207080204060503070104--


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

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

--===============4723474397795133221==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 11:59:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1FHW-0008Ib-BE; Fri, 01 Feb 2013 11:59:46 +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 1U1FHU-0008IU-4c
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 11:59:44 +0000
Received: from [85.158.139.83:40169] by server-13.bemta-5.messagelabs.com id
	32/20-06769-F2EAB015; Fri, 01 Feb 2013 11:59:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1359719960!30400907!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25289 invoked from network); 1 Feb 2013 11:59:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1062739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 11:59: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.297.1; Fri, 1 Feb 2013 11:59:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1FH5-0003GH-KT;
	Fri, 01 Feb 2013 11:59:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1FH5-0000vW-BW;
	Fri, 01 Feb 2013 11:59:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15403-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Feb 2013 11:59:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15403: 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 15403 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15403/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 15401

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 11:59:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 11: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 1U1FHW-0008Ib-BE; Fri, 01 Feb 2013 11:59:46 +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 1U1FHU-0008IU-4c
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 11:59:44 +0000
Received: from [85.158.139.83:40169] by server-13.bemta-5.messagelabs.com id
	32/20-06769-F2EAB015; Fri, 01 Feb 2013 11:59:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1359719960!30400907!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25289 invoked from network); 1 Feb 2013 11:59:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 11:59:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1062739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 11:59: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.297.1; Fri, 1 Feb 2013 11:59:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1FH5-0003GH-KT;
	Fri, 01 Feb 2013 11:59:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1FH5-0000vW-BW;
	Fri, 01 Feb 2013 11:59:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15403-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Feb 2013 11:59:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15403: 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 15403 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15403/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 15401

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 12:33:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 12: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 1U1Fnw-0000hr-1o; Fri, 01 Feb 2013 12:33:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U1Fnu-0000hm-Pr
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 12:33:14 +0000
Received: from [85.158.138.51:9808] by server-12.bemta-3.messagelabs.com id
	35/FD-05889-506BB015; Fri, 01 Feb 2013 12:33:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1359721986!11853433!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31889 invoked from network); 1 Feb 2013 12:33:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 12:33:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5650932"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 12:33:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 07:33:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1Fnl-0000LX-6y;
	Fri, 01 Feb 2013 12:33:05 +0000
Message-ID: <1359721985.23229.109.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 12:33:05 +0000
In-Reply-To: <510BA3B4.4010104@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
	<510BA3B4.4010104@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/13] xen: fix evtchn_unbind_from_user
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:15 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > It is possible the port was allocated but the irq was not. Take care of this
> > case.
> 
> I think the port should be closed when the evtchn_bind_to_user() fails
> otherwise the evtchn driver is leaving the event channel in an
> inconsistent state.
> 

Good point! I will move the fix there.

Wei.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 12:33:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 12: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 1U1Fnw-0000hr-1o; Fri, 01 Feb 2013 12:33:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U1Fnu-0000hm-Pr
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 12:33:14 +0000
Received: from [85.158.138.51:9808] by server-12.bemta-3.messagelabs.com id
	35/FD-05889-506BB015; Fri, 01 Feb 2013 12:33:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1359721986!11853433!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31889 invoked from network); 1 Feb 2013 12:33:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 12:33:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5650932"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 12:33:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 07:33:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1Fnl-0000LX-6y;
	Fri, 01 Feb 2013 12:33:05 +0000
Message-ID: <1359721985.23229.109.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 12:33:05 +0000
In-Reply-To: <510BA3B4.4010104@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
	<510BA3B4.4010104@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/13] xen: fix evtchn_unbind_from_user
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:15 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > It is possible the port was allocated but the irq was not. Take care of this
> > case.
> 
> I think the port should be closed when the evtchn_bind_to_user() fails
> otherwise the evtchn driver is leaving the event channel in an
> inconsistent state.
> 

Good point! I will move the fix there.

Wei.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 12:37:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 12:37: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 1U1FrU-00016u-V7; Fri, 01 Feb 2013 12:36:56 +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 1U1FrT-00016W-4y
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 12:36:55 +0000
Received: from [193.109.254.147:30524] by server-11.bemta-14.messagelabs.com
	id 23/EC-30685-6E6BB015; Fri, 01 Feb 2013 12:36:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1359722209!6451627!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24213 invoked from network); 1 Feb 2013 12:36:51 -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;
	1 Feb 2013 12:36:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5944546"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 12:36:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 07:36:49 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1FrM-0000OO-Ut;
	Fri, 01 Feb 2013 12:36:48 +0000
Message-ID: <1359722208.23229.111.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 12:36:48 +0000
In-Reply-To: <1359717986.9063.30.camel@dagon.hellion.org.uk>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
	<1359717986.9063.30.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:26 +0000, Ian Campbell wrote:
> On Thu, 2013-01-31 at 14:46 +0000, Wei Liu wrote:
> > It is possible that the call to xen_allocate_irq_dynamic() returns negative
> > number other than -1.
> 
> Hopefully this means it always returns -ERRNO, rather than a mixture of
> -ERRNO and literal -1?
> 
> Ian.
> 

Yes, xen_allocate_irq_dynamic() ultimately calls __irq_alloc_descs()
which returns -ERRNO.

Wei.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 12:37:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 12:37: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 1U1FrU-00016u-V7; Fri, 01 Feb 2013 12:36:56 +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 1U1FrT-00016W-4y
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 12:36:55 +0000
Received: from [193.109.254.147:30524] by server-11.bemta-14.messagelabs.com
	id 23/EC-30685-6E6BB015; Fri, 01 Feb 2013 12:36:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1359722209!6451627!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24213 invoked from network); 1 Feb 2013 12:36:51 -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;
	1 Feb 2013 12:36:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5944546"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 12:36:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 07:36:49 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1FrM-0000OO-Ut;
	Fri, 01 Feb 2013 12:36:48 +0000
Message-ID: <1359722208.23229.111.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 12:36:48 +0000
In-Reply-To: <1359717986.9063.30.camel@dagon.hellion.org.uk>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
	<1359717986.9063.30.camel@dagon.hellion.org.uk>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:26 +0000, Ian Campbell wrote:
> On Thu, 2013-01-31 at 14:46 +0000, Wei Liu wrote:
> > It is possible that the call to xen_allocate_irq_dynamic() returns negative
> > number other than -1.
> 
> Hopefully this means it always returns -ERRNO, rather than a mixture of
> -ERRNO and literal -1?
> 
> Ian.
> 

Yes, xen_allocate_irq_dynamic() ultimately calls __irq_alloc_descs()
which returns -ERRNO.

Wei.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 12:42:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 12: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 1U1Fwr-0001Xy-Pg; Fri, 01 Feb 2013 12:42:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1U1Fwq-0001Xp-5k
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 12:42:28 +0000
Received: from [85.158.138.51:58653] by server-12.bemta-3.messagelabs.com id
	8C/4F-05889-338BB015; Fri, 01 Feb 2013 12:42:27 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359722532!28401316!1
X-Originating-IP: [209.85.216.169]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1137 invoked from network); 1 Feb 2013 12:42:13 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 12:42:13 -0000
Received: by mail-qc0-f169.google.com with SMTP id t2so1757835qcq.0
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Feb 2013 04:42:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=QqHSKL4O3Ur0GTe4GjtJT4j30Kai0yiDdrjRaATEA7E=;
	b=TROQ4pbwywAJW39blMOliJTEgAdAqC/VkX6w+5StaBQRsuCAMojC8i4FQAbia4NfAE
	Hm28FjTbxwCFrxgPP/8NyjhPJE1XgOCdGhD9QJNOCgOJRFcO7OD0RJDu0rxjzVschVNN
	AwlOCAcGe4iZyupUYyrAklZ6/SDq89DxvNYh8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=QqHSKL4O3Ur0GTe4GjtJT4j30Kai0yiDdrjRaATEA7E=;
	b=dn9hGOBsZFJ4Ej+AwynCQkzVGsbPt6BHZFY5GrXdm7GqdKWddWWJl0rgqeBBrKeegj
	SMW1A8xSrw7iDlYOXs4CDBmteqSiytHUNPdfiK1LLYkl4Hvv5+YtfJ+5bzlp0bDD9pBO
	3iBlLx1qDGjY+QS0+mvM7wWIE82jWnWQ8b3JWYxTl7yBXFiTSIZg0XV0mV2qkx6os5Nu
	dTOQJicY0AGK9xMd0B1llpuH7qBhw8G8hmoShv1fOo6rDm1QWmHDAeayqi1c2rqv3Y8I
	PsSIpchdUwO1BGHjQ3e3vtNaTsBHW5KL78wOxAlrFtcJOBeoXxwSUOAGUA+LLiIhdwNK
	CVtQ==
X-Received: by 10.229.111.130 with SMTP id s2mr3023909qcp.91.1359722532136;
	Fri, 01 Feb 2013 04:42:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Fri, 1 Feb 2013 04:41:55 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <alpine.DEB.2.02.1301301609280.10432@kaball.uk.xensource.com>
References: <CACaajQtmHY2EJcODrgFCmJFqOg-sNo8Q4_DotStrLF0RFvVp8g@mail.gmail.com>
	<1358762719.3279.158.camel@zakaz.uk.xensource.com>
	<CACaajQusNCQM1qOs_38oRSba2mr0+emQzEV8Pn332D-MdtW_ZQ@mail.gmail.com>
	<1358849670.3279.315.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301221142370.29727@kaball.uk.xensource.com>
	<CACaajQstT3EbNSk=ssxjyWtT4M0YyF4xhVBYjLjyJ39O62XfCg@mail.gmail.com>
	<CACaajQsgLpWk7y7ym2Lu2fav_bJZVneu7pZt4_AqQwDX1RQMnQ@mail.gmail.com>
	<alpine.DEB.2.02.1301301609280.10432@kaball.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 1 Feb 2013 16:41:55 +0400
X-Google-Sender-Auth: RjjHk6CNcLyEqhgLCY0QzSOoPPE
Message-ID: <CACaajQtxLauXCmYP0yjzO0tCDmufafty=XOYNPWjA1bAXH98Aw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQntG7A6PmegIb21GP/PZnFeGTk1+Cn8+6NnJKuLkrFcHmzFsK+CGHWt78H5RIDR+rliJxHu
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"james.harper@bendigoit.com.au" <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] can't boot from iso on cifs mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Failed again.
may be in xenstore.c in this code i need to delete O_DIRECT flag?

In strace before i get messages about fallback without O_DIRECT
(provided with patch) i get this:

write(2, "Using file /var/storage/iso/SW_D"..., 130) = 130
open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
write(2, "qemu: could not open vbd '/local"..., 216) = 216

My be in this code i append fallback?

            if (bdrv_open2(bs, params, flags|BDRV_O_CACHE_WB /*
snapshot and write-back */, format) < 0) {
                fprintf(stderr, "qemu: could not open vbd '%s' or hard
disk image '%s' (drv '%s' format '%s')\n", buf, params, drv ? drv :
"?", format ? format->format_name : "0");
            } else {
                char* snapshot = get_snapshot_name(atoi(e_danger[i]));
                if (snapshot) {
                    fprintf(stderr, "Using snapshot %s\n", snapshot);
                    ret = bdrv_snapshot_goto(bs, snapshot);
                    switch (ret) {
                    case 0:
                        /* Success */
                        break;
                    case -ENOTSUP:
                        /* Don't abort here (could be read-only ISO) */
                        fprintf(stderr, "Snapshots are not supported for "
                            "this image file format\n");
                        break;
                    case -ENOENT:
                        fprintf(stderr, "No such snapshot, skipping this "
                            "image file\n");
                        continue;
                    default:
                        fprintf(stderr, "Could not load snapshot, skipping"
                            " this image file\n");
                        continue;
                    }
                }
            }

2013/1/30 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> Sorry that was my stupid mistake.
> This should work:
>
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 33a5531..1786db8 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
>         if (blkdev->bs) {
>             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
>                             bdrv_find_format(blkdev->fileproto)) != 0) {
> -               bdrv_delete(blkdev->bs);
> -               blkdev->bs = NULL;
> -           }
> +                /* try without O_DIRECT */
> +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
> +                        blkdev->filename);
> +                qflags &= ~BDRV_O_NOCACHE;
> +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> +                            bdrv_find_format(blkdev->fileproto)) != 0) {
> +                    bdrv_delete(blkdev->bs);
> +                    blkdev->bs = NULL;
> +                }
> +            }
>         }
>         if (!blkdev->bs)
>             return -1;
>
> On Wed, 30 Jan 2013, Vasiliy Tolstov wrote:
>> Strace shows that qemu after O_DIRECT next try with O_DIRECT
>> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
>> EINVAL (Invalid argument)
>> write(2, "xen be: qdisk-832: ", 19)     = 19
>> write(2, "xen be: qdisk-832: ", 19)     = 19
>> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
>> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
>> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
>> EINVAL (Invalid argument)
>>
>> 2013/1/30 Vasiliy Tolstov <v.tolstov@selfip.ru>:
>> > Thanks for patch. But it not solve problem:
>> > Now i have :
>> > domid: 6
>> > Using file /dev/disk/vbd/21-828 in read-write mode
>> > Strip off blktap sub-type prefix to  (drv 'aio')
>> > Watching /local/domain/0/device-model/6/logdirty/cmd
>> > Watching /local/domain/0/device-model/6/command
>> > Watching /local/domain/6/cpu
>> > char device redirected to /dev/pts/5
>> > qemu_map_cache_init nr_buckets = 10000 size 4194304
>> > Could not open /var/run/tap/qemu-read-6
>> > shared page at pfn feffd
>> > buffered io page at pfn feffb
>> > Guest uuid = c98c33c8-1891-41ec-96a0-984f3df80def
>> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
>> > trying write-through.
>> > opening  with O_DIRECT failed, trying write-through.
>> > 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/6/xen_extended_power_mgmt): read error
>> > medium change watch on `hdc' (index: 1): aio:
>> > 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
>> > vcpu-set: watch node error.
>> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
>> > xs_read(/local/domain/6/log-throttling): read error
>> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
>> > medium change watch on `/local/domain/6/log-throttling' - unknown
>> > device, ignored
>> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
>> > trying write-through.
>> > opening  with O_DIRECT failed, trying write-through.
>> > log_throttling disabled
>> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
>> > medium change watch on `/local/domain/6/log-throttling' - unknown
>> > device, ignored
>> > vga s->lfb_addr = f0000000 s->lfb_end = f1000000
>> > 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.
>> >
>> >
>> > (XEN) HVM6: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
>> > (XEN) HVM6: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $
>> > (XEN) HVM6: Bochs BIOS - build: 06/23/99
>> > (XEN) HVM6: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
>> > (XEN) HVM6: Options: apmbios pcibios eltorito PMM
>> > (XEN) HVM6:
>> > (XEN) HVM6: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
>> > (XEN) HVM6: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10246 MBytes)
>> > (XEN) HVM6: IDE time out
>> > (XEN) HVM6: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
>> > (XEN) HVM6: IDE time out
>> > (XEN) HVM6:
>> > (XEN) HVM6:
>> > (XEN) HVM6:
>> > (XEN) HVM6: Press F12 for boot menu.
>> > (XEN) HVM6:
>> > (XEN) HVM6: Booting from Hard Disk...
>> > (XEN) HVM6: Boot from Hard Disk failed: not a bootable disk
>> > (XEN) HVM6:
>> > (XEN) HVM6:
>> > (XEN) HVM6: No bootable device.
>> > (XEN) HVM6: Powering off in 30 seconds.
>> > (XEN) hvm.c:1080:d6 All CPUs offline -- powering off.
>> >
>> > 2013/1/22 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
>> >> On Tue, 22 Jan 2013, Ian Campbell wrote:
>> >>> Please don't top post.
>> >>>
>> >>> On Tue, 2013-01-22 at 05:38 +0000, Vasiliy Tolstov wrote:
>> >>> > Thanks!
>> >>> > I found, that now xl tries to open iso with O_DIRECT flag.
>> >>> > open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
>> >>> > O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
>> >>> > write(2, "qemu: could not open vbd '/local"..., 217) = 217
>> >>
>> >> xl? I guess you mean QEMU tries to open the ISO with O_DIRECT.
>> >>
>> >>
>> >>> I guess CIFS doesn't support O_DIRECT. It looks like it does have mount
>> >>> -o directio though, worth a try.
>> >>>
>> >>> I'm not sure what options exist to turn this off from the qemu side --
>> >>> Stefano? I also have a feeling something changed in this regard in 4.2.x
>> >>
>> >> Given that you are not passing any device_model_version option to xl, I
>> >> assume that you are running qemu-xen-traditional (ps should show that a
>> >> binary called qemu-dm is running).
>> >>
>> >> If that is the case, there is currently no way to specify any flags.
>> >> However the interesting bit is that qemu-xen-traditional opens files
>> >> corresponding to emulated devices with BDRV_O_CACHE_WB and opens files
>> >> corresponding to PV interfaces using BDRV_O_NOCACHE (this means
>> >> O_DIRECT).
>> >> This means that the failure should be caused by hw/xen_disk.c trying to
>> >> opening the iso O_DIRECT. Paradoxically the PV inteface for a cdrom
>> >> drive is usually never used AFAIK.
>> >>
>> >> Did the Windows PV drivers start using the PV cdrom interface all of a
>> >> sudden?
>> >>
>> >> In any case I think that the best thing we could do it fall back to
>> >> write-through (or should it be write-back? It might not be safe..) in
>> >> case O_DIRECT fails. This is what qemu-xen does in such cases.
>> >>
>> >> Try this patch:
>> >>
>> >> ---
>> >>
>> >> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>> >> index 33a5531..d6d71fe 100644
>> >> --- a/hw/xen_disk.c
>> >> +++ b/hw/xen_disk.c
>> >> @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
>> >>         if (blkdev->bs) {
>> >>             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
>> >>                             bdrv_find_format(blkdev->fileproto)) != 0) {
>> >> -               bdrv_delete(blkdev->bs);
>> >> -               blkdev->bs = NULL;
>> >> -           }
>> >> +                /* try without O_DIRECT */
>> >> +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
>> >> +                        blkdev->filename);
>> >> +                qflags &= BDRV_O_NOCACHE;
>> >> +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
>> >> +                            bdrv_find_format(blkdev->fileproto)) != 0) {
>> >> +                    bdrv_delete(blkdev->bs);
>> >> +                    blkdev->bs = NULL;
>> >> +                }
>> >> +            }
>> >>         }
>> >>         if (!blkdev->bs)
>> >>             return -1;
>> >>
>> >
>> >
>> >
>> > --
>> > Vasiliy Tolstov,
>> > Clodo.ru
>> > e-mail: v.tolstov@selfip.ru
>> > jabber: vase@selfip.ru
>>
>>
>>
>> --
>> Vasiliy Tolstov,
>> Clodo.ru
>> e-mail: v.tolstov@selfip.ru
>> jabber: vase@selfip.ru
>>



-- 
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 Feb 01 12:42:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 12: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 1U1Fwr-0001Xy-Pg; Fri, 01 Feb 2013 12:42:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1U1Fwq-0001Xp-5k
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 12:42:28 +0000
Received: from [85.158.138.51:58653] by server-12.bemta-3.messagelabs.com id
	8C/4F-05889-338BB015; Fri, 01 Feb 2013 12:42:27 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359722532!28401316!1
X-Originating-IP: [209.85.216.169]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1137 invoked from network); 1 Feb 2013 12:42:13 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 12:42:13 -0000
Received: by mail-qc0-f169.google.com with SMTP id t2so1757835qcq.0
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Feb 2013 04:42:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=QqHSKL4O3Ur0GTe4GjtJT4j30Kai0yiDdrjRaATEA7E=;
	b=TROQ4pbwywAJW39blMOliJTEgAdAqC/VkX6w+5StaBQRsuCAMojC8i4FQAbia4NfAE
	Hm28FjTbxwCFrxgPP/8NyjhPJE1XgOCdGhD9QJNOCgOJRFcO7OD0RJDu0rxjzVschVNN
	AwlOCAcGe4iZyupUYyrAklZ6/SDq89DxvNYh8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=QqHSKL4O3Ur0GTe4GjtJT4j30Kai0yiDdrjRaATEA7E=;
	b=dn9hGOBsZFJ4Ej+AwynCQkzVGsbPt6BHZFY5GrXdm7GqdKWddWWJl0rgqeBBrKeegj
	SMW1A8xSrw7iDlYOXs4CDBmteqSiytHUNPdfiK1LLYkl4Hvv5+YtfJ+5bzlp0bDD9pBO
	3iBlLx1qDGjY+QS0+mvM7wWIE82jWnWQ8b3JWYxTl7yBXFiTSIZg0XV0mV2qkx6os5Nu
	dTOQJicY0AGK9xMd0B1llpuH7qBhw8G8hmoShv1fOo6rDm1QWmHDAeayqi1c2rqv3Y8I
	PsSIpchdUwO1BGHjQ3e3vtNaTsBHW5KL78wOxAlrFtcJOBeoXxwSUOAGUA+LLiIhdwNK
	CVtQ==
X-Received: by 10.229.111.130 with SMTP id s2mr3023909qcp.91.1359722532136;
	Fri, 01 Feb 2013 04:42:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Fri, 1 Feb 2013 04:41:55 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <alpine.DEB.2.02.1301301609280.10432@kaball.uk.xensource.com>
References: <CACaajQtmHY2EJcODrgFCmJFqOg-sNo8Q4_DotStrLF0RFvVp8g@mail.gmail.com>
	<1358762719.3279.158.camel@zakaz.uk.xensource.com>
	<CACaajQusNCQM1qOs_38oRSba2mr0+emQzEV8Pn332D-MdtW_ZQ@mail.gmail.com>
	<1358849670.3279.315.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301221142370.29727@kaball.uk.xensource.com>
	<CACaajQstT3EbNSk=ssxjyWtT4M0YyF4xhVBYjLjyJ39O62XfCg@mail.gmail.com>
	<CACaajQsgLpWk7y7ym2Lu2fav_bJZVneu7pZt4_AqQwDX1RQMnQ@mail.gmail.com>
	<alpine.DEB.2.02.1301301609280.10432@kaball.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 1 Feb 2013 16:41:55 +0400
X-Google-Sender-Auth: RjjHk6CNcLyEqhgLCY0QzSOoPPE
Message-ID: <CACaajQtxLauXCmYP0yjzO0tCDmufafty=XOYNPWjA1bAXH98Aw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQntG7A6PmegIb21GP/PZnFeGTk1+Cn8+6NnJKuLkrFcHmzFsK+CGHWt78H5RIDR+rliJxHu
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"james.harper@bendigoit.com.au" <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] can't boot from iso on cifs mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Failed again.
may be in xenstore.c in this code i need to delete O_DIRECT flag?

In strace before i get messages about fallback without O_DIRECT
(provided with patch) i get this:

write(2, "Using file /var/storage/iso/SW_D"..., 130) = 130
open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
write(2, "qemu: could not open vbd '/local"..., 216) = 216

My be in this code i append fallback?

            if (bdrv_open2(bs, params, flags|BDRV_O_CACHE_WB /*
snapshot and write-back */, format) < 0) {
                fprintf(stderr, "qemu: could not open vbd '%s' or hard
disk image '%s' (drv '%s' format '%s')\n", buf, params, drv ? drv :
"?", format ? format->format_name : "0");
            } else {
                char* snapshot = get_snapshot_name(atoi(e_danger[i]));
                if (snapshot) {
                    fprintf(stderr, "Using snapshot %s\n", snapshot);
                    ret = bdrv_snapshot_goto(bs, snapshot);
                    switch (ret) {
                    case 0:
                        /* Success */
                        break;
                    case -ENOTSUP:
                        /* Don't abort here (could be read-only ISO) */
                        fprintf(stderr, "Snapshots are not supported for "
                            "this image file format\n");
                        break;
                    case -ENOENT:
                        fprintf(stderr, "No such snapshot, skipping this "
                            "image file\n");
                        continue;
                    default:
                        fprintf(stderr, "Could not load snapshot, skipping"
                            " this image file\n");
                        continue;
                    }
                }
            }

2013/1/30 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> Sorry that was my stupid mistake.
> This should work:
>
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 33a5531..1786db8 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
>         if (blkdev->bs) {
>             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
>                             bdrv_find_format(blkdev->fileproto)) != 0) {
> -               bdrv_delete(blkdev->bs);
> -               blkdev->bs = NULL;
> -           }
> +                /* try without O_DIRECT */
> +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
> +                        blkdev->filename);
> +                qflags &= ~BDRV_O_NOCACHE;
> +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> +                            bdrv_find_format(blkdev->fileproto)) != 0) {
> +                    bdrv_delete(blkdev->bs);
> +                    blkdev->bs = NULL;
> +                }
> +            }
>         }
>         if (!blkdev->bs)
>             return -1;
>
> On Wed, 30 Jan 2013, Vasiliy Tolstov wrote:
>> Strace shows that qemu after O_DIRECT next try with O_DIRECT
>> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
>> EINVAL (Invalid argument)
>> write(2, "xen be: qdisk-832: ", 19)     = 19
>> write(2, "xen be: qdisk-832: ", 19)     = 19
>> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
>> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
>> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
>> EINVAL (Invalid argument)
>>
>> 2013/1/30 Vasiliy Tolstov <v.tolstov@selfip.ru>:
>> > Thanks for patch. But it not solve problem:
>> > Now i have :
>> > domid: 6
>> > Using file /dev/disk/vbd/21-828 in read-write mode
>> > Strip off blktap sub-type prefix to  (drv 'aio')
>> > Watching /local/domain/0/device-model/6/logdirty/cmd
>> > Watching /local/domain/0/device-model/6/command
>> > Watching /local/domain/6/cpu
>> > char device redirected to /dev/pts/5
>> > qemu_map_cache_init nr_buckets = 10000 size 4194304
>> > Could not open /var/run/tap/qemu-read-6
>> > shared page at pfn feffd
>> > buffered io page at pfn feffb
>> > Guest uuid = c98c33c8-1891-41ec-96a0-984f3df80def
>> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
>> > trying write-through.
>> > opening  with O_DIRECT failed, trying write-through.
>> > 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/6/xen_extended_power_mgmt): read error
>> > medium change watch on `hdc' (index: 1): aio:
>> > 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
>> > vcpu-set: watch node error.
>> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
>> > xs_read(/local/domain/6/log-throttling): read error
>> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
>> > medium change watch on `/local/domain/6/log-throttling' - unknown
>> > device, ignored
>> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
>> > trying write-through.
>> > opening  with O_DIRECT failed, trying write-through.
>> > log_throttling disabled
>> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
>> > medium change watch on `/local/domain/6/log-throttling' - unknown
>> > device, ignored
>> > vga s->lfb_addr = f0000000 s->lfb_end = f1000000
>> > 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.
>> >
>> >
>> > (XEN) HVM6: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
>> > (XEN) HVM6: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $
>> > (XEN) HVM6: Bochs BIOS - build: 06/23/99
>> > (XEN) HVM6: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
>> > (XEN) HVM6: Options: apmbios pcibios eltorito PMM
>> > (XEN) HVM6:
>> > (XEN) HVM6: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
>> > (XEN) HVM6: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10246 MBytes)
>> > (XEN) HVM6: IDE time out
>> > (XEN) HVM6: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
>> > (XEN) HVM6: IDE time out
>> > (XEN) HVM6:
>> > (XEN) HVM6:
>> > (XEN) HVM6:
>> > (XEN) HVM6: Press F12 for boot menu.
>> > (XEN) HVM6:
>> > (XEN) HVM6: Booting from Hard Disk...
>> > (XEN) HVM6: Boot from Hard Disk failed: not a bootable disk
>> > (XEN) HVM6:
>> > (XEN) HVM6:
>> > (XEN) HVM6: No bootable device.
>> > (XEN) HVM6: Powering off in 30 seconds.
>> > (XEN) hvm.c:1080:d6 All CPUs offline -- powering off.
>> >
>> > 2013/1/22 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
>> >> On Tue, 22 Jan 2013, Ian Campbell wrote:
>> >>> Please don't top post.
>> >>>
>> >>> On Tue, 2013-01-22 at 05:38 +0000, Vasiliy Tolstov wrote:
>> >>> > Thanks!
>> >>> > I found, that now xl tries to open iso with O_DIRECT flag.
>> >>> > open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
>> >>> > O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
>> >>> > write(2, "qemu: could not open vbd '/local"..., 217) = 217
>> >>
>> >> xl? I guess you mean QEMU tries to open the ISO with O_DIRECT.
>> >>
>> >>
>> >>> I guess CIFS doesn't support O_DIRECT. It looks like it does have mount
>> >>> -o directio though, worth a try.
>> >>>
>> >>> I'm not sure what options exist to turn this off from the qemu side --
>> >>> Stefano? I also have a feeling something changed in this regard in 4.2.x
>> >>
>> >> Given that you are not passing any device_model_version option to xl, I
>> >> assume that you are running qemu-xen-traditional (ps should show that a
>> >> binary called qemu-dm is running).
>> >>
>> >> If that is the case, there is currently no way to specify any flags.
>> >> However the interesting bit is that qemu-xen-traditional opens files
>> >> corresponding to emulated devices with BDRV_O_CACHE_WB and opens files
>> >> corresponding to PV interfaces using BDRV_O_NOCACHE (this means
>> >> O_DIRECT).
>> >> This means that the failure should be caused by hw/xen_disk.c trying to
>> >> opening the iso O_DIRECT. Paradoxically the PV inteface for a cdrom
>> >> drive is usually never used AFAIK.
>> >>
>> >> Did the Windows PV drivers start using the PV cdrom interface all of a
>> >> sudden?
>> >>
>> >> In any case I think that the best thing we could do it fall back to
>> >> write-through (or should it be write-back? It might not be safe..) in
>> >> case O_DIRECT fails. This is what qemu-xen does in such cases.
>> >>
>> >> Try this patch:
>> >>
>> >> ---
>> >>
>> >> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>> >> index 33a5531..d6d71fe 100644
>> >> --- a/hw/xen_disk.c
>> >> +++ b/hw/xen_disk.c
>> >> @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
>> >>         if (blkdev->bs) {
>> >>             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
>> >>                             bdrv_find_format(blkdev->fileproto)) != 0) {
>> >> -               bdrv_delete(blkdev->bs);
>> >> -               blkdev->bs = NULL;
>> >> -           }
>> >> +                /* try without O_DIRECT */
>> >> +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
>> >> +                        blkdev->filename);
>> >> +                qflags &= BDRV_O_NOCACHE;
>> >> +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
>> >> +                            bdrv_find_format(blkdev->fileproto)) != 0) {
>> >> +                    bdrv_delete(blkdev->bs);
>> >> +                    blkdev->bs = NULL;
>> >> +                }
>> >> +            }
>> >>         }
>> >>         if (!blkdev->bs)
>> >>             return -1;
>> >>
>> >
>> >
>> >
>> > --
>> > Vasiliy Tolstov,
>> > Clodo.ru
>> > e-mail: v.tolstov@selfip.ru
>> > jabber: vase@selfip.ru
>>
>>
>>
>> --
>> Vasiliy Tolstov,
>> Clodo.ru
>> e-mail: v.tolstov@selfip.ru
>> jabber: vase@selfip.ru
>>



-- 
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 Feb 01 13:11:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13:11: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 1U1GOU-0002FB-EU; Fri, 01 Feb 2013 13:11:02 +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 1U1GOS-0002Ey-Nk
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:11:00 +0000
Received: from [85.158.143.99:53687] by server-3.bemta-4.messagelabs.com id
	CD/A9-08920-3EEBB015; Fri, 01 Feb 2013 13:10:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359724254!20705711!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 1 Feb 2013 13:10:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 13:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5947488"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 13:10:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 08:10:53 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1GOL-0000x7-JY;
	Fri, 01 Feb 2013 13:10:53 +0000
Message-ID: <1359724253.23229.115.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 13:10:53 +0000
In-Reply-To: <510BA19F.6010900@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
	<510BA19F.6010900@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:06 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > Four things are fixed:
> >  a) the test result of globaly masked event;
> >  b) make the per-cpu selector L1 to be consistent with description in
> >     __xen_evtchn_do_upcall's comment;
> >  c) the test result of L1 selector;
> >  d) add KERN_DEBUG in printk.
> 
> It's hard to pick out the correctness fixes with all the cosmetic
> KERN_DEBUG fixes in the same patch.
> 

Moved to separate changeset.

> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |   34 +++++++++++++++++-----------------
> >  1 file changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 7595581..2c94aad 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> [...]
> > +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +					     ? "" : " l1-clear",
> 
> This looks backwards now.
> 

Did you mean the "globally-masked" below? I think I made a mistake here,
because in global mask 1 means masked while in per cpu mask 0 means
masked...


Wei.

> > +			       sync_test_bit(i, sh->evtchn_mask)
> >  					     ? "" : " globally-masked",
> >  			       sync_test_bit(i, cpu_evtchn)
> >  					     ? "" : " locally-masked");
> 
> David
> 



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

From xen-devel-bounces@lists.xen.org Fri Feb 01 13:11:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13:11: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 1U1GOU-0002FB-EU; Fri, 01 Feb 2013 13:11:02 +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 1U1GOS-0002Ey-Nk
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:11:00 +0000
Received: from [85.158.143.99:53687] by server-3.bemta-4.messagelabs.com id
	CD/A9-08920-3EEBB015; Fri, 01 Feb 2013 13:10:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359724254!20705711!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 1 Feb 2013 13:10:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 13:10:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5947488"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 13:10:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 08:10:53 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1GOL-0000x7-JY;
	Fri, 01 Feb 2013 13:10:53 +0000
Message-ID: <1359724253.23229.115.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 13:10:53 +0000
In-Reply-To: <510BA19F.6010900@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
	<510BA19F.6010900@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:06 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > Four things are fixed:
> >  a) the test result of globaly masked event;
> >  b) make the per-cpu selector L1 to be consistent with description in
> >     __xen_evtchn_do_upcall's comment;
> >  c) the test result of L1 selector;
> >  d) add KERN_DEBUG in printk.
> 
> It's hard to pick out the correctness fixes with all the cosmetic
> KERN_DEBUG fixes in the same patch.
> 

Moved to separate changeset.

> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |   34 +++++++++++++++++-----------------
> >  1 file changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 7595581..2c94aad 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> [...]
> > +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +					     ? "" : " l1-clear",
> 
> This looks backwards now.
> 

Did you mean the "globally-masked" below? I think I made a mistake here,
because in global mask 1 means masked while in per cpu mask 0 means
masked...


Wei.

> > +			       sync_test_bit(i, sh->evtchn_mask)
> >  					     ? "" : " globally-masked",
> >  			       sync_test_bit(i, cpu_evtchn)
> >  					     ? "" : " locally-masked");
> 
> David
> 



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

From xen-devel-bounces@lists.xen.org Fri Feb 01 13:14:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13:14: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 1U1GRj-0002Qg-2W; Fri, 01 Feb 2013 13:14:23 +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 1U1GRh-0002QY-EL
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:14:21 +0000
Received: from [85.158.139.211:44151] by server-3.bemta-5.messagelabs.com id
	65/FA-07037-CAFBB015; Fri, 01 Feb 2013 13:14:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1359724458!20682232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29574 invoked from network); 1 Feb 2013 13:14:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 13:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5654210"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 13:14:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 08:14:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1GRd-00010f-Ra;
	Fri, 01 Feb 2013 13:14:17 +0000
Message-ID: <1359724457.23229.116.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 13:14:17 +0000
In-Reply-To: <510BA19F.6010900@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
	<510BA19F.6010900@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:06 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > Four things are fixed:
> >  a) the test result of globaly masked event;
> >  b) make the per-cpu selector L1 to be consistent with description in
> >     __xen_evtchn_do_upcall's comment;
> >  c) the test result of L1 selector;
> >  d) add KERN_DEBUG in printk.
> 
> It's hard to pick out the correctness fixes with all the cosmetic
> KERN_DEBUG fixes in the same patch.
> 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |   34 +++++++++++++++++-----------------
> >  1 file changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 7595581..2c94aad 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> [...]
> > +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +					     ? "" : " l1-clear",
> 
> This looks backwards now.

Ah, I understand now. You're right, this fix is not necessary.


Wei. 

> 
> > +			       sync_test_bit(i, sh->evtchn_mask)
> >  					     ? "" : " globally-masked",
> >  			       sync_test_bit(i, cpu_evtchn)
> >  					     ? "" : " locally-masked");
> 
> David
> 



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

From xen-devel-bounces@lists.xen.org Fri Feb 01 13:14:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13:14: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 1U1GRj-0002Qg-2W; Fri, 01 Feb 2013 13:14:23 +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 1U1GRh-0002QY-EL
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:14:21 +0000
Received: from [85.158.139.211:44151] by server-3.bemta-5.messagelabs.com id
	65/FA-07037-CAFBB015; Fri, 01 Feb 2013 13:14:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1359724458!20682232!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29574 invoked from network); 1 Feb 2013 13:14:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 13:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5654210"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 13:14:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 08:14:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U1GRd-00010f-Ra;
	Fri, 01 Feb 2013 13:14:17 +0000
Message-ID: <1359724457.23229.116.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 13:14:17 +0000
In-Reply-To: <510BA19F.6010900@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-2-git-send-email-wei.liu2@citrix.com>
	<510BA19F.6010900@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:06 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > Four things are fixed:
> >  a) the test result of globaly masked event;
> >  b) make the per-cpu selector L1 to be consistent with description in
> >     __xen_evtchn_do_upcall's comment;
> >  c) the test result of L1 selector;
> >  d) add KERN_DEBUG in printk.
> 
> It's hard to pick out the correctness fixes with all the cosmetic
> KERN_DEBUG fixes in the same patch.
> 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |   34 +++++++++++++++++-----------------
> >  1 file changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 7595581..2c94aad 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> [...]
> > +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +					     ? "" : " l1-clear",
> 
> This looks backwards now.

Ah, I understand now. You're right, this fix is not necessary.


Wei. 

> 
> > +			       sync_test_bit(i, sh->evtchn_mask)
> >  					     ? "" : " globally-masked",
> >  			       sync_test_bit(i, cpu_evtchn)
> >  					     ? "" : " locally-masked");
> 
> David
> 



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

From xen-devel-bounces@lists.xen.org Fri Feb 01 13:42:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13:42: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 1U1GsK-0002mu-KD; Fri, 01 Feb 2013 13:41:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1GsI-0002mp-E9
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:41:50 +0000
Received: from [85.158.139.83:46194] by server-15.bemta-5.messagelabs.com id
	B2/40-18914-D16CB015; Fri, 01 Feb 2013 13:41:49 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359726108!29572932!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4MTA1MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29349 invoked from network); 1 Feb 2013 13:41:48 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 13:41:48 -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=kNyUS4hK33DGs8BGgApCSspg532AFZyXdj/Hk8p/SaiqgZKhs0tGQwE7
	G5zC6t9sv4gJhxbG9KWl5ELUVuMCXhVPhvIZPF66pAtBl/ypmIEK3SO5S
	5TQIF7QxymY/Bbacwz/bZBrb0oBcLGauV0FFFTCfQa0brfhD5UysXms9J
	UWCjO5DHz1Sku54X8/NYWm6CumyPnQAgqxiZerlq6x/voE30Kn5y7qyzs
	747qcv4JN0ImIGDiqKY6rYmGSO2vi;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359726108; x=1391262108;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=uana1EKEHESaE7LI5XmB5O8uSkmwhu5GD7Ikk0wi6rY=;
	b=Debs9tyDxl4umJZvtZxyHu0Xz/QkoIOPsa5IJcsCEPmM706VmJ5k6PSl
	yzDphgXr3h3jrVhYLVY99tuis3+r5fqLmSdOSyx1LSiuS8Il4i4anRXrw
	RUJXsaFMkzBEh7FLfBDRcTp6ZXaHjtxOag1QUcjriW99V8imWqhotaq4n
	P3HRtqKaiXHByYeeJ+2vNBVOxaIHFGWhhLyLe88OZDuKBCJrerTBb6uE3
	yFY1eckB7PsJSPqQlhFAHuCdb4ei6;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="135525744"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 01 Feb 2013 14:41:48 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="158060454"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with SMTP; 01 Feb 2013 14:41:47 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3928496BB1C;
	Fri,  1 Feb 2013 14:41:47 +0100 (CET)
Message-ID: <510BC61B.6090300@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 14:41:47 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<f05ac3f656309bc71d43.1359716481@Solace>
In-Reply-To: <f05ac3f656309bc71d43.1359716481@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 11 of 11 v3] docs: rearrange and update 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-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 01.02.2013 12:01, schrieb Dario Faggioli:
> To include the new concept of NUMA aware scheduling and
> describe its impact.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

>
> diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
> --- a/docs/misc/xl-numa-placement.markdown
> +++ b/docs/misc/xl-numa-placement.markdown
> @@ -14,22 +14,67 @@ the memory directly attached to the set
>
>   The Xen hypervisor deals with NUMA machines by assigning to each domain
>   a "node affinity", i.e., a set of NUMA nodes of the host from which they
> -get their memory allocated.
> +get their memory allocated. Also, even if the node affinity of a domain
> +is allowed to change on-line, it is very important to "place" the domain
> +correctly when it is fist created, as the most of its memory is allocated
> +at that time and can not (for now) be moved easily.
>
>   NUMA awareness becomes very important as soon as many domains start
>   running memory-intensive workloads on a shared host. In fact, the cost
>   of accessing non node-local memory locations is very high, and the
>   performance degradation is likely to be noticeable.
>
> -## Guest Placement in xl ##
> +For more information, have a look at the [Xen NUMA Introduction][numa_intro]
> +page on the Wiki.
> +
> +### Placing via pinning and cpupools ###
> +
> +The simplest way of placing a domain on a NUMA node is statically pinning
> +the domain's vCPUs to the pCPUs of the node. This goes under the name of
> +CPU affinity and can be set through the "cpus=" option in the config file
> +(more about this below). Another option is to pool together the pCPUs
> +spanning the node and put the domain in such a cpupool with the "pool="
> +config option (as documented in our [Wiki][cpupools_howto]).
> +
> +In both the above cases, the domain will not be able to execute outside
> +the specified set of pCPUs for any reasons, even if all those pCPUs are
> +busy doing something else while there are others, idle, pCPUs.
> +
> +So, when doing this, local memory accesses are 100% guaranteed, but that
> +may come at he cost of some load imbalances.
> +
> +### NUMA aware scheduling ###
> +
> +If the credit scheduler is in use, the concept of node affinity defined
> +above does not only apply to memory. In fact, starting from Xen 4.3, the
> +scheduler always tries to run the domain's vCPUs on one of the nodes in
> +its node affinity. Only if that turns out to be impossible, it will just
> +pick any free pCPU.
> +
> +This is, therefore, something more flexible than CPU affinity, as a domain
> +can still run everywhere, it just prefers some nodes rather than others.
> +Locality of access is less guaranteed than in the pinning case, but that
> +comes along with better chances to exploit all the host resources (e.g.,
> +the pCPUs).
> +
> +In fact, if all the pCPUs in a domain's node affinity are busy, it is
> +possible for the domain to run outside of there, but it is very likely that
> +slower execution (due to remote memory accesses) is still better than no
> +execution at all, as it would happen with pinning. For this reason, NUMA
> +aware scheduling has the potential of bringing substantial performances
> +benefits, although this will depend on the workload.
> +
> +## Guest placement in xl ##
>
>   If using xl for creating and managing guests, it is very easy to ask for
>   both manual or automatic placement of them across the host's NUMA nodes.
>
> -Note that xm/xend does the very same thing, the only differences residing
> -in the details of the heuristics adopted for the placement (see below).
> +Note that xm/xend does a very similar thing, the only differences being
> +the details of the heuristics adopted for automatic placement (see below),
> +and the lack of support (in both xm/xend and the Xen versions where that\
> +was the default toolstack) for NUMA aware scheduling.
>
> -### Manual Guest Placement with xl ###
> +### Placing the guest manually ###
>
>   Thanks to the "cpus=" option, it is possible to specify where a domain
>   should be created and scheduled on, directly in its config file. This
> @@ -41,14 +86,19 @@ This is very simple and effective, but r
>   administrator to explicitly specify affinities for each and every domain,
>   or Xen won't be able to guarantee the locality for their memory accesses.
>
> -It is also possible to deal with NUMA by partitioning the system using
> -cpupools. Again, this could be "The Right Answer" for many needs and
> -occasions, but has to be carefully considered and setup by hand.
> +Notice that this also pins the domain's vCPUs to the specified set of
> +pCPUs, so it not only sets the domain's node affinity (its memory will
> +come from the nodes to which the pCPUs belong), but at the same time
> +forces the vCPUs of the domain to be scheduled on those same pCPUs.
>
> -### Automatic Guest Placement with xl ###
> +### Placing the guest automatically ###
>
>   If no "cpus=" option is specified in the config file, libxl tries
>   to figure out on its own on which node(s) the domain could fit best.
> +If it finds one (some), the domain's node affinity get set to there,
> +and both memory allocations and NUMA aware scheduling (for the credit
> +scheduler and starting from Xen 4.3) will comply with it.
> +
>   It is worthwhile noting that optimally fitting a set of VMs on the NUMA
>   nodes of an host is an incarnation of the Bin Packing Problem. In fact,
>   the various VMs with different memory sizes are the items to be packed,
> @@ -81,7 +131,7 @@ largest amounts of free memory helps kee
>   small, and maximizes the probability of being able to put more domains
>   there.
>
> -## Guest Placement within libxl ##
> +## Guest placement in libxl ##
>
>   xl achieves automatic NUMA placement because that is what libxl does
>   by default. No API is provided (yet) for modifying the behaviour of
> @@ -93,15 +143,34 @@ any placement from happening:
>       libxl_defbool_set(&domain_build_info->numa_placement, false);
>
>   Also, if `numa_placement` is set to `true`, the domain must not
> -have any cpu affinity (i.e., `domain_build_info->cpumap` must
> +have any CPU affinity (i.e., `domain_build_info->cpumap` must
>   have all its bits set, as it is by default), or domain creation
>   will fail returning `ERROR_INVAL`.
>
> +Starting from Xen 4.3, in case automatic placement happens (and is
> +successful), it will affect the domain's node affinity and _not_ its
> +CPU affinity. Namely, the domain's vCPUs will not be pinned to any
> +pCPU on the host, but the memory from the domain will come from the
> +selected node(s) and the NUMA aware scheduling (if the credit scheduler
> +is in use) will try to keep the domain there as much as possible.
> +
>   Besides than that, looking and/or tweaking the placement algorithm
>   search "Automatic NUMA placement" in libxl\_internal.h.
>
>   Note this may change in future versions of Xen/libxl.
>
> +## Xen<  4.3 ##
> +
> +As NUMA aware scheduling is a new feature of Xen 4.3, things are a little
> +bit different for earlier version of Xen. If no "cpus=" option is specified
> +and Xen 4.2 is in use, the automatic placement algorithm still runs, but
> +the results is used to _pin_ the vCPUs of the domain to the output node(s).
> +This is consistent with what was happening with xm/xend, which were also
> +affecting the domain's CPU affinity.
> +
> +On a version of Xen earlier than 4.2, there is not automatic placement at
> +all in xl or libxl, and hence no node or CPU affinity being affected.
> +
>   ## Limitations ##
>
>   Analyzing various possible placement solutions is what makes the
> @@ -109,3 +178,6 @@ algorithm flexible and quite effective.
>   it won't scale well to systems with arbitrary number of nodes.
>   For this reason, automatic placement is disabled (with a warning)
>   if it is requested on a host with more than 16 NUMA nodes.
> +
> +[numa_intro]: http://wiki.xen.org/wiki/Xen_NUMA_Introduction
> +[cpupools_howto]: http://wiki.xen.org/wiki/Cpupools_Howto
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 13:42:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13:42: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 1U1GsK-0002mu-KD; Fri, 01 Feb 2013 13:41:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1GsI-0002mp-E9
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:41:50 +0000
Received: from [85.158.139.83:46194] by server-15.bemta-5.messagelabs.com id
	B2/40-18914-D16CB015; Fri, 01 Feb 2013 13:41:49 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359726108!29572932!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4MTA1MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29349 invoked from network); 1 Feb 2013 13:41:48 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 13:41:48 -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=kNyUS4hK33DGs8BGgApCSspg532AFZyXdj/Hk8p/SaiqgZKhs0tGQwE7
	G5zC6t9sv4gJhxbG9KWl5ELUVuMCXhVPhvIZPF66pAtBl/ypmIEK3SO5S
	5TQIF7QxymY/Bbacwz/bZBrb0oBcLGauV0FFFTCfQa0brfhD5UysXms9J
	UWCjO5DHz1Sku54X8/NYWm6CumyPnQAgqxiZerlq6x/voE30Kn5y7qyzs
	747qcv4JN0ImIGDiqKY6rYmGSO2vi;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359726108; x=1391262108;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=uana1EKEHESaE7LI5XmB5O8uSkmwhu5GD7Ikk0wi6rY=;
	b=Debs9tyDxl4umJZvtZxyHu0Xz/QkoIOPsa5IJcsCEPmM706VmJ5k6PSl
	yzDphgXr3h3jrVhYLVY99tuis3+r5fqLmSdOSyx1LSiuS8Il4i4anRXrw
	RUJXsaFMkzBEh7FLfBDRcTp6ZXaHjtxOag1QUcjriW99V8imWqhotaq4n
	P3HRtqKaiXHByYeeJ+2vNBVOxaIHFGWhhLyLe88OZDuKBCJrerTBb6uE3
	yFY1eckB7PsJSPqQlhFAHuCdb4ei6;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="135525744"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 01 Feb 2013 14:41:48 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="158060454"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with SMTP; 01 Feb 2013 14:41:47 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3928496BB1C;
	Fri,  1 Feb 2013 14:41:47 +0100 (CET)
Message-ID: <510BC61B.6090300@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 14:41:47 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<f05ac3f656309bc71d43.1359716481@Solace>
In-Reply-To: <f05ac3f656309bc71d43.1359716481@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 11 of 11 v3] docs: rearrange and update 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-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 01.02.2013 12:01, schrieb Dario Faggioli:
> To include the new concept of NUMA aware scheduling and
> describe its impact.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

>
> diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
> --- a/docs/misc/xl-numa-placement.markdown
> +++ b/docs/misc/xl-numa-placement.markdown
> @@ -14,22 +14,67 @@ the memory directly attached to the set
>
>   The Xen hypervisor deals with NUMA machines by assigning to each domain
>   a "node affinity", i.e., a set of NUMA nodes of the host from which they
> -get their memory allocated.
> +get their memory allocated. Also, even if the node affinity of a domain
> +is allowed to change on-line, it is very important to "place" the domain
> +correctly when it is fist created, as the most of its memory is allocated
> +at that time and can not (for now) be moved easily.
>
>   NUMA awareness becomes very important as soon as many domains start
>   running memory-intensive workloads on a shared host. In fact, the cost
>   of accessing non node-local memory locations is very high, and the
>   performance degradation is likely to be noticeable.
>
> -## Guest Placement in xl ##
> +For more information, have a look at the [Xen NUMA Introduction][numa_intro]
> +page on the Wiki.
> +
> +### Placing via pinning and cpupools ###
> +
> +The simplest way of placing a domain on a NUMA node is statically pinning
> +the domain's vCPUs to the pCPUs of the node. This goes under the name of
> +CPU affinity and can be set through the "cpus=" option in the config file
> +(more about this below). Another option is to pool together the pCPUs
> +spanning the node and put the domain in such a cpupool with the "pool="
> +config option (as documented in our [Wiki][cpupools_howto]).
> +
> +In both the above cases, the domain will not be able to execute outside
> +the specified set of pCPUs for any reasons, even if all those pCPUs are
> +busy doing something else while there are others, idle, pCPUs.
> +
> +So, when doing this, local memory accesses are 100% guaranteed, but that
> +may come at he cost of some load imbalances.
> +
> +### NUMA aware scheduling ###
> +
> +If the credit scheduler is in use, the concept of node affinity defined
> +above does not only apply to memory. In fact, starting from Xen 4.3, the
> +scheduler always tries to run the domain's vCPUs on one of the nodes in
> +its node affinity. Only if that turns out to be impossible, it will just
> +pick any free pCPU.
> +
> +This is, therefore, something more flexible than CPU affinity, as a domain
> +can still run everywhere, it just prefers some nodes rather than others.
> +Locality of access is less guaranteed than in the pinning case, but that
> +comes along with better chances to exploit all the host resources (e.g.,
> +the pCPUs).
> +
> +In fact, if all the pCPUs in a domain's node affinity are busy, it is
> +possible for the domain to run outside of there, but it is very likely that
> +slower execution (due to remote memory accesses) is still better than no
> +execution at all, as it would happen with pinning. For this reason, NUMA
> +aware scheduling has the potential of bringing substantial performances
> +benefits, although this will depend on the workload.
> +
> +## Guest placement in xl ##
>
>   If using xl for creating and managing guests, it is very easy to ask for
>   both manual or automatic placement of them across the host's NUMA nodes.
>
> -Note that xm/xend does the very same thing, the only differences residing
> -in the details of the heuristics adopted for the placement (see below).
> +Note that xm/xend does a very similar thing, the only differences being
> +the details of the heuristics adopted for automatic placement (see below),
> +and the lack of support (in both xm/xend and the Xen versions where that\
> +was the default toolstack) for NUMA aware scheduling.
>
> -### Manual Guest Placement with xl ###
> +### Placing the guest manually ###
>
>   Thanks to the "cpus=" option, it is possible to specify where a domain
>   should be created and scheduled on, directly in its config file. This
> @@ -41,14 +86,19 @@ This is very simple and effective, but r
>   administrator to explicitly specify affinities for each and every domain,
>   or Xen won't be able to guarantee the locality for their memory accesses.
>
> -It is also possible to deal with NUMA by partitioning the system using
> -cpupools. Again, this could be "The Right Answer" for many needs and
> -occasions, but has to be carefully considered and setup by hand.
> +Notice that this also pins the domain's vCPUs to the specified set of
> +pCPUs, so it not only sets the domain's node affinity (its memory will
> +come from the nodes to which the pCPUs belong), but at the same time
> +forces the vCPUs of the domain to be scheduled on those same pCPUs.
>
> -### Automatic Guest Placement with xl ###
> +### Placing the guest automatically ###
>
>   If no "cpus=" option is specified in the config file, libxl tries
>   to figure out on its own on which node(s) the domain could fit best.
> +If it finds one (some), the domain's node affinity get set to there,
> +and both memory allocations and NUMA aware scheduling (for the credit
> +scheduler and starting from Xen 4.3) will comply with it.
> +
>   It is worthwhile noting that optimally fitting a set of VMs on the NUMA
>   nodes of an host is an incarnation of the Bin Packing Problem. In fact,
>   the various VMs with different memory sizes are the items to be packed,
> @@ -81,7 +131,7 @@ largest amounts of free memory helps kee
>   small, and maximizes the probability of being able to put more domains
>   there.
>
> -## Guest Placement within libxl ##
> +## Guest placement in libxl ##
>
>   xl achieves automatic NUMA placement because that is what libxl does
>   by default. No API is provided (yet) for modifying the behaviour of
> @@ -93,15 +143,34 @@ any placement from happening:
>       libxl_defbool_set(&domain_build_info->numa_placement, false);
>
>   Also, if `numa_placement` is set to `true`, the domain must not
> -have any cpu affinity (i.e., `domain_build_info->cpumap` must
> +have any CPU affinity (i.e., `domain_build_info->cpumap` must
>   have all its bits set, as it is by default), or domain creation
>   will fail returning `ERROR_INVAL`.
>
> +Starting from Xen 4.3, in case automatic placement happens (and is
> +successful), it will affect the domain's node affinity and _not_ its
> +CPU affinity. Namely, the domain's vCPUs will not be pinned to any
> +pCPU on the host, but the memory from the domain will come from the
> +selected node(s) and the NUMA aware scheduling (if the credit scheduler
> +is in use) will try to keep the domain there as much as possible.
> +
>   Besides than that, looking and/or tweaking the placement algorithm
>   search "Automatic NUMA placement" in libxl\_internal.h.
>
>   Note this may change in future versions of Xen/libxl.
>
> +## Xen<  4.3 ##
> +
> +As NUMA aware scheduling is a new feature of Xen 4.3, things are a little
> +bit different for earlier version of Xen. If no "cpus=" option is specified
> +and Xen 4.2 is in use, the automatic placement algorithm still runs, but
> +the results is used to _pin_ the vCPUs of the domain to the output node(s).
> +This is consistent with what was happening with xm/xend, which were also
> +affecting the domain's CPU affinity.
> +
> +On a version of Xen earlier than 4.2, there is not automatic placement at
> +all in xl or libxl, and hence no node or CPU affinity being affected.
> +
>   ## Limitations ##
>
>   Analyzing various possible placement solutions is what makes the
> @@ -109,3 +178,6 @@ algorithm flexible and quite effective.
>   it won't scale well to systems with arbitrary number of nodes.
>   For this reason, automatic placement is disabled (with a warning)
>   if it is requested on a host with more than 16 NUMA nodes.
> +
> +[numa_intro]: http://wiki.xen.org/wiki/Xen_NUMA_Introduction
> +[cpupools_howto]: http://wiki.xen.org/wiki/Cpupools_Howto
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 13:57:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13: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 1U1H7C-00030n-CV; Fri, 01 Feb 2013 13:57:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1H7B-00030i-Jm
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:57:13 +0000
Received: from [85.158.139.83:36371] by server-11.bemta-5.messagelabs.com id
	7C/F7-19159-8B9CB015; Fri, 01 Feb 2013 13:57:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1359727032!30007416!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25971 invoked from network); 1 Feb 2013 13:57:12 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 13:57:12 -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=m+yvpdcO8up/Xbis+HnX1r+S4Gc28NfEEzpNCbQgNS8S+YGIL7Nueqf+
	2hQG70C1vGNwAKlOcD7m+/XPqgRJV4CWJfpb6qv6NMADhWX5bp3e5Z8mo
	Zf5z53dNd5E+4YyR9feOFsHW9YoDB16J1ZFrJah530baiW6OH5qAgoSLC
	O4xv/t0u2qs9c18117yhBx7zs4HBEQi0N7/4U8B8J7N9uTMwUgW6Fi3lN
	x9fCRsPWz/eo56+/2/1QczeUvQnvm;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359727032; x=1391263032;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aeq1u9MbBWp5zq20cRYCWWq09w45H3m/8AfA4maPHQQ=;
	b=IHdx2r0EgFNIw59Nmbh0OtaS7EHMVYpdMvgHAQ8NMjmsPvc3tlwAlyMK
	2IW1ReczSxayURVuEj/Q2qk7tFJFDobSjfKpdyV0LVtsXbCSMJzjdJHho
	+uZsJ4Ckttg1XAk2/72r6XMhugdHcqntHtyt9jJqvjTdh23GMkKDBcj72
	4dGdRxxvtXEWAQDHaF/rLIPoBbhU6xMAIY5pTEWTa9zLQu7nts5zsjy41
	WbYZ1Ty0MFIFWvuJKqQovL+rc99x0;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114891792"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 14:57:12 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="157105273"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with SMTP; 01 Feb 2013 14:57:11 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id D54D6970FD7;
	Fri,  1 Feb 2013 14:57:11 +0100 (CET)
Message-ID: <510BC9B7.6030906@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 14:57:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<45d2f5dc459ce84ca7ee.1359716473@Solace>
In-Reply-To: <45d2f5dc459ce84ca7ee.1359716473@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 03 of 11 v3] xen: sched_credit: when picking,
 make sure we get an idle one, if any
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 01.02.2013 12:01, schrieb Dario Faggioli:
> The pcpu picking algorithm treats two threads of a SMT core the same.
> More specifically, if one is idle and the other one is busy, they both
> will be assigned a weight of 1. Therefore, when picking begins, if the
> first target pcpu is the busy thread (and if there are no other idle
> pcpu than its sibling), that will never change.
>
> This change fixes this by ensuring that, before entering the core of
> the picking algorithm, the target pcpu is an idle one (if there is an
> idle pcpu at all, of course).
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

>
> 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
> @@ -526,6 +526,18 @@ static int
>       if ( vc->processor == cpu&&  IS_RUNQ_IDLE(cpu) )
>           cpumask_set_cpu(cpu,&idlers);
>       cpumask_and(&cpus,&cpus,&idlers);
> +
> +    /*
> +     * It is important that cpu points to an idle processor, if a suitable
> +     * one exists (and we can use cpus to check and, possibly, choose a new
> +     * CPU, as we just&&-ed it with idlers). In fact, if we are on SMT, and
> +     * cpu points to a busy thread with an idle sibling, both the threads
> +     * will be considered the same, from the "idleness" calculation point
> +     * of view", preventing vcpu from being moved to the thread that is
> +     * actually idle.
> +     */
> +    if ( !cpumask_empty(&cpus)&&  !cpumask_test_cpu(cpu,&cpus) )
> +        cpu = cpumask_cycle(cpu,&cpus);
>       cpumask_clear_cpu(cpu,&cpus);
>
>       while ( !cpumask_empty(&cpus) )
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 13:57:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 13: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 1U1H7C-00030n-CV; Fri, 01 Feb 2013 13:57:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1H7B-00030i-Jm
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 13:57:13 +0000
Received: from [85.158.139.83:36371] by server-11.bemta-5.messagelabs.com id
	7C/F7-19159-8B9CB015; Fri, 01 Feb 2013 13:57:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1359727032!30007416!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25971 invoked from network); 1 Feb 2013 13:57:12 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 13:57:12 -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=m+yvpdcO8up/Xbis+HnX1r+S4Gc28NfEEzpNCbQgNS8S+YGIL7Nueqf+
	2hQG70C1vGNwAKlOcD7m+/XPqgRJV4CWJfpb6qv6NMADhWX5bp3e5Z8mo
	Zf5z53dNd5E+4YyR9feOFsHW9YoDB16J1ZFrJah530baiW6OH5qAgoSLC
	O4xv/t0u2qs9c18117yhBx7zs4HBEQi0N7/4U8B8J7N9uTMwUgW6Fi3lN
	x9fCRsPWz/eo56+/2/1QczeUvQnvm;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359727032; x=1391263032;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=aeq1u9MbBWp5zq20cRYCWWq09w45H3m/8AfA4maPHQQ=;
	b=IHdx2r0EgFNIw59Nmbh0OtaS7EHMVYpdMvgHAQ8NMjmsPvc3tlwAlyMK
	2IW1ReczSxayURVuEj/Q2qk7tFJFDobSjfKpdyV0LVtsXbCSMJzjdJHho
	+uZsJ4Ckttg1XAk2/72r6XMhugdHcqntHtyt9jJqvjTdh23GMkKDBcj72
	4dGdRxxvtXEWAQDHaF/rLIPoBbhU6xMAIY5pTEWTa9zLQu7nts5zsjy41
	WbYZ1Ty0MFIFWvuJKqQovL+rc99x0;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114891792"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 14:57:12 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="157105273"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with SMTP; 01 Feb 2013 14:57:11 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id D54D6970FD7;
	Fri,  1 Feb 2013 14:57:11 +0100 (CET)
Message-ID: <510BC9B7.6030906@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 14:57:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<45d2f5dc459ce84ca7ee.1359716473@Solace>
In-Reply-To: <45d2f5dc459ce84ca7ee.1359716473@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 03 of 11 v3] xen: sched_credit: when picking,
 make sure we get an idle one, if any
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 01.02.2013 12:01, schrieb Dario Faggioli:
> The pcpu picking algorithm treats two threads of a SMT core the same.
> More specifically, if one is idle and the other one is busy, they both
> will be assigned a weight of 1. Therefore, when picking begins, if the
> first target pcpu is the busy thread (and if there are no other idle
> pcpu than its sibling), that will never change.
>
> This change fixes this by ensuring that, before entering the core of
> the picking algorithm, the target pcpu is an idle one (if there is an
> idle pcpu at all, of course).
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

>
> 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
> @@ -526,6 +526,18 @@ static int
>       if ( vc->processor == cpu&&  IS_RUNQ_IDLE(cpu) )
>           cpumask_set_cpu(cpu,&idlers);
>       cpumask_and(&cpus,&cpus,&idlers);
> +
> +    /*
> +     * It is important that cpu points to an idle processor, if a suitable
> +     * one exists (and we can use cpus to check and, possibly, choose a new
> +     * CPU, as we just&&-ed it with idlers). In fact, if we are on SMT, and
> +     * cpu points to a busy thread with an idle sibling, both the threads
> +     * will be considered the same, from the "idleness" calculation point
> +     * of view", preventing vcpu from being moved to the thread that is
> +     * actually idle.
> +     */
> +    if ( !cpumask_empty(&cpus)&&  !cpumask_test_cpu(cpu,&cpus) )
> +        cpu = cpumask_cycle(cpu,&cpus);
>       cpumask_clear_cpu(cpu,&cpus);
>
>       while ( !cpumask_empty(&cpus) )
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 14:18:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:18: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 1U1HRf-0003Js-LS; Fri, 01 Feb 2013 14:18:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <digvijaych@gmail.com>) id 1U1HRd-0003Jl-MM
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 14:18:21 +0000
Received: from [85.158.139.211:16207] by server-6.bemta-5.messagelabs.com id
	33/11-01489-CAECB015; Fri, 01 Feb 2013 14:18:20 +0000
X-Env-Sender: digvijaych@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1359728299!20665328!1
X-Originating-IP: [209.85.215.41]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17920 invoked from network); 1 Feb 2013 14:18:19 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:18:19 -0000
Received: by mail-la0-f41.google.com with SMTP id fo12so2869833lab.0
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Feb 2013 06:18:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=HFCfntkWU35LWM/dwQ+jVlkLCkoWt+9st+5iAYXQvkQ=;
	b=QFpAQR8Xu8EpkMkFcTvGqYGDIGZ8Lw3fblbJpYeVDGMH6tdQj6+N1QOvpdMP1hL6bJ
	TG8uCNEaPFLHzIGg2UlsdJuNpf4bKqNyqkKeQRALrtYRgbPrzNVJebXcvZYFqGRFl4mj
	ujLCUDjlTPMfTTFAl7EwdzfY/Uyx5S1pQE4TcerzBBoR+xS7nsbUqukjOmpJEKK8J3aY
	0DJPfAbka+4SUC/6ftWv0oOSwsv07R/wszxjP7bRTH3ZKyJWaTUNsBX4Pt0T57/4/TyO
	oYdWzar3lTkc6s7J/7k4sfgTKeaVRsUfiMhMy1QVXbqXJLYmWXwHb/xTLlVqS2e66Vfo
	KZog==
MIME-Version: 1.0
X-Received: by 10.112.47.168 with SMTP id e8mr4853989lbn.46.1359728298551;
	Fri, 01 Feb 2013 06:18:18 -0800 (PST)
Received: by 10.112.79.37 with HTTP; Fri, 1 Feb 2013 06:18:18 -0800 (PST)
Date: Fri, 1 Feb 2013 19:48:18 +0530
Message-ID: <CANq0ewvS6ryme4aRMLOqg=bx1CKNoZWUpgf4iJrmMEDmt_3Djg@mail.gmail.com>
From: digvijay chauhan <digvijaych@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xensource.com
Subject: [Xen-devel] how to use sctp during live migration of vm with 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="===============2998497454009598700=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2998497454009598700==
Content-Type: multipart/alternative; boundary=bcaec553fde039e9bd04d4aa6a02

--bcaec553fde039e9bd04d4aa6a02
Content-Type: text/plain; charset=ISO-8859-1

Hello,
         I want to carry out the performance analysis of transport protocol
i.e sctp so how can we achieve it.Instead of using tcp if we have to use
sctp how to do that?



regards,
DigvijaySingh

--bcaec553fde039e9bd04d4aa6a02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello, <br>=A0=A0=A0=A0=A0=A0=A0=A0 I want to carry out the performance ana=
lysis of transport protocol i.e sctp so how can we achieve it.Instead of us=
ing tcp if we have to use sctp how to do that?<br><br><br><br>regards,<br>D=
igvijaySingh<br>

--bcaec553fde039e9bd04d4aa6a02--


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

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

--===============2998497454009598700==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 14:18:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:18: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 1U1HRf-0003Js-LS; Fri, 01 Feb 2013 14:18:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <digvijaych@gmail.com>) id 1U1HRd-0003Jl-MM
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 14:18:21 +0000
Received: from [85.158.139.211:16207] by server-6.bemta-5.messagelabs.com id
	33/11-01489-CAECB015; Fri, 01 Feb 2013 14:18:20 +0000
X-Env-Sender: digvijaych@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1359728299!20665328!1
X-Originating-IP: [209.85.215.41]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17920 invoked from network); 1 Feb 2013 14:18:19 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:18:19 -0000
Received: by mail-la0-f41.google.com with SMTP id fo12so2869833lab.0
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Feb 2013 06:18:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=HFCfntkWU35LWM/dwQ+jVlkLCkoWt+9st+5iAYXQvkQ=;
	b=QFpAQR8Xu8EpkMkFcTvGqYGDIGZ8Lw3fblbJpYeVDGMH6tdQj6+N1QOvpdMP1hL6bJ
	TG8uCNEaPFLHzIGg2UlsdJuNpf4bKqNyqkKeQRALrtYRgbPrzNVJebXcvZYFqGRFl4mj
	ujLCUDjlTPMfTTFAl7EwdzfY/Uyx5S1pQE4TcerzBBoR+xS7nsbUqukjOmpJEKK8J3aY
	0DJPfAbka+4SUC/6ftWv0oOSwsv07R/wszxjP7bRTH3ZKyJWaTUNsBX4Pt0T57/4/TyO
	oYdWzar3lTkc6s7J/7k4sfgTKeaVRsUfiMhMy1QVXbqXJLYmWXwHb/xTLlVqS2e66Vfo
	KZog==
MIME-Version: 1.0
X-Received: by 10.112.47.168 with SMTP id e8mr4853989lbn.46.1359728298551;
	Fri, 01 Feb 2013 06:18:18 -0800 (PST)
Received: by 10.112.79.37 with HTTP; Fri, 1 Feb 2013 06:18:18 -0800 (PST)
Date: Fri, 1 Feb 2013 19:48:18 +0530
Message-ID: <CANq0ewvS6ryme4aRMLOqg=bx1CKNoZWUpgf4iJrmMEDmt_3Djg@mail.gmail.com>
From: digvijay chauhan <digvijaych@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xensource.com
Subject: [Xen-devel] how to use sctp during live migration of vm with 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="===============2998497454009598700=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2998497454009598700==
Content-Type: multipart/alternative; boundary=bcaec553fde039e9bd04d4aa6a02

--bcaec553fde039e9bd04d4aa6a02
Content-Type: text/plain; charset=ISO-8859-1

Hello,
         I want to carry out the performance analysis of transport protocol
i.e sctp so how can we achieve it.Instead of using tcp if we have to use
sctp how to do that?



regards,
DigvijaySingh

--bcaec553fde039e9bd04d4aa6a02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello, <br>=A0=A0=A0=A0=A0=A0=A0=A0 I want to carry out the performance ana=
lysis of transport protocol i.e sctp so how can we achieve it.Instead of us=
ing tcp if we have to use sctp how to do that?<br><br><br><br>regards,<br>D=
igvijaySingh<br>

--bcaec553fde039e9bd04d4aa6a02--


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

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

--===============2998497454009598700==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 14:21:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:21: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 1U1HUA-0003Xu-SG; Fri, 01 Feb 2013 14:20:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1HU9-0003WW-8g
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:20:57 +0000
Received: from [85.158.143.35:37167] by server-2.bemta-4.messagelabs.com id
	15/98-01597-84FCB015; Fri, 01 Feb 2013 14:20:56 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359728418!10154857!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17907 invoked from network); 1 Feb 2013 14:20:29 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 14:20:29 -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=oeTHeaXe3nu3ozW4I94Xasu15jg6daqqn9HwUpoje8G3dQP2XIXqOXaj
	U3Jj4d2ONdAGLiA0VBP0xnG/iBpE5LE8g+Pt4/pyi6iGnDM2mQu51Z0ZM
	rmX8wgv4GLTME9iSkun/debASHsRVGpBd4oLGu7CXiXmpSbAmxHW+dHSJ
	rBo707cTdw+VZw9+VJIgY32ckeJiptVWRQ0eB/x5Xnns/wwdCfEl9nQY/
	ShnP4WSd5wuKTwp0JuhAsAA7zy7Ne;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359728430; x=1391264430;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=KoFXnTQXXFCdrdyl1N/JfgdLUf0Lfv0LrJ9SGPYmQsA=;
	b=BvSt6pb5KxhtyjtS9zQyK2nWBt8T7Hop2HVhn/xSZ8HtDqBHeJxWZYft
	oegKzCVRJ7uTptL0Q4/uE/4v5rSO2kpqdJANOEc3vwj2De+BG3LXH8Z8H
	BfKBRAnQ7bkEbRTxYrcRlr/gOcIW34lbOun1s+tdcH7R8/868pzhMM/4o
	WSCV3lqY+AvM/LFQ5h6Jl43AAwO7G7DeDDAiRAuxcDlwsv75uIjaRyXwK
	lNRSHKvRZnuAYrHGvH0+kFfZTEOrL;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114895000"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 15:20:17 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="157106753"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with SMTP; 01 Feb 2013 15:20:16 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 5BB1E9669F9;
	Fri,  1 Feb 2013 15:20:17 +0100 (CET)
Message-ID: <510BCF21.50908@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 15:20:17 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<7ad5cdfea9c033b89415.1359716475@Solace>
In-Reply-To: <7ad5cdfea9c033b89415.1359716475@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 05 of 11 v3] xen: allow for
 explicitly	specifying 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: 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

Am 01.02.2013 12:01, schrieb Dario Faggioli:
> Make it possible to pass the node-affinity of a domain to the hypervisor
> from the upper layers, instead of always being computed automatically.
>
> Note that this also required generalizing the Flask hooks for setting
> and getting the affinity, so that they now deal with both vcpu and
> node affinity.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
> Acked-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
> Acked-by: George Dunlap<george.dunlap@eu.citrix.com>

Except one minor note (see below):

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

> ---
> Changes from v2:
>   * reworked as needed after the merge of Daniel's IS_PRIV work;
>   * xen.te taken care of, as requested during review.
>
> Changes from v1:
>   * added the missing dummy hook for nodeaffinity;
>   * let the permission renaming affect flask policies too.
>
> diff --git a/tools/flask/policy/policy/mls b/tools/flask/policy/policy/mls
> --- a/tools/flask/policy/policy/mls
> +++ b/tools/flask/policy/policy/mls
> @@ -70,11 +70,11 @@ mlsconstrain domain transition
>   	(( h1 dom h2 ) and (( l1 eq l2 ) or (t1 =3D=3D mls_priv)));
>
>   # all the domain "read" ops
> -mlsconstrain domain { getvcpuaffinity getdomaininfo getvcpuinfo getvcpuc=
ontext getaddrsize getextvcpucontext }
> +mlsconstrain domain { getaffinity getdomaininfo getvcpuinfo getvcpuconte=
xt getaddrsize getextvcpucontext }
>   	((l1 dom l2) or (t1 =3D=3D mls_priv));
>
>   # all the domain "write" ops
> -mlsconstrain domain { setvcpucontext pause unpause resume create max_vcp=
us destroy setvcpuaffinity scheduler setdomainmaxmem setdomainhandle setdeb=
ugging hypercall settime set_target shutdown setaddrsize trigger setextvcpu=
context }
> +mlsconstrain domain { setvcpucontext pause unpause resume create max_vcp=
us destroy setaffinity scheduler setdomainmaxmem setdomainhandle setdebuggi=
ng hypercall settime set_target shutdown setaddrsize trigger setextvcpucont=
ext }
>   	((l1 eq l2) or (t1 =3D=3D mls_priv));
>
>   # This is incomplete - similar constraints must be written for all clas=
ses
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/p=
olicy/policy/modules/xen/xen.if
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -48,7 +48,7 @@ define(`create_domain_common', `
>   	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
> -			getvcpuaffinity setvcpuaffinity };
> +			getaffinity setaffinity };
>   	allow $1 $2:domain2 { set_cpuid settsc setscheduler };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
> @@ -77,9 +77,9 @@ define(`create_domain_build_label', `
>   # manage_domain(priv, target)
>   #   Allow managing a running domain
>   define(`manage_domain', `
> -	allow $1 $2:domain { getdomaininfo getvcpuinfo getvcpuaffinity
> +	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
>   			getaddrsize pause unpause trigger shutdown destroy
> -			setvcpuaffinity setdomainmaxmem getscheduler };
> +			setaffinity setdomainmaxmem getscheduler };
>   ')
>
>   # migrate_domain_out(priv, target)
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/p=
olicy/policy/modules/xen/xen.te
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -62,7 +62,7 @@ allow dom0_t security_t:security { check
>   	compute_member load_policy compute_relabel compute_user setenforce
>   	setbool setsecparam add_ocontext del_ocontext };
>
> -allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
> +allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getaffinity };
>   allow dom0_t dom0_t:resource { add remove };
>
>   admin_device(dom0_t, device_t)
> 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 =3D NODE_MASK_ALL;
> +    d->auto_node_affinity =3D 1;
>
>       spin_lock_init(&d->shutdown_lock);
>       d->shutdown_code =3D -1;
> @@ -362,11 +363,26 @@ void domain_update_node_affinity(struct
>           cpumask_or(cpumask, cpumask, online_affinity);
>       }
>
> -    for_each_online_node ( node )
> -        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> -            node_set(node, nodemask);
> +    if ( d->auto_node_affinity )
> +    {
> +        /* Node-affinity is automaically computed from all vcpu-affiniti=
es */
> +        for_each_online_node ( node )
> +            if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_set(node, nodemask);
>
> -    d->node_affinity =3D nodemask;
> +        d->node_affinity =3D nodemask;
> +    }
> +    else
> +    {
> +        /* Node-affinity is provided by someone else, just filter out cp=
us
> +         * that are either offline or not in the affinity of any vcpus. =
*/
> +        for_each_node_mask ( node, d->node_affinity )
> +            if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_clear(node, d->node_affinity);
> +    }
> +
> +    sched_set_node_affinity(d,&d->node_affinity);
> +
>       spin_unlock(&d->node_affinity_lock);
>
>       free_cpumask_var(online_affinity);
> @@ -374,6 +390,36 @@ void domain_update_node_affinity(struct
>   }
>
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinit=
y)
> +{
> +    /* Being affine with no nodes is just wrong */
> +    if ( nodes_empty(*affinity) )
> +        return -EINVAL;
> +
> +    spin_lock(&d->node_affinity_lock);
> +
> +    /*
> +     * Being/becoming explicitly affine to all nodes is not particularly
> +     * useful. Let's take it as the `reset node affinity` command.
> +     */
> +    if ( nodes_full(*affinity) )
> +    {
> +        d->auto_node_affinity =3D 1;
> +        goto out;
> +    }
> +
> +    d->auto_node_affinity =3D 0;
> +    d->node_affinity =3D *affinity;
> +
> +out:
> +    spin_unlock(&d->node_affinity_lock);
> +
> +    domain_update_node_affinity(d);
> +
> +    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
> @@ -559,6 +559,26 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>       }
>       break;
>
> +    case XEN_DOMCTL_setnodeaffinity:
> +    case XEN_DOMCTL_getnodeaffinity:
> +    {
> +        if ( op->cmd =3D=3D XEN_DOMCTL_setnodeaffinity )
> +        {
> +            nodemask_t new_affinity;
> +
> +            ret =3D xenctl_bitmap_to_nodemask(&new_affinity,
> +&op->u.nodeaffinity.nodemap);
> +            if ( !ret )
> +                ret =3D domain_set_node_affinity(d,&new_affinity);
> +        }
> +        else
> +        {
> +            ret =3D nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodema=
p,
> +&d->node_affinity);
> +        }
> +    }
> +    break;
> +

The two cases shouldn't be handled in one block, I think. Only the break
statement seems to be common here.


J=FCrgen

-- =

Juergen Gross                 Principal Developer Operating Systems
PBG 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.ht=
ml

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:21:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:21: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 1U1HUA-0003Xu-SG; Fri, 01 Feb 2013 14:20:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1HU9-0003WW-8g
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:20:57 +0000
Received: from [85.158.143.35:37167] by server-2.bemta-4.messagelabs.com id
	15/98-01597-84FCB015; Fri, 01 Feb 2013 14:20:56 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359728418!10154857!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17907 invoked from network); 1 Feb 2013 14:20:29 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 14:20:29 -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=oeTHeaXe3nu3ozW4I94Xasu15jg6daqqn9HwUpoje8G3dQP2XIXqOXaj
	U3Jj4d2ONdAGLiA0VBP0xnG/iBpE5LE8g+Pt4/pyi6iGnDM2mQu51Z0ZM
	rmX8wgv4GLTME9iSkun/debASHsRVGpBd4oLGu7CXiXmpSbAmxHW+dHSJ
	rBo707cTdw+VZw9+VJIgY32ckeJiptVWRQ0eB/x5Xnns/wwdCfEl9nQY/
	ShnP4WSd5wuKTwp0JuhAsAA7zy7Ne;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359728430; x=1391264430;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=KoFXnTQXXFCdrdyl1N/JfgdLUf0Lfv0LrJ9SGPYmQsA=;
	b=BvSt6pb5KxhtyjtS9zQyK2nWBt8T7Hop2HVhn/xSZ8HtDqBHeJxWZYft
	oegKzCVRJ7uTptL0Q4/uE/4v5rSO2kpqdJANOEc3vwj2De+BG3LXH8Z8H
	BfKBRAnQ7bkEbRTxYrcRlr/gOcIW34lbOun1s+tdcH7R8/868pzhMM/4o
	WSCV3lqY+AvM/LFQ5h6Jl43AAwO7G7DeDDAiRAuxcDlwsv75uIjaRyXwK
	lNRSHKvRZnuAYrHGvH0+kFfZTEOrL;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114895000"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 15:20:17 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="157106753"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with SMTP; 01 Feb 2013 15:20:16 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 5BB1E9669F9;
	Fri,  1 Feb 2013 15:20:17 +0100 (CET)
Message-ID: <510BCF21.50908@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 15:20:17 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<7ad5cdfea9c033b89415.1359716475@Solace>
In-Reply-To: <7ad5cdfea9c033b89415.1359716475@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 05 of 11 v3] xen: allow for
 explicitly	specifying 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: 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

Am 01.02.2013 12:01, schrieb Dario Faggioli:
> Make it possible to pass the node-affinity of a domain to the hypervisor
> from the upper layers, instead of always being computed automatically.
>
> Note that this also required generalizing the Flask hooks for setting
> and getting the affinity, so that they now deal with both vcpu and
> node affinity.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>
> Acked-by: Daniel De Graaf<dgdegra@tycho.nsa.gov>
> Acked-by: George Dunlap<george.dunlap@eu.citrix.com>

Except one minor note (see below):

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

> ---
> Changes from v2:
>   * reworked as needed after the merge of Daniel's IS_PRIV work;
>   * xen.te taken care of, as requested during review.
>
> Changes from v1:
>   * added the missing dummy hook for nodeaffinity;
>   * let the permission renaming affect flask policies too.
>
> diff --git a/tools/flask/policy/policy/mls b/tools/flask/policy/policy/mls
> --- a/tools/flask/policy/policy/mls
> +++ b/tools/flask/policy/policy/mls
> @@ -70,11 +70,11 @@ mlsconstrain domain transition
>   	(( h1 dom h2 ) and (( l1 eq l2 ) or (t1 =3D=3D mls_priv)));
>
>   # all the domain "read" ops
> -mlsconstrain domain { getvcpuaffinity getdomaininfo getvcpuinfo getvcpuc=
ontext getaddrsize getextvcpucontext }
> +mlsconstrain domain { getaffinity getdomaininfo getvcpuinfo getvcpuconte=
xt getaddrsize getextvcpucontext }
>   	((l1 dom l2) or (t1 =3D=3D mls_priv));
>
>   # all the domain "write" ops
> -mlsconstrain domain { setvcpucontext pause unpause resume create max_vcp=
us destroy setvcpuaffinity scheduler setdomainmaxmem setdomainhandle setdeb=
ugging hypercall settime set_target shutdown setaddrsize trigger setextvcpu=
context }
> +mlsconstrain domain { setvcpucontext pause unpause resume create max_vcp=
us destroy setaffinity scheduler setdomainmaxmem setdomainhandle setdebuggi=
ng hypercall settime set_target shutdown setaddrsize trigger setextvcpucont=
ext }
>   	((l1 eq l2) or (t1 =3D=3D mls_priv));
>
>   # This is incomplete - similar constraints must be written for all clas=
ses
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/p=
olicy/policy/modules/xen/xen.if
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -48,7 +48,7 @@ define(`create_domain_common', `
>   	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
>   			getdomaininfo hypercall setvcpucontext setextvcpucontext
>   			getscheduler getvcpuinfo getvcpuextstate getaddrsize
> -			getvcpuaffinity setvcpuaffinity };
> +			getaffinity setaffinity };
>   	allow $1 $2:domain2 { set_cpuid settsc setscheduler };
>   	allow $1 $2:security check_context;
>   	allow $1 $2:shadow enable;
> @@ -77,9 +77,9 @@ define(`create_domain_build_label', `
>   # manage_domain(priv, target)
>   #   Allow managing a running domain
>   define(`manage_domain', `
> -	allow $1 $2:domain { getdomaininfo getvcpuinfo getvcpuaffinity
> +	allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
>   			getaddrsize pause unpause trigger shutdown destroy
> -			setvcpuaffinity setdomainmaxmem getscheduler };
> +			setaffinity setdomainmaxmem getscheduler };
>   ')
>
>   # migrate_domain_out(priv, target)
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/p=
olicy/policy/modules/xen/xen.te
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -62,7 +62,7 @@ allow dom0_t security_t:security { check
>   	compute_member load_policy compute_relabel compute_user setenforce
>   	setbool setsecparam add_ocontext del_ocontext };
>
> -allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
> +allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getaffinity };
>   allow dom0_t dom0_t:resource { add remove };
>
>   admin_device(dom0_t, device_t)
> 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 =3D NODE_MASK_ALL;
> +    d->auto_node_affinity =3D 1;
>
>       spin_lock_init(&d->shutdown_lock);
>       d->shutdown_code =3D -1;
> @@ -362,11 +363,26 @@ void domain_update_node_affinity(struct
>           cpumask_or(cpumask, cpumask, online_affinity);
>       }
>
> -    for_each_online_node ( node )
> -        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> -            node_set(node, nodemask);
> +    if ( d->auto_node_affinity )
> +    {
> +        /* Node-affinity is automaically computed from all vcpu-affiniti=
es */
> +        for_each_online_node ( node )
> +            if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_set(node, nodemask);
>
> -    d->node_affinity =3D nodemask;
> +        d->node_affinity =3D nodemask;
> +    }
> +    else
> +    {
> +        /* Node-affinity is provided by someone else, just filter out cp=
us
> +         * that are either offline or not in the affinity of any vcpus. =
*/
> +        for_each_node_mask ( node, d->node_affinity )
> +            if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_clear(node, d->node_affinity);
> +    }
> +
> +    sched_set_node_affinity(d,&d->node_affinity);
> +
>       spin_unlock(&d->node_affinity_lock);
>
>       free_cpumask_var(online_affinity);
> @@ -374,6 +390,36 @@ void domain_update_node_affinity(struct
>   }
>
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinit=
y)
> +{
> +    /* Being affine with no nodes is just wrong */
> +    if ( nodes_empty(*affinity) )
> +        return -EINVAL;
> +
> +    spin_lock(&d->node_affinity_lock);
> +
> +    /*
> +     * Being/becoming explicitly affine to all nodes is not particularly
> +     * useful. Let's take it as the `reset node affinity` command.
> +     */
> +    if ( nodes_full(*affinity) )
> +    {
> +        d->auto_node_affinity =3D 1;
> +        goto out;
> +    }
> +
> +    d->auto_node_affinity =3D 0;
> +    d->node_affinity =3D *affinity;
> +
> +out:
> +    spin_unlock(&d->node_affinity_lock);
> +
> +    domain_update_node_affinity(d);
> +
> +    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
> @@ -559,6 +559,26 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>       }
>       break;
>
> +    case XEN_DOMCTL_setnodeaffinity:
> +    case XEN_DOMCTL_getnodeaffinity:
> +    {
> +        if ( op->cmd =3D=3D XEN_DOMCTL_setnodeaffinity )
> +        {
> +            nodemask_t new_affinity;
> +
> +            ret =3D xenctl_bitmap_to_nodemask(&new_affinity,
> +&op->u.nodeaffinity.nodemap);
> +            if ( !ret )
> +                ret =3D domain_set_node_affinity(d,&new_affinity);
> +        }
> +        else
> +        {
> +            ret =3D nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodema=
p,
> +&d->node_affinity);
> +        }
> +    }
> +    break;
> +

The two cases shouldn't be handled in one block, I think. Only the break
statement seems to be common here.


J=FCrgen

-- =

Juergen Gross                 Principal Developer Operating Systems
PBG 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.ht=
ml

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:28:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:28: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 1U1Han-0003rz-Pl; Fri, 01 Feb 2013 14:27:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1Ham-0003rs-IE
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:27:48 +0000
Received: from [85.158.143.99:49251] by server-1.bemta-4.messagelabs.com id
	23/D0-08839-3E0DB015; Fri, 01 Feb 2013 14:27:47 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1359728867!25160524!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14781 invoked from network); 1 Feb 2013 14:27:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1069271"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 14:27:47 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 1 Feb 2013
	14:27:47 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "konrad@kernel.org" <konrad@kernel.org>
Date: Fri, 1 Feb 2013 14:27:46 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Adding support for coverage informations
Thread-Index: Ac4AiE4oghgexIREQGiDv1ypjR880w==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458350@LONPMAILBOX01.citrite.net>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
In-Reply-To: <20130130213418.GC1885@konrad-lan.dumpdata.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: George Dunlap <George.Dunlap@eu.citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-30 at 16:34 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 29, 2013 at 12:02:55PM +0000, Frediano Ziglio wrote:
> > On Tue, 2013-01-29 at 10:56 +0000, Ian Campbell wrote:
> > > On Mon, 2013-01-28 at 21:16 +0000, Frediano Ziglio wrote:
> > > > From: Frediano Ziglio <frediano.ziglio@citrix.com>
> > > > 
> > > > This patch introduce coverage support to Xen.
> > > > Currently it allows to compile Xen with coverage support but there is no way
> > > > to extract them.
> > > > 
> > > > The declarations came from Linux source files (as you can see from file
> > > > headers).
> > > > 
> > > > It also add a new hypercall (can somebody reserve a number for this stuff?).
> > > 
> > > You can simply patch xen/include/public/xen.h to declare the new
> > > __HYPERVISOR_foo_op. (which I now see you have done in this patch!). If
> > > you just want to reserve the number it is also allowed to send just that
> > > hunk to reserve a number pending the implementation.
> > > 
> > > BTW I'd suggest leaving the stub implementation out of the patch until
> > > you've decided what it will look like, so it returns ENOSYS instead of
> > > EINVAL (or change your stub to return ENOSYS).
> > > 
> > 
> > Easy to change. Actually I discovered that my patch does not even
> > compile if you disable TEST_COVERAGE (and it should be disabled by
> > default too). EINVAL say that the hypercall is present but the value
> > passed in invalid.
> > 
> > The reason why adding a new hypercall instead of a new sysctl is simply
> > because is easier to have a zero cost if you disable coverage
> > informations. The best thing would be redirect do_coverage_op to
> > do_ni_hypercall using linker options but even two small stub would do
> > (these stubs will return ENOSYS instead).
> 
> I am not sure I follow. Is the sysctl hypercall code path "longer" than
> the hypercall path you are introducing? What is the zero cost?

Require more changes to code already present and more compiled in code.
Yes, perhaps I'm too paranoid, I'm talking about a bunch of bytes never
executed.

Frediano

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:28:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:28: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 1U1Han-0003rz-Pl; Fri, 01 Feb 2013 14:27:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1Ham-0003rs-IE
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:27:48 +0000
Received: from [85.158.143.99:49251] by server-1.bemta-4.messagelabs.com id
	23/D0-08839-3E0DB015; Fri, 01 Feb 2013 14:27:47 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1359728867!25160524!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14781 invoked from network); 1 Feb 2013 14:27:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1069271"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 14:27:47 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 1 Feb 2013
	14:27:47 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "konrad@kernel.org" <konrad@kernel.org>
Date: Fri, 1 Feb 2013 14:27:46 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Adding support for coverage informations
Thread-Index: Ac4AiE4oghgexIREQGiDv1ypjR880w==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458350@LONPMAILBOX01.citrite.net>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
In-Reply-To: <20130130213418.GC1885@konrad-lan.dumpdata.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: George Dunlap <George.Dunlap@eu.citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-30 at 16:34 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 29, 2013 at 12:02:55PM +0000, Frediano Ziglio wrote:
> > On Tue, 2013-01-29 at 10:56 +0000, Ian Campbell wrote:
> > > On Mon, 2013-01-28 at 21:16 +0000, Frediano Ziglio wrote:
> > > > From: Frediano Ziglio <frediano.ziglio@citrix.com>
> > > > 
> > > > This patch introduce coverage support to Xen.
> > > > Currently it allows to compile Xen with coverage support but there is no way
> > > > to extract them.
> > > > 
> > > > The declarations came from Linux source files (as you can see from file
> > > > headers).
> > > > 
> > > > It also add a new hypercall (can somebody reserve a number for this stuff?).
> > > 
> > > You can simply patch xen/include/public/xen.h to declare the new
> > > __HYPERVISOR_foo_op. (which I now see you have done in this patch!). If
> > > you just want to reserve the number it is also allowed to send just that
> > > hunk to reserve a number pending the implementation.
> > > 
> > > BTW I'd suggest leaving the stub implementation out of the patch until
> > > you've decided what it will look like, so it returns ENOSYS instead of
> > > EINVAL (or change your stub to return ENOSYS).
> > > 
> > 
> > Easy to change. Actually I discovered that my patch does not even
> > compile if you disable TEST_COVERAGE (and it should be disabled by
> > default too). EINVAL say that the hypercall is present but the value
> > passed in invalid.
> > 
> > The reason why adding a new hypercall instead of a new sysctl is simply
> > because is easier to have a zero cost if you disable coverage
> > informations. The best thing would be redirect do_coverage_op to
> > do_ni_hypercall using linker options but even two small stub would do
> > (these stubs will return ENOSYS instead).
> 
> I am not sure I follow. Is the sysctl hypercall code path "longer" than
> the hypercall path you are introducing? What is the zero cost?

Require more changes to code already present and more compiled in code.
Yes, perhaps I'm too paranoid, I'm talking about a bunch of bytes never
executed.

Frediano

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:29:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:29: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 1U1Hbw-0003wr-8f; Fri, 01 Feb 2013 14:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1Hbu-0003wZ-59
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:28:58 +0000
Received: from [85.158.143.99:55498] by server-1.bemta-4.messagelabs.com id
	6B/52-08839-921DB015; Fri, 01 Feb 2013 14:28:57 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359728932!20840296!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29865 invoked from network); 1 Feb 2013 14:28:55 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 14:28:55 -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=oe1YR8ao36s4AUosso9D0rGt8yjc+PudWPxiy2jjaZkpKHbuZZZY7lmv
	azjiCWxzn+r1UQIx9xa/vjSBN/LnJJDUnHggLIRZq/E+9GF2KbNtQ2Un3
	EYhYlzUg+c9Hrg5zKa9ELeVUs7aQ8A46rW6OdH3XBsaQc043yPa287CRV
	NkGfR2AiFfyHeM4tjIB/WN1J2PJuMtAIc2xsSOIksCu5za0sKzXBSEdVW
	Saw3fSJhiOok4lxJtRUT8BuQj9/mc;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359728935; x=1391264935;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=G8kL0+v3WCJbGO3VcVI1tuwMXVBnzBYGTjino9N0FmM=;
	b=hv5aekijGcb90tTvUA5gGgdas4UMNnH6aUI9Ck9L37GjS4xFrpkx52wf
	erpcJFE6r5Tfwe1C4MtPfRBvwxJ1PnB7+iuH/wIo2ymi7pNjNa1cUop1a
	LG2jr8fBudo8fDm+wceURBzqlaQ401nflESigVi+yRnSfbfkpCNvGa1t7
	TsUJnguQEolkpsrGgGxuzTdF4KaNw/TqCcV0g5P4us6LV/3boBIATEvqo
	XGBPy9xb9GErD5F9SFc923I10ACKr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114895889"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 15:28:52 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="157107435"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with SMTP; 01 Feb 2013 15:28:51 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 8E91F9669F9;
	Fri,  1 Feb 2013 15:28:51 +0100 (CET)
Message-ID: <510BD123.1010203@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 15:28:51 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<4e5a5f4ba12771415995.1359716478@Solace>
In-Reply-To: <4e5a5f4ba12771415995.1359716478@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 08 of 11 v3] libxl: optimize the calculation
 of how many VCPUs can run on a candidate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 01.02.2013 12:01, schrieb Dario Faggioli:
> For choosing the best NUMA placement candidate, we need to figure out
> how many VCPUs are runnable on each of them. That requires going through
> all the VCPUs of all the domains and check their affinities.
>
> With this change, instead of doing the above for each candidate, we
> do it once for all, populating an array while counting. This way, when
> we later are evaluating candidates, all we need is summing up the right
> elements of the array itself.
>
> This reduces the complexity of the overall algorithm, as it moves a
> potentially expensive operation (for_each_vcpu_of_each_domain {})
> outside from the core placement loop, so that it is performed only
> once instead of (potentially) tens or hundreds of times. More
> specifically, we go from a worst case computation time complaxity of:
>
>   O(2^n_nodes) * O(n_domains*n_domain_vcpus)
>
> To, with this change:
>
>   O(n_domains*n_domains_vcpus) + O(2^n_nodes) = O(2^n_nodes)
>
> (with n_nodes<=16, otherwise the algorithm suggests partitioning with
> cpupools and does not even start.)
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

> ---
> Changes from v2:
>   * in nr_vcpus_on_nodes(), vcpu_nodemap renamed to something more
>     sensible, as suggested during review.
>
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -165,22 +165,34 @@ static uint32_t nodemap_to_free_memkb(li
>       return free_memkb;
>   }
>
> -/* Retrieve the number of vcpus able to run on the cpus of the nodes
> - * that are part of the nodemap. */
> -static int nodemap_to_nr_vcpus(libxl__gc *gc, libxl_cputopology *tinfo,
> +/* Retrieve the number of vcpus able to run on the nodes in nodemap */
> +static int nodemap_to_nr_vcpus(libxl__gc *gc, int vcpus_on_node[],
>                                  const libxl_bitmap *nodemap)
>   {
> +    int i, nr_vcpus = 0;
> +
> +    libxl_for_each_set_bit(i, *nodemap)
> +        nr_vcpus += vcpus_on_node[i];
> +
> +    return nr_vcpus;
> +}
> +
> +/* Number of vcpus able to run on the cpus of the various nodes
> + * (reported by filling the array vcpus_on_node[]). */
> +static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
> +                             const libxl_bitmap *suitable_cpumap,
> +                             int vcpus_on_node[])
> +{
>       libxl_dominfo *dinfo = NULL;
> -    libxl_bitmap vcpu_nodemap;
> +    libxl_bitmap nodes_counted;
>       int nr_doms, nr_cpus;
> -    int nr_vcpus = 0;
>       int i, j, k;
>
>       dinfo = libxl_list_domain(CTX,&nr_doms);
>       if (dinfo == NULL)
>           return ERROR_FAIL;
>
> -    if (libxl_node_bitmap_alloc(CTX,&vcpu_nodemap, 0)<  0) {
> +    if (libxl_node_bitmap_alloc(CTX,&nodes_counted, 0)<  0) {
>           libxl_dominfo_list_free(dinfo, nr_doms);
>           return ERROR_FAIL;
>       }
> @@ -193,19 +205,17 @@ static int nodemap_to_nr_vcpus(libxl__gc
>           if (vinfo == NULL)
>               continue;
>
> -        /* For each vcpu of each domain ... */
>           for (j = 0; j<  nr_dom_vcpus; j++) {
> +            /* For each vcpu of each domain, increment the elements of
> +             * the array corresponding to the nodes where the vcpu runs */
> +            libxl_bitmap_set_none(&nodes_counted);
> +            libxl_for_each_set_bit(k, vinfo[j].cpumap) {
> +                int node = tinfo[k].node;
>
> -            /* Build up a map telling on which nodes the vcpu is runnable on */
> -            libxl_bitmap_set_none(&vcpu_nodemap);
> -            libxl_for_each_set_bit(k, vinfo[j].cpumap)
> -                libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node);
> -
> -            /* And check if that map has any intersection with our nodemap */
> -            libxl_for_each_set_bit(k, vcpu_nodemap) {
> -                if (libxl_bitmap_test(nodemap, k)) {
> -                    nr_vcpus++;
> -                    break;
> +                if (libxl_bitmap_test(suitable_cpumap, k)&&
> +                    !libxl_bitmap_test(&nodes_counted, node)) {
> +                    libxl_bitmap_set(&nodes_counted, node);
> +                    vcpus_on_node[node]++;
>                   }
>               }
>           }
> @@ -213,9 +223,9 @@ static int nodemap_to_nr_vcpus(libxl__gc
>           libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
>       }
>
> -    libxl_bitmap_dispose(&vcpu_nodemap);
> +    libxl_bitmap_dispose(&nodes_counted);
>       libxl_dominfo_list_free(dinfo, nr_doms);
> -    return nr_vcpus;
> +    return 0;
>   }
>
>   /*
> @@ -270,7 +280,7 @@ int libxl__get_numa_candidate(libxl__gc
>       libxl_numainfo *ninfo = NULL;
>       int nr_nodes = 0, nr_suit_nodes, nr_cpus = 0;
>       libxl_bitmap suitable_nodemap, nodemap;
> -    int rc = 0;
> +    int *vcpus_on_node, rc = 0;
>
>       libxl_bitmap_init(&nodemap);
>       libxl_bitmap_init(&suitable_nodemap);
> @@ -281,6 +291,8 @@ int libxl__get_numa_candidate(libxl__gc
>       if (ninfo == NULL)
>           return ERROR_FAIL;
>
> +    GCNEW_ARRAY(vcpus_on_node, nr_nodes);
> +
>       /*
>        * The good thing about this solution is that it is based on heuristics
>        * (implemented in numa_cmpf() ), but we at least can evaluate it on
> @@ -330,6 +342,19 @@ int libxl__get_numa_candidate(libxl__gc
>           goto out;
>
>       /*
> +     * Later on, we will try to figure out how many vcpus are runnable on
> +     * each candidate (as a part of choosing the best one of them). That
> +     * requires going through all the vcpus of all the domains and check
> +     * their affinities. So, instead of doing that for each candidate,
> +     * let's count here the number of vcpus runnable on each node, so that
> +     * all we have to do later is summing up the right elements of the
> +     * vcpus_on_node array.
> +     */
> +    rc = nr_vcpus_on_nodes(gc, tinfo, suitable_cpumap, vcpus_on_node);
> +    if (rc)
> +        goto out;
> +
> +    /*
>        * If the minimum number of NUMA nodes is not explicitly specified
>        * (i.e., min_nodes == 0), we try to figure out a sensible number of nodes
>        * from where to start generating candidates, if possible (or just start
> @@ -414,7 +439,8 @@ int libxl__get_numa_candidate(libxl__gc
>                * current best one (if any).
>                */
>               libxl__numa_candidate_put_nodemap(gc,&new_cndt,&nodemap);
> -            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo,&nodemap);
> +            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, vcpus_on_node,
> +&nodemap);
>               new_cndt.free_memkb = nodes_free_memkb;
>               new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
>               new_cndt.nr_cpus = nodes_cpus;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 14:29:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:29: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 1U1Hbw-0003wr-8f; Fri, 01 Feb 2013 14:29:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U1Hbu-0003wZ-59
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:28:58 +0000
Received: from [85.158.143.99:55498] by server-1.bemta-4.messagelabs.com id
	6B/52-08839-921DB015; Fri, 01 Feb 2013 14:28:57 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359728932!20840296!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29865 invoked from network); 1 Feb 2013 14:28:55 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 14:28:55 -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=oe1YR8ao36s4AUosso9D0rGt8yjc+PudWPxiy2jjaZkpKHbuZZZY7lmv
	azjiCWxzn+r1UQIx9xa/vjSBN/LnJJDUnHggLIRZq/E+9GF2KbNtQ2Un3
	EYhYlzUg+c9Hrg5zKa9ELeVUs7aQ8A46rW6OdH3XBsaQc043yPa287CRV
	NkGfR2AiFfyHeM4tjIB/WN1J2PJuMtAIc2xsSOIksCu5za0sKzXBSEdVW
	Saw3fSJhiOok4lxJtRUT8BuQj9/mc;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359728935; x=1391264935;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=G8kL0+v3WCJbGO3VcVI1tuwMXVBnzBYGTjino9N0FmM=;
	b=hv5aekijGcb90tTvUA5gGgdas4UMNnH6aUI9Ck9L37GjS4xFrpkx52wf
	erpcJFE6r5Tfwe1C4MtPfRBvwxJ1PnB7+iuH/wIo2ymi7pNjNa1cUop1a
	LG2jr8fBudo8fDm+wceURBzqlaQ401nflESigVi+yRnSfbfkpCNvGa1t7
	TsUJnguQEolkpsrGgGxuzTdF4KaNw/TqCcV0g5P4us6LV/3boBIATEvqo
	XGBPy9xb9GErD5F9SFc923I10ACKr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114895889"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 15:28:52 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="157107435"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with SMTP; 01 Feb 2013 15:28:51 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 8E91F9669F9;
	Fri,  1 Feb 2013 15:28:51 +0100 (CET)
Message-ID: <510BD123.1010203@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 15:28:51 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<4e5a5f4ba12771415995.1359716478@Solace>
In-Reply-To: <4e5a5f4ba12771415995.1359716478@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 08 of 11 v3] libxl: optimize the calculation
 of how many VCPUs can run on a candidate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 01.02.2013 12:01, schrieb Dario Faggioli:
> For choosing the best NUMA placement candidate, we need to figure out
> how many VCPUs are runnable on each of them. That requires going through
> all the VCPUs of all the domains and check their affinities.
>
> With this change, instead of doing the above for each candidate, we
> do it once for all, populating an array while counting. This way, when
> we later are evaluating candidates, all we need is summing up the right
> elements of the array itself.
>
> This reduces the complexity of the overall algorithm, as it moves a
> potentially expensive operation (for_each_vcpu_of_each_domain {})
> outside from the core placement loop, so that it is performed only
> once instead of (potentially) tens or hundreds of times. More
> specifically, we go from a worst case computation time complaxity of:
>
>   O(2^n_nodes) * O(n_domains*n_domain_vcpus)
>
> To, with this change:
>
>   O(n_domains*n_domains_vcpus) + O(2^n_nodes) = O(2^n_nodes)
>
> (with n_nodes<=16, otherwise the algorithm suggests partitioning with
> cpupools and does not even start.)
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

> ---
> Changes from v2:
>   * in nr_vcpus_on_nodes(), vcpu_nodemap renamed to something more
>     sensible, as suggested during review.
>
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -165,22 +165,34 @@ static uint32_t nodemap_to_free_memkb(li
>       return free_memkb;
>   }
>
> -/* Retrieve the number of vcpus able to run on the cpus of the nodes
> - * that are part of the nodemap. */
> -static int nodemap_to_nr_vcpus(libxl__gc *gc, libxl_cputopology *tinfo,
> +/* Retrieve the number of vcpus able to run on the nodes in nodemap */
> +static int nodemap_to_nr_vcpus(libxl__gc *gc, int vcpus_on_node[],
>                                  const libxl_bitmap *nodemap)
>   {
> +    int i, nr_vcpus = 0;
> +
> +    libxl_for_each_set_bit(i, *nodemap)
> +        nr_vcpus += vcpus_on_node[i];
> +
> +    return nr_vcpus;
> +}
> +
> +/* Number of vcpus able to run on the cpus of the various nodes
> + * (reported by filling the array vcpus_on_node[]). */
> +static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
> +                             const libxl_bitmap *suitable_cpumap,
> +                             int vcpus_on_node[])
> +{
>       libxl_dominfo *dinfo = NULL;
> -    libxl_bitmap vcpu_nodemap;
> +    libxl_bitmap nodes_counted;
>       int nr_doms, nr_cpus;
> -    int nr_vcpus = 0;
>       int i, j, k;
>
>       dinfo = libxl_list_domain(CTX,&nr_doms);
>       if (dinfo == NULL)
>           return ERROR_FAIL;
>
> -    if (libxl_node_bitmap_alloc(CTX,&vcpu_nodemap, 0)<  0) {
> +    if (libxl_node_bitmap_alloc(CTX,&nodes_counted, 0)<  0) {
>           libxl_dominfo_list_free(dinfo, nr_doms);
>           return ERROR_FAIL;
>       }
> @@ -193,19 +205,17 @@ static int nodemap_to_nr_vcpus(libxl__gc
>           if (vinfo == NULL)
>               continue;
>
> -        /* For each vcpu of each domain ... */
>           for (j = 0; j<  nr_dom_vcpus; j++) {
> +            /* For each vcpu of each domain, increment the elements of
> +             * the array corresponding to the nodes where the vcpu runs */
> +            libxl_bitmap_set_none(&nodes_counted);
> +            libxl_for_each_set_bit(k, vinfo[j].cpumap) {
> +                int node = tinfo[k].node;
>
> -            /* Build up a map telling on which nodes the vcpu is runnable on */
> -            libxl_bitmap_set_none(&vcpu_nodemap);
> -            libxl_for_each_set_bit(k, vinfo[j].cpumap)
> -                libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node);
> -
> -            /* And check if that map has any intersection with our nodemap */
> -            libxl_for_each_set_bit(k, vcpu_nodemap) {
> -                if (libxl_bitmap_test(nodemap, k)) {
> -                    nr_vcpus++;
> -                    break;
> +                if (libxl_bitmap_test(suitable_cpumap, k)&&
> +                    !libxl_bitmap_test(&nodes_counted, node)) {
> +                    libxl_bitmap_set(&nodes_counted, node);
> +                    vcpus_on_node[node]++;
>                   }
>               }
>           }
> @@ -213,9 +223,9 @@ static int nodemap_to_nr_vcpus(libxl__gc
>           libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
>       }
>
> -    libxl_bitmap_dispose(&vcpu_nodemap);
> +    libxl_bitmap_dispose(&nodes_counted);
>       libxl_dominfo_list_free(dinfo, nr_doms);
> -    return nr_vcpus;
> +    return 0;
>   }
>
>   /*
> @@ -270,7 +280,7 @@ int libxl__get_numa_candidate(libxl__gc
>       libxl_numainfo *ninfo = NULL;
>       int nr_nodes = 0, nr_suit_nodes, nr_cpus = 0;
>       libxl_bitmap suitable_nodemap, nodemap;
> -    int rc = 0;
> +    int *vcpus_on_node, rc = 0;
>
>       libxl_bitmap_init(&nodemap);
>       libxl_bitmap_init(&suitable_nodemap);
> @@ -281,6 +291,8 @@ int libxl__get_numa_candidate(libxl__gc
>       if (ninfo == NULL)
>           return ERROR_FAIL;
>
> +    GCNEW_ARRAY(vcpus_on_node, nr_nodes);
> +
>       /*
>        * The good thing about this solution is that it is based on heuristics
>        * (implemented in numa_cmpf() ), but we at least can evaluate it on
> @@ -330,6 +342,19 @@ int libxl__get_numa_candidate(libxl__gc
>           goto out;
>
>       /*
> +     * Later on, we will try to figure out how many vcpus are runnable on
> +     * each candidate (as a part of choosing the best one of them). That
> +     * requires going through all the vcpus of all the domains and check
> +     * their affinities. So, instead of doing that for each candidate,
> +     * let's count here the number of vcpus runnable on each node, so that
> +     * all we have to do later is summing up the right elements of the
> +     * vcpus_on_node array.
> +     */
> +    rc = nr_vcpus_on_nodes(gc, tinfo, suitable_cpumap, vcpus_on_node);
> +    if (rc)
> +        goto out;
> +
> +    /*
>        * If the minimum number of NUMA nodes is not explicitly specified
>        * (i.e., min_nodes == 0), we try to figure out a sensible number of nodes
>        * from where to start generating candidates, if possible (or just start
> @@ -414,7 +439,8 @@ int libxl__get_numa_candidate(libxl__gc
>                * current best one (if any).
>                */
>               libxl__numa_candidate_put_nodemap(gc,&new_cndt,&nodemap);
> -            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo,&nodemap);
> +            new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, vcpus_on_node,
> +&nodemap);
>               new_cndt.free_memkb = nodes_free_memkb;
>               new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
>               new_cndt.nr_cpus = nodes_cpus;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 14:29:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14: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 1U1Hc3-0003yB-SI; Fri, 01 Feb 2013 14:29:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1Hc2-0003xv-VP
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:29:07 +0000
Received: from [85.158.139.211:29855] by server-11.bemta-5.messagelabs.com id
	3D/29-19159-231DB015; Fri, 01 Feb 2013 14:29:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1359728945!18380160!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14906 invoked from network); 1 Feb 2013 14:29:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1069338"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 14:29:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 1 Feb 2013
	14:29:05 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:29:04 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Adding support for coverage informations
Thread-Index: Ac4AiHywyRpV6jUZRAG/jkyN+puPFA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359622305.12252.241.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: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > because is easier to have a zero cost if you disable coverage
> > > informations. The best thing would be redirect do_coverage_op to
> > > do_ni_hypercall using linker options but even two small stub would do
> > > (these stubs will return ENOSYS instead).
> > 
> > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > the hypercall path you are introducing? What is the zero cost?
> 
> I don't think we care a jot about the performance of this system call
> when coverage is disabled, it's certainly not a hot path and in any case
> if it is a NOP it doesn't really matter anyway.
> 
> Ian.
> 

It's not about the speed, it's about the bytes introduced in Xen binary.

Frediano

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:29:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14: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 1U1Hc3-0003yB-SI; Fri, 01 Feb 2013 14:29:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1Hc2-0003xv-VP
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:29:07 +0000
Received: from [85.158.139.211:29855] by server-11.bemta-5.messagelabs.com id
	3D/29-19159-231DB015; Fri, 01 Feb 2013 14:29:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1359728945!18380160!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14906 invoked from network); 1 Feb 2013 14:29:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1069338"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 14:29:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 1 Feb 2013
	14:29:05 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:29:04 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Adding support for coverage informations
Thread-Index: Ac4AiHywyRpV6jUZRAG/jkyN+puPFA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359622305.12252.241.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: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > because is easier to have a zero cost if you disable coverage
> > > informations. The best thing would be redirect do_coverage_op to
> > > do_ni_hypercall using linker options but even two small stub would do
> > > (these stubs will return ENOSYS instead).
> > 
> > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > the hypercall path you are introducing? What is the zero cost?
> 
> I don't think we care a jot about the performance of this system call
> when coverage is disabled, it's certainly not a hot path and in any case
> if it is a NOP it doesn't really matter anyway.
> 
> Ian.
> 

It's not about the speed, it's about the bytes introduced in Xen binary.

Frediano

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:30:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:30: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 1U1HdE-00047q-CD; Fri, 01 Feb 2013 14:30:20 +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 1U1HdC-00047V-CH
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:30:18 +0000
Received: from [85.158.137.99:3541] by server-1.bemta-3.messagelabs.com id
	33/4C-08955-971DB015; Fri, 01 Feb 2013 14:30:17 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1359729016!18708247!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20173 invoked from network); 1 Feb 2013 14:30:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 14:30:16 -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=WnCLoOV5AR1ecpW/f3AfbtTwa2P37si4zxKZOE9SZuUhf/AZFYC267eK
	kIqhlZ569B5qa5JxNNId0OjD174Id5L0UhNv/ydvhZwHo/ZjhUvZlgPu3
	eY/YTAhTtrB2GFYQ15Qy9EebPgfPqoe7z0D2NnuudIVoZhgNNNGrJf8L/
	AjXWs+WStjguuUHgTWeAr7Apv3K+G17QMr1D3OJUy0aLpocXuws13EV//
	Y6QMhvUv6tK7GuUJ7lfiJjXOL4Wkx;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359729017; x=1391265017;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=l8kJeY3Vx1EqR64Zs2Kj3bZEao7piHXSy104D2s9BCM=;
	b=G/sSH4CP2dKO5nnCqhnuE9Ni4jSkrni+v1akIp6q15UQlqu3dVXnmrBe
	MeYHW4F3xm0TZgBRJNELQ3Nb7iCJS4c/XcM3I+YMpjzlQnTJkngiT007j
	BDst+VP5iWViBjR8DVZ8JyQQVB4iemwvcbcbnWdn+O2iqa+QBn/CkhlyH
	FMh7pALrBmTjIujyoNisyxZcHD8mdYjZbHMxA+Smqyc/fKO97OBnqDnBo
	i/pMyDgHexo+6T8ggc3A9DLGhFPWz;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114896057"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 15:30:16 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="158064321"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with SMTP; 01 Feb 2013 15:30:15 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B7AAF9669F9;
	Fri,  1 Feb 2013 15:30:15 +0100 (CET)
Message-ID: <510BD177.9010504@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 15:30:15 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<7b30913e753c4f0a2396.1359716474@Solace>
In-Reply-To: <7b30913e753c4f0a2396.1359716474@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 04 of 11 v3] xen: 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

Am 01.02.2013 12:01, schrieb Dario Faggioli:
> As vcpu-affinity tells where VCPUs must run, node-affinity tells
> where they should or, better, prefer. While respecting vcpu-affinity
> remains mandatory, node-affinity is not that strict, it only expresses
> a preference, although honouring it is almost always true that will
> bring significant performances benefit (especially as compared to
> not having any affinity at all).
>
> This change modifies the VCPU load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferable
> for the domain to run. If that fails in finding a valid PCPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

> ---
> Changes from v2:
>   * for_each_csched_balance_step() now is defined as a regular, and
>     easier to understand, 0...n for() loop, instead of a going backwards
>     one, as that wasn't really needed;
>   * checking whether or not a CSCHED_BALANCE_NODE_AFFINITY balancing
>     set is useful or not now happens outside of csched_balance_cpumask(),
>     i.e., closer to the actual loop, making the logic a lot more evident
>     and easy to understand, as requested during review;
>   * while reworking __runq_tickle(), handling of idle pcpu has been brought
>     outside from the balancing loop, as requested during review;
>   * __csched_vcpu_is_migrateable() was just wrong, so it has been removed;
>   * the suboptimal handling of SMT in _csched_cpu_pick() has been moved
>     to a separate patch (i.e., the previous patch in the series);
>   * moved the CPU mask needed for balancing within `csched_pcpu', as
>     suggested during review. This way it is not only more close to
>     other per-PCPU data (potential cache related benefits), but it is
>     also only allocated for the PCPUs credit is in charge of.
>
> Changes from v1:
>   * CPU masks variables moved off from the stack, as requested during
>     review. As per the comments in the code, having them in the private
>     (per-scheduler instance) struct could have been enough, but it would be
>     racy (again, see comments). For that reason, use a global bunch of
>     them of (via per_cpu());
>   * George suggested a different load balancing logic during v1's review. I
>     think he was right and then I changed the old implementation in a way
>     that resembles exactly that. I rewrote most of this patch to introduce
>     a more sensible and effective noda-affinity handling logic.
>
> 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
> @@ -111,6 +111,12 @@
>
>
>   /*
> + * Node Balancing
> + */
> +#define CSCHED_BALANCE_NODE_AFFINITY    0
> +#define CSCHED_BALANCE_CPU_AFFINITY     1
> +
> +/*
>    * Boot parameters
>    */
>   static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
> @@ -125,9 +131,20 @@ struct csched_pcpu {
>       struct timer ticker;
>       unsigned int tick;
>       unsigned int idle_bias;
> +    /* Store this here to avoid having too many cpumask_var_t-s on stack */
> +    cpumask_var_t balance_mask;
>   };
>
>   /*
> + * Convenience macro for accessing the per-PCPU cpumask we need for
> + * implementing the two steps (vcpu and node affinity) balancing logic.
> + * It is stored in csched_pcpu so that serialization is not an issue,
> + * as there is a csched_pcpu for each PCPU and we always hold the
> + * runqueue spin-lock when using this.
> + */
> +#define csched_balance_mask (CSCHED_PCPU(smp_processor_id())->balance_mask)
> +
> +/*
>    * Virtual CPU
>    */
>   struct csched_vcpu {
> @@ -159,6 +176,9 @@ struct csched_dom {
>       struct list_head active_vcpu;
>       struct list_head active_sdom_elem;
>       struct domain *dom;
> +    /* cpumask translated from the domain's node-affinity.
> +     * Basically, the CPUs we prefer to be scheduled on. */
> +    cpumask_var_t node_affinity_cpumask;
>       uint16_t active_vcpu_count;
>       uint16_t weight;
>       uint16_t cap;
> @@ -239,6 +259,43 @@ static inline void
>       list_del_init(&svc->runq_elem);
>   }
>
> +#define for_each_csched_balance_step(step) \
> +    for ( (step) = 0; (step)<= CSCHED_BALANCE_CPU_AFFINITY; (step)++ )
> +
> +
> +/*
> + * vcpu-affinity balancing is always necessary and must never be skipped.
> + * OTOH, if a domain has affinity with all the nodes, we can tell the caller
> + * that he can safely skip the node-affinity balancing step.
> + */
> +#define __vcpu_has_valuable_node_affinity(vc) \
> +    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
> +
> +static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
> +{
> +    if ( step == CSCHED_BALANCE_NODE_AFFINITY
> +&&  !__vcpu_has_valuable_node_affinity(vc) )
> +        return 1;
> +    return 0;
> +}
> +
> +/*
> + * Each csched-balance step uses its own cpumask. This function determines
> + * which one (given the step) and copies it in mask. For the node-affinity
> + * balancing step, the pcpus that are not part of vc's vcpu-affinity are
> + * filtered out from the result, to avoid running a vcpu where it would
> + * like, but is not allowed to!
> + */
> +static void
> +csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
> +{
> +    if ( step == CSCHED_BALANCE_NODE_AFFINITY )
> +        cpumask_and(mask, CSCHED_DOM(vc->domain)->node_affinity_cpumask,
> +                    vc->cpu_affinity);
> +    else /* step == CSCHED_BALANCE_CPU_AFFINITY */
> +        cpumask_copy(mask, vc->cpu_affinity);
> +}
> +
>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>   {
>       s_time_t delta;
> @@ -266,12 +323,12 @@ static inline void
>       struct csched_vcpu * const cur = CSCHED_VCPU(curr_on_cpu(cpu));
>       struct csched_private *prv = CSCHED_PRIV(per_cpu(scheduler, cpu));
>       cpumask_t mask, idle_mask;
> -    int idlers_empty;
> +    int balance_step, idlers_empty;
>
>       ASSERT(cur);
>       cpumask_clear(&mask);
> +    idlers_empty = cpumask_empty(prv->idlers);
>
> -    idlers_empty = cpumask_empty(prv->idlers);
>
>       /*
>        * If the pcpu is idle, or there are no idlers and the new
> @@ -291,41 +348,67 @@ static inline void
>       }
>       else if ( !idlers_empty )
>       {
> -        /* Check whether or not there are idlers that can run new */
> -        cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
> +        /* Node and vcpu-affinity balancing loop */
> +        for_each_csched_balance_step( balance_step )
> +        {
> +            int new_idlers_empty;
>
> -        /*
> -         * If there are no suitable idlers for new, and it's higher
> -         * priority than cur, ask the scheduler to migrate cur away.
> -         * We have to act like this (instead of just waking some of
> -         * the idlers suitable for cur) because cur is running.
> -         *
> -         * If there are suitable idlers for new, no matter priorities,
> -         * leave cur alone (as it is running and is, likely, cache-hot)
> -         * and wake some of them (which is waking up and so is, likely,
> -         * cache cold anyway).
> -         */
> -        if ( cpumask_empty(&idle_mask)&&  new->pri>  cur->pri )
> -        {
> -            SCHED_STAT_CRANK(tickle_idlers_none);
> -            SCHED_VCPU_STAT_CRANK(cur, kicked_away);
> -            SCHED_VCPU_STAT_CRANK(cur, migrate_r);
> -            SCHED_STAT_CRANK(migrate_kicked_away);
> -            set_bit(_VPF_migrating,&cur->vcpu->pause_flags);
> -            cpumask_set_cpu(cpu,&mask);
> -        }
> -        else if ( !cpumask_empty(&idle_mask) )
> -        {
> -            /* Which of the idlers suitable for new shall we wake up? */
> -            SCHED_STAT_CRANK(tickle_idlers_some);
> -            if ( opt_tickle_one_idle )
> +            /* For vcpus with no node-affinity, consider vcpu-affinity only */
> +            if ( csched_balance_step_skippable( balance_step, new->vcpu) )
> +                continue;
> +
> +            /* Are there idlers suitable for new (for this balance step)? */
> +            csched_balance_cpumask(new->vcpu, balance_step,
> +                                   csched_balance_mask);
> +            cpumask_and(&idle_mask, prv->idlers, csched_balance_mask);
> +            new_idlers_empty = cpumask_empty(&idle_mask);
> +
> +            /*
> +             * Let's not be too harsh! If there aren't idlers suitable
> +             * for new in its node-affinity mask, make sure we check its
> +             * vcpu-affinity as well, before taking final decisions.
> +             */
> +            if ( new_idlers_empty
> +&&  balance_step == CSCHED_BALANCE_NODE_AFFINITY )
> +                continue;
> +
> +            /*
> +             * If there are no suitable idlers for new, and it's higher
> +             * priority than cur, ask the scheduler to migrate cur away.
> +             * We have to act like this (instead of just waking some of
> +             * the idlers suitable for cur) because cur is running.
> +             *
> +             * If there are suitable idlers for new, no matter priorities,
> +             * leave cur alone (as it is running and is, likely, cache-hot)
> +             * and wake some of them (which is waking up and so is, likely,
> +             * cache cold anyway).
> +             */
> +            if ( new_idlers_empty&&  new->pri>  cur->pri )
>               {
> -                this_cpu(last_tickle_cpu) =
> -                    cpumask_cycle(this_cpu(last_tickle_cpu),&idle_mask);
> -                cpumask_set_cpu(this_cpu(last_tickle_cpu),&mask);
> +                SCHED_STAT_CRANK(tickle_idlers_none);
> +                SCHED_VCPU_STAT_CRANK(cur, kicked_away);
> +                SCHED_VCPU_STAT_CRANK(cur, migrate_r);
> +                SCHED_STAT_CRANK(migrate_kicked_away);
> +                set_bit(_VPF_migrating,&cur->vcpu->pause_flags);
> +                cpumask_set_cpu(cpu,&mask);
>               }
> -            else
> -                cpumask_or(&mask,&mask,&idle_mask);
> +            else if ( !new_idlers_empty )
> +            {
> +                /* Which of the idlers suitable for new shall we wake up? */
> +                SCHED_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);
> +            }
> +
> +            /* Did we find anyone? */
> +            if ( !cpumask_empty(&mask) )
> +                break;
>           }
>       }
>
> @@ -370,6 +453,7 @@ csched_free_pdata(const struct scheduler
>
>       spin_unlock_irqrestore(&prv->lock, flags);
>
> +    free_cpumask_var(spc->balance_mask);
>       xfree(spc);
>   }
>
> @@ -385,6 +469,12 @@ csched_alloc_pdata(const struct schedule
>       if ( spc == NULL )
>           return NULL;
>
> +    if ( !alloc_cpumask_var(&spc->balance_mask) )
> +    {
> +        xfree(spc);
> +        return NULL;
> +    }
> +
>       spin_lock_irqsave(&prv->lock, flags);
>
>       /* Initialize/update system-wide config */
> @@ -475,15 +565,16 @@ 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
> -     * peer PCPU. Only pick up work that's allowed to run on our CPU.
> +     * peer PCPU. Only pick up work that prefers and/or is allowed to run
> +     * on our CPU.
>        */
>       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
> @@ -493,97 +584,110 @@ static int
>       cpumask_t idlers;
>       cpumask_t *online;
>       struct csched_pcpu *spc = NULL;
> -    int cpu;
> +    int cpu = vc->processor;
> +    int balance_step;
>
> -    /*
> -     * Pick from online CPUs in VCPU's affinity mask, giving a
> -     * preference to its current processor if it's in there.
> -     */
>       online = cpupool_scheduler_cpumask(vc->domain->cpupool);
> -    cpumask_and(&cpus, online, vc->cpu_affinity);
> -    cpu = cpumask_test_cpu(vc->processor,&cpus)
> -            ? vc->processor
> -            : cpumask_cycle(vc->processor,&cpus);
> -    ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );
> +    for_each_csched_balance_step( balance_step )
> +    {
> +        if ( csched_balance_step_skippable( balance_step, vc) )
> +            continue;
>
> -    /*
> -     * Try to find an idle processor within the above constraints.
> -     *
> -     * In multi-core and multi-threaded CPUs, not all idle execution
> -     * vehicles are equal!
> -     *
> -     * We give preference to the idle execution vehicle with the most
> -     * idling neighbours in its grouping. This distributes work across
> -     * distinct cores first and guarantees we don't do something stupid
> -     * like run two VCPUs on co-hyperthreads while there are idle cores
> -     * or sockets.
> -     *
> -     * Notice that, when computing the "idleness" of cpu, we may want to
> -     * discount vc. That is, iff vc is the currently running and the only
> -     * runnable vcpu on cpu, we add cpu to the idlers.
> -     */
> -    cpumask_and(&idlers,&cpu_online_map, CSCHED_PRIV(ops)->idlers);
> -    if ( vc->processor == cpu&&  IS_RUNQ_IDLE(cpu) )
> -        cpumask_set_cpu(cpu,&idlers);
> -    cpumask_and(&cpus,&cpus,&idlers);
> +        /* Pick an online CPU from the proper affinity mask */
> +        csched_balance_cpumask(vc, balance_step,&cpus);
> +        cpumask_and(&cpus,&cpus, online);
>
> -    /*
> -     * It is important that cpu points to an idle processor, if a suitable
> -     * one exists (and we can use cpus to check and, possibly, choose a new
> -     * CPU, as we just&&-ed it with idlers). In fact, if we are on SMT, and
> -     * cpu points to a busy thread with an idle sibling, both the threads
> -     * will be considered the same, from the "idleness" calculation point
> -     * of view", preventing vcpu from being moved to the thread that is
> -     * actually idle.
> -     */
> -    if ( !cpumask_empty(&cpus)&&  !cpumask_test_cpu(cpu,&cpus) )
> -        cpu = cpumask_cycle(cpu,&cpus);
> -    cpumask_clear_cpu(cpu,&cpus);
> +        /* If present, prefer vc's current processor */
> +        cpu = cpumask_test_cpu(vc->processor,&cpus)
> +                ? vc->processor
> +                : cpumask_cycle(vc->processor,&cpus);
> +        ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );
>
> -    while ( !cpumask_empty(&cpus) )
> -    {
> -        cpumask_t cpu_idlers;
> -        cpumask_t nxt_idlers;
> -        int nxt, weight_cpu, weight_nxt;
> -        int migrate_factor;
> +        /*
> +         * Try to find an idle processor within the above constraints.
> +         *
> +         * In multi-core and multi-threaded CPUs, not all idle execution
> +         * vehicles are equal!
> +         *
> +         * We give preference to the idle execution vehicle with the most
> +         * idling neighbours in its grouping. This distributes work across
> +         * distinct cores first and guarantees we don't do something stupid
> +         * like run two VCPUs on co-hyperthreads while there are idle cores
> +         * or sockets.
> +         *
> +         * Notice that, when computing the "idleness" of cpu, we may want to
> +         * discount vc. That is, iff vc is the currently running and the only
> +         * runnable vcpu on cpu, we add cpu to the idlers.
> +         */
> +        cpumask_and(&idlers,&cpu_online_map, CSCHED_PRIV(ops)->idlers);
> +        if ( vc->processor == cpu&&  IS_RUNQ_IDLE(cpu) )
> +            cpumask_set_cpu(cpu,&idlers);
> +        cpumask_and(&cpus,&cpus,&idlers);
>
> -        nxt = cpumask_cycle(cpu,&cpus);
> +        /*
> +         * It is important that cpu points to an idle processor, if a suitable
> +         * one exists (and we can use cpus to check and, possibly, choose a new
> +         * CPU, as we just&&-ed it with idlers). In fact, if we are on SMT, and
> +         * cpu points to a busy thread with an idle sibling, both the threads
> +         * will be considered the same, from the "idleness" calculation point
> +         * of view", preventing vcpu from being moved to the thread that is
> +         * actually idle.
> +         */
> +        if ( !cpumask_empty(&cpus)&&  !cpumask_test_cpu(cpu,&cpus) )
> +            cpu = cpumask_cycle(cpu,&cpus);
> +        cpumask_clear_cpu(cpu,&cpus);
>
> -        if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
> +        while ( !cpumask_empty(&cpus) )
>           {
> -            /* We're on the same socket, so check the busy-ness of threads.
> -             * Migrate if # of idlers is less at all */
> -            ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> -            migrate_factor = 1;
> -            cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_sibling_mask, cpu));
> -            cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_sibling_mask, nxt));
> -        }
> -        else
> -        {
> -            /* We're on different sockets, so check the busy-ness of cores.
> -             * Migrate only if the other core is twice as idle */
> -            ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> -            migrate_factor = 2;
> -            cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_core_mask, cpu));
> -            cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_core_mask, nxt));
> +            cpumask_t cpu_idlers;
> +            cpumask_t nxt_idlers;
> +            int nxt, weight_cpu, weight_nxt;
> +            int migrate_factor;
> +
> +            nxt = cpumask_cycle(cpu,&cpus);
> +
> +            if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
> +            {
> +                /* We're on the same socket, so check the busy-ness of threads.
> +                 * Migrate if # of idlers is less at all */
> +                ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> +                migrate_factor = 1;
> +                cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_sibling_mask,
> +                            cpu));
> +                cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_sibling_mask,
> +                            nxt));
> +            }
> +            else
> +            {
> +                /* We're on different sockets, so check the busy-ness of cores.
> +                 * Migrate only if the other core is twice as idle */
> +                ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> +                migrate_factor = 2;
> +                cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_core_mask, cpu));
> +                cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_core_mask, nxt));
> +            }
> +
> +            weight_cpu = cpumask_weight(&cpu_idlers);
> +            weight_nxt = cpumask_weight(&nxt_idlers);
> +            /* smt_power_savings: consolidate work rather than spreading it */
> +            if ( sched_smt_power_savings ?
> +                 weight_cpu>  weight_nxt :
> +                 weight_cpu * migrate_factor<  weight_nxt )
> +            {
> +                cpumask_and(&nxt_idlers,&cpus,&nxt_idlers);
> +                spc = CSCHED_PCPU(nxt);
> +                cpu = cpumask_cycle(spc->idle_bias,&nxt_idlers);
> +                cpumask_andnot(&cpus,&cpus, per_cpu(cpu_sibling_mask, cpu));
> +            }
> +            else
> +            {
> +                cpumask_andnot(&cpus,&cpus,&nxt_idlers);
> +            }
>           }
>
> -        weight_cpu = cpumask_weight(&cpu_idlers);
> -        weight_nxt = cpumask_weight(&nxt_idlers);
> -        /* smt_power_savings: consolidate work rather than spreading it */
> -        if ( sched_smt_power_savings ?
> -             weight_cpu>  weight_nxt :
> -             weight_cpu * migrate_factor<  weight_nxt )
> -        {
> -            cpumask_and(&nxt_idlers,&cpus,&nxt_idlers);
> -            spc = CSCHED_PCPU(nxt);
> -            cpu = cpumask_cycle(spc->idle_bias,&nxt_idlers);
> -            cpumask_andnot(&cpus,&cpus, per_cpu(cpu_sibling_mask, cpu));
> -        }
> -        else
> -        {
> -            cpumask_andnot(&cpus,&cpus,&nxt_idlers);
> -        }
> +        /* Stop if cpu is idle */
> +        if ( cpumask_test_cpu(cpu,&idlers) )
> +            break;
>       }
>
>       if ( commit&&  spc )
> @@ -925,6 +1029,13 @@ csched_alloc_domdata(const struct schedu
>       if ( sdom == NULL )
>           return NULL;
>
> +    if ( !alloc_cpumask_var(&sdom->node_affinity_cpumask) )
> +    {
> +        xfree(sdom);
> +        return NULL;
> +    }
> +    cpumask_setall(sdom->node_affinity_cpumask);
> +
>       /* Initialize credit and weight */
>       INIT_LIST_HEAD(&sdom->active_vcpu);
>       sdom->active_vcpu_count = 0;
> @@ -956,6 +1067,9 @@ csched_dom_init(const struct scheduler *
>   static void
>   csched_free_domdata(const struct scheduler *ops, void *data)
>   {
> +    struct csched_dom *sdom = data;
> +
> +    free_cpumask_var(sdom->node_affinity_cpumask);
>       xfree(data);
>   }
>
> @@ -1252,7 +1366,7 @@ csched_tick(void *_cpu)
>   }
>
>   static struct csched_vcpu *
> -csched_runq_steal(int peer_cpu, int cpu, int pri)
> +csched_runq_steal(int peer_cpu, int cpu, int pri, int balance_step)
>   {
>       const struct csched_pcpu * const peer_pcpu = CSCHED_PCPU(peer_cpu);
>       const struct vcpu * const peer_vcpu = curr_on_cpu(peer_cpu);
> @@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,
>               if ( speer->pri<= pri )
>                   break;
>
> -            /* Is this VCPU is runnable on our PCPU? */
> +            /* Is this VCPU runnable on our PCPU? */
>               vc = speer->vcpu;
>               BUG_ON( is_idle_vcpu(vc) );
>
> -            if (__csched_vcpu_is_migrateable(vc, cpu))
> +            /*
> +             * If the vcpu has no valuable node-affinity, skip this vcpu.
> +             * In fact, what we want is to check if we have any node-affine
> +             * work to steal, before starting to look at vcpu-affine work.
> +             */
> +            if ( balance_step == CSCHED_BALANCE_NODE_AFFINITY
> +&&  !__vcpu_has_valuable_node_affinity(vc) )
> +                continue;
> +
> +            csched_balance_cpumask(vc, balance_step, csched_balance_mask);
> +            if ( __csched_vcpu_is_migrateable(vc, cpu, csched_balance_mask) )
>               {
>                   /* We got a candidate. Grab it! */
>                   TRACE_3D(TRC_CSCHED_STOLEN_VCPU, peer_cpu,
> @@ -1307,7 +1431,8 @@ csched_load_balance(struct csched_privat
>       struct csched_vcpu *speer;
>       cpumask_t workers;
>       cpumask_t *online;
> -    int peer_cpu;
> +    int peer_cpu, peer_node, bstep;
> +    int node = cpu_to_node(cpu);
>
>       BUG_ON( cpu != snext->vcpu->processor );
>       online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
> @@ -1324,42 +1449,68 @@ csched_load_balance(struct csched_privat
>           SCHED_STAT_CRANK(load_balance_other);
>
>       /*
> -     * Peek at non-idling CPUs in the system, starting with our
> -     * immediate neighbour.
> +     * Let's look around for work to steal, taking both vcpu-affinity
> +     * and node-affinity into account. More specifically, we check all
> +     * the non-idle CPUs' runq, looking for:
> +     *  1. any node-affine work to steal first,
> +     *  2. if not finding anything, any vcpu-affine work to steal.
>        */
> -    cpumask_andnot(&workers, online, prv->idlers);
> -    cpumask_clear_cpu(cpu,&workers);
> -    peer_cpu = cpu;
> +    for_each_csched_balance_step( bstep )
> +    {
> +        /*
> +         * We peek at the non-idling CPUs in a node-wise fashion. In fact,
> +         * it is more likely that we find some node-affine work on our same
> +         * node, not to mention that migrating vcpus within the same node
> +         * could well expected to be cheaper than across-nodes (memory
> +         * stays local, there might be some node-wide cache[s], etc.).
> +         */
> +        peer_node = node;
> +        do
> +        {
> +            /* Find out what the !idle are in this node */
> +            cpumask_andnot(&workers, online, prv->idlers);
> +            cpumask_and(&workers,&workers,&node_to_cpumask(peer_node));
> +            cpumask_clear_cpu(cpu,&workers);
>
> -    while ( !cpumask_empty(&workers) )
> -    {
> -        peer_cpu = cpumask_cycle(peer_cpu,&workers);
> -        cpumask_clear_cpu(peer_cpu,&workers);
> +            if ( cpumask_empty(&workers) )
> +                goto next_node;
>
> -        /*
> -         * Get ahold of the scheduler lock for this peer CPU.
> -         *
> -         * Note: We don't spin on this lock but simply try it. Spinning could
> -         * cause a deadlock if the peer CPU is also load balancing and trying
> -         * to lock this CPU.
> -         */
> -        if ( !pcpu_schedule_trylock(peer_cpu) )
> -        {
> -            SCHED_STAT_CRANK(steal_trylock_failed);
> -            continue;
> -        }
> +            peer_cpu = cpumask_first(&workers);
> +            do
> +            {
> +                /*
> +                 * Get ahold of the scheduler lock for this peer CPU.
> +                 *
> +                 * Note: We don't spin on this lock but simply try it. Spinning
> +                 * could cause a deadlock if the peer CPU is also load
> +                 * balancing and trying to lock this CPU.
> +                 */
> +                if ( !pcpu_schedule_trylock(peer_cpu) )
> +                {
> +                    SCHED_STAT_CRANK(steal_trylock_failed);
> +                    peer_cpu = cpumask_cycle(peer_cpu,&workers);
> +                    continue;
> +                }
>
> -        /*
> -         * Any work over there to steal?
> -         */
> -        speer = cpumask_test_cpu(peer_cpu, online) ?
> -            csched_runq_steal(peer_cpu, cpu, snext->pri) : NULL;
> -        pcpu_schedule_unlock(peer_cpu);
> -        if ( speer != NULL )
> -        {
> -            *stolen = 1;
> -            return speer;
> -        }
> +                /* Any work over there to steal? */
> +                speer = cpumask_test_cpu(peer_cpu, online) ?
> +                    csched_runq_steal(peer_cpu, cpu, snext->pri, bstep) : NULL;
> +                pcpu_schedule_unlock(peer_cpu);
> +
> +                /* As soon as one vcpu is found, balancing ends */
> +                if ( speer != NULL )
> +                {
> +                    *stolen = 1;
> +                    return speer;
> +                }
> +
> +                peer_cpu = cpumask_cycle(peer_cpu,&workers);
> +
> +            } while( peer_cpu != cpumask_first(&workers) );
> +
> + next_node:
> +            peer_node = cycle_node(peer_node, node_online_map);
> +        } while( peer_node != node );
>       }
>
>    out:
> 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
> @@ -41,6 +41,8 @@
>    * int last_node(mask)			Number highest set bit, or MAX_NUMNODES
>    * int first_unset_node(mask)		First node not set in mask, or
>    *					MAX_NUMNODES.
> + * int cycle_node(node, mask)		Next node cycling from 'node', or
> + *					MAX_NUMNODES
>    *
>    * nodemask_t nodemask_of_node(node)	Return nodemask with bit 'node' set
>    * NODE_MASK_ALL			Initializer - all bits set
> @@ -254,6 +256,16 @@ static inline int __first_unset_node(con
>   			find_first_zero_bit(maskp->bits, MAX_NUMNODES));
>   }
>
> +#define cycle_node(n, src) __cycle_node((n),&(src), MAX_NUMNODES)
> +static inline int __cycle_node(int n, const nodemask_t *maskp, int nbits)
> +{
> +    int nxt = __next_node(n, maskp, nbits);
> +
> +    if (nxt == nbits)
> +        nxt = __first_node(maskp, nbits);
> +    return nxt;
> +}
> +
>   #define NODE_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(MAX_NUMNODES)
>
>   #if MAX_NUMNODES<= BITS_PER_LONG
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 14:30:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:30: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 1U1HdE-00047q-CD; Fri, 01 Feb 2013 14:30:20 +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 1U1HdC-00047V-CH
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:30:18 +0000
Received: from [85.158.137.99:3541] by server-1.bemta-3.messagelabs.com id
	33/4C-08955-971DB015; Fri, 01 Feb 2013 14:30:17 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1359729016!18708247!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE5NzY4Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20173 invoked from network); 1 Feb 2013 14:30:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 14:30:16 -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=WnCLoOV5AR1ecpW/f3AfbtTwa2P37si4zxKZOE9SZuUhf/AZFYC267eK
	kIqhlZ569B5qa5JxNNId0OjD174Id5L0UhNv/ydvhZwHo/ZjhUvZlgPu3
	eY/YTAhTtrB2GFYQ15Qy9EebPgfPqoe7z0D2NnuudIVoZhgNNNGrJf8L/
	AjXWs+WStjguuUHgTWeAr7Apv3K+G17QMr1D3OJUy0aLpocXuws13EV//
	Y6QMhvUv6tK7GuUJ7lfiJjXOL4Wkx;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1359729017; x=1391265017;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=l8kJeY3Vx1EqR64Zs2Kj3bZEao7piHXSy104D2s9BCM=;
	b=G/sSH4CP2dKO5nnCqhnuE9Ni4jSkrni+v1akIp6q15UQlqu3dVXnmrBe
	MeYHW4F3xm0TZgBRJNELQ3Nb7iCJS4c/XcM3I+YMpjzlQnTJkngiT007j
	BDst+VP5iWViBjR8DVZ8JyQQVB4iemwvcbcbnWdn+O2iqa+QBn/CkhlyH
	FMh7pALrBmTjIujyoNisyxZcHD8mdYjZbHMxA+Smqyc/fKO97OBnqDnBo
	i/pMyDgHexo+6T8ggc3A9DLGhFPWz;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="114896057"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 01 Feb 2013 15:30:16 +0100
X-IronPort-AV: E=Sophos;i="4.84,579,1355094000"; d="scan'208";a="158064321"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with SMTP; 01 Feb 2013 15:30:15 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B7AAF9669F9;
	Fri,  1 Feb 2013 15:30:15 +0100 (CET)
Message-ID: <510BD177.9010504@ts.fujitsu.com>
Date: Fri, 01 Feb 2013 15:30:15 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<7b30913e753c4f0a2396.1359716474@Solace>
In-Reply-To: <7b30913e753c4f0a2396.1359716474@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 04 of 11 v3] xen: 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

Am 01.02.2013 12:01, schrieb Dario Faggioli:
> As vcpu-affinity tells where VCPUs must run, node-affinity tells
> where they should or, better, prefer. While respecting vcpu-affinity
> remains mandatory, node-affinity is not that strict, it only expresses
> a preference, although honouring it is almost always true that will
> bring significant performances benefit (especially as compared to
> not having any affinity at all).
>
> This change modifies the VCPU load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferable
> for the domain to run. If that fails in finding a valid PCPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli<dario.faggioli@citrix.com>

Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

> ---
> Changes from v2:
>   * for_each_csched_balance_step() now is defined as a regular, and
>     easier to understand, 0...n for() loop, instead of a going backwards
>     one, as that wasn't really needed;
>   * checking whether or not a CSCHED_BALANCE_NODE_AFFINITY balancing
>     set is useful or not now happens outside of csched_balance_cpumask(),
>     i.e., closer to the actual loop, making the logic a lot more evident
>     and easy to understand, as requested during review;
>   * while reworking __runq_tickle(), handling of idle pcpu has been brought
>     outside from the balancing loop, as requested during review;
>   * __csched_vcpu_is_migrateable() was just wrong, so it has been removed;
>   * the suboptimal handling of SMT in _csched_cpu_pick() has been moved
>     to a separate patch (i.e., the previous patch in the series);
>   * moved the CPU mask needed for balancing within `csched_pcpu', as
>     suggested during review. This way it is not only more close to
>     other per-PCPU data (potential cache related benefits), but it is
>     also only allocated for the PCPUs credit is in charge of.
>
> Changes from v1:
>   * CPU masks variables moved off from the stack, as requested during
>     review. As per the comments in the code, having them in the private
>     (per-scheduler instance) struct could have been enough, but it would be
>     racy (again, see comments). For that reason, use a global bunch of
>     them of (via per_cpu());
>   * George suggested a different load balancing logic during v1's review. I
>     think he was right and then I changed the old implementation in a way
>     that resembles exactly that. I rewrote most of this patch to introduce
>     a more sensible and effective noda-affinity handling logic.
>
> 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
> @@ -111,6 +111,12 @@
>
>
>   /*
> + * Node Balancing
> + */
> +#define CSCHED_BALANCE_NODE_AFFINITY    0
> +#define CSCHED_BALANCE_CPU_AFFINITY     1
> +
> +/*
>    * Boot parameters
>    */
>   static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
> @@ -125,9 +131,20 @@ struct csched_pcpu {
>       struct timer ticker;
>       unsigned int tick;
>       unsigned int idle_bias;
> +    /* Store this here to avoid having too many cpumask_var_t-s on stack */
> +    cpumask_var_t balance_mask;
>   };
>
>   /*
> + * Convenience macro for accessing the per-PCPU cpumask we need for
> + * implementing the two steps (vcpu and node affinity) balancing logic.
> + * It is stored in csched_pcpu so that serialization is not an issue,
> + * as there is a csched_pcpu for each PCPU and we always hold the
> + * runqueue spin-lock when using this.
> + */
> +#define csched_balance_mask (CSCHED_PCPU(smp_processor_id())->balance_mask)
> +
> +/*
>    * Virtual CPU
>    */
>   struct csched_vcpu {
> @@ -159,6 +176,9 @@ struct csched_dom {
>       struct list_head active_vcpu;
>       struct list_head active_sdom_elem;
>       struct domain *dom;
> +    /* cpumask translated from the domain's node-affinity.
> +     * Basically, the CPUs we prefer to be scheduled on. */
> +    cpumask_var_t node_affinity_cpumask;
>       uint16_t active_vcpu_count;
>       uint16_t weight;
>       uint16_t cap;
> @@ -239,6 +259,43 @@ static inline void
>       list_del_init(&svc->runq_elem);
>   }
>
> +#define for_each_csched_balance_step(step) \
> +    for ( (step) = 0; (step)<= CSCHED_BALANCE_CPU_AFFINITY; (step)++ )
> +
> +
> +/*
> + * vcpu-affinity balancing is always necessary and must never be skipped.
> + * OTOH, if a domain has affinity with all the nodes, we can tell the caller
> + * that he can safely skip the node-affinity balancing step.
> + */
> +#define __vcpu_has_valuable_node_affinity(vc) \
> +    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
> +
> +static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
> +{
> +    if ( step == CSCHED_BALANCE_NODE_AFFINITY
> +&&  !__vcpu_has_valuable_node_affinity(vc) )
> +        return 1;
> +    return 0;
> +}
> +
> +/*
> + * Each csched-balance step uses its own cpumask. This function determines
> + * which one (given the step) and copies it in mask. For the node-affinity
> + * balancing step, the pcpus that are not part of vc's vcpu-affinity are
> + * filtered out from the result, to avoid running a vcpu where it would
> + * like, but is not allowed to!
> + */
> +static void
> +csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
> +{
> +    if ( step == CSCHED_BALANCE_NODE_AFFINITY )
> +        cpumask_and(mask, CSCHED_DOM(vc->domain)->node_affinity_cpumask,
> +                    vc->cpu_affinity);
> +    else /* step == CSCHED_BALANCE_CPU_AFFINITY */
> +        cpumask_copy(mask, vc->cpu_affinity);
> +}
> +
>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>   {
>       s_time_t delta;
> @@ -266,12 +323,12 @@ static inline void
>       struct csched_vcpu * const cur = CSCHED_VCPU(curr_on_cpu(cpu));
>       struct csched_private *prv = CSCHED_PRIV(per_cpu(scheduler, cpu));
>       cpumask_t mask, idle_mask;
> -    int idlers_empty;
> +    int balance_step, idlers_empty;
>
>       ASSERT(cur);
>       cpumask_clear(&mask);
> +    idlers_empty = cpumask_empty(prv->idlers);
>
> -    idlers_empty = cpumask_empty(prv->idlers);
>
>       /*
>        * If the pcpu is idle, or there are no idlers and the new
> @@ -291,41 +348,67 @@ static inline void
>       }
>       else if ( !idlers_empty )
>       {
> -        /* Check whether or not there are idlers that can run new */
> -        cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
> +        /* Node and vcpu-affinity balancing loop */
> +        for_each_csched_balance_step( balance_step )
> +        {
> +            int new_idlers_empty;
>
> -        /*
> -         * If there are no suitable idlers for new, and it's higher
> -         * priority than cur, ask the scheduler to migrate cur away.
> -         * We have to act like this (instead of just waking some of
> -         * the idlers suitable for cur) because cur is running.
> -         *
> -         * If there are suitable idlers for new, no matter priorities,
> -         * leave cur alone (as it is running and is, likely, cache-hot)
> -         * and wake some of them (which is waking up and so is, likely,
> -         * cache cold anyway).
> -         */
> -        if ( cpumask_empty(&idle_mask)&&  new->pri>  cur->pri )
> -        {
> -            SCHED_STAT_CRANK(tickle_idlers_none);
> -            SCHED_VCPU_STAT_CRANK(cur, kicked_away);
> -            SCHED_VCPU_STAT_CRANK(cur, migrate_r);
> -            SCHED_STAT_CRANK(migrate_kicked_away);
> -            set_bit(_VPF_migrating,&cur->vcpu->pause_flags);
> -            cpumask_set_cpu(cpu,&mask);
> -        }
> -        else if ( !cpumask_empty(&idle_mask) )
> -        {
> -            /* Which of the idlers suitable for new shall we wake up? */
> -            SCHED_STAT_CRANK(tickle_idlers_some);
> -            if ( opt_tickle_one_idle )
> +            /* For vcpus with no node-affinity, consider vcpu-affinity only */
> +            if ( csched_balance_step_skippable( balance_step, new->vcpu) )
> +                continue;
> +
> +            /* Are there idlers suitable for new (for this balance step)? */
> +            csched_balance_cpumask(new->vcpu, balance_step,
> +                                   csched_balance_mask);
> +            cpumask_and(&idle_mask, prv->idlers, csched_balance_mask);
> +            new_idlers_empty = cpumask_empty(&idle_mask);
> +
> +            /*
> +             * Let's not be too harsh! If there aren't idlers suitable
> +             * for new in its node-affinity mask, make sure we check its
> +             * vcpu-affinity as well, before taking final decisions.
> +             */
> +            if ( new_idlers_empty
> +&&  balance_step == CSCHED_BALANCE_NODE_AFFINITY )
> +                continue;
> +
> +            /*
> +             * If there are no suitable idlers for new, and it's higher
> +             * priority than cur, ask the scheduler to migrate cur away.
> +             * We have to act like this (instead of just waking some of
> +             * the idlers suitable for cur) because cur is running.
> +             *
> +             * If there are suitable idlers for new, no matter priorities,
> +             * leave cur alone (as it is running and is, likely, cache-hot)
> +             * and wake some of them (which is waking up and so is, likely,
> +             * cache cold anyway).
> +             */
> +            if ( new_idlers_empty&&  new->pri>  cur->pri )
>               {
> -                this_cpu(last_tickle_cpu) =
> -                    cpumask_cycle(this_cpu(last_tickle_cpu),&idle_mask);
> -                cpumask_set_cpu(this_cpu(last_tickle_cpu),&mask);
> +                SCHED_STAT_CRANK(tickle_idlers_none);
> +                SCHED_VCPU_STAT_CRANK(cur, kicked_away);
> +                SCHED_VCPU_STAT_CRANK(cur, migrate_r);
> +                SCHED_STAT_CRANK(migrate_kicked_away);
> +                set_bit(_VPF_migrating,&cur->vcpu->pause_flags);
> +                cpumask_set_cpu(cpu,&mask);
>               }
> -            else
> -                cpumask_or(&mask,&mask,&idle_mask);
> +            else if ( !new_idlers_empty )
> +            {
> +                /* Which of the idlers suitable for new shall we wake up? */
> +                SCHED_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);
> +            }
> +
> +            /* Did we find anyone? */
> +            if ( !cpumask_empty(&mask) )
> +                break;
>           }
>       }
>
> @@ -370,6 +453,7 @@ csched_free_pdata(const struct scheduler
>
>       spin_unlock_irqrestore(&prv->lock, flags);
>
> +    free_cpumask_var(spc->balance_mask);
>       xfree(spc);
>   }
>
> @@ -385,6 +469,12 @@ csched_alloc_pdata(const struct schedule
>       if ( spc == NULL )
>           return NULL;
>
> +    if ( !alloc_cpumask_var(&spc->balance_mask) )
> +    {
> +        xfree(spc);
> +        return NULL;
> +    }
> +
>       spin_lock_irqsave(&prv->lock, flags);
>
>       /* Initialize/update system-wide config */
> @@ -475,15 +565,16 @@ 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
> -     * peer PCPU. Only pick up work that's allowed to run on our CPU.
> +     * peer PCPU. Only pick up work that prefers and/or is allowed to run
> +     * on our CPU.
>        */
>       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
> @@ -493,97 +584,110 @@ static int
>       cpumask_t idlers;
>       cpumask_t *online;
>       struct csched_pcpu *spc = NULL;
> -    int cpu;
> +    int cpu = vc->processor;
> +    int balance_step;
>
> -    /*
> -     * Pick from online CPUs in VCPU's affinity mask, giving a
> -     * preference to its current processor if it's in there.
> -     */
>       online = cpupool_scheduler_cpumask(vc->domain->cpupool);
> -    cpumask_and(&cpus, online, vc->cpu_affinity);
> -    cpu = cpumask_test_cpu(vc->processor,&cpus)
> -            ? vc->processor
> -            : cpumask_cycle(vc->processor,&cpus);
> -    ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );
> +    for_each_csched_balance_step( balance_step )
> +    {
> +        if ( csched_balance_step_skippable( balance_step, vc) )
> +            continue;
>
> -    /*
> -     * Try to find an idle processor within the above constraints.
> -     *
> -     * In multi-core and multi-threaded CPUs, not all idle execution
> -     * vehicles are equal!
> -     *
> -     * We give preference to the idle execution vehicle with the most
> -     * idling neighbours in its grouping. This distributes work across
> -     * distinct cores first and guarantees we don't do something stupid
> -     * like run two VCPUs on co-hyperthreads while there are idle cores
> -     * or sockets.
> -     *
> -     * Notice that, when computing the "idleness" of cpu, we may want to
> -     * discount vc. That is, iff vc is the currently running and the only
> -     * runnable vcpu on cpu, we add cpu to the idlers.
> -     */
> -    cpumask_and(&idlers,&cpu_online_map, CSCHED_PRIV(ops)->idlers);
> -    if ( vc->processor == cpu&&  IS_RUNQ_IDLE(cpu) )
> -        cpumask_set_cpu(cpu,&idlers);
> -    cpumask_and(&cpus,&cpus,&idlers);
> +        /* Pick an online CPU from the proper affinity mask */
> +        csched_balance_cpumask(vc, balance_step,&cpus);
> +        cpumask_and(&cpus,&cpus, online);
>
> -    /*
> -     * It is important that cpu points to an idle processor, if a suitable
> -     * one exists (and we can use cpus to check and, possibly, choose a new
> -     * CPU, as we just&&-ed it with idlers). In fact, if we are on SMT, and
> -     * cpu points to a busy thread with an idle sibling, both the threads
> -     * will be considered the same, from the "idleness" calculation point
> -     * of view", preventing vcpu from being moved to the thread that is
> -     * actually idle.
> -     */
> -    if ( !cpumask_empty(&cpus)&&  !cpumask_test_cpu(cpu,&cpus) )
> -        cpu = cpumask_cycle(cpu,&cpus);
> -    cpumask_clear_cpu(cpu,&cpus);
> +        /* If present, prefer vc's current processor */
> +        cpu = cpumask_test_cpu(vc->processor,&cpus)
> +                ? vc->processor
> +                : cpumask_cycle(vc->processor,&cpus);
> +        ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );
>
> -    while ( !cpumask_empty(&cpus) )
> -    {
> -        cpumask_t cpu_idlers;
> -        cpumask_t nxt_idlers;
> -        int nxt, weight_cpu, weight_nxt;
> -        int migrate_factor;
> +        /*
> +         * Try to find an idle processor within the above constraints.
> +         *
> +         * In multi-core and multi-threaded CPUs, not all idle execution
> +         * vehicles are equal!
> +         *
> +         * We give preference to the idle execution vehicle with the most
> +         * idling neighbours in its grouping. This distributes work across
> +         * distinct cores first and guarantees we don't do something stupid
> +         * like run two VCPUs on co-hyperthreads while there are idle cores
> +         * or sockets.
> +         *
> +         * Notice that, when computing the "idleness" of cpu, we may want to
> +         * discount vc. That is, iff vc is the currently running and the only
> +         * runnable vcpu on cpu, we add cpu to the idlers.
> +         */
> +        cpumask_and(&idlers,&cpu_online_map, CSCHED_PRIV(ops)->idlers);
> +        if ( vc->processor == cpu&&  IS_RUNQ_IDLE(cpu) )
> +            cpumask_set_cpu(cpu,&idlers);
> +        cpumask_and(&cpus,&cpus,&idlers);
>
> -        nxt = cpumask_cycle(cpu,&cpus);
> +        /*
> +         * It is important that cpu points to an idle processor, if a suitable
> +         * one exists (and we can use cpus to check and, possibly, choose a new
> +         * CPU, as we just&&-ed it with idlers). In fact, if we are on SMT, and
> +         * cpu points to a busy thread with an idle sibling, both the threads
> +         * will be considered the same, from the "idleness" calculation point
> +         * of view", preventing vcpu from being moved to the thread that is
> +         * actually idle.
> +         */
> +        if ( !cpumask_empty(&cpus)&&  !cpumask_test_cpu(cpu,&cpus) )
> +            cpu = cpumask_cycle(cpu,&cpus);
> +        cpumask_clear_cpu(cpu,&cpus);
>
> -        if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
> +        while ( !cpumask_empty(&cpus) )
>           {
> -            /* We're on the same socket, so check the busy-ness of threads.
> -             * Migrate if # of idlers is less at all */
> -            ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> -            migrate_factor = 1;
> -            cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_sibling_mask, cpu));
> -            cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_sibling_mask, nxt));
> -        }
> -        else
> -        {
> -            /* We're on different sockets, so check the busy-ness of cores.
> -             * Migrate only if the other core is twice as idle */
> -            ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> -            migrate_factor = 2;
> -            cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_core_mask, cpu));
> -            cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_core_mask, nxt));
> +            cpumask_t cpu_idlers;
> +            cpumask_t nxt_idlers;
> +            int nxt, weight_cpu, weight_nxt;
> +            int migrate_factor;
> +
> +            nxt = cpumask_cycle(cpu,&cpus);
> +
> +            if ( cpumask_test_cpu(cpu, per_cpu(cpu_core_mask, nxt)) )
> +            {
> +                /* We're on the same socket, so check the busy-ness of threads.
> +                 * Migrate if # of idlers is less at all */
> +                ASSERT( cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> +                migrate_factor = 1;
> +                cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_sibling_mask,
> +                            cpu));
> +                cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_sibling_mask,
> +                            nxt));
> +            }
> +            else
> +            {
> +                /* We're on different sockets, so check the busy-ness of cores.
> +                 * Migrate only if the other core is twice as idle */
> +                ASSERT( !cpumask_test_cpu(nxt, per_cpu(cpu_core_mask, cpu)) );
> +                migrate_factor = 2;
> +                cpumask_and(&cpu_idlers,&idlers, per_cpu(cpu_core_mask, cpu));
> +                cpumask_and(&nxt_idlers,&idlers, per_cpu(cpu_core_mask, nxt));
> +            }
> +
> +            weight_cpu = cpumask_weight(&cpu_idlers);
> +            weight_nxt = cpumask_weight(&nxt_idlers);
> +            /* smt_power_savings: consolidate work rather than spreading it */
> +            if ( sched_smt_power_savings ?
> +                 weight_cpu>  weight_nxt :
> +                 weight_cpu * migrate_factor<  weight_nxt )
> +            {
> +                cpumask_and(&nxt_idlers,&cpus,&nxt_idlers);
> +                spc = CSCHED_PCPU(nxt);
> +                cpu = cpumask_cycle(spc->idle_bias,&nxt_idlers);
> +                cpumask_andnot(&cpus,&cpus, per_cpu(cpu_sibling_mask, cpu));
> +            }
> +            else
> +            {
> +                cpumask_andnot(&cpus,&cpus,&nxt_idlers);
> +            }
>           }
>
> -        weight_cpu = cpumask_weight(&cpu_idlers);
> -        weight_nxt = cpumask_weight(&nxt_idlers);
> -        /* smt_power_savings: consolidate work rather than spreading it */
> -        if ( sched_smt_power_savings ?
> -             weight_cpu>  weight_nxt :
> -             weight_cpu * migrate_factor<  weight_nxt )
> -        {
> -            cpumask_and(&nxt_idlers,&cpus,&nxt_idlers);
> -            spc = CSCHED_PCPU(nxt);
> -            cpu = cpumask_cycle(spc->idle_bias,&nxt_idlers);
> -            cpumask_andnot(&cpus,&cpus, per_cpu(cpu_sibling_mask, cpu));
> -        }
> -        else
> -        {
> -            cpumask_andnot(&cpus,&cpus,&nxt_idlers);
> -        }
> +        /* Stop if cpu is idle */
> +        if ( cpumask_test_cpu(cpu,&idlers) )
> +            break;
>       }
>
>       if ( commit&&  spc )
> @@ -925,6 +1029,13 @@ csched_alloc_domdata(const struct schedu
>       if ( sdom == NULL )
>           return NULL;
>
> +    if ( !alloc_cpumask_var(&sdom->node_affinity_cpumask) )
> +    {
> +        xfree(sdom);
> +        return NULL;
> +    }
> +    cpumask_setall(sdom->node_affinity_cpumask);
> +
>       /* Initialize credit and weight */
>       INIT_LIST_HEAD(&sdom->active_vcpu);
>       sdom->active_vcpu_count = 0;
> @@ -956,6 +1067,9 @@ csched_dom_init(const struct scheduler *
>   static void
>   csched_free_domdata(const struct scheduler *ops, void *data)
>   {
> +    struct csched_dom *sdom = data;
> +
> +    free_cpumask_var(sdom->node_affinity_cpumask);
>       xfree(data);
>   }
>
> @@ -1252,7 +1366,7 @@ csched_tick(void *_cpu)
>   }
>
>   static struct csched_vcpu *
> -csched_runq_steal(int peer_cpu, int cpu, int pri)
> +csched_runq_steal(int peer_cpu, int cpu, int pri, int balance_step)
>   {
>       const struct csched_pcpu * const peer_pcpu = CSCHED_PCPU(peer_cpu);
>       const struct vcpu * const peer_vcpu = curr_on_cpu(peer_cpu);
> @@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,
>               if ( speer->pri<= pri )
>                   break;
>
> -            /* Is this VCPU is runnable on our PCPU? */
> +            /* Is this VCPU runnable on our PCPU? */
>               vc = speer->vcpu;
>               BUG_ON( is_idle_vcpu(vc) );
>
> -            if (__csched_vcpu_is_migrateable(vc, cpu))
> +            /*
> +             * If the vcpu has no valuable node-affinity, skip this vcpu.
> +             * In fact, what we want is to check if we have any node-affine
> +             * work to steal, before starting to look at vcpu-affine work.
> +             */
> +            if ( balance_step == CSCHED_BALANCE_NODE_AFFINITY
> +&&  !__vcpu_has_valuable_node_affinity(vc) )
> +                continue;
> +
> +            csched_balance_cpumask(vc, balance_step, csched_balance_mask);
> +            if ( __csched_vcpu_is_migrateable(vc, cpu, csched_balance_mask) )
>               {
>                   /* We got a candidate. Grab it! */
>                   TRACE_3D(TRC_CSCHED_STOLEN_VCPU, peer_cpu,
> @@ -1307,7 +1431,8 @@ csched_load_balance(struct csched_privat
>       struct csched_vcpu *speer;
>       cpumask_t workers;
>       cpumask_t *online;
> -    int peer_cpu;
> +    int peer_cpu, peer_node, bstep;
> +    int node = cpu_to_node(cpu);
>
>       BUG_ON( cpu != snext->vcpu->processor );
>       online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
> @@ -1324,42 +1449,68 @@ csched_load_balance(struct csched_privat
>           SCHED_STAT_CRANK(load_balance_other);
>
>       /*
> -     * Peek at non-idling CPUs in the system, starting with our
> -     * immediate neighbour.
> +     * Let's look around for work to steal, taking both vcpu-affinity
> +     * and node-affinity into account. More specifically, we check all
> +     * the non-idle CPUs' runq, looking for:
> +     *  1. any node-affine work to steal first,
> +     *  2. if not finding anything, any vcpu-affine work to steal.
>        */
> -    cpumask_andnot(&workers, online, prv->idlers);
> -    cpumask_clear_cpu(cpu,&workers);
> -    peer_cpu = cpu;
> +    for_each_csched_balance_step( bstep )
> +    {
> +        /*
> +         * We peek at the non-idling CPUs in a node-wise fashion. In fact,
> +         * it is more likely that we find some node-affine work on our same
> +         * node, not to mention that migrating vcpus within the same node
> +         * could well expected to be cheaper than across-nodes (memory
> +         * stays local, there might be some node-wide cache[s], etc.).
> +         */
> +        peer_node = node;
> +        do
> +        {
> +            /* Find out what the !idle are in this node */
> +            cpumask_andnot(&workers, online, prv->idlers);
> +            cpumask_and(&workers,&workers,&node_to_cpumask(peer_node));
> +            cpumask_clear_cpu(cpu,&workers);
>
> -    while ( !cpumask_empty(&workers) )
> -    {
> -        peer_cpu = cpumask_cycle(peer_cpu,&workers);
> -        cpumask_clear_cpu(peer_cpu,&workers);
> +            if ( cpumask_empty(&workers) )
> +                goto next_node;
>
> -        /*
> -         * Get ahold of the scheduler lock for this peer CPU.
> -         *
> -         * Note: We don't spin on this lock but simply try it. Spinning could
> -         * cause a deadlock if the peer CPU is also load balancing and trying
> -         * to lock this CPU.
> -         */
> -        if ( !pcpu_schedule_trylock(peer_cpu) )
> -        {
> -            SCHED_STAT_CRANK(steal_trylock_failed);
> -            continue;
> -        }
> +            peer_cpu = cpumask_first(&workers);
> +            do
> +            {
> +                /*
> +                 * Get ahold of the scheduler lock for this peer CPU.
> +                 *
> +                 * Note: We don't spin on this lock but simply try it. Spinning
> +                 * could cause a deadlock if the peer CPU is also load
> +                 * balancing and trying to lock this CPU.
> +                 */
> +                if ( !pcpu_schedule_trylock(peer_cpu) )
> +                {
> +                    SCHED_STAT_CRANK(steal_trylock_failed);
> +                    peer_cpu = cpumask_cycle(peer_cpu,&workers);
> +                    continue;
> +                }
>
> -        /*
> -         * Any work over there to steal?
> -         */
> -        speer = cpumask_test_cpu(peer_cpu, online) ?
> -            csched_runq_steal(peer_cpu, cpu, snext->pri) : NULL;
> -        pcpu_schedule_unlock(peer_cpu);
> -        if ( speer != NULL )
> -        {
> -            *stolen = 1;
> -            return speer;
> -        }
> +                /* Any work over there to steal? */
> +                speer = cpumask_test_cpu(peer_cpu, online) ?
> +                    csched_runq_steal(peer_cpu, cpu, snext->pri, bstep) : NULL;
> +                pcpu_schedule_unlock(peer_cpu);
> +
> +                /* As soon as one vcpu is found, balancing ends */
> +                if ( speer != NULL )
> +                {
> +                    *stolen = 1;
> +                    return speer;
> +                }
> +
> +                peer_cpu = cpumask_cycle(peer_cpu,&workers);
> +
> +            } while( peer_cpu != cpumask_first(&workers) );
> +
> + next_node:
> +            peer_node = cycle_node(peer_node, node_online_map);
> +        } while( peer_node != node );
>       }
>
>    out:
> 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
> @@ -41,6 +41,8 @@
>    * int last_node(mask)			Number highest set bit, or MAX_NUMNODES
>    * int first_unset_node(mask)		First node not set in mask, or
>    *					MAX_NUMNODES.
> + * int cycle_node(node, mask)		Next node cycling from 'node', or
> + *					MAX_NUMNODES
>    *
>    * nodemask_t nodemask_of_node(node)	Return nodemask with bit 'node' set
>    * NODE_MASK_ALL			Initializer - all bits set
> @@ -254,6 +256,16 @@ static inline int __first_unset_node(con
>   			find_first_zero_bit(maskp->bits, MAX_NUMNODES));
>   }
>
> +#define cycle_node(n, src) __cycle_node((n),&(src), MAX_NUMNODES)
> +static inline int __cycle_node(int n, const nodemask_t *maskp, int nbits)
> +{
> +    int nxt = __next_node(n, maskp, nbits);
> +
> +    if (nxt == nbits)
> +        nxt = __first_node(maskp, nbits);
> +    return nxt;
> +}
> +
>   #define NODE_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(MAX_NUMNODES)
>
>   #if MAX_NUMNODES<= BITS_PER_LONG
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 01 14:43:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14: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 1U1Hpd-0004fg-UW; Fri, 01 Feb 2013 14:43:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U1Hpd-0004fb-12
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:43:09 +0000
Received: from [85.158.139.211:6892] by server-7.bemta-5.messagelabs.com id
	53/83-11121-C74DB015; Fri, 01 Feb 2013 14:43:08 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1359729784!20646684!1
X-Originating-IP: [209.85.128.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14366 invoked from network); 1 Feb 2013 14:43:05 -0000
Received: from mail-ve0-f180.google.com (HELO mail-ve0-f180.google.com)
	(209.85.128.180)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:43:05 -0000
Received: by mail-ve0-f180.google.com with SMTP id jx10so3006249veb.11
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 06:43:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=dBSd0Y5UsRlwYq/14XMREAbfXshGQY1tFPmYSgpOCxo=;
	b=yu95QSCQ0nhtLWH2WSiPUf0AmaedYp11wcVQ5F1JHXhxlE3oukmPKbIQILvSFleJEB
	y5S6bHko7trC1ngRiTOtoB5pCQlXqu5NI6jATuC4ut+D09xqzSqoG51jtRzPHhYPp0RH
	ydDM9WVGoSOT+YQTjEntXB2TDx6fhNYNbe6wPb7uS+Gs8zHLr9gbLSdnUF+o0izNA/l4
	jl6qxg5MVGQBCuTjxFe7T2hlLigBdb0ktHMH2BkjRucAfsWw5XmAvlWRgMjFnoanLRo5
	xl9orv7W9gK+EXBWoI1Oc/TUn8Pmb0WjWudhyqTrJX5CYZWQjNOCrYrVDCO8Tk0ItXzB
	FVWA==
X-Received: by 10.59.7.170 with SMTP id dd10mr7356372ved.2.1359729783544;
	Fri, 01 Feb 2013 06:43:03 -0800 (PST)
Received: from konrad-lan.dumpdata.com (ip-64-134-67-155.public.wayport.net.
	[64.134.67.155])
	by mx.google.com with ESMTPS id p20sm8210216vdj.6.2013.02.01.06.43.02
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 06:43:03 -0800 (PST)
Date: Fri, 1 Feb 2013 09:42:56 -0500
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20130201144255.GA7461@konrad-lan.dumpdata.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
	<1359655545.23229.101.camel@zion.uk.xensource.com>
	<CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback disk I/O limit 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

On Fri, Feb 01, 2013 at 10:53:46AM +0400, Vasiliy Tolstov wrote:
> Sorry,

Ugh, you didn't inline it - you just copied and pasted it.

Also you are missing an SoB and a description of what this patch does
and why is it better than existing device mapper I/O limiting work?

> 
> diff -NruabBEp xen_blkback_limit.orig/blkback.c xen_blkback_limit.new//blkback.c
> --- xen_blkback_limit.orig/blkback.c 2012-12-04 13:03:58.000000000 +0400
> +++ xen_blkback_limit.new//blkback.c 2013-01-28 08:11:30.000000000 +0400
> @@ -211,10 +211,18 @@ static void print_stats(blkif_t *blkif)
>   blkif->st_pk_req = 0;
>  }
> 
> +static void refill_iops(blkif_t *blkif)
> +{
> + blkif->reqtime = jiffies + msecs_to_jiffies(1000);
> + blkif->reqcount = 0;
> +}
> +
>  int blkif_schedule(void *arg)
>  {
>   blkif_t *blkif = arg;
>   struct vbd *vbd = &blkif->vbd;
> + int     ret = 0;
> + struct timeval cur_time;
> 
>   blkif_get(blkif);
> 
> @@ -237,10 +245,22 @@ int blkif_schedule(void *arg)
>   blkif->waiting_reqs = 0;
>   smp_mb(); /* clear flag *before* checking for work */
> 
> - if (do_block_io_op(blkif))
> + ret = do_block_io_op(blkif);
> + if (ret)
>   blkif->waiting_reqs = 1;
>   unplug_queue(blkif);
> 
> + if (blkif->reqrate) {
> + if (2 == ret && (blkif->reqtime > jiffies)) {
> + jiffies_to_timeval(jiffies, &cur_time);
> +
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(blkif->reqtime - jiffies);
> + }
> + if (time_after(jiffies, blkif->reqtime))
> + refill_iops(blkif);
> + }
> +
>   if (log_stats && time_after(jiffies, blkif->st_print))
>   print_stats(blkif);
>   }
> @@ -394,10 +414,19 @@ static int _do_block_io_op(blkif_t *blki
>   rp = blk_rings->common.sring->req_prod;
>   rmb(); /* Ensure we see queued requests up to 'rp'. */
> 
> + if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
> + return (rc != rp) ? 2 : 0;
> + }
> +
>   while (rc != rp) {
>   if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
>   break;
> 
> + if (blkif->reqrate) {
> + if (blkif->reqcount >= blkif->reqrate)
> + return 2;
> + }
> +
>   if (kthread_should_stop())
>   return 1;
> 
> @@ -434,8 +463,8 @@ static int _do_block_io_op(blkif_t *blki
> 
>   /* Apply all sanity checks to /private copy/ of request. */
>   barrier();
> -
>   dispatch_rw_block_io(blkif, &req, pending_req);
> + blkif->reqcount++;
>   break;
>   case BLKIF_OP_DISCARD:
>   blk_rings->common.req_cons = rc;
> @@ -452,7 +481,7 @@ static int _do_block_io_op(blkif_t *blki
>   break;
>   default:
>   /* A good sign something is wrong: sleep for a while to
> - * avoid excessive CPU consumption by a bad guest. */
> + * avoid excessive CPU consumption by a bad guest.*/
>   msleep(1);
>   blk_rings->common.req_cons = rc;
>   barrier();
> @@ -501,6 +530,7 @@ static void dispatch_rw_block_io(blkif_t
>   uint32_t flags;
>   int ret, i;
>   int operation;
> + struct timeval cur_time;
> 
>   switch (req->operation) {
>   case BLKIF_OP_READ:
> @@ -658,6 +688,7 @@ static void dispatch_rw_block_io(blkif_t
>   else
>   blkif->st_wr_sect += preq.nr_sects;
> 
> + jiffies_to_timeval(jiffies, &cur_time);
>   return;
> 
>   fail_flush:
> diff -NruabBEp xen_blkback_limit.orig/common.h xen_blkback_limit.new//common.h
> --- xen_blkback_limit.orig/common.h 2012-12-04 13:03:58.000000000 +0400
> +++ xen_blkback_limit.new//common.h 2013-01-28 08:09:35.000000000 +0400
> @@ -82,6 +82,11 @@ typedef struct blkif_st {
>   unsigned int        waiting_reqs;
>   struct request_queue *plug;
> 
> + /* qos information */
> + unsigned long   reqtime;
> + int    reqcount;
> + int    reqrate;
> +
>   /* statistics */
>   unsigned long       st_print;
>   int                 st_rd_req;
> @@ -106,6 +111,8 @@ struct backend_info
>   unsigned major;
>   unsigned minor;
>   char *mode;
> + /* qos information */
> + struct xenbus_watch reqrate_watch;
>  };
> 
>  blkif_t *blkif_alloc(domid_t domid);
> diff -NruabBEp xen_blkback_limit.orig/xenbus.c xen_blkback_limit.new//xenbus.c
> --- xen_blkback_limit.orig/xenbus.c 2012-12-04 13:03:58.000000000 +0400
> +++ xen_blkback_limit.new//xenbus.c 2013-01-28 08:22:26.000000000 +0400
> @@ -120,6 +120,79 @@ static void update_blkif_status(blkif_t
>   } \
>   static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
> 
> +static ssize_t
> +show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
> +{
> + ssize_t ret = -ENODEV;
> + struct xenbus_device *dev;
> + struct backend_info *be;
> +
> + if (!get_device(_dev))
> + return ret;
> +
> + dev = to_xenbus_device(_dev);
> + be = dev_get_drvdata(&dev->dev);
> +
> + if (be != NULL)
> + ret = sprintf(buf, "%d\n", be->blkif->reqrate);
> +
> + put_device(_dev);
> +
> + return ret;
> +}
> +
> +static ssize_t
> +store_reqrate(struct device *_dev, struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + int value;
> + struct xenbus_device *dev;
> + struct backend_info *be;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + if (!get_device(_dev))
> + return -ENODEV;
> +
> + if (sscanf(buf, "%d", &value) != 1)
> + return -EINVAL;
> +
> + dev = to_xenbus_device(_dev);
> + be = dev_get_drvdata(&dev->dev);
> +
> + if (be != NULL)
> + be->blkif->reqrate = value;
> +
> + put_device(_dev);
> +
> + return size;
> +}
> +static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
> + store_reqrate);
> +
> +static ssize_t
> +show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
> +{
> + ssize_t ret = -ENODEV;
> + struct xenbus_device *dev;
> + struct backend_info *be;
> +
> + if (!get_device(_dev))
> + return ret;
> +
> + dev = to_xenbus_device(_dev);
> + be = dev_get_drvdata(&dev->dev);
> +
> + if (be != NULL)
> + ret = sprintf(buf, "%d\n", be->blkif->reqcount);
> +
> + put_device(_dev);
> +
> + return ret;
> +}
> +static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
> +
>  VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
>  VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
>  VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
> @@ -146,6 +219,17 @@ static const struct attribute_group vbds
>   .attrs = vbdstat_attrs,
>  };
> 
> +static struct attribute *vbdreq_attrs[] = {
> + &dev_attr_reqrate.attr,
> + &dev_attr_reqcount.attr,
> + NULL
> +};
> +
> +static const struct attribute_group vbdreq_group = {
> + .name = "qos",
> + .attrs = vbdreq_attrs,
> +};
> +
>  VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
>  VBD_SHOW(mode, "%s\n", be->mode);
> 
> @@ -165,8 +249,13 @@ int xenvbd_sysfs_addif(struct xenbus_dev
>   if (error)
>   goto fail3;
> 
> + error = sysfs_create_group(&dev->dev.kobj, &vbdreq_group);
> + if (error)
> + goto fail4;
> +
>   return 0;
> 
> +fail4:  sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>  fail3: sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>  fail2: device_remove_file(&dev->dev, &dev_attr_mode);
>  fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
> @@ -175,6 +264,7 @@ fail1: device_remove_file(&dev->dev, &de
> 
>  void xenvbd_sysfs_delif(struct xenbus_device *dev)
>  {
> + sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>   sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>   device_remove_file(&dev->dev, &dev_attr_mode);
>   device_remove_file(&dev->dev, &dev_attr_physical_device);
> @@ -201,6 +291,12 @@ static int blkback_remove(struct xenbus_
>   be->cdrom_watch.node = NULL;
>   }
> 
> + if (be->reqrate_watch.node) {
> + unregister_xenbus_watch(&be->reqrate_watch);
> + kfree(be->reqrate_watch.node);
> + be->reqrate_watch.node = NULL;
> + }
> +
>   if (be->blkif) {
>   blkif_disconnect(be->blkif);
>   vbd_free(&be->blkif->vbd);
> @@ -338,6 +434,7 @@ static void backend_changed(struct xenbu
>   struct xenbus_device *dev = be->dev;
>   int cdrom = 0;
>   char *device_type;
> + char name[TASK_COMM_LEN];
> 
>   DPRINTK("");
> 
> @@ -376,6 +473,21 @@ static void backend_changed(struct xenbu
>   kfree(device_type);
>   }
> 
> + /* gather information about QoS policy for this device. */
> + err = blkback_name(be->blkif, name);
> + if (err) {
> + xenbus_dev_error(be->dev, err, "get blkback dev name");
> + return;
> + }
> +
> + err = xenbus_gather(XBT_NIL, dev->otherend,
> + "reqrate", "%d", &be->blkif->reqrate,
> + NULL);
> + if (err)
> + DPRINTK("%s xenbus_gather(reqrate) error", name);
> +
> + be->blkif->reqtime = jiffies;
> +
>   if (be->major == 0 && be->minor == 0) {
>   /* Front end dir is a number, which is used as the handle. */
> 
> @@ -482,6 +594,30 @@ static void frontend_changed(struct xenb
> 
>  /* ** Connection ** */
> 
> +static void reqrate_changed(struct xenbus_watch *watch,
> + const char **vec, unsigned int len)
> +{
> + struct backend_info *be = container_of(watch, struct backend_info,
> + reqrate_watch);
> + int err;
> + char name[TASK_COMM_LEN];
> +
> + err = blkback_name(be->blkif, name);
> + if (err) {
> + xenbus_dev_error(be->dev, err, "get blkback dev name");
> + return;
> + }
> +
> + err = xenbus_gather(XBT_NIL, be->dev->otherend,
> + "reqrate",  "%d",
> + &be->blkif->reqrate, NULL);
> + if (err) {
> + DPRINTK("%s xenbus_gather(reqrate) error", name);
> + } else {
> + if (be->blkif->reqrate <= 0)
> + be->blkif->reqrate = 0;
> + }
> +}
> 
>  /**
>   * Write the physical details regarding the block device to the store, and
> @@ -542,6 +678,21 @@ again:
>   xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
>   dev->nodename);
> 
> + if (be->reqrate_watch.node) {
> + unregister_xenbus_watch(&be->reqrate_watch);
> + kfree(be->reqrate_watch.node);
> + be->reqrate_watch.node = NULL;
> + }
> +
> + err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
> + &be->reqrate_watch,
> + reqrate_changed);
> + if (err) {
> + xenbus_dev_fatal(dev, err, "%s: watching reqrate",
> + dev->nodename);
> + goto abort;
> + }
> +
>   return;
>   abort:
>   xenbus_transaction_end(xbt, 1);
> 
> 2013/1/31 Wei Liu <wei.liu2@citrix.com>:
> > On Thu, 2013-01-31 at 05:14 +0000, Vasiliy Tolstov wrote:
> >> Sorry forget to send patch
> >> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
> >> Patch for kernel 3.6.9, but if that needed i can rebase it to current
> >> git Linus tree.
> >
> > Can you inline your patch in your email so that developer can comment on
> > it.
> >
> >
> > Wei.
> >
> 
> 
> 
> -- 
> 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
> 

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:43:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14: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 1U1Hpd-0004fg-UW; Fri, 01 Feb 2013 14:43:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U1Hpd-0004fb-12
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:43:09 +0000
Received: from [85.158.139.211:6892] by server-7.bemta-5.messagelabs.com id
	53/83-11121-C74DB015; Fri, 01 Feb 2013 14:43:08 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1359729784!20646684!1
X-Originating-IP: [209.85.128.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14366 invoked from network); 1 Feb 2013 14:43:05 -0000
Received: from mail-ve0-f180.google.com (HELO mail-ve0-f180.google.com)
	(209.85.128.180)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:43:05 -0000
Received: by mail-ve0-f180.google.com with SMTP id jx10so3006249veb.11
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 06:43:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=dBSd0Y5UsRlwYq/14XMREAbfXshGQY1tFPmYSgpOCxo=;
	b=yu95QSCQ0nhtLWH2WSiPUf0AmaedYp11wcVQ5F1JHXhxlE3oukmPKbIQILvSFleJEB
	y5S6bHko7trC1ngRiTOtoB5pCQlXqu5NI6jATuC4ut+D09xqzSqoG51jtRzPHhYPp0RH
	ydDM9WVGoSOT+YQTjEntXB2TDx6fhNYNbe6wPb7uS+Gs8zHLr9gbLSdnUF+o0izNA/l4
	jl6qxg5MVGQBCuTjxFe7T2hlLigBdb0ktHMH2BkjRucAfsWw5XmAvlWRgMjFnoanLRo5
	xl9orv7W9gK+EXBWoI1Oc/TUn8Pmb0WjWudhyqTrJX5CYZWQjNOCrYrVDCO8Tk0ItXzB
	FVWA==
X-Received: by 10.59.7.170 with SMTP id dd10mr7356372ved.2.1359729783544;
	Fri, 01 Feb 2013 06:43:03 -0800 (PST)
Received: from konrad-lan.dumpdata.com (ip-64-134-67-155.public.wayport.net.
	[64.134.67.155])
	by mx.google.com with ESMTPS id p20sm8210216vdj.6.2013.02.01.06.43.02
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 06:43:03 -0800 (PST)
Date: Fri, 1 Feb 2013 09:42:56 -0500
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20130201144255.GA7461@konrad-lan.dumpdata.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
	<1359655545.23229.101.camel@zion.uk.xensource.com>
	<CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback disk I/O limit 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

On Fri, Feb 01, 2013 at 10:53:46AM +0400, Vasiliy Tolstov wrote:
> Sorry,

Ugh, you didn't inline it - you just copied and pasted it.

Also you are missing an SoB and a description of what this patch does
and why is it better than existing device mapper I/O limiting work?

> 
> diff -NruabBEp xen_blkback_limit.orig/blkback.c xen_blkback_limit.new//blkback.c
> --- xen_blkback_limit.orig/blkback.c 2012-12-04 13:03:58.000000000 +0400
> +++ xen_blkback_limit.new//blkback.c 2013-01-28 08:11:30.000000000 +0400
> @@ -211,10 +211,18 @@ static void print_stats(blkif_t *blkif)
>   blkif->st_pk_req = 0;
>  }
> 
> +static void refill_iops(blkif_t *blkif)
> +{
> + blkif->reqtime = jiffies + msecs_to_jiffies(1000);
> + blkif->reqcount = 0;
> +}
> +
>  int blkif_schedule(void *arg)
>  {
>   blkif_t *blkif = arg;
>   struct vbd *vbd = &blkif->vbd;
> + int     ret = 0;
> + struct timeval cur_time;
> 
>   blkif_get(blkif);
> 
> @@ -237,10 +245,22 @@ int blkif_schedule(void *arg)
>   blkif->waiting_reqs = 0;
>   smp_mb(); /* clear flag *before* checking for work */
> 
> - if (do_block_io_op(blkif))
> + ret = do_block_io_op(blkif);
> + if (ret)
>   blkif->waiting_reqs = 1;
>   unplug_queue(blkif);
> 
> + if (blkif->reqrate) {
> + if (2 == ret && (blkif->reqtime > jiffies)) {
> + jiffies_to_timeval(jiffies, &cur_time);
> +
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(blkif->reqtime - jiffies);
> + }
> + if (time_after(jiffies, blkif->reqtime))
> + refill_iops(blkif);
> + }
> +
>   if (log_stats && time_after(jiffies, blkif->st_print))
>   print_stats(blkif);
>   }
> @@ -394,10 +414,19 @@ static int _do_block_io_op(blkif_t *blki
>   rp = blk_rings->common.sring->req_prod;
>   rmb(); /* Ensure we see queued requests up to 'rp'. */
> 
> + if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
> + return (rc != rp) ? 2 : 0;
> + }
> +
>   while (rc != rp) {
>   if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
>   break;
> 
> + if (blkif->reqrate) {
> + if (blkif->reqcount >= blkif->reqrate)
> + return 2;
> + }
> +
>   if (kthread_should_stop())
>   return 1;
> 
> @@ -434,8 +463,8 @@ static int _do_block_io_op(blkif_t *blki
> 
>   /* Apply all sanity checks to /private copy/ of request. */
>   barrier();
> -
>   dispatch_rw_block_io(blkif, &req, pending_req);
> + blkif->reqcount++;
>   break;
>   case BLKIF_OP_DISCARD:
>   blk_rings->common.req_cons = rc;
> @@ -452,7 +481,7 @@ static int _do_block_io_op(blkif_t *blki
>   break;
>   default:
>   /* A good sign something is wrong: sleep for a while to
> - * avoid excessive CPU consumption by a bad guest. */
> + * avoid excessive CPU consumption by a bad guest.*/
>   msleep(1);
>   blk_rings->common.req_cons = rc;
>   barrier();
> @@ -501,6 +530,7 @@ static void dispatch_rw_block_io(blkif_t
>   uint32_t flags;
>   int ret, i;
>   int operation;
> + struct timeval cur_time;
> 
>   switch (req->operation) {
>   case BLKIF_OP_READ:
> @@ -658,6 +688,7 @@ static void dispatch_rw_block_io(blkif_t
>   else
>   blkif->st_wr_sect += preq.nr_sects;
> 
> + jiffies_to_timeval(jiffies, &cur_time);
>   return;
> 
>   fail_flush:
> diff -NruabBEp xen_blkback_limit.orig/common.h xen_blkback_limit.new//common.h
> --- xen_blkback_limit.orig/common.h 2012-12-04 13:03:58.000000000 +0400
> +++ xen_blkback_limit.new//common.h 2013-01-28 08:09:35.000000000 +0400
> @@ -82,6 +82,11 @@ typedef struct blkif_st {
>   unsigned int        waiting_reqs;
>   struct request_queue *plug;
> 
> + /* qos information */
> + unsigned long   reqtime;
> + int    reqcount;
> + int    reqrate;
> +
>   /* statistics */
>   unsigned long       st_print;
>   int                 st_rd_req;
> @@ -106,6 +111,8 @@ struct backend_info
>   unsigned major;
>   unsigned minor;
>   char *mode;
> + /* qos information */
> + struct xenbus_watch reqrate_watch;
>  };
> 
>  blkif_t *blkif_alloc(domid_t domid);
> diff -NruabBEp xen_blkback_limit.orig/xenbus.c xen_blkback_limit.new//xenbus.c
> --- xen_blkback_limit.orig/xenbus.c 2012-12-04 13:03:58.000000000 +0400
> +++ xen_blkback_limit.new//xenbus.c 2013-01-28 08:22:26.000000000 +0400
> @@ -120,6 +120,79 @@ static void update_blkif_status(blkif_t
>   } \
>   static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
> 
> +static ssize_t
> +show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
> +{
> + ssize_t ret = -ENODEV;
> + struct xenbus_device *dev;
> + struct backend_info *be;
> +
> + if (!get_device(_dev))
> + return ret;
> +
> + dev = to_xenbus_device(_dev);
> + be = dev_get_drvdata(&dev->dev);
> +
> + if (be != NULL)
> + ret = sprintf(buf, "%d\n", be->blkif->reqrate);
> +
> + put_device(_dev);
> +
> + return ret;
> +}
> +
> +static ssize_t
> +store_reqrate(struct device *_dev, struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + int value;
> + struct xenbus_device *dev;
> + struct backend_info *be;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + if (!get_device(_dev))
> + return -ENODEV;
> +
> + if (sscanf(buf, "%d", &value) != 1)
> + return -EINVAL;
> +
> + dev = to_xenbus_device(_dev);
> + be = dev_get_drvdata(&dev->dev);
> +
> + if (be != NULL)
> + be->blkif->reqrate = value;
> +
> + put_device(_dev);
> +
> + return size;
> +}
> +static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
> + store_reqrate);
> +
> +static ssize_t
> +show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
> +{
> + ssize_t ret = -ENODEV;
> + struct xenbus_device *dev;
> + struct backend_info *be;
> +
> + if (!get_device(_dev))
> + return ret;
> +
> + dev = to_xenbus_device(_dev);
> + be = dev_get_drvdata(&dev->dev);
> +
> + if (be != NULL)
> + ret = sprintf(buf, "%d\n", be->blkif->reqcount);
> +
> + put_device(_dev);
> +
> + return ret;
> +}
> +static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
> +
>  VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
>  VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
>  VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
> @@ -146,6 +219,17 @@ static const struct attribute_group vbds
>   .attrs = vbdstat_attrs,
>  };
> 
> +static struct attribute *vbdreq_attrs[] = {
> + &dev_attr_reqrate.attr,
> + &dev_attr_reqcount.attr,
> + NULL
> +};
> +
> +static const struct attribute_group vbdreq_group = {
> + .name = "qos",
> + .attrs = vbdreq_attrs,
> +};
> +
>  VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
>  VBD_SHOW(mode, "%s\n", be->mode);
> 
> @@ -165,8 +249,13 @@ int xenvbd_sysfs_addif(struct xenbus_dev
>   if (error)
>   goto fail3;
> 
> + error = sysfs_create_group(&dev->dev.kobj, &vbdreq_group);
> + if (error)
> + goto fail4;
> +
>   return 0;
> 
> +fail4:  sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>  fail3: sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>  fail2: device_remove_file(&dev->dev, &dev_attr_mode);
>  fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
> @@ -175,6 +264,7 @@ fail1: device_remove_file(&dev->dev, &de
> 
>  void xenvbd_sysfs_delif(struct xenbus_device *dev)
>  {
> + sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>   sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>   device_remove_file(&dev->dev, &dev_attr_mode);
>   device_remove_file(&dev->dev, &dev_attr_physical_device);
> @@ -201,6 +291,12 @@ static int blkback_remove(struct xenbus_
>   be->cdrom_watch.node = NULL;
>   }
> 
> + if (be->reqrate_watch.node) {
> + unregister_xenbus_watch(&be->reqrate_watch);
> + kfree(be->reqrate_watch.node);
> + be->reqrate_watch.node = NULL;
> + }
> +
>   if (be->blkif) {
>   blkif_disconnect(be->blkif);
>   vbd_free(&be->blkif->vbd);
> @@ -338,6 +434,7 @@ static void backend_changed(struct xenbu
>   struct xenbus_device *dev = be->dev;
>   int cdrom = 0;
>   char *device_type;
> + char name[TASK_COMM_LEN];
> 
>   DPRINTK("");
> 
> @@ -376,6 +473,21 @@ static void backend_changed(struct xenbu
>   kfree(device_type);
>   }
> 
> + /* gather information about QoS policy for this device. */
> + err = blkback_name(be->blkif, name);
> + if (err) {
> + xenbus_dev_error(be->dev, err, "get blkback dev name");
> + return;
> + }
> +
> + err = xenbus_gather(XBT_NIL, dev->otherend,
> + "reqrate", "%d", &be->blkif->reqrate,
> + NULL);
> + if (err)
> + DPRINTK("%s xenbus_gather(reqrate) error", name);
> +
> + be->blkif->reqtime = jiffies;
> +
>   if (be->major == 0 && be->minor == 0) {
>   /* Front end dir is a number, which is used as the handle. */
> 
> @@ -482,6 +594,30 @@ static void frontend_changed(struct xenb
> 
>  /* ** Connection ** */
> 
> +static void reqrate_changed(struct xenbus_watch *watch,
> + const char **vec, unsigned int len)
> +{
> + struct backend_info *be = container_of(watch, struct backend_info,
> + reqrate_watch);
> + int err;
> + char name[TASK_COMM_LEN];
> +
> + err = blkback_name(be->blkif, name);
> + if (err) {
> + xenbus_dev_error(be->dev, err, "get blkback dev name");
> + return;
> + }
> +
> + err = xenbus_gather(XBT_NIL, be->dev->otherend,
> + "reqrate",  "%d",
> + &be->blkif->reqrate, NULL);
> + if (err) {
> + DPRINTK("%s xenbus_gather(reqrate) error", name);
> + } else {
> + if (be->blkif->reqrate <= 0)
> + be->blkif->reqrate = 0;
> + }
> +}
> 
>  /**
>   * Write the physical details regarding the block device to the store, and
> @@ -542,6 +678,21 @@ again:
>   xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
>   dev->nodename);
> 
> + if (be->reqrate_watch.node) {
> + unregister_xenbus_watch(&be->reqrate_watch);
> + kfree(be->reqrate_watch.node);
> + be->reqrate_watch.node = NULL;
> + }
> +
> + err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
> + &be->reqrate_watch,
> + reqrate_changed);
> + if (err) {
> + xenbus_dev_fatal(dev, err, "%s: watching reqrate",
> + dev->nodename);
> + goto abort;
> + }
> +
>   return;
>   abort:
>   xenbus_transaction_end(xbt, 1);
> 
> 2013/1/31 Wei Liu <wei.liu2@citrix.com>:
> > On Thu, 2013-01-31 at 05:14 +0000, Vasiliy Tolstov wrote:
> >> Sorry forget to send patch
> >> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
> >> Patch for kernel 3.6.9, but if that needed i can rebase it to current
> >> git Linus tree.
> >
> > Can you inline your patch in your email so that developer can comment on
> > it.
> >
> >
> > Wei.
> >
> 
> 
> 
> -- 
> 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
> 

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:46:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:46: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 1U1Hsz-0004mB-Ik; Fri, 01 Feb 2013 14:46:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>)
	id 1U1Hsy-0004lz-2T; Fri, 01 Feb 2013 14:46:36 +0000
Received: from [85.158.138.51:32437] by server-11.bemta-3.messagelabs.com id
	94/AC-10249-B45DB015; Fri, 01 Feb 2013 14:46:35 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1359729994!30637509!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27242 invoked from network); 1 Feb 2013 14:46:34 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 14:46:34 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U1Hsu-0007KY-EQ; Fri, 01 Feb 2013 15:46:32 +0100
Message-ID: <510BD542.10602@hosteurope.de>
Date: Fri, 01 Feb 2013 15:46:26 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20121026072821.GA9853@intersect>
	<1351237241.8558.9.camel@dagon.hellion.org.uk>
	<20121026121544.GA14662@intersect>
	<1351255054.15162.66.camel@zakaz.uk.xensource.com>
	<20121026170920.GA4835@intersect>
	<1351276218.11876.0.camel@dagon.hellion.org.uk>
	<51015DB8.40107@hosteurope.de>
	<1359105618.32057.58.camel@zakaz.uk.xensource.com>
	<51028DDE.9070907@citrix.com> <510680E6.6050406@hosteurope.de>
	<1359381541.12252.0.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359381541.12252.0.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [Xen-users] Problemi using vif-route 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: multipart/mixed; boundary="===============7178661660568737543=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============7178661660568737543==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2SXNRDBCVDEFVEEKURTHK"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2SXNRDBCVDEFVEEKURTHK
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 28.01.2013 14:59, Ian Campbell wrote:
> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote:
>> The mac address is not parsed correctly if not padded with leading
>> zeros (and no error reported, though):=20
>=20
> Ick, well spotted. It is a bug in xl that it doesn't Do The Right Thing=

> here, even if stripping the leading zeroes is somewhat unconventional
> IMHO.
>=20
> Ian.

How shall I proceed here? Shall I open a bug report or did some of you
already open one?

Thanks and regards,
Ulf


------enig2SXNRDBCVDEFVEEKURTHK
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEL1UgACgkQhHSVerqjg04j2wCfVEiYbgBMkSA30WSAJe6rJ2u2
xJ0AnjdrKMwY0LWMJSTPyAgDAjJdye3b
=C/MT
-----END PGP SIGNATURE-----

------enig2SXNRDBCVDEFVEEKURTHK--


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

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

--===============7178661660568737543==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 14:46:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:46: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 1U1Hsz-0004mB-Ik; Fri, 01 Feb 2013 14:46:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>)
	id 1U1Hsy-0004lz-2T; Fri, 01 Feb 2013 14:46:36 +0000
Received: from [85.158.138.51:32437] by server-11.bemta-3.messagelabs.com id
	94/AC-10249-B45DB015; Fri, 01 Feb 2013 14:46:35 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1359729994!30637509!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27242 invoked from network); 1 Feb 2013 14:46:34 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 14:46:34 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U1Hsu-0007KY-EQ; Fri, 01 Feb 2013 15:46:32 +0100
Message-ID: <510BD542.10602@hosteurope.de>
Date: Fri, 01 Feb 2013 15:46:26 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20121026072821.GA9853@intersect>
	<1351237241.8558.9.camel@dagon.hellion.org.uk>
	<20121026121544.GA14662@intersect>
	<1351255054.15162.66.camel@zakaz.uk.xensource.com>
	<20121026170920.GA4835@intersect>
	<1351276218.11876.0.camel@dagon.hellion.org.uk>
	<51015DB8.40107@hosteurope.de>
	<1359105618.32057.58.camel@zakaz.uk.xensource.com>
	<51028DDE.9070907@citrix.com> <510680E6.6050406@hosteurope.de>
	<1359381541.12252.0.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359381541.12252.0.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [Xen-users] Problemi using vif-route 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: multipart/mixed; boundary="===============7178661660568737543=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============7178661660568737543==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2SXNRDBCVDEFVEEKURTHK"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2SXNRDBCVDEFVEEKURTHK
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 28.01.2013 14:59, Ian Campbell wrote:
> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote:
>> The mac address is not parsed correctly if not padded with leading
>> zeros (and no error reported, though):=20
>=20
> Ick, well spotted. It is a bug in xl that it doesn't Do The Right Thing=

> here, even if stripping the leading zeroes is somewhat unconventional
> IMHO.
>=20
> Ian.

How shall I proceed here? Shall I open a bug report or did some of you
already open one?

Thanks and regards,
Ulf


------enig2SXNRDBCVDEFVEEKURTHK
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEL1UgACgkQhHSVerqjg04j2wCfVEiYbgBMkSA30WSAJe6rJ2u2
xJ0AnjdrKMwY0LWMJSTPyAgDAjJdye3b
=C/MT
-----END PGP SIGNATURE-----

------enig2SXNRDBCVDEFVEEKURTHK--


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

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

--===============7178661660568737543==--


From xen-devel-bounces@lists.xen.org Fri Feb 01 14:46:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14: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 1U1Ht9-0004nE-4h; Fri, 01 Feb 2013 14:46:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U1Ht7-0004mv-Ne
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:46:45 +0000
Received: from [85.158.139.83:59656] by server-15.bemta-5.messagelabs.com id
	2C/3D-18914-555DB015; Fri, 01 Feb 2013 14:46:45 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1359730003!19166669!1
X-Originating-IP: [209.85.128.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24847 invoked from network); 1 Feb 2013 14:46:44 -0000
Received: from mail-ve0-f181.google.com (HELO mail-ve0-f181.google.com)
	(209.85.128.181)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:46:44 -0000
Received: by mail-ve0-f181.google.com with SMTP id d10so2964178vea.40
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 06:46:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=ObKQwVAb4HYLECxlcq63MaOQj8ynF93YIUGsV5VaULA=;
	b=fAhGJW4onNN2TYuUm0zXf9WE12KQEov8pkWTNr/rLzVRS44pH5M5S/C0rbBGwrqBP3
	WpaA1sttDsVJv7s4ENZVVNGpUHjnajECXk5prWd366BJSFEUADPCm3L/pH4JQQiwh46f
	Ke2bpzI8gFlpQk+P6CeEd48bCaOh5ZHJCFKdR2bwNf8qFo3qI0whAMHKGPi20RSsRA9B
	+osophp3P+vOagX/2l0fc03gLDKjD8gysNHaE23a/apkTeueG3IFzPoHUYj7HhtFNFBp
	/OeGGitrnSmdeN+7V3DFcpvshpWtx8LqoOZ0UWIW5zkIvOCQl48GqvXKziT6H0G3lAiV
	vwDw==
X-Received: by 10.58.145.106 with SMTP id st10mr7379757veb.39.1359730003075;
	Fri, 01 Feb 2013 06:46:43 -0800 (PST)
Received: from konrad-lan.dumpdata.com (ip-64-134-67-155.public.wayport.net.
	[64.134.67.155])
	by mx.google.com with ESMTPS id l18sm8208267vdh.10.2013.02.01.06.46.42
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 06:46:42 -0800 (PST)
Date: Fri, 1 Feb 2013 09:46:40 -0500
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Message-ID: <20130201144639.GC7461@konrad-lan.dumpdata.com>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > because is easier to have a zero cost if you disable coverage
> > > > informations. The best thing would be redirect do_coverage_op to
> > > > do_ni_hypercall using linker options but even two small stub would do
> > > > (these stubs will return ENOSYS instead).
> > > 
> > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > the hypercall path you are introducing? What is the zero cost?
> > 
> > I don't think we care a jot about the performance of this system call
> > when coverage is disabled, it's certainly not a hot path and in any case
> > if it is a NOP it doesn't really matter anyway.
> > 
> > Ian.
> > 
> 
> It's not about the speed, it's about the bytes introduced in Xen binary.

Not sure I follow. What bytes? Just that the code size is bigger b/c it
will go through the sysctl functions? How many bytes of extra code are
talking here? 

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:46:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14: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 1U1Ht9-0004nE-4h; Fri, 01 Feb 2013 14:46:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U1Ht7-0004mv-Ne
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:46:45 +0000
Received: from [85.158.139.83:59656] by server-15.bemta-5.messagelabs.com id
	2C/3D-18914-555DB015; Fri, 01 Feb 2013 14:46:45 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1359730003!19166669!1
X-Originating-IP: [209.85.128.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24847 invoked from network); 1 Feb 2013 14:46:44 -0000
Received: from mail-ve0-f181.google.com (HELO mail-ve0-f181.google.com)
	(209.85.128.181)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 14:46:44 -0000
Received: by mail-ve0-f181.google.com with SMTP id d10so2964178vea.40
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 06:46:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=ObKQwVAb4HYLECxlcq63MaOQj8ynF93YIUGsV5VaULA=;
	b=fAhGJW4onNN2TYuUm0zXf9WE12KQEov8pkWTNr/rLzVRS44pH5M5S/C0rbBGwrqBP3
	WpaA1sttDsVJv7s4ENZVVNGpUHjnajECXk5prWd366BJSFEUADPCm3L/pH4JQQiwh46f
	Ke2bpzI8gFlpQk+P6CeEd48bCaOh5ZHJCFKdR2bwNf8qFo3qI0whAMHKGPi20RSsRA9B
	+osophp3P+vOagX/2l0fc03gLDKjD8gysNHaE23a/apkTeueG3IFzPoHUYj7HhtFNFBp
	/OeGGitrnSmdeN+7V3DFcpvshpWtx8LqoOZ0UWIW5zkIvOCQl48GqvXKziT6H0G3lAiV
	vwDw==
X-Received: by 10.58.145.106 with SMTP id st10mr7379757veb.39.1359730003075;
	Fri, 01 Feb 2013 06:46:43 -0800 (PST)
Received: from konrad-lan.dumpdata.com (ip-64-134-67-155.public.wayport.net.
	[64.134.67.155])
	by mx.google.com with ESMTPS id l18sm8208267vdh.10.2013.02.01.06.46.42
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 06:46:42 -0800 (PST)
Date: Fri, 1 Feb 2013 09:46:40 -0500
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Message-ID: <20130201144639.GC7461@konrad-lan.dumpdata.com>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > because is easier to have a zero cost if you disable coverage
> > > > informations. The best thing would be redirect do_coverage_op to
> > > > do_ni_hypercall using linker options but even two small stub would do
> > > > (these stubs will return ENOSYS instead).
> > > 
> > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > the hypercall path you are introducing? What is the zero cost?
> > 
> > I don't think we care a jot about the performance of this system call
> > when coverage is disabled, it's certainly not a hot path and in any case
> > if it is a NOP it doesn't really matter anyway.
> > 
> > Ian.
> > 
> 
> It's not about the speed, it's about the bytes introduced in Xen binary.

Not sure I follow. What bytes? Just that the code size is bigger b/c it
will go through the sysctl functions? How many bytes of extra code are
talking here? 

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:51:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 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 1U1HxG-0005GY-Eq; Fri, 01 Feb 2013 14:51:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1HxE-0005FK-73
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:51:00 +0000
Received: from [85.158.143.35:55935] by server-1.bemta-4.messagelabs.com id
	FC/90-08839-356DB015; Fri, 01 Feb 2013 14:50:59 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359730232!5250227!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17030 invoked from network); 1 Feb 2013 14:50:33 -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;
	1 Feb 2013 14:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5665777"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwk-0002au-SS;
	Fri, 01 Feb 2013 14:50:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:19 +0000
Message-ID: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC PATCH] Coverage 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

Updated set of patches for coverage.
Changes:
- implemented way of getting information
- use only 2 parameter in hypercall (still not sure it's better to use
  sysctl)
- use "coverage" for configuration option as suggested by Ian Campbell
- split header in include/public/gcov.h and include/xen/gcov.h to allow
  tools to include public header
- use weak to avoid defining compat_coverage_op

I manage to write 2 tools, one that call the new hypercall and dump the
blob in a file, one that split this file into required .gcda files. 
Both very hack ones and dirty but works and prove the hypervisor code is 
fine. Should I just send them anyway?

The forth patch allow to consume just 0 bytes if coverage is disabled.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:51:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 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 1U1HxG-0005GY-Eq; Fri, 01 Feb 2013 14:51:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1HxE-0005FK-73
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:51:00 +0000
Received: from [85.158.143.35:55935] by server-1.bemta-4.messagelabs.com id
	FC/90-08839-356DB015; Fri, 01 Feb 2013 14:50:59 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359730232!5250227!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17030 invoked from network); 1 Feb 2013 14:50:33 -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;
	1 Feb 2013 14:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5665777"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwk-0002au-SS;
	Fri, 01 Feb 2013 14:50:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:19 +0000
Message-ID: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC PATCH] Coverage 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

Updated set of patches for coverage.
Changes:
- implemented way of getting information
- use only 2 parameter in hypercall (still not sure it's better to use
  sysctl)
- use "coverage" for configuration option as suggested by Ian Campbell
- split header in include/public/gcov.h and include/xen/gcov.h to allow
  tools to include public header
- use weak to avoid defining compat_coverage_op

I manage to write 2 tools, one that call the new hypercall and dump the
blob in a file, one that split this file into required .gcda files. 
Both very hack ones and dirty but works and prove the hypervisor code is 
fine. Should I just send them anyway?

The forth patch allow to consume just 0 bytes if coverage is disabled.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 14:51:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:51: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 1U1HxE-0005Fz-Fw; Fri, 01 Feb 2013 14:51:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1HxC-0005Ey-V8
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:50:59 +0000
Received: from [85.158.143.35:55861] by server-2.bemta-4.messagelabs.com id
	2B/A0-01597-256DB015; Fri, 01 Feb 2013 14:50:58 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359730232!5250227!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17226 invoked from network); 1 Feb 2013 14:50:36 -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;
	1 Feb 2013 14:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5665778"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwk-0002au-UI;
	Fri, 01 Feb 2013 14:50:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:20 +0000
Message-ID: <1359730103-9474-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Reserve hypercall number for handling
	coverage informations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/include/public/xen.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..feec70e 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -101,6 +101,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
 #define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
+#define __HYPERVISOR_coverage             40 /* reserved to get coverage information */
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
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 Fri Feb 01 14:51:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:51: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 1U1HxE-0005Fz-Fw; Fri, 01 Feb 2013 14:51:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1HxC-0005Ey-V8
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:50:59 +0000
Received: from [85.158.143.35:55861] by server-2.bemta-4.messagelabs.com id
	2B/A0-01597-256DB015; Fri, 01 Feb 2013 14:50:58 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359730232!5250227!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17226 invoked from network); 1 Feb 2013 14:50:36 -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;
	1 Feb 2013 14:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5665778"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwk-0002au-UI;
	Fri, 01 Feb 2013 14:50:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:20 +0000
Message-ID: <1359730103-9474-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Reserve hypercall number for handling
	coverage informations.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/include/public/xen.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..feec70e 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -101,6 +101,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
 #define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient */
+#define __HYPERVISOR_coverage             40 /* reserved to get coverage information */
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
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 Fri Feb 01 14:52:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:52: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 1U1HyK-0005SY-V9; Fri, 01 Feb 2013 14:52:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1HyJ-0005S9-F3
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:52:07 +0000
Received: from [193.109.254.147:17921] by server-4.bemta-14.messagelabs.com id
	44/09-20719-696DB015; Fri, 01 Feb 2013 14:52:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1359730235!3378320!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9526 invoked from network); 1 Feb 2013 14:50:36 -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;
	1 Feb 2013 14:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5665779"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:31 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwl-0002au-0h;
	Fri, 01 Feb 2013 14:50:31 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:23 +0000
Message-ID: <1359730103-9474-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Use weak symbol to avoid bad trick in
	Makefiles
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Define do_coverage_op to point to do_ni_hypercall as weak symbol.
This allow the linked to redirect coverage operations to void function if
coverage are not enabled.
This save some space and compression bytes if coverage is disabled.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/Makefile        |    2 +-
 xen/common/compat/kernel.c |    1 +
 xen/common/gcov/Makefile   |    5 +----
 xen/common/gcov/nogcov.c   |   22 ----------------------
 xen/common/kernel.c        |    4 ++++
 5 files changed, 7 insertions(+), 27 deletions(-)
 delete mode 100644 xen/common/gcov/nogcov.c

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 51191d6..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,7 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
-subdir-y += gcov
+subdir-$(coverage) += gcov
 
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/compat/kernel.c b/xen/common/compat/kernel.c
index a2a2751..564c2a1 100644
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -42,6 +42,7 @@ CHECK_TYPE(domain_handle);
 #define xennmi_callback_t compat_nmi_callback_t
 
 #define DO(fn) int compat_##fn
+#define NAME(fn) "compat_" #fn
 #define COMPAT
 
 #include "../kernel.c"
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index 43a692c..c9efe6c 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -1,5 +1,2 @@
-ifneq ($(coverage),y)
-obj-y += nogcov.o
-endif
-obj-$(coverage) += gcov.o
+obj-y += gcov.o
 
diff --git a/xen/common/gcov/nogcov.c b/xen/common/gcov/nogcov.c
deleted file mode 100644
index 9642c96..0000000
--- a/xen/common/gcov/nogcov.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * nogov.c
- *
- * Compiled if coverage information are not enabled
- */
-
-#include <xen/config.h>
-#include <xen/lib.h>
-#include <xen/errno.h>
-#include <public/xen.h>
-
-long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
-{
-    return -ENOSYS;
-}
-
-#ifdef CONFIG_COMPAT
-int compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
-    __attribute__ ((alias ("do_coverage_op")));
-#endif
-
-
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 55caff6..25ba667 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -197,6 +197,7 @@ void __init do_initcalls(void)
 }
 
 # define DO(fn) long do_##fn
+# define NAME(fn) "do_" #fn
 
 #endif
 
@@ -367,6 +368,9 @@ DO(ni_hypercall)(void)
     return -ENOSYS;
 }
 
+DO(coverage_op)(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+    __attribute__ ((weak, alias(NAME(ni_hypercall))));
+
 /*
  * Local variables:
  * mode: C
-- 
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 Fri Feb 01 14:52:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:52: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 1U1HyK-0005SY-V9; Fri, 01 Feb 2013 14:52:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1HyJ-0005S9-F3
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:52:07 +0000
Received: from [193.109.254.147:17921] by server-4.bemta-14.messagelabs.com id
	44/09-20719-696DB015; Fri, 01 Feb 2013 14:52:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1359730235!3378320!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9526 invoked from network); 1 Feb 2013 14:50:36 -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;
	1 Feb 2013 14:50:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5665779"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:31 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwl-0002au-0h;
	Fri, 01 Feb 2013 14:50:31 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:23 +0000
Message-ID: <1359730103-9474-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Use weak symbol to avoid bad trick in
	Makefiles
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Define do_coverage_op to point to do_ni_hypercall as weak symbol.
This allow the linked to redirect coverage operations to void function if
coverage are not enabled.
This save some space and compression bytes if coverage is disabled.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/Makefile        |    2 +-
 xen/common/compat/kernel.c |    1 +
 xen/common/gcov/Makefile   |    5 +----
 xen/common/gcov/nogcov.c   |   22 ----------------------
 xen/common/kernel.c        |    4 ++++
 5 files changed, 7 insertions(+), 27 deletions(-)
 delete mode 100644 xen/common/gcov/nogcov.c

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 51191d6..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,7 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
-subdir-y += gcov
+subdir-$(coverage) += gcov
 
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/compat/kernel.c b/xen/common/compat/kernel.c
index a2a2751..564c2a1 100644
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -42,6 +42,7 @@ CHECK_TYPE(domain_handle);
 #define xennmi_callback_t compat_nmi_callback_t
 
 #define DO(fn) int compat_##fn
+#define NAME(fn) "compat_" #fn
 #define COMPAT
 
 #include "../kernel.c"
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index 43a692c..c9efe6c 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -1,5 +1,2 @@
-ifneq ($(coverage),y)
-obj-y += nogcov.o
-endif
-obj-$(coverage) += gcov.o
+obj-y += gcov.o
 
diff --git a/xen/common/gcov/nogcov.c b/xen/common/gcov/nogcov.c
deleted file mode 100644
index 9642c96..0000000
--- a/xen/common/gcov/nogcov.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * nogov.c
- *
- * Compiled if coverage information are not enabled
- */
-
-#include <xen/config.h>
-#include <xen/lib.h>
-#include <xen/errno.h>
-#include <public/xen.h>
-
-long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
-{
-    return -ENOSYS;
-}
-
-#ifdef CONFIG_COMPAT
-int compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
-    __attribute__ ((alias ("do_coverage_op")));
-#endif
-
-
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 55caff6..25ba667 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -197,6 +197,7 @@ void __init do_initcalls(void)
 }
 
 # define DO(fn) long do_##fn
+# define NAME(fn) "do_" #fn
 
 #endif
 
@@ -367,6 +368,9 @@ DO(ni_hypercall)(void)
     return -ENOSYS;
 }
 
+DO(coverage_op)(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+    __attribute__ ((weak, alias(NAME(ni_hypercall))));
+
 /*
  * Local variables:
  * mode: C
-- 
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 Fri Feb 01 14:58:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:58: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 1U1I3s-0005sL-28; Fri, 01 Feb 2013 14:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1I3r-0005sG-5l
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:57:51 +0000
Received: from [85.158.143.35:32671] by server-1.bemta-4.messagelabs.com id
	DD/F8-08839-EE7DB015; Fri, 01 Feb 2013 14:57:50 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359730232!10158245!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14721 invoked from network); 1 Feb 2013 14:50:34 -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;
	1 Feb 2013 14:50:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5959537"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwl-0002au-0E;
	Fri, 01 Feb 2013 14:50:31 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:22 +0000
Message-ID: <1359730103-9474-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

Check does not check for any permission while other operations require a
privileged domain. This cause these statistics can lead to security
problems.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c    |  157 +++++++++++++++++++++++++++++++++++++++++++--
 xen/include/public/gcov.h |   24 +++++++
 2 files changed, 177 insertions(+), 4 deletions(-)

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index e208596..d5d74d0 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,10 +19,10 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <public/xen.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -37,7 +37,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -78,15 +77,165 @@ void init_coverage(void)
         __CTOR_LIST__.funcs[n]();
 
 #ifndef NDEBUG
-    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
     if ( info_list )
         printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
 #endif
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8_t) ptr;
+    int real;
+    unsigned write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset =
+        (iter->write_offset + data_len + (sizeof(uint32_t) - 1)) &
+        -sizeof(uint32_t);
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < GCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        chk(write32(iter, GCOV_DATA_MAGIC));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < GCOV_COUNTERS; ++ctr )
+        {
+            chk(write32(iter, GCOV_TAG_FOR_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        chk(write32(iter, GCOV_TAG_FUNCTION));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    chk(write32(iter, 0));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < GCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
 long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
-    return -EINVAL;
+    long ret = -EINVAL;
+    uint32_t len;
+    write_iter_t iter;
+
+    /*
+     * just return success to check for coverage support,
+     * no permission check
+     */
+    if ( op == XEN_COVERAGE_enabled )
+        return 0;
+
+    /*
+     * all other information although statistical one
+     * are too accurate and could lead to security issues
+     */
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    switch ( op )
+    {
+    case XEN_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        len = iter.write_offset;
+        ret = copy_to_guest(uarg, &len, 1) ? -EFAULT : 0;
+        break;
+
+    case XEN_COVERAGE_read:
+        iter.ptr = guest_handle_cast(uarg, uint8_t);
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+    }
+    return ret;
 }
 
 #ifdef CONFIG_COMPAT
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
index 67aedf6..a2863f7 100644
--- a/xen/include/public/gcov.h
+++ b/xen/include/public/gcov.h
@@ -90,4 +90,28 @@ struct gcov_info
     struct gcov_ctr_info      counts[0];
 };
 
+
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ */
+#define XEN_COVERAGE_reset          3
+
 #endif /* XEN_PUBLIC_GCOV_H */
-- 
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 Fri Feb 01 14:58:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:58: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 1U1I3s-0005sL-28; Fri, 01 Feb 2013 14:57:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1I3r-0005sG-5l
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:57:51 +0000
Received: from [85.158.143.35:32671] by server-1.bemta-4.messagelabs.com id
	DD/F8-08839-EE7DB015; Fri, 01 Feb 2013 14:57:50 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359730232!10158245!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14721 invoked from network); 1 Feb 2013 14:50:34 -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;
	1 Feb 2013 14:50:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5959537"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwl-0002au-0E;
	Fri, 01 Feb 2013 14:50:31 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:22 +0000
Message-ID: <1359730103-9474-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

Check does not check for any permission while other operations require a
privileged domain. This cause these statistics can lead to security
problems.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c    |  157 +++++++++++++++++++++++++++++++++++++++++++--
 xen/include/public/gcov.h |   24 +++++++
 2 files changed, 177 insertions(+), 4 deletions(-)

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index e208596..d5d74d0 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,10 +19,10 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
 #include <public/xen.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -37,7 +37,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -78,15 +77,165 @@ void init_coverage(void)
         __CTOR_LIST__.funcs[n]();
 
 #ifndef NDEBUG
-    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
     if ( info_list )
         printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
 #endif
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8_t) ptr;
+    int real;
+    unsigned write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset =
+        (iter->write_offset + data_len + (sizeof(uint32_t) - 1)) &
+        -sizeof(uint32_t);
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < GCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        chk(write32(iter, GCOV_DATA_MAGIC));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < GCOV_COUNTERS; ++ctr )
+        {
+            chk(write32(iter, GCOV_TAG_FOR_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        chk(write32(iter, GCOV_TAG_FUNCTION));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    chk(write32(iter, 0));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < GCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
 long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
-    return -EINVAL;
+    long ret = -EINVAL;
+    uint32_t len;
+    write_iter_t iter;
+
+    /*
+     * just return success to check for coverage support,
+     * no permission check
+     */
+    if ( op == XEN_COVERAGE_enabled )
+        return 0;
+
+    /*
+     * all other information although statistical one
+     * are too accurate and could lead to security issues
+     */
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    switch ( op )
+    {
+    case XEN_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        len = iter.write_offset;
+        ret = copy_to_guest(uarg, &len, 1) ? -EFAULT : 0;
+        break;
+
+    case XEN_COVERAGE_read:
+        iter.ptr = guest_handle_cast(uarg, uint8_t);
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+    }
+    return ret;
 }
 
 #ifdef CONFIG_COMPAT
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
index 67aedf6..a2863f7 100644
--- a/xen/include/public/gcov.h
+++ b/xen/include/public/gcov.h
@@ -90,4 +90,28 @@ struct gcov_info
     struct gcov_ctr_info      counts[0];
 };
 
+
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ */
+#define XEN_COVERAGE_reset          3
+
 #endif /* XEN_PUBLIC_GCOV_H */
-- 
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 Fri Feb 01 14:58:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:58: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 1U1I3y-0005sm-FP; Fri, 01 Feb 2013 14:57:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1I3x-0005sc-1e
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:57:57 +0000
Received: from [85.158.143.35:32897] by server-2.bemta-4.messagelabs.com id
	44/39-01597-4F7DB015; Fri, 01 Feb 2013 14:57:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359730232!10158245!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14788 invoked from network); 1 Feb 2013 14:50:35 -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;
	1 Feb 2013 14:50:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5959538"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwk-0002au-W0;
	Fri, 01 Feb 2013 14:50:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:21 +0000
Message-ID: <1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

The op parameter in the hypercall will be the operation.
The uarg parameter is a pointer (used to read size or data).

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore                         |    2 +
 Config.mk                          |    4 ++
 xen/Rules.mk                       |    5 ++
 xen/arch/x86/setup.c               |    3 ++
 xen/arch/x86/x86_64/compat/entry.S |    4 ++
 xen/arch/x86/x86_64/entry.S        |    4 ++
 xen/arch/x86/xen.lds.S             |    7 +++
 xen/common/Makefile                |    2 +
 xen/common/gcov/Makefile           |    5 ++
 xen/common/gcov/gcov.c             |  105 ++++++++++++++++++++++++++++++++++++
 xen/common/gcov/nogcov.c           |   22 ++++++++
 xen/include/public/gcov.h          |   93 ++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h             |   32 +++++++++++
 xen/include/xen/hypercall.h        |    6 +++
 14 files changed, 294 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/common/gcov/nogcov.c
 create mode 100644 xen/include/public/gcov.h
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/Config.mk b/Config.mk
index 64541c8..a49b7c9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -228,3 +228,7 @@ QEMU_TAG ?= 2a1354d655d816feaad7dbdb8364f40a208439c1
 # doing and are prepared for some pain.
 
 CONFIG_TESTS       ?= y
+
+# Test coverage support
+coverage ?= n
+
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..c9044f5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+
+ifeq ($(coverage),y)
+$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+endif
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..ddf5c4d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -46,6 +46,7 @@
 #include <asm/setup.h>
 #include <xen/cpu.h>
 #include <asm/nmi.h>
+#include <xen/gcov.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
@@ -1313,6 +1314,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_coverage();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 7051f90..ebbb6b7 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -413,6 +413,8 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad compat_ni_hypercall
+        .quad compat_coverage_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -461,6 +463,8 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 0 /* compat_ni_hypercall      */
+        .byte 2 /* compat_coverage_op       */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 408c348..670a2e6 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -738,6 +738,8 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_ni_hypercall
+        .quad do_coverage_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -786,6 +788,8 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 0 /* do_ni_hypercall      */
+        .byte 2 /* do_coverage_op       */
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..51191d6 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-y += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..43a692c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,5 @@
+ifneq ($(coverage),y)
+obj-y += nogcov.o
+endif
+obj-$(coverage) += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..e208596
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,105 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+#include <public/xen.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+typedef void (*ctor_func_t)(void);
+extern struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void init_coverage(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+
+#ifndef NDEBUG
+    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
+    if ( info_list )
+        printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
+#endif
+}
+
+long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    return -EINVAL;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+    __attribute__ ((alias ("do_coverage_op")));
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/gcov/nogcov.c b/xen/common/gcov/nogcov.c
new file mode 100644
index 0000000..9642c96
--- /dev/null
+++ b/xen/common/gcov/nogcov.c
@@ -0,0 +1,22 @@
+/*
+ * nogov.c
+ *
+ * Compiled if coverage information are not enabled
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/xen.h>
+
+long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    return -ENOSYS;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+    __attribute__ ((alias ("do_coverage_op")));
+#endif
+
+
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..67aedf6
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,93 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef XEN_PUBLIC_GCOV_H
+#define XEN_PUBLIC_GCOV_H XEN_PUBLIC_GCOV_H
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+#define GCOV_COUNTERS         5
+#define GCOV_DATA_MAGIC       ((unsigned int) 0x67636461)
+#define GCOV_TAG_FUNCTION     ((unsigned int) 0x01000000)
+#define GCOV_TAG_COUNTER_BASE ((unsigned int) 0x01a10000)
+#define GCOV_TAG_FOR_COUNTER(count) \
+    (GCOV_TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
+
+#if BITS_PER_LONG >= 64
+typedef long gcov_type;
+#else
+typedef long long gcov_type;
+#endif
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+#endif /* XEN_PUBLIC_GCOV_H */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..517ed75
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,32 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef XEN_GCOV_H
+#define XEN_GCOV_H XEN_GCOV_H
+
+#include <public/gcov.h>
+
+/**
+ * Initialize coverage informations
+ * Currently create a linked list of all files compiled in with
+ * coverage informations.
+ */
+#ifdef TEST_COVERAGE
+void __init init_coverage(void);
+#else
+static inline void init_coverage(void)
+{
+}
+#endif
+
+#endif /* GCOV_H */
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 7c3d719..e62525a 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -140,6 +140,9 @@ do_tmem_op(
 extern long
 do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
+extern long
+do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg);
+
 #ifdef CONFIG_COMPAT
 
 extern int
@@ -163,6 +166,9 @@ extern int
 compat_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
+compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg);
+
+extern int
 compat_xen_version(
     int cmd,
     XEN_GUEST_HANDLE_PARAM(void) arg);
-- 
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 Fri Feb 01 14:58:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 14:58: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 1U1I3y-0005sm-FP; Fri, 01 Feb 2013 14:57:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1I3x-0005sc-1e
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 14:57:57 +0000
Received: from [85.158.143.35:32897] by server-2.bemta-4.messagelabs.com id
	44/39-01597-4F7DB015; Fri, 01 Feb 2013 14:57:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359730232!10158245!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14788 invoked from network); 1 Feb 2013 14:50:35 -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;
	1 Feb 2013 14:50:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5959538"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 14:50:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 09:50:30 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U1Hwk-0002au-W0;
	Fri, 01 Feb 2013 14:50:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: <frediano.ziglio@citrix.com>, Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 1 Feb 2013 14:48:21 +0000
Message-ID: <1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

The op parameter in the hypercall will be the operation.
The uarg parameter is a pointer (used to read size or data).

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore                         |    2 +
 Config.mk                          |    4 ++
 xen/Rules.mk                       |    5 ++
 xen/arch/x86/setup.c               |    3 ++
 xen/arch/x86/x86_64/compat/entry.S |    4 ++
 xen/arch/x86/x86_64/entry.S        |    4 ++
 xen/arch/x86/xen.lds.S             |    7 +++
 xen/common/Makefile                |    2 +
 xen/common/gcov/Makefile           |    5 ++
 xen/common/gcov/gcov.c             |  105 ++++++++++++++++++++++++++++++++++++
 xen/common/gcov/nogcov.c           |   22 ++++++++
 xen/include/public/gcov.h          |   93 ++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h             |   32 +++++++++++
 xen/include/xen/hypercall.h        |    6 +++
 14 files changed, 294 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/common/gcov/nogcov.c
 create mode 100644 xen/include/public/gcov.h
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/Config.mk b/Config.mk
index 64541c8..a49b7c9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -228,3 +228,7 @@ QEMU_TAG ?= 2a1354d655d816feaad7dbdb8364f40a208439c1
 # doing and are prepared for some pain.
 
 CONFIG_TESTS       ?= y
+
+# Test coverage support
+coverage ?= n
+
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..c9044f5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+
+ifeq ($(coverage),y)
+$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+endif
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..ddf5c4d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -46,6 +46,7 @@
 #include <asm/setup.h>
 #include <xen/cpu.h>
 #include <asm/nmi.h>
+#include <xen/gcov.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
@@ -1313,6 +1314,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_coverage();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 7051f90..ebbb6b7 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -413,6 +413,8 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad compat_ni_hypercall
+        .quad compat_coverage_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -461,6 +463,8 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 0 /* compat_ni_hypercall      */
+        .byte 2 /* compat_coverage_op       */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 408c348..670a2e6 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -738,6 +738,8 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_ni_hypercall
+        .quad do_coverage_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -786,6 +788,8 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 0 /* do_ni_hypercall      */
+        .byte 2 /* do_coverage_op       */
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..51191d6 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-y += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..43a692c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,5 @@
+ifneq ($(coverage),y)
+obj-y += nogcov.o
+endif
+obj-$(coverage) += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..e208596
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,105 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+#include <public/xen.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+typedef void (*ctor_func_t)(void);
+extern struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void init_coverage(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+
+#ifndef NDEBUG
+    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
+    if ( info_list )
+        printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
+#endif
+}
+
+long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    return -EINVAL;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+    __attribute__ ((alias ("do_coverage_op")));
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/gcov/nogcov.c b/xen/common/gcov/nogcov.c
new file mode 100644
index 0000000..9642c96
--- /dev/null
+++ b/xen/common/gcov/nogcov.c
@@ -0,0 +1,22 @@
+/*
+ * nogov.c
+ *
+ * Compiled if coverage information are not enabled
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/xen.h>
+
+long do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    return -ENOSYS;
+}
+
+#ifdef CONFIG_COMPAT
+int compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+    __attribute__ ((alias ("do_coverage_op")));
+#endif
+
+
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..67aedf6
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,93 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef XEN_PUBLIC_GCOV_H
+#define XEN_PUBLIC_GCOV_H XEN_PUBLIC_GCOV_H
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+#define GCOV_COUNTERS         5
+#define GCOV_DATA_MAGIC       ((unsigned int) 0x67636461)
+#define GCOV_TAG_FUNCTION     ((unsigned int) 0x01000000)
+#define GCOV_TAG_COUNTER_BASE ((unsigned int) 0x01a10000)
+#define GCOV_TAG_FOR_COUNTER(count) \
+    (GCOV_TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
+
+#if BITS_PER_LONG >= 64
+typedef long gcov_type;
+#else
+typedef long long gcov_type;
+#endif
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+#endif /* XEN_PUBLIC_GCOV_H */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..517ed75
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,32 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef XEN_GCOV_H
+#define XEN_GCOV_H XEN_GCOV_H
+
+#include <public/gcov.h>
+
+/**
+ * Initialize coverage informations
+ * Currently create a linked list of all files compiled in with
+ * coverage informations.
+ */
+#ifdef TEST_COVERAGE
+void __init init_coverage(void);
+#else
+static inline void init_coverage(void)
+{
+}
+#endif
+
+#endif /* GCOV_H */
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 7c3d719..e62525a 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -140,6 +140,9 @@ do_tmem_op(
 extern long
 do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
+extern long
+do_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg);
+
 #ifdef CONFIG_COMPAT
 
 extern int
@@ -163,6 +166,9 @@ extern int
 compat_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
+compat_coverage_op(int op, XEN_GUEST_HANDLE_PARAM(void) uarg);
+
+extern int
 compat_xen_version(
     int cmd,
     XEN_GUEST_HANDLE_PARAM(void) arg);
-- 
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 Fri Feb 01 15:05:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 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 1U1IBO-0006Hj-HK; Fri, 01 Feb 2013 15:05:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1IBM-0006He-O0
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 15:05:36 +0000
Received: from [85.158.138.51:63813] by server-14.bemta-3.messagelabs.com id
	FB/C0-23533-6B9DB015; Fri, 01 Feb 2013 15:05:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1359731124!30582166!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1435 invoked from network); 1 Feb 2013 15:05:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 15:05:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1072230"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 15:05:24 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 1 Feb 2013
	15:05:24 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "konrad@kernel.org" <konrad@kernel.org>
Date: Fri, 1 Feb 2013 15:05:23 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Adding support for coverage informations
Thread-Index: Ac4AjY+TaOzxby62Qa2yHbno+mH5Tg==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458352@LONPMAILBOX01.citrite.net>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
	<20130201144639.GC7461@konrad-lan.dumpdata.com>
In-Reply-To: <20130201144639.GC7461@konrad-lan.dumpdata.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: George Dunlap <George.Dunlap@eu.citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 09:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> > On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > > because is easier to have a zero cost if you disable coverage
> > > > > informations. The best thing would be redirect do_coverage_op to
> > > > > do_ni_hypercall using linker options but even two small stub would do
> > > > > (these stubs will return ENOSYS instead).
> > > > 
> > > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > > the hypercall path you are introducing? What is the zero cost?
> > > 
> > > I don't think we care a jot about the performance of this system call
> > > when coverage is disabled, it's certainly not a hot path and in any case
> > > if it is a NOP it doesn't really matter anyway.
> > > 
> > > Ian.
> > > 
> > 
> > It's not about the speed, it's about the bytes introduced in Xen binary.
> 
> Not sure I follow. What bytes? Just that the code size is bigger b/c it
> will go through the sysctl functions? How many bytes of extra code are
> talking here? 

Probably less than 20...

In do_sysctl something like

    case XEN_SYSCTL_coverage_op:
        ret = coverage_op(&op->u.coverage_op);
        break;

where when disabled coverage_op should be declared as

static inline long coverage_op(struct xen_sysvtl_coverage_op *op)
{
    return -ENOSYS;
}

Frediano

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 15:05:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 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 1U1IBO-0006Hj-HK; Fri, 01 Feb 2013 15:05:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1IBM-0006He-O0
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 15:05:36 +0000
Received: from [85.158.138.51:63813] by server-14.bemta-3.messagelabs.com id
	FB/C0-23533-6B9DB015; Fri, 01 Feb 2013 15:05:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1359731124!30582166!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1435 invoked from network); 1 Feb 2013 15:05:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 15:05:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1072230"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 15:05:24 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 1 Feb 2013
	15:05:24 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "konrad@kernel.org" <konrad@kernel.org>
Date: Fri, 1 Feb 2013 15:05:23 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Adding support for coverage informations
Thread-Index: Ac4AjY+TaOzxby62Qa2yHbno+mH5Tg==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458352@LONPMAILBOX01.citrite.net>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
	<20130201144639.GC7461@konrad-lan.dumpdata.com>
In-Reply-To: <20130201144639.GC7461@konrad-lan.dumpdata.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: George Dunlap <George.Dunlap@eu.citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 09:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> > On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > > because is easier to have a zero cost if you disable coverage
> > > > > informations. The best thing would be redirect do_coverage_op to
> > > > > do_ni_hypercall using linker options but even two small stub would do
> > > > > (these stubs will return ENOSYS instead).
> > > > 
> > > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > > the hypercall path you are introducing? What is the zero cost?
> > > 
> > > I don't think we care a jot about the performance of this system call
> > > when coverage is disabled, it's certainly not a hot path and in any case
> > > if it is a NOP it doesn't really matter anyway.
> > > 
> > > Ian.
> > > 
> > 
> > It's not about the speed, it's about the bytes introduced in Xen binary.
> 
> Not sure I follow. What bytes? Just that the code size is bigger b/c it
> will go through the sysctl functions? How many bytes of extra code are
> talking here? 

Probably less than 20...

In do_sysctl something like

    case XEN_SYSCTL_coverage_op:
        ret = coverage_op(&op->u.coverage_op);
        break;

where when disabled coverage_op should be declared as

static inline long coverage_op(struct xen_sysvtl_coverage_op *op)
{
    return -ENOSYS;
}

Frediano

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 15:48:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 15:48: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 1U1Ipz-0006jr-BH; Fri, 01 Feb 2013 15:47:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1Ipy-0006jm-FG
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 15:47:34 +0000
Received: from [193.109.254.147:48470] by server-16.bemta-14.messagelabs.com
	id 7D/B1-25906-593EB015; Fri, 01 Feb 2013 15:47:33 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359733578!2989237!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12027 invoked from network); 1 Feb 2013 15:46:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 15:46:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
	d="c'?pl'?scan'208";a="1073592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 15:46:18 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 1 Feb 2013
	15:46:17 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Fri, 1 Feb 2013 15:46:17 +0000
Thread-Topic: [RFC PATCH] Coverage support
Thread-Index: Ac4Ak0YZ2cvsSGMKS0is0vAwUmk3pA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458354@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_"
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T24gRnJpLCAyMDEzLTAyLTAxIGF0IDE0OjQ4ICswMDAwLCBGcmVkaWFubyBaaWdsaW8gd3JvdGU6
Cj4gVXBkYXRlZCBzZXQgb2YgcGF0Y2hlcyBmb3IgY292ZXJhZ2UuCj4gQ2hhbmdlczoKPiAtIGlt
cGxlbWVudGVkIHdheSBvZiBnZXR0aW5nIGluZm9ybWF0aW9uCj4gLSB1c2Ugb25seSAyIHBhcmFt
ZXRlciBpbiBoeXBlcmNhbGwgKHN0aWxsIG5vdCBzdXJlIGl0J3MgYmV0dGVyIHRvIHVzZQo+ICAg
c3lzY3RsKQo+IC0gdXNlICJjb3ZlcmFnZSIgZm9yIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGFzIHN1
Z2dlc3RlZCBieSBJYW4gQ2FtcGJlbGwKPiAtIHNwbGl0IGhlYWRlciBpbiBpbmNsdWRlL3B1Ymxp
Yy9nY292LmggYW5kIGluY2x1ZGUveGVuL2djb3YuaCB0byBhbGxvdwo+ICAgdG9vbHMgdG8gaW5j
bHVkZSBwdWJsaWMgaGVhZGVyCj4gLSB1c2Ugd2VhayB0byBhdm9pZCBkZWZpbmluZyBjb21wYXRf
Y292ZXJhZ2Vfb3AKPiAKPiBJIG1hbmFnZSB0byB3cml0ZSAyIHRvb2xzLCBvbmUgdGhhdCBjYWxs
IHRoZSBuZXcgaHlwZXJjYWxsIGFuZCBkdW1wIHRoZQo+IGJsb2IgaW4gYSBmaWxlLCBvbmUgdGhh
dCBzcGxpdCB0aGlzIGZpbGUgaW50byByZXF1aXJlZCAuZ2NkYSBmaWxlcy4gCj4gQm90aCB2ZXJ5
IGhhY2sgb25lcyBhbmQgZGlydHkgYnV0IHdvcmtzIGFuZCBwcm92ZSB0aGUgaHlwZXJ2aXNvciBj
b2RlIGlzIAo+IGZpbmUuIFNob3VsZCBJIGp1c3Qgc2VuZCB0aGVtIGFueXdheT8KPiAKPiBUaGUg
Zm9ydGggcGF0Y2ggYWxsb3cgdG8gY29uc3VtZSBqdXN0IDAgYnl0ZXMgaWYgY292ZXJhZ2UgaXMg
ZGlzYWJsZWQuCj4gCgpUaGVzZSBhcmUgdGhlIHR3byB1dGlsaXRpZXMuIElmIGFueWJvZHkgd2Fu
dHMgdG8gdHJ5LgoKRnJlZGlhbm8KCg==

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_
Content-Type: text/x-csrc; name="get_coverage.c"
Content-Description: get_coverage.c
Content-Disposition: attachment; filename="get_coverage.c"; size=2783;
	creation-date="Fri, 01 Feb 2013 15:46:17 GMT";
	modification-date="Fri, 01 Feb 2013 15:46:17 GMT"
Content-Transfer-Encoding: base64

LyogZ2V0X2NvdmVyYWdlIC0gcHJvZ3JhbSB0byBnZXQgY292ZXJhZ2UgaW5mb3JtYXRpb25zIGZy
b20gWGVuCiAqIAogKiBDb3B5cmlnaHQgKEMpIDIwMTMgIC0gQ2l0cml4IFN5c3RlbXMKICogLS0t
LS0KICoKICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkKICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKICogdGhlIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKICogKGF0IHlv
dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KICoKICogVGhpcyBwcm9ncmFtIGlzIGRpc3Ry
aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiAqIGJ1dCBXSVRIT1VU
IEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiAqIE1F
UkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0
aGUKICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KICoKICog
WW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UKICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhl
IEZyZWUgU29mdHdhcmUKICogRm91bmRhdGlvbiwgSW5jLiwgNjc1IE1hc3MgQXZlLCBDYW1icmlk
Z2UsIE1BIDAyMTM5LCBVU0EuCiAqLwoKI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRs
aWIuaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1
ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxlcnJuby5oPgojaW5jbHVkZSA8c3lzL2lvY3RsLmg+CiNp
bmNsdWRlIDxpbnR0eXBlcy5oPgojaW5jbHVkZSA8c3lzL21tYW4uaD4KI2luY2x1ZGUgPGVyci5o
PgoKdHlwZWRlZiBzdHJ1Y3QgcHJpdmNtZF9oeXBlcmNhbGwKewoJdWludDY0X3Qgb3A7Cgl1aW50
NjRfdCBhcmdbNV07Cn0gcHJpdmNtZF9oeXBlcmNhbGxfdDsKCiNkZWZpbmUgSU9DVExfUFJJVkNN
RF9IWVBFUkNBTEwJCQkJCQkJCSBcCglfSU9DKF9JT0NfTk9ORSwgJ1AnLCAwLCBzaXplb2YocHJp
dmNtZF9oeXBlcmNhbGxfdCkpCgojZGVmaW5lIFBBR0VfU0laRSA0MDk2dQoKc3RhdGljIGludCBw
cml2Y21kX2ZkID0gLTE7CgppbnQgZ2V0X2djb3ZfaW5mbyhpbnQgb3AsIHZvaWQgKnB0cikKewoJ
cHJpdmNtZF9oeXBlcmNhbGxfdCBoY1sxXTsKCWludCByZXQ7CgoJaGMtPm9wID0gNDA7IC8vIFRP
RE8KCWhjLT5hcmdbMF0gPSBvcDsKCWhjLT5hcmdbMV0gPSAoaW50cHRyX3QpIHB0cjsKCXJldCA9
IGlvY3RsKHByaXZjbWRfZmQsIElPQ1RMX1BSSVZDTURfSFlQRVJDQUxMLCBoYyk7CglpZiAocmV0
ID49IDApCgkJcmV0dXJuIHJldDsKCXJldHVybiAtZXJybm87Cn0KCmludCBtYWluKHZvaWQpCnsK
CS8vIG9wZW4gcHJpdiBjb21tYW5kCglwcml2Y21kX2ZkID0gb3BlbigiL3Byb2MveGVuL3ByaXZj
bWQiLCBPX1JEV1IpOwoJaWYgKHByaXZjbWRfZmQgPCAwKQoJCWVycigxLCAib3BlbmluZyBwcml2
Y21kIik7CgoJLy8gY2hlY2sgc3VwcG9ydAoJaWYgKGdldF9nY292X2luZm8oMCwgTlVMTCkgPCAw
KQoJCWVycigxLCAiY2hlY2tpbmcgY292ZXJhZ2Ugc3VwcG9ydCIpOwoKCS8vIGFsbG9jYXRlCgl1
aW50OF90ICpwID0gbW1hcCgwLCBQQUdFX1NJWkUsIFBST1RfV1JJVEV8UFJPVF9SRUFELCBNQVBf
UFJJVkFURXxNQVBfQU5PTnxNQVBfTE9DS0VELCAtMSwgMCk7CglpZiAocCA9PSAodWludDhfdCAq
KSAtMSkKCQllcnIoMSwgImFsbG9jYXRpbmcgbWVtb3J5Iik7CgoJLy8gZ2V0IHRvdGFsIGxlbmd0
aAoJdWludDMyX3QgKnVpID0gKHVpbnQzMl90ICopIHA7CgkqdWkgPSAwOwoJaWYgKGdldF9nY292
X2luZm8oMSwgdWkpIDwgMCkKCQllcnIoMSwgImdldHRpbmcgdG90YWwgbGVuZ3RoIik7Cglwcmlu
dGYoInJldHVybmVkICV1IGJ5dGVzXG4iLCAodW5zaWduZWQpICp1aSk7CgoJLy8gc2FmZSBjaGVj
awoJdWludDMyX3QgdG90YWxfbGVuID0gKnVpOwoJaWYgKHRvdGFsX2xlbiA+IDE2dSAqIDEwMjR1
ICogMTAyNHUpCgkJZXJyeCgxLCAiY292ZXJhZ2Ugc2l6ZSB0b28gYmlnICV1IGJ5dGVzXG4iLCB0
b3RhbF9sZW4pOwoKCS8vIHJlYWxsb2NhdGUKCW11bm1hcChwLCBQQUdFX1NJWkUpOwoJc2l6ZV90
IHNpemUgPSB0b3RhbF9sZW4gKyBQQUdFX1NJWkU7CglzaXplIC09IChzaXplICUgUEFHRV9TSVpF
KTsKCXAgPSBtbWFwKDAsIHNpemUsIFBST1RfV1JJVEV8UFJPVF9SRUFELCBNQVBfUFJJVkFURXxN
QVBfQU5PTnxNQVBfTE9DS0VELCAtMSwgMCk7CglpZiAocCA9PSAodWludDhfdCAqKSAtMSkKCQll
cnIoMSwgIm1hcHBpbmcgbWVtb3J5IGZvciBjb3ZlcmFnZSIpOwoKCS8vIGdldCBkYXRhCglpZiAo
Z2V0X2djb3ZfaW5mbygyLCBwKSA8IDApCgkJZXJyKDEsICJnZXR0aW5nIGNvdmVyYWdlIGluZm9y
bWF0aW9uIik7CgoJLy8gd3JpdGUgdG8gYSBmaWxlCglGSUxFICpmID0gZm9wZW4oImdjZGEuZGF0
IiwgInciKTsKCWlmICghZikKCQllcnIoMSwgIm9wZW5pbmcgb3V0cHV0IGZpbGUiKTsKCWlmIChm
d3JpdGUocCwgMSwgdG90YWxfbGVuLCBmKSAhPSB0b3RhbF9sZW4pCgkJZXJyKDEsICJ3cml0aW5n
IGNvdmVyYWdlIHRvIGZpbGUiKTsKCWZjbG9zZShmKTsKCglyZXR1cm4gMDsKfQo=

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_
Content-Type: application/x-perl; name="split_coverage.pl"
Content-Description: split_coverage.pl
Content-Disposition: attachment; filename="split_coverage.pl"; size=3957;
	creation-date="Fri, 01 Feb 2013 15:46:17 GMT";
	modification-date="Fri, 01 Feb 2013 15:46:17 GMT"
Content-Transfer-Encoding: base64

IyEvdXNyL2Jpbi9wZXJsCgojIHNwbGl0X2NvdmVyYWdlLnBsIC0gc3BsaXQgY292ZXJhZ2UgaW5m
b3JtYXRpb24gZnJvbSBYZW4KIwojIENvcHlyaWdodCAoQykgMjAxMyAgLSBDaXRyaXggU3lzdGVt
cwojIC0tLS0tCiMKIyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQojIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CiMgdGhlIEZyZWUgU29mdHdh
cmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKIyAoYXQg
eW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgojCiMgVGhpcyBwcm9ncmFtIGlzIGRpc3Ry
aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiMgYnV0IFdJVEhPVVQg
QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKIyBNRVJD
SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhl
CiMgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KIwojIFlvdSBz
aG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlCiMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUg
U29mdHdhcmUKIyBGb3VuZGF0aW9uLCBJbmMuLCA2NzUgTWFzcyBBdmUsIENhbWJyaWRnZSwgTUEg
MDIxMzksIFVTQS4KCnVzZSBzdHJpY3Q7CnVzZSBGaWxlOjpQYXRoIHF3KG1ha2VfcGF0aCk7Cgpt
eSAkZm4gPSAkQVJHVlswXTsKb3BlbihJTiwgJzwnLCAkZm4pIG9yIGRpZSAnb3BlbmluZyc7Cm15
ICRkYXRhOwpkaWUgJ3JlYWRpbmcnIGlmICFkZWZpbmVkKHN5c3JlYWQoSU4sICRkYXRhLCAxNiox
MDI0KjEwMjQpKTsKbXkgJHM7CmRpZSAncmVhZGluZycgaWYgc3lzcmVhZChJTiwgJHMsIDEpICE9
IDA7CmNsb3NlKElOKTsKCm15ICRwb3MgPSAwOwoKc3ViIGdldFJhdygkKQp7CiAgICBteSAkbCA9
IHNoaWZ0OwogICAgZGllIGlmICRsIDwgMDsKICAgIGRpZSBpZiAkcG9zICsgJGwgPiBsZW5ndGgo
JGRhdGEpOwogICAgbXkgJHJlcyA9IHN1YnN0cigkZGF0YSwgJHBvcywgJGwpOwogICAgJHBvcyAr
PSAkbDsKICAgIHJldHVybiAkcmVzOwp9CgpzdWIgZ2V0MzIoKQp7CiAgICByZXR1cm4gdW5wYWNr
KCdWJywgZ2V0UmF3KDQpKTsKfQoKc3ViIGdldDY0KCkKewogICAgcmV0dXJuIHVucGFjaygnUTwn
LCBnZXRSYXcoOCkpOwp9CgpzdWIgZ2V0UygpCnsKICAgIG15ICRsID0gZ2V0MzIoKTsKICAgIG15
ICRyZXMgPSBnZXRSYXcoJGwpOwogICAgJGwgPSAkbCAmIDM7CiAgICBnZXRSYXcoNC0kbCkgaWYg
JGw7CiAgICByZXR1cm4gJHJlczsKfQoKc3ViIHBlZWszMigpCnsKICAgIG15ICRyZXMgPSBnZXQz
MigpOwogICAgJHBvcyAtPSA0OwogICAgcmV0dXJuICRyZXM7Cn0KCm15ICRtYWdpYyA9IDB4Njc2
MzY0NjE7Cm15ICRjdHJCYXNlID0gMHgwMWExMDAwMDsKCmRpZSAnbm8gY292ZXJhZ2UnIGlmIHBl
ZWszMigpICE9IDB4Njc2MzY0NjE7CgpzdWIgcGFyc2VGdW5jdGlvbnMoJCkKewogICAgbXkgJG51
bUNvdW50ZXJzID0gc2hpZnQ7CiAgICBteSAkdGFnID0gZ2V0MzIoKTsKICAgIG15ICRudW0gPSBn
ZXQzMigpOwoKICAgIG15IEBmdW5jczsKICAgIGZvciBteSAkbiAoMS4uJG51bSkgewogICAgICAg
IG15IEBkYXRhOwogICAgICAgIG15ICRpZGVudCA9IGdldDMyKCk7CiAgICAgICAgbXkgJGNoZWNr
c3VtID0gZ2V0MzIoKTsKICAgICAgICBmb3IgbXkgJG4gKDEuLiRudW1Db3VudGVycykgewogICAg
ICAgICAgICBwdXNoIEBkYXRhLCBnZXQzMigpOyAjIG51bWJlciBvZiBjb3VudGVycyBmb3IgYSB0
eXBlCiAgICAgICAgfQogICAgICAgIHB1c2ggQGZ1bmNzLCBbJGlkZW50LCAkY2hlY2tzdW0sIFxA
ZGF0YV07CiAgICB9CiAgICByZXR1cm4gQGZ1bmNzOwp9CgpzdWIgcGFyc2VDb3VudGVycygpCnsK
ICAgIG15ICRudW1Db3VudGVycyA9IHNoaWZ0OwogICAgbXkgJHRhZyA9IGdldDMyKCk7CiAgICBk
aWUgc3ByaW50Zigid3JvbmcgdGFnIDB4JTA4eCBwb3MgJHBvcyAoMHglMDh4KSIsICR0YWcsICRw
b3MpIGlmICR0YWcgPCAkY3RyQmFzZTsKICAgICR0YWcgLT0gJGN0ckJhc2U7CiAgICBkaWUgJ3dy
b25nIHRhZycgaWYgJHRhZyAmIDB4MWZmZmY7CiAgICAkdGFnID4+PSAxNzsKICAgIGRpZSAnd3Jv
bmcgdGFnJyBpZiAkdGFnID4gNTsKICAgIG15ICRkYXRhID0gJyc7CgogICAgbXkgJG51bSA9IGdl
dDMyKCk7CiAgICBmb3IgbXkgJG4gKDEuLiRudW0pIHsKICAgICAgICBteSAkY3RyID0gZ2V0NjQo
KTsgIyBjb3VudGVyCiAgICAgICAgJGRhdGEgLj0gcGFjaygnVlYnLCAkY3RyICYgMHhmZmZmZmZm
ZiwgKCRjdHIgPj4gMzIpICYgMHhmZmZmZmZmZik7CiAgICB9CiAgICByZXR1cm4gWyR0YWcsICRk
YXRhXTsKfQoKCnN1YiBwYXJzZUZpbGUoKQp7CiAgICBteSAkdGFnID0gZ2V0MzIoKTsKICAgIG15
ICR2ZXIgPSBnZXQzMigpOwogICAgbXkgJHN0YW1wID0gZ2V0MzIoKTsKICAgIG15ICRmbiA9IGdl
dFMoKTsKICAgIG15ICRudW1Db3VudGVyczsKCiAgICBwcmludCAiZ290IGZpbGUgJGZuXG4iOwog
ICAgZGllIGlmICRmbiAhfiBtLF4oLy4qPylbXi9dK1wuZ2NkYSQsOwogICAgbWFrZV9wYXRoKCIu
JDEiKTsKICAgIG9wZW4oT1VULCAnPicsICIuJGZuIikgb3IgZGllOwoKICAgIHByaW50IE9VVCBw
YWNrKCdWVlYnLCAkdGFnLCAkdmVyLCAkc3RhbXApOwoKICAgICMgcmVhZCBjb3VudGVycyBvZiBm
aWxlCiAgICBteSBAY3RyczsKICAgIG15IEBmdW5jczsKICAgIGZvciAoOzspIHsKICAgICAgICBt
eSAkdGFnID0gcGVlazMyKCk7CiAgICAgICAgbGFzdCBpZiAoJHRhZyA9PSAkbWFnaWMgfHwgJHRh
ZyA9PSAwKTsKICAgICAgICBpZiAoJHRhZyA9PSAweDAxMDAwMDAwKSB7CiAgICAgICAgICAgIGRp
ZSBpZiBzY2FsYXIoQGZ1bmNzKTsKICAgICAgICAgICAgQGZ1bmNzID0gcGFyc2VGdW5jdGlvbnMo
c2NhbGFyKEBjdHJzKSk7CiAgICAgICAgICAgIG5leHQ7CiAgICAgICAgfQoKICAgICAgICAjIG11
c3QgYmUgYSBjb3VudGVyCiAgICAgICAgcHVzaCBAY3RycywgcGFyc2VDb3VudGVycygpOwogICAg
ICAgICsrJG51bUNvdW50ZXJzOwogICAgfQoKICAgICMgcHJpbnQgYWxsIGZ1bmN0aW9ucwogICAg
Zm9yIG15ICRmIChAZnVuY3MpIHsKICAgICAgICAjIHRhZyB0YWdfbGVuIGlkZW50IGNoZWNrc3Vt
CiAgICAgICAgcHJpbnQgT1VUIHBhY2soJ1ZWVlYnLCAweDAxMDAwMDAwLCAyLCAkZi0+WzBdLCAk
Zi0+WzFdKTsKICAgICAgICAjIGFsbCBjb3VudHMKICAgICAgICBteSAkbiA9IDA7CiAgICAgICAg
Zm9yIG15ICRjIChAeyRmLT5bMl19KSB7CiAgICAgICAgICAgIG15ICgkdHlwZSwgJGRhdGEpID0g
QHskY3Ryc1skbl19OwogICAgICAgICAgICBwcmludCBPVVQgcGFjaygnVlYnLCAkY3RyQmFzZSAr
IDB4MjAwMDAgKiAkdHlwZSwgJGMqMik7CiAgICAgICAgICAgIGRpZSAiLS0kYy0tJHR5cGUtLSRk
YXRhLS0iIGlmIGxlbmd0aCgkZGF0YSkgPCAkYyAqIDg7CiAgICAgICAgICAgIHByaW50IE9VVCBz
dWJzdHIoJGRhdGEsIDAsICRjICogOCk7CiAgICAgICAgICAgICRjdHJzWyRuXSA9IFskdHlwZSwg
c3Vic3RyKCRkYXRhLCAkYyAqIDgpXTsKICAgICAgICAgICAgKyskbjsKICAgICAgICB9CiAgICB9
CiAgICBjbG9zZShPVVQpOwp9Cgpmb3IgKDs7KSB7CiAgICBteSAkdGFnID0gcGVlazMyKCk7CiAg
ICBpZiAoJHRhZyA9PSAkbWFnaWMpIHsKICAgICAgICBwYXJzZUZpbGUoKTsKICAgIH0gZWxzaWYg
KCR0YWcgPT0gMCkgewogICAgICAgIGxhc3Q7CiAgICB9IGVsc2UgewogICAgICAgIGRpZSAid3Jv
bmcgdGFnICR0YWciOwogICAgfQp9CgoK

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

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

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 15:48:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 15:48: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 1U1Ipz-0006jr-BH; Fri, 01 Feb 2013 15:47:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U1Ipy-0006jm-FG
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 15:47:34 +0000
Received: from [193.109.254.147:48470] by server-16.bemta-14.messagelabs.com
	id 7D/B1-25906-593EB015; Fri, 01 Feb 2013 15:47:33 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359733578!2989237!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12027 invoked from network); 1 Feb 2013 15:46:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 15:46:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
	d="c'?pl'?scan'208";a="1073592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 15:46:18 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 1 Feb 2013
	15:46:17 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Fri, 1 Feb 2013 15:46:17 +0000
Thread-Topic: [RFC PATCH] Coverage support
Thread-Index: Ac4Ak0YZ2cvsSGMKS0is0vAwUmk3pA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458354@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_"
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T24gRnJpLCAyMDEzLTAyLTAxIGF0IDE0OjQ4ICswMDAwLCBGcmVkaWFubyBaaWdsaW8gd3JvdGU6
Cj4gVXBkYXRlZCBzZXQgb2YgcGF0Y2hlcyBmb3IgY292ZXJhZ2UuCj4gQ2hhbmdlczoKPiAtIGlt
cGxlbWVudGVkIHdheSBvZiBnZXR0aW5nIGluZm9ybWF0aW9uCj4gLSB1c2Ugb25seSAyIHBhcmFt
ZXRlciBpbiBoeXBlcmNhbGwgKHN0aWxsIG5vdCBzdXJlIGl0J3MgYmV0dGVyIHRvIHVzZQo+ICAg
c3lzY3RsKQo+IC0gdXNlICJjb3ZlcmFnZSIgZm9yIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGFzIHN1
Z2dlc3RlZCBieSBJYW4gQ2FtcGJlbGwKPiAtIHNwbGl0IGhlYWRlciBpbiBpbmNsdWRlL3B1Ymxp
Yy9nY292LmggYW5kIGluY2x1ZGUveGVuL2djb3YuaCB0byBhbGxvdwo+ICAgdG9vbHMgdG8gaW5j
bHVkZSBwdWJsaWMgaGVhZGVyCj4gLSB1c2Ugd2VhayB0byBhdm9pZCBkZWZpbmluZyBjb21wYXRf
Y292ZXJhZ2Vfb3AKPiAKPiBJIG1hbmFnZSB0byB3cml0ZSAyIHRvb2xzLCBvbmUgdGhhdCBjYWxs
IHRoZSBuZXcgaHlwZXJjYWxsIGFuZCBkdW1wIHRoZQo+IGJsb2IgaW4gYSBmaWxlLCBvbmUgdGhh
dCBzcGxpdCB0aGlzIGZpbGUgaW50byByZXF1aXJlZCAuZ2NkYSBmaWxlcy4gCj4gQm90aCB2ZXJ5
IGhhY2sgb25lcyBhbmQgZGlydHkgYnV0IHdvcmtzIGFuZCBwcm92ZSB0aGUgaHlwZXJ2aXNvciBj
b2RlIGlzIAo+IGZpbmUuIFNob3VsZCBJIGp1c3Qgc2VuZCB0aGVtIGFueXdheT8KPiAKPiBUaGUg
Zm9ydGggcGF0Y2ggYWxsb3cgdG8gY29uc3VtZSBqdXN0IDAgYnl0ZXMgaWYgY292ZXJhZ2UgaXMg
ZGlzYWJsZWQuCj4gCgpUaGVzZSBhcmUgdGhlIHR3byB1dGlsaXRpZXMuIElmIGFueWJvZHkgd2Fu
dHMgdG8gdHJ5LgoKRnJlZGlhbm8KCg==

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_
Content-Type: text/x-csrc; name="get_coverage.c"
Content-Description: get_coverage.c
Content-Disposition: attachment; filename="get_coverage.c"; size=2783;
	creation-date="Fri, 01 Feb 2013 15:46:17 GMT";
	modification-date="Fri, 01 Feb 2013 15:46:17 GMT"
Content-Transfer-Encoding: base64

LyogZ2V0X2NvdmVyYWdlIC0gcHJvZ3JhbSB0byBnZXQgY292ZXJhZ2UgaW5mb3JtYXRpb25zIGZy
b20gWGVuCiAqIAogKiBDb3B5cmlnaHQgKEMpIDIwMTMgIC0gQ2l0cml4IFN5c3RlbXMKICogLS0t
LS0KICoKICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkKICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu
ZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKICogdGhlIEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKICogKGF0IHlv
dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KICoKICogVGhpcyBwcm9ncmFtIGlzIGRpc3Ry
aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiAqIGJ1dCBXSVRIT1VU
IEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiAqIE1F
UkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0
aGUKICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KICoKICog
WW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UKICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhl
IEZyZWUgU29mdHdhcmUKICogRm91bmRhdGlvbiwgSW5jLiwgNjc1IE1hc3MgQXZlLCBDYW1icmlk
Z2UsIE1BIDAyMTM5LCBVU0EuCiAqLwoKI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRs
aWIuaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1
ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxlcnJuby5oPgojaW5jbHVkZSA8c3lzL2lvY3RsLmg+CiNp
bmNsdWRlIDxpbnR0eXBlcy5oPgojaW5jbHVkZSA8c3lzL21tYW4uaD4KI2luY2x1ZGUgPGVyci5o
PgoKdHlwZWRlZiBzdHJ1Y3QgcHJpdmNtZF9oeXBlcmNhbGwKewoJdWludDY0X3Qgb3A7Cgl1aW50
NjRfdCBhcmdbNV07Cn0gcHJpdmNtZF9oeXBlcmNhbGxfdDsKCiNkZWZpbmUgSU9DVExfUFJJVkNN
RF9IWVBFUkNBTEwJCQkJCQkJCSBcCglfSU9DKF9JT0NfTk9ORSwgJ1AnLCAwLCBzaXplb2YocHJp
dmNtZF9oeXBlcmNhbGxfdCkpCgojZGVmaW5lIFBBR0VfU0laRSA0MDk2dQoKc3RhdGljIGludCBw
cml2Y21kX2ZkID0gLTE7CgppbnQgZ2V0X2djb3ZfaW5mbyhpbnQgb3AsIHZvaWQgKnB0cikKewoJ
cHJpdmNtZF9oeXBlcmNhbGxfdCBoY1sxXTsKCWludCByZXQ7CgoJaGMtPm9wID0gNDA7IC8vIFRP
RE8KCWhjLT5hcmdbMF0gPSBvcDsKCWhjLT5hcmdbMV0gPSAoaW50cHRyX3QpIHB0cjsKCXJldCA9
IGlvY3RsKHByaXZjbWRfZmQsIElPQ1RMX1BSSVZDTURfSFlQRVJDQUxMLCBoYyk7CglpZiAocmV0
ID49IDApCgkJcmV0dXJuIHJldDsKCXJldHVybiAtZXJybm87Cn0KCmludCBtYWluKHZvaWQpCnsK
CS8vIG9wZW4gcHJpdiBjb21tYW5kCglwcml2Y21kX2ZkID0gb3BlbigiL3Byb2MveGVuL3ByaXZj
bWQiLCBPX1JEV1IpOwoJaWYgKHByaXZjbWRfZmQgPCAwKQoJCWVycigxLCAib3BlbmluZyBwcml2
Y21kIik7CgoJLy8gY2hlY2sgc3VwcG9ydAoJaWYgKGdldF9nY292X2luZm8oMCwgTlVMTCkgPCAw
KQoJCWVycigxLCAiY2hlY2tpbmcgY292ZXJhZ2Ugc3VwcG9ydCIpOwoKCS8vIGFsbG9jYXRlCgl1
aW50OF90ICpwID0gbW1hcCgwLCBQQUdFX1NJWkUsIFBST1RfV1JJVEV8UFJPVF9SRUFELCBNQVBf
UFJJVkFURXxNQVBfQU5PTnxNQVBfTE9DS0VELCAtMSwgMCk7CglpZiAocCA9PSAodWludDhfdCAq
KSAtMSkKCQllcnIoMSwgImFsbG9jYXRpbmcgbWVtb3J5Iik7CgoJLy8gZ2V0IHRvdGFsIGxlbmd0
aAoJdWludDMyX3QgKnVpID0gKHVpbnQzMl90ICopIHA7CgkqdWkgPSAwOwoJaWYgKGdldF9nY292
X2luZm8oMSwgdWkpIDwgMCkKCQllcnIoMSwgImdldHRpbmcgdG90YWwgbGVuZ3RoIik7Cglwcmlu
dGYoInJldHVybmVkICV1IGJ5dGVzXG4iLCAodW5zaWduZWQpICp1aSk7CgoJLy8gc2FmZSBjaGVj
awoJdWludDMyX3QgdG90YWxfbGVuID0gKnVpOwoJaWYgKHRvdGFsX2xlbiA+IDE2dSAqIDEwMjR1
ICogMTAyNHUpCgkJZXJyeCgxLCAiY292ZXJhZ2Ugc2l6ZSB0b28gYmlnICV1IGJ5dGVzXG4iLCB0
b3RhbF9sZW4pOwoKCS8vIHJlYWxsb2NhdGUKCW11bm1hcChwLCBQQUdFX1NJWkUpOwoJc2l6ZV90
IHNpemUgPSB0b3RhbF9sZW4gKyBQQUdFX1NJWkU7CglzaXplIC09IChzaXplICUgUEFHRV9TSVpF
KTsKCXAgPSBtbWFwKDAsIHNpemUsIFBST1RfV1JJVEV8UFJPVF9SRUFELCBNQVBfUFJJVkFURXxN
QVBfQU5PTnxNQVBfTE9DS0VELCAtMSwgMCk7CglpZiAocCA9PSAodWludDhfdCAqKSAtMSkKCQll
cnIoMSwgIm1hcHBpbmcgbWVtb3J5IGZvciBjb3ZlcmFnZSIpOwoKCS8vIGdldCBkYXRhCglpZiAo
Z2V0X2djb3ZfaW5mbygyLCBwKSA8IDApCgkJZXJyKDEsICJnZXR0aW5nIGNvdmVyYWdlIGluZm9y
bWF0aW9uIik7CgoJLy8gd3JpdGUgdG8gYSBmaWxlCglGSUxFICpmID0gZm9wZW4oImdjZGEuZGF0
IiwgInciKTsKCWlmICghZikKCQllcnIoMSwgIm9wZW5pbmcgb3V0cHV0IGZpbGUiKTsKCWlmIChm
d3JpdGUocCwgMSwgdG90YWxfbGVuLCBmKSAhPSB0b3RhbF9sZW4pCgkJZXJyKDEsICJ3cml0aW5n
IGNvdmVyYWdlIHRvIGZpbGUiKTsKCWZjbG9zZShmKTsKCglyZXR1cm4gMDsKfQo=

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_
Content-Type: application/x-perl; name="split_coverage.pl"
Content-Description: split_coverage.pl
Content-Disposition: attachment; filename="split_coverage.pl"; size=3957;
	creation-date="Fri, 01 Feb 2013 15:46:17 GMT";
	modification-date="Fri, 01 Feb 2013 15:46:17 GMT"
Content-Transfer-Encoding: base64

IyEvdXNyL2Jpbi9wZXJsCgojIHNwbGl0X2NvdmVyYWdlLnBsIC0gc3BsaXQgY292ZXJhZ2UgaW5m
b3JtYXRpb24gZnJvbSBYZW4KIwojIENvcHlyaWdodCAoQykgMjAxMyAgLSBDaXRyaXggU3lzdGVt
cwojIC0tLS0tCiMKIyBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRp
c3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQojIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5CiMgdGhlIEZyZWUgU29mdHdh
cmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKIyAoYXQg
eW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLgojCiMgVGhpcyBwcm9ncmFtIGlzIGRpc3Ry
aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiMgYnV0IFdJVEhPVVQg
QU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKIyBNRVJD
SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhl
CiMgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KIwojIFlvdSBz
aG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl
bnNlCiMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUg
U29mdHdhcmUKIyBGb3VuZGF0aW9uLCBJbmMuLCA2NzUgTWFzcyBBdmUsIENhbWJyaWRnZSwgTUEg
MDIxMzksIFVTQS4KCnVzZSBzdHJpY3Q7CnVzZSBGaWxlOjpQYXRoIHF3KG1ha2VfcGF0aCk7Cgpt
eSAkZm4gPSAkQVJHVlswXTsKb3BlbihJTiwgJzwnLCAkZm4pIG9yIGRpZSAnb3BlbmluZyc7Cm15
ICRkYXRhOwpkaWUgJ3JlYWRpbmcnIGlmICFkZWZpbmVkKHN5c3JlYWQoSU4sICRkYXRhLCAxNiox
MDI0KjEwMjQpKTsKbXkgJHM7CmRpZSAncmVhZGluZycgaWYgc3lzcmVhZChJTiwgJHMsIDEpICE9
IDA7CmNsb3NlKElOKTsKCm15ICRwb3MgPSAwOwoKc3ViIGdldFJhdygkKQp7CiAgICBteSAkbCA9
IHNoaWZ0OwogICAgZGllIGlmICRsIDwgMDsKICAgIGRpZSBpZiAkcG9zICsgJGwgPiBsZW5ndGgo
JGRhdGEpOwogICAgbXkgJHJlcyA9IHN1YnN0cigkZGF0YSwgJHBvcywgJGwpOwogICAgJHBvcyAr
PSAkbDsKICAgIHJldHVybiAkcmVzOwp9CgpzdWIgZ2V0MzIoKQp7CiAgICByZXR1cm4gdW5wYWNr
KCdWJywgZ2V0UmF3KDQpKTsKfQoKc3ViIGdldDY0KCkKewogICAgcmV0dXJuIHVucGFjaygnUTwn
LCBnZXRSYXcoOCkpOwp9CgpzdWIgZ2V0UygpCnsKICAgIG15ICRsID0gZ2V0MzIoKTsKICAgIG15
ICRyZXMgPSBnZXRSYXcoJGwpOwogICAgJGwgPSAkbCAmIDM7CiAgICBnZXRSYXcoNC0kbCkgaWYg
JGw7CiAgICByZXR1cm4gJHJlczsKfQoKc3ViIHBlZWszMigpCnsKICAgIG15ICRyZXMgPSBnZXQz
MigpOwogICAgJHBvcyAtPSA0OwogICAgcmV0dXJuICRyZXM7Cn0KCm15ICRtYWdpYyA9IDB4Njc2
MzY0NjE7Cm15ICRjdHJCYXNlID0gMHgwMWExMDAwMDsKCmRpZSAnbm8gY292ZXJhZ2UnIGlmIHBl
ZWszMigpICE9IDB4Njc2MzY0NjE7CgpzdWIgcGFyc2VGdW5jdGlvbnMoJCkKewogICAgbXkgJG51
bUNvdW50ZXJzID0gc2hpZnQ7CiAgICBteSAkdGFnID0gZ2V0MzIoKTsKICAgIG15ICRudW0gPSBn
ZXQzMigpOwoKICAgIG15IEBmdW5jczsKICAgIGZvciBteSAkbiAoMS4uJG51bSkgewogICAgICAg
IG15IEBkYXRhOwogICAgICAgIG15ICRpZGVudCA9IGdldDMyKCk7CiAgICAgICAgbXkgJGNoZWNr
c3VtID0gZ2V0MzIoKTsKICAgICAgICBmb3IgbXkgJG4gKDEuLiRudW1Db3VudGVycykgewogICAg
ICAgICAgICBwdXNoIEBkYXRhLCBnZXQzMigpOyAjIG51bWJlciBvZiBjb3VudGVycyBmb3IgYSB0
eXBlCiAgICAgICAgfQogICAgICAgIHB1c2ggQGZ1bmNzLCBbJGlkZW50LCAkY2hlY2tzdW0sIFxA
ZGF0YV07CiAgICB9CiAgICByZXR1cm4gQGZ1bmNzOwp9CgpzdWIgcGFyc2VDb3VudGVycygpCnsK
ICAgIG15ICRudW1Db3VudGVycyA9IHNoaWZ0OwogICAgbXkgJHRhZyA9IGdldDMyKCk7CiAgICBk
aWUgc3ByaW50Zigid3JvbmcgdGFnIDB4JTA4eCBwb3MgJHBvcyAoMHglMDh4KSIsICR0YWcsICRw
b3MpIGlmICR0YWcgPCAkY3RyQmFzZTsKICAgICR0YWcgLT0gJGN0ckJhc2U7CiAgICBkaWUgJ3dy
b25nIHRhZycgaWYgJHRhZyAmIDB4MWZmZmY7CiAgICAkdGFnID4+PSAxNzsKICAgIGRpZSAnd3Jv
bmcgdGFnJyBpZiAkdGFnID4gNTsKICAgIG15ICRkYXRhID0gJyc7CgogICAgbXkgJG51bSA9IGdl
dDMyKCk7CiAgICBmb3IgbXkgJG4gKDEuLiRudW0pIHsKICAgICAgICBteSAkY3RyID0gZ2V0NjQo
KTsgIyBjb3VudGVyCiAgICAgICAgJGRhdGEgLj0gcGFjaygnVlYnLCAkY3RyICYgMHhmZmZmZmZm
ZiwgKCRjdHIgPj4gMzIpICYgMHhmZmZmZmZmZik7CiAgICB9CiAgICByZXR1cm4gWyR0YWcsICRk
YXRhXTsKfQoKCnN1YiBwYXJzZUZpbGUoKQp7CiAgICBteSAkdGFnID0gZ2V0MzIoKTsKICAgIG15
ICR2ZXIgPSBnZXQzMigpOwogICAgbXkgJHN0YW1wID0gZ2V0MzIoKTsKICAgIG15ICRmbiA9IGdl
dFMoKTsKICAgIG15ICRudW1Db3VudGVyczsKCiAgICBwcmludCAiZ290IGZpbGUgJGZuXG4iOwog
ICAgZGllIGlmICRmbiAhfiBtLF4oLy4qPylbXi9dK1wuZ2NkYSQsOwogICAgbWFrZV9wYXRoKCIu
JDEiKTsKICAgIG9wZW4oT1VULCAnPicsICIuJGZuIikgb3IgZGllOwoKICAgIHByaW50IE9VVCBw
YWNrKCdWVlYnLCAkdGFnLCAkdmVyLCAkc3RhbXApOwoKICAgICMgcmVhZCBjb3VudGVycyBvZiBm
aWxlCiAgICBteSBAY3RyczsKICAgIG15IEBmdW5jczsKICAgIGZvciAoOzspIHsKICAgICAgICBt
eSAkdGFnID0gcGVlazMyKCk7CiAgICAgICAgbGFzdCBpZiAoJHRhZyA9PSAkbWFnaWMgfHwgJHRh
ZyA9PSAwKTsKICAgICAgICBpZiAoJHRhZyA9PSAweDAxMDAwMDAwKSB7CiAgICAgICAgICAgIGRp
ZSBpZiBzY2FsYXIoQGZ1bmNzKTsKICAgICAgICAgICAgQGZ1bmNzID0gcGFyc2VGdW5jdGlvbnMo
c2NhbGFyKEBjdHJzKSk7CiAgICAgICAgICAgIG5leHQ7CiAgICAgICAgfQoKICAgICAgICAjIG11
c3QgYmUgYSBjb3VudGVyCiAgICAgICAgcHVzaCBAY3RycywgcGFyc2VDb3VudGVycygpOwogICAg
ICAgICsrJG51bUNvdW50ZXJzOwogICAgfQoKICAgICMgcHJpbnQgYWxsIGZ1bmN0aW9ucwogICAg
Zm9yIG15ICRmIChAZnVuY3MpIHsKICAgICAgICAjIHRhZyB0YWdfbGVuIGlkZW50IGNoZWNrc3Vt
CiAgICAgICAgcHJpbnQgT1VUIHBhY2soJ1ZWVlYnLCAweDAxMDAwMDAwLCAyLCAkZi0+WzBdLCAk
Zi0+WzFdKTsKICAgICAgICAjIGFsbCBjb3VudHMKICAgICAgICBteSAkbiA9IDA7CiAgICAgICAg
Zm9yIG15ICRjIChAeyRmLT5bMl19KSB7CiAgICAgICAgICAgIG15ICgkdHlwZSwgJGRhdGEpID0g
QHskY3Ryc1skbl19OwogICAgICAgICAgICBwcmludCBPVVQgcGFjaygnVlYnLCAkY3RyQmFzZSAr
IDB4MjAwMDAgKiAkdHlwZSwgJGMqMik7CiAgICAgICAgICAgIGRpZSAiLS0kYy0tJHR5cGUtLSRk
YXRhLS0iIGlmIGxlbmd0aCgkZGF0YSkgPCAkYyAqIDg7CiAgICAgICAgICAgIHByaW50IE9VVCBz
dWJzdHIoJGRhdGEsIDAsICRjICogOCk7CiAgICAgICAgICAgICRjdHJzWyRuXSA9IFskdHlwZSwg
c3Vic3RyKCRkYXRhLCAkYyAqIDgpXTsKICAgICAgICAgICAgKyskbjsKICAgICAgICB9CiAgICB9
CiAgICBjbG9zZShPVVQpOwp9Cgpmb3IgKDs7KSB7CiAgICBteSAkdGFnID0gcGVlazMyKCk7CiAg
ICBpZiAoJHRhZyA9PSAkbWFnaWMpIHsKICAgICAgICBwYXJzZUZpbGUoKTsKICAgIH0gZWxzaWYg
KCR0YWcgPT0gMCkgewogICAgICAgIGxhc3Q7CiAgICB9IGVsc2UgewogICAgICAgIGRpZSAid3Jv
bmcgdGFnICR0YWciOwogICAgfQp9CgoK

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

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

--_003_7CE799CC0E4DE04B88D5FDF226E18AC201058D458354LONPMAILBOX_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 16:25:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 16:25: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 1U1JQG-0007oR-0X; Fri, 01 Feb 2013 16:25: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 1U1JQD-0007oM-Os
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 16:25:02 +0000
Received: from [85.158.139.83:12547] by server-9.bemta-5.messagelabs.com id
	4C/F1-24440-D5CEB015; Fri, 01 Feb 2013 16:25:01 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1359735900!23253488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10118 invoked from network); 1 Feb 2013 16:25:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 16:25:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Feb 2013 16:25:00 +0000
Message-Id: <510BEC590200007800094177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 01 Feb 2013 16:24:57 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <mukesh.rathor@oracle.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
In-Reply-To: <20130131182329.2cb3a225@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad@kernel.org, konrad.wilk@oracle.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Mukesh Rathor <mukesh.rathor@oracle.com> 02/01/13 3:23 AM >>>
>On Tue, 29 Jan 2013 10:48:12 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
>> >>> wrote:
>> > On xen side I added the ifdef:
>> > 
>> > #if __XEN_INTERFACE_VERSION__ < 0x00040300
>> >     unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames,
>> > # ents) */
>> > #else
>> >     union {
>> >         struct {
>> >             /* GDT (machine frames, # ents) */
>> >             unsigned long gdt_frames[16], gdt_ents;
>> >         } pv;
>> >         struct {
>> >             /* PVH: GDTR addr and size */
>> >             unsigned long gdtaddr, gdtsz;
>> >         } pvh;
>> >     } u;
>> > #endif
>> > 
>> > but it doesn't matter on linux side, so up to you.
>> 
>> But I'd still prefer for this to go away again - you could simply use
>> gdt_frames[0] for gdtaddr and gdt_ents for the (normalized)
>> gdtsz.
>
>That was my patch version 1 during linux patch review. Then the reviewer
>suggested to make it a union.
>
>> And if you nevertheless go the union route, call it "gdt" instead
>> of "u" and drop the gdt/gdt_ prefixes from the member names
>> (yes, I know, grepping and cscoping for such member is more
>> difficult, but I continue to see more advantage in avoiding the
>> redundancy).
>
>That was my patch version 2, where I called it gdt and another reviewer
>suggested to change to u. So I changed it to u.
>
>It's gone thru enough iterations that I'd like to leave as is. Thank
>you in advance for your compromise in helping us mortals grep/cscope 
>to learn code.

That's part of the reason why I said from the beginning that doing the Linux
side first is wrong.

Jan


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 16:25:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 16:25: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 1U1JQG-0007oR-0X; Fri, 01 Feb 2013 16:25: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 1U1JQD-0007oM-Os
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 16:25:02 +0000
Received: from [85.158.139.83:12547] by server-9.bemta-5.messagelabs.com id
	4C/F1-24440-D5CEB015; Fri, 01 Feb 2013 16:25:01 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1359735900!23253488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10118 invoked from network); 1 Feb 2013 16:25:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 16:25:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 01 Feb 2013 16:25:00 +0000
Message-Id: <510BEC590200007800094177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 01 Feb 2013 16:24:57 +0000
From: "Jan Beulich" <jbeulich@suse.com>
To: <mukesh.rathor@oracle.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
In-Reply-To: <20130131182329.2cb3a225@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad@kernel.org, konrad.wilk@oracle.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> Mukesh Rathor <mukesh.rathor@oracle.com> 02/01/13 3:23 AM >>>
>On Tue, 29 Jan 2013 10:48:12 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
>> >>> wrote:
>> > On xen side I added the ifdef:
>> > 
>> > #if __XEN_INTERFACE_VERSION__ < 0x00040300
>> >     unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames,
>> > # ents) */
>> > #else
>> >     union {
>> >         struct {
>> >             /* GDT (machine frames, # ents) */
>> >             unsigned long gdt_frames[16], gdt_ents;
>> >         } pv;
>> >         struct {
>> >             /* PVH: GDTR addr and size */
>> >             unsigned long gdtaddr, gdtsz;
>> >         } pvh;
>> >     } u;
>> > #endif
>> > 
>> > but it doesn't matter on linux side, so up to you.
>> 
>> But I'd still prefer for this to go away again - you could simply use
>> gdt_frames[0] for gdtaddr and gdt_ents for the (normalized)
>> gdtsz.
>
>That was my patch version 1 during linux patch review. Then the reviewer
>suggested to make it a union.
>
>> And if you nevertheless go the union route, call it "gdt" instead
>> of "u" and drop the gdt/gdt_ prefixes from the member names
>> (yes, I know, grepping and cscoping for such member is more
>> difficult, but I continue to see more advantage in avoiding the
>> redundancy).
>
>That was my patch version 2, where I called it gdt and another reviewer
>suggested to change to u. So I changed it to u.
>
>It's gone thru enough iterations that I'd like to leave as is. Thank
>you in advance for your compromise in helping us mortals grep/cscope 
>to learn code.

That's part of the reason why I said from the beginning that doing the Linux
side first is wrong.

Jan


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 17:15:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 17: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 1U1KD2-0008I9-OP; Fri, 01 Feb 2013 17:15:28 +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 1U1KD1-0008Hy-8u
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 17:15:27 +0000
Received: from [193.109.254.147:41598] by server-4.bemta-14.messagelabs.com id
	B1/AC-20719-E28FB015; Fri, 01 Feb 2013 17:15:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359738925!2999251!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1Nzc1OTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1Nzc1OTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15832 invoked from network); 1 Feb 2013 17:15:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 17:15:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiS0ME4tB
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-087-200.pools.arcor-ip.net [88.65.87.200])
	by smtp.strato.de (jored mo7) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602789p11GuERM
	for <xen-devel@lists.xen.org>; Fri, 1 Feb 2013 18:15:25 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D8E0D1863D
	for <xen-devel@lists.xen.org>; Fri,  1 Feb 2013 18:15:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6d1d516ecaade56f796e3216e9931fdcc12282cd
Message-Id: <6d1d516ecaade56f796e.1359738924@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Fri, 01 Feb 2013 18:15:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: fix logic error in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1359738883 -3600
# Node ID 6d1d516ecaade56f796e3216e9931fdcc12282cd
# Parent  6727070b4129cf852199b66b6a81042ee6966a98
tools/xc: fix logic error in stdiostream_progress

Setting XTL_STDIOSTREAM_HIDE_PROGRESS should disable progress reporting,
instead of not setting it.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6727070b4129 -r 6d1d516ecaad tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -89,7 +89,7 @@ static void stdiostream_progress(struct 
     int newpel, extra_erase;
     xentoollog_level this_level;
 
-    if (!(lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS))
+    if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
         return;
 
     if (percent < lg->progress_last_percent) {

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 17:15:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 17: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 1U1KD2-0008I9-OP; Fri, 01 Feb 2013 17:15:28 +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 1U1KD1-0008Hy-8u
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 17:15:27 +0000
Received: from [193.109.254.147:41598] by server-4.bemta-14.messagelabs.com id
	B1/AC-20719-E28FB015; Fri, 01 Feb 2013 17:15:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359738925!2999251!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1Nzc1OTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1Nzc1OTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15832 invoked from network); 1 Feb 2013 17:15:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 17:15:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiS0ME4tB
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-087-200.pools.arcor-ip.net [88.65.87.200])
	by smtp.strato.de (jored mo7) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602789p11GuERM
	for <xen-devel@lists.xen.org>; Fri, 1 Feb 2013 18:15:25 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D8E0D1863D
	for <xen-devel@lists.xen.org>; Fri,  1 Feb 2013 18:15:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6d1d516ecaade56f796e3216e9931fdcc12282cd
Message-Id: <6d1d516ecaade56f796e.1359738924@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Fri, 01 Feb 2013 18:15:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: fix logic error in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1359738883 -3600
# Node ID 6d1d516ecaade56f796e3216e9931fdcc12282cd
# Parent  6727070b4129cf852199b66b6a81042ee6966a98
tools/xc: fix logic error in stdiostream_progress

Setting XTL_STDIOSTREAM_HIDE_PROGRESS should disable progress reporting,
instead of not setting it.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6727070b4129 -r 6d1d516ecaad tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -89,7 +89,7 @@ static void stdiostream_progress(struct 
     int newpel, extra_erase;
     xentoollog_level this_level;
 
-    if (!(lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS))
+    if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
         return;
 
     if (percent < lg->progress_last_percent) {

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 18:50:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 18:50: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 1U1Lg5-0000de-8k; Fri, 01 Feb 2013 18:49: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 1U1Lg2-0000dZ-OF
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 18:49:31 +0000
Received: from [85.158.138.51:61000] by server-13.bemta-3.messagelabs.com id
	F9/EF-20653-43E0C015; Fri, 01 Feb 2013 18:49:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359744563!28454712!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7191 invoked from network); 1 Feb 2013 18:49:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 18:49:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1083534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 18:49: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.297.1; Fri, 1 Feb 2013 18:49:22 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1Lfu-0005ND-An;
	Fri, 01 Feb 2013 18:49:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1Lft-0002QR-Vk;
	Fri, 01 Feb 2013 18:49:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15404-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Feb 2013 18:49:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15404: 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 15404 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15404/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 18:50:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 18:50: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 1U1Lg5-0000de-8k; Fri, 01 Feb 2013 18:49: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 1U1Lg2-0000dZ-OF
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 18:49:31 +0000
Received: from [85.158.138.51:61000] by server-13.bemta-3.messagelabs.com id
	F9/EF-20653-43E0C015; Fri, 01 Feb 2013 18:49:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359744563!28454712!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMjA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7191 invoked from network); 1 Feb 2013 18:49:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 18:49:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="1083534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 18:49: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.297.1; Fri, 1 Feb 2013 18:49:22 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1Lfu-0005ND-An;
	Fri, 01 Feb 2013 18:49:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1Lft-0002QR-Vk;
	Fri, 01 Feb 2013 18:49:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15404-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 1 Feb 2013 18:49:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15404: 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 15404 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15404/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 18:58:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 18:58: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 1U1Lof-0000ps-KY; Fri, 01 Feb 2013 18:58:25 +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 1U1Lod-0000pn-Sn
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 18:58:24 +0000
Received: from [85.158.138.51:13951] by server-10.bemta-3.messagelabs.com id
	94/33-10609-F401C015; Fri, 01 Feb 2013 18:58:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1359745101!28863715!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5Mzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30890 invoked from network); 1 Feb 2013 18:58:21 -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; 1 Feb 2013 18:58:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiS0ME4tB
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-087-200.pools.arcor-ip.net [88.65.87.200])
	by smtp.strato.de (josoe mo45) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602409p11IlLhi
	for <xen-devel@lists.xen.org>; Fri, 1 Feb 2013 19:58:21 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DB7EE1863D
	for <xen-devel@lists.xen.org>; Fri,  1 Feb 2013 19:58:20 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d76b38b799293ff17fed8eaaac8fbbebced1b72f
Message-Id: <d76b38b799293ff17fed.1359745100@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Fri, 01 Feb 2013 19:58:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1359745022 -3600
# Node ID d76b38b799293ff17fed8eaaac8fbbebced1b72f
# Parent  6d1d516ecaade56f796e3216e9931fdcc12282cd
tools/xc: restore logging in xc_save

Prior to xen-4.1 the helper xc_save would print some progress during
migration. With the new xc_interface_open API no more messages were
printed because no logger was configured.

Restore previous behaviour by providing a logger. The progress in
xc_domain_save will be disabled because its output lacks a linefeed
which makes xend.log look ugly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6d1d516ecaad -r d76b38b79929 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
 int
 main(int argc, char **argv)
 {
-    unsigned int maxit, max_f;
+    unsigned int maxit, max_f, lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    xentoollog_level lvl;
+    xentoollog_logger *l;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
 
-    si.xch = xc_interface_open(0,0,0);
-    if (!si.xch)
-        errx(1, "failed to open control interface");
-
     io_fd = atoi(argv[1]);
     si.domid = atoi(argv[2]);
     maxit = atoi(argv[3]);
@@ -185,6 +183,13 @@ main(int argc, char **argv)
 
     si.suspend_evtchn = -1;
 
+    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
+    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
+    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
+    si.xch = xc_interface_open(l, 0, 0);
+    if (!si.xch)
+        errx(1, "failed to open control interface");
+
     si.xce = xc_evtchn_open(NULL, 0);
     if (si.xce == NULL)
         warnx("failed to open event channel handle");

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 18:58:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 18:58: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 1U1Lof-0000ps-KY; Fri, 01 Feb 2013 18:58:25 +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 1U1Lod-0000pn-Sn
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 18:58:24 +0000
Received: from [85.158.138.51:13951] by server-10.bemta-3.messagelabs.com id
	94/33-10609-F401C015; Fri, 01 Feb 2013 18:58:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1359745101!28863715!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5Mzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30890 invoked from network); 1 Feb 2013 18:58:21 -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; 1 Feb 2013 18:58:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiS0ME4tB
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-087-200.pools.arcor-ip.net [88.65.87.200])
	by smtp.strato.de (josoe mo45) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 602409p11IlLhi
	for <xen-devel@lists.xen.org>; Fri, 1 Feb 2013 19:58:21 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DB7EE1863D
	for <xen-devel@lists.xen.org>; Fri,  1 Feb 2013 19:58:20 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d76b38b799293ff17fed8eaaac8fbbebced1b72f
Message-Id: <d76b38b799293ff17fed.1359745100@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Fri, 01 Feb 2013 19:58:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1359745022 -3600
# Node ID d76b38b799293ff17fed8eaaac8fbbebced1b72f
# Parent  6d1d516ecaade56f796e3216e9931fdcc12282cd
tools/xc: restore logging in xc_save

Prior to xen-4.1 the helper xc_save would print some progress during
migration. With the new xc_interface_open API no more messages were
printed because no logger was configured.

Restore previous behaviour by providing a logger. The progress in
xc_domain_save will be disabled because its output lacks a linefeed
which makes xend.log look ugly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6d1d516ecaad -r d76b38b79929 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
 int
 main(int argc, char **argv)
 {
-    unsigned int maxit, max_f;
+    unsigned int maxit, max_f, lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    xentoollog_level lvl;
+    xentoollog_logger *l;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
 
-    si.xch = xc_interface_open(0,0,0);
-    if (!si.xch)
-        errx(1, "failed to open control interface");
-
     io_fd = atoi(argv[1]);
     si.domid = atoi(argv[2]);
     maxit = atoi(argv[3]);
@@ -185,6 +183,13 @@ main(int argc, char **argv)
 
     si.suspend_evtchn = -1;
 
+    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
+    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
+    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
+    si.xch = xc_interface_open(l, 0, 0);
+    if (!si.xch)
+        errx(1, "failed to open control interface");
+
     si.xce = xc_evtchn_open(NULL, 0);
     if (si.xce == NULL)
         warnx("failed to open event channel handle");

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 19:28:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 19:28: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 1U1MHh-0001Dd-Sa; Fri, 01 Feb 2013 19:28:25 +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 1U1MHh-0001DV-3f
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 19:28:25 +0000
Received: from [85.158.139.211:37668] by server-12.bemta-5.messagelabs.com id
	72/66-20195-8571C015; Fri, 01 Feb 2013 19:28:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1359746902!19041570!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk5NTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7517 invoked from network); 1 Feb 2013 19:28:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 19:28:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r11JRJ1s018180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 19:27:20 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
	r11JRIp9016587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 19:27:19 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
	r11JRIhs008544; Fri, 1 Feb 2013 13:27:18 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 01 Feb 2013 11:27:18 -0800
Date: Fri, 1 Feb 2013 11:27:16 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <jbeulich@suse.com>
Message-ID: <20130201112716.4d63716c@mantra.us.oracle.com>
In-Reply-To: <510BEC590200007800094177@nat28.tlf.novell.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.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]
Cc: konrad@kernel.org, konrad.wilk@oracle.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 01 Feb 2013 16:24:57 +0000
"Jan Beulich" <jbeulich@suse.com> wrote:

> >>> Mukesh Rathor <mukesh.rathor@oracle.com> 02/01/13 3:23 AM >>>
> >On Tue, 29 Jan 2013 10:48:12 +0000 "Jan Beulich" <JBeulich@suse.com>
> >wrote:
> >> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> >>> wrote:
> >> difficult, but I continue to see more advantage in avoiding the
> >> redundancy).
> >
> >That was my patch version 2, where I called it gdt and another
> >reviewer suggested to change to u. So I changed it to u.
> >
> >It's gone thru enough iterations that I'd like to leave as is. Thank
> >you in advance for your compromise in helping us mortals grep/cscope 
> >to learn code.
> 
> That's part of the reason why I said from the beginning that doing
> the Linux side first is wrong.

It was reviewed by xen folks like Ian C, Stefano, etc... 

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 Feb 01 19:28:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 19:28: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 1U1MHh-0001Dd-Sa; Fri, 01 Feb 2013 19:28:25 +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 1U1MHh-0001DV-3f
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 19:28:25 +0000
Received: from [85.158.139.211:37668] by server-12.bemta-5.messagelabs.com id
	72/66-20195-8571C015; Fri, 01 Feb 2013 19:28:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1359746902!19041570!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTk5NTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7517 invoked from network); 1 Feb 2013 19:28:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 19:28:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r11JRJ1s018180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 19:27:20 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
	r11JRIp9016587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 19:27:19 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
	r11JRIhs008544; Fri, 1 Feb 2013 13:27:18 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 01 Feb 2013 11:27:18 -0800
Date: Fri, 1 Feb 2013 11:27:16 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <jbeulich@suse.com>
Message-ID: <20130201112716.4d63716c@mantra.us.oracle.com>
In-Reply-To: <510BEC590200007800094177@nat28.tlf.novell.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.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]
Cc: konrad@kernel.org, konrad.wilk@oracle.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 01 Feb 2013 16:24:57 +0000
"Jan Beulich" <jbeulich@suse.com> wrote:

> >>> Mukesh Rathor <mukesh.rathor@oracle.com> 02/01/13 3:23 AM >>>
> >On Tue, 29 Jan 2013 10:48:12 +0000 "Jan Beulich" <JBeulich@suse.com>
> >wrote:
> >> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> >>> wrote:
> >> difficult, but I continue to see more advantage in avoiding the
> >> redundancy).
> >
> >That was my patch version 2, where I called it gdt and another
> >reviewer suggested to change to u. So I changed it to u.
> >
> >It's gone thru enough iterations that I'd like to leave as is. Thank
> >you in advance for your compromise in helping us mortals grep/cscope 
> >to learn code.
> 
> That's part of the reason why I said from the beginning that doing
> the Linux side first is wrong.

It was reviewed by xen folks like Ian C, Stefano, etc... 

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 Feb 01 19:35:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 19: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 1U1MNo-0001VX-Mv; Fri, 01 Feb 2013 19:34:44 +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 1U1MNn-0001VP-P3
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 19:34:44 +0000
Received: from [193.109.254.147:58761] by server-7.bemta-14.messagelabs.com id
	29/7B-13581-2D81C015; Fri, 01 Feb 2013 19:34:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1359747279!8930133!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NDkwODg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NDkwODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11689 invoked from network); 1 Feb 2013 19:34:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 19:34:39 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiS0ME4tB
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-087-200.pools.arcor-ip.net [88.65.87.200])
	by smtp.strato.de (josoe mo7) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601a8bp11JOm3J
	for <xen-devel@lists.xen.org>; Fri, 1 Feb 2013 20:34:38 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DFF0B1863D
	for <xen-devel@lists.xen.org>; Fri,  1 Feb 2013 20:34:35 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 785c8f34e1f802106e53ca4d2c54dce55c8ee166
Message-Id: <785c8f34e1f802106e53.1359747275@probook.site>
In-Reply-To: <577b051fca174be9f7b3.1359394360@probook.site>
References: <577b051fca174be9f7b3.1359394360@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Fri, 01 Feb 2013 20:34:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v4] tools: set migration constraints from cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1359746832 -3600
# Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
# Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
tools: set migration constraints from cmdline

Add new options to xm/xl migrate to control the process of migration.
The intention is to optionally abort the migration if it takes too long
to migrate a busy guest due to the high number of dirty pages. Currently
the guest is suspended to transfer the remaining dirty pages. This
transfer can take too long, which can confuse the guest if its suspended
for too long.

-M <number>   Number of iterations before final suspend (default: 30)
--max_iters <number>

-m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
--max_factor <factor>

-N            Abort migration instead of doing final suspend.
--no_suspend



The changes to libxl change the API, is that approach acceptable?

v4:
 - update default for no_suspend from None to 0 in XendCheckpoint.py:save
 - update logoutput in setMigrateConstraints
 - change xm migrate defaults from None to 0
 - add new options to xl.1
 - fix syntax error in XendDomain.py:domain_migrate_constraints_set
 - fix xm migrate -N option name to match xl migrate

v3:
 - move logic errors in libxl__domain_suspend and fixed help text in
   cmd_table to separate patches
 - fix syntax error in XendCheckpoint.py
 - really pass max_iters and max_factor in libxl__xc_domain_save
 - make libxl_domain_suspend_0x040200 declaration globally visible
 - bump libxenlight.so SONAME from 2.0 to 2.1 due to changed
   libxl_domain_suspend

v2:
 - use LIBXL_API_VERSION and define libxl_domain_suspend_0x040200
 - fix logic error in min_reached check in xc_domain_save
 - add longopts
 - update --help text
 - correct description of migrate --help text

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r fd711ebdce9a -r 785c8f34e1f8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -391,6 +391,18 @@ Send <config> instead of config file fro
 
 Print huge (!) amount of debug during the migration process.
 
+=item B<-M> I<number>, B<--max_iters> I<number>
+
+Number of iterations before final suspend (default: 30)
+
+=item B<-m> I<factor>, B<--max_factor> I<factor>
+
+Max amount of memory to transfer before final suspend (default: 3*RAM)
+
+=item B<-N>, B<--no_suspend>
+
+Abort migration instead of doing final suspend.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -43,6 +43,8 @@
 */
 #define DEF_MAX_ITERS   29   /* limit us to 30 times round loop   */
 #define DEF_MAX_FACTOR   3   /* never send more than 3x p2m_size  */
+/* Suspend guest for final transit once number of dirty pages is that low */
+#define DEF_MIN_REMAINING 50
 
 struct save_ctx {
     unsigned long hvirt_start; /* virtual starting address of the hypervisor */
@@ -804,6 +806,7 @@ int xc_domain_save(xc_interface *xch, in
     int rc = 1, frc, i, j, last_iter = 0, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
+    int no_suspend = (flags & XCFLAGS_DOMSAVE_NOSUSPEND);
     int superpages = !!hvm;
     int race = 0, sent_last_iter, skip_this_iter = 0;
     unsigned int sent_this_iter = 0;
@@ -1525,10 +1528,20 @@ int xc_domain_save(xc_interface *xch, in
 
         if ( live )
         {
+            int min_reached = sent_this_iter + skip_this_iter < DEF_MIN_REMAINING;
             if ( (iter >= max_iters) ||
-                 (sent_this_iter+skip_this_iter < 50) ||
+                 min_reached ||
                  (total_sent > dinfo->p2m_size*max_factor) )
             {
+                if ( !min_reached && no_suspend )
+                {
+                    ERROR("Live migration aborted, as requested. (guest too busy?)"
+                     " total_sent %lu iter %d, max_iters %u max_factor %u",
+                      total_sent, iter, max_iters, max_factor);
+                    rc = 1;
+                    goto out;
+                }
+
                 DPRINTF("Start last iteration\n");
                 last_iter = 1;
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -28,6 +28,8 @@
 #define XCFLAGS_HVM       4
 #define XCFLAGS_STDVGA    8
 #define XCFLAGS_CHECKPOINT_COMPRESS    16
+#define XCFLAGS_DOMSAVE_NOSUSPEND      32
+
 #define X86_64_B_SIZE   64 
 #define X86_32_B_SIZE   32
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -5,7 +5,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR = 2.0
+MAJOR = 2.1
 MINOR = 0
 
 XLUMAJOR = 1.0
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -756,7 +756,8 @@ static void domain_suspend_cb(libxl__egc
 
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+static int __libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, int max_iters, int max_factor,
                          const libxl_asyncop_how *ao_how)
 {
     AO_CREATE(ctx, domid, ao_how);
@@ -779,6 +780,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     dss->type = type;
     dss->live = flags & LIBXL_SUSPEND_LIVE;
     dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+    dss->max_iters = max_iters;
+    dss->max_factor = max_factor;
+    dss->xlflags = flags;
 
     libxl__domain_suspend(egc, dss);
     return AO_INPROGRESS;
@@ -787,6 +791,20 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     return AO_ABORT(rc);
 }
 
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, const libxl_asyncop_how *ao_how)
+{
+	return __libxl_domain_suspend(ctx, domid, fd, flags, 0,0, ao_how);
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         int max_iters, int max_factor,
+                         const libxl_asyncop_how *ao_how)
+{
+	return __libxl_domain_suspend(ctx, domid, fd, flags, max_iters,
+                                      max_factor, ao_how);
+}
+
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
 {
     int ret;
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
 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, uint32_t domid, int fd,
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
+#ifdef LIBXL_API_VERSION
+#if LIBXL_API_VERSION == 0x040200
+#define libxl_domain_suspend libxl_domain_suspend_0x040200
+#endif
+#else
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         int max_iters, int max_factor,
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
+#endif
+
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
+#define LIBXL_SUSPEND_NO_FINAL_SUSPEND 4
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
 
     dss->xcflags = (live ? XCFLAGS_LIVE : 0)
           | (debug ? XCFLAGS_DEBUG : 0)
+          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
           | (dss->hvm ? XCFLAGS_HVM : 0);
 
     dss->suspend_eventchn = -1;
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2253,6 +2253,9 @@ struct libxl__domain_suspend_state {
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
     int hvm;
+    int max_iters;
+    int max_factor;
+    int xlflags;
     int xcflags;
     int guest_responded;
     const char *dm_savefile;
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_save_callout.c
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -108,8 +108,8 @@ void libxl__xc_domain_save(libxl__egc *e
     }
 
     const unsigned long argnums[] = {
-        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
-        toolstack_data_fd, toolstack_data_len,
+        dss->domid, dss->max_iters, dss->max_factor, dss->xcflags, dss->hvm,
+        vm_generationid_addr, toolstack_data_fd, toolstack_data_len,
         cbflags,
     };
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
+    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);
     close(fd);
 
     if (rc < 0)
@@ -3332,6 +3332,7 @@ static void migrate_do_preamble(int send
 }
 
 static void migrate_domain(uint32_t domid, const char *rune, int debug,
+                           int max_iters, int max_factor, int no_suspend,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3360,7 +3361,10 @@ static void migrate_domain(uint32_t domi
 
     if (debug)
         flags |= LIBXL_SUSPEND_DEBUG;
-    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
+    if (no_suspend)
+        flags |= LIBXL_SUSPEND_NO_FINAL_SUSPEND;
+
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, max_iters, max_factor, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3753,8 +3757,16 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    int max_iters = 0, max_factor = 0, no_suspend = 0;
+    static struct option opts[] = {
+        {"max_iters", 1, 0, 'M'},
+        {"max_factor", 1, 0, 'm'},
+        {"no_suspend", 0, 0, 'N'},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:edM:m:N", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3771,6 +3783,15 @@ int main_migrate(int argc, char **argv)
     case 'd':
         debug = 1;
         break;
+    case 'M':
+        max_iters = atoi(optarg);
+        break;
+    case 'm':
+        max_factor = atoi(optarg);
+        break;
+    case 'N':
+        no_suspend = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -3786,7 +3807,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, debug, config_filename);
+    migrate_domain(domid, rune, debug, max_iters, max_factor, no_suspend, config_filename);
     return 0;
 }
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -147,14 +147,19 @@ struct cmd_spec cmd_table[] = {
       &main_migrate, 0, 1,
       "Migrate a domain to another host",
       "[options] <Domain> <host>",
-      "-h              Print this help.\n"
-      "-C <config>     Send <config> instead of config file from creation.\n"
-      "-s <sshcommand> Use <sshcommand> instead of ssh.  String will be passed\n"
-      "                to sh. If empty, run <host> instead of ssh <host> xl\n"
-      "                migrate-receive [-d -e]\n"
-      "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain.\n"
-      "-d              Print huge (!) amount of debug during the migration process."
+      "-h               Print this help.\n"
+      "-C <config>      Send <config> instead of config file from creation.\n"
+      "-s <sshcommand>  Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                 to sh. If empty, run <host> instead of ssh <host> xl\n"
+      "                 migrate-receive [-d -e]\n"
+      "-e               Do not wait in the background (on <host>) for the death\n"
+      "                 of the domain.\n"
+      "-d               Print huge (!) amount of debug during the migration process.\n"
+      "-M <number>      Number of iterations before final suspend (default: 30)\n"
+      "--max_iters <number>\n"
+      "-m <factor>      Max amount of memory to transfer before final suspend (default: 3*RAM).\n"
+      "--max_factor <factor>\n"
+      "-N, --no_suspend Abort migration instead of doing final suspend."
     },
     { "dump-core",
       &main_dump_core, 0, 1,
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendCheckpoint.py
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -118,9 +118,19 @@ def save(fd, dominfo, network, live, dst
         # enabled. Passing "0" simply uses the defaults compiled into
         # libxenguest; see the comments and/or code in xc_linux_save() for
         # more information.
+        max_iters = dominfo.info.get('max_iters', "0")
+        max_factor = dominfo.info.get('max_factor', "0")
+        no_suspend = dominfo.info.get('no_suspend', "0")
+        if max_iters == "None":
+            max_iters = "0"
+        if max_factor == "None":
+            max_factor = "0"
+        if no_suspend == "None":
+            no_suspend = "0"
         cmd = [xen.util.auxbin.pathTo(XC_SAVE), str(fd),
-               str(dominfo.getDomid()), "0", "0", 
-               str(int(live) | (int(hvm) << 2)) ]
+               str(dominfo.getDomid()),
+               max_iters, max_factor,
+               str(int(live) | (int(hvm) << 2) | (int(no_suspend) << 5)) ]
         log.debug("[xc_save]: %s", string.join(cmd))
 
         def saveInputHandler(line, tochild):
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py
+++ b/tools/python/xen/xend/XendDomain.py
@@ -1832,6 +1832,18 @@ class XendDomain:
             log.exception(ex)
             raise XendError(str(ex))
 
+    def domain_migrate_constraints_set(self, domid, max_iters, max_factor, no_suspend):
+        """Set the Migrate Constraints of this domain.
+        @param domid: Domain ID or Name
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param no_suspend: Abort migration instead of doing final suspend
+        """
+        dominfo = self.domain_lookup_nr(domid)
+        if not dominfo:
+            raise XendInvalidDomain(str(domid))
+        dominfo.setMigrateConstraints(max_iters, max_factor, no_suspend)
+
     def domain_maxmem_set(self, domid, mem):
         """Set the memory limit for a domain.
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -1459,6 +1459,18 @@ class XendDomainInfo:
         pci_conf = self.info['devices'][dev_uuid][1]
         return map(pci_dict_to_bdf_str, pci_conf['devs'])
 
+    def setMigrateConstraints(self, max_iters, max_factor, no_suspend):
+        """Set the Migrate Constraints of this domain.
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param no_suspend: Abort migration instead of doing final suspend
+        """
+        log.debug("Setting migration constraints of domain %s (%s) to '%s' '%s' '%s'.",
+                  self.info['name_label'], str(self.domid), max_iters, max_factor, no_suspend)
+        self.info['max_iters'] = str(max_iters)
+        self.info['max_factor'] = str(max_factor)
+        self.info['no_suspend'] = str(no_suspend)
+
     def setMemoryTarget(self, target):
         """Set the memory target of this domain.
         @param target: In MiB.
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xm/migrate.py
--- a/tools/python/xen/xm/migrate.py
+++ b/tools/python/xen/xm/migrate.py
@@ -55,6 +55,18 @@ gopts.opt('change_home_server', short='c
           fn=set_true, default=0,
           use="Change home server for managed domains.")
 
+gopts.opt('max_iters', short='M', val='max_iters',
+          fn=set_int, default=0,
+          use="Number of iterations before final suspend (default: 30).")
+
+gopts.opt('max_factor', short='m', val='max_factor',
+          fn=set_int, default=0,
+          use="Max amount of memory to transfer before final suspend (default: 3*RAM).")
+
+gopts.opt('no_suspend', short='N',
+          fn=set_true, default=0,
+          use="Abort migration instead of doing final suspend.")
+
 def help():
     return str(gopts)
     
@@ -80,6 +92,10 @@ def main(argv):
         server.xenapi.VM.migrate(vm_ref, dst, bool(opts.vals.live),
                                  other_config)
     else:
+        server.xend.domain.migrate_constraints_set(dom,
+                                                   opts.vals.max_iters,
+                                                   opts.vals.max_factor,
+                                                   opts.vals.no_suspend)
         server.xend.domain.migrate(dom, dst, opts.vals.live,
                                    opts.vals.port,
                                    opts.vals.node,

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 19:35:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 19: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 1U1MNo-0001VX-Mv; Fri, 01 Feb 2013 19:34:44 +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 1U1MNn-0001VP-P3
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 19:34:44 +0000
Received: from [193.109.254.147:58761] by server-7.bemta-14.messagelabs.com id
	29/7B-13581-2D81C015; Fri, 01 Feb 2013 19:34:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1359747279!8930133!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NDkwODg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NDkwODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11689 invoked from network); 1 Feb 2013 19:34:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 19:34:39 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiS0ME4tB
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-087-200.pools.arcor-ip.net [88.65.87.200])
	by smtp.strato.de (josoe mo7) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601a8bp11JOm3J
	for <xen-devel@lists.xen.org>; Fri, 1 Feb 2013 20:34:38 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DFF0B1863D
	for <xen-devel@lists.xen.org>; Fri,  1 Feb 2013 20:34:35 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 785c8f34e1f802106e53ca4d2c54dce55c8ee166
Message-Id: <785c8f34e1f802106e53.1359747275@probook.site>
In-Reply-To: <577b051fca174be9f7b3.1359394360@probook.site>
References: <577b051fca174be9f7b3.1359394360@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Fri, 01 Feb 2013 20:34:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v4] tools: set migration constraints from cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1359746832 -3600
# Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
# Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
tools: set migration constraints from cmdline

Add new options to xm/xl migrate to control the process of migration.
The intention is to optionally abort the migration if it takes too long
to migrate a busy guest due to the high number of dirty pages. Currently
the guest is suspended to transfer the remaining dirty pages. This
transfer can take too long, which can confuse the guest if its suspended
for too long.

-M <number>   Number of iterations before final suspend (default: 30)
--max_iters <number>

-m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
--max_factor <factor>

-N            Abort migration instead of doing final suspend.
--no_suspend



The changes to libxl change the API, is that approach acceptable?

v4:
 - update default for no_suspend from None to 0 in XendCheckpoint.py:save
 - update logoutput in setMigrateConstraints
 - change xm migrate defaults from None to 0
 - add new options to xl.1
 - fix syntax error in XendDomain.py:domain_migrate_constraints_set
 - fix xm migrate -N option name to match xl migrate

v3:
 - move logic errors in libxl__domain_suspend and fixed help text in
   cmd_table to separate patches
 - fix syntax error in XendCheckpoint.py
 - really pass max_iters and max_factor in libxl__xc_domain_save
 - make libxl_domain_suspend_0x040200 declaration globally visible
 - bump libxenlight.so SONAME from 2.0 to 2.1 due to changed
   libxl_domain_suspend

v2:
 - use LIBXL_API_VERSION and define libxl_domain_suspend_0x040200
 - fix logic error in min_reached check in xc_domain_save
 - add longopts
 - update --help text
 - correct description of migrate --help text

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r fd711ebdce9a -r 785c8f34e1f8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -391,6 +391,18 @@ Send <config> instead of config file fro
 
 Print huge (!) amount of debug during the migration process.
 
+=item B<-M> I<number>, B<--max_iters> I<number>
+
+Number of iterations before final suspend (default: 30)
+
+=item B<-m> I<factor>, B<--max_factor> I<factor>
+
+Max amount of memory to transfer before final suspend (default: 3*RAM)
+
+=item B<-N>, B<--no_suspend>
+
+Abort migration instead of doing final suspend.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -43,6 +43,8 @@
 */
 #define DEF_MAX_ITERS   29   /* limit us to 30 times round loop   */
 #define DEF_MAX_FACTOR   3   /* never send more than 3x p2m_size  */
+/* Suspend guest for final transit once number of dirty pages is that low */
+#define DEF_MIN_REMAINING 50
 
 struct save_ctx {
     unsigned long hvirt_start; /* virtual starting address of the hypervisor */
@@ -804,6 +806,7 @@ int xc_domain_save(xc_interface *xch, in
     int rc = 1, frc, i, j, last_iter = 0, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
+    int no_suspend = (flags & XCFLAGS_DOMSAVE_NOSUSPEND);
     int superpages = !!hvm;
     int race = 0, sent_last_iter, skip_this_iter = 0;
     unsigned int sent_this_iter = 0;
@@ -1525,10 +1528,20 @@ int xc_domain_save(xc_interface *xch, in
 
         if ( live )
         {
+            int min_reached = sent_this_iter + skip_this_iter < DEF_MIN_REMAINING;
             if ( (iter >= max_iters) ||
-                 (sent_this_iter+skip_this_iter < 50) ||
+                 min_reached ||
                  (total_sent > dinfo->p2m_size*max_factor) )
             {
+                if ( !min_reached && no_suspend )
+                {
+                    ERROR("Live migration aborted, as requested. (guest too busy?)"
+                     " total_sent %lu iter %d, max_iters %u max_factor %u",
+                      total_sent, iter, max_iters, max_factor);
+                    rc = 1;
+                    goto out;
+                }
+
                 DPRINTF("Start last iteration\n");
                 last_iter = 1;
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -28,6 +28,8 @@
 #define XCFLAGS_HVM       4
 #define XCFLAGS_STDVGA    8
 #define XCFLAGS_CHECKPOINT_COMPRESS    16
+#define XCFLAGS_DOMSAVE_NOSUSPEND      32
+
 #define X86_64_B_SIZE   64 
 #define X86_32_B_SIZE   32
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -5,7 +5,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR = 2.0
+MAJOR = 2.1
 MINOR = 0
 
 XLUMAJOR = 1.0
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -756,7 +756,8 @@ static void domain_suspend_cb(libxl__egc
 
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+static int __libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, int max_iters, int max_factor,
                          const libxl_asyncop_how *ao_how)
 {
     AO_CREATE(ctx, domid, ao_how);
@@ -779,6 +780,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     dss->type = type;
     dss->live = flags & LIBXL_SUSPEND_LIVE;
     dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+    dss->max_iters = max_iters;
+    dss->max_factor = max_factor;
+    dss->xlflags = flags;
 
     libxl__domain_suspend(egc, dss);
     return AO_INPROGRESS;
@@ -787,6 +791,20 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     return AO_ABORT(rc);
 }
 
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, const libxl_asyncop_how *ao_how)
+{
+	return __libxl_domain_suspend(ctx, domid, fd, flags, 0,0, ao_how);
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
+                         int max_iters, int max_factor,
+                         const libxl_asyncop_how *ao_how)
+{
+	return __libxl_domain_suspend(ctx, domid, fd, flags, max_iters,
+                                      max_factor, ao_how);
+}
+
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
 {
     int ret;
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
 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, uint32_t domid, int fd,
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, /* LIBXL_SUSPEND_* */
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
+#ifdef LIBXL_API_VERSION
+#if LIBXL_API_VERSION == 0x040200
+#define libxl_domain_suspend libxl_domain_suspend_0x040200
+#endif
+#else
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, /* LIBXL_SUSPEND_* */
+                         int max_iters, int max_factor,
+                         const libxl_asyncop_how *ao_how)
+                         LIBXL_EXTERNAL_CALLERS_ONLY;
+#endif
+
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
+#define LIBXL_SUSPEND_NO_FINAL_SUSPEND 4
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
 
     dss->xcflags = (live ? XCFLAGS_LIVE : 0)
           | (debug ? XCFLAGS_DEBUG : 0)
+          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
           | (dss->hvm ? XCFLAGS_HVM : 0);
 
     dss->suspend_eventchn = -1;
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2253,6 +2253,9 @@ struct libxl__domain_suspend_state {
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
     int hvm;
+    int max_iters;
+    int max_factor;
+    int xlflags;
     int xcflags;
     int guest_responded;
     const char *dm_savefile;
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_save_callout.c
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -108,8 +108,8 @@ void libxl__xc_domain_save(libxl__egc *e
     }
 
     const unsigned long argnums[] = {
-        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
-        toolstack_data_fd, toolstack_data_len,
+        dss->domid, dss->max_iters, dss->max_factor, dss->xcflags, dss->hvm,
+        vm_generationid_addr, toolstack_data_fd, toolstack_data_len,
         cbflags,
     };
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
+    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);
     close(fd);
 
     if (rc < 0)
@@ -3332,6 +3332,7 @@ static void migrate_do_preamble(int send
 }
 
 static void migrate_domain(uint32_t domid, const char *rune, int debug,
+                           int max_iters, int max_factor, int no_suspend,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3360,7 +3361,10 @@ static void migrate_domain(uint32_t domi
 
     if (debug)
         flags |= LIBXL_SUSPEND_DEBUG;
-    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
+    if (no_suspend)
+        flags |= LIBXL_SUSPEND_NO_FINAL_SUSPEND;
+
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, max_iters, max_factor, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3753,8 +3757,16 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    int max_iters = 0, max_factor = 0, no_suspend = 0;
+    static struct option opts[] = {
+        {"max_iters", 1, 0, 'M'},
+        {"max_factor", 1, 0, 'm'},
+        {"no_suspend", 0, 0, 'N'},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:edM:m:N", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3771,6 +3783,15 @@ int main_migrate(int argc, char **argv)
     case 'd':
         debug = 1;
         break;
+    case 'M':
+        max_iters = atoi(optarg);
+        break;
+    case 'm':
+        max_factor = atoi(optarg);
+        break;
+    case 'N':
+        no_suspend = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -3786,7 +3807,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, debug, config_filename);
+    migrate_domain(domid, rune, debug, max_iters, max_factor, no_suspend, config_filename);
     return 0;
 }
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -147,14 +147,19 @@ struct cmd_spec cmd_table[] = {
       &main_migrate, 0, 1,
       "Migrate a domain to another host",
       "[options] <Domain> <host>",
-      "-h              Print this help.\n"
-      "-C <config>     Send <config> instead of config file from creation.\n"
-      "-s <sshcommand> Use <sshcommand> instead of ssh.  String will be passed\n"
-      "                to sh. If empty, run <host> instead of ssh <host> xl\n"
-      "                migrate-receive [-d -e]\n"
-      "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain.\n"
-      "-d              Print huge (!) amount of debug during the migration process."
+      "-h               Print this help.\n"
+      "-C <config>      Send <config> instead of config file from creation.\n"
+      "-s <sshcommand>  Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                 to sh. If empty, run <host> instead of ssh <host> xl\n"
+      "                 migrate-receive [-d -e]\n"
+      "-e               Do not wait in the background (on <host>) for the death\n"
+      "                 of the domain.\n"
+      "-d               Print huge (!) amount of debug during the migration process.\n"
+      "-M <number>      Number of iterations before final suspend (default: 30)\n"
+      "--max_iters <number>\n"
+      "-m <factor>      Max amount of memory to transfer before final suspend (default: 3*RAM).\n"
+      "--max_factor <factor>\n"
+      "-N, --no_suspend Abort migration instead of doing final suspend."
     },
     { "dump-core",
       &main_dump_core, 0, 1,
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendCheckpoint.py
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -118,9 +118,19 @@ def save(fd, dominfo, network, live, dst
         # enabled. Passing "0" simply uses the defaults compiled into
         # libxenguest; see the comments and/or code in xc_linux_save() for
         # more information.
+        max_iters = dominfo.info.get('max_iters', "0")
+        max_factor = dominfo.info.get('max_factor', "0")
+        no_suspend = dominfo.info.get('no_suspend', "0")
+        if max_iters == "None":
+            max_iters = "0"
+        if max_factor == "None":
+            max_factor = "0"
+        if no_suspend == "None":
+            no_suspend = "0"
         cmd = [xen.util.auxbin.pathTo(XC_SAVE), str(fd),
-               str(dominfo.getDomid()), "0", "0", 
-               str(int(live) | (int(hvm) << 2)) ]
+               str(dominfo.getDomid()),
+               max_iters, max_factor,
+               str(int(live) | (int(hvm) << 2) | (int(no_suspend) << 5)) ]
         log.debug("[xc_save]: %s", string.join(cmd))
 
         def saveInputHandler(line, tochild):
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py
+++ b/tools/python/xen/xend/XendDomain.py
@@ -1832,6 +1832,18 @@ class XendDomain:
             log.exception(ex)
             raise XendError(str(ex))
 
+    def domain_migrate_constraints_set(self, domid, max_iters, max_factor, no_suspend):
+        """Set the Migrate Constraints of this domain.
+        @param domid: Domain ID or Name
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param no_suspend: Abort migration instead of doing final suspend
+        """
+        dominfo = self.domain_lookup_nr(domid)
+        if not dominfo:
+            raise XendInvalidDomain(str(domid))
+        dominfo.setMigrateConstraints(max_iters, max_factor, no_suspend)
+
     def domain_maxmem_set(self, domid, mem):
         """Set the memory limit for a domain.
 
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -1459,6 +1459,18 @@ class XendDomainInfo:
         pci_conf = self.info['devices'][dev_uuid][1]
         return map(pci_dict_to_bdf_str, pci_conf['devs'])
 
+    def setMigrateConstraints(self, max_iters, max_factor, no_suspend):
+        """Set the Migrate Constraints of this domain.
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param no_suspend: Abort migration instead of doing final suspend
+        """
+        log.debug("Setting migration constraints of domain %s (%s) to '%s' '%s' '%s'.",
+                  self.info['name_label'], str(self.domid), max_iters, max_factor, no_suspend)
+        self.info['max_iters'] = str(max_iters)
+        self.info['max_factor'] = str(max_factor)
+        self.info['no_suspend'] = str(no_suspend)
+
     def setMemoryTarget(self, target):
         """Set the memory target of this domain.
         @param target: In MiB.
diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xm/migrate.py
--- a/tools/python/xen/xm/migrate.py
+++ b/tools/python/xen/xm/migrate.py
@@ -55,6 +55,18 @@ gopts.opt('change_home_server', short='c
           fn=set_true, default=0,
           use="Change home server for managed domains.")
 
+gopts.opt('max_iters', short='M', val='max_iters',
+          fn=set_int, default=0,
+          use="Number of iterations before final suspend (default: 30).")
+
+gopts.opt('max_factor', short='m', val='max_factor',
+          fn=set_int, default=0,
+          use="Max amount of memory to transfer before final suspend (default: 3*RAM).")
+
+gopts.opt('no_suspend', short='N',
+          fn=set_true, default=0,
+          use="Abort migration instead of doing final suspend.")
+
 def help():
     return str(gopts)
     
@@ -80,6 +92,10 @@ def main(argv):
         server.xenapi.VM.migrate(vm_ref, dst, bool(opts.vals.live),
                                  other_config)
     else:
+        server.xend.domain.migrate_constraints_set(dom,
+                                                   opts.vals.max_iters,
+                                                   opts.vals.max_factor,
+                                                   opts.vals.no_suspend)
         server.xend.domain.migrate(dom, dst, opts.vals.live,
                                    opts.vals.port,
                                    opts.vals.node,

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20: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 1U1N1c-0001va-50; Fri, 01 Feb 2013 20:15:52 +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 1U1N1a-0001vV-PV
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:15:50 +0000
Received: from [85.158.137.99:64106] by server-14.bemta-3.messagelabs.com id
	51/30-23533-5722C015; Fri, 01 Feb 2013 20:15:49 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1359749747!17274459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6625 invoked from network); 1 Feb 2013 20:15:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:15:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5712186"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:15:47 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:15:46 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:15:44 -0500
Thread-Topic: [Xen-devel] [PATCH v2 00/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuIq+JBfq0UfhQJiKd1cjlLiHMA==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E4@FTLPMAILBOX02.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] [PATCH v2 00/03] HVM firmware passthrough libxl 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

This patch series is a follow-up to the earlier HVM firmware passthrough
patch set. It introduces support in libxl for specifying and loading the
ACPI and SMBIOS firmware blobs that are passed to libxc.  

There are 3 patches in the series:
01 - Switch xl to use the new xc_hvm_build() libxc API.
02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
     Doc changes to the man page for xl.cfg describing the new params.
03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

(Based on xen-4.3 staging/unstable cs 26502)


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20: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 1U1N1c-0001va-50; Fri, 01 Feb 2013 20:15:52 +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 1U1N1a-0001vV-PV
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:15:50 +0000
Received: from [85.158.137.99:64106] by server-14.bemta-3.messagelabs.com id
	51/30-23533-5722C015; Fri, 01 Feb 2013 20:15:49 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1359749747!17274459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6625 invoked from network); 1 Feb 2013 20:15:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:15:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5712186"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:15:47 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:15:46 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:15:44 -0500
Thread-Topic: [Xen-devel] [PATCH v2 00/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuIq+JBfq0UfhQJiKd1cjlLiHMA==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E4@FTLPMAILBOX02.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] [PATCH v2 00/03] HVM firmware passthrough libxl 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

This patch series is a follow-up to the earlier HVM firmware passthrough
patch set. It introduces support in libxl for specifying and loading the
ACPI and SMBIOS firmware blobs that are passed to libxc.  

There are 3 patches in the series:
01 - Switch xl to use the new xc_hvm_build() libxc API.
02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
     Doc changes to the man page for xl.cfg describing the new params.
03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

(Based on xen-4.3 staging/unstable cs 26502)


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20: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 1U1N1o-0001wX-ON; Fri, 01 Feb 2013 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 <Ross.Philipson@citrix.com>) id 1U1N1n-0001wS-La
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:16:03 +0000
Received: from [85.158.138.51:65367] by server-10.bemta-3.messagelabs.com id
	87/E3-10609-2822C015; Fri, 01 Feb 2013 20:16:02 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1359749760!22521918!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31149 invoked from network); 1 Feb 2013 20:16:01 -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;
	1 Feb 2013 20:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="sf'?scan'208";a="5712204"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:16:00 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:15:59 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:15:57 -0500
Thread-Topic: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuJRfUKlqHGJMQneo30DCkrYerQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Switch libxl to use the new xc_hvm_build() libxc API.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: application/octet-stream;
	name="hvm-firmware-passthrough-libxl-v2-01.patch"
Content-Description: hvm-firmware-passthrough-libxl-v2-01.patch
Content-Disposition: attachment;
	filename="hvm-firmware-passthrough-libxl-v2-01.patch"; size=1502;
	creation-date="Fri, 01 Feb 2013 19:55:13 GMT";
	modification-date="Fri, 01 Feb 2013 19:55:13 GMT"
Content-Transfer-Encoding: base64

U3dpdGNoIGxpYnhsIHRvIHVzZSB0aGUgbmV3IHhjX2h2bV9idWlsZCgpIGxpYnhjIEFQSS4KClNp
Z25lZC1vZmYtYnk6IFJvc3MgUGhpbGlwc29uIDxyb3NzLnBoaWxpcHNvbkBjaXRyaXguY29tPgoK
ZGlmZiAtciAyNzc3OGI0MDk5YmEgdG9vbHMvbGlieGwvbGlieGxfZG9tLmMKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfZG9tLmMJRnJpIEphbiAyNSAxNTowNDoxMSAyMDEzICswMDAwCisrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsX2RvbS5jCUZyaSBKYW4gMjUgMTM6Mzc6NTUgMjAxMyAtMDUwMApAQCAt
NTQyLDE3ICs1NDIsMjQgQEAgaW50IGxpYnhsX19idWlsZF9odm0obGlieGxfX2djICpnYywgdWlu
dAogICAgICAgICAgICAgICBsaWJ4bF9fZG9tYWluX2J1aWxkX3N0YXRlICpzdGF0ZSkKIHsKICAg
ICBsaWJ4bF9jdHggKmN0eCA9IGxpYnhsX19nY19vd25lcihnYyk7CisgICAgc3RydWN0IHhjX2h2
bV9idWlsZF9hcmdzIGFyZ3MgPSB7fTsKICAgICBpbnQgcmV0LCByYyA9IEVSUk9SX0ZBSUw7CiAg
ICAgY29uc3QgY2hhciAqZmlybXdhcmUgPSBsaWJ4bF9fZG9tYWluX2Zpcm13YXJlKGdjLCBpbmZv
KTsKIAogICAgIGlmICghZmlybXdhcmUpCiAgICAgICAgIGdvdG8gb3V0OwotICAgIHJldCA9IHhj
X2h2bV9idWlsZF90YXJnZXRfbWVtKAotICAgICAgICBjdHgtPnhjaCwKLSAgICAgICAgZG9taWQs
Ci0gICAgICAgIChpbmZvLT5tYXhfbWVta2IgLSBpbmZvLT52aWRlb19tZW1rYikgLyAxMDI0LAot
ICAgICAgICAoaW5mby0+dGFyZ2V0X21lbWtiIC0gaW5mby0+dmlkZW9fbWVta2IpIC8gMTAyNCwK
LSAgICAgICAgZmlybXdhcmUpOworCisgICAgbWVtc2V0KCZhcmdzLCAwLCBzaXplb2Yoc3RydWN0
IHhjX2h2bV9idWlsZF9hcmdzKSk7CisgICAgLyogVGhlIG1lbW9yeSBzaXplIG5hbWVzIGFyZSBt
aXNsZWFkaW5nLiBUaGUgcGFyYW1zIGFyZSBpbiBNYiB0aGVuCisgICAgICogbXVsdGlwbGllZCBi
eSAxIEtiLiBUaGlzIHdhcyB0aGVuIGRpdmlkZWQgb2ZmIHdoZW4gY2FsbGluZworICAgICAqIHRo
ZSBvbGQgeGNfaHZtX2J1aWxkX3RhcmdldF9tZW0oKSB3aGljaCB0aGVuIHR1cm5lZCB0aGVtIHRv
IGJ5dGVzLgorICAgICAqIERvIGFsbCB0aGlzIGluIG9uZSBzdGVwIGhlcmUuLi4KKyAgICAgKi8K
KyAgICBhcmdzLm1lbV9zaXplID0gKHVpbnQ2NF90KShpbmZvLT5tYXhfbWVta2IgLSBpbmZvLT52
aWRlb19tZW1rYikgPDwgMTA7CisgICAgYXJncy5tZW1fdGFyZ2V0ID0gKHVpbnQ2NF90KShpbmZv
LT50YXJnZXRfbWVta2IgLSBpbmZvLT52aWRlb19tZW1rYikgPDwgMTA7CisgICAgYXJncy5pbWFn
ZV9maWxlX25hbWUgPSBmaXJtd2FyZTsKKworICAgIHJldCA9IHhjX2h2bV9idWlsZChjdHgtPnhj
aCwgZG9taWQsICZhcmdzKTsKICAgICBpZiAocmV0KSB7CiAgICAgICAgIExJQlhMX19MT0dfRVJS
Tk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCByZXQsICJodm0gYnVpbGRpbmcgZmFpbGVkIik7
CiAgICAgICAgIGdvdG8gb3V0Owo=

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: application/octet-stream; name="fd1700bde7.aa.sf"
Content-Description: fd1700bde7.aa.sf
Content-Disposition: attachment; filename="fd1700bde7.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:12:38 GMT";
	modification-date="Fri, 01 Feb 2013 20:12:38 GMT"
Content-Transfer-Encoding: base64

ZmQxNzAwYmRlNw0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXGZkMTcwMGJkZTdcDQowDQowDQowDQpOT05FDQpOT05F

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: application/octet-stream; name="65d46b1796.aa.sf"
Content-Description: 65d46b1796.aa.sf
Content-Disposition: attachment; filename="65d46b1796.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:13:10 GMT";
	modification-date="Fri, 01 Feb 2013 20:13:10 GMT"
Content-Transfer-Encoding: base64

NjVkNDZiMTc5Ng0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXDY1ZDQ2YjE3OTZcDQowDQowDQowDQpOT05FDQpOT05F

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

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

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20: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 1U1N1o-0001wX-ON; Fri, 01 Feb 2013 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 <Ross.Philipson@citrix.com>) id 1U1N1n-0001wS-La
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:16:03 +0000
Received: from [85.158.138.51:65367] by server-10.bemta-3.messagelabs.com id
	87/E3-10609-2822C015; Fri, 01 Feb 2013 20:16:02 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1359749760!22521918!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31149 invoked from network); 1 Feb 2013 20:16:01 -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;
	1 Feb 2013 20:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="sf'?scan'208";a="5712204"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:16:00 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:15:59 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:15:57 -0500
Thread-Topic: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuJRfUKlqHGJMQneo30DCkrYerQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Switch libxl to use the new xc_hvm_build() libxc API.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: application/octet-stream;
	name="hvm-firmware-passthrough-libxl-v2-01.patch"
Content-Description: hvm-firmware-passthrough-libxl-v2-01.patch
Content-Disposition: attachment;
	filename="hvm-firmware-passthrough-libxl-v2-01.patch"; size=1502;
	creation-date="Fri, 01 Feb 2013 19:55:13 GMT";
	modification-date="Fri, 01 Feb 2013 19:55:13 GMT"
Content-Transfer-Encoding: base64

U3dpdGNoIGxpYnhsIHRvIHVzZSB0aGUgbmV3IHhjX2h2bV9idWlsZCgpIGxpYnhjIEFQSS4KClNp
Z25lZC1vZmYtYnk6IFJvc3MgUGhpbGlwc29uIDxyb3NzLnBoaWxpcHNvbkBjaXRyaXguY29tPgoK
ZGlmZiAtciAyNzc3OGI0MDk5YmEgdG9vbHMvbGlieGwvbGlieGxfZG9tLmMKLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfZG9tLmMJRnJpIEphbiAyNSAxNTowNDoxMSAyMDEzICswMDAwCisrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsX2RvbS5jCUZyaSBKYW4gMjUgMTM6Mzc6NTUgMjAxMyAtMDUwMApAQCAt
NTQyLDE3ICs1NDIsMjQgQEAgaW50IGxpYnhsX19idWlsZF9odm0obGlieGxfX2djICpnYywgdWlu
dAogICAgICAgICAgICAgICBsaWJ4bF9fZG9tYWluX2J1aWxkX3N0YXRlICpzdGF0ZSkKIHsKICAg
ICBsaWJ4bF9jdHggKmN0eCA9IGxpYnhsX19nY19vd25lcihnYyk7CisgICAgc3RydWN0IHhjX2h2
bV9idWlsZF9hcmdzIGFyZ3MgPSB7fTsKICAgICBpbnQgcmV0LCByYyA9IEVSUk9SX0ZBSUw7CiAg
ICAgY29uc3QgY2hhciAqZmlybXdhcmUgPSBsaWJ4bF9fZG9tYWluX2Zpcm13YXJlKGdjLCBpbmZv
KTsKIAogICAgIGlmICghZmlybXdhcmUpCiAgICAgICAgIGdvdG8gb3V0OwotICAgIHJldCA9IHhj
X2h2bV9idWlsZF90YXJnZXRfbWVtKAotICAgICAgICBjdHgtPnhjaCwKLSAgICAgICAgZG9taWQs
Ci0gICAgICAgIChpbmZvLT5tYXhfbWVta2IgLSBpbmZvLT52aWRlb19tZW1rYikgLyAxMDI0LAot
ICAgICAgICAoaW5mby0+dGFyZ2V0X21lbWtiIC0gaW5mby0+dmlkZW9fbWVta2IpIC8gMTAyNCwK
LSAgICAgICAgZmlybXdhcmUpOworCisgICAgbWVtc2V0KCZhcmdzLCAwLCBzaXplb2Yoc3RydWN0
IHhjX2h2bV9idWlsZF9hcmdzKSk7CisgICAgLyogVGhlIG1lbW9yeSBzaXplIG5hbWVzIGFyZSBt
aXNsZWFkaW5nLiBUaGUgcGFyYW1zIGFyZSBpbiBNYiB0aGVuCisgICAgICogbXVsdGlwbGllZCBi
eSAxIEtiLiBUaGlzIHdhcyB0aGVuIGRpdmlkZWQgb2ZmIHdoZW4gY2FsbGluZworICAgICAqIHRo
ZSBvbGQgeGNfaHZtX2J1aWxkX3RhcmdldF9tZW0oKSB3aGljaCB0aGVuIHR1cm5lZCB0aGVtIHRv
IGJ5dGVzLgorICAgICAqIERvIGFsbCB0aGlzIGluIG9uZSBzdGVwIGhlcmUuLi4KKyAgICAgKi8K
KyAgICBhcmdzLm1lbV9zaXplID0gKHVpbnQ2NF90KShpbmZvLT5tYXhfbWVta2IgLSBpbmZvLT52
aWRlb19tZW1rYikgPDwgMTA7CisgICAgYXJncy5tZW1fdGFyZ2V0ID0gKHVpbnQ2NF90KShpbmZv
LT50YXJnZXRfbWVta2IgLSBpbmZvLT52aWRlb19tZW1rYikgPDwgMTA7CisgICAgYXJncy5pbWFn
ZV9maWxlX25hbWUgPSBmaXJtd2FyZTsKKworICAgIHJldCA9IHhjX2h2bV9idWlsZChjdHgtPnhj
aCwgZG9taWQsICZhcmdzKTsKICAgICBpZiAocmV0KSB7CiAgICAgICAgIExJQlhMX19MT0dfRVJS
Tk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCByZXQsICJodm0gYnVpbGRpbmcgZmFpbGVkIik7
CiAgICAgICAgIGdvdG8gb3V0Owo=

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: application/octet-stream; name="fd1700bde7.aa.sf"
Content-Description: fd1700bde7.aa.sf
Content-Disposition: attachment; filename="fd1700bde7.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:12:38 GMT";
	modification-date="Fri, 01 Feb 2013 20:12:38 GMT"
Content-Transfer-Encoding: base64

ZmQxNzAwYmRlNw0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXGZkMTcwMGJkZTdcDQowDQowDQowDQpOT05FDQpOT05F

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_
Content-Type: application/octet-stream; name="65d46b1796.aa.sf"
Content-Description: 65d46b1796.aa.sf
Content-Disposition: attachment; filename="65d46b1796.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:13:10 GMT";
	modification-date="Fri, 01 Feb 2013 20:13:10 GMT"
Content-Transfer-Encoding: base64

NjVkNDZiMTc5Ng0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXDY1ZDQ2YjE3OTZcDQowDQowDQowDQpOT05FDQpOT05F

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

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

--_004_831D55AF5A11D64C9B4B43F59EEBF720A320A939E5FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20:16: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 1U1N2L-000205-KM; Fri, 01 Feb 2013 20:16:37 +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 1U1N2J-0001zV-TF
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:16:36 +0000
Received: from [85.158.139.83:15344] by server-8.bemta-5.messagelabs.com id
	98/3E-19075-2A22C015; Fri, 01 Feb 2013 20:16:34 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1359749786!26509409!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32329 invoked from network); 1 Feb 2013 20:16:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:16:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="sf'?scan'208";a="6006887"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:16:33 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:16:32 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:16:30 -0500
Thread-Topic: [Xen-devel] [PATCH v2 03/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuL7WsvpbB/smQrq/BDQVUSMpwQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E7@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 03/03] HVM firmware passthrough libxl 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_
Content-Type: application/octet-stream;
	name="hvm-firmware-passthrough-libxl-v2-03.patch"
Content-Description: hvm-firmware-passthrough-libxl-v2-03.patch
Content-Disposition: attachment;
	filename="hvm-firmware-passthrough-libxl-v2-03.patch"; size=12623;
	creation-date="Fri, 01 Feb 2013 19:57:23 GMT";
	modification-date="Fri, 01 Feb 2013 19:57:23 GMT"
Content-Transfer-Encoding: base64

Q2xlYW51cCwgdXNlIExPRyogYW5kIEdDU1BSSU5URiBtYWNybyBpbiBsaWJ4bF9kb20uYwoKU2ln
bmVkLW9mZi1ieTogUm9zcyBQaGlsaXBzb24gPHJvc3MucGhpbGlwc29uQGNpdHJpeC5jb20+Cgpk
aWZmIC1yIDAzMjY2MGZhNWRhMSB0b29scy9saWJ4bC9saWJ4bF9kb20uYwotLS0gYS90b29scy9s
aWJ4bC9saWJ4bF9kb20uYwlGcmkgRmViIDAxIDE0OjA4OjE3IDIwMTMgLTA1MDAKKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfZG9tLmMJRnJpIEZlYiAwMSAxNDozNTozMSAyMDEzIC0wNTAwCkBAIC0z
MSw4ICszMSw3IEBAIGxpYnhsX2RvbWFpbl90eXBlIGxpYnhsX19kb21haW5fdHlwZShsaWIKIAog
ICAgIHJldCA9IHhjX2RvbWFpbl9nZXRpbmZvbGlzdChjdHgtPnhjaCwgZG9taWQsIDEsICZpbmZv
KTsKICAgICBpZiAocmV0ICE9IDEgfHwgaW5mby5kb21haW4gIT0gZG9taWQpIHsKLSAgICAgICAg
TElCWExfX0xPRyhDVFgsIExJQlhMX19MT0dfRVJST1IsCi0gICAgICAgICAgICAgICAgICAgInVu
YWJsZSB0byBnZXQgZG9tYWluIHR5cGUgZm9yIGRvbWlkPSUiUFJJdTMyLCBkb21pZCk7CisgICAg
ICAgIExPRyhFUlJPUiwgInVuYWJsZSB0byBnZXQgZG9tYWluIHR5cGUgZm9yIGRvbWlkPSUiUFJJ
dTMyLCBkb21pZCk7CiAgICAgICAgIHJldHVybiBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEOwog
ICAgIH0KICAgICBpZiAoaW5mby5mbGFncyAmIFhFTl9ET01JTkZfaHZtX2d1ZXN0KQpAQCAtMzEz
LDIwICszMTIsMTkgQEAgaW50IGxpYnhsX19idWlsZF9wb3N0KGxpYnhsX19nYyAqZ2MsIHVpbgog
CiAgICAgZW50cyA9IGxpYnhsX19jYWxsb2MoZ2MsIDEyICsgKGluZm8tPm1heF92Y3B1cyAqIDIp
ICsgMiwgc2l6ZW9mKGNoYXIgKikpOwogICAgIGVudHNbMF0gPSAibWVtb3J5L3N0YXRpYy1tYXgi
OwotICAgIGVudHNbMV0gPSBsaWJ4bF9fc3ByaW50ZihnYywgIiUiUFJJZDY0LCBpbmZvLT5tYXhf
bWVta2IpOworICAgIGVudHNbMV0gPSBHQ1NQUklOVEYoIiUiUFJJZDY0LCBpbmZvLT5tYXhfbWVt
a2IpOwogICAgIGVudHNbMl0gPSAibWVtb3J5L3RhcmdldCI7Ci0gICAgZW50c1szXSA9IGxpYnhs
X19zcHJpbnRmKGdjLCAiJSJQUklkNjQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu
Zm8tPnRhcmdldF9tZW1rYiAtIGluZm8tPnZpZGVvX21lbWtiKTsKKyAgICBlbnRzWzNdID0gR0NT
UFJJTlRGKCIlIlBSSWQ2NCwgaW5mby0+dGFyZ2V0X21lbWtiIC0gaW5mby0+dmlkZW9fbWVta2Ip
OwogICAgIGVudHNbNF0gPSAibWVtb3J5L3ZpZGVvcmFtIjsKLSAgICBlbnRzWzVdID0gbGlieGxf
X3NwcmludGYoZ2MsICIlIlBSSWQ2NCwgaW5mby0+dmlkZW9fbWVta2IpOworICAgIGVudHNbNV0g
PSBHQ1NQUklOVEYoIiUiUFJJZDY0LCBpbmZvLT52aWRlb19tZW1rYik7CiAgICAgZW50c1s2XSA9
ICJkb21pZCI7Ci0gICAgZW50c1s3XSA9IGxpYnhsX19zcHJpbnRmKGdjLCAiJWQiLCBkb21pZCk7
CisgICAgZW50c1s3XSA9IEdDU1BSSU5URigiJWQiLCBkb21pZCk7CiAgICAgZW50c1s4XSA9ICJz
dG9yZS9wb3J0IjsKLSAgICBlbnRzWzldID0gbGlieGxfX3NwcmludGYoZ2MsICIlIlBSSXUzMiwg
c3RhdGUtPnN0b3JlX3BvcnQpOworICAgIGVudHNbOV0gPSBHQ1NQUklOVEYoIiUiUFJJdTMyLCBz
dGF0ZS0+c3RvcmVfcG9ydCk7CiAgICAgZW50c1sxMF0gPSAic3RvcmUvcmluZy1yZWYiOwotICAg
IGVudHNbMTFdID0gbGlieGxfX3NwcmludGYoZ2MsICIlbHUiLCBzdGF0ZS0+c3RvcmVfbWZuKTsK
KyAgICBlbnRzWzExXSA9IEdDU1BSSU5URigiJWx1Iiwgc3RhdGUtPnN0b3JlX21mbik7CiAgICAg
Zm9yIChpID0gMDsgaSA8IGluZm8tPm1heF92Y3B1czsgaSsrKSB7Ci0gICAgICAgIGVudHNbMTIr
KGkqMildICAgPSBsaWJ4bF9fc3ByaW50ZihnYywgImNwdS8lZC9hdmFpbGFiaWxpdHkiLCBpKTsK
KyAgICAgICAgZW50c1sxMisoaSoyKV0gICA9IEdDU1BSSU5URigiY3B1LyVkL2F2YWlsYWJpbGl0
eSIsIGkpOwogICAgICAgICBlbnRzWzEyKyhpKjIpKzFdID0gbGlieGxfYml0bWFwX3Rlc3QoJmlu
Zm8tPmF2YWlsX3ZjcHVzLCBpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIm9ubGlu
ZSIgOiAib2ZmbGluZSI7CiAgICAgfQpAQCAtMzM1LDcgKzMzMyw3IEBAIGludCBsaWJ4bF9fYnVp
bGRfcG9zdChsaWJ4bF9fZ2MgKmdjLCB1aW4KICAgICBpZiAoaW5mby0+dHlwZSA9PSBMSUJYTF9E
T01BSU5fVFlQRV9IVk0pIHsKICAgICAgICAgaHZtX2VudHMgPSBsaWJ4bF9fY2FsbG9jKGdjLCAz
LCBzaXplb2YoY2hhciAqKSk7CiAgICAgICAgIGh2bV9lbnRzWzBdID0gImh2bWxvYWRlci9nZW5l
cmF0aW9uLWlkLWFkZHJlc3MiOwotICAgICAgICBodm1fZW50c1sxXSA9IGxpYnhsX19zcHJpbnRm
KGdjLCAiMHglbHgiLCBzdGF0ZS0+dm1fZ2VuZXJhdGlvbmlkX2FkZHIpOworICAgICAgICBodm1f
ZW50c1sxXSA9IEdDU1BSSU5URigiMHglbHgiLCBzdGF0ZS0+dm1fZ2VuZXJhdGlvbmlkX2FkZHIp
OwogICAgIH0KIAogICAgIGRvbV9wYXRoID0gbGlieGxfX3hzX2dldF9kb21wYXRoKGdjLCBkb21p
ZCk7CkBAIC0zNDMsNyArMzQxLDcgQEAgaW50IGxpYnhsX19idWlsZF9wb3N0KGxpYnhsX19nYyAq
Z2MsIHVpbgogICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsKICAgICB9CiAKLSAgICB2bV9wYXRo
ID0geHNfcmVhZChjdHgtPnhzaCwgWEJUX05VTEwsIGxpYnhsX19zcHJpbnRmKGdjLCAiJXMvdm0i
LCBkb21fcGF0aCksIE5VTEwpOworICAgIHZtX3BhdGggPSB4c19yZWFkKGN0eC0+eHNoLCBYQlRf
TlVMTCwgR0NTUFJJTlRGKCIlcy92bSIsIGRvbV9wYXRoKSwgTlVMTCk7CiByZXRyeV90cmFuc2Fj
dGlvbjoKICAgICB0ID0geHNfdHJhbnNhY3Rpb25fc3RhcnQoY3R4LT54c2gpOwogCkBAIC0zNzQs
NyArMzcyLDcgQEAgaW50IGxpYnhsX19idWlsZF9wdihsaWJ4bF9fZ2MgKmdjLCB1aW50MwogCiAg
ICAgZG9tID0geGNfZG9tX2FsbG9jYXRlKGN0eC0+eGNoLCBzdGF0ZS0+cHZfY21kbGluZSwgaW5m
by0+dS5wdi5mZWF0dXJlcyk7CiAgICAgaWYgKCFkb20pIHsKLSAgICAgICAgTElCWExfX0xPR19F
UlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4Y19kb21fYWxsb2NhdGUgZmFpbGVkIik7Cisg
ICAgICAgIExPR0UoRVJST1IsICJ4Y19kb21fYWxsb2NhdGUgZmFpbGVkIik7CiAgICAgICAgIHJl
dHVybiBFUlJPUl9GQUlMOwogICAgIH0KIApAQCAtMzg0LDEzICszODIsMTMgQEAgaW50IGxpYnhs
X19idWlsZF9wdihsaWJ4bF9fZ2MgKmdjLCB1aW50MwogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzdGF0ZS0+cHZfa2VybmVsLmRhdGEsCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0YXRlLT5wdl9rZXJuZWwuc2l6ZSk7CiAgICAgICAgIGlmICggcmV0ICE9IDApIHsK
LSAgICAgICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNf
ZG9tX2tlcm5lbF9tZW0gZmFpbGVkIik7CisgICAgICAgICAgICBMT0dFKEVSUk9SLCAieGNfZG9t
X2tlcm5lbF9tZW0gZmFpbGVkIik7CiAgICAgICAgICAgICBnb3RvIG91dDsKICAgICAgICAgfQog
ICAgIH0gZWxzZSB7CiAgICAgICAgIHJldCA9IHhjX2RvbV9rZXJuZWxfZmlsZShkb20sIHN0YXRl
LT5wdl9rZXJuZWwucGF0aCk7CiAgICAgICAgIGlmICggcmV0ICE9IDApIHsKLSAgICAgICAgICAg
IExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX2tlcm5lbF9m
aWxlIGZhaWxlZCIpOworICAgICAgICAgICAgTE9HRShFUlJPUiwgInhjX2RvbV9rZXJuZWxfZmls
ZSBmYWlsZWQiKTsKICAgICAgICAgICAgIGdvdG8gb3V0OwogICAgICAgICB9CiAgICAgfQpAQCAt
Mzk4LDEyICszOTYsMTIgQEAgaW50IGxpYnhsX19idWlsZF9wdihsaWJ4bF9fZ2MgKmdjLCB1aW50
MwogICAgIGlmICggc3RhdGUtPnB2X3JhbWRpc2sucGF0aCAmJiBzdHJsZW4oc3RhdGUtPnB2X3Jh
bWRpc2sucGF0aCkgKSB7CiAgICAgICAgIGlmIChzdGF0ZS0+cHZfcmFtZGlzay5tYXBwZWQpIHsK
ICAgICAgICAgICAgIGlmICggKHJldCA9IHhjX2RvbV9yYW1kaXNrX21lbShkb20sIHN0YXRlLT5w
dl9yYW1kaXNrLmRhdGEsIHN0YXRlLT5wdl9yYW1kaXNrLnNpemUpKSAhPSAwICkgewotICAgICAg
ICAgICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9t
X3JhbWRpc2tfbWVtIGZhaWxlZCIpOworICAgICAgICAgICAgICAgIExPR0UoRVJST1IsICJ4Y19k
b21fcmFtZGlza19tZW0gZmFpbGVkIik7CiAgICAgICAgICAgICAgICAgZ290byBvdXQ7CiAgICAg
ICAgICAgICB9CiAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICBpZiAoIChyZXQgPSB4Y19k
b21fcmFtZGlza19maWxlKGRvbSwgc3RhdGUtPnB2X3JhbWRpc2sucGF0aCkpICE9IDAgKSB7Ci0g
ICAgICAgICAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4
Y19kb21fcmFtZGlza19maWxlIGZhaWxlZCIpOworICAgICAgICAgICAgICAgIExPR0UoRVJST1Is
ICJ4Y19kb21fcmFtZGlza19maWxlIGZhaWxlZCIpOwogICAgICAgICAgICAgICAgIGdvdG8gb3V0
OwogICAgICAgICAgICAgfQogICAgICAgICB9CkBAIC00MTYsMzEgKzQxNCwzMSBAQCBpbnQgbGli
eGxfX2J1aWxkX3B2KGxpYnhsX19nYyAqZ2MsIHVpbnQzCiAgICAgZG9tLT54ZW5zdG9yZV9kb21p
ZCA9IHN0YXRlLT5zdG9yZV9kb21pZDsKIAogICAgIGlmICggKHJldCA9IHhjX2RvbV9ib290X3hl
bl9pbml0KGRvbSwgY3R4LT54Y2gsIGRvbWlkKSkgIT0gMCApIHsKLSAgICAgICAgTElCWExfX0xP
R19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4Y19kb21fYm9vdF94ZW5faW5pdCBmYWls
ZWQiKTsKKyAgICAgICAgTE9HRShFUlJPUiwgInhjX2RvbV9ib290X3hlbl9pbml0IGZhaWxlZCIp
OwogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX3BhcnNl
X2ltYWdlKGRvbSkpICE9IDAgKSB7Ci0gICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJY
TF9fTE9HX0VSUk9SLCAieGNfZG9tX3BhcnNlX2ltYWdlIGZhaWxlZCIpOworICAgICAgICBMT0dF
KEVSUk9SLCAieGNfZG9tX3BhcnNlX2ltYWdlIGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsK
ICAgICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX21lbV9pbml0KGRvbSwgaW5mby0+dGFyZ2V0
X21lbWtiIC8gMTAyNCkpICE9IDAgKSB7Ci0gICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBM
SUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX21lbV9pbml0IGZhaWxlZCIpOworICAgICAgICBMT0dF
KEVSUk9SLCAieGNfZG9tX21lbV9pbml0IGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAg
ICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX2Jvb3RfbWVtX2luaXQoZG9tKSkgIT0gMCApIHsK
LSAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4Y19kb21f
Ym9vdF9tZW1faW5pdCBmYWlsZWQiKTsKKyAgICAgICAgTE9HRShFUlJPUiwgInhjX2RvbV9ib290
X21lbV9pbml0IGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAgICAgaWYgKCAo
cmV0ID0geGNfZG9tX2J1aWxkX2ltYWdlKGRvbSkpICE9IDAgKSB7Ci0gICAgICAgIExJQlhMX19M
T0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX2J1aWxkX2ltYWdlIGZhaWxl
ZCIpOworICAgICAgICBMT0dFKEVSUk9SLCAieGNfZG9tX2J1aWxkX2ltYWdlIGZhaWxlZCIpOwog
ICAgICAgICBnb3RvIG91dDsKICAgICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX2Jvb3RfaW1h
Z2UoZG9tKSkgIT0gMCApIHsKLSAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19M
T0dfRVJST1IsICJ4Y19kb21fYm9vdF9pbWFnZSBmYWlsZWQiKTsKKyAgICAgICAgTE9HRShFUlJP
UiwgInhjX2RvbV9ib290X2ltYWdlIGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9
CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX2dudHRhYl9pbml0KGRvbSkpICE9IDAgKSB7Ci0gICAg
ICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX2dudHRh
Yl9pbml0IGZhaWxlZCIpOworICAgICAgICBMT0dFKEVSUk9SLCAieGNfZG9tX2dudHRhYl9pbml0
IGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAKQEAgLTY4NSw4ICs2ODMsNyBA
QCBpbnQgbGlieGxfX3FlbXVfdHJhZGl0aW9uYWxfY21kKGxpYnhsX19nCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmNtZCkKIHsKICAgICBjaGFyICpwYXRoID0g
TlVMTDsKLSAgICBwYXRoID0gbGlieGxfX3NwcmludGYoZ2MsICIvbG9jYWwvZG9tYWluLzAvZGV2
aWNlLW1vZGVsLyVkL2NvbW1hbmQiLAotICAgICAgICAgICAgICAgICAgICAgICAgICBkb21pZCk7
CisgICAgcGF0aCA9IEdDU1BSSU5URigiL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8lZC9j
b21tYW5kIiwgZG9taWQpOwogICAgIHJldHVybiBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxM
LCBwYXRoLCAiJXMiLCBjbWQpOwogfQogCkBAIC03MDMsOCArNzAwLDcgQEAgc3RydWN0IGxpYnhs
X19waHlzbWFwX2luZm8gewogc3RhdGljIGlubGluZSBjaGFyICpyZXN0b3JlX2hlbHBlcihsaWJ4
bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCwKICAgICAgICAgdWludDY0X3QgcGh5c19vZmZzZXQs
IGNoYXIgKm5vZGUpCiB7Ci0gICAgcmV0dXJuIGxpYnhsX19zcHJpbnRmKGdjLAotICAgICAgICAg
ICAgIi9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvJWQvcGh5c21hcC8lIlBSSXg2NCIvJXMi
LAorICAgIHJldHVybiBHQ1NQUklOVEYoIi9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvJWQv
cGh5c21hcC8lIlBSSXg2NCIvJXMiLAogICAgICAgICAgICAgZG9taWQsIHBoeXNfb2Zmc2V0LCBu
b2RlKTsKIH0KIApAQCAtNzE0LDcgKzcxMCw2IEBAIGludCBsaWJ4bF9fdG9vbHN0YWNrX3Jlc3Rv
cmUodWludDMyX3QgZG8KICAgICBsaWJ4bF9fc2F2ZV9oZWxwZXJfc3RhdGUgKnNocyA9IHVzZXI7
CiAgICAgbGlieGxfX2RvbWFpbl9jcmVhdGVfc3RhdGUgKmRjcyA9IENPTlRBSU5FUl9PRihzaHMs
ICpkY3MsIHNocyk7CiAgICAgU1RBVEVfQU9fR0MoZGNzLT5hbyk7Ci0gICAgbGlieGxfY3R4ICpj
dHggPSBDVFg7CiAgICAgaW50IGksIHJldDsKICAgICBjb25zdCB1aW50OF90ICpwdHIgPSBidWY7
CiAgICAgdWludDMyX3QgY291bnQgPSAwLCB2ZXJzaW9uID0gMDsKQEAgLTcyNCw3ICs3MTksNyBA
QCBpbnQgbGlieGxfX3Rvb2xzdGFja19yZXN0b3JlKHVpbnQzMl90IGRvCiAgICAgTE9HKERFQlVH
LCJkb21haW49JSJQUkl1MzIiIHRvb2xzdGFjayBkYXRhIHNpemU9JSJQUkl1MzIsIGRvbWlkLCBz
aXplKTsKIAogICAgIGlmIChzaXplIDwgc2l6ZW9mKHZlcnNpb24pICsgc2l6ZW9mKGNvdW50KSkg
ewotICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwgIndyb25nIHNpemUi
KTsKKyAgICAgICAgTE9HKEVSUk9SLCAid3Jvbmcgc2l6ZSIpOwogICAgICAgICByZXR1cm4gLTE7
CiAgICAgfQogCkBAIC03MzIsNyArNzI3LDcgQEAgaW50IGxpYnhsX190b29sc3RhY2tfcmVzdG9y
ZSh1aW50MzJfdCBkbwogICAgIHB0ciArPSBzaXplb2YodmVyc2lvbik7CiAKICAgICBpZiAodmVy
c2lvbiAhPSBUT09MU1RBQ0tfU0FWRV9WRVJTSU9OKSB7Ci0gICAgICAgIExJQlhMX19MT0coY3R4
LCBMSUJYTF9fTE9HX0VSUk9SLCAid3JvbmcgdmVyc2lvbiIpOworICAgICAgICBMT0coRVJST1Is
ICJ3cm9uZyB2ZXJzaW9uIik7CiAgICAgICAgIHJldHVybiAtMTsKICAgICB9CiAKQEAgLTc0MSw3
ICs3MzYsNyBAQCBpbnQgbGlieGxfX3Rvb2xzdGFja19yZXN0b3JlKHVpbnQzMl90IGRvCiAKICAg
ICBpZiAoc2l6ZSA8IHNpemVvZih2ZXJzaW9uKSArIHNpemVvZihjb3VudCkgKwogICAgICAgICAg
ICAgY291bnQgKiAoc2l6ZW9mKHN0cnVjdCBsaWJ4bF9fcGh5c21hcF9pbmZvKSkpIHsKLSAgICAg
ICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ3cm9uZyBzaXplIik7CisgICAg
ICAgIExPRyhFUlJPUiwgIndyb25nIHNpemUiKTsKICAgICAgICAgcmV0dXJuIC0xOwogICAgIH0K
IApAQCAtOTkwLDE1ICs5ODUsMTMgQEAgc3RhdGljIHZvaWQgc3dpdGNoX2xvZ2RpcnR5X2RvbmUo
bGlieGxfXwogaW50IGxpYnhsX19kb21haW5fc3VzcGVuZF9kZXZpY2VfbW9kZWwobGlieGxfX2dj
ICpnYywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX19kb21h
aW5fc3VzcGVuZF9zdGF0ZSAqZHNzKQogewotICAgIGxpYnhsX2N0eCAqY3R4ID0gbGlieGxfX2dj
X293bmVyKGdjKTsKICAgICBpbnQgcmV0ID0gMDsKICAgICB1aW50MzJfdCBjb25zdCBkb21pZCA9
IGRzcy0+ZG9taWQ7CiAgICAgY29uc3QgY2hhciAqY29uc3QgZmlsZW5hbWUgPSBkc3MtPmRtX3Nh
dmVmaWxlOwogCiAgICAgc3dpdGNoIChsaWJ4bF9fZGV2aWNlX21vZGVsX3ZlcnNpb25fcnVubmlu
ZyhnYywgZG9taWQpKSB7CiAgICAgY2FzZSBMSUJYTF9ERVZJQ0VfTU9ERUxfVkVSU0lPTl9RRU1V
X1hFTl9UUkFESVRJT05BTDogewotICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19E
RUJVRywKLSAgICAgICAgICAgICAgICAgICAiU2F2aW5nIGRldmljZSBtb2RlbCBzdGF0ZSB0byAl
cyIsIGZpbGVuYW1lKTsKKyAgICAgICAgTE9HKERFQlVHLCAiU2F2aW5nIGRldmljZSBtb2RlbCBz
dGF0ZSB0byAlcyIsIGZpbGVuYW1lKTsKICAgICAgICAgbGlieGxfX3FlbXVfdHJhZGl0aW9uYWxf
Y21kKGdjLCBkb21pZCwgInNhdmUiKTsKICAgICAgICAgbGlieGxfX3dhaXRfZm9yX2RldmljZV9t
b2RlbChnYywgZG9taWQsICJwYXVzZWQiLCBOVUxMLCBOVUxMLCBOVUxMKTsKICAgICAgICAgYnJl
YWs7CkBAIC0xMTc0LDggKzExNjcsNyBAQCBpbnQgbGlieGxfX2RvbWFpbl9zdXNwZW5kX2NvbW1v
bl9jYWxsYmFjCiBzdGF0aWMgaW5saW5lIGNoYXIgKnBoeXNtYXBfcGF0aChsaWJ4bF9fZ2MgKmdj
LCB1aW50MzJfdCBkb21pZCwKICAgICAgICAgY2hhciAqcGh5c19vZmZzZXQsIGNoYXIgKm5vZGUp
CiB7Ci0gICAgcmV0dXJuIGxpYnhsX19zcHJpbnRmKGdjLAotICAgICAgICAgICAgIi9sb2NhbC9k
b21haW4vMC9kZXZpY2UtbW9kZWwvJWQvcGh5c21hcC8lcy8lcyIsCisgICAgcmV0dXJuIEdDU1BS
SU5URigiL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8lZC9waHlzbWFwLyVzLyVzIiwKICAg
ICAgICAgICAgIGRvbWlkLCBwaHlzX29mZnNldCwgbm9kZSk7CiB9CiAKQEAgLTExOTIsNyArMTE4
NCw3IEBAIGludCBsaWJ4bF9fdG9vbHN0YWNrX3NhdmUodWludDMyX3QgZG9taWQKICAgICBjaGFy
ICoqZW50cmllcyA9IE5VTEw7CiAgICAgc3RydWN0IGxpYnhsX19waHlzbWFwX2luZm8gKnBpOwog
Ci0gICAgZW50cmllcyA9IGxpYnhsX194c19kaXJlY3RvcnkoZ2MsIDAsIGxpYnhsX19zcHJpbnRm
KGdjLAorICAgIGVudHJpZXMgPSBsaWJ4bF9feHNfZGlyZWN0b3J5KGdjLCAwLCBHQ1NQUklOVEYo
CiAgICAgICAgICAgICAgICAgIi9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvJWQvcGh5c21h
cCIsIGRvbWlkKSwgJm51bSk7CiAgICAgY291bnQgPSBudW07CiAKQEAgLTEzMzMsNyArMTMyNSw3
IEBAIHZvaWQgbGlieGxfX2RvbWFpbl9zdXNwZW5kKGxpYnhsX19lZ2MgKmUKICAgICAgICAgY2hh
ciAqcGF0aDsKICAgICAgICAgY2hhciAqYWRkcjsKIAotICAgICAgICBwYXRoID0gbGlieGxfX3Nw
cmludGYoZ2MsICIlcy9odm1sb2FkZXIvZ2VuZXJhdGlvbi1pZC1hZGRyZXNzIiwKKyAgICAgICAg
cGF0aCA9IEdDU1BSSU5URigiJXMvaHZtbG9hZGVyL2dlbmVyYXRpb24taWQtYWRkcmVzcyIsCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9feHNfZ2V0X2RvbXBhdGgoZ2MsIGRv
bWlkKSk7CiAgICAgICAgIGFkZHIgPSBsaWJ4bF9feHNfcmVhZChnYywgWEJUX05VTEwsIHBhdGgp
OwogCkBAIC0xNTQ3LDEwICsxNTM5LDcgQEAgc3RhdGljIHZvaWQgZG9tYWluX3N1c3BlbmRfZG9u
ZShsaWJ4bF9fZQogCiBjaGFyICpsaWJ4bF9fdXVpZDJzdHJpbmcobGlieGxfX2djICpnYywgY29u
c3QgbGlieGxfdXVpZCB1dWlkKQogewotICAgIGNoYXIgKnMgPSBsaWJ4bF9fc3ByaW50ZihnYywg
TElCWExfVVVJRF9GTVQsIExJQlhMX1VVSURfQllURVModXVpZCkpOwotICAgIGlmICghcykKLSAg
ICAgICAgTElCWExfX0xPRyhsaWJ4bF9fZ2Nfb3duZXIoZ2MpLCBMSUJYTF9fTE9HX0VSUk9SLCAi
Y2Fubm90IGFsbG9jYXRlIGZvciB1dWlkIik7Ci0gICAgcmV0dXJuIHM7CisgICAgcmV0dXJuIEdD
U1BSSU5URihMSUJYTF9VVUlEX0ZNVCwgTElCWExfVVVJRF9CWVRFUyh1dWlkKSk7CiB9CiAKIHN0
YXRpYyBjb25zdCBjaGFyICp1c2VyZGF0YV9wYXRoKGxpYnhsX19nYyAqZ2MsIHVpbnQzMl90IGRv
bWlkLApAQCAtMTU1OCwzNCArMTU0NywyOCBAQCBzdGF0aWMgY29uc3QgY2hhciAqdXNlcmRhdGFf
cGF0aChsaWJ4bF9fCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0
IGNoYXIgKndoKQogewogICAgIGxpYnhsX2N0eCAqY3R4ID0gbGlieGxfX2djX293bmVyKGdjKTsK
LSAgICBjaGFyICpwYXRoLCAqdXVpZF9zdHJpbmc7CisgICAgY2hhciAqdXVpZF9zdHJpbmc7CiAg
ICAgbGlieGxfZG9taW5mbyBpbmZvOwogICAgIGludCByYzsKIAogICAgIHJjID0gbGlieGxfZG9t
YWluX2luZm8oY3R4LCAmaW5mbywgZG9taWQpOwogICAgIGlmIChyYykgewotICAgICAgICBMSUJY
TF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgInVuYWJsZSB0byBmaW5kIGRvbWFp
biBpbmZvIgotICAgICAgICAgICAgICAgICAgICAgIiBmb3IgZG9tYWluICUiUFJJdTMyLCBkb21p
ZCk7CisgICAgICAgIExPR0UoRVJST1IsICJ1bmFibGUgdG8gZmluZCBkb21haW4gaW5mbyBmb3Ig
ZG9tYWluICUiUFJJdTMyLCBkb21pZCk7CiAgICAgICAgIHJldHVybiBOVUxMOwogICAgIH0KLSAg
ICB1dWlkX3N0cmluZyA9IGxpYnhsX19zcHJpbnRmKGdjLCBMSUJYTF9VVUlEX0ZNVCwgTElCWExf
VVVJRF9CWVRFUyhpbmZvLnV1aWQpKTsKKyAgICB1dWlkX3N0cmluZyA9IEdDU1BSSU5URihMSUJY
TF9VVUlEX0ZNVCwgTElCWExfVVVJRF9CWVRFUyhpbmZvLnV1aWQpKTsKIAotICAgIHBhdGggPSBs
aWJ4bF9fc3ByaW50ZihnYywgIi92YXIvbGliL3hlbi8iCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgInVzZXJkYXRhLSVzLiV1LiVzLiVzIiwKLSAgICAgICAgICAgICAgICAgICAgICAgICB3aCwg
ZG9taWQsIHV1aWRfc3RyaW5nLCB1c2VyZGF0YV91c2VyaWQpOwotICAgIGlmICghcGF0aCkKLSAg
ICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8g
YWxsb2NhdGUgZm9yIgotICAgICAgICAgICAgICAgICAgICAgIiB1c2VyZGF0YSBwYXRoIik7Ci0g
ICAgcmV0dXJuIHBhdGg7CisgICAgcmV0dXJuIEdDU1BSSU5URigiL3Zhci9saWIveGVuL3VzZXJk
YXRhLSVzLiV1LiVzLiVzIiwKKyAgICAgICAgICAgICAgICAgICAgIHdoLCBkb21pZCwgdXVpZF9z
dHJpbmcsIHVzZXJkYXRhX3VzZXJpZCk7CiB9CiAKIHN0YXRpYyBpbnQgdXNlcmRhdGFfZGVsZXRl
KGxpYnhsX19nYyAqZ2MsIGNvbnN0IGNoYXIgKnBhdGgpCiB7Ci0gICAgbGlieGxfY3R4ICpjdHgg
PSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwogICAgIGludCByOworCiAgICAgciA9IHVubGluayhwYXRo
KTsKICAgICBpZiAocikgewotICAgICAgICBMSUJYTF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xP
R19FUlJPUiwgInJlbW92ZSBmYWlsZWQgZm9yICVzIiwgcGF0aCk7CisgICAgICAgIExPR0UoRVJS
T1IsICJyZW1vdmUgZmFpbGVkIGZvciAlcyIsIHBhdGgpOwogICAgICAgICByZXR1cm4gZXJybm87
CiAgICAgfQogICAgIHJldHVybiAwOwpAQCAtMTU5Myw3ICsxNTc2LDYgQEAgc3RhdGljIGludCB1
c2VyZGF0YV9kZWxldGUobGlieGxfX2djICpnYwogCiB2b2lkIGxpYnhsX191c2VyZGF0YV9kZXN0
cm95YWxsKGxpYnhsX19nYyAqZ2MsIHVpbnQzMl90IGRvbWlkKQogewotICAgIGxpYnhsX2N0eCAq
Y3R4ID0gbGlieGxfX2djX293bmVyKGdjKTsKICAgICBjb25zdCBjaGFyICpwYXR0ZXJuOwogICAg
IGdsb2JfdCBnbDsKICAgICBpbnQgciwgaTsKQEAgLTE2MDksNyArMTU5MSw3IEBAIHZvaWQgbGli
eGxfX3VzZXJkYXRhX2Rlc3Ryb3lhbGwobGlieGxfX2cKICAgICBpZiAociA9PSBHTE9CX05PTUFU
Q0gpCiAgICAgICAgIGdvdG8gb3V0OwogICAgIGlmIChyKQotICAgICAgICBMSUJYTF9fTE9HX0VS
Uk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImdsb2IgZmFpbGVkIGZvciAlcyIsIHBhdHRlcm4p
OworICAgICAgICBMT0dFKEVSUk9SLCAiZ2xvYiBmYWlsZWQgZm9yICVzIiwgcGF0dGVybik7CiAK
ICAgICBmb3IgKGk9MDsgaTxnbC5nbF9wYXRoYzsgaSsrKSB7CiAgICAgICAgIHVzZXJkYXRhX2Rl
bGV0ZShnYywgZ2wuZ2xfcGF0aHZbaV0pOwo=

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_
Content-Type: application/octet-stream; name="fb80b3380e.aa.sf"
Content-Description: fb80b3380e.aa.sf
Content-Disposition: attachment; filename="fb80b3380e.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:14:47 GMT";
	modification-date="Fri, 01 Feb 2013 20:14:47 GMT"
Content-Transfer-Encoding: base64

ZmI4MGIzMzgwZQ0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXGZiODBiMzM4MGVcDQowDQowDQowDQpOT05FDQpOT05F

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

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

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20:16: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 1U1N2L-000205-KM; Fri, 01 Feb 2013 20:16:37 +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 1U1N2J-0001zV-TF
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:16:36 +0000
Received: from [85.158.139.83:15344] by server-8.bemta-5.messagelabs.com id
	98/3E-19075-2A22C015; Fri, 01 Feb 2013 20:16:34 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1359749786!26509409!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32329 invoked from network); 1 Feb 2013 20:16:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:16:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="sf'?scan'208";a="6006887"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:16:33 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:16:32 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:16:30 -0500
Thread-Topic: [Xen-devel] [PATCH v2 03/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuL7WsvpbB/smQrq/BDQVUSMpwQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E7@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 03/03] HVM firmware passthrough libxl 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_
Content-Type: application/octet-stream;
	name="hvm-firmware-passthrough-libxl-v2-03.patch"
Content-Description: hvm-firmware-passthrough-libxl-v2-03.patch
Content-Disposition: attachment;
	filename="hvm-firmware-passthrough-libxl-v2-03.patch"; size=12623;
	creation-date="Fri, 01 Feb 2013 19:57:23 GMT";
	modification-date="Fri, 01 Feb 2013 19:57:23 GMT"
Content-Transfer-Encoding: base64

Q2xlYW51cCwgdXNlIExPRyogYW5kIEdDU1BSSU5URiBtYWNybyBpbiBsaWJ4bF9kb20uYwoKU2ln
bmVkLW9mZi1ieTogUm9zcyBQaGlsaXBzb24gPHJvc3MucGhpbGlwc29uQGNpdHJpeC5jb20+Cgpk
aWZmIC1yIDAzMjY2MGZhNWRhMSB0b29scy9saWJ4bC9saWJ4bF9kb20uYwotLS0gYS90b29scy9s
aWJ4bC9saWJ4bF9kb20uYwlGcmkgRmViIDAxIDE0OjA4OjE3IDIwMTMgLTA1MDAKKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfZG9tLmMJRnJpIEZlYiAwMSAxNDozNTozMSAyMDEzIC0wNTAwCkBAIC0z
MSw4ICszMSw3IEBAIGxpYnhsX2RvbWFpbl90eXBlIGxpYnhsX19kb21haW5fdHlwZShsaWIKIAog
ICAgIHJldCA9IHhjX2RvbWFpbl9nZXRpbmZvbGlzdChjdHgtPnhjaCwgZG9taWQsIDEsICZpbmZv
KTsKICAgICBpZiAocmV0ICE9IDEgfHwgaW5mby5kb21haW4gIT0gZG9taWQpIHsKLSAgICAgICAg
TElCWExfX0xPRyhDVFgsIExJQlhMX19MT0dfRVJST1IsCi0gICAgICAgICAgICAgICAgICAgInVu
YWJsZSB0byBnZXQgZG9tYWluIHR5cGUgZm9yIGRvbWlkPSUiUFJJdTMyLCBkb21pZCk7CisgICAg
ICAgIExPRyhFUlJPUiwgInVuYWJsZSB0byBnZXQgZG9tYWluIHR5cGUgZm9yIGRvbWlkPSUiUFJJ
dTMyLCBkb21pZCk7CiAgICAgICAgIHJldHVybiBMSUJYTF9ET01BSU5fVFlQRV9JTlZBTElEOwog
ICAgIH0KICAgICBpZiAoaW5mby5mbGFncyAmIFhFTl9ET01JTkZfaHZtX2d1ZXN0KQpAQCAtMzEz
LDIwICszMTIsMTkgQEAgaW50IGxpYnhsX19idWlsZF9wb3N0KGxpYnhsX19nYyAqZ2MsIHVpbgog
CiAgICAgZW50cyA9IGxpYnhsX19jYWxsb2MoZ2MsIDEyICsgKGluZm8tPm1heF92Y3B1cyAqIDIp
ICsgMiwgc2l6ZW9mKGNoYXIgKikpOwogICAgIGVudHNbMF0gPSAibWVtb3J5L3N0YXRpYy1tYXgi
OwotICAgIGVudHNbMV0gPSBsaWJ4bF9fc3ByaW50ZihnYywgIiUiUFJJZDY0LCBpbmZvLT5tYXhf
bWVta2IpOworICAgIGVudHNbMV0gPSBHQ1NQUklOVEYoIiUiUFJJZDY0LCBpbmZvLT5tYXhfbWVt
a2IpOwogICAgIGVudHNbMl0gPSAibWVtb3J5L3RhcmdldCI7Ci0gICAgZW50c1szXSA9IGxpYnhs
X19zcHJpbnRmKGdjLCAiJSJQUklkNjQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu
Zm8tPnRhcmdldF9tZW1rYiAtIGluZm8tPnZpZGVvX21lbWtiKTsKKyAgICBlbnRzWzNdID0gR0NT
UFJJTlRGKCIlIlBSSWQ2NCwgaW5mby0+dGFyZ2V0X21lbWtiIC0gaW5mby0+dmlkZW9fbWVta2Ip
OwogICAgIGVudHNbNF0gPSAibWVtb3J5L3ZpZGVvcmFtIjsKLSAgICBlbnRzWzVdID0gbGlieGxf
X3NwcmludGYoZ2MsICIlIlBSSWQ2NCwgaW5mby0+dmlkZW9fbWVta2IpOworICAgIGVudHNbNV0g
PSBHQ1NQUklOVEYoIiUiUFJJZDY0LCBpbmZvLT52aWRlb19tZW1rYik7CiAgICAgZW50c1s2XSA9
ICJkb21pZCI7Ci0gICAgZW50c1s3XSA9IGxpYnhsX19zcHJpbnRmKGdjLCAiJWQiLCBkb21pZCk7
CisgICAgZW50c1s3XSA9IEdDU1BSSU5URigiJWQiLCBkb21pZCk7CiAgICAgZW50c1s4XSA9ICJz
dG9yZS9wb3J0IjsKLSAgICBlbnRzWzldID0gbGlieGxfX3NwcmludGYoZ2MsICIlIlBSSXUzMiwg
c3RhdGUtPnN0b3JlX3BvcnQpOworICAgIGVudHNbOV0gPSBHQ1NQUklOVEYoIiUiUFJJdTMyLCBz
dGF0ZS0+c3RvcmVfcG9ydCk7CiAgICAgZW50c1sxMF0gPSAic3RvcmUvcmluZy1yZWYiOwotICAg
IGVudHNbMTFdID0gbGlieGxfX3NwcmludGYoZ2MsICIlbHUiLCBzdGF0ZS0+c3RvcmVfbWZuKTsK
KyAgICBlbnRzWzExXSA9IEdDU1BSSU5URigiJWx1Iiwgc3RhdGUtPnN0b3JlX21mbik7CiAgICAg
Zm9yIChpID0gMDsgaSA8IGluZm8tPm1heF92Y3B1czsgaSsrKSB7Ci0gICAgICAgIGVudHNbMTIr
KGkqMildICAgPSBsaWJ4bF9fc3ByaW50ZihnYywgImNwdS8lZC9hdmFpbGFiaWxpdHkiLCBpKTsK
KyAgICAgICAgZW50c1sxMisoaSoyKV0gICA9IEdDU1BSSU5URigiY3B1LyVkL2F2YWlsYWJpbGl0
eSIsIGkpOwogICAgICAgICBlbnRzWzEyKyhpKjIpKzFdID0gbGlieGxfYml0bWFwX3Rlc3QoJmlu
Zm8tPmF2YWlsX3ZjcHVzLCBpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIm9ubGlu
ZSIgOiAib2ZmbGluZSI7CiAgICAgfQpAQCAtMzM1LDcgKzMzMyw3IEBAIGludCBsaWJ4bF9fYnVp
bGRfcG9zdChsaWJ4bF9fZ2MgKmdjLCB1aW4KICAgICBpZiAoaW5mby0+dHlwZSA9PSBMSUJYTF9E
T01BSU5fVFlQRV9IVk0pIHsKICAgICAgICAgaHZtX2VudHMgPSBsaWJ4bF9fY2FsbG9jKGdjLCAz
LCBzaXplb2YoY2hhciAqKSk7CiAgICAgICAgIGh2bV9lbnRzWzBdID0gImh2bWxvYWRlci9nZW5l
cmF0aW9uLWlkLWFkZHJlc3MiOwotICAgICAgICBodm1fZW50c1sxXSA9IGxpYnhsX19zcHJpbnRm
KGdjLCAiMHglbHgiLCBzdGF0ZS0+dm1fZ2VuZXJhdGlvbmlkX2FkZHIpOworICAgICAgICBodm1f
ZW50c1sxXSA9IEdDU1BSSU5URigiMHglbHgiLCBzdGF0ZS0+dm1fZ2VuZXJhdGlvbmlkX2FkZHIp
OwogICAgIH0KIAogICAgIGRvbV9wYXRoID0gbGlieGxfX3hzX2dldF9kb21wYXRoKGdjLCBkb21p
ZCk7CkBAIC0zNDMsNyArMzQxLDcgQEAgaW50IGxpYnhsX19idWlsZF9wb3N0KGxpYnhsX19nYyAq
Z2MsIHVpbgogICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsKICAgICB9CiAKLSAgICB2bV9wYXRo
ID0geHNfcmVhZChjdHgtPnhzaCwgWEJUX05VTEwsIGxpYnhsX19zcHJpbnRmKGdjLCAiJXMvdm0i
LCBkb21fcGF0aCksIE5VTEwpOworICAgIHZtX3BhdGggPSB4c19yZWFkKGN0eC0+eHNoLCBYQlRf
TlVMTCwgR0NTUFJJTlRGKCIlcy92bSIsIGRvbV9wYXRoKSwgTlVMTCk7CiByZXRyeV90cmFuc2Fj
dGlvbjoKICAgICB0ID0geHNfdHJhbnNhY3Rpb25fc3RhcnQoY3R4LT54c2gpOwogCkBAIC0zNzQs
NyArMzcyLDcgQEAgaW50IGxpYnhsX19idWlsZF9wdihsaWJ4bF9fZ2MgKmdjLCB1aW50MwogCiAg
ICAgZG9tID0geGNfZG9tX2FsbG9jYXRlKGN0eC0+eGNoLCBzdGF0ZS0+cHZfY21kbGluZSwgaW5m
by0+dS5wdi5mZWF0dXJlcyk7CiAgICAgaWYgKCFkb20pIHsKLSAgICAgICAgTElCWExfX0xPR19F
UlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4Y19kb21fYWxsb2NhdGUgZmFpbGVkIik7Cisg
ICAgICAgIExPR0UoRVJST1IsICJ4Y19kb21fYWxsb2NhdGUgZmFpbGVkIik7CiAgICAgICAgIHJl
dHVybiBFUlJPUl9GQUlMOwogICAgIH0KIApAQCAtMzg0LDEzICszODIsMTMgQEAgaW50IGxpYnhs
X19idWlsZF9wdihsaWJ4bF9fZ2MgKmdjLCB1aW50MwogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzdGF0ZS0+cHZfa2VybmVsLmRhdGEsCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0YXRlLT5wdl9rZXJuZWwuc2l6ZSk7CiAgICAgICAgIGlmICggcmV0ICE9IDApIHsK
LSAgICAgICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNf
ZG9tX2tlcm5lbF9tZW0gZmFpbGVkIik7CisgICAgICAgICAgICBMT0dFKEVSUk9SLCAieGNfZG9t
X2tlcm5lbF9tZW0gZmFpbGVkIik7CiAgICAgICAgICAgICBnb3RvIG91dDsKICAgICAgICAgfQog
ICAgIH0gZWxzZSB7CiAgICAgICAgIHJldCA9IHhjX2RvbV9rZXJuZWxfZmlsZShkb20sIHN0YXRl
LT5wdl9rZXJuZWwucGF0aCk7CiAgICAgICAgIGlmICggcmV0ICE9IDApIHsKLSAgICAgICAgICAg
IExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX2tlcm5lbF9m
aWxlIGZhaWxlZCIpOworICAgICAgICAgICAgTE9HRShFUlJPUiwgInhjX2RvbV9rZXJuZWxfZmls
ZSBmYWlsZWQiKTsKICAgICAgICAgICAgIGdvdG8gb3V0OwogICAgICAgICB9CiAgICAgfQpAQCAt
Mzk4LDEyICszOTYsMTIgQEAgaW50IGxpYnhsX19idWlsZF9wdihsaWJ4bF9fZ2MgKmdjLCB1aW50
MwogICAgIGlmICggc3RhdGUtPnB2X3JhbWRpc2sucGF0aCAmJiBzdHJsZW4oc3RhdGUtPnB2X3Jh
bWRpc2sucGF0aCkgKSB7CiAgICAgICAgIGlmIChzdGF0ZS0+cHZfcmFtZGlzay5tYXBwZWQpIHsK
ICAgICAgICAgICAgIGlmICggKHJldCA9IHhjX2RvbV9yYW1kaXNrX21lbShkb20sIHN0YXRlLT5w
dl9yYW1kaXNrLmRhdGEsIHN0YXRlLT5wdl9yYW1kaXNrLnNpemUpKSAhPSAwICkgewotICAgICAg
ICAgICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9t
X3JhbWRpc2tfbWVtIGZhaWxlZCIpOworICAgICAgICAgICAgICAgIExPR0UoRVJST1IsICJ4Y19k
b21fcmFtZGlza19tZW0gZmFpbGVkIik7CiAgICAgICAgICAgICAgICAgZ290byBvdXQ7CiAgICAg
ICAgICAgICB9CiAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICBpZiAoIChyZXQgPSB4Y19k
b21fcmFtZGlza19maWxlKGRvbSwgc3RhdGUtPnB2X3JhbWRpc2sucGF0aCkpICE9IDAgKSB7Ci0g
ICAgICAgICAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4
Y19kb21fcmFtZGlza19maWxlIGZhaWxlZCIpOworICAgICAgICAgICAgICAgIExPR0UoRVJST1Is
ICJ4Y19kb21fcmFtZGlza19maWxlIGZhaWxlZCIpOwogICAgICAgICAgICAgICAgIGdvdG8gb3V0
OwogICAgICAgICAgICAgfQogICAgICAgICB9CkBAIC00MTYsMzEgKzQxNCwzMSBAQCBpbnQgbGli
eGxfX2J1aWxkX3B2KGxpYnhsX19nYyAqZ2MsIHVpbnQzCiAgICAgZG9tLT54ZW5zdG9yZV9kb21p
ZCA9IHN0YXRlLT5zdG9yZV9kb21pZDsKIAogICAgIGlmICggKHJldCA9IHhjX2RvbV9ib290X3hl
bl9pbml0KGRvbSwgY3R4LT54Y2gsIGRvbWlkKSkgIT0gMCApIHsKLSAgICAgICAgTElCWExfX0xP
R19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4Y19kb21fYm9vdF94ZW5faW5pdCBmYWls
ZWQiKTsKKyAgICAgICAgTE9HRShFUlJPUiwgInhjX2RvbV9ib290X3hlbl9pbml0IGZhaWxlZCIp
OwogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX3BhcnNl
X2ltYWdlKGRvbSkpICE9IDAgKSB7Ci0gICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJY
TF9fTE9HX0VSUk9SLCAieGNfZG9tX3BhcnNlX2ltYWdlIGZhaWxlZCIpOworICAgICAgICBMT0dF
KEVSUk9SLCAieGNfZG9tX3BhcnNlX2ltYWdlIGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsK
ICAgICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX21lbV9pbml0KGRvbSwgaW5mby0+dGFyZ2V0
X21lbWtiIC8gMTAyNCkpICE9IDAgKSB7Ci0gICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBM
SUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX21lbV9pbml0IGZhaWxlZCIpOworICAgICAgICBMT0dF
KEVSUk9SLCAieGNfZG9tX21lbV9pbml0IGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAg
ICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX2Jvb3RfbWVtX2luaXQoZG9tKSkgIT0gMCApIHsK
LSAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ4Y19kb21f
Ym9vdF9tZW1faW5pdCBmYWlsZWQiKTsKKyAgICAgICAgTE9HRShFUlJPUiwgInhjX2RvbV9ib290
X21lbV9pbml0IGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAgICAgaWYgKCAo
cmV0ID0geGNfZG9tX2J1aWxkX2ltYWdlKGRvbSkpICE9IDAgKSB7Ci0gICAgICAgIExJQlhMX19M
T0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX2J1aWxkX2ltYWdlIGZhaWxl
ZCIpOworICAgICAgICBMT0dFKEVSUk9SLCAieGNfZG9tX2J1aWxkX2ltYWdlIGZhaWxlZCIpOwog
ICAgICAgICBnb3RvIG91dDsKICAgICB9CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX2Jvb3RfaW1h
Z2UoZG9tKSkgIT0gMCApIHsKLSAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19M
T0dfRVJST1IsICJ4Y19kb21fYm9vdF9pbWFnZSBmYWlsZWQiKTsKKyAgICAgICAgTE9HRShFUlJP
UiwgInhjX2RvbV9ib290X2ltYWdlIGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9
CiAgICAgaWYgKCAocmV0ID0geGNfZG9tX2dudHRhYl9pbml0KGRvbSkpICE9IDAgKSB7Ci0gICAg
ICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAieGNfZG9tX2dudHRh
Yl9pbml0IGZhaWxlZCIpOworICAgICAgICBMT0dFKEVSUk9SLCAieGNfZG9tX2dudHRhYl9pbml0
IGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9CiAKQEAgLTY4NSw4ICs2ODMsNyBA
QCBpbnQgbGlieGxfX3FlbXVfdHJhZGl0aW9uYWxfY21kKGxpYnhsX19nCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmNtZCkKIHsKICAgICBjaGFyICpwYXRoID0g
TlVMTDsKLSAgICBwYXRoID0gbGlieGxfX3NwcmludGYoZ2MsICIvbG9jYWwvZG9tYWluLzAvZGV2
aWNlLW1vZGVsLyVkL2NvbW1hbmQiLAotICAgICAgICAgICAgICAgICAgICAgICAgICBkb21pZCk7
CisgICAgcGF0aCA9IEdDU1BSSU5URigiL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8lZC9j
b21tYW5kIiwgZG9taWQpOwogICAgIHJldHVybiBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9OVUxM
LCBwYXRoLCAiJXMiLCBjbWQpOwogfQogCkBAIC03MDMsOCArNzAwLDcgQEAgc3RydWN0IGxpYnhs
X19waHlzbWFwX2luZm8gewogc3RhdGljIGlubGluZSBjaGFyICpyZXN0b3JlX2hlbHBlcihsaWJ4
bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCwKICAgICAgICAgdWludDY0X3QgcGh5c19vZmZzZXQs
IGNoYXIgKm5vZGUpCiB7Ci0gICAgcmV0dXJuIGxpYnhsX19zcHJpbnRmKGdjLAotICAgICAgICAg
ICAgIi9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvJWQvcGh5c21hcC8lIlBSSXg2NCIvJXMi
LAorICAgIHJldHVybiBHQ1NQUklOVEYoIi9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvJWQv
cGh5c21hcC8lIlBSSXg2NCIvJXMiLAogICAgICAgICAgICAgZG9taWQsIHBoeXNfb2Zmc2V0LCBu
b2RlKTsKIH0KIApAQCAtNzE0LDcgKzcxMCw2IEBAIGludCBsaWJ4bF9fdG9vbHN0YWNrX3Jlc3Rv
cmUodWludDMyX3QgZG8KICAgICBsaWJ4bF9fc2F2ZV9oZWxwZXJfc3RhdGUgKnNocyA9IHVzZXI7
CiAgICAgbGlieGxfX2RvbWFpbl9jcmVhdGVfc3RhdGUgKmRjcyA9IENPTlRBSU5FUl9PRihzaHMs
ICpkY3MsIHNocyk7CiAgICAgU1RBVEVfQU9fR0MoZGNzLT5hbyk7Ci0gICAgbGlieGxfY3R4ICpj
dHggPSBDVFg7CiAgICAgaW50IGksIHJldDsKICAgICBjb25zdCB1aW50OF90ICpwdHIgPSBidWY7
CiAgICAgdWludDMyX3QgY291bnQgPSAwLCB2ZXJzaW9uID0gMDsKQEAgLTcyNCw3ICs3MTksNyBA
QCBpbnQgbGlieGxfX3Rvb2xzdGFja19yZXN0b3JlKHVpbnQzMl90IGRvCiAgICAgTE9HKERFQlVH
LCJkb21haW49JSJQUkl1MzIiIHRvb2xzdGFjayBkYXRhIHNpemU9JSJQUkl1MzIsIGRvbWlkLCBz
aXplKTsKIAogICAgIGlmIChzaXplIDwgc2l6ZW9mKHZlcnNpb24pICsgc2l6ZW9mKGNvdW50KSkg
ewotICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwgIndyb25nIHNpemUi
KTsKKyAgICAgICAgTE9HKEVSUk9SLCAid3Jvbmcgc2l6ZSIpOwogICAgICAgICByZXR1cm4gLTE7
CiAgICAgfQogCkBAIC03MzIsNyArNzI3LDcgQEAgaW50IGxpYnhsX190b29sc3RhY2tfcmVzdG9y
ZSh1aW50MzJfdCBkbwogICAgIHB0ciArPSBzaXplb2YodmVyc2lvbik7CiAKICAgICBpZiAodmVy
c2lvbiAhPSBUT09MU1RBQ0tfU0FWRV9WRVJTSU9OKSB7Ci0gICAgICAgIExJQlhMX19MT0coY3R4
LCBMSUJYTF9fTE9HX0VSUk9SLCAid3JvbmcgdmVyc2lvbiIpOworICAgICAgICBMT0coRVJST1Is
ICJ3cm9uZyB2ZXJzaW9uIik7CiAgICAgICAgIHJldHVybiAtMTsKICAgICB9CiAKQEAgLTc0MSw3
ICs3MzYsNyBAQCBpbnQgbGlieGxfX3Rvb2xzdGFja19yZXN0b3JlKHVpbnQzMl90IGRvCiAKICAg
ICBpZiAoc2l6ZSA8IHNpemVvZih2ZXJzaW9uKSArIHNpemVvZihjb3VudCkgKwogICAgICAgICAg
ICAgY291bnQgKiAoc2l6ZW9mKHN0cnVjdCBsaWJ4bF9fcGh5c21hcF9pbmZvKSkpIHsKLSAgICAg
ICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ3cm9uZyBzaXplIik7CisgICAg
ICAgIExPRyhFUlJPUiwgIndyb25nIHNpemUiKTsKICAgICAgICAgcmV0dXJuIC0xOwogICAgIH0K
IApAQCAtOTkwLDE1ICs5ODUsMTMgQEAgc3RhdGljIHZvaWQgc3dpdGNoX2xvZ2RpcnR5X2RvbmUo
bGlieGxfXwogaW50IGxpYnhsX19kb21haW5fc3VzcGVuZF9kZXZpY2VfbW9kZWwobGlieGxfX2dj
ICpnYywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX19kb21h
aW5fc3VzcGVuZF9zdGF0ZSAqZHNzKQogewotICAgIGxpYnhsX2N0eCAqY3R4ID0gbGlieGxfX2dj
X293bmVyKGdjKTsKICAgICBpbnQgcmV0ID0gMDsKICAgICB1aW50MzJfdCBjb25zdCBkb21pZCA9
IGRzcy0+ZG9taWQ7CiAgICAgY29uc3QgY2hhciAqY29uc3QgZmlsZW5hbWUgPSBkc3MtPmRtX3Nh
dmVmaWxlOwogCiAgICAgc3dpdGNoIChsaWJ4bF9fZGV2aWNlX21vZGVsX3ZlcnNpb25fcnVubmlu
ZyhnYywgZG9taWQpKSB7CiAgICAgY2FzZSBMSUJYTF9ERVZJQ0VfTU9ERUxfVkVSU0lPTl9RRU1V
X1hFTl9UUkFESVRJT05BTDogewotICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19E
RUJVRywKLSAgICAgICAgICAgICAgICAgICAiU2F2aW5nIGRldmljZSBtb2RlbCBzdGF0ZSB0byAl
cyIsIGZpbGVuYW1lKTsKKyAgICAgICAgTE9HKERFQlVHLCAiU2F2aW5nIGRldmljZSBtb2RlbCBz
dGF0ZSB0byAlcyIsIGZpbGVuYW1lKTsKICAgICAgICAgbGlieGxfX3FlbXVfdHJhZGl0aW9uYWxf
Y21kKGdjLCBkb21pZCwgInNhdmUiKTsKICAgICAgICAgbGlieGxfX3dhaXRfZm9yX2RldmljZV9t
b2RlbChnYywgZG9taWQsICJwYXVzZWQiLCBOVUxMLCBOVUxMLCBOVUxMKTsKICAgICAgICAgYnJl
YWs7CkBAIC0xMTc0LDggKzExNjcsNyBAQCBpbnQgbGlieGxfX2RvbWFpbl9zdXNwZW5kX2NvbW1v
bl9jYWxsYmFjCiBzdGF0aWMgaW5saW5lIGNoYXIgKnBoeXNtYXBfcGF0aChsaWJ4bF9fZ2MgKmdj
LCB1aW50MzJfdCBkb21pZCwKICAgICAgICAgY2hhciAqcGh5c19vZmZzZXQsIGNoYXIgKm5vZGUp
CiB7Ci0gICAgcmV0dXJuIGxpYnhsX19zcHJpbnRmKGdjLAotICAgICAgICAgICAgIi9sb2NhbC9k
b21haW4vMC9kZXZpY2UtbW9kZWwvJWQvcGh5c21hcC8lcy8lcyIsCisgICAgcmV0dXJuIEdDU1BS
SU5URigiL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8lZC9waHlzbWFwLyVzLyVzIiwKICAg
ICAgICAgICAgIGRvbWlkLCBwaHlzX29mZnNldCwgbm9kZSk7CiB9CiAKQEAgLTExOTIsNyArMTE4
NCw3IEBAIGludCBsaWJ4bF9fdG9vbHN0YWNrX3NhdmUodWludDMyX3QgZG9taWQKICAgICBjaGFy
ICoqZW50cmllcyA9IE5VTEw7CiAgICAgc3RydWN0IGxpYnhsX19waHlzbWFwX2luZm8gKnBpOwog
Ci0gICAgZW50cmllcyA9IGxpYnhsX194c19kaXJlY3RvcnkoZ2MsIDAsIGxpYnhsX19zcHJpbnRm
KGdjLAorICAgIGVudHJpZXMgPSBsaWJ4bF9feHNfZGlyZWN0b3J5KGdjLCAwLCBHQ1NQUklOVEYo
CiAgICAgICAgICAgICAgICAgIi9sb2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvJWQvcGh5c21h
cCIsIGRvbWlkKSwgJm51bSk7CiAgICAgY291bnQgPSBudW07CiAKQEAgLTEzMzMsNyArMTMyNSw3
IEBAIHZvaWQgbGlieGxfX2RvbWFpbl9zdXNwZW5kKGxpYnhsX19lZ2MgKmUKICAgICAgICAgY2hh
ciAqcGF0aDsKICAgICAgICAgY2hhciAqYWRkcjsKIAotICAgICAgICBwYXRoID0gbGlieGxfX3Nw
cmludGYoZ2MsICIlcy9odm1sb2FkZXIvZ2VuZXJhdGlvbi1pZC1hZGRyZXNzIiwKKyAgICAgICAg
cGF0aCA9IEdDU1BSSU5URigiJXMvaHZtbG9hZGVyL2dlbmVyYXRpb24taWQtYWRkcmVzcyIsCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9feHNfZ2V0X2RvbXBhdGgoZ2MsIGRv
bWlkKSk7CiAgICAgICAgIGFkZHIgPSBsaWJ4bF9feHNfcmVhZChnYywgWEJUX05VTEwsIHBhdGgp
OwogCkBAIC0xNTQ3LDEwICsxNTM5LDcgQEAgc3RhdGljIHZvaWQgZG9tYWluX3N1c3BlbmRfZG9u
ZShsaWJ4bF9fZQogCiBjaGFyICpsaWJ4bF9fdXVpZDJzdHJpbmcobGlieGxfX2djICpnYywgY29u
c3QgbGlieGxfdXVpZCB1dWlkKQogewotICAgIGNoYXIgKnMgPSBsaWJ4bF9fc3ByaW50ZihnYywg
TElCWExfVVVJRF9GTVQsIExJQlhMX1VVSURfQllURVModXVpZCkpOwotICAgIGlmICghcykKLSAg
ICAgICAgTElCWExfX0xPRyhsaWJ4bF9fZ2Nfb3duZXIoZ2MpLCBMSUJYTF9fTE9HX0VSUk9SLCAi
Y2Fubm90IGFsbG9jYXRlIGZvciB1dWlkIik7Ci0gICAgcmV0dXJuIHM7CisgICAgcmV0dXJuIEdD
U1BSSU5URihMSUJYTF9VVUlEX0ZNVCwgTElCWExfVVVJRF9CWVRFUyh1dWlkKSk7CiB9CiAKIHN0
YXRpYyBjb25zdCBjaGFyICp1c2VyZGF0YV9wYXRoKGxpYnhsX19nYyAqZ2MsIHVpbnQzMl90IGRv
bWlkLApAQCAtMTU1OCwzNCArMTU0NywyOCBAQCBzdGF0aWMgY29uc3QgY2hhciAqdXNlcmRhdGFf
cGF0aChsaWJ4bF9fCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0
IGNoYXIgKndoKQogewogICAgIGxpYnhsX2N0eCAqY3R4ID0gbGlieGxfX2djX293bmVyKGdjKTsK
LSAgICBjaGFyICpwYXRoLCAqdXVpZF9zdHJpbmc7CisgICAgY2hhciAqdXVpZF9zdHJpbmc7CiAg
ICAgbGlieGxfZG9taW5mbyBpbmZvOwogICAgIGludCByYzsKIAogICAgIHJjID0gbGlieGxfZG9t
YWluX2luZm8oY3R4LCAmaW5mbywgZG9taWQpOwogICAgIGlmIChyYykgewotICAgICAgICBMSUJY
TF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgInVuYWJsZSB0byBmaW5kIGRvbWFp
biBpbmZvIgotICAgICAgICAgICAgICAgICAgICAgIiBmb3IgZG9tYWluICUiUFJJdTMyLCBkb21p
ZCk7CisgICAgICAgIExPR0UoRVJST1IsICJ1bmFibGUgdG8gZmluZCBkb21haW4gaW5mbyBmb3Ig
ZG9tYWluICUiUFJJdTMyLCBkb21pZCk7CiAgICAgICAgIHJldHVybiBOVUxMOwogICAgIH0KLSAg
ICB1dWlkX3N0cmluZyA9IGxpYnhsX19zcHJpbnRmKGdjLCBMSUJYTF9VVUlEX0ZNVCwgTElCWExf
VVVJRF9CWVRFUyhpbmZvLnV1aWQpKTsKKyAgICB1dWlkX3N0cmluZyA9IEdDU1BSSU5URihMSUJY
TF9VVUlEX0ZNVCwgTElCWExfVVVJRF9CWVRFUyhpbmZvLnV1aWQpKTsKIAotICAgIHBhdGggPSBs
aWJ4bF9fc3ByaW50ZihnYywgIi92YXIvbGliL3hlbi8iCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgInVzZXJkYXRhLSVzLiV1LiVzLiVzIiwKLSAgICAgICAgICAgICAgICAgICAgICAgICB3aCwg
ZG9taWQsIHV1aWRfc3RyaW5nLCB1c2VyZGF0YV91c2VyaWQpOwotICAgIGlmICghcGF0aCkKLSAg
ICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJ1bmFibGUgdG8g
YWxsb2NhdGUgZm9yIgotICAgICAgICAgICAgICAgICAgICAgIiB1c2VyZGF0YSBwYXRoIik7Ci0g
ICAgcmV0dXJuIHBhdGg7CisgICAgcmV0dXJuIEdDU1BSSU5URigiL3Zhci9saWIveGVuL3VzZXJk
YXRhLSVzLiV1LiVzLiVzIiwKKyAgICAgICAgICAgICAgICAgICAgIHdoLCBkb21pZCwgdXVpZF9z
dHJpbmcsIHVzZXJkYXRhX3VzZXJpZCk7CiB9CiAKIHN0YXRpYyBpbnQgdXNlcmRhdGFfZGVsZXRl
KGxpYnhsX19nYyAqZ2MsIGNvbnN0IGNoYXIgKnBhdGgpCiB7Ci0gICAgbGlieGxfY3R4ICpjdHgg
PSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwogICAgIGludCByOworCiAgICAgciA9IHVubGluayhwYXRo
KTsKICAgICBpZiAocikgewotICAgICAgICBMSUJYTF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xP
R19FUlJPUiwgInJlbW92ZSBmYWlsZWQgZm9yICVzIiwgcGF0aCk7CisgICAgICAgIExPR0UoRVJS
T1IsICJyZW1vdmUgZmFpbGVkIGZvciAlcyIsIHBhdGgpOwogICAgICAgICByZXR1cm4gZXJybm87
CiAgICAgfQogICAgIHJldHVybiAwOwpAQCAtMTU5Myw3ICsxNTc2LDYgQEAgc3RhdGljIGludCB1
c2VyZGF0YV9kZWxldGUobGlieGxfX2djICpnYwogCiB2b2lkIGxpYnhsX191c2VyZGF0YV9kZXN0
cm95YWxsKGxpYnhsX19nYyAqZ2MsIHVpbnQzMl90IGRvbWlkKQogewotICAgIGxpYnhsX2N0eCAq
Y3R4ID0gbGlieGxfX2djX293bmVyKGdjKTsKICAgICBjb25zdCBjaGFyICpwYXR0ZXJuOwogICAg
IGdsb2JfdCBnbDsKICAgICBpbnQgciwgaTsKQEAgLTE2MDksNyArMTU5MSw3IEBAIHZvaWQgbGli
eGxfX3VzZXJkYXRhX2Rlc3Ryb3lhbGwobGlieGxfX2cKICAgICBpZiAociA9PSBHTE9CX05PTUFU
Q0gpCiAgICAgICAgIGdvdG8gb3V0OwogICAgIGlmIChyKQotICAgICAgICBMSUJYTF9fTE9HX0VS
Uk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImdsb2IgZmFpbGVkIGZvciAlcyIsIHBhdHRlcm4p
OworICAgICAgICBMT0dFKEVSUk9SLCAiZ2xvYiBmYWlsZWQgZm9yICVzIiwgcGF0dGVybik7CiAK
ICAgICBmb3IgKGk9MDsgaTxnbC5nbF9wYXRoYzsgaSsrKSB7CiAgICAgICAgIHVzZXJkYXRhX2Rl
bGV0ZShnYywgZ2wuZ2xfcGF0aHZbaV0pOwo=

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_
Content-Type: application/octet-stream; name="fb80b3380e.aa.sf"
Content-Description: fb80b3380e.aa.sf
Content-Disposition: attachment; filename="fb80b3380e.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:14:47 GMT";
	modification-date="Fri, 01 Feb 2013 20:14:47 GMT"
Content-Transfer-Encoding: base64

ZmI4MGIzMzgwZQ0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXGZiODBiMzM4MGVcDQowDQowDQowDQpOT05FDQpOT05F

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

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

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E7FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20:16: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 1U1N2K-0001zh-6B; Fri, 01 Feb 2013 20:16:36 +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 1U1N2D-0001yo-PR
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:16:30 +0000
Received: from [85.158.139.83:15135] by server-9.bemta-5.messagelabs.com id
	FD/FD-24440-D922C015; Fri, 01 Feb 2013 20:16:29 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1359749786!26509409!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31906 invoked from network); 1 Feb 2013 20:16:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="sf'?scan'208";a="6006872"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:16:26 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:16:25 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:16:23 -0500
Thread-Topic: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuJp3Hz//Rl8lSMKCG0xjKR9GAQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This patch introduces support for two new parameters in libxl:

smbios_firmware=3D<path_to_smbios_structures_file>
acpi_firmware=3D<path_to_acpi_tables_file>

The changes are primarily in the domain building code where the firmware fi=
les
are read and passed to libxc for loading into the new guest. After the doma=
in
building call to libxc, the addresses for the loaded blobs are returned and
written to xenstore.

LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users to
determine if the feature is present.
=20
This patch also updates the xl.cfg man page with descriptions of the two ne=
w
parameters for firmware passthrough.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_
Content-Type: application/octet-stream;
	name="hvm-firmware-passthrough-libxl-v2-02.patch"
Content-Description: hvm-firmware-passthrough-libxl-v2-02.patch
Content-Disposition: attachment;
	filename="hvm-firmware-passthrough-libxl-v2-02.patch"; size=11346;
	creation-date="Fri, 01 Feb 2013 19:55:13 GMT";
	modification-date="Fri, 01 Feb 2013 19:55:13 GMT"
Content-Transfer-Encoding: base64

VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIHN1cHBvcnQgZm9yIHR3byBuZXcgcGFyYW1ldGVycyBpbiBs
aWJ4bDoKCnNtYmlvc19maXJtd2FyZT08cGF0aF90b19zbWJpb3Nfc3RydWN0dXJlc19maWxlPgph
Y3BpX2Zpcm13YXJlPTxwYXRoX3RvX2FjcGlfdGFibGVzX2ZpbGU+CgpUaGUgY2hhbmdlcyBhcmUg
cHJpbWFyaWx5IGluIHRoZSBkb21haW4gYnVpbGRpbmcgY29kZSB3aGVyZSB0aGUgZmlybXdhcmUg
ZmlsZXMKYXJlIHJlYWQgYW5kIHBhc3NlZCB0byBsaWJ4YyBmb3IgbG9hZGluZyBpbnRvIHRoZSBu
ZXcgZ3Vlc3QuIEFmdGVyIHRoZSBkb21haW4KYnVpbGRpbmcgY2FsbCB0byBsaWJ4YywgdGhlIGFk
ZHJlc3NlcyBmb3IgdGhlIGxvYWRlZCBibG9icyBhcmUgcmV0dXJuZWQgYW5kCndyaXR0ZW4gdG8g
eGVuc3RvcmUuCgpMSUJYTF9IQVZFX0ZJUk1XQVJFX1BBU1NUSFJPVUdIIGlzIGRlZmluZWQgaW4g
bGlieGwuaCB0byBhbGxvdyB1c2VycyB0bwpkZXRlcm1pbmUgaWYgdGhlIGZlYXR1cmUgaXMgcHJl
c2VudC4KIApUaGlzIHBhdGNoIGFsc28gdXBkYXRlcyB0aGUgeGwuY2ZnIG1hbiBwYWdlIHdpdGgg
ZGVzY3JpcHRpb25zIG9mIHRoZSB0d28gbmV3CnBhcmFtZXRlcnMgZm9yIGZpcm13YXJlIHBhc3N0
aHJvdWdoLgoKU2lnbmVkLW9mZi1ieTogUm9zcyBQaGlsaXBzb24gPHJvc3MucGhpbGlwc29uQGNp
dHJpeC5jb20+CgpkaWZmIC1yIDI1YjI4Yjc2ZmM2OCBkb2NzL21hbi94bC5jZmcucG9kLjUKLS0t
IGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41CUZyaSBGZWIgMDEgMTA6MjA6MjUgMjAxMyAtMDUwMAor
KysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUJRnJpIEZlYiAwMSAxMToyNDoyMSAyMDEzIC0wNTAw
CkBAIC04MjksNiArODI5LDI1IEBAIGxpYnhsOiAnaG9zdCx0bT0wLHNzZTM9MCcKIE1vcmUgaW5m
byBhYm91dCB0aGUgQ1BVSUQgaW5zdHJ1Y3Rpb24gY2FuIGJlIGZvdW5kIGluIHRoZSBwcm9jZXNz
b3IgbWFudWFscywgYW5kCiBpbiBXaWtpcGVkaWE6IEw8aHR0cDovL2VuLndpa2lwZWRpYS5vcmcv
d2lraS9DUFVJRD4KIAorPWl0ZW0gQjxhY3BpX2Zpcm13YXJlPSJTVFJJTkciPgorCitTcGVjaWZ5
IGEgcGF0aCB0byBhIGZpbGUgdGhhdCBjb250YWlucyBleHRyYSBBQ1BJIGZpcm13YXJlIHRhYmxl
cyB0byBwYXNzIGluIHRvCithIGd1ZXN0LiBUaGUgZmlsZSBjYW4gY29udGFpbiBzZXZlcmFsIHRh
YmxlcyBpbiB0aGVpciBiaW5hcnkgQU1MIGZvcm0KK2NvbmNhdGVuYXRlZCB0b2dldGhlci4gRWFj
aCB0YWJsZSBzZWxmIGRlc2NyaWJlcyBpdHMgbGVuZ3RoIHNvIG5vIGFkZGl0aW9uYWwKK2luZm9y
bWF0aW9uIGlzIG5lZWRlZC4gVGhlc2UgdGFibGVzIHdpbGwgYmUgYWRkZWQgdG8gdGhlIEFDUEkg
dGFibGUgc2V0IGluIHRoZQorZ3Vlc3QuIE5vdGUgdGhhdCBleGlzdGluZyB0YWJsZXMgY2Fubm90
IGJlIG92ZXJyaWRlbiBieSB0aGlzIGZlYXR1cmUuIEZvcgorZXhhbXBsZSB0aGlzIGNhbm5vdCBi
ZSB1c2VkIHRvIG92ZXJyaWRlIHRhYmxlcyBsaWtlIERTRFQsIEZBRFQsIGV0Yy4KKworPWl0ZW0g
QjxzbWJpb3NfZmlybXdhcmU9IlNUUklORyI+CisKK1NwZWNpZnkgYSBwYXRoIHRvIGEgZmlsZSB0
aGF0IGNvbnRhaW5zIGV4dHJhIFNNQklPUyBmaXJtd2FyZSBzdHJ1Y3R1cmVzIHRvIHBhc3MKK2lu
IHRvIGEgZ3Vlc3QuIFRoZSBmaWxlIGNhbiBjb250YWluIGEgc2V0IERNVEYgcHJlZGVmaW5lZCBz
dHJ1Y3R1cmVzIHdoaWNoIHdpbGwKK292ZXJyaWRlIHRoZSBpbnRlcm5hbCBkZWZhdWx0cy4gTm90
IGFsbCBwcmVkZWZpbmVkIHN0cnVjdHVyZXMgY2FuIGJlIG92ZXJyaWRlbiwKK29ubHkgdGhlIGZv
bGxvd2luZyB0eXBlczogMCwgMSwgMiwgMywgMTEsIDIyLCAzOS4gVGhlIGZpbGUgY2FuIGFsc28g
Y29udGFpbiBhbnkKK251bWJlciBvZiB2ZW5kb3IgZGVmaW5lZCBTTUJJT1Mgc3RydWN0dXJlcyAo
dHlwZSAxMjggLSAyNTUpLiBTaW5jZSBTTUJJT1MKK3N0cnVjdHVyZXMgZG8gbm90IHByZXNlbnQg
dGhlaXIgb3ZlcmFsbCBzaXplLCBlYWNoIGVudHJ5IGluIHRoZSBmaWxlIG11c3QgYmUKK3ByZWNl
ZWRlZCBieSBhIDMyYiBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIHNpemUgb2YgdGhlIG5leHQgc3Ry
dWN0dXJlLgorCiA9YmFjayAKIAogPWhlYWQzIEd1ZXN0IFZpcnR1YWwgVGltZSBDb250cm9scwpk
aWZmIC1yIDI1YjI4Yjc2ZmM2OCB0b29scy9saWJ4bC9saWJ4bC5oCi0tLSBhL3Rvb2xzL2xpYnhs
L2xpYnhsLmgJRnJpIEZlYiAwMSAxMDoyMDoyNSAyMDEzIC0wNTAwCisrKyBiL3Rvb2xzL2xpYnhs
L2xpYnhsLmgJRnJpIEZlYiAwMSAxMToyNDoyMSAyMDEzIC0wNTAwCkBAIC02OCw2ICs2OCwxMyBA
QAogICovCiAKIC8qCisgKiBMSUJYTF9IQVZFX0ZJUk1XQVJFX1BBU1NUSFJPVUdIIGluZGljYXRl
cyB0aGUgbmV3IGZlYXR1cmUgZm9yCisgKiBwYXNzaW5nIGluIFNNQklPUyBhbmQgQUNQSSBmaXJt
d2FyZSB0byBIVk0gZ3Vlc3RzIGlzIHByZXNlbnQKKyAqIGluIHRoZSBsaWJyYXJ5LgorICovCisj
ZGVmaW5lIExJQlhMX0hBVkVfRklSTVdBUkVfUEFTU1RIUk9VR0ggMQorCisvKgogICogbGlieGwg
QUJJIGNvbXBhdGliaWxpdHkKICAqCiAgKiBUaGUgb25seSBndWFyYW50ZWUgd2hpY2ggbGlieGwg
bWFrZXMgcmVnYXJkaW5nIEFCSSBjb21wYXRpYmlsaXR5CmRpZmYgLXIgMjViMjhiNzZmYzY4IHRv
b2xzL2xpYnhsL2xpYnhsX2RvbS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCUZyaSBG
ZWIgMDEgMTA6MjA6MjUgMjAxMyAtMDUwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9kb20uYwlG
cmkgRmViIDAxIDExOjI0OjIxIDIwMTMgLTA1MDAKQEAgLTIxLDYgKzIxLDcgQEAKIAogI2luY2x1
ZGUgPHhjX2RvbS5oPgogI2luY2x1ZGUgPHhlbi9odm0vaHZtX2luZm9fdGFibGUuaD4KKyNpbmNs
dWRlIDx4ZW4vaHZtL2h2bV94c19zdHJpbmdzLmg+CiAKIGxpYnhsX2RvbWFpbl90eXBlIGxpYnhs
X19kb21haW5fdHlwZShsaWJ4bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCkKIHsKQEAgLTUxMCwx
MSArNTExLDYxIEBAIHN0YXRpYyBpbnQgaHZtX2J1aWxkX3NldF9wYXJhbXMoeGNfaW50ZXIKICAg
ICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGNvbnN0IGNoYXIgKmxpYnhsX19kb21haW5fZmlybXdh
cmUobGlieGxfX2djICpnYywKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvICppbmZvKQorc3RhdGljIGludCBodm1fYnVpbGRf
c2V0X3hzX3ZhbHVlcyhsaWJ4bF9fZ2MgKmdjLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3RydWN0IHhjX2h2bV9idWlsZF9hcmdzICphcmdzKQoreworICAgIGNoYXIgKnBhdGggPSBO
VUxMOworICAgIGludCByZXQgPSAwOworCisgICAgaWYgKGFyZ3MtPnNtYmlvc19tb2R1bGUuZ3Vl
c3RfYWRkcl9vdXQpIHsKKyAgICAgICAgcGF0aCA9IEdDU1BSSU5URigiL2xvY2FsL2RvbWFpbi8l
ZC8iSFZNX1hTX1NNQklPU19QVF9BRERSRVNTLCBkb21pZCk7CisKKyAgICAgICAgcmV0ID0gbGli
eGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgcGF0aCwgIjB4JSJQUkl4NjQsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBhcmdzLT5zbWJpb3NfbW9kdWxlLmd1ZXN0X2FkZHJfb3V0KTsK
KyAgICAgICAgaWYgKHJldCkKKyAgICAgICAgICAgIGdvdG8gZXJyOworCisgICAgICAgIHBhdGgg
PSBHQ1NQUklOVEYoIi9sb2NhbC9kb21haW4vJWQvIkhWTV9YU19TTUJJT1NfUFRfTEVOR1RILCBk
b21pZCk7CisKKyAgICAgICAgcmV0ID0gbGlieGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgcGF0
aCwgIjB4JXgiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJncy0+c21iaW9zX21v
ZHVsZS5sZW5ndGgpOworICAgICAgICBpZiAocmV0KQorICAgICAgICAgICAgZ290byBlcnI7Cisg
ICAgfQorCisgICAgaWYgKGFyZ3MtPmFjcGlfbW9kdWxlLmd1ZXN0X2FkZHJfb3V0KSB7CisgICAg
ICAgIHBhdGggPSBHQ1NQUklOVEYoIi9sb2NhbC9kb21haW4vJWQvIkhWTV9YU19BQ1BJX1BUX0FE
RFJFU1MsIGRvbWlkKTsKKworICAgICAgICByZXQgPSBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9O
VUxMLCBwYXRoLCAiMHglIlBSSXg2NCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFy
Z3MtPmFjcGlfbW9kdWxlLmd1ZXN0X2FkZHJfb3V0KTsKKyAgICAgICAgaWYgKHJldCkKKyAgICAg
ICAgICAgIGdvdG8gZXJyOworCisgICAgICAgIHBhdGggPSBHQ1NQUklOVEYoIi9sb2NhbC9kb21h
aW4vJWQvIkhWTV9YU19BQ1BJX1BUX0xFTkdUSCwgZG9taWQpOworCisgICAgICAgIHJldCA9IGxp
YnhsX194c193cml0ZShnYywgWEJUX05VTEwsIHBhdGgsICIweCV4IiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGFyZ3MtPmFjcGlfbW9kdWxlLmxlbmd0aCk7CisgICAgICAgIGlmIChy
ZXQpCisgICAgICAgICAgICBnb3RvIGVycjsKKyAgICB9CisKKyAgICByZXR1cm4gMDsKKworZXJy
OgorICAgIExPRyhFUlJPUiwgImZhaWxlZCB0byB3cml0ZSBmaXJtd2FyZSB4ZW5zdG9yZSB2YWx1
ZSwgZXJyOiAlZCIsIHJldCk7CisgICAgcmV0dXJuIC0xOworfQorCitzdGF0aWMgaW50IGxpYnhs
X19kb21haW5fZmlybXdhcmUobGlieGxfX2djICpnYywKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyAqaW5mbywKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGNfaHZtX2J1aWxkX2FyZ3MgKmFyZ3MpCiB7CiAg
ICAgbGlieGxfY3R4ICpjdHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwogICAgIGNvbnN0IGNoYXIg
KmZpcm13YXJlOworICAgIGludCBlLCByYyA9IEVSUk9SX0ZBSUw7CisgICAgaW50IGRhdGFsZW4g
PSAwOworICAgIHZvaWQgKmRhdGEgPSAwOwogCiAgICAgaWYgKGluZm8tPnUuaHZtLmZpcm13YXJl
KQogICAgICAgICBmaXJtd2FyZSA9IGluZm8tPnUuaHZtLmZpcm13YXJlOwpAQCAtNTI4LDEzICs1
NzksNTggQEAgc3RhdGljIGNvbnN0IGNoYXIgKmxpYnhsX19kb21haW5fZmlybXdhcgogICAgICAg
ICAgICAgZmlybXdhcmUgPSAiaHZtbG9hZGVyIjsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAg
ICBkZWZhdWx0OgotICAgICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1Is
ICJpbnZhbGlkIGRldmljZSBtb2RlbCB2ZXJzaW9uICVkIiwKLSAgICAgICAgICAgICAgICAgICAg
ICAgaW5mby0+ZGV2aWNlX21vZGVsX3ZlcnNpb24pOwotICAgICAgICAgICAgcmV0dXJuIE5VTEw7
CisgICAgICAgICAgICBMT0coRVJST1IsICJpbnZhbGlkIGRldmljZSBtb2RlbCB2ZXJzaW9uICVk
IiwKKyAgICAgICAgICAgICAgICBpbmZvLT5kZXZpY2VfbW9kZWxfdmVyc2lvbik7CisgICAgICAg
ICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgfQogICAgIH0KLSAg
ICByZXR1cm4gbGlieGxfX2Fic19wYXRoKGdjLCBmaXJtd2FyZSwgbGlieGxfX3hlbmZpcm13YXJl
ZGlyX3BhdGgoKSk7CisgICAgYXJncy0+aW1hZ2VfZmlsZV9uYW1lID0gbGlieGxfX2Fic19wYXRo
KGdjLCBmaXJtd2FyZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbGlieGxfX3hlbmZpcm13YXJlZGlyX3BhdGgoKSk7CisgICAgaWYgKCFhcmdzLT5pbWFnZV9m
aWxlX25hbWUpIHsKKyAgICAgICAgTE9HKEVSUk9SLCAiaW52YWxpZCBmaXJtd2FyZSBwYXRoIik7
CisgICAgICAgIHJldHVybiAtMTsKKyAgICB9CisKKyAgICBpZiAoaW5mby0+dS5odm0uc21iaW9z
X2Zpcm13YXJlKSB7CisgICAgICAgIGUgPSBsaWJ4bF9yZWFkX2ZpbGVfY29udGVudHMoY3R4LCBp
bmZvLT51Lmh2bS5zbWJpb3NfZmlybXdhcmUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmRhdGEsICZkYXRhbGVuKTsKKyAgICAgICAgaWYgKGUpIHsKKyAgICAgICAgICAg
IExPRyhFUlJPUiwgImZhaWxlZCB0byByZWFkIFNNQklPUyBmaXJtd2FyZSBmaWxlICVzIiwKKyAg
ICAgICAgICAgICAgICBpbmZvLT51Lmh2bS5zbWJpb3NfZmlybXdhcmUpOworICAgICAgICAgICAg
Z290byBvdXQ7CisgICAgICAgIH0KKyAgICAgICAgaWYgKCFkYXRhbGVuKSB7CisgICAgICAgICAg
ICBMT0coRVJST1IsICJTTUJJT1MgZmlybXdhcmUgZmlsZSAlcyBpcyBlbXB0eSIsCisgICAgICAg
ICAgICAgICAgaW5mby0+dS5odm0uc21iaW9zX2Zpcm13YXJlKTsKKyAgICAgICAgICAgIGdvdG8g
b3V0OworICAgICAgICB9CisgICAgICAgIGxpYnhsX19wdHJfYWRkKGdjLCBkYXRhKTsKKyAgICAg
ICAgYXJncy0+c21iaW9zX21vZHVsZS5kYXRhID0gZGF0YTsKKyAgICAgICAgYXJncy0+c21iaW9z
X21vZHVsZS5sZW5ndGggPSAodWludDMyX3QpZGF0YWxlbjsKKyAgICB9CisKKyAgICBpZiAoaW5m
by0+dS5odm0uYWNwaV9maXJtd2FyZSkgeworICAgICAgICBlID0gbGlieGxfcmVhZF9maWxlX2Nv
bnRlbnRzKGN0eCwgaW5mby0+dS5odm0uYWNwaV9maXJtd2FyZSwKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZGF0YSwgJmRhdGFsZW4pOworICAgICAgICBpZiAoZSkgewor
ICAgICAgICAgICAgTE9HKEVSUk9SLCAiZmFpbGVkIHRvIHJlYWQgQUNQSSBmaXJtd2FyZSBmaWxl
ICVzIiwKKyAgICAgICAgICAgICAgICBpbmZvLT51Lmh2bS5hY3BpX2Zpcm13YXJlKTsKKyAgICAg
ICAgICAgIGdvdG8gb3V0OworICAgICAgICB9CisgICAgICAgIGlmICghZGF0YWxlbikgeworICAg
ICAgICAgICAgTE9HKEVSUk9SLCAiQUNQSSBmaXJtd2FyZSBmaWxlICVzIGlzIGVtcHR5IiwKKyAg
ICAgICAgICAgICAgICBpbmZvLT51Lmh2bS5hY3BpX2Zpcm13YXJlKTsKKyAgICAgICAgICAgIGdv
dG8gb3V0OworICAgICAgICB9CisgICAgICAgIGxpYnhsX19wdHJfYWRkKGdjLCBkYXRhKTsKKyAg
ICAgICAgYXJncy0+YWNwaV9tb2R1bGUuZGF0YSA9IGRhdGE7CisgICAgICAgIGFyZ3MtPmFjcGlf
bW9kdWxlLmxlbmd0aCA9ICh1aW50MzJfdClkYXRhbGVuOworICAgIH0KKworICAgIHJldHVybiAw
Oworb3V0OgorICAgIHJldHVybiByYzsKIH0KIAogaW50IGxpYnhsX19idWlsZF9odm0obGlieGxf
X2djICpnYywgdWludDMyX3QgZG9taWQsCkBAIC01NDQsMTAgKzY0MCw2IEBAIGludCBsaWJ4bF9f
YnVpbGRfaHZtKGxpYnhsX19nYyAqZ2MsIHVpbnQKICAgICBsaWJ4bF9jdHggKmN0eCA9IGxpYnhs
X19nY19vd25lcihnYyk7CiAgICAgc3RydWN0IHhjX2h2bV9idWlsZF9hcmdzIGFyZ3MgPSB7fTsK
ICAgICBpbnQgcmV0LCByYyA9IEVSUk9SX0ZBSUw7Ci0gICAgY29uc3QgY2hhciAqZmlybXdhcmUg
PSBsaWJ4bF9fZG9tYWluX2Zpcm13YXJlKGdjLCBpbmZvKTsKLQotICAgIGlmICghZmlybXdhcmUp
Ci0gICAgICAgIGdvdG8gb3V0OwogCiAgICAgbWVtc2V0KCZhcmdzLCAwLCBzaXplb2Yoc3RydWN0
IHhjX2h2bV9idWlsZF9hcmdzKSk7CiAgICAgLyogVGhlIG1lbW9yeSBzaXplIG5hbWVzIGFyZSBt
aXNsZWFkaW5nLiBUaGUgcGFyYW1zIGFyZSBpbiBNYiB0aGVuCkBAIC01NTcsMjIgKzY0OSwzNCBA
QCBpbnQgbGlieGxfX2J1aWxkX2h2bShsaWJ4bF9fZ2MgKmdjLCB1aW50CiAgICAgICovCiAgICAg
YXJncy5tZW1fc2l6ZSA9ICh1aW50NjRfdCkoaW5mby0+bWF4X21lbWtiIC0gaW5mby0+dmlkZW9f
bWVta2IpIDw8IDEwOwogICAgIGFyZ3MubWVtX3RhcmdldCA9ICh1aW50NjRfdCkoaW5mby0+dGFy
Z2V0X21lbWtiIC0gaW5mby0+dmlkZW9fbWVta2IpIDw8IDEwOwotICAgIGFyZ3MuaW1hZ2VfZmls
ZV9uYW1lID0gZmlybXdhcmU7CisKKyAgICBpZiAobGlieGxfX2RvbWFpbl9maXJtd2FyZShnYywg
aW5mbywgJmFyZ3MpKSB7CisgICAgICAgIExPRyhFUlJPUiwgImluaXRpYWxpemluZyBkb21haW4g
ZmlybXdhcmUgZmFpbGVkIik7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KIAogICAgIHJldCA9
IHhjX2h2bV9idWlsZChjdHgtPnhjaCwgZG9taWQsICZhcmdzKTsKICAgICBpZiAocmV0KSB7Ci0g
ICAgICAgIExJQlhMX19MT0dfRVJSTk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCByZXQsICJo
dm0gYnVpbGRpbmcgZmFpbGVkIik7CisgICAgICAgIExPR0VWKEVSUk9SLCByZXQsICJodm0gYnVp
bGRpbmcgZmFpbGVkIik7CiAgICAgICAgIGdvdG8gb3V0OwogICAgIH0KKwogICAgIHJldCA9IGh2
bV9idWlsZF9zZXRfcGFyYW1zKGN0eC0+eGNoLCBkb21pZCwgaW5mbywgc3RhdGUtPnN0b3JlX3Bv
cnQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnN0YXRlLT5zdG9yZV9tZm4sIHN0
YXRlLT5jb25zb2xlX3BvcnQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnN0YXRl
LT5jb25zb2xlX21mbiwgc3RhdGUtPnN0b3JlX2RvbWlkLAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0YXRlLT5jb25zb2xlX2RvbWlkKTsKICAgICBpZiAocmV0KSB7Ci0gICAgICAg
IExJQlhMX19MT0dfRVJSTk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCByZXQsICJodm0gYnVp
bGQgc2V0IHBhcmFtcyBmYWlsZWQiKTsKKyAgICAgICAgTE9HRVYoRVJST1IsIHJldCwgImh2bSBi
dWlsZCBzZXQgcGFyYW1zIGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9Ci0gICAg
cmMgPSAwOworCisgICAgcmV0ID0gaHZtX2J1aWxkX3NldF94c192YWx1ZXMoZ2MsIGRvbWlkLCAm
YXJncyk7CisgICAgaWYgKHJldCkgeworICAgICAgICBMT0dFVihFUlJPUiwgcmV0LCAiaHZtIGJ1
aWxkIHNldCB4ZW5zdG9yZSB2YWx1ZXMgZmFpbGVkIik7CisgICAgICAgIGdvdG8gb3V0OworICAg
IH0KKworICAgIHJldHVybiAwOwogb3V0OgogICAgIHJldHVybiByYzsKIH0KQEAgLTYzNCw3ICs3
MzgsNyBAQCBpbnQgbGlieGxfX3Rvb2xzdGFja19yZXN0b3JlKHVpbnQzMl90IGRvCiAKICAgICBt
ZW1jcHkoJmNvdW50LCBwdHIsIHNpemVvZihjb3VudCkpOwogICAgIHB0ciArPSBzaXplb2YoY291
bnQpOwotIAorCiAgICAgaWYgKHNpemUgPCBzaXplb2YodmVyc2lvbikgKyBzaXplb2YoY291bnQp
ICsKICAgICAgICAgICAgIGNvdW50ICogKHNpemVvZihzdHJ1Y3QgbGlieGxfX3BoeXNtYXBfaW5m
bykpKSB7CiAgICAgICAgIExJQlhMX19MT0coY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAid3Jvbmcg
c2l6ZSIpOwpAQCAtODQ4LDcgKzk1Miw3IEBAIHN0YXRpYyB2b2lkIHN3aXRjaF9sb2dkaXJ0eV94
c3dhdGNoKGxpYngKICAgICAgICAgcmMgPSBsaWJ4bF9feHNfcm1fY2hlY2tlZChnYywgdCwgbGRz
LT5yZXRfcGF0aCk7CiAgICAgICAgIGlmIChyYykgZ290byBvdXQ7CiAKLSAgICAgICAgcmMgPSBs
aWJ4bF9feHNfdHJhbnNhY3Rpb25fY29tbWl0KGdjLCAmdCk7IAorICAgICAgICByYyA9IGxpYnhs
X194c190cmFuc2FjdGlvbl9jb21taXQoZ2MsICZ0KTsKICAgICAgICAgaWYgKCFyYykgYnJlYWs7
CiAgICAgICAgIGlmIChyYzwwKSBnb3RvIG91dDsKICAgICB9CkBAIC0xMzIwLDcgKzE0MjQsNyBA
QCB2b2lkIGxpYnhsX194Y19kb21haW5fc2F2ZV9kb25lKGxpYnhsX19lCiAgICAgaWYgKHR5cGUg
PT0gTElCWExfRE9NQUlOX1RZUEVfSFZNKSB7CiAgICAgICAgIHJjID0gbGlieGxfX2RvbWFpbl9z
dXNwZW5kX2RldmljZV9tb2RlbChnYywgZHNzKTsKICAgICAgICAgaWYgKHJjKSBnb3RvIG91dDsK
LSAgICAgICAgCisKICAgICAgICAgbGlieGxfX2RvbWFpbl9zYXZlX2RldmljZV9tb2RlbChlZ2Ms
IGRzcywgZG9tYWluX3N1c3BlbmRfZG9uZSk7CiAgICAgICAgIHJldHVybjsKICAgICB9CmRpZmYg
LXIgMjViMjhiNzZmYzY4IHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAotLS0gYS90b29scy9s
aWJ4bC9saWJ4bF90eXBlcy5pZGwJRnJpIEZlYiAwMSAxMDoyMDoyNSAyMDEzIC0wNTAwCisrKyBi
L3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlGcmkgRmViIDAxIDExOjI0OjIxIDIwMTMgLTA1
MDAKQEAgLTMwOCw2ICszMDgsOCBAQCBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgi
ZG9tYWluCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInZwdF9hbGln
biIsICAgICAgICBsaWJ4bF9kZWZib29sKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICgidGltZXJfbW9kZSIsICAgICAgIGxpYnhsX3RpbWVyX21vZGUpLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJuZXN0ZWRfaHZtIiwgICAgICAgbGli
eGxfZGVmYm9vbCksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInNt
Ymlvc19maXJtd2FyZSIsICBzdHJpbmcpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKCJhY3BpX2Zpcm13YXJlIiwgICAgc3RyaW5nKSwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgibm9ncmFwaGljIiwgICAgICAgIGxpYnhsX2RlZmJvb2wp
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ2Z2EiLCAgICAgICAg
ICAgICAgbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvKSwKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICgidm5jIiwgICAgICAgICAgICAgIGxpYnhsX3ZuY19pbmZvKSwKZGlm
ZiAtciAyNWIyOGI3NmZjNjggdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCi0tLSBhL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwlGcmkgRmViIDAxIDEwOjIwOjI1IDIwMTMgLTA1MDAKKysrIGIvdG9v
bHMvbGlieGwveGxfY21kaW1wbC5jCUZyaSBGZWIgMDEgMTE6MjQ6MjEgMjAxMyAtMDUwMApAQCAt
ODgyLDYgKzg4MiwxMSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFy
CiAgICAgICAgIH0KIAogICAgICAgICB4bHVfY2ZnX2dldF9kZWZib29sKGNvbmZpZywgIm5lc3Rl
ZGh2bSIsICZiX2luZm8tPnUuaHZtLm5lc3RlZF9odm0sIDApOworCisgICAgICAgIHhsdV9jZmdf
cmVwbGFjZV9zdHJpbmcoY29uZmlnLCAic21iaW9zX2Zpcm13YXJlIiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS5zbWJpb3NfZmlybXdhcmUsIDApOworICAg
ICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nKGNvbmZpZywgImFjcGlfZmlybXdhcmUiLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZiX2luZm8tPnUuaHZtLmFjcGlfZmlybXdhcmUs
IDApOwogICAgICAgICBicmVhazsKICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX1BWOgogICAg
IHsK

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_
Content-Type: application/octet-stream; name="ce7329e6fa.aa.sf"
Content-Description: ce7329e6fa.aa.sf
Content-Disposition: attachment; filename="ce7329e6fa.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:13:52 GMT";
	modification-date="Fri, 01 Feb 2013 20:13:52 GMT"
Content-Transfer-Encoding: base64

Y2U3MzI5ZTZmYQ0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXGNlNzMyOWU2ZmFcDQowDQowDQowDQpOT05FDQpOT05F

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

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

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 20:16:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20:16: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 1U1N2K-0001zh-6B; Fri, 01 Feb 2013 20:16:36 +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 1U1N2D-0001yo-PR
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:16:30 +0000
Received: from [85.158.139.83:15135] by server-9.bemta-5.messagelabs.com id
	FD/FD-24440-D922C015; Fri, 01 Feb 2013 20:16:29 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1359749786!26509409!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31906 invoked from network); 1 Feb 2013 20:16:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="sf'?scan'208";a="6006872"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:16:26 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Fri, 1 Feb 2013 15:16:25 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:16:23 -0500
Thread-Topic: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4AuJp3Hz//Rl8lSMKCG0xjKR9GAQ==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This patch introduces support for two new parameters in libxl:

smbios_firmware=3D<path_to_smbios_structures_file>
acpi_firmware=3D<path_to_acpi_tables_file>

The changes are primarily in the domain building code where the firmware fi=
les
are read and passed to libxc for loading into the new guest. After the doma=
in
building call to libxc, the addresses for the loaded blobs are returned and
written to xenstore.

LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users to
determine if the feature is present.
=20
This patch also updates the xl.cfg man page with descriptions of the two ne=
w
parameters for firmware passthrough.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>


--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_
Content-Type: application/octet-stream;
	name="hvm-firmware-passthrough-libxl-v2-02.patch"
Content-Description: hvm-firmware-passthrough-libxl-v2-02.patch
Content-Disposition: attachment;
	filename="hvm-firmware-passthrough-libxl-v2-02.patch"; size=11346;
	creation-date="Fri, 01 Feb 2013 19:55:13 GMT";
	modification-date="Fri, 01 Feb 2013 19:55:13 GMT"
Content-Transfer-Encoding: base64

VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIHN1cHBvcnQgZm9yIHR3byBuZXcgcGFyYW1ldGVycyBpbiBs
aWJ4bDoKCnNtYmlvc19maXJtd2FyZT08cGF0aF90b19zbWJpb3Nfc3RydWN0dXJlc19maWxlPgph
Y3BpX2Zpcm13YXJlPTxwYXRoX3RvX2FjcGlfdGFibGVzX2ZpbGU+CgpUaGUgY2hhbmdlcyBhcmUg
cHJpbWFyaWx5IGluIHRoZSBkb21haW4gYnVpbGRpbmcgY29kZSB3aGVyZSB0aGUgZmlybXdhcmUg
ZmlsZXMKYXJlIHJlYWQgYW5kIHBhc3NlZCB0byBsaWJ4YyBmb3IgbG9hZGluZyBpbnRvIHRoZSBu
ZXcgZ3Vlc3QuIEFmdGVyIHRoZSBkb21haW4KYnVpbGRpbmcgY2FsbCB0byBsaWJ4YywgdGhlIGFk
ZHJlc3NlcyBmb3IgdGhlIGxvYWRlZCBibG9icyBhcmUgcmV0dXJuZWQgYW5kCndyaXR0ZW4gdG8g
eGVuc3RvcmUuCgpMSUJYTF9IQVZFX0ZJUk1XQVJFX1BBU1NUSFJPVUdIIGlzIGRlZmluZWQgaW4g
bGlieGwuaCB0byBhbGxvdyB1c2VycyB0bwpkZXRlcm1pbmUgaWYgdGhlIGZlYXR1cmUgaXMgcHJl
c2VudC4KIApUaGlzIHBhdGNoIGFsc28gdXBkYXRlcyB0aGUgeGwuY2ZnIG1hbiBwYWdlIHdpdGgg
ZGVzY3JpcHRpb25zIG9mIHRoZSB0d28gbmV3CnBhcmFtZXRlcnMgZm9yIGZpcm13YXJlIHBhc3N0
aHJvdWdoLgoKU2lnbmVkLW9mZi1ieTogUm9zcyBQaGlsaXBzb24gPHJvc3MucGhpbGlwc29uQGNp
dHJpeC5jb20+CgpkaWZmIC1yIDI1YjI4Yjc2ZmM2OCBkb2NzL21hbi94bC5jZmcucG9kLjUKLS0t
IGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41CUZyaSBGZWIgMDEgMTA6MjA6MjUgMjAxMyAtMDUwMAor
KysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUJRnJpIEZlYiAwMSAxMToyNDoyMSAyMDEzIC0wNTAw
CkBAIC04MjksNiArODI5LDI1IEBAIGxpYnhsOiAnaG9zdCx0bT0wLHNzZTM9MCcKIE1vcmUgaW5m
byBhYm91dCB0aGUgQ1BVSUQgaW5zdHJ1Y3Rpb24gY2FuIGJlIGZvdW5kIGluIHRoZSBwcm9jZXNz
b3IgbWFudWFscywgYW5kCiBpbiBXaWtpcGVkaWE6IEw8aHR0cDovL2VuLndpa2lwZWRpYS5vcmcv
d2lraS9DUFVJRD4KIAorPWl0ZW0gQjxhY3BpX2Zpcm13YXJlPSJTVFJJTkciPgorCitTcGVjaWZ5
IGEgcGF0aCB0byBhIGZpbGUgdGhhdCBjb250YWlucyBleHRyYSBBQ1BJIGZpcm13YXJlIHRhYmxl
cyB0byBwYXNzIGluIHRvCithIGd1ZXN0LiBUaGUgZmlsZSBjYW4gY29udGFpbiBzZXZlcmFsIHRh
YmxlcyBpbiB0aGVpciBiaW5hcnkgQU1MIGZvcm0KK2NvbmNhdGVuYXRlZCB0b2dldGhlci4gRWFj
aCB0YWJsZSBzZWxmIGRlc2NyaWJlcyBpdHMgbGVuZ3RoIHNvIG5vIGFkZGl0aW9uYWwKK2luZm9y
bWF0aW9uIGlzIG5lZWRlZC4gVGhlc2UgdGFibGVzIHdpbGwgYmUgYWRkZWQgdG8gdGhlIEFDUEkg
dGFibGUgc2V0IGluIHRoZQorZ3Vlc3QuIE5vdGUgdGhhdCBleGlzdGluZyB0YWJsZXMgY2Fubm90
IGJlIG92ZXJyaWRlbiBieSB0aGlzIGZlYXR1cmUuIEZvcgorZXhhbXBsZSB0aGlzIGNhbm5vdCBi
ZSB1c2VkIHRvIG92ZXJyaWRlIHRhYmxlcyBsaWtlIERTRFQsIEZBRFQsIGV0Yy4KKworPWl0ZW0g
QjxzbWJpb3NfZmlybXdhcmU9IlNUUklORyI+CisKK1NwZWNpZnkgYSBwYXRoIHRvIGEgZmlsZSB0
aGF0IGNvbnRhaW5zIGV4dHJhIFNNQklPUyBmaXJtd2FyZSBzdHJ1Y3R1cmVzIHRvIHBhc3MKK2lu
IHRvIGEgZ3Vlc3QuIFRoZSBmaWxlIGNhbiBjb250YWluIGEgc2V0IERNVEYgcHJlZGVmaW5lZCBz
dHJ1Y3R1cmVzIHdoaWNoIHdpbGwKK292ZXJyaWRlIHRoZSBpbnRlcm5hbCBkZWZhdWx0cy4gTm90
IGFsbCBwcmVkZWZpbmVkIHN0cnVjdHVyZXMgY2FuIGJlIG92ZXJyaWRlbiwKK29ubHkgdGhlIGZv
bGxvd2luZyB0eXBlczogMCwgMSwgMiwgMywgMTEsIDIyLCAzOS4gVGhlIGZpbGUgY2FuIGFsc28g
Y29udGFpbiBhbnkKK251bWJlciBvZiB2ZW5kb3IgZGVmaW5lZCBTTUJJT1Mgc3RydWN0dXJlcyAo
dHlwZSAxMjggLSAyNTUpLiBTaW5jZSBTTUJJT1MKK3N0cnVjdHVyZXMgZG8gbm90IHByZXNlbnQg
dGhlaXIgb3ZlcmFsbCBzaXplLCBlYWNoIGVudHJ5IGluIHRoZSBmaWxlIG11c3QgYmUKK3ByZWNl
ZWRlZCBieSBhIDMyYiBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIHNpemUgb2YgdGhlIG5leHQgc3Ry
dWN0dXJlLgorCiA9YmFjayAKIAogPWhlYWQzIEd1ZXN0IFZpcnR1YWwgVGltZSBDb250cm9scwpk
aWZmIC1yIDI1YjI4Yjc2ZmM2OCB0b29scy9saWJ4bC9saWJ4bC5oCi0tLSBhL3Rvb2xzL2xpYnhs
L2xpYnhsLmgJRnJpIEZlYiAwMSAxMDoyMDoyNSAyMDEzIC0wNTAwCisrKyBiL3Rvb2xzL2xpYnhs
L2xpYnhsLmgJRnJpIEZlYiAwMSAxMToyNDoyMSAyMDEzIC0wNTAwCkBAIC02OCw2ICs2OCwxMyBA
QAogICovCiAKIC8qCisgKiBMSUJYTF9IQVZFX0ZJUk1XQVJFX1BBU1NUSFJPVUdIIGluZGljYXRl
cyB0aGUgbmV3IGZlYXR1cmUgZm9yCisgKiBwYXNzaW5nIGluIFNNQklPUyBhbmQgQUNQSSBmaXJt
d2FyZSB0byBIVk0gZ3Vlc3RzIGlzIHByZXNlbnQKKyAqIGluIHRoZSBsaWJyYXJ5LgorICovCisj
ZGVmaW5lIExJQlhMX0hBVkVfRklSTVdBUkVfUEFTU1RIUk9VR0ggMQorCisvKgogICogbGlieGwg
QUJJIGNvbXBhdGliaWxpdHkKICAqCiAgKiBUaGUgb25seSBndWFyYW50ZWUgd2hpY2ggbGlieGwg
bWFrZXMgcmVnYXJkaW5nIEFCSSBjb21wYXRpYmlsaXR5CmRpZmYgLXIgMjViMjhiNzZmYzY4IHRv
b2xzL2xpYnhsL2xpYnhsX2RvbS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCUZyaSBG
ZWIgMDEgMTA6MjA6MjUgMjAxMyAtMDUwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9kb20uYwlG
cmkgRmViIDAxIDExOjI0OjIxIDIwMTMgLTA1MDAKQEAgLTIxLDYgKzIxLDcgQEAKIAogI2luY2x1
ZGUgPHhjX2RvbS5oPgogI2luY2x1ZGUgPHhlbi9odm0vaHZtX2luZm9fdGFibGUuaD4KKyNpbmNs
dWRlIDx4ZW4vaHZtL2h2bV94c19zdHJpbmdzLmg+CiAKIGxpYnhsX2RvbWFpbl90eXBlIGxpYnhs
X19kb21haW5fdHlwZShsaWJ4bF9fZ2MgKmdjLCB1aW50MzJfdCBkb21pZCkKIHsKQEAgLTUxMCwx
MSArNTExLDYxIEBAIHN0YXRpYyBpbnQgaHZtX2J1aWxkX3NldF9wYXJhbXMoeGNfaW50ZXIKICAg
ICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGNvbnN0IGNoYXIgKmxpYnhsX19kb21haW5fZmlybXdh
cmUobGlieGxfX2djICpnYywKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxpYnhsX2RvbWFpbl9idWlsZF9pbmZvICppbmZvKQorc3RhdGljIGludCBodm1fYnVpbGRf
c2V0X3hzX3ZhbHVlcyhsaWJ4bF9fZ2MgKmdjLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3RydWN0IHhjX2h2bV9idWlsZF9hcmdzICphcmdzKQoreworICAgIGNoYXIgKnBhdGggPSBO
VUxMOworICAgIGludCByZXQgPSAwOworCisgICAgaWYgKGFyZ3MtPnNtYmlvc19tb2R1bGUuZ3Vl
c3RfYWRkcl9vdXQpIHsKKyAgICAgICAgcGF0aCA9IEdDU1BSSU5URigiL2xvY2FsL2RvbWFpbi8l
ZC8iSFZNX1hTX1NNQklPU19QVF9BRERSRVNTLCBkb21pZCk7CisKKyAgICAgICAgcmV0ID0gbGli
eGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgcGF0aCwgIjB4JSJQUkl4NjQsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBhcmdzLT5zbWJpb3NfbW9kdWxlLmd1ZXN0X2FkZHJfb3V0KTsK
KyAgICAgICAgaWYgKHJldCkKKyAgICAgICAgICAgIGdvdG8gZXJyOworCisgICAgICAgIHBhdGgg
PSBHQ1NQUklOVEYoIi9sb2NhbC9kb21haW4vJWQvIkhWTV9YU19TTUJJT1NfUFRfTEVOR1RILCBk
b21pZCk7CisKKyAgICAgICAgcmV0ID0gbGlieGxfX3hzX3dyaXRlKGdjLCBYQlRfTlVMTCwgcGF0
aCwgIjB4JXgiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJncy0+c21iaW9zX21v
ZHVsZS5sZW5ndGgpOworICAgICAgICBpZiAocmV0KQorICAgICAgICAgICAgZ290byBlcnI7Cisg
ICAgfQorCisgICAgaWYgKGFyZ3MtPmFjcGlfbW9kdWxlLmd1ZXN0X2FkZHJfb3V0KSB7CisgICAg
ICAgIHBhdGggPSBHQ1NQUklOVEYoIi9sb2NhbC9kb21haW4vJWQvIkhWTV9YU19BQ1BJX1BUX0FE
RFJFU1MsIGRvbWlkKTsKKworICAgICAgICByZXQgPSBsaWJ4bF9feHNfd3JpdGUoZ2MsIFhCVF9O
VUxMLCBwYXRoLCAiMHglIlBSSXg2NCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFy
Z3MtPmFjcGlfbW9kdWxlLmd1ZXN0X2FkZHJfb3V0KTsKKyAgICAgICAgaWYgKHJldCkKKyAgICAg
ICAgICAgIGdvdG8gZXJyOworCisgICAgICAgIHBhdGggPSBHQ1NQUklOVEYoIi9sb2NhbC9kb21h
aW4vJWQvIkhWTV9YU19BQ1BJX1BUX0xFTkdUSCwgZG9taWQpOworCisgICAgICAgIHJldCA9IGxp
YnhsX194c193cml0ZShnYywgWEJUX05VTEwsIHBhdGgsICIweCV4IiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGFyZ3MtPmFjcGlfbW9kdWxlLmxlbmd0aCk7CisgICAgICAgIGlmIChy
ZXQpCisgICAgICAgICAgICBnb3RvIGVycjsKKyAgICB9CisKKyAgICByZXR1cm4gMDsKKworZXJy
OgorICAgIExPRyhFUlJPUiwgImZhaWxlZCB0byB3cml0ZSBmaXJtd2FyZSB4ZW5zdG9yZSB2YWx1
ZSwgZXJyOiAlZCIsIHJldCk7CisgICAgcmV0dXJuIC0xOworfQorCitzdGF0aWMgaW50IGxpYnhs
X19kb21haW5fZmlybXdhcmUobGlieGxfX2djICpnYywKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyAqaW5mbywKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGNfaHZtX2J1aWxkX2FyZ3MgKmFyZ3MpCiB7CiAg
ICAgbGlieGxfY3R4ICpjdHggPSBsaWJ4bF9fZ2Nfb3duZXIoZ2MpOwogICAgIGNvbnN0IGNoYXIg
KmZpcm13YXJlOworICAgIGludCBlLCByYyA9IEVSUk9SX0ZBSUw7CisgICAgaW50IGRhdGFsZW4g
PSAwOworICAgIHZvaWQgKmRhdGEgPSAwOwogCiAgICAgaWYgKGluZm8tPnUuaHZtLmZpcm13YXJl
KQogICAgICAgICBmaXJtd2FyZSA9IGluZm8tPnUuaHZtLmZpcm13YXJlOwpAQCAtNTI4LDEzICs1
NzksNTggQEAgc3RhdGljIGNvbnN0IGNoYXIgKmxpYnhsX19kb21haW5fZmlybXdhcgogICAgICAg
ICAgICAgZmlybXdhcmUgPSAiaHZtbG9hZGVyIjsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAg
ICBkZWZhdWx0OgotICAgICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1Is
ICJpbnZhbGlkIGRldmljZSBtb2RlbCB2ZXJzaW9uICVkIiwKLSAgICAgICAgICAgICAgICAgICAg
ICAgaW5mby0+ZGV2aWNlX21vZGVsX3ZlcnNpb24pOwotICAgICAgICAgICAgcmV0dXJuIE5VTEw7
CisgICAgICAgICAgICBMT0coRVJST1IsICJpbnZhbGlkIGRldmljZSBtb2RlbCB2ZXJzaW9uICVk
IiwKKyAgICAgICAgICAgICAgICBpbmZvLT5kZXZpY2VfbW9kZWxfdmVyc2lvbik7CisgICAgICAg
ICAgICByZXR1cm4gLTE7CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgfQogICAgIH0KLSAg
ICByZXR1cm4gbGlieGxfX2Fic19wYXRoKGdjLCBmaXJtd2FyZSwgbGlieGxfX3hlbmZpcm13YXJl
ZGlyX3BhdGgoKSk7CisgICAgYXJncy0+aW1hZ2VfZmlsZV9uYW1lID0gbGlieGxfX2Fic19wYXRo
KGdjLCBmaXJtd2FyZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbGlieGxfX3hlbmZpcm13YXJlZGlyX3BhdGgoKSk7CisgICAgaWYgKCFhcmdzLT5pbWFnZV9m
aWxlX25hbWUpIHsKKyAgICAgICAgTE9HKEVSUk9SLCAiaW52YWxpZCBmaXJtd2FyZSBwYXRoIik7
CisgICAgICAgIHJldHVybiAtMTsKKyAgICB9CisKKyAgICBpZiAoaW5mby0+dS5odm0uc21iaW9z
X2Zpcm13YXJlKSB7CisgICAgICAgIGUgPSBsaWJ4bF9yZWFkX2ZpbGVfY29udGVudHMoY3R4LCBp
bmZvLT51Lmh2bS5zbWJpb3NfZmlybXdhcmUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmRhdGEsICZkYXRhbGVuKTsKKyAgICAgICAgaWYgKGUpIHsKKyAgICAgICAgICAg
IExPRyhFUlJPUiwgImZhaWxlZCB0byByZWFkIFNNQklPUyBmaXJtd2FyZSBmaWxlICVzIiwKKyAg
ICAgICAgICAgICAgICBpbmZvLT51Lmh2bS5zbWJpb3NfZmlybXdhcmUpOworICAgICAgICAgICAg
Z290byBvdXQ7CisgICAgICAgIH0KKyAgICAgICAgaWYgKCFkYXRhbGVuKSB7CisgICAgICAgICAg
ICBMT0coRVJST1IsICJTTUJJT1MgZmlybXdhcmUgZmlsZSAlcyBpcyBlbXB0eSIsCisgICAgICAg
ICAgICAgICAgaW5mby0+dS5odm0uc21iaW9zX2Zpcm13YXJlKTsKKyAgICAgICAgICAgIGdvdG8g
b3V0OworICAgICAgICB9CisgICAgICAgIGxpYnhsX19wdHJfYWRkKGdjLCBkYXRhKTsKKyAgICAg
ICAgYXJncy0+c21iaW9zX21vZHVsZS5kYXRhID0gZGF0YTsKKyAgICAgICAgYXJncy0+c21iaW9z
X21vZHVsZS5sZW5ndGggPSAodWludDMyX3QpZGF0YWxlbjsKKyAgICB9CisKKyAgICBpZiAoaW5m
by0+dS5odm0uYWNwaV9maXJtd2FyZSkgeworICAgICAgICBlID0gbGlieGxfcmVhZF9maWxlX2Nv
bnRlbnRzKGN0eCwgaW5mby0+dS5odm0uYWNwaV9maXJtd2FyZSwKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZGF0YSwgJmRhdGFsZW4pOworICAgICAgICBpZiAoZSkgewor
ICAgICAgICAgICAgTE9HKEVSUk9SLCAiZmFpbGVkIHRvIHJlYWQgQUNQSSBmaXJtd2FyZSBmaWxl
ICVzIiwKKyAgICAgICAgICAgICAgICBpbmZvLT51Lmh2bS5hY3BpX2Zpcm13YXJlKTsKKyAgICAg
ICAgICAgIGdvdG8gb3V0OworICAgICAgICB9CisgICAgICAgIGlmICghZGF0YWxlbikgeworICAg
ICAgICAgICAgTE9HKEVSUk9SLCAiQUNQSSBmaXJtd2FyZSBmaWxlICVzIGlzIGVtcHR5IiwKKyAg
ICAgICAgICAgICAgICBpbmZvLT51Lmh2bS5hY3BpX2Zpcm13YXJlKTsKKyAgICAgICAgICAgIGdv
dG8gb3V0OworICAgICAgICB9CisgICAgICAgIGxpYnhsX19wdHJfYWRkKGdjLCBkYXRhKTsKKyAg
ICAgICAgYXJncy0+YWNwaV9tb2R1bGUuZGF0YSA9IGRhdGE7CisgICAgICAgIGFyZ3MtPmFjcGlf
bW9kdWxlLmxlbmd0aCA9ICh1aW50MzJfdClkYXRhbGVuOworICAgIH0KKworICAgIHJldHVybiAw
Oworb3V0OgorICAgIHJldHVybiByYzsKIH0KIAogaW50IGxpYnhsX19idWlsZF9odm0obGlieGxf
X2djICpnYywgdWludDMyX3QgZG9taWQsCkBAIC01NDQsMTAgKzY0MCw2IEBAIGludCBsaWJ4bF9f
YnVpbGRfaHZtKGxpYnhsX19nYyAqZ2MsIHVpbnQKICAgICBsaWJ4bF9jdHggKmN0eCA9IGxpYnhs
X19nY19vd25lcihnYyk7CiAgICAgc3RydWN0IHhjX2h2bV9idWlsZF9hcmdzIGFyZ3MgPSB7fTsK
ICAgICBpbnQgcmV0LCByYyA9IEVSUk9SX0ZBSUw7Ci0gICAgY29uc3QgY2hhciAqZmlybXdhcmUg
PSBsaWJ4bF9fZG9tYWluX2Zpcm13YXJlKGdjLCBpbmZvKTsKLQotICAgIGlmICghZmlybXdhcmUp
Ci0gICAgICAgIGdvdG8gb3V0OwogCiAgICAgbWVtc2V0KCZhcmdzLCAwLCBzaXplb2Yoc3RydWN0
IHhjX2h2bV9idWlsZF9hcmdzKSk7CiAgICAgLyogVGhlIG1lbW9yeSBzaXplIG5hbWVzIGFyZSBt
aXNsZWFkaW5nLiBUaGUgcGFyYW1zIGFyZSBpbiBNYiB0aGVuCkBAIC01NTcsMjIgKzY0OSwzNCBA
QCBpbnQgbGlieGxfX2J1aWxkX2h2bShsaWJ4bF9fZ2MgKmdjLCB1aW50CiAgICAgICovCiAgICAg
YXJncy5tZW1fc2l6ZSA9ICh1aW50NjRfdCkoaW5mby0+bWF4X21lbWtiIC0gaW5mby0+dmlkZW9f
bWVta2IpIDw8IDEwOwogICAgIGFyZ3MubWVtX3RhcmdldCA9ICh1aW50NjRfdCkoaW5mby0+dGFy
Z2V0X21lbWtiIC0gaW5mby0+dmlkZW9fbWVta2IpIDw8IDEwOwotICAgIGFyZ3MuaW1hZ2VfZmls
ZV9uYW1lID0gZmlybXdhcmU7CisKKyAgICBpZiAobGlieGxfX2RvbWFpbl9maXJtd2FyZShnYywg
aW5mbywgJmFyZ3MpKSB7CisgICAgICAgIExPRyhFUlJPUiwgImluaXRpYWxpemluZyBkb21haW4g
ZmlybXdhcmUgZmFpbGVkIik7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KIAogICAgIHJldCA9
IHhjX2h2bV9idWlsZChjdHgtPnhjaCwgZG9taWQsICZhcmdzKTsKICAgICBpZiAocmV0KSB7Ci0g
ICAgICAgIExJQlhMX19MT0dfRVJSTk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCByZXQsICJo
dm0gYnVpbGRpbmcgZmFpbGVkIik7CisgICAgICAgIExPR0VWKEVSUk9SLCByZXQsICJodm0gYnVp
bGRpbmcgZmFpbGVkIik7CiAgICAgICAgIGdvdG8gb3V0OwogICAgIH0KKwogICAgIHJldCA9IGh2
bV9idWlsZF9zZXRfcGFyYW1zKGN0eC0+eGNoLCBkb21pZCwgaW5mbywgc3RhdGUtPnN0b3JlX3Bv
cnQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnN0YXRlLT5zdG9yZV9tZm4sIHN0
YXRlLT5jb25zb2xlX3BvcnQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnN0YXRl
LT5jb25zb2xlX21mbiwgc3RhdGUtPnN0b3JlX2RvbWlkLAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0YXRlLT5jb25zb2xlX2RvbWlkKTsKICAgICBpZiAocmV0KSB7Ci0gICAgICAg
IExJQlhMX19MT0dfRVJSTk9WQUwoY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCByZXQsICJodm0gYnVp
bGQgc2V0IHBhcmFtcyBmYWlsZWQiKTsKKyAgICAgICAgTE9HRVYoRVJST1IsIHJldCwgImh2bSBi
dWlsZCBzZXQgcGFyYW1zIGZhaWxlZCIpOwogICAgICAgICBnb3RvIG91dDsKICAgICB9Ci0gICAg
cmMgPSAwOworCisgICAgcmV0ID0gaHZtX2J1aWxkX3NldF94c192YWx1ZXMoZ2MsIGRvbWlkLCAm
YXJncyk7CisgICAgaWYgKHJldCkgeworICAgICAgICBMT0dFVihFUlJPUiwgcmV0LCAiaHZtIGJ1
aWxkIHNldCB4ZW5zdG9yZSB2YWx1ZXMgZmFpbGVkIik7CisgICAgICAgIGdvdG8gb3V0OworICAg
IH0KKworICAgIHJldHVybiAwOwogb3V0OgogICAgIHJldHVybiByYzsKIH0KQEAgLTYzNCw3ICs3
MzgsNyBAQCBpbnQgbGlieGxfX3Rvb2xzdGFja19yZXN0b3JlKHVpbnQzMl90IGRvCiAKICAgICBt
ZW1jcHkoJmNvdW50LCBwdHIsIHNpemVvZihjb3VudCkpOwogICAgIHB0ciArPSBzaXplb2YoY291
bnQpOwotIAorCiAgICAgaWYgKHNpemUgPCBzaXplb2YodmVyc2lvbikgKyBzaXplb2YoY291bnQp
ICsKICAgICAgICAgICAgIGNvdW50ICogKHNpemVvZihzdHJ1Y3QgbGlieGxfX3BoeXNtYXBfaW5m
bykpKSB7CiAgICAgICAgIExJQlhMX19MT0coY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAid3Jvbmcg
c2l6ZSIpOwpAQCAtODQ4LDcgKzk1Miw3IEBAIHN0YXRpYyB2b2lkIHN3aXRjaF9sb2dkaXJ0eV94
c3dhdGNoKGxpYngKICAgICAgICAgcmMgPSBsaWJ4bF9feHNfcm1fY2hlY2tlZChnYywgdCwgbGRz
LT5yZXRfcGF0aCk7CiAgICAgICAgIGlmIChyYykgZ290byBvdXQ7CiAKLSAgICAgICAgcmMgPSBs
aWJ4bF9feHNfdHJhbnNhY3Rpb25fY29tbWl0KGdjLCAmdCk7IAorICAgICAgICByYyA9IGxpYnhs
X194c190cmFuc2FjdGlvbl9jb21taXQoZ2MsICZ0KTsKICAgICAgICAgaWYgKCFyYykgYnJlYWs7
CiAgICAgICAgIGlmIChyYzwwKSBnb3RvIG91dDsKICAgICB9CkBAIC0xMzIwLDcgKzE0MjQsNyBA
QCB2b2lkIGxpYnhsX194Y19kb21haW5fc2F2ZV9kb25lKGxpYnhsX19lCiAgICAgaWYgKHR5cGUg
PT0gTElCWExfRE9NQUlOX1RZUEVfSFZNKSB7CiAgICAgICAgIHJjID0gbGlieGxfX2RvbWFpbl9z
dXNwZW5kX2RldmljZV9tb2RlbChnYywgZHNzKTsKICAgICAgICAgaWYgKHJjKSBnb3RvIG91dDsK
LSAgICAgICAgCisKICAgICAgICAgbGlieGxfX2RvbWFpbl9zYXZlX2RldmljZV9tb2RlbChlZ2Ms
IGRzcywgZG9tYWluX3N1c3BlbmRfZG9uZSk7CiAgICAgICAgIHJldHVybjsKICAgICB9CmRpZmYg
LXIgMjViMjhiNzZmYzY4IHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAotLS0gYS90b29scy9s
aWJ4bC9saWJ4bF90eXBlcy5pZGwJRnJpIEZlYiAwMSAxMDoyMDoyNSAyMDEzIC0wNTAwCisrKyBi
L3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlGcmkgRmViIDAxIDExOjI0OjIxIDIwMTMgLTA1
MDAKQEAgLTMwOCw2ICszMDgsOCBAQCBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgi
ZG9tYWluCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInZwdF9hbGln
biIsICAgICAgICBsaWJ4bF9kZWZib29sKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICgidGltZXJfbW9kZSIsICAgICAgIGxpYnhsX3RpbWVyX21vZGUpLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJuZXN0ZWRfaHZtIiwgICAgICAgbGli
eGxfZGVmYm9vbCksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInNt
Ymlvc19maXJtd2FyZSIsICBzdHJpbmcpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKCJhY3BpX2Zpcm13YXJlIiwgICAgc3RyaW5nKSwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgibm9ncmFwaGljIiwgICAgICAgIGxpYnhsX2RlZmJvb2wp
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJ2Z2EiLCAgICAgICAg
ICAgICAgbGlieGxfdmdhX2ludGVyZmFjZV9pbmZvKSwKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICgidm5jIiwgICAgICAgICAgICAgIGxpYnhsX3ZuY19pbmZvKSwKZGlm
ZiAtciAyNWIyOGI3NmZjNjggdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCi0tLSBhL3Rvb2xzL2xp
YnhsL3hsX2NtZGltcGwuYwlGcmkgRmViIDAxIDEwOjIwOjI1IDIwMTMgLTA1MDAKKysrIGIvdG9v
bHMvbGlieGwveGxfY21kaW1wbC5jCUZyaSBGZWIgMDEgMTE6MjQ6MjEgMjAxMyAtMDUwMApAQCAt
ODgyLDYgKzg4MiwxMSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFy
CiAgICAgICAgIH0KIAogICAgICAgICB4bHVfY2ZnX2dldF9kZWZib29sKGNvbmZpZywgIm5lc3Rl
ZGh2bSIsICZiX2luZm8tPnUuaHZtLm5lc3RlZF9odm0sIDApOworCisgICAgICAgIHhsdV9jZmdf
cmVwbGFjZV9zdHJpbmcoY29uZmlnLCAic21iaW9zX2Zpcm13YXJlIiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS5zbWJpb3NfZmlybXdhcmUsIDApOworICAg
ICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nKGNvbmZpZywgImFjcGlfZmlybXdhcmUiLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZiX2luZm8tPnUuaHZtLmFjcGlfZmlybXdhcmUs
IDApOwogICAgICAgICBicmVhazsKICAgICBjYXNlIExJQlhMX0RPTUFJTl9UWVBFX1BWOgogICAg
IHsK

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_
Content-Type: application/octet-stream; name="ce7329e6fa.aa.sf"
Content-Description: ce7329e6fa.aa.sf
Content-Disposition: attachment; filename="ce7329e6fa.aa.sf"; size=105;
	creation-date="Fri, 01 Feb 2013 20:13:52 GMT";
	modification-date="Fri, 01 Feb 2013 20:13:52 GMT"
Content-Transfer-Encoding: base64

Y2U3MzI5ZTZmYQ0KMA0KMA0KTk9ORQ0KQzpcVXNlcnNccm9zc3BcQXBwRGF0YVxSb2FtaW5nXFNo
YXJlRmlsZVxPdXRsb29rXGNlNzMyOWU2ZmFcDQowDQowDQowDQpOT05FDQpOT05F

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

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

--_003_831D55AF5A11D64C9B4B43F59EEBF720A320A939E6FTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Fri Feb 01 20:26:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20:26: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 1U1NC1-0002ZO-Ss; Fri, 01 Feb 2013 20:26:37 +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 1U1NBz-0002ZJ-NO
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:26:35 +0000
Received: from [85.158.138.51:8524] by server-8.bemta-3.messagelabs.com id
	6D/0C-25687-AF42C015; Fri, 01 Feb 2013 20:26:34 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1359750392!28859954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24718 invoked from network); 1 Feb 2013 20:26:34 -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;
	1 Feb 2013 20:26:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5713904"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:26:32 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Fri, 1 Feb 2013 15:26:32 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:26:29 -0500
Thread-Topic: [Xen-devel] HVM firmware passthrough - helper library
Thread-Index: Ac3uVlAJwhmmWCLQT8m5P7nJdAonUASYtKnQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BC0@FTLPMAILBOX02.citrite.net>
	<1357728271.7989.220.camel@zakaz.uk.xensource.com>
In-Reply-To: <1357728271.7989.220.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] HVM firmware passthrough - helper library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, January 09, 2013 5:45 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com; Art Napor (artnapor@yahoo.com)
> Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> 
> On Tue, 2013-01-08 at 22:04 +0000, Ross Philipson wrote:
> > Attached is a tarball with a helper library for reading host ACPI and
> > SMBIOS firmware and creating firmware files that can be used with the
> > HVM firmware passthrough patches I submitted. I used it in my testing
> > of the patches and planned to use it later when we moved to a new Xen
> > version. This library was requested by a few people - I hope you find
> > it useful.
> 
> Would it make sense / are you planning to integrate this into the Xen
> tree as well? I'm not sure if it fits into an existing library e.g.
> libxenguest if it would be a separate library.
> 
> Ian.

Following up on this. Is there any interest in integrating this into
xen? I don't think it belongs in xenguest because it would be used up
at the libxl level where the fw blobs are passed in via the xl config
file. It seems like it should be in some separate utilities library
but I can't really see where.

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 20:26:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20:26: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 1U1NC1-0002ZO-Ss; Fri, 01 Feb 2013 20:26:37 +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 1U1NBz-0002ZJ-NO
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 20:26:35 +0000
Received: from [85.158.138.51:8524] by server-8.bemta-3.messagelabs.com id
	6D/0C-25687-AF42C015; Fri, 01 Feb 2013 20:26:34 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1359750392!28859954!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24718 invoked from network); 1 Feb 2013 20:26:34 -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;
	1 Feb 2013 20:26:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5713904"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Feb 2013 20:26:32 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Fri, 1 Feb 2013 15:26:32 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 1 Feb 2013 15:26:29 -0500
Thread-Topic: [Xen-devel] HVM firmware passthrough - helper library
Thread-Index: Ac3uVlAJwhmmWCLQT8m5P7nJdAonUASYtKnQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BC0@FTLPMAILBOX02.citrite.net>
	<1357728271.7989.220.camel@zakaz.uk.xensource.com>
In-Reply-To: <1357728271.7989.220.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] HVM firmware passthrough - helper library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, January 09, 2013 5:45 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com; Art Napor (artnapor@yahoo.com)
> Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> 
> On Tue, 2013-01-08 at 22:04 +0000, Ross Philipson wrote:
> > Attached is a tarball with a helper library for reading host ACPI and
> > SMBIOS firmware and creating firmware files that can be used with the
> > HVM firmware passthrough patches I submitted. I used it in my testing
> > of the patches and planned to use it later when we moved to a new Xen
> > version. This library was requested by a few people - I hope you find
> > it useful.
> 
> Would it make sense / are you planning to integrate this into the Xen
> tree as well? I'm not sure if it fits into an existing library e.g.
> libxenguest if it would be a separate library.
> 
> Ian.

Following up on this. Is there any interest in integrating this into
xen? I don't think it belongs in xenguest because it would be used up
at the libxl level where the fw blobs are passed in via the xl config
file. It seems like it should be in some separate utilities library
but I can't really see where.

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 20:54:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20: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 1U1Nd8-0002rZ-Ls; Fri, 01 Feb 2013 20:54:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U1Nd7-0002rT-MT
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 20:54:37 +0000
Received: from [85.158.139.211:56274] by server-15.bemta-5.messagelabs.com id
	83/98-18914-C8B2C015; Fri, 01 Feb 2013 20:54:36 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1359752075!20318324!1
X-Originating-IP: [209.85.220.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3544 invoked from network); 1 Feb 2013 20:54:36 -0000
Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com)
	(209.85.220.172)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:54:36 -0000
Received: by mail-vc0-f172.google.com with SMTP id l6so2718612vcl.31
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 12:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=Xpal5EBbISAdCE9qgV7ybgQ2BxgXLGZP6hxIYDq4Y80=;
	b=Wdtob3YEXSCM4joQo93ol4JCOkxfLXHyvCe2ZlaAv5bIZZIc0NUnpd6ZskwXgl4OVb
	MKCoy/eH0KlSDLCihc2iJuE5p17dhFoBzZaFWhdcuKv6/ey0FGeul0TGv4M2XjEjGOqi
	DsUs7yw0146HCZAsNJUFcVbfY8ylDWSYvjlZ84NF9dAqfUyWIlksELXdcDCdX5orqqUH
	OgrHztT8gHnWKLzXsexLvWFNTSMvNyE0+iVhuDjlVW52c/qK9GM2SO3A+ytzjStiJxUw
	///cXLbbr/KWhq96Uo22SFlNBvtm4v8gC986Pt9fOUcMF2Z35q5WlCsqQfOEPEW9nthq
	/iyA==
X-Received: by 10.221.0.79 with SMTP id nl15mr12575309vcb.41.1359752075136;
	Fri, 01 Feb 2013 12:54:35 -0800 (PST)
Received: from konrad-lan.dumpdata.com (ip-64-134-67-155.public.wayport.net.
	[64.134.67.155])
	by mx.google.com with ESMTPS id a19sm9182815vdh.9.2013.02.01.12.54.34
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 12:54:34 -0800 (PST)
Date: Fri, 1 Feb 2013 15:54:29 -0500
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Message-ID: <20130201205428.GA24013@konrad-lan.dumpdata.com>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
	<20130201144639.GC7461@konrad-lan.dumpdata.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458352@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458352@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 01, 2013 at 03:05:23PM +0000, Frediano Ziglio wrote:
> On Fri, 2013-02-01 at 09:46 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> > > On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > > > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > > > because is easier to have a zero cost if you disable coverage
> > > > > > informations. The best thing would be redirect do_coverage_op to
> > > > > > do_ni_hypercall using linker options but even two small stub would do
> > > > > > (these stubs will return ENOSYS instead).
> > > > > 
> > > > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > > > the hypercall path you are introducing? What is the zero cost?
> > > > 
> > > > I don't think we care a jot about the performance of this system call
> > > > when coverage is disabled, it's certainly not a hot path and in any case
> > > > if it is a NOP it doesn't really matter anyway.
> > > > 
> > > > Ian.
> > > > 
> > > 
> > > It's not about the speed, it's about the bytes introduced in Xen binary.
> > 
> > Not sure I follow. What bytes? Just that the code size is bigger b/c it
> > will go through the sysctl functions? How many bytes of extra code are
> > talking here? 
> 
> Probably less than 20...
> 
> In do_sysctl something like
> 
>     case XEN_SYSCTL_coverage_op:
>         ret = coverage_op(&op->u.coverage_op);
>         break;
> 
> where when disabled coverage_op should be declared as
> 
> static inline long coverage_op(struct xen_sysvtl_coverage_op *op)
> {
>     return -ENOSYS;
> }

Ok. Then it looks like XEN_SYSCTL_* it is the right place.

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 20:54:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 20: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 1U1Nd8-0002rZ-Ls; Fri, 01 Feb 2013 20:54:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U1Nd7-0002rT-MT
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 20:54:37 +0000
Received: from [85.158.139.211:56274] by server-15.bemta-5.messagelabs.com id
	83/98-18914-C8B2C015; Fri, 01 Feb 2013 20:54:36 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1359752075!20318324!1
X-Originating-IP: [209.85.220.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3544 invoked from network); 1 Feb 2013 20:54:36 -0000
Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com)
	(209.85.220.172)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 20:54:36 -0000
Received: by mail-vc0-f172.google.com with SMTP id l6so2718612vcl.31
	for <xen-devel@lists.xen.org>; Fri, 01 Feb 2013 12:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=Xpal5EBbISAdCE9qgV7ybgQ2BxgXLGZP6hxIYDq4Y80=;
	b=Wdtob3YEXSCM4joQo93ol4JCOkxfLXHyvCe2ZlaAv5bIZZIc0NUnpd6ZskwXgl4OVb
	MKCoy/eH0KlSDLCihc2iJuE5p17dhFoBzZaFWhdcuKv6/ey0FGeul0TGv4M2XjEjGOqi
	DsUs7yw0146HCZAsNJUFcVbfY8ylDWSYvjlZ84NF9dAqfUyWIlksELXdcDCdX5orqqUH
	OgrHztT8gHnWKLzXsexLvWFNTSMvNyE0+iVhuDjlVW52c/qK9GM2SO3A+ytzjStiJxUw
	///cXLbbr/KWhq96Uo22SFlNBvtm4v8gC986Pt9fOUcMF2Z35q5WlCsqQfOEPEW9nthq
	/iyA==
X-Received: by 10.221.0.79 with SMTP id nl15mr12575309vcb.41.1359752075136;
	Fri, 01 Feb 2013 12:54:35 -0800 (PST)
Received: from konrad-lan.dumpdata.com (ip-64-134-67-155.public.wayport.net.
	[64.134.67.155])
	by mx.google.com with ESMTPS id a19sm9182815vdh.9.2013.02.01.12.54.34
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 01 Feb 2013 12:54:34 -0800 (PST)
Date: Fri, 1 Feb 2013 15:54:29 -0500
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Message-ID: <20130201205428.GA24013@konrad-lan.dumpdata.com>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
	<20130201144639.GC7461@konrad-lan.dumpdata.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458352@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458352@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Adding support for coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 01, 2013 at 03:05:23PM +0000, Frediano Ziglio wrote:
> On Fri, 2013-02-01 at 09:46 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> > > On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > > > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > > > because is easier to have a zero cost if you disable coverage
> > > > > > informations. The best thing would be redirect do_coverage_op to
> > > > > > do_ni_hypercall using linker options but even two small stub would do
> > > > > > (these stubs will return ENOSYS instead).
> > > > > 
> > > > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > > > the hypercall path you are introducing? What is the zero cost?
> > > > 
> > > > I don't think we care a jot about the performance of this system call
> > > > when coverage is disabled, it's certainly not a hot path and in any case
> > > > if it is a NOP it doesn't really matter anyway.
> > > > 
> > > > Ian.
> > > > 
> > > 
> > > It's not about the speed, it's about the bytes introduced in Xen binary.
> > 
> > Not sure I follow. What bytes? Just that the code size is bigger b/c it
> > will go through the sysctl functions? How many bytes of extra code are
> > talking here? 
> 
> Probably less than 20...
> 
> In do_sysctl something like
> 
>     case XEN_SYSCTL_coverage_op:
>         ret = coverage_op(&op->u.coverage_op);
>         break;
> 
> where when disabled coverage_op should be declared as
> 
> static inline long coverage_op(struct xen_sysvtl_coverage_op *op)
> {
>     return -ENOSYS;
> }

Ok. Then it looks like XEN_SYSCTL_* it is the right place.

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 21:59:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 21: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 1U1OdU-0003MZ-3j; Fri, 01 Feb 2013 21:59:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U1OdS-0003MU-Ox
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 21:59:02 +0000
Received: from [85.158.139.83:34643] by server-15.bemta-5.messagelabs.com id
	4F/3B-18914-6AA3C015; Fri, 01 Feb 2013 21:59:02 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359755940!29628376!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4996 invoked from network); 1 Feb 2013 21:59:01 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-13.tower-182.messagelabs.com with SMTP;
	1 Feb 2013 21:59:01 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r11LwxwR029755
	for <xen-devel@lists.xensource.com>; Fri, 1 Feb 2013 16:58:59 -0500
Message-ID: <510C3AA3.2090508@theshore.net>
Date: Fri, 01 Feb 2013 16:58:59 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] netback Oops then xenwatch stuck in D 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-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

We've been hitting the following issue on a variety of hosts and recent 
Xen/dom0 version combinations.  Here's an excerpt from our latest:

Xen: 4.1.4 (xenbits @ 23432)
Dom0: 3.7.1-x86_64

BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb
CPU 0
Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro 
X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+
RIP: e030:[<ffffffff8141a301>]  [<ffffffff8141a301>] 
evtchn_from_irq+0x11/0x40
RSP: e02b:ffff88004334fc98  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c
RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000
R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720
R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84
FS:  00007f8939347700(0000) GS:ffff880101e00000(0000) 
knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task 
ffff880043fd5fe0)
Stack:
  ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200
  ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040
  ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0
Call Trace:
  [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40
  [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/0x800
  [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60
  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
  [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/0xa10
  [<ffffffff81071926>] kthread+0xc6/0xd0
  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 
00 00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff <0f> b7 
40 1c c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00
RIP  [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
  RSP <ffff88004334fc98>
CR2: 000000000000001c
---[ end trace 1b5f6b359343fcfe ]---


Which leads to xenwatch being stuck in D state, which then requires us 
to reboot the host.

SysRq : Show Blocked State
   task                        PC stack   pid father
xenwatch        D ffff880101f938c0  5056    49      2 0x00000000
  ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0
  ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0
  ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760
Call Trace:
  [<ffffffff8175f444>] schedule+0x24/0x70
  [<ffffffff8154698d>] xenvif_disconnect+0x7d/0x130
  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
  [<ffffffff81545ac4>] frontend_changed+0x214/0x660
  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
  [<ffffffff8141fb22>] xenbus_otherend_changed+0xb2/0xc0
  [<ffffffff8175fe39>] ? _raw_spin_unlock_irqrestore+0x19/0x20
  [<ffffffff8141fd3b>] frontend_changed+0xb/0x10
  [<ffffffff8141da3a>] xenwatch_thread+0xba/0x180
  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
  [<ffffffff8141d980>] ? xs_watch+0x60/0x60
  [<ffffffff81071926>] kthread+0xc6/0xd0
  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70

I'll give building an updated dom0 kernel a shot, but was hoping this 
rang a bell or two.

Thanks,
-Chris

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 21:59:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 21: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 1U1OdU-0003MZ-3j; Fri, 01 Feb 2013 21:59:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U1OdS-0003MU-Ox
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 21:59:02 +0000
Received: from [85.158.139.83:34643] by server-15.bemta-5.messagelabs.com id
	4F/3B-18914-6AA3C015; Fri, 01 Feb 2013 21:59:02 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359755940!29628376!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4996 invoked from network); 1 Feb 2013 21:59:01 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-13.tower-182.messagelabs.com with SMTP;
	1 Feb 2013 21:59:01 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r11LwxwR029755
	for <xen-devel@lists.xensource.com>; Fri, 1 Feb 2013 16:58:59 -0500
Message-ID: <510C3AA3.2090508@theshore.net>
Date: Fri, 01 Feb 2013 16:58:59 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] netback Oops then xenwatch stuck in D 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-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

We've been hitting the following issue on a variety of hosts and recent 
Xen/dom0 version combinations.  Here's an excerpt from our latest:

Xen: 4.1.4 (xenbits @ 23432)
Dom0: 3.7.1-x86_64

BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb
CPU 0
Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro 
X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+
RIP: e030:[<ffffffff8141a301>]  [<ffffffff8141a301>] 
evtchn_from_irq+0x11/0x40
RSP: e02b:ffff88004334fc98  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c
RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000
R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720
R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84
FS:  00007f8939347700(0000) GS:ffff880101e00000(0000) 
knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task 
ffff880043fd5fe0)
Stack:
  ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200
  ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040
  ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0
Call Trace:
  [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40
  [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/0x800
  [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60
  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
  [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/0xa10
  [<ffffffff81071926>] kthread+0xc6/0xd0
  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 
00 00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff <0f> b7 
40 1c c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00
RIP  [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
  RSP <ffff88004334fc98>
CR2: 000000000000001c
---[ end trace 1b5f6b359343fcfe ]---


Which leads to xenwatch being stuck in D state, which then requires us 
to reboot the host.

SysRq : Show Blocked State
   task                        PC stack   pid father
xenwatch        D ffff880101f938c0  5056    49      2 0x00000000
  ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0
  ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0
  ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760
Call Trace:
  [<ffffffff8175f444>] schedule+0x24/0x70
  [<ffffffff8154698d>] xenvif_disconnect+0x7d/0x130
  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
  [<ffffffff81545ac4>] frontend_changed+0x214/0x660
  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
  [<ffffffff8141fb22>] xenbus_otherend_changed+0xb2/0xc0
  [<ffffffff8175fe39>] ? _raw_spin_unlock_irqrestore+0x19/0x20
  [<ffffffff8141fd3b>] frontend_changed+0xb/0x10
  [<ffffffff8141da3a>] xenwatch_thread+0xba/0x180
  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
  [<ffffffff8141d980>] ? xs_watch+0x60/0x60
  [<ffffffff81071926>] kthread+0xc6/0xd0
  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70

I'll give building an updated dom0 kernel a shot, but was hoping this 
rang a bell or two.

Thanks,
-Chris

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

From xen-devel-bounces@lists.xen.org Fri Feb 01 22:01:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 22:01: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 1U1OfW-0003UF-Kl; Fri, 01 Feb 2013 22:01:10 +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 1U1OfV-0003U9-Qb
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 22:01:10 +0000
Received: from [85.158.137.99:62606] by server-1.bemta-3.messagelabs.com id
	88/EC-08955-52B3C015; Fri, 01 Feb 2013 22:01:09 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1359756066!17282620!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDg4MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27516 invoked from network); 1 Feb 2013 22:01:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 22:01:08 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r11M11Y6014490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 22:01:02 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
	r11M101Q006737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 22:01:01 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
	r11M10IF004772; Fri, 1 Feb 2013 16:01:00 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 01 Feb 2013 14:01:00 -0800
Date: Fri, 1 Feb 2013 14:00:58 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130201140058.156d3b9c@mantra.us.oracle.com>
In-Reply-To: <20130131184446.654a2289@mantra.us.oracle.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
	<20130131184446.654a2289@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: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
 table 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

On Thu, 31 Jan 2013 18:44:46 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 31 Jan 2013 18:30:15 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > This patch fixes a fixme in Linux to use alloc_xenballooned_pages()
> > to allocate pfns for grant table pages instead of kmalloc. This also
> > simplifies add to physmap on the xen side a bit.
> 
> Looking at it again, I realized rc should be signed in
> gnttab_resume(). Below again. Thanks.

Konrad, Please hold off on this patch. I discovered an issue on the 
domU side with this change. I'm currently investigating if it's 
related.

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 Feb 01 22:01:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 22:01: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 1U1OfW-0003UF-Kl; Fri, 01 Feb 2013 22:01:10 +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 1U1OfV-0003U9-Qb
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 22:01:10 +0000
Received: from [85.158.137.99:62606] by server-1.bemta-3.messagelabs.com id
	88/EC-08955-52B3C015; Fri, 01 Feb 2013 22:01:09 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1359756066!17282620!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDg4MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27516 invoked from network); 1 Feb 2013 22:01:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 1 Feb 2013 22:01:08 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r11M11Y6014490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 22:01:02 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
	r11M101Q006737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 22:01:01 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
	r11M10IF004772; Fri, 1 Feb 2013 16:01:00 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 01 Feb 2013 14:01:00 -0800
Date: Fri, 1 Feb 2013 14:00:58 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130201140058.156d3b9c@mantra.us.oracle.com>
In-Reply-To: <20130131184446.654a2289@mantra.us.oracle.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
	<20130131184446.654a2289@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: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
 table 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

On Thu, 31 Jan 2013 18:44:46 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 31 Jan 2013 18:30:15 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > This patch fixes a fixme in Linux to use alloc_xenballooned_pages()
> > to allocate pfns for grant table pages instead of kmalloc. This also
> > simplifies add to physmap on the xen side a bit.
> 
> Looking at it again, I realized rc should be signed in
> gnttab_resume(). Below again. Thanks.

Konrad, Please hold off on this patch. I discovered an issue on the 
domU side with this change. I'm currently investigating if it's 
related.

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 Feb 01 22:11:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 22:11: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 1U1Ooo-0003hh-Ni; Fri, 01 Feb 2013 22:10: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 1U1Oom-0003hc-Vo
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 22:10:45 +0000
Received: from [85.158.139.211:59113] by server-11.bemta-5.messagelabs.com id
	90/18-19159-46D3C015; Fri, 01 Feb 2013 22:10:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1359756642!17984197!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk3ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15180 invoked from network); 1 Feb 2013 22:10:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 22:10:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="6019401"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 22:10:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 17:10:41 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U1Ooi-0001N8-Pt;
	Fri, 01 Feb 2013 22:10:40 +0000
Message-ID: <1359756493.29345.1.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 23:08:13 +0100
In-Reply-To: <510BA877.40200@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-6-git-send-email-wei.liu2@citrix.com>
	<510BA877.40200@citrix.com>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>, "jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/13] xen: introduce test_and_set_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:35 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |   10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 93a3648..0fae3f9 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -345,6 +345,12 @@ static inline int test_evtchn(int port)
> >  	return sync_test_bit(port, &s->evtchn_pending[0]);
> >  }
> >  
> > +static inline int test_and_set_mask(int port)
> 
> This name is too generic.  Suggest test_and_set_evtchn_mask() or similar.

For a static function inside drivers/xen/events.c that seems like
overkill.

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 22:11:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 22:11: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 1U1Ooo-0003hh-Ni; Fri, 01 Feb 2013 22:10: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 1U1Oom-0003hc-Vo
	for xen-devel@lists.xen.org; Fri, 01 Feb 2013 22:10:45 +0000
Received: from [85.158.139.211:59113] by server-11.bemta-5.messagelabs.com id
	90/18-19159-46D3C015; Fri, 01 Feb 2013 22:10:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1359756642!17984197!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk3ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15180 invoked from network); 1 Feb 2013 22:10:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Feb 2013 22:10:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="6019401"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 22:10:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 17:10:41 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U1Ooi-0001N8-Pt;
	Fri, 01 Feb 2013 22:10:40 +0000
Message-ID: <1359756493.29345.1.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 1 Feb 2013 23:08:13 +0100
In-Reply-To: <510BA877.40200@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-6-git-send-email-wei.liu2@citrix.com>
	<510BA877.40200@citrix.com>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Wei Liu <wei.liu2@citrix.com>, "jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/13] xen: introduce test_and_set_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 11:35 +0000, David Vrabel wrote:
> On 31/01/13 14:46, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |   10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 93a3648..0fae3f9 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -345,6 +345,12 @@ static inline int test_evtchn(int port)
> >  	return sync_test_bit(port, &s->evtchn_pending[0]);
> >  }
> >  
> > +static inline int test_and_set_mask(int port)
> 
> This name is too generic.  Suggest test_and_set_evtchn_mask() or similar.

For a static function inside drivers/xen/events.c that seems like
overkill.

Ian.


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

From xen-devel-bounces@lists.xen.org Fri Feb 01 22:15:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 22:15: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 1U1OtF-000402-2B; Fri, 01 Feb 2013 22:15:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U1OtD-0003zt-PU
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 22:15:19 +0000
Received: from [193.109.254.147:46838] by server-15.bemta-14.messagelabs.com
	id 1E/9E-24599-77E3C015; Fri, 01 Feb 2013 22:15:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1359756866!8955451!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDExMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7406 invoked from network); 1 Feb 2013 22:14:30 -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;
	1 Feb 2013 22:14:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5725441"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 22:14:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 17:14:25 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U1OsL-0001Rj-A9;
	Fri, 01 Feb 2013 22:14:25 +0000
Message-ID: <510C3E41.8010705@citrix.com>
Date: Fri, 1 Feb 2013 22:14:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: "Christopher S. Aker" <caker@theshore.net>
References: <510C3AA3.2090508@theshore.net>
In-Reply-To: <510C3AA3.2090508@theshore.net>
X-Enigmail-Version: 1.4
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 01/02/13 21:58, Christopher S. Aker wrote:
> We've been hitting the following issue on a variety of hosts and recent 
> Xen/dom0 version combinations.  Here's an excerpt from our latest:
>
> Xen: 4.1.4 (xenbits @ 23432)
> Dom0: 3.7.1-x86_64
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb
> CPU 0
> Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro 
> X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+
> RIP: e030:[<ffffffff8141a301>]  [<ffffffff8141a301>] 
> evtchn_from_irq+0x11/0x40
> RSP: e02b:ffff88004334fc98  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c
> RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000
> R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720
> R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84
> FS:  00007f8939347700(0000) GS:ffff880101e00000(0000) 
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task 
> ffff880043fd5fe0)
> Stack:
>   ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200
>   ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040
>   ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0
> Call Trace:
>   [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40
>   [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/0x800
>   [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60
>   [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/0xa10
>   [<ffffffff81071926>] kthread+0xc6/0xd0
>   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
>   [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
> Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 
> 00 00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff <0f> b7 
> 40 1c c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00
> RIP  [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
>   RSP <ffff88004334fc98>
> CR2: 000000000000001c
> ---[ end trace 1b5f6b359343fcfe ]---
>
>
> Which leads to xenwatch being stuck in D state, which then requires us 
> to reboot the host.
>
> SysRq : Show Blocked State
>    task                        PC stack   pid father
> xenwatch        D ffff880101f938c0  5056    49      2 0x00000000
>   ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0
>   ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0
>   ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760
> Call Trace:
>   [<ffffffff8175f444>] schedule+0x24/0x70
>   [<ffffffff8154698d>] xenvif_disconnect+0x7d/0x130
>   [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff81545ac4>] frontend_changed+0x214/0x660
>   [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff8141fb22>] xenbus_otherend_changed+0xb2/0xc0
>   [<ffffffff8175fe39>] ? _raw_spin_unlock_irqrestore+0x19/0x20
>   [<ffffffff8141fd3b>] frontend_changed+0xb/0x10
>   [<ffffffff8141da3a>] xenwatch_thread+0xba/0x180
>   [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff8141d980>] ? xs_watch+0x60/0x60
>   [<ffffffff81071926>] kthread+0xc6/0xd0
>   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
>   [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
>
> I'll give building an updated dom0 kernel a shot, but was hoping this 
> rang a bell or two.
>
> Thanks,
> -Chris

Well - it looks like info_for_irq(irq) returns a null pointer, and
evtchn_from_irq blindly dereferences it trying to find the event channel.

As for why the info is NULL, I can't help you, but perhaps there should
be a NULL check, returning 0 in the case of an error?

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 01 22:15:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 22:15: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 1U1OtF-000402-2B; Fri, 01 Feb 2013 22:15:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U1OtD-0003zt-PU
	for xen-devel@lists.xensource.com; Fri, 01 Feb 2013 22:15:19 +0000
Received: from [193.109.254.147:46838] by server-15.bemta-14.messagelabs.com
	id 1E/9E-24599-77E3C015; Fri, 01 Feb 2013 22:15:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1359756866!8955451!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDExMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7406 invoked from network); 1 Feb 2013 22:14:30 -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;
	1 Feb 2013 22:14:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; 
   d="scan'208";a="5725441"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	01 Feb 2013 22:14:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 1 Feb 2013 17:14:25 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U1OsL-0001Rj-A9;
	Fri, 01 Feb 2013 22:14:25 +0000
Message-ID: <510C3E41.8010705@citrix.com>
Date: Fri, 1 Feb 2013 22:14:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: "Christopher S. Aker" <caker@theshore.net>
References: <510C3AA3.2090508@theshore.net>
In-Reply-To: <510C3AA3.2090508@theshore.net>
X-Enigmail-Version: 1.4
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 01/02/13 21:58, Christopher S. Aker wrote:
> We've been hitting the following issue on a variety of hosts and recent 
> Xen/dom0 version combinations.  Here's an excerpt from our latest:
>
> Xen: 4.1.4 (xenbits @ 23432)
> Dom0: 3.7.1-x86_64
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb
> CPU 0
> Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro 
> X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+
> RIP: e030:[<ffffffff8141a301>]  [<ffffffff8141a301>] 
> evtchn_from_irq+0x11/0x40
> RSP: e02b:ffff88004334fc98  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c
> RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000
> R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720
> R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84
> FS:  00007f8939347700(0000) GS:ffff880101e00000(0000) 
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task 
> ffff880043fd5fe0)
> Stack:
>   ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200
>   ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040
>   ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0
> Call Trace:
>   [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40
>   [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/0x800
>   [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60
>   [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/0xa10
>   [<ffffffff81071926>] kthread+0xc6/0xd0
>   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
>   [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
> Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 
> 00 00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff <0f> b7 
> 40 1c c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00
> RIP  [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
>   RSP <ffff88004334fc98>
> CR2: 000000000000001c
> ---[ end trace 1b5f6b359343fcfe ]---
>
>
> Which leads to xenwatch being stuck in D state, which then requires us 
> to reboot the host.
>
> SysRq : Show Blocked State
>    task                        PC stack   pid father
> xenwatch        D ffff880101f938c0  5056    49      2 0x00000000
>   ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0
>   ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0
>   ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760
> Call Trace:
>   [<ffffffff8175f444>] schedule+0x24/0x70
>   [<ffffffff8154698d>] xenvif_disconnect+0x7d/0x130
>   [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff81545ac4>] frontend_changed+0x214/0x660
>   [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff8141fb22>] xenbus_otherend_changed+0xb2/0xc0
>   [<ffffffff8175fe39>] ? _raw_spin_unlock_irqrestore+0x19/0x20
>   [<ffffffff8141fd3b>] frontend_changed+0xb/0x10
>   [<ffffffff8141da3a>] xenwatch_thread+0xba/0x180
>   [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff8141d980>] ? xs_watch+0x60/0x60
>   [<ffffffff81071926>] kthread+0xc6/0xd0
>   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
>   [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70
>
> I'll give building an updated dom0 kernel a shot, but was hoping this 
> rang a bell or two.
>
> Thanks,
> -Chris

Well - it looks like info_for_irq(irq) returns a null pointer, and
evtchn_from_irq blindly dereferences it trying to find the event channel.

As for why the info is NULL, I can't help you, but perhaps there should
be a NULL check, returning 0 in the case of an error?

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 01 23:52:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 23:52: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 1U1QOX-0004v5-JF; Fri, 01 Feb 2013 23:51:45 +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 1U1QOV-0004uu-V4
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 23:51:44 +0000
Received: from [85.158.138.51:49648] by server-12.bemta-3.messagelabs.com id
	66/52-05889-F055C015; Fri, 01 Feb 2013 23:51:43 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359762700!28475958!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDg4MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12984 invoked from network); 1 Feb 2013 23:51:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 23:51:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r11NpZdX007925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 23:51:36 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
	r11NpZGl025333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 23:51:35 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
	r11NpZ3O012996; Fri, 1 Feb 2013 17:51:35 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 01 Feb 2013 15:51:34 -0800
Date: Fri, 1 Feb 2013 15:51:32 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130201155132.71e0257c@mantra.us.oracle.com>
In-Reply-To: <20130201140058.156d3b9c@mantra.us.oracle.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
	<20130131184446.654a2289@mantra.us.oracle.com>
	<20130201140058.156d3b9c@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]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
 table 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

On Fri, 1 Feb 2013 14:00:58 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 31 Jan 2013 18:44:46 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > On Thu, 31 Jan 2013 18:30:15 -0800
> > Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > 
> > > This patch fixes a fixme in Linux to use
> > > alloc_xenballooned_pages() to allocate pfns for grant table pages
> > > instead of kmalloc. This also simplifies add to physmap on the
> > > xen side a bit.
> > 
> > Looking at it again, I realized rc should be signed in
> > gnttab_resume(). Below again. Thanks.
> 
> Konrad, Please hold off on this patch. I discovered an issue on the 
> domU side with this change. I'm currently investigating if it's 
> related.

Ah right, I forgot the pfn's from balloon may not be always contigous.
Besides these are special pfns so to speak, so in gnttab_map()
virt_to_pfn doesn't work. 

I'm gonna have to create a separate gnttab map routine for pvh case, it
appears. Shouldn't be too bad tho.

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 Feb 01 23:52:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 01 Feb 2013 23:52: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 1U1QOX-0004v5-JF; Fri, 01 Feb 2013 23:51:45 +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 1U1QOV-0004uu-V4
	for Xen-devel@lists.xensource.com; Fri, 01 Feb 2013 23:51:44 +0000
Received: from [85.158.138.51:49648] by server-12.bemta-3.messagelabs.com id
	66/52-05889-F055C015; Fri, 01 Feb 2013 23:51:43 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1359762700!28475958!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMDg4MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12984 invoked from network); 1 Feb 2013 23:51:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Feb 2013 23:51:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id r11NpZdX007925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 1 Feb 2013 23:51:36 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
	r11NpZGl025333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 1 Feb 2013 23:51:35 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
	r11NpZ3O012996; Fri, 1 Feb 2013 17:51:35 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 01 Feb 2013 15:51:34 -0800
Date: Fri, 1 Feb 2013 15:51:32 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130201155132.71e0257c@mantra.us.oracle.com>
In-Reply-To: <20130201140058.156d3b9c@mantra.us.oracle.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
	<20130131184446.654a2289@mantra.us.oracle.com>
	<20130201140058.156d3b9c@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]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
 table 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

On Fri, 1 Feb 2013 14:00:58 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 31 Jan 2013 18:44:46 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > On Thu, 31 Jan 2013 18:30:15 -0800
> > Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > 
> > > This patch fixes a fixme in Linux to use
> > > alloc_xenballooned_pages() to allocate pfns for grant table pages
> > > instead of kmalloc. This also simplifies add to physmap on the
> > > xen side a bit.
> > 
> > Looking at it again, I realized rc should be signed in
> > gnttab_resume(). Below again. Thanks.
> 
> Konrad, Please hold off on this patch. I discovered an issue on the 
> domU side with this change. I'm currently investigating if it's 
> related.

Ah right, I forgot the pfn's from balloon may not be always contigous.
Besides these are special pfns so to speak, so in gnttab_map()
virt_to_pfn doesn't work. 

I'm gonna have to create a separate gnttab map routine for pvh case, it
appears. Shouldn't be too bad tho.

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 Feb 02 01:02:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 01:02: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 1U1RUu-0002hU-K6; Sat, 02 Feb 2013 01:02:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U1RUs-0002LD-Ua
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 01:02:23 +0000
Received: from [193.109.254.147:58829] by server-12.bemta-14.messagelabs.com
	id 9F/6F-32582-E956C015; Sat, 02 Feb 2013 01:02:22 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-4.tower-27.messagelabs.com!1359766940!8880364!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 2 Feb 2013 01:02:20 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 01:02:20 -0000
Received: by mail-wi0-f182.google.com with SMTP id hn14so1208675wib.15
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Feb 2013 17:02:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=xoWkPBJ4rNRFJjJ4VR4a7oqateZI7SgwER4sTaZ9RkE=;
	b=AjIaM8M82+YHtl2N5uOUVBGA7FKFC+PE3kgHgfauXMQxrSBC2bWj8N6M4mJylupyob
	/f0onC3ztnLKqNaJzOkgVwJNn46wFY9Gm1GSss8itPsq+fHbhrcpHfMKPe4gZbqp83Hh
	xET5f1Ixey3/deB/+BHmzG1Ps4im7DU4BcZcr281zEMdaDvcK7DJnqTIATuBYiU1Xnx+
	0Wj0QtQwsDRSoBwGtgxHWKhAI8D6CdjbWxHWAthRAwzrmkjLiCFJhUCJPr4hfC3KxOTs
	0PYb/qTc4eosUeL0SnfDEsnLSCEh8a7Z1YuZSAedXt3UHINUU9VniLr1t8qq4JCH+eBy
	lCgA==
X-Received: by 10.180.77.35 with SMTP id p3mr716628wiw.18.1359766939604; Fri,
	01 Feb 2013 17:02:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.80.98 with HTTP; Fri, 1 Feb 2013 17:01:48 -0800 (PST)
In-Reply-To: <510C3AA3.2090508@theshore.net>
References: <510C3AA3.2090508@theshore.net>
From: Wei Liu <liuw@liuw.name>
Date: Sat, 2 Feb 2013 01:01:48 +0000
Message-ID: <CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
To: "Christopher S. Aker" <caker@theshore.net>
X-Gm-Message-State: ALoCoQn3Pq+jvKE8OfnRtJU9opSHpUfrTx3kyN6K8NBqWkPuweGveVx0PQDZ7eD88n7iUFDihPcI
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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: multipart/mixed; boundary="===============3213613126076694081=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3213613126076694081==
Content-Type: multipart/alternative; boundary=f46d043c064469976304d4b3694b

--f46d043c064469976304d4b3694b
Content-Type: text/plain; charset=UTF-8

Dose your Dom0 has very limited RAM?

Just happened to fix a bug related to OOM not getting handled correctly.

http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html


Wei.


On Fri, Feb 1, 2013 at 9:58 PM, Christopher S. Aker <caker@theshore.net>wrote:

> We've been hitting the following issue on a variety of hosts and recent
> Xen/dom0 version combinations.  Here's an excerpt from our latest:
>
> Xen: 4.1.4 (xenbits @ 23432)
> Dom0: 3.7.1-x86_64
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip
> ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb
> CPU 0
> Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro
> X9DRi-LN4+/X9DR3-LN4+/X9DRi-**LN4+/X9DR3-LN4+
> RIP: e030:[<ffffffff8141a301>]  [<ffffffff8141a301>]
> evtchn_from_irq+0x11/0x40
> RSP: e02b:ffff88004334fc98  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c
> RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000
> R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720
> R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84
> FS:  00007f8939347700(0000) GS:ffff880101e00000(0000)
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task
> ffff880043fd5fe0)
> Stack:
>  ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200
>  ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040
>  ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0
> Call Trace:
>  [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40
>  [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/**0x800
>  [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60
>  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>  [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/**0xa10
>  [<ffffffff81071926>] kthread+0xc6/0xd0
>  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/**0x20
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
>  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
> Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 00
> 00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff <0f> b7 40 1c
> c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00
> RIP  [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
>  RSP <ffff88004334fc98>
> CR2: 000000000000001c
> ---[ end trace 1b5f6b359343fcfe ]---
>
>
> Which leads to xenwatch being stuck in D state, which then requires us to
> reboot the host.
>
> SysRq : Show Blocked State
>   task                        PC stack   pid father
> xenwatch        D ffff880101f938c0  5056    49      2 0x00000000
>  ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0
>  ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0
>  ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760
> Call Trace:
>  [<ffffffff8175f444>] schedule+0x24/0x70
>  [<ffffffff8154698d>] xenvif_disconnect+0x7d/0x130
>  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>  [<ffffffff81545ac4>] frontend_changed+0x214/0x660
>  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>  [<ffffffff8141fb22>] xenbus_otherend_changed+0xb2/**0xc0
>  [<ffffffff8175fe39>] ? _raw_spin_unlock_irqrestore+**0x19/0x20
>  [<ffffffff8141fd3b>] frontend_changed+0xb/0x10
>  [<ffffffff8141da3a>] xenwatch_thread+0xba/0x180
>  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>  [<ffffffff8141d980>] ? xs_watch+0x60/0x60
>  [<ffffffff81071926>] kthread+0xc6/0xd0
>  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/**0x20
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
>  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
>
> I'll give building an updated dom0 kernel a shot, but was hoping this rang
> a bell or two.
>
> Thanks,
> -Chris
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

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

<div dir=3D"ltr">Dose your Dom0 has very limited RAM?<div><br></div><div>Ju=
st happened to fix a bug related to OOM not getting handled correctly.</div=
><div><br></div><div><a href=3D"http://lists.xen.org/archives/html/xen-deve=
l/2013-01/msg02549.html" target=3D"_blank">http://lists.xen.org/archives/ht=
ml/xen-devel/2013-01/msg02549.html</a></div>


<div><br></div><div><br></div><div>Wei.<br><div class=3D"gmail_extra"><br><=
br><div class=3D"gmail_quote">On Fri, Feb 1, 2013 at 9:58 PM, Christopher S=
. Aker <span dir=3D"ltr">&lt;<a href=3D"mailto:caker@theshore.net" target=
=3D"_blank">caker@theshore.net</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">We&#39;ve been hitting the following issue on a variety of=
 hosts and recent Xen/dom0 version combinations. =C2=A0Here&#39;s an excerp=
t from our latest:<br>



<br>
Xen: 4.1.4 (xenbits @ 23432)<br>
Dom0: 3.7.1-x86_64<br>
<br>
BUG: unable to handle kernel NULL pointer dereference at 000000000000001c<b=
r>
IP: [&lt;ffffffff8141a301&gt;] evtchn_from_irq+0x11/0x40<br>
PGD 0<br>
Oops: 0000 [#1] SMP<br>
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_=
set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb<br>
CPU 0<br>
Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro X9DRi-LN4=
+/X9DR3-LN4+/X9DRi-<u></u>LN4+/X9DR3-LN4+<br>
RIP: e030:[&lt;ffffffff8141a301&gt;] =C2=A0[&lt;ffffffff8141a301&gt;] evtch=
n_from_irq+0x11/0x40<br>
RSP: e02b:ffff88004334fc98 =C2=A0EFLAGS: 00010246<br>
RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000<br>
RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c<br>
RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000<br>
R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720<br>
R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84<br>
FS: =C2=A000007f8939347700(0000) GS:ffff880101e00000(0000) knlGS:0000000000=
000000<br>
CS: =C2=A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b<br>
CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660<br>
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br>
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br>
Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task ffff880043f=
d5fe0)<br>
Stack:<br>
=C2=A0ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200<b=
r>
=C2=A0ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040<b=
r>
=C2=A0ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0<b=
r>
Call Trace:<br>
=C2=A0[&lt;ffffffff8141b06d&gt;] notify_remote_via_irq+0xd/0x40<br>
=C2=A0[&lt;ffffffff81543b9b&gt;] xen_netbk_rx_action+0x73b/<u></u>0x800<br>
=C2=A0[&lt;ffffffff81544c25&gt;] xen_netbk_kthread+0xb5/0xa60<br>
=C2=A0[&lt;ffffffff81080050&gt;] ? finish_task_switch+0x60/0xd0<br>
=C2=A0[&lt;ffffffff81071fe0&gt;] ? wake_up_bit+0x40/0x40<br>
=C2=A0[&lt;ffffffff81544b70&gt;] ? xen_netbk_tx_build_gops+0xa10/<u></u>0xa=
10<br>
=C2=A0[&lt;ffffffff81071926&gt;] kthread+0xc6/0xd0<br>
=C2=A0[&lt;ffffffff810037b9&gt;] ? xen_end_context_switch+0x19/<u></u>0x20<=
br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
=C2=A0[&lt;ffffffff81767c7c&gt;] ret_from_fork+0x7c/0xb0<br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 00 =
00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff &lt;0f&gt; b7 4=
0 1c c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00<br>
RIP =C2=A0[&lt;ffffffff8141a301&gt;] evtchn_from_irq+0x11/0x40<br>
=C2=A0RSP &lt;ffff88004334fc98&gt;<br>
CR2: 000000000000001c<br>
---[ end trace 1b5f6b359343fcfe ]---<br>
<br>
<br>
Which leads to xenwatch being stuck in D state, which then requires us to r=
eboot the host.<br>
<br>
SysRq : Show Blocked State<br>
=C2=A0 task =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0PC stack =C2=A0 pid father<br>
xenwatch =C2=A0 =C2=A0 =C2=A0 =C2=A0D ffff880101f938c0 =C2=A05056 =C2=A0 =
=C2=A049 =C2=A0 =C2=A0 =C2=A02 0x00000000<br>
=C2=A0ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0<b=
r>
=C2=A0ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0<b=
r>
=C2=A0ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760<b=
r>
Call Trace:<br>
=C2=A0[&lt;ffffffff8175f444&gt;] schedule+0x24/0x70<br>
=C2=A0[&lt;ffffffff8154698d&gt;] xenvif_disconnect+0x7d/0x130<br>
=C2=A0[&lt;ffffffff81071fe0&gt;] ? wake_up_bit+0x40/0x40<br>
=C2=A0[&lt;ffffffff81545ac4&gt;] frontend_changed+0x214/0x660<br>
=C2=A0[&lt;ffffffff81080050&gt;] ? finish_task_switch+0x60/0xd0<br>
=C2=A0[&lt;ffffffff8141fb22&gt;] xenbus_otherend_changed+0xb2/<u></u>0xc0<b=
r>
=C2=A0[&lt;ffffffff8175fe39&gt;] ? _raw_spin_unlock_irqrestore+<u></u>0x19/=
0x20<br>
=C2=A0[&lt;ffffffff8141fd3b&gt;] frontend_changed+0xb/0x10<br>
=C2=A0[&lt;ffffffff8141da3a&gt;] xenwatch_thread+0xba/0x180<br>
=C2=A0[&lt;ffffffff81071fe0&gt;] ? wake_up_bit+0x40/0x40<br>
=C2=A0[&lt;ffffffff8141d980&gt;] ? xs_watch+0x60/0x60<br>
=C2=A0[&lt;ffffffff81071926&gt;] kthread+0xc6/0xd0<br>
=C2=A0[&lt;ffffffff810037b9&gt;] ? xen_end_context_switch+0x19/<u></u>0x20<=
br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
=C2=A0[&lt;ffffffff81767c7c&gt;] ret_from_fork+0x7c/0xb0<br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
<br>
I&#39;ll give building an updated dom0 kernel a shot, but was hoping this r=
ang a bell or two.<br>
<br>
Thanks,<br>
-Chris<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.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>
</blockquote></div><br></div></div></div>

--f46d043c064469976304d4b3694b--


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

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

--===============3213613126076694081==--


From xen-devel-bounces@lists.xen.org Sat Feb 02 01:02:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 01:02: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 1U1RUu-0002hU-K6; Sat, 02 Feb 2013 01:02:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U1RUs-0002LD-Ua
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 01:02:23 +0000
Received: from [193.109.254.147:58829] by server-12.bemta-14.messagelabs.com
	id 9F/6F-32582-E956C015; Sat, 02 Feb 2013 01:02:22 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-4.tower-27.messagelabs.com!1359766940!8880364!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 2 Feb 2013 01:02:20 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 01:02:20 -0000
Received: by mail-wi0-f182.google.com with SMTP id hn14so1208675wib.15
	for <xen-devel@lists.xensource.com>;
	Fri, 01 Feb 2013 17:02:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=xoWkPBJ4rNRFJjJ4VR4a7oqateZI7SgwER4sTaZ9RkE=;
	b=AjIaM8M82+YHtl2N5uOUVBGA7FKFC+PE3kgHgfauXMQxrSBC2bWj8N6M4mJylupyob
	/f0onC3ztnLKqNaJzOkgVwJNn46wFY9Gm1GSss8itPsq+fHbhrcpHfMKPe4gZbqp83Hh
	xET5f1Ixey3/deB/+BHmzG1Ps4im7DU4BcZcr281zEMdaDvcK7DJnqTIATuBYiU1Xnx+
	0Wj0QtQwsDRSoBwGtgxHWKhAI8D6CdjbWxHWAthRAwzrmkjLiCFJhUCJPr4hfC3KxOTs
	0PYb/qTc4eosUeL0SnfDEsnLSCEh8a7Z1YuZSAedXt3UHINUU9VniLr1t8qq4JCH+eBy
	lCgA==
X-Received: by 10.180.77.35 with SMTP id p3mr716628wiw.18.1359766939604; Fri,
	01 Feb 2013 17:02:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.80.98 with HTTP; Fri, 1 Feb 2013 17:01:48 -0800 (PST)
In-Reply-To: <510C3AA3.2090508@theshore.net>
References: <510C3AA3.2090508@theshore.net>
From: Wei Liu <liuw@liuw.name>
Date: Sat, 2 Feb 2013 01:01:48 +0000
Message-ID: <CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
To: "Christopher S. Aker" <caker@theshore.net>
X-Gm-Message-State: ALoCoQn3Pq+jvKE8OfnRtJU9opSHpUfrTx3kyN6K8NBqWkPuweGveVx0PQDZ7eD88n7iUFDihPcI
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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: multipart/mixed; boundary="===============3213613126076694081=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3213613126076694081==
Content-Type: multipart/alternative; boundary=f46d043c064469976304d4b3694b

--f46d043c064469976304d4b3694b
Content-Type: text/plain; charset=UTF-8

Dose your Dom0 has very limited RAM?

Just happened to fix a bug related to OOM not getting handled correctly.

http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html


Wei.


On Fri, Feb 1, 2013 at 9:58 PM, Christopher S. Aker <caker@theshore.net>wrote:

> We've been hitting the following issue on a variety of hosts and recent
> Xen/dom0 version combinations.  Here's an excerpt from our latest:
>
> Xen: 4.1.4 (xenbits @ 23432)
> Dom0: 3.7.1-x86_64
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip
> ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb
> CPU 0
> Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro
> X9DRi-LN4+/X9DR3-LN4+/X9DRi-**LN4+/X9DR3-LN4+
> RIP: e030:[<ffffffff8141a301>]  [<ffffffff8141a301>]
> evtchn_from_irq+0x11/0x40
> RSP: e02b:ffff88004334fc98  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c
> RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000
> R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720
> R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84
> FS:  00007f8939347700(0000) GS:ffff880101e00000(0000)
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task
> ffff880043fd5fe0)
> Stack:
>  ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200
>  ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040
>  ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0
> Call Trace:
>  [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40
>  [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/**0x800
>  [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60
>  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>  [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/**0xa10
>  [<ffffffff81071926>] kthread+0xc6/0xd0
>  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/**0x20
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
>  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
> Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 00
> 00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff <0f> b7 40 1c
> c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00
> RIP  [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40
>  RSP <ffff88004334fc98>
> CR2: 000000000000001c
> ---[ end trace 1b5f6b359343fcfe ]---
>
>
> Which leads to xenwatch being stuck in D state, which then requires us to
> reboot the host.
>
> SysRq : Show Blocked State
>   task                        PC stack   pid father
> xenwatch        D ffff880101f938c0  5056    49      2 0x00000000
>  ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0
>  ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0
>  ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760
> Call Trace:
>  [<ffffffff8175f444>] schedule+0x24/0x70
>  [<ffffffff8154698d>] xenvif_disconnect+0x7d/0x130
>  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>  [<ffffffff81545ac4>] frontend_changed+0x214/0x660
>  [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0
>  [<ffffffff8141fb22>] xenbus_otherend_changed+0xb2/**0xc0
>  [<ffffffff8175fe39>] ? _raw_spin_unlock_irqrestore+**0x19/0x20
>  [<ffffffff8141fd3b>] frontend_changed+0xb/0x10
>  [<ffffffff8141da3a>] xenwatch_thread+0xba/0x180
>  [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40
>  [<ffffffff8141d980>] ? xs_watch+0x60/0x60
>  [<ffffffff81071926>] kthread+0xc6/0xd0
>  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/**0x20
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
>  [<ffffffff81767c7c>] ret_from_fork+0x7c/0xb0
>  [<ffffffff81071860>] ? kthread_freezable_should_stop+**0x70/0x70
>
> I'll give building an updated dom0 kernel a shot, but was hoping this rang
> a bell or two.
>
> Thanks,
> -Chris
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

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

<div dir=3D"ltr">Dose your Dom0 has very limited RAM?<div><br></div><div>Ju=
st happened to fix a bug related to OOM not getting handled correctly.</div=
><div><br></div><div><a href=3D"http://lists.xen.org/archives/html/xen-deve=
l/2013-01/msg02549.html" target=3D"_blank">http://lists.xen.org/archives/ht=
ml/xen-devel/2013-01/msg02549.html</a></div>


<div><br></div><div><br></div><div>Wei.<br><div class=3D"gmail_extra"><br><=
br><div class=3D"gmail_quote">On Fri, Feb 1, 2013 at 9:58 PM, Christopher S=
. Aker <span dir=3D"ltr">&lt;<a href=3D"mailto:caker@theshore.net" target=
=3D"_blank">caker@theshore.net</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">We&#39;ve been hitting the following issue on a variety of=
 hosts and recent Xen/dom0 version combinations. =C2=A0Here&#39;s an excerp=
t from our latest:<br>



<br>
Xen: 4.1.4 (xenbits @ 23432)<br>
Dom0: 3.7.1-x86_64<br>
<br>
BUG: unable to handle kernel NULL pointer dereference at 000000000000001c<b=
r>
IP: [&lt;ffffffff8141a301&gt;] evtchn_from_irq+0x11/0x40<br>
PGD 0<br>
Oops: 0000 [#1] SMP<br>
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_=
set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter igb<br>
CPU 0<br>
Pid: 1636, comm: netback/0 Not tainted 3.7.1-x86_64 #1 Supermicro X9DRi-LN4=
+/X9DR3-LN4+/X9DRi-<u></u>LN4+/X9DR3-LN4+<br>
RIP: e030:[&lt;ffffffff8141a301&gt;] =C2=A0[&lt;ffffffff8141a301&gt;] evtch=
n_from_irq+0x11/0x40<br>
RSP: e02b:ffff88004334fc98 =C2=A0EFLAGS: 00010246<br>
RAX: 0000000000000000 RBX: ffff880004964700 RCX: 0000000000000000<br>
RDX: 0000000000000000 RSI: 00000000000001dc RDI: 000000000000001c<br>
RBP: ffff88004334fc98 R08: ffffea00010bf818 R09: 0000000000000000<br>
R10: 0000000000000001 R11: ffff880000000000 R12: ffff880004964720<br>
R13: ffff88002d34d700 R14: 00000000ffffffff R15: ffff88004334fd84<br>
FS: =C2=A000007f8939347700(0000) GS:ffff880101e00000(0000) knlGS:0000000000=
000000<br>
CS: =C2=A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b<br>
CR2: 000000000000001c CR3: 0000000001c0b000 CR4: 0000000000002660<br>
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br>
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br>
Process netback/0 (pid: 1636, threadinfo ffff88004334e000, task ffff880043f=
d5fe0)<br>
Stack:<br>
=C2=A0ffff88004334fcb8 ffffffff8141b06d ffff880000000218 ffff880042fe1200<b=
r>
=C2=A0ffff88004334fdb8 ffffffff81543b9b ffff88004334fd84 ffff880042c59040<b=
r>
=C2=A0ffff88004334fd68 ffff88004334fd48 ffff880000000cc0 ffffc900106c7ac0<b=
r>
Call Trace:<br>
=C2=A0[&lt;ffffffff8141b06d&gt;] notify_remote_via_irq+0xd/0x40<br>
=C2=A0[&lt;ffffffff81543b9b&gt;] xen_netbk_rx_action+0x73b/<u></u>0x800<br>
=C2=A0[&lt;ffffffff81544c25&gt;] xen_netbk_kthread+0xb5/0xa60<br>
=C2=A0[&lt;ffffffff81080050&gt;] ? finish_task_switch+0x60/0xd0<br>
=C2=A0[&lt;ffffffff81071fe0&gt;] ? wake_up_bit+0x40/0x40<br>
=C2=A0[&lt;ffffffff81544b70&gt;] ? xen_netbk_tx_build_gops+0xa10/<u></u>0xa=
10<br>
=C2=A0[&lt;ffffffff81071926&gt;] kthread+0xc6/0xd0<br>
=C2=A0[&lt;ffffffff810037b9&gt;] ? xen_end_context_switch+0x19/<u></u>0x20<=
br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
=C2=A0[&lt;ffffffff81767c7c&gt;] ret_from_fork+0x7c/0xb0<br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
Code: be f5 01 00 00 48 c7 c7 12 e2 99 81 e8 d9 4c c3 ff eb cd 0f 1f 80 00 =
00 00 00 55 48 89 e5 39 3d c6 fd 80 00 76 0b e8 df fa ff ff &lt;0f&gt; b7 4=
0 1c c9 c3 89 f9 31 c0 48 c7 c2 27 e2 99 81 be db 00 00<br>
RIP =C2=A0[&lt;ffffffff8141a301&gt;] evtchn_from_irq+0x11/0x40<br>
=C2=A0RSP &lt;ffff88004334fc98&gt;<br>
CR2: 000000000000001c<br>
---[ end trace 1b5f6b359343fcfe ]---<br>
<br>
<br>
Which leads to xenwatch being stuck in D state, which then requires us to r=
eboot the host.<br>
<br>
SysRq : Show Blocked State<br>
=C2=A0 task =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0PC stack =C2=A0 pid father<br>
xenwatch =C2=A0 =C2=A0 =C2=A0 =C2=A0D ffff880101f938c0 =C2=A05056 =C2=A0 =
=C2=A049 =C2=A0 =C2=A0 =C2=A02 0x00000000<br>
=C2=A0ffff880101305cb8 0000000000000246 ffff8801012a0760 00000000000138c0<b=
r>
=C2=A0ffff880101305fd8 ffff880101304010 00000000000138c0 00000000000138c0<b=
r>
=C2=A0ffff880101305fd8 00000000000138c0 ffff8800349224e0 ffff8801012a0760<b=
r>
Call Trace:<br>
=C2=A0[&lt;ffffffff8175f444&gt;] schedule+0x24/0x70<br>
=C2=A0[&lt;ffffffff8154698d&gt;] xenvif_disconnect+0x7d/0x130<br>
=C2=A0[&lt;ffffffff81071fe0&gt;] ? wake_up_bit+0x40/0x40<br>
=C2=A0[&lt;ffffffff81545ac4&gt;] frontend_changed+0x214/0x660<br>
=C2=A0[&lt;ffffffff81080050&gt;] ? finish_task_switch+0x60/0xd0<br>
=C2=A0[&lt;ffffffff8141fb22&gt;] xenbus_otherend_changed+0xb2/<u></u>0xc0<b=
r>
=C2=A0[&lt;ffffffff8175fe39&gt;] ? _raw_spin_unlock_irqrestore+<u></u>0x19/=
0x20<br>
=C2=A0[&lt;ffffffff8141fd3b&gt;] frontend_changed+0xb/0x10<br>
=C2=A0[&lt;ffffffff8141da3a&gt;] xenwatch_thread+0xba/0x180<br>
=C2=A0[&lt;ffffffff81071fe0&gt;] ? wake_up_bit+0x40/0x40<br>
=C2=A0[&lt;ffffffff8141d980&gt;] ? xs_watch+0x60/0x60<br>
=C2=A0[&lt;ffffffff81071926&gt;] kthread+0xc6/0xd0<br>
=C2=A0[&lt;ffffffff810037b9&gt;] ? xen_end_context_switch+0x19/<u></u>0x20<=
br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
=C2=A0[&lt;ffffffff81767c7c&gt;] ret_from_fork+0x7c/0xb0<br>
=C2=A0[&lt;ffffffff81071860&gt;] ? kthread_freezable_should_stop+<u></u>0x7=
0/0x70<br>
<br>
I&#39;ll give building an updated dom0 kernel a shot, but was hoping this r=
ang a bell or two.<br>
<br>
Thanks,<br>
-Chris<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.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>
</blockquote></div><br></div></div></div>

--f46d043c064469976304d4b3694b--


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

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

--===============3213613126076694081==--


From xen-devel-bounces@lists.xen.org Sat Feb 02 01:41:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 01: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 1U1S6Z-0003g0-JD; Sat, 02 Feb 2013 01:41: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 1U1S6Y-0003ft-K4
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 01:41:18 +0000
Received: from [85.158.138.51:18093] by server-10.bemta-3.messagelabs.com id
	82/CB-10609-9BE6C015; Sat, 02 Feb 2013 01:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359769272!28872106!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMzk3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2279 invoked from network); 2 Feb 2013 01:41:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 01:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,588,1355097600"; 
   d="scan'208";a="1088616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 01:41: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.297.1; Sat, 2 Feb 2013 01:41:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1S6R-0007QF-K4;
	Sat, 02 Feb 2013 01:41:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1S6R-0004IC-5C;
	Sat, 02 Feb 2013 01:41:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15405-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Feb 2013 01:41:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15405: 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 15405 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15405/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 01:41:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 01: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 1U1S6Z-0003g0-JD; Sat, 02 Feb 2013 01:41: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 1U1S6Y-0003ft-K4
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 01:41:18 +0000
Received: from [85.158.138.51:18093] by server-10.bemta-3.messagelabs.com id
	82/CB-10609-9BE6C015; Sat, 02 Feb 2013 01:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359769272!28872106!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwMzk3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2279 invoked from network); 2 Feb 2013 01:41:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 01:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,588,1355097600"; 
   d="scan'208";a="1088616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 01:41: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.297.1; Sat, 2 Feb 2013 01:41:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1S6R-0007QF-K4;
	Sat, 02 Feb 2013 01:41:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1S6R-0004IC-5C;
	Sat, 02 Feb 2013 01:41:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15405-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Feb 2013 01:41:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15405: 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 15405 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15405/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 08:49:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 08: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 1U1YmP-0006vF-SE; Sat, 02 Feb 2013 08:48:57 +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 1U1YmO-0006vA-Bg
	for xen-devel@lists.xen.org; Sat, 02 Feb 2013 08:48:56 +0000
Received: from [85.158.137.99:25861] by server-11.bemta-3.messagelabs.com id
	44/49-10249-7F2DC015; Sat, 02 Feb 2013 08:48:55 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1359794933!18592305!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24780 invoked from network); 2 Feb 2013 08:48:54 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-14.tower-217.messagelabs.com with SMTP;
	2 Feb 2013 08:48:54 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r128mpUW021274;
	Sat, 2 Feb 2013 02:48:51 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id r128mpBb021273;
	Sat, 2 Feb 2013 02:48:51 -0600
Date: Sat, 2 Feb 2013 02:48:51 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201302020848.r128mpBb021273@wind.enjellic.com>
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-devel@lists.xen.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sat, 02 Feb 2013 02:48:51 -0600 (CST)
Subject: [Xen-devel] Migration issues with 4.1.
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

Good morning, hope everyone's day is going well.

We have sorted out most of the issues with a new iSCSI hotplug script
which allows Xen guests to be treated as first class SAN guests.  The
script allows each virtual machine to be treated as an independent
initiator (IQN) which enables guests to be managed through LUN masking
initiator groups on popular target platforms such as SCST.

When we began testing live migration on Xen 4.2.1 we noted problems
with PVOPS kernels not starting on the migration target.  The
following is output when a migration is attempted:

---------------------------------------------------------------------------
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/8146)
Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/8146) Savefile contains xl domain config
xc: Saving memory: iter 0 (last sent 0 skipped 0): 65536/65536  100%
xc: Saving memory: iter 1 (last sent 65457 skipped 79): 65536/65536  100%
xc: Saving memory: iter 2 (last sent 86 skipped 0): 65536/65536  100%
xc: Saving memory: iter 3 (last sent 16 skipped 0): 65536/65536  100%
migration receiver stream contained unexpected data instead of ready message
(command run was: exec ./xen-migrate rainbow xl migrate-receive )
migration target: Transfer complete, requesting permission to start domain.
libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading GO message from migration stream
migration target: Failure, destroying our copy.
migration child [8355] not exiting, no longer waiting (exit status will be unreported)
Migration failed, resuming at sender.
---------------------------------------------------------------------------

The xen-migrate script we are using is as follows:

---------------------------------------------------------------------------
#! /bin/bash
exec ssh $1 /usr/sbin/xl migrate-receive;
---------------------------------------------------------------------------

We have verified the problem persists up to and including Linux 3.7.5
but it seems like a toolstack problem rather then anything to do with
the kernel.

The output above indicates the guest is resumed on the sender but the
guest is dead with a kernel panic after the migration attempt.  I
don't have the kernel panic handy but can post it if that would be
helpful, but this issue is really secondary to the migration failure.

An 'xl save' followed by transfer of the image to the target and
re-starting the image with 'xl restore' works perfectly.

I found a reference to a similar problem, including the guest panic,
with 4.0.x but never stumbled on the resolution of the problem.

We will be making the iSCSI script available but since live migration
is the obvious application we want to sort this issue first to verify
we are offering something useful to the community.

Will look forward to any comment/suggestions.

Have a good weekend.

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
------------------------------------------------------------------------------
"There are two things that are infinite; Human stupidity and the
 universe.  And I'm not sure about the universe."
                                -- Albert Einstein

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 08:49:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 08: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 1U1YmP-0006vF-SE; Sat, 02 Feb 2013 08:48:57 +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 1U1YmO-0006vA-Bg
	for xen-devel@lists.xen.org; Sat, 02 Feb 2013 08:48:56 +0000
Received: from [85.158.137.99:25861] by server-11.bemta-3.messagelabs.com id
	44/49-10249-7F2DC015; Sat, 02 Feb 2013 08:48:55 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1359794933!18592305!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24780 invoked from network); 2 Feb 2013 08:48:54 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-14.tower-217.messagelabs.com with SMTP;
	2 Feb 2013 08:48:54 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r128mpUW021274;
	Sat, 2 Feb 2013 02:48:51 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id r128mpBb021273;
	Sat, 2 Feb 2013 02:48:51 -0600
Date: Sat, 2 Feb 2013 02:48:51 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201302020848.r128mpBb021273@wind.enjellic.com>
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-devel@lists.xen.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sat, 02 Feb 2013 02:48:51 -0600 (CST)
Subject: [Xen-devel] Migration issues with 4.1.
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

Good morning, hope everyone's day is going well.

We have sorted out most of the issues with a new iSCSI hotplug script
which allows Xen guests to be treated as first class SAN guests.  The
script allows each virtual machine to be treated as an independent
initiator (IQN) which enables guests to be managed through LUN masking
initiator groups on popular target platforms such as SCST.

When we began testing live migration on Xen 4.2.1 we noted problems
with PVOPS kernels not starting on the migration target.  The
following is output when a migration is attempted:

---------------------------------------------------------------------------
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/8146)
Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/8146) Savefile contains xl domain config
xc: Saving memory: iter 0 (last sent 0 skipped 0): 65536/65536  100%
xc: Saving memory: iter 1 (last sent 65457 skipped 79): 65536/65536  100%
xc: Saving memory: iter 2 (last sent 86 skipped 0): 65536/65536  100%
xc: Saving memory: iter 3 (last sent 16 skipped 0): 65536/65536  100%
migration receiver stream contained unexpected data instead of ready message
(command run was: exec ./xen-migrate rainbow xl migrate-receive )
migration target: Transfer complete, requesting permission to start domain.
libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading GO message from migration stream
migration target: Failure, destroying our copy.
migration child [8355] not exiting, no longer waiting (exit status will be unreported)
Migration failed, resuming at sender.
---------------------------------------------------------------------------

The xen-migrate script we are using is as follows:

---------------------------------------------------------------------------
#! /bin/bash
exec ssh $1 /usr/sbin/xl migrate-receive;
---------------------------------------------------------------------------

We have verified the problem persists up to and including Linux 3.7.5
but it seems like a toolstack problem rather then anything to do with
the kernel.

The output above indicates the guest is resumed on the sender but the
guest is dead with a kernel panic after the migration attempt.  I
don't have the kernel panic handy but can post it if that would be
helpful, but this issue is really secondary to the migration failure.

An 'xl save' followed by transfer of the image to the target and
re-starting the image with 'xl restore' works perfectly.

I found a reference to a similar problem, including the guest panic,
with 4.0.x but never stumbled on the resolution of the problem.

We will be making the iSCSI script available but since live migration
is the obvious application we want to sort this issue first to verify
we are offering something useful to the community.

Will look forward to any comment/suggestions.

Have a good weekend.

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
------------------------------------------------------------------------------
"There are two things that are infinite; Human stupidity and the
 universe.  And I'm not sure about the universe."
                                -- Albert Einstein

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 09:07:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 09: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 1U1Z45-0007BR-2n; Sat, 02 Feb 2013 09:07: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 1U1Z43-0007BM-70
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 09:07:11 +0000
Received: from [85.158.138.51:36803] by server-16.bemta-3.messagelabs.com id
	B2/13-02727-E37DC015; Sat, 02 Feb 2013 09:07:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1359796029!20435629!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6035 invoked from network); 2 Feb 2013 09:07:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 09:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,590,1355097600"; 
   d="scan'208";a="1090962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 09:07: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.297.1; Sat, 2 Feb 2013 09:07:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1Z40-0001CU-Sx;
	Sat, 02 Feb 2013 09:07:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1Z40-0005ba-Kb;
	Sat, 02 Feb 2013 09:07:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15406-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Feb 2013 09:07:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15406: 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 15406 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15406/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 09:07:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 09: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 1U1Z45-0007BR-2n; Sat, 02 Feb 2013 09:07: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 1U1Z43-0007BM-70
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 09:07:11 +0000
Received: from [85.158.138.51:36803] by server-16.bemta-3.messagelabs.com id
	B2/13-02727-E37DC015; Sat, 02 Feb 2013 09:07:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1359796029!20435629!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6035 invoked from network); 2 Feb 2013 09:07:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 09:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,590,1355097600"; 
   d="scan'208";a="1090962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 09:07: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.297.1; Sat, 2 Feb 2013 09:07:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1Z40-0001CU-Sx;
	Sat, 02 Feb 2013 09:07:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1Z40-0005ba-Kb;
	Sat, 02 Feb 2013 09:07:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15406-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Feb 2013 09:07:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15406: 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 15406 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15406/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 11:58:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 11:58: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 1U1bjU-0007o8-5r; Sat, 02 Feb 2013 11:58:08 +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 1U1bjS-0007o0-1l
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 11:58:06 +0000
Received: from [85.158.137.99:60712] by server-4.bemta-3.messagelabs.com id
	F4/00-12802-C4FFC015; Sat, 02 Feb 2013 11:58:04 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1359806281!11830282!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18093 invoked from network); 2 Feb 2013 11:58:01 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Feb 2013 11:58:01 -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 BBB1FA3E1C;
	Sat,  2 Feb 2013 12:57:57 +0100 (CET)
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
To: qemu-devel@nongnu.org
Date: Sat,  2 Feb 2013 12:57:23 +0100
Message-Id: <1359806247-27799-6-git-send-email-afaerber@suse.de>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359806247-27799-1-git-send-email-afaerber@suse.de>
References: <1359806247-27799-1-git-send-email-afaerber@suse.de>
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>, Guan Xuetao <gxt@mprc.pku.edu.cn>,
	"open list:Overall" <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Alexander Graf <agraf@suse.de>,
	Fabien Chouteau <chouteau@adacore.com>, Blue Swirl <blauwirbel@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>, Michael Walle <michael@walle.cc>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	"open list:e500" <qemu-ppc@nongnu.org>, Paul Brook <paul@codesourcery.com>,
	Scott Wood <scottwood@freescale.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Richard Henderson <rth@twiddle.net>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
	Aurelien Jarno <aurelien@aurel32.net>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [Xen-devel] [RFC qom-cpu-next 5/9] cpu: Move halted and
	interrupt_request fields to CPUState
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Qm90aCBmaWVsZHMgYXJlIHVzZWQgaW4gVk1TdGF0ZSwgdGh1cyBuZWVkIHRvIGJlIG1vdmVkIHRv
Z2V0aGVyLgpFeHBsaWNpdGx5IHplcm8gdGhlbSBvbiByZXNldCBzaW5jZSB0aGV5IHdlcmUgbG9j
YXRlZCBiZWZvcmUKYnJlYWtwb2ludHMuCgpQYXNzIFBvd2VyUENDUFUgdG8ga3ZtcHBjX2hhbmRs
ZV9oYWx0KCkuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZWFzIEbDpHJiZXIgPGFmYWVyYmVyQHN1c2Uu
ZGU+Ci0tLQogY3B1LWV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMzQgKysrKysr
KysrKysrLS0tLS0tLS0tLS0tCiBjcHVzLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgNCArLS0KIGV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDE2ICsrKysr
KystLS0tLQogZ2Ric3R1Yi5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIGh3
L2xlb24zLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIGh3L29tYXAxLmMg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA3ICsrKy0tCiBody9vcGVucmlzY190aW1lci5j
ICAgICAgICAgICAgICAgIHwgICAgNCArKy0KIGh3L3BwYy5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgIDIyICsrKysrKysrKystLS0tLS0KIGh3L3BwYy9lNTAwLmMgICAgICAgICAgICAg
ICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9wcGNlNTAwX3NwaW4uYyAgICAgICAgICAgICAg
ICAgIHwgICAgMiArLQogaHcvcHhhMnh4X2dwaW8uYyAgICAgICAgICAgICAgICAgICB8ICAgIDMg
KystCiBody9weGEyeHhfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAgMyArKy0KIGh3L3Mz
OTB4L3MzOTAtdmlydGlvLmMgICAgICAgICAgICAgfCAgIDE0ICsrKysrKy0tLS0KIGh3L3NwYXBy
LmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9zcGFwcl9oY2Fs
bC5jICAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogaHcvc3BhcHJfcnRhcy5jICAgICAgICAg
ICAgICAgICAgICB8ICAgIDYgKystLS0KIGh3L3N1bjRtLmMgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgIDIxICsrKysrKysrLS0tLS0tLQogaHcvc3VuNHUuYyAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgMTUgKysrKysrKy0tLS0KIGh3L3hlbl9tYWNoaW5lX3B2LmMgICAgICAgICAgICAg
ICAgfCAgICA2ICsrLS0tCiBody94dGVuc2FfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAg
OCArKystLS0KIGluY2x1ZGUvZXhlYy9jcHUtZGVmcy5oICAgICAgICAgICAgfCAgICAyIC0tCiBp
bmNsdWRlL3FvbS9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArKysKIGt2bS1hbGwuYyAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAyICstCiBxb20vY3B1LmMgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgMiArKwogdGFyZ2V0LWFscGhhL2NwdS5oICAgICAgICAgICAgICAg
ICB8ICAgIDQgKy0tCiB0YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMgICAgICAgICAgIHwgICAgMyAr
Ky0KIHRhcmdldC1hcm0vY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0
LWFybS9oZWxwZXIuYyAgICAgICAgICAgICAgICB8ICAgIDQgKystCiB0YXJnZXQtYXJtL29wX2hl
bHBlci5jICAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1jcmlzL2NwdS5oICAgICAgICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LWNyaXMvaGVscGVyLmMgICAgICAgICAgICAgICB8
ICAgIDkgKysrKy0tLQogdGFyZ2V0LWNyaXMvdHJhbnNsYXRlLmMgICAgICAgICAgICB8ICAgIDMg
KystCiB0YXJnZXQtaTM4Ni9jcHUuYyAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogdGFyZ2V0
LWkzODYvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgMjAgKysrKysrKystLS0tLS0tCiB0YXJn
ZXQtaTM4Ni9oZWxwZXIuYyAgICAgICAgICAgICAgIHwgICAxMiArKysrKy0tLS0KIHRhcmdldC1p
Mzg2L2t2bS5jICAgICAgICAgICAgICAgICAgfCAgIDUwICsrKysrKysrKysrKysrKysrKystLS0t
LS0tLS0tLS0tLS0tLQogdGFyZ2V0LWkzODYvbWlzY19oZWxwZXIuYyAgICAgICAgICB8ICAgMjEg
KysrKysrKysrKy0tLS0tCiB0YXJnZXQtaTM4Ni9zdm1faGVscGVyLmMgICAgICAgICAgIHwgICAg
OSArKysrLS0tCiB0YXJnZXQtbG0zMi9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArLS0K
IHRhcmdldC1sbTMyL29wX2hlbHBlci5jICAgICAgICAgICAgfCAgICA0ICsrLQogdGFyZ2V0LW02
OGsvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtbTY4ay9vcF9oZWxw
ZXIuYyAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1tNjhrL3FyZWdzLmRlZiAgICAgICAg
ICAgICAgfCAgICAxIC0KIHRhcmdldC1tNjhrL3RyYW5zbGF0ZS5jICAgICAgICAgICAgfCAgICA4
ICsrKysrLQogdGFyZ2V0LW1pY3JvYmxhemUvY3B1LmggICAgICAgICAgICB8ICAgIDQgKy0tCiB0
YXJnZXQtbWlwcy9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArLS0KIHRhcmdldC1taXBz
L29wX2hlbHBlci5jICAgICAgICAgICAgfCAgIDEwICsrKysrLS0tCiB0YXJnZXQtbWlwcy90cmFu
c2xhdGUuYyAgICAgICAgICAgIHwgICAgNCArLS0KIHRhcmdldC1vcGVucmlzYy9jcHUuaCAgICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LW9wZW5yaXNjL2ludGVycnVwdF9oZWxwZXIuYyB8
ICAgIDMgKystCiB0YXJnZXQtb3BlbnJpc2Mvc3lzX2hlbHBlci5jICAgICAgIHwgICAgMyArKy0K
IHRhcmdldC1wcGMvY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIHRhcmdldC1w
cGMvZXhjcF9oZWxwZXIuYyAgICAgICAgICAgfCAgIDIyICsrKysrKysrKysrLS0tLS0KIHRhcmdl
dC1wcGMvaGVscGVyX3JlZ3MuaCAgICAgICAgICAgfCAgIDExICsrKysrLS0tCiB0YXJnZXQtcHBj
L2t2bS5jICAgICAgICAgICAgICAgICAgIHwgICAxNiArKysrKysrLS0tLS0KIHRhcmdldC1wcGMv
dHJhbnNsYXRlLmMgICAgICAgICAgICAgfCAgICAzICsrLQogdGFyZ2V0LXMzOTB4L2NwdS5jICAg
ICAgICAgICAgICAgICB8ICAgIDggKysrLS0tCiB0YXJnZXQtczM5MHgvY3B1LmggICAgICAgICAg
ICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQtczM5MHgvaGVscGVyLmMgICAgICAgICAgICAgIHwg
ICAgNyArKystLQogdGFyZ2V0LXNoNC9jcHUuaCAgICAgICAgICAgICAgICAgICB8ICAgIDQgKy0t
CiB0YXJnZXQtc2g0L2hlbHBlci5jICAgICAgICAgICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQt
c2g0L29wX2hlbHBlci5jICAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1zcGFyYy9jcHUu
aCAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIHRhcmdldC11bmljb3JlMzIvY3B1LmggICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11LmMgICAgICAgICB8
ICAgIDMgKystCiB0YXJnZXQteHRlbnNhL29wX2hlbHBlci5jICAgICAgICAgIHwgICAgNSArKyst
CiB0cmFuc2xhdGUtYWxsLmMgICAgICAgICAgICAgICAgICAgIHwgICAxMCArKysrLS0tLQogeGVu
LWFsbC5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMTAgKysrKystLS0KIDY4IERhdGVp
ZW4gZ2XDpG5kZXJ0LCAzMTUgWmVpbGVuIGhpbnp1Z2Vmw7xndCgrKSwgMjIyIFplaWxlbiBlbnRm
ZXJudCgtKQoKZGlmZiAtLWdpdCBhL2NwdS1leGVjLmMgYi9jcHUtZXhlYy5jCmluZGV4IDgzZGRl
YTQuLjE5MWExOWIgMTAwNjQ0Ci0tLSBhL2NwdS1leGVjLmMKKysrIGIvY3B1LWV4ZWMuYwpAQCAt
MTkwLDEyICsxOTAsMTIgQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogICAgIHVp
bnQ4X3QgKnRjX3B0cjsKICAgICB0Y2dfdGFyZ2V0X3Vsb25nIG5leHRfdGI7CiAKLSAgICBpZiAo
ZW52LT5oYWx0ZWQpIHsKKyAgICBpZiAoY3B1LT5oYWx0ZWQpIHsKICAgICAgICAgaWYgKCFjcHVf
aGFzX3dvcmsoY3B1KSkgewogICAgICAgICAgICAgcmV0dXJuIEVYQ1BfSEFMVEVEOwogICAgICAg
ICB9CiAKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAwOworICAgICAgICBjcHUtPmhhbHRlZCA9IDA7
CiAgICAgfQogCiAgICAgY3B1X3NpbmdsZV9lbnYgPSBlbnY7CkBAIC0yNjUsMTQgKzI2NSwxNCBA
QCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAKICAgICAgICAgICAgIG5leHRfdGIg
PSAwOyAvKiBmb3JjZSBsb29rdXAgb2YgZmlyc3QgVEIgKi8KICAgICAgICAgICAgIGZvcig7Oykg
ewotICAgICAgICAgICAgICAgIGludGVycnVwdF9yZXF1ZXN0ID0gZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdDsKKyAgICAgICAgICAgICAgICBpbnRlcnJ1cHRfcmVxdWVzdCA9IGNwdS0+aW50ZXJydXB0
X3JlcXVlc3Q7CiAgICAgICAgICAgICAgICAgaWYgKHVubGlrZWx5KGludGVycnVwdF9yZXF1ZXN0
KSkgewogICAgICAgICAgICAgICAgICAgICBpZiAodW5saWtlbHkoZW52LT5zaW5nbGVzdGVwX2Vu
YWJsZWQgJiBTU1RFUF9OT0lSUSkpIHsKICAgICAgICAgICAgICAgICAgICAgICAgIC8qIE1hc2sg
b3V0IGV4dGVybmFsIGludGVycnVwdHMgZm9yIHRoaXMgc3RlcC4gKi8KICAgICAgICAgICAgICAg
ICAgICAgICAgIGludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NTVEVQX01BU0s7
CiAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVw
dF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9ERUJVRykgewotICAgICAgICAgICAgICAgICAgICAg
ICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9ERUJVRzsKKyAgICAg
ICAgICAgICAgICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJV
UFRfREVCVUc7CiAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9
IEVYQ1BfREVCVUc7CiAgICAgICAgICAgICAgICAgICAgICAgICBjcHVfbG9vcF9leGl0KGVudik7
CiAgICAgICAgICAgICAgICAgICAgIH0KQEAgLTI4MCw4ICsyODAsOCBAQCBpbnQgY3B1X2V4ZWMo
Q1BVQXJjaFN0YXRlICplbnYpCiAgICAgZGVmaW5lZChUQVJHRVRfUFBDKSB8fCBkZWZpbmVkKFRB
UkdFVF9BTFBIQSkgfHwgZGVmaW5lZChUQVJHRVRfQ1JJUykgfHwgXAogICAgIGRlZmluZWQoVEFS
R0VUX01JQ1JPQkxBWkUpIHx8IGRlZmluZWQoVEFSR0VUX0xNMzIpIHx8IGRlZmluZWQoVEFSR0VU
X1VOSUNPUkUzMikKICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYg
Q1BVX0lOVEVSUlVQVF9IQUxUKSB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVy
cnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBTFQ7Ci0gICAgICAgICAgICAgICAgICAg
ICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVy
cnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBTFQ7CisgICAgICAgICAgICAgICAgICAg
ICAgICBjcHUtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmV4Y2Vw
dGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgICAgICAgICAgICAgICAgICAgICAgY3B1X2xvb3Bf
ZXhpdChlbnYpOwogICAgICAgICAgICAgICAgICAgICB9CkBAIC0yODksNyArMjg5LDcgQEAgaW50
IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogI2lmIGRlZmluZWQoVEFSR0VUX0kzODYpCiAj
aWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkKICAgICAgICAgICAgICAgICAgICAgaWYgKGlu
dGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9QT0xMKSB7Ci0gICAgICAgICAgICAgICAg
ICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7Cisg
ICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5U
RVJSVVBUX1BPTEw7CiAgICAgICAgICAgICAgICAgICAgICAgICBhcGljX3BvbGxfaXJxKGVudi0+
YXBpY19zdGF0ZSk7CiAgICAgICAgICAgICAgICAgICAgIH0KICNlbmRpZgpAQCAtMzA2LDE3ICsz
MDYsMTcgQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICEoZW52LT5oZmxhZ3MgJiBIRl9TTU1fTUFTSykpIHsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBjcHVfc3ZtX2NoZWNrX2ludGVyY2VwdF9wYXJhbShlbnYsIFNWTV9F
WElUX1NNSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwKTsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NNSTsKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NNSTsKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBkb19zbW1fZW50ZXIoZW52KTsKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBuZXh0X3RiID0gMDsKICAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxz
ZSBpZiAoKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9OTUkpICYmCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICEoZW52LT5oZmxhZ3MyICYgSEYyX05NSV9NQVNL
KSkgewotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3Qg
Jj0gfkNQVV9JTlRFUlJVUFRfTk1JOworICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+
aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfTk1JOwogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGVudi0+aGZsYWdzMiB8PSBIRjJfTk1JX01BU0s7CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZG9faW50ZXJydXB0X3g4Nl9oYXJkaXJxKGVudiwgRVhDUDAyX05NSSwg
MSk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAg
ICAgICAgICAgICAgICB9IGVsc2UgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQ
VF9NQ0UpIHsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
cHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBkb19pbnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBFWENQMTJfTUNI
SywgMCk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAg
ICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKChpbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRF
UlJVUFRfSEFSRCkgJiYKQEAgLTMyOCw3ICszMjgsOCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0
YXRlICplbnYpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IGludG5vOwogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNwdV9zdm1fY2hlY2tfaW50ZXJjZXB0X3BhcmFtKGVudiwg
U1ZNX0VYSVRfSU5UUiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAwKTsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmlu
dGVycnVwdF9yZXF1ZXN0ICY9IH4oQ1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9W
SVJRKTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0
ICY9IH4oQ1BVX0lOVEVSUlVQVF9IQVJEIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9WSVJRKTsKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBpbnRubyA9IGNwdV9nZXRfcGljX2ludGVycnVwdChlbnYpOwog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHFlbXVfbG9nX21hc2soQ1BVX0xPR19UQl9JTl9B
U00sICJTZXJ2aWNpbmcgaGFyZHdhcmUgSU5UPTB4JTAyeFxuIiwgaW50bm8pOwogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGRvX2ludGVycnVwdF94ODZfaGFyZGlycShlbnYsIGludG5vLCAx
KTsKQEAgLTM0Niw3ICszNDcsNyBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50bm8gPSBsZGxfcGh5cyhlbnYtPnZtX3ZtY2Ig
KyBvZmZzZXRvZihzdHJ1Y3Qgdm1jYiwgY29udHJvbC5pbnRfdmVjdG9yKSk7CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcWVtdV9sb2dfbWFzayhDUFVfTE9HX1RCX0lOX0FTTSwgIlNlcnZp
Y2luZyB2aXJ0dWFsIGhhcmR3YXJlIElOVD0weCUwMnhcbiIsIGludG5vKTsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBkb19pbnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBpbnRubywgMSk7
Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+
Q1BVX0lOVEVSUlVQVF9WSVJROworICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+aW50
ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfVklSUTsKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBuZXh0X3RiID0gMDsKICNlbmRpZgogICAgICAgICAgICAgICAgICAgICAgICAg
fQpAQCAtMzU3LDggKzM1OCw5IEBAIGludCBjcHVfZXhlYyhDUFVBcmNoU3RhdGUgKmVudikKICAg
ICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICBpZiAoaW50ZXJydXB0X3Jl
cXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKICAgICAgICAgICAgICAgICAgICAgICAgIHBw
Y19od19pbnRlcnJ1cHQoZW52KTsKLSAgICAgICAgICAgICAgICAgICAgICAgIGlmIChlbnYtPnBl
bmRpbmdfaW50ZXJydXB0cyA9PSAwKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+
aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICAgICAgICAgICAg
ICAgICAgICAgIGlmIChlbnYtPnBlbmRpbmdfaW50ZXJydXB0cyA9PSAwKSB7CisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQ
VF9IQVJEOworICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAg
ICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAgICAgICAgICAgIH0KICNlbGlmIGRlZmluZWQoVEFS
R0VUX0xNMzIpCkBAIC01MzUsOCArNTM3LDggQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAq
ZW52KQogI2VuZGlmCiAgICAgICAgICAgICAgICAgICAgLyogRG9uJ3QgdXNlIHRoZSBjYWNoZWQg
aW50ZXJydXB0X3JlcXVlc3QgdmFsdWUsCiAgICAgICAgICAgICAgICAgICAgICAgZG9faW50ZXJy
dXB0IG1heSBoYXZlIHVwZGF0ZWQgdGhlIEVYSVRUQiBmbGFnLiAqLwotICAgICAgICAgICAgICAg
ICAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfRVhJVFRCKSB7
Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVf
SU5URVJSVVBUX0VYSVRUQjsKKyAgICAgICAgICAgICAgICAgICAgaWYgKGNwdS0+aW50ZXJydXB0
X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0VYSVRUQikgeworICAgICAgICAgICAgICAgICAgICAg
ICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAg
ICAgICAgICAgICAgICAgICAgICAvKiBlbnN1cmUgdGhhdCBubyBUQiBqdW1wIHdpbGwgYmUgbW9k
aWZpZWQgYXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBwcm9ncmFtIGZsb3cgd2Fz
IGNoYW5nZWQgKi8KICAgICAgICAgICAgICAgICAgICAgICAgIG5leHRfdGIgPSAwOwpkaWZmIC0t
Z2l0IGEvY3B1cy5jIGIvY3B1cy5jCmluZGV4IDQxNzc5ZWIuLjhiNWY0MjYgMTAwNjQ0Ci0tLSBh
L2NwdXMuYworKysgYi9jcHVzLmMKQEAgLTcyLDcgKzcyLDcgQEAgc3RhdGljIGJvb2wgY3B1X3Ro
cmVhZF9pc19pZGxlKENQVUFyY2hTdGF0ZSAqZW52KQogICAgIGlmIChjcHUtPnN0b3BwZWQgfHwg
IXJ1bnN0YXRlX2lzX3J1bm5pbmcoKSkgewogICAgICAgICByZXR1cm4gdHJ1ZTsKICAgICB9Ci0g
ICAgaWYgKCFlbnYtPmhhbHRlZCB8fCBxZW11X2NwdV9oYXNfd29yayhjcHUpIHx8CisgICAgaWYg
KCFjcHUtPmhhbHRlZCB8fCBxZW11X2NwdV9oYXNfd29yayhjcHUpIHx8CiAgICAgICAgIGt2bV9h
c3luY19pbnRlcnJ1cHRzX2VuYWJsZWQoKSkgewogICAgICAgICByZXR1cm4gZmFsc2U7CiAgICAg
fQpAQCAtMTIxOSw3ICsxMjE5LDcgQEAgQ3B1SW5mb0xpc3QgKnFtcF9xdWVyeV9jcHVzKEVycm9y
ICoqZXJycCkKICAgICAgICAgaW5mby0+dmFsdWUgPSBnX21hbGxvYzAoc2l6ZW9mKCppbmZvLT52
YWx1ZSkpOwogICAgICAgICBpbmZvLT52YWx1ZS0+Q1BVID0gY3B1LT5jcHVfaW5kZXg7CiAgICAg
ICAgIGluZm8tPnZhbHVlLT5jdXJyZW50ID0gKGVudiA9PSBmaXJzdF9jcHUpOwotICAgICAgICBp
bmZvLT52YWx1ZS0+aGFsdGVkID0gZW52LT5oYWx0ZWQ7CisgICAgICAgIGluZm8tPnZhbHVlLT5o
YWx0ZWQgPSBjcHUtPmhhbHRlZDsKICAgICAgICAgaW5mby0+dmFsdWUtPnRocmVhZF9pZCA9IGNw
dS0+dGhyZWFkX2lkOwogI2lmIGRlZmluZWQoVEFSR0VUX0kzODYpCiAgICAgICAgIGluZm8tPnZh
bHVlLT5oYXNfcGMgPSB0cnVlOwpkaWZmIC0tZ2l0IGEvZXhlYy5jIGIvZXhlYy5jCmluZGV4IGE0
MWJjYjguLjVhYjdhZjQgMTAwNjQ0Ci0tLSBhL2V4ZWMuYworKysgYi9leGVjLmMKQEAgLTIyMywx
MiArMjIzLDEyIEBAIHZvaWQgY3B1X2V4ZWNfaW5pdF9hbGwodm9pZCkKIAogc3RhdGljIGludCBj
cHVfY29tbW9uX3Bvc3RfbG9hZCh2b2lkICpvcGFxdWUsIGludCB2ZXJzaW9uX2lkKQogewotICAg
IENQVUFyY2hTdGF0ZSAqZW52ID0gb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBvcGFxdWU7
CiAKICAgICAvKiAweDAxIHdhcyBDUFVfSU5URVJSVVBUX0VYSVQuIFRoaXMgbGluZSBjYW4gYmUg
cmVtb3ZlZCB3aGVuIHRoZQogICAgICAgIHZlcnNpb25faWQgaXMgaW5jcmVhc2VkLiAqLwotICAg
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfjB4MDE7Ci0gICAgdGxiX2ZsdXNoKGVudiwgMSk7
CisgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+MHgwMTsKKyAgICB0bGJfZmx1c2goY3B1
LT5lbnZfcHRyLCAxKTsKIAogICAgIHJldHVybiAwOwogfQpAQCAtMjQwLDggKzI0MCw4IEBAIHN0
YXRpYyBjb25zdCBWTVN0YXRlRGVzY3JpcHRpb24gdm1zdGF0ZV9jcHVfY29tbW9uID0gewogICAg
IC5taW5pbXVtX3ZlcnNpb25faWRfb2xkID0gMSwKICAgICAucG9zdF9sb2FkID0gY3B1X2NvbW1v
bl9wb3N0X2xvYWQsCiAgICAgLmZpZWxkcyAgICAgID0gKFZNU3RhdGVGaWVsZCBbXSkgewotICAg
ICAgICBWTVNUQVRFX1VJTlQzMihoYWx0ZWQsIENQVUFyY2hTdGF0ZSksCi0gICAgICAgIFZNU1RB
VEVfVUlOVDMyKGludGVycnVwdF9yZXF1ZXN0LCBDUFVBcmNoU3RhdGUpLAorICAgICAgICBWTVNU
QVRFX1VJTlQzMihoYWx0ZWQsIENQVVN0YXRlKSwKKyAgICAgICAgVk1TVEFURV9VSU5UMzIoaW50
ZXJydXB0X3JlcXVlc3QsIENQVVN0YXRlKSwKICAgICAgICAgVk1TVEFURV9FTkRfT0ZfTElTVCgp
CiAgICAgfQogfTsKQEAgLTI5MSw3ICsyOTEsNyBAQCB2b2lkIGNwdV9leGVjX2luaXQoQ1BVQXJj
aFN0YXRlICplbnYpCiAgICAgY3B1X2xpc3RfdW5sb2NrKCk7CiAjZW5kaWYKICNpZiBkZWZpbmVk
KENQVV9TQVZFX1ZFUlNJT04pICYmICFkZWZpbmVkKENPTkZJR19VU0VSX09OTFkpCi0gICAgdm1z
dGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2NwdV9jb21tb24sIGVudik7
CisgICAgdm1zdGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2NwdV9jb21t
b24sIGNwdSk7CiAgICAgcmVnaXN0ZXJfc2F2ZXZtKE5VTEwsICJjcHUiLCBjcHVfaW5kZXgsIENQ
VV9TQVZFX1ZFUlNJT04sCiAgICAgICAgICAgICAgICAgICAgIGNwdV9zYXZlLCBjcHVfbG9hZCwg
ZW52KTsKICNlbmRpZgpAQCAtNDg3LDcgKzQ4Nyw5IEBAIHZvaWQgY3B1X3NpbmdsZV9zdGVwKENQ
VUFyY2hTdGF0ZSAqZW52LCBpbnQgZW5hYmxlZCkKIAogdm9pZCBjcHVfcmVzZXRfaW50ZXJydXB0
KENQVUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKIHsKLSAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICY9IH5tYXNrOworICAgIENQVVN0YXRlICpjcHUgPSBFTlZfR0VUX0NQVShlbnYpOworCisg
ICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+bWFzazsKIH0KIAogdm9pZCBjcHVfZXhpdChD
UFVBcmNoU3RhdGUgKmVudikKZGlmZiAtLWdpdCBhL2dkYnN0dWIuYyBiL2dkYnN0dWIuYwppbmRl
eCAzMmRmZWE5Li44NDZkZTFjIDEwMDY0NAotLS0gYS9nZGJzdHViLmMKKysrIGIvZ2Ric3R1Yi5j
CkBAIC0yNDA4LDcgKzI0MDgsNyBAQCBzdGF0aWMgaW50IGdkYl9oYW5kbGVfcGFja2V0KEdEQlN0
YXRlICpzLCBjb25zdCBjaGFyICpsaW5lX2J1ZikKICAgICAgICAgICAgICAgICBjcHVfc3luY2hy
b25pemVfc3RhdGUoZW52KTsKICAgICAgICAgICAgICAgICBsZW4gPSBzbnByaW50ZigoY2hhciAq
KW1lbV9idWYsIHNpemVvZihtZW1fYnVmKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAiQ1BVIyVkIFslc10iLCBjcHUtPmNwdV9pbmRleCwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBlbnYtPmhhbHRlZCA/ICJoYWx0ZWQgIiA6ICJydW5uaW5nIik7CisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY3B1LT5oYWx0ZWQgPyAiaGFsdGVkICIgOiAicnVubmluZyIp
OwogICAgICAgICAgICAgICAgIG1lbXRvaGV4KGJ1ZiwgbWVtX2J1ZiwgbGVuKTsKICAgICAgICAg
ICAgICAgICBwdXRfcGFja2V0KHMsIGJ1Zik7CiAgICAgICAgICAgICB9CmRpZmYgLS1naXQgYS9o
dy9sZW9uMy5jIGIvaHcvbGVvbjMuYwppbmRleCBmMTZhOGJiLi5lOTcxZDVjIDEwMDY0NAotLS0g
YS9ody9sZW9uMy5jCisrKyBiL2h3L2xlb24zLmMKQEAgLTQ5LDExICs0OSwxMiBAQCB0eXBlZGVm
IHN0cnVjdCBSZXNldERhdGEgewogc3RhdGljIHZvaWQgbWFpbl9jcHVfcmVzZXQodm9pZCAqb3Bh
cXVlKQogewogICAgIFJlc2V0RGF0YSAqcyAgID0gKFJlc2V0RGF0YSAqKW9wYXF1ZTsKKyAgICBD
UFVTdGF0ZSAqY3B1ID0gQ1BVKHMtPmNwdSk7CiAgICAgQ1BVU1BBUkNTdGF0ZSAgKmVudiA9ICZz
LT5jcHUtPmVudjsKIAotICAgIGNwdV9yZXNldChDUFUocy0+Y3B1KSk7CisgICAgY3B1X3Jlc2V0
KGNwdSk7CiAKLSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgY3B1LT5oYWx0ZWQgPSAwOwogICAg
IGVudi0+cGMgICAgID0gcy0+ZW50cnk7CiAgICAgZW52LT5ucGMgICAgPSBzLT5lbnRyeSArIDQ7
CiB9CmRpZmYgLS1naXQgYS9ody9vbWFwMS5jIGIvaHcvb21hcDEuYwppbmRleCA2MjNiMTAxLi5j
MzZhMzMwIDEwMDY0NAotLS0gYS9ody9vbWFwMS5jCisrKyBiL2h3L29tYXAxLmMKQEAgLTE3MjEs
NiArMTcyMSw3IEBAIHN0YXRpYyB1aW50NjRfdCBvbWFwX2Nsa2RzcF9yZWFkKHZvaWQgKm9wYXF1
ZSwgaHdhZGRyIGFkZHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25l
ZCBzaXplKQogewogICAgIHN0cnVjdCBvbWFwX21wdV9zdGF0ZV9zICpzID0gKHN0cnVjdCBvbWFw
X21wdV9zdGF0ZV9zICopIG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3B1ID0gQ1BVKHMtPmNwdSk7
CiAKICAgICBpZiAoc2l6ZSAhPSAyKSB7CiAgICAgICAgIHJldHVybiBvbWFwX2JhZHdpZHRoX3Jl
YWQxNihvcGFxdWUsIGFkZHIpOwpAQCAtMTczNyw4ICsxNzM4LDkgQEAgc3RhdGljIHVpbnQ2NF90
IG9tYXBfY2xrZHNwX3JlYWQodm9pZCAqb3BhcXVlLCBod2FkZHIgYWRkciwKICAgICAgICAgcmV0
dXJuIHMtPmNsa20uZHNwX3JzdGN0MjsKIAogICAgIGNhc2UgMHgxODoJLyogRFNQX1NZU1NUICov
CisgICAgICAgIGNwdSA9IENQVShzLT5jcHUpOwogICAgICAgICByZXR1cm4gKHMtPmNsa20uY2xv
Y2tpbmdfc2NoZW1lIDw8IDExKSB8IHMtPmNsa20uY29sZF9zdGFydCB8Ci0gICAgICAgICAgICAg
ICAgKHMtPmNwdS0+ZW52LmhhbHRlZCA8PCA2KTsgICAgICAvKiBRdWl0ZSB1c2VsZXNzLi4uICov
CisgICAgICAgICAgICAgICAgKGNwdS0+aGFsdGVkIDw8IDYpOyAgICAgIC8qIFF1aXRlIHVzZWxl
c3MuLi4gKi8KICAgICB9CiAKICAgICBPTUFQX0JBRF9SRUcoYWRkcik7CkBAIC0zNzU0LDggKzM3
NTYsOSBAQCBzdGF0aWMgdm9pZCBvbWFwX3NldHVwX2RzcF9tYXBwaW5nKE1lbW9yeVJlZ2lvbiAq
c3lzdGVtX21lbW9yeSwKIHZvaWQgb21hcF9tcHVfd2FrZXVwKHZvaWQgKm9wYXF1ZSwgaW50IGly
cSwgaW50IHJlcSkKIHsKICAgICBzdHJ1Y3Qgb21hcF9tcHVfc3RhdGVfcyAqbXB1ID0gKHN0cnVj
dCBvbWFwX21wdV9zdGF0ZV9zICopIG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3B1ID0gQ1BVKG1w
dS0+Y3B1KTsKIAotICAgIGlmIChtcHUtPmNwdS0+ZW52LmhhbHRlZCkgeworICAgIGlmIChjcHUt
PmhhbHRlZCkgewogICAgICAgICBjcHVfaW50ZXJydXB0KCZtcHUtPmNwdS0+ZW52LCBDUFVfSU5U
RVJSVVBUX0VYSVRUQik7CiAgICAgfQogfQpkaWZmIC0tZ2l0IGEvaHcvb3BlbnJpc2NfdGltZXIu
YyBiL2h3L29wZW5yaXNjX3RpbWVyLmMKaW5kZXggZDk2NWJlNy4uZjlmMTE2YSAxMDA2NDQKLS0t
IGEvaHcvb3BlbnJpc2NfdGltZXIuYworKysgYi9ody9vcGVucmlzY190aW1lci5jCkBAIC03Myw4
ICs3MywxMCBAQCBzdGF0aWMgdm9pZCBvcGVucmlzY190aW1lcl9jYih2b2lkICpvcGFxdWUpCiAK
ICAgICBpZiAoKGNwdS0+ZW52LnR0bXIgJiBUVE1SX0lFKSAmJgogICAgICAgICAgcWVtdV90aW1l
cl9leHBpcmVkKGNwdS0+ZW52LnRpbWVyLCBxZW11X2dldF9jbG9ja19ucyh2bV9jbG9jaykpKSB7
CisgICAgICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOworCiAgICAgICAgIGNwdS0+ZW52LnR0
bXIgfD0gVFRNUl9JUDsKLSAgICAgICAgY3B1LT5lbnYuaW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BV
X0lOVEVSUlVQVF9USU1FUjsKKyAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9J
TlRFUlJVUFRfVElNRVI7CiAgICAgfQogCiAgICAgc3dpdGNoIChjcHUtPmVudi50dG1yICYgVFRN
Ul9NKSB7CmRpZmYgLS1naXQgYS9ody9wcGMuYyBiL2h3L3BwYy5jCmluZGV4IDg5MzUyYmUuLjQw
MGRhYWIgMTAwNjQ0Ci0tLSBhL2h3L3BwYy5jCisrKyBiL2h3L3BwYy5jCkBAIC03Miw3ICs3Miw3
IEBAIHZvaWQgcHBjX3NldF9pcnEoUG93ZXJQQ0NQVSAqY3B1LCBpbnQgbl9JUlEsIGludCBsZXZl
bCkKIAogICAgIExPR19JUlEoIiVzOiAlcCBuX0lSUSAlZCBsZXZlbCAlZCA9PiBwZW5kaW5nICUw
OCIgUFJJeDMyCiAgICAgICAgICAgICAgICAgInJlcSAlMDh4XG4iLCBfX2Z1bmNfXywgZW52LCBu
X0lSUSwgbGV2ZWwsCi0gICAgICAgICAgICAgICAgZW52LT5wZW5kaW5nX2ludGVycnVwdHMsIGVu
di0+aW50ZXJydXB0X3JlcXVlc3QpOworICAgICAgICAgICAgICAgIGVudi0+cGVuZGluZ19pbnRl
cnJ1cHRzLCBDUFUoY3B1KS0+aW50ZXJydXB0X3JlcXVlc3QpOwogfQogCiAvKiBQb3dlclBDIDZ4
eCAvIDd4eCBpbnRlcm5hbCBJUlEgY29udHJvbGxlciAqLwpAQCAtODcsNiArODcsOCBAQCBzdGF0
aWMgdm9pZCBwcGM2eHhfc2V0X2lycSh2b2lkICpvcGFxdWUsIGludCBwaW4sIGludCBsZXZlbCkK
ICAgICBjdXJfbGV2ZWwgPSAoZW52LT5pcnFfaW5wdXRfc3RhdGUgPj4gcGluKSAmIDE7CiAgICAg
LyogRG9uJ3QgZ2VuZXJhdGUgc3B1cmlvdXMgZXZlbnRzICovCiAgICAgaWYgKChjdXJfbGV2ZWwg
PT0gMSAmJiBsZXZlbCA9PSAwKSB8fCAoY3VyX2xldmVsID09IDAgJiYgbGV2ZWwgIT0gMCkpIHsK
KyAgICAgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CisKICAgICAgICAgc3dpdGNoIChwaW4p
IHsKICAgICAgICAgY2FzZSBQUEM2eHhfSU5QVVRfVEJFTjoKICAgICAgICAgICAgIC8qIExldmVs
IHNlbnNpdGl2ZSAtIGFjdGl2ZSBoaWdoICovCkBAIC0xMjYsNyArMTI4LDcgQEAgc3RhdGljIHZv
aWQgcHBjNnh4X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwpCiAgICAg
ICAgICAgICAvKiBYWFg6IE5vdGUgdGhhdCB0aGUgb25seSB3YXkgdG8gcmVzdGFydCB0aGUgQ1BV
IGlzIHRvIHJlc2V0IGl0ICovCiAgICAgICAgICAgICBpZiAobGV2ZWwpIHsKICAgICAgICAgICAg
ICAgICBMT0dfSVJRKCIlczogc3RvcCB0aGUgQ1BVXG4iLCBfX2Z1bmNfXyk7Ci0gICAgICAgICAg
ICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwog
ICAgICAgICAgICAgfQogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgUFBDNnh4X0lO
UFVUX0hSRVNFVDoKQEAgLTE3NCw2ICsxNzYsOCBAQCBzdGF0aWMgdm9pZCBwcGM5NzBfc2V0X2ly
cSh2b2lkICpvcGFxdWUsIGludCBwaW4sIGludCBsZXZlbCkKICAgICBjdXJfbGV2ZWwgPSAoZW52
LT5pcnFfaW5wdXRfc3RhdGUgPj4gcGluKSAmIDE7CiAgICAgLyogRG9uJ3QgZ2VuZXJhdGUgc3B1
cmlvdXMgZXZlbnRzICovCiAgICAgaWYgKChjdXJfbGV2ZWwgPT0gMSAmJiBsZXZlbCA9PSAwKSB8
fCAoY3VyX2xldmVsID09IDAgJiYgbGV2ZWwgIT0gMCkpIHsKKyAgICAgICAgQ1BVU3RhdGUgKmNz
ID0gQ1BVKGNwdSk7CisKICAgICAgICAgc3dpdGNoIChwaW4pIHsKICAgICAgICAgY2FzZSBQUEM5
NzBfSU5QVVRfSU5UOgogICAgICAgICAgICAgLyogTGV2ZWwgc2Vuc2l0aXZlIC0gYWN0aXZlIGhp
Z2ggKi8KQEAgLTIwMywxMSArMjA3LDExIEBAIHN0YXRpYyB2b2lkIHBwYzk3MF9zZXRfaXJxKHZv
aWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQogICAgICAgICAgICAgLyogWFhYOiBUT0RP
OiByZWxheSB0aGUgc2lnbmFsIHRvIENLU1RQX09VVCBwaW4gKi8KICAgICAgICAgICAgIGlmIChs
ZXZlbCkgewogICAgICAgICAgICAgICAgIExPR19JUlEoIiVzOiBzdG9wIHRoZSBDUFVcbiIsIF9f
ZnVuY19fKTsKLSAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICAg
ICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgICAg
IExPR19JUlEoIiVzOiByZXN0YXJ0IHRoZSBDUFVcbiIsIF9fZnVuY19fKTsKLSAgICAgICAgICAg
ICAgICBlbnYtPmhhbHRlZCA9IDA7Ci0gICAgICAgICAgICAgICAgcWVtdV9jcHVfa2ljayhDUFUo
Y3B1KSk7CisgICAgICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDA7CisgICAgICAgICAgICAgICAg
cWVtdV9jcHVfa2ljayhjcyk7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBicmVhazsKICAg
ICAgICAgY2FzZSBQUEM5NzBfSU5QVVRfSFJFU0VUOgpAQCAtMjk1LDYgKzI5OSw4IEBAIHN0YXRp
YyB2b2lkIHBwYzQweF9zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQog
ICAgIGN1cl9sZXZlbCA9IChlbnYtPmlycV9pbnB1dF9zdGF0ZSA+PiBwaW4pICYgMTsKICAgICAv
KiBEb24ndCBnZW5lcmF0ZSBzcHVyaW91cyBldmVudHMgKi8KICAgICBpZiAoKGN1cl9sZXZlbCA9
PSAxICYmIGxldmVsID09IDApIHx8IChjdXJfbGV2ZWwgPT0gMCAmJiBsZXZlbCAhPSAwKSkgewor
ICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKKwogICAgICAgICBzd2l0Y2ggKHBpbikg
ewogICAgICAgICBjYXNlIFBQQzQweF9JTlBVVF9SRVNFVF9TWVM6CiAgICAgICAgICAgICBpZiAo
bGV2ZWwpIHsKQEAgLTMzMiwxMSArMzM4LDExIEBAIHN0YXRpYyB2b2lkIHBwYzQweF9zZXRfaXJx
KHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQogICAgICAgICAgICAgLyogTGV2ZWwg
c2Vuc2l0aXZlIC0gYWN0aXZlIGxvdyAqLwogICAgICAgICAgICAgaWYgKGxldmVsKSB7CiAgICAg
ICAgICAgICAgICAgTE9HX0lSUSgiJXM6IHN0b3AgdGhlIENQVVxuIiwgX19mdW5jX18pOwotICAg
ICAgICAgICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgICAgICAgICBjcy0+aGFsdGVk
ID0gMTsKICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgTE9HX0lSUSgiJXM6
IHJlc3RhcnQgdGhlIENQVVxuIiwgX19mdW5jX18pOwotICAgICAgICAgICAgICAgIGVudi0+aGFs
dGVkID0gMDsKLSAgICAgICAgICAgICAgICBxZW11X2NwdV9raWNrKENQVShjcHUpKTsKKyAgICAg
ICAgICAgICAgICBjcy0+aGFsdGVkID0gMDsKKyAgICAgICAgICAgICAgICBxZW11X2NwdV9raWNr
KGNzKTsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjYXNlIFBQ
QzQweF9JTlBVVF9ERUJVRzoKZGlmZiAtLWdpdCBhL2h3L3BwYy9lNTAwLmMgYi9ody9wcGMvZTUw
MC5jCmluZGV4IGI3NDc0YzAuLjI2NWQ3NWMgMTAwNjQ0Ci0tLSBhL2h3L3BwYy9lNTAwLmMKKysr
IGIvaHcvcHBjL2U1MDAuYwpAQCAtNDI1LDI2ICs0MjUsMjggQEAgc3RhdGljIHZvaWQgbW11Ym9v
a2VfY3JlYXRlX2luaXRpYWxfbWFwcGluZyhDUFVQUENTdGF0ZSAqZW52KQogc3RhdGljIHZvaWQg
cHBjZTUwMF9jcHVfcmVzZXRfc2VjKHZvaWQgKm9wYXF1ZSkKIHsKICAgICBQb3dlclBDQ1BVICpj
cHUgPSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVUFBDU3Rh
dGUgKmVudiA9ICZjcHUtPmVudjsKIAotICAgIGNwdV9yZXNldChDUFUoY3B1KSk7CisgICAgY3B1
X3Jlc2V0KGNzKTsKIAogICAgIC8qIFNlY29uZGFyeSBDUFUgc3RhcnRzIGluIGhhbHRlZCBzdGF0
ZSBmb3Igbm93LiBOZWVkcyB0byBjaGFuZ2Ugd2hlbgogICAgICAgIGltcGxlbWVudGluZyBub24t
a2VybmVsIGJvb3QuICovCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNzLT5oYWx0ZWQgPSAx
OwogICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiB9CiAKIHN0YXRpYyB2b2lk
IHBwY2U1MDBfY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAgICBQb3dlclBDQ1BVICpjcHUg
PSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVUFBDU3RhdGUg
KmVudiA9ICZjcHUtPmVudjsKICAgICBzdHJ1Y3QgYm9vdF9pbmZvICpiaSA9IGVudi0+bG9hZF9p
bmZvOwogCi0gICAgY3B1X3Jlc2V0KENQVShjcHUpKTsKKyAgICBjcHVfcmVzZXQoY3MpOwogCiAg
ICAgLyogU2V0IGluaXRpYWwgZ3Vlc3Qgc3RhdGUuICovCi0gICAgZW52LT5oYWx0ZWQgPSAwOwor
ICAgIGNzLT5oYWx0ZWQgPSAwOwogICAgIGVudi0+Z3ByWzFdID0gKDE2PDwyMCkgLSA4OwogICAg
IGVudi0+Z3ByWzNdID0gYmktPmR0X2Jhc2U7CiAgICAgZW52LT5uaXAgPSBiaS0+ZW50cnk7CmRp
ZmYgLS1naXQgYS9ody9wcGNlNTAwX3NwaW4uYyBiL2h3L3BwY2U1MDBfc3Bpbi5jCmluZGV4IDdl
OTBmYjkuLjBkMjBhNDMgMTAwNjQ0Ci0tLSBhL2h3L3BwY2U1MDBfc3Bpbi5jCisrKyBiL2h3L3Bw
Y2U1MDBfc3Bpbi5jCkBAIC0xMTIsNyArMTEyLDcgQEAgc3RhdGljIHZvaWQgc3Bpbl9raWNrKHZv
aWQgKmRhdGEpCiAgICAgbWFwX3N0YXJ0ID0gbGRxX3AoJmN1cnNwaW4tPmFkZHIpICYgfihtYXBf
c2l6ZSAtIDEpOwogICAgIG1tdWJvb2tlX2NyZWF0ZV9pbml0aWFsX21hcHBpbmcoZW52LCAwLCBt
YXBfc3RhcnQsIG1hcF9zaXplKTsKIAotICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICBjcHUtPmhh
bHRlZCA9IDA7CiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSAtMTsKICAgICBjcHUtPnN0b3Bw
ZWQgPSBmYWxzZTsKICAgICBxZW11X2NwdV9raWNrKGNwdSk7CmRpZmYgLS1naXQgYS9ody9weGEy
eHhfZ3Bpby5jIGIvaHcvcHhhMnh4X2dwaW8uYwppbmRleCAwNWQyYWQyLi5mMDBkMTUwIDEwMDY0
NAotLS0gYS9ody9weGEyeHhfZ3Bpby5jCisrKyBiL2h3L3B4YTJ4eF9ncGlvLmMKQEAgLTkzLDYg
KzkzLDcgQEAgc3RhdGljIGNvbnN0IGludCBweGEyeHhfZ3Bpb193YWtlW1BYQTJYWF9HUElPX0JB
TktTXSA9IHsKIHN0YXRpYyB2b2lkIHB4YTJ4eF9ncGlvX3NldCh2b2lkICpvcGFxdWUsIGludCBs
aW5lLCBpbnQgbGV2ZWwpCiB7CiAgICAgUFhBMnh4R1BJT0luZm8gKnMgPSAoUFhBMnh4R1BJT0lu
Zm8gKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBDUFUocy0+Y3B1KTsKICAgICBpbnQg
YmFuazsKICAgICB1aW50MzJfdCBtYXNrOwogCkBAIC0xMTgsNyArMTE5LDcgQEAgc3RhdGljIHZv
aWQgcHhhMnh4X2dwaW9fc2V0KHZvaWQgKm9wYXF1ZSwgaW50IGxpbmUsIGludCBsZXZlbCkKICAg
ICAgICAgcHhhMnh4X2dwaW9faXJxX3VwZGF0ZShzKTsKIAogICAgIC8qIFdha2UtdXAgR1BJT3Mg
Ki8KLSAgICBpZiAocy0+Y3B1LT5lbnYuaGFsdGVkICYmIChtYXNrICYgfnMtPmRpcltiYW5rXSAm
IHB4YTJ4eF9ncGlvX3dha2VbYmFua10pKSB7CisgICAgaWYgKGNwdS0+aGFsdGVkICYmIChtYXNr
ICYgfnMtPmRpcltiYW5rXSAmIHB4YTJ4eF9ncGlvX3dha2VbYmFua10pKSB7CiAgICAgICAgIGNw
dV9pbnRlcnJ1cHQoJnMtPmNwdS0+ZW52LCBDUFVfSU5URVJSVVBUX0VYSVRUQik7CiAgICAgfQog
fQpkaWZmIC0tZ2l0IGEvaHcvcHhhMnh4X3BpYy5jIGIvaHcvcHhhMnh4X3BpYy5jCmluZGV4IDkw
YjhmZWYuLmM3M2U3MDkgMTAwNjQ0Ci0tLSBhL2h3L3B4YTJ4eF9waWMuYworKysgYi9ody9weGEy
eHhfcGljLmMKQEAgLTQ2LDggKzQ2LDkgQEAgc3RhdGljIHZvaWQgcHhhMnh4X3BpY191cGRhdGUo
dm9pZCAqb3BhcXVlKQogewogICAgIHVpbnQzMl90IG1hc2tbMl07CiAgICAgUFhBMnh4UElDU3Rh
dGUgKnMgPSAoUFhBMnh4UElDU3RhdGUgKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBD
UFUocy0+Y3B1KTsKIAotICAgIGlmIChzLT5jcHUtPmVudi5oYWx0ZWQpIHsKKyAgICBpZiAoY3B1
LT5oYWx0ZWQpIHsKICAgICAgICAgbWFza1swXSA9IHMtPmludF9wZW5kaW5nWzBdICYgKHMtPmlu
dF9lbmFibGVkWzBdIHwgcy0+aW50X2lkbGUpOwogICAgICAgICBtYXNrWzFdID0gcy0+aW50X3Bl
bmRpbmdbMV0gJiAocy0+aW50X2VuYWJsZWRbMV0gfCBzLT5pbnRfaWRsZSk7CiAgICAgICAgIGlm
IChtYXNrWzBdIHx8IG1hc2tbMV0pIHsKZGlmZiAtLWdpdCBhL2h3L3MzOTB4L3MzOTAtdmlydGlv
LmMgYi9ody9zMzkweC9zMzkwLXZpcnRpby5jCmluZGV4IGUyNWMzMzAuLmNhMjc1YmQgMTAwNjQ0
Ci0tLSBhL2h3L3MzOTB4L3MzOTAtdmlydGlvLmMKKysrIGIvaHcvczM5MHgvczM5MC12aXJ0aW8u
YwpAQCAtMTMyLDIzICsxMzIsMjUgQEAgc3RhdGljIHVuc2lnbmVkIHMzOTBfcnVubmluZ19jcHVz
OwogCiB2b2lkIHMzOTBfYWRkX3J1bm5pbmdfY3B1KFMzOTBDUFUgKmNwdSkKIHsKKyAgICBDUFVT
dGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVTMzkwWFN0YXRlICplbnYgPSAmY3B1LT5lbnY7
CiAKLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBpZiAoY3MtPmhhbHRlZCkgewogICAgICAg
ICBzMzkwX3J1bm5pbmdfY3B1cysrOwotICAgICAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgICAg
IGNzLT5oYWx0ZWQgPSAwOwogICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IC0xOwogICAg
IH0KIH0KIAogdW5zaWduZWQgczM5MF9kZWxfcnVubmluZ19jcHUoUzM5MENQVSAqY3B1KQogewor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVMzOTBYU3RhdGUgKmVudiA9ICZj
cHUtPmVudjsKIAotICAgIGlmIChlbnYtPmhhbHRlZCA9PSAwKSB7CisgICAgaWYgKGNzLT5oYWx0
ZWQgPT0gMCkgewogICAgICAgICBhc3NlcnQoczM5MF9ydW5uaW5nX2NwdXMgPj0gMSk7CiAgICAg
ICAgIHMzOTBfcnVubmluZ19jcHVzLS07Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAg
ICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9I
TFQ7CiAgICAgfQogICAgIHJldHVybiBzMzkwX3J1bm5pbmdfY3B1czsKQEAgLTE4MywxMSArMTg1
LDEzIEBAIHZvaWQgczM5MF9pbml0X2NwdXMoY29uc3QgY2hhciAqY3B1X21vZGVsLCB1aW50OF90
ICpzdG9yYWdlX2tleXMpCiAKICAgICBmb3IgKGkgPSAwOyBpIDwgc21wX2NwdXM7IGkrKykgewog
ICAgICAgICBTMzkwQ1BVICpjcHU7CisgICAgICAgIENQVVN0YXRlICpjczsKIAogICAgICAgICBj
cHUgPSBjcHVfczM5MHhfaW5pdChjcHVfbW9kZWwpOworICAgICAgICBjcyA9IENQVShjcHUpOwog
CiAgICAgICAgIGlwaV9zdGF0ZXNbaV0gPSBjcHU7Ci0gICAgICAgIGNwdS0+ZW52LmhhbHRlZCA9
IDE7CisgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgICAgICBjcHUtPmVudi5leGNlcHRpb25f
aW5kZXggPSBFWENQX0hMVDsKICAgICAgICAgY3B1LT5lbnYuc3RvcmFnZV9rZXlzID0gc3RvcmFn
ZV9rZXlzOwogICAgIH0KZGlmZiAtLWdpdCBhL2h3L3NwYXByLmMgYi9ody9zcGFwci5jCmluZGV4
IGU4OGEyN2EuLmRhNTE4MWMgMTAwNjQ0Ci0tLSBhL2h3L3NwYXByLmMKKysrIGIvaHcvc3BhcHIu
YwpAQCAtNjE2LDYgKzYxNiw4IEBAIHN0YXRpYyB2b2lkIHNwYXByX3Jlc2V0X2h0YWIoc1BBUFJF
bnZpcm9ubWVudCAqc3BhcHIpCiAKIHN0YXRpYyB2b2lkIHBwY19zcGFwcl9yZXNldCh2b2lkKQog
eworICAgIENQVVN0YXRlICpmaXJzdF9jcHVfY3B1OworCiAgICAgLyogUmVzZXQgdGhlIGhhc2gg
dGFibGUgJiByZWNhbGMgdGhlIFJNQSAqLwogICAgIHNwYXByX3Jlc2V0X2h0YWIoc3BhcHIpOwog
CkBAIC02MjYsOSArNjI4LDEwIEBAIHN0YXRpYyB2b2lkIHBwY19zcGFwcl9yZXNldCh2b2lkKQog
ICAgICAgICAgICAgICAgICAgICAgICBzcGFwci0+cnRhc19zaXplKTsKIAogICAgIC8qIFNldCB1
cCB0aGUgZW50cnkgc3RhdGUgKi8KKyAgICBmaXJzdF9jcHVfY3B1ID0gQ1BVKGZpcnN0X2NwdSk7
CiAgICAgZmlyc3RfY3B1LT5ncHJbM10gPSBzcGFwci0+ZmR0X2FkZHI7CiAgICAgZmlyc3RfY3B1
LT5ncHJbNV0gPSAwOwotICAgIGZpcnN0X2NwdS0+aGFsdGVkID0gMDsKKyAgICBmaXJzdF9jcHVf
Y3B1LT5oYWx0ZWQgPSAwOwogICAgIGZpcnN0X2NwdS0+bmlwID0gc3BhcHItPmVudHJ5X3BvaW50
OwogCiB9CkBAIC02MzYsMTQgKzYzOSwxNSBAQCBzdGF0aWMgdm9pZCBwcGNfc3BhcHJfcmVzZXQo
dm9pZCkKIHN0YXRpYyB2b2lkIHNwYXByX2NwdV9yZXNldCh2b2lkICpvcGFxdWUpCiB7CiAgICAg
UG93ZXJQQ0NQVSAqY3B1ID0gb3BhcXVlOworICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwog
ICAgIENQVVBQQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNw
dSkpOworICAgIGNwdV9yZXNldChjcyk7CiAKICAgICAvKiBBbGwgQ1BVcyBzdGFydCBoYWx0ZWQu
ICBDUFUwIGlzIHVuaGFsdGVkIGZyb20gdGhlIG1hY2hpbmUgbGV2ZWwKICAgICAgKiByZXNldCBj
b2RlIGFuZCB0aGUgcmVzdCBhcmUgZXhwbGljaXRseSBzdGFydGVkIHVwIGJ5IHRoZSBndWVzdAog
ICAgICAqIHVzaW5nIGFuIFJUQVMgY2FsbCAqLwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBj
cy0+aGFsdGVkID0gMTsKIAogICAgIGVudi0+c3ByW1NQUl9ISU9SXSA9IDA7CiAKZGlmZiAtLWdp
dCBhL2h3L3NwYXByX2hjYWxsLmMgYi9ody9zcGFwcl9oY2FsbC5jCmluZGV4IGFmMWRiNmUuLjdj
MjgxNDQgMTAwNjQ0Ci0tLSBhL2h3L3NwYXByX2hjYWxsLmMKKysrIGIvaHcvc3BhcHJfaGNhbGwu
YwpAQCAtNTE4LDcgKzUxOCw3IEBAIHN0YXRpYyB0YXJnZXRfdWxvbmcgaF9jZWRlKFBvd2VyUEND
UFUgKmNwdSwgc1BBUFJFbnZpcm9ubWVudCAqc3BhcHIsCiAgICAgZW52LT5tc3IgfD0gKDFVTEwg
PDwgTVNSX0VFKTsKICAgICBocmVnX2NvbXB1dGVfaGZsYWdzKGVudik7CiAgICAgaWYgKCFjcHVf
aGFzX3dvcmsoY3MpKSB7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgY3MtPmhh
bHRlZCA9IDE7CiAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiAgICAg
ICAgIGNzLT5leGl0X3JlcXVlc3QgPSAxOwogICAgIH0KZGlmZiAtLWdpdCBhL2h3L3NwYXByX3J0
YXMuYyBiL2h3L3NwYXByX3J0YXMuYwppbmRleCA1ZWM3ODdmLi5hMjRlODUzIDEwMDY0NAotLS0g
YS9ody9zcGFwcl9ydGFzLmMKKysrIGIvaHcvc3BhcHJfcnRhcy5jCkBAIC0xNDUsNyArMTQ1LDcg
QEAgc3RhdGljIHZvaWQgcnRhc19xdWVyeV9jcHVfc3RvcHBlZF9zdGF0ZShzUEFQUkVudmlyb25t
ZW50ICpzcGFwciwKICAgICAgICAgICAgIGNvbnRpbnVlOwogICAgICAgICB9CiAKLSAgICAgICAg
aWYgKGVudi0+aGFsdGVkKSB7CisgICAgICAgIGlmIChjcHUtPmhhbHRlZCkgewogICAgICAgICAg
ICAgcnRhc19zdChyZXRzLCAxLCAwKTsKICAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgIHJ0
YXNfc3QocmV0cywgMSwgMik7CkBAIC0xODQsNyArMTg0LDcgQEAgc3RhdGljIHZvaWQgcnRhc19z
dGFydF9jcHUoc1BBUFJFbnZpcm9ubWVudCAqc3BhcHIsCiAgICAgICAgICAgICBjb250aW51ZTsK
ICAgICAgICAgfQogCi0gICAgICAgIGlmICghZW52LT5oYWx0ZWQpIHsKKyAgICAgICAgaWYgKCFj
cHUtPmhhbHRlZCkgewogICAgICAgICAgICAgcnRhc19zdChyZXRzLCAwLCAtMSk7CiAgICAgICAg
ICAgICByZXR1cm47CiAgICAgICAgIH0KQEAgLTE5Nyw3ICsxOTcsNyBAQCBzdGF0aWMgdm9pZCBy
dGFzX3N0YXJ0X2NwdShzUEFQUkVudmlyb25tZW50ICpzcGFwciwKICAgICAgICAgZW52LT5tc3Ig
PSAoMVVMTCA8PCBNU1JfU0YpIHwgKDFVTEwgPDwgTVNSX01FKTsKICAgICAgICAgZW52LT5uaXAg
PSBzdGFydDsKICAgICAgICAgZW52LT5ncHJbM10gPSByMzsKLSAgICAgICAgZW52LT5oYWx0ZWQg
PSAwOworICAgICAgICBjcHUtPmhhbHRlZCA9IDA7CiAKICAgICAgICAgcWVtdV9jcHVfa2ljayhj
cHUpOwogCmRpZmYgLS1naXQgYS9ody9zdW40bS5jIGIvaHcvc3VuNG0uYwppbmRleCA5OTAzZjQ0
Li40NWY5NDQxIDEwMDY0NAotLS0gYS9ody9zdW40bS5jCisrKyBiL2h3L3N1bjRtLmMKQEAgLTI1
NiwxMCArMjU2LDExIEBAIHZvaWQgY3B1X2NoZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQog
c3RhdGljIHZvaWQgY3B1X2tpY2tfaXJxKFNQQVJDQ1BVICpjcHUpCiB7CiAgICAgQ1BVU1BBUkNT
dGF0ZSAqZW52ID0gJmNwdS0+ZW52OworICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogCi0g
ICAgZW52LT5oYWx0ZWQgPSAwOworICAgIGNzLT5oYWx0ZWQgPSAwOwogICAgIGNwdV9jaGVja19p
cnFzKGVudik7Ci0gICAgcWVtdV9jcHVfa2ljayhDUFUoY3B1KSk7CisgICAgcWVtdV9jcHVfa2lj
ayhjcyk7CiB9CiAKIHN0YXRpYyB2b2lkIGNwdV9zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IGly
cSwgaW50IGxldmVsKQpAQCAtMjg1LDE5ICsyODYsMTkgQEAgc3RhdGljIHZvaWQgZHVtbXlfY3B1
X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQgaXJxLCBpbnQgbGV2ZWwpCiBzdGF0aWMgdm9pZCBt
YWluX2NwdV9yZXNldCh2b2lkICpvcGFxdWUpCiB7CiAgICAgU1BBUkNDUFUgKmNwdSA9IG9wYXF1
ZTsKLSAgICBDUFVTUEFSQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CisgICAgQ1BVU3RhdGUgKmNz
ID0gQ1BVKGNwdSk7CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNwdSkpOwotICAgIGVudi0+aGFsdGVk
ID0gMDsKKyAgICBjcHVfcmVzZXQoY3MpOworICAgIGNzLT5oYWx0ZWQgPSAwOwogfQogCiBzdGF0
aWMgdm9pZCBzZWNvbmRhcnlfY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAgICBTUEFSQ0NQ
VSAqY3B1ID0gb3BhcXVlOwotICAgIENQVVNQQVJDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKKyAg
ICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKIAotICAgIGNwdV9yZXNldChDUFUoY3B1KSk7Ci0g
ICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNwdV9yZXNldChjcyk7CisgICAgY3MtPmhhbHRlZCA9
IDE7CiB9CiAKIHN0YXRpYyB2b2lkIGNwdV9oYWx0X3NpZ25hbCh2b2lkICpvcGFxdWUsIGludCBp
cnEsIGludCBsZXZlbCkKQEAgLTgyNiw2ICs4MjcsNyBAQCBzdGF0aWMgY29uc3QgVHlwZUluZm8g
cmFtX2luZm8gPSB7CiBzdGF0aWMgdm9pZCBjcHVfZGV2aW5pdChjb25zdCBjaGFyICpjcHVfbW9k
ZWwsIHVuc2lnbmVkIGludCBpZCwKICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2NF90IHBy
b21fYWRkciwgcWVtdV9pcnEgKipjcHVfaXJxcykKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAg
U1BBUkNDUFUgKmNwdTsKICAgICBDUFVTUEFSQ1N0YXRlICplbnY7CiAKQEAgLTg0MSw3ICs4NDMs
OCBAQCBzdGF0aWMgdm9pZCBjcHVfZGV2aW5pdChjb25zdCBjaGFyICpjcHVfbW9kZWwsIHVuc2ln
bmVkIGludCBpZCwKICAgICAgICAgcWVtdV9yZWdpc3Rlcl9yZXNldChtYWluX2NwdV9yZXNldCwg
Y3B1KTsKICAgICB9IGVsc2UgewogICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0KHNlY29uZGFy
eV9jcHVfcmVzZXQsIGNwdSk7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgY3Mg
PSBDUFUoY3B1KTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgfQogICAgICpjcHVfaXJx
cyA9IHFlbXVfYWxsb2NhdGVfaXJxcyhjcHVfc2V0X2lycSwgY3B1LCBNQVhfUElMUyk7CiAgICAg
ZW52LT5wcm9tX2FkZHIgPSBwcm9tX2FkZHI7CmRpZmYgLS1naXQgYS9ody9zdW40dS5jIGIvaHcv
c3VuNHUuYwppbmRleCA5ZmJkYTI5Li4wNTZiYjRkIDEwMDY0NAotLS0gYS9ody9zdW40dS5jCisr
KyBiL2h3L3N1bjR1LmMKQEAgLTI1NCw2ICsyNTQsNyBAQCBzdGF0aWMgdWludDY0X3Qgc3VuNHVf
bG9hZF9rZXJuZWwoY29uc3QgY2hhciAqa2VybmVsX2ZpbGVuYW1lLAogCiB2b2lkIGNwdV9jaGVj
a19pcnFzKENQVVNQQVJDU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAgdWlu
dDMyX3QgcGlsID0gZW52LT5waWxfaW4gfAogICAgICAgICAgICAgICAgICAgKGVudi0+c29mdGlu
dCAmIH4oU09GVElOVF9USU1FUiB8IFNPRlRJTlRfU1RJTUVSKSk7CiAKQEAgLTI2MSw2ICsyNjIs
NyBAQCB2b2lkIGNwdV9jaGVja19pcnFzKENQVVNQQVJDU3RhdGUgKmVudikKICAgICBpZiAoZW52
LT5pdmVjX3N0YXR1cyAmIDB4MjApIHsKICAgICAgICAgcmV0dXJuOwogICAgIH0KKyAgICBjcyA9
IENQVShzcGFyY19lbnZfZ2V0X2NwdShlbnYpKTsKICAgICAvKiBjaGVjayBpZiBUTSBvciBTTSBp
biBTT0ZUSU5UIGFyZSBzZXQKICAgICAgICBzZXR0aW5nIHRoZXNlIGFsc28gY2F1c2VzIGludGVy
cnVwdCAxNCAqLwogICAgIGlmIChlbnYtPnNvZnRpbnQgJiAoU09GVElOVF9USU1FUiB8IFNPRlRJ
TlRfU1RJTUVSKSkgewpAQCAtMjcwLDcgKzI3Miw3IEBAIHZvaWQgY3B1X2NoZWNrX2lycXMoQ1BV
U1BBUkNTdGF0ZSAqZW52KQogICAgIC8qIFRoZSBiaXQgY29ycmVzcG9uZGluZyB0byBwc3JwaWwg
aXMgKDE8PCBwc3JwaWwpLCB0aGUgbmV4dCBiaXQKICAgICAgICBpcyAoMiA8PCBwc3JwaWwpLiAq
LwogICAgIGlmIChwaWwgPCAoMiA8PCBlbnYtPnBzcnBpbCkpewotICAgICAgICBpZiAoZW52LT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgeworICAgICAgICBpZiAoY3Mt
PmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSB7CiAgICAgICAgICAgICBD
UFVJUlFfRFBSSU5URigiUmVzZXQgQ1BVIElSUSAoY3VycmVudCBpbnRlcnJ1cHQgJXgpXG4iLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfaW5kZXgpOwogICAgICAg
ICAgICAgZW52LT5pbnRlcnJ1cHRfaW5kZXggPSAwOwpAQCAtMzAyLDcgKzMwNCw3IEBAIHZvaWQg
Y3B1X2NoZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogICAgICAgICAgICAgICAgIGJyZWFr
OwogICAgICAgICAgICAgfQogICAgICAgICB9Ci0gICAgfSBlbHNlIGlmIChlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSB7CisgICAgfSBlbHNlIGlmIChjcy0+aW50
ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKICAgICAgICAgQ1BVSVJRX0RQ
UklOVEYoIkludGVycnVwdHMgZGlzYWJsZWQsIHBpbD0lMDh4IHBpbF9pbj0lMDh4IHNvZnRpbnQ9
JTA4eCAiCiAgICAgICAgICAgICAgICAgICAgICAgICJjdXJyZW50IGludGVycnVwdCAleFxuIiwK
ICAgICAgICAgICAgICAgICAgICAgICAgcGlsLCBlbnYtPnBpbF9pbiwgZW52LT5zb2Z0aW50LCBl
bnYtPmludGVycnVwdF9pbmRleCk7CkBAIC0zMTMsMjIgKzMxNSwyNSBAQCB2b2lkIGNwdV9jaGVj
a19pcnFzKENQVVNQQVJDU3RhdGUgKmVudikKIAogc3RhdGljIHZvaWQgY3B1X2tpY2tfaXJxKFNQ
QVJDQ1BVICpjcHUpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVU1BB
UkNTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgZW52LT5oYWx0ZWQgPSAwOworICAgIGNz
LT5oYWx0ZWQgPSAwOwogICAgIGNwdV9jaGVja19pcnFzKGVudik7Ci0gICAgcWVtdV9jcHVfa2lj
ayhDUFUoY3B1KSk7CisgICAgcWVtdV9jcHVfa2ljayhjcyk7CiB9CiAKIHN0YXRpYyB2b2lkIGNw
dV9zZXRfaXZlY19pcnEodm9pZCAqb3BhcXVlLCBpbnQgaXJxLCBpbnQgbGV2ZWwpCiB7CiAgICAg
U1BBUkNDUFUgKmNwdSA9IG9wYXF1ZTsKICAgICBDUFVTUEFSQ1N0YXRlICplbnYgPSAmY3B1LT5l
bnY7CisgICAgQ1BVU3RhdGUgKmNzOwogCiAgICAgaWYgKGxldmVsKSB7CiAgICAgICAgIGlmICgh
KGVudi0+aXZlY19zdGF0dXMgJiAweDIwKSkgewogICAgICAgICAgICAgQ1BVSVJRX0RQUklOVEYo
IlJhaXNlIElWRUMgSVJRICVkXG4iLCBpcnEpOwotICAgICAgICAgICAgZW52LT5oYWx0ZWQgPSAw
OworICAgICAgICAgICAgY3MgPSBDUFUoY3B1KTsKKyAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAw
OwogICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfaW5kZXggPSBUVF9JVkVDOwogICAgICAgICAg
ICAgZW52LT5pdmVjX3N0YXR1cyB8PSAweDIwOwogICAgICAgICAgICAgZW52LT5pdmVjX2RhdGFb
MF0gPSAoMHgxZiA8PCA2KSB8IGlycTsKZGlmZiAtLWdpdCBhL2h3L3hlbl9tYWNoaW5lX3B2LmMg
Yi9ody94ZW5fbWFjaGluZV9wdi5jCmluZGV4IDY2ZTg5ODEuLjRmZWM0ZmMgMTAwNjQ0Ci0tLSBh
L2h3L3hlbl9tYWNoaW5lX3B2LmMKKysrIGIvaHcveGVuX21hY2hpbmVfcHYuYwpAQCAtMzYsNyAr
MzYsNyBAQCBzdGF0aWMgdm9pZCB4ZW5faW5pdF9wdihRRU1VTWFjaGluZUluaXRBcmdzICphcmdz
KQogICAgIGNvbnN0IGNoYXIgKmtlcm5lbF9jbWRsaW5lID0gYXJncy0+a2VybmVsX2NtZGxpbmU7
CiAgICAgY29uc3QgY2hhciAqaW5pdHJkX2ZpbGVuYW1lID0gYXJncy0+aW5pdHJkX2ZpbGVuYW1l
OwogICAgIFg4NkNQVSAqY3B1OwotICAgIENQVVg4NlN0YXRlICplbnY7CisgICAgQ1BVU3RhdGUg
KmNzOwogICAgIERyaXZlSW5mbyAqZGluZm87CiAgICAgaW50IGk7CiAKQEAgLTQ5LDggKzQ5LDgg
QEAgc3RhdGljIHZvaWQgeGVuX2luaXRfcHYoUUVNVU1hY2hpbmVJbml0QXJncyAqYXJncykKICNl
bmRpZgogICAgIH0KICAgICBjcHUgPSBjcHVfeDg2X2luaXQoY3B1X21vZGVsKTsKLSAgICBlbnYg
PSAmY3B1LT5lbnY7Ci0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNzID0gQ1BVKGNwdSk7Cisg
ICAgY3MtPmhhbHRlZCA9IDE7CiAKICAgICAvKiBJbml0aWFsaXplIGJhY2tlbmQgY29yZSAmIGRy
aXZlcnMgKi8KICAgICBpZiAoeGVuX2JlX2luaXQoKSAhPSAwKSB7CmRpZmYgLS1naXQgYS9ody94
dGVuc2FfcGljLmMgYi9ody94dGVuc2FfcGljLmMKaW5kZXggOTdkMzZiZS4uZGNhMTViNCAxMDA2
NDQKLS0tIGEvaHcveHRlbnNhX3BpYy5jCisrKyBiL2h3L3h0ZW5zYV9waWMuYwpAQCAtNDcsNiAr
NDcsNyBAQCB2b2lkIHh0ZW5zYV9hZHZhbmNlX2Njb3VudChDUFVYdGVuc2FTdGF0ZSAqZW52LCB1
aW50MzJfdCBkKQogCiB2b2lkIGNoZWNrX2ludGVycnVwdHMoQ1BVWHRlbnNhU3RhdGUgKmVudikK
IHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoeHRlbnNhX2Vudl9nZXRfY3B1KGVudikpOwogICAg
IGludCBtaW5sZXZlbCA9IHh0ZW5zYV9nZXRfY2ludGxldmVsKGVudik7CiAgICAgdWludDMyX3Qg
aW50X3NldF9lbmFibGVkID0gZW52LT5zcmVnc1tJTlRTRVRdICYgZW52LT5zcmVnc1tJTlRFTkFC
TEVdOwogICAgIGludCBsZXZlbDsKQEAgLTU0LDcgKzU1LDcgQEAgdm9pZCBjaGVja19pbnRlcnJ1
cHRzKENQVVh0ZW5zYVN0YXRlICplbnYpCiAgICAgLyogSWYgdGhlIENQVSBpcyBoYWx0ZWQgYWR2
YW5jZSBDQ09VTlQgYWNjb3JkaW5nIHRvIHRoZSB2bV9jbG9jayB0aW1lCiAgICAgICogZWxhcHNl
ZCBzaW5jZSB0aGUgbW9tZW50IHdoZW4gaXQgd2FzIGFkdmFuY2VkIGxhc3QgdGltZS4KICAgICAg
Ki8KLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBpZiAoY3MtPmhhbHRlZCkgewogICAgICAg
ICBpbnQ2NF90IG5vdyA9IHFlbXVfZ2V0X2Nsb2NrX25zKHZtX2Nsb2NrKTsKIAogICAgICAgICB4
dGVuc2FfYWR2YW5jZV9jY291bnQoZW52LApAQCAtMTI3LDExICsxMjgsMTIgQEAgc3RhdGljIHZv
aWQgeHRlbnNhX2Njb21wYXJlX2NiKHZvaWQgKm9wYXF1ZSkKIHsKICAgICBYdGVuc2FDUFUgKmNw
dSA9IG9wYXF1ZTsKICAgICBDUFVYdGVuc2FTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OworICAgIENQ
VVN0YXRlICpjcyA9IENQVShjcHUpOwogCi0gICAgaWYgKGVudi0+aGFsdGVkKSB7CisgICAgaWYg
KGNzLT5oYWx0ZWQpIHsKICAgICAgICAgZW52LT5oYWx0X2Nsb2NrID0gcWVtdV9nZXRfY2xvY2tf
bnModm1fY2xvY2spOwogICAgICAgICB4dGVuc2FfYWR2YW5jZV9jY291bnQoZW52LCBlbnYtPndh
a2VfY2NvdW50IC0gZW52LT5zcmVnc1tDQ09VTlRdKTsKLSAgICAgICAgaWYgKCFjcHVfaGFzX3dv
cmsoQ1BVKGNwdSkpKSB7CisgICAgICAgIGlmICghY3B1X2hhc193b3JrKGNzKSkgewogICAgICAg
ICAgICAgZW52LT5zcmVnc1tDQ09VTlRdID0gZW52LT53YWtlX2Njb3VudCArIDE7CiAgICAgICAg
ICAgICB4dGVuc2FfcmVhcm1fY2NvbXBhcmVfdGltZXIoZW52KTsKICAgICAgICAgfQpkaWZmIC0t
Z2l0IGEvaW5jbHVkZS9leGVjL2NwdS1kZWZzLmggYi9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMuaApp
bmRleCBhZTY0NTkwLi5hNGM2MzcwIDEwMDY0NAotLS0gYS9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMu
aAorKysgYi9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMuaApAQCAtMTU2LDggKzE1Niw2IEBAIHR5cGVk
ZWYgc3RydWN0IENQVVdhdGNocG9pbnQgewogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFj
Y2Vzc2VkICovICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIHRhcmdldF91
bG9uZyBtZW1faW9fdmFkZHI7IC8qIHRhcmdldCB2aXJ0dWFsIGFkZHIgYXQgd2hpY2ggdGhlICAg
ICAgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lbW9yeSB3YXMgYWNj
ZXNzZWQgKi8gICAgICAgICAgICAgXAotICAgIHVpbnQzMl90IGhhbHRlZDsgLyogTm9uemVybyBp
ZiB0aGUgQ1BVIGlzIGluIHN1c3BlbmQgc3RhdGUgKi8gICAgICAgXAotICAgIHVpbnQzMl90IGlu
dGVycnVwdF9yZXF1ZXN0OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAogICAgIENQVV9DT01NT05fVExCICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAogICAgIHN0cnVjdCBUcmFuc2xhdGlvbkJsb2NrICp0Yl9qbXBf
Y2FjaGVbVEJfSk1QX0NBQ0hFX1NJWkVdOyAgICAgICAgICAgXAogICAgIC8qIGJ1ZmZlciBmb3Ig
dGVtcG9yYXJpZXMgaW4gdGhlIGNvZGUgZ2VuZXJhdG9yICovICAgICAgICAgICAgICAgICAgXApk
aWZmIC0tZ2l0IGEvaW5jbHVkZS9xb20vY3B1LmggYi9pbmNsdWRlL3FvbS9jcHUuaAppbmRleCBl
ZTFhN2M4Li45YWQ5ODIyIDEwMDY0NAotLS0gYS9pbmNsdWRlL3FvbS9jcHUuaAorKysgYi9pbmNs
dWRlL3FvbS9jcHUuaApAQCAtNjksNiArNjksOCBAQCBzdHJ1Y3Qga3ZtX3J1bjsKICAqIEBob3N0
X3RpZDogSG9zdCB0aHJlYWQgSUQuCiAgKiBAcnVubmluZzogI3RydWUgaWYgQ1BVIGlzIGN1cnJl
bnRseSBydW5uaW5nICh1c2VybW9kZSkuCiAgKiBAY3JlYXRlZDogSW5kaWNhdGVzIHdoZXRoZXIg
dGhlIENQVSB0aHJlYWQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQuCisgKiBAaW50ZXJy
dXB0X3JlcXVlc3Q6IEluZGljYXRlcyBhIHBlbmRpbmcgaW50ZXJydXB0IHJlcXVlc3QuCisgKiBA
aGFsdGVkOiBOb256ZXJvIGlmIHRoZSBDUFUgaXMgaW4gc3VzcGVuZGVkIHN0YXRlLgogICogQHN0
b3A6IEluZGljYXRlcyBhIHBlbmRpbmcgc3RvcCByZXF1ZXN0LgogICogQHN0b3BwZWQ6IEluZGlj
YXRlcyB0aGUgQ1BVIGhhcyBiZWVuIGFydGlmaWNpYWxseSBzdG9wcGVkLgogICogQGVudl9wdHI6
IFBvaW50ZXIgdG8gc3ViY2xhc3Mtc3BlY2lmaWMgQ1BVQXJjaFN0YXRlIGZpZWxkLgpAQCAtMTAw
LDYgKzEwMiw3IEBAIHN0cnVjdCBDUFVTdGF0ZSB7CiAgICAgYm9vbCBzdG9wOwogICAgIGJvb2wg
c3RvcHBlZDsKICAgICB2b2xhdGlsZSBzaWdfYXRvbWljX3QgZXhpdF9yZXF1ZXN0OworICAgIHVp
bnQzMl90IGludGVycnVwdF9yZXF1ZXN0OwogCiAgICAgdm9pZCAqZW52X3B0cjsgLyogQ1BVQXJj
aFN0YXRlICovCiAgICAgc3RydWN0IFRyYW5zbGF0aW9uQmxvY2sgKmN1cnJlbnRfdGI7CkBAIC0x
MTEsNiArMTE0LDcgQEAgc3RydWN0IENQVVN0YXRlIHsKIAogICAgIC8qIFRPRE8gTW92ZSBjb21t
b24gZmllbGRzIGZyb20gQ1BVQXJjaFN0YXRlIGhlcmUuICovCiAgICAgaW50IGNwdV9pbmRleDsg
LyogdXNlZCBieSBhbHBoYSBUQ0cgKi8KKyAgICB1aW50MzJfdCBoYWx0ZWQ7IC8qIHVzZWQgYnkg
YWxwaGEsIGNyaXMsIHBwYyBUQ0cgKi8KIH07CiAKIApkaWZmIC0tZ2l0IGEva3ZtLWFsbC5jIGIv
a3ZtLWFsbC5jCmluZGV4IDRkZWNmZGMuLjJiNzYxZTAgMTAwNjQ0Ci0tLSBhL2t2bS1hbGwuYwor
KysgYi9rdm0tYWxsLmMKQEAgLTgzMCw3ICs4MzAsNyBAQCBzdGF0aWMgdm9pZCBrdm1faGFuZGxl
X2ludGVycnVwdChDUFVBcmNoU3RhdGUgKmVudiwgaW50IG1hc2spCiB7CiAgICAgQ1BVU3RhdGUg
KmNwdSA9IEVOVl9HRVRfQ1BVKGVudik7CiAKLSAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9
IG1hc2s7CisgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBtYXNrOwogCiAgICAgaWYgKCFx
ZW11X2NwdV9pc19zZWxmKGNwdSkpIHsKICAgICAgICAgcWVtdV9jcHVfa2ljayhjcHUpOwpkaWZm
IC0tZ2l0IGEvcW9tL2NwdS5jIGIvcW9tL2NwdS5jCmluZGV4IDBhMjE5NGQuLjBhYTliZTcgMTAw
NjQ0Ci0tLSBhL3FvbS9jcHUuYworKysgYi9xb20vY3B1LmMKQEAgLTMzLDcgKzMzLDkgQEAgdm9p
ZCBjcHVfcmVzZXQoQ1BVU3RhdGUgKmNwdSkKIHN0YXRpYyB2b2lkIGNwdV9jb21tb25fcmVzZXQo
Q1BVU3RhdGUgKmNwdSkKIHsKICAgICBjcHUtPmV4aXRfcmVxdWVzdCA9IDA7CisgICAgY3B1LT5p
bnRlcnJ1cHRfcmVxdWVzdCA9IDA7CiAgICAgY3B1LT5jdXJyZW50X3RiID0gTlVMTDsKKyAgICBj
cHUtPmhhbHRlZCA9IDA7CiB9CiAKIE9iamVjdENsYXNzICpjcHVfY2xhc3NfYnlfbmFtZShjb25z
dCBjaGFyICp0eXBlbmFtZSwgY29uc3QgY2hhciAqY3B1X21vZGVsKQpkaWZmIC0tZ2l0IGEvdGFy
Z2V0LWFscGhhL2NwdS5oIGIvdGFyZ2V0LWFscGhhL2NwdS5oCmluZGV4IGYxZGI2NTEuLjkwZjc4
YWMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1hbHBoYS9jcHUuaAorKysgYi90YXJnZXQtYWxwaGEvY3B1
LmgKQEAgLTUxNyw4ICs1MTcsNiBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X3NldF90bHMoQ1BV
QWxwaGFTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgbmV3dGxzKQogCiBzdGF0aWMgaW5saW5lIGJv
b2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVQWxwaGFTdGF0ZSAqZW52
ID0gJkFMUEhBX0NQVShjcHUpLT5lbnY7Ci0KICAgICAvKiBIZXJlIHdlIGFyZSBjaGVja2luZyB0
byBzZWUgaWYgdGhlIENQVSBzaG91bGQgd2FrZSB1cCBmcm9tIEhBTFQuCiAgICAgICAgV2Ugd2ls
bCBoYXZlIGdvdHRlbiBpbnRvIHRoaXMgc3RhdGUgb25seSBmb3IgV1RJTlQgZnJvbSBQQUxtb2Rl
LiAgKi8KICAgICAvKiA/Pz8gSSdtIG5vdCBzdXJlIGhvdyB0aGUgSVBMIHN0YXRlIHdvcmtzIHdp
dGggV1RJTlQgdG8ga2VlcCBhIENQVQpAQCAtNTI2LDcgKzUyNCw3IEBAIHN0YXRpYyBpbmxpbmUg
Ym9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKICAgICAgICBhc3N1bWUgdGhhdCBpZiBh
IENQVSByZWFsbHkgd2FudHMgdG8gc3RheSBhc2xlZXAsIGl0IHdpbGwgbWFzawogICAgICAgIGlu
dGVycnVwdHMgYXQgdGhlIGNoaXBzZXQgbGV2ZWwsIHdoaWNoIHdpbGwgcHJldmVudCB0aGVzZSBi
aXRzCiAgICAgICAgZnJvbSBiZWluZyBzZXQgaW4gdGhlIGZpcnN0IHBsYWNlLiAgKi8KLSAgICBy
ZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQKKyAgICBy
ZXR1cm4gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENQVV9JTlRFUlJVUFRfVElNRVIKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENQVV9JTlRFUlJVUFRfU01QCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBDUFVfSU5URVJSVVBUX01DSEsp
OwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWFscGhhL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LWFscGhhL3Ry
YW5zbGF0ZS5jCmluZGV4IGY2ODdiOTUuLmE0ZjcyYjggMTAwNjQ0Ci0tLSBhL3RhcmdldC1hbHBo
YS90cmFuc2xhdGUuYworKysgYi90YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMKQEAgLTE2ODcsNyAr
MTY4Nyw4IEBAIHN0YXRpYyBFeGl0U3RhdHVzIGdlbl9tdHByKERpc2FzQ29udGV4dCAqY3R4LCBp
bnQgcmIsIGludCByZWdubykKICAgICBjYXNlIDI1MzoKICAgICAgICAgLyogV0FJVCAqLwogICAg
ICAgICB0bXAgPSB0Y2dfY29uc3RfaTY0KDEpOwotICAgICAgICB0Y2dfZ2VuX3N0MzJfaTY0KHRt
cCwgY3B1X2Vudiwgb2Zmc2V0b2YoQ1BVQWxwaGFTdGF0ZSwgaGFsdGVkKSk7CisgICAgICAgIHRj
Z19nZW5fc3QzMl9pNjQodG1wLCBjcHVfZW52LCAtb2Zmc2V0b2YoQWxwaGFDUFUsIGVudikgKwor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2Zmc2V0b2YoQ1BVU3RhdGUs
IGhhbHRlZCkpOwogICAgICAgICByZXR1cm4gZ2VuX2V4Y3AoY3R4LCBFWENQX0hMVCwgMCk7CiAK
ICAgICBjYXNlIDI1MjoKZGlmZiAtLWdpdCBhL3RhcmdldC1hcm0vY3B1LmggYi90YXJnZXQtYXJt
L2NwdS5oCmluZGV4IDI5MDJiYTUuLjdjNDc0NjcgMTAwNjQ0Ci0tLSBhL3RhcmdldC1hcm0vY3B1
LmgKKysrIGIvdGFyZ2V0LWFybS9jcHUuaApAQCAtNzIxLDkgKzcyMSw3IEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBjcHVfZ2V0X3RiX2NwdV9zdGF0ZShDUFVBUk1TdGF0ZSAqZW52LCB0YXJnZXRfdWxv
bmcgKnBjLAogCiBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUp
CiB7Ci0gICAgQ1BVQVJNU3RhdGUgKmVudiA9ICZBUk1fQ1BVKGNwdSktPmVudjsKLQotICAgIHJl
dHVybiBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYKKyAgICByZXR1cm4gY3B1LT5pbnRlcnJ1cHRf
cmVxdWVzdCAmCiAgICAgICAgIChDUFVfSU5URVJSVVBUX0ZJUSB8IENQVV9JTlRFUlJVUFRfSEFS
RCB8IENQVV9JTlRFUlJVUFRfRVhJVFRCKTsKIH0KIApkaWZmIC0tZ2l0IGEvdGFyZ2V0LWFybS9o
ZWxwZXIuYyBiL3RhcmdldC1hcm0vaGVscGVyLmMKaW5kZXggZTYzZGE1Ny4uMzFiN2EzYyAxMDA2
NDQKLS0tIGEvdGFyZ2V0LWFybS9oZWxwZXIuYworKysgYi90YXJnZXQtYXJtL2hlbHBlci5jCkBA
IC0xODAyLDYgKzE4MDIsNyBAQCBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1cHRfdjdtKENQVUFSTVN0
YXRlICplbnYpCiAvKiBIYW5kbGUgYSBDUFUgZXhjZXB0aW9uLiAgKi8KIHZvaWQgZG9faW50ZXJy
dXB0KENQVUFSTVN0YXRlICplbnYpCiB7CisgICAgQ1BVU3RhdGUgKmNzOwogICAgIHVpbnQzMl90
IGFkZHI7CiAgICAgdWludDMyX3QgbWFzazsKICAgICBpbnQgbmV3X21vZGU7CkBAIC0xOTA4LDcg
KzE5MDksOCBAQCB2b2lkIGRvX2ludGVycnVwdChDUFVBUk1TdGF0ZSAqZW52KQogICAgIH0KICAg
ICBlbnYtPnJlZ3NbMTRdID0gZW52LT5yZWdzWzE1XSArIG9mZnNldDsKICAgICBlbnYtPnJlZ3Nb
MTVdID0gYWRkcjsKLSAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRf
RVhJVFRCOworICAgIGNzID0gQ1BVKGFybV9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICBjcy0+aW50
ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiB9CiAKIC8qIENoZWNrIHNl
Y3Rpb24vcGFnZSBhY2Nlc3MgcGVybWlzc2lvbnMuCmRpZmYgLS1naXQgYS90YXJnZXQtYXJtL29w
X2hlbHBlci5jIGIvdGFyZ2V0LWFybS9vcF9oZWxwZXIuYwppbmRleCA5OTYxMGQ3Li43YWY1MTg3
IDEwMDY0NAotLS0gYS90YXJnZXQtYXJtL29wX2hlbHBlci5jCisrKyBiL3RhcmdldC1hcm0vb3Bf
aGVscGVyLmMKQEAgLTIxOCw4ICsyMTgsMTAgQEAgdWludDMyX3QgSEVMUEVSKHVzYXQxNikoQ1BV
QVJNU3RhdGUgKmVudiwgdWludDMyX3QgeCwgdWludDMyX3Qgc2hpZnQpCiAKIHZvaWQgSEVMUEVS
KHdmaSkoQ1BVQVJNU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoYXJtX2Vu
dl9nZXRfY3B1KGVudikpOworCiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsK
LSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgY3B1X2xvb3Bf
ZXhpdChlbnYpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtY3Jpcy9jcHUuaCBiL3RhcmdldC1j
cmlzL2NwdS5oCmluZGV4IGViZjJkNDAuLjJmYzdjNWMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1jcmlz
L2NwdS5oCisrKyBiL3RhcmdldC1jcmlzL2NwdS5oCkBAIC0yODksOSArMjg5LDcgQEAgdm9pZCBj
cmlzX2NwdV9saXN0KEZJTEUgKmYsIGZwcmludGZfZnVuY3Rpb24gY3B1X2ZwcmludGYpOwogCiBz
dGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BV
Q1JJU1N0YXRlICplbnYgPSAmQ1JJU19DUFUoY3B1KS0+ZW52OwotCi0gICAgcmV0dXJuIGVudi0+
aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9O
TUkpOworICAgIHJldHVybiBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRf
SEFSRCB8IENQVV9JTlRFUlJVUFRfTk1JKTsKIH0KIAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwu
aCIKZGlmZiAtLWdpdCBhL3RhcmdldC1jcmlzL2hlbHBlci5jIGIvdGFyZ2V0LWNyaXMvaGVscGVy
LmMKaW5kZXggZGUwNDE0My4uNTFjOWE5ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWNyaXMvaGVscGVy
LmMKKysrIGIvdGFyZ2V0LWNyaXMvaGVscGVyLmMKQEAgLTY2LDYgKzY2LDcgQEAgc3RhdGljIHZv
aWQgY3Jpc19zaGlmdF9jY3MoQ1BVQ1JJU1N0YXRlICplbnYpCiBpbnQgY3B1X2NyaXNfaGFuZGxl
X21tdV9mYXVsdChDUFVDUklTU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIGFkZHJlc3MsIGludCBy
dywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBtbXVfaWR4KQogeworICAgIEQo
Q1BVU3RhdGUgKmNwdSA9IENQVShjcmlzX2Vudl9nZXRfY3B1KGVudikpKTsKICAgICBzdHJ1Y3Qg
Y3Jpc19tbXVfcmVzdWx0IHJlczsKICAgICBpbnQgcHJvdCwgbWlzczsKICAgICBpbnQgciA9IC0x
OwpAQCAtOTksNyArMTAwLDcgQEAgaW50IGNwdV9jcmlzX2hhbmRsZV9tbXVfZmF1bHQoQ1BVQ1JJ
U1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBhZGRyZXNzLCBpbnQgcncsCiAgICAgfQogICAgIGlm
IChyID4gMCkgewogICAgICAgICBEX0xPRygiJXMgcmV0dXJucyAlZCBpcnFyZXE9JXggYWRkcj0l
eCBwaHk9JXggdmVjPSV4IHBjPSV4XG4iLAotICAgICAgICAgICAgICBfX2Z1bmNfXywgciwgZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCwgYWRkcmVzcywgcmVzLnBoeSwKKyAgICAgICAgICAgICAgX19m
dW5jX18sIHIsIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QsIGFkZHJlc3MsIHJlcy5waHksCiAgICAg
ICAgICAgICAgIHJlcy5iZl92ZWMsIGVudi0+cGMpOwogICAgIH0KICAgICByZXR1cm4gcjsKQEAg
LTEwNywxMSArMTA4LDEyIEBAIGludCBjcHVfY3Jpc19oYW5kbGVfbW11X2ZhdWx0KENQVUNSSVNT
dGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgYWRkcmVzcywgaW50IHJ3LAogCiBzdGF0aWMgdm9pZCBk
b19pbnRlcnJ1cHR2MTAoQ1BVQ1JJU1N0YXRlICplbnYpCiB7CisgICAgRChDUFVTdGF0ZSAqY3B1
ID0gQ1BVKGNyaXNfZW52X2dldF9jcHUoZW52KSkpOwogICAgIGludCBleF92ZWMgPSAtMTsKIAog
ICAgIERfTE9HKCJleGNlcHRpb24gaW5kZXg9JWQgaW50ZXJydXB0X3JlcT0lZFxuIiwKICAgICAg
ICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCwKLSAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0KTsKKyAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0KTsKIAogICAgIGFzc2VydCgh
KGVudi0+cHJlZ3NbUFJfQ0NTXSAmIFBGSVhfRkxBRykpOwogICAgIHN3aXRjaCAoZW52LT5leGNl
cHRpb25faW5kZXgpIHsKQEAgLTE2Miw2ICsxNjQsNyBAQCBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1
cHR2MTAoQ1BVQ1JJU1N0YXRlICplbnYpCiAKIHZvaWQgZG9faW50ZXJydXB0KENQVUNSSVNTdGF0
ZSAqZW52KQogeworICAgIEQoQ1BVU3RhdGUgKmNwdSA9IENQVShjcmlzX2Vudl9nZXRfY3B1KGVu
dikpKTsKICAgICBpbnQgZXhfdmVjID0gLTE7CiAKICAgICBpZiAoZW52LT5wcmVnc1tQUl9WUl0g
PCAzMikgewpAQCAtMTcwLDcgKzE3Myw3IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVUNSSVNTdGF0
ZSAqZW52KQogCiAgICAgRF9MT0coImV4Y2VwdGlvbiBpbmRleD0lZCBpbnRlcnJ1cHRfcmVxPSVk
XG4iLAogICAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4LAotICAgICAgICAgIGVudi0+aW50
ZXJydXB0X3JlcXVlc3QpOworICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QpOwogCiAg
ICAgc3dpdGNoIChlbnYtPmV4Y2VwdGlvbl9pbmRleCkgewogICAgIGNhc2UgRVhDUF9CUkVBSzoK
ZGlmZiAtLWdpdCBhL3RhcmdldC1jcmlzL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LWNyaXMvdHJhbnNs
YXRlLmMKaW5kZXggMjVhNDNmYS4uMjJlNWU5ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWNyaXMvdHJh
bnNsYXRlLmMKKysrIGIvdGFyZ2V0LWNyaXMvdHJhbnNsYXRlLmMKQEAgLTI5MjgsNyArMjkyOCw4
IEBAIHN0YXRpYyBpbnQgZGVjX3JmZV9ldGMoQ1BVQ1JJU1N0YXRlICplbnYsIERpc2FzQ29udGV4
dCAqZGMpCiAgICAgY3Jpc19jY19tYXNrKGRjLCAwKTsKIAogICAgIGlmIChkYy0+b3AyID09IDE1
KSB7Ci0gICAgICAgIHRfZ2VuX21vdl9lbnZfVE4oaGFsdGVkLCB0Y2dfY29uc3RfdGwoMSkpOwor
ICAgICAgICB0Y2dfZ2VuX3N0X2kzMih0Y2dfY29uc3RfaTMyKDEpLCBjcHVfZW52LAorICAgICAg
ICAgICAgICAgICAgICAgICAtb2Zmc2V0b2YoQ1JJU0NQVSwgZW52KSArIG9mZnNldG9mKENQVVN0
YXRlLCBoYWx0ZWQpKTsKICAgICAgICAgdGNnX2dlbl9tb3ZpX3RsKGVudl9wYywgZGMtPnBjICsg
Mik7CiAgICAgICAgIHRfZ2VuX3JhaXNlX2V4Y2VwdGlvbihFWENQX0hMVCk7CiAgICAgICAgIHJl
dHVybiAyOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYvY3B1LmMgYi90YXJnZXQtaTM4Ni9jcHUu
YwppbmRleCA4YWQ4ZjIyLi5iODkyZGEwIDEwMDY0NAotLS0gYS90YXJnZXQtaTM4Ni9jcHUuYwor
KysgYi90YXJnZXQtaTM4Ni9jcHUuYwpAQCAtMTk4MCw3ICsxOTgwLDcgQEAgc3RhdGljIHZvaWQg
eDg2X2NwdV9yZXNldChDUFVTdGF0ZSAqcykKICAgICAgICAgYXBpY19kZXNpZ25hdGVfYnNwKGVu
di0+YXBpY19zdGF0ZSk7CiAgICAgfQogCi0gICAgZW52LT5oYWx0ZWQgPSAhY3B1X2lzX2JzcChj
cHUpOworICAgIHMtPmhhbHRlZCA9ICFjcHVfaXNfYnNwKGNwdSk7CiAjZW5kaWYKIH0KIApkaWZm
IC0tZ2l0IGEvdGFyZ2V0LWkzODYvY3B1LmggYi90YXJnZXQtaTM4Ni9jcHUuaAppbmRleCA5ZTZl
MWE2Li40MGNmMjQ2IDEwMDY0NAotLS0gYS90YXJnZXQtaTM4Ni9jcHUuaAorKysgYi90YXJnZXQt
aTM4Ni9jcHUuaApAQCAtOTU2LDYgKzk1Niw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBjcHVfeDg2
X2xvYWRfc2VnX2NhY2hlKENQVVg4NlN0YXRlICplbnYsCiBzdGF0aWMgaW5saW5lIHZvaWQgY3B1
X3g4Nl9sb2FkX3NlZ19jYWNoZV9zaXBpKFg4NkNQVSAqY3B1LAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgc2lwaV92ZWN0b3IpCiB7CisgICAgQ1BV
U3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsK
IAogICAgIGVudi0+ZWlwID0gMDsKQEAgLTk2Myw3ICs5NjQsNyBAQCBzdGF0aWMgaW5saW5lIHZv
aWQgY3B1X3g4Nl9sb2FkX3NlZ19jYWNoZV9zaXBpKFg4NkNQVSAqY3B1LAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lwaV92ZWN0b3IgPDwgMTIsCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBlbnYtPnNlZ3NbUl9DU10ubGltaXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBl
bnYtPnNlZ3NbUl9DU10uZmxhZ3MpOwotICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICBjcy0+aGFs
dGVkID0gMDsKIH0KIAogaW50IGNwdV94ODZfZ2V0X2Rlc2NyX2RlYnVnKENQVVg4NlN0YXRlICpl
bnYsIHVuc2lnbmVkIGludCBzZWxlY3RvciwKQEAgLTExNTcsMTcgKzExNTgsMTggQEAgc3RhdGlj
IGlubGluZSB2b2lkIGNwdV9jbG9uZV9yZWdzKENQVVg4NlN0YXRlICplbnYsIHRhcmdldF91bG9u
ZyBuZXdzcCkKICNpbmNsdWRlICJody9hcGljLmgiCiAjZW5kaWYKIAotc3RhdGljIGlubGluZSBi
b29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQorc3RhdGljIGlubGluZSBib29sIGNwdV9o
YXNfd29yayhDUFVTdGF0ZSAqY3MpCiB7Ci0gICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZYODZfQ1BV
KGNwdSktPmVudjsKKyAgICBYODZDUFUgKmNwdSA9IFg4Nl9DUFUoY3MpOworICAgIENQVVg4NlN0
YXRlICplbnYgPSAmY3B1LT5lbnY7CiAKLSAgICByZXR1cm4gKChlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBDUFVfSU5URVJSVVBUX1BPTEwpKSAmJgorICAgIHJldHVybiAoKGNzLT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX1BPTEwpKSAmJgogICAgICAgICAgICAg
KGVudi0+ZWZsYWdzICYgSUZfTUFTSykpIHx8Ci0gICAgICAgICAgIChlbnYtPmludGVycnVwdF9y
ZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfTk1JIHwKLSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9JTklUIHwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9TSVBJIHwKLSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9NQ0UpKTsKKyAgICAgICAgICAgKGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX05NSSB8CisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9JTklUIHwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX1NJUEkgfAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfTUNFKSk7CiB9CiAKICNpbmNs
dWRlICJleGVjL2V4ZWMtYWxsLmgiCmRpZmYgLS1naXQgYS90YXJnZXQtaTM4Ni9oZWxwZXIuYyBi
L3RhcmdldC1pMzg2L2hlbHBlci5jCmluZGV4IDFhODcyZmEuLjgwOGQ4NzkgMTAwNjQ0Ci0tLSBh
L3RhcmdldC1pMzg2L2hlbHBlci5jCisrKyBiL3RhcmdldC1pMzg2L2hlbHBlci5jCkBAIC0xNzEs
NiArMTcxLDcgQEAgZG9uZToKIHZvaWQgY3B1X2R1bXBfc3RhdGUoQ1BVWDg2U3RhdGUgKmVudiwg
RklMRSAqZiwgZnByaW50Zl9mdW5jdGlvbiBjcHVfZnByaW50ZiwKICAgICAgICAgICAgICAgICAg
ICAgaW50IGZsYWdzKQogeworICAgIENQVVN0YXRlICpjcyA9IENQVSh4ODZfZW52X2dldF9jcHUo
ZW52KSk7CiAgICAgaW50IGVmbGFncywgaSwgbmI7CiAgICAgY2hhciBjY19vcF9uYW1lWzMyXTsK
ICAgICBzdGF0aWMgY29uc3QgY2hhciAqc2VnX25hbWVbNl0gPSB7ICJFUyIsICJDUyIsICJTUyIs
ICJEUyIsICJGUyIsICJHUyIgfTsKQEAgLTIxNCw3ICsyMTUsNyBAQCB2b2lkIGNwdV9kdW1wX3N0
YXRlKENQVVg4NlN0YXRlICplbnYsIEZJTEUgKmYsIGZwcmludGZfZnVuY3Rpb24gY3B1X2Zwcmlu
dGYsCiAgICAgICAgICAgICAgICAgICAgIChlbnYtPmhmbGFncyA+PiBIRl9JTkhJQklUX0lSUV9T
SElGVCkgJiAxLAogICAgICAgICAgICAgICAgICAgICAoZW52LT5hMjBfbWFzayA+PiAyMCkgJiAx
LAogICAgICAgICAgICAgICAgICAgICAoZW52LT5oZmxhZ3MgPj4gSEZfU01NX1NISUZUKSAmIDEs
Ci0gICAgICAgICAgICAgICAgICAgIGVudi0+aGFsdGVkKTsKKyAgICAgICAgICAgICAgICAgICAg
Y3MtPmhhbHRlZCk7CiAgICAgfSBlbHNlCiAjZW5kaWYKICAgICB7CkBAIC0yNDEsNyArMjQyLDcg
QEAgdm9pZCBjcHVfZHVtcF9zdGF0ZShDUFVYODZTdGF0ZSAqZW52LCBGSUxFICpmLCBmcHJpbnRm
X2Z1bmN0aW9uIGNwdV9mcHJpbnRmLAogICAgICAgICAgICAgICAgICAgICAoZW52LT5oZmxhZ3Mg
Pj4gSEZfSU5ISUJJVF9JUlFfU0hJRlQpICYgMSwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+
YTIwX21hc2sgPj4gMjApICYgMSwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+aGZsYWdzID4+
IEhGX1NNTV9TSElGVCkgJiAxLAotICAgICAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCk7Cisg
ICAgICAgICAgICAgICAgICAgIGNzLT5oYWx0ZWQpOwogICAgIH0KIAogICAgIGZvcihpID0gMDsg
aSA8IDY7IGkrKykgewpAQCAtMTI5NCwxMiArMTI5NSwxMyBAQCBYODZDUFUgKmNwdV94ODZfaW5p
dChjb25zdCBjaGFyICpjcHVfbW9kZWwpCiAjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkK
IHZvaWQgZG9fY3B1X2luaXQoWDg2Q1BVICpjcHUpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BV
KGNwdSk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKLSAgICBpbnQgc2lwaSA9
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1NJUEk7CisgICAgaW50IHNp
cGkgPSBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1NJUEk7CiAgICAgdWlu
dDY0X3QgcGF0ID0gZW52LT5wYXQ7CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNwdSkpOwotICAgIGVu
di0+aW50ZXJydXB0X3JlcXVlc3QgPSBzaXBpOworICAgIGNwdV9yZXNldChjcyk7CisgICAgY3Mt
PmludGVycnVwdF9yZXF1ZXN0ID0gc2lwaTsKICAgICBlbnYtPnBhdCA9IHBhdDsKICAgICBhcGlj
X2luaXRfcmVzZXQoZW52LT5hcGljX3N0YXRlKTsKIH0KZGlmZiAtLWdpdCBhL3RhcmdldC1pMzg2
L2t2bS5jIGIvdGFyZ2V0LWkzODYva3ZtLmMKaW5kZXggMGNmNDEzZC4uZGYzMGZhNiAxMDA2NDQK
LS0tIGEvdGFyZ2V0LWkzODYva3ZtLmMKKysrIGIvdGFyZ2V0LWkzODYva3ZtLmMKQEAgLTE0NjAs
MTcgKzE0NjAsMTggQEAgc3RhdGljIGludCBrdm1fcHV0X21wX3N0YXRlKFg4NkNQVSAqY3B1KQog
CiBzdGF0aWMgaW50IGt2bV9nZXRfbXBfc3RhdGUoWDg2Q1BVICpjcHUpCiB7CisgICAgQ1BVU3Rh
dGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKICAg
ICBzdHJ1Y3Qga3ZtX21wX3N0YXRlIG1wX3N0YXRlOwogICAgIGludCByZXQ7CiAKLSAgICByZXQg
PSBrdm1fdmNwdV9pb2N0bChDUFUoY3B1KSwgS1ZNX0dFVF9NUF9TVEFURSwgJm1wX3N0YXRlKTsK
KyAgICByZXQgPSBrdm1fdmNwdV9pb2N0bChjcywgS1ZNX0dFVF9NUF9TVEFURSwgJm1wX3N0YXRl
KTsKICAgICBpZiAocmV0IDwgMCkgewogICAgICAgICByZXR1cm4gcmV0OwogICAgIH0KICAgICBl
bnYtPm1wX3N0YXRlID0gbXBfc3RhdGUubXBfc3RhdGU7CiAgICAgaWYgKGt2bV9pcnFjaGlwX2lu
X2tlcm5lbCgpKSB7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gKG1wX3N0YXRlLm1wX3N0YXRlID09
IEtWTV9NUF9TVEFURV9IQUxURUQpOworICAgICAgICBjcy0+aGFsdGVkID0gKG1wX3N0YXRlLm1w
X3N0YXRlID09IEtWTV9NUF9TVEFURV9IQUxURUQpOwogICAgIH0KICAgICByZXR1cm4gMDsKIH0K
QEAgLTE3NjIsOCArMTc2Myw4IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihDUFVTdGF0ZSAqY3B1
LCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogICAgIGludCByZXQ7CiAKICAgICAvKiBJbmplY3QgTk1J
ICovCi0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkg
ewotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX05NSTsK
KyAgICBpZiAoY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfTk1JKSB7Cisg
ICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfTk1JOwogICAg
ICAgICBEUFJJTlRGKCJpbmplY3RlZCBOTUlcbiIpOwogICAgICAgICByZXQgPSBrdm1fdmNwdV9p
b2N0bChjcHUsIEtWTV9OTUkpOwogICAgICAgICBpZiAocmV0IDwgMCkgewpAQCAtMTc3NSwxOCAr
MTc3NiwxOCBAQCB2b2lkIGt2bV9hcmNoX3ByZV9ydW4oQ1BVU3RhdGUgKmNwdSwgc3RydWN0IGt2
bV9ydW4gKnJ1bikKICAgICBpZiAoIWt2bV9pcnFjaGlwX2luX2tlcm5lbCgpKSB7CiAgICAgICAg
IC8qIEZvcmNlIHRoZSBWQ1BVIG91dCBvZiBpdHMgaW5uZXIgbG9vcCB0byBwcm9jZXNzIGFueSBJ
TklUIHJlcXVlc3RzCiAgICAgICAgICAqIG9yIHBlbmRpbmcgVFBSIGFjY2VzcyByZXBvcnRzLiAq
LwotICAgICAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmCisgICAgICAgIGlmIChjcHUt
PmludGVycnVwdF9yZXF1ZXN0ICYKICAgICAgICAgICAgIChDUFVfSU5URVJSVVBUX0lOSVQgfCBD
UFVfSU5URVJSVVBUX1RQUikpIHsKICAgICAgICAgICAgIGNwdS0+ZXhpdF9yZXF1ZXN0ID0gMTsK
ICAgICAgICAgfQogCiAgICAgICAgIC8qIFRyeSB0byBpbmplY3QgYW4gaW50ZXJydXB0IGlmIHRo
ZSBndWVzdCBjYW4gYWNjZXB0IGl0ICovCiAgICAgICAgIGlmIChydW4tPnJlYWR5X2Zvcl9pbnRl
cnJ1cHRfaW5qZWN0aW9uICYmCi0gICAgICAgICAgICAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKKyAgICAgICAgICAgIChjcHUtPmludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAgICAgICAgKGVudi0+ZWZsYWdzICYg
SUZfTUFTSykpIHsKICAgICAgICAgICAgIGludCBpcnE7CiAKLSAgICAgICAgICAgIGVudi0+aW50
ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICAgICAgICAgIGNwdS0+
aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFSRDsKICAgICAgICAgICAgIGly
cSA9IGNwdV9nZXRfcGljX2ludGVycnVwdChlbnYpOwogICAgICAgICAgICAgaWYgKGlycSA+PSAw
KSB7CiAgICAgICAgICAgICAgICAgc3RydWN0IGt2bV9pbnRlcnJ1cHQgaW50cjsKQEAgLTE4MDYs
NyArMTgwNyw3IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihDUFVTdGF0ZSAqY3B1LCBzdHJ1Y3Qg
a3ZtX3J1biAqcnVuKQogICAgICAgICAgKiBpbnRlcnJ1cHQsIHJlcXVlc3QgYW4gaW50ZXJydXB0
IHdpbmRvdyBleGl0LiAgVGhpcyB3aWxsCiAgICAgICAgICAqIGNhdXNlIGEgcmV0dXJuIHRvIHVz
ZXJzcGFjZSBhcyBzb29uIGFzIHRoZSBndWVzdCBpcyByZWFkeSB0bwogICAgICAgICAgKiByZWNl
aXZlIGludGVycnVwdHMuICovCi0gICAgICAgIGlmICgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfSEFSRCkpIHsKKyAgICAgICAgaWYgKChjcHUtPmludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSkgewogICAgICAgICAgICAgcnVuLT5yZXF1ZXN0X2lu
dGVycnVwdF93aW5kb3cgPSAxOwogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgcnVuLT5y
ZXF1ZXN0X2ludGVycnVwdF93aW5kb3cgPSAwOwpAQCAtMTgzNiwxMSArMTgzNywxMSBAQCBpbnQg
a3ZtX2FyY2hfcHJvY2Vzc19hc3luY19ldmVudHMoQ1BVU3RhdGUgKmNzKQogICAgIFg4NkNQVSAq
Y3B1ID0gWDg2X0NQVShjcyk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKIAot
ICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9NQ0UpIHsKKyAg
ICBpZiAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9NQ0UpIHsKICAgICAg
ICAgLyogV2UgbXVzdCBub3QgcmFpc2UgQ1BVX0lOVEVSUlVQVF9NQ0UgaWYgaXQncyBub3Qgc3Vw
cG9ydGVkLiAqLwogICAgICAgICBhc3NlcnQoZW52LT5tY2dfY2FwKTsKIAotICAgICAgICBlbnYt
PmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKKyAgICAgICAgY3MtPmlu
dGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKIAogICAgICAgICBrdm1fY3B1
X3N5bmNocm9uaXplX3N0YXRlKGVudik7CiAKQEAgLTE4NTMsNyArMTg1NCw3IEBAIGludCBrdm1f
YXJjaF9wcm9jZXNzX2FzeW5jX2V2ZW50cyhDUFVTdGF0ZSAqY3MpCiAgICAgICAgIGVudi0+ZXhj
ZXB0aW9uX2luamVjdGVkID0gRVhDUDEyX01DSEs7CiAgICAgICAgIGVudi0+aGFzX2Vycm9yX2Nv
ZGUgPSAwOwogCi0gICAgICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICAgICAgY3MtPmhhbHRlZCA9
IDA7CiAgICAgICAgIGlmIChrdm1faXJxY2hpcF9pbl9rZXJuZWwoKSAmJiBlbnYtPm1wX3N0YXRl
ID09IEtWTV9NUF9TVEFURV9IQUxURUQpIHsKICAgICAgICAgICAgIGVudi0+bXBfc3RhdGUgPSBL
Vk1fTVBfU1RBVEVfUlVOTkFCTEU7CiAgICAgICAgIH0KQEAgLTE4NjMsNDEgKzE4NjQsNDIgQEAg
aW50IGt2bV9hcmNoX3Byb2Nlc3NfYXN5bmNfZXZlbnRzKENQVVN0YXRlICpjcykKICAgICAgICAg
cmV0dXJuIDA7CiAgICAgfQogCi0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVf
SU5URVJSVVBUX1BPTEwpIHsKLSAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BV
X0lOVEVSUlVQVF9QT0xMOworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5U
RVJSVVBUX1BPTEwpIHsKKyAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5U
RVJSVVBUX1BPTEw7CiAgICAgICAgIGFwaWNfcG9sbF9pcnEoZW52LT5hcGljX3N0YXRlKTsKICAg
ICB9Ci0gICAgaWYgKCgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFS
RCkgJiYKKyAgICBpZiAoKChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hB
UkQpICYmCiAgICAgICAgICAoZW52LT5lZmxhZ3MgJiBJRl9NQVNLKSkgfHwKLSAgICAgICAgKGVu
di0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkpIHsKLSAgICAgICAgZW52
LT5oYWx0ZWQgPSAwOworICAgICAgICAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9OTUkpKSB7CisgICAgICAgIGNzLT5oYWx0ZWQgPSAwOwogICAgIH0KLSAgICBpZiAoZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSU5JVCkgeworICAgIGlmIChjcy0+
aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0lOSVQpIHsKICAgICAgICAga3ZtX2Nw
dV9zeW5jaHJvbml6ZV9zdGF0ZShlbnYpOwogICAgICAgICBkb19jcHVfaW5pdChjcHUpOwogICAg
IH0KLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfU0lQSSkg
eworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1NJUEkpIHsK
ICAgICAgICAga3ZtX2NwdV9zeW5jaHJvbml6ZV9zdGF0ZShlbnYpOwogICAgICAgICBkb19jcHVf
c2lwaShjcHUpOwogICAgIH0KLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9J
TlRFUlJVUFRfVFBSKSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9J
TlRFUlJVUFRfVFBSOworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX1RQUikgeworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJV
UFRfVFBSOwogICAgICAgICBrdm1fY3B1X3N5bmNocm9uaXplX3N0YXRlKGVudik7CiAgICAgICAg
IGFwaWNfaGFuZGxlX3Rwcl9hY2Nlc3NfcmVwb3J0KGVudi0+YXBpY19zdGF0ZSwgZW52LT5laXAs
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+dHByX2FjY2Vzc190
eXBlKTsKICAgICB9CiAKLSAgICByZXR1cm4gZW52LT5oYWx0ZWQ7CisgICAgcmV0dXJuIGNzLT5o
YWx0ZWQ7CiB9CiAKIHN0YXRpYyBpbnQga3ZtX2hhbmRsZV9oYWx0KFg4NkNQVSAqY3B1KQogewor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVg4NlN0YXRlICplbnYgPSAmY3B1
LT5lbnY7CiAKLSAgICBpZiAoISgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJV
UFRfSEFSRCkgJiYKKyAgICBpZiAoISgoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9IQVJEKSAmJgogICAgICAgICAgIChlbnYtPmVmbGFncyAmIElGX01BU0spKSAmJgotICAg
ICAgICAhKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkpIHsKLSAg
ICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICAhKGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfTk1JKSkgeworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAg
cmV0dXJuIEVYQ1BfSExUOwogICAgIH0KIApkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYvbWlzY19o
ZWxwZXIuYyBiL3RhcmdldC1pMzg2L21pc2NfaGVscGVyLmMKaW5kZXggYjZkNTc0MC4uZGZiYzA3
YiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvbWlzY19oZWxwZXIuYworKysgYi90YXJnZXQtaTM4
Ni9taXNjX2hlbHBlci5jCkBAIC01NTMsMjAgKzU1MywyNSBAQCB2b2lkIGhlbHBlcl9yZG1zcihD
UFVYODZTdGF0ZSAqZW52KQogfQogI2VuZGlmCiAKLXN0YXRpYyB2b2lkIGRvX2hsdChDUFVYODZT
dGF0ZSAqZW52KQorc3RhdGljIHZvaWQgZG9faGx0KFg4NkNQVSAqY3B1KQogeworICAgIENQVVN0
YXRlICpjcyA9IENQVShjcHUpOworICAgIENQVVg4NlN0YXRlICplbnYgPSAmY3B1LT5lbnY7CisK
ICAgICBlbnYtPmhmbGFncyAmPSB+SEZfSU5ISUJJVF9JUlFfTUFTSzsgLyogbmVlZGVkIGlmIHN0
aSBpcyBqdXN0IGJlZm9yZSAqLwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcy0+aGFsdGVk
ID0gMTsKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgIGNwdV9sb29w
X2V4aXQoZW52KTsKIH0KIAogdm9pZCBoZWxwZXJfaGx0KENQVVg4NlN0YXRlICplbnYsIGludCBu
ZXh0X2VpcF9hZGRlbmQpCiB7CisgICAgWDg2Q1BVICpjcHUgPSB4ODZfZW52X2dldF9jcHUoZW52
KTsKKwogICAgIGNwdV9zdm1fY2hlY2tfaW50ZXJjZXB0X3BhcmFtKGVudiwgU1ZNX0VYSVRfSExU
LCAwKTsKICAgICBFSVAgKz0gbmV4dF9laXBfYWRkZW5kOwogCi0gICAgZG9faGx0KGVudik7Cisg
ICAgZG9faGx0KGNwdSk7CiB9CiAKIHZvaWQgaGVscGVyX21vbml0b3IoQ1BVWDg2U3RhdGUgKmVu
diwgdGFyZ2V0X3Vsb25nIHB0cikKQEAgLTU4MCw3ICs1ODUsOCBAQCB2b2lkIGhlbHBlcl9tb25p
dG9yKENQVVg4NlN0YXRlICplbnYsIHRhcmdldF91bG9uZyBwdHIpCiAKIHZvaWQgaGVscGVyX213
YWl0KENQVVg4NlN0YXRlICplbnYsIGludCBuZXh0X2VpcF9hZGRlbmQpCiB7Ci0gICAgQ1BVU3Rh
dGUgKmNwdTsKKyAgICBDUFVTdGF0ZSAqY3M7CisgICAgWDg2Q1BVICpjcHU7CiAKICAgICBpZiAo
KHVpbnQzMl90KUVDWCAhPSAwKSB7CiAgICAgICAgIHJhaXNlX2V4Y2VwdGlvbihlbnYsIEVYQ1Aw
RF9HUEYpOwpAQCAtNTg4LDEzICs1OTQsMTQgQEAgdm9pZCBoZWxwZXJfbXdhaXQoQ1BVWDg2U3Rh
dGUgKmVudiwgaW50IG5leHRfZWlwX2FkZGVuZCkKICAgICBjcHVfc3ZtX2NoZWNrX2ludGVyY2Vw
dF9wYXJhbShlbnYsIFNWTV9FWElUX01XQUlULCAwKTsKICAgICBFSVAgKz0gbmV4dF9laXBfYWRk
ZW5kOwogCi0gICAgY3B1ID0gQ1BVKHg4Nl9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICBjcHUgPSB4
ODZfZW52X2dldF9jcHUoZW52KTsKKyAgICBjcyA9IENQVShjcHUpOwogICAgIC8qIFhYWDogbm90
IGNvbXBsZXRlIGJ1dCBub3QgY29tcGxldGVseSBlcnJvbmVvdXMgKi8KLSAgICBpZiAoY3B1LT5j
cHVfaW5kZXggIT0gMCB8fCBlbnYtPm5leHRfY3B1ICE9IE5VTEwpIHsKKyAgICBpZiAoY3MtPmNw
dV9pbmRleCAhPSAwIHx8IGVudi0+bmV4dF9jcHUgIT0gTlVMTCkgewogICAgICAgICAvKiBtb3Jl
IHRoYW4gb25lIENQVTogZG8gbm90IHNsZWVwIGJlY2F1c2UgYW5vdGhlciBDUFUgbWF5CiAgICAg
ICAgICAgIHdha2UgdGhpcyBvbmUgKi8KICAgICB9IGVsc2UgewotICAgICAgICBkb19obHQoZW52
KTsKKyAgICAgICAgZG9faGx0KGNwdSk7CiAgICAgfQogfQogCmRpZmYgLS1naXQgYS90YXJnZXQt
aTM4Ni9zdm1faGVscGVyLmMgYi90YXJnZXQtaTM4Ni9zdm1faGVscGVyLmMKaW5kZXggM2YyNDZl
OS4uYzQ2YTIxMyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvc3ZtX2hlbHBlci5jCisrKyBiL3Rh
cmdldC1pMzg2L3N2bV9oZWxwZXIuYwpAQCAtMjcxLDcgKzI3MSw5IEBAIHZvaWQgaGVscGVyX3Zt
cnVuKENQVVg4NlN0YXRlICplbnYsIGludCBhZmxhZywgaW50IG5leHRfZWlwX2FkZGVuZCkKICAg
ICBlbnYtPmhmbGFnczIgfD0gSEYyX0dJRl9NQVNLOwogCiAgICAgaWYgKGludF9jdGwgJiBWX0lS
UV9NQVNLKSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQ
VF9WSVJROworICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoeDg2X2Vudl9nZXRfY3B1KGVudikp
OworCisgICAgICAgIGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX1ZJUlE7
CiAgICAgfQogCiAgICAgLyogbWF5YmUgd2UgbmVlZCB0byBpbmplY3QgYW4gZXZlbnQgKi8KQEAg
LTU0OCw2ICs1NTAsNyBAQCB2b2lkIGhlbHBlcl9zdm1fY2hlY2tfaW8oQ1BVWDg2U3RhdGUgKmVu
diwgdWludDMyX3QgcG9ydCwgdWludDMyX3QgcGFyYW0sCiAvKiBOb3RlOiBjdXJyZW50bHkgb25s
eSAzMiBiaXRzIG9mIGV4aXRfY29kZSBhcmUgdXNlZCAqLwogdm9pZCBoZWxwZXJfdm1leGl0KENQ
VVg4NlN0YXRlICplbnYsIHVpbnQzMl90IGV4aXRfY29kZSwgdWludDY0X3QgZXhpdF9pbmZvXzEp
CiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHg4Nl9lbnZfZ2V0X2NwdShlbnYpKTsKICAgICB1
aW50MzJfdCBpbnRfY3RsOwogCiAgICAgcWVtdV9sb2dfbWFzayhDUFVfTE9HX1RCX0lOX0FTTSwg
InZtZXhpdCglMDh4LCAlMDE2IiBQUkl4NjQgIiwgJTAxNiIKQEAgLTU5NCw3ICs1OTcsNyBAQCB2
b2lkIGhlbHBlcl92bWV4aXQoQ1BVWDg2U3RhdGUgKmVudiwgdWludDMyX3QgZXhpdF9jb2RlLCB1
aW50NjRfdCBleGl0X2luZm9fMSkKICAgICBpbnRfY3RsID0gbGRsX3BoeXMoZW52LT52bV92bWNi
ICsgb2Zmc2V0b2Yoc3RydWN0IHZtY2IsIGNvbnRyb2wuaW50X2N0bCkpOwogICAgIGludF9jdGwg
Jj0gfihWX1RQUl9NQVNLIHwgVl9JUlFfTUFTSyk7CiAgICAgaW50X2N0bCB8PSBlbnYtPnZfdHBy
ICYgVl9UUFJfTUFTSzsKLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRF
UlJVUFRfVklSUSkgeworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX1ZJUlEpIHsKICAgICAgICAgaW50X2N0bCB8PSBWX0lSUV9NQVNLOwogICAgIH0KICAgICBz
dGxfcGh5cyhlbnYtPnZtX3ZtY2IgKyBvZmZzZXRvZihzdHJ1Y3Qgdm1jYiwgY29udHJvbC5pbnRf
Y3RsKSwgaW50X2N0bCk7CkBAIC02MTUsNyArNjE4LDcgQEAgdm9pZCBoZWxwZXJfdm1leGl0KENQ
VVg4NlN0YXRlICplbnYsIHVpbnQzMl90IGV4aXRfY29kZSwgdWludDY0X3QgZXhpdF9pbmZvXzEp
CiAgICAgZW52LT5oZmxhZ3MgJj0gfkhGX1NWTUlfTUFTSzsKICAgICBlbnYtPmludGVyY2VwdCA9
IDA7CiAgICAgZW52LT5pbnRlcmNlcHRfZXhjZXB0aW9ucyA9IDA7Ci0gICAgZW52LT5pbnRlcnJ1
cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9WSVJROworICAgIGNzLT5pbnRlcnJ1cHRfcmVx
dWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9WSVJROwogICAgIGVudi0+dHNjX29mZnNldCA9IDA7CiAK
ICAgICBlbnYtPmdkdC5iYXNlICA9IGxkcV9waHlzKGVudi0+dm1faHNhdmUgKyBvZmZzZXRvZihz
dHJ1Y3Qgdm1jYiwKZGlmZiAtLWdpdCBhL3RhcmdldC1sbTMyL2NwdS5oIGIvdGFyZ2V0LWxtMzIv
Y3B1LmgKaW5kZXggNjk0OGQwZS4uZDgxZjEwMyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWxtMzIvY3B1
LmgKKysrIGIvdGFyZ2V0LWxtMzIvY3B1LmgKQEAgLTI1NCw5ICsyNTQsNyBAQCBzdGF0aWMgaW5s
aW5lIHZvaWQgY3B1X2dldF90Yl9jcHVfc3RhdGUoQ1BVTE0zMlN0YXRlICplbnYsIHRhcmdldF91
bG9uZyAqcGMsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNw
dSkKIHsKLSAgICBDUFVMTTMyU3RhdGUgKmVudiA9ICZMTTMyX0NQVShjcHUpLT5lbnY7Ci0KLSAg
ICByZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKKyAg
ICByZXR1cm4gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKIH0K
IAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3RhcmdldC1sbTMyL29w
X2hlbHBlci5jIGIvdGFyZ2V0LWxtMzIvb3BfaGVscGVyLmMKaW5kZXggNTM0MTBiMS4uZWJjOTRh
MCAxMDA2NDQKLS0tIGEvdGFyZ2V0LWxtMzIvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LWxtMzIv
b3BfaGVscGVyLmMKQEAgLTI1LDcgKzI1LDkgQEAgdm9pZCBoZWxwZXJfcmFpc2VfZXhjZXB0aW9u
KENQVUxNMzJTdGF0ZSAqZW52LCB1aW50MzJfdCBpbmRleCkKIAogdm9pZCBoZWxwZXJfaGx0KENQ
VUxNMzJTdGF0ZSAqZW52KQogewotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUobG0zMl9lbnZfZ2V0X2NwdShlbnYpKTsKKworICAgIGNzLT5oYWx0ZWQgPSAxOwog
ICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiAgICAgY3B1X2xvb3BfZXhpdChl
bnYpOwogfQpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvY3B1LmggYi90YXJnZXQtbTY4ay9jcHUu
aAppbmRleCAyNjcyZWFlLi5iYjJmYmQ2IDEwMDY0NAotLS0gYS90YXJnZXQtbTY4ay9jcHUuaAor
KysgYi90YXJnZXQtbTY4ay9jcHUuaApAQCAtMjY1LDkgKzI2NSw3IEBAIHN0YXRpYyBpbmxpbmUg
dm9pZCBjcHVfZ2V0X3RiX2NwdV9zdGF0ZShDUFVNNjhLU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25n
ICpwYywKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQog
ewotICAgIENQVU02OEtTdGF0ZSAqZW52ID0gJk02OEtfQ1BVKGNwdSktPmVudjsKLQotICAgIHJl
dHVybiBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOworICAgIHJl
dHVybiBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOwogfQogCiAj
aW5jbHVkZSAiZXhlYy9leGVjLWFsbC5oIgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvb3BfaGVs
cGVyLmMgYi90YXJnZXQtbTY4ay9vcF9oZWxwZXIuYwppbmRleCAxNmRmMjRjLi5lMTFmMzRiIDEw
MDY0NAotLS0gYS90YXJnZXQtbTY4ay9vcF9oZWxwZXIuYworKysgYi90YXJnZXQtbTY4ay9vcF9o
ZWxwZXIuYwpAQCAtODQsNiArODQsNyBAQCBzdGF0aWMgdm9pZCBkb19ydGUoQ1BVTTY4S1N0YXRl
ICplbnYpCiAKIHN0YXRpYyB2b2lkIGRvX2ludGVycnVwdF9hbGwoQ1BVTTY4S1N0YXRlICplbnYs
IGludCBpc19odykKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAgdWludDMyX3Qgc3A7CiAgICAg
dWludDMyX3QgZm10OwogICAgIHVpbnQzMl90IHJldGFkZHI7CkBAIC0xMDgsNyArMTA5LDggQEAg
c3RhdGljIHZvaWQgZG9faW50ZXJydXB0X2FsbChDUFVNNjhLU3RhdGUgKmVudiwgaW50IGlzX2h3
KQogICAgICAgICAgICAgICAgIGRvX202OGtfc2VtaWhvc3RpbmcoZW52LCBlbnYtPmRyZWdzWzBd
KTsKICAgICAgICAgICAgICAgICByZXR1cm47CiAgICAgICAgICAgICB9Ci0gICAgICAgICAgICBl
bnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICBjcyA9IENQVShtNjhrX2Vudl9nZXRfY3B1KGVu
dikpOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICBlbnYtPmV4Y2Vw
dGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgICAgICAgICAgY3B1X2xvb3BfZXhpdChlbnYpOwog
ICAgICAgICAgICAgcmV0dXJuOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvcXJlZ3MuZGVmIGIv
dGFyZ2V0LW02OGsvcXJlZ3MuZGVmCmluZGV4IDQ5NDAwYzQuLjQyMzViMDIgMTAwNjQ0Ci0tLSBh
L3RhcmdldC1tNjhrL3FyZWdzLmRlZgorKysgYi90YXJnZXQtbTY4ay9xcmVncy5kZWYKQEAgLTgs
NiArOCw1IEBAIERFRk8zMihDQ19YLCBjY194KQogREVGTzMyKERJVjEsIGRpdjEpCiBERUZPMzIo
RElWMiwgZGl2MikKIERFRk8zMihFWENFUFRJT04sIGV4Y2VwdGlvbl9pbmRleCkKLURFRk8zMihI
QUxURUQsIGhhbHRlZCkKIERFRk8zMihNQUNTUiwgbWFjc3IpCiBERUZPMzIoTUFDX01BU0ssIG1h
Y19tYXNrKQpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvdHJhbnNsYXRlLmMgYi90YXJnZXQtbTY4
ay90cmFuc2xhdGUuYwppbmRleCBlNzYzMTk1Li5hYWJkMmQ5IDEwMDY0NAotLS0gYS90YXJnZXQt
bTY4ay90cmFuc2xhdGUuYworKysgYi90YXJnZXQtbTY4ay90cmFuc2xhdGUuYwpAQCAtNDIsNiAr
NDIsOCBAQAogI3VuZGVmIERFRk82NAogI3VuZGVmIERFRkY2NAogCitzdGF0aWMgVENHdl9pMzIg
Y3B1X2hhbHRlZDsKKwogc3RhdGljIFRDR3ZfcHRyIGNwdV9lbnY7CiAKIHN0YXRpYyBjaGFyIGNw
dV9yZWdfbmFtZXNbMyo4KjMgKyA1KjRdOwpAQCAtNzYsNiArNzgsMTAgQEAgdm9pZCBtNjhrX3Rj
Z19pbml0KHZvaWQpCiAjdW5kZWYgREVGTzY0CiAjdW5kZWYgREVGRjY0CiAKKyAgICBjcHVfaGFs
dGVkID0gdGNnX2dsb2JhbF9tZW1fbmV3X2kzMihUQ0dfQVJFRzAsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLW9mZnNldG9mKE02OGtDUFUsIGVudikgKworICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mZnNldG9mKENQVVN0YXRlLCBoYWx0
ZWQpLCAiSEFMVEVEIik7CisKICAgICBjcHVfZW52ID0gdGNnX2dsb2JhbF9yZWdfbmV3X3B0cihU
Q0dfQVJFRzAsICJlbnYiKTsKIAogICAgIHAgPSBjcHVfcmVnX25hbWVzOwpAQCAtMjAyNCw3ICsy
MDMwLDcgQEAgRElTQVNfSU5TTihzdG9wKQogICAgIHMtPnBjICs9IDI7CiAKICAgICBnZW5fc2V0
X3NyX2ltKHMsIGV4dCwgMCk7Ci0gICAgdGNnX2dlbl9tb3ZpX2kzMihRUkVHX0hBTFRFRCwgMSk7
CisgICAgdGNnX2dlbl9tb3ZpX2kzMihjcHVfaGFsdGVkLCAxKTsKICAgICBnZW5fZXhjZXB0aW9u
KHMsIHMtPnBjLCBFWENQX0hMVCk7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC1taWNyb2JsYXpl
L2NwdS5oIGIvdGFyZ2V0LW1pY3JvYmxhemUvY3B1LmgKaW5kZXggYzNkZDdmNi4uNzU0OGFhOSAx
MDA2NDQKLS0tIGEvdGFyZ2V0LW1pY3JvYmxhemUvY3B1LmgKKysrIGIvdGFyZ2V0LW1pY3JvYmxh
emUvY3B1LmgKQEAgLTM3NCw5ICszNzQsNyBAQCB2b2lkIGNwdV91bmFzc2lnbmVkX2FjY2VzcyhD
UFVNQlN0YXRlICplbnYxLCBod2FkZHIgYWRkciwKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9o
YXNfd29yayhDUFVTdGF0ZSAqY3B1KQogewotICAgIENQVU1CU3RhdGUgKmVudiA9ICZNSUNST0JM
QVpFX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IChDUFVfSU5URVJSVVBUX0hBUkQgfCBDUFVfSU5URVJSVVBUX05NSSk7CisgICAgcmV0dXJuIGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQ
VF9OTUkpOwogfQogCiAjaW5jbHVkZSAiZXhlYy9leGVjLWFsbC5oIgpkaWZmIC0tZ2l0IGEvdGFy
Z2V0LW1pcHMvY3B1LmggYi90YXJnZXQtbWlwcy9jcHUuaAppbmRleCAwZTE5OGIxLi43NDM0MDk5
IDEwMDY0NAotLS0gYS90YXJnZXQtbWlwcy9jcHUuaAorKysgYi90YXJnZXQtbWlwcy9jcHUuaApA
QCAtNzE5LDcgKzcxOSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3Rh
dGUgKmNwdSkKICAgICAvKiBJdCBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgaWYgbm9uLWVu
YWJsZWQgaW50ZXJydXB0cwogICAgICAgIHdha2UtdXAgdGhlIENQVSwgaG93ZXZlciBtb3N0IG9m
IHRoZSBpbXBsZW1lbnRhdGlvbnMgb25seQogICAgICAgIGNoZWNrIGZvciBpbnRlcnJ1cHRzIHRo
YXQgY2FuIGJlIHRha2VuLiAqLwotICAgIGlmICgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQ
VV9JTlRFUlJVUFRfSEFSRCkgJiYKKyAgICBpZiAoKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBD
UFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAgICAgIGNwdV9taXBzX2h3X2ludGVycnVwdHNfcGVu
ZGluZyhlbnYpKSB7CiAgICAgICAgIGhhc193b3JrID0gdHJ1ZTsKICAgICB9CkBAIC03MjgsNyAr
NzI4LDcgQEAgc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQog
ICAgIGlmIChlbnYtPkNQMF9Db25maWczICYgKDEgPDwgQ1AwQzNfTVQpKSB7CiAgICAgICAgIC8q
IFRoZSBRRU1VIG1vZGVsIHdpbGwgaXNzdWUgYW4gX1dBS0UgcmVxdWVzdCB3aGVuZXZlciB0aGUg
Q1BVcwogICAgICAgICAgICBzaG91bGQgYmUgd29rZW4gdXAuICAqLwotICAgICAgICBpZiAoZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfV0FLRSkgeworICAgICAgICBpZiAo
Y3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfV0FLRSkgewogICAgICAgICAg
ICAgaGFzX3dvcmsgPSB0cnVlOwogICAgICAgICB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC1taXBz
L29wX2hlbHBlci5jIGIvdGFyZ2V0LW1pcHMvb3BfaGVscGVyLmMKaW5kZXggNTI2Zjg0Zi4uNzk5
MmYwZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LW1pcHMvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LW1p
cHMvb3BfaGVscGVyLmMKQEAgLTUyNywxMSArNTI3LDEyIEBAIHZvaWQgaGVscGVyX3NkbShDUFVN
SVBTU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIGFkZHIsIHRhcmdldF91bG9uZyByZWdsaXN0LAog
LyogU01QIGhlbHBlcnMuICAqLwogc3RhdGljIGJvb2wgbWlwc192cGVfaXNfd2ZpKE1JUFNDUFUg
KmMpCiB7CisgICAgQ1BVU3RhdGUgKmNwdSA9IENQVShjKTsKICAgICBDUFVNSVBTU3RhdGUgKmVu
diA9ICZjLT5lbnY7CiAKICAgICAvKiBJZiB0aGUgVlBFIGlzIGhhbHRlZCBidXQgb3RoZXJ3aXNl
IGFjdGl2ZSwgaXQgbWVhbnMgaXQncyB3YWl0aW5nIGZvcgogICAgICAgIGFuIGludGVycnVwdC4g
ICovCi0gICAgcmV0dXJuIGVudi0+aGFsdGVkICYmIG1pcHNfdnBlX2FjdGl2ZShlbnYpOworICAg
IHJldHVybiBjcHUtPmhhbHRlZCAmJiBtaXBzX3ZwZV9hY3RpdmUoZW52KTsKIH0KIAogc3RhdGlj
IGlubGluZSB2b2lkIG1pcHNfdnBlX3dha2UoQ1BVTUlQU1N0YXRlICpjKQpAQCAtNTQ0LDExICs1
NDUsMTIgQEAgc3RhdGljIGlubGluZSB2b2lkIG1pcHNfdnBlX3dha2UoQ1BVTUlQU1N0YXRlICpj
KQogCiBzdGF0aWMgaW5saW5lIHZvaWQgbWlwc192cGVfc2xlZXAoTUlQU0NQVSAqY3B1KQogewor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVU1JUFNTdGF0ZSAqYyA9ICZjcHUt
PmVudjsKIAogICAgIC8qIFRoZSBWUEUgd2FzIHNodXQgb2ZmLCByZWFsbHkgZ28gdG8gYmVkLgog
ICAgICAgIFJlc2V0IGFueSBvbGQgX1dBS0UgcmVxdWVzdHMuICAqLwotICAgIGMtPmhhbHRlZCA9
IDE7CisgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgY3B1X3Jlc2V0X2ludGVycnVwdChjLCBDUFVf
SU5URVJSVVBUX1dBS0UpOwogfQogCkBAIC0yMTExLDcgKzIxMTMsOSBAQCB2b2lkIGhlbHBlcl9w
bW9uKENQVU1JUFNTdGF0ZSAqZW52LCBpbnQgZnVuY3Rpb24pCiAKIHZvaWQgaGVscGVyX3dhaXQo
Q1BVTUlQU1N0YXRlICplbnYpCiB7Ci0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIENQVVN0YXRl
ICpjcyA9IENQVShtaXBzX2Vudl9nZXRfY3B1KGVudikpOworCisgICAgY3MtPmhhbHRlZCA9IDE7
CiAgICAgY3B1X3Jlc2V0X2ludGVycnVwdChlbnYsIENQVV9JTlRFUlJVUFRfV0FLRSk7CiAgICAg
aGVscGVyX3JhaXNlX2V4Y2VwdGlvbihlbnYsIEVYQ1BfSExUKTsKIH0KZGlmZiAtLWdpdCBhL3Rh
cmdldC1taXBzL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMKaW5kZXggNGVl
OTYxNS4uNWNkMzEyNCAxMDA2NDQKLS0tIGEvdGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMKKysrIGIv
dGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMKQEAgLTE2MDIwLDcgKzE2MDIwLDcgQEAgdm9pZCBjcHVf
c3RhdGVfcmVzZXQoQ1BVTUlQU1N0YXRlICplbnYpCiAgICAgICAgICAgICBlbnYtPnRjc1tpXS5D
UDBfVENIYWx0ID0gMTsKICAgICAgICAgfQogICAgICAgICBlbnYtPmFjdGl2ZV90Yy5DUDBfVENI
YWx0ID0gMTsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICBjcy0+aGFsdGVkID0g
MTsKIAogICAgICAgICBpZiAoY3MtPmNwdV9pbmRleCA9PSAwKSB7CiAgICAgICAgICAgICAvKiBW
UEUwIHN0YXJ0cyB1cCBlbmFibGVkLiAgKi8KQEAgLTE2MDI4LDcgKzE2MDI4LDcgQEAgdm9pZCBj
cHVfc3RhdGVfcmVzZXQoQ1BVTUlQU1N0YXRlICplbnYpCiAgICAgICAgICAgICBlbnYtPkNQMF9W
UEVDb25mMCB8PSAoMSA8PCBDUDBWUEVDMF9NVlApIHwgKDEgPDwgQ1AwVlBFQzBfVlBBKTsKIAog
ICAgICAgICAgICAgLyogVEMwIHN0YXJ0cyB1cCB1bmhhbHRlZC4gICovCi0gICAgICAgICAgICBl
bnYtPmhhbHRlZCA9IDA7CisgICAgICAgICAgICBjcy0+aGFsdGVkID0gMDsKICAgICAgICAgICAg
IGVudi0+YWN0aXZlX3RjLkNQMF9UQ0hhbHQgPSAwOwogICAgICAgICAgICAgZW52LT50Y3NbMF0u
Q1AwX1RDSGFsdCA9IDA7CiAgICAgICAgICAgICAvKiBXaXRoIHRocmVhZCAwIGFjdGl2ZS4gICov
CmRpZmYgLS1naXQgYS90YXJnZXQtb3BlbnJpc2MvY3B1LmggYi90YXJnZXQtb3BlbnJpc2MvY3B1
LmgKaW5kZXggNDE5ZjAwNy4uNjg3YzI0ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LW9wZW5yaXNjL2Nw
dS5oCisrKyBiL3RhcmdldC1vcGVucmlzYy9jcHUuaApAQCAtNDIxLDkgKzQyMSw3IEBAIHN0YXRp
YyBpbmxpbmUgaW50IGNwdV9tbXVfaW5kZXgoQ1BVT3BlblJJU0NTdGF0ZSAqZW52KQogI2RlZmlu
ZSBDUFVfSU5URVJSVVBUX1RJTUVSICAgQ1BVX0lOVEVSUlVQVF9UR1RfSU5UXzAKIHN0YXRpYyBp
bmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVPcGVuUklT
Q1N0YXRlICplbnYgPSAmT1BFTlJJU0NfQ1BVKGNwdSktPmVudjsKLQotICAgIHJldHVybiBlbnYt
PmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8CisgICAgcmV0dXJuIGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX1RJTUVSKTsKIH0KIApkaWZm
IC0tZ2l0IGEvdGFyZ2V0LW9wZW5yaXNjL2ludGVycnVwdF9oZWxwZXIuYyBiL3RhcmdldC1vcGVu
cmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMKaW5kZXggYTE3NjQ0MS4uODQ0NjQ4ZiAxMDA2NDQKLS0t
IGEvdGFyZ2V0LW9wZW5yaXNjL2ludGVycnVwdF9oZWxwZXIuYworKysgYi90YXJnZXQtb3BlbnJp
c2MvaW50ZXJydXB0X2hlbHBlci5jCkBAIC0yNCw2ICsyNCw3IEBACiB2b2lkIEhFTFBFUihyZmUp
KENQVU9wZW5SSVNDU3RhdGUgKmVudikKIHsKICAgICBPcGVuUklTQ0NQVSAqY3B1ID0gb3BlbnJp
c2NfZW52X2dldF9jcHUoZW52KTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICNpZm5k
ZWYgQ09ORklHX1VTRVJfT05MWQogICAgIGludCBuZWVkX2ZsdXNoX3RsYiA9IChjcHUtPmVudi5z
ciAmIChTUl9TTSB8IFNSX0lNRSB8IFNSX0RNRSkpIF4KICAgICAgICAgICAgICAgICAgICAgICAg
ICAoY3B1LT5lbnYuZXNyICYgKFNSX1NNIHwgU1JfSU1FIHwgU1JfRE1FKSk7CkBAIC01Myw1ICs1
NCw1IEBAIHZvaWQgSEVMUEVSKHJmZSkoQ1BVT3BlblJJU0NTdGF0ZSAqZW52KQogICAgICAgICB0
bGJfZmx1c2goJmNwdS0+ZW52LCAxKTsKICAgICB9CiAjZW5kaWYKLSAgICBjcHUtPmVudi5pbnRl
cnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICBjcy0+aW50ZXJydXB0
X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiB9CmRpZmYgLS1naXQgYS90YXJnZXQt
b3BlbnJpc2Mvc3lzX2hlbHBlci5jIGIvdGFyZ2V0LW9wZW5yaXNjL3N5c19oZWxwZXIuYwppbmRl
eCAzYzVmNDVhLi5jY2NiYzBlIDEwMDY0NAotLS0gYS90YXJnZXQtb3BlbnJpc2Mvc3lzX2hlbHBl
ci5jCisrKyBiL3RhcmdldC1vcGVucmlzYy9zeXNfaGVscGVyLmMKQEAgLTMxLDYgKzMxLDcgQEAg
dm9pZCBIRUxQRVIobXRzcHIpKENQVU9wZW5SSVNDU3RhdGUgKmVudiwKICAgICBpbnQgaWR4Owog
CiAgICAgT3BlblJJU0NDUFUgKmNwdSA9IG9wZW5yaXNjX2Vudl9nZXRfY3B1KGVudik7CisgICAg
Q1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAKICAgICBzd2l0Y2ggKHNwcikgewogICAgIGNhc2Ug
VE9fU1BSKDAsIDApOiAvKiBWUiAqLwpAQCAtMTMyLDcgKzEzMyw3IEBAIHZvaWQgSEVMUEVSKG10
c3ByKShDUFVPcGVuUklTQ1N0YXRlICplbnYsCiAgICAgICAgICAgICAgICAgZW52LT50dG1yID0g
KHJiICYgflRUTVJfSVApICsgaXA7CiAgICAgICAgICAgICB9IGVsc2UgeyAgICAvKiBDbGVhciBJ
UCBiaXQuICAqLwogICAgICAgICAgICAgICAgIGVudi0+dHRtciA9IHJiICYgflRUTVJfSVA7Ci0g
ICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9U
SU1FUjsKKyAgICAgICAgICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRF
UlJVUFRfVElNRVI7CiAgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIGNwdV9vcGVucmlzY19j
b3VudF91cGRhdGUoY3B1KTsKZGlmZiAtLWdpdCBhL3RhcmdldC1wcGMvY3B1LmggYi90YXJnZXQt
cHBjL2NwdS5oCmluZGV4IDhjMDgxZGIuLjc1MTkwZjMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1wcGMv
Y3B1LmgKKysrIGIvdGFyZ2V0LXBwYy9jcHUuaApAQCAtMjIxNSw5ICsyMjE1LDEwIEBAIGV4dGVy
biB2b2lkICgqY3B1X3BwY19oeXBlcmNhbGwpKFBvd2VyUENDUFUgKik7CiAKIHN0YXRpYyBpbmxp
bmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVQUENTdGF0ZSAq
ZW52ID0gJlBPV0VSUENfQ1BVKGNwdSktPmVudjsKKyAgICBQb3dlclBDQ1BVICpwcGNfY3B1ID0g
UE9XRVJQQ19DUFUoY3B1KTsKKyAgICBDUFVQUENTdGF0ZSAqZW52ID0gJnBwY19jcHUtPmVudjsK
IAotICAgIHJldHVybiBtc3JfZWUgJiYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5U
RVJSVVBUX0hBUkQpOworICAgIHJldHVybiBtc3JfZWUgJiYgKGNwdS0+aW50ZXJydXB0X3JlcXVl
c3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpOwogfQogCiAjaW5jbHVkZSAiZXhlYy9leGVjLWFsbC5o
IgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXBwYy9leGNwX2hlbHBlci5jIGIvdGFyZ2V0LXBwYy9leGNw
X2hlbHBlci5jCmluZGV4IDBhMWFjODYuLjc5Y2U3YmYgMTAwNjQ0Ci0tLSBhL3RhcmdldC1wcGMv
ZXhjcF9oZWxwZXIuYworKysgYi90YXJnZXQtcHBjL2V4Y3BfaGVscGVyLmMKQEAgLTY2LDYgKzY2
LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGR1bXBfc3lzY2FsbChDUFVQUENTdGF0ZSAqZW52KQog
c3RhdGljIGlubGluZSB2b2lkIHBvd2VycGNfZXhjcChQb3dlclBDQ1BVICpjcHUsIGludCBleGNw
X21vZGVsLCBpbnQgZXhjcCkKIHsKICAgICBDUFVQUENTdGF0ZSAqZW52ID0gJmNwdS0+ZW52Owor
ICAgIENQVVN0YXRlICpjczsKICAgICB0YXJnZXRfdWxvbmcgbXNyLCBuZXdfbXNyLCB2ZWN0b3I7
CiAgICAgaW50IHNycjAsIHNycjEsIGFzcnIwLCBhc3JyMTsKICAgICBpbnQgbHBlczAsIGxwZXMx
LCBsZXY7CkBAIC0xMzEsOCArMTMyLDkgQEAgc3RhdGljIGlubGluZSB2b2lkIHBvd2VycGNfZXhj
cChQb3dlclBDQ1BVICpjcHUsIGludCBleGNwX21vZGVsLCBpbnQgZXhjcCkKICAgICAgICAgICAg
ICAgICBmcHJpbnRmKHN0ZGVyciwgIk1hY2hpbmUgY2hlY2sgd2hpbGUgbm90IGFsbG93ZWQuICIK
ICAgICAgICAgICAgICAgICAgICAgICAgICJFbnRlcmluZyBjaGVja3N0b3Agc3RhdGVcbiIpOwog
ICAgICAgICAgICAgfQotICAgICAgICAgICAgZW52LT5oYWx0ZWQgPSAxOwotICAgICAgICAgICAg
ZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICAgICAg
ICAgIGNzID0gQ1BVKGNwdSk7CisgICAgICAgICAgICBjcy0+aGFsdGVkID0gMTsKKyAgICAgICAg
ICAgIGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKICAgICAg
ICAgfQogICAgICAgICBpZiAoMCkgewogICAgICAgICAgICAgLyogWFhYOiBmaW5kIGEgc3VpdGFi
bGUgY29uZGl0aW9uIHRvIGVuYWJsZSB0aGUgaHlwZXJ2aXNvciBtb2RlICovCkBAIC02NjMsMTEg
KzY2NSwxMiBAQCB2b2lkIHBwY19od19pbnRlcnJ1cHQoQ1BVUFBDU3RhdGUgKmVudikKIHsKICAg
ICBQb3dlclBDQ1BVICpjcHUgPSBwcGNfZW52X2dldF9jcHUoZW52KTsKICAgICBpbnQgaGRpY2U7
Ci0KICNpZiAwCisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CisKICAgICBxZW11X2xvZ19t
YXNrKENQVV9MT0dfSU5ULCAiJXM6ICVwIHBlbmRpbmcgJTA4eCByZXEgJTA4eCBtZSAlZCBlZSAl
ZFxuIiwKLSAgICAgICAgICAgICAgICBfX2Z1bmNfXywgZW52LCBlbnYtPnBlbmRpbmdfaW50ZXJy
dXB0cywKLSAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0LCAoaW50KW1zcl9t
ZSwgKGludCltc3JfZWUpOworICAgICAgICAgICAgICAgICAgX19mdW5jX18sIGVudiwgZW52LT5w
ZW5kaW5nX2ludGVycnVwdHMsCisgICAgICAgICAgICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVl
c3QsIChpbnQpbXNyX21lLCAoaW50KW1zcl9lZSk7CiAjZW5kaWYKICAgICAvKiBFeHRlcm5hbCBy
ZXNldCAqLwogICAgIGlmIChlbnYtPnBlbmRpbmdfaW50ZXJydXB0cyAmICgxIDw8IFBQQ19JTlRF
UlJVUFRfUkVTRVQpKSB7CkBAIC04MDcsOSArODEwLDEyIEBAIHZvaWQgaGVscGVyX3JhaXNlX2V4
Y2VwdGlvbihDUFVQUENTdGF0ZSAqZW52LCB1aW50MzJfdCBleGNlcHRpb24pCiAjaWYgIWRlZmlu
ZWQoQ09ORklHX1VTRVJfT05MWSkKIHZvaWQgaGVscGVyX3N0b3JlX21zcihDUFVQUENTdGF0ZSAq
ZW52LCB0YXJnZXRfdWxvbmcgdmFsKQogeworICAgIENQVVN0YXRlICpjczsKKwogICAgIHZhbCA9
IGhyZWdfc3RvcmVfbXNyKGVudiwgdmFsLCAwKTsKICAgICBpZiAodmFsICE9IDApIHsKLSAgICAg
ICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICAg
ICAgY3MgPSBDUFUocHBjX2Vudl9nZXRfY3B1KGVudikpOworICAgICAgICBjcy0+aW50ZXJydXB0
X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgICAgIGhlbHBlcl9yYWlzZV9l
eGNlcHRpb24oZW52LCB2YWwpOwogICAgIH0KIH0KQEAgLTgxNyw2ICs4MjMsOCBAQCB2b2lkIGhl
bHBlcl9zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIHZhbCkKIHN0YXRp
YyBpbmxpbmUgdm9pZCBkb19yZmkoQ1BVUFBDU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIG5pcCwg
dGFyZ2V0X3Vsb25nIG1zciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0X3Vsb25n
IG1zcm0sIGludCBrZWVwX21zcmgpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHBwY19lbnZf
Z2V0X2NwdShlbnYpKTsKKwogI2lmIGRlZmluZWQoVEFSR0VUX1BQQzY0KQogICAgIGlmIChtc3Jf
aXNfNjRiaXQoZW52LCBtc3IpKSB7CiAgICAgICAgIG5pcCA9ICh1aW50NjRfdCluaXA7CkBAIC04
NDEsNyArODQ5LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGRvX3JmaShDUFVQUENTdGF0ZSAqZW52
LCB0YXJnZXRfdWxvbmcgbmlwLCB0YXJnZXRfdWxvbmcgbXNyLAogICAgIC8qIE5vIG5lZWQgdG8g
cmFpc2UgYW4gZXhjZXB0aW9uIGhlcmUsCiAgICAgICogYXMgcmZpIGlzIGFsd2F5cyB0aGUgbGFz
dCBpbnNuIG9mIGEgVEIKICAgICAgKi8KLSAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQ
VV9JTlRFUlJVUFRfRVhJVFRCOworICAgIGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5U
RVJSVVBUX0VYSVRUQjsKIH0KIAogdm9pZCBoZWxwZXJfcmZpKENQVVBQQ1N0YXRlICplbnYpCmRp
ZmYgLS1naXQgYS90YXJnZXQtcHBjL2hlbHBlcl9yZWdzLmggYi90YXJnZXQtcHBjL2hlbHBlcl9y
ZWdzLmgKaW5kZXggM2M5ODg1MC4uYTZkNWUyZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LXBwYy9oZWxw
ZXJfcmVncy5oCisrKyBiL3RhcmdldC1wcGMvaGVscGVyX3JlZ3MuaApAQCAtNjgsMTAgKzY4LDEz
IEBAIHN0YXRpYyBpbmxpbmUgaW50IGhyZWdfc3RvcmVfbXNyKENQVVBQQ1N0YXRlICplbnYsIHRh
cmdldF91bG9uZyB2YWx1ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBh
bHRlcl9odikKIHsKICAgICBpbnQgZXhjcDsKKyNpZiAhZGVmaW5lZChDT05GSUdfVVNFUl9PTkxZ
KQorICAgIENQVVN0YXRlICpjcyA9IENQVShwcGNfZW52X2dldF9jcHUoZW52KSk7CisjZW5kaWYK
IAogICAgIGV4Y3AgPSAwOwogICAgIHZhbHVlICY9IGVudi0+bXNyX21hc2s7Ci0jaWYgIWRlZmlu
ZWQgKENPTkZJR19VU0VSX09OTFkpCisjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkKICAg
ICBpZiAoIWFsdGVyX2h2KSB7CiAgICAgICAgIC8qIG10bXNyIGNhbm5vdCBhbHRlciB0aGUgaHlw
ZXJ2aXNvciBzdGF0ZSAqLwogICAgICAgICB2YWx1ZSAmPSB+TVNSX0hWQjsKQEAgLTgyLDcgKzg1
LDcgQEAgc3RhdGljIGlubGluZSBpbnQgaHJlZ19zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVudiwg
dGFyZ2V0X3Vsb25nIHZhbHVlLAogICAgICAgICAvKiBGbHVzaCBhbGwgdGxiIHdoZW4gY2hhbmdp
bmcgdHJhbnNsYXRpb24gbW9kZSAqLwogICAgICAgICB0bGJfZmx1c2goZW52LCAxKTsKICAgICAg
ICAgZXhjcCA9IFBPV0VSUENfRVhDUF9OT05FOwotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVl
c3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgfQogICAgIGlmICh1bmxpa2VseSgoZW52
LT5mbGFncyAmIFBPV0VSUENfRkxBR19UR1BSKSAmJgogICAgICAgICAgICAgICAgICAoKHZhbHVl
IF4gZW52LT5tc3IpICYgKDEgPDwgTVNSX1RHUFIpKSkpIHsKQEAgLTk2LDEwICs5OSwxMCBAQCBz
dGF0aWMgaW5saW5lIGludCBocmVnX3N0b3JlX21zcihDUFVQUENTdGF0ZSAqZW52LCB0YXJnZXRf
dWxvbmcgdmFsdWUsCiAjZW5kaWYKICAgICBlbnYtPm1zciA9IHZhbHVlOwogICAgIGhyZWdfY29t
cHV0ZV9oZmxhZ3MoZW52KTsKLSNpZiAhZGVmaW5lZCAoQ09ORklHX1VTRVJfT05MWSkKKyNpZiAh
ZGVmaW5lZChDT05GSUdfVVNFUl9PTkxZKQogICAgIGlmICh1bmxpa2VseShtc3JfcG93ID09IDEp
KSB7CiAgICAgICAgIGlmICgoKmVudi0+Y2hlY2tfcG93KShlbnYpKSB7Ci0gICAgICAgICAgICBl
bnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgICAg
IGV4Y3AgPSBFWENQX0hBTFRFRDsKICAgICAgICAgfQogICAgIH0KZGlmZiAtLWdpdCBhL3Rhcmdl
dC1wcGMva3ZtLmMgYi90YXJnZXQtcHBjL2t2bS5jCmluZGV4IDJjNjRjNjMuLmVlOTM1ZDggMTAw
NjQ0Ci0tLSBhL3RhcmdldC1wcGMva3ZtLmMKKysrIGIvdGFyZ2V0LXBwYy9rdm0uYwpAQCAtNzYw
LDcgKzc2MCw3IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihDUFVTdGF0ZSAqY3MsIHN0cnVjdCBr
dm1fcnVuICpydW4pCiAgICAgICogaW50ZXJydXB0LCByZXNldCwgZXRjKSBpbiBQUEMtc3BlY2lm
aWMgZW52LT5pcnFfaW5wdXRfc3RhdGUuICovCiAgICAgaWYgKCFjYXBfaW50ZXJydXB0X2xldmVs
ICYmCiAgICAgICAgIHJ1bi0+cmVhZHlfZm9yX2ludGVycnVwdF9pbmplY3Rpb24gJiYKLSAgICAg
ICAgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCisgICAg
ICAgIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAg
ICAgIChlbnYtPmlycV9pbnB1dF9zdGF0ZSAmICgxPDxQUENfSU5QVVRfSU5UKSkpCiAgICAgewog
ICAgICAgICAvKiBGb3Igbm93IEtWTSBkaXNyZWdhcmRzIHRoZSAnaXJxJyBhcmd1bWVudC4gSG93
ZXZlciwgaW4gdGhlCkBAIC03OTEsMTQgKzc5MSwxNiBAQCB2b2lkIGt2bV9hcmNoX3Bvc3RfcnVu
KENQVVN0YXRlICpjcHUsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAKIGludCBrdm1fYXJjaF9wcm9j
ZXNzX2FzeW5jX2V2ZW50cyhDUFVTdGF0ZSAqY3MpCiB7Ci0gICAgUG93ZXJQQ0NQVSAqY3B1ID0g
UE9XRVJQQ19DUFUoY3MpOwotICAgIHJldHVybiBjcHUtPmVudi5oYWx0ZWQ7CisgICAgcmV0dXJu
IGNzLT5oYWx0ZWQ7CiB9CiAKLXN0YXRpYyBpbnQga3ZtcHBjX2hhbmRsZV9oYWx0KENQVVBQQ1N0
YXRlICplbnYpCitzdGF0aWMgaW50IGt2bXBwY19oYW5kbGVfaGFsdChQb3dlclBDQ1BVICpjcHUp
CiB7Ci0gICAgaWYgKCEoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFS
RCkgJiYgKG1zcl9lZSkpIHsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgIENQVVN0YXRl
ICpjcyA9IENQVShjcHUpOworICAgIENQVVBQQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CisKKyAg
ICBpZiAoIShjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmICht
c3JfZWUpKSB7CisgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgICAgICBlbnYtPmV4Y2VwdGlv
bl9pbmRleCA9IEVYQ1BfSExUOwogICAgIH0KIApAQCAtODQwLDcgKzg0Miw3IEBAIGludCBrdm1f
YXJjaF9oYW5kbGVfZXhpdChDUFVTdGF0ZSAqY3MsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAgICAg
ICAgIGJyZWFrOwogICAgIGNhc2UgS1ZNX0VYSVRfSExUOgogICAgICAgICBkcHJpbnRmKCJoYW5k
bGUgaGFsdFxuIik7Ci0gICAgICAgIHJldCA9IGt2bXBwY19oYW5kbGVfaGFsdChlbnYpOworICAg
ICAgICByZXQgPSBrdm1wcGNfaGFuZGxlX2hhbHQoY3B1KTsKICAgICAgICAgYnJlYWs7CiAjaWZk
ZWYgQ09ORklHX1BTRVJJRVMKICAgICBjYXNlIEtWTV9FWElUX1BBUFJfSENBTEw6CmRpZmYgLS1n
aXQgYS90YXJnZXQtcHBjL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LXBwYy90cmFuc2xhdGUuYwppbmRl
eCAyYWM1Nzk0Li40ZDUwMTk4IDEwMDY0NAotLS0gYS90YXJnZXQtcHBjL3RyYW5zbGF0ZS5jCisr
KyBiL3RhcmdldC1wcGMvdHJhbnNsYXRlLmMKQEAgLTMyNDMsNyArMzI0Myw4IEBAIHN0YXRpYyB2
b2lkIGdlbl9zeW5jKERpc2FzQ29udGV4dCAqY3R4KQogc3RhdGljIHZvaWQgZ2VuX3dhaXQoRGlz
YXNDb250ZXh0ICpjdHgpCiB7CiAgICAgVENHdl9pMzIgdDAgPSB0Y2dfdGVtcF9uZXdfaTMyKCk7
Ci0gICAgdGNnX2dlbl9zdF9pMzIodDAsIGNwdV9lbnYsIG9mZnNldG9mKENQVVBQQ1N0YXRlLCBo
YWx0ZWQpKTsKKyAgICB0Y2dfZ2VuX3N0X2kzMih0MCwgY3B1X2VudiwKKyAgICAgICAgICAgICAg
ICAgICAtb2Zmc2V0b2YoUG93ZXJQQ0NQVSwgZW52KSArIG9mZnNldG9mKENQVVN0YXRlLCBoYWx0
ZWQpKTsKICAgICB0Y2dfdGVtcF9mcmVlX2kzMih0MCk7CiAgICAgLyogU3RvcCB0cmFuc2xhdGlv
biwgYXMgdGhlIENQVSBpcyBzdXBwb3NlZCB0byBzbGVlcCBmcm9tIG5vdyAqLwogICAgIGdlbl9l
eGNlcHRpb25fZXJyKGN0eCwgRVhDUF9ITFQsIDEpOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXMzOTB4
L2NwdS5jIGIvdGFyZ2V0LXMzOTB4L2NwdS5jCmluZGV4IGI3NDY1NDcuLjczOGEwYWQgMTAwNjQ0
Ci0tLSBhL3RhcmdldC1zMzkweC9jcHUuYworKysgYi90YXJnZXQtczM5MHgvY3B1LmMKQEAgLTgw
LDEwICs4MCwxMCBAQCBzdGF0aWMgdm9pZCBzMzkwX2NwdV9yZXNldChDUFVTdGF0ZSAqcykKICAg
ICBlbnYtPmNyZWdzWzBdID0gQ1IwX1JFU0VUOwogICAgIGVudi0+Y3JlZ3NbMTRdID0gQ1IxNF9S
RVNFVDsKICAgICAvKiBzZXQgaGFsdGVkIHRvIDEgdG8gbWFrZSBzdXJlIHdlIGNhbiBhZGQgdGhl
IGNwdSBpbgotICAgICAqIHMzOTBfaXBsX2NwdSBjb2RlLCB3aGVyZSBlbnYtPmhhbHRlZCBpcyBz
ZXQgYmFjayB0byAwCisgICAgICogczM5MF9pcGxfY3B1IGNvZGUsIHdoZXJlIENQVVN0YXRlOjpo
YWx0ZWQgaXMgc2V0IGJhY2sgdG8gMAogICAgICAqIGFmdGVyIGluY3JlbWVudGluZyB0aGUgY3B1
IGNvdW50ZXIgKi8KICNpZiAhZGVmaW5lZChDT05GSUdfVVNFUl9PTkxZKQotICAgIGVudi0+aGFs
dGVkID0gMTsKKyAgICBzLT5oYWx0ZWQgPSAxOwogI2VuZGlmCiAgICAgdGxiX2ZsdXNoKGVudiwg
MSk7CiB9CkBAIC0xMjksMTAgKzEyOSwxMCBAQCBzdGF0aWMgdm9pZCBzMzkwX2NwdV9pbml0Zm4o
T2JqZWN0ICpvYmopCiAgICAgZW52LT50b2RfYmFzZXRpbWUgPSAwOwogICAgIGVudi0+dG9kX3Rp
bWVyID0gcWVtdV9uZXdfdGltZXJfbnModm1fY2xvY2ssIHMzOTB4X3RvZF90aW1lciwgY3B1KTsK
ICAgICBlbnYtPmNwdV90aW1lciA9IHFlbXVfbmV3X3RpbWVyX25zKHZtX2Nsb2NrLCBzMzkweF9j
cHVfdGltZXIsIGNwdSk7Ci0gICAgLyogc2V0IGVudi0+aGFsdGVkIHN0YXRlIHRvIDEgdG8gYXZv
aWQgZGVjcmVtZW50aW5nIHRoZSBydW5uaW5nCisgICAgLyogc2V0IENQVVN0YXRlOjpoYWx0ZWQg
c3RhdGUgdG8gMSB0byBhdm9pZCBkZWNyZW1lbnRpbmcgdGhlIHJ1bm5pbmcKICAgICAgKiBjcHUg
Y291bnRlciBpbiBzMzkwX2NwdV9yZXNldCB0byBhIG5lZ2F0aXZlIG51bWJlciBhdAogICAgICAq
IGluaXRpYWwgaXBsICovCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNzLT5oYWx0ZWQgPSAx
OwogI2VuZGlmCiAgICAgZW52LT5jcHVfbnVtID0gY3B1X251bSsrOwogICAgIGVudi0+ZXh0X2lu
ZGV4ID0gLTE7CmRpZmYgLS1naXQgYS90YXJnZXQtczM5MHgvY3B1LmggYi90YXJnZXQtczM5MHgv
Y3B1LmgKaW5kZXggMDA3MGM0MC4uZTY5OTdlZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LXMzOTB4L2Nw
dS5oCisrKyBiL3RhcmdldC1zMzkweC9jcHUuaApAQCAtMTAzOSw5ICsxMDM5LDEwIEBAIHN0YXRp
YyBpbmxpbmUgdm9pZCBjcHVfaW5qZWN0X2Nyd19tY2hrKFMzOTBDUFUgKmNwdSkKIAogc3RhdGlj
IGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQogewotICAgIENQVVMzOTBY
U3RhdGUgKmVudiA9ICZTMzkwX0NQVShjcHUpLT5lbnY7CisgICAgUzM5MENQVSAqczM5MF9jcHUg
PSBTMzkwX0NQVShjcHUpOworICAgIENQVVMzOTBYU3RhdGUgKmVudiA9ICZzMzkwX2NwdS0+ZW52
OwogCi0gICAgcmV0dXJuIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9I
QVJEKSAmJgorICAgIHJldHVybiAoY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJV
UFRfSEFSRCkgJiYKICAgICAgICAgKGVudi0+cHN3Lm1hc2sgJiBQU1dfTUFTS19FWFQpOwogfQog
CmRpZmYgLS1naXQgYS90YXJnZXQtczM5MHgvaGVscGVyLmMgYi90YXJnZXQtczM5MHgvaGVscGVy
LmMKaW5kZXggYmM2ZmM0Yy4uM2E1NDY1MSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXMzOTB4L2hlbHBl
ci5jCisrKyBiL3RhcmdldC1zMzkweC9oZWxwZXIuYwpAQCAtNDM3LDYgKzQzNyw3IEBAIHZvaWQg
bG9hZF9wc3coQ1BVUzM5MFhTdGF0ZSAqZW52LCB1aW50NjRfdCBtYXNrLCB1aW50NjRfdCBhZGRy
KQogewogICAgIGlmIChtYXNrICYgUFNXX01BU0tfV0FJVCkgewogICAgICAgICBTMzkwQ1BVICpj
cHUgPSBzMzkwX2Vudl9nZXRfY3B1KGVudik7CisgICAgICAgIENQVVN0YXRlICpjcyA9IENQVShj
cHUpOwogICAgICAgICBpZiAoIShtYXNrICYgKFBTV19NQVNLX0lPIHwgUFNXX01BU0tfRVhUIHwg
UFNXX01BU0tfTUNIRUNLKSkpIHsKICAgICAgICAgICAgIGlmIChzMzkwX2RlbF9ydW5uaW5nX2Nw
dShjcHUpID09IDApIHsKICNpZm5kZWYgQ09ORklHX1VTRVJfT05MWQpAQCAtNDQ0LDcgKzQ0NSw3
IEBAIHZvaWQgbG9hZF9wc3coQ1BVUzM5MFhTdGF0ZSAqZW52LCB1aW50NjRfdCBtYXNrLCB1aW50
NjRfdCBhZGRyKQogI2VuZGlmCiAgICAgICAgICAgICB9CiAgICAgICAgIH0KLSAgICAgICAgZW52
LT5oYWx0ZWQgPSAxOworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNl
cHRpb25faW5kZXggPSBFWENQX0hMVDsKICAgICB9CiAKQEAgLTczNCw2ICs3MzUsNyBAQCBzdGF0
aWMgdm9pZCBkb19tY2hrX2ludGVycnVwdChDUFVTMzkwWFN0YXRlICplbnYpCiB2b2lkIGRvX2lu
dGVycnVwdChDUFVTMzkwWFN0YXRlICplbnYpCiB7CiAgICAgUzM5MENQVSAqY3B1ID0gczM5MF9l
bnZfZ2V0X2NwdShlbnYpOworICAgIENQVVN0YXRlICpjczsKIAogICAgIHFlbXVfbG9nX21hc2so
Q1BVX0xPR19JTlQsICIlczogJWQgYXQgcGM9JSIgUFJJeDY0ICJcbiIsCiAgICAgICAgICAgICAg
ICAgICBfX2Z1bmNfXywgZW52LT5leGNlcHRpb25faW5kZXgsIGVudi0+cHN3LmFkZHIpOwpAQCAt
NzkyLDcgKzc5NCw4IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVVMzOTBYU3RhdGUgKmVudikKICAg
ICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IC0xOwogCiAgICAgaWYgKCFlbnYtPnBlbmRpbmdfaW50
KSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFS
RDsKKyAgICAgICAgY3MgPSBDUFUoczM5MF9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICAgICAgY3Mt
PmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBUkQ7CiAgICAgfQogfQogCmRp
ZmYgLS1naXQgYS90YXJnZXQtc2g0L2NwdS5oIGIvdGFyZ2V0LXNoNC9jcHUuaAppbmRleCA0OWRj
ZDllLi45MjZlYzQxIDEwMDY0NAotLS0gYS90YXJnZXQtc2g0L2NwdS5oCisrKyBiL3RhcmdldC1z
aDQvY3B1LmgKQEAgLTM3Miw5ICszNzIsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X2dldF90
Yl9jcHVfc3RhdGUoQ1BVU0g0U3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nICpwYywKIAogc3RhdGlj
IGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQogewotICAgIENQVVNINFN0
YXRlICplbnYgPSAmU1VQRVJIX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICByZXR1cm4gY3B1LT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKIH0KIAogI2luY2x1ZGUgImV4ZWMv
ZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3RhcmdldC1zaDQvaGVscGVyLmMgYi90YXJnZXQtc2g0
L2hlbHBlci5jCmluZGV4IGRkZWJjNzguLmZkNGVmZWUgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zaDQv
aGVscGVyLmMKKysrIGIvdGFyZ2V0LXNoNC9oZWxwZXIuYwpAQCAtNzgsOSArNzgsMTAgQEAgaW50
IGNwdV9zaDRfaXNfY2FjaGVkKENQVVNINFN0YXRlICogZW52LCB0YXJnZXRfdWxvbmcgYWRkcikK
ICNkZWZpbmUgTU1VX0RBRERSX0VSUk9SX1JFQUQgICAgICgtMTIpCiAjZGVmaW5lIE1NVV9EQURE
Ul9FUlJPUl9XUklURSAgICAoLTEzKQogCi12b2lkIGRvX2ludGVycnVwdChDUFVTSDRTdGF0ZSAq
IGVudikKK3ZvaWQgZG9faW50ZXJydXB0KENQVVNINFN0YXRlICplbnYpCiB7Ci0gICAgaW50IGRv
X2lycSA9IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CisgICAg
Q1BVU3RhdGUgKmNzID0gQ1BVKHNoX2Vudl9nZXRfY3B1KGVudikpOworICAgIGludCBkb19pcnEg
PSBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CiAgICAgaW50IGRv
X2V4cCwgaXJxX3ZlY3RvciA9IGVudi0+ZXhjZXB0aW9uX2luZGV4OwogCiAgICAgLyogcHJpb3Jp
dGl6ZSBleGNlcHRpb25zIG92ZXIgaW50ZXJydXB0cyAqLwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXNo
NC9vcF9oZWxwZXIuYyBiL3RhcmdldC1zaDQvb3BfaGVscGVyLmMKaW5kZXggMDllM2QyMy4uZTk1
NWU4MSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXNoNC9vcF9oZWxwZXIuYworKysgYi90YXJnZXQtc2g0
L29wX2hlbHBlci5jCkBAIC0xMDIsNyArMTAyLDkgQEAgdm9pZCBoZWxwZXJfZGVidWcoQ1BVU0g0
U3RhdGUgKmVudikKIAogdm9pZCBoZWxwZXJfc2xlZXAoQ1BVU0g0U3RhdGUgKmVudikKIHsKLSAg
ICBlbnYtPmhhbHRlZCA9IDE7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHNoX2Vudl9nZXRfY3B1
KGVudikpOworCisgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgZW52LT5pbl9zbGVlcCA9IDE7CiAg
ICAgcmFpc2VfZXhjZXB0aW9uKGVudiwgRVhDUF9ITFQsIDApOwogfQpkaWZmIC0tZ2l0IGEvdGFy
Z2V0LXNwYXJjL2NwdS5oIGIvdGFyZ2V0LXNwYXJjL2NwdS5oCmluZGV4IDczODliMDMuLjk1Y2Ji
YTAgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zcGFyYy9jcHUuaAorKysgYi90YXJnZXQtc3BhcmMvY3B1
LmgKQEAgLTc2MSw5ICs3NjEsMTAgQEAgc3RhdGljIGlubGluZSBib29sIHRiX2FtX2VuYWJsZWQo
aW50IHRiX2ZsYWdzKQogCiBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRl
ICpjcHUpCiB7Ci0gICAgQ1BVU1BBUkNTdGF0ZSAqZW52MSA9ICZTUEFSQ19DUFUoY3B1KS0+ZW52
OworICAgIFNQQVJDQ1BVICpzcGFyY19jcHUgPSBTUEFSQ19DUFUoY3B1KTsKKyAgICBDUFVTUEFS
Q1N0YXRlICplbnYxID0gJnNwYXJjX2NwdS0+ZW52OwogCi0gICAgcmV0dXJuIChlbnYxLT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKKyAgICByZXR1cm4gKGNwdS0+
aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAgICAgICAgIGNw
dV9pbnRlcnJ1cHRzX2VuYWJsZWQoZW52MSk7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC11bmlj
b3JlMzIvY3B1LmggYi90YXJnZXQtdW5pY29yZTMyL2NwdS5oCmluZGV4IGFlOWE5ZDYuLjU4ZjFm
MjAgMTAwNjQ0Ci0tLSBhL3RhcmdldC11bmljb3JlMzIvY3B1LmgKKysrIGIvdGFyZ2V0LXVuaWNv
cmUzMi9jcHUuaApAQCAtMTgxLDkgKzE4MSw3IEBAIHZvaWQgc3dpdGNoX21vZGUoQ1BVVW5pQ29y
ZTMyU3RhdGUgKiwgaW50KTsKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVT
dGF0ZSAqY3B1KQogewotICAgIENQVVVuaUNvcmUzMlN0YXRlICplbnYgPSAmVU5JQ09SRTMyX0NQ
VShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmCisgICAg
cmV0dXJuIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJgogICAgICAgICAoQ1BVX0lOVEVSUlVQVF9I
QVJEIHwgQ1BVX0lOVEVSUlVQVF9FWElUVEIpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtdW5p
Y29yZTMyL3NvZnRtbXUuYyBiL3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jCmluZGV4IGZjMjcx
MDAuLjFjNGM3ZjUgMTAwNjQ0Ci0tLSBhL3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jCisrKyBi
L3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jCkBAIC03NCw2ICs3NCw3IEBAIHZvaWQgc3dpdGNo
X21vZGUoQ1BVVW5pQ29yZTMyU3RhdGUgKmVudiwgaW50IG1vZGUpCiAvKiBIYW5kbGUgYSBDUFUg
ZXhjZXB0aW9uLiAgKi8KIHZvaWQgZG9faW50ZXJydXB0KENQVVVuaUNvcmUzMlN0YXRlICplbnYp
CiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHVjMzJfZW52X2dldF9jcHUoZW52KSk7CiAgICAg
dWludDMyX3QgYWRkcjsKICAgICBpbnQgbmV3X21vZGU7CiAKQEAgLTExMiw3ICsxMTMsNyBAQCB2
b2lkIGRvX2ludGVycnVwdChDUFVVbmlDb3JlMzJTdGF0ZSAqZW52KQogICAgIC8qIFRoZSBQQyBh
bHJlYWR5IHBvaW50cyB0byB0aGUgcHJvcGVyIGluc3RydWN0aW9uLiAgKi8KICAgICBlbnYtPnJl
Z3NbMzBdID0gZW52LT5yZWdzWzMxXTsKICAgICBlbnYtPnJlZ3NbMzFdID0gYWRkcjsKLSAgICBl
bnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOworICAgIGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKIH0KIAogc3RhdGljIGlu
dCBnZXRfcGh5c19hZGRyX3VjdjIoQ1BVVW5pQ29yZTMyU3RhdGUgKmVudiwgdWludDMyX3QgYWRk
cmVzcywKZGlmZiAtLWdpdCBhL3RhcmdldC14dGVuc2Evb3BfaGVscGVyLmMgYi90YXJnZXQteHRl
bnNhL29wX2hlbHBlci5jCmluZGV4IDM4MTNhNzIuLjEwMzcxMDEgMTAwNjQ0Ci0tLSBhL3Rhcmdl
dC14dGVuc2Evb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LXh0ZW5zYS9vcF9oZWxwZXIuYwpAQCAt
MzczLDYgKzM3Myw4IEBAIHZvaWQgSEVMUEVSKGR1bXBfc3RhdGUpKENQVVh0ZW5zYVN0YXRlICpl
bnYpCiAKIHZvaWQgSEVMUEVSKHdhaXRpKShDUFVYdGVuc2FTdGF0ZSAqZW52LCB1aW50MzJfdCBw
YywgdWludDMyX3QgaW50bGV2ZWwpCiB7CisgICAgQ1BVU3RhdGUgKmNwdTsKKwogICAgIGVudi0+
cGMgPSBwYzsKICAgICBlbnYtPnNyZWdzW1BTXSA9IChlbnYtPnNyZWdzW1BTXSAmIH5QU19JTlRM
RVZFTCkgfAogICAgICAgICAoaW50bGV2ZWwgPDwgUFNfSU5UTEVWRUxfU0hJRlQpOwpAQCAtMzgy
LDggKzM4NCw5IEBAIHZvaWQgSEVMUEVSKHdhaXRpKShDUFVYdGVuc2FTdGF0ZSAqZW52LCB1aW50
MzJfdCBwYywgdWludDMyX3QgaW50bGV2ZWwpCiAgICAgICAgIHJldHVybjsKICAgICB9CiAKKyAg
ICBjcHUgPSBDUFUoeHRlbnNhX2Vudl9nZXRfY3B1KGVudikpOwogICAgIGVudi0+aGFsdF9jbG9j
ayA9IHFlbXVfZ2V0X2Nsb2NrX25zKHZtX2Nsb2NrKTsKLSAgICBlbnYtPmhhbHRlZCA9IDE7Cisg
ICAgY3B1LT5oYWx0ZWQgPSAxOwogICAgIGlmICh4dGVuc2Ffb3B0aW9uX2VuYWJsZWQoZW52LT5j
b25maWcsIFhURU5TQV9PUFRJT05fVElNRVJfSU5URVJSVVBUKSkgewogICAgICAgICB4dGVuc2Ff
cmVhcm1fY2NvbXBhcmVfdGltZXIoZW52KTsKICAgICB9CmRpZmYgLS1naXQgYS90cmFuc2xhdGUt
YWxsLmMgYi90cmFuc2xhdGUtYWxsLmMKaW5kZXggMTliYzQxNC4uMjE3NjEzMiAxMDA2NDQKLS0t
IGEvdHJhbnNsYXRlLWFsbC5jCisrKyBiL3RyYW5zbGF0ZS1hbGwuYwpAQCAtMTA4Nyw4ICsxMDg3
LDggQEAgdm9pZCB0Yl9pbnZhbGlkYXRlX3BoeXNfcGFnZV9yYW5nZSh0Yl9wYWdlX2FkZHJfdCBz
dGFydCwgdGJfcGFnZV9hZGRyX3QgZW5kLAogICAgICAgICAgICAgdGJfcGh5c19pbnZhbGlkYXRl
KHRiLCAtMSk7CiAgICAgICAgICAgICBpZiAoY3B1ICE9IE5VTEwpIHsKICAgICAgICAgICAgICAg
ICBjcHUtPmN1cnJlbnRfdGIgPSBzYXZlZF90YjsKLSAgICAgICAgICAgICAgICBpZiAoZW52ICYm
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiYgY3B1LT5jdXJyZW50X3RiKSB7Ci0gICAgICAgICAg
ICAgICAgICAgIGNwdV9pbnRlcnJ1cHQoZW52LCBlbnYtPmludGVycnVwdF9yZXF1ZXN0KTsKKyAg
ICAgICAgICAgICAgICBpZiAoZW52ICYmIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiYgY3B1LT5j
dXJyZW50X3RiKSB7CisgICAgICAgICAgICAgICAgICAgIGNwdV9pbnRlcnJ1cHQoZW52LCBjcHUt
PmludGVycnVwdF9yZXF1ZXN0KTsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICB9CiAg
ICAgICAgIH0KQEAgLTE0NjUsOCArMTQ2NSw4IEBAIHN0YXRpYyB2b2lkIHRjZ19oYW5kbGVfaW50
ZXJydXB0KENQVUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKICAgICBDUFVTdGF0ZSAqY3B1ID0g
RU5WX0dFVF9DUFUoZW52KTsKICAgICBpbnQgb2xkX21hc2s7CiAKLSAgICBvbGRfbWFzayA9IGVu
di0+aW50ZXJydXB0X3JlcXVlc3Q7Ci0gICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBtYXNr
OworICAgIG9sZF9tYXNrID0gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdDsKKyAgICBjcHUtPmludGVy
cnVwdF9yZXF1ZXN0IHw9IG1hc2s7CiAKICAgICAvKgogICAgICAqIElmIGNhbGxlZCBmcm9tIGlv
dGhyZWFkIGNvbnRleHQsIHdha2UgdGhlIHRhcmdldCBjcHUgaW4KQEAgLTE2MjYsNyArMTYyNiw3
IEBAIHZvaWQgY3B1X2ludGVycnVwdChDUFVBcmNoU3RhdGUgKmVudiwgaW50IG1hc2spCiB7CiAg
ICAgQ1BVU3RhdGUgKmNwdSA9IEVOVl9HRVRfQ1BVKGVudik7CiAKLSAgICBlbnYtPmludGVycnVw
dF9yZXF1ZXN0IHw9IG1hc2s7CisgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBtYXNrOwog
ICAgIGNwdV91bmxpbmtfdGIoY3B1KTsKIH0KIApkaWZmIC0tZ2l0IGEveGVuLWFsbC5jIGIveGVu
LWFsbC5jCmluZGV4IDExMGY5NTguLjhjMDU4NDMgMTAwNjQ0Ci0tLSBhL3hlbi1hbGwuYworKysg
Yi94ZW4tYWxsLmMKQEAgLTU3OCwxNiArNTc4LDE4IEBAIHZvaWQgcW1wX3hlbl9zZXRfZ2xvYmFs
X2RpcnR5X2xvZyhib29sIGVuYWJsZSwgRXJyb3IgKiplcnJwKQogCiBzdGF0aWMgdm9pZCB4ZW5f
cmVzZXRfdmNwdSh2b2lkICpvcGFxdWUpCiB7Ci0gICAgQ1BVQXJjaFN0YXRlICplbnYgPSBvcGFx
dWU7CisgICAgQ1BVU3RhdGUgKmNwdSA9IG9wYXF1ZTsKIAotICAgIGVudi0+aGFsdGVkID0gMTsK
KyAgICBjcHUtPmhhbHRlZCA9IDE7CiB9CiAKIHZvaWQgeGVuX3ZjcHVfaW5pdCh2b2lkKQogewog
ICAgIGlmIChmaXJzdF9jcHUgIT0gTlVMTCkgewotICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0
KHhlbl9yZXNldF92Y3B1LCBmaXJzdF9jcHUpOwotICAgICAgICB4ZW5fcmVzZXRfdmNwdShmaXJz
dF9jcHUpOworICAgICAgICBDUFVTdGF0ZSAqY3B1ID0gRU5WX0dFVF9DUFUoZmlyc3RfY3B1KTsK
KworICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0KHhlbl9yZXNldF92Y3B1LCBjcHUpOworICAg
ICAgICB4ZW5fcmVzZXRfdmNwdShjcHUpOwogICAgIH0KICAgICAvKiBpZiBydGNfY2xvY2sgaXMg
bGVmdCB0byBkZWZhdWx0IChob3N0X2Nsb2NrKSwgZGlzYWJsZSBpdCAqLwogICAgIGlmIChydGNf
Y2xvY2sgPT0gaG9zdF9jbG9jaykgewotLSAKMS43LjEwLjQKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sat Feb 02 11:58:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 11:58: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 1U1bjU-0007o8-5r; Sat, 02 Feb 2013 11:58:08 +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 1U1bjS-0007o0-1l
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 11:58:06 +0000
Received: from [85.158.137.99:60712] by server-4.bemta-3.messagelabs.com id
	F4/00-12802-C4FFC015; Sat, 02 Feb 2013 11:58:04 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1359806281!11830282!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18093 invoked from network); 2 Feb 2013 11:58:01 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Feb 2013 11:58:01 -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 BBB1FA3E1C;
	Sat,  2 Feb 2013 12:57:57 +0100 (CET)
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
To: qemu-devel@nongnu.org
Date: Sat,  2 Feb 2013 12:57:23 +0100
Message-Id: <1359806247-27799-6-git-send-email-afaerber@suse.de>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359806247-27799-1-git-send-email-afaerber@suse.de>
References: <1359806247-27799-1-git-send-email-afaerber@suse.de>
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>, Guan Xuetao <gxt@mprc.pku.edu.cn>,
	"open list:Overall" <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Alexander Graf <agraf@suse.de>,
	Fabien Chouteau <chouteau@adacore.com>, Blue Swirl <blauwirbel@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>, Michael Walle <michael@walle.cc>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	"open list:e500" <qemu-ppc@nongnu.org>, Paul Brook <paul@codesourcery.com>,
	Scott Wood <scottwood@freescale.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Richard Henderson <rth@twiddle.net>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
	Aurelien Jarno <aurelien@aurel32.net>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [Xen-devel] [RFC qom-cpu-next 5/9] cpu: Move halted and
	interrupt_request fields to CPUState
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Qm90aCBmaWVsZHMgYXJlIHVzZWQgaW4gVk1TdGF0ZSwgdGh1cyBuZWVkIHRvIGJlIG1vdmVkIHRv
Z2V0aGVyLgpFeHBsaWNpdGx5IHplcm8gdGhlbSBvbiByZXNldCBzaW5jZSB0aGV5IHdlcmUgbG9j
YXRlZCBiZWZvcmUKYnJlYWtwb2ludHMuCgpQYXNzIFBvd2VyUENDUFUgdG8ga3ZtcHBjX2hhbmRs
ZV9oYWx0KCkuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZWFzIEbDpHJiZXIgPGFmYWVyYmVyQHN1c2Uu
ZGU+Ci0tLQogY3B1LWV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMzQgKysrKysr
KysrKysrLS0tLS0tLS0tLS0tCiBjcHVzLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgNCArLS0KIGV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDE2ICsrKysr
KystLS0tLQogZ2Ric3R1Yi5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIGh3
L2xlb24zLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIGh3L29tYXAxLmMg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA3ICsrKy0tCiBody9vcGVucmlzY190aW1lci5j
ICAgICAgICAgICAgICAgIHwgICAgNCArKy0KIGh3L3BwYy5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgIDIyICsrKysrKysrKystLS0tLS0KIGh3L3BwYy9lNTAwLmMgICAgICAgICAgICAg
ICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9wcGNlNTAwX3NwaW4uYyAgICAgICAgICAgICAg
ICAgIHwgICAgMiArLQogaHcvcHhhMnh4X2dwaW8uYyAgICAgICAgICAgICAgICAgICB8ICAgIDMg
KystCiBody9weGEyeHhfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAgMyArKy0KIGh3L3Mz
OTB4L3MzOTAtdmlydGlvLmMgICAgICAgICAgICAgfCAgIDE0ICsrKysrKy0tLS0KIGh3L3NwYXBy
LmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9zcGFwcl9oY2Fs
bC5jICAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogaHcvc3BhcHJfcnRhcy5jICAgICAgICAg
ICAgICAgICAgICB8ICAgIDYgKystLS0KIGh3L3N1bjRtLmMgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgIDIxICsrKysrKysrLS0tLS0tLQogaHcvc3VuNHUuYyAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgMTUgKysrKysrKy0tLS0KIGh3L3hlbl9tYWNoaW5lX3B2LmMgICAgICAgICAgICAg
ICAgfCAgICA2ICsrLS0tCiBody94dGVuc2FfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAg
OCArKystLS0KIGluY2x1ZGUvZXhlYy9jcHUtZGVmcy5oICAgICAgICAgICAgfCAgICAyIC0tCiBp
bmNsdWRlL3FvbS9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArKysKIGt2bS1hbGwuYyAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAyICstCiBxb20vY3B1LmMgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgMiArKwogdGFyZ2V0LWFscGhhL2NwdS5oICAgICAgICAgICAgICAg
ICB8ICAgIDQgKy0tCiB0YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMgICAgICAgICAgIHwgICAgMyAr
Ky0KIHRhcmdldC1hcm0vY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0
LWFybS9oZWxwZXIuYyAgICAgICAgICAgICAgICB8ICAgIDQgKystCiB0YXJnZXQtYXJtL29wX2hl
bHBlci5jICAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1jcmlzL2NwdS5oICAgICAgICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LWNyaXMvaGVscGVyLmMgICAgICAgICAgICAgICB8
ICAgIDkgKysrKy0tLQogdGFyZ2V0LWNyaXMvdHJhbnNsYXRlLmMgICAgICAgICAgICB8ICAgIDMg
KystCiB0YXJnZXQtaTM4Ni9jcHUuYyAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogdGFyZ2V0
LWkzODYvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgMjAgKysrKysrKystLS0tLS0tCiB0YXJn
ZXQtaTM4Ni9oZWxwZXIuYyAgICAgICAgICAgICAgIHwgICAxMiArKysrKy0tLS0KIHRhcmdldC1p
Mzg2L2t2bS5jICAgICAgICAgICAgICAgICAgfCAgIDUwICsrKysrKysrKysrKysrKysrKystLS0t
LS0tLS0tLS0tLS0tLQogdGFyZ2V0LWkzODYvbWlzY19oZWxwZXIuYyAgICAgICAgICB8ICAgMjEg
KysrKysrKysrKy0tLS0tCiB0YXJnZXQtaTM4Ni9zdm1faGVscGVyLmMgICAgICAgICAgIHwgICAg
OSArKysrLS0tCiB0YXJnZXQtbG0zMi9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArLS0K
IHRhcmdldC1sbTMyL29wX2hlbHBlci5jICAgICAgICAgICAgfCAgICA0ICsrLQogdGFyZ2V0LW02
OGsvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtbTY4ay9vcF9oZWxw
ZXIuYyAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1tNjhrL3FyZWdzLmRlZiAgICAgICAg
ICAgICAgfCAgICAxIC0KIHRhcmdldC1tNjhrL3RyYW5zbGF0ZS5jICAgICAgICAgICAgfCAgICA4
ICsrKysrLQogdGFyZ2V0LW1pY3JvYmxhemUvY3B1LmggICAgICAgICAgICB8ICAgIDQgKy0tCiB0
YXJnZXQtbWlwcy9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArLS0KIHRhcmdldC1taXBz
L29wX2hlbHBlci5jICAgICAgICAgICAgfCAgIDEwICsrKysrLS0tCiB0YXJnZXQtbWlwcy90cmFu
c2xhdGUuYyAgICAgICAgICAgIHwgICAgNCArLS0KIHRhcmdldC1vcGVucmlzYy9jcHUuaCAgICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LW9wZW5yaXNjL2ludGVycnVwdF9oZWxwZXIuYyB8
ICAgIDMgKystCiB0YXJnZXQtb3BlbnJpc2Mvc3lzX2hlbHBlci5jICAgICAgIHwgICAgMyArKy0K
IHRhcmdldC1wcGMvY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIHRhcmdldC1w
cGMvZXhjcF9oZWxwZXIuYyAgICAgICAgICAgfCAgIDIyICsrKysrKysrKysrLS0tLS0KIHRhcmdl
dC1wcGMvaGVscGVyX3JlZ3MuaCAgICAgICAgICAgfCAgIDExICsrKysrLS0tCiB0YXJnZXQtcHBj
L2t2bS5jICAgICAgICAgICAgICAgICAgIHwgICAxNiArKysrKysrLS0tLS0KIHRhcmdldC1wcGMv
dHJhbnNsYXRlLmMgICAgICAgICAgICAgfCAgICAzICsrLQogdGFyZ2V0LXMzOTB4L2NwdS5jICAg
ICAgICAgICAgICAgICB8ICAgIDggKysrLS0tCiB0YXJnZXQtczM5MHgvY3B1LmggICAgICAgICAg
ICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQtczM5MHgvaGVscGVyLmMgICAgICAgICAgICAgIHwg
ICAgNyArKystLQogdGFyZ2V0LXNoNC9jcHUuaCAgICAgICAgICAgICAgICAgICB8ICAgIDQgKy0t
CiB0YXJnZXQtc2g0L2hlbHBlci5jICAgICAgICAgICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQt
c2g0L29wX2hlbHBlci5jICAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1zcGFyYy9jcHUu
aCAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIHRhcmdldC11bmljb3JlMzIvY3B1LmggICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11LmMgICAgICAgICB8
ICAgIDMgKystCiB0YXJnZXQteHRlbnNhL29wX2hlbHBlci5jICAgICAgICAgIHwgICAgNSArKyst
CiB0cmFuc2xhdGUtYWxsLmMgICAgICAgICAgICAgICAgICAgIHwgICAxMCArKysrLS0tLQogeGVu
LWFsbC5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMTAgKysrKystLS0KIDY4IERhdGVp
ZW4gZ2XDpG5kZXJ0LCAzMTUgWmVpbGVuIGhpbnp1Z2Vmw7xndCgrKSwgMjIyIFplaWxlbiBlbnRm
ZXJudCgtKQoKZGlmZiAtLWdpdCBhL2NwdS1leGVjLmMgYi9jcHUtZXhlYy5jCmluZGV4IDgzZGRl
YTQuLjE5MWExOWIgMTAwNjQ0Ci0tLSBhL2NwdS1leGVjLmMKKysrIGIvY3B1LWV4ZWMuYwpAQCAt
MTkwLDEyICsxOTAsMTIgQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogICAgIHVp
bnQ4X3QgKnRjX3B0cjsKICAgICB0Y2dfdGFyZ2V0X3Vsb25nIG5leHRfdGI7CiAKLSAgICBpZiAo
ZW52LT5oYWx0ZWQpIHsKKyAgICBpZiAoY3B1LT5oYWx0ZWQpIHsKICAgICAgICAgaWYgKCFjcHVf
aGFzX3dvcmsoY3B1KSkgewogICAgICAgICAgICAgcmV0dXJuIEVYQ1BfSEFMVEVEOwogICAgICAg
ICB9CiAKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAwOworICAgICAgICBjcHUtPmhhbHRlZCA9IDA7
CiAgICAgfQogCiAgICAgY3B1X3NpbmdsZV9lbnYgPSBlbnY7CkBAIC0yNjUsMTQgKzI2NSwxNCBA
QCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAKICAgICAgICAgICAgIG5leHRfdGIg
PSAwOyAvKiBmb3JjZSBsb29rdXAgb2YgZmlyc3QgVEIgKi8KICAgICAgICAgICAgIGZvcig7Oykg
ewotICAgICAgICAgICAgICAgIGludGVycnVwdF9yZXF1ZXN0ID0gZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdDsKKyAgICAgICAgICAgICAgICBpbnRlcnJ1cHRfcmVxdWVzdCA9IGNwdS0+aW50ZXJydXB0
X3JlcXVlc3Q7CiAgICAgICAgICAgICAgICAgaWYgKHVubGlrZWx5KGludGVycnVwdF9yZXF1ZXN0
KSkgewogICAgICAgICAgICAgICAgICAgICBpZiAodW5saWtlbHkoZW52LT5zaW5nbGVzdGVwX2Vu
YWJsZWQgJiBTU1RFUF9OT0lSUSkpIHsKICAgICAgICAgICAgICAgICAgICAgICAgIC8qIE1hc2sg
b3V0IGV4dGVybmFsIGludGVycnVwdHMgZm9yIHRoaXMgc3RlcC4gKi8KICAgICAgICAgICAgICAg
ICAgICAgICAgIGludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NTVEVQX01BU0s7
CiAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVw
dF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9ERUJVRykgewotICAgICAgICAgICAgICAgICAgICAg
ICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9ERUJVRzsKKyAgICAg
ICAgICAgICAgICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJV
UFRfREVCVUc7CiAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9
IEVYQ1BfREVCVUc7CiAgICAgICAgICAgICAgICAgICAgICAgICBjcHVfbG9vcF9leGl0KGVudik7
CiAgICAgICAgICAgICAgICAgICAgIH0KQEAgLTI4MCw4ICsyODAsOCBAQCBpbnQgY3B1X2V4ZWMo
Q1BVQXJjaFN0YXRlICplbnYpCiAgICAgZGVmaW5lZChUQVJHRVRfUFBDKSB8fCBkZWZpbmVkKFRB
UkdFVF9BTFBIQSkgfHwgZGVmaW5lZChUQVJHRVRfQ1JJUykgfHwgXAogICAgIGRlZmluZWQoVEFS
R0VUX01JQ1JPQkxBWkUpIHx8IGRlZmluZWQoVEFSR0VUX0xNMzIpIHx8IGRlZmluZWQoVEFSR0VU
X1VOSUNPUkUzMikKICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYg
Q1BVX0lOVEVSUlVQVF9IQUxUKSB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVy
cnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBTFQ7Ci0gICAgICAgICAgICAgICAgICAg
ICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVy
cnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBTFQ7CisgICAgICAgICAgICAgICAgICAg
ICAgICBjcHUtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmV4Y2Vw
dGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgICAgICAgICAgICAgICAgICAgICAgY3B1X2xvb3Bf
ZXhpdChlbnYpOwogICAgICAgICAgICAgICAgICAgICB9CkBAIC0yODksNyArMjg5LDcgQEAgaW50
IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogI2lmIGRlZmluZWQoVEFSR0VUX0kzODYpCiAj
aWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkKICAgICAgICAgICAgICAgICAgICAgaWYgKGlu
dGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9QT0xMKSB7Ci0gICAgICAgICAgICAgICAg
ICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7Cisg
ICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5U
RVJSVVBUX1BPTEw7CiAgICAgICAgICAgICAgICAgICAgICAgICBhcGljX3BvbGxfaXJxKGVudi0+
YXBpY19zdGF0ZSk7CiAgICAgICAgICAgICAgICAgICAgIH0KICNlbmRpZgpAQCAtMzA2LDE3ICsz
MDYsMTcgQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICEoZW52LT5oZmxhZ3MgJiBIRl9TTU1fTUFTSykpIHsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBjcHVfc3ZtX2NoZWNrX2ludGVyY2VwdF9wYXJhbShlbnYsIFNWTV9F
WElUX1NNSSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwKTsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NNSTsKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NNSTsKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBkb19zbW1fZW50ZXIoZW52KTsKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBuZXh0X3RiID0gMDsKICAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxz
ZSBpZiAoKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9OTUkpICYmCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICEoZW52LT5oZmxhZ3MyICYgSEYyX05NSV9NQVNL
KSkgewotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3Qg
Jj0gfkNQVV9JTlRFUlJVUFRfTk1JOworICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+
aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfTk1JOwogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGVudi0+aGZsYWdzMiB8PSBIRjJfTk1JX01BU0s7CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZG9faW50ZXJydXB0X3g4Nl9oYXJkaXJxKGVudiwgRVhDUDAyX05NSSwg
MSk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAg
ICAgICAgICAgICAgICB9IGVsc2UgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQ
VF9NQ0UpIHsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
cHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBkb19pbnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBFWENQMTJfTUNI
SywgMCk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAg
ICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKChpbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRF
UlJVUFRfSEFSRCkgJiYKQEAgLTMyOCw3ICszMjgsOCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0
YXRlICplbnYpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IGludG5vOwogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNwdV9zdm1fY2hlY2tfaW50ZXJjZXB0X3BhcmFtKGVudiwg
U1ZNX0VYSVRfSU5UUiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAwKTsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmlu
dGVycnVwdF9yZXF1ZXN0ICY9IH4oQ1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9W
SVJRKTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0
ICY9IH4oQ1BVX0lOVEVSUlVQVF9IQVJEIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9WSVJRKTsKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBpbnRubyA9IGNwdV9nZXRfcGljX2ludGVycnVwdChlbnYpOwog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHFlbXVfbG9nX21hc2soQ1BVX0xPR19UQl9JTl9B
U00sICJTZXJ2aWNpbmcgaGFyZHdhcmUgSU5UPTB4JTAyeFxuIiwgaW50bm8pOwogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGRvX2ludGVycnVwdF94ODZfaGFyZGlycShlbnYsIGludG5vLCAx
KTsKQEAgLTM0Niw3ICszNDcsNyBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50bm8gPSBsZGxfcGh5cyhlbnYtPnZtX3ZtY2Ig
KyBvZmZzZXRvZihzdHJ1Y3Qgdm1jYiwgY29udHJvbC5pbnRfdmVjdG9yKSk7CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcWVtdV9sb2dfbWFzayhDUFVfTE9HX1RCX0lOX0FTTSwgIlNlcnZp
Y2luZyB2aXJ0dWFsIGhhcmR3YXJlIElOVD0weCUwMnhcbiIsIGludG5vKTsKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBkb19pbnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBpbnRubywgMSk7
Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+
Q1BVX0lOVEVSUlVQVF9WSVJROworICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+aW50
ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfVklSUTsKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBuZXh0X3RiID0gMDsKICNlbmRpZgogICAgICAgICAgICAgICAgICAgICAgICAg
fQpAQCAtMzU3LDggKzM1OCw5IEBAIGludCBjcHVfZXhlYyhDUFVBcmNoU3RhdGUgKmVudikKICAg
ICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICBpZiAoaW50ZXJydXB0X3Jl
cXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKICAgICAgICAgICAgICAgICAgICAgICAgIHBw
Y19od19pbnRlcnJ1cHQoZW52KTsKLSAgICAgICAgICAgICAgICAgICAgICAgIGlmIChlbnYtPnBl
bmRpbmdfaW50ZXJydXB0cyA9PSAwKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+
aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICAgICAgICAgICAg
ICAgICAgICAgIGlmIChlbnYtPnBlbmRpbmdfaW50ZXJydXB0cyA9PSAwKSB7CisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQ
VF9IQVJEOworICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAg
ICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAgICAgICAgICAgIH0KICNlbGlmIGRlZmluZWQoVEFS
R0VUX0xNMzIpCkBAIC01MzUsOCArNTM3LDggQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAq
ZW52KQogI2VuZGlmCiAgICAgICAgICAgICAgICAgICAgLyogRG9uJ3QgdXNlIHRoZSBjYWNoZWQg
aW50ZXJydXB0X3JlcXVlc3QgdmFsdWUsCiAgICAgICAgICAgICAgICAgICAgICAgZG9faW50ZXJy
dXB0IG1heSBoYXZlIHVwZGF0ZWQgdGhlIEVYSVRUQiBmbGFnLiAqLwotICAgICAgICAgICAgICAg
ICAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfRVhJVFRCKSB7
Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVf
SU5URVJSVVBUX0VYSVRUQjsKKyAgICAgICAgICAgICAgICAgICAgaWYgKGNwdS0+aW50ZXJydXB0
X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0VYSVRUQikgeworICAgICAgICAgICAgICAgICAgICAg
ICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAg
ICAgICAgICAgICAgICAgICAgICAvKiBlbnN1cmUgdGhhdCBubyBUQiBqdW1wIHdpbGwgYmUgbW9k
aWZpZWQgYXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBwcm9ncmFtIGZsb3cgd2Fz
IGNoYW5nZWQgKi8KICAgICAgICAgICAgICAgICAgICAgICAgIG5leHRfdGIgPSAwOwpkaWZmIC0t
Z2l0IGEvY3B1cy5jIGIvY3B1cy5jCmluZGV4IDQxNzc5ZWIuLjhiNWY0MjYgMTAwNjQ0Ci0tLSBh
L2NwdXMuYworKysgYi9jcHVzLmMKQEAgLTcyLDcgKzcyLDcgQEAgc3RhdGljIGJvb2wgY3B1X3Ro
cmVhZF9pc19pZGxlKENQVUFyY2hTdGF0ZSAqZW52KQogICAgIGlmIChjcHUtPnN0b3BwZWQgfHwg
IXJ1bnN0YXRlX2lzX3J1bm5pbmcoKSkgewogICAgICAgICByZXR1cm4gdHJ1ZTsKICAgICB9Ci0g
ICAgaWYgKCFlbnYtPmhhbHRlZCB8fCBxZW11X2NwdV9oYXNfd29yayhjcHUpIHx8CisgICAgaWYg
KCFjcHUtPmhhbHRlZCB8fCBxZW11X2NwdV9oYXNfd29yayhjcHUpIHx8CiAgICAgICAgIGt2bV9h
c3luY19pbnRlcnJ1cHRzX2VuYWJsZWQoKSkgewogICAgICAgICByZXR1cm4gZmFsc2U7CiAgICAg
fQpAQCAtMTIxOSw3ICsxMjE5LDcgQEAgQ3B1SW5mb0xpc3QgKnFtcF9xdWVyeV9jcHVzKEVycm9y
ICoqZXJycCkKICAgICAgICAgaW5mby0+dmFsdWUgPSBnX21hbGxvYzAoc2l6ZW9mKCppbmZvLT52
YWx1ZSkpOwogICAgICAgICBpbmZvLT52YWx1ZS0+Q1BVID0gY3B1LT5jcHVfaW5kZXg7CiAgICAg
ICAgIGluZm8tPnZhbHVlLT5jdXJyZW50ID0gKGVudiA9PSBmaXJzdF9jcHUpOwotICAgICAgICBp
bmZvLT52YWx1ZS0+aGFsdGVkID0gZW52LT5oYWx0ZWQ7CisgICAgICAgIGluZm8tPnZhbHVlLT5o
YWx0ZWQgPSBjcHUtPmhhbHRlZDsKICAgICAgICAgaW5mby0+dmFsdWUtPnRocmVhZF9pZCA9IGNw
dS0+dGhyZWFkX2lkOwogI2lmIGRlZmluZWQoVEFSR0VUX0kzODYpCiAgICAgICAgIGluZm8tPnZh
bHVlLT5oYXNfcGMgPSB0cnVlOwpkaWZmIC0tZ2l0IGEvZXhlYy5jIGIvZXhlYy5jCmluZGV4IGE0
MWJjYjguLjVhYjdhZjQgMTAwNjQ0Ci0tLSBhL2V4ZWMuYworKysgYi9leGVjLmMKQEAgLTIyMywx
MiArMjIzLDEyIEBAIHZvaWQgY3B1X2V4ZWNfaW5pdF9hbGwodm9pZCkKIAogc3RhdGljIGludCBj
cHVfY29tbW9uX3Bvc3RfbG9hZCh2b2lkICpvcGFxdWUsIGludCB2ZXJzaW9uX2lkKQogewotICAg
IENQVUFyY2hTdGF0ZSAqZW52ID0gb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBvcGFxdWU7
CiAKICAgICAvKiAweDAxIHdhcyBDUFVfSU5URVJSVVBUX0VYSVQuIFRoaXMgbGluZSBjYW4gYmUg
cmVtb3ZlZCB3aGVuIHRoZQogICAgICAgIHZlcnNpb25faWQgaXMgaW5jcmVhc2VkLiAqLwotICAg
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfjB4MDE7Ci0gICAgdGxiX2ZsdXNoKGVudiwgMSk7
CisgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+MHgwMTsKKyAgICB0bGJfZmx1c2goY3B1
LT5lbnZfcHRyLCAxKTsKIAogICAgIHJldHVybiAwOwogfQpAQCAtMjQwLDggKzI0MCw4IEBAIHN0
YXRpYyBjb25zdCBWTVN0YXRlRGVzY3JpcHRpb24gdm1zdGF0ZV9jcHVfY29tbW9uID0gewogICAg
IC5taW5pbXVtX3ZlcnNpb25faWRfb2xkID0gMSwKICAgICAucG9zdF9sb2FkID0gY3B1X2NvbW1v
bl9wb3N0X2xvYWQsCiAgICAgLmZpZWxkcyAgICAgID0gKFZNU3RhdGVGaWVsZCBbXSkgewotICAg
ICAgICBWTVNUQVRFX1VJTlQzMihoYWx0ZWQsIENQVUFyY2hTdGF0ZSksCi0gICAgICAgIFZNU1RB
VEVfVUlOVDMyKGludGVycnVwdF9yZXF1ZXN0LCBDUFVBcmNoU3RhdGUpLAorICAgICAgICBWTVNU
QVRFX1VJTlQzMihoYWx0ZWQsIENQVVN0YXRlKSwKKyAgICAgICAgVk1TVEFURV9VSU5UMzIoaW50
ZXJydXB0X3JlcXVlc3QsIENQVVN0YXRlKSwKICAgICAgICAgVk1TVEFURV9FTkRfT0ZfTElTVCgp
CiAgICAgfQogfTsKQEAgLTI5MSw3ICsyOTEsNyBAQCB2b2lkIGNwdV9leGVjX2luaXQoQ1BVQXJj
aFN0YXRlICplbnYpCiAgICAgY3B1X2xpc3RfdW5sb2NrKCk7CiAjZW5kaWYKICNpZiBkZWZpbmVk
KENQVV9TQVZFX1ZFUlNJT04pICYmICFkZWZpbmVkKENPTkZJR19VU0VSX09OTFkpCi0gICAgdm1z
dGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2NwdV9jb21tb24sIGVudik7
CisgICAgdm1zdGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2NwdV9jb21t
b24sIGNwdSk7CiAgICAgcmVnaXN0ZXJfc2F2ZXZtKE5VTEwsICJjcHUiLCBjcHVfaW5kZXgsIENQ
VV9TQVZFX1ZFUlNJT04sCiAgICAgICAgICAgICAgICAgICAgIGNwdV9zYXZlLCBjcHVfbG9hZCwg
ZW52KTsKICNlbmRpZgpAQCAtNDg3LDcgKzQ4Nyw5IEBAIHZvaWQgY3B1X3NpbmdsZV9zdGVwKENQ
VUFyY2hTdGF0ZSAqZW52LCBpbnQgZW5hYmxlZCkKIAogdm9pZCBjcHVfcmVzZXRfaW50ZXJydXB0
KENQVUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKIHsKLSAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICY9IH5tYXNrOworICAgIENQVVN0YXRlICpjcHUgPSBFTlZfR0VUX0NQVShlbnYpOworCisg
ICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+bWFzazsKIH0KIAogdm9pZCBjcHVfZXhpdChD
UFVBcmNoU3RhdGUgKmVudikKZGlmZiAtLWdpdCBhL2dkYnN0dWIuYyBiL2dkYnN0dWIuYwppbmRl
eCAzMmRmZWE5Li44NDZkZTFjIDEwMDY0NAotLS0gYS9nZGJzdHViLmMKKysrIGIvZ2Ric3R1Yi5j
CkBAIC0yNDA4LDcgKzI0MDgsNyBAQCBzdGF0aWMgaW50IGdkYl9oYW5kbGVfcGFja2V0KEdEQlN0
YXRlICpzLCBjb25zdCBjaGFyICpsaW5lX2J1ZikKICAgICAgICAgICAgICAgICBjcHVfc3luY2hy
b25pemVfc3RhdGUoZW52KTsKICAgICAgICAgICAgICAgICBsZW4gPSBzbnByaW50ZigoY2hhciAq
KW1lbV9idWYsIHNpemVvZihtZW1fYnVmKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAiQ1BVIyVkIFslc10iLCBjcHUtPmNwdV9pbmRleCwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBlbnYtPmhhbHRlZCA/ICJoYWx0ZWQgIiA6ICJydW5uaW5nIik7CisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY3B1LT5oYWx0ZWQgPyAiaGFsdGVkICIgOiAicnVubmluZyIp
OwogICAgICAgICAgICAgICAgIG1lbXRvaGV4KGJ1ZiwgbWVtX2J1ZiwgbGVuKTsKICAgICAgICAg
ICAgICAgICBwdXRfcGFja2V0KHMsIGJ1Zik7CiAgICAgICAgICAgICB9CmRpZmYgLS1naXQgYS9o
dy9sZW9uMy5jIGIvaHcvbGVvbjMuYwppbmRleCBmMTZhOGJiLi5lOTcxZDVjIDEwMDY0NAotLS0g
YS9ody9sZW9uMy5jCisrKyBiL2h3L2xlb24zLmMKQEAgLTQ5LDExICs0OSwxMiBAQCB0eXBlZGVm
IHN0cnVjdCBSZXNldERhdGEgewogc3RhdGljIHZvaWQgbWFpbl9jcHVfcmVzZXQodm9pZCAqb3Bh
cXVlKQogewogICAgIFJlc2V0RGF0YSAqcyAgID0gKFJlc2V0RGF0YSAqKW9wYXF1ZTsKKyAgICBD
UFVTdGF0ZSAqY3B1ID0gQ1BVKHMtPmNwdSk7CiAgICAgQ1BVU1BBUkNTdGF0ZSAgKmVudiA9ICZz
LT5jcHUtPmVudjsKIAotICAgIGNwdV9yZXNldChDUFUocy0+Y3B1KSk7CisgICAgY3B1X3Jlc2V0
KGNwdSk7CiAKLSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgY3B1LT5oYWx0ZWQgPSAwOwogICAg
IGVudi0+cGMgICAgID0gcy0+ZW50cnk7CiAgICAgZW52LT5ucGMgICAgPSBzLT5lbnRyeSArIDQ7
CiB9CmRpZmYgLS1naXQgYS9ody9vbWFwMS5jIGIvaHcvb21hcDEuYwppbmRleCA2MjNiMTAxLi5j
MzZhMzMwIDEwMDY0NAotLS0gYS9ody9vbWFwMS5jCisrKyBiL2h3L29tYXAxLmMKQEAgLTE3MjEs
NiArMTcyMSw3IEBAIHN0YXRpYyB1aW50NjRfdCBvbWFwX2Nsa2RzcF9yZWFkKHZvaWQgKm9wYXF1
ZSwgaHdhZGRyIGFkZHIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25l
ZCBzaXplKQogewogICAgIHN0cnVjdCBvbWFwX21wdV9zdGF0ZV9zICpzID0gKHN0cnVjdCBvbWFw
X21wdV9zdGF0ZV9zICopIG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3B1ID0gQ1BVKHMtPmNwdSk7
CiAKICAgICBpZiAoc2l6ZSAhPSAyKSB7CiAgICAgICAgIHJldHVybiBvbWFwX2JhZHdpZHRoX3Jl
YWQxNihvcGFxdWUsIGFkZHIpOwpAQCAtMTczNyw4ICsxNzM4LDkgQEAgc3RhdGljIHVpbnQ2NF90
IG9tYXBfY2xrZHNwX3JlYWQodm9pZCAqb3BhcXVlLCBod2FkZHIgYWRkciwKICAgICAgICAgcmV0
dXJuIHMtPmNsa20uZHNwX3JzdGN0MjsKIAogICAgIGNhc2UgMHgxODoJLyogRFNQX1NZU1NUICov
CisgICAgICAgIGNwdSA9IENQVShzLT5jcHUpOwogICAgICAgICByZXR1cm4gKHMtPmNsa20uY2xv
Y2tpbmdfc2NoZW1lIDw8IDExKSB8IHMtPmNsa20uY29sZF9zdGFydCB8Ci0gICAgICAgICAgICAg
ICAgKHMtPmNwdS0+ZW52LmhhbHRlZCA8PCA2KTsgICAgICAvKiBRdWl0ZSB1c2VsZXNzLi4uICov
CisgICAgICAgICAgICAgICAgKGNwdS0+aGFsdGVkIDw8IDYpOyAgICAgIC8qIFF1aXRlIHVzZWxl
c3MuLi4gKi8KICAgICB9CiAKICAgICBPTUFQX0JBRF9SRUcoYWRkcik7CkBAIC0zNzU0LDggKzM3
NTYsOSBAQCBzdGF0aWMgdm9pZCBvbWFwX3NldHVwX2RzcF9tYXBwaW5nKE1lbW9yeVJlZ2lvbiAq
c3lzdGVtX21lbW9yeSwKIHZvaWQgb21hcF9tcHVfd2FrZXVwKHZvaWQgKm9wYXF1ZSwgaW50IGly
cSwgaW50IHJlcSkKIHsKICAgICBzdHJ1Y3Qgb21hcF9tcHVfc3RhdGVfcyAqbXB1ID0gKHN0cnVj
dCBvbWFwX21wdV9zdGF0ZV9zICopIG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3B1ID0gQ1BVKG1w
dS0+Y3B1KTsKIAotICAgIGlmIChtcHUtPmNwdS0+ZW52LmhhbHRlZCkgeworICAgIGlmIChjcHUt
PmhhbHRlZCkgewogICAgICAgICBjcHVfaW50ZXJydXB0KCZtcHUtPmNwdS0+ZW52LCBDUFVfSU5U
RVJSVVBUX0VYSVRUQik7CiAgICAgfQogfQpkaWZmIC0tZ2l0IGEvaHcvb3BlbnJpc2NfdGltZXIu
YyBiL2h3L29wZW5yaXNjX3RpbWVyLmMKaW5kZXggZDk2NWJlNy4uZjlmMTE2YSAxMDA2NDQKLS0t
IGEvaHcvb3BlbnJpc2NfdGltZXIuYworKysgYi9ody9vcGVucmlzY190aW1lci5jCkBAIC03Myw4
ICs3MywxMCBAQCBzdGF0aWMgdm9pZCBvcGVucmlzY190aW1lcl9jYih2b2lkICpvcGFxdWUpCiAK
ICAgICBpZiAoKGNwdS0+ZW52LnR0bXIgJiBUVE1SX0lFKSAmJgogICAgICAgICAgcWVtdV90aW1l
cl9leHBpcmVkKGNwdS0+ZW52LnRpbWVyLCBxZW11X2dldF9jbG9ja19ucyh2bV9jbG9jaykpKSB7
CisgICAgICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOworCiAgICAgICAgIGNwdS0+ZW52LnR0
bXIgfD0gVFRNUl9JUDsKLSAgICAgICAgY3B1LT5lbnYuaW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BV
X0lOVEVSUlVQVF9USU1FUjsKKyAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9J
TlRFUlJVUFRfVElNRVI7CiAgICAgfQogCiAgICAgc3dpdGNoIChjcHUtPmVudi50dG1yICYgVFRN
Ul9NKSB7CmRpZmYgLS1naXQgYS9ody9wcGMuYyBiL2h3L3BwYy5jCmluZGV4IDg5MzUyYmUuLjQw
MGRhYWIgMTAwNjQ0Ci0tLSBhL2h3L3BwYy5jCisrKyBiL2h3L3BwYy5jCkBAIC03Miw3ICs3Miw3
IEBAIHZvaWQgcHBjX3NldF9pcnEoUG93ZXJQQ0NQVSAqY3B1LCBpbnQgbl9JUlEsIGludCBsZXZl
bCkKIAogICAgIExPR19JUlEoIiVzOiAlcCBuX0lSUSAlZCBsZXZlbCAlZCA9PiBwZW5kaW5nICUw
OCIgUFJJeDMyCiAgICAgICAgICAgICAgICAgInJlcSAlMDh4XG4iLCBfX2Z1bmNfXywgZW52LCBu
X0lSUSwgbGV2ZWwsCi0gICAgICAgICAgICAgICAgZW52LT5wZW5kaW5nX2ludGVycnVwdHMsIGVu
di0+aW50ZXJydXB0X3JlcXVlc3QpOworICAgICAgICAgICAgICAgIGVudi0+cGVuZGluZ19pbnRl
cnJ1cHRzLCBDUFUoY3B1KS0+aW50ZXJydXB0X3JlcXVlc3QpOwogfQogCiAvKiBQb3dlclBDIDZ4
eCAvIDd4eCBpbnRlcm5hbCBJUlEgY29udHJvbGxlciAqLwpAQCAtODcsNiArODcsOCBAQCBzdGF0
aWMgdm9pZCBwcGM2eHhfc2V0X2lycSh2b2lkICpvcGFxdWUsIGludCBwaW4sIGludCBsZXZlbCkK
ICAgICBjdXJfbGV2ZWwgPSAoZW52LT5pcnFfaW5wdXRfc3RhdGUgPj4gcGluKSAmIDE7CiAgICAg
LyogRG9uJ3QgZ2VuZXJhdGUgc3B1cmlvdXMgZXZlbnRzICovCiAgICAgaWYgKChjdXJfbGV2ZWwg
PT0gMSAmJiBsZXZlbCA9PSAwKSB8fCAoY3VyX2xldmVsID09IDAgJiYgbGV2ZWwgIT0gMCkpIHsK
KyAgICAgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CisKICAgICAgICAgc3dpdGNoIChwaW4p
IHsKICAgICAgICAgY2FzZSBQUEM2eHhfSU5QVVRfVEJFTjoKICAgICAgICAgICAgIC8qIExldmVs
IHNlbnNpdGl2ZSAtIGFjdGl2ZSBoaWdoICovCkBAIC0xMjYsNyArMTI4LDcgQEAgc3RhdGljIHZv
aWQgcHBjNnh4X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwpCiAgICAg
ICAgICAgICAvKiBYWFg6IE5vdGUgdGhhdCB0aGUgb25seSB3YXkgdG8gcmVzdGFydCB0aGUgQ1BV
IGlzIHRvIHJlc2V0IGl0ICovCiAgICAgICAgICAgICBpZiAobGV2ZWwpIHsKICAgICAgICAgICAg
ICAgICBMT0dfSVJRKCIlczogc3RvcCB0aGUgQ1BVXG4iLCBfX2Z1bmNfXyk7Ci0gICAgICAgICAg
ICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwog
ICAgICAgICAgICAgfQogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgUFBDNnh4X0lO
UFVUX0hSRVNFVDoKQEAgLTE3NCw2ICsxNzYsOCBAQCBzdGF0aWMgdm9pZCBwcGM5NzBfc2V0X2ly
cSh2b2lkICpvcGFxdWUsIGludCBwaW4sIGludCBsZXZlbCkKICAgICBjdXJfbGV2ZWwgPSAoZW52
LT5pcnFfaW5wdXRfc3RhdGUgPj4gcGluKSAmIDE7CiAgICAgLyogRG9uJ3QgZ2VuZXJhdGUgc3B1
cmlvdXMgZXZlbnRzICovCiAgICAgaWYgKChjdXJfbGV2ZWwgPT0gMSAmJiBsZXZlbCA9PSAwKSB8
fCAoY3VyX2xldmVsID09IDAgJiYgbGV2ZWwgIT0gMCkpIHsKKyAgICAgICAgQ1BVU3RhdGUgKmNz
ID0gQ1BVKGNwdSk7CisKICAgICAgICAgc3dpdGNoIChwaW4pIHsKICAgICAgICAgY2FzZSBQUEM5
NzBfSU5QVVRfSU5UOgogICAgICAgICAgICAgLyogTGV2ZWwgc2Vuc2l0aXZlIC0gYWN0aXZlIGhp
Z2ggKi8KQEAgLTIwMywxMSArMjA3LDExIEBAIHN0YXRpYyB2b2lkIHBwYzk3MF9zZXRfaXJxKHZv
aWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQogICAgICAgICAgICAgLyogWFhYOiBUT0RP
OiByZWxheSB0aGUgc2lnbmFsIHRvIENLU1RQX09VVCBwaW4gKi8KICAgICAgICAgICAgIGlmIChs
ZXZlbCkgewogICAgICAgICAgICAgICAgIExPR19JUlEoIiVzOiBzdG9wIHRoZSBDUFVcbiIsIF9f
ZnVuY19fKTsKLSAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICAg
ICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgICAg
IExPR19JUlEoIiVzOiByZXN0YXJ0IHRoZSBDUFVcbiIsIF9fZnVuY19fKTsKLSAgICAgICAgICAg
ICAgICBlbnYtPmhhbHRlZCA9IDA7Ci0gICAgICAgICAgICAgICAgcWVtdV9jcHVfa2ljayhDUFUo
Y3B1KSk7CisgICAgICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDA7CisgICAgICAgICAgICAgICAg
cWVtdV9jcHVfa2ljayhjcyk7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBicmVhazsKICAg
ICAgICAgY2FzZSBQUEM5NzBfSU5QVVRfSFJFU0VUOgpAQCAtMjk1LDYgKzI5OSw4IEBAIHN0YXRp
YyB2b2lkIHBwYzQweF9zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQog
ICAgIGN1cl9sZXZlbCA9IChlbnYtPmlycV9pbnB1dF9zdGF0ZSA+PiBwaW4pICYgMTsKICAgICAv
KiBEb24ndCBnZW5lcmF0ZSBzcHVyaW91cyBldmVudHMgKi8KICAgICBpZiAoKGN1cl9sZXZlbCA9
PSAxICYmIGxldmVsID09IDApIHx8IChjdXJfbGV2ZWwgPT0gMCAmJiBsZXZlbCAhPSAwKSkgewor
ICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKKwogICAgICAgICBzd2l0Y2ggKHBpbikg
ewogICAgICAgICBjYXNlIFBQQzQweF9JTlBVVF9SRVNFVF9TWVM6CiAgICAgICAgICAgICBpZiAo
bGV2ZWwpIHsKQEAgLTMzMiwxMSArMzM4LDExIEBAIHN0YXRpYyB2b2lkIHBwYzQweF9zZXRfaXJx
KHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQogICAgICAgICAgICAgLyogTGV2ZWwg
c2Vuc2l0aXZlIC0gYWN0aXZlIGxvdyAqLwogICAgICAgICAgICAgaWYgKGxldmVsKSB7CiAgICAg
ICAgICAgICAgICAgTE9HX0lSUSgiJXM6IHN0b3AgdGhlIENQVVxuIiwgX19mdW5jX18pOwotICAg
ICAgICAgICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgICAgICAgICBjcy0+aGFsdGVk
ID0gMTsKICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgTE9HX0lSUSgiJXM6
IHJlc3RhcnQgdGhlIENQVVxuIiwgX19mdW5jX18pOwotICAgICAgICAgICAgICAgIGVudi0+aGFs
dGVkID0gMDsKLSAgICAgICAgICAgICAgICBxZW11X2NwdV9raWNrKENQVShjcHUpKTsKKyAgICAg
ICAgICAgICAgICBjcy0+aGFsdGVkID0gMDsKKyAgICAgICAgICAgICAgICBxZW11X2NwdV9raWNr
KGNzKTsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjYXNlIFBQ
QzQweF9JTlBVVF9ERUJVRzoKZGlmZiAtLWdpdCBhL2h3L3BwYy9lNTAwLmMgYi9ody9wcGMvZTUw
MC5jCmluZGV4IGI3NDc0YzAuLjI2NWQ3NWMgMTAwNjQ0Ci0tLSBhL2h3L3BwYy9lNTAwLmMKKysr
IGIvaHcvcHBjL2U1MDAuYwpAQCAtNDI1LDI2ICs0MjUsMjggQEAgc3RhdGljIHZvaWQgbW11Ym9v
a2VfY3JlYXRlX2luaXRpYWxfbWFwcGluZyhDUFVQUENTdGF0ZSAqZW52KQogc3RhdGljIHZvaWQg
cHBjZTUwMF9jcHVfcmVzZXRfc2VjKHZvaWQgKm9wYXF1ZSkKIHsKICAgICBQb3dlclBDQ1BVICpj
cHUgPSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVUFBDU3Rh
dGUgKmVudiA9ICZjcHUtPmVudjsKIAotICAgIGNwdV9yZXNldChDUFUoY3B1KSk7CisgICAgY3B1
X3Jlc2V0KGNzKTsKIAogICAgIC8qIFNlY29uZGFyeSBDUFUgc3RhcnRzIGluIGhhbHRlZCBzdGF0
ZSBmb3Igbm93LiBOZWVkcyB0byBjaGFuZ2Ugd2hlbgogICAgICAgIGltcGxlbWVudGluZyBub24t
a2VybmVsIGJvb3QuICovCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNzLT5oYWx0ZWQgPSAx
OwogICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiB9CiAKIHN0YXRpYyB2b2lk
IHBwY2U1MDBfY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAgICBQb3dlclBDQ1BVICpjcHUg
PSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVUFBDU3RhdGUg
KmVudiA9ICZjcHUtPmVudjsKICAgICBzdHJ1Y3QgYm9vdF9pbmZvICpiaSA9IGVudi0+bG9hZF9p
bmZvOwogCi0gICAgY3B1X3Jlc2V0KENQVShjcHUpKTsKKyAgICBjcHVfcmVzZXQoY3MpOwogCiAg
ICAgLyogU2V0IGluaXRpYWwgZ3Vlc3Qgc3RhdGUuICovCi0gICAgZW52LT5oYWx0ZWQgPSAwOwor
ICAgIGNzLT5oYWx0ZWQgPSAwOwogICAgIGVudi0+Z3ByWzFdID0gKDE2PDwyMCkgLSA4OwogICAg
IGVudi0+Z3ByWzNdID0gYmktPmR0X2Jhc2U7CiAgICAgZW52LT5uaXAgPSBiaS0+ZW50cnk7CmRp
ZmYgLS1naXQgYS9ody9wcGNlNTAwX3NwaW4uYyBiL2h3L3BwY2U1MDBfc3Bpbi5jCmluZGV4IDdl
OTBmYjkuLjBkMjBhNDMgMTAwNjQ0Ci0tLSBhL2h3L3BwY2U1MDBfc3Bpbi5jCisrKyBiL2h3L3Bw
Y2U1MDBfc3Bpbi5jCkBAIC0xMTIsNyArMTEyLDcgQEAgc3RhdGljIHZvaWQgc3Bpbl9raWNrKHZv
aWQgKmRhdGEpCiAgICAgbWFwX3N0YXJ0ID0gbGRxX3AoJmN1cnNwaW4tPmFkZHIpICYgfihtYXBf
c2l6ZSAtIDEpOwogICAgIG1tdWJvb2tlX2NyZWF0ZV9pbml0aWFsX21hcHBpbmcoZW52LCAwLCBt
YXBfc3RhcnQsIG1hcF9zaXplKTsKIAotICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICBjcHUtPmhh
bHRlZCA9IDA7CiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSAtMTsKICAgICBjcHUtPnN0b3Bw
ZWQgPSBmYWxzZTsKICAgICBxZW11X2NwdV9raWNrKGNwdSk7CmRpZmYgLS1naXQgYS9ody9weGEy
eHhfZ3Bpby5jIGIvaHcvcHhhMnh4X2dwaW8uYwppbmRleCAwNWQyYWQyLi5mMDBkMTUwIDEwMDY0
NAotLS0gYS9ody9weGEyeHhfZ3Bpby5jCisrKyBiL2h3L3B4YTJ4eF9ncGlvLmMKQEAgLTkzLDYg
KzkzLDcgQEAgc3RhdGljIGNvbnN0IGludCBweGEyeHhfZ3Bpb193YWtlW1BYQTJYWF9HUElPX0JB
TktTXSA9IHsKIHN0YXRpYyB2b2lkIHB4YTJ4eF9ncGlvX3NldCh2b2lkICpvcGFxdWUsIGludCBs
aW5lLCBpbnQgbGV2ZWwpCiB7CiAgICAgUFhBMnh4R1BJT0luZm8gKnMgPSAoUFhBMnh4R1BJT0lu
Zm8gKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBDUFUocy0+Y3B1KTsKICAgICBpbnQg
YmFuazsKICAgICB1aW50MzJfdCBtYXNrOwogCkBAIC0xMTgsNyArMTE5LDcgQEAgc3RhdGljIHZv
aWQgcHhhMnh4X2dwaW9fc2V0KHZvaWQgKm9wYXF1ZSwgaW50IGxpbmUsIGludCBsZXZlbCkKICAg
ICAgICAgcHhhMnh4X2dwaW9faXJxX3VwZGF0ZShzKTsKIAogICAgIC8qIFdha2UtdXAgR1BJT3Mg
Ki8KLSAgICBpZiAocy0+Y3B1LT5lbnYuaGFsdGVkICYmIChtYXNrICYgfnMtPmRpcltiYW5rXSAm
IHB4YTJ4eF9ncGlvX3dha2VbYmFua10pKSB7CisgICAgaWYgKGNwdS0+aGFsdGVkICYmIChtYXNr
ICYgfnMtPmRpcltiYW5rXSAmIHB4YTJ4eF9ncGlvX3dha2VbYmFua10pKSB7CiAgICAgICAgIGNw
dV9pbnRlcnJ1cHQoJnMtPmNwdS0+ZW52LCBDUFVfSU5URVJSVVBUX0VYSVRUQik7CiAgICAgfQog
fQpkaWZmIC0tZ2l0IGEvaHcvcHhhMnh4X3BpYy5jIGIvaHcvcHhhMnh4X3BpYy5jCmluZGV4IDkw
YjhmZWYuLmM3M2U3MDkgMTAwNjQ0Ci0tLSBhL2h3L3B4YTJ4eF9waWMuYworKysgYi9ody9weGEy
eHhfcGljLmMKQEAgLTQ2LDggKzQ2LDkgQEAgc3RhdGljIHZvaWQgcHhhMnh4X3BpY191cGRhdGUo
dm9pZCAqb3BhcXVlKQogewogICAgIHVpbnQzMl90IG1hc2tbMl07CiAgICAgUFhBMnh4UElDU3Rh
dGUgKnMgPSAoUFhBMnh4UElDU3RhdGUgKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBD
UFUocy0+Y3B1KTsKIAotICAgIGlmIChzLT5jcHUtPmVudi5oYWx0ZWQpIHsKKyAgICBpZiAoY3B1
LT5oYWx0ZWQpIHsKICAgICAgICAgbWFza1swXSA9IHMtPmludF9wZW5kaW5nWzBdICYgKHMtPmlu
dF9lbmFibGVkWzBdIHwgcy0+aW50X2lkbGUpOwogICAgICAgICBtYXNrWzFdID0gcy0+aW50X3Bl
bmRpbmdbMV0gJiAocy0+aW50X2VuYWJsZWRbMV0gfCBzLT5pbnRfaWRsZSk7CiAgICAgICAgIGlm
IChtYXNrWzBdIHx8IG1hc2tbMV0pIHsKZGlmZiAtLWdpdCBhL2h3L3MzOTB4L3MzOTAtdmlydGlv
LmMgYi9ody9zMzkweC9zMzkwLXZpcnRpby5jCmluZGV4IGUyNWMzMzAuLmNhMjc1YmQgMTAwNjQ0
Ci0tLSBhL2h3L3MzOTB4L3MzOTAtdmlydGlvLmMKKysrIGIvaHcvczM5MHgvczM5MC12aXJ0aW8u
YwpAQCAtMTMyLDIzICsxMzIsMjUgQEAgc3RhdGljIHVuc2lnbmVkIHMzOTBfcnVubmluZ19jcHVz
OwogCiB2b2lkIHMzOTBfYWRkX3J1bm5pbmdfY3B1KFMzOTBDUFUgKmNwdSkKIHsKKyAgICBDUFVT
dGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVTMzkwWFN0YXRlICplbnYgPSAmY3B1LT5lbnY7
CiAKLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBpZiAoY3MtPmhhbHRlZCkgewogICAgICAg
ICBzMzkwX3J1bm5pbmdfY3B1cysrOwotICAgICAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgICAg
IGNzLT5oYWx0ZWQgPSAwOwogICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IC0xOwogICAg
IH0KIH0KIAogdW5zaWduZWQgczM5MF9kZWxfcnVubmluZ19jcHUoUzM5MENQVSAqY3B1KQogewor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVMzOTBYU3RhdGUgKmVudiA9ICZj
cHUtPmVudjsKIAotICAgIGlmIChlbnYtPmhhbHRlZCA9PSAwKSB7CisgICAgaWYgKGNzLT5oYWx0
ZWQgPT0gMCkgewogICAgICAgICBhc3NlcnQoczM5MF9ydW5uaW5nX2NwdXMgPj0gMSk7CiAgICAg
ICAgIHMzOTBfcnVubmluZ19jcHVzLS07Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAg
ICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9I
TFQ7CiAgICAgfQogICAgIHJldHVybiBzMzkwX3J1bm5pbmdfY3B1czsKQEAgLTE4MywxMSArMTg1
LDEzIEBAIHZvaWQgczM5MF9pbml0X2NwdXMoY29uc3QgY2hhciAqY3B1X21vZGVsLCB1aW50OF90
ICpzdG9yYWdlX2tleXMpCiAKICAgICBmb3IgKGkgPSAwOyBpIDwgc21wX2NwdXM7IGkrKykgewog
ICAgICAgICBTMzkwQ1BVICpjcHU7CisgICAgICAgIENQVVN0YXRlICpjczsKIAogICAgICAgICBj
cHUgPSBjcHVfczM5MHhfaW5pdChjcHVfbW9kZWwpOworICAgICAgICBjcyA9IENQVShjcHUpOwog
CiAgICAgICAgIGlwaV9zdGF0ZXNbaV0gPSBjcHU7Ci0gICAgICAgIGNwdS0+ZW52LmhhbHRlZCA9
IDE7CisgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgICAgICBjcHUtPmVudi5leGNlcHRpb25f
aW5kZXggPSBFWENQX0hMVDsKICAgICAgICAgY3B1LT5lbnYuc3RvcmFnZV9rZXlzID0gc3RvcmFn
ZV9rZXlzOwogICAgIH0KZGlmZiAtLWdpdCBhL2h3L3NwYXByLmMgYi9ody9zcGFwci5jCmluZGV4
IGU4OGEyN2EuLmRhNTE4MWMgMTAwNjQ0Ci0tLSBhL2h3L3NwYXByLmMKKysrIGIvaHcvc3BhcHIu
YwpAQCAtNjE2LDYgKzYxNiw4IEBAIHN0YXRpYyB2b2lkIHNwYXByX3Jlc2V0X2h0YWIoc1BBUFJF
bnZpcm9ubWVudCAqc3BhcHIpCiAKIHN0YXRpYyB2b2lkIHBwY19zcGFwcl9yZXNldCh2b2lkKQog
eworICAgIENQVVN0YXRlICpmaXJzdF9jcHVfY3B1OworCiAgICAgLyogUmVzZXQgdGhlIGhhc2gg
dGFibGUgJiByZWNhbGMgdGhlIFJNQSAqLwogICAgIHNwYXByX3Jlc2V0X2h0YWIoc3BhcHIpOwog
CkBAIC02MjYsOSArNjI4LDEwIEBAIHN0YXRpYyB2b2lkIHBwY19zcGFwcl9yZXNldCh2b2lkKQog
ICAgICAgICAgICAgICAgICAgICAgICBzcGFwci0+cnRhc19zaXplKTsKIAogICAgIC8qIFNldCB1
cCB0aGUgZW50cnkgc3RhdGUgKi8KKyAgICBmaXJzdF9jcHVfY3B1ID0gQ1BVKGZpcnN0X2NwdSk7
CiAgICAgZmlyc3RfY3B1LT5ncHJbM10gPSBzcGFwci0+ZmR0X2FkZHI7CiAgICAgZmlyc3RfY3B1
LT5ncHJbNV0gPSAwOwotICAgIGZpcnN0X2NwdS0+aGFsdGVkID0gMDsKKyAgICBmaXJzdF9jcHVf
Y3B1LT5oYWx0ZWQgPSAwOwogICAgIGZpcnN0X2NwdS0+bmlwID0gc3BhcHItPmVudHJ5X3BvaW50
OwogCiB9CkBAIC02MzYsMTQgKzYzOSwxNSBAQCBzdGF0aWMgdm9pZCBwcGNfc3BhcHJfcmVzZXQo
dm9pZCkKIHN0YXRpYyB2b2lkIHNwYXByX2NwdV9yZXNldCh2b2lkICpvcGFxdWUpCiB7CiAgICAg
UG93ZXJQQ0NQVSAqY3B1ID0gb3BhcXVlOworICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwog
ICAgIENQVVBQQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNw
dSkpOworICAgIGNwdV9yZXNldChjcyk7CiAKICAgICAvKiBBbGwgQ1BVcyBzdGFydCBoYWx0ZWQu
ICBDUFUwIGlzIHVuaGFsdGVkIGZyb20gdGhlIG1hY2hpbmUgbGV2ZWwKICAgICAgKiByZXNldCBj
b2RlIGFuZCB0aGUgcmVzdCBhcmUgZXhwbGljaXRseSBzdGFydGVkIHVwIGJ5IHRoZSBndWVzdAog
ICAgICAqIHVzaW5nIGFuIFJUQVMgY2FsbCAqLwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBj
cy0+aGFsdGVkID0gMTsKIAogICAgIGVudi0+c3ByW1NQUl9ISU9SXSA9IDA7CiAKZGlmZiAtLWdp
dCBhL2h3L3NwYXByX2hjYWxsLmMgYi9ody9zcGFwcl9oY2FsbC5jCmluZGV4IGFmMWRiNmUuLjdj
MjgxNDQgMTAwNjQ0Ci0tLSBhL2h3L3NwYXByX2hjYWxsLmMKKysrIGIvaHcvc3BhcHJfaGNhbGwu
YwpAQCAtNTE4LDcgKzUxOCw3IEBAIHN0YXRpYyB0YXJnZXRfdWxvbmcgaF9jZWRlKFBvd2VyUEND
UFUgKmNwdSwgc1BBUFJFbnZpcm9ubWVudCAqc3BhcHIsCiAgICAgZW52LT5tc3IgfD0gKDFVTEwg
PDwgTVNSX0VFKTsKICAgICBocmVnX2NvbXB1dGVfaGZsYWdzKGVudik7CiAgICAgaWYgKCFjcHVf
aGFzX3dvcmsoY3MpKSB7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgY3MtPmhh
bHRlZCA9IDE7CiAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiAgICAg
ICAgIGNzLT5leGl0X3JlcXVlc3QgPSAxOwogICAgIH0KZGlmZiAtLWdpdCBhL2h3L3NwYXByX3J0
YXMuYyBiL2h3L3NwYXByX3J0YXMuYwppbmRleCA1ZWM3ODdmLi5hMjRlODUzIDEwMDY0NAotLS0g
YS9ody9zcGFwcl9ydGFzLmMKKysrIGIvaHcvc3BhcHJfcnRhcy5jCkBAIC0xNDUsNyArMTQ1LDcg
QEAgc3RhdGljIHZvaWQgcnRhc19xdWVyeV9jcHVfc3RvcHBlZF9zdGF0ZShzUEFQUkVudmlyb25t
ZW50ICpzcGFwciwKICAgICAgICAgICAgIGNvbnRpbnVlOwogICAgICAgICB9CiAKLSAgICAgICAg
aWYgKGVudi0+aGFsdGVkKSB7CisgICAgICAgIGlmIChjcHUtPmhhbHRlZCkgewogICAgICAgICAg
ICAgcnRhc19zdChyZXRzLCAxLCAwKTsKICAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgIHJ0
YXNfc3QocmV0cywgMSwgMik7CkBAIC0xODQsNyArMTg0LDcgQEAgc3RhdGljIHZvaWQgcnRhc19z
dGFydF9jcHUoc1BBUFJFbnZpcm9ubWVudCAqc3BhcHIsCiAgICAgICAgICAgICBjb250aW51ZTsK
ICAgICAgICAgfQogCi0gICAgICAgIGlmICghZW52LT5oYWx0ZWQpIHsKKyAgICAgICAgaWYgKCFj
cHUtPmhhbHRlZCkgewogICAgICAgICAgICAgcnRhc19zdChyZXRzLCAwLCAtMSk7CiAgICAgICAg
ICAgICByZXR1cm47CiAgICAgICAgIH0KQEAgLTE5Nyw3ICsxOTcsNyBAQCBzdGF0aWMgdm9pZCBy
dGFzX3N0YXJ0X2NwdShzUEFQUkVudmlyb25tZW50ICpzcGFwciwKICAgICAgICAgZW52LT5tc3Ig
PSAoMVVMTCA8PCBNU1JfU0YpIHwgKDFVTEwgPDwgTVNSX01FKTsKICAgICAgICAgZW52LT5uaXAg
PSBzdGFydDsKICAgICAgICAgZW52LT5ncHJbM10gPSByMzsKLSAgICAgICAgZW52LT5oYWx0ZWQg
PSAwOworICAgICAgICBjcHUtPmhhbHRlZCA9IDA7CiAKICAgICAgICAgcWVtdV9jcHVfa2ljayhj
cHUpOwogCmRpZmYgLS1naXQgYS9ody9zdW40bS5jIGIvaHcvc3VuNG0uYwppbmRleCA5OTAzZjQ0
Li40NWY5NDQxIDEwMDY0NAotLS0gYS9ody9zdW40bS5jCisrKyBiL2h3L3N1bjRtLmMKQEAgLTI1
NiwxMCArMjU2LDExIEBAIHZvaWQgY3B1X2NoZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQog
c3RhdGljIHZvaWQgY3B1X2tpY2tfaXJxKFNQQVJDQ1BVICpjcHUpCiB7CiAgICAgQ1BVU1BBUkNT
dGF0ZSAqZW52ID0gJmNwdS0+ZW52OworICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogCi0g
ICAgZW52LT5oYWx0ZWQgPSAwOworICAgIGNzLT5oYWx0ZWQgPSAwOwogICAgIGNwdV9jaGVja19p
cnFzKGVudik7Ci0gICAgcWVtdV9jcHVfa2ljayhDUFUoY3B1KSk7CisgICAgcWVtdV9jcHVfa2lj
ayhjcyk7CiB9CiAKIHN0YXRpYyB2b2lkIGNwdV9zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IGly
cSwgaW50IGxldmVsKQpAQCAtMjg1LDE5ICsyODYsMTkgQEAgc3RhdGljIHZvaWQgZHVtbXlfY3B1
X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQgaXJxLCBpbnQgbGV2ZWwpCiBzdGF0aWMgdm9pZCBt
YWluX2NwdV9yZXNldCh2b2lkICpvcGFxdWUpCiB7CiAgICAgU1BBUkNDUFUgKmNwdSA9IG9wYXF1
ZTsKLSAgICBDUFVTUEFSQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CisgICAgQ1BVU3RhdGUgKmNz
ID0gQ1BVKGNwdSk7CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNwdSkpOwotICAgIGVudi0+aGFsdGVk
ID0gMDsKKyAgICBjcHVfcmVzZXQoY3MpOworICAgIGNzLT5oYWx0ZWQgPSAwOwogfQogCiBzdGF0
aWMgdm9pZCBzZWNvbmRhcnlfY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAgICBTUEFSQ0NQ
VSAqY3B1ID0gb3BhcXVlOwotICAgIENQVVNQQVJDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKKyAg
ICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKIAotICAgIGNwdV9yZXNldChDUFUoY3B1KSk7Ci0g
ICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNwdV9yZXNldChjcyk7CisgICAgY3MtPmhhbHRlZCA9
IDE7CiB9CiAKIHN0YXRpYyB2b2lkIGNwdV9oYWx0X3NpZ25hbCh2b2lkICpvcGFxdWUsIGludCBp
cnEsIGludCBsZXZlbCkKQEAgLTgyNiw2ICs4MjcsNyBAQCBzdGF0aWMgY29uc3QgVHlwZUluZm8g
cmFtX2luZm8gPSB7CiBzdGF0aWMgdm9pZCBjcHVfZGV2aW5pdChjb25zdCBjaGFyICpjcHVfbW9k
ZWwsIHVuc2lnbmVkIGludCBpZCwKICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2NF90IHBy
b21fYWRkciwgcWVtdV9pcnEgKipjcHVfaXJxcykKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAg
U1BBUkNDUFUgKmNwdTsKICAgICBDUFVTUEFSQ1N0YXRlICplbnY7CiAKQEAgLTg0MSw3ICs4NDMs
OCBAQCBzdGF0aWMgdm9pZCBjcHVfZGV2aW5pdChjb25zdCBjaGFyICpjcHVfbW9kZWwsIHVuc2ln
bmVkIGludCBpZCwKICAgICAgICAgcWVtdV9yZWdpc3Rlcl9yZXNldChtYWluX2NwdV9yZXNldCwg
Y3B1KTsKICAgICB9IGVsc2UgewogICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0KHNlY29uZGFy
eV9jcHVfcmVzZXQsIGNwdSk7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgY3Mg
PSBDUFUoY3B1KTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgfQogICAgICpjcHVfaXJx
cyA9IHFlbXVfYWxsb2NhdGVfaXJxcyhjcHVfc2V0X2lycSwgY3B1LCBNQVhfUElMUyk7CiAgICAg
ZW52LT5wcm9tX2FkZHIgPSBwcm9tX2FkZHI7CmRpZmYgLS1naXQgYS9ody9zdW40dS5jIGIvaHcv
c3VuNHUuYwppbmRleCA5ZmJkYTI5Li4wNTZiYjRkIDEwMDY0NAotLS0gYS9ody9zdW40dS5jCisr
KyBiL2h3L3N1bjR1LmMKQEAgLTI1NCw2ICsyNTQsNyBAQCBzdGF0aWMgdWludDY0X3Qgc3VuNHVf
bG9hZF9rZXJuZWwoY29uc3QgY2hhciAqa2VybmVsX2ZpbGVuYW1lLAogCiB2b2lkIGNwdV9jaGVj
a19pcnFzKENQVVNQQVJDU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAgdWlu
dDMyX3QgcGlsID0gZW52LT5waWxfaW4gfAogICAgICAgICAgICAgICAgICAgKGVudi0+c29mdGlu
dCAmIH4oU09GVElOVF9USU1FUiB8IFNPRlRJTlRfU1RJTUVSKSk7CiAKQEAgLTI2MSw2ICsyNjIs
NyBAQCB2b2lkIGNwdV9jaGVja19pcnFzKENQVVNQQVJDU3RhdGUgKmVudikKICAgICBpZiAoZW52
LT5pdmVjX3N0YXR1cyAmIDB4MjApIHsKICAgICAgICAgcmV0dXJuOwogICAgIH0KKyAgICBjcyA9
IENQVShzcGFyY19lbnZfZ2V0X2NwdShlbnYpKTsKICAgICAvKiBjaGVjayBpZiBUTSBvciBTTSBp
biBTT0ZUSU5UIGFyZSBzZXQKICAgICAgICBzZXR0aW5nIHRoZXNlIGFsc28gY2F1c2VzIGludGVy
cnVwdCAxNCAqLwogICAgIGlmIChlbnYtPnNvZnRpbnQgJiAoU09GVElOVF9USU1FUiB8IFNPRlRJ
TlRfU1RJTUVSKSkgewpAQCAtMjcwLDcgKzI3Miw3IEBAIHZvaWQgY3B1X2NoZWNrX2lycXMoQ1BV
U1BBUkNTdGF0ZSAqZW52KQogICAgIC8qIFRoZSBiaXQgY29ycmVzcG9uZGluZyB0byBwc3JwaWwg
aXMgKDE8PCBwc3JwaWwpLCB0aGUgbmV4dCBiaXQKICAgICAgICBpcyAoMiA8PCBwc3JwaWwpLiAq
LwogICAgIGlmIChwaWwgPCAoMiA8PCBlbnYtPnBzcnBpbCkpewotICAgICAgICBpZiAoZW52LT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgeworICAgICAgICBpZiAoY3Mt
PmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSB7CiAgICAgICAgICAgICBD
UFVJUlFfRFBSSU5URigiUmVzZXQgQ1BVIElSUSAoY3VycmVudCBpbnRlcnJ1cHQgJXgpXG4iLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfaW5kZXgpOwogICAgICAg
ICAgICAgZW52LT5pbnRlcnJ1cHRfaW5kZXggPSAwOwpAQCAtMzAyLDcgKzMwNCw3IEBAIHZvaWQg
Y3B1X2NoZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogICAgICAgICAgICAgICAgIGJyZWFr
OwogICAgICAgICAgICAgfQogICAgICAgICB9Ci0gICAgfSBlbHNlIGlmIChlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSB7CisgICAgfSBlbHNlIGlmIChjcy0+aW50
ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKICAgICAgICAgQ1BVSVJRX0RQ
UklOVEYoIkludGVycnVwdHMgZGlzYWJsZWQsIHBpbD0lMDh4IHBpbF9pbj0lMDh4IHNvZnRpbnQ9
JTA4eCAiCiAgICAgICAgICAgICAgICAgICAgICAgICJjdXJyZW50IGludGVycnVwdCAleFxuIiwK
ICAgICAgICAgICAgICAgICAgICAgICAgcGlsLCBlbnYtPnBpbF9pbiwgZW52LT5zb2Z0aW50LCBl
bnYtPmludGVycnVwdF9pbmRleCk7CkBAIC0zMTMsMjIgKzMxNSwyNSBAQCB2b2lkIGNwdV9jaGVj
a19pcnFzKENQVVNQQVJDU3RhdGUgKmVudikKIAogc3RhdGljIHZvaWQgY3B1X2tpY2tfaXJxKFNQ
QVJDQ1BVICpjcHUpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVU1BB
UkNTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgZW52LT5oYWx0ZWQgPSAwOworICAgIGNz
LT5oYWx0ZWQgPSAwOwogICAgIGNwdV9jaGVja19pcnFzKGVudik7Ci0gICAgcWVtdV9jcHVfa2lj
ayhDUFUoY3B1KSk7CisgICAgcWVtdV9jcHVfa2ljayhjcyk7CiB9CiAKIHN0YXRpYyB2b2lkIGNw
dV9zZXRfaXZlY19pcnEodm9pZCAqb3BhcXVlLCBpbnQgaXJxLCBpbnQgbGV2ZWwpCiB7CiAgICAg
U1BBUkNDUFUgKmNwdSA9IG9wYXF1ZTsKICAgICBDUFVTUEFSQ1N0YXRlICplbnYgPSAmY3B1LT5l
bnY7CisgICAgQ1BVU3RhdGUgKmNzOwogCiAgICAgaWYgKGxldmVsKSB7CiAgICAgICAgIGlmICgh
KGVudi0+aXZlY19zdGF0dXMgJiAweDIwKSkgewogICAgICAgICAgICAgQ1BVSVJRX0RQUklOVEYo
IlJhaXNlIElWRUMgSVJRICVkXG4iLCBpcnEpOwotICAgICAgICAgICAgZW52LT5oYWx0ZWQgPSAw
OworICAgICAgICAgICAgY3MgPSBDUFUoY3B1KTsKKyAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAw
OwogICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfaW5kZXggPSBUVF9JVkVDOwogICAgICAgICAg
ICAgZW52LT5pdmVjX3N0YXR1cyB8PSAweDIwOwogICAgICAgICAgICAgZW52LT5pdmVjX2RhdGFb
MF0gPSAoMHgxZiA8PCA2KSB8IGlycTsKZGlmZiAtLWdpdCBhL2h3L3hlbl9tYWNoaW5lX3B2LmMg
Yi9ody94ZW5fbWFjaGluZV9wdi5jCmluZGV4IDY2ZTg5ODEuLjRmZWM0ZmMgMTAwNjQ0Ci0tLSBh
L2h3L3hlbl9tYWNoaW5lX3B2LmMKKysrIGIvaHcveGVuX21hY2hpbmVfcHYuYwpAQCAtMzYsNyAr
MzYsNyBAQCBzdGF0aWMgdm9pZCB4ZW5faW5pdF9wdihRRU1VTWFjaGluZUluaXRBcmdzICphcmdz
KQogICAgIGNvbnN0IGNoYXIgKmtlcm5lbF9jbWRsaW5lID0gYXJncy0+a2VybmVsX2NtZGxpbmU7
CiAgICAgY29uc3QgY2hhciAqaW5pdHJkX2ZpbGVuYW1lID0gYXJncy0+aW5pdHJkX2ZpbGVuYW1l
OwogICAgIFg4NkNQVSAqY3B1OwotICAgIENQVVg4NlN0YXRlICplbnY7CisgICAgQ1BVU3RhdGUg
KmNzOwogICAgIERyaXZlSW5mbyAqZGluZm87CiAgICAgaW50IGk7CiAKQEAgLTQ5LDggKzQ5LDgg
QEAgc3RhdGljIHZvaWQgeGVuX2luaXRfcHYoUUVNVU1hY2hpbmVJbml0QXJncyAqYXJncykKICNl
bmRpZgogICAgIH0KICAgICBjcHUgPSBjcHVfeDg2X2luaXQoY3B1X21vZGVsKTsKLSAgICBlbnYg
PSAmY3B1LT5lbnY7Ci0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNzID0gQ1BVKGNwdSk7Cisg
ICAgY3MtPmhhbHRlZCA9IDE7CiAKICAgICAvKiBJbml0aWFsaXplIGJhY2tlbmQgY29yZSAmIGRy
aXZlcnMgKi8KICAgICBpZiAoeGVuX2JlX2luaXQoKSAhPSAwKSB7CmRpZmYgLS1naXQgYS9ody94
dGVuc2FfcGljLmMgYi9ody94dGVuc2FfcGljLmMKaW5kZXggOTdkMzZiZS4uZGNhMTViNCAxMDA2
NDQKLS0tIGEvaHcveHRlbnNhX3BpYy5jCisrKyBiL2h3L3h0ZW5zYV9waWMuYwpAQCAtNDcsNiAr
NDcsNyBAQCB2b2lkIHh0ZW5zYV9hZHZhbmNlX2Njb3VudChDUFVYdGVuc2FTdGF0ZSAqZW52LCB1
aW50MzJfdCBkKQogCiB2b2lkIGNoZWNrX2ludGVycnVwdHMoQ1BVWHRlbnNhU3RhdGUgKmVudikK
IHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoeHRlbnNhX2Vudl9nZXRfY3B1KGVudikpOwogICAg
IGludCBtaW5sZXZlbCA9IHh0ZW5zYV9nZXRfY2ludGxldmVsKGVudik7CiAgICAgdWludDMyX3Qg
aW50X3NldF9lbmFibGVkID0gZW52LT5zcmVnc1tJTlRTRVRdICYgZW52LT5zcmVnc1tJTlRFTkFC
TEVdOwogICAgIGludCBsZXZlbDsKQEAgLTU0LDcgKzU1LDcgQEAgdm9pZCBjaGVja19pbnRlcnJ1
cHRzKENQVVh0ZW5zYVN0YXRlICplbnYpCiAgICAgLyogSWYgdGhlIENQVSBpcyBoYWx0ZWQgYWR2
YW5jZSBDQ09VTlQgYWNjb3JkaW5nIHRvIHRoZSB2bV9jbG9jayB0aW1lCiAgICAgICogZWxhcHNl
ZCBzaW5jZSB0aGUgbW9tZW50IHdoZW4gaXQgd2FzIGFkdmFuY2VkIGxhc3QgdGltZS4KICAgICAg
Ki8KLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBpZiAoY3MtPmhhbHRlZCkgewogICAgICAg
ICBpbnQ2NF90IG5vdyA9IHFlbXVfZ2V0X2Nsb2NrX25zKHZtX2Nsb2NrKTsKIAogICAgICAgICB4
dGVuc2FfYWR2YW5jZV9jY291bnQoZW52LApAQCAtMTI3LDExICsxMjgsMTIgQEAgc3RhdGljIHZv
aWQgeHRlbnNhX2Njb21wYXJlX2NiKHZvaWQgKm9wYXF1ZSkKIHsKICAgICBYdGVuc2FDUFUgKmNw
dSA9IG9wYXF1ZTsKICAgICBDUFVYdGVuc2FTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OworICAgIENQ
VVN0YXRlICpjcyA9IENQVShjcHUpOwogCi0gICAgaWYgKGVudi0+aGFsdGVkKSB7CisgICAgaWYg
KGNzLT5oYWx0ZWQpIHsKICAgICAgICAgZW52LT5oYWx0X2Nsb2NrID0gcWVtdV9nZXRfY2xvY2tf
bnModm1fY2xvY2spOwogICAgICAgICB4dGVuc2FfYWR2YW5jZV9jY291bnQoZW52LCBlbnYtPndh
a2VfY2NvdW50IC0gZW52LT5zcmVnc1tDQ09VTlRdKTsKLSAgICAgICAgaWYgKCFjcHVfaGFzX3dv
cmsoQ1BVKGNwdSkpKSB7CisgICAgICAgIGlmICghY3B1X2hhc193b3JrKGNzKSkgewogICAgICAg
ICAgICAgZW52LT5zcmVnc1tDQ09VTlRdID0gZW52LT53YWtlX2Njb3VudCArIDE7CiAgICAgICAg
ICAgICB4dGVuc2FfcmVhcm1fY2NvbXBhcmVfdGltZXIoZW52KTsKICAgICAgICAgfQpkaWZmIC0t
Z2l0IGEvaW5jbHVkZS9leGVjL2NwdS1kZWZzLmggYi9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMuaApp
bmRleCBhZTY0NTkwLi5hNGM2MzcwIDEwMDY0NAotLS0gYS9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMu
aAorKysgYi9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMuaApAQCAtMTU2LDggKzE1Niw2IEBAIHR5cGVk
ZWYgc3RydWN0IENQVVdhdGNocG9pbnQgewogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFj
Y2Vzc2VkICovICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIHRhcmdldF91
bG9uZyBtZW1faW9fdmFkZHI7IC8qIHRhcmdldCB2aXJ0dWFsIGFkZHIgYXQgd2hpY2ggdGhlICAg
ICAgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lbW9yeSB3YXMgYWNj
ZXNzZWQgKi8gICAgICAgICAgICAgXAotICAgIHVpbnQzMl90IGhhbHRlZDsgLyogTm9uemVybyBp
ZiB0aGUgQ1BVIGlzIGluIHN1c3BlbmQgc3RhdGUgKi8gICAgICAgXAotICAgIHVpbnQzMl90IGlu
dGVycnVwdF9yZXF1ZXN0OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAogICAgIENQVV9DT01NT05fVExCICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAogICAgIHN0cnVjdCBUcmFuc2xhdGlvbkJsb2NrICp0Yl9qbXBf
Y2FjaGVbVEJfSk1QX0NBQ0hFX1NJWkVdOyAgICAgICAgICAgXAogICAgIC8qIGJ1ZmZlciBmb3Ig
dGVtcG9yYXJpZXMgaW4gdGhlIGNvZGUgZ2VuZXJhdG9yICovICAgICAgICAgICAgICAgICAgXApk
aWZmIC0tZ2l0IGEvaW5jbHVkZS9xb20vY3B1LmggYi9pbmNsdWRlL3FvbS9jcHUuaAppbmRleCBl
ZTFhN2M4Li45YWQ5ODIyIDEwMDY0NAotLS0gYS9pbmNsdWRlL3FvbS9jcHUuaAorKysgYi9pbmNs
dWRlL3FvbS9jcHUuaApAQCAtNjksNiArNjksOCBAQCBzdHJ1Y3Qga3ZtX3J1bjsKICAqIEBob3N0
X3RpZDogSG9zdCB0aHJlYWQgSUQuCiAgKiBAcnVubmluZzogI3RydWUgaWYgQ1BVIGlzIGN1cnJl
bnRseSBydW5uaW5nICh1c2VybW9kZSkuCiAgKiBAY3JlYXRlZDogSW5kaWNhdGVzIHdoZXRoZXIg
dGhlIENQVSB0aHJlYWQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQuCisgKiBAaW50ZXJy
dXB0X3JlcXVlc3Q6IEluZGljYXRlcyBhIHBlbmRpbmcgaW50ZXJydXB0IHJlcXVlc3QuCisgKiBA
aGFsdGVkOiBOb256ZXJvIGlmIHRoZSBDUFUgaXMgaW4gc3VzcGVuZGVkIHN0YXRlLgogICogQHN0
b3A6IEluZGljYXRlcyBhIHBlbmRpbmcgc3RvcCByZXF1ZXN0LgogICogQHN0b3BwZWQ6IEluZGlj
YXRlcyB0aGUgQ1BVIGhhcyBiZWVuIGFydGlmaWNpYWxseSBzdG9wcGVkLgogICogQGVudl9wdHI6
IFBvaW50ZXIgdG8gc3ViY2xhc3Mtc3BlY2lmaWMgQ1BVQXJjaFN0YXRlIGZpZWxkLgpAQCAtMTAw
LDYgKzEwMiw3IEBAIHN0cnVjdCBDUFVTdGF0ZSB7CiAgICAgYm9vbCBzdG9wOwogICAgIGJvb2wg
c3RvcHBlZDsKICAgICB2b2xhdGlsZSBzaWdfYXRvbWljX3QgZXhpdF9yZXF1ZXN0OworICAgIHVp
bnQzMl90IGludGVycnVwdF9yZXF1ZXN0OwogCiAgICAgdm9pZCAqZW52X3B0cjsgLyogQ1BVQXJj
aFN0YXRlICovCiAgICAgc3RydWN0IFRyYW5zbGF0aW9uQmxvY2sgKmN1cnJlbnRfdGI7CkBAIC0x
MTEsNiArMTE0LDcgQEAgc3RydWN0IENQVVN0YXRlIHsKIAogICAgIC8qIFRPRE8gTW92ZSBjb21t
b24gZmllbGRzIGZyb20gQ1BVQXJjaFN0YXRlIGhlcmUuICovCiAgICAgaW50IGNwdV9pbmRleDsg
LyogdXNlZCBieSBhbHBoYSBUQ0cgKi8KKyAgICB1aW50MzJfdCBoYWx0ZWQ7IC8qIHVzZWQgYnkg
YWxwaGEsIGNyaXMsIHBwYyBUQ0cgKi8KIH07CiAKIApkaWZmIC0tZ2l0IGEva3ZtLWFsbC5jIGIv
a3ZtLWFsbC5jCmluZGV4IDRkZWNmZGMuLjJiNzYxZTAgMTAwNjQ0Ci0tLSBhL2t2bS1hbGwuYwor
KysgYi9rdm0tYWxsLmMKQEAgLTgzMCw3ICs4MzAsNyBAQCBzdGF0aWMgdm9pZCBrdm1faGFuZGxl
X2ludGVycnVwdChDUFVBcmNoU3RhdGUgKmVudiwgaW50IG1hc2spCiB7CiAgICAgQ1BVU3RhdGUg
KmNwdSA9IEVOVl9HRVRfQ1BVKGVudik7CiAKLSAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9
IG1hc2s7CisgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBtYXNrOwogCiAgICAgaWYgKCFx
ZW11X2NwdV9pc19zZWxmKGNwdSkpIHsKICAgICAgICAgcWVtdV9jcHVfa2ljayhjcHUpOwpkaWZm
IC0tZ2l0IGEvcW9tL2NwdS5jIGIvcW9tL2NwdS5jCmluZGV4IDBhMjE5NGQuLjBhYTliZTcgMTAw
NjQ0Ci0tLSBhL3FvbS9jcHUuYworKysgYi9xb20vY3B1LmMKQEAgLTMzLDcgKzMzLDkgQEAgdm9p
ZCBjcHVfcmVzZXQoQ1BVU3RhdGUgKmNwdSkKIHN0YXRpYyB2b2lkIGNwdV9jb21tb25fcmVzZXQo
Q1BVU3RhdGUgKmNwdSkKIHsKICAgICBjcHUtPmV4aXRfcmVxdWVzdCA9IDA7CisgICAgY3B1LT5p
bnRlcnJ1cHRfcmVxdWVzdCA9IDA7CiAgICAgY3B1LT5jdXJyZW50X3RiID0gTlVMTDsKKyAgICBj
cHUtPmhhbHRlZCA9IDA7CiB9CiAKIE9iamVjdENsYXNzICpjcHVfY2xhc3NfYnlfbmFtZShjb25z
dCBjaGFyICp0eXBlbmFtZSwgY29uc3QgY2hhciAqY3B1X21vZGVsKQpkaWZmIC0tZ2l0IGEvdGFy
Z2V0LWFscGhhL2NwdS5oIGIvdGFyZ2V0LWFscGhhL2NwdS5oCmluZGV4IGYxZGI2NTEuLjkwZjc4
YWMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1hbHBoYS9jcHUuaAorKysgYi90YXJnZXQtYWxwaGEvY3B1
LmgKQEAgLTUxNyw4ICs1MTcsNiBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X3NldF90bHMoQ1BV
QWxwaGFTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgbmV3dGxzKQogCiBzdGF0aWMgaW5saW5lIGJv
b2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVQWxwaGFTdGF0ZSAqZW52
ID0gJkFMUEhBX0NQVShjcHUpLT5lbnY7Ci0KICAgICAvKiBIZXJlIHdlIGFyZSBjaGVja2luZyB0
byBzZWUgaWYgdGhlIENQVSBzaG91bGQgd2FrZSB1cCBmcm9tIEhBTFQuCiAgICAgICAgV2Ugd2ls
bCBoYXZlIGdvdHRlbiBpbnRvIHRoaXMgc3RhdGUgb25seSBmb3IgV1RJTlQgZnJvbSBQQUxtb2Rl
LiAgKi8KICAgICAvKiA/Pz8gSSdtIG5vdCBzdXJlIGhvdyB0aGUgSVBMIHN0YXRlIHdvcmtzIHdp
dGggV1RJTlQgdG8ga2VlcCBhIENQVQpAQCAtNTI2LDcgKzUyNCw3IEBAIHN0YXRpYyBpbmxpbmUg
Ym9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKICAgICAgICBhc3N1bWUgdGhhdCBpZiBh
IENQVSByZWFsbHkgd2FudHMgdG8gc3RheSBhc2xlZXAsIGl0IHdpbGwgbWFzawogICAgICAgIGlu
dGVycnVwdHMgYXQgdGhlIGNoaXBzZXQgbGV2ZWwsIHdoaWNoIHdpbGwgcHJldmVudCB0aGVzZSBi
aXRzCiAgICAgICAgZnJvbSBiZWluZyBzZXQgaW4gdGhlIGZpcnN0IHBsYWNlLiAgKi8KLSAgICBy
ZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQKKyAgICBy
ZXR1cm4gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENQVV9JTlRFUlJVUFRfVElNRVIKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENQVV9JTlRFUlJVUFRfU01QCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBDUFVfSU5URVJSVVBUX01DSEsp
OwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWFscGhhL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LWFscGhhL3Ry
YW5zbGF0ZS5jCmluZGV4IGY2ODdiOTUuLmE0ZjcyYjggMTAwNjQ0Ci0tLSBhL3RhcmdldC1hbHBo
YS90cmFuc2xhdGUuYworKysgYi90YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMKQEAgLTE2ODcsNyAr
MTY4Nyw4IEBAIHN0YXRpYyBFeGl0U3RhdHVzIGdlbl9tdHByKERpc2FzQ29udGV4dCAqY3R4LCBp
bnQgcmIsIGludCByZWdubykKICAgICBjYXNlIDI1MzoKICAgICAgICAgLyogV0FJVCAqLwogICAg
ICAgICB0bXAgPSB0Y2dfY29uc3RfaTY0KDEpOwotICAgICAgICB0Y2dfZ2VuX3N0MzJfaTY0KHRt
cCwgY3B1X2Vudiwgb2Zmc2V0b2YoQ1BVQWxwaGFTdGF0ZSwgaGFsdGVkKSk7CisgICAgICAgIHRj
Z19nZW5fc3QzMl9pNjQodG1wLCBjcHVfZW52LCAtb2Zmc2V0b2YoQWxwaGFDUFUsIGVudikgKwor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2Zmc2V0b2YoQ1BVU3RhdGUs
IGhhbHRlZCkpOwogICAgICAgICByZXR1cm4gZ2VuX2V4Y3AoY3R4LCBFWENQX0hMVCwgMCk7CiAK
ICAgICBjYXNlIDI1MjoKZGlmZiAtLWdpdCBhL3RhcmdldC1hcm0vY3B1LmggYi90YXJnZXQtYXJt
L2NwdS5oCmluZGV4IDI5MDJiYTUuLjdjNDc0NjcgMTAwNjQ0Ci0tLSBhL3RhcmdldC1hcm0vY3B1
LmgKKysrIGIvdGFyZ2V0LWFybS9jcHUuaApAQCAtNzIxLDkgKzcyMSw3IEBAIHN0YXRpYyBpbmxp
bmUgdm9pZCBjcHVfZ2V0X3RiX2NwdV9zdGF0ZShDUFVBUk1TdGF0ZSAqZW52LCB0YXJnZXRfdWxv
bmcgKnBjLAogCiBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUp
CiB7Ci0gICAgQ1BVQVJNU3RhdGUgKmVudiA9ICZBUk1fQ1BVKGNwdSktPmVudjsKLQotICAgIHJl
dHVybiBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYKKyAgICByZXR1cm4gY3B1LT5pbnRlcnJ1cHRf
cmVxdWVzdCAmCiAgICAgICAgIChDUFVfSU5URVJSVVBUX0ZJUSB8IENQVV9JTlRFUlJVUFRfSEFS
RCB8IENQVV9JTlRFUlJVUFRfRVhJVFRCKTsKIH0KIApkaWZmIC0tZ2l0IGEvdGFyZ2V0LWFybS9o
ZWxwZXIuYyBiL3RhcmdldC1hcm0vaGVscGVyLmMKaW5kZXggZTYzZGE1Ny4uMzFiN2EzYyAxMDA2
NDQKLS0tIGEvdGFyZ2V0LWFybS9oZWxwZXIuYworKysgYi90YXJnZXQtYXJtL2hlbHBlci5jCkBA
IC0xODAyLDYgKzE4MDIsNyBAQCBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1cHRfdjdtKENQVUFSTVN0
YXRlICplbnYpCiAvKiBIYW5kbGUgYSBDUFUgZXhjZXB0aW9uLiAgKi8KIHZvaWQgZG9faW50ZXJy
dXB0KENQVUFSTVN0YXRlICplbnYpCiB7CisgICAgQ1BVU3RhdGUgKmNzOwogICAgIHVpbnQzMl90
IGFkZHI7CiAgICAgdWludDMyX3QgbWFzazsKICAgICBpbnQgbmV3X21vZGU7CkBAIC0xOTA4LDcg
KzE5MDksOCBAQCB2b2lkIGRvX2ludGVycnVwdChDUFVBUk1TdGF0ZSAqZW52KQogICAgIH0KICAg
ICBlbnYtPnJlZ3NbMTRdID0gZW52LT5yZWdzWzE1XSArIG9mZnNldDsKICAgICBlbnYtPnJlZ3Nb
MTVdID0gYWRkcjsKLSAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRf
RVhJVFRCOworICAgIGNzID0gQ1BVKGFybV9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICBjcy0+aW50
ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiB9CiAKIC8qIENoZWNrIHNl
Y3Rpb24vcGFnZSBhY2Nlc3MgcGVybWlzc2lvbnMuCmRpZmYgLS1naXQgYS90YXJnZXQtYXJtL29w
X2hlbHBlci5jIGIvdGFyZ2V0LWFybS9vcF9oZWxwZXIuYwppbmRleCA5OTYxMGQ3Li43YWY1MTg3
IDEwMDY0NAotLS0gYS90YXJnZXQtYXJtL29wX2hlbHBlci5jCisrKyBiL3RhcmdldC1hcm0vb3Bf
aGVscGVyLmMKQEAgLTIxOCw4ICsyMTgsMTAgQEAgdWludDMyX3QgSEVMUEVSKHVzYXQxNikoQ1BV
QVJNU3RhdGUgKmVudiwgdWludDMyX3QgeCwgdWludDMyX3Qgc2hpZnQpCiAKIHZvaWQgSEVMUEVS
KHdmaSkoQ1BVQVJNU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoYXJtX2Vu
dl9nZXRfY3B1KGVudikpOworCiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsK
LSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgY3B1X2xvb3Bf
ZXhpdChlbnYpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtY3Jpcy9jcHUuaCBiL3RhcmdldC1j
cmlzL2NwdS5oCmluZGV4IGViZjJkNDAuLjJmYzdjNWMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1jcmlz
L2NwdS5oCisrKyBiL3RhcmdldC1jcmlzL2NwdS5oCkBAIC0yODksOSArMjg5LDcgQEAgdm9pZCBj
cmlzX2NwdV9saXN0KEZJTEUgKmYsIGZwcmludGZfZnVuY3Rpb24gY3B1X2ZwcmludGYpOwogCiBz
dGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BV
Q1JJU1N0YXRlICplbnYgPSAmQ1JJU19DUFUoY3B1KS0+ZW52OwotCi0gICAgcmV0dXJuIGVudi0+
aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9O
TUkpOworICAgIHJldHVybiBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRf
SEFSRCB8IENQVV9JTlRFUlJVUFRfTk1JKTsKIH0KIAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwu
aCIKZGlmZiAtLWdpdCBhL3RhcmdldC1jcmlzL2hlbHBlci5jIGIvdGFyZ2V0LWNyaXMvaGVscGVy
LmMKaW5kZXggZGUwNDE0My4uNTFjOWE5ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWNyaXMvaGVscGVy
LmMKKysrIGIvdGFyZ2V0LWNyaXMvaGVscGVyLmMKQEAgLTY2LDYgKzY2LDcgQEAgc3RhdGljIHZv
aWQgY3Jpc19zaGlmdF9jY3MoQ1BVQ1JJU1N0YXRlICplbnYpCiBpbnQgY3B1X2NyaXNfaGFuZGxl
X21tdV9mYXVsdChDUFVDUklTU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIGFkZHJlc3MsIGludCBy
dywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBtbXVfaWR4KQogeworICAgIEQo
Q1BVU3RhdGUgKmNwdSA9IENQVShjcmlzX2Vudl9nZXRfY3B1KGVudikpKTsKICAgICBzdHJ1Y3Qg
Y3Jpc19tbXVfcmVzdWx0IHJlczsKICAgICBpbnQgcHJvdCwgbWlzczsKICAgICBpbnQgciA9IC0x
OwpAQCAtOTksNyArMTAwLDcgQEAgaW50IGNwdV9jcmlzX2hhbmRsZV9tbXVfZmF1bHQoQ1BVQ1JJ
U1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBhZGRyZXNzLCBpbnQgcncsCiAgICAgfQogICAgIGlm
IChyID4gMCkgewogICAgICAgICBEX0xPRygiJXMgcmV0dXJucyAlZCBpcnFyZXE9JXggYWRkcj0l
eCBwaHk9JXggdmVjPSV4IHBjPSV4XG4iLAotICAgICAgICAgICAgICBfX2Z1bmNfXywgciwgZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCwgYWRkcmVzcywgcmVzLnBoeSwKKyAgICAgICAgICAgICAgX19m
dW5jX18sIHIsIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QsIGFkZHJlc3MsIHJlcy5waHksCiAgICAg
ICAgICAgICAgIHJlcy5iZl92ZWMsIGVudi0+cGMpOwogICAgIH0KICAgICByZXR1cm4gcjsKQEAg
LTEwNywxMSArMTA4LDEyIEBAIGludCBjcHVfY3Jpc19oYW5kbGVfbW11X2ZhdWx0KENQVUNSSVNT
dGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgYWRkcmVzcywgaW50IHJ3LAogCiBzdGF0aWMgdm9pZCBk
b19pbnRlcnJ1cHR2MTAoQ1BVQ1JJU1N0YXRlICplbnYpCiB7CisgICAgRChDUFVTdGF0ZSAqY3B1
ID0gQ1BVKGNyaXNfZW52X2dldF9jcHUoZW52KSkpOwogICAgIGludCBleF92ZWMgPSAtMTsKIAog
ICAgIERfTE9HKCJleGNlcHRpb24gaW5kZXg9JWQgaW50ZXJydXB0X3JlcT0lZFxuIiwKICAgICAg
ICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCwKLSAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0KTsKKyAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0KTsKIAogICAgIGFzc2VydCgh
KGVudi0+cHJlZ3NbUFJfQ0NTXSAmIFBGSVhfRkxBRykpOwogICAgIHN3aXRjaCAoZW52LT5leGNl
cHRpb25faW5kZXgpIHsKQEAgLTE2Miw2ICsxNjQsNyBAQCBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1
cHR2MTAoQ1BVQ1JJU1N0YXRlICplbnYpCiAKIHZvaWQgZG9faW50ZXJydXB0KENQVUNSSVNTdGF0
ZSAqZW52KQogeworICAgIEQoQ1BVU3RhdGUgKmNwdSA9IENQVShjcmlzX2Vudl9nZXRfY3B1KGVu
dikpKTsKICAgICBpbnQgZXhfdmVjID0gLTE7CiAKICAgICBpZiAoZW52LT5wcmVnc1tQUl9WUl0g
PCAzMikgewpAQCAtMTcwLDcgKzE3Myw3IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVUNSSVNTdGF0
ZSAqZW52KQogCiAgICAgRF9MT0coImV4Y2VwdGlvbiBpbmRleD0lZCBpbnRlcnJ1cHRfcmVxPSVk
XG4iLAogICAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4LAotICAgICAgICAgIGVudi0+aW50
ZXJydXB0X3JlcXVlc3QpOworICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QpOwogCiAg
ICAgc3dpdGNoIChlbnYtPmV4Y2VwdGlvbl9pbmRleCkgewogICAgIGNhc2UgRVhDUF9CUkVBSzoK
ZGlmZiAtLWdpdCBhL3RhcmdldC1jcmlzL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LWNyaXMvdHJhbnNs
YXRlLmMKaW5kZXggMjVhNDNmYS4uMjJlNWU5ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWNyaXMvdHJh
bnNsYXRlLmMKKysrIGIvdGFyZ2V0LWNyaXMvdHJhbnNsYXRlLmMKQEAgLTI5MjgsNyArMjkyOCw4
IEBAIHN0YXRpYyBpbnQgZGVjX3JmZV9ldGMoQ1BVQ1JJU1N0YXRlICplbnYsIERpc2FzQ29udGV4
dCAqZGMpCiAgICAgY3Jpc19jY19tYXNrKGRjLCAwKTsKIAogICAgIGlmIChkYy0+b3AyID09IDE1
KSB7Ci0gICAgICAgIHRfZ2VuX21vdl9lbnZfVE4oaGFsdGVkLCB0Y2dfY29uc3RfdGwoMSkpOwor
ICAgICAgICB0Y2dfZ2VuX3N0X2kzMih0Y2dfY29uc3RfaTMyKDEpLCBjcHVfZW52LAorICAgICAg
ICAgICAgICAgICAgICAgICAtb2Zmc2V0b2YoQ1JJU0NQVSwgZW52KSArIG9mZnNldG9mKENQVVN0
YXRlLCBoYWx0ZWQpKTsKICAgICAgICAgdGNnX2dlbl9tb3ZpX3RsKGVudl9wYywgZGMtPnBjICsg
Mik7CiAgICAgICAgIHRfZ2VuX3JhaXNlX2V4Y2VwdGlvbihFWENQX0hMVCk7CiAgICAgICAgIHJl
dHVybiAyOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYvY3B1LmMgYi90YXJnZXQtaTM4Ni9jcHUu
YwppbmRleCA4YWQ4ZjIyLi5iODkyZGEwIDEwMDY0NAotLS0gYS90YXJnZXQtaTM4Ni9jcHUuYwor
KysgYi90YXJnZXQtaTM4Ni9jcHUuYwpAQCAtMTk4MCw3ICsxOTgwLDcgQEAgc3RhdGljIHZvaWQg
eDg2X2NwdV9yZXNldChDUFVTdGF0ZSAqcykKICAgICAgICAgYXBpY19kZXNpZ25hdGVfYnNwKGVu
di0+YXBpY19zdGF0ZSk7CiAgICAgfQogCi0gICAgZW52LT5oYWx0ZWQgPSAhY3B1X2lzX2JzcChj
cHUpOworICAgIHMtPmhhbHRlZCA9ICFjcHVfaXNfYnNwKGNwdSk7CiAjZW5kaWYKIH0KIApkaWZm
IC0tZ2l0IGEvdGFyZ2V0LWkzODYvY3B1LmggYi90YXJnZXQtaTM4Ni9jcHUuaAppbmRleCA5ZTZl
MWE2Li40MGNmMjQ2IDEwMDY0NAotLS0gYS90YXJnZXQtaTM4Ni9jcHUuaAorKysgYi90YXJnZXQt
aTM4Ni9jcHUuaApAQCAtOTU2LDYgKzk1Niw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBjcHVfeDg2
X2xvYWRfc2VnX2NhY2hlKENQVVg4NlN0YXRlICplbnYsCiBzdGF0aWMgaW5saW5lIHZvaWQgY3B1
X3g4Nl9sb2FkX3NlZ19jYWNoZV9zaXBpKFg4NkNQVSAqY3B1LAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgc2lwaV92ZWN0b3IpCiB7CisgICAgQ1BV
U3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsK
IAogICAgIGVudi0+ZWlwID0gMDsKQEAgLTk2Myw3ICs5NjQsNyBAQCBzdGF0aWMgaW5saW5lIHZv
aWQgY3B1X3g4Nl9sb2FkX3NlZ19jYWNoZV9zaXBpKFg4NkNQVSAqY3B1LAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lwaV92ZWN0b3IgPDwgMTIsCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBlbnYtPnNlZ3NbUl9DU10ubGltaXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBl
bnYtPnNlZ3NbUl9DU10uZmxhZ3MpOwotICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICBjcy0+aGFs
dGVkID0gMDsKIH0KIAogaW50IGNwdV94ODZfZ2V0X2Rlc2NyX2RlYnVnKENQVVg4NlN0YXRlICpl
bnYsIHVuc2lnbmVkIGludCBzZWxlY3RvciwKQEAgLTExNTcsMTcgKzExNTgsMTggQEAgc3RhdGlj
IGlubGluZSB2b2lkIGNwdV9jbG9uZV9yZWdzKENQVVg4NlN0YXRlICplbnYsIHRhcmdldF91bG9u
ZyBuZXdzcCkKICNpbmNsdWRlICJody9hcGljLmgiCiAjZW5kaWYKIAotc3RhdGljIGlubGluZSBi
b29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQorc3RhdGljIGlubGluZSBib29sIGNwdV9o
YXNfd29yayhDUFVTdGF0ZSAqY3MpCiB7Ci0gICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZYODZfQ1BV
KGNwdSktPmVudjsKKyAgICBYODZDUFUgKmNwdSA9IFg4Nl9DUFUoY3MpOworICAgIENQVVg4NlN0
YXRlICplbnYgPSAmY3B1LT5lbnY7CiAKLSAgICByZXR1cm4gKChlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBDUFVfSU5URVJSVVBUX1BPTEwpKSAmJgorICAgIHJldHVybiAoKGNzLT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX1BPTEwpKSAmJgogICAgICAgICAgICAg
KGVudi0+ZWZsYWdzICYgSUZfTUFTSykpIHx8Ci0gICAgICAgICAgIChlbnYtPmludGVycnVwdF9y
ZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfTk1JIHwKLSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9JTklUIHwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9TSVBJIHwKLSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9NQ0UpKTsKKyAgICAgICAgICAgKGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX05NSSB8CisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9JTklUIHwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX1NJUEkgfAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfTUNFKSk7CiB9CiAKICNpbmNs
dWRlICJleGVjL2V4ZWMtYWxsLmgiCmRpZmYgLS1naXQgYS90YXJnZXQtaTM4Ni9oZWxwZXIuYyBi
L3RhcmdldC1pMzg2L2hlbHBlci5jCmluZGV4IDFhODcyZmEuLjgwOGQ4NzkgMTAwNjQ0Ci0tLSBh
L3RhcmdldC1pMzg2L2hlbHBlci5jCisrKyBiL3RhcmdldC1pMzg2L2hlbHBlci5jCkBAIC0xNzEs
NiArMTcxLDcgQEAgZG9uZToKIHZvaWQgY3B1X2R1bXBfc3RhdGUoQ1BVWDg2U3RhdGUgKmVudiwg
RklMRSAqZiwgZnByaW50Zl9mdW5jdGlvbiBjcHVfZnByaW50ZiwKICAgICAgICAgICAgICAgICAg
ICAgaW50IGZsYWdzKQogeworICAgIENQVVN0YXRlICpjcyA9IENQVSh4ODZfZW52X2dldF9jcHUo
ZW52KSk7CiAgICAgaW50IGVmbGFncywgaSwgbmI7CiAgICAgY2hhciBjY19vcF9uYW1lWzMyXTsK
ICAgICBzdGF0aWMgY29uc3QgY2hhciAqc2VnX25hbWVbNl0gPSB7ICJFUyIsICJDUyIsICJTUyIs
ICJEUyIsICJGUyIsICJHUyIgfTsKQEAgLTIxNCw3ICsyMTUsNyBAQCB2b2lkIGNwdV9kdW1wX3N0
YXRlKENQVVg4NlN0YXRlICplbnYsIEZJTEUgKmYsIGZwcmludGZfZnVuY3Rpb24gY3B1X2Zwcmlu
dGYsCiAgICAgICAgICAgICAgICAgICAgIChlbnYtPmhmbGFncyA+PiBIRl9JTkhJQklUX0lSUV9T
SElGVCkgJiAxLAogICAgICAgICAgICAgICAgICAgICAoZW52LT5hMjBfbWFzayA+PiAyMCkgJiAx
LAogICAgICAgICAgICAgICAgICAgICAoZW52LT5oZmxhZ3MgPj4gSEZfU01NX1NISUZUKSAmIDEs
Ci0gICAgICAgICAgICAgICAgICAgIGVudi0+aGFsdGVkKTsKKyAgICAgICAgICAgICAgICAgICAg
Y3MtPmhhbHRlZCk7CiAgICAgfSBlbHNlCiAjZW5kaWYKICAgICB7CkBAIC0yNDEsNyArMjQyLDcg
QEAgdm9pZCBjcHVfZHVtcF9zdGF0ZShDUFVYODZTdGF0ZSAqZW52LCBGSUxFICpmLCBmcHJpbnRm
X2Z1bmN0aW9uIGNwdV9mcHJpbnRmLAogICAgICAgICAgICAgICAgICAgICAoZW52LT5oZmxhZ3Mg
Pj4gSEZfSU5ISUJJVF9JUlFfU0hJRlQpICYgMSwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+
YTIwX21hc2sgPj4gMjApICYgMSwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+aGZsYWdzID4+
IEhGX1NNTV9TSElGVCkgJiAxLAotICAgICAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCk7Cisg
ICAgICAgICAgICAgICAgICAgIGNzLT5oYWx0ZWQpOwogICAgIH0KIAogICAgIGZvcihpID0gMDsg
aSA8IDY7IGkrKykgewpAQCAtMTI5NCwxMiArMTI5NSwxMyBAQCBYODZDUFUgKmNwdV94ODZfaW5p
dChjb25zdCBjaGFyICpjcHVfbW9kZWwpCiAjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkK
IHZvaWQgZG9fY3B1X2luaXQoWDg2Q1BVICpjcHUpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BV
KGNwdSk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKLSAgICBpbnQgc2lwaSA9
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1NJUEk7CisgICAgaW50IHNp
cGkgPSBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1NJUEk7CiAgICAgdWlu
dDY0X3QgcGF0ID0gZW52LT5wYXQ7CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNwdSkpOwotICAgIGVu
di0+aW50ZXJydXB0X3JlcXVlc3QgPSBzaXBpOworICAgIGNwdV9yZXNldChjcyk7CisgICAgY3Mt
PmludGVycnVwdF9yZXF1ZXN0ID0gc2lwaTsKICAgICBlbnYtPnBhdCA9IHBhdDsKICAgICBhcGlj
X2luaXRfcmVzZXQoZW52LT5hcGljX3N0YXRlKTsKIH0KZGlmZiAtLWdpdCBhL3RhcmdldC1pMzg2
L2t2bS5jIGIvdGFyZ2V0LWkzODYva3ZtLmMKaW5kZXggMGNmNDEzZC4uZGYzMGZhNiAxMDA2NDQK
LS0tIGEvdGFyZ2V0LWkzODYva3ZtLmMKKysrIGIvdGFyZ2V0LWkzODYva3ZtLmMKQEAgLTE0NjAs
MTcgKzE0NjAsMTggQEAgc3RhdGljIGludCBrdm1fcHV0X21wX3N0YXRlKFg4NkNQVSAqY3B1KQog
CiBzdGF0aWMgaW50IGt2bV9nZXRfbXBfc3RhdGUoWDg2Q1BVICpjcHUpCiB7CisgICAgQ1BVU3Rh
dGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKICAg
ICBzdHJ1Y3Qga3ZtX21wX3N0YXRlIG1wX3N0YXRlOwogICAgIGludCByZXQ7CiAKLSAgICByZXQg
PSBrdm1fdmNwdV9pb2N0bChDUFUoY3B1KSwgS1ZNX0dFVF9NUF9TVEFURSwgJm1wX3N0YXRlKTsK
KyAgICByZXQgPSBrdm1fdmNwdV9pb2N0bChjcywgS1ZNX0dFVF9NUF9TVEFURSwgJm1wX3N0YXRl
KTsKICAgICBpZiAocmV0IDwgMCkgewogICAgICAgICByZXR1cm4gcmV0OwogICAgIH0KICAgICBl
bnYtPm1wX3N0YXRlID0gbXBfc3RhdGUubXBfc3RhdGU7CiAgICAgaWYgKGt2bV9pcnFjaGlwX2lu
X2tlcm5lbCgpKSB7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gKG1wX3N0YXRlLm1wX3N0YXRlID09
IEtWTV9NUF9TVEFURV9IQUxURUQpOworICAgICAgICBjcy0+aGFsdGVkID0gKG1wX3N0YXRlLm1w
X3N0YXRlID09IEtWTV9NUF9TVEFURV9IQUxURUQpOwogICAgIH0KICAgICByZXR1cm4gMDsKIH0K
QEAgLTE3NjIsOCArMTc2Myw4IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihDUFVTdGF0ZSAqY3B1
LCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogICAgIGludCByZXQ7CiAKICAgICAvKiBJbmplY3QgTk1J
ICovCi0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkg
ewotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX05NSTsK
KyAgICBpZiAoY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfTk1JKSB7Cisg
ICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfTk1JOwogICAg
ICAgICBEUFJJTlRGKCJpbmplY3RlZCBOTUlcbiIpOwogICAgICAgICByZXQgPSBrdm1fdmNwdV9p
b2N0bChjcHUsIEtWTV9OTUkpOwogICAgICAgICBpZiAocmV0IDwgMCkgewpAQCAtMTc3NSwxOCAr
MTc3NiwxOCBAQCB2b2lkIGt2bV9hcmNoX3ByZV9ydW4oQ1BVU3RhdGUgKmNwdSwgc3RydWN0IGt2
bV9ydW4gKnJ1bikKICAgICBpZiAoIWt2bV9pcnFjaGlwX2luX2tlcm5lbCgpKSB7CiAgICAgICAg
IC8qIEZvcmNlIHRoZSBWQ1BVIG91dCBvZiBpdHMgaW5uZXIgbG9vcCB0byBwcm9jZXNzIGFueSBJ
TklUIHJlcXVlc3RzCiAgICAgICAgICAqIG9yIHBlbmRpbmcgVFBSIGFjY2VzcyByZXBvcnRzLiAq
LwotICAgICAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmCisgICAgICAgIGlmIChjcHUt
PmludGVycnVwdF9yZXF1ZXN0ICYKICAgICAgICAgICAgIChDUFVfSU5URVJSVVBUX0lOSVQgfCBD
UFVfSU5URVJSVVBUX1RQUikpIHsKICAgICAgICAgICAgIGNwdS0+ZXhpdF9yZXF1ZXN0ID0gMTsK
ICAgICAgICAgfQogCiAgICAgICAgIC8qIFRyeSB0byBpbmplY3QgYW4gaW50ZXJydXB0IGlmIHRo
ZSBndWVzdCBjYW4gYWNjZXB0IGl0ICovCiAgICAgICAgIGlmIChydW4tPnJlYWR5X2Zvcl9pbnRl
cnJ1cHRfaW5qZWN0aW9uICYmCi0gICAgICAgICAgICAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKKyAgICAgICAgICAgIChjcHUtPmludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAgICAgICAgKGVudi0+ZWZsYWdzICYg
SUZfTUFTSykpIHsKICAgICAgICAgICAgIGludCBpcnE7CiAKLSAgICAgICAgICAgIGVudi0+aW50
ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICAgICAgICAgIGNwdS0+
aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFSRDsKICAgICAgICAgICAgIGly
cSA9IGNwdV9nZXRfcGljX2ludGVycnVwdChlbnYpOwogICAgICAgICAgICAgaWYgKGlycSA+PSAw
KSB7CiAgICAgICAgICAgICAgICAgc3RydWN0IGt2bV9pbnRlcnJ1cHQgaW50cjsKQEAgLTE4MDYs
NyArMTgwNyw3IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihDUFVTdGF0ZSAqY3B1LCBzdHJ1Y3Qg
a3ZtX3J1biAqcnVuKQogICAgICAgICAgKiBpbnRlcnJ1cHQsIHJlcXVlc3QgYW4gaW50ZXJydXB0
IHdpbmRvdyBleGl0LiAgVGhpcyB3aWxsCiAgICAgICAgICAqIGNhdXNlIGEgcmV0dXJuIHRvIHVz
ZXJzcGFjZSBhcyBzb29uIGFzIHRoZSBndWVzdCBpcyByZWFkeSB0bwogICAgICAgICAgKiByZWNl
aXZlIGludGVycnVwdHMuICovCi0gICAgICAgIGlmICgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfSEFSRCkpIHsKKyAgICAgICAgaWYgKChjcHUtPmludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSkgewogICAgICAgICAgICAgcnVuLT5yZXF1ZXN0X2lu
dGVycnVwdF93aW5kb3cgPSAxOwogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAgcnVuLT5y
ZXF1ZXN0X2ludGVycnVwdF93aW5kb3cgPSAwOwpAQCAtMTgzNiwxMSArMTgzNywxMSBAQCBpbnQg
a3ZtX2FyY2hfcHJvY2Vzc19hc3luY19ldmVudHMoQ1BVU3RhdGUgKmNzKQogICAgIFg4NkNQVSAq
Y3B1ID0gWDg2X0NQVShjcyk7CiAgICAgQ1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKIAot
ICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9NQ0UpIHsKKyAg
ICBpZiAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9NQ0UpIHsKICAgICAg
ICAgLyogV2UgbXVzdCBub3QgcmFpc2UgQ1BVX0lOVEVSUlVQVF9NQ0UgaWYgaXQncyBub3Qgc3Vw
cG9ydGVkLiAqLwogICAgICAgICBhc3NlcnQoZW52LT5tY2dfY2FwKTsKIAotICAgICAgICBlbnYt
PmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKKyAgICAgICAgY3MtPmlu
dGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKIAogICAgICAgICBrdm1fY3B1
X3N5bmNocm9uaXplX3N0YXRlKGVudik7CiAKQEAgLTE4NTMsNyArMTg1NCw3IEBAIGludCBrdm1f
YXJjaF9wcm9jZXNzX2FzeW5jX2V2ZW50cyhDUFVTdGF0ZSAqY3MpCiAgICAgICAgIGVudi0+ZXhj
ZXB0aW9uX2luamVjdGVkID0gRVhDUDEyX01DSEs7CiAgICAgICAgIGVudi0+aGFzX2Vycm9yX2Nv
ZGUgPSAwOwogCi0gICAgICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICAgICAgY3MtPmhhbHRlZCA9
IDA7CiAgICAgICAgIGlmIChrdm1faXJxY2hpcF9pbl9rZXJuZWwoKSAmJiBlbnYtPm1wX3N0YXRl
ID09IEtWTV9NUF9TVEFURV9IQUxURUQpIHsKICAgICAgICAgICAgIGVudi0+bXBfc3RhdGUgPSBL
Vk1fTVBfU1RBVEVfUlVOTkFCTEU7CiAgICAgICAgIH0KQEAgLTE4NjMsNDEgKzE4NjQsNDIgQEAg
aW50IGt2bV9hcmNoX3Byb2Nlc3NfYXN5bmNfZXZlbnRzKENQVVN0YXRlICpjcykKICAgICAgICAg
cmV0dXJuIDA7CiAgICAgfQogCi0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVf
SU5URVJSVVBUX1BPTEwpIHsKLSAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BV
X0lOVEVSUlVQVF9QT0xMOworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5U
RVJSVVBUX1BPTEwpIHsKKyAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5U
RVJSVVBUX1BPTEw7CiAgICAgICAgIGFwaWNfcG9sbF9pcnEoZW52LT5hcGljX3N0YXRlKTsKICAg
ICB9Ci0gICAgaWYgKCgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFS
RCkgJiYKKyAgICBpZiAoKChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hB
UkQpICYmCiAgICAgICAgICAoZW52LT5lZmxhZ3MgJiBJRl9NQVNLKSkgfHwKLSAgICAgICAgKGVu
di0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkpIHsKLSAgICAgICAgZW52
LT5oYWx0ZWQgPSAwOworICAgICAgICAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9OTUkpKSB7CisgICAgICAgIGNzLT5oYWx0ZWQgPSAwOwogICAgIH0KLSAgICBpZiAoZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSU5JVCkgeworICAgIGlmIChjcy0+
aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0lOSVQpIHsKICAgICAgICAga3ZtX2Nw
dV9zeW5jaHJvbml6ZV9zdGF0ZShlbnYpOwogICAgICAgICBkb19jcHVfaW5pdChjcHUpOwogICAg
IH0KLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfU0lQSSkg
eworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1NJUEkpIHsK
ICAgICAgICAga3ZtX2NwdV9zeW5jaHJvbml6ZV9zdGF0ZShlbnYpOwogICAgICAgICBkb19jcHVf
c2lwaShjcHUpOwogICAgIH0KLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9J
TlRFUlJVUFRfVFBSKSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9J
TlRFUlJVUFRfVFBSOworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX1RQUikgeworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJV
UFRfVFBSOwogICAgICAgICBrdm1fY3B1X3N5bmNocm9uaXplX3N0YXRlKGVudik7CiAgICAgICAg
IGFwaWNfaGFuZGxlX3Rwcl9hY2Nlc3NfcmVwb3J0KGVudi0+YXBpY19zdGF0ZSwgZW52LT5laXAs
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+dHByX2FjY2Vzc190
eXBlKTsKICAgICB9CiAKLSAgICByZXR1cm4gZW52LT5oYWx0ZWQ7CisgICAgcmV0dXJuIGNzLT5o
YWx0ZWQ7CiB9CiAKIHN0YXRpYyBpbnQga3ZtX2hhbmRsZV9oYWx0KFg4NkNQVSAqY3B1KQogewor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVg4NlN0YXRlICplbnYgPSAmY3B1
LT5lbnY7CiAKLSAgICBpZiAoISgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJV
UFRfSEFSRCkgJiYKKyAgICBpZiAoISgoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9IQVJEKSAmJgogICAgICAgICAgIChlbnYtPmVmbGFncyAmIElGX01BU0spKSAmJgotICAg
ICAgICAhKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkpIHsKLSAg
ICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICAhKGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfTk1JKSkgeworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAg
cmV0dXJuIEVYQ1BfSExUOwogICAgIH0KIApkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYvbWlzY19o
ZWxwZXIuYyBiL3RhcmdldC1pMzg2L21pc2NfaGVscGVyLmMKaW5kZXggYjZkNTc0MC4uZGZiYzA3
YiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvbWlzY19oZWxwZXIuYworKysgYi90YXJnZXQtaTM4
Ni9taXNjX2hlbHBlci5jCkBAIC01NTMsMjAgKzU1MywyNSBAQCB2b2lkIGhlbHBlcl9yZG1zcihD
UFVYODZTdGF0ZSAqZW52KQogfQogI2VuZGlmCiAKLXN0YXRpYyB2b2lkIGRvX2hsdChDUFVYODZT
dGF0ZSAqZW52KQorc3RhdGljIHZvaWQgZG9faGx0KFg4NkNQVSAqY3B1KQogeworICAgIENQVVN0
YXRlICpjcyA9IENQVShjcHUpOworICAgIENQVVg4NlN0YXRlICplbnYgPSAmY3B1LT5lbnY7CisK
ICAgICBlbnYtPmhmbGFncyAmPSB+SEZfSU5ISUJJVF9JUlFfTUFTSzsgLyogbmVlZGVkIGlmIHN0
aSBpcyBqdXN0IGJlZm9yZSAqLwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcy0+aGFsdGVk
ID0gMTsKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgIGNwdV9sb29w
X2V4aXQoZW52KTsKIH0KIAogdm9pZCBoZWxwZXJfaGx0KENQVVg4NlN0YXRlICplbnYsIGludCBu
ZXh0X2VpcF9hZGRlbmQpCiB7CisgICAgWDg2Q1BVICpjcHUgPSB4ODZfZW52X2dldF9jcHUoZW52
KTsKKwogICAgIGNwdV9zdm1fY2hlY2tfaW50ZXJjZXB0X3BhcmFtKGVudiwgU1ZNX0VYSVRfSExU
LCAwKTsKICAgICBFSVAgKz0gbmV4dF9laXBfYWRkZW5kOwogCi0gICAgZG9faGx0KGVudik7Cisg
ICAgZG9faGx0KGNwdSk7CiB9CiAKIHZvaWQgaGVscGVyX21vbml0b3IoQ1BVWDg2U3RhdGUgKmVu
diwgdGFyZ2V0X3Vsb25nIHB0cikKQEAgLTU4MCw3ICs1ODUsOCBAQCB2b2lkIGhlbHBlcl9tb25p
dG9yKENQVVg4NlN0YXRlICplbnYsIHRhcmdldF91bG9uZyBwdHIpCiAKIHZvaWQgaGVscGVyX213
YWl0KENQVVg4NlN0YXRlICplbnYsIGludCBuZXh0X2VpcF9hZGRlbmQpCiB7Ci0gICAgQ1BVU3Rh
dGUgKmNwdTsKKyAgICBDUFVTdGF0ZSAqY3M7CisgICAgWDg2Q1BVICpjcHU7CiAKICAgICBpZiAo
KHVpbnQzMl90KUVDWCAhPSAwKSB7CiAgICAgICAgIHJhaXNlX2V4Y2VwdGlvbihlbnYsIEVYQ1Aw
RF9HUEYpOwpAQCAtNTg4LDEzICs1OTQsMTQgQEAgdm9pZCBoZWxwZXJfbXdhaXQoQ1BVWDg2U3Rh
dGUgKmVudiwgaW50IG5leHRfZWlwX2FkZGVuZCkKICAgICBjcHVfc3ZtX2NoZWNrX2ludGVyY2Vw
dF9wYXJhbShlbnYsIFNWTV9FWElUX01XQUlULCAwKTsKICAgICBFSVAgKz0gbmV4dF9laXBfYWRk
ZW5kOwogCi0gICAgY3B1ID0gQ1BVKHg4Nl9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICBjcHUgPSB4
ODZfZW52X2dldF9jcHUoZW52KTsKKyAgICBjcyA9IENQVShjcHUpOwogICAgIC8qIFhYWDogbm90
IGNvbXBsZXRlIGJ1dCBub3QgY29tcGxldGVseSBlcnJvbmVvdXMgKi8KLSAgICBpZiAoY3B1LT5j
cHVfaW5kZXggIT0gMCB8fCBlbnYtPm5leHRfY3B1ICE9IE5VTEwpIHsKKyAgICBpZiAoY3MtPmNw
dV9pbmRleCAhPSAwIHx8IGVudi0+bmV4dF9jcHUgIT0gTlVMTCkgewogICAgICAgICAvKiBtb3Jl
IHRoYW4gb25lIENQVTogZG8gbm90IHNsZWVwIGJlY2F1c2UgYW5vdGhlciBDUFUgbWF5CiAgICAg
ICAgICAgIHdha2UgdGhpcyBvbmUgKi8KICAgICB9IGVsc2UgewotICAgICAgICBkb19obHQoZW52
KTsKKyAgICAgICAgZG9faGx0KGNwdSk7CiAgICAgfQogfQogCmRpZmYgLS1naXQgYS90YXJnZXQt
aTM4Ni9zdm1faGVscGVyLmMgYi90YXJnZXQtaTM4Ni9zdm1faGVscGVyLmMKaW5kZXggM2YyNDZl
OS4uYzQ2YTIxMyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvc3ZtX2hlbHBlci5jCisrKyBiL3Rh
cmdldC1pMzg2L3N2bV9oZWxwZXIuYwpAQCAtMjcxLDcgKzI3MSw5IEBAIHZvaWQgaGVscGVyX3Zt
cnVuKENQVVg4NlN0YXRlICplbnYsIGludCBhZmxhZywgaW50IG5leHRfZWlwX2FkZGVuZCkKICAg
ICBlbnYtPmhmbGFnczIgfD0gSEYyX0dJRl9NQVNLOwogCiAgICAgaWYgKGludF9jdGwgJiBWX0lS
UV9NQVNLKSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQ
VF9WSVJROworICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoeDg2X2Vudl9nZXRfY3B1KGVudikp
OworCisgICAgICAgIGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX1ZJUlE7
CiAgICAgfQogCiAgICAgLyogbWF5YmUgd2UgbmVlZCB0byBpbmplY3QgYW4gZXZlbnQgKi8KQEAg
LTU0OCw2ICs1NTAsNyBAQCB2b2lkIGhlbHBlcl9zdm1fY2hlY2tfaW8oQ1BVWDg2U3RhdGUgKmVu
diwgdWludDMyX3QgcG9ydCwgdWludDMyX3QgcGFyYW0sCiAvKiBOb3RlOiBjdXJyZW50bHkgb25s
eSAzMiBiaXRzIG9mIGV4aXRfY29kZSBhcmUgdXNlZCAqLwogdm9pZCBoZWxwZXJfdm1leGl0KENQ
VVg4NlN0YXRlICplbnYsIHVpbnQzMl90IGV4aXRfY29kZSwgdWludDY0X3QgZXhpdF9pbmZvXzEp
CiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHg4Nl9lbnZfZ2V0X2NwdShlbnYpKTsKICAgICB1
aW50MzJfdCBpbnRfY3RsOwogCiAgICAgcWVtdV9sb2dfbWFzayhDUFVfTE9HX1RCX0lOX0FTTSwg
InZtZXhpdCglMDh4LCAlMDE2IiBQUkl4NjQgIiwgJTAxNiIKQEAgLTU5NCw3ICs1OTcsNyBAQCB2
b2lkIGhlbHBlcl92bWV4aXQoQ1BVWDg2U3RhdGUgKmVudiwgdWludDMyX3QgZXhpdF9jb2RlLCB1
aW50NjRfdCBleGl0X2luZm9fMSkKICAgICBpbnRfY3RsID0gbGRsX3BoeXMoZW52LT52bV92bWNi
ICsgb2Zmc2V0b2Yoc3RydWN0IHZtY2IsIGNvbnRyb2wuaW50X2N0bCkpOwogICAgIGludF9jdGwg
Jj0gfihWX1RQUl9NQVNLIHwgVl9JUlFfTUFTSyk7CiAgICAgaW50X2N0bCB8PSBlbnYtPnZfdHBy
ICYgVl9UUFJfTUFTSzsKLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRF
UlJVUFRfVklSUSkgeworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX1ZJUlEpIHsKICAgICAgICAgaW50X2N0bCB8PSBWX0lSUV9NQVNLOwogICAgIH0KICAgICBz
dGxfcGh5cyhlbnYtPnZtX3ZtY2IgKyBvZmZzZXRvZihzdHJ1Y3Qgdm1jYiwgY29udHJvbC5pbnRf
Y3RsKSwgaW50X2N0bCk7CkBAIC02MTUsNyArNjE4LDcgQEAgdm9pZCBoZWxwZXJfdm1leGl0KENQ
VVg4NlN0YXRlICplbnYsIHVpbnQzMl90IGV4aXRfY29kZSwgdWludDY0X3QgZXhpdF9pbmZvXzEp
CiAgICAgZW52LT5oZmxhZ3MgJj0gfkhGX1NWTUlfTUFTSzsKICAgICBlbnYtPmludGVyY2VwdCA9
IDA7CiAgICAgZW52LT5pbnRlcmNlcHRfZXhjZXB0aW9ucyA9IDA7Ci0gICAgZW52LT5pbnRlcnJ1
cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9WSVJROworICAgIGNzLT5pbnRlcnJ1cHRfcmVx
dWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9WSVJROwogICAgIGVudi0+dHNjX29mZnNldCA9IDA7CiAK
ICAgICBlbnYtPmdkdC5iYXNlICA9IGxkcV9waHlzKGVudi0+dm1faHNhdmUgKyBvZmZzZXRvZihz
dHJ1Y3Qgdm1jYiwKZGlmZiAtLWdpdCBhL3RhcmdldC1sbTMyL2NwdS5oIGIvdGFyZ2V0LWxtMzIv
Y3B1LmgKaW5kZXggNjk0OGQwZS4uZDgxZjEwMyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWxtMzIvY3B1
LmgKKysrIGIvdGFyZ2V0LWxtMzIvY3B1LmgKQEAgLTI1NCw5ICsyNTQsNyBAQCBzdGF0aWMgaW5s
aW5lIHZvaWQgY3B1X2dldF90Yl9jcHVfc3RhdGUoQ1BVTE0zMlN0YXRlICplbnYsIHRhcmdldF91
bG9uZyAqcGMsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNw
dSkKIHsKLSAgICBDUFVMTTMyU3RhdGUgKmVudiA9ICZMTTMyX0NQVShjcHUpLT5lbnY7Ci0KLSAg
ICByZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKKyAg
ICByZXR1cm4gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKIH0K
IAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3RhcmdldC1sbTMyL29w
X2hlbHBlci5jIGIvdGFyZ2V0LWxtMzIvb3BfaGVscGVyLmMKaW5kZXggNTM0MTBiMS4uZWJjOTRh
MCAxMDA2NDQKLS0tIGEvdGFyZ2V0LWxtMzIvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LWxtMzIv
b3BfaGVscGVyLmMKQEAgLTI1LDcgKzI1LDkgQEAgdm9pZCBoZWxwZXJfcmFpc2VfZXhjZXB0aW9u
KENQVUxNMzJTdGF0ZSAqZW52LCB1aW50MzJfdCBpbmRleCkKIAogdm9pZCBoZWxwZXJfaGx0KENQ
VUxNMzJTdGF0ZSAqZW52KQogewotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUobG0zMl9lbnZfZ2V0X2NwdShlbnYpKTsKKworICAgIGNzLT5oYWx0ZWQgPSAxOwog
ICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiAgICAgY3B1X2xvb3BfZXhpdChl
bnYpOwogfQpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvY3B1LmggYi90YXJnZXQtbTY4ay9jcHUu
aAppbmRleCAyNjcyZWFlLi5iYjJmYmQ2IDEwMDY0NAotLS0gYS90YXJnZXQtbTY4ay9jcHUuaAor
KysgYi90YXJnZXQtbTY4ay9jcHUuaApAQCAtMjY1LDkgKzI2NSw3IEBAIHN0YXRpYyBpbmxpbmUg
dm9pZCBjcHVfZ2V0X3RiX2NwdV9zdGF0ZShDUFVNNjhLU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25n
ICpwYywKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQog
ewotICAgIENQVU02OEtTdGF0ZSAqZW52ID0gJk02OEtfQ1BVKGNwdSktPmVudjsKLQotICAgIHJl
dHVybiBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOworICAgIHJl
dHVybiBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOwogfQogCiAj
aW5jbHVkZSAiZXhlYy9leGVjLWFsbC5oIgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvb3BfaGVs
cGVyLmMgYi90YXJnZXQtbTY4ay9vcF9oZWxwZXIuYwppbmRleCAxNmRmMjRjLi5lMTFmMzRiIDEw
MDY0NAotLS0gYS90YXJnZXQtbTY4ay9vcF9oZWxwZXIuYworKysgYi90YXJnZXQtbTY4ay9vcF9o
ZWxwZXIuYwpAQCAtODQsNiArODQsNyBAQCBzdGF0aWMgdm9pZCBkb19ydGUoQ1BVTTY4S1N0YXRl
ICplbnYpCiAKIHN0YXRpYyB2b2lkIGRvX2ludGVycnVwdF9hbGwoQ1BVTTY4S1N0YXRlICplbnYs
IGludCBpc19odykKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAgdWludDMyX3Qgc3A7CiAgICAg
dWludDMyX3QgZm10OwogICAgIHVpbnQzMl90IHJldGFkZHI7CkBAIC0xMDgsNyArMTA5LDggQEAg
c3RhdGljIHZvaWQgZG9faW50ZXJydXB0X2FsbChDUFVNNjhLU3RhdGUgKmVudiwgaW50IGlzX2h3
KQogICAgICAgICAgICAgICAgIGRvX202OGtfc2VtaWhvc3RpbmcoZW52LCBlbnYtPmRyZWdzWzBd
KTsKICAgICAgICAgICAgICAgICByZXR1cm47CiAgICAgICAgICAgICB9Ci0gICAgICAgICAgICBl
bnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICBjcyA9IENQVShtNjhrX2Vudl9nZXRfY3B1KGVu
dikpOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICBlbnYtPmV4Y2Vw
dGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgICAgICAgICAgY3B1X2xvb3BfZXhpdChlbnYpOwog
ICAgICAgICAgICAgcmV0dXJuOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvcXJlZ3MuZGVmIGIv
dGFyZ2V0LW02OGsvcXJlZ3MuZGVmCmluZGV4IDQ5NDAwYzQuLjQyMzViMDIgMTAwNjQ0Ci0tLSBh
L3RhcmdldC1tNjhrL3FyZWdzLmRlZgorKysgYi90YXJnZXQtbTY4ay9xcmVncy5kZWYKQEAgLTgs
NiArOCw1IEBAIERFRk8zMihDQ19YLCBjY194KQogREVGTzMyKERJVjEsIGRpdjEpCiBERUZPMzIo
RElWMiwgZGl2MikKIERFRk8zMihFWENFUFRJT04sIGV4Y2VwdGlvbl9pbmRleCkKLURFRk8zMihI
QUxURUQsIGhhbHRlZCkKIERFRk8zMihNQUNTUiwgbWFjc3IpCiBERUZPMzIoTUFDX01BU0ssIG1h
Y19tYXNrKQpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW02OGsvdHJhbnNsYXRlLmMgYi90YXJnZXQtbTY4
ay90cmFuc2xhdGUuYwppbmRleCBlNzYzMTk1Li5hYWJkMmQ5IDEwMDY0NAotLS0gYS90YXJnZXQt
bTY4ay90cmFuc2xhdGUuYworKysgYi90YXJnZXQtbTY4ay90cmFuc2xhdGUuYwpAQCAtNDIsNiAr
NDIsOCBAQAogI3VuZGVmIERFRk82NAogI3VuZGVmIERFRkY2NAogCitzdGF0aWMgVENHdl9pMzIg
Y3B1X2hhbHRlZDsKKwogc3RhdGljIFRDR3ZfcHRyIGNwdV9lbnY7CiAKIHN0YXRpYyBjaGFyIGNw
dV9yZWdfbmFtZXNbMyo4KjMgKyA1KjRdOwpAQCAtNzYsNiArNzgsMTAgQEAgdm9pZCBtNjhrX3Rj
Z19pbml0KHZvaWQpCiAjdW5kZWYgREVGTzY0CiAjdW5kZWYgREVGRjY0CiAKKyAgICBjcHVfaGFs
dGVkID0gdGNnX2dsb2JhbF9tZW1fbmV3X2kzMihUQ0dfQVJFRzAsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLW9mZnNldG9mKE02OGtDUFUsIGVudikgKworICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mZnNldG9mKENQVVN0YXRlLCBoYWx0
ZWQpLCAiSEFMVEVEIik7CisKICAgICBjcHVfZW52ID0gdGNnX2dsb2JhbF9yZWdfbmV3X3B0cihU
Q0dfQVJFRzAsICJlbnYiKTsKIAogICAgIHAgPSBjcHVfcmVnX25hbWVzOwpAQCAtMjAyNCw3ICsy
MDMwLDcgQEAgRElTQVNfSU5TTihzdG9wKQogICAgIHMtPnBjICs9IDI7CiAKICAgICBnZW5fc2V0
X3NyX2ltKHMsIGV4dCwgMCk7Ci0gICAgdGNnX2dlbl9tb3ZpX2kzMihRUkVHX0hBTFRFRCwgMSk7
CisgICAgdGNnX2dlbl9tb3ZpX2kzMihjcHVfaGFsdGVkLCAxKTsKICAgICBnZW5fZXhjZXB0aW9u
KHMsIHMtPnBjLCBFWENQX0hMVCk7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC1taWNyb2JsYXpl
L2NwdS5oIGIvdGFyZ2V0LW1pY3JvYmxhemUvY3B1LmgKaW5kZXggYzNkZDdmNi4uNzU0OGFhOSAx
MDA2NDQKLS0tIGEvdGFyZ2V0LW1pY3JvYmxhemUvY3B1LmgKKysrIGIvdGFyZ2V0LW1pY3JvYmxh
emUvY3B1LmgKQEAgLTM3NCw5ICszNzQsNyBAQCB2b2lkIGNwdV91bmFzc2lnbmVkX2FjY2VzcyhD
UFVNQlN0YXRlICplbnYxLCBod2FkZHIgYWRkciwKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9o
YXNfd29yayhDUFVTdGF0ZSAqY3B1KQogewotICAgIENQVU1CU3RhdGUgKmVudiA9ICZNSUNST0JM
QVpFX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IChDUFVfSU5URVJSVVBUX0hBUkQgfCBDUFVfSU5URVJSVVBUX05NSSk7CisgICAgcmV0dXJuIGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQ
VF9OTUkpOwogfQogCiAjaW5jbHVkZSAiZXhlYy9leGVjLWFsbC5oIgpkaWZmIC0tZ2l0IGEvdGFy
Z2V0LW1pcHMvY3B1LmggYi90YXJnZXQtbWlwcy9jcHUuaAppbmRleCAwZTE5OGIxLi43NDM0MDk5
IDEwMDY0NAotLS0gYS90YXJnZXQtbWlwcy9jcHUuaAorKysgYi90YXJnZXQtbWlwcy9jcHUuaApA
QCAtNzE5LDcgKzcxOSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3Rh
dGUgKmNwdSkKICAgICAvKiBJdCBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgaWYgbm9uLWVu
YWJsZWQgaW50ZXJydXB0cwogICAgICAgIHdha2UtdXAgdGhlIENQVSwgaG93ZXZlciBtb3N0IG9m
IHRoZSBpbXBsZW1lbnRhdGlvbnMgb25seQogICAgICAgIGNoZWNrIGZvciBpbnRlcnJ1cHRzIHRo
YXQgY2FuIGJlIHRha2VuLiAqLwotICAgIGlmICgoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQ
VV9JTlRFUlJVUFRfSEFSRCkgJiYKKyAgICBpZiAoKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBD
UFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAgICAgIGNwdV9taXBzX2h3X2ludGVycnVwdHNfcGVu
ZGluZyhlbnYpKSB7CiAgICAgICAgIGhhc193b3JrID0gdHJ1ZTsKICAgICB9CkBAIC03MjgsNyAr
NzI4LDcgQEAgc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQog
ICAgIGlmIChlbnYtPkNQMF9Db25maWczICYgKDEgPDwgQ1AwQzNfTVQpKSB7CiAgICAgICAgIC8q
IFRoZSBRRU1VIG1vZGVsIHdpbGwgaXNzdWUgYW4gX1dBS0UgcmVxdWVzdCB3aGVuZXZlciB0aGUg
Q1BVcwogICAgICAgICAgICBzaG91bGQgYmUgd29rZW4gdXAuICAqLwotICAgICAgICBpZiAoZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfV0FLRSkgeworICAgICAgICBpZiAo
Y3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfV0FLRSkgewogICAgICAgICAg
ICAgaGFzX3dvcmsgPSB0cnVlOwogICAgICAgICB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC1taXBz
L29wX2hlbHBlci5jIGIvdGFyZ2V0LW1pcHMvb3BfaGVscGVyLmMKaW5kZXggNTI2Zjg0Zi4uNzk5
MmYwZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LW1pcHMvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LW1p
cHMvb3BfaGVscGVyLmMKQEAgLTUyNywxMSArNTI3LDEyIEBAIHZvaWQgaGVscGVyX3NkbShDUFVN
SVBTU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIGFkZHIsIHRhcmdldF91bG9uZyByZWdsaXN0LAog
LyogU01QIGhlbHBlcnMuICAqLwogc3RhdGljIGJvb2wgbWlwc192cGVfaXNfd2ZpKE1JUFNDUFUg
KmMpCiB7CisgICAgQ1BVU3RhdGUgKmNwdSA9IENQVShjKTsKICAgICBDUFVNSVBTU3RhdGUgKmVu
diA9ICZjLT5lbnY7CiAKICAgICAvKiBJZiB0aGUgVlBFIGlzIGhhbHRlZCBidXQgb3RoZXJ3aXNl
IGFjdGl2ZSwgaXQgbWVhbnMgaXQncyB3YWl0aW5nIGZvcgogICAgICAgIGFuIGludGVycnVwdC4g
ICovCi0gICAgcmV0dXJuIGVudi0+aGFsdGVkICYmIG1pcHNfdnBlX2FjdGl2ZShlbnYpOworICAg
IHJldHVybiBjcHUtPmhhbHRlZCAmJiBtaXBzX3ZwZV9hY3RpdmUoZW52KTsKIH0KIAogc3RhdGlj
IGlubGluZSB2b2lkIG1pcHNfdnBlX3dha2UoQ1BVTUlQU1N0YXRlICpjKQpAQCAtNTQ0LDExICs1
NDUsMTIgQEAgc3RhdGljIGlubGluZSB2b2lkIG1pcHNfdnBlX3dha2UoQ1BVTUlQU1N0YXRlICpj
KQogCiBzdGF0aWMgaW5saW5lIHZvaWQgbWlwc192cGVfc2xlZXAoTUlQU0NQVSAqY3B1KQogewor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVU1JUFNTdGF0ZSAqYyA9ICZjcHUt
PmVudjsKIAogICAgIC8qIFRoZSBWUEUgd2FzIHNodXQgb2ZmLCByZWFsbHkgZ28gdG8gYmVkLgog
ICAgICAgIFJlc2V0IGFueSBvbGQgX1dBS0UgcmVxdWVzdHMuICAqLwotICAgIGMtPmhhbHRlZCA9
IDE7CisgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgY3B1X3Jlc2V0X2ludGVycnVwdChjLCBDUFVf
SU5URVJSVVBUX1dBS0UpOwogfQogCkBAIC0yMTExLDcgKzIxMTMsOSBAQCB2b2lkIGhlbHBlcl9w
bW9uKENQVU1JUFNTdGF0ZSAqZW52LCBpbnQgZnVuY3Rpb24pCiAKIHZvaWQgaGVscGVyX3dhaXQo
Q1BVTUlQU1N0YXRlICplbnYpCiB7Ci0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIENQVVN0YXRl
ICpjcyA9IENQVShtaXBzX2Vudl9nZXRfY3B1KGVudikpOworCisgICAgY3MtPmhhbHRlZCA9IDE7
CiAgICAgY3B1X3Jlc2V0X2ludGVycnVwdChlbnYsIENQVV9JTlRFUlJVUFRfV0FLRSk7CiAgICAg
aGVscGVyX3JhaXNlX2V4Y2VwdGlvbihlbnYsIEVYQ1BfSExUKTsKIH0KZGlmZiAtLWdpdCBhL3Rh
cmdldC1taXBzL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMKaW5kZXggNGVl
OTYxNS4uNWNkMzEyNCAxMDA2NDQKLS0tIGEvdGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMKKysrIGIv
dGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMKQEAgLTE2MDIwLDcgKzE2MDIwLDcgQEAgdm9pZCBjcHVf
c3RhdGVfcmVzZXQoQ1BVTUlQU1N0YXRlICplbnYpCiAgICAgICAgICAgICBlbnYtPnRjc1tpXS5D
UDBfVENIYWx0ID0gMTsKICAgICAgICAgfQogICAgICAgICBlbnYtPmFjdGl2ZV90Yy5DUDBfVENI
YWx0ID0gMTsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICBjcy0+aGFsdGVkID0g
MTsKIAogICAgICAgICBpZiAoY3MtPmNwdV9pbmRleCA9PSAwKSB7CiAgICAgICAgICAgICAvKiBW
UEUwIHN0YXJ0cyB1cCBlbmFibGVkLiAgKi8KQEAgLTE2MDI4LDcgKzE2MDI4LDcgQEAgdm9pZCBj
cHVfc3RhdGVfcmVzZXQoQ1BVTUlQU1N0YXRlICplbnYpCiAgICAgICAgICAgICBlbnYtPkNQMF9W
UEVDb25mMCB8PSAoMSA8PCBDUDBWUEVDMF9NVlApIHwgKDEgPDwgQ1AwVlBFQzBfVlBBKTsKIAog
ICAgICAgICAgICAgLyogVEMwIHN0YXJ0cyB1cCB1bmhhbHRlZC4gICovCi0gICAgICAgICAgICBl
bnYtPmhhbHRlZCA9IDA7CisgICAgICAgICAgICBjcy0+aGFsdGVkID0gMDsKICAgICAgICAgICAg
IGVudi0+YWN0aXZlX3RjLkNQMF9UQ0hhbHQgPSAwOwogICAgICAgICAgICAgZW52LT50Y3NbMF0u
Q1AwX1RDSGFsdCA9IDA7CiAgICAgICAgICAgICAvKiBXaXRoIHRocmVhZCAwIGFjdGl2ZS4gICov
CmRpZmYgLS1naXQgYS90YXJnZXQtb3BlbnJpc2MvY3B1LmggYi90YXJnZXQtb3BlbnJpc2MvY3B1
LmgKaW5kZXggNDE5ZjAwNy4uNjg3YzI0ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LW9wZW5yaXNjL2Nw
dS5oCisrKyBiL3RhcmdldC1vcGVucmlzYy9jcHUuaApAQCAtNDIxLDkgKzQyMSw3IEBAIHN0YXRp
YyBpbmxpbmUgaW50IGNwdV9tbXVfaW5kZXgoQ1BVT3BlblJJU0NTdGF0ZSAqZW52KQogI2RlZmlu
ZSBDUFVfSU5URVJSVVBUX1RJTUVSICAgQ1BVX0lOVEVSUlVQVF9UR1RfSU5UXzAKIHN0YXRpYyBp
bmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVPcGVuUklT
Q1N0YXRlICplbnYgPSAmT1BFTlJJU0NfQ1BVKGNwdSktPmVudjsKLQotICAgIHJldHVybiBlbnYt
PmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8CisgICAgcmV0dXJuIGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX1RJTUVSKTsKIH0KIApkaWZm
IC0tZ2l0IGEvdGFyZ2V0LW9wZW5yaXNjL2ludGVycnVwdF9oZWxwZXIuYyBiL3RhcmdldC1vcGVu
cmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMKaW5kZXggYTE3NjQ0MS4uODQ0NjQ4ZiAxMDA2NDQKLS0t
IGEvdGFyZ2V0LW9wZW5yaXNjL2ludGVycnVwdF9oZWxwZXIuYworKysgYi90YXJnZXQtb3BlbnJp
c2MvaW50ZXJydXB0X2hlbHBlci5jCkBAIC0yNCw2ICsyNCw3IEBACiB2b2lkIEhFTFBFUihyZmUp
KENQVU9wZW5SSVNDU3RhdGUgKmVudikKIHsKICAgICBPcGVuUklTQ0NQVSAqY3B1ID0gb3BlbnJp
c2NfZW52X2dldF9jcHUoZW52KTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICNpZm5k
ZWYgQ09ORklHX1VTRVJfT05MWQogICAgIGludCBuZWVkX2ZsdXNoX3RsYiA9IChjcHUtPmVudi5z
ciAmIChTUl9TTSB8IFNSX0lNRSB8IFNSX0RNRSkpIF4KICAgICAgICAgICAgICAgICAgICAgICAg
ICAoY3B1LT5lbnYuZXNyICYgKFNSX1NNIHwgU1JfSU1FIHwgU1JfRE1FKSk7CkBAIC01Myw1ICs1
NCw1IEBAIHZvaWQgSEVMUEVSKHJmZSkoQ1BVT3BlblJJU0NTdGF0ZSAqZW52KQogICAgICAgICB0
bGJfZmx1c2goJmNwdS0+ZW52LCAxKTsKICAgICB9CiAjZW5kaWYKLSAgICBjcHUtPmVudi5pbnRl
cnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICBjcy0+aW50ZXJydXB0
X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiB9CmRpZmYgLS1naXQgYS90YXJnZXQt
b3BlbnJpc2Mvc3lzX2hlbHBlci5jIGIvdGFyZ2V0LW9wZW5yaXNjL3N5c19oZWxwZXIuYwppbmRl
eCAzYzVmNDVhLi5jY2NiYzBlIDEwMDY0NAotLS0gYS90YXJnZXQtb3BlbnJpc2Mvc3lzX2hlbHBl
ci5jCisrKyBiL3RhcmdldC1vcGVucmlzYy9zeXNfaGVscGVyLmMKQEAgLTMxLDYgKzMxLDcgQEAg
dm9pZCBIRUxQRVIobXRzcHIpKENQVU9wZW5SSVNDU3RhdGUgKmVudiwKICAgICBpbnQgaWR4Owog
CiAgICAgT3BlblJJU0NDUFUgKmNwdSA9IG9wZW5yaXNjX2Vudl9nZXRfY3B1KGVudik7CisgICAg
Q1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAKICAgICBzd2l0Y2ggKHNwcikgewogICAgIGNhc2Ug
VE9fU1BSKDAsIDApOiAvKiBWUiAqLwpAQCAtMTMyLDcgKzEzMyw3IEBAIHZvaWQgSEVMUEVSKG10
c3ByKShDUFVPcGVuUklTQ1N0YXRlICplbnYsCiAgICAgICAgICAgICAgICAgZW52LT50dG1yID0g
KHJiICYgflRUTVJfSVApICsgaXA7CiAgICAgICAgICAgICB9IGVsc2UgeyAgICAvKiBDbGVhciBJ
UCBiaXQuICAqLwogICAgICAgICAgICAgICAgIGVudi0+dHRtciA9IHJiICYgflRUTVJfSVA7Ci0g
ICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9U
SU1FUjsKKyAgICAgICAgICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRF
UlJVUFRfVElNRVI7CiAgICAgICAgICAgICB9CiAKICAgICAgICAgICAgIGNwdV9vcGVucmlzY19j
b3VudF91cGRhdGUoY3B1KTsKZGlmZiAtLWdpdCBhL3RhcmdldC1wcGMvY3B1LmggYi90YXJnZXQt
cHBjL2NwdS5oCmluZGV4IDhjMDgxZGIuLjc1MTkwZjMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1wcGMv
Y3B1LmgKKysrIGIvdGFyZ2V0LXBwYy9jcHUuaApAQCAtMjIxNSw5ICsyMjE1LDEwIEBAIGV4dGVy
biB2b2lkICgqY3B1X3BwY19oeXBlcmNhbGwpKFBvd2VyUENDUFUgKik7CiAKIHN0YXRpYyBpbmxp
bmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVQUENTdGF0ZSAq
ZW52ID0gJlBPV0VSUENfQ1BVKGNwdSktPmVudjsKKyAgICBQb3dlclBDQ1BVICpwcGNfY3B1ID0g
UE9XRVJQQ19DUFUoY3B1KTsKKyAgICBDUFVQUENTdGF0ZSAqZW52ID0gJnBwY19jcHUtPmVudjsK
IAotICAgIHJldHVybiBtc3JfZWUgJiYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5U
RVJSVVBUX0hBUkQpOworICAgIHJldHVybiBtc3JfZWUgJiYgKGNwdS0+aW50ZXJydXB0X3JlcXVl
c3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpOwogfQogCiAjaW5jbHVkZSAiZXhlYy9leGVjLWFsbC5o
IgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXBwYy9leGNwX2hlbHBlci5jIGIvdGFyZ2V0LXBwYy9leGNw
X2hlbHBlci5jCmluZGV4IDBhMWFjODYuLjc5Y2U3YmYgMTAwNjQ0Ci0tLSBhL3RhcmdldC1wcGMv
ZXhjcF9oZWxwZXIuYworKysgYi90YXJnZXQtcHBjL2V4Y3BfaGVscGVyLmMKQEAgLTY2LDYgKzY2
LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGR1bXBfc3lzY2FsbChDUFVQUENTdGF0ZSAqZW52KQog
c3RhdGljIGlubGluZSB2b2lkIHBvd2VycGNfZXhjcChQb3dlclBDQ1BVICpjcHUsIGludCBleGNw
X21vZGVsLCBpbnQgZXhjcCkKIHsKICAgICBDUFVQUENTdGF0ZSAqZW52ID0gJmNwdS0+ZW52Owor
ICAgIENQVVN0YXRlICpjczsKICAgICB0YXJnZXRfdWxvbmcgbXNyLCBuZXdfbXNyLCB2ZWN0b3I7
CiAgICAgaW50IHNycjAsIHNycjEsIGFzcnIwLCBhc3JyMTsKICAgICBpbnQgbHBlczAsIGxwZXMx
LCBsZXY7CkBAIC0xMzEsOCArMTMyLDkgQEAgc3RhdGljIGlubGluZSB2b2lkIHBvd2VycGNfZXhj
cChQb3dlclBDQ1BVICpjcHUsIGludCBleGNwX21vZGVsLCBpbnQgZXhjcCkKICAgICAgICAgICAg
ICAgICBmcHJpbnRmKHN0ZGVyciwgIk1hY2hpbmUgY2hlY2sgd2hpbGUgbm90IGFsbG93ZWQuICIK
ICAgICAgICAgICAgICAgICAgICAgICAgICJFbnRlcmluZyBjaGVja3N0b3Agc3RhdGVcbiIpOwog
ICAgICAgICAgICAgfQotICAgICAgICAgICAgZW52LT5oYWx0ZWQgPSAxOwotICAgICAgICAgICAg
ZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICAgICAg
ICAgIGNzID0gQ1BVKGNwdSk7CisgICAgICAgICAgICBjcy0+aGFsdGVkID0gMTsKKyAgICAgICAg
ICAgIGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKICAgICAg
ICAgfQogICAgICAgICBpZiAoMCkgewogICAgICAgICAgICAgLyogWFhYOiBmaW5kIGEgc3VpdGFi
bGUgY29uZGl0aW9uIHRvIGVuYWJsZSB0aGUgaHlwZXJ2aXNvciBtb2RlICovCkBAIC02NjMsMTEg
KzY2NSwxMiBAQCB2b2lkIHBwY19od19pbnRlcnJ1cHQoQ1BVUFBDU3RhdGUgKmVudikKIHsKICAg
ICBQb3dlclBDQ1BVICpjcHUgPSBwcGNfZW52X2dldF9jcHUoZW52KTsKICAgICBpbnQgaGRpY2U7
Ci0KICNpZiAwCisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CisKICAgICBxZW11X2xvZ19t
YXNrKENQVV9MT0dfSU5ULCAiJXM6ICVwIHBlbmRpbmcgJTA4eCByZXEgJTA4eCBtZSAlZCBlZSAl
ZFxuIiwKLSAgICAgICAgICAgICAgICBfX2Z1bmNfXywgZW52LCBlbnYtPnBlbmRpbmdfaW50ZXJy
dXB0cywKLSAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0LCAoaW50KW1zcl9t
ZSwgKGludCltc3JfZWUpOworICAgICAgICAgICAgICAgICAgX19mdW5jX18sIGVudiwgZW52LT5w
ZW5kaW5nX2ludGVycnVwdHMsCisgICAgICAgICAgICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVl
c3QsIChpbnQpbXNyX21lLCAoaW50KW1zcl9lZSk7CiAjZW5kaWYKICAgICAvKiBFeHRlcm5hbCBy
ZXNldCAqLwogICAgIGlmIChlbnYtPnBlbmRpbmdfaW50ZXJydXB0cyAmICgxIDw8IFBQQ19JTlRF
UlJVUFRfUkVTRVQpKSB7CkBAIC04MDcsOSArODEwLDEyIEBAIHZvaWQgaGVscGVyX3JhaXNlX2V4
Y2VwdGlvbihDUFVQUENTdGF0ZSAqZW52LCB1aW50MzJfdCBleGNlcHRpb24pCiAjaWYgIWRlZmlu
ZWQoQ09ORklHX1VTRVJfT05MWSkKIHZvaWQgaGVscGVyX3N0b3JlX21zcihDUFVQUENTdGF0ZSAq
ZW52LCB0YXJnZXRfdWxvbmcgdmFsKQogeworICAgIENQVVN0YXRlICpjczsKKwogICAgIHZhbCA9
IGhyZWdfc3RvcmVfbXNyKGVudiwgdmFsLCAwKTsKICAgICBpZiAodmFsICE9IDApIHsKLSAgICAg
ICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICAg
ICAgY3MgPSBDUFUocHBjX2Vudl9nZXRfY3B1KGVudikpOworICAgICAgICBjcy0+aW50ZXJydXB0
X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgICAgIGhlbHBlcl9yYWlzZV9l
eGNlcHRpb24oZW52LCB2YWwpOwogICAgIH0KIH0KQEAgLTgxNyw2ICs4MjMsOCBAQCB2b2lkIGhl
bHBlcl9zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIHZhbCkKIHN0YXRp
YyBpbmxpbmUgdm9pZCBkb19yZmkoQ1BVUFBDU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIG5pcCwg
dGFyZ2V0X3Vsb25nIG1zciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0X3Vsb25n
IG1zcm0sIGludCBrZWVwX21zcmgpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHBwY19lbnZf
Z2V0X2NwdShlbnYpKTsKKwogI2lmIGRlZmluZWQoVEFSR0VUX1BQQzY0KQogICAgIGlmIChtc3Jf
aXNfNjRiaXQoZW52LCBtc3IpKSB7CiAgICAgICAgIG5pcCA9ICh1aW50NjRfdCluaXA7CkBAIC04
NDEsNyArODQ5LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGRvX3JmaShDUFVQUENTdGF0ZSAqZW52
LCB0YXJnZXRfdWxvbmcgbmlwLCB0YXJnZXRfdWxvbmcgbXNyLAogICAgIC8qIE5vIG5lZWQgdG8g
cmFpc2UgYW4gZXhjZXB0aW9uIGhlcmUsCiAgICAgICogYXMgcmZpIGlzIGFsd2F5cyB0aGUgbGFz
dCBpbnNuIG9mIGEgVEIKICAgICAgKi8KLSAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQ
VV9JTlRFUlJVUFRfRVhJVFRCOworICAgIGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5U
RVJSVVBUX0VYSVRUQjsKIH0KIAogdm9pZCBoZWxwZXJfcmZpKENQVVBQQ1N0YXRlICplbnYpCmRp
ZmYgLS1naXQgYS90YXJnZXQtcHBjL2hlbHBlcl9yZWdzLmggYi90YXJnZXQtcHBjL2hlbHBlcl9y
ZWdzLmgKaW5kZXggM2M5ODg1MC4uYTZkNWUyZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LXBwYy9oZWxw
ZXJfcmVncy5oCisrKyBiL3RhcmdldC1wcGMvaGVscGVyX3JlZ3MuaApAQCAtNjgsMTAgKzY4LDEz
IEBAIHN0YXRpYyBpbmxpbmUgaW50IGhyZWdfc3RvcmVfbXNyKENQVVBQQ1N0YXRlICplbnYsIHRh
cmdldF91bG9uZyB2YWx1ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBh
bHRlcl9odikKIHsKICAgICBpbnQgZXhjcDsKKyNpZiAhZGVmaW5lZChDT05GSUdfVVNFUl9PTkxZ
KQorICAgIENQVVN0YXRlICpjcyA9IENQVShwcGNfZW52X2dldF9jcHUoZW52KSk7CisjZW5kaWYK
IAogICAgIGV4Y3AgPSAwOwogICAgIHZhbHVlICY9IGVudi0+bXNyX21hc2s7Ci0jaWYgIWRlZmlu
ZWQgKENPTkZJR19VU0VSX09OTFkpCisjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkKICAg
ICBpZiAoIWFsdGVyX2h2KSB7CiAgICAgICAgIC8qIG10bXNyIGNhbm5vdCBhbHRlciB0aGUgaHlw
ZXJ2aXNvciBzdGF0ZSAqLwogICAgICAgICB2YWx1ZSAmPSB+TVNSX0hWQjsKQEAgLTgyLDcgKzg1
LDcgQEAgc3RhdGljIGlubGluZSBpbnQgaHJlZ19zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVudiwg
dGFyZ2V0X3Vsb25nIHZhbHVlLAogICAgICAgICAvKiBGbHVzaCBhbGwgdGxiIHdoZW4gY2hhbmdp
bmcgdHJhbnNsYXRpb24gbW9kZSAqLwogICAgICAgICB0bGJfZmx1c2goZW52LCAxKTsKICAgICAg
ICAgZXhjcCA9IFBPV0VSUENfRVhDUF9OT05FOwotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1
ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVl
c3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgfQogICAgIGlmICh1bmxpa2VseSgoZW52
LT5mbGFncyAmIFBPV0VSUENfRkxBR19UR1BSKSAmJgogICAgICAgICAgICAgICAgICAoKHZhbHVl
IF4gZW52LT5tc3IpICYgKDEgPDwgTVNSX1RHUFIpKSkpIHsKQEAgLTk2LDEwICs5OSwxMCBAQCBz
dGF0aWMgaW5saW5lIGludCBocmVnX3N0b3JlX21zcihDUFVQUENTdGF0ZSAqZW52LCB0YXJnZXRf
dWxvbmcgdmFsdWUsCiAjZW5kaWYKICAgICBlbnYtPm1zciA9IHZhbHVlOwogICAgIGhyZWdfY29t
cHV0ZV9oZmxhZ3MoZW52KTsKLSNpZiAhZGVmaW5lZCAoQ09ORklHX1VTRVJfT05MWSkKKyNpZiAh
ZGVmaW5lZChDT05GSUdfVVNFUl9PTkxZKQogICAgIGlmICh1bmxpa2VseShtc3JfcG93ID09IDEp
KSB7CiAgICAgICAgIGlmICgoKmVudi0+Y2hlY2tfcG93KShlbnYpKSB7Ci0gICAgICAgICAgICBl
bnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgICAg
IGV4Y3AgPSBFWENQX0hBTFRFRDsKICAgICAgICAgfQogICAgIH0KZGlmZiAtLWdpdCBhL3Rhcmdl
dC1wcGMva3ZtLmMgYi90YXJnZXQtcHBjL2t2bS5jCmluZGV4IDJjNjRjNjMuLmVlOTM1ZDggMTAw
NjQ0Ci0tLSBhL3RhcmdldC1wcGMva3ZtLmMKKysrIGIvdGFyZ2V0LXBwYy9rdm0uYwpAQCAtNzYw
LDcgKzc2MCw3IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihDUFVTdGF0ZSAqY3MsIHN0cnVjdCBr
dm1fcnVuICpydW4pCiAgICAgICogaW50ZXJydXB0LCByZXNldCwgZXRjKSBpbiBQUEMtc3BlY2lm
aWMgZW52LT5pcnFfaW5wdXRfc3RhdGUuICovCiAgICAgaWYgKCFjYXBfaW50ZXJydXB0X2xldmVs
ICYmCiAgICAgICAgIHJ1bi0+cmVhZHlfZm9yX2ludGVycnVwdF9pbmplY3Rpb24gJiYKLSAgICAg
ICAgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCisgICAg
ICAgIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAg
ICAgIChlbnYtPmlycV9pbnB1dF9zdGF0ZSAmICgxPDxQUENfSU5QVVRfSU5UKSkpCiAgICAgewog
ICAgICAgICAvKiBGb3Igbm93IEtWTSBkaXNyZWdhcmRzIHRoZSAnaXJxJyBhcmd1bWVudC4gSG93
ZXZlciwgaW4gdGhlCkBAIC03OTEsMTQgKzc5MSwxNiBAQCB2b2lkIGt2bV9hcmNoX3Bvc3RfcnVu
KENQVVN0YXRlICpjcHUsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAKIGludCBrdm1fYXJjaF9wcm9j
ZXNzX2FzeW5jX2V2ZW50cyhDUFVTdGF0ZSAqY3MpCiB7Ci0gICAgUG93ZXJQQ0NQVSAqY3B1ID0g
UE9XRVJQQ19DUFUoY3MpOwotICAgIHJldHVybiBjcHUtPmVudi5oYWx0ZWQ7CisgICAgcmV0dXJu
IGNzLT5oYWx0ZWQ7CiB9CiAKLXN0YXRpYyBpbnQga3ZtcHBjX2hhbmRsZV9oYWx0KENQVVBQQ1N0
YXRlICplbnYpCitzdGF0aWMgaW50IGt2bXBwY19oYW5kbGVfaGFsdChQb3dlclBDQ1BVICpjcHUp
CiB7Ci0gICAgaWYgKCEoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFS
RCkgJiYgKG1zcl9lZSkpIHsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgIENQVVN0YXRl
ICpjcyA9IENQVShjcHUpOworICAgIENQVVBQQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CisKKyAg
ICBpZiAoIShjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmICht
c3JfZWUpKSB7CisgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgICAgICBlbnYtPmV4Y2VwdGlv
bl9pbmRleCA9IEVYQ1BfSExUOwogICAgIH0KIApAQCAtODQwLDcgKzg0Miw3IEBAIGludCBrdm1f
YXJjaF9oYW5kbGVfZXhpdChDUFVTdGF0ZSAqY3MsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAgICAg
ICAgIGJyZWFrOwogICAgIGNhc2UgS1ZNX0VYSVRfSExUOgogICAgICAgICBkcHJpbnRmKCJoYW5k
bGUgaGFsdFxuIik7Ci0gICAgICAgIHJldCA9IGt2bXBwY19oYW5kbGVfaGFsdChlbnYpOworICAg
ICAgICByZXQgPSBrdm1wcGNfaGFuZGxlX2hhbHQoY3B1KTsKICAgICAgICAgYnJlYWs7CiAjaWZk
ZWYgQ09ORklHX1BTRVJJRVMKICAgICBjYXNlIEtWTV9FWElUX1BBUFJfSENBTEw6CmRpZmYgLS1n
aXQgYS90YXJnZXQtcHBjL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LXBwYy90cmFuc2xhdGUuYwppbmRl
eCAyYWM1Nzk0Li40ZDUwMTk4IDEwMDY0NAotLS0gYS90YXJnZXQtcHBjL3RyYW5zbGF0ZS5jCisr
KyBiL3RhcmdldC1wcGMvdHJhbnNsYXRlLmMKQEAgLTMyNDMsNyArMzI0Myw4IEBAIHN0YXRpYyB2
b2lkIGdlbl9zeW5jKERpc2FzQ29udGV4dCAqY3R4KQogc3RhdGljIHZvaWQgZ2VuX3dhaXQoRGlz
YXNDb250ZXh0ICpjdHgpCiB7CiAgICAgVENHdl9pMzIgdDAgPSB0Y2dfdGVtcF9uZXdfaTMyKCk7
Ci0gICAgdGNnX2dlbl9zdF9pMzIodDAsIGNwdV9lbnYsIG9mZnNldG9mKENQVVBQQ1N0YXRlLCBo
YWx0ZWQpKTsKKyAgICB0Y2dfZ2VuX3N0X2kzMih0MCwgY3B1X2VudiwKKyAgICAgICAgICAgICAg
ICAgICAtb2Zmc2V0b2YoUG93ZXJQQ0NQVSwgZW52KSArIG9mZnNldG9mKENQVVN0YXRlLCBoYWx0
ZWQpKTsKICAgICB0Y2dfdGVtcF9mcmVlX2kzMih0MCk7CiAgICAgLyogU3RvcCB0cmFuc2xhdGlv
biwgYXMgdGhlIENQVSBpcyBzdXBwb3NlZCB0byBzbGVlcCBmcm9tIG5vdyAqLwogICAgIGdlbl9l
eGNlcHRpb25fZXJyKGN0eCwgRVhDUF9ITFQsIDEpOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXMzOTB4
L2NwdS5jIGIvdGFyZ2V0LXMzOTB4L2NwdS5jCmluZGV4IGI3NDY1NDcuLjczOGEwYWQgMTAwNjQ0
Ci0tLSBhL3RhcmdldC1zMzkweC9jcHUuYworKysgYi90YXJnZXQtczM5MHgvY3B1LmMKQEAgLTgw
LDEwICs4MCwxMCBAQCBzdGF0aWMgdm9pZCBzMzkwX2NwdV9yZXNldChDUFVTdGF0ZSAqcykKICAg
ICBlbnYtPmNyZWdzWzBdID0gQ1IwX1JFU0VUOwogICAgIGVudi0+Y3JlZ3NbMTRdID0gQ1IxNF9S
RVNFVDsKICAgICAvKiBzZXQgaGFsdGVkIHRvIDEgdG8gbWFrZSBzdXJlIHdlIGNhbiBhZGQgdGhl
IGNwdSBpbgotICAgICAqIHMzOTBfaXBsX2NwdSBjb2RlLCB3aGVyZSBlbnYtPmhhbHRlZCBpcyBz
ZXQgYmFjayB0byAwCisgICAgICogczM5MF9pcGxfY3B1IGNvZGUsIHdoZXJlIENQVVN0YXRlOjpo
YWx0ZWQgaXMgc2V0IGJhY2sgdG8gMAogICAgICAqIGFmdGVyIGluY3JlbWVudGluZyB0aGUgY3B1
IGNvdW50ZXIgKi8KICNpZiAhZGVmaW5lZChDT05GSUdfVVNFUl9PTkxZKQotICAgIGVudi0+aGFs
dGVkID0gMTsKKyAgICBzLT5oYWx0ZWQgPSAxOwogI2VuZGlmCiAgICAgdGxiX2ZsdXNoKGVudiwg
MSk7CiB9CkBAIC0xMjksMTAgKzEyOSwxMCBAQCBzdGF0aWMgdm9pZCBzMzkwX2NwdV9pbml0Zm4o
T2JqZWN0ICpvYmopCiAgICAgZW52LT50b2RfYmFzZXRpbWUgPSAwOwogICAgIGVudi0+dG9kX3Rp
bWVyID0gcWVtdV9uZXdfdGltZXJfbnModm1fY2xvY2ssIHMzOTB4X3RvZF90aW1lciwgY3B1KTsK
ICAgICBlbnYtPmNwdV90aW1lciA9IHFlbXVfbmV3X3RpbWVyX25zKHZtX2Nsb2NrLCBzMzkweF9j
cHVfdGltZXIsIGNwdSk7Ci0gICAgLyogc2V0IGVudi0+aGFsdGVkIHN0YXRlIHRvIDEgdG8gYXZv
aWQgZGVjcmVtZW50aW5nIHRoZSBydW5uaW5nCisgICAgLyogc2V0IENQVVN0YXRlOjpoYWx0ZWQg
c3RhdGUgdG8gMSB0byBhdm9pZCBkZWNyZW1lbnRpbmcgdGhlIHJ1bm5pbmcKICAgICAgKiBjcHUg
Y291bnRlciBpbiBzMzkwX2NwdV9yZXNldCB0byBhIG5lZ2F0aXZlIG51bWJlciBhdAogICAgICAq
IGluaXRpYWwgaXBsICovCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNzLT5oYWx0ZWQgPSAx
OwogI2VuZGlmCiAgICAgZW52LT5jcHVfbnVtID0gY3B1X251bSsrOwogICAgIGVudi0+ZXh0X2lu
ZGV4ID0gLTE7CmRpZmYgLS1naXQgYS90YXJnZXQtczM5MHgvY3B1LmggYi90YXJnZXQtczM5MHgv
Y3B1LmgKaW5kZXggMDA3MGM0MC4uZTY5OTdlZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LXMzOTB4L2Nw
dS5oCisrKyBiL3RhcmdldC1zMzkweC9jcHUuaApAQCAtMTAzOSw5ICsxMDM5LDEwIEBAIHN0YXRp
YyBpbmxpbmUgdm9pZCBjcHVfaW5qZWN0X2Nyd19tY2hrKFMzOTBDUFUgKmNwdSkKIAogc3RhdGlj
IGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQogewotICAgIENQVVMzOTBY
U3RhdGUgKmVudiA9ICZTMzkwX0NQVShjcHUpLT5lbnY7CisgICAgUzM5MENQVSAqczM5MF9jcHUg
PSBTMzkwX0NQVShjcHUpOworICAgIENQVVMzOTBYU3RhdGUgKmVudiA9ICZzMzkwX2NwdS0+ZW52
OwogCi0gICAgcmV0dXJuIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9I
QVJEKSAmJgorICAgIHJldHVybiAoY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJV
UFRfSEFSRCkgJiYKICAgICAgICAgKGVudi0+cHN3Lm1hc2sgJiBQU1dfTUFTS19FWFQpOwogfQog
CmRpZmYgLS1naXQgYS90YXJnZXQtczM5MHgvaGVscGVyLmMgYi90YXJnZXQtczM5MHgvaGVscGVy
LmMKaW5kZXggYmM2ZmM0Yy4uM2E1NDY1MSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXMzOTB4L2hlbHBl
ci5jCisrKyBiL3RhcmdldC1zMzkweC9oZWxwZXIuYwpAQCAtNDM3LDYgKzQzNyw3IEBAIHZvaWQg
bG9hZF9wc3coQ1BVUzM5MFhTdGF0ZSAqZW52LCB1aW50NjRfdCBtYXNrLCB1aW50NjRfdCBhZGRy
KQogewogICAgIGlmIChtYXNrICYgUFNXX01BU0tfV0FJVCkgewogICAgICAgICBTMzkwQ1BVICpj
cHUgPSBzMzkwX2Vudl9nZXRfY3B1KGVudik7CisgICAgICAgIENQVVN0YXRlICpjcyA9IENQVShj
cHUpOwogICAgICAgICBpZiAoIShtYXNrICYgKFBTV19NQVNLX0lPIHwgUFNXX01BU0tfRVhUIHwg
UFNXX01BU0tfTUNIRUNLKSkpIHsKICAgICAgICAgICAgIGlmIChzMzkwX2RlbF9ydW5uaW5nX2Nw
dShjcHUpID09IDApIHsKICNpZm5kZWYgQ09ORklHX1VTRVJfT05MWQpAQCAtNDQ0LDcgKzQ0NSw3
IEBAIHZvaWQgbG9hZF9wc3coQ1BVUzM5MFhTdGF0ZSAqZW52LCB1aW50NjRfdCBtYXNrLCB1aW50
NjRfdCBhZGRyKQogI2VuZGlmCiAgICAgICAgICAgICB9CiAgICAgICAgIH0KLSAgICAgICAgZW52
LT5oYWx0ZWQgPSAxOworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNl
cHRpb25faW5kZXggPSBFWENQX0hMVDsKICAgICB9CiAKQEAgLTczNCw2ICs3MzUsNyBAQCBzdGF0
aWMgdm9pZCBkb19tY2hrX2ludGVycnVwdChDUFVTMzkwWFN0YXRlICplbnYpCiB2b2lkIGRvX2lu
dGVycnVwdChDUFVTMzkwWFN0YXRlICplbnYpCiB7CiAgICAgUzM5MENQVSAqY3B1ID0gczM5MF9l
bnZfZ2V0X2NwdShlbnYpOworICAgIENQVVN0YXRlICpjczsKIAogICAgIHFlbXVfbG9nX21hc2so
Q1BVX0xPR19JTlQsICIlczogJWQgYXQgcGM9JSIgUFJJeDY0ICJcbiIsCiAgICAgICAgICAgICAg
ICAgICBfX2Z1bmNfXywgZW52LT5leGNlcHRpb25faW5kZXgsIGVudi0+cHN3LmFkZHIpOwpAQCAt
NzkyLDcgKzc5NCw4IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVVMzOTBYU3RhdGUgKmVudikKICAg
ICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IC0xOwogCiAgICAgaWYgKCFlbnYtPnBlbmRpbmdfaW50
KSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfSEFS
RDsKKyAgICAgICAgY3MgPSBDUFUoczM5MF9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICAgICAgY3Mt
PmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBUkQ7CiAgICAgfQogfQogCmRp
ZmYgLS1naXQgYS90YXJnZXQtc2g0L2NwdS5oIGIvdGFyZ2V0LXNoNC9jcHUuaAppbmRleCA0OWRj
ZDllLi45MjZlYzQxIDEwMDY0NAotLS0gYS90YXJnZXQtc2g0L2NwdS5oCisrKyBiL3RhcmdldC1z
aDQvY3B1LmgKQEAgLTM3Miw5ICszNzIsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X2dldF90
Yl9jcHVfc3RhdGUoQ1BVU0g0U3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nICpwYywKIAogc3RhdGlj
IGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQogewotICAgIENQVVNINFN0
YXRlICplbnYgPSAmU1VQRVJIX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICByZXR1cm4gY3B1LT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKIH0KIAogI2luY2x1ZGUgImV4ZWMv
ZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3RhcmdldC1zaDQvaGVscGVyLmMgYi90YXJnZXQtc2g0
L2hlbHBlci5jCmluZGV4IGRkZWJjNzguLmZkNGVmZWUgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zaDQv
aGVscGVyLmMKKysrIGIvdGFyZ2V0LXNoNC9oZWxwZXIuYwpAQCAtNzgsOSArNzgsMTAgQEAgaW50
IGNwdV9zaDRfaXNfY2FjaGVkKENQVVNINFN0YXRlICogZW52LCB0YXJnZXRfdWxvbmcgYWRkcikK
ICNkZWZpbmUgTU1VX0RBRERSX0VSUk9SX1JFQUQgICAgICgtMTIpCiAjZGVmaW5lIE1NVV9EQURE
Ul9FUlJPUl9XUklURSAgICAoLTEzKQogCi12b2lkIGRvX2ludGVycnVwdChDUFVTSDRTdGF0ZSAq
IGVudikKK3ZvaWQgZG9faW50ZXJydXB0KENQVVNINFN0YXRlICplbnYpCiB7Ci0gICAgaW50IGRv
X2lycSA9IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CisgICAg
Q1BVU3RhdGUgKmNzID0gQ1BVKHNoX2Vudl9nZXRfY3B1KGVudikpOworICAgIGludCBkb19pcnEg
PSBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CiAgICAgaW50IGRv
X2V4cCwgaXJxX3ZlY3RvciA9IGVudi0+ZXhjZXB0aW9uX2luZGV4OwogCiAgICAgLyogcHJpb3Jp
dGl6ZSBleGNlcHRpb25zIG92ZXIgaW50ZXJydXB0cyAqLwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXNo
NC9vcF9oZWxwZXIuYyBiL3RhcmdldC1zaDQvb3BfaGVscGVyLmMKaW5kZXggMDllM2QyMy4uZTk1
NWU4MSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXNoNC9vcF9oZWxwZXIuYworKysgYi90YXJnZXQtc2g0
L29wX2hlbHBlci5jCkBAIC0xMDIsNyArMTAyLDkgQEAgdm9pZCBoZWxwZXJfZGVidWcoQ1BVU0g0
U3RhdGUgKmVudikKIAogdm9pZCBoZWxwZXJfc2xlZXAoQ1BVU0g0U3RhdGUgKmVudikKIHsKLSAg
ICBlbnYtPmhhbHRlZCA9IDE7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHNoX2Vudl9nZXRfY3B1
KGVudikpOworCisgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgZW52LT5pbl9zbGVlcCA9IDE7CiAg
ICAgcmFpc2VfZXhjZXB0aW9uKGVudiwgRVhDUF9ITFQsIDApOwogfQpkaWZmIC0tZ2l0IGEvdGFy
Z2V0LXNwYXJjL2NwdS5oIGIvdGFyZ2V0LXNwYXJjL2NwdS5oCmluZGV4IDczODliMDMuLjk1Y2Ji
YTAgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zcGFyYy9jcHUuaAorKysgYi90YXJnZXQtc3BhcmMvY3B1
LmgKQEAgLTc2MSw5ICs3NjEsMTAgQEAgc3RhdGljIGlubGluZSBib29sIHRiX2FtX2VuYWJsZWQo
aW50IHRiX2ZsYWdzKQogCiBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRl
ICpjcHUpCiB7Ci0gICAgQ1BVU1BBUkNTdGF0ZSAqZW52MSA9ICZTUEFSQ19DUFUoY3B1KS0+ZW52
OworICAgIFNQQVJDQ1BVICpzcGFyY19jcHUgPSBTUEFSQ19DUFUoY3B1KTsKKyAgICBDUFVTUEFS
Q1N0YXRlICplbnYxID0gJnNwYXJjX2NwdS0+ZW52OwogCi0gICAgcmV0dXJuIChlbnYxLT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKKyAgICByZXR1cm4gKGNwdS0+
aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAgICAgICAgIGNw
dV9pbnRlcnJ1cHRzX2VuYWJsZWQoZW52MSk7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC11bmlj
b3JlMzIvY3B1LmggYi90YXJnZXQtdW5pY29yZTMyL2NwdS5oCmluZGV4IGFlOWE5ZDYuLjU4ZjFm
MjAgMTAwNjQ0Ci0tLSBhL3RhcmdldC11bmljb3JlMzIvY3B1LmgKKysrIGIvdGFyZ2V0LXVuaWNv
cmUzMi9jcHUuaApAQCAtMTgxLDkgKzE4MSw3IEBAIHZvaWQgc3dpdGNoX21vZGUoQ1BVVW5pQ29y
ZTMyU3RhdGUgKiwgaW50KTsKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVT
dGF0ZSAqY3B1KQogewotICAgIENQVVVuaUNvcmUzMlN0YXRlICplbnYgPSAmVU5JQ09SRTMyX0NQ
VShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmCisgICAg
cmV0dXJuIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJgogICAgICAgICAoQ1BVX0lOVEVSUlVQVF9I
QVJEIHwgQ1BVX0lOVEVSUlVQVF9FWElUVEIpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtdW5p
Y29yZTMyL3NvZnRtbXUuYyBiL3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jCmluZGV4IGZjMjcx
MDAuLjFjNGM3ZjUgMTAwNjQ0Ci0tLSBhL3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jCisrKyBi
L3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jCkBAIC03NCw2ICs3NCw3IEBAIHZvaWQgc3dpdGNo
X21vZGUoQ1BVVW5pQ29yZTMyU3RhdGUgKmVudiwgaW50IG1vZGUpCiAvKiBIYW5kbGUgYSBDUFUg
ZXhjZXB0aW9uLiAgKi8KIHZvaWQgZG9faW50ZXJydXB0KENQVVVuaUNvcmUzMlN0YXRlICplbnYp
CiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHVjMzJfZW52X2dldF9jcHUoZW52KSk7CiAgICAg
dWludDMyX3QgYWRkcjsKICAgICBpbnQgbmV3X21vZGU7CiAKQEAgLTExMiw3ICsxMTMsNyBAQCB2
b2lkIGRvX2ludGVycnVwdChDUFVVbmlDb3JlMzJTdGF0ZSAqZW52KQogICAgIC8qIFRoZSBQQyBh
bHJlYWR5IHBvaW50cyB0byB0aGUgcHJvcGVyIGluc3RydWN0aW9uLiAgKi8KICAgICBlbnYtPnJl
Z3NbMzBdID0gZW52LT5yZWdzWzMxXTsKICAgICBlbnYtPnJlZ3NbMzFdID0gYWRkcjsKLSAgICBl
bnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOworICAgIGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKIH0KIAogc3RhdGljIGlu
dCBnZXRfcGh5c19hZGRyX3VjdjIoQ1BVVW5pQ29yZTMyU3RhdGUgKmVudiwgdWludDMyX3QgYWRk
cmVzcywKZGlmZiAtLWdpdCBhL3RhcmdldC14dGVuc2Evb3BfaGVscGVyLmMgYi90YXJnZXQteHRl
bnNhL29wX2hlbHBlci5jCmluZGV4IDM4MTNhNzIuLjEwMzcxMDEgMTAwNjQ0Ci0tLSBhL3Rhcmdl
dC14dGVuc2Evb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LXh0ZW5zYS9vcF9oZWxwZXIuYwpAQCAt
MzczLDYgKzM3Myw4IEBAIHZvaWQgSEVMUEVSKGR1bXBfc3RhdGUpKENQVVh0ZW5zYVN0YXRlICpl
bnYpCiAKIHZvaWQgSEVMUEVSKHdhaXRpKShDUFVYdGVuc2FTdGF0ZSAqZW52LCB1aW50MzJfdCBw
YywgdWludDMyX3QgaW50bGV2ZWwpCiB7CisgICAgQ1BVU3RhdGUgKmNwdTsKKwogICAgIGVudi0+
cGMgPSBwYzsKICAgICBlbnYtPnNyZWdzW1BTXSA9IChlbnYtPnNyZWdzW1BTXSAmIH5QU19JTlRM
RVZFTCkgfAogICAgICAgICAoaW50bGV2ZWwgPDwgUFNfSU5UTEVWRUxfU0hJRlQpOwpAQCAtMzgy
LDggKzM4NCw5IEBAIHZvaWQgSEVMUEVSKHdhaXRpKShDUFVYdGVuc2FTdGF0ZSAqZW52LCB1aW50
MzJfdCBwYywgdWludDMyX3QgaW50bGV2ZWwpCiAgICAgICAgIHJldHVybjsKICAgICB9CiAKKyAg
ICBjcHUgPSBDUFUoeHRlbnNhX2Vudl9nZXRfY3B1KGVudikpOwogICAgIGVudi0+aGFsdF9jbG9j
ayA9IHFlbXVfZ2V0X2Nsb2NrX25zKHZtX2Nsb2NrKTsKLSAgICBlbnYtPmhhbHRlZCA9IDE7Cisg
ICAgY3B1LT5oYWx0ZWQgPSAxOwogICAgIGlmICh4dGVuc2Ffb3B0aW9uX2VuYWJsZWQoZW52LT5j
b25maWcsIFhURU5TQV9PUFRJT05fVElNRVJfSU5URVJSVVBUKSkgewogICAgICAgICB4dGVuc2Ff
cmVhcm1fY2NvbXBhcmVfdGltZXIoZW52KTsKICAgICB9CmRpZmYgLS1naXQgYS90cmFuc2xhdGUt
YWxsLmMgYi90cmFuc2xhdGUtYWxsLmMKaW5kZXggMTliYzQxNC4uMjE3NjEzMiAxMDA2NDQKLS0t
IGEvdHJhbnNsYXRlLWFsbC5jCisrKyBiL3RyYW5zbGF0ZS1hbGwuYwpAQCAtMTA4Nyw4ICsxMDg3
LDggQEAgdm9pZCB0Yl9pbnZhbGlkYXRlX3BoeXNfcGFnZV9yYW5nZSh0Yl9wYWdlX2FkZHJfdCBz
dGFydCwgdGJfcGFnZV9hZGRyX3QgZW5kLAogICAgICAgICAgICAgdGJfcGh5c19pbnZhbGlkYXRl
KHRiLCAtMSk7CiAgICAgICAgICAgICBpZiAoY3B1ICE9IE5VTEwpIHsKICAgICAgICAgICAgICAg
ICBjcHUtPmN1cnJlbnRfdGIgPSBzYXZlZF90YjsKLSAgICAgICAgICAgICAgICBpZiAoZW52ICYm
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiYgY3B1LT5jdXJyZW50X3RiKSB7Ci0gICAgICAgICAg
ICAgICAgICAgIGNwdV9pbnRlcnJ1cHQoZW52LCBlbnYtPmludGVycnVwdF9yZXF1ZXN0KTsKKyAg
ICAgICAgICAgICAgICBpZiAoZW52ICYmIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiYgY3B1LT5j
dXJyZW50X3RiKSB7CisgICAgICAgICAgICAgICAgICAgIGNwdV9pbnRlcnJ1cHQoZW52LCBjcHUt
PmludGVycnVwdF9yZXF1ZXN0KTsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICB9CiAg
ICAgICAgIH0KQEAgLTE0NjUsOCArMTQ2NSw4IEBAIHN0YXRpYyB2b2lkIHRjZ19oYW5kbGVfaW50
ZXJydXB0KENQVUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKICAgICBDUFVTdGF0ZSAqY3B1ID0g
RU5WX0dFVF9DUFUoZW52KTsKICAgICBpbnQgb2xkX21hc2s7CiAKLSAgICBvbGRfbWFzayA9IGVu
di0+aW50ZXJydXB0X3JlcXVlc3Q7Ci0gICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBtYXNr
OworICAgIG9sZF9tYXNrID0gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdDsKKyAgICBjcHUtPmludGVy
cnVwdF9yZXF1ZXN0IHw9IG1hc2s7CiAKICAgICAvKgogICAgICAqIElmIGNhbGxlZCBmcm9tIGlv
dGhyZWFkIGNvbnRleHQsIHdha2UgdGhlIHRhcmdldCBjcHUgaW4KQEAgLTE2MjYsNyArMTYyNiw3
IEBAIHZvaWQgY3B1X2ludGVycnVwdChDUFVBcmNoU3RhdGUgKmVudiwgaW50IG1hc2spCiB7CiAg
ICAgQ1BVU3RhdGUgKmNwdSA9IEVOVl9HRVRfQ1BVKGVudik7CiAKLSAgICBlbnYtPmludGVycnVw
dF9yZXF1ZXN0IHw9IG1hc2s7CisgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBtYXNrOwog
ICAgIGNwdV91bmxpbmtfdGIoY3B1KTsKIH0KIApkaWZmIC0tZ2l0IGEveGVuLWFsbC5jIGIveGVu
LWFsbC5jCmluZGV4IDExMGY5NTguLjhjMDU4NDMgMTAwNjQ0Ci0tLSBhL3hlbi1hbGwuYworKysg
Yi94ZW4tYWxsLmMKQEAgLTU3OCwxNiArNTc4LDE4IEBAIHZvaWQgcW1wX3hlbl9zZXRfZ2xvYmFs
X2RpcnR5X2xvZyhib29sIGVuYWJsZSwgRXJyb3IgKiplcnJwKQogCiBzdGF0aWMgdm9pZCB4ZW5f
cmVzZXRfdmNwdSh2b2lkICpvcGFxdWUpCiB7Ci0gICAgQ1BVQXJjaFN0YXRlICplbnYgPSBvcGFx
dWU7CisgICAgQ1BVU3RhdGUgKmNwdSA9IG9wYXF1ZTsKIAotICAgIGVudi0+aGFsdGVkID0gMTsK
KyAgICBjcHUtPmhhbHRlZCA9IDE7CiB9CiAKIHZvaWQgeGVuX3ZjcHVfaW5pdCh2b2lkKQogewog
ICAgIGlmIChmaXJzdF9jcHUgIT0gTlVMTCkgewotICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0
KHhlbl9yZXNldF92Y3B1LCBmaXJzdF9jcHUpOwotICAgICAgICB4ZW5fcmVzZXRfdmNwdShmaXJz
dF9jcHUpOworICAgICAgICBDUFVTdGF0ZSAqY3B1ID0gRU5WX0dFVF9DUFUoZmlyc3RfY3B1KTsK
KworICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0KHhlbl9yZXNldF92Y3B1LCBjcHUpOworICAg
ICAgICB4ZW5fcmVzZXRfdmNwdShjcHUpOwogICAgIH0KICAgICAvKiBpZiBydGNfY2xvY2sgaXMg
bGVmdCB0byBkZWZhdWx0IChob3N0X2Nsb2NrKSwgZGlzYWJsZSBpdCAqLwogICAgIGlmIChydGNf
Y2xvY2sgPT0gaG9zdF9jbG9jaykgewotLSAKMS43LjEwLjQKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sat Feb 02 15:52:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 15:52: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 1U1fNT-0002Qb-8Z; Sat, 02 Feb 2013 15:51:39 +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 1U1fNR-0002QT-Co; Sat, 02 Feb 2013 15:51:37 +0000
Received: from [85.158.143.99:12337] by server-2.bemta-4.messagelabs.com id
	CB/F7-01597-8063D015; Sat, 02 Feb 2013 15:51:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1359820295!30537638!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 746 invoked from network); 2 Feb 2013 15:51:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 15:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; 
   d="scan'208";a="1093448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 15:51:35 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Sat, 2 Feb 2013
	15:51:35 +0000
Message-ID: <510D3609.80301@citrix.com>
Date: Sat, 2 Feb 2013 16:51:37 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
References: <20121026072821.GA9853@intersect>
	<1351237241.8558.9.camel@dagon.hellion.org.uk>
	<20121026121544.GA14662@intersect>
	<1351255054.15162.66.camel@zakaz.uk.xensource.com>
	<20121026170920.GA4835@intersect>
	<1351276218.11876.0.camel@dagon.hellion.org.uk>
	<51015DB8.40107@hosteurope.de>
	<1359105618.32057.58.camel@zakaz.uk.xensource.com>
	<51028DDE.9070907@citrix.com> <510680E6.6050406@hosteurope.de>
	<1359381541.12252.0.camel@zakaz.uk.xensource.com>
	<510BD542.10602@hosteurope.de>
In-Reply-To: <510BD542.10602@hosteurope.de>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Problemi using vif-route 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/02/13 15:46, Ulf Kreutzberg wrote:
> 
> On 28.01.2013 14:59, Ian Campbell wrote:
>> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote:
>>> The mac address is not parsed correctly if not padded with leading
>>> zeros (and no error reported, though): 
>>
>> Ick, well spotted. It is a bug in xl that it doesn't Do The Right Thing
>> here, even if stripping the leading zeroes is somewhat unconventional
>> IMHO.
>>
>> Ian.
> 
> How shall I proceed here? Shall I open a bug report or did some of you
> already open one?

Hello,

I've send a patch series that I think should fix your issues, could you
please try them and report back?

http://lists.xen.org/archives/html/xen-devel/2013-01/msg02217.html

Thanks, Roger.


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

From xen-devel-bounces@lists.xen.org Sat Feb 02 15:52:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 15:52: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 1U1fNT-0002Qb-8Z; Sat, 02 Feb 2013 15:51:39 +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 1U1fNR-0002QT-Co; Sat, 02 Feb 2013 15:51:37 +0000
Received: from [85.158.143.99:12337] by server-2.bemta-4.messagelabs.com id
	CB/F7-01597-8063D015; Sat, 02 Feb 2013 15:51:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1359820295!30537638!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 746 invoked from network); 2 Feb 2013 15:51:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 15:51:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; 
   d="scan'208";a="1093448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 15:51:35 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Sat, 2 Feb 2013
	15:51:35 +0000
Message-ID: <510D3609.80301@citrix.com>
Date: Sat, 2 Feb 2013 16:51:37 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
References: <20121026072821.GA9853@intersect>
	<1351237241.8558.9.camel@dagon.hellion.org.uk>
	<20121026121544.GA14662@intersect>
	<1351255054.15162.66.camel@zakaz.uk.xensource.com>
	<20121026170920.GA4835@intersect>
	<1351276218.11876.0.camel@dagon.hellion.org.uk>
	<51015DB8.40107@hosteurope.de>
	<1359105618.32057.58.camel@zakaz.uk.xensource.com>
	<51028DDE.9070907@citrix.com> <510680E6.6050406@hosteurope.de>
	<1359381541.12252.0.camel@zakaz.uk.xensource.com>
	<510BD542.10602@hosteurope.de>
In-Reply-To: <510BD542.10602@hosteurope.de>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Problemi using vif-route 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 01/02/13 15:46, Ulf Kreutzberg wrote:
> 
> On 28.01.2013 14:59, Ian Campbell wrote:
>> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote:
>>> The mac address is not parsed correctly if not padded with leading
>>> zeros (and no error reported, though): 
>>
>> Ick, well spotted. It is a bug in xl that it doesn't Do The Right Thing
>> here, even if stripping the leading zeroes is somewhat unconventional
>> IMHO.
>>
>> Ian.
> 
> How shall I proceed here? Shall I open a bug report or did some of you
> already open one?

Hello,

I've send a patch series that I think should fix your issues, could you
please try them and report back?

http://lists.xen.org/archives/html/xen-devel/2013-01/msg02217.html

Thanks, Roger.


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

From xen-devel-bounces@lists.xen.org Sat Feb 02 20:42:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 20:42: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 1U1jtv-0004FX-8K; Sat, 02 Feb 2013 20:41:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U1bRj-0007ld-CZ
	for xen-devel@lists.xen.org; Sat, 02 Feb 2013 11:39:47 +0000
Received: from [85.158.137.99:40967] by server-11.bemta-3.messagelabs.com id
	74/C2-10249-20BFC015; Sat, 02 Feb 2013 11:39:46 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1359805183!16486255!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11738 invoked from network); 2 Feb 2013 11:39:43 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 11:39:43 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so941523wie.8
	for <xen-devel@lists.xen.org>; Sat, 02 Feb 2013 03:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=Hw8QyOtIxPs0QVSaUxqPWIMAzhocme3a0QktFAqiUrE=;
	b=iGOXzWKfX3GMCFfMRZTZO4FjBHyDYYFb8tkEjzMuARk20D1RF9ecEvRCniQYDZwCWN
	xo3vlckeO0Jezv0ugWiSt8b0Ix/dIWyv33iAmS8cm79cFruzppnmIaGUS+vO999oeasS
	NxWhbXXtUicCuYqUpwpcdB0GGu6g1GNiNsg+VobDCX8YN4SCJWYvaIRjAwSDrcT2uYol
	nV/Vm3+LBx5OQPixTC0uKGYtss6s1uszgdiqGHqytJ4g+9PfPX21koY5a8Bi9KDsDFKU
	GoRAOQKueYFR9bd1Q7aIe/N0YAJTich9ORLMP6FyRtC9vh5nd7GjCFxRL/gGB2hO51ZP
	VSkQ==
MIME-Version: 1.0
X-Received: by 10.194.108.101 with SMTP id hj5mr26614116wjb.6.1359805183539;
	Sat, 02 Feb 2013 03:39:43 -0800 (PST)
Received: by 10.180.144.77 with HTTP; Sat, 2 Feb 2013 03:39:43 -0800 (PST)
Date: Sat, 2 Feb 2013 12:39:43 +0100
Message-ID: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Sat, 02 Feb 2013 20:41:26 +0000
Subject: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============3261794435837385297=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3261794435837385297==
Content-Type: multipart/alternative; boundary=047d7bf10a36edbb5804d4bc50e6

--047d7bf10a36edbb5804d4bc50e6
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I cannot resume from S3 sleep in Dom0. I'm running on Xen 4.2.1 with Dom0
3.6.11-1-ARCH linux. The laptop is lenovo T400 with Intel Core2 Duo
processor.

I've found in one of the previous threads that the problem might be caused
by lacking the acpi-cpufreq module in Dom0. However, when I try to load it,
I get 'no such device' error. This error is present on both, Domain0 based
cpufreq as well as Hypervisor based cpufreq power management.

I suspect this is a Xen related issue.
Thank you,
Milan

--047d7bf10a36edbb5804d4bc50e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Hello,<br><br></div>I cannot resu=
me from S3 sleep in Dom0. I&#39;m running on Xen 4.2.1 with Dom0 3.6.11-1-A=
RCH linux. The laptop is lenovo T400 with Intel Core2 Duo processor.<br><br=
>
</div>I&#39;ve found in one of the previous threads that the problem might =
be caused by lacking the acpi-cpufreq module in Dom0. However, when I try t=
o load it, I get &#39;no such device&#39; error. This error is present on b=
oth, Domain0 based cpufreq as well as Hypervisor based cpufreq power manage=
ment.<br>
<br></div>I suspect this is a Xen related issue.<br></div>Thank you,<br></d=
iv>Milan<br></div>

--047d7bf10a36edbb5804d4bc50e6--


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

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

--===============3261794435837385297==--


From xen-devel-bounces@lists.xen.org Sat Feb 02 20:42:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 20:42: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 1U1jtv-0004FX-8K; Sat, 02 Feb 2013 20:41:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U1bRj-0007ld-CZ
	for xen-devel@lists.xen.org; Sat, 02 Feb 2013 11:39:47 +0000
Received: from [85.158.137.99:40967] by server-11.bemta-3.messagelabs.com id
	74/C2-10249-20BFC015; Sat, 02 Feb 2013 11:39:46 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1359805183!16486255!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11738 invoked from network); 2 Feb 2013 11:39:43 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 11:39:43 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so941523wie.8
	for <xen-devel@lists.xen.org>; Sat, 02 Feb 2013 03:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=Hw8QyOtIxPs0QVSaUxqPWIMAzhocme3a0QktFAqiUrE=;
	b=iGOXzWKfX3GMCFfMRZTZO4FjBHyDYYFb8tkEjzMuARk20D1RF9ecEvRCniQYDZwCWN
	xo3vlckeO0Jezv0ugWiSt8b0Ix/dIWyv33iAmS8cm79cFruzppnmIaGUS+vO999oeasS
	NxWhbXXtUicCuYqUpwpcdB0GGu6g1GNiNsg+VobDCX8YN4SCJWYvaIRjAwSDrcT2uYol
	nV/Vm3+LBx5OQPixTC0uKGYtss6s1uszgdiqGHqytJ4g+9PfPX21koY5a8Bi9KDsDFKU
	GoRAOQKueYFR9bd1Q7aIe/N0YAJTich9ORLMP6FyRtC9vh5nd7GjCFxRL/gGB2hO51ZP
	VSkQ==
MIME-Version: 1.0
X-Received: by 10.194.108.101 with SMTP id hj5mr26614116wjb.6.1359805183539;
	Sat, 02 Feb 2013 03:39:43 -0800 (PST)
Received: by 10.180.144.77 with HTTP; Sat, 2 Feb 2013 03:39:43 -0800 (PST)
Date: Sat, 2 Feb 2013 12:39:43 +0100
Message-ID: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Sat, 02 Feb 2013 20:41:26 +0000
Subject: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============3261794435837385297=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3261794435837385297==
Content-Type: multipart/alternative; boundary=047d7bf10a36edbb5804d4bc50e6

--047d7bf10a36edbb5804d4bc50e6
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I cannot resume from S3 sleep in Dom0. I'm running on Xen 4.2.1 with Dom0
3.6.11-1-ARCH linux. The laptop is lenovo T400 with Intel Core2 Duo
processor.

I've found in one of the previous threads that the problem might be caused
by lacking the acpi-cpufreq module in Dom0. However, when I try to load it,
I get 'no such device' error. This error is present on both, Domain0 based
cpufreq as well as Hypervisor based cpufreq power management.

I suspect this is a Xen related issue.
Thank you,
Milan

--047d7bf10a36edbb5804d4bc50e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Hello,<br><br></div>I cannot resu=
me from S3 sleep in Dom0. I&#39;m running on Xen 4.2.1 with Dom0 3.6.11-1-A=
RCH linux. The laptop is lenovo T400 with Intel Core2 Duo processor.<br><br=
>
</div>I&#39;ve found in one of the previous threads that the problem might =
be caused by lacking the acpi-cpufreq module in Dom0. However, when I try t=
o load it, I get &#39;no such device&#39; error. This error is present on b=
oth, Domain0 based cpufreq as well as Hypervisor based cpufreq power manage=
ment.<br>
<br></div>I suspect this is a Xen related issue.<br></div>Thank you,<br></d=
iv>Milan<br></div>

--047d7bf10a36edbb5804d4bc50e6--


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

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

--===============3261794435837385297==--


From xen-devel-bounces@lists.xen.org Sat Feb 02 21:36:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 21:36: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 1U1kkT-0004WN-Mj; Sat, 02 Feb 2013 21:35:45 +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 1U1kkR-0004WG-Cu
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 21:35:43 +0000
Received: from [193.109.254.147:61527] by server-4.bemta-14.messagelabs.com id
	ED/58-20719-EA68D015; Sat, 02 Feb 2013 21:35:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359840935!9881443!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8219 invoked from network); 2 Feb 2013 21:35:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 21:35:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; 
   d="scan'208";a="1095035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 21:35: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.297.1; Sat, 2 Feb 2013 21:35:34 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1kkI-0004ri-Bq;
	Sat, 02 Feb 2013 21:35:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1kkH-00016P-V8;
	Sat, 02 Feb 2013 21:35:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15411-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Feb 2013 21:35:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15411: 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 15411 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15411/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sat Feb 02 21:36:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 02 Feb 2013 21:36: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 1U1kkT-0004WN-Mj; Sat, 02 Feb 2013 21:35:45 +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 1U1kkR-0004WG-Cu
	for xen-devel@lists.xensource.com; Sat, 02 Feb 2013 21:35:43 +0000
Received: from [193.109.254.147:61527] by server-4.bemta-14.messagelabs.com id
	ED/58-20719-EA68D015; Sat, 02 Feb 2013 21:35:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359840935!9881443!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8219 invoked from network); 2 Feb 2013 21:35:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Feb 2013 21:35:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; 
   d="scan'208";a="1095035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Feb 2013 21:35: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.297.1; Sat, 2 Feb 2013 21:35:34 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1kkI-0004ri-Bq;
	Sat, 02 Feb 2013 21:35:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1kkH-00016P-V8;
	Sat, 02 Feb 2013 21:35:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15411-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 2 Feb 2013 21:35:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15411: 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 15411 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15411/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sun Feb 03 04:30:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Feb 2013 04: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 1U1rDC-0002j6-Om; Sun, 03 Feb 2013 04:29: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 1U1rDA-0002j1-DQ
	for xen-devel@lists.xensource.com; Sun, 03 Feb 2013 04:29:48 +0000
Received: from [85.158.143.99:38448] by server-2.bemta-4.messagelabs.com id
	64/94-01597-BB7ED015; Sun, 03 Feb 2013 04:29:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1359865786!27103230!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21077 invoked from network); 3 Feb 2013 04:29:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2013 04:29:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; 
   d="scan'208";a="1096614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2013 04:29: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.297.1; Sun, 3 Feb 2013 04:29:46 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1rD8-0006su-Au;
	Sun, 03 Feb 2013 04:29:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1rD7-0003Se-Uv;
	Sun, 03 Feb 2013 04:29:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15412-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Feb 2013 04:29:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15412: 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 15412 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15412/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sun Feb 03 04:30:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Feb 2013 04: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 1U1rDC-0002j6-Om; Sun, 03 Feb 2013 04:29: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 1U1rDA-0002j1-DQ
	for xen-devel@lists.xensource.com; Sun, 03 Feb 2013 04:29:48 +0000
Received: from [85.158.143.99:38448] by server-2.bemta-4.messagelabs.com id
	64/94-01597-BB7ED015; Sun, 03 Feb 2013 04:29:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1359865786!27103230!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21077 invoked from network); 3 Feb 2013 04:29:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2013 04:29:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; 
   d="scan'208";a="1096614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2013 04:29: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.297.1; Sun, 3 Feb 2013 04:29:46 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1rD8-0006su-Au;
	Sun, 03 Feb 2013 04:29:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1rD7-0003Se-Uv;
	Sun, 03 Feb 2013 04:29:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15412-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Feb 2013 04:29:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15412: 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 15412 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15412/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sun Feb 03 11:29:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Feb 2013 11:29: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 1U1xkj-0007Ci-Rv; Sun, 03 Feb 2013 11:28: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 1U1xki-0007Cd-HZ
	for xen-devel@lists.xensource.com; Sun, 03 Feb 2013 11:28:52 +0000
Received: from [193.109.254.147:62722] by server-11.bemta-14.messagelabs.com
	id 22/83-30685-3F94E015; Sun, 03 Feb 2013 11:28:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1359890928!8972785!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19380 invoked from network); 3 Feb 2013 11:28:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2013 11:28:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,593,1355097600"; 
   d="scan'208";a="1099260"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2013 11:28: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.297.1; Sun, 3 Feb 2013 11:28:48 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1xke-0000YL-2x;
	Sun, 03 Feb 2013 11:28:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1xkd-0004RD-Qq;
	Sun, 03 Feb 2013 11:28:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15413-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Feb 2013 11:28:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15413: 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 15413 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15413/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore     fail pass in 15412

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 15412 like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 15412 never pass

version targeted for testing:
 xen                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sun Feb 03 11:29:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Feb 2013 11:29: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 1U1xkj-0007Ci-Rv; Sun, 03 Feb 2013 11:28: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 1U1xki-0007Cd-HZ
	for xen-devel@lists.xensource.com; Sun, 03 Feb 2013 11:28:52 +0000
Received: from [193.109.254.147:62722] by server-11.bemta-14.messagelabs.com
	id 22/83-30685-3F94E015; Sun, 03 Feb 2013 11:28:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1359890928!8972785!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19380 invoked from network); 3 Feb 2013 11:28:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2013 11:28:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,593,1355097600"; 
   d="scan'208";a="1099260"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2013 11:28: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.297.1; Sun, 3 Feb 2013 11:28:48 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U1xke-0000YL-2x;
	Sun, 03 Feb 2013 11:28:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U1xkd-0004RD-Qq;
	Sun, 03 Feb 2013 11:28:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15413-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Feb 2013 11:28:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15413: 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 15413 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15413/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore     fail pass in 15412

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 15412 like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 15412 never pass

version targeted for testing:
 xen                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sun Feb 03 18:17:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Feb 2013 18:17: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 1U247l-0001PK-Au; Sun, 03 Feb 2013 18:17:05 +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 1U247i-0001PF-RR
	for xen-devel@lists.xensource.com; Sun, 03 Feb 2013 18:17:03 +0000
Received: from [85.158.138.51:14901] by server-15.bemta-3.messagelabs.com id
	28/40-25405-A99AE015; Sun, 03 Feb 2013 18:16:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1359915410!22671423!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10598 invoked from network); 3 Feb 2013 18:16:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2013 18:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,595,1355097600"; 
   d="scan'208";a="1101652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2013 18:16: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.297.1; Sun, 3 Feb 2013 18:16:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U247W-0002XE-7j;
	Sun, 03 Feb 2013 18:16:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U247V-0006iq-Q8;
	Sun, 03 Feb 2013 18:16:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15414-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Feb 2013 18:16:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15414: 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 15414 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15414/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Sun Feb 03 18:17:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 03 Feb 2013 18:17: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 1U247l-0001PK-Au; Sun, 03 Feb 2013 18:17:05 +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 1U247i-0001PF-RR
	for xen-devel@lists.xensource.com; Sun, 03 Feb 2013 18:17:03 +0000
Received: from [85.158.138.51:14901] by server-15.bemta-3.messagelabs.com id
	28/40-25405-A99AE015; Sun, 03 Feb 2013 18:16:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1359915410!22671423!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10598 invoked from network); 3 Feb 2013 18:16:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Feb 2013 18:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,595,1355097600"; 
   d="scan'208";a="1101652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Feb 2013 18:16: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.297.1; Sun, 3 Feb 2013 18:16:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U247W-0002XE-7j;
	Sun, 03 Feb 2013 18:16:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U247V-0006iq-Q8;
	Sun, 03 Feb 2013 18:16:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15414-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 3 Feb 2013 18:16:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15414: 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 15414 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15414/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 00:58:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 00:58: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 1U2ANc-0004xc-Ld; Mon, 04 Feb 2013 00:57:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1U2ANb-0004xX-BZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 00:57:51 +0000
Received: from [193.109.254.147:23372] by server-9.bemta-14.messagelabs.com id
	46/B8-30867-E870F015; Mon, 04 Feb 2013 00:57:50 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1359939467!9080246!1
X-Originating-IP: [209.85.210.176]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18261 invoked from network); 4 Feb 2013 00:57:48 -0000
Received: from mail-ia0-f176.google.com (HELO mail-ia0-f176.google.com)
	(209.85.210.176)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 00:57:48 -0000
Received: by mail-ia0-f176.google.com with SMTP id i18so7469827iac.21
	for <xen-devel@lists.xen.org>; Sun, 03 Feb 2013 16:57:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=WYAwY+F9D9OWxzfhwOrxZwzt1oKn/TsxJHO6bSh54EU=;
	b=Z9qGdaSJgVPwZI8wLSYpBeanhdynhsFo0oPRIL71AG/SuYezBIRMeSSJeAGuLKs6OG
	NuM3Re0rO5YIneJPzS7bYBp+5X/tbDf8lHQXe0zbGGlrxOdPgpj1RwF/58lLolkMPJfa
	cB9Kz4FNJ5rIg02eNXZ8xxeKWoX3w8FqkOVes4dBVScjYOAAR4xeFLGq5CBlK4/4wIoY
	Qec36iEnSEf5ToNikHGLGL6sD1tIfvyL8T5PtSoT3uv1l0L/ghVKca9luG7tp90WM3Nm
	kdy74IDo5Wmp7rKIS5K+0lylGKtQy75qUc5q7xzXIkFWmo/IPlhgxcrkZQ5D6DdJfOUz
	ynlQ==
MIME-Version: 1.0
X-Received: by 10.42.212.8 with SMTP id gq8mr13681476icb.48.1359939467127;
	Sun, 03 Feb 2013 16:57:47 -0800 (PST)
Received: by 10.231.73.2 with HTTP; Sun, 3 Feb 2013 16:57:47 -0800 (PST)
In-Reply-To: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
Date: Sun, 3 Feb 2013 19:57:47 -0500
X-Google-Sender-Auth: _nBSbK5GenbKHcv9rSRjZ9fkzkU
Message-ID: <CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Milan opath <milan.opath@gmail.com>
Content-Type: multipart/mixed; boundary=20cf301d43b0daadac04d4db94fb
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure what Arch linux uses for a kernel, as I'm not terribly
familiar with the distro.

That said, a number of things are needed to get this to work, that are
not accepted upstream.

1. You'll need one of Konrad's acpi-s3 branches, or the patches from
the tip of those branches:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/acpi-s3.v9

2. Apply the attached patches in the following order:
fix-dmar-zap-reinstate
fix-suspend-scheduler-v2
fix-suspend-scheduler-revert-affinity-part
s3-timerirq

All of these fixes have been proposed to the xen-devel list, but have
not yet been accepted, for one reason, or another.

I've CC'ed Konrad, and Tomasz who authored some of the things
mentioned above, and Jan Beulich who has been commenting on the
validity / correctness of these changes.


Ben

On Sat, Feb 2, 2013 at 6:39 AM, Milan opath <milan.opath@gmail.com> wrote:
> Hello,
>
> I cannot resume from S3 sleep in Dom0. I'm running on Xen 4.2.1 with Dom0
> 3.6.11-1-ARCH linux. The laptop is lenovo T400 with Intel Core2 Duo
> processor.
>
> I've found in one of the previous threads that the problem might be caused
> by lacking the acpi-cpufreq module in Dom0. However, when I try to load it,
> I get 'no such device' error. This error is present on both, Domain0 based
> cpufreq as well as Hypervisor based cpufreq power management.
>
> I suspect this is a Xen related issue.
> Thank you,
> Milan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; name="fix-dmar-zap-reinstate.txt"
Content-Disposition: attachment; filename="fix-dmar-zap-reinstate.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwoojl0

ZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2FjcGkvdGFibGVzL3RieGZhY2UuYyBiL3hlbi9kcml2
ZXJzL2FjcGkvdGFibGVzL3RieGZhY2UuYwppbmRleCBkZjZlZWJhLi4xNjAyYmIyIDEwMDY0NAot
LS0gYS94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy90YnhmYWNlLmMKKysrIGIveGVuL2RyaXZlcnMv
YWNwaS90YWJsZXMvdGJ4ZmFjZS5jCkBAIC0yMDUsMyArMjA1LDUxIEBAIGFjcGlfZ2V0X3RhYmxl
KGNoYXIgKnNpZ25hdHVyZSwKIAogCXJldHVybiAoQUVfTk9UX0ZPVU5EKTsKIH0KKworLyoqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgorICoKKyAqIEZVTkNUSU9OOiAgICBhY3BpX2dldF90YWJsZV9waHlz
CisgKgorICogUEFSQU1FVEVSUzogIHNpZ25hdHVyZSAgICAgIC0gQUNQSSBzaWduYXR1cmUgb2Yg
bmVlZGVkIHRhYmxlCisgKiAgICAgICAgICAgICAgaW5zdGFuY2UgICAgICAgLSBXaGljaCBpbnN0
YW5jZSAoZm9yIFNTRFRzKQorICogICAgICAgICAgICAgIGFkZHIgICAgICAgICAgIC0gV2hlcmUg
dGhlIHRhYmxlJ3MgcGh5c2ljYWwgYWRkcmVzcyBpcyByZXR1cm5lZAorICogICAgICAgICAgICAg
IGxlbiAgICAgICAgICAgIC0gV2hlcmUgdGhlIGxlbmd0aCBvZiB0YWJsZSBpcyByZXR1cm5lZAor
ICoKKyAqIFJFVFVSTjogICAgICBTdGF0dXMsIHBvaW50ZXIgYW5kIGxlbmd0aCBvZiB0YWJsZQor
ICoKKyAqIERFU0NSSVBUSU9OOiBGaW5kcyBwaHlzaWNhbCBhZGRyZXNzIGFuZCBsZW5ndGggb2Yg
QUNQSSB0YWJsZQorICoKKyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KK2FjcGlfc3RhdHVzIF9faW5p
dAorYWNwaV9nZXRfdGFibGVfcGh5cyhhY3BpX3N0cmluZyBzaWduYXR1cmUsIGFjcGlfbmF0aXZl
X3VpbnQgaW5zdGFuY2UsCisJCSAgICAgYWNwaV9waHlzaWNhbF9hZGRyZXNzICphZGRyLCBhY3Bp
X25hdGl2ZV91aW50ICpsZW4pCit7CisJYWNwaV9uYXRpdmVfdWludCBpLCBqOworCWFjcGlfc3Rh
dHVzIHN0YXR1czsKKworCWlmICghc2lnbmF0dXJlIHx8ICFhZGRyIHx8ICFsZW4pCisJCXJldHVy
biBBRV9CQURfUEFSQU1FVEVSOworCisJZm9yIChpID0gaiA9IDA7IGkgPCBhY3BpX2dibF9yb290
X3RhYmxlX2xpc3QuY291bnQ7IGkrKykgeworCQlpZiAoIUFDUElfQ09NUEFSRV9OQU1FKAorCQkJ
CSZhY3BpX2dibF9yb290X3RhYmxlX2xpc3QudGFibGVzW2ldLnNpZ25hdHVyZSwKKwkJCQlzaWdu
YXR1cmUpKQorCQkJY29udGludWU7CisKKwkJaWYgKCsraiA8IGluc3RhbmNlKQorCQkJY29udGlu
dWU7CisKKwkJc3RhdHVzID0KKwkJICAgIGFjcGlfdGJfdmVyaWZ5X3RhYmxlKCZhY3BpX2dibF9y
b290X3RhYmxlX2xpc3QudGFibGVzW2ldKTsKKwkJaWYgKEFDUElfU1VDQ0VTUyhzdGF0dXMpKSB7
CisJCQkqYWRkciA9IGFjcGlfZ2JsX3Jvb3RfdGFibGVfbGlzdC50YWJsZXNbaV0uYWRkcmVzczsK
KwkJCSpsZW4gPSBhY3BpX2dibF9yb290X3RhYmxlX2xpc3QudGFibGVzW2ldLmxlbmd0aDsKKwkJ
fQorCisJCWFjcGlfZ2JsX3Jvb3RfdGFibGVfbGlzdC50YWJsZXNbaV0ucG9pbnRlciA9IE5VTEw7
CisKKwkJcmV0dXJuIHN0YXR1czsKKwl9CisKKwlyZXR1cm4gQUVfTk9UX0ZPVU5EOworfQpkaWZm
IC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkL2RtYXIuYyBiL3hlbi9kcml2ZXJz
L3Bhc3N0aHJvdWdoL3Z0ZC9kbWFyLmMKaW5kZXggM2ZiYzVlNi4uNzNhZDFkNyAxMDA2NDQKLS0t
IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkL2RtYXIuYworKysgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC92dGQvZG1hci5jCkBAIC03ODYsNyArNzg2LDE4IEBAIG91dDoKIAogaW50IF9f
aW5pdCBhY3BpX2RtYXJfaW5pdCh2b2lkKQogewotICAgIGFjcGlfZ2V0X3RhYmxlKEFDUElfU0lH
X0RNQVIsIDAsICZkbWFyX3RhYmxlKTsKKyAgICBhY3BpX3BoeXNpY2FsX2FkZHJlc3MgZG1hcl9h
ZGRyOworICAgIGFjcGlfbmF0aXZlX3VpbnQgZG1hcl9sZW47CisKKyAgICBpZiAoIEFDUElfU1VD
Q0VTUyhhY3BpX2dldF90YWJsZV9waHlzKEFDUElfU0lHX0RNQVIsIDAsCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZG1hcl9hZGRyLCAmZG1hcl9sZW4pKSApCisg
ICAgeworICAgICAgICBtYXBfcGFnZXNfdG9feGVuKCh1bnNpZ25lZCBsb25nKV9fdmEoZG1hcl9h
ZGRyKSwgUEZOX0RPV04oZG1hcl9hZGRyKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICBQRk5f
VVAoZG1hcl9hZGRyICsgZG1hcl9sZW4pIC0gUEZOX0RPV04oZG1hcl9hZGRyKSwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICBQQUdFX0hZUEVSVklTT1IpOworICAgICAgICBkbWFyX3RhYmxlID0g
X192YShkbWFyX2FkZHIpOworICAgIH0KKwogICAgIHJldHVybiBwYXJzZV9kbWFyX3RhYmxlKGFj
cGlfcGFyc2VfZG1hcik7CiB9CiAKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FjcGkvYWNwaXhm
LmggYi94ZW4vaW5jbHVkZS9hY3BpL2FjcGl4Zi5oCmluZGV4IGNkMmI0ZmIuLjdhZTFmMDcgMTAw
NjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FjcGkvYWNwaXhmLmgKKysrIGIveGVuL2luY2x1ZGUvYWNw
aS9hY3BpeGYuaApAQCAtNzcsNiArNzcsOSBAQCBhY3BpX3N0YXR1cwogYWNwaV9nZXRfdGFibGUo
YWNwaV9zdHJpbmcgc2lnbmF0dXJlLAogCSAgICAgICBhY3BpX25hdGl2ZV91aW50IGluc3RhbmNl
LCBzdHJ1Y3QgYWNwaV90YWJsZV9oZWFkZXIgKipvdXRfdGFibGUpOwogCithY3BpX3N0YXR1cwor
YWNwaV9nZXRfdGFibGVfcGh5cyhhY3BpX3N0cmluZyBzaWduYXR1cmUsIGFjcGlfbmF0aXZlX3Vp
bnQgaW5zdGFuY2UsCisJCSAgICAgYWNwaV9waHlzaWNhbF9hZGRyZXNzICphZGRyLCBhY3BpX25h
dGl2ZV91aW50ICpsZW4pOwogLyoKICAqIE5hbWVzcGFjZSBhbmQgbmFtZSBpbnRlcmZhY2VzCiAg
Ki8K
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; 
	name="fix-suspend-scheduler-revert-affinity-part.txt"
Content-Disposition: attachment; 
	filename="fix-suspend-scheduler-revert-affinity-part.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwook51

ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWR1bGUuYyBiL3hlbi9jb21tb24vc2NoZWR1bGUu
YwppbmRleCBlZWZjYTFjLi5mZmNhZmNkIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3NjaGVkdWxl
LmMKKysrIGIveGVuL2NvbW1vbi9zY2hlZHVsZS5jCkBAIC01NTQsOCArNTU0LDcgQEAgaW50IGNw
dV9kaXNhYmxlX3NjaGVkdWxlcih1bnNpZ25lZCBpbnQgY3B1KQogCiAgICAgICAgICAgICBjcHVt
YXNrX2FuZCgmb25saW5lX2FmZmluaXR5LCB2LT5jcHVfYWZmaW5pdHksIGMtPmNwdV92YWxpZCk7
CiAgICAgICAgICAgICBpZiAoIGNwdW1hc2tfZW1wdHkoJm9ubGluZV9hZmZpbml0eSkgJiYKLSAg
ICAgICAgICAgICAgICAgY3B1bWFza190ZXN0X2NwdShjcHUsIHYtPmNwdV9hZmZpbml0eSkgJiYK
LSAgICAgICAgICAgICAgICAgc3lzdGVtX3N0YXRlICE9IFNZU19TVEFURV9zdXNwZW5kICkKKyAg
ICAgICAgICAgICAgICAgY3B1bWFza190ZXN0X2NwdShjcHUsIHYtPmNwdV9hZmZpbml0eSkgKQog
ICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIHByaW50aygiQnJlYWtpbmcgdmNwdSBhZmZp
bml0eSBmb3IgZG9tYWluICVkIHZjcHUgJWRcbiIsCiAgICAgICAgICAgICAgICAgICAgICAgICB2
LT5kb21haW4tPmRvbWFpbl9pZCwgdi0+dmNwdV9pZCk7Cg==
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; name="fix-suspend-scheduler-v2.txt"
Content-Disposition: attachment; filename="fix-suspend-scheduler-v2.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwook72

ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vY3B1LmMgYi94ZW4vY29tbW9uL2NwdS5jCmluZGV4IDYz
MDg4MWUuLmUyMDg2OGMgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vY3B1LmMKKysrIGIveGVuL2Nv
bW1vbi9jcHUuYwpAQCAtNSw2ICs1LDcgQEAKICNpbmNsdWRlIDx4ZW4vaW5pdC5oPgogI2luY2x1
ZGUgPHhlbi9zY2hlZC5oPgogI2luY2x1ZGUgPHhlbi9zdG9wX21hY2hpbmUuaD4KKyNpbmNsdWRl
IDx4ZW4vc2NoZWQtaWYuaD4KIAogdW5zaWduZWQgaW50IF9fcmVhZF9tb3N0bHkgbnJfY3B1X2lk
cyA9IE5SX0NQVVM7CiAjaWZuZGVmIG5yX2NwdW1hc2tfYml0cwpAQCAtMjEyLDYgKzIxMyw4IEBA
IHZvaWQgZW5hYmxlX25vbmJvb3RfY3B1cyh2b2lkKQogICAgICAgICAgICAgQlVHX09OKGVycm9y
ID09IC1FQlVTWSk7CiAgICAgICAgICAgICBwcmludGsoIkVycm9yIHRha2luZyBDUFUlZCB1cDog
JWRcbiIsIGNwdSwgZXJyb3IpOwogICAgICAgICB9CisgICAgICAgIGlmIChzeXN0ZW1fc3RhdGUg
PT0gU1lTX1NUQVRFX3Jlc3VtZSkKKyAgICAgICAgICAgIGNwdW1hc2tfc2V0X2NwdShjcHUsIGNw
dXBvb2wwLT5jcHVfdmFsaWQpOwogICAgIH0KIAogICAgIGNwdW1hc2tfY2xlYXIoJmZyb3plbl9j
cHVzKTsKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWR1bGUuYyBiL3hlbi9jb21tb24vc2No
ZWR1bGUuYwppbmRleCBlZWU3NGJlLi5lZWZjYTFjIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3Nj
aGVkdWxlLmMKKysrIGIveGVuL2NvbW1vbi9zY2hlZHVsZS5jCkBAIC01NDMsNyArNTQzLDcgQEAg
aW50IGNwdV9kaXNhYmxlX3NjaGVkdWxlcih1bnNpZ25lZCBpbnQgY3B1KQogICAgIGludCAgICBy
ZXQgPSAwOwogCiAgICAgYyA9IHBlcl9jcHUoY3B1cG9vbCwgY3B1KTsKLSAgICBpZiAoIChjID09
IE5VTEwpIHx8IChzeXN0ZW1fc3RhdGUgPT0gU1lTX1NUQVRFX3N1c3BlbmQpICkKKyAgICBpZiAo
IGMgPT0gTlVMTCApCiAgICAgICAgIHJldHVybiByZXQ7CiAKICAgICBmb3JfZWFjaF9kb21haW5f
aW5fY3B1cG9vbCAoIGQsIGMgKQpAQCAtNTU0LDcgKzU1NCw4IEBAIGludCBjcHVfZGlzYWJsZV9z
Y2hlZHVsZXIodW5zaWduZWQgaW50IGNwdSkKIAogICAgICAgICAgICAgY3B1bWFza19hbmQoJm9u
bGluZV9hZmZpbml0eSwgdi0+Y3B1X2FmZmluaXR5LCBjLT5jcHVfdmFsaWQpOwogICAgICAgICAg
ICAgaWYgKCBjcHVtYXNrX2VtcHR5KCZvbmxpbmVfYWZmaW5pdHkpICYmCi0gICAgICAgICAgICAg
ICAgIGNwdW1hc2tfdGVzdF9jcHUoY3B1LCB2LT5jcHVfYWZmaW5pdHkpICkKKyAgICAgICAgICAg
ICAgICAgY3B1bWFza190ZXN0X2NwdShjcHUsIHYtPmNwdV9hZmZpbml0eSkgJiYKKyAgICAgICAg
ICAgICAgICAgc3lzdGVtX3N0YXRlICE9IFNZU19TVEFURV9zdXNwZW5kICkKICAgICAgICAgICAg
IHsKICAgICAgICAgICAgICAgICBwcmludGsoIkJyZWFraW5nIHZjcHUgYWZmaW5pdHkgZm9yIGRv
bWFpbiAlZCB2Y3B1ICVkXG4iLAogICAgICAgICAgICAgICAgICAgICAgICAgdi0+ZG9tYWluLT5k
b21haW5faWQsIHYtPnZjcHVfaWQpOwo=
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; name="s3-timerirq.txt"
Content-Disposition: attachment; filename="s3-timerirq.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwook93

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IDllMWY5ODkuLjE1NDk0YmMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMzAsNiAr
MzAsNyBAQAogI2luY2x1ZGUgPGFzbS9hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4K
ICNpbmNsdWRlIDxhY3BpL2NwdWZyZXEvY3B1ZnJlcS5oPgorI2luY2x1ZGUgPHhlbi9zb2Z0aXJx
Lmg+CiAKIHVpbnQzMl90IHN5c3RlbV9yZXNldF9jb3VudGVyID0gMTsKIApAQCAtMjIwLDYgKzIy
MSw3IEBAIHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGVuYWJsZV9ub25i
b290X2NwdXMoKTsKICAgICBtdHJyX2Fwc19zeW5jX2VuZCgpOwogICAgIGFjcGlfZG1hcl96YXAo
KTsKKyAgICByYWlzZV9zb2Z0aXJxKFRJTUVSX1NPRlRJUlEpOwogICAgIHRoYXdfZG9tYWlucygp
OwogICAgIHN5c3RlbV9zdGF0ZSA9IFNZU19TVEFURV9hY3RpdmU7CiAgICAgc3Bpbl91bmxvY2so
JnBtX2xvY2spOwo=
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--20cf301d43b0daadac04d4db94fb--


From xen-devel-bounces@lists.xen.org Mon Feb 04 00:58:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 00:58: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 1U2ANc-0004xc-Ld; Mon, 04 Feb 2013 00:57:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1U2ANb-0004xX-BZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 00:57:51 +0000
Received: from [193.109.254.147:23372] by server-9.bemta-14.messagelabs.com id
	46/B8-30867-E870F015; Mon, 04 Feb 2013 00:57:50 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1359939467!9080246!1
X-Originating-IP: [209.85.210.176]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18261 invoked from network); 4 Feb 2013 00:57:48 -0000
Received: from mail-ia0-f176.google.com (HELO mail-ia0-f176.google.com)
	(209.85.210.176)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 00:57:48 -0000
Received: by mail-ia0-f176.google.com with SMTP id i18so7469827iac.21
	for <xen-devel@lists.xen.org>; Sun, 03 Feb 2013 16:57:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=WYAwY+F9D9OWxzfhwOrxZwzt1oKn/TsxJHO6bSh54EU=;
	b=Z9qGdaSJgVPwZI8wLSYpBeanhdynhsFo0oPRIL71AG/SuYezBIRMeSSJeAGuLKs6OG
	NuM3Re0rO5YIneJPzS7bYBp+5X/tbDf8lHQXe0zbGGlrxOdPgpj1RwF/58lLolkMPJfa
	cB9Kz4FNJ5rIg02eNXZ8xxeKWoX3w8FqkOVes4dBVScjYOAAR4xeFLGq5CBlK4/4wIoY
	Qec36iEnSEf5ToNikHGLGL6sD1tIfvyL8T5PtSoT3uv1l0L/ghVKca9luG7tp90WM3Nm
	kdy74IDo5Wmp7rKIS5K+0lylGKtQy75qUc5q7xzXIkFWmo/IPlhgxcrkZQ5D6DdJfOUz
	ynlQ==
MIME-Version: 1.0
X-Received: by 10.42.212.8 with SMTP id gq8mr13681476icb.48.1359939467127;
	Sun, 03 Feb 2013 16:57:47 -0800 (PST)
Received: by 10.231.73.2 with HTTP; Sun, 3 Feb 2013 16:57:47 -0800 (PST)
In-Reply-To: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
Date: Sun, 3 Feb 2013 19:57:47 -0500
X-Google-Sender-Auth: _nBSbK5GenbKHcv9rSRjZ9fkzkU
Message-ID: <CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Milan opath <milan.opath@gmail.com>
Content-Type: multipart/mixed; boundary=20cf301d43b0daadac04d4db94fb
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure what Arch linux uses for a kernel, as I'm not terribly
familiar with the distro.

That said, a number of things are needed to get this to work, that are
not accepted upstream.

1. You'll need one of Konrad's acpi-s3 branches, or the patches from
the tip of those branches:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/acpi-s3.v9

2. Apply the attached patches in the following order:
fix-dmar-zap-reinstate
fix-suspend-scheduler-v2
fix-suspend-scheduler-revert-affinity-part
s3-timerirq

All of these fixes have been proposed to the xen-devel list, but have
not yet been accepted, for one reason, or another.

I've CC'ed Konrad, and Tomasz who authored some of the things
mentioned above, and Jan Beulich who has been commenting on the
validity / correctness of these changes.


Ben

On Sat, Feb 2, 2013 at 6:39 AM, Milan opath <milan.opath@gmail.com> wrote:
> Hello,
>
> I cannot resume from S3 sleep in Dom0. I'm running on Xen 4.2.1 with Dom0
> 3.6.11-1-ARCH linux. The laptop is lenovo T400 with Intel Core2 Duo
> processor.
>
> I've found in one of the previous threads that the problem might be caused
> by lacking the acpi-cpufreq module in Dom0. However, when I try to load it,
> I get 'no such device' error. This error is present on both, Domain0 based
> cpufreq as well as Hypervisor based cpufreq power management.
>
> I suspect this is a Xen related issue.
> Thank you,
> Milan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; name="fix-dmar-zap-reinstate.txt"
Content-Disposition: attachment; filename="fix-dmar-zap-reinstate.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwoojl0

ZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2FjcGkvdGFibGVzL3RieGZhY2UuYyBiL3hlbi9kcml2
ZXJzL2FjcGkvdGFibGVzL3RieGZhY2UuYwppbmRleCBkZjZlZWJhLi4xNjAyYmIyIDEwMDY0NAot
LS0gYS94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy90YnhmYWNlLmMKKysrIGIveGVuL2RyaXZlcnMv
YWNwaS90YWJsZXMvdGJ4ZmFjZS5jCkBAIC0yMDUsMyArMjA1LDUxIEBAIGFjcGlfZ2V0X3RhYmxl
KGNoYXIgKnNpZ25hdHVyZSwKIAogCXJldHVybiAoQUVfTk9UX0ZPVU5EKTsKIH0KKworLyoqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgorICoKKyAqIEZVTkNUSU9OOiAgICBhY3BpX2dldF90YWJsZV9waHlz
CisgKgorICogUEFSQU1FVEVSUzogIHNpZ25hdHVyZSAgICAgIC0gQUNQSSBzaWduYXR1cmUgb2Yg
bmVlZGVkIHRhYmxlCisgKiAgICAgICAgICAgICAgaW5zdGFuY2UgICAgICAgLSBXaGljaCBpbnN0
YW5jZSAoZm9yIFNTRFRzKQorICogICAgICAgICAgICAgIGFkZHIgICAgICAgICAgIC0gV2hlcmUg
dGhlIHRhYmxlJ3MgcGh5c2ljYWwgYWRkcmVzcyBpcyByZXR1cm5lZAorICogICAgICAgICAgICAg
IGxlbiAgICAgICAgICAgIC0gV2hlcmUgdGhlIGxlbmd0aCBvZiB0YWJsZSBpcyByZXR1cm5lZAor
ICoKKyAqIFJFVFVSTjogICAgICBTdGF0dXMsIHBvaW50ZXIgYW5kIGxlbmd0aCBvZiB0YWJsZQor
ICoKKyAqIERFU0NSSVBUSU9OOiBGaW5kcyBwaHlzaWNhbCBhZGRyZXNzIGFuZCBsZW5ndGggb2Yg
QUNQSSB0YWJsZQorICoKKyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KK2FjcGlfc3RhdHVzIF9faW5p
dAorYWNwaV9nZXRfdGFibGVfcGh5cyhhY3BpX3N0cmluZyBzaWduYXR1cmUsIGFjcGlfbmF0aXZl
X3VpbnQgaW5zdGFuY2UsCisJCSAgICAgYWNwaV9waHlzaWNhbF9hZGRyZXNzICphZGRyLCBhY3Bp
X25hdGl2ZV91aW50ICpsZW4pCit7CisJYWNwaV9uYXRpdmVfdWludCBpLCBqOworCWFjcGlfc3Rh
dHVzIHN0YXR1czsKKworCWlmICghc2lnbmF0dXJlIHx8ICFhZGRyIHx8ICFsZW4pCisJCXJldHVy
biBBRV9CQURfUEFSQU1FVEVSOworCisJZm9yIChpID0gaiA9IDA7IGkgPCBhY3BpX2dibF9yb290
X3RhYmxlX2xpc3QuY291bnQ7IGkrKykgeworCQlpZiAoIUFDUElfQ09NUEFSRV9OQU1FKAorCQkJ
CSZhY3BpX2dibF9yb290X3RhYmxlX2xpc3QudGFibGVzW2ldLnNpZ25hdHVyZSwKKwkJCQlzaWdu
YXR1cmUpKQorCQkJY29udGludWU7CisKKwkJaWYgKCsraiA8IGluc3RhbmNlKQorCQkJY29udGlu
dWU7CisKKwkJc3RhdHVzID0KKwkJICAgIGFjcGlfdGJfdmVyaWZ5X3RhYmxlKCZhY3BpX2dibF9y
b290X3RhYmxlX2xpc3QudGFibGVzW2ldKTsKKwkJaWYgKEFDUElfU1VDQ0VTUyhzdGF0dXMpKSB7
CisJCQkqYWRkciA9IGFjcGlfZ2JsX3Jvb3RfdGFibGVfbGlzdC50YWJsZXNbaV0uYWRkcmVzczsK
KwkJCSpsZW4gPSBhY3BpX2dibF9yb290X3RhYmxlX2xpc3QudGFibGVzW2ldLmxlbmd0aDsKKwkJ
fQorCisJCWFjcGlfZ2JsX3Jvb3RfdGFibGVfbGlzdC50YWJsZXNbaV0ucG9pbnRlciA9IE5VTEw7
CisKKwkJcmV0dXJuIHN0YXR1czsKKwl9CisKKwlyZXR1cm4gQUVfTk9UX0ZPVU5EOworfQpkaWZm
IC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkL2RtYXIuYyBiL3hlbi9kcml2ZXJz
L3Bhc3N0aHJvdWdoL3Z0ZC9kbWFyLmMKaW5kZXggM2ZiYzVlNi4uNzNhZDFkNyAxMDA2NDQKLS0t
IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvdnRkL2RtYXIuYworKysgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC92dGQvZG1hci5jCkBAIC03ODYsNyArNzg2LDE4IEBAIG91dDoKIAogaW50IF9f
aW5pdCBhY3BpX2RtYXJfaW5pdCh2b2lkKQogewotICAgIGFjcGlfZ2V0X3RhYmxlKEFDUElfU0lH
X0RNQVIsIDAsICZkbWFyX3RhYmxlKTsKKyAgICBhY3BpX3BoeXNpY2FsX2FkZHJlc3MgZG1hcl9h
ZGRyOworICAgIGFjcGlfbmF0aXZlX3VpbnQgZG1hcl9sZW47CisKKyAgICBpZiAoIEFDUElfU1VD
Q0VTUyhhY3BpX2dldF90YWJsZV9waHlzKEFDUElfU0lHX0RNQVIsIDAsCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZG1hcl9hZGRyLCAmZG1hcl9sZW4pKSApCisg
ICAgeworICAgICAgICBtYXBfcGFnZXNfdG9feGVuKCh1bnNpZ25lZCBsb25nKV9fdmEoZG1hcl9h
ZGRyKSwgUEZOX0RPV04oZG1hcl9hZGRyKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICBQRk5f
VVAoZG1hcl9hZGRyICsgZG1hcl9sZW4pIC0gUEZOX0RPV04oZG1hcl9hZGRyKSwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICBQQUdFX0hZUEVSVklTT1IpOworICAgICAgICBkbWFyX3RhYmxlID0g
X192YShkbWFyX2FkZHIpOworICAgIH0KKwogICAgIHJldHVybiBwYXJzZV9kbWFyX3RhYmxlKGFj
cGlfcGFyc2VfZG1hcik7CiB9CiAKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FjcGkvYWNwaXhm
LmggYi94ZW4vaW5jbHVkZS9hY3BpL2FjcGl4Zi5oCmluZGV4IGNkMmI0ZmIuLjdhZTFmMDcgMTAw
NjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FjcGkvYWNwaXhmLmgKKysrIGIveGVuL2luY2x1ZGUvYWNw
aS9hY3BpeGYuaApAQCAtNzcsNiArNzcsOSBAQCBhY3BpX3N0YXR1cwogYWNwaV9nZXRfdGFibGUo
YWNwaV9zdHJpbmcgc2lnbmF0dXJlLAogCSAgICAgICBhY3BpX25hdGl2ZV91aW50IGluc3RhbmNl
LCBzdHJ1Y3QgYWNwaV90YWJsZV9oZWFkZXIgKipvdXRfdGFibGUpOwogCithY3BpX3N0YXR1cwor
YWNwaV9nZXRfdGFibGVfcGh5cyhhY3BpX3N0cmluZyBzaWduYXR1cmUsIGFjcGlfbmF0aXZlX3Vp
bnQgaW5zdGFuY2UsCisJCSAgICAgYWNwaV9waHlzaWNhbF9hZGRyZXNzICphZGRyLCBhY3BpX25h
dGl2ZV91aW50ICpsZW4pOwogLyoKICAqIE5hbWVzcGFjZSBhbmQgbmFtZSBpbnRlcmZhY2VzCiAg
Ki8K
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; 
	name="fix-suspend-scheduler-revert-affinity-part.txt"
Content-Disposition: attachment; 
	filename="fix-suspend-scheduler-revert-affinity-part.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwook51

ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWR1bGUuYyBiL3hlbi9jb21tb24vc2NoZWR1bGUu
YwppbmRleCBlZWZjYTFjLi5mZmNhZmNkIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3NjaGVkdWxl
LmMKKysrIGIveGVuL2NvbW1vbi9zY2hlZHVsZS5jCkBAIC01NTQsOCArNTU0LDcgQEAgaW50IGNw
dV9kaXNhYmxlX3NjaGVkdWxlcih1bnNpZ25lZCBpbnQgY3B1KQogCiAgICAgICAgICAgICBjcHVt
YXNrX2FuZCgmb25saW5lX2FmZmluaXR5LCB2LT5jcHVfYWZmaW5pdHksIGMtPmNwdV92YWxpZCk7
CiAgICAgICAgICAgICBpZiAoIGNwdW1hc2tfZW1wdHkoJm9ubGluZV9hZmZpbml0eSkgJiYKLSAg
ICAgICAgICAgICAgICAgY3B1bWFza190ZXN0X2NwdShjcHUsIHYtPmNwdV9hZmZpbml0eSkgJiYK
LSAgICAgICAgICAgICAgICAgc3lzdGVtX3N0YXRlICE9IFNZU19TVEFURV9zdXNwZW5kICkKKyAg
ICAgICAgICAgICAgICAgY3B1bWFza190ZXN0X2NwdShjcHUsIHYtPmNwdV9hZmZpbml0eSkgKQog
ICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIHByaW50aygiQnJlYWtpbmcgdmNwdSBhZmZp
bml0eSBmb3IgZG9tYWluICVkIHZjcHUgJWRcbiIsCiAgICAgICAgICAgICAgICAgICAgICAgICB2
LT5kb21haW4tPmRvbWFpbl9pZCwgdi0+dmNwdV9pZCk7Cg==
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; name="fix-suspend-scheduler-v2.txt"
Content-Disposition: attachment; filename="fix-suspend-scheduler-v2.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwook72

ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vY3B1LmMgYi94ZW4vY29tbW9uL2NwdS5jCmluZGV4IDYz
MDg4MWUuLmUyMDg2OGMgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vY3B1LmMKKysrIGIveGVuL2Nv
bW1vbi9jcHUuYwpAQCAtNSw2ICs1LDcgQEAKICNpbmNsdWRlIDx4ZW4vaW5pdC5oPgogI2luY2x1
ZGUgPHhlbi9zY2hlZC5oPgogI2luY2x1ZGUgPHhlbi9zdG9wX21hY2hpbmUuaD4KKyNpbmNsdWRl
IDx4ZW4vc2NoZWQtaWYuaD4KIAogdW5zaWduZWQgaW50IF9fcmVhZF9tb3N0bHkgbnJfY3B1X2lk
cyA9IE5SX0NQVVM7CiAjaWZuZGVmIG5yX2NwdW1hc2tfYml0cwpAQCAtMjEyLDYgKzIxMyw4IEBA
IHZvaWQgZW5hYmxlX25vbmJvb3RfY3B1cyh2b2lkKQogICAgICAgICAgICAgQlVHX09OKGVycm9y
ID09IC1FQlVTWSk7CiAgICAgICAgICAgICBwcmludGsoIkVycm9yIHRha2luZyBDUFUlZCB1cDog
JWRcbiIsIGNwdSwgZXJyb3IpOwogICAgICAgICB9CisgICAgICAgIGlmIChzeXN0ZW1fc3RhdGUg
PT0gU1lTX1NUQVRFX3Jlc3VtZSkKKyAgICAgICAgICAgIGNwdW1hc2tfc2V0X2NwdShjcHUsIGNw
dXBvb2wwLT5jcHVfdmFsaWQpOwogICAgIH0KIAogICAgIGNwdW1hc2tfY2xlYXIoJmZyb3plbl9j
cHVzKTsKZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWR1bGUuYyBiL3hlbi9jb21tb24vc2No
ZWR1bGUuYwppbmRleCBlZWU3NGJlLi5lZWZjYTFjIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL3Nj
aGVkdWxlLmMKKysrIGIveGVuL2NvbW1vbi9zY2hlZHVsZS5jCkBAIC01NDMsNyArNTQzLDcgQEAg
aW50IGNwdV9kaXNhYmxlX3NjaGVkdWxlcih1bnNpZ25lZCBpbnQgY3B1KQogICAgIGludCAgICBy
ZXQgPSAwOwogCiAgICAgYyA9IHBlcl9jcHUoY3B1cG9vbCwgY3B1KTsKLSAgICBpZiAoIChjID09
IE5VTEwpIHx8IChzeXN0ZW1fc3RhdGUgPT0gU1lTX1NUQVRFX3N1c3BlbmQpICkKKyAgICBpZiAo
IGMgPT0gTlVMTCApCiAgICAgICAgIHJldHVybiByZXQ7CiAKICAgICBmb3JfZWFjaF9kb21haW5f
aW5fY3B1cG9vbCAoIGQsIGMgKQpAQCAtNTU0LDcgKzU1NCw4IEBAIGludCBjcHVfZGlzYWJsZV9z
Y2hlZHVsZXIodW5zaWduZWQgaW50IGNwdSkKIAogICAgICAgICAgICAgY3B1bWFza19hbmQoJm9u
bGluZV9hZmZpbml0eSwgdi0+Y3B1X2FmZmluaXR5LCBjLT5jcHVfdmFsaWQpOwogICAgICAgICAg
ICAgaWYgKCBjcHVtYXNrX2VtcHR5KCZvbmxpbmVfYWZmaW5pdHkpICYmCi0gICAgICAgICAgICAg
ICAgIGNwdW1hc2tfdGVzdF9jcHUoY3B1LCB2LT5jcHVfYWZmaW5pdHkpICkKKyAgICAgICAgICAg
ICAgICAgY3B1bWFza190ZXN0X2NwdShjcHUsIHYtPmNwdV9hZmZpbml0eSkgJiYKKyAgICAgICAg
ICAgICAgICAgc3lzdGVtX3N0YXRlICE9IFNZU19TVEFURV9zdXNwZW5kICkKICAgICAgICAgICAg
IHsKICAgICAgICAgICAgICAgICBwcmludGsoIkJyZWFraW5nIHZjcHUgYWZmaW5pdHkgZm9yIGRv
bWFpbiAlZCB2Y3B1ICVkXG4iLAogICAgICAgICAgICAgICAgICAgICAgICAgdi0+ZG9tYWluLT5k
b21haW5faWQsIHYtPnZjcHVfaWQpOwo=
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset=US-ASCII; name="s3-timerirq.txt"
Content-Disposition: attachment; filename="s3-timerirq.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hcqwook93

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IDllMWY5ODkuLjE1NDk0YmMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMzAsNiAr
MzAsNyBAQAogI2luY2x1ZGUgPGFzbS9hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4K
ICNpbmNsdWRlIDxhY3BpL2NwdWZyZXEvY3B1ZnJlcS5oPgorI2luY2x1ZGUgPHhlbi9zb2Z0aXJx
Lmg+CiAKIHVpbnQzMl90IHN5c3RlbV9yZXNldF9jb3VudGVyID0gMTsKIApAQCAtMjIwLDYgKzIy
MSw3IEBAIHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGVuYWJsZV9ub25i
b290X2NwdXMoKTsKICAgICBtdHJyX2Fwc19zeW5jX2VuZCgpOwogICAgIGFjcGlfZG1hcl96YXAo
KTsKKyAgICByYWlzZV9zb2Z0aXJxKFRJTUVSX1NPRlRJUlEpOwogICAgIHRoYXdfZG9tYWlucygp
OwogICAgIHN5c3RlbV9zdGF0ZSA9IFNZU19TVEFURV9hY3RpdmU7CiAgICAgc3Bpbl91bmxvY2so
JnBtX2xvY2spOwo=
--20cf301d43b0daadac04d4db94fb
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--20cf301d43b0daadac04d4db94fb--


From xen-devel-bounces@lists.xen.org Mon Feb 04 01:49:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 01:49: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 1U2BAv-0000cq-P4; Mon, 04 Feb 2013 01:48: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 1U2BAt-0000cl-LC
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 01:48:47 +0000
Received: from [85.158.143.35:56353] by server-3.bemta-4.messagelabs.com id
	76/27-08920-F731F015; Mon, 04 Feb 2013 01:48:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1359942524!5249959!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTgx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9655 invoked from network); 4 Feb 2013 01:48:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 01:48:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,596,1355097600"; 
   d="scan'208";a="1103994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 01:48: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.297.1; Mon, 4 Feb 2013 01:48:44 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2BAq-0004jl-4c;
	Mon, 04 Feb 2013 01:48:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2BAp-000794-Qm;
	Mon, 04 Feb 2013 01:48:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15415-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 01:48:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15415: 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 15415 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15415/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 15414
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 15414

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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 15414 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 15414 never pass

version targeted for testing:
 xen                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 01:49:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 01:49: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 1U2BAv-0000cq-P4; Mon, 04 Feb 2013 01:48: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 1U2BAt-0000cl-LC
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 01:48:47 +0000
Received: from [85.158.143.35:56353] by server-3.bemta-4.messagelabs.com id
	76/27-08920-F731F015; Mon, 04 Feb 2013 01:48:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1359942524!5249959!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTgx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9655 invoked from network); 4 Feb 2013 01:48:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 01:48:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,596,1355097600"; 
   d="scan'208";a="1103994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 01:48: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.297.1; Mon, 4 Feb 2013 01:48:44 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2BAq-0004jl-4c;
	Mon, 04 Feb 2013 01:48:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2BAp-000794-Qm;
	Mon, 04 Feb 2013 01:48:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15415-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 01:48:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15415: 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 15415 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15415/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 15414
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 15414

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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 15414 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 15414 never pass

version targeted for testing:
 xen                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 01:54:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 01:54: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 1U2BGS-0000nX-OQ; Mon, 04 Feb 2013 01:54:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U2BGR-0000nQ-41
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 01:54:31 +0000
Received: from [193.109.254.147:52307] by server-2.bemta-14.messagelabs.com id
	4A/AA-16277-6D41F015; Mon, 04 Feb 2013 01:54:30 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1359942868!9015271!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjAyNzMx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31838 invoked from network); 4 Feb 2013 01:54:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 01:54:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r141sPjt012174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 4 Feb 2013 01:54:26 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
	r141sPEh009338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 4 Feb 2013 01:54:25 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
	r141sOtt023751; Sun, 3 Feb 2013 19:54:24 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 03 Feb 2013 17:54:24 -0800
Message-ID: <510F14CF.6050801@oracle.com>
Date: Mon, 04 Feb 2013 09:54:23 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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

Current Xend allowing multiple call destroy() for same domain, this lead
multiple hard resets(FLR) for pci pass-through, and some controller might
failed.

In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, after
guest brought up, call xm-destroy twice, the adapters's BIOS will hung, and
we had to reboot the server to recovery it.

Signed-off-by: Joe Jin <joe.jin@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/python/xen/xend/XendDomainInfo.py | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/python/xen/xend/XendDomainInfo.py b/tools/python/xen/xend/XendDomainInfo.py
index e9d3e7e..658c3b6 100644
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -367,6 +367,8 @@ class XendDomainInfo:
     @type refresh_shutdown_lock: threading.Condition
     @ivar _deviceControllers: device controller cache for this domain
     @type _deviceControllers: dict 'string' to DevControllers
+    @ivar destroying: Is this domain destroying
+    @type destroying: bool
     """
     
     def __init__(self, info, domid = None, dompath = None, augment = False,
@@ -455,6 +457,8 @@ class XendDomainInfo:
         self._checkName(self.info['name_label'])
 
         self.metrics = XendVMMetrics(uuid.createString(), self)
+
+        self.destroying = False
             
 
     #
@@ -3073,6 +3077,12 @@ class XendDomainInfo:
 
         if self.domid is None:
             return
+
+        if self.destroying == False:
+            self.destroying = True
+        else:
+            raise VmError("Domain (domid=%s) is destroying, please wait!", str(self.domid))
+
         from xen.xend import XendDomain
         log.debug("XendDomainInfo.destroy: domid=%s", str(self.domid))
 
@@ -3088,6 +3098,7 @@ class XendDomainInfo:
                     self.info[state] = 0
                 self._stateSet(DOM_STATE_HALTED)
             except:
+                self.destroying = False
                 log.exception("XendDomainInfo.destroy: domain destruction failed.")
 
             XendDomain.instance().remove_domain(self)
-- 
1.8.1


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 01:54:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 01:54: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 1U2BGS-0000nX-OQ; Mon, 04 Feb 2013 01:54:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U2BGR-0000nQ-41
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 01:54:31 +0000
Received: from [193.109.254.147:52307] by server-2.bemta-14.messagelabs.com id
	4A/AA-16277-6D41F015; Mon, 04 Feb 2013 01:54:30 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1359942868!9015271!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjAyNzMx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31838 invoked from network); 4 Feb 2013 01:54:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 01:54:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r141sPjt012174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 4 Feb 2013 01:54:26 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
	r141sPEh009338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 4 Feb 2013 01:54:25 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
	r141sOtt023751; Sun, 3 Feb 2013 19:54:24 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 03 Feb 2013 17:54:24 -0800
Message-ID: <510F14CF.6050801@oracle.com>
Date: Mon, 04 Feb 2013 09:54:23 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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

Current Xend allowing multiple call destroy() for same domain, this lead
multiple hard resets(FLR) for pci pass-through, and some controller might
failed.

In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, after
guest brought up, call xm-destroy twice, the adapters's BIOS will hung, and
we had to reboot the server to recovery it.

Signed-off-by: Joe Jin <joe.jin@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/python/xen/xend/XendDomainInfo.py | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/python/xen/xend/XendDomainInfo.py b/tools/python/xen/xend/XendDomainInfo.py
index e9d3e7e..658c3b6 100644
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -367,6 +367,8 @@ class XendDomainInfo:
     @type refresh_shutdown_lock: threading.Condition
     @ivar _deviceControllers: device controller cache for this domain
     @type _deviceControllers: dict 'string' to DevControllers
+    @ivar destroying: Is this domain destroying
+    @type destroying: bool
     """
     
     def __init__(self, info, domid = None, dompath = None, augment = False,
@@ -455,6 +457,8 @@ class XendDomainInfo:
         self._checkName(self.info['name_label'])
 
         self.metrics = XendVMMetrics(uuid.createString(), self)
+
+        self.destroying = False
             
 
     #
@@ -3073,6 +3077,12 @@ class XendDomainInfo:
 
         if self.domid is None:
             return
+
+        if self.destroying == False:
+            self.destroying = True
+        else:
+            raise VmError("Domain (domid=%s) is destroying, please wait!", str(self.domid))
+
         from xen.xend import XendDomain
         log.debug("XendDomainInfo.destroy: domid=%s", str(self.domid))
 
@@ -3088,6 +3098,7 @@ class XendDomainInfo:
                     self.info[state] = 0
                 self._stateSet(DOM_STATE_HALTED)
             except:
+                self.destroying = False
                 log.exception("XendDomainInfo.destroy: domain destruction failed.")
 
             XendDomain.instance().remove_domain(self)
-- 
1.8.1


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 07:20:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 07:20: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 1U2GKt-0004Kj-Fu; Mon, 04 Feb 2013 07:19:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U2GKr-0004Ke-NE
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 07:19:26 +0000
Received: from [85.158.143.35:33898] by server-2.bemta-4.messagelabs.com id
	BF/0F-01597-DF06F015; Mon, 04 Feb 2013 07:19:25 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1359962360!12886833!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTE5NTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17266 invoked from network); 4 Feb 2013 07:19:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 07:19:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r147JHtx010526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Mon, 4 Feb 2013 07:19:18 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
	r147JGcf025737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Mon, 4 Feb 2013 07:19:16 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
	r147JGgd016480
	for <xen-devel@lists.xen.org>; Mon, 4 Feb 2013 01:19:16 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 03 Feb 2013 23:19:15 -0800
Message-ID: <510F60F2.4070706@oracle.com>
Date: Mon, 04 Feb 2013 15:19:14 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <50F6A619.7030606@oracle.com>
In-Reply-To: <50F6A619.7030606@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] rombios unable to loaded MPT BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 debugged PMM I found it caused MPT(LSI controller) BIOS, MPT BIOS
overwrote pmm header and lead PMM unable to allocate memory.

Thanks,
Joe

On 01/16/13 21:07, Joe Jin wrote:
> Hi All,
> 
> When tried to pass through 2 mpt2sas HBA to hvm guest, hvmloader
> paused with below:
> 
> MPT BIOS Fault 09h encountered at adapter PCI(00h,04h,00h)
> Press any key to continue...
> 
> Checked related codes and mostly like it caused by rombios did not
> loaded MPT BIOS properly, and lead MPT BIOS failed to bootup.
> 
> config-file of the guest as below:
> ----------------------------------
> # cat vm.cfg
> kernel = '/usr/lib/xen/boot/hvmloader'
> builder = 'hvm'
> device_model = '/usr/lib64/xen/bin/qemu-dm'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> apic=1
> acpi=1
> pae=1
> serial='pty'
> vif = ['type=netfront,bridge=priv1','type=netfront,bridge=net1','type=netfront,bridge=net2']
> #memory = '32768'
> memory = '4096'
> name = 'pci-passthrough-dom1'
> on_crash = 'destroy'
> on_reboot = 'restart'
> timer_mode = 0
> vcpus=8
> pci=['0d:00.0','1f:00.0']
> disk = ['file:/OVS/Repositories/oakDom1/System.img,xvda,w','file:/OVS/Repositories/oakDom1/u01.img,xvdb,w','file:/OVS/Repositories/oakDom1/swap.img,xvdc,w']
> 
> Device pci info:
> ----------------
> # lspci -nvv -s 0f:00.0
> 0d:00.0 0107: 1000:0072 (rev 03)
>     Subsystem: 1000:3050
>     Physical Slot: 3
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0, Cache Line Size: 256 bytes
>     Interrupt: pin A routed to IRQ 24
>     Region 0: I/O ports at 9000 [size=256]
>     Region 1: Memory at df03c000 (64-bit, non-prefetchable) [size=16K]
>     Region 3: Memory at df040000 (64-bit, non-prefetchable) [size=256K]
>     Expansion ROM at df080000 [disabled] [size=512K]
>     Capabilities: [50] Power Management version 3
>         Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] Express (v2) Endpoint, MSI 00
>         DevCap:    MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #0, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <64ns, L1 <1us
>             ClockPM- Surprise- LLActRep- BwNot-
>         LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Range BC, TimeoutDis+
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance-ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB
>     Capabilities: [d0] Vital Product Data
>         Product Name: SGX-SAS6-INT-Z, Sun StorageTek 6Gb/s SAS PCIe HBA, Internal
>         Read-only fields:
>             [PN] Part number: 375-3640-02
>             [EC] Engineering changes: 01
>             [MN] Manufacture ID: 53 75 6e 20 4d 69 63 72 6f 73 79 73 74 65 6d 73 2c 20 49 6e 63 2e
>             [SN] Serial number: SP14344072
>             [RV] Reserved: checksum good, 0 byte(s) reserved
>         End
>     Capabilities: [a8] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Address: 00000000fee00738  Data: 0000
>     Capabilities: [c0] MSI-X: Enable- Count=15 Masked-
>         Vector table: BAR=1 offset=00002000
>         PBA: BAR=1 offset=00003800
>     Capabilities: [100 v1] Advanced Error Reporting
>         UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UESvrt:    DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>         CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         AERCap:    First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>     Capabilities: [138 v1] Power Budgeting <?>
>     Kernel driver in use: pciback
>     Kernel modules: mpt2sas
> 
> # lspci -nvv -s 1f:00.0
> 1f:00.0 0107: 1000:0072 (rev 03)
>     Subsystem: 1000:3050
>     Physical Slot: 4
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0, Cache Line Size: 256 bytes
>     Interrupt: pin A routed to IRQ 32
>     Region 0: I/O ports at d000 [size=256]
>     Region 1: Memory at df63c000 (64-bit, non-prefetchable) [size=16K]
>     Region 3: Memory at df640000 (64-bit, non-prefetchable) [size=256K]
>     Expansion ROM at df680000 [disabled] [size=512K]
>     Capabilities: [50] Power Management version 3
>         Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] Express (v2) Endpoint, MSI 00
>         DevCap:    MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported- 
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #0, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <64ns, L1 <1us
>             ClockPM- Surprise- LLActRep- BwNot-
>         LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Range BC, TimeoutDis+
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance-ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB
>     Capabilities: [d0] Vital Product Data
>         Product Name: SGX-SAS6-INT-Z, Sun StorageTek 6Gb/s SAS PCIe HBA, Internal
>         Read-only fields:
>             [PN] Part number: 375-3640-02
>             [EC] Engineering changes: 01
>             [MN] Manufacture ID: 53 75 6e 20 4d 69 63 72 6f 73 79 73 74 65 6d 73 2c 20 49 6e 63 2e
>             [SN] Serial number: SP14035588
>             [RV] Reserved: checksum good, 0 byte(s) reserved
>         End
>     Capabilities: [a8] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Address: 00000000fee00758  Data: 0000
>     Capabilities: [c0] MSI-X: Enable- Count=15 Masked-
>         Vector table: BAR=1 offset=00002000
>         PBA: BAR=1 offset=00003800
>     Capabilities: [100 v1] Advanced Error Reporting
>         UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UESvrt:    DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>         CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         AERCap:    First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>     Capabilities: [138 v1] Power Budgeting <?>
>     Kernel driver in use: pciback
>     Kernel modules: mpt2sas
> 
> 
> 
> Debug info when xm-create the guest:
> -------------------------------------
> (XEN) HVM4: HVM Loader
> (XEN) HVM4: Detected Xen v4.1.2-OVM
> (XEN) HVM4: CPU speed is 3060 MHz
> (XEN) HVM4: Xenbus rings @0xfeffc000, event channel 9
> (XEN) irq.c:264: Dom4 PCI link 0 changed 0 -> 5
> (XEN) HVM4: PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:264: Dom4 PCI link 1 changed 0 -> 10
> (XEN) HVM4: PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:264: Dom4 PCI link 2 changed 0 -> 11
> (XEN) HVM4: PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:264: Dom4 PCI link 3 changed 0 -> 5
> (XEN) HVM4: PCI-ISA link 3 routed to IRQ5
> (XEN) HVM4: pci dev 01:3 INTA->IRQ10
> (XEN) HVM4: pci dev 03:0 INTA->IRQ5
> (XEN) HVM4: pci dev 04:0 INTA->IRQ5
> (XEN) HVM4: pci dev 05:0 INTA->IRQ10
> (XEN) HVM4: pci dev 02:0 bar 10 size 02000000: f0000008
> (XEN) HVM4: pci dev 03:0 bar 14 size 01000000: f2000008
> (XEN) HVM4: pci dev 04:0 bar 30 size 00080000: f3000000
> (XEN) HVM4: pci dev 05:0 bar 30 size 00080000: f3080000
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40
> (XEN) HVM4: pci dev 04:0 bar 1c size 00040000: f3100004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40
> (XEN) HVM4: pci dev 05:0 bar 1c size 00040000: f3140004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3182 mfn=df03e nr_mfns=1
> (XEN) HVM4: pci dev 04:0 bar 14 size 00004000: f3180004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3184 mfn=df63c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3186 mfn=df63e nr_mfns=1
> (XEN) HVM4: pci dev 05:0 bar 14 size 00004000: f3184004
> (XEN) HVM4: pci dev 02:0 bar 14 size 00001000: f3188000
> (XEN) HVM4: pci dev 03:0 bar 10 size 00000100: 0000c001
> (XEN) HVM4: pci dev 04:0 bar 10 size 00000100: 0000c101
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) HVM4: pci dev 05:0 bar 10 size 00000100: 0000c201
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) HVM4: pci dev 01:1 bar 20 size 00000010: 0000c301
> (XEN) HVM4: Multiprocessor initialisation:
> (XEN) HVM4:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU6 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU7 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4: Writing SMBIOS tables ...
> (XEN) HVM4: Loading ROMBIOS ...
> (XEN) HVM4: 10332 bytes of ROMBIOS high-memory extensions:
> (XEN) HVM4:   Relocating to 0xfc000000-0xfc00285c ... done
> (XEN) HVM4: Creating MP tables ...
> (XEN) HVM4: Loading Cirrus VGABIOS ...
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3000 mfn=df080 nr_mfns=80
> (XEN) HVM4: Loading PCI Option ROM ...
> (XEN) HVM4:  - Manufacturer: LSI Corporation
> (XEN) HVM4:  - Product name: LSI MPI Boot Support
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3000 mfn=df080 nr_mfns=80
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) HVM4: Loading ACPI ...
> (XEN) HVM4:  - Lo data: 000ea020-000ea04f
> (XEN) HVM4:  - Hi data: fc002c00-fc00eb0f
> (XEN) HVM4: vm86 TSS at fc00ec00
> (XEN) HVM4: BIOS map:
> (XEN) HVM4:  c0000-c8fff: VGA BIOS
> (XEN) HVM4:  c9000-d4fff: PCI Option ROMs
> (XEN) HVM4:  eb000-eb263: SMBIOS tables
> (XEN) HVM4:  f0000-fffff: Main BIOS
> (XEN) HVM4: E820 table:
> (XEN) HVM4:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM4:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
> (XEN) HVM4:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
> (XEN) HVM4:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM4:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM4:  [04]: 00000000:00100000 - 00000000:f0000000: RAM
> (XEN) HVM4:  HOLE: 00000000:f0000000 - 00000000:fc000000
> (XEN) HVM4:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (XEN) HVM4:  [06]: 00000001:00000000 - 00000001:10000000: RAM
> (XEN) HVM4: Invoking ROMBIOS ...
> (XEN) HVM4: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) stdvga.c:147:d4 entering stdvga and caching modes
> (XEN) HVM4: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> (XEN) HVM4: Bochs BIOS - build: 06/23/99
> (XEN) HVM4: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) HVM4: Options: apmbios pcibios eltorito PMM 
> (XEN) HVM4: 
> (XEN) HVM4: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM4: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (60000 MBytes)
> (XEN) HVM4: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM4: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  97 GBytes)
> (XEN) HVM4: ata1-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM4: ata1 master: QEMU HARDDISK ATA-7 Hard-Disk (20000 MBytes)
> (XEN) HVM4: IDE time out
> (XEN) HVM4: 
> (XEN) HVM4: PCI device 1000:0070 not found at index 0
> (XEN) HVM4: PCI device 1000:0072 not found at index 2
> (XEN) HVM4: PCI device 1000:0074 not found at index 0
> (XEN) HVM4: PCI device 1000:0076 not found at index 0
> (XEN) HVM4: PCI device 1000:0077 not found at index 0
> (XEN) HVM4: PCI device 1000:0064 not found at index 0
> (XEN) HVM4: PCI device 1000:0065 not found at index 0
> (XEN) HVM4: PCI device 1000:0080 not found at index 0
> (XEN) HVM4: PCI device 1000:0081 not found at index 0
> (XEN) HVM4: PCI device 1000:0082 not found at index 0
> (XEN) HVM4: PCI device 1000:0083 not found at index 0
> (XEN) HVM4: PCI device 1000:0084 not found at index 0
> (XEN) HVM4: PCI device 1000:0085 not found at index 0
> (XEN) HVM4: PCI device 1000:0086 not found at index 0
> (XEN) HVM4: PCI device 1000:0087 not found at index 0
> (XEN) HVM4: 
> (XEN) HVM4: 
> (XEN) HVM4: Press F12 for boot menu.
> (XEN) HVM4: 
> (XEN) HVM4: Booting from Hard Disk...
> (XEN) HVM4: Booting from 0000:7c00
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=83
> (XEN) HVM4: int13_harddisk: function 08, unmapped device for ELDL=83
> (XEN) HVM4: *** int 15h function AX=00c0, BX=0000 not yet supported!
> (XEN) HVM4: *** int 15h function AX=ec00, BX=0002 not yet supported!
> (XEN) HVM4: KBD: unsupported int 16h function 03
> (XEN) HVM4: *** int 15h function AX=e980, BX=0000 not yet supported!
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=83
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=83
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=84
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=84
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=85
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=85
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=86
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=86
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=87
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=87
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 88
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 88
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 89
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 89
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8a
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8a
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8b
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8b
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8c
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8c
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8d
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8d
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8e
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8e
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8f
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8f
> (XEN) irq.c:330: Dom4 callback via changed to Direct Vector 0xe9
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) irq.c:264: Dom4 PCI link 0 changed 5 -> 0
> (XEN) irq.c:264: Dom4 PCI link 1 changed 10 -> 0
> (XEN) irq.c:264: Dom4 PCI link 2 changed 11 -> 0
> (XEN) irq.c:264: Dom4 PCI link 3 changed 5 -> 0
> (XEN) msi.c:867: MSI is already in use on device 0d:00.0
> (XEN) msi.c:867: MSI is already in use on device 1f:00.0
> 
> qemu log:
> ----------
> # cat /var/log/xen/qemu-dm-oakDom1.log
> domid: 4
> Using xvda for guest's hda
> Using file /OVS/Repositories/oakDom1/System.img in read-write mode
> Using xvdb for guest's hdb
> Using file /OVS/Repositories/oakDom1/u01.img in read-write mode
> Using xvdc for guest's hdc
> Using file /OVS/Repositories/oakDom1/swap.img in read-write mode
> Watching /local/domain/0/device-model/4/logdirty/cmd
> Watching /local/domain/0/device-model/4/command
> Watching /local/domain/4/cpu
> char device redirected to /dev/pts/1
> qemu_map_cache_init nr_buckets = 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid = 21f8dda2-cb14-5887-bddf-d3a45aa42311
> 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/4/xen_extended_power_mgmt): read error
> xs_read(): vncpasswd get error.
> /vm/21f8dda2-cb14-5887-bddf-d3a45aa42311/vncpasswd.
> 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
> vcpu-set: watch node error.
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> xs_read(/local/domain/4/log-throttling): read error
> qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
> medium change watch on `/local/domain/4/log-throttling' - unknown device,
> ignored
> 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
> 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
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> dm-command: hot insert pass-through pci dev 
> register_real_device: Assigning real physical device 0d:00.0 ...
> register_real_device: Enable MSI translation via per device option
> register_real_device: Disable power management
> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such
> file or directory: 0xd:0x0.0x0
> pt_register_regions: IO region registered (size=0x00000100
> base_addr=0x00009001)
> pt_register_regions: IO region registered (size=0x00004000
> base_addr=0xdf03c004)
> pt_register_regions: IO region registered (size=0x00040000
> base_addr=0xdf040004)
> pt_register_regions: Expansion ROM registered (size=0x00080000
> base_addr=0xdf080000)
> pt_msix_init: get MSI-X table bar base df03c000
> pt_msix_init: table_off = 2000, total_entries = 15
> pt_msix_init: errno = 2
> pt_msix_init: mapping physical MSI-X table to 7fd7738ea000
> pt_msi_setup: msi mapped with pirq 4f
> pci_intx: intx=1
> register_real_device: Real physical device 0d:00.0 registered successfuly!
> IRQ type = MSI-INTx
> dm-command: hot insert pass-through pci dev 
> register_real_device: Assigning real physical device 1f:00.0 ...
> register_real_device: Enable MSI translation via per device option
> register_real_device: Disable power management
> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such
> file or directory: 0x1f:0x0.0x0
> pt_register_regions: IO region registered (size=0x00000100
> base_addr=0x0000d001)
> pt_register_regions: IO region registered (size=0x00004000
> base_addr=0xdf63c004)
> pt_register_regions: IO region registered (size=0x00040000
> base_addr=0xdf640004)
> pt_register_regions: Expansion ROM registered (size=0x00080000
> base_addr=0xdf680000)
> pt_msix_init: get MSI-X table bar base df63c000
> pt_msix_init: table_off = 2000, total_entries = 15
> pt_msix_init: errno = 2
> pt_msix_init: mapping physical MSI-X table to 7fd7738e9000
> pt_msi_setup: msi mapped with pirq 4e
> pci_intx: intx=1
> register_real_device: Real physical device 1f:00.0 registered successfuly!
> IRQ type = MSI-INTx
> char device redirected to /dev/pts/2
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> cirrus vga map change while on lfb mode
> pt_iomem_map: e_phys=f3100000 maddr=df040000 type=0 len=262144 index=3
> first_map=1
> pt_iomem_map: e_phys=f3140000 maddr=df640000 type=0 len=262144 index=3
> first_map=1
> pt_iomem_map: e_phys=f3180000 maddr=df03c000 type=0 len=16384 index=1
> first_map=1
> pt_iomem_map: e_phys=f3184000 maddr=df63c000 type=0 len=16384 index=1
> first_map=1
> pt_ioport_map: e_phys=c100 pio_base=9000 len=256 index=0 first_map=1
> pt_ioport_map: e_phys=c200 pio_base=d000 len=256 index=0 first_map=1
> Overlapped to device[00:05.0][Region:6][Address:f3080000h][Size:00080000h]
> pt_bar_mapping_one: Warning:
> ptdev[00:04.0][Region:6][Address:f3000001h][Size:00080000h] is overlapped.
> pt_iomem_map: e_phys=f3000001 maddr=df080000 type=8 len=524288 index=6
> first_map=1
> pt_iomem_map: e_phys=ffffffff maddr=df080000 type=8 len=524288 index=6
> first_map=0
> Overlapped to device[00:04.0][Region:3][Address:f3100000h][Size:00040000h]
> pt_bar_mapping_one: Warning:
> ptdev[00:05.0][Region:6][Address:f3080001h][Size:00080000h] is overlapped.
> pt_iomem_map: e_phys=f3080001 maddr=df680000 type=8 len=524288 index=6
> first_map=1
> pt_iomem_map: e_phys=ffffffff maddr=df680000 type=8 len=524288 index=6
> first_map=0
> 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.
> Unknown PV product 3 loaded in guest
> PV driver build 1
> pt_ioport_map: e_phys=ffff pio_base=9000 len=256 index=0 first_map=0
> pt_ioport_map: e_phys=c100 pio_base=9000 len=256 index=0 first_map=0
> pt_ioport_map: e_phys=ffff pio_base=d000 len=256 index=0 first_map=0
> pt_ioport_map: e_phys=c200 pio_base=d000 len=256 index=0 first_map=0
> pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
> pci_intx: intx=1
> pt_msix_update_one: Update msix entry 0 with pirq 4d gvec 59
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
> pci_intx: intx=1
> pt_msix_update_one: Update msix entry 0 with pirq 4c gvec 69
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pt_msix_update_one: Update msix entry 0 with pirq 4d gvec 71
> pt_msix_update_one: Update msix entry 0 with pirq 4c gvec 79
> 
> 
> Any input will appreciate!
> Joe
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


-- 
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing 

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 07:20:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 07:20: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 1U2GKt-0004Kj-Fu; Mon, 04 Feb 2013 07:19:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U2GKr-0004Ke-NE
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 07:19:26 +0000
Received: from [85.158.143.35:33898] by server-2.bemta-4.messagelabs.com id
	BF/0F-01597-DF06F015; Mon, 04 Feb 2013 07:19:25 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1359962360!12886833!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTE5NTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17266 invoked from network); 4 Feb 2013 07:19:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 07:19:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r147JHtx010526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Mon, 4 Feb 2013 07:19:18 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
	r147JGcf025737
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Mon, 4 Feb 2013 07:19:16 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
	r147JGgd016480
	for <xen-devel@lists.xen.org>; Mon, 4 Feb 2013 01:19:16 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sun, 03 Feb 2013 23:19:15 -0800
Message-ID: <510F60F2.4070706@oracle.com>
Date: Mon, 04 Feb 2013 15:19:14 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <50F6A619.7030606@oracle.com>
In-Reply-To: <50F6A619.7030606@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] rombios unable to loaded MPT BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 debugged PMM I found it caused MPT(LSI controller) BIOS, MPT BIOS
overwrote pmm header and lead PMM unable to allocate memory.

Thanks,
Joe

On 01/16/13 21:07, Joe Jin wrote:
> Hi All,
> 
> When tried to pass through 2 mpt2sas HBA to hvm guest, hvmloader
> paused with below:
> 
> MPT BIOS Fault 09h encountered at adapter PCI(00h,04h,00h)
> Press any key to continue...
> 
> Checked related codes and mostly like it caused by rombios did not
> loaded MPT BIOS properly, and lead MPT BIOS failed to bootup.
> 
> config-file of the guest as below:
> ----------------------------------
> # cat vm.cfg
> kernel = '/usr/lib/xen/boot/hvmloader'
> builder = 'hvm'
> device_model = '/usr/lib64/xen/bin/qemu-dm'
> vnc=1
> vncunused=1
> vnclisten="0.0.0.0"
> apic=1
> acpi=1
> pae=1
> serial='pty'
> vif = ['type=netfront,bridge=priv1','type=netfront,bridge=net1','type=netfront,bridge=net2']
> #memory = '32768'
> memory = '4096'
> name = 'pci-passthrough-dom1'
> on_crash = 'destroy'
> on_reboot = 'restart'
> timer_mode = 0
> vcpus=8
> pci=['0d:00.0','1f:00.0']
> disk = ['file:/OVS/Repositories/oakDom1/System.img,xvda,w','file:/OVS/Repositories/oakDom1/u01.img,xvdb,w','file:/OVS/Repositories/oakDom1/swap.img,xvdc,w']
> 
> Device pci info:
> ----------------
> # lspci -nvv -s 0f:00.0
> 0d:00.0 0107: 1000:0072 (rev 03)
>     Subsystem: 1000:3050
>     Physical Slot: 3
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0, Cache Line Size: 256 bytes
>     Interrupt: pin A routed to IRQ 24
>     Region 0: I/O ports at 9000 [size=256]
>     Region 1: Memory at df03c000 (64-bit, non-prefetchable) [size=16K]
>     Region 3: Memory at df040000 (64-bit, non-prefetchable) [size=256K]
>     Expansion ROM at df080000 [disabled] [size=512K]
>     Capabilities: [50] Power Management version 3
>         Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] Express (v2) Endpoint, MSI 00
>         DevCap:    MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #0, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <64ns, L1 <1us
>             ClockPM- Surprise- LLActRep- BwNot-
>         LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Range BC, TimeoutDis+
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance-ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB
>     Capabilities: [d0] Vital Product Data
>         Product Name: SGX-SAS6-INT-Z, Sun StorageTek 6Gb/s SAS PCIe HBA, Internal
>         Read-only fields:
>             [PN] Part number: 375-3640-02
>             [EC] Engineering changes: 01
>             [MN] Manufacture ID: 53 75 6e 20 4d 69 63 72 6f 73 79 73 74 65 6d 73 2c 20 49 6e 63 2e
>             [SN] Serial number: SP14344072
>             [RV] Reserved: checksum good, 0 byte(s) reserved
>         End
>     Capabilities: [a8] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Address: 00000000fee00738  Data: 0000
>     Capabilities: [c0] MSI-X: Enable- Count=15 Masked-
>         Vector table: BAR=1 offset=00002000
>         PBA: BAR=1 offset=00003800
>     Capabilities: [100 v1] Advanced Error Reporting
>         UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UESvrt:    DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>         CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         AERCap:    First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>     Capabilities: [138 v1] Power Budgeting <?>
>     Kernel driver in use: pciback
>     Kernel modules: mpt2sas
> 
> # lspci -nvv -s 1f:00.0
> 1f:00.0 0107: 1000:0072 (rev 03)
>     Subsystem: 1000:3050
>     Physical Slot: 4
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0, Cache Line Size: 256 bytes
>     Interrupt: pin A routed to IRQ 32
>     Region 0: I/O ports at d000 [size=256]
>     Region 1: Memory at df63c000 (64-bit, non-prefetchable) [size=16K]
>     Region 3: Memory at df640000 (64-bit, non-prefetchable) [size=256K]
>     Expansion ROM at df680000 [disabled] [size=512K]
>     Capabilities: [50] Power Management version 3
>         Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] Express (v2) Endpoint, MSI 00
>         DevCap:    MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported- 
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #0, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <64ns, L1 <1us
>             ClockPM- Surprise- LLActRep- BwNot-
>         LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Range BC, TimeoutDis+
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance-ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB
>     Capabilities: [d0] Vital Product Data
>         Product Name: SGX-SAS6-INT-Z, Sun StorageTek 6Gb/s SAS PCIe HBA, Internal
>         Read-only fields:
>             [PN] Part number: 375-3640-02
>             [EC] Engineering changes: 01
>             [MN] Manufacture ID: 53 75 6e 20 4d 69 63 72 6f 73 79 73 74 65 6d 73 2c 20 49 6e 63 2e
>             [SN] Serial number: SP14035588
>             [RV] Reserved: checksum good, 0 byte(s) reserved
>         End
>     Capabilities: [a8] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Address: 00000000fee00758  Data: 0000
>     Capabilities: [c0] MSI-X: Enable- Count=15 Masked-
>         Vector table: BAR=1 offset=00002000
>         PBA: BAR=1 offset=00003800
>     Capabilities: [100 v1] Advanced Error Reporting
>         UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>         UESvrt:    DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>         CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>         AERCap:    First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>     Capabilities: [138 v1] Power Budgeting <?>
>     Kernel driver in use: pciback
>     Kernel modules: mpt2sas
> 
> 
> 
> Debug info when xm-create the guest:
> -------------------------------------
> (XEN) HVM4: HVM Loader
> (XEN) HVM4: Detected Xen v4.1.2-OVM
> (XEN) HVM4: CPU speed is 3060 MHz
> (XEN) HVM4: Xenbus rings @0xfeffc000, event channel 9
> (XEN) irq.c:264: Dom4 PCI link 0 changed 0 -> 5
> (XEN) HVM4: PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:264: Dom4 PCI link 1 changed 0 -> 10
> (XEN) HVM4: PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:264: Dom4 PCI link 2 changed 0 -> 11
> (XEN) HVM4: PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:264: Dom4 PCI link 3 changed 0 -> 5
> (XEN) HVM4: PCI-ISA link 3 routed to IRQ5
> (XEN) HVM4: pci dev 01:3 INTA->IRQ10
> (XEN) HVM4: pci dev 03:0 INTA->IRQ5
> (XEN) HVM4: pci dev 04:0 INTA->IRQ5
> (XEN) HVM4: pci dev 05:0 INTA->IRQ10
> (XEN) HVM4: pci dev 02:0 bar 10 size 02000000: f0000008
> (XEN) HVM4: pci dev 03:0 bar 14 size 01000000: f2000008
> (XEN) HVM4: pci dev 04:0 bar 30 size 00080000: f3000000
> (XEN) HVM4: pci dev 05:0 bar 30 size 00080000: f3080000
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40
> (XEN) HVM4: pci dev 04:0 bar 1c size 00040000: f3100004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40
> (XEN) HVM4: pci dev 05:0 bar 1c size 00040000: f3140004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3182 mfn=df03e nr_mfns=1
> (XEN) HVM4: pci dev 04:0 bar 14 size 00004000: f3180004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3184 mfn=df63c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3186 mfn=df63e nr_mfns=1
> (XEN) HVM4: pci dev 05:0 bar 14 size 00004000: f3184004
> (XEN) HVM4: pci dev 02:0 bar 14 size 00001000: f3188000
> (XEN) HVM4: pci dev 03:0 bar 10 size 00000100: 0000c001
> (XEN) HVM4: pci dev 04:0 bar 10 size 00000100: 0000c101
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) HVM4: pci dev 05:0 bar 10 size 00000100: 0000c201
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) HVM4: pci dev 01:1 bar 20 size 00000010: 0000c301
> (XEN) HVM4: Multiprocessor initialisation:
> (XEN) HVM4:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU6 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4:  - CPU7 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM4: Writing SMBIOS tables ...
> (XEN) HVM4: Loading ROMBIOS ...
> (XEN) HVM4: 10332 bytes of ROMBIOS high-memory extensions:
> (XEN) HVM4:   Relocating to 0xfc000000-0xfc00285c ... done
> (XEN) HVM4: Creating MP tables ...
> (XEN) HVM4: Loading Cirrus VGABIOS ...
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3000 mfn=df080 nr_mfns=80
> (XEN) HVM4: Loading PCI Option ROM ...
> (XEN) HVM4:  - Manufacturer: LSI Corporation
> (XEN) HVM4:  - Product name: LSI MPI Boot Support
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3000 mfn=df080 nr_mfns=80
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) HVM4: Loading ACPI ...
> (XEN) HVM4:  - Lo data: 000ea020-000ea04f
> (XEN) HVM4:  - Hi data: fc002c00-fc00eb0f
> (XEN) HVM4: vm86 TSS at fc00ec00
> (XEN) HVM4: BIOS map:
> (XEN) HVM4:  c0000-c8fff: VGA BIOS
> (XEN) HVM4:  c9000-d4fff: PCI Option ROMs
> (XEN) HVM4:  eb000-eb263: SMBIOS tables
> (XEN) HVM4:  f0000-fffff: Main BIOS
> (XEN) HVM4: E820 table:
> (XEN) HVM4:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM4:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
> (XEN) HVM4:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
> (XEN) HVM4:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM4:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM4:  [04]: 00000000:00100000 - 00000000:f0000000: RAM
> (XEN) HVM4:  HOLE: 00000000:f0000000 - 00000000:fc000000
> (XEN) HVM4:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (XEN) HVM4:  [06]: 00000001:00000000 - 00000001:10000000: RAM
> (XEN) HVM4: Invoking ROMBIOS ...
> (XEN) HVM4: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) stdvga.c:147:d4 entering stdvga and caching modes
> (XEN) HVM4: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> (XEN) HVM4: Bochs BIOS - build: 06/23/99
> (XEN) HVM4: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) HVM4: Options: apmbios pcibios eltorito PMM 
> (XEN) HVM4: 
> (XEN) HVM4: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM4: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (60000 MBytes)
> (XEN) HVM4: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM4: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  97 GBytes)
> (XEN) HVM4: ata1-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM4: ata1 master: QEMU HARDDISK ATA-7 Hard-Disk (20000 MBytes)
> (XEN) HVM4: IDE time out
> (XEN) HVM4: 
> (XEN) HVM4: PCI device 1000:0070 not found at index 0
> (XEN) HVM4: PCI device 1000:0072 not found at index 2
> (XEN) HVM4: PCI device 1000:0074 not found at index 0
> (XEN) HVM4: PCI device 1000:0076 not found at index 0
> (XEN) HVM4: PCI device 1000:0077 not found at index 0
> (XEN) HVM4: PCI device 1000:0064 not found at index 0
> (XEN) HVM4: PCI device 1000:0065 not found at index 0
> (XEN) HVM4: PCI device 1000:0080 not found at index 0
> (XEN) HVM4: PCI device 1000:0081 not found at index 0
> (XEN) HVM4: PCI device 1000:0082 not found at index 0
> (XEN) HVM4: PCI device 1000:0083 not found at index 0
> (XEN) HVM4: PCI device 1000:0084 not found at index 0
> (XEN) HVM4: PCI device 1000:0085 not found at index 0
> (XEN) HVM4: PCI device 1000:0086 not found at index 0
> (XEN) HVM4: PCI device 1000:0087 not found at index 0
> (XEN) HVM4: 
> (XEN) HVM4: 
> (XEN) HVM4: Press F12 for boot menu.
> (XEN) HVM4: 
> (XEN) HVM4: Booting from Hard Disk...
> (XEN) HVM4: Booting from 0000:7c00
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=83
> (XEN) HVM4: int13_harddisk: function 08, unmapped device for ELDL=83
> (XEN) HVM4: *** int 15h function AX=00c0, BX=0000 not yet supported!
> (XEN) HVM4: *** int 15h function AX=ec00, BX=0002 not yet supported!
> (XEN) HVM4: KBD: unsupported int 16h function 03
> (XEN) HVM4: *** int 15h function AX=e980, BX=0000 not yet supported!
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=83
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=83
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=84
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=84
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=85
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=85
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=86
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=86
> (XEN) HVM4: int13_harddisk: function 41, unmapped device for ELDL=87
> (XEN) HVM4: int13_harddisk: function 02, unmapped device for ELDL=87
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 88
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 88
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 89
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 89
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8a
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8a
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8b
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8b
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8c
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8c
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8d
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8d
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8e
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8e
> (XEN) HVM4: int13_harddisk: function 41, ELDL out of range 8f
> (XEN) HVM4: int13_harddisk: function 02, ELDL out of range 8f
> (XEN) irq.c:330: Dom4 callback via changed to Direct Vector 0xe9
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) irq.c:264: Dom4 PCI link 0 changed 5 -> 0
> (XEN) irq.c:264: Dom4 PCI link 1 changed 10 -> 0
> (XEN) irq.c:264: Dom4 PCI link 2 changed 11 -> 0
> (XEN) irq.c:264: Dom4 PCI link 3 changed 5 -> 0
> (XEN) msi.c:867: MSI is already in use on device 0d:00.0
> (XEN) msi.c:867: MSI is already in use on device 1f:00.0
> 
> qemu log:
> ----------
> # cat /var/log/xen/qemu-dm-oakDom1.log
> domid: 4
> Using xvda for guest's hda
> Using file /OVS/Repositories/oakDom1/System.img in read-write mode
> Using xvdb for guest's hdb
> Using file /OVS/Repositories/oakDom1/u01.img in read-write mode
> Using xvdc for guest's hdc
> Using file /OVS/Repositories/oakDom1/swap.img in read-write mode
> Watching /local/domain/0/device-model/4/logdirty/cmd
> Watching /local/domain/0/device-model/4/command
> Watching /local/domain/4/cpu
> char device redirected to /dev/pts/1
> qemu_map_cache_init nr_buckets = 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid = 21f8dda2-cb14-5887-bddf-d3a45aa42311
> 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/4/xen_extended_power_mgmt): read error
> xs_read(): vncpasswd get error.
> /vm/21f8dda2-cb14-5887-bddf-d3a45aa42311/vncpasswd.
> 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
> vcpu-set: watch node error.
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> xs_read(/local/domain/4/log-throttling): read error
> qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
> medium change watch on `/local/domain/4/log-throttling' - unknown device,
> ignored
> 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
> 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
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> dm-command: hot insert pass-through pci dev 
> register_real_device: Assigning real physical device 0d:00.0 ...
> register_real_device: Enable MSI translation via per device option
> register_real_device: Disable power management
> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such
> file or directory: 0xd:0x0.0x0
> pt_register_regions: IO region registered (size=0x00000100
> base_addr=0x00009001)
> pt_register_regions: IO region registered (size=0x00004000
> base_addr=0xdf03c004)
> pt_register_regions: IO region registered (size=0x00040000
> base_addr=0xdf040004)
> pt_register_regions: Expansion ROM registered (size=0x00080000
> base_addr=0xdf080000)
> pt_msix_init: get MSI-X table bar base df03c000
> pt_msix_init: table_off = 2000, total_entries = 15
> pt_msix_init: errno = 2
> pt_msix_init: mapping physical MSI-X table to 7fd7738ea000
> pt_msi_setup: msi mapped with pirq 4f
> pci_intx: intx=1
> register_real_device: Real physical device 0d:00.0 registered successfuly!
> IRQ type = MSI-INTx
> dm-command: hot insert pass-through pci dev 
> register_real_device: Assigning real physical device 1f:00.0 ...
> register_real_device: Enable MSI translation via per device option
> register_real_device: Disable power management
> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such
> file or directory: 0x1f:0x0.0x0
> pt_register_regions: IO region registered (size=0x00000100
> base_addr=0x0000d001)
> pt_register_regions: IO region registered (size=0x00004000
> base_addr=0xdf63c004)
> pt_register_regions: IO region registered (size=0x00040000
> base_addr=0xdf640004)
> pt_register_regions: Expansion ROM registered (size=0x00080000
> base_addr=0xdf680000)
> pt_msix_init: get MSI-X table bar base df63c000
> pt_msix_init: table_off = 2000, total_entries = 15
> pt_msix_init: errno = 2
> pt_msix_init: mapping physical MSI-X table to 7fd7738e9000
> pt_msi_setup: msi mapped with pirq 4e
> pci_intx: intx=1
> register_real_device: Real physical device 1f:00.0 registered successfuly!
> IRQ type = MSI-INTx
> char device redirected to /dev/pts/2
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> cirrus vga map change while on lfb mode
> pt_iomem_map: e_phys=f3100000 maddr=df040000 type=0 len=262144 index=3
> first_map=1
> pt_iomem_map: e_phys=f3140000 maddr=df640000 type=0 len=262144 index=3
> first_map=1
> pt_iomem_map: e_phys=f3180000 maddr=df03c000 type=0 len=16384 index=1
> first_map=1
> pt_iomem_map: e_phys=f3184000 maddr=df63c000 type=0 len=16384 index=1
> first_map=1
> pt_ioport_map: e_phys=c100 pio_base=9000 len=256 index=0 first_map=1
> pt_ioport_map: e_phys=c200 pio_base=d000 len=256 index=0 first_map=1
> Overlapped to device[00:05.0][Region:6][Address:f3080000h][Size:00080000h]
> pt_bar_mapping_one: Warning:
> ptdev[00:04.0][Region:6][Address:f3000001h][Size:00080000h] is overlapped.
> pt_iomem_map: e_phys=f3000001 maddr=df080000 type=8 len=524288 index=6
> first_map=1
> pt_iomem_map: e_phys=ffffffff maddr=df080000 type=8 len=524288 index=6
> first_map=0
> Overlapped to device[00:04.0][Region:3][Address:f3100000h][Size:00040000h]
> pt_bar_mapping_one: Warning:
> ptdev[00:05.0][Region:6][Address:f3080001h][Size:00080000h] is overlapped.
> pt_iomem_map: e_phys=f3080001 maddr=df680000 type=8 len=524288 index=6
> first_map=1
> pt_iomem_map: e_phys=ffffffff maddr=df680000 type=8 len=524288 index=6
> first_map=0
> 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.
> Unknown PV product 3 loaded in guest
> PV driver build 1
> pt_ioport_map: e_phys=ffff pio_base=9000 len=256 index=0 first_map=0
> pt_ioport_map: e_phys=c100 pio_base=9000 len=256 index=0 first_map=0
> pt_ioport_map: e_phys=ffff pio_base=d000 len=256 index=0 first_map=0
> pt_ioport_map: e_phys=c200 pio_base=d000 len=256 index=0 first_map=0
> pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
> pci_intx: intx=1
> pt_msix_update_one: Update msix entry 0 with pirq 4d gvec 59
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
> pci_intx: intx=1
> pt_msix_update_one: Update msix entry 0 with pirq 4c gvec 69
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already                function.
> pt_msix_update_one: Update msix entry 0 with pirq 4d gvec 71
> pt_msix_update_one: Update msix entry 0 with pirq 4c gvec 79
> 
> 
> Any input will appreciate!
> Joe
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


-- 
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing 

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 08:12:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08: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 1U2HA1-0005WD-Iz; Mon, 04 Feb 2013 08:12:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagana.c@gmail.com>) id 1U2H9z-0005W8-UP
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:12:16 +0000
Received: from [85.158.137.99:5004] by server-15.bemta-3.messagelabs.com id
	B8/CB-25405-F5D6F015; Mon, 04 Feb 2013 08:12:15 +0000
X-Env-Sender: sagana.c@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1359965533!19842733!1
X-Originating-IP: [209.85.217.182]
X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4849 invoked from network); 4 Feb 2013 08:12:14 -0000
Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com)
	(209.85.217.182)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 08:12:14 -0000
Received: by mail-lb0-f182.google.com with SMTP id gg6so6438131lbb.13
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 00:12:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=HZ4hSjHfigdfdJ9KBLZ9KYPTTYnDAah2ABXgFFefoVI=;
	b=I8V7OoHORYjmmYbjL6dlvLufgrX27ROSfB08amHAeXFvALzT5F5xKgaMELTQrPArfL
	bFr/VIgm5C90krxm4wjy7U3y6RY2qvenImPRhYMoUa3fK05lPO+T8zNAUxtvXGTCW3bc
	PeHEi7ED/yw03lO1Jso0NKXvhfv/cBBBBVu0qFGCcrSYj8S80HI+dSyTHrylfsno04Yu
	U1K7uudIOjPEFW/5UCrOsk4S4MONsjMLo8fiE07ijtaZ5zUi7tT33jkoNbhkkkk1Nflf
	ZOVQ9QjP6FtQZkkACHXBMoblxDGIHsZzegSF8y2g1IVAN/VqADbGq/XA96iq7nFTdRBt
	0YjQ==
MIME-Version: 1.0
X-Received: by 10.152.105.17 with SMTP id gi17mr18169863lab.46.1359965533609; 
	Mon, 04 Feb 2013 00:12:13 -0800 (PST)
Received: by 10.114.69.199 with HTTP; Mon, 4 Feb 2013 00:12:13 -0800 (PST)
Date: Mon, 4 Feb 2013 13:42:13 +0530
Message-ID: <CAG_Pk2s1V9KaEG6x7EtOroKGiyUeusEbB28NiBxDFP9RTS1cVg@mail.gmail.com>
From: sagana chinnathambi <sagana.c@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] live migration reg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7127101979761239118=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7127101979761239118==
Content-Type: multipart/alternative; boundary=f46d040892fd899f9e04d4e1a62f

--f46d040892fd899f9e04d4e1a62f
Content-Type: text/plain; charset=ISO-8859-1

how to implement working set in live migration of virtual machine using xen

--f46d040892fd899f9e04d4e1a62f
Content-Type: text/html; charset=ISO-8859-1

<br clear="all"><div><br></div>how to implement working set in live migration of virtual machine using xen

--f46d040892fd899f9e04d4e1a62f--


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

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

--===============7127101979761239118==--


From xen-devel-bounces@lists.xen.org Mon Feb 04 08:12:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08: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 1U2HA1-0005WD-Iz; Mon, 04 Feb 2013 08:12:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sagana.c@gmail.com>) id 1U2H9z-0005W8-UP
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:12:16 +0000
Received: from [85.158.137.99:5004] by server-15.bemta-3.messagelabs.com id
	B8/CB-25405-F5D6F015; Mon, 04 Feb 2013 08:12:15 +0000
X-Env-Sender: sagana.c@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1359965533!19842733!1
X-Originating-IP: [209.85.217.182]
X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4849 invoked from network); 4 Feb 2013 08:12:14 -0000
Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com)
	(209.85.217.182)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 08:12:14 -0000
Received: by mail-lb0-f182.google.com with SMTP id gg6so6438131lbb.13
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 00:12:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=HZ4hSjHfigdfdJ9KBLZ9KYPTTYnDAah2ABXgFFefoVI=;
	b=I8V7OoHORYjmmYbjL6dlvLufgrX27ROSfB08amHAeXFvALzT5F5xKgaMELTQrPArfL
	bFr/VIgm5C90krxm4wjy7U3y6RY2qvenImPRhYMoUa3fK05lPO+T8zNAUxtvXGTCW3bc
	PeHEi7ED/yw03lO1Jso0NKXvhfv/cBBBBVu0qFGCcrSYj8S80HI+dSyTHrylfsno04Yu
	U1K7uudIOjPEFW/5UCrOsk4S4MONsjMLo8fiE07ijtaZ5zUi7tT33jkoNbhkkkk1Nflf
	ZOVQ9QjP6FtQZkkACHXBMoblxDGIHsZzegSF8y2g1IVAN/VqADbGq/XA96iq7nFTdRBt
	0YjQ==
MIME-Version: 1.0
X-Received: by 10.152.105.17 with SMTP id gi17mr18169863lab.46.1359965533609; 
	Mon, 04 Feb 2013 00:12:13 -0800 (PST)
Received: by 10.114.69.199 with HTTP; Mon, 4 Feb 2013 00:12:13 -0800 (PST)
Date: Mon, 4 Feb 2013 13:42:13 +0530
Message-ID: <CAG_Pk2s1V9KaEG6x7EtOroKGiyUeusEbB28NiBxDFP9RTS1cVg@mail.gmail.com>
From: sagana chinnathambi <sagana.c@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] live migration reg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7127101979761239118=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7127101979761239118==
Content-Type: multipart/alternative; boundary=f46d040892fd899f9e04d4e1a62f

--f46d040892fd899f9e04d4e1a62f
Content-Type: text/plain; charset=ISO-8859-1

how to implement working set in live migration of virtual machine using xen

--f46d040892fd899f9e04d4e1a62f
Content-Type: text/html; charset=ISO-8859-1

<br clear="all"><div><br></div>how to implement working set in live migration of virtual machine using xen

--f46d040892fd899f9e04d4e1a62f--


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

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

--===============7127101979761239118==--


From xen-devel-bounces@lists.xen.org Mon Feb 04 08:22:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08:22: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 1U2HJE-0005h4-KW; Mon, 04 Feb 2013 08:21: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 1U2HJD-0005gz-7k
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:21:47 +0000
Received: from [85.158.139.83:14113] by server-12.bemta-5.messagelabs.com id
	81/D0-20195-99F6F015; Mon, 04 Feb 2013 08:21:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1359966094!23690213!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17732 invoked from network); 4 Feb 2013 08:21:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 08:21:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 08:21:33 +0000
Message-Id: <510F7D9902000078000BB63F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 08:21:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de> <20130131184637.GA3052@aepfle.de>
In-Reply-To: <20130131184637.GA3052@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.01.13 at 19:46, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Jan 31, Olaf Hering wrote:
> 
>> On Thu, Jan 31, Ian Campbell wrote:
>> 
>> > On Thu, 2013-01-31 at 17:07 +0000, Olaf Hering wrote:
>> > > Current xen-unstable has appearently issues with HVM guest.
>> > 
>> > staging or tested? which changeset?
>> 
>> staging, 26493:6727070b4129
>> Its the first time since many weeks that I run xen-unstable again, so I
>> cant tell when it started.
> 
> It works with xend for some reason, pvops dom0+domU and changeset
> 26502:d1bf3b21f783. What I see in guest dmesg is shown below. With xl the 
> irq#8
> message does not appear.

Odd - I didn't observe any problems specifically with SLE guests
(which is what I used for testing). In fact I also, subsequent to
the series that's already in staging, figured the problem with the
remaining changes left from the submission about half a year
ago, and was hoping to post that one soon too (but of course
won't until what's in is really sane).

Looking over the changes again (and without having looked at
the Linux side yet again), I think the most likely candidates for
reverting are

26457:aa82638d58b0 (x86/HVM: consolidate toggling of RTC IRQ)
26461:78e91e9e4d61 (x86/HVM: generalize IRQ raising on RTC_REG_B writes)

Especially the latter I can't really see to be responsible for
apparently superfluous IRQ8 instances, as my understanding
is that this would imply repeated REG_B writes (which I specifically
didn't observe with extra debugging code added).

Considering that I didn't see any problems with the patches
myself - any chance you could try the individual reverts above
as a first step? (Obviously reverting 26461 should be strait
forward, but reverting 26457 alone might not be as simple.)

Thanks, Jan

> ...
> [    0.832275] udev: starting version 147
> [    1.312097] tsc: Refined TSC clocksource calibration: 2926.333 MHz
> [   14.378118] udev: starting version 147
> [   14.469299] input: Xen Virtual Keyboard as /devices/virtual/input/input5
> [   14.469532] input: Xen Virtual Pointer as /devices/virtual/input/input6
> [   14.480053] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0xc
> [   14.480626] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - 
> upgrade BIOS or use force_addr=0xaddr
> [   14.546814] microcode: CPU1 sig=0x206c2, pf=0x1, revision=0xc
> [   14.601594] NET: Registered protocol family 10
> [   14.725108] microcode: Microcode Update Driver: v2.00 
> <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [   15.084864] Adding 331772k swap on /dev/xvda2.  Priority:-1 extents:1 
> across:331772k SS
> [   18.810217] irq 8: nobody cared (try booting with the "irqpoll" option)
> [   18.812058] Pid: 0, comm: swapper/0 Not tainted 
> 3.7.5-9.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 #1
> [   18.812058] Call Trace:
> [   18.812058]  <IRQ>  [<ffffffff8109ce78>] __report_bad_irq+0x38/0xe0
> [   18.812058]  [<ffffffff8109d0ef>] note_interrupt+0x1cf/0x210
> [   18.812058]  [<ffffffff8109aa77>] handle_irq_event_percpu+0x97/0x170
> [   18.812058]  [<ffffffff8109ab8c>] handle_irq_event+0x3c/0x60
> [   18.812058]  [<ffffffff8109d79d>] handle_edge_irq+0x6d/0x120
> [   18.812058]  [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4/0x280
> [   18.812058]  [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a/0x40
> [   18.812058]  [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d/0x80
> [   18.812058]  <EOI>  [<ffffffff810668f3>] ? hrtimer_start+0x13/0x20
> [   18.812058]  [<ffffffff810360d6>] ? native_safe_halt+0x6/0x10
> [   18.812058]  [<ffffffff81569e8f>] ? cpuidle_idle_call+0x1f/0xc0
> [   18.812058]  [<ffffffff81014735>] default_idle+0x45/0x50
> [   18.812058]  [<ffffffff81014a68>] cpu_idle+0x88/0xd0
> [   18.812058]  [<ffffffff81642428>] rest_init+0x68/0x70
> [   18.812058]  [<ffffffff81c7bc8f>] start_kernel+0x2f3/0x3b4
> [   18.812058]  [<ffffffff81c7b795>] ? repair_env_string+0x58/0x58
> [   18.812058]  [<ffffffff81cb8c36>] ? memblock_reserve+0x2e/0x4e
> [   18.812058]  [<ffffffff81c7b2d5>] x86_64_start_reservations+0xa5/0xc2
> [   18.812058]  [<ffffffff81c7b401>] x86_64_start_kernel+0x10f/0x12a
> [   18.812058]  [<ffffffff81c7b120>] ? early_idt_handlers+0x120/0x120
> [   18.812058] handlers:
> [   18.812058] [<ffffffff81550740>] cmos_interrupt
> [   18.812058] Disabling IRQ #8
> [   19.420384] loop: module loaded
> [   19.548950] kjournald starting.  Commit interval 5 seconds
> [   19.548970] EXT3-fs (xvda1): mounted filesystem with ordered data mode
> [   59.305223] PM: freeze of devices complete after 2.291 msecs
> [   59.305227] suspending xenstore...
> [   59.305290] PM: late freeze of devices complete after 0.058 msecs
> [   59.309521] PM: noirq freeze of devices complete after 4.227 msecs
> [   59.312080] Xen HVM callback vector for event delivery is enabled
> [   59.312080] Xen Platform PCI: I/O protocol version 1
> [   59.312080] Grant tables using version 1 layout.
> [   59.312080] xen: --> irq=8, pirq=16
> [   59.312080] xen: --> irq=12, pirq=17
> [   59.312080] xen: --> irq=1, pirq=18
> [   59.312080] xen: --> irq=6, pirq=19
> [   59.312080] xen: --> irq=4, pirq=20
> [   59.312080] xen: --> irq=7, pirq=21
> [   59.312080] xen: --> irq=28, pirq=22
> [   59.313545] ata_piix 0000:00:01.1: restoring config space at offset 0x4 
> (was 0x2800001, writing 0x2800005)
> [   59.313545] PM: noirq restore of devices complete after 7.838 msecs
> [   59.313545] PM: early restore of devices complete after 0.046 msecs
> [   59.319592] pci 0000:00:00.0: calling quirk_passive_release+0x0/0xa0
> [   59.479464] PM: restore of devices complete after 159.921 msecs
> [   59.488309] Setting capacity to 2097152
> [   59.498494] Setting capacity to 2097152
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 04 08:22:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08:22: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 1U2HJE-0005h4-KW; Mon, 04 Feb 2013 08:21: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 1U2HJD-0005gz-7k
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:21:47 +0000
Received: from [85.158.139.83:14113] by server-12.bemta-5.messagelabs.com id
	81/D0-20195-99F6F015; Mon, 04 Feb 2013 08:21:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1359966094!23690213!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17732 invoked from network); 4 Feb 2013 08:21:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 08:21:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 08:21:33 +0000
Message-Id: <510F7D9902000078000BB63F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 08:21:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de> <20130131184637.GA3052@aepfle.de>
In-Reply-To: <20130131184637.GA3052@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.01.13 at 19:46, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Jan 31, Olaf Hering wrote:
> 
>> On Thu, Jan 31, Ian Campbell wrote:
>> 
>> > On Thu, 2013-01-31 at 17:07 +0000, Olaf Hering wrote:
>> > > Current xen-unstable has appearently issues with HVM guest.
>> > 
>> > staging or tested? which changeset?
>> 
>> staging, 26493:6727070b4129
>> Its the first time since many weeks that I run xen-unstable again, so I
>> cant tell when it started.
> 
> It works with xend for some reason, pvops dom0+domU and changeset
> 26502:d1bf3b21f783. What I see in guest dmesg is shown below. With xl the 
> irq#8
> message does not appear.

Odd - I didn't observe any problems specifically with SLE guests
(which is what I used for testing). In fact I also, subsequent to
the series that's already in staging, figured the problem with the
remaining changes left from the submission about half a year
ago, and was hoping to post that one soon too (but of course
won't until what's in is really sane).

Looking over the changes again (and without having looked at
the Linux side yet again), I think the most likely candidates for
reverting are

26457:aa82638d58b0 (x86/HVM: consolidate toggling of RTC IRQ)
26461:78e91e9e4d61 (x86/HVM: generalize IRQ raising on RTC_REG_B writes)

Especially the latter I can't really see to be responsible for
apparently superfluous IRQ8 instances, as my understanding
is that this would imply repeated REG_B writes (which I specifically
didn't observe with extra debugging code added).

Considering that I didn't see any problems with the patches
myself - any chance you could try the individual reverts above
as a first step? (Obviously reverting 26461 should be strait
forward, but reverting 26457 alone might not be as simple.)

Thanks, Jan

> ...
> [    0.832275] udev: starting version 147
> [    1.312097] tsc: Refined TSC clocksource calibration: 2926.333 MHz
> [   14.378118] udev: starting version 147
> [   14.469299] input: Xen Virtual Keyboard as /devices/virtual/input/input5
> [   14.469532] input: Xen Virtual Pointer as /devices/virtual/input/input6
> [   14.480053] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0xc
> [   14.480626] piix4_smbus 0000:00:01.3: SMBus base address uninitialized - 
> upgrade BIOS or use force_addr=0xaddr
> [   14.546814] microcode: CPU1 sig=0x206c2, pf=0x1, revision=0xc
> [   14.601594] NET: Registered protocol family 10
> [   14.725108] microcode: Microcode Update Driver: v2.00 
> <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [   15.084864] Adding 331772k swap on /dev/xvda2.  Priority:-1 extents:1 
> across:331772k SS
> [   18.810217] irq 8: nobody cared (try booting with the "irqpoll" option)
> [   18.812058] Pid: 0, comm: swapper/0 Not tainted 
> 3.7.5-9.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 #1
> [   18.812058] Call Trace:
> [   18.812058]  <IRQ>  [<ffffffff8109ce78>] __report_bad_irq+0x38/0xe0
> [   18.812058]  [<ffffffff8109d0ef>] note_interrupt+0x1cf/0x210
> [   18.812058]  [<ffffffff8109aa77>] handle_irq_event_percpu+0x97/0x170
> [   18.812058]  [<ffffffff8109ab8c>] handle_irq_event+0x3c/0x60
> [   18.812058]  [<ffffffff8109d79d>] handle_edge_irq+0x6d/0x120
> [   18.812058]  [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4/0x280
> [   18.812058]  [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a/0x40
> [   18.812058]  [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d/0x80
> [   18.812058]  <EOI>  [<ffffffff810668f3>] ? hrtimer_start+0x13/0x20
> [   18.812058]  [<ffffffff810360d6>] ? native_safe_halt+0x6/0x10
> [   18.812058]  [<ffffffff81569e8f>] ? cpuidle_idle_call+0x1f/0xc0
> [   18.812058]  [<ffffffff81014735>] default_idle+0x45/0x50
> [   18.812058]  [<ffffffff81014a68>] cpu_idle+0x88/0xd0
> [   18.812058]  [<ffffffff81642428>] rest_init+0x68/0x70
> [   18.812058]  [<ffffffff81c7bc8f>] start_kernel+0x2f3/0x3b4
> [   18.812058]  [<ffffffff81c7b795>] ? repair_env_string+0x58/0x58
> [   18.812058]  [<ffffffff81cb8c36>] ? memblock_reserve+0x2e/0x4e
> [   18.812058]  [<ffffffff81c7b2d5>] x86_64_start_reservations+0xa5/0xc2
> [   18.812058]  [<ffffffff81c7b401>] x86_64_start_kernel+0x10f/0x12a
> [   18.812058]  [<ffffffff81c7b120>] ? early_idt_handlers+0x120/0x120
> [   18.812058] handlers:
> [   18.812058] [<ffffffff81550740>] cmos_interrupt
> [   18.812058] Disabling IRQ #8
> [   19.420384] loop: module loaded
> [   19.548950] kjournald starting.  Commit interval 5 seconds
> [   19.548970] EXT3-fs (xvda1): mounted filesystem with ordered data mode
> [   59.305223] PM: freeze of devices complete after 2.291 msecs
> [   59.305227] suspending xenstore...
> [   59.305290] PM: late freeze of devices complete after 0.058 msecs
> [   59.309521] PM: noirq freeze of devices complete after 4.227 msecs
> [   59.312080] Xen HVM callback vector for event delivery is enabled
> [   59.312080] Xen Platform PCI: I/O protocol version 1
> [   59.312080] Grant tables using version 1 layout.
> [   59.312080] xen: --> irq=8, pirq=16
> [   59.312080] xen: --> irq=12, pirq=17
> [   59.312080] xen: --> irq=1, pirq=18
> [   59.312080] xen: --> irq=6, pirq=19
> [   59.312080] xen: --> irq=4, pirq=20
> [   59.312080] xen: --> irq=7, pirq=21
> [   59.312080] xen: --> irq=28, pirq=22
> [   59.313545] ata_piix 0000:00:01.1: restoring config space at offset 0x4 
> (was 0x2800001, writing 0x2800005)
> [   59.313545] PM: noirq restore of devices complete after 7.838 msecs
> [   59.313545] PM: early restore of devices complete after 0.046 msecs
> [   59.319592] pci 0000:00:00.0: calling quirk_passive_release+0x0/0xa0
> [   59.479464] PM: restore of devices complete after 159.921 msecs
> [   59.488309] Setting capacity to 2097152
> [   59.498494] Setting capacity to 2097152
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 04 08:44:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08:44: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 1U2Heq-0005tM-LS; Mon, 04 Feb 2013 08:44: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 1U2Hep-0005tE-5B
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 08:44:07 +0000
Received: from [85.158.143.99:58269] by server-2.bemta-4.messagelabs.com id
	7C/B3-01597-6D47F015; Mon, 04 Feb 2013 08:44:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1359967445!23710755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTgx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18292 invoked from network); 4 Feb 2013 08:44:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 08:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,597,1355097600"; 
   d="scan'208";a="1108553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 08:44: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.297.1; Mon, 4 Feb 2013 08:44:05 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2Hen-0006pY-1D;
	Mon, 04 Feb 2013 08:44:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2Hem-0000j3-TX;
	Mon, 04 Feb 2013 08:44:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15416-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 08:44:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15416: 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 15416 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15416/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10     fail pass in 15415
 test-amd64-amd64-xl-qemut-winxpsp3 12 guest-localmigrate/x10 fail pass in 15415
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore   fail pass in 15414
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail in 15415 pass in 15416
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 15415 pass in 15416

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 15415 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 15415 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 15414 never pass

version targeted for testing:
 xen                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 08:44:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08:44: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 1U2Heq-0005tM-LS; Mon, 04 Feb 2013 08:44: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 1U2Hep-0005tE-5B
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 08:44:07 +0000
Received: from [85.158.143.99:58269] by server-2.bemta-4.messagelabs.com id
	7C/B3-01597-6D47F015; Mon, 04 Feb 2013 08:44:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1359967445!23710755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTgx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18292 invoked from network); 4 Feb 2013 08:44:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 08:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,597,1355097600"; 
   d="scan'208";a="1108553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 08:44: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.297.1; Mon, 4 Feb 2013 08:44:05 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2Hen-0006pY-1D;
	Mon, 04 Feb 2013 08:44:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2Hem-0000j3-TX;
	Mon, 04 Feb 2013 08:44:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15416-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 08:44:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15416: 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 15416 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15416/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10     fail pass in 15415
 test-amd64-amd64-xl-qemut-winxpsp3 12 guest-localmigrate/x10 fail pass in 15415
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore   fail pass in 15414
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail in 15415 pass in 15416
 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail in 15415 pass in 15416

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 15415 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 15415 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 15414 never pass

version targeted for testing:
 xen                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 08:47:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08:47: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 1U2Hi6-00061W-9r; Mon, 04 Feb 2013 08:47:30 +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 1U2Hi4-00061N-PE
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:47:28 +0000
Received: from [85.158.143.35:7785] by server-1.bemta-4.messagelabs.com id
	FC/04-08839-0A57F015; Mon, 04 Feb 2013 08:47:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359967646!13684190!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21652 invoked from network); 4 Feb 2013 08:47:26 -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; 4 Feb 2013 08:47:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 08:47:25 +0000
Message-Id: <510F83AA02000078000BB64A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 08:47:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>,"Jan Beulich" <JBeulich@suse.com>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de> <20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
In-Reply-To: <510F7D9902000078000BB63F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 09:21, "Jan Beulich" <JBeulich@suse.com> wrote:
> Looking over the changes again (and without having looked at
> the Linux side yet again), I think the most likely candidates for
> reverting are
> 
> 26457:aa82638d58b0 (x86/HVM: consolidate toggling of RTC IRQ)
> 26461:78e91e9e4d61 (x86/HVM: generalize IRQ raising on RTC_REG_B writes)

Actually, one possibility occurred to me right after sending the
earlier response - could you give the patch below a try?

Jan

--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -55,6 +55,8 @@ static void rtc_toggle_irq(RTCState *s)
     struct domain *d = vrtc_domain(s);
 
     ASSERT(spin_is_locked(&s->lock));
+    if ( s->hw.cmos_data[RTC_REG_C] & RTC_IRQF )
+        return;
     s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
     hvm_isa_irq_deassert(d, RTC_IRQ);
     hvm_isa_irq_assert(d, RTC_IRQ);



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 08:47:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08:47: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 1U2Hi6-00061W-9r; Mon, 04 Feb 2013 08:47:30 +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 1U2Hi4-00061N-PE
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:47:28 +0000
Received: from [85.158.143.35:7785] by server-1.bemta-4.messagelabs.com id
	FC/04-08839-0A57F015; Mon, 04 Feb 2013 08:47:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359967646!13684190!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21652 invoked from network); 4 Feb 2013 08:47:26 -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; 4 Feb 2013 08:47:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 08:47:25 +0000
Message-Id: <510F83AA02000078000BB64A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 08:47:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>,"Jan Beulich" <JBeulich@suse.com>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de> <20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
In-Reply-To: <510F7D9902000078000BB63F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 09:21, "Jan Beulich" <JBeulich@suse.com> wrote:
> Looking over the changes again (and without having looked at
> the Linux side yet again), I think the most likely candidates for
> reverting are
> 
> 26457:aa82638d58b0 (x86/HVM: consolidate toggling of RTC IRQ)
> 26461:78e91e9e4d61 (x86/HVM: generalize IRQ raising on RTC_REG_B writes)

Actually, one possibility occurred to me right after sending the
earlier response - could you give the patch below a try?

Jan

--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -55,6 +55,8 @@ static void rtc_toggle_irq(RTCState *s)
     struct domain *d = vrtc_domain(s);
 
     ASSERT(spin_is_locked(&s->lock));
+    if ( s->hw.cmos_data[RTC_REG_C] & RTC_IRQF )
+        return;
     s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
     hvm_isa_irq_deassert(d, RTC_IRQ);
     hvm_isa_irq_assert(d, RTC_IRQ);



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 08:57:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08: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 1U2Hra-0006Dx-Di; Mon, 04 Feb 2013 08:57:18 +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 1U2HrY-0006Ds-U1
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:57:17 +0000
Received: from [193.109.254.147:62342] by server-16.bemta-14.messagelabs.com
	id 23/73-25906-BE77F015; Mon, 04 Feb 2013 08:57:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1359968199!8903978!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9054 invoked from network); 4 Feb 2013 08:56:40 -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; 4 Feb 2013 08:56:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 08:56:38 +0000
Message-Id: <510F85D302000078000BB65E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 08:56:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, konrad.wilk@oracle.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
 xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.01.13 at 15:47, Wei Liu <wei.liu2@citrix.com> wrote:
> @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
>  void xen_callback_vector(void) {}
>  #endif
>  
> +static int xen_event_channel_register_3level(void)
> +{
> +	evtchn_register_nlevel_t reg;
> +	int i, cpu;
> +	unsigned long *_evtchn_pending = NULL;
> +	unsigned long *_evtchn_mask = NULL;
> +	unsigned long *l2sel_mfns = NULL;
> +	unsigned long *l2sel_offsets = NULL;
> +	int rc;
> +
> +	/* If we come from restore path, we don't need to allocate
> +	 * pages.
> +	 */
> +	if (!evtchn_pending && !evtchn_mask) {
> +		evtchn_pending =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		evtchn_mask =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		if (!evtchn_pending || !evtchn_mask) {
> +			free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +			free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);

free_pages() takes an order just like __get_free_pages() does.

> +			evtchn_pending = NULL;
> +			evtchn_mask = NULL;
> +			rc = -ENOMEM;
> +			goto err;
> +		}
> +	}
> +
> +	rc = -ENOMEM; /* Common error code for following operations */
> +#define __ALLOC_ARRAY(_ptr, _nr)					\
> +	do {								\
> +		(_ptr) = kzalloc(sizeof(unsigned long) * (_nr),		\
> +				 GFP_KERNEL);				\
> +		if (!(_ptr))						\
> +			goto out;					\
> +	} while (0)
> +
> +	__ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
> +	__ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
> +#undef __ALLOC_ARRAY
> +
> +	memset(&reg, 0, sizeof(reg));
> +
> +	for (i = 0; i < BITMAP_NR_PAGES; i++) {
> +		unsigned long offset = PAGE_SIZE * i;
> +		_evtchn_pending[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_pending+offset));
> +		_evtchn_mask[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_mask+offset));
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		l2sel_mfns[cpu] =
> +			arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
> +		l2sel_offsets[cpu] =
> +			offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
> +	}
> +
> +	reg.u.l3.nr_pages = BITMAP_NR_PAGES;
> +	reg.u.l3.evtchn_pending = _evtchn_pending;
> +	reg.u.l3.evtchn_mask = _evtchn_mask;
> +
> +	reg.u.l3.nr_vcpus = nr_cpu_ids;
> +	reg.u.l3.l2sel_mfns = l2sel_mfns;
> +	reg.u.l3.l2sel_offsets = l2sel_offsets;
> +
> +	reg.level = 3;
> +
> +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> +	if (rc) {
> +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);

Same here.

Jan

> +		evtchn_pending = NULL;
> +		evtchn_mask = NULL;
> +	}
> +
> +out:
> +	kfree(_evtchn_pending);
> +	kfree(_evtchn_mask);
> +	kfree(l2sel_mfns);
> +	kfree(l2sel_offsets);
> +err:
> +	return rc;
> +}
> +
>  void __init xen_init_IRQ(void)
>  {
>  	int i, rc;
> -- 
> 1.7.10.4




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

From xen-devel-bounces@lists.xen.org Mon Feb 04 08:57:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 08: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 1U2Hra-0006Dx-Di; Mon, 04 Feb 2013 08:57:18 +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 1U2HrY-0006Ds-U1
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 08:57:17 +0000
Received: from [193.109.254.147:62342] by server-16.bemta-14.messagelabs.com
	id 23/73-25906-BE77F015; Mon, 04 Feb 2013 08:57:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1359968199!8903978!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9054 invoked from network); 4 Feb 2013 08:56:40 -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; 4 Feb 2013 08:56:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 08:56:38 +0000
Message-Id: <510F85D302000078000BB65E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 08:56:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, konrad.wilk@oracle.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
 xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.01.13 at 15:47, Wei Liu <wei.liu2@citrix.com> wrote:
> @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
>  void xen_callback_vector(void) {}
>  #endif
>  
> +static int xen_event_channel_register_3level(void)
> +{
> +	evtchn_register_nlevel_t reg;
> +	int i, cpu;
> +	unsigned long *_evtchn_pending = NULL;
> +	unsigned long *_evtchn_mask = NULL;
> +	unsigned long *l2sel_mfns = NULL;
> +	unsigned long *l2sel_offsets = NULL;
> +	int rc;
> +
> +	/* If we come from restore path, we don't need to allocate
> +	 * pages.
> +	 */
> +	if (!evtchn_pending && !evtchn_mask) {
> +		evtchn_pending =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		evtchn_mask =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		if (!evtchn_pending || !evtchn_mask) {
> +			free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +			free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);

free_pages() takes an order just like __get_free_pages() does.

> +			evtchn_pending = NULL;
> +			evtchn_mask = NULL;
> +			rc = -ENOMEM;
> +			goto err;
> +		}
> +	}
> +
> +	rc = -ENOMEM; /* Common error code for following operations */
> +#define __ALLOC_ARRAY(_ptr, _nr)					\
> +	do {								\
> +		(_ptr) = kzalloc(sizeof(unsigned long) * (_nr),		\
> +				 GFP_KERNEL);				\
> +		if (!(_ptr))						\
> +			goto out;					\
> +	} while (0)
> +
> +	__ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
> +	__ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
> +#undef __ALLOC_ARRAY
> +
> +	memset(&reg, 0, sizeof(reg));
> +
> +	for (i = 0; i < BITMAP_NR_PAGES; i++) {
> +		unsigned long offset = PAGE_SIZE * i;
> +		_evtchn_pending[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_pending+offset));
> +		_evtchn_mask[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_mask+offset));
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		l2sel_mfns[cpu] =
> +			arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
> +		l2sel_offsets[cpu] =
> +			offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
> +	}
> +
> +	reg.u.l3.nr_pages = BITMAP_NR_PAGES;
> +	reg.u.l3.evtchn_pending = _evtchn_pending;
> +	reg.u.l3.evtchn_mask = _evtchn_mask;
> +
> +	reg.u.l3.nr_vcpus = nr_cpu_ids;
> +	reg.u.l3.l2sel_mfns = l2sel_mfns;
> +	reg.u.l3.l2sel_offsets = l2sel_offsets;
> +
> +	reg.level = 3;
> +
> +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> +	if (rc) {
> +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);

Same here.

Jan

> +		evtchn_pending = NULL;
> +		evtchn_mask = NULL;
> +	}
> +
> +out:
> +	kfree(_evtchn_pending);
> +	kfree(_evtchn_mask);
> +	kfree(l2sel_mfns);
> +	kfree(l2sel_offsets);
> +err:
> +	return rc;
> +}
> +
>  void __init xen_init_IRQ(void)
>  {
>  	int i, rc;
> -- 
> 1.7.10.4




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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:01:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2Hv5-0006Nq-F1; Mon, 04 Feb 2013 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 <JBeulich@suse.com>) id 1U2Hv3-0006Nk-Dl
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:00:53 +0000
Received: from [193.109.254.147:46070] by server-5.bemta-14.messagelabs.com id
	ED/95-21539-4C87F015; Mon, 04 Feb 2013 09:00:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359968449!8459057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21497 invoked from network); 4 Feb 2013 09:00:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:00:49 +0000
Message-Id: <510F86CE02000078000BB665@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:00:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643384-29392-5-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 04/16] Move event channel macros / struct
 definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.01.13 at 15:42, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -557,6 +557,8 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
>  #define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define EVTCHNS_PER_BUCKET 128
> +#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)

These aren't part of the hypercall ABI, and hence don't belong here.
What is preventing you from putting them alongside the other
stuff you move to xen/include/xen/event.h?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:01:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2Hv5-0006Nq-F1; Mon, 04 Feb 2013 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 <JBeulich@suse.com>) id 1U2Hv3-0006Nk-Dl
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:00:53 +0000
Received: from [193.109.254.147:46070] by server-5.bemta-14.messagelabs.com id
	ED/95-21539-4C87F015; Mon, 04 Feb 2013 09:00:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359968449!8459057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21497 invoked from network); 4 Feb 2013 09:00:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:00:49 +0000
Message-Id: <510F86CE02000078000BB665@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:00:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643384-29392-5-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 04/16] Move event channel macros / struct
 definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.01.13 at 15:42, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -557,6 +557,8 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
>  #define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define EVTCHNS_PER_BUCKET 128
> +#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)

These aren't part of the hypercall ABI, and hence don't belong here.
What is preventing you from putting them alongside the other
stuff you move to xen/include/xen/event.h?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:04:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2HyF-0006Yy-95; Mon, 04 Feb 2013 09:04:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andia@pereslavl.ru>) id 1U2GPz-0004f7-Ic
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 07:24:43 +0000
Received: from [85.158.138.51:2594] by server-2.bemta-3.messagelabs.com id
	17/9A-25961-A326F015; Mon, 04 Feb 2013 07:24:42 +0000
X-Env-Sender: andia@pereslavl.ru
X-Msg-Ref: server-3.tower-174.messagelabs.com!1359962681!20591962!1
X-Originating-IP: [95.129.137.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24893 invoked from network); 4 Feb 2013 07:24:41 -0000
Received: from mail.botik.ru (HELO mail.botik.ru) (95.129.137.166)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Feb 2013 07:24:41 -0000
Received: from connect.botik.ru ([192.168.192.114]:34647)
	by mail.botik.ru with esmtps (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <andia@pereslavl.ru>) id 1U2GPt-00024m-1M
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:24:39 +0400
Message-ID: <1359962676.5263.71.camel@connect.botik.ru>
From: "Elena V. Titova" <andia@pereslavl.ru>
To: xen-devel@lists.xen.org
Date: Mon, 04 Feb 2013 11:24:36 +0400
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-Mailman-Approved-At: Mon, 04 Feb 2013 09:04:10 +0000
Subject: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful live migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andia@pereslavl.ru
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.

We use debian sarge, linux-image-3.2.0-3-amd64 and xen-4.1.3 on our
servers.
When a live migration is run the guest domain may not resume on a
destination
host and is destroyed on a source host.
This patch fixes it by resuming the guest domain on a source host when a
start of
the guest domain was failed.

git diff tools/python/xen/xend/XendCheckpoint.py
diff --git a/tools/python/xen/xend/XendCheckpoint.py
b/tools/python/xen/xend/XendCheckpoint.py
index fa09757..6b8765f 100644
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -163,12 +163,16 @@ def save(fd, dominfo, network, live, dst,
checkpoint=False, node=-1,sock=None):
             dominfo.resumeDomain()
         else:
             if live and sock != None:
+                status = os.read(fd, 64) 
                 try:
                     sock.shutdown(2)
                 except:
                     pass
                 sock.close()

+                if status == "FAIL":
+                    raise XendError("Restore failed")
+
             dominfo.destroy()
             dominfo.testDeviceComplete()
         try:
@@ -351,8 +355,14 @@ def restore(xd, fd, dominfo = None, paused = False,
relocating = False):
         if not paused:
             dominfo.unpause()

+        if relocating:
+            os.write(fd, "SUCCESS")
+
         return dominfo
     except Exception, exn:
+        if relocating:
+            os.write(fd, "FAIL")
+
         dominfo.destroy()
         log.exception(exn)
         raise exn 

--
Elena Titova


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:04:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2HyF-0006Yy-95; Mon, 04 Feb 2013 09:04:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andia@pereslavl.ru>) id 1U2GPz-0004f7-Ic
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 07:24:43 +0000
Received: from [85.158.138.51:2594] by server-2.bemta-3.messagelabs.com id
	17/9A-25961-A326F015; Mon, 04 Feb 2013 07:24:42 +0000
X-Env-Sender: andia@pereslavl.ru
X-Msg-Ref: server-3.tower-174.messagelabs.com!1359962681!20591962!1
X-Originating-IP: [95.129.137.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24893 invoked from network); 4 Feb 2013 07:24:41 -0000
Received: from mail.botik.ru (HELO mail.botik.ru) (95.129.137.166)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Feb 2013 07:24:41 -0000
Received: from connect.botik.ru ([192.168.192.114]:34647)
	by mail.botik.ru with esmtps (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <andia@pereslavl.ru>) id 1U2GPt-00024m-1M
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:24:39 +0400
Message-ID: <1359962676.5263.71.camel@connect.botik.ru>
From: "Elena V. Titova" <andia@pereslavl.ru>
To: xen-devel@lists.xen.org
Date: Mon, 04 Feb 2013 11:24:36 +0400
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-Mailman-Approved-At: Mon, 04 Feb 2013 09:04:10 +0000
Subject: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful live migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andia@pereslavl.ru
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.

We use debian sarge, linux-image-3.2.0-3-amd64 and xen-4.1.3 on our
servers.
When a live migration is run the guest domain may not resume on a
destination
host and is destroyed on a source host.
This patch fixes it by resuming the guest domain on a source host when a
start of
the guest domain was failed.

git diff tools/python/xen/xend/XendCheckpoint.py
diff --git a/tools/python/xen/xend/XendCheckpoint.py
b/tools/python/xen/xend/XendCheckpoint.py
index fa09757..6b8765f 100644
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -163,12 +163,16 @@ def save(fd, dominfo, network, live, dst,
checkpoint=False, node=-1,sock=None):
             dominfo.resumeDomain()
         else:
             if live and sock != None:
+                status = os.read(fd, 64) 
                 try:
                     sock.shutdown(2)
                 except:
                     pass
                 sock.close()

+                if status == "FAIL":
+                    raise XendError("Restore failed")
+
             dominfo.destroy()
             dominfo.testDeviceComplete()
         try:
@@ -351,8 +355,14 @@ def restore(xd, fd, dominfo = None, paused = False,
relocating = False):
         if not paused:
             dominfo.unpause()

+        if relocating:
+            os.write(fd, "SUCCESS")
+
         return dominfo
     except Exception, exn:
+        if relocating:
+            os.write(fd, "FAIL")
+
         dominfo.destroy()
         log.exception(exn)
         raise exn 

--
Elena Titova


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:23:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2IGj-0006n4-2U; Mon, 04 Feb 2013 09:23:17 +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 1U2IGh-0006mz-Dx
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:23:15 +0000
Received: from [85.158.143.99:52777] by server-1.bemta-4.messagelabs.com id
	02/65-08839-20E7F015; Mon, 04 Feb 2013 09:23:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1359969793!29709413!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18344 invoked from network); 4 Feb 2013 09:23:14 -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; 4 Feb 2013 09:23:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:23:13 +0000
Message-Id: <510F8C0E02000078000BB67C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:23:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

>>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
> +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
> +                            xen_pfn_t *mask, int nr_pages)
> +{
> +    int rc;
> +    void *mapping;
> +    struct page_info *pginfo;
> +    unsigned long gfn;
> +    int pending_count = 0, mask_count = 0;
> +
> +#define __MAP(src, dst, cnt)                                    \
> +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
> +    {                                                           \
> +        rc = -EINVAL;                                           \
> +        gfn = (src)[(cnt)];                                     \
> +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
> +        if ( !pginfo )                                          \
> +            goto err;                                           \
> +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
> +        {                                                       \
> +            put_page(pginfo);                                   \
> +            goto err;                                           \
> +        }                                                       \
> +        mapping = __map_domain_page_global(pginfo);             \
> +        if ( !mapping )                                         \
> +        {                                                       \
> +            put_page_and_type(pginfo);                          \
> +            rc = -ENOMEM;                                       \
> +            goto err;                                           \
> +        }                                                       \
> +        (dst)[(cnt)] = mapping;                                 \
> +    }
> +
> +    __MAP(pending, d->evtchn_pending, pending_count)
> +    __MAP(mask, d->evtchn_mask, mask_count)
> +#undef __MAP
> +
> +    rc = 0;
> +
> + err:
> +    return rc;
> +}

So this alone already is up to 16 pages per guest, and hence a
theoretical maximum of 512k pages, i.e. 2G mapped space. The
global page mapping area, however, is only 1Gb in size on x86-64
(didn't check ARM at all)... Which is why I said that you need to
at least explain why bumping that address range isn't necessary
(i.e. if we think that we really don't want to support the
maximum number of guests allowed in theory, and that their
amount is really always going to be low enough to also not run
into resource conflicts with other users of the interface).

> +static long evtchn_register_3level(evtchn_register_3level_t *arg)
> +{
> +    struct domain *d = current->domain;
> +    struct vcpu *v;
> +    int rc = 0;
> +    xen_pfn_t evtchn_pending[EVTCHN_MAX_L3_PAGES];
> +    xen_pfn_t evtchn_mask[EVTCHN_MAX_L3_PAGES];
> +    xen_pfn_t l2sel_mfn = 0;
> +    xen_pfn_t l2sel_offset = 0;
> +
> +    if ( d->evtchn_level == EVTCHN_3_LEVEL )
> +    {
> +        rc = -EINVAL;
> +        goto out;
> +    }
> +
> +    if ( arg->nr_vcpus > d->max_vcpus ||
> +         arg->nr_pages > EVTCHN_MAX_L3_PAGES )
> +    {
> +        rc = -EINVAL;
> +        goto out;
> +    }
> +
> +    memset(evtchn_pending, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
> +    memset(evtchn_mask, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
> +
> +#define __COPY_ARRAY(_d, _s, _nr)                                       \
> +    do {                                                                \
> +        if ( copy_from_guest((_d), (_s), (_nr)) )                       \
> +        {                                                               \
> +            rc = -EFAULT;                                               \
> +            goto out;                                                   \
> +        }                                                               \
> +    } while (0)
> +    __COPY_ARRAY(evtchn_pending, arg->evtchn_pending, arg->nr_pages);
> +    __COPY_ARRAY(evtchn_mask, arg->evtchn_mask, arg->nr_pages);
> +#undef __COPY_ARRAY

I don't think this really benefits from using the __COPY_ARRAY()
macro.

Jan

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:23:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2IGj-0006n4-2U; Mon, 04 Feb 2013 09:23:17 +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 1U2IGh-0006mz-Dx
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:23:15 +0000
Received: from [85.158.143.99:52777] by server-1.bemta-4.messagelabs.com id
	02/65-08839-20E7F015; Mon, 04 Feb 2013 09:23:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1359969793!29709413!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18344 invoked from network); 4 Feb 2013 09:23:14 -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; 4 Feb 2013 09:23:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:23:13 +0000
Message-Id: <510F8C0E02000078000BB67C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:23:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

>>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
> +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
> +                            xen_pfn_t *mask, int nr_pages)
> +{
> +    int rc;
> +    void *mapping;
> +    struct page_info *pginfo;
> +    unsigned long gfn;
> +    int pending_count = 0, mask_count = 0;
> +
> +#define __MAP(src, dst, cnt)                                    \
> +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
> +    {                                                           \
> +        rc = -EINVAL;                                           \
> +        gfn = (src)[(cnt)];                                     \
> +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
> +        if ( !pginfo )                                          \
> +            goto err;                                           \
> +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
> +        {                                                       \
> +            put_page(pginfo);                                   \
> +            goto err;                                           \
> +        }                                                       \
> +        mapping = __map_domain_page_global(pginfo);             \
> +        if ( !mapping )                                         \
> +        {                                                       \
> +            put_page_and_type(pginfo);                          \
> +            rc = -ENOMEM;                                       \
> +            goto err;                                           \
> +        }                                                       \
> +        (dst)[(cnt)] = mapping;                                 \
> +    }
> +
> +    __MAP(pending, d->evtchn_pending, pending_count)
> +    __MAP(mask, d->evtchn_mask, mask_count)
> +#undef __MAP
> +
> +    rc = 0;
> +
> + err:
> +    return rc;
> +}

So this alone already is up to 16 pages per guest, and hence a
theoretical maximum of 512k pages, i.e. 2G mapped space. The
global page mapping area, however, is only 1Gb in size on x86-64
(didn't check ARM at all)... Which is why I said that you need to
at least explain why bumping that address range isn't necessary
(i.e. if we think that we really don't want to support the
maximum number of guests allowed in theory, and that their
amount is really always going to be low enough to also not run
into resource conflicts with other users of the interface).

> +static long evtchn_register_3level(evtchn_register_3level_t *arg)
> +{
> +    struct domain *d = current->domain;
> +    struct vcpu *v;
> +    int rc = 0;
> +    xen_pfn_t evtchn_pending[EVTCHN_MAX_L3_PAGES];
> +    xen_pfn_t evtchn_mask[EVTCHN_MAX_L3_PAGES];
> +    xen_pfn_t l2sel_mfn = 0;
> +    xen_pfn_t l2sel_offset = 0;
> +
> +    if ( d->evtchn_level == EVTCHN_3_LEVEL )
> +    {
> +        rc = -EINVAL;
> +        goto out;
> +    }
> +
> +    if ( arg->nr_vcpus > d->max_vcpus ||
> +         arg->nr_pages > EVTCHN_MAX_L3_PAGES )
> +    {
> +        rc = -EINVAL;
> +        goto out;
> +    }
> +
> +    memset(evtchn_pending, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
> +    memset(evtchn_mask, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
> +
> +#define __COPY_ARRAY(_d, _s, _nr)                                       \
> +    do {                                                                \
> +        if ( copy_from_guest((_d), (_s), (_nr)) )                       \
> +        {                                                               \
> +            rc = -EFAULT;                                               \
> +            goto out;                                                   \
> +        }                                                               \
> +    } while (0)
> +    __COPY_ARRAY(evtchn_pending, arg->evtchn_pending, arg->nr_pages);
> +    __COPY_ARRAY(evtchn_mask, arg->evtchn_mask, arg->nr_pages);
> +#undef __COPY_ARRAY

I don't think this really benefits from using the __COPY_ARRAY()
macro.

Jan

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:27:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09:27: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 1U2IKo-0006vH-Og; Mon, 04 Feb 2013 09:27:30 +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 1U2IKn-0006vB-9z
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:27:29 +0000
Received: from [85.158.143.99:18022] by server-3.bemta-4.messagelabs.com id
	8D/7B-08920-00F7F015; Mon, 04 Feb 2013 09:27:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1359970046!29808839!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20096 invoked from network); 4 Feb 2013 09:27:26 -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; 4 Feb 2013 09:27:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:27:26 +0000
Message-Id: <510F8D0B02000078000BB681@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:27:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> Updated set of patches for coverage.
> Changes:
> - implemented way of getting information
> - use only 2 parameter in hypercall (still not sure it's better to use
>   sysctl)
> - use "coverage" for configuration option as suggested by Ian Campbell
> - split header in include/public/gcov.h and include/xen/gcov.h to allow
>   tools to include public header
> - use weak to avoid defining compat_coverage_op

While probably not formally documented anywhere, we decided
against using weak some time ago.

Furthermore, iirc I already told you that with a suitably defined
interface you won't need a compat variant at all (and in particular
that would be the case if you went the sysctl route, as was
suggested to you).

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:27:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09:27: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 1U2IKo-0006vH-Og; Mon, 04 Feb 2013 09:27:30 +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 1U2IKn-0006vB-9z
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:27:29 +0000
Received: from [85.158.143.99:18022] by server-3.bemta-4.messagelabs.com id
	8D/7B-08920-00F7F015; Mon, 04 Feb 2013 09:27:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1359970046!29808839!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20096 invoked from network); 4 Feb 2013 09:27:26 -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; 4 Feb 2013 09:27:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:27:26 +0000
Message-Id: <510F8D0B02000078000BB681@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:27:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> Updated set of patches for coverage.
> Changes:
> - implemented way of getting information
> - use only 2 parameter in hypercall (still not sure it's better to use
>   sysctl)
> - use "coverage" for configuration option as suggested by Ian Campbell
> - split header in include/public/gcov.h and include/xen/gcov.h to allow
>   tools to include public header
> - use weak to avoid defining compat_coverage_op

While probably not formally documented anywhere, we decided
against using weak some time ago.

Furthermore, iirc I already told you that with a suitably defined
interface you won't need a compat variant at all (and in particular
that would be the case if you went the sysctl route, as was
suggested to you).

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:40:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2IWx-00079S-NS; Mon, 04 Feb 2013 09:40:03 +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 1U2IWv-000793-NP
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:40:02 +0000
Received: from [85.158.137.99:14088] by server-4.bemta-3.messagelabs.com id
	F2/C5-12802-FE18F015; Mon, 04 Feb 2013 09:39:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1359970793!19835488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28802 invoked from network); 4 Feb 2013 09:39:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:39:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:39:53 +0000
Message-Id: <510F8FF502000078000BB69C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:39:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -228,3 +228,7 @@ QEMU_TAG ?= 2a1354d655d816feaad7dbdb8364f40a208439c1
>  # doing and are prepared for some pain.
>  
>  CONFIG_TESTS       ?= y
> +
> +# Test coverage support
> +coverage ?= n
> +

Alongside debug and debug_symbols please.

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
>  
>  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
>  
> +

Stray blank line.

> +ifeq ($(coverage),y)
> +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> +endif

For one - isn't simply using $(obj-y) here sufficient (i.e. without the
$(filter-out ...))?

And second, I would thing this then ought to become a single line:

$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE

> --- /dev/null
> +++ b/xen/common/gcov/Makefile
> @@ -0,0 +1,5 @@
> +ifneq ($(coverage),y)
> +obj-y += nogcov.o
> +endif
> +obj-$(coverage) += gcov.o
> +

How about

obj-y := nogcov.o
obj-$(coverage) := gcov.o


> +typedef void (*ctor_func_t)(void);
> +extern struct
> +{
> +    unsigned long count;
> +    ctor_func_t funcs[1];
> +} __CTOR_LIST__;

const?

> +
> +void init_coverage(void)

__init

> --- /dev/null
> +++ b/xen/include/public/gcov.h
> @@ -0,0 +1,93 @@
> +/*
> + *  Profiling infrastructure declarations.
> + *
> + *  This file is based on gcc-internal definitions. Data structures are
> + *  defined to be compatible with gcc counterparts. For a better
> + *  understanding, refer to gcc source: gcc/gcov-io.h.
> + *
> + *    Copyright IBM Corp. 2009
> + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> + *
> + *    Uses gcc-internal data definitions.
> + */
> +
> +#ifndef XEN_PUBLIC_GCOV_H
> +#define XEN_PUBLIC_GCOV_H XEN_PUBLIC_GCOV_H
> +
> +/*
> + * Profiling data types used for gcc 3.4 and above - these are defined by
> + * gcc and need to be kept as close to the original definition as possible to
> + * remain compatible.
> + */
> +#define GCOV_COUNTERS         5
> +#define GCOV_DATA_MAGIC       ((unsigned int) 0x67636461)
> +#define GCOV_TAG_FUNCTION     ((unsigned int) 0x01000000)
> +#define GCOV_TAG_COUNTER_BASE ((unsigned int) 0x01a10000)
> +#define GCOV_TAG_FOR_COUNTER(count) \
> +    (GCOV_TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
> +
> +#if BITS_PER_LONG >= 64
> +typedef long gcov_type;
> +#else
> +typedef long long gcov_type;
> +#endif

What's this???

> +/**
> + * struct gcov_ctr_info - profiling data per counter type
> + * @num: number of counter values for this type
> + * @values: array of counter values for this type
> + * @merge: merge function for counter values of this type (unused)
> + *
> + * This data is generated by gcc during compilation and doesn't change
> + * at run-time with the exception of the values array.
> + */
> +struct gcov_ctr_info
> +{
> +    unsigned int num;
> +    gcov_type *values;
> +    void (*merge)(gcov_type *, unsigned int);
> +};

Pointers, and even more so function ones, can't be part of the
public interface.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:40:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2IWx-00079S-NS; Mon, 04 Feb 2013 09:40:03 +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 1U2IWv-000793-NP
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:40:02 +0000
Received: from [85.158.137.99:14088] by server-4.bemta-3.messagelabs.com id
	F2/C5-12802-FE18F015; Mon, 04 Feb 2013 09:39:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1359970793!19835488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28802 invoked from network); 4 Feb 2013 09:39:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:39:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:39:53 +0000
Message-Id: <510F8FF502000078000BB69C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:39:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -228,3 +228,7 @@ QEMU_TAG ?= 2a1354d655d816feaad7dbdb8364f40a208439c1
>  # doing and are prepared for some pain.
>  
>  CONFIG_TESTS       ?= y
> +
> +# Test coverage support
> +coverage ?= n
> +

Alongside debug and debug_symbols please.

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
>  
>  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
>  
> +

Stray blank line.

> +ifeq ($(coverage),y)
> +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> +endif

For one - isn't simply using $(obj-y) here sufficient (i.e. without the
$(filter-out ...))?

And second, I would thing this then ought to become a single line:

$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE

> --- /dev/null
> +++ b/xen/common/gcov/Makefile
> @@ -0,0 +1,5 @@
> +ifneq ($(coverage),y)
> +obj-y += nogcov.o
> +endif
> +obj-$(coverage) += gcov.o
> +

How about

obj-y := nogcov.o
obj-$(coverage) := gcov.o


> +typedef void (*ctor_func_t)(void);
> +extern struct
> +{
> +    unsigned long count;
> +    ctor_func_t funcs[1];
> +} __CTOR_LIST__;

const?

> +
> +void init_coverage(void)

__init

> --- /dev/null
> +++ b/xen/include/public/gcov.h
> @@ -0,0 +1,93 @@
> +/*
> + *  Profiling infrastructure declarations.
> + *
> + *  This file is based on gcc-internal definitions. Data structures are
> + *  defined to be compatible with gcc counterparts. For a better
> + *  understanding, refer to gcc source: gcc/gcov-io.h.
> + *
> + *    Copyright IBM Corp. 2009
> + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> + *
> + *    Uses gcc-internal data definitions.
> + */
> +
> +#ifndef XEN_PUBLIC_GCOV_H
> +#define XEN_PUBLIC_GCOV_H XEN_PUBLIC_GCOV_H
> +
> +/*
> + * Profiling data types used for gcc 3.4 and above - these are defined by
> + * gcc and need to be kept as close to the original definition as possible to
> + * remain compatible.
> + */
> +#define GCOV_COUNTERS         5
> +#define GCOV_DATA_MAGIC       ((unsigned int) 0x67636461)
> +#define GCOV_TAG_FUNCTION     ((unsigned int) 0x01000000)
> +#define GCOV_TAG_COUNTER_BASE ((unsigned int) 0x01a10000)
> +#define GCOV_TAG_FOR_COUNTER(count) \
> +    (GCOV_TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
> +
> +#if BITS_PER_LONG >= 64
> +typedef long gcov_type;
> +#else
> +typedef long long gcov_type;
> +#endif

What's this???

> +/**
> + * struct gcov_ctr_info - profiling data per counter type
> + * @num: number of counter values for this type
> + * @values: array of counter values for this type
> + * @merge: merge function for counter values of this type (unused)
> + *
> + * This data is generated by gcc during compilation and doesn't change
> + * at run-time with the exception of the values array.
> + */
> +struct gcov_ctr_info
> +{
> +    unsigned int num;
> +    gcov_type *values;
> +    void (*merge)(gcov_type *, unsigned int);
> +};

Pointers, and even more so function ones, can't be part of the
public interface.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:48:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2Ief-0007iF-AX; Mon, 04 Feb 2013 09:48:01 +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 1U2Ied-0007i7-Lc
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:47:59 +0000
Received: from [193.109.254.147:43633] by server-16.bemta-14.messagelabs.com
	id 40/85-25906-FC38F015; Mon, 04 Feb 2013 09:47:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1359971262!9462322!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14437 invoked from network); 4 Feb 2013 09:47:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:47:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:47:41 +0000
Message-Id: <510F91CA02000078000BB6AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:47:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
In-Reply-To: <CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Milan opath <milan.opath@gmail.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 04.02.13 at 01:57, Ben Guthro <ben@guthro.net> wrote:
> I'm not sure what Arch linux uses for a kernel, as I'm not terribly
> familiar with the distro.
> 
> That said, a number of things are needed to get this to work, that are
> not accepted upstream.
> 
> 1. You'll need one of Konrad's acpi-s3 branches, or the patches from
> the tip of those branches:
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/h 
> eads/devel/acpi-s3.v9
> 
> 2. Apply the attached patches in the following order:
> fix-dmar-zap-reinstate

This one actually is in the staging tree already.

> fix-suspend-scheduler-v2
> fix-suspend-scheduler-revert-affinity-part
> s3-timerirq
> 
> All of these fixes have been proposed to the xen-devel list, but have
> not yet been accepted, for one reason, or another.

And I don't think comments on them have seen follow-ups.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:48:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09: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 1U2Ief-0007iF-AX; Mon, 04 Feb 2013 09:48:01 +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 1U2Ied-0007i7-Lc
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:47:59 +0000
Received: from [193.109.254.147:43633] by server-16.bemta-14.messagelabs.com
	id 40/85-25906-FC38F015; Mon, 04 Feb 2013 09:47:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1359971262!9462322!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14437 invoked from network); 4 Feb 2013 09:47:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:47:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 09:47:41 +0000
Message-Id: <510F91CA02000078000BB6AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 09:47:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
In-Reply-To: <CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Milan opath <milan.opath@gmail.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 04.02.13 at 01:57, Ben Guthro <ben@guthro.net> wrote:
> I'm not sure what Arch linux uses for a kernel, as I'm not terribly
> familiar with the distro.
> 
> That said, a number of things are needed to get this to work, that are
> not accepted upstream.
> 
> 1. You'll need one of Konrad's acpi-s3 branches, or the patches from
> the tip of those branches:
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/h 
> eads/devel/acpi-s3.v9
> 
> 2. Apply the attached patches in the following order:
> fix-dmar-zap-reinstate

This one actually is in the staging tree already.

> fix-suspend-scheduler-v2
> fix-suspend-scheduler-revert-affinity-part
> s3-timerirq
> 
> All of these fixes have been proposed to the xen-devel list, but have
> not yet been accepted, for one reason, or another.

And I don't think comments on them have seen follow-ups.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:50:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09:50: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 1U2IgN-0007qh-Ky; Mon, 04 Feb 2013 09:49:47 +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 1U2IgK-0007qQ-TN
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:49:46 +0000
Received: from [85.158.137.99:20876] by server-6.bemta-3.messagelabs.com id
	73/C7-29959-3348F015; Mon, 04 Feb 2013 09:49:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-217.messagelabs.com!1359971365!18983129!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26514 invoked from network); 4 Feb 2013 09:49:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:49:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo29) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u02cadp148qXWR ;
	Mon, 4 Feb 2013 10:49:10 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id DDB5A1884C; Mon,  4 Feb 2013 10:49:09 +0100 (CET)
Date: Mon, 4 Feb 2013 10:49:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204094909.GA2564@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de>
	<20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
	<510F83AA02000078000BB64A@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <510F83AA02000078000BB64A@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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=utf-8
Content-Disposition: inline

On Mon, Feb 04, Jan Beulich wrote:

> >>> On 04.02.13 at 09:21, "Jan Beulich" <JBeulich@suse.com> wrote:
> > Looking over the changes again (and without having looked at
> > the Linux side yet again), I think the most likely candidates for
> > reverting are
> > 
> > 26457:aa82638d58b0 (x86/HVM: consolidate toggling of RTC IRQ)
> > 26461:78e91e9e4d61 (x86/HVM: generalize IRQ raising on RTC_REG_B writes)
> 
> Actually, one possibility occurred to me right after sending the
> earlier response - could you give the patch below a try?

This patch leads also to a hang.
The initial boot of a HVM guest hangs in "Set System Time to the current
Hardware Clock", with the same backtrace in hpet_rtc_interrupt.
If the HVM guest is later migrated to localhost, the new guest hangs
also in hpet_rtc_interrupt.

I'm attaching the xen, dom0 and domU logs from a pvops kernel. sles
kernel will follow.

I will also try to revert the two changeset above.


Olaf

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="xl-dmesg.txt"

 __  __          
 \ \/ /___ _ __  
  \  // _ \ '_ \ 
  /  \  __/ | | |
 /_/\_\___|_| |_|
                 
  _  _    _____  ____   __  ____   ___ ____    ____   ___  _ _____  ___ ____  
 | || |  |___ / |___ \ / /_| ___| / _ \___ \  |___ \ / _ \/ |___ / / _ \___ \ 
 | || |_   |_ \   __) | '_ \___ \| | | |__) |__ __) | | | | | |_ \| | | |__) |
 |__   _| ___) | / __/| (_) |__) | |_| / __/|__/ __/| |_| | |___) | |_| / __/ 
    |_|(_)____(_)_____|\___/____/ \___/_____| |_____|\___/|_|____/ \___/_____|
                                                                              
   ___  _  _    ___   ___   ___   ___ ____ ____  
  / _ \| || |  / _ \ / _ \ / _ \ ( _ ) ___|___ \ 
 | | | | || |_| | | | (_) | | | |/ _ \___ \ __) |
 | |_| |__   _| |_| |\__, | |_| | (_) |__) / __/ 
  \___/   |_|(_)___/   /_/ \___/ \___/____/_____|
                                                 
(XEN) Xen version 4.3.26502-20130204.090852 (abuild@) (gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]) debug=y Mon Feb  4 09:12:15 UTC 2013
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: loglvl=all guest_loglvl=all console=com1,vga com1=57600,8n1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b000 (usable)
(XEN)  000000000009b000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000008c21c000 (usable)
(XEN)  000000008c21c000 - 000000008c2ef000 (ACPI NVS)
(XEN)  000000008c2ef000 - 000000008c3df000 (ACPI data)
(XEN)  000000008c3df000 - 000000008d7df000 (ACPI NVS)
(XEN)  000000008d7df000 - 000000008f302000 (ACPI data)
(XEN)  000000008f302000 - 000000008f34f000 (reserved)
(XEN)  000000008f34f000 - 000000008f3d4000 (ACPI data)
(XEN)  000000008f3d4000 - 000000008f3de000 (ACPI NVS)
(XEN)  000000008f3de000 - 000000008f3e2000 (ACPI data)
(XEN)  000000008f3e2000 - 000000008f4cf000 (ACPI NVS)
(XEN)  000000008f4cf000 - 000000008f500000 (ACPI data)
(XEN)  000000008f500000 - 0000000090000000 (reserved)
(XEN)  00000000a0000000 - 00000000b0000000 (reserved)
(XEN)  00000000fc000000 - 00000000fd000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000670000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 8F4FD120, 00A4 (r1 INTEL  S5520UT         0       1000013)
(XEN) ACPI: FACP 8F4FB000, 00F4 (r4 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: DSDT 8F4F4000, 65E9 (r2 INTEL  S5520UT         3 MSFT  100000D)
(XEN) ACPI: FACS 8F3E2000, 0040
(XEN) ACPI: APIC 8F4F3000, 01A8 (r2 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: MCFG 8F4F2000, 003C (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: HPET 8F4F1000, 0038 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SLIT 8F4F0000, 0030 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SRAT 8F4EF000, 0430 (r2 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SPCR 8F4EE000, 0050 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: WDDT 8F4ED000, 0040 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: SSDT 8F4D2000, 1AFC4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 8F4D1000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: TCPA 8F4D0000, 0032 (r0                        0             0)
(XEN) ACPI: HEST 8F4CF000, 00A8 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: BERT 8F3E1000, 0030 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: ERST 8F3E0000, 0230 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: EINJ 8F3DF000, 0130 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: DMAR 8F3DE000, 01A8 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) System RAM: 24513MB (25102044kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-90000000
(XEN) SRAT: Node 0 PXM 0 100000000-370000000
(XEN) SRAT: Node 1 PXM 1 370000000-670000000
(XEN) NUMA: Allocated memnodemap from 66dbe2000 - 66dbe3000
(XEN) NUMA: Using 16 for the hash shift.
(XEN) Domain heap initialised DMA width 31 bits
(XEN) found SMP MP-table at 000fdb60
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[8f3e200c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a401 base: 0xfed00000
(XEN) Xen ERST support is initialized.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 24 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2926.444 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control 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.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(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, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0xa43000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0x660f0
(XEN) elf_parse_binary: phdr: paddr=0x1c67000 memsz=0x13100
(XEN) elf_parse_binary: phdr: paddr=0x1c7b000 memsz=0x70d000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x2388000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81c7b210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff82388000
(XEN)     virt_entry       = 0xffffffff81c7b210
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2388000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000650000000->0000000658000000 (6122675 pages to be allocated)
(XEN)  Init. ramdisk: 000000066f195000->000000066ffff600
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82388000
(XEN)  Init. ramdisk: ffffffff82388000->ffffffff831f2600
(XEN)  Phys-Mach map: ffffffff831f3000->ffffffff860f08f0
(XEN)  Start info:    ffffffff860f1000->ffffffff860f14b4
(XEN)  Page tables:   ffffffff860f2000->ffffffff86127000
(XEN)  Boot stack:    ffffffff86127000->ffffffff86128000
(XEN)  TOTAL:         ffffffff80000000->ffffffff86400000
(XEN)  ENTRY ADDRESS: ffffffff81c7b210
(XEN) Dom0 has maximum 24 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81a43000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81c660f0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81c67000 -> 0xffffffff81c7a100
(XEN) elf_load_binary: phdr 3 at 0xffffffff81c7b000 -> 0xffffffff81d0e000
(XEN) Scrubbing Free RAM: .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 248kB init memory.
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add device 0000:00:10.0
(XEN) PCI add device 0000:00:10.1
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:00:13.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.2
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:01:00.1
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:02.0
(XEN) PCI add device 0000:06:04.0
(XEN) PCI add device 0000:09:00.0
(XEN) PCI add device 0000:0a:02.0
(XEN) PCI add device 0000:0a:04.0
(XEN) PCI add device 0000:0f:00.0
(XEN) PCI add device 0000:10:00.0
(XEN) PCI add device 0000:fe:00.0
(XEN) PCI add device 0000:fe:00.1
(XEN) PCI add device 0000:fe:02.0
(XEN) PCI add device 0000:fe:02.1
(XEN) PCI add device 0000:fe:02.2
(XEN) PCI add device 0000:fe:02.3
(XEN) PCI add device 0000:fe:02.4
(XEN) PCI add device 0000:fe:02.5
(XEN) PCI add device 0000:fe:03.0
(XEN) PCI add device 0000:fe:03.1
(XEN) PCI add device 0000:fe:03.2
(XEN) PCI add device 0000:fe:03.4
(XEN) PCI add device 0000:fe:04.0
(XEN) PCI add device 0000:fe:04.1
(XEN) PCI add device 0000:fe:04.2
(XEN) PCI add device 0000:fe:04.3
(XEN) PCI add device 0000:fe:05.0
(XEN) PCI add device 0000:fe:05.1
(XEN) PCI add device 0000:fe:05.2
(XEN) PCI add device 0000:fe:05.3
(XEN) PCI add device 0000:fe:06.0
(XEN) PCI add device 0000:fe:06.1
(XEN) PCI add device 0000:fe:06.2
(XEN) PCI add device 0000:fe:06.3
(XEN) PCI add device 0000:ff:00.0
(XEN) PCI add device 0000:ff:00.1
(XEN) PCI add device 0000:ff:02.0
(XEN) PCI add device 0000:ff:02.1
(XEN) PCI add device 0000:ff:02.2
(XEN) PCI add device 0000:ff:02.3
(XEN) PCI add device 0000:ff:02.4
(XEN) PCI add device 0000:ff:02.5
(XEN) PCI add device 0000:ff:03.0
(XEN) PCI add device 0000:ff:03.1
(XEN) PCI add device 0000:ff:03.2
(XEN) PCI add device 0000:ff:03.4
(XEN) PCI add device 0000:ff:04.0
(XEN) PCI add device 0000:ff:04.1
(XEN) PCI add device 0000:ff:04.2
(XEN) PCI add device 0000:ff:04.3
(XEN) PCI add device 0000:ff:05.0
(XEN) PCI add device 0000:ff:05.1
(XEN) PCI add device 0000:ff:05.2
(XEN) PCI add device 0000:ff:05.3
(XEN) PCI add device 0000:ff:06.0
(XEN) PCI add device 0000:ff:06.1
(XEN) PCI add device 0000:ff:06.2
(XEN) PCI add device 0000:ff:06.3
(XEN) HVM1: HVM Loader
(XEN) HVM1: Detected Xen v4.3.26502-20130204
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 4
(XEN) HVM1: System requested ROMBIOS
(XEN) HVM1: CPU speed is 2926 MHz
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 02:0 bar 10 size lx: 02000000
(XEN) HVM1: pci dev 03:0 bar 14 size lx: 01000000
(XEN) HVM1: pci dev 02:0 bar 14 size lx: 00001000
(XEN) HVM1: pci dev 03:0 bar 10 size lx: 00000100
(XEN) HVM1: pci dev 01:1 bar 20 size lx: 00000010
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1: Testing HVM environment:
(XEN) HVM1:  - REP INSB across page boundaries ... passed
(XEN) HVM1:  - GS base MSRs and SWAPGS ... passed
(XEN) HVM1: Passed 2 of 2 tests
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions:
(XEN) HVM1:   Relocating to 0xfc001000-0xfc0035bc ... done
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading Cirrus VGABIOS ...
(XEN) HVM1: Option ROMs:
(XEN) HVM1:  c0000-c8fff: VGA BIOS
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1: vm86 TSS at fc00f680
(XEN) HVM1: BIOS map:
(XEN) HVM1:  f0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [03]: 00000000:00100000 - 00000000:1f800000: RAM
(XEN) HVM1:  HOLE: 00000000:1f800000 - 00000000:fc000000
(XEN) HVM1:  [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1: Invoking ROMBIOS ...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM1: Bochs BIOS - build: 06/23/99
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM1: Options: apmbios pcibios eltorito PMM 
(XEN) HVM1: 
(XEN) HVM1: ata0-0: PCHS=2080/16/63 translation=large LCHS=520/64/63
(XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (1024 MBytes)
(XEN) HVM1: IDE time out
(XEN) HVM1: 
(XEN) HVM1: 
(XEN) HVM1: 
(XEN) HVM1: Press F12 for boot menu.
(XEN) HVM1: 
(XEN) HVM1: Booting from CD-Rom...
(XEN) HVM1: CDROM boot failure code : 0002
(XEN) HVM1: Boot from CD-Rom failed: could not read the boot disk
(XEN) HVM1: 
(XEN) HVM1: Booting from Hard Disk...
(XEN) HVM1: Booting from 0000:7c00
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM1: int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) HVM1: *** int 15h function AX=00c0, BX=0000 not yet supported!
(XEN) HVM1: *** int 15h function AX=ec00, BX=0002 not yet supported!
(XEN) HVM1: KBD: unsupported int 16h function 03
(XEN) HVM1: *** int 15h function AX=e980, BX=0000 not yet supported!
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=82
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=82
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=83
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=83
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=84
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=84
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=85
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=85
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=86
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=86
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=87
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=87
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 88
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 88
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 89
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 89
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8a
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8a
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8b
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8b
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8c
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8c
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8d
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8d
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8e
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8e
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8f
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8f
(XEN) irq.c:375: Dom1 callback via changed to Direct Vector 0xf3
(XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="dmesg-3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7.txt"

[    0.000000] Linux version 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 (abuild@build20) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Mon Feb 4 07:02:12 UTC 2013
[    0.000000] Command line: debug panic=9 sysrq=yes showopts log_buf_len=64M console=hvc0
[    0.000000] Freeing 9b-100 pfn range: 101 pages freed
[    0.000000] 1-1 mapping on 9b->100
[    0.000000] Freeing 8c21c-100000 pfn range: 474596 pages freed
[    0.000000] 1-1 mapping on 8c21c->100000
[    0.000000] Released 474697 pages of unused memory
[    0.000000] Set 474697 page(s) to 1-1 mapping
[    0.000000] Populating 5dfb1e-653967 pfn range: 474697 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009afff] usable
[    0.000000] Xen: [mem 0x000000000009b000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000008c21bfff] usable
[    0.000000] Xen: [mem 0x000000008c21c000-0x000000008c2eefff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008c2ef000-0x000000008c3defff] ACPI data
[    0.000000] Xen: [mem 0x000000008c3df000-0x000000008d7defff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008d7df000-0x000000008f301fff] ACPI data
[    0.000000] Xen: [mem 0x000000008f302000-0x000000008f34efff] reserved
[    0.000000] Xen: [mem 0x000000008f34f000-0x000000008f3d3fff] ACPI data
[    0.000000] Xen: [mem 0x000000008f3d4000-0x000000008f3ddfff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008f3de000-0x000000008f3e1fff] ACPI data
[    0.000000] Xen: [mem 0x000000008f3e2000-0x000000008f4cefff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008f4cf000-0x000000008f4fffff] ACPI data
[    0.000000] Xen: [mem 0x000000008f500000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000a0000000-0x00000000afffffff] reserved
[    0.000000] Xen: [mem 0x00000000fc000000-0x00000000fcffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fec90000-0x00000000fec90fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000066fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.5 present.
[    0.000000] DMI: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x670000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0x8c21c max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x031f2fff]
[    0.000000] Base memory trampoline at [ffff880000094000] 94000 size 28672
[    0.000000] init_memory_mapping: [mem 0x00000000-0x8c21bfff]
[    0.000000]  [mem 0x00000000-0x8c21bfff] page 4k
[    0.000000] kernel direct mapping tables up to 0x8c21bfff @ [mem 0x00b9a000-0x00ffffff]
[    0.000000] xen: setting RW the range fcc000 - 1000000
[    0.000000] init_memory_mapping: [mem 0x100000000-0x66fffffff]
[    0.000000]  [mem 0x100000000-0x66fffffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x66fffffff @ [mem 0x89685000-0x8c21bfff]
[    0.000000] xen: setting RW the range 8c21b000 - 8c21c000
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 2093540(99%)
[    0.000000] RAMDISK: [mem 0x02388000-0x031f2fff]
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000008f4fd120 000A4 (v01 INTEL  S5520UT  00000000      01000013)
[    0.000000] ACPI: FACP 000000008f4fb000 000F4 (v04 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000008f4f4000 065E9 (v02 INTEL  S5520UT  00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000008f3e2000 00040
[    0.000000] ACPI: APIC 000000008f4f3000 001A8 (v02 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000008f4f2000 0003C (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000008f4f1000 00038 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000008f4f0000 00030 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SRAT 000000008f4ef000 00430 (v02 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000008f4ee000 00050 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000008f4ed000 00040 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000008f4d2000 1AFC4 (v02  INTEL SSDT  PM 00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000008f4d1000 001D8 (v02  INTEL IPMI     00004000 INTL 20061109)
[    0.000000] ACPI: TCPA 000000008f4d0000 00032 (v00                 00000000      00000000)
[    0.000000] ACPI: HEST 000000008f4cf000 000A8 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000008f3e1000 00030 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000008f3e0000 00230 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000008f3df000 00130 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: XMAR 000000008f3de000 001A8 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x66fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009afff]
[    0.000000]   node   0: [mem 0x00100000-0x8c21bfff]
[    0.000000]   node   0: [mem 0x100000000-0x66fffffff]
[    0.000000] On node 0 totalpages: 6275495
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 1081 pages reserved
[    0.000000]   DMA zone: 2834 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 16320 pages used for memmap
[    0.000000]   DMA32 zone: 553564 pages, LIFO batch:31
[    0.000000]   Normal zone: 89088 pages used for memmap
[    0.000000]   Normal zone: 5612544 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 8/0x12 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 9/0x32 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 10/0x14 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 11/0x34 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 12/0x1 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 13/0x21 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 14/0x3 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 15/0x23 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 16/0x5 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 17/0x25 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 18/0x11 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 19/0x31 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 20/0x13 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 21/0x33 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 22/0x15 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 23/0x35 ignored.
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
[    0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a401 base: 0xfed00000
[    0.000000] smpboot: 24 Processors exceeds NR_CPUS limit of 8
[    0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 000000008c21c000 - 000000008c2ef000
[    0.000000] PM: Registered nosave memory: 000000008c2ef000 - 000000008c3df000
[    0.000000] PM: Registered nosave memory: 000000008c3df000 - 000000008d7df000
[    0.000000] PM: Registered nosave memory: 000000008d7df000 - 000000008f302000
[    0.000000] PM: Registered nosave memory: 000000008f302000 - 000000008f34f000
[    0.000000] PM: Registered nosave memory: 000000008f34f000 - 000000008f3d4000
[    0.000000] PM: Registered nosave memory: 000000008f3d4000 - 000000008f3de000
[    0.000000] PM: Registered nosave memory: 000000008f3de000 - 000000008f3e2000
[    0.000000] PM: Registered nosave memory: 000000008f3e2000 - 000000008f4cf000
[    0.000000] PM: Registered nosave memory: 000000008f4cf000 - 000000008f500000
[    0.000000] PM: Registered nosave memory: 000000008f500000 - 0000000090000000
[    0.000000] PM: Registered nosave memory: 0000000090000000 - 00000000a0000000
[    0.000000] PM: Registered nosave memory: 00000000a0000000 - 00000000b0000000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fc000000
[    0.000000] PM: Registered nosave memory: 00000000fc000000 - 00000000fd000000
[    0.000000] PM: Registered nosave memory: 00000000fd000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fec90000
[    0.000000] PM: Registered nosave memory: 00000000fec90000 - 00000000fec91000
[    0.000000] PM: Registered nosave memory: 00000000fec91000 - 00000000fed1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff800000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 0000000100000000
[    0.000000] e820: [mem 0xb0000000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.3.26502-20130204 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88064f600000 s78080 r8192 d24320 u262144
[    0.000000] pcpu-alloc: s78080 r8192 d24320 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    8.570118] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 6168942
[    8.570120] Kernel command line: debug panic=9 sysrq=yes showopts log_buf_len=64M console=hvc0
[    8.570177] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    8.575301] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    8.583181] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    8.585686] __ex_table already sorted, skipping sort
[    8.618817] software IO TLB [mem 0x62d102000-0x631101fff] (64MB) mapped at [ffff88062d102000-ffff880631101fff]
[    8.716651] Memory: 23932616k/27000832k available (6541k kernel code, 1898852k absent, 1169364k reserved, 6150k data, 636k init)
[    8.716739] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    8.716782] Hierarchical RCU implementation.
[    8.716792] NR_IRQS:4352 nr_irqs:1152 16
[    8.716855] xen: sci override: global_irq=9 trigger=0 polarity=0
[    8.716858] xen: registering gsi 9 triggering 0 polarity 0
[    8.716872] xen: --> pirq=9 -> irq=9 (gsi=9)
[    8.716904] xen: acpi sci 9
[    8.716908] xen: --> pirq=1 -> irq=1 (gsi=1)
[    8.716910] xen: --> pirq=2 -> irq=2 (gsi=2)
[    8.716913] xen: --> pirq=3 -> irq=3 (gsi=3)
[    8.716916] xen: --> pirq=4 -> irq=4 (gsi=4)
[    8.716918] xen: --> pirq=5 -> irq=5 (gsi=5)
[    8.716921] xen: --> pirq=6 -> irq=6 (gsi=6)
[    8.716923] xen: --> pirq=7 -> irq=7 (gsi=7)
[    8.716926] xen: --> pirq=8 -> irq=8 (gsi=8)
[    8.716928] xen: --> pirq=10 -> irq=10 (gsi=10)
[    8.716931] xen: --> pirq=11 -> irq=11 (gsi=11)
[    8.716934] xen: --> pirq=12 -> irq=12 (gsi=12)
[    8.716936] xen: --> pirq=13 -> irq=13 (gsi=13)
[    8.716939] xen: --> pirq=14 -> irq=14 (gsi=14)
[    8.716941] xen: --> pirq=15 -> irq=15 (gsi=15)
[    8.723114] Console: colour VGA+ 80x25
[    8.723624] console [hvc0] enabled
[    8.723646] Xen: using vcpuop timer interface
[    8.723653] installing Xen timer for CPU 0
[    8.723682] tsc: Detected 2926.444 MHz processor
[    8.723689] Calibrating delay loop (skipped), value calculated using timer frequency.. 5852.88 BogoMIPS (lpj=11705776)
[    8.723694] pid_max: default: 32768 minimum: 301
[    8.723734] Mount-cache hash table entries: 256
[    8.723976] CPU: Physical Processor ID: 0
[    8.723979] CPU: Processor Core ID: 0
[    8.723982] mce: CPU supports 2 MCE banks
[    8.723998] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    8.723998] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    8.723998] tlb_flushall_shift: 6
[    8.724094] Freeing SMP alternatives: 28k freed
[    8.724940] ACPI: Core revision 20120913
[    8.733214] Performance Events: unsupported p6 CPU model 44 no PMU driver, software events only.
[    8.733369] installing Xen timer for CPU 1
[    8.734623] installing Xen timer for CPU 2
[    8.735820] installing Xen timer for CPU 3
[    8.737059] installing Xen timer for CPU 4
[    8.738037] installing Xen timer for CPU 5
[    8.739017] installing Xen timer for CPU 6
[    8.740032] installing Xen timer for CPU 7
[    8.740964] Brought up 8 CPUs
[    8.741540] devtmpfs: initialized
[    8.741942] PM: Registering ACPI NVS region [mem 0x8c21c000-0x8c2eefff] (864256 bytes)
[    8.741960] PM: Registering ACPI NVS region [mem 0x8c3df000-0x8d7defff] (20971520 bytes)
[    8.742195] PM: Registering ACPI NVS region [mem 0x8f3d4000-0x8f3ddfff] (40960 bytes)
[    8.742198] PM: Registering ACPI NVS region [mem 0x8f3e2000-0x8f4cefff] (970752 bytes)
[    8.742250] Grant tables using version 2 layout.
[    8.742263] Grant table initialized
[    8.742297] NET: Registered protocol family 16
[    8.742988] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    8.742994] ACPI: bus type pci registered
[    8.743193] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xa0000000-0xafffffff] (base 0xa0000000)
[    8.743199] PCI: MMCONFIG at [mem 0xa0000000-0xafffffff] reserved in E820
[    8.787823] PCI: Using configuration type 1 for base access
[    8.788567] bio: create slab <bio-0> at 0
[    8.788791] ACPI: Added _OSI(Module Device)
[    8.788798] ACPI: Added _OSI(Processor Device)
[    8.788802] ACPI: Added _OSI(3.0 _SCP Extensions)
[    8.788806] ACPI: Added _OSI(Processor Aggregator Device)
[    8.789956] ACPI: EC: Look up EC in DSDT
[    8.805910] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL] size 64 (bits) (20120913/dsopcode-236)
[    8.805918] ACPI Error: Method parse/execution failed [\_SB_._OSC] (Node ffff88062cc491b8), AE_AML_BUFFER_LIMIT (20120913/psparse-536)
[    8.806714] ACPI: Interpreter enabled
[    8.806719] ACPI: (supports S0 S1 S5)
[    8.806729] ACPI: Using IOAPIC for interrupt routing
[    8.809807] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    8.810337] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fd])
[    8.810772] pci_root PNP0A08:00: ignoring host bridge window [mem 0x000c4000-0x000cbfff] (conflicts with Video ROM [mem 0x000c0000-0x000c7fff])
[    8.810801] PCI host bridge to bus 0000:00
[    8.810804] pci_bus 0000:00: root bus resource [bus 00-fd]
[    8.810808] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    8.810811] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    8.810814] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    8.810818] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
[    8.810821] pci_bus 0000:00: root bus resource [mem 0xb0000000-0xfdffffff]
[    8.810824] pci_bus 0000:00: scanning bus
[    8.810845] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
[    8.810856] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0xa
[    8.810955] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    8.810962] pci 0000:00:00.0: PME# disabled
[    8.810999] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
[    8.811047] pci 0000:00:01.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811110] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    8.811116] pci 0000:00:01.0: PME# disabled
[    8.811155] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
[    8.811200] pci 0000:00:03.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811264] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    8.811270] pci 0000:00:03.0: PME# disabled
[    8.811309] pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
[    8.811354] pci 0000:00:05.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811417] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    8.811423] pci 0000:00:05.0: PME# disabled
[    8.811462] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
[    8.811507] pci 0000:00:07.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811570] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    8.811576] pci 0000:00:07.0: PME# disabled
[    8.811615] pci 0000:00:09.0: [8086:3410] type 01 class 0x060400
[    8.811660] pci 0000:00:09.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811723] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    8.811729] pci 0000:00:09.0: PME# disabled
[    8.811766] pci 0000:00:0a.0: [8086:3411] type 01 class 0x060400
[    8.811811] pci 0000:00:0a.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811874] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
[    8.811880] pci 0000:00:0a.0: PME# disabled
[    8.811917] pci 0000:00:10.0: [8086:3425] type 00 class 0x080000
[    8.812039] pci 0000:00:10.1: [8086:3426] type 00 class 0x080000
[    8.812144] pci 0000:00:11.0: [8086:3427] type 00 class 0x080000
[    8.812271] pci 0000:00:11.1: [8086:3428] type 00 class 0x080000
[    8.812378] pci 0000:00:13.0: [8086:342d] type 00 class 0x080020
[    8.812398] pci 0000:00:13.0: reg 10: [mem 0xb1b24000-0xb1b24fff]
[    8.812489] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold
[    8.812496] pci 0000:00:13.0: PME# disabled
[    8.812525] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
[    8.812645] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
[    8.812766] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
[    8.812880] pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
[    8.812980] pci 0000:00:15.0: [8086:342f] type 00 class 0x080020
[    8.813089] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
[    8.813111] pci 0000:00:16.0: reg 10: [mem 0xb1b00000-0xb1b03fff 64bit]
[    8.813239] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
[    8.813261] pci 0000:00:16.1: reg 10: [mem 0xb1b04000-0xb1b07fff 64bit]
[    8.813389] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
[    8.813417] pci 0000:00:16.2: reg 10: [mem 0xb1b08000-0xb1b0bfff 64bit]
[    8.813546] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
[    8.813568] pci 0000:00:16.3: reg 10: [mem 0xb1b0c000-0xb1b0ffff 64bit]
[    8.813696] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
[    8.813717] pci 0000:00:16.4: reg 10: [mem 0xb1b10000-0xb1b13fff 64bit]
[    8.813846] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
[    8.813868] pci 0000:00:16.5: reg 10: [mem 0xb1b14000-0xb1b17fff 64bit]
[    8.813995] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
[    8.814017] pci 0000:00:16.6: reg 10: [mem 0xb1b18000-0xb1b1bfff 64bit]
[    8.814146] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
[    8.814168] pci 0000:00:16.7: reg 10: [mem 0xb1b1c000-0xb1b1ffff 64bit]
[    8.814298] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300
[    8.814369] pci 0000:00:1a.0: reg 20: [io  0x30e0-0x30ff]
[    8.814452] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300
[    8.814522] pci 0000:00:1a.1: reg 20: [io  0x30c0-0x30df]
[    8.814605] pci 0000:00:1a.2: [8086:3a39] type 00 class 0x0c0300
[    8.814675] pci 0000:00:1a.2: reg 20: [io  0x30a0-0x30bf]
[    8.814772] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320
[    8.814806] pci 0000:00:1a.7: reg 10: [mem 0xb1b22000-0xb1b223ff]
[    8.814949] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    8.814956] pci 0000:00:1a.7: PME# disabled
[    8.814989] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400
[    8.815046] pci 0000:00:1c.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.815111] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    8.815118] pci 0000:00:1c.0: PME# disabled
[    8.815158] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400
[    8.815214] pci 0000:00:1c.4: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.815280] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    8.815286] pci 0000:00:1c.4: PME# disabled
[    8.815321] pci 0000:00:1c.5: [8086:3a4a] type 01 class 0x060400
[    8.815377] pci 0000:00:1c.5: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.815443] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    8.815449] pci 0000:00:1c.5: PME# disabled
[    8.815489] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
[    8.815559] pci 0000:00:1d.0: reg 20: [io  0x3080-0x309f]
[    8.815642] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
[    8.815713] pci 0000:00:1d.1: reg 20: [io  0x3060-0x307f]
[    8.815796] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[    8.815866] pci 0000:00:1d.2: reg 20: [io  0x3040-0x305f]
[    8.815963] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
[    8.815997] pci 0000:00:1d.7: reg 10: [mem 0xb1b21000-0xb1b213ff]
[    8.816140] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    8.816147] pci 0000:00:1d.7: PME# disabled
[    8.816176] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[    8.816229] pci 0000:00:1e.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.816290] pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100
[    8.816406] pci 0000:00:1f.0: calling ich_force_enable_hpet+0x0/0x1c0
[    8.816410] pci 0000:00:1f.0: calling quirk_ich7_lpc+0x0/0x68
[    8.816424] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 000f)
[    8.816430] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)
[    8.816458] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0600 (mask 001f)
[    8.816536] pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601
[    8.816569] pci 0000:00:1f.2: reg 10: [io  0x3108-0x310f]
[    8.816583] pci 0000:00:1f.2: reg 14: [io  0x3114-0x3117]
[    8.816596] pci 0000:00:1f.2: reg 18: [io  0x3100-0x3107]
[    8.816610] pci 0000:00:1f.2: reg 1c: [io  0x3110-0x3113]
[    8.816623] pci 0000:00:1f.2: reg 20: [io  0x3020-0x303f]
[    8.816637] pci 0000:00:1f.2: reg 24: [mem 0xb1b20000-0xb1b207ff]
[    8.816717] pci 0000:00:1f.2: PME# supported from D3hot
[    8.816723] pci 0000:00:1f.2: PME# disabled
[    8.816749] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
[    8.816774] pci 0000:00:1f.3: reg 10: [mem 0xb1b23000-0xb1b230ff 64bit]
[    8.816810] pci 0000:00:1f.3: reg 20: [io  0x3000-0x301f]
[    8.816856] pci_bus 0000:00: fixups for bus
[    8.816861] pci 0000:00:01.0: scanning [bus 01-03] behind bridge, pass 0
[    8.816921] pci_bus 0000:01: scanning bus
[    8.816951] pci 0000:01:00.0: [8086:10c9] type 00 class 0x020000
[    8.816971] pci 0000:01:00.0: reg 10: [mem 0xb1a20000-0xb1a3ffff]
[    8.816998] pci 0000:01:00.0: reg 18: [io  0x2020-0x203f]
[    8.817013] pci 0000:01:00.0: reg 1c: [mem 0xb1ac4000-0xb1ac7fff]
[    8.817122] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    8.817128] pci 0000:01:00.0: PME# disabled
[    8.817174] pci 0000:01:00.0: reg 184: [mem 0xb1a40000-0xb1a43fff 64bit]
[    8.817196] pci 0000:01:00.0: reg 190: [mem 0xb1a60000-0xb1a63fff 64bit]
[    8.817240] pci 0000:01:00.1: [8086:10c9] type 00 class 0x020000
[    8.817260] pci 0000:01:00.1: reg 10: [mem 0xb1a00000-0xb1a1ffff]
[    8.817287] pci 0000:01:00.1: reg 18: [io  0x2000-0x201f]
[    8.817302] pci 0000:01:00.1: reg 1c: [mem 0xb1ac0000-0xb1ac3fff]
[    8.817410] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
[    8.817417] pci 0000:01:00.1: PME# disabled
[    8.817455] pci 0000:01:00.1: reg 184: [mem 0xb1a80000-0xb1a83fff 64bit]
[    8.817483] pci 0000:01:00.1: reg 190: [mem 0xb1aa0000-0xb1aa3fff 64bit]
[    8.819001] pci_bus 0000:01: fixups for bus
[    8.819004] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    8.819010] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    8.819016] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    8.819025] pci_bus 0000:01: bus scan returning with max=01
[    8.819031] pci 0000:00:03.0: scanning [bus 04-04] behind bridge, pass 0
[    8.819092] pci_bus 0000:04: scanning bus
[    8.819096] pci_bus 0000:04: fixups for bus
[    8.819098] pci 0000:00:03.0: PCI bridge to [bus 04]
[    8.819112] pci_bus 0000:04: bus scan returning with max=04
[    8.819118] pci 0000:00:05.0: scanning [bus 05-08] behind bridge, pass 0
[    8.819177] pci_bus 0000:05: scanning bus
[    8.819197] pci 0000:05:00.0: [111d:806a] type 01 class 0x060400
[    8.819311] pci 0000:05:00.0: PME# supported from D0 D3hot D3cold
[    8.819319] pci 0000:05:00.0: PME# disabled
[    8.820727] pci_bus 0000:05: fixups for bus
[    8.820745] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    8.820761] pci 0000:05:00.0: scanning [bus 06-08] behind bridge, pass 0
[    8.820813] pci_bus 0000:06: scanning bus
[    8.820836] pci 0000:06:02.0: [111d:806a] type 01 class 0x060400
[    8.820965] pci 0000:06:02.0: PME# supported from D0 D3hot D3cold
[    8.820973] pci 0000:06:02.0: PME# disabled
[    8.821013] pci 0000:06:04.0: [111d:806a] type 01 class 0x060400
[    8.821141] pci 0000:06:04.0: PME# supported from D0 D3hot D3cold
[    8.821149] pci 0000:06:04.0: PME# disabled
[    8.821211] pci_bus 0000:06: fixups for bus
[    8.821213] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    8.821238] pci 0000:06:02.0: scanning [bus 07-07] behind bridge, pass 0
[    8.821300] pci_bus 0000:07: scanning bus
[    8.821305] pci_bus 0000:07: fixups for bus
[    8.821307] pci 0000:06:02.0: PCI bridge to [bus 07]
[    8.821329] pci_bus 0000:07: bus scan returning with max=07
[    8.821336] pci 0000:06:04.0: scanning [bus 08-08] behind bridge, pass 0
[    8.821398] pci_bus 0000:08: scanning bus
[    8.821402] pci_bus 0000:08: fixups for bus
[    8.821405] pci 0000:06:04.0: PCI bridge to [bus 08]
[    8.821427] pci_bus 0000:08: bus scan returning with max=08
[    8.821434] pci 0000:06:02.0: scanning [bus 07-07] behind bridge, pass 1
[    8.821445] pci 0000:06:04.0: scanning [bus 08-08] behind bridge, pass 1
[    8.821454] pci_bus 0000:06: bus scan returning with max=08
[    8.821461] pci 0000:05:00.0: scanning [bus 06-08] behind bridge, pass 1
[    8.821470] pci_bus 0000:05: bus scan returning with max=08
[    8.821476] pci 0000:00:07.0: scanning [bus 09-0c] behind bridge, pass 0
[    8.821542] pci_bus 0000:09: scanning bus
[    8.821562] pci 0000:09:00.0: [111d:806a] type 01 class 0x060400
[    8.821676] pci 0000:09:00.0: PME# supported from D0 D3hot D3cold
[    8.821683] pci 0000:09:00.0: PME# disabled
[    8.823103] pci_bus 0000:09: fixups for bus
[    8.823106] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    8.823122] pci 0000:09:00.0: scanning [bus 0a-0c] behind bridge, pass 0
[    8.823175] pci_bus 0000:0a: scanning bus
[    8.823197] pci 0000:0a:02.0: [111d:806a] type 01 class 0x060400
[    8.823326] pci 0000:0a:02.0: PME# supported from D0 D3hot D3cold
[    8.823333] pci 0000:0a:02.0: PME# disabled
[    8.823373] pci 0000:0a:04.0: [111d:806a] type 01 class 0x060400
[    8.823502] pci 0000:0a:04.0: PME# supported from D0 D3hot D3cold
[    8.823509] pci 0000:0a:04.0: PME# disabled
[    8.823571] pci_bus 0000:0a: fixups for bus
[    8.823573] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    8.823598] pci 0000:0a:02.0: scanning [bus 0b-0b] behind bridge, pass 0
[    8.823660] pci_bus 0000:0b: scanning bus
[    8.823664] pci_bus 0000:0b: fixups for bus
[    8.823667] pci 0000:0a:02.0: PCI bridge to [bus 0b]
[    8.823689] pci_bus 0000:0b: bus scan returning with max=0b
[    8.823696] pci 0000:0a:04.0: scanning [bus 0c-0c] behind bridge, pass 0
[    8.823758] pci_bus 0000:0c: scanning bus
[    8.823762] pci_bus 0000:0c: fixups for bus
[    8.823765] pci 0000:0a:04.0: PCI bridge to [bus 0c]
[    8.823787] pci_bus 0000:0c: bus scan returning with max=0c
[    8.823794] pci 0000:0a:02.0: scanning [bus 0b-0b] behind bridge, pass 1
[    8.823805] pci 0000:0a:04.0: scanning [bus 0c-0c] behind bridge, pass 1
[    8.823814] pci_bus 0000:0a: bus scan returning with max=0c
[    8.823821] pci 0000:09:00.0: scanning [bus 0a-0c] behind bridge, pass 1
[    8.823830] pci_bus 0000:09: bus scan returning with max=0c
[    8.823836] pci 0000:00:09.0: scanning [bus 0d-0d] behind bridge, pass 0
[    8.823922] pci_bus 0000:0d: scanning bus
[    8.823925] pci_bus 0000:0d: fixups for bus
[    8.823928] pci 0000:00:09.0: PCI bridge to [bus 0d]
[    8.823941] pci_bus 0000:0d: bus scan returning with max=0d
[    8.823947] pci 0000:00:0a.0: scanning [bus 0e-0e] behind bridge, pass 0
[    8.824007] pci_bus 0000:0e: scanning bus
[    8.824010] pci_bus 0000:0e: fixups for bus
[    8.824013] pci 0000:00:0a.0: PCI bridge to [bus 0e]
[    8.824026] pci_bus 0000:0e: bus scan returning with max=0e
[    8.824033] pci 0000:00:1c.0: scanning [bus 0f-0f] behind bridge, pass 0
[    8.824094] pci_bus 0000:0f: scanning bus
[    8.824117] pci 0000:0f:00.0: [1000:0062] type 00 class 0x010000
[    8.824147] pci 0000:0f:00.0: reg 10: [mem 0xb1940000-0xb1943fff 64bit]
[    8.824165] pci 0000:0f:00.0: reg 18: [io  0x1000-0x10ff]
[    8.824190] pci 0000:0f:00.0: reg 1c: [mem 0xb1900000-0xb193ffff 64bit]
[    8.824221] pci 0000:0f:00.0: reg 30: [mem 0xfff80000-0xffffffff pref]
[    8.824311] pci 0000:0f:00.0: supports D1
[    8.833857] pci_bus 0000:0f: fixups for bus
[    8.833866] pci 0000:00:1c.0: PCI bridge to [bus 0f]
[    8.833877] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    8.833889] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    8.833904] pci_bus 0000:0f: bus scan returning with max=0f
[    8.833917] pci 0000:00:1c.4: scanning [bus 10-10] behind bridge, pass 0
[    8.833986] pci_bus 0000:10: scanning bus
[    8.834016] pci 0000:10:00.0: [102b:0522] type 00 class 0x030000
[    8.834045] pci 0000:10:00.0: reg 10: [mem 0xb0000000-0xb0ffffff pref]
[    8.834066] pci 0000:10:00.0: reg 14: [mem 0xb1800000-0xb1803fff]
[    8.834086] pci 0000:10:00.0: reg 18: [mem 0xb1000000-0xb17fffff]
[    8.834159] pci 0000:10:00.0: reg 30: [mem 0xffff0000-0xffffffff pref]
[    8.842079] pci_bus 0000:10: fixups for bus
[    8.842087] pci 0000:00:1c.4: PCI bridge to [bus 10]
[    8.842104] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    8.842120] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    8.842127] pci_bus 0000:10: bus scan returning with max=10
[    8.842141] pci 0000:00:1c.5: scanning [bus 11-11] behind bridge, pass 0
[    8.842204] pci_bus 0000:11: scanning bus
[    8.842209] pci_bus 0000:11: fixups for bus
[    8.842211] pci 0000:00:1c.5: PCI bridge to [bus 11]
[    8.842227] pci_bus 0000:11: bus scan returning with max=11
[    8.842233] pci 0000:00:1e.0: scanning [bus 12-12] behind bridge, pass 0
[    8.842265] pci_bus 0000:12: scanning bus
[    8.842326] pci_bus 0000:12: fixups for bus
[    8.842329] pci 0000:00:1e.0: PCI bridge to [bus 12] (subtractive decode)
[    8.842345] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    8.842348] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    8.842352] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    8.842356] pci 0000:00:1e.0:   bridge window [mem 0xfed40000-0xfedfffff] (subtractive decode)
[    8.842359] pci 0000:00:1e.0:   bridge window [mem 0xb0000000-0xfdffffff] (subtractive decode)
[    8.842363] pci_bus 0000:12: bus scan returning with max=12
[    8.842370] pci 0000:00:01.0: scanning [bus 01-03] behind bridge, pass 1
[    8.842379] pci 0000:00:03.0: scanning [bus 04-04] behind bridge, pass 1
[    8.842387] pci 0000:00:05.0: scanning [bus 05-08] behind bridge, pass 1
[    8.842396] pci 0000:00:07.0: scanning [bus 09-0c] behind bridge, pass 1
[    8.842405] pci 0000:00:09.0: scanning [bus 0d-0d] behind bridge, pass 1
[    8.842414] pci 0000:00:0a.0: scanning [bus 0e-0e] behind bridge, pass 1
[    8.842424] pci 0000:00:1c.0: scanning [bus 0f-0f] behind bridge, pass 1
[    8.842433] pci 0000:00:1c.4: scanning [bus 10-10] behind bridge, pass 1
[    8.842443] pci 0000:00:1c.5: scanning [bus 11-11] behind bridge, pass 1
[    8.842452] pci 0000:00:1e.0: scanning [bus 12-12] behind bridge, pass 1
[    8.842460] pci_bus 0000:00: bus scan returning with max=12
[    8.842463] pci_bus 0000:00: on NUMA node 0
[    8.842468] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    8.871220] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP1._PRT]
[    8.871256] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP3._PRT]
[    8.871282] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP5._PRT]
[    8.871307] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP7._PRT]
[    8.871334] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP9._PRT]
[    8.871369] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRPA._PRT]
[    8.871411] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[    8.871439] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[    8.871521]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    8.871589]  pci0000:00: ACPI _OSC control (0x1d) granted
[    8.879474] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    8.879522] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    8.879567] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[    8.879611] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
[    8.879654] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879700] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879745] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879790] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879821] xen/balloon: Initialising balloon driver.
[    8.881103] xen-balloon: Initialising balloon driver.
[    8.881327] vgaarb: device added: PCI:0000:10:00.0,decodes=io+mem,owns=io+mem,locks=none
[    8.881335] vgaarb: loaded
[    8.881339] vgaarb: bridge control possible 0000:10:00.0
[    8.881410] SCSI subsystem initialized
[    8.881415] ACPI: bus type scsi registered
[    8.881674] libata version 3.00 loaded.
[    8.881704] ACPI: bus type usb registered
[    8.881729] usbcore: registered new interface driver usbfs
[    8.881737] usbcore: registered new interface driver hub
[    8.881892] usbcore: registered new device driver usb
[    8.881937] PCI: Using ACPI for IRQ routing
[    8.893174] PCI: Discovered peer bus fe
[    8.893177] PCI: root bus fe: using default resources
[    8.893180] PCI: Probing PCI hardware (bus fe)
[    8.893199] PCI host bridge to bus 0000:fe
[    8.893202] pci_bus 0000:fe: root bus resource [io  0x0000-0xffff]
[    8.893206] pci_bus 0000:fe: root bus resource [mem 0x00000000-0xffffffffff]
[    8.893209] pci_bus 0000:fe: No busn resource found for root bus, will use [bus fe-ff]
[    8.893213] pci_bus 0000:fe: scanning bus
[    8.893222] pci 0000:fe:00.0: [8086:2c70] type 00 class 0x060000
[    8.893228] pci 0000:fe:00.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893280] pci 0000:fe:00.1: [8086:2d81] type 00 class 0x060000
[    8.893284] pci 0000:fe:00.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893342] pci 0000:fe:02.0: [8086:2d90] type 00 class 0x060000
[    8.893346] pci 0000:fe:02.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893396] pci 0000:fe:02.1: [8086:2d91] type 00 class 0x060000
[    8.893400] pci 0000:fe:02.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893452] pci 0000:fe:02.2: [8086:2d92] type 00 class 0x060000
[    8.893456] pci 0000:fe:02.2: calling quirk_mmio_always_on+0x0/0xa
[    8.893505] pci 0000:fe:02.3: [8086:2d93] type 00 class 0x060000
[    8.893510] pci 0000:fe:02.3: calling quirk_mmio_always_on+0x0/0xa
[    8.893559] pci 0000:fe:02.4: [8086:2d94] type 00 class 0x060000
[    8.893563] pci 0000:fe:02.4: calling quirk_mmio_always_on+0x0/0xa
[    8.893613] pci 0000:fe:02.5: [8086:2d95] type 00 class 0x060000
[    8.893617] pci 0000:fe:02.5: calling quirk_mmio_always_on+0x0/0xa
[    8.893669] pci 0000:fe:03.0: [8086:2d98] type 00 class 0x060000
[    8.893673] pci 0000:fe:03.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893723] pci 0000:fe:03.1: [8086:2d99] type 00 class 0x060000
[    8.893727] pci 0000:fe:03.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893776] pci 0000:fe:03.2: [8086:2d9a] type 00 class 0x060000
[    8.893781] pci 0000:fe:03.2: calling quirk_mmio_always_on+0x0/0xa
[    8.893831] pci 0000:fe:03.4: [8086:2d9c] type 00 class 0x060000
[    8.893835] pci 0000:fe:03.4: calling quirk_mmio_always_on+0x0/0xa
[    8.893890] pci 0000:fe:04.0: [8086:2da0] type 00 class 0x060000
[    8.893894] pci 0000:fe:04.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893944] pci 0000:fe:04.1: [8086:2da1] type 00 class 0x060000
[    8.893948] pci 0000:fe:04.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893997] pci 0000:fe:04.2: [8086:2da2] type 00 class 0x060000
[    8.894001] pci 0000:fe:04.2: calling quirk_mmio_always_on+0x0/0xa
[    8.894051] pci 0000:fe:04.3: [8086:2da3] type 00 class 0x060000
[    8.894055] pci 0000:fe:04.3: calling quirk_mmio_always_on+0x0/0xa
[    8.894110] pci 0000:fe:05.0: [8086:2da8] type 00 class 0x060000
[    8.894114] pci 0000:fe:05.0: calling quirk_mmio_always_on+0x0/0xa
[    8.894163] pci 0000:fe:05.1: [8086:2da9] type 00 class 0x060000
[    8.894167] pci 0000:fe:05.1: calling quirk_mmio_always_on+0x0/0xa
[    8.894217] pci 0000:fe:05.2: [8086:2daa] type 00 class 0x060000
[    8.894221] pci 0000:fe:05.2: calling quirk_mmio_always_on+0x0/0xa
[    8.894271] pci 0000:fe:05.3: [8086:2dab] type 00 class 0x060000
[    8.894275] pci 0000:fe:05.3: calling quirk_mmio_always_on+0x0/0xa
[    8.894331] pci 0000:fe:06.0: [8086:2db0] type 00 class 0x060000
[    8.894335] pci 0000:fe:06.0: calling quirk_mmio_always_on+0x0/0xa
[    8.894387] pci 0000:fe:06.1: [8086:2db1] type 00 class 0x060000
[    8.894394] pci 0000:fe:06.1: calling quirk_mmio_always_on+0x0/0xa
[    8.894447] pci 0000:fe:06.2: [8086:2db2] type 00 class 0x060000
[    8.894451] pci 0000:fe:06.2: calling quirk_mmio_always_on+0x0/0xa
[    8.894501] pci 0000:fe:06.3: [8086:2db3] type 00 class 0x060000
[    8.894505] pci 0000:fe:06.3: calling quirk_mmio_always_on+0x0/0xa
[    8.894584] pci_bus 0000:fe: fixups for bus
[    8.894587] pci_bus 0000:fe: bus scan returning with max=fe
[    8.894591] pci_bus 0000:fe: busn_res: [bus fe-ff] end is updated to fe
[    8.894956] PCI: Discovered peer bus ff
[    8.894959] PCI: root bus ff: using default resources
[    8.894961] PCI: Probing PCI hardware (bus ff)
[    8.894977] PCI host bridge to bus 0000:ff
[    8.894980] pci_bus 0000:ff: root bus resource [io  0x0000-0xffff]
[    8.894984] pci_bus 0000:ff: root bus resource [mem 0x00000000-0xffffffffff]
[    8.894987] pci_bus 0000:ff: No busn resource found for root bus, will use [bus ff-ff]
[    8.894991] pci_bus 0000:ff: scanning bus
[    8.894999] pci 0000:ff:00.0: [8086:2c70] type 00 class 0x060000
[    8.895004] pci 0000:ff:00.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895053] pci 0000:ff:00.1: [8086:2d81] type 00 class 0x060000
[    8.895057] pci 0000:ff:00.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895120] pci 0000:ff:02.0: [8086:2d90] type 00 class 0x060000
[    8.895124] pci 0000:ff:02.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895172] pci 0000:ff:02.1: [8086:2d91] type 00 class 0x060000
[    8.895176] pci 0000:ff:02.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895226] pci 0000:ff:02.2: [8086:2d92] type 00 class 0x060000
[    8.895230] pci 0000:ff:02.2: calling quirk_mmio_always_on+0x0/0xa
[    8.895277] pci 0000:ff:02.3: [8086:2d93] type 00 class 0x060000
[    8.895281] pci 0000:ff:02.3: calling quirk_mmio_always_on+0x0/0xa
[    8.895329] pci 0000:ff:02.4: [8086:2d94] type 00 class 0x060000
[    8.895333] pci 0000:ff:02.4: calling quirk_mmio_always_on+0x0/0xa
[    8.895380] pci 0000:ff:02.5: [8086:2d95] type 00 class 0x060000
[    8.895384] pci 0000:ff:02.5: calling quirk_mmio_always_on+0x0/0xa
[    8.895434] pci 0000:ff:03.0: [8086:2d98] type 00 class 0x060000
[    8.895438] pci 0000:ff:03.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895486] pci 0000:ff:03.1: [8086:2d99] type 00 class 0x060000
[    8.895490] pci 0000:ff:03.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895537] pci 0000:ff:03.2: [8086:2d9a] type 00 class 0x060000
[    8.895549] pci 0000:ff:03.2: calling quirk_mmio_always_on+0x0/0xa
[    8.895598] pci 0000:ff:03.4: [8086:2d9c] type 00 class 0x060000
[    8.895602] pci 0000:ff:03.4: calling quirk_mmio_always_on+0x0/0xa
[    8.895655] pci 0000:ff:04.0: [8086:2da0] type 00 class 0x060000
[    8.895658] pci 0000:ff:04.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895706] pci 0000:ff:04.1: [8086:2da1] type 00 class 0x060000
[    8.895710] pci 0000:ff:04.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895758] pci 0000:ff:04.2: [8086:2da2] type 00 class 0x060000
[    8.895762] pci 0000:ff:04.2: calling quirk_mmio_always_on+0x0/0xa
[    8.895809] pci 0000:ff:04.3: [8086:2da3] type 00 class 0x060000
[    8.895813] pci 0000:ff:04.3: calling quirk_mmio_always_on+0x0/0xa
[    8.895865] pci 0000:ff:05.0: [8086:2da8] type 00 class 0x060000
[    8.895869] pci 0000:ff:05.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895917] pci 0000:ff:05.1: [8086:2da9] type 00 class 0x060000
[    8.895921] pci 0000:ff:05.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895968] pci 0000:ff:05.2: [8086:2daa] type 00 class 0x060000
[    8.895972] pci 0000:ff:05.2: calling quirk_mmio_always_on+0x0/0xa
[    8.896020] pci 0000:ff:05.3: [8086:2dab] type 00 class 0x060000
[    8.896024] pci 0000:ff:05.3: calling quirk_mmio_always_on+0x0/0xa
[    8.896078] pci 0000:ff:06.0: [8086:2db0] type 00 class 0x060000
[    8.896082] pci 0000:ff:06.0: calling quirk_mmio_always_on+0x0/0xa
[    8.896130] pci 0000:ff:06.1: [8086:2db1] type 00 class 0x060000
[    8.896134] pci 0000:ff:06.1: calling quirk_mmio_always_on+0x0/0xa
[    8.896182] pci 0000:ff:06.2: [8086:2db2] type 00 class 0x060000
[    8.896186] pci 0000:ff:06.2: calling quirk_mmio_always_on+0x0/0xa
[    8.896233] pci 0000:ff:06.3: [8086:2db3] type 00 class 0x060000
[    8.896237] pci 0000:ff:06.3: calling quirk_mmio_always_on+0x0/0xa
[    8.896312] pci_bus 0000:ff: fixups for bus
[    8.896315] pci_bus 0000:ff: bus scan returning with max=ff
[    8.896318] pci_bus 0000:ff: busn_res: [bus ff] end is updated to ff
[    8.896670] PCI: pci_cache_line_size set to 64 bytes
[    8.896697] pci 0000:00:13.0: BAR 0: reserving [mem 0xb1b24000-0xb1b24fff flags 0x40200] (d=0, p=0)
[    8.896711] pci 0000:00:16.0: BAR 0: reserving [mem 0xb1b00000-0xb1b03fff flags 0x140204] (d=0, p=0)
[    8.896717] pci 0000:00:16.1: BAR 0: reserving [mem 0xb1b04000-0xb1b07fff flags 0x140204] (d=0, p=0)
[    8.896723] pci 0000:00:16.2: BAR 0: reserving [mem 0xb1b08000-0xb1b0bfff flags 0x140204] (d=0, p=0)
[    8.896729] pci 0000:00:16.3: BAR 0: reserving [mem 0xb1b0c000-0xb1b0ffff flags 0x140204] (d=0, p=0)
[    8.896735] pci 0000:00:16.4: BAR 0: reserving [mem 0xb1b10000-0xb1b13fff flags 0x140204] (d=0, p=0)
[    8.896741] pci 0000:00:16.5: BAR 0: reserving [mem 0xb1b14000-0xb1b17fff flags 0x140204] (d=0, p=0)
[    8.896746] pci 0000:00:16.6: BAR 0: reserving [mem 0xb1b18000-0xb1b1bfff flags 0x140204] (d=0, p=0)
[    8.896752] pci 0000:00:16.7: BAR 0: reserving [mem 0xb1b1c000-0xb1b1ffff flags 0x140204] (d=0, p=0)
[    8.896759] pci 0000:00:1a.0: BAR 4: reserving [io  0x30e0-0x30ff flags 0x40101] (d=0, p=0)
[    8.896764] pci 0000:00:1a.1: BAR 4: reserving [io  0x30c0-0x30df flags 0x40101] (d=0, p=0)
[    8.896770] pci 0000:00:1a.2: BAR 4: reserving [io  0x30a0-0x30bf flags 0x40101] (d=0, p=0)
[    8.896776] pci 0000:00:1a.7: BAR 0: reserving [mem 0xb1b22000-0xb1b223ff flags 0x40200] (d=0, p=0)
[    8.896788] pci 0000:00:1d.0: BAR 4: reserving [io  0x3080-0x309f flags 0x40101] (d=0, p=0)
[    8.896793] pci 0000:00:1d.1: BAR 4: reserving [io  0x3060-0x307f flags 0x40101] (d=0, p=0)
[    8.896799] pci 0000:00:1d.2: BAR 4: reserving [io  0x3040-0x305f flags 0x40101] (d=0, p=0)
[    8.896805] pci 0000:00:1d.7: BAR 0: reserving [mem 0xb1b21000-0xb1b213ff flags 0x40200] (d=0, p=0)
[    8.896815] pci 0000:00:1f.2: BAR 0: reserving [io  0x3108-0x310f flags 0x40101] (d=0, p=0)
[    8.896819] pci 0000:00:1f.2: BAR 1: reserving [io  0x3114-0x3117 flags 0x40101] (d=0, p=0)
[    8.896823] pci 0000:00:1f.2: BAR 2: reserving [io  0x3100-0x3107 flags 0x40101] (d=0, p=0)
[    8.896827] pci 0000:00:1f.2: BAR 3: reserving [io  0x3110-0x3113 flags 0x40101] (d=0, p=0)
[    8.896830] pci 0000:00:1f.2: BAR 4: reserving [io  0x3020-0x303f flags 0x40101] (d=0, p=0)
[    8.896834] pci 0000:00:1f.2: BAR 5: reserving [mem 0xb1b20000-0xb1b207ff flags 0x40200] (d=0, p=0)
[    8.896840] pci 0000:00:1f.3: BAR 0: reserving [mem 0xb1b23000-0xb1b230ff flags 0x140204] (d=0, p=0)
[    8.896845] pci 0000:00:1f.3: BAR 4: reserving [io  0x3000-0x301f flags 0x40101] (d=0, p=0)
[    8.896850] pci 0000:01:00.0: BAR 0: reserving [mem 0xb1a20000-0xb1a3ffff flags 0x40200] (d=0, p=0)
[    8.896855] pci 0000:01:00.0: BAR 2: reserving [io  0x2020-0x203f flags 0x40101] (d=0, p=0)
[    8.896858] pci 0000:01:00.0: BAR 3: reserving [mem 0xb1ac4000-0xb1ac7fff flags 0x40200] (d=0, p=0)
[    8.896863] pci 0000:01:00.0: BAR 7: reserving [mem 0xb1a40000-0xb1a5ffff flags 0x140204] (d=0, p=0)
[    8.896867] pci 0000:01:00.0: BAR 10: reserving [mem 0xb1a60000-0xb1a7ffff flags 0x140204] (d=0, p=0)
[    8.896873] pci 0000:01:00.1: BAR 0: reserving [mem 0xb1a00000-0xb1a1ffff flags 0x40200] (d=0, p=0)
[    8.896877] pci 0000:01:00.1: BAR 2: reserving [io  0x2000-0x201f flags 0x40101] (d=0, p=0)
[    8.896881] pci 0000:01:00.1: BAR 3: reserving [mem 0xb1ac0000-0xb1ac3fff flags 0x40200] (d=0, p=0)
[    8.896885] pci 0000:01:00.1: BAR 7: reserving [mem 0xb1a80000-0xb1a9ffff flags 0x140204] (d=0, p=0)
[    8.896889] pci 0000:01:00.1: BAR 10: reserving [mem 0xb1aa0000-0xb1abffff flags 0x140204] (d=0, p=0)
[    8.896908] pci 0000:0f:00.0: BAR 0: reserving [mem 0xb1940000-0xb1943fff flags 0x140204] (d=0, p=0)
[    8.896912] pci 0000:0f:00.0: BAR 2: reserving [io  0x1000-0x10ff flags 0x40101] (d=0, p=0)
[    8.896916] pci 0000:0f:00.0: BAR 3: reserving [mem 0xb1900000-0xb193ffff flags 0x140204] (d=0, p=0)
[    8.896923] pci 0000:10:00.0: BAR 0: reserving [mem 0xb0000000-0xb0ffffff flags 0x42208] (d=0, p=0)
[    8.896927] pci 0000:10:00.0: BAR 1: reserving [mem 0xb1800000-0xb1803fff flags 0x40200] (d=0, p=0)
[    8.896931] pci 0000:10:00.0: BAR 2: reserving [mem 0xb1000000-0xb17fffff flags 0x40200] (d=0, p=0)
[    8.897136] e820: reserve RAM buffer [mem 0x0009b000-0x0009ffff]
[    8.897139] e820: reserve RAM buffer [mem 0x8c21c000-0x8fffffff]
[    8.897249] Switching to clocksource xen
[    8.897508] pnp: PnP ACPI init
[    8.897518] ACPI: bus type pnp registered
[    8.897745] pnp 00:00: [bus 00-fd]
[    8.897749] pnp 00:00: [io  0x0cf8-0x0cff]
[    8.897752] pnp 00:00: [io  0x0000-0x0cf7 window]
[    8.897755] pnp 00:00: [io  0x0d00-0xffff window]
[    8.897758] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    8.897761] pnp 00:00: [mem 0x000c4000-0x000cbfff window]
[    8.897764] pnp 00:00: [mem 0xfed40000-0xfedfffff window]
[    8.897767] pnp 00:00: [mem 0xb0000000-0xfdffffff window]
[    8.897770] pnp 00:00: [mem 0x00000000 window]
[    8.897794] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)
[    8.897802] pnp 00:01: [mem 0xfec00000-0xfecfffff]
[    8.897817] pnp 00:01: Plug and Play ACPI device, IDs PNP0003 (active)
[    8.897942] pnp 00:02: [io  0x0000-0x000f]
[    8.897945] pnp 00:02: [io  0x0081-0x0083]
[    8.897948] pnp 00:02: [io  0x0087]
[    8.897950] pnp 00:02: [io  0x0089-0x008b]
[    8.897953] pnp 00:02: [io  0x008f]
[    8.897955] pnp 00:02: [io  0x00c0-0x00df]
[    8.897958] pnp 00:02: [dma 4]
[    8.897974] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    8.897982] pnp 00:03: [io  0x0070-0x0071]
[    8.897984] pnp 00:03: [io  0x0074-0x0077]
[    8.897988] xen: registering gsi 8 triggering 1 polarity 0
[    8.898021] pnp 00:03: [irq 8]
[    8.898035] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    8.898044] pnp 00:04: [io  0x00f0]
[    8.898046] xen: registering gsi 13 triggering 1 polarity 0
[    8.898075] pnp 00:04: [irq 13]
[    8.898092] pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active)
[    8.898100] pnp 00:05: [io  0x0061]
[    8.898114] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[    8.898143] pnp 00:06: [mem 0xfed00000-0xfed003ff]
[    8.898163] pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
[    8.898173] pnp 00:07: [io  0x0500-0x057f]
[    8.898175] pnp 00:07: [io  0x0400-0x047f]
[    8.898178] pnp 00:07: [io  0x0092]
[    8.898180] pnp 00:07: [io  0x0010-0x001f]
[    8.898182] pnp 00:07: [io  0x0072-0x0073]
[    8.898185] pnp 00:07: [io  0x0080]
[    8.898187] pnp 00:07: [io  0x0084-0x0086]
[    8.898190] pnp 00:07: [io  0x0088]
[    8.898192] pnp 00:07: [io  0x008c-0x008e]
[    8.898194] pnp 00:07: [io  0x0090-0x009f]
[    8.898197] pnp 00:07: [io  0x0800-0x081f]
[    8.898199] pnp 00:07: [io  0x0ca2-0x0ca3]
[    8.898202] pnp 00:07: [io  0x0600-0x061f]
[    8.898204] pnp 00:07: [io  0x0880-0x0883]
[    8.898206] pnp 00:07: [io  0x0ca4-0x0ca5]
[    8.898209] pnp 00:07: [mem 0xfed1c000-0xfed3fffe]
[    8.898211] pnp 00:07: [mem 0xff000000-0xffffffff]
[    8.898214] pnp 00:07: [mem 0xfee00000-0xfeefffff]
[    8.898218] pnp 00:07: [mem 0xfe900000-0xfe90001f]
[    8.898221] pnp 00:07: [mem 0xfea00000-0xfea0001f]
[    8.898224] pnp 00:07: [mem 0xfed1b000-0xfed1bfff]
[    8.898275] system 00:07: [io  0x0500-0x057f] has been reserved
[    8.898279] system 00:07: [io  0x0400-0x047f] has been reserved
[    8.898282] system 00:07: [io  0x0800-0x081f] has been reserved
[    8.898285] system 00:07: [io  0x0ca2-0x0ca3] has been reserved
[    8.898289] system 00:07: [io  0x0600-0x061f] has been reserved
[    8.898292] system 00:07: [io  0x0880-0x0883] has been reserved
[    8.898295] system 00:07: [io  0x0ca4-0x0ca5] has been reserved
[    8.898299] system 00:07: [mem 0xfed1c000-0xfed3fffe] could not be reserved
[    8.898303] system 00:07: [mem 0xff000000-0xffffffff] could not be reserved
[    8.898306] system 00:07: [mem 0xfee00000-0xfeefffff] could not be reserved
[    8.898310] system 00:07: [mem 0xfe900000-0xfe90001f] has been reserved
[    8.898313] system 00:07: [mem 0xfea00000-0xfea0001f] has been reserved
[    8.898316] system 00:07: [mem 0xfed1b000-0xfed1bfff] has been reserved
[    8.898320] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    8.898436] pnp 00:08: [io  0x02f8-0x02ff]
[    8.898440] xen: registering gsi 3 triggering 1 polarity 0
[    8.898469] pnp 00:08: [irq 3]
[    8.898513] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active)
[    8.898535] pnp 00:09: [mem 0xfed40000-0xfed44fff]
[    8.898551] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active)
[    8.898576] pnp 00:0a: [io  0x0ca2]
[    8.898579] pnp 00:0a: [io  0x0ca3]
[    8.898594] pnp 00:0a: Plug and Play ACPI device, IDs IPI0001 (active)
[    8.898626] pnp: PnP ACPI: found 11 devices
[    8.898652] ACPI: ACPI bus type pnp unregistered
[    8.905571] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    8.905583] pci 0000:0f:00.0: no compatible bridge window for [mem 0xfff80000-0xffffffff pref]
[    8.905588] pci 0000:10:00.0: no compatible bridge window for [mem 0xffff0000-0xffffffff pref]
[    8.905733] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus 0f] add_size 200000
[    8.905747] pci 0000:00:1c.4: bridge window [io  0x1000-0x0fff] to [bus 10] add_size 1000
[    8.905761] pci 0000:00:1c.5: bridge window [io  0x1000-0x0fff] to [bus 11] add_size 1000
[    8.905765] pci 0000:00:1c.5: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 11] add_size 200000
[    8.905769] pci 0000:00:1c.5: bridge window [mem 0x00100000-0x000fffff] to [bus 11] add_size 200000
[    8.905802] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x001fffff pref] get_res_add_size add_size 200000
[    8.905806] pci 0000:00:1c.5: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[    8.905810] pci 0000:00:1c.5: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[    8.905814] pci 0000:00:1c.4: res[13]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
[    8.905818] pci 0000:00:1c.5: res[13]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
[    8.905824] pci 0000:00:1c.0: BAR 15: assigned [mem 0xb1c00000-0xb1efffff pref]
[    8.905828] pci 0000:00:1c.5: BAR 14: assigned [mem 0xb1f00000-0xb20fffff]
[    8.905833] pci 0000:00:1c.5: BAR 15: assigned [mem 0xb2100000-0xb22fffff 64bit pref]
[    8.905837] pci 0000:00:1c.4: BAR 13: assigned [io  0x4000-0x4fff]
[    8.905841] pci 0000:00:1c.5: BAR 13: assigned [io  0x5000-0x5fff]
[    8.905845] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    8.905850] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    8.905858] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    8.905869] pci 0000:00:03.0: PCI bridge to [bus 04]
[    8.905884] pci 0000:06:02.0: PCI bridge to [bus 07]
[    8.905905] pci 0000:06:04.0: PCI bridge to [bus 08]
[    8.905925] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    8.905946] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    8.905961] pci 0000:0a:02.0: PCI bridge to [bus 0b]
[    8.905981] pci 0000:0a:04.0: PCI bridge to [bus 0c]
[    8.906002] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    8.906022] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    8.906037] pci 0000:00:09.0: PCI bridge to [bus 0d]
[    8.906052] pci 0000:00:0a.0: PCI bridge to [bus 0e]
[    8.906068] pci 0000:0f:00.0: BAR 6: assigned [mem 0xb1c00000-0xb1c7ffff pref]
[    8.906071] pci 0000:00:1c.0: PCI bridge to [bus 0f]
[    8.906076] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    8.906084] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    8.906090] pci 0000:00:1c.0:   bridge window [mem 0xb1c00000-0xb1efffff pref]
[    8.906100] pci 0000:10:00.0: BAR 6: assigned [mem 0xb1810000-0xb181ffff pref]
[    8.906103] pci 0000:00:1c.4: PCI bridge to [bus 10]
[    8.906108] pci 0000:00:1c.4:   bridge window [io  0x4000-0x4fff]
[    8.906115] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    8.906122] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    8.906131] pci 0000:00:1c.5: PCI bridge to [bus 11]
[    8.906136] pci 0000:00:1c.5:   bridge window [io  0x5000-0x5fff]
[    8.906143] pci 0000:00:1c.5:   bridge window [mem 0xb1f00000-0xb20fffff]
[    8.906150] pci 0000:00:1c.5:   bridge window [mem 0xb2100000-0xb22fffff 64bit pref]
[    8.906159] pci 0000:00:1e.0: PCI bridge to [bus 12]
[    8.906182] xen: registering gsi 28 triggering 0 polarity 1
[    8.906196] xen: --> pirq=28 -> irq=28 (gsi=28)
[    8.906232] xen: registering gsi 24 triggering 0 polarity 1
[    8.906238] xen: --> pirq=24 -> irq=24 (gsi=24)
[    8.906270] xen: registering gsi 26 triggering 0 polarity 1
[    8.906276] xen: --> pirq=26 -> irq=26 (gsi=26)
[    8.906326] xen: registering gsi 30 triggering 0 polarity 1
[    8.906332] xen: --> pirq=30 -> irq=30 (gsi=30)
[    8.906381] xen: registering gsi 32 triggering 0 polarity 1
[    8.906387] xen: --> pirq=32 -> irq=32 (gsi=32)
[    8.906419] xen: registering gsi 33 triggering 0 polarity 1
[    8.906425] xen: --> pirq=33 -> irq=33 (gsi=33)
[    8.906458] xen: registering gsi 16 triggering 0 polarity 1
[    8.906466] xen: --> pirq=16 -> irq=16 (gsi=16)
[    8.906498] xen: registering gsi 16 triggering 0 polarity 1
[    8.906501] Already setup the GSI :16
[    8.906508] xen: registering gsi 17 triggering 0 polarity 1
[    8.906513] xen: --> pirq=17 -> irq=17 (gsi=17)
[    8.906549] pci 0000:00:1e.0: setting latency timer to 64
[    8.906555] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    8.906558] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    8.906561] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    8.906564] pci_bus 0000:00: resource 7 [mem 0xfed40000-0xfedfffff]
[    8.906568] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xfdffffff]
[    8.906571] pci_bus 0000:01: resource 0 [io  0x2000-0x2fff]
[    8.906574] pci_bus 0000:01: resource 1 [mem 0xb1a00000-0xb1afffff]
[    8.906578] pci_bus 0000:0f: resource 0 [io  0x1000-0x1fff]
[    8.906581] pci_bus 0000:0f: resource 1 [mem 0xb1900000-0xb19fffff]
[    8.906584] pci_bus 0000:0f: resource 2 [mem 0xb1c00000-0xb1efffff pref]
[    8.906587] pci_bus 0000:10: resource 0 [io  0x4000-0x4fff]
[    8.906590] pci_bus 0000:10: resource 1 [mem 0xb1000000-0xb18fffff]
[    8.906594] pci_bus 0000:10: resource 2 [mem 0xb0000000-0xb0ffffff 64bit pref]
[    8.906597] pci_bus 0000:11: resource 0 [io  0x5000-0x5fff]
[    8.906600] pci_bus 0000:11: resource 1 [mem 0xb1f00000-0xb20fffff]
[    8.906603] pci_bus 0000:11: resource 2 [mem 0xb2100000-0xb22fffff 64bit pref]
[    8.906607] pci_bus 0000:12: resource 4 [io  0x0000-0x0cf7]
[    8.906609] pci_bus 0000:12: resource 5 [io  0x0d00-0xffff]
[    8.906612] pci_bus 0000:12: resource 6 [mem 0x000a0000-0x000bffff]
[    8.906615] pci_bus 0000:12: resource 7 [mem 0xfed40000-0xfedfffff]
[    8.906618] pci_bus 0000:12: resource 8 [mem 0xb0000000-0xfdffffff]
[    8.906622] pci_bus 0000:fe: resource 4 [io  0x0000-0xffff]
[    8.906624] pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff]
[    8.906628] pci_bus 0000:ff: resource 4 [io  0x0000-0xffff]
[    8.906631] pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff]
[    8.906665] NET: Registered protocol family 2
[    8.906794] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    8.907486] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    8.907663] TCP: Hash tables configured (established 262144 bind 65536)
[    8.907693] TCP: reno registered
[    8.907700] UDP hash table entries: 16384 (order: 7, 524288 bytes)
[    8.907798] UDP-Lite hash table entries: 16384 (order: 7, 524288 bytes)
[    8.907939] NET: Registered protocol family 1
[    8.908037] RPC: Registered named UNIX socket transport module.
[    8.908042] RPC: Registered udp transport module.
[    8.908045] RPC: Registered tcp transport module.
[    8.908047] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    8.908110] pci 0000:00:1a.0: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908118] xen: registering gsi 19 triggering 0 polarity 1
[    8.908128] xen: --> pirq=19 -> irq=19 (gsi=19)
[    8.908182] pci 0000:00:1a.1: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908188] xen: registering gsi 19 triggering 0 polarity 1
[    8.908191] Already setup the GSI :19
[    8.908217] pci 0000:00:1a.2: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908222] xen: registering gsi 19 triggering 0 polarity 1
[    8.908225] Already setup the GSI :19
[    8.908250] pci 0000:00:1a.7: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908257] xen: registering gsi 19 triggering 0 polarity 1
[    8.908259] Already setup the GSI :19
[    8.908413] pci 0000:00:1d.0: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908420] xen: registering gsi 16 triggering 0 polarity 1
[    8.908422] Already setup the GSI :16
[    8.908448] pci 0000:00:1d.1: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908453] xen: registering gsi 16 triggering 0 polarity 1
[    8.908455] Already setup the GSI :16
[    8.908481] pci 0000:00:1d.2: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908486] xen: registering gsi 16 triggering 0 polarity 1
[    8.908489] Already setup the GSI :16
[    8.908514] pci 0000:00:1d.7: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908520] xen: registering gsi 16 triggering 0 polarity 1
[    8.908523] Already setup the GSI :16
[    8.908708] pci 0000:01:00.0: calling quirk_e100_interrupt+0x0/0x18d
[    8.908716] pci 0000:01:00.1: calling quirk_e100_interrupt+0x0/0x18d
[    8.908740] pci 0000:10:00.0: calling pci_fixup_video+0x0/0xc1
[    8.908747] pci 0000:10:00.0: Boot video device
[    8.908836] PCI: CLS 64 bytes, default 64
[    8.908869] Unpacking initramfs...
[    8.920521] Freeing initrd memory: 14764k freed
[    8.926621] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    8.926956] NFS: Registering the id_resolver key type
[    8.926969] Key type id_resolver registered
[    8.926971] Key type id_legacy registered
[    8.926984] NTFS driver 2.1.30 [Flags: R/O].
[    8.927096] fuse init (API version 7.20)
[    8.927337] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[    8.928200] Btrfs loaded
[    8.928212] msgmni has been set to 32768
[    8.928580] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    8.928585] io scheduler noop registered
[    8.928587] io scheduler deadline registered
[    8.928592] io scheduler cfq registered (default)
[    8.931221] aer 0000:00:01.0:pcie02: service driver aer loaded
[    8.931259] aer 0000:00:03.0:pcie02: service driver aer loaded
[    8.931313] aer 0000:00:05.0:pcie02: service driver aer loaded
[    8.931364] aer 0000:00:07.0:pcie02: service driver aer loaded
[    8.931401] aer 0000:00:09.0:pcie02: service driver aer loaded
[    8.931439] aer 0000:00:0a.0:pcie02: service driver aer loaded
[    8.931456] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[    8.931459] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    8.931462] pci 0000:01:00.1: Signaling PME through PCIe PME interrupt
[    8.931469] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[    8.931480] pcieport 0000:00:03.0: Signaling PME through PCIe PME interrupt
[    8.931486] pcie_pme 0000:00:03.0:pcie01: service driver pcie_pme loaded
[    8.931497] pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt
[    8.931500] pcieport 0000:05:00.0: Signaling PME through PCIe PME interrupt
[    8.931504] pcieport 0000:06:02.0: Signaling PME through PCIe PME interrupt
[    8.931507] pcieport 0000:06:04.0: Signaling PME through PCIe PME interrupt
[    8.931513] pcie_pme 0000:00:05.0:pcie01: service driver pcie_pme loaded
[    8.931526] pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt
[    8.931529] pcieport 0000:09:00.0: Signaling PME through PCIe PME interrupt
[    8.931532] pcieport 0000:0a:02.0: Signaling PME through PCIe PME interrupt
[    8.931535] pcieport 0000:0a:04.0: Signaling PME through PCIe PME interrupt
[    8.931542] pcie_pme 0000:00:07.0:pcie01: service driver pcie_pme loaded
[    8.931553] pcieport 0000:00:09.0: Signaling PME through PCIe PME interrupt
[    8.931559] pcie_pme 0000:00:09.0:pcie01: service driver pcie_pme loaded
[    8.931570] pcieport 0000:00:0a.0: Signaling PME through PCIe PME interrupt
[    8.931576] pcie_pme 0000:00:0a.0:pcie01: service driver pcie_pme loaded
[    8.931606] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[    8.931610] pci 0000:0f:00.0: Signaling PME through PCIe PME interrupt
[    8.931616] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[    8.931647] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt
[    8.931651] pci 0000:10:00.0: Signaling PME through PCIe PME interrupt
[    8.931657] pcie_pme 0000:00:1c.4:pcie01: service driver pcie_pme loaded
[    8.931686] pcieport 0000:00:1c.5: Signaling PME through PCIe PME interrupt
[    8.931694] pcie_pme 0000:00:1c.5:pcie01: service driver pcie_pme loaded
[    8.931798] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
[    8.931806] ACPI: Sleep Button [SLPB]
[    8.931832] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    8.931836] ACPI: Power Button [PWRF]
[    8.931901] ACPI: Requesting acpi_cpufreq
[    8.932364] Monitor-Mwait will be used to enter C-1 state
[    8.932422] Monitor-Mwait will be used to enter C-3 state
[    8.936323] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    8.956986] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    8.957582] hpet_acpi_add: no address or irqs in _CRS
[    8.957661] Non-volatile memory driver v1.3
[    8.957664] Linux agpgart interface v0.103
[    8.957780] ahci 0000:00:1f.2: version 3.0
[    8.957793] xen: registering gsi 18 triggering 0 polarity 1
[    8.957805] xen: --> pirq=18 -> irq=18 (gsi=18)
[    8.958019] ahci 0000:00:1f.2: forcing PORTS_IMPL to 0x3f
[    8.958084] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[    8.958090] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc 
[    8.958097] ahci 0000:00:1f.2: setting latency timer to 64
[    8.958954] scsi0 : ahci
[    8.959091] scsi1 : ahci
[    8.959235] scsi2 : ahci
[    8.959404] scsi3 : ahci
[    8.959589] scsi4 : ahci
[    8.959726] scsi5 : ahci
[    8.959753] ata1: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20100 irq 128
[    8.959758] ata2: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20180 irq 128
[    8.959761] ata3: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20200 irq 128
[    8.959765] ata4: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20280 irq 128
[    8.959769] ata5: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20300 irq 128
[    8.959773] ata6: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20380 irq 128
[    8.959833] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
[    8.959836] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    8.959862] igb: Intel(R) Gigabit Ethernet Network Driver - version 4.0.1-k
[    8.959865] igb: Copyright (c) 2007-2012 Intel Corporation.
[    8.959882] xen: registering gsi 40 triggering 0 polarity 1
[    8.959891] xen: --> pirq=40 -> irq=40 (gsi=40)
[    8.960770] igb 0000:01:00.0: PHY reset is blocked due to SOL/IDER session.
[    9.006468] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
[    9.006474] igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e4
[    9.006551] igb 0000:01:00.0: eth0: PBA No: 0080FF-0FF
[    9.006554] igb 0000:01:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[    9.006566] xen: registering gsi 28 triggering 0 polarity 1
[    9.006570] Already setup the GSI :28
[    9.197779] igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
[    9.197784] igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e5
[    9.197861] igb 0000:01:00.1: eth1: PBA No: 0080FF-0FF
[    9.197864] igb 0000:01:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[    9.197882] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.1-k
[    9.197885] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    9.197898] sky2: driver version 1.30
[    9.198251] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    9.198279] xen: registering gsi 19 triggering 0 polarity 1
[    9.198289] Already setup the GSI :19
[    9.198305] ehci_hcd 0000:00:1a.7: enabling bus mastering
[    9.198312] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[    9.198317] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[    9.198324] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[    9.198344] ehci_hcd 0000:00:1a.7: debug port 1
[    9.202402] ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
[    9.202459] ehci_hcd 0000:00:1a.7: irq 19, io mem 0xb1b22000
[    9.213520] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[    9.213578] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    9.213585] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.213591] usb usb1: Product: EHCI Host Controller
[    9.213597] usb usb1: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 ehci_hcd
[    9.213604] usb usb1: SerialNumber: 0000:00:1a.7
[    9.213820] hub 1-0:1.0: USB hub found
[    9.213830] hub 1-0:1.0: 6 ports detected
[    9.213915] xen: registering gsi 16 triggering 0 polarity 1
[    9.213919] Already setup the GSI :16
[    9.213934] ehci_hcd 0000:00:1d.7: enabling bus mastering
[    9.213941] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[    9.213946] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    9.213951] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[    9.213968] ehci_hcd 0000:00:1d.7: debug port 1
[    9.217965] ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
[    9.218021] ehci_hcd 0000:00:1d.7: irq 16, io mem 0xb1b21000
[    9.229529] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    9.229576] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    9.229583] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.229589] usb usb2: Product: EHCI Host Controller
[    9.229594] usb usb2: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 ehci_hcd
[    9.229601] usb usb2: SerialNumber: 0000:00:1d.7
[    9.229809] hub 2-0:1.0: USB hub found
[    9.229821] hub 2-0:1.0: 6 ports detected
[    9.229906] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    9.229919] uhci_hcd: USB Universal Host Controller Interface driver
[    9.229933] xen: registering gsi 19 triggering 0 polarity 1
[    9.229937] Already setup the GSI :19
[    9.229942] uhci_hcd 0000:00:1a.0: enabling bus mastering
[    9.229949] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[    9.229954] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[    9.229959] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[    9.229990] uhci_hcd 0000:00:1a.0: irq 19, io base 0x000030e0
[    9.230134] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    9.230138] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.230141] usb usb3: Product: UHCI Host Controller
[    9.230144] usb usb3: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.230148] usb usb3: SerialNumber: 0000:00:1a.0
[    9.230321] hub 3-0:1.0: USB hub found
[    9.230330] hub 3-0:1.0: 2 ports detected
[    9.230404] xen: registering gsi 19 triggering 0 polarity 1
[    9.230408] Already setup the GSI :19
[    9.230416] uhci_hcd 0000:00:1a.1: enabling bus mastering
[    9.230423] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[    9.230427] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[    9.230433] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[    9.230465] uhci_hcd 0000:00:1a.1: irq 19, io base 0x000030c0
[    9.230537] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    9.230541] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.230545] usb usb4: Product: UHCI Host Controller
[    9.230548] usb usb4: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.230551] usb usb4: SerialNumber: 0000:00:1a.1
[    9.230684] hub 4-0:1.0: USB hub found
[    9.230693] hub 4-0:1.0: 2 ports detected
[    9.230768] xen: registering gsi 19 triggering 0 polarity 1
[    9.230772] Already setup the GSI :19
[    9.230778] uhci_hcd 0000:00:1a.2: enabling bus mastering
[    9.230784] uhci_hcd 0000:00:1a.2: setting latency timer to 64
[    9.230789] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    9.230797] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    9.230828] uhci_hcd 0000:00:1a.2: irq 19, io base 0x000030a0
[    9.230896] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    9.230900] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.230904] usb usb5: Product: UHCI Host Controller
[    9.230907] usb usb5: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.230911] usb usb5: SerialNumber: 0000:00:1a.2
[    9.231047] hub 5-0:1.0: USB hub found
[    9.231056] hub 5-0:1.0: 2 ports detected
[    9.231160] xen: registering gsi 16 triggering 0 polarity 1
[    9.231164] Already setup the GSI :16
[    9.231170] uhci_hcd 0000:00:1d.0: enabling bus mastering
[    9.231177] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[    9.231181] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    9.231187] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[    9.231217] uhci_hcd 0000:00:1d.0: irq 16, io base 0x00003080
[    9.231290] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[    9.231294] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.231297] usb usb6: Product: UHCI Host Controller
[    9.231300] usb usb6: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.231304] usb usb6: SerialNumber: 0000:00:1d.0
[    9.231481] hub 6-0:1.0: USB hub found
[    9.231502] hub 6-0:1.0: 2 ports detected
[    9.231560] xen: registering gsi 16 triggering 0 polarity 1
[    9.231564] Already setup the GSI :16
[    9.231570] uhci_hcd 0000:00:1d.1: enabling bus mastering
[    9.231577] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[    9.231582] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    9.231587] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[    9.231617] uhci_hcd 0000:00:1d.1: irq 16, io base 0x00003060
[    9.231687] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[    9.231691] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.231695] usb usb7: Product: UHCI Host Controller
[    9.231698] usb usb7: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.231701] usb usb7: SerialNumber: 0000:00:1d.1
[    9.231835] hub 7-0:1.0: USB hub found
[    9.231844] hub 7-0:1.0: 2 ports detected
[    9.231924] xen: registering gsi 16 triggering 0 polarity 1
[    9.231928] Already setup the GSI :16
[    9.231934] uhci_hcd 0000:00:1d.2: enabling bus mastering
[    9.231940] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[    9.231945] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    9.231950] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[    9.231980] uhci_hcd 0000:00:1d.2: irq 16, io base 0x00003040
[    9.232050] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[    9.232054] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.232057] usb usb8: Product: UHCI Host Controller
[    9.232060] usb usb8: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.232064] usb usb8: SerialNumber: 0000:00:1d.2
[    9.232202] hub 8-0:1.0: USB hub found
[    9.232211] hub 8-0:1.0: 2 ports detected
[    9.232324] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    9.985548] ata3: failed to resume link (SControl 0)
[    9.985560] ata3: SATA link down (SStatus 0 SControl 0)
[    9.985570] ata2: failed to resume link (SControl 0)
[    9.985582] ata2: SATA link down (SStatus 0 SControl 0)
[    9.989511] ata4: failed to resume link (SControl 0)
[    9.989522] ata4: SATA link down (SStatus 0 SControl 0)
[    9.989535] ata6: failed to resume link (SControl 0)
[    9.989547] ata6: SATA link down (SStatus 0 SControl 0)
[    9.989556] ata1: failed to resume link (SControl 0)
[    9.989568] ata1: SATA link down (SStatus 0 SControl 0)
[   10.277949] i8042: No controller found
[   10.278119] mousedev: PS/2 mouse device common for all mice
[   10.278762] input: PC Speaker as /devices/platform/pcspkr/input/input2
[   10.278912] rtc_cmos 00:03: RTC can wake from S4
[   10.279104] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[   10.279194] rtc0: alarms up to one month, y3k, 114 bytes nvram
[   10.279234] device-mapper: uevent: version 1.0.3
[   10.279332] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
[   10.279644] usbcore: registered new interface driver usbhid
[   10.279647] usbhid: USB HID core driver
[   10.279725] TCP: cubic registered
[   10.279728] NET: Registered protocol family 17
[   10.279747] Key type dns_resolver registered
[   10.280161] registered taskstats version 1
[   10.281423] rtc_cmos 00:03: setting system clock to 2013-02-04 09:28:23 UTC (1359970103)
[   10.281433] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[   10.281437] EDD information not available.
[   10.365566] ata5: failed to resume link (SControl 0)
[   10.365583] ata5: SATA link down (SStatus 0 SControl 0)
[   10.366099] Freeing unused kernel memory: 636k freed
[   10.366228] Write protecting the kernel read-only data: 12288k
[   10.369824] Freeing unused kernel memory: 1640k freed
[   10.370670] Freeing unused kernel memory: 1780k freed
[   10.450801] Fusion MPT base driver 3.04.20
[   10.450806] Copyright (c) 1999-2008 LSI Corporation
[   10.451327] Fusion MPT SAS Host driver 3.04.20
[   10.451362] xen: registering gsi 16 triggering 0 polarity 1
[   10.451367] Already setup the GSI :16
[   10.451638] mptbase: ioc0: Initiating bringup
[   10.605551] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[   10.739714] usb 2-1: New USB device found, idVendor=05e3, idProduct=0719
[   10.739724] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[   10.739732] usb 2-1: Product: USB Storage
[   10.739737] usb 2-1: SerialNumber: 000000000033
[   10.977529] usb 5-1: new full-speed USB device number 2 using uhci_hcd
[   11.017542] ioc0: LSISAS1078 C2: Capabilities={Initiator}
[   11.135930] usb 5-1: New USB device found, idVendor=046b, idProduct=ff10
[   11.135940] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   11.135947] usb 5-1: Product: Virtual Keyboard and Mouse
[   11.135953] usb 5-1: Manufacturer: American Megatrends Inc.
[   11.135958] usb 5-1: SerialNumber: serial
[   11.145157] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/input/input3
[   11.145425] hid-generic 0003:046B:FF10.0001: input,hidraw0: USB HID v1.10 Keyboard [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input0
[   11.151093] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.1/input/input4
[   11.151360] hid-generic 0003:046B:FF10.0002: input,hidraw1: USB HID v1.10 Mouse [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input1
[   23.819242] scsi6 : ioc0: LSISAS1078 C2, FwRev=011b0000h, Ports=1, MaxQ=276, IRQ=16
[   23.823655] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221000000000000
[   23.827124] scsi 6:0:0:0: Direct-Access     ATA      ST9500530NS      SN04 PQ: 0 ANSI: 5
[   23.827774] sd 6:0:0:0: Attached scsi generic sg0 type 0
[   23.828186] sd 6:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[   23.882101] sd 6:0:0:0: [sda] Write Protect is off
[   23.882110] sd 6:0:0:0: [sda] Mode Sense: 73 00 00 08
[   23.884318] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   23.993837]  sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
[   24.050901] sd 6:0:0:0: [sda] Attached SCSI disk
[   24.073501] Initialising Xen virtual ethernet driver.
[   24.089738] udev: starting version 147
[   25.225175] kjournald starting.  Commit interval 5 seconds
[   25.225985] EXT3-fs (sda6): using internal journal
[   25.225996] EXT3-fs (sda6): mounted filesystem with ordered data mode
[   27.430759] udev: starting version 147
[   27.533221] tpm_tis 00:09: 1.2 TPM (device-id 0x0, rev-id 78)
[   27.541200] xen: registering gsi 18 triggering 0 polarity 1
[   27.541208] Already setup the GSI :18
[   27.541292] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[   27.589606] tpm_tis 00:09: TPM is disabled/deactivated (0x6)
[   27.676939] Initializing USB Mass Storage driver...
[   27.677509] scsi7 : usb-storage 2-1:1.0
[   27.677593] usbcore: registered new interface driver usb-storage
[   27.677597] USB Mass Storage support registered.
[   27.689507] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0xc
[   27.689515] i7core_edac: Unknown symbol edac_mc_del_mc (err 0)
[   27.689528] i7core_edac: Unknown symbol edac_mc_add_mc (err 0)
[   27.689536] i7core_edac: Unknown symbol edac_pci_create_generic_ctl (err 0)
[   27.689540] i7core_edac: Unknown symbol edac_mc_alloc (err 0)
[   27.689546] i7core_edac: Unknown symbol edac_mc_free (err 0)
[   27.689552] i7core_edac: Unknown symbol edac_mc_handle_error (err 0)
[   27.689565] i7core_edac: Unknown symbol edac_pci_release_generic_ctl (err 0)
[   27.762633] microcode: CPU1 sig=0x206c2, pf=0x1, revision=0xc
[   27.771813] microcode: CPU2 sig=0x206c2, pf=0x1, revision=0xc
[   27.781360] microcode: CPU3 sig=0x206c2, pf=0x1, revision=0xc
[   27.790101] microcode: CPU4 sig=0x206c2, pf=0x1, revision=0xc
[   27.791214] NET: Registered protocol family 10
[   27.799375] microcode: CPU5 sig=0x206c2, pf=0x1, revision=0xc
[   27.809037] microcode: CPU6 sig=0x206c2, pf=0x1, revision=0xc
[   27.818861] microcode: CPU7 sig=0x206c2, pf=0x1, revision=0xc
[   27.828158] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   28.679744] scsi 7:0:0:0: CD-ROM            TEAC     DV-W28S-V        1.0A PQ: 0 ANSI: 0
[   28.684959] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[   28.684969] cdrom: Uniform CD-ROM driver Revision: 3.20
[   28.685236] sr 7:0:0:0: Attached scsi CD-ROM sr0
[   28.685401] sr 7:0:0:0: Attached scsi generic sg1 type 5
[   28.824831] Adding 2096476k swap on /dev/sda2.  Priority:-1 extents:1 across:2096476k 
[   30.833821] loop: module loaded
[   30.971071] kjournald starting.  Commit interval 5 seconds
[   30.971670] EXT3-fs (sda5): mounted filesystem with ordered data mode
[   40.070007] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   40.070260] igb: eth0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
[   40.070331] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   42.489429] Bridge firewalling registered
[   42.502752] device eth0 entered promiscuous mode
[   42.509612] br0: port 1(eth0) entered forwarding state
[   42.509617] br0: port 1(eth0) entered forwarding state
[   48.476283] irqbalance[3575]: segfault at 4 ip 00007ff5b07d18ed sp 00007fff7fe80d50 error 6 in libc-2.11.3.so[7ff5b072e000+16d000]
[   48.639756] mcelog:3587 map pfn expected mapping type write-back for [mem 0x8f302000-0x8f302fff], got uncached-minus
[   48.639777] ------------[ cut here ]------------
[   48.639783] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x94/0xc0()
[   48.639784] Hardware name: S5520UR
[   48.639785] Modules linked in: bridge stp llc loop crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul ipv6 microcode usb_storage i2c_i801 joydev tpm_tis tpm tpm_bios xen_blkfront xen_netfront mptsas mptscsih mptbase scsi_transport_sas
[   48.639800] Pid: 3587, comm: mcelog Not tainted 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 #1
[   48.639801] Call Trace:
[   48.639804]  [<ffffffff8103d1d4>] ? untrack_pfn+0x94/0xc0
[   48.639809]  [<ffffffff81043f0a>] warn_slowpath_common+0x7a/0xb0
[   48.639811]  [<ffffffff81043f55>] warn_slowpath_null+0x15/0x20
[   48.639812]  [<ffffffff8103d1d4>] untrack_pfn+0x94/0xc0
[   48.639817]  [<ffffffff810d2cdb>] unmap_single_vma+0x77b/0x7f0
[   48.639819]  [<ffffffff810d2daa>] unmap_vmas+0x5a/0x90
[   48.639821]  [<ffffffff810d5037>] exit_mmap+0x87/0x150
[   48.639823]  [<ffffffff81041cbd>] mmput+0x2d/0xd0
[   48.639825]  [<ffffffff810420cb>] dup_mm+0x36b/0x460
[   48.639827]  [<ffffffff81042af8>] copy_process+0x828/0x1120
[   48.639829]  [<ffffffff81043542>] do_fork+0x62/0x340
[   48.639834]  [<ffffffff8158a4c1>] ? sys_connect+0x71/0xa0
[   48.639836]  [<ffffffff81108090>] ? set_close_on_exec+0x40/0x80
[   48.639841]  [<ffffffff81014ad3>] sys_clone+0x23/0x30
[   48.639844]  [<ffffffff8165faf3>] stub_clone+0x13/0x20
[   48.639846]  [<ffffffff8165f869>] ? system_call_fastpath+0x16/0x1b
[   48.639847] ---[ end trace 32d9c32b0defe75a ]---
[   50.101769] Event-channel device installed.
[   50.174766] xen-pciback: backend is vpci

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="screenlog.0.txt"


kernel /boot/vmlinuz-kernel-linux-3_7 root=bax.arch.suse.de:/olaf_xenimages/bug
694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M ignore_loglevel debug
   [Linux-bzImage, setup=0x3c00, size=0x48ea10]
initrd /boot/initrd-kernel-linux-3_7
   [Linux-initrd @ 0x1f3a3000, 0x44c8b0 bytes]

[    0.000000] Linux version 3.7.5-9.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 (abuild@build21) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Mon Jan 28 07:49:06 UTC 2013
[    0.000000] Command line: root=bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M ignore_loglevel debug
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f7fffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.3.26502-20130204 02/04/2013
[    0.000000] Xen version 4.3.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] HVMOP_pagetable_dying not supported
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x1f800 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 00F0000000 mask FFF8000000 uncachable
[    0.000000]   1 base 00F8000000 mask FFFC000000 uncachable
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at [ffff8800000fbba0]
[    0.000000] initial memory mapped: [mem 0x00000000-0x1fffffff]
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 28672
[    0.000000] init_memory_mapping: [mem 0x00000000-0x1f7fffff]
[    0.000000]  [mem 0x00000000-0x1f7fffff] page 2M
[    0.000000] kernel direct mapping tables up to 0x1f7fffff @ [mem 0x1f7fe000-0x1f7fffff]
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 2094252(99%)
[    0.000000] RAMDISK: [mem 0x1f3a3000-0x1f7effff]
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc00f5c0 00054 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00f280 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc003600 0BBF6 (v02    Xen      HVM 00000000 INTL 20081031)
[    0.000000] ACPI: FACS 00000000fc0035c0 00040
[    0.000000] ACPI: APIC 00000000fc00f380 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc00f4d0 00038 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc00f510 00028 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc00f540 00031 (v02    Xen      HVM 00000000 INTL 20081031)
[    0.000000] ACPI: SSDT 00000000fc00f580 00031 (v02    Xen      HVM 00000000 INTL 20081031)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000]  [ffffea0000000000-ffffea00007fffff] PMD -> [ffff88001a200000-ffff88001a9fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0x1f7fffff]
[    0.000000] On node 0 totalpages: 128910
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 7 pages reserved
[    0.000000]   DMA zone: 3911 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 1952 pages used for memmap
[    0.000000]   DMA32 zone: 122976 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: 15 Processors exceeds NR_CPUS limit of 8
[    0.000000] smpboot: Allowing 8 CPUs, 6 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] e820: [mem 0x1f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88001b000000 s78080 r8192 d24320 u262144
[    0.000000] pcpu-alloc: s78080 r8192 d24320 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 126887
[    0.000000] Kernel command line: root=bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M ignore_loglevel debug
[    0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 420008k/516096k available (6541k kernel code, 456k absent, 95632k reserved, 6150k data, 636k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:4352 nr_irqs:1152 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Detected 2926.444 MHz processor
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5852.88 BogoMIPS (lpj=11705776)
[    0.012002] pid_max: default: 32768 minimum: 301
[    0.014412] Mount-cache hash table entries: 256
[    0.016196] CPU: Physical Processor ID: 0
[    0.020003] CPU: Processor Core ID: 0
[    0.021984] mce: CPU supports 2 MCE banks
[    0.024025] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    0.024025] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    0.024025] tlb_flushall_shift: 6
[    0.028246] Freeing SMP alternatives: 28k freed
[    0.036405] ACPI: Core revision 20120913
[    0.044382] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.088011] smpboot: CPU0: Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz (fam: 06, model: 2c, stepping: 02)
[    0.097544] Xen: using vcpuop timer interface
[    0.100007] installing Xen timer for CPU 0
[    0.104081] Performance Events: 16-deep LBR, Westmere events, Intel PMU driver.
[    0.108008] perf_event_intel: CPUID marked event: 'bus cycles' unavailable
[    0.112011] ... version:                3
[    0.114519] ... bit width:              48
[    0.116005] ... generic registers:      4
[    0.118496] ... value mask:             0000ffffffffffff
[    0.120005] ... max period:             000000007fffffff
[    0.123427] ... fixed-purpose events:   3
[    0.124004] ... event mask:             000000070000000f
[    0.127674] register_vcpu_info failed: err=-22
[    0.128021] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
[    0.144053] Brought up 2 CPUs
[    0.144054] smpboot: Total of 2 processors activated (11705.77 BogoMIPS)

[    0.154834] devtmpfs: initialized
[    0.156169] NET: Registered protocol family 16
[    0.160133] ACPI: bus type pci registered
[    0.164270] PCI: Using configuration type 1 for base access
[    0.168912] bio: create slab <bio-0> at 0
[    0.170892] ACPI: Added _OSI(Module Device)
[    0.172016] ACPI: Added _OSI(Processor Device)
[    0.175442] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.176012] ACPI: Added _OSI(Processor Aggregator Device)
[    0.182021] ACPI: EC: Look up EC in DSDT
[    0.189510] ACPI: Interpreter enabled
[    0.192012] ACPI: (supports S0 S3 S4 S5)
[    0.195294] ACPI: Using IOAPIC for interrupt routing
[    0.249933] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.252089] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.256121] pci_root PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    0.260041] PCI host bridge to bus 0000:00
[    0.263031] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.264011] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.268010] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.272010] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.276010] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    0.280010] pci_bus 0000:00: scanning bus
[    0.283178] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    0.284015] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0xa
[    0.289865] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    0.294911] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    0.297940] pci 0000:00:01.1: reg 20: [io  0xc100-0xc10f]
[    0.301283] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[    0.304063] pci 0000:00:01.3: calling acpi_pm_check_blacklist+0x0/0x3b
[    0.308009] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
[    0.308009] * this clock source is slow. Consider trying other clock sources
[    0.314390] pci 0000:00:01.3: calling quirk_piix4_acpi+0x0/0x177
[    0.316059] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    0.320329] pci 0000:00:01.3: calling pci_fixup_piix4_acpi+0x0/0x10
[    0.324647] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[    0.328419] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.332353] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff]
[    0.338132] pci 0000:00:03.0: [5853:0001] type 00 class 0xff8000
[    0.340472] pci 0000:00:03.0: reg 10: [io  0xc000-0xc0ff]
[    0.344377] pci 0000:00:03.0: reg 14: [mem 0xf2000000-0xf2ffffff pref]
[    0.351212] pci_bus 0000:00: fixups for bus
[    0.352011] pci_bus 0000:00: bus scan returning with max=00
[    0.356010] pci_bus 0000:00: on NUMA node 0
[    0.359023] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.360469]  pci0000:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[    0.364010]  pci0000:00: Unable to request _OSC control (_OSC support mask: 0x08)
[    0.567295] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    0.569759] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.573643] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.577717] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    0.581589] xen/balloon: Initialising balloon driver.
[    0.584055] xen-balloon: Initialising balloon driver.
[    0.588099] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.592010] vgaarb: loaded
[    0.594043] vgaarb: bridge control possible 0000:00:02.0
[    0.596075] SCSI subsystem initialized
[    0.598940] ACPI: bus type scsi registered
[    0.600052] libata version 3.00 loaded.
[    0.603067] ACPI: bus type usb registered
[    0.604033] usbcore: registered new interface driver usbfs
[    0.608021] usbcore: registered new interface driver hub
[    0.612027] usbcore: registered new device driver usb
[    0.615809] PCI: Using ACPI for IRQ routing
[    0.616009] PCI: pci_cache_line_size set to 64 bytes
[    0.619915] pci 0000:00:01.1: BAR 0: reserving [io  0x01f0-0x01f7 flags 0x110] (d=0, p=0)
[    0.620011] pci 0000:00:01.1: BAR 1: reserving [io  0x03f6 flags 0x110] (d=0, p=0)
[    0.624011] pci 0000:00:01.1: BAR 2: reserving [io  0x0170-0x0177 flags 0x110] (d=0, p=0)
[    0.628011] pci 0000:00:01.1: BAR 3: reserving [io  0x0376 flags 0x110] (d=0, p=0)
[    0.632012] pci 0000:00:01.1: BAR 4: reserving [io  0xc100-0xc10f flags 0x40101] (d=0, p=0)
[    0.636112] pci 0000:00:02.0: BAR 0: reserving [mem 0xf0000000-0xf1ffffff flags 0x42208] (d=0, p=0)
[    0.640010] pci 0000:00:02.0: BAR 1: reserving [mem 0xf3000000-0xf3000fff flags 0x40200] (d=0, p=0)
[    0.644069] pci 0000:00:03.0: BAR 0: reserving [io  0xc000-0xc0ff flags 0x40101] (d=0, p=0)
[    0.648011] pci 0000:00:03.0: BAR 1: reserving [mem 0xf2000000-0xf2ffffff flags 0x42208] (d=0, p=0)
[    0.652292] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[    0.656010] e820: reserve RAM buffer [mem 0x1f800000-0x1fffffff]
[    0.660157] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    0.664036] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.668000] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.671132] Switching to clocksource xen
[    0.672072] pnp: PnP ACPI init
[    0.674017] ACPI: bus type pnp registered
[    0.676000] pnp 00:00: [mem 0x00000000-0x0009ffff]
[    0.676000] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.683863] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.688359] pnp 00:01: [bus 00-ff]
[    0.690518] pnp 00:01: [io  0x0cf8-0x0cff]
[    0.693072] pnp 00:01: [io  0x0000-0x0cf7 window]
[    0.695954] pnp 00:01: [io  0x0d00-0xffff window]
[    0.698918] pnp 00:01: [mem 0x000a0000-0x000bffff window]
[    0.702290] pnp 00:01: [mem 0xf0000000-0xfbffffff window]
[    0.705672] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.709770] pnp 00:02: [mem 0xfed00000-0xfed003ff]
[    0.712672] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.716786] pnp 00:03: [io  0x0010-0x001f]
[    0.719274] pnp 00:03: [io  0x0022-0x002d]
[    0.721849] pnp 00:03: [io  0x0030-0x003f]
[    0.724404] pnp 00:03: [io  0x0044-0x005f]
[    0.726922] pnp 00:03: [io  0x0062-0x0063]
[    0.729497] pnp 00:03: [io  0x0065-0x006f]
[    0.731978] pnp 00:03: [io  0x0072-0x007f]
[    0.734612] pnp 00:03: [io  0x0080]
[    0.736808] pnp 00:03: [io  0x0084-0x0086]
[    0.739319] pnp 00:03: [io  0x0088]
[    0.741566] pnp 00:03: [io  0x008c-0x008e]
[    0.744145] pnp 00:03: [io  0x0090-0x009f]
[    0.746686] pnp 00:03: [io  0x00a2-0x00bd]
[    0.749253] pnp 00:03: [io  0x00e0-0x00ef]
[    0.751774] pnp 00:03: [io  0x08a0-0x08a3]
[    0.754355] pnp 00:03: [io  0x0cc0-0x0ccf]
[    0.756887] pnp 00:03: [io  0x04d0-0x04d1]
[    0.759493] system 00:03: [io  0x08a0-0x08a3] has been reserved
[    0.763228] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
[    0.766904] system 00:03: [io  0x04d0-0x04d1] has been reserved
[    0.770558] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.774805] pnp 00:04: [dma 4]
[    0.776778] pnp 00:04: [io  0x0000-0x000f]
[    0.779329] pnp 00:04: [io  0x0081-0x0083]
[    0.781899] pnp 00:04: [io  0x0087]
[    0.784118] pnp 00:04: [io  0x0089-0x008b]
[    0.786645] pnp 00:04: [io  0x008f]
[    0.788826] pnp 00:04: [io  0x00c0-0x00df]
[    0.791344] pnp 00:04: [io  0x0480-0x048f]
[    0.793925] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.798000] pnp 00:05: [io  0x0070-0x0071]
[    0.800522] xen: --> pirq=16 -> irq=8 (gsi=8)
[    0.803328] pnp 00:05: [irq 8]
[    0.805247] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.809211] pnp 00:06: [io  0x0061]
[    0.811359] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.815448] xen: --> pirq=17 -> irq=12 (gsi=12)
[    0.818295] pnp 00:07: [irq 12]
[    0.820313] pnp 00:07: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.824391] pnp 00:08: [io  0x0060]
[    0.826562] pnp 00:08: [io  0x0064]
[    0.828827] xen: --> pirq=18 -> irq=1 (gsi=1)
[    0.831460] pnp 00:08: [irq 1]
[    0.833383] pnp 00:08: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    0.837901] pnp 00:09: [io  0x03f0-0x03f5]
[    0.840445] pnp 00:09: [io  0x03f7]
[    0.842679] xen: --> pirq=19 -> irq=6 (gsi=6)
[    0.845446] pnp 00:09: [irq 6]
[    0.847320] pnp 00:09: [dma 2]
[    0.849307] pnp 00:09: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.853345] pnp 00:0a: [io  0x03f8-0x03ff]
[    0.855925] xen: --> pirq=20 -> irq=4 (gsi=4)
[    0.858704] pnp 00:0a: [irq 4]
[    0.860661] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.864752] pnp 00:0b: [io  0x0378-0x037f]
[    0.867304] xen: --> pirq=21 -> irq=7 (gsi=7)
[    0.870066] pnp 00:0b: [irq 7]
[    0.871934] pnp 00:0b: Plug and Play ACPI device, IDs PNP0400 (active)
[    0.876092] pnp 00:0c: [io  0x10c0-0x1141]
[    0.878636] pnp 00:0c: [io  0xb044-0xb047]
[    0.881200] system 00:0c: [io  0x10c0-0x1141] has been reserved
[    0.884899] system 00:0c: [io  0xb044-0xb047] has been reserved
[    0.888633] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.910161] pnp: PnP ACPI: found 13 devices
[    0.912735] ACPI: ACPI bus type pnp unregistered
[    0.920985] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.924522] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.928424] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.932368] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff]
[    0.936329] NET: Registered protocol family 2
[    0.939109] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.943720] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.948055] TCP: Hash tables configured (established 16384 bind 16384)
[    0.952007] TCP: reno registered
[    0.954122] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.957814] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.961781] NET: Registered protocol family 1
[    0.964644] RPC: Registered named UNIX socket transport module.
[    0.968303] RPC: Registered udp transport module.
[    0.971229] RPC: Registered tcp transport module.
[    0.974127] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.978124] pci 0000:00:00.0: calling quirk_natoma+0x0/0x2d
[    0.981627] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.985304] pci 0000:00:00.0: calling quirk_passive_release+0x0/0xa0
[    0.989263] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.992866] pci 0000:00:01.0: calling quirk_isa_dma_hangs+0x0/0x31
[    0.996657] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    1.000546] pci 0000:00:02.0: calling pci_fixup_video+0x0/0xc1
[    1.004286] pci 0000:00:02.0: Boot video device
[    1.007121] PCI: CLS 0 bytes, default 64
[    1.009631] Unpacking initramfs...
[    1.081590] Freeing initrd memory: 4404k freed
[    1.087058] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.091075] NFS: Registering the id_resolver key type
[    1.094234] Key type id_resolver registered
[    1.096921] Key type id_legacy registered
[    1.099456] NTFS driver 2.1.30 [Flags: R/O].
[    1.102302] fuse init (API version 7.20)
[    1.104824] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[    1.111244] Btrfs loaded
[    1.112829] msgmni has been set to 828
[    1.115526] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    1.120213] io scheduler noop registered
[    1.122645] io scheduler deadline registered
[    1.125307] io scheduler cfq registered (default)
[    1.128389] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    1.132877] ACPI: Power Button [PWRF]
[    1.135250] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    1.139847] ACPI: Sleep Button [SLPF]
[    1.179759] xen: --> pirq=22 -> irq=28 (gsi=28)
[    1.182740] Grant tables using version 1 layout.
[    1.185653] Grant table initialized
[    1.188183] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.219464] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.223520] Non-volatile memory driver v1.3
[    1.226155] Linux agpgart interface v0.103
[    1.228839] ata_piix 0000:00:01.1: version 2.13
[    1.231775] ata_piix 0000:00:01.1: setting latency timer to 64
[    1.235970] scsi0 : ata_piix
[    1.238022] scsi1 : ata_piix
[    1.239873] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc100 irq 14
[    1.244109] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc108 irq 15
[    1.248384] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
[    1.252594] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    1.256321] igb: Intel(R) Gigabit Ethernet Network Driver - version 4.0.1-k
[    1.260623] igb: Copyright (c) 2007-2012 Intel Corporation.
[    1.264079] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.1-k
[    1.268920] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    1.272532] sky2: driver version 1.30
[    1.274967] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.279127] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.283088] uhci_hcd: USB Universal Host Controller Interface driver
[    1.287132] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.295065] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.299017] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.302951] mousedev: PS/2 mouse device common for all mice
[    1.308186] input: PC Speaker as /devices/platform/pcspkr/input/input2
[    1.308324] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    1.322418] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    1.326271] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs
[    1.330205] device-mapper: uevent: version 1.0.3
[    1.333094] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
[    1.338340] cpuidle: using governor ladder
[    1.340929] cpuidle: using governor menu
[    1.343484] usbcore: registered new interface driver usbhid
[    1.346956] usbhid: USB HID core driver
[    1.349499] TCP: cubic registered
[    1.351492] NET: Registered protocol family 17
[    1.354387] Key type dns_resolver registered
[    1.357631] registered taskstats version 1
[    1.360352] XENBUS: Device with no driver: device/vbd/768
[    1.363781] XENBUS: Device with no driver: device/vkbd/0
[    1.367140] XENBUS: Device with no driver: device/vif/0
[    1.370651] rtc_cmos 00:05: setting system clock to 2013-02-04 09:33:40 UTC (1359970420)
[    1.375665] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[    1.407269] Freeing unused kernel memory: 636k freed
[    1.412902] Write protecting the kernel read-only data: 12288k
[    1.426157] Freeing unused kernel memory: 1640k freed
[    1.439757] Freeing unused kernel memory: 1780k freed
doing fast boot
[    1.498809] blkfront: xvda: barrier: enabled
[    1.506405]  xvda: xvda1 xvda2
[    1.525946] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4
FATAL: Module ata_piix not found.
FATAL: Error running install command for ata_piix
FATAL: Module ata_generic not found.
[    1.624458] Initialising Xen virtual ethernet driver.
preping 03-storage.sh
running 03-storage.sh
preping 04-udev.sh
running 04-udev.sh
Creating device nodes with udev
[    1.748426] udev: starting version 147
[    2.084182] tsc: Refined TSC clocksource calibration: 2926.327 MHz
preping 05-blogd.sh
running 05-blogd.sh
mount: devpts already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts
Boot logging started on /dev/ttyS0(/dev/console) at Mon Feb  4 10:33:41 2013
preping 05-clock.sh
running 05-clock.sh
preping 12-network.sh
running 12-network.sh
FATAL: Module af_packet not found.
running dhcpcd on interface eth0
err, eth0: Failed to lookup hostname via DNS: Temporary failure in name resolution
preping 21-devinit_done.sh
running 21-devinit_done.sh
preping 21-nfs.sh
running 21-nfs.sh
FATAL: Module nfs not found.
preping 81-mount.sh
running 81-mount.sh
device node not found
Mounting root bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot
mount -o rw,nolock -t nfs bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot /root
preping 82-remount.sh
running 82-remount.sh
preping 91-createfb.sh
running 91-createfb.sh
preping 91-killblogd.sh
running 91-killblogd.sh
preping 91-killudev.sh
running 91-killudev.sh
preping 91-shell.sh
running 91-shell.sh
preping 92-killblogd2.sh
running 92-killblogd2.sh
preping 93-boot.sh
running 93-boot.sh
INIT: version 2.86 booting
System Boot Control: Running /etc/init.d/boot

--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 Mon Feb 04 09:50:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09:50: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 1U2IgN-0007qh-Ky; Mon, 04 Feb 2013 09:49:47 +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 1U2IgK-0007qQ-TN
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:49:46 +0000
Received: from [85.158.137.99:20876] by server-6.bemta-3.messagelabs.com id
	73/C7-29959-3348F015; Mon, 04 Feb 2013 09:49:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-217.messagelabs.com!1359971365!18983129!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26514 invoked from network); 4 Feb 2013 09:49:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 09:49:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo29) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u02cadp148qXWR ;
	Mon, 4 Feb 2013 10:49:10 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id DDB5A1884C; Mon,  4 Feb 2013 10:49:09 +0100 (CET)
Date: Mon, 4 Feb 2013 10:49:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204094909.GA2564@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de>
	<20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
	<510F83AA02000078000BB64A@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <510F83AA02000078000BB64A@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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=utf-8
Content-Disposition: inline

On Mon, Feb 04, Jan Beulich wrote:

> >>> On 04.02.13 at 09:21, "Jan Beulich" <JBeulich@suse.com> wrote:
> > Looking over the changes again (and without having looked at
> > the Linux side yet again), I think the most likely candidates for
> > reverting are
> > 
> > 26457:aa82638d58b0 (x86/HVM: consolidate toggling of RTC IRQ)
> > 26461:78e91e9e4d61 (x86/HVM: generalize IRQ raising on RTC_REG_B writes)
> 
> Actually, one possibility occurred to me right after sending the
> earlier response - could you give the patch below a try?

This patch leads also to a hang.
The initial boot of a HVM guest hangs in "Set System Time to the current
Hardware Clock", with the same backtrace in hpet_rtc_interrupt.
If the HVM guest is later migrated to localhost, the new guest hangs
also in hpet_rtc_interrupt.

I'm attaching the xen, dom0 and domU logs from a pvops kernel. sles
kernel will follow.

I will also try to revert the two changeset above.


Olaf

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="xl-dmesg.txt"

 __  __          
 \ \/ /___ _ __  
  \  // _ \ '_ \ 
  /  \  __/ | | |
 /_/\_\___|_| |_|
                 
  _  _    _____  ____   __  ____   ___ ____    ____   ___  _ _____  ___ ____  
 | || |  |___ / |___ \ / /_| ___| / _ \___ \  |___ \ / _ \/ |___ / / _ \___ \ 
 | || |_   |_ \   __) | '_ \___ \| | | |__) |__ __) | | | | | |_ \| | | |__) |
 |__   _| ___) | / __/| (_) |__) | |_| / __/|__/ __/| |_| | |___) | |_| / __/ 
    |_|(_)____(_)_____|\___/____/ \___/_____| |_____|\___/|_|____/ \___/_____|
                                                                              
   ___  _  _    ___   ___   ___   ___ ____ ____  
  / _ \| || |  / _ \ / _ \ / _ \ ( _ ) ___|___ \ 
 | | | | || |_| | | | (_) | | | |/ _ \___ \ __) |
 | |_| |__   _| |_| |\__, | |_| | (_) |__) / __/ 
  \___/   |_|(_)___/   /_/ \___/ \___/____/_____|
                                                 
(XEN) Xen version 4.3.26502-20130204.090852 (abuild@) (gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]) debug=y Mon Feb  4 09:12:15 UTC 2013
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: loglvl=all guest_loglvl=all console=com1,vga com1=57600,8n1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b000 (usable)
(XEN)  000000000009b000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000008c21c000 (usable)
(XEN)  000000008c21c000 - 000000008c2ef000 (ACPI NVS)
(XEN)  000000008c2ef000 - 000000008c3df000 (ACPI data)
(XEN)  000000008c3df000 - 000000008d7df000 (ACPI NVS)
(XEN)  000000008d7df000 - 000000008f302000 (ACPI data)
(XEN)  000000008f302000 - 000000008f34f000 (reserved)
(XEN)  000000008f34f000 - 000000008f3d4000 (ACPI data)
(XEN)  000000008f3d4000 - 000000008f3de000 (ACPI NVS)
(XEN)  000000008f3de000 - 000000008f3e2000 (ACPI data)
(XEN)  000000008f3e2000 - 000000008f4cf000 (ACPI NVS)
(XEN)  000000008f4cf000 - 000000008f500000 (ACPI data)
(XEN)  000000008f500000 - 0000000090000000 (reserved)
(XEN)  00000000a0000000 - 00000000b0000000 (reserved)
(XEN)  00000000fc000000 - 00000000fd000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000670000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 8F4FD120, 00A4 (r1 INTEL  S5520UT         0       1000013)
(XEN) ACPI: FACP 8F4FB000, 00F4 (r4 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: DSDT 8F4F4000, 65E9 (r2 INTEL  S5520UT         3 MSFT  100000D)
(XEN) ACPI: FACS 8F3E2000, 0040
(XEN) ACPI: APIC 8F4F3000, 01A8 (r2 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: MCFG 8F4F2000, 003C (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: HPET 8F4F1000, 0038 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SLIT 8F4F0000, 0030 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SRAT 8F4EF000, 0430 (r2 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SPCR 8F4EE000, 0050 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: WDDT 8F4ED000, 0040 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: SSDT 8F4D2000, 1AFC4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 8F4D1000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: TCPA 8F4D0000, 0032 (r0                        0             0)
(XEN) ACPI: HEST 8F4CF000, 00A8 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: BERT 8F3E1000, 0030 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: ERST 8F3E0000, 0230 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: EINJ 8F3DF000, 0130 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: DMAR 8F3DE000, 01A8 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) System RAM: 24513MB (25102044kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-90000000
(XEN) SRAT: Node 0 PXM 0 100000000-370000000
(XEN) SRAT: Node 1 PXM 1 370000000-670000000
(XEN) NUMA: Allocated memnodemap from 66dbe2000 - 66dbe3000
(XEN) NUMA: Using 16 for the hash shift.
(XEN) Domain heap initialised DMA width 31 bits
(XEN) found SMP MP-table at 000fdb60
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[8f3e200c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a401 base: 0xfed00000
(XEN) Xen ERST support is initialized.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 24 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2926.444 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control 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.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(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, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0xa43000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0x660f0
(XEN) elf_parse_binary: phdr: paddr=0x1c67000 memsz=0x13100
(XEN) elf_parse_binary: phdr: paddr=0x1c7b000 memsz=0x70d000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x2388000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81c7b210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff82388000
(XEN)     virt_entry       = 0xffffffff81c7b210
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2388000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000650000000->0000000658000000 (6122675 pages to be allocated)
(XEN)  Init. ramdisk: 000000066f195000->000000066ffff600
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82388000
(XEN)  Init. ramdisk: ffffffff82388000->ffffffff831f2600
(XEN)  Phys-Mach map: ffffffff831f3000->ffffffff860f08f0
(XEN)  Start info:    ffffffff860f1000->ffffffff860f14b4
(XEN)  Page tables:   ffffffff860f2000->ffffffff86127000
(XEN)  Boot stack:    ffffffff86127000->ffffffff86128000
(XEN)  TOTAL:         ffffffff80000000->ffffffff86400000
(XEN)  ENTRY ADDRESS: ffffffff81c7b210
(XEN) Dom0 has maximum 24 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff81a43000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 -> 0xffffffff81c660f0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81c67000 -> 0xffffffff81c7a100
(XEN) elf_load_binary: phdr 3 at 0xffffffff81c7b000 -> 0xffffffff81d0e000
(XEN) Scrubbing Free RAM: .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 248kB init memory.
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add device 0000:00:10.0
(XEN) PCI add device 0000:00:10.1
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:00:13.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.2
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:01:00.1
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:02.0
(XEN) PCI add device 0000:06:04.0
(XEN) PCI add device 0000:09:00.0
(XEN) PCI add device 0000:0a:02.0
(XEN) PCI add device 0000:0a:04.0
(XEN) PCI add device 0000:0f:00.0
(XEN) PCI add device 0000:10:00.0
(XEN) PCI add device 0000:fe:00.0
(XEN) PCI add device 0000:fe:00.1
(XEN) PCI add device 0000:fe:02.0
(XEN) PCI add device 0000:fe:02.1
(XEN) PCI add device 0000:fe:02.2
(XEN) PCI add device 0000:fe:02.3
(XEN) PCI add device 0000:fe:02.4
(XEN) PCI add device 0000:fe:02.5
(XEN) PCI add device 0000:fe:03.0
(XEN) PCI add device 0000:fe:03.1
(XEN) PCI add device 0000:fe:03.2
(XEN) PCI add device 0000:fe:03.4
(XEN) PCI add device 0000:fe:04.0
(XEN) PCI add device 0000:fe:04.1
(XEN) PCI add device 0000:fe:04.2
(XEN) PCI add device 0000:fe:04.3
(XEN) PCI add device 0000:fe:05.0
(XEN) PCI add device 0000:fe:05.1
(XEN) PCI add device 0000:fe:05.2
(XEN) PCI add device 0000:fe:05.3
(XEN) PCI add device 0000:fe:06.0
(XEN) PCI add device 0000:fe:06.1
(XEN) PCI add device 0000:fe:06.2
(XEN) PCI add device 0000:fe:06.3
(XEN) PCI add device 0000:ff:00.0
(XEN) PCI add device 0000:ff:00.1
(XEN) PCI add device 0000:ff:02.0
(XEN) PCI add device 0000:ff:02.1
(XEN) PCI add device 0000:ff:02.2
(XEN) PCI add device 0000:ff:02.3
(XEN) PCI add device 0000:ff:02.4
(XEN) PCI add device 0000:ff:02.5
(XEN) PCI add device 0000:ff:03.0
(XEN) PCI add device 0000:ff:03.1
(XEN) PCI add device 0000:ff:03.2
(XEN) PCI add device 0000:ff:03.4
(XEN) PCI add device 0000:ff:04.0
(XEN) PCI add device 0000:ff:04.1
(XEN) PCI add device 0000:ff:04.2
(XEN) PCI add device 0000:ff:04.3
(XEN) PCI add device 0000:ff:05.0
(XEN) PCI add device 0000:ff:05.1
(XEN) PCI add device 0000:ff:05.2
(XEN) PCI add device 0000:ff:05.3
(XEN) PCI add device 0000:ff:06.0
(XEN) PCI add device 0000:ff:06.1
(XEN) PCI add device 0000:ff:06.2
(XEN) PCI add device 0000:ff:06.3
(XEN) HVM1: HVM Loader
(XEN) HVM1: Detected Xen v4.3.26502-20130204
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 4
(XEN) HVM1: System requested ROMBIOS
(XEN) HVM1: CPU speed is 2926 MHz
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 02:0 bar 10 size lx: 02000000
(XEN) HVM1: pci dev 03:0 bar 14 size lx: 01000000
(XEN) HVM1: pci dev 02:0 bar 14 size lx: 00001000
(XEN) HVM1: pci dev 03:0 bar 10 size lx: 00000100
(XEN) HVM1: pci dev 01:1 bar 20 size lx: 00000010
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1: Testing HVM environment:
(XEN) HVM1:  - REP INSB across page boundaries ... passed
(XEN) HVM1:  - GS base MSRs and SWAPGS ... passed
(XEN) HVM1: Passed 2 of 2 tests
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: 9660 bytes of ROMBIOS high-memory extensions:
(XEN) HVM1:   Relocating to 0xfc001000-0xfc0035bc ... done
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading Cirrus VGABIOS ...
(XEN) HVM1: Option ROMs:
(XEN) HVM1:  c0000-c8fff: VGA BIOS
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1: vm86 TSS at fc00f680
(XEN) HVM1: BIOS map:
(XEN) HVM1:  f0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [03]: 00000000:00100000 - 00000000:1f800000: RAM
(XEN) HVM1:  HOLE: 00000000:1f800000 - 00000000:fc000000
(XEN) HVM1:  [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1: Invoking ROMBIOS ...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM1: Bochs BIOS - build: 06/23/99
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM1: Options: apmbios pcibios eltorito PMM 
(XEN) HVM1: 
(XEN) HVM1: ata0-0: PCHS=2080/16/63 translation=large LCHS=520/64/63
(XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (1024 MBytes)
(XEN) HVM1: IDE time out
(XEN) HVM1: 
(XEN) HVM1: 
(XEN) HVM1: 
(XEN) HVM1: Press F12 for boot menu.
(XEN) HVM1: 
(XEN) HVM1: Booting from CD-Rom...
(XEN) HVM1: CDROM boot failure code : 0002
(XEN) HVM1: Boot from CD-Rom failed: could not read the boot disk
(XEN) HVM1: 
(XEN) HVM1: Booting from Hard Disk...
(XEN) HVM1: Booting from 0000:7c00
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM1: int13_harddisk: function 08, unmapped device for ELDL=81
(XEN) HVM1: *** int 15h function AX=00c0, BX=0000 not yet supported!
(XEN) HVM1: *** int 15h function AX=ec00, BX=0002 not yet supported!
(XEN) HVM1: KBD: unsupported int 16h function 03
(XEN) HVM1: *** int 15h function AX=e980, BX=0000 not yet supported!
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=82
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=82
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=83
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=83
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=84
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=84
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=85
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=85
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=86
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=86
(XEN) HVM1: int13_harddisk: function 41, unmapped device for ELDL=87
(XEN) HVM1: int13_harddisk: function 02, unmapped device for ELDL=87
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 88
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 88
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 89
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 89
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8a
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8a
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8b
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8b
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8c
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8c
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8d
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8d
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8e
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8e
(XEN) HVM1: int13_harddisk: function 41, ELDL out of range 8f
(XEN) HVM1: int13_harddisk: function 02, ELDL out of range 8f
(XEN) irq.c:375: Dom1 callback via changed to Direct Vector 0xf3
(XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="dmesg-3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7.txt"

[    0.000000] Linux version 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 (abuild@build20) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Mon Feb 4 07:02:12 UTC 2013
[    0.000000] Command line: debug panic=9 sysrq=yes showopts log_buf_len=64M console=hvc0
[    0.000000] Freeing 9b-100 pfn range: 101 pages freed
[    0.000000] 1-1 mapping on 9b->100
[    0.000000] Freeing 8c21c-100000 pfn range: 474596 pages freed
[    0.000000] 1-1 mapping on 8c21c->100000
[    0.000000] Released 474697 pages of unused memory
[    0.000000] Set 474697 page(s) to 1-1 mapping
[    0.000000] Populating 5dfb1e-653967 pfn range: 474697 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009afff] usable
[    0.000000] Xen: [mem 0x000000000009b000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000008c21bfff] usable
[    0.000000] Xen: [mem 0x000000008c21c000-0x000000008c2eefff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008c2ef000-0x000000008c3defff] ACPI data
[    0.000000] Xen: [mem 0x000000008c3df000-0x000000008d7defff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008d7df000-0x000000008f301fff] ACPI data
[    0.000000] Xen: [mem 0x000000008f302000-0x000000008f34efff] reserved
[    0.000000] Xen: [mem 0x000000008f34f000-0x000000008f3d3fff] ACPI data
[    0.000000] Xen: [mem 0x000000008f3d4000-0x000000008f3ddfff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008f3de000-0x000000008f3e1fff] ACPI data
[    0.000000] Xen: [mem 0x000000008f3e2000-0x000000008f4cefff] ACPI NVS
[    0.000000] Xen: [mem 0x000000008f4cf000-0x000000008f4fffff] ACPI data
[    0.000000] Xen: [mem 0x000000008f500000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000a0000000-0x00000000afffffff] reserved
[    0.000000] Xen: [mem 0x00000000fc000000-0x00000000fcffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fec90000-0x00000000fec90fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000066fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.5 present.
[    0.000000] DMI: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x670000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0x8c21c max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x031f2fff]
[    0.000000] Base memory trampoline at [ffff880000094000] 94000 size 28672
[    0.000000] init_memory_mapping: [mem 0x00000000-0x8c21bfff]
[    0.000000]  [mem 0x00000000-0x8c21bfff] page 4k
[    0.000000] kernel direct mapping tables up to 0x8c21bfff @ [mem 0x00b9a000-0x00ffffff]
[    0.000000] xen: setting RW the range fcc000 - 1000000
[    0.000000] init_memory_mapping: [mem 0x100000000-0x66fffffff]
[    0.000000]  [mem 0x100000000-0x66fffffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x66fffffff @ [mem 0x89685000-0x8c21bfff]
[    0.000000] xen: setting RW the range 8c21b000 - 8c21c000
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 2093540(99%)
[    0.000000] RAMDISK: [mem 0x02388000-0x031f2fff]
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000008f4fd120 000A4 (v01 INTEL  S5520UT  00000000      01000013)
[    0.000000] ACPI: FACP 000000008f4fb000 000F4 (v04 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000008f4f4000 065E9 (v02 INTEL  S5520UT  00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000008f3e2000 00040
[    0.000000] ACPI: APIC 000000008f4f3000 001A8 (v02 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000008f4f2000 0003C (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000008f4f1000 00038 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000008f4f0000 00030 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SRAT 000000008f4ef000 00430 (v02 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000008f4ee000 00050 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000008f4ed000 00040 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000008f4d2000 1AFC4 (v02  INTEL SSDT  PM 00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000008f4d1000 001D8 (v02  INTEL IPMI     00004000 INTL 20061109)
[    0.000000] ACPI: TCPA 000000008f4d0000 00032 (v00                 00000000      00000000)
[    0.000000] ACPI: HEST 000000008f4cf000 000A8 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000008f3e1000 00030 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000008f3e0000 00230 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000008f3df000 00130 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: XMAR 000000008f3de000 001A8 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x66fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009afff]
[    0.000000]   node   0: [mem 0x00100000-0x8c21bfff]
[    0.000000]   node   0: [mem 0x100000000-0x66fffffff]
[    0.000000] On node 0 totalpages: 6275495
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 1081 pages reserved
[    0.000000]   DMA zone: 2834 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 16320 pages used for memmap
[    0.000000]   DMA32 zone: 553564 pages, LIFO batch:31
[    0.000000]   Normal zone: 89088 pages used for memmap
[    0.000000]   Normal zone: 5612544 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 8/0x12 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 9/0x32 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 10/0x14 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 11/0x34 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 12/0x1 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 13/0x21 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 14/0x3 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 15/0x23 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 16/0x5 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 17/0x25 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 18/0x11 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 19/0x31 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 20/0x13 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 21/0x33 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 22/0x15 ignored.
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
[    0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached.  Processor 23/0x35 ignored.
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
[    0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a401 base: 0xfed00000
[    0.000000] smpboot: 24 Processors exceeds NR_CPUS limit of 8
[    0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 000000008c21c000 - 000000008c2ef000
[    0.000000] PM: Registered nosave memory: 000000008c2ef000 - 000000008c3df000
[    0.000000] PM: Registered nosave memory: 000000008c3df000 - 000000008d7df000
[    0.000000] PM: Registered nosave memory: 000000008d7df000 - 000000008f302000
[    0.000000] PM: Registered nosave memory: 000000008f302000 - 000000008f34f000
[    0.000000] PM: Registered nosave memory: 000000008f34f000 - 000000008f3d4000
[    0.000000] PM: Registered nosave memory: 000000008f3d4000 - 000000008f3de000
[    0.000000] PM: Registered nosave memory: 000000008f3de000 - 000000008f3e2000
[    0.000000] PM: Registered nosave memory: 000000008f3e2000 - 000000008f4cf000
[    0.000000] PM: Registered nosave memory: 000000008f4cf000 - 000000008f500000
[    0.000000] PM: Registered nosave memory: 000000008f500000 - 0000000090000000
[    0.000000] PM: Registered nosave memory: 0000000090000000 - 00000000a0000000
[    0.000000] PM: Registered nosave memory: 00000000a0000000 - 00000000b0000000
[    0.000000] PM: Registered nosave memory: 00000000b0000000 - 00000000fc000000
[    0.000000] PM: Registered nosave memory: 00000000fc000000 - 00000000fd000000
[    0.000000] PM: Registered nosave memory: 00000000fd000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fec90000
[    0.000000] PM: Registered nosave memory: 00000000fec90000 - 00000000fec91000
[    0.000000] PM: Registered nosave memory: 00000000fec91000 - 00000000fed1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ff800000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 - 0000000100000000
[    0.000000] e820: [mem 0xb0000000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.3.26502-20130204 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88064f600000 s78080 r8192 d24320 u262144
[    0.000000] pcpu-alloc: s78080 r8192 d24320 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    8.570118] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 6168942
[    8.570120] Kernel command line: debug panic=9 sysrq=yes showopts log_buf_len=64M console=hvc0
[    8.570177] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    8.575301] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    8.583181] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    8.585686] __ex_table already sorted, skipping sort
[    8.618817] software IO TLB [mem 0x62d102000-0x631101fff] (64MB) mapped at [ffff88062d102000-ffff880631101fff]
[    8.716651] Memory: 23932616k/27000832k available (6541k kernel code, 1898852k absent, 1169364k reserved, 6150k data, 636k init)
[    8.716739] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    8.716782] Hierarchical RCU implementation.
[    8.716792] NR_IRQS:4352 nr_irqs:1152 16
[    8.716855] xen: sci override: global_irq=9 trigger=0 polarity=0
[    8.716858] xen: registering gsi 9 triggering 0 polarity 0
[    8.716872] xen: --> pirq=9 -> irq=9 (gsi=9)
[    8.716904] xen: acpi sci 9
[    8.716908] xen: --> pirq=1 -> irq=1 (gsi=1)
[    8.716910] xen: --> pirq=2 -> irq=2 (gsi=2)
[    8.716913] xen: --> pirq=3 -> irq=3 (gsi=3)
[    8.716916] xen: --> pirq=4 -> irq=4 (gsi=4)
[    8.716918] xen: --> pirq=5 -> irq=5 (gsi=5)
[    8.716921] xen: --> pirq=6 -> irq=6 (gsi=6)
[    8.716923] xen: --> pirq=7 -> irq=7 (gsi=7)
[    8.716926] xen: --> pirq=8 -> irq=8 (gsi=8)
[    8.716928] xen: --> pirq=10 -> irq=10 (gsi=10)
[    8.716931] xen: --> pirq=11 -> irq=11 (gsi=11)
[    8.716934] xen: --> pirq=12 -> irq=12 (gsi=12)
[    8.716936] xen: --> pirq=13 -> irq=13 (gsi=13)
[    8.716939] xen: --> pirq=14 -> irq=14 (gsi=14)
[    8.716941] xen: --> pirq=15 -> irq=15 (gsi=15)
[    8.723114] Console: colour VGA+ 80x25
[    8.723624] console [hvc0] enabled
[    8.723646] Xen: using vcpuop timer interface
[    8.723653] installing Xen timer for CPU 0
[    8.723682] tsc: Detected 2926.444 MHz processor
[    8.723689] Calibrating delay loop (skipped), value calculated using timer frequency.. 5852.88 BogoMIPS (lpj=11705776)
[    8.723694] pid_max: default: 32768 minimum: 301
[    8.723734] Mount-cache hash table entries: 256
[    8.723976] CPU: Physical Processor ID: 0
[    8.723979] CPU: Processor Core ID: 0
[    8.723982] mce: CPU supports 2 MCE banks
[    8.723998] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    8.723998] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    8.723998] tlb_flushall_shift: 6
[    8.724094] Freeing SMP alternatives: 28k freed
[    8.724940] ACPI: Core revision 20120913
[    8.733214] Performance Events: unsupported p6 CPU model 44 no PMU driver, software events only.
[    8.733369] installing Xen timer for CPU 1
[    8.734623] installing Xen timer for CPU 2
[    8.735820] installing Xen timer for CPU 3
[    8.737059] installing Xen timer for CPU 4
[    8.738037] installing Xen timer for CPU 5
[    8.739017] installing Xen timer for CPU 6
[    8.740032] installing Xen timer for CPU 7
[    8.740964] Brought up 8 CPUs
[    8.741540] devtmpfs: initialized
[    8.741942] PM: Registering ACPI NVS region [mem 0x8c21c000-0x8c2eefff] (864256 bytes)
[    8.741960] PM: Registering ACPI NVS region [mem 0x8c3df000-0x8d7defff] (20971520 bytes)
[    8.742195] PM: Registering ACPI NVS region [mem 0x8f3d4000-0x8f3ddfff] (40960 bytes)
[    8.742198] PM: Registering ACPI NVS region [mem 0x8f3e2000-0x8f4cefff] (970752 bytes)
[    8.742250] Grant tables using version 2 layout.
[    8.742263] Grant table initialized
[    8.742297] NET: Registered protocol family 16
[    8.742988] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    8.742994] ACPI: bus type pci registered
[    8.743193] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xa0000000-0xafffffff] (base 0xa0000000)
[    8.743199] PCI: MMCONFIG at [mem 0xa0000000-0xafffffff] reserved in E820
[    8.787823] PCI: Using configuration type 1 for base access
[    8.788567] bio: create slab <bio-0> at 0
[    8.788791] ACPI: Added _OSI(Module Device)
[    8.788798] ACPI: Added _OSI(Processor Device)
[    8.788802] ACPI: Added _OSI(3.0 _SCP Extensions)
[    8.788806] ACPI: Added _OSI(Processor Aggregator Device)
[    8.789956] ACPI: EC: Look up EC in DSDT
[    8.805910] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL] size 64 (bits) (20120913/dsopcode-236)
[    8.805918] ACPI Error: Method parse/execution failed [\_SB_._OSC] (Node ffff88062cc491b8), AE_AML_BUFFER_LIMIT (20120913/psparse-536)
[    8.806714] ACPI: Interpreter enabled
[    8.806719] ACPI: (supports S0 S1 S5)
[    8.806729] ACPI: Using IOAPIC for interrupt routing
[    8.809807] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    8.810337] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fd])
[    8.810772] pci_root PNP0A08:00: ignoring host bridge window [mem 0x000c4000-0x000cbfff] (conflicts with Video ROM [mem 0x000c0000-0x000c7fff])
[    8.810801] PCI host bridge to bus 0000:00
[    8.810804] pci_bus 0000:00: root bus resource [bus 00-fd]
[    8.810808] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    8.810811] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    8.810814] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    8.810818] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfedfffff]
[    8.810821] pci_bus 0000:00: root bus resource [mem 0xb0000000-0xfdffffff]
[    8.810824] pci_bus 0000:00: scanning bus
[    8.810845] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
[    8.810856] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0xa
[    8.810955] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    8.810962] pci 0000:00:00.0: PME# disabled
[    8.810999] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
[    8.811047] pci 0000:00:01.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811110] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    8.811116] pci 0000:00:01.0: PME# disabled
[    8.811155] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
[    8.811200] pci 0000:00:03.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811264] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    8.811270] pci 0000:00:03.0: PME# disabled
[    8.811309] pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
[    8.811354] pci 0000:00:05.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811417] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    8.811423] pci 0000:00:05.0: PME# disabled
[    8.811462] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
[    8.811507] pci 0000:00:07.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811570] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    8.811576] pci 0000:00:07.0: PME# disabled
[    8.811615] pci 0000:00:09.0: [8086:3410] type 01 class 0x060400
[    8.811660] pci 0000:00:09.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811723] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    8.811729] pci 0000:00:09.0: PME# disabled
[    8.811766] pci 0000:00:0a.0: [8086:3411] type 01 class 0x060400
[    8.811811] pci 0000:00:0a.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.811874] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
[    8.811880] pci 0000:00:0a.0: PME# disabled
[    8.811917] pci 0000:00:10.0: [8086:3425] type 00 class 0x080000
[    8.812039] pci 0000:00:10.1: [8086:3426] type 00 class 0x080000
[    8.812144] pci 0000:00:11.0: [8086:3427] type 00 class 0x080000
[    8.812271] pci 0000:00:11.1: [8086:3428] type 00 class 0x080000
[    8.812378] pci 0000:00:13.0: [8086:342d] type 00 class 0x080020
[    8.812398] pci 0000:00:13.0: reg 10: [mem 0xb1b24000-0xb1b24fff]
[    8.812489] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold
[    8.812496] pci 0000:00:13.0: PME# disabled
[    8.812525] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
[    8.812645] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
[    8.812766] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
[    8.812880] pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
[    8.812980] pci 0000:00:15.0: [8086:342f] type 00 class 0x080020
[    8.813089] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
[    8.813111] pci 0000:00:16.0: reg 10: [mem 0xb1b00000-0xb1b03fff 64bit]
[    8.813239] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
[    8.813261] pci 0000:00:16.1: reg 10: [mem 0xb1b04000-0xb1b07fff 64bit]
[    8.813389] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
[    8.813417] pci 0000:00:16.2: reg 10: [mem 0xb1b08000-0xb1b0bfff 64bit]
[    8.813546] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
[    8.813568] pci 0000:00:16.3: reg 10: [mem 0xb1b0c000-0xb1b0ffff 64bit]
[    8.813696] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
[    8.813717] pci 0000:00:16.4: reg 10: [mem 0xb1b10000-0xb1b13fff 64bit]
[    8.813846] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
[    8.813868] pci 0000:00:16.5: reg 10: [mem 0xb1b14000-0xb1b17fff 64bit]
[    8.813995] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
[    8.814017] pci 0000:00:16.6: reg 10: [mem 0xb1b18000-0xb1b1bfff 64bit]
[    8.814146] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
[    8.814168] pci 0000:00:16.7: reg 10: [mem 0xb1b1c000-0xb1b1ffff 64bit]
[    8.814298] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300
[    8.814369] pci 0000:00:1a.0: reg 20: [io  0x30e0-0x30ff]
[    8.814452] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300
[    8.814522] pci 0000:00:1a.1: reg 20: [io  0x30c0-0x30df]
[    8.814605] pci 0000:00:1a.2: [8086:3a39] type 00 class 0x0c0300
[    8.814675] pci 0000:00:1a.2: reg 20: [io  0x30a0-0x30bf]
[    8.814772] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320
[    8.814806] pci 0000:00:1a.7: reg 10: [mem 0xb1b22000-0xb1b223ff]
[    8.814949] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    8.814956] pci 0000:00:1a.7: PME# disabled
[    8.814989] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400
[    8.815046] pci 0000:00:1c.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.815111] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    8.815118] pci 0000:00:1c.0: PME# disabled
[    8.815158] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400
[    8.815214] pci 0000:00:1c.4: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.815280] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    8.815286] pci 0000:00:1c.4: PME# disabled
[    8.815321] pci 0000:00:1c.5: [8086:3a4a] type 01 class 0x060400
[    8.815377] pci 0000:00:1c.5: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.815443] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    8.815449] pci 0000:00:1c.5: PME# disabled
[    8.815489] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
[    8.815559] pci 0000:00:1d.0: reg 20: [io  0x3080-0x309f]
[    8.815642] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
[    8.815713] pci 0000:00:1d.1: reg 20: [io  0x3060-0x307f]
[    8.815796] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[    8.815866] pci 0000:00:1d.2: reg 20: [io  0x3040-0x305f]
[    8.815963] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
[    8.815997] pci 0000:00:1d.7: reg 10: [mem 0xb1b21000-0xb1b213ff]
[    8.816140] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    8.816147] pci 0000:00:1d.7: PME# disabled
[    8.816176] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[    8.816229] pci 0000:00:1e.0: calling pci_fixup_transparent_bridge+0x0/0x1f
[    8.816290] pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100
[    8.816406] pci 0000:00:1f.0: calling ich_force_enable_hpet+0x0/0x1c0
[    8.816410] pci 0000:00:1f.0: calling quirk_ich7_lpc+0x0/0x68
[    8.816424] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 000f)
[    8.816430] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)
[    8.816458] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0600 (mask 001f)
[    8.816536] pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601
[    8.816569] pci 0000:00:1f.2: reg 10: [io  0x3108-0x310f]
[    8.816583] pci 0000:00:1f.2: reg 14: [io  0x3114-0x3117]
[    8.816596] pci 0000:00:1f.2: reg 18: [io  0x3100-0x3107]
[    8.816610] pci 0000:00:1f.2: reg 1c: [io  0x3110-0x3113]
[    8.816623] pci 0000:00:1f.2: reg 20: [io  0x3020-0x303f]
[    8.816637] pci 0000:00:1f.2: reg 24: [mem 0xb1b20000-0xb1b207ff]
[    8.816717] pci 0000:00:1f.2: PME# supported from D3hot
[    8.816723] pci 0000:00:1f.2: PME# disabled
[    8.816749] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
[    8.816774] pci 0000:00:1f.3: reg 10: [mem 0xb1b23000-0xb1b230ff 64bit]
[    8.816810] pci 0000:00:1f.3: reg 20: [io  0x3000-0x301f]
[    8.816856] pci_bus 0000:00: fixups for bus
[    8.816861] pci 0000:00:01.0: scanning [bus 01-03] behind bridge, pass 0
[    8.816921] pci_bus 0000:01: scanning bus
[    8.816951] pci 0000:01:00.0: [8086:10c9] type 00 class 0x020000
[    8.816971] pci 0000:01:00.0: reg 10: [mem 0xb1a20000-0xb1a3ffff]
[    8.816998] pci 0000:01:00.0: reg 18: [io  0x2020-0x203f]
[    8.817013] pci 0000:01:00.0: reg 1c: [mem 0xb1ac4000-0xb1ac7fff]
[    8.817122] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    8.817128] pci 0000:01:00.0: PME# disabled
[    8.817174] pci 0000:01:00.0: reg 184: [mem 0xb1a40000-0xb1a43fff 64bit]
[    8.817196] pci 0000:01:00.0: reg 190: [mem 0xb1a60000-0xb1a63fff 64bit]
[    8.817240] pci 0000:01:00.1: [8086:10c9] type 00 class 0x020000
[    8.817260] pci 0000:01:00.1: reg 10: [mem 0xb1a00000-0xb1a1ffff]
[    8.817287] pci 0000:01:00.1: reg 18: [io  0x2000-0x201f]
[    8.817302] pci 0000:01:00.1: reg 1c: [mem 0xb1ac0000-0xb1ac3fff]
[    8.817410] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
[    8.817417] pci 0000:01:00.1: PME# disabled
[    8.817455] pci 0000:01:00.1: reg 184: [mem 0xb1a80000-0xb1a83fff 64bit]
[    8.817483] pci 0000:01:00.1: reg 190: [mem 0xb1aa0000-0xb1aa3fff 64bit]
[    8.819001] pci_bus 0000:01: fixups for bus
[    8.819004] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    8.819010] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    8.819016] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    8.819025] pci_bus 0000:01: bus scan returning with max=01
[    8.819031] pci 0000:00:03.0: scanning [bus 04-04] behind bridge, pass 0
[    8.819092] pci_bus 0000:04: scanning bus
[    8.819096] pci_bus 0000:04: fixups for bus
[    8.819098] pci 0000:00:03.0: PCI bridge to [bus 04]
[    8.819112] pci_bus 0000:04: bus scan returning with max=04
[    8.819118] pci 0000:00:05.0: scanning [bus 05-08] behind bridge, pass 0
[    8.819177] pci_bus 0000:05: scanning bus
[    8.819197] pci 0000:05:00.0: [111d:806a] type 01 class 0x060400
[    8.819311] pci 0000:05:00.0: PME# supported from D0 D3hot D3cold
[    8.819319] pci 0000:05:00.0: PME# disabled
[    8.820727] pci_bus 0000:05: fixups for bus
[    8.820745] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    8.820761] pci 0000:05:00.0: scanning [bus 06-08] behind bridge, pass 0
[    8.820813] pci_bus 0000:06: scanning bus
[    8.820836] pci 0000:06:02.0: [111d:806a] type 01 class 0x060400
[    8.820965] pci 0000:06:02.0: PME# supported from D0 D3hot D3cold
[    8.820973] pci 0000:06:02.0: PME# disabled
[    8.821013] pci 0000:06:04.0: [111d:806a] type 01 class 0x060400
[    8.821141] pci 0000:06:04.0: PME# supported from D0 D3hot D3cold
[    8.821149] pci 0000:06:04.0: PME# disabled
[    8.821211] pci_bus 0000:06: fixups for bus
[    8.821213] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    8.821238] pci 0000:06:02.0: scanning [bus 07-07] behind bridge, pass 0
[    8.821300] pci_bus 0000:07: scanning bus
[    8.821305] pci_bus 0000:07: fixups for bus
[    8.821307] pci 0000:06:02.0: PCI bridge to [bus 07]
[    8.821329] pci_bus 0000:07: bus scan returning with max=07
[    8.821336] pci 0000:06:04.0: scanning [bus 08-08] behind bridge, pass 0
[    8.821398] pci_bus 0000:08: scanning bus
[    8.821402] pci_bus 0000:08: fixups for bus
[    8.821405] pci 0000:06:04.0: PCI bridge to [bus 08]
[    8.821427] pci_bus 0000:08: bus scan returning with max=08
[    8.821434] pci 0000:06:02.0: scanning [bus 07-07] behind bridge, pass 1
[    8.821445] pci 0000:06:04.0: scanning [bus 08-08] behind bridge, pass 1
[    8.821454] pci_bus 0000:06: bus scan returning with max=08
[    8.821461] pci 0000:05:00.0: scanning [bus 06-08] behind bridge, pass 1
[    8.821470] pci_bus 0000:05: bus scan returning with max=08
[    8.821476] pci 0000:00:07.0: scanning [bus 09-0c] behind bridge, pass 0
[    8.821542] pci_bus 0000:09: scanning bus
[    8.821562] pci 0000:09:00.0: [111d:806a] type 01 class 0x060400
[    8.821676] pci 0000:09:00.0: PME# supported from D0 D3hot D3cold
[    8.821683] pci 0000:09:00.0: PME# disabled
[    8.823103] pci_bus 0000:09: fixups for bus
[    8.823106] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    8.823122] pci 0000:09:00.0: scanning [bus 0a-0c] behind bridge, pass 0
[    8.823175] pci_bus 0000:0a: scanning bus
[    8.823197] pci 0000:0a:02.0: [111d:806a] type 01 class 0x060400
[    8.823326] pci 0000:0a:02.0: PME# supported from D0 D3hot D3cold
[    8.823333] pci 0000:0a:02.0: PME# disabled
[    8.823373] pci 0000:0a:04.0: [111d:806a] type 01 class 0x060400
[    8.823502] pci 0000:0a:04.0: PME# supported from D0 D3hot D3cold
[    8.823509] pci 0000:0a:04.0: PME# disabled
[    8.823571] pci_bus 0000:0a: fixups for bus
[    8.823573] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    8.823598] pci 0000:0a:02.0: scanning [bus 0b-0b] behind bridge, pass 0
[    8.823660] pci_bus 0000:0b: scanning bus
[    8.823664] pci_bus 0000:0b: fixups for bus
[    8.823667] pci 0000:0a:02.0: PCI bridge to [bus 0b]
[    8.823689] pci_bus 0000:0b: bus scan returning with max=0b
[    8.823696] pci 0000:0a:04.0: scanning [bus 0c-0c] behind bridge, pass 0
[    8.823758] pci_bus 0000:0c: scanning bus
[    8.823762] pci_bus 0000:0c: fixups for bus
[    8.823765] pci 0000:0a:04.0: PCI bridge to [bus 0c]
[    8.823787] pci_bus 0000:0c: bus scan returning with max=0c
[    8.823794] pci 0000:0a:02.0: scanning [bus 0b-0b] behind bridge, pass 1
[    8.823805] pci 0000:0a:04.0: scanning [bus 0c-0c] behind bridge, pass 1
[    8.823814] pci_bus 0000:0a: bus scan returning with max=0c
[    8.823821] pci 0000:09:00.0: scanning [bus 0a-0c] behind bridge, pass 1
[    8.823830] pci_bus 0000:09: bus scan returning with max=0c
[    8.823836] pci 0000:00:09.0: scanning [bus 0d-0d] behind bridge, pass 0
[    8.823922] pci_bus 0000:0d: scanning bus
[    8.823925] pci_bus 0000:0d: fixups for bus
[    8.823928] pci 0000:00:09.0: PCI bridge to [bus 0d]
[    8.823941] pci_bus 0000:0d: bus scan returning with max=0d
[    8.823947] pci 0000:00:0a.0: scanning [bus 0e-0e] behind bridge, pass 0
[    8.824007] pci_bus 0000:0e: scanning bus
[    8.824010] pci_bus 0000:0e: fixups for bus
[    8.824013] pci 0000:00:0a.0: PCI bridge to [bus 0e]
[    8.824026] pci_bus 0000:0e: bus scan returning with max=0e
[    8.824033] pci 0000:00:1c.0: scanning [bus 0f-0f] behind bridge, pass 0
[    8.824094] pci_bus 0000:0f: scanning bus
[    8.824117] pci 0000:0f:00.0: [1000:0062] type 00 class 0x010000
[    8.824147] pci 0000:0f:00.0: reg 10: [mem 0xb1940000-0xb1943fff 64bit]
[    8.824165] pci 0000:0f:00.0: reg 18: [io  0x1000-0x10ff]
[    8.824190] pci 0000:0f:00.0: reg 1c: [mem 0xb1900000-0xb193ffff 64bit]
[    8.824221] pci 0000:0f:00.0: reg 30: [mem 0xfff80000-0xffffffff pref]
[    8.824311] pci 0000:0f:00.0: supports D1
[    8.833857] pci_bus 0000:0f: fixups for bus
[    8.833866] pci 0000:00:1c.0: PCI bridge to [bus 0f]
[    8.833877] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    8.833889] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    8.833904] pci_bus 0000:0f: bus scan returning with max=0f
[    8.833917] pci 0000:00:1c.4: scanning [bus 10-10] behind bridge, pass 0
[    8.833986] pci_bus 0000:10: scanning bus
[    8.834016] pci 0000:10:00.0: [102b:0522] type 00 class 0x030000
[    8.834045] pci 0000:10:00.0: reg 10: [mem 0xb0000000-0xb0ffffff pref]
[    8.834066] pci 0000:10:00.0: reg 14: [mem 0xb1800000-0xb1803fff]
[    8.834086] pci 0000:10:00.0: reg 18: [mem 0xb1000000-0xb17fffff]
[    8.834159] pci 0000:10:00.0: reg 30: [mem 0xffff0000-0xffffffff pref]
[    8.842079] pci_bus 0000:10: fixups for bus
[    8.842087] pci 0000:00:1c.4: PCI bridge to [bus 10]
[    8.842104] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    8.842120] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    8.842127] pci_bus 0000:10: bus scan returning with max=10
[    8.842141] pci 0000:00:1c.5: scanning [bus 11-11] behind bridge, pass 0
[    8.842204] pci_bus 0000:11: scanning bus
[    8.842209] pci_bus 0000:11: fixups for bus
[    8.842211] pci 0000:00:1c.5: PCI bridge to [bus 11]
[    8.842227] pci_bus 0000:11: bus scan returning with max=11
[    8.842233] pci 0000:00:1e.0: scanning [bus 12-12] behind bridge, pass 0
[    8.842265] pci_bus 0000:12: scanning bus
[    8.842326] pci_bus 0000:12: fixups for bus
[    8.842329] pci 0000:00:1e.0: PCI bridge to [bus 12] (subtractive decode)
[    8.842345] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    8.842348] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    8.842352] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    8.842356] pci 0000:00:1e.0:   bridge window [mem 0xfed40000-0xfedfffff] (subtractive decode)
[    8.842359] pci 0000:00:1e.0:   bridge window [mem 0xb0000000-0xfdffffff] (subtractive decode)
[    8.842363] pci_bus 0000:12: bus scan returning with max=12
[    8.842370] pci 0000:00:01.0: scanning [bus 01-03] behind bridge, pass 1
[    8.842379] pci 0000:00:03.0: scanning [bus 04-04] behind bridge, pass 1
[    8.842387] pci 0000:00:05.0: scanning [bus 05-08] behind bridge, pass 1
[    8.842396] pci 0000:00:07.0: scanning [bus 09-0c] behind bridge, pass 1
[    8.842405] pci 0000:00:09.0: scanning [bus 0d-0d] behind bridge, pass 1
[    8.842414] pci 0000:00:0a.0: scanning [bus 0e-0e] behind bridge, pass 1
[    8.842424] pci 0000:00:1c.0: scanning [bus 0f-0f] behind bridge, pass 1
[    8.842433] pci 0000:00:1c.4: scanning [bus 10-10] behind bridge, pass 1
[    8.842443] pci 0000:00:1c.5: scanning [bus 11-11] behind bridge, pass 1
[    8.842452] pci 0000:00:1e.0: scanning [bus 12-12] behind bridge, pass 1
[    8.842460] pci_bus 0000:00: bus scan returning with max=12
[    8.842463] pci_bus 0000:00: on NUMA node 0
[    8.842468] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    8.871220] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP1._PRT]
[    8.871256] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP3._PRT]
[    8.871282] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP5._PRT]
[    8.871307] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP7._PRT]
[    8.871334] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP9._PRT]
[    8.871369] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRPA._PRT]
[    8.871411] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[    8.871439] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[    8.871521]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    8.871589]  pci0000:00: ACPI _OSC control (0x1d) granted
[    8.879474] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    8.879522] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    8.879567] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[    8.879611] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
[    8.879654] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879700] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879745] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879790] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    8.879821] xen/balloon: Initialising balloon driver.
[    8.881103] xen-balloon: Initialising balloon driver.
[    8.881327] vgaarb: device added: PCI:0000:10:00.0,decodes=io+mem,owns=io+mem,locks=none
[    8.881335] vgaarb: loaded
[    8.881339] vgaarb: bridge control possible 0000:10:00.0
[    8.881410] SCSI subsystem initialized
[    8.881415] ACPI: bus type scsi registered
[    8.881674] libata version 3.00 loaded.
[    8.881704] ACPI: bus type usb registered
[    8.881729] usbcore: registered new interface driver usbfs
[    8.881737] usbcore: registered new interface driver hub
[    8.881892] usbcore: registered new device driver usb
[    8.881937] PCI: Using ACPI for IRQ routing
[    8.893174] PCI: Discovered peer bus fe
[    8.893177] PCI: root bus fe: using default resources
[    8.893180] PCI: Probing PCI hardware (bus fe)
[    8.893199] PCI host bridge to bus 0000:fe
[    8.893202] pci_bus 0000:fe: root bus resource [io  0x0000-0xffff]
[    8.893206] pci_bus 0000:fe: root bus resource [mem 0x00000000-0xffffffffff]
[    8.893209] pci_bus 0000:fe: No busn resource found for root bus, will use [bus fe-ff]
[    8.893213] pci_bus 0000:fe: scanning bus
[    8.893222] pci 0000:fe:00.0: [8086:2c70] type 00 class 0x060000
[    8.893228] pci 0000:fe:00.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893280] pci 0000:fe:00.1: [8086:2d81] type 00 class 0x060000
[    8.893284] pci 0000:fe:00.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893342] pci 0000:fe:02.0: [8086:2d90] type 00 class 0x060000
[    8.893346] pci 0000:fe:02.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893396] pci 0000:fe:02.1: [8086:2d91] type 00 class 0x060000
[    8.893400] pci 0000:fe:02.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893452] pci 0000:fe:02.2: [8086:2d92] type 00 class 0x060000
[    8.893456] pci 0000:fe:02.2: calling quirk_mmio_always_on+0x0/0xa
[    8.893505] pci 0000:fe:02.3: [8086:2d93] type 00 class 0x060000
[    8.893510] pci 0000:fe:02.3: calling quirk_mmio_always_on+0x0/0xa
[    8.893559] pci 0000:fe:02.4: [8086:2d94] type 00 class 0x060000
[    8.893563] pci 0000:fe:02.4: calling quirk_mmio_always_on+0x0/0xa
[    8.893613] pci 0000:fe:02.5: [8086:2d95] type 00 class 0x060000
[    8.893617] pci 0000:fe:02.5: calling quirk_mmio_always_on+0x0/0xa
[    8.893669] pci 0000:fe:03.0: [8086:2d98] type 00 class 0x060000
[    8.893673] pci 0000:fe:03.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893723] pci 0000:fe:03.1: [8086:2d99] type 00 class 0x060000
[    8.893727] pci 0000:fe:03.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893776] pci 0000:fe:03.2: [8086:2d9a] type 00 class 0x060000
[    8.893781] pci 0000:fe:03.2: calling quirk_mmio_always_on+0x0/0xa
[    8.893831] pci 0000:fe:03.4: [8086:2d9c] type 00 class 0x060000
[    8.893835] pci 0000:fe:03.4: calling quirk_mmio_always_on+0x0/0xa
[    8.893890] pci 0000:fe:04.0: [8086:2da0] type 00 class 0x060000
[    8.893894] pci 0000:fe:04.0: calling quirk_mmio_always_on+0x0/0xa
[    8.893944] pci 0000:fe:04.1: [8086:2da1] type 00 class 0x060000
[    8.893948] pci 0000:fe:04.1: calling quirk_mmio_always_on+0x0/0xa
[    8.893997] pci 0000:fe:04.2: [8086:2da2] type 00 class 0x060000
[    8.894001] pci 0000:fe:04.2: calling quirk_mmio_always_on+0x0/0xa
[    8.894051] pci 0000:fe:04.3: [8086:2da3] type 00 class 0x060000
[    8.894055] pci 0000:fe:04.3: calling quirk_mmio_always_on+0x0/0xa
[    8.894110] pci 0000:fe:05.0: [8086:2da8] type 00 class 0x060000
[    8.894114] pci 0000:fe:05.0: calling quirk_mmio_always_on+0x0/0xa
[    8.894163] pci 0000:fe:05.1: [8086:2da9] type 00 class 0x060000
[    8.894167] pci 0000:fe:05.1: calling quirk_mmio_always_on+0x0/0xa
[    8.894217] pci 0000:fe:05.2: [8086:2daa] type 00 class 0x060000
[    8.894221] pci 0000:fe:05.2: calling quirk_mmio_always_on+0x0/0xa
[    8.894271] pci 0000:fe:05.3: [8086:2dab] type 00 class 0x060000
[    8.894275] pci 0000:fe:05.3: calling quirk_mmio_always_on+0x0/0xa
[    8.894331] pci 0000:fe:06.0: [8086:2db0] type 00 class 0x060000
[    8.894335] pci 0000:fe:06.0: calling quirk_mmio_always_on+0x0/0xa
[    8.894387] pci 0000:fe:06.1: [8086:2db1] type 00 class 0x060000
[    8.894394] pci 0000:fe:06.1: calling quirk_mmio_always_on+0x0/0xa
[    8.894447] pci 0000:fe:06.2: [8086:2db2] type 00 class 0x060000
[    8.894451] pci 0000:fe:06.2: calling quirk_mmio_always_on+0x0/0xa
[    8.894501] pci 0000:fe:06.3: [8086:2db3] type 00 class 0x060000
[    8.894505] pci 0000:fe:06.3: calling quirk_mmio_always_on+0x0/0xa
[    8.894584] pci_bus 0000:fe: fixups for bus
[    8.894587] pci_bus 0000:fe: bus scan returning with max=fe
[    8.894591] pci_bus 0000:fe: busn_res: [bus fe-ff] end is updated to fe
[    8.894956] PCI: Discovered peer bus ff
[    8.894959] PCI: root bus ff: using default resources
[    8.894961] PCI: Probing PCI hardware (bus ff)
[    8.894977] PCI host bridge to bus 0000:ff
[    8.894980] pci_bus 0000:ff: root bus resource [io  0x0000-0xffff]
[    8.894984] pci_bus 0000:ff: root bus resource [mem 0x00000000-0xffffffffff]
[    8.894987] pci_bus 0000:ff: No busn resource found for root bus, will use [bus ff-ff]
[    8.894991] pci_bus 0000:ff: scanning bus
[    8.894999] pci 0000:ff:00.0: [8086:2c70] type 00 class 0x060000
[    8.895004] pci 0000:ff:00.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895053] pci 0000:ff:00.1: [8086:2d81] type 00 class 0x060000
[    8.895057] pci 0000:ff:00.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895120] pci 0000:ff:02.0: [8086:2d90] type 00 class 0x060000
[    8.895124] pci 0000:ff:02.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895172] pci 0000:ff:02.1: [8086:2d91] type 00 class 0x060000
[    8.895176] pci 0000:ff:02.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895226] pci 0000:ff:02.2: [8086:2d92] type 00 class 0x060000
[    8.895230] pci 0000:ff:02.2: calling quirk_mmio_always_on+0x0/0xa
[    8.895277] pci 0000:ff:02.3: [8086:2d93] type 00 class 0x060000
[    8.895281] pci 0000:ff:02.3: calling quirk_mmio_always_on+0x0/0xa
[    8.895329] pci 0000:ff:02.4: [8086:2d94] type 00 class 0x060000
[    8.895333] pci 0000:ff:02.4: calling quirk_mmio_always_on+0x0/0xa
[    8.895380] pci 0000:ff:02.5: [8086:2d95] type 00 class 0x060000
[    8.895384] pci 0000:ff:02.5: calling quirk_mmio_always_on+0x0/0xa
[    8.895434] pci 0000:ff:03.0: [8086:2d98] type 00 class 0x060000
[    8.895438] pci 0000:ff:03.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895486] pci 0000:ff:03.1: [8086:2d99] type 00 class 0x060000
[    8.895490] pci 0000:ff:03.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895537] pci 0000:ff:03.2: [8086:2d9a] type 00 class 0x060000
[    8.895549] pci 0000:ff:03.2: calling quirk_mmio_always_on+0x0/0xa
[    8.895598] pci 0000:ff:03.4: [8086:2d9c] type 00 class 0x060000
[    8.895602] pci 0000:ff:03.4: calling quirk_mmio_always_on+0x0/0xa
[    8.895655] pci 0000:ff:04.0: [8086:2da0] type 00 class 0x060000
[    8.895658] pci 0000:ff:04.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895706] pci 0000:ff:04.1: [8086:2da1] type 00 class 0x060000
[    8.895710] pci 0000:ff:04.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895758] pci 0000:ff:04.2: [8086:2da2] type 00 class 0x060000
[    8.895762] pci 0000:ff:04.2: calling quirk_mmio_always_on+0x0/0xa
[    8.895809] pci 0000:ff:04.3: [8086:2da3] type 00 class 0x060000
[    8.895813] pci 0000:ff:04.3: calling quirk_mmio_always_on+0x0/0xa
[    8.895865] pci 0000:ff:05.0: [8086:2da8] type 00 class 0x060000
[    8.895869] pci 0000:ff:05.0: calling quirk_mmio_always_on+0x0/0xa
[    8.895917] pci 0000:ff:05.1: [8086:2da9] type 00 class 0x060000
[    8.895921] pci 0000:ff:05.1: calling quirk_mmio_always_on+0x0/0xa
[    8.895968] pci 0000:ff:05.2: [8086:2daa] type 00 class 0x060000
[    8.895972] pci 0000:ff:05.2: calling quirk_mmio_always_on+0x0/0xa
[    8.896020] pci 0000:ff:05.3: [8086:2dab] type 00 class 0x060000
[    8.896024] pci 0000:ff:05.3: calling quirk_mmio_always_on+0x0/0xa
[    8.896078] pci 0000:ff:06.0: [8086:2db0] type 00 class 0x060000
[    8.896082] pci 0000:ff:06.0: calling quirk_mmio_always_on+0x0/0xa
[    8.896130] pci 0000:ff:06.1: [8086:2db1] type 00 class 0x060000
[    8.896134] pci 0000:ff:06.1: calling quirk_mmio_always_on+0x0/0xa
[    8.896182] pci 0000:ff:06.2: [8086:2db2] type 00 class 0x060000
[    8.896186] pci 0000:ff:06.2: calling quirk_mmio_always_on+0x0/0xa
[    8.896233] pci 0000:ff:06.3: [8086:2db3] type 00 class 0x060000
[    8.896237] pci 0000:ff:06.3: calling quirk_mmio_always_on+0x0/0xa
[    8.896312] pci_bus 0000:ff: fixups for bus
[    8.896315] pci_bus 0000:ff: bus scan returning with max=ff
[    8.896318] pci_bus 0000:ff: busn_res: [bus ff] end is updated to ff
[    8.896670] PCI: pci_cache_line_size set to 64 bytes
[    8.896697] pci 0000:00:13.0: BAR 0: reserving [mem 0xb1b24000-0xb1b24fff flags 0x40200] (d=0, p=0)
[    8.896711] pci 0000:00:16.0: BAR 0: reserving [mem 0xb1b00000-0xb1b03fff flags 0x140204] (d=0, p=0)
[    8.896717] pci 0000:00:16.1: BAR 0: reserving [mem 0xb1b04000-0xb1b07fff flags 0x140204] (d=0, p=0)
[    8.896723] pci 0000:00:16.2: BAR 0: reserving [mem 0xb1b08000-0xb1b0bfff flags 0x140204] (d=0, p=0)
[    8.896729] pci 0000:00:16.3: BAR 0: reserving [mem 0xb1b0c000-0xb1b0ffff flags 0x140204] (d=0, p=0)
[    8.896735] pci 0000:00:16.4: BAR 0: reserving [mem 0xb1b10000-0xb1b13fff flags 0x140204] (d=0, p=0)
[    8.896741] pci 0000:00:16.5: BAR 0: reserving [mem 0xb1b14000-0xb1b17fff flags 0x140204] (d=0, p=0)
[    8.896746] pci 0000:00:16.6: BAR 0: reserving [mem 0xb1b18000-0xb1b1bfff flags 0x140204] (d=0, p=0)
[    8.896752] pci 0000:00:16.7: BAR 0: reserving [mem 0xb1b1c000-0xb1b1ffff flags 0x140204] (d=0, p=0)
[    8.896759] pci 0000:00:1a.0: BAR 4: reserving [io  0x30e0-0x30ff flags 0x40101] (d=0, p=0)
[    8.896764] pci 0000:00:1a.1: BAR 4: reserving [io  0x30c0-0x30df flags 0x40101] (d=0, p=0)
[    8.896770] pci 0000:00:1a.2: BAR 4: reserving [io  0x30a0-0x30bf flags 0x40101] (d=0, p=0)
[    8.896776] pci 0000:00:1a.7: BAR 0: reserving [mem 0xb1b22000-0xb1b223ff flags 0x40200] (d=0, p=0)
[    8.896788] pci 0000:00:1d.0: BAR 4: reserving [io  0x3080-0x309f flags 0x40101] (d=0, p=0)
[    8.896793] pci 0000:00:1d.1: BAR 4: reserving [io  0x3060-0x307f flags 0x40101] (d=0, p=0)
[    8.896799] pci 0000:00:1d.2: BAR 4: reserving [io  0x3040-0x305f flags 0x40101] (d=0, p=0)
[    8.896805] pci 0000:00:1d.7: BAR 0: reserving [mem 0xb1b21000-0xb1b213ff flags 0x40200] (d=0, p=0)
[    8.896815] pci 0000:00:1f.2: BAR 0: reserving [io  0x3108-0x310f flags 0x40101] (d=0, p=0)
[    8.896819] pci 0000:00:1f.2: BAR 1: reserving [io  0x3114-0x3117 flags 0x40101] (d=0, p=0)
[    8.896823] pci 0000:00:1f.2: BAR 2: reserving [io  0x3100-0x3107 flags 0x40101] (d=0, p=0)
[    8.896827] pci 0000:00:1f.2: BAR 3: reserving [io  0x3110-0x3113 flags 0x40101] (d=0, p=0)
[    8.896830] pci 0000:00:1f.2: BAR 4: reserving [io  0x3020-0x303f flags 0x40101] (d=0, p=0)
[    8.896834] pci 0000:00:1f.2: BAR 5: reserving [mem 0xb1b20000-0xb1b207ff flags 0x40200] (d=0, p=0)
[    8.896840] pci 0000:00:1f.3: BAR 0: reserving [mem 0xb1b23000-0xb1b230ff flags 0x140204] (d=0, p=0)
[    8.896845] pci 0000:00:1f.3: BAR 4: reserving [io  0x3000-0x301f flags 0x40101] (d=0, p=0)
[    8.896850] pci 0000:01:00.0: BAR 0: reserving [mem 0xb1a20000-0xb1a3ffff flags 0x40200] (d=0, p=0)
[    8.896855] pci 0000:01:00.0: BAR 2: reserving [io  0x2020-0x203f flags 0x40101] (d=0, p=0)
[    8.896858] pci 0000:01:00.0: BAR 3: reserving [mem 0xb1ac4000-0xb1ac7fff flags 0x40200] (d=0, p=0)
[    8.896863] pci 0000:01:00.0: BAR 7: reserving [mem 0xb1a40000-0xb1a5ffff flags 0x140204] (d=0, p=0)
[    8.896867] pci 0000:01:00.0: BAR 10: reserving [mem 0xb1a60000-0xb1a7ffff flags 0x140204] (d=0, p=0)
[    8.896873] pci 0000:01:00.1: BAR 0: reserving [mem 0xb1a00000-0xb1a1ffff flags 0x40200] (d=0, p=0)
[    8.896877] pci 0000:01:00.1: BAR 2: reserving [io  0x2000-0x201f flags 0x40101] (d=0, p=0)
[    8.896881] pci 0000:01:00.1: BAR 3: reserving [mem 0xb1ac0000-0xb1ac3fff flags 0x40200] (d=0, p=0)
[    8.896885] pci 0000:01:00.1: BAR 7: reserving [mem 0xb1a80000-0xb1a9ffff flags 0x140204] (d=0, p=0)
[    8.896889] pci 0000:01:00.1: BAR 10: reserving [mem 0xb1aa0000-0xb1abffff flags 0x140204] (d=0, p=0)
[    8.896908] pci 0000:0f:00.0: BAR 0: reserving [mem 0xb1940000-0xb1943fff flags 0x140204] (d=0, p=0)
[    8.896912] pci 0000:0f:00.0: BAR 2: reserving [io  0x1000-0x10ff flags 0x40101] (d=0, p=0)
[    8.896916] pci 0000:0f:00.0: BAR 3: reserving [mem 0xb1900000-0xb193ffff flags 0x140204] (d=0, p=0)
[    8.896923] pci 0000:10:00.0: BAR 0: reserving [mem 0xb0000000-0xb0ffffff flags 0x42208] (d=0, p=0)
[    8.896927] pci 0000:10:00.0: BAR 1: reserving [mem 0xb1800000-0xb1803fff flags 0x40200] (d=0, p=0)
[    8.896931] pci 0000:10:00.0: BAR 2: reserving [mem 0xb1000000-0xb17fffff flags 0x40200] (d=0, p=0)
[    8.897136] e820: reserve RAM buffer [mem 0x0009b000-0x0009ffff]
[    8.897139] e820: reserve RAM buffer [mem 0x8c21c000-0x8fffffff]
[    8.897249] Switching to clocksource xen
[    8.897508] pnp: PnP ACPI init
[    8.897518] ACPI: bus type pnp registered
[    8.897745] pnp 00:00: [bus 00-fd]
[    8.897749] pnp 00:00: [io  0x0cf8-0x0cff]
[    8.897752] pnp 00:00: [io  0x0000-0x0cf7 window]
[    8.897755] pnp 00:00: [io  0x0d00-0xffff window]
[    8.897758] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    8.897761] pnp 00:00: [mem 0x000c4000-0x000cbfff window]
[    8.897764] pnp 00:00: [mem 0xfed40000-0xfedfffff window]
[    8.897767] pnp 00:00: [mem 0xb0000000-0xfdffffff window]
[    8.897770] pnp 00:00: [mem 0x00000000 window]
[    8.897794] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)
[    8.897802] pnp 00:01: [mem 0xfec00000-0xfecfffff]
[    8.897817] pnp 00:01: Plug and Play ACPI device, IDs PNP0003 (active)
[    8.897942] pnp 00:02: [io  0x0000-0x000f]
[    8.897945] pnp 00:02: [io  0x0081-0x0083]
[    8.897948] pnp 00:02: [io  0x0087]
[    8.897950] pnp 00:02: [io  0x0089-0x008b]
[    8.897953] pnp 00:02: [io  0x008f]
[    8.897955] pnp 00:02: [io  0x00c0-0x00df]
[    8.897958] pnp 00:02: [dma 4]
[    8.897974] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    8.897982] pnp 00:03: [io  0x0070-0x0071]
[    8.897984] pnp 00:03: [io  0x0074-0x0077]
[    8.897988] xen: registering gsi 8 triggering 1 polarity 0
[    8.898021] pnp 00:03: [irq 8]
[    8.898035] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    8.898044] pnp 00:04: [io  0x00f0]
[    8.898046] xen: registering gsi 13 triggering 1 polarity 0
[    8.898075] pnp 00:04: [irq 13]
[    8.898092] pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active)
[    8.898100] pnp 00:05: [io  0x0061]
[    8.898114] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[    8.898143] pnp 00:06: [mem 0xfed00000-0xfed003ff]
[    8.898163] pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
[    8.898173] pnp 00:07: [io  0x0500-0x057f]
[    8.898175] pnp 00:07: [io  0x0400-0x047f]
[    8.898178] pnp 00:07: [io  0x0092]
[    8.898180] pnp 00:07: [io  0x0010-0x001f]
[    8.898182] pnp 00:07: [io  0x0072-0x0073]
[    8.898185] pnp 00:07: [io  0x0080]
[    8.898187] pnp 00:07: [io  0x0084-0x0086]
[    8.898190] pnp 00:07: [io  0x0088]
[    8.898192] pnp 00:07: [io  0x008c-0x008e]
[    8.898194] pnp 00:07: [io  0x0090-0x009f]
[    8.898197] pnp 00:07: [io  0x0800-0x081f]
[    8.898199] pnp 00:07: [io  0x0ca2-0x0ca3]
[    8.898202] pnp 00:07: [io  0x0600-0x061f]
[    8.898204] pnp 00:07: [io  0x0880-0x0883]
[    8.898206] pnp 00:07: [io  0x0ca4-0x0ca5]
[    8.898209] pnp 00:07: [mem 0xfed1c000-0xfed3fffe]
[    8.898211] pnp 00:07: [mem 0xff000000-0xffffffff]
[    8.898214] pnp 00:07: [mem 0xfee00000-0xfeefffff]
[    8.898218] pnp 00:07: [mem 0xfe900000-0xfe90001f]
[    8.898221] pnp 00:07: [mem 0xfea00000-0xfea0001f]
[    8.898224] pnp 00:07: [mem 0xfed1b000-0xfed1bfff]
[    8.898275] system 00:07: [io  0x0500-0x057f] has been reserved
[    8.898279] system 00:07: [io  0x0400-0x047f] has been reserved
[    8.898282] system 00:07: [io  0x0800-0x081f] has been reserved
[    8.898285] system 00:07: [io  0x0ca2-0x0ca3] has been reserved
[    8.898289] system 00:07: [io  0x0600-0x061f] has been reserved
[    8.898292] system 00:07: [io  0x0880-0x0883] has been reserved
[    8.898295] system 00:07: [io  0x0ca4-0x0ca5] has been reserved
[    8.898299] system 00:07: [mem 0xfed1c000-0xfed3fffe] could not be reserved
[    8.898303] system 00:07: [mem 0xff000000-0xffffffff] could not be reserved
[    8.898306] system 00:07: [mem 0xfee00000-0xfeefffff] could not be reserved
[    8.898310] system 00:07: [mem 0xfe900000-0xfe90001f] has been reserved
[    8.898313] system 00:07: [mem 0xfea00000-0xfea0001f] has been reserved
[    8.898316] system 00:07: [mem 0xfed1b000-0xfed1bfff] has been reserved
[    8.898320] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    8.898436] pnp 00:08: [io  0x02f8-0x02ff]
[    8.898440] xen: registering gsi 3 triggering 1 polarity 0
[    8.898469] pnp 00:08: [irq 3]
[    8.898513] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active)
[    8.898535] pnp 00:09: [mem 0xfed40000-0xfed44fff]
[    8.898551] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active)
[    8.898576] pnp 00:0a: [io  0x0ca2]
[    8.898579] pnp 00:0a: [io  0x0ca3]
[    8.898594] pnp 00:0a: Plug and Play ACPI device, IDs IPI0001 (active)
[    8.898626] pnp: PnP ACPI: found 11 devices
[    8.898652] ACPI: ACPI bus type pnp unregistered
[    8.905571] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    8.905583] pci 0000:0f:00.0: no compatible bridge window for [mem 0xfff80000-0xffffffff pref]
[    8.905588] pci 0000:10:00.0: no compatible bridge window for [mem 0xffff0000-0xffffffff pref]
[    8.905733] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus 0f] add_size 200000
[    8.905747] pci 0000:00:1c.4: bridge window [io  0x1000-0x0fff] to [bus 10] add_size 1000
[    8.905761] pci 0000:00:1c.5: bridge window [io  0x1000-0x0fff] to [bus 11] add_size 1000
[    8.905765] pci 0000:00:1c.5: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 11] add_size 200000
[    8.905769] pci 0000:00:1c.5: bridge window [mem 0x00100000-0x000fffff] to [bus 11] add_size 200000
[    8.905802] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x001fffff pref] get_res_add_size add_size 200000
[    8.905806] pci 0000:00:1c.5: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[    8.905810] pci 0000:00:1c.5: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[    8.905814] pci 0000:00:1c.4: res[13]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
[    8.905818] pci 0000:00:1c.5: res[13]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
[    8.905824] pci 0000:00:1c.0: BAR 15: assigned [mem 0xb1c00000-0xb1efffff pref]
[    8.905828] pci 0000:00:1c.5: BAR 14: assigned [mem 0xb1f00000-0xb20fffff]
[    8.905833] pci 0000:00:1c.5: BAR 15: assigned [mem 0xb2100000-0xb22fffff 64bit pref]
[    8.905837] pci 0000:00:1c.4: BAR 13: assigned [io  0x4000-0x4fff]
[    8.905841] pci 0000:00:1c.5: BAR 13: assigned [io  0x5000-0x5fff]
[    8.905845] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    8.905850] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    8.905858] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    8.905869] pci 0000:00:03.0: PCI bridge to [bus 04]
[    8.905884] pci 0000:06:02.0: PCI bridge to [bus 07]
[    8.905905] pci 0000:06:04.0: PCI bridge to [bus 08]
[    8.905925] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    8.905946] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    8.905961] pci 0000:0a:02.0: PCI bridge to [bus 0b]
[    8.905981] pci 0000:0a:04.0: PCI bridge to [bus 0c]
[    8.906002] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    8.906022] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    8.906037] pci 0000:00:09.0: PCI bridge to [bus 0d]
[    8.906052] pci 0000:00:0a.0: PCI bridge to [bus 0e]
[    8.906068] pci 0000:0f:00.0: BAR 6: assigned [mem 0xb1c00000-0xb1c7ffff pref]
[    8.906071] pci 0000:00:1c.0: PCI bridge to [bus 0f]
[    8.906076] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    8.906084] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    8.906090] pci 0000:00:1c.0:   bridge window [mem 0xb1c00000-0xb1efffff pref]
[    8.906100] pci 0000:10:00.0: BAR 6: assigned [mem 0xb1810000-0xb181ffff pref]
[    8.906103] pci 0000:00:1c.4: PCI bridge to [bus 10]
[    8.906108] pci 0000:00:1c.4:   bridge window [io  0x4000-0x4fff]
[    8.906115] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    8.906122] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    8.906131] pci 0000:00:1c.5: PCI bridge to [bus 11]
[    8.906136] pci 0000:00:1c.5:   bridge window [io  0x5000-0x5fff]
[    8.906143] pci 0000:00:1c.5:   bridge window [mem 0xb1f00000-0xb20fffff]
[    8.906150] pci 0000:00:1c.5:   bridge window [mem 0xb2100000-0xb22fffff 64bit pref]
[    8.906159] pci 0000:00:1e.0: PCI bridge to [bus 12]
[    8.906182] xen: registering gsi 28 triggering 0 polarity 1
[    8.906196] xen: --> pirq=28 -> irq=28 (gsi=28)
[    8.906232] xen: registering gsi 24 triggering 0 polarity 1
[    8.906238] xen: --> pirq=24 -> irq=24 (gsi=24)
[    8.906270] xen: registering gsi 26 triggering 0 polarity 1
[    8.906276] xen: --> pirq=26 -> irq=26 (gsi=26)
[    8.906326] xen: registering gsi 30 triggering 0 polarity 1
[    8.906332] xen: --> pirq=30 -> irq=30 (gsi=30)
[    8.906381] xen: registering gsi 32 triggering 0 polarity 1
[    8.906387] xen: --> pirq=32 -> irq=32 (gsi=32)
[    8.906419] xen: registering gsi 33 triggering 0 polarity 1
[    8.906425] xen: --> pirq=33 -> irq=33 (gsi=33)
[    8.906458] xen: registering gsi 16 triggering 0 polarity 1
[    8.906466] xen: --> pirq=16 -> irq=16 (gsi=16)
[    8.906498] xen: registering gsi 16 triggering 0 polarity 1
[    8.906501] Already setup the GSI :16
[    8.906508] xen: registering gsi 17 triggering 0 polarity 1
[    8.906513] xen: --> pirq=17 -> irq=17 (gsi=17)
[    8.906549] pci 0000:00:1e.0: setting latency timer to 64
[    8.906555] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    8.906558] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    8.906561] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    8.906564] pci_bus 0000:00: resource 7 [mem 0xfed40000-0xfedfffff]
[    8.906568] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xfdffffff]
[    8.906571] pci_bus 0000:01: resource 0 [io  0x2000-0x2fff]
[    8.906574] pci_bus 0000:01: resource 1 [mem 0xb1a00000-0xb1afffff]
[    8.906578] pci_bus 0000:0f: resource 0 [io  0x1000-0x1fff]
[    8.906581] pci_bus 0000:0f: resource 1 [mem 0xb1900000-0xb19fffff]
[    8.906584] pci_bus 0000:0f: resource 2 [mem 0xb1c00000-0xb1efffff pref]
[    8.906587] pci_bus 0000:10: resource 0 [io  0x4000-0x4fff]
[    8.906590] pci_bus 0000:10: resource 1 [mem 0xb1000000-0xb18fffff]
[    8.906594] pci_bus 0000:10: resource 2 [mem 0xb0000000-0xb0ffffff 64bit pref]
[    8.906597] pci_bus 0000:11: resource 0 [io  0x5000-0x5fff]
[    8.906600] pci_bus 0000:11: resource 1 [mem 0xb1f00000-0xb20fffff]
[    8.906603] pci_bus 0000:11: resource 2 [mem 0xb2100000-0xb22fffff 64bit pref]
[    8.906607] pci_bus 0000:12: resource 4 [io  0x0000-0x0cf7]
[    8.906609] pci_bus 0000:12: resource 5 [io  0x0d00-0xffff]
[    8.906612] pci_bus 0000:12: resource 6 [mem 0x000a0000-0x000bffff]
[    8.906615] pci_bus 0000:12: resource 7 [mem 0xfed40000-0xfedfffff]
[    8.906618] pci_bus 0000:12: resource 8 [mem 0xb0000000-0xfdffffff]
[    8.906622] pci_bus 0000:fe: resource 4 [io  0x0000-0xffff]
[    8.906624] pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff]
[    8.906628] pci_bus 0000:ff: resource 4 [io  0x0000-0xffff]
[    8.906631] pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff]
[    8.906665] NET: Registered protocol family 2
[    8.906794] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    8.907486] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    8.907663] TCP: Hash tables configured (established 262144 bind 65536)
[    8.907693] TCP: reno registered
[    8.907700] UDP hash table entries: 16384 (order: 7, 524288 bytes)
[    8.907798] UDP-Lite hash table entries: 16384 (order: 7, 524288 bytes)
[    8.907939] NET: Registered protocol family 1
[    8.908037] RPC: Registered named UNIX socket transport module.
[    8.908042] RPC: Registered udp transport module.
[    8.908045] RPC: Registered tcp transport module.
[    8.908047] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    8.908110] pci 0000:00:1a.0: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908118] xen: registering gsi 19 triggering 0 polarity 1
[    8.908128] xen: --> pirq=19 -> irq=19 (gsi=19)
[    8.908182] pci 0000:00:1a.1: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908188] xen: registering gsi 19 triggering 0 polarity 1
[    8.908191] Already setup the GSI :19
[    8.908217] pci 0000:00:1a.2: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908222] xen: registering gsi 19 triggering 0 polarity 1
[    8.908225] Already setup the GSI :19
[    8.908250] pci 0000:00:1a.7: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908257] xen: registering gsi 19 triggering 0 polarity 1
[    8.908259] Already setup the GSI :19
[    8.908413] pci 0000:00:1d.0: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908420] xen: registering gsi 16 triggering 0 polarity 1
[    8.908422] Already setup the GSI :16
[    8.908448] pci 0000:00:1d.1: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908453] xen: registering gsi 16 triggering 0 polarity 1
[    8.908455] Already setup the GSI :16
[    8.908481] pci 0000:00:1d.2: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908486] xen: registering gsi 16 triggering 0 polarity 1
[    8.908489] Already setup the GSI :16
[    8.908514] pci 0000:00:1d.7: calling quirk_usb_early_handoff+0x0/0x6eb
[    8.908520] xen: registering gsi 16 triggering 0 polarity 1
[    8.908523] Already setup the GSI :16
[    8.908708] pci 0000:01:00.0: calling quirk_e100_interrupt+0x0/0x18d
[    8.908716] pci 0000:01:00.1: calling quirk_e100_interrupt+0x0/0x18d
[    8.908740] pci 0000:10:00.0: calling pci_fixup_video+0x0/0xc1
[    8.908747] pci 0000:10:00.0: Boot video device
[    8.908836] PCI: CLS 64 bytes, default 64
[    8.908869] Unpacking initramfs...
[    8.920521] Freeing initrd memory: 14764k freed
[    8.926621] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    8.926956] NFS: Registering the id_resolver key type
[    8.926969] Key type id_resolver registered
[    8.926971] Key type id_legacy registered
[    8.926984] NTFS driver 2.1.30 [Flags: R/O].
[    8.927096] fuse init (API version 7.20)
[    8.927337] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[    8.928200] Btrfs loaded
[    8.928212] msgmni has been set to 32768
[    8.928580] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    8.928585] io scheduler noop registered
[    8.928587] io scheduler deadline registered
[    8.928592] io scheduler cfq registered (default)
[    8.931221] aer 0000:00:01.0:pcie02: service driver aer loaded
[    8.931259] aer 0000:00:03.0:pcie02: service driver aer loaded
[    8.931313] aer 0000:00:05.0:pcie02: service driver aer loaded
[    8.931364] aer 0000:00:07.0:pcie02: service driver aer loaded
[    8.931401] aer 0000:00:09.0:pcie02: service driver aer loaded
[    8.931439] aer 0000:00:0a.0:pcie02: service driver aer loaded
[    8.931456] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[    8.931459] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    8.931462] pci 0000:01:00.1: Signaling PME through PCIe PME interrupt
[    8.931469] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[    8.931480] pcieport 0000:00:03.0: Signaling PME through PCIe PME interrupt
[    8.931486] pcie_pme 0000:00:03.0:pcie01: service driver pcie_pme loaded
[    8.931497] pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt
[    8.931500] pcieport 0000:05:00.0: Signaling PME through PCIe PME interrupt
[    8.931504] pcieport 0000:06:02.0: Signaling PME through PCIe PME interrupt
[    8.931507] pcieport 0000:06:04.0: Signaling PME through PCIe PME interrupt
[    8.931513] pcie_pme 0000:00:05.0:pcie01: service driver pcie_pme loaded
[    8.931526] pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt
[    8.931529] pcieport 0000:09:00.0: Signaling PME through PCIe PME interrupt
[    8.931532] pcieport 0000:0a:02.0: Signaling PME through PCIe PME interrupt
[    8.931535] pcieport 0000:0a:04.0: Signaling PME through PCIe PME interrupt
[    8.931542] pcie_pme 0000:00:07.0:pcie01: service driver pcie_pme loaded
[    8.931553] pcieport 0000:00:09.0: Signaling PME through PCIe PME interrupt
[    8.931559] pcie_pme 0000:00:09.0:pcie01: service driver pcie_pme loaded
[    8.931570] pcieport 0000:00:0a.0: Signaling PME through PCIe PME interrupt
[    8.931576] pcie_pme 0000:00:0a.0:pcie01: service driver pcie_pme loaded
[    8.931606] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[    8.931610] pci 0000:0f:00.0: Signaling PME through PCIe PME interrupt
[    8.931616] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[    8.931647] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt
[    8.931651] pci 0000:10:00.0: Signaling PME through PCIe PME interrupt
[    8.931657] pcie_pme 0000:00:1c.4:pcie01: service driver pcie_pme loaded
[    8.931686] pcieport 0000:00:1c.5: Signaling PME through PCIe PME interrupt
[    8.931694] pcie_pme 0000:00:1c.5:pcie01: service driver pcie_pme loaded
[    8.931798] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
[    8.931806] ACPI: Sleep Button [SLPB]
[    8.931832] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    8.931836] ACPI: Power Button [PWRF]
[    8.931901] ACPI: Requesting acpi_cpufreq
[    8.932364] Monitor-Mwait will be used to enter C-1 state
[    8.932422] Monitor-Mwait will be used to enter C-3 state
[    8.936323] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    8.956986] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    8.957582] hpet_acpi_add: no address or irqs in _CRS
[    8.957661] Non-volatile memory driver v1.3
[    8.957664] Linux agpgart interface v0.103
[    8.957780] ahci 0000:00:1f.2: version 3.0
[    8.957793] xen: registering gsi 18 triggering 0 polarity 1
[    8.957805] xen: --> pirq=18 -> irq=18 (gsi=18)
[    8.958019] ahci 0000:00:1f.2: forcing PORTS_IMPL to 0x3f
[    8.958084] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[    8.958090] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc 
[    8.958097] ahci 0000:00:1f.2: setting latency timer to 64
[    8.958954] scsi0 : ahci
[    8.959091] scsi1 : ahci
[    8.959235] scsi2 : ahci
[    8.959404] scsi3 : ahci
[    8.959589] scsi4 : ahci
[    8.959726] scsi5 : ahci
[    8.959753] ata1: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20100 irq 128
[    8.959758] ata2: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20180 irq 128
[    8.959761] ata3: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20200 irq 128
[    8.959765] ata4: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20280 irq 128
[    8.959769] ata5: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20300 irq 128
[    8.959773] ata6: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20380 irq 128
[    8.959833] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
[    8.959836] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    8.959862] igb: Intel(R) Gigabit Ethernet Network Driver - version 4.0.1-k
[    8.959865] igb: Copyright (c) 2007-2012 Intel Corporation.
[    8.959882] xen: registering gsi 40 triggering 0 polarity 1
[    8.959891] xen: --> pirq=40 -> irq=40 (gsi=40)
[    8.960770] igb 0000:01:00.0: PHY reset is blocked due to SOL/IDER session.
[    9.006468] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
[    9.006474] igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e4
[    9.006551] igb 0000:01:00.0: eth0: PBA No: 0080FF-0FF
[    9.006554] igb 0000:01:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[    9.006566] xen: registering gsi 28 triggering 0 polarity 1
[    9.006570] Already setup the GSI :28
[    9.197779] igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
[    9.197784] igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e5
[    9.197861] igb 0000:01:00.1: eth1: PBA No: 0080FF-0FF
[    9.197864] igb 0000:01:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[    9.197882] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.1-k
[    9.197885] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    9.197898] sky2: driver version 1.30
[    9.198251] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    9.198279] xen: registering gsi 19 triggering 0 polarity 1
[    9.198289] Already setup the GSI :19
[    9.198305] ehci_hcd 0000:00:1a.7: enabling bus mastering
[    9.198312] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[    9.198317] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[    9.198324] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[    9.198344] ehci_hcd 0000:00:1a.7: debug port 1
[    9.202402] ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
[    9.202459] ehci_hcd 0000:00:1a.7: irq 19, io mem 0xb1b22000
[    9.213520] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[    9.213578] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    9.213585] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.213591] usb usb1: Product: EHCI Host Controller
[    9.213597] usb usb1: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 ehci_hcd
[    9.213604] usb usb1: SerialNumber: 0000:00:1a.7
[    9.213820] hub 1-0:1.0: USB hub found
[    9.213830] hub 1-0:1.0: 6 ports detected
[    9.213915] xen: registering gsi 16 triggering 0 polarity 1
[    9.213919] Already setup the GSI :16
[    9.213934] ehci_hcd 0000:00:1d.7: enabling bus mastering
[    9.213941] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[    9.213946] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    9.213951] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[    9.213968] ehci_hcd 0000:00:1d.7: debug port 1
[    9.217965] ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
[    9.218021] ehci_hcd 0000:00:1d.7: irq 16, io mem 0xb1b21000
[    9.229529] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    9.229576] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    9.229583] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.229589] usb usb2: Product: EHCI Host Controller
[    9.229594] usb usb2: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 ehci_hcd
[    9.229601] usb usb2: SerialNumber: 0000:00:1d.7
[    9.229809] hub 2-0:1.0: USB hub found
[    9.229821] hub 2-0:1.0: 6 ports detected
[    9.229906] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    9.229919] uhci_hcd: USB Universal Host Controller Interface driver
[    9.229933] xen: registering gsi 19 triggering 0 polarity 1
[    9.229937] Already setup the GSI :19
[    9.229942] uhci_hcd 0000:00:1a.0: enabling bus mastering
[    9.229949] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[    9.229954] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[    9.229959] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[    9.229990] uhci_hcd 0000:00:1a.0: irq 19, io base 0x000030e0
[    9.230134] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    9.230138] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.230141] usb usb3: Product: UHCI Host Controller
[    9.230144] usb usb3: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.230148] usb usb3: SerialNumber: 0000:00:1a.0
[    9.230321] hub 3-0:1.0: USB hub found
[    9.230330] hub 3-0:1.0: 2 ports detected
[    9.230404] xen: registering gsi 19 triggering 0 polarity 1
[    9.230408] Already setup the GSI :19
[    9.230416] uhci_hcd 0000:00:1a.1: enabling bus mastering
[    9.230423] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[    9.230427] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[    9.230433] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[    9.230465] uhci_hcd 0000:00:1a.1: irq 19, io base 0x000030c0
[    9.230537] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    9.230541] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.230545] usb usb4: Product: UHCI Host Controller
[    9.230548] usb usb4: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.230551] usb usb4: SerialNumber: 0000:00:1a.1
[    9.230684] hub 4-0:1.0: USB hub found
[    9.230693] hub 4-0:1.0: 2 ports detected
[    9.230768] xen: registering gsi 19 triggering 0 polarity 1
[    9.230772] Already setup the GSI :19
[    9.230778] uhci_hcd 0000:00:1a.2: enabling bus mastering
[    9.230784] uhci_hcd 0000:00:1a.2: setting latency timer to 64
[    9.230789] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    9.230797] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    9.230828] uhci_hcd 0000:00:1a.2: irq 19, io base 0x000030a0
[    9.230896] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    9.230900] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.230904] usb usb5: Product: UHCI Host Controller
[    9.230907] usb usb5: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.230911] usb usb5: SerialNumber: 0000:00:1a.2
[    9.231047] hub 5-0:1.0: USB hub found
[    9.231056] hub 5-0:1.0: 2 ports detected
[    9.231160] xen: registering gsi 16 triggering 0 polarity 1
[    9.231164] Already setup the GSI :16
[    9.231170] uhci_hcd 0000:00:1d.0: enabling bus mastering
[    9.231177] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[    9.231181] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    9.231187] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[    9.231217] uhci_hcd 0000:00:1d.0: irq 16, io base 0x00003080
[    9.231290] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[    9.231294] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.231297] usb usb6: Product: UHCI Host Controller
[    9.231300] usb usb6: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.231304] usb usb6: SerialNumber: 0000:00:1d.0
[    9.231481] hub 6-0:1.0: USB hub found
[    9.231502] hub 6-0:1.0: 2 ports detected
[    9.231560] xen: registering gsi 16 triggering 0 polarity 1
[    9.231564] Already setup the GSI :16
[    9.231570] uhci_hcd 0000:00:1d.1: enabling bus mastering
[    9.231577] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[    9.231582] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    9.231587] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[    9.231617] uhci_hcd 0000:00:1d.1: irq 16, io base 0x00003060
[    9.231687] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[    9.231691] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.231695] usb usb7: Product: UHCI Host Controller
[    9.231698] usb usb7: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.231701] usb usb7: SerialNumber: 0000:00:1d.1
[    9.231835] hub 7-0:1.0: USB hub found
[    9.231844] hub 7-0:1.0: 2 ports detected
[    9.231924] xen: registering gsi 16 triggering 0 polarity 1
[    9.231928] Already setup the GSI :16
[    9.231934] uhci_hcd 0000:00:1d.2: enabling bus mastering
[    9.231940] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[    9.231945] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    9.231950] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[    9.231980] uhci_hcd 0000:00:1d.2: irq 16, io base 0x00003040
[    9.232050] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[    9.232054] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.232057] usb usb8: Product: UHCI Host Controller
[    9.232060] usb usb8: Manufacturer: Linux 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 uhci_hcd
[    9.232064] usb usb8: SerialNumber: 0000:00:1d.2
[    9.232202] hub 8-0:1.0: USB hub found
[    9.232211] hub 8-0:1.0: 2 ports detected
[    9.232324] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    9.985548] ata3: failed to resume link (SControl 0)
[    9.985560] ata3: SATA link down (SStatus 0 SControl 0)
[    9.985570] ata2: failed to resume link (SControl 0)
[    9.985582] ata2: SATA link down (SStatus 0 SControl 0)
[    9.989511] ata4: failed to resume link (SControl 0)
[    9.989522] ata4: SATA link down (SStatus 0 SControl 0)
[    9.989535] ata6: failed to resume link (SControl 0)
[    9.989547] ata6: SATA link down (SStatus 0 SControl 0)
[    9.989556] ata1: failed to resume link (SControl 0)
[    9.989568] ata1: SATA link down (SStatus 0 SControl 0)
[   10.277949] i8042: No controller found
[   10.278119] mousedev: PS/2 mouse device common for all mice
[   10.278762] input: PC Speaker as /devices/platform/pcspkr/input/input2
[   10.278912] rtc_cmos 00:03: RTC can wake from S4
[   10.279104] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[   10.279194] rtc0: alarms up to one month, y3k, 114 bytes nvram
[   10.279234] device-mapper: uevent: version 1.0.3
[   10.279332] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
[   10.279644] usbcore: registered new interface driver usbhid
[   10.279647] usbhid: USB HID core driver
[   10.279725] TCP: cubic registered
[   10.279728] NET: Registered protocol family 17
[   10.279747] Key type dns_resolver registered
[   10.280161] registered taskstats version 1
[   10.281423] rtc_cmos 00:03: setting system clock to 2013-02-04 09:28:23 UTC (1359970103)
[   10.281433] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[   10.281437] EDD information not available.
[   10.365566] ata5: failed to resume link (SControl 0)
[   10.365583] ata5: SATA link down (SStatus 0 SControl 0)
[   10.366099] Freeing unused kernel memory: 636k freed
[   10.366228] Write protecting the kernel read-only data: 12288k
[   10.369824] Freeing unused kernel memory: 1640k freed
[   10.370670] Freeing unused kernel memory: 1780k freed
[   10.450801] Fusion MPT base driver 3.04.20
[   10.450806] Copyright (c) 1999-2008 LSI Corporation
[   10.451327] Fusion MPT SAS Host driver 3.04.20
[   10.451362] xen: registering gsi 16 triggering 0 polarity 1
[   10.451367] Already setup the GSI :16
[   10.451638] mptbase: ioc0: Initiating bringup
[   10.605551] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[   10.739714] usb 2-1: New USB device found, idVendor=05e3, idProduct=0719
[   10.739724] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[   10.739732] usb 2-1: Product: USB Storage
[   10.739737] usb 2-1: SerialNumber: 000000000033
[   10.977529] usb 5-1: new full-speed USB device number 2 using uhci_hcd
[   11.017542] ioc0: LSISAS1078 C2: Capabilities={Initiator}
[   11.135930] usb 5-1: New USB device found, idVendor=046b, idProduct=ff10
[   11.135940] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   11.135947] usb 5-1: Product: Virtual Keyboard and Mouse
[   11.135953] usb 5-1: Manufacturer: American Megatrends Inc.
[   11.135958] usb 5-1: SerialNumber: serial
[   11.145157] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/input/input3
[   11.145425] hid-generic 0003:046B:FF10.0001: input,hidraw0: USB HID v1.10 Keyboard [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input0
[   11.151093] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.1/input/input4
[   11.151360] hid-generic 0003:046B:FF10.0002: input,hidraw1: USB HID v1.10 Mouse [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input1
[   23.819242] scsi6 : ioc0: LSISAS1078 C2, FwRev=011b0000h, Ports=1, MaxQ=276, IRQ=16
[   23.823655] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221000000000000
[   23.827124] scsi 6:0:0:0: Direct-Access     ATA      ST9500530NS      SN04 PQ: 0 ANSI: 5
[   23.827774] sd 6:0:0:0: Attached scsi generic sg0 type 0
[   23.828186] sd 6:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[   23.882101] sd 6:0:0:0: [sda] Write Protect is off
[   23.882110] sd 6:0:0:0: [sda] Mode Sense: 73 00 00 08
[   23.884318] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   23.993837]  sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
[   24.050901] sd 6:0:0:0: [sda] Attached SCSI disk
[   24.073501] Initialising Xen virtual ethernet driver.
[   24.089738] udev: starting version 147
[   25.225175] kjournald starting.  Commit interval 5 seconds
[   25.225985] EXT3-fs (sda6): using internal journal
[   25.225996] EXT3-fs (sda6): mounted filesystem with ordered data mode
[   27.430759] udev: starting version 147
[   27.533221] tpm_tis 00:09: 1.2 TPM (device-id 0x0, rev-id 78)
[   27.541200] xen: registering gsi 18 triggering 0 polarity 1
[   27.541208] Already setup the GSI :18
[   27.541292] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[   27.589606] tpm_tis 00:09: TPM is disabled/deactivated (0x6)
[   27.676939] Initializing USB Mass Storage driver...
[   27.677509] scsi7 : usb-storage 2-1:1.0
[   27.677593] usbcore: registered new interface driver usb-storage
[   27.677597] USB Mass Storage support registered.
[   27.689507] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0xc
[   27.689515] i7core_edac: Unknown symbol edac_mc_del_mc (err 0)
[   27.689528] i7core_edac: Unknown symbol edac_mc_add_mc (err 0)
[   27.689536] i7core_edac: Unknown symbol edac_pci_create_generic_ctl (err 0)
[   27.689540] i7core_edac: Unknown symbol edac_mc_alloc (err 0)
[   27.689546] i7core_edac: Unknown symbol edac_mc_free (err 0)
[   27.689552] i7core_edac: Unknown symbol edac_mc_handle_error (err 0)
[   27.689565] i7core_edac: Unknown symbol edac_pci_release_generic_ctl (err 0)
[   27.762633] microcode: CPU1 sig=0x206c2, pf=0x1, revision=0xc
[   27.771813] microcode: CPU2 sig=0x206c2, pf=0x1, revision=0xc
[   27.781360] microcode: CPU3 sig=0x206c2, pf=0x1, revision=0xc
[   27.790101] microcode: CPU4 sig=0x206c2, pf=0x1, revision=0xc
[   27.791214] NET: Registered protocol family 10
[   27.799375] microcode: CPU5 sig=0x206c2, pf=0x1, revision=0xc
[   27.809037] microcode: CPU6 sig=0x206c2, pf=0x1, revision=0xc
[   27.818861] microcode: CPU7 sig=0x206c2, pf=0x1, revision=0xc
[   27.828158] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   28.679744] scsi 7:0:0:0: CD-ROM            TEAC     DV-W28S-V        1.0A PQ: 0 ANSI: 0
[   28.684959] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[   28.684969] cdrom: Uniform CD-ROM driver Revision: 3.20
[   28.685236] sr 7:0:0:0: Attached scsi CD-ROM sr0
[   28.685401] sr 7:0:0:0: Attached scsi generic sg1 type 5
[   28.824831] Adding 2096476k swap on /dev/sda2.  Priority:-1 extents:1 across:2096476k 
[   30.833821] loop: module loaded
[   30.971071] kjournald starting.  Commit interval 5 seconds
[   30.971670] EXT3-fs (sda5): mounted filesystem with ordered data mode
[   40.070007] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   40.070260] igb: eth0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
[   40.070331] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   42.489429] Bridge firewalling registered
[   42.502752] device eth0 entered promiscuous mode
[   42.509612] br0: port 1(eth0) entered forwarding state
[   42.509617] br0: port 1(eth0) entered forwarding state
[   48.476283] irqbalance[3575]: segfault at 4 ip 00007ff5b07d18ed sp 00007fff7fe80d50 error 6 in libc-2.11.3.so[7ff5b072e000+16d000]
[   48.639756] mcelog:3587 map pfn expected mapping type write-back for [mem 0x8f302000-0x8f302fff], got uncached-minus
[   48.639777] ------------[ cut here ]------------
[   48.639783] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x94/0xc0()
[   48.639784] Hardware name: S5520UR
[   48.639785] Modules linked in: bridge stp llc loop crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul ipv6 microcode usb_storage i2c_i801 joydev tpm_tis tpm tpm_bios xen_blkfront xen_netfront mptsas mptscsih mptbase scsi_transport_sas
[   48.639800] Pid: 3587, comm: mcelog Not tainted 3.7.6-10.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 #1
[   48.639801] Call Trace:
[   48.639804]  [<ffffffff8103d1d4>] ? untrack_pfn+0x94/0xc0
[   48.639809]  [<ffffffff81043f0a>] warn_slowpath_common+0x7a/0xb0
[   48.639811]  [<ffffffff81043f55>] warn_slowpath_null+0x15/0x20
[   48.639812]  [<ffffffff8103d1d4>] untrack_pfn+0x94/0xc0
[   48.639817]  [<ffffffff810d2cdb>] unmap_single_vma+0x77b/0x7f0
[   48.639819]  [<ffffffff810d2daa>] unmap_vmas+0x5a/0x90
[   48.639821]  [<ffffffff810d5037>] exit_mmap+0x87/0x150
[   48.639823]  [<ffffffff81041cbd>] mmput+0x2d/0xd0
[   48.639825]  [<ffffffff810420cb>] dup_mm+0x36b/0x460
[   48.639827]  [<ffffffff81042af8>] copy_process+0x828/0x1120
[   48.639829]  [<ffffffff81043542>] do_fork+0x62/0x340
[   48.639834]  [<ffffffff8158a4c1>] ? sys_connect+0x71/0xa0
[   48.639836]  [<ffffffff81108090>] ? set_close_on_exec+0x40/0x80
[   48.639841]  [<ffffffff81014ad3>] sys_clone+0x23/0x30
[   48.639844]  [<ffffffff8165faf3>] stub_clone+0x13/0x20
[   48.639846]  [<ffffffff8165f869>] ? system_call_fastpath+0x16/0x1b
[   48.639847] ---[ end trace 32d9c32b0defe75a ]---
[   50.101769] Event-channel device installed.
[   50.174766] xen-pciback: backend is vpci

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="screenlog.0.txt"


kernel /boot/vmlinuz-kernel-linux-3_7 root=bax.arch.suse.de:/olaf_xenimages/bug
694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M ignore_loglevel debug
   [Linux-bzImage, setup=0x3c00, size=0x48ea10]
initrd /boot/initrd-kernel-linux-3_7
   [Linux-initrd @ 0x1f3a3000, 0x44c8b0 bytes]

[    0.000000] Linux version 3.7.5-9.home_olh_kernel_sles11sp1.1-kernel-linux-3_7 (abuild@build21) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Mon Jan 28 07:49:06 UTC 2013
[    0.000000] Command line: root=bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M ignore_loglevel debug
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f7fffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.3.26502-20130204 02/04/2013
[    0.000000] Xen version 4.3.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] HVMOP_pagetable_dying not supported
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x1f800 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 00F0000000 mask FFF8000000 uncachable
[    0.000000]   1 base 00F8000000 mask FFFC000000 uncachable
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at [ffff8800000fbba0]
[    0.000000] initial memory mapped: [mem 0x00000000-0x1fffffff]
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 28672
[    0.000000] init_memory_mapping: [mem 0x00000000-0x1f7fffff]
[    0.000000]  [mem 0x00000000-0x1f7fffff] page 2M
[    0.000000] kernel direct mapping tables up to 0x1f7fffff @ [mem 0x1f7fe000-0x1f7fffff]
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 2094252(99%)
[    0.000000] RAMDISK: [mem 0x1f3a3000-0x1f7effff]
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc00f5c0 00054 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00f280 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc003600 0BBF6 (v02    Xen      HVM 00000000 INTL 20081031)
[    0.000000] ACPI: FACS 00000000fc0035c0 00040
[    0.000000] ACPI: APIC 00000000fc00f380 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc00f4d0 00038 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc00f510 00028 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc00f540 00031 (v02    Xen      HVM 00000000 INTL 20081031)
[    0.000000] ACPI: SSDT 00000000fc00f580 00031 (v02    Xen      HVM 00000000 INTL 20081031)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000]  [ffffea0000000000-ffffea00007fffff] PMD -> [ffff88001a200000-ffff88001a9fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0x1f7fffff]
[    0.000000] On node 0 totalpages: 128910
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 7 pages reserved
[    0.000000]   DMA zone: 3911 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 1952 pages used for memmap
[    0.000000]   DMA32 zone: 122976 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: 15 Processors exceeds NR_CPUS limit of 8
[    0.000000] smpboot: Allowing 8 CPUs, 6 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] e820: [mem 0x1f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88001b000000 s78080 r8192 d24320 u262144
[    0.000000] pcpu-alloc: s78080 r8192 d24320 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 126887
[    0.000000] Kernel command line: root=bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M ignore_loglevel debug
[    0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 420008k/516096k available (6541k kernel code, 456k absent, 95632k reserved, 6150k data, 636k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:4352 nr_irqs:1152 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Detected 2926.444 MHz processor
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5852.88 BogoMIPS (lpj=11705776)
[    0.012002] pid_max: default: 32768 minimum: 301
[    0.014412] Mount-cache hash table entries: 256
[    0.016196] CPU: Physical Processor ID: 0
[    0.020003] CPU: Processor Core ID: 0
[    0.021984] mce: CPU supports 2 MCE banks
[    0.024025] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    0.024025] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    0.024025] tlb_flushall_shift: 6
[    0.028246] Freeing SMP alternatives: 28k freed
[    0.036405] ACPI: Core revision 20120913
[    0.044382] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.088011] smpboot: CPU0: Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz (fam: 06, model: 2c, stepping: 02)
[    0.097544] Xen: using vcpuop timer interface
[    0.100007] installing Xen timer for CPU 0
[    0.104081] Performance Events: 16-deep LBR, Westmere events, Intel PMU driver.
[    0.108008] perf_event_intel: CPUID marked event: 'bus cycles' unavailable
[    0.112011] ... version:                3
[    0.114519] ... bit width:              48
[    0.116005] ... generic registers:      4
[    0.118496] ... value mask:             0000ffffffffffff
[    0.120005] ... max period:             000000007fffffff
[    0.123427] ... fixed-purpose events:   3
[    0.124004] ... event mask:             000000070000000f
[    0.127674] register_vcpu_info failed: err=-22
[    0.128021] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
[    0.144053] Brought up 2 CPUs
[    0.144054] smpboot: Total of 2 processors activated (11705.77 BogoMIPS)

[    0.154834] devtmpfs: initialized
[    0.156169] NET: Registered protocol family 16
[    0.160133] ACPI: bus type pci registered
[    0.164270] PCI: Using configuration type 1 for base access
[    0.168912] bio: create slab <bio-0> at 0
[    0.170892] ACPI: Added _OSI(Module Device)
[    0.172016] ACPI: Added _OSI(Processor Device)
[    0.175442] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.176012] ACPI: Added _OSI(Processor Aggregator Device)
[    0.182021] ACPI: EC: Look up EC in DSDT
[    0.189510] ACPI: Interpreter enabled
[    0.192012] ACPI: (supports S0 S3 S4 S5)
[    0.195294] ACPI: Using IOAPIC for interrupt routing
[    0.249933] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.252089] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.256121] pci_root PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    0.260041] PCI host bridge to bus 0000:00
[    0.263031] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.264011] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.268010] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.272010] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.276010] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    0.280010] pci_bus 0000:00: scanning bus
[    0.283178] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    0.284015] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0xa
[    0.289865] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    0.294911] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    0.297940] pci 0000:00:01.1: reg 20: [io  0xc100-0xc10f]
[    0.301283] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[    0.304063] pci 0000:00:01.3: calling acpi_pm_check_blacklist+0x0/0x3b
[    0.308009] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
[    0.308009] * this clock source is slow. Consider trying other clock sources
[    0.314390] pci 0000:00:01.3: calling quirk_piix4_acpi+0x0/0x177
[    0.316059] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    0.320329] pci 0000:00:01.3: calling pci_fixup_piix4_acpi+0x0/0x10
[    0.324647] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[    0.328419] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.332353] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff]
[    0.338132] pci 0000:00:03.0: [5853:0001] type 00 class 0xff8000
[    0.340472] pci 0000:00:03.0: reg 10: [io  0xc000-0xc0ff]
[    0.344377] pci 0000:00:03.0: reg 14: [mem 0xf2000000-0xf2ffffff pref]
[    0.351212] pci_bus 0000:00: fixups for bus
[    0.352011] pci_bus 0000:00: bus scan returning with max=00
[    0.356010] pci_bus 0000:00: on NUMA node 0
[    0.359023] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.360469]  pci0000:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[    0.364010]  pci0000:00: Unable to request _OSC control (_OSC support mask: 0x08)
[    0.567295] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    0.569759] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.573643] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.577717] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    0.581589] xen/balloon: Initialising balloon driver.
[    0.584055] xen-balloon: Initialising balloon driver.
[    0.588099] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.592010] vgaarb: loaded
[    0.594043] vgaarb: bridge control possible 0000:00:02.0
[    0.596075] SCSI subsystem initialized
[    0.598940] ACPI: bus type scsi registered
[    0.600052] libata version 3.00 loaded.
[    0.603067] ACPI: bus type usb registered
[    0.604033] usbcore: registered new interface driver usbfs
[    0.608021] usbcore: registered new interface driver hub
[    0.612027] usbcore: registered new device driver usb
[    0.615809] PCI: Using ACPI for IRQ routing
[    0.616009] PCI: pci_cache_line_size set to 64 bytes
[    0.619915] pci 0000:00:01.1: BAR 0: reserving [io  0x01f0-0x01f7 flags 0x110] (d=0, p=0)
[    0.620011] pci 0000:00:01.1: BAR 1: reserving [io  0x03f6 flags 0x110] (d=0, p=0)
[    0.624011] pci 0000:00:01.1: BAR 2: reserving [io  0x0170-0x0177 flags 0x110] (d=0, p=0)
[    0.628011] pci 0000:00:01.1: BAR 3: reserving [io  0x0376 flags 0x110] (d=0, p=0)
[    0.632012] pci 0000:00:01.1: BAR 4: reserving [io  0xc100-0xc10f flags 0x40101] (d=0, p=0)
[    0.636112] pci 0000:00:02.0: BAR 0: reserving [mem 0xf0000000-0xf1ffffff flags 0x42208] (d=0, p=0)
[    0.640010] pci 0000:00:02.0: BAR 1: reserving [mem 0xf3000000-0xf3000fff flags 0x40200] (d=0, p=0)
[    0.644069] pci 0000:00:03.0: BAR 0: reserving [io  0xc000-0xc0ff flags 0x40101] (d=0, p=0)
[    0.648011] pci 0000:00:03.0: BAR 1: reserving [mem 0xf2000000-0xf2ffffff flags 0x42208] (d=0, p=0)
[    0.652292] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[    0.656010] e820: reserve RAM buffer [mem 0x1f800000-0x1fffffff]
[    0.660157] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    0.664036] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.668000] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.671132] Switching to clocksource xen
[    0.672072] pnp: PnP ACPI init
[    0.674017] ACPI: bus type pnp registered
[    0.676000] pnp 00:00: [mem 0x00000000-0x0009ffff]
[    0.676000] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.683863] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.688359] pnp 00:01: [bus 00-ff]
[    0.690518] pnp 00:01: [io  0x0cf8-0x0cff]
[    0.693072] pnp 00:01: [io  0x0000-0x0cf7 window]
[    0.695954] pnp 00:01: [io  0x0d00-0xffff window]
[    0.698918] pnp 00:01: [mem 0x000a0000-0x000bffff window]
[    0.702290] pnp 00:01: [mem 0xf0000000-0xfbffffff window]
[    0.705672] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.709770] pnp 00:02: [mem 0xfed00000-0xfed003ff]
[    0.712672] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.716786] pnp 00:03: [io  0x0010-0x001f]
[    0.719274] pnp 00:03: [io  0x0022-0x002d]
[    0.721849] pnp 00:03: [io  0x0030-0x003f]
[    0.724404] pnp 00:03: [io  0x0044-0x005f]
[    0.726922] pnp 00:03: [io  0x0062-0x0063]
[    0.729497] pnp 00:03: [io  0x0065-0x006f]
[    0.731978] pnp 00:03: [io  0x0072-0x007f]
[    0.734612] pnp 00:03: [io  0x0080]
[    0.736808] pnp 00:03: [io  0x0084-0x0086]
[    0.739319] pnp 00:03: [io  0x0088]
[    0.741566] pnp 00:03: [io  0x008c-0x008e]
[    0.744145] pnp 00:03: [io  0x0090-0x009f]
[    0.746686] pnp 00:03: [io  0x00a2-0x00bd]
[    0.749253] pnp 00:03: [io  0x00e0-0x00ef]
[    0.751774] pnp 00:03: [io  0x08a0-0x08a3]
[    0.754355] pnp 00:03: [io  0x0cc0-0x0ccf]
[    0.756887] pnp 00:03: [io  0x04d0-0x04d1]
[    0.759493] system 00:03: [io  0x08a0-0x08a3] has been reserved
[    0.763228] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
[    0.766904] system 00:03: [io  0x04d0-0x04d1] has been reserved
[    0.770558] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.774805] pnp 00:04: [dma 4]
[    0.776778] pnp 00:04: [io  0x0000-0x000f]
[    0.779329] pnp 00:04: [io  0x0081-0x0083]
[    0.781899] pnp 00:04: [io  0x0087]
[    0.784118] pnp 00:04: [io  0x0089-0x008b]
[    0.786645] pnp 00:04: [io  0x008f]
[    0.788826] pnp 00:04: [io  0x00c0-0x00df]
[    0.791344] pnp 00:04: [io  0x0480-0x048f]
[    0.793925] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.798000] pnp 00:05: [io  0x0070-0x0071]
[    0.800522] xen: --> pirq=16 -> irq=8 (gsi=8)
[    0.803328] pnp 00:05: [irq 8]
[    0.805247] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.809211] pnp 00:06: [io  0x0061]
[    0.811359] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.815448] xen: --> pirq=17 -> irq=12 (gsi=12)
[    0.818295] pnp 00:07: [irq 12]
[    0.820313] pnp 00:07: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.824391] pnp 00:08: [io  0x0060]
[    0.826562] pnp 00:08: [io  0x0064]
[    0.828827] xen: --> pirq=18 -> irq=1 (gsi=1)
[    0.831460] pnp 00:08: [irq 1]
[    0.833383] pnp 00:08: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    0.837901] pnp 00:09: [io  0x03f0-0x03f5]
[    0.840445] pnp 00:09: [io  0x03f7]
[    0.842679] xen: --> pirq=19 -> irq=6 (gsi=6)
[    0.845446] pnp 00:09: [irq 6]
[    0.847320] pnp 00:09: [dma 2]
[    0.849307] pnp 00:09: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.853345] pnp 00:0a: [io  0x03f8-0x03ff]
[    0.855925] xen: --> pirq=20 -> irq=4 (gsi=4)
[    0.858704] pnp 00:0a: [irq 4]
[    0.860661] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.864752] pnp 00:0b: [io  0x0378-0x037f]
[    0.867304] xen: --> pirq=21 -> irq=7 (gsi=7)
[    0.870066] pnp 00:0b: [irq 7]
[    0.871934] pnp 00:0b: Plug and Play ACPI device, IDs PNP0400 (active)
[    0.876092] pnp 00:0c: [io  0x10c0-0x1141]
[    0.878636] pnp 00:0c: [io  0xb044-0xb047]
[    0.881200] system 00:0c: [io  0x10c0-0x1141] has been reserved
[    0.884899] system 00:0c: [io  0xb044-0xb047] has been reserved
[    0.888633] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.910161] pnp: PnP ACPI: found 13 devices
[    0.912735] ACPI: ACPI bus type pnp unregistered
[    0.920985] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.924522] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.928424] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.932368] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff]
[    0.936329] NET: Registered protocol family 2
[    0.939109] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.943720] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.948055] TCP: Hash tables configured (established 16384 bind 16384)
[    0.952007] TCP: reno registered
[    0.954122] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.957814] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.961781] NET: Registered protocol family 1
[    0.964644] RPC: Registered named UNIX socket transport module.
[    0.968303] RPC: Registered udp transport module.
[    0.971229] RPC: Registered tcp transport module.
[    0.974127] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.978124] pci 0000:00:00.0: calling quirk_natoma+0x0/0x2d
[    0.981627] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.985304] pci 0000:00:00.0: calling quirk_passive_release+0x0/0xa0
[    0.989263] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.992866] pci 0000:00:01.0: calling quirk_isa_dma_hangs+0x0/0x31
[    0.996657] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    1.000546] pci 0000:00:02.0: calling pci_fixup_video+0x0/0xc1
[    1.004286] pci 0000:00:02.0: Boot video device
[    1.007121] PCI: CLS 0 bytes, default 64
[    1.009631] Unpacking initramfs...
[    1.081590] Freeing initrd memory: 4404k freed
[    1.087058] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.091075] NFS: Registering the id_resolver key type
[    1.094234] Key type id_resolver registered
[    1.096921] Key type id_legacy registered
[    1.099456] NTFS driver 2.1.30 [Flags: R/O].
[    1.102302] fuse init (API version 7.20)
[    1.104824] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[    1.111244] Btrfs loaded
[    1.112829] msgmni has been set to 828
[    1.115526] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    1.120213] io scheduler noop registered
[    1.122645] io scheduler deadline registered
[    1.125307] io scheduler cfq registered (default)
[    1.128389] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    1.132877] ACPI: Power Button [PWRF]
[    1.135250] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    1.139847] ACPI: Sleep Button [SLPF]
[    1.179759] xen: --> pirq=22 -> irq=28 (gsi=28)
[    1.182740] Grant tables using version 1 layout.
[    1.185653] Grant table initialized
[    1.188183] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.219464] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.223520] Non-volatile memory driver v1.3
[    1.226155] Linux agpgart interface v0.103
[    1.228839] ata_piix 0000:00:01.1: version 2.13
[    1.231775] ata_piix 0000:00:01.1: setting latency timer to 64
[    1.235970] scsi0 : ata_piix
[    1.238022] scsi1 : ata_piix
[    1.239873] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc100 irq 14
[    1.244109] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc108 irq 15
[    1.248384] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
[    1.252594] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    1.256321] igb: Intel(R) Gigabit Ethernet Network Driver - version 4.0.1-k
[    1.260623] igb: Copyright (c) 2007-2012 Intel Corporation.
[    1.264079] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.1-k
[    1.268920] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    1.272532] sky2: driver version 1.30
[    1.274967] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.279127] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.283088] uhci_hcd: USB Universal Host Controller Interface driver
[    1.287132] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.295065] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.299017] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.302951] mousedev: PS/2 mouse device common for all mice
[    1.308186] input: PC Speaker as /devices/platform/pcspkr/input/input2
[    1.308324] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    1.322418] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    1.326271] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs
[    1.330205] device-mapper: uevent: version 1.0.3
[    1.333094] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
[    1.338340] cpuidle: using governor ladder
[    1.340929] cpuidle: using governor menu
[    1.343484] usbcore: registered new interface driver usbhid
[    1.346956] usbhid: USB HID core driver
[    1.349499] TCP: cubic registered
[    1.351492] NET: Registered protocol family 17
[    1.354387] Key type dns_resolver registered
[    1.357631] registered taskstats version 1
[    1.360352] XENBUS: Device with no driver: device/vbd/768
[    1.363781] XENBUS: Device with no driver: device/vkbd/0
[    1.367140] XENBUS: Device with no driver: device/vif/0
[    1.370651] rtc_cmos 00:05: setting system clock to 2013-02-04 09:33:40 UTC (1359970420)
[    1.375665] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[    1.407269] Freeing unused kernel memory: 636k freed
[    1.412902] Write protecting the kernel read-only data: 12288k
[    1.426157] Freeing unused kernel memory: 1640k freed
[    1.439757] Freeing unused kernel memory: 1780k freed
doing fast boot
[    1.498809] blkfront: xvda: barrier: enabled
[    1.506405]  xvda: xvda1 xvda2
[    1.525946] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4
FATAL: Module ata_piix not found.
FATAL: Error running install command for ata_piix
FATAL: Module ata_generic not found.
[    1.624458] Initialising Xen virtual ethernet driver.
preping 03-storage.sh
running 03-storage.sh
preping 04-udev.sh
running 04-udev.sh
Creating device nodes with udev
[    1.748426] udev: starting version 147
[    2.084182] tsc: Refined TSC clocksource calibration: 2926.327 MHz
preping 05-blogd.sh
running 05-blogd.sh
mount: devpts already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts
Boot logging started on /dev/ttyS0(/dev/console) at Mon Feb  4 10:33:41 2013
preping 05-clock.sh
running 05-clock.sh
preping 12-network.sh
running 12-network.sh
FATAL: Module af_packet not found.
running dhcpcd on interface eth0
err, eth0: Failed to lookup hostname via DNS: Temporary failure in name resolution
preping 21-devinit_done.sh
running 21-devinit_done.sh
preping 21-nfs.sh
running 21-nfs.sh
FATAL: Module nfs not found.
preping 81-mount.sh
running 81-mount.sh
device node not found
Mounting root bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot
mount -o rw,nolock -t nfs bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot /root
preping 82-remount.sh
running 82-remount.sh
preping 91-createfb.sh
running 91-createfb.sh
preping 91-killblogd.sh
running 91-killblogd.sh
preping 91-killudev.sh
running 91-killudev.sh
preping 91-shell.sh
running 91-shell.sh
preping 92-killblogd2.sh
running 92-killblogd2.sh
preping 93-boot.sh
running 93-boot.sh
INIT: version 2.86 booting
System Boot Control: Running /etc/init.d/boot

--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 Mon Feb 04 09:58:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09:58: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 1U2Iod-0008OL-NE; Mon, 04 Feb 2013 09:58:19 +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 1U2Ioc-0008OF-Cu
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:58:18 +0000
Received: from [85.158.139.211:51931] by server-15.bemta-5.messagelabs.com id
	C4/70-18914-9368F015; Mon, 04 Feb 2013 09:58:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1359971893!20938962!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27498 invoked from network); 4 Feb 2013 09:58:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 09:58:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo22) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R02b1dp148wV9R ;
	Mon, 4 Feb 2013 10:57:10 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 20BF21884C; Mon,  4 Feb 2013 10:57:10 +0100 (CET)
Date: Mon, 4 Feb 2013 10:57:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204095709.GB2564@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359556230.12252.235.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
	cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 30, Ian Campbell wrote:

> On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > A variant of this change has been tested with xend, the patch below is
> > only compile tested. The changes to libxl change the API, is that
> > approach acceptable?
> 
> I'm afraid not, the compatibility requirements are covered in the
> comment near the top of libxl.h.
> 
> So you either need a new function or to leverage the LIBXL_API_VERSION
> define (which the user must supply) such that people providing 0x040200
> see the current interface and people providing 0x040300 (or nothing) see
> the new one.

And to avoid the API change at all, should max_iters and max_factor be
passed via xenstore to xc_domain_save()? So that either the caller of
xc_domain_save reads the values from xenstore, or the function itself
reads it from there. What do you think?


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 09:58:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 09:58: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 1U2Iod-0008OL-NE; Mon, 04 Feb 2013 09:58:19 +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 1U2Ioc-0008OF-Cu
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 09:58:18 +0000
Received: from [85.158.139.211:51931] by server-15.bemta-5.messagelabs.com id
	C4/70-18914-9368F015; Mon, 04 Feb 2013 09:58:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1359971893!20938962!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27498 invoked from network); 4 Feb 2013 09:58:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 09:58:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo22) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R02b1dp148wV9R ;
	Mon, 4 Feb 2013 10:57:10 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 20BF21884C; Mon,  4 Feb 2013 10:57:10 +0100 (CET)
Date: Mon, 4 Feb 2013 10:57:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204095709.GB2564@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359556230.12252.235.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
	cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 30, Ian Campbell wrote:

> On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > A variant of this change has been tested with xend, the patch below is
> > only compile tested. The changes to libxl change the API, is that
> > approach acceptable?
> 
> I'm afraid not, the compatibility requirements are covered in the
> comment near the top of libxl.h.
> 
> So you either need a new function or to leverage the LIBXL_API_VERSION
> define (which the user must supply) such that people providing 0x040200
> see the current interface and people providing 0x040300 (or nothing) see
> the new one.

And to avoid the API change at all, should max_iters and max_factor be
passed via xenstore to xc_domain_save()? So that either the caller of
xc_domain_save reads the values from xenstore, or the function itself
reads it from there. What do you think?


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:05:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:05: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 1U2IvC-0000Rs-6N; Mon, 04 Feb 2013 10:05:06 +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 1U2IvB-0000Rj-03
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:05:05 +0000
Received: from [85.158.143.35:34302] by server-2.bemta-4.messagelabs.com id
	82/38-01597-0D78F015; Mon, 04 Feb 2013 10:05:04 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1359971525!13996354!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28879 invoked from network); 4 Feb 2013 09:52:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 09:52:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 09:52:03 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Mon, 4 Feb 2013
	09:52:03 +0000
Message-ID: <510F84C2.9090505@citrix.com>
Date: Mon, 4 Feb 2013 10:52:02 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Joe Jin <joe.jin@oracle.com>
References: <510F14CF.6050801@oracle.com>
In-Reply-To: <510F14CF.6050801@oracle.com>
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 04/02/13 02:54, Joe Jin wrote:
> Current Xend allowing multiple call destroy() for same domain, this lead
> multiple hard resets(FLR) for pci pass-through, and some controller might
> failed.
> 
> In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, after
> guest brought up, call xm-destroy twice, the adapters's BIOS will hung, and
> we had to reboot the server to recovery it.

Does the same problem happen with libxl/xl?

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:05:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:05: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 1U2IvC-0000Rs-6N; Mon, 04 Feb 2013 10:05:06 +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 1U2IvB-0000Rj-03
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:05:05 +0000
Received: from [85.158.143.35:34302] by server-2.bemta-4.messagelabs.com id
	82/38-01597-0D78F015; Mon, 04 Feb 2013 10:05:04 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1359971525!13996354!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28879 invoked from network); 4 Feb 2013 09:52:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 09:52:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 09:52:03 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Mon, 4 Feb 2013
	09:52:03 +0000
Message-ID: <510F84C2.9090505@citrix.com>
Date: Mon, 4 Feb 2013 10:52:02 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Joe Jin <joe.jin@oracle.com>
References: <510F14CF.6050801@oracle.com>
In-Reply-To: <510F14CF.6050801@oracle.com>
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 04/02/13 02:54, Joe Jin wrote:
> Current Xend allowing multiple call destroy() for same domain, this lead
> multiple hard resets(FLR) for pci pass-through, and some controller might
> failed.
> 
> In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, after
> guest brought up, call xm-destroy twice, the adapters's BIOS will hung, and
> we had to reboot the server to recovery it.

Does the same problem happen with libxl/xl?

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:07:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2IxZ-0000bc-O6; Mon, 04 Feb 2013 10:07:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U2IxW-0000bL-AZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:07:32 +0000
Received: from [85.158.139.211:54666] by server-5.bemta-5.messagelabs.com id
	F3/4A-11945-1688F015; Mon, 04 Feb 2013 10:07:29 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1359972444!17002651!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32511 invoked from network); 4 Feb 2013 10:07:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:07:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:07: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.297.1; Mon, 4 Feb 2013 10:07:24 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U2IxQ-0007Ee-1r; Mon, 04 Feb 2013
	10:07:24 +0000
Message-ID: <510F885B.2040603@citrix.com>
Date: Mon, 4 Feb 2013 11:07:23 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
In-Reply-To: <510F91CA02000078000BB6AA@nat28.tlf.novell.com>
Cc: Milan opath <milan.opath@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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


>> fix-suspend-scheduler-v2
>> fix-suspend-scheduler-revert-affinity-part
>> s3-timerirq
>>
>> All of these fixes have been proposed to the xen-devel list, but have
>> not yet been accepted, for one reason, or another.
>>      
> And I don't think comments on them have seen follow-ups.
>
> Jan
>
>    
I guess it's worth bringing this up again;

s3-timerirq: this was empirical hack which for some reason is needed on 
stable 4.2 we use, but not on latest unstable, didn't really investigate 
further since it appeared fixed later on anyway..

fix-suspend-scheduler/revert-affinity: the big objection here was the 
part which reverts one of the hunks in Keir's commit. I tried for quite 
few days to find a working fix which does not do this revert using 
posted suggestions, but was not succesfull:

- there was a crash in xen scheduler, which was fixable using your 
suggestion of masking softirqs during s3 (ugly)
- there was also a crash in xen acpi cpufreq driver, which was 
similarily fixable using a bandaid s3 condition (ugly)
- unfortunately this turned out to not be all, xen did not crash anymore 
at this point but dom0 kernel did around the time it enables cpus, in 
multiple places: at this point I didn't have a good explanation for it, 
my opinion of aggravating hunk was rather low, so I uttered a hearty 
curse and stuck a revert into private patchqueue.

The dom0 kernel crashes were as follows:

1)

[   60.657751] Enabling non-boot CPUs ...
[   60.657958] installing Xen timer for CPU 1
[   60.657987] cpu 1 spinlock event irq 279
[   60.658101] Disabled fast string operations
[   60.658466] CPU1 is up
[   60.658736] installing Xen timer for CPU 2
[   60.658784] cpu 2 spinlock event irq 285
[   60.659764] Disabled fast string operations
[   60.661811] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000018
[   60.661817] IP: [<ffffffff8105f700>] build_sched_domains+0x770/0(XEN) 
*** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0)




2)
.332997] installing Xen timer for CPU 2emory
[   36.333061] cpu 2 spinlock event irq 285
[   36.333343] Disabled fast string operations
[   36.334939] CPU2 is up
[   36.335213] installing Xen timer for CPU 3
[   36.335244] cpu 3 spinlock event irq 291
[   36.335561] Disabled fast string operations
[   36.337461] CPU3 is up
[   36.339513] ACPI: Waking up from system sleep state S3
[   36.350193] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000004
[   36.350211] IP: [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
[   36.350236] PGD 2f19067 PUD 2ec7067 PMD 0
[   36.350252] Oops: 0000 [#1] SMP
[   36.350263] CPU 1
[   36.350267] Modules linked in: xt_mac ipt_MASQUERADE ebtable_filter 
ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O) xt_state crc32c 
xt_multiport libcrc32c iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4 ip_tables 
scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C) 
snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse 
serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O) 
thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm 
snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video 
intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
[   36.350437]
[   36.350445] Pid: 2730, comm: bash Tainted: G         C O 3.2.23-orc 
#19 LENOVO 42404EU/42404EU
[   36.350463] RIP: e030:[<ffffffff81055f9a>]  [<ffffffff81055f9a>] 
find_busiest_group+0x38a/0xbb0
[   36.350481] RSP: e02b:ffff880002b71228  EFLAGS: 00010046
[   36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX: 
0000000000000000
[   36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI: 
0000000000000000
[   36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09: 
0000000000000000
[   36.350519] R10: 0000000000000000 R11: 0000000000000001 R12: 
0000000000000000
[   36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15: 
ffff880026109f98
[   36.350547] FS:  00007fc41e295700(0000) GS:ffff88002dc40000(0000) 
knlGS:0000000000000000
[   36.350558] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4: 
0000000000002660
[   36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[   36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[   36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000, 
task ffff880027a7db40)
[   36.350608] Stack:
[   36.350613]  00ffffff00000002 0000000300000001 ffff880002b71498 
ffff880002b71534
[   36.350630]  00ffffff00000002 0000000100000001 ffff8800262cf000 
0000000000000008
[   36.350646]  ffffffff00000000 0000000000000000 0000000000000000 
ffff88002dc4e2c8
[   36.350662] Call Trace:
[   36.350677]  [<ffffffff8105b158>] load_balance+0xb8/0x840
[   36.350690]  [<ffffffff8101b909>] ? sched_clock+0x9/0x10
[   36.350706]  [<ffffffff8108ccad>] ? sched_clock_cpu+0xbd/0x110
[   36.350718]  [<ffffffff81052b1c>] ? update_shares+0xcc/0x100
[   36.350735]  [<ffffffff8157b9b5>] __schedule+0x875/0x8d0
[   36.350749]  [<ffffffff81073ae2>] ? try_to_del_timer_sync+0x92/0x130
[   36.350762]  [<ffffffff8157bd3f>] schedule+0x3f/0x60
[   36.350773]  [<ffffffff8157c24d>] schedule_timeout+0x16d/0x320
[   36.350786]  [<ffffffff810728e0>] ? usleep_range+0x50/0x50
[   36.350800]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   36.350817]  [<ffffffff8130c340>] 
acpi_ec_transaction_unlocked+0x134/0x1d8
[   36.350830]  [<ffffffff81086b90>] ? add_wait_queue+0x60/0x60
[   36.350842]  [<ffffffff8130c6c6>] acpi_ec_transaction+0x196/0x239
[   36.350856]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   36.350869]  [<ffffffff8130c8a0>] acpi_ec_write+0x40/0x42
[   36.350881]  [<ffffffff8130c9a8>] acpi_ec_space_handler+0x9e/0xfc
[   36.350894]  [<ffffffff8130c90a>] ? acpi_ec_burst_disable+0x3d/0x3d
[   36.350909]  [<ffffffff813159c6>] 
acpi_ev_address_space_dispatch+0x179/0x1c8
[   36.350924]  [<ffffffff8131aafe>] acpi_ex_access_region+0x23e/0x24b
[   36.350936]  [<ffffffff8106e82c>] ? __sysctl_head_next+0x11c/0x130
[   36.350951]  [<ffffffff8131ae15>] acpi_ex_field_datum_io+0xf9/0x17a
[   36.350965]  [<ffffffff8131b148>] 
acpi_ex_write_with_update_rule+0xb5/0xc1
[   36.350989]  [<ffffffff8131acfa>] acpi_ex_insert_into_field+0x1ef/0x211
[   36.351003]  [<ffffffff8132b5a7>] ? 
acpi_ut_allocate_object_desc_dbg+0x45/0x7f
[   36.351018]  [<ffffffff8131980e>] acpi_ex_write_data_to_field+0x194/0x1c2
[   36.351031]  [<ffffffff813131e4>] ? 
acpi_ds_init_object_from_op+0x137/0x231
[   36.351044]  [<ffffffff8131d94f>] acpi_ex_store_object_to_node+0xa3/0xe2
[   36.351056]  [<ffffffff8131da51>] acpi_ex_store+0xc3/0x256
[   36.351066]  [<ffffffff8131b62b>] acpi_ex_opcode_1A_1T_1R+0x353/0x4a5
[   36.351078]  [<ffffffff8131260c>] acpi_ds_exec_end_op+0xf7/0x3e7
[   36.351092]  [<ffffffff81325ae7>] acpi_ps_parse_loop+0x7bd/0x94e
[   36.351105]  [<ffffffff81324ed9>] acpi_ps_parse_aml+0x96/0x275
[   36.351119]  [<ffffffff81326394>] acpi_ps_execute_method+0x1ce/0x276
[   36.351131]  [<ffffffff8132165b>] acpi_ns_evaluate+0xdf/0x1aa
[   36.351144]  [<ffffffff81320c9d>] acpi_evaluate_object+0xfb/0x1f4
[   36.351156]  [<ffffffff8130f8ee>] acpi_device_sleep_wake+0x95/0xc7
[   36.351168]  [<ffffffff8130fa60>] 
acpi_disable_wakeup_device_power+0x6e/0xc9
[   36.351182]  [<ffffffff813085e2>] acpi_disable_wakeup_devices+0x7b/0x95
[   36.351194]  [<ffffffff81308710>] acpi_pm_finish+0x39/0x55
[   36.351208]  [<ffffffff810a6034>] suspend_devices_and_enter+0x104/0x310
[   36.351222]  [<ffffffff810a63a7>] enter_state+0x167/0x190
[   36.351234]  [<ffffffff810a4d27>] state_store+0xb7/0x130
[   36.351246]  [<ffffffff812b54df>] kobj_attr_store+0xf/0x30
[   36.351260]  [<ffffffff811d382f>] sysfs_write_file+0xef/0x170
[   36.351274]  [<ffffffff811668d3>] vfs_write+0xb3/0x180
[   36.351286]  [<ffffffff81166bfa>] sys_write+0x4a/0x90
[   36.351300]  [<ffffffff81585d02>] system_call_fastpath+0x16/0x1b
[   36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8 5d 
fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b 4d 98 
31 d2 <8b> 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0 48 85 c9 48
[   36.351435] RIP  [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
[   36.351450]  RSP <ffff880002b71228>
[   36.351456] CR2: 0000000000000004
[   36.351465] ---[ end trace 5ad2b14b3a9050ae ]---
[   36.352362] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000010
[   36.352379] IP: [<ffffffff812ba531>] rb_next+0x1/0x50
[   36.352394] PGD 0
[   36.352402] Oops: 0000 [#2] SMP
[   36.352411] CPU 1
[   36.352416] Modules linked in: xt_mac ipt_MASQUERADE ebtable_filter 
ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O) xt_state crc32c 
xt_multiport libcrc32c iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4 ip_tables 
scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C) 
snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse 
serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O) 
thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm 
snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video 
intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
[   36.352573]
[   36.352580] Pid: 2730, comm: bash Tainted: G      D  C O 3.2.23-orc 
#19 LENOVO 42404EU/42404EU
[   36.352596] RIP: e030:[<ffffffff812ba531>]  [<fffffff




3)

[   47.833362] Resuming Xen processor info
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
[   47.886297] Enabling non-boot CPUs ...
[   47.890082] installing Xen timer for CPU 1
[   47.894257] cpu 1 spinlock event irq 48
[   47.899013] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[   47.906740] IP: [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
[   47.913578] PGD 34a4067 PUD 3ac3067 PMD 0
[   47.917825] Oops: 0000 [#1] SMP
[   47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebtables iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdisk(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs bridge stp llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul microcode psmouse serio_raw arc4 iwldvm mac80211 i915 drm_kms_helper drm iwlwifi intel_agp i2c_algo_bit cfg80211 intel_gtt video ahci libahci e1000e [last unloaded: tpm_bios]
[   47.974636] CPU 0
[   47.976456] Pid: 2468, comm: pm-suspend Tainted: G         C O 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake
[   47.988310] RIP: e030:[<ffffffff8149196b>]  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
[   47.997605] RSP: e02b:ffff880025685c98  EFLAGS: 00010286
[   48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX: 0000000000000000
[   48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI: ffff88002de40000
[   48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09: 0000000000000000
[   48.024520] R10: 0000000000000030 R11: 0000000000000000 R12: ffff88002de40000
[   48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15: 0000000000000000
[   48.038927] FS:  00007fb599d0e700(0000) GS:ffff88002de00000(0000) knlGS:0000000000000000
[   48.047060] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4: 0000000000002660
[   48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   48.074450] Process pm-suspend (pid: 2468, threadinfo ffff880025684000, task ffff880003558000)
[   48.083102] Stack:
[   48.085179]  ffff88002de40000 ffff88002de40000 00000000ffffffde ffffffff81a6b480
[   48.092622]  ffff880025685cd8 ffffffff81491cc1 0000000000000001 ffff88002de40000
[   48.100064]  ffff880025685cf8 ffffffff813046df 0000000000000001 0000000000000001
[   48.107517] Call Trace:
[   48.110029]  [<ffffffff81491cc1>] cpuidle_register_device+0x31/0x80
[   48.116348]  [<ffffffff813046df>] intel_idle_cpu_init+0xbf/0x120
[   48.122423]  [<ffffffff813047b0>] cpu_hotplug_notify+0x70/0x80
[   48.128310]  [<ffffffff815a619d>] notifier_call_chain+0x4d/0x70
[   48.134281]  [<ffffffff8107969e>] __raw_notifier_call_chain+0xe/0x10
[   48.140686]  [<ffffffff81053bb0>] __cpu_notify+0x20/0x40
[   48.146050]  [<ffffffff81594c7c>] _cpu_up+0xf1/0x138
[   48.151070]  [<ffffffff8158ab39>] enable_nonboot_cpus+0x99/0xd0
[   48.157090]  [<ffffffff81097b8d>] suspend_devices_and_enter+0x25d/0x330
[   48.163752]  [<ffffffff81097def>] pm_suspend+0x18f/0x1f0
[   48.169117]  [<ffffffff81096dea>] state_store+0x8a/0x100
[   48.174483]  [<ffffffff812ac29f>] kobj_attr_store+0xf/0x30
[   48.180022]  [<ffffffff811c005f>] sysfs_write_file+0xef/0x170
[   48.185943]  [<ffffffff8115c253>] vfs_write+0xb3/0x180
[   48.191056]  [<ffffffff8115c592>] sys_write+0x52/0xa0
[   48.196160]  [<ffffffff815a614e>] ? do_page_fault+0xe/0x10
[   48.201700]  [<ffffffff815aa7d9>] system_call_fastpath+0x16/0x1b
[   48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e0 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a 00 00<48>  8b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 49 c7
[   48.226658] RIP  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
[   48.233582]  RSP<ffff880025685c98>
[   48.237131] CR2: 0000000000000008

[   48.240521] ---[ end trace 535ebe28cd06b143 ]---




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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:07:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2IxZ-0000bc-O6; Mon, 04 Feb 2013 10:07:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U2IxW-0000bL-AZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:07:32 +0000
Received: from [85.158.139.211:54666] by server-5.bemta-5.messagelabs.com id
	F3/4A-11945-1688F015; Mon, 04 Feb 2013 10:07:29 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1359972444!17002651!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32511 invoked from network); 4 Feb 2013 10:07:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:07:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:07: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.297.1; Mon, 4 Feb 2013 10:07:24 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U2IxQ-0007Ee-1r; Mon, 04 Feb 2013
	10:07:24 +0000
Message-ID: <510F885B.2040603@citrix.com>
Date: Mon, 4 Feb 2013 11:07:23 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
In-Reply-To: <510F91CA02000078000BB6AA@nat28.tlf.novell.com>
Cc: Milan opath <milan.opath@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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


>> fix-suspend-scheduler-v2
>> fix-suspend-scheduler-revert-affinity-part
>> s3-timerirq
>>
>> All of these fixes have been proposed to the xen-devel list, but have
>> not yet been accepted, for one reason, or another.
>>      
> And I don't think comments on them have seen follow-ups.
>
> Jan
>
>    
I guess it's worth bringing this up again;

s3-timerirq: this was empirical hack which for some reason is needed on 
stable 4.2 we use, but not on latest unstable, didn't really investigate 
further since it appeared fixed later on anyway..

fix-suspend-scheduler/revert-affinity: the big objection here was the 
part which reverts one of the hunks in Keir's commit. I tried for quite 
few days to find a working fix which does not do this revert using 
posted suggestions, but was not succesfull:

- there was a crash in xen scheduler, which was fixable using your 
suggestion of masking softirqs during s3 (ugly)
- there was also a crash in xen acpi cpufreq driver, which was 
similarily fixable using a bandaid s3 condition (ugly)
- unfortunately this turned out to not be all, xen did not crash anymore 
at this point but dom0 kernel did around the time it enables cpus, in 
multiple places: at this point I didn't have a good explanation for it, 
my opinion of aggravating hunk was rather low, so I uttered a hearty 
curse and stuck a revert into private patchqueue.

The dom0 kernel crashes were as follows:

1)

[   60.657751] Enabling non-boot CPUs ...
[   60.657958] installing Xen timer for CPU 1
[   60.657987] cpu 1 spinlock event irq 279
[   60.658101] Disabled fast string operations
[   60.658466] CPU1 is up
[   60.658736] installing Xen timer for CPU 2
[   60.658784] cpu 2 spinlock event irq 285
[   60.659764] Disabled fast string operations
[   60.661811] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000018
[   60.661817] IP: [<ffffffff8105f700>] build_sched_domains+0x770/0(XEN) 
*** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0)




2)
.332997] installing Xen timer for CPU 2emory
[   36.333061] cpu 2 spinlock event irq 285
[   36.333343] Disabled fast string operations
[   36.334939] CPU2 is up
[   36.335213] installing Xen timer for CPU 3
[   36.335244] cpu 3 spinlock event irq 291
[   36.335561] Disabled fast string operations
[   36.337461] CPU3 is up
[   36.339513] ACPI: Waking up from system sleep state S3
[   36.350193] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000004
[   36.350211] IP: [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
[   36.350236] PGD 2f19067 PUD 2ec7067 PMD 0
[   36.350252] Oops: 0000 [#1] SMP
[   36.350263] CPU 1
[   36.350267] Modules linked in: xt_mac ipt_MASQUERADE ebtable_filter 
ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O) xt_state crc32c 
xt_multiport libcrc32c iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4 ip_tables 
scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C) 
snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse 
serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O) 
thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm 
snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video 
intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
[   36.350437]
[   36.350445] Pid: 2730, comm: bash Tainted: G         C O 3.2.23-orc 
#19 LENOVO 42404EU/42404EU
[   36.350463] RIP: e030:[<ffffffff81055f9a>]  [<ffffffff81055f9a>] 
find_busiest_group+0x38a/0xbb0
[   36.350481] RSP: e02b:ffff880002b71228  EFLAGS: 00010046
[   36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX: 
0000000000000000
[   36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI: 
0000000000000000
[   36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09: 
0000000000000000
[   36.350519] R10: 0000000000000000 R11: 0000000000000001 R12: 
0000000000000000
[   36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15: 
ffff880026109f98
[   36.350547] FS:  00007fc41e295700(0000) GS:ffff88002dc40000(0000) 
knlGS:0000000000000000
[   36.350558] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4: 
0000000000002660
[   36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[   36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[   36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000, 
task ffff880027a7db40)
[   36.350608] Stack:
[   36.350613]  00ffffff00000002 0000000300000001 ffff880002b71498 
ffff880002b71534
[   36.350630]  00ffffff00000002 0000000100000001 ffff8800262cf000 
0000000000000008
[   36.350646]  ffffffff00000000 0000000000000000 0000000000000000 
ffff88002dc4e2c8
[   36.350662] Call Trace:
[   36.350677]  [<ffffffff8105b158>] load_balance+0xb8/0x840
[   36.350690]  [<ffffffff8101b909>] ? sched_clock+0x9/0x10
[   36.350706]  [<ffffffff8108ccad>] ? sched_clock_cpu+0xbd/0x110
[   36.350718]  [<ffffffff81052b1c>] ? update_shares+0xcc/0x100
[   36.350735]  [<ffffffff8157b9b5>] __schedule+0x875/0x8d0
[   36.350749]  [<ffffffff81073ae2>] ? try_to_del_timer_sync+0x92/0x130
[   36.350762]  [<ffffffff8157bd3f>] schedule+0x3f/0x60
[   36.350773]  [<ffffffff8157c24d>] schedule_timeout+0x16d/0x320
[   36.350786]  [<ffffffff810728e0>] ? usleep_range+0x50/0x50
[   36.350800]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   36.350817]  [<ffffffff8130c340>] 
acpi_ec_transaction_unlocked+0x134/0x1d8
[   36.350830]  [<ffffffff81086b90>] ? add_wait_queue+0x60/0x60
[   36.350842]  [<ffffffff8130c6c6>] acpi_ec_transaction+0x196/0x239
[   36.350856]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
[   36.350869]  [<ffffffff8130c8a0>] acpi_ec_write+0x40/0x42
[   36.350881]  [<ffffffff8130c9a8>] acpi_ec_space_handler+0x9e/0xfc
[   36.350894]  [<ffffffff8130c90a>] ? acpi_ec_burst_disable+0x3d/0x3d
[   36.350909]  [<ffffffff813159c6>] 
acpi_ev_address_space_dispatch+0x179/0x1c8
[   36.350924]  [<ffffffff8131aafe>] acpi_ex_access_region+0x23e/0x24b
[   36.350936]  [<ffffffff8106e82c>] ? __sysctl_head_next+0x11c/0x130
[   36.350951]  [<ffffffff8131ae15>] acpi_ex_field_datum_io+0xf9/0x17a
[   36.350965]  [<ffffffff8131b148>] 
acpi_ex_write_with_update_rule+0xb5/0xc1
[   36.350989]  [<ffffffff8131acfa>] acpi_ex_insert_into_field+0x1ef/0x211
[   36.351003]  [<ffffffff8132b5a7>] ? 
acpi_ut_allocate_object_desc_dbg+0x45/0x7f
[   36.351018]  [<ffffffff8131980e>] acpi_ex_write_data_to_field+0x194/0x1c2
[   36.351031]  [<ffffffff813131e4>] ? 
acpi_ds_init_object_from_op+0x137/0x231
[   36.351044]  [<ffffffff8131d94f>] acpi_ex_store_object_to_node+0xa3/0xe2
[   36.351056]  [<ffffffff8131da51>] acpi_ex_store+0xc3/0x256
[   36.351066]  [<ffffffff8131b62b>] acpi_ex_opcode_1A_1T_1R+0x353/0x4a5
[   36.351078]  [<ffffffff8131260c>] acpi_ds_exec_end_op+0xf7/0x3e7
[   36.351092]  [<ffffffff81325ae7>] acpi_ps_parse_loop+0x7bd/0x94e
[   36.351105]  [<ffffffff81324ed9>] acpi_ps_parse_aml+0x96/0x275
[   36.351119]  [<ffffffff81326394>] acpi_ps_execute_method+0x1ce/0x276
[   36.351131]  [<ffffffff8132165b>] acpi_ns_evaluate+0xdf/0x1aa
[   36.351144]  [<ffffffff81320c9d>] acpi_evaluate_object+0xfb/0x1f4
[   36.351156]  [<ffffffff8130f8ee>] acpi_device_sleep_wake+0x95/0xc7
[   36.351168]  [<ffffffff8130fa60>] 
acpi_disable_wakeup_device_power+0x6e/0xc9
[   36.351182]  [<ffffffff813085e2>] acpi_disable_wakeup_devices+0x7b/0x95
[   36.351194]  [<ffffffff81308710>] acpi_pm_finish+0x39/0x55
[   36.351208]  [<ffffffff810a6034>] suspend_devices_and_enter+0x104/0x310
[   36.351222]  [<ffffffff810a63a7>] enter_state+0x167/0x190
[   36.351234]  [<ffffffff810a4d27>] state_store+0xb7/0x130
[   36.351246]  [<ffffffff812b54df>] kobj_attr_store+0xf/0x30
[   36.351260]  [<ffffffff811d382f>] sysfs_write_file+0xef/0x170
[   36.351274]  [<ffffffff811668d3>] vfs_write+0xb3/0x180
[   36.351286]  [<ffffffff81166bfa>] sys_write+0x4a/0x90
[   36.351300]  [<ffffffff81585d02>] system_call_fastpath+0x16/0x1b
[   36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8 5d 
fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b 4d 98 
31 d2 <8b> 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0 48 85 c9 48
[   36.351435] RIP  [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
[   36.351450]  RSP <ffff880002b71228>
[   36.351456] CR2: 0000000000000004
[   36.351465] ---[ end trace 5ad2b14b3a9050ae ]---
[   36.352362] BUG: unable to handle kernel NULL pointer dereference at 
0000000000000010
[   36.352379] IP: [<ffffffff812ba531>] rb_next+0x1/0x50
[   36.352394] PGD 0
[   36.352402] Oops: 0000 [#2] SMP
[   36.352411] CPU 1
[   36.352416] Modules linked in: xt_mac ipt_MASQUERADE ebtable_filter 
ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O) xt_state crc32c 
xt_multiport libcrc32c iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4 ip_tables 
scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C) 
snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse 
serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O) 
thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm 
snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video 
intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
[   36.352573]
[   36.352580] Pid: 2730, comm: bash Tainted: G      D  C O 3.2.23-orc 
#19 LENOVO 42404EU/42404EU
[   36.352596] RIP: e030:[<ffffffff812ba531>]  [<fffffff




3)

[   47.833362] Resuming Xen processor info
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
(XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
[   47.886297] Enabling non-boot CPUs ...
[   47.890082] installing Xen timer for CPU 1
[   47.894257] cpu 1 spinlock event irq 48
[   47.899013] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[   47.906740] IP: [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
[   47.913578] PGD 34a4067 PUD 3ac3067 PMD 0
[   47.917825] Oops: 0000 [#1] SMP
[   47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebtables iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdisk(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs bridge stp llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul microcode psmouse serio_raw arc4 iwldvm mac80211 i915 drm_kms_helper drm iwlwifi intel_agp i2c_algo_bit cfg80211 intel_gtt video ahci libahci e1000e [last unloaded: tpm_bios]
[   47.974636] CPU 0
[   47.976456] Pid: 2468, comm: pm-suspend Tainted: G         C O 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake
[   47.988310] RIP: e030:[<ffffffff8149196b>]  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
[   47.997605] RSP: e02b:ffff880025685c98  EFLAGS: 00010286
[   48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX: 0000000000000000
[   48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI: ffff88002de40000
[   48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09: 0000000000000000
[   48.024520] R10: 0000000000000030 R11: 0000000000000000 R12: ffff88002de40000
[   48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15: 0000000000000000
[   48.038927] FS:  00007fb599d0e700(0000) GS:ffff88002de00000(0000) knlGS:0000000000000000
[   48.047060] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4: 0000000000002660
[   48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   48.074450] Process pm-suspend (pid: 2468, threadinfo ffff880025684000, task ffff880003558000)
[   48.083102] Stack:
[   48.085179]  ffff88002de40000 ffff88002de40000 00000000ffffffde ffffffff81a6b480
[   48.092622]  ffff880025685cd8 ffffffff81491cc1 0000000000000001 ffff88002de40000
[   48.100064]  ffff880025685cf8 ffffffff813046df 0000000000000001 0000000000000001
[   48.107517] Call Trace:
[   48.110029]  [<ffffffff81491cc1>] cpuidle_register_device+0x31/0x80
[   48.116348]  [<ffffffff813046df>] intel_idle_cpu_init+0xbf/0x120
[   48.122423]  [<ffffffff813047b0>] cpu_hotplug_notify+0x70/0x80
[   48.128310]  [<ffffffff815a619d>] notifier_call_chain+0x4d/0x70
[   48.134281]  [<ffffffff8107969e>] __raw_notifier_call_chain+0xe/0x10
[   48.140686]  [<ffffffff81053bb0>] __cpu_notify+0x20/0x40
[   48.146050]  [<ffffffff81594c7c>] _cpu_up+0xf1/0x138
[   48.151070]  [<ffffffff8158ab39>] enable_nonboot_cpus+0x99/0xd0
[   48.157090]  [<ffffffff81097b8d>] suspend_devices_and_enter+0x25d/0x330
[   48.163752]  [<ffffffff81097def>] pm_suspend+0x18f/0x1f0
[   48.169117]  [<ffffffff81096dea>] state_store+0x8a/0x100
[   48.174483]  [<ffffffff812ac29f>] kobj_attr_store+0xf/0x30
[   48.180022]  [<ffffffff811c005f>] sysfs_write_file+0xef/0x170
[   48.185943]  [<ffffffff8115c253>] vfs_write+0xb3/0x180
[   48.191056]  [<ffffffff8115c592>] sys_write+0x52/0xa0
[   48.196160]  [<ffffffff815a614e>] ? do_page_fault+0xe/0x10
[   48.201700]  [<ffffffff815aa7d9>] system_call_fastpath+0x16/0x1b
[   48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e0 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a 00 00<48>  8b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 49 c7
[   48.226658] RIP  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
[   48.233582]  RSP<ffff880025685c98>
[   48.237131] CR2: 0000000000000008

[   48.240521] ---[ end trace 535ebe28cd06b143 ]---




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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:12:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:12: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 1U2J21-00011E-4w; Mon, 04 Feb 2013 10:12:09 +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 1U2J1z-000113-S6
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:12:08 +0000
Received: from [85.158.137.99:47243] by server-2.bemta-3.messagelabs.com id
	AB/E3-25961-7798F015; Mon, 04 Feb 2013 10:12:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1359972722!19742327!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27565 invoked from network); 4 Feb 2013 10:12:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:12:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:12: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.297.1; Mon, 4 Feb 2013
	10:12:02 +0000
Message-ID: <1359972720.5281.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 10:12:00 +0000
In-Reply-To: <d76b38b799293ff17fed.1359745100@probook.site>
References: <d76b38b799293ff17fed.1359745100@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359745022 -3600
> # Node ID d76b38b799293ff17fed8eaaac8fbbebced1b72f
> # Parent  6d1d516ecaade56f796e3216e9931fdcc12282cd
> tools/xc: restore logging in xc_save
> 
> Prior to xen-4.1 the helper xc_save would print some progress during
> migration. With the new xc_interface_open API no more messages were
> printed because no logger was configured.
> 
> Restore previous behaviour by providing a logger. The progress in
> xc_domain_save will be disabled because its output lacks a linefeed
> which makes xend.log look ugly.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 6d1d516ecaad -r d76b38b79929 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c
> +++ b/tools/xcutils/xc_save.c
> @@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
>  int
>  main(int argc, char **argv)
>  {
> -    unsigned int maxit, max_f;
> +    unsigned int maxit, max_f, lflags;
>      int io_fd, ret, port;
>      struct save_callbacks callbacks;
> +    xentoollog_level lvl;
> +    xentoollog_logger *l;
>  
>      if (argc != 6)
>          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
>  
> -    si.xch = xc_interface_open(0,0,0);
> -    if (!si.xch)
> -        errx(1, "failed to open control interface");
> -
>      io_fd = atoi(argv[1]);
>      si.domid = atoi(argv[2]);
>      maxit = atoi(argv[3]);
> @@ -185,6 +183,13 @@ main(int argc, char **argv)
>  
>      si.suspend_evtchn = -1;
>  
> +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;

Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
flag which makes it output something more suitable for logging,
e.g. ...10%...20%...30%... 
(or perhaps automatic based on isatty(outputfd)?)

> +    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);

Might this fail and therefore require error handling?

The lvl and lflags variables seem a bit useless to me.

> +    si.xch = xc_interface_open(l, 0, 0);
> +    if (!si.xch)
> +        errx(1, "failed to open control interface");
> +
>      si.xce = xc_evtchn_open(NULL, 0);
>      if (si.xce == NULL)
>          warnx("failed to open event channel handle");
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 10:12:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:12: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 1U2J21-00011E-4w; Mon, 04 Feb 2013 10:12:09 +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 1U2J1z-000113-S6
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:12:08 +0000
Received: from [85.158.137.99:47243] by server-2.bemta-3.messagelabs.com id
	AB/E3-25961-7798F015; Mon, 04 Feb 2013 10:12:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1359972722!19742327!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27565 invoked from network); 4 Feb 2013 10:12:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:12:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:12: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.297.1; Mon, 4 Feb 2013
	10:12:02 +0000
Message-ID: <1359972720.5281.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 10:12:00 +0000
In-Reply-To: <d76b38b799293ff17fed.1359745100@probook.site>
References: <d76b38b799293ff17fed.1359745100@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359745022 -3600
> # Node ID d76b38b799293ff17fed8eaaac8fbbebced1b72f
> # Parent  6d1d516ecaade56f796e3216e9931fdcc12282cd
> tools/xc: restore logging in xc_save
> 
> Prior to xen-4.1 the helper xc_save would print some progress during
> migration. With the new xc_interface_open API no more messages were
> printed because no logger was configured.
> 
> Restore previous behaviour by providing a logger. The progress in
> xc_domain_save will be disabled because its output lacks a linefeed
> which makes xend.log look ugly.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 6d1d516ecaad -r d76b38b79929 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c
> +++ b/tools/xcutils/xc_save.c
> @@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
>  int
>  main(int argc, char **argv)
>  {
> -    unsigned int maxit, max_f;
> +    unsigned int maxit, max_f, lflags;
>      int io_fd, ret, port;
>      struct save_callbacks callbacks;
> +    xentoollog_level lvl;
> +    xentoollog_logger *l;
>  
>      if (argc != 6)
>          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
>  
> -    si.xch = xc_interface_open(0,0,0);
> -    if (!si.xch)
> -        errx(1, "failed to open control interface");
> -
>      io_fd = atoi(argv[1]);
>      si.domid = atoi(argv[2]);
>      maxit = atoi(argv[3]);
> @@ -185,6 +183,13 @@ main(int argc, char **argv)
>  
>      si.suspend_evtchn = -1;
>  
> +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;

Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
flag which makes it output something more suitable for logging,
e.g. ...10%...20%...30%... 
(or perhaps automatic based on isatty(outputfd)?)

> +    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);

Might this fail and therefore require error handling?

The lvl and lflags variables seem a bit useless to me.

> +    si.xch = xc_interface_open(l, 0, 0);
> +    if (!si.xch)
> +        errx(1, "failed to open control interface");
> +
>      si.xce = xc_evtchn_open(NULL, 0);
>      if (si.xce == NULL)
>          warnx("failed to open event channel handle");
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 10:24:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JDr-0001PZ-E1; Mon, 04 Feb 2013 10:24: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 1U2JDp-0001PQ-W0
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 10:24:22 +0000
Received: from [85.158.143.99:25840] by server-2.bemta-4.messagelabs.com id
	E8/54-01597-55C8F015; Mon, 04 Feb 2013 10:24:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359973451!20975745!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19701 invoked from network); 4 Feb 2013 10:24:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1112460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:24: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.297.1; Mon, 4 Feb 2013
	10:24:11 +0000
Message-ID: <1359973450.5281.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 10:24:10 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BC0@FTLPMAILBOX02.citrite.net>
	<1357728271.7989.220.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 20:26 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Wednesday, January 09, 2013 5:45 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com; Art Napor (artnapor@yahoo.com)
> > Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> > 
> > On Tue, 2013-01-08 at 22:04 +0000, Ross Philipson wrote:
> > > Attached is a tarball with a helper library for reading host ACPI and
> > > SMBIOS firmware and creating firmware files that can be used with the
> > > HVM firmware passthrough patches I submitted. I used it in my testing
> > > of the patches and planned to use it later when we moved to a new Xen
> > > version. This library was requested by a few people - I hope you find
> > > it useful.
> > 
> > Would it make sense / are you planning to integrate this into the Xen
> > tree as well? I'm not sure if it fits into an existing library e.g.
> > libxenguest if it would be a separate library.
> > 
> > Ian.
> 
> Following up on this. Is there any interest in integrating this into
> xen? I don't think it belongs in xenguest because it would be used up
> at the libxl level where the fw blobs are passed in via the xl config
> file. It seems like it should be in some separate utilities library
> but I can't really see where.

Maybe the best place would be in libxl itself, or perhaps better in
libxlu?

Toolstacks are supposed to be moving towards using libxl(u) anyway and
even in the interim linking against the library for just these functions
is no great hardship.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:24:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JDr-0001PZ-E1; Mon, 04 Feb 2013 10:24: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 1U2JDp-0001PQ-W0
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 10:24:22 +0000
Received: from [85.158.143.99:25840] by server-2.bemta-4.messagelabs.com id
	E8/54-01597-55C8F015; Mon, 04 Feb 2013 10:24:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359973451!20975745!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19701 invoked from network); 4 Feb 2013 10:24:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1112460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:24: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.297.1; Mon, 4 Feb 2013
	10:24:11 +0000
Message-ID: <1359973450.5281.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 10:24:10 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BC0@FTLPMAILBOX02.citrite.net>
	<1357728271.7989.220.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 20:26 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Wednesday, January 09, 2013 5:45 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com; Art Napor (artnapor@yahoo.com)
> > Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> > 
> > On Tue, 2013-01-08 at 22:04 +0000, Ross Philipson wrote:
> > > Attached is a tarball with a helper library for reading host ACPI and
> > > SMBIOS firmware and creating firmware files that can be used with the
> > > HVM firmware passthrough patches I submitted. I used it in my testing
> > > of the patches and planned to use it later when we moved to a new Xen
> > > version. This library was requested by a few people - I hope you find
> > > it useful.
> > 
> > Would it make sense / are you planning to integrate this into the Xen
> > tree as well? I'm not sure if it fits into an existing library e.g.
> > libxenguest if it would be a separate library.
> > 
> > Ian.
> 
> Following up on this. Is there any interest in integrating this into
> xen? I don't think it belongs in xenguest because it would be used up
> at the libxl level where the fw blobs are passed in via the xl config
> file. It seems like it should be in some separate utilities library
> but I can't really see where.

Maybe the best place would be in libxl itself, or perhaps better in
libxlu?

Toolstacks are supposed to be moving towards using libxl(u) anyway and
even in the interim linking against the library for just these functions
is no great hardship.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:24:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:24: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 1U2JEA-0001R6-26; Mon, 04 Feb 2013 10:24:42 +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 1U2JE8-0001Ql-Nf
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:24:40 +0000
Received: from [85.158.138.51:18886] by server-10.bemta-3.messagelabs.com id
	67/58-10609-36C8F015; Mon, 04 Feb 2013 10:24:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1359973475!21997072!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31445 invoked from network); 4 Feb 2013 10:24:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 10:24:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo37) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4042a1p14AGnGK ;
	Mon, 4 Feb 2013 11:23:32 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D0D711884C; Mon,  4 Feb 2013 11:23:31 +0100 (CET)
Date: Mon, 4 Feb 2013 11:23:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204102331.GA6328@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359972720.5281.20.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> 
> Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> flag which makes it output something more suitable for logging,
> e.g. ...10%...20%...30%... 
> (or perhaps automatic based on isatty(outputfd)?)

I was thinking about that, to extend the called progress functions. In
the case of xend.log it would produce many lines of progress.
Since the default xend logging is limited to 1MB, the xend.log file
would be rotated quickly and maybe useful logging output will be lost?

But for other callers of the progress functions it might be useful to
have a parsable output so that they dont have to jump through the hoops.
No idea if any caller makes use of the progress, given that it did not
work at all without the other patch I sent last Friday.

> > +    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
> 
> Might this fail and therefore require error handling?

If it fails then no logging will happen.

> The lvl and lflags variables seem a bit useless to me.

They are there to keep the lines short.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:24:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:24: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 1U2JEA-0001R6-26; Mon, 04 Feb 2013 10:24:42 +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 1U2JE8-0001Ql-Nf
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:24:40 +0000
Received: from [85.158.138.51:18886] by server-10.bemta-3.messagelabs.com id
	67/58-10609-36C8F015; Mon, 04 Feb 2013 10:24:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1359973475!21997072!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31445 invoked from network); 4 Feb 2013 10:24:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 10:24:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo37) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4042a1p14AGnGK ;
	Mon, 4 Feb 2013 11:23:32 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D0D711884C; Mon,  4 Feb 2013 11:23:31 +0100 (CET)
Date: Mon, 4 Feb 2013 11:23:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204102331.GA6328@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359972720.5281.20.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> 
> Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> flag which makes it output something more suitable for logging,
> e.g. ...10%...20%...30%... 
> (or perhaps automatic based on isatty(outputfd)?)

I was thinking about that, to extend the called progress functions. In
the case of xend.log it would produce many lines of progress.
Since the default xend logging is limited to 1MB, the xend.log file
would be rotated quickly and maybe useful logging output will be lost?

But for other callers of the progress functions it might be useful to
have a parsable output so that they dont have to jump through the hoops.
No idea if any caller makes use of the progress, given that it did not
work at all without the other patch I sent last Friday.

> > +    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
> 
> Might this fail and therefore require error handling?

If it fails then no logging will happen.

> The lvl and lflags variables seem a bit useless to me.

They are there to keep the lines short.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:25:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JEm-0001VX-Fs; Mon, 04 Feb 2013 10:25:20 +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 1U2JEl-0001VG-AG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:25:19 +0000
Received: from [85.158.139.83:61621] by server-9.bemta-5.messagelabs.com id
	97/A3-24440-E8C8F015; Mon, 04 Feb 2013 10:25:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1359973516!25309926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 4 Feb 2013 10:25:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="6143094"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 10:25:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 05:25:16 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2JEh-0003Xj-TJ;
	Mon, 04 Feb 2013 10:25:15 +0000
Message-ID: <1359973515.7477.15.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 10:25:15 +0000
In-Reply-To: <510F86CE02000078000BB665@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-5-git-send-email-wei.liu2@citrix.com>
	<510F86CE02000078000BB665@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/16] Move event channel macros / struct
 definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 09:00 +0000, Jan Beulich wrote:
> >>> On 31.01.13 at 15:42, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -557,6 +557,8 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
> >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> >   */
> >  #define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > +#define EVTCHNS_PER_BUCKET 128
> > +#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
> 
> These aren't part of the hypercall ABI, and hence don't belong here.
> What is preventing you from putting them alongside the other
> stuff you move to xen/include/xen/event.h?
> 

That would cause circular inclusion and break the build.

a) sched.h: struct domain reference NR_EVTCHN_BUCKETS
b) event.h: refereces sched.h

Now a second thought come to me, a clean fix would be that I make the
allocation of evtchn in struct domain first, then move those macros /
definitions to proper place.


Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:25:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JEm-0001VX-Fs; Mon, 04 Feb 2013 10:25:20 +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 1U2JEl-0001VG-AG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:25:19 +0000
Received: from [85.158.139.83:61621] by server-9.bemta-5.messagelabs.com id
	97/A3-24440-E8C8F015; Mon, 04 Feb 2013 10:25:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1359973516!25309926!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 4 Feb 2013 10:25:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:25:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="6143094"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 10:25:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 05:25:16 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2JEh-0003Xj-TJ;
	Mon, 04 Feb 2013 10:25:15 +0000
Message-ID: <1359973515.7477.15.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 10:25:15 +0000
In-Reply-To: <510F86CE02000078000BB665@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-5-git-send-email-wei.liu2@citrix.com>
	<510F86CE02000078000BB665@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/16] Move event channel macros / struct
 definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 09:00 +0000, Jan Beulich wrote:
> >>> On 31.01.13 at 15:42, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -557,6 +557,8 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
> >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> >   */
> >  #define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > +#define EVTCHNS_PER_BUCKET 128
> > +#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
> 
> These aren't part of the hypercall ABI, and hence don't belong here.
> What is preventing you from putting them alongside the other
> stuff you move to xen/include/xen/event.h?
> 

That would cause circular inclusion and break the build.

a) sched.h: struct domain reference NR_EVTCHN_BUCKETS
b) event.h: refereces sched.h

Now a second thought come to me, a clean fix would be that I make the
allocation of evtchn in struct domain first, then move those macros /
definitions to proper place.


Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:31:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:31: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 1U2JL2-0001sq-B4; Mon, 04 Feb 2013 10: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 1U2JL0-0001sl-EL
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:31:46 +0000
Received: from [85.158.138.51:5151] by server-16.bemta-3.messagelabs.com id
	F7/A4-02727-11E8F015; Mon, 04 Feb 2013 10:31:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1359973903!22756300!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14290 invoked from network); 4 Feb 2013 10:31:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1112831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:31: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.297.1; Mon, 4 Feb 2013
	10:31:43 +0000
Message-ID: <1359973901.5281.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 4 Feb 2013 10:31:41 +0000
In-Reply-To: <20130201112716.4d63716c@mantra.us.oracle.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.com>
	<20130201112716.4d63716c@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "konrad@kernel.org" <konrad@kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 19:27 +0000, Mukesh Rathor wrote:
> On Fri, 01 Feb 2013 16:24:57 +0000
> "Jan Beulich" <jbeulich@suse.com> wrote:
> 
> > >>> Mukesh Rathor <mukesh.rathor@oracle.com> 02/01/13 3:23 AM >>>
> > >On Tue, 29 Jan 2013 10:48:12 +0000 "Jan Beulich" <JBeulich@suse.com>
> > >wrote:
> > >> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> > >> >>> wrote:
> > >> difficult, but I continue to see more advantage in avoiding the
> > >> redundancy).
> > >
> > >That was my patch version 2, where I called it gdt and another
> > >reviewer suggested to change to u. So I changed it to u.
> > >
> > >It's gone thru enough iterations that I'd like to leave as is. Thank
> > >you in advance for your compromise in helping us mortals grep/cscope 
> > >to learn code.
> > 
> > That's part of the reason why I said from the beginning that doing
> > the Linux side first is wrong.
> 
> It was reviewed by xen folks like Ian C, Stefano, etc... 

Well, that doesn't in any way mean that Jan's opinion isn't valid or
relevant and where reviewers/authors cannot reach consensus over
something then it is ultimately the maintainer's call.

I deliberately avoided formally Acking any of the Linux side patches
until the hypervisor side was posted and reviewed, precisely because it
is necessary to review the hypervisor interfaces as part of the
hypervisor changes before committing to them. I believe we explicitly
agreed that the interface would be subject to change when the hypervisor
patches were posted for review.

WRT this particular change I don't personally like the idea of sharing
gdt_frames[0] and gdt_ents for two semantically different usages, but I
would defer to Jan as a hypervisor maintainer on that point.

I don't much care about the gdt vs u naming for the union, although I
would probably have gone with the more meaningful gdt if it were me.
cscope-wise in emacs I would just use "C-c s t" to look for "gdt.size"
etc.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:31:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:31: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 1U2JL2-0001sq-B4; Mon, 04 Feb 2013 10: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 1U2JL0-0001sl-EL
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:31:46 +0000
Received: from [85.158.138.51:5151] by server-16.bemta-3.messagelabs.com id
	F7/A4-02727-11E8F015; Mon, 04 Feb 2013 10:31:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1359973903!22756300!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14290 invoked from network); 4 Feb 2013 10:31:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:31:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1112831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:31: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.297.1; Mon, 4 Feb 2013
	10:31:43 +0000
Message-ID: <1359973901.5281.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 4 Feb 2013 10:31:41 +0000
In-Reply-To: <20130201112716.4d63716c@mantra.us.oracle.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.com>
	<20130201112716.4d63716c@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "konrad@kernel.org" <konrad@kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 19:27 +0000, Mukesh Rathor wrote:
> On Fri, 01 Feb 2013 16:24:57 +0000
> "Jan Beulich" <jbeulich@suse.com> wrote:
> 
> > >>> Mukesh Rathor <mukesh.rathor@oracle.com> 02/01/13 3:23 AM >>>
> > >On Tue, 29 Jan 2013 10:48:12 +0000 "Jan Beulich" <JBeulich@suse.com>
> > >wrote:
> > >> >>> On 29.01.13 at 03:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> > >> >>> wrote:
> > >> difficult, but I continue to see more advantage in avoiding the
> > >> redundancy).
> > >
> > >That was my patch version 2, where I called it gdt and another
> > >reviewer suggested to change to u. So I changed it to u.
> > >
> > >It's gone thru enough iterations that I'd like to leave as is. Thank
> > >you in advance for your compromise in helping us mortals grep/cscope 
> > >to learn code.
> > 
> > That's part of the reason why I said from the beginning that doing
> > the Linux side first is wrong.
> 
> It was reviewed by xen folks like Ian C, Stefano, etc... 

Well, that doesn't in any way mean that Jan's opinion isn't valid or
relevant and where reviewers/authors cannot reach consensus over
something then it is ultimately the maintainer's call.

I deliberately avoided formally Acking any of the Linux side patches
until the hypervisor side was posted and reviewed, precisely because it
is necessary to review the hypervisor interfaces as part of the
hypervisor changes before committing to them. I believe we explicitly
agreed that the interface would be subject to change when the hypervisor
patches were posted for review.

WRT this particular change I don't personally like the idea of sharing
gdt_frames[0] and gdt_ents for two semantically different usages, but I
would defer to Jan as a hypervisor maintainer on that point.

I don't much care about the gdt vs u naming for the union, although I
would probably have gone with the more meaningful gdt if it were me.
cscope-wise in emacs I would just use "C-c s t" to look for "gdt.size"
etc.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:37:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2JPx-00021g-3c; Mon, 04 Feb 2013 10:36:53 +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 1U2JPv-00021Z-LC
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:36:51 +0000
Received: from [85.158.139.83:18238] by server-1.bemta-5.messagelabs.com id
	FB/0E-29263-24F8F015; Mon, 04 Feb 2013 10:36:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1359974208!26744687!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5025 invoked from network); 4 Feb 2013 10:36:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:36:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="6143973"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 10:36:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 05:36:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2JPU-0003iE-Je;
	Mon, 04 Feb 2013 10:36:24 +0000
Message-ID: <1359974184.7477.16.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 10:36:24 +0000
In-Reply-To: <510F85D302000078000BB65E@nat28.tlf.novell.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
	<510F85D302000078000BB65E@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 08:56 +0000, Jan Beulich wrote:
> >>> On 31.01.13 at 15:47, Wei Liu <wei.liu2@citrix.com> wrote:
> > @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
> >  void xen_callback_vector(void) {}
> >  #endif
> >  
> > +static int xen_event_channel_register_3level(void)
> > +{
> > +	evtchn_register_nlevel_t reg;
> > +	int i, cpu;
> > +	unsigned long *_evtchn_pending = NULL;
> > +	unsigned long *_evtchn_mask = NULL;
> > +	unsigned long *l2sel_mfns = NULL;
> > +	unsigned long *l2sel_offsets = NULL;
> > +	int rc;
> > +
> > +	/* If we come from restore path, we don't need to allocate
> > +	 * pages.
> > +	 */
> > +	if (!evtchn_pending && !evtchn_mask) {
> > +		evtchn_pending =
> > +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> > +							  BITMAP_PG_ORDER);
> > +		evtchn_mask =
> > +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> > +							  BITMAP_PG_ORDER);
> > +		if (!evtchn_pending || !evtchn_mask) {
> > +			free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> > +			free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> 
> free_pages() takes an order just like __get_free_pages() does.

Good catch, thanks!


Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:37:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2JPx-00021g-3c; Mon, 04 Feb 2013 10:36:53 +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 1U2JPv-00021Z-LC
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:36:51 +0000
Received: from [85.158.139.83:18238] by server-1.bemta-5.messagelabs.com id
	FB/0E-29263-24F8F015; Mon, 04 Feb 2013 10:36:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1359974208!26744687!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5025 invoked from network); 4 Feb 2013 10:36:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:36:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="6143973"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 10:36:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 05:36:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2JPU-0003iE-Je;
	Mon, 04 Feb 2013 10:36:24 +0000
Message-ID: <1359974184.7477.16.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 10:36:24 +0000
In-Reply-To: <510F85D302000078000BB65E@nat28.tlf.novell.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
	<510F85D302000078000BB65E@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 08:56 +0000, Jan Beulich wrote:
> >>> On 31.01.13 at 15:47, Wei Liu <wei.liu2@citrix.com> wrote:
> > @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
> >  void xen_callback_vector(void) {}
> >  #endif
> >  
> > +static int xen_event_channel_register_3level(void)
> > +{
> > +	evtchn_register_nlevel_t reg;
> > +	int i, cpu;
> > +	unsigned long *_evtchn_pending = NULL;
> > +	unsigned long *_evtchn_mask = NULL;
> > +	unsigned long *l2sel_mfns = NULL;
> > +	unsigned long *l2sel_offsets = NULL;
> > +	int rc;
> > +
> > +	/* If we come from restore path, we don't need to allocate
> > +	 * pages.
> > +	 */
> > +	if (!evtchn_pending && !evtchn_mask) {
> > +		evtchn_pending =
> > +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> > +							  BITMAP_PG_ORDER);
> > +		evtchn_mask =
> > +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> > +							  BITMAP_PG_ORDER);
> > +		if (!evtchn_pending || !evtchn_mask) {
> > +			free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> > +			free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> 
> free_pages() takes an order just like __get_free_pages() does.

Good catch, thanks!


Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:38:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JR2-00026R-Iq; Mon, 04 Feb 2013 10:38: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 1U2JR1-00026I-EQ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:37:59 +0000
Received: from [85.158.139.83:29297] by server-9.bemta-5.messagelabs.com id
	48/97-24440-68F8F015; Mon, 04 Feb 2013 10:37:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1359974277!25312065!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29891 invoked from network); 4 Feb 2013 10:37:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:37:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1113103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:37: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.297.1; Mon, 4 Feb 2013
	10:37:57 +0000
Message-ID: <1359974276.5281.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 10:37:56 +0000
In-Reply-To: <20130204102331.GA6328@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130204102331.GA6328@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, 2013-02-04 at 10:23 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> > 
> > Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> > flag which makes it output something more suitable for logging,
> > e.g. ...10%...20%...30%... 
> > (or perhaps automatic based on isatty(outputfd)?)
> 
> I was thinking about that, to extend the called progress functions. In
> the case of xend.log it would produce many lines of progress.

How come many lines? I imaged the above as a single line.

> Since the default xend logging is limited to 1MB, the xend.log file
> would be rotated quickly and maybe useful logging output will be lost?
> 
> But for other callers of the progress functions it might be useful to
> have a parsable output so that they dont have to jump through the hoops.
> No idea if any caller makes use of the progress, given that it did not
> work at all without the other patch I sent last Friday.

xl migrate uses AFAIK, which isn't to say it wasn't broken ;-)

> 
> > > +    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
> > 
> > Might this fail and therefore require error handling?
> 
> If it fails then no logging will happen.

Which I suppose is better than failing the migration altogether.

> 
> > The lvl and lflags variables seem a bit useless to me.
> 
> They are there to keep the lines short

I would have done:
    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr,
                                        si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL,
                                        XTL_STDIOSTREAM_HIDE_PROGRESS);

But OK.

I think that addresses both of my questions, so
	Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I did mean to ask why the code had to move?

(I've been avoiding committing anything while we sort out the staging
backlog, and I seem to have a massive email backlog this morning to
boot, but this is in my queue)

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:38:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JR2-00026R-Iq; Mon, 04 Feb 2013 10:38: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 1U2JR1-00026I-EQ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:37:59 +0000
Received: from [85.158.139.83:29297] by server-9.bemta-5.messagelabs.com id
	48/97-24440-68F8F015; Mon, 04 Feb 2013 10:37:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1359974277!25312065!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29891 invoked from network); 4 Feb 2013 10:37:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:37:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1113103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:37: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.297.1; Mon, 4 Feb 2013
	10:37:57 +0000
Message-ID: <1359974276.5281.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 10:37:56 +0000
In-Reply-To: <20130204102331.GA6328@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130204102331.GA6328@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, 2013-02-04 at 10:23 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> > 
> > Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> > flag which makes it output something more suitable for logging,
> > e.g. ...10%...20%...30%... 
> > (or perhaps automatic based on isatty(outputfd)?)
> 
> I was thinking about that, to extend the called progress functions. In
> the case of xend.log it would produce many lines of progress.

How come many lines? I imaged the above as a single line.

> Since the default xend logging is limited to 1MB, the xend.log file
> would be rotated quickly and maybe useful logging output will be lost?
> 
> But for other callers of the progress functions it might be useful to
> have a parsable output so that they dont have to jump through the hoops.
> No idea if any caller makes use of the progress, given that it did not
> work at all without the other patch I sent last Friday.

xl migrate uses AFAIK, which isn't to say it wasn't broken ;-)

> 
> > > +    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
> > 
> > Might this fail and therefore require error handling?
> 
> If it fails then no logging will happen.

Which I suppose is better than failing the migration altogether.

> 
> > The lvl and lflags variables seem a bit useless to me.
> 
> They are there to keep the lines short

I would have done:
    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr,
                                        si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL,
                                        XTL_STDIOSTREAM_HIDE_PROGRESS);

But OK.

I think that addresses both of my questions, so
	Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I did mean to ask why the code had to move?

(I've been avoiding committing anything while we sort out the staging
backlog, and I seem to have a massive email backlog this morning to
boot, but this is in my queue)

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:43:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:43: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 1U2JWM-0002MX-Fy; Mon, 04 Feb 2013 10:43:30 +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 1U2JWK-0002MS-Rv
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 10:43:29 +0000
Received: from [193.109.254.147:31256] by server-7.bemta-14.messagelabs.com id
	97/38-13581-0D09F015; Mon, 04 Feb 2013 10:43:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1359974584!6699189!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28899 invoked from network); 4 Feb 2013 10:43:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1113323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:43: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.297.1; Mon, 4 Feb 2013
	10:43:04 +0000
Message-ID: <1359974582.5281.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 10:43:02 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
 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 Fri, 2013-02-01 at 20:15 +0000, Ross Philipson wrote:
> Switch libxl to use the new xc_hvm_build() libxc API.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> diff -r 27778b4099ba tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Fri Jan 25 15:04:11 2013 +0000
> +++ b/tools/libxl/libxl_dom.c   Fri Jan 25 13:37:55 2013 -0500
> @@ -542,17 +542,24 @@ int libxl__build_hvm(libxl__gc *gc, uint
>                libxl__domain_build_state *state)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> +    struct xc_hvm_build_args args = {};
>      int ret, rc = ERROR_FAIL;
>      const char *firmware = libxl__domain_firmware(gc, info);
>  
>      if (!firmware)
>          goto out;
> -    ret = xc_hvm_build_target_mem(
> -        ctx->xch,
> -        domid,
> -        (info->max_memkb - info->video_memkb) / 1024,
> -        (info->target_memkb - info->video_memkb) / 1024,
> -        firmware);
> +
> +    memset(&args, 0, sizeof(struct xc_hvm_build_args));
> +    /* The memory size names are misleading. The params are in Mb then
> +     * multiplied by 1 Kb.

What's misleading about max_memkb? It contains kb doesn't it? Likewise
the others.

The actual code in this patch looks good to me. Assuming I've remembered
the precedence of cast vs << correctly.

>  This was then divided off when calling
> +     * the old xc_hvm_build_target_mem() which then turned them to bytes.
> +     * Do all this in one step here...
> +     */
> +    args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
> +    args.mem_target = (uint64_t)(info->target_memkb - info->video_memkb) << 10;
> +    args.image_file_name = firmware;
> +
> +    ret = xc_hvm_build(ctx->xch, domid, &args);
>      if (ret) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building failed");
>          goto out; 


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:43:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10:43: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 1U2JWM-0002MX-Fy; Mon, 04 Feb 2013 10:43:30 +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 1U2JWK-0002MS-Rv
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 10:43:29 +0000
Received: from [193.109.254.147:31256] by server-7.bemta-14.messagelabs.com id
	97/38-13581-0D09F015; Mon, 04 Feb 2013 10:43:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1359974584!6699189!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28899 invoked from network); 4 Feb 2013 10:43:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1113323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:43: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.297.1; Mon, 4 Feb 2013
	10:43:04 +0000
Message-ID: <1359974582.5281.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 10:43:02 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
 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 Fri, 2013-02-01 at 20:15 +0000, Ross Philipson wrote:
> Switch libxl to use the new xc_hvm_build() libxc API.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> diff -r 27778b4099ba tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Fri Jan 25 15:04:11 2013 +0000
> +++ b/tools/libxl/libxl_dom.c   Fri Jan 25 13:37:55 2013 -0500
> @@ -542,17 +542,24 @@ int libxl__build_hvm(libxl__gc *gc, uint
>                libxl__domain_build_state *state)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> +    struct xc_hvm_build_args args = {};
>      int ret, rc = ERROR_FAIL;
>      const char *firmware = libxl__domain_firmware(gc, info);
>  
>      if (!firmware)
>          goto out;
> -    ret = xc_hvm_build_target_mem(
> -        ctx->xch,
> -        domid,
> -        (info->max_memkb - info->video_memkb) / 1024,
> -        (info->target_memkb - info->video_memkb) / 1024,
> -        firmware);
> +
> +    memset(&args, 0, sizeof(struct xc_hvm_build_args));
> +    /* The memory size names are misleading. The params are in Mb then
> +     * multiplied by 1 Kb.

What's misleading about max_memkb? It contains kb doesn't it? Likewise
the others.

The actual code in this patch looks good to me. Assuming I've remembered
the precedence of cast vs << correctly.

>  This was then divided off when calling
> +     * the old xc_hvm_build_target_mem() which then turned them to bytes.
> +     * Do all this in one step here...
> +     */
> +    args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
> +    args.mem_target = (uint64_t)(info->target_memkb - info->video_memkb) << 10;
> +    args.image_file_name = firmware;
> +
> +    ret = xc_hvm_build(ctx->xch, domid, &args);
>      if (ret) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building failed");
>          goto out; 


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:50:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JdI-0002VV-CK; Mon, 04 Feb 2013 10:50:40 +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 1U2JdH-0002VQ-00
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:50:39 +0000
Received: from [85.158.143.99:35389] by server-1.bemta-4.messagelabs.com id
	FF/96-08839-E729F015; Mon, 04 Feb 2013 10:50:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1359975008!23735514!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18599 invoked from network); 4 Feb 2013 10:50:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 10:50:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo44) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j045a3p14AWjOF ;
	Mon, 4 Feb 2013 11:50:08 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 81C8B1884C; Mon,  4 Feb 2013 11:50:07 +0100 (CET)
Date: Mon, 4 Feb 2013 11:50:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204105007.GA10728@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130204102331.GA6328@aepfle.de>
	<1359974276.5281.40.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359974276.5281.40.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, Feb 04, Ian Campbell wrote:

> On Mon, 2013-02-04 at 10:23 +0000, Olaf Hering wrote:
> > On Mon, Feb 04, Ian Campbell wrote:
> > 
> > > On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > > > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > > > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> > > 
> > > Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> > > flag which makes it output something more suitable for logging,
> > > e.g. ...10%...20%...30%... 
> > > (or perhaps automatic based on isatty(outputfd)?)
> > 
> > I was thinking about that, to extend the called progress functions. In
> > the case of xend.log it would produce many lines of progress.
> 
> How come many lines? I imaged the above as a single line.

Oh, I did not realize that we did not talk about
XTL_STDIOSTREAM_HIDE_PROGRESS but about another new flag.


> > No idea if any caller makes use of the progress, given that it did not
> > work at all without the other patch I sent last Friday.
> 
> xl migrate uses AFAIK, which isn't to say it wasn't broken ;-)

For me it was not printed without the patch in
<6d1d516ecaade56f796e.1359738924@probook.site>

> Although I did mean to ask why the code had to move?

To get to si.flags.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:50:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2JdI-0002VV-CK; Mon, 04 Feb 2013 10:50:40 +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 1U2JdH-0002VQ-00
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 10:50:39 +0000
Received: from [85.158.143.99:35389] by server-1.bemta-4.messagelabs.com id
	FF/96-08839-E729F015; Mon, 04 Feb 2013 10:50:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1359975008!23735514!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18599 invoked from network); 4 Feb 2013 10:50:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 10:50:15 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo44) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j045a3p14AWjOF ;
	Mon, 4 Feb 2013 11:50:08 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 81C8B1884C; Mon,  4 Feb 2013 11:50:07 +0100 (CET)
Date: Mon, 4 Feb 2013 11:50:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204105007.GA10728@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130204102331.GA6328@aepfle.de>
	<1359974276.5281.40.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359974276.5281.40.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, Feb 04, Ian Campbell wrote:

> On Mon, 2013-02-04 at 10:23 +0000, Olaf Hering wrote:
> > On Mon, Feb 04, Ian Campbell wrote:
> > 
> > > On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > > > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > > > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> > > 
> > > Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> > > flag which makes it output something more suitable for logging,
> > > e.g. ...10%...20%...30%... 
> > > (or perhaps automatic based on isatty(outputfd)?)
> > 
> > I was thinking about that, to extend the called progress functions. In
> > the case of xend.log it would produce many lines of progress.
> 
> How come many lines? I imaged the above as a single line.

Oh, I did not realize that we did not talk about
XTL_STDIOSTREAM_HIDE_PROGRESS but about another new flag.


> > No idea if any caller makes use of the progress, given that it did not
> > work at all without the other patch I sent last Friday.
> 
> xl migrate uses AFAIK, which isn't to say it wasn't broken ;-)

For me it was not printed without the patch in
<6d1d516ecaade56f796e.1359738924@probook.site>

> Although I did mean to ask why the code had to move?

To get to si.flags.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 10:57:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2Jk1-0002hR-Ar; Mon, 04 Feb 2013 10:57:37 +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 1U2Jk0-0002hM-3E
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 10:57:36 +0000
Received: from [85.158.138.51:9913] by server-1.bemta-3.messagelabs.com id
	B8/E4-08955-F149F015; Mon, 04 Feb 2013 10:57:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1359975451!22760908!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15608 invoked from network); 4 Feb 2013 10:57:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:57:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:57: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.297.1; Mon, 4 Feb 2013
	10:57:31 +0000
Message-ID: <1359975450.5281.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 10:57:30 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
 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 Fri, 2013-02-01 at 20:16 +0000, Ross Philipson wrote:
> This patch introduces support for two new parameters in libxl:
> 
> smbios_firmware=<path_to_smbios_structures_file>
> acpi_firmware=<path_to_acpi_tables_file>
> 
> The changes are primarily in the domain building code where the firmware files
> are read and passed to libxc for loading into the new guest. After the domain
> building call to libxc, the addresses for the loaded blobs are returned and
> written to xenstore.
> 
> LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users to
> determine if the feature is present.
>  
> This patch also updates the xl.cfg man page with descriptions of the two new
> parameters for firmware passthrough.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> diff -r 25b28b76fc68 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5     Fri Feb 01 10:20:25 2013 -0500
> +++ b/docs/man/xl.cfg.pod.5     Fri Feb 01 11:24:21 2013 -0500
> @@ -829,6 +829,25 @@ libxl: 'host,tm=0,sse3=0'
>  More info about the CPUID instruction can be found in the processor manuals, and
>  in Wikipedia: L<http://en.wikipedia.org/wiki/CPUID>
>  
> +=item B<acpi_firmware="STRING">
> +
> +Specify a path to a file that contains extra ACPI firmware tables to pass in to
> +a guest. The file can contain several tables in their binary AML form
> +concatenated together. Each table self describes its length so no additional
> +information is needed. These tables will be added to the ACPI table set in the
> +guest. Note that existing tables cannot be overriden by this feature. For

                                             "overridden"

(or is this a en_US vs en_GB thing?)

> +example this cannot be used to override tables like DSDT, FADT, etc.
> +
> +=item B<smbios_firmware="STRING">
> +
> +Specify a path to a file that contains extra SMBIOS firmware structures to pass
> +in to a guest. The file can contain a set DMTF predefined structures which will
> +override the internal defaults. Not all predefined structures can be overriden,

overridden again?

> +only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also contain any
> +number of vendor defined SMBIOS structures (type 128 - 255). Since SMBIOS
> +structures do not present their overall size, each entry in the file must be
> +preceeded by a 32b integer indicating the size of the next structure.

   preceded

> +
>  =back 
>  
>  =head3 Guest Virtual Time Controls
> diff -r 25b28b76fc68 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h       Fri Feb 01 10:20:25 2013 -0500
> +++ b/tools/libxl/libxl.h       Fri Feb 01 11:24:21 2013 -0500
> @@ -68,6 +68,13 @@
>   */
>  
>  /*
> + * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the new feature for

"new" now but not forever ;-)

(ok, maybe that's nit picking)

> + * passing in SMBIOS and ACPI firmware to HVM guests is present
> + * in the library.
> + */
> +#define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
> +
> +/*
>   * libxl ABI compatibility
>   *
>   * The only guarantee which libxl makes regarding ABI compatibility
> diff -r 25b28b76fc68 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Fri Feb 01 10:20:25 2013 -0500
> +++ b/tools/libxl/libxl_dom.c   Fri Feb 01 11:24:21 2013 -0500
> @@ -21,6 +21,7 @@
>  
>  #include <xc_dom.h>
>  #include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/hvm_xs_strings.h>
>  
>  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
>  {
> @@ -510,11 +511,61 @@ static int hvm_build_set_params(xc_inter
>      return 0;
>  }
>  
> -static const char *libxl__domain_firmware(libxl__gc *gc,
> -                                          libxl_domain_build_info *info)
> +static int hvm_build_set_xs_values(libxl__gc *gc,
> +                                   uint32_t domid,
> +                                   struct xc_hvm_build_args *args)
> +{
> +    char *path = NULL;
> +    int ret = 0;
> +
> +    if (args->smbios_module.guest_addr_out) {
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_ADDRESS, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> +                              args->smbios_module.guest_addr_out);
> +        if (ret)
> +            goto err;
> +
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_LENGTH, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> +                              args->smbios_module.length);
> +        if (ret)
> +            goto err;
> +    }
> +
> +    if (args->acpi_module.guest_addr_out) {
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> +                              args->acpi_module.guest_addr_out);
> +        if (ret)
> +            goto err;
> +
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> +                              args->acpi_module.length);
> +        if (ret)
> +            goto err;
> +    }
> +
> +    return 0;
> +
> +err:
> +    LOG(ERROR, "failed to write firmware xenstore value, err: %d", ret);
> +    return -1;

Why not propagate ret?

> +}
> +
> +static int libxl__domain_firmware(libxl__gc *gc,
> +                                  libxl_domain_build_info *info,
> +                                  struct xc_hvm_build_args *args)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      const char *firmware;
> +    int e, rc = ERROR_FAIL;
> +    int datalen = 0;
> +    void *data = 0;
>  
>      if (info->u.hvm.firmware)
>          firmware = info->u.hvm.firmware;
> @@ -528,13 +579,58 @@ static const char *libxl__domain_firmwar
>              firmware = "hvmloader";
>              break;
>          default:
> -            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
> -                       info->device_model_version);
> -            return NULL;
> +            LOG(ERROR, "invalid device model version %d",
> +                info->device_model_version);
> +            return -1;

I think this makes this function return a mixture of ERROR_* (via rc)
and -1? Likewise in a few other places. Using ERROR_* consistently would
be preferable I think.

>              break;
>          }
>      }
> -    return libxl__abs_path(gc, firmware, libxl__xenfirmwaredir_path());
> +    args->image_file_name = libxl__abs_path(gc, firmware,
> +                                            libxl__xenfirmwaredir_path());
> +    if (!args->image_file_name) {

I think the only way this can fail is memory allocation failure, which
you needn't worry about.

> +        LOG(ERROR, "invalid firmware path");
> +        return -1;
> +    }
> +
> +    if (info->u.hvm.smbios_firmware) {
> +        e = libxl_read_file_contents(ctx, info->u.hvm.smbios_firmware,
> +                                     &data, &datalen);
> +        if (e) {
> +            LOG(ERROR, "failed to read SMBIOS firmware file %s",
> +                info->u.hvm.smbios_firmware);

e here is an errno value (I think) so I think you could use LOGEV.

> +            goto out;
> +        }
> +        if (!datalen) {
> +            LOG(ERROR, "SMBIOS firmware file %s is empty",
> +                info->u.hvm.smbios_firmware);

I suppose passing an empty firmware file doesn't make much sense. It
does it mean that a caller who is generating the table needs to check if
it actually produced anything though, might be easier to silently accept
an empty table?

> +            goto out;
> +        }
> +        libxl__ptr_add(gc, data);
> +        args->smbios_module.data = data;
> +        args->smbios_module.length = (uint32_t)datalen;
> +    }
> +
> +    if (info->u.hvm.acpi_firmware) {
> +        e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
> +                                     &data, &datalen);
> +        if (e) {
> +            LOG(ERROR, "failed to read ACPI firmware file %s",
> +                info->u.hvm.acpi_firmware);

LOGEV again.

> +            goto out;
> +        }
> +        if (!datalen) {
> +            LOG(ERROR, "ACPI firmware file %s is empty",
> +                info->u.hvm.acpi_firmware);
> +            goto out;
> +        }
> +        libxl__ptr_add(gc, data);

I suppose adding libxl__read_file_contents(gc, ...) might be overkill?


> +        args->acpi_module.data = data;
> +        args->acpi_module.length = (uint32_t)datalen;
> +    }
> +
> +    return 0;
> +out:
> +    return rc;
>  }
>  
>  int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> @@ -557,22 +649,34 @@ int libxl__build_hvm(libxl__gc *gc, uint
[...]
>      ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>                                 &state->store_mfn, state->console_port,
>                                 &state->console_mfn, state->store_domid,
>                                 state->console_domid);
>      if (ret) {
> -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
> +        LOGEV(ERROR, ret, "hvm build set params failed");
>          goto out;
>      }
> -    rc = 0;
> +
> +    ret = hvm_build_set_xs_values(gc, domid, &args);
> +    if (ret) {
> +        LOGEV(ERROR, ret, "hvm build set xenstore values failed");

I'm not sure this guy actually returns an errnoval.

> +        goto out;
> +    }
> +
> +    return 0;
>  out:
>      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 Feb 04 10:57:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 10: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 1U2Jk1-0002hR-Ar; Mon, 04 Feb 2013 10:57:37 +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 1U2Jk0-0002hM-3E
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 10:57:36 +0000
Received: from [85.158.138.51:9913] by server-1.bemta-3.messagelabs.com id
	B8/E4-08955-F149F015; Mon, 04 Feb 2013 10:57:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1359975451!22760908!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15608 invoked from network); 4 Feb 2013 10:57:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 10:57:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 10:57: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.297.1; Mon, 4 Feb 2013
	10:57:31 +0000
Message-ID: <1359975450.5281.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 10:57:30 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
 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 Fri, 2013-02-01 at 20:16 +0000, Ross Philipson wrote:
> This patch introduces support for two new parameters in libxl:
> 
> smbios_firmware=<path_to_smbios_structures_file>
> acpi_firmware=<path_to_acpi_tables_file>
> 
> The changes are primarily in the domain building code where the firmware files
> are read and passed to libxc for loading into the new guest. After the domain
> building call to libxc, the addresses for the loaded blobs are returned and
> written to xenstore.
> 
> LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users to
> determine if the feature is present.
>  
> This patch also updates the xl.cfg man page with descriptions of the two new
> parameters for firmware passthrough.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> diff -r 25b28b76fc68 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5     Fri Feb 01 10:20:25 2013 -0500
> +++ b/docs/man/xl.cfg.pod.5     Fri Feb 01 11:24:21 2013 -0500
> @@ -829,6 +829,25 @@ libxl: 'host,tm=0,sse3=0'
>  More info about the CPUID instruction can be found in the processor manuals, and
>  in Wikipedia: L<http://en.wikipedia.org/wiki/CPUID>
>  
> +=item B<acpi_firmware="STRING">
> +
> +Specify a path to a file that contains extra ACPI firmware tables to pass in to
> +a guest. The file can contain several tables in their binary AML form
> +concatenated together. Each table self describes its length so no additional
> +information is needed. These tables will be added to the ACPI table set in the
> +guest. Note that existing tables cannot be overriden by this feature. For

                                             "overridden"

(or is this a en_US vs en_GB thing?)

> +example this cannot be used to override tables like DSDT, FADT, etc.
> +
> +=item B<smbios_firmware="STRING">
> +
> +Specify a path to a file that contains extra SMBIOS firmware structures to pass
> +in to a guest. The file can contain a set DMTF predefined structures which will
> +override the internal defaults. Not all predefined structures can be overriden,

overridden again?

> +only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also contain any
> +number of vendor defined SMBIOS structures (type 128 - 255). Since SMBIOS
> +structures do not present their overall size, each entry in the file must be
> +preceeded by a 32b integer indicating the size of the next structure.

   preceded

> +
>  =back 
>  
>  =head3 Guest Virtual Time Controls
> diff -r 25b28b76fc68 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h       Fri Feb 01 10:20:25 2013 -0500
> +++ b/tools/libxl/libxl.h       Fri Feb 01 11:24:21 2013 -0500
> @@ -68,6 +68,13 @@
>   */
>  
>  /*
> + * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the new feature for

"new" now but not forever ;-)

(ok, maybe that's nit picking)

> + * passing in SMBIOS and ACPI firmware to HVM guests is present
> + * in the library.
> + */
> +#define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
> +
> +/*
>   * libxl ABI compatibility
>   *
>   * The only guarantee which libxl makes regarding ABI compatibility
> diff -r 25b28b76fc68 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c   Fri Feb 01 10:20:25 2013 -0500
> +++ b/tools/libxl/libxl_dom.c   Fri Feb 01 11:24:21 2013 -0500
> @@ -21,6 +21,7 @@
>  
>  #include <xc_dom.h>
>  #include <xen/hvm/hvm_info_table.h>
> +#include <xen/hvm/hvm_xs_strings.h>
>  
>  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
>  {
> @@ -510,11 +511,61 @@ static int hvm_build_set_params(xc_inter
>      return 0;
>  }
>  
> -static const char *libxl__domain_firmware(libxl__gc *gc,
> -                                          libxl_domain_build_info *info)
> +static int hvm_build_set_xs_values(libxl__gc *gc,
> +                                   uint32_t domid,
> +                                   struct xc_hvm_build_args *args)
> +{
> +    char *path = NULL;
> +    int ret = 0;
> +
> +    if (args->smbios_module.guest_addr_out) {
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_ADDRESS, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> +                              args->smbios_module.guest_addr_out);
> +        if (ret)
> +            goto err;
> +
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_LENGTH, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> +                              args->smbios_module.length);
> +        if (ret)
> +            goto err;
> +    }
> +
> +    if (args->acpi_module.guest_addr_out) {
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> +                              args->acpi_module.guest_addr_out);
> +        if (ret)
> +            goto err;
> +
> +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
> +
> +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> +                              args->acpi_module.length);
> +        if (ret)
> +            goto err;
> +    }
> +
> +    return 0;
> +
> +err:
> +    LOG(ERROR, "failed to write firmware xenstore value, err: %d", ret);
> +    return -1;

Why not propagate ret?

> +}
> +
> +static int libxl__domain_firmware(libxl__gc *gc,
> +                                  libxl_domain_build_info *info,
> +                                  struct xc_hvm_build_args *args)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      const char *firmware;
> +    int e, rc = ERROR_FAIL;
> +    int datalen = 0;
> +    void *data = 0;
>  
>      if (info->u.hvm.firmware)
>          firmware = info->u.hvm.firmware;
> @@ -528,13 +579,58 @@ static const char *libxl__domain_firmwar
>              firmware = "hvmloader";
>              break;
>          default:
> -            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
> -                       info->device_model_version);
> -            return NULL;
> +            LOG(ERROR, "invalid device model version %d",
> +                info->device_model_version);
> +            return -1;

I think this makes this function return a mixture of ERROR_* (via rc)
and -1? Likewise in a few other places. Using ERROR_* consistently would
be preferable I think.

>              break;
>          }
>      }
> -    return libxl__abs_path(gc, firmware, libxl__xenfirmwaredir_path());
> +    args->image_file_name = libxl__abs_path(gc, firmware,
> +                                            libxl__xenfirmwaredir_path());
> +    if (!args->image_file_name) {

I think the only way this can fail is memory allocation failure, which
you needn't worry about.

> +        LOG(ERROR, "invalid firmware path");
> +        return -1;
> +    }
> +
> +    if (info->u.hvm.smbios_firmware) {
> +        e = libxl_read_file_contents(ctx, info->u.hvm.smbios_firmware,
> +                                     &data, &datalen);
> +        if (e) {
> +            LOG(ERROR, "failed to read SMBIOS firmware file %s",
> +                info->u.hvm.smbios_firmware);

e here is an errno value (I think) so I think you could use LOGEV.

> +            goto out;
> +        }
> +        if (!datalen) {
> +            LOG(ERROR, "SMBIOS firmware file %s is empty",
> +                info->u.hvm.smbios_firmware);

I suppose passing an empty firmware file doesn't make much sense. It
does it mean that a caller who is generating the table needs to check if
it actually produced anything though, might be easier to silently accept
an empty table?

> +            goto out;
> +        }
> +        libxl__ptr_add(gc, data);
> +        args->smbios_module.data = data;
> +        args->smbios_module.length = (uint32_t)datalen;
> +    }
> +
> +    if (info->u.hvm.acpi_firmware) {
> +        e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
> +                                     &data, &datalen);
> +        if (e) {
> +            LOG(ERROR, "failed to read ACPI firmware file %s",
> +                info->u.hvm.acpi_firmware);

LOGEV again.

> +            goto out;
> +        }
> +        if (!datalen) {
> +            LOG(ERROR, "ACPI firmware file %s is empty",
> +                info->u.hvm.acpi_firmware);
> +            goto out;
> +        }
> +        libxl__ptr_add(gc, data);

I suppose adding libxl__read_file_contents(gc, ...) might be overkill?


> +        args->acpi_module.data = data;
> +        args->acpi_module.length = (uint32_t)datalen;
> +    }
> +
> +    return 0;
> +out:
> +    return rc;
>  }
>  
>  int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> @@ -557,22 +649,34 @@ int libxl__build_hvm(libxl__gc *gc, uint
[...]
>      ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>                                 &state->store_mfn, state->console_port,
>                                 &state->console_mfn, state->store_domid,
>                                 state->console_domid);
>      if (ret) {
> -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
> +        LOGEV(ERROR, ret, "hvm build set params failed");
>          goto out;
>      }
> -    rc = 0;
> +
> +    ret = hvm_build_set_xs_values(gc, domid, &args);
> +    if (ret) {
> +        LOGEV(ERROR, ret, "hvm build set xenstore values failed");

I'm not sure this guy actually returns an errnoval.

> +        goto out;
> +    }
> +
> +    return 0;
>  out:
>      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 Feb 04 11:03:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:03: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 1U2JpY-0002w3-Cf; Mon, 04 Feb 2013 11:03:20 +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 1U2JpW-0002vx-LV
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:03:19 +0000
Received: from [85.158.137.99:15411] by server-16.bemta-3.messagelabs.com id
	63/8D-02727-5759F015; Mon, 04 Feb 2013 11:03:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1359975731!16683096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3244 invoked from network); 4 Feb 2013 11:02:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 11:02:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 11:02:11 +0000
Message-Id: <510FA33F02000078000BB71D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 11:02:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
In-Reply-To: <20130131170718.GB19350@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9CACCF3F.1__="
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part9CACCF3F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 31.01.13 at 18:07, Olaf Hering <olaf@aepfle.de> wrote:

> xenctx output:

I'm confused by this: For one, the mere fact that
hpet_rtc_interrupt() is in use suggests that the kernel uses
RTC emulation (and hence wouldn't depend on any of the
RTC registers we emulate to be set correctly). The only issue
then could be that we're raising way too many IRQ8-s.

While that could explain hangs (due to the IRQ getting shut off
by the kernel), has two other inconsistencies in itself:

(a) hpet_rtc_interrupt() unconditionally returns IRQ_HANDLED,
and hence the interrupt should never be regarded as spurious
by the kernel (and hence never be shut off).

(b) Once turned off (which we see happening in the kernel log
you posted subsequently), hpet_rtc_interrupt() cannot possibly
get onto the call stack at all anymore, hence a hang _here_ is
impossible.

So one question to you would be to clarify which hangs you see
where under what conditions (I'm particularly unclear about the
exact difference in behavior that you observe with xend vs xl).

And then there is a problem with the xenctx output below,
assuming they were taken subsequently on the same guest
instance while in that hung state:

> ...
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
>=20
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
>=20
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
>=20
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
> ...

One of the vCPU-s (presumably vCPU0, but that doesn't really
matter) has an _invariant_ register state, yet the loop it's in
guarantees at least %ebx to change on each iteration (and
one would expect %eax to change too). Which would imply
the guest isn't making forward progress at all anymore. With
interrupts being disabled during that code sequence, this also
can't mean the guest is completely busy servicing interrupts - it
must be getting no execution time anymore. Which in turn would
mean either the vCPU is no longer in running state, or Xen itself
is hung. As you didn't indicate the latter, could you check the
former?

Finally, while I don't see a connection (namely because I don't
think periodic interrupts would be in use by the guest here, which
is what this change to a large part revolves around), you might
nevertheless want to try to apply the last outstanding change
(attached) as an alternative to reverting.

Jan

--=__Part9CACCF3F.1__=
Content-Type: text/plain; name="x86-HVM-RTC.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-RTC.patch"

x86/HVM: assorted RTC emulation adjustments=0A=0A- only call check_update_t=
imer() on REG_B writes when SET changes=0A- only call alarm_timer_update() =
on REG_B writes when relevant bits=0A  change=0A- instead properly handle =
AF and PF when the guest is not also setting=0A  AIE/PIE respectively (for =
UF this was already the case, only a=0A  comment was slightly inaccurate), =
including calling the respective=0A  update functions upon REG_C =
reads=0A=0A--- a/xen/arch/x86/hvm/rtc.c=0A+++ b/xen/arch/x86/hvm/rtc.c=0A@@=
 -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState *s)=0A     hvm_isa_ir=
q_assert(d, RTC_IRQ);=0A }=0A =0A-static void rtc_periodic_cb(struct vcpu =
*v, void *opaque)=0A+void rtc_periodic_interrupt(void *opaque)=0A {=0A     =
RTCState *s =3D opaque;=0A =0A     spin_lock(&s->lock);=0A-    s->hw.cmos_d=
ata[RTC_REG_C] |=3D RTC_PF | RTC_IRQF;=0A+    if ( s->hw.cmos_data[RTC_REG_=
C] & RTC_PF )=0A+        destroy_periodic_time(&s->pt);=0A+    else=0A+    =
{=0A+        s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;=0A+        if ( =
s->hw.cmos_data[RTC_REG_B] & RTC_PIE )=0A+            rtc_toggle_irq(s);=0A=
+    }=0A     spin_unlock(&s->lock);=0A }=0A =0A@@ -91,8 +98,7 @@ static =
void rtc_timer_update(RTCState *s=0A         {=0A             period =3D 1 =
<< (period_code - 1); /* period in 32 Khz cycles */=0A             period =
=3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */=0A-            =
create_periodic_time(v, &s->pt, period, period, RTC_IRQ,=0A-               =
                  rtc_periodic_cb, s);=0A+            create_periodic_time(=
v, &s->pt, period, period, RTC_IRQ, NULL, s);=0A             break;=0A     =
    }=0A         /* fall through */=0A@@ -120,7 +126,7 @@ static void =
check_update_timer(RTCState =0A         guest_usec =3D get_localtime_us(d) =
% USEC_PER_SEC;=0A         if (guest_usec >=3D (USEC_PER_SEC - 244))=0A    =
     {=0A-            /* RTC is in update cycle when enabling UIE */=0A+   =
         /* RTC is in update cycle */=0A             s->hw.cmos_data[RTC_RE=
G_A] |=3D RTC_UIP;=0A             next_update_time =3D (USEC_PER_SEC - =
guest_usec) * NS_PER_USEC;=0A             expire_time =3D NOW() + =
next_update_time;=0A@@ -188,7 +194,7 @@ static void alarm_timer_update(RTCS=
tate =0A =0A     stop_timer(&s->alarm_timer);=0A =0A-    if ((s->hw.cmos_da=
ta[RTC_REG_B] & RTC_AIE) &&=0A+    if (!(s->hw.cmos_data[RTC_REG_C] & =
RTC_AF) &&=0A             !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A     =
{=0A         s->current_tm =3D gmtime(get_localtime(d));=0A@@ -455,8 =
+461,10 @@ static int rtc_ioport_write(void *opaque=0A                 =
break;=0A             }=0A         s->hw.cmos_data[RTC_REG_B] =3D =
data;=0A-        check_update_timer(s);=0A-        alarm_timer_update(s);=
=0A+        if ( (data ^ orig) & RTC_SET )=0A+            check_update_time=
r(s);=0A+        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) =
)=0A+            alarm_timer_update(s);=0A         break;=0A     case =
RTC_REG_C:=0A     case RTC_REG_D:=0A@@ -610,6 +618,8 @@ static uint32_t =
rtc_ioport_read(RTCState=0A         hvm_isa_irq_deassert(vrtc_domain(s), =
RTC_IRQ);=0A         s->hw.cmos_data[RTC_REG_C] =3D 0x00;=0A         =
check_update_timer(s);=0A+        alarm_timer_update(s);=0A+        =
rtc_timer_update(s);=0A         break;=0A     default:=0A         ret =3D =
s->hw.cmos_data[s->hw.cmos_index];=0A--- a/xen/arch/x86/hvm/vpt.c=0A+++ =
b/xen/arch/x86/hvm/vpt.c=0A@@ -22,6 +22,7 @@=0A #include <asm/hvm/vpt.h>=0A=
 #include <asm/event.h>=0A #include <asm/apic.h>=0A+#include <asm/mc146818r=
tc.h>=0A =0A #define mode_is(d, name) \=0A     ((d)->arch.hvm_domain.params=
[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##name)=0A@@ -218,6 +219,7 @@ int =
pt_update_irq(struct vcpu *v)=0A     struct periodic_time *pt, *temp, =
*earliest_pt =3D NULL;=0A     uint64_t max_lag =3D -1ULL;=0A     int irq, =
is_lapic;=0A+    void *pt_priv;=0A =0A     spin_lock(&v->arch.hvm_vcpu.tm_l=
ock);=0A =0A@@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu *v)=0A     =
earliest_pt->irq_issued =3D 1;=0A     irq =3D earliest_pt->irq;=0A     =
is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);=0A+    pt_priv =3D =
earliest_pt->priv;=0A =0A     spin_unlock(&v->arch.hvm_vcpu.tm_lock);=0A =
=0A     if ( is_lapic )=0A-    {=0A         vlapic_set_irq(vcpu_vlapic(v), =
irq, 0);=0A-    }=0A+    else if ( irq =3D=3D RTC_IRQ && pt_priv )=0A+     =
   rtc_periodic_interrupt(pt_priv);=0A     else=0A     {=0A         =
hvm_isa_irq_deassert(v->domain, irq);=0A--- a/xen/include/asm-x86/hvm/vpt.h=
=0A+++ b/xen/include/asm-x86/hvm/vpt.h=0A@@ -181,6 +181,7 @@ void =
rtc_migrate_timers(struct vcpu *v);=0A void rtc_deinit(struct domain =
*d);=0A void rtc_reset(struct domain *d);=0A void rtc_update_clock(struct =
domain *d);=0A+void rtc_periodic_interrupt(void *);=0A =0A void pmtimer_ini=
t(struct vcpu *v);=0A void pmtimer_deinit(struct domain *d);=0A
--=__Part9CACCF3F.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

--=__Part9CACCF3F.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 04 11:03:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:03: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 1U2JpY-0002w3-Cf; Mon, 04 Feb 2013 11:03:20 +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 1U2JpW-0002vx-LV
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:03:19 +0000
Received: from [85.158.137.99:15411] by server-16.bemta-3.messagelabs.com id
	63/8D-02727-5759F015; Mon, 04 Feb 2013 11:03:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1359975731!16683096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3244 invoked from network); 4 Feb 2013 11:02:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 11:02:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 11:02:11 +0000
Message-Id: <510FA33F02000078000BB71D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 11:02:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
In-Reply-To: <20130131170718.GB19350@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9CACCF3F.1__="
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part9CACCF3F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 31.01.13 at 18:07, Olaf Hering <olaf@aepfle.de> wrote:

> xenctx output:

I'm confused by this: For one, the mere fact that
hpet_rtc_interrupt() is in use suggests that the kernel uses
RTC emulation (and hence wouldn't depend on any of the
RTC registers we emulate to be set correctly). The only issue
then could be that we're raising way too many IRQ8-s.

While that could explain hangs (due to the IRQ getting shut off
by the kernel), has two other inconsistencies in itself:

(a) hpet_rtc_interrupt() unconditionally returns IRQ_HANDLED,
and hence the interrupt should never be regarded as spurious
by the kernel (and hence never be shut off).

(b) Once turned off (which we see happening in the kernel log
you posted subsequently), hpet_rtc_interrupt() cannot possibly
get onto the call stack at all anymore, hence a hang _here_ is
impossible.

So one question to you would be to clarify which hangs you see
where under what conditions (I'm particularly unclear about the
exact difference in behavior that you observe with xend vs xl).

And then there is a problem with the xenctx output below,
assuming they were taken subsequently on the same guest
instance while in that hung state:

> ...
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
>=20
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
>=20
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
>=20
> rip: ffffffff81034b97 hpet_rtc_interrupt+0x97
> flags: 00000086 s nz p
> rsp: ffff88001b003df8
> rax: 00000000bc004a66   rcx: 00000000000ee6b2   rdx: 00000000ba6b145a
> rbx: 000000000000087d   rsi: ffff88001aec5000   rdi: 0000000000000008
> rbp: ffff88001b003e68    r8: ffff88001ac06800    r9: ffff88001b003e38
> r10: 000000000000008c   r11: 000000000000f800   r12: ffff88001ac06884
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000008
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b000000/0000000000000000
> Code (instr addr ffffffff81034b97)
> 00 89 10 48 8b 05 74 da d0 00 83 c3 01 48 05 f0 00 00 00 8b 00 <3b> 05 =
d3 da=20
> d0 00 79 c9 85 db 74
>=20
>=20
> Stack:
>  ffff88001b003e68 ffff88001aec5000 0000000000000000 0000000800000000
>  ffff88001ad49c68 0000000000000000 00000008156570c6 ffffffff8165e9cc
>  ffff88001b0125c0 ffff880019278480 ffff88001ac06884 0000000000000000
>  0000000000000000 0000000000000008 ffff88001b003eb8 ffffffff8109aa2b
>=20
> Call Trace:
>   [<ffffffff81034b97>] hpet_rtc_interrupt+0x97  <--
>   [<ffffffff8165e9cc>] _raw_spin_unlock_irqrestore+0xc
>   [<ffffffff8109aa2b>] handle_irq_event_percpu+0x4b
>   [<ffffffff8109ab8c>] handle_irq_event+0x3c
>   [<ffffffff8109d79d>] handle_edge_irq+0x6d
>   [<ffffffff8142b474>] __xen_evtchn_do_upcall+0x1a4
>   [<ffffffff8142ca6a>] xen_evtchn_do_upcall+0x2a
>   [<ffffffff81660aad>] xen_hvm_callback_vector+0x6d
> rip: ffffffff810360d6 native_safe_halt+0x6
> flags: 00000246 i z p
> rsp: ffff88001acbdef8
> rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
> rbx: ffff88001acbc010   rsi: 0140000000000000   rdi: 0000000000000086
> rbp: ffff88001acbdef8    r8: 0000000000000000    r9: 0000000000000000
> r10: 0000000000000001   r11: 0000000000000000   r12: ffffffff81c62330
> r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cs: 0010        ss: 0018        ds: 0000        es: 0000
>  fs: 0000 @ 0000000000000000
>  gs: 0000 @ ffff88001b040000/0000000000000000
> Code (instr addr ffffffff810360d6)
> 48 89 e5 fb c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <c9> c3 =
0f 1f=20
> 84 00 00 00 00 00 55
>=20
>=20
> Stack:
>  ffff88001acbdf08 ffffffff81014735 ffff88001acbdf28 ffffffff81014a68
>  0000000000000001 0000000000000000 ffff88001acbdf48 ffffffff8165824a
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>=20
> Call Trace:
>   [<ffffffff810360d6>] native_safe_halt+0x6  <--
>   [<ffffffff81014735>] default_idle+0x45
>   [<ffffffff81014a68>] cpu_idle+0x88
>   [<ffffffff8165824a>] start_secondary+0x188
> ...

One of the vCPU-s (presumably vCPU0, but that doesn't really
matter) has an _invariant_ register state, yet the loop it's in
guarantees at least %ebx to change on each iteration (and
one would expect %eax to change too). Which would imply
the guest isn't making forward progress at all anymore. With
interrupts being disabled during that code sequence, this also
can't mean the guest is completely busy servicing interrupts - it
must be getting no execution time anymore. Which in turn would
mean either the vCPU is no longer in running state, or Xen itself
is hung. As you didn't indicate the latter, could you check the
former?

Finally, while I don't see a connection (namely because I don't
think periodic interrupts would be in use by the guest here, which
is what this change to a large part revolves around), you might
nevertheless want to try to apply the last outstanding change
(attached) as an alternative to reverting.

Jan

--=__Part9CACCF3F.1__=
Content-Type: text/plain; name="x86-HVM-RTC.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-RTC.patch"

x86/HVM: assorted RTC emulation adjustments=0A=0A- only call check_update_t=
imer() on REG_B writes when SET changes=0A- only call alarm_timer_update() =
on REG_B writes when relevant bits=0A  change=0A- instead properly handle =
AF and PF when the guest is not also setting=0A  AIE/PIE respectively (for =
UF this was already the case, only a=0A  comment was slightly inaccurate), =
including calling the respective=0A  update functions upon REG_C =
reads=0A=0A--- a/xen/arch/x86/hvm/rtc.c=0A+++ b/xen/arch/x86/hvm/rtc.c=0A@@=
 -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState *s)=0A     hvm_isa_ir=
q_assert(d, RTC_IRQ);=0A }=0A =0A-static void rtc_periodic_cb(struct vcpu =
*v, void *opaque)=0A+void rtc_periodic_interrupt(void *opaque)=0A {=0A     =
RTCState *s =3D opaque;=0A =0A     spin_lock(&s->lock);=0A-    s->hw.cmos_d=
ata[RTC_REG_C] |=3D RTC_PF | RTC_IRQF;=0A+    if ( s->hw.cmos_data[RTC_REG_=
C] & RTC_PF )=0A+        destroy_periodic_time(&s->pt);=0A+    else=0A+    =
{=0A+        s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;=0A+        if ( =
s->hw.cmos_data[RTC_REG_B] & RTC_PIE )=0A+            rtc_toggle_irq(s);=0A=
+    }=0A     spin_unlock(&s->lock);=0A }=0A =0A@@ -91,8 +98,7 @@ static =
void rtc_timer_update(RTCState *s=0A         {=0A             period =3D 1 =
<< (period_code - 1); /* period in 32 Khz cycles */=0A             period =
=3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */=0A-            =
create_periodic_time(v, &s->pt, period, period, RTC_IRQ,=0A-               =
                  rtc_periodic_cb, s);=0A+            create_periodic_time(=
v, &s->pt, period, period, RTC_IRQ, NULL, s);=0A             break;=0A     =
    }=0A         /* fall through */=0A@@ -120,7 +126,7 @@ static void =
check_update_timer(RTCState =0A         guest_usec =3D get_localtime_us(d) =
% USEC_PER_SEC;=0A         if (guest_usec >=3D (USEC_PER_SEC - 244))=0A    =
     {=0A-            /* RTC is in update cycle when enabling UIE */=0A+   =
         /* RTC is in update cycle */=0A             s->hw.cmos_data[RTC_RE=
G_A] |=3D RTC_UIP;=0A             next_update_time =3D (USEC_PER_SEC - =
guest_usec) * NS_PER_USEC;=0A             expire_time =3D NOW() + =
next_update_time;=0A@@ -188,7 +194,7 @@ static void alarm_timer_update(RTCS=
tate =0A =0A     stop_timer(&s->alarm_timer);=0A =0A-    if ((s->hw.cmos_da=
ta[RTC_REG_B] & RTC_AIE) &&=0A+    if (!(s->hw.cmos_data[RTC_REG_C] & =
RTC_AF) &&=0A             !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A     =
{=0A         s->current_tm =3D gmtime(get_localtime(d));=0A@@ -455,8 =
+461,10 @@ static int rtc_ioport_write(void *opaque=0A                 =
break;=0A             }=0A         s->hw.cmos_data[RTC_REG_B] =3D =
data;=0A-        check_update_timer(s);=0A-        alarm_timer_update(s);=
=0A+        if ( (data ^ orig) & RTC_SET )=0A+            check_update_time=
r(s);=0A+        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) =
)=0A+            alarm_timer_update(s);=0A         break;=0A     case =
RTC_REG_C:=0A     case RTC_REG_D:=0A@@ -610,6 +618,8 @@ static uint32_t =
rtc_ioport_read(RTCState=0A         hvm_isa_irq_deassert(vrtc_domain(s), =
RTC_IRQ);=0A         s->hw.cmos_data[RTC_REG_C] =3D 0x00;=0A         =
check_update_timer(s);=0A+        alarm_timer_update(s);=0A+        =
rtc_timer_update(s);=0A         break;=0A     default:=0A         ret =3D =
s->hw.cmos_data[s->hw.cmos_index];=0A--- a/xen/arch/x86/hvm/vpt.c=0A+++ =
b/xen/arch/x86/hvm/vpt.c=0A@@ -22,6 +22,7 @@=0A #include <asm/hvm/vpt.h>=0A=
 #include <asm/event.h>=0A #include <asm/apic.h>=0A+#include <asm/mc146818r=
tc.h>=0A =0A #define mode_is(d, name) \=0A     ((d)->arch.hvm_domain.params=
[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##name)=0A@@ -218,6 +219,7 @@ int =
pt_update_irq(struct vcpu *v)=0A     struct periodic_time *pt, *temp, =
*earliest_pt =3D NULL;=0A     uint64_t max_lag =3D -1ULL;=0A     int irq, =
is_lapic;=0A+    void *pt_priv;=0A =0A     spin_lock(&v->arch.hvm_vcpu.tm_l=
ock);=0A =0A@@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu *v)=0A     =
earliest_pt->irq_issued =3D 1;=0A     irq =3D earliest_pt->irq;=0A     =
is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);=0A+    pt_priv =3D =
earliest_pt->priv;=0A =0A     spin_unlock(&v->arch.hvm_vcpu.tm_lock);=0A =
=0A     if ( is_lapic )=0A-    {=0A         vlapic_set_irq(vcpu_vlapic(v), =
irq, 0);=0A-    }=0A+    else if ( irq =3D=3D RTC_IRQ && pt_priv )=0A+     =
   rtc_periodic_interrupt(pt_priv);=0A     else=0A     {=0A         =
hvm_isa_irq_deassert(v->domain, irq);=0A--- a/xen/include/asm-x86/hvm/vpt.h=
=0A+++ b/xen/include/asm-x86/hvm/vpt.h=0A@@ -181,6 +181,7 @@ void =
rtc_migrate_timers(struct vcpu *v);=0A void rtc_deinit(struct domain =
*d);=0A void rtc_reset(struct domain *d);=0A void rtc_update_clock(struct =
domain *d);=0A+void rtc_periodic_interrupt(void *);=0A =0A void pmtimer_ini=
t(struct vcpu *v);=0A void pmtimer_deinit(struct domain *d);=0A
--=__Part9CACCF3F.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

--=__Part9CACCF3F.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 04 11:04:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11: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 1U2JqE-0002yX-6q; Mon, 04 Feb 2013 11:04: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 1U2JqB-0002yI-Ho
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:03:59 +0000
Received: from [85.158.139.83:3290] by server-9.bemta-5.messagelabs.com id
	A2/9D-24440-E959F015; Mon, 04 Feb 2013 11:03:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1359975838!28321369!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10600 invoked from network); 4 Feb 2013 11:03:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:03: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.297.1; Mon, 4 Feb 2013
	11:03:58 +0000
Message-ID: <1359975836.5281.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 11:03:56 +0000
In-Reply-To: <20130204105007.GA10728@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130204102331.GA6328@aepfle.de>
	<1359974276.5281.40.camel@zakaz.uk.xensource.com>
	<20130204105007.GA10728@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, 2013-02-04 at 10:50 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 10:23 +0000, Olaf Hering wrote:
> > > On Mon, Feb 04, Ian Campbell wrote:
> > > 
> > > > On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > > > > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > > > > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> > > > 
> > > > Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> > > > flag which makes it output something more suitable for logging,
> > > > e.g. ...10%...20%...30%... 
> > > > (or perhaps automatic based on isatty(outputfd)?)
> > > 
> > > I was thinking about that, to extend the called progress functions. In
> > > the case of xend.log it would produce many lines of progress.
> > 
> > How come many lines? I imaged the above as a single line.
> 
> Oh, I did not realize that we did not talk about
> XTL_STDIOSTREAM_HIDE_PROGRESS but about another new flag.

Right, or perhaps changing the behaviour of the !HIDE_PROGRESS flag
based on isatty, which would also perhaps fix the ugliness here:
http://www.chiark.greenend.org.uk/~xensrcts/logs/15367/test-amd64-amd64-xl/11.ts-guest-localmigrate.log
(not a big deal though)

> 
> 
> > > No idea if any caller makes use of the progress, given that it did not
> > > work at all without the other patch I sent last Friday.
> > 
> > xl migrate uses AFAIK, which isn't to say it wasn't broken ;-)
> 
> For me it was not printed without the patch in
> <6d1d516ecaade56f796e.1359738924@probook.site>

I guess this is in my queue somewhere, I'll take a look.

> > Although I did mean to ask why the code had to move?
> 
> To get to si.flags.

A-ha!

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 Feb 04 11:04:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11: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 1U2JqE-0002yX-6q; Mon, 04 Feb 2013 11:04: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 1U2JqB-0002yI-Ho
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:03:59 +0000
Received: from [85.158.139.83:3290] by server-9.bemta-5.messagelabs.com id
	A2/9D-24440-E959F015; Mon, 04 Feb 2013 11:03:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1359975838!28321369!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10600 invoked from network); 4 Feb 2013 11:03:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:03: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.297.1; Mon, 4 Feb 2013
	11:03:58 +0000
Message-ID: <1359975836.5281.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 11:03:56 +0000
In-Reply-To: <20130204105007.GA10728@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130204102331.GA6328@aepfle.de>
	<1359974276.5281.40.camel@zakaz.uk.xensource.com>
	<20130204105007.GA10728@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, 2013-02-04 at 10:50 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 10:23 +0000, Olaf Hering wrote:
> > > On Mon, Feb 04, Ian Campbell wrote:
> > > 
> > > > On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > > > > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > > > > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> > > > 
> > > > Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> > > > flag which makes it output something more suitable for logging,
> > > > e.g. ...10%...20%...30%... 
> > > > (or perhaps automatic based on isatty(outputfd)?)
> > > 
> > > I was thinking about that, to extend the called progress functions. In
> > > the case of xend.log it would produce many lines of progress.
> > 
> > How come many lines? I imaged the above as a single line.
> 
> Oh, I did not realize that we did not talk about
> XTL_STDIOSTREAM_HIDE_PROGRESS but about another new flag.

Right, or perhaps changing the behaviour of the !HIDE_PROGRESS flag
based on isatty, which would also perhaps fix the ugliness here:
http://www.chiark.greenend.org.uk/~xensrcts/logs/15367/test-amd64-amd64-xl/11.ts-guest-localmigrate.log
(not a big deal though)

> 
> 
> > > No idea if any caller makes use of the progress, given that it did not
> > > work at all without the other patch I sent last Friday.
> > 
> > xl migrate uses AFAIK, which isn't to say it wasn't broken ;-)
> 
> For me it was not printed without the patch in
> <6d1d516ecaade56f796e.1359738924@probook.site>

I guess this is in my queue somewhere, I'll take a look.

> > Although I did mean to ask why the code had to move?
> 
> To get to si.flags.

A-ha!

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 Feb 04 11:05:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:05: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 1U2Jr9-00033g-Mt; Mon, 04 Feb 2013 11:04:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2Jr8-00033S-MC
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:04:58 +0000
Received: from [85.158.143.99:7369] by server-2.bemta-4.messagelabs.com id
	0C/11-01597-9D59F015; Mon, 04 Feb 2013 11:04:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359975896!29176680!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14305 invoked from network); 4 Feb 2013 11:04:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:04:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:04: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.297.1; Mon, 4 Feb 2013
	11:04:56 +0000
Message-ID: <1359975895.5281.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 11:04:55 +0000
In-Reply-To: <6d1d516ecaade56f796e.1359738924@probook.site>
References: <6d1d516ecaade56f796e.1359738924@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: fix logic error in
 stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 17:15 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359738883 -3600
> # Node ID 6d1d516ecaade56f796e3216e9931fdcc12282cd
> # Parent  6727070b4129cf852199b66b6a81042ee6966a98
> tools/xc: fix logic error in stdiostream_progress
> 
> Setting XTL_STDIOSTREAM_HIDE_PROGRESS should disable progress reporting,
> instead of not setting it.

Oops!

> Signed-off-by: Olaf Hering <olaf@aepfle.de>

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

> 
> diff -r 6727070b4129 -r 6d1d516ecaad tools/libxc/xtl_logger_stdio.c
> --- a/tools/libxc/xtl_logger_stdio.c
> +++ b/tools/libxc/xtl_logger_stdio.c
> @@ -89,7 +89,7 @@ static void stdiostream_progress(struct 
>      int newpel, extra_erase;
>      xentoollog_level this_level;
>  
> -    if (!(lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS))
> +    if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
>          return;
>  
>      if (percent < lg->progress_last_percent) {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 11:05:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:05: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 1U2Jr9-00033g-Mt; Mon, 04 Feb 2013 11:04:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2Jr8-00033S-MC
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:04:58 +0000
Received: from [85.158.143.99:7369] by server-2.bemta-4.messagelabs.com id
	0C/11-01597-9D59F015; Mon, 04 Feb 2013 11:04:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359975896!29176680!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14305 invoked from network); 4 Feb 2013 11:04:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:04:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:04: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.297.1; Mon, 4 Feb 2013
	11:04:56 +0000
Message-ID: <1359975895.5281.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 11:04:55 +0000
In-Reply-To: <6d1d516ecaade56f796e.1359738924@probook.site>
References: <6d1d516ecaade56f796e.1359738924@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: fix logic error in
 stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 17:15 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359738883 -3600
> # Node ID 6d1d516ecaade56f796e3216e9931fdcc12282cd
> # Parent  6727070b4129cf852199b66b6a81042ee6966a98
> tools/xc: fix logic error in stdiostream_progress
> 
> Setting XTL_STDIOSTREAM_HIDE_PROGRESS should disable progress reporting,
> instead of not setting it.

Oops!

> Signed-off-by: Olaf Hering <olaf@aepfle.de>

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

> 
> diff -r 6727070b4129 -r 6d1d516ecaad tools/libxc/xtl_logger_stdio.c
> --- a/tools/libxc/xtl_logger_stdio.c
> +++ b/tools/libxc/xtl_logger_stdio.c
> @@ -89,7 +89,7 @@ static void stdiostream_progress(struct 
>      int newpel, extra_erase;
>      xentoollog_level this_level;
>  
> -    if (!(lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS))
> +    if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
>          return;
>  
>      if (percent < lg->progress_last_percent) {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 11:06:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:06: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 1U2JsE-0003BM-6J; Mon, 04 Feb 2013 11:06: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 1U2JsC-0003B6-IU
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:06:04 +0000
Received: from [85.158.143.35:41213] by server-3.bemta-4.messagelabs.com id
	91/43-08920-B169F015; Mon, 04 Feb 2013 11:06:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1359975628!15810673!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13960 invoked from network); 4 Feb 2013 11:00:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:00:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:00: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.297.1; Mon, 4 Feb 2013
	11:00:28 +0000
Message-ID: <1359975627.5281.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 11:00:27 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E7@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E7@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 03/03] HVM firmware passthrough libxl
 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 Fri, 2013-02-01 at 20:16 +0000, Ross Philipson wrote:
> Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

Looks pretty mechanical and a quick by eye-scan didn't show anything odd:

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

I didn't comment at the time but it looked like a few of these leaked
into the previous patch, up to you if you want to fix I think.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:06:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:06: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 1U2JsE-0003BM-6J; Mon, 04 Feb 2013 11:06: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 1U2JsC-0003B6-IU
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:06:04 +0000
Received: from [85.158.143.35:41213] by server-3.bemta-4.messagelabs.com id
	91/43-08920-B169F015; Mon, 04 Feb 2013 11:06:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1359975628!15810673!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13960 invoked from network); 4 Feb 2013 11:00:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:00:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:00: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.297.1; Mon, 4 Feb 2013
	11:00:28 +0000
Message-ID: <1359975627.5281.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 11:00:27 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E7@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E7@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 03/03] HVM firmware passthrough libxl
 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 Fri, 2013-02-01 at 20:16 +0000, Ross Philipson wrote:
> Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

Looks pretty mechanical and a quick by eye-scan didn't show anything odd:

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

I didn't comment at the time but it looked like a few of these leaked
into the previous patch, up to you if you want to fix I think.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:06:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:06: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 1U2JsT-0003EO-Qx; Mon, 04 Feb 2013 11:06:21 +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 1U2JsS-0003E5-Ki
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:06:20 +0000
Received: from [85.158.137.99:4272] by server-7.bemta-3.messagelabs.com id
	F1/99-10367-B269F015; Mon, 04 Feb 2013 11:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1359975978!16687152!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5461 invoked from network); 4 Feb 2013 11:06:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:06: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.297.1; Mon, 4 Feb 2013
	11:06:18 +0000
Message-ID: <1359975977.5281.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 11:06:17 +0000
In-Reply-To: <20747.43677.802351.664975@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
> > flight 15401 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> 
> With some handholding, I managed to get the bisector to work on this.
> It found that the original "good" version is unreliable: it built Xen
> 5af4f2ab06f3 and in two recent tests on the same host, of the same
> build, it failed once and passed once.

Hrm, did it make any progress over the w/e.

> Under the circumstances it's not clear that the current staging is any
> worse than non-staging.  I think we should push the revision reported
> in this test (which was otherwise OK according to the tester) to
> non-staging, with a manual "hg push".

This sounds like a good idea.

> > version targeted for testing:
> >  xen                  d1bf3b21f783
> 
> I'm not sure how to do this with hg and have to go catch a train so I
> don't have time to look it up, but presumably there's some rune of the
> form "hg push -r d1bf3b21f783 ssh://xenbits/xen-unstable.hg"

That looks right to me...

Shall I? (not sure I'm in the necessary group on xenbits, but I could
try ;-))

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:06:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:06: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 1U2JsT-0003EO-Qx; Mon, 04 Feb 2013 11:06:21 +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 1U2JsS-0003E5-Ki
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:06:20 +0000
Received: from [85.158.137.99:4272] by server-7.bemta-3.messagelabs.com id
	F1/99-10367-B269F015; Mon, 04 Feb 2013 11:06:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1359975978!16687152!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5461 invoked from network); 4 Feb 2013 11:06:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1114437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:06: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.297.1; Mon, 4 Feb 2013
	11:06:18 +0000
Message-ID: <1359975977.5281.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 11:06:17 +0000
In-Reply-To: <20747.43677.802351.664975@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
> > flight 15401 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> 
> With some handholding, I managed to get the bisector to work on this.
> It found that the original "good" version is unreliable: it built Xen
> 5af4f2ab06f3 and in two recent tests on the same host, of the same
> build, it failed once and passed once.

Hrm, did it make any progress over the w/e.

> Under the circumstances it's not clear that the current staging is any
> worse than non-staging.  I think we should push the revision reported
> in this test (which was otherwise OK according to the tester) to
> non-staging, with a manual "hg push".

This sounds like a good idea.

> > version targeted for testing:
> >  xen                  d1bf3b21f783
> 
> I'm not sure how to do this with hg and have to go catch a train so I
> don't have time to look it up, but presumably there's some rune of the
> form "hg push -r d1bf3b21f783 ssh://xenbits/xen-unstable.hg"

That looks right to me...

Shall I? (not sure I'm in the necessary group on xenbits, but I could
try ;-))

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:19:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:19: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 1U2K4Y-0003iH-8V; Mon, 04 Feb 2013 11:18:50 +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 1U2K4W-0003iC-Pc
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:18:49 +0000
Received: from [193.109.254.147:2685] by server-2.bemta-14.messagelabs.com id
	A1/73-16277-8199F015; Mon, 04 Feb 2013 11:18:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359976672!3216054!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32234 invoked from network); 4 Feb 2013 11:17:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 11:17:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 11:17:52 +0000
Message-Id: <510FA6ED02000078000BB742@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 11:17:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359975977.5281.58.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
>> xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
>> > flight 15401 xen-unstable real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/ 
>> > 
>> > Regressions :-(
>> > 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
>> 
>> With some handholding, I managed to get the bisector to work on this.
>> It found that the original "good" version is unreliable: it built Xen
>> 5af4f2ab06f3 and in two recent tests on the same host, of the same
>> build, it failed once and passed once.
> 
> Hrm, did it make any progress over the w/e.

With the failure now being consistent rather than intermittent,
we almost definitely have a state worse than before.

>> Under the circumstances it's not clear that the current staging is any
>> worse than non-staging.  I think we should push the revision reported
>> in this test (which was otherwise OK according to the tester) to
>> non-staging, with a manual "hg push".
> 
> This sounds like a good idea.

Wouldn't that set us up for the same problem again when the next
testing round fails here again?

Unless Olaf's testing with partial reverts shows otherwise, I'd be up
for reverting all non-trivial x86 HVM RTC patches I had applied
recently (where "trivial" to me would be "use RTC_* names instead of
literal numbers" and "use cached original value in RTC_REG_B writing
code", albeit the latter may not revert cleanly on its own). Should
they turn out not to be the culprit, they could always be re-applied
later.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:19:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:19: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 1U2K4Y-0003iH-8V; Mon, 04 Feb 2013 11:18:50 +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 1U2K4W-0003iC-Pc
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:18:49 +0000
Received: from [193.109.254.147:2685] by server-2.bemta-14.messagelabs.com id
	A1/73-16277-8199F015; Mon, 04 Feb 2013 11:18:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359976672!3216054!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32234 invoked from network); 4 Feb 2013 11:17:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 11:17:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 11:17:52 +0000
Message-Id: <510FA6ED02000078000BB742@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 11:17:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359975977.5281.58.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
>> xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
>> > flight 15401 xen-unstable real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/ 
>> > 
>> > Regressions :-(
>> > 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
>> 
>> With some handholding, I managed to get the bisector to work on this.
>> It found that the original "good" version is unreliable: it built Xen
>> 5af4f2ab06f3 and in two recent tests on the same host, of the same
>> build, it failed once and passed once.
> 
> Hrm, did it make any progress over the w/e.

With the failure now being consistent rather than intermittent,
we almost definitely have a state worse than before.

>> Under the circumstances it's not clear that the current staging is any
>> worse than non-staging.  I think we should push the revision reported
>> in this test (which was otherwise OK according to the tester) to
>> non-staging, with a manual "hg push".
> 
> This sounds like a good idea.

Wouldn't that set us up for the same problem again when the next
testing round fails here again?

Unless Olaf's testing with partial reverts shows otherwise, I'd be up
for reverting all non-trivial x86 HVM RTC patches I had applied
recently (where "trivial" to me would be "use RTC_* names instead of
literal numbers" and "use cached original value in RTC_REG_B writing
code", albeit the latter may not revert cleanly on its own). Should
they turn out not to be the culprit, they could always be re-applied
later.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:21:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:21: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 1U2K6Y-0003nL-P5; Mon, 04 Feb 2013 11:20: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 1U2K6X-0003nG-FT
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:20:53 +0000
Received: from [85.158.143.35:15554] by server-1.bemta-4.messagelabs.com id
	38/14-08839-4999F015; Mon, 04 Feb 2013 11:20:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1359976821!11612090!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21497 invoked from network); 4 Feb 2013 11:20:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:20:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1115074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:20: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.297.1; Mon, 4 Feb 2013
	11:20:21 +0000
Message-ID: <1359976820.5281.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 11:20:20 +0000
In-Reply-To: <510F8C0E02000078000BB67C@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 09:23 +0000, Jan Beulich wrote:
> >>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
> > +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
> > +                            xen_pfn_t *mask, int nr_pages)
> > +{
> > +    int rc;
> > +    void *mapping;
> > +    struct page_info *pginfo;
> > +    unsigned long gfn;
> > +    int pending_count = 0, mask_count = 0;
> > +
> > +#define __MAP(src, dst, cnt)                                    \
> > +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
> > +    {                                                           \
> > +        rc = -EINVAL;                                           \
> > +        gfn = (src)[(cnt)];                                     \
> > +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
> > +        if ( !pginfo )                                          \
> > +            goto err;                                           \
> > +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
> > +        {                                                       \
> > +            put_page(pginfo);                                   \
> > +            goto err;                                           \
> > +        }                                                       \
> > +        mapping = __map_domain_page_global(pginfo);             \
> > +        if ( !mapping )                                         \
> > +        {                                                       \
> > +            put_page_and_type(pginfo);                          \
> > +            rc = -ENOMEM;                                       \
> > +            goto err;                                           \
> > +        }                                                       \
> > +        (dst)[(cnt)] = mapping;                                 \
> > +    }
> > +
> > +    __MAP(pending, d->evtchn_pending, pending_count)
> > +    __MAP(mask, d->evtchn_mask, mask_count)
> > +#undef __MAP
> > +
> > +    rc = 0;
> > +
> > + err:
> > +    return rc;
> > +}
> 
> So this alone already is up to 16 pages per guest, and hence a
> theoretical maximum of 512k pages, i.e. 2G mapped space.

That's given a theoretical 32k guests? Ouch. It also ignores the need
for other global mappings.

on the flip side only a minority of domains are likely to be using the
extended scheme, and I expect even those which are would not be using
all 16 pages, so maybe we can fault them in on demand as we bind/unbind
evtchns.

Where does 16 come from? How many pages to we end up with at each level
in the new scheme?

Some levels of the trie are per-VCPU, did you account for that already
in the 2GB?

>  The
> global page mapping area, however, is only 1Gb in size on x86-64
> (didn't check ARM at all)...

There isn't currently a global page mapping area on 32-bit ARM (I
suppose we have avoided them somehow...) but obviously 2G would be a
problem in a 4GB address space.

On ARM we currently have 2G for domheap mappings which I suppose we
would split if we needed a global page map

These need to be global so we can deliver evtchns to VCPUs which aren't
running, right? I suppose mapping on demand (other than for a running
VCPU) would be prohibitively expensive.

Could we make this space per-VCPU (or per-domain) by saying that a
domain maps its own evtchn pages plus the required pages from other
domains with which an evtchn is bound? Might be tricky to arrange
though, especially with the per-VCPU pages and affinity changes?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:21:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:21: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 1U2K6Y-0003nL-P5; Mon, 04 Feb 2013 11:20: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 1U2K6X-0003nG-FT
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:20:53 +0000
Received: from [85.158.143.35:15554] by server-1.bemta-4.messagelabs.com id
	38/14-08839-4999F015; Mon, 04 Feb 2013 11:20:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1359976821!11612090!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21497 invoked from network); 4 Feb 2013 11:20:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:20:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1115074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:20: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.297.1; Mon, 4 Feb 2013
	11:20:21 +0000
Message-ID: <1359976820.5281.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 11:20:20 +0000
In-Reply-To: <510F8C0E02000078000BB67C@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 09:23 +0000, Jan Beulich wrote:
> >>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
> > +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
> > +                            xen_pfn_t *mask, int nr_pages)
> > +{
> > +    int rc;
> > +    void *mapping;
> > +    struct page_info *pginfo;
> > +    unsigned long gfn;
> > +    int pending_count = 0, mask_count = 0;
> > +
> > +#define __MAP(src, dst, cnt)                                    \
> > +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
> > +    {                                                           \
> > +        rc = -EINVAL;                                           \
> > +        gfn = (src)[(cnt)];                                     \
> > +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
> > +        if ( !pginfo )                                          \
> > +            goto err;                                           \
> > +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
> > +        {                                                       \
> > +            put_page(pginfo);                                   \
> > +            goto err;                                           \
> > +        }                                                       \
> > +        mapping = __map_domain_page_global(pginfo);             \
> > +        if ( !mapping )                                         \
> > +        {                                                       \
> > +            put_page_and_type(pginfo);                          \
> > +            rc = -ENOMEM;                                       \
> > +            goto err;                                           \
> > +        }                                                       \
> > +        (dst)[(cnt)] = mapping;                                 \
> > +    }
> > +
> > +    __MAP(pending, d->evtchn_pending, pending_count)
> > +    __MAP(mask, d->evtchn_mask, mask_count)
> > +#undef __MAP
> > +
> > +    rc = 0;
> > +
> > + err:
> > +    return rc;
> > +}
> 
> So this alone already is up to 16 pages per guest, and hence a
> theoretical maximum of 512k pages, i.e. 2G mapped space.

That's given a theoretical 32k guests? Ouch. It also ignores the need
for other global mappings.

on the flip side only a minority of domains are likely to be using the
extended scheme, and I expect even those which are would not be using
all 16 pages, so maybe we can fault them in on demand as we bind/unbind
evtchns.

Where does 16 come from? How many pages to we end up with at each level
in the new scheme?

Some levels of the trie are per-VCPU, did you account for that already
in the 2GB?

>  The
> global page mapping area, however, is only 1Gb in size on x86-64
> (didn't check ARM at all)...

There isn't currently a global page mapping area on 32-bit ARM (I
suppose we have avoided them somehow...) but obviously 2G would be a
problem in a 4GB address space.

On ARM we currently have 2G for domheap mappings which I suppose we
would split if we needed a global page map

These need to be global so we can deliver evtchns to VCPUs which aren't
running, right? I suppose mapping on demand (other than for a running
VCPU) would be prohibitively expensive.

Could we make this space per-VCPU (or per-domain) by saying that a
domain maps its own evtchn pages plus the required pages from other
domains with which an evtchn is bound? Might be tricky to arrange
though, especially with the per-VCPU pages and affinity changes?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:22: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 1U2K7t-0003vf-By; Mon, 04 Feb 2013 11:22: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 1U2K7r-0003vU-Sv
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:22:16 +0000
Received: from [85.158.139.211:10837] by server-1.bemta-5.messagelabs.com id
	0E/D4-29263-7E99F015; Mon, 04 Feb 2013 11:22:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1359976934!18223364!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29749 invoked from network); 4 Feb 2013 11:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1115145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:22: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.297.1; Mon, 4 Feb 2013
	11:22:14 +0000
Message-ID: <1359976933.5281.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 11:22:13 +0000
In-Reply-To: <510FA6ED02000078000BB742@nat28.tlf.novell.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> >> xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
> >> > flight 15401 xen-unstable real [real]
> >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/ 
> >> > 
> >> > Regressions :-(
> >> > 
> >> > Tests which did not succeed and are blocking,
> >> > including tests which could not be run:
> >> >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> >> 
> >> With some handholding, I managed to get the bisector to work on this.
> >> It found that the original "good" version is unreliable: it built Xen
> >> 5af4f2ab06f3 and in two recent tests on the same host, of the same
> >> build, it failed once and passed once.
> > 
> > Hrm, did it make any progress over the w/e.
> 
> With the failure now being consistent rather than intermittent,
> we almost definitely have a state worse than before.
> 
> >> Under the circumstances it's not clear that the current staging is any
> >> worse than non-staging.  I think we should push the revision reported
> >> in this test (which was otherwise OK according to the tester) to
> >> non-staging, with a manual "hg push".
> > 
> > This sounds like a good idea.
> 
> Wouldn't that set us up for the same problem again when the next
> testing round fails here again?

Yes, that's true.

> 
> Unless Olaf's testing with partial reverts shows otherwise, I'd be up
> for reverting all non-trivial x86 HVM RTC patches I had applied
> recently (where "trivial" to me would be "use RTC_* names instead of
> literal numbers" and "use cached original value in RTC_REG_B writing
> code", albeit the latter may not revert cleanly on its own). Should
> they turn out not to be the culprit, they could always be re-applied
> later.

We should certainly see what Olaf's test shows. I'd also be interested
in what (if anything) the bisector has discovered. But then yes, if we
think these might be the culprit then reverting would be sensible.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:22: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 1U2K7t-0003vf-By; Mon, 04 Feb 2013 11:22: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 1U2K7r-0003vU-Sv
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:22:16 +0000
Received: from [85.158.139.211:10837] by server-1.bemta-5.messagelabs.com id
	0E/D4-29263-7E99F015; Mon, 04 Feb 2013 11:22:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1359976934!18223364!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29749 invoked from network); 4 Feb 2013 11:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1115145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:22: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.297.1; Mon, 4 Feb 2013
	11:22:14 +0000
Message-ID: <1359976933.5281.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 11:22:13 +0000
In-Reply-To: <510FA6ED02000078000BB742@nat28.tlf.novell.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> >> xen.org writes ("[xen-unstable test] 15401: regressions - FAIL"):
> >> > flight 15401 xen-unstable real [real]
> >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15401/ 
> >> > 
> >> > Regressions :-(
> >> > 
> >> > Tests which did not succeed and are blocking,
> >> > including tests which could not be run:
> >> >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> >> 
> >> With some handholding, I managed to get the bisector to work on this.
> >> It found that the original "good" version is unreliable: it built Xen
> >> 5af4f2ab06f3 and in two recent tests on the same host, of the same
> >> build, it failed once and passed once.
> > 
> > Hrm, did it make any progress over the w/e.
> 
> With the failure now being consistent rather than intermittent,
> we almost definitely have a state worse than before.
> 
> >> Under the circumstances it's not clear that the current staging is any
> >> worse than non-staging.  I think we should push the revision reported
> >> in this test (which was otherwise OK according to the tester) to
> >> non-staging, with a manual "hg push".
> > 
> > This sounds like a good idea.
> 
> Wouldn't that set us up for the same problem again when the next
> testing round fails here again?

Yes, that's true.

> 
> Unless Olaf's testing with partial reverts shows otherwise, I'd be up
> for reverting all non-trivial x86 HVM RTC patches I had applied
> recently (where "trivial" to me would be "use RTC_* names instead of
> literal numbers" and "use cached original value in RTC_REG_B writing
> code", albeit the latter may not revert cleanly on its own). Should
> they turn out not to be the culprit, they could always be re-applied
> later.

We should certainly see what Olaf's test shows. I'd also be interested
in what (if anything) the bisector has discovered. But then yes, if we
think these might be the culprit then reverting would be sensible.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:25:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:25: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 1U2KBB-00048u-2g; Mon, 04 Feb 2013 11:25:41 +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 1U2KB9-00048m-RJ
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:25:39 +0000
Received: from [85.158.138.51:24763] by server-7.bemta-3.messagelabs.com id
	E9/28-10367-EAA9F015; Mon, 04 Feb 2013 11:25:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1359977131!20633281!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4912 invoked from network); 4 Feb 2013 11:25:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1115279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:25: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.297.1; Mon, 4 Feb 2013
	11:25:30 +0000
Message-ID: <1359977129.5281.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 11:25:29 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
 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

I don't suppose you could arrange for your replies to be threaded with
the 0/N mail could you? It helps keep them together in my queue, which I
useful when I come to apply a series which has had a few revisions.

hg email and git send-email can both do this for you.
http://wiki.xen.org/wiki/Submitting_Xen_Patches has some tips for hg.
http://wiki.xen.org/wiki/Submitting_Xen_Patches_with_Git some for git.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:25:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:25: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 1U2KBB-00048u-2g; Mon, 04 Feb 2013 11:25:41 +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 1U2KB9-00048m-RJ
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 11:25:39 +0000
Received: from [85.158.138.51:24763] by server-7.bemta-3.messagelabs.com id
	E9/28-10367-EAA9F015; Mon, 04 Feb 2013 11:25:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1359977131!20633281!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4912 invoked from network); 4 Feb 2013 11:25:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1115279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 11:25: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.297.1; Mon, 4 Feb 2013
	11:25:30 +0000
Message-ID: <1359977129.5281.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>
Date: Mon, 4 Feb 2013 11:25:29 +0000
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
 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

I don't suppose you could arrange for your replies to be threaded with
the 0/N mail could you? It helps keep them together in my queue, which I
useful when I come to apply a series which has had a few revisions.

hg email and git send-email can both do this for you.
http://wiki.xen.org/wiki/Submitting_Xen_Patches has some tips for hg.
http://wiki.xen.org/wiki/Submitting_Xen_Patches_with_Git some for git.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:30:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:30: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 1U2KFH-0004IP-Q3; Mon, 04 Feb 2013 11:29: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 1U2KFG-0004IH-Pv
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:29:55 +0000
Received: from [85.158.138.51:58158] by server-8.bemta-3.messagelabs.com id
	96/FA-25687-2BB9F015; Mon, 04 Feb 2013 11:29:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359977392!29093659!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7516 invoked from network); 4 Feb 2013 11:29:53 -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; 4 Feb 2013 11:29:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 11:29:52 +0000
Message-Id: <510FA9B902000078000BB762@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 11:29:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359976820.5281.66.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

>>> On 04.02.13 at 12:20, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-04 at 09:23 +0000, Jan Beulich wrote:
>> >>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
>> > +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
>> > +                            xen_pfn_t *mask, int nr_pages)
>> > +{
>> > +    int rc;
>> > +    void *mapping;
>> > +    struct page_info *pginfo;
>> > +    unsigned long gfn;
>> > +    int pending_count = 0, mask_count = 0;
>> > +
>> > +#define __MAP(src, dst, cnt)                                    \
>> > +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
>> > +    {                                                           \
>> > +        rc = -EINVAL;                                           \
>> > +        gfn = (src)[(cnt)];                                     \
>> > +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
>> > +        if ( !pginfo )                                          \
>> > +            goto err;                                           \
>> > +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
>> > +        {                                                       \
>> > +            put_page(pginfo);                                   \
>> > +            goto err;                                           \
>> > +        }                                                       \
>> > +        mapping = __map_domain_page_global(pginfo);             \
>> > +        if ( !mapping )                                         \
>> > +        {                                                       \
>> > +            put_page_and_type(pginfo);                          \
>> > +            rc = -ENOMEM;                                       \
>> > +            goto err;                                           \
>> > +        }                                                       \
>> > +        (dst)[(cnt)] = mapping;                                 \
>> > +    }
>> > +
>> > +    __MAP(pending, d->evtchn_pending, pending_count)
>> > +    __MAP(mask, d->evtchn_mask, mask_count)
>> > +#undef __MAP
>> > +
>> > +    rc = 0;
>> > +
>> > + err:
>> > +    return rc;
>> > +}
>> 
>> So this alone already is up to 16 pages per guest, and hence a
>> theoretical maximum of 512k pages, i.e. 2G mapped space.
> 
> That's given a theoretical 32k guests? Ouch. It also ignores the need
> for other global mappings.
> 
> on the flip side only a minority of domains are likely to be using the
> extended scheme, and I expect even those which are would not be using
> all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> evtchns.
> 
> Where does 16 come from? How many pages to we end up with at each level
> in the new scheme?

Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
got two of them (pending and mask bits).

> Some levels of the trie are per-VCPU, did you account for that already
> in the 2GB?

No, I didn't, as it would only increase the number, and make
the math less clear.

>>  The
>> global page mapping area, however, is only 1Gb in size on x86-64
>> (didn't check ARM at all)...
> 
> There isn't currently a global page mapping area on 32-bit ARM (I
> suppose we have avoided them somehow...) but obviously 2G would be a
> problem in a 4GB address space.
> 
> On ARM we currently have 2G for domheap mappings which I suppose we
> would split if we needed a global page map
> 
> These need to be global so we can deliver evtchns to VCPUs which aren't
> running, right? I suppose mapping on demand (other than for a running
> VCPU) would be prohibitively expensive.

Likely, especially for high rate ones.

> Could we make this space per-VCPU (or per-domain) by saying that a
> domain maps its own evtchn pages plus the required pages from other
> domains with which an evtchn is bound? Might be tricky to arrange
> though, especially with the per-VCPU pages and affinity changes?

Even without that trickiness it wouldn't work I'm afraid: In various
cases we need to be able to raise the events out of context (timer,
IRQs from passed through devices).

Jan

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:30:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:30: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 1U2KFH-0004IP-Q3; Mon, 04 Feb 2013 11:29: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 1U2KFG-0004IH-Pv
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:29:55 +0000
Received: from [85.158.138.51:58158] by server-8.bemta-3.messagelabs.com id
	96/FA-25687-2BB9F015; Mon, 04 Feb 2013 11:29:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1359977392!29093659!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7516 invoked from network); 4 Feb 2013 11:29:53 -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; 4 Feb 2013 11:29:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 11:29:52 +0000
Message-Id: <510FA9B902000078000BB762@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 11:29:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359976820.5281.66.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

>>> On 04.02.13 at 12:20, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-04 at 09:23 +0000, Jan Beulich wrote:
>> >>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
>> > +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
>> > +                            xen_pfn_t *mask, int nr_pages)
>> > +{
>> > +    int rc;
>> > +    void *mapping;
>> > +    struct page_info *pginfo;
>> > +    unsigned long gfn;
>> > +    int pending_count = 0, mask_count = 0;
>> > +
>> > +#define __MAP(src, dst, cnt)                                    \
>> > +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
>> > +    {                                                           \
>> > +        rc = -EINVAL;                                           \
>> > +        gfn = (src)[(cnt)];                                     \
>> > +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
>> > +        if ( !pginfo )                                          \
>> > +            goto err;                                           \
>> > +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
>> > +        {                                                       \
>> > +            put_page(pginfo);                                   \
>> > +            goto err;                                           \
>> > +        }                                                       \
>> > +        mapping = __map_domain_page_global(pginfo);             \
>> > +        if ( !mapping )                                         \
>> > +        {                                                       \
>> > +            put_page_and_type(pginfo);                          \
>> > +            rc = -ENOMEM;                                       \
>> > +            goto err;                                           \
>> > +        }                                                       \
>> > +        (dst)[(cnt)] = mapping;                                 \
>> > +    }
>> > +
>> > +    __MAP(pending, d->evtchn_pending, pending_count)
>> > +    __MAP(mask, d->evtchn_mask, mask_count)
>> > +#undef __MAP
>> > +
>> > +    rc = 0;
>> > +
>> > + err:
>> > +    return rc;
>> > +}
>> 
>> So this alone already is up to 16 pages per guest, and hence a
>> theoretical maximum of 512k pages, i.e. 2G mapped space.
> 
> That's given a theoretical 32k guests? Ouch. It also ignores the need
> for other global mappings.
> 
> on the flip side only a minority of domains are likely to be using the
> extended scheme, and I expect even those which are would not be using
> all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> evtchns.
> 
> Where does 16 come from? How many pages to we end up with at each level
> in the new scheme?

Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
got two of them (pending and mask bits).

> Some levels of the trie are per-VCPU, did you account for that already
> in the 2GB?

No, I didn't, as it would only increase the number, and make
the math less clear.

>>  The
>> global page mapping area, however, is only 1Gb in size on x86-64
>> (didn't check ARM at all)...
> 
> There isn't currently a global page mapping area on 32-bit ARM (I
> suppose we have avoided them somehow...) but obviously 2G would be a
> problem in a 4GB address space.
> 
> On ARM we currently have 2G for domheap mappings which I suppose we
> would split if we needed a global page map
> 
> These need to be global so we can deliver evtchns to VCPUs which aren't
> running, right? I suppose mapping on demand (other than for a running
> VCPU) would be prohibitively expensive.

Likely, especially for high rate ones.

> Could we make this space per-VCPU (or per-domain) by saying that a
> domain maps its own evtchn pages plus the required pages from other
> domains with which an evtchn is bound? Might be tricky to arrange
> though, especially with the per-VCPU pages and affinity changes?

Even without that trickiness it wouldn't work I'm afraid: In various
cases we need to be able to raise the events out of context (timer,
IRQs from passed through devices).

Jan

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:38:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:38: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 1U2KN1-0004Un-RL; Mon, 04 Feb 2013 11:37:55 +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 1U2KN0-0004Ui-Ie
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:37:54 +0000
Received: from [85.158.139.211:8182] by server-16.bemta-5.messagelabs.com id
	32/9F-14948-19D9F015; Mon, 04 Feb 2013 11:37:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359977871!19914496!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7910 invoked from network); 4 Feb 2013 11:37:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:37:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="5846739"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 11:37:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 06:37:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2KMw-0004cw-0d;
	Mon, 04 Feb 2013 11:37:50 +0000
Message-ID: <1359977869.7477.26.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 11:37:49 +0000
In-Reply-To: <1359976820.5281.66.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 11:20 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 09:23 +0000, Jan Beulich wrote:
> > >>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
> > > +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
> > > +                            xen_pfn_t *mask, int nr_pages)
> > > +{
> > > +    int rc;
> > > +    void *mapping;
> > > +    struct page_info *pginfo;
> > > +    unsigned long gfn;
> > > +    int pending_count = 0, mask_count = 0;
> > > +
> > > +#define __MAP(src, dst, cnt)                                    \
> > > +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
> > > +    {                                                           \
> > > +        rc = -EINVAL;                                           \
> > > +        gfn = (src)[(cnt)];                                     \
> > > +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
> > > +        if ( !pginfo )                                          \
> > > +            goto err;                                           \
> > > +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
> > > +        {                                                       \
> > > +            put_page(pginfo);                                   \
> > > +            goto err;                                           \
> > > +        }                                                       \
> > > +        mapping = __map_domain_page_global(pginfo);             \
> > > +        if ( !mapping )                                         \
> > > +        {                                                       \
> > > +            put_page_and_type(pginfo);                          \
> > > +            rc = -ENOMEM;                                       \
> > > +            goto err;                                           \
> > > +        }                                                       \
> > > +        (dst)[(cnt)] = mapping;                                 \
> > > +    }
> > > +
> > > +    __MAP(pending, d->evtchn_pending, pending_count)
> > > +    __MAP(mask, d->evtchn_mask, mask_count)
> > > +#undef __MAP
> > > +
> > > +    rc = 0;
> > > +
> > > + err:
> > > +    return rc;
> > > +}
> > 
> > So this alone already is up to 16 pages per guest, and hence a
> > theoretical maximum of 512k pages, i.e. 2G mapped space.
> 
> That's given a theoretical 32k guests? Ouch. It also ignores the need
> for other global mappings.
> 
> on the flip side only a minority of domains are likely to be using the
> extended scheme, and I expect even those which are would not be using
> all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> evtchns.
> 

This is doable. However I'm afraid checking for mapping validity in hot
path could bring in performance penalty.

> Where does 16 come from? How many pages to we end up with at each level
> in the new scheme?
> 

For 64 bit guest, 8 pages each for evtchn_pending / evtchn_mask. And
there are also other global mappings for per-vcpu L2 selectors - there
is no API for a vcpu to manipulate other vcpu's mapping. So the worst
case would be there could be lots of global mappings if a domain has
hundreds of cpus utilizes 3-level event channel.

> Some levels of the trie are per-VCPU, did you account for that already
> in the 2GB?
> 
> >  The
> > global page mapping area, however, is only 1Gb in size on x86-64
> > (didn't check ARM at all)...
> 
> There isn't currently a global page mapping area on 32-bit ARM (I
> suppose we have avoided them somehow...) but obviously 2G would be a
> problem in a 4GB address space.
> 
> On ARM we currently have 2G for domheap mappings which I suppose we
> would split if we needed a global page map
> 
> These need to be global so we can deliver evtchns to VCPUs which aren't
> running, right? I suppose mapping on demand (other than for a running
> VCPU) would be prohibitively expensive.
> 

Those are the leaf mappings which are supposed to be global.

> Could we make this space per-VCPU (or per-domain) by saying that a
> domain maps its own evtchn pages plus the required pages from other
> domains with which an evtchn is bound? Might be tricky to arrange
> though, especially with the per-VCPU pages and affinity changes?
> 

Really tricky... Also potential performance penalty.



Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 11:38:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 11:38: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 1U2KN1-0004Un-RL; Mon, 04 Feb 2013 11:37:55 +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 1U2KN0-0004Ui-Ie
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 11:37:54 +0000
Received: from [85.158.139.211:8182] by server-16.bemta-5.messagelabs.com id
	32/9F-14948-19D9F015; Mon, 04 Feb 2013 11:37:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359977871!19914496!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7910 invoked from network); 4 Feb 2013 11:37:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 11:37:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="5846739"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 11:37:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 06:37:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2KMw-0004cw-0d;
	Mon, 04 Feb 2013 11:37:50 +0000
Message-ID: <1359977869.7477.26.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 11:37:49 +0000
In-Reply-To: <1359976820.5281.66.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 11:20 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 09:23 +0000, Jan Beulich wrote:
> > >>> On 31.01.13 at 15:43, Wei Liu <wei.liu2@citrix.com> wrote:
> > > +static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
> > > +                            xen_pfn_t *mask, int nr_pages)
> > > +{
> > > +    int rc;
> > > +    void *mapping;
> > > +    struct page_info *pginfo;
> > > +    unsigned long gfn;
> > > +    int pending_count = 0, mask_count = 0;
> > > +
> > > +#define __MAP(src, dst, cnt)                                    \
> > > +    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
> > > +    {                                                           \
> > > +        rc = -EINVAL;                                           \
> > > +        gfn = (src)[(cnt)];                                     \
> > > +        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
> > > +        if ( !pginfo )                                          \
> > > +            goto err;                                           \
> > > +        if ( !get_page_type(pginfo, PGT_writable_page) )        \
> > > +        {                                                       \
> > > +            put_page(pginfo);                                   \
> > > +            goto err;                                           \
> > > +        }                                                       \
> > > +        mapping = __map_domain_page_global(pginfo);             \
> > > +        if ( !mapping )                                         \
> > > +        {                                                       \
> > > +            put_page_and_type(pginfo);                          \
> > > +            rc = -ENOMEM;                                       \
> > > +            goto err;                                           \
> > > +        }                                                       \
> > > +        (dst)[(cnt)] = mapping;                                 \
> > > +    }
> > > +
> > > +    __MAP(pending, d->evtchn_pending, pending_count)
> > > +    __MAP(mask, d->evtchn_mask, mask_count)
> > > +#undef __MAP
> > > +
> > > +    rc = 0;
> > > +
> > > + err:
> > > +    return rc;
> > > +}
> > 
> > So this alone already is up to 16 pages per guest, and hence a
> > theoretical maximum of 512k pages, i.e. 2G mapped space.
> 
> That's given a theoretical 32k guests? Ouch. It also ignores the need
> for other global mappings.
> 
> on the flip side only a minority of domains are likely to be using the
> extended scheme, and I expect even those which are would not be using
> all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> evtchns.
> 

This is doable. However I'm afraid checking for mapping validity in hot
path could bring in performance penalty.

> Where does 16 come from? How many pages to we end up with at each level
> in the new scheme?
> 

For 64 bit guest, 8 pages each for evtchn_pending / evtchn_mask. And
there are also other global mappings for per-vcpu L2 selectors - there
is no API for a vcpu to manipulate other vcpu's mapping. So the worst
case would be there could be lots of global mappings if a domain has
hundreds of cpus utilizes 3-level event channel.

> Some levels of the trie are per-VCPU, did you account for that already
> in the 2GB?
> 
> >  The
> > global page mapping area, however, is only 1Gb in size on x86-64
> > (didn't check ARM at all)...
> 
> There isn't currently a global page mapping area on 32-bit ARM (I
> suppose we have avoided them somehow...) but obviously 2G would be a
> problem in a 4GB address space.
> 
> On ARM we currently have 2G for domheap mappings which I suppose we
> would split if we needed a global page map
> 
> These need to be global so we can deliver evtchns to VCPUs which aren't
> running, right? I suppose mapping on demand (other than for a running
> VCPU) would be prohibitively expensive.
> 

Those are the leaf mappings which are supposed to be global.

> Could we make this space per-VCPU (or per-domain) by saying that a
> domain maps its own evtchn pages plus the required pages from other
> domains with which an evtchn is bound? Might be tricky to arrange
> though, especially with the per-VCPU pages and affinity changes?
> 

Really tricky... Also potential performance penalty.



Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 12:49:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 12: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 1U2LUI-0006g9-Gz; Mon, 04 Feb 2013 12:49: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 1U2LUH-0006fx-2D
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 12:49:29 +0000
Received: from [85.158.139.83:61425] by server-6.bemta-5.messagelabs.com id
	A4/50-01489-85EAF015; Mon, 04 Feb 2013 12:49:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1359982167!28341002!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31604 invoked from network); 4 Feb 2013 12:49:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 12:49:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1118561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 12:49: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.297.1; Mon, 4 Feb 2013
	12:49:26 +0000
Message-ID: <1359982165.7743.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: sagana chinnathambi <sagana.c@gmail.com>
Date: Mon, 4 Feb 2013 12:49:25 +0000
In-Reply-To: <CAG_Pk2s1V9KaEG6x7EtOroKGiyUeusEbB28NiBxDFP9RTS1cVg@mail.gmail.com>
References: <CAG_Pk2s1V9KaEG6x7EtOroKGiyUeusEbB28NiBxDFP9RTS1cVg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] live migration reg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 08:12 +0000, sagana chinnathambi wrote:

> how to implement working set in live migration of virtual machine
> using xen

That's a very broad question which is unlikely to gather many responses.
I recommend taking a look at
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions which should help
you ask questions which people might be able to answer.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 12:49:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 12: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 1U2LUI-0006g9-Gz; Mon, 04 Feb 2013 12:49: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 1U2LUH-0006fx-2D
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 12:49:29 +0000
Received: from [85.158.139.83:61425] by server-6.bemta-5.messagelabs.com id
	A4/50-01489-85EAF015; Mon, 04 Feb 2013 12:49:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1359982167!28341002!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31604 invoked from network); 4 Feb 2013 12:49:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 12:49:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1118561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 12:49: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.297.1; Mon, 4 Feb 2013
	12:49:26 +0000
Message-ID: <1359982165.7743.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: sagana chinnathambi <sagana.c@gmail.com>
Date: Mon, 4 Feb 2013 12:49:25 +0000
In-Reply-To: <CAG_Pk2s1V9KaEG6x7EtOroKGiyUeusEbB28NiBxDFP9RTS1cVg@mail.gmail.com>
References: <CAG_Pk2s1V9KaEG6x7EtOroKGiyUeusEbB28NiBxDFP9RTS1cVg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] live migration reg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 08:12 +0000, sagana chinnathambi wrote:

> how to implement working set in live migration of virtual machine
> using xen

That's a very broad question which is unlikely to gather many responses.
I recommend taking a look at
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions which should help
you ask questions which people might be able to answer.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 12:54:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 12: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 1U2LYv-00074H-8E; Mon, 04 Feb 2013 12:54: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 1U2LYt-00073y-Mg
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 12:54:15 +0000
Received: from [85.158.139.211:2101] by server-6.bemta-5.messagelabs.com id
	B1/D8-01489-67FAF015; Mon, 04 Feb 2013 12:54:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1359982454!21003580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23792 invoked from network); 4 Feb 2013 12:54:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 12:54:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1118772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 12:54: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.297.1; Mon, 4 Feb 2013
	12:54:14 +0000
Message-ID: <1359982452.7743.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Mon, 4 Feb 2013 12:54:12 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458354@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458354@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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 Fri, 2013-02-01 at 15:46 +0000, Frediano Ziglio wrote:
> On Fri, 2013-02-01 at 14:48 +0000, Frediano Ziglio wrote:
> > Updated set of patches for coverage.
> > Changes:
> > - implemented way of getting information
> > - use only 2 parameter in hypercall (still not sure it's better to use
> >   sysctl)
> > - use "coverage" for configuration option as suggested by Ian Campbell
> > - split header in include/public/gcov.h and include/xen/gcov.h to allow
> >   tools to include public header
> > - use weak to avoid defining compat_coverage_op
> > 
> > I manage to write 2 tools, one that call the new hypercall and dump the
> > blob in a file, one that split this file into required .gcda files. 
> > Both very hack ones and dirty but works and prove the hypervisor code is 
> > fine. Should I just send them anyway?
> > 
> > The forth patch allow to consume just 0 bytes if coverage is disabled.
> > 
> 
> These are the two utilities. If anybody wants to try.

Thanks, are you going to eventually post these for inclusion in the
tree? (tools/misc or somewhere perhaps).

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 12:54:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 12: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 1U2LYv-00074H-8E; Mon, 04 Feb 2013 12:54: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 1U2LYt-00073y-Mg
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 12:54:15 +0000
Received: from [85.158.139.211:2101] by server-6.bemta-5.messagelabs.com id
	B1/D8-01489-67FAF015; Mon, 04 Feb 2013 12:54:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1359982454!21003580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23792 invoked from network); 4 Feb 2013 12:54:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 12:54:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1118772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 12:54: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.297.1; Mon, 4 Feb 2013
	12:54:14 +0000
Message-ID: <1359982452.7743.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Mon, 4 Feb 2013 12:54:12 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458354@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458354@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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 Fri, 2013-02-01 at 15:46 +0000, Frediano Ziglio wrote:
> On Fri, 2013-02-01 at 14:48 +0000, Frediano Ziglio wrote:
> > Updated set of patches for coverage.
> > Changes:
> > - implemented way of getting information
> > - use only 2 parameter in hypercall (still not sure it's better to use
> >   sysctl)
> > - use "coverage" for configuration option as suggested by Ian Campbell
> > - split header in include/public/gcov.h and include/xen/gcov.h to allow
> >   tools to include public header
> > - use weak to avoid defining compat_coverage_op
> > 
> > I manage to write 2 tools, one that call the new hypercall and dump the
> > blob in a file, one that split this file into required .gcda files. 
> > Both very hack ones and dirty but works and prove the hypervisor code is 
> > fine. Should I just send them anyway?
> > 
> > The forth patch allow to consume just 0 bytes if coverage is disabled.
> > 
> 
> These are the two utilities. If anybody wants to try.

Thanks, are you going to eventually post these for inclusion in the
tree? (tools/misc or somewhere perhaps).

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 12:55:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2LZR-00077Y-NY; Mon, 04 Feb 2013 12:54:49 +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 1U2LZQ-00077J-Ie
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 12:54:48 +0000
Received: from [85.158.139.83:31999] by server-12.bemta-5.messagelabs.com id
	E9/1C-20195-79FAF015; Mon, 04 Feb 2013 12:54:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359982487!29886190!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17946 invoked from network); 4 Feb 2013 12:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 12:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1118796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 12:54: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.297.1; Mon, 4 Feb 2013
	12:54:46 +0000
Message-ID: <1359982485.7743.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 12:54:45 +0000
In-Reply-To: <20130204095709.GB2564@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
	<20130204095709.GB2564@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> On Wed, Jan 30, Ian Campbell wrote:
> 
> > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > A variant of this change has been tested with xend, the patch below is
> > > only compile tested. The changes to libxl change the API, is that
> > > approach acceptable?
> > 
> > I'm afraid not, the compatibility requirements are covered in the
> > comment near the top of libxl.h.
> > 
> > So you either need a new function or to leverage the LIBXL_API_VERSION
> > define (which the user must supply) such that people providing 0x040200
> > see the current interface and people providing 0x040300 (or nothing) see
> > the new one.
> 
> And to avoid the API change at all, should max_iters and max_factor be
> passed via xenstore to xc_domain_save()? So that either the caller of
> xc_domain_save reads the values from xenstore, or the function itself
> reads it from there. What do you think?

Unfortunately libxc cannot access xenstore.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 12:55:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2LZR-00077Y-NY; Mon, 04 Feb 2013 12:54:49 +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 1U2LZQ-00077J-Ie
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 12:54:48 +0000
Received: from [85.158.139.83:31999] by server-12.bemta-5.messagelabs.com id
	E9/1C-20195-79FAF015; Mon, 04 Feb 2013 12:54:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359982487!29886190!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17946 invoked from network); 4 Feb 2013 12:54:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 12:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1118796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 12:54: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.297.1; Mon, 4 Feb 2013
	12:54:46 +0000
Message-ID: <1359982485.7743.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 12:54:45 +0000
In-Reply-To: <20130204095709.GB2564@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
	<20130204095709.GB2564@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> On Wed, Jan 30, Ian Campbell wrote:
> 
> > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > A variant of this change has been tested with xend, the patch below is
> > > only compile tested. The changes to libxl change the API, is that
> > > approach acceptable?
> > 
> > I'm afraid not, the compatibility requirements are covered in the
> > comment near the top of libxl.h.
> > 
> > So you either need a new function or to leverage the LIBXL_API_VERSION
> > define (which the user must supply) such that people providing 0x040200
> > see the current interface and people providing 0x040300 (or nothing) see
> > the new one.
> 
> And to avoid the API change at all, should max_iters and max_factor be
> passed via xenstore to xc_domain_save()? So that either the caller of
> xc_domain_save reads the values from xenstore, or the function itself
> reads it from there. What do you think?

Unfortunately libxc cannot access xenstore.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:10:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:10: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 1U2Lnq-0007mN-QG; Mon, 04 Feb 2013 13:09:42 +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 1U2Lnq-0007mI-0C
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:09:42 +0000
Received: from [85.158.139.83:50837] by server-8.bemta-5.messagelabs.com id
	D6/78-19075-513BF015; Mon, 04 Feb 2013 13:09:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1359983380!30636362!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18797 invoked from network); 4 Feb 2013 13:09:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 13:09:40 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo24) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v040bep14CpNCS ;
	Mon, 4 Feb 2013 14:09:40 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0C2AC1884C; Mon,  4 Feb 2013 14:09:39 +0100 (CET)
Date: Mon, 4 Feb 2013 14:09:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204130939.GA16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
	<20130204095709.GB2564@aepfle.de>
	<1359982485.7743.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359982485.7743.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
	cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Mon, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> > On Wed, Jan 30, Ian Campbell wrote:
> > 
> > > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > > A variant of this change has been tested with xend, the patch below is
> > > > only compile tested. The changes to libxl change the API, is that
> > > > approach acceptable?
> > > 
> > > I'm afraid not, the compatibility requirements are covered in the
> > > comment near the top of libxl.h.
> > > 
> > > So you either need a new function or to leverage the LIBXL_API_VERSION
> > > define (which the user must supply) such that people providing 0x040200
> > > see the current interface and people providing 0x040300 (or nothing) see
> > > the new one.
> > 
> > And to avoid the API change at all, should max_iters and max_factor be
> > passed via xenstore to xc_domain_save()? So that either the caller of
> > xc_domain_save reads the values from xenstore, or the function itself
> > reads it from there. What do you think?
> 
> Unfortunately libxc cannot access xenstore.

In case of xm, it would be the xc_save binary, which can receive both
values from argv[].
In case of xl, it would be a xenstore write in main_migrate and a read
in libxl_domain_suspend. Which would cover also other callers of
libxl_domain_suspend.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:10:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:10: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 1U2Lnq-0007mN-QG; Mon, 04 Feb 2013 13:09:42 +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 1U2Lnq-0007mI-0C
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:09:42 +0000
Received: from [85.158.139.83:50837] by server-8.bemta-5.messagelabs.com id
	D6/78-19075-513BF015; Mon, 04 Feb 2013 13:09:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1359983380!30636362!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18797 invoked from network); 4 Feb 2013 13:09:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 13:09:40 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo24) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v040bep14CpNCS ;
	Mon, 4 Feb 2013 14:09:40 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0C2AC1884C; Mon,  4 Feb 2013 14:09:39 +0100 (CET)
Date: Mon, 4 Feb 2013 14:09:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204130939.GA16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
	<20130204095709.GB2564@aepfle.de>
	<1359982485.7743.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359982485.7743.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
	cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Mon, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> > On Wed, Jan 30, Ian Campbell wrote:
> > 
> > > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > > A variant of this change has been tested with xend, the patch below is
> > > > only compile tested. The changes to libxl change the API, is that
> > > > approach acceptable?
> > > 
> > > I'm afraid not, the compatibility requirements are covered in the
> > > comment near the top of libxl.h.
> > > 
> > > So you either need a new function or to leverage the LIBXL_API_VERSION
> > > define (which the user must supply) such that people providing 0x040200
> > > see the current interface and people providing 0x040300 (or nothing) see
> > > the new one.
> > 
> > And to avoid the API change at all, should max_iters and max_factor be
> > passed via xenstore to xc_domain_save()? So that either the caller of
> > xc_domain_save reads the values from xenstore, or the function itself
> > reads it from there. What do you think?
> 
> Unfortunately libxc cannot access xenstore.

In case of xm, it would be the xc_save binary, which can receive both
values from argv[].
In case of xl, it would be a xenstore write in main_migrate and a read
in libxl_domain_suspend. Which would cover also other callers of
libxl_domain_suspend.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:11:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:11: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 1U2LpG-0007r0-AK; Mon, 04 Feb 2013 13:11: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 1U2LpE-0007qj-9q
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:11:08 +0000
Received: from [85.158.137.99:57801] by server-4.bemta-3.messagelabs.com id
	22/8D-12802-B63BF015; Mon, 04 Feb 2013 13:11:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1359983464!19872526!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18334 invoked from network); 4 Feb 2013 13:11:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1119410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:11: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.297.1; Mon, 4 Feb 2013
	13:11:04 +0000
Message-ID: <1359983463.7743.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:11:03 +0000
In-Reply-To: <785c8f34e1f802106e53.1359747275@probook.site>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359746832 -3600
> # Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
> # Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
> tools: set migration constraints from cmdline
> 
> Add new options to xm/xl migrate to control the process of migration.
> The intention is to optionally abort the migration if it takes too long
> to migrate a busy guest due to the high number of dirty pages. Currently
> the guest is suspended to transfer the remaining dirty pages. This
> transfer can take too long, which can confuse the guest if its suspended
> for too long.
> 
> -M <number>   Number of iterations before final suspend (default: 30)
> --max_iters <number>
> 
> -m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
> --max_factor <factor>
> 
> -N            Abort migration instead of doing final suspend.
> --no_suspend

Is this last one a debug option? (Having read the patch I think not, but
the description here doesn't really explain it)

> The changes to libxl change the API, is that approach acceptable?

I think this is now along the right lines (see below though).

> v4:
>  - update default for no_suspend from None to 0 in XendCheckpoint.py:save
>  - update logoutput in setMigrateConstraints
>  - change xm migrate defaults from None to 0
>  - add new options to xl.1
>  - fix syntax error in XendDomain.py:domain_migrate_constraints_set
>  - fix xm migrate -N option name to match xl migrate
> 
> v3:
>  - move logic errors in libxl__domain_suspend and fixed help text in
>    cmd_table to separate patches
>  - fix syntax error in XendCheckpoint.py
>  - really pass max_iters and max_factor in libxl__xc_domain_save
>  - make libxl_domain_suspend_0x040200 declaration globally visible
>  - bump libxenlight.so SONAME from 2.0 to 2.1 due to changed
>    libxl_domain_suspend
> 
> v2:
>  - use LIBXL_API_VERSION and define libxl_domain_suspend_0x040200
>  - fix logic error in min_reached check in xc_domain_save
>  - add longopts
>  - update --help text
>  - correct description of migrate --help text
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r fd711ebdce9a -r 785c8f34e1f8 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -391,6 +391,18 @@ Send <config> instead of config file fro
> 
>  Print huge (!) amount of debug during the migration process.
> 
> +=item B<-M> I<number>, B<--max_iters> I<number>
> +
> +Number of iterations before final suspend (default: 30)
> +
> +=item B<-m> I<factor>, B<--max_factor> I<factor>
> +
> +Max amount of memory to transfer before final suspend (default: 3*RAM)
> +
> +=item B<-N>, B<--no_suspend>
> +
> +Abort migration instead of doing final suspend.
> +
>  =back
> 
>  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c

The changes to this file only seem to implement the -N and not the other
two?

> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
>  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, uint32_t domid, int fd,
> +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
>                           int flags, /* LIBXL_SUSPEND_* */
>                           const libxl_asyncop_how *ao_how)
>                           LIBXL_EXTERNAL_CALLERS_ONLY;
> +#ifdef LIBXL_API_VERSION
> +#if LIBXL_API_VERSION == 0x040200
> +#define libxl_domain_suspend libxl_domain_suspend_0x040200

int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                         int flags, /* LIBXL_SUSPEND_* */
                         int max_iters, int max_factor,
                         const libxl_asyncop_how *ao_how)
                         LIBXL_EXTERNAL_CALLERS_ONLY;
#ifdef LIBXL_API_VERSION
#if LIBXL_API_VERSION == 0x040200
#define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
            libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
#endif /* LIBXL_API_VERSION == 0x040200 */
#endif /* defined(LIBXL_API_VERSION) */

Should work?

Not sure if
#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION == 0x040200
works in CPP.

Maybe we should
#ifndef LIBXL_API_VERSION
#define LIBXL_API_VERSION LIBXL_API_VERSION_LATEST
#endif
?

> +
>  #define LIBXL_SUSPEND_DEBUG 1
>  #define LIBXL_SUSPEND_LIVE 2
> +#define LIBXL_SUSPEND_NO_FINAL_SUSPEND 4

(These should really be in the IDL, but this is a pre-existing
condition)

The name of this new option doesn't quite describe what it does, since
it doesn't disable the final suspend always, only under certain
condition.

LIBXL_SUSPEND_ABORT_ON_<xxx>

Where the <xxx> is tricky ;-)

<xxx> == DIRTYING_TOO_FAST
<xxx> == GUEST_TOO_BUSY
<xxx> == YOUR_SUGGESTIONS_HERE

> 
>  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
>   *   If this parameter is true, use co-operative resume. The guest
> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
> 
>      dss->xcflags = (live ? XCFLAGS_LIVE : 0)
>            | (debug ? XCFLAGS_DEBUG : 0)
> +          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
>            | (dss->hvm ? XCFLAGS_HVM : 0);
> 
>      dss->suspend_eventchn = -1;

> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
> 
>      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> 
> -    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
> +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);

Doesn't this need to pass down the selected values?

> @@ -3753,8 +3757,16 @@ int main_migrate(int argc, char **argv)
>      char *rune = NULL;
>      char *host;
>      int opt, daemonize = 1, monitor = 1, debug = 0;
> -
> -    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
> +    int max_iters = 0, max_factor = 0, no_suspend = 0;
> +    static struct option opts[] = {
> +        {"max_iters", 1, 0, 'M'},
> +        {"max_factor", 1, 0, 'm'},
> +        {"no_suspend", 0, 0, 'N'},

I think _ in arguments is pretty ugly... But I see we have others
already.

> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendCheckpoint.py
> --- a/tools/python/xen/xend/XendCheckpoint.py
> +++ b/tools/python/xen/xend/XendCheckpoint.py

I didn't look at any of the python stuff.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:11:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:11: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 1U2LpG-0007r0-AK; Mon, 04 Feb 2013 13:11: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 1U2LpE-0007qj-9q
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:11:08 +0000
Received: from [85.158.137.99:57801] by server-4.bemta-3.messagelabs.com id
	22/8D-12802-B63BF015; Mon, 04 Feb 2013 13:11:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1359983464!19872526!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18334 invoked from network); 4 Feb 2013 13:11:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1119410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:11: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.297.1; Mon, 4 Feb 2013
	13:11:04 +0000
Message-ID: <1359983463.7743.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:11:03 +0000
In-Reply-To: <785c8f34e1f802106e53.1359747275@probook.site>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359746832 -3600
> # Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
> # Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
> tools: set migration constraints from cmdline
> 
> Add new options to xm/xl migrate to control the process of migration.
> The intention is to optionally abort the migration if it takes too long
> to migrate a busy guest due to the high number of dirty pages. Currently
> the guest is suspended to transfer the remaining dirty pages. This
> transfer can take too long, which can confuse the guest if its suspended
> for too long.
> 
> -M <number>   Number of iterations before final suspend (default: 30)
> --max_iters <number>
> 
> -m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
> --max_factor <factor>
> 
> -N            Abort migration instead of doing final suspend.
> --no_suspend

Is this last one a debug option? (Having read the patch I think not, but
the description here doesn't really explain it)

> The changes to libxl change the API, is that approach acceptable?

I think this is now along the right lines (see below though).

> v4:
>  - update default for no_suspend from None to 0 in XendCheckpoint.py:save
>  - update logoutput in setMigrateConstraints
>  - change xm migrate defaults from None to 0
>  - add new options to xl.1
>  - fix syntax error in XendDomain.py:domain_migrate_constraints_set
>  - fix xm migrate -N option name to match xl migrate
> 
> v3:
>  - move logic errors in libxl__domain_suspend and fixed help text in
>    cmd_table to separate patches
>  - fix syntax error in XendCheckpoint.py
>  - really pass max_iters and max_factor in libxl__xc_domain_save
>  - make libxl_domain_suspend_0x040200 declaration globally visible
>  - bump libxenlight.so SONAME from 2.0 to 2.1 due to changed
>    libxl_domain_suspend
> 
> v2:
>  - use LIBXL_API_VERSION and define libxl_domain_suspend_0x040200
>  - fix logic error in min_reached check in xc_domain_save
>  - add longopts
>  - update --help text
>  - correct description of migrate --help text
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r fd711ebdce9a -r 785c8f34e1f8 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -391,6 +391,18 @@ Send <config> instead of config file fro
> 
>  Print huge (!) amount of debug during the migration process.
> 
> +=item B<-M> I<number>, B<--max_iters> I<number>
> +
> +Number of iterations before final suspend (default: 30)
> +
> +=item B<-m> I<factor>, B<--max_factor> I<factor>
> +
> +Max amount of memory to transfer before final suspend (default: 3*RAM)
> +
> +=item B<-N>, B<--no_suspend>
> +
> +Abort migration instead of doing final suspend.
> +
>  =back
> 
>  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c

The changes to this file only seem to implement the -N and not the other
two?

> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
>  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, uint32_t domid, int fd,
> +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
>                           int flags, /* LIBXL_SUSPEND_* */
>                           const libxl_asyncop_how *ao_how)
>                           LIBXL_EXTERNAL_CALLERS_ONLY;
> +#ifdef LIBXL_API_VERSION
> +#if LIBXL_API_VERSION == 0x040200
> +#define libxl_domain_suspend libxl_domain_suspend_0x040200

int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                         int flags, /* LIBXL_SUSPEND_* */
                         int max_iters, int max_factor,
                         const libxl_asyncop_how *ao_how)
                         LIBXL_EXTERNAL_CALLERS_ONLY;
#ifdef LIBXL_API_VERSION
#if LIBXL_API_VERSION == 0x040200
#define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
            libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
#endif /* LIBXL_API_VERSION == 0x040200 */
#endif /* defined(LIBXL_API_VERSION) */

Should work?

Not sure if
#if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION == 0x040200
works in CPP.

Maybe we should
#ifndef LIBXL_API_VERSION
#define LIBXL_API_VERSION LIBXL_API_VERSION_LATEST
#endif
?

> +
>  #define LIBXL_SUSPEND_DEBUG 1
>  #define LIBXL_SUSPEND_LIVE 2
> +#define LIBXL_SUSPEND_NO_FINAL_SUSPEND 4

(These should really be in the IDL, but this is a pre-existing
condition)

The name of this new option doesn't quite describe what it does, since
it doesn't disable the final suspend always, only under certain
condition.

LIBXL_SUSPEND_ABORT_ON_<xxx>

Where the <xxx> is tricky ;-)

<xxx> == DIRTYING_TOO_FAST
<xxx> == GUEST_TOO_BUSY
<xxx> == YOUR_SUGGESTIONS_HERE

> 
>  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
>   *   If this parameter is true, use co-operative resume. The guest
> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
> 
>      dss->xcflags = (live ? XCFLAGS_LIVE : 0)
>            | (debug ? XCFLAGS_DEBUG : 0)
> +          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
>            | (dss->hvm ? XCFLAGS_HVM : 0);
> 
>      dss->suspend_eventchn = -1;

> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
> 
>      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> 
> -    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
> +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);

Doesn't this need to pass down the selected values?

> @@ -3753,8 +3757,16 @@ int main_migrate(int argc, char **argv)
>      char *rune = NULL;
>      char *host;
>      int opt, daemonize = 1, monitor = 1, debug = 0;
> -
> -    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
> +    int max_iters = 0, max_factor = 0, no_suspend = 0;
> +    static struct option opts[] = {
> +        {"max_iters", 1, 0, 'M'},
> +        {"max_factor", 1, 0, 'm'},
> +        {"no_suspend", 0, 0, 'N'},

I think _ in arguments is pretty ugly... But I see we have others
already.

> diff -r fd711ebdce9a -r 785c8f34e1f8 tools/python/xen/xend/XendCheckpoint.py
> --- a/tools/python/xen/xend/XendCheckpoint.py
> +++ b/tools/python/xen/xend/XendCheckpoint.py

I didn't look at any of the python stuff.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:14:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2LsI-000847-UW; Mon, 04 Feb 2013 13:14: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 1U2LsH-000840-6r
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:14:17 +0000
Received: from [85.158.143.99:49115] by server-1.bemta-4.messagelabs.com id
	70/9C-08839-824BF015; Mon, 04 Feb 2013 13:14:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1359983656!22532681!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30409 invoked from network); 4 Feb 2013 13:14:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1119547"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:14: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.297.1; Mon, 4 Feb 2013
	13:14:16 +0000
Message-ID: <1359983654.7743.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:14:14 +0000
In-Reply-To: <20130204130939.GA16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
	<20130204095709.GB2564@aepfle.de>
	<1359982485.7743.11.camel@zakaz.uk.xensource.com>
	<20130204130939.GA16090@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:09 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> > > On Wed, Jan 30, Ian Campbell wrote:
> > > 
> > > > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > > > A variant of this change has been tested with xend, the patch below is
> > > > > only compile tested. The changes to libxl change the API, is that
> > > > > approach acceptable?
> > > > 
> > > > I'm afraid not, the compatibility requirements are covered in the
> > > > comment near the top of libxl.h.
> > > > 
> > > > So you either need a new function or to leverage the LIBXL_API_VERSION
> > > > define (which the user must supply) such that people providing 0x040200
> > > > see the current interface and people providing 0x040300 (or nothing) see
> > > > the new one.
> > > 
> > > And to avoid the API change at all, should max_iters and max_factor be
> > > passed via xenstore to xc_domain_save()? So that either the caller of
> > > xc_domain_save reads the values from xenstore, or the function itself
> > > reads it from there. What do you think?
> > 
> > Unfortunately libxc cannot access xenstore.
> 
> In case of xm, it would be the xc_save binary, which can receive both
> values from argv[].
> In case of xl, it would be a xenstore write in main_migrate and a read
> in libxl_domain_suspend. Which would cover also other callers of
> libxl_domain_suspend.

I see, I think this is worse than the LIBXL_API_VERSION approach you've
already implemented.

Also, now I think about it, users of libxl are not expected to have to
use xenstore either.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:14:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2LsI-000847-UW; Mon, 04 Feb 2013 13:14: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 1U2LsH-000840-6r
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:14:17 +0000
Received: from [85.158.143.99:49115] by server-1.bemta-4.messagelabs.com id
	70/9C-08839-824BF015; Mon, 04 Feb 2013 13:14:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1359983656!22532681!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30409 invoked from network); 4 Feb 2013 13:14:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1119547"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:14: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.297.1; Mon, 4 Feb 2013
	13:14:16 +0000
Message-ID: <1359983654.7743.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:14:14 +0000
In-Reply-To: <20130204130939.GA16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<1359556230.12252.235.camel@zakaz.uk.xensource.com>
	<20130204095709.GB2564@aepfle.de>
	<1359982485.7743.11.camel@zakaz.uk.xensource.com>
	<20130204130939.GA16090@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:09 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 09:57 +0000, Olaf Hering wrote:
> > > On Wed, Jan 30, Ian Campbell wrote:
> > > 
> > > > On Mon, 2013-01-28 at 17:32 +0000, Olaf Hering wrote:
> > > > > A variant of this change has been tested with xend, the patch below is
> > > > > only compile tested. The changes to libxl change the API, is that
> > > > > approach acceptable?
> > > > 
> > > > I'm afraid not, the compatibility requirements are covered in the
> > > > comment near the top of libxl.h.
> > > > 
> > > > So you either need a new function or to leverage the LIBXL_API_VERSION
> > > > define (which the user must supply) such that people providing 0x040200
> > > > see the current interface and people providing 0x040300 (or nothing) see
> > > > the new one.
> > > 
> > > And to avoid the API change at all, should max_iters and max_factor be
> > > passed via xenstore to xc_domain_save()? So that either the caller of
> > > xc_domain_save reads the values from xenstore, or the function itself
> > > reads it from there. What do you think?
> > 
> > Unfortunately libxc cannot access xenstore.
> 
> In case of xm, it would be the xc_save binary, which can receive both
> values from argv[].
> In case of xl, it would be a xenstore write in main_migrate and a read
> in libxl_domain_suspend. Which would cover also other callers of
> libxl_domain_suspend.

I see, I think this is worse than the LIBXL_API_VERSION approach you've
already implemented.

Also, now I think about it, users of libxl are not expected to have to
use xenstore either.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:14:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2LsZ-00086A-Az; Mon, 04 Feb 2013 13:14:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U2LsX-00085W-21
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:14:33 +0000
Received: from [85.158.139.83:34893] by server-4.bemta-5.messagelabs.com id
	CE/9F-29496-834BF015; Mon, 04 Feb 2013 13:14:32 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1359983671!30319711!1
X-Originating-IP: [74.125.83.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1787 invoked from network); 4 Feb 2013 13:14:31 -0000
Received: from mail-ee0-f51.google.com (HELO mail-ee0-f51.google.com)
	(74.125.83.51)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:14:31 -0000
Received: by mail-ee0-f51.google.com with SMTP id d17so3091485eek.24
	for <xen-devel@lists.xensource.com>;
	Mon, 04 Feb 2013 05:14:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=b3az66uOs5SNo8iYyB5uSRXa3V7NTlB+B9D7WMrX8k8=;
	b=FH999kQTUmgF2wMnFbptg371heiMn2VC2+Ybhs6xuk0HIb0ZejjmoXUCXQJa9UfU7y
	Kn+kaFLzrh4TMIUKXAsZyQk2suH3j3jyYiY4+xvvS8dHilqodgzw3/ftHPL9tP5R5j0c
	QW1zeTXb/QBTiT+3GUlbesHFY7IYFkFU83070gEWtVXPUEvisCEm0ixCInvlaSrRjjl/
	G8hOZDvl+o+zEAF/ej9u9mnyUa9ir8mpVticY4iNUuxhRWHPr79bi9isKwRvX0hcUVxZ
	Tf81oEOsAfBADsIbd8UcS3/sJrtsEK3RqE0t9Z6fTvBb6SUc4MKRu9UQRl8Pyu89wYQb
	vQaA==
X-Received: by 10.14.223.137 with SMTP id v9mr72442746eep.22.1359983671007;
	Mon, 04 Feb 2013 05:14:31 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id t4sm27232387eel.0.2013.02.04.05.14.28
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 05:14:30 -0800 (PST)
Message-ID: <510FB432.1030004@heliman.it>
Date: Mon, 04 Feb 2013 14:14:26 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
X-Gm-Message-State: ALoCoQl1giLzuRcm91ZgFQ3Ye4P66CqaBj1h2QpfOdx50C5P41Jqn0m4C/ul6kEBcj/eqrAA3KAO
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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-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

Il 18/01/2013 16:51, Stefano Stabellini ha scritto:
> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
>>> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>>>> 1) Both linux and windows domU with qemu upstream have an additional
>>>> empty floppy and cdrom.
>>>> Is there a way to remove these additionals block devices?
>>> the best way would be to pass a device or a global command line option
>>> to QEMU to change the default for isa-fdc
>>>
>>>
>>>> 2) xl cd-eject and cd-insert are not working:
>>>>
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
>>>> how=(nil) callback=(nil) poller=0x1b95930
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>>>> backend phy unsuitable as phys path not a block device
>>>> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
>>>> suitable backend for disk hdb
>>> cd-eject should work by trying to insert an empty cdrom.
>>> In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
>>> think this is not the case here.
>>> I guess it is a bug in parse_disk_config.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
>>>> how=(nil) callback=(nil) poller=0x1d079f0
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
>>>> directory
>>> It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
>>> of "/mnt/vm/iso/QUANTAL.iso".  The format parsing must be wrong.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> Seem there is parsing error about backend and device/iso path, for now I
>>>> not found solution for fix it on code.
>> I've added -nodefaults option to qemu upstream to remove empty floppy
>> and cdrom with success. Please could this be added by default on libxl
>> on qemu upstream starting?
> The problem with -nodefaults is that it changes a lot of other things
> aside from the floppy drive:
>
> default_serial = 0;
> default_parallel = 0;
> default_virtcon = 0;
> default_monitor = 0;
> default_vga = 0;
> default_net = 0;
> default_floppy = 0;
> default_cdrom = 0;
> default_sdcard = 0;
>
> libxl should always set the right command line options for vga and
> network, and most of the other settings don't matter for us.
> However I am concerned about the monitor and the cdrom drive.
>
> I thought that we always wanted to have a cdrom drive on HVM guests,
> even if empty.
>
> It would be better to find a way to change only the floppy default
> setting.
>

It seems there is no other way to disable default floppy only, what can 
we do about it?
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html

>> About cd-eject cd-insert parsing bug can you solve please?
> Yes, however I am a bit busy at the moment so it might take some time.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:14:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2LsZ-00086A-Az; Mon, 04 Feb 2013 13:14:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U2LsX-00085W-21
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:14:33 +0000
Received: from [85.158.139.83:34893] by server-4.bemta-5.messagelabs.com id
	CE/9F-29496-834BF015; Mon, 04 Feb 2013 13:14:32 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1359983671!30319711!1
X-Originating-IP: [74.125.83.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1787 invoked from network); 4 Feb 2013 13:14:31 -0000
Received: from mail-ee0-f51.google.com (HELO mail-ee0-f51.google.com)
	(74.125.83.51)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:14:31 -0000
Received: by mail-ee0-f51.google.com with SMTP id d17so3091485eek.24
	for <xen-devel@lists.xensource.com>;
	Mon, 04 Feb 2013 05:14:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=b3az66uOs5SNo8iYyB5uSRXa3V7NTlB+B9D7WMrX8k8=;
	b=FH999kQTUmgF2wMnFbptg371heiMn2VC2+Ybhs6xuk0HIb0ZejjmoXUCXQJa9UfU7y
	Kn+kaFLzrh4TMIUKXAsZyQk2suH3j3jyYiY4+xvvS8dHilqodgzw3/ftHPL9tP5R5j0c
	QW1zeTXb/QBTiT+3GUlbesHFY7IYFkFU83070gEWtVXPUEvisCEm0ixCInvlaSrRjjl/
	G8hOZDvl+o+zEAF/ej9u9mnyUa9ir8mpVticY4iNUuxhRWHPr79bi9isKwRvX0hcUVxZ
	Tf81oEOsAfBADsIbd8UcS3/sJrtsEK3RqE0t9Z6fTvBb6SUc4MKRu9UQRl8Pyu89wYQb
	vQaA==
X-Received: by 10.14.223.137 with SMTP id v9mr72442746eep.22.1359983671007;
	Mon, 04 Feb 2013 05:14:31 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id t4sm27232387eel.0.2013.02.04.05.14.28
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 05:14:30 -0800 (PST)
Message-ID: <510FB432.1030004@heliman.it>
Date: Mon, 04 Feb 2013 14:14:26 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
X-Gm-Message-State: ALoCoQl1giLzuRcm91ZgFQ3Ye4P66CqaBj1h2QpfOdx50C5P41Jqn0m4C/ul6kEBcj/eqrAA3KAO
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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-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

Il 18/01/2013 16:51, Stefano Stabellini ha scritto:
> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
>>> On Fri, 18 Jan 2013, Fabio Fantoni wrote:
>>>> 1) Both linux and windows domU with qemu upstream have an additional
>>>> empty floppy and cdrom.
>>>> Is there a way to remove these additionals block devices?
>>> the best way would be to pass a device or a global command line option
>>> to QEMU to change the default for isa-fdc
>>>
>>>
>>>> 2) xl cd-eject and cd-insert are not working:
>>>>
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
>>>> how=(nil) callback=(nil) poller=0x1b95930
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
>>>> backend phy unsuitable as phys path not a block device
>>>> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
>>>> suitable backend for disk hdb
>>> cd-eject should work by trying to insert an empty cdrom.
>>> In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
>>> think this is not the case here.
>>> I guess it is a bug in parse_disk_config.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
>>>> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
>>>> how=(nil) callback=(nil) poller=0x1d079f0
>>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb spec.backend=phy
>>>> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
>>>> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
>>>> directory
>>> It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
>>> of "/mnt/vm/iso/QUANTAL.iso".  The format parsing must be wrong.
>>>
>>>
>>>> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
>>>> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
>>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>>>> xc: debug: hypercall buffer: cache current size:2
>>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>>>
>>>> Seem there is parsing error about backend and device/iso path, for now I
>>>> not found solution for fix it on code.
>> I've added -nodefaults option to qemu upstream to remove empty floppy
>> and cdrom with success. Please could this be added by default on libxl
>> on qemu upstream starting?
> The problem with -nodefaults is that it changes a lot of other things
> aside from the floppy drive:
>
> default_serial = 0;
> default_parallel = 0;
> default_virtcon = 0;
> default_monitor = 0;
> default_vga = 0;
> default_net = 0;
> default_floppy = 0;
> default_cdrom = 0;
> default_sdcard = 0;
>
> libxl should always set the right command line options for vga and
> network, and most of the other settings don't matter for us.
> However I am concerned about the monitor and the cdrom drive.
>
> I thought that we always wanted to have a cdrom drive on HVM guests,
> even if empty.
>
> It would be better to find a way to change only the floppy default
> setting.
>

It seems there is no other way to disable default floppy only, what can 
we do about it?
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html

>> About cd-eject cd-insert parsing bug can you solve please?
> Yes, however I am a bit busy at the moment so it might take some time.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:21:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:21: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 1U2Lyk-0008RO-BU; Mon, 04 Feb 2013 13:20:58 +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 1U2Lyi-0008R8-OW
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:20:56 +0000
Received: from [85.158.138.51:51630] by server-16.bemta-3.messagelabs.com id
	27/5D-02727-3B5BF015; Mon, 04 Feb 2013 13:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1359984050!21951005!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29668 invoked from network); 4 Feb 2013 13:20:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1119792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:20: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.297.1; Mon, 4 Feb 2013
	13:20:50 +0000
Message-ID: <1359984048.7743.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Mon, 4 Feb 2013 13:20:48 +0000
In-Reply-To: <510FB432.1030004@heliman.it>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
	<510FB432.1030004@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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 Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
> > It would be better to find a way to change only the floppy default
> > setting.
> >
> 
> It seems there is no other way to disable default floppy only, what can 
> we do about it?

Patch upstream qemu to add an option to do this.

> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html

Ian.




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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:21:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:21: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 1U2Lyk-0008RO-BU; Mon, 04 Feb 2013 13:20:58 +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 1U2Lyi-0008R8-OW
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:20:56 +0000
Received: from [85.158.138.51:51630] by server-16.bemta-3.messagelabs.com id
	27/5D-02727-3B5BF015; Mon, 04 Feb 2013 13:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1359984050!21951005!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29668 invoked from network); 4 Feb 2013 13:20:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1119792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:20: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.297.1; Mon, 4 Feb 2013
	13:20:50 +0000
Message-ID: <1359984048.7743.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Mon, 4 Feb 2013 13:20:48 +0000
In-Reply-To: <510FB432.1030004@heliman.it>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
	<510FB432.1030004@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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 Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
> > It would be better to find a way to change only the floppy default
> > setting.
> >
> 
> It seems there is no other way to disable default floppy only, what can 
> we do about it?

Patch upstream qemu to add an option to do this.

> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html

Ian.




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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:35:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:35: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 1U2MCv-0000FY-Q1; Mon, 04 Feb 2013 13:35: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 1U2MCu-0000FT-Lu
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:35:36 +0000
Received: from [85.158.143.99:37953] by server-2.bemta-4.messagelabs.com id
	78/4D-01597-729BF015; Mon, 04 Feb 2013 13:35:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1359984927!29764351!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4499 invoked from network); 4 Feb 2013 13:35:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:35:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1120276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:35: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.297.1; Mon, 4 Feb 2013
	13:35:27 +0000
Message-ID: <1359984925.7743.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "greg@enjellic.com" <greg@enjellic.com>
Date: Mon, 4 Feb 2013 13:35:25 +0000
In-Reply-To: <201302020848.r128mpBb021273@wind.enjellic.com>
References: <201302020848.r128mpBb021273@wind.enjellic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Migration issues with 4.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 Sat, 2013-02-02 at 08:48 +0000, Dr. Greg Wettstein wrote:
> Good morning, hope everyone's day is going well.
> 
> We have sorted out most of the issues with a new iSCSI hotplug script
> which allows Xen guests to be treated as first class SAN guests.  The
> script allows each virtual machine to be treated as an independent
> initiator (IQN) which enables guests to be managed through LUN masking
> initiator groups on popular target platforms such as SCST.
> 
> When we began testing live migration on Xen 4.2.1 we noted problems
> with PVOPS kernels not starting on the migration target.  The
> following is output when a migration is attempted:
> 
> ---------------------------------------------------------------------------
> migration target: Ready to receive domain.
> Saving to migration stream new xl format (info 0x0/0x0/8146)
> Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/8146) Savefile contains xl domain config
> xc: Saving memory: iter 0 (last sent 0 skipped 0): 65536/65536  100%
> xc: Saving memory: iter 1 (last sent 65457 skipped 79): 65536/65536  100%
> xc: Saving memory: iter 2 (last sent 86 skipped 0): 65536/65536  100%
> xc: Saving memory: iter 3 (last sent 16 skipped 0): 65536/65536  100%
> migration receiver stream contained unexpected data instead of ready message

Can you patch (lib)xl to print this unexpected data?

> (command run was: exec ./xen-migrate rainbow xl migrate-receive )

What happens if you run this by hand? I wonder if it is asking for a
password or printing a message about accepting host keys or something
and confusing the xl migration protocol.

> migration target: Transfer complete, requesting permission to start domain.
> libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading GO message from migration stream
> migration target: Failure, destroying our copy.
> migration child [8355] not exiting, no longer waiting (exit status will be unreported)
> Migration failed, resuming at sender.

There is a known issue with libxl_domain_resume not properly
implementing the slow mode correctly, it might help to changing the
libxl_domain_resume call after the "Migration failed, resuming at
sender.\n" from
	libxl_domain_resume(ctx, domid, 0, 0);
to
	libxl_domain_resume(ctx, domid, 1, 0);

Note that this won't fix you migration, but I hope it will fix the
failure path at least.

If someone is interested in fixing libxl_domain_resume(..., 0, 0) then
what's needed is to add the stuff from
tools/python/xen/xend/XendDomainInfo.py resumeDomain to libxl. I'd be
happy to advise.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:35:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:35: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 1U2MCv-0000FY-Q1; Mon, 04 Feb 2013 13:35: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 1U2MCu-0000FT-Lu
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:35:36 +0000
Received: from [85.158.143.99:37953] by server-2.bemta-4.messagelabs.com id
	78/4D-01597-729BF015; Mon, 04 Feb 2013 13:35:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1359984927!29764351!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4499 invoked from network); 4 Feb 2013 13:35:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:35:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1120276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:35: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.297.1; Mon, 4 Feb 2013
	13:35:27 +0000
Message-ID: <1359984925.7743.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "greg@enjellic.com" <greg@enjellic.com>
Date: Mon, 4 Feb 2013 13:35:25 +0000
In-Reply-To: <201302020848.r128mpBb021273@wind.enjellic.com>
References: <201302020848.r128mpBb021273@wind.enjellic.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Migration issues with 4.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 Sat, 2013-02-02 at 08:48 +0000, Dr. Greg Wettstein wrote:
> Good morning, hope everyone's day is going well.
> 
> We have sorted out most of the issues with a new iSCSI hotplug script
> which allows Xen guests to be treated as first class SAN guests.  The
> script allows each virtual machine to be treated as an independent
> initiator (IQN) which enables guests to be managed through LUN masking
> initiator groups on popular target platforms such as SCST.
> 
> When we began testing live migration on Xen 4.2.1 we noted problems
> with PVOPS kernels not starting on the migration target.  The
> following is output when a migration is attempted:
> 
> ---------------------------------------------------------------------------
> migration target: Ready to receive domain.
> Saving to migration stream new xl format (info 0x0/0x0/8146)
> Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/8146) Savefile contains xl domain config
> xc: Saving memory: iter 0 (last sent 0 skipped 0): 65536/65536  100%
> xc: Saving memory: iter 1 (last sent 65457 skipped 79): 65536/65536  100%
> xc: Saving memory: iter 2 (last sent 86 skipped 0): 65536/65536  100%
> xc: Saving memory: iter 3 (last sent 16 skipped 0): 65536/65536  100%
> migration receiver stream contained unexpected data instead of ready message

Can you patch (lib)xl to print this unexpected data?

> (command run was: exec ./xen-migrate rainbow xl migrate-receive )

What happens if you run this by hand? I wonder if it is asking for a
password or printing a message about accepting host keys or something
and confusing the xl migration protocol.

> migration target: Transfer complete, requesting permission to start domain.
> libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading GO message from migration stream
> migration target: Failure, destroying our copy.
> migration child [8355] not exiting, no longer waiting (exit status will be unreported)
> Migration failed, resuming at sender.

There is a known issue with libxl_domain_resume not properly
implementing the slow mode correctly, it might help to changing the
libxl_domain_resume call after the "Migration failed, resuming at
sender.\n" from
	libxl_domain_resume(ctx, domid, 0, 0);
to
	libxl_domain_resume(ctx, domid, 1, 0);

Note that this won't fix you migration, but I hope it will fix the
failure path at least.

If someone is interested in fixing libxl_domain_resume(..., 0, 0) then
what's needed is to add the stuff from
tools/python/xen/xend/XendDomainInfo.py resumeDomain to libxl. I'd be
happy to advise.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:41:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MIH-0000Ov-Id; Mon, 04 Feb 2013 13:41:09 +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 1U2MIF-0000Ol-VH
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:41:08 +0000
Received: from [85.158.138.51:51615] by server-5.bemta-3.messagelabs.com id
	2B/F8-04457-17ABF015; Mon, 04 Feb 2013 13:41:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1359985264!27534128!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29426 invoked from network); 4 Feb 2013 13:41:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 13:41:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jorabe mo18) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 507575p14DYFBa ;
	Mon, 4 Feb 2013 14:41:04 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id C46481884C; Mon,  4 Feb 2013 14:41:02 +0100 (CET)
Date: Mon, 4 Feb 2013 14:41:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204134102.GC16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359983463.7743.23.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1359746832 -3600
> > # Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
> > # Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
> > tools: set migration constraints from cmdline
> > 
> > Add new options to xm/xl migrate to control the process of migration.
> > The intention is to optionally abort the migration if it takes too long
> > to migrate a busy guest due to the high number of dirty pages. Currently
> > the guest is suspended to transfer the remaining dirty pages. This
> > transfer can take too long, which can confuse the guest if its suspended
> > for too long.
> > 
> > -M <number>   Number of iterations before final suspend (default: 30)
> > --max_iters <number>
> > 
> > -m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
> > --max_factor <factor>
> > 
> > -N            Abort migration instead of doing final suspend.
> > --no_suspend
> 
> Is this last one a debug option? (Having read the patch I think not, but
> the description here doesn't really explain it)

No, its not debug. And the naming of that -N option is not really good,
I agree.

What it is supposed to do is to avoid the final suspend+migrate+resume
step when either there were too many iterations or too many pages
transfered when the guest continues to dirty many pages. Its not
predictable how long the guest will be suspended to transfer the
remaining pages to the new host. I think even transfering 1GB RAM at
1000/GBs takes maybe 10 seconds and with large guests there may be
several GB dirty pages, so that a guest may be suspended for a minute.
This caused issues in a customer environment.

Instead the migration should be aborted and the guest should continue to
run on the old host.


> >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > --- a/tools/libxc/xc_domain_save.c
> > +++ b/tools/libxc/xc_domain_save.c
> 
> The changes to this file only seem to implement the -N and not the other
> two?

xc_domain_save already has max_iters and max_factor as arguments.

> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> >  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, uint32_t domid, int fd,
> > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> >                           int flags, /* LIBXL_SUSPEND_* */
> >                           const libxl_asyncop_how *ao_how)
> >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > +#ifdef LIBXL_API_VERSION
> > +#if LIBXL_API_VERSION == 0x040200
> > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> 
> int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                          int flags, /* LIBXL_SUSPEND_* */
>                          int max_iters, int max_factor,
>                          const libxl_asyncop_how *ao_how)
>                          LIBXL_EXTERNAL_CALLERS_ONLY;
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION == 0x040200
> #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
>             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> #endif /* LIBXL_API_VERSION == 0x040200 */
> #endif /* defined(LIBXL_API_VERSION) */
> 
> Should work?

That may work, have to try it. In the end if we make such a change it
would serve as example for other upcoming API changes.

> >  #define LIBXL_SUSPEND_DEBUG 1
> >  #define LIBXL_SUSPEND_LIVE 2
> > +#define LIBXL_SUSPEND_NO_FINAL_SUSPEND 4
> 
> (These should really be in the IDL, but this is a pre-existing
> condition)
> 
> The name of this new option doesn't quite describe what it does, since
> it doesn't disable the final suspend always, only under certain
> condition.
> 
> LIBXL_SUSPEND_ABORT_ON_<xxx>
> 
> Where the <xxx> is tricky ;-)
> 
> <xxx> == DIRTYING_TOO_FAST
> <xxx> == GUEST_TOO_BUSY
> <xxx> == YOUR_SUGGESTIONS_HERE

Thats alot more descriptive, thanks. DIRTYING_TOO_FAST describes it well
I think.


> >  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> >   *   If this parameter is true, use co-operative resume. The guest
> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
> > 
> >      dss->xcflags = (live ? XCFLAGS_LIVE : 0)
> >            | (debug ? XCFLAGS_DEBUG : 0)
> > +          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
> >            | (dss->hvm ? XCFLAGS_HVM : 0);
> > 
> >      dss->suspend_eventchn = -1;
> 
> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
> > 
> >      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> > 
> > -    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
> > +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);
> 
> Doesn't this need to pass down the selected values?

save_domain is different from migrate_domain, I think xl save will
suspend the guest anyway? But I notice the -c option for "save", so
perhaps it would be useful to catch busy guests as well here?


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:41:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MIH-0000Ov-Id; Mon, 04 Feb 2013 13:41:09 +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 1U2MIF-0000Ol-VH
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:41:08 +0000
Received: from [85.158.138.51:51615] by server-5.bemta-3.messagelabs.com id
	2B/F8-04457-17ABF015; Mon, 04 Feb 2013 13:41:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1359985264!27534128!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29426 invoked from network); 4 Feb 2013 13:41:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 13:41:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jorabe mo18) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 507575p14DYFBa ;
	Mon, 4 Feb 2013 14:41:04 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id C46481884C; Mon,  4 Feb 2013 14:41:02 +0100 (CET)
Date: Mon, 4 Feb 2013 14:41:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204134102.GC16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359983463.7743.23.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1359746832 -3600
> > # Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
> > # Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
> > tools: set migration constraints from cmdline
> > 
> > Add new options to xm/xl migrate to control the process of migration.
> > The intention is to optionally abort the migration if it takes too long
> > to migrate a busy guest due to the high number of dirty pages. Currently
> > the guest is suspended to transfer the remaining dirty pages. This
> > transfer can take too long, which can confuse the guest if its suspended
> > for too long.
> > 
> > -M <number>   Number of iterations before final suspend (default: 30)
> > --max_iters <number>
> > 
> > -m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
> > --max_factor <factor>
> > 
> > -N            Abort migration instead of doing final suspend.
> > --no_suspend
> 
> Is this last one a debug option? (Having read the patch I think not, but
> the description here doesn't really explain it)

No, its not debug. And the naming of that -N option is not really good,
I agree.

What it is supposed to do is to avoid the final suspend+migrate+resume
step when either there were too many iterations or too many pages
transfered when the guest continues to dirty many pages. Its not
predictable how long the guest will be suspended to transfer the
remaining pages to the new host. I think even transfering 1GB RAM at
1000/GBs takes maybe 10 seconds and with large guests there may be
several GB dirty pages, so that a guest may be suspended for a minute.
This caused issues in a customer environment.

Instead the migration should be aborted and the guest should continue to
run on the old host.


> >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > --- a/tools/libxc/xc_domain_save.c
> > +++ b/tools/libxc/xc_domain_save.c
> 
> The changes to this file only seem to implement the -N and not the other
> two?

xc_domain_save already has max_iters and max_factor as arguments.

> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> >  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, uint32_t domid, int fd,
> > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> >                           int flags, /* LIBXL_SUSPEND_* */
> >                           const libxl_asyncop_how *ao_how)
> >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > +#ifdef LIBXL_API_VERSION
> > +#if LIBXL_API_VERSION == 0x040200
> > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> 
> int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                          int flags, /* LIBXL_SUSPEND_* */
>                          int max_iters, int max_factor,
>                          const libxl_asyncop_how *ao_how)
>                          LIBXL_EXTERNAL_CALLERS_ONLY;
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION == 0x040200
> #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
>             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> #endif /* LIBXL_API_VERSION == 0x040200 */
> #endif /* defined(LIBXL_API_VERSION) */
> 
> Should work?

That may work, have to try it. In the end if we make such a change it
would serve as example for other upcoming API changes.

> >  #define LIBXL_SUSPEND_DEBUG 1
> >  #define LIBXL_SUSPEND_LIVE 2
> > +#define LIBXL_SUSPEND_NO_FINAL_SUSPEND 4
> 
> (These should really be in the IDL, but this is a pre-existing
> condition)
> 
> The name of this new option doesn't quite describe what it does, since
> it doesn't disable the final suspend always, only under certain
> condition.
> 
> LIBXL_SUSPEND_ABORT_ON_<xxx>
> 
> Where the <xxx> is tricky ;-)
> 
> <xxx> == DIRTYING_TOO_FAST
> <xxx> == GUEST_TOO_BUSY
> <xxx> == YOUR_SUGGESTIONS_HERE

Thats alot more descriptive, thanks. DIRTYING_TOO_FAST describes it well
I think.


> >  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> >   *   If this parameter is true, use co-operative resume. The guest
> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
> > 
> >      dss->xcflags = (live ? XCFLAGS_LIVE : 0)
> >            | (debug ? XCFLAGS_DEBUG : 0)
> > +          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
> >            | (dss->hvm ? XCFLAGS_HVM : 0);
> > 
> >      dss->suspend_eventchn = -1;
> 
> > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
> > 
> >      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> > 
> > -    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
> > +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);
> 
> Doesn't this need to pass down the selected values?

save_domain is different from migrate_domain, I think xl save will
suspend the guest anyway? But I notice the -c option for "save", so
perhaps it would be useful to catch busy guests as well here?


Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:45:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MMP-0000Z4-8u; Mon, 04 Feb 2013 13:45:25 +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 1U2MMN-0000Yz-Vx
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:45:24 +0000
Received: from [85.158.143.35:33894] by server-3.bemta-4.messagelabs.com id
	6C/95-08920-37BBF015; Mon, 04 Feb 2013 13:45:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1359985518!14024634!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31052 invoked from network); 4 Feb 2013 13:45:19 -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;
	4 Feb 2013 13:45:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5857577"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 13:45:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 08:45:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2MMH-0006Zx-Cv;
	Mon, 04 Feb 2013 13:45:17 +0000
Message-ID: <1359985517.7477.42.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 13:45:17 +0000
In-Reply-To: <510FA9B902000078000BB762@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
> >> 
> >> So this alone already is up to 16 pages per guest, and hence a
> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
> > 
> > That's given a theoretical 32k guests? Ouch. It also ignores the need
> > for other global mappings.
> > 
> > on the flip side only a minority of domains are likely to be using the
> > extended scheme, and I expect even those which are would not be using
> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> > evtchns.
> > 
> > Where does 16 come from? How many pages to we end up with at each level
> > in the new scheme?
> 
> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
> got two of them (pending and mask bits).
> 
> > Some levels of the trie are per-VCPU, did you account for that already
> > in the 2GB?
> 
> No, I didn't, as it would only increase the number, and make
> the math less clear.
> 
> >>  The
> >> global page mapping area, however, is only 1Gb in size on x86-64
> >> (didn't check ARM at all)...
> > 
> > There isn't currently a global page mapping area on 32-bit ARM (I
> > suppose we have avoided them somehow...) but obviously 2G would be a
> > problem in a 4GB address space.
> > 
> > On ARM we currently have 2G for domheap mappings which I suppose we
> > would split if we needed a global page map
> > 
> > These need to be global so we can deliver evtchns to VCPUs which aren't
> > running, right? I suppose mapping on demand (other than for a running
> > VCPU) would be prohibitively expensive.
> 
> Likely, especially for high rate ones.
> 
> > Could we make this space per-VCPU (or per-domain) by saying that a
> > domain maps its own evtchn pages plus the required pages from other
> > domains with which an evtchn is bound? Might be tricky to arrange
> > though, especially with the per-VCPU pages and affinity changes?
> 
> Even without that trickiness it wouldn't work I'm afraid: In various
> cases we need to be able to raise the events out of context (timer,
> IRQs from passed through devices).
> 
> Jan

So I come up with following comment on the 3-level registration
interface (not specific to __map_l3_array() function).

/*
 * Note to 3-level event channel users:
 * Only enable 3-level event channel for Dom0 or driver domains, because
 * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
 * area in Xen.
 */



Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:45:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MMP-0000Z4-8u; Mon, 04 Feb 2013 13:45:25 +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 1U2MMN-0000Yz-Vx
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:45:24 +0000
Received: from [85.158.143.35:33894] by server-3.bemta-4.messagelabs.com id
	6C/95-08920-37BBF015; Mon, 04 Feb 2013 13:45:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1359985518!14024634!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31052 invoked from network); 4 Feb 2013 13:45:19 -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;
	4 Feb 2013 13:45:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5857577"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 13:45:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 08:45:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2MMH-0006Zx-Cv;
	Mon, 04 Feb 2013 13:45:17 +0000
Message-ID: <1359985517.7477.42.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 13:45:17 +0000
In-Reply-To: <510FA9B902000078000BB762@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
> >> 
> >> So this alone already is up to 16 pages per guest, and hence a
> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
> > 
> > That's given a theoretical 32k guests? Ouch. It also ignores the need
> > for other global mappings.
> > 
> > on the flip side only a minority of domains are likely to be using the
> > extended scheme, and I expect even those which are would not be using
> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> > evtchns.
> > 
> > Where does 16 come from? How many pages to we end up with at each level
> > in the new scheme?
> 
> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
> got two of them (pending and mask bits).
> 
> > Some levels of the trie are per-VCPU, did you account for that already
> > in the 2GB?
> 
> No, I didn't, as it would only increase the number, and make
> the math less clear.
> 
> >>  The
> >> global page mapping area, however, is only 1Gb in size on x86-64
> >> (didn't check ARM at all)...
> > 
> > There isn't currently a global page mapping area on 32-bit ARM (I
> > suppose we have avoided them somehow...) but obviously 2G would be a
> > problem in a 4GB address space.
> > 
> > On ARM we currently have 2G for domheap mappings which I suppose we
> > would split if we needed a global page map
> > 
> > These need to be global so we can deliver evtchns to VCPUs which aren't
> > running, right? I suppose mapping on demand (other than for a running
> > VCPU) would be prohibitively expensive.
> 
> Likely, especially for high rate ones.
> 
> > Could we make this space per-VCPU (or per-domain) by saying that a
> > domain maps its own evtchn pages plus the required pages from other
> > domains with which an evtchn is bound? Might be tricky to arrange
> > though, especially with the per-VCPU pages and affinity changes?
> 
> Even without that trickiness it wouldn't work I'm afraid: In various
> cases we need to be able to raise the events out of context (timer,
> IRQs from passed through devices).
> 
> Jan

So I come up with following comment on the 3-level registration
interface (not specific to __map_l3_array() function).

/*
 * Note to 3-level event channel users:
 * Only enable 3-level event channel for Dom0 or driver domains, because
 * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
 * area in Xen.
 */



Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:47:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MO3-0000eS-PT; Mon, 04 Feb 2013 13:47:07 +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 1U2MO2-0000eK-7O
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:47:06 +0000
Received: from [85.158.139.83:49708] by server-6.bemta-5.messagelabs.com id
	D7/B8-01489-9DBBF015; Mon, 04 Feb 2013 13:47:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1359985624!23542133!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32376 invoked from network); 4 Feb 2013 13:47:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:47:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1120715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:47: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.297.1; Mon, 4 Feb 2013
	13:47:04 +0000
Message-ID: <1359985623.7743.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 4 Feb 2013 13:47:03 +0000
In-Reply-To: <1359985517.7477.42.camel@zion.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:

> /*
>  * Note to 3-level event channel users:
>  * Only enable 3-level event channel for Dom0 or driver domains, because
>  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
>  * area in Xen.
>  */

Can this be enforced by the system administrator?

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:47:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MO3-0000eS-PT; Mon, 04 Feb 2013 13:47:07 +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 1U2MO2-0000eK-7O
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:47:06 +0000
Received: from [85.158.139.83:49708] by server-6.bemta-5.messagelabs.com id
	D7/B8-01489-9DBBF015; Mon, 04 Feb 2013 13:47:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1359985624!23542133!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32376 invoked from network); 4 Feb 2013 13:47:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:47:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1120715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:47: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.297.1; Mon, 4 Feb 2013
	13:47:04 +0000
Message-ID: <1359985623.7743.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 4 Feb 2013 13:47:03 +0000
In-Reply-To: <1359985517.7477.42.camel@zion.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:

> /*
>  * Note to 3-level event channel users:
>  * Only enable 3-level event channel for Dom0 or driver domains, because
>  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
>  * area in Xen.
>  */

Can this be enforced by the system administrator?

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:47:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MO9-0000f4-6T; Mon, 04 Feb 2013 13:47: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 1U2MO7-0000eq-Ku
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:47:11 +0000
Received: from [193.109.254.147:62891] by server-3.bemta-14.messagelabs.com id
	1D/FC-22141-EDBBF015; Mon, 04 Feb 2013 13:47:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1359985585!1120389!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6301 invoked from network); 4 Feb 2013 13:46:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1120692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:46: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.297.1; Mon, 4 Feb 2013
	13:46:25 +0000
Message-ID: <1359985584.7743.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:46:24 +0000
In-Reply-To: <20130204134102.GC16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:41 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1359746832 -3600
> > > # Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
> > > # Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
> > > tools: set migration constraints from cmdline
> > > 
> > > Add new options to xm/xl migrate to control the process of migration.
> > > The intention is to optionally abort the migration if it takes too long
> > > to migrate a busy guest due to the high number of dirty pages. Currently
> > > the guest is suspended to transfer the remaining dirty pages. This
> > > transfer can take too long, which can confuse the guest if its suspended
> > > for too long.
> > > 
> > > -M <number>   Number of iterations before final suspend (default: 30)
> > > --max_iters <number>
> > > 
> > > -m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
> > > --max_factor <factor>
> > > 
> > > -N            Abort migration instead of doing final suspend.
> > > --no_suspend
> > 
> > Is this last one a debug option? (Having read the patch I think not, but
> > the description here doesn't really explain it)
> 
> No, its not debug. And the naming of that -N option is not really good,
> I agree.
> 
> What it is supposed to do is to avoid the final suspend+migrate+resume
> step when either there were too many iterations or too many pages
> transfered when the guest continues to dirty many pages. Its not
> predictable how long the guest will be suspended to transfer the
> remaining pages to the new host. I think even transfering 1GB RAM at
> 1000/GBs takes maybe 10 seconds and with large guests there may be
> several GB dirty pages, so that a guest may be suspended for a minute.
> This caused issues in a customer environment.
> 
> Instead the migration should be aborted and the guest should continue to
> run on the old host.

That's what I understood from reading the code, can we make the docs say
it too ;-)
> 
> 
> > >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > > --- a/tools/libxc/xc_domain_save.c
> > > +++ b/tools/libxc/xc_domain_save.c
> > 
> > The changes to this file only seem to implement the -N and not the other
> > two?
> 
> xc_domain_save already has max_iters and max_factor as arguments.

Ah, I didn't appreciate that.

BTW did you want to add a way to override DEF_MIN_REMAINING?

> 
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
> > > --- a/tools/libxl/libxl.h
> > > +++ b/tools/libxl/libxl.h
> > > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> > >  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, uint32_t domid, int fd,
> > > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> > >                           int flags, /* LIBXL_SUSPEND_* */
> > >                           const libxl_asyncop_how *ao_how)
> > >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > > +#ifdef LIBXL_API_VERSION
> > > +#if LIBXL_API_VERSION == 0x040200
> > > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> > 
> > int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> >                          int flags, /* LIBXL_SUSPEND_* */
> >                          int max_iters, int max_factor,
> >                          const libxl_asyncop_how *ao_how)
> >                          LIBXL_EXTERNAL_CALLERS_ONLY;
> > #ifdef LIBXL_API_VERSION
> > #if LIBXL_API_VERSION == 0x040200
> > #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
> >             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> > #endif /* LIBXL_API_VERSION == 0x040200 */
> > #endif /* defined(LIBXL_API_VERSION) */
> > 
> > Should work?
> 
> That may work, have to try it. In the end if we make such a change it
> would serve as example for other upcoming API changes.

Agreed.

> > >  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> > >   *   If this parameter is true, use co-operative resume. The guest
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c
> > > +++ b/tools/libxl/libxl_dom.c
> > > @@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
> > > 
> > >      dss->xcflags = (live ? XCFLAGS_LIVE : 0)
> > >            | (debug ? XCFLAGS_DEBUG : 0)
> > > +          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
> > >            | (dss->hvm ? XCFLAGS_HVM : 0);
> > > 
> > >      dss->suspend_eventchn = -1;
> > 
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
> > > 
> > >      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> > > 
> > > -    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
> > > +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);
> > 
> > Doesn't this need to pass down the selected values?
> 
> save_domain is different from migrate_domain, I think xl save will
> suspend the guest anyway?

Oh yes, I didn't spot this as the save path (despite it being right
there in the function name).

>  But I notice the -c option for "save", so
> perhaps it would be useful to catch busy guests as well here?

I'm not really sure what the usecase is for save -c. I'd be a bit
inclined to leave it until someone wants it I think.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:47:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MO9-0000f4-6T; Mon, 04 Feb 2013 13:47: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 1U2MO7-0000eq-Ku
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:47:11 +0000
Received: from [193.109.254.147:62891] by server-3.bemta-14.messagelabs.com id
	1D/FC-22141-EDBBF015; Mon, 04 Feb 2013 13:47:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1359985585!1120389!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6301 invoked from network); 4 Feb 2013 13:46:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1120692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:46: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.297.1; Mon, 4 Feb 2013
	13:46:25 +0000
Message-ID: <1359985584.7743.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:46:24 +0000
In-Reply-To: <20130204134102.GC16090@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:41 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1359746832 -3600
> > > # Node ID 785c8f34e1f802106e53ca4d2c54dce55c8ee166
> > > # Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
> > > tools: set migration constraints from cmdline
> > > 
> > > Add new options to xm/xl migrate to control the process of migration.
> > > The intention is to optionally abort the migration if it takes too long
> > > to migrate a busy guest due to the high number of dirty pages. Currently
> > > the guest is suspended to transfer the remaining dirty pages. This
> > > transfer can take too long, which can confuse the guest if its suspended
> > > for too long.
> > > 
> > > -M <number>   Number of iterations before final suspend (default: 30)
> > > --max_iters <number>
> > > 
> > > -m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
> > > --max_factor <factor>
> > > 
> > > -N            Abort migration instead of doing final suspend.
> > > --no_suspend
> > 
> > Is this last one a debug option? (Having read the patch I think not, but
> > the description here doesn't really explain it)
> 
> No, its not debug. And the naming of that -N option is not really good,
> I agree.
> 
> What it is supposed to do is to avoid the final suspend+migrate+resume
> step when either there were too many iterations or too many pages
> transfered when the guest continues to dirty many pages. Its not
> predictable how long the guest will be suspended to transfer the
> remaining pages to the new host. I think even transfering 1GB RAM at
> 1000/GBs takes maybe 10 seconds and with large guests there may be
> several GB dirty pages, so that a guest may be suspended for a minute.
> This caused issues in a customer environment.
> 
> Instead the migration should be aborted and the guest should continue to
> run on the old host.

That's what I understood from reading the code, can we make the docs say
it too ;-)
> 
> 
> > >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > > --- a/tools/libxc/xc_domain_save.c
> > > +++ b/tools/libxc/xc_domain_save.c
> > 
> > The changes to this file only seem to implement the -N and not the other
> > two?
> 
> xc_domain_save already has max_iters and max_factor as arguments.

Ah, I didn't appreciate that.

BTW did you want to add a way to override DEF_MIN_REMAINING?

> 
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl.h
> > > --- a/tools/libxl/libxl.h
> > > +++ b/tools/libxl/libxl.h
> > > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> > >  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, uint32_t domid, int fd,
> > > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> > >                           int flags, /* LIBXL_SUSPEND_* */
> > >                           const libxl_asyncop_how *ao_how)
> > >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > > +#ifdef LIBXL_API_VERSION
> > > +#if LIBXL_API_VERSION == 0x040200
> > > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> > 
> > int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> >                          int flags, /* LIBXL_SUSPEND_* */
> >                          int max_iters, int max_factor,
> >                          const libxl_asyncop_how *ao_how)
> >                          LIBXL_EXTERNAL_CALLERS_ONLY;
> > #ifdef LIBXL_API_VERSION
> > #if LIBXL_API_VERSION == 0x040200
> > #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
> >             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> > #endif /* LIBXL_API_VERSION == 0x040200 */
> > #endif /* defined(LIBXL_API_VERSION) */
> > 
> > Should work?
> 
> That may work, have to try it. In the end if we make such a change it
> would serve as example for other upcoming API changes.

Agreed.

> > >  /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
> > >   *   If this parameter is true, use co-operative resume. The guest
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c
> > > +++ b/tools/libxl/libxl_dom.c
> > > @@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
> > > 
> > >      dss->xcflags = (live ? XCFLAGS_LIVE : 0)
> > >            | (debug ? XCFLAGS_DEBUG : 0)
> > > +          | (dss->xlflags & LIBXL_SUSPEND_NO_FINAL_SUSPEND ? XCFLAGS_DOMSAVE_NOSUSPEND : 0)
> > >            | (dss->hvm ? XCFLAGS_HVM : 0);
> > > 
> > >      dss->suspend_eventchn = -1;
> > 
> > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxl/xl_cmdimpl.c
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
> > > 
> > >      save_domain_core_writeconfig(fd, filename, config_data, config_len);
> > > 
> > > -    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
> > > +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, 0, 0, NULL);
> > 
> > Doesn't this need to pass down the selected values?
> 
> save_domain is different from migrate_domain, I think xl save will
> suspend the guest anyway?

Oh yes, I didn't spot this as the save path (despite it being right
there in the function name).

>  But I notice the -c option for "save", so
> perhaps it would be useful to catch busy guests as well here?

I'm not really sure what the usecase is for save -c. I'd be a bit
inclined to leave it until someone wants it I think.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:48:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:48: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 1U2MPd-0000rg-Td; Mon, 04 Feb 2013 13:48:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U2MPc-0000rU-Qv
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:48:45 +0000
Received: from [85.158.137.99:30436] by server-9.bemta-3.messagelabs.com id
	8C/AB-09484-73CBF015; Mon, 04 Feb 2013 13:48:39 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-15.tower-217.messagelabs.com!1359985718!17561755!1
X-Originating-IP: [209.85.215.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 933 invoked from network); 4 Feb 2013 13:48:38 -0000
Received: from mail-ea0-f181.google.com (HELO mail-ea0-f181.google.com)
	(209.85.215.181)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:48:38 -0000
Received: by mail-ea0-f181.google.com with SMTP id i13so2723722eaa.12
	for <xen-devel@lists.xensource.com>;
	Mon, 04 Feb 2013 05:48:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=RFAdGJ05V/a912jA9zKyvMyC9eMAaGTqc6ZePocyuFo=;
	b=nFkkFC1VPJfBowrta0Q7rRL7ivY85GDWAFHpd/Js8cKVlmQrfdVLjA3FbAaXmFXI2a
	+MLrY57I/P7ms8rvO/djs13LMmKjyTR89vetVvx6XY0wyWCE/K72FoC5wPH0TtRWgWhY
	8WLqugtMlMUQWxGHCNFJzI3+AGrVkJPQen6fy2IRTnz203myPAFOeJwWdWIlvt6l+ORg
	cB2X1DV86rTQvoCpH+P8F+xRCU9ZgA8DBbtnRBiyUbpcyP1SNRR8E28+MLh34D737cDw
	6kqLv8FnpUC8o6ztCkjrXJzYbryv23ft048kw/wA4JwKXAu1IPHo55QhwT2FGhG8mnkW
	jgZg==
X-Received: by 10.14.213.7 with SMTP id z7mr72373361eeo.2.1359985704177;
	Mon, 04 Feb 2013 05:48:24 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id d3sm27344045eeo.13.2013.02.04.05.48.22
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 05:48:23 -0800 (PST)
Message-ID: <510FBC24.4080707@heliman.it>
Date: Mon, 04 Feb 2013 14:48:20 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
	<510FB432.1030004@heliman.it>
	<1359984048.7743.25.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359984048.7743.25.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQnhv4c99rn7Zg1Vyh3D02UkpvGa3qnhrev+rXjLgAeb3KQ33VjsU+T7pOOpbakL/4jQfxNS
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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-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

Il 04/02/2013 14:20, Ian Campbell ha scritto:
> On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
>>> It would be better to find a way to change only the floppy default
>>> setting.
>>>
>> It seems there is no other way to disable default floppy only, what can
>> we do about it?
> Patch upstream qemu to add an option to do this.
>
>> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
> Ian.
Thanks for reply, I asked it on qemu-devel, if nobody will make a patch, 
I'll try to do it.
About my latest patch submission here, was it correct?
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02314.html
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02311.html
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02321.html

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:48:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:48: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 1U2MPd-0000rg-Td; Mon, 04 Feb 2013 13:48:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U2MPc-0000rU-Qv
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:48:45 +0000
Received: from [85.158.137.99:30436] by server-9.bemta-3.messagelabs.com id
	8C/AB-09484-73CBF015; Mon, 04 Feb 2013 13:48:39 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-15.tower-217.messagelabs.com!1359985718!17561755!1
X-Originating-IP: [209.85.215.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 933 invoked from network); 4 Feb 2013 13:48:38 -0000
Received: from mail-ea0-f181.google.com (HELO mail-ea0-f181.google.com)
	(209.85.215.181)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:48:38 -0000
Received: by mail-ea0-f181.google.com with SMTP id i13so2723722eaa.12
	for <xen-devel@lists.xensource.com>;
	Mon, 04 Feb 2013 05:48:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=RFAdGJ05V/a912jA9zKyvMyC9eMAaGTqc6ZePocyuFo=;
	b=nFkkFC1VPJfBowrta0Q7rRL7ivY85GDWAFHpd/Js8cKVlmQrfdVLjA3FbAaXmFXI2a
	+MLrY57I/P7ms8rvO/djs13LMmKjyTR89vetVvx6XY0wyWCE/K72FoC5wPH0TtRWgWhY
	8WLqugtMlMUQWxGHCNFJzI3+AGrVkJPQen6fy2IRTnz203myPAFOeJwWdWIlvt6l+ORg
	cB2X1DV86rTQvoCpH+P8F+xRCU9ZgA8DBbtnRBiyUbpcyP1SNRR8E28+MLh34D737cDw
	6kqLv8FnpUC8o6ztCkjrXJzYbryv23ft048kw/wA4JwKXAu1IPHo55QhwT2FGhG8mnkW
	jgZg==
X-Received: by 10.14.213.7 with SMTP id z7mr72373361eeo.2.1359985704177;
	Mon, 04 Feb 2013 05:48:24 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id d3sm27344045eeo.13.2013.02.04.05.48.22
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 05:48:23 -0800 (PST)
Message-ID: <510FBC24.4080707@heliman.it>
Date: Mon, 04 Feb 2013 14:48:20 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
	<510FB432.1030004@heliman.it>
	<1359984048.7743.25.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359984048.7743.25.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQnhv4c99rn7Zg1Vyh3D02UkpvGa3qnhrev+rXjLgAeb3KQ33VjsU+T7pOOpbakL/4jQfxNS
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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-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

Il 04/02/2013 14:20, Ian Campbell ha scritto:
> On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
>>> It would be better to find a way to change only the floppy default
>>> setting.
>>>
>> It seems there is no other way to disable default floppy only, what can
>> we do about it?
> Patch upstream qemu to add an option to do this.
>
>> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
> Ian.
Thanks for reply, I asked it on qemu-devel, if nobody will make a patch, 
I'll try to do it.
About my latest patch submission here, was it correct?
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02314.html
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02311.html
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02321.html

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:51:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MRy-000166-H2; Mon, 04 Feb 2013 13:51:10 +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 1U2MRx-00015y-Dy
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:51:09 +0000
Received: from [85.158.143.35:54974] by server-2.bemta-4.messagelabs.com id
	BF/84-01597-CCCBF015; Mon, 04 Feb 2013 13:51:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359985865!5497581!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29806 invoked from network); 4 Feb 2013 13:51:07 -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;
	4 Feb 2013 13:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5858079"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 13:51:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 08:51:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2MRs-0006ec-Vi;
	Mon, 04 Feb 2013 13:51:04 +0000
Message-ID: <1359985864.7477.45.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:51:04 +0000
In-Reply-To: <1359985623.7743.40.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> 
> > /*
> >  * Note to 3-level event channel users:
> >  * Only enable 3-level event channel for Dom0 or driver domains, because
> >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> >  * area in Xen.
> >  */
> 
> Can this be enforced by the system administrator?
> 

Knowing a domain is Dom0 is easy, but is it possible to know a domain is
driver domain?


Wei.

> Ian.
> 
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:51:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13: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 1U2MRy-000166-H2; Mon, 04 Feb 2013 13:51:10 +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 1U2MRx-00015y-Dy
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:51:09 +0000
Received: from [85.158.143.35:54974] by server-2.bemta-4.messagelabs.com id
	BF/84-01597-CCCBF015; Mon, 04 Feb 2013 13:51:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1359985865!5497581!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29806 invoked from network); 4 Feb 2013 13:51:07 -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;
	4 Feb 2013 13:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5858079"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 13:51:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 08:51:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2MRs-0006ec-Vi;
	Mon, 04 Feb 2013 13:51:04 +0000
Message-ID: <1359985864.7477.45.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:51:04 +0000
In-Reply-To: <1359985623.7743.40.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> 
> > /*
> >  * Note to 3-level event channel users:
> >  * Only enable 3-level event channel for Dom0 or driver domains, because
> >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> >  * area in Xen.
> >  */
> 
> Can this be enforced by the system administrator?
> 

Knowing a domain is Dom0 is easy, but is it possible to know a domain is
driver domain?


Wei.

> Ian.
> 
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:55:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:55: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 1U2MVq-0001Ko-6Z; Mon, 04 Feb 2013 13:55: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 1U2MVm-0001Ke-EX
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:55:08 +0000
Received: from [85.158.137.99:33881] by server-5.bemta-3.messagelabs.com id
	C7/FE-04457-9BDBF015; Mon, 04 Feb 2013 13:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1359986104!19039292!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19851 invoked from network); 4 Feb 2013 13:55:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:55:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1121037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:54: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.297.1; Mon, 4 Feb 2013
	13:54:05 +0000
Message-ID: <1359986043.7743.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 4 Feb 2013 13:54:03 +0000
In-Reply-To: <1359985864.7477.45.camel@zion.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > 
> > > /*
> > >  * Note to 3-level event channel users:
> > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > >  * area in Xen.
> > >  */
> > 
> > Can this be enforced by the system administrator?
> > 
> 
> Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> driver domain?

The admin knows, at the very least they need to have a manual override
(or maybe this should even default off for non-dom0)

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:55:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:55: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 1U2MVq-0001Ko-6Z; Mon, 04 Feb 2013 13:55: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 1U2MVm-0001Ke-EX
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:55:08 +0000
Received: from [85.158.137.99:33881] by server-5.bemta-3.messagelabs.com id
	C7/FE-04457-9BDBF015; Mon, 04 Feb 2013 13:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1359986104!19039292!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19851 invoked from network); 4 Feb 2013 13:55:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:55:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1121037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:54: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.297.1; Mon, 4 Feb 2013
	13:54:05 +0000
Message-ID: <1359986043.7743.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 4 Feb 2013 13:54:03 +0000
In-Reply-To: <1359985864.7477.45.camel@zion.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > 
> > > /*
> > >  * Note to 3-level event channel users:
> > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > >  * area in Xen.
> > >  */
> > 
> > Can this be enforced by the system administrator?
> > 
> 
> Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> driver domain?

The admin knows, at the very least they need to have a manual override
(or maybe this should even default off for non-dom0)

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:56:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:56: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 1U2MWd-0001Nr-LR; Mon, 04 Feb 2013 13:55:59 +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 1U2MWc-0001Nf-Gn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:55:58 +0000
Received: from [85.158.139.83:33337] by server-7.bemta-5.messagelabs.com id
	AA/52-11121-DEDBF015; Mon, 04 Feb 2013 13:55:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359986154!23430160!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2900 invoked from network); 4 Feb 2013 13:55:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 13:55:54 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (josoe mo21) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601e1cp14D6Ruw ;
	Mon, 4 Feb 2013 14:55:54 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 99CB41884C; Mon,  4 Feb 2013 14:55:53 +0100 (CET)
Date: Mon, 4 Feb 2013 14:55:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204135553.GB16668@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359985584.7743.39.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> > Instead the migration should be aborted and the guest should continue to
> > run on the old host.
> 
> That's what I understood from reading the code, can we make the docs say
> it too ;-)

-A --abort-if-busy maybe?

> > > >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > > > --- a/tools/libxc/xc_domain_save.c
> > > > +++ b/tools/libxc/xc_domain_save.c
> > > 
> > > The changes to this file only seem to implement the -N and not the other
> > > two?
> > 
> > xc_domain_save already has max_iters and max_factor as arguments.
> 
> Ah, I didn't appreciate that.
> 
> BTW did you want to add a way to override DEF_MIN_REMAINING?

I did consider it, but havent looked closer how to do it.

> I'm not really sure what the usecase is for save -c. I'd be a bit
> inclined to leave it until someone wants it I think.

save -c looks like a snapshot feature, but does not seem to take storage
into accound. So yes, I will leave it alone.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:56:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:56: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 1U2MWd-0001Nr-LR; Mon, 04 Feb 2013 13:55:59 +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 1U2MWc-0001Nf-Gn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:55:58 +0000
Received: from [85.158.139.83:33337] by server-7.bemta-5.messagelabs.com id
	AA/52-11121-DEDBF015; Mon, 04 Feb 2013 13:55:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359986154!23430160!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTIwNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2900 invoked from network); 4 Feb 2013 13:55:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 13:55:54 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (josoe mo21) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601e1cp14D6Ruw ;
	Mon, 4 Feb 2013 14:55:54 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 99CB41884C; Mon,  4 Feb 2013 14:55:53 +0100 (CET)
Date: Mon, 4 Feb 2013 14:55:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204135553.GB16668@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359985584.7743.39.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> > Instead the migration should be aborted and the guest should continue to
> > run on the old host.
> 
> That's what I understood from reading the code, can we make the docs say
> it too ;-)

-A --abort-if-busy maybe?

> > > >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > > > --- a/tools/libxc/xc_domain_save.c
> > > > +++ b/tools/libxc/xc_domain_save.c
> > > 
> > > The changes to this file only seem to implement the -N and not the other
> > > two?
> > 
> > xc_domain_save already has max_iters and max_factor as arguments.
> 
> Ah, I didn't appreciate that.
> 
> BTW did you want to add a way to override DEF_MIN_REMAINING?

I did consider it, but havent looked closer how to do it.

> I'm not really sure what the usecase is for save -c. I'd be a bit
> inclined to leave it until someone wants it I think.

save -c looks like a snapshot feature, but does not seem to take storage
into accound. So yes, I will leave it alone.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:58:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:58: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 1U2MYg-0001Y8-6v; Mon, 04 Feb 2013 13:58: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 1U2MYe-0001Xt-IL
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:58:04 +0000
Received: from [193.109.254.147:20211] by server-11.bemta-14.messagelabs.com
	id BB/51-30685-B6EBF015; Mon, 04 Feb 2013 13:58:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1359986188!1121811!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6578 invoked from network); 4 Feb 2013 13:56:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:56:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1121156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:56: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.297.1; Mon, 4 Feb 2013
	13:56:28 +0000
Message-ID: <1359986187.7743.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Mon, 4 Feb 2013 13:56:27 +0000
In-Reply-To: <510FBC24.4080707@heliman.it>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
	<510FB432.1030004@heliman.it>
	<1359984048.7743.25.camel@zakaz.uk.xensource.com>
	<510FBC24.4080707@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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 Mon, 2013-02-04 at 13:48 +0000, Fabio Fantoni wrote:
> Il 04/02/2013 14:20, Ian Campbell ha scritto:
> > On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
> >>> It would be better to find a way to change only the floppy default
> >>> setting.
> >>>
> >> It seems there is no other way to disable default floppy only, what can
> >> we do about it?
> > Patch upstream qemu to add an option to do this.
> >
> >> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
> > Ian.
> Thanks for reply, I asked it on qemu-devel, if nobody will make a patch, 
> I'll try to do it.

Excellent.

> About my latest patch submission here, was it correct?
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02314.html
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02311.html
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02321.html

These are in my queue but I haven't gotten to them yet.

I'm hoping we can get a test gate push soon (we've not had one for a
couple of weeks) and I am holding off committing too much stuff 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 Mon Feb 04 13:58:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:58: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 1U2MYg-0001Y8-6v; Mon, 04 Feb 2013 13:58: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 1U2MYe-0001Xt-IL
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 13:58:04 +0000
Received: from [193.109.254.147:20211] by server-11.bemta-14.messagelabs.com
	id BB/51-30685-B6EBF015; Mon, 04 Feb 2013 13:58:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1359986188!1121811!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6578 invoked from network); 4 Feb 2013 13:56:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:56:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1121156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:56: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.297.1; Mon, 4 Feb 2013
	13:56:28 +0000
Message-ID: <1359986187.7743.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Mon, 4 Feb 2013 13:56:27 +0000
In-Reply-To: <510FBC24.4080707@heliman.it>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<alpine.DEB.2.02.1301181446370.4978@kaball.uk.xensource.com>
	<510FB432.1030004@heliman.it>
	<1359984048.7743.25.camel@zakaz.uk.xensource.com>
	<510FBC24.4080707@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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 Mon, 2013-02-04 at 13:48 +0000, Fabio Fantoni wrote:
> Il 04/02/2013 14:20, Ian Campbell ha scritto:
> > On Mon, 2013-02-04 at 13:14 +0000, Fabio Fantoni wrote:
> >>> It would be better to find a way to change only the floppy default
> >>> setting.
> >>>
> >> It seems there is no other way to disable default floppy only, what can
> >> we do about it?
> > Patch upstream qemu to add an option to do this.
> >
> >> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00338.html
> > Ian.
> Thanks for reply, I asked it on qemu-devel, if nobody will make a patch, 
> I'll try to do it.

Excellent.

> About my latest patch submission here, was it correct?
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02314.html
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02311.html
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02321.html

These are in my queue but I haven't gotten to them yet.

I'm hoping we can get a test gate push soon (we've not had one for a
couple of weeks) and I am holding off committing too much stuff 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 Mon Feb 04 13:59:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:59: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 1U2MZn-0001dr-MW; Mon, 04 Feb 2013 13:59:15 +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 1U2MZm-0001dZ-6e
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:59:14 +0000
Received: from [85.158.137.99:43521] by server-6.bemta-3.messagelabs.com id
	B9/F7-29959-1BEBF015; Mon, 04 Feb 2013 13:59:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1359986352!18837886!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22250 invoked from network); 4 Feb 2013 13:59:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:59:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1121302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:59: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.297.1; Mon, 4 Feb 2013
	13:59:12 +0000
Message-ID: <1359986349.7743.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:59:09 +0000
In-Reply-To: <20130204135553.GB16668@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:55 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > > Instead the migration should be aborted and the guest should continue to
> > > run on the old host.
> > 
> > That's what I understood from reading the code, can we make the docs say
> > it too ;-)
> 
> -A --abort-if-busy maybe?

Could work. Not sure if everything needs to have a short option, but I
suppose there's no harm.

> > > > >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > > > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > > > > --- a/tools/libxc/xc_domain_save.c
> > > > > +++ b/tools/libxc/xc_domain_save.c
> > > > 
> > > > The changes to this file only seem to implement the -N and not the other
> > > > two?
> > > 
> > > xc_domain_save already has max_iters and max_factor as arguments.
> > 
> > Ah, I didn't appreciate that.
> > 
> > BTW did you want to add a way to override DEF_MIN_REMAINING?
> 
> I did consider it, but havent looked closer how to do it.

Might be best to do while you are changing the API anyway?

It just occurred to me, instead of adding lots of individual arguments
perhaps packing them into a (e.g.) libxl_save_properties and adding a
pointer would be a nicer and more extensible (in the future) interface?

> > I'm not really sure what the usecase is for save -c. I'd be a bit
> > inclined to leave it until someone wants it I think.
> 
> save -c looks like a snapshot feature, but does not seem to take storage
> into accound. So yes, I will leave it alone.

Ack.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:59:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:59: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 1U2MZn-0001dr-MW; Mon, 04 Feb 2013 13:59:15 +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 1U2MZm-0001dZ-6e
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:59:14 +0000
Received: from [85.158.137.99:43521] by server-6.bemta-3.messagelabs.com id
	B9/F7-29959-1BEBF015; Mon, 04 Feb 2013 13:59:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1359986352!18837886!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22250 invoked from network); 4 Feb 2013 13:59:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 13:59:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1121302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 13:59: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.297.1; Mon, 4 Feb 2013
	13:59:12 +0000
Message-ID: <1359986349.7743.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 13:59:09 +0000
In-Reply-To: <20130204135553.GB16668@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:55 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > > Instead the migration should be aborted and the guest should continue to
> > > run on the old host.
> > 
> > That's what I understood from reading the code, can we make the docs say
> > it too ;-)
> 
> -A --abort-if-busy maybe?

Could work. Not sure if everything needs to have a short option, but I
suppose there's no harm.

> > > > >  =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
> > > > > diff -r fd711ebdce9a -r 785c8f34e1f8 tools/libxc/xc_domain_save.c
> > > > > --- a/tools/libxc/xc_domain_save.c
> > > > > +++ b/tools/libxc/xc_domain_save.c
> > > > 
> > > > The changes to this file only seem to implement the -N and not the other
> > > > two?
> > > 
> > > xc_domain_save already has max_iters and max_factor as arguments.
> > 
> > Ah, I didn't appreciate that.
> > 
> > BTW did you want to add a way to override DEF_MIN_REMAINING?
> 
> I did consider it, but havent looked closer how to do it.

Might be best to do while you are changing the API anyway?

It just occurred to me, instead of adding lots of individual arguments
perhaps packing them into a (e.g.) libxl_save_properties and adding a
pointer would be a nicer and more extensible (in the future) interface?

> > I'm not really sure what the usecase is for save -c. I'd be a bit
> > inclined to leave it until someone wants it I think.
> 
> save -c looks like a snapshot feature, but does not seem to take storage
> into accound. So yes, I will leave it alone.

Ack.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:59:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:59: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 1U2MaC-0001h1-4K; Mon, 04 Feb 2013 13:59:40 +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 1U2MaB-0001gs-I2
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:59:39 +0000
Received: from [193.109.254.147:9014] by server-5.bemta-14.messagelabs.com id
	53/21-21539-ACEBF015; Mon, 04 Feb 2013 13:59:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359986376!10029726!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14448 invoked from network); 4 Feb 2013 13:59:38 -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;
	4 Feb 2013 13:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5859323"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 13:59:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 08:59:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2Ma8-0006m8-3C;
	Mon, 04 Feb 2013 13:59:36 +0000
Message-ID: <1359986376.7477.49.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:59:36 +0000
In-Reply-To: <1359986043.7743.42.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
	<1359986043.7743.42.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > 
> > > > /*
> > > >  * Note to 3-level event channel users:
> > > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > > >  * area in Xen.
> > > >  */
> > > 
> > > Can this be enforced by the system administrator?
> > > 
> > 
> > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > driver domain?
> 
> The admin knows, at the very least they need to have a manual override
> (or maybe this should even default off for non-dom0)
> 

Do you mean maintaining white list in Xen or adding options in guest
kernel? I already have that in my kernel patch series - only enable
3-level event channel for Dom0. And I used to propose a kernel option
for overriding this, but Konrad didn't like it.


Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 13:59:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 13:59: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 1U2MaC-0001h1-4K; Mon, 04 Feb 2013 13:59:40 +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 1U2MaB-0001gs-I2
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 13:59:39 +0000
Received: from [193.109.254.147:9014] by server-5.bemta-14.messagelabs.com id
	53/21-21539-ACEBF015; Mon, 04 Feb 2013 13:59:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359986376!10029726!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14448 invoked from network); 4 Feb 2013 13:59:38 -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;
	4 Feb 2013 13:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5859323"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 13:59:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 08:59:36 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2Ma8-0006m8-3C;
	Mon, 04 Feb 2013 13:59:36 +0000
Message-ID: <1359986376.7477.49.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:59:36 +0000
In-Reply-To: <1359986043.7743.42.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
	<1359986043.7743.42.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > 
> > > > /*
> > > >  * Note to 3-level event channel users:
> > > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > > >  * area in Xen.
> > > >  */
> > > 
> > > Can this be enforced by the system administrator?
> > > 
> > 
> > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > driver domain?
> 
> The admin knows, at the very least they need to have a manual override
> (or maybe this should even default off for non-dom0)
> 

Do you mean maintaining white list in Xen or adding options in guest
kernel? I already have that in my kernel patch series - only enable
3-level event channel for Dom0. And I used to propose a kernel option
for overriding this, but Konrad didn't like it.


Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:03:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2Mdy-00026K-Q0; Mon, 04 Feb 2013 14:03:34 +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 1U2Mdv-000266-KL
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:03:34 +0000
Received: from [85.158.137.99:3973] by server-6.bemta-3.messagelabs.com id
	3D/7F-29959-2BFBF015; Mon, 04 Feb 2013 14:03:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-217.messagelabs.com!1359986604!15188102!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11625 invoked from network); 4 Feb 2013 14:03:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 14:03:24 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo30) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n041c2p14DlPKg ;
	Mon, 4 Feb 2013 15:03:17 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id EE4191884C; Mon,  4 Feb 2013 15:03:12 +0100 (CET)
Date: Mon, 4 Feb 2013 15:03:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204140312.GA14684@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de>
	<20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
	<510F83AA02000078000BB64A@nat28.tlf.novell.com>
	<20130204094909.GA2564@aepfle.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <20130204094909.GA2564@aepfle.de>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

[ sorry, had this reply open in another window and forgot to send it ]

On Mon, Feb 04, Olaf Hering wrote:

> I'm attaching the xen, dom0 and domU logs from a pvops kernel. sles
> kernel will follow.
> 
> I will also try to revert the two changeset above.

These are the logs from sles11sp2 kernel in dom0+domU.
The guest prints "hpet1: lost 2201 rtc interrupts".

Xen has changeset 26461 reverted, but this does at least not solve the
"hpet1: lost 2201 rtc interrupts" interrupt messages.

Olaf

PS:
xl migrate with sles11 kernel does not seem to work for other unrelated reasons:

root@satriani:~/hpet # xl -v -v migrate -M 3 -m 2 -N sles11sp2_full_minimal_nfsroot_bug694863 localhost
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/657)
Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/657)
 Savefile contains xl domain config
xc: error: Can't create lock file for suspend event channel /var/lib/xen/suspend_evtchn_2_lock.d: Internal error
libxl: warning: libxl_dom.c:1268:libxl__domain_suspend: Suspend event channel initialization failed
xc: Reloading memory pages: 105472/1048575   10%^Axc: detail: type fail: page 0 mfn 000f2000
xc: detail: type fail: page 1 mfn 000f2001
xc: detail: type fail: page 2 mfn 000f2002
xc: detail: delta 5993ms, dom0 20%, target 6%, sent 722Mb/s, dirtied 94Mb/s 17369 pages
xc: detail: type fail: page 861 mfn 000f2001
xc: detail: delta 545ms, dom0 37%, target 4%, sent 1036Mb/s, dirtied 8Mb/s 147 pages
xc: detail: type fail: page 133 mfn 000f2000
xc: detail: type fail: page 134 mfn 000f2002
xc: error: Live migration aborted, as requested. (guest too busy?) total_sent 149477 iter 3, max_iters 3 max_factor 2: Internal error
xc: detail: Save exit rc=1
libxl: error: libxl_dom.c:1306:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: No such device
migration sender: libxl_domain_suspend failed (rc=-8)
xc: error: 0-length read: Internal error
xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error
xc: error: Error when reading batch size (0 = Success): Internal error
xc: error: Error when reading batch (0 = Success): Internal error
libxl: error: libxl_create.c:787:libxl__xc_domain_restore_done: restoring domain: Resource temporarily unavailable
libxl: error: libxl_create.c:869:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl.c:1395:libxl__destroy_domid: non-existant domain 3
libxl: error: libxl.c:1359:domain_destroy_callback: unable to destroy guest with domid 3
libxl: error: libxl_create.c:1177:domcreate_destruction_cb: unable to destroy domain 3 following failed creation
migration target: Domain creation failed (code -3).
libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration target process [5218] exited with error status 3
Migration failed, failed to suspend at sender.



--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="dmesg-3.0.51-0.7.9-xen.txt"

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.0.51-0.7.9-xen (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)
[    0.000000] Command line: quiet sysrq=yes panic=9 console=ttyS0,57600 resume=/dev/disk/by-id/ata-ST9500530NS_9SP1KKAS-part2 splash=silent showopts log_buf_len=64M
[    0.000000] Xen-provided machine memory map:
[    0.000000]  BIOS: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  BIOS: 000000000009b000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS: 0000000000100000 - 000000008c21c000 (usable)
[    0.000000]  BIOS: 000000008c21c000 - 000000008c2ef000 (ACPI NVS)
[    0.000000]  BIOS: 000000008c2ef000 - 000000008c3df000 (ACPI data)
[    0.000000]  BIOS: 000000008c3df000 - 000000008d7df000 (ACPI NVS)
[    0.000000]  BIOS: 000000008d7df000 - 000000008f302000 (ACPI data)
[    0.000000]  BIOS: 000000008f302000 - 000000008f34f000 (reserved)
[    0.000000]  BIOS: 000000008f34f000 - 000000008f3d4000 (ACPI data)
[    0.000000]  BIOS: 000000008f3d4000 - 000000008f3de000 (ACPI NVS)
[    0.000000]  BIOS: 000000008f3de000 - 000000008f3e2000 (ACPI data)
[    0.000000]  BIOS: 000000008f3e2000 - 000000008f4cf000 (ACPI NVS)
[    0.000000]  BIOS: 000000008f4cf000 - 000000008f500000 (ACPI data)
[    0.000000]  BIOS: 000000008f500000 - 0000000090000000 (reserved)
[    0.000000]  BIOS: 00000000a0000000 - 00000000b0000000 (reserved)
[    0.000000]  BIOS: 00000000fc000000 - 00000000fd000000 (reserved)
[    0.000000]  BIOS: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS: 00000000fec90000 - 00000000fec91000 (reserved)
[    0.000000]  BIOS: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  BIOS: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  BIOS: 0000000100000000 - 0000000670000000 (usable)
[    0.000000] Xen-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000005e0337000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] DMI: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
[    0.000000] last_pfn = 0x5e0337 max_arch_pfn = 0x80000000
[    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x80000000
[    0.000000] found SMP MP-table at [ffffffffff5f8b60] 000fdb60
[    0.000000] initial memory mapped : 0 - 00000000
[    0.000000] init_memory_mapping: 0000000000000000-0000000002113000
[    0.000000]  0000000000 - 0002113000 page 4k
[    0.000000] kernel direct mapping tables up to 0x2112fff @ [mem 0x00886000-0x00898fff]
[    0.000000] init_memory_mapping: 0000000005014000-0000000100000000
[    0.000000]  0005014000 - 0100000000 page 4k
[    0.000000] kernel direct mapping tables up to 0xffffffff @ [mem 0x00899000-0x01075fff]
[    0.000000] init_memory_mapping: 0000000100000000-00000005e0337000
[    0.000000]  0100000000 - 05e0337000 page 4k
[    0.000000] kernel direct mapping tables up to 0x5e0336fff @ [mem 0x05088000-0x0779efff]
[    0.000000] init_memory_mapping: 0000000002113000-0000000005014000
[    0.000000]  0002113000 - 0005014000 page 4k
[    0.000000] kernel direct mapping tables up to 0x5013fff @ [mem 0x0779e000-0x077b7fff]
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 258547(98%)
[    0.000000] RAMDISK: 01000000 - 02113000
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000008f4fd120 000A4 (v01 INTEL  S5520UT  00000000      01000013)
[    0.000000] ACPI: FACP 000000008f4fb000 000F4 (v04 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000008f4f4000 065E9 (v02 INTEL  S5520UT  00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000008f3e2000 00040
[    0.000000] ACPI: APIC 000000008f4f3000 001A8 (v02 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000008f4f2000 0003C (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000008f4f1000 00038 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000008f4f0000 00030 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SRAT 000000008f4ef000 00430 (v02 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000008f4ee000 00050 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000008f4ed000 00040 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000008f4d2000 1AFC4 (v02  INTEL SSDT  PM 00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000008f4d1000 001D8 (v02  INTEL IPMI     00004000 INTL 20061109)
[    0.000000] ACPI: TCPA 000000008f4d0000 00032 (v00                 00000000      00000000)
[    0.000000] ACPI: HEST 000000008f4cf000 000A8 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000008f3e1000 00030 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000008f3e0000 00230 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000008f3df000 00130 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: XMAR 000000008f3de000 001A8 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x005e0337
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x005dfb37
[    0.000000]     0: 0x005e0337 -> 0x005e0337
[    0.000000] On node 0 totalpages: 6159159
[    0.000000] free_area_init_node: node 0, pgdat ffffffff8070c300, node_mem_map ffff8805c7a29000
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4040 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 1030200 pages, LIFO batch:31
[    0.000000]   Normal zone: 69900 pages used for memmap
[    0.000000]   Normal zone: 5040683 pages, LIFO batch:31
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
[    0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at b0000000 (gap: b0000000:4c000000)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:24 nr_node_ids:1
[    0.000000] PERCPU: Embedded 17 pages/cpu @ffff8805c4600000 s40960 r8192 d20480 u131072
[    0.000000] pcpu-alloc: s40960 r8192 d20480 u131072 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 
[    0.000000] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 -- -- -- -- -- -- -- -- 
[    0.000000] Swapping MFNs for PFN 723 and 5c4605 (MFN 65e723 and 26869)
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 6074923
[    0.000000] Kernel command line: quiet sysrq=yes panic=9 console=ttyS0,57600 resume=/dev/disk/by-id/ata-ST9500530NS_9SP1KKAS-part2 splash=silent showopts log_buf_len=64M
[    0.000000] bootsplash: silent mode.
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    0.000000] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    0.000000] allocated 197158624 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Software IO TLB enabled: 
[    0.000000]  Aperture:     64 megabytes
[    0.000000]  Address size: 27 bits
[    0.000000]  Kernel range: ffff8805b19f9000 - ffff8805b59f9000
[    0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.000000] Memory: 23810364k/24644828k available (4111k kernel code, 8192k absent, 826272k reserved, 3164k data, 428k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] nr_pirqs: 64
[    0.000000] NR_IRQS:38912 nr_irqs:3200 16
[    0.000000] Extended CMOS year: 2000
[    0.000000] Xen reported: 2926.408 MHz processor.
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [xvc-1] enabled
[    0.080005] Calibrating delay using timer specific routine.. 5926.02 BogoMIPS (lpj=11852059)
[    0.080008] pid_max: default: 32768 minimum: 301
[    0.080051] Security Framework initialized
[    0.080072] AppArmor: AppArmor initialized
[    0.080091] Mount-cache hash table entries: 256
[    0.080187] Initializing cgroup subsys cpuacct
[    0.080192] Initializing cgroup subsys memory
[    0.080201] Initializing cgroup subsys devices
[    0.080202] Initializing cgroup subsys freezer
[    0.080203] Initializing cgroup subsys net_cls
[    0.080205] Initializing cgroup subsys blkio
[    0.080209] Initializing cgroup subsys perf_event
[    0.080255] mce: CPU supports 2 MCE banks
[    0.080291] SMP alternatives: switching to UP code
[    0.102891] ACPI: Core revision 20110413
[    0.125653] SMP alternatives: switching to SMP code
[    0.165979] Brought up 24 CPUs
[    0.166176] devtmpfs: initialized
[    0.166176] print_constraints: dummy: 
[    0.166176] Time: 10:41:01  Date: 02/04/13
[    0.168578] NET: Registered protocol family 16
[    0.168667] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.168667] ACPI: bus type pci registered
[    0.168667] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xa0000000-0xafffffff] (base 0xa0000000)
[    0.168667] PCI: MMCONFIG at [mem 0xa0000000-0xafffffff] reserved in E820
[    0.181711] PCI: Using configuration type 1 for base access
[    0.186358] bio: create slab <bio-0> at 0
[    0.190304] ACPI: EC: Look up EC in DSDT
[    0.216409] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL] size 64 (bits) (20110413/dsopcode-236)
[    0.216414] ACPI Error: Method parse/execution failed [\_SB_._OSC] (Node ffff8805b14fac90), AE_AML_BUFFER_LIMIT (20110413/psparse-536)
[    0.220745] ACPI: Interpreter enabled
[    0.220748] ACPI: (supports S0 S1 S5)
[    0.220758] ACPI: Using IOAPIC for interrupt routing
[    0.225732] ACPI: No dock devices found.
[    0.225736] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.226377] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fd])
[    0.226908] pci_root PNP0A08:00: host bridge window [io  0x0000-0x0cf7]
[    0.226910] pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]
[    0.226912] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.226913] pci_root PNP0A08:00: host bridge window [mem 0x000c4000-0x000cbfff]
[    0.226915] pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfedfffff]
[    0.226916] pci_root PNP0A08:00: host bridge window [mem 0xb0000000-0xfdffffff]
[    0.226920] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000c4000-0x000cbfff] conflicts with Video ROM [mem 0x000c0000-0x000c7fff]
[    0.226950] pci 0000:00:00.0: [8086:3406] type 0 class 0x000600
[    0.227044] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    0.227048] pci 0000:00:00.0: PME# disabled
[    0.227083] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604
[    0.227180] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    0.227184] pci 0000:00:01.0: PME# disabled
[    0.227220] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604
[    0.227348] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    0.227352] pci 0000:00:03.0: PME# disabled
[    0.227388] pci 0000:00:05.0: [8086:340c] type 1 class 0x000604
[    0.227484] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    0.227488] pci 0000:00:05.0: PME# disabled
[    0.227524] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604
[    0.227620] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    0.227624] pci 0000:00:07.0: PME# disabled
[    0.227663] pci 0000:00:09.0: [8086:3410] type 1 class 0x000604
[    0.227760] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    0.227763] pci 0000:00:09.0: PME# disabled
[    0.227799] pci 0000:00:0a.0: [8086:3411] type 1 class 0x000604
[    0.227899] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
[    0.227904] pci 0000:00:0a.0: PME# disabled
[    0.227939] pci 0000:00:10.0: [8086:3425] type 0 class 0x000800
[    0.228017] pci 0000:00:10.1: [8086:3426] type 0 class 0x000800
[    0.228115] pci 0000:00:11.0: [8086:3427] type 0 class 0x000800
[    0.228227] pci 0000:00:11.1: [8086:3428] type 0 class 0x000800
[    0.228326] pci 0000:00:13.0: [8086:342d] type 0 class 0x000800
[    0.228343] pci 0000:00:13.0: reg 10: [mem 0xb1b24000-0xb1b24fff]
[    0.228427] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold
[    0.228431] pci 0000:00:13.0: PME# disabled
[    0.228458] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800
[    0.228570] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800
[    0.228682] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800
[    0.228788] pci 0000:00:14.3: [8086:3438] type 0 class 0x000800
[    0.228879] pci 0000:00:15.0: [8086:342f] type 0 class 0x000800
[    0.228980] pci 0000:00:16.0: [8086:3430] type 0 class 0x000880
[    0.228999] pci 0000:00:16.0: reg 10: [mem 0xb1b00000-0xb1b03fff 64bit]
[    0.229118] pci 0000:00:16.1: [8086:3431] type 0 class 0x000880
[    0.229136] pci 0000:00:16.1: reg 10: [mem 0xb1b04000-0xb1b07fff 64bit]
[    0.229256] pci 0000:00:16.2: [8086:3432] type 0 class 0x000880
[    0.229274] pci 0000:00:16.2: reg 10: [mem 0xb1b08000-0xb1b0bfff 64bit]
[    0.229393] pci 0000:00:16.3: [8086:3433] type 0 class 0x000880
[    0.229412] pci 0000:00:16.3: reg 10: [mem 0xb1b0c000-0xb1b0ffff 64bit]
[    0.229531] pci 0000:00:16.4: [8086:3429] type 0 class 0x000880
[    0.229550] pci 0000:00:16.4: reg 10: [mem 0xb1b10000-0xb1b13fff 64bit]
[    0.229669] pci 0000:00:16.5: [8086:342a] type 0 class 0x000880
[    0.229688] pci 0000:00:16.5: reg 10: [mem 0xb1b14000-0xb1b17fff 64bit]
[    0.229807] pci 0000:00:16.6: [8086:342b] type 0 class 0x000880
[    0.229826] pci 0000:00:16.6: reg 10: [mem 0xb1b18000-0xb1b1bfff 64bit]
[    0.229945] pci 0000:00:16.7: [8086:342c] type 0 class 0x000880
[    0.229963] pci 0000:00:16.7: reg 10: [mem 0xb1b1c000-0xb1b1ffff 64bit]
[    0.230085] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03
[    0.230150] pci 0000:00:1a.0: reg 20: [io  0x30e0-0x30ff]
[    0.230227] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03
[    0.230293] pci 0000:00:1a.1: reg 20: [io  0x30c0-0x30df]
[    0.230401] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03
[    0.230466] pci 0000:00:1a.2: reg 20: [io  0x30a0-0x30bf]
[    0.230558] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03
[    0.230588] pci 0000:00:1a.7: reg 10: [mem 0xb1b22000-0xb1b223ff]
[    0.230722] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    0.230727] pci 0000:00:1a.7: PME# disabled
[    0.230757] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604
[    0.230868] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.230872] pci 0000:00:1c.0: PME# disabled
[    0.230909] pci 0000:00:1c.4: [8086:3a48] type 1 class 0x000604
[    0.231021] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    0.231025] pci 0000:00:1c.4: PME# disabled
[    0.231058] pci 0000:00:1c.5: [8086:3a4a] type 1 class 0x000604
[    0.231168] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    0.231173] pci 0000:00:1c.5: PME# disabled
[    0.231208] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03
[    0.231273] pci 0000:00:1d.0: reg 20: [io  0x3080-0x309f]
[    0.231350] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03
[    0.231415] pci 0000:00:1d.1: reg 20: [io  0x3060-0x307f]
[    0.231492] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03
[    0.231557] pci 0000:00:1d.2: reg 20: [io  0x3040-0x305f]
[    0.231648] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03
[    0.231678] pci 0000:00:1d.7: reg 10: [mem 0xb1b21000-0xb1b213ff]
[    0.231813] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    0.231818] pci 0000:00:1d.7: PME# disabled
[    0.231846] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604
[    0.231948] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601
[    0.232027] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 000f)
[    0.232031] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)
[    0.232034] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0600 (mask 001f)
[    0.232105] pci 0000:00:1f.2: [8086:3a22] type 0 class 0x000106
[    0.232134] pci 0000:00:1f.2: reg 10: [io  0x3108-0x310f]
[    0.232146] pci 0000:00:1f.2: reg 14: [io  0x3114-0x3117]
[    0.232157] pci 0000:00:1f.2: reg 18: [io  0x3100-0x3107]
[    0.232168] pci 0000:00:1f.2: reg 1c: [io  0x3110-0x3113]
[    0.232180] pci 0000:00:1f.2: reg 20: [io  0x3020-0x303f]
[    0.232191] pci 0000:00:1f.2: reg 24: [mem 0xb1b20000-0xb1b207ff]
[    0.232265] pci 0000:00:1f.2: PME# supported from D3hot
[    0.232269] pci 0000:00:1f.2: PME# disabled
[    0.232293] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05
[    0.232315] pci 0000:00:1f.3: reg 10: [mem 0xb1b23000-0xb1b230ff 64bit]
[    0.232348] pci 0000:00:1f.3: reg 20: [io  0x3000-0x301f]
[    0.232469] pci 0000:01:00.0: [8086:10c9] type 0 class 0x000200
[    0.232487] pci 0000:01:00.0: reg 10: [mem 0xb1a20000-0xb1a3ffff]
[    0.232511] pci 0000:01:00.0: reg 18: [io  0x2020-0x203f]
[    0.232523] pci 0000:01:00.0: reg 1c: [mem 0xb1ac4000-0xb1ac7fff]
[    0.232625] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    0.232630] pci 0000:01:00.0: PME# disabled
[    0.232675] pci 0000:01:00.0: reg 184: [mem 0xb1a40000-0xb1a43fff 64bit]
[    0.232695] pci 0000:01:00.0: reg 190: [mem 0xb1a60000-0xb1a63fff 64bit]
[    0.232737] pci 0000:01:00.1: [8086:10c9] type 0 class 0x000200
[    0.232753] pci 0000:01:00.1: reg 10: [mem 0xb1a00000-0xb1a1ffff]
[    0.232777] pci 0000:01:00.1: reg 18: [io  0x2000-0x201f]
[    0.232790] pci 0000:01:00.1: reg 1c: [mem 0xb1ac0000-0xb1ac3fff]
[    0.232892] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
[    0.232896] pci 0000:01:00.1: PME# disabled
[    0.232934] pci 0000:01:00.1: reg 184: [mem 0xb1a80000-0xb1a83fff 64bit]
[    0.232954] pci 0000:01:00.1: reg 190: [mem 0xb1aa0000-0xb1aa3fff 64bit]
[    0.232984] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    0.232988] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    0.232992] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    0.232999] pci 0000:00:01.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233058] pci 0000:00:03.0: PCI bridge to [bus 04-04]
[    0.233062] pci 0000:00:03.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.233066] pci 0000:00:03.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233073] pci 0000:00:03.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233147] pci 0000:05:00.0: [111d:806a] type 1 class 0x000604
[    0.233255] pci 0000:05:00.0: PME# supported from D0 D3hot D3cold
[    0.233260] pci 0000:05:00.0: PME# disabled
[    0.233286] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    0.233290] pci 0000:00:05.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.233295] pci 0000:00:05.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233301] pci 0000:00:05.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233371] pci 0000:06:02.0: [111d:806a] type 1 class 0x000604
[    0.233523] pci 0000:06:02.0: PME# supported from D0 D3hot D3cold
[    0.233528] pci 0000:06:02.0: PME# disabled
[    0.233566] pci 0000:06:04.0: [111d:806a] type 1 class 0x000604
[    0.233687] pci 0000:06:04.0: PME# supported from D0 D3hot D3cold
[    0.233692] pci 0000:06:04.0: PME# disabled
[    0.233751] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    0.233760] pci 0000:05:00.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.233765] pci 0000:05:00.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233774] pci 0000:05:00.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233837] pci 0000:06:02.0: PCI bridge to [bus 07-07]
[    0.233846] pci 0000:06:02.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.233851] pci 0000:06:02.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233860] pci 0000:06:02.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233924] pci 0000:06:04.0: PCI bridge to [bus 08-08]
[    0.233932] pci 0000:06:04.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.233938] pci 0000:06:04.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233946] pci 0000:06:04.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234047] pci 0000:09:00.0: [111d:806a] type 1 class 0x000604
[    0.234154] pci 0000:09:00.0: PME# supported from D0 D3hot D3cold
[    0.234159] pci 0000:09:00.0: PME# disabled
[    0.234186] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    0.234190] pci 0000:00:07.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.234194] pci 0000:00:07.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234201] pci 0000:00:07.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234271] pci 0000:0a:02.0: [111d:806a] type 1 class 0x000604
[    0.234392] pci 0000:0a:02.0: PME# supported from D0 D3hot D3cold
[    0.234397] pci 0000:0a:02.0: PME# disabled
[    0.234435] pci 0000:0a:04.0: [111d:806a] type 1 class 0x000604
[    0.234556] pci 0000:0a:04.0: PME# supported from D0 D3hot D3cold
[    0.234561] pci 0000:0a:04.0: PME# disabled
[    0.234619] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    0.234628] pci 0000:09:00.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.234633] pci 0000:09:00.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234642] pci 0000:09:00.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234705] pci 0000:0a:02.0: PCI bridge to [bus 0b-0b]
[    0.234713] pci 0000:0a:02.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.234719] pci 0000:0a:02.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234727] pci 0000:0a:02.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234791] pci 0000:0a:04.0: PCI bridge to [bus 0c-0c]
[    0.234800] pci 0000:0a:04.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.234805] pci 0000:0a:04.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234814] pci 0000:0a:04.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234899] pci 0000:00:09.0: PCI bridge to [bus 0d-0d]
[    0.234903] pci 0000:00:09.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.234908] pci 0000:00:09.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234914] pci 0000:00:09.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234973] pci 0000:00:0a.0: PCI bridge to [bus 0e-0e]
[    0.234977] pci 0000:00:0a.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.234981] pci 0000:00:0a.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234988] pci 0000:00:0a.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235066] pci 0000:0f:00.0: [1000:0062] type 0 class 0x000100
[    0.235093] pci 0000:0f:00.0: reg 10: [mem 0xb1940000-0xb1943fff 64bit]
[    0.235108] pci 0000:0f:00.0: reg 18: [io  0x1000-0x10ff]
[    0.235130] pci 0000:0f:00.0: reg 1c: [mem 0xb1900000-0xb193ffff 64bit]
[    0.235159] pci 0000:0f:00.0: reg 30: [mem 0xfff80000-0xffffffff pref]
[    0.235244] pci 0000:0f:00.0: supports D1
[    0.235279] pci 0000:00:1c.0: PCI bridge to [bus 0f-0f]
[    0.235283] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    0.235287] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    0.235295] pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235381] pci 0000:10:00.0: [102b:0522] type 0 class 0x000300
[    0.235406] pci 0000:10:00.0: reg 10: [mem 0xb0000000-0xb0ffffff pref]
[    0.235424] pci 0000:10:00.0: reg 14: [mem 0xb1800000-0xb1803fff]
[    0.235442] pci 0000:10:00.0: reg 18: [mem 0xb1000000-0xb17fffff]
[    0.235511] pci 0000:10:00.0: reg 30: [mem 0xffff0000-0xffffffff pref]
[    0.235633] pci 0000:00:1c.4: PCI bridge to [bus 10-10]
[    0.235638] pci 0000:00:1c.4:   bridge window [io  0xf000-0x0000] (disabled)
[    0.235642] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    0.235650] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    0.235711] pci 0000:00:1c.5: PCI bridge to [bus 11-11]
[    0.235716] pci 0000:00:1c.5:   bridge window [io  0xf000-0x0000] (disabled)
[    0.235720] pci 0000:00:1c.5:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.235727] pci 0000:00:1c.5:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235816] pci 0000:00:1e.0: PCI bridge to [bus 12-12] (subtractive decode)
[    0.235820] pci 0000:00:1e.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.235824] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.235832] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235834] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    0.235835] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    0.235837] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    0.235839] pci 0000:00:1e.0:   bridge window [mem 0xfed40000-0xfedfffff] (subtractive decode)
[    0.235841] pci 0000:00:1e.0:   bridge window [mem 0xb0000000-0xfdffffff] (subtractive decode)
[    0.235903] pci_bus 0000:00: on NUMA node 0
[    0.235906] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.244723] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP1._PRT]
[    0.244763] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP3._PRT]
[    0.244794] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP5._PRT]
[    0.244826] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP7._PRT]
[    0.244857] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP9._PRT]
[    0.244902] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRPA._PRT]
[    0.244954] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[    0.244986] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[    0.245110]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.245237]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.256319] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    0.256380] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    0.256441] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[    0.256499] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
[    0.256559] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256618] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256677] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256736] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256790] pci 0000:00:00.0: GSI47: level-low
[    0.256817] pci 0000:00:01.0: GSI28: level-low
[    0.256843] pci 0000:00:03.0: GSI24: level-low
[    0.256869] pci 0000:00:05.0: GSI26: level-low
[    0.256895] pci 0000:00:07.0: GSI30: level-low
[    0.256920] pci 0000:00:09.0: GSI32: level-low
[    0.256946] pci 0000:00:0a.0: GSI33: level-low
[    0.256975] pci 0000:00:16.0: GSI43: level-low
[    0.257001] pci 0000:00:16.1: GSI44: level-low
[    0.257027] pci 0000:00:16.2: GSI45: level-low
[    0.257053] pci 0000:00:16.3: GSI46: level-low
[    0.257083] pci 0000:00:1a.0: GSI19: level-low
[    0.257110] pci 0000:00:1c.0: GSI16: level-low
[    0.257136] pci 0000:00:1c.5: GSI17: level-low
[    0.257164] pci 0000:00:1f.2: GSI18: level-low
[    0.257191] pci 0000:01:00.0: GSI40: level-low
[    0.257250] vgaarb: device added: PCI:0000:10:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.257252] vgaarb: loaded
[    0.257363] xen_mem: Initialising balloon driver.
[    0.257522] PCI: Using ACPI for IRQ routing
[    0.268063] PCI: Discovered peer bus fe
[    0.268090] pci 0000:fe:00.0: [8086:2c70] type 0 class 0x000600
[    0.268138] pci 0000:fe:00.1: [8086:2d81] type 0 class 0x000600
[    0.268190] pci 0000:fe:02.0: [8086:2d90] type 0 class 0x000600
[    0.268235] pci 0000:fe:02.1: [8086:2d91] type 0 class 0x000600
[    0.268281] pci 0000:fe:02.2: [8086:2d92] type 0 class 0x000600
[    0.268326] pci 0000:fe:02.3: [8086:2d93] type 0 class 0x000600
[    0.268370] pci 0000:fe:02.4: [8086:2d94] type 0 class 0x000600
[    0.268415] pci 0000:fe:02.5: [8086:2d95] type 0 class 0x000600
[    0.268462] pci 0000:fe:03.0: [8086:2d98] type 0 class 0x000600
[    0.268506] pci 0000:fe:03.1: [8086:2d99] type 0 class 0x000600
[    0.268551] pci 0000:fe:03.2: [8086:2d9a] type 0 class 0x000600
[    0.268597] pci 0000:fe:03.4: [8086:2d9c] type 0 class 0x000600
[    0.268644] pci 0000:fe:04.0: [8086:2da0] type 0 class 0x000600
[    0.268689] pci 0000:fe:04.1: [8086:2da1] type 0 class 0x000600
[    0.268734] pci 0000:fe:04.2: [8086:2da2] type 0 class 0x000600
[    0.268778] pci 0000:fe:04.3: [8086:2da3] type 0 class 0x000600
[    0.268827] pci 0000:fe:05.0: [8086:2da8] type 0 class 0x000600
[    0.268872] pci 0000:fe:05.1: [8086:2da9] type 0 class 0x000600
[    0.268917] pci 0000:fe:05.2: [8086:2daa] type 0 class 0x000600
[    0.268961] pci 0000:fe:05.3: [8086:2dab] type 0 class 0x000600
[    0.269010] pci 0000:fe:06.0: [8086:2db0] type 0 class 0x000600
[    0.269055] pci 0000:fe:06.1: [8086:2db1] type 0 class 0x000600
[    0.269100] pci 0000:fe:06.2: [8086:2db2] type 0 class 0x000600
[    0.269144] pci 0000:fe:06.3: [8086:2db3] type 0 class 0x000600
[    0.269611] PCI: Discovered peer bus ff
[    0.269635] pci 0000:ff:00.0: [8086:2c70] type 0 class 0x000600
[    0.269678] pci 0000:ff:00.1: [8086:2d81] type 0 class 0x000600
[    0.269728] pci 0000:ff:02.0: [8086:2d90] type 0 class 0x000600
[    0.269770] pci 0000:ff:02.1: [8086:2d91] type 0 class 0x000600
[    0.269813] pci 0000:ff:02.2: [8086:2d92] type 0 class 0x000600
[    0.269855] pci 0000:ff:02.3: [8086:2d93] type 0 class 0x000600
[    0.269898] pci 0000:ff:02.4: [8086:2d94] type 0 class 0x000600
[    0.269940] pci 0000:ff:02.5: [8086:2d95] type 0 class 0x000600
[    0.269985] pci 0000:ff:03.0: [8086:2d98] type 0 class 0x000600
[    0.270058] pci 0000:ff:03.1: [8086:2d99] type 0 class 0x000600
[    0.270100] pci 0000:ff:03.2: [8086:2d9a] type 0 class 0x000600
[    0.270143] pci 0000:ff:03.4: [8086:2d9c] type 0 class 0x000600
[    0.270190] pci 0000:ff:04.0: [8086:2da0] type 0 class 0x000600
[    0.270233] pci 0000:ff:04.1: [8086:2da1] type 0 class 0x000600
[    0.270275] pci 0000:ff:04.2: [8086:2da2] type 0 class 0x000600
[    0.270317] pci 0000:ff:04.3: [8086:2da3] type 0 class 0x000600
[    0.270364] pci 0000:ff:05.0: [8086:2da8] type 0 class 0x000600
[    0.270406] pci 0000:ff:05.1: [8086:2da9] type 0 class 0x000600
[    0.270448] pci 0000:ff:05.2: [8086:2daa] type 0 class 0x000600
[    0.270492] pci 0000:ff:05.3: [8086:2dab] type 0 class 0x000600
[    0.270538] pci 0000:ff:06.0: [8086:2db0] type 0 class 0x000600
[    0.270580] pci 0000:ff:06.1: [8086:2db1] type 0 class 0x000600
[    0.270623] pci 0000:ff:06.2: [8086:2db2] type 0 class 0x000600
[    0.270665] pci 0000:ff:06.3: [8086:2db3] type 0 class 0x000600
[    0.271125] PCI: pci_cache_line_size set to 64 bytes
[    0.271437] reserve RAM buffer: 000000000009b000 - 000000000009ffff 
[    0.271439] reserve RAM buffer: 000000008c21c000 - 000000008fffffff 
[    0.271511] NetLabel: Initializing
[    0.271512] NetLabel:  domain hash size = 128
[    0.271513] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.271524] NetLabel:  unlabeled traffic allowed by default
[    0.271554] Switching to clocksource xen
[    0.272184] Switched to NOHz mode on CPU #7
[    0.272367] Switched to NOHz mode on CPU #16
[    0.272656] Switched to NOHz mode on CPU #12
[    0.272902] Switched to NOHz mode on CPU #21
[    0.273272] Switched to NOHz mode on CPU #8
[    0.273435] Switched to NOHz mode on CPU #17
[    0.273658] Switched to NOHz mode on CPU #4
[    0.273669] Switched to NOHz mode on CPU #13
[    0.273888] Switched to NOHz mode on CPU #22
[    0.274082] AppArmor: AppArmor Filesystem Enabled
[    0.274096] pnp: PnP ACPI init
[    0.274106] ACPI: bus type pnp registered
[    0.274076] Switched to NOHz mode on CPU #9
[    0.274129] Switched to NOHz mode on CPU #1
[    0.274391] pnp 00:00: [bus 00-fd]
[    0.274393] pnp 00:00: [io  0x0cf8-0x0cff]
[    0.274395] pnp 00:00: [io  0x0000-0x0cf7 window]
[    0.274396] pnp 00:00: [io  0x0d00-0xffff window]
[    0.274398] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    0.274399] pnp 00:00: [mem 0x000c4000-0x000cbfff window]
[    0.274401] pnp 00:00: [mem 0xfed40000-0xfedfffff window]
[    0.274323] Switched to NOHz mode on CPU #18
[    0.274407] pnp 00:00: [mem 0xb0000000-0xfdffffff window]
[    0.274408] pnp 00:00: [mem 0x00000000 window]
[    0.274447] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)
[    0.274455] pnp 00:01: [mem 0xfec00000-0xfecfffff]
[    0.274471] pnp 00:01: Plug and Play ACPI device, IDs PNP0003 (active)
[    0.274458] Switched to NOHz mode on CPU #5
[    0.274634] pnp 00:02: [io  0x0000-0x000f]
[    0.274635] pnp 00:02: [io  0x0081-0x0083]
[    0.274636] pnp 00:02: [io  0x0087]
[    0.274638] pnp 00:02: [io  0x0089-0x008b]
[    0.274639] pnp 00:02: [io  0x008f]
[    0.274640] pnp 00:02: [io  0x00c0-0x00df]
[    0.274642] pnp 00:02: [dma 4]
[    0.274672] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.274679] pnp 00:03: [io  0x0070-0x0071]
[    0.274680] pnp 00:03: [io  0x0074-0x0077]
[    0.274709] pnp 00:03: [irq 8]
[    0.274736] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.274744] pnp 00:04: [io  0x00f0]
[    0.274770] pnp 00:04: [irq 13]
[    0.274799] pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.274807] pnp 00:05: [io  0x0061]
[    0.274741] Switched to NOHz mode on CPU #14
[    0.274834] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.274780] Switched to NOHz mode on CPU #23
[    0.274875] pnp 00:06: [mem 0xfed00000-0xfed003ff]
[    0.274906] pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.274917] pnp 00:07: [io  0x0500-0x057f]
[    0.274918] pnp 00:07: [io  0x0400-0x047f]
[    0.274919] pnp 00:07: [io  0x0092]
[    0.274920] pnp 00:07: [io  0x0010-0x001f]
[    0.274922] pnp 00:07: [io  0x0072-0x0073]
[    0.274923] pnp 00:07: [io  0x0080]
[    0.274924] pnp 00:07: [io  0x0084-0x0086]
[    0.274925] pnp 00:07: [io  0x0088]
[    0.274926] pnp 00:07: [io  0x008c-0x008e]
[    0.274928] pnp 00:07: [io  0x0090-0x009f]
[    0.274929] pnp 00:07: [io  0x0800-0x081f]
[    0.274930] pnp 00:07: [io  0x0ca2-0x0ca3]
[    0.274931] pnp 00:07: [io  0x0600-0x061f]
[    0.274932] pnp 00:07: [io  0x0880-0x0883]
[    0.274933] pnp 00:07: [io  0x0ca4-0x0ca5]
[    0.274934] pnp 00:07: [mem 0xfed1c000-0xfed3fffe]
[    0.274936] pnp 00:07: [mem 0xff000000-0xffffffff]
[    0.274937] pnp 00:07: [mem 0xfee00000-0xfeefffff]
[    0.274938] pnp 00:07: [mem 0xfe900000-0xfe90001f]
[    0.274939] pnp 00:07: [mem 0xfea00000-0xfea0001f]
[    0.274941] pnp 00:07: [mem 0xfed1b000-0xfed1bfff]
[    0.275024] system 00:07: [io  0x0500-0x057f] has been reserved
[    0.275026] system 00:07: [io  0x0400-0x047f] has been reserved
[    0.275028] system 00:07: [io  0x0800-0x081f] has been reserved
[    0.275030] system 00:07: [io  0x0ca2-0x0ca3] has been reserved
[    0.275032] system 00:07: [io  0x0600-0x061f] has been reserved
[    0.275034] system 00:07: [io  0x0880-0x0883] has been reserved
[    0.275036] system 00:07: [io  0x0ca4-0x0ca5] has been reserved
[    0.275039] system 00:07: [mem 0xfed1c000-0xfed3fffe] could not be reserved
[    0.275040] system 00:07: [mem 0xff000000-0xffffffff] could not be reserved
[    0.275042] system 00:07: [mem 0xfee00000-0xfeefffff] could not be reserved
[    0.275044] system 00:07: [mem 0xfe900000-0xfe90001f] has been reserved
[    0.275046] system 00:07: [mem 0xfea00000-0xfea0001f] has been reserved
[    0.275048] system 00:07: [mem 0xfed1b000-0xfed1bfff] has been reserved
[    0.275050] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.274974] Switched to NOHz mode on CPU #10
[    0.275224] pnp 00:08: [io  0x02f8-0x02ff]
[    0.275161] Switched to NOHz mode on CPU #19
[    0.275252] pnp 00:08: [irq 3]
[    0.275320] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.275346] pnp 00:09: [mem 0xfed40000-0xfed44fff]
[    0.275376] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active)
[    0.275318] Switched to NOHz mode on CPU #2
[    0.275407] pnp 00:0a: [io  0x0ca2]
[    0.275408] pnp 00:0a: [io  0x0ca3]
[    0.275438] pnp 00:0a: Plug and Play ACPI device, IDs IPI0001 (active)
[    0.275480] pnp: PnP ACPI: found 11 devices
[    0.275481] ACPI: ACPI bus type pnp unregistered
[    0.275434] Switched to NOHz mode on CPU #6
[    0.275612] Switched to NOHz mode on CPU #15
[    0.275787] Switched to NOHz mode on CPU #11
[    0.275818] Switched to NOHz mode on CPU #3
[    0.275978] Switched to NOHz mode on CPU #0
[    0.276097] Switched to NOHz mode on CPU #20
[    0.276391] pci 0000:0f:00.0: no compatible bridge window for [mem 0xfff80000-0xffffffff pref]
[    0.276394] pci 0000:10:00.0: no compatible bridge window for [mem 0xffff0000-0xffffffff pref]
[    0.276411] PCI: max bus depth: 3 pci_try_num: 4
[    0.276590] pci 0000:00:1c.0: BAR 15: assigned [mem 0xb1c00000-0xb1cfffff pref]
[    0.276594] pci 0000:00:1c.5: BAR 14: assigned [mem 0xb1d00000-0xb1efffff]
[    0.276597] pci 0000:00:1c.5: BAR 15: assigned [mem 0xb1f00000-0xb20fffff 64bit pref]
[    0.276599] pci 0000:00:1c.5: BAR 13: assigned [io  0x4000-0x4fff]
[    0.276601] pci 0000:00:1c.4: BAR 13: assigned [io  0x5000-0x5fff]
[    0.276604] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    0.276607] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    0.276612] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    0.276616] pci 0000:00:01.0:   bridge window [mem pref disabled]
[    0.276623] pci 0000:00:03.0: PCI bridge to [bus 04-04]
[    0.276624] pci 0000:00:03.0:   bridge window [io  disabled]
[    0.276629] pci 0000:00:03.0:   bridge window [mem disabled]
[    0.276633] pci 0000:00:03.0:   bridge window [mem pref disabled]
[    0.276639] pci 0000:06:02.0: PCI bridge to [bus 07-07]
[    0.276641] pci 0000:06:02.0:   bridge window [io  disabled]
[    0.276647] pci 0000:06:02.0:   bridge window [mem disabled]
[    0.276652] pci 0000:06:02.0:   bridge window [mem pref disabled]
[    0.276661] pci 0000:06:04.0: PCI bridge to [bus 08-08]
[    0.276662] pci 0000:06:04.0:   bridge window [io  disabled]
[    0.276669] pci 0000:06:04.0:   bridge window [mem disabled]
[    0.276674] pci 0000:06:04.0:   bridge window [mem pref disabled]
[    0.276683] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    0.276684] pci 0000:05:00.0:   bridge window [io  disabled]
[    0.276691] pci 0000:05:00.0:   bridge window [mem disabled]
[    0.276696] pci 0000:05:00.0:   bridge window [mem pref disabled]
[    0.276705] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    0.276706] pci 0000:00:05.0:   bridge window [io  disabled]
[    0.276711] pci 0000:00:05.0:   bridge window [mem disabled]
[    0.276715] pci 0000:00:05.0:   bridge window [mem pref disabled]
[    0.276722] pci 0000:0a:02.0: PCI bridge to [bus 0b-0b]
[    0.276723] pci 0000:0a:02.0:   bridge window [io  disabled]
[    0.276730] pci 0000:0a:02.0:   bridge window [mem disabled]
[    0.276734] pci 0000:0a:02.0:   bridge window [mem pref disabled]
[    0.276743] pci 0000:0a:04.0: PCI bridge to [bus 0c-0c]
[    0.276744] pci 0000:0a:04.0:   bridge window [io  disabled]
[    0.276751] pci 0000:0a:04.0:   bridge window [mem disabled]
[    0.276756] pci 0000:0a:04.0:   bridge window [mem pref disabled]
[    0.276765] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    0.276766] pci 0000:09:00.0:   bridge window [io  disabled]
[    0.276773] pci 0000:09:00.0:   bridge window [mem disabled]
[    0.276778] pci 0000:09:00.0:   bridge window [mem pref disabled]
[    0.276787] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    0.276788] pci 0000:00:07.0:   bridge window [io  disabled]
[    0.276793] pci 0000:00:07.0:   bridge window [mem disabled]
[    0.276797] pci 0000:00:07.0:   bridge window [mem pref disabled]
[    0.276803] pci 0000:00:09.0: PCI bridge to [bus 0d-0d]
[    0.276804] pci 0000:00:09.0:   bridge window [io  disabled]
[    0.276809] pci 0000:00:09.0:   bridge window [mem disabled]
[    0.276813] pci 0000:00:09.0:   bridge window [mem pref disabled]
[    0.276820] pci 0000:00:0a.0: PCI bridge to [bus 0e-0e]
[    0.276823] pci 0000:00:0a.0:   bridge window [io  disabled]
[    0.276828] pci 0000:00:0a.0:   bridge window [mem disabled]
[    0.276832] pci 0000:00:0a.0:   bridge window [mem pref disabled]
[    0.276840] pci 0000:0f:00.0: BAR 6: assigned [mem 0xb1c00000-0xb1c7ffff pref]
[    0.276842] pci 0000:00:1c.0: PCI bridge to [bus 0f-0f]
[    0.276845] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    0.276850] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    0.276855] pci 0000:00:1c.0:   bridge window [mem 0xb1c00000-0xb1cfffff pref]
[    0.276863] pci 0000:10:00.0: BAR 6: assigned [mem 0xb1810000-0xb181ffff pref]
[    0.276864] pci 0000:00:1c.4: PCI bridge to [bus 10-10]
[    0.276867] pci 0000:00:1c.4:   bridge window [io  0x5000-0x5fff]
[    0.276873] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    0.276877] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    0.276884] pci 0000:00:1c.5: PCI bridge to [bus 11-11]
[    0.276887] pci 0000:00:1c.5:   bridge window [io  0x4000-0x4fff]
[    0.276893] pci 0000:00:1c.5:   bridge window [mem 0xb1d00000-0xb1efffff]
[    0.276897] pci 0000:00:1c.5:   bridge window [mem 0xb1f00000-0xb20fffff 64bit pref]
[    0.276905] pci 0000:00:1e.0: PCI bridge to [bus 12-12]
[    0.276906] pci 0000:00:1e.0:   bridge window [io  disabled]
[    0.276911] pci 0000:00:1e.0:   bridge window [mem disabled]
[    0.276915] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    0.276938] pci 0000:00:01.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    0.276943] pci 0000:00:01.0: setting latency timer to 64
[    0.276953] pci 0000:00:03.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
[    0.276957] pci 0000:00:03.0: setting latency timer to 64
[    0.276967] pci 0000:00:05.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
[    0.276971] pci 0000:00:05.0: setting latency timer to 64
[    0.276981] pci 0000:05:00.0: setting latency timer to 64
[    0.276991] pci 0000:06:02.0: setting latency timer to 64
[    0.277001] pci 0000:06:04.0: setting latency timer to 64
[    0.277013] pci 0000:00:07.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
[    0.277017] pci 0000:00:07.0: setting latency timer to 64
[    0.277027] pci 0000:09:00.0: setting latency timer to 64
[    0.277037] pci 0000:0a:02.0: setting latency timer to 64
[    0.277048] pci 0000:0a:04.0: setting latency timer to 64
[    0.277058] pci 0000:00:09.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
[    0.277062] pci 0000:00:09.0: setting latency timer to 64
[    0.277071] pci 0000:00:0a.0: PCI INT A -> GSI 33 (level, low) -> IRQ 33
[    0.277075] pci 0000:00:0a.0: setting latency timer to 64
[    0.277085] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.277090] pci 0000:00:1c.0: setting latency timer to 64
[    0.277097] pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.277101] pci 0000:00:1c.4: setting latency timer to 64
[    0.277111] pci 0000:00:1c.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    0.277116] pci 0000:00:1c.5: setting latency timer to 64
[    0.277123] pci 0000:00:1e.0: setting latency timer to 64
[    0.277128] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.277129] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.277131] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.277132] pci_bus 0000:00: resource 7 [mem 0xfed40000-0xfedfffff]
[    0.277134] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xfdffffff]
[    0.277135] pci_bus 0000:01: resource 0 [io  0x2000-0x2fff]
[    0.277136] pci_bus 0000:01: resource 1 [mem 0xb1a00000-0xb1afffff]
[    0.277139] pci_bus 0000:0f: resource 0 [io  0x1000-0x1fff]
[    0.277140] pci_bus 0000:0f: resource 1 [mem 0xb1900000-0xb19fffff]
[    0.277142] pci_bus 0000:0f: resource 2 [mem 0xb1c00000-0xb1cfffff pref]
[    0.277143] pci_bus 0000:10: resource 0 [io  0x5000-0x5fff]
[    0.277145] pci_bus 0000:10: resource 1 [mem 0xb1000000-0xb18fffff]
[    0.277146] pci_bus 0000:10: resource 2 [mem 0xb0000000-0xb0ffffff 64bit pref]
[    0.277148] pci_bus 0000:11: resource 0 [io  0x4000-0x4fff]
[    0.277149] pci_bus 0000:11: resource 1 [mem 0xb1d00000-0xb1efffff]
[    0.277151] pci_bus 0000:11: resource 2 [mem 0xb1f00000-0xb20fffff 64bit pref]
[    0.277153] pci_bus 0000:12: resource 4 [io  0x0000-0x0cf7]
[    0.277154] pci_bus 0000:12: resource 5 [io  0x0d00-0xffff]
[    0.277155] pci_bus 0000:12: resource 6 [mem 0x000a0000-0x000bffff]
[    0.277157] pci_bus 0000:12: resource 7 [mem 0xfed40000-0xfedfffff]
[    0.277158] pci_bus 0000:12: resource 8 [mem 0xb0000000-0xfdffffff]
[    0.277160] pci_bus 0000:fe: resource 0 [io  0x0000-0xffff]
[    0.277161] pci_bus 0000:fe: resource 1 [mem 0x00000000-0xffffffffff]
[    0.277163] pci_bus 0000:ff: resource 0 [io  0x0000-0xffff]
[    0.277165] pci_bus 0000:ff: resource 1 [mem 0x00000000-0xffffffffff]
[    0.279638] NET: Registered protocol family 2
[    0.280515] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.283580] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    0.284178] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.284311] TCP: Hash tables configured (established 262144 bind 65536)
[    0.284313] TCP reno registered
[    0.284318] UDP hash table entries: 16384 (order: 8, 1048576 bytes)
[    0.284452] UDP-Lite hash table entries: 16384 (order: 8, 1048576 bytes)
[    0.285968] NET: Registered protocol family 1
[    0.286204] pci 0000:00:1a.0: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286226] pci 0000:00:1a.0: PCI INT D disabled
[    0.286239] pci 0000:00:1a.1: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286260] pci 0000:00:1a.1: PCI INT D disabled
[    0.286272] pci 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286292] pci 0000:00:1a.2: PCI INT D disabled
[    0.286314] pci 0000:00:1a.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286836] pci 0000:00:1a.7: PCI INT D disabled
[    0.286870] pci 0000:00:1d.0: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.286893] pci 0000:00:1d.0: PCI INT D disabled
[    0.286906] pci 0000:00:1d.1: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.286926] pci 0000:00:1d.1: PCI INT D disabled
[    0.286938] pci 0000:00:1d.2: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.286958] pci 0000:00:1d.2: PCI INT D disabled
[    0.286980] pci 0000:00:1d.7: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.287102] pci 0000:00:1d.7: PCI INT D disabled
[    0.287251] pci 0000:10:00.0: Boot video device
[    0.287384] PCI: CLS 64 bytes, default 64
[    0.287425] Unpacking initramfs...
[    0.297648] Freeing initrd memory: 17484k freed
[    0.302827] MCE: bind virq for DOM0 logging
[    0.303235] MCE_DOM0_LOG: enter dom0 mce vIRQ handler
[    0.303236] MCE_DOM0_LOG: No more urgent data
[    0.303237] MCE_DOM0_LOG: No more nonurgent data
[    0.305384] audit: initializing netlink socket (disabled)
[    0.305397] type=2000 audit(1359974461.304:1): initialized
[    0.340373] VFS: Disk quotas dquot_6.5.2
[    0.340797] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.341206] msgmni has been set to 12038
[    0.341815] alg: No test for stdrng (krng)
[    0.342224] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.342297] io scheduler noop registered
[    0.342298] io scheduler deadline registered
[    0.343033] io scheduler cfq registered (default)
[    0.343618] pcieport 0000:00:01.0: setting latency timer to 64
[    0.343699] pcieport 0000:00:01.0: irq 68 (303) for MSI/MSI-X
[    0.343786] pcieport 0000:00:03.0: setting latency timer to 64
[    0.343851] pcieport 0000:00:03.0: irq 69 (302) for MSI/MSI-X
[    0.343933] pcieport 0000:00:05.0: setting latency timer to 64
[    0.343997] pcieport 0000:00:05.0: irq 70 (301) for MSI/MSI-X
[    0.344080] pcieport 0000:00:07.0: setting latency timer to 64
[    0.344182] pcieport 0000:00:07.0: irq 71 (300) for MSI/MSI-X
[    0.344266] pcieport 0000:00:09.0: setting latency timer to 64
[    0.344332] pcieport 0000:00:09.0: irq 72 (299) for MSI/MSI-X
[    0.344413] pcieport 0000:00:0a.0: setting latency timer to 64
[    0.344479] pcieport 0000:00:0a.0: irq 73 (298) for MSI/MSI-X
[    0.344567] pcieport 0000:00:1c.0: setting latency timer to 64
[    0.344639] pcieport 0000:00:1c.0: irq 74 (297) for MSI/MSI-X
[    0.344736] pcieport 0000:00:1c.4: setting latency timer to 64
[    0.344810] pcieport 0000:00:1c.4: irq 75 (296) for MSI/MSI-X
[    0.344906] pcieport 0000:00:1c.5: setting latency timer to 64
[    0.344977] pcieport 0000:00:1c.5: irq 76 (295) for MSI/MSI-X
[    0.345074] pcieport 0000:05:00.0: setting latency timer to 64
[    0.345180] pcieport 0000:06:02.0: setting latency timer to 64
[    0.345281] pcieport 0000:06:02.0: irq 77 (294) for MSI/MSI-X
[    0.345383] pcieport 0000:06:04.0: setting latency timer to 64
[    0.345484] pcieport 0000:06:04.0: irq 78 (293) for MSI/MSI-X
[    0.345586] pcieport 0000:09:00.0: setting latency timer to 64
[    0.345692] pcieport 0000:0a:02.0: setting latency timer to 64
[    0.345793] pcieport 0000:0a:02.0: irq 79 (292) for MSI/MSI-X
[    0.345899] pcieport 0000:0a:04.0: setting latency timer to 64
[    0.345999] pcieport 0000:0a:04.0: irq 80 (291) for MSI/MSI-X
[    0.346135] aer 0000:00:01.0:pcie02: service driver aer loaded
[    0.346169] aer 0000:00:03.0:pcie02: service driver aer loaded
[    0.346215] aer 0000:00:05.0:pcie02: service driver aer loaded
[    0.346263] aer 0000:00:07.0:pcie02: service driver aer loaded
[    0.346295] aer 0000:00:09.0:pcie02: service driver aer loaded
[    0.346327] aer 0000:00:0a.0:pcie02: service driver aer loaded
[    0.346343] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[    0.346344] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    0.346346] pci 0000:01:00.1: Signaling PME through PCIe PME interrupt
[    0.346350] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[    0.346358] pcieport 0000:00:03.0: Signaling PME through PCIe PME interrupt
[    0.346362] pcie_pme 0000:00:03.0:pcie01: service driver pcie_pme loaded
[    0.346371] pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt
[    0.346372] pcieport 0000:05:00.0: Signaling PME through PCIe PME interrupt
[    0.346373] pcieport 0000:06:02.0: Signaling PME through PCIe PME interrupt
[    0.346375] pcieport 0000:06:04.0: Signaling PME through PCIe PME interrupt
[    0.346379] pcie_pme 0000:00:05.0:pcie01: service driver pcie_pme loaded
[    0.346387] pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt
[    0.346389] pcieport 0000:09:00.0: Signaling PME through PCIe PME interrupt
[    0.346390] pcieport 0000:0a:02.0: Signaling PME through PCIe PME interrupt
[    0.346391] pcieport 0000:0a:04.0: Signaling PME through PCIe PME interrupt
[    0.346395] pcie_pme 0000:00:07.0:pcie01: service driver pcie_pme loaded
[    0.346404] pcieport 0000:00:09.0: Signaling PME through PCIe PME interrupt
[    0.346408] pcie_pme 0000:00:09.0:pcie01: service driver pcie_pme loaded
[    0.346417] pcieport 0000:00:0a.0: Signaling PME through PCIe PME interrupt
[    0.346421] pcie_pme 0000:00:0a.0:pcie01: service driver pcie_pme loaded
[    0.346447] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[    0.346449] pci 0000:0f:00.0: Signaling PME through PCIe PME interrupt
[    0.346454] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[    0.346480] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt
[    0.346482] pci 0000:10:00.0: Signaling PME through PCIe PME interrupt
[    0.346486] pcie_pme 0000:00:1c.4:pcie01: service driver pcie_pme loaded
[    0.346511] pcieport 0000:00:1c.5: Signaling PME through PCIe PME interrupt
[    0.346516] pcie_pme 0000:00:1c.5:pcie01: service driver pcie_pme loaded
[    0.346674] Non-volatile memory driver v1.3
[    0.346752] Xen virtual console successfully installed as xvc0
[    0.346781] Fixed MDIO Bus: probed
[    0.346815] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    0.347699] i8042: No controller found
[    0.347736] mousedev: PS/2 mouse device common for all mice
[    0.347886] EFI Variables Facility v0.08 2004-May-17
[    0.348466] TCP cubic registered
[    0.348477] Registering the dns_resolver key type
[    0.348546] registered taskstats version 1
[    0.349436]   Magic number: 1:466:678
[    0.350013] Freeing unused kernel memory: 428k freed
[    0.350133] Write protecting the kernel read-only data: 6868k
[    0.422206] SCSI subsystem initialized
[    0.428554] Fusion MPT base driver 4.28.00.00suse
[    0.428556] Copyright (c) 1999-2010 LSI Corporation
[    0.434123] Fusion MPT SAS Host driver 4.28.00.00suse
[    0.434163] mptsas 0000:0f:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.434168] mptbase: ioc0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total memory = 24654548 kB
[    0.434700] mptbase: ioc0: Initiating bringup
[    1.016109] ioc0: LSISAS1078 C2: Capabilities={Initiator}
[    1.016191] mptsas 0000:0f:00.0: setting latency timer to 64
[    1.016208] Adjusted maximum contiguous region order to 7
[   13.834395] scsi0 : ioc0: LSISAS1078 C2, FwRev=011b0000h, Ports=1, MaxQ=276, IRQ=16
[   14.844149] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221000000000000
[   14.844268] scsi target0:0:0: mptsas: ioc0: add device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221000000000000
[   14.846987] scsi 0:0:0:0: Direct-Access     ATA      ST9500530NS      SN04 PQ: 0 ANSI: 5
[   14.847688] scsi 0:0:0:0: mptscsih: ioc0: qdepth=64, tagged=1, simple=1, ordered=0, scsi_level=6, cmd_que=1
[   14.847692] sdev dma_alignment 511 
[   14.860458] libata version 3.00 loaded.
[   14.865330] ahci 0000:00:1f.2: version 3.0
[   14.865351] ahci 0000:00:1f.2: PCI INT B -> GSI 18 (level, low) -> IRQ 18
[   14.865862] ahci 0000:00:1f.2: irq 82 (290) for MSI/MSI-X
[   14.865873] ahci 0000:00:1f.2: forcing PORTS_IMPL to 0x3f
[   14.865927] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[   14.865930] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc 
[   14.865934] ahci 0000:00:1f.2: setting latency timer to 64
[   14.866823] scsi1 : ahci
[   14.866995] scsi2 : ahci
[   14.867159] scsi3 : ahci
[   14.867339] scsi4 : ahci
[   14.867481] scsi5 : ahci
[   14.867577] scsi6 : ahci
[   14.867698] ata1: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20100 irq 82
[   14.867700] ata2: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20180 irq 82
[   14.867702] ata3: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20200 irq 82
[   14.867704] ata4: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20280 irq 82
[   14.867706] ata5: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20300 irq 82
[   14.867708] ata6: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20380 irq 82
[   15.892163] ata5: failed to resume link (SControl 0)
[   15.892184] ata5: SATA link down (SStatus 0 SControl 0)
[   15.892199] ata1: failed to resume link (SControl 0)
[   15.892209] ata1: SATA link down (SStatus 0 SControl 0)
[   15.892219] ata6: failed to resume link (SControl 0)
[   15.892229] ata6: SATA link down (SStatus 0 SControl 0)
[   15.892240] ata3: failed to resume link (SControl 0)
[   15.892249] ata3: SATA link down (SStatus 0 SControl 0)
[   15.892255] ata4: failed to resume link (SControl 0)
[   15.892263] ata4: SATA link down (SStatus 0 SControl 0)
[   15.892270] ata2: failed to resume link (SControl 0)
[   15.892278] ata2: SATA link down (SStatus 0 SControl 0)
[   15.903622] netfront: Initialising virtual ethernet driver.
[   15.930557] rdac: device handler registered
[   15.940550] hp_sw: device handler registered
[   15.951150] emc: device handler registered
[   15.961035] alua: device handler registered
[   15.965823] udev: starting version 147
[   16.012568] usbcore: registered new interface driver usbfs
[   16.012588] usbcore: registered new interface driver hub
[   16.012675] usbcore: registered new device driver usb
[   16.014313] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[   16.015546] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   16.015584] ehci_hcd 0000:00:1a.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.015611] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[   16.015614] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[   16.015638] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[   16.015689] ehci_hcd 0000:00:1a.7: debug port 1
[   16.019587] ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
[   16.019656] ehci_hcd 0000:00:1a.7: irq 19, io mem 0xb1b22000
[   16.033645] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[   16.033662] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   16.033663] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.033665] usb usb1: Product: EHCI Host Controller
[   16.033666] usb usb1: Manufacturer: Linux 3.0.51-0.7.9-xen ehci_hcd
[   16.033667] usb usb1: SerialNumber: 0000:00:1a.7
[   16.033762] hub 1-0:1.0: USB hub found
[   16.033766] hub 1-0:1.0: 6 ports detected
[   16.033889] ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.033911] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[   16.033914] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   16.033922] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[   16.033974] ehci_hcd 0000:00:1d.7: debug port 1
[   16.037864] ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
[   16.037871] ehci_hcd 0000:00:1d.7: irq 16, io mem 0xb1b21000
[   16.053691] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[   16.053716] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[   16.053719] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.053722] usb usb2: Product: EHCI Host Controller
[   16.053724] usb usb2: Manufacturer: Linux 3.0.51-0.7.9-xen ehci_hcd
[   16.053726] usb usb2: SerialNumber: 0000:00:1d.7
[   16.053843] hub 2-0:1.0: USB hub found
[   16.053846] hub 2-0:1.0: 6 ports detected
[   16.067580] sd 0:0:0:0: [sda] Write Protect is off
[   16.067587] sd 0:0:0:0: [sda] Mode Sense: 73 00 00 08
[   16.069821] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   16.118840] uhci_hcd: USB Universal Host Controller Interface driver
[   16.119347] uhci_hcd 0000:00:1a.0: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.119359] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[   16.119363] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[   16.119374] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[   16.119411] uhci_hcd 0000:00:1a.0: irq 19, io base 0x000030e0
[   16.119812] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[   16.119815] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.119817] usb usb3: Product: UHCI Host Controller
[   16.119819] usb usb3: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.119822] usb usb3: SerialNumber: 0000:00:1a.0
[   16.119920] hub 3-0:1.0: USB hub found
[   16.119924] hub 3-0:1.0: 2 ports detected
[   16.120028] uhci_hcd 0000:00:1a.1: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.120037] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[   16.120040] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[   16.120046] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[   16.120076] uhci_hcd 0000:00:1a.1: irq 19, io base 0x000030c0
[   16.120131] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120133] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120134] usb usb4: Product: UHCI Host Controller
[   16.120136] usb usb4: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120137] usb usb4: SerialNumber: 0000:00:1a.1
[   16.120206] hub 4-0:1.0: USB hub found
[   16.120211] hub 4-0:1.0: 2 ports detected
[   16.120288] uhci_hcd 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.120296] uhci_hcd 0000:00:1a.2: setting latency timer to 64
[   16.120299] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[   16.120305] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[   16.120336] uhci_hcd 0000:00:1a.2: irq 19, io base 0x000030a0
[   16.120390] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120392] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120393] usb usb5: Product: UHCI Host Controller
[   16.120394] usb usb5: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120396] usb usb5: SerialNumber: 0000:00:1a.2
[   16.120465] hub 5-0:1.0: USB hub found
[   16.120468] hub 5-0:1.0: 2 ports detected
[   16.120547] uhci_hcd 0000:00:1d.0: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.120555] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[   16.120558] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   16.120563] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[   16.120594] uhci_hcd 0000:00:1d.0: irq 16, io base 0x00003080
[   16.120648] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120650] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120652] usb usb6: Product: UHCI Host Controller
[   16.120653] usb usb6: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120655] usb usb6: SerialNumber: 0000:00:1d.0
[   16.120726] hub 6-0:1.0: USB hub found
[   16.120731] hub 6-0:1.0: 2 ports detected
[   16.120805] uhci_hcd 0000:00:1d.1: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.120814] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[   16.120816] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   16.120823] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[   16.120851] uhci_hcd 0000:00:1d.1: irq 16, io base 0x00003060
[   16.120924] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120925] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120927] usb usb7: Product: UHCI Host Controller
[   16.120928] usb usb7: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120930] usb usb7: SerialNumber: 0000:00:1d.1
[   16.120997] hub 7-0:1.0: USB hub found
[   16.121002] hub 7-0:1.0: 2 ports detected
[   16.121075] uhci_hcd 0000:00:1d.2: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.121083] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[   16.121086] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   16.121091] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[   16.121118] uhci_hcd 0000:00:1d.2: irq 16, io base 0x00003040
[   16.121215] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[   16.121216] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.121218] usb usb8: Product: UHCI Host Controller
[   16.121219] usb usb8: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.121221] usb usb8: SerialNumber: 0000:00:1d.2
[   16.121283] hub 8-0:1.0: USB hub found
[   16.121285] hub 8-0:1.0: 2 ports detected
[   16.196826]  sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
[   16.269865] sd 0:0:0:0: [sda] Attached SCSI disk
[   16.468213] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[   16.602327] usb 2-1: New USB device found, idVendor=05e3, idProduct=0719
[   16.602331] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[   16.602334] usb 2-1: Product: USB Storage
[   16.602337] usb 2-1: SerialNumber: 000000000033
[   16.848147] usb 5-1: new full-speed USB device number 2 using uhci_hcd
[   17.016431] usb 5-1: New USB device found, idVendor=046b, idProduct=ff10
[   17.016435] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   17.016438] usb 5-1: Product: Virtual Keyboard and Mouse
[   17.016441] usb 5-1: Manufacturer: American Megatrends Inc.
[   17.016443] usb 5-1: SerialNumber: serial
[   17.038058] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/input/input0
[   17.038134] generic-usb 0003:046B:FF10.0001: input,hidraw0: USB HID v1.10 Keyboard [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input0
[   17.041631] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.1/input/input1
[   17.041725] generic-usb 0003:046B:FF10.0002: input,hidraw1: USB HID v1.10 Mouse [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input1
[   17.041739] usbcore: registered new interface driver usbhid
[   17.041741] usbhid: USB HID core driver
[   17.349457] kjournald starting.  Commit interval 15 seconds
[   17.350430] EXT3-fs (sda6): using internal journal
[   17.350435] EXT3-fs (sda6): mounted filesystem with ordered data mode
[   19.104265] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[   19.172491] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[   19.749833] udev: starting version 147
[   19.826436] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2
[   19.826499] ACPI: Sleep Button [SLPB]
[   19.826555] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[   19.826598] ACPI: Power Button [PWRF]
[   19.946211] Fusion MPT misc device (ioctl) driver 4.28.00.00suse
[   19.946270] mptctl: Registered with Fusion MPT base driver
[   19.946273] mptctl: /dev/mptctl @ (major,minor=10,220)
[   20.009439] rtc_cmos 00:03: RTC can wake from S4
[   20.009589] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[   20.009675] rtc0: alarms up to one month, y3k, 114 bytes nvram
[   20.021378] ioatdma: Intel(R) QuickData Technology Driver 4.00
[   20.021800] ioatdma 0000:00:16.0: PCI INT A -> GSI 43 (level, low) -> IRQ 43
[   20.022202] ioatdma 0000:00:16.0: setting latency timer to 64
[   20.022316] ioatdma 0000:00:16.0: irq 83 (289) for MSI/MSI-X
[   20.022591] ioatdma 0000:00:16.1: PCI INT B -> GSI 44 (level, low) -> IRQ 44
[   20.022616] ioatdma 0000:00:16.1: setting latency timer to 64
[   20.022717] ioatdma 0000:00:16.1: irq 84 (288) for MSI/MSI-X
[   20.022970] ioatdma 0000:00:16.2: PCI INT C -> GSI 45 (level, low) -> IRQ 45
[   20.022995] ioatdma 0000:00:16.2: setting latency timer to 64
[   20.023093] ioatdma 0000:00:16.2: irq 85 (287) for MSI/MSI-X
[   20.023340] ioatdma 0000:00:16.3: PCI INT D -> GSI 46 (level, low) -> IRQ 46
[   20.023365] ioatdma 0000:00:16.3: setting latency timer to 64
[   20.023465] ioatdma 0000:00:16.3: irq 86 (286) for MSI/MSI-X
[   20.023709] ioatdma 0000:00:16.4: PCI INT A -> GSI 43 (level, low) -> IRQ 43
[   20.023733] ioatdma 0000:00:16.4: setting latency timer to 64
[   20.023834] ioatdma 0000:00:16.4: irq 87 (285) for MSI/MSI-X
[   20.024107] ioatdma 0000:00:16.5: PCI INT B -> GSI 44 (level, low) -> IRQ 44
[   20.024136] ioatdma 0000:00:16.5: setting latency timer to 64
[   20.024241] ioatdma 0000:00:16.5: irq 88 (284) for MSI/MSI-X
[   20.024541] ioatdma 0000:00:16.6: PCI INT C -> GSI 45 (level, low) -> IRQ 45
[   20.024618] ioatdma 0000:00:16.6: setting latency timer to 64
[   20.024720] ioatdma 0000:00:16.6: irq 89 (283) for MSI/MSI-X
[   20.025000] ioatdma 0000:00:16.7: PCI INT D -> GSI 46 (level, low) -> IRQ 46
[   20.025048] ioatdma 0000:00:16.7: setting latency timer to 64
[   20.025173] ioatdma 0000:00:16.7: irq 90 (282) for MSI/MSI-X
[   20.040633] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[   20.057692] Intel(R) Gigabit Ethernet Network Driver - version 3.0.6-k2
[   20.057695] Copyright (c) 2007-2011 Intel Corporation.
[   20.057743] igb 0000:01:00.0: PCI INT B -> GSI 40 (level, low) -> IRQ 40
[   20.057761] igb 0000:01:00.0: setting latency timer to 64
[   20.058609] igb 0000:01:00.0: irq 91 (281) for MSI/MSI-X
[   20.058660] igb 0000:01:00.0: irq 92 (280) for MSI/MSI-X
[   20.058710] igb 0000:01:00.0: irq 93 (279) for MSI/MSI-X
[   20.058760] igb 0000:01:00.0: irq 94 (278) for MSI/MSI-X
[   20.058809] igb 0000:01:00.0: irq 95 (277) for MSI/MSI-X
[   20.058860] igb 0000:01:00.0: irq 96 (276) for MSI/MSI-X
[   20.058912] igb 0000:01:00.0: irq 97 (275) for MSI/MSI-X
[   20.058963] igb 0000:01:00.0: irq 98 (274) for MSI/MSI-X
[   20.059013] igb 0000:01:00.0: irq 99 (273) for MSI/MSI-X
[   20.059031] igb 0000:01:00.0: 0 vfs allocated
[   20.059063] igb 0000:01:00.0: PHY reset is blocked due to SOL/IDER session.
[   20.073101] iTCO_vendor_support: vendor-support=0
[   20.077593] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
[   20.077717] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[   20.128112] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
[   20.128116] igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e4
[   20.128237] igb 0000:01:00.0: eth0: PBA No: 0080FF-0FF
[   20.128239] igb 0000:01:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[   20.128263] igb 0000:01:00.1: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[   20.128277] igb 0000:01:00.1: setting latency timer to 64
[   20.128532] input: PC Speaker as /devices/platform/pcspkr/input/input4
[   20.128715] igb 0000:01:00.1: irq 100 (272) for MSI/MSI-X
[   20.128761] igb 0000:01:00.1: irq 101 (271) for MSI/MSI-X
[   20.128805] igb 0000:01:00.1: irq 102 (270) for MSI/MSI-X
[   20.128849] igb 0000:01:00.1: irq 103 (269) for MSI/MSI-X
[   20.128902] igb 0000:01:00.1: irq 104 (268) for MSI/MSI-X
[   20.128947] igb 0000:01:00.1: irq 105 (267) for MSI/MSI-X
[   20.128994] igb 0000:01:00.1: irq 106 (266) for MSI/MSI-X
[   20.129039] igb 0000:01:00.1: irq 107 (265) for MSI/MSI-X
[   20.129085] igb 0000:01:00.1: irq 108 (264) for MSI/MSI-X
[   20.129098] igb 0000:01:00.1: 0 vfs allocated
[   20.233347] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   20.290132] tpm_tis 00:09: 1.2 TPM (device-id 0x0, rev-id 78)
[   20.293251] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 18 (level, low) -> IRQ 18
[   20.320628] igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
[   20.320633] igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e5
[   20.320711] igb 0000:01:00.1: eth1: PBA No: 0080FF-0FF
[   20.320714] igb 0000:01:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[   20.407692] i7core_edac: Unknown symbol edac_mc_del_mc (err 0)
[   20.407714] i7core_edac: Unknown symbol edac_mc_add_mc (err 0)
[   20.407728] i7core_edac: Unknown symbol edac_pci_create_generic_ctl (err 0)
[   20.407741] i7core_edac: Unknown symbol edac_mc_alloc (err 0)
[   20.407753] i7core_edac: Unknown symbol edac_mc_handle_fbd_ce (err 0)
[   20.407765] i7core_edac: Unknown symbol edac_mc_free (err 0)
[   20.407792] i7core_edac: Unknown symbol edac_pci_release_generic_ctl (err 0)
[   20.407804] i7core_edac: Unknown symbol edac_mc_handle_fbd_ue (err 0)
[   20.454868] Initializing USB Mass Storage driver...
[   20.455645] scsi7 : usb-storage 2-1:1.0
[   20.455737] usbcore: registered new interface driver usb-storage
[   20.455740] USB Mass Storage support registered.
[   20.632488] NET: Registered protocol family 10
[   21.456311] scsi 7:0:0:0: CD-ROM            TEAC     DV-W28S-V        1.0A PQ: 0 ANSI: 0
[   21.456470] scsi 7:0:0:0: Attached scsi generic sg1 type 5
[   21.505640] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[   21.505644] cdrom: Uniform CD-ROM driver Revision: 3.20
[   21.505760] sr 7:0:0:0: Attached scsi CD-ROM sr0
[   21.747501] Adding 2096476k swap on /dev/sda2.  Priority:-1 extents:1 across:2096476k 
[   23.066092] device-mapper: uevent: version 1.0.3
[   23.066890] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
[   24.946268] loop: module loaded
[   25.059150] kjournald starting.  Commit interval 15 seconds
[   25.059658] EXT3-fs (sda5): mounted filesystem with ordered data mode
[   26.843989] fuse init (API version 7.16)
[   29.284013] type=1400 audit(1359974490.280:2): apparmor="STATUS" operation="profile_load" name="/bin/ping" pid=1444 comm="apparmor_parser"
[   29.313534] type=1400 audit(1359974490.312:3): apparmor="STATUS" operation="profile_load" name="/sbin/klogd" pid=1449 comm="apparmor_parser"
[   29.373425] type=1400 audit(1359974490.372:4): apparmor="STATUS" operation="profile_load" name="/sbin/syslog-ng" pid=1453 comm="apparmor_parser"
[   29.435199] type=1400 audit(1359974490.432:5): apparmor="STATUS" operation="profile_load" name="/sbin/syslogd" pid=1457 comm="apparmor_parser"
[   29.478778] type=1400 audit(1359974490.476:6): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-explicit-grant-helper" pid=1462 comm="apparmor_parser"
[   29.543126] type=1400 audit(1359974490.540:7): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-grant-helper" pid=1466 comm="apparmor_parser"
[   29.608731] type=1400 audit(1359974490.604:8): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-grant-helper-pam" pid=1470 comm="apparmor_parser"
[   29.667902] type=1400 audit(1359974490.664:9): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-read-auth-helper" pid=1474 comm="apparmor_parser"
[   29.699853] type=1400 audit(1359974490.696:10): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-resolve-exe-helper" pid=1478 comm="apparmor_parser"
[   29.732326] type=1400 audit(1359974490.732:11): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-revoke-helper" pid=1482 comm="apparmor_parser"
[   31.832062] microcode: Microcode Update Driver: v2.00-xen <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   35.372759] igb: eth0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
[   35.373923] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   35.374841] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   38.190222] Bridge firewalling registered
[   38.206036] device eth0 entered promiscuous mode
[   38.216718] br0: port 1(eth0) entering forwarding state
[   38.216723] br0: port 1(eth0) entering forwarding state
[   38.865943] NET: Registered protocol family 17
[   42.194050] auditd (3594): /proc/3594/oom_adj is deprecated, please use /proc/3594/oom_score_adj instead.
[   42.744861] RPC: Registered named UNIX socket transport module.
[   42.744865] RPC: Registered udp transport module.
[   42.744867] RPC: Registered tcp transport module.
[   42.744869] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   42.801661] FS-Cache: Loaded
[   42.834796] FS-Cache: Netfs 'nfs' registered for caching
[   44.273808] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[   45.549687] eth0: no IPv6 routers present
[   46.246164] Event-channel device installed.
[   46.392132] usbcore: registered new interface driver usbback
[   46.415498] blktap_device_init: 21 callbacks suppressed
[   46.415501] blktap_device_init: blktap device major 252
[   46.415506] blktap_ring_init: blktap ring major: 250
[   46.569965] Unable to read sysrq code in control/sysrq
[   49.028133] br0: no IPv6 routers present
[  586.633768] blktap_control_allocate_tap: allocated tap ffff8805ac1b9000
[  586.655151] blktap_ring_open: opening device blktap0
[  586.655155] blktap_ring_open: opened device 0
[  586.655171] blktap_ring_mmap: blktap: mapping pid is 4908
[  586.656089] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  586.656095] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  586.656100] blktap_device_create: minor 0 sectors 2097152 sector-size 512
[  586.656409] blktap_device_create: creation of 252:0: 0
[  587.201145] device vif1.0 entered promiscuous mode
[  587.205967] br0: port 2(vif1.0) entering forwarding state
[  587.205974] br0: port 2(vif1.0) entering forwarding state
[  587.328994] ip_tables: (C) 2000-2006 Netfilter Core Team
[  597.692122] vif1.0: no IPv6 routers present
[  609.373001] blkback: ring-ref 8, event-channel 22, protocol 1 (x86_64-abi)
[  621.284358] br0: port 2(vif1.0) entering forwarding state
[  621.285202] device vif1.0 left promiscuous mode
[  621.285206] br0: port 2(vif1.0) entering disabled state
[  621.328927] blktap_ring_vm_close: unmapping ring 0
[  621.328932] blktap_ring_release: freeing device 0
[  621.333129] blktap_device_destroy: destroy device 0 users 0
[  635.451911] blktap_control_allocate_tap: allocated tap ffff8805ac1b9000
[  635.458825] blktap_ring_open: opening device blktap0
[  635.458830] blktap_ring_open: opened device 0
[  635.458845] blktap_ring_mmap: blktap: mapping pid is 5112
[  635.459741] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  635.459747] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  635.459751] blktap_device_create: minor 0 sectors 2097152 sector-size 512
[  635.459943] blktap_device_create: creation of 252:0: 0
[  635.709203] device vif2.0 entered promiscuous mode
[  635.713903] br0: port 2(vif2.0) entering forwarding state
[  635.713908] br0: port 2(vif2.0) entering forwarding state
[  646.332056] vif2.0: no IPv6 routers present
[  663.955441] blkback: ring-ref 8, event-channel 7, protocol 1 (x86_64-abi)

--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="screenlog.0.txt"
Content-Transfer-Encoding: quoted-printable

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-3.0.51-0.7.9-default root=3Dbax.arch.suse.de:/olaf_xenimage=
s/bug6
94863/nfsroot console=3DttyS0,115200 quiet log_buf_len=3D64M memblock=3Ddeb=
ug ignore_
loglevel debug
   [Linux-bzImage, setup=3D0x3c00, size=3D0x3a31b0]
initrd /initrd-3.0.51-0.7.9-default
   [Linux-initrd @ 0x1f2d0000, 0x51f161 bytes]

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.0.51-0.7.9-default (geeko@buildhost) (gcc ve=
rsion 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov =
29 22:12:17 UTC 2012 (f3be9d0)
[    0.000000] Command line: root=3Dbax.arch.suse.de:/olaf_xenimages/bug694=
863/nfsroot console=3DttyS0,115200 quiet log_buf_len=3D64M memblock=3Ddebug=
 ignore_loglevel debug
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000001f800000 (usable)
[    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.3.26502-20130204 02/04/2013
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usab=
le) =3D=3D> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usab=
le)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn =3D 0x1f800 max_arch_pfn =3D 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 00F0000000 mask FFF8000000 uncachable
[    0.000000]   1 base 00F8000000 mask FFFC000000 uncachable
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x701060007=
0106
[    0.000000] found SMP MP-table at [ffff8800000fbba0] fbba0
[    0.000000]     memblock_x86_reserve_range: [0x000fbba0-0x000fbbaf]   * =
MP-table mpf
[    0.000000]     memblock_x86_reserve_range: [0x000fbbb0-0x000fbc93]   * =
MP-table mpc
[    0.000000]     memblock_x86_reserve_range: [0x01fd7000-0x01fd70d7]     =
         BRK
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size =3D 0x1f78e000
[    0.000000]  memory.cnt  =3D 0x2
[    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009dfff], 0x8e000 by=
tes
[    0.000000]  memory[0x1]	[0x00000000100000-0x0000001f7fffff], 0x1f700000=
 bytes
[    0.000000]  reserved.cnt  =3D 0x3
[    0.000000]  reserved[0x0]	[0x0000000009e000-0x000000000fffff], 0x62000 =
bytes
[    0.000000]  reserved[0x1]	[0x00000001000000-0x00000001fd70d7], 0xfd70d8=
 bytes
[    0.000000]  reserved[0x2]	[0x0000001f2d0000-0x0000001f7effff], 0x520000=
 bytes
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000]     memblock_x86_reserve_range: [0x00099000-0x0009dfff]     =
  TRAMPOLINE
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480
[    0.000000] init_memory_mapping: 0000000000000000-000000001f800000
[    0.000000]  0000000000 - 001f800000 page 2M
[    0.000000] kernel direct mapping tables up to 0x1f7fffff @ [mem 0x1f7fe=
000-0x1f7fffff]
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 258723(98%)
[    0.000000] RAMDISK: 1f2d0000 - 1f7f0000
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc00f5c0 00054 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00f280 000F4 (v04    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc003600 0BBF6 (v02    Xen      HVM 00000=
000 INTL 20081031)
[    0.000000] ACPI: FACS 00000000fc0035c0 00040
[    0.000000] ACPI: APIC 00000000fc00f380 000D8 (v02    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc00f4d0 00038 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc00f510 00028 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc00f540 00031 (v02    Xen      HVM 00000=
000 INTL 20081031)
[    0.000000] ACPI: SSDT 00000000fc00f580 00031 (v02    Xen      HVM 00000=
000 INTL 20081031)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000001f800000
[    0.000000] Initmem setup node 0 0000000000000000-000000001f800000
[    0.000000]     memblock_x86_reserve_range: [0x1b2a9000-0x1b2cffff]     =
   NODE_DATA
[    0.000000]   NODE_DATA [000000001b2a9000 - 000000001b2cffff]
[    0.000000]     memblock_x86_reserve_range: [0x1f7ff000-0x1f7fffff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1aea9000-0x1b2a8fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fef80-0x1f7fefdf]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1aaa9000-0x1aea8fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1a200000-0x1a9fffff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fd000-0x1f7fdfff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fc000-0x1f7fcfff]     =
     BOOTMEM
[    0.000000]  [ffffea0000000000-ffffea00007fffff] PMD -> [ffff88001a20000=
0-ffff88001a9fffff] on node 0
[    0.000000]        memblock_x86_free_range: [0x1aaa9000-0x1aea8fff]
[    0.000000]        memblock_x86_free_range: [0x1aea9000-0x1b2a8fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x0001f800
[    0.000000] On node 0 totalpages: 128910
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 5 pages reserved
[    0.000000]   DMA zone: 3921 pages, LIFO batch:0
[    0.000000]     memblock_x86_reserve_range: [0x1b291000-0x1b2a8fff]     =
     BOOTMEM
[    0.000000]   DMA32 zone: 1708 pages used for memmap
[    0.000000]   DMA32 zone: 123220 pages, LIFO batch:31
[    0.000000]     memblock_x86_reserve_range: [0x1b279000-0x1b290fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fb000-0x1f7fbfff]     =
     BOOTMEM
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-=
47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000]     memblock_x86_reserve_range: [0x1f7fef00-0x1f7fef40]     =
     BOOTMEM
[    0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs
[    0.000000]     memblock_x86_reserve_range: [0x1f7fee80-0x1f7feec2]     =
     BOOTMEM
[    0.000000] nr_irqs_gsi: 64
[    0.000000]     memblock_x86_reserve_range: [0x1f7fed00-0x1f7fee4f]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fec80-0x1f7fece7]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fec00-0x1f7fec67]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7feb80-0x1f7febe7]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7feb00-0x1f7feb67]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fea80-0x1f7feae7]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fea00-0x1f7fea1f]     =
     BOOTMEM
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000=
a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000=
e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 00000000001=
00000
[    0.000000] Allocating PCI resources starting at 1f800000 (gap: 1f800000=
:dc800000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe900-0x1f7fe987]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe800-0x1f7fe887]     =
     BOOTMEM
[    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:15 nr_cpu_ids:15 =
nr_node_ids:1
[    0.000000]     memblock_x86_reserve_range: [0x1f7fa000-0x1f7fafff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7f9000-0x1f7f9fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1b000000-0x1b1fffff]     =
     BOOTMEM
[    0.000000]        memblock_x86_free_range: [0x1b019000-0x1b01ffff]
[    0.000000]        memblock_x86_free_range: [0x1b039000-0x1b03ffff]
[    0.000000]        memblock_x86_free_range: [0x1b059000-0x1b05ffff]
[    0.000000]        memblock_x86_free_range: [0x1b079000-0x1b07ffff]
[    0.000000]        memblock_x86_free_range: [0x1b099000-0x1b09ffff]
[    0.000000]        memblock_x86_free_range: [0x1b0b9000-0x1b0bffff]
[    0.000000]        memblock_x86_free_range: [0x1b0d9000-0x1b0dffff]
[    0.000000]        memblock_x86_free_range: [0x1b0f9000-0x1b0fffff]
[    0.000000]        memblock_x86_free_range: [0x1b119000-0x1b11ffff]
[    0.000000]        memblock_x86_free_range: [0x1b139000-0x1b13ffff]
[    0.000000]        memblock_x86_free_range: [0x1b159000-0x1b15ffff]
[    0.000000]        memblock_x86_free_range: [0x1b179000-0x1b17ffff]
[    0.000000]        memblock_x86_free_range: [0x1b199000-0x1b19ffff]
[    0.000000]        memblock_x86_free_range: [0x1b1b9000-0x1b1bffff]
[    0.000000]        memblock_x86_free_range: [0x1b1d9000-0x1b1dffff]
[    0.000000]        memblock_x86_free_range: [0x1b1e0000-0x1b1fffff]
[    0.000000] PERCPU: Embedded 25 pages/cpu @ffff88001b000000 s73728 r8192=
 d20480 u131072
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe780-0x1f7fe787]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe700-0x1f7fe707]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe680-0x1f7fe6bb]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe600-0x1f7fe677]     =
     BOOTMEM
[    0.000000] pcpu-alloc: s73728 r8192 d20480 u131072 alloc=3D1*2097152
[    0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14=
 --=20
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe480-0x1f7fe58f]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe400-0x1f7fe447]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe380-0x1f7fe3c7]     =
     BOOTMEM
[    0.000000]        memblock_x86_free_range: [0x1f7fa000-0x1f7fafff]
[    0.000000]        memblock_x86_free_range: [0x1f7f9000-0x1f7f9fff]
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe180-0x1f7fe37f]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fae00-0x1f7fafff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fac00-0x1f7fadff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7faa00-0x1f7fabff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fa800-0x1f7fa9ff]     =
     BOOTMEM
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Tota=
l pages: 127141
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: root=3Dbax.arch.suse.de:/olaf_xenimages=
/bug694863/nfsroot console=3DttyS0,115200 quiet log_buf_len=3D64M memblock=
=3Ddebug ignore_loglevel debug
[    0.000000]     memblock_x86_reserve_range: [0x1f7f6800-0x1f7fa7ff]     =
     BOOTMEM
[    0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (40 early reservations)
[    0.000000]   [0000099000-00000fffff]
[    0.000000]   [0001000000-0001fd70d7]
[    0.000000]   [001a200000-001a9fffff]
[    0.000000]   [001b000000-001b018fff]
[    0.000000]   [001b020000-001b038fff]
[    0.000000]   [001b040000-001b058fff]
[    0.000000]   [001b060000-001b078fff]
[    0.000000]   [001b080000-001b098fff]
[    0.000000]   [001b0a0000-001b0b8fff]
[    0.000000]   [001b0c0000-001b0d8fff]
[    0.000000]   [001b0e0000-001b0f8fff]
[    0.000000]   [001b100000-001b118fff]
[    0.000000]   [001b120000-001b138fff]
[    0.000000]   [001b140000-001b158fff]
[    0.000000]   [001b160000-001b178fff]
[    0.000000]   [001b180000-001b198fff]
[    0.000000]   [001b1a0000-001b1b8fff]
[    0.000000]   [001b1c0000-001b1d8fff]
[    0.000000]   [001b279000-001f7effff]
[    0.000000]   [001f7f6800-001f7fdfff]
[    0.000000]   [001f7fe180-001f7fe3c7]
[    0.000000]   [001f7fe400-001f7fe447]
[    0.000000]   [001f7fe480-001f7fe58f]
[    0.000000]   [001f7fe600-001f7fe677]
[    0.000000]   [001f7fe680-001f7fe6bb]
[    0.000000]   [001f7fe700-001f7fe707]
[    0.000000]   [001f7fe780-001f7fe787]
[    0.000000]   [001f7fe800-001f7fe887]
[    0.000000]   [001f7fe900-001f7fe987]
[    0.000000]   [001f7fea00-001f7fea1f]
[    0.000000]   [001f7fea80-001f7feae7]
[    0.000000]   [001f7feb00-001f7feb67]
[    0.000000]   [001f7feb80-001f7febe7]
[    0.000000]   [001f7fec00-001f7fec67]
[    0.000000]   [001f7fec80-001f7fece7]
[    0.000000]   [001f7fed00-001f7fee4f]
[    0.000000]   [001f7fee80-001f7feec2]
[    0.000000]   [001f7fef00-001f7fef40]
[    0.000000]   [001f7fef80-001f7fefdf]
[    0.000000]   [001f7ff000-001f7fffff]
[    0.000000] Memory: 418532k/516096k available (4417k kernel code, 456k a=
bsent, 97108k reserved, 7677k data, 1344k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS:262400 nr_irqs:1208 16
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] allocated 4194304 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=3Dmemory' option if you don't wan=
t memory cgroups
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2926.355 MHz processor.
[    0.028005] Calibrating delay loop (skipped), value calculated using tim=
er frequency.. 5852.71 BogoMIPS (lpj=3D11705420)
[    0.033089] pid_max: default: 32768 minimum: 301
[    0.036182] kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI=
, All Rights Reserved
kdb_cmd[0]: defcmd archkdb "" "First line arch debugging"
kdb_cmd[8]: defcmd archkdbcpu "" "archkdb with only tasks on cpus"
kdb_cmd[15]: defcmd archkdbshort "" "archkdb with less detailed backtrace"
kdb_cmd[22]: defcmd archkdbcommon "" "Common arch debugging"
[    0.048129] Security Framework initialized
[    0.049749] AppArmor: AppArmor initialized
[    0.051423] Dentry cache hash table entries: 65536 (order: 7, 524288 byt=
es)
[    0.052102] Inode-cache hash table entries: 32768 (order: 6, 262144 byte=
s)
[    0.056067] Mount-cache hash table entries: 256
[    0.057957] Initializing cgroup subsys cpuacct
[    0.060008] Initializing cgroup subsys memory
[    0.061784] Initializing cgroup subsys devices
[    0.064006] Initializing cgroup subsys freezer
[    0.065753] Initializing cgroup subsys net_cls
[    0.068006] Initializing cgroup subsys blkio
[    0.070741] Initializing cgroup subsys perf_event
[    0.072077] CPU: Physical Processor ID: 0
[    0.076007] CPU: Processor Core ID: 0
[    0.078267] mce: CPU supports 2 MCE banks
[    0.081797] ACPI: Core revision 20110413
[    0.091343] Enabling x2apic
[    0.092004] Enabled x2apic
[    0.092008] Switched APIC routing to physical x2apic.
[    0.100348] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D2 apic2=3D0 pin2=3D0
[    0.145426] CPU0: Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz steppi=
ng 02
[    0.152008] Performance Events: Westmere events, Intel PMU driver.
[    0.152008] ... version:                3
[    0.152008] ... bit width:              48
[    0.152010] ... generic registers:      4
[    0.153570] ... value mask:             0000ffffffffffff
[    0.156010] ... max period:             000000007fffffff
[    0.158051] ... fixed-purpose events:   3
[    0.159643] ... event mask:             000000070000000f
[    0.160132] NMI watchdog enabled, takes one hw-pmu counter.
[    0.164127] Booting Node   0, Processors  #1
[    0.165779] smpboot cpu 1: start_ip =3D 99000
[    0.196032] NMI watchdog enabled, takes one hw-pmu counter.
[    0.200056] Brought up 2 CPUs
[    0.201251] Total of 2 processors activated (11705.42 BogoMIPS).
[    0.204397] devtmpfs: initialized
[    0.211598] print_constraints: dummy:=20
[    0.212039] Time: 10:52:04  Date: 02/04/13
[    0.213745] NET: Registered protocol family 16
[    0.216120] ACPI: bus type pci registered
[    0.217923] PCI: Using configuration type 1 for base access
[    0.220315] bio: create slab <bio-0> at 0
[    0.224902] ACPI: EC: Look up EC in DSDT
[    0.230797] ACPI: Interpreter enabled
[    0.232018] ACPI: (supports S0 S3 S4 S5)
[    0.233770] ACPI: Using IOAPIC for interrupt routing
[    0.313797] ACPI: No dock devices found.
[    0.316027] PCI: Using host bridge windows from ACPI; if necessary, use =
"pci=3Dnocrs" and report a bug
[    0.320130] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.324232] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.328028] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.332026] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x00=
0bffff]
[    0.336023] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfb=
ffffff]
[    0.340113] pci 0000:00:00.0: [8086:1237] type 0 class 0x000600
[    0.344800] pci 0000:00:01.0: [8086:7000] type 0 class 0x000601
[    0.349185] pci 0000:00:01.1: [8086:7010] type 0 class 0x000101
[    0.352478] pci 0000:00:01.1: reg 20: [io  0xc100-0xc10f]
[    0.355093] pci 0000:00:01.3: [8086:7113] type 0 class 0x000680
[    0.356049] * Found PM-Timer Bug on the chipset. Due to workarounds for =
a bug,
[    0.356050] * this clock source is slow. Consider trying other clock sou=
rces
[    0.361012] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX=
4 ACPI
[    0.364417] pci 0000:00:02.0: [1013:00b8] type 0 class 0x000300
[    0.368201] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.372112] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff]
[    0.375255] pci 0000:00:03.0: [5853:0001] type 0 class 0x00ff80
[    0.376244] pci 0000:00:03.0: reg 10: [io  0xc000-0xc0ff]
[    0.378436] pci 0000:00:03.0: reg 14: [mem 0xf2000000-0xf2ffffff pref]
[    0.381439] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.384392]  pci0000:00: Unable to request _OSC control (_OSC support ma=
sk: 0x1e)
[    0.493508] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    0.497291] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.501286] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.508512] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    0.513339] vgaarb: device added: PCI:0000:00:02.0,decodes=3Dio+mem,owns=
=3Dio+mem,locks=3Dnone
[    0.520035] vgaarb: loaded
[    0.522143] PCI: Using ACPI for IRQ routing
[    0.524036] PCI: pci_cache_line_size set to 64 bytes
[    0.528336] reserve RAM buffer: 000000000009e000 - 000000000009ffff=20
[    0.532036] reserve RAM buffer: 000000001f800000 - 000000001fffffff=20
[    0.536101] NetLabel: Initializing
[    0.540036] NetLabel:  domain hash size =3D 128
[    0.544036] NetLabel:  protocols =3D UNLABELED CIPSOv4
[    0.547635] NetLabel:  unlabeled traffic allowed by default
[    0.548049] HPET: 3 timers in total, 0 timers will be used for per-cpu t=
imer
[    0.556049] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.560151] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.572058] Switching to clocksource hpet
[    0.575022] Switched to NOHz mode on CPU #0
[    0.575003] Switched to NOHz mode on CPU #1
[    0.579544] AppArmor: AppArmor Filesystem Enabled
[    0.583390] pnp: PnP ACPI init
[    0.585982] ACPI: bus type pnp registered
[    0.589261] pnp 00:00: [mem 0x00000000-0x0009ffff]
[    0.593273] system 00:00: [mem 0x00000000-0x0009ffff] could not be reser=
ved
[    0.598588] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.603299] pnp 00:01: [bus 00-ff]
[    0.605767] pnp 00:01: [io  0x0cf8-0x0cff]
[    0.608802] pnp 00:01: [io  0x0000-0x0cf7 window]
[    0.612193] pnp 00:01: [io  0x0d00-0xffff window]
[    0.615471] pnp 00:01: [mem 0x000a0000-0x000bffff window]
[    0.619318] pnp 00:01: [mem 0xf0000000-0xfbffffff window]
[    0.623415] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.628200] pnp 00:02: [mem 0xfed00000-0xfed003ff]
[    0.631598] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.636397] pnp 00:03: [io  0x0010-0x001f]
[    0.639399] pnp 00:03: [io  0x0022-0x002d]
[    0.642425] pnp 00:03: [io  0x0030-0x003f]
[    0.645360] pnp 00:03: [io  0x0044-0x005f]
[    0.648445] pnp 00:03: [io  0x0062-0x0063]
[    0.651382] pnp 00:03: [io  0x0065-0x006f]
[    0.654279] pnp 00:03: [io  0x0072-0x007f]
[    0.657262] pnp 00:03: [io  0x0080]
[    0.659817] pnp 00:03: [io  0x0084-0x0086]
[    0.662839] pnp 00:03: [io  0x0088]
[    0.665326] pnp 00:03: [io  0x008c-0x008e]
[    0.668324] pnp 00:03: [io  0x0090-0x009f]
[    0.671440] pnp 00:03: [io  0x00a2-0x00bd]
[    0.674437] pnp 00:03: [io  0x00e0-0x00ef]
[    0.677481] pnp 00:03: [io  0x08a0-0x08a3]
[    0.680360] pnp 00:03: [io  0x0cc0-0x0ccf]
[    0.683428] pnp 00:03: [io  0x04d0-0x04d1]
[    0.686415] system 00:03: [io  0x08a0-0x08a3] has been reserved
[    0.690682] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
[    0.695000] system 00:03: [io  0x04d0-0x04d1] has been reserved
[    0.699255] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.704056] pnp 00:04: [dma 4]
[    0.706190] pnp 00:04: [io  0x0000-0x000f]
[    0.709135] pnp 00:04: [io  0x0081-0x0083]
[    0.712181] pnp 00:04: [io  0x0087]
[    0.714566] pnp 00:04: [io  0x0089-0x008b]
[    0.717543] pnp 00:04: [io  0x008f]
[    0.719963] pnp 00:04: [io  0x00c0-0x00df]
[    0.722868] pnp 00:04: [io  0x0480-0x048f]
[    0.725885] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.730652] pnp 00:05: [io  0x0070-0x0071]
[    0.733749] pnp 00:05: [irq 8]
[    0.735989] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.740760] pnp 00:06: [io  0x0061]
[    0.743302] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.747811] pnp 00:07: [irq 12]
[    0.750141] pnp 00:07: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.754947] pnp 00:08: [io  0x0060]
[    0.757546] pnp 00:08: [io  0x0064]
[    0.760097] pnp 00:08: [irq 1]
[    0.762356] pnp 00:08: Plug and Play ACPI device, IDs PNP0303 PNP030b (a=
ctive)
[    0.767695] pnp 00:09: [io  0x03f0-0x03f5]
[    0.770636] pnp 00:09: [io  0x03f7]
[    0.773235] pnp 00:09: [irq 6]
[    0.775362] pnp 00:09: [dma 2]
[    0.777604] pnp 00:09: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.782481] pnp 00:0a: [io  0x03f8-0x03ff]
[    0.785253] pnp 00:0a: [irq 4]
[    0.787390] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.792005] pnp 00:0b: [io  0x0378-0x037f]
[    0.795054] pnp 00:0b: [irq 7]
[    0.797294] pnp 00:0b: Plug and Play ACPI device, IDs PNP0400 (active)
[    0.802236] pnp 00:0c: [io  0x10c0-0x1141]
[    0.805220] pnp 00:0c: [io  0xb044-0xb047]
[    0.808173] system 00:0c: [io  0x10c0-0x1141] has been reserved
[    0.812455] system 00:0c: [io  0xb044-0xb047] has been reserved
[    0.816704] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.836518] pnp: PnP ACPI: found 13 devices
[    0.838142] ACPI: ACPI bus type pnp unregistered
[    0.845336] PCI: max bus depth: 0 pci_try_num: 1
[    0.847076] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.849146] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.851128] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.853620] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff]
[    0.856190] NET: Registered protocol family 2
[    0.857949] IP route cache hash table entries: 4096 (order: 3, 32768 byt=
es)
[    0.860920] TCP established hash table entries: 16384 (order: 6, 262144 =
bytes)
[    0.863704] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.866176] TCP: Hash tables configured (established 16384 bind 16384)
[    0.868589] TCP reno registered
[    0.869758] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.871901] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.874372] NET: Registered protocol family 1
[    0.876069] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.878260] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.880496] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.882834] pci 0000:00:02.0: Boot video device
[    0.884683] PCI: CLS 0 bytes, default 64
[    0.886148] Unpacking initramfs...
[    0.976604] Freeing initrd memory: 5248k freed
[    0.980429] audit: initializing netlink socket (disabled)
[    0.983042] type=3D2000 audit(1359975123.980:1): initialized
[    1.004701] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.008589] VFS: Disk quotas dquot_6.5.2
[    1.010529] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.013798] msgmni has been set to 206
[    1.015783] alg: No test for stdrng (krng)
[    1.017861] Block layer SCSI generic (bsg) driver version 0.4 loaded (ma=
jor 253)
[    1.021554] io scheduler noop registered
[    1.023499] io scheduler deadline registered
[    1.025676] io scheduler cfq registered (default)
[    1.028165] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    1.031894] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    1.081698] 00:0a: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    1.086755] Non-volatile memory driver v1.3
[    1.090225] Linux agpgart interface v0.103
[    1.093645] Fixed MDIO Bus: probed
[    1.096245] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0=
x60,0x64 irq 1,12
[    1.101847] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.103763] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.105793] mousedev: PS/2 mouse device common for all mice
[    1.108472] input: AT Translated Set 2 keyboard as /devices/platform/i80=
42/serio0/input/input0
[    1.112125] cpuidle: using governor ladder
[    1.115129] cpuidle: using governor menu
[    1.118082] EFI Variables Facility v0.08 2004-May-17
[    1.121893] TCP cubic registered
[    1.124323] Registering the dns_resolver key type
[    1.127000] PM: Hibernation image not present or could not be loaded.
[    1.130046] registered taskstats version 1
[    1.132335]   Magic number: 1:672:880
[    1.136317] Freeing unused kernel memory: 1344k freed
[    1.138955] Write protecting the kernel read-only data: 10240k
[    1.145263] Freeing unused kernel memory: 1708k freed
[    1.150105] Freeing unused kernel memory: 1008k freed
doing fast boot
[    1.188853] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level, l=
ow) -> IRQ 28
[    1.193124] Xen version 4.3.
[    1.195541] Hypercall area is 1 pages.
[    1.198665] xen-platform-pci 0000:00:03.0: I/O protocol version 1
[    1.207973] suspend: event channel 6
[    1.208560] Unable to read sysrq code in control/sysrq
[    1.221813] xen-vbd: registered block device major 3
[    1.223998] blkfront: hda: barrier or flush: disabled
[    1.228565] SCSI subsystem initialized
[    1.230818]  hda: hda1 hda2
[    1.234705] libata version 3.00 loaded.
[    1.239483] ata_piix 0000:00:01.1: version 2.13
[    1.241440] ata_piix 0000:00:01.1: setting latency timer to 64
[    1.244067] scsi0 : ata_piix
[    1.245700] scsi1 : ata_piix
[    1.247085] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc100 irq 14
[    1.250205] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc108 irq 15
[    1.410471] ata1.01: NODEV after polling detection
[    1.416170] ata1.00: ATA-7: QEMU HARDDISK, 0.10.2, max UDMA/100
[    1.418989] ata1.00: 2097152 sectors, multi 16: LBA48=20
[    1.422384] ata1.00: configured for MWDMA2
[    1.424433] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    0.=
10 PQ: 0 ANSI: 5
[    1.435008] xen_mem: Initialising balloon driver.
[    1.450694] netfront: Initialising virtual ethernet driver.
preping 03-scsi_dh.sh
running 03-scsi_dh.sh
[    1.461201] alua: device handler registered
[    1.467600] rdac: device handler registered
[    1.474392] emc: device handler registered
[    1.482510] hp_sw: device handler registered
preping 03-storage.sh
running 03-storage.sh
preping 04-udev.sh
running 04-udev.sh
Creating device nodes with udev
[    1.495392] udev: starting version 147
[    1.518783] ACPI: acpi_idle registered with cpuidle
ata_id[269]: HDIO_GET_IDENTITY failed for '/dev/.tmp-block-3:0'

[    1.544774] sd 0:0:0:0: [sda] 2097152 512-byte logical blocks: (1.07 GB/=
1.00 GiB)
[    1.547753] sd 0:0:0:0: [sda] Write Protect is off
[    1.549620] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.551543] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled=
, doesn't support DPO or FUA
[    1.560158]  sda: sda1 sda2
[    1.561440] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.763078] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/=
i8042/serio1/input/input1
[    2.004223] Refined TSC clocksource calibration: 2926.331 MHz.
[    2.009973] Switching to clocksource tsc
preping 05-blogd.sh
running 05-blogd.sh
mount: devpts already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts
Boot logging started on /dev/ttyS0(/dev/console) at Mon Feb  4 11:52:05 2013
preping 05-clock.sh
running 05-clock.sh
preping 12-network.sh
running 12-network.sh
[    2.270768] NET: Registered protocol family 17
running dhcpcd on interface eth0
err, eth0: Failed to lookup hostname via DNS: Temporary failure in name res=
olution
preping 21-devinit_done.sh
running 21-devinit_done.sh
preping 21-nfs.sh
running 21-nfs.sh
[   14.340515] RPC: Registered named UNIX socket transport module.
[   14.344694] RPC: Registered udp transport module.
[   14.347892] RPC: Registered tcp transport module.
[   14.351057] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   14.357560] FS-Cache: Loaded
[   14.364398] FS-Cache: Netfs 'nfs' registered for caching
preping 81-mount.sh
running 81-mount.sh
device node not found
Mounting root bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot
mount -o rw,nolock -t nfs bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroo=
t /root
preping 82-remount.sh
running 82-remount.sh
preping 91-createfb.sh
running 91-createfb.sh
preping 91-killblogd.sh
running 91-killblogd.sh
preping 91-killudev.sh
running 91-killudev.sh
preping 91-shell.sh
running 91-shell.sh
preping 92-killblogd2.sh
running 92-killblogd2.sh
preping 93-boot.sh
running 93-boot.sh
INIT: version 2.86 booting
System Boot Control: Running /etc/init.d/boot
Mounting sysfs at /sys=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=
=1B[?25h
Copying static /dev content=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=
=1B8=1B[?25h
Mounting devpts at /dev/pts=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=
=1B8=1B[?25h
Boot logging started on /dev/ttyS0(/dev/console) at Mon Feb  4 11:52:18 2013
Mounting debugfs at /sys/kernel/debug=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdon=
e=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting udevd: [   15.759402] udev: starting version 147
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
Loading drivers, configuring devices: [   16.043511] piix4_smbus 0000:00:01=
=2E3: SMBus base address uninitialized - upgrade BIOS or use force_addr=3D0=
xaddr
[   16.054379] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/inpu=
t/input2
[   16.058842] ACPI: Power Button [PWRF]
[   16.061519] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/inpu=
t/input3
[   16.065478] ACPI: Sleep Button [SLPF]
[   16.068700] input: PC Speaker as /devices/platform/pcspkr/input/input4
[   16.103431] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   16.114015] FDC 0 is a S82078B
ata_id[492]: HDIO_GET_IDENTITY failed for '/dev/hda'

[   16.138550] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[   16.143169] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs
[   16.156472] parport_pc 00:0b: reported by Plug and Play ACPI
[   16.161408] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[   16.392954] ppdev: user-space parallel port driver
[   16.513197] NET: Registered protocol family 10
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hActivating swap-devices in /etc/fstab...
[   17.013265] Adding 331772k swap on /dev/hda2.  Priority:-1 extents:1 acr=
oss:331772k SS
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hSet System Time to the current Hardware Clock=1B7=1B[?25l=1B[80C=1B=
[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hActivating device mapper...
[   18.168178] device-mapper: uevent: version 1.0.3
[   18.170617] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised:=
 dm-devel@redhat.com
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hLoading required kernel modules
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hStarting MD RAID =1B[80C=1B[10D=1B[1munused=1B[m=0F
=1B[m=0F=1B[?25hChecking file systems...
fsck from util-linux 2.19.1
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/hda1=20
BOOT: clean, 64/44736 files, 22702/178944 blocks
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hMounting l=
ocal file systems...
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
[   19.404458] loop: module loaded
udev on /dev type tmpfs (rw,mode=3D0755)
tmpfs on /dev/shm type tmpfs (rw,mode=3D1777)
devpts on /dev/pts type devpts (rw,mode=3D0620,gid=3D5)
[   20.109015] kjournald starting.  Commit interval 15 seconds
[   20.111889] EXT3-fs (hda1): mounted filesystem with ordered data mode
/dev/hda1 on /boot type ext3 (ro,noatime,acl,user_xattr)
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hCheck if the profiles matches the system=1B7=1B[?25l=1B[80C=1B[10D=
=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hCreating /var/log/boot.msg
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hEnabling monitoring on LVM volume groups...
  No volume groups found
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hActivating remaining swap-devices in /etc/f=
stab...
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hSetting up hostname 'hammer185'=1B7=
=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
Setting up NIS domainname 'suse.de'=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
Setting up loopback interface     lo       =20
    lo        IP address: 127.0.0.1/8  =20
              IP address: 127.0.0.2/8  =20
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hSetting current sysctl status from /etc/sysctl.conf=1B7=1B[=
?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hEnabling syn flood protection=1B[80C=1B[10D=1B[1;32mdone=1B=
[m=0F
Disabling IP forwarding=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=
=1B[?25h
Disabling IPv6 forwarding=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B=
8=1B[?25h
Disabling IPv6 privacy=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=
=1B[?25h
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hSystem Boot Control: The system has been =1B[80C=1B[10D=1B[=
1mset up=1B[m=0F
Skipped features: =1B[80C=1B[14D=1B[1;33mboot.md=1B[m=0F
System Boot Control: Running /etc/init.d/boot.local
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hINIT: Ente=
ring runlevel: 3
Master Resource Control: previous runlevel: N, switching to runlevel: =1B[8=
0C=1B[10D=1B[1m3=1B[m=0F
Starting D-Bus daemon=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B=
[?25h
=1B[m=0F=1B[?25hStarting syslog services=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32m=
done=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h[   27.424084] eth0: no IPv=
6 routers present
Initializing random number generator=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hLoading CPUFreq modules (CPUFreq not supported)
Starting HAL daemon=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?=
25h
=1B[m=0F=1B[?25hSetting up (localfs) network interfaces:
    lo       =20
    lo        IP address: 127.0.0.1/8  =20
              IP address: 127.0.0.2/8  =20
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h    eth0  =
    name: Virtual Ethernet Card 0
    eth0      Starting DHCP4 client. =20
    eth0      IP address: 10.11.3.133/17
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hSetting up=
 service (localfs) network  .  .  .  .  .  .  .  .  .  .=1B7=1B[?25l=1B[80C=
=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hStarting auditd [   41.455249] auditd (2107=
): /proc/2107/oom_adj is deprecated, please use /proc/2107/oom_score_adj in=
stead.
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting haveged daemon =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32m=
done=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting rpcbind =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B=
[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hStarting NFS client services: sm-notify idm=
apd=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hLoading console font lat9w-16.psfu  -m trivial G0:loadable
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hLoading ke=
ymap assuming iso-8859-15 euro
Loading /usr/share/kbd/keymaps/i386/qwerty/us.map.gz
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h[   45.803=
412] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Loading compose table latin1.add=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[=
m=0F=1B8=1B[?25h
Start Unicode mode
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hStarting irqbalance =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=
=1B8=1B[?25h
=1B[m=0F=1B[?25hSetting up (remotefs) network interfaces:
Setting up service (remotefs) network  .  .  .  .  .  .  .  .  .  .=1B7=1B[=
?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hStarting SSH daemon=1B7=1B[?25l=1B[80C=1B[1=
0D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting ypbind=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=
=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting network time protocol daemon (NTPD)=1B7=1B[?25l=1B=
[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting automount =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting mail service (Postfix)=1B7=1B[?25l=1B[80C=1B[10D=
=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting CRON daemon=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hMaster Resource Control: runlevel 3 has been =1B[80C=1B[10D=
=1B[1mreached=1B[m=0F
Skipped services in runlevel 3: =1B[80C=1B[13D=1B[1;33msplash=1B[m=0F


Welcome to SUSE Linux Enterprise Server 11 SP2  (x86_64) - Kernel 3.0.51-0.=
7.9-default (console).


hammer133 login: root
Password: [   60.101248] hpet1: lost 2200 rtc interrupts

Last login: Mon Feb  4 11:35:54 CET 2013 on console
[   62.390313] hpet1: lost 2201 rtc interrupts
root@hammer133:~ # [   64.679349] hpet1: lost 2200 rtc interrupts
=1B[3@(reverse-i-search)`':=1B[C=08=08=08e': init 0 ; exit=08=08=08=08=08=
=08=08=08=08=08=08=08=08=08=08=08v': eval `initviocons -e`=08=08=08=08=08=
=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=1B[1@a=1B[C=1B[C=
=1B[C=1B[6Proot@hammer133:~ #=1B[C
=1B[?25lProbing connected terminal...
=1B[c=1B7=1B[r=1B[999;999H=1B[6n=1B8=1B[>c
Initializing virtual console...
=1B[3g        =1BH        =1BH        =1BH        =1BH        =1BH        =
=1BH        =1BH        =1BH        =1BH[   66.968419] hpet1: lost 2201 rtc=
 interrupts
=1B[?25h
Found a screen terminal on /dev/console (263 columns x 62 lines).
Use the 'initviocons' command whenever the terminal has been resized.
root@hammer133:~ # [   69.257490] hpet1: lost 2200 rtc interrupts
[   71.546573] hpet1: lost 2201 rtc interrupts
[   73.835597] hpet1: lost 2201 rtc interrupts
[   76.123698] hpet1: lost 2201 rtc interrupts
[   78.412737] hpet1: lost 2200 rtc interrupts
[   80.701810] hpet1: lost 2201 rtc interrupts
[   82.990880] hpet1: lost 2201 rtc interrupts
[   85.278972] hpet1: lost 2201 rtc interrupts
[   87.568047] hpet1: lost 2201 rtc interrupts
[   89.857068] hpet1: lost 2200 rtc interrupts
[   92.146157] hpet1: lost 2201 rtc interrupts
[   94.435227] hpet1: lost 2201 rtc interrupts
[   96.723293] hpet1: lost 2201 rtc interrupts
[   99.012363] hpet1: lost 2201 rtc interrupts
[  101.300457] hpet1: lost 2201 rtc interrupts
[  103.589519] hpet1: lost 2201 rtc interrupts
[  105.877589] hpet1: lost 2201 rtc interrupts
[  108.166658] hpet1: lost 2201 rtc interrupts
[  110.454751] hpet1: lost 2201 rtc interrupts
[  112.743795] hpet1: lost 2200 rtc interrupts
[  115.032870] hpet1: lost 2201 rtc interrupts
[  117.321940] hpet1: lost 2201 rtc interrupts
[  119.610033] hpet1: lost 2201 rtc interrupts
[  121.899078] hpet1: lost 2201 rtc interrupts
[  124.187170] hpet1: lost 2201 rtc interrupts
[  126.476240] hpet1: lost 2201 rtc interrupts
[  128.764306] hpet1: lost 2202 rtc interrupts
[  131.052403] hpet1: lost 2201 rtc interrupts
[  133.340490] hpet1: lost 2201 rtc interrupts
[  135.629556] hpet1: lost 2201 rtc interrupts
[  137.917630] hpet1: lost 2201 rtc interrupts
[  140.206695] hpet1: lost 2201 rtc interrupts
[  142.495770] hpet1: lost 2200 rtc interrupts
INIT: Switching to runlevel: 0
=07
Broadcast message from root (Mon Feb  4 11:54:28 2013):

The system is going down for system halt NOW!
INIT: Sending processes the TERM signal
[  144.784813] hpet1: lost 2201 rtc interrupts
[  147.073885] hpet1: lost 2201 rtc interrupts
INIT: Sending processes the KILL signal
[  149.361977] hpet1: lost 2201 rtc interrupts
Boot logging started on /dev/ttyS0((no tty)) at Mon Feb  4 11:54:34 2013
Master Resource Control: previous runlevel: 3, switching to runlevel: =1B[2=
63C=1B[10D=1B[1m0=1B[m=0F
Shutting down automount (force) [  151.651047] hpet1: lost 2201 rtc interru=
pts

=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down CRON daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;3=
2mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down irqbalance =1B7=1B[?25l=1B[263C=1B[10D=1B[1;3=
2mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hShutting do=
wn SSH daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down auditd =1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdo=
ne=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hShutting down haveged daemon =1B7=1B[?25l=
=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h/etc/init.d/rc3.d/K02kbd stop=1B7=1B[?25l=1B[263C=1B[10D=1B=
[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down network time protocol daemon (NTPD)[  153.939=
120] hpet1: lost 2201 rtc interrupts
=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down mail service (Postfix)=1B7=1B[?25l=1B[263C=1B=
[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h[  156.228184] hpet1: lost 2201 rtc interrupts
Shutting down (remotefs) network interfaces:
Shutting down service (remotefs) network  .  .  .  .  .  .  .  .  .=1B7=1B[=
?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hSaving random seed=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down ypbind=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdon=
e=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down HAL daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32=
mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down NFS client services: root filesystem is on NF=
S=1B[263C=1B[10D=1B[1;33mskipped=1B[m=0F
=1B[m=0F=1B[?25hShutting down rpcbind =1B7=1B[?25l=1B[263C=1B[10D=1B[1;32md=
one=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down syslog services[  158.516277] hpet1: lost 220=
1 rtc interrupts
=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hShutting down (localfs) network interfaces:
    eth0      name: Virtual Ethernet Card 0
    eth0      serves root filesystem. Leave it up.
=1B7=1B[?25l=1B[1A=1B[263C=1B[10D=1B[1;33mskipped=1B[m=0F=1B8=1B[?25h[  160=
=2E804384] hpet1: lost 2200 rtc interrupts
Shutting down service (localfs) network  .  .  .  .  .  .  .  .  .=1B7=1B[?=
25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down D-Bus daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;=
32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hRunning /etc/init.d/halt.local
=1B7=1B[?25l=1B[1A=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B7=1B[?=
25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
The System Time is in sync with Hardware Clock =1B[263C=1B[10D=1B[1;32mgood=
=1B[m=0F
Turning off swap files
Unmounting file systems
/dev/hda1 has been unmounted
=1B7=1B[?25l=1B[1A=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hNot shutt=
ing down MD RAID - reboot/halt scripts do this.=1B7=1B[?25l=1B[263C=1B[10D=
=1B[1;31mmissing=1B[m=0F=1B8=1B[?25h
Stopping udevd: =1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
Sending all processes the TERM signal...
=1B[1A=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F
[  163.094391] hpet1: lost 2201 rtc interrupts
[  165.383463] hpet1: lost 2201 rtc interrupts
Sending all processes the KILL signal...
The system will be halted immediately.
[  167.668005] hpet1: lost 2200 rtc interrupts
[  168.552334] sd 0:0:0:0: [sda] Stopping disk
[  168.619245] xen vkbd-0: xenbus_dev_shutdown: device/vkbd/0: Initialising=
 !=3D Connected, skipping
[  168.630166] ACPI: Preparing to enter system sleep state S5
[  168.634186] Disabling non-boot CPUs ...
[  168.638602] Broke affinity for irq 12
[  168.643277] Power down.
[  168.649135] acpi_power_off called

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

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

--cWoXeonUoKmBZSoM--


From xen-devel-bounces@lists.xen.org Mon Feb 04 14:03:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2Mdy-00026K-Q0; Mon, 04 Feb 2013 14:03:34 +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 1U2Mdv-000266-KL
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:03:34 +0000
Received: from [85.158.137.99:3973] by server-6.bemta-3.messagelabs.com id
	3D/7F-29959-2BFBF015; Mon, 04 Feb 2013 14:03:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-217.messagelabs.com!1359986604!15188102!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11625 invoked from network); 4 Feb 2013 14:03:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 14:03:24 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo30) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n041c2p14DlPKg ;
	Mon, 4 Feb 2013 15:03:17 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id EE4191884C; Mon,  4 Feb 2013 15:03:12 +0100 (CET)
Date: Mon, 4 Feb 2013 15:03:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204140312.GA14684@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de>
	<20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
	<510F83AA02000078000BB64A@nat28.tlf.novell.com>
	<20130204094909.GA2564@aepfle.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <20130204094909.GA2564@aepfle.de>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

[ sorry, had this reply open in another window and forgot to send it ]

On Mon, Feb 04, Olaf Hering wrote:

> I'm attaching the xen, dom0 and domU logs from a pvops kernel. sles
> kernel will follow.
> 
> I will also try to revert the two changeset above.

These are the logs from sles11sp2 kernel in dom0+domU.
The guest prints "hpet1: lost 2201 rtc interrupts".

Xen has changeset 26461 reverted, but this does at least not solve the
"hpet1: lost 2201 rtc interrupts" interrupt messages.

Olaf

PS:
xl migrate with sles11 kernel does not seem to work for other unrelated reasons:

root@satriani:~/hpet # xl -v -v migrate -M 3 -m 2 -N sles11sp2_full_minimal_nfsroot_bug694863 localhost
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x0/0x0/657)
Loading new save file <incoming migration stream> (new xl fmt info 0x0/0x0/657)
 Savefile contains xl domain config
xc: error: Can't create lock file for suspend event channel /var/lib/xen/suspend_evtchn_2_lock.d: Internal error
libxl: warning: libxl_dom.c:1268:libxl__domain_suspend: Suspend event channel initialization failed
xc: Reloading memory pages: 105472/1048575   10%^Axc: detail: type fail: page 0 mfn 000f2000
xc: detail: type fail: page 1 mfn 000f2001
xc: detail: type fail: page 2 mfn 000f2002
xc: detail: delta 5993ms, dom0 20%, target 6%, sent 722Mb/s, dirtied 94Mb/s 17369 pages
xc: detail: type fail: page 861 mfn 000f2001
xc: detail: delta 545ms, dom0 37%, target 4%, sent 1036Mb/s, dirtied 8Mb/s 147 pages
xc: detail: type fail: page 133 mfn 000f2000
xc: detail: type fail: page 134 mfn 000f2002
xc: error: Live migration aborted, as requested. (guest too busy?) total_sent 149477 iter 3, max_iters 3 max_factor 2: Internal error
xc: detail: Save exit rc=1
libxl: error: libxl_dom.c:1306:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: No such device
migration sender: libxl_domain_suspend failed (rc=-8)
xc: error: 0-length read: Internal error
xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error
xc: error: Error when reading batch size (0 = Success): Internal error
xc: error: Error when reading batch (0 = Success): Internal error
libxl: error: libxl_create.c:787:libxl__xc_domain_restore_done: restoring domain: Resource temporarily unavailable
libxl: error: libxl_create.c:869:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl.c:1395:libxl__destroy_domid: non-existant domain 3
libxl: error: libxl.c:1359:domain_destroy_callback: unable to destroy guest with domid 3
libxl: error: libxl_create.c:1177:domcreate_destruction_cb: unable to destroy domain 3 following failed creation
migration target: Domain creation failed (code -3).
libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration target process [5218] exited with error status 3
Migration failed, failed to suspend at sender.



--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="dmesg-3.0.51-0.7.9-xen.txt"

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.0.51-0.7.9-xen (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)
[    0.000000] Command line: quiet sysrq=yes panic=9 console=ttyS0,57600 resume=/dev/disk/by-id/ata-ST9500530NS_9SP1KKAS-part2 splash=silent showopts log_buf_len=64M
[    0.000000] Xen-provided machine memory map:
[    0.000000]  BIOS: 0000000000000000 - 000000000009b000 (usable)
[    0.000000]  BIOS: 000000000009b000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS: 0000000000100000 - 000000008c21c000 (usable)
[    0.000000]  BIOS: 000000008c21c000 - 000000008c2ef000 (ACPI NVS)
[    0.000000]  BIOS: 000000008c2ef000 - 000000008c3df000 (ACPI data)
[    0.000000]  BIOS: 000000008c3df000 - 000000008d7df000 (ACPI NVS)
[    0.000000]  BIOS: 000000008d7df000 - 000000008f302000 (ACPI data)
[    0.000000]  BIOS: 000000008f302000 - 000000008f34f000 (reserved)
[    0.000000]  BIOS: 000000008f34f000 - 000000008f3d4000 (ACPI data)
[    0.000000]  BIOS: 000000008f3d4000 - 000000008f3de000 (ACPI NVS)
[    0.000000]  BIOS: 000000008f3de000 - 000000008f3e2000 (ACPI data)
[    0.000000]  BIOS: 000000008f3e2000 - 000000008f4cf000 (ACPI NVS)
[    0.000000]  BIOS: 000000008f4cf000 - 000000008f500000 (ACPI data)
[    0.000000]  BIOS: 000000008f500000 - 0000000090000000 (reserved)
[    0.000000]  BIOS: 00000000a0000000 - 00000000b0000000 (reserved)
[    0.000000]  BIOS: 00000000fc000000 - 00000000fd000000 (reserved)
[    0.000000]  BIOS: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS: 00000000fec90000 - 00000000fec91000 (reserved)
[    0.000000]  BIOS: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  BIOS: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS: 00000000ff800000 - 0000000100000000 (reserved)
[    0.000000]  BIOS: 0000000100000000 - 0000000670000000 (usable)
[    0.000000] Xen-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000005e0337000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] DMI: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
[    0.000000] last_pfn = 0x5e0337 max_arch_pfn = 0x80000000
[    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x80000000
[    0.000000] found SMP MP-table at [ffffffffff5f8b60] 000fdb60
[    0.000000] initial memory mapped : 0 - 00000000
[    0.000000] init_memory_mapping: 0000000000000000-0000000002113000
[    0.000000]  0000000000 - 0002113000 page 4k
[    0.000000] kernel direct mapping tables up to 0x2112fff @ [mem 0x00886000-0x00898fff]
[    0.000000] init_memory_mapping: 0000000005014000-0000000100000000
[    0.000000]  0005014000 - 0100000000 page 4k
[    0.000000] kernel direct mapping tables up to 0xffffffff @ [mem 0x00899000-0x01075fff]
[    0.000000] init_memory_mapping: 0000000100000000-00000005e0337000
[    0.000000]  0100000000 - 05e0337000 page 4k
[    0.000000] kernel direct mapping tables up to 0x5e0336fff @ [mem 0x05088000-0x0779efff]
[    0.000000] init_memory_mapping: 0000000002113000-0000000005014000
[    0.000000]  0002113000 - 0005014000 page 4k
[    0.000000] kernel direct mapping tables up to 0x5013fff @ [mem 0x0779e000-0x077b7fff]
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 258547(98%)
[    0.000000] RAMDISK: 01000000 - 02113000
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02 INTEL )
[    0.000000] ACPI: XSDT 000000008f4fd120 000A4 (v01 INTEL  S5520UT  00000000      01000013)
[    0.000000] ACPI: FACP 000000008f4fb000 000F4 (v04 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: DSDT 000000008f4f4000 065E9 (v02 INTEL  S5520UT  00000003 MSFT 0100000D)
[    0.000000] ACPI: FACS 000000008f3e2000 00040
[    0.000000] ACPI: APIC 000000008f4f3000 001A8 (v02 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: MCFG 000000008f4f2000 0003C (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: HPET 000000008f4f1000 00038 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SLIT 000000008f4f0000 00030 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SRAT 000000008f4ef000 00430 (v02 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] ACPI: SPCR 000000008f4ee000 00050 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: WDDT 000000008f4ed000 00040 (v01 INTEL  S5520UT  00000000 MSFT 0100000D)
[    0.000000] ACPI: SSDT 000000008f4d2000 1AFC4 (v02  INTEL SSDT  PM 00004000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000008f4d1000 001D8 (v02  INTEL IPMI     00004000 INTL 20061109)
[    0.000000] ACPI: TCPA 000000008f4d0000 00032 (v00                 00000000      00000000)
[    0.000000] ACPI: HEST 000000008f4cf000 000A8 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: BERT 000000008f3e1000 00030 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: ERST 000000008f3e0000 00230 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: EINJ 000000008f3df000 00130 (v01 INTEL  S5520UT  00000001 INTL 00000001)
[    0.000000] ACPI: XMAR 000000008f3de000 001A8 (v01 INTEL  S5520UT  00000001 MSFT 0100000D)
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x005e0337
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x005dfb37
[    0.000000]     0: 0x005e0337 -> 0x005e0337
[    0.000000] On node 0 totalpages: 6159159
[    0.000000] free_area_init_node: node 0, pgdat ffffffff8070c300, node_mem_map ffff8805c7a29000
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4040 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 1030200 pages, LIFO batch:31
[    0.000000]   Normal zone: 69900 pages used for memmap
[    0.000000]   Normal zone: 5040683 pages, LIFO batch:31
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
[    0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at b0000000 (gap: b0000000:4c000000)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:24 nr_node_ids:1
[    0.000000] PERCPU: Embedded 17 pages/cpu @ffff8805c4600000 s40960 r8192 d20480 u131072
[    0.000000] pcpu-alloc: s40960 r8192 d20480 u131072 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 
[    0.000000] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 -- -- -- -- -- -- -- -- 
[    0.000000] Swapping MFNs for PFN 723 and 5c4605 (MFN 65e723 and 26869)
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 6074923
[    0.000000] Kernel command line: quiet sysrq=yes panic=9 console=ttyS0,57600 resume=/dev/disk/by-id/ata-ST9500530NS_9SP1KKAS-part2 splash=silent showopts log_buf_len=64M
[    0.000000] bootsplash: silent mode.
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    0.000000] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    0.000000] allocated 197158624 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Software IO TLB enabled: 
[    0.000000]  Aperture:     64 megabytes
[    0.000000]  Address size: 27 bits
[    0.000000]  Kernel range: ffff8805b19f9000 - ffff8805b59f9000
[    0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.000000] Memory: 23810364k/24644828k available (4111k kernel code, 8192k absent, 826272k reserved, 3164k data, 428k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] nr_pirqs: 64
[    0.000000] NR_IRQS:38912 nr_irqs:3200 16
[    0.000000] Extended CMOS year: 2000
[    0.000000] Xen reported: 2926.408 MHz processor.
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [xvc-1] enabled
[    0.080005] Calibrating delay using timer specific routine.. 5926.02 BogoMIPS (lpj=11852059)
[    0.080008] pid_max: default: 32768 minimum: 301
[    0.080051] Security Framework initialized
[    0.080072] AppArmor: AppArmor initialized
[    0.080091] Mount-cache hash table entries: 256
[    0.080187] Initializing cgroup subsys cpuacct
[    0.080192] Initializing cgroup subsys memory
[    0.080201] Initializing cgroup subsys devices
[    0.080202] Initializing cgroup subsys freezer
[    0.080203] Initializing cgroup subsys net_cls
[    0.080205] Initializing cgroup subsys blkio
[    0.080209] Initializing cgroup subsys perf_event
[    0.080255] mce: CPU supports 2 MCE banks
[    0.080291] SMP alternatives: switching to UP code
[    0.102891] ACPI: Core revision 20110413
[    0.125653] SMP alternatives: switching to SMP code
[    0.165979] Brought up 24 CPUs
[    0.166176] devtmpfs: initialized
[    0.166176] print_constraints: dummy: 
[    0.166176] Time: 10:41:01  Date: 02/04/13
[    0.168578] NET: Registered protocol family 16
[    0.168667] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.168667] ACPI: bus type pci registered
[    0.168667] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xa0000000-0xafffffff] (base 0xa0000000)
[    0.168667] PCI: MMCONFIG at [mem 0xa0000000-0xafffffff] reserved in E820
[    0.181711] PCI: Using configuration type 1 for base access
[    0.186358] bio: create slab <bio-0> at 0
[    0.190304] ACPI: EC: Look up EC in DSDT
[    0.216409] ACPI Error: Field [CPB3] at 96 exceeds Buffer [NULL] size 64 (bits) (20110413/dsopcode-236)
[    0.216414] ACPI Error: Method parse/execution failed [\_SB_._OSC] (Node ffff8805b14fac90), AE_AML_BUFFER_LIMIT (20110413/psparse-536)
[    0.220745] ACPI: Interpreter enabled
[    0.220748] ACPI: (supports S0 S1 S5)
[    0.220758] ACPI: Using IOAPIC for interrupt routing
[    0.225732] ACPI: No dock devices found.
[    0.225736] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.226377] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fd])
[    0.226908] pci_root PNP0A08:00: host bridge window [io  0x0000-0x0cf7]
[    0.226910] pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]
[    0.226912] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.226913] pci_root PNP0A08:00: host bridge window [mem 0x000c4000-0x000cbfff]
[    0.226915] pci_root PNP0A08:00: host bridge window [mem 0xfed40000-0xfedfffff]
[    0.226916] pci_root PNP0A08:00: host bridge window [mem 0xb0000000-0xfdffffff]
[    0.226920] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000c4000-0x000cbfff] conflicts with Video ROM [mem 0x000c0000-0x000c7fff]
[    0.226950] pci 0000:00:00.0: [8086:3406] type 0 class 0x000600
[    0.227044] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    0.227048] pci 0000:00:00.0: PME# disabled
[    0.227083] pci 0000:00:01.0: [8086:3408] type 1 class 0x000604
[    0.227180] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    0.227184] pci 0000:00:01.0: PME# disabled
[    0.227220] pci 0000:00:03.0: [8086:340a] type 1 class 0x000604
[    0.227348] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    0.227352] pci 0000:00:03.0: PME# disabled
[    0.227388] pci 0000:00:05.0: [8086:340c] type 1 class 0x000604
[    0.227484] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    0.227488] pci 0000:00:05.0: PME# disabled
[    0.227524] pci 0000:00:07.0: [8086:340e] type 1 class 0x000604
[    0.227620] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    0.227624] pci 0000:00:07.0: PME# disabled
[    0.227663] pci 0000:00:09.0: [8086:3410] type 1 class 0x000604
[    0.227760] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    0.227763] pci 0000:00:09.0: PME# disabled
[    0.227799] pci 0000:00:0a.0: [8086:3411] type 1 class 0x000604
[    0.227899] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
[    0.227904] pci 0000:00:0a.0: PME# disabled
[    0.227939] pci 0000:00:10.0: [8086:3425] type 0 class 0x000800
[    0.228017] pci 0000:00:10.1: [8086:3426] type 0 class 0x000800
[    0.228115] pci 0000:00:11.0: [8086:3427] type 0 class 0x000800
[    0.228227] pci 0000:00:11.1: [8086:3428] type 0 class 0x000800
[    0.228326] pci 0000:00:13.0: [8086:342d] type 0 class 0x000800
[    0.228343] pci 0000:00:13.0: reg 10: [mem 0xb1b24000-0xb1b24fff]
[    0.228427] pci 0000:00:13.0: PME# supported from D0 D3hot D3cold
[    0.228431] pci 0000:00:13.0: PME# disabled
[    0.228458] pci 0000:00:14.0: [8086:342e] type 0 class 0x000800
[    0.228570] pci 0000:00:14.1: [8086:3422] type 0 class 0x000800
[    0.228682] pci 0000:00:14.2: [8086:3423] type 0 class 0x000800
[    0.228788] pci 0000:00:14.3: [8086:3438] type 0 class 0x000800
[    0.228879] pci 0000:00:15.0: [8086:342f] type 0 class 0x000800
[    0.228980] pci 0000:00:16.0: [8086:3430] type 0 class 0x000880
[    0.228999] pci 0000:00:16.0: reg 10: [mem 0xb1b00000-0xb1b03fff 64bit]
[    0.229118] pci 0000:00:16.1: [8086:3431] type 0 class 0x000880
[    0.229136] pci 0000:00:16.1: reg 10: [mem 0xb1b04000-0xb1b07fff 64bit]
[    0.229256] pci 0000:00:16.2: [8086:3432] type 0 class 0x000880
[    0.229274] pci 0000:00:16.2: reg 10: [mem 0xb1b08000-0xb1b0bfff 64bit]
[    0.229393] pci 0000:00:16.3: [8086:3433] type 0 class 0x000880
[    0.229412] pci 0000:00:16.3: reg 10: [mem 0xb1b0c000-0xb1b0ffff 64bit]
[    0.229531] pci 0000:00:16.4: [8086:3429] type 0 class 0x000880
[    0.229550] pci 0000:00:16.4: reg 10: [mem 0xb1b10000-0xb1b13fff 64bit]
[    0.229669] pci 0000:00:16.5: [8086:342a] type 0 class 0x000880
[    0.229688] pci 0000:00:16.5: reg 10: [mem 0xb1b14000-0xb1b17fff 64bit]
[    0.229807] pci 0000:00:16.6: [8086:342b] type 0 class 0x000880
[    0.229826] pci 0000:00:16.6: reg 10: [mem 0xb1b18000-0xb1b1bfff 64bit]
[    0.229945] pci 0000:00:16.7: [8086:342c] type 0 class 0x000880
[    0.229963] pci 0000:00:16.7: reg 10: [mem 0xb1b1c000-0xb1b1ffff 64bit]
[    0.230085] pci 0000:00:1a.0: [8086:3a37] type 0 class 0x000c03
[    0.230150] pci 0000:00:1a.0: reg 20: [io  0x30e0-0x30ff]
[    0.230227] pci 0000:00:1a.1: [8086:3a38] type 0 class 0x000c03
[    0.230293] pci 0000:00:1a.1: reg 20: [io  0x30c0-0x30df]
[    0.230401] pci 0000:00:1a.2: [8086:3a39] type 0 class 0x000c03
[    0.230466] pci 0000:00:1a.2: reg 20: [io  0x30a0-0x30bf]
[    0.230558] pci 0000:00:1a.7: [8086:3a3c] type 0 class 0x000c03
[    0.230588] pci 0000:00:1a.7: reg 10: [mem 0xb1b22000-0xb1b223ff]
[    0.230722] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    0.230727] pci 0000:00:1a.7: PME# disabled
[    0.230757] pci 0000:00:1c.0: [8086:3a40] type 1 class 0x000604
[    0.230868] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.230872] pci 0000:00:1c.0: PME# disabled
[    0.230909] pci 0000:00:1c.4: [8086:3a48] type 1 class 0x000604
[    0.231021] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    0.231025] pci 0000:00:1c.4: PME# disabled
[    0.231058] pci 0000:00:1c.5: [8086:3a4a] type 1 class 0x000604
[    0.231168] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    0.231173] pci 0000:00:1c.5: PME# disabled
[    0.231208] pci 0000:00:1d.0: [8086:3a34] type 0 class 0x000c03
[    0.231273] pci 0000:00:1d.0: reg 20: [io  0x3080-0x309f]
[    0.231350] pci 0000:00:1d.1: [8086:3a35] type 0 class 0x000c03
[    0.231415] pci 0000:00:1d.1: reg 20: [io  0x3060-0x307f]
[    0.231492] pci 0000:00:1d.2: [8086:3a36] type 0 class 0x000c03
[    0.231557] pci 0000:00:1d.2: reg 20: [io  0x3040-0x305f]
[    0.231648] pci 0000:00:1d.7: [8086:3a3a] type 0 class 0x000c03
[    0.231678] pci 0000:00:1d.7: reg 10: [mem 0xb1b21000-0xb1b213ff]
[    0.231813] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    0.231818] pci 0000:00:1d.7: PME# disabled
[    0.231846] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604
[    0.231948] pci 0000:00:1f.0: [8086:3a16] type 0 class 0x000601
[    0.232027] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 000f)
[    0.232031] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)
[    0.232034] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0600 (mask 001f)
[    0.232105] pci 0000:00:1f.2: [8086:3a22] type 0 class 0x000106
[    0.232134] pci 0000:00:1f.2: reg 10: [io  0x3108-0x310f]
[    0.232146] pci 0000:00:1f.2: reg 14: [io  0x3114-0x3117]
[    0.232157] pci 0000:00:1f.2: reg 18: [io  0x3100-0x3107]
[    0.232168] pci 0000:00:1f.2: reg 1c: [io  0x3110-0x3113]
[    0.232180] pci 0000:00:1f.2: reg 20: [io  0x3020-0x303f]
[    0.232191] pci 0000:00:1f.2: reg 24: [mem 0xb1b20000-0xb1b207ff]
[    0.232265] pci 0000:00:1f.2: PME# supported from D3hot
[    0.232269] pci 0000:00:1f.2: PME# disabled
[    0.232293] pci 0000:00:1f.3: [8086:3a30] type 0 class 0x000c05
[    0.232315] pci 0000:00:1f.3: reg 10: [mem 0xb1b23000-0xb1b230ff 64bit]
[    0.232348] pci 0000:00:1f.3: reg 20: [io  0x3000-0x301f]
[    0.232469] pci 0000:01:00.0: [8086:10c9] type 0 class 0x000200
[    0.232487] pci 0000:01:00.0: reg 10: [mem 0xb1a20000-0xb1a3ffff]
[    0.232511] pci 0000:01:00.0: reg 18: [io  0x2020-0x203f]
[    0.232523] pci 0000:01:00.0: reg 1c: [mem 0xb1ac4000-0xb1ac7fff]
[    0.232625] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    0.232630] pci 0000:01:00.0: PME# disabled
[    0.232675] pci 0000:01:00.0: reg 184: [mem 0xb1a40000-0xb1a43fff 64bit]
[    0.232695] pci 0000:01:00.0: reg 190: [mem 0xb1a60000-0xb1a63fff 64bit]
[    0.232737] pci 0000:01:00.1: [8086:10c9] type 0 class 0x000200
[    0.232753] pci 0000:01:00.1: reg 10: [mem 0xb1a00000-0xb1a1ffff]
[    0.232777] pci 0000:01:00.1: reg 18: [io  0x2000-0x201f]
[    0.232790] pci 0000:01:00.1: reg 1c: [mem 0xb1ac0000-0xb1ac3fff]
[    0.232892] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
[    0.232896] pci 0000:01:00.1: PME# disabled
[    0.232934] pci 0000:01:00.1: reg 184: [mem 0xb1a80000-0xb1a83fff 64bit]
[    0.232954] pci 0000:01:00.1: reg 190: [mem 0xb1aa0000-0xb1aa3fff 64bit]
[    0.232984] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    0.232988] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    0.232992] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    0.232999] pci 0000:00:01.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233058] pci 0000:00:03.0: PCI bridge to [bus 04-04]
[    0.233062] pci 0000:00:03.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.233066] pci 0000:00:03.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233073] pci 0000:00:03.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233147] pci 0000:05:00.0: [111d:806a] type 1 class 0x000604
[    0.233255] pci 0000:05:00.0: PME# supported from D0 D3hot D3cold
[    0.233260] pci 0000:05:00.0: PME# disabled
[    0.233286] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    0.233290] pci 0000:00:05.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.233295] pci 0000:00:05.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233301] pci 0000:00:05.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233371] pci 0000:06:02.0: [111d:806a] type 1 class 0x000604
[    0.233523] pci 0000:06:02.0: PME# supported from D0 D3hot D3cold
[    0.233528] pci 0000:06:02.0: PME# disabled
[    0.233566] pci 0000:06:04.0: [111d:806a] type 1 class 0x000604
[    0.233687] pci 0000:06:04.0: PME# supported from D0 D3hot D3cold
[    0.233692] pci 0000:06:04.0: PME# disabled
[    0.233751] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    0.233760] pci 0000:05:00.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.233765] pci 0000:05:00.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233774] pci 0000:05:00.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233837] pci 0000:06:02.0: PCI bridge to [bus 07-07]
[    0.233846] pci 0000:06:02.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.233851] pci 0000:06:02.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233860] pci 0000:06:02.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.233924] pci 0000:06:04.0: PCI bridge to [bus 08-08]
[    0.233932] pci 0000:06:04.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.233938] pci 0000:06:04.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.233946] pci 0000:06:04.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234047] pci 0000:09:00.0: [111d:806a] type 1 class 0x000604
[    0.234154] pci 0000:09:00.0: PME# supported from D0 D3hot D3cold
[    0.234159] pci 0000:09:00.0: PME# disabled
[    0.234186] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    0.234190] pci 0000:00:07.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.234194] pci 0000:00:07.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234201] pci 0000:00:07.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234271] pci 0000:0a:02.0: [111d:806a] type 1 class 0x000604
[    0.234392] pci 0000:0a:02.0: PME# supported from D0 D3hot D3cold
[    0.234397] pci 0000:0a:02.0: PME# disabled
[    0.234435] pci 0000:0a:04.0: [111d:806a] type 1 class 0x000604
[    0.234556] pci 0000:0a:04.0: PME# supported from D0 D3hot D3cold
[    0.234561] pci 0000:0a:04.0: PME# disabled
[    0.234619] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    0.234628] pci 0000:09:00.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.234633] pci 0000:09:00.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234642] pci 0000:09:00.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234705] pci 0000:0a:02.0: PCI bridge to [bus 0b-0b]
[    0.234713] pci 0000:0a:02.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.234719] pci 0000:0a:02.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234727] pci 0000:0a:02.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234791] pci 0000:0a:04.0: PCI bridge to [bus 0c-0c]
[    0.234800] pci 0000:0a:04.0:   bridge window [io  0xfffffffffffff000-0x0000] (disabled)
[    0.234805] pci 0000:0a:04.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234814] pci 0000:0a:04.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234899] pci 0000:00:09.0: PCI bridge to [bus 0d-0d]
[    0.234903] pci 0000:00:09.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.234908] pci 0000:00:09.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234914] pci 0000:00:09.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.234973] pci 0000:00:0a.0: PCI bridge to [bus 0e-0e]
[    0.234977] pci 0000:00:0a.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.234981] pci 0000:00:0a.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.234988] pci 0000:00:0a.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235066] pci 0000:0f:00.0: [1000:0062] type 0 class 0x000100
[    0.235093] pci 0000:0f:00.0: reg 10: [mem 0xb1940000-0xb1943fff 64bit]
[    0.235108] pci 0000:0f:00.0: reg 18: [io  0x1000-0x10ff]
[    0.235130] pci 0000:0f:00.0: reg 1c: [mem 0xb1900000-0xb193ffff 64bit]
[    0.235159] pci 0000:0f:00.0: reg 30: [mem 0xfff80000-0xffffffff pref]
[    0.235244] pci 0000:0f:00.0: supports D1
[    0.235279] pci 0000:00:1c.0: PCI bridge to [bus 0f-0f]
[    0.235283] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    0.235287] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    0.235295] pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235381] pci 0000:10:00.0: [102b:0522] type 0 class 0x000300
[    0.235406] pci 0000:10:00.0: reg 10: [mem 0xb0000000-0xb0ffffff pref]
[    0.235424] pci 0000:10:00.0: reg 14: [mem 0xb1800000-0xb1803fff]
[    0.235442] pci 0000:10:00.0: reg 18: [mem 0xb1000000-0xb17fffff]
[    0.235511] pci 0000:10:00.0: reg 30: [mem 0xffff0000-0xffffffff pref]
[    0.235633] pci 0000:00:1c.4: PCI bridge to [bus 10-10]
[    0.235638] pci 0000:00:1c.4:   bridge window [io  0xf000-0x0000] (disabled)
[    0.235642] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    0.235650] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    0.235711] pci 0000:00:1c.5: PCI bridge to [bus 11-11]
[    0.235716] pci 0000:00:1c.5:   bridge window [io  0xf000-0x0000] (disabled)
[    0.235720] pci 0000:00:1c.5:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.235727] pci 0000:00:1c.5:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235816] pci 0000:00:1e.0: PCI bridge to [bus 12-12] (subtractive decode)
[    0.235820] pci 0000:00:1e.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.235824] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.235832] pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.235834] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    0.235835] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    0.235837] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    0.235839] pci 0000:00:1e.0:   bridge window [mem 0xfed40000-0xfedfffff] (subtractive decode)
[    0.235841] pci 0000:00:1e.0:   bridge window [mem 0xb0000000-0xfdffffff] (subtractive decode)
[    0.235903] pci_bus 0000:00: on NUMA node 0
[    0.235906] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.244723] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP1._PRT]
[    0.244763] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP3._PRT]
[    0.244794] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP5._PRT]
[    0.244826] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP7._PRT]
[    0.244857] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRP9._PRT]
[    0.244902] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MRPA._PRT]
[    0.244954] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[    0.244986] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[    0.245110]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.245237]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.256319] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    0.256380] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    0.256441] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[    0.256499] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
[    0.256559] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256618] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256677] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256736] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[    0.256790] pci 0000:00:00.0: GSI47: level-low
[    0.256817] pci 0000:00:01.0: GSI28: level-low
[    0.256843] pci 0000:00:03.0: GSI24: level-low
[    0.256869] pci 0000:00:05.0: GSI26: level-low
[    0.256895] pci 0000:00:07.0: GSI30: level-low
[    0.256920] pci 0000:00:09.0: GSI32: level-low
[    0.256946] pci 0000:00:0a.0: GSI33: level-low
[    0.256975] pci 0000:00:16.0: GSI43: level-low
[    0.257001] pci 0000:00:16.1: GSI44: level-low
[    0.257027] pci 0000:00:16.2: GSI45: level-low
[    0.257053] pci 0000:00:16.3: GSI46: level-low
[    0.257083] pci 0000:00:1a.0: GSI19: level-low
[    0.257110] pci 0000:00:1c.0: GSI16: level-low
[    0.257136] pci 0000:00:1c.5: GSI17: level-low
[    0.257164] pci 0000:00:1f.2: GSI18: level-low
[    0.257191] pci 0000:01:00.0: GSI40: level-low
[    0.257250] vgaarb: device added: PCI:0000:10:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.257252] vgaarb: loaded
[    0.257363] xen_mem: Initialising balloon driver.
[    0.257522] PCI: Using ACPI for IRQ routing
[    0.268063] PCI: Discovered peer bus fe
[    0.268090] pci 0000:fe:00.0: [8086:2c70] type 0 class 0x000600
[    0.268138] pci 0000:fe:00.1: [8086:2d81] type 0 class 0x000600
[    0.268190] pci 0000:fe:02.0: [8086:2d90] type 0 class 0x000600
[    0.268235] pci 0000:fe:02.1: [8086:2d91] type 0 class 0x000600
[    0.268281] pci 0000:fe:02.2: [8086:2d92] type 0 class 0x000600
[    0.268326] pci 0000:fe:02.3: [8086:2d93] type 0 class 0x000600
[    0.268370] pci 0000:fe:02.4: [8086:2d94] type 0 class 0x000600
[    0.268415] pci 0000:fe:02.5: [8086:2d95] type 0 class 0x000600
[    0.268462] pci 0000:fe:03.0: [8086:2d98] type 0 class 0x000600
[    0.268506] pci 0000:fe:03.1: [8086:2d99] type 0 class 0x000600
[    0.268551] pci 0000:fe:03.2: [8086:2d9a] type 0 class 0x000600
[    0.268597] pci 0000:fe:03.4: [8086:2d9c] type 0 class 0x000600
[    0.268644] pci 0000:fe:04.0: [8086:2da0] type 0 class 0x000600
[    0.268689] pci 0000:fe:04.1: [8086:2da1] type 0 class 0x000600
[    0.268734] pci 0000:fe:04.2: [8086:2da2] type 0 class 0x000600
[    0.268778] pci 0000:fe:04.3: [8086:2da3] type 0 class 0x000600
[    0.268827] pci 0000:fe:05.0: [8086:2da8] type 0 class 0x000600
[    0.268872] pci 0000:fe:05.1: [8086:2da9] type 0 class 0x000600
[    0.268917] pci 0000:fe:05.2: [8086:2daa] type 0 class 0x000600
[    0.268961] pci 0000:fe:05.3: [8086:2dab] type 0 class 0x000600
[    0.269010] pci 0000:fe:06.0: [8086:2db0] type 0 class 0x000600
[    0.269055] pci 0000:fe:06.1: [8086:2db1] type 0 class 0x000600
[    0.269100] pci 0000:fe:06.2: [8086:2db2] type 0 class 0x000600
[    0.269144] pci 0000:fe:06.3: [8086:2db3] type 0 class 0x000600
[    0.269611] PCI: Discovered peer bus ff
[    0.269635] pci 0000:ff:00.0: [8086:2c70] type 0 class 0x000600
[    0.269678] pci 0000:ff:00.1: [8086:2d81] type 0 class 0x000600
[    0.269728] pci 0000:ff:02.0: [8086:2d90] type 0 class 0x000600
[    0.269770] pci 0000:ff:02.1: [8086:2d91] type 0 class 0x000600
[    0.269813] pci 0000:ff:02.2: [8086:2d92] type 0 class 0x000600
[    0.269855] pci 0000:ff:02.3: [8086:2d93] type 0 class 0x000600
[    0.269898] pci 0000:ff:02.4: [8086:2d94] type 0 class 0x000600
[    0.269940] pci 0000:ff:02.5: [8086:2d95] type 0 class 0x000600
[    0.269985] pci 0000:ff:03.0: [8086:2d98] type 0 class 0x000600
[    0.270058] pci 0000:ff:03.1: [8086:2d99] type 0 class 0x000600
[    0.270100] pci 0000:ff:03.2: [8086:2d9a] type 0 class 0x000600
[    0.270143] pci 0000:ff:03.4: [8086:2d9c] type 0 class 0x000600
[    0.270190] pci 0000:ff:04.0: [8086:2da0] type 0 class 0x000600
[    0.270233] pci 0000:ff:04.1: [8086:2da1] type 0 class 0x000600
[    0.270275] pci 0000:ff:04.2: [8086:2da2] type 0 class 0x000600
[    0.270317] pci 0000:ff:04.3: [8086:2da3] type 0 class 0x000600
[    0.270364] pci 0000:ff:05.0: [8086:2da8] type 0 class 0x000600
[    0.270406] pci 0000:ff:05.1: [8086:2da9] type 0 class 0x000600
[    0.270448] pci 0000:ff:05.2: [8086:2daa] type 0 class 0x000600
[    0.270492] pci 0000:ff:05.3: [8086:2dab] type 0 class 0x000600
[    0.270538] pci 0000:ff:06.0: [8086:2db0] type 0 class 0x000600
[    0.270580] pci 0000:ff:06.1: [8086:2db1] type 0 class 0x000600
[    0.270623] pci 0000:ff:06.2: [8086:2db2] type 0 class 0x000600
[    0.270665] pci 0000:ff:06.3: [8086:2db3] type 0 class 0x000600
[    0.271125] PCI: pci_cache_line_size set to 64 bytes
[    0.271437] reserve RAM buffer: 000000000009b000 - 000000000009ffff 
[    0.271439] reserve RAM buffer: 000000008c21c000 - 000000008fffffff 
[    0.271511] NetLabel: Initializing
[    0.271512] NetLabel:  domain hash size = 128
[    0.271513] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.271524] NetLabel:  unlabeled traffic allowed by default
[    0.271554] Switching to clocksource xen
[    0.272184] Switched to NOHz mode on CPU #7
[    0.272367] Switched to NOHz mode on CPU #16
[    0.272656] Switched to NOHz mode on CPU #12
[    0.272902] Switched to NOHz mode on CPU #21
[    0.273272] Switched to NOHz mode on CPU #8
[    0.273435] Switched to NOHz mode on CPU #17
[    0.273658] Switched to NOHz mode on CPU #4
[    0.273669] Switched to NOHz mode on CPU #13
[    0.273888] Switched to NOHz mode on CPU #22
[    0.274082] AppArmor: AppArmor Filesystem Enabled
[    0.274096] pnp: PnP ACPI init
[    0.274106] ACPI: bus type pnp registered
[    0.274076] Switched to NOHz mode on CPU #9
[    0.274129] Switched to NOHz mode on CPU #1
[    0.274391] pnp 00:00: [bus 00-fd]
[    0.274393] pnp 00:00: [io  0x0cf8-0x0cff]
[    0.274395] pnp 00:00: [io  0x0000-0x0cf7 window]
[    0.274396] pnp 00:00: [io  0x0d00-0xffff window]
[    0.274398] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    0.274399] pnp 00:00: [mem 0x000c4000-0x000cbfff window]
[    0.274401] pnp 00:00: [mem 0xfed40000-0xfedfffff window]
[    0.274323] Switched to NOHz mode on CPU #18
[    0.274407] pnp 00:00: [mem 0xb0000000-0xfdffffff window]
[    0.274408] pnp 00:00: [mem 0x00000000 window]
[    0.274447] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)
[    0.274455] pnp 00:01: [mem 0xfec00000-0xfecfffff]
[    0.274471] pnp 00:01: Plug and Play ACPI device, IDs PNP0003 (active)
[    0.274458] Switched to NOHz mode on CPU #5
[    0.274634] pnp 00:02: [io  0x0000-0x000f]
[    0.274635] pnp 00:02: [io  0x0081-0x0083]
[    0.274636] pnp 00:02: [io  0x0087]
[    0.274638] pnp 00:02: [io  0x0089-0x008b]
[    0.274639] pnp 00:02: [io  0x008f]
[    0.274640] pnp 00:02: [io  0x00c0-0x00df]
[    0.274642] pnp 00:02: [dma 4]
[    0.274672] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.274679] pnp 00:03: [io  0x0070-0x0071]
[    0.274680] pnp 00:03: [io  0x0074-0x0077]
[    0.274709] pnp 00:03: [irq 8]
[    0.274736] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.274744] pnp 00:04: [io  0x00f0]
[    0.274770] pnp 00:04: [irq 13]
[    0.274799] pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.274807] pnp 00:05: [io  0x0061]
[    0.274741] Switched to NOHz mode on CPU #14
[    0.274834] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.274780] Switched to NOHz mode on CPU #23
[    0.274875] pnp 00:06: [mem 0xfed00000-0xfed003ff]
[    0.274906] pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.274917] pnp 00:07: [io  0x0500-0x057f]
[    0.274918] pnp 00:07: [io  0x0400-0x047f]
[    0.274919] pnp 00:07: [io  0x0092]
[    0.274920] pnp 00:07: [io  0x0010-0x001f]
[    0.274922] pnp 00:07: [io  0x0072-0x0073]
[    0.274923] pnp 00:07: [io  0x0080]
[    0.274924] pnp 00:07: [io  0x0084-0x0086]
[    0.274925] pnp 00:07: [io  0x0088]
[    0.274926] pnp 00:07: [io  0x008c-0x008e]
[    0.274928] pnp 00:07: [io  0x0090-0x009f]
[    0.274929] pnp 00:07: [io  0x0800-0x081f]
[    0.274930] pnp 00:07: [io  0x0ca2-0x0ca3]
[    0.274931] pnp 00:07: [io  0x0600-0x061f]
[    0.274932] pnp 00:07: [io  0x0880-0x0883]
[    0.274933] pnp 00:07: [io  0x0ca4-0x0ca5]
[    0.274934] pnp 00:07: [mem 0xfed1c000-0xfed3fffe]
[    0.274936] pnp 00:07: [mem 0xff000000-0xffffffff]
[    0.274937] pnp 00:07: [mem 0xfee00000-0xfeefffff]
[    0.274938] pnp 00:07: [mem 0xfe900000-0xfe90001f]
[    0.274939] pnp 00:07: [mem 0xfea00000-0xfea0001f]
[    0.274941] pnp 00:07: [mem 0xfed1b000-0xfed1bfff]
[    0.275024] system 00:07: [io  0x0500-0x057f] has been reserved
[    0.275026] system 00:07: [io  0x0400-0x047f] has been reserved
[    0.275028] system 00:07: [io  0x0800-0x081f] has been reserved
[    0.275030] system 00:07: [io  0x0ca2-0x0ca3] has been reserved
[    0.275032] system 00:07: [io  0x0600-0x061f] has been reserved
[    0.275034] system 00:07: [io  0x0880-0x0883] has been reserved
[    0.275036] system 00:07: [io  0x0ca4-0x0ca5] has been reserved
[    0.275039] system 00:07: [mem 0xfed1c000-0xfed3fffe] could not be reserved
[    0.275040] system 00:07: [mem 0xff000000-0xffffffff] could not be reserved
[    0.275042] system 00:07: [mem 0xfee00000-0xfeefffff] could not be reserved
[    0.275044] system 00:07: [mem 0xfe900000-0xfe90001f] has been reserved
[    0.275046] system 00:07: [mem 0xfea00000-0xfea0001f] has been reserved
[    0.275048] system 00:07: [mem 0xfed1b000-0xfed1bfff] has been reserved
[    0.275050] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.274974] Switched to NOHz mode on CPU #10
[    0.275224] pnp 00:08: [io  0x02f8-0x02ff]
[    0.275161] Switched to NOHz mode on CPU #19
[    0.275252] pnp 00:08: [irq 3]
[    0.275320] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.275346] pnp 00:09: [mem 0xfed40000-0xfed44fff]
[    0.275376] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active)
[    0.275318] Switched to NOHz mode on CPU #2
[    0.275407] pnp 00:0a: [io  0x0ca2]
[    0.275408] pnp 00:0a: [io  0x0ca3]
[    0.275438] pnp 00:0a: Plug and Play ACPI device, IDs IPI0001 (active)
[    0.275480] pnp: PnP ACPI: found 11 devices
[    0.275481] ACPI: ACPI bus type pnp unregistered
[    0.275434] Switched to NOHz mode on CPU #6
[    0.275612] Switched to NOHz mode on CPU #15
[    0.275787] Switched to NOHz mode on CPU #11
[    0.275818] Switched to NOHz mode on CPU #3
[    0.275978] Switched to NOHz mode on CPU #0
[    0.276097] Switched to NOHz mode on CPU #20
[    0.276391] pci 0000:0f:00.0: no compatible bridge window for [mem 0xfff80000-0xffffffff pref]
[    0.276394] pci 0000:10:00.0: no compatible bridge window for [mem 0xffff0000-0xffffffff pref]
[    0.276411] PCI: max bus depth: 3 pci_try_num: 4
[    0.276590] pci 0000:00:1c.0: BAR 15: assigned [mem 0xb1c00000-0xb1cfffff pref]
[    0.276594] pci 0000:00:1c.5: BAR 14: assigned [mem 0xb1d00000-0xb1efffff]
[    0.276597] pci 0000:00:1c.5: BAR 15: assigned [mem 0xb1f00000-0xb20fffff 64bit pref]
[    0.276599] pci 0000:00:1c.5: BAR 13: assigned [io  0x4000-0x4fff]
[    0.276601] pci 0000:00:1c.4: BAR 13: assigned [io  0x5000-0x5fff]
[    0.276604] pci 0000:00:01.0: PCI bridge to [bus 01-03]
[    0.276607] pci 0000:00:01.0:   bridge window [io  0x2000-0x2fff]
[    0.276612] pci 0000:00:01.0:   bridge window [mem 0xb1a00000-0xb1afffff]
[    0.276616] pci 0000:00:01.0:   bridge window [mem pref disabled]
[    0.276623] pci 0000:00:03.0: PCI bridge to [bus 04-04]
[    0.276624] pci 0000:00:03.0:   bridge window [io  disabled]
[    0.276629] pci 0000:00:03.0:   bridge window [mem disabled]
[    0.276633] pci 0000:00:03.0:   bridge window [mem pref disabled]
[    0.276639] pci 0000:06:02.0: PCI bridge to [bus 07-07]
[    0.276641] pci 0000:06:02.0:   bridge window [io  disabled]
[    0.276647] pci 0000:06:02.0:   bridge window [mem disabled]
[    0.276652] pci 0000:06:02.0:   bridge window [mem pref disabled]
[    0.276661] pci 0000:06:04.0: PCI bridge to [bus 08-08]
[    0.276662] pci 0000:06:04.0:   bridge window [io  disabled]
[    0.276669] pci 0000:06:04.0:   bridge window [mem disabled]
[    0.276674] pci 0000:06:04.0:   bridge window [mem pref disabled]
[    0.276683] pci 0000:05:00.0: PCI bridge to [bus 06-08]
[    0.276684] pci 0000:05:00.0:   bridge window [io  disabled]
[    0.276691] pci 0000:05:00.0:   bridge window [mem disabled]
[    0.276696] pci 0000:05:00.0:   bridge window [mem pref disabled]
[    0.276705] pci 0000:00:05.0: PCI bridge to [bus 05-08]
[    0.276706] pci 0000:00:05.0:   bridge window [io  disabled]
[    0.276711] pci 0000:00:05.0:   bridge window [mem disabled]
[    0.276715] pci 0000:00:05.0:   bridge window [mem pref disabled]
[    0.276722] pci 0000:0a:02.0: PCI bridge to [bus 0b-0b]
[    0.276723] pci 0000:0a:02.0:   bridge window [io  disabled]
[    0.276730] pci 0000:0a:02.0:   bridge window [mem disabled]
[    0.276734] pci 0000:0a:02.0:   bridge window [mem pref disabled]
[    0.276743] pci 0000:0a:04.0: PCI bridge to [bus 0c-0c]
[    0.276744] pci 0000:0a:04.0:   bridge window [io  disabled]
[    0.276751] pci 0000:0a:04.0:   bridge window [mem disabled]
[    0.276756] pci 0000:0a:04.0:   bridge window [mem pref disabled]
[    0.276765] pci 0000:09:00.0: PCI bridge to [bus 0a-0c]
[    0.276766] pci 0000:09:00.0:   bridge window [io  disabled]
[    0.276773] pci 0000:09:00.0:   bridge window [mem disabled]
[    0.276778] pci 0000:09:00.0:   bridge window [mem pref disabled]
[    0.276787] pci 0000:00:07.0: PCI bridge to [bus 09-0c]
[    0.276788] pci 0000:00:07.0:   bridge window [io  disabled]
[    0.276793] pci 0000:00:07.0:   bridge window [mem disabled]
[    0.276797] pci 0000:00:07.0:   bridge window [mem pref disabled]
[    0.276803] pci 0000:00:09.0: PCI bridge to [bus 0d-0d]
[    0.276804] pci 0000:00:09.0:   bridge window [io  disabled]
[    0.276809] pci 0000:00:09.0:   bridge window [mem disabled]
[    0.276813] pci 0000:00:09.0:   bridge window [mem pref disabled]
[    0.276820] pci 0000:00:0a.0: PCI bridge to [bus 0e-0e]
[    0.276823] pci 0000:00:0a.0:   bridge window [io  disabled]
[    0.276828] pci 0000:00:0a.0:   bridge window [mem disabled]
[    0.276832] pci 0000:00:0a.0:   bridge window [mem pref disabled]
[    0.276840] pci 0000:0f:00.0: BAR 6: assigned [mem 0xb1c00000-0xb1c7ffff pref]
[    0.276842] pci 0000:00:1c.0: PCI bridge to [bus 0f-0f]
[    0.276845] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    0.276850] pci 0000:00:1c.0:   bridge window [mem 0xb1900000-0xb19fffff]
[    0.276855] pci 0000:00:1c.0:   bridge window [mem 0xb1c00000-0xb1cfffff pref]
[    0.276863] pci 0000:10:00.0: BAR 6: assigned [mem 0xb1810000-0xb181ffff pref]
[    0.276864] pci 0000:00:1c.4: PCI bridge to [bus 10-10]
[    0.276867] pci 0000:00:1c.4:   bridge window [io  0x5000-0x5fff]
[    0.276873] pci 0000:00:1c.4:   bridge window [mem 0xb1000000-0xb18fffff]
[    0.276877] pci 0000:00:1c.4:   bridge window [mem 0xb0000000-0xb0ffffff 64bit pref]
[    0.276884] pci 0000:00:1c.5: PCI bridge to [bus 11-11]
[    0.276887] pci 0000:00:1c.5:   bridge window [io  0x4000-0x4fff]
[    0.276893] pci 0000:00:1c.5:   bridge window [mem 0xb1d00000-0xb1efffff]
[    0.276897] pci 0000:00:1c.5:   bridge window [mem 0xb1f00000-0xb20fffff 64bit pref]
[    0.276905] pci 0000:00:1e.0: PCI bridge to [bus 12-12]
[    0.276906] pci 0000:00:1e.0:   bridge window [io  disabled]
[    0.276911] pci 0000:00:1e.0:   bridge window [mem disabled]
[    0.276915] pci 0000:00:1e.0:   bridge window [mem pref disabled]
[    0.276938] pci 0000:00:01.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    0.276943] pci 0000:00:01.0: setting latency timer to 64
[    0.276953] pci 0000:00:03.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
[    0.276957] pci 0000:00:03.0: setting latency timer to 64
[    0.276967] pci 0000:00:05.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
[    0.276971] pci 0000:00:05.0: setting latency timer to 64
[    0.276981] pci 0000:05:00.0: setting latency timer to 64
[    0.276991] pci 0000:06:02.0: setting latency timer to 64
[    0.277001] pci 0000:06:04.0: setting latency timer to 64
[    0.277013] pci 0000:00:07.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
[    0.277017] pci 0000:00:07.0: setting latency timer to 64
[    0.277027] pci 0000:09:00.0: setting latency timer to 64
[    0.277037] pci 0000:0a:02.0: setting latency timer to 64
[    0.277048] pci 0000:0a:04.0: setting latency timer to 64
[    0.277058] pci 0000:00:09.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
[    0.277062] pci 0000:00:09.0: setting latency timer to 64
[    0.277071] pci 0000:00:0a.0: PCI INT A -> GSI 33 (level, low) -> IRQ 33
[    0.277075] pci 0000:00:0a.0: setting latency timer to 64
[    0.277085] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.277090] pci 0000:00:1c.0: setting latency timer to 64
[    0.277097] pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.277101] pci 0000:00:1c.4: setting latency timer to 64
[    0.277111] pci 0000:00:1c.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    0.277116] pci 0000:00:1c.5: setting latency timer to 64
[    0.277123] pci 0000:00:1e.0: setting latency timer to 64
[    0.277128] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.277129] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.277131] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.277132] pci_bus 0000:00: resource 7 [mem 0xfed40000-0xfedfffff]
[    0.277134] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xfdffffff]
[    0.277135] pci_bus 0000:01: resource 0 [io  0x2000-0x2fff]
[    0.277136] pci_bus 0000:01: resource 1 [mem 0xb1a00000-0xb1afffff]
[    0.277139] pci_bus 0000:0f: resource 0 [io  0x1000-0x1fff]
[    0.277140] pci_bus 0000:0f: resource 1 [mem 0xb1900000-0xb19fffff]
[    0.277142] pci_bus 0000:0f: resource 2 [mem 0xb1c00000-0xb1cfffff pref]
[    0.277143] pci_bus 0000:10: resource 0 [io  0x5000-0x5fff]
[    0.277145] pci_bus 0000:10: resource 1 [mem 0xb1000000-0xb18fffff]
[    0.277146] pci_bus 0000:10: resource 2 [mem 0xb0000000-0xb0ffffff 64bit pref]
[    0.277148] pci_bus 0000:11: resource 0 [io  0x4000-0x4fff]
[    0.277149] pci_bus 0000:11: resource 1 [mem 0xb1d00000-0xb1efffff]
[    0.277151] pci_bus 0000:11: resource 2 [mem 0xb1f00000-0xb20fffff 64bit pref]
[    0.277153] pci_bus 0000:12: resource 4 [io  0x0000-0x0cf7]
[    0.277154] pci_bus 0000:12: resource 5 [io  0x0d00-0xffff]
[    0.277155] pci_bus 0000:12: resource 6 [mem 0x000a0000-0x000bffff]
[    0.277157] pci_bus 0000:12: resource 7 [mem 0xfed40000-0xfedfffff]
[    0.277158] pci_bus 0000:12: resource 8 [mem 0xb0000000-0xfdffffff]
[    0.277160] pci_bus 0000:fe: resource 0 [io  0x0000-0xffff]
[    0.277161] pci_bus 0000:fe: resource 1 [mem 0x00000000-0xffffffffff]
[    0.277163] pci_bus 0000:ff: resource 0 [io  0x0000-0xffff]
[    0.277165] pci_bus 0000:ff: resource 1 [mem 0x00000000-0xffffffffff]
[    0.279638] NET: Registered protocol family 2
[    0.280515] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.283580] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    0.284178] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.284311] TCP: Hash tables configured (established 262144 bind 65536)
[    0.284313] TCP reno registered
[    0.284318] UDP hash table entries: 16384 (order: 8, 1048576 bytes)
[    0.284452] UDP-Lite hash table entries: 16384 (order: 8, 1048576 bytes)
[    0.285968] NET: Registered protocol family 1
[    0.286204] pci 0000:00:1a.0: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286226] pci 0000:00:1a.0: PCI INT D disabled
[    0.286239] pci 0000:00:1a.1: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286260] pci 0000:00:1a.1: PCI INT D disabled
[    0.286272] pci 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286292] pci 0000:00:1a.2: PCI INT D disabled
[    0.286314] pci 0000:00:1a.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[    0.286836] pci 0000:00:1a.7: PCI INT D disabled
[    0.286870] pci 0000:00:1d.0: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.286893] pci 0000:00:1d.0: PCI INT D disabled
[    0.286906] pci 0000:00:1d.1: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.286926] pci 0000:00:1d.1: PCI INT D disabled
[    0.286938] pci 0000:00:1d.2: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.286958] pci 0000:00:1d.2: PCI INT D disabled
[    0.286980] pci 0000:00:1d.7: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    0.287102] pci 0000:00:1d.7: PCI INT D disabled
[    0.287251] pci 0000:10:00.0: Boot video device
[    0.287384] PCI: CLS 64 bytes, default 64
[    0.287425] Unpacking initramfs...
[    0.297648] Freeing initrd memory: 17484k freed
[    0.302827] MCE: bind virq for DOM0 logging
[    0.303235] MCE_DOM0_LOG: enter dom0 mce vIRQ handler
[    0.303236] MCE_DOM0_LOG: No more urgent data
[    0.303237] MCE_DOM0_LOG: No more nonurgent data
[    0.305384] audit: initializing netlink socket (disabled)
[    0.305397] type=2000 audit(1359974461.304:1): initialized
[    0.340373] VFS: Disk quotas dquot_6.5.2
[    0.340797] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.341206] msgmni has been set to 12038
[    0.341815] alg: No test for stdrng (krng)
[    0.342224] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.342297] io scheduler noop registered
[    0.342298] io scheduler deadline registered
[    0.343033] io scheduler cfq registered (default)
[    0.343618] pcieport 0000:00:01.0: setting latency timer to 64
[    0.343699] pcieport 0000:00:01.0: irq 68 (303) for MSI/MSI-X
[    0.343786] pcieport 0000:00:03.0: setting latency timer to 64
[    0.343851] pcieport 0000:00:03.0: irq 69 (302) for MSI/MSI-X
[    0.343933] pcieport 0000:00:05.0: setting latency timer to 64
[    0.343997] pcieport 0000:00:05.0: irq 70 (301) for MSI/MSI-X
[    0.344080] pcieport 0000:00:07.0: setting latency timer to 64
[    0.344182] pcieport 0000:00:07.0: irq 71 (300) for MSI/MSI-X
[    0.344266] pcieport 0000:00:09.0: setting latency timer to 64
[    0.344332] pcieport 0000:00:09.0: irq 72 (299) for MSI/MSI-X
[    0.344413] pcieport 0000:00:0a.0: setting latency timer to 64
[    0.344479] pcieport 0000:00:0a.0: irq 73 (298) for MSI/MSI-X
[    0.344567] pcieport 0000:00:1c.0: setting latency timer to 64
[    0.344639] pcieport 0000:00:1c.0: irq 74 (297) for MSI/MSI-X
[    0.344736] pcieport 0000:00:1c.4: setting latency timer to 64
[    0.344810] pcieport 0000:00:1c.4: irq 75 (296) for MSI/MSI-X
[    0.344906] pcieport 0000:00:1c.5: setting latency timer to 64
[    0.344977] pcieport 0000:00:1c.5: irq 76 (295) for MSI/MSI-X
[    0.345074] pcieport 0000:05:00.0: setting latency timer to 64
[    0.345180] pcieport 0000:06:02.0: setting latency timer to 64
[    0.345281] pcieport 0000:06:02.0: irq 77 (294) for MSI/MSI-X
[    0.345383] pcieport 0000:06:04.0: setting latency timer to 64
[    0.345484] pcieport 0000:06:04.0: irq 78 (293) for MSI/MSI-X
[    0.345586] pcieport 0000:09:00.0: setting latency timer to 64
[    0.345692] pcieport 0000:0a:02.0: setting latency timer to 64
[    0.345793] pcieport 0000:0a:02.0: irq 79 (292) for MSI/MSI-X
[    0.345899] pcieport 0000:0a:04.0: setting latency timer to 64
[    0.345999] pcieport 0000:0a:04.0: irq 80 (291) for MSI/MSI-X
[    0.346135] aer 0000:00:01.0:pcie02: service driver aer loaded
[    0.346169] aer 0000:00:03.0:pcie02: service driver aer loaded
[    0.346215] aer 0000:00:05.0:pcie02: service driver aer loaded
[    0.346263] aer 0000:00:07.0:pcie02: service driver aer loaded
[    0.346295] aer 0000:00:09.0:pcie02: service driver aer loaded
[    0.346327] aer 0000:00:0a.0:pcie02: service driver aer loaded
[    0.346343] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[    0.346344] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    0.346346] pci 0000:01:00.1: Signaling PME through PCIe PME interrupt
[    0.346350] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[    0.346358] pcieport 0000:00:03.0: Signaling PME through PCIe PME interrupt
[    0.346362] pcie_pme 0000:00:03.0:pcie01: service driver pcie_pme loaded
[    0.346371] pcieport 0000:00:05.0: Signaling PME through PCIe PME interrupt
[    0.346372] pcieport 0000:05:00.0: Signaling PME through PCIe PME interrupt
[    0.346373] pcieport 0000:06:02.0: Signaling PME through PCIe PME interrupt
[    0.346375] pcieport 0000:06:04.0: Signaling PME through PCIe PME interrupt
[    0.346379] pcie_pme 0000:00:05.0:pcie01: service driver pcie_pme loaded
[    0.346387] pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt
[    0.346389] pcieport 0000:09:00.0: Signaling PME through PCIe PME interrupt
[    0.346390] pcieport 0000:0a:02.0: Signaling PME through PCIe PME interrupt
[    0.346391] pcieport 0000:0a:04.0: Signaling PME through PCIe PME interrupt
[    0.346395] pcie_pme 0000:00:07.0:pcie01: service driver pcie_pme loaded
[    0.346404] pcieport 0000:00:09.0: Signaling PME through PCIe PME interrupt
[    0.346408] pcie_pme 0000:00:09.0:pcie01: service driver pcie_pme loaded
[    0.346417] pcieport 0000:00:0a.0: Signaling PME through PCIe PME interrupt
[    0.346421] pcie_pme 0000:00:0a.0:pcie01: service driver pcie_pme loaded
[    0.346447] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[    0.346449] pci 0000:0f:00.0: Signaling PME through PCIe PME interrupt
[    0.346454] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[    0.346480] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt
[    0.346482] pci 0000:10:00.0: Signaling PME through PCIe PME interrupt
[    0.346486] pcie_pme 0000:00:1c.4:pcie01: service driver pcie_pme loaded
[    0.346511] pcieport 0000:00:1c.5: Signaling PME through PCIe PME interrupt
[    0.346516] pcie_pme 0000:00:1c.5:pcie01: service driver pcie_pme loaded
[    0.346674] Non-volatile memory driver v1.3
[    0.346752] Xen virtual console successfully installed as xvc0
[    0.346781] Fixed MDIO Bus: probed
[    0.346815] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    0.347699] i8042: No controller found
[    0.347736] mousedev: PS/2 mouse device common for all mice
[    0.347886] EFI Variables Facility v0.08 2004-May-17
[    0.348466] TCP cubic registered
[    0.348477] Registering the dns_resolver key type
[    0.348546] registered taskstats version 1
[    0.349436]   Magic number: 1:466:678
[    0.350013] Freeing unused kernel memory: 428k freed
[    0.350133] Write protecting the kernel read-only data: 6868k
[    0.422206] SCSI subsystem initialized
[    0.428554] Fusion MPT base driver 4.28.00.00suse
[    0.428556] Copyright (c) 1999-2010 LSI Corporation
[    0.434123] Fusion MPT SAS Host driver 4.28.00.00suse
[    0.434163] mptsas 0000:0f:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    0.434168] mptbase: ioc0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total memory = 24654548 kB
[    0.434700] mptbase: ioc0: Initiating bringup
[    1.016109] ioc0: LSISAS1078 C2: Capabilities={Initiator}
[    1.016191] mptsas 0000:0f:00.0: setting latency timer to 64
[    1.016208] Adjusted maximum contiguous region order to 7
[   13.834395] scsi0 : ioc0: LSISAS1078 C2, FwRev=011b0000h, Ports=1, MaxQ=276, IRQ=16
[   14.844149] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221000000000000
[   14.844268] scsi target0:0:0: mptsas: ioc0: add device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1221000000000000
[   14.846987] scsi 0:0:0:0: Direct-Access     ATA      ST9500530NS      SN04 PQ: 0 ANSI: 5
[   14.847688] scsi 0:0:0:0: mptscsih: ioc0: qdepth=64, tagged=1, simple=1, ordered=0, scsi_level=6, cmd_que=1
[   14.847692] sdev dma_alignment 511 
[   14.860458] libata version 3.00 loaded.
[   14.865330] ahci 0000:00:1f.2: version 3.0
[   14.865351] ahci 0000:00:1f.2: PCI INT B -> GSI 18 (level, low) -> IRQ 18
[   14.865862] ahci 0000:00:1f.2: irq 82 (290) for MSI/MSI-X
[   14.865873] ahci 0000:00:1f.2: forcing PORTS_IMPL to 0x3f
[   14.865927] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[   14.865930] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc 
[   14.865934] ahci 0000:00:1f.2: setting latency timer to 64
[   14.866823] scsi1 : ahci
[   14.866995] scsi2 : ahci
[   14.867159] scsi3 : ahci
[   14.867339] scsi4 : ahci
[   14.867481] scsi5 : ahci
[   14.867577] scsi6 : ahci
[   14.867698] ata1: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20100 irq 82
[   14.867700] ata2: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20180 irq 82
[   14.867702] ata3: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20200 irq 82
[   14.867704] ata4: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20280 irq 82
[   14.867706] ata5: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20300 irq 82
[   14.867708] ata6: SATA max UDMA/133 abar m2048@0xb1b20000 port 0xb1b20380 irq 82
[   15.892163] ata5: failed to resume link (SControl 0)
[   15.892184] ata5: SATA link down (SStatus 0 SControl 0)
[   15.892199] ata1: failed to resume link (SControl 0)
[   15.892209] ata1: SATA link down (SStatus 0 SControl 0)
[   15.892219] ata6: failed to resume link (SControl 0)
[   15.892229] ata6: SATA link down (SStatus 0 SControl 0)
[   15.892240] ata3: failed to resume link (SControl 0)
[   15.892249] ata3: SATA link down (SStatus 0 SControl 0)
[   15.892255] ata4: failed to resume link (SControl 0)
[   15.892263] ata4: SATA link down (SStatus 0 SControl 0)
[   15.892270] ata2: failed to resume link (SControl 0)
[   15.892278] ata2: SATA link down (SStatus 0 SControl 0)
[   15.903622] netfront: Initialising virtual ethernet driver.
[   15.930557] rdac: device handler registered
[   15.940550] hp_sw: device handler registered
[   15.951150] emc: device handler registered
[   15.961035] alua: device handler registered
[   15.965823] udev: starting version 147
[   16.012568] usbcore: registered new interface driver usbfs
[   16.012588] usbcore: registered new interface driver hub
[   16.012675] usbcore: registered new device driver usb
[   16.014313] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[   16.015546] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   16.015584] ehci_hcd 0000:00:1a.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.015611] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[   16.015614] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[   16.015638] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[   16.015689] ehci_hcd 0000:00:1a.7: debug port 1
[   16.019587] ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
[   16.019656] ehci_hcd 0000:00:1a.7: irq 19, io mem 0xb1b22000
[   16.033645] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[   16.033662] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   16.033663] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.033665] usb usb1: Product: EHCI Host Controller
[   16.033666] usb usb1: Manufacturer: Linux 3.0.51-0.7.9-xen ehci_hcd
[   16.033667] usb usb1: SerialNumber: 0000:00:1a.7
[   16.033762] hub 1-0:1.0: USB hub found
[   16.033766] hub 1-0:1.0: 6 ports detected
[   16.033889] ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.033911] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[   16.033914] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   16.033922] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[   16.033974] ehci_hcd 0000:00:1d.7: debug port 1
[   16.037864] ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
[   16.037871] ehci_hcd 0000:00:1d.7: irq 16, io mem 0xb1b21000
[   16.053691] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[   16.053716] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[   16.053719] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.053722] usb usb2: Product: EHCI Host Controller
[   16.053724] usb usb2: Manufacturer: Linux 3.0.51-0.7.9-xen ehci_hcd
[   16.053726] usb usb2: SerialNumber: 0000:00:1d.7
[   16.053843] hub 2-0:1.0: USB hub found
[   16.053846] hub 2-0:1.0: 6 ports detected
[   16.067580] sd 0:0:0:0: [sda] Write Protect is off
[   16.067587] sd 0:0:0:0: [sda] Mode Sense: 73 00 00 08
[   16.069821] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   16.118840] uhci_hcd: USB Universal Host Controller Interface driver
[   16.119347] uhci_hcd 0000:00:1a.0: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.119359] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[   16.119363] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[   16.119374] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[   16.119411] uhci_hcd 0000:00:1a.0: irq 19, io base 0x000030e0
[   16.119812] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[   16.119815] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.119817] usb usb3: Product: UHCI Host Controller
[   16.119819] usb usb3: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.119822] usb usb3: SerialNumber: 0000:00:1a.0
[   16.119920] hub 3-0:1.0: USB hub found
[   16.119924] hub 3-0:1.0: 2 ports detected
[   16.120028] uhci_hcd 0000:00:1a.1: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.120037] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[   16.120040] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[   16.120046] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[   16.120076] uhci_hcd 0000:00:1a.1: irq 19, io base 0x000030c0
[   16.120131] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120133] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120134] usb usb4: Product: UHCI Host Controller
[   16.120136] usb usb4: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120137] usb usb4: SerialNumber: 0000:00:1a.1
[   16.120206] hub 4-0:1.0: USB hub found
[   16.120211] hub 4-0:1.0: 2 ports detected
[   16.120288] uhci_hcd 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[   16.120296] uhci_hcd 0000:00:1a.2: setting latency timer to 64
[   16.120299] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[   16.120305] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[   16.120336] uhci_hcd 0000:00:1a.2: irq 19, io base 0x000030a0
[   16.120390] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120392] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120393] usb usb5: Product: UHCI Host Controller
[   16.120394] usb usb5: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120396] usb usb5: SerialNumber: 0000:00:1a.2
[   16.120465] hub 5-0:1.0: USB hub found
[   16.120468] hub 5-0:1.0: 2 ports detected
[   16.120547] uhci_hcd 0000:00:1d.0: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.120555] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[   16.120558] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   16.120563] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[   16.120594] uhci_hcd 0000:00:1d.0: irq 16, io base 0x00003080
[   16.120648] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120650] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120652] usb usb6: Product: UHCI Host Controller
[   16.120653] usb usb6: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120655] usb usb6: SerialNumber: 0000:00:1d.0
[   16.120726] hub 6-0:1.0: USB hub found
[   16.120731] hub 6-0:1.0: 2 ports detected
[   16.120805] uhci_hcd 0000:00:1d.1: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.120814] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[   16.120816] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   16.120823] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[   16.120851] uhci_hcd 0000:00:1d.1: irq 16, io base 0x00003060
[   16.120924] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[   16.120925] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.120927] usb usb7: Product: UHCI Host Controller
[   16.120928] usb usb7: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.120930] usb usb7: SerialNumber: 0000:00:1d.1
[   16.120997] hub 7-0:1.0: USB hub found
[   16.121002] hub 7-0:1.0: 2 ports detected
[   16.121075] uhci_hcd 0000:00:1d.2: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[   16.121083] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[   16.121086] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   16.121091] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[   16.121118] uhci_hcd 0000:00:1d.2: irq 16, io base 0x00003040
[   16.121215] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[   16.121216] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.121218] usb usb8: Product: UHCI Host Controller
[   16.121219] usb usb8: Manufacturer: Linux 3.0.51-0.7.9-xen uhci_hcd
[   16.121221] usb usb8: SerialNumber: 0000:00:1d.2
[   16.121283] hub 8-0:1.0: USB hub found
[   16.121285] hub 8-0:1.0: 2 ports detected
[   16.196826]  sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
[   16.269865] sd 0:0:0:0: [sda] Attached SCSI disk
[   16.468213] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[   16.602327] usb 2-1: New USB device found, idVendor=05e3, idProduct=0719
[   16.602331] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[   16.602334] usb 2-1: Product: USB Storage
[   16.602337] usb 2-1: SerialNumber: 000000000033
[   16.848147] usb 5-1: new full-speed USB device number 2 using uhci_hcd
[   17.016431] usb 5-1: New USB device found, idVendor=046b, idProduct=ff10
[   17.016435] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   17.016438] usb 5-1: Product: Virtual Keyboard and Mouse
[   17.016441] usb 5-1: Manufacturer: American Megatrends Inc.
[   17.016443] usb 5-1: SerialNumber: serial
[   17.038058] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.0/input/input0
[   17.038134] generic-usb 0003:046B:FF10.0001: input,hidraw0: USB HID v1.10 Keyboard [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input0
[   17.041631] input: American Megatrends Inc. Virtual Keyboard and Mouse as /devices/pci0000:00/0000:00:1a.2/usb5/5-1/5-1:1.1/input/input1
[   17.041725] generic-usb 0003:046B:FF10.0002: input,hidraw1: USB HID v1.10 Mouse [American Megatrends Inc. Virtual Keyboard and Mouse] on usb-0000:00:1a.2-1/input1
[   17.041739] usbcore: registered new interface driver usbhid
[   17.041741] usbhid: USB HID core driver
[   17.349457] kjournald starting.  Commit interval 15 seconds
[   17.350430] EXT3-fs (sda6): using internal journal
[   17.350435] EXT3-fs (sda6): mounted filesystem with ordered data mode
[   19.104265] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[   19.172491] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[   19.749833] udev: starting version 147
[   19.826436] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2
[   19.826499] ACPI: Sleep Button [SLPB]
[   19.826555] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[   19.826598] ACPI: Power Button [PWRF]
[   19.946211] Fusion MPT misc device (ioctl) driver 4.28.00.00suse
[   19.946270] mptctl: Registered with Fusion MPT base driver
[   19.946273] mptctl: /dev/mptctl @ (major,minor=10,220)
[   20.009439] rtc_cmos 00:03: RTC can wake from S4
[   20.009589] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[   20.009675] rtc0: alarms up to one month, y3k, 114 bytes nvram
[   20.021378] ioatdma: Intel(R) QuickData Technology Driver 4.00
[   20.021800] ioatdma 0000:00:16.0: PCI INT A -> GSI 43 (level, low) -> IRQ 43
[   20.022202] ioatdma 0000:00:16.0: setting latency timer to 64
[   20.022316] ioatdma 0000:00:16.0: irq 83 (289) for MSI/MSI-X
[   20.022591] ioatdma 0000:00:16.1: PCI INT B -> GSI 44 (level, low) -> IRQ 44
[   20.022616] ioatdma 0000:00:16.1: setting latency timer to 64
[   20.022717] ioatdma 0000:00:16.1: irq 84 (288) for MSI/MSI-X
[   20.022970] ioatdma 0000:00:16.2: PCI INT C -> GSI 45 (level, low) -> IRQ 45
[   20.022995] ioatdma 0000:00:16.2: setting latency timer to 64
[   20.023093] ioatdma 0000:00:16.2: irq 85 (287) for MSI/MSI-X
[   20.023340] ioatdma 0000:00:16.3: PCI INT D -> GSI 46 (level, low) -> IRQ 46
[   20.023365] ioatdma 0000:00:16.3: setting latency timer to 64
[   20.023465] ioatdma 0000:00:16.3: irq 86 (286) for MSI/MSI-X
[   20.023709] ioatdma 0000:00:16.4: PCI INT A -> GSI 43 (level, low) -> IRQ 43
[   20.023733] ioatdma 0000:00:16.4: setting latency timer to 64
[   20.023834] ioatdma 0000:00:16.4: irq 87 (285) for MSI/MSI-X
[   20.024107] ioatdma 0000:00:16.5: PCI INT B -> GSI 44 (level, low) -> IRQ 44
[   20.024136] ioatdma 0000:00:16.5: setting latency timer to 64
[   20.024241] ioatdma 0000:00:16.5: irq 88 (284) for MSI/MSI-X
[   20.024541] ioatdma 0000:00:16.6: PCI INT C -> GSI 45 (level, low) -> IRQ 45
[   20.024618] ioatdma 0000:00:16.6: setting latency timer to 64
[   20.024720] ioatdma 0000:00:16.6: irq 89 (283) for MSI/MSI-X
[   20.025000] ioatdma 0000:00:16.7: PCI INT D -> GSI 46 (level, low) -> IRQ 46
[   20.025048] ioatdma 0000:00:16.7: setting latency timer to 64
[   20.025173] ioatdma 0000:00:16.7: irq 90 (282) for MSI/MSI-X
[   20.040633] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[   20.057692] Intel(R) Gigabit Ethernet Network Driver - version 3.0.6-k2
[   20.057695] Copyright (c) 2007-2011 Intel Corporation.
[   20.057743] igb 0000:01:00.0: PCI INT B -> GSI 40 (level, low) -> IRQ 40
[   20.057761] igb 0000:01:00.0: setting latency timer to 64
[   20.058609] igb 0000:01:00.0: irq 91 (281) for MSI/MSI-X
[   20.058660] igb 0000:01:00.0: irq 92 (280) for MSI/MSI-X
[   20.058710] igb 0000:01:00.0: irq 93 (279) for MSI/MSI-X
[   20.058760] igb 0000:01:00.0: irq 94 (278) for MSI/MSI-X
[   20.058809] igb 0000:01:00.0: irq 95 (277) for MSI/MSI-X
[   20.058860] igb 0000:01:00.0: irq 96 (276) for MSI/MSI-X
[   20.058912] igb 0000:01:00.0: irq 97 (275) for MSI/MSI-X
[   20.058963] igb 0000:01:00.0: irq 98 (274) for MSI/MSI-X
[   20.059013] igb 0000:01:00.0: irq 99 (273) for MSI/MSI-X
[   20.059031] igb 0000:01:00.0: 0 vfs allocated
[   20.059063] igb 0000:01:00.0: PHY reset is blocked due to SOL/IDER session.
[   20.073101] iTCO_vendor_support: vendor-support=0
[   20.077593] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06
[   20.077717] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[   20.128112] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
[   20.128116] igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e4
[   20.128237] igb 0000:01:00.0: eth0: PBA No: 0080FF-0FF
[   20.128239] igb 0000:01:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[   20.128263] igb 0000:01:00.1: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[   20.128277] igb 0000:01:00.1: setting latency timer to 64
[   20.128532] input: PC Speaker as /devices/platform/pcspkr/input/input4
[   20.128715] igb 0000:01:00.1: irq 100 (272) for MSI/MSI-X
[   20.128761] igb 0000:01:00.1: irq 101 (271) for MSI/MSI-X
[   20.128805] igb 0000:01:00.1: irq 102 (270) for MSI/MSI-X
[   20.128849] igb 0000:01:00.1: irq 103 (269) for MSI/MSI-X
[   20.128902] igb 0000:01:00.1: irq 104 (268) for MSI/MSI-X
[   20.128947] igb 0000:01:00.1: irq 105 (267) for MSI/MSI-X
[   20.128994] igb 0000:01:00.1: irq 106 (266) for MSI/MSI-X
[   20.129039] igb 0000:01:00.1: irq 107 (265) for MSI/MSI-X
[   20.129085] igb 0000:01:00.1: irq 108 (264) for MSI/MSI-X
[   20.129098] igb 0000:01:00.1: 0 vfs allocated
[   20.233347] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   20.290132] tpm_tis 00:09: 1.2 TPM (device-id 0x0, rev-id 78)
[   20.293251] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 18 (level, low) -> IRQ 18
[   20.320628] igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
[   20.320633] igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:15:17:da:f9:e5
[   20.320711] igb 0000:01:00.1: eth1: PBA No: 0080FF-0FF
[   20.320714] igb 0000:01:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[   20.407692] i7core_edac: Unknown symbol edac_mc_del_mc (err 0)
[   20.407714] i7core_edac: Unknown symbol edac_mc_add_mc (err 0)
[   20.407728] i7core_edac: Unknown symbol edac_pci_create_generic_ctl (err 0)
[   20.407741] i7core_edac: Unknown symbol edac_mc_alloc (err 0)
[   20.407753] i7core_edac: Unknown symbol edac_mc_handle_fbd_ce (err 0)
[   20.407765] i7core_edac: Unknown symbol edac_mc_free (err 0)
[   20.407792] i7core_edac: Unknown symbol edac_pci_release_generic_ctl (err 0)
[   20.407804] i7core_edac: Unknown symbol edac_mc_handle_fbd_ue (err 0)
[   20.454868] Initializing USB Mass Storage driver...
[   20.455645] scsi7 : usb-storage 2-1:1.0
[   20.455737] usbcore: registered new interface driver usb-storage
[   20.455740] USB Mass Storage support registered.
[   20.632488] NET: Registered protocol family 10
[   21.456311] scsi 7:0:0:0: CD-ROM            TEAC     DV-W28S-V        1.0A PQ: 0 ANSI: 0
[   21.456470] scsi 7:0:0:0: Attached scsi generic sg1 type 5
[   21.505640] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[   21.505644] cdrom: Uniform CD-ROM driver Revision: 3.20
[   21.505760] sr 7:0:0:0: Attached scsi CD-ROM sr0
[   21.747501] Adding 2096476k swap on /dev/sda2.  Priority:-1 extents:1 across:2096476k 
[   23.066092] device-mapper: uevent: version 1.0.3
[   23.066890] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
[   24.946268] loop: module loaded
[   25.059150] kjournald starting.  Commit interval 15 seconds
[   25.059658] EXT3-fs (sda5): mounted filesystem with ordered data mode
[   26.843989] fuse init (API version 7.16)
[   29.284013] type=1400 audit(1359974490.280:2): apparmor="STATUS" operation="profile_load" name="/bin/ping" pid=1444 comm="apparmor_parser"
[   29.313534] type=1400 audit(1359974490.312:3): apparmor="STATUS" operation="profile_load" name="/sbin/klogd" pid=1449 comm="apparmor_parser"
[   29.373425] type=1400 audit(1359974490.372:4): apparmor="STATUS" operation="profile_load" name="/sbin/syslog-ng" pid=1453 comm="apparmor_parser"
[   29.435199] type=1400 audit(1359974490.432:5): apparmor="STATUS" operation="profile_load" name="/sbin/syslogd" pid=1457 comm="apparmor_parser"
[   29.478778] type=1400 audit(1359974490.476:6): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-explicit-grant-helper" pid=1462 comm="apparmor_parser"
[   29.543126] type=1400 audit(1359974490.540:7): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-grant-helper" pid=1466 comm="apparmor_parser"
[   29.608731] type=1400 audit(1359974490.604:8): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-grant-helper-pam" pid=1470 comm="apparmor_parser"
[   29.667902] type=1400 audit(1359974490.664:9): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-read-auth-helper" pid=1474 comm="apparmor_parser"
[   29.699853] type=1400 audit(1359974490.696:10): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-resolve-exe-helper" pid=1478 comm="apparmor_parser"
[   29.732326] type=1400 audit(1359974490.732:11): apparmor="STATUS" operation="profile_load" name="/usr/lib/PolicyKit/polkit-revoke-helper" pid=1482 comm="apparmor_parser"
[   31.832062] microcode: Microcode Update Driver: v2.00-xen <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   35.372759] igb: eth0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
[   35.373923] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   35.374841] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   38.190222] Bridge firewalling registered
[   38.206036] device eth0 entered promiscuous mode
[   38.216718] br0: port 1(eth0) entering forwarding state
[   38.216723] br0: port 1(eth0) entering forwarding state
[   38.865943] NET: Registered protocol family 17
[   42.194050] auditd (3594): /proc/3594/oom_adj is deprecated, please use /proc/3594/oom_score_adj instead.
[   42.744861] RPC: Registered named UNIX socket transport module.
[   42.744865] RPC: Registered udp transport module.
[   42.744867] RPC: Registered tcp transport module.
[   42.744869] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   42.801661] FS-Cache: Loaded
[   42.834796] FS-Cache: Netfs 'nfs' registered for caching
[   44.273808] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
[   45.549687] eth0: no IPv6 routers present
[   46.246164] Event-channel device installed.
[   46.392132] usbcore: registered new interface driver usbback
[   46.415498] blktap_device_init: 21 callbacks suppressed
[   46.415501] blktap_device_init: blktap device major 252
[   46.415506] blktap_ring_init: blktap ring major: 250
[   46.569965] Unable to read sysrq code in control/sysrq
[   49.028133] br0: no IPv6 routers present
[  586.633768] blktap_control_allocate_tap: allocated tap ffff8805ac1b9000
[  586.655151] blktap_ring_open: opening device blktap0
[  586.655155] blktap_ring_open: opened device 0
[  586.655171] blktap_ring_mmap: blktap: mapping pid is 4908
[  586.656089] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  586.656095] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  586.656100] blktap_device_create: minor 0 sectors 2097152 sector-size 512
[  586.656409] blktap_device_create: creation of 252:0: 0
[  587.201145] device vif1.0 entered promiscuous mode
[  587.205967] br0: port 2(vif1.0) entering forwarding state
[  587.205974] br0: port 2(vif1.0) entering forwarding state
[  587.328994] ip_tables: (C) 2000-2006 Netfilter Core Team
[  597.692122] vif1.0: no IPv6 routers present
[  609.373001] blkback: ring-ref 8, event-channel 22, protocol 1 (x86_64-abi)
[  621.284358] br0: port 2(vif1.0) entering forwarding state
[  621.285202] device vif1.0 left promiscuous mode
[  621.285206] br0: port 2(vif1.0) entering disabled state
[  621.328927] blktap_ring_vm_close: unmapping ring 0
[  621.328932] blktap_ring_release: freeing device 0
[  621.333129] blktap_device_destroy: destroy device 0 users 0
[  635.451911] blktap_control_allocate_tap: allocated tap ffff8805ac1b9000
[  635.458825] blktap_ring_open: opening device blktap0
[  635.458830] blktap_ring_open: opened device 0
[  635.458845] blktap_ring_mmap: blktap: mapping pid is 5112
[  635.459741] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  635.459747] blktap_validate_params: aio:/bax.arch.suse.de-olaf_xenimages/bug694863/vdisk-sles11sp2_full_minimal_nfsroot-bug694863-disk0: capacity: 2097152, sector-size: 512
[  635.459751] blktap_device_create: minor 0 sectors 2097152 sector-size 512
[  635.459943] blktap_device_create: creation of 252:0: 0
[  635.709203] device vif2.0 entered promiscuous mode
[  635.713903] br0: port 2(vif2.0) entering forwarding state
[  635.713908] br0: port 2(vif2.0) entering forwarding state
[  646.332056] vif2.0: no IPv6 routers present
[  663.955441] blkback: ring-ref 8, event-channel 7, protocol 1 (x86_64-abi)

--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="screenlog.0.txt"
Content-Transfer-Encoding: quoted-printable

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-3.0.51-0.7.9-default root=3Dbax.arch.suse.de:/olaf_xenimage=
s/bug6
94863/nfsroot console=3DttyS0,115200 quiet log_buf_len=3D64M memblock=3Ddeb=
ug ignore_
loglevel debug
   [Linux-bzImage, setup=3D0x3c00, size=3D0x3a31b0]
initrd /initrd-3.0.51-0.7.9-default
   [Linux-initrd @ 0x1f2d0000, 0x51f161 bytes]

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.0.51-0.7.9-default (geeko@buildhost) (gcc ve=
rsion 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov =
29 22:12:17 UTC 2012 (f3be9d0)
[    0.000000] Command line: root=3Dbax.arch.suse.de:/olaf_xenimages/bug694=
863/nfsroot console=3DttyS0,115200 quiet log_buf_len=3D64M memblock=3Ddebug=
 ignore_loglevel debug
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000001f800000 (usable)
[    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.3.26502-20130204 02/04/2013
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usab=
le) =3D=3D> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usab=
le)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn =3D 0x1f800 max_arch_pfn =3D 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 00F0000000 mask FFF8000000 uncachable
[    0.000000]   1 base 00F8000000 mask FFFC000000 uncachable
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x701060007=
0106
[    0.000000] found SMP MP-table at [ffff8800000fbba0] fbba0
[    0.000000]     memblock_x86_reserve_range: [0x000fbba0-0x000fbbaf]   * =
MP-table mpf
[    0.000000]     memblock_x86_reserve_range: [0x000fbbb0-0x000fbc93]   * =
MP-table mpc
[    0.000000]     memblock_x86_reserve_range: [0x01fd7000-0x01fd70d7]     =
         BRK
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size =3D 0x1f78e000
[    0.000000]  memory.cnt  =3D 0x2
[    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009dfff], 0x8e000 by=
tes
[    0.000000]  memory[0x1]	[0x00000000100000-0x0000001f7fffff], 0x1f700000=
 bytes
[    0.000000]  reserved.cnt  =3D 0x3
[    0.000000]  reserved[0x0]	[0x0000000009e000-0x000000000fffff], 0x62000 =
bytes
[    0.000000]  reserved[0x1]	[0x00000001000000-0x00000001fd70d7], 0xfd70d8=
 bytes
[    0.000000]  reserved[0x2]	[0x0000001f2d0000-0x0000001f7effff], 0x520000=
 bytes
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000]     memblock_x86_reserve_range: [0x00099000-0x0009dfff]     =
  TRAMPOLINE
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480
[    0.000000] init_memory_mapping: 0000000000000000-000000001f800000
[    0.000000]  0000000000 - 001f800000 page 2M
[    0.000000] kernel direct mapping tables up to 0x1f7fffff @ [mem 0x1f7fe=
000-0x1f7fffff]
[    0.000000] log_buf_len: 67108864
[    0.000000] early log buf free: 258723(98%)
[    0.000000] RAMDISK: 1f2d0000 - 1f7f0000
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc00f5c0 00054 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00f280 000F4 (v04    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc003600 0BBF6 (v02    Xen      HVM 00000=
000 INTL 20081031)
[    0.000000] ACPI: FACS 00000000fc0035c0 00040
[    0.000000] ACPI: APIC 00000000fc00f380 000D8 (v02    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc00f4d0 00038 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc00f510 00028 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc00f540 00031 (v02    Xen      HVM 00000=
000 INTL 20081031)
[    0.000000] ACPI: SSDT 00000000fc00f580 00031 (v02    Xen      HVM 00000=
000 INTL 20081031)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000001f800000
[    0.000000] Initmem setup node 0 0000000000000000-000000001f800000
[    0.000000]     memblock_x86_reserve_range: [0x1b2a9000-0x1b2cffff]     =
   NODE_DATA
[    0.000000]   NODE_DATA [000000001b2a9000 - 000000001b2cffff]
[    0.000000]     memblock_x86_reserve_range: [0x1f7ff000-0x1f7fffff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1aea9000-0x1b2a8fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fef80-0x1f7fefdf]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1aaa9000-0x1aea8fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1a200000-0x1a9fffff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fd000-0x1f7fdfff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fc000-0x1f7fcfff]     =
     BOOTMEM
[    0.000000]  [ffffea0000000000-ffffea00007fffff] PMD -> [ffff88001a20000=
0-ffff88001a9fffff] on node 0
[    0.000000]        memblock_x86_free_range: [0x1aaa9000-0x1aea8fff]
[    0.000000]        memblock_x86_free_range: [0x1aea9000-0x1b2a8fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x0001f800
[    0.000000] On node 0 totalpages: 128910
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 5 pages reserved
[    0.000000]   DMA zone: 3921 pages, LIFO batch:0
[    0.000000]     memblock_x86_reserve_range: [0x1b291000-0x1b2a8fff]     =
     BOOTMEM
[    0.000000]   DMA32 zone: 1708 pages used for memmap
[    0.000000]   DMA32 zone: 123220 pages, LIFO batch:31
[    0.000000]     memblock_x86_reserve_range: [0x1b279000-0x1b290fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fb000-0x1f7fbfff]     =
     BOOTMEM
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-=
47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000]     memblock_x86_reserve_range: [0x1f7fef00-0x1f7fef40]     =
     BOOTMEM
[    0.000000] SMP: Allowing 15 CPUs, 13 hotplug CPUs
[    0.000000]     memblock_x86_reserve_range: [0x1f7fee80-0x1f7feec2]     =
     BOOTMEM
[    0.000000] nr_irqs_gsi: 64
[    0.000000]     memblock_x86_reserve_range: [0x1f7fed00-0x1f7fee4f]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fec80-0x1f7fece7]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fec00-0x1f7fec67]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7feb80-0x1f7febe7]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7feb00-0x1f7feb67]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fea80-0x1f7feae7]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fea00-0x1f7fea1f]     =
     BOOTMEM
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000=
a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000=
e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 00000000001=
00000
[    0.000000] Allocating PCI resources starting at 1f800000 (gap: 1f800000=
:dc800000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe900-0x1f7fe987]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe800-0x1f7fe887]     =
     BOOTMEM
[    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:15 nr_cpu_ids:15 =
nr_node_ids:1
[    0.000000]     memblock_x86_reserve_range: [0x1f7fa000-0x1f7fafff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7f9000-0x1f7f9fff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1b000000-0x1b1fffff]     =
     BOOTMEM
[    0.000000]        memblock_x86_free_range: [0x1b019000-0x1b01ffff]
[    0.000000]        memblock_x86_free_range: [0x1b039000-0x1b03ffff]
[    0.000000]        memblock_x86_free_range: [0x1b059000-0x1b05ffff]
[    0.000000]        memblock_x86_free_range: [0x1b079000-0x1b07ffff]
[    0.000000]        memblock_x86_free_range: [0x1b099000-0x1b09ffff]
[    0.000000]        memblock_x86_free_range: [0x1b0b9000-0x1b0bffff]
[    0.000000]        memblock_x86_free_range: [0x1b0d9000-0x1b0dffff]
[    0.000000]        memblock_x86_free_range: [0x1b0f9000-0x1b0fffff]
[    0.000000]        memblock_x86_free_range: [0x1b119000-0x1b11ffff]
[    0.000000]        memblock_x86_free_range: [0x1b139000-0x1b13ffff]
[    0.000000]        memblock_x86_free_range: [0x1b159000-0x1b15ffff]
[    0.000000]        memblock_x86_free_range: [0x1b179000-0x1b17ffff]
[    0.000000]        memblock_x86_free_range: [0x1b199000-0x1b19ffff]
[    0.000000]        memblock_x86_free_range: [0x1b1b9000-0x1b1bffff]
[    0.000000]        memblock_x86_free_range: [0x1b1d9000-0x1b1dffff]
[    0.000000]        memblock_x86_free_range: [0x1b1e0000-0x1b1fffff]
[    0.000000] PERCPU: Embedded 25 pages/cpu @ffff88001b000000 s73728 r8192=
 d20480 u131072
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe780-0x1f7fe787]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe700-0x1f7fe707]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe680-0x1f7fe6bb]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe600-0x1f7fe677]     =
     BOOTMEM
[    0.000000] pcpu-alloc: s73728 r8192 d20480 u131072 alloc=3D1*2097152
[    0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14=
 --=20
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe480-0x1f7fe58f]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe400-0x1f7fe447]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe380-0x1f7fe3c7]     =
     BOOTMEM
[    0.000000]        memblock_x86_free_range: [0x1f7fa000-0x1f7fafff]
[    0.000000]        memblock_x86_free_range: [0x1f7f9000-0x1f7f9fff]
[    0.000000]     memblock_x86_reserve_range: [0x1f7fe180-0x1f7fe37f]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fae00-0x1f7fafff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fac00-0x1f7fadff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7faa00-0x1f7fabff]     =
     BOOTMEM
[    0.000000]     memblock_x86_reserve_range: [0x1f7fa800-0x1f7fa9ff]     =
     BOOTMEM
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Tota=
l pages: 127141
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: root=3Dbax.arch.suse.de:/olaf_xenimages=
/bug694863/nfsroot console=3DttyS0,115200 quiet log_buf_len=3D64M memblock=
=3Ddebug ignore_loglevel debug
[    0.000000]     memblock_x86_reserve_range: [0x1f7f6800-0x1f7fa7ff]     =
     BOOTMEM
[    0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Subtract (40 early reservations)
[    0.000000]   [0000099000-00000fffff]
[    0.000000]   [0001000000-0001fd70d7]
[    0.000000]   [001a200000-001a9fffff]
[    0.000000]   [001b000000-001b018fff]
[    0.000000]   [001b020000-001b038fff]
[    0.000000]   [001b040000-001b058fff]
[    0.000000]   [001b060000-001b078fff]
[    0.000000]   [001b080000-001b098fff]
[    0.000000]   [001b0a0000-001b0b8fff]
[    0.000000]   [001b0c0000-001b0d8fff]
[    0.000000]   [001b0e0000-001b0f8fff]
[    0.000000]   [001b100000-001b118fff]
[    0.000000]   [001b120000-001b138fff]
[    0.000000]   [001b140000-001b158fff]
[    0.000000]   [001b160000-001b178fff]
[    0.000000]   [001b180000-001b198fff]
[    0.000000]   [001b1a0000-001b1b8fff]
[    0.000000]   [001b1c0000-001b1d8fff]
[    0.000000]   [001b279000-001f7effff]
[    0.000000]   [001f7f6800-001f7fdfff]
[    0.000000]   [001f7fe180-001f7fe3c7]
[    0.000000]   [001f7fe400-001f7fe447]
[    0.000000]   [001f7fe480-001f7fe58f]
[    0.000000]   [001f7fe600-001f7fe677]
[    0.000000]   [001f7fe680-001f7fe6bb]
[    0.000000]   [001f7fe700-001f7fe707]
[    0.000000]   [001f7fe780-001f7fe787]
[    0.000000]   [001f7fe800-001f7fe887]
[    0.000000]   [001f7fe900-001f7fe987]
[    0.000000]   [001f7fea00-001f7fea1f]
[    0.000000]   [001f7fea80-001f7feae7]
[    0.000000]   [001f7feb00-001f7feb67]
[    0.000000]   [001f7feb80-001f7febe7]
[    0.000000]   [001f7fec00-001f7fec67]
[    0.000000]   [001f7fec80-001f7fece7]
[    0.000000]   [001f7fed00-001f7fee4f]
[    0.000000]   [001f7fee80-001f7feec2]
[    0.000000]   [001f7fef00-001f7fef40]
[    0.000000]   [001f7fef80-001f7fefdf]
[    0.000000]   [001f7ff000-001f7fffff]
[    0.000000] Memory: 418532k/516096k available (4417k kernel code, 456k a=
bsent, 97108k reserved, 7677k data, 1344k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS:262400 nr_irqs:1208 16
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] allocated 4194304 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=3Dmemory' option if you don't wan=
t memory cgroups
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2926.355 MHz processor.
[    0.028005] Calibrating delay loop (skipped), value calculated using tim=
er frequency.. 5852.71 BogoMIPS (lpj=3D11705420)
[    0.033089] pid_max: default: 32768 minimum: 301
[    0.036182] kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI=
, All Rights Reserved
kdb_cmd[0]: defcmd archkdb "" "First line arch debugging"
kdb_cmd[8]: defcmd archkdbcpu "" "archkdb with only tasks on cpus"
kdb_cmd[15]: defcmd archkdbshort "" "archkdb with less detailed backtrace"
kdb_cmd[22]: defcmd archkdbcommon "" "Common arch debugging"
[    0.048129] Security Framework initialized
[    0.049749] AppArmor: AppArmor initialized
[    0.051423] Dentry cache hash table entries: 65536 (order: 7, 524288 byt=
es)
[    0.052102] Inode-cache hash table entries: 32768 (order: 6, 262144 byte=
s)
[    0.056067] Mount-cache hash table entries: 256
[    0.057957] Initializing cgroup subsys cpuacct
[    0.060008] Initializing cgroup subsys memory
[    0.061784] Initializing cgroup subsys devices
[    0.064006] Initializing cgroup subsys freezer
[    0.065753] Initializing cgroup subsys net_cls
[    0.068006] Initializing cgroup subsys blkio
[    0.070741] Initializing cgroup subsys perf_event
[    0.072077] CPU: Physical Processor ID: 0
[    0.076007] CPU: Processor Core ID: 0
[    0.078267] mce: CPU supports 2 MCE banks
[    0.081797] ACPI: Core revision 20110413
[    0.091343] Enabling x2apic
[    0.092004] Enabled x2apic
[    0.092008] Switched APIC routing to physical x2apic.
[    0.100348] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D2 apic2=3D0 pin2=3D0
[    0.145426] CPU0: Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz steppi=
ng 02
[    0.152008] Performance Events: Westmere events, Intel PMU driver.
[    0.152008] ... version:                3
[    0.152008] ... bit width:              48
[    0.152010] ... generic registers:      4
[    0.153570] ... value mask:             0000ffffffffffff
[    0.156010] ... max period:             000000007fffffff
[    0.158051] ... fixed-purpose events:   3
[    0.159643] ... event mask:             000000070000000f
[    0.160132] NMI watchdog enabled, takes one hw-pmu counter.
[    0.164127] Booting Node   0, Processors  #1
[    0.165779] smpboot cpu 1: start_ip =3D 99000
[    0.196032] NMI watchdog enabled, takes one hw-pmu counter.
[    0.200056] Brought up 2 CPUs
[    0.201251] Total of 2 processors activated (11705.42 BogoMIPS).
[    0.204397] devtmpfs: initialized
[    0.211598] print_constraints: dummy:=20
[    0.212039] Time: 10:52:04  Date: 02/04/13
[    0.213745] NET: Registered protocol family 16
[    0.216120] ACPI: bus type pci registered
[    0.217923] PCI: Using configuration type 1 for base access
[    0.220315] bio: create slab <bio-0> at 0
[    0.224902] ACPI: EC: Look up EC in DSDT
[    0.230797] ACPI: Interpreter enabled
[    0.232018] ACPI: (supports S0 S3 S4 S5)
[    0.233770] ACPI: Using IOAPIC for interrupt routing
[    0.313797] ACPI: No dock devices found.
[    0.316027] PCI: Using host bridge windows from ACPI; if necessary, use =
"pci=3Dnocrs" and report a bug
[    0.320130] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.324232] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.328028] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.332026] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x00=
0bffff]
[    0.336023] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfb=
ffffff]
[    0.340113] pci 0000:00:00.0: [8086:1237] type 0 class 0x000600
[    0.344800] pci 0000:00:01.0: [8086:7000] type 0 class 0x000601
[    0.349185] pci 0000:00:01.1: [8086:7010] type 0 class 0x000101
[    0.352478] pci 0000:00:01.1: reg 20: [io  0xc100-0xc10f]
[    0.355093] pci 0000:00:01.3: [8086:7113] type 0 class 0x000680
[    0.356049] * Found PM-Timer Bug on the chipset. Due to workarounds for =
a bug,
[    0.356050] * this clock source is slow. Consider trying other clock sou=
rces
[    0.361012] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX=
4 ACPI
[    0.364417] pci 0000:00:02.0: [1013:00b8] type 0 class 0x000300
[    0.368201] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.372112] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff]
[    0.375255] pci 0000:00:03.0: [5853:0001] type 0 class 0x00ff80
[    0.376244] pci 0000:00:03.0: reg 10: [io  0xc000-0xc0ff]
[    0.378436] pci 0000:00:03.0: reg 14: [mem 0xf2000000-0xf2ffffff pref]
[    0.381439] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.384392]  pci0000:00: Unable to request _OSC control (_OSC support ma=
sk: 0x1e)
[    0.493508] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    0.497291] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.501286] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.508512] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    0.513339] vgaarb: device added: PCI:0000:00:02.0,decodes=3Dio+mem,owns=
=3Dio+mem,locks=3Dnone
[    0.520035] vgaarb: loaded
[    0.522143] PCI: Using ACPI for IRQ routing
[    0.524036] PCI: pci_cache_line_size set to 64 bytes
[    0.528336] reserve RAM buffer: 000000000009e000 - 000000000009ffff=20
[    0.532036] reserve RAM buffer: 000000001f800000 - 000000001fffffff=20
[    0.536101] NetLabel: Initializing
[    0.540036] NetLabel:  domain hash size =3D 128
[    0.544036] NetLabel:  protocols =3D UNLABELED CIPSOv4
[    0.547635] NetLabel:  unlabeled traffic allowed by default
[    0.548049] HPET: 3 timers in total, 0 timers will be used for per-cpu t=
imer
[    0.556049] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.560151] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.572058] Switching to clocksource hpet
[    0.575022] Switched to NOHz mode on CPU #0
[    0.575003] Switched to NOHz mode on CPU #1
[    0.579544] AppArmor: AppArmor Filesystem Enabled
[    0.583390] pnp: PnP ACPI init
[    0.585982] ACPI: bus type pnp registered
[    0.589261] pnp 00:00: [mem 0x00000000-0x0009ffff]
[    0.593273] system 00:00: [mem 0x00000000-0x0009ffff] could not be reser=
ved
[    0.598588] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.603299] pnp 00:01: [bus 00-ff]
[    0.605767] pnp 00:01: [io  0x0cf8-0x0cff]
[    0.608802] pnp 00:01: [io  0x0000-0x0cf7 window]
[    0.612193] pnp 00:01: [io  0x0d00-0xffff window]
[    0.615471] pnp 00:01: [mem 0x000a0000-0x000bffff window]
[    0.619318] pnp 00:01: [mem 0xf0000000-0xfbffffff window]
[    0.623415] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.628200] pnp 00:02: [mem 0xfed00000-0xfed003ff]
[    0.631598] pnp 00:02: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.636397] pnp 00:03: [io  0x0010-0x001f]
[    0.639399] pnp 00:03: [io  0x0022-0x002d]
[    0.642425] pnp 00:03: [io  0x0030-0x003f]
[    0.645360] pnp 00:03: [io  0x0044-0x005f]
[    0.648445] pnp 00:03: [io  0x0062-0x0063]
[    0.651382] pnp 00:03: [io  0x0065-0x006f]
[    0.654279] pnp 00:03: [io  0x0072-0x007f]
[    0.657262] pnp 00:03: [io  0x0080]
[    0.659817] pnp 00:03: [io  0x0084-0x0086]
[    0.662839] pnp 00:03: [io  0x0088]
[    0.665326] pnp 00:03: [io  0x008c-0x008e]
[    0.668324] pnp 00:03: [io  0x0090-0x009f]
[    0.671440] pnp 00:03: [io  0x00a2-0x00bd]
[    0.674437] pnp 00:03: [io  0x00e0-0x00ef]
[    0.677481] pnp 00:03: [io  0x08a0-0x08a3]
[    0.680360] pnp 00:03: [io  0x0cc0-0x0ccf]
[    0.683428] pnp 00:03: [io  0x04d0-0x04d1]
[    0.686415] system 00:03: [io  0x08a0-0x08a3] has been reserved
[    0.690682] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
[    0.695000] system 00:03: [io  0x04d0-0x04d1] has been reserved
[    0.699255] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.704056] pnp 00:04: [dma 4]
[    0.706190] pnp 00:04: [io  0x0000-0x000f]
[    0.709135] pnp 00:04: [io  0x0081-0x0083]
[    0.712181] pnp 00:04: [io  0x0087]
[    0.714566] pnp 00:04: [io  0x0089-0x008b]
[    0.717543] pnp 00:04: [io  0x008f]
[    0.719963] pnp 00:04: [io  0x00c0-0x00df]
[    0.722868] pnp 00:04: [io  0x0480-0x048f]
[    0.725885] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.730652] pnp 00:05: [io  0x0070-0x0071]
[    0.733749] pnp 00:05: [irq 8]
[    0.735989] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.740760] pnp 00:06: [io  0x0061]
[    0.743302] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.747811] pnp 00:07: [irq 12]
[    0.750141] pnp 00:07: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.754947] pnp 00:08: [io  0x0060]
[    0.757546] pnp 00:08: [io  0x0064]
[    0.760097] pnp 00:08: [irq 1]
[    0.762356] pnp 00:08: Plug and Play ACPI device, IDs PNP0303 PNP030b (a=
ctive)
[    0.767695] pnp 00:09: [io  0x03f0-0x03f5]
[    0.770636] pnp 00:09: [io  0x03f7]
[    0.773235] pnp 00:09: [irq 6]
[    0.775362] pnp 00:09: [dma 2]
[    0.777604] pnp 00:09: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.782481] pnp 00:0a: [io  0x03f8-0x03ff]
[    0.785253] pnp 00:0a: [irq 4]
[    0.787390] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.792005] pnp 00:0b: [io  0x0378-0x037f]
[    0.795054] pnp 00:0b: [irq 7]
[    0.797294] pnp 00:0b: Plug and Play ACPI device, IDs PNP0400 (active)
[    0.802236] pnp 00:0c: [io  0x10c0-0x1141]
[    0.805220] pnp 00:0c: [io  0xb044-0xb047]
[    0.808173] system 00:0c: [io  0x10c0-0x1141] has been reserved
[    0.812455] system 00:0c: [io  0xb044-0xb047] has been reserved
[    0.816704] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.836518] pnp: PnP ACPI: found 13 devices
[    0.838142] ACPI: ACPI bus type pnp unregistered
[    0.845336] PCI: max bus depth: 0 pci_try_num: 1
[    0.847076] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.849146] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.851128] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.853620] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff]
[    0.856190] NET: Registered protocol family 2
[    0.857949] IP route cache hash table entries: 4096 (order: 3, 32768 byt=
es)
[    0.860920] TCP established hash table entries: 16384 (order: 6, 262144 =
bytes)
[    0.863704] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.866176] TCP: Hash tables configured (established 16384 bind 16384)
[    0.868589] TCP reno registered
[    0.869758] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.871901] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.874372] NET: Registered protocol family 1
[    0.876069] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.878260] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.880496] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.882834] pci 0000:00:02.0: Boot video device
[    0.884683] PCI: CLS 0 bytes, default 64
[    0.886148] Unpacking initramfs...
[    0.976604] Freeing initrd memory: 5248k freed
[    0.980429] audit: initializing netlink socket (disabled)
[    0.983042] type=3D2000 audit(1359975123.980:1): initialized
[    1.004701] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.008589] VFS: Disk quotas dquot_6.5.2
[    1.010529] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.013798] msgmni has been set to 206
[    1.015783] alg: No test for stdrng (krng)
[    1.017861] Block layer SCSI generic (bsg) driver version 0.4 loaded (ma=
jor 253)
[    1.021554] io scheduler noop registered
[    1.023499] io scheduler deadline registered
[    1.025676] io scheduler cfq registered (default)
[    1.028165] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    1.031894] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    1.081698] 00:0a: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    1.086755] Non-volatile memory driver v1.3
[    1.090225] Linux agpgart interface v0.103
[    1.093645] Fixed MDIO Bus: probed
[    1.096245] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0=
x60,0x64 irq 1,12
[    1.101847] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.103763] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.105793] mousedev: PS/2 mouse device common for all mice
[    1.108472] input: AT Translated Set 2 keyboard as /devices/platform/i80=
42/serio0/input/input0
[    1.112125] cpuidle: using governor ladder
[    1.115129] cpuidle: using governor menu
[    1.118082] EFI Variables Facility v0.08 2004-May-17
[    1.121893] TCP cubic registered
[    1.124323] Registering the dns_resolver key type
[    1.127000] PM: Hibernation image not present or could not be loaded.
[    1.130046] registered taskstats version 1
[    1.132335]   Magic number: 1:672:880
[    1.136317] Freeing unused kernel memory: 1344k freed
[    1.138955] Write protecting the kernel read-only data: 10240k
[    1.145263] Freeing unused kernel memory: 1708k freed
[    1.150105] Freeing unused kernel memory: 1008k freed
doing fast boot
[    1.188853] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level, l=
ow) -> IRQ 28
[    1.193124] Xen version 4.3.
[    1.195541] Hypercall area is 1 pages.
[    1.198665] xen-platform-pci 0000:00:03.0: I/O protocol version 1
[    1.207973] suspend: event channel 6
[    1.208560] Unable to read sysrq code in control/sysrq
[    1.221813] xen-vbd: registered block device major 3
[    1.223998] blkfront: hda: barrier or flush: disabled
[    1.228565] SCSI subsystem initialized
[    1.230818]  hda: hda1 hda2
[    1.234705] libata version 3.00 loaded.
[    1.239483] ata_piix 0000:00:01.1: version 2.13
[    1.241440] ata_piix 0000:00:01.1: setting latency timer to 64
[    1.244067] scsi0 : ata_piix
[    1.245700] scsi1 : ata_piix
[    1.247085] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc100 irq 14
[    1.250205] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc108 irq 15
[    1.410471] ata1.01: NODEV after polling detection
[    1.416170] ata1.00: ATA-7: QEMU HARDDISK, 0.10.2, max UDMA/100
[    1.418989] ata1.00: 2097152 sectors, multi 16: LBA48=20
[    1.422384] ata1.00: configured for MWDMA2
[    1.424433] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    0.=
10 PQ: 0 ANSI: 5
[    1.435008] xen_mem: Initialising balloon driver.
[    1.450694] netfront: Initialising virtual ethernet driver.
preping 03-scsi_dh.sh
running 03-scsi_dh.sh
[    1.461201] alua: device handler registered
[    1.467600] rdac: device handler registered
[    1.474392] emc: device handler registered
[    1.482510] hp_sw: device handler registered
preping 03-storage.sh
running 03-storage.sh
preping 04-udev.sh
running 04-udev.sh
Creating device nodes with udev
[    1.495392] udev: starting version 147
[    1.518783] ACPI: acpi_idle registered with cpuidle
ata_id[269]: HDIO_GET_IDENTITY failed for '/dev/.tmp-block-3:0'

[    1.544774] sd 0:0:0:0: [sda] 2097152 512-byte logical blocks: (1.07 GB/=
1.00 GiB)
[    1.547753] sd 0:0:0:0: [sda] Write Protect is off
[    1.549620] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.551543] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled=
, doesn't support DPO or FUA
[    1.560158]  sda: sda1 sda2
[    1.561440] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.763078] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/=
i8042/serio1/input/input1
[    2.004223] Refined TSC clocksource calibration: 2926.331 MHz.
[    2.009973] Switching to clocksource tsc
preping 05-blogd.sh
running 05-blogd.sh
mount: devpts already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts
Boot logging started on /dev/ttyS0(/dev/console) at Mon Feb  4 11:52:05 2013
preping 05-clock.sh
running 05-clock.sh
preping 12-network.sh
running 12-network.sh
[    2.270768] NET: Registered protocol family 17
running dhcpcd on interface eth0
err, eth0: Failed to lookup hostname via DNS: Temporary failure in name res=
olution
preping 21-devinit_done.sh
running 21-devinit_done.sh
preping 21-nfs.sh
running 21-nfs.sh
[   14.340515] RPC: Registered named UNIX socket transport module.
[   14.344694] RPC: Registered udp transport module.
[   14.347892] RPC: Registered tcp transport module.
[   14.351057] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   14.357560] FS-Cache: Loaded
[   14.364398] FS-Cache: Netfs 'nfs' registered for caching
preping 81-mount.sh
running 81-mount.sh
device node not found
Mounting root bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot
mount -o rw,nolock -t nfs bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroo=
t /root
preping 82-remount.sh
running 82-remount.sh
preping 91-createfb.sh
running 91-createfb.sh
preping 91-killblogd.sh
running 91-killblogd.sh
preping 91-killudev.sh
running 91-killudev.sh
preping 91-shell.sh
running 91-shell.sh
preping 92-killblogd2.sh
running 92-killblogd2.sh
preping 93-boot.sh
running 93-boot.sh
INIT: version 2.86 booting
System Boot Control: Running /etc/init.d/boot
Mounting sysfs at /sys=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=
=1B[?25h
Copying static /dev content=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=
=1B8=1B[?25h
Mounting devpts at /dev/pts=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=
=1B8=1B[?25h
Boot logging started on /dev/ttyS0(/dev/console) at Mon Feb  4 11:52:18 2013
Mounting debugfs at /sys/kernel/debug=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdon=
e=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting udevd: [   15.759402] udev: starting version 147
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
Loading drivers, configuring devices: [   16.043511] piix4_smbus 0000:00:01=
=2E3: SMBus base address uninitialized - upgrade BIOS or use force_addr=3D0=
xaddr
[   16.054379] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/inpu=
t/input2
[   16.058842] ACPI: Power Button [PWRF]
[   16.061519] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/inpu=
t/input3
[   16.065478] ACPI: Sleep Button [SLPF]
[   16.068700] input: PC Speaker as /devices/platform/pcspkr/input/input4
[   16.103431] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   16.114015] FDC 0 is a S82078B
ata_id[492]: HDIO_GET_IDENTITY failed for '/dev/hda'

[   16.138550] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[   16.143169] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs
[   16.156472] parport_pc 00:0b: reported by Plug and Play ACPI
[   16.161408] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[   16.392954] ppdev: user-space parallel port driver
[   16.513197] NET: Registered protocol family 10
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hActivating swap-devices in /etc/fstab...
[   17.013265] Adding 331772k swap on /dev/hda2.  Priority:-1 extents:1 acr=
oss:331772k SS
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hSet System Time to the current Hardware Clock=1B7=1B[?25l=1B[80C=1B=
[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hActivating device mapper...
[   18.168178] device-mapper: uevent: version 1.0.3
[   18.170617] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised:=
 dm-devel@redhat.com
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hLoading required kernel modules
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hStarting MD RAID =1B[80C=1B[10D=1B[1munused=1B[m=0F
=1B[m=0F=1B[?25hChecking file systems...
fsck from util-linux 2.19.1
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/hda1=20
BOOT: clean, 64/44736 files, 22702/178944 blocks
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hMounting l=
ocal file systems...
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
[   19.404458] loop: module loaded
udev on /dev type tmpfs (rw,mode=3D0755)
tmpfs on /dev/shm type tmpfs (rw,mode=3D1777)
devpts on /dev/pts type devpts (rw,mode=3D0620,gid=3D5)
[   20.109015] kjournald starting.  Commit interval 15 seconds
[   20.111889] EXT3-fs (hda1): mounted filesystem with ordered data mode
/dev/hda1 on /boot type ext3 (ro,noatime,acl,user_xattr)
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hCheck if the profiles matches the system=1B7=1B[?25l=1B[80C=1B[10D=
=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hCreating /var/log/boot.msg
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hEnabling monitoring on LVM volume groups...
  No volume groups found
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hActivating remaining swap-devices in /etc/f=
stab...
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hSetting up hostname 'hammer185'=1B7=
=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
Setting up NIS domainname 'suse.de'=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
Setting up loopback interface     lo       =20
    lo        IP address: 127.0.0.1/8  =20
              IP address: 127.0.0.2/8  =20
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hSetting current sysctl status from /etc/sysctl.conf=1B7=1B[=
?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hEnabling syn flood protection=1B[80C=1B[10D=1B[1;32mdone=1B=
[m=0F
Disabling IP forwarding=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=
=1B[?25h
Disabling IPv6 forwarding=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B=
8=1B[?25h
Disabling IPv6 privacy=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=
=1B[?25h
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hSystem Boot Control: The system has been =1B[80C=1B[10D=1B[=
1mset up=1B[m=0F
Skipped features: =1B[80C=1B[14D=1B[1;33mboot.md=1B[m=0F
System Boot Control: Running /etc/init.d/boot.local
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hINIT: Ente=
ring runlevel: 3
Master Resource Control: previous runlevel: N, switching to runlevel: =1B[8=
0C=1B[10D=1B[1m3=1B[m=0F
Starting D-Bus daemon=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B=
[?25h
=1B[m=0F=1B[?25hStarting syslog services=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32m=
done=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h[   27.424084] eth0: no IPv=
6 routers present
Initializing random number generator=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hLoading CPUFreq modules (CPUFreq not supported)
Starting HAL daemon=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?=
25h
=1B[m=0F=1B[?25hSetting up (localfs) network interfaces:
    lo       =20
    lo        IP address: 127.0.0.1/8  =20
              IP address: 127.0.0.2/8  =20
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h    eth0  =
    name: Virtual Ethernet Card 0
    eth0      Starting DHCP4 client. =20
    eth0      IP address: 10.11.3.133/17
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hSetting up=
 service (localfs) network  .  .  .  .  .  .  .  .  .  .=1B7=1B[?25l=1B[80C=
=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hStarting auditd [   41.455249] auditd (2107=
): /proc/2107/oom_adj is deprecated, please use /proc/2107/oom_score_adj in=
stead.
=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting haveged daemon =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32m=
done=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting rpcbind =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B=
[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hStarting NFS client services: sm-notify idm=
apd=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hLoading console font lat9w-16.psfu  -m trivial G0:loadable
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hLoading ke=
ymap assuming iso-8859-15 euro
Loading /usr/share/kbd/keymaps/i386/qwerty/us.map.gz
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h[   45.803=
412] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Loading compose table latin1.add=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[=
m=0F=1B8=1B[?25h
Start Unicode mode
=1B7=1B[?25l=1B[1A=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B[m=0F=
=1B[?25hStarting irqbalance =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=
=1B8=1B[?25h
=1B[m=0F=1B[?25hSetting up (remotefs) network interfaces:
Setting up service (remotefs) network  .  .  .  .  .  .  .  .  .  .=1B7=1B[=
?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hStarting SSH daemon=1B7=1B[?25l=1B[80C=1B[1=
0D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting ypbind=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=1B[m=
=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting network time protocol daemon (NTPD)=1B7=1B[?25l=1B=
[80C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting automount =1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting mail service (Postfix)=1B7=1B[?25l=1B[80C=1B[10D=
=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hStarting CRON daemon=1B7=1B[?25l=1B[80C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hMaster Resource Control: runlevel 3 has been =1B[80C=1B[10D=
=1B[1mreached=1B[m=0F
Skipped services in runlevel 3: =1B[80C=1B[13D=1B[1;33msplash=1B[m=0F


Welcome to SUSE Linux Enterprise Server 11 SP2  (x86_64) - Kernel 3.0.51-0.=
7.9-default (console).


hammer133 login: root
Password: [   60.101248] hpet1: lost 2200 rtc interrupts

Last login: Mon Feb  4 11:35:54 CET 2013 on console
[   62.390313] hpet1: lost 2201 rtc interrupts
root@hammer133:~ # [   64.679349] hpet1: lost 2200 rtc interrupts
=1B[3@(reverse-i-search)`':=1B[C=08=08=08e': init 0 ; exit=08=08=08=08=08=
=08=08=08=08=08=08=08=08=08=08=08v': eval `initviocons -e`=08=08=08=08=08=
=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=08=1B[1@a=1B[C=1B[C=
=1B[C=1B[6Proot@hammer133:~ #=1B[C
=1B[?25lProbing connected terminal...
=1B[c=1B7=1B[r=1B[999;999H=1B[6n=1B8=1B[>c
Initializing virtual console...
=1B[3g        =1BH        =1BH        =1BH        =1BH        =1BH        =
=1BH        =1BH        =1BH        =1BH[   66.968419] hpet1: lost 2201 rtc=
 interrupts
=1B[?25h
Found a screen terminal on /dev/console (263 columns x 62 lines).
Use the 'initviocons' command whenever the terminal has been resized.
root@hammer133:~ # [   69.257490] hpet1: lost 2200 rtc interrupts
[   71.546573] hpet1: lost 2201 rtc interrupts
[   73.835597] hpet1: lost 2201 rtc interrupts
[   76.123698] hpet1: lost 2201 rtc interrupts
[   78.412737] hpet1: lost 2200 rtc interrupts
[   80.701810] hpet1: lost 2201 rtc interrupts
[   82.990880] hpet1: lost 2201 rtc interrupts
[   85.278972] hpet1: lost 2201 rtc interrupts
[   87.568047] hpet1: lost 2201 rtc interrupts
[   89.857068] hpet1: lost 2200 rtc interrupts
[   92.146157] hpet1: lost 2201 rtc interrupts
[   94.435227] hpet1: lost 2201 rtc interrupts
[   96.723293] hpet1: lost 2201 rtc interrupts
[   99.012363] hpet1: lost 2201 rtc interrupts
[  101.300457] hpet1: lost 2201 rtc interrupts
[  103.589519] hpet1: lost 2201 rtc interrupts
[  105.877589] hpet1: lost 2201 rtc interrupts
[  108.166658] hpet1: lost 2201 rtc interrupts
[  110.454751] hpet1: lost 2201 rtc interrupts
[  112.743795] hpet1: lost 2200 rtc interrupts
[  115.032870] hpet1: lost 2201 rtc interrupts
[  117.321940] hpet1: lost 2201 rtc interrupts
[  119.610033] hpet1: lost 2201 rtc interrupts
[  121.899078] hpet1: lost 2201 rtc interrupts
[  124.187170] hpet1: lost 2201 rtc interrupts
[  126.476240] hpet1: lost 2201 rtc interrupts
[  128.764306] hpet1: lost 2202 rtc interrupts
[  131.052403] hpet1: lost 2201 rtc interrupts
[  133.340490] hpet1: lost 2201 rtc interrupts
[  135.629556] hpet1: lost 2201 rtc interrupts
[  137.917630] hpet1: lost 2201 rtc interrupts
[  140.206695] hpet1: lost 2201 rtc interrupts
[  142.495770] hpet1: lost 2200 rtc interrupts
INIT: Switching to runlevel: 0
=07
Broadcast message from root (Mon Feb  4 11:54:28 2013):

The system is going down for system halt NOW!
INIT: Sending processes the TERM signal
[  144.784813] hpet1: lost 2201 rtc interrupts
[  147.073885] hpet1: lost 2201 rtc interrupts
INIT: Sending processes the KILL signal
[  149.361977] hpet1: lost 2201 rtc interrupts
Boot logging started on /dev/ttyS0((no tty)) at Mon Feb  4 11:54:34 2013
Master Resource Control: previous runlevel: 3, switching to runlevel: =1B[2=
63C=1B[10D=1B[1m0=1B[m=0F
Shutting down automount (force) [  151.651047] hpet1: lost 2201 rtc interru=
pts

=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down CRON daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;3=
2mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down irqbalance =1B7=1B[?25l=1B[263C=1B[10D=1B[1;3=
2mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hShutting do=
wn SSH daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down auditd =1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdo=
ne=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hShutting down haveged daemon =1B7=1B[?25l=
=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h/etc/init.d/rc3.d/K02kbd stop=1B7=1B[?25l=1B[263C=1B[10D=1B=
[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down network time protocol daemon (NTPD)[  153.939=
120] hpet1: lost 2201 rtc interrupts
=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down mail service (Postfix)=1B7=1B[?25l=1B[263C=1B=
[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h[  156.228184] hpet1: lost 2201 rtc interrupts
Shutting down (remotefs) network interfaces:
Shutting down service (remotefs) network  .  .  .  .  .  .  .  .  .=1B7=1B[=
?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hSaving random seed=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=
=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down ypbind=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdon=
e=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down HAL daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32=
mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down NFS client services: root filesystem is on NF=
S=1B[263C=1B[10D=1B[1;33mskipped=1B[m=0F
=1B[m=0F=1B[?25hShutting down rpcbind =1B7=1B[?25l=1B[263C=1B[10D=1B[1;32md=
one=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down syslog services[  158.516277] hpet1: lost 220=
1 rtc interrupts
=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25h=1B[m=0F=1B[?25hShutting down (localfs) network interfaces:
    eth0      name: Virtual Ethernet Card 0
    eth0      serves root filesystem. Leave it up.
=1B7=1B[?25l=1B[1A=1B[263C=1B[10D=1B[1;33mskipped=1B[m=0F=1B8=1B[?25h[  160=
=2E804384] hpet1: lost 2200 rtc interrupts
Shutting down service (localfs) network  .  .  .  .  .  .  .  .  .=1B7=1B[?=
25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hShutting down D-Bus daemon=1B7=1B[?25l=1B[263C=1B[10D=1B[1;=
32mdone=1B[m=0F=1B8=1B[?25h
=1B[m=0F=1B[?25hRunning /etc/init.d/halt.local
=1B7=1B[?25l=1B[1A=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h=1B7=1B[?=
25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
=1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
The System Time is in sync with Hardware Clock =1B[263C=1B[10D=1B[1;32mgood=
=1B[m=0F
Turning off swap files
Unmounting file systems
/dev/hda1 has been unmounted
=1B7=1B[?25l=1B[1A=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25hNot shutt=
ing down MD RAID - reboot/halt scripts do this.=1B7=1B[?25l=1B[263C=1B[10D=
=1B[1;31mmissing=1B[m=0F=1B8=1B[?25h
Stopping udevd: =1B7=1B[?25l=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F=1B8=1B[?25h
Sending all processes the TERM signal...
=1B[1A=1B[263C=1B[10D=1B[1;32mdone=1B[m=0F
[  163.094391] hpet1: lost 2201 rtc interrupts
[  165.383463] hpet1: lost 2201 rtc interrupts
Sending all processes the KILL signal...
The system will be halted immediately.
[  167.668005] hpet1: lost 2200 rtc interrupts
[  168.552334] sd 0:0:0:0: [sda] Stopping disk
[  168.619245] xen vkbd-0: xenbus_dev_shutdown: device/vkbd/0: Initialising=
 !=3D Connected, skipping
[  168.630166] ACPI: Preparing to enter system sleep state S5
[  168.634186] Disabling non-boot CPUs ...
[  168.638602] Broke affinity for irq 12
[  168.643277] Power down.
[  168.649135] acpi_power_off called

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

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

--cWoXeonUoKmBZSoM--


From xen-devel-bounces@lists.xen.org Mon Feb 04 14:07:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:07: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 1U2Mhb-0002Hi-Rh; Mon, 04 Feb 2013 14:07:19 +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 1U2Mha-0002HZ-7k
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:07:18 +0000
Received: from [85.158.137.99:16879] by server-1.bemta-3.messagelabs.com id
	AB/F2-08955-590CF015; Mon, 04 Feb 2013 14:07:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1359986812!19915531!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30871 invoked from network); 4 Feb 2013 14:06:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 14:06:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:06:51 +0000
Message-Id: <510FCE8902000078000BB83A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:06:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
In-Reply-To: <1359985517.7477.42.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, DavidVrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

>>> On 04.02.13 at 14:45, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
>> >> 
>> >> So this alone already is up to 16 pages per guest, and hence a
>> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
>> > 
>> > That's given a theoretical 32k guests? Ouch. It also ignores the need
>> > for other global mappings.
>> > 
>> > on the flip side only a minority of domains are likely to be using the
>> > extended scheme, and I expect even those which are would not be using
>> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
>> > evtchns.
>> > 
>> > Where does 16 come from? How many pages to we end up with at each level
>> > in the new scheme?
>> 
>> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
>> got two of them (pending and mask bits).
>> 
>> > Some levels of the trie are per-VCPU, did you account for that already
>> > in the 2GB?
>> 
>> No, I didn't, as it would only increase the number, and make
>> the math less clear.
>> 
>> >>  The
>> >> global page mapping area, however, is only 1Gb in size on x86-64
>> >> (didn't check ARM at all)...
>> > 
>> > There isn't currently a global page mapping area on 32-bit ARM (I
>> > suppose we have avoided them somehow...) but obviously 2G would be a
>> > problem in a 4GB address space.
>> > 
>> > On ARM we currently have 2G for domheap mappings which I suppose we
>> > would split if we needed a global page map
>> > 
>> > These need to be global so we can deliver evtchns to VCPUs which aren't
>> > running, right? I suppose mapping on demand (other than for a running
>> > VCPU) would be prohibitively expensive.
>> 
>> Likely, especially for high rate ones.
>> 
>> > Could we make this space per-VCPU (or per-domain) by saying that a
>> > domain maps its own evtchn pages plus the required pages from other
>> > domains with which an evtchn is bound? Might be tricky to arrange
>> > though, especially with the per-VCPU pages and affinity changes?
>> 
>> Even without that trickiness it wouldn't work I'm afraid: In various
>> cases we need to be able to raise the events out of context (timer,
>> IRQs from passed through devices).
>> 
>> Jan
> 
> So I come up with following comment on the 3-level registration
> interface (not specific to __map_l3_array() function).
> 
> /*
>  * Note to 3-level event channel users:
>  * Only enable 3-level event channel for Dom0 or driver domains, because
>  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
>  * area in Xen.
>  */

So you intended to fail the request for other guests? That's fine
with me in principle, but how do you tell a driver domain from an
"ordinary" one?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:07:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:07: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 1U2Mhb-0002Hi-Rh; Mon, 04 Feb 2013 14:07:19 +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 1U2Mha-0002HZ-7k
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:07:18 +0000
Received: from [85.158.137.99:16879] by server-1.bemta-3.messagelabs.com id
	AB/F2-08955-590CF015; Mon, 04 Feb 2013 14:07:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1359986812!19915531!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30871 invoked from network); 4 Feb 2013 14:06:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 14:06:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:06:51 +0000
Message-Id: <510FCE8902000078000BB83A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:06:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
In-Reply-To: <1359985517.7477.42.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, DavidVrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

>>> On 04.02.13 at 14:45, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
>> >> 
>> >> So this alone already is up to 16 pages per guest, and hence a
>> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
>> > 
>> > That's given a theoretical 32k guests? Ouch. It also ignores the need
>> > for other global mappings.
>> > 
>> > on the flip side only a minority of domains are likely to be using the
>> > extended scheme, and I expect even those which are would not be using
>> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
>> > evtchns.
>> > 
>> > Where does 16 come from? How many pages to we end up with at each level
>> > in the new scheme?
>> 
>> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
>> got two of them (pending and mask bits).
>> 
>> > Some levels of the trie are per-VCPU, did you account for that already
>> > in the 2GB?
>> 
>> No, I didn't, as it would only increase the number, and make
>> the math less clear.
>> 
>> >>  The
>> >> global page mapping area, however, is only 1Gb in size on x86-64
>> >> (didn't check ARM at all)...
>> > 
>> > There isn't currently a global page mapping area on 32-bit ARM (I
>> > suppose we have avoided them somehow...) but obviously 2G would be a
>> > problem in a 4GB address space.
>> > 
>> > On ARM we currently have 2G for domheap mappings which I suppose we
>> > would split if we needed a global page map
>> > 
>> > These need to be global so we can deliver evtchns to VCPUs which aren't
>> > running, right? I suppose mapping on demand (other than for a running
>> > VCPU) would be prohibitively expensive.
>> 
>> Likely, especially for high rate ones.
>> 
>> > Could we make this space per-VCPU (or per-domain) by saying that a
>> > domain maps its own evtchn pages plus the required pages from other
>> > domains with which an evtchn is bound? Might be tricky to arrange
>> > though, especially with the per-VCPU pages and affinity changes?
>> 
>> Even without that trickiness it wouldn't work I'm afraid: In various
>> cases we need to be able to raise the events out of context (timer,
>> IRQs from passed through devices).
>> 
>> Jan
> 
> So I come up with following comment on the 3-level registration
> interface (not specific to __map_l3_array() function).
> 
> /*
>  * Note to 3-level event channel users:
>  * Only enable 3-level event channel for Dom0 or driver domains, because
>  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
>  * area in Xen.
>  */

So you intended to fail the request for other guests? That's fine
with me in principle, but how do you tell a driver domain from an
"ordinary" one?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:14:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:14: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 1U2Mo1-0002U7-Nf; Mon, 04 Feb 2013 14:13: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 1U2Mo0-0002U2-Dg
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:13:56 +0000
Received: from [193.109.254.147:48810] by server-6.bemta-14.messagelabs.com id
	39/CD-12010-322CF015; Mon, 04 Feb 2013 14:13:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359987194!8503898!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10357 invoked from network); 4 Feb 2013 14:13:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 14:13:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:13:13 +0000
Message-Id: <510FD00602000078000BB84C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:13:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de> <20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
	<510F83AA02000078000BB64A@nat28.tlf.novell.com>
	<20130204094909.GA2564@aepfle.de> <20130204140312.GA14684@aepfle.de>
In-Reply-To: <20130204140312.GA14684@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 15:03, Olaf Hering <olaf@aepfle.de> wrote:
> [ sorry, had this reply open in another window and forgot to send it ]
> 
> On Mon, Feb 04, Olaf Hering wrote:
> 
>> I'm attaching the xen, dom0 and domU logs from a pvops kernel. sles
>> kernel will follow.
>> 
>> I will also try to revert the two changeset above.
> 
> These are the logs from sles11sp2 kernel in dom0+domU.
> The guest prints "hpet1: lost 2201 rtc interrupts".
> 
> Xen has changeset 26461 reverted, but this does at least not solve the
> "hpet1: lost 2201 rtc interrupts" interrupt messages.

Ugly. But I don't see the "IRQ8: nobody cared" anymore, and so
far I had assumed the two are connected.

Are you going to try reverting 26457:aa82638d58b0 (alone, or
perhaps the full range 26457-26461) next? That would at least
tell us whether similar reverts in the staging tree would have a
chance of getting us out of the currently stuck state again.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:14:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:14: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 1U2Mo1-0002U7-Nf; Mon, 04 Feb 2013 14:13: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 1U2Mo0-0002U2-Dg
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:13:56 +0000
Received: from [193.109.254.147:48810] by server-6.bemta-14.messagelabs.com id
	39/CD-12010-322CF015; Mon, 04 Feb 2013 14:13:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359987194!8503898!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10357 invoked from network); 4 Feb 2013 14:13:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 14:13:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:13:13 +0000
Message-Id: <510FD00602000078000BB84C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:13:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<1359652329.12252.306.camel@zakaz.uk.xensource.com>
	<20130131180957.GA31672@aepfle.de> <20130131184637.GA3052@aepfle.de>
	<510F7D9902000078000BB63F@nat28.tlf.novell.com>
	<510F83AA02000078000BB64A@nat28.tlf.novell.com>
	<20130204094909.GA2564@aepfle.de> <20130204140312.GA14684@aepfle.de>
In-Reply-To: <20130204140312.GA14684@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 15:03, Olaf Hering <olaf@aepfle.de> wrote:
> [ sorry, had this reply open in another window and forgot to send it ]
> 
> On Mon, Feb 04, Olaf Hering wrote:
> 
>> I'm attaching the xen, dom0 and domU logs from a pvops kernel. sles
>> kernel will follow.
>> 
>> I will also try to revert the two changeset above.
> 
> These are the logs from sles11sp2 kernel in dom0+domU.
> The guest prints "hpet1: lost 2201 rtc interrupts".
> 
> Xen has changeset 26461 reverted, but this does at least not solve the
> "hpet1: lost 2201 rtc interrupts" interrupt messages.

Ugly. But I don't see the "IRQ8: nobody cared" anymore, and so
far I had assumed the two are connected.

Are you going to try reverting 26457:aa82638d58b0 (alone, or
perhaps the full range 26457-26461) next? That would at least
tell us whether similar reverts in the staging tree would have a
chance of getting us out of the currently stuck state again.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:20: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 1U2Mtr-0002oq-6b; Mon, 04 Feb 2013 14:19: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 1U2Mtq-0002oh-6C
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:19:58 +0000
Received: from [193.109.254.147:53682] by server-1.bemta-14.messagelabs.com id
	75/C0-29874-D83CF015; Mon, 04 Feb 2013 14:19:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359987596!3241006!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 4 Feb 2013 14:19:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:19: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.297.1; Mon, 4 Feb 2013 14:19:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2Mto-0008TK-K7; Mon, 04 Feb 2013 14:19:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2Mto-0004VZ-DF;
	Mon, 04 Feb 2013 14:19:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.50060.307130.827214@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 14:19:56 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359975977.5281.58.camel@zakaz.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> > 
> > With some handholding, I managed to get the bisector to work on this.
> > It found that the original "good" version is unreliable: it built Xen
> > 5af4f2ab06f3 and in two recent tests on the same host, of the same
> > build, it failed once and passed once.
> 
> Hrm, did it make any progress over the w/e.

It stops when it finds that the failure, or the previous pass, isn't
reproducible.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:20: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 1U2Mtr-0002oq-6b; Mon, 04 Feb 2013 14:19: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 1U2Mtq-0002oh-6C
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:19:58 +0000
Received: from [193.109.254.147:53682] by server-1.bemta-14.messagelabs.com id
	75/C0-29874-D83CF015; Mon, 04 Feb 2013 14:19:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1359987596!3241006!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 4 Feb 2013 14:19:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:19: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.297.1; Mon, 4 Feb 2013 14:19:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2Mto-0008TK-K7; Mon, 04 Feb 2013 14:19:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2Mto-0004VZ-DF;
	Mon, 04 Feb 2013 14:19:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.50060.307130.827214@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 14:19:56 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359975977.5281.58.camel@zakaz.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> > 
> > With some handholding, I managed to get the bisector to work on this.
> > It found that the original "good" version is unreliable: it built Xen
> > 5af4f2ab06f3 and in two recent tests on the same host, of the same
> > build, it failed once and passed once.
> 
> Hrm, did it make any progress over the w/e.

It stops when it finds that the failure, or the previous pass, isn't
reproducible.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:22:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2MwD-0002yj-Pz; Mon, 04 Feb 2013 14:22:25 +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 1U2MwC-0002yb-5J
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:22:24 +0000
Received: from [193.109.254.147:13048] by server-10.bemta-14.messagelabs.com
	id 9E/33-12679-F14CF015; Mon, 04 Feb 2013 14:22:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1359987728!8946981!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9265 invoked from network); 4 Feb 2013 14:22:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:22:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:22: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.297.1; Mon, 4 Feb 2013
	14:22:08 +0000
Message-ID: <1359987727.7743.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 4 Feb 2013 14:22:07 +0000
In-Reply-To: <1359986376.7477.49.camel@zion.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
	<1359986043.7743.42.camel@zakaz.uk.xensource.com>
	<1359986376.7477.49.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:59 +0000, Wei Liu wrote:
> On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > > 
> > > > > /*
> > > > >  * Note to 3-level event channel users:
> > > > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > > > >  * area in Xen.
> > > > >  */
> > > > 
> > > > Can this be enforced by the system administrator?
> > > > 
> > > 
> > > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > > driver domain?
> > 
> > The admin knows, at the very least they need to have a manual override
> > (or maybe this should even default off for non-dom0)
> > 
> 
> Do you mean maintaining white list in Xen or adding options in guest
> kernel?

I mean that it should be a property of the domain (i.e. a flag in struct
domain or whatever) whether they can use 3-levels and this should be
settable by the host administrator when they build the guest.

> I already have that in my kernel patch series - only enable
> 3-level event channel for Dom0.

Imagine I am a malicious user of you cloud service, I could potentially
create dozens of guests using kernels which forcibly try to use 3-level
evtchns and suck up loads of host RAM.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:22:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2MwD-0002yj-Pz; Mon, 04 Feb 2013 14:22:25 +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 1U2MwC-0002yb-5J
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:22:24 +0000
Received: from [193.109.254.147:13048] by server-10.bemta-14.messagelabs.com
	id 9E/33-12679-F14CF015; Mon, 04 Feb 2013 14:22:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1359987728!8946981!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9265 invoked from network); 4 Feb 2013 14:22:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:22:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:22: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.297.1; Mon, 4 Feb 2013
	14:22:08 +0000
Message-ID: <1359987727.7743.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 4 Feb 2013 14:22:07 +0000
In-Reply-To: <1359986376.7477.49.camel@zion.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
	<1359986043.7743.42.camel@zakaz.uk.xensource.com>
	<1359986376.7477.49.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 13:59 +0000, Wei Liu wrote:
> On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > > 
> > > > > /*
> > > > >  * Note to 3-level event channel users:
> > > > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > > > >  * area in Xen.
> > > > >  */
> > > > 
> > > > Can this be enforced by the system administrator?
> > > > 
> > > 
> > > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > > driver domain?
> > 
> > The admin knows, at the very least they need to have a manual override
> > (or maybe this should even default off for non-dom0)
> > 
> 
> Do you mean maintaining white list in Xen or adding options in guest
> kernel?

I mean that it should be a property of the domain (i.e. a flag in struct
domain or whatever) whether they can use 3-levels and this should be
settable by the host administrator when they build the guest.

> I already have that in my kernel patch series - only enable
> 3-level event channel for Dom0.

Imagine I am a malicious user of you cloud service, I could potentially
create dozens of guests using kernels which forcibly try to use 3-level
evtchns and suck up loads of host RAM.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:23:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:23: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 1U2Mwg-00031L-7N; Mon, 04 Feb 2013 14:22: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 1U2Mwe-000315-QT
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:22:53 +0000
Received: from [193.109.254.147:14747] by server-9.bemta-14.messagelabs.com id
	39/B1-30867-C34CF015; Mon, 04 Feb 2013 14:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1359987755!2724336!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23129 invoked from network); 4 Feb 2013 14:22:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:22:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:22: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.297.1; Mon, 4 Feb 2013 14:22:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2MwN-0008Vo-2D; Mon, 04 Feb 2013 14:22:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2MwM-0004W8-Sd;
	Mon, 04 Feb 2013 14:22:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.50218.614149.355136@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 14:22:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359976933.5281.68.camel@zakaz.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > >> Under the circumstances it's not clear that the current staging is any
> > >> worse than non-staging.  I think we should push the revision reported
> > >> in this test (which was otherwise OK according to the tester) to
> > >> non-staging, with a manual "hg push".
> > > 
> > > This sounds like a good idea.
> > 
> > Wouldn't that set us up for the same problem again when the next
> > testing round fails here again?
> 
> Yes, that's true.

No.  Because the problem is essentially a fluke pass, not a fluke
fail.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:23:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:23: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 1U2Mwg-00031L-7N; Mon, 04 Feb 2013 14:22: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 1U2Mwe-000315-QT
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:22:53 +0000
Received: from [193.109.254.147:14747] by server-9.bemta-14.messagelabs.com id
	39/B1-30867-C34CF015; Mon, 04 Feb 2013 14:22:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1359987755!2724336!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23129 invoked from network); 4 Feb 2013 14:22:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:22:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:22: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.297.1; Mon, 4 Feb 2013 14:22:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2MwN-0008Vo-2D; Mon, 04 Feb 2013 14:22:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2MwM-0004W8-Sd;
	Mon, 04 Feb 2013 14:22:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.50218.614149.355136@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 14:22:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359976933.5281.68.camel@zakaz.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > >> Under the circumstances it's not clear that the current staging is any
> > >> worse than non-staging.  I think we should push the revision reported
> > >> in this test (which was otherwise OK according to the tester) to
> > >> non-staging, with a manual "hg push".
> > > 
> > > This sounds like a good idea.
> > 
> > Wouldn't that set us up for the same problem again when the next
> > testing round fails here again?
> 
> Yes, that's true.

No.  Because the problem is essentially a fluke pass, not a fluke
fail.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:24:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2Mxw-0003Bc-O8; Mon, 04 Feb 2013 14:24: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 1U2Mxu-0003B8-NV
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:24:10 +0000
Received: from [85.158.143.35:13133] by server-3.bemta-4.messagelabs.com id
	A7/41-08920-984CF015; Mon, 04 Feb 2013 14:24:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359987845!13729682!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1044 invoked from network); 4 Feb 2013 14:24:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:24:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14: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.297.1; Mon, 4 Feb 2013
	14:24:05 +0000
Message-ID: <1359987844.7743.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 14:24:04 +0000
In-Reply-To: <20751.50218.614149.355136@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> > On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> > > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > > >> Under the circumstances it's not clear that the current staging is any
> > > >> worse than non-staging.  I think we should push the revision reported
> > > >> in this test (which was otherwise OK according to the tester) to
> > > >> non-staging, with a manual "hg push".
> > > > 
> > > > This sounds like a good idea.
> > > 
> > > Wouldn't that set us up for the same problem again when the next
> > > testing round fails here again?
> > 
> > Yes, that's true.
> 
> No.  Because the problem is essentially a fluke pass, not a fluke
> fail.

So you are also proposing to flip something in osstest to erase the
fluke pass from its memory? Otherwise won't it see all future fails as
regressions, rather than never pass, due to the fluke pass?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:24:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2Mxw-0003Bc-O8; Mon, 04 Feb 2013 14:24: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 1U2Mxu-0003B8-NV
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:24:10 +0000
Received: from [85.158.143.35:13133] by server-3.bemta-4.messagelabs.com id
	A7/41-08920-984CF015; Mon, 04 Feb 2013 14:24:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359987845!13729682!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1044 invoked from network); 4 Feb 2013 14:24:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:24:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14: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.297.1; Mon, 4 Feb 2013
	14:24:05 +0000
Message-ID: <1359987844.7743.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 14:24:04 +0000
In-Reply-To: <20751.50218.614149.355136@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> > On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> > > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > > >> Under the circumstances it's not clear that the current staging is any
> > > >> worse than non-staging.  I think we should push the revision reported
> > > >> in this test (which was otherwise OK according to the tester) to
> > > >> non-staging, with a manual "hg push".
> > > > 
> > > > This sounds like a good idea.
> > > 
> > > Wouldn't that set us up for the same problem again when the next
> > > testing round fails here again?
> > 
> > Yes, that's true.
> 
> No.  Because the problem is essentially a fluke pass, not a fluke
> fail.

So you are also proposing to flip something in osstest to erase the
fluke pass from its memory? Otherwise won't it see all future fails as
regressions, rather than never pass, due to the fluke pass?

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:25:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:25: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 1U2Myn-0003JI-7D; Mon, 04 Feb 2013 14:25:05 +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 1U2Myl-0003Iy-V5
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:25:04 +0000
Received: from [85.158.139.211:16359] by server-7.bemta-5.messagelabs.com id
	A1/A9-11121-FB4CF015; Mon, 04 Feb 2013 14:25:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1359987900!20694733!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 4 Feb 2013 14:25:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="6165799"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:24:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:24:56 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2Mye-0007AF-HW;
	Mon, 04 Feb 2013 14:24:56 +0000
Message-ID: <1359987896.7477.53.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 14:24:56 +0000
In-Reply-To: <1359987727.7743.53.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
	<1359986043.7743.42.camel@zakaz.uk.xensource.com>
	<1359986376.7477.49.camel@zion.uk.xensource.com>
	<1359987727.7743.53.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 14:22 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 13:59 +0000, Wei Liu wrote:
> > On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> > > On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > > > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > > > 
> > > > > > /*
> > > > > >  * Note to 3-level event channel users:
> > > > > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > > > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > > > > >  * area in Xen.
> > > > > >  */
> > > > > 
> > > > > Can this be enforced by the system administrator?
> > > > > 
> > > > 
> > > > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > > > driver domain?
> > > 
> > > The admin knows, at the very least they need to have a manual override
> > > (or maybe this should even default off for non-dom0)
> > > 
> > 
> > Do you mean maintaining white list in Xen or adding options in guest
> > kernel?
> 
> I mean that it should be a property of the domain (i.e. a flag in struct
> domain or whatever) whether they can use 3-levels and this should be
> settable by the host administrator when they build the guest.
> 

I'm looking at this now since I realized that we cannot trust users at
all right after I sent my email...

> > I already have that in my kernel patch series - only enable
> > 3-level event channel for Dom0.
> 
> Imagine I am a malicious user of you cloud service, I could potentially
> create dozens of guests using kernels which forcibly try to use 3-level
> evtchns and suck up loads of host RAM.
> 

Right.

Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:25:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:25: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 1U2Myn-0003JI-7D; Mon, 04 Feb 2013 14:25:05 +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 1U2Myl-0003Iy-V5
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:25:04 +0000
Received: from [85.158.139.211:16359] by server-7.bemta-5.messagelabs.com id
	A1/A9-11121-FB4CF015; Mon, 04 Feb 2013 14:25:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1359987900!20694733!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 4 Feb 2013 14:25:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="6165799"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:24:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:24:56 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2Mye-0007AF-HW;
	Mon, 04 Feb 2013 14:24:56 +0000
Message-ID: <1359987896.7477.53.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 14:24:56 +0000
In-Reply-To: <1359987727.7743.53.camel@zakaz.uk.xensource.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<1359985623.7743.40.camel@zakaz.uk.xensource.com>
	<1359985864.7477.45.camel@zion.uk.xensource.com>
	<1359986043.7743.42.camel@zakaz.uk.xensource.com>
	<1359986376.7477.49.camel@zion.uk.xensource.com>
	<1359987727.7743.53.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 14:22 +0000, Ian Campbell wrote:
> On Mon, 2013-02-04 at 13:59 +0000, Wei Liu wrote:
> > On Mon, 2013-02-04 at 13:54 +0000, Ian Campbell wrote:
> > > On Mon, 2013-02-04 at 13:51 +0000, Wei Liu wrote:
> > > > On Mon, 2013-02-04 at 13:47 +0000, Ian Campbell wrote:
> > > > > On Mon, 2013-02-04 at 13:45 +0000, Wei Liu wrote:
> > > > > 
> > > > > > /*
> > > > > >  * Note to 3-level event channel users:
> > > > > >  * Only enable 3-level event channel for Dom0 or driver domains, because
> > > > > >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> > > > > >  * area in Xen.
> > > > > >  */
> > > > > 
> > > > > Can this be enforced by the system administrator?
> > > > > 
> > > > 
> > > > Knowing a domain is Dom0 is easy, but is it possible to know a domain is
> > > > driver domain?
> > > 
> > > The admin knows, at the very least they need to have a manual override
> > > (or maybe this should even default off for non-dom0)
> > > 
> > 
> > Do you mean maintaining white list in Xen or adding options in guest
> > kernel?
> 
> I mean that it should be a property of the domain (i.e. a flag in struct
> domain or whatever) whether they can use 3-levels and this should be
> settable by the host administrator when they build the guest.
> 

I'm looking at this now since I realized that we cannot trust users at
all right after I sent my email...

> > I already have that in my kernel patch series - only enable
> > 3-level event channel for Dom0.
> 
> Imagine I am a malicious user of you cloud service, I could potentially
> create dozens of guests using kernels which forcibly try to use 3-level
> evtchns and suck up loads of host RAM.
> 

Right.

Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:25:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:25: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 1U2MzW-0003RJ-7j; Mon, 04 Feb 2013 14:25:50 +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 1U2MzU-0003Qb-Dh
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:25:48 +0000
Received: from [193.109.254.147:54642] by server-8.bemta-14.messagelabs.com id
	29/BA-17325-BE4CF015; Mon, 04 Feb 2013 14:25:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1359987946!3917552!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10267 invoked from network); 4 Feb 2013 14:25:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 14:25:47 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo10) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 902818p14DdHL1 ;
	Mon, 4 Feb 2013 15:25:41 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D75E51884C; Mon,  4 Feb 2013 15:25:40 +0100 (CET)
Date: Mon, 4 Feb 2013 15:25:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204142540.GA17824@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <510FA33F02000078000BB71D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Jan Beulich wrote:

> So one question to you would be to clarify which hangs you see
> where under what conditions (I'm particularly unclear about the
> exact difference in behavior that you observe with xend vs xl).


This is a list of dom0+domU combinations with plain
26502:d1bf3b21f783:

pvops dom0 + pvops domU
  - very first domU hangs in hpet_rtc_interrupt
 
  - xl migrate domU localhost
    migration works, but new domU hangs in hpet_rtc_interrupt


sles11 dom0 + sles11 domU
  - guest prints "hpet1: lost 2201 rtc interrupts"

  - xm migrate works



I will retest more combinations with the source state above.


Now I tried x86-HVM-RTC.patch, and the result is that the very first
pvops guest boots fine, and also two xl migrate to localhost work fine!
I will do some more testing to see if its consistent.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:25:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:25: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 1U2MzW-0003RJ-7j; Mon, 04 Feb 2013 14:25:50 +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 1U2MzU-0003Qb-Dh
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:25:48 +0000
Received: from [193.109.254.147:54642] by server-8.bemta-14.messagelabs.com id
	29/BA-17325-BE4CF015; Mon, 04 Feb 2013 14:25:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1359987946!3917552!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10267 invoked from network); 4 Feb 2013 14:25:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 14:25:47 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo10) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 902818p14DdHL1 ;
	Mon, 4 Feb 2013 15:25:41 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D75E51884C; Mon,  4 Feb 2013 15:25:40 +0100 (CET)
Date: Mon, 4 Feb 2013 15:25:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204142540.GA17824@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <510FA33F02000078000BB71D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Jan Beulich wrote:

> So one question to you would be to clarify which hangs you see
> where under what conditions (I'm particularly unclear about the
> exact difference in behavior that you observe with xend vs xl).


This is a list of dom0+domU combinations with plain
26502:d1bf3b21f783:

pvops dom0 + pvops domU
  - very first domU hangs in hpet_rtc_interrupt
 
  - xl migrate domU localhost
    migration works, but new domU hangs in hpet_rtc_interrupt


sles11 dom0 + sles11 domU
  - guest prints "hpet1: lost 2201 rtc interrupts"

  - xm migrate works



I will retest more combinations with the source state above.


Now I tried x86-HVM-RTC.patch, and the result is that the very first
pvops guest boots fine, and also two xl migrate to localhost work fine!
I will do some more testing to see if its consistent.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:25:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:25: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 1U2MzT-0003QU-LY; Mon, 04 Feb 2013 14:25:47 +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 1U2MzS-0003QJ-Mn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:25:46 +0000
Received: from [85.158.143.99:57862] by server-3.bemta-4.messagelabs.com id
	46/73-08920-AE4CF015; Mon, 04 Feb 2013 14:25:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359987937!17848854!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26790 invoked from network); 4 Feb 2013 14:25:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="6165860"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:25:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:25:36 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2MzI-0007Aw-Ab;
	Mon, 04 Feb 2013 14:25:36 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6f8c532df545a3d51fecc9f035012de83760a96b
Message-ID: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 4 Feb 2013 14:25:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
	rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While the triple fault action on native hardware will result in a system
reset, any modern operating system can and will make use of less violent
reboot methods.  As a result, the most likely cause of a triple fault is a
fatal software bug.

This patch allows the toolstack to indicate that a triple fault should mean a
crash rather than a reboot.  The default of reboot still remains the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
 void hvm_triple_fault(void)
 {
     struct vcpu *v = current;
+    struct domain * d = v->domain;
+    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
+        ? SHUTDOWN_crash : SHUTDOWN_reboot;
+
     gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
-             "invoking HVM system reset.\n", v->vcpu_id);
-    domain_shutdown(v->domain, SHUTDOWN_reboot);
+             "invoking HVM system %s.\n", v->vcpu_id,
+             reason == SHUTDOWN_crash ? "crash" : "reboot");
+    domain_shutdown(v->domain, reason);
 }
 
 void hvm_inject_trap(struct hvm_trap *trap)
diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,9 @@
 #define HVM_PARAM_ACCESS_RING_PFN   28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
-#define HVM_NR_PARAMS          31
+/* Boolean: Should a triple fault imply crash rather than reboot? */
+#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
+
+#define HVM_NR_PARAMS          32
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:25:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:25: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 1U2MzT-0003QU-LY; Mon, 04 Feb 2013 14:25:47 +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 1U2MzS-0003QJ-Mn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:25:46 +0000
Received: from [85.158.143.99:57862] by server-3.bemta-4.messagelabs.com id
	46/73-08920-AE4CF015; Mon, 04 Feb 2013 14:25:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359987937!17848854!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26790 invoked from network); 4 Feb 2013 14:25:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="6165860"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:25:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:25:36 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2MzI-0007Aw-Ab;
	Mon, 04 Feb 2013 14:25:36 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6f8c532df545a3d51fecc9f035012de83760a96b
Message-ID: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 4 Feb 2013 14:25:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
	rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While the triple fault action on native hardware will result in a system
reset, any modern operating system can and will make use of less violent
reboot methods.  As a result, the most likely cause of a triple fault is a
fatal software bug.

This patch allows the toolstack to indicate that a triple fault should mean a
crash rather than a reboot.  The default of reboot still remains the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
 void hvm_triple_fault(void)
 {
     struct vcpu *v = current;
+    struct domain * d = v->domain;
+    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
+        ? SHUTDOWN_crash : SHUTDOWN_reboot;
+
     gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
-             "invoking HVM system reset.\n", v->vcpu_id);
-    domain_shutdown(v->domain, SHUTDOWN_reboot);
+             "invoking HVM system %s.\n", v->vcpu_id,
+             reason == SHUTDOWN_crash ? "crash" : "reboot");
+    domain_shutdown(v->domain, reason);
 }
 
 void hvm_inject_trap(struct hvm_trap *trap)
diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,9 @@
 #define HVM_PARAM_ACCESS_RING_PFN   28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
-#define HVM_NR_PARAMS          31
+/* Boolean: Should a triple fault imply crash rather than reboot? */
+#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
+
+#define HVM_NR_PARAMS          32
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:26:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2N04-0003Z1-MY; Mon, 04 Feb 2013 14:26: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 1U2N03-0003Yd-Qo
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:26:24 +0000
Received: from [193.109.254.147:3341] by server-13.bemta-14.messagelabs.com id
	F4/27-30639-F05CF015; Mon, 04 Feb 2013 14:26:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1359987980!1941368!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30752 invoked from network); 4 Feb 2013 14:26:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:26:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:26: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.297.1; Mon, 4 Feb 2013
	14:26:20 +0000
Message-ID: <1359987978.7743.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 14:26:18 +0000
In-Reply-To: <20751.50060.307130.827214@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<20751.50060.307130.827214@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:19 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > > > Tests which did not succeed and are blocking,
> > > > including tests which could not be run:
> > > >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> > > 
> > > With some handholding, I managed to get the bisector to work on this.
> > > It found that the original "good" version is unreliable: it built Xen
> > > 5af4f2ab06f3 and in two recent tests on the same host, of the same
> > > build, it failed once and passed once.
> > 
> > Hrm, did it make any progress over the w/e.
> 
> It stops when it finds that the failure, or the previous pass, isn't
> reproducible.

5af4f2ab06f3 is before 26461:78e91e9e4d61 thru 26456:1e9a8e155002 which
are Jan's RTC changes which rather rules them out I think.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:26:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2N04-0003Z1-MY; Mon, 04 Feb 2013 14:26: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 1U2N03-0003Yd-Qo
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:26:24 +0000
Received: from [193.109.254.147:3341] by server-13.bemta-14.messagelabs.com id
	F4/27-30639-F05CF015; Mon, 04 Feb 2013 14:26:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1359987980!1941368!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30752 invoked from network); 4 Feb 2013 14:26:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:26:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:26: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.297.1; Mon, 4 Feb 2013
	14:26:20 +0000
Message-ID: <1359987978.7743.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 14:26:18 +0000
In-Reply-To: <20751.50060.307130.827214@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<20751.50060.307130.827214@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:19 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> > > > Tests which did not succeed and are blocking,
> > > > including tests which could not be run:
> > > >  test-amd64-amd64-xl-qemut-win  7 windows-install     fail REGR. vs. 15179
> > > 
> > > With some handholding, I managed to get the bisector to work on this.
> > > It found that the original "good" version is unreliable: it built Xen
> > > 5af4f2ab06f3 and in two recent tests on the same host, of the same
> > > build, it failed once and passed once.
> > 
> > Hrm, did it make any progress over the w/e.
> 
> It stops when it finds that the failure, or the previous pass, isn't
> reproducible.

5af4f2ab06f3 is before 26461:78e91e9e4d61 thru 26456:1e9a8e155002 which
are Jan's RTC changes which rather rules them out I think.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:31:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2N4Y-0004DK-E7; Mon, 04 Feb 2013 14:31: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 1U2N4W-0004BZ-MX
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:31:00 +0000
Received: from [85.158.138.51:36494] by server-9.bemta-3.messagelabs.com id
	4D/68-09484-F16CF015; Mon, 04 Feb 2013 14:30:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1359988254!30897538!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29908 invoked from network); 4 Feb 2013 14:30:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:30: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.297.1; Mon, 4 Feb 2013 14:30:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2N4Q-0000AA-5Q; Mon, 04 Feb 2013 14:30:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2N4Q-0004XB-1b;
	Mon, 04 Feb 2013 14:30:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.50717.946471.697009@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 14:30:53 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359987844.7743.54.camel@zakaz.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<1359987844.7743.54.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> On Mon, 2013-02-04 at 14:22 +0000, Ian Jackson wrote:
> > No.  Because the problem is essentially a fluke pass, not a fluke
> > fail.
> 
> So you are also proposing to flip something in osstest to erase the
> fluke pass from its memory? Otherwise won't it see all future fails as
> regressions, rather than never pass, due to the fluke pass?

No, right now I'm proposing to do a manual push of (as I proposed)
d1bf3b21f783.  The effect of that is that future pushes will be
regarded as regressions iff their test results are worse than
d1bf3b21f783's.

That is, the test system uses whatever revision non-staging has as the
baseline revision, not whatever it most recently tested.  (And if
non-staging hasn't had a test at all, it will test 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 Feb 04 14:31:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2N4Y-0004DK-E7; Mon, 04 Feb 2013 14:31: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 1U2N4W-0004BZ-MX
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:31:00 +0000
Received: from [85.158.138.51:36494] by server-9.bemta-3.messagelabs.com id
	4D/68-09484-F16CF015; Mon, 04 Feb 2013 14:30:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1359988254!30897538!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29908 invoked from network); 4 Feb 2013 14:30:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:30: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.297.1; Mon, 4 Feb 2013 14:30:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2N4Q-0000AA-5Q; Mon, 04 Feb 2013 14:30:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2N4Q-0004XB-1b;
	Mon, 04 Feb 2013 14:30:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.50717.946471.697009@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 14:30:53 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359987844.7743.54.camel@zakaz.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<1359987844.7743.54.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> On Mon, 2013-02-04 at 14:22 +0000, Ian Jackson wrote:
> > No.  Because the problem is essentially a fluke pass, not a fluke
> > fail.
> 
> So you are also proposing to flip something in osstest to erase the
> fluke pass from its memory? Otherwise won't it see all future fails as
> regressions, rather than never pass, due to the fluke pass?

No, right now I'm proposing to do a manual push of (as I proposed)
d1bf3b21f783.  The effect of that is that future pushes will be
regarded as regressions iff their test results are worse than
d1bf3b21f783's.

That is, the test system uses whatever revision non-staging has as the
baseline revision, not whatever it most recently tested.  (And if
non-staging hasn't had a test at all, it will test 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 Feb 04 14:34:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:34: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 1U2N7N-0004M1-0X; Mon, 04 Feb 2013 14:33: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 1U2N7L-0004Lv-Sf
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:33:55 +0000
Received: from [85.158.143.35:53143] by server-1.bemta-4.messagelabs.com id
	F5/81-08839-3D6CF015; Mon, 04 Feb 2013 14:33:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1359988403!15138003!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29824 invoked from network); 4 Feb 2013 14:33:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:33:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:33: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.297.1; Mon, 4 Feb 2013
	14:33:23 +0000
Message-ID: <1359988402.7743.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 14:33:22 +0000
In-Reply-To: <20751.50717.946471.697009@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<1359987844.7743.54.camel@zakaz.uk.xensource.com>
	<20751.50717.946471.697009@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:30 +0000, Ian Jackson wrote:
> the test system uses whatever revision non-staging has as the
> baseline revision, not whatever it most recently tested.

Ah, I was expecting it went further back in history (i.e. did this test
*ever* pass).

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:34:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:34: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 1U2N7N-0004M1-0X; Mon, 04 Feb 2013 14:33: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 1U2N7L-0004Lv-Sf
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:33:55 +0000
Received: from [85.158.143.35:53143] by server-1.bemta-4.messagelabs.com id
	F5/81-08839-3D6CF015; Mon, 04 Feb 2013 14:33:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1359988403!15138003!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29824 invoked from network); 4 Feb 2013 14:33:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:33:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1122751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:33: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.297.1; Mon, 4 Feb 2013
	14:33:23 +0000
Message-ID: <1359988402.7743.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 14:33:22 +0000
In-Reply-To: <20751.50717.946471.697009@mariner.uk.xensource.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<1359987844.7743.54.camel@zakaz.uk.xensource.com>
	<20751.50717.946471.697009@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:30 +0000, Ian Jackson wrote:
> the test system uses whatever revision non-staging has as the
> baseline revision, not whatever it most recently tested.

Ah, I was expecting it went further back in history (i.e. did this test
*ever* pass).

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:36:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:36: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 1U2NA2-0004Vf-Jd; Mon, 04 Feb 2013 14:36: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 1U2NA1-0004VV-B3
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:36:41 +0000
Received: from [85.158.139.83:52781] by server-5.bemta-5.messagelabs.com id
	D3/41-11945-877CF015; Mon, 04 Feb 2013 14:36:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1359988598!30748651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1119 invoked from network); 4 Feb 2013 14:36:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:36:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="6167408"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:36:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:36:37 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2N9x-0007KX-45;
	Mon, 04 Feb 2013 14:36:37 +0000
Message-ID: <1359988597.7477.54.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 14:36:37 +0000
In-Reply-To: <510FCE8902000078000BB83A@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<510FCE8902000078000BB83A@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	wei.liu2@citrix.com, David Vrabel <david.vrabel@citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 14:06 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 14:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
> >> >> 
> >> >> So this alone already is up to 16 pages per guest, and hence a
> >> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
> >> > 
> >> > That's given a theoretical 32k guests? Ouch. It also ignores the need
> >> > for other global mappings.
> >> > 
> >> > on the flip side only a minority of domains are likely to be using the
> >> > extended scheme, and I expect even those which are would not be using
> >> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> >> > evtchns.
> >> > 
> >> > Where does 16 come from? How many pages to we end up with at each level
> >> > in the new scheme?
> >> 
> >> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
> >> got two of them (pending and mask bits).
> >> 
> >> > Some levels of the trie are per-VCPU, did you account for that already
> >> > in the 2GB?
> >> 
> >> No, I didn't, as it would only increase the number, and make
> >> the math less clear.
> >> 
> >> >>  The
> >> >> global page mapping area, however, is only 1Gb in size on x86-64
> >> >> (didn't check ARM at all)...
> >> > 
> >> > There isn't currently a global page mapping area on 32-bit ARM (I
> >> > suppose we have avoided them somehow...) but obviously 2G would be a
> >> > problem in a 4GB address space.
> >> > 
> >> > On ARM we currently have 2G for domheap mappings which I suppose we
> >> > would split if we needed a global page map
> >> > 
> >> > These need to be global so we can deliver evtchns to VCPUs which aren't
> >> > running, right? I suppose mapping on demand (other than for a running
> >> > VCPU) would be prohibitively expensive.
> >> 
> >> Likely, especially for high rate ones.
> >> 
> >> > Could we make this space per-VCPU (or per-domain) by saying that a
> >> > domain maps its own evtchn pages plus the required pages from other
> >> > domains with which an evtchn is bound? Might be tricky to arrange
> >> > though, especially with the per-VCPU pages and affinity changes?
> >> 
> >> Even without that trickiness it wouldn't work I'm afraid: In various
> >> cases we need to be able to raise the events out of context (timer,
> >> IRQs from passed through devices).
> >> 
> >> Jan
> > 
> > So I come up with following comment on the 3-level registration
> > interface (not specific to __map_l3_array() function).
> > 
> > /*
> >  * Note to 3-level event channel users:
> >  * Only enable 3-level event channel for Dom0 or driver domains, because
> >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> >  * area in Xen.
> >  */
> 
> So you intended to fail the request for other guests? That's fine
> with me in principle, but how do you tell a driver domain from an
> "ordinary" one?
> 

I can't at the moment. I'm investigating on adding a flag in domain
creation process.


Wei.

> Jan
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:36:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:36: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 1U2NA2-0004Vf-Jd; Mon, 04 Feb 2013 14:36: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 1U2NA1-0004VV-B3
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:36:41 +0000
Received: from [85.158.139.83:52781] by server-5.bemta-5.messagelabs.com id
	D3/41-11945-877CF015; Mon, 04 Feb 2013 14:36:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1359988598!30748651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1119 invoked from network); 4 Feb 2013 14:36:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:36:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="6167408"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:36:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:36:37 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2N9x-0007KX-45;
	Mon, 04 Feb 2013 14:36:37 +0000
Message-ID: <1359988597.7477.54.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 14:36:37 +0000
In-Reply-To: <510FCE8902000078000BB83A@nat28.tlf.novell.com>
References: <1359643384-29392-1-git-send-email-wei.liu2@citrix.com>
	<1359643384-29392-16-git-send-email-wei.liu2@citrix.com>
	<510F8C0E02000078000BB67C@nat28.tlf.novell.com>
	<1359976820.5281.66.camel@zakaz.uk.xensource.com>
	<510FA9B902000078000BB762@nat28.tlf.novell.com>
	<1359985517.7477.42.camel@zion.uk.xensource.com>
	<510FCE8902000078000BB83A@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	wei.liu2@citrix.com, David Vrabel <david.vrabel@citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating
 3-level event channel 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

On Mon, 2013-02-04 at 14:06 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 14:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
> >> >> 
> >> >> So this alone already is up to 16 pages per guest, and hence a
> >> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
> >> > 
> >> > That's given a theoretical 32k guests? Ouch. It also ignores the need
> >> > for other global mappings.
> >> > 
> >> > on the flip side only a minority of domains are likely to be using the
> >> > extended scheme, and I expect even those which are would not be using
> >> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> >> > evtchns.
> >> > 
> >> > Where does 16 come from? How many pages to we end up with at each level
> >> > in the new scheme?
> >> 
> >> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
> >> got two of them (pending and mask bits).
> >> 
> >> > Some levels of the trie are per-VCPU, did you account for that already
> >> > in the 2GB?
> >> 
> >> No, I didn't, as it would only increase the number, and make
> >> the math less clear.
> >> 
> >> >>  The
> >> >> global page mapping area, however, is only 1Gb in size on x86-64
> >> >> (didn't check ARM at all)...
> >> > 
> >> > There isn't currently a global page mapping area on 32-bit ARM (I
> >> > suppose we have avoided them somehow...) but obviously 2G would be a
> >> > problem in a 4GB address space.
> >> > 
> >> > On ARM we currently have 2G for domheap mappings which I suppose we
> >> > would split if we needed a global page map
> >> > 
> >> > These need to be global so we can deliver evtchns to VCPUs which aren't
> >> > running, right? I suppose mapping on demand (other than for a running
> >> > VCPU) would be prohibitively expensive.
> >> 
> >> Likely, especially for high rate ones.
> >> 
> >> > Could we make this space per-VCPU (or per-domain) by saying that a
> >> > domain maps its own evtchn pages plus the required pages from other
> >> > domains with which an evtchn is bound? Might be tricky to arrange
> >> > though, especially with the per-VCPU pages and affinity changes?
> >> 
> >> Even without that trickiness it wouldn't work I'm afraid: In various
> >> cases we need to be able to raise the events out of context (timer,
> >> IRQs from passed through devices).
> >> 
> >> Jan
> > 
> > So I come up with following comment on the 3-level registration
> > interface (not specific to __map_l3_array() function).
> > 
> > /*
> >  * Note to 3-level event channel users:
> >  * Only enable 3-level event channel for Dom0 or driver domains, because
> >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> >  * area in Xen.
> >  */
> 
> So you intended to fail the request for other guests? That's fine
> with me in principle, but how do you tell a driver domain from an
> "ordinary" one?
> 

I can't at the moment. I'm investigating on adding a flag in domain
creation process.


Wei.

> Jan
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:40:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:40: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 1U2NDT-0004g2-Ar; Mon, 04 Feb 2013 14:40: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 1U2NDR-0004fx-SL
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:40:14 +0000
Received: from [85.158.143.35:38539] by server-1.bemta-4.messagelabs.com id
	ED/4B-08839-D48CF015; Mon, 04 Feb 2013 14:40:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1359988789!11640986!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27024 invoked from network); 4 Feb 2013 14:39:52 -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; 4 Feb 2013 14:39:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:39:48 +0000
Message-Id: <510FD64202000078000BB8BC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:39:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
In-Reply-To: <20751.50218.614149.355136@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 04.02.13 at 15:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - 
> FAIL"):
>> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
>> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
>> > >> Under the circumstances it's not clear that the current staging is any
>> > >> worse than non-staging.  I think we should push the revision reported
>> > >> in this test (which was otherwise OK according to the tester) to
>> > >> non-staging, with a manual "hg push".
>> > > 
>> > > This sounds like a good idea.
>> > 
>> > Wouldn't that set us up for the same problem again when the next
>> > testing round fails here again?
>> 
>> Yes, that's true.
> 
> No.  Because the problem is essentially a fluke pass, not a fluke
> fail.

I'm not sure - previously, iirc, we had inconsistent successes and
failures of this test (and I think another one or two). Now we
appear to have run into a consistent failure state, so something
must have changed.

Luckily there is an indication from Olaf that rather than reverting,
applying the remaining pieces of the broken up RTC emulation
changes (which I didn't post formally yet, mainly in the hope to
get a push first, considering that these bits were what originally
caused regressions when applied as a single monolithic change -
and with a bug fixed only after I split things apart - late in the
4.2 cycle) unbreaks what he reported broken.

I could certainly post that patch right away, but I'd like to give
it a little more time to see whether Olaf can confirm his initial
findings, and because with that I'm less certain that the test
failure really is to be attributed to the RTC emulation changes
at all.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:40:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:40: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 1U2NDT-0004g2-Ar; Mon, 04 Feb 2013 14:40: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 1U2NDR-0004fx-SL
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:40:14 +0000
Received: from [85.158.143.35:38539] by server-1.bemta-4.messagelabs.com id
	ED/4B-08839-D48CF015; Mon, 04 Feb 2013 14:40:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1359988789!11640986!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27024 invoked from network); 4 Feb 2013 14:39:52 -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; 4 Feb 2013 14:39:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:39:48 +0000
Message-Id: <510FD64202000078000BB8BC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:39:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
In-Reply-To: <20751.50218.614149.355136@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 04.02.13 at 15:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - 
> FAIL"):
>> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
>> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
>> > >> Under the circumstances it's not clear that the current staging is any
>> > >> worse than non-staging.  I think we should push the revision reported
>> > >> in this test (which was otherwise OK according to the tester) to
>> > >> non-staging, with a manual "hg push".
>> > > 
>> > > This sounds like a good idea.
>> > 
>> > Wouldn't that set us up for the same problem again when the next
>> > testing round fails here again?
>> 
>> Yes, that's true.
> 
> No.  Because the problem is essentially a fluke pass, not a fluke
> fail.

I'm not sure - previously, iirc, we had inconsistent successes and
failures of this test (and I think another one or two). Now we
appear to have run into a consistent failure state, so something
must have changed.

Luckily there is an indication from Olaf that rather than reverting,
applying the remaining pieces of the broken up RTC emulation
changes (which I didn't post formally yet, mainly in the hope to
get a push first, considering that these bits were what originally
caused regressions when applied as a single monolithic change -
and with a bug fixed only after I split things apart - late in the
4.2 cycle) unbreaks what he reported broken.

I could certainly post that patch right away, but I'd like to give
it a little more time to see whether Olaf can confirm his initial
findings, and because with that I'm less certain that the test
failure really is to be attributed to the RTC emulation changes
at all.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:44:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:44: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 1U2NHW-0004ta-1F; Mon, 04 Feb 2013 14:44: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 1U2NHU-0004tR-9y
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:44:24 +0000
Received: from [85.158.139.83:52567] by server-1.bemta-5.messagelabs.com id
	F0/39-29263-749CF015; Mon, 04 Feb 2013 14:44:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1359989062!24846303!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12217 invoked from network); 4 Feb 2013 14:44:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1123278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:44: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.297.1; Mon, 4 Feb 2013
	14:44:22 +0000
Message-ID: <1359989061.7743.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 14:44:21 +0000
In-Reply-To: <510FD64202000078000BB8BC@nat28.tlf.novell.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<510FD64202000078000BB8BC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:39 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 15:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - 
> > FAIL"):
> >> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> >> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> >> > >> Under the circumstances it's not clear that the current staging is any
> >> > >> worse than non-staging.  I think we should push the revision reported
> >> > >> in this test (which was otherwise OK according to the tester) to
> >> > >> non-staging, with a manual "hg push".
> >> > > 
> >> > > This sounds like a good idea.
> >> > 
> >> > Wouldn't that set us up for the same problem again when the next
> >> > testing round fails here again?
> >> 
> >> Yes, that's true.
> > 
> > No.  Because the problem is essentially a fluke pass, not a fluke
> > fail.
> 
> I'm not sure - previously, iirc, we had inconsistent successes and
> failures of this test (and I think another one or two). Now we
> appear to have run into a consistent failure state, so something
> must have changed.
> 
> Luckily there is an indication from Olaf that rather than reverting,
> applying the remaining pieces of the broken up RTC emulation
> changes (which I didn't post formally yet, mainly in the hope to
> get a push first, considering that these bits were what originally
> caused regressions when applied as a single monolithic change -
> and with a bug fixed only after I split things apart - late in the
> 4.2 cycle) unbreaks what he reported broken.
> 
> I could certainly post that patch right away, but I'd like to give
> it a little more time to see whether Olaf can confirm his initial
> findings, and because with that I'm less certain that the test
> failure really is to be attributed to the RTC emulation changes
> at all.

Based on <1359987978.7743.56.camel@zakaz.uk.xensource.com> I don't think
the RTC changes are to blame, since Ian says the baseline was
5af4f2ab06f3 which is before 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 Feb 04 14:44:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:44: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 1U2NHW-0004ta-1F; Mon, 04 Feb 2013 14:44: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 1U2NHU-0004tR-9y
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:44:24 +0000
Received: from [85.158.139.83:52567] by server-1.bemta-5.messagelabs.com id
	F0/39-29263-749CF015; Mon, 04 Feb 2013 14:44:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1359989062!24846303!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12217 invoked from network); 4 Feb 2013 14:44:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1123278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:44: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.297.1; Mon, 4 Feb 2013
	14:44:22 +0000
Message-ID: <1359989061.7743.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 14:44:21 +0000
In-Reply-To: <510FD64202000078000BB8BC@nat28.tlf.novell.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<510FD64202000078000BB8BC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 Mon, 2013-02-04 at 14:39 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 15:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - 
> > FAIL"):
> >> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
> >> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
> >> > >> Under the circumstances it's not clear that the current staging is any
> >> > >> worse than non-staging.  I think we should push the revision reported
> >> > >> in this test (which was otherwise OK according to the tester) to
> >> > >> non-staging, with a manual "hg push".
> >> > > 
> >> > > This sounds like a good idea.
> >> > 
> >> > Wouldn't that set us up for the same problem again when the next
> >> > testing round fails here again?
> >> 
> >> Yes, that's true.
> > 
> > No.  Because the problem is essentially a fluke pass, not a fluke
> > fail.
> 
> I'm not sure - previously, iirc, we had inconsistent successes and
> failures of this test (and I think another one or two). Now we
> appear to have run into a consistent failure state, so something
> must have changed.
> 
> Luckily there is an indication from Olaf that rather than reverting,
> applying the remaining pieces of the broken up RTC emulation
> changes (which I didn't post formally yet, mainly in the hope to
> get a push first, considering that these bits were what originally
> caused regressions when applied as a single monolithic change -
> and with a bug fixed only after I split things apart - late in the
> 4.2 cycle) unbreaks what he reported broken.
> 
> I could certainly post that patch right away, but I'd like to give
> it a little more time to see whether Olaf can confirm his initial
> findings, and because with that I'm less certain that the test
> failure really is to be attributed to the RTC emulation changes
> at all.

Based on <1359987978.7743.56.camel@zakaz.uk.xensource.com> I don't think
the RTC changes are to blame, since Ian says the baseline was
5af4f2ab06f3 which is before 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 Feb 04 14:44:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2NHj-0004uo-Ef; Mon, 04 Feb 2013 14:44:39 +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 1U2NHh-0004uV-Qa
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:44:37 +0000
Received: from [85.158.138.51:32799] by server-9.bemta-3.messagelabs.com id
	A7/56-09484-059CF015; Mon, 04 Feb 2013 14:44:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1359989070!27546010!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9105 invoked from network); 4 Feb 2013 14:44:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 14:44:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo19) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C02a74p14DgG9X ;
	Mon, 4 Feb 2013 15:44:25 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 99C161884C; Mon,  4 Feb 2013 15:44:24 +0100 (CET)
Date: Mon, 4 Feb 2013 15:44:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204144424.GA18602@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130204142540.GA17824@aepfle.de>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Olaf Hering wrote:

> Now I tried x86-HVM-RTC.patch, and the result is that the very first
> pvops guest boots fine, and also two xl migrate to localhost work fine!
> I will do some more testing to see if its consistent.

So two cycles of pvops dom0 show that the first guest starts fine. xl
create/migrate works fine as well.
Later I did shutdown the xl guest, started xend and ran the sles11
kernel in the guest, no more hpet1 messages. 
Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
are really gone.

So I think the x86-HVM-RTC.patch works well for me.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:44:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2NHj-0004uo-Ef; Mon, 04 Feb 2013 14:44:39 +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 1U2NHh-0004uV-Qa
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:44:37 +0000
Received: from [85.158.138.51:32799] by server-9.bemta-3.messagelabs.com id
	A7/56-09484-059CF015; Mon, 04 Feb 2013 14:44:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1359989070!27546010!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9105 invoked from network); 4 Feb 2013 14:44:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 14:44:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jored mo19) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C02a74p14DgG9X ;
	Mon, 4 Feb 2013 15:44:25 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 99C161884C; Mon,  4 Feb 2013 15:44:24 +0100 (CET)
Date: Mon, 4 Feb 2013 15:44:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204144424.GA18602@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130204142540.GA17824@aepfle.de>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Olaf Hering wrote:

> Now I tried x86-HVM-RTC.patch, and the result is that the very first
> pvops guest boots fine, and also two xl migrate to localhost work fine!
> I will do some more testing to see if its consistent.

So two cycles of pvops dom0 show that the first guest starts fine. xl
create/migrate works fine as well.
Later I did shutdown the xl guest, started xend and ran the sles11
kernel in the guest, no more hpet1 messages. 
Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
are really gone.

So I think the x86-HVM-RTC.patch works well for me.

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:47:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:47: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 1U2NKN-00056r-E5; Mon, 04 Feb 2013 14:47:23 +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 1U2NKM-00056g-3j
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:47:22 +0000
Received: from [85.158.143.35:43582] by server-2.bemta-4.messagelabs.com id
	F7/FA-01597-9F9CF015; Mon, 04 Feb 2013 14:47:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1359989171!11841436!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31786 invoked from network); 4 Feb 2013 14:46:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 14:46:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:46:11 +0000
Message-Id: <510FD7C002000078000BB8F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:46:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
In-Reply-To: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 15:25, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods.  As a result, the most likely cause of a triple fault is a
> fatal software bug.
> 
> This patch allows the toolstack to indicate that a triple fault should mean 
> a
> crash rather than a reboot.  The default of reboot still remains the same.

Makes sense to me; minor nits below (no need to resend just
because of that, but would be nice to be addressed if you had
to rev the patch anyway).

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>  void hvm_triple_fault(void)
>  {
>      struct vcpu *v = current;
> +    struct domain * d = v->domain;

Stray blank.

> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
> +
>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
> -             "invoking HVM system reset.\n", v->vcpu_id);
> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
> +             "invoking HVM system %s.\n", v->vcpu_id,
> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
> +    domain_shutdown(v->domain, reason);

So you have d cached in a local variable now, yet you still use
v->domain here?

Also, I'd prefer for the message to continue to say "reset".

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:47:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:47: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 1U2NKN-00056r-E5; Mon, 04 Feb 2013 14:47:23 +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 1U2NKM-00056g-3j
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:47:22 +0000
Received: from [85.158.143.35:43582] by server-2.bemta-4.messagelabs.com id
	F7/FA-01597-9F9CF015; Mon, 04 Feb 2013 14:47:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1359989171!11841436!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31786 invoked from network); 4 Feb 2013 14:46:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 14:46:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:46:11 +0000
Message-Id: <510FD7C002000078000BB8F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:46:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
In-Reply-To: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 15:25, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods.  As a result, the most likely cause of a triple fault is a
> fatal software bug.
> 
> This patch allows the toolstack to indicate that a triple fault should mean 
> a
> crash rather than a reboot.  The default of reboot still remains the same.

Makes sense to me; minor nits below (no need to resend just
because of that, but would be nice to be addressed if you had
to rev the patch anyway).

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>  void hvm_triple_fault(void)
>  {
>      struct vcpu *v = current;
> +    struct domain * d = v->domain;

Stray blank.

> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
> +
>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
> -             "invoking HVM system reset.\n", v->vcpu_id);
> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
> +             "invoking HVM system %s.\n", v->vcpu_id,
> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
> +    domain_shutdown(v->domain, reason);

So you have d cached in a local variable now, yet you still use
v->domain here?

Also, I'd prefer for the message to continue to say "reset".

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:48:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2NLR-0005E0-Sn; Mon, 04 Feb 2013 14:48:29 +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 1U2NLQ-0005Dh-0i
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:48:28 +0000
Received: from [85.158.139.83:24768] by server-11.bemta-5.messagelabs.com id
	76/F6-19159-B3ACF015; Mon, 04 Feb 2013 14:48:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1359989306!30333817!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5589 invoked from network); 4 Feb 2013 14:48:26 -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; 4 Feb 2013 14:48:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:48:26 +0000
Message-Id: <510FD84702000078000BB8F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:48:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<510FD64202000078000BB8BC@nat28.tlf.novell.com>
	<1359989061.7743.59.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359989061.7743.59.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 04.02.13 at 15:44, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-04 at 14:39 +0000, Jan Beulich wrote:
>> >>> On 04.02.13 at 15:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: 
> regressions - 
>> > FAIL"):
>> >> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
>> >> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
>> >> > >> Under the circumstances it's not clear that the current staging is any
>> >> > >> worse than non-staging.  I think we should push the revision reported
>> >> > >> in this test (which was otherwise OK according to the tester) to
>> >> > >> non-staging, with a manual "hg push".
>> >> > > 
>> >> > > This sounds like a good idea.
>> >> > 
>> >> > Wouldn't that set us up for the same problem again when the next
>> >> > testing round fails here again?
>> >> 
>> >> Yes, that's true.
>> > 
>> > No.  Because the problem is essentially a fluke pass, not a fluke
>> > fail.
>> 
>> I'm not sure - previously, iirc, we had inconsistent successes and
>> failures of this test (and I think another one or two). Now we
>> appear to have run into a consistent failure state, so something
>> must have changed.
>> 
>> Luckily there is an indication from Olaf that rather than reverting,
>> applying the remaining pieces of the broken up RTC emulation
>> changes (which I didn't post formally yet, mainly in the hope to
>> get a push first, considering that these bits were what originally
>> caused regressions when applied as a single monolithic change -
>> and with a bug fixed only after I split things apart - late in the
>> 4.2 cycle) unbreaks what he reported broken.
>> 
>> I could certainly post that patch right away, but I'd like to give
>> it a little more time to see whether Olaf can confirm his initial
>> findings, and because with that I'm less certain that the test
>> failure really is to be attributed to the RTC emulation changes
>> at all.
> 
> Based on <1359987978.7743.56.camel@zakaz.uk.xensource.com> I don't think
> the RTC changes are to blame, since Ian says the baseline was
> 5af4f2ab06f3 which is before then.

Okay - I'm certainly not opposed to a manual push.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:48:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14: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 1U2NLR-0005E0-Sn; Mon, 04 Feb 2013 14:48:29 +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 1U2NLQ-0005Dh-0i
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 14:48:28 +0000
Received: from [85.158.139.83:24768] by server-11.bemta-5.messagelabs.com id
	76/F6-19159-B3ACF015; Mon, 04 Feb 2013 14:48:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1359989306!30333817!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5589 invoked from network); 4 Feb 2013 14:48:26 -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; 4 Feb 2013 14:48:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 14:48:26 +0000
Message-Id: <510FD84702000078000BB8F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 14:48:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<510FD64202000078000BB8BC@nat28.tlf.novell.com>
	<1359989061.7743.59.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359989061.7743.59.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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 04.02.13 at 15:44, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-04 at 14:39 +0000, Jan Beulich wrote:
>> >>> On 04.02.13 at 15:22, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 15401: 
> regressions - 
>> > FAIL"):
>> >> On Mon, 2013-02-04 at 11:17 +0000, Jan Beulich wrote:
>> >> > >>> On 04.02.13 at 12:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > > On Fri, 2013-02-01 at 11:44 +0000, Ian Jackson wrote:
>> >> > >> Under the circumstances it's not clear that the current staging is any
>> >> > >> worse than non-staging.  I think we should push the revision reported
>> >> > >> in this test (which was otherwise OK according to the tester) to
>> >> > >> non-staging, with a manual "hg push".
>> >> > > 
>> >> > > This sounds like a good idea.
>> >> > 
>> >> > Wouldn't that set us up for the same problem again when the next
>> >> > testing round fails here again?
>> >> 
>> >> Yes, that's true.
>> > 
>> > No.  Because the problem is essentially a fluke pass, not a fluke
>> > fail.
>> 
>> I'm not sure - previously, iirc, we had inconsistent successes and
>> failures of this test (and I think another one or two). Now we
>> appear to have run into a consistent failure state, so something
>> must have changed.
>> 
>> Luckily there is an indication from Olaf that rather than reverting,
>> applying the remaining pieces of the broken up RTC emulation
>> changes (which I didn't post formally yet, mainly in the hope to
>> get a push first, considering that these bits were what originally
>> caused regressions when applied as a single monolithic change -
>> and with a bug fixed only after I split things apart - late in the
>> 4.2 cycle) unbreaks what he reported broken.
>> 
>> I could certainly post that patch right away, but I'd like to give
>> it a little more time to see whether Olaf can confirm his initial
>> findings, and because with that I'm less certain that the test
>> failure really is to be attributed to the RTC emulation changes
>> at all.
> 
> Based on <1359987978.7743.56.camel@zakaz.uk.xensource.com> I don't think
> the RTC changes are to blame, since Ian says the baseline was
> 5af4f2ab06f3 which is before then.

Okay - I'm certainly not opposed to a manual push.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:51:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2NO2-0005R5-FL; Mon, 04 Feb 2013 14:51:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U2NO0-0005Qt-Ib
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:51:08 +0000
Received: from [193.109.254.147:8854] by server-6.bemta-14.messagelabs.com id
	28/2B-12010-BDACF015; Mon, 04 Feb 2013 14:51:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1359989440!3633410!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23842 invoked from network); 4 Feb 2013 14:50:41 -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;
	4 Feb 2013 14:50:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5865525"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:50:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:50:39 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2NNX-0007Xn-Eo;
	Mon, 04 Feb 2013 14:50:39 +0000
Message-ID: <510FCABF.7010003@citrix.com>
Date: Mon, 4 Feb 2013 14:50:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
	<510FD7C002000078000BB8F0@nat28.tlf.novell.com>
In-Reply-To: <510FD7C002000078000BB8F0@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 14:46, Jan Beulich wrote:
>>>> On 04.02.13 at 15:25, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> While the triple fault action on native hardware will result in a system
>> reset, any modern operating system can and will make use of less violent
>> reboot methods.  As a result, the most likely cause of a triple fault is a
>> fatal software bug.
>>
>> This patch allows the toolstack to indicate that a triple fault should mean 
>> a
>> crash rather than a reboot.  The default of reboot still remains the same.
> Makes sense to me; minor nits below (no need to resend just
> because of that, but would be nice to be addressed if you had
> to rev the patch anyway).
>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>>  void hvm_triple_fault(void)
>>  {
>>      struct vcpu *v = current;
>> +    struct domain * d = v->domain;
> Stray blank.

Space between * and d ?

>
>> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
>> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
>> +
>>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
>> -             "invoking HVM system reset.\n", v->vcpu_id);
>> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
>> +             "invoking HVM system %s.\n", v->vcpu_id,
>> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
>> +    domain_shutdown(v->domain, reason);
> So you have d cached in a local variable now, yet you still use
> v->domain here?

Doh - missed that.

>
> Also, I'd prefer for the message to continue to say "reset".
>
> Jan
>
Ok - I will respin and send as non-rfc.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:51:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2NO2-0005R5-FL; Mon, 04 Feb 2013 14:51:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U2NO0-0005Qt-Ib
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:51:08 +0000
Received: from [193.109.254.147:8854] by server-6.bemta-14.messagelabs.com id
	28/2B-12010-BDACF015; Mon, 04 Feb 2013 14:51:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1359989440!3633410!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23842 invoked from network); 4 Feb 2013 14:50:41 -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;
	4 Feb 2013 14:50:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5865525"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:50:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:50:39 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2NNX-0007Xn-Eo;
	Mon, 04 Feb 2013 14:50:39 +0000
Message-ID: <510FCABF.7010003@citrix.com>
Date: Mon, 4 Feb 2013 14:50:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
	<510FD7C002000078000BB8F0@nat28.tlf.novell.com>
In-Reply-To: <510FD7C002000078000BB8F0@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 14:46, Jan Beulich wrote:
>>>> On 04.02.13 at 15:25, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> While the triple fault action on native hardware will result in a system
>> reset, any modern operating system can and will make use of less violent
>> reboot methods.  As a result, the most likely cause of a triple fault is a
>> fatal software bug.
>>
>> This patch allows the toolstack to indicate that a triple fault should mean 
>> a
>> crash rather than a reboot.  The default of reboot still remains the same.
> Makes sense to me; minor nits below (no need to resend just
> because of that, but would be nice to be addressed if you had
> to rev the patch anyway).
>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>>  void hvm_triple_fault(void)
>>  {
>>      struct vcpu *v = current;
>> +    struct domain * d = v->domain;
> Stray blank.

Space between * and d ?

>
>> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
>> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
>> +
>>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
>> -             "invoking HVM system reset.\n", v->vcpu_id);
>> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
>> +             "invoking HVM system %s.\n", v->vcpu_id,
>> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
>> +    domain_shutdown(v->domain, reason);
> So you have d cached in a local variable now, yet you still use
> v->domain here?

Doh - missed that.

>
> Also, I'd prefer for the message to continue to say "reset".
>
> Jan
>
Ok - I will respin and send as non-rfc.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:54:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:54: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 1U2NQu-0005f2-2r; Mon, 04 Feb 2013 14:54:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2NQt-0005es-9D
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:54:07 +0000
Received: from [85.158.139.211:15268] by server-3.bemta-5.messagelabs.com id
	80/DA-07037-E8BCF015; Mon, 04 Feb 2013 14:54:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1359989645!21046249!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5999 invoked from network); 4 Feb 2013 14:54:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:54:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1123687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:54:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 4 Feb 2013
	14:54:05 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Date: Mon, 4 Feb 2013 14:54:04 +0000
Thread-Topic: coverage license information
Thread-Index: Ac4C53o0lsCyXXPiSYOc7xdCergnOg==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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'd like to add coverage support to Xen.

I imported some headers from Linux kernel which mainly came from
gcov-io.h and the structures used internally by GCC.

Our problem is currently about the license. In gcov-io.h is stated that
license is mainly GPL2 which the exception that linking the "library"
with other files does not cause these files to be GPL2. Now however I'm
not linking to any library but just using the structure declaration
inside the header to produce a blob that is currently converted into GCC
files by an external utility (Xen has not file system so we extract
coverage information).

It's not a problem to use these headers/structure from Xen (which is
GPL2) but we'd like to have these defines in our public include headers.
The license however of these headers is quite open and allow to be used
for instance in commercial programs. How the license would affect these
programs?

Another question we have is the stability of these structures. Can we
just check the version field of gcov_info to make sure that the internal
structure is not changed or is it expected that even this field would
change (for instance position or size inside the structure) ?

Regards,
  Frediano

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:54:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:54: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 1U2NQu-0005f2-2r; Mon, 04 Feb 2013 14:54:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2NQt-0005es-9D
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:54:07 +0000
Received: from [85.158.139.211:15268] by server-3.bemta-5.messagelabs.com id
	80/DA-07037-E8BCF015; Mon, 04 Feb 2013 14:54:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1359989645!21046249!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5999 invoked from network); 4 Feb 2013 14:54:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:54:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1123687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:54:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 4 Feb 2013
	14:54:05 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Date: Mon, 4 Feb 2013 14:54:04 +0000
Thread-Topic: coverage license information
Thread-Index: Ac4C53o0lsCyXXPiSYOc7xdCergnOg==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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'd like to add coverage support to Xen.

I imported some headers from Linux kernel which mainly came from
gcov-io.h and the structures used internally by GCC.

Our problem is currently about the license. In gcov-io.h is stated that
license is mainly GPL2 which the exception that linking the "library"
with other files does not cause these files to be GPL2. Now however I'm
not linking to any library but just using the structure declaration
inside the header to produce a blob that is currently converted into GCC
files by an external utility (Xen has not file system so we extract
coverage information).

It's not a problem to use these headers/structure from Xen (which is
GPL2) but we'd like to have these defines in our public include headers.
The license however of these headers is quite open and allow to be used
for instance in commercial programs. How the license would affect these
programs?

Another question we have is the stability of these structures. Can we
just check the version field of gcov_info to make sure that the internal
structure is not changed or is it expected that even this field would
change (for instance position or size inside the structure) ?

Regards,
  Frediano

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:56:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:56: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 1U2NSr-0005m8-JE; Mon, 04 Feb 2013 14:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2NSp-0005lv-Ty
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:56:08 +0000
Received: from [85.158.138.51:7346] by server-6.bemta-3.messagelabs.com id
	0E/38-29959-70CCF015; Mon, 04 Feb 2013 14:56:07 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1359989765!30947102!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18425 invoked from network); 4 Feb 2013 14:56:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1123783"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:56:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 4 Feb 2013
	14:56:04 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 14:56:03 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Coverage support
Thread-Index: Ac4C58DQkjqo2/QaTpiEhctay+S/2A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835C@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<510F8D0B02000078000BB681@nat28.tlf.novell.com>
In-Reply-To: <510F8D0B02000078000BB681@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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, 2013-02-04 at 09:27 +0000, Jan Beulich wrote:
> >>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > Updated set of patches for coverage.
> > Changes:
> > - implemented way of getting information
> > - use only 2 parameter in hypercall (still not sure it's better to use
> >   sysctl)
> > - use "coverage" for configuration option as suggested by Ian Campbell
> > - split header in include/public/gcov.h and include/xen/gcov.h to allow
> >   tools to include public header
> > - use weak to avoid defining compat_coverage_op
> 
> While probably not formally documented anywhere, we decided
> against using weak some time ago.
> 
> Furthermore, iirc I already told you that with a suitably defined
> interface you won't need a compat variant at all (and in particular
> that would be the case if you went the sysctl route, as was
> suggested to you).
> 
> Jan
> 

I changed today the interface to use sysctl instead of directly
hypercall. No weak symbols and easier makefiles. Still to pack updated
version (see my mail about possible license issues).

Frediano


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:56:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:56: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 1U2NSr-0005m8-JE; Mon, 04 Feb 2013 14:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2NSp-0005lv-Ty
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:56:08 +0000
Received: from [85.158.138.51:7346] by server-6.bemta-3.messagelabs.com id
	0E/38-29959-70CCF015; Mon, 04 Feb 2013 14:56:07 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1359989765!30947102!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18425 invoked from network); 4 Feb 2013 14:56:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 14:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1123783"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 14:56:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 4 Feb 2013
	14:56:04 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 14:56:03 +0000
Thread-Topic: [Xen-devel] [RFC PATCH] Coverage support
Thread-Index: Ac4C58DQkjqo2/QaTpiEhctay+S/2A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835C@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<510F8D0B02000078000BB681@nat28.tlf.novell.com>
In-Reply-To: <510F8D0B02000078000BB681@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH] Coverage 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, 2013-02-04 at 09:27 +0000, Jan Beulich wrote:
> >>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > Updated set of patches for coverage.
> > Changes:
> > - implemented way of getting information
> > - use only 2 parameter in hypercall (still not sure it's better to use
> >   sysctl)
> > - use "coverage" for configuration option as suggested by Ian Campbell
> > - split header in include/public/gcov.h and include/xen/gcov.h to allow
> >   tools to include public header
> > - use weak to avoid defining compat_coverage_op
> 
> While probably not formally documented anywhere, we decided
> against using weak some time ago.
> 
> Furthermore, iirc I already told you that with a suitably defined
> interface you won't need a compat variant at all (and in particular
> that would be the case if you went the sysctl route, as was
> suggested to you).
> 
> Jan
> 

I changed today the interface to use sysctl instead of directly
hypercall. No weak symbols and easier makefiles. Still to pack updated
version (see my mail about possible license issues).

Frediano


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:59:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:59: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 1U2NVu-0005wZ-6w; Mon, 04 Feb 2013 14:59:18 +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 1U2NVs-0005wS-CE
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:59:16 +0000
Received: from [85.158.143.35:29201] by server-1.bemta-4.messagelabs.com id
	6D/66-08839-3CCCF015; Mon, 04 Feb 2013 14:59:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1359989932!13654039!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4737 invoked from network); 4 Feb 2013 14:58:54 -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;
	4 Feb 2013 14:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5866292"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:57:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:57:52 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2NUW-0007do-MK;
	Mon, 04 Feb 2013 14:57:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: de5df9f5af1d3ba1eb87a6fc766998cee3858a72
Message-ID: <de5df9f5af1d3ba1eb87.1359989872@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 4 Feb 2013 14:57:52 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] hvm: Allow triple fault to imply crash
	rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While the triple fault action on native hardware will result in a system
reset, any modern operating system can and will make use of less violent
reboot methods.  As a result, the most likely cause of a triple fault is a
fatal software bug.

This patch allows the toolstack to indicate that a triple fault should mean a
crash rather than a reboot.  The default of reboot still remains the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * "reboot" -> "reset"
 * v->domain -> d

diff -r 5af4f2ab06f3 -r de5df9f5af1d xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
 void hvm_triple_fault(void)
 {
     struct vcpu *v = current;
+    struct domain *d = v->domain;
+    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
+        ? SHUTDOWN_crash : SHUTDOWN_reboot;
+
     gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
-             "invoking HVM system reset.\n", v->vcpu_id);
-    domain_shutdown(v->domain, SHUTDOWN_reboot);
+             "invoking HVM system %s.\n", v->vcpu_id,
+             reason == SHUTDOWN_crash ? "crash" : "reset");
+    domain_shutdown(d, reason);
 }
 
 void hvm_inject_trap(struct hvm_trap *trap)
diff -r 5af4f2ab06f3 -r de5df9f5af1d xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,9 @@
 #define HVM_PARAM_ACCESS_RING_PFN   28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
-#define HVM_NR_PARAMS          31
+/* Boolean: Should a triple fault imply crash rather than reboot? */
+#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
+
+#define HVM_NR_PARAMS          32
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 14:59:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 14:59: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 1U2NVu-0005wZ-6w; Mon, 04 Feb 2013 14:59:18 +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 1U2NVs-0005wS-CE
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 14:59:16 +0000
Received: from [85.158.143.35:29201] by server-1.bemta-4.messagelabs.com id
	6D/66-08839-3CCCF015; Mon, 04 Feb 2013 14:59:15 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1359989932!13654039!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4737 invoked from network); 4 Feb 2013 14:58:54 -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;
	4 Feb 2013 14:58:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="5866292"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 14:57:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 09:57:52 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2NUW-0007do-MK;
	Mon, 04 Feb 2013 14:57:52 +0000
MIME-Version: 1.0
X-Mercurial-Node: de5df9f5af1d3ba1eb87a6fc766998cee3858a72
Message-ID: <de5df9f5af1d3ba1eb87.1359989872@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 4 Feb 2013 14:57:52 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH v2] hvm: Allow triple fault to imply crash
	rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While the triple fault action on native hardware will result in a system
reset, any modern operating system can and will make use of less violent
reboot methods.  As a result, the most likely cause of a triple fault is a
fatal software bug.

This patch allows the toolstack to indicate that a triple fault should mean a
crash rather than a reboot.  The default of reboot still remains the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * "reboot" -> "reset"
 * v->domain -> d

diff -r 5af4f2ab06f3 -r de5df9f5af1d xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
 void hvm_triple_fault(void)
 {
     struct vcpu *v = current;
+    struct domain *d = v->domain;
+    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
+        ? SHUTDOWN_crash : SHUTDOWN_reboot;
+
     gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
-             "invoking HVM system reset.\n", v->vcpu_id);
-    domain_shutdown(v->domain, SHUTDOWN_reboot);
+             "invoking HVM system %s.\n", v->vcpu_id,
+             reason == SHUTDOWN_crash ? "crash" : "reset");
+    domain_shutdown(d, reason);
 }
 
 void hvm_inject_trap(struct hvm_trap *trap)
diff -r 5af4f2ab06f3 -r de5df9f5af1d xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,9 @@
 #define HVM_PARAM_ACCESS_RING_PFN   28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
-#define HVM_NR_PARAMS          31
+/* Boolean: Should a triple fault imply crash rather than reboot? */
+#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
+
+#define HVM_NR_PARAMS          32
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:07:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2NdD-0006Eb-64; Mon, 04 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U2In0-0008Lc-E8
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 09:56:38 +0000
Received: from [85.158.143.35:3929] by server-1.bemta-4.messagelabs.com id
	85/95-08839-5D58F015; Mon, 04 Feb 2013 09:56:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359971584!10382140!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32689 invoked from network); 4 Feb 2013 09:53:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 09:53:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 09:53: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.297.1; Mon, 4 Feb 2013
	09:53:04 +0000
Message-ID: <1359971583.5281.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: digvijay chauhan <digvijaych@gmail.com>
Date: Mon, 4 Feb 2013 09:53:03 +0000
In-Reply-To: <CANq0ewvS6ryme4aRMLOqg=bx1CKNoZWUpgf4iJrmMEDmt_3Djg@mail.gmail.com>
References: <CANq0ewvS6ryme4aRMLOqg=bx1CKNoZWUpgf4iJrmMEDmt_3Djg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 04 Feb 2013 15:06:50 +0000
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] how to use sctp during live migration
	of vm with 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

Please do not cross post,
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions and
http://wiki.xen.org/wiki/Xen_Users_Netiquette both ask you not to.

Since this is a users question I've moved devel to Bcc

On Fri, 2013-02-01 at 14:18 +0000, digvijay chauhan wrote:
>          I want to carry out the performance analysis of transport
> protocol i.e sctp so how can we achieve it.Instead of using tcp if we
> have to use sctp how to do that?

The xl migrate command takes a -s option which specifies the command to
run to connect to the target, the default is to use ssh but you can
supply any script you like.

The script should take its stdin/stdout and connect them, via whatever
means, to the stdin/stdout of "xl migrate-receive" running on the remote
host.

So you just need to arrange for "whatever means" to mean SCTP. If you
have a netcat type utility for SCTP then it ought to be relatively
straightforward.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:07:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2NdD-0006Eb-64; Mon, 04 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U2In0-0008Lc-E8
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 09:56:38 +0000
Received: from [85.158.143.35:3929] by server-1.bemta-4.messagelabs.com id
	85/95-08839-5D58F015; Mon, 04 Feb 2013 09:56:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1359971584!10382140!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32689 invoked from network); 4 Feb 2013 09:53:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 09:53:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,598,1355097600"; 
   d="scan'208";a="1111146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 09:53: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.297.1; Mon, 4 Feb 2013
	09:53:04 +0000
Message-ID: <1359971583.5281.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: digvijay chauhan <digvijaych@gmail.com>
Date: Mon, 4 Feb 2013 09:53:03 +0000
In-Reply-To: <CANq0ewvS6ryme4aRMLOqg=bx1CKNoZWUpgf4iJrmMEDmt_3Djg@mail.gmail.com>
References: <CANq0ewvS6ryme4aRMLOqg=bx1CKNoZWUpgf4iJrmMEDmt_3Djg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 04 Feb 2013 15:06:50 +0000
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] how to use sctp during live migration
	of vm with 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

Please do not cross post,
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions and
http://wiki.xen.org/wiki/Xen_Users_Netiquette both ask you not to.

Since this is a users question I've moved devel to Bcc

On Fri, 2013-02-01 at 14:18 +0000, digvijay chauhan wrote:
>          I want to carry out the performance analysis of transport
> protocol i.e sctp so how can we achieve it.Instead of using tcp if we
> have to use sctp how to do that?

The xl migrate command takes a -s option which specifies the command to
run to connect to the target, the default is to use ssh but you can
supply any script you like.

The script should take its stdin/stdout and connect them, via whatever
means, to the stdin/stdout of "xl migrate-receive" running on the remote
host.

So you just need to arrange for "whatever means" to mean SCTP. If you
have a netcat type utility for SCTP then it ought to be relatively
straightforward.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:26:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:26: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 1U2Nw2-0006UM-1R; Mon, 04 Feb 2013 15:26:18 +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 1U2Nw0-0006UH-PG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:26:16 +0000
Received: from [85.158.137.99:10009] by server-9.bemta-3.messagelabs.com id
	9D/D5-09484-313DF015; Mon, 04 Feb 2013 15:26:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1359991571!19057008!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11487 invoked from network); 4 Feb 2013 15:26:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:26:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:26: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.297.1; Mon, 4 Feb 2013
	15:26:11 +0000
Message-ID: <1359991569.7743.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 4 Feb 2013 15:26:09 +0000
In-Reply-To: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
References: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods.  As a result, the most likely cause of a triple fault is a
> fatal software bug.
> 
> This patch allows the toolstack to indicate that a triple fault should mean a
> crash rather than a reboot.  The default of reboot still remains the same.

Just a random thought -- what about adding SHUTDOWN_triple_fault as an
explicit thing, then the toolstack can decide what to do?

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>  void hvm_triple_fault(void)
>  {
>      struct vcpu *v = current;
> +    struct domain * d = v->domain;
> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
> +
>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
> -             "invoking HVM system reset.\n", v->vcpu_id);
> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
> +             "invoking HVM system %s.\n", v->vcpu_id,
> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
> +    domain_shutdown(v->domain, reason);
>  }
>  
>  void hvm_inject_trap(struct hvm_trap *trap)
> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/include/public/hvm/params.h
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -142,6 +142,9 @@
>  #define HVM_PARAM_ACCESS_RING_PFN   28
>  #define HVM_PARAM_SHARING_RING_PFN  29
>  
> -#define HVM_NR_PARAMS          31
> +/* Boolean: Should a triple fault imply crash rather than reboot? */
> +#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
> +
> +#define HVM_NR_PARAMS          32
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 15:26:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:26: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 1U2Nw2-0006UM-1R; Mon, 04 Feb 2013 15:26:18 +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 1U2Nw0-0006UH-PG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:26:16 +0000
Received: from [85.158.137.99:10009] by server-9.bemta-3.messagelabs.com id
	9D/D5-09484-313DF015; Mon, 04 Feb 2013 15:26:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1359991571!19057008!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11487 invoked from network); 4 Feb 2013 15:26:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:26:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:26: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.297.1; Mon, 4 Feb 2013
	15:26:11 +0000
Message-ID: <1359991569.7743.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon, 4 Feb 2013 15:26:09 +0000
In-Reply-To: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
References: <6f8c532df545a3d51fec.1359987936@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods.  As a result, the most likely cause of a triple fault is a
> fatal software bug.
> 
> This patch allows the toolstack to indicate that a triple fault should mean a
> crash rather than a reboot.  The default of reboot still remains the same.

Just a random thought -- what about adding SHUTDOWN_triple_fault as an
explicit thing, then the toolstack can decide what to do?

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>  void hvm_triple_fault(void)
>  {
>      struct vcpu *v = current;
> +    struct domain * d = v->domain;
> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
> +
>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
> -             "invoking HVM system reset.\n", v->vcpu_id);
> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
> +             "invoking HVM system %s.\n", v->vcpu_id,
> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
> +    domain_shutdown(v->domain, reason);
>  }
>  
>  void hvm_inject_trap(struct hvm_trap *trap)
> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/include/public/hvm/params.h
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -142,6 +142,9 @@
>  #define HVM_PARAM_ACCESS_RING_PFN   28
>  #define HVM_PARAM_SHARING_RING_PFN  29
>  
> -#define HVM_NR_PARAMS          31
> +/* Boolean: Should a triple fault imply crash rather than reboot? */
> +#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
> +
> +#define HVM_NR_PARAMS          32
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 15:27:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:27: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 1U2Nwl-0006XF-Ke; Mon, 04 Feb 2013 15:27: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 1U2Nwj-0006X4-Gm
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 15:27:02 +0000
Received: from [85.158.137.99:22760] by server-5.bemta-3.messagelabs.com id
	70/BC-04457-443DF015; Mon, 04 Feb 2013 15:27:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1359991619!19898453!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23511 invoked from network); 4 Feb 2013 15:26:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:26:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:26: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.297.1; Mon, 4 Feb 2013 15:26:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2NwP-0000S3-On;
	Mon, 04 Feb 2013 15:26:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2NwP-0007vA-4W;
	Mon, 04 Feb 2013 15:26:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15417-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 15:26:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15417: 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 15417 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15417/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check            fail pass in 15416
 test-amd64-amd64-xl-qemut-winxpsp3 12 guest-localmigrate/x10 fail in 15416 pass in 15417
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 15416 pass in 15417
 test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail in 15416 pass in 15417

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:27:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:27: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 1U2Nwl-0006XF-Ke; Mon, 04 Feb 2013 15:27: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 1U2Nwj-0006X4-Gm
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 15:27:02 +0000
Received: from [85.158.137.99:22760] by server-5.bemta-3.messagelabs.com id
	70/BC-04457-443DF015; Mon, 04 Feb 2013 15:27:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1359991619!19898453!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23511 invoked from network); 4 Feb 2013 15:26:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:26:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:26: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.297.1; Mon, 4 Feb 2013 15:26:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2NwP-0000S3-On;
	Mon, 04 Feb 2013 15:26:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2NwP-0007vA-4W;
	Mon, 04 Feb 2013 15:26:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15417-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 15:26:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15417: 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 15417 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15417/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check            fail pass in 15416
 test-amd64-amd64-xl-qemut-winxpsp3 12 guest-localmigrate/x10 fail in 15416 pass in 15417
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 15416 pass in 15417
 test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail in 15416 pass in 15417

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-qemut-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         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-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  d1bf3b21f783
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1095 lines long.)

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:29:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:29: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 1U2Nz0-0006hu-9a; Mon, 04 Feb 2013 15:29:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2Nyz-0006hm-BI
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:29:21 +0000
Received: from [85.158.143.99:18321] by server-2.bemta-4.messagelabs.com id
	FB/85-01597-0D3DF015; Mon, 04 Feb 2013 15:29:20 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359991756!21153657!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18022 invoked from network); 4 Feb 2013 15:29:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125127"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:29:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 4 Feb 2013
	15:29:16 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 15:29:15 +0000
Thread-Topic: [Xen-devel] [PATCH 2/4] Adding support for coverage information
Thread-Index: Ac4C7GRpV+LMXMxBTCWGIu0zaOI4tQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835D@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
	<510F8FF502000078000BB69C@nat28.tlf.novell.com>
In-Reply-To: <510F8FF502000078000BB69C@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 09:39 +0000, Jan Beulich wrote:
> >>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -228,3 +228,7 @@ QEMU_TAG ?= 2a1354d655d816feaad7dbdb8364f40a208439c1
> >  # doing and are prepared for some pain.
> >  
> >  CONFIG_TESTS       ?= y
> > +
> > +# Test coverage support
> > +coverage ?= n
> > +
> 
> Alongside debug and debug_symbols please.

Ok.

> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
> >  
> >  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
> >  
> > +
> 
> Stray blank line.
> 
> > +ifeq ($(coverage),y)
> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> > +endif
> 
> For one - isn't simply using $(obj-y) here sufficient (i.e. without the
> $(filter-out ...))?
> 
> And second, I would thing this then ought to become a single line:
> 
> $(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> 

Yes, it works fine and seems to compile all proper files but I don't
understand why.
What's the difference between $(obj-bin-y) and $(obj-y) ??

> > --- /dev/null
> > +++ b/xen/common/gcov/Makefile
> > @@ -0,0 +1,5 @@
> > +ifneq ($(coverage),y)
> > +obj-y += nogcov.o
> > +endif
> > +obj-$(coverage) += gcov.o
> > +
> 
> How about
> 
> obj-y := nogcov.o
> obj-$(coverage) := gcov.o
> 

Using sysctl is even simpler, just 

subdir-$(coverage) += gcov

in common/Makefile and

obj-y += gcov.o

in common/gcov/Makefile

> 
> > +typedef void (*ctor_func_t)(void);
> > +extern struct
> > +{
> > +    unsigned long count;
> > +    ctor_func_t funcs[1];
> > +} __CTOR_LIST__;
> 
> const?
> 

Fine.

> > +
> > +void init_coverage(void)
> 
> __init
> 

I removed from previous and put in the header as suggestion.

> > --- /dev/null
> > +++ b/xen/include/public/gcov.h
> > @@ -0,0 +1,93 @@
> > +/*
> > + *  Profiling infrastructure declarations.
> > + *
> > + *  This file is based on gcc-internal definitions. Data structures are
> > + *  defined to be compatible with gcc counterparts. For a better
> > + *  understanding, refer to gcc source: gcc/gcov-io.h.
> > + *
> > + *    Copyright IBM Corp. 2009
> > + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > + *
> > + *    Uses gcc-internal data definitions.
> > + */
> > +
> > +#ifndef XEN_PUBLIC_GCOV_H
> > +#define XEN_PUBLIC_GCOV_H XEN_PUBLIC_GCOV_H
> > +
> > +/*
> > + * Profiling data types used for gcc 3.4 and above - these are defined by
> > + * gcc and need to be kept as close to the original definition as possible to
> > + * remain compatible.
> > + */
> > +#define GCOV_COUNTERS         5
> > +#define GCOV_DATA_MAGIC       ((unsigned int) 0x67636461)
> > +#define GCOV_TAG_FUNCTION     ((unsigned int) 0x01000000)
> > +#define GCOV_TAG_COUNTER_BASE ((unsigned int) 0x01a10000)
> > +#define GCOV_TAG_FOR_COUNTER(count) \
> > +    (GCOV_TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
> > +
> > +#if BITS_PER_LONG >= 64
> > +typedef long gcov_type;
> > +#else
> > +typedef long long gcov_type;
> > +#endif
> 
> What's this???
> 

This came from Linux, probably for Xen a simple

typedef long gcov_type

is ok.

> > +/**
> > + * struct gcov_ctr_info - profiling data per counter type
> > + * @num: number of counter values for this type
> > + * @values: array of counter values for this type
> > + * @merge: merge function for counter values of this type (unused)
> > + *
> > + * This data is generated by gcc during compilation and doesn't change
> > + * at run-time with the exception of the values array.
> > + */
> > +struct gcov_ctr_info
> > +{
> > +    unsigned int num;
> > +    gcov_type *values;
> > +    void (*merge)(gcov_type *, unsigned int);
> > +};
> 
> Pointers, and even more so function ones, can't be part of the
> public interface.
> 

Yes, probably there is no need to expose this to public.

Probably defining only the exported blob would be ok and have no licence
issues.

> Jan
> 

Frediano

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:29:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:29: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 1U2Nz0-0006hu-9a; Mon, 04 Feb 2013 15:29:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2Nyz-0006hm-BI
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:29:21 +0000
Received: from [85.158.143.99:18321] by server-2.bemta-4.messagelabs.com id
	FB/85-01597-0D3DF015; Mon, 04 Feb 2013 15:29:20 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1359991756!21153657!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18022 invoked from network); 4 Feb 2013 15:29:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125127"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:29:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 4 Feb 2013
	15:29:16 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Mon, 4 Feb 2013 15:29:15 +0000
Thread-Topic: [Xen-devel] [PATCH 2/4] Adding support for coverage information
Thread-Index: Ac4C7GRpV+LMXMxBTCWGIu0zaOI4tQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835D@LONPMAILBOX01.citrite.net>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
	<510F8FF502000078000BB69C@nat28.tlf.novell.com>
In-Reply-To: <510F8FF502000078000BB69C@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 09:39 +0000, Jan Beulich wrote:
> >>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -228,3 +228,7 @@ QEMU_TAG ?= 2a1354d655d816feaad7dbdb8364f40a208439c1
> >  # doing and are prepared for some pain.
> >  
> >  CONFIG_TESTS       ?= y
> > +
> > +# Test coverage support
> > +coverage ?= n
> > +
> 
> Alongside debug and debug_symbols please.

Ok.

> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
> >  
> >  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
> >  
> > +
> 
> Stray blank line.
> 
> > +ifeq ($(coverage),y)
> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> > +endif
> 
> For one - isn't simply using $(obj-y) here sufficient (i.e. without the
> $(filter-out ...))?
> 
> And second, I would thing this then ought to become a single line:
> 
> $(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> 

Yes, it works fine and seems to compile all proper files but I don't
understand why.
What's the difference between $(obj-bin-y) and $(obj-y) ??

> > --- /dev/null
> > +++ b/xen/common/gcov/Makefile
> > @@ -0,0 +1,5 @@
> > +ifneq ($(coverage),y)
> > +obj-y += nogcov.o
> > +endif
> > +obj-$(coverage) += gcov.o
> > +
> 
> How about
> 
> obj-y := nogcov.o
> obj-$(coverage) := gcov.o
> 

Using sysctl is even simpler, just 

subdir-$(coverage) += gcov

in common/Makefile and

obj-y += gcov.o

in common/gcov/Makefile

> 
> > +typedef void (*ctor_func_t)(void);
> > +extern struct
> > +{
> > +    unsigned long count;
> > +    ctor_func_t funcs[1];
> > +} __CTOR_LIST__;
> 
> const?
> 

Fine.

> > +
> > +void init_coverage(void)
> 
> __init
> 

I removed from previous and put in the header as suggestion.

> > --- /dev/null
> > +++ b/xen/include/public/gcov.h
> > @@ -0,0 +1,93 @@
> > +/*
> > + *  Profiling infrastructure declarations.
> > + *
> > + *  This file is based on gcc-internal definitions. Data structures are
> > + *  defined to be compatible with gcc counterparts. For a better
> > + *  understanding, refer to gcc source: gcc/gcov-io.h.
> > + *
> > + *    Copyright IBM Corp. 2009
> > + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > + *
> > + *    Uses gcc-internal data definitions.
> > + */
> > +
> > +#ifndef XEN_PUBLIC_GCOV_H
> > +#define XEN_PUBLIC_GCOV_H XEN_PUBLIC_GCOV_H
> > +
> > +/*
> > + * Profiling data types used for gcc 3.4 and above - these are defined by
> > + * gcc and need to be kept as close to the original definition as possible to
> > + * remain compatible.
> > + */
> > +#define GCOV_COUNTERS         5
> > +#define GCOV_DATA_MAGIC       ((unsigned int) 0x67636461)
> > +#define GCOV_TAG_FUNCTION     ((unsigned int) 0x01000000)
> > +#define GCOV_TAG_COUNTER_BASE ((unsigned int) 0x01a10000)
> > +#define GCOV_TAG_FOR_COUNTER(count) \
> > +    (GCOV_TAG_COUNTER_BASE + ((unsigned int) (count) << 17))
> > +
> > +#if BITS_PER_LONG >= 64
> > +typedef long gcov_type;
> > +#else
> > +typedef long long gcov_type;
> > +#endif
> 
> What's this???
> 

This came from Linux, probably for Xen a simple

typedef long gcov_type

is ok.

> > +/**
> > + * struct gcov_ctr_info - profiling data per counter type
> > + * @num: number of counter values for this type
> > + * @values: array of counter values for this type
> > + * @merge: merge function for counter values of this type (unused)
> > + *
> > + * This data is generated by gcc during compilation and doesn't change
> > + * at run-time with the exception of the values array.
> > + */
> > +struct gcov_ctr_info
> > +{
> > +    unsigned int num;
> > +    gcov_type *values;
> > +    void (*merge)(gcov_type *, unsigned int);
> > +};
> 
> Pointers, and even more so function ones, can't be part of the
> public interface.
> 

Yes, probably there is no need to expose this to public.

Probably defining only the exported blob would be ok and have no licence
issues.

> Jan
> 

Frediano

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:33:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:33: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 1U2O2L-0006ve-28; Mon, 04 Feb 2013 15:32:49 +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 1U2O2J-0006vS-1s
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:32:47 +0000
Received: from [85.158.143.35:36836] by server-1.bemta-4.messagelabs.com id
	42/26-08839-E94DF015; Mon, 04 Feb 2013 15:32:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359991666!13742213!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12738 invoked from network); 4 Feb 2013 15:27:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 15:27:46 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jorabe mo25) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 207719p14F3LSN ;
	Mon, 4 Feb 2013 16:27:39 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 60F621884C; Mon,  4 Feb 2013 16:27:39 +0100 (CET)
Date: Mon, 4 Feb 2013 16:27:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204152739.GA20329@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>
	<20130204144424.GA18602@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130204144424.GA18602@aepfle.de>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Olaf Hering wrote:

> Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> are really gone.

With sles11 dom0+domU there are no more hpet1 messages when started from
xend.


With xl however I now get a hanging guest, which I did not see before this
patch. But this happens only if it is booted with quiet, with 'debug
ignore_loglevel' booting works fine.
Also xl list shows the domain in paused state?!

I will try once more with sles11 kernel, xl and the RTC patch reverted..

Olaf


xl dump-core shows just this in dmesg:

<6>[    0.000000] Initializing cgroup subsys cpu
<5>[    0.000000] Linux version 3.0.51-0.7.9-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)
<6>[    0.000000] Command line: root=bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M memblock=debug
<6>[    0.000000] BIOS-provided physical RAM map:
<6>[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
<6>[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
<6>[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
<6>[    0.000000]  BIOS-e820: 0000000000100000 - 000000001f800000 (usable)
<6>[    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
<6>[    0.000000] NX (Execute Disable) protection: active
<6>[    0.000000] DMI 2.4 present.
<7>[    0.000000] DMI: Xen HVM domU, BIOS 4.3.26502-20130204 02/04/2013
<7>[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
<7>[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
<6>[    0.000000] No AGP bridge found
<6>[    0.000000] last_pfn = 0x1f800 max_arch_pfn = 0x400000000
<7>[    0.000000] MTRR default type: write-back
<7>[    0.000000] MTRR fixed ranges enabled:
<7>[    0.000000]   00000-9FFFF write-back
<7>[    0.000000]   A0000-BFFFF write-combining
<7>[    0.000000]   C0000-FFFFF write-back
<7>[    0.000000] MTRR variable ranges enabled:
<7>[    0.000000]   0 base 00F0000000 mask FFF8000000 uncachable
<7>[    0.000000]   1 base 00F8000000 mask FFFC000000 uncachable
<7>[    0.000000]   2 disabled
<7>[    0.000000]   3 disabled
<7>[    0.000000]   4 disabled
<7>[    0.000000]   5 disabled
<7>[    0.000000]   6 disabled
<7>[    0.000000]   7 disabled
<6>[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
<6>[    0.000000] found SMP MP-table at [ffff8800000fbba0] fbba0
<6>[    0.000000]     memblock_x86_reserve_range: [0x000fbba0-0x000fbbaf]   * MP-table mpf
<6>[    0.000000]     memblock_x86_reserve_range: [0x000fbbb0-0x000fbc93]   * MP-table mpc
<6>[    0.000000]     memblock_x86_reserve_range: [0x01fd7000-0x01fd70d7]              BRK
<6>[    0.000000] MEMBLOCK configuration:
<6>[    0.000000]  memory size = 0x1f78e000
<6>[    0.000000]  memory.cnt  = 0x2
<6>[    0.000000]  memory[0x0]  [0x00000000010000-0x0000000009dfff], 0x8e000 bytes
<6>[    0.000000]  memory[0x1]  [0x00000000100000-0x0000001f7fffff], 0x1f700000 bytes
<6>[    0.000000]  reserved.cnt  = 0x3
<6>[    0.000000]  reserved[0x0]        [0x0000000009e000-0x000000000fffff], 0x62000 bytes
<6>[    0.000000]  reserved[0x1]        [0x00000001000000-0x00000001fd70d7], 0xfd70d8 bytes
<6>[    0.000000]  reserved[0x2]        [0x0000001f2d0000-0x0000001f7effff], 0x520000 bytes
<7>[    0.000000] initial memory mapped : 0 - 20000000
<6>[    0.000000]     memblock_x86_reserve_range: [0x00099000-0x0009dfff]       TRAMPOLINE
<7>[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480
<6>[    0.000000] init_memory_mapping: 0000000000000000-000000001f800000
<7>[    0.000000]  0000000000 - 001f800000 page 2M
<7>[    0.000000] kernel direct mapping tables up to 0x1f7fffff @ [mem 0x1f7fe000-0x1f7fffff]


root@satriani:~ # /usr/lib64/xen/bin/xenctx -C  -s /boot/System.map-3.0.51-0.7.9-default `xl domid sles11sp2_full_minimal_nfsroot_bug694863 2>&1`
rip: ffffffff812a9543 acpi_os_write_port+0xe
flags: 00000246 i z p
rsp: ffff880019629468
rax: 0000000000000091   rcx: 0000000000000001   rdx: 000000000000b044
rbx: 0000000000000000   rsi: 0000000000000091   rdi: 000000000000b044
rbp: 000000000000b044    r8: 0000000000000002    r9: ffffffff817b9a2f
r10: ffff88001ac20300   r11: ffffffff00000001   r12: 0000000000000008
r13: ffff880019629678   r14: ffffffff812c3144   r15: 0000000000000000
 cs: 0010        ss: 0018        ds: 0000        es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ ffff88001b000000/0000000000000000
Code (instr addr ffffffff812a9543)
eb fe 59 31 c0 5e c3 83 fa 08 89 f0 77 09 40 0f b6 c6 89 fa ee <eb> 1c 83 fa 10 77 09 0f b7 c6 89


Stack:
 ffffffff812c31d3 ffff880000000008 ffff880000000001 0000000000000000
 ffffffff0000b044 ffff8800196106a8 0000000000000000 0000000000000000
 000000000000b044 ffff880019610f60 ffff880019622150 ffff880019610f18
 ffffffff812babf1 ffff880019622150 ffffffff812c3144 0000000000000000

Call Trace:
  [<ffffffff812a9543>] acpi_os_write_port+0xe  <--
  [<ffffffff812c31d3>] acpi_ex_system_io_space_handler+0x8f
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812babf1>] acpi_ev_address_space_dispatch+0x1d5
  [<ffffffff812c3144>] acpi_ex_system_io_space_handler
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812c0158>] acpi_ex_access_region+0x118
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812c02b9>] acpi_ex_field_datum_io+0xf2
  [<0000000000000000>] irq_stack_union
  [<0000000000000008>] irq_stack_union+0x8
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c077f>] acpi_ex_write_with_update_rule+0x130
  [<0000000000000091>] irq_stack_union+0x91
  [<0000000000000091>] irq_stack_union+0x91
  [<0000000000000011>] irq_stack_union+0x11
  [<0000000000000008>] irq_stack_union+0x8
  [<00000000000000ff>] irq_stack_union+0xff
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c0979>] acpi_ex_insert_into_field+0x1ed
  [<0000000000000202>] irq_stack_union+0x202
  [<0000000000000000>] irq_stack_union
  [<ffffffff8113b8f2>] kmem_cache_alloc+0xe2
  [<0000000000000091>] irq_stack_union+0x91
  [<0000000000000011>] irq_stack_union+0x11
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000008>] irq_stack_union+0x8
  [<ffffffff812be963>] acpi_ex_write_data_to_field+0x277
  [<0000000000000000>] irq_stack_union
  [<0000000000000011>] irq_stack_union+0x11
  [<ffffffff812c350d>] acpi_ex_store_object_to_node+0x109
  [<0000000000000002>] irq_stack_union+0x2
  [<0000000000000000>] irq_stack_union
  [<0000000000000004>] irq_stack_union+0x4
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c11a9>] acpi_ex_opcode_1A_1T_1R+0x371
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000004>] irq_stack_union+0x4
  [<ffffffff812b62de>] acpi_ds_exec_end_op+0xec
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812ce047>] acpi_ps_parse_loop+0x32b
  [<000000000000000a>] irq_stack_union+0xa
  [<0000000000000009>] irq_stack_union+0x9
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812cce4e>] acpi_ps_parse_aml+0x105
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812ce7e6>] acpi_ps_execute_method+0x213
  [<ffffffff812c895d>] acpi_ns_evaluate+0x189
  [<0000000000000004>] irq_stack_union+0x4
  [<ffffffff812d1fed>] acpi_ut_evaluate_object+0x69
  [<0000000000000060>] irq_stack_union+0x60
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000060>] irq_stack_union+0x60
  [<ffffffff812d2258>] acpi_ut_execute_STA+0x24
  [<ffffffff812c9832>] acpi_get_object_info+0x167
  [<0000000000000006>] irq_stack_union+0x6
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c9858>] acpi_get_object_info+0x18d
  [<ffffffff812a9cdc>] acpi_os_wait_semaphore+0xce
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812acd13>] do_acpi_find_child+0x16
  [<0000000000000000>] irq_stack_union
  [<ffffffff812cadc5>] acpi_ns_walk_namespace+0xc4
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812accfd>] do_acpi_find_child
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812accfd>] do_acpi_find_child
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000006>] irq_stack_union+0x6
  [<ffffffff812c8079>] acpi_walk_namespace+0x80
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812accf3>] acpi_get_child+0x42
  [<0000000000000000>] irq_stack_union
  [<ffffffff81247f76>] kobject_add+0x46
  [<ffffffff81284368>] acpi_pci_find_device+0x28
  [<ffffffff812acbb0>] acpi_platform_notify+0xb9
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131aaa3>] device_add+0xe3
  [<ffffffff8126657d>] pci_bus_add_device+0x1d
  [<ffffffff812665ec>] pci_bus_add_devices+0x3c
  [<ffffffff812b0dec>] acpi_pci_root_start+0x14
  [<ffffffff812aceb7>] acpi_start_single_object+0x21
  [<0000000000000000>] irq_stack_union
  [<ffffffff812ad041>] acpi_device_probe+0xab
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131d23a>] really_probe+0x7a
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131d483>] driver_probe_device+0x63
  [<ffffffff8131d573>] __driver_attach+0x93
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131d4e0>] __driver_attach
  [<ffffffff8131c8c8>] bus_for_each_dev+0x58
  [<ffffffff8131c065>] bus_add_driver+0x155
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131dbc9>] driver_register+0x79
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff81c1c3ce>] acpi_pci_root_init
  [<0000000000000000>] irq_stack_union
  [<ffffffff81c1c3f1>] acpi_pci_root_init+0x23
  [<0000000000000000>] irq_stack_union
  [<ffffffff810001cb>] do_one_initcall+0x3b
  [<000000000000000f>] irq_stack_union+0xf
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff81be3893>] kernel_init+0x241
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8144db44>] kernel_thread_helper+0x4
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff81be3652>] kernel_init
  [<0000000000000000>] irq_stack_union
  [<ffffffff8144db40>] kernel_thread_helper
  [<0000000000000010>] irq_stack_union+0x10
  [<0000000000000202>] irq_stack_union+0x202
  [<0000000000000018>] irq_stack_union+0x18
rip: ffffffff8102a0b2 native_safe_halt+0x2
flags: 00000246 i z p
rsp: ffff8800196a3f10
rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
rbx: ffff8800196a2010   rsi: 0000000000000001   rdi: ffffffff81d29108
rbp: 0000000000000001    r8: 0000000000000000    r9: ffff88001974d600
r10: 0000000000000000   r11: ffffffff81047df0   r12: 0000000000000000
r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
 cs: 0010        ss: 0018        ds: 0000        es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ ffff88001b020000/0000000000000000
Code (instr addr ffffffff8102a0b2)
00 00 00 fb c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 fb f4 <c3> 66 66 66 66 2e 0f 1f 84 00 00


Stack:
 ffffffff8100ad45 0000000000000000 ffff8800196a2010 ffffffff81bc8d40
 ffffffff810020e6 0000000000000000 0000000000000000 0000000000000000
 0000000000000000 0000000000000000 0000000000000000 0000000000000000
 0000000000000000 0000000000000000 0000000000000000 0000000000000000

Call Trace:
  [<ffffffff8102a0b2>] native_safe_halt+0x2  <--
  [<ffffffff8100ad45>] default_idle+0x145
  [<0000000000000000>] irq_stack_union
  [<ffffffff810020e6>] cpu_idle+0x66
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
root@satriani:~ #

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:33:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:33: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 1U2O2L-0006ve-28; Mon, 04 Feb 2013 15:32:49 +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 1U2O2J-0006vS-1s
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:32:47 +0000
Received: from [85.158.143.35:36836] by server-1.bemta-4.messagelabs.com id
	42/26-08839-E94DF015; Mon, 04 Feb 2013 15:32:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359991666!13742213!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12738 invoked from network); 4 Feb 2013 15:27:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 15:27:46 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jorabe mo25) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 207719p14F3LSN ;
	Mon, 4 Feb 2013 16:27:39 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 60F621884C; Mon,  4 Feb 2013 16:27:39 +0100 (CET)
Date: Mon, 4 Feb 2013 16:27:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130204152739.GA20329@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>
	<20130204144424.GA18602@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130204144424.GA18602@aepfle.de>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Olaf Hering wrote:

> Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> are really gone.

With sles11 dom0+domU there are no more hpet1 messages when started from
xend.


With xl however I now get a hanging guest, which I did not see before this
patch. But this happens only if it is booted with quiet, with 'debug
ignore_loglevel' booting works fine.
Also xl list shows the domain in paused state?!

I will try once more with sles11 kernel, xl and the RTC patch reverted..

Olaf


xl dump-core shows just this in dmesg:

<6>[    0.000000] Initializing cgroup subsys cpu
<5>[    0.000000] Linux version 3.0.51-0.7.9-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0)
<6>[    0.000000] Command line: root=bax.arch.suse.de:/olaf_xenimages/bug694863/nfsroot console=ttyS0,115200 quiet log_buf_len=64M memblock=debug
<6>[    0.000000] BIOS-provided physical RAM map:
<6>[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
<6>[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
<6>[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
<6>[    0.000000]  BIOS-e820: 0000000000100000 - 000000001f800000 (usable)
<6>[    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
<6>[    0.000000] NX (Execute Disable) protection: active
<6>[    0.000000] DMI 2.4 present.
<7>[    0.000000] DMI: Xen HVM domU, BIOS 4.3.26502-20130204 02/04/2013
<7>[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
<7>[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
<6>[    0.000000] No AGP bridge found
<6>[    0.000000] last_pfn = 0x1f800 max_arch_pfn = 0x400000000
<7>[    0.000000] MTRR default type: write-back
<7>[    0.000000] MTRR fixed ranges enabled:
<7>[    0.000000]   00000-9FFFF write-back
<7>[    0.000000]   A0000-BFFFF write-combining
<7>[    0.000000]   C0000-FFFFF write-back
<7>[    0.000000] MTRR variable ranges enabled:
<7>[    0.000000]   0 base 00F0000000 mask FFF8000000 uncachable
<7>[    0.000000]   1 base 00F8000000 mask FFFC000000 uncachable
<7>[    0.000000]   2 disabled
<7>[    0.000000]   3 disabled
<7>[    0.000000]   4 disabled
<7>[    0.000000]   5 disabled
<7>[    0.000000]   6 disabled
<7>[    0.000000]   7 disabled
<6>[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
<6>[    0.000000] found SMP MP-table at [ffff8800000fbba0] fbba0
<6>[    0.000000]     memblock_x86_reserve_range: [0x000fbba0-0x000fbbaf]   * MP-table mpf
<6>[    0.000000]     memblock_x86_reserve_range: [0x000fbbb0-0x000fbc93]   * MP-table mpc
<6>[    0.000000]     memblock_x86_reserve_range: [0x01fd7000-0x01fd70d7]              BRK
<6>[    0.000000] MEMBLOCK configuration:
<6>[    0.000000]  memory size = 0x1f78e000
<6>[    0.000000]  memory.cnt  = 0x2
<6>[    0.000000]  memory[0x0]  [0x00000000010000-0x0000000009dfff], 0x8e000 bytes
<6>[    0.000000]  memory[0x1]  [0x00000000100000-0x0000001f7fffff], 0x1f700000 bytes
<6>[    0.000000]  reserved.cnt  = 0x3
<6>[    0.000000]  reserved[0x0]        [0x0000000009e000-0x000000000fffff], 0x62000 bytes
<6>[    0.000000]  reserved[0x1]        [0x00000001000000-0x00000001fd70d7], 0xfd70d8 bytes
<6>[    0.000000]  reserved[0x2]        [0x0000001f2d0000-0x0000001f7effff], 0x520000 bytes
<7>[    0.000000] initial memory mapped : 0 - 20000000
<6>[    0.000000]     memblock_x86_reserve_range: [0x00099000-0x0009dfff]       TRAMPOLINE
<7>[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480
<6>[    0.000000] init_memory_mapping: 0000000000000000-000000001f800000
<7>[    0.000000]  0000000000 - 001f800000 page 2M
<7>[    0.000000] kernel direct mapping tables up to 0x1f7fffff @ [mem 0x1f7fe000-0x1f7fffff]


root@satriani:~ # /usr/lib64/xen/bin/xenctx -C  -s /boot/System.map-3.0.51-0.7.9-default `xl domid sles11sp2_full_minimal_nfsroot_bug694863 2>&1`
rip: ffffffff812a9543 acpi_os_write_port+0xe
flags: 00000246 i z p
rsp: ffff880019629468
rax: 0000000000000091   rcx: 0000000000000001   rdx: 000000000000b044
rbx: 0000000000000000   rsi: 0000000000000091   rdi: 000000000000b044
rbp: 000000000000b044    r8: 0000000000000002    r9: ffffffff817b9a2f
r10: ffff88001ac20300   r11: ffffffff00000001   r12: 0000000000000008
r13: ffff880019629678   r14: ffffffff812c3144   r15: 0000000000000000
 cs: 0010        ss: 0018        ds: 0000        es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ ffff88001b000000/0000000000000000
Code (instr addr ffffffff812a9543)
eb fe 59 31 c0 5e c3 83 fa 08 89 f0 77 09 40 0f b6 c6 89 fa ee <eb> 1c 83 fa 10 77 09 0f b7 c6 89


Stack:
 ffffffff812c31d3 ffff880000000008 ffff880000000001 0000000000000000
 ffffffff0000b044 ffff8800196106a8 0000000000000000 0000000000000000
 000000000000b044 ffff880019610f60 ffff880019622150 ffff880019610f18
 ffffffff812babf1 ffff880019622150 ffffffff812c3144 0000000000000000

Call Trace:
  [<ffffffff812a9543>] acpi_os_write_port+0xe  <--
  [<ffffffff812c31d3>] acpi_ex_system_io_space_handler+0x8f
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812babf1>] acpi_ev_address_space_dispatch+0x1d5
  [<ffffffff812c3144>] acpi_ex_system_io_space_handler
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812c0158>] acpi_ex_access_region+0x118
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812c02b9>] acpi_ex_field_datum_io+0xf2
  [<0000000000000000>] irq_stack_union
  [<0000000000000008>] irq_stack_union+0x8
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c077f>] acpi_ex_write_with_update_rule+0x130
  [<0000000000000091>] irq_stack_union+0x91
  [<0000000000000091>] irq_stack_union+0x91
  [<0000000000000011>] irq_stack_union+0x11
  [<0000000000000008>] irq_stack_union+0x8
  [<00000000000000ff>] irq_stack_union+0xff
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c0979>] acpi_ex_insert_into_field+0x1ed
  [<0000000000000202>] irq_stack_union+0x202
  [<0000000000000000>] irq_stack_union
  [<ffffffff8113b8f2>] kmem_cache_alloc+0xe2
  [<0000000000000091>] irq_stack_union+0x91
  [<0000000000000011>] irq_stack_union+0x11
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000008>] irq_stack_union+0x8
  [<ffffffff812be963>] acpi_ex_write_data_to_field+0x277
  [<0000000000000000>] irq_stack_union
  [<0000000000000011>] irq_stack_union+0x11
  [<ffffffff812c350d>] acpi_ex_store_object_to_node+0x109
  [<0000000000000002>] irq_stack_union+0x2
  [<0000000000000000>] irq_stack_union
  [<0000000000000004>] irq_stack_union+0x4
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c11a9>] acpi_ex_opcode_1A_1T_1R+0x371
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000004>] irq_stack_union+0x4
  [<ffffffff812b62de>] acpi_ds_exec_end_op+0xec
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812ce047>] acpi_ps_parse_loop+0x32b
  [<000000000000000a>] irq_stack_union+0xa
  [<0000000000000009>] irq_stack_union+0x9
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812cce4e>] acpi_ps_parse_aml+0x105
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812ce7e6>] acpi_ps_execute_method+0x213
  [<ffffffff812c895d>] acpi_ns_evaluate+0x189
  [<0000000000000004>] irq_stack_union+0x4
  [<ffffffff812d1fed>] acpi_ut_evaluate_object+0x69
  [<0000000000000060>] irq_stack_union+0x60
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000060>] irq_stack_union+0x60
  [<ffffffff812d2258>] acpi_ut_execute_STA+0x24
  [<ffffffff812c9832>] acpi_get_object_info+0x167
  [<0000000000000006>] irq_stack_union+0x6
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812c9858>] acpi_get_object_info+0x18d
  [<ffffffff812a9cdc>] acpi_os_wait_semaphore+0xce
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<ffffffff812acd13>] do_acpi_find_child+0x16
  [<0000000000000000>] irq_stack_union
  [<ffffffff812cadc5>] acpi_ns_walk_namespace+0xc4
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812accfd>] do_acpi_find_child
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812accfd>] do_acpi_find_child
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000006>] irq_stack_union+0x6
  [<ffffffff812c8079>] acpi_walk_namespace+0x80
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff812accf3>] acpi_get_child+0x42
  [<0000000000000000>] irq_stack_union
  [<ffffffff81247f76>] kobject_add+0x46
  [<ffffffff81284368>] acpi_pci_find_device+0x28
  [<ffffffff812acbb0>] acpi_platform_notify+0xb9
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131aaa3>] device_add+0xe3
  [<ffffffff8126657d>] pci_bus_add_device+0x1d
  [<ffffffff812665ec>] pci_bus_add_devices+0x3c
  [<ffffffff812b0dec>] acpi_pci_root_start+0x14
  [<ffffffff812aceb7>] acpi_start_single_object+0x21
  [<0000000000000000>] irq_stack_union
  [<ffffffff812ad041>] acpi_device_probe+0xab
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131d23a>] really_probe+0x7a
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131d483>] driver_probe_device+0x63
  [<ffffffff8131d573>] __driver_attach+0x93
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131d4e0>] __driver_attach
  [<ffffffff8131c8c8>] bus_for_each_dev+0x58
  [<ffffffff8131c065>] bus_add_driver+0x155
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8131dbc9>] driver_register+0x79
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff81c1c3ce>] acpi_pci_root_init
  [<0000000000000000>] irq_stack_union
  [<ffffffff81c1c3f1>] acpi_pci_root_init+0x23
  [<0000000000000000>] irq_stack_union
  [<ffffffff810001cb>] do_one_initcall+0x3b
  [<000000000000000f>] irq_stack_union+0xf
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff81be3893>] kernel_init+0x241
  [<0000000000000000>] irq_stack_union
  [<0000000000000001>] irq_stack_union+0x1
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff8144db44>] kernel_thread_helper+0x4
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<ffffffff81be3652>] kernel_init
  [<0000000000000000>] irq_stack_union
  [<ffffffff8144db40>] kernel_thread_helper
  [<0000000000000010>] irq_stack_union+0x10
  [<0000000000000202>] irq_stack_union+0x202
  [<0000000000000018>] irq_stack_union+0x18
rip: ffffffff8102a0b2 native_safe_halt+0x2
flags: 00000246 i z p
rsp: ffff8800196a3f10
rax: 0000000000000000   rcx: 00000000ffffffff   rdx: 0000000000000000
rbx: ffff8800196a2010   rsi: 0000000000000001   rdi: ffffffff81d29108
rbp: 0000000000000001    r8: 0000000000000000    r9: ffff88001974d600
r10: 0000000000000000   r11: ffffffff81047df0   r12: 0000000000000000
r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
 cs: 0010        ss: 0018        ds: 0000        es: 0000
 fs: 0000 @ 0000000000000000
 gs: 0000 @ ffff88001b020000/0000000000000000
Code (instr addr ffffffff8102a0b2)
00 00 00 fb c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 fb f4 <c3> 66 66 66 66 2e 0f 1f 84 00 00


Stack:
 ffffffff8100ad45 0000000000000000 ffff8800196a2010 ffffffff81bc8d40
 ffffffff810020e6 0000000000000000 0000000000000000 0000000000000000
 0000000000000000 0000000000000000 0000000000000000 0000000000000000
 0000000000000000 0000000000000000 0000000000000000 0000000000000000

Call Trace:
  [<ffffffff8102a0b2>] native_safe_halt+0x2  <--
  [<ffffffff8100ad45>] default_idle+0x145
  [<0000000000000000>] irq_stack_union
  [<ffffffff810020e6>] cpu_idle+0x66
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
  [<0000000000000000>] irq_stack_union
root@satriani:~ #

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:37:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2O6D-00078K-Sd; Mon, 04 Feb 2013 15:36: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 1U2O6C-00078C-DJ
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 15:36:48 +0000
Received: from [85.158.139.211:17618] by server-15.bemta-5.messagelabs.com id
	35/9F-18914-F85DF015; Mon, 04 Feb 2013 15:36:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1359992207!20708273!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23806 invoked from network); 4 Feb 2013 15:36:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:36:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:36: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.297.1; Mon, 4 Feb 2013 15:36:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2O6A-0000Up-Pc; Mon, 04 Feb 2013 15:36:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2O6A-0004cs-Ll;
	Mon, 04 Feb 2013 15:36:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.54670.382472.124439@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 15:36:46 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <510FD84702000078000BB8F3@nat28.tlf.novell.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<510FD64202000078000BB8BC@nat28.tlf.novell.com>
	<1359989061.7743.59.camel@zakaz.uk.xensource.com>
	<510FD84702000078000BB8F3@nat28.tlf.novell.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>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> Okay - I'm certainly not opposed to a manual push.

Done.  Specifically, I have pushed d1bf3b21f783 to non-staging
xen-unstable.  The remaining backlog in staging will probably clear
soon too.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:37:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2O6D-00078K-Sd; Mon, 04 Feb 2013 15:36: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 1U2O6C-00078C-DJ
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 15:36:48 +0000
Received: from [85.158.139.211:17618] by server-15.bemta-5.messagelabs.com id
	35/9F-18914-F85DF015; Mon, 04 Feb 2013 15:36:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1359992207!20708273!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23806 invoked from network); 4 Feb 2013 15:36:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:36:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:36: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.297.1; Mon, 4 Feb 2013 15:36:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2O6A-0000Up-Pc; Mon, 04 Feb 2013 15:36:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2O6A-0004cs-Ll;
	Mon, 04 Feb 2013 15:36:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20751.54670.382472.124439@mariner.uk.xensource.com>
Date: Mon, 4 Feb 2013 15:36:46 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <510FD84702000078000BB8F3@nat28.tlf.novell.com>
References: <osstest-15401-mainreport@xen.org>
	<20747.43677.802351.664975@mariner.uk.xensource.com>
	<1359975977.5281.58.camel@zakaz.uk.xensource.com>
	<510FA6ED02000078000BB742@nat28.tlf.novell.com>
	<1359976933.5281.68.camel@zakaz.uk.xensource.com>
	<20751.50218.614149.355136@mariner.uk.xensource.com>
	<510FD64202000078000BB8BC@nat28.tlf.novell.com>
	<1359989061.7743.59.camel@zakaz.uk.xensource.com>
	<510FD84702000078000BB8F3@nat28.tlf.novell.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>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15401: 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

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 15401: regressions - FAIL"):
> Okay - I'm certainly not opposed to a manual push.

Done.  Specifically, I have pushed d1bf3b21f783 to non-staging
xen-unstable.  The remaining backlog in staging will probably clear
soon too.

Ian.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:39:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:39: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 1U2O8U-0007FW-E6; Mon, 04 Feb 2013 15:39: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 1U2O8S-0007FQ-Rm
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:39:09 +0000
Received: from [85.158.139.211:49450] by server-8.bemta-5.messagelabs.com id
	35/AD-19075-B16DF015; Mon, 04 Feb 2013 15:39:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1359992347!21002320!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13563 invoked from network); 4 Feb 2013 15:39:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:39:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:39: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.297.1; Mon, 4 Feb 2013
	15:39:07 +0000
Message-ID: <1359992345.7743.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andia@pereslavl.ru" <andia@pereslavl.ru>
Date: Mon, 4 Feb 2013 15:39:05 +0000
In-Reply-To: <1359962676.5263.71.camel@connect.botik.ru>
References: <1359962676.5263.71.camel@connect.botik.ru>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful 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 Mon, 2013-02-04 at 07:24 +0000, Elena V. Titova wrote:
> Hello.
> 
> We use debian sarge, linux-image-3.2.0-3-amd64 and xen-4.1.3 on our
> servers.

Do you really mean Sarge? Or did you mean Squeeze or Wheezy? Those
kernel and Xen versions look like Wheezy versions but perhaps you are
using backports.

> When a live migration is run the guest domain may not resume on a
> destination
> host and is destroyed on a source host.
> This patch fixes it by resuming the guest domain on a source host when a
> start of
> the guest domain was failed.

xend is supposed to be in maintenance mode so I'm not too sure about
this sort of change.

In particular I'm worried that it might break migration from Xen version
N to version N+1 which is something we try and support.

BTW the xl toolstack already has this functionality so another option
for you may be to switch to that.

> git diff tools/python/xen/xend/XendCheckpoint.py
> diff --git a/tools/python/xen/xend/XendCheckpoint.py
> b/tools/python/xen/xend/XendCheckpoint.py
> index fa09757..6b8765f 100644
> --- a/tools/python/xen/xend/XendCheckpoint.py
> +++ b/tools/python/xen/xend/XendCheckpoint.py
> @@ -163,12 +163,16 @@ def save(fd, dominfo, network, live, dst,
> checkpoint=False, node=-1,sock=None):
>              dominfo.resumeDomain()
>          else:
>              if live and sock != None:

This same class of errors isn't possible for non-live?

> +                status = os.read(fd, 64)

The written strings are 7 or 4 bytes, it would be better to choose a
fixed length for all writes and the read I think. That might mean
padding the fail message. Also these protocol strings should be defined
as constants rather than open coded.

Even with that addressed I don't really feel confident enough about xend
internals to Ack a patch like this.

>                  try:
>                      sock.shutdown(2)
>                  except:
>                      pass
>                  sock.close()
> 
> +                if status == "FAIL":
> +                    raise XendError("Restore failed")
> +
>              dominfo.destroy()
>              dominfo.testDeviceComplete()
>          try:
> @@ -351,8 +355,14 @@ def restore(xd, fd, dominfo = None, paused = False,
> relocating = False):
>          if not paused:
>              dominfo.unpause()
> 
> +        if relocating:
> +            os.write(fd, "SUCCESS")
> +
>          return dominfo
>      except Exception, exn:
> +        if relocating:
> +            os.write(fd, "FAIL")
> +
>          dominfo.destroy()
>          log.exception(exn)
>          raise exn 
> 
> --
> Elena Titova
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 15:39:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:39: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 1U2O8U-0007FW-E6; Mon, 04 Feb 2013 15:39: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 1U2O8S-0007FQ-Rm
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:39:09 +0000
Received: from [85.158.139.211:49450] by server-8.bemta-5.messagelabs.com id
	35/AD-19075-B16DF015; Mon, 04 Feb 2013 15:39:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1359992347!21002320!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13563 invoked from network); 4 Feb 2013 15:39:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:39:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:39: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.297.1; Mon, 4 Feb 2013
	15:39:07 +0000
Message-ID: <1359992345.7743.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andia@pereslavl.ru" <andia@pereslavl.ru>
Date: Mon, 4 Feb 2013 15:39:05 +0000
In-Reply-To: <1359962676.5263.71.camel@connect.botik.ru>
References: <1359962676.5263.71.camel@connect.botik.ru>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful 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 Mon, 2013-02-04 at 07:24 +0000, Elena V. Titova wrote:
> Hello.
> 
> We use debian sarge, linux-image-3.2.0-3-amd64 and xen-4.1.3 on our
> servers.

Do you really mean Sarge? Or did you mean Squeeze or Wheezy? Those
kernel and Xen versions look like Wheezy versions but perhaps you are
using backports.

> When a live migration is run the guest domain may not resume on a
> destination
> host and is destroyed on a source host.
> This patch fixes it by resuming the guest domain on a source host when a
> start of
> the guest domain was failed.

xend is supposed to be in maintenance mode so I'm not too sure about
this sort of change.

In particular I'm worried that it might break migration from Xen version
N to version N+1 which is something we try and support.

BTW the xl toolstack already has this functionality so another option
for you may be to switch to that.

> git diff tools/python/xen/xend/XendCheckpoint.py
> diff --git a/tools/python/xen/xend/XendCheckpoint.py
> b/tools/python/xen/xend/XendCheckpoint.py
> index fa09757..6b8765f 100644
> --- a/tools/python/xen/xend/XendCheckpoint.py
> +++ b/tools/python/xen/xend/XendCheckpoint.py
> @@ -163,12 +163,16 @@ def save(fd, dominfo, network, live, dst,
> checkpoint=False, node=-1,sock=None):
>              dominfo.resumeDomain()
>          else:
>              if live and sock != None:

This same class of errors isn't possible for non-live?

> +                status = os.read(fd, 64)

The written strings are 7 or 4 bytes, it would be better to choose a
fixed length for all writes and the read I think. That might mean
padding the fail message. Also these protocol strings should be defined
as constants rather than open coded.

Even with that addressed I don't really feel confident enough about xend
internals to Ack a patch like this.

>                  try:
>                      sock.shutdown(2)
>                  except:
>                      pass
>                  sock.close()
> 
> +                if status == "FAIL":
> +                    raise XendError("Restore failed")
> +
>              dominfo.destroy()
>              dominfo.testDeviceComplete()
>          try:
> @@ -351,8 +355,14 @@ def restore(xd, fd, dominfo = None, paused = False,
> relocating = False):
>          if not paused:
>              dominfo.unpause()
> 
> +        if relocating:
> +            os.write(fd, "SUCCESS")
> +
>          return dominfo
>      except Exception, exn:
> +        if relocating:
> +            os.write(fd, "FAIL")
> +
>          dominfo.destroy()
>          log.exception(exn)
>          raise exn 
> 
> --
> Elena Titova
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 15:43:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:43: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 1U2OCH-0007Se-3z; Mon, 04 Feb 2013 15:43: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 1U2OCF-0007SZ-I1
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:43:03 +0000
Received: from [85.158.143.99:26337] by server-3.bemta-4.messagelabs.com id
	36/07-08920-607DF015; Mon, 04 Feb 2013 15:43:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1359992582!24389551!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17988 invoked from network); 4 Feb 2013 15:43:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125681"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:43: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.297.1; Mon, 4 Feb 2013
	15:43:02 +0000
Message-ID: <1359992581.7743.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 15:43:01 +0000
In-Reply-To: <20130204152739.GA20329@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>	<20130204144424.GA18602@aepfle.de>
	<20130204152739.GA20329@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 15:27 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Olaf Hering wrote:
> 
> > Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> > are really gone.
> 
> With sles11 dom0+domU there are no more hpet1 messages when started from
> xend.
> 
> 
> With xl however I now get a hanging guest, which I did not see before this
> patch. But this happens only if it is booted with quiet, with 'debug
> ignore_loglevel' booting works fine.
> Also xl list shows the domain in paused state?!

[...]
>   [<ffffffff812a9543>] acpi_os_write_port+0xe  <--

I expect this will have trapped to qemu, which would explain why the
vcpu is paused, but not why qemu appears to not be responding. Maybe
something in the qemu logs will shed some light?

>   [<ffffffff812c31d3>] acpi_ex_system_io_space_handler+0x8f
>   [<0000000000000000>] irq_stack_union
>   [<0000000000000000>] irq_stack_union
>   [<0000000000000000>] irq_stack_union
>   [<ffffffff812babf1>] acpi_ev_address_space_dispatch+0x1d5
>   [<ffffffff812c3144>] acpi_ex_system_io_space_handler
[...]



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:43:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15:43: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 1U2OCH-0007Se-3z; Mon, 04 Feb 2013 15:43: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 1U2OCF-0007SZ-I1
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:43:03 +0000
Received: from [85.158.143.99:26337] by server-3.bemta-4.messagelabs.com id
	36/07-08920-607DF015; Mon, 04 Feb 2013 15:43:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1359992582!24389551!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17988 invoked from network); 4 Feb 2013 15:43:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1125681"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:43: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.297.1; Mon, 4 Feb 2013
	15:43:02 +0000
Message-ID: <1359992581.7743.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 15:43:01 +0000
In-Reply-To: <20130204152739.GA20329@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>	<20130204144424.GA18602@aepfle.de>
	<20130204152739.GA20329@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 15:27 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Olaf Hering wrote:
> 
> > Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> > are really gone.
> 
> With sles11 dom0+domU there are no more hpet1 messages when started from
> xend.
> 
> 
> With xl however I now get a hanging guest, which I did not see before this
> patch. But this happens only if it is booted with quiet, with 'debug
> ignore_loglevel' booting works fine.
> Also xl list shows the domain in paused state?!

[...]
>   [<ffffffff812a9543>] acpi_os_write_port+0xe  <--

I expect this will have trapped to qemu, which would explain why the
vcpu is paused, but not why qemu appears to not be responding. Maybe
something in the qemu logs will shed some light?

>   [<ffffffff812c31d3>] acpi_ex_system_io_space_handler+0x8f
>   [<0000000000000000>] irq_stack_union
>   [<0000000000000000>] irq_stack_union
>   [<0000000000000000>] irq_stack_union
>   [<ffffffff812babf1>] acpi_ev_address_space_dispatch+0x1d5
>   [<ffffffff812c3144>] acpi_ex_system_io_space_handler
[...]



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:45:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2OE1-0008SF-I5; Mon, 04 Feb 2013 15:44:53 +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 1U2ODz-0008LO-6V
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:44:51 +0000
Received: from [85.158.138.51:46893] by server-11.bemta-3.messagelabs.com id
	14/38-10249-277DF015; Mon, 04 Feb 2013 15:44:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1359992689!22812214!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1719 invoked from network); 4 Feb 2013 15:44:49 -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; 4 Feb 2013 15:44:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 15:44:48 +0000
Message-Id: <510FE57D02000078000BB983@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 15:44:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
	<510F8FF502000078000BB69C@nat28.tlf.novell.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D45835D@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835D@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 16:29, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> On Mon, 2013-02-04 at 09:39 +0000, Jan Beulich wrote:
>> >>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
>> > +ifeq ($(coverage),y)
>> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
>> > +endif
>> 
>> For one - isn't simply using $(obj-y) here sufficient (i.e. without the
>> $(filter-out ...))?
>> 
>> And second, I would thing this then ought to become a single line:
>> 
>> $(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
>> 
> 
> Yes, it works fine and seems to compile all proper files but I don't
> understand why.
> What's the difference between $(obj-bin-y) and $(obj-y) ??

The former is the set of all .init.o files, which (when building with
clang instead of gcc) must not undergo certain transformations
(and aren't worth it, as init-time only code isn't really performance
critical).

>> > +
>> > +void init_coverage(void)
>> 
>> __init
>> 
> 
> I removed from previous and put in the header as suggestion.

Not sure what you mean here, but just in case - __init
annotations do specifically not belong on declarations, but
only on definitions.

>> > +#if BITS_PER_LONG >= 64
>> > +typedef long gcov_type;
>> > +#else
>> > +typedef long long gcov_type;
>> > +#endif
>> 
>> What's this???
>> 
> 
> This came from Linux, probably for Xen a simple
> 
> typedef long gcov_type
> 
> is ok.

No. Your goal - just to reiterate - must be not to use types the
size of which depends on the guest word size.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:45:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2OE1-0008SF-I5; Mon, 04 Feb 2013 15:44:53 +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 1U2ODz-0008LO-6V
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:44:51 +0000
Received: from [85.158.138.51:46893] by server-11.bemta-3.messagelabs.com id
	14/38-10249-277DF015; Mon, 04 Feb 2013 15:44:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1359992689!22812214!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1719 invoked from network); 4 Feb 2013 15:44:49 -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; 4 Feb 2013 15:44:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 15:44:48 +0000
Message-Id: <510FE57D02000078000BB983@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 15:44:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1359730103-9474-1-git-send-email-frediano.ziglio@citrix.com>
	<1359730103-9474-3-git-send-email-frediano.ziglio@citrix.com>
	<510F8FF502000078000BB69C@nat28.tlf.novell.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D45835D@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835D@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 16:29, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> On Mon, 2013-02-04 at 09:39 +0000, Jan Beulich wrote:
>> >>> On 01.02.13 at 15:48, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
>> > +ifeq ($(coverage),y)
>> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
>> > +endif
>> 
>> For one - isn't simply using $(obj-y) here sufficient (i.e. without the
>> $(filter-out ...))?
>> 
>> And second, I would thing this then ought to become a single line:
>> 
>> $(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
>> 
> 
> Yes, it works fine and seems to compile all proper files but I don't
> understand why.
> What's the difference between $(obj-bin-y) and $(obj-y) ??

The former is the set of all .init.o files, which (when building with
clang instead of gcc) must not undergo certain transformations
(and aren't worth it, as init-time only code isn't really performance
critical).

>> > +
>> > +void init_coverage(void)
>> 
>> __init
>> 
> 
> I removed from previous and put in the header as suggestion.

Not sure what you mean here, but just in case - __init
annotations do specifically not belong on declarations, but
only on definitions.

>> > +#if BITS_PER_LONG >= 64
>> > +typedef long gcov_type;
>> > +#else
>> > +typedef long long gcov_type;
>> > +#endif
>> 
>> What's this???
>> 
> 
> This came from Linux, probably for Xen a simple
> 
> typedef long gcov_type
> 
> is ok.

No. Your goal - just to reiterate - must be not to use types the
size of which depends on the guest word size.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:51:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2OK7-00019b-Ts; Mon, 04 Feb 2013 15:51:11 +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 1U2OK6-00019S-FI
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:51:10 +0000
Received: from [193.109.254.147:19645] by server-4.bemta-14.messagelabs.com id
	3D/86-20719-DE8DF015; Mon, 04 Feb 2013 15:51:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1359993065!1952291!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 4 Feb 2013 15:51:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 15:51:06 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jorabe mo18) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 507575p14FTnLy ;
	Mon, 4 Feb 2013 16:51:00 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 05B801884C; Mon,  4 Feb 2013 16:50:59 +0100 (CET)
Date: Mon, 4 Feb 2013 16:50:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204155059.GA21493@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>
	<20130204144424.GA18602@aepfle.de>
	<20130204152739.GA20329@aepfle.de>
	<1359992581.7743.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359992581.7743.72.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Mon, 2013-02-04 at 15:27 +0000, Olaf Hering wrote:
> > On Mon, Feb 04, Olaf Hering wrote:
> > 
> > > Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> > > are really gone.
> > 
> > With sles11 dom0+domU there are no more hpet1 messages when started from
> > xend.
> > 
> > 
> > With xl however I now get a hanging guest, which I did not see before this
> > patch. But this happens only if it is booted with quiet, with 'debug
> > ignore_loglevel' booting works fine.
> > Also xl list shows the domain in paused state?!
> 
> [...]
> >   [<ffffffff812a9543>] acpi_os_write_port+0xe  <--
> 
> I expect this will have trapped to qemu, which would explain why the
> vcpu is paused, but not why qemu appears to not be responding. Maybe
> something in the qemu logs will shed some light?

I was running xenctx in another window, and it leads to this sort of
hang. Without the xenctx monitoring booting works fine.

watch -n 0,1 '/usr/lib64/xen/bin/xenctx -C -s /boot/System.map-3.0.51-0.7.9-default \
        `xl domid sles11sp2_full_minimal_nfsroot_bug694863 2>&1` 2>&1'

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:51:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2OK7-00019b-Ts; Mon, 04 Feb 2013 15:51:11 +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 1U2OK6-00019S-FI
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:51:10 +0000
Received: from [193.109.254.147:19645] by server-4.bemta-14.messagelabs.com id
	3D/86-20719-DE8DF015; Mon, 04 Feb 2013 15:51:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1359993065!1952291!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODAzMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 4 Feb 2013 15:51:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Feb 2013 15:51:06 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (jorabe mo18) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 507575p14FTnLy ;
	Mon, 4 Feb 2013 16:51:00 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 05B801884C; Mon,  4 Feb 2013 16:50:59 +0100 (CET)
Date: Mon, 4 Feb 2013 16:50:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204155059.GA21493@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de>
	<20130204144424.GA18602@aepfle.de>
	<20130204152739.GA20329@aepfle.de>
	<1359992581.7743.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359992581.7743.72.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Mon, 2013-02-04 at 15:27 +0000, Olaf Hering wrote:
> > On Mon, Feb 04, Olaf Hering wrote:
> > 
> > > Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> > > are really gone.
> > 
> > With sles11 dom0+domU there are no more hpet1 messages when started from
> > xend.
> > 
> > 
> > With xl however I now get a hanging guest, which I did not see before this
> > patch. But this happens only if it is booted with quiet, with 'debug
> > ignore_loglevel' booting works fine.
> > Also xl list shows the domain in paused state?!
> 
> [...]
> >   [<ffffffff812a9543>] acpi_os_write_port+0xe  <--
> 
> I expect this will have trapped to qemu, which would explain why the
> vcpu is paused, but not why qemu appears to not be responding. Maybe
> something in the qemu logs will shed some light?

I was running xenctx in another window, and it leads to this sort of
hang. Without the xenctx monitoring booting works fine.

watch -n 0,1 '/usr/lib64/xen/bin/xenctx -C -s /boot/System.map-3.0.51-0.7.9-default \
        `xl domid sles11sp2_full_minimal_nfsroot_bug694863 2>&1` 2>&1'

Olaf

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:54:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2OMl-0001Kt-IV; Mon, 04 Feb 2013 15:53: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 1U2OMj-0001Kj-Hn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:53:53 +0000
Received: from [85.158.143.99:60509] by server-3.bemta-4.messagelabs.com id
	31/35-08920-099DF015; Mon, 04 Feb 2013 15:53:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1359993229!27285929!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27320 invoked from network); 4 Feb 2013 15:53:50 -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; 4 Feb 2013 15:53:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 15:53:49 +0000
Message-Id: <510FE79902000078000BB9AE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 15:53:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part76462599.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation 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>
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.

--=__Part76462599.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- only call check_update_timer() on REG_B writes when SET changes
- only call alarm_timer_update() on REG_B writes when relevant bits
  change
- instead properly handle AF and PF when the guest is not also setting
  AIE/PIE respectively (for UF this was already the case, only a
  comment was slightly inaccurate), including calling the respective
  update functions upon REG_C reads

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
---
v2: This is the (fixed) remaining part of a similarly named patch sent
    about half a year ago. The originally missing piece are the added
    calls from the REG_C read code (which back then I had taken note of
    only as being a possible future enhancement).

--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState *s)
     hvm_isa_irq_assert(d, RTC_IRQ);
 }
=20
-static void rtc_periodic_cb(struct vcpu *v, void *opaque)
+void rtc_periodic_interrupt(void *opaque)
 {
     RTCState *s =3D opaque;
=20
     spin_lock(&s->lock);
-    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF | RTC_IRQF;
+    if ( s->hw.cmos_data[RTC_REG_C] & RTC_PF )
+        destroy_periodic_time(&s->pt);
+    else
+    {
+        s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;
+        if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
+            rtc_toggle_irq(s);
+    }
     spin_unlock(&s->lock);
 }
=20
@@ -91,8 +98,7 @@ static void rtc_timer_update(RTCState *s
         {
             period =3D 1 << (period_code - 1); /* period in 32 Khz cycles =
*/
             period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns =
*/
-            create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
-                                 rtc_periodic_cb, s);
+            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, =
NULL, s);
             break;
         }
         /* fall through */
@@ -120,7 +126,7 @@ static void check_update_timer(RTCState=20
         guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;
         if (guest_usec >=3D (USEC_PER_SEC - 244))
         {
-            /* RTC is in update cycle when enabling UIE */
+            /* RTC is in update cycle */
             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;
             next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC=
;
             expire_time =3D NOW() + next_update_time;
@@ -188,7 +194,7 @@ static void alarm_timer_update(RTCState=20
=20
     stop_timer(&s->alarm_timer);
=20
-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
+    if (!(s->hw.cmos_data[RTC_REG_C] & RTC_AF) &&
             !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
     {
         s->current_tm =3D gmtime(get_localtime(d));
@@ -455,8 +461,10 @@ static int rtc_ioport_write(void *opaque
                 break;
             }
         s->hw.cmos_data[RTC_REG_B] =3D data;
-        check_update_timer(s);
-        alarm_timer_update(s);
+        if ( (data ^ orig) & RTC_SET )
+            check_update_timer(s);
+        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
+            alarm_timer_update(s);
         break;
     case RTC_REG_C:
     case RTC_REG_D:
@@ -610,6 +618,8 @@ static uint32_t rtc_ioport_read(RTCState
         hvm_isa_irq_deassert(vrtc_domain(s), RTC_IRQ);
         s->hw.cmos_data[RTC_REG_C] =3D 0x00;
         check_update_timer(s);
+        alarm_timer_update(s);
+        rtc_timer_update(s);
         break;
     default:
         ret =3D s->hw.cmos_data[s->hw.cmos_index];
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -22,6 +22,7 @@
 #include <asm/hvm/vpt.h>
 #include <asm/event.h>
 #include <asm/apic.h>
+#include <asm/mc146818rtc.h>
=20
 #define mode_is(d, name) \
     ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##nam=
e)
@@ -218,6 +219,7 @@ int pt_update_irq(struct vcpu *v)
     struct periodic_time *pt, *temp, *earliest_pt =3D NULL;
     uint64_t max_lag =3D -1ULL;
     int irq, is_lapic;
+    void *pt_priv;
=20
     spin_lock(&v->arch.hvm_vcpu.tm_lock);
=20
@@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu *v)
     earliest_pt->irq_issued =3D 1;
     irq =3D earliest_pt->irq;
     is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);
+    pt_priv =3D earliest_pt->priv;
=20
     spin_unlock(&v->arch.hvm_vcpu.tm_lock);
=20
     if ( is_lapic )
-    {
         vlapic_set_irq(vcpu_vlapic(v), irq, 0);
-    }
+    else if ( irq =3D=3D RTC_IRQ && pt_priv )
+        rtc_periodic_interrupt(pt_priv);
     else
     {
         hvm_isa_irq_deassert(v->domain, irq);
--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
 void rtc_deinit(struct domain *d);
 void rtc_reset(struct domain *d);
 void rtc_update_clock(struct domain *d);
+void rtc_periodic_interrupt(void *);
=20
 void pmtimer_init(struct vcpu *v);
 void pmtimer_deinit(struct domain *d);



--=__Part76462599.1__=
Content-Type: text/plain; name="x86-HVM-RTC.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-RTC.patch"

x86/HVM: assorted RTC emulation adjustments=0A=0A- only call check_update_t=
imer() on REG_B writes when SET changes=0A- only call alarm_timer_update() =
on REG_B writes when relevant bits=0A  change=0A- instead properly handle =
AF and PF when the guest is not also setting=0A  AIE/PIE respectively (for =
UF this was already the case, only a=0A  comment was slightly inaccurate), =
including calling the respective=0A  update functions upon REG_C =
reads=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: =
Olaf Hering <olaf@aepfle.de>=0A---=0Av2: This is the (fixed) remaining =
part of a similarly named patch sent=0A    about half a year ago. The =
originally missing piece are the added=0A    calls from the REG_C read =
code (which back then I had taken note of=0A    only as being a possible =
future enhancement).=0A=0A--- a/xen/arch/x86/hvm/rtc.c=0A+++ b/xen/arch/x86=
/hvm/rtc.c=0A@@ -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState =
*s)=0A     hvm_isa_irq_assert(d, RTC_IRQ);=0A }=0A =0A-static void =
rtc_periodic_cb(struct vcpu *v, void *opaque)=0A+void rtc_periodic_interrup=
t(void *opaque)=0A {=0A     RTCState *s =3D opaque;=0A =0A     spin_lock(&s=
->lock);=0A-    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF | RTC_IRQF;=0A+    =
if ( s->hw.cmos_data[RTC_REG_C] & RTC_PF )=0A+        destroy_periodic_time=
(&s->pt);=0A+    else=0A+    {=0A+        s->hw.cmos_data[RTC_REG_C] |=3D =
RTC_PF;=0A+        if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )=0A+         =
   rtc_toggle_irq(s);=0A+    }=0A     spin_unlock(&s->lock);=0A }=0A =0A@@ =
-91,8 +98,7 @@ static void rtc_timer_update(RTCState *s=0A         {=0A    =
         period =3D 1 << (period_code - 1); /* period in 32 Khz cycles =
*/=0A             period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* =
in ns */=0A-            create_periodic_time(v, &s->pt, period, period, =
RTC_IRQ,=0A-                                 rtc_periodic_cb, s);=0A+      =
      create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL, =
s);=0A             break;=0A         }=0A         /* fall through */=0A@@ =
-120,7 +126,7 @@ static void check_update_timer(RTCState =0A         =
guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;=0A         if (guest_use=
c >=3D (USEC_PER_SEC - 244))=0A         {=0A-            /* RTC is in =
update cycle when enabling UIE */=0A+            /* RTC is in update cycle =
*/=0A             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;=0A             =
next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC;=0A         =
    expire_time =3D NOW() + next_update_time;=0A@@ -188,7 +194,7 @@ static =
void alarm_timer_update(RTCState =0A =0A     stop_timer(&s->alarm_timer);=
=0A =0A-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&=0A+    if =
(!(s->hw.cmos_data[RTC_REG_C] & RTC_AF) &&=0A             !(s->hw.cmos_data=
[RTC_REG_B] & RTC_SET))=0A     {=0A         s->current_tm =3D gmtime(get_lo=
caltime(d));=0A@@ -455,8 +461,10 @@ static int rtc_ioport_write(void =
*opaque=0A                 break;=0A             }=0A         s->hw.cmos_da=
ta[RTC_REG_B] =3D data;=0A-        check_update_timer(s);=0A-        =
alarm_timer_update(s);=0A+        if ( (data ^ orig) & RTC_SET )=0A+       =
     check_update_timer(s);=0A+        if ( (data ^ orig) & (RTC_24H | =
RTC_DM_BINARY | RTC_SET) )=0A+            alarm_timer_update(s);=0A        =
 break;=0A     case RTC_REG_C:=0A     case RTC_REG_D:=0A@@ -610,6 +618,8 =
@@ static uint32_t rtc_ioport_read(RTCState=0A         hvm_isa_irq_deassert=
(vrtc_domain(s), RTC_IRQ);=0A         s->hw.cmos_data[RTC_REG_C] =3D =
0x00;=0A         check_update_timer(s);=0A+        alarm_timer_update(s);=
=0A+        rtc_timer_update(s);=0A         break;=0A     default:=0A      =
   ret =3D s->hw.cmos_data[s->hw.cmos_index];=0A--- a/xen/arch/x86/hvm/vpt.=
c=0A+++ b/xen/arch/x86/hvm/vpt.c=0A@@ -22,6 +22,7 @@=0A #include <asm/hvm/v=
pt.h>=0A #include <asm/event.h>=0A #include <asm/apic.h>=0A+#include =
<asm/mc146818rtc.h>=0A =0A #define mode_is(d, name) \=0A     ((d)->arch.hvm=
_domain.params[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##name)=0A@@ -218,6 =
+219,7 @@ int pt_update_irq(struct vcpu *v)=0A     struct periodic_time =
*pt, *temp, *earliest_pt =3D NULL;=0A     uint64_t max_lag =3D -1ULL;=0A   =
  int irq, is_lapic;=0A+    void *pt_priv;=0A =0A     spin_lock(&v->arch.hv=
m_vcpu.tm_lock);=0A =0A@@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu =
*v)=0A     earliest_pt->irq_issued =3D 1;=0A     irq =3D earliest_pt->irq;=
=0A     is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);=0A+    =
pt_priv =3D earliest_pt->priv;=0A =0A     spin_unlock(&v->arch.hvm_vcpu.tm_=
lock);=0A =0A     if ( is_lapic )=0A-    {=0A         vlapic_set_irq(vcpu_v=
lapic(v), irq, 0);=0A-    }=0A+    else if ( irq =3D=3D RTC_IRQ && pt_priv =
)=0A+        rtc_periodic_interrupt(pt_priv);=0A     else=0A     {=0A      =
   hvm_isa_irq_deassert(v->domain, irq);=0A--- a/xen/include/asm-x86/hvm/vp=
t.h=0A+++ b/xen/include/asm-x86/hvm/vpt.h=0A@@ -181,6 +181,7 @@ void =
rtc_migrate_timers(struct vcpu *v);=0A void rtc_deinit(struct domain =
*d);=0A void rtc_reset(struct domain *d);=0A void rtc_update_clock(struct =
domain *d);=0A+void rtc_periodic_interrupt(void *);=0A =0A void pmtimer_ini=
t(struct vcpu *v);=0A void pmtimer_deinit(struct domain *d);=0A
--=__Part76462599.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

--=__Part76462599.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 04 15:54:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 15: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 1U2OMl-0001Kt-IV; Mon, 04 Feb 2013 15:53: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 1U2OMj-0001Kj-Hn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:53:53 +0000
Received: from [85.158.143.99:60509] by server-3.bemta-4.messagelabs.com id
	31/35-08920-099DF015; Mon, 04 Feb 2013 15:53:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1359993229!27285929!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27320 invoked from network); 4 Feb 2013 15:53:50 -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; 4 Feb 2013 15:53:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 15:53:49 +0000
Message-Id: <510FE79902000078000BB9AE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 15:53:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part76462599.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation 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>
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.

--=__Part76462599.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- only call check_update_timer() on REG_B writes when SET changes
- only call alarm_timer_update() on REG_B writes when relevant bits
  change
- instead properly handle AF and PF when the guest is not also setting
  AIE/PIE respectively (for UF this was already the case, only a
  comment was slightly inaccurate), including calling the respective
  update functions upon REG_C reads

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
---
v2: This is the (fixed) remaining part of a similarly named patch sent
    about half a year ago. The originally missing piece are the added
    calls from the REG_C read code (which back then I had taken note of
    only as being a possible future enhancement).

--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState *s)
     hvm_isa_irq_assert(d, RTC_IRQ);
 }
=20
-static void rtc_periodic_cb(struct vcpu *v, void *opaque)
+void rtc_periodic_interrupt(void *opaque)
 {
     RTCState *s =3D opaque;
=20
     spin_lock(&s->lock);
-    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF | RTC_IRQF;
+    if ( s->hw.cmos_data[RTC_REG_C] & RTC_PF )
+        destroy_periodic_time(&s->pt);
+    else
+    {
+        s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;
+        if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
+            rtc_toggle_irq(s);
+    }
     spin_unlock(&s->lock);
 }
=20
@@ -91,8 +98,7 @@ static void rtc_timer_update(RTCState *s
         {
             period =3D 1 << (period_code - 1); /* period in 32 Khz cycles =
*/
             period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns =
*/
-            create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
-                                 rtc_periodic_cb, s);
+            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, =
NULL, s);
             break;
         }
         /* fall through */
@@ -120,7 +126,7 @@ static void check_update_timer(RTCState=20
         guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;
         if (guest_usec >=3D (USEC_PER_SEC - 244))
         {
-            /* RTC is in update cycle when enabling UIE */
+            /* RTC is in update cycle */
             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;
             next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC=
;
             expire_time =3D NOW() + next_update_time;
@@ -188,7 +194,7 @@ static void alarm_timer_update(RTCState=20
=20
     stop_timer(&s->alarm_timer);
=20
-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
+    if (!(s->hw.cmos_data[RTC_REG_C] & RTC_AF) &&
             !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
     {
         s->current_tm =3D gmtime(get_localtime(d));
@@ -455,8 +461,10 @@ static int rtc_ioport_write(void *opaque
                 break;
             }
         s->hw.cmos_data[RTC_REG_B] =3D data;
-        check_update_timer(s);
-        alarm_timer_update(s);
+        if ( (data ^ orig) & RTC_SET )
+            check_update_timer(s);
+        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
+            alarm_timer_update(s);
         break;
     case RTC_REG_C:
     case RTC_REG_D:
@@ -610,6 +618,8 @@ static uint32_t rtc_ioport_read(RTCState
         hvm_isa_irq_deassert(vrtc_domain(s), RTC_IRQ);
         s->hw.cmos_data[RTC_REG_C] =3D 0x00;
         check_update_timer(s);
+        alarm_timer_update(s);
+        rtc_timer_update(s);
         break;
     default:
         ret =3D s->hw.cmos_data[s->hw.cmos_index];
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -22,6 +22,7 @@
 #include <asm/hvm/vpt.h>
 #include <asm/event.h>
 #include <asm/apic.h>
+#include <asm/mc146818rtc.h>
=20
 #define mode_is(d, name) \
     ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##nam=
e)
@@ -218,6 +219,7 @@ int pt_update_irq(struct vcpu *v)
     struct periodic_time *pt, *temp, *earliest_pt =3D NULL;
     uint64_t max_lag =3D -1ULL;
     int irq, is_lapic;
+    void *pt_priv;
=20
     spin_lock(&v->arch.hvm_vcpu.tm_lock);
=20
@@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu *v)
     earliest_pt->irq_issued =3D 1;
     irq =3D earliest_pt->irq;
     is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);
+    pt_priv =3D earliest_pt->priv;
=20
     spin_unlock(&v->arch.hvm_vcpu.tm_lock);
=20
     if ( is_lapic )
-    {
         vlapic_set_irq(vcpu_vlapic(v), irq, 0);
-    }
+    else if ( irq =3D=3D RTC_IRQ && pt_priv )
+        rtc_periodic_interrupt(pt_priv);
     else
     {
         hvm_isa_irq_deassert(v->domain, irq);
--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
 void rtc_deinit(struct domain *d);
 void rtc_reset(struct domain *d);
 void rtc_update_clock(struct domain *d);
+void rtc_periodic_interrupt(void *);
=20
 void pmtimer_init(struct vcpu *v);
 void pmtimer_deinit(struct domain *d);



--=__Part76462599.1__=
Content-Type: text/plain; name="x86-HVM-RTC.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HVM-RTC.patch"

x86/HVM: assorted RTC emulation adjustments=0A=0A- only call check_update_t=
imer() on REG_B writes when SET changes=0A- only call alarm_timer_update() =
on REG_B writes when relevant bits=0A  change=0A- instead properly handle =
AF and PF when the guest is not also setting=0A  AIE/PIE respectively (for =
UF this was already the case, only a=0A  comment was slightly inaccurate), =
including calling the respective=0A  update functions upon REG_C =
reads=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: =
Olaf Hering <olaf@aepfle.de>=0A---=0Av2: This is the (fixed) remaining =
part of a similarly named patch sent=0A    about half a year ago. The =
originally missing piece are the added=0A    calls from the REG_C read =
code (which back then I had taken note of=0A    only as being a possible =
future enhancement).=0A=0A--- a/xen/arch/x86/hvm/rtc.c=0A+++ b/xen/arch/x86=
/hvm/rtc.c=0A@@ -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState =
*s)=0A     hvm_isa_irq_assert(d, RTC_IRQ);=0A }=0A =0A-static void =
rtc_periodic_cb(struct vcpu *v, void *opaque)=0A+void rtc_periodic_interrup=
t(void *opaque)=0A {=0A     RTCState *s =3D opaque;=0A =0A     spin_lock(&s=
->lock);=0A-    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF | RTC_IRQF;=0A+    =
if ( s->hw.cmos_data[RTC_REG_C] & RTC_PF )=0A+        destroy_periodic_time=
(&s->pt);=0A+    else=0A+    {=0A+        s->hw.cmos_data[RTC_REG_C] |=3D =
RTC_PF;=0A+        if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )=0A+         =
   rtc_toggle_irq(s);=0A+    }=0A     spin_unlock(&s->lock);=0A }=0A =0A@@ =
-91,8 +98,7 @@ static void rtc_timer_update(RTCState *s=0A         {=0A    =
         period =3D 1 << (period_code - 1); /* period in 32 Khz cycles =
*/=0A             period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* =
in ns */=0A-            create_periodic_time(v, &s->pt, period, period, =
RTC_IRQ,=0A-                                 rtc_periodic_cb, s);=0A+      =
      create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL, =
s);=0A             break;=0A         }=0A         /* fall through */=0A@@ =
-120,7 +126,7 @@ static void check_update_timer(RTCState =0A         =
guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;=0A         if (guest_use=
c >=3D (USEC_PER_SEC - 244))=0A         {=0A-            /* RTC is in =
update cycle when enabling UIE */=0A+            /* RTC is in update cycle =
*/=0A             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;=0A             =
next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC;=0A         =
    expire_time =3D NOW() + next_update_time;=0A@@ -188,7 +194,7 @@ static =
void alarm_timer_update(RTCState =0A =0A     stop_timer(&s->alarm_timer);=
=0A =0A-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&=0A+    if =
(!(s->hw.cmos_data[RTC_REG_C] & RTC_AF) &&=0A             !(s->hw.cmos_data=
[RTC_REG_B] & RTC_SET))=0A     {=0A         s->current_tm =3D gmtime(get_lo=
caltime(d));=0A@@ -455,8 +461,10 @@ static int rtc_ioport_write(void =
*opaque=0A                 break;=0A             }=0A         s->hw.cmos_da=
ta[RTC_REG_B] =3D data;=0A-        check_update_timer(s);=0A-        =
alarm_timer_update(s);=0A+        if ( (data ^ orig) & RTC_SET )=0A+       =
     check_update_timer(s);=0A+        if ( (data ^ orig) & (RTC_24H | =
RTC_DM_BINARY | RTC_SET) )=0A+            alarm_timer_update(s);=0A        =
 break;=0A     case RTC_REG_C:=0A     case RTC_REG_D:=0A@@ -610,6 +618,8 =
@@ static uint32_t rtc_ioport_read(RTCState=0A         hvm_isa_irq_deassert=
(vrtc_domain(s), RTC_IRQ);=0A         s->hw.cmos_data[RTC_REG_C] =3D =
0x00;=0A         check_update_timer(s);=0A+        alarm_timer_update(s);=
=0A+        rtc_timer_update(s);=0A         break;=0A     default:=0A      =
   ret =3D s->hw.cmos_data[s->hw.cmos_index];=0A--- a/xen/arch/x86/hvm/vpt.=
c=0A+++ b/xen/arch/x86/hvm/vpt.c=0A@@ -22,6 +22,7 @@=0A #include <asm/hvm/v=
pt.h>=0A #include <asm/event.h>=0A #include <asm/apic.h>=0A+#include =
<asm/mc146818rtc.h>=0A =0A #define mode_is(d, name) \=0A     ((d)->arch.hvm=
_domain.params[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##name)=0A@@ -218,6 =
+219,7 @@ int pt_update_irq(struct vcpu *v)=0A     struct periodic_time =
*pt, *temp, *earliest_pt =3D NULL;=0A     uint64_t max_lag =3D -1ULL;=0A   =
  int irq, is_lapic;=0A+    void *pt_priv;=0A =0A     spin_lock(&v->arch.hv=
m_vcpu.tm_lock);=0A =0A@@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu =
*v)=0A     earliest_pt->irq_issued =3D 1;=0A     irq =3D earliest_pt->irq;=
=0A     is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);=0A+    =
pt_priv =3D earliest_pt->priv;=0A =0A     spin_unlock(&v->arch.hvm_vcpu.tm_=
lock);=0A =0A     if ( is_lapic )=0A-    {=0A         vlapic_set_irq(vcpu_v=
lapic(v), irq, 0);=0A-    }=0A+    else if ( irq =3D=3D RTC_IRQ && pt_priv =
)=0A+        rtc_periodic_interrupt(pt_priv);=0A     else=0A     {=0A      =
   hvm_isa_irq_deassert(v->domain, irq);=0A--- a/xen/include/asm-x86/hvm/vp=
t.h=0A+++ b/xen/include/asm-x86/hvm/vpt.h=0A@@ -181,6 +181,7 @@ void =
rtc_migrate_timers(struct vcpu *v);=0A void rtc_deinit(struct domain =
*d);=0A void rtc_reset(struct domain *d);=0A void rtc_update_clock(struct =
domain *d);=0A+void rtc_periodic_interrupt(void *);=0A =0A void pmtimer_ini=
t(struct vcpu *v);=0A void pmtimer_deinit(struct domain *d);=0A
--=__Part76462599.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

--=__Part76462599.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 04 15:56:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2OOr-0001TQ-B9; Mon, 04 Feb 2013 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.Campbell@citrix.com>) id 1U2OOq-0001TL-EM
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:56:04 +0000
Received: from [85.158.143.99:12771] by server-1.bemta-4.messagelabs.com id
	40/25-08839-31ADF015; Mon, 04 Feb 2013 15:56:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1359993363!23190002!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19934 invoked from network); 4 Feb 2013 15:56:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1126217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:56: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.297.1; Mon, 4 Feb 2013
	15:56:03 +0000
Message-ID: <1359993361.7743.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 15:56:01 +0000
In-Reply-To: <20130204155059.GA21493@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de> <20130204144424.GA18602@aepfle.de>
	<20130204152739.GA20329@aepfle.de>
	<1359992581.7743.72.camel@zakaz.uk.xensource.com>
	<20130204155059.GA21493@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 15:50 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 15:27 +0000, Olaf Hering wrote:
> > > On Mon, Feb 04, Olaf Hering wrote:
> > > 
> > > > Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> > > > are really gone.
> > > 
> > > With sles11 dom0+domU there are no more hpet1 messages when started from
> > > xend.
> > > 
> > > 
> > > With xl however I now get a hanging guest, which I did not see before this
> > > patch. But this happens only if it is booted with quiet, with 'debug
> > > ignore_loglevel' booting works fine.
> > > Also xl list shows the domain in paused state?!
> > 
> > [...]
> > >   [<ffffffff812a9543>] acpi_os_write_port+0xe  <--
> > 
> > I expect this will have trapped to qemu, which would explain why the
> > vcpu is paused, but not why qemu appears to not be responding. Maybe
> > something in the qemu logs will shed some light?
> 
> I was running xenctx in another window, and it leads to this sort of
> hang.

That is, erm, interesting!

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 15:56:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 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 1U2OOr-0001TQ-B9; Mon, 04 Feb 2013 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.Campbell@citrix.com>) id 1U2OOq-0001TL-EM
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 15:56:04 +0000
Received: from [85.158.143.99:12771] by server-1.bemta-4.messagelabs.com id
	40/25-08839-31ADF015; Mon, 04 Feb 2013 15:56:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1359993363!23190002!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19934 invoked from network); 4 Feb 2013 15:56:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 15:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,600,1355097600"; 
   d="scan'208";a="1126217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 15:56: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.297.1; Mon, 4 Feb 2013
	15:56:03 +0000
Message-ID: <1359993361.7743.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 4 Feb 2013 15:56:01 +0000
In-Reply-To: <20130204155059.GA21493@aepfle.de>
References: <20130131170718.GB19350@aepfle.de>
	<510FA33F02000078000BB71D@nat28.tlf.novell.com>
	<20130204142540.GA17824@aepfle.de> <20130204144424.GA18602@aepfle.de>
	<20130204152739.GA20329@aepfle.de>
	<1359992581.7743.72.camel@zakaz.uk.xensource.com>
	<20130204155059.GA21493@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] HVM guests hanging in hpet_rtc_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 15:50 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Mon, 2013-02-04 at 15:27 +0000, Olaf Hering wrote:
> > > On Mon, Feb 04, Olaf Hering wrote:
> > > 
> > > > Now I'm going to boot into sles11 dom0 and see if the hpet1 messsages
> > > > are really gone.
> > > 
> > > With sles11 dom0+domU there are no more hpet1 messages when started from
> > > xend.
> > > 
> > > 
> > > With xl however I now get a hanging guest, which I did not see before this
> > > patch. But this happens only if it is booted with quiet, with 'debug
> > > ignore_loglevel' booting works fine.
> > > Also xl list shows the domain in paused state?!
> > 
> > [...]
> > >   [<ffffffff812a9543>] acpi_os_write_port+0xe  <--
> > 
> > I expect this will have trapped to qemu, which would explain why the
> > vcpu is paused, but not why qemu appears to not be responding. Maybe
> > something in the qemu logs will shed some light?
> 
> I was running xenctx in another window, and it leads to this sort of
> hang.

That is, erm, interesting!

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16: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 1U2OfA-0002Iv-8c; Mon, 04 Feb 2013 16:12:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U2Of9-0002Iq-Kq
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 16:12:55 +0000
Received: from [193.109.254.147:35641] by server-7.bemta-14.messagelabs.com id
	F5/EE-13581-60EDF015; Mon, 04 Feb 2013 16:12:54 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1359994365!8962619!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25976 invoked from network); 4 Feb 2013 16:12:46 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-2.tower-27.messagelabs.com with SMTP;
	4 Feb 2013 16:12:46 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r14GCipG028159;
	Mon, 4 Feb 2013 11:12:44 -0500
Message-ID: <510FDDFB.1040102@theshore.net>
Date: Mon, 04 Feb 2013 11:12:43 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <liuw@liuw.name>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
In-Reply-To: <CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/1/13 8:01 PM, Wei Liu wrote:
> Dose your Dom0 has very limited RAM?
>
> Just happened to fix a bug related to OOM not getting handled correctly.
>
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html

I'm not sure if it was under abnormal memory pressure.  We've tuned 
things quite a bit to not swap thrash under worst-case conditions.  But 
things happen.

If this is a likely culprit then we'll rebuild with this patch and we'll 
give it a go.  Thanks!

-Chris


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16: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 1U2OfA-0002Iv-8c; Mon, 04 Feb 2013 16:12:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U2Of9-0002Iq-Kq
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 16:12:55 +0000
Received: from [193.109.254.147:35641] by server-7.bemta-14.messagelabs.com id
	F5/EE-13581-60EDF015; Mon, 04 Feb 2013 16:12:54 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1359994365!8962619!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25976 invoked from network); 4 Feb 2013 16:12:46 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-2.tower-27.messagelabs.com with SMTP;
	4 Feb 2013 16:12:46 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r14GCipG028159;
	Mon, 4 Feb 2013 11:12:44 -0500
Message-ID: <510FDDFB.1040102@theshore.net>
Date: Mon, 04 Feb 2013 11:12:43 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <liuw@liuw.name>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
In-Reply-To: <CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/1/13 8:01 PM, Wei Liu wrote:
> Dose your Dom0 has very limited RAM?
>
> Just happened to fix a bug related to OOM not getting handled correctly.
>
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html

I'm not sure if it was under abnormal memory pressure.  We've tuned 
things quite a bit to not swap thrash under worst-case conditions.  But 
things happen.

If this is a likely culprit then we'll rebuild with this patch and we'll 
give it a go.  Thanks!

-Chris


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:47:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16: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 1U2PBq-0002eK-5U; Mon, 04 Feb 2013 16:46:42 +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 1U2PBp-0002eF-4T
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:46:41 +0000
Received: from [85.158.143.99:46637] by server-3.bemta-4.messagelabs.com id
	ED/9C-08920-0F5EF015; Mon, 04 Feb 2013 16:46:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1359996395!22065558!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25020 invoked from network); 4 Feb 2013 16:46:35 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 16:46:35 -0000
Received: by mail-wi0-f169.google.com with SMTP id l13so2752007wie.4
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 08:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=D2GyfYhLVGmZ6SB9p9nQgKC7sDrB+qaptDmSYqC3WlI=;
	b=Vq/G8ebLKMfQPrtyysbJvyWspn5YRVEMFdOnwyenG6wYWJLfOXu2t3z8lOHbau24nO
	xlCL06vcGxYq/afcrU1OymfIHU08WIxi29jKG9tx8JzGMzzBt9aGv+YAUsOVtTs61PGM
	ILB7kyM5jj9EnFoVHxM7DIjIhMeNWCJrb/4GbUe6u22asKQOWBRpKzG1nqW1e3K8oYc5
	iPGwOz/9m5hsCDJcBZ0l+0GO/81O59dADvzT4W0iWTqUv3laF5KcRzzr35xvzaaUmw23
	scLLgKcPUzKkDahVpCL9jp5nVZVuVqN7titcTnlSaH2EA/8GnIcX7+fvtQLqcmI0K4Lx
	WFvg==
X-Received: by 10.194.83.97 with SMTP id p1mr36676561wjy.17.1359996395169;
	Mon, 04 Feb 2013 08:46:35 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id ex1sm1016487wib.7.2013.02.04.08.46.33
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 08:46:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 16:46:30 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CD359666.59FAD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
	rather than reboot
Thread-Index: Ac4C9y52MCTOX6/SgkC2rJTJWKmrpw==
In-Reply-To: <1359991569.7743.60.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 15:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
>> While the triple fault action on native hardware will result in a system
>> reset, any modern operating system can and will make use of less violent
>> reboot methods.  As a result, the most likely cause of a triple fault is a
>> fatal software bug.
>> 
>> This patch allows the toolstack to indicate that a triple fault should mean a
>> crash rather than a reboot.  The default of reboot still remains the same.
> 
> Just a random thought -- what about adding SHUTDOWN_triple_fault as an
> explicit thing, then the toolstack can decide what to do?

I kind of prefer that, although it will require changes to every toolstack.

An alternative would be to do that, *and* still have the new HVM_PARAM, so
that any SHUTDOWN_* code can be generated by a triple fault (including new
SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
default behaviour is still unchanged.

Or, in any case, I'm not dead against the existing patch, it just seems less
flexible than it could be. But maybe that flexibility is pointless.

 -- Keir

>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> 
>> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>>  void hvm_triple_fault(void)
>>  {
>>      struct vcpu *v = current;
>> +    struct domain * d = v->domain;
>> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
>> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
>> +
>>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
>> -             "invoking HVM system reset.\n", v->vcpu_id);
>> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
>> +             "invoking HVM system %s.\n", v->vcpu_id,
>> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
>> +    domain_shutdown(v->domain, reason);
>>  }
>>  
>>  void hvm_inject_trap(struct hvm_trap *trap)
>> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/include/public/hvm/params.h
>> --- a/xen/include/public/hvm/params.h
>> +++ b/xen/include/public/hvm/params.h
>> @@ -142,6 +142,9 @@
>>  #define HVM_PARAM_ACCESS_RING_PFN   28
>>  #define HVM_PARAM_SHARING_RING_PFN  29
>>  
>> -#define HVM_NR_PARAMS          31
>> +/* Boolean: Should a triple fault imply crash rather than reboot? */
>> +#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
>> +
>> +#define HVM_NR_PARAMS          32
>>  
>>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 04 16:47:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16: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 1U2PBq-0002eK-5U; Mon, 04 Feb 2013 16:46:42 +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 1U2PBp-0002eF-4T
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:46:41 +0000
Received: from [85.158.143.99:46637] by server-3.bemta-4.messagelabs.com id
	ED/9C-08920-0F5EF015; Mon, 04 Feb 2013 16:46:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1359996395!22065558!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25020 invoked from network); 4 Feb 2013 16:46:35 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 16:46:35 -0000
Received: by mail-wi0-f169.google.com with SMTP id l13so2752007wie.4
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 08:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=D2GyfYhLVGmZ6SB9p9nQgKC7sDrB+qaptDmSYqC3WlI=;
	b=Vq/G8ebLKMfQPrtyysbJvyWspn5YRVEMFdOnwyenG6wYWJLfOXu2t3z8lOHbau24nO
	xlCL06vcGxYq/afcrU1OymfIHU08WIxi29jKG9tx8JzGMzzBt9aGv+YAUsOVtTs61PGM
	ILB7kyM5jj9EnFoVHxM7DIjIhMeNWCJrb/4GbUe6u22asKQOWBRpKzG1nqW1e3K8oYc5
	iPGwOz/9m5hsCDJcBZ0l+0GO/81O59dADvzT4W0iWTqUv3laF5KcRzzr35xvzaaUmw23
	scLLgKcPUzKkDahVpCL9jp5nVZVuVqN7titcTnlSaH2EA/8GnIcX7+fvtQLqcmI0K4Lx
	WFvg==
X-Received: by 10.194.83.97 with SMTP id p1mr36676561wjy.17.1359996395169;
	Mon, 04 Feb 2013 08:46:35 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id ex1sm1016487wib.7.2013.02.04.08.46.33
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 08:46:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 16:46:30 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CD359666.59FAD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
	rather than reboot
Thread-Index: Ac4C9y52MCTOX6/SgkC2rJTJWKmrpw==
In-Reply-To: <1359991569.7743.60.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 15:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
>> While the triple fault action on native hardware will result in a system
>> reset, any modern operating system can and will make use of less violent
>> reboot methods.  As a result, the most likely cause of a triple fault is a
>> fatal software bug.
>> 
>> This patch allows the toolstack to indicate that a triple fault should mean a
>> crash rather than a reboot.  The default of reboot still remains the same.
> 
> Just a random thought -- what about adding SHUTDOWN_triple_fault as an
> explicit thing, then the toolstack can decide what to do?

I kind of prefer that, although it will require changes to every toolstack.

An alternative would be to do that, *and* still have the new HVM_PARAM, so
that any SHUTDOWN_* code can be generated by a triple fault (including new
SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
default behaviour is still unchanged.

Or, in any case, I'm not dead against the existing patch, it just seems less
flexible than it could be. But maybe that flexibility is pointless.

 -- Keir

>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> 
>> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>>  void hvm_triple_fault(void)
>>  {
>>      struct vcpu *v = current;
>> +    struct domain * d = v->domain;
>> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
>> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
>> +
>>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
>> -             "invoking HVM system reset.\n", v->vcpu_id);
>> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
>> +             "invoking HVM system %s.\n", v->vcpu_id,
>> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
>> +    domain_shutdown(v->domain, reason);
>>  }
>>  
>>  void hvm_inject_trap(struct hvm_trap *trap)
>> diff -r 5af4f2ab06f3 -r 6f8c532df545 xen/include/public/hvm/params.h
>> --- a/xen/include/public/hvm/params.h
>> +++ b/xen/include/public/hvm/params.h
>> @@ -142,6 +142,9 @@
>>  #define HVM_PARAM_ACCESS_RING_PFN   28
>>  #define HVM_PARAM_SHARING_RING_PFN  29
>>  
>> -#define HVM_NR_PARAMS          31
>> +/* Boolean: Should a triple fault imply crash rather than reboot? */
>> +#define HVM_PARAM_TRIPLE_FAULT_CRASH 31
>> +
>> +#define HVM_NR_PARAMS          32
>>  
>>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 04 16:50:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16:50: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 1U2PEx-0002kv-R5; Mon, 04 Feb 2013 16:49:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iant@google.com>) id 1U2PC0-0002ei-4i
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:46:52 +0000
Received: from [85.158.139.211:48707] by server-11.bemta-5.messagelabs.com id
	05/23-19159-BF5EF015; Mon, 04 Feb 2013 16:46:51 +0000
X-Env-Sender: iant@google.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1359996409!17078907!1
X-Originating-IP: [209.85.214.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14012 invoked from network); 4 Feb 2013 16:46:50 -0000
Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com)
	(209.85.214.178)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 16:46:50 -0000
Received: by mail-ob0-f178.google.com with SMTP id wd20so6429480obb.23
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 08:46:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=J/mJLAmiVWoUNqBPAplqdeKV5To7+1lOPA34lfpsyq0=;
	b=BPqnlYwa1+GRjvQ0B/bxUwGPdalGnCdgCQDbKks8EP3WCbcUiGfr0obIZrVw6AcP5T
	pmOYK6cRyt1CW66e4IxBsVTVqiBEpkMDs4ncMxR9DwqpOEgeev2Iu3WVeQvZAZxJlkLd
	ERntrkNeZNoTF/LHkwSTZjS8hAc+bYkD5mvzoh1hlCIe1c5tJ7EitRY8BUFE/hg/70SH
	JFPPH1UsMLwdyUCLaGqJWBETY6ehSFMIiRQ5uzWklT6cClc2u9ofG16QVC6uTUU2d7N7
	uW5jvkdSWSyWoWD63jT8K8MM9uz/n+fDLu4Ald7uX5kWMOH6w6EfIlMpbkwrLngKdTkI
	Uu4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=J/mJLAmiVWoUNqBPAplqdeKV5To7+1lOPA34lfpsyq0=;
	b=iN48F3Vxk2mT1uQXiXKK3TKnHuyzcIrOmQZ8TM9y6jUcjKJTaNf8njXcbDcyRCeXr+
	MbdpzwDH6chHucbVCqaNlA1WqJfzUrA3t82ok81OvPi5iXIt6ZShXscZVUfnERRqnDhy
	L5FQJOf2ozNXFUj0tdgEO7oaE+fm/wKW42mnrCapQHZM+mJIL3tdn1cu+7mGNcldQ43a
	pCX0OdttRjzCZVAxk6GPJk9wcTfe0G4m70c808YblDi7w2t/rgcNeGgPJ4Y21pVeq43/
	/EHNKOevK1+FGbOBRnbJwrI07FB0+WqAFQZW5EqMCiT4w0uHKuPJkV41znfu//S4EmX0
	vpnA==
MIME-Version: 1.0
X-Received: by 10.60.7.129 with SMTP id j1mr16846688oea.54.1359996409163; Mon,
	04 Feb 2013 08:46:49 -0800 (PST)
Received: by 10.182.23.39 with HTTP; Mon, 4 Feb 2013 08:46:49 -0800 (PST)
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
Date: Mon, 4 Feb 2013 08:46:49 -0800
Message-ID: <CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
From: Ian Lance Taylor <iant@google.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
X-Gm-Message-State: ALoCoQmr+w4dSagspoZFrYF7pSE+oh83J3vHMDTPAeQzNItsAFs1QaKvc+Fu6HmmbOCxs1mWEGIasM0plVlQYSVnFHdkR5UrvRr1SolS4RUs4HZmf3EK/+NqTpS+zDUJ3ZUZrQ91+JBKd2z+LaQhY1R8H2gnMRJjqUcRzJthTJcr1IKTBfxp6kfR70ztT0AgMsLNuqcFgsYC
X-Mailman-Approved-At: Mon, 04 Feb 2013 16:49:54 +0000
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
<frediano.ziglio@citrix.com> wrote:
>
> I imported some headers from Linux kernel which mainly came from
> gcov-io.h and the structures used internally by GCC.
>
> Our problem is currently about the license. In gcov-io.h is stated that
> license is mainly GPL2 which the exception that linking the "library"
> with other files does not cause these files to be GPL2. Now however I'm
> not linking to any library but just using the structure declaration
> inside the header to produce a blob that is currently converted into GCC
> files by an external utility (Xen has not file system so we extract
> coverage information).
>
> It's not a problem to use these headers/structure from Xen (which is
> GPL2) but we'd like to have these defines in our public include headers.
> The license however of these headers is quite open and allow to be used
> for instance in commercial programs. How the license would affect these
> programs?
>
> Another question we have is the stability of these structures. Can we
> just check the version field of gcov_info to make sure that the internal
> structure is not changed or is it expected that even this field would
> change (for instance position or size inside the structure) ?

You neglected to say which version of GCC you are using.  In current
GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
Library Exception 3.1
(http://www.gnu.org/licenses/gcc-exception-3.1.html).

I don't fully grasp the situation in which a user of xen would want to
#include this header file.  But if a program does #include the header
file, then in the strictest possible reading that program would be
covered by GPLv3 plus the GCC Runtime Library Exception.  That would
impose certain requirements on the program, basically that if it is
compiled by a version of GCC with a proprietary extension, the program
may not be distributed in binary form.  Those requirements already
apply to essentially any program compiled by a current version of GCC.
 Inciuding the header file gcov-io.h should not add any additional
requirements.

Hope this helps.  This is of course not legal advice, but you are
unlikely to get good legal advice in this area.

Ian

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:50:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16:50: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 1U2PEx-0002kv-R5; Mon, 04 Feb 2013 16:49:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iant@google.com>) id 1U2PC0-0002ei-4i
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:46:52 +0000
Received: from [85.158.139.211:48707] by server-11.bemta-5.messagelabs.com id
	05/23-19159-BF5EF015; Mon, 04 Feb 2013 16:46:51 +0000
X-Env-Sender: iant@google.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1359996409!17078907!1
X-Originating-IP: [209.85.214.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14012 invoked from network); 4 Feb 2013 16:46:50 -0000
Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com)
	(209.85.214.178)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 16:46:50 -0000
Received: by mail-ob0-f178.google.com with SMTP id wd20so6429480obb.23
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 08:46:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=J/mJLAmiVWoUNqBPAplqdeKV5To7+1lOPA34lfpsyq0=;
	b=BPqnlYwa1+GRjvQ0B/bxUwGPdalGnCdgCQDbKks8EP3WCbcUiGfr0obIZrVw6AcP5T
	pmOYK6cRyt1CW66e4IxBsVTVqiBEpkMDs4ncMxR9DwqpOEgeev2Iu3WVeQvZAZxJlkLd
	ERntrkNeZNoTF/LHkwSTZjS8hAc+bYkD5mvzoh1hlCIe1c5tJ7EitRY8BUFE/hg/70SH
	JFPPH1UsMLwdyUCLaGqJWBETY6ehSFMIiRQ5uzWklT6cClc2u9ofG16QVC6uTUU2d7N7
	uW5jvkdSWSyWoWD63jT8K8MM9uz/n+fDLu4Ald7uX5kWMOH6w6EfIlMpbkwrLngKdTkI
	Uu4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=J/mJLAmiVWoUNqBPAplqdeKV5To7+1lOPA34lfpsyq0=;
	b=iN48F3Vxk2mT1uQXiXKK3TKnHuyzcIrOmQZ8TM9y6jUcjKJTaNf8njXcbDcyRCeXr+
	MbdpzwDH6chHucbVCqaNlA1WqJfzUrA3t82ok81OvPi5iXIt6ZShXscZVUfnERRqnDhy
	L5FQJOf2ozNXFUj0tdgEO7oaE+fm/wKW42mnrCapQHZM+mJIL3tdn1cu+7mGNcldQ43a
	pCX0OdttRjzCZVAxk6GPJk9wcTfe0G4m70c808YblDi7w2t/rgcNeGgPJ4Y21pVeq43/
	/EHNKOevK1+FGbOBRnbJwrI07FB0+WqAFQZW5EqMCiT4w0uHKuPJkV41znfu//S4EmX0
	vpnA==
MIME-Version: 1.0
X-Received: by 10.60.7.129 with SMTP id j1mr16846688oea.54.1359996409163; Mon,
	04 Feb 2013 08:46:49 -0800 (PST)
Received: by 10.182.23.39 with HTTP; Mon, 4 Feb 2013 08:46:49 -0800 (PST)
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
Date: Mon, 4 Feb 2013 08:46:49 -0800
Message-ID: <CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
From: Ian Lance Taylor <iant@google.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
X-Gm-Message-State: ALoCoQmr+w4dSagspoZFrYF7pSE+oh83J3vHMDTPAeQzNItsAFs1QaKvc+Fu6HmmbOCxs1mWEGIasM0plVlQYSVnFHdkR5UrvRr1SolS4RUs4HZmf3EK/+NqTpS+zDUJ3ZUZrQ91+JBKd2z+LaQhY1R8H2gnMRJjqUcRzJthTJcr1IKTBfxp6kfR70ztT0AgMsLNuqcFgsYC
X-Mailman-Approved-At: Mon, 04 Feb 2013 16:49:54 +0000
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
<frediano.ziglio@citrix.com> wrote:
>
> I imported some headers from Linux kernel which mainly came from
> gcov-io.h and the structures used internally by GCC.
>
> Our problem is currently about the license. In gcov-io.h is stated that
> license is mainly GPL2 which the exception that linking the "library"
> with other files does not cause these files to be GPL2. Now however I'm
> not linking to any library but just using the structure declaration
> inside the header to produce a blob that is currently converted into GCC
> files by an external utility (Xen has not file system so we extract
> coverage information).
>
> It's not a problem to use these headers/structure from Xen (which is
> GPL2) but we'd like to have these defines in our public include headers.
> The license however of these headers is quite open and allow to be used
> for instance in commercial programs. How the license would affect these
> programs?
>
> Another question we have is the stability of these structures. Can we
> just check the version field of gcov_info to make sure that the internal
> structure is not changed or is it expected that even this field would
> change (for instance position or size inside the structure) ?

You neglected to say which version of GCC you are using.  In current
GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
Library Exception 3.1
(http://www.gnu.org/licenses/gcc-exception-3.1.html).

I don't fully grasp the situation in which a user of xen would want to
#include this header file.  But if a program does #include the header
file, then in the strictest possible reading that program would be
covered by GPLv3 plus the GCC Runtime Library Exception.  That would
impose certain requirements on the program, basically that if it is
compiled by a version of GCC with a proprietary extension, the program
may not be distributed in binary form.  Those requirements already
apply to essentially any program compiled by a current version of GCC.
 Inciuding the header file gcov-io.h should not add any additional
requirements.

Hope this helps.  This is of course not legal advice, but you are
unlikely to get good legal advice in this area.

Ian

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:50:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16:50: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 1U2PFD-0002m2-8H; Mon, 04 Feb 2013 16:50:11 +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 1U2PFB-0002lu-KM
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:50:09 +0000
Received: from [193.109.254.147:16046] by server-3.bemta-14.messagelabs.com id
	9A/23-22141-0C6EF015; Mon, 04 Feb 2013 16:50:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359996607!8523777!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32167 invoked from network); 4 Feb 2013 16:50:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 16:50:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 16:50:07 +0000
Message-Id: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 16:50:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, originally having been at a fixed location outside of Xen virtual
address ranges, has seen a number of changes over the years, with
the net effect that right now we're requiring an order-1 allocation
from the Xen heap. Obviously it would be much better if this got
populated with order-0 allocations from the domain heap.

Considering that there's going to be one such area per vCPU (less
those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
seems undesirable to me to use vmap() for this purpose.

Instead I wonder whether we shouldn't go back to putting this at
a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
the virtual address range pressure (compared to the vmap()
approach as well as for the case that these areas might need
extending). Was there any other reason that you moved them out
of such a fixed area than wanting to use mostly the same code
for PV and HVM (which ought to be possible now that there's a
base pointer stored for each vCPU)?

An alternative might be to use another per-domain L3 slot for this.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:50:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16:50: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 1U2PFD-0002m2-8H; Mon, 04 Feb 2013 16:50:11 +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 1U2PFB-0002lu-KM
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:50:09 +0000
Received: from [193.109.254.147:16046] by server-3.bemta-14.messagelabs.com id
	9A/23-22141-0C6EF015; Mon, 04 Feb 2013 16:50:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359996607!8523777!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32167 invoked from network); 4 Feb 2013 16:50:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 16:50:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 16:50:07 +0000
Message-Id: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 16:50:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, originally having been at a fixed location outside of Xen virtual
address ranges, has seen a number of changes over the years, with
the net effect that right now we're requiring an order-1 allocation
from the Xen heap. Obviously it would be much better if this got
populated with order-0 allocations from the domain heap.

Considering that there's going to be one such area per vCPU (less
those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
seems undesirable to me to use vmap() for this purpose.

Instead I wonder whether we shouldn't go back to putting this at
a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
the virtual address range pressure (compared to the vmap()
approach as well as for the case that these areas might need
extending). Was there any other reason that you moved them out
of such a fixed area than wanting to use mostly the same code
for PV and HVM (which ought to be possible now that there's a
base pointer stored for each vCPU)?

An alternative might be to use another per-domain L3 slot for this.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 16:52:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16:52: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 1U2PGm-0002yr-Oi; Mon, 04 Feb 2013 16:51: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 1U2PGl-0002yh-7a
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:51:47 +0000
Received: from [85.158.143.35:20203] by server-3.bemta-4.messagelabs.com id
	A4/63-08920-227EF015; Mon, 04 Feb 2013 16:51:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359996705!13752339!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15011 invoked from network); 4 Feb 2013 16:51:45 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 16:51:45 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so3294127wgh.3
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 08:51:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=NJCZlp9zzXhNCRaOXmapf3231ti0C6+MUB8TBRDqSy4=;
	b=pcMxc4sZ62x21cL7DlJwhXW5TlP6mmxvZlR49mM/zwVIU+SIG1/57MN3J1VfWHB76W
	2ylKWIhST0wDpM9d3/9vMMtNCg1qT8MxuEOhrDUyWyzrRR1koYmknSG8jqqB97MPGYCo
	cAzKtF4blM6tgD5xVSuFKEz6eoLLDUVQWf7qYdWko0j/WEjQL+H35gIsExSlc5duGNcr
	dMAnfFSK4DaWQLoHaNS/JWIin90rVQcvZlY/4spYtqITwcrhMxs8vtLZGmb7N+4rWpTX
	tipUH+LHPSHs2GdEXCHAOGHK3lfyDgbiHcsijDo6lZ/tV2i7UfNBA9gbNy3SAnTQpAYK
	Wmng==
X-Received: by 10.194.238.226 with SMTP id vn2mr36433007wjc.23.1359996705374; 
	Mon, 04 Feb 2013 08:51:45 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id e12sm22686832wiw.5.2013.02.04.08.51.43
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 08:51:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 16:51:36 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD359798.59FB0%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation
	adjustments
Thread-Index: Ac4C9+TaZ1XB+XaVJ0+qq07Yn8lWuA==
In-Reply-To: <510FE79902000078000BB9AE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation
 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

On 04/02/2013 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> - only call check_update_timer() on REG_B writes when SET changes
> - only call alarm_timer_update() on REG_B writes when relevant bits
>   change
> - instead properly handle AF and PF when the guest is not also setting
>   AIE/PIE respectively (for UF this was already the case, only a
>   comment was slightly inaccurate), including calling the respective
>   update functions upon REG_C reads
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Olaf Hering <olaf@aepfle.de>

Without spending some quality time with the RTC data sheet and our emulation
code, I don't think I can usefully comment on this. Superficially it all
sounds reasonable. So it's hard for me to Ack it, but you can feel free to
check it in anyway!

 -- Keir

> ---
> v2: This is the (fixed) remaining part of a similarly named patch sent
>     about half a year ago. The originally missing piece are the added
>     calls from the REG_C read code (which back then I had taken note of
>     only as being a possible future enhancement).
> 
> --- a/xen/arch/x86/hvm/rtc.c
> +++ b/xen/arch/x86/hvm/rtc.c
> @@ -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState *s)
>      hvm_isa_irq_assert(d, RTC_IRQ);
>  }
>  
> -static void rtc_periodic_cb(struct vcpu *v, void *opaque)
> +void rtc_periodic_interrupt(void *opaque)
>  {
>      RTCState *s = opaque;
>  
>      spin_lock(&s->lock);
> -    s->hw.cmos_data[RTC_REG_C] |= RTC_PF | RTC_IRQF;
> +    if ( s->hw.cmos_data[RTC_REG_C] & RTC_PF )
> +        destroy_periodic_time(&s->pt);
> +    else
> +    {
> +        s->hw.cmos_data[RTC_REG_C] |= RTC_PF;
> +        if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
> +            rtc_toggle_irq(s);
> +    }
>      spin_unlock(&s->lock);
>  }
>  
> @@ -91,8 +98,7 @@ static void rtc_timer_update(RTCState *s
>          {
>              period = 1 << (period_code - 1); /* period in 32 Khz cycles */
>              period = DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */
> -            create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
> -                                 rtc_periodic_cb, s);
> +            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL,
> s);
>              break;
>          }
>          /* fall through */
> @@ -120,7 +126,7 @@ static void check_update_timer(RTCState
>          guest_usec = get_localtime_us(d) % USEC_PER_SEC;
>          if (guest_usec >= (USEC_PER_SEC - 244))
>          {
> -            /* RTC is in update cycle when enabling UIE */
> +            /* RTC is in update cycle */
>              s->hw.cmos_data[RTC_REG_A] |= RTC_UIP;
>              next_update_time = (USEC_PER_SEC - guest_usec) * NS_PER_USEC;
>              expire_time = NOW() + next_update_time;
> @@ -188,7 +194,7 @@ static void alarm_timer_update(RTCState
>  
>      stop_timer(&s->alarm_timer);
>  
> -    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
> +    if (!(s->hw.cmos_data[RTC_REG_C] & RTC_AF) &&
>              !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
>      {
>          s->current_tm = gmtime(get_localtime(d));
> @@ -455,8 +461,10 @@ static int rtc_ioport_write(void *opaque
>                  break;
>              }
>          s->hw.cmos_data[RTC_REG_B] = data;
> -        check_update_timer(s);
> -        alarm_timer_update(s);
> +        if ( (data ^ orig) & RTC_SET )
> +            check_update_timer(s);
> +        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
> +            alarm_timer_update(s);
>          break;
>      case RTC_REG_C:
>      case RTC_REG_D:
> @@ -610,6 +618,8 @@ static uint32_t rtc_ioport_read(RTCState
>          hvm_isa_irq_deassert(vrtc_domain(s), RTC_IRQ);
>          s->hw.cmos_data[RTC_REG_C] = 0x00;
>          check_update_timer(s);
> +        alarm_timer_update(s);
> +        rtc_timer_update(s);
>          break;
>      default:
>          ret = s->hw.cmos_data[s->hw.cmos_index];
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -22,6 +22,7 @@
>  #include <asm/hvm/vpt.h>
>  #include <asm/event.h>
>  #include <asm/apic.h>
> +#include <asm/mc146818rtc.h>
>  
>  #define mode_is(d, name) \
>      ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] == HVMPTM_##name)
> @@ -218,6 +219,7 @@ int pt_update_irq(struct vcpu *v)
>      struct periodic_time *pt, *temp, *earliest_pt = NULL;
>      uint64_t max_lag = -1ULL;
>      int irq, is_lapic;
> +    void *pt_priv;
>  
>      spin_lock(&v->arch.hvm_vcpu.tm_lock);
>  
> @@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu *v)
>      earliest_pt->irq_issued = 1;
>      irq = earliest_pt->irq;
>      is_lapic = (earliest_pt->source == PTSRC_lapic);
> +    pt_priv = earliest_pt->priv;
>  
>      spin_unlock(&v->arch.hvm_vcpu.tm_lock);
>  
>      if ( is_lapic )
> -    {
>          vlapic_set_irq(vcpu_vlapic(v), irq, 0);
> -    }
> +    else if ( irq == RTC_IRQ && pt_priv )
> +        rtc_periodic_interrupt(pt_priv);
>      else
>      {
>          hvm_isa_irq_deassert(v->domain, irq);
> --- a/xen/include/asm-x86/hvm/vpt.h
> +++ b/xen/include/asm-x86/hvm/vpt.h
> @@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
>  void rtc_deinit(struct domain *d);
>  void rtc_reset(struct domain *d);
>  void rtc_update_clock(struct domain *d);
> +void rtc_periodic_interrupt(void *);
>  
>  void pmtimer_init(struct vcpu *v);
>  void pmtimer_deinit(struct domain *d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 16:52:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 16:52: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 1U2PGm-0002yr-Oi; Mon, 04 Feb 2013 16:51: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 1U2PGl-0002yh-7a
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 16:51:47 +0000
Received: from [85.158.143.35:20203] by server-3.bemta-4.messagelabs.com id
	A4/63-08920-227EF015; Mon, 04 Feb 2013 16:51:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1359996705!13752339!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15011 invoked from network); 4 Feb 2013 16:51:45 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 16:51:45 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so3294127wgh.3
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 08:51:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=NJCZlp9zzXhNCRaOXmapf3231ti0C6+MUB8TBRDqSy4=;
	b=pcMxc4sZ62x21cL7DlJwhXW5TlP6mmxvZlR49mM/zwVIU+SIG1/57MN3J1VfWHB76W
	2ylKWIhST0wDpM9d3/9vMMtNCg1qT8MxuEOhrDUyWyzrRR1koYmknSG8jqqB97MPGYCo
	cAzKtF4blM6tgD5xVSuFKEz6eoLLDUVQWf7qYdWko0j/WEjQL+H35gIsExSlc5duGNcr
	dMAnfFSK4DaWQLoHaNS/JWIin90rVQcvZlY/4spYtqITwcrhMxs8vtLZGmb7N+4rWpTX
	tipUH+LHPSHs2GdEXCHAOGHK3lfyDgbiHcsijDo6lZ/tV2i7UfNBA9gbNy3SAnTQpAYK
	Wmng==
X-Received: by 10.194.238.226 with SMTP id vn2mr36433007wjc.23.1359996705374; 
	Mon, 04 Feb 2013 08:51:45 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id e12sm22686832wiw.5.2013.02.04.08.51.43
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 08:51:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 16:51:36 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD359798.59FB0%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation
	adjustments
Thread-Index: Ac4C9+TaZ1XB+XaVJ0+qq07Yn8lWuA==
In-Reply-To: <510FE79902000078000BB9AE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation
 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

On 04/02/2013 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> - only call check_update_timer() on REG_B writes when SET changes
> - only call alarm_timer_update() on REG_B writes when relevant bits
>   change
> - instead properly handle AF and PF when the guest is not also setting
>   AIE/PIE respectively (for UF this was already the case, only a
>   comment was slightly inaccurate), including calling the respective
>   update functions upon REG_C reads
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Olaf Hering <olaf@aepfle.de>

Without spending some quality time with the RTC data sheet and our emulation
code, I don't think I can usefully comment on this. Superficially it all
sounds reasonable. So it's hard for me to Ack it, but you can feel free to
check it in anyway!

 -- Keir

> ---
> v2: This is the (fixed) remaining part of a similarly named patch sent
>     about half a year ago. The originally missing piece are the added
>     calls from the REG_C read code (which back then I had taken note of
>     only as being a possible future enhancement).
> 
> --- a/xen/arch/x86/hvm/rtc.c
> +++ b/xen/arch/x86/hvm/rtc.c
> @@ -60,12 +60,19 @@ static void rtc_toggle_irq(RTCState *s)
>      hvm_isa_irq_assert(d, RTC_IRQ);
>  }
>  
> -static void rtc_periodic_cb(struct vcpu *v, void *opaque)
> +void rtc_periodic_interrupt(void *opaque)
>  {
>      RTCState *s = opaque;
>  
>      spin_lock(&s->lock);
> -    s->hw.cmos_data[RTC_REG_C] |= RTC_PF | RTC_IRQF;
> +    if ( s->hw.cmos_data[RTC_REG_C] & RTC_PF )
> +        destroy_periodic_time(&s->pt);
> +    else
> +    {
> +        s->hw.cmos_data[RTC_REG_C] |= RTC_PF;
> +        if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
> +            rtc_toggle_irq(s);
> +    }
>      spin_unlock(&s->lock);
>  }
>  
> @@ -91,8 +98,7 @@ static void rtc_timer_update(RTCState *s
>          {
>              period = 1 << (period_code - 1); /* period in 32 Khz cycles */
>              period = DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */
> -            create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
> -                                 rtc_periodic_cb, s);
> +            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL,
> s);
>              break;
>          }
>          /* fall through */
> @@ -120,7 +126,7 @@ static void check_update_timer(RTCState
>          guest_usec = get_localtime_us(d) % USEC_PER_SEC;
>          if (guest_usec >= (USEC_PER_SEC - 244))
>          {
> -            /* RTC is in update cycle when enabling UIE */
> +            /* RTC is in update cycle */
>              s->hw.cmos_data[RTC_REG_A] |= RTC_UIP;
>              next_update_time = (USEC_PER_SEC - guest_usec) * NS_PER_USEC;
>              expire_time = NOW() + next_update_time;
> @@ -188,7 +194,7 @@ static void alarm_timer_update(RTCState
>  
>      stop_timer(&s->alarm_timer);
>  
> -    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
> +    if (!(s->hw.cmos_data[RTC_REG_C] & RTC_AF) &&
>              !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
>      {
>          s->current_tm = gmtime(get_localtime(d));
> @@ -455,8 +461,10 @@ static int rtc_ioport_write(void *opaque
>                  break;
>              }
>          s->hw.cmos_data[RTC_REG_B] = data;
> -        check_update_timer(s);
> -        alarm_timer_update(s);
> +        if ( (data ^ orig) & RTC_SET )
> +            check_update_timer(s);
> +        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
> +            alarm_timer_update(s);
>          break;
>      case RTC_REG_C:
>      case RTC_REG_D:
> @@ -610,6 +618,8 @@ static uint32_t rtc_ioport_read(RTCState
>          hvm_isa_irq_deassert(vrtc_domain(s), RTC_IRQ);
>          s->hw.cmos_data[RTC_REG_C] = 0x00;
>          check_update_timer(s);
> +        alarm_timer_update(s);
> +        rtc_timer_update(s);
>          break;
>      default:
>          ret = s->hw.cmos_data[s->hw.cmos_index];
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -22,6 +22,7 @@
>  #include <asm/hvm/vpt.h>
>  #include <asm/event.h>
>  #include <asm/apic.h>
> +#include <asm/mc146818rtc.h>
>  
>  #define mode_is(d, name) \
>      ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] == HVMPTM_##name)
> @@ -218,6 +219,7 @@ int pt_update_irq(struct vcpu *v)
>      struct periodic_time *pt, *temp, *earliest_pt = NULL;
>      uint64_t max_lag = -1ULL;
>      int irq, is_lapic;
> +    void *pt_priv;
>  
>      spin_lock(&v->arch.hvm_vcpu.tm_lock);
>  
> @@ -251,13 +253,14 @@ int pt_update_irq(struct vcpu *v)
>      earliest_pt->irq_issued = 1;
>      irq = earliest_pt->irq;
>      is_lapic = (earliest_pt->source == PTSRC_lapic);
> +    pt_priv = earliest_pt->priv;
>  
>      spin_unlock(&v->arch.hvm_vcpu.tm_lock);
>  
>      if ( is_lapic )
> -    {
>          vlapic_set_irq(vcpu_vlapic(v), irq, 0);
> -    }
> +    else if ( irq == RTC_IRQ && pt_priv )
> +        rtc_periodic_interrupt(pt_priv);
>      else
>      {
>          hvm_isa_irq_deassert(v->domain, irq);
> --- a/xen/include/asm-x86/hvm/vpt.h
> +++ b/xen/include/asm-x86/hvm/vpt.h
> @@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
>  void rtc_deinit(struct domain *d);
>  void rtc_reset(struct domain *d);
>  void rtc_update_clock(struct domain *d);
> +void rtc_periodic_interrupt(void *);
>  
>  void pmtimer_init(struct vcpu *v);
>  void pmtimer_deinit(struct domain *d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 17:03:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:03: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 1U2PSB-0003KS-5i; Mon, 04 Feb 2013 17:03:35 +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 1U2PSA-0003KN-7R
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:03:34 +0000
Received: from [85.158.139.211:47270] by server-4.bemta-5.messagelabs.com id
	0C/B2-29496-5E9EF015; Mon, 04 Feb 2013 17:03:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359997412!19972386!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10292 invoked from network); 4 Feb 2013 17:03:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 17:03:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 17:03:29 +0000
Message-Id: <510FF7EE02000078000BBA38@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 17:03:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <510FE79902000078000BB9AE@nat28.tlf.novell.com>
	<CD359798.59FB0%keir@xen.org>
In-Reply-To: <CD359798.59FB0%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation
 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

>>> On 04.02.13 at 17:51, Keir Fraser <keir@xen.org> wrote:
> On 04/02/2013 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> - only call check_update_timer() on REG_B writes when SET changes
>> - only call alarm_timer_update() on REG_B writes when relevant bits
>>   change
>> - instead properly handle AF and PF when the guest is not also setting
>>   AIE/PIE respectively (for UF this was already the case, only a
>>   comment was slightly inaccurate), including calling the respective
>>   update functions upon REG_C reads
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Olaf Hering <olaf@aepfle.de>
> 
> Without spending some quality time with the RTC data sheet and our emulation
> code, I don't think I can usefully comment on this. Superficially it all
> sounds reasonable. So it's hard for me to Ack it, but you can feel free to
> check it in anyway!

Will do, not the least because it appears to fix a problem for Olaf.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:03:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:03: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 1U2PSB-0003KS-5i; Mon, 04 Feb 2013 17:03:35 +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 1U2PSA-0003KN-7R
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:03:34 +0000
Received: from [85.158.139.211:47270] by server-4.bemta-5.messagelabs.com id
	0C/B2-29496-5E9EF015; Mon, 04 Feb 2013 17:03:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359997412!19972386!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10292 invoked from network); 4 Feb 2013 17:03:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 17:03:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 17:03:29 +0000
Message-Id: <510FF7EE02000078000BBA38@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 17:03:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <510FE79902000078000BB9AE@nat28.tlf.novell.com>
	<CD359798.59FB0%keir@xen.org>
In-Reply-To: <CD359798.59FB0%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/HVM: assorted RTC emulation
 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

>>> On 04.02.13 at 17:51, Keir Fraser <keir@xen.org> wrote:
> On 04/02/2013 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> - only call check_update_timer() on REG_B writes when SET changes
>> - only call alarm_timer_update() on REG_B writes when relevant bits
>>   change
>> - instead properly handle AF and PF when the guest is not also setting
>>   AIE/PIE respectively (for UF this was already the case, only a
>>   comment was slightly inaccurate), including calling the respective
>>   update functions upon REG_C reads
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Olaf Hering <olaf@aepfle.de>
> 
> Without spending some quality time with the RTC data sheet and our emulation
> code, I don't think I can usefully comment on this. Superficially it all
> sounds reasonable. So it's hard for me to Ack it, but you can feel free to
> check it in anyway!

Will do, not the least because it appears to fix a problem for Olaf.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:05:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:05: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 1U2PUD-0003Pf-MD; Mon, 04 Feb 2013 17:05:41 +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 1U2PUB-0003PZ-QZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:05:40 +0000
Received: from [85.158.139.83:16113] by server-5.bemta-5.messagelabs.com id
	38/AC-11945-36AEF015; Mon, 04 Feb 2013 17:05:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1359997537!30675724!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4848 invoked from network); 4 Feb 2013 17:05:38 -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; 4 Feb 2013 17:05:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 17:05:37 +0000
Message-Id: <510FF86C02000078000BBA3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 17:05:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Lance Taylor" <iant@google.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
In-Reply-To: <CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 17:46, Ian Lance Taylor <iant@google.com> wrote:
> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
> <frediano.ziglio@citrix.com> wrote:
>>
>> I imported some headers from Linux kernel which mainly came from
>> gcov-io.h and the structures used internally by GCC.
>>
>> Our problem is currently about the license. In gcov-io.h is stated that
>> license is mainly GPL2 which the exception that linking the "library"
>> with other files does not cause these files to be GPL2. Now however I'm
>> not linking to any library but just using the structure declaration
>> inside the header to produce a blob that is currently converted into GCC
>> files by an external utility (Xen has not file system so we extract
>> coverage information).
>>
>> It's not a problem to use these headers/structure from Xen (which is
>> GPL2) but we'd like to have these defines in our public include headers.
>> The license however of these headers is quite open and allow to be used
>> for instance in commercial programs. How the license would affect these
>> programs?
>>
>> Another question we have is the stability of these structures. Can we
>> just check the version field of gcov_info to make sure that the internal
>> structure is not changed or is it expected that even this field would
>> change (for instance position or size inside the structure) ?
> 
> You neglected to say which version of GCC you are using.  In current
> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
> Library Exception 3.1
> (http://www.gnu.org/licenses/gcc-exception-3.1.html).
> 
> I don't fully grasp the situation in which a user of xen would want to
> #include this header file.  But if a program does #include the header
> file, then in the strictest possible reading that program would be
> covered by GPLv3 plus the GCC Runtime Library Exception.  That would
> impose certain requirements on the program, basically that if it is
> compiled by a version of GCC with a proprietary extension, the program
> may not be distributed in binary form.

You probably meant "binary only form" here?

Jan

>  Those requirements already
> apply to essentially any program compiled by a current version of GCC.
>  Inciuding the header file gcov-io.h should not add any additional
> requirements.
> 
> Hope this helps.  This is of course not legal advice, but you are
> unlikely to get good legal advice in this area.
> 
> 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 Feb 04 17:05:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:05: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 1U2PUD-0003Pf-MD; Mon, 04 Feb 2013 17:05:41 +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 1U2PUB-0003PZ-QZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:05:40 +0000
Received: from [85.158.139.83:16113] by server-5.bemta-5.messagelabs.com id
	38/AC-11945-36AEF015; Mon, 04 Feb 2013 17:05:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1359997537!30675724!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4848 invoked from network); 4 Feb 2013 17:05:38 -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; 4 Feb 2013 17:05:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 04 Feb 2013 17:05:37 +0000
Message-Id: <510FF86C02000078000BBA3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 04 Feb 2013 17:05:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Lance Taylor" <iant@google.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
In-Reply-To: <CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 17:46, Ian Lance Taylor <iant@google.com> wrote:
> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
> <frediano.ziglio@citrix.com> wrote:
>>
>> I imported some headers from Linux kernel which mainly came from
>> gcov-io.h and the structures used internally by GCC.
>>
>> Our problem is currently about the license. In gcov-io.h is stated that
>> license is mainly GPL2 which the exception that linking the "library"
>> with other files does not cause these files to be GPL2. Now however I'm
>> not linking to any library but just using the structure declaration
>> inside the header to produce a blob that is currently converted into GCC
>> files by an external utility (Xen has not file system so we extract
>> coverage information).
>>
>> It's not a problem to use these headers/structure from Xen (which is
>> GPL2) but we'd like to have these defines in our public include headers.
>> The license however of these headers is quite open and allow to be used
>> for instance in commercial programs. How the license would affect these
>> programs?
>>
>> Another question we have is the stability of these structures. Can we
>> just check the version field of gcov_info to make sure that the internal
>> structure is not changed or is it expected that even this field would
>> change (for instance position or size inside the structure) ?
> 
> You neglected to say which version of GCC you are using.  In current
> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
> Library Exception 3.1
> (http://www.gnu.org/licenses/gcc-exception-3.1.html).
> 
> I don't fully grasp the situation in which a user of xen would want to
> #include this header file.  But if a program does #include the header
> file, then in the strictest possible reading that program would be
> covered by GPLv3 plus the GCC Runtime Library Exception.  That would
> impose certain requirements on the program, basically that if it is
> compiled by a version of GCC with a proprietary extension, the program
> may not be distributed in binary form.

You probably meant "binary only form" here?

Jan

>  Those requirements already
> apply to essentially any program compiled by a current version of GCC.
>  Inciuding the header file gcov-io.h should not add any additional
> requirements.
> 
> Hope this helps.  This is of course not legal advice, but you are
> unlikely to get good legal advice in this area.
> 
> 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 Feb 04 17:11:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PZa-0003hr-2l; Mon, 04 Feb 2013 17:11:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2PZY-0003fi-CO
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:11:12 +0000
Received: from [85.158.139.83:14763] by server-7.bemta-5.messagelabs.com id
	EB/F1-11121-FABEF015; Mon, 04 Feb 2013 17:11:11 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359997863!29932440!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32685 invoked from network); 4 Feb 2013 17:11:07 -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;
	4 Feb 2013 17:11:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6193814"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:11:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:11:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2PZO-0001Du-Eh;
	Mon, 04 Feb 2013 17:11:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 4 Feb 2013 17:08:52 +0000
Message-ID: <1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 +
 .hgignore                |    2 +
 Config.mk                |    3 ++
 xen/Rules.mk             |    5 +++
 xen/arch/x86/setup.c     |    3 ++
 xen/arch/x86/xen.lds.S   |    7 ++++
 xen/common/Makefile      |    2 +
 xen/common/gcov/Makefile |    2 +
 xen/common/gcov/gcov.c   |   94 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   97 ++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 217 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..c9044f5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+
+ifeq ($(coverage),y)
+$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+endif
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..ddf5c4d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -46,6 +46,7 @@
 #include <asm/setup.h>
 #include <xen/cpu.h>
 #include <asm/nmi.h>
+#include <xen/gcov.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
@@ -1313,6 +1314,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_coverage();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..ab75fdf
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,94 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+typedef void (*ctor_func_t)(void);
+extern const struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void init_coverage(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+
+#ifndef NDEBUG
+    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
+    if ( info_list )
+        printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..7b374b8
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,97 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+/**
+ * Initialize coverage informations
+ * Currently create a linked list of all files compiled in with
+ * coverage informations.
+ */
+#ifdef TEST_COVERAGE
+void __init init_coverage(void);
+#else
+static inline void init_coverage(void)
+{
+}
+#endif
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Mon Feb 04 17:11:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PZa-0003hr-2l; Mon, 04 Feb 2013 17:11:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2PZY-0003fi-CO
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:11:12 +0000
Received: from [85.158.139.83:14763] by server-7.bemta-5.messagelabs.com id
	EB/F1-11121-FABEF015; Mon, 04 Feb 2013 17:11:11 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359997863!29932440!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32685 invoked from network); 4 Feb 2013 17:11:07 -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;
	4 Feb 2013 17:11:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6193814"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:11:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:11:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2PZO-0001Du-Eh;
	Mon, 04 Feb 2013 17:11:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 4 Feb 2013 17:08:52 +0000
Message-ID: <1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 +
 .hgignore                |    2 +
 Config.mk                |    3 ++
 xen/Rules.mk             |    5 +++
 xen/arch/x86/setup.c     |    3 ++
 xen/arch/x86/xen.lds.S   |    7 ++++
 xen/common/Makefile      |    2 +
 xen/common/gcov/Makefile |    2 +
 xen/common/gcov/gcov.c   |   94 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   97 ++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 217 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..c9044f5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+
+ifeq ($(coverage),y)
+$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+endif
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..ddf5c4d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -46,6 +46,7 @@
 #include <asm/setup.h>
 #include <xen/cpu.h>
 #include <asm/nmi.h>
+#include <xen/gcov.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
@@ -1313,6 +1314,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_coverage();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..ab75fdf
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,94 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+typedef void (*ctor_func_t)(void);
+extern const struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void init_coverage(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+
+#ifndef NDEBUG
+    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
+    if ( info_list )
+        printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..7b374b8
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,97 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+/**
+ * Initialize coverage informations
+ * Currently create a linked list of all files compiled in with
+ * coverage informations.
+ */
+#ifdef TEST_COVERAGE
+void __init init_coverage(void);
+#else
+static inline void init_coverage(void)
+{
+}
+#endif
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Mon Feb 04 17:11:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PZZ-0003hk-My; Mon, 04 Feb 2013 17:11:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2PZX-0003fb-O4
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:11:11 +0000
Received: from [85.158.139.83:14677] by server-11.bemta-5.messagelabs.com id
	CC/52-19159-EABEF015; Mon, 04 Feb 2013 17:11:10 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359997863!29932440!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32639 invoked from network); 4 Feb 2013 17:11:04 -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;
	4 Feb 2013 17:11:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6193813"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:11:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:11:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2PZO-0001Du-Cq;
	Mon, 04 Feb 2013 17:11:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 4 Feb 2013 17:08:51 +0000
Message-ID: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC PATCH v3] Coverage 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

Updated set of patches for coverage.
Changes:
- now public header contain information only of Xen export format
- use sysctl instead of a specific hypercall

Tools require smaller changes, now export one use libxc, I'll attach ASAP.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:11:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PZZ-0003hk-My; Mon, 04 Feb 2013 17:11:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2PZX-0003fb-O4
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:11:11 +0000
Received: from [85.158.139.83:14677] by server-11.bemta-5.messagelabs.com id
	CC/52-19159-EABEF015; Mon, 04 Feb 2013 17:11:10 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1359997863!29932440!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32639 invoked from network); 4 Feb 2013 17:11:04 -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;
	4 Feb 2013 17:11:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6193813"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:11:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:11:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2PZO-0001Du-Cq;
	Mon, 04 Feb 2013 17:11:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 4 Feb 2013 17:08:51 +0000
Message-ID: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC PATCH v3] Coverage 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

Updated set of patches for coverage.
Changes:
- now public header contain information only of Xen export format
- use sysctl instead of a specific hypercall

Tools require smaller changes, now export one use libxc, I'll attach ASAP.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:11:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:11: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 1U2PZo-0003k8-G2; Mon, 04 Feb 2013 17:11:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2PZn-0003jl-Em
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:11:27 +0000
Received: from [85.158.137.99:35445] by server-2.bemta-3.messagelabs.com id
	74/86-25961-EBBEF015; Mon, 04 Feb 2013 17:11:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1359997883!19949858!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6364 invoked from network); 4 Feb 2013 17:11:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5888296"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:11:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:11:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2PZO-0001Du-FF;
	Mon, 04 Feb 2013 17:11:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 4 Feb 2013 17:08:53 +0000
Message-ID: <1359997733-15769-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  151 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |   92 ++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 297 insertions(+), 3 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index ab75fdf..378866d 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -77,12 +78,156 @@ void init_coverage(void)
         __CTOR_LIST__.funcs[n]();
 
 #ifndef NDEBUG
-    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
     if ( info_list )
         printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
 #endif
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset =
+        (iter->write_offset + data_len + (sizeof(uint32_t) - 1)) &
+        -sizeof(uint32_t);
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write_string(iter, info->filename));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..5224249
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,92 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58430000u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x0100u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x0200u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x0300u+((n)&0xffu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0xff00u)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE FILENAME xencov_file COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM xencov_function..
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ */
+struct xencov_file
+{
+    uint32_t version;
+    uint32_t stamp;
+} __attribute__((packed));
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ */
+struct xencov_counter
+{
+    uint32_t num;
+    uint64_t values[0];
+} __attribute__((packed));
+
+/**
+ * Information for each function
+ * Prefixed with XENCOV_TAG_FUNC
+ * Number of counter is equal to the number of counter got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t n_ctrs[0];
+} __attribute__((packed));
+
+struct xencov_functions
+{
+    uint32_t num;
+    uint32_t xencov_function[0];
+} __attribute__((packed));
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index 7b374b8..d47a3c5 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -94,4 +96,16 @@ static inline void init_coverage(void)
 }
 #endif
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Mon Feb 04 17:11:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:11: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 1U2PZo-0003k8-G2; Mon, 04 Feb 2013 17:11:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2PZn-0003jl-Em
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:11:27 +0000
Received: from [85.158.137.99:35445] by server-2.bemta-3.messagelabs.com id
	74/86-25961-EBBEF015; Mon, 04 Feb 2013 17:11:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1359997883!19949858!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6364 invoked from network); 4 Feb 2013 17:11:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5888296"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:11:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:11:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2PZO-0001Du-FF;
	Mon, 04 Feb 2013 17:11:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 4 Feb 2013 17:08:53 +0000
Message-ID: <1359997733-15769-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  151 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |   92 ++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 297 insertions(+), 3 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index ab75fdf..378866d 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -77,12 +78,156 @@ void init_coverage(void)
         __CTOR_LIST__.funcs[n]();
 
 #ifndef NDEBUG
-    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
     if ( info_list )
         printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
 #endif
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset =
+        (iter->write_offset + data_len + (sizeof(uint32_t) - 1)) &
+        -sizeof(uint32_t);
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write_string(iter, info->filename));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..5224249
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,92 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58430000u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x0100u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x0200u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x0300u+((n)&0xffu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0xff00u)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE FILENAME xencov_file COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM xencov_function..
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ */
+struct xencov_file
+{
+    uint32_t version;
+    uint32_t stamp;
+} __attribute__((packed));
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ */
+struct xencov_counter
+{
+    uint32_t num;
+    uint64_t values[0];
+} __attribute__((packed));
+
+/**
+ * Information for each function
+ * Prefixed with XENCOV_TAG_FUNC
+ * Number of counter is equal to the number of counter got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t n_ctrs[0];
+} __attribute__((packed));
+
+struct xencov_functions
+{
+    uint32_t num;
+    uint32_t xencov_function[0];
+} __attribute__((packed));
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index 7b374b8..d47a3c5 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -94,4 +96,16 @@ static inline void init_coverage(void)
 }
 #endif
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Mon Feb 04 17:12:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:12: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 1U2Pan-0003uA-5f; Mon, 04 Feb 2013 17:12:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U2Pal-0003ti-6C
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:12:27 +0000
Received: from [193.109.254.147:11337] by server-11.bemta-14.messagelabs.com
	id 20/08-30685-AFBEF015; Mon, 04 Feb 2013 17:12:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359997942!8525920!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27774 invoked from network); 4 Feb 2013 17:12:23 -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;
	4 Feb 2013 17:12:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5888437"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:12:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:12:22 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2Paf-0001Ey-OJ;
	Mon, 04 Feb 2013 17:12:21 +0000
Message-ID: <510FEBF5.1060708@citrix.com>
Date: Mon, 4 Feb 2013 17:12:21 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CD359666.59FAD%keir@xen.org>
In-Reply-To: <CD359666.59FAD%keir@xen.org>
X-Enigmail-Version: 1.4
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 16:46, Keir Fraser wrote:
> On 04/02/2013 15:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
>> On Mon, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
>>> While the triple fault action on native hardware will result in a system
>>> reset, any modern operating system can and will make use of less violent
>>> reboot methods.  As a result, the most likely cause of a triple fault is a
>>> fatal software bug.
>>>
>>> This patch allows the toolstack to indicate that a triple fault should mean a
>>> crash rather than a reboot.  The default of reboot still remains the same.
>> Just a random thought -- what about adding SHUTDOWN_triple_fault as an
>> explicit thing, then the toolstack can decide what to do?
> I kind of prefer that, although it will require changes to every toolstack.
>
> An alternative would be to do that, *and* still have the new HVM_PARAM, so
> that any SHUTDOWN_* code can be generated by a triple fault (including new
> SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
> default behaviour is still unchanged.
>
> Or, in any case, I'm not dead against the existing patch, it just seems less
> flexible than it could be. But maybe that flexibility is pointless.
>
>  -- Keir

I considered this approach originally, but decided against it.

SHUTDOWN_triple_fault would be meaningless as a standard SCHOP_shutdown
parameter, and having the toolstack differentiate between _crash and
_triple_fault seems pointless.

I thought that the ideal end result would be specifying

on_triple_fault="reboot"|"crash"

In the vm.cfg file

The on_{crash,reboot} actions would still then take effect as usual.

Having said that, if _triple_fault is preferred, I am not overly
attached to this specific implementation.


If it isn't obvious, the motivation behind this patch is because I am
currently chasing a windows triple fault on Xen-4.2.  It appears machine
specific, but related to our PV driver, and takes a long time to
reproduce.  Having automated tests fail soon with a triple fault is
better than having the domain in question sit in a reboot loop until the
hour long timeout kicks in.

~Andrew

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:12:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:12: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 1U2Pan-0003uA-5f; Mon, 04 Feb 2013 17:12:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U2Pal-0003ti-6C
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:12:27 +0000
Received: from [193.109.254.147:11337] by server-11.bemta-14.messagelabs.com
	id 20/08-30685-AFBEF015; Mon, 04 Feb 2013 17:12:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1359997942!8525920!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27774 invoked from network); 4 Feb 2013 17:12:23 -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;
	4 Feb 2013 17:12:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5888437"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:12:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:12:22 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U2Paf-0001Ey-OJ;
	Mon, 04 Feb 2013 17:12:21 +0000
Message-ID: <510FEBF5.1060708@citrix.com>
Date: Mon, 4 Feb 2013 17:12:21 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CD359666.59FAD%keir@xen.org>
In-Reply-To: <CD359666.59FAD%keir@xen.org>
X-Enigmail-Version: 1.4
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 16:46, Keir Fraser wrote:
> On 04/02/2013 15:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
>> On Mon, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
>>> While the triple fault action on native hardware will result in a system
>>> reset, any modern operating system can and will make use of less violent
>>> reboot methods.  As a result, the most likely cause of a triple fault is a
>>> fatal software bug.
>>>
>>> This patch allows the toolstack to indicate that a triple fault should mean a
>>> crash rather than a reboot.  The default of reboot still remains the same.
>> Just a random thought -- what about adding SHUTDOWN_triple_fault as an
>> explicit thing, then the toolstack can decide what to do?
> I kind of prefer that, although it will require changes to every toolstack.
>
> An alternative would be to do that, *and* still have the new HVM_PARAM, so
> that any SHUTDOWN_* code can be generated by a triple fault (including new
> SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
> default behaviour is still unchanged.
>
> Or, in any case, I'm not dead against the existing patch, it just seems less
> flexible than it could be. But maybe that flexibility is pointless.
>
>  -- Keir

I considered this approach originally, but decided against it.

SHUTDOWN_triple_fault would be meaningless as a standard SCHOP_shutdown
parameter, and having the toolstack differentiate between _crash and
_triple_fault seems pointless.

I thought that the ideal end result would be specifying

on_triple_fault="reboot"|"crash"

In the vm.cfg file

The on_{crash,reboot} actions would still then take effect as usual.

Having said that, if _triple_fault is preferred, I am not overly
attached to this specific implementation.


If it isn't obvious, the motivation behind this patch is because I am
currently chasing a windows triple fault on Xen-4.2.  It appears machine
specific, but related to our PV driver, and takes a long time to
reproduce.  Having automated tests fail soon with a triple fault is
better than having the domain in question sit in a reboot loop until the
hour long timeout kicks in.

~Andrew

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:20:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2Phy-0004JZ-9W; Mon, 04 Feb 2013 17:19:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iant@google.com>) id 1U2Phw-0004JU-9P
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:19:52 +0000
Received: from [85.158.143.99:18300] by server-2.bemta-4.messagelabs.com id
	13/FE-01597-7BDEF015; Mon, 04 Feb 2013 17:19:51 +0000
X-Env-Sender: iant@google.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359998380!17879826!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24088 invoked from network); 4 Feb 2013 17:19:50 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:19:50 -0000
Received: by mail-ob0-f173.google.com with SMTP id dn14so6640973obc.18
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:19:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=1nr4i0fT8VQmCT5UbyOqNcOjGLVhNXsrqGpzGhEwuG8=;
	b=GVCJLJjKOuc3dA5N0snONFWoib10z6sjKcWi6t47fWHvLCMrymhpNnpkCKM1I2R2Lk
	FspqpuX3SJtiNzgps5JandFd2ophA0E0h8qhwgzYmrxLs36eV91GZg4Apw3scWlF6ZAy
	BvEN5NZfbfG+romvYBJhdC3F7LOCLvVjVESgBc5xkzjnF5zPVhRQNNXB/x8uJHUd5E+j
	YoFcg11DMYNB8/RJiFFIq+K5XFC2OSA0PJadwFWeGdAshZShnrEvpjOgyG4giDe6kgfx
	hW8ifNXN+7nXGjBPC7w+3CtM3ts8Q8jS0dYi7slbB3gLDAJ3Co+JF6YC12QH6B5S0G+B
	NQlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=1nr4i0fT8VQmCT5UbyOqNcOjGLVhNXsrqGpzGhEwuG8=;
	b=BdOh5LTvF4M0P5V5eESYdpqJoTVil2yem+d1MygCYssuFGnXLFg5f3sRlNygBkJR+R
	5MfpGTAx7L4kbisu2J+hMkq2JCMmtH6TfCFBa7LHYl1MIFnDCRZhz90UnAv05MDka8vX
	wpNOYESyn39P2rKPrFCHhEZAfBO6MdGcla3N2FbWAg9ZfjYM7gPeAJoD3K3qybToa5jW
	TvyUO3aZkSvd8HV9XZCc7LRc1GKo00JPiOhjJ4H5JBt6nxw9SrIjkN0stSg8qOb6dpkm
	jtQR4J3UpwsKlnUcgrgr31hCAjvOupMnEEWgaLsOhlcRiHv79vosMQh5MDSjCTdrpGpV
	fw3w==
MIME-Version: 1.0
X-Received: by 10.182.180.113 with SMTP id dn17mr6807453obc.5.1359998380003;
	Mon, 04 Feb 2013 09:19:40 -0800 (PST)
Received: by 10.182.23.39 with HTTP; Mon, 4 Feb 2013 09:19:39 -0800 (PST)
In-Reply-To: <510FF86C02000078000BBA3B@nat28.tlf.novell.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<510FF86C02000078000BBA3B@nat28.tlf.novell.com>
Date: Mon, 4 Feb 2013 09:19:39 -0800
Message-ID: <CAKOQZ8zBN5p4x1sQxnVgSuHitTEgs6Eg4kJDLq7BTR2BWyWOqg@mail.gmail.com>
From: Ian Lance Taylor <iant@google.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlwHi8/tTvV2rTAPrGUzHHeQREPXeLnqMLaGVWetpLxUzIlmEQt8fz7/OzhJBcUClM+gOZHN4m4HIXf/mgFxm7VZ3Q47As1P38XsrpcVStMuyXtlcpelxJF4YjX6B1X9dQAQpnGaJoLKGL0Bamqt4PV1nsQnYO+X2mYbJm2eNj9L5vKBozRsgbtGR8Ov2wnmniibwXN
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 4, 2013 at 9:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.02.13 at 17:46, Ian Lance Taylor <iant@google.com> wrote:
>> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
>> <frediano.ziglio@citrix.com> wrote:
>>>
>>> I imported some headers from Linux kernel which mainly came from
>>> gcov-io.h and the structures used internally by GCC.
>>>
>>> Our problem is currently about the license. In gcov-io.h is stated that
>>> license is mainly GPL2 which the exception that linking the "library"
>>> with other files does not cause these files to be GPL2. Now however I'm
>>> not linking to any library but just using the structure declaration
>>> inside the header to produce a blob that is currently converted into GCC
>>> files by an external utility (Xen has not file system so we extract
>>> coverage information).
>>>
>>> It's not a problem to use these headers/structure from Xen (which is
>>> GPL2) but we'd like to have these defines in our public include headers.
>>> The license however of these headers is quite open and allow to be used
>>> for instance in commercial programs. How the license would affect these
>>> programs?
>>>
>>> Another question we have is the stability of these structures. Can we
>>> just check the version field of gcov_info to make sure that the internal
>>> structure is not changed or is it expected that even this field would
>>> change (for instance position or size inside the structure) ?
>>
>> You neglected to say which version of GCC you are using.  In current
>> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
>> Library Exception 3.1
>> (http://www.gnu.org/licenses/gcc-exception-3.1.html).
>>
>> I don't fully grasp the situation in which a user of xen would want to
>> #include this header file.  But if a program does #include the header
>> file, then in the strictest possible reading that program would be
>> covered by GPLv3 plus the GCC Runtime Library Exception.  That would
>> impose certain requirements on the program, basically that if it is
>> compiled by a version of GCC with a proprietary extension, the program
>> may not be distributed in binary form.
>
> You probably meant "binary only form" here?

Yes.  Thanks.  It is (of course) OK to distribute in binary form if
sources are also included, or made available.

Ian

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:20:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2Phy-0004JZ-9W; Mon, 04 Feb 2013 17:19:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iant@google.com>) id 1U2Phw-0004JU-9P
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:19:52 +0000
Received: from [85.158.143.99:18300] by server-2.bemta-4.messagelabs.com id
	13/FE-01597-7BDEF015; Mon, 04 Feb 2013 17:19:51 +0000
X-Env-Sender: iant@google.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359998380!17879826!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24088 invoked from network); 4 Feb 2013 17:19:50 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:19:50 -0000
Received: by mail-ob0-f173.google.com with SMTP id dn14so6640973obc.18
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:19:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=1nr4i0fT8VQmCT5UbyOqNcOjGLVhNXsrqGpzGhEwuG8=;
	b=GVCJLJjKOuc3dA5N0snONFWoib10z6sjKcWi6t47fWHvLCMrymhpNnpkCKM1I2R2Lk
	FspqpuX3SJtiNzgps5JandFd2ophA0E0h8qhwgzYmrxLs36eV91GZg4Apw3scWlF6ZAy
	BvEN5NZfbfG+romvYBJhdC3F7LOCLvVjVESgBc5xkzjnF5zPVhRQNNXB/x8uJHUd5E+j
	YoFcg11DMYNB8/RJiFFIq+K5XFC2OSA0PJadwFWeGdAshZShnrEvpjOgyG4giDe6kgfx
	hW8ifNXN+7nXGjBPC7w+3CtM3ts8Q8jS0dYi7slbB3gLDAJ3Co+JF6YC12QH6B5S0G+B
	NQlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=1nr4i0fT8VQmCT5UbyOqNcOjGLVhNXsrqGpzGhEwuG8=;
	b=BdOh5LTvF4M0P5V5eESYdpqJoTVil2yem+d1MygCYssuFGnXLFg5f3sRlNygBkJR+R
	5MfpGTAx7L4kbisu2J+hMkq2JCMmtH6TfCFBa7LHYl1MIFnDCRZhz90UnAv05MDka8vX
	wpNOYESyn39P2rKPrFCHhEZAfBO6MdGcla3N2FbWAg9ZfjYM7gPeAJoD3K3qybToa5jW
	TvyUO3aZkSvd8HV9XZCc7LRc1GKo00JPiOhjJ4H5JBt6nxw9SrIjkN0stSg8qOb6dpkm
	jtQR4J3UpwsKlnUcgrgr31hCAjvOupMnEEWgaLsOhlcRiHv79vosMQh5MDSjCTdrpGpV
	fw3w==
MIME-Version: 1.0
X-Received: by 10.182.180.113 with SMTP id dn17mr6807453obc.5.1359998380003;
	Mon, 04 Feb 2013 09:19:40 -0800 (PST)
Received: by 10.182.23.39 with HTTP; Mon, 4 Feb 2013 09:19:39 -0800 (PST)
In-Reply-To: <510FF86C02000078000BBA3B@nat28.tlf.novell.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<510FF86C02000078000BBA3B@nat28.tlf.novell.com>
Date: Mon, 4 Feb 2013 09:19:39 -0800
Message-ID: <CAKOQZ8zBN5p4x1sQxnVgSuHitTEgs6Eg4kJDLq7BTR2BWyWOqg@mail.gmail.com>
From: Ian Lance Taylor <iant@google.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlwHi8/tTvV2rTAPrGUzHHeQREPXeLnqMLaGVWetpLxUzIlmEQt8fz7/OzhJBcUClM+gOZHN4m4HIXf/mgFxm7VZ3Q47As1P38XsrpcVStMuyXtlcpelxJF4YjX6B1X9dQAQpnGaJoLKGL0Bamqt4PV1nsQnYO+X2mYbJm2eNj9L5vKBozRsgbtGR8Ov2wnmniibwXN
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 4, 2013 at 9:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.02.13 at 17:46, Ian Lance Taylor <iant@google.com> wrote:
>> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
>> <frediano.ziglio@citrix.com> wrote:
>>>
>>> I imported some headers from Linux kernel which mainly came from
>>> gcov-io.h and the structures used internally by GCC.
>>>
>>> Our problem is currently about the license. In gcov-io.h is stated that
>>> license is mainly GPL2 which the exception that linking the "library"
>>> with other files does not cause these files to be GPL2. Now however I'm
>>> not linking to any library but just using the structure declaration
>>> inside the header to produce a blob that is currently converted into GCC
>>> files by an external utility (Xen has not file system so we extract
>>> coverage information).
>>>
>>> It's not a problem to use these headers/structure from Xen (which is
>>> GPL2) but we'd like to have these defines in our public include headers.
>>> The license however of these headers is quite open and allow to be used
>>> for instance in commercial programs. How the license would affect these
>>> programs?
>>>
>>> Another question we have is the stability of these structures. Can we
>>> just check the version field of gcov_info to make sure that the internal
>>> structure is not changed or is it expected that even this field would
>>> change (for instance position or size inside the structure) ?
>>
>> You neglected to say which version of GCC you are using.  In current
>> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
>> Library Exception 3.1
>> (http://www.gnu.org/licenses/gcc-exception-3.1.html).
>>
>> I don't fully grasp the situation in which a user of xen would want to
>> #include this header file.  But if a program does #include the header
>> file, then in the strictest possible reading that program would be
>> covered by GPLv3 plus the GCC Runtime Library Exception.  That would
>> impose certain requirements on the program, basically that if it is
>> compiled by a version of GCC with a proprietary extension, the program
>> may not be distributed in binary form.
>
> You probably meant "binary only form" here?

Yes.  Thanks.  It is (of course) OK to distribute in binary form if
sources are also included, or made available.

Ian

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmR-0004V1-UF; Mon, 04 Feb 2013 17:24:31 +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 1U2PmQ-0004Tg-3U
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.139.211:48107] by server-6.bemta-5.messagelabs.com id
	48/5E-01489-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31024 invoked from network); 4 Feb 2013 17:24:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195781"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-1P;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:46 +0000
Message-ID: <1359998638-16774-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 03/15] Add evtchn_level in struct domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 field is manipulated by hypervisor only, so if anything goes wrong it is
a bug.

The default event channel is 2, which has two level lookup structure: a
selector in struct vcpu and a shared bitmap in shared info.

The up coming 3-level event channel utilizes three level lookup structure: a
top level selector and second level selector for every vcpu, and shared
bitmap.

When constructing a domain, it starts with 2-level event channel, which is
guaranteed to be supported by the hypervisor. If a domain wants to use N
(N>=3) level event channel, it must explicitly issue a hypercall to setup
N-level event channel.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/xen/event.h    |   16 +++++++++++++++-
 xen/include/xen/sched.h    |    1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 3293f91..43ee854 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1180,6 +1180,7 @@ int evtchn_init(struct domain *d)
     clear_page(d->evtchn);
 
     spin_lock_init(&d->event_lock);
+    d->evtchn_level = EVTCHN_DEFAULT_LEVEL;
     if ( get_free_port(d) != 0 ) {
         free_xenheap_page(d->evtchn);
         return -EINVAL;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index a1574ea..b32b06f 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,21 @@
 #else
 #define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
 #endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+#define EVTCHN_2_LEVEL       2
+#define EVTCHN_3_LEVEL       3
+#define EVTCHN_DEFAULT_LEVEL EVTCHN_2_LEVEL
+#define MAX_EVTCHNS_L2(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+#define MAX_EVTCHNS_L3(d) (MAX_EVTCHNS_L2(d) * BITS_PER_EVTCHN_WORD(d))
+#define MAX_EVTCHNS(d) ({ int __v = 0;				\
+			switch ( d->evtchn_level ) {		\
+			case EVTCHN_2_LEVEL:			\
+				__v = MAX_EVTCHNS_L2(d); break; \
+			case EVTCHN_3_LEVEL:			\
+				__v = MAX_EVTCHNS_L3(d); break; \
+			default:				\
+				BUG();                          \
+			};					\
+			__v;})
 
 #define EVTCHNS_PER_BUCKET 128
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 45ad6bd..2f18fe5 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -217,6 +217,7 @@ struct domain
     /* Event channel information. */
     struct evtchn  **evtchn;
     spinlock_t       event_lock;
+    unsigned int     evtchn_level;
 
     struct grant_table *grant_table;
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmR-0004V1-UF; Mon, 04 Feb 2013 17:24:31 +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 1U2PmQ-0004Tg-3U
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.139.211:48107] by server-6.bemta-5.messagelabs.com id
	48/5E-01489-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31024 invoked from network); 4 Feb 2013 17:24:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195781"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-1P;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:46 +0000
Message-ID: <1359998638-16774-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 03/15] Add evtchn_level in struct domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 field is manipulated by hypervisor only, so if anything goes wrong it is
a bug.

The default event channel is 2, which has two level lookup structure: a
selector in struct vcpu and a shared bitmap in shared info.

The up coming 3-level event channel utilizes three level lookup structure: a
top level selector and second level selector for every vcpu, and shared
bitmap.

When constructing a domain, it starts with 2-level event channel, which is
guaranteed to be supported by the hypervisor. If a domain wants to use N
(N>=3) level event channel, it must explicitly issue a hypercall to setup
N-level event channel.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/xen/event.h    |   16 +++++++++++++++-
 xen/include/xen/sched.h    |    1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 3293f91..43ee854 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1180,6 +1180,7 @@ int evtchn_init(struct domain *d)
     clear_page(d->evtchn);
 
     spin_lock_init(&d->event_lock);
+    d->evtchn_level = EVTCHN_DEFAULT_LEVEL;
     if ( get_free_port(d) != 0 ) {
         free_xenheap_page(d->evtchn);
         return -EINVAL;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index a1574ea..b32b06f 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,21 @@
 #else
 #define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
 #endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+#define EVTCHN_2_LEVEL       2
+#define EVTCHN_3_LEVEL       3
+#define EVTCHN_DEFAULT_LEVEL EVTCHN_2_LEVEL
+#define MAX_EVTCHNS_L2(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+#define MAX_EVTCHNS_L3(d) (MAX_EVTCHNS_L2(d) * BITS_PER_EVTCHN_WORD(d))
+#define MAX_EVTCHNS(d) ({ int __v = 0;				\
+			switch ( d->evtchn_level ) {		\
+			case EVTCHN_2_LEVEL:			\
+				__v = MAX_EVTCHNS_L2(d); break; \
+			case EVTCHN_3_LEVEL:			\
+				__v = MAX_EVTCHNS_L3(d); break; \
+			default:				\
+				BUG();                          \
+			};					\
+			__v;})
 
 #define EVTCHNS_PER_BUCKET 128
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 45ad6bd..2f18fe5 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -217,6 +217,7 @@ struct domain
     /* Event channel information. */
     struct evtchn  **evtchn;
     spinlock_t       event_lock;
+    unsigned int     evtchn_level;
 
     struct grant_table *grant_table;
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmW-0004Z9-Gb; Mon, 04 Feb 2013 17:24:36 +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 1U2PmS-0004Tq-Bz
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.139.211:48446] by server-16.bemta-5.messagelabs.com id
	26/F5-14948-0DEEF015; Mon, 04 Feb 2013 17:24:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31331 invoked from network); 4 Feb 2013 17:24:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195794"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-T9;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:45 +0000
Message-ID: <1359998635-16866-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 04/13] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/evtchn.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b1f60a0..ef02dfa 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -269,6 +269,15 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 				       u->name, (void *)(unsigned long)port);
 	if (rc >= 0)
 		rc = evtchn_make_refcounted(port);
+	else {
+		/* bind failed, should close the port now */
+		struct evtchn_close close;
+		close.port = port;
+		if (port != 0 && /* port 0 is never used */
+		    HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
+			BUG();
+		set_port_user(port, NULL);
+	}
 
 	return rc;
 }
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmR-0004Ui-Hj; Mon, 04 Feb 2013 17:24:31 +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 1U2PmP-0004Te-SI
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:29 +0000
Received: from [85.158.143.99:21281] by server-2.bemta-4.messagelabs.com id
	F4/13-01597-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19105 invoked from network); 4 Feb 2013 17:24:28 -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;
	4 Feb 2013 17:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890072"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-ND;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:41 +0000
Message-ID: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2] Implement 3-level event channel in Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 from V1:
* separate mechanical fixes to different changesets
* close evtchn once binding to irq fails
* remove kzalloc()
* always try to register 3-level event channel


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmT-0004Vw-4m; Mon, 04 Feb 2013 17:24:33 +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 1U2PmQ-0004Te-RN
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.143.99:21343] by server-2.bemta-4.messagelabs.com id
	4B/13-01597-ECEEF015; Mon, 04 Feb 2013 17:24:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19177 invoked from network); 4 Feb 2013 17:24:29 -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;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890074"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-0R;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:47 +0000
Message-ID: <1359998635-16866-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 06/13] xen: introduce test_and_set_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 96ed76f..2278851 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -345,6 +345,12 @@ static inline int test_evtchn(int port)
 	return sync_test_bit(port, &s->evtchn_pending[0]);
 }
 
+static inline int test_and_set_mask(int port)
+{
+	struct shared_info *s = HYPERVISOR_shared_info;
+	return sync_test_and_set_bit(port, &s->evtchn_mask[0]);
+}
+
 
 /**
  * notify_remote_via_irq - send event to remote end of event channel via irq
@@ -1464,7 +1470,7 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
+	masked = test_and_set_mask(evtchn);
 	sync_set_bit(evtchn, s->evtchn_pending);
 	if (!masked)
 		unmask_evtchn(evtchn);
@@ -1513,7 +1519,7 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
+		masked = test_and_set_mask(evtchn);
 		sync_set_bit(evtchn, sh->evtchn_pending);
 		if (!masked)
 			unmask_evtchn(evtchn);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmR-0004UR-4j; Mon, 04 Feb 2013 17:24:31 +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 1U2PmP-0004TS-FS
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:29 +0000
Received: from [85.158.139.211:60800] by server-1.bemta-5.messagelabs.com id
	05/1F-29263-CCEEF015; Mon, 04 Feb 2013 17:24:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30979 invoked from network); 4 Feb 2013 17:24:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195780"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmK-0001Rd-Vq;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:45 +0000
Message-ID: <1359998638-16774-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 02/15] Move event channel macros / struct
	definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 remove reference to NR_EVTCHN_BUCKETS in struct domain, we can move
those macros / struct definitions to event.h.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/sched.h |   45 ---------------------------------------------
 2 files changed, 46 insertions(+), 45 deletions(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 65ac81a..a1574ea 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -15,6 +15,52 @@
 #include <asm/bitops.h>
 #include <asm/event.h>
 
+#ifndef CONFIG_COMPAT
+#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
+#else
+#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
+#endif
+#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+
+#define EVTCHNS_PER_BUCKET 128
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+
+struct evtchn
+{
+#define ECS_FREE         0 /* Channel is available for use.                  */
+#define ECS_RESERVED     1 /* Channel is reserved.                           */
+#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
+#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
+#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
+#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
+#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
+    u8  state;             /* ECS_* */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
+    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
+    union {
+        struct {
+            domid_t remote_domid;
+        } unbound;     /* state == ECS_UNBOUND */
+        struct {
+            u16            remote_port;
+            struct domain *remote_dom;
+        } interdomain; /* state == ECS_INTERDOMAIN */
+        struct {
+            u16            irq;
+            u16            next_port;
+            u16            prev_port;
+        } pirq;        /* state == ECS_PIRQ */
+        u16 virq;      /* state == ECS_VIRQ */
+    } u;
+#ifdef FLASK_ENABLE
+    void *ssid;
+#endif
+};
+
+int  evtchn_init(struct domain *d); /* from domain_create */
+void evtchn_destroy(struct domain *d); /* from domain_kill */
+void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
+
 /*
  * send_guest_vcpu_virq: Notify guest via a per-VCPU VIRQ.
  *  @v:        VCPU to which virtual IRQ should be sent
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ded7a10..45ad6bd 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -45,51 +45,6 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 /* A global pointer to the initial domain (DOM0). */
 extern struct domain *dom0;
 
-#ifndef CONFIG_COMPAT
-#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
-#else
-#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
-#endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
-#define EVTCHNS_PER_BUCKET 128
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
-
-struct evtchn
-{
-#define ECS_FREE         0 /* Channel is available for use.                  */
-#define ECS_RESERVED     1 /* Channel is reserved.                           */
-#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
-#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
-#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
-#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
-#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
-    u8  state;             /* ECS_* */
-    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
-    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
-    union {
-        struct {
-            domid_t remote_domid;
-        } unbound;     /* state == ECS_UNBOUND */
-        struct {
-            u16            remote_port;
-            struct domain *remote_dom;
-        } interdomain; /* state == ECS_INTERDOMAIN */
-        struct {
-            u16            irq;
-            u16            next_port;
-            u16            prev_port;
-        } pirq;        /* state == ECS_PIRQ */
-        u16 virq;      /* state == ECS_VIRQ */
-    } u;
-#ifdef FLASK_ENABLE
-    void *ssid;
-#endif
-};
-
-int  evtchn_init(struct domain *d); /* from domain_create */
-void evtchn_destroy(struct domain *d); /* from domain_kill */
-void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
-
 struct waitqueue_vcpu;
 
 struct vcpu
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmV-0004YS-P5; Mon, 04 Feb 2013 17:24:35 +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 1U2PmS-0004Uu-8f
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.139.211:48359] by server-11.bemta-5.messagelabs.com id
	3E/48-19159-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195792"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-SY;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:44 +0000
Message-ID: <1359998635-16866-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 03/13] xen: fix error handling path if
	xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 call to xen_allocate_irq_dynamic() might return -ev error codes, not
lietral -1.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index d937bf8..96ed76f 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -820,7 +820,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 
 	if (irq == -1) {
 		irq = xen_allocate_irq_dynamic();
-		if (irq == -1)
+		if (irq < 0)
 			goto out;
 
 		irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
@@ -923,7 +923,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
 
 	if (irq == -1) {
 		irq = xen_allocate_irq_dynamic();
-		if (irq == -1)
+		if (irq < 0)
 			goto out;
 
 		irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmQ-0004U7-Oe; Mon, 04 Feb 2013 17:24:30 +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 1U2PmO-0004TJ-Tz
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:29 +0000
Received: from [85.158.139.211:48026] by server-2.bemta-5.messagelabs.com id
	D0/CF-16911-CCEEF015; Mon, 04 Feb 2013 17:24:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30920 invoked from network); 4 Feb 2013 17:24:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195779"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmK-0001Rd-UA;
	Mon, 04 Feb 2013 17:24:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:44 +0000
Message-ID: <1359998638-16774-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 01/15] Dynamically allocate d->evtchn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 we move to N level evtchn we need bigger d->evtchn, as a result
this will bloat struct domain. So move this array out of struct domain
and allocate a dedicated page for it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   17 +++++++++++++++--
 xen/include/xen/sched.h    |    2 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9231eb0..3293f91 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1172,15 +1172,26 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
 
 int evtchn_init(struct domain *d)
 {
+    BUILD_BUG_ON(sizeof(struct evtchn *) * NR_EVTCHN_BUCKETS > PAGE_SIZE);
+    d->evtchn = alloc_xenheap_page();
+
+    if ( d->evtchn == NULL )
+        return -ENOMEM;
+    clear_page(d->evtchn);
+
     spin_lock_init(&d->event_lock);
-    if ( get_free_port(d) != 0 )
+    if ( get_free_port(d) != 0 ) {
+        free_xenheap_page(d->evtchn);
         return -EINVAL;
+    }
     evtchn_from_port(d, 0)->state = ECS_RESERVED;
 
 #if MAX_VIRT_CPUS > BITS_PER_LONG
     d->poll_mask = xmalloc_array(unsigned long, BITS_TO_LONGS(MAX_VIRT_CPUS));
-    if ( !d->poll_mask )
+    if ( !d->poll_mask ) {
+        free_xenheap_page(d->evtchn);
         return -ENOMEM;
+    }
     bitmap_zero(d->poll_mask, MAX_VIRT_CPUS);
 #endif
 
@@ -1214,6 +1225,8 @@ void evtchn_destroy(struct domain *d)
     spin_unlock(&d->event_lock);
 
     clear_global_virq_handlers(d);
+
+    free_xenheap_page(d->evtchn);
 }
 
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 39f85d2..ded7a10 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -260,7 +260,7 @@ struct domain
     spinlock_t       rangesets_lock;
 
     /* Event channel information. */
-    struct evtchn   *evtchn[NR_EVTCHN_BUCKETS];
+    struct evtchn  **evtchn;
     spinlock_t       event_lock;
 
     struct grant_table *grant_table;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmU-0004XG-Lr; Mon, 04 Feb 2013 17:24: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 1U2PmR-0004UG-Im
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:31 +0000
Received: from [85.158.139.211:48294] by server-7.bemta-5.messagelabs.com id
	76/94-11121-ECEEF015; Mon, 04 Feb 2013 17:24:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31203 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195785"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-8W;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:52 +0000
Message-ID: <1359998638-16774-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 09/15] Add control structures for 3-level
	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

The references to shared bitmap pending / mask are embedded in struct domain.
And pointer to the second level selector is embedded in struct vcpu.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/sched.h |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 2f18fe5..1d8c1b5 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include <public/sysctl.h>
 #include <public/vcpu.h>
 #include <public/mem_event.h>
+#include <public/event_channel.h>
 
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -57,6 +58,9 @@ struct vcpu
 
     struct domain   *domain;
 
+    /* For 3-level event channels */
+    unsigned long   *evtchn_pending_sel_l2;
+
     struct vcpu     *next_in_list;
 
     s_time_t         periodic_period;
@@ -218,6 +222,8 @@ struct domain
     struct evtchn  **evtchn;
     spinlock_t       event_lock;
     unsigned int     evtchn_level;
+    unsigned long   *evtchn_pending[EVTCHN_MAX_L3_PAGES];
+    unsigned long   *evtchn_mask[EVTCHN_MAX_L3_PAGES];
 
     struct grant_table *grant_table;
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmW-0004Z9-Gb; Mon, 04 Feb 2013 17:24:36 +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 1U2PmS-0004Tq-Bz
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.139.211:48446] by server-16.bemta-5.messagelabs.com id
	26/F5-14948-0DEEF015; Mon, 04 Feb 2013 17:24:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31331 invoked from network); 4 Feb 2013 17:24:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195794"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-T9;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:45 +0000
Message-ID: <1359998635-16866-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 04/13] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/evtchn.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b1f60a0..ef02dfa 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -269,6 +269,15 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 				       u->name, (void *)(unsigned long)port);
 	if (rc >= 0)
 		rc = evtchn_make_refcounted(port);
+	else {
+		/* bind failed, should close the port now */
+		struct evtchn_close close;
+		close.port = port;
+		if (port != 0 && /* port 0 is never used */
+		    HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
+			BUG();
+		set_port_user(port, NULL);
+	}
 
 	return rc;
 }
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmS-0004VK-AR; Mon, 04 Feb 2013 17:24:32 +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 1U2PmQ-0004TF-79
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.143.99:36480] by server-3.bemta-4.messagelabs.com id
	17/07-08920-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19143 invoked from network); 4 Feb 2013 17:24:29 -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;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890073"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-P1;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:42 +0000
Message-ID: <1359998635-16866-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 01/13] xen: add KERN_DEBUG in printk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..4d9a3a6 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1176,7 +1176,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	spin_lock_irqsave(&debug_lock, flags);
 
-	printk("\nvcpu %d\n  ", cpu);
+	printk(KERN_DEBUG "\nvcpu %d\n  ", cpu);
 
 	for_each_online_cpu(i) {
 		int pending;
@@ -1184,51 +1184,51 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk(KERN_DEBUG "%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
 	}
 	v = per_cpu(xen_vcpu, cpu);
 
-	printk("\npending:\n   ");
+	printk(KERN_DEBUG "\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
-	printk("\nglobal mask:\n   ");
+	printk(KERN_DEBUG "\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk(KERN_DEBUG "%0*lx%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
-	printk("\nglobally unmasked:\n   ");
+	printk(KERN_DEBUG "\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
-	printk("\nlocal cpu%d mask:\n   ", cpu);
+	printk(KERN_DEBUG "\nlocal cpu%d mask:\n   ", cpu);
 	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
-	printk("\nlocally unmasked:\n   ");
+	printk(KERN_DEBUG "\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
 		unsigned long pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
-	printk("\npending list:\n");
+	printk(KERN_DEBUG "\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
 		if (sync_test_bit(i, sh->evtchn_pending)) {
 			int word_idx = i / BITS_PER_LONG;
-			printk("  %d: event %d -> irq %d%s%s%s\n",
+			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
 			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmR-0004Ui-Hj; Mon, 04 Feb 2013 17:24:31 +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 1U2PmP-0004Te-SI
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:29 +0000
Received: from [85.158.143.99:21281] by server-2.bemta-4.messagelabs.com id
	F4/13-01597-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19105 invoked from network); 4 Feb 2013 17:24:28 -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;
	4 Feb 2013 17:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890072"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-ND;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:41 +0000
Message-ID: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2] Implement 3-level event channel in Linux
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 from V1:
* separate mechanical fixes to different changesets
* close evtchn once binding to irq fails
* remove kzalloc()
* always try to register 3-level event channel


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmP-0004TT-0Q; Mon, 04 Feb 2013 17:24:29 +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 1U2PmO-0004TF-CD
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:28 +0000
Received: from [85.158.143.99:36366] by server-3.bemta-4.messagelabs.com id
	7E/F6-08920-BCEEF015; Mon, 04 Feb 2013 17:24:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19034 invoked from network); 4 Feb 2013 17:24:27 -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;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890067"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmK-0001Rd-Rt;
	Mon, 04 Feb 2013 17:24:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:43 +0000
Message-ID: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: ian.campbell@citrix.com, jbeulich@suse.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2] Implement 3-level event channel 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

Changes from V1:
* move all evtchn related macros / struct definitions to event.h
* only allow 3-level evtchn for Dom0 and driver domains
* add evtchn_l3 flag in libxl


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmT-0004Wa-TN; Mon, 04 Feb 2013 17:24:33 +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 1U2PmR-0004Tp-16
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:31 +0000
Received: from [85.158.139.211:10965] by server-9.bemta-5.messagelabs.com id
	2C/42-24440-ECEEF015; Mon, 04 Feb 2013 17:24:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 4 Feb 2013 17:24:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195784"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-81;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:51 +0000
Message-ID: <1359998638-16774-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 08/15] Define N-level event channel
	registration 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/public/event_channel.h |   33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
index 07ff321..f26d6d5 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -71,6 +71,7 @@
 #define EVTCHNOP_bind_vcpu        8
 #define EVTCHNOP_unmask           9
 #define EVTCHNOP_reset           10
+#define EVTCHNOP_register_nlevel 11
 /* ` } */
 
 typedef uint32_t evtchn_port_t;
@@ -258,6 +259,38 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
+ * EVTCHNOP_register_nlevel: Register N-level event channel
+ * NOTES:
+ *  1. Currently only 3-level is supported.
+ *  2. Should fall back to 2-level if this call fails.
+ */
+/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
+ * 256k event channels while 32 bit ones only need 1 page for 32k
+ * event channels. */
+#define EVTCHN_MAX_L3_PAGES 8
+struct evtchn_register_3level {
+    /* IN parameters. */
+    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
+    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
+};
+typedef struct evtchn_register_3level evtchn_register_3level_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_3level_t);
+
+struct evtchn_register_nlevel {
+    /* IN parameters. */
+    uint32_t level;
+    union {
+        evtchn_register_3level_t l3;
+    } u;
+};
+typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_nlevel_t);
+
+/*
  * ` enum neg_errnoval
  * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
  * `
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmR-0004UR-4j; Mon, 04 Feb 2013 17:24:31 +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 1U2PmP-0004TS-FS
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:29 +0000
Received: from [85.158.139.211:60800] by server-1.bemta-5.messagelabs.com id
	05/1F-29263-CCEEF015; Mon, 04 Feb 2013 17:24:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30979 invoked from network); 4 Feb 2013 17:24:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195780"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmK-0001Rd-Vq;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:45 +0000
Message-ID: <1359998638-16774-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 02/15] Move event channel macros / struct
	definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 remove reference to NR_EVTCHN_BUCKETS in struct domain, we can move
those macros / struct definitions to event.h.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/sched.h |   45 ---------------------------------------------
 2 files changed, 46 insertions(+), 45 deletions(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 65ac81a..a1574ea 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -15,6 +15,52 @@
 #include <asm/bitops.h>
 #include <asm/event.h>
 
+#ifndef CONFIG_COMPAT
+#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
+#else
+#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
+#endif
+#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+
+#define EVTCHNS_PER_BUCKET 128
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+
+struct evtchn
+{
+#define ECS_FREE         0 /* Channel is available for use.                  */
+#define ECS_RESERVED     1 /* Channel is reserved.                           */
+#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
+#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
+#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
+#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
+#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
+    u8  state;             /* ECS_* */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
+    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
+    union {
+        struct {
+            domid_t remote_domid;
+        } unbound;     /* state == ECS_UNBOUND */
+        struct {
+            u16            remote_port;
+            struct domain *remote_dom;
+        } interdomain; /* state == ECS_INTERDOMAIN */
+        struct {
+            u16            irq;
+            u16            next_port;
+            u16            prev_port;
+        } pirq;        /* state == ECS_PIRQ */
+        u16 virq;      /* state == ECS_VIRQ */
+    } u;
+#ifdef FLASK_ENABLE
+    void *ssid;
+#endif
+};
+
+int  evtchn_init(struct domain *d); /* from domain_create */
+void evtchn_destroy(struct domain *d); /* from domain_kill */
+void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
+
 /*
  * send_guest_vcpu_virq: Notify guest via a per-VCPU VIRQ.
  *  @v:        VCPU to which virtual IRQ should be sent
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ded7a10..45ad6bd 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -45,51 +45,6 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 /* A global pointer to the initial domain (DOM0). */
 extern struct domain *dom0;
 
-#ifndef CONFIG_COMPAT
-#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
-#else
-#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
-#endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
-#define EVTCHNS_PER_BUCKET 128
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
-
-struct evtchn
-{
-#define ECS_FREE         0 /* Channel is available for use.                  */
-#define ECS_RESERVED     1 /* Channel is reserved.                           */
-#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
-#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
-#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
-#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
-#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
-    u8  state;             /* ECS_* */
-    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
-    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
-    union {
-        struct {
-            domid_t remote_domid;
-        } unbound;     /* state == ECS_UNBOUND */
-        struct {
-            u16            remote_port;
-            struct domain *remote_dom;
-        } interdomain; /* state == ECS_INTERDOMAIN */
-        struct {
-            u16            irq;
-            u16            next_port;
-            u16            prev_port;
-        } pirq;        /* state == ECS_PIRQ */
-        u16 virq;      /* state == ECS_VIRQ */
-    } u;
-#ifdef FLASK_ENABLE
-    void *ssid;
-#endif
-};
-
-int  evtchn_init(struct domain *d); /* from domain_create */
-void evtchn_destroy(struct domain *d); /* from domain_kill */
-void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
-
 struct waitqueue_vcpu;
 
 struct vcpu
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmS-0004Vj-OO; Mon, 04 Feb 2013 17:24:32 +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 1U2PmQ-0004Tp-Gq
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.139.211:48171] by server-9.bemta-5.messagelabs.com id
	97/42-24440-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28431 invoked from network); 4 Feb 2013 17:24:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195782"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-5c;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:49 +0000
Message-ID: <1359998638-16774-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 06/15] Introduce some macros for event
	channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 N-level event channels, the shared bitmaps in the hypervisor are by design
not guaranteed to be contigious.

These macros are used to calculate page number / offset within a page of a
given event channel.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/asm-arm/types.h  |    7 +++++--
 xen/include/asm-x86/config.h |    4 +++-
 xen/include/xen/event.h      |   13 +++++++++++++
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..65562b8 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,10 +41,13 @@ typedef char bool_t;
 #define test_and_clear_bool(b) xchg(&(b), 0)
 
 #endif /* __ASSEMBLY__ */
+#define BYTE_BITORDER  3
+#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
+#define BITS_PER_LONG  (1 << LONG_BITORDER)
 #define LONG_BYTEORDER 2
+#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 
 #endif /* __ARM_TYPES_H__ */
 /*
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index da82e73..b921586 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -8,11 +8,13 @@
 #define __X86_CONFIG_H__
 
 #define LONG_BYTEORDER 3
+#define BYTE_BITORDER 3
+#define LONG_BITORDER (BYTE_BITORDER + LONG_BYTEORDER)
 #define CONFIG_PAGING_LEVELS 4
 
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
-#define BITS_PER_BYTE 8
+#define BITS_PER_BYTE (1 << BYTE_BITORDER)
 
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 1021a1a..4474296 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -39,6 +39,19 @@
 #define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
 
+/* N.B. EVTCHNS_PER_PAGE is always powers of 2, use shifts to optimize */
+#define EVTCHNS_SHIFT (PAGE_SHIFT+BYTE_BITORDER)
+#define EVTCHNS_PER_PAGE (_AC(1,L) << EVTCHNS_SHIFT)
+#define EVTCHN_MASK (~(EVTCHNS_PER_PAGE-1))
+#define EVTCHN_PAGE_NO(chn) ((chn) >> EVTCHNS_SHIFT)
+#define EVTCHN_OFFSET_IN_PAGE(chn) ((chn) & ~EVTCHN_MASK)
+
+#ifndef CONFIG_COMPAT
+#define EVTCHN_WORD_BITORDER(d) LONG_BITORDER
+#else
+#define EVTCHN_WORD_BITORDER(d) (has_32bit_shinfo(d) ? 5 : LONG_BITORDER)
+#endif
+
 struct evtchn
 {
 #define ECS_FREE         0 /* Channel is available for use.                  */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmU-0004Wu-A4; Mon, 04 Feb 2013 17:24:34 +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 1U2PmR-0004TI-9z
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:31 +0000
Received: from [85.158.143.99:36544] by server-1.bemta-4.messagelabs.com id
	28/91-08839-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19199 invoked from network); 4 Feb 2013 17:24:30 -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;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890076"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-3K;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:50 +0000
Message-ID: <1359998635-16866-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 09/13] xen: dynamically allocate
	cpu_evtchn_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 355dbda..94d6570 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -123,8 +123,7 @@ static int *evtchn_to_irq;
 static unsigned long *pirq_eoi_map;
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS_L2/BITS_PER_LONG],
-		      cpu_evtchn_mask);
+static DEFINE_PER_CPU(unsigned long *, cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
 #define VALID_EVTCHN(chn)	((chn) != 0)
@@ -333,7 +332,8 @@ static void init_evtchn_cpu_bindings(void)
 
 	for_each_possible_cpu(i)
 		memset(per_cpu(cpu_evtchn_mask, i),
-		       (i == 0) ? ~0 : 0, sizeof(*per_cpu(cpu_evtchn_mask, i)));
+		       (i == 0) ? ~0 : 0,
+		       sizeof(unsigned long)*(nr_event_channels/BITS_PER_LONG));
 }
 
 static inline void clear_evtchn(int port)
@@ -1835,6 +1835,7 @@ void xen_callback_vector(void) {}
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
+	int cpu;
 	struct shared_info *s = HYPERVISOR_shared_info;
 
 	evtchn_pending = s->evtchn_pending;
@@ -1849,6 +1850,17 @@ void __init xen_init_IRQ(void)
 	for (i = 0; i < nr_event_channels; i++)
 		evtchn_to_irq[i] = -1;
 
+	for_each_possible_cpu(cpu) {
+		void *p;
+		unsigned int nr = nr_event_channels / BITS_PER_LONG;
+
+		p = kzalloc_node(sizeof(unsigned long) * nr,
+				 GFP_KERNEL,
+				 cpu_to_node(cpu));
+		BUG_ON(!p);
+		per_cpu(cpu_evtchn_mask, cpu) = p;
+	}
+
 	init_evtchn_cpu_bindings();
 
 	/* No event channels are 'live' right now. */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmU-0004XG-Lr; Mon, 04 Feb 2013 17:24: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 1U2PmR-0004UG-Im
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:31 +0000
Received: from [85.158.139.211:48294] by server-7.bemta-5.messagelabs.com id
	76/94-11121-ECEEF015; Mon, 04 Feb 2013 17:24:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31203 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195785"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-8W;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:52 +0000
Message-ID: <1359998638-16774-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 09/15] Add control structures for 3-level
	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

The references to shared bitmap pending / mask are embedded in struct domain.
And pointer to the second level selector is embedded in struct vcpu.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/sched.h |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 2f18fe5..1d8c1b5 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include <public/sysctl.h>
 #include <public/vcpu.h>
 #include <public/mem_event.h>
+#include <public/event_channel.h>
 
 #ifdef CONFIG_COMPAT
 #include <compat/vcpu.h>
@@ -57,6 +58,9 @@ struct vcpu
 
     struct domain   *domain;
 
+    /* For 3-level event channels */
+    unsigned long   *evtchn_pending_sel_l2;
+
     struct vcpu     *next_in_list;
 
     s_time_t         periodic_period;
@@ -218,6 +222,8 @@ struct domain
     struct evtchn  **evtchn;
     spinlock_t       event_lock;
     unsigned int     evtchn_level;
+    unsigned long   *evtchn_pending[EVTCHN_MAX_L3_PAGES];
+    unsigned long   *evtchn_mask[EVTCHN_MAX_L3_PAGES];
 
     struct grant_table *grant_table;
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmT-0004Vw-4m; Mon, 04 Feb 2013 17:24:33 +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 1U2PmQ-0004Te-RN
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.143.99:21343] by server-2.bemta-4.messagelabs.com id
	4B/13-01597-ECEEF015; Mon, 04 Feb 2013 17:24:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19177 invoked from network); 4 Feb 2013 17:24:29 -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;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890074"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-0R;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:47 +0000
Message-ID: <1359998635-16866-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 06/13] xen: introduce test_and_set_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 96ed76f..2278851 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -345,6 +345,12 @@ static inline int test_evtchn(int port)
 	return sync_test_bit(port, &s->evtchn_pending[0]);
 }
 
+static inline int test_and_set_mask(int port)
+{
+	struct shared_info *s = HYPERVISOR_shared_info;
+	return sync_test_and_set_bit(port, &s->evtchn_mask[0]);
+}
+
 
 /**
  * notify_remote_via_irq - send event to remote end of event channel via irq
@@ -1464,7 +1470,7 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
+	masked = test_and_set_mask(evtchn);
 	sync_set_bit(evtchn, s->evtchn_pending);
 	if (!masked)
 		unmask_evtchn(evtchn);
@@ -1513,7 +1519,7 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
+		masked = test_and_set_mask(evtchn);
 		sync_set_bit(evtchn, sh->evtchn_pending);
 		if (!masked)
 			unmask_evtchn(evtchn);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmV-0004YS-P5; Mon, 04 Feb 2013 17:24:35 +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 1U2PmS-0004Uu-8f
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.139.211:48359] by server-11.bemta-5.messagelabs.com id
	3E/48-19159-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195792"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-SY;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:44 +0000
Message-ID: <1359998635-16866-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 03/13] xen: fix error handling path if
	xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 call to xen_allocate_irq_dynamic() might return -ev error codes, not
lietral -1.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index d937bf8..96ed76f 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -820,7 +820,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 
 	if (irq == -1) {
 		irq = xen_allocate_irq_dynamic();
-		if (irq == -1)
+		if (irq < 0)
 			goto out;
 
 		irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
@@ -923,7 +923,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
 
 	if (irq == -1) {
 		irq = xen_allocate_irq_dynamic();
-		if (irq == -1)
+		if (irq < 0)
 			goto out;
 
 		irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmW-0004Zq-Th; Mon, 04 Feb 2013 17:24:36 +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 1U2PmS-0004Tp-Oz
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:33 +0000
Received: from [85.158.139.211:48482] by server-9.bemta-5.messagelabs.com id
	9A/52-24440-0DEEF015; Mon, 04 Feb 2013 17:24:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28709 invoked from network); 4 Feb 2013 17:24:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195808"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-2m;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:49 +0000
Message-ID: <1359998635-16866-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 08/13] xen: generalized event channel
	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

Use global pointers in common operations to allow for better code sharing
between N-level event channel.

Functions which are not suitable for sharing are also taken care of.

Also update drivers/xen/evtchn.c to use exported variable instead of macro.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
 drivers/xen/evtchn.c |   12 ++--
 include/xen/events.h |    2 +
 3 files changed, 123 insertions(+), 71 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6019cd9..355dbda 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -51,6 +51,16 @@
 #include <xen/interface/hvm/hvm_op.h>
 #include <xen/interface/hvm/params.h>
 
+/* N-level event channel, starting from 2 */
+unsigned int evtchn_level = 2;
+EXPORT_SYMBOL_GPL(evtchn_level);
+unsigned int nr_event_channels;
+EXPORT_SYMBOL_GPL(nr_event_channels);
+
+/* The following pointers point to pending bitmap and mask bitmap. */
+static unsigned long *evtchn_pending;
+static unsigned long *evtchn_mask;
+
 /*
  * This lock protects updates to the following mapping and reference-count
  * arrays. The lock does not need to be acquired to read the mapping tables.
@@ -113,7 +123,7 @@ static int *evtchn_to_irq;
 static unsigned long *pirq_eoi_map;
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS_L2/BITS_PER_LONG],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -286,12 +296,11 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 }
 
 static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
 					   unsigned int idx)
 {
-	return sh->evtchn_pending[idx] &
+	return evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
-		~sh->evtchn_mask[idx];
+		~evtchn_mask[idx];
 }
 
 static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
@@ -329,26 +338,22 @@ static void init_evtchn_cpu_bindings(void)
 
 static inline void clear_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, &evtchn_pending[0]);
 }
 
 static inline void set_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, &evtchn_pending[0]);
 }
 
 static inline int test_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, &evtchn_pending[0]);
 }
 
 static inline int test_and_set_mask(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_and_set_bit(port, &s->evtchn_mask[0]);
+	return sync_test_and_set_bit(port, &evtchn_mask[0]);
 }
 
 
@@ -371,13 +376,28 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 
 static void mask_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, &evtchn_mask[0]);
+}
+
+static inline void __unmask_local_port_l2(int port)
+{
+	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
+
+	sync_clear_bit(port, &evtchn_mask[0]);
+
+	/*
+	 * The following is basically the equivalent of
+	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
+	 * the interrupt edge' if the channel is masked.
+	 */
+	if (sync_test_bit(port, &evtchn_pending[0]) &&
+	    !sync_test_and_set_bit(port / BITS_PER_LONG,
+				   &vcpu_info->evtchn_pending_sel))
+		vcpu_info->evtchn_upcall_pending = 1;
 }
 
 static void unmask_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
 	unsigned int cpu = get_cpu();
 
 	BUG_ON(!irqs_disabled());
@@ -387,19 +407,13 @@ static void unmask_evtchn(int port)
 		struct evtchn_unmask unmask = { .port = port };
 		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
 	} else {
-		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
-
-		sync_clear_bit(port, &s->evtchn_mask[0]);
-
-		/*
-		 * The following is basically the equivalent of
-		 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
-		 * the interrupt edge' if the channel is masked.
-		 */
-		if (sync_test_bit(port, &s->evtchn_pending[0]) &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
-			vcpu_info->evtchn_upcall_pending = 1;
+		switch (evtchn_level) {
+		case 2:
+			__unmask_local_port_l2(port);
+			break;
+		default:
+			BUG();
+		}
 	}
 
 	put_cpu();
@@ -902,7 +916,7 @@ static int find_virq(unsigned int virq, unsigned int cpu)
 	int port, rc = -ENOENT;
 
 	memset(&status, 0, sizeof(status));
-	for (port = 0; port <= NR_EVENT_CHANNELS; port++) {
+	for (port = 0; port <= nr_event_channels; port++) {
 		status.dom = DOMID_SELF;
 		status.port = port;
 		rc = HYPERVISOR_event_channel_op(EVTCHNOP_status, &status);
@@ -1127,7 +1141,7 @@ int evtchn_get(unsigned int evtchn)
 	struct irq_info *info;
 	int err = -ENOENT;
 
-	if (evtchn >= NR_EVENT_CHANNELS)
+	if (evtchn >= nr_event_channels)
 		return -EINVAL;
 
 	mutex_lock(&irq_mapping_update_lock);
@@ -1170,15 +1184,16 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
 	notify_remote_via_irq(irq);
 }
 
+static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
+
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
-	struct shared_info *sh = HYPERVISOR_shared_info;
-	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
-	int i;
-	unsigned long flags;
+	irqreturn_t rc;
 	static DEFINE_SPINLOCK(debug_lock);
+	unsigned long flags;
+	int cpu = smp_processor_id();
 	struct vcpu_info *v;
+	int i;
 
 	spin_lock_irqsave(&debug_lock, flags);
 
@@ -1195,24 +1210,45 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
 	}
+
+	switch (evtchn_level) {
+	case 2:
+		rc = xen_debug_interrupt_l2(irq, dev_id);
+		break;
+	default:
+		BUG();
+	}
+
+	spin_unlock_irqrestore(&debug_lock, flags);
+	return rc;
+}
+
+static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
+{
+	int cpu = smp_processor_id();
+	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	int i;
+	unsigned long nr_elems = NR_EVENT_CHANNELS_L2 / BITS_PER_LONG;
+	struct vcpu_info *v;
+
 	v = per_cpu(xen_vcpu, cpu);
 
 	printk(KERN_DEBUG "\npending:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
-		       sh->evtchn_pending[i],
+	for (i = nr_elems; i >= 0; i--)
+		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(evtchn_pending[0])*2,
+		       evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk(KERN_DEBUG "\nglobal mask:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
+	for (i = nr_elems-1; i >= 0; i--)
 		printk(KERN_DEBUG "%0*lx%s",
-		       (int)(sizeof(sh->evtchn_mask[0])*2),
-		       sh->evtchn_mask[i],
+		       (int)(sizeof(evtchn_mask[0])*2),
+		       evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk(KERN_DEBUG "\nglobally unmasked:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
-		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
+	for (i = nr_elems-1; i >= 0; i--)
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
+		       evtchn_pending[i] & ~evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk(KERN_DEBUG "\nlocal cpu%d mask:\n   ", cpu);
@@ -1222,32 +1258,30 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk(KERN_DEBUG "\nlocally unmasked:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
-			& ~sh->evtchn_mask[i]
+	for (i = nr_elems-1; i >= 0; i--) {
+		unsigned long pending = evtchn_pending[i]
+			& ~evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk(KERN_DEBUG "\npending list:\n");
-	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
+	for (i = 0; i < NR_EVENT_CHANNELS_L2; i++) {
+		if (sync_test_bit(i, evtchn_pending)) {
 			int word_idx = i / BITS_PER_LONG;
 			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
 			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
 					     ? "" : " l1-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, evtchn_mask)
 					     ? "" : " globally-masked",
 			       sync_test_bit(i, cpu_evtchn)
 					     ? "" : " locally-masked");
 		}
 	}
 
-	spin_unlock_irqrestore(&debug_lock, flags);
-
 	return IRQ_HANDLED;
 }
 
@@ -1269,13 +1303,12 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
  * a bitset of words which contain pending event bits.  The second
  * level is a bitset of pending events themselves.
  */
-static void __xen_evtchn_do_upcall(void)
+static void __xen_evtchn_do_upcall_l2(void)
 {
 	int start_word_idx, start_bit_idx;
 	int word_idx, bit_idx;
 	int i;
 	int cpu = get_cpu();
-	struct shared_info *s = HYPERVISOR_shared_info;
 	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 	unsigned count;
 
@@ -1314,7 +1347,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 			word_idx = __ffs(words);
 
-			pending_bits = active_evtchns(cpu, s, word_idx);
+			pending_bits = active_evtchns(cpu, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
 			if (word_idx == start_word_idx) {
 				/* We scan the starting word in two parts */
@@ -1383,7 +1416,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 	exit_idle();
 	irq_enter();
 
-	__xen_evtchn_do_upcall();
+	switch (evtchn_level) {
+	case 2:
+		__xen_evtchn_do_upcall_l2();
+		break;
+	default:
+		BUG();
+	}
 
 	irq_exit();
 	set_irq_regs(old_regs);
@@ -1391,7 +1430,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 
 void xen_hvm_evtchn_do_upcall(void)
 {
-	__xen_evtchn_do_upcall();
+	switch (evtchn_level) {
+	case 2:
+		__xen_evtchn_do_upcall_l2();
+		break;
+	default:
+		BUG();
+	}
 }
 EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall);
 
@@ -1465,7 +1510,6 @@ static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
 int resend_irq_on_evtchn(unsigned int irq)
 {
 	int masked, evtchn = evtchn_from_irq(irq);
-	struct shared_info *s = HYPERVISOR_shared_info;
 
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
@@ -1513,7 +1557,6 @@ static void mask_ack_dynirq(struct irq_data *data)
 static int retrigger_dynirq(struct irq_data *data)
 {
 	int evtchn = evtchn_from_irq(data->irq);
-	struct shared_info *sh = HYPERVISOR_shared_info;
 	int ret = 0;
 
 	if (VALID_EVTCHN(evtchn)) {
@@ -1689,14 +1732,14 @@ void xen_irq_resume(void)
 	init_evtchn_cpu_bindings();
 
 	/* New event-channel space is not 'live' yet. */
-	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
+	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
 		mask_evtchn(evtchn);
 
 	/* No IRQ <-> event-channel mappings. */
 	list_for_each_entry(info, &xen_irq_list_head, list)
 		info->evtchn = 0; /* zap event-channel binding */
 
-	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
+	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
 		evtchn_to_irq[evtchn] = -1;
 
 	for_each_possible_cpu(cpu) {
@@ -1792,17 +1835,24 @@ void xen_callback_vector(void) {}
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
+	struct shared_info *s = HYPERVISOR_shared_info;
+
+	evtchn_pending = s->evtchn_pending;
+	evtchn_mask = s->evtchn_mask;
+
+	evtchn_level = 2;
+	nr_event_channels = NR_EVENT_CHANNELS_L2;
 
-	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
+	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
 	BUG_ON(!evtchn_to_irq);
-	for (i = 0; i < NR_EVENT_CHANNELS; i++)
+	for (i = 0; i < nr_event_channels; i++)
 		evtchn_to_irq[i] = -1;
 
 	init_evtchn_cpu_bindings();
 
 	/* No event channels are 'live' right now. */
-	for (i = 0; i < NR_EVENT_CHANNELS; i++)
+	for (i = 0; i < nr_event_channels; i++)
 		mask_evtchn(i);
 
 	pirq_needs_eoi = pirq_needs_eoi_flag;
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index ef02dfa..3eecdd7 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -232,7 +232,7 @@ static ssize_t evtchn_write(struct file *file, const char __user *buf,
 	for (i = 0; i < (count/sizeof(evtchn_port_t)); i++) {
 		unsigned port = kbuf[i];
 
-		if (port < NR_EVENT_CHANNELS &&
+		if (port < nr_event_channels &&
 		    get_port_user(port) == u &&
 		    !get_port_enabled(port)) {
 			set_port_enabled(port, true);
@@ -373,7 +373,7 @@ static long evtchn_ioctl(struct file *file,
 			break;
 
 		rc = -EINVAL;
-		if (unbind.port >= NR_EVENT_CHANNELS)
+		if (unbind.port >= nr_event_channels)
 			break;
 
 		spin_lock_irq(&port_user_lock);
@@ -401,7 +401,7 @@ static long evtchn_ioctl(struct file *file,
 		if (copy_from_user(&notify, uarg, sizeof(notify)))
 			break;
 
-		if (notify.port >= NR_EVENT_CHANNELS) {
+		if (notify.port >= nr_event_channels) {
 			rc = -EINVAL;
 		} else if (get_port_user(notify.port) != u) {
 			rc = -ENOTCONN;
@@ -491,7 +491,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
 
 	free_page((unsigned long)u->ring);
 
-	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
+	for (i = 0; i < nr_event_channels; i++) {
 		if (get_port_user(i) != u)
 			continue;
 
@@ -500,7 +500,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
 
 	spin_unlock_irq(&port_user_lock);
 
-	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
+	for (i = 0; i < nr_event_channels; i++) {
 		if (get_port_user(i) != u)
 			continue;
 
@@ -537,7 +537,7 @@ static int __init evtchn_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	port_user = kcalloc(NR_EVENT_CHANNELS, sizeof(*port_user), GFP_KERNEL);
+	port_user = kcalloc(nr_event_channels, sizeof(*port_user), GFP_KERNEL);
 	if (port_user == NULL)
 		return -ENOMEM;
 
diff --git a/include/xen/events.h b/include/xen/events.h
index 04399b2..6b117ac 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
+extern unsigned int nr_event_channels;
+
 #endif	/* _XEN_EVENTS_H */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmT-0004Wa-TN; Mon, 04 Feb 2013 17:24:33 +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 1U2PmR-0004Tp-16
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:31 +0000
Received: from [85.158.139.211:10965] by server-9.bemta-5.messagelabs.com id
	2C/42-24440-ECEEF015; Mon, 04 Feb 2013 17:24:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 4 Feb 2013 17:24:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195784"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-81;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:51 +0000
Message-ID: <1359998638-16774-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 08/15] Define N-level event channel
	registration 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/public/event_channel.h |   33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
index 07ff321..f26d6d5 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -71,6 +71,7 @@
 #define EVTCHNOP_bind_vcpu        8
 #define EVTCHNOP_unmask           9
 #define EVTCHNOP_reset           10
+#define EVTCHNOP_register_nlevel 11
 /* ` } */
 
 typedef uint32_t evtchn_port_t;
@@ -258,6 +259,38 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
+ * EVTCHNOP_register_nlevel: Register N-level event channel
+ * NOTES:
+ *  1. Currently only 3-level is supported.
+ *  2. Should fall back to 2-level if this call fails.
+ */
+/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
+ * 256k event channels while 32 bit ones only need 1 page for 32k
+ * event channels. */
+#define EVTCHN_MAX_L3_PAGES 8
+struct evtchn_register_3level {
+    /* IN parameters. */
+    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
+    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
+};
+typedef struct evtchn_register_3level evtchn_register_3level_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_3level_t);
+
+struct evtchn_register_nlevel {
+    /* IN parameters. */
+    uint32_t level;
+    union {
+        evtchn_register_3level_t l3;
+    } u;
+};
+typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_nlevel_t);
+
+/*
  * ` enum neg_errnoval
  * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
  * `
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmS-0004VK-AR; Mon, 04 Feb 2013 17:24:32 +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 1U2PmQ-0004TF-79
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.143.99:36480] by server-3.bemta-4.messagelabs.com id
	17/07-08920-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19143 invoked from network); 4 Feb 2013 17:24:29 -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;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890073"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-P1;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:42 +0000
Message-ID: <1359998635-16866-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 01/13] xen: add KERN_DEBUG in printk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..4d9a3a6 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1176,7 +1176,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	spin_lock_irqsave(&debug_lock, flags);
 
-	printk("\nvcpu %d\n  ", cpu);
+	printk(KERN_DEBUG "\nvcpu %d\n  ", cpu);
 
 	for_each_online_cpu(i) {
 		int pending;
@@ -1184,51 +1184,51 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk(KERN_DEBUG "%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
 	}
 	v = per_cpu(xen_vcpu, cpu);
 
-	printk("\npending:\n   ");
+	printk(KERN_DEBUG "\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
-	printk("\nglobal mask:\n   ");
+	printk(KERN_DEBUG "\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk(KERN_DEBUG "%0*lx%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
-	printk("\nglobally unmasked:\n   ");
+	printk(KERN_DEBUG "\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
-	printk("\nlocal cpu%d mask:\n   ", cpu);
+	printk(KERN_DEBUG "\nlocal cpu%d mask:\n   ", cpu);
 	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
-	printk("\nlocally unmasked:\n   ");
+	printk(KERN_DEBUG "\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
 		unsigned long pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
-	printk("\npending list:\n");
+	printk(KERN_DEBUG "\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
 		if (sync_test_bit(i, sh->evtchn_pending)) {
 			int word_idx = i / BITS_PER_LONG;
-			printk("  %d: event %d -> irq %d%s%s%s\n",
+			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
 			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmS-0004Vj-OO; Mon, 04 Feb 2013 17:24:32 +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 1U2PmQ-0004Tp-Gq
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.139.211:48171] by server-9.bemta-5.messagelabs.com id
	97/42-24440-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28431 invoked from network); 4 Feb 2013 17:24:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195782"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-5c;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:49 +0000
Message-ID: <1359998638-16774-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 06/15] Introduce some macros for event
	channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 N-level event channels, the shared bitmaps in the hypervisor are by design
not guaranteed to be contigious.

These macros are used to calculate page number / offset within a page of a
given event channel.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/asm-arm/types.h  |    7 +++++--
 xen/include/asm-x86/config.h |    4 +++-
 xen/include/xen/event.h      |   13 +++++++++++++
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..65562b8 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,10 +41,13 @@ typedef char bool_t;
 #define test_and_clear_bool(b) xchg(&(b), 0)
 
 #endif /* __ASSEMBLY__ */
+#define BYTE_BITORDER  3
+#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
+#define BITS_PER_LONG  (1 << LONG_BITORDER)
 #define LONG_BYTEORDER 2
+#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 
 #endif /* __ARM_TYPES_H__ */
 /*
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index da82e73..b921586 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -8,11 +8,13 @@
 #define __X86_CONFIG_H__
 
 #define LONG_BYTEORDER 3
+#define BYTE_BITORDER 3
+#define LONG_BITORDER (BYTE_BITORDER + LONG_BYTEORDER)
 #define CONFIG_PAGING_LEVELS 4
 
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
-#define BITS_PER_BYTE 8
+#define BITS_PER_BYTE (1 << BYTE_BITORDER)
 
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 1021a1a..4474296 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -39,6 +39,19 @@
 #define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
 
+/* N.B. EVTCHNS_PER_PAGE is always powers of 2, use shifts to optimize */
+#define EVTCHNS_SHIFT (PAGE_SHIFT+BYTE_BITORDER)
+#define EVTCHNS_PER_PAGE (_AC(1,L) << EVTCHNS_SHIFT)
+#define EVTCHN_MASK (~(EVTCHNS_PER_PAGE-1))
+#define EVTCHN_PAGE_NO(chn) ((chn) >> EVTCHNS_SHIFT)
+#define EVTCHN_OFFSET_IN_PAGE(chn) ((chn) & ~EVTCHN_MASK)
+
+#ifndef CONFIG_COMPAT
+#define EVTCHN_WORD_BITORDER(d) LONG_BITORDER
+#else
+#define EVTCHN_WORD_BITORDER(d) (has_32bit_shinfo(d) ? 5 : LONG_BITORDER)
+#endif
+
 struct evtchn
 {
 #define ECS_FREE         0 /* Channel is available for use.                  */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmP-0004TT-0Q; Mon, 04 Feb 2013 17:24:29 +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 1U2PmO-0004TF-CD
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:28 +0000
Received: from [85.158.143.99:36366] by server-3.bemta-4.messagelabs.com id
	7E/F6-08920-BCEEF015; Mon, 04 Feb 2013 17:24:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19034 invoked from network); 4 Feb 2013 17:24:27 -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;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890067"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmK-0001Rd-Rt;
	Mon, 04 Feb 2013 17:24:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:43 +0000
Message-ID: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: ian.campbell@citrix.com, jbeulich@suse.com, david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2] Implement 3-level event channel 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

Changes from V1:
* move all evtchn related macros / struct definitions to event.h
* only allow 3-level evtchn for Dom0 and driver domains
* add evtchn_l3 flag in libxl


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmT-0004WM-HN; Mon, 04 Feb 2013 17:24:33 +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 1U2PmQ-0004Tq-OD
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.139.211:48195] by server-16.bemta-5.messagelabs.com id
	86/E5-14948-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31071 invoked from network); 4 Feb 2013 17:24:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195783"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-7N;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:50 +0000
Message-ID: <1359998638-16774-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 07/15] Update Xen public header
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/public/xen.h |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fe44eb5..ba5d045 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -554,9 +554,16 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
 
 /*
  * Event channel endpoints per domain:
+ * 2-level:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
+ * 3-level:
+ *  32k if a long is 32 bits; 256k if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
+#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
+#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
+#endif
 
 struct vcpu_time_info {
     /*
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmQ-0004U7-Oe; Mon, 04 Feb 2013 17:24:30 +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 1U2PmO-0004TJ-Tz
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:29 +0000
Received: from [85.158.139.211:48026] by server-2.bemta-5.messagelabs.com id
	D0/CF-16911-CCEEF015; Mon, 04 Feb 2013 17:24:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30920 invoked from network); 4 Feb 2013 17:24:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195779"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmK-0001Rd-UA;
	Mon, 04 Feb 2013 17:24:24 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:44 +0000
Message-ID: <1359998638-16774-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 01/15] Dynamically allocate d->evtchn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 we move to N level evtchn we need bigger d->evtchn, as a result
this will bloat struct domain. So move this array out of struct domain
and allocate a dedicated page for it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   17 +++++++++++++++--
 xen/include/xen/sched.h    |    2 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9231eb0..3293f91 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1172,15 +1172,26 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
 
 int evtchn_init(struct domain *d)
 {
+    BUILD_BUG_ON(sizeof(struct evtchn *) * NR_EVTCHN_BUCKETS > PAGE_SIZE);
+    d->evtchn = alloc_xenheap_page();
+
+    if ( d->evtchn == NULL )
+        return -ENOMEM;
+    clear_page(d->evtchn);
+
     spin_lock_init(&d->event_lock);
-    if ( get_free_port(d) != 0 )
+    if ( get_free_port(d) != 0 ) {
+        free_xenheap_page(d->evtchn);
         return -EINVAL;
+    }
     evtchn_from_port(d, 0)->state = ECS_RESERVED;
 
 #if MAX_VIRT_CPUS > BITS_PER_LONG
     d->poll_mask = xmalloc_array(unsigned long, BITS_TO_LONGS(MAX_VIRT_CPUS));
-    if ( !d->poll_mask )
+    if ( !d->poll_mask ) {
+        free_xenheap_page(d->evtchn);
         return -ENOMEM;
+    }
     bitmap_zero(d->poll_mask, MAX_VIRT_CPUS);
 #endif
 
@@ -1214,6 +1225,8 @@ void evtchn_destroy(struct domain *d)
     spin_unlock(&d->event_lock);
 
     clear_global_virq_handlers(d);
+
+    free_xenheap_page(d->evtchn);
 }
 
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 39f85d2..ded7a10 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -260,7 +260,7 @@ struct domain
     spinlock_t       rangesets_lock;
 
     /* Event channel information. */
-    struct evtchn   *evtchn[NR_EVTCHN_BUCKETS];
+    struct evtchn  **evtchn;
     spinlock_t       event_lock;
 
     struct grant_table *grant_table;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmU-0004Wu-A4; Mon, 04 Feb 2013 17:24:34 +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 1U2PmR-0004TI-9z
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:31 +0000
Received: from [85.158.143.99:36544] by server-1.bemta-4.messagelabs.com id
	28/91-08839-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19199 invoked from network); 4 Feb 2013 17:24:30 -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;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890076"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-3K;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:50 +0000
Message-ID: <1359998635-16866-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 09/13] xen: dynamically allocate
	cpu_evtchn_mask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 355dbda..94d6570 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -123,8 +123,7 @@ static int *evtchn_to_irq;
 static unsigned long *pirq_eoi_map;
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS_L2/BITS_PER_LONG],
-		      cpu_evtchn_mask);
+static DEFINE_PER_CPU(unsigned long *, cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
 #define VALID_EVTCHN(chn)	((chn) != 0)
@@ -333,7 +332,8 @@ static void init_evtchn_cpu_bindings(void)
 
 	for_each_possible_cpu(i)
 		memset(per_cpu(cpu_evtchn_mask, i),
-		       (i == 0) ? ~0 : 0, sizeof(*per_cpu(cpu_evtchn_mask, i)));
+		       (i == 0) ? ~0 : 0,
+		       sizeof(unsigned long)*(nr_event_channels/BITS_PER_LONG));
 }
 
 static inline void clear_evtchn(int port)
@@ -1835,6 +1835,7 @@ void xen_callback_vector(void) {}
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
+	int cpu;
 	struct shared_info *s = HYPERVISOR_shared_info;
 
 	evtchn_pending = s->evtchn_pending;
@@ -1849,6 +1850,17 @@ void __init xen_init_IRQ(void)
 	for (i = 0; i < nr_event_channels; i++)
 		evtchn_to_irq[i] = -1;
 
+	for_each_possible_cpu(cpu) {
+		void *p;
+		unsigned int nr = nr_event_channels / BITS_PER_LONG;
+
+		p = kzalloc_node(sizeof(unsigned long) * nr,
+				 GFP_KERNEL,
+				 cpu_to_node(cpu));
+		BUG_ON(!p);
+		per_cpu(cpu_evtchn_mask, cpu) = p;
+	}
+
 	init_evtchn_cpu_bindings();
 
 	/* No event channels are 'live' right now. */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmW-0004Yf-43; Mon, 04 Feb 2013 17:24:36 +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 1U2PmS-0004Uo-69
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.139.211:61044] by server-8.bemta-5.messagelabs.com id
	88/EF-19075-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28654 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195786"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-3p;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:48 +0000
Message-ID: <1359998638-16774-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 05/15] Add evtchn_is_{pending,
	masked} and evtchn_clear_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 code paths access the arrays in shared info directly. This only
works with 2-level event channel.

Add functions to abstract away implementation details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/irq.c         |    7 +++----
 xen/common/event_channel.c |   22 +++++++++++++++++++---
 xen/common/keyhandler.c    |    6 ++----
 xen/common/schedule.c      |    2 +-
 xen/include/xen/event.h    |    6 ++++++
 5 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 068c5a0..216271b 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1452,7 +1452,7 @@ int pirq_guest_unmask(struct domain *d)
         {
             pirq = pirqs[i]->pirq;
             if ( pirqs[i]->masked &&
-                 !test_bit(pirqs[i]->evtchn, &shared_info(d, evtchn_mask)) )
+                 !evtchn_is_masked(d, pirqs[i]->evtchn) )
                 pirq_guest_eoi(pirqs[i]);
         }
     } while ( ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
@@ -2093,13 +2093,12 @@ static void dump_irqs(unsigned char key)
                 info = pirq_info(d, pirq);
                 printk("%u:%3d(%c%c%c%c)",
                        d->domain_id, pirq,
-                       (test_bit(info->evtchn,
-                                 &shared_info(d, evtchn_pending)) ?
+                       (evtchn_is_pending(d, info->evtchn) ?
                         'P' : '-'),
                        (test_bit(info->evtchn / BITS_PER_EVTCHN_WORD(d),
                                  &vcpu_info(d->vcpu[0], evtchn_pending_sel)) ?
                         'S' : '-'),
-                       (test_bit(info->evtchn, &shared_info(d, evtchn_mask)) ?
+                       (evtchn_is_masked(d, info->evtchn) ?
                         'M' : '-'),
                        (info->masked ? 'M' : '-'));
                 if ( i != action->nr_guests )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43ee854..37fecee 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -95,6 +95,7 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
 static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
 
 static int virq_is_global(uint32_t virq)
 {
@@ -156,6 +157,16 @@ static int get_free_port(struct domain *d)
     return port;
 }
 
+int evtchn_is_pending(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_pending));
+}
+
+int evtchn_is_masked(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_mask));
+}
+
 
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
@@ -529,7 +540,7 @@ static long __evtchn_close(struct domain *d1, int port1)
     }
 
     /* Clear pending event to avoid unexpected behavior on re-bind. */
-    clear_bit(port1, &shared_info(d1, evtchn_pending));
+    evtchn_clear_pending(d1, port1);
 
     /* Reset binding to vcpu0 when the channel is freed. */
     chn1->state          = ECS_FREE;
@@ -653,6 +664,11 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_clear_pending(struct domain *d, int port)
+{
+    clear_bit(port, &shared_info(d, evtchn_pending));
+}
+
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
@@ -1283,8 +1299,8 @@ static void domain_dump_evtchn_info(struct domain *d)
 
         printk("    %4u [%d/%d]: s=%d n=%d x=%d",
                port,
-               !!test_bit(port, &shared_info(d, evtchn_pending)),
-               !!test_bit(port, &shared_info(d, evtchn_mask)),
+               !!evtchn_is_pending(d, port),
+               !!evtchn_is_masked(d, port),
                chn->state, chn->notify_vcpu_id, chn->xen_consumer);
 
         switch ( chn->state )
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 2c5c230..16bc452 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -301,10 +301,8 @@ static void dump_domains(unsigned char key)
             printk("Notifying guest %d:%d (virq %d, port %d, stat %d/%d/%d)\n",
                    d->domain_id, v->vcpu_id,
                    VIRQ_DEBUG, v->virq_to_evtchn[VIRQ_DEBUG],
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_pending)),
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_mask)),
+                   evtchn_is_pending(d, v->virq_to_evtchn[VIRQ_DEBUG]),
+                   evtchn_is_masked(d, v->virq_to_evtchn[VIRQ_DEBUG]),
                    test_bit(v->virq_to_evtchn[VIRQ_DEBUG] /
                             BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)));
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e6a90d8..1bf010e 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -693,7 +693,7 @@ static long do_poll(struct sched_poll *sched_poll)
             goto out;
 
         rc = 0;
-        if ( test_bit(port, &shared_info(d, evtchn_pending)) )
+        if ( evtchn_is_pending(d, port) )
             goto out;
     }
 
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 59778cf..1021a1a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -114,6 +114,12 @@ int evtchn_unmask(unsigned int port);
 /* Move all PIRQs after a vCPU was moved to another pCPU. */
 void evtchn_move_pirqs(struct vcpu *v);
 
+/* Tell a given event-channel port is pending or not */
+int evtchn_is_pending(struct domain *d, int port);
+
+/* Tell a given event-channel port is masked or not */
+int evtchn_is_masked(struct domain *d, int port);
+
 /* Allocate/free a Xen-attached event channel port. */
 typedef void (*xen_event_channel_notification_t)(
     struct vcpu *v, unsigned int port);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmV-0004Xb-1f; Mon, 04 Feb 2013 17:24:35 +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 1U2PmR-0004TF-TD
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.143.99:36574] by server-3.bemta-4.messagelabs.com id
	00/17-08920-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19228 invoked from network); 4 Feb 2013 17:24:31 -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;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890077"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-Us;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:46 +0000
Message-ID: <1359998635-16866-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 05/13] xen: sync public 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h           |    9 ++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
index f494292..9d8b9e7 100644
--- a/include/xen/interface/event_channel.h
+++ b/include/xen/interface/event_channel.h
@@ -190,6 +190,39 @@ struct evtchn_reset {
 };
 typedef struct evtchn_reset evtchn_reset_t;
 
+/*
+ * EVTCHNOP_register_nlevel: Register N-level event channel
+ * NOTES:
+ *  1. Currently only 3-level is supported.
+ *  2. Should fall back to 2-level if this call fails.
+ */
+#define EVTCHNOP_register_nlevel 11
+/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
+ * 256k event channels while 32 bit ones only need 1 page for 32k
+ * event channels. */
+#define EVTCHN_MAX_L3_PAGES 8
+struct evtchn_register_3level {
+	/* IN parameters. */
+	uint32_t nr_pages; /* for evtchn_{pending,mask} */
+	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
+	GUEST_HANDLE(ulong) evtchn_pending;
+	GUEST_HANDLE(ulong) evtchn_mask;
+	GUEST_HANDLE(ulong) l2sel_mfns;
+	GUEST_HANDLE(ulong) l2sel_offsets;
+};
+typedef struct evtchn_register_3level evtchn_register_3level_t;
+DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
+
+struct evtchn_register_nlevel {
+	/* IN parameters. */
+	uint32_t level;
+	union {
+		evtchn_register_3level_t l3;
+	} u;
+};
+typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
+DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
+
 struct evtchn_op {
 	uint32_t cmd; /* EVTCHNOP_* */
 	union {
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..5220e33 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
 
 /*
  * Event channel endpoints per domain:
+ * 2-level:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
+ * 3-level:
+ *  32k if a long is 32 bits; 256k if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
+#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
+#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
+#endif
 
 struct vcpu_time_info {
 	/*
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmW-0004Zq-Th; Mon, 04 Feb 2013 17:24:36 +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 1U2PmS-0004Tp-Oz
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:33 +0000
Received: from [85.158.139.211:48482] by server-9.bemta-5.messagelabs.com id
	9A/52-24440-0DEEF015; Mon, 04 Feb 2013 17:24:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28709 invoked from network); 4 Feb 2013 17:24:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195808"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-2m;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:49 +0000
Message-ID: <1359998635-16866-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 08/13] xen: generalized event channel
	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

Use global pointers in common operations to allow for better code sharing
between N-level event channel.

Functions which are not suitable for sharing are also taken care of.

Also update drivers/xen/evtchn.c to use exported variable instead of macro.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
 drivers/xen/evtchn.c |   12 ++--
 include/xen/events.h |    2 +
 3 files changed, 123 insertions(+), 71 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6019cd9..355dbda 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -51,6 +51,16 @@
 #include <xen/interface/hvm/hvm_op.h>
 #include <xen/interface/hvm/params.h>
 
+/* N-level event channel, starting from 2 */
+unsigned int evtchn_level = 2;
+EXPORT_SYMBOL_GPL(evtchn_level);
+unsigned int nr_event_channels;
+EXPORT_SYMBOL_GPL(nr_event_channels);
+
+/* The following pointers point to pending bitmap and mask bitmap. */
+static unsigned long *evtchn_pending;
+static unsigned long *evtchn_mask;
+
 /*
  * This lock protects updates to the following mapping and reference-count
  * arrays. The lock does not need to be acquired to read the mapping tables.
@@ -113,7 +123,7 @@ static int *evtchn_to_irq;
 static unsigned long *pirq_eoi_map;
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS_L2/BITS_PER_LONG],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -286,12 +296,11 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 }
 
 static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
 					   unsigned int idx)
 {
-	return sh->evtchn_pending[idx] &
+	return evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
-		~sh->evtchn_mask[idx];
+		~evtchn_mask[idx];
 }
 
 static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
@@ -329,26 +338,22 @@ static void init_evtchn_cpu_bindings(void)
 
 static inline void clear_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, &evtchn_pending[0]);
 }
 
 static inline void set_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, &evtchn_pending[0]);
 }
 
 static inline int test_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, &evtchn_pending[0]);
 }
 
 static inline int test_and_set_mask(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_and_set_bit(port, &s->evtchn_mask[0]);
+	return sync_test_and_set_bit(port, &evtchn_mask[0]);
 }
 
 
@@ -371,13 +376,28 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 
 static void mask_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, &evtchn_mask[0]);
+}
+
+static inline void __unmask_local_port_l2(int port)
+{
+	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
+
+	sync_clear_bit(port, &evtchn_mask[0]);
+
+	/*
+	 * The following is basically the equivalent of
+	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
+	 * the interrupt edge' if the channel is masked.
+	 */
+	if (sync_test_bit(port, &evtchn_pending[0]) &&
+	    !sync_test_and_set_bit(port / BITS_PER_LONG,
+				   &vcpu_info->evtchn_pending_sel))
+		vcpu_info->evtchn_upcall_pending = 1;
 }
 
 static void unmask_evtchn(int port)
 {
-	struct shared_info *s = HYPERVISOR_shared_info;
 	unsigned int cpu = get_cpu();
 
 	BUG_ON(!irqs_disabled());
@@ -387,19 +407,13 @@ static void unmask_evtchn(int port)
 		struct evtchn_unmask unmask = { .port = port };
 		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
 	} else {
-		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
-
-		sync_clear_bit(port, &s->evtchn_mask[0]);
-
-		/*
-		 * The following is basically the equivalent of
-		 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
-		 * the interrupt edge' if the channel is masked.
-		 */
-		if (sync_test_bit(port, &s->evtchn_pending[0]) &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
-			vcpu_info->evtchn_upcall_pending = 1;
+		switch (evtchn_level) {
+		case 2:
+			__unmask_local_port_l2(port);
+			break;
+		default:
+			BUG();
+		}
 	}
 
 	put_cpu();
@@ -902,7 +916,7 @@ static int find_virq(unsigned int virq, unsigned int cpu)
 	int port, rc = -ENOENT;
 
 	memset(&status, 0, sizeof(status));
-	for (port = 0; port <= NR_EVENT_CHANNELS; port++) {
+	for (port = 0; port <= nr_event_channels; port++) {
 		status.dom = DOMID_SELF;
 		status.port = port;
 		rc = HYPERVISOR_event_channel_op(EVTCHNOP_status, &status);
@@ -1127,7 +1141,7 @@ int evtchn_get(unsigned int evtchn)
 	struct irq_info *info;
 	int err = -ENOENT;
 
-	if (evtchn >= NR_EVENT_CHANNELS)
+	if (evtchn >= nr_event_channels)
 		return -EINVAL;
 
 	mutex_lock(&irq_mapping_update_lock);
@@ -1170,15 +1184,16 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
 	notify_remote_via_irq(irq);
 }
 
+static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
+
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
-	struct shared_info *sh = HYPERVISOR_shared_info;
-	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
-	int i;
-	unsigned long flags;
+	irqreturn_t rc;
 	static DEFINE_SPINLOCK(debug_lock);
+	unsigned long flags;
+	int cpu = smp_processor_id();
 	struct vcpu_info *v;
+	int i;
 
 	spin_lock_irqsave(&debug_lock, flags);
 
@@ -1195,24 +1210,45 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
 	}
+
+	switch (evtchn_level) {
+	case 2:
+		rc = xen_debug_interrupt_l2(irq, dev_id);
+		break;
+	default:
+		BUG();
+	}
+
+	spin_unlock_irqrestore(&debug_lock, flags);
+	return rc;
+}
+
+static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
+{
+	int cpu = smp_processor_id();
+	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	int i;
+	unsigned long nr_elems = NR_EVENT_CHANNELS_L2 / BITS_PER_LONG;
+	struct vcpu_info *v;
+
 	v = per_cpu(xen_vcpu, cpu);
 
 	printk(KERN_DEBUG "\npending:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
-		       sh->evtchn_pending[i],
+	for (i = nr_elems; i >= 0; i--)
+		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(evtchn_pending[0])*2,
+		       evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk(KERN_DEBUG "\nglobal mask:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
+	for (i = nr_elems-1; i >= 0; i--)
 		printk(KERN_DEBUG "%0*lx%s",
-		       (int)(sizeof(sh->evtchn_mask[0])*2),
-		       sh->evtchn_mask[i],
+		       (int)(sizeof(evtchn_mask[0])*2),
+		       evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk(KERN_DEBUG "\nglobally unmasked:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
-		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
+	for (i = nr_elems-1; i >= 0; i--)
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
+		       evtchn_pending[i] & ~evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk(KERN_DEBUG "\nlocal cpu%d mask:\n   ", cpu);
@@ -1222,32 +1258,30 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk(KERN_DEBUG "\nlocally unmasked:\n   ");
-	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
-			& ~sh->evtchn_mask[i]
+	for (i = nr_elems-1; i >= 0; i--) {
+		unsigned long pending = evtchn_pending[i]
+			& ~evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk(KERN_DEBUG "\npending list:\n");
-	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
+	for (i = 0; i < NR_EVENT_CHANNELS_L2; i++) {
+		if (sync_test_bit(i, evtchn_pending)) {
 			int word_idx = i / BITS_PER_LONG;
 			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
 			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
 					     ? "" : " l1-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, evtchn_mask)
 					     ? "" : " globally-masked",
 			       sync_test_bit(i, cpu_evtchn)
 					     ? "" : " locally-masked");
 		}
 	}
 
-	spin_unlock_irqrestore(&debug_lock, flags);
-
 	return IRQ_HANDLED;
 }
 
@@ -1269,13 +1303,12 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
  * a bitset of words which contain pending event bits.  The second
  * level is a bitset of pending events themselves.
  */
-static void __xen_evtchn_do_upcall(void)
+static void __xen_evtchn_do_upcall_l2(void)
 {
 	int start_word_idx, start_bit_idx;
 	int word_idx, bit_idx;
 	int i;
 	int cpu = get_cpu();
-	struct shared_info *s = HYPERVISOR_shared_info;
 	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 	unsigned count;
 
@@ -1314,7 +1347,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 			word_idx = __ffs(words);
 
-			pending_bits = active_evtchns(cpu, s, word_idx);
+			pending_bits = active_evtchns(cpu, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
 			if (word_idx == start_word_idx) {
 				/* We scan the starting word in two parts */
@@ -1383,7 +1416,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 	exit_idle();
 	irq_enter();
 
-	__xen_evtchn_do_upcall();
+	switch (evtchn_level) {
+	case 2:
+		__xen_evtchn_do_upcall_l2();
+		break;
+	default:
+		BUG();
+	}
 
 	irq_exit();
 	set_irq_regs(old_regs);
@@ -1391,7 +1430,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 
 void xen_hvm_evtchn_do_upcall(void)
 {
-	__xen_evtchn_do_upcall();
+	switch (evtchn_level) {
+	case 2:
+		__xen_evtchn_do_upcall_l2();
+		break;
+	default:
+		BUG();
+	}
 }
 EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall);
 
@@ -1465,7 +1510,6 @@ static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
 int resend_irq_on_evtchn(unsigned int irq)
 {
 	int masked, evtchn = evtchn_from_irq(irq);
-	struct shared_info *s = HYPERVISOR_shared_info;
 
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
@@ -1513,7 +1557,6 @@ static void mask_ack_dynirq(struct irq_data *data)
 static int retrigger_dynirq(struct irq_data *data)
 {
 	int evtchn = evtchn_from_irq(data->irq);
-	struct shared_info *sh = HYPERVISOR_shared_info;
 	int ret = 0;
 
 	if (VALID_EVTCHN(evtchn)) {
@@ -1689,14 +1732,14 @@ void xen_irq_resume(void)
 	init_evtchn_cpu_bindings();
 
 	/* New event-channel space is not 'live' yet. */
-	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
+	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
 		mask_evtchn(evtchn);
 
 	/* No IRQ <-> event-channel mappings. */
 	list_for_each_entry(info, &xen_irq_list_head, list)
 		info->evtchn = 0; /* zap event-channel binding */
 
-	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
+	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
 		evtchn_to_irq[evtchn] = -1;
 
 	for_each_possible_cpu(cpu) {
@@ -1792,17 +1835,24 @@ void xen_callback_vector(void) {}
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
+	struct shared_info *s = HYPERVISOR_shared_info;
+
+	evtchn_pending = s->evtchn_pending;
+	evtchn_mask = s->evtchn_mask;
+
+	evtchn_level = 2;
+	nr_event_channels = NR_EVENT_CHANNELS_L2;
 
-	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
+	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
 	BUG_ON(!evtchn_to_irq);
-	for (i = 0; i < NR_EVENT_CHANNELS; i++)
+	for (i = 0; i < nr_event_channels; i++)
 		evtchn_to_irq[i] = -1;
 
 	init_evtchn_cpu_bindings();
 
 	/* No event channels are 'live' right now. */
-	for (i = 0; i < NR_EVENT_CHANNELS; i++)
+	for (i = 0; i < nr_event_channels; i++)
 		mask_evtchn(i);
 
 	pirq_needs_eoi = pirq_needs_eoi_flag;
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index ef02dfa..3eecdd7 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -232,7 +232,7 @@ static ssize_t evtchn_write(struct file *file, const char __user *buf,
 	for (i = 0; i < (count/sizeof(evtchn_port_t)); i++) {
 		unsigned port = kbuf[i];
 
-		if (port < NR_EVENT_CHANNELS &&
+		if (port < nr_event_channels &&
 		    get_port_user(port) == u &&
 		    !get_port_enabled(port)) {
 			set_port_enabled(port, true);
@@ -373,7 +373,7 @@ static long evtchn_ioctl(struct file *file,
 			break;
 
 		rc = -EINVAL;
-		if (unbind.port >= NR_EVENT_CHANNELS)
+		if (unbind.port >= nr_event_channels)
 			break;
 
 		spin_lock_irq(&port_user_lock);
@@ -401,7 +401,7 @@ static long evtchn_ioctl(struct file *file,
 		if (copy_from_user(&notify, uarg, sizeof(notify)))
 			break;
 
-		if (notify.port >= NR_EVENT_CHANNELS) {
+		if (notify.port >= nr_event_channels) {
 			rc = -EINVAL;
 		} else if (get_port_user(notify.port) != u) {
 			rc = -ENOTCONN;
@@ -491,7 +491,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
 
 	free_page((unsigned long)u->ring);
 
-	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
+	for (i = 0; i < nr_event_channels; i++) {
 		if (get_port_user(i) != u)
 			continue;
 
@@ -500,7 +500,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
 
 	spin_unlock_irq(&port_user_lock);
 
-	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
+	for (i = 0; i < nr_event_channels; i++) {
 		if (get_port_user(i) != u)
 			continue;
 
@@ -537,7 +537,7 @@ static int __init evtchn_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	port_user = kcalloc(NR_EVENT_CHANNELS, sizeof(*port_user), GFP_KERNEL);
+	port_user = kcalloc(nr_event_channels, sizeof(*port_user), GFP_KERNEL);
 	if (port_user == NULL)
 		return -ENOMEM;
 
diff --git a/include/xen/events.h b/include/xen/events.h
index 04399b2..6b117ac 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
+extern unsigned int nr_event_channels;
+
 #endif	/* _XEN_EVENTS_H */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmT-0004WM-HN; Mon, 04 Feb 2013 17:24:33 +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 1U2PmQ-0004Tq-OD
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:30 +0000
Received: from [85.158.139.211:48195] by server-16.bemta-5.messagelabs.com id
	86/E5-14948-DCEEF015; Mon, 04 Feb 2013 17:24:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1359998666!19975343!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31071 invoked from network); 4 Feb 2013 17:24:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195783"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-7N;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:50 +0000
Message-ID: <1359998638-16774-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 07/15] Update Xen public header
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/public/xen.h |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fe44eb5..ba5d045 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -554,9 +554,16 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
 
 /*
  * Event channel endpoints per domain:
+ * 2-level:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
+ * 3-level:
+ *  32k if a long is 32 bits; 256k if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
+#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
+#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
+#endif
 
 struct vcpu_time_info {
     /*
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmW-0004Yf-43; Mon, 04 Feb 2013 17:24:36 +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 1U2PmS-0004Uo-69
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.139.211:61044] by server-8.bemta-5.messagelabs.com id
	88/EF-19075-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1359998667!19931908!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28654 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195786"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-3p;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:48 +0000
Message-ID: <1359998638-16774-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 05/15] Add evtchn_is_{pending,
	masked} and evtchn_clear_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 code paths access the arrays in shared info directly. This only
works with 2-level event channel.

Add functions to abstract away implementation details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/irq.c         |    7 +++----
 xen/common/event_channel.c |   22 +++++++++++++++++++---
 xen/common/keyhandler.c    |    6 ++----
 xen/common/schedule.c      |    2 +-
 xen/include/xen/event.h    |    6 ++++++
 5 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 068c5a0..216271b 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1452,7 +1452,7 @@ int pirq_guest_unmask(struct domain *d)
         {
             pirq = pirqs[i]->pirq;
             if ( pirqs[i]->masked &&
-                 !test_bit(pirqs[i]->evtchn, &shared_info(d, evtchn_mask)) )
+                 !evtchn_is_masked(d, pirqs[i]->evtchn) )
                 pirq_guest_eoi(pirqs[i]);
         }
     } while ( ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
@@ -2093,13 +2093,12 @@ static void dump_irqs(unsigned char key)
                 info = pirq_info(d, pirq);
                 printk("%u:%3d(%c%c%c%c)",
                        d->domain_id, pirq,
-                       (test_bit(info->evtchn,
-                                 &shared_info(d, evtchn_pending)) ?
+                       (evtchn_is_pending(d, info->evtchn) ?
                         'P' : '-'),
                        (test_bit(info->evtchn / BITS_PER_EVTCHN_WORD(d),
                                  &vcpu_info(d->vcpu[0], evtchn_pending_sel)) ?
                         'S' : '-'),
-                       (test_bit(info->evtchn, &shared_info(d, evtchn_mask)) ?
+                       (evtchn_is_masked(d, info->evtchn) ?
                         'M' : '-'),
                        (info->masked ? 'M' : '-'));
                 if ( i != action->nr_guests )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43ee854..37fecee 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -95,6 +95,7 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
 static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
 
 static int virq_is_global(uint32_t virq)
 {
@@ -156,6 +157,16 @@ static int get_free_port(struct domain *d)
     return port;
 }
 
+int evtchn_is_pending(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_pending));
+}
+
+int evtchn_is_masked(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_mask));
+}
+
 
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
@@ -529,7 +540,7 @@ static long __evtchn_close(struct domain *d1, int port1)
     }
 
     /* Clear pending event to avoid unexpected behavior on re-bind. */
-    clear_bit(port1, &shared_info(d1, evtchn_pending));
+    evtchn_clear_pending(d1, port1);
 
     /* Reset binding to vcpu0 when the channel is freed. */
     chn1->state          = ECS_FREE;
@@ -653,6 +664,11 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_clear_pending(struct domain *d, int port)
+{
+    clear_bit(port, &shared_info(d, evtchn_pending));
+}
+
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
@@ -1283,8 +1299,8 @@ static void domain_dump_evtchn_info(struct domain *d)
 
         printk("    %4u [%d/%d]: s=%d n=%d x=%d",
                port,
-               !!test_bit(port, &shared_info(d, evtchn_pending)),
-               !!test_bit(port, &shared_info(d, evtchn_mask)),
+               !!evtchn_is_pending(d, port),
+               !!evtchn_is_masked(d, port),
                chn->state, chn->notify_vcpu_id, chn->xen_consumer);
 
         switch ( chn->state )
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 2c5c230..16bc452 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -301,10 +301,8 @@ static void dump_domains(unsigned char key)
             printk("Notifying guest %d:%d (virq %d, port %d, stat %d/%d/%d)\n",
                    d->domain_id, v->vcpu_id,
                    VIRQ_DEBUG, v->virq_to_evtchn[VIRQ_DEBUG],
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_pending)),
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_mask)),
+                   evtchn_is_pending(d, v->virq_to_evtchn[VIRQ_DEBUG]),
+                   evtchn_is_masked(d, v->virq_to_evtchn[VIRQ_DEBUG]),
                    test_bit(v->virq_to_evtchn[VIRQ_DEBUG] /
                             BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)));
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e6a90d8..1bf010e 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -693,7 +693,7 @@ static long do_poll(struct sched_poll *sched_poll)
             goto out;
 
         rc = 0;
-        if ( test_bit(port, &shared_info(d, evtchn_pending)) )
+        if ( evtchn_is_pending(d, port) )
             goto out;
     }
 
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 59778cf..1021a1a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -114,6 +114,12 @@ int evtchn_unmask(unsigned int port);
 /* Move all PIRQs after a vCPU was moved to another pCPU. */
 void evtchn_move_pirqs(struct vcpu *v);
 
+/* Tell a given event-channel port is pending or not */
+int evtchn_is_pending(struct domain *d, int port);
+
+/* Tell a given event-channel port is masked or not */
+int evtchn_is_masked(struct domain *d, int port);
+
 /* Allocate/free a Xen-attached event channel port. */
 typedef void (*xen_event_channel_notification_t)(
     struct vcpu *v, unsigned int port);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmV-0004Xb-1f; Mon, 04 Feb 2013 17:24:35 +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 1U2PmR-0004TF-TD
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:32 +0000
Received: from [85.158.143.99:36574] by server-3.bemta-4.messagelabs.com id
	00/17-08920-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19228 invoked from network); 4 Feb 2013 17:24:31 -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;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890077"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-Us;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:46 +0000
Message-ID: <1359998635-16866-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 05/13] xen: sync public 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h           |    9 ++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
index f494292..9d8b9e7 100644
--- a/include/xen/interface/event_channel.h
+++ b/include/xen/interface/event_channel.h
@@ -190,6 +190,39 @@ struct evtchn_reset {
 };
 typedef struct evtchn_reset evtchn_reset_t;
 
+/*
+ * EVTCHNOP_register_nlevel: Register N-level event channel
+ * NOTES:
+ *  1. Currently only 3-level is supported.
+ *  2. Should fall back to 2-level if this call fails.
+ */
+#define EVTCHNOP_register_nlevel 11
+/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
+ * 256k event channels while 32 bit ones only need 1 page for 32k
+ * event channels. */
+#define EVTCHN_MAX_L3_PAGES 8
+struct evtchn_register_3level {
+	/* IN parameters. */
+	uint32_t nr_pages; /* for evtchn_{pending,mask} */
+	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
+	GUEST_HANDLE(ulong) evtchn_pending;
+	GUEST_HANDLE(ulong) evtchn_mask;
+	GUEST_HANDLE(ulong) l2sel_mfns;
+	GUEST_HANDLE(ulong) l2sel_offsets;
+};
+typedef struct evtchn_register_3level evtchn_register_3level_t;
+DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
+
+struct evtchn_register_nlevel {
+	/* IN parameters. */
+	uint32_t level;
+	union {
+		evtchn_register_3level_t l3;
+	} u;
+};
+typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
+DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
+
 struct evtchn_op {
 	uint32_t cmd; /* EVTCHNOP_* */
 	union {
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..5220e33 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
 
 /*
  * Event channel endpoints per domain:
+ * 2-level:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
+ * 3-level:
+ *  32k if a long is 32 bits; 256k if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
+#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
+#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
+#endif
 
 struct vcpu_time_info {
 	/*
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmY-0004d3-Il; Mon, 04 Feb 2013 17:24:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2PmW-0004Yt-VZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:37 +0000
Received: from [85.158.137.99:29175] by server-5.bemta-3.messagelabs.com id
	FB/81-04457-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1359998669!14539573!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27156 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195791"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-Ql;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:43 +0000
Message-ID: <1359998635-16866-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 02/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the per-cpu selector L1 to be consistent with description in
__xen_evtchn_do_upcall's comment.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4d9a3a6..d937bf8 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1232,7 +1232,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
 			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
-					     ? "" : " l2-clear",
+					     ? "" : " l1-clear",
 			       !sync_test_bit(i, sh->evtchn_mask)
 					     ? "" : " globally-masked",
 			       sync_test_bit(i, cpu_evtchn)
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmY-0004d3-Il; Mon, 04 Feb 2013 17:24:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2PmW-0004Yt-VZ
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:37 +0000
Received: from [85.158.137.99:29175] by server-5.bemta-3.messagelabs.com id
	FB/81-04457-FCEEF015; Mon, 04 Feb 2013 17:24:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1359998669!14539573!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27156 invoked from network); 4 Feb 2013 17:24:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6195791"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmN-0001SL-Ql;
	Mon, 04 Feb 2013 17:24:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:43 +0000
Message-ID: <1359998635-16866-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 02/13] xen: fix output of xen_debug_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the per-cpu selector L1 to be consistent with description in
__xen_evtchn_do_upcall's comment.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4d9a3a6..d937bf8 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1232,7 +1232,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
 			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
-					     ? "" : " l2-clear",
+					     ? "" : " l1-clear",
 			       !sync_test_bit(i, sh->evtchn_mask)
 					     ? "" : " globally-masked",
 			       sync_test_bit(i, cpu_evtchn)
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmQ-0004Tw-Cm; Mon, 04 Feb 2013 17:24:30 +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 1U2PmO-0004TI-QW
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:28 +0000
Received: from [85.158.143.99:36397] by server-1.bemta-4.messagelabs.com id
	3D/81-08839-CCEEF015; Mon, 04 Feb 2013 17:24:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19079 invoked from network); 4 Feb 2013 17:24:27 -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;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890068"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-3A;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:47 +0000
Message-ID: <1359998638-16774-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 04/15] Bump EVTCHNS_PER_BUCKET to 512
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 64 bit build and 3-level event channel and the original value of
EVTCHNS_PER_BUCKET (128), the space needed to accommodate d->evtchn
would be 4 pages (PAGE_SIZE = 4096). Given that not every domain needs
3-level event channel, this leads to waste of memory. Also we've
restricted d->evtchn to one page, if we move to 3-level event channel,
Xen cannot build.

Having EVTCHN_PER_BUCKETS to be 512 can occupy exact one page.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index b32b06f..59778cf 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -36,7 +36,7 @@
 			};					\
 			__v;})
 
-#define EVTCHNS_PER_BUCKET 128
+#define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
 
 struct evtchn
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:24:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PmQ-0004Tw-Cm; Mon, 04 Feb 2013 17:24:30 +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 1U2PmO-0004TI-QW
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:24:28 +0000
Received: from [85.158.143.99:36397] by server-1.bemta-4.messagelabs.com id
	3D/81-08839-CCEEF015; Mon, 04 Feb 2013 17:24:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1359998665!21056210!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19079 invoked from network); 4 Feb 2013 17:24:27 -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;
	4 Feb 2013 17:24:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890068"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:25 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-3A;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:47 +0000
Message-ID: <1359998638-16774-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 04/15] Bump EVTCHNS_PER_BUCKET to 512
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 64 bit build and 3-level event channel and the original value of
EVTCHNS_PER_BUCKET (128), the space needed to accommodate d->evtchn
would be 4 pages (PAGE_SIZE = 4096). Given that not every domain needs
3-level event channel, this leads to waste of memory. Also we've
restricted d->evtchn to one page, if we move to 3-level event channel,
Xen cannot build.

Having EVTCHN_PER_BUCKETS to be 512 can occupy exact one page.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index b32b06f..59778cf 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -36,7 +36,7 @@
 			};					\
 			__v;})
 
-#define EVTCHNS_PER_BUCKET 128
+#define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
 
 struct evtchn
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:25:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:25: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 1U2PnB-0005Ov-2X; Mon, 04 Feb 2013 17:25:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2Pn9-0005MT-JG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:25:15 +0000
Received: from [85.158.137.99:33238] by server-5.bemta-3.messagelabs.com id
	48/42-04457-AFEEF015; Mon, 04 Feb 2013 17:25:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1359998668!13015655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4372 invoked from network); 4 Feb 2013 17:24:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890075"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-0y;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:48 +0000
Message-ID: <1359998635-16866-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 07/13] xen: replace raw bit ops with 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: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 2278851..6019cd9 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1471,7 +1471,7 @@ int resend_irq_on_evtchn(unsigned int irq)
 		return 1;
 
 	masked = test_and_set_mask(evtchn);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	set_evtchn(evtchn);
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1520,7 +1520,7 @@ static int retrigger_dynirq(struct irq_data *data)
 		int masked;
 
 		masked = test_and_set_mask(evtchn);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		set_evtchn(evtchn);
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:25:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:25: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 1U2PnB-0005Ov-2X; Mon, 04 Feb 2013 17:25:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2Pn9-0005MT-JG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:25:15 +0000
Received: from [85.158.137.99:33238] by server-5.bemta-3.messagelabs.com id
	48/42-04457-AFEEF015; Mon, 04 Feb 2013 17:25:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1359998668!13015655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4372 invoked from network); 4 Feb 2013 17:24:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5890075"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:24:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:24:28 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-0y;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:48 +0000
Message-ID: <1359998635-16866-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 07/13] xen: replace raw bit ops with 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: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 2278851..6019cd9 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1471,7 +1471,7 @@ int resend_irq_on_evtchn(unsigned int irq)
 		return 1;
 
 	masked = test_and_set_mask(evtchn);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	set_evtchn(evtchn);
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1520,7 +1520,7 @@ static int retrigger_dynirq(struct irq_data *data)
 		int masked;
 
 		masked = test_and_set_mask(evtchn);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		set_evtchn(evtchn);
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuH-0007VH-6g; Mon, 04 Feb 2013 17:32:37 +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 1U2PuF-0007VC-TB
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:36 +0000
Received: from [85.158.139.83:42733] by server-1.bemta-5.messagelabs.com id
	03/6A-29263-2B0FF015; Mon, 04 Feb 2013 17:32:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24933 invoked from network); 4 Feb 2013 17:32:34 -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;
	4 Feb 2013 17:32:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891189"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:32 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-6N;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:53 +0000
Message-ID: <1359998635-16866-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 12/13] xen: introduce
	xen_event_channel_register_nlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   55 ++++++++++++++++++++++++++++++++++++++++++++------
 include/xen/events.h |    7 +++++++
 2 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e0283c..6a0307c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -2217,17 +2217,60 @@ err:
 	return rc;
 }
 
+void xen_event_channel_register_nlevel(unsigned int highest_level)
+{
+	int rc;
+
+	switch (highest_level) {
+	case 3:
+		rc = xen_event_channel_register_3level();
+		if (rc == 0) {
+			printk(KERN_INFO "Register 3-level event channel succeed.\n");
+			xen_set_event_channel_nlevel(3);
+			break;
+		} else {
+			printk(KERN_INFO "Regsiter 3-level event channel failed with %d\n",
+			       rc);
+		}
+		/* fall through */
+	case 2:
+		printk(KERN_INFO "Using 2-level event channel\n");
+		xen_set_event_channel_nlevel(2);
+		break;
+	default:
+		printk(KERN_INFO "Trying to register unsupported %d-level event channel\n",
+		       highest_level);
+	}
+}
+
+void xen_set_event_channel_nlevel(unsigned int level)
+{
+	struct shared_info *s = HYPERVISOR_shared_info;
+	switch (level) {
+	case 2:
+		evtchn_pending = s->evtchn_pending;
+		evtchn_mask = s->evtchn_mask;
+		evtchn_level = 2;
+		nr_event_channels = NR_EVENT_CHANNELS_L2;
+		break;
+	case 3:
+		/* evtchn_pending/mask already set */
+		evtchn_level = 3;
+		nr_event_channels = NR_EVENT_CHANNELS_L3;
+		break;
+	default:
+		printk(KERN_EMERG "Trying to set unsupported %d-level event channel\n",
+		       level);
+		BUG();
+	}
+}
+
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
 	int cpu;
-	struct shared_info *s = HYPERVISOR_shared_info;
-
-	evtchn_pending = s->evtchn_pending;
-	evtchn_mask = s->evtchn_mask;
 
-	evtchn_level = 2;
-	nr_event_channels = NR_EVENT_CHANNELS_L2;
+	xen_set_event_channel_nlevel(2);
 
 	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
diff --git a/include/xen/events.h b/include/xen/events.h
index 6b117ac..6b6c4fb 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -111,4 +111,11 @@ int xen_test_irq_shared(int irq);
 
 extern unsigned int nr_event_channels;
 
+/* Register N-level event channel. If register N-level fails, it will try to
+ * register N-1 level, until it reaches the default 2-level event channel. */
+void xen_event_channel_register_nlevel(unsigned int highest_level);
+
+/* Set event channel to N-level if registration succeed */
+void xen_set_event_channel_nlevel(unsigned int level);
+
 #endif	/* _XEN_EVENTS_H */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuH-0007VH-6g; Mon, 04 Feb 2013 17:32:37 +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 1U2PuF-0007VC-TB
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:36 +0000
Received: from [85.158.139.83:42733] by server-1.bemta-5.messagelabs.com id
	03/6A-29263-2B0FF015; Mon, 04 Feb 2013 17:32:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24933 invoked from network); 4 Feb 2013 17:32:34 -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;
	4 Feb 2013 17:32:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891189"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:32 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-6N;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:53 +0000
Message-ID: <1359998635-16866-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 12/13] xen: introduce
	xen_event_channel_register_nlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   55 ++++++++++++++++++++++++++++++++++++++++++++------
 include/xen/events.h |    7 +++++++
 2 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e0283c..6a0307c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -2217,17 +2217,60 @@ err:
 	return rc;
 }
 
+void xen_event_channel_register_nlevel(unsigned int highest_level)
+{
+	int rc;
+
+	switch (highest_level) {
+	case 3:
+		rc = xen_event_channel_register_3level();
+		if (rc == 0) {
+			printk(KERN_INFO "Register 3-level event channel succeed.\n");
+			xen_set_event_channel_nlevel(3);
+			break;
+		} else {
+			printk(KERN_INFO "Regsiter 3-level event channel failed with %d\n",
+			       rc);
+		}
+		/* fall through */
+	case 2:
+		printk(KERN_INFO "Using 2-level event channel\n");
+		xen_set_event_channel_nlevel(2);
+		break;
+	default:
+		printk(KERN_INFO "Trying to register unsupported %d-level event channel\n",
+		       highest_level);
+	}
+}
+
+void xen_set_event_channel_nlevel(unsigned int level)
+{
+	struct shared_info *s = HYPERVISOR_shared_info;
+	switch (level) {
+	case 2:
+		evtchn_pending = s->evtchn_pending;
+		evtchn_mask = s->evtchn_mask;
+		evtchn_level = 2;
+		nr_event_channels = NR_EVENT_CHANNELS_L2;
+		break;
+	case 3:
+		/* evtchn_pending/mask already set */
+		evtchn_level = 3;
+		nr_event_channels = NR_EVENT_CHANNELS_L3;
+		break;
+	default:
+		printk(KERN_EMERG "Trying to set unsupported %d-level event channel\n",
+		       level);
+		BUG();
+	}
+}
+
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
 	int cpu;
-	struct shared_info *s = HYPERVISOR_shared_info;
-
-	evtchn_pending = s->evtchn_pending;
-	evtchn_mask = s->evtchn_mask;
 
-	evtchn_level = 2;
-	nr_event_channels = NR_EVENT_CHANNELS_L2;
+	xen_set_event_channel_nlevel(2);
 
 	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
diff --git a/include/xen/events.h b/include/xen/events.h
index 6b117ac..6b6c4fb 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -111,4 +111,11 @@ int xen_test_irq_shared(int irq);
 
 extern unsigned int nr_event_channels;
 
+/* Register N-level event channel. If register N-level fails, it will try to
+ * register N-1 level, until it reaches the default 2-level event channel. */
+void xen_event_channel_register_nlevel(unsigned int highest_level);
+
+/* Set event channel to N-level if registration succeed */
+void xen_set_event_channel_nlevel(unsigned int level);
+
 #endif	/* _XEN_EVENTS_H */
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuJ-0007VY-Ja; Mon, 04 Feb 2013 17:32:39 +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 1U2PuJ-0007VS-1t
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:39 +0000
Received: from [85.158.139.83:42927] by server-14.bemta-5.messagelabs.com id
	93/18-06967-6B0FF015; Mon, 04 Feb 2013 17:32:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25088 invoked from network); 4 Feb 2013 17:32:37 -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;
	4 Feb 2013 17:32:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891192"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:36 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-D2;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:58 +0000
Message-ID: <1359998638-16774-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 15/15] libxl: add evtchn_l3 flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Admins can add "evtchn_l3 = 1" in domain config file to enable 3-level event
channel for a domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl_create.c  |    3 +++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    2 ++
 tools/libxl/xl_sxp.c        |    1 +
 4 files changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a8dfe61..b72efde 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -35,6 +35,8 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&c_info->oos, true);
     }
 
+    libxl_defbool_setdefault(&c_info->evtchn_l3, false);
+
     libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
 
     return 0;
@@ -375,6 +377,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
         flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
         flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
+    flags |= libxl_defbool_val(info->evtchn_l3) ? XEN_DOMCTL_CDF_evtchn_l3 : 0;
     *domid = -1;
 
     /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index acc4bc9..7aa573e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -236,6 +236,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
     ("hap",          libxl_defbool),
     ("oos",          libxl_defbool),
+    ("evtchn_l3",    libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080bbd8..06fd9ed 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -651,6 +651,8 @@ static void parse_config_data(const char *config_source,
 
     xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
+    xlu_cfg_get_defbool(config, "evtchn_l3", &c_info->evtchn_l3, 0);
+
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
diff --git a/tools/libxl/xl_sxp.c b/tools/libxl/xl_sxp.c
index a16a025..9fd44c4 100644
--- a/tools/libxl/xl_sxp.c
+++ b/tools/libxl/xl_sxp.c
@@ -44,6 +44,7 @@ void printf_info_sexp(int domid, libxl_domain_config *d_config)
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
     printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
     printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
+    printf("\t(evtchn_l3 %s)\n", libxl_defbool_to_string(c_info->evtchn_l3));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuJ-0007VY-Ja; Mon, 04 Feb 2013 17:32:39 +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 1U2PuJ-0007VS-1t
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:39 +0000
Received: from [85.158.139.83:42927] by server-14.bemta-5.messagelabs.com id
	93/18-06967-6B0FF015; Mon, 04 Feb 2013 17:32:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25088 invoked from network); 4 Feb 2013 17:32:37 -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;
	4 Feb 2013 17:32:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891192"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:36 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-D2;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:58 +0000
Message-ID: <1359998638-16774-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 15/15] libxl: add evtchn_l3 flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Admins can add "evtchn_l3 = 1" in domain config file to enable 3-level event
channel for a domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl_create.c  |    3 +++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    2 ++
 tools/libxl/xl_sxp.c        |    1 +
 4 files changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a8dfe61..b72efde 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -35,6 +35,8 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&c_info->oos, true);
     }
 
+    libxl_defbool_setdefault(&c_info->evtchn_l3, false);
+
     libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
 
     return 0;
@@ -375,6 +377,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
         flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
         flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
+    flags |= libxl_defbool_val(info->evtchn_l3) ? XEN_DOMCTL_CDF_evtchn_l3 : 0;
     *domid = -1;
 
     /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index acc4bc9..7aa573e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -236,6 +236,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
     ("hap",          libxl_defbool),
     ("oos",          libxl_defbool),
+    ("evtchn_l3",    libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080bbd8..06fd9ed 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -651,6 +651,8 @@ static void parse_config_data(const char *config_source,
 
     xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
+    xlu_cfg_get_defbool(config, "evtchn_l3", &c_info->evtchn_l3, 0);
+
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
diff --git a/tools/libxl/xl_sxp.c b/tools/libxl/xl_sxp.c
index a16a025..9fd44c4 100644
--- a/tools/libxl/xl_sxp.c
+++ b/tools/libxl/xl_sxp.c
@@ -44,6 +44,7 @@ void printf_info_sexp(int domid, libxl_domain_config *d_config)
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
     printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
     printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
+    printf("\t(evtchn_l3 %s)\n", libxl_defbool_to_string(c_info->evtchn_l3));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuP-0007Wf-1Q; Mon, 04 Feb 2013 17:32:45 +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 1U2PuN-0007WE-Du
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:43 +0000
Received: from [85.158.139.83:9441] by server-12.bemta-5.messagelabs.com id
	B0/89-20195-AB0FF015; Mon, 04 Feb 2013 17:32:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25237 invoked from network); 4 Feb 2013 17:32:41 -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;
	4 Feb 2013 17:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891206"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:41 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-4f;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:52 +0000
Message-ID: <1359998635-16866-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 11/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index f3f0fdc..6e0283c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -53,6 +53,9 @@
 
 /* Helper macro(s) */
 #define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)
+/* event bitmap size: 1 page for 32 bit and 8 pages for 64 bit */
+#define BITMAP_PG_ORDER (BITS_PER_LONG == 64 ? 3 : 1)
+#define BITMAP_NR_PAGES (BITMAP_PG_ORDER == 3 ? 8 : 1)
 
 /* N-level event channel, starting from 2 */
 unsigned int evtchn_level = 2;
@@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
+static int xen_event_channel_register_3level(void)
+{
+	evtchn_register_nlevel_t reg;
+	int i, cpu;
+	unsigned long *_evtchn_pending = NULL;
+	unsigned long *_evtchn_mask = NULL;
+	unsigned long *l2sel_mfns = NULL;
+	unsigned long *l2sel_offsets = NULL;
+	int rc;
+
+	/* If we come from restore path, we don't need to allocate
+	 * pages.
+	 */
+	if (!evtchn_pending && !evtchn_mask) {
+		evtchn_pending =
+			(unsigned long *)__get_free_pages(GFP_KERNEL,
+							  BITMAP_PG_ORDER);
+		evtchn_mask =
+			(unsigned long *)__get_free_pages(GFP_KERNEL,
+							  BITMAP_PG_ORDER);
+		if (!evtchn_pending || !evtchn_mask) {
+			free_pages((unsigned long)evtchn_pending, BITMAP_PG_ORDER);
+			free_pages((unsigned long)evtchn_mask, BITMAP_PG_ORDER);
+			evtchn_pending = NULL;
+			evtchn_mask = NULL;
+			rc = -ENOMEM;
+			goto err;
+		}
+	}
+
+	rc = -ENOMEM; /* Common error code for following operations */
+#define __ALLOC_ARRAY(_ptr, _nr)					\
+	do {								\
+		(_ptr) = kzalloc(sizeof(unsigned long) * (_nr),		\
+				 GFP_KERNEL);				\
+		if (!(_ptr))						\
+			goto out;					\
+	} while (0)
+
+	__ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
+	__ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
+	__ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
+	__ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
+#undef __ALLOC_ARRAY
+
+	memset(&reg, 0, sizeof(reg));
+
+	for (i = 0; i < BITMAP_NR_PAGES; i++) {
+		unsigned long offset = PAGE_SIZE * i;
+		_evtchn_pending[i] =
+			arbitrary_virt_to_mfn(
+				(void *)((unsigned long)evtchn_pending+offset));
+		_evtchn_mask[i] =
+			arbitrary_virt_to_mfn(
+				(void *)((unsigned long)evtchn_mask+offset));
+	}
+
+	for_each_possible_cpu(cpu) {
+		l2sel_mfns[cpu] =
+			arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
+		l2sel_offsets[cpu] =
+			offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
+	}
+
+	reg.u.l3.nr_pages = BITMAP_NR_PAGES;
+	reg.u.l3.evtchn_pending = _evtchn_pending;
+	reg.u.l3.evtchn_mask = _evtchn_mask;
+
+	reg.u.l3.nr_vcpus = nr_cpu_ids;
+	reg.u.l3.l2sel_mfns = l2sel_mfns;
+	reg.u.l3.l2sel_offsets = l2sel_offsets;
+
+	reg.level = 3;
+
+	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
+	if (rc) {
+		free_pages((unsigned long)evtchn_pending, BITMAP_PG_ORDER);
+		free_pages((unsigned long)evtchn_mask, BITMAP_PG_ORDER);
+		evtchn_pending = NULL;
+		evtchn_mask = NULL;
+	}
+
+out:
+	kfree(_evtchn_pending);
+	kfree(_evtchn_mask);
+	kfree(l2sel_mfns);
+	kfree(l2sel_offsets);
+err:
+	return rc;
+}
+
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuP-0007Wf-1Q; Mon, 04 Feb 2013 17:32:45 +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 1U2PuN-0007WE-Du
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:43 +0000
Received: from [85.158.139.83:9441] by server-12.bemta-5.messagelabs.com id
	B0/89-20195-AB0FF015; Mon, 04 Feb 2013 17:32:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25237 invoked from network); 4 Feb 2013 17:32:41 -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;
	4 Feb 2013 17:32:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891206"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:41 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-4f;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:52 +0000
Message-ID: <1359998635-16866-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 11/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/events.c |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index f3f0fdc..6e0283c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -53,6 +53,9 @@
 
 /* Helper macro(s) */
 #define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)
+/* event bitmap size: 1 page for 32 bit and 8 pages for 64 bit */
+#define BITMAP_PG_ORDER (BITS_PER_LONG == 64 ? 3 : 1)
+#define BITMAP_NR_PAGES (BITMAP_PG_ORDER == 3 ? 8 : 1)
 
 /* N-level event channel, starting from 2 */
 unsigned int evtchn_level = 2;
@@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
+static int xen_event_channel_register_3level(void)
+{
+	evtchn_register_nlevel_t reg;
+	int i, cpu;
+	unsigned long *_evtchn_pending = NULL;
+	unsigned long *_evtchn_mask = NULL;
+	unsigned long *l2sel_mfns = NULL;
+	unsigned long *l2sel_offsets = NULL;
+	int rc;
+
+	/* If we come from restore path, we don't need to allocate
+	 * pages.
+	 */
+	if (!evtchn_pending && !evtchn_mask) {
+		evtchn_pending =
+			(unsigned long *)__get_free_pages(GFP_KERNEL,
+							  BITMAP_PG_ORDER);
+		evtchn_mask =
+			(unsigned long *)__get_free_pages(GFP_KERNEL,
+							  BITMAP_PG_ORDER);
+		if (!evtchn_pending || !evtchn_mask) {
+			free_pages((unsigned long)evtchn_pending, BITMAP_PG_ORDER);
+			free_pages((unsigned long)evtchn_mask, BITMAP_PG_ORDER);
+			evtchn_pending = NULL;
+			evtchn_mask = NULL;
+			rc = -ENOMEM;
+			goto err;
+		}
+	}
+
+	rc = -ENOMEM; /* Common error code for following operations */
+#define __ALLOC_ARRAY(_ptr, _nr)					\
+	do {								\
+		(_ptr) = kzalloc(sizeof(unsigned long) * (_nr),		\
+				 GFP_KERNEL);				\
+		if (!(_ptr))						\
+			goto out;					\
+	} while (0)
+
+	__ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
+	__ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
+	__ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
+	__ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
+#undef __ALLOC_ARRAY
+
+	memset(&reg, 0, sizeof(reg));
+
+	for (i = 0; i < BITMAP_NR_PAGES; i++) {
+		unsigned long offset = PAGE_SIZE * i;
+		_evtchn_pending[i] =
+			arbitrary_virt_to_mfn(
+				(void *)((unsigned long)evtchn_pending+offset));
+		_evtchn_mask[i] =
+			arbitrary_virt_to_mfn(
+				(void *)((unsigned long)evtchn_mask+offset));
+	}
+
+	for_each_possible_cpu(cpu) {
+		l2sel_mfns[cpu] =
+			arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
+		l2sel_offsets[cpu] =
+			offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
+	}
+
+	reg.u.l3.nr_pages = BITMAP_NR_PAGES;
+	reg.u.l3.evtchn_pending = _evtchn_pending;
+	reg.u.l3.evtchn_mask = _evtchn_mask;
+
+	reg.u.l3.nr_vcpus = nr_cpu_ids;
+	reg.u.l3.l2sel_mfns = l2sel_mfns;
+	reg.u.l3.l2sel_offsets = l2sel_offsets;
+
+	reg.level = 3;
+
+	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
+	if (rc) {
+		free_pages((unsigned long)evtchn_pending, BITMAP_PG_ORDER);
+		free_pages((unsigned long)evtchn_mask, BITMAP_PG_ORDER);
+		evtchn_pending = NULL;
+		evtchn_mask = NULL;
+	}
+
+out:
+	kfree(_evtchn_pending);
+	kfree(_evtchn_mask);
+	kfree(l2sel_mfns);
+	kfree(l2sel_offsets);
+err:
+	return rc;
+}
+
 void __init xen_init_IRQ(void)
 {
 	int i, rc;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuU-0007YX-Eq; Mon, 04 Feb 2013 17:32:50 +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 1U2PuS-0007Xj-KA
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:49 +0000
Received: from [85.158.139.83:43533] by server-7.bemta-5.messagelabs.com id
	D9/90-11121-FB0FF015; Mon, 04 Feb 2013 17:32:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25393 invoked from network); 4 Feb 2013 17:32:46 -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;
	4 Feb 2013 17:32:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891213"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:45 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-45;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:51 +0000
Message-ID: <1359998635-16866-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 10/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Only do_upcall, debug_interrupt and unmask_evtchn are required.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 291 insertions(+)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 94d6570..f3f0fdc 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -51,6 +51,9 @@
 #include <xen/interface/hvm/hvm_op.h>
 #include <xen/interface/hvm/params.h>
 
+/* Helper macro(s) */
+#define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)
+
 /* N-level event channel, starting from 2 */
 unsigned int evtchn_level = 2;
 EXPORT_SYMBOL_GPL(evtchn_level);
@@ -61,6 +64,9 @@ EXPORT_SYMBOL_GPL(nr_event_channels);
 static unsigned long *evtchn_pending;
 static unsigned long *evtchn_mask;
 
+/* 2nd level selector for 3-level event channel */
+static DEFINE_PER_CPU(unsigned long[sizeof(unsigned long) * 8], evtchn_sel_l2);
+
 /*
  * This lock protects updates to the following mapping and reference-count
  * arrays. The lock does not need to be acquired to read the mapping tables.
@@ -396,6 +402,28 @@ static inline void __unmask_local_port_l2(int port)
 		vcpu_info->evtchn_upcall_pending = 1;
 }
 
+static inline void __unmask_local_port_l3(int port)
+{
+	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
+	int cpu = smp_processor_id();
+	unsigned int l1bit = port >> (LONG_BITORDER << 1);
+	unsigned int l2bit = port >> LONG_BITORDER;
+
+	sync_clear_bit(port, &evtchn_mask[0]);
+
+	/*
+	 * The following is basically the equivalent of
+	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
+	 * the interrupt edge' if the channel is masked.
+	 */
+	if (sync_test_bit(port, &evtchn_pending[0]) &&
+	    !sync_test_and_set_bit(l2bit,
+				   &per_cpu(evtchn_sel_l2, cpu)[0]) &&
+	    !sync_test_and_set_bit(l1bit,
+				   &vcpu_info->evtchn_pending_sel))
+		vcpu_info->evtchn_upcall_pending = 1;
+}
+
 static void unmask_evtchn(int port)
 {
 	unsigned int cpu = get_cpu();
@@ -411,6 +439,9 @@ static void unmask_evtchn(int port)
 		case 2:
 			__unmask_local_port_l2(port);
 			break;
+		case 3:
+			__unmask_local_port_l3(port);
+			break;
 		default:
 			BUG();
 		}
@@ -1185,6 +1216,7 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
 }
 
 static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
+static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id);
 
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
@@ -1215,6 +1247,9 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 	case 2:
 		rc = xen_debug_interrupt_l2(irq, dev_id);
 		break;
+	case 3:
+		rc = xen_debug_interrupt_l3(irq, dev_id);
+		break;
 	default:
 		BUG();
 	}
@@ -1285,8 +1320,109 @@ static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
+{
+	int cpu = smp_processor_id();
+	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
+	int i;
+	struct vcpu_info *v;
+
+	v = per_cpu(xen_vcpu, cpu);
+
+	printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
+	for (i = nr_elems-1; i >= 0; i--)
+		if (evtchn_pending[i] != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)sizeof(evtchn_pending[0])*2,
+			       evtchn_pending[i]);
+		}
+
+	printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
+	for (i = nr_elems-1; i >= 0; i--)
+		if (evtchn_mask[i] != ~0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)sizeof(evtchn_mask[0])*2,
+			       evtchn_mask[i]);
+		}
+
+	printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
+	for (i = nr_elems-1; i >= 0; i--)
+		if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)(sizeof(evtchn_mask[0])*2),
+			       evtchn_pending[i] & ~evtchn_mask[i]);
+		}
+
+	printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
+	for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
+		if (cpu_evtchn[i] != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)(sizeof(cpu_evtchn[0])*2),
+			       cpu_evtchn[i]);
+		}
+
+	printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
+	for (i = nr_elems-1; i >= 0; i--) {
+		unsigned long pending = evtchn_pending[i]
+			& ~evtchn_mask[i]
+			& cpu_evtchn[i];
+		if (pending != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)(sizeof(evtchn_mask[0])*2),
+			       pending);
+		}
+	}
+
+	printk(KERN_DEBUG "\npending list:\n");
+	for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
+		if (sync_test_bit(i, evtchn_pending)) {
+			int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
+			int word_idx_l2 = i / BITS_PER_LONG;
+			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
+			       cpu_from_evtchn(i), i,
+			       evtchn_to_irq[i],
+			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       ? "" : " l1-clear",
+			       !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
+			       ? "" : " l2-clear",
+			       sync_test_bit(i, evtchn_mask)
+			       ? "" : " globally-masked",
+			       sync_test_bit(i, cpu_evtchn)
+			       ? "" : " locally-masked");
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+/* The following per-cpu variables are used to save current state of event
+ * processing loop.
+ *
+ * 2-level event channel:
+ *  current_word_idx is the bit index in L1 selector indicating the currently
+ *  processing word in shared bitmap.
+ *  current_bit_idx is the bit index in the currently processing word in shared
+ *  bitmap.
+ *  N.B. current_word_idx_l2 is not used.
+ *
+ * 3-level event channel:
+ *  current_word_idx is the bit index in L1 selector indicating the currently
+ *  processing word in L2 selector.
+ *  current_word_idx_l2 is the bit index in L2 selector word indicating the
+ *  currently processing word in shared bitmap.
+ *  current_bit_idx is the bit index in the currently processing word in shared
+ *  bitmap.
+ *
+ */
 static DEFINE_PER_CPU(unsigned, xed_nesting_count);
 static DEFINE_PER_CPU(unsigned int, current_word_idx);
+static DEFINE_PER_CPU(unsigned int, current_word_idx_l2);
 static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 
 /*
@@ -1409,6 +1545,155 @@ out:
 	put_cpu();
 }
 
+/*
+ * In the 3-level event channel implementation, the first level is a
+ * bitset of words which contain pending bits in the second level.
+ * The second level is another bitsets which contain pending bits in
+ * the third level.  The third level is a bit set of pending events
+ * themselves.
+ */
+static void __xen_evtchn_do_upcall_l3(void)
+{
+	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
+	unsigned count;
+	int start_word_idx_l1, start_word_idx_l2, start_bit_idx;
+	int word_idx_l1, word_idx_l2, bit_idx;
+	int i, j;
+	int cpu = get_cpu();
+
+	do {
+		unsigned long pending_words_l1;
+
+		vcpu_info->evtchn_upcall_pending = 0;
+
+		if (__this_cpu_inc_return(xed_nesting_count) - 1)
+			goto out;
+#ifndef CONFIG_X86
+		/* No need for a barrier -- XCHG is a barrier on x86. */
+		/* Clear master flag /before/ clearing selector flag. */
+		wmb();
+#endif
+		/* here we get l1 pending selector */
+		pending_words_l1 = xchg(&vcpu_info->evtchn_pending_sel, 0);
+
+		start_word_idx_l1 = __this_cpu_read(current_word_idx);
+		start_word_idx_l2 = __this_cpu_read(current_word_idx_l2);
+		start_bit_idx = __this_cpu_read(current_bit_idx);
+
+		word_idx_l1 = start_word_idx_l1;
+
+		/* loop through l1, try to pick up l2 */
+		for (i = 0; pending_words_l1 != 0; i++) {
+			unsigned long words_l1;
+			unsigned long pending_words_l2;
+
+			words_l1 = MASK_LSBS(pending_words_l1, word_idx_l1);
+
+			if (words_l1 == 0) {
+				word_idx_l1 = 0;
+				start_word_idx_l2 = 0;
+				continue;
+			}
+
+			word_idx_l1 = __ffs(words_l1);
+
+			pending_words_l2 =
+				xchg(&per_cpu(evtchn_sel_l2, cpu)[word_idx_l1],
+				     0);
+
+			word_idx_l2 = 0;
+			if (word_idx_l1 == start_word_idx_l1) {
+				if (i == 0)
+					word_idx_l2 = start_word_idx_l2;
+				else
+					word_idx_l2 &= (1UL << start_word_idx_l2) - 1;
+			}
+
+			for (j = 0; pending_words_l2 != 0; j++) {
+				unsigned long pending_bits;
+				unsigned long words_l2;
+				unsigned long idx;
+
+				words_l2 = MASK_LSBS(pending_words_l2,
+						     word_idx_l2);
+
+				if (words_l2 == 0) {
+					word_idx_l2 = 0;
+					bit_idx = 0;
+					continue;
+				}
+
+				word_idx_l2 = __ffs(words_l2);
+
+				idx = word_idx_l1*BITS_PER_LONG+word_idx_l2;
+				pending_bits =
+					active_evtchns(cpu, idx);
+
+				bit_idx = 0;
+				if (word_idx_l2 == start_word_idx_l2) {
+					if (j == 0)
+						bit_idx = start_bit_idx;
+					else
+						bit_idx &= (1UL<<start_bit_idx)-1;
+				}
+
+				/* process port */
+				do {
+					unsigned long bits;
+					int port, irq;
+					struct irq_desc *desc;
+
+					bits = MASK_LSBS(pending_bits, bit_idx);
+
+					if (bits == 0)
+						break;
+
+					bit_idx = __ffs(bits);
+
+					port = (word_idx_l1 << (LONG_BITORDER << 1)) +
+						(word_idx_l2 << LONG_BITORDER) +
+						bit_idx;
+
+					irq = evtchn_to_irq[port];
+
+					if (irq != -1) {
+						desc = irq_to_desc(irq);
+						if (desc)
+							generic_handle_irq_desc(irq, desc);
+					}
+
+					bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+
+					__this_cpu_write(current_bit_idx, bit_idx);
+					__this_cpu_write(current_word_idx_l2,
+							 bit_idx ? word_idx_l2 :
+							 (word_idx_l2+1) % BITS_PER_LONG);
+					__this_cpu_write(current_word_idx_l2,
+							 word_idx_l2 ? word_idx_l1 :
+							 (word_idx_l1+1) % BITS_PER_LONG);
+				} while (bit_idx != 0);
+
+				if ((word_idx_l2 != start_word_idx_l2) || (j != 0))
+					pending_words_l2 &= ~(1UL << word_idx_l2);
+
+				word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
+			}
+
+			if ((word_idx_l1 != start_word_idx_l1) || (i != 0))
+				pending_words_l1 &= ~(1UL << word_idx_l1);
+
+			word_idx_l1 = (word_idx_l1 + 1) % BITS_PER_LONG;
+		}
+
+		BUG_ON(!irqs_disabled());
+		count = __this_cpu_read(xed_nesting_count);
+		__this_cpu_write(xed_nesting_count, 0);
+	} while (count != 1 || vcpu_info->evtchn_upcall_pending);
+
+out:
+	put_cpu();
+}
+
 void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
 	struct pt_regs *old_regs = set_irq_regs(regs);
@@ -1420,6 +1705,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 	case 2:
 		__xen_evtchn_do_upcall_l2();
 		break;
+	case 3:
+		__xen_evtchn_do_upcall_l3();
+		break;
 	default:
 		BUG();
 	}
@@ -1434,6 +1722,9 @@ void xen_hvm_evtchn_do_upcall(void)
 	case 2:
 		__xen_evtchn_do_upcall_l2();
 		break;
+	case 3:
+		__xen_evtchn_do_upcall_l3();
+		break;
 	default:
 		BUG();
 	}
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuU-0007YX-Eq; Mon, 04 Feb 2013 17:32:50 +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 1U2PuS-0007Xj-KA
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:49 +0000
Received: from [85.158.139.83:43533] by server-7.bemta-5.messagelabs.com id
	D9/90-11121-FB0FF015; Mon, 04 Feb 2013 17:32:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25393 invoked from network); 4 Feb 2013 17:32:46 -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;
	4 Feb 2013 17:32:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891213"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:45 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-45;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:51 +0000
Message-ID: <1359998635-16866-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 10/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Only do_upcall, debug_interrupt and unmask_evtchn are required.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/events.c |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 291 insertions(+)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 94d6570..f3f0fdc 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -51,6 +51,9 @@
 #include <xen/interface/hvm/hvm_op.h>
 #include <xen/interface/hvm/params.h>
 
+/* Helper macro(s) */
+#define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)
+
 /* N-level event channel, starting from 2 */
 unsigned int evtchn_level = 2;
 EXPORT_SYMBOL_GPL(evtchn_level);
@@ -61,6 +64,9 @@ EXPORT_SYMBOL_GPL(nr_event_channels);
 static unsigned long *evtchn_pending;
 static unsigned long *evtchn_mask;
 
+/* 2nd level selector for 3-level event channel */
+static DEFINE_PER_CPU(unsigned long[sizeof(unsigned long) * 8], evtchn_sel_l2);
+
 /*
  * This lock protects updates to the following mapping and reference-count
  * arrays. The lock does not need to be acquired to read the mapping tables.
@@ -396,6 +402,28 @@ static inline void __unmask_local_port_l2(int port)
 		vcpu_info->evtchn_upcall_pending = 1;
 }
 
+static inline void __unmask_local_port_l3(int port)
+{
+	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
+	int cpu = smp_processor_id();
+	unsigned int l1bit = port >> (LONG_BITORDER << 1);
+	unsigned int l2bit = port >> LONG_BITORDER;
+
+	sync_clear_bit(port, &evtchn_mask[0]);
+
+	/*
+	 * The following is basically the equivalent of
+	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
+	 * the interrupt edge' if the channel is masked.
+	 */
+	if (sync_test_bit(port, &evtchn_pending[0]) &&
+	    !sync_test_and_set_bit(l2bit,
+				   &per_cpu(evtchn_sel_l2, cpu)[0]) &&
+	    !sync_test_and_set_bit(l1bit,
+				   &vcpu_info->evtchn_pending_sel))
+		vcpu_info->evtchn_upcall_pending = 1;
+}
+
 static void unmask_evtchn(int port)
 {
 	unsigned int cpu = get_cpu();
@@ -411,6 +439,9 @@ static void unmask_evtchn(int port)
 		case 2:
 			__unmask_local_port_l2(port);
 			break;
+		case 3:
+			__unmask_local_port_l3(port);
+			break;
 		default:
 			BUG();
 		}
@@ -1185,6 +1216,7 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
 }
 
 static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
+static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id);
 
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
@@ -1215,6 +1247,9 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 	case 2:
 		rc = xen_debug_interrupt_l2(irq, dev_id);
 		break;
+	case 3:
+		rc = xen_debug_interrupt_l3(irq, dev_id);
+		break;
 	default:
 		BUG();
 	}
@@ -1285,8 +1320,109 @@ static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
+{
+	int cpu = smp_processor_id();
+	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
+	int i;
+	struct vcpu_info *v;
+
+	v = per_cpu(xen_vcpu, cpu);
+
+	printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
+	for (i = nr_elems-1; i >= 0; i--)
+		if (evtchn_pending[i] != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)sizeof(evtchn_pending[0])*2,
+			       evtchn_pending[i]);
+		}
+
+	printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
+	for (i = nr_elems-1; i >= 0; i--)
+		if (evtchn_mask[i] != ~0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)sizeof(evtchn_mask[0])*2,
+			       evtchn_mask[i]);
+		}
+
+	printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
+	for (i = nr_elems-1; i >= 0; i--)
+		if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)(sizeof(evtchn_mask[0])*2),
+			       evtchn_pending[i] & ~evtchn_mask[i]);
+		}
+
+	printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
+	for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
+		if (cpu_evtchn[i] != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)(sizeof(cpu_evtchn[0])*2),
+			       cpu_evtchn[i]);
+		}
+
+	printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
+	for (i = nr_elems-1; i >= 0; i--) {
+		unsigned long pending = evtchn_pending[i]
+			& ~evtchn_mask[i]
+			& cpu_evtchn[i];
+		if (pending != 0UL) {
+			printk(KERN_DEBUG " word index %d %0*lx\n",
+			       i,
+			       (int)(sizeof(evtchn_mask[0])*2),
+			       pending);
+		}
+	}
+
+	printk(KERN_DEBUG "\npending list:\n");
+	for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
+		if (sync_test_bit(i, evtchn_pending)) {
+			int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
+			int word_idx_l2 = i / BITS_PER_LONG;
+			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
+			       cpu_from_evtchn(i), i,
+			       evtchn_to_irq[i],
+			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       ? "" : " l1-clear",
+			       !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
+			       ? "" : " l2-clear",
+			       sync_test_bit(i, evtchn_mask)
+			       ? "" : " globally-masked",
+			       sync_test_bit(i, cpu_evtchn)
+			       ? "" : " locally-masked");
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+/* The following per-cpu variables are used to save current state of event
+ * processing loop.
+ *
+ * 2-level event channel:
+ *  current_word_idx is the bit index in L1 selector indicating the currently
+ *  processing word in shared bitmap.
+ *  current_bit_idx is the bit index in the currently processing word in shared
+ *  bitmap.
+ *  N.B. current_word_idx_l2 is not used.
+ *
+ * 3-level event channel:
+ *  current_word_idx is the bit index in L1 selector indicating the currently
+ *  processing word in L2 selector.
+ *  current_word_idx_l2 is the bit index in L2 selector word indicating the
+ *  currently processing word in shared bitmap.
+ *  current_bit_idx is the bit index in the currently processing word in shared
+ *  bitmap.
+ *
+ */
 static DEFINE_PER_CPU(unsigned, xed_nesting_count);
 static DEFINE_PER_CPU(unsigned int, current_word_idx);
+static DEFINE_PER_CPU(unsigned int, current_word_idx_l2);
 static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 
 /*
@@ -1409,6 +1545,155 @@ out:
 	put_cpu();
 }
 
+/*
+ * In the 3-level event channel implementation, the first level is a
+ * bitset of words which contain pending bits in the second level.
+ * The second level is another bitsets which contain pending bits in
+ * the third level.  The third level is a bit set of pending events
+ * themselves.
+ */
+static void __xen_evtchn_do_upcall_l3(void)
+{
+	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
+	unsigned count;
+	int start_word_idx_l1, start_word_idx_l2, start_bit_idx;
+	int word_idx_l1, word_idx_l2, bit_idx;
+	int i, j;
+	int cpu = get_cpu();
+
+	do {
+		unsigned long pending_words_l1;
+
+		vcpu_info->evtchn_upcall_pending = 0;
+
+		if (__this_cpu_inc_return(xed_nesting_count) - 1)
+			goto out;
+#ifndef CONFIG_X86
+		/* No need for a barrier -- XCHG is a barrier on x86. */
+		/* Clear master flag /before/ clearing selector flag. */
+		wmb();
+#endif
+		/* here we get l1 pending selector */
+		pending_words_l1 = xchg(&vcpu_info->evtchn_pending_sel, 0);
+
+		start_word_idx_l1 = __this_cpu_read(current_word_idx);
+		start_word_idx_l2 = __this_cpu_read(current_word_idx_l2);
+		start_bit_idx = __this_cpu_read(current_bit_idx);
+
+		word_idx_l1 = start_word_idx_l1;
+
+		/* loop through l1, try to pick up l2 */
+		for (i = 0; pending_words_l1 != 0; i++) {
+			unsigned long words_l1;
+			unsigned long pending_words_l2;
+
+			words_l1 = MASK_LSBS(pending_words_l1, word_idx_l1);
+
+			if (words_l1 == 0) {
+				word_idx_l1 = 0;
+				start_word_idx_l2 = 0;
+				continue;
+			}
+
+			word_idx_l1 = __ffs(words_l1);
+
+			pending_words_l2 =
+				xchg(&per_cpu(evtchn_sel_l2, cpu)[word_idx_l1],
+				     0);
+
+			word_idx_l2 = 0;
+			if (word_idx_l1 == start_word_idx_l1) {
+				if (i == 0)
+					word_idx_l2 = start_word_idx_l2;
+				else
+					word_idx_l2 &= (1UL << start_word_idx_l2) - 1;
+			}
+
+			for (j = 0; pending_words_l2 != 0; j++) {
+				unsigned long pending_bits;
+				unsigned long words_l2;
+				unsigned long idx;
+
+				words_l2 = MASK_LSBS(pending_words_l2,
+						     word_idx_l2);
+
+				if (words_l2 == 0) {
+					word_idx_l2 = 0;
+					bit_idx = 0;
+					continue;
+				}
+
+				word_idx_l2 = __ffs(words_l2);
+
+				idx = word_idx_l1*BITS_PER_LONG+word_idx_l2;
+				pending_bits =
+					active_evtchns(cpu, idx);
+
+				bit_idx = 0;
+				if (word_idx_l2 == start_word_idx_l2) {
+					if (j == 0)
+						bit_idx = start_bit_idx;
+					else
+						bit_idx &= (1UL<<start_bit_idx)-1;
+				}
+
+				/* process port */
+				do {
+					unsigned long bits;
+					int port, irq;
+					struct irq_desc *desc;
+
+					bits = MASK_LSBS(pending_bits, bit_idx);
+
+					if (bits == 0)
+						break;
+
+					bit_idx = __ffs(bits);
+
+					port = (word_idx_l1 << (LONG_BITORDER << 1)) +
+						(word_idx_l2 << LONG_BITORDER) +
+						bit_idx;
+
+					irq = evtchn_to_irq[port];
+
+					if (irq != -1) {
+						desc = irq_to_desc(irq);
+						if (desc)
+							generic_handle_irq_desc(irq, desc);
+					}
+
+					bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+
+					__this_cpu_write(current_bit_idx, bit_idx);
+					__this_cpu_write(current_word_idx_l2,
+							 bit_idx ? word_idx_l2 :
+							 (word_idx_l2+1) % BITS_PER_LONG);
+					__this_cpu_write(current_word_idx_l2,
+							 word_idx_l2 ? word_idx_l1 :
+							 (word_idx_l1+1) % BITS_PER_LONG);
+				} while (bit_idx != 0);
+
+				if ((word_idx_l2 != start_word_idx_l2) || (j != 0))
+					pending_words_l2 &= ~(1UL << word_idx_l2);
+
+				word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
+			}
+
+			if ((word_idx_l1 != start_word_idx_l1) || (i != 0))
+				pending_words_l1 &= ~(1UL << word_idx_l1);
+
+			word_idx_l1 = (word_idx_l1 + 1) % BITS_PER_LONG;
+		}
+
+		BUG_ON(!irqs_disabled());
+		count = __this_cpu_read(xed_nesting_count);
+		__this_cpu_write(xed_nesting_count, 0);
+	} while (count != 1 || vcpu_info->evtchn_upcall_pending);
+
+out:
+	put_cpu();
+}
+
 void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
 	struct pt_regs *old_regs = set_irq_regs(regs);
@@ -1420,6 +1705,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 	case 2:
 		__xen_evtchn_do_upcall_l2();
 		break;
+	case 3:
+		__xen_evtchn_do_upcall_l3();
+		break;
 	default:
 		BUG();
 	}
@@ -1434,6 +1722,9 @@ void xen_hvm_evtchn_do_upcall(void)
 	case 2:
 		__xen_evtchn_do_upcall_l2();
 		break;
+	case 3:
+		__xen_evtchn_do_upcall_l3();
+		break;
 	default:
 		BUG();
 	}
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:32: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 1U2PuW-0007Zy-JJ; Mon, 04 Feb 2013 17:32:52 +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 1U2PuV-0007Yh-2h
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:51 +0000
Received: from [85.158.143.99:10381] by server-3.bemta-4.messagelabs.com id
	E3/EE-08920-2C0FF015; Mon, 04 Feb 2013 17:32:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11596 invoked from network); 4 Feb 2013 17:32:49 -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;
	4 Feb 2013 17:32:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197124"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-CS;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:57 +0000
Message-ID: <1359998638-16774-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 14/15] Only allow 3-level event channel on
	Dom0 and driver domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 non-Dom0 domains, add a flag to indicate whether it can use 3-level event
channel, admins can specify this flag when creating a driver domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/domain.c         |    3 +++
 xen/common/domctl.c         |    5 ++++-
 xen/common/event_channel.c  |    3 +++
 xen/include/public/domctl.h |    3 +++
 xen/include/xen/sched.h     |    5 +++++
 5 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 07f62b3..28405b8 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -250,6 +250,9 @@ struct domain *domain_create(
     if ( domcr_flags & DOMCRF_dummy )
         return d;
 
+    if ( domcr_flags & DOMCRF_evtchn_l3 )
+        d->evtchn_l3 = 1;
+
     if ( !is_idle_domain(d) )
     {
         if ( (err = xsm_domain_create(XSM_HOOK, d, ssidref)) != 0 )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a713ce6..fb61e40 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -369,7 +369,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         if ( supervisor_mode_kernel ||
              (op->u.createdomain.flags &
              ~(XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap |
-               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off)) )
+               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
+               XEN_DOMCTL_CDF_evtchn_l3)) )
             break;
 
         dom = op->domain;
@@ -405,6 +406,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             domcr_flags |= DOMCRF_s3_integrity;
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
+        if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_evtchn_l3 )
+            domcr_flags |= DOMCRF_evtchn_l3;
 
         d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
         if ( IS_ERR(d) )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a91ecba..2d9d0bb 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1262,6 +1262,9 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
     xen_pfn_t l2sel_mfn = 0;
     xen_pfn_t l2sel_offset = 0;
 
+    if ( d->evtchn_l3 == 0 && d->domain_id != 0 )
+        return -EPERM;
+
     if ( d->evtchn_level == EVTCHN_3_LEVEL )
     {
         rc = -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 74160b0..4dacf95 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -59,6 +59,9 @@ struct xen_domctl_createdomain {
  /* Disable out-of-sync shadow page tables? */
 #define _XEN_DOMCTL_CDF_oos_off       3
 #define XEN_DOMCTL_CDF_oos_off        (1U<<_XEN_DOMCTL_CDF_oos_off)
+ /* Can this domain use 3-level event channel? */
+#define _XEN_DOMCTL_CDF_evtchn_l3     4
+#define XEN_DOMCTL_CDF_evtchn_l3    (1U<<_XEN_DOMCTL_CDF_evtchn_l3)
     uint32_t flags;
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 1d8c1b5..931655f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -224,6 +224,8 @@ struct domain
     unsigned int     evtchn_level;
     unsigned long   *evtchn_pending[EVTCHN_MAX_L3_PAGES];
     unsigned long   *evtchn_mask[EVTCHN_MAX_L3_PAGES];
+    /* Can the domain use 3-level event channel? */
+    bool_t           evtchn_l3;
 
     struct grant_table *grant_table;
 
@@ -411,6 +413,9 @@ struct domain *domain_create(
  /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables */
 #define _DOMCRF_oos_off         4
 #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
+/* DOMCRF_evtchn_l3: this domain can use 3-level event channel (driver domain) */
+#define _DOMCRF_evtchn_l3     5
+#define DOMCRF_evtchn_l3      (1U<<_DOMCRF_evtchn_l3)
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:32: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 1U2PuW-0007Zy-JJ; Mon, 04 Feb 2013 17:32:52 +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 1U2PuV-0007Yh-2h
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:51 +0000
Received: from [85.158.143.99:10381] by server-3.bemta-4.messagelabs.com id
	E3/EE-08920-2C0FF015; Mon, 04 Feb 2013 17:32:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11596 invoked from network); 4 Feb 2013 17:32:49 -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;
	4 Feb 2013 17:32:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197124"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-CS;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:57 +0000
Message-ID: <1359998638-16774-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 14/15] Only allow 3-level event channel on
	Dom0 and driver domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 non-Dom0 domains, add a flag to indicate whether it can use 3-level event
channel, admins can specify this flag when creating a driver domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/domain.c         |    3 +++
 xen/common/domctl.c         |    5 ++++-
 xen/common/event_channel.c  |    3 +++
 xen/include/public/domctl.h |    3 +++
 xen/include/xen/sched.h     |    5 +++++
 5 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 07f62b3..28405b8 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -250,6 +250,9 @@ struct domain *domain_create(
     if ( domcr_flags & DOMCRF_dummy )
         return d;
 
+    if ( domcr_flags & DOMCRF_evtchn_l3 )
+        d->evtchn_l3 = 1;
+
     if ( !is_idle_domain(d) )
     {
         if ( (err = xsm_domain_create(XSM_HOOK, d, ssidref)) != 0 )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a713ce6..fb61e40 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -369,7 +369,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         if ( supervisor_mode_kernel ||
              (op->u.createdomain.flags &
              ~(XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap |
-               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off)) )
+               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
+               XEN_DOMCTL_CDF_evtchn_l3)) )
             break;
 
         dom = op->domain;
@@ -405,6 +406,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             domcr_flags |= DOMCRF_s3_integrity;
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
+        if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_evtchn_l3 )
+            domcr_flags |= DOMCRF_evtchn_l3;
 
         d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
         if ( IS_ERR(d) )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a91ecba..2d9d0bb 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1262,6 +1262,9 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
     xen_pfn_t l2sel_mfn = 0;
     xen_pfn_t l2sel_offset = 0;
 
+    if ( d->evtchn_l3 == 0 && d->domain_id != 0 )
+        return -EPERM;
+
     if ( d->evtchn_level == EVTCHN_3_LEVEL )
     {
         rc = -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 74160b0..4dacf95 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -59,6 +59,9 @@ struct xen_domctl_createdomain {
  /* Disable out-of-sync shadow page tables? */
 #define _XEN_DOMCTL_CDF_oos_off       3
 #define XEN_DOMCTL_CDF_oos_off        (1U<<_XEN_DOMCTL_CDF_oos_off)
+ /* Can this domain use 3-level event channel? */
+#define _XEN_DOMCTL_CDF_evtchn_l3     4
+#define XEN_DOMCTL_CDF_evtchn_l3    (1U<<_XEN_DOMCTL_CDF_evtchn_l3)
     uint32_t flags;
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 1d8c1b5..931655f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -224,6 +224,8 @@ struct domain
     unsigned int     evtchn_level;
     unsigned long   *evtchn_pending[EVTCHN_MAX_L3_PAGES];
     unsigned long   *evtchn_mask[EVTCHN_MAX_L3_PAGES];
+    /* Can the domain use 3-level event channel? */
+    bool_t           evtchn_l3;
 
     struct grant_table *grant_table;
 
@@ -411,6 +413,9 @@ struct domain *domain_create(
  /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables */
 #define _DOMCRF_oos_off         4
 #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
+/* DOMCRF_evtchn_l3: this domain can use 3-level event channel (driver domain) */
+#define _DOMCRF_evtchn_l3     5
+#define DOMCRF_evtchn_l3      (1U<<_DOMCRF_evtchn_l3)
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:32: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 1U2PuW-0007Zh-58; Mon, 04 Feb 2013 17:32:52 +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 1U2PuU-0007YO-KG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:50 +0000
Received: from [85.158.143.99:14207] by server-1.bemta-4.messagelabs.com id
	FC/F8-08839-1C0FF015; Mon, 04 Feb 2013 17:32:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11588 invoked from network); 4 Feb 2013 17:32:48 -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;
	4 Feb 2013 17:32:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197104"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:34 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-Aj;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:54 +0000
Message-ID: <1359998638-16774-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 11/15] Genneralized event channel 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

Use pointer in struct domain to reference evtchn_pending and evtchn_mask
bitmaps.

When building a domain, the default operation set is 2-level operation
set.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/arm/domain.c      |    1 +
 xen/arch/x86/domain.c      |    1 +
 xen/common/event_channel.c |   65 ++++++++++++++++++++++++++++++++++++--------
 xen/include/xen/event.h    |    3 ++
 4 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 59d8d73..bc477f6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -417,6 +417,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         goto fail;
 
     clear_page(d->shared_info);
+    evtchn_set_default_bitmap(d);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a58cc1a..a669dc0 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -580,6 +580,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
 
         clear_page(d->shared_info);
+        evtchn_set_default_bitmap(d);
         share_xen_page_with_guest(
             virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 37fecee..1ce97b0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -51,6 +51,9 @@
 
 #define consumer_is_xen(e) (!!(e)->xen_consumer)
 
+static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
+
 /*
  * The function alloc_unbound_xen_event_channel() allows an arbitrary
  * notifier function to be specified. However, very few unique functions
@@ -94,9 +97,6 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 /* Get the notification function for a given Xen-bound event channel. */
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
-static void evtchn_set_pending(struct vcpu *v, int port);
-static void evtchn_clear_pending(struct domain *d, int port);
-
 static int virq_is_global(uint32_t virq)
 {
     int rc;
@@ -159,15 +159,18 @@ static int get_free_port(struct domain *d)
 
 int evtchn_is_pending(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_pending));
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    return test_bit(offset, d->evtchn_pending[page_no]);
 }
 
 int evtchn_is_masked(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_mask));
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    return test_bit(offset, d->evtchn_mask[page_no]);
 }
 
-
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
     struct evtchn *chn;
@@ -623,7 +626,7 @@ out:
     return ret;
 }
 
-static void evtchn_set_pending(struct vcpu *v, int port)
+static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
     int vcpuid;
@@ -664,9 +667,25 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_set_pending(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+
+    switch ( d->evtchn_level )
+    {
+    case EVTCHN_2_LEVEL:
+        evtchn_set_pending_l2(v, port);
+        break;
+    default:
+        BUG();
+    }
+}
+
 static void evtchn_clear_pending(struct domain *d, int port)
 {
-    clear_bit(port, &shared_info(d, evtchn_pending));
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    clear_bit(offset, d->evtchn_pending[page_no]);
 }
 
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
@@ -932,10 +951,12 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id)
 }
 
 
-int evtchn_unmask(unsigned int port)
+static int evtchn_unmask_l2(unsigned int port)
 {
     struct domain *d = current->domain;
     struct vcpu   *v;
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
 
     ASSERT(spin_is_locked(&d->event_lock));
 
@@ -948,8 +969,8 @@ int evtchn_unmask(unsigned int port)
      * These operations must happen in strict order. Based on
      * include/xen/event.h:evtchn_set_pending().
      */
-    if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
-         test_bit          (port, &shared_info(d, evtchn_pending)) &&
+    if ( test_and_clear_bit(offset, d->evtchn_mask[page_no]) &&
+         test_bit          (offset, d->evtchn_pending[page_no]) &&
          !test_and_set_bit (port / BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)) )
     {
@@ -959,6 +980,23 @@ int evtchn_unmask(unsigned int port)
     return 0;
 }
 
+int evtchn_unmask(unsigned int port)
+{
+    struct domain *d = current->domain;
+    int rc = 0;
+
+    switch ( d->evtchn_level )
+    {
+    case EVTCHN_2_LEVEL:
+        rc = evtchn_unmask_l2(port);
+        break;
+    default:
+        BUG();
+    }
+
+    return rc;
+}
+
 
 static long evtchn_reset(evtchn_reset_t *r)
 {
@@ -1185,6 +1223,11 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
     spin_unlock(&ld->event_lock);
 }
 
+void evtchn_set_default_bitmap(struct domain *d)
+{
+    d->evtchn_pending[0] = (unsigned long *)shared_info(d, evtchn_pending);
+    d->evtchn_mask[0] = (unsigned long *)shared_info(d, evtchn_mask);
+}
 
 int evtchn_init(struct domain *d)
 {
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 9640a8c..5fe4149 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -148,6 +148,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* This is called after domain's shared info page is setup */
+void evtchn_set_default_bitmap(struct domain *d);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:32: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 1U2PuW-0007Zh-58; Mon, 04 Feb 2013 17:32:52 +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 1U2PuU-0007YO-KG
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:50 +0000
Received: from [85.158.143.99:14207] by server-1.bemta-4.messagelabs.com id
	FC/F8-08839-1C0FF015; Mon, 04 Feb 2013 17:32:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11588 invoked from network); 4 Feb 2013 17:32:48 -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;
	4 Feb 2013 17:32:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197104"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:34 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-Aj;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:54 +0000
Message-ID: <1359998638-16774-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 11/15] Genneralized event channel 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

Use pointer in struct domain to reference evtchn_pending and evtchn_mask
bitmaps.

When building a domain, the default operation set is 2-level operation
set.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/arm/domain.c      |    1 +
 xen/arch/x86/domain.c      |    1 +
 xen/common/event_channel.c |   65 ++++++++++++++++++++++++++++++++++++--------
 xen/include/xen/event.h    |    3 ++
 4 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 59d8d73..bc477f6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -417,6 +417,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         goto fail;
 
     clear_page(d->shared_info);
+    evtchn_set_default_bitmap(d);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a58cc1a..a669dc0 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -580,6 +580,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
 
         clear_page(d->shared_info);
+        evtchn_set_default_bitmap(d);
         share_xen_page_with_guest(
             virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 37fecee..1ce97b0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -51,6 +51,9 @@
 
 #define consumer_is_xen(e) (!!(e)->xen_consumer)
 
+static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
+
 /*
  * The function alloc_unbound_xen_event_channel() allows an arbitrary
  * notifier function to be specified. However, very few unique functions
@@ -94,9 +97,6 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 /* Get the notification function for a given Xen-bound event channel. */
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
-static void evtchn_set_pending(struct vcpu *v, int port);
-static void evtchn_clear_pending(struct domain *d, int port);
-
 static int virq_is_global(uint32_t virq)
 {
     int rc;
@@ -159,15 +159,18 @@ static int get_free_port(struct domain *d)
 
 int evtchn_is_pending(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_pending));
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    return test_bit(offset, d->evtchn_pending[page_no]);
 }
 
 int evtchn_is_masked(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_mask));
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    return test_bit(offset, d->evtchn_mask[page_no]);
 }
 
-
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
     struct evtchn *chn;
@@ -623,7 +626,7 @@ out:
     return ret;
 }
 
-static void evtchn_set_pending(struct vcpu *v, int port)
+static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
     int vcpuid;
@@ -664,9 +667,25 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_set_pending(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+
+    switch ( d->evtchn_level )
+    {
+    case EVTCHN_2_LEVEL:
+        evtchn_set_pending_l2(v, port);
+        break;
+    default:
+        BUG();
+    }
+}
+
 static void evtchn_clear_pending(struct domain *d, int port)
 {
-    clear_bit(port, &shared_info(d, evtchn_pending));
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    clear_bit(offset, d->evtchn_pending[page_no]);
 }
 
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
@@ -932,10 +951,12 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id)
 }
 
 
-int evtchn_unmask(unsigned int port)
+static int evtchn_unmask_l2(unsigned int port)
 {
     struct domain *d = current->domain;
     struct vcpu   *v;
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
 
     ASSERT(spin_is_locked(&d->event_lock));
 
@@ -948,8 +969,8 @@ int evtchn_unmask(unsigned int port)
      * These operations must happen in strict order. Based on
      * include/xen/event.h:evtchn_set_pending().
      */
-    if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
-         test_bit          (port, &shared_info(d, evtchn_pending)) &&
+    if ( test_and_clear_bit(offset, d->evtchn_mask[page_no]) &&
+         test_bit          (offset, d->evtchn_pending[page_no]) &&
          !test_and_set_bit (port / BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)) )
     {
@@ -959,6 +980,23 @@ int evtchn_unmask(unsigned int port)
     return 0;
 }
 
+int evtchn_unmask(unsigned int port)
+{
+    struct domain *d = current->domain;
+    int rc = 0;
+
+    switch ( d->evtchn_level )
+    {
+    case EVTCHN_2_LEVEL:
+        rc = evtchn_unmask_l2(port);
+        break;
+    default:
+        BUG();
+    }
+
+    return rc;
+}
+
 
 static long evtchn_reset(evtchn_reset_t *r)
 {
@@ -1185,6 +1223,11 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
     spin_unlock(&ld->event_lock);
 }
 
+void evtchn_set_default_bitmap(struct domain *d)
+{
+    d->evtchn_pending[0] = (unsigned long *)shared_info(d, evtchn_pending);
+    d->evtchn_mask[0] = (unsigned long *)shared_info(d, evtchn_mask);
+}
 
 int evtchn_init(struct domain *d)
 {
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 9640a8c..5fe4149 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -148,6 +148,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* This is called after domain's shared info page is setup */
+void evtchn_set_default_bitmap(struct domain *d);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:32: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 1U2PuX-0007aF-27; Mon, 04 Feb 2013 17:32:53 +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 1U2PuV-0007ZA-MR
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:51 +0000
Received: from [85.158.143.99:10405] by server-2.bemta-4.messagelabs.com id
	54/3B-01597-2C0FF015; Mon, 04 Feb 2013 17:32:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11604 invoked from network); 4 Feb 2013 17:32:50 -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;
	4 Feb 2013 17:32:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197135"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:48 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-91;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:53 +0000
Message-ID: <1359998638-16774-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 10/15] Make NR_EVTCHN_BUCKETS 3-level ready
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/xen/event.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 4474296..9640a8c 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -37,7 +37,7 @@
 			__v;})
 
 #define EVTCHNS_PER_BUCKET 512
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS_L3 / EVTCHNS_PER_BUCKET)
 
 /* N.B. EVTCHNS_PER_PAGE is always powers of 2, use shifts to optimize */
 #define EVTCHNS_SHIFT (PAGE_SHIFT+BYTE_BITORDER)
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:32: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 1U2PuX-0007aF-27; Mon, 04 Feb 2013 17:32:53 +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 1U2PuV-0007ZA-MR
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:51 +0000
Received: from [85.158.143.99:10405] by server-2.bemta-4.messagelabs.com id
	54/3B-01597-2C0FF015; Mon, 04 Feb 2013 17:32:50 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11604 invoked from network); 4 Feb 2013 17:32:50 -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;
	4 Feb 2013 17:32:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197135"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:48 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-91;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:53 +0000
Message-ID: <1359998638-16774-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 10/15] Make NR_EVTCHN_BUCKETS 3-level ready
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/xen/event.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 4474296..9640a8c 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -37,7 +37,7 @@
 			__v;})
 
 #define EVTCHNS_PER_BUCKET 512
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS_L3 / EVTCHNS_PER_BUCKET)
 
 /* N.B. EVTCHNS_PER_PAGE is always powers of 2, use shifts to optimize */
 #define EVTCHNS_SHIFT (PAGE_SHIFT+BYTE_BITORDER)
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuY-0007bH-GL; Mon, 04 Feb 2013 17:32:54 +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 1U2PuX-0007a5-9a
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:53 +0000
Received: from [85.158.139.83:45716] by server-9.bemta-5.messagelabs.com id
	0D/3F-24440-4C0FF015; Mon, 04 Feb 2013 17:32:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25568 invoked from network); 4 Feb 2013 17:32:51 -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;
	4 Feb 2013 17:32:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891219"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:50 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-Bo;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:56 +0000
Message-ID: <1359998638-16774-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 13/15] Implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |  110 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 90 insertions(+), 20 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 411bef8..a91ecba 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -627,10 +627,33 @@ out:
     return ret;
 }
 
+static void __check_vcpu_polling(struct vcpu *v, int port)
+{
+    int vcpuid;
+    struct domain *d = v->domain;
+
+    /* Check if some VCPU might be polling for this event. */
+    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
+        return;
+
+    /* Wake any interested (or potentially interested) pollers. */
+    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
+          vcpuid < d->max_vcpus;
+          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+    {
+        v = d->vcpu[vcpuid];
+        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
+             test_and_clear_bit(vcpuid, d->poll_mask) )
+        {
+            v->poll_evtchn = 0;
+            vcpu_unblock(v);
+        }
+    }
+}
+
 static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
-    int vcpuid;
 
     /*
      * The following bit operations must happen in strict order.
@@ -649,23 +672,35 @@ static void evtchn_set_pending_l2(struct vcpu *v, int port)
         vcpu_mark_events_pending(v);
     }
 
-    /* Check if some VCPU might be polling for this event. */
-    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
-        return;
+    __check_vcpu_polling(v, port);
+}
 
-    /* Wake any interested (or potentially interested) pollers. */
-    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
-          vcpuid < d->max_vcpus;
-          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+static void evtchn_set_pending_l3(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    /*
+     * The following bit operations must happen in strict order.
+     * NB. On x86, the atomic bit operations also act as memory barriers.
+     * There is therefore sufficiently strict ordering for this architecture --
+     * others may require explicit memory barriers.
+     */
+
+    if ( test_and_set_bit(offset, d->evtchn_pending[page_no]) )
+         return;
+
+    if ( !test_bit(offset, d->evtchn_mask[page_no]) &&
+         !test_and_set_bit(l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit(l1bit, &vcpu_info(v, evtchn_pending_sel)) )
     {
-        v = d->vcpu[vcpuid];
-        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
-             test_and_clear_bit(vcpuid, d->poll_mask) )
-        {
-            v->poll_evtchn = 0;
-            vcpu_unblock(v);
-        }
+        vcpu_mark_events_pending(v);
     }
+
+    __check_vcpu_polling(v, port);
 }
 
 static void evtchn_set_pending(struct vcpu *v, int port)
@@ -677,6 +712,9 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     case EVTCHN_2_LEVEL:
         evtchn_set_pending_l2(v, port);
         break;
+    case 3:
+        evtchn_set_pending_l3(v, port);
+        break;
     default:
         BUG();
     }
@@ -981,6 +1019,37 @@ static int evtchn_unmask_l2(unsigned int port)
     return 0;
 }
 
+static int evtchn_unmask_l3(unsigned int port)
+{
+    struct domain *d = current->domain;
+    struct vcpu   *v;
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    if ( unlikely(!port_is_valid(d, port)) )
+        return -EINVAL;
+
+    v = d->vcpu[evtchn_from_port(d, port)->notify_vcpu_id];
+
+    /*
+     * These operations must happen in strict order. Based on
+     * include/xen/event.h:evtchn_set_pending().
+     */
+    if ( test_and_clear_bit(offset, d->evtchn_mask[page_no]) &&
+         test_bit          (offset, d->evtchn_pending[page_no]) &&
+         !test_and_set_bit (l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit (l1bit, &vcpu_info(v, evtchn_pending_sel)) )
+    {
+        vcpu_mark_events_pending(v);
+    }
+
+    return 0;
+}
+
 int evtchn_unmask(unsigned int port)
 {
     struct domain *d = current->domain;
@@ -991,6 +1060,9 @@ int evtchn_unmask(unsigned int port)
     case EVTCHN_2_LEVEL:
         rc = evtchn_unmask_l2(port);
         break;
+    case 3:
+        rc = evtchn_unmask_l3(port);
+        break;
     default:
         BUG();
     }
@@ -1392,10 +1464,6 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&reg, arg, 1) != 0 )
             return -EFAULT;
         rc = evtchn_register_nlevel(&reg);
-
-        /* XXX always fails this call because it is not yet completed */
-        rc = -EINVAL;
-
         break;
     }
 
@@ -1604,8 +1672,10 @@ static void domain_dump_evtchn_info(struct domain *d)
     bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
                          d->poll_mask, d->max_vcpus);
     printk("Event channel information for domain %d:\n"
+           "Using %d-level event channel\n"
            "Polling vCPUs: {%s}\n"
-           "    port [p/m]\n", d->domain_id, keyhandler_scratch);
+           "    port [p/m]\n",
+           d->domain_id, d->evtchn_level, keyhandler_scratch);
 
     spin_lock(&d->event_lock);
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuY-0007bH-GL; Mon, 04 Feb 2013 17:32:54 +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 1U2PuX-0007a5-9a
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:53 +0000
Received: from [85.158.139.83:45716] by server-9.bemta-5.messagelabs.com id
	0D/3F-24440-4C0FF015; Mon, 04 Feb 2013 17:32:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1359999152!23466445!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25568 invoked from network); 4 Feb 2013 17:32:51 -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;
	4 Feb 2013 17:32:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891219"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:50 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-Bo;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:56 +0000
Message-ID: <1359998638-16774-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 13/15] Implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |  110 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 90 insertions(+), 20 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 411bef8..a91ecba 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -627,10 +627,33 @@ out:
     return ret;
 }
 
+static void __check_vcpu_polling(struct vcpu *v, int port)
+{
+    int vcpuid;
+    struct domain *d = v->domain;
+
+    /* Check if some VCPU might be polling for this event. */
+    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
+        return;
+
+    /* Wake any interested (or potentially interested) pollers. */
+    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
+          vcpuid < d->max_vcpus;
+          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+    {
+        v = d->vcpu[vcpuid];
+        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
+             test_and_clear_bit(vcpuid, d->poll_mask) )
+        {
+            v->poll_evtchn = 0;
+            vcpu_unblock(v);
+        }
+    }
+}
+
 static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
-    int vcpuid;
 
     /*
      * The following bit operations must happen in strict order.
@@ -649,23 +672,35 @@ static void evtchn_set_pending_l2(struct vcpu *v, int port)
         vcpu_mark_events_pending(v);
     }
 
-    /* Check if some VCPU might be polling for this event. */
-    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
-        return;
+    __check_vcpu_polling(v, port);
+}
 
-    /* Wake any interested (or potentially interested) pollers. */
-    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
-          vcpuid < d->max_vcpus;
-          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+static void evtchn_set_pending_l3(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    /*
+     * The following bit operations must happen in strict order.
+     * NB. On x86, the atomic bit operations also act as memory barriers.
+     * There is therefore sufficiently strict ordering for this architecture --
+     * others may require explicit memory barriers.
+     */
+
+    if ( test_and_set_bit(offset, d->evtchn_pending[page_no]) )
+         return;
+
+    if ( !test_bit(offset, d->evtchn_mask[page_no]) &&
+         !test_and_set_bit(l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit(l1bit, &vcpu_info(v, evtchn_pending_sel)) )
     {
-        v = d->vcpu[vcpuid];
-        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
-             test_and_clear_bit(vcpuid, d->poll_mask) )
-        {
-            v->poll_evtchn = 0;
-            vcpu_unblock(v);
-        }
+        vcpu_mark_events_pending(v);
     }
+
+    __check_vcpu_polling(v, port);
 }
 
 static void evtchn_set_pending(struct vcpu *v, int port)
@@ -677,6 +712,9 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     case EVTCHN_2_LEVEL:
         evtchn_set_pending_l2(v, port);
         break;
+    case 3:
+        evtchn_set_pending_l3(v, port);
+        break;
     default:
         BUG();
     }
@@ -981,6 +1019,37 @@ static int evtchn_unmask_l2(unsigned int port)
     return 0;
 }
 
+static int evtchn_unmask_l3(unsigned int port)
+{
+    struct domain *d = current->domain;
+    struct vcpu   *v;
+    unsigned int page_no = EVTCHN_PAGE_NO(port);
+    unsigned int offset = EVTCHN_OFFSET_IN_PAGE(port);
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    if ( unlikely(!port_is_valid(d, port)) )
+        return -EINVAL;
+
+    v = d->vcpu[evtchn_from_port(d, port)->notify_vcpu_id];
+
+    /*
+     * These operations must happen in strict order. Based on
+     * include/xen/event.h:evtchn_set_pending().
+     */
+    if ( test_and_clear_bit(offset, d->evtchn_mask[page_no]) &&
+         test_bit          (offset, d->evtchn_pending[page_no]) &&
+         !test_and_set_bit (l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit (l1bit, &vcpu_info(v, evtchn_pending_sel)) )
+    {
+        vcpu_mark_events_pending(v);
+    }
+
+    return 0;
+}
+
 int evtchn_unmask(unsigned int port)
 {
     struct domain *d = current->domain;
@@ -991,6 +1060,9 @@ int evtchn_unmask(unsigned int port)
     case EVTCHN_2_LEVEL:
         rc = evtchn_unmask_l2(port);
         break;
+    case 3:
+        rc = evtchn_unmask_l3(port);
+        break;
     default:
         BUG();
     }
@@ -1392,10 +1464,6 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( copy_from_guest(&reg, arg, 1) != 0 )
             return -EFAULT;
         rc = evtchn_register_nlevel(&reg);
-
-        /* XXX always fails this call because it is not yet completed */
-        rc = -EINVAL;
-
         break;
     }
 
@@ -1604,8 +1672,10 @@ static void domain_dump_evtchn_info(struct domain *d)
     bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
                          d->poll_mask, d->max_vcpus);
     printk("Event channel information for domain %d:\n"
+           "Using %d-level event channel\n"
            "Polling vCPUs: {%s}\n"
-           "    port [p/m]\n", d->domain_id, keyhandler_scratch);
+           "    port [p/m]\n",
+           d->domain_id, d->evtchn_level, keyhandler_scratch);
 
     spin_lock(&d->event_lock);
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuY-0007bW-SC; Mon, 04 Feb 2013 17:32:54 +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 1U2PuY-0007ZA-3s
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:54 +0000
Received: from [85.158.143.99:14320] by server-2.bemta-4.messagelabs.com id
	DE/3B-01597-5C0FF015; Mon, 04 Feb 2013 17:32:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11693 invoked from network); 4 Feb 2013 17:32:53 -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;
	4 Feb 2013 17:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197144"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-8B;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:54 +0000
Message-ID: <1359998635-16866-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 13/13] xen: register 3-level 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

3-level event channel is registered in
 a) xen_init_IRQ(), when the guest is fresh started;
 b) xen_vcpu_restore(), when the guest is restored.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 arch/x86/xen/enlighten.c |    3 +++
 drivers/xen/events.c     |    2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bc893e7..722a994 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -43,6 +43,7 @@
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>
 #include <xen/acpi.h>
+#include <xen/events.h>
 
 #include <asm/paravirt.h>
 #include <asm/apic.h>
@@ -195,6 +196,8 @@ void xen_vcpu_restore(void)
 		    HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL))
 			BUG();
 	}
+
+	xen_event_channel_register_nlevel(3);
 }
 
 static void __init xen_banner(void)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6a0307c..849d049 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -2270,7 +2270,7 @@ void __init xen_init_IRQ(void)
 	int i, rc;
 	int cpu;
 
-	xen_set_event_channel_nlevel(2);
+	xen_event_channel_register_nlevel(3);
 
 	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:32:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PuY-0007bW-SC; Mon, 04 Feb 2013 17:32:54 +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 1U2PuY-0007ZA-3s
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:54 +0000
Received: from [85.158.143.99:14320] by server-2.bemta-4.messagelabs.com id
	DE/3B-01597-5C0FF015; Mon, 04 Feb 2013 17:32:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1359999166!29248347!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11693 invoked from network); 4 Feb 2013 17:32:53 -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;
	4 Feb 2013 17:32:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197144"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmO-0001SL-8B;
	Mon, 04 Feb 2013 17:24:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:54 +0000
Message-ID: <1359998635-16866-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: david.vrabel@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	ian.campbell@citrix.com, jbeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH V2 13/13] xen: register 3-level 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

3-level event channel is registered in
 a) xen_init_IRQ(), when the guest is fresh started;
 b) xen_vcpu_restore(), when the guest is restored.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 arch/x86/xen/enlighten.c |    3 +++
 drivers/xen/events.c     |    2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bc893e7..722a994 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -43,6 +43,7 @@
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>
 #include <xen/acpi.h>
+#include <xen/events.h>
 
 #include <asm/paravirt.h>
 #include <asm/apic.h>
@@ -195,6 +196,8 @@ void xen_vcpu_restore(void)
 		    HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL))
 			BUG();
 	}
+
+	xen_event_channel_register_nlevel(3);
 }
 
 static void __init xen_banner(void)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6a0307c..849d049 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -2270,7 +2270,7 @@ void __init xen_init_IRQ(void)
 	int i, rc;
 	int cpu;
 
-	xen_set_event_channel_nlevel(2);
+	xen_event_channel_register_nlevel(3);
 
 	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:33:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PvI-00086S-N9; Mon, 04 Feb 2013 17:33:40 +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 1U2PvG-00084Y-Kh
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:33:38 +0000
Received: from [193.109.254.147:45750] by server-11.bemta-14.messagelabs.com
	id 64/9D-30685-2F0FF015; Mon, 04 Feb 2013 17:33:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359999168!10055733!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19587 invoked from network); 4 Feb 2013 17:32:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:32:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197108"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:38 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-BE;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:55 +0000
Message-ID: <1359998638-16774-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 12/15] Infrastructure for manipulating
	3-level event channel 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

NOTE: the registration call is always failed because other part of the code is
not yet completed.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |  280 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 280 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 1ce97b0..411bef8 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -26,6 +26,7 @@
 #include <xen/compat.h>
 #include <xen/guest_access.h>
 #include <xen/keyhandler.h>
+#include <xen/paging.h>
 #include <asm/current.h>
 
 #include <public/xen.h>
@@ -1024,6 +1025,260 @@ out:
 }
 
 
+static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
+                            xen_pfn_t *mask, int nr_pages)
+{
+    int rc;
+    void *mapping;
+    struct page_info *pginfo;
+    unsigned long gfn;
+    int pending_count = 0, mask_count = 0;
+
+#define __MAP(src, dst, cnt)                                    \
+    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
+    {                                                           \
+        rc = -EINVAL;                                           \
+        gfn = (src)[(cnt)];                                     \
+        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
+        if ( !pginfo )                                          \
+            goto err;                                           \
+        if ( !get_page_type(pginfo, PGT_writable_page) )        \
+        {                                                       \
+            put_page(pginfo);                                   \
+            goto err;                                           \
+        }                                                       \
+        mapping = __map_domain_page_global(pginfo);             \
+        if ( !mapping )                                         \
+        {                                                       \
+            put_page_and_type(pginfo);                          \
+            rc = -ENOMEM;                                       \
+            goto err;                                           \
+        }                                                       \
+        (dst)[(cnt)] = mapping;                                 \
+    }
+
+    __MAP(pending, d->evtchn_pending, pending_count)
+    __MAP(mask, d->evtchn_mask, mask_count)
+#undef __MAP
+
+    rc = 0;
+
+ err:
+    return rc;
+}
+
+static void __unmap_l3_arrays(struct domain *d)
+{
+    int i;
+    unsigned long mfn;
+
+    for ( i = 0; i < EVTCHN_MAX_L3_PAGES; i++ )
+    {
+        if ( d->evtchn_pending[i] != 0 )
+        {
+            mfn = domain_page_map_to_mfn(d->evtchn_pending[i]);
+            unmap_domain_page_global(d->evtchn_pending[i]);
+            put_page_and_type(mfn_to_page(mfn));
+            d->evtchn_pending[i] = 0;
+        }
+        if ( d->evtchn_mask[i] != 0 )
+        {
+            mfn = domain_page_map_to_mfn(d->evtchn_mask[i]);
+            unmap_domain_page_global(d->evtchn_mask[i]);
+            put_page_and_type(mfn_to_page(mfn));
+            d->evtchn_mask[i] = 0;
+        }
+    }
+}
+
+static long __map_l2_selector(struct vcpu *v, unsigned long gfn,
+                              unsigned long off)
+{
+    void *mapping;
+    int rc;
+    struct page_info *page;
+    struct domain *d = v->domain;
+
+    rc = -EINVAL;   /* common errno for following operations */
+
+    /* Sanity check: L2 selector has maximum size of sizeof(unsigned
+     * long) * 8, this size is equal to the size of shared bitmap
+     * array of 2-level event channel. */
+    if ( off + sizeof(unsigned long) * 8 >= PAGE_SIZE )
+        goto out;
+
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        goto out;
+
+    if ( !get_page_type(page, PGT_writable_page) )
+    {
+        put_page(page);
+        goto out;
+    }
+
+    /* Use global mapping here, because these selectors will also be
+     * accessed by other domains when setting pending for inter-domain
+     * event channels.
+     */
+    mapping = __map_domain_page_global(page);
+
+    if ( mapping == NULL )
+    {
+        put_page_and_type(page);
+        rc = -ENOMEM;
+        goto out;
+    }
+
+    v->evtchn_pending_sel_l2 = mapping + off;
+    rc = 0;
+
+ out:
+    return rc;
+}
+
+static void __unmap_l2_selector(struct vcpu *v)
+{
+    unsigned long mfn;
+
+    if ( v->evtchn_pending_sel_l2 )
+    {
+        mfn = domain_page_map_to_mfn(v->evtchn_pending_sel_l2);
+        unmap_domain_page_global(v->evtchn_pending_sel_l2);
+        put_page_and_type(mfn_to_page(mfn));
+        v->evtchn_pending_sel_l2 = NULL;
+    }
+}
+
+static void __evtchn_unmap_all_3level(struct domain *d)
+{
+    struct vcpu *v;
+    for_each_vcpu ( d, v )
+        __unmap_l2_selector(v);
+    __unmap_l3_arrays(d);
+}
+
+static void __evtchn_setup_bitmap_l3(struct domain *d)
+{
+    struct vcpu *v;
+
+    /* Easy way to setup 3-level bitmap, just move existing selector
+     * to next level then copy pending array and mask array */
+    for_each_vcpu ( d, v )
+    {
+        memcpy(&v->evtchn_pending_sel_l2[0],
+               &vcpu_info(v, evtchn_pending_sel),
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        memset(&vcpu_info(v, evtchn_pending_sel), 0,
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        set_bit(0, &vcpu_info(v, evtchn_pending_sel));
+    }
+
+    memcpy(d->evtchn_pending[0], &shared_info(d, evtchn_pending),
+           sizeof(shared_info(d, evtchn_pending)));
+    memcpy(d->evtchn_mask[0], &shared_info(d, evtchn_mask),
+           sizeof(shared_info(d, evtchn_mask)));
+}
+
+static long evtchn_register_3level(evtchn_register_3level_t *arg)
+{
+    struct domain *d = current->domain;
+    struct vcpu *v;
+    int rc = 0;
+    xen_pfn_t evtchn_pending[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t evtchn_mask[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t l2sel_mfn = 0;
+    xen_pfn_t l2sel_offset = 0;
+
+    if ( d->evtchn_level == EVTCHN_3_LEVEL )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    if ( arg->nr_vcpus > d->max_vcpus ||
+         arg->nr_pages > EVTCHN_MAX_L3_PAGES )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    memset(evtchn_pending, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+    memset(evtchn_mask, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+
+    rc = -EFAULT; /* common error code for following operations */
+    if ( copy_from_guest(evtchn_pending, arg->evtchn_pending, arg->nr_pages) )
+        goto out;
+    if ( copy_from_guest(evtchn_mask, arg->evtchn_mask, arg->nr_pages) )
+        goto out;
+
+    rc = __map_l3_arrays(d, evtchn_pending, evtchn_mask, arg->nr_pages);
+    if ( rc )
+        goto out;
+
+    for_each_vcpu ( d, v )
+    {
+        int vcpu_id = v->vcpu_id;
+
+        rc = -EFAULT; /* common error code for following operations */
+        if ( unlikely(copy_from_guest_offset(&l2sel_mfn, arg->l2sel_mfns,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+        if ( unlikely(copy_from_guest_offset(&l2sel_offset, arg->l2sel_offsets,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+
+        if ( (rc = __map_l2_selector(v, l2sel_mfn, l2sel_offset)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+    }
+
+    __evtchn_setup_bitmap_l3(d);
+
+    d->evtchn_level = EVTCHN_3_LEVEL;
+
+    rc = 0;
+
+ out:
+    return rc;
+}
+
+/*
+ * NOTE to N-level event channel users:
+ * N-level channels are likely to consume lots large global mapping
+ * area in Xen. For example, 3-level event channel consumes 16 +
+ * nr_vcpus pages global mapping area. So *ONLY* enable N-level event
+ * channel for Dom0 or driver domains.
+ */
+static long evtchn_register_nlevel(struct evtchn_register_nlevel *reg)
+{
+    struct domain *d = current->domain;
+    int rc;
+
+    spin_lock(&d->event_lock);
+
+    switch ( reg->level )
+    {
+    case EVTCHN_3_LEVEL:
+        rc = evtchn_register_3level(&reg->u.l3);
+        break;
+    default:
+        rc = -EINVAL;
+    }
+
+    spin_unlock(&d->event_lock);
+
+    return rc;
+}
+
 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
@@ -1132,6 +1387,18 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+    case EVTCHNOP_register_nlevel: {
+        struct evtchn_register_nlevel reg;
+        if ( copy_from_guest(&reg, arg, 1) != 0 )
+            return -EFAULT;
+        rc = evtchn_register_nlevel(&reg);
+
+        /* XXX always fails this call because it is not yet completed */
+        rc = -EINVAL;
+
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
@@ -1258,6 +1525,17 @@ int evtchn_init(struct domain *d)
     return 0;
 }
 
+static void evtchn_unmap_nlevel(struct domain *d)
+{
+    switch ( d->evtchn_level )
+    {
+    case EVTCHN_3_LEVEL:
+        __evtchn_unmap_all_3level(d);
+        break;
+    default:
+        break;
+    }
+}
 
 void evtchn_destroy(struct domain *d)
 {
@@ -1286,6 +1564,8 @@ void evtchn_destroy(struct domain *d)
 
     clear_global_virq_handlers(d);
 
+    evtchn_unmap_nlevel(d);
+
     free_xenheap_page(d->evtchn);
 }
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:33:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PvI-00086S-N9; Mon, 04 Feb 2013 17:33:40 +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 1U2PvG-00084Y-Kh
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:33:38 +0000
Received: from [193.109.254.147:45750] by server-11.bemta-14.messagelabs.com
	id 64/9D-30685-2F0FF015; Mon, 04 Feb 2013 17:33:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1359999168!10055733!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19587 invoked from network); 4 Feb 2013 17:32:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:32:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6197108"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:32:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:32:38 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PmL-0001Rd-BE;
	Mon, 04 Feb 2013 17:24:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 4 Feb 2013 17:23:55 +0000
Message-ID: <1359998638-16774-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com, jbeulich@suse.com,
	david.vrabel@citrix.com
Subject: [Xen-devel] [PATCH V2 12/15] Infrastructure for manipulating
	3-level event channel 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

NOTE: the registration call is always failed because other part of the code is
not yet completed.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |  280 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 280 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 1ce97b0..411bef8 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -26,6 +26,7 @@
 #include <xen/compat.h>
 #include <xen/guest_access.h>
 #include <xen/keyhandler.h>
+#include <xen/paging.h>
 #include <asm/current.h>
 
 #include <public/xen.h>
@@ -1024,6 +1025,260 @@ out:
 }
 
 
+static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
+                            xen_pfn_t *mask, int nr_pages)
+{
+    int rc;
+    void *mapping;
+    struct page_info *pginfo;
+    unsigned long gfn;
+    int pending_count = 0, mask_count = 0;
+
+#define __MAP(src, dst, cnt)                                    \
+    for ( (cnt) = 0; (cnt) < nr_pages; (cnt)++ )                \
+    {                                                           \
+        rc = -EINVAL;                                           \
+        gfn = (src)[(cnt)];                                     \
+        pginfo = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);    \
+        if ( !pginfo )                                          \
+            goto err;                                           \
+        if ( !get_page_type(pginfo, PGT_writable_page) )        \
+        {                                                       \
+            put_page(pginfo);                                   \
+            goto err;                                           \
+        }                                                       \
+        mapping = __map_domain_page_global(pginfo);             \
+        if ( !mapping )                                         \
+        {                                                       \
+            put_page_and_type(pginfo);                          \
+            rc = -ENOMEM;                                       \
+            goto err;                                           \
+        }                                                       \
+        (dst)[(cnt)] = mapping;                                 \
+    }
+
+    __MAP(pending, d->evtchn_pending, pending_count)
+    __MAP(mask, d->evtchn_mask, mask_count)
+#undef __MAP
+
+    rc = 0;
+
+ err:
+    return rc;
+}
+
+static void __unmap_l3_arrays(struct domain *d)
+{
+    int i;
+    unsigned long mfn;
+
+    for ( i = 0; i < EVTCHN_MAX_L3_PAGES; i++ )
+    {
+        if ( d->evtchn_pending[i] != 0 )
+        {
+            mfn = domain_page_map_to_mfn(d->evtchn_pending[i]);
+            unmap_domain_page_global(d->evtchn_pending[i]);
+            put_page_and_type(mfn_to_page(mfn));
+            d->evtchn_pending[i] = 0;
+        }
+        if ( d->evtchn_mask[i] != 0 )
+        {
+            mfn = domain_page_map_to_mfn(d->evtchn_mask[i]);
+            unmap_domain_page_global(d->evtchn_mask[i]);
+            put_page_and_type(mfn_to_page(mfn));
+            d->evtchn_mask[i] = 0;
+        }
+    }
+}
+
+static long __map_l2_selector(struct vcpu *v, unsigned long gfn,
+                              unsigned long off)
+{
+    void *mapping;
+    int rc;
+    struct page_info *page;
+    struct domain *d = v->domain;
+
+    rc = -EINVAL;   /* common errno for following operations */
+
+    /* Sanity check: L2 selector has maximum size of sizeof(unsigned
+     * long) * 8, this size is equal to the size of shared bitmap
+     * array of 2-level event channel. */
+    if ( off + sizeof(unsigned long) * 8 >= PAGE_SIZE )
+        goto out;
+
+    page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+    if ( !page )
+        goto out;
+
+    if ( !get_page_type(page, PGT_writable_page) )
+    {
+        put_page(page);
+        goto out;
+    }
+
+    /* Use global mapping here, because these selectors will also be
+     * accessed by other domains when setting pending for inter-domain
+     * event channels.
+     */
+    mapping = __map_domain_page_global(page);
+
+    if ( mapping == NULL )
+    {
+        put_page_and_type(page);
+        rc = -ENOMEM;
+        goto out;
+    }
+
+    v->evtchn_pending_sel_l2 = mapping + off;
+    rc = 0;
+
+ out:
+    return rc;
+}
+
+static void __unmap_l2_selector(struct vcpu *v)
+{
+    unsigned long mfn;
+
+    if ( v->evtchn_pending_sel_l2 )
+    {
+        mfn = domain_page_map_to_mfn(v->evtchn_pending_sel_l2);
+        unmap_domain_page_global(v->evtchn_pending_sel_l2);
+        put_page_and_type(mfn_to_page(mfn));
+        v->evtchn_pending_sel_l2 = NULL;
+    }
+}
+
+static void __evtchn_unmap_all_3level(struct domain *d)
+{
+    struct vcpu *v;
+    for_each_vcpu ( d, v )
+        __unmap_l2_selector(v);
+    __unmap_l3_arrays(d);
+}
+
+static void __evtchn_setup_bitmap_l3(struct domain *d)
+{
+    struct vcpu *v;
+
+    /* Easy way to setup 3-level bitmap, just move existing selector
+     * to next level then copy pending array and mask array */
+    for_each_vcpu ( d, v )
+    {
+        memcpy(&v->evtchn_pending_sel_l2[0],
+               &vcpu_info(v, evtchn_pending_sel),
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        memset(&vcpu_info(v, evtchn_pending_sel), 0,
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        set_bit(0, &vcpu_info(v, evtchn_pending_sel));
+    }
+
+    memcpy(d->evtchn_pending[0], &shared_info(d, evtchn_pending),
+           sizeof(shared_info(d, evtchn_pending)));
+    memcpy(d->evtchn_mask[0], &shared_info(d, evtchn_mask),
+           sizeof(shared_info(d, evtchn_mask)));
+}
+
+static long evtchn_register_3level(evtchn_register_3level_t *arg)
+{
+    struct domain *d = current->domain;
+    struct vcpu *v;
+    int rc = 0;
+    xen_pfn_t evtchn_pending[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t evtchn_mask[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t l2sel_mfn = 0;
+    xen_pfn_t l2sel_offset = 0;
+
+    if ( d->evtchn_level == EVTCHN_3_LEVEL )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    if ( arg->nr_vcpus > d->max_vcpus ||
+         arg->nr_pages > EVTCHN_MAX_L3_PAGES )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    memset(evtchn_pending, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+    memset(evtchn_mask, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+
+    rc = -EFAULT; /* common error code for following operations */
+    if ( copy_from_guest(evtchn_pending, arg->evtchn_pending, arg->nr_pages) )
+        goto out;
+    if ( copy_from_guest(evtchn_mask, arg->evtchn_mask, arg->nr_pages) )
+        goto out;
+
+    rc = __map_l3_arrays(d, evtchn_pending, evtchn_mask, arg->nr_pages);
+    if ( rc )
+        goto out;
+
+    for_each_vcpu ( d, v )
+    {
+        int vcpu_id = v->vcpu_id;
+
+        rc = -EFAULT; /* common error code for following operations */
+        if ( unlikely(copy_from_guest_offset(&l2sel_mfn, arg->l2sel_mfns,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+        if ( unlikely(copy_from_guest_offset(&l2sel_offset, arg->l2sel_offsets,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+
+        if ( (rc = __map_l2_selector(v, l2sel_mfn, l2sel_offset)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+    }
+
+    __evtchn_setup_bitmap_l3(d);
+
+    d->evtchn_level = EVTCHN_3_LEVEL;
+
+    rc = 0;
+
+ out:
+    return rc;
+}
+
+/*
+ * NOTE to N-level event channel users:
+ * N-level channels are likely to consume lots large global mapping
+ * area in Xen. For example, 3-level event channel consumes 16 +
+ * nr_vcpus pages global mapping area. So *ONLY* enable N-level event
+ * channel for Dom0 or driver domains.
+ */
+static long evtchn_register_nlevel(struct evtchn_register_nlevel *reg)
+{
+    struct domain *d = current->domain;
+    int rc;
+
+    spin_lock(&d->event_lock);
+
+    switch ( reg->level )
+    {
+    case EVTCHN_3_LEVEL:
+        rc = evtchn_register_3level(&reg->u.l3);
+        break;
+    default:
+        rc = -EINVAL;
+    }
+
+    spin_unlock(&d->event_lock);
+
+    return rc;
+}
+
 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
@@ -1132,6 +1387,18 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+    case EVTCHNOP_register_nlevel: {
+        struct evtchn_register_nlevel reg;
+        if ( copy_from_guest(&reg, arg, 1) != 0 )
+            return -EFAULT;
+        rc = evtchn_register_nlevel(&reg);
+
+        /* XXX always fails this call because it is not yet completed */
+        rc = -EINVAL;
+
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
@@ -1258,6 +1525,17 @@ int evtchn_init(struct domain *d)
     return 0;
 }
 
+static void evtchn_unmap_nlevel(struct domain *d)
+{
+    switch ( d->evtchn_level )
+    {
+    case EVTCHN_3_LEVEL:
+        __evtchn_unmap_all_3level(d);
+        break;
+    default:
+        break;
+    }
+}
 
 void evtchn_destroy(struct domain *d)
 {
@@ -1286,6 +1564,8 @@ void evtchn_destroy(struct domain *d)
 
     clear_global_virq_handlers(d);
 
+    evtchn_unmap_nlevel(d);
+
     free_xenheap_page(d->evtchn);
 }
 
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:38:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PzO-0000PU-Dn; Mon, 04 Feb 2013 17:37:54 +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 1U2PzN-0000PI-Ug
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 17:37:54 +0000
Received: from [193.109.254.147:50221] by server-14.bemta-14.messagelabs.com
	id 1D/3C-02031-1F1FF015; Mon, 04 Feb 2013 17:37:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1359999470!8768377!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8265 invoked from network); 4 Feb 2013 17:37:51 -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;
	4 Feb 2013 17:37:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891711"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:37:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:37:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PzJ-0001g2-MW;
	Mon, 04 Feb 2013 17:37:49 +0000
Message-ID: <1359999469.7477.56.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Mon, 4 Feb 2013 17:37:49 +0000
In-Reply-To: <510FDDFB.1040102@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<510FDDFB.1040102@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: xen devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Wei Liu <liuw@liuw.name>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-04 at 16:12 +0000, Christopher S. Aker wrote:
> On 2/1/13 8:01 PM, Wei Liu wrote:
> > Dose your Dom0 has very limited RAM?
> >
> > Just happened to fix a bug related to OOM not getting handled correctly.
> >
> > http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html
> 
> I'm not sure if it was under abnormal memory pressure.  We've tuned 
> things quite a bit to not swap thrash under worst-case conditions.  But 
> things happen.
> 
> If this is a likely culprit then we'll rebuild with this patch and we'll 
> give it a go.  Thanks!
> 

You might also need this one if you use user space event channel driver

http://lists.xen.org/archives/html/xen-devel/2013-02/msg00191.html


Wei.

> -Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 17:38:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2PzO-0000PU-Dn; Mon, 04 Feb 2013 17:37:54 +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 1U2PzN-0000PI-Ug
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 17:37:54 +0000
Received: from [193.109.254.147:50221] by server-14.bemta-14.messagelabs.com
	id 1D/3C-02031-1F1FF015; Mon, 04 Feb 2013 17:37:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1359999470!8768377!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8265 invoked from network); 4 Feb 2013 17:37:51 -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;
	4 Feb 2013 17:37:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="5891711"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:37:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 12:37:50 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2PzJ-0001g2-MW;
	Mon, 04 Feb 2013 17:37:49 +0000
Message-ID: <1359999469.7477.56.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Mon, 4 Feb 2013 17:37:49 +0000
In-Reply-To: <510FDDFB.1040102@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<510FDDFB.1040102@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: xen devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com,
	Wei Liu <liuw@liuw.name>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-04 at 16:12 +0000, Christopher S. Aker wrote:
> On 2/1/13 8:01 PM, Wei Liu wrote:
> > Dose your Dom0 has very limited RAM?
> >
> > Just happened to fix a bug related to OOM not getting handled correctly.
> >
> > http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html
> 
> I'm not sure if it was under abnormal memory pressure.  We've tuned 
> things quite a bit to not swap thrash under worst-case conditions.  But 
> things happen.
> 
> If this is a likely culprit then we'll rebuild with this patch and we'll 
> give it a go.  Thanks!
> 

You might also need this one if you use user space event channel driver

http://lists.xen.org/archives/html/xen-devel/2013-02/msg00191.html


Wei.

> -Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 17:46:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:46: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 1U2Q76-0000hs-HP; Mon, 04 Feb 2013 17:45:52 +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 1U2Q74-0000hn-V6
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:45:51 +0000
Received: from [85.158.143.99:27541] by server-3.bemta-4.messagelabs.com id
	32/19-08920-EC3FF015; Mon, 04 Feb 2013 17:45:50 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359999941!17882944!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13859 invoked from network); 4 Feb 2013 17:45:41 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-16.tower-216.messagelabs.com with SMTP;
	4 Feb 2013 17:45:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 36FA3E228C
	for <xen-devel@lists.xen.org>; Mon,  4 Feb 2013 18:44:26 +0100 (CET)
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 y-OyqHZhkJ_d for <xen-devel@lists.xen.org>;
	Mon,  4 Feb 2013 18:44:26 +0100 (CET)
Received: from [10.0.0.1] (p57946077.dip.t-dialin.net [87.148.96.119])
	by rootsrv.hfp.de (Postfix) with ESMTPA
	for <xen-devel@lists.xen.org>; Mon,  4 Feb 2013 18:44:26 +0100 (CET)
Message-ID: <510FF3C3.9070601@hfp.de>
Date: Mon, 04 Feb 2013 18:45:39 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
	compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 two design questions:

a) is there some doc on binary compatibility between dom0-kernels and 
Xen/xen-tools? For example Xen 4.2.1 on my system does not work with 
xenified OpenSuse 12.2 kernel, while it seems to work with vanilla 3.7. 
I am interested in some kind of compatibility matrix having various 
kernels (pvops0, xenified, with versions) on one axis and Xen releases 
on the other axis. Also having some info about reasons for 
breakage-by-design would be helpful.

b) is there some doc/info on what is going on with blktap[1,2,3]? I am 
specifically interested in underlying (design) questions, for example 
why blktap was not migrated to vanilla kernel 3.x?

Regards Andreas


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:46:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:46: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 1U2Q76-0000hs-HP; Mon, 04 Feb 2013 17:45:52 +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 1U2Q74-0000hn-V6
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:45:51 +0000
Received: from [85.158.143.99:27541] by server-3.bemta-4.messagelabs.com id
	32/19-08920-EC3FF015; Mon, 04 Feb 2013 17:45:50 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1359999941!17882944!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13859 invoked from network); 4 Feb 2013 17:45:41 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-16.tower-216.messagelabs.com with SMTP;
	4 Feb 2013 17:45:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 36FA3E228C
	for <xen-devel@lists.xen.org>; Mon,  4 Feb 2013 18:44:26 +0100 (CET)
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 y-OyqHZhkJ_d for <xen-devel@lists.xen.org>;
	Mon,  4 Feb 2013 18:44:26 +0100 (CET)
Received: from [10.0.0.1] (p57946077.dip.t-dialin.net [87.148.96.119])
	by rootsrv.hfp.de (Postfix) with ESMTPA
	for <xen-devel@lists.xen.org>; Mon,  4 Feb 2013 18:44:26 +0100 (CET)
Message-ID: <510FF3C3.9070601@hfp.de>
Date: Mon, 04 Feb 2013 18:45:39 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
	compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 two design questions:

a) is there some doc on binary compatibility between dom0-kernels and 
Xen/xen-tools? For example Xen 4.2.1 on my system does not work with 
xenified OpenSuse 12.2 kernel, while it seems to work with vanilla 3.7. 
I am interested in some kind of compatibility matrix having various 
kernels (pvops0, xenified, with versions) on one axis and Xen releases 
on the other axis. Also having some info about reasons for 
breakage-by-design would be helpful.

b) is there some doc/info on what is going on with blktap[1,2,3]? I am 
specifically interested in underlying (design) questions, for example 
why blktap was not migrated to vanilla kernel 3.x?

Regards Andreas


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:51:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:51: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 1U2QCE-00010V-AT; Mon, 04 Feb 2013 17:51: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 1U2QCC-000101-K7
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:51:08 +0000
Received: from [85.158.143.35:57324] by server-3.bemta-4.messagelabs.com id
	36/6D-08920-B05FF015; Mon, 04 Feb 2013 17:51:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360000210!11863930!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32205 invoked from network); 4 Feb 2013 17:50:14 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:50:14 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so3256293wic.11
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=IWrmveYmTDkbBGYMMU3/1utQ8kXUvQPhf+jYXFm+KWM=;
	b=GOcLNhnh77QPyjYK62LNmUsj/55Y2m9cbpkqxLGuCRjob/EGVmilGQMZago2Sxvmhn
	GuqxGsVuAxfeR8MnpUWKD+NEKzterRLNGGJ5K7Q6AHFO+5AOc6dJnRlihNGxL6cs8jcy
	vchPhUSeuUyyhg1zs6mwL8LmNvquCLbz5g+1WEf9cyyY/cAQFAB95WYQULjwfUlGSGLO
	61E6I3LdytXZ6WXH71VMljCOVoEB4ogLhaEaIZaHDHk6VfgyvWYPhCqXdW+b0nnUt3kC
	tI3zvEWue7I88BTrmCkzRGPGAHu+ka4cMOVsMcm5L8pDTv8YPdR2rQnk02wDg9ONRRSo
	UDBw==
X-Received: by 10.194.119.5 with SMTP id kq5mr36781416wjb.48.1360000210150;
	Mon, 04 Feb 2013 09:50:10 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id ge2sm2494012wib.4.2013.02.04.09.50.08
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 09:50:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 17:50:02 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CD35A54A.59FE4%keir@xen.org>
Thread-Topic: compat mode argument translation area
Thread-Index: Ac4DAA6XBbBj6IYIuk2DIs/W9ryVaA==
In-Reply-To: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 16:50, "Jan Beulich" <JBeulich@suse.com> wrote:

> Hi Keir,
> 
> this, originally having been at a fixed location outside of Xen virtual
> address ranges, has seen a number of changes over the years, with
> the net effect that right now we're requiring an order-1 allocation
> from the Xen heap. Obviously it would be much better if this got
> populated with order-0 allocations from the domain heap.
> 
> Considering that there's going to be one such area per vCPU (less
> those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
> seems undesirable to me to use vmap() for this purpose.
> 
> Instead I wonder whether we shouldn't go back to putting this at
> a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
> the virtual address range pressure (compared to the vmap()
> approach as well as for the case that these areas might need
> extending). Was there any other reason that you moved them out
> of such a fixed area than wanting to use mostly the same code
> for PV and HVM (which ought to be possible now that there's a
> base pointer stored for each vCPU)?

The original reason was so that we only needed to allocate memory for the
xlat_area per physical cpu.

Because of allowing sleeping in a hypercall (via a waitqueue) we can no
longer do that anyway, so we are back to allocating an xlat_area for every
vcpu. And we could as well map that at a fixed virtual address I suppose.

Do we care about vmap() pressure though? Is there a downside to making the
vmap area as big as we like? I mean even the existing 16GB area is good for
a million vcpus or so ;)

 -- Keir

> An alternative might be to use another per-domain L3 slot for this.
> 
> Jan
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:51:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:51: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 1U2QCE-00010V-AT; Mon, 04 Feb 2013 17:51: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 1U2QCC-000101-K7
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:51:08 +0000
Received: from [85.158.143.35:57324] by server-3.bemta-4.messagelabs.com id
	36/6D-08920-B05FF015; Mon, 04 Feb 2013 17:51:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360000210!11863930!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32205 invoked from network); 4 Feb 2013 17:50:14 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:50:14 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so3256293wic.11
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=IWrmveYmTDkbBGYMMU3/1utQ8kXUvQPhf+jYXFm+KWM=;
	b=GOcLNhnh77QPyjYK62LNmUsj/55Y2m9cbpkqxLGuCRjob/EGVmilGQMZago2Sxvmhn
	GuqxGsVuAxfeR8MnpUWKD+NEKzterRLNGGJ5K7Q6AHFO+5AOc6dJnRlihNGxL6cs8jcy
	vchPhUSeuUyyhg1zs6mwL8LmNvquCLbz5g+1WEf9cyyY/cAQFAB95WYQULjwfUlGSGLO
	61E6I3LdytXZ6WXH71VMljCOVoEB4ogLhaEaIZaHDHk6VfgyvWYPhCqXdW+b0nnUt3kC
	tI3zvEWue7I88BTrmCkzRGPGAHu+ka4cMOVsMcm5L8pDTv8YPdR2rQnk02wDg9ONRRSo
	UDBw==
X-Received: by 10.194.119.5 with SMTP id kq5mr36781416wjb.48.1360000210150;
	Mon, 04 Feb 2013 09:50:10 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id ge2sm2494012wib.4.2013.02.04.09.50.08
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 09:50:09 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 17:50:02 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CD35A54A.59FE4%keir@xen.org>
Thread-Topic: compat mode argument translation area
Thread-Index: Ac4DAA6XBbBj6IYIuk2DIs/W9ryVaA==
In-Reply-To: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 16:50, "Jan Beulich" <JBeulich@suse.com> wrote:

> Hi Keir,
> 
> this, originally having been at a fixed location outside of Xen virtual
> address ranges, has seen a number of changes over the years, with
> the net effect that right now we're requiring an order-1 allocation
> from the Xen heap. Obviously it would be much better if this got
> populated with order-0 allocations from the domain heap.
> 
> Considering that there's going to be one such area per vCPU (less
> those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
> seems undesirable to me to use vmap() for this purpose.
> 
> Instead I wonder whether we shouldn't go back to putting this at
> a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
> the virtual address range pressure (compared to the vmap()
> approach as well as for the case that these areas might need
> extending). Was there any other reason that you moved them out
> of such a fixed area than wanting to use mostly the same code
> for PV and HVM (which ought to be possible now that there's a
> base pointer stored for each vCPU)?

The original reason was so that we only needed to allocate memory for the
xlat_area per physical cpu.

Because of allowing sleeping in a hypercall (via a waitqueue) we can no
longer do that anyway, so we are back to allocating an xlat_area for every
vcpu. And we could as well map that at a fixed virtual address I suppose.

Do we care about vmap() pressure though? Is there a downside to making the
vmap area as big as we like? I mean even the existing 16GB area is good for
a million vcpus or so ;)

 -- Keir

> An alternative might be to use another per-domain L3 slot for this.
> 
> Jan
> 



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:52:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:52: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 1U2QDY-00018h-RJ; Mon, 04 Feb 2013 17:52:32 +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 1U2QDW-000186-Qs
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:52:31 +0000
Received: from [193.109.254.147:41539] by server-12.bemta-14.messagelabs.com
	id D1/53-32582-E55FF015; Mon, 04 Feb 2013 17:52:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360000336!8769871!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18578 invoked from network); 4 Feb 2013 17:52:19 -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;
	4 Feb 2013 17:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6199754"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:52:16 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Mon, 4 Feb 2013
	12:52:15 -0500
Message-ID: <510FF54E.1070706@citrix.com>
Date: Mon, 4 Feb 2013 17:52:14 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Here is a design for a scalable event channel ABI for Xen.  It has a
number of benefits over the design currently being proposed by Wei Lui.

* More event channels (>100,000).
* 16 event priorities.
* Reduced memory requirements (only 1 additional page per domU).
* The use of FIFOs for events ensures fairness, whereas it is difficult
to reason about the fairness with the current bitmap system.

The PDF version is easier to read and has diagrams and readable maths
but the original markdown format document is included below (for ease of
commenting).

http://xenbits.xen.org/people/dvrabel/event-channels-A.pdf

Introduction
============

Purpose
-------

Xen uses event channels to signal events (interrupts) to (fully or
partially) paravirtualized guests.  The current event channel ABI
provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
(for 64-bit guests) event channels.  This is limiting scalability as
support for more VMs, VCPUs and devices is required.

The existing ABI does not easily allow events to have different
priorities.  Current Linux kernels prioritize the timer event by
special casing this but this is not generalizable to more events.
Event priorities may be useful for prioritizing MMIO emulation
requests over bulk data traffic (such as network or disk).

This design replaces the existing event channel ABI with one that:

- is scalable to more than 100,000 event channels, with scope for
increasing this further with minimal ABI changes.

- allows guests to use up-to 16 different event priorities.

System Overview
---------------

[FIXME: diagram showing Xen and guest and shared memory block for events?]

Design Map
----------

A new event channel ABI requires changes to Xen and the guest kernels.

References
----------

[FIXME: link to alternate proposal?]

Design Considerations
=====================

Assumptions
-----------

* Atomic read-modify-write of 32-bit words is possible on all
  supported platforms.  This can be with a linked-load /
  store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
  (e.g., x86's cmpxchg).

Constraints
-----------

* The existing ABI must continue to be useable.  Compatibilty with
  existing guests is mandatory.

Risks and Volatile Areas
------------------------

* Should the 3-level proposal be merged into Xen then this design does
  not offer enough improvements to warrant the cost of maintaining
  three different event channel ABIs in Xen and guest kernels.

* The performance of some operations may be decreased.  Specifically,
  retriggering an event now always requires a hypercall.

Architecture
============

Overview
--------

The event channel ABI uses a data structure that is shared between Xen
and the guest.  Access to the structure is done with lock-less
operations (except for some less common operations where the guest
must use a hypercall).  The guest is responsible for allocating this
structure and registering it with Xen during VCPU bring-up.

Events are reported to a guest's VCPU using a FIFO queue.  There is a
queue for each priority level and each VCPU.

Each event has a _pending_ and a _masked_ bit.  The pending bit
indicates the event has been raised.  The masked bit is used by the
guest to prevent delivery of that specific event.


High Level Design
=================

Shared Event Data Structure
---------------------------

The shared event data structure has a per-domain _event array_, and a
per-VCPU _control block_.

- _event array_: A logical array of event words (one per event
  channel) which contains the pending and mask bits and the link index
  for next event in the queue.

![\label{fig_event-word}Event Array Word](event-word.pdf)

- _control block_: This contains the head and tail indexes for each
  priority level.  Each VCPU has its own control block and this is
  contained in the existing `struct vcpu_info`.

The pages within the event array need not be physically nor virtually
contiguous, but the guest or Xen may make the virtually contiguous for
ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
Linux.  Pages are added by the guest as required by the number of
bound event channels.

Only 17 bits are currently defined for the LINK field, allowing 2^17^
(131,072) events.  This limit can be trivially increased without any
other changes to the ABI.  Bits [28:17] are reserved for future
expansion or for other uses.

Event State Machine
-------------------

Event channels are bound to a domain using the existing ABI.

A bound event may be in one of three main states.

State    Abbrev.  Meaning
-----    -------  -------
BOUND    B        The event is bound but not pending.
PENDING  P        The event has been raised and not yet acknowledged.
LINKED   L        The event is on an event queue.

Additionally, events may be UNMASKED or MASKED (M).

![\label{events_sm}Event State Machine](event-sm.pdf)

The state of an event is tracked using 3 bits within the event word.
the M (masked), P (pending) and L (linked) bits.  Only state
transitions that change a single bit are valid.

Event Queues
------------

The event queues use a singly-linked list of event array words (see
figure \ref{fig_event-word} and \ref{fig_event-queue}).

![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)

Each event queue has a head and tail index stored in the control
block.  The head index is the index of the first element in the queue.
The tail index is the last element in the queue.  Every element within
the queue has the L bit set.

The LINK field in the event word indexes the next event in the queue.
LINK is zero for the last word in the queue.

The queue is empty when the head index is zero (zero is not a valid
event channel).

Hypercalls
----------

Four new EVTCHNOP hypercall sub-operations are added:

* `EVTCHNOP_init`

* `EVTCHNOP_expand`

* `EVTCHNOP_set_priority`

* `EVTCHNOP_set_limit`

### `EVTCHNOP_init`

This call initializes a single VCPU's event channel data structures,
adding one page for the event array.

A guest should call this during initial VCPU bring up (and on resume?).

    struct evtchnop_init {
        uint32_t vcpu;
        uint64_t array_pfn;
    };

Field          Purpose
-----          -------
`vcpu`         [in] The VCPU number.
`array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
               of the event array.

Error code  Reason
----------  ------
EINVAL      `vcpu` is invalid or already initialized.
EINVAL      `array_pfn` is not a valid frame for the domain.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_expand`

This call expands the event array for a VCPU by appended an additional
page.

A guest should call this for all VCPUs when a new event channel is
required and there is insufficient space in the current event array.

It is not possible to shrink the event array once it has been
expanded.

    struct evtchnop_expand {
        uint32_t vcpu;
        uint64_t array_pfn;
    };

Field          Purpose
-----          -------
`vcpu`         [in] The VCPU number.
`array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
               of the event array.

Error code  Reason
----------  ------
EINVAL      `vcpu` is invalid or already initialized.
EINVAL      `array_pfn` is not a valid frames for the domain.
EINVAL      The event array already has the maximum number of pages.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_set_priority`

This call sets the priority for an event channel.  The event must be
unbound.

A guest may call this prior to binding an event channel. The meaning
and the use of the priority are up to the guest.  Valid priorities are
0 - 15 and the default is 7.

    struct evtchnop_set_priority {
        uint32_t port;
        uint32_t priority;
    };

Field       Purpose
-----       -------
`port`      [in] The event channel.
`priority`  [in] The priority for the event channel.

Error code  Reason
----------  ------
EINVAL      `port` is invalid.
EINVAL      `port` is currently bound.
EINVAL      `priority` is outside the range 0 - 15.

### `EVTCHNOP_set_limit`

This privileged call sets the maximum number of event channels a
domain can bind.  The default for dom0 is unlimited.  Other domains
default to 1024 events (requiring only a single page for their event
array).

    struct evtchnop_set_limit {
        uint32_t domid;
        uint32_t max_events;
    };

Field         Purpose
-----         -------
`domid`       [in] The domain ID.
`max_events`  [in] The maximum number of event channels that may be bound
              to the domain.

Error code  Reason
----------  ------
EINVAL      `domid` is invalid.
EPERM       The calling domain has insufficient privileges.

Memory Usage
------------

### Event Arrays

Xen needs to map every domains' event array into its address space.
The space reserved for these global mappings is limited to 1 GiB on
x86-64 (262144 pages) and is shared with other users.

It is non-trivial to calculate the maximum number of VMs that can be
supported as this depends on the system configuration (how many driver
domains etc.) and VM configuration.  We can make some assuptions and
derive an approximate limit.

Each page of the event array has space for 1024 events ($E_P$) so a
regular domU will only require a single page.  Since event channels
typically come in pairs, the upper bound on the total number of pages
is $2 \times\text{number of VMs}$.

If the guests are further restricted in the number of event channels
($E_V$) then this upper bound can be reduced further.

The number of VMs ($V$) with a limit of $P$ total event array pages is:
\begin{equation*}
V = P \div \left(1 + \frac{E_V}{E_P}\right)
\end{equation*}

Using only half the available pages and limiting guests to only 64
events gives:
\begin{eqnarray*}
V & = & (262144 / 2) \div (1 + 64 / 1024) \\
  & = & 123 \times 10^3\text{ VMs}
\end{eqnarray*}

Alternatively, we can consider a system with $D$ driver domains, each
of which requires $E_D$ events, and a dom0 using the maximum number of
pages (128).

\begin{eqnarray*}
V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
\end{eqnarray*}

With, for example, 16 driver domains each using the maximum number of pages:
\begin{eqnarray*}
V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
   & = & 129 \times 10^3\text{ VMs}
\end{eqnarray*}

In summary, there is space to map the event arrays for over 100,000
VMs.  This is more than the limit imposed by the 16 bit domain ID
(~32,000 VMs).

### Control Block

With $L$ priority levels and two 32-bit words for the head and tail
indexes, the amount of space ($S$) required in the `struct vcpu_info`
for the control block is:
\begin{eqnarray*}
S & = & L \times 2 \times 4 \\
  & = & 16 \times 2 \times 4 \\
  & = & 128\text{ bytes}
\end{eqnarray*}

There is more than enough space within `struct vcpu_info` for the
control block while still keeping plenty of space for future use.

Low Level Design
================

In the pseudo code in this section, all memory accesses are atomic,
including those to bit-fields within the event word.

These variables have a standard meaning:

Variable  Purpose
--------  -------
E         Event array.
p         A specific event.
H         The head index for a specific priority.
T         The tail index for a specific priority.

These memory barriers are required:

Function  Purpose
--------  -------
mb()      Full (read/write) memory barrier

Raising an Event
----------------

When Xen raises an event it marks it pending and (if it is not masked)
adds it tail of event queue.

    E[p].pending = 1
    if not E[p].linked and not E[n].masked
        E[p].linked = 1
        E[p].link = 0
        mb()
        if H == 0
            H = p
        else
            E[T].link = p
        T = p

Concurrent access by Xen to the event queue must be protected by a
per-event queue spin lock.

Consuming Events
----------------

The guests consumes events starting at the head until it reaches the
tail.  Events in the queue that are not pending or are masked are
consumed but not handled.

    while H != 0
        p = H
        H = E[p].link
        if H == 0
            mb()
            H = E[p].link
        E[H].linked = 0
        if not E[p].masked
            handle(p)

handle() clears `E[p].pending` and EOIs level-triggered PIRQs.

> Note: When the event queue contains a single event, removing the
> event may race with Xen appending another event because the load of
> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> the guest must recheck `E[p].link` if the list appeared empty.

Masking Events
--------------

Events are masked by setting the masked bit.  If the event is pending
and linked it does not need to be unlinked.

    E[p].masked = 1

Unmasking Events
----------------

Events are unmasked by the guest by clearing the masked bit.  If the
event is pending the guest must call the event channel unmask
hypercall so Xen can link the event into the correct event queue.

    E[p].masked = 0
    if E[p].pending
        hypercall(EVTCHN_unmask)

The expectation here is that unmasking a pending event will be rare,
so the performance hit of the hypercall is minimal.

> Note: that after clearing the mask bit, the event may be raised and
> thus it may already be linked by the time the hypercall is done.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:52:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17:52: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 1U2QDY-00018h-RJ; Mon, 04 Feb 2013 17:52:32 +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 1U2QDW-000186-Qs
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:52:31 +0000
Received: from [193.109.254.147:41539] by server-12.bemta-14.messagelabs.com
	id D1/53-32582-E55FF015; Mon, 04 Feb 2013 17:52:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360000336!8769871!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18578 invoked from network); 4 Feb 2013 17:52:19 -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;
	4 Feb 2013 17:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; 
   d="scan'208";a="6199754"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 17:52:16 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Mon, 4 Feb 2013
	12:52:15 -0500
Message-ID: <510FF54E.1070706@citrix.com>
Date: Mon, 4 Feb 2013 17:52:14 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Here is a design for a scalable event channel ABI for Xen.  It has a
number of benefits over the design currently being proposed by Wei Lui.

* More event channels (>100,000).
* 16 event priorities.
* Reduced memory requirements (only 1 additional page per domU).
* The use of FIFOs for events ensures fairness, whereas it is difficult
to reason about the fairness with the current bitmap system.

The PDF version is easier to read and has diagrams and readable maths
but the original markdown format document is included below (for ease of
commenting).

http://xenbits.xen.org/people/dvrabel/event-channels-A.pdf

Introduction
============

Purpose
-------

Xen uses event channels to signal events (interrupts) to (fully or
partially) paravirtualized guests.  The current event channel ABI
provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
(for 64-bit guests) event channels.  This is limiting scalability as
support for more VMs, VCPUs and devices is required.

The existing ABI does not easily allow events to have different
priorities.  Current Linux kernels prioritize the timer event by
special casing this but this is not generalizable to more events.
Event priorities may be useful for prioritizing MMIO emulation
requests over bulk data traffic (such as network or disk).

This design replaces the existing event channel ABI with one that:

- is scalable to more than 100,000 event channels, with scope for
increasing this further with minimal ABI changes.

- allows guests to use up-to 16 different event priorities.

System Overview
---------------

[FIXME: diagram showing Xen and guest and shared memory block for events?]

Design Map
----------

A new event channel ABI requires changes to Xen and the guest kernels.

References
----------

[FIXME: link to alternate proposal?]

Design Considerations
=====================

Assumptions
-----------

* Atomic read-modify-write of 32-bit words is possible on all
  supported platforms.  This can be with a linked-load /
  store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
  (e.g., x86's cmpxchg).

Constraints
-----------

* The existing ABI must continue to be useable.  Compatibilty with
  existing guests is mandatory.

Risks and Volatile Areas
------------------------

* Should the 3-level proposal be merged into Xen then this design does
  not offer enough improvements to warrant the cost of maintaining
  three different event channel ABIs in Xen and guest kernels.

* The performance of some operations may be decreased.  Specifically,
  retriggering an event now always requires a hypercall.

Architecture
============

Overview
--------

The event channel ABI uses a data structure that is shared between Xen
and the guest.  Access to the structure is done with lock-less
operations (except for some less common operations where the guest
must use a hypercall).  The guest is responsible for allocating this
structure and registering it with Xen during VCPU bring-up.

Events are reported to a guest's VCPU using a FIFO queue.  There is a
queue for each priority level and each VCPU.

Each event has a _pending_ and a _masked_ bit.  The pending bit
indicates the event has been raised.  The masked bit is used by the
guest to prevent delivery of that specific event.


High Level Design
=================

Shared Event Data Structure
---------------------------

The shared event data structure has a per-domain _event array_, and a
per-VCPU _control block_.

- _event array_: A logical array of event words (one per event
  channel) which contains the pending and mask bits and the link index
  for next event in the queue.

![\label{fig_event-word}Event Array Word](event-word.pdf)

- _control block_: This contains the head and tail indexes for each
  priority level.  Each VCPU has its own control block and this is
  contained in the existing `struct vcpu_info`.

The pages within the event array need not be physically nor virtually
contiguous, but the guest or Xen may make the virtually contiguous for
ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
Linux.  Pages are added by the guest as required by the number of
bound event channels.

Only 17 bits are currently defined for the LINK field, allowing 2^17^
(131,072) events.  This limit can be trivially increased without any
other changes to the ABI.  Bits [28:17] are reserved for future
expansion or for other uses.

Event State Machine
-------------------

Event channels are bound to a domain using the existing ABI.

A bound event may be in one of three main states.

State    Abbrev.  Meaning
-----    -------  -------
BOUND    B        The event is bound but not pending.
PENDING  P        The event has been raised and not yet acknowledged.
LINKED   L        The event is on an event queue.

Additionally, events may be UNMASKED or MASKED (M).

![\label{events_sm}Event State Machine](event-sm.pdf)

The state of an event is tracked using 3 bits within the event word.
the M (masked), P (pending) and L (linked) bits.  Only state
transitions that change a single bit are valid.

Event Queues
------------

The event queues use a singly-linked list of event array words (see
figure \ref{fig_event-word} and \ref{fig_event-queue}).

![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)

Each event queue has a head and tail index stored in the control
block.  The head index is the index of the first element in the queue.
The tail index is the last element in the queue.  Every element within
the queue has the L bit set.

The LINK field in the event word indexes the next event in the queue.
LINK is zero for the last word in the queue.

The queue is empty when the head index is zero (zero is not a valid
event channel).

Hypercalls
----------

Four new EVTCHNOP hypercall sub-operations are added:

* `EVTCHNOP_init`

* `EVTCHNOP_expand`

* `EVTCHNOP_set_priority`

* `EVTCHNOP_set_limit`

### `EVTCHNOP_init`

This call initializes a single VCPU's event channel data structures,
adding one page for the event array.

A guest should call this during initial VCPU bring up (and on resume?).

    struct evtchnop_init {
        uint32_t vcpu;
        uint64_t array_pfn;
    };

Field          Purpose
-----          -------
`vcpu`         [in] The VCPU number.
`array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
               of the event array.

Error code  Reason
----------  ------
EINVAL      `vcpu` is invalid or already initialized.
EINVAL      `array_pfn` is not a valid frame for the domain.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_expand`

This call expands the event array for a VCPU by appended an additional
page.

A guest should call this for all VCPUs when a new event channel is
required and there is insufficient space in the current event array.

It is not possible to shrink the event array once it has been
expanded.

    struct evtchnop_expand {
        uint32_t vcpu;
        uint64_t array_pfn;
    };

Field          Purpose
-----          -------
`vcpu`         [in] The VCPU number.
`array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
               of the event array.

Error code  Reason
----------  ------
EINVAL      `vcpu` is invalid or already initialized.
EINVAL      `array_pfn` is not a valid frames for the domain.
EINVAL      The event array already has the maximum number of pages.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_set_priority`

This call sets the priority for an event channel.  The event must be
unbound.

A guest may call this prior to binding an event channel. The meaning
and the use of the priority are up to the guest.  Valid priorities are
0 - 15 and the default is 7.

    struct evtchnop_set_priority {
        uint32_t port;
        uint32_t priority;
    };

Field       Purpose
-----       -------
`port`      [in] The event channel.
`priority`  [in] The priority for the event channel.

Error code  Reason
----------  ------
EINVAL      `port` is invalid.
EINVAL      `port` is currently bound.
EINVAL      `priority` is outside the range 0 - 15.

### `EVTCHNOP_set_limit`

This privileged call sets the maximum number of event channels a
domain can bind.  The default for dom0 is unlimited.  Other domains
default to 1024 events (requiring only a single page for their event
array).

    struct evtchnop_set_limit {
        uint32_t domid;
        uint32_t max_events;
    };

Field         Purpose
-----         -------
`domid`       [in] The domain ID.
`max_events`  [in] The maximum number of event channels that may be bound
              to the domain.

Error code  Reason
----------  ------
EINVAL      `domid` is invalid.
EPERM       The calling domain has insufficient privileges.

Memory Usage
------------

### Event Arrays

Xen needs to map every domains' event array into its address space.
The space reserved for these global mappings is limited to 1 GiB on
x86-64 (262144 pages) and is shared with other users.

It is non-trivial to calculate the maximum number of VMs that can be
supported as this depends on the system configuration (how many driver
domains etc.) and VM configuration.  We can make some assuptions and
derive an approximate limit.

Each page of the event array has space for 1024 events ($E_P$) so a
regular domU will only require a single page.  Since event channels
typically come in pairs, the upper bound on the total number of pages
is $2 \times\text{number of VMs}$.

If the guests are further restricted in the number of event channels
($E_V$) then this upper bound can be reduced further.

The number of VMs ($V$) with a limit of $P$ total event array pages is:
\begin{equation*}
V = P \div \left(1 + \frac{E_V}{E_P}\right)
\end{equation*}

Using only half the available pages and limiting guests to only 64
events gives:
\begin{eqnarray*}
V & = & (262144 / 2) \div (1 + 64 / 1024) \\
  & = & 123 \times 10^3\text{ VMs}
\end{eqnarray*}

Alternatively, we can consider a system with $D$ driver domains, each
of which requires $E_D$ events, and a dom0 using the maximum number of
pages (128).

\begin{eqnarray*}
V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
\end{eqnarray*}

With, for example, 16 driver domains each using the maximum number of pages:
\begin{eqnarray*}
V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
   & = & 129 \times 10^3\text{ VMs}
\end{eqnarray*}

In summary, there is space to map the event arrays for over 100,000
VMs.  This is more than the limit imposed by the 16 bit domain ID
(~32,000 VMs).

### Control Block

With $L$ priority levels and two 32-bit words for the head and tail
indexes, the amount of space ($S$) required in the `struct vcpu_info`
for the control block is:
\begin{eqnarray*}
S & = & L \times 2 \times 4 \\
  & = & 16 \times 2 \times 4 \\
  & = & 128\text{ bytes}
\end{eqnarray*}

There is more than enough space within `struct vcpu_info` for the
control block while still keeping plenty of space for future use.

Low Level Design
================

In the pseudo code in this section, all memory accesses are atomic,
including those to bit-fields within the event word.

These variables have a standard meaning:

Variable  Purpose
--------  -------
E         Event array.
p         A specific event.
H         The head index for a specific priority.
T         The tail index for a specific priority.

These memory barriers are required:

Function  Purpose
--------  -------
mb()      Full (read/write) memory barrier

Raising an Event
----------------

When Xen raises an event it marks it pending and (if it is not masked)
adds it tail of event queue.

    E[p].pending = 1
    if not E[p].linked and not E[n].masked
        E[p].linked = 1
        E[p].link = 0
        mb()
        if H == 0
            H = p
        else
            E[T].link = p
        T = p

Concurrent access by Xen to the event queue must be protected by a
per-event queue spin lock.

Consuming Events
----------------

The guests consumes events starting at the head until it reaches the
tail.  Events in the queue that are not pending or are masked are
consumed but not handled.

    while H != 0
        p = H
        H = E[p].link
        if H == 0
            mb()
            H = E[p].link
        E[H].linked = 0
        if not E[p].masked
            handle(p)

handle() clears `E[p].pending` and EOIs level-triggered PIRQs.

> Note: When the event queue contains a single event, removing the
> event may race with Xen appending another event because the load of
> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> the guest must recheck `E[p].link` if the list appeared empty.

Masking Events
--------------

Events are masked by setting the masked bit.  If the event is pending
and linked it does not need to be unlinked.

    E[p].masked = 1

Unmasking Events
----------------

Events are unmasked by the guest by clearing the masked bit.  If the
event is pending the guest must call the event channel unmask
hypercall so Xen can link the event into the correct event queue.

    E[p].masked = 0
    if E[p].pending
        hypercall(EVTCHN_unmask)

The expectation here is that unmasking a pending event will be rare,
so the performance hit of the hypercall is minimal.

> Note: that after clearing the mask bit, the event may be raised and
> thus it may already be linked by the time the hypercall is done.

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:56:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2QH1-0001SC-M9; Mon, 04 Feb 2013 17:56:07 +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 1U2QH0-0001S7-8q
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:56:06 +0000
Received: from [85.158.138.51:61552] by server-14.bemta-3.messagelabs.com id
	CE/3F-23533-536FF015; Mon, 04 Feb 2013 17:56:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360000564!20700871!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9793 invoked from network); 4 Feb 2013 17:56:04 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:56:04 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so4547409wib.3
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:56:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=pI7r2a7XmeT/bXhRte4ubxSbW2j1cebKtEbhUlBELO4=;
	b=WROaBhqYDWD4bSja1pnksSALe+fu9pLaDQx9h6B43T58hcIgu1gHUrZWsoaglR/w7J
	OP0IiPOKOad8pywSZlhzqL9F/8lS9ugz6o5hGJOqfLJ8ACVYseeUcHbz67C8/4NfkZ+Z
	+DigozedqRJ+zUBXV0J18cYXC9CuVt8X3r+WnHN2X4oT46pD+hFPIfIl5DrRV3fjwK68
	MaXp/IgUaxtx9eebAAt4CqBEPO58nl3OEn8z7Nj8r4yatjG7vBpvhfQiltrtxiTBwTbd
	TOjnEpHCFJ1pBjxUC59hHr/t2XUmXye3r75N/+AkjRFX9D6Ql+Gcs7H36IfEC1IcWL9t
	tgUQ==
X-Received: by 10.180.94.234 with SMTP id df10mr12130521wib.17.1360000564038; 
	Mon, 04 Feb 2013 09:56:04 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id e12sm23043831wiw.5.2013.02.04.09.56.01
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 09:56:02 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 17:55:57 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CD35A6AD.5A00C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
	rather than reboot
Thread-Index: Ac4DAOIvkGbQJYbAY0esUj2kC3tlfQ==
In-Reply-To: <510FEBF5.1060708@citrix.com>
Mime-version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 17:12, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>> An alternative would be to do that, *and* still have the new HVM_PARAM, so
>> that any SHUTDOWN_* code can be generated by a triple fault (including new
>> SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
>> default behaviour is still unchanged.
>> 
>> Or, in any case, I'm not dead against the existing patch, it just seems less
>> flexible than it could be. But maybe that flexibility is pointless.
>> 
>>  -- Keir
> 
> I considered this approach originally, but decided against it.
> 
> SHUTDOWN_triple_fault would be meaningless as a standard SCHOP_shutdown
> parameter, and having the toolstack differentiate between _crash and
> _triple_fault seems pointless.

How about letting the HVM_PARAM accept any SHUTDOWN_ code? Rather than being
a boolean? That's a trivial change, just seems a bit cleaner than a boolean
to me.

Also adding the SHUTDOWN_triple_fault seemed like a maybe-nice-to-have. I
don't really care that much, and indeed it probably is pointless.

> I thought that the ideal end result would be specifying
> 
> on_triple_fault="reboot"|"crash"
> 
> In the vm.cfg file
> 
> The on_{crash,reboot} actions would still then take effect as usual.
> 
> Having said that, if _triple_fault is preferred, I am not overly
> attached to this specific implementation.

No let's drop the idea of a SHUTDOWN_triple_fault. :)

> If it isn't obvious, the motivation behind this patch is because I am
> currently chasing a windows triple fault on Xen-4.2.  It appears machine
> specific, but related to our PV driver, and takes a long time to
> reproduce.  Having automated tests fail soon with a triple fault is
> better than having the domain in question sit in a reboot loop until the
> hour long timeout kicks in.

Yep, agreed, a patch along these lines of some sort is a very good idea!

 -- Keir



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 17:56:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 17: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 1U2QH1-0001SC-M9; Mon, 04 Feb 2013 17:56:07 +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 1U2QH0-0001S7-8q
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:56:06 +0000
Received: from [85.158.138.51:61552] by server-14.bemta-3.messagelabs.com id
	CE/3F-23533-536FF015; Mon, 04 Feb 2013 17:56:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360000564!20700871!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9793 invoked from network); 4 Feb 2013 17:56:04 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:56:04 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so4547409wib.3
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:56:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=pI7r2a7XmeT/bXhRte4ubxSbW2j1cebKtEbhUlBELO4=;
	b=WROaBhqYDWD4bSja1pnksSALe+fu9pLaDQx9h6B43T58hcIgu1gHUrZWsoaglR/w7J
	OP0IiPOKOad8pywSZlhzqL9F/8lS9ugz6o5hGJOqfLJ8ACVYseeUcHbz67C8/4NfkZ+Z
	+DigozedqRJ+zUBXV0J18cYXC9CuVt8X3r+WnHN2X4oT46pD+hFPIfIl5DrRV3fjwK68
	MaXp/IgUaxtx9eebAAt4CqBEPO58nl3OEn8z7Nj8r4yatjG7vBpvhfQiltrtxiTBwTbd
	TOjnEpHCFJ1pBjxUC59hHr/t2XUmXye3r75N/+AkjRFX9D6Ql+Gcs7H36IfEC1IcWL9t
	tgUQ==
X-Received: by 10.180.94.234 with SMTP id df10mr12130521wib.17.1360000564038; 
	Mon, 04 Feb 2013 09:56:04 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id e12sm23043831wiw.5.2013.02.04.09.56.01
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 09:56:02 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 17:55:57 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CD35A6AD.5A00C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
	rather than reboot
Thread-Index: Ac4DAOIvkGbQJYbAY0esUj2kC3tlfQ==
In-Reply-To: <510FEBF5.1060708@citrix.com>
Mime-version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 17:12, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>> An alternative would be to do that, *and* still have the new HVM_PARAM, so
>> that any SHUTDOWN_* code can be generated by a triple fault (including new
>> SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
>> default behaviour is still unchanged.
>> 
>> Or, in any case, I'm not dead against the existing patch, it just seems less
>> flexible than it could be. But maybe that flexibility is pointless.
>> 
>>  -- Keir
> 
> I considered this approach originally, but decided against it.
> 
> SHUTDOWN_triple_fault would be meaningless as a standard SCHOP_shutdown
> parameter, and having the toolstack differentiate between _crash and
> _triple_fault seems pointless.

How about letting the HVM_PARAM accept any SHUTDOWN_ code? Rather than being
a boolean? That's a trivial change, just seems a bit cleaner than a boolean
to me.

Also adding the SHUTDOWN_triple_fault seemed like a maybe-nice-to-have. I
don't really care that much, and indeed it probably is pointless.

> I thought that the ideal end result would be specifying
> 
> on_triple_fault="reboot"|"crash"
> 
> In the vm.cfg file
> 
> The on_{crash,reboot} actions would still then take effect as usual.
> 
> Having said that, if _triple_fault is preferred, I am not overly
> attached to this specific implementation.

No let's drop the idea of a SHUTDOWN_triple_fault. :)

> If it isn't obvious, the motivation behind this patch is because I am
> currently chasing a windows triple fault on Xen-4.2.  It appears machine
> specific, but related to our PV driver, and takes a long time to
> reproduce.  Having automated tests fail soon with a triple fault is
> better than having the domain in question sit in a reboot loop until the
> hour long timeout kicks in.

Yep, agreed, a patch along these lines of some sort is a very good idea!

 -- Keir



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:05:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18: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 1U2QPo-00021q-Qp; Mon, 04 Feb 2013 18:05:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fernando@supergg.com.br>) id 1U2PuT-0007YC-Vc
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:50 +0000
Received: from [85.158.139.83:43603] by server-2.bemta-5.messagelabs.com id
	80/5B-16911-1C0FF015; Mon, 04 Feb 2013 17:32:49 +0000
X-Env-Sender: fernando@supergg.com.br
X-Msg-Ref: server-9.tower-182.messagelabs.com!1359999167!27704988!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10069 invoked from network); 4 Feb 2013 17:32:48 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:32:48 -0000
Received: by mail-la0-f45.google.com with SMTP id er20so4785932lab.4
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:32:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:x-originating-ip:date:message-id:subject
	:from:to:content-type:x-gm-message-state;
	bh=Yc/As91Y0EdqkVvZYn3LbkJf8A67DcZwfIeKtVLzl8I=;
	b=b06aggpmpneMfnvW9Z4PwoT1EgyF+Jg0+V02CQ2Rf6X+otAgzyn4pXUWcrzKNR2vXY
	Jh77FQoUwO5lffgA9AB/T4BSVKH2nXP8/KRGKOeSetJLgUCHPaFovjbwi3Ov4KarBjeC
	+DW0Y9HnNdl9hxxyCTh549WtCKg/BqWvF84kIuAjju4RaPdCD04YROV9dFfwCgGGJBwm
	MZ9Me32j2GaucK4DAh1D8M3iCZ0bSxpHccExBlZ7Kwd5MdsKggmQdFoaXIXj7jbCwBqC
	lf/4iZ2uByfUyp9SbItvOqoAmEtWy7lKtmta5vGg8CbYx98nlLw6nZInZ6Y+4t7vFbZU
	Pn5A==
MIME-Version: 1.0
X-Received: by 10.112.101.130 with SMTP id fg2mr8543111lbb.64.1359999167061;
	Mon, 04 Feb 2013 09:32:47 -0800 (PST)
Received: by 10.112.129.99 with HTTP; Mon, 4 Feb 2013 09:32:46 -0800 (PST)
X-Originating-IP: [177.19.124.119]
Date: Mon, 4 Feb 2013 14:32:46 -0300
Message-ID: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
From: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQmLLRYCG4nJP+TFvYurWs8yWDRNZMA0s3J3ZSKXjBiAjgwtTctD/9L5u+lIO0gfpeyClsdl
X-Mailman-Approved-At: Mon, 04 Feb 2013 18:05:11 +0000
Subject: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QCOW2 disk image gets corrupted when you try to install Service Pack 1
AFTER installing GPLPV drivers.

This means, without the pv drivers, everything works fine.

I tested both RAW and QCOW2 without GPLPV drivers and the installation
has completed without any error, and the image (at least qcow2) has no
errors too.

How to reproduce:
- Install Windows 7 32-bit guest
- Check the image with "qemu-img check -f qcow2 -r all" to ensure that
there still no problems.
- Install GPLPV drivers 0.11.0.356
- Try to install Service Pack 1
- Get an "unknown error" from the installer
- Check the qcow2 image with "qemu-img check -f qcow2 -r all" and gets
TONS of integrity errors.

guest config:

name = "win7"
builder = "hvm"
vcpus = 1
memory = 1536
acpi = 1
apic = 1
hap =  0
viridian = 1
localtime = 1
stdvga = 0
sdl = 0
vnc = 1
vncconsole = 1
vnclisten =  "0.0.0.0"
vncdisplay = 2
usbdevice = "tablet"
keymap = "pt-br"
disk = [ 'tap2:aio:../ISO/WIN7_AIO_X86_X64.iso,hdb:cdrom,r' ,
'tap2:qcow2:./win7.qcow2,hda,w' ]
boot = "dc"
vif = [ 'mac=00:16:3E:31:C4:D5,bridge=xenbr0' ]
on_crash =  "restart"
on_reboot =  "restart"
on_poweroff = "destroy"

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:05:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18: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 1U2QPo-00021q-Qp; Mon, 04 Feb 2013 18:05:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fernando@supergg.com.br>) id 1U2PuT-0007YC-Vc
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 17:32:50 +0000
Received: from [85.158.139.83:43603] by server-2.bemta-5.messagelabs.com id
	80/5B-16911-1C0FF015; Mon, 04 Feb 2013 17:32:49 +0000
X-Env-Sender: fernando@supergg.com.br
X-Msg-Ref: server-9.tower-182.messagelabs.com!1359999167!27704988!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10069 invoked from network); 4 Feb 2013 17:32:48 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 17:32:48 -0000
Received: by mail-la0-f45.google.com with SMTP id er20so4785932lab.4
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 09:32:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:x-originating-ip:date:message-id:subject
	:from:to:content-type:x-gm-message-state;
	bh=Yc/As91Y0EdqkVvZYn3LbkJf8A67DcZwfIeKtVLzl8I=;
	b=b06aggpmpneMfnvW9Z4PwoT1EgyF+Jg0+V02CQ2Rf6X+otAgzyn4pXUWcrzKNR2vXY
	Jh77FQoUwO5lffgA9AB/T4BSVKH2nXP8/KRGKOeSetJLgUCHPaFovjbwi3Ov4KarBjeC
	+DW0Y9HnNdl9hxxyCTh549WtCKg/BqWvF84kIuAjju4RaPdCD04YROV9dFfwCgGGJBwm
	MZ9Me32j2GaucK4DAh1D8M3iCZ0bSxpHccExBlZ7Kwd5MdsKggmQdFoaXIXj7jbCwBqC
	lf/4iZ2uByfUyp9SbItvOqoAmEtWy7lKtmta5vGg8CbYx98nlLw6nZInZ6Y+4t7vFbZU
	Pn5A==
MIME-Version: 1.0
X-Received: by 10.112.101.130 with SMTP id fg2mr8543111lbb.64.1359999167061;
	Mon, 04 Feb 2013 09:32:47 -0800 (PST)
Received: by 10.112.129.99 with HTTP; Mon, 4 Feb 2013 09:32:46 -0800 (PST)
X-Originating-IP: [177.19.124.119]
Date: Mon, 4 Feb 2013 14:32:46 -0300
Message-ID: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
From: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQmLLRYCG4nJP+TFvYurWs8yWDRNZMA0s3J3ZSKXjBiAjgwtTctD/9L5u+lIO0gfpeyClsdl
X-Mailman-Approved-At: Mon, 04 Feb 2013 18:05:11 +0000
Subject: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QCOW2 disk image gets corrupted when you try to install Service Pack 1
AFTER installing GPLPV drivers.

This means, without the pv drivers, everything works fine.

I tested both RAW and QCOW2 without GPLPV drivers and the installation
has completed without any error, and the image (at least qcow2) has no
errors too.

How to reproduce:
- Install Windows 7 32-bit guest
- Check the image with "qemu-img check -f qcow2 -r all" to ensure that
there still no problems.
- Install GPLPV drivers 0.11.0.356
- Try to install Service Pack 1
- Get an "unknown error" from the installer
- Check the qcow2 image with "qemu-img check -f qcow2 -r all" and gets
TONS of integrity errors.

guest config:

name = "win7"
builder = "hvm"
vcpus = 1
memory = 1536
acpi = 1
apic = 1
hap =  0
viridian = 1
localtime = 1
stdvga = 0
sdl = 0
vnc = 1
vncconsole = 1
vnclisten =  "0.0.0.0"
vncdisplay = 2
usbdevice = "tablet"
keymap = "pt-br"
disk = [ 'tap2:aio:../ISO/WIN7_AIO_X86_X64.iso,hdb:cdrom,r' ,
'tap2:qcow2:./win7.qcow2,hda,w' ]
boot = "dc"
vif = [ 'mac=00:16:3E:31:C4:D5,bridge=xenbr0' ]
on_crash =  "restart"
on_reboot =  "restart"
on_poweroff = "destroy"

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:43:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18:43: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 1U2R0G-0002zd-Vp; Mon, 04 Feb 2013 18:42:52 +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 1U2R0F-0002zV-BG
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:42:51 +0000
Received: from [85.158.143.99:58246] by server-2.bemta-4.messagelabs.com id
	38/EC-01597-A2100115; Mon, 04 Feb 2013 18:42:50 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360003367!22586340!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24360 invoked from network); 4 Feb 2013 18:42:48 -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;
	4 Feb 2013 18:42:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6207493"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:42:46 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Mon, 4 Feb 2013 13:42:46 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:42:43 -0500
Thread-Topic: [Xen-devel] HVM firmware passthrough - helper library
Thread-Index: Ac4CwccLij0w8E1xQXKTO6CRhpC7CgARVj4A
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B7B@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BC0@FTLPMAILBOX02.citrite.net>
	<1357728271.7989.220.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
	<1359973450.5281.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359973450.5281.30.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] HVM firmware passthrough - helper library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Monday, February 04, 2013 5:24 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> 
> On Fri, 2013-02-01 at 20:26 +0000, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: Wednesday, January 09, 2013 5:45 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com; Art Napor (artnapor@yahoo.com)
> > > Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> > >
> > > On Tue, 2013-01-08 at 22:04 +0000, Ross Philipson wrote:
> > > > Attached is a tarball with a helper library for reading host ACPI
> and
> > > > SMBIOS firmware and creating firmware files that can be used with
> the
> > > > HVM firmware passthrough patches I submitted. I used it in my
> testing
> > > > of the patches and planned to use it later when we moved to a new
> Xen
> > > > version. This library was requested by a few people - I hope you
> find
> > > > it useful.
> > >
> > > Would it make sense / are you planning to integrate this into the
> Xen
> > > tree as well? I'm not sure if it fits into an existing library e.g.
> > > libxenguest if it would be a separate library.
> > >
> > > Ian.
> >
> > Following up on this. Is there any interest in integrating this into
> > xen? I don't think it belongs in xenguest because it would be used up
> > at the libxl level where the fw blobs are passed in via the xl config
> > file. It seems like it should be in some separate utilities library
> > but I can't really see where.
> 
> Maybe the best place would be in libxl itself, or perhaps better in
> libxlu?
> 
> Toolstacks are supposed to be moving towards using libxl(u) anyway and
> even in the interim linking against the library for just these functions
> is no great hardship.
> 
> Ian.

Ok, yeah. I was looking at libxlu on Friday. I just wasn't really sure
what the intended scope of that library was. But the routines in that
helper library to snarf firmware bits are pretty much utility functions.

I can try knocking something together in libxlu and submit it.

Thanks
Ross

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:43:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18:43: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 1U2R0G-0002zd-Vp; Mon, 04 Feb 2013 18:42:52 +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 1U2R0F-0002zV-BG
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:42:51 +0000
Received: from [85.158.143.99:58246] by server-2.bemta-4.messagelabs.com id
	38/EC-01597-A2100115; Mon, 04 Feb 2013 18:42:50 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360003367!22586340!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24360 invoked from network); 4 Feb 2013 18:42:48 -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;
	4 Feb 2013 18:42:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6207493"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:42:46 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Mon, 4 Feb 2013 13:42:46 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:42:43 -0500
Thread-Topic: [Xen-devel] HVM firmware passthrough - helper library
Thread-Index: Ac4CwccLij0w8E1xQXKTO6CRhpC7CgARVj4A
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B7B@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BC0@FTLPMAILBOX02.citrite.net>
	<1357728271.7989.220.camel@zakaz.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A320A939F0@FTLPMAILBOX02.citrite.net>
	<1359973450.5281.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359973450.5281.30.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] HVM firmware passthrough - helper library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Monday, February 04, 2013 5:24 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> 
> On Fri, 2013-02-01 at 20:26 +0000, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: Wednesday, January 09, 2013 5:45 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com; Art Napor (artnapor@yahoo.com)
> > > Subject: Re: [Xen-devel] HVM firmware passthrough - helper library
> > >
> > > On Tue, 2013-01-08 at 22:04 +0000, Ross Philipson wrote:
> > > > Attached is a tarball with a helper library for reading host ACPI
> and
> > > > SMBIOS firmware and creating firmware files that can be used with
> the
> > > > HVM firmware passthrough patches I submitted. I used it in my
> testing
> > > > of the patches and planned to use it later when we moved to a new
> Xen
> > > > version. This library was requested by a few people - I hope you
> find
> > > > it useful.
> > >
> > > Would it make sense / are you planning to integrate this into the
> Xen
> > > tree as well? I'm not sure if it fits into an existing library e.g.
> > > libxenguest if it would be a separate library.
> > >
> > > Ian.
> >
> > Following up on this. Is there any interest in integrating this into
> > xen? I don't think it belongs in xenguest because it would be used up
> > at the libxl level where the fw blobs are passed in via the xl config
> > file. It seems like it should be in some separate utilities library
> > but I can't really see where.
> 
> Maybe the best place would be in libxl itself, or perhaps better in
> libxlu?
> 
> Toolstacks are supposed to be moving towards using libxl(u) anyway and
> even in the interim linking against the library for just these functions
> is no great hardship.
> 
> Ian.

Ok, yeah. I was looking at libxlu on Friday. I just wasn't really sure
what the intended scope of that library was. But the routines in that
helper library to snarf firmware bits are pretty much utility functions.

I can try knocking something together in libxlu and submit it.

Thanks
Ross

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:43:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18:43: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 1U2R0v-00031s-Dr; Mon, 04 Feb 2013 18:43: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 1U2R0t-00031j-LV
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 18:43:31 +0000
Received: from [85.158.138.51:2727] by server-1.bemta-3.messagelabs.com id
	87/35-08955-25100115; Mon, 04 Feb 2013 18:43:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360003382!22082510!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22950 invoked from network); 4 Feb 2013 18:43:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 18:43:02 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo48) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R04641p14IKBd4 ;
	Mon, 4 Feb 2013 19:43:02 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 209071884C; Mon,  4 Feb 2013 19:43:02 +0100 (CET)
Date: Mon, 4 Feb 2013 19:43:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204184301.GA31487@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
	<1359986349.7743.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359986349.7743.46.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> It just occurred to me, instead of adding lots of individual arguments
> perhaps packing them into a (e.g.) libxl_save_properties and adding a
> pointer would be a nicer and more extensible (in the future) interface?

Something like this (copy&paste from hg diff)?
I did not find a way to put also libxl_asyncop_how into
libxl_save_properties, the checker complains about missing
LIBXL_EXTERNAL_CALLERS_ONLY.

Olaf

diff -r 6087ff7a1aea tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -500,18 +500,24 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);

+typedef struct {
+    uint32_t domid;
+    int fd;
+    int flags; /* LIBXL_SUSPEND_* */
+    int max_iters;
+    int max_factor;
+} libxl_save_properties;
+
 int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
-                         int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how)
-                         LIBXL_EXTERNAL_CALLERS_ONLY;
+                                  int flags, /* LIBXL_SUSPEND_* */
+                                  const libxl_asyncop_how *ao_how)
+                                  LIBXL_EXTERNAL_CALLERS_ONLY;
 #ifdef LIBXL_API_VERSION
 #if LIBXL_API_VERSION == 0x040200
 #define libxl_domain_suspend libxl_domain_suspend_0x040200
 #endif
 #else
-int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
-                         int flags, /* LIBXL_SUSPEND_* */
-                         int max_iters, int max_factor,
+int libxl_domain_suspend(libxl_ctx *ctx, const libxl_save_properties *props,
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
 #endif


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:43:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18:43: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 1U2R0v-00031s-Dr; Mon, 04 Feb 2013 18:43: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 1U2R0t-00031j-LV
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 18:43:31 +0000
Received: from [85.158.138.51:2727] by server-1.bemta-3.messagelabs.com id
	87/35-08955-25100115; Mon, 04 Feb 2013 18:43:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360003382!22082510!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzU2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22950 invoked from network); 4 Feb 2013 18:43:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Feb 2013 18:43:02 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq2M7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-071-007.pools.arcor-ip.net [84.57.71.7])
	by smtp.strato.de (joses mo48) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R04641p14IKBd4 ;
	Mon, 4 Feb 2013 19:43:02 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 209071884C; Mon,  4 Feb 2013 19:43:02 +0100 (CET)
Date: Mon, 4 Feb 2013 19:43:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204184301.GA31487@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
	<1359986349.7743.46.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359986349.7743.46.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> It just occurred to me, instead of adding lots of individual arguments
> perhaps packing them into a (e.g.) libxl_save_properties and adding a
> pointer would be a nicer and more extensible (in the future) interface?

Something like this (copy&paste from hg diff)?
I did not find a way to put also libxl_asyncop_how into
libxl_save_properties, the checker complains about missing
LIBXL_EXTERNAL_CALLERS_ONLY.

Olaf

diff -r 6087ff7a1aea tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -500,18 +500,24 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);

+typedef struct {
+    uint32_t domid;
+    int fd;
+    int flags; /* LIBXL_SUSPEND_* */
+    int max_iters;
+    int max_factor;
+} libxl_save_properties;
+
 int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
-                         int flags, /* LIBXL_SUSPEND_* */
-                         const libxl_asyncop_how *ao_how)
-                         LIBXL_EXTERNAL_CALLERS_ONLY;
+                                  int flags, /* LIBXL_SUSPEND_* */
+                                  const libxl_asyncop_how *ao_how)
+                                  LIBXL_EXTERNAL_CALLERS_ONLY;
 #ifdef LIBXL_API_VERSION
 #if LIBXL_API_VERSION == 0x040200
 #define libxl_domain_suspend libxl_domain_suspend_0x040200
 #endif
 #else
-int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
-                         int flags, /* LIBXL_SUSPEND_* */
-                         int max_iters, int max_factor,
+int libxl_domain_suspend(libxl_ctx *ctx, const libxl_save_properties *props,
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
 #endif


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18:48: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 1U2R5V-0003IY-5P; Mon, 04 Feb 2013 18:48:17 +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 1U2R5S-0003IQ-SP
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:48:15 +0000
Received: from [85.158.143.99:49803] by server-3.bemta-4.messagelabs.com id
	37/14-08920-E6200115; Mon, 04 Feb 2013 18:48:14 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360003691!24413432!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5951 invoked from network); 4 Feb 2013 18:48:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 18:48:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6208654"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:48:11 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Mon, 4 Feb 2013 13:48:11 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:48:10 -0500
Thread-Topic: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4CxGuxp44eS0IVTFyoSUztW/sdRQAQ4T/w
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B7F@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
	<1359974582.5281.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359974582.5281.44.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 v2 01/03] HVM firmware passthrough libxl
 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: Monday, February 04, 2013 5:43 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
> support
> 
> On Fri, 2013-02-01 at 20:15 +0000, Ross Philipson wrote:
> > Switch libxl to use the new xc_hvm_build() libxc API.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> > diff -r 27778b4099ba tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c   Fri Jan 25 15:04:11 2013 +0000
> > +++ b/tools/libxl/libxl_dom.c   Fri Jan 25 13:37:55 2013 -0500
> > @@ -542,17 +542,24 @@ int libxl__build_hvm(libxl__gc *gc, uint
> >                libxl__domain_build_state *state)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> > +    struct xc_hvm_build_args args = {};
> >      int ret, rc = ERROR_FAIL;
> >      const char *firmware = libxl__domain_firmware(gc, info);
> >
> >      if (!firmware)
> >          goto out;
> > -    ret = xc_hvm_build_target_mem(
> > -        ctx->xch,
> > -        domid,
> > -        (info->max_memkb - info->video_memkb) / 1024,
> > -        (info->target_memkb - info->video_memkb) / 1024,
> > -        firmware);
> > +
> > +    memset(&args, 0, sizeof(struct xc_hvm_build_args));
> > +    /* The memory size names are misleading. The params are in Mb
> then
> > +     * multiplied by 1 Kb.
> 
> What's misleading about max_memkb? It contains kb doesn't it? Likewise
> the others.

I guess it was just confusing when I first looked at it because it got
changed in 3 spots by the time it was passed to libxc. It is not
confusing now - we could just ditch the comment.

> 
> The actual code in this patch looks good to me. Assuming I've remembered
> the precedence of cast vs << correctly.
> 
> >  This was then divided off when calling
> > +     * the old xc_hvm_build_target_mem() which then turned them to
> bytes.
> > +     * Do all this in one step here...
> > +     */
> > +    args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb)
> << 10;
> > +    args.mem_target = (uint64_t)(info->target_memkb - info-
> >video_memkb) << 10;
> > +    args.image_file_name = firmware;
> > +
> > +    ret = xc_hvm_build(ctx->xch, domid, &args);
> >      if (ret) {
> >          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building
> failed");
> >          goto out;

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18:48: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 1U2R5V-0003IY-5P; Mon, 04 Feb 2013 18:48:17 +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 1U2R5S-0003IQ-SP
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:48:15 +0000
Received: from [85.158.143.99:49803] by server-3.bemta-4.messagelabs.com id
	37/14-08920-E6200115; Mon, 04 Feb 2013 18:48:14 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360003691!24413432!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5951 invoked from network); 4 Feb 2013 18:48:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 18:48:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6208654"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:48:11 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Mon, 4 Feb 2013 13:48:11 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:48:10 -0500
Thread-Topic: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4CxGuxp44eS0IVTFyoSUztW/sdRQAQ4T/w
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B7F@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
	<1359974582.5281.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359974582.5281.44.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 v2 01/03] HVM firmware passthrough libxl
 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: Monday, February 04, 2013 5:43 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
> support
> 
> On Fri, 2013-02-01 at 20:15 +0000, Ross Philipson wrote:
> > Switch libxl to use the new xc_hvm_build() libxc API.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> > diff -r 27778b4099ba tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c   Fri Jan 25 15:04:11 2013 +0000
> > +++ b/tools/libxl/libxl_dom.c   Fri Jan 25 13:37:55 2013 -0500
> > @@ -542,17 +542,24 @@ int libxl__build_hvm(libxl__gc *gc, uint
> >                libxl__domain_build_state *state)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> > +    struct xc_hvm_build_args args = {};
> >      int ret, rc = ERROR_FAIL;
> >      const char *firmware = libxl__domain_firmware(gc, info);
> >
> >      if (!firmware)
> >          goto out;
> > -    ret = xc_hvm_build_target_mem(
> > -        ctx->xch,
> > -        domid,
> > -        (info->max_memkb - info->video_memkb) / 1024,
> > -        (info->target_memkb - info->video_memkb) / 1024,
> > -        firmware);
> > +
> > +    memset(&args, 0, sizeof(struct xc_hvm_build_args));
> > +    /* The memory size names are misleading. The params are in Mb
> then
> > +     * multiplied by 1 Kb.
> 
> What's misleading about max_memkb? It contains kb doesn't it? Likewise
> the others.

I guess it was just confusing when I first looked at it because it got
changed in 3 spots by the time it was passed to libxc. It is not
confusing now - we could just ditch the comment.

> 
> The actual code in this patch looks good to me. Assuming I've remembered
> the precedence of cast vs << correctly.
> 
> >  This was then divided off when calling
> > +     * the old xc_hvm_build_target_mem() which then turned them to
> bytes.
> > +     * Do all this in one step here...
> > +     */
> > +    args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb)
> << 10;
> > +    args.mem_target = (uint64_t)(info->target_memkb - info-
> >video_memkb) << 10;
> > +    args.image_file_name = firmware;
> > +
> > +    ret = xc_hvm_build(ctx->xch, domid, &args);
> >      if (ret) {
> >          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building
> failed");
> >          goto out;

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:55:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18: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 1U2RCM-0003Zs-2U; Mon, 04 Feb 2013 18:55:22 +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 1U2RCK-0003Zn-Iu
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:55:20 +0000
Received: from [85.158.138.51:9998] by server-12.bemta-3.messagelabs.com id
	02/5A-05889-71400115; Mon, 04 Feb 2013 18:55:19 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360004116!30937078!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2256 invoked from network); 4 Feb 2013 18:55:18 -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;
	4 Feb 2013 18:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="5903669"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:55:16 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Mon, 4 Feb 2013 13:55:16 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:55:14 -0500
Thread-Topic: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4CylpWmjzj3aLYTQedWcQhgo0MqQAPsoJg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B82@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
	<1359977129.5281.70.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359977129.5281.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 v2 01/03] HVM firmware passthrough libxl
 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: Monday, February 04, 2013 6:25 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
> support
> 
> I don't suppose you could arrange for your replies to be threaded with
> the 0/N mail could you? It helps keep them together in my queue, which I
> useful when I come to apply a series which has had a few revisions.
> 
> hg email and git send-email can both do this for you.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches has some tips for hg.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches_with_Git some for git.
> 
> Ian.
Will do.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 04 18:55:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 18: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 1U2RCM-0003Zs-2U; Mon, 04 Feb 2013 18:55:22 +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 1U2RCK-0003Zn-Iu
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:55:20 +0000
Received: from [85.158.138.51:9998] by server-12.bemta-3.messagelabs.com id
	02/5A-05889-71400115; Mon, 04 Feb 2013 18:55:19 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360004116!30937078!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2256 invoked from network); 4 Feb 2013 18:55:18 -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;
	4 Feb 2013 18:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="5903669"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:55:16 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Mon, 4 Feb 2013 13:55:16 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:55:14 -0500
Thread-Topic: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4CylpWmjzj3aLYTQedWcQhgo0MqQAPsoJg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B82@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E5@FTLPMAILBOX02.citrite.net>
	<1359977129.5281.70.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359977129.5281.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 v2 01/03] HVM firmware passthrough libxl
 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: Monday, February 04, 2013 6:25 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v2 01/03] HVM firmware passthrough libxl
> support
> 
> I don't suppose you could arrange for your replies to be threaded with
> the 0/N mail could you? It helps keep them together in my queue, which I
> useful when I come to apply a series which has had a few revisions.
> 
> hg email and git send-email can both do this for you.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches has some tips for hg.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches_with_Git some for git.
> 
> Ian.
Will do.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 04 19:00:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 19: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 1U2RGp-0003jn-PO; Mon, 04 Feb 2013 18:59:59 +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 1U2RGn-0003jg-UW
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:59:58 +0000
Received: from [85.158.143.99:47840] by server-1.bemta-4.messagelabs.com id
	DF/23-08839-D2500115; Mon, 04 Feb 2013 18:59:57 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360004394!22081321!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21584 invoked from network); 4 Feb 2013 18:59:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 18:59:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6210164"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:59:54 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Mon, 4 Feb 2013 13:59:54 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:59:52 -0500
Thread-Topic: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4Cxm9AgF6aYixgQsGf094Mu979NQAQsyKQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B84@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
	<1359975450.5281.53.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359975450.5281.53.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 v2 02/03] HVM firmware passthrough libxl
 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: Monday, February 04, 2013 5:58 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
> support
> 
> On Fri, 2013-02-01 at 20:16 +0000, Ross Philipson wrote:
> > This patch introduces support for two new parameters in libxl:
> >
> > smbios_firmware=<path_to_smbios_structures_file>
> > acpi_firmware=<path_to_acpi_tables_file>
> >
> > The changes are primarily in the domain building code where the
> firmware files
> > are read and passed to libxc for loading into the new guest. After the
> domain
> > building call to libxc, the addresses for the loaded blobs are
> returned and
> > written to xenstore.
> >
> > LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users
> to
> > determine if the feature is present.
> >
> > This patch also updates the xl.cfg man page with descriptions of the
> two new
> > parameters for firmware passthrough.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> > diff -r 25b28b76fc68 docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5     Fri Feb 01 10:20:25 2013 -0500
> > +++ b/docs/man/xl.cfg.pod.5     Fri Feb 01 11:24:21 2013 -0500
> > @@ -829,6 +829,25 @@ libxl: 'host,tm=0,sse3=0'
> >  More info about the CPUID instruction can be found in the processor
> manuals, and
> >  in Wikipedia: L<http://en.wikipedia.org/wiki/CPUID>
> >
> > +=item B<acpi_firmware="STRING">
> > +
> > +Specify a path to a file that contains extra ACPI firmware tables to
> pass in to
> > +a guest. The file can contain several tables in their binary AML form
> > +concatenated together. Each table self describes its length so no
> additional
> > +information is needed. These tables will be added to the ACPI table
> set in the
> > +guest. Note that existing tables cannot be overriden by this feature.
> For
> 
>                                              "overridden"
> 
> (or is this a en_US vs en_GB thing?)
> 
> > +example this cannot be used to override tables like DSDT, FADT, etc.
> > +
> > +=item B<smbios_firmware="STRING">
> > +
> > +Specify a path to a file that contains extra SMBIOS firmware
> structures to pass
> > +in to a guest. The file can contain a set DMTF predefined structures
> which will
> > +override the internal defaults. Not all predefined structures can be
> overriden,
> 
> overridden again?
> 
> > +only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also
> contain any
> > +number of vendor defined SMBIOS structures (type 128 - 255). Since
> SMBIOS
> > +structures do not present their overall size, each entry in the file
> must be
> > +preceeded by a 32b integer indicating the size of the next structure.
> 
>    preceded
> 
> > +
> >  =back
> >
> >  =head3 Guest Virtual Time Controls
> > diff -r 25b28b76fc68 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h       Fri Feb 01 10:20:25 2013 -0500
> > +++ b/tools/libxl/libxl.h       Fri Feb 01 11:24:21 2013 -0500
> > @@ -68,6 +68,13 @@
> >   */
> >
> >  /*
> > + * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the new feature for
> 
> "new" now but not forever ;-)
> 
> (ok, maybe that's nit picking)
> 
> > + * passing in SMBIOS and ACPI firmware to HVM guests is present
> > + * in the library.
> > + */
> > +#define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
> > +
> > +/*
> >   * libxl ABI compatibility
> >   *
> >   * The only guarantee which libxl makes regarding ABI compatibility
> > diff -r 25b28b76fc68 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c   Fri Feb 01 10:20:25 2013 -0500
> > +++ b/tools/libxl/libxl_dom.c   Fri Feb 01 11:24:21 2013 -0500
> > @@ -21,6 +21,7 @@
> >
> >  #include <xc_dom.h>
> >  #include <xen/hvm/hvm_info_table.h>
> > +#include <xen/hvm/hvm_xs_strings.h>
> >
> >  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
> >  {
> > @@ -510,11 +511,61 @@ static int hvm_build_set_params(xc_inter
> >      return 0;
> >  }
> >
> > -static const char *libxl__domain_firmware(libxl__gc *gc,
> > -                                          libxl_domain_build_info
> *info)
> > +static int hvm_build_set_xs_values(libxl__gc *gc,
> > +                                   uint32_t domid,
> > +                                   struct xc_hvm_build_args *args)
> > +{
> > +    char *path = NULL;
> > +    int ret = 0;
> > +
> > +    if (args->smbios_module.guest_addr_out) {
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_ADDRESS,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> > +                              args->smbios_module.guest_addr_out);
> > +        if (ret)
> > +            goto err;
> > +
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_LENGTH,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> > +                              args->smbios_module.length);
> > +        if (ret)
> > +            goto err;
> > +    }
> > +
> > +    if (args->acpi_module.guest_addr_out) {
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> > +                              args->acpi_module.guest_addr_out);
> > +        if (ret)
> > +            goto err;
> > +
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> > +                              args->acpi_module.length);
> > +        if (ret)
> > +            goto err;
> > +    }
> > +
> > +    return 0;
> > +
> > +err:
> > +    LOG(ERROR, "failed to write firmware xenstore value, err: %d",
> ret);
> > +    return -1;
> 
> Why not propagate ret?
> 
> > +}
> > +
> > +static int libxl__domain_firmware(libxl__gc *gc,
> > +                                  libxl_domain_build_info *info,
> > +                                  struct xc_hvm_build_args *args)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> >      const char *firmware;
> > +    int e, rc = ERROR_FAIL;
> > +    int datalen = 0;
> > +    void *data = 0;
> >
> >      if (info->u.hvm.firmware)
> >          firmware = info->u.hvm.firmware;
> > @@ -528,13 +579,58 @@ static const char *libxl__domain_firmwar
> >              firmware = "hvmloader";
> >              break;
> >          default:
> > -            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model
> version %d",
> > -                       info->device_model_version);
> > -            return NULL;
> > +            LOG(ERROR, "invalid device model version %d",
> > +                info->device_model_version);
> > +            return -1;
> 
> I think this makes this function return a mixture of ERROR_* (via rc)
> and -1? Likewise in a few other places. Using ERROR_* consistently would
> be preferable I think.
> 
> >              break;
> >          }
> >      }
> > -    return libxl__abs_path(gc, firmware,
> libxl__xenfirmwaredir_path());
> > +    args->image_file_name = libxl__abs_path(gc, firmware,
> > +
> libxl__xenfirmwaredir_path());
> > +    if (!args->image_file_name) {
> 
> I think the only way this can fail is memory allocation failure, which
> you needn't worry about.
> 
> > +        LOG(ERROR, "invalid firmware path");
> > +        return -1;
> > +    }
> > +
> > +    if (info->u.hvm.smbios_firmware) {
> > +        e = libxl_read_file_contents(ctx, info-
> >u.hvm.smbios_firmware,
> > +                                     &data, &datalen);
> > +        if (e) {
> > +            LOG(ERROR, "failed to read SMBIOS firmware file %s",
> > +                info->u.hvm.smbios_firmware);
> 
> e here is an errno value (I think) so I think you could use LOGEV.
> 
> > +            goto out;
> > +        }
> > +        if (!datalen) {
> > +            LOG(ERROR, "SMBIOS firmware file %s is empty",
> > +                info->u.hvm.smbios_firmware);
> 
> I suppose passing an empty firmware file doesn't make much sense. It
> does it mean that a caller who is generating the table needs to check if
> it actually produced anything though, might be easier to silently accept
> an empty table?

I can do that though I think it would be better to silently drop
the table (which would have the same outcome ultimately). 

> 
> > +            goto out;
> > +        }
> > +        libxl__ptr_add(gc, data);
> > +        args->smbios_module.data = data;
> > +        args->smbios_module.length = (uint32_t)datalen;
> > +    }
> > +
> > +    if (info->u.hvm.acpi_firmware) {
> > +        e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
> > +                                     &data, &datalen);
> > +        if (e) {
> > +            LOG(ERROR, "failed to read ACPI firmware file %s",
> > +                info->u.hvm.acpi_firmware);
> 
> LOGEV again.
> 
> > +            goto out;
> > +        }
> > +        if (!datalen) {
> > +            LOG(ERROR, "ACPI firmware file %s is empty",
> > +                info->u.hvm.acpi_firmware);
> > +            goto out;
> > +        }
> > +        libxl__ptr_add(gc, data);
> 
> I suppose adding libxl__read_file_contents(gc, ...) might be overkill?

Yea I thought about this but the file read routine was used in a
number of places and it might not have been all that easy to ensure
that I tested all of them so I decided to leave libxl__read_file_contents
alone as the safer route.

I will fix the other issues noted in there also.

> 
> 
> > +        args->acpi_module.data = data;
> > +        args->acpi_module.length = (uint32_t)datalen;
> > +    }
> > +
> > +    return 0;
> > +out:
> > +    return rc;
> >  }
> >
> >  int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> > @@ -557,22 +649,34 @@ int libxl__build_hvm(libxl__gc *gc, uint
> [...]
> >      ret = hvm_build_set_params(ctx->xch, domid, info, state-
> >store_port,
> >                                 &state->store_mfn, state-
> >console_port,
> >                                 &state->console_mfn, state-
> >store_domid,
> >                                 state->console_domid);
> >      if (ret) {
> > -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build
> set params failed");
> > +        LOGEV(ERROR, ret, "hvm build set params failed");
> >          goto out;
> >      }
> > -    rc = 0;
> > +
> > +    ret = hvm_build_set_xs_values(gc, domid, &args);
> > +    if (ret) {
> > +        LOGEV(ERROR, ret, "hvm build set xenstore values failed");
> 
> I'm not sure this guy actually returns an errnoval.
> 
> > +        goto out;
> > +    }
> > +
> > +    return 0;
> >  out:
> >      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 Feb 04 19:00:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 19: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 1U2RGp-0003jn-PO; Mon, 04 Feb 2013 18:59:59 +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 1U2RGn-0003jg-UW
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 18:59:58 +0000
Received: from [85.158.143.99:47840] by server-1.bemta-4.messagelabs.com id
	DF/23-08839-D2500115; Mon, 04 Feb 2013 18:59:57 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360004394!22081321!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21584 invoked from network); 4 Feb 2013 18:59:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 18:59:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6210164"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 18:59:54 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi;
	Mon, 4 Feb 2013 13:59:54 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 4 Feb 2013 13:59:52 -0500
Thread-Topic: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
	support
Thread-Index: Ac4Cxm9AgF6aYixgQsGf094Mu979NQAQsyKQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320A93B84@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A320A939E6@FTLPMAILBOX02.citrite.net>
	<1359975450.5281.53.camel@zakaz.uk.xensource.com>
In-Reply-To: <1359975450.5281.53.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 v2 02/03] HVM firmware passthrough libxl
 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: Monday, February 04, 2013 5:58 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v2 02/03] HVM firmware passthrough libxl
> support
> 
> On Fri, 2013-02-01 at 20:16 +0000, Ross Philipson wrote:
> > This patch introduces support for two new parameters in libxl:
> >
> > smbios_firmware=<path_to_smbios_structures_file>
> > acpi_firmware=<path_to_acpi_tables_file>
> >
> > The changes are primarily in the domain building code where the
> firmware files
> > are read and passed to libxc for loading into the new guest. After the
> domain
> > building call to libxc, the addresses for the loaded blobs are
> returned and
> > written to xenstore.
> >
> > LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users
> to
> > determine if the feature is present.
> >
> > This patch also updates the xl.cfg man page with descriptions of the
> two new
> > parameters for firmware passthrough.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> >
> > diff -r 25b28b76fc68 docs/man/xl.cfg.pod.5
> > --- a/docs/man/xl.cfg.pod.5     Fri Feb 01 10:20:25 2013 -0500
> > +++ b/docs/man/xl.cfg.pod.5     Fri Feb 01 11:24:21 2013 -0500
> > @@ -829,6 +829,25 @@ libxl: 'host,tm=0,sse3=0'
> >  More info about the CPUID instruction can be found in the processor
> manuals, and
> >  in Wikipedia: L<http://en.wikipedia.org/wiki/CPUID>
> >
> > +=item B<acpi_firmware="STRING">
> > +
> > +Specify a path to a file that contains extra ACPI firmware tables to
> pass in to
> > +a guest. The file can contain several tables in their binary AML form
> > +concatenated together. Each table self describes its length so no
> additional
> > +information is needed. These tables will be added to the ACPI table
> set in the
> > +guest. Note that existing tables cannot be overriden by this feature.
> For
> 
>                                              "overridden"
> 
> (or is this a en_US vs en_GB thing?)
> 
> > +example this cannot be used to override tables like DSDT, FADT, etc.
> > +
> > +=item B<smbios_firmware="STRING">
> > +
> > +Specify a path to a file that contains extra SMBIOS firmware
> structures to pass
> > +in to a guest. The file can contain a set DMTF predefined structures
> which will
> > +override the internal defaults. Not all predefined structures can be
> overriden,
> 
> overridden again?
> 
> > +only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also
> contain any
> > +number of vendor defined SMBIOS structures (type 128 - 255). Since
> SMBIOS
> > +structures do not present their overall size, each entry in the file
> must be
> > +preceeded by a 32b integer indicating the size of the next structure.
> 
>    preceded
> 
> > +
> >  =back
> >
> >  =head3 Guest Virtual Time Controls
> > diff -r 25b28b76fc68 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h       Fri Feb 01 10:20:25 2013 -0500
> > +++ b/tools/libxl/libxl.h       Fri Feb 01 11:24:21 2013 -0500
> > @@ -68,6 +68,13 @@
> >   */
> >
> >  /*
> > + * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the new feature for
> 
> "new" now but not forever ;-)
> 
> (ok, maybe that's nit picking)
> 
> > + * passing in SMBIOS and ACPI firmware to HVM guests is present
> > + * in the library.
> > + */
> > +#define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
> > +
> > +/*
> >   * libxl ABI compatibility
> >   *
> >   * The only guarantee which libxl makes regarding ABI compatibility
> > diff -r 25b28b76fc68 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c   Fri Feb 01 10:20:25 2013 -0500
> > +++ b/tools/libxl/libxl_dom.c   Fri Feb 01 11:24:21 2013 -0500
> > @@ -21,6 +21,7 @@
> >
> >  #include <xc_dom.h>
> >  #include <xen/hvm/hvm_info_table.h>
> > +#include <xen/hvm/hvm_xs_strings.h>
> >
> >  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
> >  {
> > @@ -510,11 +511,61 @@ static int hvm_build_set_params(xc_inter
> >      return 0;
> >  }
> >
> > -static const char *libxl__domain_firmware(libxl__gc *gc,
> > -                                          libxl_domain_build_info
> *info)
> > +static int hvm_build_set_xs_values(libxl__gc *gc,
> > +                                   uint32_t domid,
> > +                                   struct xc_hvm_build_args *args)
> > +{
> > +    char *path = NULL;
> > +    int ret = 0;
> > +
> > +    if (args->smbios_module.guest_addr_out) {
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_ADDRESS,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> > +                              args->smbios_module.guest_addr_out);
> > +        if (ret)
> > +            goto err;
> > +
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_LENGTH,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> > +                              args->smbios_module.length);
> > +        if (ret)
> > +            goto err;
> > +    }
> > +
> > +    if (args->acpi_module.guest_addr_out) {
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
> > +                              args->acpi_module.guest_addr_out);
> > +        if (ret)
> > +            goto err;
> > +
> > +        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH,
> domid);
> > +
> > +        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
> > +                              args->acpi_module.length);
> > +        if (ret)
> > +            goto err;
> > +    }
> > +
> > +    return 0;
> > +
> > +err:
> > +    LOG(ERROR, "failed to write firmware xenstore value, err: %d",
> ret);
> > +    return -1;
> 
> Why not propagate ret?
> 
> > +}
> > +
> > +static int libxl__domain_firmware(libxl__gc *gc,
> > +                                  libxl_domain_build_info *info,
> > +                                  struct xc_hvm_build_args *args)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> >      const char *firmware;
> > +    int e, rc = ERROR_FAIL;
> > +    int datalen = 0;
> > +    void *data = 0;
> >
> >      if (info->u.hvm.firmware)
> >          firmware = info->u.hvm.firmware;
> > @@ -528,13 +579,58 @@ static const char *libxl__domain_firmwar
> >              firmware = "hvmloader";
> >              break;
> >          default:
> > -            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model
> version %d",
> > -                       info->device_model_version);
> > -            return NULL;
> > +            LOG(ERROR, "invalid device model version %d",
> > +                info->device_model_version);
> > +            return -1;
> 
> I think this makes this function return a mixture of ERROR_* (via rc)
> and -1? Likewise in a few other places. Using ERROR_* consistently would
> be preferable I think.
> 
> >              break;
> >          }
> >      }
> > -    return libxl__abs_path(gc, firmware,
> libxl__xenfirmwaredir_path());
> > +    args->image_file_name = libxl__abs_path(gc, firmware,
> > +
> libxl__xenfirmwaredir_path());
> > +    if (!args->image_file_name) {
> 
> I think the only way this can fail is memory allocation failure, which
> you needn't worry about.
> 
> > +        LOG(ERROR, "invalid firmware path");
> > +        return -1;
> > +    }
> > +
> > +    if (info->u.hvm.smbios_firmware) {
> > +        e = libxl_read_file_contents(ctx, info-
> >u.hvm.smbios_firmware,
> > +                                     &data, &datalen);
> > +        if (e) {
> > +            LOG(ERROR, "failed to read SMBIOS firmware file %s",
> > +                info->u.hvm.smbios_firmware);
> 
> e here is an errno value (I think) so I think you could use LOGEV.
> 
> > +            goto out;
> > +        }
> > +        if (!datalen) {
> > +            LOG(ERROR, "SMBIOS firmware file %s is empty",
> > +                info->u.hvm.smbios_firmware);
> 
> I suppose passing an empty firmware file doesn't make much sense. It
> does it mean that a caller who is generating the table needs to check if
> it actually produced anything though, might be easier to silently accept
> an empty table?

I can do that though I think it would be better to silently drop
the table (which would have the same outcome ultimately). 

> 
> > +            goto out;
> > +        }
> > +        libxl__ptr_add(gc, data);
> > +        args->smbios_module.data = data;
> > +        args->smbios_module.length = (uint32_t)datalen;
> > +    }
> > +
> > +    if (info->u.hvm.acpi_firmware) {
> > +        e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
> > +                                     &data, &datalen);
> > +        if (e) {
> > +            LOG(ERROR, "failed to read ACPI firmware file %s",
> > +                info->u.hvm.acpi_firmware);
> 
> LOGEV again.
> 
> > +            goto out;
> > +        }
> > +        if (!datalen) {
> > +            LOG(ERROR, "ACPI firmware file %s is empty",
> > +                info->u.hvm.acpi_firmware);
> > +            goto out;
> > +        }
> > +        libxl__ptr_add(gc, data);
> 
> I suppose adding libxl__read_file_contents(gc, ...) might be overkill?

Yea I thought about this but the file read routine was used in a
number of places and it might not have been all that easy to ensure
that I tested all of them so I decided to leave libxl__read_file_contents
alone as the safer route.

I will fix the other issues noted in there also.

> 
> 
> > +        args->acpi_module.data = data;
> > +        args->acpi_module.length = (uint32_t)datalen;
> > +    }
> > +
> > +    return 0;
> > +out:
> > +    return rc;
> >  }
> >
> >  int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> > @@ -557,22 +649,34 @@ int libxl__build_hvm(libxl__gc *gc, uint
> [...]
> >      ret = hvm_build_set_params(ctx->xch, domid, info, state-
> >store_port,
> >                                 &state->store_mfn, state-
> >console_port,
> >                                 &state->console_mfn, state-
> >store_domid,
> >                                 state->console_domid);
> >      if (ret) {
> > -        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build
> set params failed");
> > +        LOGEV(ERROR, ret, "hvm build set params failed");
> >          goto out;
> >      }
> > -    rc = 0;
> > +
> > +    ret = hvm_build_set_xs_values(gc, domid, &args);
> > +    if (ret) {
> > +        LOGEV(ERROR, ret, "hvm build set xenstore values failed");
> 
> I'm not sure this guy actually returns an errnoval.
> 
> > +        goto out;
> > +    }
> > +
> > +    return 0;
> >  out:
> >      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 Feb 04 19:41:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 19:41: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 1U2RuK-0004q6-N2; Mon, 04 Feb 2013 19:40: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 1U2RuJ-0004q1-06
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 19:40:47 +0000
Received: from [85.158.143.99:50520] by server-3.bemta-4.messagelabs.com id
	B5/91-08920-EBE00115; Mon, 04 Feb 2013 19:40:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360006845!17893701!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 307 invoked from network); 4 Feb 2013 19:40:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 19:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1132552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 19:40: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.297.1; Mon, 4 Feb 2013 19:40:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2RuD-0001j7-Qy;
	Mon, 04 Feb 2013 19:40:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2RuD-0005C3-JV;
	Mon, 04 Feb 2013 19:40:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15418-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 19:40:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 15418: 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 15418 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15418/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15383
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 15383

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-qemut-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-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass

version targeted for testing:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46
baseline version:
 linux                214dfbe8f312326911434eee3ef521e3b78e1399

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=e1c63f9f42393f7c1dc072db7e0d54e599e96b46
+ . 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 e1c63f9f42393f7c1dc072db7e0d54e599e96b46
+ branch=linux-3.0
+ revision=e1c63f9f42393f7c1dc072db7e0d54e599e96b46
+ . 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/hg/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 e1c63f9f42393f7c1dc072db7e0d54e599e96b46:tested/linux-3.0
Counting objects: 1   
Counting objects: 32   
Counting objects: 133, done.
Compressing objects:   6% (1/16)   
Compressing objects:  12% (2/16)   
Compressing objects:  18% (3/16)   
Compressing objects:  25% (4/16)   
Compressing objects:  31% (5/16)   
Compressing objects:  37% (6/16)   
Compressing objects:  43% (7/16)   
Compressing objects:  50% (8/16)   
Compressing objects:  56% (9/16)   
Compressing objects:  62% (10/16)   
Compressing objects:  68% (11/16)   
Compressing objects:  75% (12/16)   
Compressing objects:  81% (13/16)   
Compressing objects:  87% (14/16)   
Compressing objects:  93% (15/16)   
Compressing objects: 100% (16/16)   
Compressing objects: 100% (16/16), done.
Writing objects:   1% (1/93)   
Writing objects:   2% (2/93)   
Writing objects:   3% (3/93)   
Writing objects:   4% (4/93)   
Writing objects:   5% (5/93)   
Writing objects:   6% (6/93)   
Writing objects:   7% (7/93)   
Writing objects:   8% (8/93)   
Writing objects:   9% (9/93)   
Writing objects:  10% (10/93)   
Writing objects:  11% (11/93)   
Writing objects:  12% (12/93)   
Writing objects:  13% (13/93)   
Writing objects:  16% (15/93)   
Writing objects:  17% (16/93)   
Writing objects:  18% (17/93)   
Writing objects:  19% (18/93)   
Writing objects:  20% (19/93)   
Writing objects:  21% (20/93)   
Writing objects:  22% (21/93)   
Writing objects:  23% (22/93)   
Writing objects:  24% (23/93)   
Writing objects:  25% (24/93)   
Writing objects:  26% (25/93)   
Writing objects:  27% (26/93)   
Writing objects:  29% (27/93)   
Writing objects:  30% (28/93)   
Writing objects:  31% (29/93)   
Writing objects:  32% (30/93)   
Writing objects:  33% (31/93)   
Writing objects:  34% (32/93)   
Writing objects:  35% (33/93)   
Writing objects:  36% (34/93)   
Writing objects:  37% (35/93)   
Writing objects:  38% (36/93)   
Writing objects:  39% (37/93)   
Writing objects:  40% (38/93)   
Writing objects:  41% (39/93)   
Writing objects:  43% (40/93)   
Writing objects:  44% (41/93)   
Writing objects:  45% (42/93)   
Writing objects:  46% (43/93)   
Writing objects:  47% (44/93)   
Writing objects:  48% (45/93)   
Writing objects:  49% (46/93)   
Writing objects:  50% (47/93)   
Writing objects:  51% (48/93)   
Writing objects:  52% (49/93)   
Writing objects:  53% (50/93)   
Writing objects:  54% (51/93)   
Writing objects:  55% (52/93)   
Writing objects:  56% (53/93)   
Writing objects:  58% (54/93)   
Writing objects:  59% (55/93)   
Writing objects:  60% (56/93)   
Writing objects:  61% (57/93)   
Writing objects:  62% (58/93)   
Writing objects:  63% (59/93)   
Writing objects:  64% (60/93)   
Writing objects:  65% (61/93)   
Writing objects:  66% (62/93)   
Writing objects:  67% (63/93)   
Writing objects:  68% (64/93)   
Writing objects:  69% (65/93)   
Writing objects:  70% (66/93)   
Writing objects:  72% (67/93)   
Writing objects:  73% (68/93)   
Writing objects:  74% (69/93)   
Writing objects:  75% (70/93)   
Writing objects:  76% (71/93)   
Writing objects:  77% (72/93)   
Writing objects:  78% (73/93)   
Writing objects:  79% (74/93)   
Writing objects:  80% (75/93)   
Writing objects:  81% (76/93)   
Writing objects:  82% (77/93)   
Writing objects:  83% (78/93)   
Writing objects:  84% (79/93)   
Writing objects:  86% (80/93)   
Writing objects:  87% (81/93)   
Writing objects:  88% (82/93)   
Writing objects:  89% (83/93)   
Writing objects:  90% (84/93)   
Writing objects:  91% (85/93)   
Writing objects:  92% (86/93)   
Writing objects:  93% (87/93)   
Writing objects:  94% (88/93)   
Writing objects:  95% (89/93)   
Writing objects:  96% (90/93)   
Writing objects:  97% (91/93)   
Writing objects:  98% (92/93)   
Writing objects: 100% (93/93)   
Writing objects: 100% (93/93), 14.67 KiB, done.
Total 93 (delta 79), reused 78 (delta 77)
To xen@xenbits.xensource.com:git/linux-pvops.git
   214dfbe..e1c63f9f e1c63f9f42393f7c1dc072db7e0d54e599e96b46 -> 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 Mon Feb 04 19:41:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 19:41: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 1U2RuK-0004q6-N2; Mon, 04 Feb 2013 19:40: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 1U2RuJ-0004q1-06
	for xen-devel@lists.xensource.com; Mon, 04 Feb 2013 19:40:47 +0000
Received: from [85.158.143.99:50520] by server-3.bemta-4.messagelabs.com id
	B5/91-08920-EBE00115; Mon, 04 Feb 2013 19:40:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360006845!17893701!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 307 invoked from network); 4 Feb 2013 19:40:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 19:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1132552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Feb 2013 19:40: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.297.1; Mon, 4 Feb 2013 19:40:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2RuD-0001j7-Qy;
	Mon, 04 Feb 2013 19:40:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2RuD-0005C3-JV;
	Mon, 04 Feb 2013 19:40:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15418-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 4 Feb 2013 19:40:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 15418: 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 15418 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15418/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15383
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 15383

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-qemut-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-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass

version targeted for testing:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46
baseline version:
 linux                214dfbe8f312326911434eee3ef521e3b78e1399

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=e1c63f9f42393f7c1dc072db7e0d54e599e96b46
+ . 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 e1c63f9f42393f7c1dc072db7e0d54e599e96b46
+ branch=linux-3.0
+ revision=e1c63f9f42393f7c1dc072db7e0d54e599e96b46
+ . 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/hg/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 e1c63f9f42393f7c1dc072db7e0d54e599e96b46:tested/linux-3.0
Counting objects: 1   
Counting objects: 32   
Counting objects: 133, done.
Compressing objects:   6% (1/16)   
Compressing objects:  12% (2/16)   
Compressing objects:  18% (3/16)   
Compressing objects:  25% (4/16)   
Compressing objects:  31% (5/16)   
Compressing objects:  37% (6/16)   
Compressing objects:  43% (7/16)   
Compressing objects:  50% (8/16)   
Compressing objects:  56% (9/16)   
Compressing objects:  62% (10/16)   
Compressing objects:  68% (11/16)   
Compressing objects:  75% (12/16)   
Compressing objects:  81% (13/16)   
Compressing objects:  87% (14/16)   
Compressing objects:  93% (15/16)   
Compressing objects: 100% (16/16)   
Compressing objects: 100% (16/16), done.
Writing objects:   1% (1/93)   
Writing objects:   2% (2/93)   
Writing objects:   3% (3/93)   
Writing objects:   4% (4/93)   
Writing objects:   5% (5/93)   
Writing objects:   6% (6/93)   
Writing objects:   7% (7/93)   
Writing objects:   8% (8/93)   
Writing objects:   9% (9/93)   
Writing objects:  10% (10/93)   
Writing objects:  11% (11/93)   
Writing objects:  12% (12/93)   
Writing objects:  13% (13/93)   
Writing objects:  16% (15/93)   
Writing objects:  17% (16/93)   
Writing objects:  18% (17/93)   
Writing objects:  19% (18/93)   
Writing objects:  20% (19/93)   
Writing objects:  21% (20/93)   
Writing objects:  22% (21/93)   
Writing objects:  23% (22/93)   
Writing objects:  24% (23/93)   
Writing objects:  25% (24/93)   
Writing objects:  26% (25/93)   
Writing objects:  27% (26/93)   
Writing objects:  29% (27/93)   
Writing objects:  30% (28/93)   
Writing objects:  31% (29/93)   
Writing objects:  32% (30/93)   
Writing objects:  33% (31/93)   
Writing objects:  34% (32/93)   
Writing objects:  35% (33/93)   
Writing objects:  36% (34/93)   
Writing objects:  37% (35/93)   
Writing objects:  38% (36/93)   
Writing objects:  39% (37/93)   
Writing objects:  40% (38/93)   
Writing objects:  41% (39/93)   
Writing objects:  43% (40/93)   
Writing objects:  44% (41/93)   
Writing objects:  45% (42/93)   
Writing objects:  46% (43/93)   
Writing objects:  47% (44/93)   
Writing objects:  48% (45/93)   
Writing objects:  49% (46/93)   
Writing objects:  50% (47/93)   
Writing objects:  51% (48/93)   
Writing objects:  52% (49/93)   
Writing objects:  53% (50/93)   
Writing objects:  54% (51/93)   
Writing objects:  55% (52/93)   
Writing objects:  56% (53/93)   
Writing objects:  58% (54/93)   
Writing objects:  59% (55/93)   
Writing objects:  60% (56/93)   
Writing objects:  61% (57/93)   
Writing objects:  62% (58/93)   
Writing objects:  63% (59/93)   
Writing objects:  64% (60/93)   
Writing objects:  65% (61/93)   
Writing objects:  66% (62/93)   
Writing objects:  67% (63/93)   
Writing objects:  68% (64/93)   
Writing objects:  69% (65/93)   
Writing objects:  70% (66/93)   
Writing objects:  72% (67/93)   
Writing objects:  73% (68/93)   
Writing objects:  74% (69/93)   
Writing objects:  75% (70/93)   
Writing objects:  76% (71/93)   
Writing objects:  77% (72/93)   
Writing objects:  78% (73/93)   
Writing objects:  79% (74/93)   
Writing objects:  80% (75/93)   
Writing objects:  81% (76/93)   
Writing objects:  82% (77/93)   
Writing objects:  83% (78/93)   
Writing objects:  84% (79/93)   
Writing objects:  86% (80/93)   
Writing objects:  87% (81/93)   
Writing objects:  88% (82/93)   
Writing objects:  89% (83/93)   
Writing objects:  90% (84/93)   
Writing objects:  91% (85/93)   
Writing objects:  92% (86/93)   
Writing objects:  93% (87/93)   
Writing objects:  94% (88/93)   
Writing objects:  95% (89/93)   
Writing objects:  96% (90/93)   
Writing objects:  97% (91/93)   
Writing objects:  98% (92/93)   
Writing objects: 100% (93/93)   
Writing objects: 100% (93/93), 14.67 KiB, done.
Total 93 (delta 79), reused 78 (delta 77)
To xen@xenbits.xensource.com:git/linux-pvops.git
   214dfbe..e1c63f9f e1c63f9f42393f7c1dc072db7e0d54e599e96b46 -> 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 Mon Feb 04 19:59:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 19:59: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 1U2SCQ-0005TW-28; Mon, 04 Feb 2013 19:59:30 +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 1U2SCO-0005TR-Sj
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 19:59:29 +0000
Received: from [193.109.254.147:48834] by server-12.bemta-14.messagelabs.com
	id 4C/CC-32582-02310115; Mon, 04 Feb 2013 19:59:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360007966!1695928!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16165 invoked from network); 4 Feb 2013 19:59:26 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 19:59:26 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so4695507wib.5
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 11:59:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JkdSdYitLYMHqeq2pd+drz0lOIRvFoi87t66FUY/Qqo=;
	b=FwPGlOyNoGaZ0DO7gz/T/22p1Y2RJLdC79fcUnebpun3dbRbcnEUvzMdoSSItJsqih
	1eN6uAfwcQiHuRuWCn1hIiVYJqJQYCdTpDh2V2m0l1ZfEQH8VeNKQzWWwDBalRXmVzYV
	Qy7K1CbWSWra/c3Vs1ypg7eTkus9DIuD/HdCce34g+ktj/lWwbAYoRjgfrVwRGP6HCap
	uxlC+ztYIMTmIVdvsp+yfyWIoV67BidJc3pUYY4uC4t4Y8PMRN2PQqq2S86YK4E/mEVE
	dzrsK6RRwplBdZp+QXLDYRaeraZt/WRRlsUccFFZqYnbNuQp73DbtIohE0hgbAuAbyQ5
	NEVA==
X-Received: by 10.180.90.147 with SMTP id bw19mr12713003wib.28.1360007963298; 
	Mon, 04 Feb 2013 11:59:23 -0800 (PST)
Received: from [192.168.1.94] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id s8sm461642wif.9.2013.02.04.11.59.20
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 11:59:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 19:59:16 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD35C394.4B677%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DEhxV4sjAnqEXFkSf5H8AzMbgig==
In-Reply-To: <510FF54E.1070706@citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:

> Hi,
> 
> Here is a design for a scalable event channel ABI for Xen.  It has a
> number of benefits over the design currently being proposed by Wei Lui.
> 
> * More event channels (>100,000).
> * 16 event priorities.
> * Reduced memory requirements (only 1 additional page per domU).
> * The use of FIFOs for events ensures fairness, whereas it is difficult
> to reason about the fairness with the current bitmap system.

I have some sympathy for this design. It's primary downside compared with
the 3-level alternative is its greater space cost (32*#vcpus). However, as
you say the fairness and prioritisation features are rather nice. Also
having the data structures be per vcpu may well help avoid cacheline
contention on busy multi-vcpu guests.

Interested in what others think, but I may actually prefer a ground-up
redesign like this.

 -- Keir

> The PDF version is easier to read and has diagrams and readable maths
> but the original markdown format document is included below (for ease of
> commenting).
> 
> http://xenbits.xen.org/people/dvrabel/event-channels-A.pdf
> 
> Introduction
> ============
> 
> Purpose
> -------
> 
> Xen uses event channels to signal events (interrupts) to (fully or
> partially) paravirtualized guests.  The current event channel ABI
> provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
> (for 64-bit guests) event channels.  This is limiting scalability as
> support for more VMs, VCPUs and devices is required.
> 
> The existing ABI does not easily allow events to have different
> priorities.  Current Linux kernels prioritize the timer event by
> special casing this but this is not generalizable to more events.
> Event priorities may be useful for prioritizing MMIO emulation
> requests over bulk data traffic (such as network or disk).
> 
> This design replaces the existing event channel ABI with one that:
> 
> - is scalable to more than 100,000 event channels, with scope for
> increasing this further with minimal ABI changes.
> 
> - allows guests to use up-to 16 different event priorities.
> 
> System Overview
> ---------------
> 
> [FIXME: diagram showing Xen and guest and shared memory block for events?]
> 
> Design Map
> ----------
> 
> A new event channel ABI requires changes to Xen and the guest kernels.
> 
> References
> ----------
> 
> [FIXME: link to alternate proposal?]
> 
> Design Considerations
> =====================
> 
> Assumptions
> -----------
> 
> * Atomic read-modify-write of 32-bit words is possible on all
>   supported platforms.  This can be with a linked-load /
>   store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
>   (e.g., x86's cmpxchg).
> 
> Constraints
> -----------
> 
> * The existing ABI must continue to be useable.  Compatibilty with
>   existing guests is mandatory.
> 
> Risks and Volatile Areas
> ------------------------
> 
> * Should the 3-level proposal be merged into Xen then this design does
>   not offer enough improvements to warrant the cost of maintaining
>   three different event channel ABIs in Xen and guest kernels.
> 
> * The performance of some operations may be decreased.  Specifically,
>   retriggering an event now always requires a hypercall.
> 
> Architecture
> ============
> 
> Overview
> --------
> 
> The event channel ABI uses a data structure that is shared between Xen
> and the guest.  Access to the structure is done with lock-less
> operations (except for some less common operations where the guest
> must use a hypercall).  The guest is responsible for allocating this
> structure and registering it with Xen during VCPU bring-up.
> 
> Events are reported to a guest's VCPU using a FIFO queue.  There is a
> queue for each priority level and each VCPU.
> 
> Each event has a _pending_ and a _masked_ bit.  The pending bit
> indicates the event has been raised.  The masked bit is used by the
> guest to prevent delivery of that specific event.
> 
> 
> High Level Design
> =================
> 
> Shared Event Data Structure
> ---------------------------
> 
> The shared event data structure has a per-domain _event array_, and a
> per-VCPU _control block_.
> 
> - _event array_: A logical array of event words (one per event
>   channel) which contains the pending and mask bits and the link index
>   for next event in the queue.
> 
> ![\label{fig_event-word}Event Array Word](event-word.pdf)
> 
> - _control block_: This contains the head and tail indexes for each
>   priority level.  Each VCPU has its own control block and this is
>   contained in the existing `struct vcpu_info`.
> 
> The pages within the event array need not be physically nor virtually
> contiguous, but the guest or Xen may make the virtually contiguous for
> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> Linux.  Pages are added by the guest as required by the number of
> bound event channels.
> 
> Only 17 bits are currently defined for the LINK field, allowing 2^17^
> (131,072) events.  This limit can be trivially increased without any
> other changes to the ABI.  Bits [28:17] are reserved for future
> expansion or for other uses.
> 
> Event State Machine
> -------------------
> 
> Event channels are bound to a domain using the existing ABI.
> 
> A bound event may be in one of three main states.
> 
> State    Abbrev.  Meaning
> -----    -------  -------
> BOUND    B        The event is bound but not pending.
> PENDING  P        The event has been raised and not yet acknowledged.
> LINKED   L        The event is on an event queue.
> 
> Additionally, events may be UNMASKED or MASKED (M).
> 
> ![\label{events_sm}Event State Machine](event-sm.pdf)
> 
> The state of an event is tracked using 3 bits within the event word.
> the M (masked), P (pending) and L (linked) bits.  Only state
> transitions that change a single bit are valid.
> 
> Event Queues
> ------------
> 
> The event queues use a singly-linked list of event array words (see
> figure \ref{fig_event-word} and \ref{fig_event-queue}).
> 
> ![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)
> 
> Each event queue has a head and tail index stored in the control
> block.  The head index is the index of the first element in the queue.
> The tail index is the last element in the queue.  Every element within
> the queue has the L bit set.
> 
> The LINK field in the event word indexes the next event in the queue.
> LINK is zero for the last word in the queue.
> 
> The queue is empty when the head index is zero (zero is not a valid
> event channel).
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init`
> 
> * `EVTCHNOP_expand`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init`
> 
> This call initializes a single VCPU's event channel data structures,
> adding one page for the event array.
> 
> A guest should call this during initial VCPU bring up (and on resume?).
> 
>     struct evtchnop_init {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frame for the domain.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand`
> 
> This call expands the event array for a VCPU by appended an additional
> page.
> 
> A guest should call this for all VCPUs when a new event channel is
> required and there is insufficient space in the current event array.
> 
> It is not possible to shrink the event array once it has been
> expanded.
> 
>     struct evtchnop_expand {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frames for the domain.
> EINVAL      The event array already has the maximum number of pages.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.
> 
> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> 
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.
> EINVAL      `priority` is outside the range 0 - 15.
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the maximum number of event channels a
> domain can bind.  The default for dom0 is unlimited.  Other domains
> default to 1024 events (requiring only a single page for their event
> array).
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_events;
>     };
> 
> Field         Purpose
> -----         -------
> `domid`       [in] The domain ID.
> `max_events`  [in] The maximum number of event channels that may be bound
>               to the domain.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 
> Memory Usage
> ------------
> 
> ### Event Arrays
> 
> Xen needs to map every domains' event array into its address space.
> The space reserved for these global mappings is limited to 1 GiB on
> x86-64 (262144 pages) and is shared with other users.
> 
> It is non-trivial to calculate the maximum number of VMs that can be
> supported as this depends on the system configuration (how many driver
> domains etc.) and VM configuration.  We can make some assuptions and
> derive an approximate limit.
> 
> Each page of the event array has space for 1024 events ($E_P$) so a
> regular domU will only require a single page.  Since event channels
> typically come in pairs, the upper bound on the total number of pages
> is $2 \times\text{number of VMs}$.
> 
> If the guests are further restricted in the number of event channels
> ($E_V$) then this upper bound can be reduced further.
> 
> The number of VMs ($V$) with a limit of $P$ total event array pages is:
> \begin{equation*}
> V = P \div \left(1 + \frac{E_V}{E_P}\right)
> \end{equation*}
> 
> Using only half the available pages and limiting guests to only 64
> events gives:
> \begin{eqnarray*}
> V & = & (262144 / 2) \div (1 + 64 / 1024) \\
>   & = & 123 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> Alternatively, we can consider a system with $D$ driver domains, each
> of which requires $E_D$ events, and a dom0 using the maximum number of
> pages (128).
> 
> \begin{eqnarray*}
> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> \end{eqnarray*}
> 
> With, for example, 16 driver domains each using the maximum number of pages:
> \begin{eqnarray*}
> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>    & = & 129 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> In summary, there is space to map the event arrays for over 100,000
> VMs.  This is more than the limit imposed by the 16 bit domain ID
> (~32,000 VMs).
> 
> ### Control Block
> 
> With $L$ priority levels and two 32-bit words for the head and tail
> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> for the control block is:
> \begin{eqnarray*}
> S & = & L \times 2 \times 4 \\
>   & = & 16 \times 2 \times 4 \\
>   & = & 128\text{ bytes}
> \end{eqnarray*}
> 
> There is more than enough space within `struct vcpu_info` for the
> control block while still keeping plenty of space for future use.
> 
> Low Level Design
> ================
> 
> In the pseudo code in this section, all memory accesses are atomic,
> including those to bit-fields within the event word.
> 
> These variables have a standard meaning:
> 
> Variable  Purpose
> --------  -------
> E         Event array.
> p         A specific event.
> H         The head index for a specific priority.
> T         The tail index for a specific priority.
> 
> These memory barriers are required:
> 
> Function  Purpose
> --------  -------
> mb()      Full (read/write) memory barrier
> 
> Raising an Event
> ----------------
> 
> When Xen raises an event it marks it pending and (if it is not masked)
> adds it tail of event queue.
> 
>     E[p].pending = 1
>     if not E[p].linked and not E[n].masked
>         E[p].linked = 1
>         E[p].link = 0
>         mb()
>         if H == 0
>             H = p
>         else
>             E[T].link = p
>         T = p
> 
> Concurrent access by Xen to the event queue must be protected by a
> per-event queue spin lock.
> 
> Consuming Events
> ----------------
> 
> The guests consumes events starting at the head until it reaches the
> tail.  Events in the queue that are not pending or are masked are
> consumed but not handled.
> 
>     while H != 0
>         p = H
>         H = E[p].link
>         if H == 0
>             mb()
>             H = E[p].link
>         E[H].linked = 0
>         if not E[p].masked
>             handle(p)
> 
> handle() clears `E[p].pending` and EOIs level-triggered PIRQs.
> 
>> Note: When the event queue contains a single event, removing the
>> event may race with Xen appending another event because the load of
>> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
>> the guest must recheck `E[p].link` if the list appeared empty.
> 
> Masking Events
> --------------
> 
> Events are masked by setting the masked bit.  If the event is pending
> and linked it does not need to be unlinked.
> 
>     E[p].masked = 1
> 
> Unmasking Events
> ----------------
> 
> Events are unmasked by the guest by clearing the masked bit.  If the
> event is pending the guest must call the event channel unmask
> hypercall so Xen can link the event into the correct event queue.
> 
>     E[p].masked = 0
>     if E[p].pending
>         hypercall(EVTCHN_unmask)
> 
> The expectation here is that unmasking a pending event will be rare,
> so the performance hit of the hypercall is minimal.
> 
>> Note: that after clearing the mask bit, the event may be raised and
>> thus it may already be linked by the time the hypercall is done.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 19:59:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 19:59: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 1U2SCQ-0005TW-28; Mon, 04 Feb 2013 19:59:30 +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 1U2SCO-0005TR-Sj
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 19:59:29 +0000
Received: from [193.109.254.147:48834] by server-12.bemta-14.messagelabs.com
	id 4C/CC-32582-02310115; Mon, 04 Feb 2013 19:59:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360007966!1695928!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16165 invoked from network); 4 Feb 2013 19:59:26 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 19:59:26 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so4695507wib.5
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 11:59:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JkdSdYitLYMHqeq2pd+drz0lOIRvFoi87t66FUY/Qqo=;
	b=FwPGlOyNoGaZ0DO7gz/T/22p1Y2RJLdC79fcUnebpun3dbRbcnEUvzMdoSSItJsqih
	1eN6uAfwcQiHuRuWCn1hIiVYJqJQYCdTpDh2V2m0l1ZfEQH8VeNKQzWWwDBalRXmVzYV
	Qy7K1CbWSWra/c3Vs1ypg7eTkus9DIuD/HdCce34g+ktj/lWwbAYoRjgfrVwRGP6HCap
	uxlC+ztYIMTmIVdvsp+yfyWIoV67BidJc3pUYY4uC4t4Y8PMRN2PQqq2S86YK4E/mEVE
	dzrsK6RRwplBdZp+QXLDYRaeraZt/WRRlsUccFFZqYnbNuQp73DbtIohE0hgbAuAbyQ5
	NEVA==
X-Received: by 10.180.90.147 with SMTP id bw19mr12713003wib.28.1360007963298; 
	Mon, 04 Feb 2013 11:59:23 -0800 (PST)
Received: from [192.168.1.94] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id s8sm461642wif.9.2013.02.04.11.59.20
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 11:59:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 19:59:16 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD35C394.4B677%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DEhxV4sjAnqEXFkSf5H8AzMbgig==
In-Reply-To: <510FF54E.1070706@citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:

> Hi,
> 
> Here is a design for a scalable event channel ABI for Xen.  It has a
> number of benefits over the design currently being proposed by Wei Lui.
> 
> * More event channels (>100,000).
> * 16 event priorities.
> * Reduced memory requirements (only 1 additional page per domU).
> * The use of FIFOs for events ensures fairness, whereas it is difficult
> to reason about the fairness with the current bitmap system.

I have some sympathy for this design. It's primary downside compared with
the 3-level alternative is its greater space cost (32*#vcpus). However, as
you say the fairness and prioritisation features are rather nice. Also
having the data structures be per vcpu may well help avoid cacheline
contention on busy multi-vcpu guests.

Interested in what others think, but I may actually prefer a ground-up
redesign like this.

 -- Keir

> The PDF version is easier to read and has diagrams and readable maths
> but the original markdown format document is included below (for ease of
> commenting).
> 
> http://xenbits.xen.org/people/dvrabel/event-channels-A.pdf
> 
> Introduction
> ============
> 
> Purpose
> -------
> 
> Xen uses event channels to signal events (interrupts) to (fully or
> partially) paravirtualized guests.  The current event channel ABI
> provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
> (for 64-bit guests) event channels.  This is limiting scalability as
> support for more VMs, VCPUs and devices is required.
> 
> The existing ABI does not easily allow events to have different
> priorities.  Current Linux kernels prioritize the timer event by
> special casing this but this is not generalizable to more events.
> Event priorities may be useful for prioritizing MMIO emulation
> requests over bulk data traffic (such as network or disk).
> 
> This design replaces the existing event channel ABI with one that:
> 
> - is scalable to more than 100,000 event channels, with scope for
> increasing this further with minimal ABI changes.
> 
> - allows guests to use up-to 16 different event priorities.
> 
> System Overview
> ---------------
> 
> [FIXME: diagram showing Xen and guest and shared memory block for events?]
> 
> Design Map
> ----------
> 
> A new event channel ABI requires changes to Xen and the guest kernels.
> 
> References
> ----------
> 
> [FIXME: link to alternate proposal?]
> 
> Design Considerations
> =====================
> 
> Assumptions
> -----------
> 
> * Atomic read-modify-write of 32-bit words is possible on all
>   supported platforms.  This can be with a linked-load /
>   store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
>   (e.g., x86's cmpxchg).
> 
> Constraints
> -----------
> 
> * The existing ABI must continue to be useable.  Compatibilty with
>   existing guests is mandatory.
> 
> Risks and Volatile Areas
> ------------------------
> 
> * Should the 3-level proposal be merged into Xen then this design does
>   not offer enough improvements to warrant the cost of maintaining
>   three different event channel ABIs in Xen and guest kernels.
> 
> * The performance of some operations may be decreased.  Specifically,
>   retriggering an event now always requires a hypercall.
> 
> Architecture
> ============
> 
> Overview
> --------
> 
> The event channel ABI uses a data structure that is shared between Xen
> and the guest.  Access to the structure is done with lock-less
> operations (except for some less common operations where the guest
> must use a hypercall).  The guest is responsible for allocating this
> structure and registering it with Xen during VCPU bring-up.
> 
> Events are reported to a guest's VCPU using a FIFO queue.  There is a
> queue for each priority level and each VCPU.
> 
> Each event has a _pending_ and a _masked_ bit.  The pending bit
> indicates the event has been raised.  The masked bit is used by the
> guest to prevent delivery of that specific event.
> 
> 
> High Level Design
> =================
> 
> Shared Event Data Structure
> ---------------------------
> 
> The shared event data structure has a per-domain _event array_, and a
> per-VCPU _control block_.
> 
> - _event array_: A logical array of event words (one per event
>   channel) which contains the pending and mask bits and the link index
>   for next event in the queue.
> 
> ![\label{fig_event-word}Event Array Word](event-word.pdf)
> 
> - _control block_: This contains the head and tail indexes for each
>   priority level.  Each VCPU has its own control block and this is
>   contained in the existing `struct vcpu_info`.
> 
> The pages within the event array need not be physically nor virtually
> contiguous, but the guest or Xen may make the virtually contiguous for
> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> Linux.  Pages are added by the guest as required by the number of
> bound event channels.
> 
> Only 17 bits are currently defined for the LINK field, allowing 2^17^
> (131,072) events.  This limit can be trivially increased without any
> other changes to the ABI.  Bits [28:17] are reserved for future
> expansion or for other uses.
> 
> Event State Machine
> -------------------
> 
> Event channels are bound to a domain using the existing ABI.
> 
> A bound event may be in one of three main states.
> 
> State    Abbrev.  Meaning
> -----    -------  -------
> BOUND    B        The event is bound but not pending.
> PENDING  P        The event has been raised and not yet acknowledged.
> LINKED   L        The event is on an event queue.
> 
> Additionally, events may be UNMASKED or MASKED (M).
> 
> ![\label{events_sm}Event State Machine](event-sm.pdf)
> 
> The state of an event is tracked using 3 bits within the event word.
> the M (masked), P (pending) and L (linked) bits.  Only state
> transitions that change a single bit are valid.
> 
> Event Queues
> ------------
> 
> The event queues use a singly-linked list of event array words (see
> figure \ref{fig_event-word} and \ref{fig_event-queue}).
> 
> ![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)
> 
> Each event queue has a head and tail index stored in the control
> block.  The head index is the index of the first element in the queue.
> The tail index is the last element in the queue.  Every element within
> the queue has the L bit set.
> 
> The LINK field in the event word indexes the next event in the queue.
> LINK is zero for the last word in the queue.
> 
> The queue is empty when the head index is zero (zero is not a valid
> event channel).
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init`
> 
> * `EVTCHNOP_expand`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init`
> 
> This call initializes a single VCPU's event channel data structures,
> adding one page for the event array.
> 
> A guest should call this during initial VCPU bring up (and on resume?).
> 
>     struct evtchnop_init {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frame for the domain.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand`
> 
> This call expands the event array for a VCPU by appended an additional
> page.
> 
> A guest should call this for all VCPUs when a new event channel is
> required and there is insufficient space in the current event array.
> 
> It is not possible to shrink the event array once it has been
> expanded.
> 
>     struct evtchnop_expand {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frames for the domain.
> EINVAL      The event array already has the maximum number of pages.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.
> 
> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> 
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.
> EINVAL      `priority` is outside the range 0 - 15.
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the maximum number of event channels a
> domain can bind.  The default for dom0 is unlimited.  Other domains
> default to 1024 events (requiring only a single page for their event
> array).
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_events;
>     };
> 
> Field         Purpose
> -----         -------
> `domid`       [in] The domain ID.
> `max_events`  [in] The maximum number of event channels that may be bound
>               to the domain.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 
> Memory Usage
> ------------
> 
> ### Event Arrays
> 
> Xen needs to map every domains' event array into its address space.
> The space reserved for these global mappings is limited to 1 GiB on
> x86-64 (262144 pages) and is shared with other users.
> 
> It is non-trivial to calculate the maximum number of VMs that can be
> supported as this depends on the system configuration (how many driver
> domains etc.) and VM configuration.  We can make some assuptions and
> derive an approximate limit.
> 
> Each page of the event array has space for 1024 events ($E_P$) so a
> regular domU will only require a single page.  Since event channels
> typically come in pairs, the upper bound on the total number of pages
> is $2 \times\text{number of VMs}$.
> 
> If the guests are further restricted in the number of event channels
> ($E_V$) then this upper bound can be reduced further.
> 
> The number of VMs ($V$) with a limit of $P$ total event array pages is:
> \begin{equation*}
> V = P \div \left(1 + \frac{E_V}{E_P}\right)
> \end{equation*}
> 
> Using only half the available pages and limiting guests to only 64
> events gives:
> \begin{eqnarray*}
> V & = & (262144 / 2) \div (1 + 64 / 1024) \\
>   & = & 123 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> Alternatively, we can consider a system with $D$ driver domains, each
> of which requires $E_D$ events, and a dom0 using the maximum number of
> pages (128).
> 
> \begin{eqnarray*}
> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> \end{eqnarray*}
> 
> With, for example, 16 driver domains each using the maximum number of pages:
> \begin{eqnarray*}
> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>    & = & 129 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> In summary, there is space to map the event arrays for over 100,000
> VMs.  This is more than the limit imposed by the 16 bit domain ID
> (~32,000 VMs).
> 
> ### Control Block
> 
> With $L$ priority levels and two 32-bit words for the head and tail
> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> for the control block is:
> \begin{eqnarray*}
> S & = & L \times 2 \times 4 \\
>   & = & 16 \times 2 \times 4 \\
>   & = & 128\text{ bytes}
> \end{eqnarray*}
> 
> There is more than enough space within `struct vcpu_info` for the
> control block while still keeping plenty of space for future use.
> 
> Low Level Design
> ================
> 
> In the pseudo code in this section, all memory accesses are atomic,
> including those to bit-fields within the event word.
> 
> These variables have a standard meaning:
> 
> Variable  Purpose
> --------  -------
> E         Event array.
> p         A specific event.
> H         The head index for a specific priority.
> T         The tail index for a specific priority.
> 
> These memory barriers are required:
> 
> Function  Purpose
> --------  -------
> mb()      Full (read/write) memory barrier
> 
> Raising an Event
> ----------------
> 
> When Xen raises an event it marks it pending and (if it is not masked)
> adds it tail of event queue.
> 
>     E[p].pending = 1
>     if not E[p].linked and not E[n].masked
>         E[p].linked = 1
>         E[p].link = 0
>         mb()
>         if H == 0
>             H = p
>         else
>             E[T].link = p
>         T = p
> 
> Concurrent access by Xen to the event queue must be protected by a
> per-event queue spin lock.
> 
> Consuming Events
> ----------------
> 
> The guests consumes events starting at the head until it reaches the
> tail.  Events in the queue that are not pending or are masked are
> consumed but not handled.
> 
>     while H != 0
>         p = H
>         H = E[p].link
>         if H == 0
>             mb()
>             H = E[p].link
>         E[H].linked = 0
>         if not E[p].masked
>             handle(p)
> 
> handle() clears `E[p].pending` and EOIs level-triggered PIRQs.
> 
>> Note: When the event queue contains a single event, removing the
>> event may race with Xen appending another event because the load of
>> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
>> the guest must recheck `E[p].link` if the list appeared empty.
> 
> Masking Events
> --------------
> 
> Events are masked by setting the masked bit.  If the event is pending
> and linked it does not need to be unlinked.
> 
>     E[p].masked = 1
> 
> Unmasking Events
> ----------------
> 
> Events are unmasked by the guest by clearing the masked bit.  If the
> event is pending the guest must call the event channel unmask
> hypercall so Xen can link the event into the correct event queue.
> 
>     E[p].masked = 0
>     if E[p].pending
>         hypercall(EVTCHN_unmask)
> 
> The expectation here is that unmasking a pending event will be rare,
> so the performance hit of the hypercall is minimal.
> 
>> Note: that after clearing the mask bit, the event may be raised and
>> thus it may already be linked by the time the hypercall is done.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 04 20:57:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 20: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 1U2T5j-0006dg-HR; Mon, 04 Feb 2013 20:56:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1U2T5i-0006db-78
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 20:56:38 +0000
Received: from [193.109.254.147:10837] by server-7.bemta-14.messagelabs.com id
	E3/F9-13581-58020115; Mon, 04 Feb 2013 20:56:37 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360011393!2762372!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 4 Feb 2013 20:56:34 -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;
	4 Feb 2013 20:56:34 -0000
Received: by mail-ee0-f45.google.com with SMTP id b57so3534073eek.18
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 12:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=3HErXseWa+h/FVuT0a+WadP5xKZEWYG+ibgDpDASD/A=;
	b=fIg7kQeM9vWIhZeDinCDQfAXWXMGCZM44ksI7J+21wie+LOaG2RtbrD5RzmQ6yWQAM
	K3xFkna4OClpsMP6ei1mBTj4rhSPQQ2V8EJ8/7qF/UUlPQO9qv3P87B0kJIZgANkT5Op
	otdHmZ7T5lzsjwfsYwSOyaqmyMDQ0C4w+4vH+m3vlP1PSZPkERbxgODMfDRXHeZJhZFi
	yIH6T4M5YZHoI+OBWlWebcRTNwq4NsAgSEa+2uspjdrsQhVRfSIMZtBcjlaBNYd7qd6B
	Hf35x4gbJUESA/L1GTw2bw5ymUmdqx9GfN9B90XFEk9+EgooAcVz/FyIJGiqmsjr1O23
	RxAw==
X-Received: by 10.14.201.69 with SMTP id a45mr75379350eeo.43.1360011393679;
	Mon, 04 Feb 2013 12:56:33 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-179-137.ip50.fastwebnet.it.
	[93.34.179.137])
	by mx.google.com with ESMTPS id 43sm29094767eed.10.2013.02.04.12.56.30
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 12:56:31 -0800 (PST)
Message-ID: <5110207B.4060501@gnu.org>
Date: Mon, 04 Feb 2013 21:56:27 +0100
From: Paolo Bonzini <bonzini@gnu.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Lance Taylor <iant@google.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
In-Reply-To: <CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 04/02/2013 17:46, Ian Lance Taylor ha scritto:
> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
> <frediano.ziglio@citrix.com> wrote:
>>
>> I imported some headers from Linux kernel which mainly came from
>> gcov-io.h and the structures used internally by GCC.
>>
>> Our problem is currently about the license. In gcov-io.h is stated that
>> license is mainly GPL2 which the exception that linking the "library"
>> with other files does not cause these files to be GPL2. Now however I'm
>> not linking to any library but just using the structure declaration
>> inside the header to produce a blob that is currently converted into GCC
>> files by an external utility (Xen has not file system so we extract
>> coverage information).
>>
>> It's not a problem to use these headers/structure from Xen (which is
>> GPL2) but we'd like to have these defines in our public include headers.
>> The license however of these headers is quite open and allow to be used
>> for instance in commercial programs. How the license would affect these
>> programs?
>>
>> Another question we have is the stability of these structures. Can we
>> just check the version field of gcov_info to make sure that the internal
>> structure is not changed or is it expected that even this field would
>> change (for instance position or size inside the structure) ?
> 
> You neglected to say which version of GCC you are using.  In current
> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
> Library Exception 3.1
> (http://www.gnu.org/licenses/gcc-exception-3.1.html).

Would it make sense to release the header file under a permissive
license or even public domain?

The information there is just ABI, it's dubious that it is copyrightable
at all.  If two colleagues of Frediano's did a clean-room reverse
engineering, the result would really be indistiguishable from the original.

Paolo


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 20:57:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 20: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 1U2T5j-0006dg-HR; Mon, 04 Feb 2013 20:56:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1U2T5i-0006db-78
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 20:56:38 +0000
Received: from [193.109.254.147:10837] by server-7.bemta-14.messagelabs.com id
	E3/F9-13581-58020115; Mon, 04 Feb 2013 20:56:37 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360011393!2762372!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 4 Feb 2013 20:56:34 -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;
	4 Feb 2013 20:56:34 -0000
Received: by mail-ee0-f45.google.com with SMTP id b57so3534073eek.18
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 12:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=3HErXseWa+h/FVuT0a+WadP5xKZEWYG+ibgDpDASD/A=;
	b=fIg7kQeM9vWIhZeDinCDQfAXWXMGCZM44ksI7J+21wie+LOaG2RtbrD5RzmQ6yWQAM
	K3xFkna4OClpsMP6ei1mBTj4rhSPQQ2V8EJ8/7qF/UUlPQO9qv3P87B0kJIZgANkT5Op
	otdHmZ7T5lzsjwfsYwSOyaqmyMDQ0C4w+4vH+m3vlP1PSZPkERbxgODMfDRXHeZJhZFi
	yIH6T4M5YZHoI+OBWlWebcRTNwq4NsAgSEa+2uspjdrsQhVRfSIMZtBcjlaBNYd7qd6B
	Hf35x4gbJUESA/L1GTw2bw5ymUmdqx9GfN9B90XFEk9+EgooAcVz/FyIJGiqmsjr1O23
	RxAw==
X-Received: by 10.14.201.69 with SMTP id a45mr75379350eeo.43.1360011393679;
	Mon, 04 Feb 2013 12:56:33 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-179-137.ip50.fastwebnet.it.
	[93.34.179.137])
	by mx.google.com with ESMTPS id 43sm29094767eed.10.2013.02.04.12.56.30
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 12:56:31 -0800 (PST)
Message-ID: <5110207B.4060501@gnu.org>
Date: Mon, 04 Feb 2013 21:56:27 +0100
From: Paolo Bonzini <bonzini@gnu.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Lance Taylor <iant@google.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
In-Reply-To: <CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 04/02/2013 17:46, Ian Lance Taylor ha scritto:
> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
> <frediano.ziglio@citrix.com> wrote:
>>
>> I imported some headers from Linux kernel which mainly came from
>> gcov-io.h and the structures used internally by GCC.
>>
>> Our problem is currently about the license. In gcov-io.h is stated that
>> license is mainly GPL2 which the exception that linking the "library"
>> with other files does not cause these files to be GPL2. Now however I'm
>> not linking to any library but just using the structure declaration
>> inside the header to produce a blob that is currently converted into GCC
>> files by an external utility (Xen has not file system so we extract
>> coverage information).
>>
>> It's not a problem to use these headers/structure from Xen (which is
>> GPL2) but we'd like to have these defines in our public include headers.
>> The license however of these headers is quite open and allow to be used
>> for instance in commercial programs. How the license would affect these
>> programs?
>>
>> Another question we have is the stability of these structures. Can we
>> just check the version field of gcov_info to make sure that the internal
>> structure is not changed or is it expected that even this field would
>> change (for instance position or size inside the structure) ?
> 
> You neglected to say which version of GCC you are using.  In current
> GCC the header file gcov-io.h is under GPLv3 with the GCC Runtime
> Library Exception 3.1
> (http://www.gnu.org/licenses/gcc-exception-3.1.html).

Would it make sense to release the header file under a permissive
license or even public domain?

The information there is just ABI, it's dubious that it is copyrightable
at all.  If two colleagues of Frediano's did a clean-room reverse
engineering, the result would really be indistiguishable from the original.

Paolo


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 21:08:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 21:08: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 1U2TGm-0006sP-N7; Mon, 04 Feb 2013 21:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2TGl-0006sK-5t
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 21:08:03 +0000
Received: from [85.158.137.99:56186] by server-8.bemta-3.messagelabs.com id
	8E/8C-25687-23320115; Mon, 04 Feb 2013 21:08:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360012079!14561322!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11807 invoked from network); 4 Feb 2013 21:08:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 21:08:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="5923232"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 21:07:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 16:07:56 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2TGe-0004jI-Ao;
	Mon, 04 Feb 2013 21:07:56 +0000
Message-ID: <1360012076.7477.132.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 4 Feb 2013 21:07:56 +0000
In-Reply-To: <510FF54E.1070706@citrix.com>
References: <510FF54E.1070706@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nice work and interesting reading for the night! please see inline
comments.

On Mon, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> Hi,
> 
> Here is a design for a scalable event channel ABI for Xen.  It has a
> number of benefits over the design currently being proposed by Wei Lui.
> 
> * More event channels (>100,000).

This is not a benefit over the 3-level design. ;-)

> * 16 event priorities.
> * Reduced memory requirements (only 1 additional page per domU).
> * The use of FIFOs for events ensures fairness, whereas it is difficult
> to reason about the fairness with the current bitmap system.

These are! ;-)

> The PDF version is easier to read and has diagrams and readable maths
> but the original markdown format document is included below (for ease of
> commenting).
> 
> http://xenbits.xen.org/people/dvrabel/event-channels-A.pdf
> 
> Introduction
> ============
> 
> Purpose
> -------
> 
> Xen uses event channels to signal events (interrupts) to (fully or
> partially) paravirtualized guests.  The current event channel ABI
> provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
> (for 64-bit guests) event channels.  This is limiting scalability as
> support for more VMs, VCPUs and devices is required.
> 
> The existing ABI does not easily allow events to have different
> priorities.  Current Linux kernels prioritize the timer event by
> special casing this but this is not generalizable to more events.
> Event priorities may be useful for prioritizing MMIO emulation
> requests over bulk data traffic (such as network or disk).
> 
> This design replaces the existing event channel ABI with one that:
> 
> - is scalable to more than 100,000 event channels, with scope for
> increasing this further with minimal ABI changes.
> 
> - allows guests to use up-to 16 different event priorities.
> 
> System Overview
> ---------------
> 
> [FIXME: diagram showing Xen and guest and shared memory block for events?]
> 
> Design Map
> ----------
> 
> A new event channel ABI requires changes to Xen and the guest kernels.
> 
> References
> ----------
> 
> [FIXME: link to alternate proposal?]
> 
> Design Considerations
> =====================
> 
> Assumptions
> -----------
> 
> * Atomic read-modify-write of 32-bit words is possible on all
>   supported platforms.  This can be with a linked-load /
>   store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
>   (e.g., x86's cmpxchg).
> 
> Constraints
> -----------
> 
> * The existing ABI must continue to be useable.  Compatibilty with
>   existing guests is mandatory.
> 
> Risks and Volatile Areas
> ------------------------
> 
> * Should the 3-level proposal be merged into Xen then this design does
>   not offer enough improvements to warrant the cost of maintaining
>   three different event channel ABIs in Xen and guest kernels.
> 
> * The performance of some operations may be decreased.  Specifically,
>   retriggering an event now always requires a hypercall.
> 
> Architecture
> ============
> 
> Overview
> --------
> 
> The event channel ABI uses a data structure that is shared between Xen
> and the guest.  Access to the structure is done with lock-less
> operations (except for some less common operations where the guest
> must use a hypercall).  The guest is responsible for allocating this
> structure and registering it with Xen during VCPU bring-up.

Just for completeness, legacy guests might not register vcpu info - they
just use those vcpu info inside shared info. And a modern guest might
use vcpu info inside shared info along with registered per-vcpu vcpu
info if registrations fail half way.

But this will not be a big problem for this design.

> Events are reported to a guest's VCPU using a FIFO queue.  There is a
> queue for each priority level and each VCPU.
> 
> Each event has a _pending_ and a _masked_ bit.  The pending bit
> indicates the event has been raised.  The masked bit is used by the
> guest to prevent delivery of that specific event.
> 
> 
> High Level Design
> =================
> 
> Shared Event Data Structure
> ---------------------------
> 
> The shared event data structure has a per-domain _event array_, and a
> per-VCPU _control block_.
> 
> - _event array_: A logical array of event words (one per event
>   channel) which contains the pending and mask bits and the link index
>   for next event in the queue.
> 
> ![\label{fig_event-word}Event Array Word](event-word.pdf)
> 
> - _control block_: This contains the head and tail indexes for each
>   priority level.  Each VCPU has its own control block and this is
>   contained in the existing `struct vcpu_info`.
> 
> The pages within the event array need not be physically nor virtually
> contiguous, but the guest or Xen may make the virtually contiguous for
> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> Linux.  Pages are added by the guest as required by the number of
> bound event channels.
> 
> Only 17 bits are currently defined for the LINK field, allowing 2^17^
> (131,072) events.  This limit can be trivially increased without any
> other changes to the ABI.  Bits [28:17] are reserved for future
> expansion or for other uses.
> 
> Event State Machine
> -------------------
> 
> Event channels are bound to a domain using the existing ABI.
> 
> A bound event may be in one of three main states.
> 
> State    Abbrev.  Meaning
> -----    -------  -------
> BOUND    B        The event is bound but not pending.
> PENDING  P        The event has been raised and not yet acknowledged.
> LINKED   L        The event is on an event queue.
> 
> Additionally, events may be UNMASKED or MASKED (M).
> 
> ![\label{events_sm}Event State Machine](event-sm.pdf)
> 
> The state of an event is tracked using 3 bits within the event word.
> the M (masked), P (pending) and L (linked) bits.  Only state
> transitions that change a single bit are valid.
> 

Where is the "priority" information stored? I think it should be
somewhere inside Xen, right? I presume a field in struct evtchn?

> Event Queues
> ------------
> 
> The event queues use a singly-linked list of event array words (see
> figure \ref{fig_event-word} and \ref{fig_event-queue}).
> 
> ![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)
> 
> Each event queue has a head and tail index stored in the control
> block.  The head index is the index of the first element in the queue.
> The tail index is the last element in the queue.  Every element within
> the queue has the L bit set.
> 
> The LINK field in the event word indexes the next event in the queue.
> LINK is zero for the last word in the queue.
> 
> The queue is empty when the head index is zero (zero is not a valid
> event channel).
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init`
> 
> * `EVTCHNOP_expand`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init`
> 
> This call initializes a single VCPU's event channel data structures,
> adding one page for the event array.
> 

I think the registration for new event channels should always be done in
a batch. If not then you need to provide another OP to rollback previous
registered ones.

> A guest should call this during initial VCPU bring up (and on resume?).
> 
>     struct evtchnop_init {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frame for the domain.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand`
> 
> This call expands the event array for a VCPU by appended an additional
> page.
> 
> A guest should call this for all VCPUs when a new event channel is
> required and there is insufficient space in the current event array.
> 
> It is not possible to shrink the event array once it has been
> expanded.
> 
>     struct evtchnop_expand {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frames for the domain.
> EINVAL      The event array already has the maximum number of pages.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.
> 
> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.
> EINVAL      `priority` is outside the range 0 - 15.
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the maximum number of event channels a
> domain can bind.  The default for dom0 is unlimited.  Other domains
> default to 1024 events (requiring only a single page for their event
> array).
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_events;
>     };
> 
> Field         Purpose
> -----         -------
> `domid`       [in] The domain ID.
> `max_events`  [in] The maximum number of event channels that may be bound
>               to the domain.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 

Is shrinking max_events legal? Should also deal with max_events >
design_limit case.

> Memory Usage
> ------------
> 
> ### Event Arrays
> 
> Xen needs to map every domains' event array into its address space.
> The space reserved for these global mappings is limited to 1 GiB on
> x86-64 (262144 pages) and is shared with other users.
> 
> It is non-trivial to calculate the maximum number of VMs that can be
> supported as this depends on the system configuration (how many driver
> domains etc.) and VM configuration.  We can make some assuptions and
> derive an approximate limit.
> 
> Each page of the event array has space for 1024 events ($E_P$) so a
> regular domU will only require a single page.  Since event channels
> typically come in pairs, the upper bound on the total number of pages
                               ^^^^^
                               upper or lower?

> is $2 \times\text{number of VMs}$.
> 
> If the guests are further restricted in the number of event channels
> ($E_V$) then this upper bound can be reduced further.
> 

Can this bound really be reduced? Can you map memory on non-page
granularity?

> The number of VMs ($V$) with a limit of $P$ total event array pages is:
> \begin{equation*}
> V = P \div \left(1 + \frac{E_V}{E_P}\right)
> \end{equation*}
> 
> Using only half the available pages and limiting guests to only 64
> events gives:
> \begin{eqnarray*}
> V & = & (262144 / 2) \div (1 + 64 / 1024) \\
>   & = & 123 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> Alternatively, we can consider a system with $D$ driver domains, each
> of which requires $E_D$ events, and a dom0 using the maximum number of
> pages (128).
> 
> \begin{eqnarray*}
> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> \end{eqnarray*}
> 
> With, for example, 16 driver domains each using the maximum number of pages:
> \begin{eqnarray*}
> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>    & = & 129 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> In summary, there is space to map the event arrays for over 100,000
> VMs.  This is more than the limit imposed by the 16 bit domain ID
> (~32,000 VMs).
> 
> ### Control Block
> 
> With $L$ priority levels and two 32-bit words for the head and tail
> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> for the control block is:
> \begin{eqnarray*}
> S & = & L \times 2 \times 4 \\
>   & = & 16 \times 2 \times 4 \\
>   & = & 128\text{ bytes}
> \end{eqnarray*}
> 
> There is more than enough space within `struct vcpu_info` for the
> control block while still keeping plenty of space for future use.
> 
> Low Level Design
> ================
> 
> In the pseudo code in this section, all memory accesses are atomic,
> including those to bit-fields within the event word.
> 
> These variables have a standard meaning:
> 
> Variable  Purpose
> --------  -------
> E         Event array.
> p         A specific event.
> H         The head index for a specific priority.
> T         The tail index for a specific priority.
> 
> These memory barriers are required:
> 
> Function  Purpose
> --------  -------
> mb()      Full (read/write) memory barrier
> 
> Raising an Event
> ----------------
> 
> When Xen raises an event it marks it pending and (if it is not masked)
> adds it tail of event queue.
> 
>     E[p].pending = 1
>     if not E[p].linked and not E[n].masked
>         E[p].linked = 1
>         E[p].link = 0
>         mb()
>         if H == 0
>             H = p
>         else
>             E[T].link = p
>         T = p
> 
> Concurrent access by Xen to the event queue must be protected by a
> per-event queue spin lock.
> 

I presume "E[n]" in the pseudo code is "E[p]"?

Is this spin lock really a good idea? How many threads / cpus will spin
on this lock? As [0] shows, contention on spin lock incurs heavy
performance penalty.

[0] https://lwn.net/Articles/530458/

> Consuming Events
> ----------------
> 
> The guests consumes events starting at the head until it reaches the
> tail.  Events in the queue that are not pending or are masked are
> consumed but not handled.
> 
>     while H != 0
>         p = H
>         H = E[p].link
>         if H == 0
>             mb()
>             H = E[p].link
>         E[H].linked = 0
>         if not E[p].masked
>             handle(p)
> 
> handle() clears `E[p].pending` and EOIs level-triggered PIRQs.
> 

How to synchronize access to the array and control blocks between Xen
and guest? I'm afraid I have no knowledge of a xen-guest spin lock...

AFAICT at least inter-domain event channel is a corner case in your
design - cpu A is handling events in Linux kernel while cpu B tries to
raise a inter-domain port to A. If this is not a problem, please also
clarify a bit. (sorry I'm a bit fuzzy after a day's work)

> > Note: When the event queue contains a single event, removing the
> > event may race with Xen appending another event because the load of
> > `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> > the guest must recheck `E[p].link` if the list appeared empty.
> 
> Masking Events
> --------------
> 
> Events are masked by setting the masked bit.  If the event is pending
> and linked it does not need to be unlinked.
> 
>     E[p].masked = 1
> 
> Unmasking Events
> ----------------
> 
> Events are unmasked by the guest by clearing the masked bit.  If the
> event is pending the guest must call the event channel unmask
> hypercall so Xen can link the event into the correct event queue.
> 
>     E[p].masked = 0
>     if E[p].pending
>         hypercall(EVTCHN_unmask)
> 
> The expectation here is that unmasking a pending event will be rare,
> so the performance hit of the hypercall is minimal.
> 

Currently unmask a "remote" port requires issuing hyercall as well, so
if unmasking is not very frequent, this is not a big problem.

But please take some interrupt-intensive workloads into consideration.
For example, 1G nic (e1000) even with NAPI enabled can generate 27k+
intrs per second under high packet load [1], 10G nic can surely generate
more. Can you give estimation on the performance hit on the context
switch?

[1] http://www.linuxfoundation.org/collaborate/workgroups/networking/napi

> > Note: that after clearing the mask bit, the event may be raised and
> > thus it may already be linked by the time the hypercall is done.

Even if the event has already been linked before you finish the
hypercall, you would still need to get hold of the a lock to serialize
access to event structure for checking, right? Or a test_bit on linked
field is sufficient? I think you need to write some pseudo code for this
as well.


Thanks
Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 21:08:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 21:08: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 1U2TGm-0006sP-N7; Mon, 04 Feb 2013 21:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2TGl-0006sK-5t
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 21:08:03 +0000
Received: from [85.158.137.99:56186] by server-8.bemta-3.messagelabs.com id
	8E/8C-25687-23320115; Mon, 04 Feb 2013 21:08:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360012079!14561322!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDEzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11807 invoked from network); 4 Feb 2013 21:08:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 21:08:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="5923232"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	04 Feb 2013 21:07:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 4 Feb 2013 16:07:56 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2TGe-0004jI-Ao;
	Mon, 04 Feb 2013 21:07:56 +0000
Message-ID: <1360012076.7477.132.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 4 Feb 2013 21:07:56 +0000
In-Reply-To: <510FF54E.1070706@citrix.com>
References: <510FF54E.1070706@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nice work and interesting reading for the night! please see inline
comments.

On Mon, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> Hi,
> 
> Here is a design for a scalable event channel ABI for Xen.  It has a
> number of benefits over the design currently being proposed by Wei Lui.
> 
> * More event channels (>100,000).

This is not a benefit over the 3-level design. ;-)

> * 16 event priorities.
> * Reduced memory requirements (only 1 additional page per domU).
> * The use of FIFOs for events ensures fairness, whereas it is difficult
> to reason about the fairness with the current bitmap system.

These are! ;-)

> The PDF version is easier to read and has diagrams and readable maths
> but the original markdown format document is included below (for ease of
> commenting).
> 
> http://xenbits.xen.org/people/dvrabel/event-channels-A.pdf
> 
> Introduction
> ============
> 
> Purpose
> -------
> 
> Xen uses event channels to signal events (interrupts) to (fully or
> partially) paravirtualized guests.  The current event channel ABI
> provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
> (for 64-bit guests) event channels.  This is limiting scalability as
> support for more VMs, VCPUs and devices is required.
> 
> The existing ABI does not easily allow events to have different
> priorities.  Current Linux kernels prioritize the timer event by
> special casing this but this is not generalizable to more events.
> Event priorities may be useful for prioritizing MMIO emulation
> requests over bulk data traffic (such as network or disk).
> 
> This design replaces the existing event channel ABI with one that:
> 
> - is scalable to more than 100,000 event channels, with scope for
> increasing this further with minimal ABI changes.
> 
> - allows guests to use up-to 16 different event priorities.
> 
> System Overview
> ---------------
> 
> [FIXME: diagram showing Xen and guest and shared memory block for events?]
> 
> Design Map
> ----------
> 
> A new event channel ABI requires changes to Xen and the guest kernels.
> 
> References
> ----------
> 
> [FIXME: link to alternate proposal?]
> 
> Design Considerations
> =====================
> 
> Assumptions
> -----------
> 
> * Atomic read-modify-write of 32-bit words is possible on all
>   supported platforms.  This can be with a linked-load /
>   store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
>   (e.g., x86's cmpxchg).
> 
> Constraints
> -----------
> 
> * The existing ABI must continue to be useable.  Compatibilty with
>   existing guests is mandatory.
> 
> Risks and Volatile Areas
> ------------------------
> 
> * Should the 3-level proposal be merged into Xen then this design does
>   not offer enough improvements to warrant the cost of maintaining
>   three different event channel ABIs in Xen and guest kernels.
> 
> * The performance of some operations may be decreased.  Specifically,
>   retriggering an event now always requires a hypercall.
> 
> Architecture
> ============
> 
> Overview
> --------
> 
> The event channel ABI uses a data structure that is shared between Xen
> and the guest.  Access to the structure is done with lock-less
> operations (except for some less common operations where the guest
> must use a hypercall).  The guest is responsible for allocating this
> structure and registering it with Xen during VCPU bring-up.

Just for completeness, legacy guests might not register vcpu info - they
just use those vcpu info inside shared info. And a modern guest might
use vcpu info inside shared info along with registered per-vcpu vcpu
info if registrations fail half way.

But this will not be a big problem for this design.

> Events are reported to a guest's VCPU using a FIFO queue.  There is a
> queue for each priority level and each VCPU.
> 
> Each event has a _pending_ and a _masked_ bit.  The pending bit
> indicates the event has been raised.  The masked bit is used by the
> guest to prevent delivery of that specific event.
> 
> 
> High Level Design
> =================
> 
> Shared Event Data Structure
> ---------------------------
> 
> The shared event data structure has a per-domain _event array_, and a
> per-VCPU _control block_.
> 
> - _event array_: A logical array of event words (one per event
>   channel) which contains the pending and mask bits and the link index
>   for next event in the queue.
> 
> ![\label{fig_event-word}Event Array Word](event-word.pdf)
> 
> - _control block_: This contains the head and tail indexes for each
>   priority level.  Each VCPU has its own control block and this is
>   contained in the existing `struct vcpu_info`.
> 
> The pages within the event array need not be physically nor virtually
> contiguous, but the guest or Xen may make the virtually contiguous for
> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> Linux.  Pages are added by the guest as required by the number of
> bound event channels.
> 
> Only 17 bits are currently defined for the LINK field, allowing 2^17^
> (131,072) events.  This limit can be trivially increased without any
> other changes to the ABI.  Bits [28:17] are reserved for future
> expansion or for other uses.
> 
> Event State Machine
> -------------------
> 
> Event channels are bound to a domain using the existing ABI.
> 
> A bound event may be in one of three main states.
> 
> State    Abbrev.  Meaning
> -----    -------  -------
> BOUND    B        The event is bound but not pending.
> PENDING  P        The event has been raised and not yet acknowledged.
> LINKED   L        The event is on an event queue.
> 
> Additionally, events may be UNMASKED or MASKED (M).
> 
> ![\label{events_sm}Event State Machine](event-sm.pdf)
> 
> The state of an event is tracked using 3 bits within the event word.
> the M (masked), P (pending) and L (linked) bits.  Only state
> transitions that change a single bit are valid.
> 

Where is the "priority" information stored? I think it should be
somewhere inside Xen, right? I presume a field in struct evtchn?

> Event Queues
> ------------
> 
> The event queues use a singly-linked list of event array words (see
> figure \ref{fig_event-word} and \ref{fig_event-queue}).
> 
> ![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)
> 
> Each event queue has a head and tail index stored in the control
> block.  The head index is the index of the first element in the queue.
> The tail index is the last element in the queue.  Every element within
> the queue has the L bit set.
> 
> The LINK field in the event word indexes the next event in the queue.
> LINK is zero for the last word in the queue.
> 
> The queue is empty when the head index is zero (zero is not a valid
> event channel).
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init`
> 
> * `EVTCHNOP_expand`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init`
> 
> This call initializes a single VCPU's event channel data structures,
> adding one page for the event array.
> 

I think the registration for new event channels should always be done in
a batch. If not then you need to provide another OP to rollback previous
registered ones.

> A guest should call this during initial VCPU bring up (and on resume?).
> 
>     struct evtchnop_init {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frame for the domain.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand`
> 
> This call expands the event array for a VCPU by appended an additional
> page.
> 
> A guest should call this for all VCPUs when a new event channel is
> required and there is insufficient space in the current event array.
> 
> It is not possible to shrink the event array once it has been
> expanded.
> 
>     struct evtchnop_expand {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frames for the domain.
> EINVAL      The event array already has the maximum number of pages.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.
> 
> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.
> EINVAL      `priority` is outside the range 0 - 15.
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the maximum number of event channels a
> domain can bind.  The default for dom0 is unlimited.  Other domains
> default to 1024 events (requiring only a single page for their event
> array).
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_events;
>     };
> 
> Field         Purpose
> -----         -------
> `domid`       [in] The domain ID.
> `max_events`  [in] The maximum number of event channels that may be bound
>               to the domain.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 

Is shrinking max_events legal? Should also deal with max_events >
design_limit case.

> Memory Usage
> ------------
> 
> ### Event Arrays
> 
> Xen needs to map every domains' event array into its address space.
> The space reserved for these global mappings is limited to 1 GiB on
> x86-64 (262144 pages) and is shared with other users.
> 
> It is non-trivial to calculate the maximum number of VMs that can be
> supported as this depends on the system configuration (how many driver
> domains etc.) and VM configuration.  We can make some assuptions and
> derive an approximate limit.
> 
> Each page of the event array has space for 1024 events ($E_P$) so a
> regular domU will only require a single page.  Since event channels
> typically come in pairs, the upper bound on the total number of pages
                               ^^^^^
                               upper or lower?

> is $2 \times\text{number of VMs}$.
> 
> If the guests are further restricted in the number of event channels
> ($E_V$) then this upper bound can be reduced further.
> 

Can this bound really be reduced? Can you map memory on non-page
granularity?

> The number of VMs ($V$) with a limit of $P$ total event array pages is:
> \begin{equation*}
> V = P \div \left(1 + \frac{E_V}{E_P}\right)
> \end{equation*}
> 
> Using only half the available pages and limiting guests to only 64
> events gives:
> \begin{eqnarray*}
> V & = & (262144 / 2) \div (1 + 64 / 1024) \\
>   & = & 123 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> Alternatively, we can consider a system with $D$ driver domains, each
> of which requires $E_D$ events, and a dom0 using the maximum number of
> pages (128).
> 
> \begin{eqnarray*}
> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> \end{eqnarray*}
> 
> With, for example, 16 driver domains each using the maximum number of pages:
> \begin{eqnarray*}
> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>    & = & 129 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> In summary, there is space to map the event arrays for over 100,000
> VMs.  This is more than the limit imposed by the 16 bit domain ID
> (~32,000 VMs).
> 
> ### Control Block
> 
> With $L$ priority levels and two 32-bit words for the head and tail
> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> for the control block is:
> \begin{eqnarray*}
> S & = & L \times 2 \times 4 \\
>   & = & 16 \times 2 \times 4 \\
>   & = & 128\text{ bytes}
> \end{eqnarray*}
> 
> There is more than enough space within `struct vcpu_info` for the
> control block while still keeping plenty of space for future use.
> 
> Low Level Design
> ================
> 
> In the pseudo code in this section, all memory accesses are atomic,
> including those to bit-fields within the event word.
> 
> These variables have a standard meaning:
> 
> Variable  Purpose
> --------  -------
> E         Event array.
> p         A specific event.
> H         The head index for a specific priority.
> T         The tail index for a specific priority.
> 
> These memory barriers are required:
> 
> Function  Purpose
> --------  -------
> mb()      Full (read/write) memory barrier
> 
> Raising an Event
> ----------------
> 
> When Xen raises an event it marks it pending and (if it is not masked)
> adds it tail of event queue.
> 
>     E[p].pending = 1
>     if not E[p].linked and not E[n].masked
>         E[p].linked = 1
>         E[p].link = 0
>         mb()
>         if H == 0
>             H = p
>         else
>             E[T].link = p
>         T = p
> 
> Concurrent access by Xen to the event queue must be protected by a
> per-event queue spin lock.
> 

I presume "E[n]" in the pseudo code is "E[p]"?

Is this spin lock really a good idea? How many threads / cpus will spin
on this lock? As [0] shows, contention on spin lock incurs heavy
performance penalty.

[0] https://lwn.net/Articles/530458/

> Consuming Events
> ----------------
> 
> The guests consumes events starting at the head until it reaches the
> tail.  Events in the queue that are not pending or are masked are
> consumed but not handled.
> 
>     while H != 0
>         p = H
>         H = E[p].link
>         if H == 0
>             mb()
>             H = E[p].link
>         E[H].linked = 0
>         if not E[p].masked
>             handle(p)
> 
> handle() clears `E[p].pending` and EOIs level-triggered PIRQs.
> 

How to synchronize access to the array and control blocks between Xen
and guest? I'm afraid I have no knowledge of a xen-guest spin lock...

AFAICT at least inter-domain event channel is a corner case in your
design - cpu A is handling events in Linux kernel while cpu B tries to
raise a inter-domain port to A. If this is not a problem, please also
clarify a bit. (sorry I'm a bit fuzzy after a day's work)

> > Note: When the event queue contains a single event, removing the
> > event may race with Xen appending another event because the load of
> > `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> > the guest must recheck `E[p].link` if the list appeared empty.
> 
> Masking Events
> --------------
> 
> Events are masked by setting the masked bit.  If the event is pending
> and linked it does not need to be unlinked.
> 
>     E[p].masked = 1
> 
> Unmasking Events
> ----------------
> 
> Events are unmasked by the guest by clearing the masked bit.  If the
> event is pending the guest must call the event channel unmask
> hypercall so Xen can link the event into the correct event queue.
> 
>     E[p].masked = 0
>     if E[p].pending
>         hypercall(EVTCHN_unmask)
> 
> The expectation here is that unmasking a pending event will be rare,
> so the performance hit of the hypercall is minimal.
> 

Currently unmask a "remote" port requires issuing hyercall as well, so
if unmasking is not very frequent, this is not a big problem.

But please take some interrupt-intensive workloads into consideration.
For example, 1G nic (e1000) even with NAPI enabled can generate 27k+
intrs per second under high packet load [1], 10G nic can surely generate
more. Can you give estimation on the performance hit on the context
switch?

[1] http://www.linuxfoundation.org/collaborate/workgroups/networking/napi

> > Note: that after clearing the mask bit, the event may be raised and
> > thus it may already be linked by the time the hypercall is done.

Even if the event has already been linked before you finish the
hypercall, you would still need to get hold of the a lock to serialize
access to event structure for checking, right? Or a test_bit on linked
field is sufficient? I think you need to write some pseudo code for this
as well.


Thanks
Wei.


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

From xen-devel-bounces@lists.xen.org Mon Feb 04 21:24:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 21:24: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 1U2TWh-00079E-8t; Mon, 04 Feb 2013 21:24:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iant@google.com>) id 1U2TWe-000799-Rn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 21:24:29 +0000
Received: from [85.158.138.51:31856] by server-11.bemta-3.messagelabs.com id
	C1/75-10249-70720115; Mon, 04 Feb 2013 21:24:23 +0000
X-Env-Sender: iant@google.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360013061!22095968!1
X-Originating-IP: [209.85.219.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28256 invoked from network); 4 Feb 2013 21:24:22 -0000
Received: from mail-oa0-f41.google.com (HELO mail-oa0-f41.google.com)
	(209.85.219.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 21:24:22 -0000
Received: by mail-oa0-f41.google.com with SMTP id i10so7065253oag.28
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 13:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=cBOEj1JFb0L6uDogug5xLum12ap7nOXqN4zCCfOEDpo=;
	b=ZwgrKdMPJxJ1JO/f7WuQdiw8LBzZX7T5CjtbyAz/9ZMt7StXGwlbaWg2nayPlt4a71
	Rk+pyrHo8ACzVbzN+4FSF/y5cq6GGfIvhxkUTFTgafGgVBMD+Agv/kowQU8N2VFs6DZ4
	LxVhAuUyyGEEvxtEUuGfg0uO98leGayBfUI33fojPZFd6hYdbqSONE/YkrYQ1Q+gbzBs
	ziZpoUUkcRw9M0UXu4tuTP3EYkPufOAIS62yrIlM6ASU5ugwryobhHS/0B/+dGNMm5by
	bNLJn9stbgCEV1advAHAZCuwE1TBDszaSrLPMhGlRvuvarg1o2AKYWTwmFp5bEYRVmwf
	XlLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=cBOEj1JFb0L6uDogug5xLum12ap7nOXqN4zCCfOEDpo=;
	b=iG6PVyGtktcUeGRJ0kGpqjbOEYwwuIXFCpU8cawhx0s32si7Zb0gKWuVV9/gFubxkD
	ZDi5lvjJKWw9QhCy6dpyUIdOoX9t+C7RvBVT72ispSOksgd/kSTjdeJc4cYJEL3bGrkO
	hEh1vgIcIfix1TZTjLMXUwtJt6YvNrs6n2/mPGMG/hOwlYBc6Cqs4CVlbAKXn7gVyvG3
	x4uGgiQ6OtubMAGLUziFhXgwKtkTQoPHC/NGNAx32DwgZ2gq36cscVeQnF9WqVtMGLSP
	DWxVLqIxQkBrm04buuMo9qLrmM7JqImip2mZvhLhpoGAI7ln8bmer4Tyqs2osHfSUiNG
	Bneg==
MIME-Version: 1.0
X-Received: by 10.60.6.105 with SMTP id z9mr3879055oez.52.1360013060510; Mon,
	04 Feb 2013 13:24:20 -0800 (PST)
Received: by 10.182.23.39 with HTTP; Mon, 4 Feb 2013 13:24:20 -0800 (PST)
In-Reply-To: <5110207B.4060501@gnu.org>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<5110207B.4060501@gnu.org>
Date: Mon, 4 Feb 2013 13:24:20 -0800
Message-ID: <CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.gmail.com>
From: Ian Lance Taylor <iant@google.com>
To: Paolo Bonzini <bonzini@gnu.org>
X-Gm-Message-State: ALoCoQmeWmCnOzzFH0Lu78YxneaIulp4mVpCKotHxxqBGvKLc7bJgy9+tOpVWKBV+lrfZQBopES5i/6NrhmxfmL7fJ/get6XV4FivfR3mb+9f+VjSSkI1ZP1t75WCNZei1uvtZETkH8vcthtbma8FLXNB/bGdUIQDzzErexzrOcmr3mxOHcTSGwwNLyTye0aAm6ONxAQLccq
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 4, 2013 at 12:56 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> Would it make sense to release the header file under a permissive
> license or even public domain?
>
> The information there is just ABI, it's dubious that it is copyrightable
> at all.  If two colleagues of Frediano's did a clean-room reverse
> engineering, the result would really be indistiguishable from the original.

I agree that the information in gcov-io.h is almost certainly uncopyrightable.

But since it's under the GCC Runtime Library Exception, which applies
to approximately every program compiled by GCC, I don't think it makes
much difference one way or another.  I'm not opposed to asking the FSF
to relicense the file, I just don't think it matters.

Ian

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 21:24:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 21:24: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 1U2TWh-00079E-8t; Mon, 04 Feb 2013 21:24:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iant@google.com>) id 1U2TWe-000799-Rn
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 21:24:29 +0000
Received: from [85.158.138.51:31856] by server-11.bemta-3.messagelabs.com id
	C1/75-10249-70720115; Mon, 04 Feb 2013 21:24:23 +0000
X-Env-Sender: iant@google.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360013061!22095968!1
X-Originating-IP: [209.85.219.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28256 invoked from network); 4 Feb 2013 21:24:22 -0000
Received: from mail-oa0-f41.google.com (HELO mail-oa0-f41.google.com)
	(209.85.219.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 21:24:22 -0000
Received: by mail-oa0-f41.google.com with SMTP id i10so7065253oag.28
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 13:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=cBOEj1JFb0L6uDogug5xLum12ap7nOXqN4zCCfOEDpo=;
	b=ZwgrKdMPJxJ1JO/f7WuQdiw8LBzZX7T5CjtbyAz/9ZMt7StXGwlbaWg2nayPlt4a71
	Rk+pyrHo8ACzVbzN+4FSF/y5cq6GGfIvhxkUTFTgafGgVBMD+Agv/kowQU8N2VFs6DZ4
	LxVhAuUyyGEEvxtEUuGfg0uO98leGayBfUI33fojPZFd6hYdbqSONE/YkrYQ1Q+gbzBs
	ziZpoUUkcRw9M0UXu4tuTP3EYkPufOAIS62yrIlM6ASU5ugwryobhHS/0B/+dGNMm5by
	bNLJn9stbgCEV1advAHAZCuwE1TBDszaSrLPMhGlRvuvarg1o2AKYWTwmFp5bEYRVmwf
	XlLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=cBOEj1JFb0L6uDogug5xLum12ap7nOXqN4zCCfOEDpo=;
	b=iG6PVyGtktcUeGRJ0kGpqjbOEYwwuIXFCpU8cawhx0s32si7Zb0gKWuVV9/gFubxkD
	ZDi5lvjJKWw9QhCy6dpyUIdOoX9t+C7RvBVT72ispSOksgd/kSTjdeJc4cYJEL3bGrkO
	hEh1vgIcIfix1TZTjLMXUwtJt6YvNrs6n2/mPGMG/hOwlYBc6Cqs4CVlbAKXn7gVyvG3
	x4uGgiQ6OtubMAGLUziFhXgwKtkTQoPHC/NGNAx32DwgZ2gq36cscVeQnF9WqVtMGLSP
	DWxVLqIxQkBrm04buuMo9qLrmM7JqImip2mZvhLhpoGAI7ln8bmer4Tyqs2osHfSUiNG
	Bneg==
MIME-Version: 1.0
X-Received: by 10.60.6.105 with SMTP id z9mr3879055oez.52.1360013060510; Mon,
	04 Feb 2013 13:24:20 -0800 (PST)
Received: by 10.182.23.39 with HTTP; Mon, 4 Feb 2013 13:24:20 -0800 (PST)
In-Reply-To: <5110207B.4060501@gnu.org>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<5110207B.4060501@gnu.org>
Date: Mon, 4 Feb 2013 13:24:20 -0800
Message-ID: <CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.gmail.com>
From: Ian Lance Taylor <iant@google.com>
To: Paolo Bonzini <bonzini@gnu.org>
X-Gm-Message-State: ALoCoQmeWmCnOzzFH0Lu78YxneaIulp4mVpCKotHxxqBGvKLc7bJgy9+tOpVWKBV+lrfZQBopES5i/6NrhmxfmL7fJ/get6XV4FivfR3mb+9f+VjSSkI1ZP1t75WCNZei1uvtZETkH8vcthtbma8FLXNB/bGdUIQDzzErexzrOcmr3mxOHcTSGwwNLyTye0aAm6ONxAQLccq
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 4, 2013 at 12:56 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> Would it make sense to release the header file under a permissive
> license or even public domain?
>
> The information there is just ABI, it's dubious that it is copyrightable
> at all.  If two colleagues of Frediano's did a clean-room reverse
> engineering, the result would really be indistiguishable from the original.

I agree that the information in gcov-io.h is almost certainly uncopyrightable.

But since it's under the GCC Runtime Library Exception, which applies
to approximately every program compiled by GCC, I don't think it makes
much difference one way or another.  I'm not opposed to asking the FSF
to relicense the file, I just don't think it matters.

Ian

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

From xen-devel-bounces@lists.xen.org Mon Feb 04 22:17:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 22: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 1U2UL2-0008HG-Tt; Mon, 04 Feb 2013 22:16:32 +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 1U2UL1-0008HB-6d
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 22:16:31 +0000
Received: from [193.109.254.147:50417] by server-6.bemta-14.messagelabs.com id
	01/CA-12010-E3330115; Mon, 04 Feb 2013 22:16:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360016188!10075587!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9965 invoked from network); 4 Feb 2013 22:16:28 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 22:16:28 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so3556385wic.17
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 14:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=NKgjbDk/dNcreidAp3PpiHQffMa0ZyQZBvKJ0+Yv0cc=;
	b=XVe5/7aRsd8jlSO5YWJSzAOI5b5fFVfMyKWGbm3cP3zAwj0ERBTHx8fwFb7kbJjlck
	wiOfe9tYjKgK61Dl/C8/GuuBGhpKjI67OFYJOktcBfpc8c+wjLXiADbuqQMR+45lmM7v
	wqKkUZqaD7NC2MTlyEPx4AtY8+JrAyjbOSmRNGFPS4ZjAanuIeOVLESPO7yGqyXhKi52
	ydb8Z/lCFPS2GQ99bBnjyrxZXtPHSH3pM4Qeg1r2tCby9E+EqG8OvY6BuEzOt99c7oSn
	/+ELSzFO3Wqe6N3aakXMwp3oRack0GuKCbs78YUtYQKVxEd9jctyQ5yeYILhZbIB+gfi
	gc5w==
X-Received: by 10.194.178.33 with SMTP id cv1mr37980459wjc.46.1360016188102;
	Mon, 04 Feb 2013 14:16:28 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id hb9sm4531848wib.3.2013.02.04.14.16.26
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 14:16:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 22:16:21 +0000
From: Keir Fraser <keir@xen.org>
To: Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD35E3B5.5A03B%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DJULRh+z6mJeN4kOvzX5AwyTGPA==
In-Reply-To: <1360012076.7477.132.camel@zion.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 21:07, "Wei Liu" <wei.liu2@citrix.com> wrote:

>> Concurrent access by Xen to the event queue must be protected by a
>> per-event queue spin lock.
>> 
> 
> I presume "E[n]" in the pseudo code is "E[p]"?
> 
> Is this spin lock really a good idea? How many threads / cpus will spin
> on this lock? As [0] shows, contention on spin lock incurs heavy
> performance penalty.
> 
> [0] https://lwn.net/Articles/530458/

Given that the critical region is small, the extra cache line contention for
the spinlock is probably not a big deal. Even in the current event-channel
design, we would get cache ping-pong on the event-channel bitmaps.

Consider 10k interrupts to a CPU would be a heavy amount. That's one every
100us. The event-channel delivery code described probably runs in less than
1us, even if memory accesses are horrible cache misses. The really highly
contended case shouldn't happen.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Mon Feb 04 22:17:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 04 Feb 2013 22: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 1U2UL2-0008HG-Tt; Mon, 04 Feb 2013 22:16:32 +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 1U2UL1-0008HB-6d
	for xen-devel@lists.xen.org; Mon, 04 Feb 2013 22:16:31 +0000
Received: from [193.109.254.147:50417] by server-6.bemta-14.messagelabs.com id
	01/CA-12010-E3330115; Mon, 04 Feb 2013 22:16:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360016188!10075587!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9965 invoked from network); 4 Feb 2013 22:16:28 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Feb 2013 22:16:28 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so3556385wic.17
	for <xen-devel@lists.xen.org>; Mon, 04 Feb 2013 14:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=NKgjbDk/dNcreidAp3PpiHQffMa0ZyQZBvKJ0+Yv0cc=;
	b=XVe5/7aRsd8jlSO5YWJSzAOI5b5fFVfMyKWGbm3cP3zAwj0ERBTHx8fwFb7kbJjlck
	wiOfe9tYjKgK61Dl/C8/GuuBGhpKjI67OFYJOktcBfpc8c+wjLXiADbuqQMR+45lmM7v
	wqKkUZqaD7NC2MTlyEPx4AtY8+JrAyjbOSmRNGFPS4ZjAanuIeOVLESPO7yGqyXhKi52
	ydb8Z/lCFPS2GQ99bBnjyrxZXtPHSH3pM4Qeg1r2tCby9E+EqG8OvY6BuEzOt99c7oSn
	/+ELSzFO3Wqe6N3aakXMwp3oRack0GuKCbs78YUtYQKVxEd9jctyQ5yeYILhZbIB+gfi
	gc5w==
X-Received: by 10.194.178.33 with SMTP id cv1mr37980459wjc.46.1360016188102;
	Mon, 04 Feb 2013 14:16:28 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id hb9sm4531848wib.3.2013.02.04.14.16.26
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 04 Feb 2013 14:16:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 04 Feb 2013 22:16:21 +0000
From: Keir Fraser <keir@xen.org>
To: Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD35E3B5.5A03B%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DJULRh+z6mJeN4kOvzX5AwyTGPA==
In-Reply-To: <1360012076.7477.132.camel@zion.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/2013 21:07, "Wei Liu" <wei.liu2@citrix.com> wrote:

>> Concurrent access by Xen to the event queue must be protected by a
>> per-event queue spin lock.
>> 
> 
> I presume "E[n]" in the pseudo code is "E[p]"?
> 
> Is this spin lock really a good idea? How many threads / cpus will spin
> on this lock? As [0] shows, contention on spin lock incurs heavy
> performance penalty.
> 
> [0] https://lwn.net/Articles/530458/

Given that the critical region is small, the extra cache line contention for
the spinlock is probably not a big deal. Even in the current event-channel
design, we would get cache ping-pong on the event-channel bitmaps.

Consider 10k interrupts to a CPU would be a heavy amount. That's one every
100us. The event-channel delivery code described probably runs in less than
1us, even if memory accesses are horrible cache misses. The really highly
contended case shouldn't happen.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 01:05:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 01:05: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 1U2Wy5-0005oG-6j; Tue, 05 Feb 2013 01:05:01 +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 1U2Wy3-0005oB-3j
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 01:04:59 +0000
Received: from [85.158.139.83:2146] by server-5.bemta-5.messagelabs.com id
	A8/E3-11945-ABA50115; Tue, 05 Feb 2013 01:04:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360026295!30852363!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA0MzM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28318 invoked from network); 5 Feb 2013 01:04:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 01:04:57 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1514qSP012344
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 01:04:52 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
	r1514p96020680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 01:04:52 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1514pDG012033; Mon, 4 Feb 2013 19:04:51 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 04 Feb 2013 17:04:50 -0800
Date: Mon, 4 Feb 2013 17:04:49 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204170449.24408e42@mantra.us.oracle.com>
In-Reply-To: <1359973901.5281.35.camel@zakaz.uk.xensource.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.com>
	<20130201112716.4d63716c@mantra.us.oracle.com>
	<1359973901.5281.35.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: acsinet22.oracle.com [141.146.126.238]
Cc: "konrad@kernel.org" <konrad@kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 4 Feb 2013 10:31:41 +0000
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-02-01 at 19:27 +0000, Mukesh Rathor wrote:
> > On Fri, 01 Feb 2013 16:24:57 +0000
> > "Jan Beulich" <jbeulich@suse.com> wrote:
> > 

> I don't much care about the gdt vs u naming for the union, although I
> would probably have gone with the more meaningful gdt if it were me.
> cscope-wise in emacs I would just use "C-c s t" to look for "gdt.size"
> etc.

Unf vim cscope doesn't support that. Moreover, I bet if size was accessed
via pointer, you couldn't search it that way either. In general, all 
enterprise software I've worked on prohibited such generic names for 
the reason people couldn't easily find their usages. I find it very 
frustrating, and I hope I can continue to be able to read xen code.

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 Feb 05 01:05:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 01:05: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 1U2Wy5-0005oG-6j; Tue, 05 Feb 2013 01:05:01 +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 1U2Wy3-0005oB-3j
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 01:04:59 +0000
Received: from [85.158.139.83:2146] by server-5.bemta-5.messagelabs.com id
	A8/E3-11945-ABA50115; Tue, 05 Feb 2013 01:04:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360026295!30852363!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA0MzM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28318 invoked from network); 5 Feb 2013 01:04:57 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 01:04:57 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1514qSP012344
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 01:04:52 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
	r1514p96020680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 01:04:52 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1514pDG012033; Mon, 4 Feb 2013 19:04:51 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 04 Feb 2013 17:04:50 -0800
Date: Mon, 4 Feb 2013 17:04:49 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130204170449.24408e42@mantra.us.oracle.com>
In-Reply-To: <1359973901.5281.35.camel@zakaz.uk.xensource.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.com>
	<20130201112716.4d63716c@mantra.us.oracle.com>
	<1359973901.5281.35.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: acsinet22.oracle.com [141.146.126.238]
Cc: "konrad@kernel.org" <konrad@kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 4 Feb 2013 10:31:41 +0000
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-02-01 at 19:27 +0000, Mukesh Rathor wrote:
> > On Fri, 01 Feb 2013 16:24:57 +0000
> > "Jan Beulich" <jbeulich@suse.com> wrote:
> > 

> I don't much care about the gdt vs u naming for the union, although I
> would probably have gone with the more meaningful gdt if it were me.
> cscope-wise in emacs I would just use "C-c s t" to look for "gdt.size"
> etc.

Unf vim cscope doesn't support that. Moreover, I bet if size was accessed
via pointer, you couldn't search it that way either. In general, all 
enterprise software I've worked on prohibited such generic names for 
the reason people couldn't easily find their usages. I find it very 
frustrating, and I hope I can continue to be able to read xen code.

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 Feb 05 06:13:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:13: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 1U2bm1-0001Q4-AI; Tue, 05 Feb 2013 06:12:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1U2blz-0001Pz-IU
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 06:12:51 +0000
Received: from [85.158.143.99:39184] by server-3.bemta-4.messagelabs.com id
	E1/35-08920-2E2A0115; Tue, 05 Feb 2013 06:12:50 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360044767!29304051!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDE5NTgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6800 invoked from network); 5 Feb 2013 06:12:49 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 06:12:49 -0000
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 20F9B3EE0C1
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:46 +0900 (JST)
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 0AC2845DE55
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:46 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id E911645DE54
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:45 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id DD65F1DB804D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:45 +0900 (JST)
Received: from G01JPEXCHKW08.g01.fujitsu.local
	(G01JPEXCHKW08.g01.fujitsu.local [10.0.194.47])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 953201DB8042
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:45 +0900 (JST)
Received: from [10.33.110.103] (10.33.110.103) by
	G01JPEXCHKW08.g01.fujitsu.local (10.0.194.47) with Microsoft SMTP
	Server (TLS) id 14.2.309.2; Tue, 5 Feb 2013 15:12:44 +0900
Message-ID: <5110A2DD.1080603@jp.fujitsu.com>
Date: Tue, 5 Feb 2013 15:12:45 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------050105020702020508050106"
X-Originating-IP: [10.33.110.103]
Subject: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050105020702020508050106
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

The value of ACPI PM-Timer may be broken on save unless the timer mode
is delay_for_missed_ticks.
With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero
and the adjustment from its value is wrong.

This patch fixes the saved value of ACPI PM-Timer:
- don't adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero.
- consolidate calculations of PM-Timer to one function. more precise on save.

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

--------------050105020702020508050106
Content-Type: text/x-patch; name="fix_corrupt_saved_pmtimer.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="fix_corrupt_saved_pmtimer.patch"

diff -r 5af4f2ab06f3 xen/arch/x86/hvm/pmtimer.c
--- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
+++ b/xen/arch/x86/hvm/pmtimer.c	Tue Feb 05 10:26:13 2013 +0900
@@ -84,28 +84,31 @@ void hvm_acpi_sleep_button(struct domain
 }
 
 /* Set the correct value in the timer, accounting for time elapsed
- * since the last time we did that. */
-static void pmt_update_time(PMTState *s)
+ * since the last time we did that.
+ * return true if the counter's MSB has changed. */
+static bool_t pmt_count_up_and_test_msb(PMTState *s, uint64_t gtime)
 {
-    uint64_t curr_gtime, tmp;
     uint32_t tmr_val = s->pm.tmr_val, msb = tmr_val & TMR_VAL_MSB;
-    
-    ASSERT(spin_is_locked(&s->lock));
+    uint64_t tmp = ((gtime - s->last_gtime) * s->scale) + s->not_accounted;
 
-    /* Update the timer */
-    curr_gtime = hvm_get_guest_time(s->vcpu);
-    tmp = ((curr_gtime - s->last_gtime) * s->scale) + s->not_accounted;
     s->not_accounted = (uint32_t)tmp;
     tmr_val += tmp >> 32;
     tmr_val &= TMR_VAL_MASK;
-    s->last_gtime = curr_gtime;
+    s->last_gtime = gtime;
 
     /* Update timer value atomically wrt lock-free reads in handle_pmt_io(). */
     *(volatile uint32_t *)&s->pm.tmr_val = tmr_val;
 
-    /* If the counter's MSB has changed, set the status bit */
-    if ( (tmr_val & TMR_VAL_MSB) != msb )
+    return  ((tmr_val & TMR_VAL_MSB) != msb);
+}
+
+static void pmt_update_time(PMTState *s)
+{
+    ASSERT(spin_is_locked(&s->lock));
+
+    if ( pmt_count_up_and_test_msb(s, hvm_get_guest_time(s->vcpu)) )
     {
+        /* MSB has changed, set the status bit */
         s->pm.pm1a_sts |= TMR_STS;
         pmt_update_sci(s);
     }
@@ -244,21 +247,34 @@ static int handle_pmt_io(
 static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
 {
     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
+    uint64_t guest_time;
     int rc;
 
     spin_lock(&s->lock);
 
-    /* Update the counter to the guest's current time.  We always save
-     * with the domain paused, so the saved time should be after the
-     * last_gtime, but just in case, make sure we only go forwards */
-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
-    if ( x < 1UL<<31 )
-        s->pm.tmr_val += x;
-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
-        s->pm.pm1a_sts |= TMR_STS;
-    /* No point in setting the SCI here because we'll already have saved the 
-     * IRQ and *PIC state; we'll fix it up when we restore the domain */
+    guest_time = s->vcpu->arch.hvm_vcpu.guest_time;
+    /* Update the counter to the guest's current time only if the
+     * timer mode is delay_for_missed_ticks */
+    if ( guest_time != 0 )
+    {
+        /* We always save with the domain paused, so the saved time
+         * should be after the last_gtime, but just in case, make sure
+         * we only go forwards */
+        if ( (s64)guest_time - (s64)s->last_gtime < 0)
+        {
+            dprintk(XENLOG_WARNING,
+                    "Last update of PMT is ahead of guest's time by %ld\n",
+                    s->last_gtime - guest_time);
+        }
+        else
+        {
+            if ( pmt_count_up_and_test_msb(s, guest_time) )
+                s->pm.pm1a_sts |= TMR_STS;
+            /* No point in setting the SCI here because we'll already
+             * have saved the IRQ and *PIC state;
+             * we'll fix it up when we restore the domain */
+        }
+    }
 
     rc = hvm_save_entry(PMTIMER, 0, h, &s->pm);
 

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

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

--------------050105020702020508050106--


From xen-devel-bounces@lists.xen.org Tue Feb 05 06:13:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:13: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 1U2bm1-0001Q4-AI; Tue, 05 Feb 2013 06:12:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1U2blz-0001Pz-IU
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 06:12:51 +0000
Received: from [85.158.143.99:39184] by server-3.bemta-4.messagelabs.com id
	E1/35-08920-2E2A0115; Tue, 05 Feb 2013 06:12:50 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360044767!29304051!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDE5NTgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6800 invoked from network); 5 Feb 2013 06:12:49 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 06:12:49 -0000
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 20F9B3EE0C1
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:46 +0900 (JST)
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 0AC2845DE55
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:46 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id E911645DE54
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:45 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id DD65F1DB804D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:45 +0900 (JST)
Received: from G01JPEXCHKW08.g01.fujitsu.local
	(G01JPEXCHKW08.g01.fujitsu.local [10.0.194.47])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 953201DB8042
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:12:45 +0900 (JST)
Received: from [10.33.110.103] (10.33.110.103) by
	G01JPEXCHKW08.g01.fujitsu.local (10.0.194.47) with Microsoft SMTP
	Server (TLS) id 14.2.309.2; Tue, 5 Feb 2013 15:12:44 +0900
Message-ID: <5110A2DD.1080603@jp.fujitsu.com>
Date: Tue, 5 Feb 2013 15:12:45 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------050105020702020508050106"
X-Originating-IP: [10.33.110.103]
Subject: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050105020702020508050106
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

The value of ACPI PM-Timer may be broken on save unless the timer mode
is delay_for_missed_ticks.
With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero
and the adjustment from its value is wrong.

This patch fixes the saved value of ACPI PM-Timer:
- don't adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero.
- consolidate calculations of PM-Timer to one function. more precise on save.

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

--------------050105020702020508050106
Content-Type: text/x-patch; name="fix_corrupt_saved_pmtimer.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="fix_corrupt_saved_pmtimer.patch"

diff -r 5af4f2ab06f3 xen/arch/x86/hvm/pmtimer.c
--- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
+++ b/xen/arch/x86/hvm/pmtimer.c	Tue Feb 05 10:26:13 2013 +0900
@@ -84,28 +84,31 @@ void hvm_acpi_sleep_button(struct domain
 }
 
 /* Set the correct value in the timer, accounting for time elapsed
- * since the last time we did that. */
-static void pmt_update_time(PMTState *s)
+ * since the last time we did that.
+ * return true if the counter's MSB has changed. */
+static bool_t pmt_count_up_and_test_msb(PMTState *s, uint64_t gtime)
 {
-    uint64_t curr_gtime, tmp;
     uint32_t tmr_val = s->pm.tmr_val, msb = tmr_val & TMR_VAL_MSB;
-    
-    ASSERT(spin_is_locked(&s->lock));
+    uint64_t tmp = ((gtime - s->last_gtime) * s->scale) + s->not_accounted;
 
-    /* Update the timer */
-    curr_gtime = hvm_get_guest_time(s->vcpu);
-    tmp = ((curr_gtime - s->last_gtime) * s->scale) + s->not_accounted;
     s->not_accounted = (uint32_t)tmp;
     tmr_val += tmp >> 32;
     tmr_val &= TMR_VAL_MASK;
-    s->last_gtime = curr_gtime;
+    s->last_gtime = gtime;
 
     /* Update timer value atomically wrt lock-free reads in handle_pmt_io(). */
     *(volatile uint32_t *)&s->pm.tmr_val = tmr_val;
 
-    /* If the counter's MSB has changed, set the status bit */
-    if ( (tmr_val & TMR_VAL_MSB) != msb )
+    return  ((tmr_val & TMR_VAL_MSB) != msb);
+}
+
+static void pmt_update_time(PMTState *s)
+{
+    ASSERT(spin_is_locked(&s->lock));
+
+    if ( pmt_count_up_and_test_msb(s, hvm_get_guest_time(s->vcpu)) )
     {
+        /* MSB has changed, set the status bit */
         s->pm.pm1a_sts |= TMR_STS;
         pmt_update_sci(s);
     }
@@ -244,21 +247,34 @@ static int handle_pmt_io(
 static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
 {
     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
+    uint64_t guest_time;
     int rc;
 
     spin_lock(&s->lock);
 
-    /* Update the counter to the guest's current time.  We always save
-     * with the domain paused, so the saved time should be after the
-     * last_gtime, but just in case, make sure we only go forwards */
-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
-    if ( x < 1UL<<31 )
-        s->pm.tmr_val += x;
-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
-        s->pm.pm1a_sts |= TMR_STS;
-    /* No point in setting the SCI here because we'll already have saved the 
-     * IRQ and *PIC state; we'll fix it up when we restore the domain */
+    guest_time = s->vcpu->arch.hvm_vcpu.guest_time;
+    /* Update the counter to the guest's current time only if the
+     * timer mode is delay_for_missed_ticks */
+    if ( guest_time != 0 )
+    {
+        /* We always save with the domain paused, so the saved time
+         * should be after the last_gtime, but just in case, make sure
+         * we only go forwards */
+        if ( (s64)guest_time - (s64)s->last_gtime < 0)
+        {
+            dprintk(XENLOG_WARNING,
+                    "Last update of PMT is ahead of guest's time by %ld\n",
+                    s->last_gtime - guest_time);
+        }
+        else
+        {
+            if ( pmt_count_up_and_test_msb(s, guest_time) )
+                s->pm.pm1a_sts |= TMR_STS;
+            /* No point in setting the SCI here because we'll already
+             * have saved the IRQ and *PIC state;
+             * we'll fix it up when we restore the domain */
+        }
+    }
 
     rc = hvm_save_entry(PMTIMER, 0, h, &s->pm);
 

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

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

--------------050105020702020508050106--


From xen-devel-bounces@lists.xen.org Tue Feb 05 06:36:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:36: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 1U2c8C-0001hb-Nu; Tue, 05 Feb 2013 06:35:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <junjie.mao@intel.com>) id 1U2Yaw-0007OI-0u
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 02:49:14 +0000
Received: from [85.158.139.211:32574] by server-16.bemta-5.messagelabs.com id
	C5/F7-14948-92370115; Tue, 05 Feb 2013 02:49:13 +0000
X-Env-Sender: junjie.mao@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360032552!21063656!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ1NzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29502 invoked from network); 5 Feb 2013 02:49:12 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-206.messagelabs.com with SMTP;
	5 Feb 2013 02:49:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 04 Feb 2013 18:49:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,602,1355126400"; d="scan'208";a="257720997"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 04 Feb 2013 18:49:11 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 4 Feb 2013 18:49:10 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Tue, 5 Feb 2013 10:49:09 +0800
From: "Mao, Junjie" <junjie.mao@intel.com>
To: "jeremy@goop.org" <jeremy@goop.org>
Thread-Topic: How can I run 3.x dom0 w/o PAE? (Resend w/o format)
Thread-Index: AQHOA0teoxYAw3BHiUqQN25BcRyXCw==
Date: Tue, 5 Feb 2013 02:49:08 +0000
Message-ID: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C49@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
X-Mailman-Approved-At: Tue, 05 Feb 2013 06:35:47 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>
Subject: [Xen-devel] How can I run 3.x dom0 w/o PAE? (Resend w/o format)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jeremy,

I'm now working in a Xen-based project where some drivers in the Dom0 kernel (based on Linux 3.0) refuse to work with PAE. Do you know if it is possible to run 3.x kernel as non-PAE dom0 on Xen (any version is ok)? If so, how can I make it work? Many thanks in advance!

Best Regards
Junjie Mao


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 06:36:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:36: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 1U2c8C-0001hb-Nu; Tue, 05 Feb 2013 06:35:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <junjie.mao@intel.com>) id 1U2Yaw-0007OI-0u
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 02:49:14 +0000
Received: from [85.158.139.211:32574] by server-16.bemta-5.messagelabs.com id
	C5/F7-14948-92370115; Tue, 05 Feb 2013 02:49:13 +0000
X-Env-Sender: junjie.mao@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360032552!21063656!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ1NzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29502 invoked from network); 5 Feb 2013 02:49:12 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-206.messagelabs.com with SMTP;
	5 Feb 2013 02:49:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 04 Feb 2013 18:49:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,602,1355126400"; d="scan'208";a="257720997"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 04 Feb 2013 18:49:11 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 4 Feb 2013 18:49:10 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Tue, 5 Feb 2013 10:49:09 +0800
From: "Mao, Junjie" <junjie.mao@intel.com>
To: "jeremy@goop.org" <jeremy@goop.org>
Thread-Topic: How can I run 3.x dom0 w/o PAE? (Resend w/o format)
Thread-Index: AQHOA0teoxYAw3BHiUqQN25BcRyXCw==
Date: Tue, 5 Feb 2013 02:49:08 +0000
Message-ID: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C49@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
X-Mailman-Approved-At: Tue, 05 Feb 2013 06:35:47 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>
Subject: [Xen-devel] How can I run 3.x dom0 w/o PAE? (Resend w/o format)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jeremy,

I'm now working in a Xen-based project where some drivers in the Dom0 kernel (based on Linux 3.0) refuse to work with PAE. Do you know if it is possible to run 3.x kernel as non-PAE dom0 on Xen (any version is ok)? If so, how can I make it work? Many thanks in advance!

Best Regards
Junjie Mao


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 06:36:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:36: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 1U2c8C-0001hU-BZ; Tue, 05 Feb 2013 06:35:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <junjie.mao@intel.com>) id 1U2YXS-0007Ng-AC
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 02:45:38 +0000
Received: from [85.158.143.35:30691] by server-2.bemta-4.messagelabs.com id
	FD/DE-01597-15270115; Tue, 05 Feb 2013 02:45:37 +0000
X-Env-Sender: junjie.mao@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360032335!5565444!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ1NzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16821 invoked from network); 5 Feb 2013 02:45:36 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	5 Feb 2013 02:45:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 04 Feb 2013 18:45:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,602,1355126400"; 
	d="scan'208,217";a="280958760"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 04 Feb 2013 18:45:34 -0800
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 4 Feb 2013 18:45:34 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 4 Feb 2013 18:45:33 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.181]) with mapi id
	14.01.0355.002; Tue, 5 Feb 2013 10:45:32 +0800
From: "Mao, Junjie" <junjie.mao@intel.com>
To: "jeremy@goop.org" <jeremy@goop.org>
Thread-Topic: How can I run 3.x dom0 w/o PAE?
Thread-Index: Ac4DSt07oNJBtjCOT6SqWqXKuV35pw==
Date: Tue, 5 Feb 2013 02:45:31 +0000
Message-ID: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38@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
X-Mailman-Approved-At: Tue, 05 Feb 2013 06:35:47 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>
Subject: [Xen-devel] How can I run 3.x dom0 w/o PAE?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6893854006629933549=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6893854006629933549==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_"

--_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

I'm now working in a Xen-based project where some drivers in the Dom0 kerne=
l (based on Linux 3.0) refuse to work with PAE. Do you know if it is possib=
le to run 3.x kernel as non-PAE dom0 on Xen (any version is ok)? If so, how=
 can I make it work? Many thanks in advance!

Best Regards
Junjie Mao




--_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:10.5pt;">
<div align=3D"left" style=3D"text-align:justify;">Hi Jeremy,</div>
<div align=3D"left" style=3D"text-align:justify;">&nbsp;</div>
<div align=3D"left" style=3D"text-align:justify;">I&#8217;m now working in =
a Xen-based project where some drivers in the Dom0 kernel (based on Linux 3=
.0) refuse to work with PAE. Do you know if it is possible to run 3.x kerne=
l as non-PAE dom0 on Xen (any version is ok)?
If so, how can I make it work? Many thanks in advance!</div>
<div align=3D"left" style=3D"text-align:justify;"><font face=3D"Times New R=
oman">&nbsp;</font></div>
<div align=3D"left" style=3D"text-align:justify;">Best Regards</div>
<div align=3D"left" style=3D"text-align:justify;">Junjie Mao</div>
<div align=3D"left" style=3D"text-align:justify;">&nbsp;</div>
<div align=3D"left" style=3D"text-align:justify;"><font face=3D"Times New R=
oman">&nbsp;</font></div>
<div align=3D"left" style=3D"text-align:justify;"><font face=3D"Times New R=
oman">&nbsp;</font></div>
</span></font>
</body>
</html>

--_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_--


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

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

--===============6893854006629933549==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 06:36:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:36: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 1U2c8C-0001hU-BZ; Tue, 05 Feb 2013 06:35:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <junjie.mao@intel.com>) id 1U2YXS-0007Ng-AC
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 02:45:38 +0000
Received: from [85.158.143.35:30691] by server-2.bemta-4.messagelabs.com id
	FD/DE-01597-15270115; Tue, 05 Feb 2013 02:45:37 +0000
X-Env-Sender: junjie.mao@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360032335!5565444!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ1NzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16821 invoked from network); 5 Feb 2013 02:45:36 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-2.tower-21.messagelabs.com with SMTP;
	5 Feb 2013 02:45:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 04 Feb 2013 18:45:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,602,1355126400"; 
	d="scan'208,217";a="280958760"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 04 Feb 2013 18:45:34 -0800
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 4 Feb 2013 18:45:34 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 4 Feb 2013 18:45:33 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.181]) with mapi id
	14.01.0355.002; Tue, 5 Feb 2013 10:45:32 +0800
From: "Mao, Junjie" <junjie.mao@intel.com>
To: "jeremy@goop.org" <jeremy@goop.org>
Thread-Topic: How can I run 3.x dom0 w/o PAE?
Thread-Index: Ac4DSt07oNJBtjCOT6SqWqXKuV35pw==
Date: Tue, 5 Feb 2013 02:45:31 +0000
Message-ID: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38@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
X-Mailman-Approved-At: Tue, 05 Feb 2013 06:35:47 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>
Subject: [Xen-devel] How can I run 3.x dom0 w/o PAE?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6893854006629933549=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6893854006629933549==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_"

--_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

I'm now working in a Xen-based project where some drivers in the Dom0 kerne=
l (based on Linux 3.0) refuse to work with PAE. Do you know if it is possib=
le to run 3.x kernel as non-PAE dom0 on Xen (any version is ok)? If so, how=
 can I make it work? Many thanks in advance!

Best Regards
Junjie Mao




--_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:10.5pt;">
<div align=3D"left" style=3D"text-align:justify;">Hi Jeremy,</div>
<div align=3D"left" style=3D"text-align:justify;">&nbsp;</div>
<div align=3D"left" style=3D"text-align:justify;">I&#8217;m now working in =
a Xen-based project where some drivers in the Dom0 kernel (based on Linux 3=
.0) refuse to work with PAE. Do you know if it is possible to run 3.x kerne=
l as non-PAE dom0 on Xen (any version is ok)?
If so, how can I make it work? Many thanks in advance!</div>
<div align=3D"left" style=3D"text-align:justify;"><font face=3D"Times New R=
oman">&nbsp;</font></div>
<div align=3D"left" style=3D"text-align:justify;">Best Regards</div>
<div align=3D"left" style=3D"text-align:justify;">Junjie Mao</div>
<div align=3D"left" style=3D"text-align:justify;">&nbsp;</div>
<div align=3D"left" style=3D"text-align:justify;"><font face=3D"Times New R=
oman">&nbsp;</font></div>
<div align=3D"left" style=3D"text-align:justify;"><font face=3D"Times New R=
oman">&nbsp;</font></div>
</span></font>
</body>
</html>

--_000_EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38SHSMSX101ccrcor_--


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

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

--===============6893854006629933549==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 06:42:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06: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 1U2cE0-00022N-JP; Tue, 05 Feb 2013 06:41: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 1U2cDz-00022G-F5
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 06:41:47 +0000
Received: from [85.158.139.211:20384] by server-9.bemta-5.messagelabs.com id
	FB/42-24440-AA9A0115; Tue, 05 Feb 2013 06:41:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360046505!18303590!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26852 invoked from network); 5 Feb 2013 06:41:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 06:41:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1140718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 06:41: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.297.1; Tue, 5 Feb 2013 06:41:45 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2cDx-0004zx-0c;
	Tue, 05 Feb 2013 06:41:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2cDw-0001wl-EO;
	Tue, 05 Feb 2013 06:41:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15419-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Feb 2013 06:41:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15419: 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 15419 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15419/

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. 15179
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
 test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15179
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15179
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 15179
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 15179
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 15179
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 15179
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15179
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15179
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 15179
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 15179
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15179
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 15179
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15179
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 15179
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 15179
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 15179
 test-amd64-amd64-xl-qemut-win  7 windows-install          fail REGR. vs. 15179

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  ff77e84ddfdc
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Eddie Dong <eddie.dong@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1160 lines long.)

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 06:42:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06: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 1U2cE0-00022N-JP; Tue, 05 Feb 2013 06:41: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 1U2cDz-00022G-F5
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 06:41:47 +0000
Received: from [85.158.139.211:20384] by server-9.bemta-5.messagelabs.com id
	FB/42-24440-AA9A0115; Tue, 05 Feb 2013 06:41:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360046505!18303590!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwNTkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26852 invoked from network); 5 Feb 2013 06:41:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 06:41:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1140718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 06:41: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.297.1; Tue, 5 Feb 2013 06:41:45 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2cDx-0004zx-0c;
	Tue, 05 Feb 2013 06:41:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2cDw-0001wl-EO;
	Tue, 05 Feb 2013 06:41:44 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15419-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Feb 2013 06:41:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15419: 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 15419 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15419/

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. 15179
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
 test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15179
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15179
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 15179
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 15179
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 15179
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 15179
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15179
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15179
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 15179
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 15179
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15179
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 15179
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15179
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 15179
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 15179
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 15179
 test-amd64-amd64-xl-qemut-win  7 windows-install          fail REGR. vs. 15179

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15179
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15179

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  ff77e84ddfdc
baseline version:
 xen                  5af4f2ab06f3

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Vrabel <david.vrabel@citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Eddie Dong <eddie.dong@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Razvan Cojocaru <rzvncj@gmail.com>
  Roger Pau Monn? <roger.pau@citrix.com>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Wei Huang <huangwei@gmail.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 1160 lines long.)

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 06:47:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:47: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 1U2cJZ-0002Bt-KX; Tue, 05 Feb 2013 06:47:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U2cJY-0002Bo-5Z
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 06:47:32 +0000
Received: from [85.158.137.99:15391] by server-1.bemta-3.messagelabs.com id
	52/EC-08955-30BA0115; Tue, 05 Feb 2013 06:47:31 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360046849!16813325!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTM1NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15703 invoked from network); 5 Feb 2013 06:47:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 06:47:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r156lQW9006972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 06:47: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
	r156lPpD029039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 06:47: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
	r156lPlH001462; Tue, 5 Feb 2013 00:47:25 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 04 Feb 2013 22:47:24 -0800
Message-ID: <5110AAFA.7060602@oracle.com>
Date: Tue, 05 Feb 2013 14:47:22 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
In-Reply-To: <510F84C2.9090505@citrix.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/13 17:52, Roger Pau Monn=E9 wrote:
> On 04/02/13 02:54, Joe Jin wrote:
>> Current Xend allowing multiple call destroy() for same domain, this lead
>> multiple hard resets(FLR) for pci pass-through, and some controller might
>> failed.
>>
>> In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, a=
fter
>> guest brought up, call xm-destroy twice, the adapters's BIOS will hung, =
and
>> we had to reboot the server to recovery it.
> =

> Does the same problem happen with libxl/xl?

execute xl-destroy twice crashed my server!

Thanks,
Joe



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 06:47:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 06:47: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 1U2cJZ-0002Bt-KX; Tue, 05 Feb 2013 06:47:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U2cJY-0002Bo-5Z
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 06:47:32 +0000
Received: from [85.158.137.99:15391] by server-1.bemta-3.messagelabs.com id
	52/EC-08955-30BA0115; Tue, 05 Feb 2013 06:47:31 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360046849!16813325!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTM1NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15703 invoked from network); 5 Feb 2013 06:47:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 06:47:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r156lQW9006972
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 06:47: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
	r156lPpD029039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 06:47: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
	r156lPlH001462; Tue, 5 Feb 2013 00:47:25 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 04 Feb 2013 22:47:24 -0800
Message-ID: <5110AAFA.7060602@oracle.com>
Date: Tue, 05 Feb 2013 14:47:22 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
In-Reply-To: <510F84C2.9090505@citrix.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/04/13 17:52, Roger Pau Monn=E9 wrote:
> On 04/02/13 02:54, Joe Jin wrote:
>> Current Xend allowing multiple call destroy() for same domain, this lead
>> multiple hard resets(FLR) for pci pass-through, and some controller might
>> failed.
>>
>> In our test, we pass through 2 LSI HAB controllers to the PVHVM guest, a=
fter
>> guest brought up, call xm-destroy twice, the adapters's BIOS will hung, =
and
>> we had to reboot the server to recovery it.
> =

> Does the same problem happen with libxl/xl?

execute xl-destroy twice crashed my server!

Thanks,
Joe



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 07:36:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 07:36: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 1U2d4J-0002q5-KR; Tue, 05 Feb 2013 07:35:51 +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 1U2d4H-0002q0-Dx
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 07:35:49 +0000
Received: from [85.158.138.51:14678] by server-11.bemta-3.messagelabs.com id
	27/B0-10249-456B0115; Tue, 05 Feb 2013 07:35:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360049737!22137646!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 646 invoked from network); 5 Feb 2013 07:35:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 07:35:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 07:34:23 +0000
Message-Id: <5110C40E02000078000BBD10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 07:34:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
	<CD35A54A.59FE4%keir@xen.org>
In-Reply-To: <CD35A54A.59FE4%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:50, Keir Fraser <keir@xen.org> wrote:
> On 04/02/2013 16:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>> this, originally having been at a fixed location outside of Xen virtual
>> address ranges, has seen a number of changes over the years, with
>> the net effect that right now we're requiring an order-1 allocation
>> from the Xen heap. Obviously it would be much better if this got
>> populated with order-0 allocations from the domain heap.
>> 
>> Considering that there's going to be one such area per vCPU (less
>> those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
>> seems undesirable to me to use vmap() for this purpose.
>> 
>> Instead I wonder whether we shouldn't go back to putting this at
>> a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
>> the virtual address range pressure (compared to the vmap()
>> approach as well as for the case that these areas might need
>> extending). Was there any other reason that you moved them out
>> of such a fixed area than wanting to use mostly the same code
>> for PV and HVM (which ought to be possible now that there's a
>> base pointer stored for each vCPU)?
> 
> The original reason was so that we only needed to allocate memory for the
> xlat_area per physical cpu.
> 
> Because of allowing sleeping in a hypercall (via a waitqueue) we can no
> longer do that anyway, so we are back to allocating an xlat_area for every
> vcpu. And we could as well map that at a fixed virtual address I suppose.
> 
> Do we care about vmap() pressure though? Is there a downside to making the
> vmap area as big as we like? I mean even the existing 16GB area is good for
> a million vcpus or so ;)

My original intention was for vmap() to be used for the planned
for per-vCPU stacks (alongside any ioremap() users of course,
of which we - fortunately - shouldn't have too many). So my
concern was really more with regard to other possible users
showing up; the use case here certainly doesn't represent a
limiting factor on it own.

Making the range arbitrarily large of course isn't an option;
raising it up to, say, about 100G wouldn't be problem though
(slightly depending on whether we also need to grow the
global domain page map area - of course that implementation
could also be switched to build upon vmap()).

I guess I'll go with that approach then; likely the 3-level event
channel implementation (Wei - hint, hint) also ought to use this
to simplify the code there.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 07:36:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 07:36: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 1U2d4J-0002q5-KR; Tue, 05 Feb 2013 07:35:51 +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 1U2d4H-0002q0-Dx
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 07:35:49 +0000
Received: from [85.158.138.51:14678] by server-11.bemta-3.messagelabs.com id
	27/B0-10249-456B0115; Tue, 05 Feb 2013 07:35:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360049737!22137646!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 646 invoked from network); 5 Feb 2013 07:35:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 07:35:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 07:34:23 +0000
Message-Id: <5110C40E02000078000BBD10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 07:34:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
	<CD35A54A.59FE4%keir@xen.org>
In-Reply-To: <CD35A54A.59FE4%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:50, Keir Fraser <keir@xen.org> wrote:
> On 04/02/2013 16:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>> this, originally having been at a fixed location outside of Xen virtual
>> address ranges, has seen a number of changes over the years, with
>> the net effect that right now we're requiring an order-1 allocation
>> from the Xen heap. Obviously it would be much better if this got
>> populated with order-0 allocations from the domain heap.
>> 
>> Considering that there's going to be one such area per vCPU (less
>> those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
>> seems undesirable to me to use vmap() for this purpose.
>> 
>> Instead I wonder whether we shouldn't go back to putting this at
>> a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
>> the virtual address range pressure (compared to the vmap()
>> approach as well as for the case that these areas might need
>> extending). Was there any other reason that you moved them out
>> of such a fixed area than wanting to use mostly the same code
>> for PV and HVM (which ought to be possible now that there's a
>> base pointer stored for each vCPU)?
> 
> The original reason was so that we only needed to allocate memory for the
> xlat_area per physical cpu.
> 
> Because of allowing sleeping in a hypercall (via a waitqueue) we can no
> longer do that anyway, so we are back to allocating an xlat_area for every
> vcpu. And we could as well map that at a fixed virtual address I suppose.
> 
> Do we care about vmap() pressure though? Is there a downside to making the
> vmap area as big as we like? I mean even the existing 16GB area is good for
> a million vcpus or so ;)

My original intention was for vmap() to be used for the planned
for per-vCPU stacks (alongside any ioremap() users of course,
of which we - fortunately - shouldn't have too many). So my
concern was really more with regard to other possible users
showing up; the use case here certainly doesn't represent a
limiting factor on it own.

Making the range arbitrarily large of course isn't an option;
raising it up to, say, about 100G wouldn't be problem though
(slightly depending on whether we also need to grow the
global domain page map area - of course that implementation
could also be switched to build upon vmap()).

I guess I'll go with that approach then; likely the 3-level event
channel implementation (Wei - hint, hint) also ought to use this
to simplify the code there.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 07:54:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 07:54: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 1U2dLX-00037L-9d; Tue, 05 Feb 2013 07:53: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 1U2dLW-00037G-5G
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 07:53:38 +0000
Received: from [85.158.138.51:25156] by server-15.bemta-3.messagelabs.com id
	8F/04-25405-18AB0115; Tue, 05 Feb 2013 07:53:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360050816!12290404!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6715 invoked from network); 5 Feb 2013 07:53:36 -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; 5 Feb 2013 07:53:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 07:53:35 +0000
Message-Id: <5110C88E02000078000BBD27@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 07:53:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.com>
	<20130201112716.4d63716c@mantra.us.oracle.com>
	<1359973901.5281.35.camel@zakaz.uk.xensource.com>
	<20130204170449.24408e42@mantra.us.oracle.com>
In-Reply-To: <20130204170449.24408e42@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad@kernel.org" <konrad@kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 02:04, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Mon, 4 Feb 2013 10:31:41 +0000
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
>> On Fri, 2013-02-01 at 19:27 +0000, Mukesh Rathor wrote:
>> > On Fri, 01 Feb 2013 16:24:57 +0000
>> > "Jan Beulich" <jbeulich@suse.com> wrote:
>> > 
> 
>> I don't much care about the gdt vs u naming for the union, although I
>> would probably have gone with the more meaningful gdt if it were me.
>> cscope-wise in emacs I would just use "C-c s t" to look for "gdt.size"
>> etc.
> 
> Unf vim cscope doesn't support that. Moreover, I bet if size was accessed
> via pointer, you couldn't search it that way either. In general, all 
> enterprise software I've worked on prohibited such generic names for 
> the reason people couldn't easily find their usages. I find it very 
> frustrating, and I hope I can continue to be able to read xen code.

I'm sorry, Mukesh, but if everyone else manages to read Xen
code with untagged field names and the like, then I'm afraid
you'll need to find a way for yourself to handle this...

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 07:54:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 07:54: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 1U2dLX-00037L-9d; Tue, 05 Feb 2013 07:53: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 1U2dLW-00037G-5G
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 07:53:38 +0000
Received: from [85.158.138.51:25156] by server-15.bemta-3.messagelabs.com id
	8F/04-25405-18AB0115; Tue, 05 Feb 2013 07:53:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360050816!12290404!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6715 invoked from network); 5 Feb 2013 07:53:36 -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; 5 Feb 2013 07:53:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 07:53:35 +0000
Message-Id: <5110C88E02000078000BBD27@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 07:53:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <50FD3D6202000078000B7CE4@nat28.tlf.novell.com>
	<20130122151241.7ed034f4@mantra.us.oracle.com>
	<50FFABE702000078000B88E1@nat28.tlf.novell.com>
	<20130123144347.78ba0a3f@mantra.us.oracle.com>
	<51010A1802000078000B9027@nat28.tlf.novell.com>
	<20130124151336.311c3456@mantra.us.oracle.com>
	<51024A2602000078000B9786@nat28.tlf.novell.com>
	<1359108703.10051.5.camel@zakaz.uk.xensource.com>
	<51026C3602000078000B9911@nat28.tlf.novell.com>
	<1359110621.10051.25.camel@zakaz.uk.xensource.com>
	<20130128162607.GA7223@konrad-lan.dumpdata.com>
	<20130128185737.55ec65f8@mantra.us.oracle.com>
	<5107B6FC02000078000BA589@nat28.tlf.novell.com>
	<20130131182329.2cb3a225@mantra.us.oracle.com>
	<510BEC590200007800094177@nat28.tlf.novell.com>
	<20130201112716.4d63716c@mantra.us.oracle.com>
	<1359973901.5281.35.camel@zakaz.uk.xensource.com>
	<20130204170449.24408e42@mantra.us.oracle.com>
In-Reply-To: <20130204170449.24408e42@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad@kernel.org" <konrad@kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: PVH + ARM new hypercalls. Was: Re: [PATCH]:
 PVH: specify xen features strings cleany for PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 02:04, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Mon, 4 Feb 2013 10:31:41 +0000
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
>> On Fri, 2013-02-01 at 19:27 +0000, Mukesh Rathor wrote:
>> > On Fri, 01 Feb 2013 16:24:57 +0000
>> > "Jan Beulich" <jbeulich@suse.com> wrote:
>> > 
> 
>> I don't much care about the gdt vs u naming for the union, although I
>> would probably have gone with the more meaningful gdt if it were me.
>> cscope-wise in emacs I would just use "C-c s t" to look for "gdt.size"
>> etc.
> 
> Unf vim cscope doesn't support that. Moreover, I bet if size was accessed
> via pointer, you couldn't search it that way either. In general, all 
> enterprise software I've worked on prohibited such generic names for 
> the reason people couldn't easily find their usages. I find it very 
> frustrating, and I hope I can continue to be able to read xen code.

I'm sorry, Mukesh, but if everyone else manages to read Xen
code with untagged field names and the like, then I'm afraid
you'll need to find a way for yourself to handle this...

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:20:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:20: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 1U2dlI-0003qm-MC; Tue, 05 Feb 2013 08:20:16 +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 1U2dlH-0003qh-Pl
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:20:16 +0000
Received: from [85.158.139.211:17703] by server-10.bemta-5.messagelabs.com id
	46/01-04697-EB0C0115; Tue, 05 Feb 2013 08:20:14 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360052411!20005077!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31279 invoked from network); 5 Feb 2013 08:20:14 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 08:20:14 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U2dl5-0001vz-7H; Tue, 05 Feb 2013 19:20:03 +1100
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 id
	14.01.0438.000; Tue, 5 Feb 2013 19:20:02 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
Thread-Index: AQHOAwL0yIhvjXglT0iFeuC/WNl905hq6m9Q
Date: Tue, 5 Feb 2013 08:20:01 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35659C37@BITCOM1.int.sbss.com.au>
References: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
In-Reply-To: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19614.006
x-tm-as-result: No--37.526600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> QCOW2 disk image gets corrupted when you try to install Service Pack 1
> AFTER installing GPLPV drivers.
> 
> This means, without the pv drivers, everything works fine.
> 
> I tested both RAW and QCOW2 without GPLPV drivers and the installation
> has completed without any error, and the image (at least qcow2) has no
> errors too.
> 
> How to reproduce:
> - Install Windows 7 32-bit guest
> - Check the image with "qemu-img check -f qcow2 -r all" to ensure that
> there still no problems.
> - Install GPLPV drivers 0.11.0.356
> - Try to install Service Pack 1
> - Get an "unknown error" from the installer
> - Check the qcow2 image with "qemu-img check -f qcow2 -r all" and gets
> TONS of integrity errors.
> 

I can't test this just now, but are you saying that the qcow2 volume itself goes corrupt as opposed to, say, the filesystem going corrupt?

If 'qemu-img check' is reporting corruption then I guess it has to be the qcow2 volume... afaik no VM should ever be able to corrupt this so it must be a bug in qemu or some other layer like that. I don't know what would be special about gplpv that could bring this behaviour out though.

What's your feeling on the sp1 side of things? Do you think it could be just a coincidence that it happens during the sp1 install (sp1 install is a pretty big operation), or are you confident that it is the installation of sp1 that triggers it?

Can you run the debug version of gplpv and try it again then send me the output of /var/log/xen/qemu-dm-<domu name>.log?

Also, before you install sp1, please post the output of:

fsutil fsinfo ntfsinfo c:

Someone else may be able to comment on if there is a potential security issue with a DomU being able to 'escape' its box and corrupt it's storage container.

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 Feb 05 08:20:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:20: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 1U2dlI-0003qm-MC; Tue, 05 Feb 2013 08:20:16 +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 1U2dlH-0003qh-Pl
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:20:16 +0000
Received: from [85.158.139.211:17703] by server-10.bemta-5.messagelabs.com id
	46/01-04697-EB0C0115; Tue, 05 Feb 2013 08:20:14 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360052411!20005077!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31279 invoked from network); 5 Feb 2013 08:20:14 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 08:20:14 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U2dl5-0001vz-7H; Tue, 05 Feb 2013 19:20:03 +1100
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 id
	14.01.0438.000; Tue, 5 Feb 2013 19:20:02 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
Thread-Index: AQHOAwL0yIhvjXglT0iFeuC/WNl905hq6m9Q
Date: Tue, 5 Feb 2013 08:20:01 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35659C37@BITCOM1.int.sbss.com.au>
References: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
In-Reply-To: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19614.006
x-tm-as-result: No--37.526600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> QCOW2 disk image gets corrupted when you try to install Service Pack 1
> AFTER installing GPLPV drivers.
> 
> This means, without the pv drivers, everything works fine.
> 
> I tested both RAW and QCOW2 without GPLPV drivers and the installation
> has completed without any error, and the image (at least qcow2) has no
> errors too.
> 
> How to reproduce:
> - Install Windows 7 32-bit guest
> - Check the image with "qemu-img check -f qcow2 -r all" to ensure that
> there still no problems.
> - Install GPLPV drivers 0.11.0.356
> - Try to install Service Pack 1
> - Get an "unknown error" from the installer
> - Check the qcow2 image with "qemu-img check -f qcow2 -r all" and gets
> TONS of integrity errors.
> 

I can't test this just now, but are you saying that the qcow2 volume itself goes corrupt as opposed to, say, the filesystem going corrupt?

If 'qemu-img check' is reporting corruption then I guess it has to be the qcow2 volume... afaik no VM should ever be able to corrupt this so it must be a bug in qemu or some other layer like that. I don't know what would be special about gplpv that could bring this behaviour out though.

What's your feeling on the sp1 side of things? Do you think it could be just a coincidence that it happens during the sp1 install (sp1 install is a pretty big operation), or are you confident that it is the installation of sp1 that triggers it?

Can you run the debug version of gplpv and try it again then send me the output of /var/log/xen/qemu-dm-<domu name>.log?

Also, before you install sp1, please post the output of:

fsutil fsinfo ntfsinfo c:

Someone else may be able to comment on if there is a potential security issue with a DomU being able to 'escape' its box and corrupt it's storage container.

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 Feb 05 08:24:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:24: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 1U2dp1-00040u-G1; Tue, 05 Feb 2013 08:24:07 +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 1U2dp0-00040n-Hl
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:24:06 +0000
Received: from [85.158.137.99:30587] by server-5.bemta-3.messagelabs.com id
	CF/D7-04457-4A1C0115; Tue, 05 Feb 2013 08:24:04 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360052640!12170828!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13118 invoked from network); 5 Feb 2013 08:24:03 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 08:24:03 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U2dop-0005cA-GZ; Tue, 05 Feb 2013 19:23:55 +1100
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 id
	14.01.0438.000; Tue, 5 Feb 2013 19:23:55 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
Thread-Index: AQHOAwL0yIhvjXglT0iFeuC/WNl905hq7gYA
Date: Tue, 5 Feb 2013 08:23:54 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35659C86@BITCOM1.int.sbss.com.au>
References: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
In-Reply-To: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19614.006
x-tm-as-result: No--23.974400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> QCOW2 disk image gets corrupted when you try to install Service Pack 1
> AFTER installing GPLPV drivers.
> 
> 
> How to reproduce:
> - Install Windows 7 32-bit guest
> - Check the image with "qemu-img check -f qcow2 -r all" to ensure that
> there still no problems.
> - Install GPLPV drivers 0.11.0.356
> - Try to install Service Pack 1
> - Get an "unknown error" from the installer
> - Check the qcow2 image with "qemu-img check -f qcow2 -r all" and gets
> TONS of integrity errors.
> 

I forgot to ask - what version of Xen and of Linux?

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 Feb 05 08:24:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:24: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 1U2dp1-00040u-G1; Tue, 05 Feb 2013 08:24:07 +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 1U2dp0-00040n-Hl
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:24:06 +0000
Received: from [85.158.137.99:30587] by server-5.bemta-3.messagelabs.com id
	CF/D7-04457-4A1C0115; Tue, 05 Feb 2013 08:24:04 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360052640!12170828!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13118 invoked from network); 5 Feb 2013 08:24:03 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 08:24:03 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U2dop-0005cA-GZ; Tue, 05 Feb 2013 19:23:55 +1100
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 id
	14.01.0438.000; Tue, 5 Feb 2013 19:23:55 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
Thread-Index: AQHOAwL0yIhvjXglT0iFeuC/WNl905hq7gYA
Date: Tue, 5 Feb 2013 08:23:54 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35659C86@BITCOM1.int.sbss.com.au>
References: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
In-Reply-To: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19614.006
x-tm-as-result: No--23.974400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> QCOW2 disk image gets corrupted when you try to install Service Pack 1
> AFTER installing GPLPV drivers.
> 
> 
> How to reproduce:
> - Install Windows 7 32-bit guest
> - Check the image with "qemu-img check -f qcow2 -r all" to ensure that
> there still no problems.
> - Install GPLPV drivers 0.11.0.356
> - Try to install Service Pack 1
> - Get an "unknown error" from the installer
> - Check the qcow2 image with "qemu-img check -f qcow2 -r all" and gets
> TONS of integrity errors.
> 

I forgot to ask - what version of Xen and of Linux?

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 Feb 05 08:26:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08: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 1U2dqk-00047F-2U; Tue, 05 Feb 2013 08:25:54 +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 1U2dqi-000476-HB
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:25:52 +0000
Received: from [193.109.254.147:7643] by server-8.bemta-14.messagelabs.com id
	C8/35-17325-F02C0115; Tue, 05 Feb 2013 08:25:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360052750!3704505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9819 invoked from network); 5 Feb 2013 08:25:50 -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; 5 Feb 2013 08:25:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:25:49 +0000
Message-Id: <5110D01B02000078000BBD92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:25:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-15419-mainreport@xen.org>
In-Reply-To: <osstest-15419-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [xen-unstable test] 15419: 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 05.02.13 at 07:41, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 15419 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15419/ 
> 
> 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. 15179
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
>  test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15179
>  test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15179
>  test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 15179
>  test-amd64-i386-win           7 windows-install           fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 15179
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15179
>  test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15179
>  test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 15179
>  test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 15179
>  test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15179
>  test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 15179
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 15179
>  test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 15179
>  test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemut-win  7 windows-install          fail REGR. vs. 15179

So this was due to 26503:69398345c10e conflicting with
26486:7648ef657fe7 and 26489:83a3fa9c8434 (the former was
put together much earlier than the other two, but had to be held
back until XSA-34 and XSA-35 went public, and I failed to notice
the conflict). I reverted it until I get a chance to clean this up
properly.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:26:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08: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 1U2dqk-00047F-2U; Tue, 05 Feb 2013 08:25:54 +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 1U2dqi-000476-HB
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:25:52 +0000
Received: from [193.109.254.147:7643] by server-8.bemta-14.messagelabs.com id
	C8/35-17325-F02C0115; Tue, 05 Feb 2013 08:25:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360052750!3704505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9819 invoked from network); 5 Feb 2013 08:25:50 -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; 5 Feb 2013 08:25:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:25:49 +0000
Message-Id: <5110D01B02000078000BBD92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:25:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-15419-mainreport@xen.org>
In-Reply-To: <osstest-15419-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [xen-unstable test] 15419: 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 05.02.13 at 07:41, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 15419 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15419/ 
> 
> 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. 15179
>  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
>  test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15179
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15179
>  test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15179
>  test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 15179
>  test-amd64-i386-win           7 windows-install           fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 15179
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15179
>  test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15179
>  test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 15179
>  test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 15179
>  test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15179
>  test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 15179
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 15179
>  test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 15179
>  test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 15179
>  test-amd64-amd64-xl-qemut-win  7 windows-install          fail REGR. vs. 15179

So this was due to 26503:69398345c10e conflicting with
26486:7648ef657fe7 and 26489:83a3fa9c8434 (the former was
put together much earlier than the other two, but had to be held
back until XSA-34 and XSA-35 went public, and I failed to notice
the conflict). I reverted it until I get a chance to clean this up
properly.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:29:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:29: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 1U2duG-0004K1-Qe; Tue, 05 Feb 2013 08:29: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 1U2duG-0004Jv-4s
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:29:32 +0000
Received: from [193.109.254.147:30688] by server-3.bemta-14.messagelabs.com id
	24/F2-22141-BE2C0115; Tue, 05 Feb 2013 08:29:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360052970!9251440!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11818 invoked from network); 5 Feb 2013 08:29:31 -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; 5 Feb 2013 08:29:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:29:30 +0000
Message-Id: <5110D0F802000078000BBDA6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:29:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andreas Kinzler" <ml-xen-devel@hfp.de>
References: <510FF3C3.9070601@hfp.de>
In-Reply-To: <510FF3C3.9070601@hfp.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
 compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:45, Andreas Kinzler <ml-xen-devel@hfp.de> wrote:
> a) is there some doc on binary compatibility between dom0-kernels and 
> Xen/xen-tools? For example Xen 4.2.1 on my system does not work with 
> xenified OpenSuse 12.2 kernel, while it seems to work with vanilla 3.7. 
> I am interested in some kind of compatibility matrix having various 
> kernels (pvops0, xenified, with versions) on one axis and Xen releases 
> on the other axis. Also having some info about reasons for 
> breakage-by-design would be helpful.

That's very odd, and clearly unintended (and certainly not the
case for me). But of course you'd need to be more specific to
understand what went wrong here.

Our kernels (unless re-compiled) may not work on older Xen
versions, but they're certainly intended to work on newer ones.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:29:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:29: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 1U2duG-0004K1-Qe; Tue, 05 Feb 2013 08:29: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 1U2duG-0004Jv-4s
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:29:32 +0000
Received: from [193.109.254.147:30688] by server-3.bemta-14.messagelabs.com id
	24/F2-22141-BE2C0115; Tue, 05 Feb 2013 08:29:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360052970!9251440!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11818 invoked from network); 5 Feb 2013 08:29:31 -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; 5 Feb 2013 08:29:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:29:30 +0000
Message-Id: <5110D0F802000078000BBDA6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:29:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andreas Kinzler" <ml-xen-devel@hfp.de>
References: <510FF3C3.9070601@hfp.de>
In-Reply-To: <510FF3C3.9070601@hfp.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
 compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:45, Andreas Kinzler <ml-xen-devel@hfp.de> wrote:
> a) is there some doc on binary compatibility between dom0-kernels and 
> Xen/xen-tools? For example Xen 4.2.1 on my system does not work with 
> xenified OpenSuse 12.2 kernel, while it seems to work with vanilla 3.7. 
> I am interested in some kind of compatibility matrix having various 
> kernels (pvops0, xenified, with versions) on one axis and Xen releases 
> on the other axis. Also having some info about reasons for 
> breakage-by-design would be helpful.

That's very odd, and clearly unintended (and certainly not the
case for me). But of course you'd need to be more specific to
understand what went wrong here.

Our kernels (unless re-compiled) may not work on older Xen
versions, but they're certainly intended to work on newer ones.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:38:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08: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 1U2e2l-0004YP-TS; Tue, 05 Feb 2013 08:38:19 +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 1U2e2k-0004YK-C9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:38:18 +0000
Received: from [85.158.139.83:45343] by server-16.bemta-5.messagelabs.com id
	BA/87-14948-9F4C0115; Tue, 05 Feb 2013 08:38:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360053496!25459206!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32008 invoked from network); 5 Feb 2013 08:38:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 08:38:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:38:16 +0000
Message-Id: <5110D30502000078000BBDC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:38:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
	<1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:08, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
>  
>  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
>  
> +
> +ifeq ($(coverage),y)
> +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> +endif

So you had tried out the simplified version of this that I had
suggested, it worked, yet you still don't use it?

> +void init_coverage(void)

As already said previously: __init!

> +#ifdef TEST_COVERAGE
> +void __init init_coverage(void);

And as also already said previously - no __init on declarations!

Please, don't waste reviewers' time by claiming you incorporated
review comments when you really didn't.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:38:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08: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 1U2e2l-0004YP-TS; Tue, 05 Feb 2013 08:38:19 +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 1U2e2k-0004YK-C9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:38:18 +0000
Received: from [85.158.139.83:45343] by server-16.bemta-5.messagelabs.com id
	BA/87-14948-9F4C0115; Tue, 05 Feb 2013 08:38:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360053496!25459206!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32008 invoked from network); 5 Feb 2013 08:38:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 08:38:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:38:16 +0000
Message-Id: <5110D30502000078000BBDC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:38:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
	<1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:08, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
>  
>  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
>  
> +
> +ifeq ($(coverage),y)
> +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> +endif

So you had tried out the simplified version of this that I had
suggested, it worked, yet you still don't use it?

> +void init_coverage(void)

As already said previously: __init!

> +#ifdef TEST_COVERAGE
> +void __init init_coverage(void);

And as also already said previously - no __init on declarations!

Please, don't waste reviewers' time by claiming you incorporated
review comments when you really didn't.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 08:43:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:43: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 1U2e7R-0004mA-Ua; Tue, 05 Feb 2013 08:43:09 +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 1U2e7R-0004m5-CA
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:43:09 +0000
Received: from [85.158.139.83:36425] by server-10.bemta-5.messagelabs.com id
	69/7C-04697-C16C0115; Tue, 05 Feb 2013 08:43:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360053787!28462189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1000 invoked from network); 5 Feb 2013 08:43:08 -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; 5 Feb 2013 08:43:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:42:49 +0000
Message-Id: <5110D41702000078000BBDD4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:42:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
	<1359997733-15769-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359997733-15769-3-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:08, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> +/**
> + * File information
> + * Prefixed with XENCOV_TAG_FILE and a string with filename
> + */
> +struct xencov_file
> +{
> +    uint32_t version;
> +    uint32_t stamp;
> +} __attribute__((packed));

No (unconditional) use of compiler extensions in public headers.
Even more so that you really don't need it here ...

> +
> +/**
> + * Counters information
> + * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
> + */
> +struct xencov_counter
> +{
> +    uint32_t num;
> +    uint64_t values[0];
> +} __attribute__((packed));

... and you can easily avoid it here, and it's pointless again further
down.

The [0] btw also is a compiler extension, and hence you'll also
need to replace 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 Feb 05 08:43:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 08:43: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 1U2e7R-0004mA-Ua; Tue, 05 Feb 2013 08:43:09 +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 1U2e7R-0004m5-CA
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 08:43:09 +0000
Received: from [85.158.139.83:36425] by server-10.bemta-5.messagelabs.com id
	69/7C-04697-C16C0115; Tue, 05 Feb 2013 08:43:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360053787!28462189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1000 invoked from network); 5 Feb 2013 08:43:08 -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; 5 Feb 2013 08:43:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 08:42:49 +0000
Message-Id: <5110D41702000078000BBDD4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 08:42:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
	<1359997733-15769-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1359997733-15769-3-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:08, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> +/**
> + * File information
> + * Prefixed with XENCOV_TAG_FILE and a string with filename
> + */
> +struct xencov_file
> +{
> +    uint32_t version;
> +    uint32_t stamp;
> +} __attribute__((packed));

No (unconditional) use of compiler extensions in public headers.
Even more so that you really don't need it here ...

> +
> +/**
> + * Counters information
> + * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
> + */
> +struct xencov_counter
> +{
> +    uint32_t num;
> +    uint64_t values[0];
> +} __attribute__((packed));

... and you can easily avoid it here, and it's pointless again further
down.

The [0] btw also is a compiler extension, and hence you'll also
need to replace 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 Feb 05 09:13:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09: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 1U2eaB-0005DV-5O; Tue, 05 Feb 2013 09:12:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U2ea9-0005DQ-7w
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:12:49 +0000
Received: from [85.158.143.99:30382] by server-2.bemta-4.messagelabs.com id
	8F/62-01597-01DC0115; Tue, 05 Feb 2013 09:12:48 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360055547!22151158!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29889 invoked from network); 5 Feb 2013 09:12:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:12:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1144725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:12:27 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 5 Feb 2013
	09:12:27 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 09:12:25 +0000
Thread-Topic: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
	compatibility
Thread-Index: Ac4C/6yIJF6lawxrRdmJtbndgbfKlwAgOeTw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153A736453F@LONPMAILBOX01.citrite.net>
References: <510FF3C3.9070601@hfp.de>
In-Reply-To: <510FF3C3.9070601@hfp.de>
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] design questions: blktap & dom0-kernel/Xen
	binary	compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Andreas Kinzler
> Sent: 04 February 2013 17:46
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
> compatibility
> 
> I have two design questions:
> 
> a) is there some doc on binary compatibility between dom0-kernels and
> Xen/xen-tools? For example Xen 4.2.1 on my system does not work with
> xenified OpenSuse 12.2 kernel, while it seems to work with vanilla 3.7.
> I am interested in some kind of compatibility matrix having various
> kernels (pvops0, xenified, with versions) on one axis and Xen releases
> on the other axis. Also having some info about reasons for breakage-by-
> design would be helpful.
> 
> b) is there some doc/info on what is going on with blktap[1,2,3]? I am
> specifically interested in underlying (design) questions, for example
> why blktap was not migrated to vanilla kernel 3.x?

Blktap3 is under development (https://bitbucket.org/tmakatos/blktap3-patches), if you search the xen-devel archives for blktap3 you can get a rough idea of its architecture.

> 
> Regards Andreas
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 05 09:13:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09: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 1U2eaB-0005DV-5O; Tue, 05 Feb 2013 09:12:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U2ea9-0005DQ-7w
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:12:49 +0000
Received: from [85.158.143.99:30382] by server-2.bemta-4.messagelabs.com id
	8F/62-01597-01DC0115; Tue, 05 Feb 2013 09:12:48 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360055547!22151158!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29889 invoked from network); 5 Feb 2013 09:12:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:12:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1144725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:12:27 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 5 Feb 2013
	09:12:27 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 09:12:25 +0000
Thread-Topic: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
	compatibility
Thread-Index: Ac4C/6yIJF6lawxrRdmJtbndgbfKlwAgOeTw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153A736453F@LONPMAILBOX01.citrite.net>
References: <510FF3C3.9070601@hfp.de>
In-Reply-To: <510FF3C3.9070601@hfp.de>
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] design questions: blktap & dom0-kernel/Xen
	binary	compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Andreas Kinzler
> Sent: 04 February 2013 17:46
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
> compatibility
> 
> I have two design questions:
> 
> a) is there some doc on binary compatibility between dom0-kernels and
> Xen/xen-tools? For example Xen 4.2.1 on my system does not work with
> xenified OpenSuse 12.2 kernel, while it seems to work with vanilla 3.7.
> I am interested in some kind of compatibility matrix having various
> kernels (pvops0, xenified, with versions) on one axis and Xen releases
> on the other axis. Also having some info about reasons for breakage-by-
> design would be helpful.
> 
> b) is there some doc/info on what is going on with blktap[1,2,3]? I am
> specifically interested in underlying (design) questions, for example
> why blktap was not migrated to vanilla kernel 3.x?

Blktap3 is under development (https://bitbucket.org/tmakatos/blktap3-patches), if you search the xen-devel archives for blktap3 you can get a rough idea of its architecture.

> 
> Regards Andreas
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 05 09:23:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09: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 1U2ek1-0005Qg-90; Tue, 05 Feb 2013 09:23:01 +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 1U2ek0-0005Qb-J9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:23:00 +0000
Received: from [193.109.254.147:37043] by server-10.bemta-14.messagelabs.com
	id 31/BA-12679-37FC0115; Tue, 05 Feb 2013 09:22:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360056175!8593763!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7601 invoked from network); 5 Feb 2013 09:22:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1145360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:22: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.297.1; Tue, 5 Feb 2013
	09:22:55 +0000
Message-ID: <1360056173.7743.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 09:22:53 +0000
In-Reply-To: <20130204184301.GA31487@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
	<1359986349.7743.46.camel@zakaz.uk.xensource.com>
	<20130204184301.GA31487@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 18:43 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > It just occurred to me, instead of adding lots of individual arguments
> > perhaps packing them into a (e.g.) libxl_save_properties and adding a
> > pointer would be a nicer and more extensible (in the future) interface?
> 
> Something like this (copy&paste from hg diff)?

It's a tricky balance of what goes in the struct and what goes in the
prototype but I didn't imagine putting domid or fd into the struct,
domid because that's how other libxl APIs behave and fd because it isn't
really a property of the save/migrate as such.

Moving flags into the struct could be optional is it complicates the
compat code too much.

> I did not find a way to put also libxl_asyncop_how into
> libxl_save_properties, the checker complains about missing
> LIBXL_EXTERNAL_CALLERS_ONLY.

I think this is fine to remain in the prototype alongside domid etc.

> 
> Olaf
> 
> diff -r 6087ff7a1aea tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -500,18 +500,24 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_init(libxl_domain_config *d_config);
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> 
> +typedef struct {
> +    uint32_t domid;
> +    int fd;
> +    int flags; /* LIBXL_SUSPEND_* */
> +    int max_iters;
> +    int max_factor;
> +} libxl_save_properties;
> +
>  int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> -                         int flags, /* LIBXL_SUSPEND_* */
> -                         const libxl_asyncop_how *ao_how)
> -                         LIBXL_EXTERNAL_CALLERS_ONLY;
> +                                  int flags, /* LIBXL_SUSPEND_* */
> +                                  const libxl_asyncop_how *ao_how)
> +                                  LIBXL_EXTERNAL_CALLERS_ONLY;
>  #ifdef LIBXL_API_VERSION
>  #if LIBXL_API_VERSION == 0x040200
>  #define libxl_domain_suspend libxl_domain_suspend_0x040200
>  #endif
>  #else
> -int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> -                         int flags, /* LIBXL_SUSPEND_* */
> -                         int max_iters, int max_factor,
> +int libxl_domain_suspend(libxl_ctx *ctx, const libxl_save_properties *props,
>                           const libxl_asyncop_how *ao_how)
>                           LIBXL_EXTERNAL_CALLERS_ONLY;
>  #endif
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:23:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09: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 1U2ek1-0005Qg-90; Tue, 05 Feb 2013 09:23:01 +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 1U2ek0-0005Qb-J9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:23:00 +0000
Received: from [193.109.254.147:37043] by server-10.bemta-14.messagelabs.com
	id 31/BA-12679-37FC0115; Tue, 05 Feb 2013 09:22:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360056175!8593763!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7601 invoked from network); 5 Feb 2013 09:22:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1145360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:22: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.297.1; Tue, 5 Feb 2013
	09:22:55 +0000
Message-ID: <1360056173.7743.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 09:22:53 +0000
In-Reply-To: <20130204184301.GA31487@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
	<1359986349.7743.46.camel@zakaz.uk.xensource.com>
	<20130204184301.GA31487@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 18:43 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > It just occurred to me, instead of adding lots of individual arguments
> > perhaps packing them into a (e.g.) libxl_save_properties and adding a
> > pointer would be a nicer and more extensible (in the future) interface?
> 
> Something like this (copy&paste from hg diff)?

It's a tricky balance of what goes in the struct and what goes in the
prototype but I didn't imagine putting domid or fd into the struct,
domid because that's how other libxl APIs behave and fd because it isn't
really a property of the save/migrate as such.

Moving flags into the struct could be optional is it complicates the
compat code too much.

> I did not find a way to put also libxl_asyncop_how into
> libxl_save_properties, the checker complains about missing
> LIBXL_EXTERNAL_CALLERS_ONLY.

I think this is fine to remain in the prototype alongside domid etc.

> 
> Olaf
> 
> diff -r 6087ff7a1aea tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -500,18 +500,24 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_init(libxl_domain_config *d_config);
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> 
> +typedef struct {
> +    uint32_t domid;
> +    int fd;
> +    int flags; /* LIBXL_SUSPEND_* */
> +    int max_iters;
> +    int max_factor;
> +} libxl_save_properties;
> +
>  int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> -                         int flags, /* LIBXL_SUSPEND_* */
> -                         const libxl_asyncop_how *ao_how)
> -                         LIBXL_EXTERNAL_CALLERS_ONLY;
> +                                  int flags, /* LIBXL_SUSPEND_* */
> +                                  const libxl_asyncop_how *ao_how)
> +                                  LIBXL_EXTERNAL_CALLERS_ONLY;
>  #ifdef LIBXL_API_VERSION
>  #if LIBXL_API_VERSION == 0x040200
>  #define libxl_domain_suspend libxl_domain_suspend_0x040200
>  #endif
>  #else
> -int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> -                         int flags, /* LIBXL_SUSPEND_* */
> -                         int max_iters, int max_factor,
> +int libxl_domain_suspend(libxl_ctx *ctx, const libxl_save_properties *props,
>                           const libxl_asyncop_how *ao_how)
>                           LIBXL_EXTERNAL_CALLERS_ONLY;
>  #endif
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:34:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09:34: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 1U2euf-0005mm-5h; Tue, 05 Feb 2013 09:34: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 1U2eud-0005mf-N6
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 09:33:59 +0000
Received: from [85.158.138.51:31270] by server-11.bemta-3.messagelabs.com id
	7F/92-10249-202D0115; Tue, 05 Feb 2013 09:33:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360056833!23745305!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11844 invoked from network); 5 Feb 2013 09:33:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:33:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1145874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:33: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.297.1; Tue, 5 Feb 2013
	09:33:53 +0000
Message-ID: <1360056831.7743.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Mao, Junjie" <junjie.mao@intel.com>
Date: Tue, 5 Feb 2013 09:33:51 +0000
In-Reply-To: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C49@SHSMSX101.ccr.corp.intel.com>
References: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C49@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>
Subject: Re: [Xen-devel] How can I run 3.x dom0 w/o PAE? (Resend w/o format)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 02:49 +0000, Mao, Junjie wrote:
> Hi Jeremy,
> 
> I'm now working in a Xen-based project where some drivers in the Dom0
> kernel (based on Linux 3.0) refuse to work with PAE. Do you know if it
> is possible to run 3.x kernel as non-PAE dom0 on Xen (any version is
> ok)? If so, how can I make it work? Many thanks in advance!

Modern hypervisors support only 32-bit PAE PV and 64-bit PV guests
(along with HVM guests in any mode). dom0 must be a PV guest and
therefore must be either PAE or 64-bit. I'm afraid there is no option
for a plain 32-bit PV guest.

I suggest that you either fix your drivers (which are clearly very
broken if they care about PAE vs non) or switch to a 64-bit dom0.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:34:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09:34: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 1U2euf-0005mm-5h; Tue, 05 Feb 2013 09:34: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 1U2eud-0005mf-N6
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 09:33:59 +0000
Received: from [85.158.138.51:31270] by server-11.bemta-3.messagelabs.com id
	7F/92-10249-202D0115; Tue, 05 Feb 2013 09:33:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360056833!23745305!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11844 invoked from network); 5 Feb 2013 09:33:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:33:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1145874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:33: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.297.1; Tue, 5 Feb 2013
	09:33:53 +0000
Message-ID: <1360056831.7743.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Mao, Junjie" <junjie.mao@intel.com>
Date: Tue, 5 Feb 2013 09:33:51 +0000
In-Reply-To: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C49@SHSMSX101.ccr.corp.intel.com>
References: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C49@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>
Subject: Re: [Xen-devel] How can I run 3.x dom0 w/o PAE? (Resend w/o format)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 02:49 +0000, Mao, Junjie wrote:
> Hi Jeremy,
> 
> I'm now working in a Xen-based project where some drivers in the Dom0
> kernel (based on Linux 3.0) refuse to work with PAE. Do you know if it
> is possible to run 3.x kernel as non-PAE dom0 on Xen (any version is
> ok)? If so, how can I make it work? Many thanks in advance!

Modern hypervisors support only 32-bit PAE PV and 64-bit PV guests
(along with HVM guests in any mode). dom0 must be a PV guest and
therefore must be either PAE or 64-bit. I'm afraid there is no option
for a plain 32-bit PV guest.

I suggest that you either fix your drivers (which are clearly very
broken if they care about PAE vs non) or switch to a 64-bit dom0.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:40:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2f0e-000611-E4; Tue, 05 Feb 2013 09:40:12 +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 1U2f0d-00060u-2l
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:40:11 +0000
Received: from [193.109.254.147:33362] by server-12.bemta-14.messagelabs.com
	id 63/5C-32582-A73D0115; Tue, 05 Feb 2013 09:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360057209!1749685!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15817 invoked from network); 5 Feb 2013 09:40:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1146164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:40: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.297.1; Tue, 5 Feb 2013
	09:40:09 +0000
Message-ID: <1360057206.17017.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Date: Tue, 5 Feb 2013 09:40:06 +0000
In-Reply-To: <510FF3C3.9070601@hfp.de>
References: <510FF3C3.9070601@hfp.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
 compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 17:45 +0000, Andreas Kinzler wrote:
> for example why blktap was not migrated to vanilla kernel 3.x? 

The short answer is that it wasn't felt like it would be acceptable
upstream for various architectural reasons (e.g. it doesn't need to be
done in the kernel at all, hence blktap3).

Please check the list archives, this has been discussed a few times over
the last couple of years.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:40:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2f0e-000611-E4; Tue, 05 Feb 2013 09:40:12 +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 1U2f0d-00060u-2l
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:40:11 +0000
Received: from [193.109.254.147:33362] by server-12.bemta-14.messagelabs.com
	id 63/5C-32582-A73D0115; Tue, 05 Feb 2013 09:40:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360057209!1749685!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15817 invoked from network); 5 Feb 2013 09:40:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1146164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:40: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.297.1; Tue, 5 Feb 2013
	09:40:09 +0000
Message-ID: <1360057206.17017.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Date: Tue, 5 Feb 2013 09:40:06 +0000
In-Reply-To: <510FF3C3.9070601@hfp.de>
References: <510FF3C3.9070601@hfp.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] design questions: blktap & dom0-kernel/Xen binary
 compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 17:45 +0000, Andreas Kinzler wrote:
> for example why blktap was not migrated to vanilla kernel 3.x? 

The short answer is that it wasn't felt like it would be acceptable
upstream for various architectural reasons (e.g. it doesn't need to be
done in the kernel at all, hence blktap3).

Please check the list archives, this has been discussed a few times over
the last couple of years.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:43:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09: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 1U2f3m-0006Du-N5; Tue, 05 Feb 2013 09:43:26 +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 1U2f3l-0006Dk-JS
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:43:25 +0000
Received: from [85.158.138.51:45378] by server-1.bemta-3.messagelabs.com id
	25/BD-08955-C34D0115; Tue, 05 Feb 2013 09:43:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360057379!29243389!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12978 invoked from network); 5 Feb 2013 09:42:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:42:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1146422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:43: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.297.1; Tue, 5 Feb 2013
	09:42:59 +0000
Message-ID: <1360057377.17017.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joe Jin <joe.jin@oracle.com>
Date: Tue, 5 Feb 2013 09:42:57 +0000
In-Reply-To: <5110AAFA.7060602@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
> execute xl-destroy twice crashed my server!

Can you give more details please.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:43:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09: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 1U2f3m-0006Du-N5; Tue, 05 Feb 2013 09:43:26 +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 1U2f3l-0006Dk-JS
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:43:25 +0000
Received: from [85.158.138.51:45378] by server-1.bemta-3.messagelabs.com id
	25/BD-08955-C34D0115; Tue, 05 Feb 2013 09:43:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360057379!29243389!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12978 invoked from network); 5 Feb 2013 09:42:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 09:42:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1146422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 09:43: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.297.1; Tue, 5 Feb 2013
	09:42:59 +0000
Message-ID: <1360057377.17017.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joe Jin <joe.jin@oracle.com>
Date: Tue, 5 Feb 2013 09:42:57 +0000
In-Reply-To: <5110AAFA.7060602@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
> execute xl-destroy twice crashed my server!

Can you give more details please.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:57:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09:57: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 1U2fHF-0006n3-3S; Tue, 05 Feb 2013 09:57:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1U2fHD-0006ma-QP
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:57:19 +0000
Received: from [85.158.138.51:64035] by server-7.bemta-3.messagelabs.com id
	46/60-10367-A77D0115; Tue, 05 Feb 2013 09:57:14 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360058213!23749004!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7716 invoked from network); 5 Feb 2013 09:56:54 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 09:56:54 -0000
Received: (qmail 5951 invoked from network); 5 Feb 2013 11:56:53 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 11:56:52 +0200
Message-ID: <5110D7EB.7090303@gmail.com>
Date: Tue, 05 Feb 2013 11:59:07 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.6.156201, Dats:
	244219, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: 11fd4315181a5a61c33ab1a833375d39.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v1.4.7; Id:
	2m1g3ta.17ik0imk9.1o16q], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45248
Subject: [Xen-devel] What happened to hvm_emulate_one_no_write()?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 see that hvm_emulate_one_no_write() no longer exists in Xen 4.2 (it 
was there in 4.1). Why has it been removed, and is there another way to 
achieve what it did with the more recent Xen versions?

Thanks,
Razvan Cojocaru

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 09:57:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 09:57: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 1U2fHF-0006n3-3S; Tue, 05 Feb 2013 09:57:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1U2fHD-0006ma-QP
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 09:57:19 +0000
Received: from [85.158.138.51:64035] by server-7.bemta-3.messagelabs.com id
	46/60-10367-A77D0115; Tue, 05 Feb 2013 09:57:14 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360058213!23749004!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7716 invoked from network); 5 Feb 2013 09:56:54 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 09:56:54 -0000
Received: (qmail 5951 invoked from network); 5 Feb 2013 11:56:53 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 11:56:52 +0200
Message-ID: <5110D7EB.7090303@gmail.com>
Date: Tue, 05 Feb 2013 11:59:07 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.6.156201, Dats:
	244219, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: 11fd4315181a5a61c33ab1a833375d39.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v1.4.7; Id:
	2m1g3ta.17ik0imk9.1o16q], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45248
Subject: [Xen-devel] What happened to hvm_emulate_one_no_write()?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 see that hvm_emulate_one_no_write() no longer exists in Xen 4.2 (it 
was there in 4.1). Why has it been removed, and is there another way to 
achieve what it did with the more recent Xen versions?

Thanks,
Razvan Cojocaru

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:04:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fNc-0007J7-Hz; Tue, 05 Feb 2013 10:03:56 +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 1U2fNa-0007Iz-UF
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:03:55 +0000
Received: from [85.158.143.99:15222] by server-3.bemta-4.messagelabs.com id
	E5/56-08920-A09D0115; Tue, 05 Feb 2013 10:03:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360058632!24947498!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17174 invoked from network); 5 Feb 2013 10:03:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 10:03:53 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (josoe mo28) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 301ef6p159stFn
	for <xen-devel@lists.xen.org>; Tue, 5 Feb 2013 11:03:52 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 19F871863D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 11:03:52 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f474238aa14e1216e297ddb8fa20e8cdbacfa78a
Message-Id: <f474238aa14e1216e297.1360058631@probook.site>
In-Reply-To: <577b051fca174be9f7b3.1359394360@probook.site>
References: <577b051fca174be9f7b3.1359394360@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Tue, 05 Feb 2013 11:03:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v5] tools: set migration constraints from cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360058505 -3600
# Node ID f474238aa14e1216e297ddb8fa20e8cdbacfa78a
# Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
tools: set migration constraints from cmdline

Add new options to xm/xl migrate to control the process of migration.
The intention is to optionally abort the migration if it takes too long
to migrate a busy guest due to the high number of dirty pages. Currently
the guest is suspended to transfer the remaining dirty pages. This
transfer can take too long, which can confuse the guest if its suspended
for too long.

-M <number>   Number of iterations before final suspend (default: 30)
--max_iters <number>

-m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
--max_factor <factor>

-A            Abort migration instead of doing final suspend.
--abort_if_busy



The changes to libxl change the API, is that approach acceptable?

v5:
 - adjust libxl_domain_suspend prototype, move flags, max_iters,
   max_factor into a new, optional struct libxl_save_properties
 - rename XCFLAGS_DOMSAVE_NOSUSPEND to XCFLAGS_DOMSAVE_ABORT_IF_BUSY
 - rename LIBXL_SUSPEND_NO_FINAL_SUSPEND to LIBXL_SUSPEND_ABORT_IF_BUSY
 - rename variables no_suspend to abort_if_busy
 - rename option -N/--no_suspend to -A/--abort_if_busy
 - update xl.1, extend description of -A option

v4:
 - update default for no_suspend from None to 0 in XendCheckpoint.py:save
 - update logoutput in setMigrateConstraints
 - change xm migrate defaults from None to 0
 - add new options to xl.1
 - fix syntax error in XendDomain.py:domain_migrate_constraints_set
 - fix xm migrate -N option name to match xl migrate

v3:
 - move logic errors in libxl__domain_suspend and fixed help text in
   cmd_table to separate patches
 - fix syntax error in XendCheckpoint.py
 - really pass max_iters and max_factor in libxl__xc_domain_save
 - make libxl_domain_suspend_0x040200 declaration globally visible
 - bump libxenlight.so SONAME from 2.0 to 2.1 due to changed
   libxl_domain_suspend

v2:
 - use LIBXL_API_VERSION and define libxl_domain_suspend_0x040200
 - fix logic error in min_reached check in xc_domain_save
 - add longopts
 - update --help text
 - correct description of migrate --help text

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r fd711ebdce9a -r f474238aa14e docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -391,6 +391,21 @@ Send <config> instead of config file fro
 
 Print huge (!) amount of debug during the migration process.
 
+=item B<-M> I<number>, B<--max_iters> I<number>
+
+Number of iterations before final suspend (default: 30)
+
+=item B<-m> I<factor>, B<--max_factor> I<factor>
+
+Max amount of memory to transfer before final suspend (default: 3*RAM)
+
+=item B<-A>, B<--abort_if_busy>
+
+Abort migration instead of doing final suspend/transfer/resume if the
+guest has still dirty pages after the number of iterations and/or the
+amount of RAM transfered. This avoids long periods of time were the
+guest is suspended.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r fd711ebdce9a -r f474238aa14e tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -43,6 +43,8 @@
 */
 #define DEF_MAX_ITERS   29   /* limit us to 30 times round loop   */
 #define DEF_MAX_FACTOR   3   /* never send more than 3x p2m_size  */
+/* Suspend guest for final transit once number of dirty pages is that low */
+#define DEF_MIN_REMAINING 50
 
 struct save_ctx {
     unsigned long hvirt_start; /* virtual starting address of the hypervisor */
@@ -804,6 +806,7 @@ int xc_domain_save(xc_interface *xch, in
     int rc = 1, frc, i, j, last_iter = 0, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
+    int abort_if_busy = (flags & XCFLAGS_DOMSAVE_ABORT_IF_BUSY);
     int superpages = !!hvm;
     int race = 0, sent_last_iter, skip_this_iter = 0;
     unsigned int sent_this_iter = 0;
@@ -1525,10 +1528,20 @@ int xc_domain_save(xc_interface *xch, in
 
         if ( live )
         {
+            int min_reached = sent_this_iter + skip_this_iter < DEF_MIN_REMAINING;
             if ( (iter >= max_iters) ||
-                 (sent_this_iter+skip_this_iter < 50) ||
+                 min_reached ||
                  (total_sent > dinfo->p2m_size*max_factor) )
             {
+                if ( !min_reached && abort_if_busy )
+                {
+                    ERROR("Live migration aborted, as requested. (guest too busy?)"
+                     " total_sent %lu iter %d, max_iters %u max_factor %u",
+                      total_sent, iter, max_iters, max_factor);
+                    rc = 1;
+                    goto out;
+                }
+
                 DPRINTF("Start last iteration\n");
                 last_iter = 1;
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -28,6 +28,8 @@
 #define XCFLAGS_HVM       4
 #define XCFLAGS_STDVGA    8
 #define XCFLAGS_CHECKPOINT_COMPRESS    16
+#define XCFLAGS_DOMSAVE_ABORT_IF_BUSY  32
+
 #define X86_64_B_SIZE   64 
 #define X86_32_B_SIZE   32
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -5,7 +5,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR = 2.0
+MAJOR = 2.1
 MINOR = 0
 
 XLUMAJOR = 1.0
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -756,8 +756,9 @@ static void domain_suspend_cb(libxl__egc
 
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
-                         const libxl_asyncop_how *ao_how)
+static int __libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                                  const libxl_save_properties *props,
+                                  const libxl_asyncop_how *ao_how)
 {
     AO_CREATE(ctx, domid, ao_how);
     int rc;
@@ -777,8 +778,13 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     dss->domid = domid;
     dss->fd = fd;
     dss->type = type;
-    dss->live = flags & LIBXL_SUSPEND_LIVE;
-    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+    if (props) {
+        dss->live = props->xlflags & LIBXL_SUSPEND_LIVE;
+        dss->debug = props->xlflags & LIBXL_SUSPEND_DEBUG;
+        dss->max_iters = props->max_iters;
+        dss->max_factor = props->max_factor;
+        dss->xlflags = props->xlflags;
+    }
 
     libxl__domain_suspend(egc, dss);
     return AO_INPROGRESS;
@@ -787,6 +793,22 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     return AO_ABORT(rc);
 }
 
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, const libxl_asyncop_how *ao_how)
+{
+    libxl_save_properties props = {
+        .xlflags = flags,
+    };
+    return __libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         const libxl_save_properties *props,
+                         const libxl_asyncop_how *ao_how)
+{
+    return __libxl_domain_suspend(ctx, domid, fd, props, ao_how);
+}
+
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
 {
     int ret;
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -500,12 +500,30 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
+typedef struct {
+    int xlflags; /* LIBXL_SUSPEND_* */
+    int max_iters;
+    int max_factor;
+} libxl_save_properties;
+
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
+                                  int flags, /* LIBXL_SUSPEND_* */
+                                  const libxl_asyncop_how *ao_how)
+                                  LIBXL_EXTERNAL_CALLERS_ONLY;
+#ifdef LIBXL_API_VERSION
+#if LIBXL_API_VERSION == 0x040200
+#define libxl_domain_suspend libxl_domain_suspend_0x040200
+#endif
+#else
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
-                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_save_properties *props,
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
+#endif
+
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
+#define LIBXL_SUSPEND_ABORT_IF_BUSY 4
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
 
     dss->xcflags = (live ? XCFLAGS_LIVE : 0)
           | (debug ? XCFLAGS_DEBUG : 0)
+          | (dss->xlflags & LIBXL_SUSPEND_ABORT_IF_BUSY ? XCFLAGS_DOMSAVE_ABORT_IF_BUSY : 0)
           | (dss->hvm ? XCFLAGS_HVM : 0);
 
     dss->suspend_eventchn = -1;
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2253,6 +2253,9 @@ struct libxl__domain_suspend_state {
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
     int hvm;
+    int max_iters;
+    int max_factor;
+    int xlflags;
     int xcflags;
     int guest_responded;
     const char *dm_savefile;
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl_save_callout.c
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -108,8 +108,8 @@ void libxl__xc_domain_save(libxl__egc *e
     }
 
     const unsigned long argnums[] = {
-        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
-        toolstack_data_fd, toolstack_data_len,
+        dss->domid, dss->max_iters, dss->max_factor, dss->xcflags, dss->hvm,
+        vm_generationid_addr, toolstack_data_fd, toolstack_data_len,
         cbflags,
     };
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
+    int rc = libxl_domain_suspend(ctx, domid, fd, NULL, NULL);
     close(fd);
 
     if (rc < 0)
@@ -3332,6 +3332,7 @@ static void migrate_do_preamble(int send
 }
 
 static void migrate_domain(uint32_t domid, const char *rune, int debug,
+                           int max_iters, int max_factor, int abort_if_busy,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3341,12 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len, flags = LIBXL_SUSPEND_LIVE;
+    int config_len;
+    libxl_save_properties props = {
+        .xlflags = LIBXL_SUSPEND_LIVE,
+        .max_iters = max_iters,
+        .max_factor = max_factor,
+    };
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3359,8 +3365,11 @@ static void migrate_domain(uint32_t domi
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     if (debug)
-        flags |= LIBXL_SUSPEND_DEBUG;
-    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
+        props.xlflags |= LIBXL_SUSPEND_DEBUG;
+    if (abort_if_busy)
+        props.xlflags |= LIBXL_SUSPEND_ABORT_IF_BUSY;
+
+    rc = libxl_domain_suspend(ctx, domid, send_fd, &props, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3753,8 +3762,16 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    int max_iters = 0, max_factor = 0, abort_if_busy = 0;
+    static struct option opts[] = {
+        {"max_iters", 1, 0, 'M'},
+        {"max_factor", 1, 0, 'm'},
+        {"abort_if_busy", 0, 0, 'A'},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:edM:m:A", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3771,6 +3788,15 @@ int main_migrate(int argc, char **argv)
     case 'd':
         debug = 1;
         break;
+    case 'M':
+        max_iters = atoi(optarg);
+        break;
+    case 'm':
+        max_factor = atoi(optarg);
+        break;
+    case 'A':
+        abort_if_busy = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -3786,7 +3812,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, debug, config_filename);
+    migrate_domain(domid, rune, debug, max_iters, max_factor, abort_if_busy, config_filename);
     return 0;
 }
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -147,14 +147,19 @@ struct cmd_spec cmd_table[] = {
       &main_migrate, 0, 1,
       "Migrate a domain to another host",
       "[options] <Domain> <host>",
-      "-h              Print this help.\n"
-      "-C <config>     Send <config> instead of config file from creation.\n"
-      "-s <sshcommand> Use <sshcommand> instead of ssh.  String will be passed\n"
-      "                to sh. If empty, run <host> instead of ssh <host> xl\n"
-      "                migrate-receive [-d -e]\n"
-      "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain.\n"
-      "-d              Print huge (!) amount of debug during the migration process."
+      "-h               Print this help.\n"
+      "-C <config>      Send <config> instead of config file from creation.\n"
+      "-s <sshcommand>  Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                 to sh. If empty, run <host> instead of ssh <host> xl\n"
+      "                 migrate-receive [-d -e]\n"
+      "-e               Do not wait in the background (on <host>) for the death\n"
+      "                 of the domain.\n"
+      "-d               Print huge (!) amount of debug during the migration process.\n"
+      "-M <number>      Number of iterations before final suspend (default: 30)\n"
+      "--max_iters <number>\n"
+      "-m <factor>      Max amount of memory to transfer before final suspend (default: 3*RAM).\n"
+      "--max_factor <factor>\n"
+      "-A, --abort_if_busy Abort migration instead of doing final suspend."
     },
     { "dump-core",
       &main_dump_core, 0, 1,
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xend/XendCheckpoint.py
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -118,9 +118,19 @@ def save(fd, dominfo, network, live, dst
         # enabled. Passing "0" simply uses the defaults compiled into
         # libxenguest; see the comments and/or code in xc_linux_save() for
         # more information.
+        max_iters = dominfo.info.get('max_iters', "0")
+        max_factor = dominfo.info.get('max_factor', "0")
+        abort_if_busy = dominfo.info.get('abort_if_busy', "0")
+        if max_iters == "None":
+            max_iters = "0"
+        if max_factor == "None":
+            max_factor = "0"
+        if abort_if_busy == "None":
+            abort_if_busy = "0"
         cmd = [xen.util.auxbin.pathTo(XC_SAVE), str(fd),
-               str(dominfo.getDomid()), "0", "0", 
-               str(int(live) | (int(hvm) << 2)) ]
+               str(dominfo.getDomid()),
+               max_iters, max_factor,
+               str(int(live) | (int(hvm) << 2) | (int(abort_if_busy) << 5)) ]
         log.debug("[xc_save]: %s", string.join(cmd))
 
         def saveInputHandler(line, tochild):
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py
+++ b/tools/python/xen/xend/XendDomain.py
@@ -1832,6 +1832,18 @@ class XendDomain:
             log.exception(ex)
             raise XendError(str(ex))
 
+    def domain_migrate_constraints_set(self, domid, max_iters, max_factor, abort_if_busy):
+        """Set the Migrate Constraints of this domain.
+        @param domid: Domain ID or Name
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param abort_if_busy: Abort migration instead of doing final suspend
+        """
+        dominfo = self.domain_lookup_nr(domid)
+        if not dominfo:
+            raise XendInvalidDomain(str(domid))
+        dominfo.setMigrateConstraints(max_iters, max_factor, abort_if_busy)
+
     def domain_maxmem_set(self, domid, mem):
         """Set the memory limit for a domain.
 
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -1459,6 +1459,18 @@ class XendDomainInfo:
         pci_conf = self.info['devices'][dev_uuid][1]
         return map(pci_dict_to_bdf_str, pci_conf['devs'])
 
+    def setMigrateConstraints(self, max_iters, max_factor, abort_if_busy):
+        """Set the Migrate Constraints of this domain.
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param abort_if_busy: Abort migration instead of doing final suspend
+        """
+        log.debug("Setting migration constraints of domain %s (%s) to '%s' '%s' '%s'.",
+                  self.info['name_label'], str(self.domid), max_iters, max_factor, abort_if_busy)
+        self.info['max_iters'] = str(max_iters)
+        self.info['max_factor'] = str(max_factor)
+        self.info['abort_if_busy'] = str(abort_if_busy)
+
     def setMemoryTarget(self, target):
         """Set the memory target of this domain.
         @param target: In MiB.
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xm/migrate.py
--- a/tools/python/xen/xm/migrate.py
+++ b/tools/python/xen/xm/migrate.py
@@ -55,6 +55,18 @@ gopts.opt('change_home_server', short='c
           fn=set_true, default=0,
           use="Change home server for managed domains.")
 
+gopts.opt('max_iters', short='M', val='max_iters',
+          fn=set_int, default=0,
+          use="Number of iterations before final suspend (default: 30).")
+
+gopts.opt('max_factor', short='m', val='max_factor',
+          fn=set_int, default=0,
+          use="Max amount of memory to transfer before final suspend (default: 3*RAM).")
+
+gopts.opt('abort_if_busy', short='A',
+          fn=set_true, default=0,
+          use="Abort migration instead of doing final suspend.")
+
 def help():
     return str(gopts)
     
@@ -80,6 +92,10 @@ def main(argv):
         server.xenapi.VM.migrate(vm_ref, dst, bool(opts.vals.live),
                                  other_config)
     else:
+        server.xend.domain.migrate_constraints_set(dom,
+                                                   opts.vals.max_iters,
+                                                   opts.vals.max_factor,
+                                                   opts.vals.abort_if_busy)
         server.xend.domain.migrate(dom, dst, opts.vals.live,
                                    opts.vals.port,
                                    opts.vals.node,

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:04:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fNc-0007J7-Hz; Tue, 05 Feb 2013 10:03:56 +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 1U2fNa-0007Iz-UF
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:03:55 +0000
Received: from [85.158.143.99:15222] by server-3.bemta-4.messagelabs.com id
	E5/56-08920-A09D0115; Tue, 05 Feb 2013 10:03:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360058632!24947498!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17174 invoked from network); 5 Feb 2013 10:03:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 10:03:53 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (josoe mo28) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 301ef6p159stFn
	for <xen-devel@lists.xen.org>; Tue, 5 Feb 2013 11:03:52 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 19F871863D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 11:03:52 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f474238aa14e1216e297ddb8fa20e8cdbacfa78a
Message-Id: <f474238aa14e1216e297.1360058631@probook.site>
In-Reply-To: <577b051fca174be9f7b3.1359394360@probook.site>
References: <577b051fca174be9f7b3.1359394360@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Tue, 05 Feb 2013 11:03:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v5] tools: set migration constraints from cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360058505 -3600
# Node ID f474238aa14e1216e297ddb8fa20e8cdbacfa78a
# Parent  fd711ebdce9a58556d62c2daaf5d49ab06de4a3c
tools: set migration constraints from cmdline

Add new options to xm/xl migrate to control the process of migration.
The intention is to optionally abort the migration if it takes too long
to migrate a busy guest due to the high number of dirty pages. Currently
the guest is suspended to transfer the remaining dirty pages. This
transfer can take too long, which can confuse the guest if its suspended
for too long.

-M <number>   Number of iterations before final suspend (default: 30)
--max_iters <number>

-m <factor>   Max amount of memory to transfer before final suspend (default: 3*RAM)
--max_factor <factor>

-A            Abort migration instead of doing final suspend.
--abort_if_busy



The changes to libxl change the API, is that approach acceptable?

v5:
 - adjust libxl_domain_suspend prototype, move flags, max_iters,
   max_factor into a new, optional struct libxl_save_properties
 - rename XCFLAGS_DOMSAVE_NOSUSPEND to XCFLAGS_DOMSAVE_ABORT_IF_BUSY
 - rename LIBXL_SUSPEND_NO_FINAL_SUSPEND to LIBXL_SUSPEND_ABORT_IF_BUSY
 - rename variables no_suspend to abort_if_busy
 - rename option -N/--no_suspend to -A/--abort_if_busy
 - update xl.1, extend description of -A option

v4:
 - update default for no_suspend from None to 0 in XendCheckpoint.py:save
 - update logoutput in setMigrateConstraints
 - change xm migrate defaults from None to 0
 - add new options to xl.1
 - fix syntax error in XendDomain.py:domain_migrate_constraints_set
 - fix xm migrate -N option name to match xl migrate

v3:
 - move logic errors in libxl__domain_suspend and fixed help text in
   cmd_table to separate patches
 - fix syntax error in XendCheckpoint.py
 - really pass max_iters and max_factor in libxl__xc_domain_save
 - make libxl_domain_suspend_0x040200 declaration globally visible
 - bump libxenlight.so SONAME from 2.0 to 2.1 due to changed
   libxl_domain_suspend

v2:
 - use LIBXL_API_VERSION and define libxl_domain_suspend_0x040200
 - fix logic error in min_reached check in xc_domain_save
 - add longopts
 - update --help text
 - correct description of migrate --help text

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r fd711ebdce9a -r f474238aa14e docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -391,6 +391,21 @@ Send <config> instead of config file fro
 
 Print huge (!) amount of debug during the migration process.
 
+=item B<-M> I<number>, B<--max_iters> I<number>
+
+Number of iterations before final suspend (default: 30)
+
+=item B<-m> I<factor>, B<--max_factor> I<factor>
+
+Max amount of memory to transfer before final suspend (default: 3*RAM)
+
+=item B<-A>, B<--abort_if_busy>
+
+Abort migration instead of doing final suspend/transfer/resume if the
+guest has still dirty pages after the number of iterations and/or the
+amount of RAM transfered. This avoids long periods of time were the
+guest is suspended.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r fd711ebdce9a -r f474238aa14e tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -43,6 +43,8 @@
 */
 #define DEF_MAX_ITERS   29   /* limit us to 30 times round loop   */
 #define DEF_MAX_FACTOR   3   /* never send more than 3x p2m_size  */
+/* Suspend guest for final transit once number of dirty pages is that low */
+#define DEF_MIN_REMAINING 50
 
 struct save_ctx {
     unsigned long hvirt_start; /* virtual starting address of the hypervisor */
@@ -804,6 +806,7 @@ int xc_domain_save(xc_interface *xch, in
     int rc = 1, frc, i, j, last_iter = 0, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
+    int abort_if_busy = (flags & XCFLAGS_DOMSAVE_ABORT_IF_BUSY);
     int superpages = !!hvm;
     int race = 0, sent_last_iter, skip_this_iter = 0;
     unsigned int sent_this_iter = 0;
@@ -1525,10 +1528,20 @@ int xc_domain_save(xc_interface *xch, in
 
         if ( live )
         {
+            int min_reached = sent_this_iter + skip_this_iter < DEF_MIN_REMAINING;
             if ( (iter >= max_iters) ||
-                 (sent_this_iter+skip_this_iter < 50) ||
+                 min_reached ||
                  (total_sent > dinfo->p2m_size*max_factor) )
             {
+                if ( !min_reached && abort_if_busy )
+                {
+                    ERROR("Live migration aborted, as requested. (guest too busy?)"
+                     " total_sent %lu iter %d, max_iters %u max_factor %u",
+                      total_sent, iter, max_iters, max_factor);
+                    rc = 1;
+                    goto out;
+                }
+
                 DPRINTF("Start last iteration\n");
                 last_iter = 1;
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -28,6 +28,8 @@
 #define XCFLAGS_HVM       4
 #define XCFLAGS_STDVGA    8
 #define XCFLAGS_CHECKPOINT_COMPRESS    16
+#define XCFLAGS_DOMSAVE_ABORT_IF_BUSY  32
+
 #define X86_64_B_SIZE   64 
 #define X86_32_B_SIZE   32
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -5,7 +5,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR = 2.0
+MAJOR = 2.1
 MINOR = 0
 
 XLUMAJOR = 1.0
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -756,8 +756,9 @@ static void domain_suspend_cb(libxl__egc
 
 }
 
-int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
-                         const libxl_asyncop_how *ao_how)
+static int __libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                                  const libxl_save_properties *props,
+                                  const libxl_asyncop_how *ao_how)
 {
     AO_CREATE(ctx, domid, ao_how);
     int rc;
@@ -777,8 +778,13 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     dss->domid = domid;
     dss->fd = fd;
     dss->type = type;
-    dss->live = flags & LIBXL_SUSPEND_LIVE;
-    dss->debug = flags & LIBXL_SUSPEND_DEBUG;
+    if (props) {
+        dss->live = props->xlflags & LIBXL_SUSPEND_LIVE;
+        dss->debug = props->xlflags & LIBXL_SUSPEND_DEBUG;
+        dss->max_iters = props->max_iters;
+        dss->max_factor = props->max_factor;
+        dss->xlflags = props->xlflags;
+    }
 
     libxl__domain_suspend(egc, dss);
     return AO_INPROGRESS;
@@ -787,6 +793,22 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     return AO_ABORT(rc);
 }
 
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
+                         int flags, const libxl_asyncop_how *ao_how)
+{
+    libxl_save_properties props = {
+        .xlflags = flags,
+    };
+    return __libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
+}
+
+int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
+                         const libxl_save_properties *props,
+                         const libxl_asyncop_how *ao_how)
+{
+    return __libxl_domain_suspend(ctx, domid, fd, props, ao_how);
+}
+
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
 {
     int ret;
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -500,12 +500,30 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_init(libxl_domain_config *d_config);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 
+typedef struct {
+    int xlflags; /* LIBXL_SUSPEND_* */
+    int max_iters;
+    int max_factor;
+} libxl_save_properties;
+
+int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
+                                  int flags, /* LIBXL_SUSPEND_* */
+                                  const libxl_asyncop_how *ao_how)
+                                  LIBXL_EXTERNAL_CALLERS_ONLY;
+#ifdef LIBXL_API_VERSION
+#if LIBXL_API_VERSION == 0x040200
+#define libxl_domain_suspend libxl_domain_suspend_0x040200
+#endif
+#else
 int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
-                         int flags, /* LIBXL_SUSPEND_* */
+                         const libxl_save_properties *props,
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
+#endif
+
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
+#define LIBXL_SUSPEND_ABORT_IF_BUSY 4
 
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1240,6 +1240,7 @@ void libxl__domain_suspend(libxl__egc *e
 
     dss->xcflags = (live ? XCFLAGS_LIVE : 0)
           | (debug ? XCFLAGS_DEBUG : 0)
+          | (dss->xlflags & LIBXL_SUSPEND_ABORT_IF_BUSY ? XCFLAGS_DOMSAVE_ABORT_IF_BUSY : 0)
           | (dss->hvm ? XCFLAGS_HVM : 0);
 
     dss->suspend_eventchn = -1;
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2253,6 +2253,9 @@ struct libxl__domain_suspend_state {
     xc_evtchn *xce; /* event channel handle */
     int suspend_eventchn;
     int hvm;
+    int max_iters;
+    int max_factor;
+    int xlflags;
     int xcflags;
     int guest_responded;
     const char *dm_savefile;
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/libxl_save_callout.c
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -108,8 +108,8 @@ void libxl__xc_domain_save(libxl__egc *e
     }
 
     const unsigned long argnums[] = {
-        dss->domid, 0, 0, dss->xcflags, dss->hvm, vm_generationid_addr,
-        toolstack_data_fd, toolstack_data_len,
+        dss->domid, dss->max_iters, dss->max_factor, dss->xcflags, dss->hvm,
+        vm_generationid_addr, toolstack_data_fd, toolstack_data_len,
         cbflags,
     };
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3172,7 +3172,7 @@ static int save_domain(uint32_t domid, c
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
+    int rc = libxl_domain_suspend(ctx, domid, fd, NULL, NULL);
     close(fd);
 
     if (rc < 0)
@@ -3332,6 +3332,7 @@ static void migrate_do_preamble(int send
 }
 
 static void migrate_domain(uint32_t domid, const char *rune, int debug,
+                           int max_iters, int max_factor, int abort_if_busy,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3341,12 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len, flags = LIBXL_SUSPEND_LIVE;
+    int config_len;
+    libxl_save_properties props = {
+        .xlflags = LIBXL_SUSPEND_LIVE,
+        .max_iters = max_iters,
+        .max_factor = max_factor,
+    };
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3359,8 +3365,11 @@ static void migrate_domain(uint32_t domi
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     if (debug)
-        flags |= LIBXL_SUSPEND_DEBUG;
-    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
+        props.xlflags |= LIBXL_SUSPEND_DEBUG;
+    if (abort_if_busy)
+        props.xlflags |= LIBXL_SUSPEND_ABORT_IF_BUSY;
+
+    rc = libxl_domain_suspend(ctx, domid, send_fd, &props, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3753,8 +3762,16 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    int max_iters = 0, max_factor = 0, abort_if_busy = 0;
+    static struct option opts[] = {
+        {"max_iters", 1, 0, 'M'},
+        {"max_factor", 1, 0, 'm'},
+        {"abort_if_busy", 0, 0, 'A'},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:edM:m:A", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3771,6 +3788,15 @@ int main_migrate(int argc, char **argv)
     case 'd':
         debug = 1;
         break;
+    case 'M':
+        max_iters = atoi(optarg);
+        break;
+    case 'm':
+        max_factor = atoi(optarg);
+        break;
+    case 'A':
+        abort_if_busy = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -3786,7 +3812,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, debug, config_filename);
+    migrate_domain(domid, rune, debug, max_iters, max_factor, abort_if_busy, config_filename);
     return 0;
 }
 
diff -r fd711ebdce9a -r f474238aa14e tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -147,14 +147,19 @@ struct cmd_spec cmd_table[] = {
       &main_migrate, 0, 1,
       "Migrate a domain to another host",
       "[options] <Domain> <host>",
-      "-h              Print this help.\n"
-      "-C <config>     Send <config> instead of config file from creation.\n"
-      "-s <sshcommand> Use <sshcommand> instead of ssh.  String will be passed\n"
-      "                to sh. If empty, run <host> instead of ssh <host> xl\n"
-      "                migrate-receive [-d -e]\n"
-      "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain.\n"
-      "-d              Print huge (!) amount of debug during the migration process."
+      "-h               Print this help.\n"
+      "-C <config>      Send <config> instead of config file from creation.\n"
+      "-s <sshcommand>  Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                 to sh. If empty, run <host> instead of ssh <host> xl\n"
+      "                 migrate-receive [-d -e]\n"
+      "-e               Do not wait in the background (on <host>) for the death\n"
+      "                 of the domain.\n"
+      "-d               Print huge (!) amount of debug during the migration process.\n"
+      "-M <number>      Number of iterations before final suspend (default: 30)\n"
+      "--max_iters <number>\n"
+      "-m <factor>      Max amount of memory to transfer before final suspend (default: 3*RAM).\n"
+      "--max_factor <factor>\n"
+      "-A, --abort_if_busy Abort migration instead of doing final suspend."
     },
     { "dump-core",
       &main_dump_core, 0, 1,
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xend/XendCheckpoint.py
--- a/tools/python/xen/xend/XendCheckpoint.py
+++ b/tools/python/xen/xend/XendCheckpoint.py
@@ -118,9 +118,19 @@ def save(fd, dominfo, network, live, dst
         # enabled. Passing "0" simply uses the defaults compiled into
         # libxenguest; see the comments and/or code in xc_linux_save() for
         # more information.
+        max_iters = dominfo.info.get('max_iters', "0")
+        max_factor = dominfo.info.get('max_factor', "0")
+        abort_if_busy = dominfo.info.get('abort_if_busy', "0")
+        if max_iters == "None":
+            max_iters = "0"
+        if max_factor == "None":
+            max_factor = "0"
+        if abort_if_busy == "None":
+            abort_if_busy = "0"
         cmd = [xen.util.auxbin.pathTo(XC_SAVE), str(fd),
-               str(dominfo.getDomid()), "0", "0", 
-               str(int(live) | (int(hvm) << 2)) ]
+               str(dominfo.getDomid()),
+               max_iters, max_factor,
+               str(int(live) | (int(hvm) << 2) | (int(abort_if_busy) << 5)) ]
         log.debug("[xc_save]: %s", string.join(cmd))
 
         def saveInputHandler(line, tochild):
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xend/XendDomain.py
--- a/tools/python/xen/xend/XendDomain.py
+++ b/tools/python/xen/xend/XendDomain.py
@@ -1832,6 +1832,18 @@ class XendDomain:
             log.exception(ex)
             raise XendError(str(ex))
 
+    def domain_migrate_constraints_set(self, domid, max_iters, max_factor, abort_if_busy):
+        """Set the Migrate Constraints of this domain.
+        @param domid: Domain ID or Name
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param abort_if_busy: Abort migration instead of doing final suspend
+        """
+        dominfo = self.domain_lookup_nr(domid)
+        if not dominfo:
+            raise XendInvalidDomain(str(domid))
+        dominfo.setMigrateConstraints(max_iters, max_factor, abort_if_busy)
+
     def domain_maxmem_set(self, domid, mem):
         """Set the memory limit for a domain.
 
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -1459,6 +1459,18 @@ class XendDomainInfo:
         pci_conf = self.info['devices'][dev_uuid][1]
         return map(pci_dict_to_bdf_str, pci_conf['devs'])
 
+    def setMigrateConstraints(self, max_iters, max_factor, abort_if_busy):
+        """Set the Migrate Constraints of this domain.
+        @param max_iters: Number of iterations before final suspend
+        @param max_factor: Max amount of memory to transfer before final suspend
+        @param abort_if_busy: Abort migration instead of doing final suspend
+        """
+        log.debug("Setting migration constraints of domain %s (%s) to '%s' '%s' '%s'.",
+                  self.info['name_label'], str(self.domid), max_iters, max_factor, abort_if_busy)
+        self.info['max_iters'] = str(max_iters)
+        self.info['max_factor'] = str(max_factor)
+        self.info['abort_if_busy'] = str(abort_if_busy)
+
     def setMemoryTarget(self, target):
         """Set the memory target of this domain.
         @param target: In MiB.
diff -r fd711ebdce9a -r f474238aa14e tools/python/xen/xm/migrate.py
--- a/tools/python/xen/xm/migrate.py
+++ b/tools/python/xen/xm/migrate.py
@@ -55,6 +55,18 @@ gopts.opt('change_home_server', short='c
           fn=set_true, default=0,
           use="Change home server for managed domains.")
 
+gopts.opt('max_iters', short='M', val='max_iters',
+          fn=set_int, default=0,
+          use="Number of iterations before final suspend (default: 30).")
+
+gopts.opt('max_factor', short='m', val='max_factor',
+          fn=set_int, default=0,
+          use="Max amount of memory to transfer before final suspend (default: 3*RAM).")
+
+gopts.opt('abort_if_busy', short='A',
+          fn=set_true, default=0,
+          use="Abort migration instead of doing final suspend.")
+
 def help():
     return str(gopts)
     
@@ -80,6 +92,10 @@ def main(argv):
         server.xenapi.VM.migrate(vm_ref, dst, bool(opts.vals.live),
                                  other_config)
     else:
+        server.xend.domain.migrate_constraints_set(dom,
+                                                   opts.vals.max_iters,
+                                                   opts.vals.max_factor,
+                                                   opts.vals.abort_if_busy)
         server.xend.domain.migrate(dom, dst, opts.vals.live,
                                    opts.vals.port,
                                    opts.vals.node,

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:09:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fSZ-0007Vy-HJ; Tue, 05 Feb 2013 10:09:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2fSX-0007Vs-4H
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:09:01 +0000
Received: from [85.158.143.99:7875] by server-2.bemta-4.messagelabs.com id
	E4/E7-01597-C3AD0115; Tue, 05 Feb 2013 10:09:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360058939!17972341!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12507 invoked from network); 5 Feb 2013 10:09:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:09:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1147613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:09: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.297.1; Tue, 5 Feb 2013
	10:09:00 +0000
Message-ID: <1360058938.17017.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 10:08:58 +0000
In-Reply-To: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
References: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "port-xen@netbsd.org" <port-xen@netbsd.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: add suport for NetBSD gntdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTExLTI4IGF0IDEzOjIwICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gQWRkIE9TIHNwZWNpZmljIGhhbmRsZXJzIGZvciBOZXRCU0QgZ250ZGV2LiBUaGUgbWFpbiBk
aWZmZXJlbmNlIGlzCj4gdGhhdCBOZXRCU0QgcGFzc2VzIHRoZSBWQSB3aGVyZSB0aGUgZ3JhbnQg
c2hvdWxkIGJlIHNldCBpbnNpZGUgdGhlCj4gSU9DVExfR05UREVWX01BUF9HUkFOVF9SRUYgaW9j
dGwsIGluc3RlYWQgb2YgdXNpbmcgbW1hcCAodGhpcyBpcyBkdWUKPiB0byBPUyBjb25zdHJhaW50
cykuCj4gCj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+CgpEaWQgdGhlIGtlcm5lbCBzaWRlIG9mIHRoaXMgZ28gaW50byBOZXRCU0QgaW4gdGhl
IGVuZD8KCklPVyBzaG91bGQgSSBhcHBseT8gKEkndmUganVzdCBzcG90dGVkIHRoZSBWMiBpbiBt
eSBxdWV1ZSwgc28gaXQgd291bGQKYmUgdGhhdCBvbmUgaWYgYW55dGhpbmcpCgpJYW4uCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:09:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fSZ-0007Vy-HJ; Tue, 05 Feb 2013 10:09:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2fSX-0007Vs-4H
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:09:01 +0000
Received: from [85.158.143.99:7875] by server-2.bemta-4.messagelabs.com id
	E4/E7-01597-C3AD0115; Tue, 05 Feb 2013 10:09:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360058939!17972341!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12507 invoked from network); 5 Feb 2013 10:09:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:09:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1147613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:09: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.297.1; Tue, 5 Feb 2013
	10:09:00 +0000
Message-ID: <1360058938.17017.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 10:08:58 +0000
In-Reply-To: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
References: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "port-xen@netbsd.org" <port-xen@netbsd.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: add suport for NetBSD gntdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCAyMDEyLTExLTI4IGF0IDEzOjIwICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gQWRkIE9TIHNwZWNpZmljIGhhbmRsZXJzIGZvciBOZXRCU0QgZ250ZGV2LiBUaGUgbWFpbiBk
aWZmZXJlbmNlIGlzCj4gdGhhdCBOZXRCU0QgcGFzc2VzIHRoZSBWQSB3aGVyZSB0aGUgZ3JhbnQg
c2hvdWxkIGJlIHNldCBpbnNpZGUgdGhlCj4gSU9DVExfR05UREVWX01BUF9HUkFOVF9SRUYgaW9j
dGwsIGluc3RlYWQgb2YgdXNpbmcgbW1hcCAodGhpcyBpcyBkdWUKPiB0byBPUyBjb25zdHJhaW50
cykuCj4gCj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+CgpEaWQgdGhlIGtlcm5lbCBzaWRlIG9mIHRoaXMgZ28gaW50byBOZXRCU0QgaW4gdGhl
IGVuZD8KCklPVyBzaG91bGQgSSBhcHBseT8gKEkndmUganVzdCBzcG90dGVkIHRoZSBWMiBpbiBt
eSBxdWV1ZSwgc28gaXQgd291bGQKYmUgdGhhdCBvbmUgaWYgYW55dGhpbmcpCgpJYW4uCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:16:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fZ8-0007p7-CH; Tue, 05 Feb 2013 10:15:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2fZ7-0007p1-07
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:15:49 +0000
Received: from [193.109.254.147:3093] by server-10.bemta-14.messagelabs.com id
	69/88-12679-4DBD0115; Tue, 05 Feb 2013 10:15:48 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360059347!10129580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11275 invoked from network); 5 Feb 2013 10:15:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:15:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1147994"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:15:48 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 5 Feb 2013
	10:15:47 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Tue, 5 Feb 2013 10:15:47 +0000
Thread-Topic: [PATCH 1/2] Adding support for coverage information
Thread-Index: Ac4DicQjGSJdi6LOTNaegxnocMP16A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458362@LONPMAILBOX01.citrite.net>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
	<1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
	<5110D30502000078000BBDC6@nat28.tlf.novell.com>
In-Reply-To: <5110D30502000078000BBDC6@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: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 08:38 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 18:08, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
> >  
> >  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
> >  
> > +
> > +ifeq ($(coverage),y)
> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> > +endif
> 
> So you had tried out the simplified version of this that I had
> suggested, it worked, yet you still don't use it?
> 

Yes, I forget to explain why I didn't change this (apart I forgot to
remove the extra blank line).

It seems that if I change this code as you suggested the code compile
correctly but if I extract the informations there are less data.
Now I don't understand if this is just an error or something more
critical.

Currently I'm trying to understand which file change and why.

It seems that these files are compiled with different options

xen/common/libelf/libelf-loader.o
xen/common/libelf/libelf.o
xen/common/libelf/libelf-dominfo.o
xen/common/libelf/built_in.o
xen/common/libelf/libelf-tools.o
xen/common/libelf/libelf-temp.o

I'll try to understand better what's going on.

> > +void init_coverage(void)
> 
> As already said previously: __init!
> 
> > +#ifdef TEST_COVERAGE
> > +void __init init_coverage(void);
> 
> And as also already said previously - no __init on declarations!
> 

Got it, I checked code and understood. First patch the __init was
correctly in the .c file and somebody complaints so I moved to .h (or
probably I misunderstood and the solution was only to remove from
header).

> Please, don't waste reviewers' time by claiming you incorporated
> review comments when you really didn't.
> 
> Jan
> 

Frediano

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:16:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fZ8-0007p7-CH; Tue, 05 Feb 2013 10:15:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2fZ7-0007p1-07
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:15:49 +0000
Received: from [193.109.254.147:3093] by server-10.bemta-14.messagelabs.com id
	69/88-12679-4DBD0115; Tue, 05 Feb 2013 10:15:48 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360059347!10129580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11275 invoked from network); 5 Feb 2013 10:15:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:15:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1147994"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:15:48 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 5 Feb 2013
	10:15:47 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Tue, 5 Feb 2013 10:15:47 +0000
Thread-Topic: [PATCH 1/2] Adding support for coverage information
Thread-Index: Ac4DicQjGSJdi6LOTNaegxnocMP16A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458362@LONPMAILBOX01.citrite.net>
References: <1359997733-15769-1-git-send-email-frediano.ziglio@citrix.com>
	<1359997733-15769-2-git-send-email-frediano.ziglio@citrix.com>
	<5110D30502000078000BBDC6@nat28.tlf.novell.com>
In-Reply-To: <5110D30502000078000BBDC6@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: George Dunlap <George.Dunlap@eu.citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 08:38 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 18:08, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -103,6 +103,11 @@ subdir-all := $(subdir-y) $(subdir-n)
> >  
> >  $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
> >  
> > +
> > +ifeq ($(coverage),y)
> > +$(filter-out %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
> > +endif
> 
> So you had tried out the simplified version of this that I had
> suggested, it worked, yet you still don't use it?
> 

Yes, I forget to explain why I didn't change this (apart I forgot to
remove the extra blank line).

It seems that if I change this code as you suggested the code compile
correctly but if I extract the informations there are less data.
Now I don't understand if this is just an error or something more
critical.

Currently I'm trying to understand which file change and why.

It seems that these files are compiled with different options

xen/common/libelf/libelf-loader.o
xen/common/libelf/libelf.o
xen/common/libelf/libelf-dominfo.o
xen/common/libelf/built_in.o
xen/common/libelf/libelf-tools.o
xen/common/libelf/libelf-temp.o

I'll try to understand better what's going on.

> > +void init_coverage(void)
> 
> As already said previously: __init!
> 
> > +#ifdef TEST_COVERAGE
> > +void __init init_coverage(void);
> 
> And as also already said previously - no __init on declarations!
> 

Got it, I checked code and understood. First patch the __init was
correctly in the .c file and somebody complaints so I moved to .h (or
probably I misunderstood and the solution was only to remove from
header).

> Please, don't waste reviewers' time by claiming you incorporated
> review comments when you really didn't.
> 
> Jan
> 

Frediano

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:19:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2fct-0007wi-1l; Tue, 05 Feb 2013 10:19: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 1U2fcs-0007wd-2C
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:19:42 +0000
Received: from [193.109.254.147:55026] by server-4.bemta-14.messagelabs.com id
	F6/74-20719-DBCD0115; Tue, 05 Feb 2013 10:19:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360059580!1756508!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10158 invoked from network); 5 Feb 2013 10:19:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:19:41 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	10:19:40 +0000
Message-ID: <5110DCBB.6050802@citrix.com>
Date: Tue, 5 Feb 2013 11:19:39 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
	<1360058938.17017.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360058938.17017.10.camel@zakaz.uk.xensource.com>
Cc: "port-xen@netbsd.org" <port-xen@netbsd.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: add suport for NetBSD gntdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMDUvMDIvMTMgMTE6MDgsIElhbiBDYW1wYmVsbCB3cm90ZToKPiBPbiBXZWQsIDIwMTItMTEt
MjggYXQgMTM6MjAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gQWRkIE9TIHNwZWNp
ZmljIGhhbmRsZXJzIGZvciBOZXRCU0QgZ250ZGV2LiBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzCj4+
IHRoYXQgTmV0QlNEIHBhc3NlcyB0aGUgVkEgd2hlcmUgdGhlIGdyYW50IHNob3VsZCBiZSBzZXQg
aW5zaWRlIHRoZQo+PiBJT0NUTF9HTlRERVZfTUFQX0dSQU5UX1JFRiBpb2N0bCwgaW5zdGVhZCBv
ZiB1c2luZyBtbWFwICh0aGlzIGlzIGR1ZQo+PiB0byBPUyBjb25zdHJhaW50cykuCj4+Cj4+IFNp
Z25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+IAo+
IERpZCB0aGUga2VybmVsIHNpZGUgb2YgdGhpcyBnbyBpbnRvIE5ldEJTRCBpbiB0aGUgZW5kPwoK
Tm8sIHRoZSBrZXJuZWwgc2lkZSBvbmx5IHdvcmtlZCB3aXRoIFBWIGd1ZXN0cywgaXQgZmFpbGVk
IHRvIG1hcCBncmFudApyZWZzIGZyb20gSFZNIGd1ZXN0cy4gU29sdmluZyB0aGlzIHJlcXVpcmVz
IHF1aXRlIGEgbG90IG9mIGNoYW5nZXMgaW4KdGhlIGNvZGUsIHdoaWNoIHJpZ2h0IG5vdyBJIGRv
bid0IGhhdmUgdGltZSB0byBwZXJmb3JtLCBzbyBob2xkIG9uIHRoZQpsaWJ4Yy9saWJ4bCBjaGFu
Z2VzIGZvciBub3cuCgo+IElPVyBzaG91bGQgSSBhcHBseT8gKEkndmUganVzdCBzcG90dGVkIHRo
ZSBWMiBpbiBteSBxdWV1ZSwgc28gaXQgd291bGQKPiBiZSB0aGF0IG9uZSBpZiBhbnl0aGluZykK
PiAKPiBJYW4uCj4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:19:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2fct-0007wi-1l; Tue, 05 Feb 2013 10:19: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 1U2fcs-0007wd-2C
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:19:42 +0000
Received: from [193.109.254.147:55026] by server-4.bemta-14.messagelabs.com id
	F6/74-20719-DBCD0115; Tue, 05 Feb 2013 10:19:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360059580!1756508!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10158 invoked from network); 5 Feb 2013 10:19:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:19:41 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	10:19:40 +0000
Message-ID: <5110DCBB.6050802@citrix.com>
Date: Tue, 5 Feb 2013 11:19:39 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
	<1360058938.17017.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360058938.17017.10.camel@zakaz.uk.xensource.com>
Cc: "port-xen@netbsd.org" <port-xen@netbsd.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: add suport for NetBSD gntdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMDUvMDIvMTMgMTE6MDgsIElhbiBDYW1wYmVsbCB3cm90ZToKPiBPbiBXZWQsIDIwMTItMTEt
MjggYXQgMTM6MjAgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gQWRkIE9TIHNwZWNp
ZmljIGhhbmRsZXJzIGZvciBOZXRCU0QgZ250ZGV2LiBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzCj4+
IHRoYXQgTmV0QlNEIHBhc3NlcyB0aGUgVkEgd2hlcmUgdGhlIGdyYW50IHNob3VsZCBiZSBzZXQg
aW5zaWRlIHRoZQo+PiBJT0NUTF9HTlRERVZfTUFQX0dSQU5UX1JFRiBpb2N0bCwgaW5zdGVhZCBv
ZiB1c2luZyBtbWFwICh0aGlzIGlzIGR1ZQo+PiB0byBPUyBjb25zdHJhaW50cykuCj4+Cj4+IFNp
Z25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+IAo+
IERpZCB0aGUga2VybmVsIHNpZGUgb2YgdGhpcyBnbyBpbnRvIE5ldEJTRCBpbiB0aGUgZW5kPwoK
Tm8sIHRoZSBrZXJuZWwgc2lkZSBvbmx5IHdvcmtlZCB3aXRoIFBWIGd1ZXN0cywgaXQgZmFpbGVk
IHRvIG1hcCBncmFudApyZWZzIGZyb20gSFZNIGd1ZXN0cy4gU29sdmluZyB0aGlzIHJlcXVpcmVz
IHF1aXRlIGEgbG90IG9mIGNoYW5nZXMgaW4KdGhlIGNvZGUsIHdoaWNoIHJpZ2h0IG5vdyBJIGRv
bid0IGhhdmUgdGltZSB0byBwZXJmb3JtLCBzbyBob2xkIG9uIHRoZQpsaWJ4Yy9saWJ4bCBjaGFu
Z2VzIGZvciBub3cuCgo+IElPVyBzaG91bGQgSSBhcHBseT8gKEkndmUganVzdCBzcG90dGVkIHRo
ZSBWMiBpbiBteSBxdWV1ZSwgc28gaXQgd291bGQKPiBiZSB0aGF0IG9uZSBpZiBhbnl0aGluZykK
PiAKPiBJYW4uCj4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:22:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2ffl-00086u-Ka; Tue, 05 Feb 2013 10:22:41 +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 1U2ffj-00086p-Ob
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:22:39 +0000
Received: from [85.158.143.35:14603] by server-3.bemta-4.messagelabs.com id
	13/F9-08920-F6DD0115; Tue, 05 Feb 2013 10:22:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360059415!14134438!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32716 invoked from network); 5 Feb 2013 10:17:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 10:17:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (jored mo8) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f027d3p159M28P ;
	Tue, 5 Feb 2013 11:16:55 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id B4E9B1884C; Tue,  5 Feb 2013 11:16:54 +0100 (CET)
Date: Tue, 5 Feb 2013 11:16:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130205101654.GA13955@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
	<1359986349.7743.46.camel@zakaz.uk.xensource.com>
	<20130204184301.GA31487@aepfle.de>
	<1360056173.7743.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360056173.7743.81.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, Ian Campbell wrote:

> On Mon, 2013-02-04 at 18:43 +0000, Olaf Hering wrote:
> > On Mon, Feb 04, Ian Campbell wrote:
> > 
> > > It just occurred to me, instead of adding lots of individual arguments
> > > perhaps packing them into a (e.g.) libxl_save_properties and adding a
> > > pointer would be a nicer and more extensible (in the future) interface?
> > 
> > Something like this (copy&paste from hg diff)?
> 
> It's a tricky balance of what goes in the struct and what goes in the
> prototype but I didn't imagine putting domid or fd into the struct,
> domid because that's how other libxl APIs behave and fd because it isn't
> really a property of the save/migrate as such.
> 
> Moving flags into the struct could be optional is it complicates the
> compat code too much.

I sent v5 with a new libxl_domain_suspend prototype. If that direction
is ok I will look how to improve the LIBXL_API_VERSION handling and how
to provide a knob for DEF_MIN_REMAINING.

While I do that I would like to drop the hvm parameter from
xc_domain_save because there is a flag for this.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:22:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2ffl-00086u-Ka; Tue, 05 Feb 2013 10:22:41 +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 1U2ffj-00086p-Ob
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:22:39 +0000
Received: from [85.158.143.35:14603] by server-3.bemta-4.messagelabs.com id
	13/F9-08920-F6DD0115; Tue, 05 Feb 2013 10:22:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360059415!14134438!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32716 invoked from network); 5 Feb 2013 10:17:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 10:17:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (jored mo8) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f027d3p159M28P ;
	Tue, 5 Feb 2013 11:16:55 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id B4E9B1884C; Tue,  5 Feb 2013 11:16:54 +0100 (CET)
Date: Tue, 5 Feb 2013 11:16:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130205101654.GA13955@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130204134102.GC16090@aepfle.de>
	<1359985584.7743.39.camel@zakaz.uk.xensource.com>
	<20130204135553.GB16668@aepfle.de>
	<1359986349.7743.46.camel@zakaz.uk.xensource.com>
	<20130204184301.GA31487@aepfle.de>
	<1360056173.7743.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360056173.7743.81.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, Ian Campbell wrote:

> On Mon, 2013-02-04 at 18:43 +0000, Olaf Hering wrote:
> > On Mon, Feb 04, Ian Campbell wrote:
> > 
> > > It just occurred to me, instead of adding lots of individual arguments
> > > perhaps packing them into a (e.g.) libxl_save_properties and adding a
> > > pointer would be a nicer and more extensible (in the future) interface?
> > 
> > Something like this (copy&paste from hg diff)?
> 
> It's a tricky balance of what goes in the struct and what goes in the
> prototype but I didn't imagine putting domid or fd into the struct,
> domid because that's how other libxl APIs behave and fd because it isn't
> really a property of the save/migrate as such.
> 
> Moving flags into the struct could be optional is it complicates the
> compat code too much.

I sent v5 with a new libxl_domain_suspend prototype. If that direction
is ok I will look how to improve the LIBXL_API_VERSION handling and how
to provide a knob for DEF_MIN_REMAINING.

While I do that I would like to drop the hvm parameter from
xc_domain_save because there is a flag for this.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:26:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10:26: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 1U2fj6-0008Gz-7l; Tue, 05 Feb 2013 10:26: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 1U2fj5-0008Gs-5v
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 10:26:07 +0000
Received: from [193.109.254.147:20904] by server-5.bemta-14.messagelabs.com id
	62/EC-21539-E3ED0115; Tue, 05 Feb 2013 10:26:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360059949!1223335!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26436 invoked from network); 5 Feb 2013 10:25:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:25:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:25: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.297.1; Tue, 5 Feb 2013
	10:25:49 +0000
Message-ID: <1360059948.17017.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 5 Feb 2013 10:25:48 +0000
In-Reply-To: <51069350.5020106@tiscali.it>
References: <51069350.5020106@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 RESEND] tools/libxl: Improve videoram
	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

On Mon, 2013-01-28 at 15:03 +0000, Fabio Fantoni wrote:
> tools/libxl: Improve videoram setting
> 
> - If videoram setting is less than 8 mb shows error and exit.
> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).

Which version of qemu does Xen currently ship? Do we need some compat
code with work with e.g. qemu 1.2 or do older versions silently accept +
ignore this option?

> - Updated xl.cfg man.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   docs/man/xl.cfg.pod.5      |   14 +++++---------
>   tools/libxl/libxl_create.c |    4 ++++
>   tools/libxl/libxl_dm.c     |    6 ++++++
>   3 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index caba162..9c5cdcd 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual 
> frame buffer devices
> 
>   Sets the amount of RAM which the emulated video card will contain,
>   which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B<stdvga>
> -option (see below).
> +available.
>   The default amount of video ram for stdvga is 8MB which is sufficient
> -for e.g. 1600x1200 at 32bpp.
> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
> +only when using the qemu-xen-traditional device-model.
> 
>   When using the emulated Cirrus graphics card (B<stdvga=0>)
>   the amount of video ram is fixed at 4MB which is sufficient
> -for 1024x768 at 32 bpp.
> -
> -videoram option is currently only available when using the
> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
> -currently does not support changing the amount of video memory for the
> -emulated graphics device.
> +for 1024x768 at 32 bpp and videoram option is currently working
> +only when using the upstream qemu-xen device-model.
> 
>   =item B<stdvga=BOOLEAN>
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a8dfe61..55014e5 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>               b_info->shadow_memkb = 0;
>           if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->video_memkb = 8 * 1024;
> +        else if (b_info->video_memkb < 8192){
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,"videoram must be at least 
> 8 mb");

Unfortunately the patch is whitespace damaged and doesn't apply. The
indentation is off too (might be related to the whitespace damage?)

> +            return ERROR_INVAL;
> +        }
>           if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
>               b_info->u.hvm.timer_mode =
>                   LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..465b1fd 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -430,6 +430,12 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>               break;
>           case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>               flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "vga.vram_size_mb=%d",
> +                libxl__sizekb_to_mb(b_info->video_memkb)),
> +                NULL);
> +            }

The indentation here is wrong as well.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:26:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10:26: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 1U2fj6-0008Gz-7l; Tue, 05 Feb 2013 10:26: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 1U2fj5-0008Gs-5v
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 10:26:07 +0000
Received: from [193.109.254.147:20904] by server-5.bemta-14.messagelabs.com id
	62/EC-21539-E3ED0115; Tue, 05 Feb 2013 10:26:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360059949!1223335!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26436 invoked from network); 5 Feb 2013 10:25:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:25:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:25: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.297.1; Tue, 5 Feb 2013
	10:25:49 +0000
Message-ID: <1360059948.17017.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 5 Feb 2013 10:25:48 +0000
In-Reply-To: <51069350.5020106@tiscali.it>
References: <51069350.5020106@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 RESEND] tools/libxl: Improve videoram
	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

On Mon, 2013-01-28 at 15:03 +0000, Fabio Fantoni wrote:
> tools/libxl: Improve videoram setting
> 
> - If videoram setting is less than 8 mb shows error and exit.
> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).

Which version of qemu does Xen currently ship? Do we need some compat
code with work with e.g. qemu 1.2 or do older versions silently accept +
ignore this option?

> - Updated xl.cfg man.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   docs/man/xl.cfg.pod.5      |   14 +++++---------
>   tools/libxl/libxl_create.c |    4 ++++
>   tools/libxl/libxl_dm.c     |    6 ++++++
>   3 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index caba162..9c5cdcd 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual 
> frame buffer devices
> 
>   Sets the amount of RAM which the emulated video card will contain,
>   which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B<stdvga>
> -option (see below).
> +available.
>   The default amount of video ram for stdvga is 8MB which is sufficient
> -for e.g. 1600x1200 at 32bpp.
> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
> +only when using the qemu-xen-traditional device-model.
> 
>   When using the emulated Cirrus graphics card (B<stdvga=0>)
>   the amount of video ram is fixed at 4MB which is sufficient
> -for 1024x768 at 32 bpp.
> -
> -videoram option is currently only available when using the
> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
> -currently does not support changing the amount of video memory for the
> -emulated graphics device.
> +for 1024x768 at 32 bpp and videoram option is currently working
> +only when using the upstream qemu-xen device-model.
> 
>   =item B<stdvga=BOOLEAN>
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a8dfe61..55014e5 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>               b_info->shadow_memkb = 0;
>           if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->video_memkb = 8 * 1024;
> +        else if (b_info->video_memkb < 8192){
> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,"videoram must be at least 
> 8 mb");

Unfortunately the patch is whitespace damaged and doesn't apply. The
indentation is off too (might be related to the whitespace damage?)

> +            return ERROR_INVAL;
> +        }
>           if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
>               b_info->u.hvm.timer_mode =
>                   LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..465b1fd 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -430,6 +430,12 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>               break;
>           case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>               flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "vga.vram_size_mb=%d",
> +                libxl__sizekb_to_mb(b_info->video_memkb)),
> +                NULL);
> +            }

The indentation here is wrong as well.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:34:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fqk-00009m-6L; Tue, 05 Feb 2013 10:34: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 1U2fqj-00009h-1h
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 10:34:01 +0000
Received: from [85.158.138.51:14183] by server-16.bemta-3.messagelabs.com id
	76/40-02727-310E0115; Tue, 05 Feb 2013 10:33:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360060434!12320273!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8559 invoked from network); 5 Feb 2013 10:33:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:33:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:33: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.297.1; Tue, 5 Feb 2013
	10:33:54 +0000
Message-ID: <1360060432.17017.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 5 Feb 2013 10:33:52 +0000
In-Reply-To: <5106A14E.2040703@tiscali.it>
References: <5106A14E.2040703@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
 support for upstream-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

On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
> tools/libxl: Add qxl vga interface support for
>   upstream-qemu-xen.
> 
> Usage:
>    qxl=1|0
> 
> Changes from v7:
> - Fix videoram settings parameters for qemu.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> Signed-off-by: Zhou Peng <zpengxen@gmail.com>

Unfortunately this patch is whitespace damaged in various places.

> ---
>   docs/man/xl.cfg.pod.5       |   11 +++++++++++
>   tools/libxl/libxl_create.c  |   12 ++++++++++++
>   tools/libxl/libxl_dm.c      |   15 +++++++++++++++
>   tools/libxl/libxl_types.idl |    1 +
>   tools/libxl/xl_cmdimpl.c    |    7 ++++++-
>   5 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9c5cdcd..a0f0dc3 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is 
> sufficient
>   for 1024x768 at 32 bpp and videoram option is currently working
>   only when using the upstream qemu-xen device-model.
> 
> +For B<qxl> vga, the default is both default and minimal 128MB.
> +If B<videoram> is set less than 128MB, an error will be triggered.
> +
>   =item B<stdvga=BOOLEAN>
> 
>   Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> @@ -992,6 +995,14 @@ a Cirrus Logic GD5446 VGA card. If your guest 
> supports VBE 2.0 or
>   later (e.g. Windows XP onwards) then you should enable this.
>   stdvga supports more video ram and bigger resolutions than Cirrus.
> 
> +=item B<qxl=BOOLEAN>

What happens if I give qxl=1 and stdvga=1?

Perhaps we should deprecate stdvga and add a new option:
	vga = "stdvga|cirrus|qxl"
?
> +
> +Select a QXL VGA card as the emulated graphics device.
> +In general, QXL should work with the Spice remote display protocol
> +for acceleration, and QXL driver is necessary in guest in this case.

Do we have any docs on where to obtain this driver and how to install
it? On the wiki perhaps, a link would be useful.

> +QXL can also work with the VNC protocol, but it will be like a standard
> +VGA without acceleration.
> +
>   =item B<vnc=BOOLEAN>
> 
>   Allow access to the display via the VNC protocol.  This enables the
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 55014e5..4761b5a 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -197,6 +197,18 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>       case LIBXL_DOMAIN_TYPE_HVM:
>           if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->shadow_memkb = 0;
> +
> +        if (b_info->device_model_version == 
> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                b_info->video_memkb = (128 * 1024);
> +            }else if (b_info->video_memkb < (128 * 1024)) {
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                    "128 Mib videoram is the minimum for qxl default");

You can use the LOG() macros to shorten this line (and in other places
including you videoram patch too).

Should this error out on qemu == traditional and vga == QXL?

> +                return ERROR_INVAL;
> +            }
> +        }
> +
>           if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->video_memkb = 8 * 1024;
>           else if (b_info->video_memkb < 8192){
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 465b1fd..0813258 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -437,6 +439,19 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>                   NULL);
>               }
>               break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);

flexarray_append_pair() ?

> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)),
> +                NULL);
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)),
> +                NULL);

You could combine the second two vappends into a single one, or use
flexarray_append_pair().

The /2 is because the videomem is split between vram and ram? A comment
to that affect would be useful.

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080bbd8..b4f7a0e 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1469,7 +1469,12 @@ skip_vfb:
>   #undef parse_extra_args
> 
>       if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +        if (!xlu_cfg_get_long(config, "qxl", &l, 0))
> +            b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_QXL :
> + LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +
> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0) &&
> +            b_info->u.hvm.vga.kind != LIBXL_VGA_INTERFACE_TYPE_QXL)
>               b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
> LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:34:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fqk-00009m-6L; Tue, 05 Feb 2013 10:34: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 1U2fqj-00009h-1h
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 10:34:01 +0000
Received: from [85.158.138.51:14183] by server-16.bemta-3.messagelabs.com id
	76/40-02727-310E0115; Tue, 05 Feb 2013 10:33:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360060434!12320273!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8559 invoked from network); 5 Feb 2013 10:33:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:33:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:33: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.297.1; Tue, 5 Feb 2013
	10:33:54 +0000
Message-ID: <1360060432.17017.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 5 Feb 2013 10:33:52 +0000
In-Reply-To: <5106A14E.2040703@tiscali.it>
References: <5106A14E.2040703@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
 support for upstream-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

On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
> tools/libxl: Add qxl vga interface support for
>   upstream-qemu-xen.
> 
> Usage:
>    qxl=1|0
> 
> Changes from v7:
> - Fix videoram settings parameters for qemu.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> Signed-off-by: Zhou Peng <zpengxen@gmail.com>

Unfortunately this patch is whitespace damaged in various places.

> ---
>   docs/man/xl.cfg.pod.5       |   11 +++++++++++
>   tools/libxl/libxl_create.c  |   12 ++++++++++++
>   tools/libxl/libxl_dm.c      |   15 +++++++++++++++
>   tools/libxl/libxl_types.idl |    1 +
>   tools/libxl/xl_cmdimpl.c    |    7 ++++++-
>   5 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9c5cdcd..a0f0dc3 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is 
> sufficient
>   for 1024x768 at 32 bpp and videoram option is currently working
>   only when using the upstream qemu-xen device-model.
> 
> +For B<qxl> vga, the default is both default and minimal 128MB.
> +If B<videoram> is set less than 128MB, an error will be triggered.
> +
>   =item B<stdvga=BOOLEAN>
> 
>   Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> @@ -992,6 +995,14 @@ a Cirrus Logic GD5446 VGA card. If your guest 
> supports VBE 2.0 or
>   later (e.g. Windows XP onwards) then you should enable this.
>   stdvga supports more video ram and bigger resolutions than Cirrus.
> 
> +=item B<qxl=BOOLEAN>

What happens if I give qxl=1 and stdvga=1?

Perhaps we should deprecate stdvga and add a new option:
	vga = "stdvga|cirrus|qxl"
?
> +
> +Select a QXL VGA card as the emulated graphics device.
> +In general, QXL should work with the Spice remote display protocol
> +for acceleration, and QXL driver is necessary in guest in this case.

Do we have any docs on where to obtain this driver and how to install
it? On the wiki perhaps, a link would be useful.

> +QXL can also work with the VNC protocol, but it will be like a standard
> +VGA without acceleration.
> +
>   =item B<vnc=BOOLEAN>
> 
>   Allow access to the display via the VNC protocol.  This enables the
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 55014e5..4761b5a 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -197,6 +197,18 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>       case LIBXL_DOMAIN_TYPE_HVM:
>           if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->shadow_memkb = 0;
> +
> +        if (b_info->device_model_version == 
> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                b_info->video_memkb = (128 * 1024);
> +            }else if (b_info->video_memkb < (128 * 1024)) {
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                    "128 Mib videoram is the minimum for qxl default");

You can use the LOG() macros to shorten this line (and in other places
including you videoram patch too).

Should this error out on qemu == traditional and vga == QXL?

> +                return ERROR_INVAL;
> +            }
> +        }
> +
>           if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->video_memkb = 8 * 1024;
>           else if (b_info->video_memkb < 8192){
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 465b1fd..0813258 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -437,6 +439,19 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>                   NULL);
>               }
>               break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);

flexarray_append_pair() ?

> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)),
> +                NULL);
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)),
> +                NULL);

You could combine the second two vappends into a single one, or use
flexarray_append_pair().

The /2 is because the videomem is split between vram and ram? A comment
to that affect would be useful.

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080bbd8..b4f7a0e 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1469,7 +1469,12 @@ skip_vfb:
>   #undef parse_extra_args
> 
>       if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +        if (!xlu_cfg_get_long(config, "qxl", &l, 0))
> +            b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_QXL :
> + LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +
> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0) &&
> +            b_info->u.hvm.vga.kind != LIBXL_VGA_INTERFACE_TYPE_QXL)
>               b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
> LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:38:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10:38: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 1U2fuh-0000HQ-Tb; Tue, 05 Feb 2013 10:38:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2fuh-0000HK-25
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:38:07 +0000
Received: from [85.158.143.35:65074] by server-1.bemta-4.messagelabs.com id
	EC/4F-08839-E01E0115; Tue, 05 Feb 2013 10:38:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360060474!4965031!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15273 invoked from network); 5 Feb 2013 10:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:34: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.297.1; Tue, 5 Feb 2013
	10:34:34 +0000
Message-ID: <1360060473.17017.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 10:34:33 +0000
In-Reply-To: <5110DCBB.6050802@citrix.com>
References: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
	<1360058938.17017.10.camel@zakaz.uk.xensource.com>
	<5110DCBB.6050802@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "port-xen@netbsd.org" <port-xen@netbsd.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: add suport for NetBSD gntdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAyMDEzLTAyLTA1IGF0IDEwOjE5ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gT24gMDUvMDIvMTMgMTE6MDgsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+IE9uIFdlZCwgMjAx
Mi0xMS0yOCBhdCAxMzoyMCArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+ID4+IEFkZCBP
UyBzcGVjaWZpYyBoYW5kbGVycyBmb3IgTmV0QlNEIGdudGRldi4gVGhlIG1haW4gZGlmZmVyZW5j
ZSBpcwo+ID4+IHRoYXQgTmV0QlNEIHBhc3NlcyB0aGUgVkEgd2hlcmUgdGhlIGdyYW50IHNob3Vs
ZCBiZSBzZXQgaW5zaWRlIHRoZQo+ID4+IElPQ1RMX0dOVERFVl9NQVBfR1JBTlRfUkVGIGlvY3Rs
LCBpbnN0ZWFkIG9mIHVzaW5nIG1tYXAgKHRoaXMgaXMgZHVlCj4gPj4gdG8gT1MgY29uc3RyYWlu
dHMpLgo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+Cj4gPiAKPiA+IERpZCB0aGUga2VybmVsIHNpZGUgb2YgdGhpcyBnbyBpbnRv
IE5ldEJTRCBpbiB0aGUgZW5kPwo+IAo+IE5vLCB0aGUga2VybmVsIHNpZGUgb25seSB3b3JrZWQg
d2l0aCBQViBndWVzdHMsIGl0IGZhaWxlZCB0byBtYXAgZ3JhbnQKPiByZWZzIGZyb20gSFZNIGd1
ZXN0cy4gU29sdmluZyB0aGlzIHJlcXVpcmVzIHF1aXRlIGEgbG90IG9mIGNoYW5nZXMgaW4KPiB0
aGUgY29kZSwgd2hpY2ggcmlnaHQgbm93IEkgZG9uJ3QgaGF2ZSB0aW1lIHRvIHBlcmZvcm0sIHNv
IGhvbGQgb24gdGhlCj4gbGlieGMvbGlieGwgY2hhbmdlcyBmb3Igbm93LgoKQWNrLCB0aGFua3Mh
CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:38:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10:38: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 1U2fuh-0000HQ-Tb; Tue, 05 Feb 2013 10:38:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2fuh-0000HK-25
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:38:07 +0000
Received: from [85.158.143.35:65074] by server-1.bemta-4.messagelabs.com id
	EC/4F-08839-E01E0115; Tue, 05 Feb 2013 10:38:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360060474!4965031!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15273 invoked from network); 5 Feb 2013 10:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1148913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:34: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.297.1; Tue, 5 Feb 2013
	10:34:34 +0000
Message-ID: <1360060473.17017.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 10:34:33 +0000
In-Reply-To: <5110DCBB.6050802@citrix.com>
References: <1354108851-2383-1-git-send-email-roger.pau@citrix.com>
	<1360058938.17017.10.camel@zakaz.uk.xensource.com>
	<5110DCBB.6050802@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "port-xen@netbsd.org" <port-xen@netbsd.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: add suport for NetBSD gntdev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCAyMDEzLTAyLTA1IGF0IDEwOjE5ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gT24gMDUvMDIvMTMgMTE6MDgsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+IE9uIFdlZCwgMjAx
Mi0xMS0yOCBhdCAxMzoyMCArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+ID4+IEFkZCBP
UyBzcGVjaWZpYyBoYW5kbGVycyBmb3IgTmV0QlNEIGdudGRldi4gVGhlIG1haW4gZGlmZmVyZW5j
ZSBpcwo+ID4+IHRoYXQgTmV0QlNEIHBhc3NlcyB0aGUgVkEgd2hlcmUgdGhlIGdyYW50IHNob3Vs
ZCBiZSBzZXQgaW5zaWRlIHRoZQo+ID4+IElPQ1RMX0dOVERFVl9NQVBfR1JBTlRfUkVGIGlvY3Rs
LCBpbnN0ZWFkIG9mIHVzaW5nIG1tYXAgKHRoaXMgaXMgZHVlCj4gPj4gdG8gT1MgY29uc3RyYWlu
dHMpLgo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+Cj4gPiAKPiA+IERpZCB0aGUga2VybmVsIHNpZGUgb2YgdGhpcyBnbyBpbnRv
IE5ldEJTRCBpbiB0aGUgZW5kPwo+IAo+IE5vLCB0aGUga2VybmVsIHNpZGUgb25seSB3b3JrZWQg
d2l0aCBQViBndWVzdHMsIGl0IGZhaWxlZCB0byBtYXAgZ3JhbnQKPiByZWZzIGZyb20gSFZNIGd1
ZXN0cy4gU29sdmluZyB0aGlzIHJlcXVpcmVzIHF1aXRlIGEgbG90IG9mIGNoYW5nZXMgaW4KPiB0
aGUgY29kZSwgd2hpY2ggcmlnaHQgbm93IEkgZG9uJ3QgaGF2ZSB0aW1lIHRvIHBlcmZvcm0sIHNv
IGhvbGQgb24gdGhlCj4gbGlieGMvbGlieGwgY2hhbmdlcyBmb3Igbm93LgoKQWNrLCB0aGFua3Mh
CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:42:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fyI-0000X1-Nk; Tue, 05 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U2fyG-0000Wt-Qb
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:41:49 +0000
Received: from [85.158.143.35:27103] by server-1.bemta-4.messagelabs.com id
	C7/E5-08839-CE1E0115; Tue, 05 Feb 2013 10:41:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360060897!15955012!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26693 invoked from network); 5 Feb 2013 10:41:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:41:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1149244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:41: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.297.1; Tue, 5 Feb 2013
	10:41:37 +0000
Message-ID: <1360060895.17017.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 10:41:35 +0000
In-Reply-To: <CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-3-git-send-email-roger.pau@citrix.com>
	<CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xl: allow specifying a default netdev
 in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-28 at 11:00 +0000, George Dunlap wrote:
> On Fri, Jan 25, 2013 at 3:26 PM, Roger Pau Monne
> <roger.pau@citrix.com> wrote:
>         This adds a new global option in the xl configuration file
>         called
>         "defaultnetdev", that is used to specify the default netdev to
>         use
>         when none is passed in the vif specification.
> 
> 
> I'm not a fan of the name, though; it doesn't seem very scalable.  It
> looks like we already have "defaultbridge', so I can see this is just
> following precedent, but I wonder if it might be worth putting some
> more thought into it before proceeding?
> 
> 
> It seems like if we're going to have a default sub-option, it should
> at least have the name of the option in which it resides.
> "vif_netdev_default" or "default_vif_netdev" seem like better option.
> Or maybe "vif.netdev.default"? "defaults.vif.netdev"?

netdev is also a bit non-descriptive, even if it is what the vif-route
script uses perhaps we present something more meaningful to the user?

"gatewaydev" or something along those lines perhaps?

I'd be inclined to use whatever name we decide here in the libxl
API/internals as well and just go netdev at the hotplug script
interface.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:42:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2fyI-0000X1-Nk; Tue, 05 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U2fyG-0000Wt-Qb
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:41:49 +0000
Received: from [85.158.143.35:27103] by server-1.bemta-4.messagelabs.com id
	C7/E5-08839-CE1E0115; Tue, 05 Feb 2013 10:41:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360060897!15955012!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26693 invoked from network); 5 Feb 2013 10:41:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:41:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1149244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:41: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.297.1; Tue, 5 Feb 2013
	10:41:37 +0000
Message-ID: <1360060895.17017.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 10:41:35 +0000
In-Reply-To: <CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-3-git-send-email-roger.pau@citrix.com>
	<CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xl: allow specifying a default netdev
 in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-28 at 11:00 +0000, George Dunlap wrote:
> On Fri, Jan 25, 2013 at 3:26 PM, Roger Pau Monne
> <roger.pau@citrix.com> wrote:
>         This adds a new global option in the xl configuration file
>         called
>         "defaultnetdev", that is used to specify the default netdev to
>         use
>         when none is passed in the vif specification.
> 
> 
> I'm not a fan of the name, though; it doesn't seem very scalable.  It
> looks like we already have "defaultbridge', so I can see this is just
> following precedent, but I wonder if it might be worth putting some
> more thought into it before proceeding?
> 
> 
> It seems like if we're going to have a default sub-option, it should
> at least have the name of the option in which it resides.
> "vif_netdev_default" or "default_vif_netdev" seem like better option.
> Or maybe "vif.netdev.default"? "defaults.vif.netdev"?

netdev is also a bit non-descriptive, even if it is what the vif-route
script uses perhaps we present something more meaningful to the user?

"gatewaydev" or something along those lines perhaps?

I'd be inclined to use whatever name we decide here in the libxl
API/internals as well and just go netdev at the hotplug script
interface.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:44:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2g0q-0000eL-9t; Tue, 05 Feb 2013 10:44: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 1U2g0p-0000eE-3j
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:44:27 +0000
Received: from [85.158.143.35:35562] by server-3.bemta-4.messagelabs.com id
	29/10-08920-A82E0115; Tue, 05 Feb 2013 10:44:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360060808!14138163!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 553 invoked from network); 5 Feb 2013 10:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1149169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:40: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.297.1; Tue, 5 Feb 2013
	10:40:08 +0000
Message-ID: <1360060806.17017.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 10:40:06 +0000
In-Reply-To: <1359127583-32490-2-git-send-email-roger.pau@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
 specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gRnJpLCAyMDEzLTAxLTI1IGF0IDE1OjI2ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gVGhpcyBvcHRpb24gd2FzIHN1cHBvcnRlZCBpbiB0aGUgcGFzdCwgYWNjb3JkaW5nIHRvCj4g
aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1ZpZi1yb3V0ZSwgc28gd2Ugc2hvdWxkIGFsc28gc3Vw
cG9ydCBpdCBpbgo+IGxpYnhsLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kg
PHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+IENjOiBVbGYgS3JldXR6YmVyZyA8dWxmLmtyZXV0emJl
cmdAaG9zdGV1cm9wZS5kZT4KPiAtLS0KPiAgZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJh
dGlvbi5tYXJrZG93biB8ICAgIDYgKysrKysrCj4gIHRvb2xzL2xpYnhsL2xpYnhsLmMgICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgICA2ICsrKysrLQo+ICB0b29scy9saWJ4bC9saWJ4bF9saW51
eC5jICAgICAgICAgICAgICAgICAgIHwgICAgOSArKysrKysrKy0KPiAgdG9vbHMvbGlieGwvbGli
eGxfdHlwZXMuaWRsICAgICAgICAgICAgICAgICB8ICAgIDEgKwo+ICB0b29scy9saWJ4bC94bF9j
bWRpbXBsLmMgICAgICAgICAgICAgICAgICAgIHwgICAgNSArKysrKwo+ICA1IGZpbGVzIGNoYW5n
ZWQsIDI1IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdpdCBhL2Rv
Y3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYi9kb2NzL21pc2MveGwt
bmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCj4gaW5kZXggNWUyZjA0OS4uYjk4YjI4ZSAx
MDA2NDQKPiAtLS0gYS9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3du
Cj4gKysrIGIvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgo+IEBA
IC02Nyw2ICs2NywxMiBAQCBhZGRlZCB0by4gVGhlIGRlZmF1bHQgaXMgYHhlbmJyMGAuIFRoZSBi
cmlkZ2UgbXVzdCBiZSBjb25maWd1cmVkIHVzaW5nCj4gIHlvdXIgZGlzdHJpYnV0aW9uJ3MgbmV0
d29yayBjb25maWd1cmF0aW9uIHRvb2xzLiBTZWUgdGhlIFt3aWtpXVtuZXRdCj4gIGZvciBndWlk
YW5jZSBhbmQgZXhhbXBsZXMuCj4gIAo+ICsjIyMgbmV0ZGV2Cj4gKwo+ICtTcGVjaWZpZXMgdGhl
IG5hbWUgb2YgdGhlIG5ldHdvcmsgaW50ZXJmYWNlIHdoaWNoIGhhcyBhbiBJUCBhbmQgd2hpY2gK
PiAraXMgaW4gdGhlIG5ldHdvcmsgdGhlIFZJRiBzaG91bGQgY29tbXVuaWNhdGUgd2l0aC4KCkkg
dGhpbmsgdGhpcyBuZWVkcyB0byBjbGFyaWZ5IHRoYXQgaXQgaXMgYSBob3N0IG5ldHdvcmsgZGV2
aWNlLgoKPiAgVGhpcyBpcyB1c2VkIGJ5IHRoZQo+ICt2aWYtcm91dGUgaG90cGx1ZyBzY3JpcHQu
IFNlZSBbd2lraV1bdmlmLXJvdXRlXSBmb3IgZ3VpZGFuY2UgYW5kIGV4YW1wbGVzLgoKWW91IG5l
ZWQgdG8gYWRkIGEgVVJMIGZvciB2aWYtcm91dGUgbmVhciB0aGUgYm90dG9tIEkgdGhpbmsuCgo+
ICsKPiAgIyMjIHR5cGUKPiAgCj4gIFRoaXMga2V5d29yZCBpcyB2YWxpZCBmb3IgSFZNIGd1ZXN0
cyBvbmx5Lgo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwv
bGlieGwuYwo+IGluZGV4IDczZTBkYzMuLjAzYmZlMWEgMTAwNjQ0Cj4gLS0tIGEvdG9vbHMvbGli
eGwvbGlieGwuYwo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKPiBAQCAtMjgyNiw3ICsyODI2
LDcgQEAgdm9pZCBsaWJ4bF9fZGV2aWNlX25pY19hZGQobGlieGxfX2VnYyAqZWdjLCB1aW50MzJf
dCBkb21pZCwKPiAgICAgIGlmIChyYykgZ290byBvdXQ7Cj4gIAo+ICAgICAgZnJvbnQgPSBmbGV4
YXJyYXlfbWFrZShnYywgMTYsIDEpOwo+IC0gICAgYmFjayA9IGZsZXhhcnJheV9tYWtlKGdjLCAx
NiwgMSk7Cj4gKyAgICBiYWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE4LCAxKTsKPiAgCj4gICAg
ICBpZiAobmljLT5kZXZpZCA9PSAtMSkgewo+ICAgICAgICAgIGlmICgobmljLT5kZXZpZCA9IGxp
YnhsX19kZXZpY2VfbmV4dGlkKGdjLCBkb21pZCwgInZpZiIpIDwgMCkpIHsKPiBAQCAtMjg2Miw2
ICsyODYyLDEwIEBAIHZvaWQgbGlieGxfX2RldmljZV9uaWNfYWRkKGxpYnhsX19lZ2MgKmVnYywg
dWludDMyX3QgZG9taWQsCj4gICAgICAgICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCAiaXAiKTsK
PiAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+
aXApKTsKPiAgICAgIH0KPiArICAgIGlmIChuaWMtPm5ldGRldikgewo+ICsgICAgICAgIGZsZXhh
cnJheV9hcHBlbmQoYmFjaywgIm5ldGRldiIpOwo+ICsgICAgICAgIGZsZXhhcnJheV9hcHBlbmQo
YmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5uZXRkZXYpKTsKPiArICAgIH0KPiAgCj4gICAg
ICBpZiAobmljLT5yYXRlX2ludGVydmFsX3VzZWNzID4gMCkgewo+ICAgICAgICAgIGZsZXhhcnJh
eV9hcHBlbmQoYmFjaywgInJhdGUiKTsKPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxf
bGludXguYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPiBpbmRleCAxZmVkM2NkLi40Y2Jk
YzE5IDEwMDY0NAo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPiArKysgYi90b29s
cy9saWJ4bC9saWJ4bF9saW51eC5jCj4gQEAgLTg0LDExICs4NCwxNiBAQCBzdGF0aWMgY2hhciAq
KmdldF9ob3RwbHVnX2VudihsaWJ4bF9fZ2MgKmdjLAo+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjaGFyICpzY3JpcHQsIGxpYnhsX19kZXZpY2UgKmRldikKPiAgewo+ICAgICAgY29u
c3QgY2hhciAqdHlwZSA9IGxpYnhsX19kZXZpY2Vfa2luZF90b19zdHJpbmcoZGV2LT5iYWNrZW5k
X2tpbmQpOwo+ICsgICAgY2hhciAqYmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfYmFja2VuZF9wYXRo
KGdjLCBkZXYpOwo+ICAgICAgY2hhciAqKmVudjsKPiArICAgIGNoYXIgKm5ldGRldjsKPiAgICAg
IGludCBuciA9IDA7Cj4gICAgICBsaWJ4bF9uaWNfdHlwZSBuaWN0eXBlOwo+ICAKPiAtICAgIGNv
bnN0IGludCBhcnJheXNpemUgPSAxMzsKPiArICAgIG5ldGRldiA9IGxpYnhsX194c19yZWFkKGdj
LCBYQlRfTlVMTCwgR0NTUFJJTlRGKCIlcy8lcyIsIGJlX3BhdGgsCj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAibmV0ZGV2Iikp
Owo+ICsKPiArICAgIGNvbnN0IGludCBhcnJheXNpemUgPSAxNTsKPiAgICAgIEdDTkVXX0FSUkFZ
KGVudiwgYXJyYXlzaXplKTsKPiAgICAgIGVudltucisrXSA9ICJzY3JpcHQiOwo+ICAgICAgZW52
W25yKytdID0gc2NyaXB0Owo+IEBAIC05OCw2ICsxMDMsOCBAQCBzdGF0aWMgY2hhciAqKmdldF9o
b3RwbHVnX2VudihsaWJ4bF9fZ2MgKmdjLAo+ICAgICAgZW52W25yKytdID0gR0NTUFJJTlRGKCJi
YWNrZW5kLyVzLyV1LyVkIiwgdHlwZSwgZGV2LT5kb21pZCwgZGV2LT5kZXZpZCk7Cj4gICAgICBl
bnZbbnIrK10gPSAiWEVOQlVTX0JBU0VfUEFUSCI7Cj4gICAgICBlbnZbbnIrK10gPSAiYmFja2Vu
ZCI7Cj4gKyAgICBlbnZbbnIrK10gPSAibmV0ZGV2IjsKPiArICAgIGVudltucisrXSA9IG5ldGRl
djsKCk1pZ2h0bid0IHRoaXMgYmUgTlVMTD8KCj4gICAgICBpZiAoZGV2LT5iYWNrZW5kX2tpbmQg
PT0gTElCWExfX0RFVklDRV9LSU5EX1ZJRikgewo+ICAgICAgICAgIGlmIChsaWJ4bF9fbmljX3R5
cGUoZ2MsIGRldiwgJm5pY3R5cGUpKSB7Cj4gICAgICAgICAgICAgIExPRyhFUlJPUiwgInVuYWJs
ZSB0byBnZXQgbmljdHlwZSIpOwo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBl
cy5pZGwgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKPiBpbmRleCBhY2M0YmM5Li4wZTc5
NDNlIDEwMDY0NAo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+ICsrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+IEBAIC0zODIsNiArMzgyLDcgQEAgbGlieGxfZGV2
aWNlX25pYyA9IFN0cnVjdCgiZGV2aWNlX25pYyIsIFsKPiAgICAgICgibmljdHlwZSIsIGxpYnhs
X25pY190eXBlKSwKPiAgICAgICgicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAo+
ICAgICAgKCJyYXRlX2ludGVydmFsX3VzZWNzIiwgdWludDMyKSwKPiArICAgICgibmV0ZGV2Iiwg
c3RyaW5nKSwKPiAgICAgIF0pCj4gIAo+ICBsaWJ4bF9kZXZpY2VfcGNpID0gU3RydWN0KCJkZXZp
Y2VfcGNpIiwgWwo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKPiBpbmRleCBlOTY0YmYxLi45MmE2NGU0IDEwMDY0NAo+IC0t
LSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+ICsrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYwo+IEBAIC0xMjA1LDYgKzEyMDUsOSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0
YShjb25zdCBjaGFyICpjb25maWdfc291cmNlLAo+ICAgICAgICAgICAgICAgICAgICAgIHBhcnNl
X3ZpZl9yYXRlKCZjb25maWcsIChwMiArIDEpLCBuaWMpOwo+ICAgICAgICAgICAgICAgICAgfSBl
bHNlIGlmICghc3RyY21wKHAsICJhY2NlbCIpKSB7Cj4gICAgICAgICAgICAgICAgICAgICAgZnBy
aW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJlbnRseSBu
b3Qgc3VwcG9ydGVkXG4iKTsKPiArICAgICAgICAgICAgICAgIH0gZWxzZSBpZiAoIXN0cmNtcChw
LCAibmV0ZGV2IikpIHsKPiArICAgICAgICAgICAgICAgICAgICBmcmVlKG5pYy0+bmV0ZGV2KTsK
PiArICAgICAgICAgICAgICAgICAgICBuaWMtPm5ldGRldiA9IHN0cmR1cChwMiArIDEpOwo+ICAg
ICAgICAgICAgICAgICAgfQo+ICAgICAgICAgICAgICB9IHdoaWxlICgocCA9IHN0cnRvayhOVUxM
LCAiLCIpKSAhPSBOVUxMKTsKPiAgc2tpcF9uaWM6Cj4gQEAgLTU1MTEsNiArNTUxNCw4IEBAIGlu
dCBtYWluX25ldHdvcmthdHRhY2goaW50IGFyZ2MsIGNoYXIgKiphcmd2KQo+ICAgICAgICAgICAg
ICB9Cj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04oImJyaWRnZSIsICphcmd2LCBv
cGFyZykpIHsKPiAgICAgICAgICAgICAgcmVwbGFjZV9zdHJpbmcoJm5pYy5icmlkZ2UsIG9wYXJn
KTsKPiArICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigibmV0ZGV2IiwgKmFyZ3YsIG9w
YXJnKSkgewo+ICsgICAgICAgICAgICByZXBsYWNlX3N0cmluZygmbmljLm5ldGRldiwgb3Bhcmcp
Owo+ICAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9OKCJpcCIsICphcmd2LCBvcGFyZykp
IHsKPiAgICAgICAgICAgICAgcmVwbGFjZV9zdHJpbmcoJm5pYy5pcCwgb3BhcmcpOwo+ICAgICAg
ICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9OKCJzY3JpcHQiLCAqYXJndiwgb3BhcmcpKSB7CgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:44:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10: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 1U2g0q-0000eL-9t; Tue, 05 Feb 2013 10:44: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 1U2g0p-0000eE-3j
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:44:27 +0000
Received: from [85.158.143.35:35562] by server-3.bemta-4.messagelabs.com id
	29/10-08920-A82E0115; Tue, 05 Feb 2013 10:44:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360060808!14138163!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 553 invoked from network); 5 Feb 2013 10:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1149169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:40: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.297.1; Tue, 5 Feb 2013
	10:40:08 +0000
Message-ID: <1360060806.17017.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 10:40:06 +0000
In-Reply-To: <1359127583-32490-2-git-send-email-roger.pau@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
 specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gRnJpLCAyMDEzLTAxLTI1IGF0IDE1OjI2ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gVGhpcyBvcHRpb24gd2FzIHN1cHBvcnRlZCBpbiB0aGUgcGFzdCwgYWNjb3JkaW5nIHRvCj4g
aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1ZpZi1yb3V0ZSwgc28gd2Ugc2hvdWxkIGFsc28gc3Vw
cG9ydCBpdCBpbgo+IGxpYnhsLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kg
PHJvZ2VyLnBhdUBjaXRyaXguY29tPgo+IENjOiBVbGYgS3JldXR6YmVyZyA8dWxmLmtyZXV0emJl
cmdAaG9zdGV1cm9wZS5kZT4KPiAtLS0KPiAgZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJh
dGlvbi5tYXJrZG93biB8ICAgIDYgKysrKysrCj4gIHRvb2xzL2xpYnhsL2xpYnhsLmMgICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgICA2ICsrKysrLQo+ICB0b29scy9saWJ4bC9saWJ4bF9saW51
eC5jICAgICAgICAgICAgICAgICAgIHwgICAgOSArKysrKysrKy0KPiAgdG9vbHMvbGlieGwvbGli
eGxfdHlwZXMuaWRsICAgICAgICAgICAgICAgICB8ICAgIDEgKwo+ICB0b29scy9saWJ4bC94bF9j
bWRpbXBsLmMgICAgICAgICAgICAgICAgICAgIHwgICAgNSArKysrKwo+ICA1IGZpbGVzIGNoYW5n
ZWQsIDI1IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdpdCBhL2Rv
Y3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYi9kb2NzL21pc2MveGwt
bmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCj4gaW5kZXggNWUyZjA0OS4uYjk4YjI4ZSAx
MDA2NDQKPiAtLS0gYS9kb2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3du
Cj4gKysrIGIvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgo+IEBA
IC02Nyw2ICs2NywxMiBAQCBhZGRlZCB0by4gVGhlIGRlZmF1bHQgaXMgYHhlbmJyMGAuIFRoZSBi
cmlkZ2UgbXVzdCBiZSBjb25maWd1cmVkIHVzaW5nCj4gIHlvdXIgZGlzdHJpYnV0aW9uJ3MgbmV0
d29yayBjb25maWd1cmF0aW9uIHRvb2xzLiBTZWUgdGhlIFt3aWtpXVtuZXRdCj4gIGZvciBndWlk
YW5jZSBhbmQgZXhhbXBsZXMuCj4gIAo+ICsjIyMgbmV0ZGV2Cj4gKwo+ICtTcGVjaWZpZXMgdGhl
IG5hbWUgb2YgdGhlIG5ldHdvcmsgaW50ZXJmYWNlIHdoaWNoIGhhcyBhbiBJUCBhbmQgd2hpY2gK
PiAraXMgaW4gdGhlIG5ldHdvcmsgdGhlIFZJRiBzaG91bGQgY29tbXVuaWNhdGUgd2l0aC4KCkkg
dGhpbmsgdGhpcyBuZWVkcyB0byBjbGFyaWZ5IHRoYXQgaXQgaXMgYSBob3N0IG5ldHdvcmsgZGV2
aWNlLgoKPiAgVGhpcyBpcyB1c2VkIGJ5IHRoZQo+ICt2aWYtcm91dGUgaG90cGx1ZyBzY3JpcHQu
IFNlZSBbd2lraV1bdmlmLXJvdXRlXSBmb3IgZ3VpZGFuY2UgYW5kIGV4YW1wbGVzLgoKWW91IG5l
ZWQgdG8gYWRkIGEgVVJMIGZvciB2aWYtcm91dGUgbmVhciB0aGUgYm90dG9tIEkgdGhpbmsuCgo+
ICsKPiAgIyMjIHR5cGUKPiAgCj4gIFRoaXMga2V5d29yZCBpcyB2YWxpZCBmb3IgSFZNIGd1ZXN0
cyBvbmx5Lgo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwv
bGlieGwuYwo+IGluZGV4IDczZTBkYzMuLjAzYmZlMWEgMTAwNjQ0Cj4gLS0tIGEvdG9vbHMvbGli
eGwvbGlieGwuYwo+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKPiBAQCAtMjgyNiw3ICsyODI2
LDcgQEAgdm9pZCBsaWJ4bF9fZGV2aWNlX25pY19hZGQobGlieGxfX2VnYyAqZWdjLCB1aW50MzJf
dCBkb21pZCwKPiAgICAgIGlmIChyYykgZ290byBvdXQ7Cj4gIAo+ICAgICAgZnJvbnQgPSBmbGV4
YXJyYXlfbWFrZShnYywgMTYsIDEpOwo+IC0gICAgYmFjayA9IGZsZXhhcnJheV9tYWtlKGdjLCAx
NiwgMSk7Cj4gKyAgICBiYWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE4LCAxKTsKPiAgCj4gICAg
ICBpZiAobmljLT5kZXZpZCA9PSAtMSkgewo+ICAgICAgICAgIGlmICgobmljLT5kZXZpZCA9IGxp
YnhsX19kZXZpY2VfbmV4dGlkKGdjLCBkb21pZCwgInZpZiIpIDwgMCkpIHsKPiBAQCAtMjg2Miw2
ICsyODYyLDEwIEBAIHZvaWQgbGlieGxfX2RldmljZV9uaWNfYWRkKGxpYnhsX19lZ2MgKmVnYywg
dWludDMyX3QgZG9taWQsCj4gICAgICAgICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCAiaXAiKTsK
PiAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+
aXApKTsKPiAgICAgIH0KPiArICAgIGlmIChuaWMtPm5ldGRldikgewo+ICsgICAgICAgIGZsZXhh
cnJheV9hcHBlbmQoYmFjaywgIm5ldGRldiIpOwo+ICsgICAgICAgIGZsZXhhcnJheV9hcHBlbmQo
YmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5uZXRkZXYpKTsKPiArICAgIH0KPiAgCj4gICAg
ICBpZiAobmljLT5yYXRlX2ludGVydmFsX3VzZWNzID4gMCkgewo+ICAgICAgICAgIGZsZXhhcnJh
eV9hcHBlbmQoYmFjaywgInJhdGUiKTsKPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxf
bGludXguYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPiBpbmRleCAxZmVkM2NkLi40Y2Jk
YzE5IDEwMDY0NAo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPiArKysgYi90b29s
cy9saWJ4bC9saWJ4bF9saW51eC5jCj4gQEAgLTg0LDExICs4NCwxNiBAQCBzdGF0aWMgY2hhciAq
KmdldF9ob3RwbHVnX2VudihsaWJ4bF9fZ2MgKmdjLAo+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjaGFyICpzY3JpcHQsIGxpYnhsX19kZXZpY2UgKmRldikKPiAgewo+ICAgICAgY29u
c3QgY2hhciAqdHlwZSA9IGxpYnhsX19kZXZpY2Vfa2luZF90b19zdHJpbmcoZGV2LT5iYWNrZW5k
X2tpbmQpOwo+ICsgICAgY2hhciAqYmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfYmFja2VuZF9wYXRo
KGdjLCBkZXYpOwo+ICAgICAgY2hhciAqKmVudjsKPiArICAgIGNoYXIgKm5ldGRldjsKPiAgICAg
IGludCBuciA9IDA7Cj4gICAgICBsaWJ4bF9uaWNfdHlwZSBuaWN0eXBlOwo+ICAKPiAtICAgIGNv
bnN0IGludCBhcnJheXNpemUgPSAxMzsKPiArICAgIG5ldGRldiA9IGxpYnhsX194c19yZWFkKGdj
LCBYQlRfTlVMTCwgR0NTUFJJTlRGKCIlcy8lcyIsIGJlX3BhdGgsCj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAibmV0ZGV2Iikp
Owo+ICsKPiArICAgIGNvbnN0IGludCBhcnJheXNpemUgPSAxNTsKPiAgICAgIEdDTkVXX0FSUkFZ
KGVudiwgYXJyYXlzaXplKTsKPiAgICAgIGVudltucisrXSA9ICJzY3JpcHQiOwo+ICAgICAgZW52
W25yKytdID0gc2NyaXB0Owo+IEBAIC05OCw2ICsxMDMsOCBAQCBzdGF0aWMgY2hhciAqKmdldF9o
b3RwbHVnX2VudihsaWJ4bF9fZ2MgKmdjLAo+ICAgICAgZW52W25yKytdID0gR0NTUFJJTlRGKCJi
YWNrZW5kLyVzLyV1LyVkIiwgdHlwZSwgZGV2LT5kb21pZCwgZGV2LT5kZXZpZCk7Cj4gICAgICBl
bnZbbnIrK10gPSAiWEVOQlVTX0JBU0VfUEFUSCI7Cj4gICAgICBlbnZbbnIrK10gPSAiYmFja2Vu
ZCI7Cj4gKyAgICBlbnZbbnIrK10gPSAibmV0ZGV2IjsKPiArICAgIGVudltucisrXSA9IG5ldGRl
djsKCk1pZ2h0bid0IHRoaXMgYmUgTlVMTD8KCj4gICAgICBpZiAoZGV2LT5iYWNrZW5kX2tpbmQg
PT0gTElCWExfX0RFVklDRV9LSU5EX1ZJRikgewo+ICAgICAgICAgIGlmIChsaWJ4bF9fbmljX3R5
cGUoZ2MsIGRldiwgJm5pY3R5cGUpKSB7Cj4gICAgICAgICAgICAgIExPRyhFUlJPUiwgInVuYWJs
ZSB0byBnZXQgbmljdHlwZSIpOwo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBl
cy5pZGwgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKPiBpbmRleCBhY2M0YmM5Li4wZTc5
NDNlIDEwMDY0NAo+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+ICsrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+IEBAIC0zODIsNiArMzgyLDcgQEAgbGlieGxfZGV2
aWNlX25pYyA9IFN0cnVjdCgiZGV2aWNlX25pYyIsIFsKPiAgICAgICgibmljdHlwZSIsIGxpYnhs
X25pY190eXBlKSwKPiAgICAgICgicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAo+
ICAgICAgKCJyYXRlX2ludGVydmFsX3VzZWNzIiwgdWludDMyKSwKPiArICAgICgibmV0ZGV2Iiwg
c3RyaW5nKSwKPiAgICAgIF0pCj4gIAo+ICBsaWJ4bF9kZXZpY2VfcGNpID0gU3RydWN0KCJkZXZp
Y2VfcGNpIiwgWwo+IGRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMKPiBpbmRleCBlOTY0YmYxLi45MmE2NGU0IDEwMDY0NAo+IC0t
LSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+ICsrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYwo+IEBAIC0xMjA1LDYgKzEyMDUsOSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0
YShjb25zdCBjaGFyICpjb25maWdfc291cmNlLAo+ICAgICAgICAgICAgICAgICAgICAgIHBhcnNl
X3ZpZl9yYXRlKCZjb25maWcsIChwMiArIDEpLCBuaWMpOwo+ICAgICAgICAgICAgICAgICAgfSBl
bHNlIGlmICghc3RyY21wKHAsICJhY2NlbCIpKSB7Cj4gICAgICAgICAgICAgICAgICAgICAgZnBy
aW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1cnJlbnRseSBu
b3Qgc3VwcG9ydGVkXG4iKTsKPiArICAgICAgICAgICAgICAgIH0gZWxzZSBpZiAoIXN0cmNtcChw
LCAibmV0ZGV2IikpIHsKPiArICAgICAgICAgICAgICAgICAgICBmcmVlKG5pYy0+bmV0ZGV2KTsK
PiArICAgICAgICAgICAgICAgICAgICBuaWMtPm5ldGRldiA9IHN0cmR1cChwMiArIDEpOwo+ICAg
ICAgICAgICAgICAgICAgfQo+ICAgICAgICAgICAgICB9IHdoaWxlICgocCA9IHN0cnRvayhOVUxM
LCAiLCIpKSAhPSBOVUxMKTsKPiAgc2tpcF9uaWM6Cj4gQEAgLTU1MTEsNiArNTUxNCw4IEBAIGlu
dCBtYWluX25ldHdvcmthdHRhY2goaW50IGFyZ2MsIGNoYXIgKiphcmd2KQo+ICAgICAgICAgICAg
ICB9Cj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04oImJyaWRnZSIsICphcmd2LCBv
cGFyZykpIHsKPiAgICAgICAgICAgICAgcmVwbGFjZV9zdHJpbmcoJm5pYy5icmlkZ2UsIG9wYXJn
KTsKPiArICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigibmV0ZGV2IiwgKmFyZ3YsIG9w
YXJnKSkgewo+ICsgICAgICAgICAgICByZXBsYWNlX3N0cmluZygmbmljLm5ldGRldiwgb3Bhcmcp
Owo+ICAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9OKCJpcCIsICphcmd2LCBvcGFyZykp
IHsKPiAgICAgICAgICAgICAgcmVwbGFjZV9zdHJpbmcoJm5pYy5pcCwgb3BhcmcpOwo+ICAgICAg
ICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9OKCJzY3JpcHQiLCAqYXJndiwgb3BhcmcpKSB7CgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:57:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10:57: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 1U2gCz-0000vs-Js; Tue, 05 Feb 2013 10:57: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 1U2gCx-0000vn-L9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:56:59 +0000
Received: from [85.158.137.99:29772] by server-6.bemta-3.messagelabs.com id
	D8/EB-29959-A75E0115; Tue, 05 Feb 2013 10:56:58 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360061799!19933320!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28214 invoked from network); 5 Feb 2013 10:56:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1149933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:56:36 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	10:56:36 +0000
Message-ID: <5110E563.8030604@citrix.com>
Date: Tue, 5 Feb 2013 11:56:35 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360060806.17017.25.camel@zakaz.uk.xensource.com>
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
	specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMDUvMDIvMTMgMTE6NDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPiBPbiBGcmksIDIwMTMtMDEt
MjUgYXQgMTU6MjYgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gVGhpcyBvcHRpb24g
d2FzIHN1cHBvcnRlZCBpbiB0aGUgcGFzdCwgYWNjb3JkaW5nIHRvCj4+IGh0dHA6Ly93aWtpLnhl
bi5vcmcvd2lraS9WaWYtcm91dGUsIHNvIHdlIHNob3VsZCBhbHNvIHN1cHBvcnQgaXQgaW4KPj4g
bGlieGwuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPgo+PiBDYzogVWxmIEtyZXV0emJlcmcgPHVsZi5rcmV1dHpiZXJnQGhvc3RldXJv
cGUuZGU+Cj4+IC0tLQo+PiAgZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJr
ZG93biB8ICAgIDYgKysrKysrCj4+ICB0b29scy9saWJ4bC9saWJ4bC5jICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgNiArKysrKy0KPj4gIHRvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMgICAg
ICAgICAgICAgICAgICAgfCAgICA5ICsrKysrKysrLQo+PiAgdG9vbHMvbGlieGwvbGlieGxfdHlw
ZXMuaWRsICAgICAgICAgICAgICAgICB8ICAgIDEgKwo+PiAgdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jICAgICAgICAgICAgICAgICAgICB8ICAgIDUgKysrKysKPj4gIDUgZmlsZXMgY2hhbmdlZCwg
MjUgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL2RvY3Mv
bWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYi9kb2NzL21pc2MveGwtbmV0
d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCj4+IGluZGV4IDVlMmYwNDkuLmI5OGIyOGUgMTAw
NjQ0Cj4+IC0tLSBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24K
Pj4gKysrIGIvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgo+PiBA
QCAtNjcsNiArNjcsMTIgQEAgYWRkZWQgdG8uIFRoZSBkZWZhdWx0IGlzIGB4ZW5icjBgLiBUaGUg
YnJpZGdlIG11c3QgYmUgY29uZmlndXJlZCB1c2luZwo+PiAgeW91ciBkaXN0cmlidXRpb24ncyBu
ZXR3b3JrIGNvbmZpZ3VyYXRpb24gdG9vbHMuIFNlZSB0aGUgW3dpa2ldW25ldF0KPj4gIGZvciBn
dWlkYW5jZSBhbmQgZXhhbXBsZXMuCj4+ICAKPj4gKyMjIyBuZXRkZXYKPj4gKwo+PiArU3BlY2lm
aWVzIHRoZSBuYW1lIG9mIHRoZSBuZXR3b3JrIGludGVyZmFjZSB3aGljaCBoYXMgYW4gSVAgYW5k
IHdoaWNoCj4+ICtpcyBpbiB0aGUgbmV0d29yayB0aGUgVklGIHNob3VsZCBjb21tdW5pY2F0ZSB3
aXRoLgo+IAo+IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBjbGFyaWZ5IHRoYXQgaXQgaXMgYSBob3N0
IG5ldHdvcmsgZGV2aWNlLgoKQWNrCgo+IAo+PiAgVGhpcyBpcyB1c2VkIGJ5IHRoZQo+PiArdmlm
LXJvdXRlIGhvdHBsdWcgc2NyaXB0LiBTZWUgW3dpa2ldW3ZpZi1yb3V0ZV0gZm9yIGd1aWRhbmNl
IGFuZCBleGFtcGxlcy4KPiAKPiBZb3UgbmVlZCB0byBhZGQgYSBVUkwgZm9yIHZpZi1yb3V0ZSBu
ZWFyIHRoZSBib3R0b20gSSB0aGluay4KPiAKPj4gKwo+PiAgIyMjIHR5cGUKPj4gIAo+PiAgVGhp
cyBrZXl3b3JkIGlzIHZhbGlkIGZvciBIVk0gZ3Vlc3RzIG9ubHkuCj4+IGRpZmYgLS1naXQgYS90
b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwvbGlieGwuYwo+PiBpbmRleCA3M2UwZGMz
Li4wM2JmZTFhIDEwMDY0NAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCj4+ICsrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsLmMKPj4gQEAgLTI4MjYsNyArMjgyNiw3IEBAIHZvaWQgbGlieGxfX2Rl
dmljZV9uaWNfYWRkKGxpYnhsX19lZ2MgKmVnYywgdWludDMyX3QgZG9taWQsCj4+ICAgICAgaWYg
KHJjKSBnb3RvIG91dDsKPj4gIAo+PiAgICAgIGZyb250ID0gZmxleGFycmF5X21ha2UoZ2MsIDE2
LCAxKTsKPj4gLSAgICBiYWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE2LCAxKTsKPj4gKyAgICBi
YWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE4LCAxKTsKPj4gIAo+PiAgICAgIGlmIChuaWMtPmRl
dmlkID09IC0xKSB7Cj4+ICAgICAgICAgIGlmICgobmljLT5kZXZpZCA9IGxpYnhsX19kZXZpY2Vf
bmV4dGlkKGdjLCBkb21pZCwgInZpZiIpIDwgMCkpIHsKPj4gQEAgLTI4NjIsNiArMjg2MiwxMCBA
QCB2b2lkIGxpYnhsX19kZXZpY2VfbmljX2FkZChsaWJ4bF9fZWdjICplZ2MsIHVpbnQzMl90IGRv
bWlkLAo+PiAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJpcCIpOwo+PiAgICAgICAg
ICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+aXApKTsKPj4g
ICAgICB9Cj4+ICsgICAgaWYgKG5pYy0+bmV0ZGV2KSB7Cj4+ICsgICAgICAgIGZsZXhhcnJheV9h
cHBlbmQoYmFjaywgIm5ldGRldiIpOwo+PiArICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ss
IGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+bmV0ZGV2KSk7Cj4+ICsgICAgfQo+PiAgCj4+ICAgICAg
aWYgKG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcyA+IDApIHsKPj4gICAgICAgICAgZmxleGFycmF5
X2FwcGVuZChiYWNrLCAicmF0ZSIpOwo+PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxf
bGludXguYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPj4gaW5kZXggMWZlZDNjZC4uNGNi
ZGMxOSAxMDA2NDQKPj4gLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfbGludXguYwo+PiArKysgYi90
b29scy9saWJ4bC9saWJ4bF9saW51eC5jCj4+IEBAIC04NCwxMSArODQsMTYgQEAgc3RhdGljIGNo
YXIgKipnZXRfaG90cGx1Z19lbnYobGlieGxfX2djICpnYywKPj4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGNoYXIgKnNjcmlwdCwgbGlieGxfX2RldmljZSAqZGV2KQo+PiAgewo+PiAg
ICAgIGNvbnN0IGNoYXIgKnR5cGUgPSBsaWJ4bF9fZGV2aWNlX2tpbmRfdG9fc3RyaW5nKGRldi0+
YmFja2VuZF9raW5kKTsKPj4gKyAgICBjaGFyICpiZV9wYXRoID0gbGlieGxfX2RldmljZV9iYWNr
ZW5kX3BhdGgoZ2MsIGRldik7Cj4+ICAgICAgY2hhciAqKmVudjsKPj4gKyAgICBjaGFyICpuZXRk
ZXY7Cj4+ICAgICAgaW50IG5yID0gMDsKPj4gICAgICBsaWJ4bF9uaWNfdHlwZSBuaWN0eXBlOwo+
PiAgCj4+IC0gICAgY29uc3QgaW50IGFycmF5c2l6ZSA9IDEzOwo+PiArICAgIG5ldGRldiA9IGxp
YnhsX194c19yZWFkKGdjLCBYQlRfTlVMTCwgR0NTUFJJTlRGKCIlcy8lcyIsIGJlX3BhdGgsCj4+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIm5ldGRldiIpKTsKPj4gKwo+PiArICAgIGNvbnN0IGludCBhcnJheXNpemUgPSAxNTsK
Pj4gICAgICBHQ05FV19BUlJBWShlbnYsIGFycmF5c2l6ZSk7Cj4+ICAgICAgZW52W25yKytdID0g
InNjcmlwdCI7Cj4+ICAgICAgZW52W25yKytdID0gc2NyaXB0Owo+PiBAQCAtOTgsNiArMTAzLDgg
QEAgc3RhdGljIGNoYXIgKipnZXRfaG90cGx1Z19lbnYobGlieGxfX2djICpnYywKPj4gICAgICBl
bnZbbnIrK10gPSBHQ1NQUklOVEYoImJhY2tlbmQvJXMvJXUvJWQiLCB0eXBlLCBkZXYtPmRvbWlk
LCBkZXYtPmRldmlkKTsKPj4gICAgICBlbnZbbnIrK10gPSAiWEVOQlVTX0JBU0VfUEFUSCI7Cj4+
ICAgICAgZW52W25yKytdID0gImJhY2tlbmQiOwo+PiArICAgIGVudltucisrXSA9ICJuZXRkZXYi
Owo+PiArICAgIGVudltucisrXSA9IG5ldGRldjsKPiAKPiBNaWdodG4ndCB0aGlzIGJlIE5VTEw/
CgpZZXMsIGlmIHdlIGFyZSB1c2luZyB0aGUgdmlmLWJyaWRnZSBzY3JpcHQgdGhpcyB3aWxsIGJl
IE5VTEwsIGJ1dCBJCnByZWZlciBhZGRpbmcgdGhpcyBOVUxMIGhlcmUgcmF0aGVyIHRoYW4gaGF2
aW5nIGEgY29uZGl0aW9uYWwgYW5kIGEKdmFyaWFibGUgYXJyYXkgc2l6ZSAoYmVjYXVzZSB3ZSBh
bHNvIGhhdmUgYW4gYXNzZXJ0KG5yID09IGFycmF5c2l6ZSkgYXQKdGhlIGVuZCBvZiB0aGUgY29k
ZSBibG9jaykuCgo+IAo+PiAgICAgIGlmIChkZXYtPmJhY2tlbmRfa2luZCA9PSBMSUJYTF9fREVW
SUNFX0tJTkRfVklGKSB7Cj4+ICAgICAgICAgIGlmIChsaWJ4bF9fbmljX3R5cGUoZ2MsIGRldiwg
Jm5pY3R5cGUpKSB7Cj4+ICAgICAgICAgICAgICBMT0coRVJST1IsICJ1bmFibGUgdG8gZ2V0IG5p
Y3R5cGUiKTsKPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+PiBpbmRleCBhY2M0YmM5Li4wZTc5NDNlIDEwMDY0
NAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKPj4gKysrIGIvdG9vbHMvbGli
eGwvbGlieGxfdHlwZXMuaWRsCj4+IEBAIC0zODIsNiArMzgyLDcgQEAgbGlieGxfZGV2aWNlX25p
YyA9IFN0cnVjdCgiZGV2aWNlX25pYyIsIFsKPj4gICAgICAoIm5pY3R5cGUiLCBsaWJ4bF9uaWNf
dHlwZSksCj4+ICAgICAgKCJyYXRlX2J5dGVzX3Blcl9pbnRlcnZhbCIsIHVpbnQ2NCksCj4+ICAg
ICAgKCJyYXRlX2ludGVydmFsX3VzZWNzIiwgdWludDMyKSwKPj4gKyAgICAoIm5ldGRldiIsIHN0
cmluZyksCj4+ICAgICAgXSkKPj4gIAo+PiAgbGlieGxfZGV2aWNlX3BjaSA9IFN0cnVjdCgiZGV2
aWNlX3BjaSIsIFsKPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+PiBpbmRleCBlOTY0YmYxLi45MmE2NGU0IDEwMDY0NAo+
PiAtLS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKPj4gKysrIGIvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCj4+IEBAIC0xMjA1LDYgKzEyMDUsOSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25m
aWdfZGF0YShjb25zdCBjaGFyICpjb25maWdfc291cmNlLAo+PiAgICAgICAgICAgICAgICAgICAg
ICBwYXJzZV92aWZfcmF0ZSgmY29uZmlnLCAocDIgKyAxKSwgbmljKTsKPj4gICAgICAgICAgICAg
ICAgICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgImFjY2VsIikpIHsKPj4gICAgICAgICAgICAgICAg
ICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1
cnJlbnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKPj4gKyAgICAgICAgICAgICAgICB9IGVsc2UgaWYg
KCFzdHJjbXAocCwgIm5ldGRldiIpKSB7Cj4+ICsgICAgICAgICAgICAgICAgICAgIGZyZWUobmlj
LT5uZXRkZXYpOwo+PiArICAgICAgICAgICAgICAgICAgICBuaWMtPm5ldGRldiA9IHN0cmR1cChw
MiArIDEpOwo+PiAgICAgICAgICAgICAgICAgIH0KPj4gICAgICAgICAgICAgIH0gd2hpbGUgKChw
ID0gc3RydG9rKE5VTEwsICIsIikpICE9IE5VTEwpOwo+PiAgc2tpcF9uaWM6Cj4+IEBAIC01NTEx
LDYgKzU1MTQsOCBAQCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqYXJn
dikKPj4gICAgICAgICAgICAgIH0KPj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04o
ImJyaWRnZSIsICphcmd2LCBvcGFyZykpIHsKPj4gICAgICAgICAgICAgIHJlcGxhY2Vfc3RyaW5n
KCZuaWMuYnJpZGdlLCBvcGFyZyk7Cj4+ICsgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9O
KCJuZXRkZXYiLCAqYXJndiwgb3BhcmcpKSB7Cj4+ICsgICAgICAgICAgICByZXBsYWNlX3N0cmlu
ZygmbmljLm5ldGRldiwgb3BhcmcpOwo+PiAgICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElP
TigiaXAiLCAqYXJndiwgb3BhcmcpKSB7Cj4+ICAgICAgICAgICAgICByZXBsYWNlX3N0cmluZygm
bmljLmlwLCBvcGFyZyk7Cj4+ICAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9OKCJzY3Jp
cHQiLCAqYXJndiwgb3BhcmcpKSB7Cj4gCj4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:57:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 10:57: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 1U2gCz-0000vs-Js; Tue, 05 Feb 2013 10:57: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 1U2gCx-0000vn-L9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:56:59 +0000
Received: from [85.158.137.99:29772] by server-6.bemta-3.messagelabs.com id
	D8/EB-29959-A75E0115; Tue, 05 Feb 2013 10:56:58 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360061799!19933320!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28214 invoked from network); 5 Feb 2013 10:56:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1149933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:56:36 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	10:56:36 +0000
Message-ID: <5110E563.8030604@citrix.com>
Date: Tue, 5 Feb 2013 11:56:35 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360060806.17017.25.camel@zakaz.uk.xensource.com>
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
	specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMDUvMDIvMTMgMTE6NDAsIElhbiBDYW1wYmVsbCB3cm90ZToKPiBPbiBGcmksIDIwMTMtMDEt
MjUgYXQgMTU6MjYgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4gVGhpcyBvcHRpb24g
d2FzIHN1cHBvcnRlZCBpbiB0aGUgcGFzdCwgYWNjb3JkaW5nIHRvCj4+IGh0dHA6Ly93aWtpLnhl
bi5vcmcvd2lraS9WaWYtcm91dGUsIHNvIHdlIHNob3VsZCBhbHNvIHN1cHBvcnQgaXQgaW4KPj4g
bGlieGwuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPgo+PiBDYzogVWxmIEtyZXV0emJlcmcgPHVsZi5rcmV1dHpiZXJnQGhvc3RldXJv
cGUuZGU+Cj4+IC0tLQo+PiAgZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJr
ZG93biB8ICAgIDYgKysrKysrCj4+ICB0b29scy9saWJ4bC9saWJ4bC5jICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgNiArKysrKy0KPj4gIHRvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMgICAg
ICAgICAgICAgICAgICAgfCAgICA5ICsrKysrKysrLQo+PiAgdG9vbHMvbGlieGwvbGlieGxfdHlw
ZXMuaWRsICAgICAgICAgICAgICAgICB8ICAgIDEgKwo+PiAgdG9vbHMvbGlieGwveGxfY21kaW1w
bC5jICAgICAgICAgICAgICAgICAgICB8ICAgIDUgKysrKysKPj4gIDUgZmlsZXMgY2hhbmdlZCwg
MjUgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL2RvY3Mv
bWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYi9kb2NzL21pc2MveGwtbmV0
d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCj4+IGluZGV4IDVlMmYwNDkuLmI5OGIyOGUgMTAw
NjQ0Cj4+IC0tLSBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24K
Pj4gKysrIGIvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93bgo+PiBA
QCAtNjcsNiArNjcsMTIgQEAgYWRkZWQgdG8uIFRoZSBkZWZhdWx0IGlzIGB4ZW5icjBgLiBUaGUg
YnJpZGdlIG11c3QgYmUgY29uZmlndXJlZCB1c2luZwo+PiAgeW91ciBkaXN0cmlidXRpb24ncyBu
ZXR3b3JrIGNvbmZpZ3VyYXRpb24gdG9vbHMuIFNlZSB0aGUgW3dpa2ldW25ldF0KPj4gIGZvciBn
dWlkYW5jZSBhbmQgZXhhbXBsZXMuCj4+ICAKPj4gKyMjIyBuZXRkZXYKPj4gKwo+PiArU3BlY2lm
aWVzIHRoZSBuYW1lIG9mIHRoZSBuZXR3b3JrIGludGVyZmFjZSB3aGljaCBoYXMgYW4gSVAgYW5k
IHdoaWNoCj4+ICtpcyBpbiB0aGUgbmV0d29yayB0aGUgVklGIHNob3VsZCBjb21tdW5pY2F0ZSB3
aXRoLgo+IAo+IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBjbGFyaWZ5IHRoYXQgaXQgaXMgYSBob3N0
IG5ldHdvcmsgZGV2aWNlLgoKQWNrCgo+IAo+PiAgVGhpcyBpcyB1c2VkIGJ5IHRoZQo+PiArdmlm
LXJvdXRlIGhvdHBsdWcgc2NyaXB0LiBTZWUgW3dpa2ldW3ZpZi1yb3V0ZV0gZm9yIGd1aWRhbmNl
IGFuZCBleGFtcGxlcy4KPiAKPiBZb3UgbmVlZCB0byBhZGQgYSBVUkwgZm9yIHZpZi1yb3V0ZSBu
ZWFyIHRoZSBib3R0b20gSSB0aGluay4KPiAKPj4gKwo+PiAgIyMjIHR5cGUKPj4gIAo+PiAgVGhp
cyBrZXl3b3JkIGlzIHZhbGlkIGZvciBIVk0gZ3Vlc3RzIG9ubHkuCj4+IGRpZmYgLS1naXQgYS90
b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwvbGlieGwuYwo+PiBpbmRleCA3M2UwZGMz
Li4wM2JmZTFhIDEwMDY0NAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCj4+ICsrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsLmMKPj4gQEAgLTI4MjYsNyArMjgyNiw3IEBAIHZvaWQgbGlieGxfX2Rl
dmljZV9uaWNfYWRkKGxpYnhsX19lZ2MgKmVnYywgdWludDMyX3QgZG9taWQsCj4+ICAgICAgaWYg
KHJjKSBnb3RvIG91dDsKPj4gIAo+PiAgICAgIGZyb250ID0gZmxleGFycmF5X21ha2UoZ2MsIDE2
LCAxKTsKPj4gLSAgICBiYWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE2LCAxKTsKPj4gKyAgICBi
YWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE4LCAxKTsKPj4gIAo+PiAgICAgIGlmIChuaWMtPmRl
dmlkID09IC0xKSB7Cj4+ICAgICAgICAgIGlmICgobmljLT5kZXZpZCA9IGxpYnhsX19kZXZpY2Vf
bmV4dGlkKGdjLCBkb21pZCwgInZpZiIpIDwgMCkpIHsKPj4gQEAgLTI4NjIsNiArMjg2MiwxMCBA
QCB2b2lkIGxpYnhsX19kZXZpY2VfbmljX2FkZChsaWJ4bF9fZWdjICplZ2MsIHVpbnQzMl90IGRv
bWlkLAo+PiAgICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJpcCIpOwo+PiAgICAgICAg
ICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+aXApKTsKPj4g
ICAgICB9Cj4+ICsgICAgaWYgKG5pYy0+bmV0ZGV2KSB7Cj4+ICsgICAgICAgIGZsZXhhcnJheV9h
cHBlbmQoYmFjaywgIm5ldGRldiIpOwo+PiArICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ss
IGxpYnhsX19zdHJkdXAoZ2MsIG5pYy0+bmV0ZGV2KSk7Cj4+ICsgICAgfQo+PiAgCj4+ICAgICAg
aWYgKG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcyA+IDApIHsKPj4gICAgICAgICAgZmxleGFycmF5
X2FwcGVuZChiYWNrLCAicmF0ZSIpOwo+PiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGwvbGlieGxf
bGludXguYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKPj4gaW5kZXggMWZlZDNjZC4uNGNi
ZGMxOSAxMDA2NDQKPj4gLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfbGludXguYwo+PiArKysgYi90
b29scy9saWJ4bC9saWJ4bF9saW51eC5jCj4+IEBAIC04NCwxMSArODQsMTYgQEAgc3RhdGljIGNo
YXIgKipnZXRfaG90cGx1Z19lbnYobGlieGxfX2djICpnYywKPj4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGNoYXIgKnNjcmlwdCwgbGlieGxfX2RldmljZSAqZGV2KQo+PiAgewo+PiAg
ICAgIGNvbnN0IGNoYXIgKnR5cGUgPSBsaWJ4bF9fZGV2aWNlX2tpbmRfdG9fc3RyaW5nKGRldi0+
YmFja2VuZF9raW5kKTsKPj4gKyAgICBjaGFyICpiZV9wYXRoID0gbGlieGxfX2RldmljZV9iYWNr
ZW5kX3BhdGgoZ2MsIGRldik7Cj4+ICAgICAgY2hhciAqKmVudjsKPj4gKyAgICBjaGFyICpuZXRk
ZXY7Cj4+ICAgICAgaW50IG5yID0gMDsKPj4gICAgICBsaWJ4bF9uaWNfdHlwZSBuaWN0eXBlOwo+
PiAgCj4+IC0gICAgY29uc3QgaW50IGFycmF5c2l6ZSA9IDEzOwo+PiArICAgIG5ldGRldiA9IGxp
YnhsX194c19yZWFkKGdjLCBYQlRfTlVMTCwgR0NTUFJJTlRGKCIlcy8lcyIsIGJlX3BhdGgsCj4+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIm5ldGRldiIpKTsKPj4gKwo+PiArICAgIGNvbnN0IGludCBhcnJheXNpemUgPSAxNTsK
Pj4gICAgICBHQ05FV19BUlJBWShlbnYsIGFycmF5c2l6ZSk7Cj4+ICAgICAgZW52W25yKytdID0g
InNjcmlwdCI7Cj4+ICAgICAgZW52W25yKytdID0gc2NyaXB0Owo+PiBAQCAtOTgsNiArMTAzLDgg
QEAgc3RhdGljIGNoYXIgKipnZXRfaG90cGx1Z19lbnYobGlieGxfX2djICpnYywKPj4gICAgICBl
bnZbbnIrK10gPSBHQ1NQUklOVEYoImJhY2tlbmQvJXMvJXUvJWQiLCB0eXBlLCBkZXYtPmRvbWlk
LCBkZXYtPmRldmlkKTsKPj4gICAgICBlbnZbbnIrK10gPSAiWEVOQlVTX0JBU0VfUEFUSCI7Cj4+
ICAgICAgZW52W25yKytdID0gImJhY2tlbmQiOwo+PiArICAgIGVudltucisrXSA9ICJuZXRkZXYi
Owo+PiArICAgIGVudltucisrXSA9IG5ldGRldjsKPiAKPiBNaWdodG4ndCB0aGlzIGJlIE5VTEw/
CgpZZXMsIGlmIHdlIGFyZSB1c2luZyB0aGUgdmlmLWJyaWRnZSBzY3JpcHQgdGhpcyB3aWxsIGJl
IE5VTEwsIGJ1dCBJCnByZWZlciBhZGRpbmcgdGhpcyBOVUxMIGhlcmUgcmF0aGVyIHRoYW4gaGF2
aW5nIGEgY29uZGl0aW9uYWwgYW5kIGEKdmFyaWFibGUgYXJyYXkgc2l6ZSAoYmVjYXVzZSB3ZSBh
bHNvIGhhdmUgYW4gYXNzZXJ0KG5yID09IGFycmF5c2l6ZSkgYXQKdGhlIGVuZCBvZiB0aGUgY29k
ZSBibG9jaykuCgo+IAo+PiAgICAgIGlmIChkZXYtPmJhY2tlbmRfa2luZCA9PSBMSUJYTF9fREVW
SUNFX0tJTkRfVklGKSB7Cj4+ICAgICAgICAgIGlmIChsaWJ4bF9fbmljX3R5cGUoZ2MsIGRldiwg
Jm5pY3R5cGUpKSB7Cj4+ICAgICAgICAgICAgICBMT0coRVJST1IsICJ1bmFibGUgdG8gZ2V0IG5p
Y3R5cGUiKTsKPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbCBiL3Rv
b2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAo+PiBpbmRleCBhY2M0YmM5Li4wZTc5NDNlIDEwMDY0
NAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKPj4gKysrIGIvdG9vbHMvbGli
eGwvbGlieGxfdHlwZXMuaWRsCj4+IEBAIC0zODIsNiArMzgyLDcgQEAgbGlieGxfZGV2aWNlX25p
YyA9IFN0cnVjdCgiZGV2aWNlX25pYyIsIFsKPj4gICAgICAoIm5pY3R5cGUiLCBsaWJ4bF9uaWNf
dHlwZSksCj4+ICAgICAgKCJyYXRlX2J5dGVzX3Blcl9pbnRlcnZhbCIsIHVpbnQ2NCksCj4+ICAg
ICAgKCJyYXRlX2ludGVydmFsX3VzZWNzIiwgdWludDMyKSwKPj4gKyAgICAoIm5ldGRldiIsIHN0
cmluZyksCj4+ICAgICAgXSkKPj4gIAo+PiAgbGlieGxfZGV2aWNlX3BjaSA9IFN0cnVjdCgiZGV2
aWNlX3BjaSIsIFsKPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rv
b2xzL2xpYnhsL3hsX2NtZGltcGwuYwo+PiBpbmRleCBlOTY0YmYxLi45MmE2NGU0IDEwMDY0NAo+
PiAtLS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKPj4gKysrIGIvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCj4+IEBAIC0xMjA1LDYgKzEyMDUsOSBAQCBzdGF0aWMgdm9pZCBwYXJzZV9jb25m
aWdfZGF0YShjb25zdCBjaGFyICpjb25maWdfc291cmNlLAo+PiAgICAgICAgICAgICAgICAgICAg
ICBwYXJzZV92aWZfcmF0ZSgmY29uZmlnLCAocDIgKyAxKSwgbmljKTsKPj4gICAgICAgICAgICAg
ICAgICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgImFjY2VsIikpIHsKPj4gICAgICAgICAgICAgICAg
ICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVyIGZvciB2aWZzIGlzIGN1
cnJlbnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKPj4gKyAgICAgICAgICAgICAgICB9IGVsc2UgaWYg
KCFzdHJjbXAocCwgIm5ldGRldiIpKSB7Cj4+ICsgICAgICAgICAgICAgICAgICAgIGZyZWUobmlj
LT5uZXRkZXYpOwo+PiArICAgICAgICAgICAgICAgICAgICBuaWMtPm5ldGRldiA9IHN0cmR1cChw
MiArIDEpOwo+PiAgICAgICAgICAgICAgICAgIH0KPj4gICAgICAgICAgICAgIH0gd2hpbGUgKChw
ID0gc3RydG9rKE5VTEwsICIsIikpICE9IE5VTEwpOwo+PiAgc2tpcF9uaWM6Cj4+IEBAIC01NTEx
LDYgKzU1MTQsOCBAQCBpbnQgbWFpbl9uZXR3b3JrYXR0YWNoKGludCBhcmdjLCBjaGFyICoqYXJn
dikKPj4gICAgICAgICAgICAgIH0KPj4gICAgICAgICAgfSBlbHNlIGlmIChNQVRDSF9PUFRJT04o
ImJyaWRnZSIsICphcmd2LCBvcGFyZykpIHsKPj4gICAgICAgICAgICAgIHJlcGxhY2Vfc3RyaW5n
KCZuaWMuYnJpZGdlLCBvcGFyZyk7Cj4+ICsgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9O
KCJuZXRkZXYiLCAqYXJndiwgb3BhcmcpKSB7Cj4+ICsgICAgICAgICAgICByZXBsYWNlX3N0cmlu
ZygmbmljLm5ldGRldiwgb3BhcmcpOwo+PiAgICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElP
TigiaXAiLCAqYXJndiwgb3BhcmcpKSB7Cj4+ICAgICAgICAgICAgICByZXBsYWNlX3N0cmluZygm
bmljLmlwLCBvcGFyZyk7Cj4+ICAgICAgICAgIH0gZWxzZSBpZiAoTUFUQ0hfT1BUSU9OKCJzY3Jp
cHQiLCAqYXJndiwgb3BhcmcpKSB7Cj4gCj4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:59:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2gEr-00010v-4H; Tue, 05 Feb 2013 10:58:57 +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 1U2gEp-00010p-Gm
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:58:55 +0000
Received: from [193.109.254.147:7195] by server-13.bemta-14.messagelabs.com id
	4C/D9-30639-EE5E0115; Tue, 05 Feb 2013 10:58:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360061932!9273399!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18312 invoked from network); 5 Feb 2013 10:58:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:58: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.297.1; Tue, 5 Feb 2013
	10:58:51 +0000
Message-ID: <1360061930.17017.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 5 Feb 2013 10:58:50 +0000
In-Reply-To: <1358866214.1836.35.camel@zion.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-01-22 at 14:50 +0000, Wei Liu wrote:
> > > > > +		    !(reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) &&
> > > > 
> > > > This represents an error case I think? Is there anything we can do about
> > > > it? If this sort of error occurs and we do nothing will we end up just
> > > > spinning because every subsequent poll will just return straight away?
> > > > 
> > > > 
> > > 
> > > Yes, this represents an error. This indicates the pipe used to trigger
> > > reopen_log is broken. What's the motivation of reopening log file?
> > 
> > Rotation I should imagine.
> > 
> > >  I
> > > have no idea about the use case. But simply ignoring this error instead
> > > of crashing the process is better choice IMHO.
> > 
> > Agreed, but my concern was that the daemon would spin consuming 100%
> > CPU, which is nearly as bad as crashing.
> > 
> > > The whole pollfd set is reinitialized for every loop. So it is also
> > > possible that for the next loop it will success even previous poll
> > > fails?
> > 
> > I suppose it depends on the reason it failed. I would expect most of
> > them would be pretty final rather than temporary but I haven't looked at
> > the pipe docs.
> > 
> 
> We can reinitialize the pipe if error occurs, because this pipe is only
> used within xenstored itself to notify log reload.

But if you get POLLPRI or POLLOUT you don't do this with the code as it
currently stands (from the v2 patch):
+                       if (reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) {
+                               close(reopen_log_pipe[0]);
+                               close(reopen_log_pipe[1]);
+                               init_pipe(reopen_log_pipe);
+                       } else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
+                               char c;
+                               if (read(reopen_log_pipe[0], &c, 1) != 1)
+                                       barf_perror("read failed");
+                               reopen_log();
+                       }

So on POLLRDHUP or POLLERR etc you reopen the log, on POLLIN you act as
expected but for POLLPRI and POLLOUT you don't do anything.

If these two events should never occur then you should include the in
the error handling part of the above. If they can occur then you need to
do something to handle them, otherwise they will just keep reoccuring on
every iteration.

The same goes for the other instances of this pattern.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 10:59:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2gEr-00010v-4H; Tue, 05 Feb 2013 10:58:57 +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 1U2gEp-00010p-Gm
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 10:58:55 +0000
Received: from [193.109.254.147:7195] by server-13.bemta-14.messagelabs.com id
	4C/D9-30639-EE5E0115; Tue, 05 Feb 2013 10:58:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360061932!9273399!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18312 invoked from network); 5 Feb 2013 10:58:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 10:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10:58: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.297.1; Tue, 5 Feb 2013
	10:58:51 +0000
Message-ID: <1360061930.17017.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 5 Feb 2013 10:58:50 +0000
In-Reply-To: <1358866214.1836.35.camel@zion.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-01-22 at 14:50 +0000, Wei Liu wrote:
> > > > > +		    !(reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) &&
> > > > 
> > > > This represents an error case I think? Is there anything we can do about
> > > > it? If this sort of error occurs and we do nothing will we end up just
> > > > spinning because every subsequent poll will just return straight away?
> > > > 
> > > > 
> > > 
> > > Yes, this represents an error. This indicates the pipe used to trigger
> > > reopen_log is broken. What's the motivation of reopening log file?
> > 
> > Rotation I should imagine.
> > 
> > >  I
> > > have no idea about the use case. But simply ignoring this error instead
> > > of crashing the process is better choice IMHO.
> > 
> > Agreed, but my concern was that the daemon would spin consuming 100%
> > CPU, which is nearly as bad as crashing.
> > 
> > > The whole pollfd set is reinitialized for every loop. So it is also
> > > possible that for the next loop it will success even previous poll
> > > fails?
> > 
> > I suppose it depends on the reason it failed. I would expect most of
> > them would be pretty final rather than temporary but I haven't looked at
> > the pipe docs.
> > 
> 
> We can reinitialize the pipe if error occurs, because this pipe is only
> used within xenstored itself to notify log reload.

But if you get POLLPRI or POLLOUT you don't do this with the code as it
currently stands (from the v2 patch):
+                       if (reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) {
+                               close(reopen_log_pipe[0]);
+                               close(reopen_log_pipe[1]);
+                               init_pipe(reopen_log_pipe);
+                       } else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
+                               char c;
+                               if (read(reopen_log_pipe[0], &c, 1) != 1)
+                                       barf_perror("read failed");
+                               reopen_log();
+                       }

So on POLLRDHUP or POLLERR etc you reopen the log, on POLLIN you act as
expected but for POLLPRI and POLLOUT you don't do anything.

If these two events should never occur then you should include the in
the error handling part of the above. If they can occur then you need to
do something to handle them, otherwise they will just keep reoccuring on
every iteration.

The same goes for the other instances of this pattern.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:00:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gGU-00019S-LZ; Tue, 05 Feb 2013 11:00: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 1U2gGT-00019G-4z
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:00:37 +0000
Received: from [85.158.137.99:23067] by server-6.bemta-3.messagelabs.com id
	CC/B2-29959-456E0115; Tue, 05 Feb 2013 11:00:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360062019!12206014!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5723 invoked from network); 5 Feb 2013 11:00:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:00:19 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	11:00:18 +0000
Message-ID: <5110E641.9090902@citrix.com>
Date: Tue, 5 Feb 2013 12:00:17 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-3-git-send-email-roger.pau@citrix.com>
	<CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
	<1360060895.17017.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360060895.17017.27.camel@zakaz.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xl: allow specifying a default netdev
 in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 11:41, Ian Campbell wrote:
> On Mon, 2013-01-28 at 11:00 +0000, George Dunlap wrote:
>> On Fri, Jan 25, 2013 at 3:26 PM, Roger Pau Monne
>> <roger.pau@citrix.com> wrote:
>>         This adds a new global option in the xl configuration file
>>         called
>>         "defaultnetdev", that is used to specify the default netdev to
>>         use
>>         when none is passed in the vif specification.
>>
>>
>> I'm not a fan of the name, though; it doesn't seem very scalable.  It
>> looks like we already have "defaultbridge', so I can see this is just
>> following precedent, but I wonder if it might be worth putting some
>> more thought into it before proceeding?
>>
>>
>> It seems like if we're going to have a default sub-option, it should
>> at least have the name of the option in which it resides.
>> "vif_netdev_default" or "default_vif_netdev" seem like better option.
>> Or maybe "vif.netdev.default"? "defaults.vif.netdev"?
> 
> netdev is also a bit non-descriptive, even if it is what the vif-route
> script uses perhaps we present something more meaningful to the user?
> 
> "gatewaydev" or something along those lines perhaps?

Will this also imply that xl should use gatewaydev instead of netdev in
the vif config line? Right now we don't support netdev, but I guess we
should add it for backwards compatibility.

> I'd be inclined to use whatever name we decide here in the libxl
> API/internals as well and just go netdev at the hotplug script
> interface.
> 
> Ian.
> 
> 


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:00:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gGU-00019S-LZ; Tue, 05 Feb 2013 11:00: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 1U2gGT-00019G-4z
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:00:37 +0000
Received: from [85.158.137.99:23067] by server-6.bemta-3.messagelabs.com id
	CC/B2-29959-456E0115; Tue, 05 Feb 2013 11:00:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360062019!12206014!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5723 invoked from network); 5 Feb 2013 11:00:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:00:19 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	11:00:18 +0000
Message-ID: <5110E641.9090902@citrix.com>
Date: Tue, 5 Feb 2013 12:00:17 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-3-git-send-email-roger.pau@citrix.com>
	<CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
	<1360060895.17017.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360060895.17017.27.camel@zakaz.uk.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xl: allow specifying a default netdev
 in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 11:41, Ian Campbell wrote:
> On Mon, 2013-01-28 at 11:00 +0000, George Dunlap wrote:
>> On Fri, Jan 25, 2013 at 3:26 PM, Roger Pau Monne
>> <roger.pau@citrix.com> wrote:
>>         This adds a new global option in the xl configuration file
>>         called
>>         "defaultnetdev", that is used to specify the default netdev to
>>         use
>>         when none is passed in the vif specification.
>>
>>
>> I'm not a fan of the name, though; it doesn't seem very scalable.  It
>> looks like we already have "defaultbridge', so I can see this is just
>> following precedent, but I wonder if it might be worth putting some
>> more thought into it before proceeding?
>>
>>
>> It seems like if we're going to have a default sub-option, it should
>> at least have the name of the option in which it resides.
>> "vif_netdev_default" or "default_vif_netdev" seem like better option.
>> Or maybe "vif.netdev.default"? "defaults.vif.netdev"?
> 
> netdev is also a bit non-descriptive, even if it is what the vif-route
> script uses perhaps we present something more meaningful to the user?
> 
> "gatewaydev" or something along those lines perhaps?

Will this also imply that xl should use gatewaydev instead of netdev in
the vif config line? Right now we don't support netdev, but I guess we
should add it for backwards compatibility.

> I'd be inclined to use whatever name we decide here in the libxl
> API/internals as well and just go netdev at the hotplug script
> interface.
> 
> Ian.
> 
> 


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:07:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:07: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 1U2gN1-0001T3-HH; Tue, 05 Feb 2013 11:07:23 +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 1U2gN0-0001Sy-9U
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:07:22 +0000
Received: from [85.158.139.211:30036] by server-16.bemta-5.messagelabs.com id
	65/DE-14948-9E7E0115; Tue, 05 Feb 2013 11:07:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360062440!20080250!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28049 invoked from network); 5 Feb 2013 11:07:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:07:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:07: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.297.1; Tue, 5 Feb 2013
	11:07:20 +0000
Message-ID: <1360062439.17017.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:07:19 +0000
In-Reply-To: <256d59b2bc8a41387655.1359648303@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: pass debug flag down to
 libxl_domain_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 Thu, 2013-01-31 at 16:05 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359648298 -3600
> # Node ID 256d59b2bc8a413876559dc8daf4c52ba46677de
> # Parent  12455da211d4e841692b2374086356a87eb74ff7
> libxl: pass debug flag down to libxl_domain_suspend
> 
> libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> and xl migrate handles the -d switch as well. Pass this flag down to
> libxl_domain_suspend, so that finally xc_domain_save can dump huge
> amount of debug data to stdout.
> Update xl.5 and help text output.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 12455da211d4 -r 256d59b2bc8a docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -387,6 +387,10 @@ domain. See the corresponding option of 
>  
>  Send <config> instead of config file from creation.
>  
> +=item B<-e>

You mean -d here.

I wonder if we should make this option a bit more obscure (e.g. a long
option only) ? Or tie it to verbose > 5 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 Feb 05 11:07:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:07: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 1U2gN1-0001T3-HH; Tue, 05 Feb 2013 11:07:23 +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 1U2gN0-0001Sy-9U
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:07:22 +0000
Received: from [85.158.139.211:30036] by server-16.bemta-5.messagelabs.com id
	65/DE-14948-9E7E0115; Tue, 05 Feb 2013 11:07:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360062440!20080250!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28049 invoked from network); 5 Feb 2013 11:07:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:07:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:07: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.297.1; Tue, 5 Feb 2013
	11:07:20 +0000
Message-ID: <1360062439.17017.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:07:19 +0000
In-Reply-To: <256d59b2bc8a41387655.1359648303@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: pass debug flag down to
 libxl_domain_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 Thu, 2013-01-31 at 16:05 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359648298 -3600
> # Node ID 256d59b2bc8a413876559dc8daf4c52ba46677de
> # Parent  12455da211d4e841692b2374086356a87eb74ff7
> libxl: pass debug flag down to libxl_domain_suspend
> 
> libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> and xl migrate handles the -d switch as well. Pass this flag down to
> libxl_domain_suspend, so that finally xc_domain_save can dump huge
> amount of debug data to stdout.
> Update xl.5 and help text output.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 12455da211d4 -r 256d59b2bc8a docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -387,6 +387,10 @@ domain. See the corresponding option of 
>  
>  Send <config> instead of config file from creation.
>  
> +=item B<-e>

You mean -d here.

I wonder if we should make this option a bit more obscure (e.g. a long
option only) ? Or tie it to verbose > 5 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 Feb 05 11:07:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:07: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 1U2gNO-0001Uu-57; Tue, 05 Feb 2013 11:07: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 1U2gNM-0001Uh-VO
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:07:45 +0000
Received: from [85.158.139.211:61770] by server-1.bemta-5.messagelabs.com id
	48/41-29263-008E0115; Tue, 05 Feb 2013 11:07:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360062463!21127069!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18820 invoked from network); 5 Feb 2013 11:07:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:07:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:07: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.297.1; Tue, 5 Feb 2013
	11:07:43 +0000
Message-ID: <1360062461.17017.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:07:41 +0000
In-Reply-To: <7265026699c6a72e150d.1359658178@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
	<7265026699c6a72e150d.1359658178@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: pass debug flag down to
 libxl_domain_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 Thu, 2013-01-31 at 18:49 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359658156 -3600
> # Node ID 7265026699c6a72e150d40d2fb45fd4131c83c19
> # Parent  12455da211d4e841692b2374086356a87eb74ff7
> libxl: pass debug flag down to libxl_domain_suspend
> 
> libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> and xl migrate handles the -d switch as well. Pass this flag down to
> libxl_domain_suspend, so that finally xc_domain_save can dump huge
> amount of debug data to stdout.
> Update xl.1 and help text output.
> 
> v2:
>  - fix xl.1 option, really use -d instead of -e

Oops, you can ignore my first comment on v1 then ;-)



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:07:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:07: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 1U2gNO-0001Uu-57; Tue, 05 Feb 2013 11:07: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 1U2gNM-0001Uh-VO
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:07:45 +0000
Received: from [85.158.139.211:61770] by server-1.bemta-5.messagelabs.com id
	48/41-29263-008E0115; Tue, 05 Feb 2013 11:07:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360062463!21127069!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18820 invoked from network); 5 Feb 2013 11:07:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:07:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:07: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.297.1; Tue, 5 Feb 2013
	11:07:43 +0000
Message-ID: <1360062461.17017.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:07:41 +0000
In-Reply-To: <7265026699c6a72e150d.1359658178@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
	<7265026699c6a72e150d.1359658178@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: pass debug flag down to
 libxl_domain_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 Thu, 2013-01-31 at 18:49 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359658156 -3600
> # Node ID 7265026699c6a72e150d40d2fb45fd4131c83c19
> # Parent  12455da211d4e841692b2374086356a87eb74ff7
> libxl: pass debug flag down to libxl_domain_suspend
> 
> libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> and xl migrate handles the -d switch as well. Pass this flag down to
> libxl_domain_suspend, so that finally xc_domain_save can dump huge
> amount of debug data to stdout.
> Update xl.1 and help text output.
> 
> v2:
>  - fix xl.1 option, really use -d instead of -e

Oops, you can ignore my first comment on v1 then ;-)



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:09:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gOX-0001e3-O8; Tue, 05 Feb 2013 11:08: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 1U2gOW-0001do-02
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:08:56 +0000
Received: from [85.158.143.35:39061] by server-2.bemta-4.messagelabs.com id
	2A/DB-01597-748E0115; Tue, 05 Feb 2013 11:08:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360062000!11944134!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3703 invoked from network); 5 Feb 2013 11:00:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:00:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10: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.297.1; Tue, 5 Feb 2013
	10:59:56 +0000
Message-ID: <1360061994.17017.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Tue, 5 Feb 2013 10:59:54 +0000
In-Reply-To: <1359623804.12252.257.camel@zakaz.uk.xensource.com>
References: <1358448953-2892-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1358448953-2892-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1358500751.13856.108.camel@zakaz.uk.xensource.com>
	<1359623804.12252.257.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
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 3/3] xen/arch/arm: add XSM hook to
 HVMOP_{get, set}_param
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, Tim, can you (n)ack this please.

On Thu, 2013-01-31 at 09:16 +0000, Ian Campbell wrote:
> 8<--------------------------------
> 
> From f2ec1f2cba7eab8d6c6c93378625379abe0e29bc Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 31 Jan 2013 09:14:40 +0000
> Subject: [PATCH] xen: arm: fix build of hvm.c
> 
> Add include of xsm/xsm.h to fix:
> 
> hvm.c: In function 'do_hvm_op': hvm.c:37:9: error: implicit declaration of function 'xsm_hvm_param' [-Werror=implicit-function-declaration]
> hvm.c:37:9: error: nested extern declaration of 'xsm_hvm_param' [-Werror=nested-externs]
> hvm.c:37:28: error: 'XSM_TARGET' undeclared (first use in this function)
> hvm.c:37:28: note: each undeclared identifier is reported only once for each function it appears in
> cc1: all warnings being treated as errors
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
> Cc: Tim Deegan <tim@xen.org>
> ---
>  xen/arch/arm/hvm.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
> index 63ac793..471c4cd 100644
> --- a/xen/arch/arm/hvm.c
> +++ b/xen/arch/arm/hvm.c
> @@ -5,6 +5,8 @@
>  #include <xen/guest_access.h>
>  #include <xen/sched.h>
>  
> +#include <xsm/xsm.h>
> +
>  #include <public/xen.h>
>  #include <public/hvm/params.h>
>  #include <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 Tue Feb 05 11:09:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gOX-0001e3-O8; Tue, 05 Feb 2013 11:08: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 1U2gOW-0001do-02
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:08:56 +0000
Received: from [85.158.143.35:39061] by server-2.bemta-4.messagelabs.com id
	2A/DB-01597-748E0115; Tue, 05 Feb 2013 11:08:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360062000!11944134!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3703 invoked from network); 5 Feb 2013 11:00:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:00:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 10: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.297.1; Tue, 5 Feb 2013
	10:59:56 +0000
Message-ID: <1360061994.17017.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Tue, 5 Feb 2013 10:59:54 +0000
In-Reply-To: <1359623804.12252.257.camel@zakaz.uk.xensource.com>
References: <1358448953-2892-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1358448953-2892-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1358500751.13856.108.camel@zakaz.uk.xensource.com>
	<1359623804.12252.257.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
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 3/3] xen/arch/arm: add XSM hook to
 HVMOP_{get, set}_param
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, Tim, can you (n)ack this please.

On Thu, 2013-01-31 at 09:16 +0000, Ian Campbell wrote:
> 8<--------------------------------
> 
> From f2ec1f2cba7eab8d6c6c93378625379abe0e29bc Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 31 Jan 2013 09:14:40 +0000
> Subject: [PATCH] xen: arm: fix build of hvm.c
> 
> Add include of xsm/xsm.h to fix:
> 
> hvm.c: In function 'do_hvm_op': hvm.c:37:9: error: implicit declaration of function 'xsm_hvm_param' [-Werror=implicit-function-declaration]
> hvm.c:37:9: error: nested extern declaration of 'xsm_hvm_param' [-Werror=nested-externs]
> hvm.c:37:28: error: 'XSM_TARGET' undeclared (first use in this function)
> hvm.c:37:28: note: each undeclared identifier is reported only once for each function it appears in
> cc1: all warnings being treated as errors
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
> Cc: Tim Deegan <tim@xen.org>
> ---
>  xen/arch/arm/hvm.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
> index 63ac793..471c4cd 100644
> --- a/xen/arch/arm/hvm.c
> +++ b/xen/arch/arm/hvm.c
> @@ -5,6 +5,8 @@
>  #include <xen/guest_access.h>
>  #include <xen/sched.h>
>  
> +#include <xsm/xsm.h>
> +
>  #include <public/xen.h>
>  #include <public/hvm/params.h>
>  #include <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 Tue Feb 05 11:09:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:09: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 1U2gPB-0001i9-78; Tue, 05 Feb 2013 11:09:37 +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 1U2gP9-0001hm-Qa
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:09:36 +0000
Received: from [85.158.137.99:25058] by server-16.bemta-3.messagelabs.com id
	CA/85-02727-E68E0115; Tue, 05 Feb 2013 11:09:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360062574!19179175!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13992 invoked from network); 5 Feb 2013 11:09:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:09: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.297.1; Tue, 5 Feb 2013
	11:09:33 +0000
Message-ID: <1360062572.17017.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:09:32 +0000
In-Reply-To: <5110E641.9090902@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-3-git-send-email-roger.pau@citrix.com>
	<CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
	<1360060895.17017.27.camel@zakaz.uk.xensource.com>
	<5110E641.9090902@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xl: allow specifying a default netdev
 in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:00 +0000, Roger Pau Monne wrote:
> On 05/02/13 11:41, Ian Campbell wrote:
> > On Mon, 2013-01-28 at 11:00 +0000, George Dunlap wrote:
> >> On Fri, Jan 25, 2013 at 3:26 PM, Roger Pau Monne
> >> <roger.pau@citrix.com> wrote:
> >>         This adds a new global option in the xl configuration file
> >>         called
> >>         "defaultnetdev", that is used to specify the default netdev to
> >>         use
> >>         when none is passed in the vif specification.
> >>
> >>
> >> I'm not a fan of the name, though; it doesn't seem very scalable.  It
> >> looks like we already have "defaultbridge', so I can see this is just
> >> following precedent, but I wonder if it might be worth putting some
> >> more thought into it before proceeding?
> >>
> >>
> >> It seems like if we're going to have a default sub-option, it should
> >> at least have the name of the option in which it resides.
> >> "vif_netdev_default" or "default_vif_netdev" seem like better option.
> >> Or maybe "vif.netdev.default"? "defaults.vif.netdev"?
> > 
> > netdev is also a bit non-descriptive, even if it is what the vif-route
> > script uses perhaps we present something more meaningful to the user?
> > 
> > "gatewaydev" or something along those lines perhaps?
> 
> Will this also imply that xl should use gatewaydev instead of netdev in
> the vif config line? Right now we don't support netdev, but I guess we
> should add it for backwards compatibility.

netdev is the xend name too? I didn't realise that.

I guess we could accept netdev as a deprecated alias.

> 
> > I'd be inclined to use whatever name we decide here in the libxl
> > API/internals as well and just go netdev at the hotplug script
> > interface.
> > 
> > Ian.
> > 
> > 
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:09:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:09: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 1U2gPB-0001i9-78; Tue, 05 Feb 2013 11:09:37 +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 1U2gP9-0001hm-Qa
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:09:36 +0000
Received: from [85.158.137.99:25058] by server-16.bemta-3.messagelabs.com id
	CA/85-02727-E68E0115; Tue, 05 Feb 2013 11:09:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360062574!19179175!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13992 invoked from network); 5 Feb 2013 11:09:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:09: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.297.1; Tue, 5 Feb 2013
	11:09:33 +0000
Message-ID: <1360062572.17017.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:09:32 +0000
In-Reply-To: <5110E641.9090902@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-3-git-send-email-roger.pau@citrix.com>
	<CAFLBxZa2d-iq5cFn+aBqmQG3-GNE9MrwuXE3zEcU3Rvtas0M=w@mail.gmail.com>
	<1360060895.17017.27.camel@zakaz.uk.xensource.com>
	<5110E641.9090902@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xl: allow specifying a default netdev
 in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:00 +0000, Roger Pau Monne wrote:
> On 05/02/13 11:41, Ian Campbell wrote:
> > On Mon, 2013-01-28 at 11:00 +0000, George Dunlap wrote:
> >> On Fri, Jan 25, 2013 at 3:26 PM, Roger Pau Monne
> >> <roger.pau@citrix.com> wrote:
> >>         This adds a new global option in the xl configuration file
> >>         called
> >>         "defaultnetdev", that is used to specify the default netdev to
> >>         use
> >>         when none is passed in the vif specification.
> >>
> >>
> >> I'm not a fan of the name, though; it doesn't seem very scalable.  It
> >> looks like we already have "defaultbridge', so I can see this is just
> >> following precedent, but I wonder if it might be worth putting some
> >> more thought into it before proceeding?
> >>
> >>
> >> It seems like if we're going to have a default sub-option, it should
> >> at least have the name of the option in which it resides.
> >> "vif_netdev_default" or "default_vif_netdev" seem like better option.
> >> Or maybe "vif.netdev.default"? "defaults.vif.netdev"?
> > 
> > netdev is also a bit non-descriptive, even if it is what the vif-route
> > script uses perhaps we present something more meaningful to the user?
> > 
> > "gatewaydev" or something along those lines perhaps?
> 
> Will this also imply that xl should use gatewaydev instead of netdev in
> the vif config line? Right now we don't support netdev, but I guess we
> should add it for backwards compatibility.

netdev is the xend name too? I didn't realise that.

I guess we could accept netdev as a deprecated alias.

> 
> > I'd be inclined to use whatever name we decide here in the libxl
> > API/internals as well and just go netdev at the hotplug script
> > interface.
> > 
> > Ian.
> > 
> > 
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:11:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gR8-0001xc-QZ; Tue, 05 Feb 2013 11:11: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 1U2gR8-0001xP-DM
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:11:38 +0000
Received: from [85.158.137.99:55162] by server-8.bemta-3.messagelabs.com id
	E3/F4-25687-9E8E0115; Tue, 05 Feb 2013 11:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360062661!18981970!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31333 invoked from network); 5 Feb 2013 11:11:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:11:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:11: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.297.1; Tue, 5 Feb 2013
	11:11:01 +0000
Message-ID: <1360062659.17017.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:10:59 +0000
In-Reply-To: <5110E563.8030604@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
	<5110E563.8030604@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
 specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 10:56 +0000, Roger Pau Monne wrote:
> >> @@ -98,6 +103,8 @@ static char **get_hotplug_env(libxl__gc *gc,
> >>      env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
> >>      env[nr++] = "XENBUS_BASE_PATH";
> >>      env[nr++] = "backend";
> >> +    env[nr++] = "netdev";
> >> +    env[nr++] = netdev;
> > 
> > Mightn't this be NULL?
> 
> Yes, if we are using the vif-bridge script this will be NULL, but I
> prefer adding this NULL here rather than having a conditional and a
> variable array size (because we also have an assert(nr == arraysize) at
> the end of the code block).

Doesn't NULL terminate the env list? That might work right now while
this option is last but it will confuse the hell out of whoever adds the
next variable...

env[nr++] = netdev ? : "" might suffice?

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:11:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gR8-0001xc-QZ; Tue, 05 Feb 2013 11:11: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 1U2gR8-0001xP-DM
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:11:38 +0000
Received: from [85.158.137.99:55162] by server-8.bemta-3.messagelabs.com id
	E3/F4-25687-9E8E0115; Tue, 05 Feb 2013 11:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360062661!18981970!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31333 invoked from network); 5 Feb 2013 11:11:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:11:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1150738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:11: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.297.1; Tue, 5 Feb 2013
	11:11:01 +0000
Message-ID: <1360062659.17017.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:10:59 +0000
In-Reply-To: <5110E563.8030604@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
	<5110E563.8030604@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
 specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 10:56 +0000, Roger Pau Monne wrote:
> >> @@ -98,6 +103,8 @@ static char **get_hotplug_env(libxl__gc *gc,
> >>      env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
> >>      env[nr++] = "XENBUS_BASE_PATH";
> >>      env[nr++] = "backend";
> >> +    env[nr++] = "netdev";
> >> +    env[nr++] = netdev;
> > 
> > Mightn't this be NULL?
> 
> Yes, if we are using the vif-bridge script this will be NULL, but I
> prefer adding this NULL here rather than having a conditional and a
> variable array size (because we also have an assert(nr == arraysize) at
> the end of the code block).

Doesn't NULL terminate the env list? That might work right now while
this option is last but it will confuse the hell out of whoever adds the
next variable...

env[nr++] = netdev ? : "" might suffice?

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:18:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gXm-0002Hn-Re; Tue, 05 Feb 2013 11:18:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2gXl-0002Hi-5n
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:18:29 +0000
Received: from [85.158.138.51:37005] by server-16.bemta-3.messagelabs.com id
	D1/EB-02727-48AE0115; Tue, 05 Feb 2013 11:18:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360063106!12329167!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23370 invoked from network); 5 Feb 2013 11:18:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:18:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="5986554"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:18:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:18:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2gXh-0000pf-6K;
	Tue, 05 Feb 2013 11:18:25 +0000
Message-ID: <1360063105.7477.134.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 5 Feb 2013 11:18:25 +0000
In-Reply-To: <5110C40E02000078000BBD10@nat28.tlf.novell.com>
References: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
	<CD35A54A.59FE4%keir@xen.org>
	<5110C40E02000078000BBD10@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 07:34 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 18:50, Keir Fraser <keir@xen.org> wrote:
> > On 04/02/2013 16:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> this, originally having been at a fixed location outside of Xen virtual
> >> address ranges, has seen a number of changes over the years, with
> >> the net effect that right now we're requiring an order-1 allocation
> >> from the Xen heap. Obviously it would be much better if this got
> >> populated with order-0 allocations from the domain heap.
> >> 
> >> Considering that there's going to be one such area per vCPU (less
> >> those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
> >> seems undesirable to me to use vmap() for this purpose.
> >> 
> >> Instead I wonder whether we shouldn't go back to putting this at
> >> a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
> >> the virtual address range pressure (compared to the vmap()
> >> approach as well as for the case that these areas might need
> >> extending). Was there any other reason that you moved them out
> >> of such a fixed area than wanting to use mostly the same code
> >> for PV and HVM (which ought to be possible now that there's a
> >> base pointer stored for each vCPU)?
> > 
> > The original reason was so that we only needed to allocate memory for the
> > xlat_area per physical cpu.
> > 
> > Because of allowing sleeping in a hypercall (via a waitqueue) we can no
> > longer do that anyway, so we are back to allocating an xlat_area for every
> > vcpu. And we could as well map that at a fixed virtual address I suppose.
> > 
> > Do we care about vmap() pressure though? Is there a downside to making the
> > vmap area as big as we like? I mean even the existing 16GB area is good for
> > a million vcpus or so ;)
> 
> My original intention was for vmap() to be used for the planned
> for per-vCPU stacks (alongside any ioremap() users of course,
> of which we - fortunately - shouldn't have too many). So my
> concern was really more with regard to other possible users
> showing up; the use case here certainly doesn't represent a
> limiting factor on it own.
> 
> Making the range arbitrarily large of course isn't an option;
> raising it up to, say, about 100G wouldn't be problem though
> (slightly depending on whether we also need to grow the
> global domain page map area - of course that implementation
> could also be switched to build upon vmap()).
> 
> I guess I'll go with that approach then; likely the 3-level event
> channel implementation (Wei - hint, hint) also ought to use this
> to simplify the code there.
> 

Aha, thanks for the hint. ;-)


Wei.

> Jan
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:18:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gXm-0002Hn-Re; Tue, 05 Feb 2013 11:18:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2gXl-0002Hi-5n
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:18:29 +0000
Received: from [85.158.138.51:37005] by server-16.bemta-3.messagelabs.com id
	D1/EB-02727-48AE0115; Tue, 05 Feb 2013 11:18:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360063106!12329167!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23370 invoked from network); 5 Feb 2013 11:18:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:18:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="5986554"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:18:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:18:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2gXh-0000pf-6K;
	Tue, 05 Feb 2013 11:18:25 +0000
Message-ID: <1360063105.7477.134.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 5 Feb 2013 11:18:25 +0000
In-Reply-To: <5110C40E02000078000BBD10@nat28.tlf.novell.com>
References: <510FF4CD02000078000BBA11@nat28.tlf.novell.com>
	<CD35A54A.59FE4%keir@xen.org>
	<5110C40E02000078000BBD10@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] compat mode argument translation area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 07:34 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 18:50, Keir Fraser <keir@xen.org> wrote:
> > On 04/02/2013 16:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> this, originally having been at a fixed location outside of Xen virtual
> >> address ranges, has seen a number of changes over the years, with
> >> the net effect that right now we're requiring an order-1 allocation
> >> from the Xen heap. Obviously it would be much better if this got
> >> populated with order-0 allocations from the domain heap.
> >> 
> >> Considering that there's going to be one such area per vCPU (less
> >> those vCPU-s that don't need translation, i.e. 64-bit PV ones), it
> >> seems undesirable to me to use vmap() for this purpose.
> >> 
> >> Instead I wonder whether we shouldn't go back to putting this at
> >> a fixed address (5Gb or 8Gb) at least for PV guests, thus reducing
> >> the virtual address range pressure (compared to the vmap()
> >> approach as well as for the case that these areas might need
> >> extending). Was there any other reason that you moved them out
> >> of such a fixed area than wanting to use mostly the same code
> >> for PV and HVM (which ought to be possible now that there's a
> >> base pointer stored for each vCPU)?
> > 
> > The original reason was so that we only needed to allocate memory for the
> > xlat_area per physical cpu.
> > 
> > Because of allowing sleeping in a hypercall (via a waitqueue) we can no
> > longer do that anyway, so we are back to allocating an xlat_area for every
> > vcpu. And we could as well map that at a fixed virtual address I suppose.
> > 
> > Do we care about vmap() pressure though? Is there a downside to making the
> > vmap area as big as we like? I mean even the existing 16GB area is good for
> > a million vcpus or so ;)
> 
> My original intention was for vmap() to be used for the planned
> for per-vCPU stacks (alongside any ioremap() users of course,
> of which we - fortunately - shouldn't have too many). So my
> concern was really more with regard to other possible users
> showing up; the use case here certainly doesn't represent a
> limiting factor on it own.
> 
> Making the range arbitrarily large of course isn't an option;
> raising it up to, say, about 100G wouldn't be problem though
> (slightly depending on whether we also need to grow the
> global domain page map area - of course that implementation
> could also be switched to build upon vmap()).
> 
> I guess I'll go with that approach then; likely the 3-level event
> channel implementation (Wei - hint, hint) also ought to use this
> to simplify the code there.
> 

Aha, thanks for the hint. ;-)


Wei.

> Jan
> 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:27:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gfx-0002Vo-Se; Tue, 05 Feb 2013 11:26: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 1U2gfw-0002Vi-D1
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:26:56 +0000
Received: from [85.158.143.99:25895] by server-3.bemta-4.messagelabs.com id
	17/14-08920-E7CE0115; Tue, 05 Feb 2013 11:26:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360063612!24963373!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17782 invoked from network); 5 Feb 2013 11:26:54 -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;
	5 Feb 2013 11:26:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6296707"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:26:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:26:52 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1U2gfs-0000zD-1u;
	Tue, 05 Feb 2013 11:26:52 +0000
Message-ID: <5110EC7B.1060804@citrix.com>
Date: Tue, 5 Feb 2013 11:26:51 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
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 4/4] xen: arm: create dom0 DTB /hypervisor/
	node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/13 14:26, Ian Campbell wrote:
> I initially added hypervisor-new and confirmed via /proc/device-model
> that the content is the same before changing it to drop and replace
> an existing node.
> 
> NB: There is an ambiguity in the compatibility property.
> linux/arch/arm/boot/dts/xenvm-4.2.dts says "xen,xen-4.2" while
> Documentation/devicetree/bindings/arm/xen.txt says "xen,xen-4.3". I
> don't know which is correct but I've erred on the side of the DTS.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   53 +++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bb10096..d3ef180 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -34,7 +34,7 @@ custom_param("dom0_mem", parse_dom0_mem);
>   * are added (yet) but one terminating reserve map entry (16 bytes) is
>   * added.
>   */
> -#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
> +#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>  
>  struct vcpu *__init alloc_dom0_vcpu0(void)
>  {
> @@ -186,6 +186,13 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
>              break;
>  
> +        /* Skip /hypervisor/ node. We will inject our own. */
> +        if ( fdt_node_check_compatible(fdt, node, "xen,xen" ) == 0 )
> +        {
> +            printk("Device-tree contains \"xen,xen\" node. Ignoring.\n");
> +            continue;
> +        }
> +
>          /* Skip multiboot subnodes */
>          if ( fdt_node_check_compatible(fdt, node,
>                                         "xen,multiboot-module" ) == 0 )
> @@ -199,6 +206,45 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>      return node;
>  }
>  
> +static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
> +{
> +    const char compat[] = "xen,xen-4.2\0xen,xen";
> +    u32 reg[4];
> +    u32 intr[3];
> +    u32 *cell;
> +
> +    /*
> +     * Sanity-check address sizes, since addresses and sizes which do not take
> +     * up exactly 4 or 8 bytes are not supported.
> +     */
> +    if ((addrcells != 1 && addrcells != 2) ||
> +        (sizecells != 1 && sizecells != 2))
> +        panic("Cannot cope with this size");

You could add those two properties in the hypervisor node if they don't
match what we expect them to be. This would avoid panicking with a
device tree that have different default values.

-- 
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 Feb 05 11:27:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gfx-0002Vo-Se; Tue, 05 Feb 2013 11:26: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 1U2gfw-0002Vi-D1
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:26:56 +0000
Received: from [85.158.143.99:25895] by server-3.bemta-4.messagelabs.com id
	17/14-08920-E7CE0115; Tue, 05 Feb 2013 11:26:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360063612!24963373!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17782 invoked from network); 5 Feb 2013 11:26:54 -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;
	5 Feb 2013 11:26:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6296707"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:26:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:26:52 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1U2gfs-0000zD-1u;
	Tue, 05 Feb 2013 11:26:52 +0000
Message-ID: <5110EC7B.1060804@citrix.com>
Date: Tue, 5 Feb 2013 11:26:51 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
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 4/4] xen: arm: create dom0 DTB /hypervisor/
	node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/01/13 14:26, Ian Campbell wrote:
> I initially added hypervisor-new and confirmed via /proc/device-model
> that the content is the same before changing it to drop and replace
> an existing node.
> 
> NB: There is an ambiguity in the compatibility property.
> linux/arch/arm/boot/dts/xenvm-4.2.dts says "xen,xen-4.2" while
> Documentation/devicetree/bindings/arm/xen.txt says "xen,xen-4.3". I
> don't know which is correct but I've erred on the side of the DTS.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   53 +++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bb10096..d3ef180 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -34,7 +34,7 @@ custom_param("dom0_mem", parse_dom0_mem);
>   * are added (yet) but one terminating reserve map entry (16 bytes) is
>   * added.
>   */
> -#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
> +#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>  
>  struct vcpu *__init alloc_dom0_vcpu0(void)
>  {
> @@ -186,6 +186,13 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
>              break;
>  
> +        /* Skip /hypervisor/ node. We will inject our own. */
> +        if ( fdt_node_check_compatible(fdt, node, "xen,xen" ) == 0 )
> +        {
> +            printk("Device-tree contains \"xen,xen\" node. Ignoring.\n");
> +            continue;
> +        }
> +
>          /* Skip multiboot subnodes */
>          if ( fdt_node_check_compatible(fdt, node,
>                                         "xen,multiboot-module" ) == 0 )
> @@ -199,6 +206,45 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>      return node;
>  }
>  
> +static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
> +{
> +    const char compat[] = "xen,xen-4.2\0xen,xen";
> +    u32 reg[4];
> +    u32 intr[3];
> +    u32 *cell;
> +
> +    /*
> +     * Sanity-check address sizes, since addresses and sizes which do not take
> +     * up exactly 4 or 8 bytes are not supported.
> +     */
> +    if ((addrcells != 1 && addrcells != 2) ||
> +        (sizecells != 1 && sizecells != 2))
> +        panic("Cannot cope with this size");

You could add those two properties in the hypervisor node if they don't
match what we expect them to be. This would avoid panicking with a
device tree that have different default values.

-- 
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 Feb 05 11:31:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gjl-0002d4-J0; Tue, 05 Feb 2013 11:30:53 +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 1U2gjj-0002cz-RI
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:30:52 +0000
Received: from [85.158.139.211:5808] by server-2.bemta-5.messagelabs.com id
	33/44-16911-B6DE0115; Tue, 05 Feb 2013 11:30:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360063850!20043222!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4237 invoked from network); 5 Feb 2013 11:30:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:30:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:30: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.297.1; Tue, 5 Feb 2013
	11:30:50 +0000
Message-ID: <1360063848.17017.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 5 Feb 2013 11:30:48 +0000
In-Reply-To: <5110EC7B.1060804@citrix.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
	<5110EC7B.1060804@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
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 4/4] xen: arm: create dom0 DTB /hypervisor/
 node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:26 +0000, Anthony PERARD wrote:
> > +static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
> > +{
> > +    const char compat[] = "xen,xen-4.2\0xen,xen";
> > +    u32 reg[4];
> > +    u32 intr[3];
> > +    u32 *cell;
> > +
> > +    /*
> > +     * Sanity-check address sizes, since addresses and sizes which do not take
> > +     * up exactly 4 or 8 bytes are not supported.
> > +     */
> > +    if ((addrcells != 1 && addrcells != 2) ||
> > +        (sizecells != 1 && sizecells != 2))
> > +        panic("Cannot cope with this size");
> 
> You could add those two properties in the hypervisor node if they don't
> match what we expect them to be. This would avoid panicking with a
> device tree that have different default values.

Yes, I suppose that ought to work.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:31:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gjl-0002d4-J0; Tue, 05 Feb 2013 11:30:53 +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 1U2gjj-0002cz-RI
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:30:52 +0000
Received: from [85.158.139.211:5808] by server-2.bemta-5.messagelabs.com id
	33/44-16911-B6DE0115; Tue, 05 Feb 2013 11:30:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360063850!20043222!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4237 invoked from network); 5 Feb 2013 11:30:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:30:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:30: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.297.1; Tue, 5 Feb 2013
	11:30:50 +0000
Message-ID: <1360063848.17017.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 5 Feb 2013 11:30:48 +0000
In-Reply-To: <5110EC7B.1060804@citrix.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
	<5110EC7B.1060804@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
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 4/4] xen: arm: create dom0 DTB /hypervisor/
 node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:26 +0000, Anthony PERARD wrote:
> > +static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
> > +{
> > +    const char compat[] = "xen,xen-4.2\0xen,xen";
> > +    u32 reg[4];
> > +    u32 intr[3];
> > +    u32 *cell;
> > +
> > +    /*
> > +     * Sanity-check address sizes, since addresses and sizes which do not take
> > +     * up exactly 4 or 8 bytes are not supported.
> > +     */
> > +    if ((addrcells != 1 && addrcells != 2) ||
> > +        (sizecells != 1 && sizecells != 2))
> > +        panic("Cannot cope with this size");
> 
> You could add those two properties in the hypervisor node if they don't
> match what we expect them to be. This would avoid panicking with a
> device tree that have different default values.

Yes, I suppose that ought to work.

Ian.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:33:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:33: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 1U2glu-0002o0-7W; Tue, 05 Feb 2013 11:33: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 1U2glt-0002nv-Fi
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:33:05 +0000
Received: from [85.158.143.99:36279] by server-3.bemta-4.messagelabs.com id
	32/0E-08920-0FDE0115; Tue, 05 Feb 2013 11:33:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360063982!22179671!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19534 invoked from network); 5 Feb 2013 11:33:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:33:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6297122"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:32:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:32:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U2gkr-000151-Kl;
	Tue, 05 Feb 2013 11:32:01 +0000
Date: Tue, 5 Feb 2013 11:31:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360061994.17017.35.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302051131430.4275@kaball.uk.xensource.com>
References: <1358448953-2892-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1358448953-2892-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1358500751.13856.108.camel@zakaz.uk.xensource.com>
	<1359623804.12252.257.camel@zakaz.uk.xensource.com>
	<1360061994.17017.35.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	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 3/3] xen/arch/arm: add XSM hook to
 HVMOP_{get, set}_param
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 5 Feb 2013, Ian Campbell wrote:
> Stefano, Tim, can you (n)ack this please.

The patch seems simple enough.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> On Thu, 2013-01-31 at 09:16 +0000, Ian Campbell wrote:
> > 8<--------------------------------
> > 
> > From f2ec1f2cba7eab8d6c6c93378625379abe0e29bc Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Thu, 31 Jan 2013 09:14:40 +0000
> > Subject: [PATCH] xen: arm: fix build of hvm.c
> > 
> > Add include of xsm/xsm.h to fix:
> > 
> > hvm.c: In function 'do_hvm_op': hvm.c:37:9: error: implicit declaration of function 'xsm_hvm_param' [-Werror=implicit-function-declaration]
> > hvm.c:37:9: error: nested extern declaration of 'xsm_hvm_param' [-Werror=nested-externs]
> > hvm.c:37:28: error: 'XSM_TARGET' undeclared (first use in this function)
> > hvm.c:37:28: note: each undeclared identifier is reported only once for each function it appears in
> > cc1: all warnings being treated as errors
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
> > Cc: Tim Deegan <tim@xen.org>
> > ---
> >  xen/arch/arm/hvm.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
> > index 63ac793..471c4cd 100644
> > --- a/xen/arch/arm/hvm.c
> > +++ b/xen/arch/arm/hvm.c
> > @@ -5,6 +5,8 @@
> >  #include <xen/guest_access.h>
> >  #include <xen/sched.h>
> >  
> > +#include <xsm/xsm.h>
> > +
> >  #include <public/xen.h>
> >  #include <public/hvm/params.h>
> >  #include <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 Tue Feb 05 11:33:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:33: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 1U2glu-0002o0-7W; Tue, 05 Feb 2013 11:33: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 1U2glt-0002nv-Fi
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:33:05 +0000
Received: from [85.158.143.99:36279] by server-3.bemta-4.messagelabs.com id
	32/0E-08920-0FDE0115; Tue, 05 Feb 2013 11:33:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360063982!22179671!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19534 invoked from network); 5 Feb 2013 11:33:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:33:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6297122"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:32:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:32:02 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U2gkr-000151-Kl;
	Tue, 05 Feb 2013 11:32:01 +0000
Date: Tue, 5 Feb 2013 11:31:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360061994.17017.35.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302051131430.4275@kaball.uk.xensource.com>
References: <1358448953-2892-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1358448953-2892-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1358500751.13856.108.camel@zakaz.uk.xensource.com>
	<1359623804.12252.257.camel@zakaz.uk.xensource.com>
	<1360061994.17017.35.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	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 3/3] xen/arch/arm: add XSM hook to
 HVMOP_{get, set}_param
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 5 Feb 2013, Ian Campbell wrote:
> Stefano, Tim, can you (n)ack this please.

The patch seems simple enough.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> On Thu, 2013-01-31 at 09:16 +0000, Ian Campbell wrote:
> > 8<--------------------------------
> > 
> > From f2ec1f2cba7eab8d6c6c93378625379abe0e29bc Mon Sep 17 00:00:00 2001
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Thu, 31 Jan 2013 09:14:40 +0000
> > Subject: [PATCH] xen: arm: fix build of hvm.c
> > 
> > Add include of xsm/xsm.h to fix:
> > 
> > hvm.c: In function 'do_hvm_op': hvm.c:37:9: error: implicit declaration of function 'xsm_hvm_param' [-Werror=implicit-function-declaration]
> > hvm.c:37:9: error: nested extern declaration of 'xsm_hvm_param' [-Werror=nested-externs]
> > hvm.c:37:28: error: 'XSM_TARGET' undeclared (first use in this function)
> > hvm.c:37:28: note: each undeclared identifier is reported only once for each function it appears in
> > cc1: all warnings being treated as errors
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
> > Cc: Tim Deegan <tim@xen.org>
> > ---
> >  xen/arch/arm/hvm.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
> > index 63ac793..471c4cd 100644
> > --- a/xen/arch/arm/hvm.c
> > +++ b/xen/arch/arm/hvm.c
> > @@ -5,6 +5,8 @@
> >  #include <xen/guest_access.h>
> >  #include <xen/sched.h>
> >  
> > +#include <xsm/xsm.h>
> > +
> >  #include <public/xen.h>
> >  #include <public/hvm/params.h>
> >  #include <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 Tue Feb 05 11:33:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gm9-0002qY-8y; Tue, 05 Feb 2013 11:33:21 +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 1U2gm7-0002pn-Ch
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 11:33:19 +0000
Received: from [193.109.254.147:36312] by server-4.bemta-14.messagelabs.com id
	FD/2A-20719-EFDE0115; Tue, 05 Feb 2013 11:33:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360063837!1232689!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25937 invoked from network); 5 Feb 2013 11:30:39 -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;
	5 Feb 2013 11:30:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6297043"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:30:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:30:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U2gjU-00013O-IK;
	Tue, 05 Feb 2013 11:30:36 +0000
Date: Tue, 5 Feb 2013 11:30:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360060432.17017.22.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302051126590.4275@kaball.uk.xensource.com>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
 support for upstream-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

On Tue, 5 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
> > tools/libxl: Add qxl vga interface support for
> >   upstream-qemu-xen.
> > 
> > Usage:
> >    qxl=1|0
> > 
> > Changes from v7:
> > - Fix videoram settings parameters for qemu.
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> > Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> 
> Unfortunately this patch is whitespace damaged in various places.

BTW you can find a simple doc here that explains how to send patches to
mailing lists:

http://www.kernel.org/doc/Documentation/SubmittingPatches

the first part is a bit out-of-date: nowadays you would use "hg diff" or
"git diff" to generate your patches.

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:33:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2gm9-0002qY-8y; Tue, 05 Feb 2013 11:33:21 +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 1U2gm7-0002pn-Ch
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 11:33:19 +0000
Received: from [193.109.254.147:36312] by server-4.bemta-14.messagelabs.com id
	FD/2A-20719-EFDE0115; Tue, 05 Feb 2013 11:33:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360063837!1232689!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25937 invoked from network); 5 Feb 2013 11:30:39 -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;
	5 Feb 2013 11:30:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6297043"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 11:30:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 06:30:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U2gjU-00013O-IK;
	Tue, 05 Feb 2013 11:30:36 +0000
Date: Tue, 5 Feb 2013 11:30:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360060432.17017.22.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302051126590.4275@kaball.uk.xensource.com>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
 support for upstream-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

On Tue, 5 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
> > tools/libxl: Add qxl vga interface support for
> >   upstream-qemu-xen.
> > 
> > Usage:
> >    qxl=1|0
> > 
> > Changes from v7:
> > - Fix videoram settings parameters for qemu.
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> > Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> 
> Unfortunately this patch is whitespace damaged in various places.

BTW you can find a simple doc here that explains how to send patches to
mailing lists:

http://www.kernel.org/doc/Documentation/SubmittingPatches

the first part is a bit out-of-date: nowadays you would use "hg diff" or
"git diff" to generate your patches.

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:35:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2gnn-00034m-Fr; Tue, 05 Feb 2013 11:35: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 1U2gnl-00034U-Ua
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:35:02 +0000
Received: from [85.158.139.83:53500] by server-6.bemta-5.messagelabs.com id
	BE/4A-01489-46EE0115; Tue, 05 Feb 2013 11:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360064098!26727379!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27438 invoked from network); 5 Feb 2013 11:35:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:35:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:34: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.297.1; Tue, 5 Feb 2013
	11:34:58 +0000
Message-ID: <1360064096.17017.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:34:56 +0000
In-Reply-To: <10d9f4caffa8986185b9.1359642536@probook.site>
References: <b5de88e7e5c8a30be26f.1359641068@probook.site>
	<10d9f4caffa8986185b9.1359642536@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] tools: update ocamlfind 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 Thu, 2013-01-31 at 14:28 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359642490 -3600
> # Node ID 10d9f4caffa8986185b9f8824bd5bf0bb41de660
> # Parent  6727070b4129cf852199b66b6a81042ee6966a98
> tools: update ocamlfind handling
> 
> configure checks just for ocamlc, but the tools in tools/ocaml depend
> also on ocamlfind. On my workstation I have just ocamlc installed, but
> no ocamlfind. As a result make will fail.
> 
> Update configure.ac to check also for OCAMLFIND, update various
> Makefiles and replace hardcoded ocamlfind string with $(OCAMLFIND)
> 
> Please rerun autogen.sh after applying this patch.
> 
> v2:
>  - fix logic error in configure.ac
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked + applied, thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:35:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2gnn-00034m-Fr; Tue, 05 Feb 2013 11:35: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 1U2gnl-00034U-Ua
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:35:02 +0000
Received: from [85.158.139.83:53500] by server-6.bemta-5.messagelabs.com id
	BE/4A-01489-46EE0115; Tue, 05 Feb 2013 11:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360064098!26727379!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27438 invoked from network); 5 Feb 2013 11:35:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:35:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:34: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.297.1; Tue, 5 Feb 2013
	11:34:58 +0000
Message-ID: <1360064096.17017.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:34:56 +0000
In-Reply-To: <10d9f4caffa8986185b9.1359642536@probook.site>
References: <b5de88e7e5c8a30be26f.1359641068@probook.site>
	<10d9f4caffa8986185b9.1359642536@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] tools: update ocamlfind 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 Thu, 2013-01-31 at 14:28 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359642490 -3600
> # Node ID 10d9f4caffa8986185b9f8824bd5bf0bb41de660
> # Parent  6727070b4129cf852199b66b6a81042ee6966a98
> tools: update ocamlfind handling
> 
> configure checks just for ocamlc, but the tools in tools/ocaml depend
> also on ocamlfind. On my workstation I have just ocamlc installed, but
> no ocamlfind. As a result make will fail.
> 
> Update configure.ac to check also for OCAMLFIND, update various
> Makefiles and replace hardcoded ocamlfind string with $(OCAMLFIND)
> 
> Please rerun autogen.sh after applying this patch.
> 
> v2:
>  - fix logic error in configure.ac
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked + applied, thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:35:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2gnn-00034d-16; Tue, 05 Feb 2013 11:35: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 1U2gnl-00034T-Kx
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:35:01 +0000
Received: from [85.158.139.83:51307] by server-14.bemta-5.messagelabs.com id
	DB/F7-06967-46EE0115; Tue, 05 Feb 2013 11:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360064098!26727379!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27321 invoked from network); 5 Feb 2013 11:34:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:34:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:34: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.297.1; Tue, 5 Feb 2013
	11:34:26 +0000
Message-ID: <1360064064.17017.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:34:24 +0000
In-Reply-To: <91fe6b42c7d4010ada78.1359645119@probook.site>
References: <91fe6b42c7d4010ada78.1359645119@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix xcflags assignment in
 libxl__domain_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 Thu, 2013-01-31 at 15:11 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359645080 -3600
> # Node ID 91fe6b42c7d4010ada78617d18133137d7194d9b
> # Parent  6727070b4129cf852199b66b6a81042ee6966a98
> libxl: fix xcflags assignment in libxl__domain_suspend
> 
> Currently ->xcflags remains 1 because the braces are placed incorrectly.
> Put each logical unit into its own braces to fix assigment to xcflags.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked + applied , thanks.

> 
> diff -r 6727070b4129 -r 91fe6b42c7d4 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1238,9 +1238,9 @@ void libxl__domain_suspend(libxl__egc *e
>          abort();
>      }
>  
> -    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
> -          | (debug) ? XCFLAGS_DEBUG : 0
> -          | (dss->hvm) ? XCFLAGS_HVM : 0;
> +    dss->xcflags = (live ? XCFLAGS_LIVE : 0)
> +          | (debug ? XCFLAGS_DEBUG : 0)
> +          | (dss->hvm ? XCFLAGS_HVM : 0);
>  
>      dss->suspend_eventchn = -1;
>      dss->guest_responded = 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 Feb 05 11:35:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2gnn-00034d-16; Tue, 05 Feb 2013 11:35: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 1U2gnl-00034T-Kx
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:35:01 +0000
Received: from [85.158.139.83:51307] by server-14.bemta-5.messagelabs.com id
	DB/F7-06967-46EE0115; Tue, 05 Feb 2013 11:35:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360064098!26727379!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27321 invoked from network); 5 Feb 2013 11:34:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:34:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:34: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.297.1; Tue, 5 Feb 2013
	11:34:26 +0000
Message-ID: <1360064064.17017.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 11:34:24 +0000
In-Reply-To: <91fe6b42c7d4010ada78.1359645119@probook.site>
References: <91fe6b42c7d4010ada78.1359645119@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix xcflags assignment in
 libxl__domain_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 Thu, 2013-01-31 at 15:11 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1359645080 -3600
> # Node ID 91fe6b42c7d4010ada78617d18133137d7194d9b
> # Parent  6727070b4129cf852199b66b6a81042ee6966a98
> libxl: fix xcflags assignment in libxl__domain_suspend
> 
> Currently ->xcflags remains 1 because the braces are placed incorrectly.
> Put each logical unit into its own braces to fix assigment to xcflags.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked + applied , thanks.

> 
> diff -r 6727070b4129 -r 91fe6b42c7d4 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1238,9 +1238,9 @@ void libxl__domain_suspend(libxl__egc *e
>          abort();
>      }
>  
> -    dss->xcflags = (live) ? XCFLAGS_LIVE : 0
> -          | (debug) ? XCFLAGS_DEBUG : 0
> -          | (dss->hvm) ? XCFLAGS_HVM : 0;
> +    dss->xcflags = (live ? XCFLAGS_LIVE : 0)
> +          | (debug ? XCFLAGS_DEBUG : 0)
> +          | (dss->hvm ? XCFLAGS_HVM : 0);
>  
>      dss->suspend_eventchn = -1;
>      dss->guest_responded = 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 Feb 05 11:35:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2go1-00037c-To; Tue, 05 Feb 2013 11:35: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 1U2go0-00036w-Gr
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:35:16 +0000
Received: from [85.158.139.211:26869] by server-15.bemta-5.messagelabs.com id
	FD/02-18914-37EE0115; Tue, 05 Feb 2013 11:35:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360064115!20750261!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 697 invoked from network); 5 Feb 2013 11:35:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:35:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:35: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.297.1; Tue, 5 Feb 2013
	11:35:14 +0000
Message-ID: <1360064113.17017.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 5 Feb 2013 11:35:13 +0000
In-Reply-To: <alpine.DEB.2.02.1301281846320.10432@kaball.uk.xensource.com>
References: <1359119447-20967-1-git-send-email-ian.campbell@citrix.com>
	<51028BA0.2020004@citrix.com>
	<1359130524.10051.92.camel@zakaz.uk.xensource.com>
	<1098084018.20130127224937@eikelenboom.it>
	<1359368738.6559.42.camel@zakaz.uk.xensource.com>
	<1027570226.20130128113931@eikelenboom.it>
	<1359370255.6559.59.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301281846320.10432@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xencommons: redirect serial and parallel to
	/dev/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 Mon, 2013-01-28 at 18:48 +0000, Stefano Stabellini wrote:
> Upstream QEMU doesn't support -nographic with -daemonize unless monitor,
> serial and parallel outputs are all redirected:
> 
> /* According to documentation and historically, -nographic redirects
>  * serial port, parallel port and monitor to stdio, which does not work
>  * with -daemonize.  We can redirect these to null instead, but since
>  * -nographic is legacy, let's just error out.
>  * We disallow -nographic only if all other ports are not redirected
>  * explicitly, to not break existing legacy setups which uses
>  * -nographic _and_ redirects all ports explicitly - this is valid
>  * usage, -nographic is just a no-op in this case.
>  */
> 
> Considering that we do want to redirect them to /dev/null anyway, do so.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

I think I asked you IRL if this would work with older QEMU too and IIRC
you said yes, so :
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied, I had to adjust because of 26352:9a1610c1e564 "xencommons: Stop
QEMU in do_stop()" and I rewrapped it since the line was getting a bit
ridiculous, let me know if I did it wrong...



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:35:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2go1-00037c-To; Tue, 05 Feb 2013 11:35: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 1U2go0-00036w-Gr
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:35:16 +0000
Received: from [85.158.139.211:26869] by server-15.bemta-5.messagelabs.com id
	FD/02-18914-37EE0115; Tue, 05 Feb 2013 11:35:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360064115!20750261!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 697 invoked from network); 5 Feb 2013 11:35:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:35:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:35: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.297.1; Tue, 5 Feb 2013
	11:35:14 +0000
Message-ID: <1360064113.17017.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 5 Feb 2013 11:35:13 +0000
In-Reply-To: <alpine.DEB.2.02.1301281846320.10432@kaball.uk.xensource.com>
References: <1359119447-20967-1-git-send-email-ian.campbell@citrix.com>
	<51028BA0.2020004@citrix.com>
	<1359130524.10051.92.camel@zakaz.uk.xensource.com>
	<1098084018.20130127224937@eikelenboom.it>
	<1359368738.6559.42.camel@zakaz.uk.xensource.com>
	<1027570226.20130128113931@eikelenboom.it>
	<1359370255.6559.59.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301281846320.10432@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xencommons: redirect serial and parallel to
	/dev/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 Mon, 2013-01-28 at 18:48 +0000, Stefano Stabellini wrote:
> Upstream QEMU doesn't support -nographic with -daemonize unless monitor,
> serial and parallel outputs are all redirected:
> 
> /* According to documentation and historically, -nographic redirects
>  * serial port, parallel port and monitor to stdio, which does not work
>  * with -daemonize.  We can redirect these to null instead, but since
>  * -nographic is legacy, let's just error out.
>  * We disallow -nographic only if all other ports are not redirected
>  * explicitly, to not break existing legacy setups which uses
>  * -nographic _and_ redirects all ports explicitly - this is valid
>  * usage, -nographic is just a no-op in this case.
>  */
> 
> Considering that we do want to redirect them to /dev/null anyway, do so.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

I think I asked you IRL if this would work with older QEMU too and IIRC
you said yes, so :
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Applied, I had to adjust because of 26352:9a1610c1e564 "xencommons: Stop
QEMU in do_stop()" and I rewrapped it since the line was getting a bit
ridiculous, let me know if I did it wrong...



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:35:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2goX-0003Ew-DW; Tue, 05 Feb 2013 11:35: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 1U2goV-0003EQ-PO
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 11:35:47 +0000
Received: from [193.109.254.147:6367] by server-10.bemta-14.messagelabs.com id
	7F/62-12679-29EE0115; Tue, 05 Feb 2013 11:35:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360064144!8615271!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4758 invoked from network); 5 Feb 2013 11:35:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:35:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:35: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.297.1; Tue, 5 Feb 2013
	11:35:44 +0000
Message-ID: <1360064143.17017.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 5 Feb 2013 11:35:43 +0000
In-Reply-To: <20130124174328.GO20551@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1301221300520.29727@kaball.uk.xensource.com>
	<1359048842.32057.34.camel@zakaz.uk.xensource.com>
	<20130124174328.GO20551@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 0/3] xen/arm: domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-24 at 17:43 +0000, Tim Deegan wrote:
> At 17:34 +0000 on 24 Jan (1359048842), Ian Campbell wrote:
> > On Tue, 2013-01-22 at 13:03 +0000, Stefano Stabellini wrote:
> > > Hi all,
> > > this patch series implements the few missing functions to successfully
> > > complete a domain destruction.
> > 
> > These all look ok to me.
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Me too.
> 
> Acked-by: Tim Deegan <tim@xen.org>

Applied. Thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:35:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:35: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 1U2goX-0003Ew-DW; Tue, 05 Feb 2013 11:35: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 1U2goV-0003EQ-PO
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 11:35:47 +0000
Received: from [193.109.254.147:6367] by server-10.bemta-14.messagelabs.com id
	7F/62-12679-29EE0115; Tue, 05 Feb 2013 11:35:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360064144!8615271!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4758 invoked from network); 5 Feb 2013 11:35:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:35:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1151924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:35: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.297.1; Tue, 5 Feb 2013
	11:35:44 +0000
Message-ID: <1360064143.17017.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 5 Feb 2013 11:35:43 +0000
In-Reply-To: <20130124174328.GO20551@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1301221300520.29727@kaball.uk.xensource.com>
	<1359048842.32057.34.camel@zakaz.uk.xensource.com>
	<20130124174328.GO20551@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 0/3] xen/arm: domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-24 at 17:43 +0000, Tim Deegan wrote:
> At 17:34 +0000 on 24 Jan (1359048842), Ian Campbell wrote:
> > On Tue, 2013-01-22 at 13:03 +0000, Stefano Stabellini wrote:
> > > Hi all,
> > > this patch series implements the few missing functions to successfully
> > > complete a domain destruction.
> > 
> > These all look ok to me.
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Me too.
> 
> Acked-by: Tim Deegan <tim@xen.org>

Applied. Thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:39:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2grW-0003gI-2a; Tue, 05 Feb 2013 11:38:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.phillips@citrix.com>) id 1U2grU-0003g1-1m
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:38:52 +0000
Received: from [193.109.254.147:64423] by server-16.bemta-14.messagelabs.com
	id 3C/58-25906-A4FE0115; Tue, 05 Feb 2013 11:38:50 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360064293!9278646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9595 invoked from network); 5 Feb 2013 11:38:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6297736"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:38:12 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Tue, 5 Feb 2013 06:38:12 -0500
From: Robert Phillips <robert.phillips@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Tue, 5 Feb 2013 06:38:09 -0500
Thread-Topic: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen
Thread-Index: Ac36JYjIv4cSnfJDRg6Io8fd+FAkHAJbs44Q
Message-ID: <048EAD622912254A9DEA24C1734613C18C8A4B8974@FTLPMAILBOX02.citrite.net>
References: <1358796510-2861-1-git-send-email-robert.phillips@citrix.com>
	<20130124112521.GB18850@ocelot.phlegethon.org>
In-Reply-To: <20130124112521.GB18850@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: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
 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

See below
-- rsp

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, January 24, 2013 6:25 AM
> To: Robert Phillips
> Cc: Jan Beulich; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
> in Xen
> 
> Hi,
> 
> At 14:28 -0500 on 21 Jan (1358778509), Robert Phillips wrote:
> > Support is provided for both shadow and hardware assisted paging (HAP)
> > modes. This code bookkeeps the set of video frame buffers (vram),
> > detects when the guest has modified any of those buffers and, upon
> > request, returns a bitmap of the modified pages.
> > This lets other software components re-paint the portions of the
> > monitor (or monitors) that have changed.
> > Each monitor has a frame buffer of some size at some position in guest
> > physical memory.
> > The set of frame buffers being tracked can change over time as
> > monitors are plugged and unplugged.
> 
> This doesn't apply to tip of xen-unstable.  Also:
> 
> > +        ext = __map_domain_page(pg);
> > +        /* Is unmapped in dirty_vram_free() */
> 
> Mappings from map_domain_page() can't be kept around like this.  They're
> supposed to be short-term, and in systems where we don't have a full 1-1
> map of memory (e.g. x86 once Jan's 16TB-support series goes in) there are a
> limited number of mapping slots.
> 
> Jan, what do you recommend here?  These are pages of linked-list entries,
> part of the p2m/mm overhead and so allocated from the guest's shadow
> memory.  Are we going to have to allocate them from xenheap instead or is
> there any way to avoid that?

One possible solution is to use a fixmap table. 
Rather than storing VAs in these tables, the code could store
entries containing physical_page/offset_in_page. 

 When managing the table
the code could remap PA/offset into a single fixed virtual address
(and clear its TLB).  Clearing a single TLB shouldn't hurt
performance too terribly, right?

(When I write "a single VA" I really mean "a small number of VAs".)

I do not know about fixmap tables, whether this is their
intended use and whether this solution would work.

> 
> Tim.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:39:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2grW-0003gI-2a; Tue, 05 Feb 2013 11:38:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.phillips@citrix.com>) id 1U2grU-0003g1-1m
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:38:52 +0000
Received: from [193.109.254.147:64423] by server-16.bemta-14.messagelabs.com
	id 3C/58-25906-A4FE0115; Tue, 05 Feb 2013 11:38:50 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360064293!9278646!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9595 invoked from network); 5 Feb 2013 11:38:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6297736"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:38:12 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Tue, 5 Feb 2013 06:38:12 -0500
From: Robert Phillips <robert.phillips@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Tue, 5 Feb 2013 06:38:09 -0500
Thread-Topic: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen
Thread-Index: Ac36JYjIv4cSnfJDRg6Io8fd+FAkHAJbs44Q
Message-ID: <048EAD622912254A9DEA24C1734613C18C8A4B8974@FTLPMAILBOX02.citrite.net>
References: <1358796510-2861-1-git-send-email-robert.phillips@citrix.com>
	<20130124112521.GB18850@ocelot.phlegethon.org>
In-Reply-To: <20130124112521.GB18850@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: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
 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

See below
-- rsp

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Thursday, January 24, 2013 6:25 AM
> To: Robert Phillips
> Cc: Jan Beulich; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
> in Xen
> 
> Hi,
> 
> At 14:28 -0500 on 21 Jan (1358778509), Robert Phillips wrote:
> > Support is provided for both shadow and hardware assisted paging (HAP)
> > modes. This code bookkeeps the set of video frame buffers (vram),
> > detects when the guest has modified any of those buffers and, upon
> > request, returns a bitmap of the modified pages.
> > This lets other software components re-paint the portions of the
> > monitor (or monitors) that have changed.
> > Each monitor has a frame buffer of some size at some position in guest
> > physical memory.
> > The set of frame buffers being tracked can change over time as
> > monitors are plugged and unplugged.
> 
> This doesn't apply to tip of xen-unstable.  Also:
> 
> > +        ext = __map_domain_page(pg);
> > +        /* Is unmapped in dirty_vram_free() */
> 
> Mappings from map_domain_page() can't be kept around like this.  They're
> supposed to be short-term, and in systems where we don't have a full 1-1
> map of memory (e.g. x86 once Jan's 16TB-support series goes in) there are a
> limited number of mapping slots.
> 
> Jan, what do you recommend here?  These are pages of linked-list entries,
> part of the p2m/mm overhead and so allocated from the guest's shadow
> memory.  Are we going to have to allocate them from xenheap instead or is
> there any way to avoid that?

One possible solution is to use a fixmap table. 
Rather than storing VAs in these tables, the code could store
entries containing physical_page/offset_in_page. 

 When managing the table
the code could remap PA/offset into a single fixed virtual address
(and clear its TLB).  Clearing a single TLB shouldn't hurt
performance too terribly, right?

(When I write "a single VA" I really mean "a small number of VAs".)

I do not know about fixmap tables, whether this is their
intended use and whether this solution would work.

> 
> Tim.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:39:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:39: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 1U2grt-0003jK-Gu; Tue, 05 Feb 2013 11:39:17 +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 1U2grr-0003j4-C1
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:39:15 +0000
Received: from [85.158.143.99:22927] by server-3.bemta-4.messagelabs.com id
	B8/67-08920-26FE0115; Tue, 05 Feb 2013 11:39:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360064354!30888891!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29584 invoked from network); 5 Feb 2013 11:39:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:39:15 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	11:39:13 +0000
Message-ID: <5110EF60.8010207@citrix.com>
Date: Tue, 5 Feb 2013 12:39:12 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
	<5110E563.8030604@citrix.com>
	<1360062659.17017.43.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360062659.17017.43.camel@zakaz.uk.xensource.com>
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
	specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 12:10, Ian Campbell wrote:
> On Tue, 2013-02-05 at 10:56 +0000, Roger Pau Monne wrote:
>>>> @@ -98,6 +103,8 @@ static char **get_hotplug_env(libxl__gc *gc,
>>>>      env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
>>>>      env[nr++] = "XENBUS_BASE_PATH";
>>>>      env[nr++] = "backend";
>>>> +    env[nr++] = "netdev";
>>>> +    env[nr++] = netdev;
>>>
>>> Mightn't this be NULL?
>>
>> Yes, if we are using the vif-bridge script this will be NULL, but I
>> prefer adding this NULL here rather than having a conditional and a
>> variable array size (because we also have an assert(nr == arraysize) at
>> the end of the code block).
> 
> Doesn't NULL terminate the env list? That might work right now while
> this option is last but it will confuse the hell out of whoever adds the
> next variable...

Indeed, good catch. Also we are enforcing this (not passing NULL values
in env variables) in libxl__exec.

> env[nr++] = netdev ? : "" might suffice?

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 Feb 05 11:39:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:39: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 1U2grt-0003jK-Gu; Tue, 05 Feb 2013 11:39:17 +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 1U2grr-0003j4-C1
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:39:15 +0000
Received: from [85.158.143.99:22927] by server-3.bemta-4.messagelabs.com id
	B8/67-08920-26FE0115; Tue, 05 Feb 2013 11:39:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360064354!30888891!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29584 invoked from network); 5 Feb 2013 11:39:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:39:15 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Tue, 5 Feb 2013
	11:39:13 +0000
Message-ID: <5110EF60.8010207@citrix.com>
Date: Tue, 5 Feb 2013 12:39:12 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
	<5110E563.8030604@citrix.com>
	<1360062659.17017.43.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360062659.17017.43.camel@zakaz.uk.xensource.com>
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
	specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 12:10, Ian Campbell wrote:
> On Tue, 2013-02-05 at 10:56 +0000, Roger Pau Monne wrote:
>>>> @@ -98,6 +103,8 @@ static char **get_hotplug_env(libxl__gc *gc,
>>>>      env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
>>>>      env[nr++] = "XENBUS_BASE_PATH";
>>>>      env[nr++] = "backend";
>>>> +    env[nr++] = "netdev";
>>>> +    env[nr++] = netdev;
>>>
>>> Mightn't this be NULL?
>>
>> Yes, if we are using the vif-bridge script this will be NULL, but I
>> prefer adding this NULL here rather than having a conditional and a
>> variable array size (because we also have an assert(nr == arraysize) at
>> the end of the code block).
> 
> Doesn't NULL terminate the env list? That might work right now while
> this option is last but it will confuse the hell out of whoever adds the
> next variable...

Indeed, good catch. Also we are enforcing this (not passing NULL values
in env variables) in libxl__exec.

> env[nr++] = netdev ? : "" might suffice?

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 Feb 05 11:41:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:41: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 1U2guF-0003yi-6O; Tue, 05 Feb 2013 11:41: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 1U2guE-0003yX-3b
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:41:42 +0000
Received: from [85.158.139.83:26713] by server-14.bemta-5.messagelabs.com id
	16/99-06967-5FFE0115; Tue, 05 Feb 2013 11:41:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360064472!30045147!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3670 invoked from network); 5 Feb 2013 11:41:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:41: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.297.1; Tue, 5 Feb 2013
	11:41:11 +0000
Message-ID: <1360064470.17017.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:41:10 +0000
In-Reply-To: <5110EF60.8010207@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
	<5110E563.8030604@citrix.com>
	<1360062659.17017.43.camel@zakaz.uk.xensource.com>
	<5110EF60.8010207@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
 specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:39 +0000, Roger Pau Monne wrote:
> On 05/02/13 12:10, Ian Campbell wrote:
> > On Tue, 2013-02-05 at 10:56 +0000, Roger Pau Monne wrote:
> >>>> @@ -98,6 +103,8 @@ static char **get_hotplug_env(libxl__gc *gc,
> >>>>      env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
> >>>>      env[nr++] = "XENBUS_BASE_PATH";
> >>>>      env[nr++] = "backend";
> >>>> +    env[nr++] = "netdev";
> >>>> +    env[nr++] = netdev;
> >>>
> >>> Mightn't this be NULL?
> >>
> >> Yes, if we are using the vif-bridge script this will be NULL, but I
> >> prefer adding this NULL here rather than having a conditional and a
> >> variable array size (because we also have an assert(nr == arraysize) at
> >> the end of the code block).
> > 
> > Doesn't NULL terminate the env list? That might work right now while
> > this option is last but it will confuse the hell out of whoever adds the
> > next variable...
> 
> Indeed, good catch. Also we are enforcing this (not passing NULL values
> in env variables) in libxl__exec.

No, finding a NULL env entry signals the end of the list:
    if (env != NULL) {
        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
            if (setenv(env[i], env[i+1], 1) < 0) {
                LOGEV(ERROR, errno, "setting env vars (%s = %s)",
                                    env[i], env[i+1]);
                goto out;
            }
        }
    }

I suppose we could treat env[i] != NULL  and env[i+1] == NULL specially
(e.g. ignore it and continue), but ick...

Ian 


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:41:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:41: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 1U2guF-0003yi-6O; Tue, 05 Feb 2013 11:41: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 1U2guE-0003yX-3b
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:41:42 +0000
Received: from [85.158.139.83:26713] by server-14.bemta-5.messagelabs.com id
	16/99-06967-5FFE0115; Tue, 05 Feb 2013 11:41:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360064472!30045147!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3670 invoked from network); 5 Feb 2013 11:41:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:41: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.297.1; Tue, 5 Feb 2013
	11:41:11 +0000
Message-ID: <1360064470.17017.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:41:10 +0000
In-Reply-To: <5110EF60.8010207@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
	<1359127583-32490-2-git-send-email-roger.pau@citrix.com>
	<1360060806.17017.25.camel@zakaz.uk.xensource.com>
	<5110E563.8030604@citrix.com>
	<1360062659.17017.43.camel@zakaz.uk.xensource.com>
	<5110EF60.8010207@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xl/libxl: add netdev to vif
 specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:39 +0000, Roger Pau Monne wrote:
> On 05/02/13 12:10, Ian Campbell wrote:
> > On Tue, 2013-02-05 at 10:56 +0000, Roger Pau Monne wrote:
> >>>> @@ -98,6 +103,8 @@ static char **get_hotplug_env(libxl__gc *gc,
> >>>>      env[nr++] = GCSPRINTF("backend/%s/%u/%d", type, dev->domid, dev->devid);
> >>>>      env[nr++] = "XENBUS_BASE_PATH";
> >>>>      env[nr++] = "backend";
> >>>> +    env[nr++] = "netdev";
> >>>> +    env[nr++] = netdev;
> >>>
> >>> Mightn't this be NULL?
> >>
> >> Yes, if we are using the vif-bridge script this will be NULL, but I
> >> prefer adding this NULL here rather than having a conditional and a
> >> variable array size (because we also have an assert(nr == arraysize) at
> >> the end of the code block).
> > 
> > Doesn't NULL terminate the env list? That might work right now while
> > this option is last but it will confuse the hell out of whoever adds the
> > next variable...
> 
> Indeed, good catch. Also we are enforcing this (not passing NULL values
> in env variables) in libxl__exec.

No, finding a NULL env entry signals the end of the list:
    if (env != NULL) {
        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
            if (setenv(env[i], env[i+1], 1) < 0) {
                LOGEV(ERROR, errno, "setting env vars (%s = %s)",
                                    env[i], env[i+1]);
                goto out;
            }
        }
    }

I suppose we could treat env[i] != NULL  and env[i+1] == NULL specially
(e.g. ignore it and continue), but ick...

Ian 


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:47:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:47: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 1U2gze-0004Hq-8I; Tue, 05 Feb 2013 11:47:18 +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 1U2gzc-0004Hi-0l
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:47:16 +0000
Received: from [85.158.138.51:20373] by server-7.bemta-3.messagelabs.com id
	FC/A4-10367-241F0115; Tue, 05 Feb 2013 11:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360064820!29284584!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17455 invoked from network); 5 Feb 2013 11:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:47: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.297.1; Tue, 5 Feb 2013
	11:47:00 +0000
Message-ID: <1360064819.17017.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 5 Feb 2013 11:46:59 +0000
In-Reply-To: <alpine.DEB.2.02.1302051131430.4275@kaball.uk.xensource.com>
References: <1358448953-2892-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1358448953-2892-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1358500751.13856.108.camel@zakaz.uk.xensource.com>
	<1359623804.12252.257.camel@zakaz.uk.xensource.com>
	<1360061994.17017.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302051131430.4275@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] xen/arch/arm: add XSM hook to
 HVMOP_{get, set}_param
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:31 +0000, Stefano Stabellini wrote:
> On Tue, 5 Feb 2013, Ian Campbell wrote:
> > Stefano, Tim, can you (n)ack this please.
> 
> The patch seems simple enough.
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:47:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11:47: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 1U2gze-0004Hq-8I; Tue, 05 Feb 2013 11:47:18 +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 1U2gzc-0004Hi-0l
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:47:16 +0000
Received: from [85.158.138.51:20373] by server-7.bemta-3.messagelabs.com id
	FC/A4-10367-241F0115; Tue, 05 Feb 2013 11:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360064820!29284584!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17455 invoked from network); 5 Feb 2013 11:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:47: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.297.1; Tue, 5 Feb 2013
	11:47:00 +0000
Message-ID: <1360064819.17017.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 5 Feb 2013 11:46:59 +0000
In-Reply-To: <alpine.DEB.2.02.1302051131430.4275@kaball.uk.xensource.com>
References: <1358448953-2892-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1358448953-2892-4-git-send-email-dgdegra@tycho.nsa.gov>
	<1358500751.13856.108.camel@zakaz.uk.xensource.com>
	<1359623804.12252.257.camel@zakaz.uk.xensource.com>
	<1360061994.17017.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302051131430.4275@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/3] xen/arch/arm: add XSM hook to
 HVMOP_{get, set}_param
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:31 +0000, Stefano Stabellini wrote:
> On Tue, 5 Feb 2013, Ian Campbell wrote:
> > Stefano, Tim, can you (n)ack this please.
> 
> The patch seems simple enough.
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:48:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2h0Y-0004LC-P3; Tue, 05 Feb 2013 11:48: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 1U2h0X-0004L2-R8
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:48:13 +0000
Received: from [85.158.138.51:33750] by server-7.bemta-3.messagelabs.com id
	8A/76-10367-D71F0115; Tue, 05 Feb 2013 11:48:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360064892!29270078!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14647 invoked from network); 5 Feb 2013 11:48:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:48: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.297.1; Tue, 5 Feb 2013
	11:48:12 +0000
Message-ID: <1360064890.17017.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:48:10 +0000
In-Reply-To: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] add vif-route support to libxl/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

On Fri, 2013-01-25 at 15:26 +0000, Roger Pau Monne wrote:
> Support for vif-route was missing in libxl, this patch series adds a 
> "netdev" vif option and also allows setting a default netdev in 
> xl.conf global configuration file.
> 
> vif-route doesn't support HVM domains because it doesn't support the 
> "add" or "remove" actions.

Should be easy to add?

> I would like to request some testing from people that actually use 
> this network mode.

Might be worth sending a Call-For-Testing to -users@ ?

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 11:48:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 11: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 1U2h0Y-0004LC-P3; Tue, 05 Feb 2013 11:48: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 1U2h0X-0004L2-R8
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 11:48:13 +0000
Received: from [85.158.138.51:33750] by server-7.bemta-3.messagelabs.com id
	8A/76-10367-D71F0115; Tue, 05 Feb 2013 11:48:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360064892!29270078!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14647 invoked from network); 5 Feb 2013 11:48:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 11:48:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1152465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 11:48: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.297.1; Tue, 5 Feb 2013
	11:48:12 +0000
Message-ID: <1360064890.17017.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue, 5 Feb 2013 11:48:10 +0000
In-Reply-To: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
References: <1359127583-32490-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] add vif-route support to libxl/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

On Fri, 2013-01-25 at 15:26 +0000, Roger Pau Monne wrote:
> Support for vif-route was missing in libxl, this patch series adds a 
> "netdev" vif option and also allows setting a default netdev in 
> xl.conf global configuration file.
> 
> vif-route doesn't support HVM domains because it doesn't support the 
> "add" or "remove" actions.

Should be easy to add?

> I would like to request some testing from people that actually use 
> this network mode.

Might be worth sending a Call-For-Testing to -users@ ?

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 12:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 12:31: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 1U2hgJ-0005XO-Im; Tue, 05 Feb 2013 12:31: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 1U2hgJ-0005XE-3D
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 12:31:23 +0000
Received: from [85.158.137.99:13632] by server-14.bemta-3.messagelabs.com id
	FA/0A-23533-79BF0115; Tue, 05 Feb 2013 12:31:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360067464!15292270!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6110 invoked from network); 5 Feb 2013 12:31:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 12:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1154202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 12:31: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.297.1; Tue, 5 Feb 2013
	12:31:03 +0000
Message-ID: <1360067461.17017.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andia@pereslavl.ru" <andia@pereslavl.ru>
Date: Tue, 5 Feb 2013 12:31:01 +0000
In-Reply-To: <1360066464.5263.117.camel@connect.botik.ru>
References: <1359962676.5263.71.camel@connect.botik.ru>
	<1359992345.7743.69.camel@zakaz.uk.xensource.com>
	<1360066464.5263.117.camel@connect.botik.ru>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful 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

> > 
> > > +                status = os.read(fd, 64)
> > 
> > The written strings are 7 or 4 bytes, it would be better to choose a
> > fixed length for all writes and the read I think. That might mean
> > padding the fail message. Also these protocol strings should be defined
> > as constants rather than open coded.
> > 
> > Even with that addressed I don't really feel confident enough about xend
> > internals to Ack a patch like this.
> > 
> 
> Thank you for your comments and advice to use xl toolstack. We use xen
> and xend toolstack and have some scripts with xm and XenAPI. But as I
> read xend is deprecated in Xen 4.1 and will be removed in a future
> release and a switch to xl may be a good idea.

If you are using XenAPI then you might also consider switching to the
xapi toolstack (the XCP toolstack), which is now in Debian as a
standalone thing 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 Feb 05 12:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 12:31: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 1U2hgJ-0005XO-Im; Tue, 05 Feb 2013 12:31: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 1U2hgJ-0005XE-3D
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 12:31:23 +0000
Received: from [85.158.137.99:13632] by server-14.bemta-3.messagelabs.com id
	FA/0A-23533-79BF0115; Tue, 05 Feb 2013 12:31:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360067464!15292270!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6110 invoked from network); 5 Feb 2013 12:31:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 12:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1154202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 12:31: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.297.1; Tue, 5 Feb 2013
	12:31:03 +0000
Message-ID: <1360067461.17017.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andia@pereslavl.ru" <andia@pereslavl.ru>
Date: Tue, 5 Feb 2013 12:31:01 +0000
In-Reply-To: <1360066464.5263.117.camel@connect.botik.ru>
References: <1359962676.5263.71.camel@connect.botik.ru>
	<1359992345.7743.69.camel@zakaz.uk.xensource.com>
	<1360066464.5263.117.camel@connect.botik.ru>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful 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

> > 
> > > +                status = os.read(fd, 64)
> > 
> > The written strings are 7 or 4 bytes, it would be better to choose a
> > fixed length for all writes and the read I think. That might mean
> > padding the fail message. Also these protocol strings should be defined
> > as constants rather than open coded.
> > 
> > Even with that addressed I don't really feel confident enough about xend
> > internals to Ack a patch like this.
> > 
> 
> Thank you for your comments and advice to use xl toolstack. We use xen
> and xend toolstack and have some scripts with xm and XenAPI. But as I
> read xend is deprecated in Xen 4.1 and will be removed in a future
> release and a switch to xl may be a good idea.

If you are using XenAPI then you might also consider switching to the
xapi toolstack (the XCP toolstack), which is now in Debian as a
standalone thing 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 Feb 05 12:38:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 12: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 1U2hmr-0005we-9B; Tue, 05 Feb 2013 12:38:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <digvijaych@gmail.com>) id 1U2hmp-0005wV-NX
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 12:38:07 +0000
Received: from [85.158.139.211:23807] by server-12.bemta-5.messagelabs.com id
	DE/6D-20195-E2DF0115; Tue, 05 Feb 2013 12:38:06 +0000
X-Env-Sender: digvijaych@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360067885!17210026!1
X-Originating-IP: [209.85.215.49]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18199 invoked from network); 5 Feb 2013 12:38:06 -0000
Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com)
	(209.85.215.49)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 12:38:06 -0000
Received: by mail-la0-f49.google.com with SMTP id fs13so87455lab.22
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Feb 2013 04:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=bZEbyjRZQFsIvZLS7vMFHafcVkOiEl6+5awE3p7XoNI=;
	b=X6IODBNKoRyBIBRlr8ubfcb/GTqIL3ohIlUhzVIDXI0bf7PFY8rA4Z/QjOIdVIpAp8
	+ehrQ76d2U5l1gxz9r+RMi/qae24tU/TEEBMLt/kQX2M+svmSpRLM1/W5luEVpUaVUQT
	zue83hw/a6RjGP5DKW9cON19E5WxnEuWFTTs7xsHDenZ3NVMbGr4WfkCoqdFszinrf0C
	zWH4K/0EXHVkYCVKI0Z+GBCHvWNhf8ZHNJkw2jre3o/HvPLM/wSQy8aKDF+ZRF7WLi7i
	7VifR9/EUUV4Vl+JLz6zKfz5zke7csIKRwfZ81Y+jC8bVoeYXH67AUtJLMuOk+xr0+MV
	j8Ow==
MIME-Version: 1.0
X-Received: by 10.112.36.165 with SMTP id r5mr9762833lbj.112.1360067885404;
	Tue, 05 Feb 2013 04:38:05 -0800 (PST)
Received: by 10.112.79.37 with HTTP; Tue, 5 Feb 2013 04:38:05 -0800 (PST)
Date: Tue, 5 Feb 2013 18:08:05 +0530
Message-ID: <CANq0ewssKVT8fB=i_jJCzGTA4RmPX=J2owkgR60xQ5fTCVehgQ@mail.gmail.com>
From: digvijay chauhan <digvijaych@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xen.org
Subject: [Xen-devel] What parameters to evaluate during 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: multipart/mixed; boundary="===============9131391581056186879=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9131391581056186879==
Content-Type: multipart/alternative; boundary=e0cb4efe30bc2e115604d4f97b9e

--e0cb4efe30bc2e115604d4f97b9e
Content-Type: text/plain; charset=ISO-8859-1

Hello i am trying on live migration of vm using xen,bt during migration
what parameters can be evaluated and which tool will be used in that ?

I mean like memory performance ,disk,cpu performance etc.how can we measure?

regards,
digvijaysingh

--e0cb4efe30bc2e115604d4f97b9e
Content-Type: text/html; charset=ISO-8859-1

Hello i am trying on live migration of vm using xen,bt during migration what parameters can be evaluated and which tool will be used in that ?<br><br>I mean like memory performance ,disk,cpu performance etc.how can we measure?<br>
<br>regards,<br>digvijaysingh<br><br>

--e0cb4efe30bc2e115604d4f97b9e--


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

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

--===============9131391581056186879==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 12:38:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 12: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 1U2hmr-0005we-9B; Tue, 05 Feb 2013 12:38:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <digvijaych@gmail.com>) id 1U2hmp-0005wV-NX
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 12:38:07 +0000
Received: from [85.158.139.211:23807] by server-12.bemta-5.messagelabs.com id
	DE/6D-20195-E2DF0115; Tue, 05 Feb 2013 12:38:06 +0000
X-Env-Sender: digvijaych@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360067885!17210026!1
X-Originating-IP: [209.85.215.49]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18199 invoked from network); 5 Feb 2013 12:38:06 -0000
Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com)
	(209.85.215.49)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 12:38:06 -0000
Received: by mail-la0-f49.google.com with SMTP id fs13so87455lab.22
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Feb 2013 04:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=bZEbyjRZQFsIvZLS7vMFHafcVkOiEl6+5awE3p7XoNI=;
	b=X6IODBNKoRyBIBRlr8ubfcb/GTqIL3ohIlUhzVIDXI0bf7PFY8rA4Z/QjOIdVIpAp8
	+ehrQ76d2U5l1gxz9r+RMi/qae24tU/TEEBMLt/kQX2M+svmSpRLM1/W5luEVpUaVUQT
	zue83hw/a6RjGP5DKW9cON19E5WxnEuWFTTs7xsHDenZ3NVMbGr4WfkCoqdFszinrf0C
	zWH4K/0EXHVkYCVKI0Z+GBCHvWNhf8ZHNJkw2jre3o/HvPLM/wSQy8aKDF+ZRF7WLi7i
	7VifR9/EUUV4Vl+JLz6zKfz5zke7csIKRwfZ81Y+jC8bVoeYXH67AUtJLMuOk+xr0+MV
	j8Ow==
MIME-Version: 1.0
X-Received: by 10.112.36.165 with SMTP id r5mr9762833lbj.112.1360067885404;
	Tue, 05 Feb 2013 04:38:05 -0800 (PST)
Received: by 10.112.79.37 with HTTP; Tue, 5 Feb 2013 04:38:05 -0800 (PST)
Date: Tue, 5 Feb 2013 18:08:05 +0530
Message-ID: <CANq0ewssKVT8fB=i_jJCzGTA4RmPX=J2owkgR60xQ5fTCVehgQ@mail.gmail.com>
From: digvijay chauhan <digvijaych@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xen.org
Subject: [Xen-devel] What parameters to evaluate during 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: multipart/mixed; boundary="===============9131391581056186879=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9131391581056186879==
Content-Type: multipart/alternative; boundary=e0cb4efe30bc2e115604d4f97b9e

--e0cb4efe30bc2e115604d4f97b9e
Content-Type: text/plain; charset=ISO-8859-1

Hello i am trying on live migration of vm using xen,bt during migration
what parameters can be evaluated and which tool will be used in that ?

I mean like memory performance ,disk,cpu performance etc.how can we measure?

regards,
digvijaysingh

--e0cb4efe30bc2e115604d4f97b9e
Content-Type: text/html; charset=ISO-8859-1

Hello i am trying on live migration of vm using xen,bt during migration what parameters can be evaluated and which tool will be used in that ?<br><br>I mean like memory performance ,disk,cpu performance etc.how can we measure?<br>
<br>regards,<br>digvijaysingh<br><br>

--e0cb4efe30bc2e115604d4f97b9e--


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

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

--===============9131391581056186879==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 12:50:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 12:50: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 1U2hy5-0006hR-Px; Tue, 05 Feb 2013 12:49:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1U2hy4-0006hF-E3
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 12:49:44 +0000
Received: from [85.158.137.99:7044] by server-10.bemta-3.messagelabs.com id
	96/1A-10609-7EFF0115; Tue, 05 Feb 2013 12:49:43 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360068582!12230409!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13599 invoked from network); 5 Feb 2013 12:49:43 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 12:49:43 -0000
Received: (qmail 21189 invoked from network); 5 Feb 2013 14:49:41 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 14:49:41 +0200
Message-ID: <5111006C.6020803@gmail.com>
Date: Tue, 05 Feb 2013 14:51:56 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <5110D7EB.7090303@gmail.com>
In-Reply-To: <5110D7EB.7090303@gmail.com>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.6.156201, Dats:
	244244, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_LEGIT_VALID_REPLY; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: e51ff0424340321a9f8be265a6c01d30.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v1.4.7; Id:
	2m1g3ta.17ik0imk9.2cu0f], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45251
Subject: Re: [Xen-devel] What happened to hvm_emulate_one_no_write()?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 see that hvm_emulate_one_no_write() no longer exists in Xen 4.2 (it
> was there in 4.1). Why has it been removed, and is there another way to
> achieve what it did with the more recent Xen versions?

Sorry, a case of mistaken identity :). Please ignore the question.




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

From xen-devel-bounces@lists.xen.org Tue Feb 05 12:50:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 12:50: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 1U2hy5-0006hR-Px; Tue, 05 Feb 2013 12:49:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1U2hy4-0006hF-E3
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 12:49:44 +0000
Received: from [85.158.137.99:7044] by server-10.bemta-3.messagelabs.com id
	96/1A-10609-7EFF0115; Tue, 05 Feb 2013 12:49:43 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360068582!12230409!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13599 invoked from network); 5 Feb 2013 12:49:43 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 12:49:43 -0000
Received: (qmail 21189 invoked from network); 5 Feb 2013 14:49:41 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 14:49:41 +0200
Message-ID: <5111006C.6020803@gmail.com>
Date: Tue, 05 Feb 2013 14:51:56 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <5110D7EB.7090303@gmail.com>
In-Reply-To: <5110D7EB.7090303@gmail.com>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.6.156201, Dats:
	244244, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_LEGIT_VALID_REPLY; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: e51ff0424340321a9f8be265a6c01d30.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v1.4.7; Id:
	2m1g3ta.17ik0imk9.2cu0f], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45251
Subject: Re: [Xen-devel] What happened to hvm_emulate_one_no_write()?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 see that hvm_emulate_one_no_write() no longer exists in Xen 4.2 (it
> was there in 4.1). Why has it been removed, and is there another way to
> achieve what it did with the more recent Xen versions?

Sorry, a case of mistaken identity :). Please ignore the question.




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

From xen-devel-bounces@lists.xen.org Tue Feb 05 13:13:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2iKW-0007Kz-QA; Tue, 05 Feb 2013 13:12:56 +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 1U2iKU-0007Ku-Rp
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 13:12:55 +0000
Received: from [85.158.137.99:60279] by server-15.bemta-3.messagelabs.com id
	BA/74-25405-05501115; Tue, 05 Feb 2013 13:12:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360069967!20051628!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1141 invoked from network); 5 Feb 2013 13:12:47 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 13:12:47 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 736A540036D;
	Tue,  5 Feb 2013 14:12:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id gxWYs0rrOu6K; Tue,  5 Feb 2013 14:12:46 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 5D79E40010D;
	Tue,  5 Feb 2013 14:12:46 +0100 (CET)
Message-ID: <5111054C.2060407@tiscali.it>
Date: Tue, 05 Feb 2013 14:12:44 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51069350.5020106@tiscali.it>
	<1360059948.17017.15.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360059948.17017.15.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 RESEND] tools/libxl: Improve videoram
	setting
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="===============1445101435966142487=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1445101435966142487==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070406020404060203040403"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070406020404060203040403
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 05/02/2013 11:25, Ian Campbell ha scritto:
> On Mon, 2013-01-28 at 15:03 +0000, Fabio Fantoni wrote:
>> tools/libxl: Improve videoram setting
>>
>> - If videoram setting is less than 8 mb shows error and exit.
>> - Added videoram setting for qemu upstream with cirrus (added in qemu =
1.3).
> Which version of qemu does Xen currently ship? Do we need some compat
> code with work with e.g. qemu 1.2 or do older versions silently accept =
+
> ignore this option?

For now not tried with older qemu, I'll try with xen 4.2 that has older=20
qemu.

>> - Updated xl.cfg man.
>>
>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> ---
>>    docs/man/xl.cfg.pod.5      |   14 +++++---------
>>    tools/libxl/libxl_create.c |    4 ++++
>>    tools/libxl/libxl_dm.c     |    6 ++++++
>>    3 files changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index caba162..9c5cdcd 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtua=
l
>> frame buffer devices
>>
>>    Sets the amount of RAM which the emulated video card will contain,
>>    which in turn limits the resolutions and bit depths which will be
>> -available. This option is only available when using the B<stdvga>
>> -option (see below).
>> +available.
>>    The default amount of video ram for stdvga is 8MB which is sufficie=
nt
>> -for e.g. 1600x1200 at 32bpp.
>> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
>> +only when using the qemu-xen-traditional device-model.
>>
>>    When using the emulated Cirrus graphics card (B<stdvga=3D0>)
>>    the amount of video ram is fixed at 4MB which is sufficient
>> -for 1024x768 at 32 bpp.
>> -
>> -videoram option is currently only available when using the
>> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
>> -currently does not support changing the amount of video memory for th=
e
>> -emulated graphics device.
>> +for 1024x768 at 32 bpp and videoram option is currently working
>> +only when using the upstream qemu-xen device-model.
>>
>>    =3Ditem B<stdvga=3DBOOLEAN>
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index a8dfe61..55014e5 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc=
 *gc,
>>                b_info->shadow_memkb =3D 0;
>>            if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DEFAULT)
>>                b_info->video_memkb =3D 8 * 1024;
>> +        else if (b_info->video_memkb < 8192){
>> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,"videoram must be at lea=
st
>> 8 mb");
> Unfortunately the patch is whitespace damaged and doesn't apply. The
> indentation is off too (might be related to the whitespace damage?)

Do not apply this patch now, I'll improve it before following your advice=
s.

>> +            return ERROR_INVAL;
>> +        }
>>            if (b_info->u.hvm.timer_mode =3D=3D LIBXL_TIMER_MODE_DEFAUL=
T)
>>                b_info->u.hvm.timer_mode =3D
>>                    LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 51f9914..465b1fd 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -430,6 +430,12 @@ static char **
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>                break;
>>            case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>>                flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
>> +            if (b_info->video_memkb) {
>> +                flexarray_vappend(dm_args, "-global",
>> +                libxl__sprintf(gc, "vga.vram_size_mb=3D%d",
>> +                libxl__sizekb_to_mb(b_info->video_memkb)),
>> +                NULL);
>> +            }
> The indentation here is wrong as well.
>
> Ian.
>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2897 / Database dei virus: 2639/6080 -  Data di rilasc=
io: 04/02/2013
>
>



--------------ms070406020404060203040403
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNTEzMTI0NFowIwYJKoZIhvcNAQkEMRYEFCbPpq0ROY7j53Rw4ASgqbmB
Yb+RMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAc79oRpFYWLim4TK7v5Rvd0QE
0rlzbbmPvMU8qDlLZ7UedBcBeKBP7Wu9qjJulqV+V+eKqjiMGpynDf/aYQ2YkzM5Yas37fZN
mxe7DlAoOqJ/G73JOElajm1a6x8NgEZWD3bDOPodRCraVtetvMEqGgm5gidgJh2JDm4vnIGM
yNRodTRnLUQpcBmrOQj5R0fX494+W6LZxu5ROdheL1fZ0zLt3lPuAti2w3/jjKk7Z3LeOCn0
7g+MujIXnW4baUt3pVBg45ZvJM0/rI/CB8u1QKHl1nesZA5V4Dligc0Bl0B/+zBDIlZKy9qV
V2X9D6izdGdXKMZJOw+bmFzW5m+ioQAAAAAAAA==
--------------ms070406020404060203040403--


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

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

--===============1445101435966142487==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:13:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2iKW-0007Kz-QA; Tue, 05 Feb 2013 13:12:56 +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 1U2iKU-0007Ku-Rp
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 13:12:55 +0000
Received: from [85.158.137.99:60279] by server-15.bemta-3.messagelabs.com id
	BA/74-25405-05501115; Tue, 05 Feb 2013 13:12:48 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360069967!20051628!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1141 invoked from network); 5 Feb 2013 13:12:47 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 13:12:47 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 736A540036D;
	Tue,  5 Feb 2013 14:12:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id gxWYs0rrOu6K; Tue,  5 Feb 2013 14:12:46 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 5D79E40010D;
	Tue,  5 Feb 2013 14:12:46 +0100 (CET)
Message-ID: <5111054C.2060407@tiscali.it>
Date: Tue, 05 Feb 2013 14:12:44 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51069350.5020106@tiscali.it>
	<1360059948.17017.15.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360059948.17017.15.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 RESEND] tools/libxl: Improve videoram
	setting
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="===============1445101435966142487=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1445101435966142487==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070406020404060203040403"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070406020404060203040403
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 05/02/2013 11:25, Ian Campbell ha scritto:
> On Mon, 2013-01-28 at 15:03 +0000, Fabio Fantoni wrote:
>> tools/libxl: Improve videoram setting
>>
>> - If videoram setting is less than 8 mb shows error and exit.
>> - Added videoram setting for qemu upstream with cirrus (added in qemu =
1.3).
> Which version of qemu does Xen currently ship? Do we need some compat
> code with work with e.g. qemu 1.2 or do older versions silently accept =
+
> ignore this option?

For now not tried with older qemu, I'll try with xen 4.2 that has older=20
qemu.

>> - Updated xl.cfg man.
>>
>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> ---
>>    docs/man/xl.cfg.pod.5      |   14 +++++---------
>>    tools/libxl/libxl_create.c |    4 ++++
>>    tools/libxl/libxl_dm.c     |    6 ++++++
>>    3 files changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index caba162..9c5cdcd 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtua=
l
>> frame buffer devices
>>
>>    Sets the amount of RAM which the emulated video card will contain,
>>    which in turn limits the resolutions and bit depths which will be
>> -available. This option is only available when using the B<stdvga>
>> -option (see below).
>> +available.
>>    The default amount of video ram for stdvga is 8MB which is sufficie=
nt
>> -for e.g. 1600x1200 at 32bpp.
>> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
>> +only when using the qemu-xen-traditional device-model.
>>
>>    When using the emulated Cirrus graphics card (B<stdvga=3D0>)
>>    the amount of video ram is fixed at 4MB which is sufficient
>> -for 1024x768 at 32 bpp.
>> -
>> -videoram option is currently only available when using the
>> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
>> -currently does not support changing the amount of video memory for th=
e
>> -emulated graphics device.
>> +for 1024x768 at 32 bpp and videoram option is currently working
>> +only when using the upstream qemu-xen device-model.
>>
>>    =3Ditem B<stdvga=3DBOOLEAN>
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index a8dfe61..55014e5 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc=
 *gc,
>>                b_info->shadow_memkb =3D 0;
>>            if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DEFAULT)
>>                b_info->video_memkb =3D 8 * 1024;
>> +        else if (b_info->video_memkb < 8192){
>> +            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,"videoram must be at lea=
st
>> 8 mb");
> Unfortunately the patch is whitespace damaged and doesn't apply. The
> indentation is off too (might be related to the whitespace damage?)

Do not apply this patch now, I'll improve it before following your advice=
s.

>> +            return ERROR_INVAL;
>> +        }
>>            if (b_info->u.hvm.timer_mode =3D=3D LIBXL_TIMER_MODE_DEFAUL=
T)
>>                b_info->u.hvm.timer_mode =3D
>>                    LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 51f9914..465b1fd 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -430,6 +430,12 @@ static char **
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>                break;
>>            case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>>                flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
>> +            if (b_info->video_memkb) {
>> +                flexarray_vappend(dm_args, "-global",
>> +                libxl__sprintf(gc, "vga.vram_size_mb=3D%d",
>> +                libxl__sizekb_to_mb(b_info->video_memkb)),
>> +                NULL);
>> +            }
> The indentation here is wrong as well.
>
> Ian.
>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2897 / Database dei virus: 2639/6080 -  Data di rilasc=
io: 04/02/2013
>
>



--------------ms070406020404060203040403
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNTEzMTI0NFowIwYJKoZIhvcNAQkEMRYEFCbPpq0ROY7j53Rw4ASgqbmB
Yb+RMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAc79oRpFYWLim4TK7v5Rvd0QE
0rlzbbmPvMU8qDlLZ7UedBcBeKBP7Wu9qjJulqV+V+eKqjiMGpynDf/aYQ2YkzM5Yas37fZN
mxe7DlAoOqJ/G73JOElajm1a6x8NgEZWD3bDOPodRCraVtetvMEqGgm5gidgJh2JDm4vnIGM
yNRodTRnLUQpcBmrOQj5R0fX494+W6LZxu5ROdheL1fZ0zLt3lPuAti2w3/jjKk7Z3LeOCn0
7g+MujIXnW4baUt3pVBg45ZvJM0/rI/CB8u1QKHl1nesZA5V4Dligc0Bl0B/+zBDIlZKy9qV
V2X9D6izdGdXKMZJOw+bmFzW5m+ioQAAAAAAAA==
--------------ms070406020404060203040403--


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

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

--===============1445101435966142487==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:15:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2iMs-0007RA-Lu; Tue, 05 Feb 2013 13:15:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMq-0007QZ-09; Tue, 05 Feb 2013 13:15:20 +0000
Received: from [85.158.138.51:18533] by server-8.bemta-3.messagelabs.com id
	91/04-25687-6E501115; Tue, 05 Feb 2013 13:15:18 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360070116!31104417!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18786 invoked from network); 5 Feb 2013 13:15:17 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:17 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMe-0003a8-Mt; Tue, 05 Feb 2013 13:15:08 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMe-00089M-1r; Tue, 05 Feb 2013 13:15:08 +0000
Date: Tue, 05 Feb 2013 13:15:08 +0000
Message-Id: <E1U2iMe-00089M-1r@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 38 (CVE-2013-0215) - oxenstored
 incorrect handling of certain Xenbus ring 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

         Xen Security Advisory CVE-2013-0215 / XSA-38
			      version 2

    oxenstored incorrect handling of certain Xenbus ring states

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The oxenstored daemon (the ocaml version of the xenstore daemon) does
not correctly handle unusual or malicious contents in the xenstore
ring.  A malicious guest can exploit this to cause oxenstored to read
past the end of the ring (and very likely crash) or to allocate large
amounts of RAM.

IMPACT
======

A malicious guest administrator can mount a denial of service attack
affecting domain control and management functions.

In more detail:

A malicious guest administrator can cause oxenstored to crash; after
this many host control operations (for example, starting and stopping
domains, device hotplug, and some monitoring functions), will be
unavailable.  Domains which are already running are not directly
affected.

Such an attacker can also cause a memory exhaustion in the domain
running oxenstored; often this will make the host's management
functions unavailable.

Information leak of control plane data is also theoretically possible.

VULNERABLE SYSTEMS
==================

Any system running oxenstored is vulnerable. oxenstored was introduced
in Xen version 4.1.

oxenstored was made the default in Xen 4.2.if a suitable ocaml
toolchain was installed at build time.

Systems running a 32-bit oxenstored are vulnerable only to the crash
and not to the large memory allocation issue.

MITIGATION
==========

Running the C version of xenstored will avoid this issue.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa38.patch             Xen 4.1.x, Xen 4.2.x, xen-unstable

$ sha256sum xsa38*.patch
7d7a5746bc76da747bf61eb87b3303a8f3abb0d96561f35a706c671317ebe4eb  xsa38.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQI0AAoJEIP+FMlX6CvZ6wAIAJdVEbDm51534QlQBGEE160O
beOVzi6J0y1XOV3iDVnPlSxynhhBn3HcNWl0p0ERRAJt+FbZrH/WLMZ/9XLLbzZO
LWVQHPiKkTYxbgxYsNXt/64CxKN8We2lffuBZn6DUQt1ZiV7T9L4SYVTWHeKo5vW
mvs4j4VvlGgQTxIy0a724bEEPbBXNCu76+b6uwbJCkocnul1QMxyMK5mCJK/n/dv
Q4KCXjJ9sfRHcKR8jteU0v45MP3VXbgEjrW70nvqXed3ly01SdBt/OJVAadmiG38
/EPJiFDT9cqPbl9591yQ6tQqRH5B4J3VoT7vl/hcV9AI8cduHVkQ8nLhfo71lLg=
=CAag
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa38.patch"
Content-Disposition: attachment; filename="xsa38.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbCBi
L3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbAppbmRleCAzNTU4ODg5
Li5kNGQxYzdiIDEwMDY0NAotLS0gYS90b29scy9vY2FtbC9saWJzL3hiL3Bh
cnRpYWwubWwKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi9wYXJ0aWFsLm1s
CkBAIC0yNyw4ICsyNywxNSBAQCBleHRlcm5hbCBoZWFkZXJfc2l6ZTogdW5p
dCAtPiBpbnQgPSAic3R1Yl9oZWFkZXJfc2l6ZSIKIGV4dGVybmFsIGhlYWRl
cl9vZl9zdHJpbmdfaW50ZXJuYWw6IHN0cmluZyAtPiBpbnQgKiBpbnQgKiBp
bnQgKiBpbnQKICAgICAgICAgID0gInN0dWJfaGVhZGVyX29mX3N0cmluZyIK
IAorbGV0IHhlbnN0b3JlX3BheWxvYWRfbWF4ID0gNDA5NiAoKiB4ZW4vaW5j
bHVkZS9wdWJsaWMvaW8veHNfd2lyZS5oICopCisKIGxldCBvZl9zdHJpbmcg
cyA9CiAJbGV0IHRpZCwgcmlkLCBvcGludCwgZGxlbiA9IGhlYWRlcl9vZl9z
dHJpbmdfaW50ZXJuYWwgcyBpbgorCSgqIEEgcGFja2V0IHdoaWNoIGlzIGJp
Z2dlciB0aGFuIHhlbnN0b3JlX3BheWxvYWRfbWF4IGlzIGlsbGVnYWwuCisJ
ICAgVGhpcyB3aWxsIGxlYXZlIHRoZSBndWVzdCBjb25uZWN0aW9uIGlzIGEg
YmFkIHN0YXRlIGFuZCB3aWxsCisJICAgYmUgaGFyZCB0byByZWNvdmVyIGZy
b20gd2l0aG91dCByZXN0YXJ0aW5nIHRoZSBjb25uZWN0aW9uCisJICAgKGll
IHJlYm9vdGluZyB0aGUgZ3Vlc3QpICopCisJbGV0IGRsZW4gPSBtaW4geGVu
c3RvcmVfcGF5bG9hZF9tYXggZGxlbiBpbgogCXsKIAkJdGlkID0gdGlkOwog
CQlyaWQgPSByaWQ7CkBAIC0zOCw2ICs0NSw3IEBAIGxldCBvZl9zdHJpbmcg
cyA9CiAJfQogCiBsZXQgYXBwZW5kIHBrdCBzIHN6ID0KKwlpZiBwa3QubGVu
ID4gNDA5NiB0aGVuIGZhaWx3aXRoICJCdWZmZXIuYWRkOiBjYW5ub3QgZ3Jv
dyBidWZmZXIiOwogCUJ1ZmZlci5hZGRfc3RyaW5nIHBrdC5idWYgKFN0cmlu
Zy5zdWIgcyAwIHN6KQogCiBsZXQgdG9fY29tcGxldGUgcGt0ID0KZGlmZiAt
LWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIveHNfcmluZ19zdHVicy5jIGIv
dG9vbHMvb2NhbWwvbGlicy94Yi94c19yaW5nX3N0dWJzLmMKaW5kZXggMDA0
MTRjNS4uNDg4OGFjNSAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwvbGlicy94
Yi94c19yaW5nX3N0dWJzLmMKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi94
c19yaW5nX3N0dWJzLmMKQEAgLTM5LDIxICszOSwyMyBAQCBzdGF0aWMgaW50
IHhzX3JpbmdfcmVhZChzdHJ1Y3QgbW1hcF9pbnRlcmZhY2UgKmludGVyZmFj
ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqYnVmZmVy
LCBpbnQgbGVuKQogewogCXN0cnVjdCB4ZW5zdG9yZV9kb21haW5faW50ZXJm
YWNlICppbnRmID0gaW50ZXJmYWNlLT5hZGRyOwotCVhFTlNUT1JFX1JJTkdf
SURYIGNvbnMsIHByb2Q7CisJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJv
ZDsgLyogb2Zmc2V0cyBvbmx5ICovCiAJaW50IHRvX3JlYWQ7CiAKLQljb25z
ID0gaW50Zi0+cmVxX2NvbnM7Ci0JcHJvZCA9IGludGYtPnJlcV9wcm9kOwor
CWNvbnMgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9jb25zOwor
CXByb2QgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9wcm9kOwog
CXhlbl9tYigpOworCWNvbnMgPSBNQVNLX1hFTlNUT1JFX0lEWChjb25zKTsK
Kwlwcm9kID0gTUFTS19YRU5TVE9SRV9JRFgocHJvZCk7CiAJaWYgKHByb2Qg
PT0gY29ucykKIAkJcmV0dXJuIDA7Ci0JaWYgKE1BU0tfWEVOU1RPUkVfSURY
KHByb2QpID4gTUFTS19YRU5TVE9SRV9JRFgoY29ucykpIAorCWlmIChwcm9k
ID4gY29ucykKIAkJdG9fcmVhZCA9IHByb2QgLSBjb25zOwogCWVsc2UKLQkJ
dG9fcmVhZCA9IFhFTlNUT1JFX1JJTkdfU0laRSAtIE1BU0tfWEVOU1RPUkVf
SURYKGNvbnMpOworCQl0b19yZWFkID0gWEVOU1RPUkVfUklOR19TSVpFIC0g
Y29uczsKIAlpZiAodG9fcmVhZCA8IGxlbikKIAkJbGVuID0gdG9fcmVhZDsK
LQltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBNQVNLX1hFTlNUT1JFX0lE
WChjb25zKSwgbGVuKTsKKwltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBj
b25zLCBsZW4pOwogCXhlbl9tYigpOwogCWludGYtPnJlcV9jb25zICs9IGxl
bjsKIAlyZXR1cm4gbGVuOwpAQCAtNjYsOCArNjgsOCBAQCBzdGF0aWMgaW50
IHhzX3Jpbmdfd3JpdGUoc3RydWN0IG1tYXBfaW50ZXJmYWNlICppbnRlcmZh
Y2UsCiAJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJvZDsKIAlpbnQgY2Fu
X3dyaXRlOwogCi0JY29ucyA9IGludGYtPnJzcF9jb25zOwotCXByb2QgPSBp
bnRmLT5yc3BfcHJvZDsKKwljb25zID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfY29uczsKKwlwcm9kID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfcHJvZDsKIAl4ZW5fbWIoKTsKIAlpZiAoIChwcm9kIC0gY29u
cykgPj0gWEVOU1RPUkVfUklOR19TSVpFICkKIAkJcmV0dXJuIDA7Cg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:15:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2iMs-0007RA-Lu; Tue, 05 Feb 2013 13:15:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMq-0007QZ-09; Tue, 05 Feb 2013 13:15:20 +0000
Received: from [85.158.138.51:18533] by server-8.bemta-3.messagelabs.com id
	91/04-25687-6E501115; Tue, 05 Feb 2013 13:15:18 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360070116!31104417!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18786 invoked from network); 5 Feb 2013 13:15:17 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:17 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMe-0003a8-Mt; Tue, 05 Feb 2013 13:15:08 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMe-00089M-1r; Tue, 05 Feb 2013 13:15:08 +0000
Date: Tue, 05 Feb 2013 13:15:08 +0000
Message-Id: <E1U2iMe-00089M-1r@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 38 (CVE-2013-0215) - oxenstored
 incorrect handling of certain Xenbus ring 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

         Xen Security Advisory CVE-2013-0215 / XSA-38
			      version 2

    oxenstored incorrect handling of certain Xenbus ring states

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The oxenstored daemon (the ocaml version of the xenstore daemon) does
not correctly handle unusual or malicious contents in the xenstore
ring.  A malicious guest can exploit this to cause oxenstored to read
past the end of the ring (and very likely crash) or to allocate large
amounts of RAM.

IMPACT
======

A malicious guest administrator can mount a denial of service attack
affecting domain control and management functions.

In more detail:

A malicious guest administrator can cause oxenstored to crash; after
this many host control operations (for example, starting and stopping
domains, device hotplug, and some monitoring functions), will be
unavailable.  Domains which are already running are not directly
affected.

Such an attacker can also cause a memory exhaustion in the domain
running oxenstored; often this will make the host's management
functions unavailable.

Information leak of control plane data is also theoretically possible.

VULNERABLE SYSTEMS
==================

Any system running oxenstored is vulnerable. oxenstored was introduced
in Xen version 4.1.

oxenstored was made the default in Xen 4.2.if a suitable ocaml
toolchain was installed at build time.

Systems running a 32-bit oxenstored are vulnerable only to the crash
and not to the large memory allocation issue.

MITIGATION
==========

Running the C version of xenstored will avoid this issue.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa38.patch             Xen 4.1.x, Xen 4.2.x, xen-unstable

$ sha256sum xsa38*.patch
7d7a5746bc76da747bf61eb87b3303a8f3abb0d96561f35a706c671317ebe4eb  xsa38.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQI0AAoJEIP+FMlX6CvZ6wAIAJdVEbDm51534QlQBGEE160O
beOVzi6J0y1XOV3iDVnPlSxynhhBn3HcNWl0p0ERRAJt+FbZrH/WLMZ/9XLLbzZO
LWVQHPiKkTYxbgxYsNXt/64CxKN8We2lffuBZn6DUQt1ZiV7T9L4SYVTWHeKo5vW
mvs4j4VvlGgQTxIy0a724bEEPbBXNCu76+b6uwbJCkocnul1QMxyMK5mCJK/n/dv
Q4KCXjJ9sfRHcKR8jteU0v45MP3VXbgEjrW70nvqXed3ly01SdBt/OJVAadmiG38
/EPJiFDT9cqPbl9591yQ6tQqRH5B4J3VoT7vl/hcV9AI8cduHVkQ8nLhfo71lLg=
=CAag
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa38.patch"
Content-Disposition: attachment; filename="xsa38.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbCBi
L3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbAppbmRleCAzNTU4ODg5
Li5kNGQxYzdiIDEwMDY0NAotLS0gYS90b29scy9vY2FtbC9saWJzL3hiL3Bh
cnRpYWwubWwKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi9wYXJ0aWFsLm1s
CkBAIC0yNyw4ICsyNywxNSBAQCBleHRlcm5hbCBoZWFkZXJfc2l6ZTogdW5p
dCAtPiBpbnQgPSAic3R1Yl9oZWFkZXJfc2l6ZSIKIGV4dGVybmFsIGhlYWRl
cl9vZl9zdHJpbmdfaW50ZXJuYWw6IHN0cmluZyAtPiBpbnQgKiBpbnQgKiBp
bnQgKiBpbnQKICAgICAgICAgID0gInN0dWJfaGVhZGVyX29mX3N0cmluZyIK
IAorbGV0IHhlbnN0b3JlX3BheWxvYWRfbWF4ID0gNDA5NiAoKiB4ZW4vaW5j
bHVkZS9wdWJsaWMvaW8veHNfd2lyZS5oICopCisKIGxldCBvZl9zdHJpbmcg
cyA9CiAJbGV0IHRpZCwgcmlkLCBvcGludCwgZGxlbiA9IGhlYWRlcl9vZl9z
dHJpbmdfaW50ZXJuYWwgcyBpbgorCSgqIEEgcGFja2V0IHdoaWNoIGlzIGJp
Z2dlciB0aGFuIHhlbnN0b3JlX3BheWxvYWRfbWF4IGlzIGlsbGVnYWwuCisJ
ICAgVGhpcyB3aWxsIGxlYXZlIHRoZSBndWVzdCBjb25uZWN0aW9uIGlzIGEg
YmFkIHN0YXRlIGFuZCB3aWxsCisJICAgYmUgaGFyZCB0byByZWNvdmVyIGZy
b20gd2l0aG91dCByZXN0YXJ0aW5nIHRoZSBjb25uZWN0aW9uCisJICAgKGll
IHJlYm9vdGluZyB0aGUgZ3Vlc3QpICopCisJbGV0IGRsZW4gPSBtaW4geGVu
c3RvcmVfcGF5bG9hZF9tYXggZGxlbiBpbgogCXsKIAkJdGlkID0gdGlkOwog
CQlyaWQgPSByaWQ7CkBAIC0zOCw2ICs0NSw3IEBAIGxldCBvZl9zdHJpbmcg
cyA9CiAJfQogCiBsZXQgYXBwZW5kIHBrdCBzIHN6ID0KKwlpZiBwa3QubGVu
ID4gNDA5NiB0aGVuIGZhaWx3aXRoICJCdWZmZXIuYWRkOiBjYW5ub3QgZ3Jv
dyBidWZmZXIiOwogCUJ1ZmZlci5hZGRfc3RyaW5nIHBrdC5idWYgKFN0cmlu
Zy5zdWIgcyAwIHN6KQogCiBsZXQgdG9fY29tcGxldGUgcGt0ID0KZGlmZiAt
LWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIveHNfcmluZ19zdHVicy5jIGIv
dG9vbHMvb2NhbWwvbGlicy94Yi94c19yaW5nX3N0dWJzLmMKaW5kZXggMDA0
MTRjNS4uNDg4OGFjNSAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwvbGlicy94
Yi94c19yaW5nX3N0dWJzLmMKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi94
c19yaW5nX3N0dWJzLmMKQEAgLTM5LDIxICszOSwyMyBAQCBzdGF0aWMgaW50
IHhzX3JpbmdfcmVhZChzdHJ1Y3QgbW1hcF9pbnRlcmZhY2UgKmludGVyZmFj
ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqYnVmZmVy
LCBpbnQgbGVuKQogewogCXN0cnVjdCB4ZW5zdG9yZV9kb21haW5faW50ZXJm
YWNlICppbnRmID0gaW50ZXJmYWNlLT5hZGRyOwotCVhFTlNUT1JFX1JJTkdf
SURYIGNvbnMsIHByb2Q7CisJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJv
ZDsgLyogb2Zmc2V0cyBvbmx5ICovCiAJaW50IHRvX3JlYWQ7CiAKLQljb25z
ID0gaW50Zi0+cmVxX2NvbnM7Ci0JcHJvZCA9IGludGYtPnJlcV9wcm9kOwor
CWNvbnMgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9jb25zOwor
CXByb2QgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9wcm9kOwog
CXhlbl9tYigpOworCWNvbnMgPSBNQVNLX1hFTlNUT1JFX0lEWChjb25zKTsK
Kwlwcm9kID0gTUFTS19YRU5TVE9SRV9JRFgocHJvZCk7CiAJaWYgKHByb2Qg
PT0gY29ucykKIAkJcmV0dXJuIDA7Ci0JaWYgKE1BU0tfWEVOU1RPUkVfSURY
KHByb2QpID4gTUFTS19YRU5TVE9SRV9JRFgoY29ucykpIAorCWlmIChwcm9k
ID4gY29ucykKIAkJdG9fcmVhZCA9IHByb2QgLSBjb25zOwogCWVsc2UKLQkJ
dG9fcmVhZCA9IFhFTlNUT1JFX1JJTkdfU0laRSAtIE1BU0tfWEVOU1RPUkVf
SURYKGNvbnMpOworCQl0b19yZWFkID0gWEVOU1RPUkVfUklOR19TSVpFIC0g
Y29uczsKIAlpZiAodG9fcmVhZCA8IGxlbikKIAkJbGVuID0gdG9fcmVhZDsK
LQltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBNQVNLX1hFTlNUT1JFX0lE
WChjb25zKSwgbGVuKTsKKwltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBj
b25zLCBsZW4pOwogCXhlbl9tYigpOwogCWludGYtPnJlcV9jb25zICs9IGxl
bjsKIAlyZXR1cm4gbGVuOwpAQCAtNjYsOCArNjgsOCBAQCBzdGF0aWMgaW50
IHhzX3Jpbmdfd3JpdGUoc3RydWN0IG1tYXBfaW50ZXJmYWNlICppbnRlcmZh
Y2UsCiAJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJvZDsKIAlpbnQgY2Fu
X3dyaXRlOwogCi0JY29ucyA9IGludGYtPnJzcF9jb25zOwotCXByb2QgPSBp
bnRmLT5yc3BfcHJvZDsKKwljb25zID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfY29uczsKKwlwcm9kID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfcHJvZDsKIAl4ZW5fbWIoKTsKIAlpZiAoIChwcm9kIC0gY29u
cykgPj0gWEVOU1RPUkVfUklOR19TSVpFICkKIAkJcmV0dXJuIDA7Cg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:15:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:15: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 1U2iMz-0007TH-2M; Tue, 05 Feb 2013 13:15:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMx-0007SU-9y; Tue, 05 Feb 2013 13:15:27 +0000
Received: from [85.158.143.99:40548] by server-2.bemta-4.messagelabs.com id
	21/FB-01597-EE501115; Tue, 05 Feb 2013 13:15:26 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360070121!22200145!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27328 invoked from network); 5 Feb 2013 13:15:23 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:23 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMi-0003aO-Bd; Tue, 05 Feb 2013 13:15:12 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMi-0008AG-9I; Tue, 05 Feb 2013 13:15:12 +0000
Date: Tue, 05 Feb 2013 13:15:12 +0000
Message-Id: <E1U2iMi-0008AG-9I@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 39 (CVE-2013-0216,
 CVE-2013-0217) - Linux netback DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

    Xen Security Advisory CVE-2013-0216,CVE-2013-0217 / XSA-39
			      version 2

          Linux netback DoS via malicious guest ring.

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The Xen netback implementation contains a couple of flaws which can
allow a guest to cause a DoS in the backend domain, potentially
affecting other domains in the system.

CVE-2013-0216 is a failure to sanity check the ring producer/consumer
pointers which can allow a guest to cause netback to loop for an
extended period preventing other work from occurring.

CVE-2013-0217 is a memory leak on an error path which is guest
triggerable.

IMPACT
======

A malicious guest can mount a DoS affecting the entire system.

VULNERABLE SYSTEMS
==================

All systems running guests with access to PV network devices are
vulnerable.

CVE-2013-0216 affects both mainline ("pvops") and classic-Xen patch
kernels.

CVE-2013-0217 affects only mainline ("pvops") kernels.

MITIGATION
==========

Running HVM guests with only emulated or passthrough NICs or PV guests
with only passthrough NICs will avoid this vulnerability.

RESOLUTION
==========

Applying the appropriate attached patches in sequence resolves this issue.

xsa39-pvops-*.patch            Apply to mainline Linux 3.8-rc2
xsa39-classic-*.patch          Apply to linux-2.6.18-xen tree.

All patches for the given branch should be applied in numerical order.

$ sha256sum xsa39*.patch
4b75961673b940f5eb31451080dd668b9119eb88db1df44db1a3ba4b0d037ce1  xsa39-classic-0001-xen-netback-garbage-ring.patch
096143750b99eb2d88970338c3f9debfbbfdaef766525a620281b28528ebe0ce  xsa39-classic-0002-xen-netback-wrap-around.patch
99cf93e37985908243b974cc726f57e592e62ae005eca52969f11fb6fdea6fb5  xsa39-pvops-0001-xen-netback-shutdown-the-ring-if-it-contains-garbage.patch
e0c4226b0910ca455f22ae117e8346d87053e9faf03ec155dd6c31e2f58a1969  xsa39-pvops-0002-xen-netback-don-t-leak-pages-on-failure-in-xen_netbk.patch
70e6cb644a57cdda7f29eb86086a8e697706c3fc974a44c52322e451fd6b9d5c  xsa39-pvops-0003-xen-netback-free-already-allocated-memory-on-failure.patch
5d0db59bbd5ad3a7efae78a6c26fc2491b7c553e5519dd946d1422a116af73dd  xsa39-pvops-0004-netback-correct-netbk_tx_err-to-handle-wrap-around.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQI5AAoJEIP+FMlX6CvZLbcIAL7gpD+EzDjb+g3ZlORl1jPV
+icqyDoPWeWructbggY+YcJJc2IavNrRXBSN/9edSTUXSi7YTW+Tjeh8bcLza1JM
McWKxPtJB8CKEIAjAeT8qMVaNUNQuJQTtTLtXHGuQE6xwxK8YmgLzQSx91OOp9Bx
49GK1Ptnp7bQoEoc7B3oN6GXr/hs/FvaD0Cr481yUxXX1GxV+AL7sxXiJ4kXu1rE
UTSLFAzUfw1KWI5wP3GQCREhysCvgIq4mZyD5+TF8MUagpg+m1aURs2AUUxrJ/Zw
o+LVEKWYRsTtWIRtwYOdPHn73bllyPOrBgimTDBM9rY9CztOnN8yoPRlUz0Sux0=
=UhBt
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream;
 name="xsa39-classic-0001-xen-netback-garbage-ring.patch"
Content-Disposition: attachment;
 filename="xsa39-classic-0001-xen-netback-garbage-ring.patch"
Content-Transfer-Encoding: base64

bmV0YmFjazogc2h1dGRvd24gdGhlIHJpbmcgaWYgaXQgY29udGFpbnMgZ2Fy
YmFnZQoKQSBidWdneSBvciBtYWxpY2lvdXMgZnJvbnRlbmQgc2hvdWxkIG5v
dCBiZSBhYmxlIHRvIGNvbmZ1c2UgbmV0YmFjay4KSWYgd2Ugc3BvdCBhbnl0
aGluZyB3aGljaCBpcyBub3QgYXMgaXQgc2hvdWxkIGJlIHRoZW4gc2h1dGRv
d24gdGhlCmRldmljZSBhbmQgZG9uJ3QgdHJ5IHRvIGNvbnRpbnVlIHdpdGgg
dGhlIHJpbmcgaW4gYSBwb3RlbnRpYWxseQpob3N0aWxlIHN0YXRlLiBXZWxs
IGJlaGF2ZWQgYW5kIG5vbi1ob3N0aWxlIGZyb250ZW5kcyB3aWxsIG5vdCBi
ZQpwZW5hbGlzZWQuCgpBcyB3ZWxsIGFzIG1ha2luZyB0aGUgZXhpc3Rpbmcg
Y2hlY2tzIGZvciBzdWNoIGVycm9ycyBmYXRhbCBhbHNvIGFkZCBhCm5ldyBj
aGVjayB0aGF0IGVuc3VyZXMgdGhhdCB0aGVyZSBpc24ndCBhbiBpbnNhbmUg
bnVtYmVyIG9mIHJlcXVlc3RzCm9uIHRoZSByaW5nIChpLmUuIG1vcmUgdGhh
biB3b3VsZCBmaXQgaW4gdGhlIHJpbmcpLiBJZiB0aGUgcmluZwpjb250YWlu
cyBnYXJiYWdlIHRoZW4gcHJldmlvdXNseSBpcyB3YXMgcG9zc2libGUgdG8g
bG9vcCBvdmVyIHRoaXMKaW5zYW5lIG51bWJlciwgZ2V0dGluZyBhbiBlcnJv
ciBlYWNoIHRpbWUgYW5kIHRoZXJlZm9yZSBub3QgZ2VuZXJhdGluZwphbnkg
bW9yZSBwZW5kaW5nIHJlcXVlc3RzIGFuZCB0aGVyZWZvcmUgbm90IGV4aXRp
bmcgdGhlIGxvb3AgaW4KeGVuX25ldGJrX3R4X2J1aWxkX2dvcHMgZm9yIGFu
IGV4dGVybmRlZCBwZXJpb2QuCgpBbHNvIHR1cm4gdmFyaW91cyBuZXRkZXZf
ZGJnIGNhbGxzIHdoaWNoIG5vIHByZWNpcGl0YXRlIGEgZmF0YWwgZXJyb3IK
aW50byBuZXRkZXZfZXJyLCB0aGV5IGFyZSByYXRlIGxpbWl0ZWQgYmVjYXVz
ZSB0aGUgZGV2aWNlIGlzIHNodXRkb3duCmFmdGVyd2FyZHMuCgpUaGlzIGZp
eGVzIGF0IGxlYXN0IG9uZSBrbm93biBEb1Mvc29mdGxvY2t1cCBvZiB0aGUg
YmFja2VuZCBkb21haW4uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+CgotLS0gYS9kcml2ZXJzL3hl
bi9uZXRiYWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMveGVuL25ldGJhY2sv
Y29tbW9uLmgKQEAgLTIwNCw2ICsyMDQsOSBAQCBpbnQgbmV0aWZfYmVfc3Rh
cnRfeG1pdChzdHJ1Y3Qgc2tfYnVmZiAqCiBzdHJ1Y3QgbmV0X2RldmljZV9z
dGF0cyAqbmV0aWZfYmVfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICpk
ZXYpOwogaXJxcmV0dXJuX3QgbmV0aWZfYmVfaW50KGludCBpcnEsIHZvaWQg
KmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpOwogCisvKiBQcmV2ZW50
IHRoZSBkZXZpY2UgZnJvbSBnZW5lcmF0aW5nIGFueSBmdXJ0aGVyIHRyYWZm
aWMuICovCit2b2lkIHhlbnZpZl9jYXJyaWVyX29mZihuZXRpZl90ICpuZXRp
Zik7CisKIHN0YXRpYyBpbmxpbmUgaW50IG5ldGJrX2Nhbl9xdWV1ZShzdHJ1
Y3QgbmV0X2RldmljZSAqZGV2KQogewogCW5ldGlmX3QgKm5ldGlmID0gbmV0
ZGV2X3ByaXYoZGV2KTsKLS0tIGEvZHJpdmVycy94ZW4vbmV0YmFjay9pbnRl
cmZhY2UuYworKysgYi9kcml2ZXJzL3hlbi9uZXRiYWNrL2ludGVyZmFjZS5j
CkBAIC0zNDcsMTkgKzM0NywyMyBAQCBlcnJfcng6CiAJcmV0dXJuIGVycjsK
IH0KIAordm9pZCB4ZW52aWZfY2Fycmllcl9vZmYobmV0aWZfdCAqbmV0aWYp
Cit7CisJcnRubF9sb2NrKCk7CisJbmV0YmFja19jYXJyaWVyX29mZihuZXRp
Zik7CisJbmV0aWZfY2Fycmllcl9vZmYobmV0aWYtPmRldik7IC8qIGRpc2Nh
cmQgcXVldWVkIHBhY2tldHMgKi8KKwlpZiAobmV0aWZfcnVubmluZyhuZXRp
Zi0+ZGV2KSkKKwkJX19uZXRpZl9kb3duKG5ldGlmKTsKKwlydG5sX3VubG9j
aygpOworCW5ldGlmX3B1dChuZXRpZik7Cit9CisKIHZvaWQgbmV0aWZfZGlz
Y29ubmVjdChzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSkKIHsKIAluZXRpZl90
ICpuZXRpZiA9IGJlLT5uZXRpZjsKIAotCWlmIChuZXRiYWNrX2NhcnJpZXJf
b2sobmV0aWYpKSB7Ci0JCXJ0bmxfbG9jaygpOwotCQluZXRiYWNrX2NhcnJp
ZXJfb2ZmKG5ldGlmKTsKLQkJbmV0aWZfY2Fycmllcl9vZmYobmV0aWYtPmRl
dik7IC8qIGRpc2NhcmQgcXVldWVkIHBhY2tldHMgKi8KLQkJaWYgKG5ldGlm
X3J1bm5pbmcobmV0aWYtPmRldikpCi0JCQlfX25ldGlmX2Rvd24obmV0aWYp
OwotCQlydG5sX3VubG9jaygpOwotCQluZXRpZl9wdXQobmV0aWYpOwotCX0K
KwlpZiAobmV0YmFja19jYXJyaWVyX29rKG5ldGlmKSkKKwkJeGVudmlmX2Nh
cnJpZXJfb2ZmKG5ldGlmKTsKIAogCWF0b21pY19kZWMoJm5ldGlmLT5yZWZj
bnQpOwogCXdhaXRfZXZlbnQobmV0aWYtPndhaXRpbmdfdG9fZnJlZSwgYXRv
bWljX3JlYWQoJm5ldGlmLT5yZWZjbnQpID09IDApOwotLS0gYS9kcml2ZXJz
L3hlbi9uZXRiYWNrL25ldGJhY2suYworKysgYi9kcml2ZXJzL3hlbi9uZXRi
YWNrL25ldGJhY2suYwpAQCAtMTAyMCw2ICsxMDIwLDE0IEBAIHN0YXRpYyB2
b2lkIG5ldGJrX3R4X2VycihuZXRpZl90ICpuZXRpZiwKIAluZXRpZl9wdXQo
bmV0aWYpOwogfQogCitzdGF0aWMgdm9pZCBuZXRia19mYXRhbF90eF9lcnIo
bmV0aWZfdCAqbmV0aWYpCit7CisJcHJpbnRrKEtFUk5fRVJSICIlczogZmF0
YWwgZXJyb3I7IGRpc2FibGluZyBkZXZpY2VcbiIsCisJICAgICAgIG5ldGlm
LT5kZXYtPm5hbWUpOworCXhlbnZpZl9jYXJyaWVyX29mZihuZXRpZik7CisJ
bmV0aWZfcHV0KG5ldGlmKTsKK30KKwogc3RhdGljIGludCBuZXRia19jb3Vu
dF9yZXF1ZXN0cyhuZXRpZl90ICpuZXRpZiwgbmV0aWZfdHhfcmVxdWVzdF90
ICpmaXJzdCwKIAkJCQluZXRpZl90eF9yZXF1ZXN0X3QgKnR4cCwgaW50IHdv
cmtfdG9fZG8pCiB7CkBAIC0xMDMxLDE5ICsxMDM5LDI1IEBAIHN0YXRpYyBp
bnQgbmV0YmtfY291bnRfcmVxdWVzdHMobmV0aWZfdCAKIAogCWRvIHsKIAkJ
aWYgKGZyYWdzID49IHdvcmtfdG9fZG8pIHsKLQkJCURQUklOVEsoIk5lZWQg
bW9yZSBmcmFnc1xuIik7CisJCQlwcmludGsoS0VSTl9FUlIgIiVzOiBOZWVk
IG1vcmUgZnJhZ3NcbiIsCisJCQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSk7
CisJCQluZXRia19mYXRhbF90eF9lcnIobmV0aWYpOwogCQkJcmV0dXJuIC1m
cmFnczsKIAkJfQogCiAJCWlmICh1bmxpa2VseShmcmFncyA+PSBNQVhfU0tC
X0ZSQUdTKSkgewotCQkJRFBSSU5USygiVG9vIG1hbnkgZnJhZ3NcbiIpOwor
CQkJcHJpbnRrKEtFUk5fRVJSICIlczogVG9vIG1hbnkgZnJhZ3NcbiIsCisJ
CQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSk7CisJCQluZXRia19mYXRhbF90
eF9lcnIobmV0aWYpOwogCQkJcmV0dXJuIC1mcmFnczsKIAkJfQogCiAJCW1l
bWNweSh0eHAsIFJJTkdfR0VUX1JFUVVFU1QoJm5ldGlmLT50eCwgY29ucyAr
IGZyYWdzKSwKIAkJICAgICAgIHNpemVvZigqdHhwKSk7CiAJCWlmICh0eHAt
PnNpemUgPiBmaXJzdC0+c2l6ZSkgewotCQkJRFBSSU5USygiRnJhZ3MgZ2Fs
b3JlXG4iKTsKKwkJCXByaW50ayhLRVJOX0VSUiAiJXM6IEZyYWcgaXMgYmln
Z2VyIHRoYW4gZnJhbWUuXG4iLAorCQkJICAgICAgIG5ldGlmLT5kZXYtPm5h
bWUpOworCQkJbmV0YmtfZmF0YWxfdHhfZXJyKG5ldGlmKTsKIAkJCXJldHVy
biAtZnJhZ3M7CiAJCX0KIApAQCAtMTA1MSw4ICsxMDY1LDkgQEAgc3RhdGlj
IGludCBuZXRia19jb3VudF9yZXF1ZXN0cyhuZXRpZl90IAogCQlmcmFncysr
OwogCiAJCWlmICh1bmxpa2VseSgodHhwLT5vZmZzZXQgKyB0eHAtPnNpemUp
ID4gUEFHRV9TSVpFKSkgewotCQkJRFBSSU5USygidHhwLT5vZmZzZXQ6ICV4
LCBzaXplOiAldVxuIiwKLQkJCQl0eHAtPm9mZnNldCwgdHhwLT5zaXplKTsK
KwkJCXByaW50ayhLRVJOX0VSUiAiJXM6IHR4cC0+b2Zmc2V0OiAleCwgc2l6
ZTogJXVcbiIsCisJCQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSwgdHhwLT5v
ZmZzZXQsIHR4cC0+c2l6ZSk7CisJCQluZXRia19mYXRhbF90eF9lcnIobmV0
aWYpOwogCQkJcmV0dXJuIC1mcmFnczsKIAkJfQogCX0gd2hpbGUgKCh0eHAr
KyktPmZsYWdzICYgTkVUVFhGX21vcmVfZGF0YSk7CkBAIC0xMTk1LDcgKzEy
MTAsOSBAQCBpbnQgbmV0YmtfZ2V0X2V4dHJhcyhuZXRpZl90ICpuZXRpZiwg
c3RyCiAKIAlkbyB7CiAJCWlmICh1bmxpa2VseSh3b3JrX3RvX2RvLS0gPD0g
MCkpIHsKLQkJCURQUklOVEsoIk1pc3NpbmcgZXh0cmEgaW5mb1xuIik7CisJ
CQlwcmludGsoS0VSTl9FUlIgIiVzOiBNaXNzaW5nIGV4dHJhIGluZm9cbiIs
CisJCQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSk7CisJCQluZXRia19mYXRh
bF90eF9lcnIobmV0aWYpOwogCQkJcmV0dXJuIC1FQkFEUjsKIAkJfQogCkBA
IC0xMjA0LDcgKzEyMjEsOSBAQCBpbnQgbmV0YmtfZ2V0X2V4dHJhcyhuZXRp
Zl90ICpuZXRpZiwgc3RyCiAJCWlmICh1bmxpa2VseSghZXh0cmEudHlwZSB8
fAogCQkJICAgICBleHRyYS50eXBlID49IFhFTl9ORVRJRl9FWFRSQV9UWVBF
X01BWCkpIHsKIAkJCW5ldGlmLT50eC5yZXFfY29ucyA9ICsrY29uczsKLQkJ
CURQUklOVEsoIkludmFsaWQgZXh0cmEgdHlwZTogJWRcbiIsIGV4dHJhLnR5
cGUpOworCQkJcHJpbnRrKEtFUk5fRVJSICIlczogSW52YWxpZCBleHRyYSB0
eXBlOiAlZFxuIiwKKwkJCSAgICAgICBuZXRpZi0+ZGV2LT5uYW1lLCBleHRy
YS50eXBlKTsKKwkJCW5ldGJrX2ZhdGFsX3R4X2VycihuZXRpZik7CiAJCQly
ZXR1cm4gLUVJTlZBTDsKIAkJfQogCkBAIC0xMjE1LDE2ICsxMjM0LDIxIEBA
IGludCBuZXRia19nZXRfZXh0cmFzKG5ldGlmX3QgKm5ldGlmLCBzdHIKIAly
ZXR1cm4gd29ya190b19kbzsKIH0KIAotc3RhdGljIGludCBuZXRia19zZXRf
c2tiX2dzbyhzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0aWZfZXh0
cmFfaW5mbyAqZ3NvKQorc3RhdGljIGludCBuZXRia19zZXRfc2tiX2dzbyhu
ZXRpZl90ICpuZXRpZiwgc3RydWN0IHNrX2J1ZmYgKnNrYiwKKwkJCSAgICAg
c3RydWN0IG5ldGlmX2V4dHJhX2luZm8gKmdzbykKIHsKIAlpZiAoIWdzby0+
dS5nc28uc2l6ZSkgewotCQlEUFJJTlRLKCJHU08gc2l6ZSBtdXN0IG5vdCBi
ZSB6ZXJvLlxuIik7CisJCXByaW50ayhLRVJOX0VSUiAiJXM6IEdTTyBzaXpl
IG11c3Qgbm90IGJlIHplcm8uXG4iLAorCQkgICAgICAgbmV0aWYtPmRldi0+
bmFtZSk7CisJCW5ldGJrX2ZhdGFsX3R4X2VycihuZXRpZik7CiAJCXJldHVy
biAtRUlOVkFMOwogCX0KIAogCS8qIEN1cnJlbnRseSBvbmx5IFRDUHY0IFMu
Ty4gaXMgc3VwcG9ydGVkLiAqLwogCWlmIChnc28tPnUuZ3NvLnR5cGUgIT0g
WEVOX05FVElGX0dTT19UWVBFX1RDUFY0KSB7Ci0JCURQUklOVEsoIkJhZCBH
U08gdHlwZSAlZC5cbiIsIGdzby0+dS5nc28udHlwZSk7CisJCXByaW50ayhL
RVJOX0VSUiAiJXM6IEJhZCBHU08gdHlwZSAlZC5cbiIsCisJCSAgICAgICBu
ZXRpZi0+ZGV2LT5uYW1lLCBnc28tPnUuZ3NvLnR5cGUpOworCQluZXRia19m
YXRhbF90eF9lcnIobmV0aWYpOwogCQlyZXR1cm4gLUVJTlZBTDsKIAl9CiAK
QEAgLTEyNTksOSArMTI4MywyNSBAQCBzdGF0aWMgdm9pZCBuZXRfdHhfYWN0
aW9uKHVuc2lnbmVkIGxvbmcgCiAJCSFsaXN0X2VtcHR5KCZuZXRfc2NoZWR1
bGVfbGlzdCkpIHsKIAkJLyogR2V0IGEgbmV0aWYgZnJvbSB0aGUgbGlzdCB3
aXRoIHdvcmsgdG8gZG8uICovCiAJCW5ldGlmID0gcG9sbF9uZXRfc2NoZWR1
bGVfbGlzdCgpOworCQkvKgorCQkgKiBUaGlzIGNhbiBzb21ldGltZXMgaGFw
cGVuIGJlY2F1c2UgdGhlIHRlc3Qgb2YKKwkJICogbGlzdF9lbXB0eShuZXRf
c2NoZWR1bGVfbGlzdCkgYXQgdGhlIHRvcCBvZiB0aGUKKwkJICogbG9vcCBp
cyB1bmxvY2tlZC4gIEp1c3QgZ28gYmFjayBhbmQgaGF2ZSBhbm90aGVyCisJ
CSAqIGxvb2suCisJCSAqLwogCQlpZiAoIW5ldGlmKQogCQkJY29udGludWU7
CiAKKwkJaWYgKG5ldGlmLT50eC5zcmluZy0+cmVxX3Byb2QgLSBuZXRpZi0+
dHgucmVxX2NvbnMgPgorCQkgICAgTkVUX1RYX1JJTkdfU0laRSkgeworCQkJ
cHJpbnRrKEtFUk5fRVJSICIlczogSW1wb3NzaWJsZSBudW1iZXIgb2YgcmVx
dWVzdHMuICIKKwkJCSAgICAgICAicmVxX3Byb2QgJXUsIHJlcV9jb25zICV1
LCBzaXplICVsdVxuIiwKKwkJCSAgICAgICBuZXRpZi0+ZGV2LT5uYW1lLCBu
ZXRpZi0+dHguc3JpbmctPnJlcV9wcm9kLAorCQkJICAgICAgIG5ldGlmLT50
eC5yZXFfY29ucywgTkVUX1RYX1JJTkdfU0laRSk7CisJCQluZXRia19mYXRh
bF90eF9lcnIobmV0aWYpOworCQkJY29udGludWU7CisJCX0KKwogCQlSSU5H
X0ZJTkFMX0NIRUNLX0ZPUl9SRVFVRVNUUygmbmV0aWYtPnR4LCB3b3JrX3Rv
X2RvKTsKIAkJaWYgKCF3b3JrX3RvX2RvKSB7CiAJCQluZXRpZl9wdXQobmV0
aWYpOwpAQCAtMTMxMywxNyArMTM1MywxNCBAQCBzdGF0aWMgdm9pZCBuZXRf
dHhfYWN0aW9uKHVuc2lnbmVkIGxvbmcgCiAJCQl3b3JrX3RvX2RvID0gbmV0
YmtfZ2V0X2V4dHJhcyhuZXRpZiwgZXh0cmFzLAogCQkJCQkJICAgICAgd29y
a190b19kbyk7CiAJCQlpID0gbmV0aWYtPnR4LnJlcV9jb25zOwotCQkJaWYg
KHVubGlrZWx5KHdvcmtfdG9fZG8gPCAwKSkgewotCQkJCW5ldGJrX3R4X2Vy
cihuZXRpZiwgJnR4cmVxLCBpKTsKKwkJCWlmICh1bmxpa2VseSh3b3JrX3Rv
X2RvIDwgMCkpCiAJCQkJY29udGludWU7Ci0JCQl9CiAJCX0KIAogCQlyZXQg
PSBuZXRia19jb3VudF9yZXF1ZXN0cyhuZXRpZiwgJnR4cmVxLCB0eGZyYWdz
LCB3b3JrX3RvX2RvKTsKLQkJaWYgKHVubGlrZWx5KHJldCA8IDApKSB7Ci0J
CQluZXRia190eF9lcnIobmV0aWYsICZ0eHJlcSwgaSAtIHJldCk7CisJCWlm
ICh1bmxpa2VseShyZXQgPCAwKSkKIAkJCWNvbnRpbnVlOwotCQl9CisKIAkJ
aSArPSByZXQ7CiAKIAkJaWYgKHVubGlrZWx5KHR4cmVxLnNpemUgPCBFVEhf
SExFTikpIHsKQEAgLTEzMzQsMTAgKzEzNzEsMTAgQEAgc3RhdGljIHZvaWQg
bmV0X3R4X2FjdGlvbih1bnNpZ25lZCBsb25nIAogCiAJCS8qIE5vIGNyb3Nz
aW5nIGEgcGFnZSBhcyB0aGUgcGF5bG9hZCBtdXN0bid0IGZyYWdtZW50LiAq
LwogCQlpZiAodW5saWtlbHkoKHR4cmVxLm9mZnNldCArIHR4cmVxLnNpemUp
ID4gUEFHRV9TSVpFKSkgewotCQkJRFBSSU5USygidHhyZXEub2Zmc2V0OiAl
eCwgc2l6ZTogJXUsIGVuZDogJWx1XG4iLCAKLQkJCQl0eHJlcS5vZmZzZXQs
IHR4cmVxLnNpemUsIAotCQkJCSh0eHJlcS5vZmZzZXQgJn5QQUdFX01BU0sp
ICsgdHhyZXEuc2l6ZSk7Ci0JCQluZXRia190eF9lcnIobmV0aWYsICZ0eHJl
cSwgaSk7CisJCQlwcmludGsoS0VSTl9FUlIgIiVzOiB0eHJlcS5vZmZzZXQ6
ICV4LCBzaXplOiAldSwgZW5kOiAlbHVcbiIsCisJCQkgICAgICAgbmV0aWYt
PmRldi0+bmFtZSwgdHhyZXEub2Zmc2V0LCB0eHJlcS5zaXplLAorCQkJICAg
ICAgICh0eHJlcS5vZmZzZXQgJiB+UEFHRV9NQVNLKSArIHR4cmVxLnNpemUp
OworCQkJbmV0YmtfZmF0YWxfdHhfZXJyKG5ldGlmKTsKIAkJCWNvbnRpbnVl
OwogCQl9CiAKQEAgLTEzNjIsOSArMTM5OSw5IEBAIHN0YXRpYyB2b2lkIG5l
dF90eF9hY3Rpb24odW5zaWduZWQgbG9uZyAKIAkJCXN0cnVjdCBuZXRpZl9l
eHRyYV9pbmZvICpnc287CiAJCQlnc28gPSAmZXh0cmFzW1hFTl9ORVRJRl9F
WFRSQV9UWVBFX0dTTyAtIDFdOwogCi0JCQlpZiAobmV0Ymtfc2V0X3NrYl9n
c28oc2tiLCBnc28pKSB7CisJCQlpZiAobmV0Ymtfc2V0X3NrYl9nc28obmV0
aWYsIHNrYiwgZ3NvKSkgeworCQkJCS8qIEZhaWx1cmUgaW4gbmV0Ymtfc2V0
X3NrYl9nc28gaXMgZmF0YWwuICovCiAJCQkJa2ZyZWVfc2tiKHNrYik7Ci0J
CQkJbmV0YmtfdHhfZXJyKG5ldGlmLCAmdHhyZXEsIGkpOwogCQkJCWNvbnRp
bnVlOwogCQkJfQogCQl9Cg==

--=separator
Content-Type: application/octet-stream;
 name="xsa39-classic-0002-xen-netback-wrap-around.patch"
Content-Disposition: attachment;
 filename="xsa39-classic-0002-xen-netback-wrap-around.patch"
Content-Transfer-Encoding: base64

bmV0YmFjazogY29ycmVjdCBuZXRia190eF9lcnIoKSB0byBoYW5kbGUgd3Jh
cCBhcm91bmQKClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNh
bXBiZWxsQGNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNo
IDxKQmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL2RyaXZlcnMveGVuL25ldGJh
Y2svbmV0YmFjay5jCisrKyBiL2RyaXZlcnMveGVuL25ldGJhY2svbmV0YmFj
ay5jCkBAIC0xMDExLDcgKzEwMTEsNyBAQCBzdGF0aWMgdm9pZCBuZXRia190
eF9lcnIobmV0aWZfdCAqbmV0aWYsCiAKIAlkbyB7CiAJCW1ha2VfdHhfcmVz
cG9uc2UobmV0aWYsIHR4cCwgTkVUSUZfUlNQX0VSUk9SKTsKLQkJaWYgKGNv
bnMgPj0gZW5kKQorCQlpZiAoY29ucyA9PSBlbmQpCiAJCQlicmVhazsKIAkJ
dHhwID0gUklOR19HRVRfUkVRVUVTVCgmbmV0aWYtPnR4LCBjb25zKyspOwog
CX0gd2hpbGUgKDEpOwo=

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0001-xen-netback-shutdown-the-ring-if-it-contains-garbage.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0001-xen-netback-shutdown-the-ring-if-it-contains-garbage.patch"
Content-Transfer-Encoding: base64

RnJvbSA3ZGQ3Y2U0NDU5M2E4YzRjNzE1ZmE2NjUwMjdhZjhlMDcyNDVjOGNm
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBGcmksIDExIEphbiAy
MDEzIDE0OjI2OjI5ICswMDAwClN1YmplY3Q6IFtQQVRDSCAxLzRdIHhlbi9u
ZXRiYWNrOiBzaHV0ZG93biB0aGUgcmluZyBpZiBpdCBjb250YWlucyBnYXJi
YWdlLgoKQSBidWdneSBvciBtYWxpY2lvdXMgZnJvbnRlbmQgc2hvdWxkIG5v
dCBiZSBhYmxlIHRvIGNvbmZ1c2UgbmV0YmFjay4KSWYgd2Ugc3BvdCBhbnl0
aGluZyB3aGljaCBpcyBub3QgYXMgaXQgc2hvdWxkIGJlIHRoZW4gc2h1dGRv
d24gdGhlCmRldmljZSBhbmQgZG9uJ3QgdHJ5IHRvIGNvbnRpbnVlIHdpdGgg
dGhlIHJpbmcgaW4gYSBwb3RlbnRpYWxseQpob3N0aWxlIHN0YXRlLiBXZWxs
IGJlaGF2ZWQgYW5kIG5vbi1ob3N0aWxlIGZyb250ZW5kcyB3aWxsIG5vdCBi
ZQpwZW5hbGlzZWQuCgpBcyB3ZWxsIGFzIG1ha2luZyB0aGUgZXhpc3Rpbmcg
Y2hlY2tzIGZvciBzdWNoIGVycm9ycyBmYXRhbCBhbHNvIGFkZCBhCm5ldyBj
aGVjayB0aGF0IGVuc3VyZXMgdGhhdCB0aGVyZSBpc24ndCBhbiBpbnNhbmUg
bnVtYmVyIG9mIHJlcXVlc3RzCm9uIHRoZSByaW5nIChpLmUuIG1vcmUgdGhh
biB3b3VsZCBmaXQgaW4gdGhlIHJpbmcpLiBJZiB0aGUgcmluZwpjb250YWlu
cyBnYXJiYWdlIHRoZW4gcHJldmlvdXNseSBpcyB3YXMgcG9zc2libGUgdG8g
bG9vcCBvdmVyIHRoaXMKaW5zYW5lIG51bWJlciwgZ2V0dGluZyBhbiBlcnJv
ciBlYWNoIHRpbWUgYW5kIHRoZXJlZm9yZSBub3QgZ2VuZXJhdGluZwphbnkg
bW9yZSBwZW5kaW5nIHJlcXVlc3RzIGFuZCB0aGVyZWZvcmUgbm90IGV4aXRp
bmcgdGhlIGxvb3AgaW4KeGVuX25ldGJrX3R4X2J1aWxkX2dvcHMgZm9yIGFu
IGV4dGVybmRlZCBwZXJpb2QuCgpBbHNvIHR1cm4gdmFyaW91cyBuZXRkZXZf
ZGJnIGNhbGxzIHdoaWNoIG5vIHByZWNpcGl0YXRlIGEgZmF0YWwgZXJyb3IK
aW50byBuZXRkZXZfZXJyLCB0aGV5IGFyZSByYXRlIGxpbWl0ZWQgYmVjYXVz
ZSB0aGUgZGV2aWNlIGlzIHNodXRkb3duCmFmdGVyd2FyZHMuCgpUaGlzIGZp
eGVzIGF0IGxlYXN0IG9uZSBrbm93biBEb1Mvc29mdGxvY2t1cCBvZiB0aGUg
YmFja2VuZCBkb21haW4uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogS29ucmFk
IFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpBY2tl
ZC1ieTogSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPgotLS0KIGRy
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oICAgIHwgICAgMyArKwog
ZHJpdmVycy9uZXQveGVuLW5ldGJhY2svaW50ZXJmYWNlLmMgfCAgIDIzICsr
KysrKysrLS0tLS0KIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2su
YyAgIHwgICA2MyArKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t
CiAzIGZpbGVzIGNoYW5nZWQsIDYzIGluc2VydGlvbnMoKyksIDI2IGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNr
L2NvbW1vbi5oIGIvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svY29tbW9uLmgK
aW5kZXggOTRiNzljMy4uOWQ3ZjE3MiAxMDA2NDQKLS0tIGEvZHJpdmVycy9u
ZXQveGVuLW5ldGJhY2svY29tbW9uLmgKKysrIGIvZHJpdmVycy9uZXQveGVu
LW5ldGJhY2svY29tbW9uLmgKQEAgLTE1MSw2ICsxNTEsOSBAQCB2b2lkIHhl
bl9uZXRia19xdWV1ZV90eF9za2Ioc3RydWN0IHhlbnZpZiAqdmlmLCBzdHJ1
Y3Qgc2tfYnVmZiAqc2tiKTsKIC8qIE5vdGlmeSB4ZW52aWYgdGhhdCByaW5n
IG5vdyBoYXMgc3BhY2UgdG8gc2VuZCBhbiBza2IgdG8gdGhlIGZyb250ZW5k
ICovCiB2b2lkIHhlbnZpZl9ub3RpZnlfdHhfY29tcGxldGlvbihzdHJ1Y3Qg
eGVudmlmICp2aWYpOwogCisvKiBQcmV2ZW50IHRoZSBkZXZpY2UgZnJvbSBn
ZW5lcmF0aW5nIGFueSBmdXJ0aGVyIHRyYWZmaWMuICovCit2b2lkIHhlbnZp
Zl9jYXJyaWVyX29mZihzdHJ1Y3QgeGVudmlmICp2aWYpOworCiAvKiBSZXR1
cm5zIG51bWJlciBvZiByaW5nIHNsb3RzIHJlcXVpcmVkIHRvIHNlbmQgYW4g
c2tiIHRvIHRoZSBmcm9udGVuZCAqLwogdW5zaWduZWQgaW50IHhlbl9uZXRi
a19jb3VudF9za2Jfc2xvdHMoc3RydWN0IHhlbnZpZiAqdmlmLCBzdHJ1Y3Qg
c2tfYnVmZiAqc2tiKTsKIApkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQveGVu
LW5ldGJhY2svaW50ZXJmYWNlLmMgYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFj
ay9pbnRlcmZhY2UuYwppbmRleCBiN2Q0MWY4Li5iOGM1MTkzIDEwMDY0NAot
LS0gYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9pbnRlcmZhY2UuYworKysg
Yi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9pbnRlcmZhY2UuYwpAQCAtMzQz
LDE3ICszNDMsMjIgQEAgZXJyOgogCXJldHVybiBlcnI7CiB9CiAKLXZvaWQg
eGVudmlmX2Rpc2Nvbm5lY3Qoc3RydWN0IHhlbnZpZiAqdmlmKQordm9pZCB4
ZW52aWZfY2Fycmllcl9vZmYoc3RydWN0IHhlbnZpZiAqdmlmKQogewogCXN0
cnVjdCBuZXRfZGV2aWNlICpkZXYgPSB2aWYtPmRldjsKLQlpZiAobmV0aWZf
Y2Fycmllcl9vayhkZXYpKSB7Ci0JCXJ0bmxfbG9jaygpOwotCQluZXRpZl9j
YXJyaWVyX29mZihkZXYpOyAvKiBkaXNjYXJkIHF1ZXVlZCBwYWNrZXRzICov
Ci0JCWlmIChuZXRpZl9ydW5uaW5nKGRldikpCi0JCQl4ZW52aWZfZG93bih2
aWYpOwotCQlydG5sX3VubG9jaygpOwotCQl4ZW52aWZfcHV0KHZpZik7Ci0J
fQorCisJcnRubF9sb2NrKCk7CisJbmV0aWZfY2Fycmllcl9vZmYoZGV2KTsg
LyogZGlzY2FyZCBxdWV1ZWQgcGFja2V0cyAqLworCWlmIChuZXRpZl9ydW5u
aW5nKGRldikpCisJCXhlbnZpZl9kb3duKHZpZik7CisJcnRubF91bmxvY2so
KTsKKwl4ZW52aWZfcHV0KHZpZik7Cit9CisKK3ZvaWQgeGVudmlmX2Rpc2Nv
bm5lY3Qoc3RydWN0IHhlbnZpZiAqdmlmKQoreworCWlmIChuZXRpZl9jYXJy
aWVyX29rKHZpZi0+ZGV2KSkKKwkJeGVudmlmX2NhcnJpZXJfb2ZmKHZpZik7
CiAKIAlhdG9taWNfZGVjKCZ2aWYtPnJlZmNudCk7CiAJd2FpdF9ldmVudCh2
aWYtPndhaXRpbmdfdG9fZnJlZSwgYXRvbWljX3JlYWQoJnZpZi0+cmVmY250
KSA9PSAwKTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNr
L25ldGJhY2suYyBiL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2su
YwppbmRleCBmMmQ2Yjc4Li4xYTQ0OWY5IDEwMDY0NAotLS0gYS9kcml2ZXJz
L25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKKysrIGIvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jCkBAIC04ODgsNiArODg4LDEzIEBAIHN0
YXRpYyB2b2lkIG5ldGJrX3R4X2VycihzdHJ1Y3QgeGVudmlmICp2aWYsCiAJ
eGVudmlmX3B1dCh2aWYpOwogfQogCitzdGF0aWMgdm9pZCBuZXRia19mYXRh
bF90eF9lcnIoc3RydWN0IHhlbnZpZiAqdmlmKQoreworCW5ldGRldl9lcnIo
dmlmLT5kZXYsICJmYXRhbCBlcnJvcjsgZGlzYWJsaW5nIGRldmljZVxuIik7
CisJeGVudmlmX2NhcnJpZXJfb2ZmKHZpZik7CisJeGVudmlmX3B1dCh2aWYp
OworfQorCiBzdGF0aWMgaW50IG5ldGJrX2NvdW50X3JlcXVlc3RzKHN0cnVj
dCB4ZW52aWYgKnZpZiwKIAkJCQlzdHJ1Y3QgeGVuX25ldGlmX3R4X3JlcXVl
c3QgKmZpcnN0LAogCQkJCXN0cnVjdCB4ZW5fbmV0aWZfdHhfcmVxdWVzdCAq
dHhwLApAQCAtOTAxLDE5ICs5MDgsMjIgQEAgc3RhdGljIGludCBuZXRia19j
b3VudF9yZXF1ZXN0cyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAKIAlkbyB7CiAJ
CWlmIChmcmFncyA+PSB3b3JrX3RvX2RvKSB7Ci0JCQluZXRkZXZfZGJnKHZp
Zi0+ZGV2LCAiTmVlZCBtb3JlIGZyYWdzXG4iKTsKKwkJCW5ldGRldl9lcnIo
dmlmLT5kZXYsICJOZWVkIG1vcmUgZnJhZ3NcbiIpOworCQkJbmV0YmtfZmF0
YWxfdHhfZXJyKHZpZik7CiAJCQlyZXR1cm4gLWZyYWdzOwogCQl9CiAKIAkJ
aWYgKHVubGlrZWx5KGZyYWdzID49IE1BWF9TS0JfRlJBR1MpKSB7Ci0JCQlu
ZXRkZXZfZGJnKHZpZi0+ZGV2LCAiVG9vIG1hbnkgZnJhZ3NcbiIpOworCQkJ
bmV0ZGV2X2Vycih2aWYtPmRldiwgIlRvbyBtYW55IGZyYWdzXG4iKTsKKwkJ
CW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYpOwogCQkJcmV0dXJuIC1mcmFnczsK
IAkJfQogCiAJCW1lbWNweSh0eHAsIFJJTkdfR0VUX1JFUVVFU1QoJnZpZi0+
dHgsIGNvbnMgKyBmcmFncyksCiAJCSAgICAgICBzaXplb2YoKnR4cCkpOwog
CQlpZiAodHhwLT5zaXplID4gZmlyc3QtPnNpemUpIHsKLQkJCW5ldGRldl9k
YmcodmlmLT5kZXYsICJGcmFncyBnYWxvcmVcbiIpOworCQkJbmV0ZGV2X2Vy
cih2aWYtPmRldiwgIkZyYWcgaXMgYmlnZ2VyIHRoYW4gZnJhbWUuXG4iKTsK
KwkJCW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYpOwogCQkJcmV0dXJuIC1mcmFn
czsKIAkJfQogCkBAIC05MjEsOCArOTMxLDkgQEAgc3RhdGljIGludCBuZXRi
a19jb3VudF9yZXF1ZXN0cyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAJCWZyYWdz
Kys7CiAKIAkJaWYgKHVubGlrZWx5KCh0eHAtPm9mZnNldCArIHR4cC0+c2l6
ZSkgPiBQQUdFX1NJWkUpKSB7Ci0JCQluZXRkZXZfZGJnKHZpZi0+ZGV2LCAi
dHhwLT5vZmZzZXQ6ICV4LCBzaXplOiAldVxuIiwKKwkJCW5ldGRldl9lcnIo
dmlmLT5kZXYsICJ0eHAtPm9mZnNldDogJXgsIHNpemU6ICV1XG4iLAogCQkJ
CSB0eHAtPm9mZnNldCwgdHhwLT5zaXplKTsKKwkJCW5ldGJrX2ZhdGFsX3R4
X2Vycih2aWYpOwogCQkJcmV0dXJuIC1mcmFnczsKIAkJfQogCX0gd2hpbGUg
KCh0eHArKyktPmZsYWdzICYgWEVOX05FVFRYRl9tb3JlX2RhdGEpOwpAQCAt
MTA5NSw3ICsxMTA2LDggQEAgc3RhdGljIGludCB4ZW5fbmV0YmtfZ2V0X2V4
dHJhcyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAKIAlkbyB7CiAJCWlmICh1bmxp
a2VseSh3b3JrX3RvX2RvLS0gPD0gMCkpIHsKLQkJCW5ldGRldl9kYmcodmlm
LT5kZXYsICJNaXNzaW5nIGV4dHJhIGluZm9cbiIpOworCQkJbmV0ZGV2X2Vy
cih2aWYtPmRldiwgIk1pc3NpbmcgZXh0cmEgaW5mb1xuIik7CisJCQluZXRi
a19mYXRhbF90eF9lcnIodmlmKTsKIAkJCXJldHVybiAtRUJBRFI7CiAJCX0K
IApAQCAtMTEwNCw4ICsxMTE2LDkgQEAgc3RhdGljIGludCB4ZW5fbmV0Ymtf
Z2V0X2V4dHJhcyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAJCWlmICh1bmxpa2Vs
eSghZXh0cmEudHlwZSB8fAogCQkJICAgICBleHRyYS50eXBlID49IFhFTl9O
RVRJRl9FWFRSQV9UWVBFX01BWCkpIHsKIAkJCXZpZi0+dHgucmVxX2NvbnMg
PSArK2NvbnM7Ci0JCQluZXRkZXZfZGJnKHZpZi0+ZGV2LAorCQkJbmV0ZGV2
X2Vycih2aWYtPmRldiwKIAkJCQkgICAiSW52YWxpZCBleHRyYSB0eXBlOiAl
ZFxuIiwgZXh0cmEudHlwZSk7CisJCQluZXRia19mYXRhbF90eF9lcnIodmlm
KTsKIAkJCXJldHVybiAtRUlOVkFMOwogCQl9CiAKQEAgLTExMjEsMTMgKzEx
MzQsMTUgQEAgc3RhdGljIGludCBuZXRia19zZXRfc2tiX2dzbyhzdHJ1Y3Qg
eGVudmlmICp2aWYsCiAJCQkgICAgIHN0cnVjdCB4ZW5fbmV0aWZfZXh0cmFf
aW5mbyAqZ3NvKQogewogCWlmICghZ3NvLT51Lmdzby5zaXplKSB7Ci0JCW5l
dGRldl9kYmcodmlmLT5kZXYsICJHU08gc2l6ZSBtdXN0IG5vdCBiZSB6ZXJv
LlxuIik7CisJCW5ldGRldl9lcnIodmlmLT5kZXYsICJHU08gc2l6ZSBtdXN0
IG5vdCBiZSB6ZXJvLlxuIik7CisJCW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYp
OwogCQlyZXR1cm4gLUVJTlZBTDsKIAl9CiAKIAkvKiBDdXJyZW50bHkgb25s
eSBUQ1B2NCBTLk8uIGlzIHN1cHBvcnRlZC4gKi8KIAlpZiAoZ3NvLT51Lmdz
by50eXBlICE9IFhFTl9ORVRJRl9HU09fVFlQRV9UQ1BWNCkgewotCQluZXRk
ZXZfZGJnKHZpZi0+ZGV2LCAiQmFkIEdTTyB0eXBlICVkLlxuIiwgZ3NvLT51
Lmdzby50eXBlKTsKKwkJbmV0ZGV2X2Vycih2aWYtPmRldiwgIkJhZCBHU08g
dHlwZSAlZC5cbiIsIGdzby0+dS5nc28udHlwZSk7CisJCW5ldGJrX2ZhdGFs
X3R4X2Vycih2aWYpOwogCQlyZXR1cm4gLUVJTlZBTDsKIAl9CiAKQEAgLTEy
NjQsOSArMTI3OSwyNiBAQCBzdGF0aWMgdW5zaWduZWQgeGVuX25ldGJrX3R4
X2J1aWxkX2dvcHMoc3RydWN0IHhlbl9uZXRiayAqbmV0YmspCiAKIAkJLyog
R2V0IGEgbmV0aWYgZnJvbSB0aGUgbGlzdCB3aXRoIHdvcmsgdG8gZG8uICov
CiAJCXZpZiA9IHBvbGxfbmV0X3NjaGVkdWxlX2xpc3QobmV0YmspOworCQkv
KgorCQkgKiBUaGlzIGNhbiBzb21ldGltZXMgaGFwcGVuIGJlY2F1c2UgdGhl
IHRlc3Qgb2YKKwkJICogbGlzdF9lbXB0eShuZXRfc2NoZWR1bGVfbGlzdCkg
YXQgdGhlIHRvcCBvZiB0aGUKKwkJICogbG9vcCBpcyB1bmxvY2tlZC4gIEp1
c3QgZ28gYmFjayBhbmQgaGF2ZSBhbm90aGVyCisJCSAqIGxvb2suCisJCSAq
LwogCQlpZiAoIXZpZikKIAkJCWNvbnRpbnVlOwogCisJCWlmICh2aWYtPnR4
LnNyaW5nLT5yZXFfcHJvZCAtIHZpZi0+dHgucmVxX2NvbnMgPgorCQkgICAg
WEVOX05FVElGX1RYX1JJTkdfU0laRSkgeworCQkJbmV0ZGV2X2Vycih2aWYt
PmRldiwKKwkJCQkgICAiSW1wb3NzaWJsZSBudW1iZXIgb2YgcmVxdWVzdHMu
ICIKKwkJCQkgICAicmVxX3Byb2QgJWQsIHJlcV9jb25zICVkLCBzaXplICVs
ZFxuIiwKKwkJCQkgICB2aWYtPnR4LnNyaW5nLT5yZXFfcHJvZCwgdmlmLT50
eC5yZXFfY29ucywKKwkJCQkgICBYRU5fTkVUSUZfVFhfUklOR19TSVpFKTsK
KwkJCW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYpOworCQkJY29udGludWU7CisJ
CX0KKwogCQlSSU5HX0ZJTkFMX0NIRUNLX0ZPUl9SRVFVRVNUUygmdmlmLT50
eCwgd29ya190b19kbyk7CiAJCWlmICghd29ya190b19kbykgewogCQkJeGVu
dmlmX3B1dCh2aWYpOwpAQCAtMTI5NCwxNyArMTMyNiwxNCBAQCBzdGF0aWMg
dW5zaWduZWQgeGVuX25ldGJrX3R4X2J1aWxkX2dvcHMoc3RydWN0IHhlbl9u
ZXRiayAqbmV0YmspCiAJCQl3b3JrX3RvX2RvID0geGVuX25ldGJrX2dldF9l
eHRyYXModmlmLCBleHRyYXMsCiAJCQkJCQkJICB3b3JrX3RvX2RvKTsKIAkJ
CWlkeCA9IHZpZi0+dHgucmVxX2NvbnM7Ci0JCQlpZiAodW5saWtlbHkod29y
a190b19kbyA8IDApKSB7Ci0JCQkJbmV0YmtfdHhfZXJyKHZpZiwgJnR4cmVx
LCBpZHgpOworCQkJaWYgKHVubGlrZWx5KHdvcmtfdG9fZG8gPCAwKSkKIAkJ
CQljb250aW51ZTsKLQkJCX0KIAkJfQogCiAJCXJldCA9IG5ldGJrX2NvdW50
X3JlcXVlc3RzKHZpZiwgJnR4cmVxLCB0eGZyYWdzLCB3b3JrX3RvX2RvKTsK
LQkJaWYgKHVubGlrZWx5KHJldCA8IDApKSB7Ci0JCQluZXRia190eF9lcnIo
dmlmLCAmdHhyZXEsIGlkeCAtIHJldCk7CisJCWlmICh1bmxpa2VseShyZXQg
PCAwKSkKIAkJCWNvbnRpbnVlOwotCQl9CisKIAkJaWR4ICs9IHJldDsKIAog
CQlpZiAodW5saWtlbHkodHhyZXEuc2l6ZSA8IEVUSF9ITEVOKSkgewpAQCAt
MTMxNiwxMSArMTM0NSwxMSBAQCBzdGF0aWMgdW5zaWduZWQgeGVuX25ldGJr
X3R4X2J1aWxkX2dvcHMoc3RydWN0IHhlbl9uZXRiayAqbmV0YmspCiAKIAkJ
LyogTm8gY3Jvc3NpbmcgYSBwYWdlIGFzIHRoZSBwYXlsb2FkIG11c3RuJ3Qg
ZnJhZ21lbnQuICovCiAJCWlmICh1bmxpa2VseSgodHhyZXEub2Zmc2V0ICsg
dHhyZXEuc2l6ZSkgPiBQQUdFX1NJWkUpKSB7Ci0JCQluZXRkZXZfZGJnKHZp
Zi0+ZGV2LAorCQkJbmV0ZGV2X2Vycih2aWYtPmRldiwKIAkJCQkgICAidHhy
ZXEub2Zmc2V0OiAleCwgc2l6ZTogJXUsIGVuZDogJWx1XG4iLAogCQkJCSAg
IHR4cmVxLm9mZnNldCwgdHhyZXEuc2l6ZSwKIAkJCQkgICAodHhyZXEub2Zm
c2V0Jn5QQUdFX01BU0spICsgdHhyZXEuc2l6ZSk7Ci0JCQluZXRia190eF9l
cnIodmlmLCAmdHhyZXEsIGlkeCk7CisJCQluZXRia19mYXRhbF90eF9lcnIo
dmlmKTsKIAkJCWNvbnRpbnVlOwogCQl9CiAKQEAgLTEzNDgsOCArMTM3Nyw4
IEBAIHN0YXRpYyB1bnNpZ25lZCB4ZW5fbmV0YmtfdHhfYnVpbGRfZ29wcyhz
dHJ1Y3QgeGVuX25ldGJrICpuZXRiaykKIAkJCWdzbyA9ICZleHRyYXNbWEVO
X05FVElGX0VYVFJBX1RZUEVfR1NPIC0gMV07CiAKIAkJCWlmIChuZXRia19z
ZXRfc2tiX2dzbyh2aWYsIHNrYiwgZ3NvKSkgeworCQkJCS8qIEZhaWx1cmUg
aW4gbmV0Ymtfc2V0X3NrYl9nc28gaXMgZmF0YWwuICovCiAJCQkJa2ZyZWVf
c2tiKHNrYik7Ci0JCQkJbmV0YmtfdHhfZXJyKHZpZiwgJnR4cmVxLCBpZHgp
OwogCQkJCWNvbnRpbnVlOwogCQkJfQogCQl9Ci0tIAoxLjcuMi41Cgo=

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0002-xen-netback-don-t-leak-pages-on-failure-in-xen_netbk.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0002-xen-netback-don-t-leak-pages-on-failure-in-xen_netbk.patch"
Content-Transfer-Encoding: base64

RnJvbSA5MDQyMDYzMWQyYjc4YWNhMjhjOTRiZWI2NmIyNTQ0N2U1N2E4ZGQ0
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBNb24sIDE0IEphbiAy
MDEzIDEyOjIwOjA0ICswMDAwClN1YmplY3Q6IFtQQVRDSCAyLzRdIHhlbi9u
ZXRiYWNrOiBkb24ndCBsZWFrIHBhZ2VzIG9uIGZhaWx1cmUgaW4geGVuX25l
dGJrX3R4X2NoZWNrX2dvcC4KClNpZ25lZC1vZmYtYnk6IE1hdHRoZXcgRGFs
ZXkgPG1hdHRqZEBnbWFpbC5jb20+ClJldmlld2VkLWJ5OiBLb25yYWQgUnpl
c3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkFja2VkLWJ5
OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpBY2tl
ZC1ieTogSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPgotLS0KIGRy
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYyB8ICAgMzggKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5n
ZWQsIDEzIGluc2VydGlvbnMoKyksIDI1IGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYyBiL2Ry
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwppbmRleCAxYTQ0OWY5
Li45NzUyNDFlIDEwMDY0NAotLS0gYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFj
ay9uZXRiYWNrLmMKKysrIGIvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svbmV0
YmFjay5jCkBAIC0xNDcsNyArMTQ3LDggQEAgdm9pZCB4ZW5fbmV0YmtfcmVt
b3ZlX3hlbnZpZihzdHJ1Y3QgeGVudmlmICp2aWYpCiAJYXRvbWljX2RlYygm
bmV0YmstPm5ldGZyb250X2NvdW50KTsKIH0KIAotc3RhdGljIHZvaWQgeGVu
X25ldGJrX2lkeF9yZWxlYXNlKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCB1
MTYgcGVuZGluZ19pZHgpOworc3RhdGljIHZvaWQgeGVuX25ldGJrX2lkeF9y
ZWxlYXNlKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCB1MTYgcGVuZGluZ19p
ZHgsCisJCQkJICB1OCBzdGF0dXMpOwogc3RhdGljIHZvaWQgbWFrZV90eF9y
ZXNwb25zZShzdHJ1Y3QgeGVudmlmICp2aWYsCiAJCQkgICAgIHN0cnVjdCB4
ZW5fbmV0aWZfdHhfcmVxdWVzdCAqdHhwLAogCQkJICAgICBzOCAgICAgICBz
dCk7CkBAIC0xMDA3LDMwICsxMDA4LDIwIEBAIHN0YXRpYyBpbnQgeGVuX25l
dGJrX3R4X2NoZWNrX2dvcChzdHJ1Y3QgeGVuX25ldGJrICpuZXRiaywKIHsK
IAlzdHJ1Y3QgZ250dGFiX2NvcHkgKmdvcCA9ICpnb3BwOwogCXUxNiBwZW5k
aW5nX2lkeCA9ICooKHUxNiAqKXNrYi0+ZGF0YSk7Ci0Jc3RydWN0IHBlbmRp
bmdfdHhfaW5mbyAqcGVuZGluZ190eF9pbmZvID0gbmV0YmstPnBlbmRpbmdf
dHhfaW5mbzsKLQlzdHJ1Y3QgeGVudmlmICp2aWYgPSBwZW5kaW5nX3R4X2lu
Zm9bcGVuZGluZ19pZHhdLnZpZjsKLQlzdHJ1Y3QgeGVuX25ldGlmX3R4X3Jl
cXVlc3QgKnR4cDsKIAlzdHJ1Y3Qgc2tiX3NoYXJlZF9pbmZvICpzaGluZm8g
PSBza2Jfc2hpbmZvKHNrYik7CiAJaW50IG5yX2ZyYWdzID0gc2hpbmZvLT5u
cl9mcmFnczsKIAlpbnQgaSwgZXJyLCBzdGFydDsKIAogCS8qIENoZWNrIHN0
YXR1cyBvZiBoZWFkZXIuICovCiAJZXJyID0gZ29wLT5zdGF0dXM7Ci0JaWYg
KHVubGlrZWx5KGVycikpIHsKLQkJcGVuZGluZ19yaW5nX2lkeF90IGluZGV4
OwotCQlpbmRleCA9IHBlbmRpbmdfaW5kZXgobmV0YmstPnBlbmRpbmdfcHJv
ZCsrKTsKLQkJdHhwID0gJnBlbmRpbmdfdHhfaW5mb1twZW5kaW5nX2lkeF0u
cmVxOwotCQltYWtlX3R4X3Jlc3BvbnNlKHZpZiwgdHhwLCBYRU5fTkVUSUZf
UlNQX0VSUk9SKTsKLQkJbmV0YmstPnBlbmRpbmdfcmluZ1tpbmRleF0gPSBw
ZW5kaW5nX2lkeDsKLQkJeGVudmlmX3B1dCh2aWYpOwotCX0KKwlpZiAodW5s
aWtlbHkoZXJyKSkKKwkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBw
ZW5kaW5nX2lkeCwgWEVOX05FVElGX1JTUF9FUlJPUik7CiAKIAkvKiBTa2lw
IGZpcnN0IHNrYiBmcmFnbWVudCBpZiBpdCBpcyBvbiBzYW1lIHBhZ2UgYXMg
aGVhZGVyIGZyYWdtZW50LiAqLwogCXN0YXJ0ID0gKGZyYWdfZ2V0X3BlbmRp
bmdfaWR4KCZzaGluZm8tPmZyYWdzWzBdKSA9PSBwZW5kaW5nX2lkeCk7CiAK
IAlmb3IgKGkgPSBzdGFydDsgaSA8IG5yX2ZyYWdzOyBpKyspIHsKIAkJaW50
IGosIG5ld2VycjsKLQkJcGVuZGluZ19yaW5nX2lkeF90IGluZGV4OwogCiAJ
CXBlbmRpbmdfaWR4ID0gZnJhZ19nZXRfcGVuZGluZ19pZHgoJnNoaW5mby0+
ZnJhZ3NbaV0pOwogCkBAIC0xMDM5LDE2ICsxMDMwLDEyIEBAIHN0YXRpYyBp
bnQgeGVuX25ldGJrX3R4X2NoZWNrX2dvcChzdHJ1Y3QgeGVuX25ldGJrICpu
ZXRiaywKIAkJaWYgKGxpa2VseSghbmV3ZXJyKSkgewogCQkJLyogSGFkIGEg
cHJldmlvdXMgZXJyb3I/IEludmFsaWRhdGUgdGhpcyBmcmFnbWVudC4gKi8K
IAkJCWlmICh1bmxpa2VseShlcnIpKQotCQkJCXhlbl9uZXRia19pZHhfcmVs
ZWFzZShuZXRiaywgcGVuZGluZ19pZHgpOworCQkJCXhlbl9uZXRia19pZHhf
cmVsZWFzZShuZXRiaywgcGVuZGluZ19pZHgsIFhFTl9ORVRJRl9SU1BfT0tB
WSk7CiAJCQljb250aW51ZTsKIAkJfQogCiAJCS8qIEVycm9yIG9uIHRoaXMg
ZnJhZ21lbnQ6IHJlc3BvbmQgdG8gY2xpZW50IHdpdGggYW4gZXJyb3IuICov
Ci0JCXR4cCA9ICZuZXRiay0+cGVuZGluZ190eF9pbmZvW3BlbmRpbmdfaWR4
XS5yZXE7Ci0JCW1ha2VfdHhfcmVzcG9uc2UodmlmLCB0eHAsIFhFTl9ORVRJ
Rl9SU1BfRVJST1IpOwotCQlpbmRleCA9IHBlbmRpbmdfaW5kZXgobmV0Ymst
PnBlbmRpbmdfcHJvZCsrKTsKLQkJbmV0YmstPnBlbmRpbmdfcmluZ1tpbmRl
eF0gPSBwZW5kaW5nX2lkeDsKLQkJeGVudmlmX3B1dCh2aWYpOworCQl4ZW5f
bmV0YmtfaWR4X3JlbGVhc2UobmV0YmssIHBlbmRpbmdfaWR4LCBYRU5fTkVU
SUZfUlNQX0VSUk9SKTsKIAogCQkvKiBOb3QgdGhlIGZpcnN0IGVycm9yPyBQ
cmVjZWRpbmcgZnJhZ3MgYWxyZWFkeSBpbnZhbGlkYXRlZC4gKi8KIAkJaWYg
KGVycikKQEAgLTEwNTYsMTAgKzEwNDMsMTAgQEAgc3RhdGljIGludCB4ZW5f
bmV0YmtfdHhfY2hlY2tfZ29wKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLAog
CiAJCS8qIEZpcnN0IGVycm9yOiBpbnZhbGlkYXRlIGhlYWRlciBhbmQgcHJl
Y2VkaW5nIGZyYWdtZW50cy4gKi8KIAkJcGVuZGluZ19pZHggPSAqKCh1MTYg
Kilza2ItPmRhdGEpOwotCQl4ZW5fbmV0YmtfaWR4X3JlbGVhc2UobmV0Ymss
IHBlbmRpbmdfaWR4KTsKKwkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJr
LCBwZW5kaW5nX2lkeCwgWEVOX05FVElGX1JTUF9PS0FZKTsKIAkJZm9yIChq
ID0gc3RhcnQ7IGogPCBpOyBqKyspIHsKIAkJCXBlbmRpbmdfaWR4ID0gZnJh
Z19nZXRfcGVuZGluZ19pZHgoJnNoaW5mby0+ZnJhZ3Nbal0pOwotCQkJeGVu
X25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lkeCk7CisJCQl4
ZW5fbmV0YmtfaWR4X3JlbGVhc2UobmV0YmssIHBlbmRpbmdfaWR4LCBYRU5f
TkVUSUZfUlNQX09LQVkpOwogCQl9CiAKIAkJLyogUmVtZW1iZXIgdGhlIGVy
cm9yOiBpbnZhbGlkYXRlIGFsbCBzdWJzZXF1ZW50IGZyYWdtZW50cy4gKi8K
QEAgLTEwOTMsNyArMTA4MCw3IEBAIHN0YXRpYyB2b2lkIHhlbl9uZXRia19m
aWxsX2ZyYWdzKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCBzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKQogCiAJCS8qIFRha2UgYW4gZXh0cmEgcmVmZXJlbmNlIHRv
IG9mZnNldCB4ZW5fbmV0YmtfaWR4X3JlbGVhc2UgKi8KIAkJZ2V0X3BhZ2Uo
bmV0YmstPm1tYXBfcGFnZXNbcGVuZGluZ19pZHhdKTsKLQkJeGVuX25ldGJr
X2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lkeCk7CisJCXhlbl9uZXRi
a19pZHhfcmVsZWFzZShuZXRiaywgcGVuZGluZ19pZHgsIFhFTl9ORVRJRl9S
U1BfT0tBWSk7CiAJfQogfQogCkBAIC0xNDc3LDcgKzE0NjQsNyBAQCBzdGF0
aWMgdm9pZCB4ZW5fbmV0YmtfdHhfc3VibWl0KHN0cnVjdCB4ZW5fbmV0Ymsg
Km5ldGJrKQogCQkJdHhwLT5zaXplIC09IGRhdGFfbGVuOwogCQl9IGVsc2Ug
ewogCQkJLyogU2NoZWR1bGUgYSByZXNwb25zZSBpbW1lZGlhdGVseS4gKi8K
LQkJCXhlbl9uZXRia19pZHhfcmVsZWFzZShuZXRiaywgcGVuZGluZ19pZHgp
OworCQkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lk
eCwgWEVOX05FVElGX1JTUF9PS0FZKTsKIAkJfQogCiAJCWlmICh0eHAtPmZs
YWdzICYgWEVOX05FVFRYRl9jc3VtX2JsYW5rKQpAQCAtMTUyOSw3ICsxNTE2
LDggQEAgc3RhdGljIHZvaWQgeGVuX25ldGJrX3R4X2FjdGlvbihzdHJ1Y3Qg
eGVuX25ldGJrICpuZXRiaykKIAl4ZW5fbmV0YmtfdHhfc3VibWl0KG5ldGJr
KTsKIH0KIAotc3RhdGljIHZvaWQgeGVuX25ldGJrX2lkeF9yZWxlYXNlKHN0
cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCB1MTYgcGVuZGluZ19pZHgpCitzdGF0
aWMgdm9pZCB4ZW5fbmV0YmtfaWR4X3JlbGVhc2Uoc3RydWN0IHhlbl9uZXRi
ayAqbmV0YmssIHUxNiBwZW5kaW5nX2lkeCwKKwkJCQkgIHU4IHN0YXR1cykK
IHsKIAlzdHJ1Y3QgeGVudmlmICp2aWY7CiAJc3RydWN0IHBlbmRpbmdfdHhf
aW5mbyAqcGVuZGluZ190eF9pbmZvOwpAQCAtMTU0Myw3ICsxNTMxLDcgQEAg
c3RhdGljIHZvaWQgeGVuX25ldGJrX2lkeF9yZWxlYXNlKHN0cnVjdCB4ZW5f
bmV0YmsgKm5ldGJrLCB1MTYgcGVuZGluZ19pZHgpCiAKIAl2aWYgPSBwZW5k
aW5nX3R4X2luZm8tPnZpZjsKIAotCW1ha2VfdHhfcmVzcG9uc2UodmlmLCAm
cGVuZGluZ190eF9pbmZvLT5yZXEsIFhFTl9ORVRJRl9SU1BfT0tBWSk7CisJ
bWFrZV90eF9yZXNwb25zZSh2aWYsICZwZW5kaW5nX3R4X2luZm8tPnJlcSwg
c3RhdHVzKTsKIAogCWluZGV4ID0gcGVuZGluZ19pbmRleChuZXRiay0+cGVu
ZGluZ19wcm9kKyspOwogCW5ldGJrLT5wZW5kaW5nX3JpbmdbaW5kZXhdID0g
cGVuZGluZ19pZHg7Ci0tIAoxLjcuMi41Cgo=

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0003-xen-netback-free-already-allocated-memory-on-failure.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0003-xen-netback-free-already-allocated-memory-on-failure.patch"
Content-Transfer-Encoding: base64

RnJvbSBiNmIxZjE3YWE0NGFjZmUxMDI0OTY4YmFmYjFkMWZlNzcwNGE3NDlh
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBNb24sIDE0IEphbiAy
MDEzIDEyOjUxOjIyICswMDAwClN1YmplY3Q6IFtQQVRDSCAzLzRdIHhlbi9u
ZXRiYWNrOiBmcmVlIGFscmVhZHkgYWxsb2NhdGVkIG1lbW9yeSBvbiBmYWls
dXJlIGluIHhlbl9uZXRia19nZXRfcmVxdWVzdHMKClNpZ25lZC1vZmYtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ci0tLQog
ZHJpdmVycy9uZXQveGVuLW5ldGJhY2svbmV0YmFjay5jIHwgICAxNiArKysr
KysrKysrKysrKystCiAxIGZpbGVzIGNoYW5nZWQsIDE1IGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jIGIvZHJpdmVycy9uZXQveGVuLW5ldGJh
Y2svbmV0YmFjay5jCmluZGV4IDk3NTI0MWUuLjFhOTkyODggMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYworKysgYi9k
cml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKQEAgLTk3OCw3ICs5
NzgsNyBAQCBzdGF0aWMgc3RydWN0IGdudHRhYl9jb3B5ICp4ZW5fbmV0Ymtf
Z2V0X3JlcXVlc3RzKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLAogCQlwZW5k
aW5nX2lkeCA9IG5ldGJrLT5wZW5kaW5nX3JpbmdbaW5kZXhdOwogCQlwYWdl
ID0geGVuX25ldGJrX2FsbG9jX3BhZ2UobmV0YmssIHNrYiwgcGVuZGluZ19p
ZHgpOwogCQlpZiAoIXBhZ2UpCi0JCQlyZXR1cm4gTlVMTDsKKwkJCWdvdG8g
ZXJyOwogCiAJCWdvcC0+c291cmNlLnUucmVmID0gdHhwLT5ncmVmOwogCQln
b3AtPnNvdXJjZS5kb21pZCA9IHZpZi0+ZG9taWQ7CkBAIC0xMDAwLDYgKzEw
MDAsMjAgQEAgc3RhdGljIHN0cnVjdCBnbnR0YWJfY29weSAqeGVuX25ldGJr
X2dldF9yZXF1ZXN0cyhzdHJ1Y3QgeGVuX25ldGJrICpuZXRiaywKIAl9CiAK
IAlyZXR1cm4gZ29wOworZXJyOgorCS8qCisJICogVW53aW5kLCBmcmVlaW5n
IGFsbCBwYWdlcyBhbmQgc2VuZGluZyBlcnJvcgorCSAqIHJlcG9uc2VzLgor
CSAqLworCXdoaWxlIChpLS0gPiBzdGFydCkgeworCQl4ZW5fbmV0YmtfaWR4
X3JlbGVhc2UobmV0YmssIGZyYWdfZ2V0X3BlbmRpbmdfaWR4KCZmcmFnc1tp
XSksCisJCQkJICAgICAgWEVOX05FVElGX1JTUF9FUlJPUik7CisJfQorCS8q
IFRoZSBoZWFkIHRvbywgaWYgbmVjZXNzYXJ5LiAqLworCWlmIChzdGFydCkK
KwkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lkeCwg
WEVOX05FVElGX1JTUF9FUlJPUik7CisKKwlyZXR1cm4gTlVMTDsKIH0KIAog
c3RhdGljIGludCB4ZW5fbmV0YmtfdHhfY2hlY2tfZ29wKHN0cnVjdCB4ZW5f
bmV0YmsgKm5ldGJrLAotLSAKMS43LjIuNQoK

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0004-netback-correct-netbk_tx_err-to-handle-wrap-around.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0004-netback-correct-netbk_tx_err-to-handle-wrap-around.patch"
Content-Transfer-Encoding: base64

RnJvbSBlYTVlM2MxZThmZDlmZmU2MDgwZTAxYWY3NzY5YTlmYTQyMGNjNjJl
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBNb24sIDE0IEphbiAy
MDEzIDEzOjMyOjMxICswMDAwClN1YmplY3Q6IFtQQVRDSCA0LzRdIG5ldGJh
Y2s6IGNvcnJlY3QgbmV0YmtfdHhfZXJyIHRvIGhhbmRsZSB3cmFwIGFyb3Vu
ZC4KClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxs
QGNpdHJpeC5jb20+CkFja2VkLWJ5OiBKYW4gQmV1bGljaCA8SkJldWxpY2hA
c3VzZS5jb20+Ci0tLQogZHJpdmVycy9uZXQveGVuLW5ldGJhY2svbmV0YmFj
ay5jIHwgICAgMiArLQogMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jIGIvZHJpdmVycy9uZXQveGVuLW5ldGJh
Y2svbmV0YmFjay5jCmluZGV4IDFhOTkyODguLjI4ZDVlMDYgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYworKysgYi9k
cml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKQEAgLTg4MCw3ICs4
ODAsNyBAQCBzdGF0aWMgdm9pZCBuZXRia190eF9lcnIoc3RydWN0IHhlbnZp
ZiAqdmlmLAogCiAJZG8gewogCQltYWtlX3R4X3Jlc3BvbnNlKHZpZiwgdHhw
LCBYRU5fTkVUSUZfUlNQX0VSUk9SKTsKLQkJaWYgKGNvbnMgPj0gZW5kKQor
CQlpZiAoY29ucyA9PSBlbmQpCiAJCQlicmVhazsKIAkJdHhwID0gUklOR19H
RVRfUkVRVUVTVCgmdmlmLT50eCwgY29ucysrKTsKIAl9IHdoaWxlICgxKTsK
LS0gCjEuNy4yLjUKCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:15:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:15: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 1U2iMz-0007TH-2M; Tue, 05 Feb 2013 13:15:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMx-0007SU-9y; Tue, 05 Feb 2013 13:15:27 +0000
Received: from [85.158.143.99:40548] by server-2.bemta-4.messagelabs.com id
	21/FB-01597-EE501115; Tue, 05 Feb 2013 13:15:26 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360070121!22200145!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27328 invoked from network); 5 Feb 2013 13:15:23 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:23 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMi-0003aO-Bd; Tue, 05 Feb 2013 13:15:12 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMi-0008AG-9I; Tue, 05 Feb 2013 13:15:12 +0000
Date: Tue, 05 Feb 2013 13:15:12 +0000
Message-Id: <E1U2iMi-0008AG-9I@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 39 (CVE-2013-0216,
 CVE-2013-0217) - Linux netback DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

    Xen Security Advisory CVE-2013-0216,CVE-2013-0217 / XSA-39
			      version 2

          Linux netback DoS via malicious guest ring.

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The Xen netback implementation contains a couple of flaws which can
allow a guest to cause a DoS in the backend domain, potentially
affecting other domains in the system.

CVE-2013-0216 is a failure to sanity check the ring producer/consumer
pointers which can allow a guest to cause netback to loop for an
extended period preventing other work from occurring.

CVE-2013-0217 is a memory leak on an error path which is guest
triggerable.

IMPACT
======

A malicious guest can mount a DoS affecting the entire system.

VULNERABLE SYSTEMS
==================

All systems running guests with access to PV network devices are
vulnerable.

CVE-2013-0216 affects both mainline ("pvops") and classic-Xen patch
kernels.

CVE-2013-0217 affects only mainline ("pvops") kernels.

MITIGATION
==========

Running HVM guests with only emulated or passthrough NICs or PV guests
with only passthrough NICs will avoid this vulnerability.

RESOLUTION
==========

Applying the appropriate attached patches in sequence resolves this issue.

xsa39-pvops-*.patch            Apply to mainline Linux 3.8-rc2
xsa39-classic-*.patch          Apply to linux-2.6.18-xen tree.

All patches for the given branch should be applied in numerical order.

$ sha256sum xsa39*.patch
4b75961673b940f5eb31451080dd668b9119eb88db1df44db1a3ba4b0d037ce1  xsa39-classic-0001-xen-netback-garbage-ring.patch
096143750b99eb2d88970338c3f9debfbbfdaef766525a620281b28528ebe0ce  xsa39-classic-0002-xen-netback-wrap-around.patch
99cf93e37985908243b974cc726f57e592e62ae005eca52969f11fb6fdea6fb5  xsa39-pvops-0001-xen-netback-shutdown-the-ring-if-it-contains-garbage.patch
e0c4226b0910ca455f22ae117e8346d87053e9faf03ec155dd6c31e2f58a1969  xsa39-pvops-0002-xen-netback-don-t-leak-pages-on-failure-in-xen_netbk.patch
70e6cb644a57cdda7f29eb86086a8e697706c3fc974a44c52322e451fd6b9d5c  xsa39-pvops-0003-xen-netback-free-already-allocated-memory-on-failure.patch
5d0db59bbd5ad3a7efae78a6c26fc2491b7c553e5519dd946d1422a116af73dd  xsa39-pvops-0004-netback-correct-netbk_tx_err-to-handle-wrap-around.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQI5AAoJEIP+FMlX6CvZLbcIAL7gpD+EzDjb+g3ZlORl1jPV
+icqyDoPWeWructbggY+YcJJc2IavNrRXBSN/9edSTUXSi7YTW+Tjeh8bcLza1JM
McWKxPtJB8CKEIAjAeT8qMVaNUNQuJQTtTLtXHGuQE6xwxK8YmgLzQSx91OOp9Bx
49GK1Ptnp7bQoEoc7B3oN6GXr/hs/FvaD0Cr481yUxXX1GxV+AL7sxXiJ4kXu1rE
UTSLFAzUfw1KWI5wP3GQCREhysCvgIq4mZyD5+TF8MUagpg+m1aURs2AUUxrJ/Zw
o+LVEKWYRsTtWIRtwYOdPHn73bllyPOrBgimTDBM9rY9CztOnN8yoPRlUz0Sux0=
=UhBt
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream;
 name="xsa39-classic-0001-xen-netback-garbage-ring.patch"
Content-Disposition: attachment;
 filename="xsa39-classic-0001-xen-netback-garbage-ring.patch"
Content-Transfer-Encoding: base64

bmV0YmFjazogc2h1dGRvd24gdGhlIHJpbmcgaWYgaXQgY29udGFpbnMgZ2Fy
YmFnZQoKQSBidWdneSBvciBtYWxpY2lvdXMgZnJvbnRlbmQgc2hvdWxkIG5v
dCBiZSBhYmxlIHRvIGNvbmZ1c2UgbmV0YmFjay4KSWYgd2Ugc3BvdCBhbnl0
aGluZyB3aGljaCBpcyBub3QgYXMgaXQgc2hvdWxkIGJlIHRoZW4gc2h1dGRv
d24gdGhlCmRldmljZSBhbmQgZG9uJ3QgdHJ5IHRvIGNvbnRpbnVlIHdpdGgg
dGhlIHJpbmcgaW4gYSBwb3RlbnRpYWxseQpob3N0aWxlIHN0YXRlLiBXZWxs
IGJlaGF2ZWQgYW5kIG5vbi1ob3N0aWxlIGZyb250ZW5kcyB3aWxsIG5vdCBi
ZQpwZW5hbGlzZWQuCgpBcyB3ZWxsIGFzIG1ha2luZyB0aGUgZXhpc3Rpbmcg
Y2hlY2tzIGZvciBzdWNoIGVycm9ycyBmYXRhbCBhbHNvIGFkZCBhCm5ldyBj
aGVjayB0aGF0IGVuc3VyZXMgdGhhdCB0aGVyZSBpc24ndCBhbiBpbnNhbmUg
bnVtYmVyIG9mIHJlcXVlc3RzCm9uIHRoZSByaW5nIChpLmUuIG1vcmUgdGhh
biB3b3VsZCBmaXQgaW4gdGhlIHJpbmcpLiBJZiB0aGUgcmluZwpjb250YWlu
cyBnYXJiYWdlIHRoZW4gcHJldmlvdXNseSBpcyB3YXMgcG9zc2libGUgdG8g
bG9vcCBvdmVyIHRoaXMKaW5zYW5lIG51bWJlciwgZ2V0dGluZyBhbiBlcnJv
ciBlYWNoIHRpbWUgYW5kIHRoZXJlZm9yZSBub3QgZ2VuZXJhdGluZwphbnkg
bW9yZSBwZW5kaW5nIHJlcXVlc3RzIGFuZCB0aGVyZWZvcmUgbm90IGV4aXRp
bmcgdGhlIGxvb3AgaW4KeGVuX25ldGJrX3R4X2J1aWxkX2dvcHMgZm9yIGFu
IGV4dGVybmRlZCBwZXJpb2QuCgpBbHNvIHR1cm4gdmFyaW91cyBuZXRkZXZf
ZGJnIGNhbGxzIHdoaWNoIG5vIHByZWNpcGl0YXRlIGEgZmF0YWwgZXJyb3IK
aW50byBuZXRkZXZfZXJyLCB0aGV5IGFyZSByYXRlIGxpbWl0ZWQgYmVjYXVz
ZSB0aGUgZGV2aWNlIGlzIHNodXRkb3duCmFmdGVyd2FyZHMuCgpUaGlzIGZp
eGVzIGF0IGxlYXN0IG9uZSBrbm93biBEb1Mvc29mdGxvY2t1cCBvZiB0aGUg
YmFja2VuZCBkb21haW4uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8SkJldWxpY2hAc3VzZS5jb20+CgotLS0gYS9kcml2ZXJzL3hl
bi9uZXRiYWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMveGVuL25ldGJhY2sv
Y29tbW9uLmgKQEAgLTIwNCw2ICsyMDQsOSBAQCBpbnQgbmV0aWZfYmVfc3Rh
cnRfeG1pdChzdHJ1Y3Qgc2tfYnVmZiAqCiBzdHJ1Y3QgbmV0X2RldmljZV9z
dGF0cyAqbmV0aWZfYmVfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICpk
ZXYpOwogaXJxcmV0dXJuX3QgbmV0aWZfYmVfaW50KGludCBpcnEsIHZvaWQg
KmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpOwogCisvKiBQcmV2ZW50
IHRoZSBkZXZpY2UgZnJvbSBnZW5lcmF0aW5nIGFueSBmdXJ0aGVyIHRyYWZm
aWMuICovCit2b2lkIHhlbnZpZl9jYXJyaWVyX29mZihuZXRpZl90ICpuZXRp
Zik7CisKIHN0YXRpYyBpbmxpbmUgaW50IG5ldGJrX2Nhbl9xdWV1ZShzdHJ1
Y3QgbmV0X2RldmljZSAqZGV2KQogewogCW5ldGlmX3QgKm5ldGlmID0gbmV0
ZGV2X3ByaXYoZGV2KTsKLS0tIGEvZHJpdmVycy94ZW4vbmV0YmFjay9pbnRl
cmZhY2UuYworKysgYi9kcml2ZXJzL3hlbi9uZXRiYWNrL2ludGVyZmFjZS5j
CkBAIC0zNDcsMTkgKzM0NywyMyBAQCBlcnJfcng6CiAJcmV0dXJuIGVycjsK
IH0KIAordm9pZCB4ZW52aWZfY2Fycmllcl9vZmYobmV0aWZfdCAqbmV0aWYp
Cit7CisJcnRubF9sb2NrKCk7CisJbmV0YmFja19jYXJyaWVyX29mZihuZXRp
Zik7CisJbmV0aWZfY2Fycmllcl9vZmYobmV0aWYtPmRldik7IC8qIGRpc2Nh
cmQgcXVldWVkIHBhY2tldHMgKi8KKwlpZiAobmV0aWZfcnVubmluZyhuZXRp
Zi0+ZGV2KSkKKwkJX19uZXRpZl9kb3duKG5ldGlmKTsKKwlydG5sX3VubG9j
aygpOworCW5ldGlmX3B1dChuZXRpZik7Cit9CisKIHZvaWQgbmV0aWZfZGlz
Y29ubmVjdChzdHJ1Y3QgYmFja2VuZF9pbmZvICpiZSkKIHsKIAluZXRpZl90
ICpuZXRpZiA9IGJlLT5uZXRpZjsKIAotCWlmIChuZXRiYWNrX2NhcnJpZXJf
b2sobmV0aWYpKSB7Ci0JCXJ0bmxfbG9jaygpOwotCQluZXRiYWNrX2NhcnJp
ZXJfb2ZmKG5ldGlmKTsKLQkJbmV0aWZfY2Fycmllcl9vZmYobmV0aWYtPmRl
dik7IC8qIGRpc2NhcmQgcXVldWVkIHBhY2tldHMgKi8KLQkJaWYgKG5ldGlm
X3J1bm5pbmcobmV0aWYtPmRldikpCi0JCQlfX25ldGlmX2Rvd24obmV0aWYp
OwotCQlydG5sX3VubG9jaygpOwotCQluZXRpZl9wdXQobmV0aWYpOwotCX0K
KwlpZiAobmV0YmFja19jYXJyaWVyX29rKG5ldGlmKSkKKwkJeGVudmlmX2Nh
cnJpZXJfb2ZmKG5ldGlmKTsKIAogCWF0b21pY19kZWMoJm5ldGlmLT5yZWZj
bnQpOwogCXdhaXRfZXZlbnQobmV0aWYtPndhaXRpbmdfdG9fZnJlZSwgYXRv
bWljX3JlYWQoJm5ldGlmLT5yZWZjbnQpID09IDApOwotLS0gYS9kcml2ZXJz
L3hlbi9uZXRiYWNrL25ldGJhY2suYworKysgYi9kcml2ZXJzL3hlbi9uZXRi
YWNrL25ldGJhY2suYwpAQCAtMTAyMCw2ICsxMDIwLDE0IEBAIHN0YXRpYyB2
b2lkIG5ldGJrX3R4X2VycihuZXRpZl90ICpuZXRpZiwKIAluZXRpZl9wdXQo
bmV0aWYpOwogfQogCitzdGF0aWMgdm9pZCBuZXRia19mYXRhbF90eF9lcnIo
bmV0aWZfdCAqbmV0aWYpCit7CisJcHJpbnRrKEtFUk5fRVJSICIlczogZmF0
YWwgZXJyb3I7IGRpc2FibGluZyBkZXZpY2VcbiIsCisJICAgICAgIG5ldGlm
LT5kZXYtPm5hbWUpOworCXhlbnZpZl9jYXJyaWVyX29mZihuZXRpZik7CisJ
bmV0aWZfcHV0KG5ldGlmKTsKK30KKwogc3RhdGljIGludCBuZXRia19jb3Vu
dF9yZXF1ZXN0cyhuZXRpZl90ICpuZXRpZiwgbmV0aWZfdHhfcmVxdWVzdF90
ICpmaXJzdCwKIAkJCQluZXRpZl90eF9yZXF1ZXN0X3QgKnR4cCwgaW50IHdv
cmtfdG9fZG8pCiB7CkBAIC0xMDMxLDE5ICsxMDM5LDI1IEBAIHN0YXRpYyBp
bnQgbmV0YmtfY291bnRfcmVxdWVzdHMobmV0aWZfdCAKIAogCWRvIHsKIAkJ
aWYgKGZyYWdzID49IHdvcmtfdG9fZG8pIHsKLQkJCURQUklOVEsoIk5lZWQg
bW9yZSBmcmFnc1xuIik7CisJCQlwcmludGsoS0VSTl9FUlIgIiVzOiBOZWVk
IG1vcmUgZnJhZ3NcbiIsCisJCQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSk7
CisJCQluZXRia19mYXRhbF90eF9lcnIobmV0aWYpOwogCQkJcmV0dXJuIC1m
cmFnczsKIAkJfQogCiAJCWlmICh1bmxpa2VseShmcmFncyA+PSBNQVhfU0tC
X0ZSQUdTKSkgewotCQkJRFBSSU5USygiVG9vIG1hbnkgZnJhZ3NcbiIpOwor
CQkJcHJpbnRrKEtFUk5fRVJSICIlczogVG9vIG1hbnkgZnJhZ3NcbiIsCisJ
CQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSk7CisJCQluZXRia19mYXRhbF90
eF9lcnIobmV0aWYpOwogCQkJcmV0dXJuIC1mcmFnczsKIAkJfQogCiAJCW1l
bWNweSh0eHAsIFJJTkdfR0VUX1JFUVVFU1QoJm5ldGlmLT50eCwgY29ucyAr
IGZyYWdzKSwKIAkJICAgICAgIHNpemVvZigqdHhwKSk7CiAJCWlmICh0eHAt
PnNpemUgPiBmaXJzdC0+c2l6ZSkgewotCQkJRFBSSU5USygiRnJhZ3MgZ2Fs
b3JlXG4iKTsKKwkJCXByaW50ayhLRVJOX0VSUiAiJXM6IEZyYWcgaXMgYmln
Z2VyIHRoYW4gZnJhbWUuXG4iLAorCQkJICAgICAgIG5ldGlmLT5kZXYtPm5h
bWUpOworCQkJbmV0YmtfZmF0YWxfdHhfZXJyKG5ldGlmKTsKIAkJCXJldHVy
biAtZnJhZ3M7CiAJCX0KIApAQCAtMTA1MSw4ICsxMDY1LDkgQEAgc3RhdGlj
IGludCBuZXRia19jb3VudF9yZXF1ZXN0cyhuZXRpZl90IAogCQlmcmFncysr
OwogCiAJCWlmICh1bmxpa2VseSgodHhwLT5vZmZzZXQgKyB0eHAtPnNpemUp
ID4gUEFHRV9TSVpFKSkgewotCQkJRFBSSU5USygidHhwLT5vZmZzZXQ6ICV4
LCBzaXplOiAldVxuIiwKLQkJCQl0eHAtPm9mZnNldCwgdHhwLT5zaXplKTsK
KwkJCXByaW50ayhLRVJOX0VSUiAiJXM6IHR4cC0+b2Zmc2V0OiAleCwgc2l6
ZTogJXVcbiIsCisJCQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSwgdHhwLT5v
ZmZzZXQsIHR4cC0+c2l6ZSk7CisJCQluZXRia19mYXRhbF90eF9lcnIobmV0
aWYpOwogCQkJcmV0dXJuIC1mcmFnczsKIAkJfQogCX0gd2hpbGUgKCh0eHAr
KyktPmZsYWdzICYgTkVUVFhGX21vcmVfZGF0YSk7CkBAIC0xMTk1LDcgKzEy
MTAsOSBAQCBpbnQgbmV0YmtfZ2V0X2V4dHJhcyhuZXRpZl90ICpuZXRpZiwg
c3RyCiAKIAlkbyB7CiAJCWlmICh1bmxpa2VseSh3b3JrX3RvX2RvLS0gPD0g
MCkpIHsKLQkJCURQUklOVEsoIk1pc3NpbmcgZXh0cmEgaW5mb1xuIik7CisJ
CQlwcmludGsoS0VSTl9FUlIgIiVzOiBNaXNzaW5nIGV4dHJhIGluZm9cbiIs
CisJCQkgICAgICAgbmV0aWYtPmRldi0+bmFtZSk7CisJCQluZXRia19mYXRh
bF90eF9lcnIobmV0aWYpOwogCQkJcmV0dXJuIC1FQkFEUjsKIAkJfQogCkBA
IC0xMjA0LDcgKzEyMjEsOSBAQCBpbnQgbmV0YmtfZ2V0X2V4dHJhcyhuZXRp
Zl90ICpuZXRpZiwgc3RyCiAJCWlmICh1bmxpa2VseSghZXh0cmEudHlwZSB8
fAogCQkJICAgICBleHRyYS50eXBlID49IFhFTl9ORVRJRl9FWFRSQV9UWVBF
X01BWCkpIHsKIAkJCW5ldGlmLT50eC5yZXFfY29ucyA9ICsrY29uczsKLQkJ
CURQUklOVEsoIkludmFsaWQgZXh0cmEgdHlwZTogJWRcbiIsIGV4dHJhLnR5
cGUpOworCQkJcHJpbnRrKEtFUk5fRVJSICIlczogSW52YWxpZCBleHRyYSB0
eXBlOiAlZFxuIiwKKwkJCSAgICAgICBuZXRpZi0+ZGV2LT5uYW1lLCBleHRy
YS50eXBlKTsKKwkJCW5ldGJrX2ZhdGFsX3R4X2VycihuZXRpZik7CiAJCQly
ZXR1cm4gLUVJTlZBTDsKIAkJfQogCkBAIC0xMjE1LDE2ICsxMjM0LDIxIEBA
IGludCBuZXRia19nZXRfZXh0cmFzKG5ldGlmX3QgKm5ldGlmLCBzdHIKIAly
ZXR1cm4gd29ya190b19kbzsKIH0KIAotc3RhdGljIGludCBuZXRia19zZXRf
c2tiX2dzbyhzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0aWZfZXh0
cmFfaW5mbyAqZ3NvKQorc3RhdGljIGludCBuZXRia19zZXRfc2tiX2dzbyhu
ZXRpZl90ICpuZXRpZiwgc3RydWN0IHNrX2J1ZmYgKnNrYiwKKwkJCSAgICAg
c3RydWN0IG5ldGlmX2V4dHJhX2luZm8gKmdzbykKIHsKIAlpZiAoIWdzby0+
dS5nc28uc2l6ZSkgewotCQlEUFJJTlRLKCJHU08gc2l6ZSBtdXN0IG5vdCBi
ZSB6ZXJvLlxuIik7CisJCXByaW50ayhLRVJOX0VSUiAiJXM6IEdTTyBzaXpl
IG11c3Qgbm90IGJlIHplcm8uXG4iLAorCQkgICAgICAgbmV0aWYtPmRldi0+
bmFtZSk7CisJCW5ldGJrX2ZhdGFsX3R4X2VycihuZXRpZik7CiAJCXJldHVy
biAtRUlOVkFMOwogCX0KIAogCS8qIEN1cnJlbnRseSBvbmx5IFRDUHY0IFMu
Ty4gaXMgc3VwcG9ydGVkLiAqLwogCWlmIChnc28tPnUuZ3NvLnR5cGUgIT0g
WEVOX05FVElGX0dTT19UWVBFX1RDUFY0KSB7Ci0JCURQUklOVEsoIkJhZCBH
U08gdHlwZSAlZC5cbiIsIGdzby0+dS5nc28udHlwZSk7CisJCXByaW50ayhL
RVJOX0VSUiAiJXM6IEJhZCBHU08gdHlwZSAlZC5cbiIsCisJCSAgICAgICBu
ZXRpZi0+ZGV2LT5uYW1lLCBnc28tPnUuZ3NvLnR5cGUpOworCQluZXRia19m
YXRhbF90eF9lcnIobmV0aWYpOwogCQlyZXR1cm4gLUVJTlZBTDsKIAl9CiAK
QEAgLTEyNTksOSArMTI4MywyNSBAQCBzdGF0aWMgdm9pZCBuZXRfdHhfYWN0
aW9uKHVuc2lnbmVkIGxvbmcgCiAJCSFsaXN0X2VtcHR5KCZuZXRfc2NoZWR1
bGVfbGlzdCkpIHsKIAkJLyogR2V0IGEgbmV0aWYgZnJvbSB0aGUgbGlzdCB3
aXRoIHdvcmsgdG8gZG8uICovCiAJCW5ldGlmID0gcG9sbF9uZXRfc2NoZWR1
bGVfbGlzdCgpOworCQkvKgorCQkgKiBUaGlzIGNhbiBzb21ldGltZXMgaGFw
cGVuIGJlY2F1c2UgdGhlIHRlc3Qgb2YKKwkJICogbGlzdF9lbXB0eShuZXRf
c2NoZWR1bGVfbGlzdCkgYXQgdGhlIHRvcCBvZiB0aGUKKwkJICogbG9vcCBp
cyB1bmxvY2tlZC4gIEp1c3QgZ28gYmFjayBhbmQgaGF2ZSBhbm90aGVyCisJ
CSAqIGxvb2suCisJCSAqLwogCQlpZiAoIW5ldGlmKQogCQkJY29udGludWU7
CiAKKwkJaWYgKG5ldGlmLT50eC5zcmluZy0+cmVxX3Byb2QgLSBuZXRpZi0+
dHgucmVxX2NvbnMgPgorCQkgICAgTkVUX1RYX1JJTkdfU0laRSkgeworCQkJ
cHJpbnRrKEtFUk5fRVJSICIlczogSW1wb3NzaWJsZSBudW1iZXIgb2YgcmVx
dWVzdHMuICIKKwkJCSAgICAgICAicmVxX3Byb2QgJXUsIHJlcV9jb25zICV1
LCBzaXplICVsdVxuIiwKKwkJCSAgICAgICBuZXRpZi0+ZGV2LT5uYW1lLCBu
ZXRpZi0+dHguc3JpbmctPnJlcV9wcm9kLAorCQkJICAgICAgIG5ldGlmLT50
eC5yZXFfY29ucywgTkVUX1RYX1JJTkdfU0laRSk7CisJCQluZXRia19mYXRh
bF90eF9lcnIobmV0aWYpOworCQkJY29udGludWU7CisJCX0KKwogCQlSSU5H
X0ZJTkFMX0NIRUNLX0ZPUl9SRVFVRVNUUygmbmV0aWYtPnR4LCB3b3JrX3Rv
X2RvKTsKIAkJaWYgKCF3b3JrX3RvX2RvKSB7CiAJCQluZXRpZl9wdXQobmV0
aWYpOwpAQCAtMTMxMywxNyArMTM1MywxNCBAQCBzdGF0aWMgdm9pZCBuZXRf
dHhfYWN0aW9uKHVuc2lnbmVkIGxvbmcgCiAJCQl3b3JrX3RvX2RvID0gbmV0
YmtfZ2V0X2V4dHJhcyhuZXRpZiwgZXh0cmFzLAogCQkJCQkJICAgICAgd29y
a190b19kbyk7CiAJCQlpID0gbmV0aWYtPnR4LnJlcV9jb25zOwotCQkJaWYg
KHVubGlrZWx5KHdvcmtfdG9fZG8gPCAwKSkgewotCQkJCW5ldGJrX3R4X2Vy
cihuZXRpZiwgJnR4cmVxLCBpKTsKKwkJCWlmICh1bmxpa2VseSh3b3JrX3Rv
X2RvIDwgMCkpCiAJCQkJY29udGludWU7Ci0JCQl9CiAJCX0KIAogCQlyZXQg
PSBuZXRia19jb3VudF9yZXF1ZXN0cyhuZXRpZiwgJnR4cmVxLCB0eGZyYWdz
LCB3b3JrX3RvX2RvKTsKLQkJaWYgKHVubGlrZWx5KHJldCA8IDApKSB7Ci0J
CQluZXRia190eF9lcnIobmV0aWYsICZ0eHJlcSwgaSAtIHJldCk7CisJCWlm
ICh1bmxpa2VseShyZXQgPCAwKSkKIAkJCWNvbnRpbnVlOwotCQl9CisKIAkJ
aSArPSByZXQ7CiAKIAkJaWYgKHVubGlrZWx5KHR4cmVxLnNpemUgPCBFVEhf
SExFTikpIHsKQEAgLTEzMzQsMTAgKzEzNzEsMTAgQEAgc3RhdGljIHZvaWQg
bmV0X3R4X2FjdGlvbih1bnNpZ25lZCBsb25nIAogCiAJCS8qIE5vIGNyb3Nz
aW5nIGEgcGFnZSBhcyB0aGUgcGF5bG9hZCBtdXN0bid0IGZyYWdtZW50LiAq
LwogCQlpZiAodW5saWtlbHkoKHR4cmVxLm9mZnNldCArIHR4cmVxLnNpemUp
ID4gUEFHRV9TSVpFKSkgewotCQkJRFBSSU5USygidHhyZXEub2Zmc2V0OiAl
eCwgc2l6ZTogJXUsIGVuZDogJWx1XG4iLCAKLQkJCQl0eHJlcS5vZmZzZXQs
IHR4cmVxLnNpemUsIAotCQkJCSh0eHJlcS5vZmZzZXQgJn5QQUdFX01BU0sp
ICsgdHhyZXEuc2l6ZSk7Ci0JCQluZXRia190eF9lcnIobmV0aWYsICZ0eHJl
cSwgaSk7CisJCQlwcmludGsoS0VSTl9FUlIgIiVzOiB0eHJlcS5vZmZzZXQ6
ICV4LCBzaXplOiAldSwgZW5kOiAlbHVcbiIsCisJCQkgICAgICAgbmV0aWYt
PmRldi0+bmFtZSwgdHhyZXEub2Zmc2V0LCB0eHJlcS5zaXplLAorCQkJICAg
ICAgICh0eHJlcS5vZmZzZXQgJiB+UEFHRV9NQVNLKSArIHR4cmVxLnNpemUp
OworCQkJbmV0YmtfZmF0YWxfdHhfZXJyKG5ldGlmKTsKIAkJCWNvbnRpbnVl
OwogCQl9CiAKQEAgLTEzNjIsOSArMTM5OSw5IEBAIHN0YXRpYyB2b2lkIG5l
dF90eF9hY3Rpb24odW5zaWduZWQgbG9uZyAKIAkJCXN0cnVjdCBuZXRpZl9l
eHRyYV9pbmZvICpnc287CiAJCQlnc28gPSAmZXh0cmFzW1hFTl9ORVRJRl9F
WFRSQV9UWVBFX0dTTyAtIDFdOwogCi0JCQlpZiAobmV0Ymtfc2V0X3NrYl9n
c28oc2tiLCBnc28pKSB7CisJCQlpZiAobmV0Ymtfc2V0X3NrYl9nc28obmV0
aWYsIHNrYiwgZ3NvKSkgeworCQkJCS8qIEZhaWx1cmUgaW4gbmV0Ymtfc2V0
X3NrYl9nc28gaXMgZmF0YWwuICovCiAJCQkJa2ZyZWVfc2tiKHNrYik7Ci0J
CQkJbmV0YmtfdHhfZXJyKG5ldGlmLCAmdHhyZXEsIGkpOwogCQkJCWNvbnRp
bnVlOwogCQkJfQogCQl9Cg==

--=separator
Content-Type: application/octet-stream;
 name="xsa39-classic-0002-xen-netback-wrap-around.patch"
Content-Disposition: attachment;
 filename="xsa39-classic-0002-xen-netback-wrap-around.patch"
Content-Transfer-Encoding: base64

bmV0YmFjazogY29ycmVjdCBuZXRia190eF9lcnIoKSB0byBoYW5kbGUgd3Jh
cCBhcm91bmQKClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNh
bXBiZWxsQGNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNo
IDxKQmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL2RyaXZlcnMveGVuL25ldGJh
Y2svbmV0YmFjay5jCisrKyBiL2RyaXZlcnMveGVuL25ldGJhY2svbmV0YmFj
ay5jCkBAIC0xMDExLDcgKzEwMTEsNyBAQCBzdGF0aWMgdm9pZCBuZXRia190
eF9lcnIobmV0aWZfdCAqbmV0aWYsCiAKIAlkbyB7CiAJCW1ha2VfdHhfcmVz
cG9uc2UobmV0aWYsIHR4cCwgTkVUSUZfUlNQX0VSUk9SKTsKLQkJaWYgKGNv
bnMgPj0gZW5kKQorCQlpZiAoY29ucyA9PSBlbmQpCiAJCQlicmVhazsKIAkJ
dHhwID0gUklOR19HRVRfUkVRVUVTVCgmbmV0aWYtPnR4LCBjb25zKyspOwog
CX0gd2hpbGUgKDEpOwo=

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0001-xen-netback-shutdown-the-ring-if-it-contains-garbage.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0001-xen-netback-shutdown-the-ring-if-it-contains-garbage.patch"
Content-Transfer-Encoding: base64

RnJvbSA3ZGQ3Y2U0NDU5M2E4YzRjNzE1ZmE2NjUwMjdhZjhlMDcyNDVjOGNm
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBGcmksIDExIEphbiAy
MDEzIDE0OjI2OjI5ICswMDAwClN1YmplY3Q6IFtQQVRDSCAxLzRdIHhlbi9u
ZXRiYWNrOiBzaHV0ZG93biB0aGUgcmluZyBpZiBpdCBjb250YWlucyBnYXJi
YWdlLgoKQSBidWdneSBvciBtYWxpY2lvdXMgZnJvbnRlbmQgc2hvdWxkIG5v
dCBiZSBhYmxlIHRvIGNvbmZ1c2UgbmV0YmFjay4KSWYgd2Ugc3BvdCBhbnl0
aGluZyB3aGljaCBpcyBub3QgYXMgaXQgc2hvdWxkIGJlIHRoZW4gc2h1dGRv
d24gdGhlCmRldmljZSBhbmQgZG9uJ3QgdHJ5IHRvIGNvbnRpbnVlIHdpdGgg
dGhlIHJpbmcgaW4gYSBwb3RlbnRpYWxseQpob3N0aWxlIHN0YXRlLiBXZWxs
IGJlaGF2ZWQgYW5kIG5vbi1ob3N0aWxlIGZyb250ZW5kcyB3aWxsIG5vdCBi
ZQpwZW5hbGlzZWQuCgpBcyB3ZWxsIGFzIG1ha2luZyB0aGUgZXhpc3Rpbmcg
Y2hlY2tzIGZvciBzdWNoIGVycm9ycyBmYXRhbCBhbHNvIGFkZCBhCm5ldyBj
aGVjayB0aGF0IGVuc3VyZXMgdGhhdCB0aGVyZSBpc24ndCBhbiBpbnNhbmUg
bnVtYmVyIG9mIHJlcXVlc3RzCm9uIHRoZSByaW5nIChpLmUuIG1vcmUgdGhh
biB3b3VsZCBmaXQgaW4gdGhlIHJpbmcpLiBJZiB0aGUgcmluZwpjb250YWlu
cyBnYXJiYWdlIHRoZW4gcHJldmlvdXNseSBpcyB3YXMgcG9zc2libGUgdG8g
bG9vcCBvdmVyIHRoaXMKaW5zYW5lIG51bWJlciwgZ2V0dGluZyBhbiBlcnJv
ciBlYWNoIHRpbWUgYW5kIHRoZXJlZm9yZSBub3QgZ2VuZXJhdGluZwphbnkg
bW9yZSBwZW5kaW5nIHJlcXVlc3RzIGFuZCB0aGVyZWZvcmUgbm90IGV4aXRp
bmcgdGhlIGxvb3AgaW4KeGVuX25ldGJrX3R4X2J1aWxkX2dvcHMgZm9yIGFu
IGV4dGVybmRlZCBwZXJpb2QuCgpBbHNvIHR1cm4gdmFyaW91cyBuZXRkZXZf
ZGJnIGNhbGxzIHdoaWNoIG5vIHByZWNpcGl0YXRlIGEgZmF0YWwgZXJyb3IK
aW50byBuZXRkZXZfZXJyLCB0aGV5IGFyZSByYXRlIGxpbWl0ZWQgYmVjYXVz
ZSB0aGUgZGV2aWNlIGlzIHNodXRkb3duCmFmdGVyd2FyZHMuCgpUaGlzIGZp
eGVzIGF0IGxlYXN0IG9uZSBrbm93biBEb1Mvc29mdGxvY2t1cCBvZiB0aGUg
YmFja2VuZCBkb21haW4uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogS29ucmFk
IFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpBY2tl
ZC1ieTogSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPgotLS0KIGRy
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oICAgIHwgICAgMyArKwog
ZHJpdmVycy9uZXQveGVuLW5ldGJhY2svaW50ZXJmYWNlLmMgfCAgIDIzICsr
KysrKysrLS0tLS0KIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2su
YyAgIHwgICA2MyArKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t
CiAzIGZpbGVzIGNoYW5nZWQsIDYzIGluc2VydGlvbnMoKyksIDI2IGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNr
L2NvbW1vbi5oIGIvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svY29tbW9uLmgK
aW5kZXggOTRiNzljMy4uOWQ3ZjE3MiAxMDA2NDQKLS0tIGEvZHJpdmVycy9u
ZXQveGVuLW5ldGJhY2svY29tbW9uLmgKKysrIGIvZHJpdmVycy9uZXQveGVu
LW5ldGJhY2svY29tbW9uLmgKQEAgLTE1MSw2ICsxNTEsOSBAQCB2b2lkIHhl
bl9uZXRia19xdWV1ZV90eF9za2Ioc3RydWN0IHhlbnZpZiAqdmlmLCBzdHJ1
Y3Qgc2tfYnVmZiAqc2tiKTsKIC8qIE5vdGlmeSB4ZW52aWYgdGhhdCByaW5n
IG5vdyBoYXMgc3BhY2UgdG8gc2VuZCBhbiBza2IgdG8gdGhlIGZyb250ZW5k
ICovCiB2b2lkIHhlbnZpZl9ub3RpZnlfdHhfY29tcGxldGlvbihzdHJ1Y3Qg
eGVudmlmICp2aWYpOwogCisvKiBQcmV2ZW50IHRoZSBkZXZpY2UgZnJvbSBn
ZW5lcmF0aW5nIGFueSBmdXJ0aGVyIHRyYWZmaWMuICovCit2b2lkIHhlbnZp
Zl9jYXJyaWVyX29mZihzdHJ1Y3QgeGVudmlmICp2aWYpOworCiAvKiBSZXR1
cm5zIG51bWJlciBvZiByaW5nIHNsb3RzIHJlcXVpcmVkIHRvIHNlbmQgYW4g
c2tiIHRvIHRoZSBmcm9udGVuZCAqLwogdW5zaWduZWQgaW50IHhlbl9uZXRi
a19jb3VudF9za2Jfc2xvdHMoc3RydWN0IHhlbnZpZiAqdmlmLCBzdHJ1Y3Qg
c2tfYnVmZiAqc2tiKTsKIApkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQveGVu
LW5ldGJhY2svaW50ZXJmYWNlLmMgYi9kcml2ZXJzL25ldC94ZW4tbmV0YmFj
ay9pbnRlcmZhY2UuYwppbmRleCBiN2Q0MWY4Li5iOGM1MTkzIDEwMDY0NAot
LS0gYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9pbnRlcmZhY2UuYworKysg
Yi9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9pbnRlcmZhY2UuYwpAQCAtMzQz
LDE3ICszNDMsMjIgQEAgZXJyOgogCXJldHVybiBlcnI7CiB9CiAKLXZvaWQg
eGVudmlmX2Rpc2Nvbm5lY3Qoc3RydWN0IHhlbnZpZiAqdmlmKQordm9pZCB4
ZW52aWZfY2Fycmllcl9vZmYoc3RydWN0IHhlbnZpZiAqdmlmKQogewogCXN0
cnVjdCBuZXRfZGV2aWNlICpkZXYgPSB2aWYtPmRldjsKLQlpZiAobmV0aWZf
Y2Fycmllcl9vayhkZXYpKSB7Ci0JCXJ0bmxfbG9jaygpOwotCQluZXRpZl9j
YXJyaWVyX29mZihkZXYpOyAvKiBkaXNjYXJkIHF1ZXVlZCBwYWNrZXRzICov
Ci0JCWlmIChuZXRpZl9ydW5uaW5nKGRldikpCi0JCQl4ZW52aWZfZG93bih2
aWYpOwotCQlydG5sX3VubG9jaygpOwotCQl4ZW52aWZfcHV0KHZpZik7Ci0J
fQorCisJcnRubF9sb2NrKCk7CisJbmV0aWZfY2Fycmllcl9vZmYoZGV2KTsg
LyogZGlzY2FyZCBxdWV1ZWQgcGFja2V0cyAqLworCWlmIChuZXRpZl9ydW5u
aW5nKGRldikpCisJCXhlbnZpZl9kb3duKHZpZik7CisJcnRubF91bmxvY2so
KTsKKwl4ZW52aWZfcHV0KHZpZik7Cit9CisKK3ZvaWQgeGVudmlmX2Rpc2Nv
bm5lY3Qoc3RydWN0IHhlbnZpZiAqdmlmKQoreworCWlmIChuZXRpZl9jYXJy
aWVyX29rKHZpZi0+ZGV2KSkKKwkJeGVudmlmX2NhcnJpZXJfb2ZmKHZpZik7
CiAKIAlhdG9taWNfZGVjKCZ2aWYtPnJlZmNudCk7CiAJd2FpdF9ldmVudCh2
aWYtPndhaXRpbmdfdG9fZnJlZSwgYXRvbWljX3JlYWQoJnZpZi0+cmVmY250
KSA9PSAwKTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNr
L25ldGJhY2suYyBiL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2su
YwppbmRleCBmMmQ2Yjc4Li4xYTQ0OWY5IDEwMDY0NAotLS0gYS9kcml2ZXJz
L25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKKysrIGIvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jCkBAIC04ODgsNiArODg4LDEzIEBAIHN0
YXRpYyB2b2lkIG5ldGJrX3R4X2VycihzdHJ1Y3QgeGVudmlmICp2aWYsCiAJ
eGVudmlmX3B1dCh2aWYpOwogfQogCitzdGF0aWMgdm9pZCBuZXRia19mYXRh
bF90eF9lcnIoc3RydWN0IHhlbnZpZiAqdmlmKQoreworCW5ldGRldl9lcnIo
dmlmLT5kZXYsICJmYXRhbCBlcnJvcjsgZGlzYWJsaW5nIGRldmljZVxuIik7
CisJeGVudmlmX2NhcnJpZXJfb2ZmKHZpZik7CisJeGVudmlmX3B1dCh2aWYp
OworfQorCiBzdGF0aWMgaW50IG5ldGJrX2NvdW50X3JlcXVlc3RzKHN0cnVj
dCB4ZW52aWYgKnZpZiwKIAkJCQlzdHJ1Y3QgeGVuX25ldGlmX3R4X3JlcXVl
c3QgKmZpcnN0LAogCQkJCXN0cnVjdCB4ZW5fbmV0aWZfdHhfcmVxdWVzdCAq
dHhwLApAQCAtOTAxLDE5ICs5MDgsMjIgQEAgc3RhdGljIGludCBuZXRia19j
b3VudF9yZXF1ZXN0cyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAKIAlkbyB7CiAJ
CWlmIChmcmFncyA+PSB3b3JrX3RvX2RvKSB7Ci0JCQluZXRkZXZfZGJnKHZp
Zi0+ZGV2LCAiTmVlZCBtb3JlIGZyYWdzXG4iKTsKKwkJCW5ldGRldl9lcnIo
dmlmLT5kZXYsICJOZWVkIG1vcmUgZnJhZ3NcbiIpOworCQkJbmV0YmtfZmF0
YWxfdHhfZXJyKHZpZik7CiAJCQlyZXR1cm4gLWZyYWdzOwogCQl9CiAKIAkJ
aWYgKHVubGlrZWx5KGZyYWdzID49IE1BWF9TS0JfRlJBR1MpKSB7Ci0JCQlu
ZXRkZXZfZGJnKHZpZi0+ZGV2LCAiVG9vIG1hbnkgZnJhZ3NcbiIpOworCQkJ
bmV0ZGV2X2Vycih2aWYtPmRldiwgIlRvbyBtYW55IGZyYWdzXG4iKTsKKwkJ
CW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYpOwogCQkJcmV0dXJuIC1mcmFnczsK
IAkJfQogCiAJCW1lbWNweSh0eHAsIFJJTkdfR0VUX1JFUVVFU1QoJnZpZi0+
dHgsIGNvbnMgKyBmcmFncyksCiAJCSAgICAgICBzaXplb2YoKnR4cCkpOwog
CQlpZiAodHhwLT5zaXplID4gZmlyc3QtPnNpemUpIHsKLQkJCW5ldGRldl9k
YmcodmlmLT5kZXYsICJGcmFncyBnYWxvcmVcbiIpOworCQkJbmV0ZGV2X2Vy
cih2aWYtPmRldiwgIkZyYWcgaXMgYmlnZ2VyIHRoYW4gZnJhbWUuXG4iKTsK
KwkJCW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYpOwogCQkJcmV0dXJuIC1mcmFn
czsKIAkJfQogCkBAIC05MjEsOCArOTMxLDkgQEAgc3RhdGljIGludCBuZXRi
a19jb3VudF9yZXF1ZXN0cyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAJCWZyYWdz
Kys7CiAKIAkJaWYgKHVubGlrZWx5KCh0eHAtPm9mZnNldCArIHR4cC0+c2l6
ZSkgPiBQQUdFX1NJWkUpKSB7Ci0JCQluZXRkZXZfZGJnKHZpZi0+ZGV2LCAi
dHhwLT5vZmZzZXQ6ICV4LCBzaXplOiAldVxuIiwKKwkJCW5ldGRldl9lcnIo
dmlmLT5kZXYsICJ0eHAtPm9mZnNldDogJXgsIHNpemU6ICV1XG4iLAogCQkJ
CSB0eHAtPm9mZnNldCwgdHhwLT5zaXplKTsKKwkJCW5ldGJrX2ZhdGFsX3R4
X2Vycih2aWYpOwogCQkJcmV0dXJuIC1mcmFnczsKIAkJfQogCX0gd2hpbGUg
KCh0eHArKyktPmZsYWdzICYgWEVOX05FVFRYRl9tb3JlX2RhdGEpOwpAQCAt
MTA5NSw3ICsxMTA2LDggQEAgc3RhdGljIGludCB4ZW5fbmV0YmtfZ2V0X2V4
dHJhcyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAKIAlkbyB7CiAJCWlmICh1bmxp
a2VseSh3b3JrX3RvX2RvLS0gPD0gMCkpIHsKLQkJCW5ldGRldl9kYmcodmlm
LT5kZXYsICJNaXNzaW5nIGV4dHJhIGluZm9cbiIpOworCQkJbmV0ZGV2X2Vy
cih2aWYtPmRldiwgIk1pc3NpbmcgZXh0cmEgaW5mb1xuIik7CisJCQluZXRi
a19mYXRhbF90eF9lcnIodmlmKTsKIAkJCXJldHVybiAtRUJBRFI7CiAJCX0K
IApAQCAtMTEwNCw4ICsxMTE2LDkgQEAgc3RhdGljIGludCB4ZW5fbmV0Ymtf
Z2V0X2V4dHJhcyhzdHJ1Y3QgeGVudmlmICp2aWYsCiAJCWlmICh1bmxpa2Vs
eSghZXh0cmEudHlwZSB8fAogCQkJICAgICBleHRyYS50eXBlID49IFhFTl9O
RVRJRl9FWFRSQV9UWVBFX01BWCkpIHsKIAkJCXZpZi0+dHgucmVxX2NvbnMg
PSArK2NvbnM7Ci0JCQluZXRkZXZfZGJnKHZpZi0+ZGV2LAorCQkJbmV0ZGV2
X2Vycih2aWYtPmRldiwKIAkJCQkgICAiSW52YWxpZCBleHRyYSB0eXBlOiAl
ZFxuIiwgZXh0cmEudHlwZSk7CisJCQluZXRia19mYXRhbF90eF9lcnIodmlm
KTsKIAkJCXJldHVybiAtRUlOVkFMOwogCQl9CiAKQEAgLTExMjEsMTMgKzEx
MzQsMTUgQEAgc3RhdGljIGludCBuZXRia19zZXRfc2tiX2dzbyhzdHJ1Y3Qg
eGVudmlmICp2aWYsCiAJCQkgICAgIHN0cnVjdCB4ZW5fbmV0aWZfZXh0cmFf
aW5mbyAqZ3NvKQogewogCWlmICghZ3NvLT51Lmdzby5zaXplKSB7Ci0JCW5l
dGRldl9kYmcodmlmLT5kZXYsICJHU08gc2l6ZSBtdXN0IG5vdCBiZSB6ZXJv
LlxuIik7CisJCW5ldGRldl9lcnIodmlmLT5kZXYsICJHU08gc2l6ZSBtdXN0
IG5vdCBiZSB6ZXJvLlxuIik7CisJCW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYp
OwogCQlyZXR1cm4gLUVJTlZBTDsKIAl9CiAKIAkvKiBDdXJyZW50bHkgb25s
eSBUQ1B2NCBTLk8uIGlzIHN1cHBvcnRlZC4gKi8KIAlpZiAoZ3NvLT51Lmdz
by50eXBlICE9IFhFTl9ORVRJRl9HU09fVFlQRV9UQ1BWNCkgewotCQluZXRk
ZXZfZGJnKHZpZi0+ZGV2LCAiQmFkIEdTTyB0eXBlICVkLlxuIiwgZ3NvLT51
Lmdzby50eXBlKTsKKwkJbmV0ZGV2X2Vycih2aWYtPmRldiwgIkJhZCBHU08g
dHlwZSAlZC5cbiIsIGdzby0+dS5nc28udHlwZSk7CisJCW5ldGJrX2ZhdGFs
X3R4X2Vycih2aWYpOwogCQlyZXR1cm4gLUVJTlZBTDsKIAl9CiAKQEAgLTEy
NjQsOSArMTI3OSwyNiBAQCBzdGF0aWMgdW5zaWduZWQgeGVuX25ldGJrX3R4
X2J1aWxkX2dvcHMoc3RydWN0IHhlbl9uZXRiayAqbmV0YmspCiAKIAkJLyog
R2V0IGEgbmV0aWYgZnJvbSB0aGUgbGlzdCB3aXRoIHdvcmsgdG8gZG8uICov
CiAJCXZpZiA9IHBvbGxfbmV0X3NjaGVkdWxlX2xpc3QobmV0YmspOworCQkv
KgorCQkgKiBUaGlzIGNhbiBzb21ldGltZXMgaGFwcGVuIGJlY2F1c2UgdGhl
IHRlc3Qgb2YKKwkJICogbGlzdF9lbXB0eShuZXRfc2NoZWR1bGVfbGlzdCkg
YXQgdGhlIHRvcCBvZiB0aGUKKwkJICogbG9vcCBpcyB1bmxvY2tlZC4gIEp1
c3QgZ28gYmFjayBhbmQgaGF2ZSBhbm90aGVyCisJCSAqIGxvb2suCisJCSAq
LwogCQlpZiAoIXZpZikKIAkJCWNvbnRpbnVlOwogCisJCWlmICh2aWYtPnR4
LnNyaW5nLT5yZXFfcHJvZCAtIHZpZi0+dHgucmVxX2NvbnMgPgorCQkgICAg
WEVOX05FVElGX1RYX1JJTkdfU0laRSkgeworCQkJbmV0ZGV2X2Vycih2aWYt
PmRldiwKKwkJCQkgICAiSW1wb3NzaWJsZSBudW1iZXIgb2YgcmVxdWVzdHMu
ICIKKwkJCQkgICAicmVxX3Byb2QgJWQsIHJlcV9jb25zICVkLCBzaXplICVs
ZFxuIiwKKwkJCQkgICB2aWYtPnR4LnNyaW5nLT5yZXFfcHJvZCwgdmlmLT50
eC5yZXFfY29ucywKKwkJCQkgICBYRU5fTkVUSUZfVFhfUklOR19TSVpFKTsK
KwkJCW5ldGJrX2ZhdGFsX3R4X2Vycih2aWYpOworCQkJY29udGludWU7CisJ
CX0KKwogCQlSSU5HX0ZJTkFMX0NIRUNLX0ZPUl9SRVFVRVNUUygmdmlmLT50
eCwgd29ya190b19kbyk7CiAJCWlmICghd29ya190b19kbykgewogCQkJeGVu
dmlmX3B1dCh2aWYpOwpAQCAtMTI5NCwxNyArMTMyNiwxNCBAQCBzdGF0aWMg
dW5zaWduZWQgeGVuX25ldGJrX3R4X2J1aWxkX2dvcHMoc3RydWN0IHhlbl9u
ZXRiayAqbmV0YmspCiAJCQl3b3JrX3RvX2RvID0geGVuX25ldGJrX2dldF9l
eHRyYXModmlmLCBleHRyYXMsCiAJCQkJCQkJICB3b3JrX3RvX2RvKTsKIAkJ
CWlkeCA9IHZpZi0+dHgucmVxX2NvbnM7Ci0JCQlpZiAodW5saWtlbHkod29y
a190b19kbyA8IDApKSB7Ci0JCQkJbmV0YmtfdHhfZXJyKHZpZiwgJnR4cmVx
LCBpZHgpOworCQkJaWYgKHVubGlrZWx5KHdvcmtfdG9fZG8gPCAwKSkKIAkJ
CQljb250aW51ZTsKLQkJCX0KIAkJfQogCiAJCXJldCA9IG5ldGJrX2NvdW50
X3JlcXVlc3RzKHZpZiwgJnR4cmVxLCB0eGZyYWdzLCB3b3JrX3RvX2RvKTsK
LQkJaWYgKHVubGlrZWx5KHJldCA8IDApKSB7Ci0JCQluZXRia190eF9lcnIo
dmlmLCAmdHhyZXEsIGlkeCAtIHJldCk7CisJCWlmICh1bmxpa2VseShyZXQg
PCAwKSkKIAkJCWNvbnRpbnVlOwotCQl9CisKIAkJaWR4ICs9IHJldDsKIAog
CQlpZiAodW5saWtlbHkodHhyZXEuc2l6ZSA8IEVUSF9ITEVOKSkgewpAQCAt
MTMxNiwxMSArMTM0NSwxMSBAQCBzdGF0aWMgdW5zaWduZWQgeGVuX25ldGJr
X3R4X2J1aWxkX2dvcHMoc3RydWN0IHhlbl9uZXRiayAqbmV0YmspCiAKIAkJ
LyogTm8gY3Jvc3NpbmcgYSBwYWdlIGFzIHRoZSBwYXlsb2FkIG11c3RuJ3Qg
ZnJhZ21lbnQuICovCiAJCWlmICh1bmxpa2VseSgodHhyZXEub2Zmc2V0ICsg
dHhyZXEuc2l6ZSkgPiBQQUdFX1NJWkUpKSB7Ci0JCQluZXRkZXZfZGJnKHZp
Zi0+ZGV2LAorCQkJbmV0ZGV2X2Vycih2aWYtPmRldiwKIAkJCQkgICAidHhy
ZXEub2Zmc2V0OiAleCwgc2l6ZTogJXUsIGVuZDogJWx1XG4iLAogCQkJCSAg
IHR4cmVxLm9mZnNldCwgdHhyZXEuc2l6ZSwKIAkJCQkgICAodHhyZXEub2Zm
c2V0Jn5QQUdFX01BU0spICsgdHhyZXEuc2l6ZSk7Ci0JCQluZXRia190eF9l
cnIodmlmLCAmdHhyZXEsIGlkeCk7CisJCQluZXRia19mYXRhbF90eF9lcnIo
dmlmKTsKIAkJCWNvbnRpbnVlOwogCQl9CiAKQEAgLTEzNDgsOCArMTM3Nyw4
IEBAIHN0YXRpYyB1bnNpZ25lZCB4ZW5fbmV0YmtfdHhfYnVpbGRfZ29wcyhz
dHJ1Y3QgeGVuX25ldGJrICpuZXRiaykKIAkJCWdzbyA9ICZleHRyYXNbWEVO
X05FVElGX0VYVFJBX1RZUEVfR1NPIC0gMV07CiAKIAkJCWlmIChuZXRia19z
ZXRfc2tiX2dzbyh2aWYsIHNrYiwgZ3NvKSkgeworCQkJCS8qIEZhaWx1cmUg
aW4gbmV0Ymtfc2V0X3NrYl9nc28gaXMgZmF0YWwuICovCiAJCQkJa2ZyZWVf
c2tiKHNrYik7Ci0JCQkJbmV0YmtfdHhfZXJyKHZpZiwgJnR4cmVxLCBpZHgp
OwogCQkJCWNvbnRpbnVlOwogCQkJfQogCQl9Ci0tIAoxLjcuMi41Cgo=

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0002-xen-netback-don-t-leak-pages-on-failure-in-xen_netbk.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0002-xen-netback-don-t-leak-pages-on-failure-in-xen_netbk.patch"
Content-Transfer-Encoding: base64

RnJvbSA5MDQyMDYzMWQyYjc4YWNhMjhjOTRiZWI2NmIyNTQ0N2U1N2E4ZGQ0
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBNb24sIDE0IEphbiAy
MDEzIDEyOjIwOjA0ICswMDAwClN1YmplY3Q6IFtQQVRDSCAyLzRdIHhlbi9u
ZXRiYWNrOiBkb24ndCBsZWFrIHBhZ2VzIG9uIGZhaWx1cmUgaW4geGVuX25l
dGJrX3R4X2NoZWNrX2dvcC4KClNpZ25lZC1vZmYtYnk6IE1hdHRoZXcgRGFs
ZXkgPG1hdHRqZEBnbWFpbC5jb20+ClJldmlld2VkLWJ5OiBLb25yYWQgUnpl
c3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkFja2VkLWJ5
OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpBY2tl
ZC1ieTogSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPgotLS0KIGRy
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYyB8ICAgMzggKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5n
ZWQsIDEzIGluc2VydGlvbnMoKyksIDI1IGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYyBiL2Ry
aXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYwppbmRleCAxYTQ0OWY5
Li45NzUyNDFlIDEwMDY0NAotLS0gYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFj
ay9uZXRiYWNrLmMKKysrIGIvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svbmV0
YmFjay5jCkBAIC0xNDcsNyArMTQ3LDggQEAgdm9pZCB4ZW5fbmV0YmtfcmVt
b3ZlX3hlbnZpZihzdHJ1Y3QgeGVudmlmICp2aWYpCiAJYXRvbWljX2RlYygm
bmV0YmstPm5ldGZyb250X2NvdW50KTsKIH0KIAotc3RhdGljIHZvaWQgeGVu
X25ldGJrX2lkeF9yZWxlYXNlKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCB1
MTYgcGVuZGluZ19pZHgpOworc3RhdGljIHZvaWQgeGVuX25ldGJrX2lkeF9y
ZWxlYXNlKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCB1MTYgcGVuZGluZ19p
ZHgsCisJCQkJICB1OCBzdGF0dXMpOwogc3RhdGljIHZvaWQgbWFrZV90eF9y
ZXNwb25zZShzdHJ1Y3QgeGVudmlmICp2aWYsCiAJCQkgICAgIHN0cnVjdCB4
ZW5fbmV0aWZfdHhfcmVxdWVzdCAqdHhwLAogCQkJICAgICBzOCAgICAgICBz
dCk7CkBAIC0xMDA3LDMwICsxMDA4LDIwIEBAIHN0YXRpYyBpbnQgeGVuX25l
dGJrX3R4X2NoZWNrX2dvcChzdHJ1Y3QgeGVuX25ldGJrICpuZXRiaywKIHsK
IAlzdHJ1Y3QgZ250dGFiX2NvcHkgKmdvcCA9ICpnb3BwOwogCXUxNiBwZW5k
aW5nX2lkeCA9ICooKHUxNiAqKXNrYi0+ZGF0YSk7Ci0Jc3RydWN0IHBlbmRp
bmdfdHhfaW5mbyAqcGVuZGluZ190eF9pbmZvID0gbmV0YmstPnBlbmRpbmdf
dHhfaW5mbzsKLQlzdHJ1Y3QgeGVudmlmICp2aWYgPSBwZW5kaW5nX3R4X2lu
Zm9bcGVuZGluZ19pZHhdLnZpZjsKLQlzdHJ1Y3QgeGVuX25ldGlmX3R4X3Jl
cXVlc3QgKnR4cDsKIAlzdHJ1Y3Qgc2tiX3NoYXJlZF9pbmZvICpzaGluZm8g
PSBza2Jfc2hpbmZvKHNrYik7CiAJaW50IG5yX2ZyYWdzID0gc2hpbmZvLT5u
cl9mcmFnczsKIAlpbnQgaSwgZXJyLCBzdGFydDsKIAogCS8qIENoZWNrIHN0
YXR1cyBvZiBoZWFkZXIuICovCiAJZXJyID0gZ29wLT5zdGF0dXM7Ci0JaWYg
KHVubGlrZWx5KGVycikpIHsKLQkJcGVuZGluZ19yaW5nX2lkeF90IGluZGV4
OwotCQlpbmRleCA9IHBlbmRpbmdfaW5kZXgobmV0YmstPnBlbmRpbmdfcHJv
ZCsrKTsKLQkJdHhwID0gJnBlbmRpbmdfdHhfaW5mb1twZW5kaW5nX2lkeF0u
cmVxOwotCQltYWtlX3R4X3Jlc3BvbnNlKHZpZiwgdHhwLCBYRU5fTkVUSUZf
UlNQX0VSUk9SKTsKLQkJbmV0YmstPnBlbmRpbmdfcmluZ1tpbmRleF0gPSBw
ZW5kaW5nX2lkeDsKLQkJeGVudmlmX3B1dCh2aWYpOwotCX0KKwlpZiAodW5s
aWtlbHkoZXJyKSkKKwkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBw
ZW5kaW5nX2lkeCwgWEVOX05FVElGX1JTUF9FUlJPUik7CiAKIAkvKiBTa2lw
IGZpcnN0IHNrYiBmcmFnbWVudCBpZiBpdCBpcyBvbiBzYW1lIHBhZ2UgYXMg
aGVhZGVyIGZyYWdtZW50LiAqLwogCXN0YXJ0ID0gKGZyYWdfZ2V0X3BlbmRp
bmdfaWR4KCZzaGluZm8tPmZyYWdzWzBdKSA9PSBwZW5kaW5nX2lkeCk7CiAK
IAlmb3IgKGkgPSBzdGFydDsgaSA8IG5yX2ZyYWdzOyBpKyspIHsKIAkJaW50
IGosIG5ld2VycjsKLQkJcGVuZGluZ19yaW5nX2lkeF90IGluZGV4OwogCiAJ
CXBlbmRpbmdfaWR4ID0gZnJhZ19nZXRfcGVuZGluZ19pZHgoJnNoaW5mby0+
ZnJhZ3NbaV0pOwogCkBAIC0xMDM5LDE2ICsxMDMwLDEyIEBAIHN0YXRpYyBp
bnQgeGVuX25ldGJrX3R4X2NoZWNrX2dvcChzdHJ1Y3QgeGVuX25ldGJrICpu
ZXRiaywKIAkJaWYgKGxpa2VseSghbmV3ZXJyKSkgewogCQkJLyogSGFkIGEg
cHJldmlvdXMgZXJyb3I/IEludmFsaWRhdGUgdGhpcyBmcmFnbWVudC4gKi8K
IAkJCWlmICh1bmxpa2VseShlcnIpKQotCQkJCXhlbl9uZXRia19pZHhfcmVs
ZWFzZShuZXRiaywgcGVuZGluZ19pZHgpOworCQkJCXhlbl9uZXRia19pZHhf
cmVsZWFzZShuZXRiaywgcGVuZGluZ19pZHgsIFhFTl9ORVRJRl9SU1BfT0tB
WSk7CiAJCQljb250aW51ZTsKIAkJfQogCiAJCS8qIEVycm9yIG9uIHRoaXMg
ZnJhZ21lbnQ6IHJlc3BvbmQgdG8gY2xpZW50IHdpdGggYW4gZXJyb3IuICov
Ci0JCXR4cCA9ICZuZXRiay0+cGVuZGluZ190eF9pbmZvW3BlbmRpbmdfaWR4
XS5yZXE7Ci0JCW1ha2VfdHhfcmVzcG9uc2UodmlmLCB0eHAsIFhFTl9ORVRJ
Rl9SU1BfRVJST1IpOwotCQlpbmRleCA9IHBlbmRpbmdfaW5kZXgobmV0Ymst
PnBlbmRpbmdfcHJvZCsrKTsKLQkJbmV0YmstPnBlbmRpbmdfcmluZ1tpbmRl
eF0gPSBwZW5kaW5nX2lkeDsKLQkJeGVudmlmX3B1dCh2aWYpOworCQl4ZW5f
bmV0YmtfaWR4X3JlbGVhc2UobmV0YmssIHBlbmRpbmdfaWR4LCBYRU5fTkVU
SUZfUlNQX0VSUk9SKTsKIAogCQkvKiBOb3QgdGhlIGZpcnN0IGVycm9yPyBQ
cmVjZWRpbmcgZnJhZ3MgYWxyZWFkeSBpbnZhbGlkYXRlZC4gKi8KIAkJaWYg
KGVycikKQEAgLTEwNTYsMTAgKzEwNDMsMTAgQEAgc3RhdGljIGludCB4ZW5f
bmV0YmtfdHhfY2hlY2tfZ29wKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLAog
CiAJCS8qIEZpcnN0IGVycm9yOiBpbnZhbGlkYXRlIGhlYWRlciBhbmQgcHJl
Y2VkaW5nIGZyYWdtZW50cy4gKi8KIAkJcGVuZGluZ19pZHggPSAqKCh1MTYg
Kilza2ItPmRhdGEpOwotCQl4ZW5fbmV0YmtfaWR4X3JlbGVhc2UobmV0Ymss
IHBlbmRpbmdfaWR4KTsKKwkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJr
LCBwZW5kaW5nX2lkeCwgWEVOX05FVElGX1JTUF9PS0FZKTsKIAkJZm9yIChq
ID0gc3RhcnQ7IGogPCBpOyBqKyspIHsKIAkJCXBlbmRpbmdfaWR4ID0gZnJh
Z19nZXRfcGVuZGluZ19pZHgoJnNoaW5mby0+ZnJhZ3Nbal0pOwotCQkJeGVu
X25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lkeCk7CisJCQl4
ZW5fbmV0YmtfaWR4X3JlbGVhc2UobmV0YmssIHBlbmRpbmdfaWR4LCBYRU5f
TkVUSUZfUlNQX09LQVkpOwogCQl9CiAKIAkJLyogUmVtZW1iZXIgdGhlIGVy
cm9yOiBpbnZhbGlkYXRlIGFsbCBzdWJzZXF1ZW50IGZyYWdtZW50cy4gKi8K
QEAgLTEwOTMsNyArMTA4MCw3IEBAIHN0YXRpYyB2b2lkIHhlbl9uZXRia19m
aWxsX2ZyYWdzKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCBzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKQogCiAJCS8qIFRha2UgYW4gZXh0cmEgcmVmZXJlbmNlIHRv
IG9mZnNldCB4ZW5fbmV0YmtfaWR4X3JlbGVhc2UgKi8KIAkJZ2V0X3BhZ2Uo
bmV0YmstPm1tYXBfcGFnZXNbcGVuZGluZ19pZHhdKTsKLQkJeGVuX25ldGJr
X2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lkeCk7CisJCXhlbl9uZXRi
a19pZHhfcmVsZWFzZShuZXRiaywgcGVuZGluZ19pZHgsIFhFTl9ORVRJRl9S
U1BfT0tBWSk7CiAJfQogfQogCkBAIC0xNDc3LDcgKzE0NjQsNyBAQCBzdGF0
aWMgdm9pZCB4ZW5fbmV0YmtfdHhfc3VibWl0KHN0cnVjdCB4ZW5fbmV0Ymsg
Km5ldGJrKQogCQkJdHhwLT5zaXplIC09IGRhdGFfbGVuOwogCQl9IGVsc2Ug
ewogCQkJLyogU2NoZWR1bGUgYSByZXNwb25zZSBpbW1lZGlhdGVseS4gKi8K
LQkJCXhlbl9uZXRia19pZHhfcmVsZWFzZShuZXRiaywgcGVuZGluZ19pZHgp
OworCQkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lk
eCwgWEVOX05FVElGX1JTUF9PS0FZKTsKIAkJfQogCiAJCWlmICh0eHAtPmZs
YWdzICYgWEVOX05FVFRYRl9jc3VtX2JsYW5rKQpAQCAtMTUyOSw3ICsxNTE2
LDggQEAgc3RhdGljIHZvaWQgeGVuX25ldGJrX3R4X2FjdGlvbihzdHJ1Y3Qg
eGVuX25ldGJrICpuZXRiaykKIAl4ZW5fbmV0YmtfdHhfc3VibWl0KG5ldGJr
KTsKIH0KIAotc3RhdGljIHZvaWQgeGVuX25ldGJrX2lkeF9yZWxlYXNlKHN0
cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLCB1MTYgcGVuZGluZ19pZHgpCitzdGF0
aWMgdm9pZCB4ZW5fbmV0YmtfaWR4X3JlbGVhc2Uoc3RydWN0IHhlbl9uZXRi
ayAqbmV0YmssIHUxNiBwZW5kaW5nX2lkeCwKKwkJCQkgIHU4IHN0YXR1cykK
IHsKIAlzdHJ1Y3QgeGVudmlmICp2aWY7CiAJc3RydWN0IHBlbmRpbmdfdHhf
aW5mbyAqcGVuZGluZ190eF9pbmZvOwpAQCAtMTU0Myw3ICsxNTMxLDcgQEAg
c3RhdGljIHZvaWQgeGVuX25ldGJrX2lkeF9yZWxlYXNlKHN0cnVjdCB4ZW5f
bmV0YmsgKm5ldGJrLCB1MTYgcGVuZGluZ19pZHgpCiAKIAl2aWYgPSBwZW5k
aW5nX3R4X2luZm8tPnZpZjsKIAotCW1ha2VfdHhfcmVzcG9uc2UodmlmLCAm
cGVuZGluZ190eF9pbmZvLT5yZXEsIFhFTl9ORVRJRl9SU1BfT0tBWSk7CisJ
bWFrZV90eF9yZXNwb25zZSh2aWYsICZwZW5kaW5nX3R4X2luZm8tPnJlcSwg
c3RhdHVzKTsKIAogCWluZGV4ID0gcGVuZGluZ19pbmRleChuZXRiay0+cGVu
ZGluZ19wcm9kKyspOwogCW5ldGJrLT5wZW5kaW5nX3JpbmdbaW5kZXhdID0g
cGVuZGluZ19pZHg7Ci0tIAoxLjcuMi41Cgo=

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0003-xen-netback-free-already-allocated-memory-on-failure.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0003-xen-netback-free-already-allocated-memory-on-failure.patch"
Content-Transfer-Encoding: base64

RnJvbSBiNmIxZjE3YWE0NGFjZmUxMDI0OTY4YmFmYjFkMWZlNzcwNGE3NDlh
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBNb24sIDE0IEphbiAy
MDEzIDEyOjUxOjIyICswMDAwClN1YmplY3Q6IFtQQVRDSCAzLzRdIHhlbi9u
ZXRiYWNrOiBmcmVlIGFscmVhZHkgYWxsb2NhdGVkIG1lbW9yeSBvbiBmYWls
dXJlIGluIHhlbl9uZXRia19nZXRfcmVxdWVzdHMKClNpZ25lZC1vZmYtYnk6
IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ci0tLQog
ZHJpdmVycy9uZXQveGVuLW5ldGJhY2svbmV0YmFjay5jIHwgICAxNiArKysr
KysrKysrKysrKystCiAxIGZpbGVzIGNoYW5nZWQsIDE1IGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jIGIvZHJpdmVycy9uZXQveGVuLW5ldGJh
Y2svbmV0YmFjay5jCmluZGV4IDk3NTI0MWUuLjFhOTkyODggMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYworKysgYi9k
cml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKQEAgLTk3OCw3ICs5
NzgsNyBAQCBzdGF0aWMgc3RydWN0IGdudHRhYl9jb3B5ICp4ZW5fbmV0Ymtf
Z2V0X3JlcXVlc3RzKHN0cnVjdCB4ZW5fbmV0YmsgKm5ldGJrLAogCQlwZW5k
aW5nX2lkeCA9IG5ldGJrLT5wZW5kaW5nX3JpbmdbaW5kZXhdOwogCQlwYWdl
ID0geGVuX25ldGJrX2FsbG9jX3BhZ2UobmV0YmssIHNrYiwgcGVuZGluZ19p
ZHgpOwogCQlpZiAoIXBhZ2UpCi0JCQlyZXR1cm4gTlVMTDsKKwkJCWdvdG8g
ZXJyOwogCiAJCWdvcC0+c291cmNlLnUucmVmID0gdHhwLT5ncmVmOwogCQln
b3AtPnNvdXJjZS5kb21pZCA9IHZpZi0+ZG9taWQ7CkBAIC0xMDAwLDYgKzEw
MDAsMjAgQEAgc3RhdGljIHN0cnVjdCBnbnR0YWJfY29weSAqeGVuX25ldGJr
X2dldF9yZXF1ZXN0cyhzdHJ1Y3QgeGVuX25ldGJrICpuZXRiaywKIAl9CiAK
IAlyZXR1cm4gZ29wOworZXJyOgorCS8qCisJICogVW53aW5kLCBmcmVlaW5n
IGFsbCBwYWdlcyBhbmQgc2VuZGluZyBlcnJvcgorCSAqIHJlcG9uc2VzLgor
CSAqLworCXdoaWxlIChpLS0gPiBzdGFydCkgeworCQl4ZW5fbmV0YmtfaWR4
X3JlbGVhc2UobmV0YmssIGZyYWdfZ2V0X3BlbmRpbmdfaWR4KCZmcmFnc1tp
XSksCisJCQkJICAgICAgWEVOX05FVElGX1JTUF9FUlJPUik7CisJfQorCS8q
IFRoZSBoZWFkIHRvbywgaWYgbmVjZXNzYXJ5LiAqLworCWlmIChzdGFydCkK
KwkJeGVuX25ldGJrX2lkeF9yZWxlYXNlKG5ldGJrLCBwZW5kaW5nX2lkeCwg
WEVOX05FVElGX1JTUF9FUlJPUik7CisKKwlyZXR1cm4gTlVMTDsKIH0KIAog
c3RhdGljIGludCB4ZW5fbmV0YmtfdHhfY2hlY2tfZ29wKHN0cnVjdCB4ZW5f
bmV0YmsgKm5ldGJrLAotLSAKMS43LjIuNQoK

--=separator
Content-Type: application/octet-stream;
 name="xsa39-pvops-0004-netback-correct-netbk_tx_err-to-handle-wrap-around.patch"
Content-Disposition: attachment;
 filename="xsa39-pvops-0004-netback-correct-netbk_tx_err-to-handle-wrap-around.patch"
Content-Transfer-Encoding: base64

RnJvbSBlYTVlM2MxZThmZDlmZmU2MDgwZTAxYWY3NzY5YTlmYTQyMGNjNjJl
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gQ2FtcGJlbGwg
PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpEYXRlOiBNb24sIDE0IEphbiAy
MDEzIDEzOjMyOjMxICswMDAwClN1YmplY3Q6IFtQQVRDSCA0LzRdIG5ldGJh
Y2s6IGNvcnJlY3QgbmV0YmtfdHhfZXJyIHRvIGhhbmRsZSB3cmFwIGFyb3Vu
ZC4KClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxs
QGNpdHJpeC5jb20+CkFja2VkLWJ5OiBKYW4gQmV1bGljaCA8SkJldWxpY2hA
c3VzZS5jb20+Ci0tLQogZHJpdmVycy9uZXQveGVuLW5ldGJhY2svbmV0YmFj
ay5jIHwgICAgMiArLQogMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMo
KyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQv
eGVuLW5ldGJhY2svbmV0YmFjay5jIGIvZHJpdmVycy9uZXQveGVuLW5ldGJh
Y2svbmV0YmFjay5jCmluZGV4IDFhOTkyODguLjI4ZDVlMDYgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJhY2suYworKysgYi9k
cml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKQEAgLTg4MCw3ICs4
ODAsNyBAQCBzdGF0aWMgdm9pZCBuZXRia190eF9lcnIoc3RydWN0IHhlbnZp
ZiAqdmlmLAogCiAJZG8gewogCQltYWtlX3R4X3Jlc3BvbnNlKHZpZiwgdHhw
LCBYRU5fTkVUSUZfUlNQX0VSUk9SKTsKLQkJaWYgKGNvbnMgPj0gZW5kKQor
CQlpZiAoY29ucyA9PSBlbmQpCiAJCQlicmVhazsKIAkJdHhwID0gUklOR19H
RVRfUkVRVUVTVCgmdmlmLT50eCwgY29ucysrKTsKIAl9IHdoaWxlICgxKTsK
LS0gCjEuNy4yLjUKCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:16:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:16: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 1U2iNJ-0007Zs-Sn; Tue, 05 Feb 2013 13:15:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iNG-0007YC-H3; Tue, 05 Feb 2013 13:15:47 +0000
Received: from [85.158.138.51:8056] by server-3.bemta-3.messagelabs.com id
	27/9E-31070-10601115; Tue, 05 Feb 2013 13:15:45 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360070134!28898814!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 5 Feb 2013 13:15:36 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:36 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMZ-0003Zw-6U; Tue, 05 Feb 2013 13:15:03 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMY-00088X-Tl; Tue, 05 Feb 2013 13:15:02 +0000
Date: Tue, 05 Feb 2013 13:15:02 +0000
Message-Id: <E1U2iMY-00088X-Tl@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 36 (CVE-2013-0153) - interrupt
 remap entries shared and old ones not cleared on AMD IOMMUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2013-0153 / XSA-36
			      version 3

  interrupt remap entries shared and old ones not cleared on AMD IOMMUs

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system.  This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.

Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.

In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.

IMPACT
======

A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.

VULNERABLE SYSTEMS
==================

Xen versions 3.3 onwards are vulnerable.  Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.

Only systems using AMD-Vi for PCI passthrough are vulnerable.

Any domain which is given access to a PCI device can take advantage of
this vulnerability.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted
guests.

In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor.  This option is not fully functional on earlier
hypervisors.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore.  This should be dealt with by a BIOS
update, if available.  Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.

xsa36-unstable.patch              Xen unstable
xsa36-4.2.patch                   Xen 4.2.x
xsa36-4.1.patch                   Xen 4.1.x

$ sha256sum xsa36*.patch
2254fa46dcbc164d2d55ad9d519e7aa4ac5b83e9fb8d8e1f224114d08fe44237  xsa36-4.1.patch
6848712b560b522f7d3cede53e29e799624311e7dee6e450f0c02c165a590783  xsa36-4.2.patch
0e5d53c0b2bbbf07ef07bf31d8adeca4c043c0277f122f74557b018dc7348b74  xsa36-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQItAAoJEIP+FMlX6CvZapMH/i+AeMV4Mi9EAe97JWto2xrg
bCBdq7LEJ1cIpXGbhpXwTRzmsEGJmFR2VwkaxEtk+BuC7bzJ/KRjWYg6viQ7v+0t
thHEMtaRYTOIIel8YZ5t+v8oMdEUos7Oo94xhCk+n7ioH6PO+quUTI+aGd0+lcJm
d/5TC5f8w+HZNTB0nCQX9tQx5d4veQXghKs1NbKHeMyZ66nMZiqUqVUwQNTaFhUO
9eWyGOik5/mFctRrMxoOZHQm3d36AnDisiOku2CaG1xYYwDaAnOe/u6QcBZcVX3M
Q9COmTAWnOfIKYMIFnXRnyHSiw2+oZL6PTD5nX4O68B6hZ8pemVa+lFhSTvxsXM=
=5jP3
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa36-4.1.patch"
Content-Disposition: attachment; filename="xsa36-4.1.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgotLS0g
YS94ZW4vYXJjaC94ODYvaXJxLmMKKysrIGIveGVuL2FyY2gveDg2L2lycS5j
CkBAIC0xNjc3LDkgKzE2NzcsNiBAQCBpbnQgbWFwX2RvbWFpbl9waXJxKAog
ICAgICAgICBkLT5hcmNoLnBpcnFfaXJxW3BpcnFdID0gaXJxOwogICAgICAg
ICBkLT5hcmNoLmlycV9waXJxW2lycV0gPSBwaXJxOwogICAgICAgICBzcGlu
X3VubG9ja19pcnFyZXN0b3JlKCZkZXNjLT5sb2NrLCBmbGFncyk7Ci0KLSAg
ICAgICAgaWYgKCBvcHRfaXJxX3ZlY3Rvcl9tYXAgPT0gT1BUX0lSUV9WRUNU
T1JfTUFQX1BFUkRFViApCi0gICAgICAgICAgICBwcmludGsoWEVOTE9HX0lO
Rk8gIlBlci1kZXZpY2UgdmVjdG9yIG1hcHMgZm9yIEdTSXMgbm90IGltcGxl
bWVudGVkIHlldC5cbiIpOwogICAgIH0KIAogZG9uZToKLS0tIGEveGVuL2Ry
aXZlcnMvYWNwaS90YWJsZXMuYworKysgYi94ZW4vZHJpdmVycy9hY3BpL3Rh
Ymxlcy5jCkBAIC0yNjcsNyArMjY3LDcgQEAgYWNwaV90YWJsZV9wYXJzZV9t
YWR0KGVudW0gYWNwaV9tYWR0X3R5cAogICogQGhhbmRsZXI6IGhhbmRsZXIg
dG8gcnVuCiAgKgogICogU2NhbiB0aGUgQUNQSSBTeXN0ZW0gRGVzY3JpcHRv
ciBUYWJsZSAoU1REKSBmb3IgYSB0YWJsZSBtYXRjaGluZyBAaWQsCi0gKiBy
dW4gQGhhbmRsZXIgb24gaXQuICBSZXR1cm4gMCBpZiB0YWJsZSBmb3VuZCwg
cmV0dXJuIG9uIGlmIG5vdC4KKyAqIHJ1biBAaGFuZGxlciBvbiBpdC4KICAq
LwogaW50IGFjcGlfdGFibGVfcGFyc2UoY2hhciAqaWQsIGFjcGlfdGFibGVf
aGFuZGxlciBoYW5kbGVyKQogewpAQCAtMjgyLDggKzI4Miw3IEBAIGludCBh
Y3BpX3RhYmxlX3BhcnNlKGNoYXIgKmlkLCBhY3BpX3RhYmwKIAkJYWNwaV9n
ZXRfdGFibGUoaWQsIDAsICZ0YWJsZSk7CiAKIAlpZiAodGFibGUpIHsKLQkJ
aGFuZGxlcih0YWJsZSk7Ci0JCXJldHVybiAwOworCQlyZXR1cm4gaGFuZGxl
cih0YWJsZSk7CiAJfSBlbHNlCiAJCXJldHVybiAxOwogfQotLS0gYS94ZW4v
ZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jCisrKyBiL3hl
bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9hY3BpLmMKQEAgLTIx
LDYgKzIxLDcgQEAKICNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CiAjaW5jbHVk
ZSA8eGVuL2Vycm5vLmg+CiAjaW5jbHVkZSA8YXNtL2FwaWNkZWYuaD4KKyNp
bmNsdWRlIDxhc20vaW9fYXBpYy5oPgogI2luY2x1ZGUgPGFzbS9hbWQtaW9t
bXUuaD4KICNpbmNsdWRlIDxhc20vaHZtL3N2bS9hbWQtaW9tbXUtcHJvdG8u
aD4KICNpbmNsdWRlIDxhc20vaHZtL3N2bS9hbWQtaW9tbXUtYWNwaS5oPgpA
QCAtMjksNyArMzAsNiBAQCBleHRlcm4gdW5zaWduZWQgbG9uZyBhbWRfaW9t
bXVfcGFnZV9lbnRyCiBleHRlcm4gdW5zaWduZWQgc2hvcnQgaXZyc19iZGZf
ZW50cmllczsKIGV4dGVybiBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19t
YXBwaW5nczsKIGV4dGVybiB1bnNpZ25lZCBzaG9ydCBsYXN0X2JkZjsKLWV4
dGVybiBpbnQgaW9hcGljX2JkZltNQVhfSU9fQVBJQ1NdOwogZXh0ZXJuIHZv
aWQgKnNoYXJlZF9pbnRyZW1hcF90YWJsZTsKIAogc3RhdGljIHZvaWQgYWRk
X2l2cnNfbWFwcGluZ19lbnRyeSgKQEAgLTYzNiw2ICs2MzYsNyBAQCBzdGF0
aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAgdTE2
IGhlYWRlcl9sZW5ndGgsIHUxNiBibG9ja19sZW5ndGgsIHN0cnVjdCBhbWRf
aW9tbXUgKmlvbW11KQogewogICAgIHUxNiBkZXZfbGVuZ3RoLCBiZGY7Cisg
ICAgaW50IGFwaWM7CiAKICAgICBkZXZfbGVuZ3RoID0gc2l6ZW9mKHN0cnVj
dCBhY3BpX2l2aGRfZGV2aWNlX3NwZWNpYWwpOwogICAgIGlmICggaGVhZGVy
X2xlbmd0aCA8IChibG9ja19sZW5ndGggKyBkZXZfbGVuZ3RoKSApCkBAIC02
NTIsOSArNjUzLDU4IEBAIHN0YXRpYyB1MTYgX19pbml0IHBhcnNlX2l2aGRf
ZGV2aWNlX3NwZWMKICAgICB9CiAKICAgICBhZGRfaXZyc19tYXBwaW5nX2Vu
dHJ5KGJkZiwgYmRmLCBpdmhkX2RldmljZS0+aGVhZGVyLmZsYWdzLCBpb21t
dSk7Ci0gICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMgKi8KLSAgICBp
b2FwaWNfYmRmW2l2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZV0gPSBiZGY7
Ci0gICAgcmV0dXJuIGRldl9sZW5ndGg7CisKKyAgICBpZiAoIGl2aGRfZGV2
aWNlLT5zcGVjaWFsLnZhcmlldHkgIT0gMSAvKiBBQ1BJX0lWSERfSU9BUElD
ICovICkKKyAgICB7CisgICAgICAgIGlmICggaXZoZF9kZXZpY2UtPnNwZWNp
YWwudmFyaWV0eSAhPSAyIC8qIEFDUElfSVZIRF9IUEVUICovICkKKyAgICAg
ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJVbnJlY29nbml6ZWQgSVZIRCBz
cGVjaWFsIHZhcmlldHkgJSN4XG4iLAorICAgICAgICAgICAgICAgICAgIGl2
aGRfZGV2aWNlLT5zcGVjaWFsLnZhcmlldHkpOworICAgICAgICByZXR1cm4g
ZGV2X2xlbmd0aDsKKyAgICB9CisKKyAgICAvKgorICAgICAqIFNvbWUgQklP
U2VzIGhhdmUgSU9BUElDIGJyb2tlbiBlbnRyaWVzIHNvIHdlIGNoZWNrIGZv
ciBJVlJTCisgICAgICogY29uc2lzdGVuY3kgaGVyZSAtLS0gd2hldGhlciBl
bnRyeSdzIElPQVBJQyBJRCBpcyB2YWxpZCBhbmQKKyAgICAgKiB3aGV0aGVy
IHRoZXJlIGFyZSBjb25mbGljdGluZy9kdXBsaWNhdGVkIGVudHJpZXMuCisg
ICAgICovCisgICAgZm9yICggYXBpYyA9IDA7IGFwaWMgPCBucl9pb2FwaWNz
OyBhcGljKysgKQorICAgIHsKKyAgICAgICAgaWYgKCBJT19BUElDX0lEKGFw
aWMpICE9IGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSApCisgICAgICAg
ICAgICBjb250aW51ZTsKKworICAgICAgICBpZiAoIGlvYXBpY19iZGZbaXZo
ZF9kZXZpY2UtPnNwZWNpYWwuaGFuZGxlXS5waW5fc2V0dXAgKQorICAgICAg
ICB7CisgICAgICAgICAgICBpZiAoIGlvYXBpY19iZGZbaXZoZF9kZXZpY2Ut
PnNwZWNpYWwuaGFuZGxlXS5iZGYgPT0gYmRmICkKKyAgICAgICAgICAgICAg
ICBBTURfSU9NTVVfREVCVUcoIklWSEQgV2FybmluZzogRHVwbGljYXRlIElP
LUFQSUMgJSN4IGVudHJpZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSk7CisgICAg
ICAgICAgICBlbHNlCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgIklWSEQgRXJyb3I6IENvbmZsaWN0aW5nIElP
LUFQSUMgJSN4IGVudHJpZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAg
IGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSk7CisgICAgICAgICAgICAg
ICAgaWYgKCBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAg
ICAgICAgICAgICAgcmV0dXJuIDA7CisgICAgICAgICAgICB9CisgICAgICAg
IH0KKyAgICAgICAgZWxzZQorICAgICAgICB7CisgICAgICAgICAgICAvKiBz
ZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyAqLworICAgICAgICAgICAgaW9hcGlj
X2JkZltpdmhkX2RldmljZS0+c3BlY2lhbC5oYW5kbGVdLmJkZiA9IGJkZjsK
KworICAgICAgICAgICAgaW9hcGljX2JkZltpdmhkX2RldmljZS0+c3BlY2lh
bC5oYW5kbGVdLnBpbl9zZXR1cCA9IHh6YWxsb2NfYXJyYXkoCisgICAgICAg
ICAgICAgICAgdW5zaWduZWQgbG9uZywgQklUU19UT19MT05HUyhucl9pb2Fw
aWNfcmVnaXN0ZXJzW2FwaWNdKSk7CisgICAgICAgICAgICBpZiAoIG5yX2lv
YXBpY19yZWdpc3RlcnNbYXBpY10gJiYKKyAgICAgICAgICAgICAgICAgIWlv
YXBpY19iZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3NldHVwICkKKyAgICAg
ICAgICAgIHsKKyAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAi
SVZIRCBFcnJvcjogT3V0IG9mIG1lbW9yeVxuIik7CisgICAgICAgICAgICAg
ICAgcmV0dXJuIDA7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICAg
ICAgcmV0dXJuIGRldl9sZW5ndGg7CisgICAgfQorCisgICAgcHJpbnRrKFhF
TkxPR19FUlIgIklWSEQgRXJyb3I6IEludmFsaWQgSU8tQVBJQyAlI3hcbiIs
CisgICAgICAgICAgIGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSk7Cisg
ICAgcmV0dXJuIDA7CiB9CiAKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2l2
aGRfYmxvY2soc3RydWN0IGFjcGlfaXZoZF9ibG9ja19oZWFkZXIgKml2aGRf
YmxvY2spCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9pbml0LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lv
bW11X2luaXQuYwpAQCAtODk3LDEyICs4OTcsNDUgQEAgc3RhdGljIGludCBf
X2luaXQgYW1kX2lvbW11X3NldHVwX2RldmljZQogICAgIHJldHVybiAwOwog
fQogCisvKiBDaGVjayB3aGV0aGVyIFNQNTEwMCBTQVRBIENvbWJpbmVkIG1v
ZGUgaXMgb24gKi8KK3N0YXRpYyBib29sX3QgX19pbml0IGFtZF9zcDUxMDBf
ZXJyYXR1bTI4KHZvaWQpCit7CisgICAgdTMyIGJ1cywgaWQ7CisgICAgdTE2
IHZlbmRvcl9pZCwgZGV2X2lkOworICAgIHU4IGJ5dGU7CisKKyAgICBmb3Ig
KGJ1cyA9IDA7IGJ1cyA8IDI1NjsgYnVzKyspCisgICAgeworICAgICAgICBp
ZCA9IHBjaV9jb25mX3JlYWQzMihidXMsIDB4MTQsIDAsIFBDSV9WRU5ET1Jf
SUQpOworCisgICAgICAgIHZlbmRvcl9pZCA9IGlkICYgMHhmZmZmOworICAg
ICAgICBkZXZfaWQgPSAoaWQgPj4gMTYpICYgMHhmZmZmOworCisgICAgICAg
IC8qIFNQNTEwMCBTTUJ1cyBtb2R1bGUgc2V0cyBDb21iaW5lZCBtb2RlIG9u
ICovCisgICAgICAgIGlmICh2ZW5kb3JfaWQgIT0gMHgxMDAyIHx8IGRldl9p
ZCAhPSAweDQzODUpCisgICAgICAgICAgICBjb250aW51ZTsKKworICAgICAg
ICBieXRlID0gcGNpX2NvbmZfcmVhZDgoYnVzLCAweDE0LCAwLCAweGFkKTsK
KyAgICAgICAgaWYgKCAoYnl0ZSA+PiAzKSAmIDEgKQorICAgICAgICB7Cisg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIkFNRC1WaTogU1A1
MTAwIGVycmF0dW0gMjggZGV0ZWN0ZWQsIGRpc2FibGluZyBJT01NVS5cbiIK
KyAgICAgICAgICAgICAgICAgICAiSWYgcG9zc2libGUsIGRpc2FibGUgU0FU
QSBDb21iaW5lZCBtb2RlIGluIEJJT1Mgb3IgY29udGFjdCB5b3VyIHZlbmRv
ciBmb3IgQklPUyB1cGRhdGUuXG4iKTsKKyAgICAgICAgICAgIHJldHVybiAx
OworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9CisKIGlu
dCBfX2luaXQgYW1kX2lvbW11X2luaXQodm9pZCkKIHsKICAgICBzdHJ1Y3Qg
YW1kX2lvbW11ICppb21tdTsKIAogICAgIEJVR19PTiggIWlvbW11X2ZvdW5k
KCkgKTsKIAorICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCAm
JiBhbWRfc3A1MTAwX2VycmF0dW0yOCgpICkKKyAgICAgICAgZ290byBlcnJv
cl9vdXQ7CisKICAgICBpcnFfdG9faW9tbXUgPSB4bWFsbG9jX2FycmF5KHN0
cnVjdCBhbWRfaW9tbXUgKiwgbnJfaXJxcyk7CiAgICAgaWYgKCBpcnFfdG9f
aW9tbXUgPT0gTlVMTCApCiAgICAgICAgIGdvdG8gZXJyb3Jfb3V0OwotLS0g
YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW50ci5jCisr
KyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbnRyLmMK
QEAgLTI3LDcgKzI3LDcgQEAKICNkZWZpbmUgSU5UUkVNQVBfTEVOR1RIIDB4
QgogI2RlZmluZSBJTlRSRU1BUF9FTlRSSUVTICgxIDw8IElOVFJFTUFQX0xF
TkdUSCkKIAotaW50IGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsKK3N0cnVj
dCBpb2FwaWNfYmRmIGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsKIGV4dGVy
biBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19tYXBwaW5nczsKIGV4dGVy
biB1bnNpZ25lZCBzaG9ydCBpdnJzX2JkZl9lbnRyaWVzOwogdm9pZCAqc2hh
cmVkX2ludHJlbWFwX3RhYmxlOwpAQCAtMTE3LDEyICsxMTcsMTIgQEAgdm9p
ZCBpbnZhbGlkYXRlX2ludGVycnVwdF90YWJsZShzdHJ1Y3QgYQogc3RhdGlj
IHZvaWQgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGljKAogICAg
IGludCBiZGYsCiAgICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXUsCi0gICAg
c3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKmlvYXBpY19ydGUpCisgICAg
Y29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSwKKyAgICBj
b25zdCBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqb2xkX3J0ZSkKIHsK
ICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwogICAgIHUzMiogZW50cnk7CiAg
ICAgdTggZGVsaXZlcnlfbW9kZSwgZGVzdCwgdmVjdG9yLCBkZXN0X21vZGU7
Ci0gICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSA9IGlvYXBp
Y19ydGU7CiAgICAgaW50IHJlcV9pZDsKICAgICBzcGlubG9ja190ICpsb2Nr
OwogICAgIGludCBvZmZzZXQ7CkBAIC0xMzgsNiArMTM4LDE0IEBAIHN0YXRp
YyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2kKICAgICBzcGlu
X2xvY2tfaXJxc2F2ZShsb2NrLCBmbGFncyk7CiAKICAgICBvZmZzZXQgPSBn
ZXRfaW50cmVtYXBfb2Zmc2V0KHZlY3RvciwgZGVsaXZlcnlfbW9kZSk7Cisg
ICAgaWYgKCBvbGRfcnRlICkKKyAgICB7CisgICAgICAgIGludCBvbGRfb2Zm
c2V0ID0gZ2V0X2ludHJlbWFwX29mZnNldChvbGRfcnRlLT52ZWN0b3IsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBv
bGRfcnRlLT5kZWxpdmVyeV9tb2RlKTsKKworICAgICAgICBpZiAoIG9mZnNl
dCAhPSBvbGRfb2Zmc2V0ICkKKyAgICAgICAgICAgIGZyZWVfaW50cmVtYXBf
ZW50cnkoYmRmLCBvbGRfb2Zmc2V0KTsKKyAgICB9CiAgICAgZW50cnkgPSAo
dTMyKilnZXRfaW50cmVtYXBfZW50cnkocmVxX2lkLCBvZmZzZXQpOwogICAg
IHVwZGF0ZV9pbnRyZW1hcF9lbnRyeShlbnRyeSwgdmVjdG9yLCBkZWxpdmVy
eV9tb2RlLCBkZXN0X21vZGUsIGRlc3QpOwogCkBAIC0xNzYsNyArMTg0LDcg
QEAgaW50IF9faW5pdCBhbWRfaW9tbXVfc2V0dXBfaW9hcGljX3JlbWFwcAog
ICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCiAgICAgICAgICAgICAvKiBn
ZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyBkZXZpY2VzICovCi0gICAgICAgICAg
ICBiZGYgPSBpb2FwaWNfYmRmW0lPX0FQSUNfSUQoYXBpYyldOworICAgICAg
ICAgICAgYmRmID0gaW9hcGljX2JkZltJT19BUElDX0lEKGFwaWMpXS5iZGY7
CiAgICAgICAgICAgICBpb21tdSA9IGZpbmRfaW9tbXVfZm9yX2RldmljZShi
ZGYpOwogICAgICAgICAgICAgaWYgKCAhaW9tbXUgKQogICAgICAgICAgICAg
ewpAQCAtMjA3LDYgKzIxNSw3IEBAIGludCBfX2luaXQgYW1kX2lvbW11X3Nl
dHVwX2lvYXBpY19yZW1hcHAKICAgICAgICAgICAgICAgICBmbHVzaF9jb21t
YW5kX2J1ZmZlcihpb21tdSk7CiAgICAgICAgICAgICAgICAgc3Bpbl91bmxv
Y2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsKICAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgIHNldF9iaXQocGluLCBpb2FwaWNfYmRmW0lP
X0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCk7CiAgICAgICAgIH0KICAgICB9
CiAgICAgcmV0dXJuIDA7CkBAIC0yMTgsNiArMjI3LDcgQEAgdm9pZCBhbWRf
aW9tbXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAgICAgc3RydWN0IElPX0FQSUNf
cm91dGVfZW50cnkgb2xkX3J0ZSA9IHsgMCB9OwogICAgIHN0cnVjdCBJT19B
UElDX3JvdXRlX2VudHJ5IG5ld19ydGUgPSB7IDAgfTsKICAgICB1bnNpZ25l
ZCBpbnQgcnRlX2xvID0gKHJlZyAmIDEpID8gcmVnIC0gMSA6IHJlZzsKKyAg
ICB1bnNpZ25lZCBpbnQgcGluID0gKHJlZyAtIDB4MTApIC8gMjsKICAgICBp
bnQgc2F2ZWRfbWFzaywgYmRmOwogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlv
bW11OwogCkBAIC0yMjgsNyArMjM4LDcgQEAgdm9pZCBhbWRfaW9tbXVfaW9h
cGljX3VwZGF0ZV9pcmUoCiAgICAgfQogCiAgICAgLyogZ2V0IGRldmljZSBp
ZCBvZiBpb2FwaWMgZGV2aWNlcyAqLwotICAgIGJkZiA9IGlvYXBpY19iZGZb
SU9fQVBJQ19JRChhcGljKV07CisgICAgYmRmID0gaW9hcGljX2JkZltJT19B
UElDX0lEKGFwaWMpXS5iZGY7CiAgICAgaW9tbXUgPSBmaW5kX2lvbW11X2Zv
cl9kZXZpY2UoYmRmKTsKICAgICBpZiAoICFpb21tdSApCiAgICAgewpAQCAt
MjU0LDYgKzI2NCwxNCBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRl
X2lyZSgKICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRlKSArIDEpID0gdmFs
dWU7CiAgICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1hc2sgJiYKKyAgICAg
ICAgICF0ZXN0X2JpdChwaW4sIGlvYXBpY19iZGZbSU9fQVBJQ19JRChhcGlj
KV0ucGluX3NldHVwKSApCisgICAgeworICAgICAgICBBU1NFUlQoc2F2ZWRf
bWFzayk7CisgICAgICAgIF9faW9fYXBpY193cml0ZShhcGljLCByZWcsIHZh
bHVlKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAgIC8qIG1hc2sg
dGhlIGludGVycnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGludHJlbWFwIHRh
YmxlICovCiAgICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAgewpAQCAtMjYy
LDcgKzI4MCwxMSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2ly
ZSgKICAgICB9CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0IHJlbWFwcGlu
ZyBlbnRyeSAqLwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lv
YXBpYyhiZGYsIGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBkYXRlX2ludHJl
bWFwX2VudHJ5X2Zyb21faW9hcGljKAorICAgICAgICBiZGYsIGlvbW11LCAm
bmV3X3J0ZSwKKyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChwaW4sCisgICAg
ICAgICAgICAgICAgICAgICAgICAgaW9hcGljX2JkZltJT19BUElDX0lEKGFw
aWMpXS5waW5fc2V0dXApID8gJm9sZF9ydGUKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgOiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQgd3JpdGUgYWNjZXNzIHRv
IElPLUFQSUMgUlRFICovCiAgICAgX19pb19hcGljX3dyaXRlKGFwaWMsIHJl
ZywgdmFsdWUpOwpAQCAtMzczLDYgKzM5NSwxMiBAQCB2b2lkIGFtZF9pb21t
dV9tc2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAgIHJldHVybjsKICAgICB9
CiAKKyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9pbmRleCA+PSAwICkKKyAg
ICAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21zZyhpb21t
dSwgcGRldiwgbXNpX2Rlc2MsIE5VTEwpOworCisgICAgaWYgKCAhbXNnICkK
KyAgICAgICAgcmV0dXJuOworCiAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5
X2Zyb21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIG1zZyk7CiB9
CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRf
aW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvcGNp
X2FtZF9pb21tdS5jCkBAIC0xOTUsNiArMTk1LDggQEAgaW50IF9faW5pdCBh
bWRfaW92X2RldGVjdCh2b2lkKQogICAgIHsKICAgICAgICAgcHJpbnRrKCJB
TUQtVmk6IE5vdCBvdmVycmlkaW5nIGlycV92ZWN0b3JfbWFwIHNldHRpbmdc
biIpOwogICAgIH0KKyAgICBpZiAoICFhbWRfaW9tbXVfcGVyZGV2X2ludHJl
bWFwICkKKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJBTUQtVmk6
IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUgaXMgbm90IHJl
Y29tbWVuZGVkIChzZWUgWFNBLTM2KSFcbiIpOwogICAgIHJldHVybiBzY2Fu
X3BjaV9kZXZpY2VzKCk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9p
b21tdS5jCkBAIC00OSw3ICs0OSw3IEBAIGJvb2xfdCBfX3JlYWRfbW9zdGx5
IGlvbW11X3FpbnZhbCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21t
dV9pbnRyZW1hcCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21tdV9o
YXBfcHRfc2hhcmU7CiBib29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVf
ZGVidWc7Ci1ib29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVfcGVyZGV2
X2ludHJlbWFwOworYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lvbW11X3Bl
cmRldl9pbnRyZW1hcCA9IDE7CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBwYXJz
ZV9pb21tdV9wYXJhbShjaGFyICpzKQogewpAQCAtNzgsNiArNzgsOCBAQCBz
dGF0aWMgdm9pZCBfX2luaXQgcGFyc2VfaW9tbXVfcGFyYW0oY2hhCiAgICAg
ICAgICAgICBhbWRfaW9tbXVfZGVidWcgPSAxOwogICAgICAgICBlbHNlIGlm
ICggIXN0cmNtcChzLCAiYW1kLWlvbW11LXBlcmRldi1pbnRyZW1hcCIpICkK
ICAgICAgICAgICAgIGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAgPSAxOwor
ICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzLCAiYW1kLWlvbW11LWdsb2Jh
bC1pbnRyZW1hcCIpICkKKyAgICAgICAgICAgIGFtZF9pb21tdV9wZXJkZXZf
aW50cmVtYXAgPSAwOwogICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzLCAi
ZG9tMC1wYXNzdGhyb3VnaCIpICkKICAgICAgICAgICAgIGlvbW11X3Bhc3N0
aHJvdWdoID0gMTsKICAgICAgICAgZWxzZSBpZiAoICFzdHJjbXAocywgImRv
bTAtc3RyaWN0IikgKQotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9z
dm0vYW1kLWlvbW11LXByb3RvLmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4
Ni9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oCkBAIC04OCw2ICs4OCwxMSBA
QCB2b2lkIGFtZF9pb21tdV9yZWFkX21zaV9mcm9tX2lyZSgKIHVuc2lnbmVk
IGludCBhbWRfaW9tbXVfcmVhZF9pb2FwaWNfZnJvbV9pcmUoCiAgICAgdW5z
aWduZWQgaW50IGFwaWMsIHVuc2lnbmVkIGludCByZWcpOwogCitleHRlcm4g
c3RydWN0IGlvYXBpY19iZGYgeworICAgIHUxNiBiZGY7CisgICAgdW5zaWdu
ZWQgbG9uZyAqcGluX3NldHVwOworfSBpb2FwaWNfYmRmW107CisKIC8qIHBv
d2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAqLwogdm9pZCBhbWRfaW9tbXVfcmVz
dW1lKHZvaWQpOwogdm9pZCBhbWRfaW9tbXVfc3VzcGVuZCh2b2lkKTsK

--=separator
Content-Type: application/octet-stream; name="xsa36-4.2.patch"
Content-Disposition: attachment; filename="xsa36-4.2.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgotLS0g
YS94ZW4vYXJjaC94ODYvaXJxLmMKKysrIGIveGVuL2FyY2gveDg2L2lycS5j
CkBAIC0xOTQyLDkgKzE5NDIsNiBAQCBpbnQgbWFwX2RvbWFpbl9waXJxKAog
ICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3Mp
OwogICAgICAgICBzZXRfZG9tYWluX2lycV9waXJxKGQsIGlycSwgaW5mbyk7
CiAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ss
IGZsYWdzKTsKLQotICAgICAgICBpZiAoIG9wdF9pcnFfdmVjdG9yX21hcCA9
PSBPUFRfSVJRX1ZFQ1RPUl9NQVBfUEVSREVWICkKLSAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfSU5GTyAiUGVyLWRldmljZSB2ZWN0b3IgbWFwcyBmb3Ig
R1NJcyBub3QgaW1wbGVtZW50ZWQgeWV0LlxuIik7CiAgICAgfQogCiBkb25l
OgotLS0gYS94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCisrKyBiL3hlbi9k
cml2ZXJzL2FjcGkvdGFibGVzLmMKQEAgLTI2Nyw3ICsyNjcsNyBAQCBhY3Bp
X3RhYmxlX3BhcnNlX21hZHQoZW51bSBhY3BpX21hZHRfdHlwCiAgKiBAaGFu
ZGxlcjogaGFuZGxlciB0byBydW4KICAqCiAgKiBTY2FuIHRoZSBBQ1BJIFN5
c3RlbSBEZXNjcmlwdG9yIFRhYmxlIChTVEQpIGZvciBhIHRhYmxlIG1hdGNo
aW5nIEBpZCwKLSAqIHJ1biBAaGFuZGxlciBvbiBpdC4gIFJldHVybiAwIGlm
IHRhYmxlIGZvdW5kLCByZXR1cm4gb24gaWYgbm90LgorICogcnVuIEBoYW5k
bGVyIG9uIGl0LgogICovCiBpbnQgX19pbml0IGFjcGlfdGFibGVfcGFyc2Uo
Y2hhciAqaWQsIGFjcGlfdGFibGVfaGFuZGxlciBoYW5kbGVyKQogewpAQCAt
MjgyLDggKzI4Miw3IEBAIGludCBfX2luaXQgYWNwaV90YWJsZV9wYXJzZShj
aGFyICppZCwgYWMKIAkJYWNwaV9nZXRfdGFibGUoaWQsIDAsICZ0YWJsZSk7
CiAKIAlpZiAodGFibGUpIHsKLQkJaGFuZGxlcih0YWJsZSk7Ci0JCXJldHVy
biAwOworCQlyZXR1cm4gaGFuZGxlcih0YWJsZSk7CiAJfSBlbHNlCiAJCXJl
dHVybiAxOwogfQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQv
aW9tbXVfYWNwaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9hY3BpLmMKQEAgLTIyLDYgKzIyLDcgQEAKICNpbmNsdWRlIDx4
ZW4vZXJybm8uaD4KICNpbmNsdWRlIDx4ZW4vYWNwaS5oPgogI2luY2x1ZGUg
PGFzbS9hcGljZGVmLmg+CisjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4KICNp
bmNsdWRlIDxhc20vYW1kLWlvbW11Lmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9z
dm0vYW1kLWlvbW11LXByb3RvLmg+CiAKQEAgLTYzNSw2ICs2MzYsNyBAQCBz
dGF0aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAg
dTE2IGhlYWRlcl9sZW5ndGgsIHUxNiBibG9ja19sZW5ndGgsIHN0cnVjdCBh
bWRfaW9tbXUgKmlvbW11KQogewogICAgIHUxNiBkZXZfbGVuZ3RoLCBiZGY7
CisgICAgaW50IGFwaWM7CiAKICAgICBkZXZfbGVuZ3RoID0gc2l6ZW9mKCpz
cGVjaWFsKTsKICAgICBpZiAoIGhlYWRlcl9sZW5ndGggPCAoYmxvY2tfbGVu
Z3RoICsgZGV2X2xlbmd0aCkgKQpAQCAtNjUxLDEwICs2NTMsNTkgQEAgc3Rh
dGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZpY2Vfc3BlYwogICAgIH0K
IAogICAgIGFkZF9pdnJzX21hcHBpbmdfZW50cnkoYmRmLCBiZGYsIHNwZWNp
YWwtPmhlYWRlci5kYXRhX3NldHRpbmcsIGlvbW11KTsKLSAgICAvKiBzZXQg
ZGV2aWNlIGlkIG9mIGlvYXBpYyAqLwotICAgIGlvYXBpY19zYmRmW3NwZWNp
YWwtPmhhbmRsZV0uYmRmID0gYmRmOwotICAgIGlvYXBpY19zYmRmW3NwZWNp
YWwtPmhhbmRsZV0uc2VnID0gc2VnOwotICAgIHJldHVybiBkZXZfbGVuZ3Ro
OworCisgICAgaWYgKCBzcGVjaWFsLT52YXJpZXR5ICE9IEFDUElfSVZIRF9J
T0FQSUMgKQorICAgIHsKKyAgICAgICAgaWYgKCBzcGVjaWFsLT52YXJpZXR5
ICE9IEFDUElfSVZIRF9IUEVUICkKKyAgICAgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSICJVbnJlY29nbml6ZWQgSVZIRCBzcGVjaWFsIHZhcmlldHkgJSN4
XG4iLAorICAgICAgICAgICAgICAgICAgIHNwZWNpYWwtPnZhcmlldHkpOwor
ICAgICAgICByZXR1cm4gZGV2X2xlbmd0aDsKKyAgICB9CisKKyAgICAvKgor
ICAgICAqIFNvbWUgQklPU2VzIGhhdmUgSU9BUElDIGJyb2tlbiBlbnRyaWVz
IHNvIHdlIGNoZWNrIGZvciBJVlJTCisgICAgICogY29uc2lzdGVuY3kgaGVy
ZSAtLS0gd2hldGhlciBlbnRyeSdzIElPQVBJQyBJRCBpcyB2YWxpZCBhbmQK
KyAgICAgKiB3aGV0aGVyIHRoZXJlIGFyZSBjb25mbGljdGluZy9kdXBsaWNh
dGVkIGVudHJpZXMuCisgICAgICovCisgICAgZm9yICggYXBpYyA9IDA7IGFw
aWMgPCBucl9pb2FwaWNzOyBhcGljKysgKQorICAgIHsKKyAgICAgICAgaWYg
KCBJT19BUElDX0lEKGFwaWMpICE9IHNwZWNpYWwtPmhhbmRsZSApCisgICAg
ICAgICAgICBjb250aW51ZTsKKworICAgICAgICBpZiAoIGlvYXBpY19zYmRm
W3NwZWNpYWwtPmhhbmRsZV0ucGluX3NldHVwICkKKyAgICAgICAgeworICAg
ICAgICAgICAgaWYgKCBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLmJk
ZiA9PSBiZGYgJiYKKyAgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZbc3Bl
Y2lhbC0+aGFuZGxlXS5zZWcgPT0gc2VnICkKKyAgICAgICAgICAgICAgICBB
TURfSU9NTVVfREVCVUcoIklWSEQgV2FybmluZzogRHVwbGljYXRlIElPLUFQ
SUMgJSN4IGVudHJpZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHNwZWNpYWwtPmhhbmRsZSk7CisgICAgICAgICAgICBlbHNlCisg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19F
UlIgIklWSEQgRXJyb3I6IENvbmZsaWN0aW5nIElPLUFQSUMgJSN4IGVudHJp
ZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpYWwtPmhhbmRs
ZSk7CisgICAgICAgICAgICAgICAgaWYgKCBhbWRfaW9tbXVfcGVyZGV2X2lu
dHJlbWFwICkKKyAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDA7CisgICAg
ICAgICAgICB9CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICB7
CisgICAgICAgICAgICAvKiBzZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyAqLwor
ICAgICAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lhbC0+aGFuZGxlXS5iZGYg
PSBiZGY7CisgICAgICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5k
bGVdLnNlZyA9IHNlZzsKKworICAgICAgICAgICAgaW9hcGljX3NiZGZbc3Bl
Y2lhbC0+aGFuZGxlXS5waW5fc2V0dXAgPSB4emFsbG9jX2FycmF5KAorICAg
ICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9fTE9OR1MobnJf
aW9hcGljX2VudHJpZXNbYXBpY10pKTsKKyAgICAgICAgICAgIGlmICggbnJf
aW9hcGljX2VudHJpZXNbYXBpY10gJiYKKyAgICAgICAgICAgICAgICAgIWlv
YXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCApCisgICAg
ICAgICAgICB7CisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIg
IklWSEQgRXJyb3I6IE91dCBvZiBtZW1vcnlcbiIpOworICAgICAgICAgICAg
ICAgIHJldHVybiAwOworICAgICAgICAgICAgfQorICAgICAgICB9CisgICAg
ICAgIHJldHVybiBkZXZfbGVuZ3RoOworICAgIH0KKworICAgIHByaW50ayhY
RU5MT0dfRVJSICJJVkhEIEVycm9yOiBJbnZhbGlkIElPLUFQSUMgJSN4XG4i
LCBzcGVjaWFsLT5oYW5kbGUpOworICAgIHJldHVybiAwOwogfQogCiBzdGF0
aWMgaW50IF9faW5pdCBwYXJzZV9pdmhkX2Jsb2NrKGNvbnN0IHN0cnVjdCBh
Y3BpX2l2cnNfaGFyZHdhcmUgKml2aGRfYmxvY2spCi0tLSBhL3hlbi9kcml2
ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbml0LmMKKysrIGIveGVuL2Ry
aXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2luaXQuYwpAQCAtMTEyNiwx
MiArMTEyNiw0NSBAQCBzdGF0aWMgaW50IF9faW5pdCBhbWRfaW9tbXVfc2V0
dXBfZGV2aWNlCiAgICAgcmV0dXJuIDA7CiB9CiAKKy8qIENoZWNrIHdoZXRo
ZXIgU1A1MTAwIFNBVEEgQ29tYmluZWQgbW9kZSBpcyBvbiAqLworc3RhdGlj
IGJvb2xfdCBfX2luaXQgYW1kX3NwNTEwMF9lcnJhdHVtMjgodm9pZCkKK3sK
KyAgICB1MzIgYnVzLCBpZDsKKyAgICB1MTYgdmVuZG9yX2lkLCBkZXZfaWQ7
CisgICAgdTggYnl0ZTsKKworICAgIGZvciAoYnVzID0gMDsgYnVzIDwgMjU2
OyBidXMrKykKKyAgICB7CisgICAgICAgIGlkID0gcGNpX2NvbmZfcmVhZDMy
KDAsIGJ1cywgMHgxNCwgMCwgUENJX1ZFTkRPUl9JRCk7CisKKyAgICAgICAg
dmVuZG9yX2lkID0gaWQgJiAweGZmZmY7CisgICAgICAgIGRldl9pZCA9IChp
ZCA+PiAxNikgJiAweGZmZmY7CisKKyAgICAgICAgLyogU1A1MTAwIFNNQnVz
IG1vZHVsZSBzZXRzIENvbWJpbmVkIG1vZGUgb24gKi8KKyAgICAgICAgaWYg
KHZlbmRvcl9pZCAhPSAweDEwMDIgfHwgZGV2X2lkICE9IDB4NDM4NSkKKyAg
ICAgICAgICAgIGNvbnRpbnVlOworCisgICAgICAgIGJ5dGUgPSBwY2lfY29u
Zl9yZWFkOCgwLCBidXMsIDB4MTQsIDAsIDB4YWQpOworICAgICAgICBpZiAo
IChieXRlID4+IDMpICYgMSApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfV0FSTklORyAiQU1ELVZpOiBTUDUxMDAgZXJyYXR1bSAy
OCBkZXRlY3RlZCwgZGlzYWJsaW5nIElPTU1VLlxuIgorICAgICAgICAgICAg
ICAgICAgICJJZiBwb3NzaWJsZSwgZGlzYWJsZSBTQVRBIENvbWJpbmVkIG1v
ZGUgaW4gQklPUyBvciBjb250YWN0IHlvdXIgdmVuZG9yIGZvciBCSU9TIHVw
ZGF0ZS5cbiIpOworICAgICAgICAgICAgcmV0dXJuIDE7CisgICAgICAgIH0K
KyAgICB9CisKKyAgICByZXR1cm4gMDsKK30KKwogaW50IF9faW5pdCBhbWRf
aW9tbXVfaW5pdCh2b2lkKQogewogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlv
bW11OwogCiAgICAgQlVHX09OKCAhaW9tbXVfZm91bmQoKSApOwogCisgICAg
aWYgKCBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICYmIGFtZF9zcDUxMDBf
ZXJyYXR1bTI4KCkgKQorICAgICAgICBnb3RvIGVycm9yX291dDsKKwogICAg
IGl2cnNfYmRmX2VudHJpZXMgPSBhbWRfaW9tbXVfZ2V0X2l2cnNfZGV2X2Vu
dHJpZXMoKTsKIAogICAgIGlmICggIWl2cnNfYmRmX2VudHJpZXMgKQotLS0g
YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW50ci5jCisr
KyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbnRyLmMK
QEAgLTk5LDEyICs5OSwxMiBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVt
YXBfZW50cnkodTMyKiBlCiBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBf
ZW50cnlfZnJvbV9pb2FwaWMoCiAgICAgaW50IGJkZiwKICAgICBzdHJ1Y3Qg
YW1kX2lvbW11ICppb21tdSwKLSAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9l
bnRyeSAqaW9hcGljX3J0ZSkKKyAgICBjb25zdCBzdHJ1Y3QgSU9fQVBJQ19y
b3V0ZV9lbnRyeSAqcnRlLAorICAgIGNvbnN0IHN0cnVjdCBJT19BUElDX3Jv
dXRlX2VudHJ5ICpvbGRfcnRlKQogewogICAgIHVuc2lnbmVkIGxvbmcgZmxh
Z3M7CiAgICAgdTMyKiBlbnRyeTsKICAgICB1OCBkZWxpdmVyeV9tb2RlLCBk
ZXN0LCB2ZWN0b3IsIGRlc3RfbW9kZTsKLSAgICBzdHJ1Y3QgSU9fQVBJQ19y
b3V0ZV9lbnRyeSAqcnRlID0gaW9hcGljX3J0ZTsKICAgICBpbnQgcmVxX2lk
OwogICAgIHNwaW5sb2NrX3QgKmxvY2s7CiAgICAgaW50IG9mZnNldDsKQEAg
LTEyMCw2ICsxMjAsMTQgQEAgc3RhdGljIHZvaWQgdXBkYXRlX2ludHJlbWFw
X2VudHJ5X2Zyb21faQogICAgIHNwaW5fbG9ja19pcnFzYXZlKGxvY2ssIGZs
YWdzKTsKIAogICAgIG9mZnNldCA9IGdldF9pbnRyZW1hcF9vZmZzZXQodmVj
dG9yLCBkZWxpdmVyeV9tb2RlKTsKKyAgICBpZiAoIG9sZF9ydGUgKQorICAg
IHsKKyAgICAgICAgaW50IG9sZF9vZmZzZXQgPSBnZXRfaW50cmVtYXBfb2Zm
c2V0KG9sZF9ydGUtPnZlY3RvciwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG9sZF9ydGUtPmRlbGl2ZXJ5X21vZGUp
OworCisgICAgICAgIGlmICggb2Zmc2V0ICE9IG9sZF9vZmZzZXQgKQorICAg
ICAgICAgICAgZnJlZV9pbnRyZW1hcF9lbnRyeShpb21tdS0+c2VnLCBiZGYs
IG9sZF9vZmZzZXQpOworICAgIH0KICAgICBlbnRyeSA9ICh1MzIqKWdldF9p
bnRyZW1hcF9lbnRyeShpb21tdS0+c2VnLCByZXFfaWQsIG9mZnNldCk7CiAg
ICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5KGVudHJ5LCB2ZWN0b3IsIGRlbGl2
ZXJ5X21vZGUsIGRlc3RfbW9kZSwgZGVzdCk7CiAKQEAgLTE4OCw2ICsxOTYs
NyBAQCBpbnQgX19pbml0IGFtZF9pb21tdV9zZXR1cF9pb2FwaWNfcmVtYXBw
CiAgICAgICAgICAgICAgICAgYW1kX2lvbW11X2ZsdXNoX2ludHJlbWFwKGlv
bW11LCByZXFfaWQpOwogICAgICAgICAgICAgICAgIHNwaW5fdW5sb2NrX2ly
cXJlc3RvcmUoJmlvbW11LT5sb2NrLCBmbGFncyk7CiAgICAgICAgICAgICB9
CisgICAgICAgICAgICBzZXRfYml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJ
Q19JRChhcGljKV0ucGluX3NldHVwKTsKICAgICAgICAgfQogICAgIH0KICAg
ICByZXR1cm4gMDsKQEAgLTE5OSw2ICsyMDgsNyBAQCB2b2lkIGFtZF9pb21t
dV9pb2FwaWNfdXBkYXRlX2lyZSgKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0
ZV9lbnRyeSBvbGRfcnRlID0geyAwIH07CiAgICAgc3RydWN0IElPX0FQSUNf
cm91dGVfZW50cnkgbmV3X3J0ZSA9IHsgMCB9OwogICAgIHVuc2lnbmVkIGlu
dCBydGVfbG8gPSAocmVnICYgMSkgPyByZWcgLSAxIDogcmVnOworICAgIHVu
c2lnbmVkIGludCBwaW4gPSAocmVnIC0gMHgxMCkgLyAyOwogICAgIGludCBz
YXZlZF9tYXNrLCBzZWcsIGJkZjsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICpp
b21tdTsKIApAQCAtMjM2LDYgKzI0NiwxNCBAQCB2b2lkIGFtZF9pb21tdV9p
b2FwaWNfdXBkYXRlX2lyZSgKICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRl
KSArIDEpID0gdmFsdWU7CiAgICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1h
c2sgJiYKKyAgICAgICAgICF0ZXN0X2JpdChwaW4sIGlvYXBpY19zYmRmW0lP
X0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCkgKQorICAgIHsKKyAgICAgICAg
QVNTRVJUKHNhdmVkX21hc2spOworICAgICAgICBfX2lvX2FwaWNfd3JpdGUo
YXBpYywgcmVnLCB2YWx1ZSk7CisgICAgICAgIHJldHVybjsKKyAgICB9CisK
ICAgICAvKiBtYXNrIHRoZSBpbnRlcnJ1cHQgd2hpbGUgd2UgY2hhbmdlIHRo
ZSBpbnRyZW1hcCB0YWJsZSAqLwogICAgIGlmICggIXNhdmVkX21hc2sgKQog
ICAgIHsKQEAgLTI0NCw3ICsyNjIsMTEgQEAgdm9pZCBhbWRfaW9tbXVfaW9h
cGljX3VwZGF0ZV9pcmUoCiAgICAgfQogCiAgICAgLyogVXBkYXRlIGludGVy
cnVwdCByZW1hcHBpbmcgZW50cnkgKi8KLSAgICB1cGRhdGVfaW50cmVtYXBf
ZW50cnlfZnJvbV9pb2FwaWMoYmRmLCBpb21tdSwgJm5ld19ydGUpOworICAg
IHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lvYXBpYygKKyAgICAgICAg
YmRmLCBpb21tdSwgJm5ld19ydGUsCisgICAgICAgIHRlc3RfYW5kX3NldF9i
aXQocGluLAorICAgICAgICAgICAgICAgICAgICAgICAgIGlvYXBpY19zYmRm
W0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCkgPyAmb2xkX3J0ZQorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgOiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQg
d3JpdGUgYWNjZXNzIHRvIElPLUFQSUMgUlRFICovCiAgICAgX19pb19hcGlj
X3dyaXRlKGFwaWMsIHJlZywgdmFsdWUpOwpAQCAtMzU0LDYgKzM3NiwxMiBA
QCB2b2lkIGFtZF9pb21tdV9tc2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAg
IHJldHVybjsKICAgICB9CiAKKyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9p
bmRleCA+PSAwICkKKyAgICAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zy
b21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIE5VTEwpOworCisg
ICAgaWYgKCAhbXNnICkKKyAgICAgICAgcmV0dXJuOworCiAgICAgdXBkYXRl
X2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNp
X2Rlc2MsIG1zZyk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91
Z2gvYW1kL3BjaV9hbWRfaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvcGNpX2FtZF9pb21tdS5jCkBAIC0yMDUsNiArMjA1LDgg
QEAgaW50IF9faW5pdCBhbWRfaW92X2RldGVjdCh2b2lkKQogICAgIHsKICAg
ICAgICAgcHJpbnRrKCJBTUQtVmk6IE5vdCBvdmVycmlkaW5nIGlycV92ZWN0
b3JfbWFwIHNldHRpbmdcbiIpOwogICAgIH0KKyAgICBpZiAoICFhbWRfaW9t
bXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgcHJpbnRrKFhFTkxPR19X
QVJOSU5HICJBTUQtVmk6IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAg
dGFibGUgaXMgbm90IHJlY29tbWVuZGVkIChzZWUgWFNBLTM2KSFcbiIpOwog
ICAgIHJldHVybiBzY2FuX3BjaV9kZXZpY2VzKCk7CiB9CiAKLS0tIGEveGVu
L2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9tbXUuYworKysgYi94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9pb21tdS5jCkBAIC01Miw3ICs1Miw3IEBAIGJvb2xf
dCBfX3JlYWRfbW9zdGx5IGlvbW11X3FpbnZhbCA9IDE7CiBib29sX3QgX19y
ZWFkX21vc3RseSBpb21tdV9pbnRyZW1hcCA9IDE7CiBib29sX3QgX19yZWFk
X21vc3RseSBpb21tdV9oYXBfcHRfc2hhcmUgPSAxOwogYm9vbF90IF9fcmVh
ZF9tb3N0bHkgaW9tbXVfZGVidWc7Ci1ib29sX3QgX19yZWFkX21vc3RseSBh
bWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwOworYm9vbF90IF9fcmVhZF9tb3N0
bHkgYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCA9IDE7CiAKIERFRklORV9Q
RVJfQ1BVKGJvb2xfdCwgaW9tbXVfZG9udF9mbHVzaF9pb3RsYik7CiAKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL2FtZC1pb21tdS1wcm90
by5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3N2bS9hbWQtaW9t
bXUtcHJvdG8uaApAQCAtMTAwLDYgKzEwMCw3IEBAIHZvaWQgYW1kX2lvbW11
X3JlYWRfbXNpX2Zyb21faXJlKAogCiBleHRlcm4gc3RydWN0IGlvYXBpY19z
YmRmIHsKICAgICB1MTYgYmRmLCBzZWc7CisgICAgdW5zaWduZWQgbG9uZyAq
cGluX3NldHVwOwogfSBpb2FwaWNfc2JkZltNQVhfSU9fQVBJQ1NdOwogZXh0
ZXJuIHZvaWQgKnNoYXJlZF9pbnRyZW1hcF90YWJsZTsKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa36-unstable.patch"
Content-Disposition: attachment; filename="xsa36-unstable.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgotLS0g
YS94ZW4vYXJjaC94ODYvaXJxLmMKKysrIGIveGVuL2FyY2gveDg2L2lycS5j
CkBAIC0xOTQzLDkgKzE5NDMsNiBAQCBpbnQgbWFwX2RvbWFpbl9waXJxKAog
ICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3Mp
OwogICAgICAgICBzZXRfZG9tYWluX2lycV9waXJxKGQsIGlycSwgaW5mbyk7
CiAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ss
IGZsYWdzKTsKLQotICAgICAgICBpZiAoIG9wdF9pcnFfdmVjdG9yX21hcCA9
PSBPUFRfSVJRX1ZFQ1RPUl9NQVBfUEVSREVWICkKLSAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfSU5GTyAiUGVyLWRldmljZSB2ZWN0b3IgbWFwcyBmb3Ig
R1NJcyBub3QgaW1wbGVtZW50ZWQgeWV0LlxuIik7CiAgICAgfQogCiBkb25l
OgotLS0gYS94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCisrKyBiL3hlbi9k
cml2ZXJzL2FjcGkvdGFibGVzLmMKQEAgLTI2NSw3ICsyNjUsNyBAQCBhY3Bp
X3RhYmxlX3BhcnNlX21hZHQoZW51bSBhY3BpX21hZHRfdHlwCiAgKiBAaGFu
ZGxlcjogaGFuZGxlciB0byBydW4KICAqCiAgKiBTY2FuIHRoZSBBQ1BJIFN5
c3RlbSBEZXNjcmlwdG9yIFRhYmxlIChTVEQpIGZvciBhIHRhYmxlIG1hdGNo
aW5nIEBpZCwKLSAqIHJ1biBAaGFuZGxlciBvbiBpdC4gIFJldHVybiAwIGlm
IHRhYmxlIGZvdW5kLCByZXR1cm4gb24gaWYgbm90LgorICogcnVuIEBoYW5k
bGVyIG9uIGl0LgogICovCiBpbnQgX19pbml0IGFjcGlfdGFibGVfcGFyc2Uo
Y2hhciAqaWQsIGFjcGlfdGFibGVfaGFuZGxlciBoYW5kbGVyKQogewpAQCAt
MjgwLDggKzI4MCw3IEBAIGludCBfX2luaXQgYWNwaV90YWJsZV9wYXJzZShj
aGFyICppZCwgYWMKIAkJYWNwaV9nZXRfdGFibGUoaWQsIDAsICZ0YWJsZSk7
CiAKIAlpZiAodGFibGUpIHsKLQkJaGFuZGxlcih0YWJsZSk7Ci0JCXJldHVy
biAwOworCQlyZXR1cm4gaGFuZGxlcih0YWJsZSk7CiAJfSBlbHNlCiAJCXJl
dHVybiAxOwogfQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQv
aW9tbXVfYWNwaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9hY3BpLmMKQEAgLTIyLDYgKzIyLDcgQEAKICNpbmNsdWRlIDx4
ZW4vZXJybm8uaD4KICNpbmNsdWRlIDx4ZW4vYWNwaS5oPgogI2luY2x1ZGUg
PGFzbS9hcGljZGVmLmg+CisjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4KICNp
bmNsdWRlIDxhc20vYW1kLWlvbW11Lmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9z
dm0vYW1kLWlvbW11LXByb3RvLmg+CiAKQEAgLTYzNyw2ICs2MzgsNyBAQCBz
dGF0aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAg
dTE2IGhlYWRlcl9sZW5ndGgsIHUxNiBibG9ja19sZW5ndGgsIHN0cnVjdCBh
bWRfaW9tbXUgKmlvbW11KQogewogICAgIHUxNiBkZXZfbGVuZ3RoLCBiZGY7
CisgICAgaW50IGFwaWM7CiAKICAgICBkZXZfbGVuZ3RoID0gc2l6ZW9mKCpz
cGVjaWFsKTsKICAgICBpZiAoIGhlYWRlcl9sZW5ndGggPCAoYmxvY2tfbGVu
Z3RoICsgZGV2X2xlbmd0aCkgKQpAQCAtNjU3LDkgKzY1OSw1MyBAQCBzdGF0
aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAgc3dp
dGNoICggc3BlY2lhbC0+dmFyaWV0eSApCiAgICAgewogICAgIGNhc2UgQUNQ
SV9JVkhEX0lPQVBJQzoKLSAgICAvKiBzZXQgZGV2aWNlIGlkIG9mIGlvYXBp
YyAqLwotICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLmJk
ZiA9IGJkZjsKLSAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lhbC0+aGFuZGxl
XS5zZWcgPSBzZWc7CisgICAgICAgIC8qCisgICAgICAgICAqIFNvbWUgQklP
U2VzIGhhdmUgSU9BUElDIGJyb2tlbiBlbnRyaWVzIHNvIHdlIGNoZWNrIGZv
ciBJVlJTCisgICAgICAgICAqIGNvbnNpc3RlbmN5IGhlcmUgLS0tIHdoZXRo
ZXIgZW50cnkncyBJT0FQSUMgSUQgaXMgdmFsaWQgYW5kCisgICAgICAgICAq
IHdoZXRoZXIgdGhlcmUgYXJlIGNvbmZsaWN0aW5nL2R1cGxpY2F0ZWQgZW50
cmllcy4KKyAgICAgICAgICovCisgICAgICAgIGZvciAoIGFwaWMgPSAwOyBh
cGljIDwgbnJfaW9hcGljczsgYXBpYysrICkKKyAgICAgICAgeworICAgICAg
ICAgICAgaWYgKCBJT19BUElDX0lEKGFwaWMpICE9IHNwZWNpYWwtPmhhbmRs
ZSApCisgICAgICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgICAg
IGlmICggaW9hcGljX3NiZGZbc3BlY2lhbC0+aGFuZGxlXS5waW5fc2V0dXAg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGlmICggaW9hcGlj
X3NiZGZbc3BlY2lhbC0+aGFuZGxlXS5iZGYgPT0gYmRmICYmCisgICAgICAg
ICAgICAgICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLnNl
ZyA9PSBzZWcgKQorICAgICAgICAgICAgICAgICAgICBBTURfSU9NTVVfREVC
VUcoIklWSEQgV2FybmluZzogRHVwbGljYXRlIElPLUFQSUMgJSN4IGVudHJp
ZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
cGVjaWFsLT5oYW5kbGUpOworICAgICAgICAgICAgICAgIGVsc2UKKyAgICAg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSICJJVkhEIEVycm9yOiBDb25mbGljdGluZyBJTy1BUElDICUjeCBl
bnRyaWVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lh
bC0+aGFuZGxlKTsKKyAgICAgICAgICAgICAgICAgICAgaWYgKCBhbWRfaW9t
bXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgICAgICAgICAgICAgICAg
IHJldHVybiAwOworICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIH0K
KyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAg
ICAgICAvKiBzZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyAqLworICAgICAgICAg
ICAgICAgIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0uYmRmID0gYmRm
OworICAgICAgICAgICAgICAgIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRs
ZV0uc2VnID0gc2VnOworCisgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZb
c3BlY2lhbC0+aGFuZGxlXS5waW5fc2V0dXAgPSB4emFsbG9jX2FycmF5KAor
ICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nLCBCSVRTX1RPX0xP
TkdTKG5yX2lvYXBpY19lbnRyaWVzW2FwaWNdKSk7CisgICAgICAgICAgICAg
ICAgaWYgKCBucl9pb2FwaWNfZW50cmllc1thcGljXSAmJgorICAgICAgICAg
ICAgICAgICAgICAgIWlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBp
bl9zZXR1cCApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogT3V0IG9mIG1l
bW9yeVxuIik7CisgICAgICAgICAgICAgICAgICAgIHJldHVybiAwOworICAg
ICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGJy
ZWFrOworICAgICAgICB9CisgICAgICAgIGlmICggYXBpYyA9PSBucl9pb2Fw
aWNzICkKKyAgICAgICAgeworICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19F
UlIgIklWSEQgRXJyb3I6IEludmFsaWQgSU8tQVBJQyAlI3hcbiIsCisgICAg
ICAgICAgICAgICAgICAgc3BlY2lhbC0+aGFuZGxlKTsKKyAgICAgICAgICAg
IHJldHVybiAwOworICAgICAgICB9CiAgICAgICAgIGJyZWFrOwogICAgIGNh
c2UgQUNQSV9JVkhEX0hQRVQ6CiAgICAgICAgIC8qIHNldCBkZXZpY2UgaWQg
b2YgaHBldCAqLwotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQv
aW9tbXVfaW5pdC5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9pbml0LmMKQEAgLTExMjAsMTIgKzExMjAsNDUgQEAgc3RhdGlj
IGludCBfX2luaXQgYW1kX2lvbW11X3NldHVwX2RldmljZQogICAgIHJldHVy
biAwOwogfQogCisvKiBDaGVjayB3aGV0aGVyIFNQNTEwMCBTQVRBIENvbWJp
bmVkIG1vZGUgaXMgb24gKi8KK3N0YXRpYyBib29sX3QgX19pbml0IGFtZF9z
cDUxMDBfZXJyYXR1bTI4KHZvaWQpCit7CisgICAgdTMyIGJ1cywgaWQ7Cisg
ICAgdTE2IHZlbmRvcl9pZCwgZGV2X2lkOworICAgIHU4IGJ5dGU7CisKKyAg
ICBmb3IgKGJ1cyA9IDA7IGJ1cyA8IDI1NjsgYnVzKyspCisgICAgeworICAg
ICAgICBpZCA9IHBjaV9jb25mX3JlYWQzMigwLCBidXMsIDB4MTQsIDAsIFBD
SV9WRU5ET1JfSUQpOworCisgICAgICAgIHZlbmRvcl9pZCA9IGlkICYgMHhm
ZmZmOworICAgICAgICBkZXZfaWQgPSAoaWQgPj4gMTYpICYgMHhmZmZmOwor
CisgICAgICAgIC8qIFNQNTEwMCBTTUJ1cyBtb2R1bGUgc2V0cyBDb21iaW5l
ZCBtb2RlIG9uICovCisgICAgICAgIGlmICh2ZW5kb3JfaWQgIT0gMHgxMDAy
IHx8IGRldl9pZCAhPSAweDQzODUpCisgICAgICAgICAgICBjb250aW51ZTsK
KworICAgICAgICBieXRlID0gcGNpX2NvbmZfcmVhZDgoMCwgYnVzLCAweDE0
LCAwLCAweGFkKTsKKyAgICAgICAgaWYgKCAoYnl0ZSA+PiAzKSAmIDEgKQor
ICAgICAgICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcg
IkFNRC1WaTogU1A1MTAwIGVycmF0dW0gMjggZGV0ZWN0ZWQsIGRpc2FibGlu
ZyBJT01NVS5cbiIKKyAgICAgICAgICAgICAgICAgICAiSWYgcG9zc2libGUs
IGRpc2FibGUgU0FUQSBDb21iaW5lZCBtb2RlIGluIEJJT1Mgb3IgY29udGFj
dCB5b3VyIHZlbmRvciBmb3IgQklPUyB1cGRhdGUuXG4iKTsKKyAgICAgICAg
ICAgIHJldHVybiAxOworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJu
IDA7Cit9CisKIGludCBfX2luaXQgYW1kX2lvbW11X2luaXQodm9pZCkKIHsK
ICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIAogICAgIEJVR19PTigg
IWlvbW11X2ZvdW5kKCkgKTsKIAorICAgIGlmICggYW1kX2lvbW11X3BlcmRl
dl9pbnRyZW1hcCAmJiBhbWRfc3A1MTAwX2VycmF0dW0yOCgpICkKKyAgICAg
ICAgZ290byBlcnJvcl9vdXQ7CisKICAgICBpdnJzX2JkZl9lbnRyaWVzID0g
YW1kX2lvbW11X2dldF9pdnJzX2Rldl9lbnRyaWVzKCk7CiAKICAgICBpZiAo
ICFpdnJzX2JkZl9lbnRyaWVzICkKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvYW1kL2lvbW11X2ludHIuYworKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvaW9tbXVfaW50ci5jCkBAIC0xMDAsMTIgKzEwMCwxMiBA
QCBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50cnkodTMyKiBlCiBz
dGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9pb2FwaWMo
CiAgICAgaW50IGJkZiwKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSwK
LSAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqaW9hcGljX3J0ZSkK
KyAgICBjb25zdCBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqcnRlLAor
ICAgIGNvbnN0IHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICpvbGRfcnRl
KQogewogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7CiAgICAgdTMyKiBlbnRy
eTsKICAgICB1OCBkZWxpdmVyeV9tb2RlLCBkZXN0LCB2ZWN0b3IsIGRlc3Rf
bW9kZTsKLSAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqcnRlID0g
aW9hcGljX3J0ZTsKICAgICBpbnQgcmVxX2lkOwogICAgIHNwaW5sb2NrX3Qg
KmxvY2s7CiAgICAgaW50IG9mZnNldDsKQEAgLTEyMSw2ICsxMjEsMTQgQEAg
c3RhdGljIHZvaWQgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faQogICAg
IHNwaW5fbG9ja19pcnFzYXZlKGxvY2ssIGZsYWdzKTsKIAogICAgIG9mZnNl
dCA9IGdldF9pbnRyZW1hcF9vZmZzZXQodmVjdG9yLCBkZWxpdmVyeV9tb2Rl
KTsKKyAgICBpZiAoIG9sZF9ydGUgKQorICAgIHsKKyAgICAgICAgaW50IG9s
ZF9vZmZzZXQgPSBnZXRfaW50cmVtYXBfb2Zmc2V0KG9sZF9ydGUtPnZlY3Rv
ciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG9sZF9ydGUtPmRlbGl2ZXJ5X21vZGUpOworCisgICAgICAgIGlmICgg
b2Zmc2V0ICE9IG9sZF9vZmZzZXQgKQorICAgICAgICAgICAgZnJlZV9pbnRy
ZW1hcF9lbnRyeShpb21tdS0+c2VnLCBiZGYsIG9sZF9vZmZzZXQpOworICAg
IH0KICAgICBlbnRyeSA9ICh1MzIqKWdldF9pbnRyZW1hcF9lbnRyeShpb21t
dS0+c2VnLCByZXFfaWQsIG9mZnNldCk7CiAgICAgdXBkYXRlX2ludHJlbWFw
X2VudHJ5KGVudHJ5LCB2ZWN0b3IsIGRlbGl2ZXJ5X21vZGUsIGRlc3RfbW9k
ZSwgZGVzdCk7CiAKQEAgLTE4OSw2ICsxOTcsNyBAQCBpbnQgX19pbml0IGFt
ZF9pb21tdV9zZXR1cF9pb2FwaWNfcmVtYXBwCiAgICAgICAgICAgICAgICAg
YW1kX2lvbW11X2ZsdXNoX2ludHJlbWFwKGlvbW11LCByZXFfaWQpOwogICAg
ICAgICAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmlvbW11LT5s
b2NrLCBmbGFncyk7CiAgICAgICAgICAgICB9CisgICAgICAgICAgICBzZXRf
Yml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3Nl
dHVwKTsKICAgICAgICAgfQogICAgIH0KICAgICByZXR1cm4gMDsKQEAgLTIw
MCw2ICsyMDksNyBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2ly
ZSgKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSBvbGRfcnRlID0g
eyAwIH07CiAgICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgbmV3X3J0
ZSA9IHsgMCB9OwogICAgIHVuc2lnbmVkIGludCBydGVfbG8gPSAocmVnICYg
MSkgPyByZWcgLSAxIDogcmVnOworICAgIHVuc2lnbmVkIGludCBwaW4gPSAo
cmVnIC0gMHgxMCkgLyAyOwogICAgIGludCBzYXZlZF9tYXNrLCBzZWcsIGJk
ZjsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIApAQCAtMjM3LDYg
KzI0NywxNCBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2lyZSgK
ICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRlKSArIDEpID0gdmFsdWU7CiAg
ICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1hc2sgJiYKKyAgICAgICAgICF0
ZXN0X2JpdChwaW4sIGlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBp
bl9zZXR1cCkgKQorICAgIHsKKyAgICAgICAgQVNTRVJUKHNhdmVkX21hc2sp
OworICAgICAgICBfX2lvX2FwaWNfd3JpdGUoYXBpYywgcmVnLCB2YWx1ZSk7
CisgICAgICAgIHJldHVybjsKKyAgICB9CisKICAgICAvKiBtYXNrIHRoZSBp
bnRlcnJ1cHQgd2hpbGUgd2UgY2hhbmdlIHRoZSBpbnRyZW1hcCB0YWJsZSAq
LwogICAgIGlmICggIXNhdmVkX21hc2sgKQogICAgIHsKQEAgLTI0NSw3ICsy
NjMsMTEgQEAgdm9pZCBhbWRfaW9tbXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAg
ICAgfQogCiAgICAgLyogVXBkYXRlIGludGVycnVwdCByZW1hcHBpbmcgZW50
cnkgKi8KLSAgICB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9pb2FwaWMo
YmRmLCBpb21tdSwgJm5ld19ydGUpOworICAgIHVwZGF0ZV9pbnRyZW1hcF9l
bnRyeV9mcm9tX2lvYXBpYygKKyAgICAgICAgYmRmLCBpb21tdSwgJm5ld19y
dGUsCisgICAgICAgIHRlc3RfYW5kX3NldF9iaXQocGluLAorICAgICAgICAg
ICAgICAgICAgICAgICAgIGlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyld
LnBpbl9zZXR1cCkgPyAmb2xkX3J0ZQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
OiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQgd3JpdGUgYWNjZXNzIHRvIElP
LUFQSUMgUlRFICovCiAgICAgX19pb19hcGljX3dyaXRlKGFwaWMsIHJlZywg
dmFsdWUpOwpAQCAtMzU2LDYgKzM3OCwxMiBAQCB2b2lkIGFtZF9pb21tdV9t
c2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAgIHJldHVybjsKICAgICB9CiAK
KyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9pbmRleCA+PSAwICkKKyAgICAg
ICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21zZyhpb21tdSwg
YmRmLCBtc2lfZGVzYywgTlVMTCk7CisKKyAgICBpZiAoICFtc2cgKQorICAg
ICAgICByZXR1cm47CisKICAgICB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJv
bV9tc2lfbXNnKGlvbW11LCBiZGYsIG1zaV9kZXNjLCBtc2cpOwogfQogCi0t
LSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9wY2lfYW1kX2lvbW11
LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRf
aW9tbXUuYwpAQCAtMjA4LDYgKzIwOCw4IEBAIGludCBfX2luaXQgYW1kX2lv
dl9kZXRlY3Qodm9pZCkKICAgICB7CiAgICAgICAgIHByaW50aygiQU1ELVZp
OiBOb3Qgb3ZlcnJpZGluZyBpcnFfdmVjdG9yX21hcCBzZXR0aW5nXG4iKTsK
ICAgICB9CisgICAgaWYgKCAhYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCAp
CisgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiQU1ELVZpOiBVc2lu
ZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwIHRhYmxlIGlzIG5vdCByZWNvbW1l
bmRlZCAoc2VlIFhTQS0zNikhXG4iKTsKICAgICByZXR1cm4gc2Nhbl9wY2lf
ZGV2aWNlcygpOwogfQogCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L2lvbW11LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9tbXUu
YwpAQCAtNTMsNyArNTMsNyBAQCBib29sX3QgX19yZWFkX21vc3RseSBpb21t
dV9xaW52YWwgPSAxOwogYm9vbF90IF9fcmVhZF9tb3N0bHkgaW9tbXVfaW50
cmVtYXAgPSAxOwogYm9vbF90IF9fcmVhZF9tb3N0bHkgaW9tbXVfaGFwX3B0
X3NoYXJlID0gMTsKIGJvb2xfdCBfX3JlYWRfbW9zdGx5IGlvbW11X2RlYnVn
OwotYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lvbW11X3BlcmRldl9pbnRy
ZW1hcDsKK2Jvb2xfdCBfX3JlYWRfbW9zdGx5IGFtZF9pb21tdV9wZXJkZXZf
aW50cmVtYXAgPSAxOwogCiBERUZJTkVfUEVSX0NQVShib29sX3QsIGlvbW11
X2RvbnRfZmx1c2hfaW90bGIpOwogCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14
ODYvaHZtL3N2bS9hbWQtaW9tbXUtcHJvdG8uaAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L2h2bS9zdm0vYW1kLWlvbW11LXByb3RvLmgKQEAgLTEwMSw2
ICsxMDEsNyBAQCBpbnQgYW1kX3NldHVwX2hwZXRfbXNpKHN0cnVjdCBtc2lf
ZGVzYyAqCiAKIGV4dGVybiBzdHJ1Y3QgaW9hcGljX3NiZGYgewogICAgIHUx
NiBiZGYsIHNlZzsKKyAgICB1bnNpZ25lZCBsb25nICpwaW5fc2V0dXA7CiB9
IGlvYXBpY19zYmRmW01BWF9JT19BUElDU107CiBleHRlcm4gdm9pZCAqc2hh
cmVkX2ludHJlbWFwX3RhYmxlOwogCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:16:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:16: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 1U2iNJ-0007Zs-Sn; Tue, 05 Feb 2013 13:15:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iNG-0007YC-H3; Tue, 05 Feb 2013 13:15:47 +0000
Received: from [85.158.138.51:8056] by server-3.bemta-3.messagelabs.com id
	27/9E-31070-10601115; Tue, 05 Feb 2013 13:15:45 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360070134!28898814!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 5 Feb 2013 13:15:36 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:36 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMZ-0003Zw-6U; Tue, 05 Feb 2013 13:15:03 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMY-00088X-Tl; Tue, 05 Feb 2013 13:15:02 +0000
Date: Tue, 05 Feb 2013 13:15:02 +0000
Message-Id: <E1U2iMY-00088X-Tl@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 36 (CVE-2013-0153) - interrupt
 remap entries shared and old ones not cleared on AMD IOMMUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2013-0153 / XSA-36
			      version 3

  interrupt remap entries shared and old ones not cleared on AMD IOMMUs

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system.  This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.

Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.

In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.

IMPACT
======

A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.

VULNERABLE SYSTEMS
==================

Xen versions 3.3 onwards are vulnerable.  Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.

Only systems using AMD-Vi for PCI passthrough are vulnerable.

Any domain which is given access to a PCI device can take advantage of
this vulnerability.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted
guests.

In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor.  This option is not fully functional on earlier
hypervisors.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore.  This should be dealt with by a BIOS
update, if available.  Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.

xsa36-unstable.patch              Xen unstable
xsa36-4.2.patch                   Xen 4.2.x
xsa36-4.1.patch                   Xen 4.1.x

$ sha256sum xsa36*.patch
2254fa46dcbc164d2d55ad9d519e7aa4ac5b83e9fb8d8e1f224114d08fe44237  xsa36-4.1.patch
6848712b560b522f7d3cede53e29e799624311e7dee6e450f0c02c165a590783  xsa36-4.2.patch
0e5d53c0b2bbbf07ef07bf31d8adeca4c043c0277f122f74557b018dc7348b74  xsa36-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQItAAoJEIP+FMlX6CvZapMH/i+AeMV4Mi9EAe97JWto2xrg
bCBdq7LEJ1cIpXGbhpXwTRzmsEGJmFR2VwkaxEtk+BuC7bzJ/KRjWYg6viQ7v+0t
thHEMtaRYTOIIel8YZ5t+v8oMdEUos7Oo94xhCk+n7ioH6PO+quUTI+aGd0+lcJm
d/5TC5f8w+HZNTB0nCQX9tQx5d4veQXghKs1NbKHeMyZ66nMZiqUqVUwQNTaFhUO
9eWyGOik5/mFctRrMxoOZHQm3d36AnDisiOku2CaG1xYYwDaAnOe/u6QcBZcVX3M
Q9COmTAWnOfIKYMIFnXRnyHSiw2+oZL6PTD5nX4O68B6hZ8pemVa+lFhSTvxsXM=
=5jP3
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa36-4.1.patch"
Content-Disposition: attachment; filename="xsa36-4.1.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgotLS0g
YS94ZW4vYXJjaC94ODYvaXJxLmMKKysrIGIveGVuL2FyY2gveDg2L2lycS5j
CkBAIC0xNjc3LDkgKzE2NzcsNiBAQCBpbnQgbWFwX2RvbWFpbl9waXJxKAog
ICAgICAgICBkLT5hcmNoLnBpcnFfaXJxW3BpcnFdID0gaXJxOwogICAgICAg
ICBkLT5hcmNoLmlycV9waXJxW2lycV0gPSBwaXJxOwogICAgICAgICBzcGlu
X3VubG9ja19pcnFyZXN0b3JlKCZkZXNjLT5sb2NrLCBmbGFncyk7Ci0KLSAg
ICAgICAgaWYgKCBvcHRfaXJxX3ZlY3Rvcl9tYXAgPT0gT1BUX0lSUV9WRUNU
T1JfTUFQX1BFUkRFViApCi0gICAgICAgICAgICBwcmludGsoWEVOTE9HX0lO
Rk8gIlBlci1kZXZpY2UgdmVjdG9yIG1hcHMgZm9yIEdTSXMgbm90IGltcGxl
bWVudGVkIHlldC5cbiIpOwogICAgIH0KIAogZG9uZToKLS0tIGEveGVuL2Ry
aXZlcnMvYWNwaS90YWJsZXMuYworKysgYi94ZW4vZHJpdmVycy9hY3BpL3Rh
Ymxlcy5jCkBAIC0yNjcsNyArMjY3LDcgQEAgYWNwaV90YWJsZV9wYXJzZV9t
YWR0KGVudW0gYWNwaV9tYWR0X3R5cAogICogQGhhbmRsZXI6IGhhbmRsZXIg
dG8gcnVuCiAgKgogICogU2NhbiB0aGUgQUNQSSBTeXN0ZW0gRGVzY3JpcHRv
ciBUYWJsZSAoU1REKSBmb3IgYSB0YWJsZSBtYXRjaGluZyBAaWQsCi0gKiBy
dW4gQGhhbmRsZXIgb24gaXQuICBSZXR1cm4gMCBpZiB0YWJsZSBmb3VuZCwg
cmV0dXJuIG9uIGlmIG5vdC4KKyAqIHJ1biBAaGFuZGxlciBvbiBpdC4KICAq
LwogaW50IGFjcGlfdGFibGVfcGFyc2UoY2hhciAqaWQsIGFjcGlfdGFibGVf
aGFuZGxlciBoYW5kbGVyKQogewpAQCAtMjgyLDggKzI4Miw3IEBAIGludCBh
Y3BpX3RhYmxlX3BhcnNlKGNoYXIgKmlkLCBhY3BpX3RhYmwKIAkJYWNwaV9n
ZXRfdGFibGUoaWQsIDAsICZ0YWJsZSk7CiAKIAlpZiAodGFibGUpIHsKLQkJ
aGFuZGxlcih0YWJsZSk7Ci0JCXJldHVybiAwOworCQlyZXR1cm4gaGFuZGxl
cih0YWJsZSk7CiAJfSBlbHNlCiAJCXJldHVybiAxOwogfQotLS0gYS94ZW4v
ZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jCisrKyBiL3hl
bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9hY3BpLmMKQEAgLTIx
LDYgKzIxLDcgQEAKICNpbmNsdWRlIDx4ZW4vY29uZmlnLmg+CiAjaW5jbHVk
ZSA8eGVuL2Vycm5vLmg+CiAjaW5jbHVkZSA8YXNtL2FwaWNkZWYuaD4KKyNp
bmNsdWRlIDxhc20vaW9fYXBpYy5oPgogI2luY2x1ZGUgPGFzbS9hbWQtaW9t
bXUuaD4KICNpbmNsdWRlIDxhc20vaHZtL3N2bS9hbWQtaW9tbXUtcHJvdG8u
aD4KICNpbmNsdWRlIDxhc20vaHZtL3N2bS9hbWQtaW9tbXUtYWNwaS5oPgpA
QCAtMjksNyArMzAsNiBAQCBleHRlcm4gdW5zaWduZWQgbG9uZyBhbWRfaW9t
bXVfcGFnZV9lbnRyCiBleHRlcm4gdW5zaWduZWQgc2hvcnQgaXZyc19iZGZf
ZW50cmllczsKIGV4dGVybiBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19t
YXBwaW5nczsKIGV4dGVybiB1bnNpZ25lZCBzaG9ydCBsYXN0X2JkZjsKLWV4
dGVybiBpbnQgaW9hcGljX2JkZltNQVhfSU9fQVBJQ1NdOwogZXh0ZXJuIHZv
aWQgKnNoYXJlZF9pbnRyZW1hcF90YWJsZTsKIAogc3RhdGljIHZvaWQgYWRk
X2l2cnNfbWFwcGluZ19lbnRyeSgKQEAgLTYzNiw2ICs2MzYsNyBAQCBzdGF0
aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAgdTE2
IGhlYWRlcl9sZW5ndGgsIHUxNiBibG9ja19sZW5ndGgsIHN0cnVjdCBhbWRf
aW9tbXUgKmlvbW11KQogewogICAgIHUxNiBkZXZfbGVuZ3RoLCBiZGY7Cisg
ICAgaW50IGFwaWM7CiAKICAgICBkZXZfbGVuZ3RoID0gc2l6ZW9mKHN0cnVj
dCBhY3BpX2l2aGRfZGV2aWNlX3NwZWNpYWwpOwogICAgIGlmICggaGVhZGVy
X2xlbmd0aCA8IChibG9ja19sZW5ndGggKyBkZXZfbGVuZ3RoKSApCkBAIC02
NTIsOSArNjUzLDU4IEBAIHN0YXRpYyB1MTYgX19pbml0IHBhcnNlX2l2aGRf
ZGV2aWNlX3NwZWMKICAgICB9CiAKICAgICBhZGRfaXZyc19tYXBwaW5nX2Vu
dHJ5KGJkZiwgYmRmLCBpdmhkX2RldmljZS0+aGVhZGVyLmZsYWdzLCBpb21t
dSk7Ci0gICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMgKi8KLSAgICBp
b2FwaWNfYmRmW2l2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZV0gPSBiZGY7
Ci0gICAgcmV0dXJuIGRldl9sZW5ndGg7CisKKyAgICBpZiAoIGl2aGRfZGV2
aWNlLT5zcGVjaWFsLnZhcmlldHkgIT0gMSAvKiBBQ1BJX0lWSERfSU9BUElD
ICovICkKKyAgICB7CisgICAgICAgIGlmICggaXZoZF9kZXZpY2UtPnNwZWNp
YWwudmFyaWV0eSAhPSAyIC8qIEFDUElfSVZIRF9IUEVUICovICkKKyAgICAg
ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJVbnJlY29nbml6ZWQgSVZIRCBz
cGVjaWFsIHZhcmlldHkgJSN4XG4iLAorICAgICAgICAgICAgICAgICAgIGl2
aGRfZGV2aWNlLT5zcGVjaWFsLnZhcmlldHkpOworICAgICAgICByZXR1cm4g
ZGV2X2xlbmd0aDsKKyAgICB9CisKKyAgICAvKgorICAgICAqIFNvbWUgQklP
U2VzIGhhdmUgSU9BUElDIGJyb2tlbiBlbnRyaWVzIHNvIHdlIGNoZWNrIGZv
ciBJVlJTCisgICAgICogY29uc2lzdGVuY3kgaGVyZSAtLS0gd2hldGhlciBl
bnRyeSdzIElPQVBJQyBJRCBpcyB2YWxpZCBhbmQKKyAgICAgKiB3aGV0aGVy
IHRoZXJlIGFyZSBjb25mbGljdGluZy9kdXBsaWNhdGVkIGVudHJpZXMuCisg
ICAgICovCisgICAgZm9yICggYXBpYyA9IDA7IGFwaWMgPCBucl9pb2FwaWNz
OyBhcGljKysgKQorICAgIHsKKyAgICAgICAgaWYgKCBJT19BUElDX0lEKGFw
aWMpICE9IGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSApCisgICAgICAg
ICAgICBjb250aW51ZTsKKworICAgICAgICBpZiAoIGlvYXBpY19iZGZbaXZo
ZF9kZXZpY2UtPnNwZWNpYWwuaGFuZGxlXS5waW5fc2V0dXAgKQorICAgICAg
ICB7CisgICAgICAgICAgICBpZiAoIGlvYXBpY19iZGZbaXZoZF9kZXZpY2Ut
PnNwZWNpYWwuaGFuZGxlXS5iZGYgPT0gYmRmICkKKyAgICAgICAgICAgICAg
ICBBTURfSU9NTVVfREVCVUcoIklWSEQgV2FybmluZzogRHVwbGljYXRlIElP
LUFQSUMgJSN4IGVudHJpZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSk7CisgICAg
ICAgICAgICBlbHNlCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgIklWSEQgRXJyb3I6IENvbmZsaWN0aW5nIElP
LUFQSUMgJSN4IGVudHJpZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAg
IGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSk7CisgICAgICAgICAgICAg
ICAgaWYgKCBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAg
ICAgICAgICAgICAgcmV0dXJuIDA7CisgICAgICAgICAgICB9CisgICAgICAg
IH0KKyAgICAgICAgZWxzZQorICAgICAgICB7CisgICAgICAgICAgICAvKiBz
ZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyAqLworICAgICAgICAgICAgaW9hcGlj
X2JkZltpdmhkX2RldmljZS0+c3BlY2lhbC5oYW5kbGVdLmJkZiA9IGJkZjsK
KworICAgICAgICAgICAgaW9hcGljX2JkZltpdmhkX2RldmljZS0+c3BlY2lh
bC5oYW5kbGVdLnBpbl9zZXR1cCA9IHh6YWxsb2NfYXJyYXkoCisgICAgICAg
ICAgICAgICAgdW5zaWduZWQgbG9uZywgQklUU19UT19MT05HUyhucl9pb2Fw
aWNfcmVnaXN0ZXJzW2FwaWNdKSk7CisgICAgICAgICAgICBpZiAoIG5yX2lv
YXBpY19yZWdpc3RlcnNbYXBpY10gJiYKKyAgICAgICAgICAgICAgICAgIWlv
YXBpY19iZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3NldHVwICkKKyAgICAg
ICAgICAgIHsKKyAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAi
SVZIRCBFcnJvcjogT3V0IG9mIG1lbW9yeVxuIik7CisgICAgICAgICAgICAg
ICAgcmV0dXJuIDA7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICAg
ICAgcmV0dXJuIGRldl9sZW5ndGg7CisgICAgfQorCisgICAgcHJpbnRrKFhF
TkxPR19FUlIgIklWSEQgRXJyb3I6IEludmFsaWQgSU8tQVBJQyAlI3hcbiIs
CisgICAgICAgICAgIGl2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZSk7Cisg
ICAgcmV0dXJuIDA7CiB9CiAKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2l2
aGRfYmxvY2soc3RydWN0IGFjcGlfaXZoZF9ibG9ja19oZWFkZXIgKml2aGRf
YmxvY2spCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9pbml0LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lv
bW11X2luaXQuYwpAQCAtODk3LDEyICs4OTcsNDUgQEAgc3RhdGljIGludCBf
X2luaXQgYW1kX2lvbW11X3NldHVwX2RldmljZQogICAgIHJldHVybiAwOwog
fQogCisvKiBDaGVjayB3aGV0aGVyIFNQNTEwMCBTQVRBIENvbWJpbmVkIG1v
ZGUgaXMgb24gKi8KK3N0YXRpYyBib29sX3QgX19pbml0IGFtZF9zcDUxMDBf
ZXJyYXR1bTI4KHZvaWQpCit7CisgICAgdTMyIGJ1cywgaWQ7CisgICAgdTE2
IHZlbmRvcl9pZCwgZGV2X2lkOworICAgIHU4IGJ5dGU7CisKKyAgICBmb3Ig
KGJ1cyA9IDA7IGJ1cyA8IDI1NjsgYnVzKyspCisgICAgeworICAgICAgICBp
ZCA9IHBjaV9jb25mX3JlYWQzMihidXMsIDB4MTQsIDAsIFBDSV9WRU5ET1Jf
SUQpOworCisgICAgICAgIHZlbmRvcl9pZCA9IGlkICYgMHhmZmZmOworICAg
ICAgICBkZXZfaWQgPSAoaWQgPj4gMTYpICYgMHhmZmZmOworCisgICAgICAg
IC8qIFNQNTEwMCBTTUJ1cyBtb2R1bGUgc2V0cyBDb21iaW5lZCBtb2RlIG9u
ICovCisgICAgICAgIGlmICh2ZW5kb3JfaWQgIT0gMHgxMDAyIHx8IGRldl9p
ZCAhPSAweDQzODUpCisgICAgICAgICAgICBjb250aW51ZTsKKworICAgICAg
ICBieXRlID0gcGNpX2NvbmZfcmVhZDgoYnVzLCAweDE0LCAwLCAweGFkKTsK
KyAgICAgICAgaWYgKCAoYnl0ZSA+PiAzKSAmIDEgKQorICAgICAgICB7Cisg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIkFNRC1WaTogU1A1
MTAwIGVycmF0dW0gMjggZGV0ZWN0ZWQsIGRpc2FibGluZyBJT01NVS5cbiIK
KyAgICAgICAgICAgICAgICAgICAiSWYgcG9zc2libGUsIGRpc2FibGUgU0FU
QSBDb21iaW5lZCBtb2RlIGluIEJJT1Mgb3IgY29udGFjdCB5b3VyIHZlbmRv
ciBmb3IgQklPUyB1cGRhdGUuXG4iKTsKKyAgICAgICAgICAgIHJldHVybiAx
OworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9CisKIGlu
dCBfX2luaXQgYW1kX2lvbW11X2luaXQodm9pZCkKIHsKICAgICBzdHJ1Y3Qg
YW1kX2lvbW11ICppb21tdTsKIAogICAgIEJVR19PTiggIWlvbW11X2ZvdW5k
KCkgKTsKIAorICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCAm
JiBhbWRfc3A1MTAwX2VycmF0dW0yOCgpICkKKyAgICAgICAgZ290byBlcnJv
cl9vdXQ7CisKICAgICBpcnFfdG9faW9tbXUgPSB4bWFsbG9jX2FycmF5KHN0
cnVjdCBhbWRfaW9tbXUgKiwgbnJfaXJxcyk7CiAgICAgaWYgKCBpcnFfdG9f
aW9tbXUgPT0gTlVMTCApCiAgICAgICAgIGdvdG8gZXJyb3Jfb3V0OwotLS0g
YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW50ci5jCisr
KyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbnRyLmMK
QEAgLTI3LDcgKzI3LDcgQEAKICNkZWZpbmUgSU5UUkVNQVBfTEVOR1RIIDB4
QgogI2RlZmluZSBJTlRSRU1BUF9FTlRSSUVTICgxIDw8IElOVFJFTUFQX0xF
TkdUSCkKIAotaW50IGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsKK3N0cnVj
dCBpb2FwaWNfYmRmIGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsKIGV4dGVy
biBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19tYXBwaW5nczsKIGV4dGVy
biB1bnNpZ25lZCBzaG9ydCBpdnJzX2JkZl9lbnRyaWVzOwogdm9pZCAqc2hh
cmVkX2ludHJlbWFwX3RhYmxlOwpAQCAtMTE3LDEyICsxMTcsMTIgQEAgdm9p
ZCBpbnZhbGlkYXRlX2ludGVycnVwdF90YWJsZShzdHJ1Y3QgYQogc3RhdGlj
IHZvaWQgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGljKAogICAg
IGludCBiZGYsCiAgICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXUsCi0gICAg
c3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKmlvYXBpY19ydGUpCisgICAg
Y29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSwKKyAgICBj
b25zdCBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqb2xkX3J0ZSkKIHsK
ICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwogICAgIHUzMiogZW50cnk7CiAg
ICAgdTggZGVsaXZlcnlfbW9kZSwgZGVzdCwgdmVjdG9yLCBkZXN0X21vZGU7
Ci0gICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSA9IGlvYXBp
Y19ydGU7CiAgICAgaW50IHJlcV9pZDsKICAgICBzcGlubG9ja190ICpsb2Nr
OwogICAgIGludCBvZmZzZXQ7CkBAIC0xMzgsNiArMTM4LDE0IEBAIHN0YXRp
YyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2kKICAgICBzcGlu
X2xvY2tfaXJxc2F2ZShsb2NrLCBmbGFncyk7CiAKICAgICBvZmZzZXQgPSBn
ZXRfaW50cmVtYXBfb2Zmc2V0KHZlY3RvciwgZGVsaXZlcnlfbW9kZSk7Cisg
ICAgaWYgKCBvbGRfcnRlICkKKyAgICB7CisgICAgICAgIGludCBvbGRfb2Zm
c2V0ID0gZ2V0X2ludHJlbWFwX29mZnNldChvbGRfcnRlLT52ZWN0b3IsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBv
bGRfcnRlLT5kZWxpdmVyeV9tb2RlKTsKKworICAgICAgICBpZiAoIG9mZnNl
dCAhPSBvbGRfb2Zmc2V0ICkKKyAgICAgICAgICAgIGZyZWVfaW50cmVtYXBf
ZW50cnkoYmRmLCBvbGRfb2Zmc2V0KTsKKyAgICB9CiAgICAgZW50cnkgPSAo
dTMyKilnZXRfaW50cmVtYXBfZW50cnkocmVxX2lkLCBvZmZzZXQpOwogICAg
IHVwZGF0ZV9pbnRyZW1hcF9lbnRyeShlbnRyeSwgdmVjdG9yLCBkZWxpdmVy
eV9tb2RlLCBkZXN0X21vZGUsIGRlc3QpOwogCkBAIC0xNzYsNyArMTg0LDcg
QEAgaW50IF9faW5pdCBhbWRfaW9tbXVfc2V0dXBfaW9hcGljX3JlbWFwcAog
ICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCiAgICAgICAgICAgICAvKiBn
ZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyBkZXZpY2VzICovCi0gICAgICAgICAg
ICBiZGYgPSBpb2FwaWNfYmRmW0lPX0FQSUNfSUQoYXBpYyldOworICAgICAg
ICAgICAgYmRmID0gaW9hcGljX2JkZltJT19BUElDX0lEKGFwaWMpXS5iZGY7
CiAgICAgICAgICAgICBpb21tdSA9IGZpbmRfaW9tbXVfZm9yX2RldmljZShi
ZGYpOwogICAgICAgICAgICAgaWYgKCAhaW9tbXUgKQogICAgICAgICAgICAg
ewpAQCAtMjA3LDYgKzIxNSw3IEBAIGludCBfX2luaXQgYW1kX2lvbW11X3Nl
dHVwX2lvYXBpY19yZW1hcHAKICAgICAgICAgICAgICAgICBmbHVzaF9jb21t
YW5kX2J1ZmZlcihpb21tdSk7CiAgICAgICAgICAgICAgICAgc3Bpbl91bmxv
Y2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsKICAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgIHNldF9iaXQocGluLCBpb2FwaWNfYmRmW0lP
X0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCk7CiAgICAgICAgIH0KICAgICB9
CiAgICAgcmV0dXJuIDA7CkBAIC0yMTgsNiArMjI3LDcgQEAgdm9pZCBhbWRf
aW9tbXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAgICAgc3RydWN0IElPX0FQSUNf
cm91dGVfZW50cnkgb2xkX3J0ZSA9IHsgMCB9OwogICAgIHN0cnVjdCBJT19B
UElDX3JvdXRlX2VudHJ5IG5ld19ydGUgPSB7IDAgfTsKICAgICB1bnNpZ25l
ZCBpbnQgcnRlX2xvID0gKHJlZyAmIDEpID8gcmVnIC0gMSA6IHJlZzsKKyAg
ICB1bnNpZ25lZCBpbnQgcGluID0gKHJlZyAtIDB4MTApIC8gMjsKICAgICBp
bnQgc2F2ZWRfbWFzaywgYmRmOwogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlv
bW11OwogCkBAIC0yMjgsNyArMjM4LDcgQEAgdm9pZCBhbWRfaW9tbXVfaW9h
cGljX3VwZGF0ZV9pcmUoCiAgICAgfQogCiAgICAgLyogZ2V0IGRldmljZSBp
ZCBvZiBpb2FwaWMgZGV2aWNlcyAqLwotICAgIGJkZiA9IGlvYXBpY19iZGZb
SU9fQVBJQ19JRChhcGljKV07CisgICAgYmRmID0gaW9hcGljX2JkZltJT19B
UElDX0lEKGFwaWMpXS5iZGY7CiAgICAgaW9tbXUgPSBmaW5kX2lvbW11X2Zv
cl9kZXZpY2UoYmRmKTsKICAgICBpZiAoICFpb21tdSApCiAgICAgewpAQCAt
MjU0LDYgKzI2NCwxNCBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRl
X2lyZSgKICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRlKSArIDEpID0gdmFs
dWU7CiAgICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1hc2sgJiYKKyAgICAg
ICAgICF0ZXN0X2JpdChwaW4sIGlvYXBpY19iZGZbSU9fQVBJQ19JRChhcGlj
KV0ucGluX3NldHVwKSApCisgICAgeworICAgICAgICBBU1NFUlQoc2F2ZWRf
bWFzayk7CisgICAgICAgIF9faW9fYXBpY193cml0ZShhcGljLCByZWcsIHZh
bHVlKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAgIC8qIG1hc2sg
dGhlIGludGVycnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGludHJlbWFwIHRh
YmxlICovCiAgICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAgewpAQCAtMjYy
LDcgKzI4MCwxMSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2ly
ZSgKICAgICB9CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0IHJlbWFwcGlu
ZyBlbnRyeSAqLwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lv
YXBpYyhiZGYsIGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBkYXRlX2ludHJl
bWFwX2VudHJ5X2Zyb21faW9hcGljKAorICAgICAgICBiZGYsIGlvbW11LCAm
bmV3X3J0ZSwKKyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChwaW4sCisgICAg
ICAgICAgICAgICAgICAgICAgICAgaW9hcGljX2JkZltJT19BUElDX0lEKGFw
aWMpXS5waW5fc2V0dXApID8gJm9sZF9ydGUKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgOiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQgd3JpdGUgYWNjZXNzIHRv
IElPLUFQSUMgUlRFICovCiAgICAgX19pb19hcGljX3dyaXRlKGFwaWMsIHJl
ZywgdmFsdWUpOwpAQCAtMzczLDYgKzM5NSwxMiBAQCB2b2lkIGFtZF9pb21t
dV9tc2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAgIHJldHVybjsKICAgICB9
CiAKKyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9pbmRleCA+PSAwICkKKyAg
ICAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21zZyhpb21t
dSwgcGRldiwgbXNpX2Rlc2MsIE5VTEwpOworCisgICAgaWYgKCAhbXNnICkK
KyAgICAgICAgcmV0dXJuOworCiAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5
X2Zyb21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIG1zZyk7CiB9
CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRf
aW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvcGNp
X2FtZF9pb21tdS5jCkBAIC0xOTUsNiArMTk1LDggQEAgaW50IF9faW5pdCBh
bWRfaW92X2RldGVjdCh2b2lkKQogICAgIHsKICAgICAgICAgcHJpbnRrKCJB
TUQtVmk6IE5vdCBvdmVycmlkaW5nIGlycV92ZWN0b3JfbWFwIHNldHRpbmdc
biIpOwogICAgIH0KKyAgICBpZiAoICFhbWRfaW9tbXVfcGVyZGV2X2ludHJl
bWFwICkKKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJBTUQtVmk6
IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUgaXMgbm90IHJl
Y29tbWVuZGVkIChzZWUgWFNBLTM2KSFcbiIpOwogICAgIHJldHVybiBzY2Fu
X3BjaV9kZXZpY2VzKCk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9p
b21tdS5jCkBAIC00OSw3ICs0OSw3IEBAIGJvb2xfdCBfX3JlYWRfbW9zdGx5
IGlvbW11X3FpbnZhbCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21t
dV9pbnRyZW1hcCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21tdV9o
YXBfcHRfc2hhcmU7CiBib29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVf
ZGVidWc7Ci1ib29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVfcGVyZGV2
X2ludHJlbWFwOworYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lvbW11X3Bl
cmRldl9pbnRyZW1hcCA9IDE7CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBwYXJz
ZV9pb21tdV9wYXJhbShjaGFyICpzKQogewpAQCAtNzgsNiArNzgsOCBAQCBz
dGF0aWMgdm9pZCBfX2luaXQgcGFyc2VfaW9tbXVfcGFyYW0oY2hhCiAgICAg
ICAgICAgICBhbWRfaW9tbXVfZGVidWcgPSAxOwogICAgICAgICBlbHNlIGlm
ICggIXN0cmNtcChzLCAiYW1kLWlvbW11LXBlcmRldi1pbnRyZW1hcCIpICkK
ICAgICAgICAgICAgIGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAgPSAxOwor
ICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzLCAiYW1kLWlvbW11LWdsb2Jh
bC1pbnRyZW1hcCIpICkKKyAgICAgICAgICAgIGFtZF9pb21tdV9wZXJkZXZf
aW50cmVtYXAgPSAwOwogICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzLCAi
ZG9tMC1wYXNzdGhyb3VnaCIpICkKICAgICAgICAgICAgIGlvbW11X3Bhc3N0
aHJvdWdoID0gMTsKICAgICAgICAgZWxzZSBpZiAoICFzdHJjbXAocywgImRv
bTAtc3RyaWN0IikgKQotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9z
dm0vYW1kLWlvbW11LXByb3RvLmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4
Ni9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oCkBAIC04OCw2ICs4OCwxMSBA
QCB2b2lkIGFtZF9pb21tdV9yZWFkX21zaV9mcm9tX2lyZSgKIHVuc2lnbmVk
IGludCBhbWRfaW9tbXVfcmVhZF9pb2FwaWNfZnJvbV9pcmUoCiAgICAgdW5z
aWduZWQgaW50IGFwaWMsIHVuc2lnbmVkIGludCByZWcpOwogCitleHRlcm4g
c3RydWN0IGlvYXBpY19iZGYgeworICAgIHUxNiBiZGY7CisgICAgdW5zaWdu
ZWQgbG9uZyAqcGluX3NldHVwOworfSBpb2FwaWNfYmRmW107CisKIC8qIHBv
d2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAqLwogdm9pZCBhbWRfaW9tbXVfcmVz
dW1lKHZvaWQpOwogdm9pZCBhbWRfaW9tbXVfc3VzcGVuZCh2b2lkKTsK

--=separator
Content-Type: application/octet-stream; name="xsa36-4.2.patch"
Content-Disposition: attachment; filename="xsa36-4.2.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgotLS0g
YS94ZW4vYXJjaC94ODYvaXJxLmMKKysrIGIveGVuL2FyY2gveDg2L2lycS5j
CkBAIC0xOTQyLDkgKzE5NDIsNiBAQCBpbnQgbWFwX2RvbWFpbl9waXJxKAog
ICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3Mp
OwogICAgICAgICBzZXRfZG9tYWluX2lycV9waXJxKGQsIGlycSwgaW5mbyk7
CiAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ss
IGZsYWdzKTsKLQotICAgICAgICBpZiAoIG9wdF9pcnFfdmVjdG9yX21hcCA9
PSBPUFRfSVJRX1ZFQ1RPUl9NQVBfUEVSREVWICkKLSAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfSU5GTyAiUGVyLWRldmljZSB2ZWN0b3IgbWFwcyBmb3Ig
R1NJcyBub3QgaW1wbGVtZW50ZWQgeWV0LlxuIik7CiAgICAgfQogCiBkb25l
OgotLS0gYS94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCisrKyBiL3hlbi9k
cml2ZXJzL2FjcGkvdGFibGVzLmMKQEAgLTI2Nyw3ICsyNjcsNyBAQCBhY3Bp
X3RhYmxlX3BhcnNlX21hZHQoZW51bSBhY3BpX21hZHRfdHlwCiAgKiBAaGFu
ZGxlcjogaGFuZGxlciB0byBydW4KICAqCiAgKiBTY2FuIHRoZSBBQ1BJIFN5
c3RlbSBEZXNjcmlwdG9yIFRhYmxlIChTVEQpIGZvciBhIHRhYmxlIG1hdGNo
aW5nIEBpZCwKLSAqIHJ1biBAaGFuZGxlciBvbiBpdC4gIFJldHVybiAwIGlm
IHRhYmxlIGZvdW5kLCByZXR1cm4gb24gaWYgbm90LgorICogcnVuIEBoYW5k
bGVyIG9uIGl0LgogICovCiBpbnQgX19pbml0IGFjcGlfdGFibGVfcGFyc2Uo
Y2hhciAqaWQsIGFjcGlfdGFibGVfaGFuZGxlciBoYW5kbGVyKQogewpAQCAt
MjgyLDggKzI4Miw3IEBAIGludCBfX2luaXQgYWNwaV90YWJsZV9wYXJzZShj
aGFyICppZCwgYWMKIAkJYWNwaV9nZXRfdGFibGUoaWQsIDAsICZ0YWJsZSk7
CiAKIAlpZiAodGFibGUpIHsKLQkJaGFuZGxlcih0YWJsZSk7Ci0JCXJldHVy
biAwOworCQlyZXR1cm4gaGFuZGxlcih0YWJsZSk7CiAJfSBlbHNlCiAJCXJl
dHVybiAxOwogfQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQv
aW9tbXVfYWNwaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9hY3BpLmMKQEAgLTIyLDYgKzIyLDcgQEAKICNpbmNsdWRlIDx4
ZW4vZXJybm8uaD4KICNpbmNsdWRlIDx4ZW4vYWNwaS5oPgogI2luY2x1ZGUg
PGFzbS9hcGljZGVmLmg+CisjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4KICNp
bmNsdWRlIDxhc20vYW1kLWlvbW11Lmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9z
dm0vYW1kLWlvbW11LXByb3RvLmg+CiAKQEAgLTYzNSw2ICs2MzYsNyBAQCBz
dGF0aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAg
dTE2IGhlYWRlcl9sZW5ndGgsIHUxNiBibG9ja19sZW5ndGgsIHN0cnVjdCBh
bWRfaW9tbXUgKmlvbW11KQogewogICAgIHUxNiBkZXZfbGVuZ3RoLCBiZGY7
CisgICAgaW50IGFwaWM7CiAKICAgICBkZXZfbGVuZ3RoID0gc2l6ZW9mKCpz
cGVjaWFsKTsKICAgICBpZiAoIGhlYWRlcl9sZW5ndGggPCAoYmxvY2tfbGVu
Z3RoICsgZGV2X2xlbmd0aCkgKQpAQCAtNjUxLDEwICs2NTMsNTkgQEAgc3Rh
dGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZpY2Vfc3BlYwogICAgIH0K
IAogICAgIGFkZF9pdnJzX21hcHBpbmdfZW50cnkoYmRmLCBiZGYsIHNwZWNp
YWwtPmhlYWRlci5kYXRhX3NldHRpbmcsIGlvbW11KTsKLSAgICAvKiBzZXQg
ZGV2aWNlIGlkIG9mIGlvYXBpYyAqLwotICAgIGlvYXBpY19zYmRmW3NwZWNp
YWwtPmhhbmRsZV0uYmRmID0gYmRmOwotICAgIGlvYXBpY19zYmRmW3NwZWNp
YWwtPmhhbmRsZV0uc2VnID0gc2VnOwotICAgIHJldHVybiBkZXZfbGVuZ3Ro
OworCisgICAgaWYgKCBzcGVjaWFsLT52YXJpZXR5ICE9IEFDUElfSVZIRF9J
T0FQSUMgKQorICAgIHsKKyAgICAgICAgaWYgKCBzcGVjaWFsLT52YXJpZXR5
ICE9IEFDUElfSVZIRF9IUEVUICkKKyAgICAgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSICJVbnJlY29nbml6ZWQgSVZIRCBzcGVjaWFsIHZhcmlldHkgJSN4
XG4iLAorICAgICAgICAgICAgICAgICAgIHNwZWNpYWwtPnZhcmlldHkpOwor
ICAgICAgICByZXR1cm4gZGV2X2xlbmd0aDsKKyAgICB9CisKKyAgICAvKgor
ICAgICAqIFNvbWUgQklPU2VzIGhhdmUgSU9BUElDIGJyb2tlbiBlbnRyaWVz
IHNvIHdlIGNoZWNrIGZvciBJVlJTCisgICAgICogY29uc2lzdGVuY3kgaGVy
ZSAtLS0gd2hldGhlciBlbnRyeSdzIElPQVBJQyBJRCBpcyB2YWxpZCBhbmQK
KyAgICAgKiB3aGV0aGVyIHRoZXJlIGFyZSBjb25mbGljdGluZy9kdXBsaWNh
dGVkIGVudHJpZXMuCisgICAgICovCisgICAgZm9yICggYXBpYyA9IDA7IGFw
aWMgPCBucl9pb2FwaWNzOyBhcGljKysgKQorICAgIHsKKyAgICAgICAgaWYg
KCBJT19BUElDX0lEKGFwaWMpICE9IHNwZWNpYWwtPmhhbmRsZSApCisgICAg
ICAgICAgICBjb250aW51ZTsKKworICAgICAgICBpZiAoIGlvYXBpY19zYmRm
W3NwZWNpYWwtPmhhbmRsZV0ucGluX3NldHVwICkKKyAgICAgICAgeworICAg
ICAgICAgICAgaWYgKCBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLmJk
ZiA9PSBiZGYgJiYKKyAgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZbc3Bl
Y2lhbC0+aGFuZGxlXS5zZWcgPT0gc2VnICkKKyAgICAgICAgICAgICAgICBB
TURfSU9NTVVfREVCVUcoIklWSEQgV2FybmluZzogRHVwbGljYXRlIElPLUFQ
SUMgJSN4IGVudHJpZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHNwZWNpYWwtPmhhbmRsZSk7CisgICAgICAgICAgICBlbHNlCisg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19F
UlIgIklWSEQgRXJyb3I6IENvbmZsaWN0aW5nIElPLUFQSUMgJSN4IGVudHJp
ZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpYWwtPmhhbmRs
ZSk7CisgICAgICAgICAgICAgICAgaWYgKCBhbWRfaW9tbXVfcGVyZGV2X2lu
dHJlbWFwICkKKyAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDA7CisgICAg
ICAgICAgICB9CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICB7
CisgICAgICAgICAgICAvKiBzZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyAqLwor
ICAgICAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lhbC0+aGFuZGxlXS5iZGYg
PSBiZGY7CisgICAgICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5k
bGVdLnNlZyA9IHNlZzsKKworICAgICAgICAgICAgaW9hcGljX3NiZGZbc3Bl
Y2lhbC0+aGFuZGxlXS5waW5fc2V0dXAgPSB4emFsbG9jX2FycmF5KAorICAg
ICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9fTE9OR1MobnJf
aW9hcGljX2VudHJpZXNbYXBpY10pKTsKKyAgICAgICAgICAgIGlmICggbnJf
aW9hcGljX2VudHJpZXNbYXBpY10gJiYKKyAgICAgICAgICAgICAgICAgIWlv
YXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCApCisgICAg
ICAgICAgICB7CisgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIg
IklWSEQgRXJyb3I6IE91dCBvZiBtZW1vcnlcbiIpOworICAgICAgICAgICAg
ICAgIHJldHVybiAwOworICAgICAgICAgICAgfQorICAgICAgICB9CisgICAg
ICAgIHJldHVybiBkZXZfbGVuZ3RoOworICAgIH0KKworICAgIHByaW50ayhY
RU5MT0dfRVJSICJJVkhEIEVycm9yOiBJbnZhbGlkIElPLUFQSUMgJSN4XG4i
LCBzcGVjaWFsLT5oYW5kbGUpOworICAgIHJldHVybiAwOwogfQogCiBzdGF0
aWMgaW50IF9faW5pdCBwYXJzZV9pdmhkX2Jsb2NrKGNvbnN0IHN0cnVjdCBh
Y3BpX2l2cnNfaGFyZHdhcmUgKml2aGRfYmxvY2spCi0tLSBhL3hlbi9kcml2
ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbml0LmMKKysrIGIveGVuL2Ry
aXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2luaXQuYwpAQCAtMTEyNiwx
MiArMTEyNiw0NSBAQCBzdGF0aWMgaW50IF9faW5pdCBhbWRfaW9tbXVfc2V0
dXBfZGV2aWNlCiAgICAgcmV0dXJuIDA7CiB9CiAKKy8qIENoZWNrIHdoZXRo
ZXIgU1A1MTAwIFNBVEEgQ29tYmluZWQgbW9kZSBpcyBvbiAqLworc3RhdGlj
IGJvb2xfdCBfX2luaXQgYW1kX3NwNTEwMF9lcnJhdHVtMjgodm9pZCkKK3sK
KyAgICB1MzIgYnVzLCBpZDsKKyAgICB1MTYgdmVuZG9yX2lkLCBkZXZfaWQ7
CisgICAgdTggYnl0ZTsKKworICAgIGZvciAoYnVzID0gMDsgYnVzIDwgMjU2
OyBidXMrKykKKyAgICB7CisgICAgICAgIGlkID0gcGNpX2NvbmZfcmVhZDMy
KDAsIGJ1cywgMHgxNCwgMCwgUENJX1ZFTkRPUl9JRCk7CisKKyAgICAgICAg
dmVuZG9yX2lkID0gaWQgJiAweGZmZmY7CisgICAgICAgIGRldl9pZCA9IChp
ZCA+PiAxNikgJiAweGZmZmY7CisKKyAgICAgICAgLyogU1A1MTAwIFNNQnVz
IG1vZHVsZSBzZXRzIENvbWJpbmVkIG1vZGUgb24gKi8KKyAgICAgICAgaWYg
KHZlbmRvcl9pZCAhPSAweDEwMDIgfHwgZGV2X2lkICE9IDB4NDM4NSkKKyAg
ICAgICAgICAgIGNvbnRpbnVlOworCisgICAgICAgIGJ5dGUgPSBwY2lfY29u
Zl9yZWFkOCgwLCBidXMsIDB4MTQsIDAsIDB4YWQpOworICAgICAgICBpZiAo
IChieXRlID4+IDMpICYgMSApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfV0FSTklORyAiQU1ELVZpOiBTUDUxMDAgZXJyYXR1bSAy
OCBkZXRlY3RlZCwgZGlzYWJsaW5nIElPTU1VLlxuIgorICAgICAgICAgICAg
ICAgICAgICJJZiBwb3NzaWJsZSwgZGlzYWJsZSBTQVRBIENvbWJpbmVkIG1v
ZGUgaW4gQklPUyBvciBjb250YWN0IHlvdXIgdmVuZG9yIGZvciBCSU9TIHVw
ZGF0ZS5cbiIpOworICAgICAgICAgICAgcmV0dXJuIDE7CisgICAgICAgIH0K
KyAgICB9CisKKyAgICByZXR1cm4gMDsKK30KKwogaW50IF9faW5pdCBhbWRf
aW9tbXVfaW5pdCh2b2lkKQogewogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlv
bW11OwogCiAgICAgQlVHX09OKCAhaW9tbXVfZm91bmQoKSApOwogCisgICAg
aWYgKCBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICYmIGFtZF9zcDUxMDBf
ZXJyYXR1bTI4KCkgKQorICAgICAgICBnb3RvIGVycm9yX291dDsKKwogICAg
IGl2cnNfYmRmX2VudHJpZXMgPSBhbWRfaW9tbXVfZ2V0X2l2cnNfZGV2X2Vu
dHJpZXMoKTsKIAogICAgIGlmICggIWl2cnNfYmRmX2VudHJpZXMgKQotLS0g
YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW50ci5jCisr
KyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbnRyLmMK
QEAgLTk5LDEyICs5OSwxMiBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVt
YXBfZW50cnkodTMyKiBlCiBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBf
ZW50cnlfZnJvbV9pb2FwaWMoCiAgICAgaW50IGJkZiwKICAgICBzdHJ1Y3Qg
YW1kX2lvbW11ICppb21tdSwKLSAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9l
bnRyeSAqaW9hcGljX3J0ZSkKKyAgICBjb25zdCBzdHJ1Y3QgSU9fQVBJQ19y
b3V0ZV9lbnRyeSAqcnRlLAorICAgIGNvbnN0IHN0cnVjdCBJT19BUElDX3Jv
dXRlX2VudHJ5ICpvbGRfcnRlKQogewogICAgIHVuc2lnbmVkIGxvbmcgZmxh
Z3M7CiAgICAgdTMyKiBlbnRyeTsKICAgICB1OCBkZWxpdmVyeV9tb2RlLCBk
ZXN0LCB2ZWN0b3IsIGRlc3RfbW9kZTsKLSAgICBzdHJ1Y3QgSU9fQVBJQ19y
b3V0ZV9lbnRyeSAqcnRlID0gaW9hcGljX3J0ZTsKICAgICBpbnQgcmVxX2lk
OwogICAgIHNwaW5sb2NrX3QgKmxvY2s7CiAgICAgaW50IG9mZnNldDsKQEAg
LTEyMCw2ICsxMjAsMTQgQEAgc3RhdGljIHZvaWQgdXBkYXRlX2ludHJlbWFw
X2VudHJ5X2Zyb21faQogICAgIHNwaW5fbG9ja19pcnFzYXZlKGxvY2ssIGZs
YWdzKTsKIAogICAgIG9mZnNldCA9IGdldF9pbnRyZW1hcF9vZmZzZXQodmVj
dG9yLCBkZWxpdmVyeV9tb2RlKTsKKyAgICBpZiAoIG9sZF9ydGUgKQorICAg
IHsKKyAgICAgICAgaW50IG9sZF9vZmZzZXQgPSBnZXRfaW50cmVtYXBfb2Zm
c2V0KG9sZF9ydGUtPnZlY3RvciwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG9sZF9ydGUtPmRlbGl2ZXJ5X21vZGUp
OworCisgICAgICAgIGlmICggb2Zmc2V0ICE9IG9sZF9vZmZzZXQgKQorICAg
ICAgICAgICAgZnJlZV9pbnRyZW1hcF9lbnRyeShpb21tdS0+c2VnLCBiZGYs
IG9sZF9vZmZzZXQpOworICAgIH0KICAgICBlbnRyeSA9ICh1MzIqKWdldF9p
bnRyZW1hcF9lbnRyeShpb21tdS0+c2VnLCByZXFfaWQsIG9mZnNldCk7CiAg
ICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5KGVudHJ5LCB2ZWN0b3IsIGRlbGl2
ZXJ5X21vZGUsIGRlc3RfbW9kZSwgZGVzdCk7CiAKQEAgLTE4OCw2ICsxOTYs
NyBAQCBpbnQgX19pbml0IGFtZF9pb21tdV9zZXR1cF9pb2FwaWNfcmVtYXBw
CiAgICAgICAgICAgICAgICAgYW1kX2lvbW11X2ZsdXNoX2ludHJlbWFwKGlv
bW11LCByZXFfaWQpOwogICAgICAgICAgICAgICAgIHNwaW5fdW5sb2NrX2ly
cXJlc3RvcmUoJmlvbW11LT5sb2NrLCBmbGFncyk7CiAgICAgICAgICAgICB9
CisgICAgICAgICAgICBzZXRfYml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJ
Q19JRChhcGljKV0ucGluX3NldHVwKTsKICAgICAgICAgfQogICAgIH0KICAg
ICByZXR1cm4gMDsKQEAgLTE5OSw2ICsyMDgsNyBAQCB2b2lkIGFtZF9pb21t
dV9pb2FwaWNfdXBkYXRlX2lyZSgKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0
ZV9lbnRyeSBvbGRfcnRlID0geyAwIH07CiAgICAgc3RydWN0IElPX0FQSUNf
cm91dGVfZW50cnkgbmV3X3J0ZSA9IHsgMCB9OwogICAgIHVuc2lnbmVkIGlu
dCBydGVfbG8gPSAocmVnICYgMSkgPyByZWcgLSAxIDogcmVnOworICAgIHVu
c2lnbmVkIGludCBwaW4gPSAocmVnIC0gMHgxMCkgLyAyOwogICAgIGludCBz
YXZlZF9tYXNrLCBzZWcsIGJkZjsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICpp
b21tdTsKIApAQCAtMjM2LDYgKzI0NiwxNCBAQCB2b2lkIGFtZF9pb21tdV9p
b2FwaWNfdXBkYXRlX2lyZSgKICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRl
KSArIDEpID0gdmFsdWU7CiAgICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1h
c2sgJiYKKyAgICAgICAgICF0ZXN0X2JpdChwaW4sIGlvYXBpY19zYmRmW0lP
X0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCkgKQorICAgIHsKKyAgICAgICAg
QVNTRVJUKHNhdmVkX21hc2spOworICAgICAgICBfX2lvX2FwaWNfd3JpdGUo
YXBpYywgcmVnLCB2YWx1ZSk7CisgICAgICAgIHJldHVybjsKKyAgICB9CisK
ICAgICAvKiBtYXNrIHRoZSBpbnRlcnJ1cHQgd2hpbGUgd2UgY2hhbmdlIHRo
ZSBpbnRyZW1hcCB0YWJsZSAqLwogICAgIGlmICggIXNhdmVkX21hc2sgKQog
ICAgIHsKQEAgLTI0NCw3ICsyNjIsMTEgQEAgdm9pZCBhbWRfaW9tbXVfaW9h
cGljX3VwZGF0ZV9pcmUoCiAgICAgfQogCiAgICAgLyogVXBkYXRlIGludGVy
cnVwdCByZW1hcHBpbmcgZW50cnkgKi8KLSAgICB1cGRhdGVfaW50cmVtYXBf
ZW50cnlfZnJvbV9pb2FwaWMoYmRmLCBpb21tdSwgJm5ld19ydGUpOworICAg
IHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lvYXBpYygKKyAgICAgICAg
YmRmLCBpb21tdSwgJm5ld19ydGUsCisgICAgICAgIHRlc3RfYW5kX3NldF9i
aXQocGluLAorICAgICAgICAgICAgICAgICAgICAgICAgIGlvYXBpY19zYmRm
W0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCkgPyAmb2xkX3J0ZQorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgOiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQg
d3JpdGUgYWNjZXNzIHRvIElPLUFQSUMgUlRFICovCiAgICAgX19pb19hcGlj
X3dyaXRlKGFwaWMsIHJlZywgdmFsdWUpOwpAQCAtMzU0LDYgKzM3NiwxMiBA
QCB2b2lkIGFtZF9pb21tdV9tc2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAg
IHJldHVybjsKICAgICB9CiAKKyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9p
bmRleCA+PSAwICkKKyAgICAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zy
b21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIE5VTEwpOworCisg
ICAgaWYgKCAhbXNnICkKKyAgICAgICAgcmV0dXJuOworCiAgICAgdXBkYXRl
X2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNp
X2Rlc2MsIG1zZyk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91
Z2gvYW1kL3BjaV9hbWRfaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvcGNpX2FtZF9pb21tdS5jCkBAIC0yMDUsNiArMjA1LDgg
QEAgaW50IF9faW5pdCBhbWRfaW92X2RldGVjdCh2b2lkKQogICAgIHsKICAg
ICAgICAgcHJpbnRrKCJBTUQtVmk6IE5vdCBvdmVycmlkaW5nIGlycV92ZWN0
b3JfbWFwIHNldHRpbmdcbiIpOwogICAgIH0KKyAgICBpZiAoICFhbWRfaW9t
bXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgcHJpbnRrKFhFTkxPR19X
QVJOSU5HICJBTUQtVmk6IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAg
dGFibGUgaXMgbm90IHJlY29tbWVuZGVkIChzZWUgWFNBLTM2KSFcbiIpOwog
ICAgIHJldHVybiBzY2FuX3BjaV9kZXZpY2VzKCk7CiB9CiAKLS0tIGEveGVu
L2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9tbXUuYworKysgYi94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9pb21tdS5jCkBAIC01Miw3ICs1Miw3IEBAIGJvb2xf
dCBfX3JlYWRfbW9zdGx5IGlvbW11X3FpbnZhbCA9IDE7CiBib29sX3QgX19y
ZWFkX21vc3RseSBpb21tdV9pbnRyZW1hcCA9IDE7CiBib29sX3QgX19yZWFk
X21vc3RseSBpb21tdV9oYXBfcHRfc2hhcmUgPSAxOwogYm9vbF90IF9fcmVh
ZF9tb3N0bHkgaW9tbXVfZGVidWc7Ci1ib29sX3QgX19yZWFkX21vc3RseSBh
bWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwOworYm9vbF90IF9fcmVhZF9tb3N0
bHkgYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCA9IDE7CiAKIERFRklORV9Q
RVJfQ1BVKGJvb2xfdCwgaW9tbXVfZG9udF9mbHVzaF9pb3RsYik7CiAKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL2FtZC1pb21tdS1wcm90
by5oCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3N2bS9hbWQtaW9t
bXUtcHJvdG8uaApAQCAtMTAwLDYgKzEwMCw3IEBAIHZvaWQgYW1kX2lvbW11
X3JlYWRfbXNpX2Zyb21faXJlKAogCiBleHRlcm4gc3RydWN0IGlvYXBpY19z
YmRmIHsKICAgICB1MTYgYmRmLCBzZWc7CisgICAgdW5zaWduZWQgbG9uZyAq
cGluX3NldHVwOwogfSBpb2FwaWNfc2JkZltNQVhfSU9fQVBJQ1NdOwogZXh0
ZXJuIHZvaWQgKnNoYXJlZF9pbnRyZW1hcF90YWJsZTsKIAo=

--=separator
Content-Type: application/octet-stream; name="xsa36-unstable.patch"
Content-Disposition: attachment; filename="xsa36-unstable.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgotLS0g
YS94ZW4vYXJjaC94ODYvaXJxLmMKKysrIGIveGVuL2FyY2gveDg2L2lycS5j
CkBAIC0xOTQzLDkgKzE5NDMsNiBAQCBpbnQgbWFwX2RvbWFpbl9waXJxKAog
ICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmZGVzYy0+bG9jaywgZmxhZ3Mp
OwogICAgICAgICBzZXRfZG9tYWluX2lycV9waXJxKGQsIGlycSwgaW5mbyk7
CiAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmRlc2MtPmxvY2ss
IGZsYWdzKTsKLQotICAgICAgICBpZiAoIG9wdF9pcnFfdmVjdG9yX21hcCA9
PSBPUFRfSVJRX1ZFQ1RPUl9NQVBfUEVSREVWICkKLSAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfSU5GTyAiUGVyLWRldmljZSB2ZWN0b3IgbWFwcyBmb3Ig
R1NJcyBub3QgaW1wbGVtZW50ZWQgeWV0LlxuIik7CiAgICAgfQogCiBkb25l
OgotLS0gYS94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCisrKyBiL3hlbi9k
cml2ZXJzL2FjcGkvdGFibGVzLmMKQEAgLTI2NSw3ICsyNjUsNyBAQCBhY3Bp
X3RhYmxlX3BhcnNlX21hZHQoZW51bSBhY3BpX21hZHRfdHlwCiAgKiBAaGFu
ZGxlcjogaGFuZGxlciB0byBydW4KICAqCiAgKiBTY2FuIHRoZSBBQ1BJIFN5
c3RlbSBEZXNjcmlwdG9yIFRhYmxlIChTVEQpIGZvciBhIHRhYmxlIG1hdGNo
aW5nIEBpZCwKLSAqIHJ1biBAaGFuZGxlciBvbiBpdC4gIFJldHVybiAwIGlm
IHRhYmxlIGZvdW5kLCByZXR1cm4gb24gaWYgbm90LgorICogcnVuIEBoYW5k
bGVyIG9uIGl0LgogICovCiBpbnQgX19pbml0IGFjcGlfdGFibGVfcGFyc2Uo
Y2hhciAqaWQsIGFjcGlfdGFibGVfaGFuZGxlciBoYW5kbGVyKQogewpAQCAt
MjgwLDggKzI4MCw3IEBAIGludCBfX2luaXQgYWNwaV90YWJsZV9wYXJzZShj
aGFyICppZCwgYWMKIAkJYWNwaV9nZXRfdGFibGUoaWQsIDAsICZ0YWJsZSk7
CiAKIAlpZiAodGFibGUpIHsKLQkJaGFuZGxlcih0YWJsZSk7Ci0JCXJldHVy
biAwOworCQlyZXR1cm4gaGFuZGxlcih0YWJsZSk7CiAJfSBlbHNlCiAJCXJl
dHVybiAxOwogfQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQv
aW9tbXVfYWNwaS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9hY3BpLmMKQEAgLTIyLDYgKzIyLDcgQEAKICNpbmNsdWRlIDx4
ZW4vZXJybm8uaD4KICNpbmNsdWRlIDx4ZW4vYWNwaS5oPgogI2luY2x1ZGUg
PGFzbS9hcGljZGVmLmg+CisjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4KICNp
bmNsdWRlIDxhc20vYW1kLWlvbW11Lmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9z
dm0vYW1kLWlvbW11LXByb3RvLmg+CiAKQEAgLTYzNyw2ICs2MzgsNyBAQCBz
dGF0aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAg
dTE2IGhlYWRlcl9sZW5ndGgsIHUxNiBibG9ja19sZW5ndGgsIHN0cnVjdCBh
bWRfaW9tbXUgKmlvbW11KQogewogICAgIHUxNiBkZXZfbGVuZ3RoLCBiZGY7
CisgICAgaW50IGFwaWM7CiAKICAgICBkZXZfbGVuZ3RoID0gc2l6ZW9mKCpz
cGVjaWFsKTsKICAgICBpZiAoIGhlYWRlcl9sZW5ndGggPCAoYmxvY2tfbGVu
Z3RoICsgZGV2X2xlbmd0aCkgKQpAQCAtNjU3LDkgKzY1OSw1MyBAQCBzdGF0
aWMgdTE2IF9faW5pdCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAgc3dp
dGNoICggc3BlY2lhbC0+dmFyaWV0eSApCiAgICAgewogICAgIGNhc2UgQUNQ
SV9JVkhEX0lPQVBJQzoKLSAgICAvKiBzZXQgZGV2aWNlIGlkIG9mIGlvYXBp
YyAqLwotICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLmJk
ZiA9IGJkZjsKLSAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lhbC0+aGFuZGxl
XS5zZWcgPSBzZWc7CisgICAgICAgIC8qCisgICAgICAgICAqIFNvbWUgQklP
U2VzIGhhdmUgSU9BUElDIGJyb2tlbiBlbnRyaWVzIHNvIHdlIGNoZWNrIGZv
ciBJVlJTCisgICAgICAgICAqIGNvbnNpc3RlbmN5IGhlcmUgLS0tIHdoZXRo
ZXIgZW50cnkncyBJT0FQSUMgSUQgaXMgdmFsaWQgYW5kCisgICAgICAgICAq
IHdoZXRoZXIgdGhlcmUgYXJlIGNvbmZsaWN0aW5nL2R1cGxpY2F0ZWQgZW50
cmllcy4KKyAgICAgICAgICovCisgICAgICAgIGZvciAoIGFwaWMgPSAwOyBh
cGljIDwgbnJfaW9hcGljczsgYXBpYysrICkKKyAgICAgICAgeworICAgICAg
ICAgICAgaWYgKCBJT19BUElDX0lEKGFwaWMpICE9IHNwZWNpYWwtPmhhbmRs
ZSApCisgICAgICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgICAg
IGlmICggaW9hcGljX3NiZGZbc3BlY2lhbC0+aGFuZGxlXS5waW5fc2V0dXAg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGlmICggaW9hcGlj
X3NiZGZbc3BlY2lhbC0+aGFuZGxlXS5iZGYgPT0gYmRmICYmCisgICAgICAg
ICAgICAgICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLnNl
ZyA9PSBzZWcgKQorICAgICAgICAgICAgICAgICAgICBBTURfSU9NTVVfREVC
VUcoIklWSEQgV2FybmluZzogRHVwbGljYXRlIElPLUFQSUMgJSN4IGVudHJp
ZXNcbiIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
cGVjaWFsLT5oYW5kbGUpOworICAgICAgICAgICAgICAgIGVsc2UKKyAgICAg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgIHByaW50ayhYRU5M
T0dfRVJSICJJVkhEIEVycm9yOiBDb25mbGljdGluZyBJTy1BUElDICUjeCBl
bnRyaWVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lh
bC0+aGFuZGxlKTsKKyAgICAgICAgICAgICAgICAgICAgaWYgKCBhbWRfaW9t
bXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgICAgICAgICAgICAgICAg
IHJldHVybiAwOworICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIH0K
KyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAg
ICAgICAvKiBzZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyAqLworICAgICAgICAg
ICAgICAgIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0uYmRmID0gYmRm
OworICAgICAgICAgICAgICAgIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRs
ZV0uc2VnID0gc2VnOworCisgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZb
c3BlY2lhbC0+aGFuZGxlXS5waW5fc2V0dXAgPSB4emFsbG9jX2FycmF5KAor
ICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nLCBCSVRTX1RPX0xP
TkdTKG5yX2lvYXBpY19lbnRyaWVzW2FwaWNdKSk7CisgICAgICAgICAgICAg
ICAgaWYgKCBucl9pb2FwaWNfZW50cmllc1thcGljXSAmJgorICAgICAgICAg
ICAgICAgICAgICAgIWlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBp
bl9zZXR1cCApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogT3V0IG9mIG1l
bW9yeVxuIik7CisgICAgICAgICAgICAgICAgICAgIHJldHVybiAwOworICAg
ICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGJy
ZWFrOworICAgICAgICB9CisgICAgICAgIGlmICggYXBpYyA9PSBucl9pb2Fw
aWNzICkKKyAgICAgICAgeworICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19F
UlIgIklWSEQgRXJyb3I6IEludmFsaWQgSU8tQVBJQyAlI3hcbiIsCisgICAg
ICAgICAgICAgICAgICAgc3BlY2lhbC0+aGFuZGxlKTsKKyAgICAgICAgICAg
IHJldHVybiAwOworICAgICAgICB9CiAgICAgICAgIGJyZWFrOwogICAgIGNh
c2UgQUNQSV9JVkhEX0hQRVQ6CiAgICAgICAgIC8qIHNldCBkZXZpY2UgaWQg
b2YgaHBldCAqLwotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQv
aW9tbXVfaW5pdC5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9pbml0LmMKQEAgLTExMjAsMTIgKzExMjAsNDUgQEAgc3RhdGlj
IGludCBfX2luaXQgYW1kX2lvbW11X3NldHVwX2RldmljZQogICAgIHJldHVy
biAwOwogfQogCisvKiBDaGVjayB3aGV0aGVyIFNQNTEwMCBTQVRBIENvbWJp
bmVkIG1vZGUgaXMgb24gKi8KK3N0YXRpYyBib29sX3QgX19pbml0IGFtZF9z
cDUxMDBfZXJyYXR1bTI4KHZvaWQpCit7CisgICAgdTMyIGJ1cywgaWQ7Cisg
ICAgdTE2IHZlbmRvcl9pZCwgZGV2X2lkOworICAgIHU4IGJ5dGU7CisKKyAg
ICBmb3IgKGJ1cyA9IDA7IGJ1cyA8IDI1NjsgYnVzKyspCisgICAgeworICAg
ICAgICBpZCA9IHBjaV9jb25mX3JlYWQzMigwLCBidXMsIDB4MTQsIDAsIFBD
SV9WRU5ET1JfSUQpOworCisgICAgICAgIHZlbmRvcl9pZCA9IGlkICYgMHhm
ZmZmOworICAgICAgICBkZXZfaWQgPSAoaWQgPj4gMTYpICYgMHhmZmZmOwor
CisgICAgICAgIC8qIFNQNTEwMCBTTUJ1cyBtb2R1bGUgc2V0cyBDb21iaW5l
ZCBtb2RlIG9uICovCisgICAgICAgIGlmICh2ZW5kb3JfaWQgIT0gMHgxMDAy
IHx8IGRldl9pZCAhPSAweDQzODUpCisgICAgICAgICAgICBjb250aW51ZTsK
KworICAgICAgICBieXRlID0gcGNpX2NvbmZfcmVhZDgoMCwgYnVzLCAweDE0
LCAwLCAweGFkKTsKKyAgICAgICAgaWYgKCAoYnl0ZSA+PiAzKSAmIDEgKQor
ICAgICAgICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcg
IkFNRC1WaTogU1A1MTAwIGVycmF0dW0gMjggZGV0ZWN0ZWQsIGRpc2FibGlu
ZyBJT01NVS5cbiIKKyAgICAgICAgICAgICAgICAgICAiSWYgcG9zc2libGUs
IGRpc2FibGUgU0FUQSBDb21iaW5lZCBtb2RlIGluIEJJT1Mgb3IgY29udGFj
dCB5b3VyIHZlbmRvciBmb3IgQklPUyB1cGRhdGUuXG4iKTsKKyAgICAgICAg
ICAgIHJldHVybiAxOworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJu
IDA7Cit9CisKIGludCBfX2luaXQgYW1kX2lvbW11X2luaXQodm9pZCkKIHsK
ICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIAogICAgIEJVR19PTigg
IWlvbW11X2ZvdW5kKCkgKTsKIAorICAgIGlmICggYW1kX2lvbW11X3BlcmRl
dl9pbnRyZW1hcCAmJiBhbWRfc3A1MTAwX2VycmF0dW0yOCgpICkKKyAgICAg
ICAgZ290byBlcnJvcl9vdXQ7CisKICAgICBpdnJzX2JkZl9lbnRyaWVzID0g
YW1kX2lvbW11X2dldF9pdnJzX2Rldl9lbnRyaWVzKCk7CiAKICAgICBpZiAo
ICFpdnJzX2JkZl9lbnRyaWVzICkKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvYW1kL2lvbW11X2ludHIuYworKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvaW9tbXVfaW50ci5jCkBAIC0xMDAsMTIgKzEwMCwxMiBA
QCBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50cnkodTMyKiBlCiBz
dGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9pb2FwaWMo
CiAgICAgaW50IGJkZiwKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSwK
LSAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqaW9hcGljX3J0ZSkK
KyAgICBjb25zdCBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqcnRlLAor
ICAgIGNvbnN0IHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICpvbGRfcnRl
KQogewogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7CiAgICAgdTMyKiBlbnRy
eTsKICAgICB1OCBkZWxpdmVyeV9tb2RlLCBkZXN0LCB2ZWN0b3IsIGRlc3Rf
bW9kZTsKLSAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqcnRlID0g
aW9hcGljX3J0ZTsKICAgICBpbnQgcmVxX2lkOwogICAgIHNwaW5sb2NrX3Qg
KmxvY2s7CiAgICAgaW50IG9mZnNldDsKQEAgLTEyMSw2ICsxMjEsMTQgQEAg
c3RhdGljIHZvaWQgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faQogICAg
IHNwaW5fbG9ja19pcnFzYXZlKGxvY2ssIGZsYWdzKTsKIAogICAgIG9mZnNl
dCA9IGdldF9pbnRyZW1hcF9vZmZzZXQodmVjdG9yLCBkZWxpdmVyeV9tb2Rl
KTsKKyAgICBpZiAoIG9sZF9ydGUgKQorICAgIHsKKyAgICAgICAgaW50IG9s
ZF9vZmZzZXQgPSBnZXRfaW50cmVtYXBfb2Zmc2V0KG9sZF9ydGUtPnZlY3Rv
ciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG9sZF9ydGUtPmRlbGl2ZXJ5X21vZGUpOworCisgICAgICAgIGlmICgg
b2Zmc2V0ICE9IG9sZF9vZmZzZXQgKQorICAgICAgICAgICAgZnJlZV9pbnRy
ZW1hcF9lbnRyeShpb21tdS0+c2VnLCBiZGYsIG9sZF9vZmZzZXQpOworICAg
IH0KICAgICBlbnRyeSA9ICh1MzIqKWdldF9pbnRyZW1hcF9lbnRyeShpb21t
dS0+c2VnLCByZXFfaWQsIG9mZnNldCk7CiAgICAgdXBkYXRlX2ludHJlbWFw
X2VudHJ5KGVudHJ5LCB2ZWN0b3IsIGRlbGl2ZXJ5X21vZGUsIGRlc3RfbW9k
ZSwgZGVzdCk7CiAKQEAgLTE4OSw2ICsxOTcsNyBAQCBpbnQgX19pbml0IGFt
ZF9pb21tdV9zZXR1cF9pb2FwaWNfcmVtYXBwCiAgICAgICAgICAgICAgICAg
YW1kX2lvbW11X2ZsdXNoX2ludHJlbWFwKGlvbW11LCByZXFfaWQpOwogICAg
ICAgICAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmlvbW11LT5s
b2NrLCBmbGFncyk7CiAgICAgICAgICAgICB9CisgICAgICAgICAgICBzZXRf
Yml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3Nl
dHVwKTsKICAgICAgICAgfQogICAgIH0KICAgICByZXR1cm4gMDsKQEAgLTIw
MCw2ICsyMDksNyBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2ly
ZSgKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSBvbGRfcnRlID0g
eyAwIH07CiAgICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgbmV3X3J0
ZSA9IHsgMCB9OwogICAgIHVuc2lnbmVkIGludCBydGVfbG8gPSAocmVnICYg
MSkgPyByZWcgLSAxIDogcmVnOworICAgIHVuc2lnbmVkIGludCBwaW4gPSAo
cmVnIC0gMHgxMCkgLyAyOwogICAgIGludCBzYXZlZF9tYXNrLCBzZWcsIGJk
ZjsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIApAQCAtMjM3LDYg
KzI0NywxNCBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2lyZSgK
ICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRlKSArIDEpID0gdmFsdWU7CiAg
ICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1hc2sgJiYKKyAgICAgICAgICF0
ZXN0X2JpdChwaW4sIGlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBp
bl9zZXR1cCkgKQorICAgIHsKKyAgICAgICAgQVNTRVJUKHNhdmVkX21hc2sp
OworICAgICAgICBfX2lvX2FwaWNfd3JpdGUoYXBpYywgcmVnLCB2YWx1ZSk7
CisgICAgICAgIHJldHVybjsKKyAgICB9CisKICAgICAvKiBtYXNrIHRoZSBp
bnRlcnJ1cHQgd2hpbGUgd2UgY2hhbmdlIHRoZSBpbnRyZW1hcCB0YWJsZSAq
LwogICAgIGlmICggIXNhdmVkX21hc2sgKQogICAgIHsKQEAgLTI0NSw3ICsy
NjMsMTEgQEAgdm9pZCBhbWRfaW9tbXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAg
ICAgfQogCiAgICAgLyogVXBkYXRlIGludGVycnVwdCByZW1hcHBpbmcgZW50
cnkgKi8KLSAgICB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9pb2FwaWMo
YmRmLCBpb21tdSwgJm5ld19ydGUpOworICAgIHVwZGF0ZV9pbnRyZW1hcF9l
bnRyeV9mcm9tX2lvYXBpYygKKyAgICAgICAgYmRmLCBpb21tdSwgJm5ld19y
dGUsCisgICAgICAgIHRlc3RfYW5kX3NldF9iaXQocGluLAorICAgICAgICAg
ICAgICAgICAgICAgICAgIGlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyld
LnBpbl9zZXR1cCkgPyAmb2xkX3J0ZQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
OiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQgd3JpdGUgYWNjZXNzIHRvIElP
LUFQSUMgUlRFICovCiAgICAgX19pb19hcGljX3dyaXRlKGFwaWMsIHJlZywg
dmFsdWUpOwpAQCAtMzU2LDYgKzM3OCwxMiBAQCB2b2lkIGFtZF9pb21tdV9t
c2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAgIHJldHVybjsKICAgICB9CiAK
KyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9pbmRleCA+PSAwICkKKyAgICAg
ICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21zZyhpb21tdSwg
YmRmLCBtc2lfZGVzYywgTlVMTCk7CisKKyAgICBpZiAoICFtc2cgKQorICAg
ICAgICByZXR1cm47CisKICAgICB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJv
bV9tc2lfbXNnKGlvbW11LCBiZGYsIG1zaV9kZXNjLCBtc2cpOwogfQogCi0t
LSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9wY2lfYW1kX2lvbW11
LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRf
aW9tbXUuYwpAQCAtMjA4LDYgKzIwOCw4IEBAIGludCBfX2luaXQgYW1kX2lv
dl9kZXRlY3Qodm9pZCkKICAgICB7CiAgICAgICAgIHByaW50aygiQU1ELVZp
OiBOb3Qgb3ZlcnJpZGluZyBpcnFfdmVjdG9yX21hcCBzZXR0aW5nXG4iKTsK
ICAgICB9CisgICAgaWYgKCAhYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCAp
CisgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiQU1ELVZpOiBVc2lu
ZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwIHRhYmxlIGlzIG5vdCByZWNvbW1l
bmRlZCAoc2VlIFhTQS0zNikhXG4iKTsKICAgICByZXR1cm4gc2Nhbl9wY2lf
ZGV2aWNlcygpOwogfQogCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L2lvbW11LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9tbXUu
YwpAQCAtNTMsNyArNTMsNyBAQCBib29sX3QgX19yZWFkX21vc3RseSBpb21t
dV9xaW52YWwgPSAxOwogYm9vbF90IF9fcmVhZF9tb3N0bHkgaW9tbXVfaW50
cmVtYXAgPSAxOwogYm9vbF90IF9fcmVhZF9tb3N0bHkgaW9tbXVfaGFwX3B0
X3NoYXJlID0gMTsKIGJvb2xfdCBfX3JlYWRfbW9zdGx5IGlvbW11X2RlYnVn
OwotYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lvbW11X3BlcmRldl9pbnRy
ZW1hcDsKK2Jvb2xfdCBfX3JlYWRfbW9zdGx5IGFtZF9pb21tdV9wZXJkZXZf
aW50cmVtYXAgPSAxOwogCiBERUZJTkVfUEVSX0NQVShib29sX3QsIGlvbW11
X2RvbnRfZmx1c2hfaW90bGIpOwogCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14
ODYvaHZtL3N2bS9hbWQtaW9tbXUtcHJvdG8uaAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L2h2bS9zdm0vYW1kLWlvbW11LXByb3RvLmgKQEAgLTEwMSw2
ICsxMDEsNyBAQCBpbnQgYW1kX3NldHVwX2hwZXRfbXNpKHN0cnVjdCBtc2lf
ZGVzYyAqCiAKIGV4dGVybiBzdHJ1Y3QgaW9hcGljX3NiZGYgewogICAgIHUx
NiBiZGYsIHNlZzsKKyAgICB1bnNpZ25lZCBsb25nICpwaW5fc2V0dXA7CiB9
IGlvYXBpY19zYmRmW01BWF9JT19BUElDU107CiBleHRlcm4gdm9pZCAqc2hh
cmVkX2ludHJlbWFwX3RhYmxlOwogCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:16:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2iO0-0007zU-Lc; Tue, 05 Feb 2013 13:16:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iNy-0007xy-Q3; Tue, 05 Feb 2013 13:16:31 +0000
Received: from [193.109.254.147:30992] by server-15.bemta-14.messagelabs.com
	id 2E/C5-24599-D2601115; Tue, 05 Feb 2013 13:16:29 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360070124!9615039!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14883 invoked from network); 5 Feb 2013 13:15:26 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:26 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMo-0003am-0E; Tue, 05 Feb 2013 13:15:18 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMn-0008As-4b; Tue, 05 Feb 2013 13:15:17 +0000
Date: Tue, 05 Feb 2013 13:15:17 +0000
Message-Id: <E1U2iMn-0008As-4b@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 43 (CVE-2013-0231) - Linux
 pciback DoS via not rate limited log 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen Security Advisory CVE-2013-0231 / XSA-43
			      version 2

         Linux pciback DoS via not rate limited log messages.

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

Xen's PCI backend drivers in Linux allow a guest with assigned PCI device(s)
to cause a DoS through a flood of kernel messages, potentially affecting other
domains in the system.

IMPACT
======

A malicious guest can mount a DoS affecting the entire system.

VULNERABLE SYSTEMS
==================

All systems running guests with access to passed through PCI devices are
vulnerable.

Both mainline ("pvops") and classic-Xen patch kernels are affected.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted
guests.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa43-pvops.patch            Apply to mainline Linux 3.8-rc5.
xsa43-classic.patch          Apply to linux-2.6.18-xen tree.

$ sha256sum xsa43*.patch
4dec2d9b043bce2b8b54578573ba254fa7e6cbf4640cd100f40d8bf8a5a6a470  xsa43-classic.patch
6efe83c9951dcba20f18095814d19089e19230c6876bbdab32cc2f1165bb07c8  xsa43-pvops.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQI+AAoJEIP+FMlX6CvZkoEH/2sIEO+1qLiHTde/UJznrvr8
R8MDNC5tqXVLtbPjScoTItMHaPfz33lcypz9UFknHepdwZKhRrcuqy4E79lxeXDG
BybbbbfNfJPeUG44O1fkyJTJys0xRBnAGzWInZZwq+gWRaJv+JNhzinFujvLNDJV
4m2ObnSwT1mx/9CjRxWGakKDhPcZSGmWIicyN5tueNKdWbAjSqiR/J8N5W+QJiCm
+BzjzYpfUqn0vKOlARQIMshzqFjYVTnoHFZf/4Hl7ogIibxfGGo5t05pzBoAlIgj
nTizW2Bxs9XM1NaFsZ2ESg8KVDTFSHS+jsMtdl0bWoHwRs6nNMQJJTjTPHXspCQ=
=5o5U
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa43-classic.patch"
Content-Disposition: attachment; filename="xsa43-classic.patch"
Content-Transfer-Encoding: base64

cGNpYmFjazogcmF0ZSBsaW1pdCBlcnJvciBtZXNzYWdlIGZyb20gcGNpYmFj
a19lbmFibGVfbXNpKCkKCi4uLiBhcyBiZWluZyBndWVzdCB0cmlnZ2VyYWJs
ZSAoZS5nLiBieSBpbnZva2luZyBYRU5fUENJX09QX2VuYWJsZV9tc2kKb24g
YSBkZXZpY2Ugbm90IGJlaW5nIE1TSSBjYXBhYmxlKS4KClRoaXMgaXMgQ1ZF
LTIwMTMtMDIzMSAvIFhTQS00My4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVs
aWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL2RyaXZlcnMveGVuL3Bj
aWJhY2svY29uZl9zcGFjZV9jYXBhYmlsaXR5X21zaS5jCisrKyBiL2RyaXZl
cnMveGVuL3BjaWJhY2svY29uZl9zcGFjZV9jYXBhYmlsaXR5X21zaS5jCkBA
IC0xMSwxMyArMTEsMTIgQEAKIGludCBwY2liYWNrX2VuYWJsZV9tc2koc3Ry
dWN0IHBjaWJhY2tfZGV2aWNlICpwZGV2LAogCQlzdHJ1Y3QgcGNpX2RldiAq
ZGV2LCBzdHJ1Y3QgeGVuX3BjaV9vcCAqb3ApCiB7Ci0JaW50IG90aGVyZW5k
ID0gcGRldi0+eGRldi0+b3RoZXJlbmRfaWQ7Ci0JaW50IHN0YXR1czsKLQot
CXN0YXR1cyA9IHBjaV9lbmFibGVfbXNpKGRldik7CisJaW50IHN0YXR1cyA9
IHBjaV9lbmFibGVfbXNpKGRldik7CiAKIAlpZiAoc3RhdHVzKSB7Ci0JCXBy
aW50aygiZXJyb3IgZW5hYmxlIG1zaSBmb3IgZ3Vlc3QgJXggc3RhdHVzICV4
XG4iLCBvdGhlcmVuZCwgc3RhdHVzKTsKKwkJaWYgKHByaW50a19yYXRlbGlt
aXQoKSkKKwkJCXByaW50aygiZXJyb3IgZW5hYmxpbmcgTVNJIGZvciBndWVz
dCAldSBzdGF0dXMgJWRcbiIsCisJCQkgICAgICAgcGRldi0+eGRldi0+b3Ro
ZXJlbmRfaWQsIHN0YXR1cyk7CiAJCW9wLT52YWx1ZSA9IDA7CiAJCXJldHVy
biBYRU5fUENJX0VSUl9vcF9mYWlsZWQ7CiAJfQo=

--=separator
Content-Type: application/octet-stream; name="xsa43-pvops.patch"
Content-Disposition: attachment; filename="xsa43-pvops.patch"
Content-Transfer-Encoding: base64

eGVuLXBjaWJhY2s6IHJhdGUgbGltaXQgZXJyb3IgbWVzc2FnZXMgZnJvbSB4
ZW5fcGNpYmtfZW5hYmxlX21zaXsseH0oKQoKLi4uIGFzIGJlaW5nIGd1ZXN0
IHRyaWdnZXJhYmxlIChlLmcuIGJ5IGludm9raW5nClhFTl9QQ0lfT1BfZW5h
YmxlX21zaXsseH0gb24gYSBkZXZpY2Ugbm90IGJlaW5nIE1TSS9NU0ktWCBj
YXBhYmxlKS4KClRoaXMgaXMgQ1ZFLTIwMTMtMDIzMSAvIFhTQS00My4KCkFs
c28gbWFrZSB0aGUgdHdvIG1lc3NhZ2VzIHVuaWZvcm0gaW4gYm90aCB0aGVp
ciB3b3JkaW5nIGFuZCBzZXZlcml0eS4KClNpZ25lZC1vZmYtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBL
b25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+
CgotLS0KIGRyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2tfb3BzLmMg
fCAgIDE0ICsrKysrKystLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgNyBpbnNl
cnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKLS0tIDMuOC1yYzUvZHJpdmVy
cy94ZW4veGVuLXBjaWJhY2svcGNpYmFja19vcHMuYworKysgMy44LXJjNS14
ZW4tcGNpYmFjay1yYXRlbGltaXQvZHJpdmVycy94ZW4veGVuLXBjaWJhY2sv
cGNpYmFja19vcHMuYwpAQCAtMTM1LDcgKzEzNSw2IEBAIGludCB4ZW5fcGNp
YmtfZW5hYmxlX21zaShzdHJ1Y3QgeGVuX3BjaWIKIAkJCSBzdHJ1Y3QgcGNp
X2RldiAqZGV2LCBzdHJ1Y3QgeGVuX3BjaV9vcCAqb3ApCiB7CiAJc3RydWN0
IHhlbl9wY2lia19kZXZfZGF0YSAqZGV2X2RhdGE7Ci0JaW50IG90aGVyZW5k
ID0gcGRldi0+eGRldi0+b3RoZXJlbmRfaWQ7CiAJaW50IHN0YXR1czsKIAog
CWlmICh1bmxpa2VseSh2ZXJib3NlX3JlcXVlc3QpKQpAQCAtMTQ0LDggKzE0
Myw5IEBAIGludCB4ZW5fcGNpYmtfZW5hYmxlX21zaShzdHJ1Y3QgeGVuX3Bj
aWIKIAlzdGF0dXMgPSBwY2lfZW5hYmxlX21zaShkZXYpOwogCiAJaWYgKHN0
YXR1cykgewotCQlwcmludGsoS0VSTl9FUlIgImVycm9yIGVuYWJsZSBtc2kg
Zm9yIGd1ZXN0ICV4IHN0YXR1cyAleFxuIiwKLQkJCW90aGVyZW5kLCBzdGF0
dXMpOworCQlwcl93YXJuX3JhdGVsaW1pdGVkKERSVl9OQU1FICI6ICVzOiBl
cnJvciBlbmFibGluZyBNU0kgZm9yIGd1ZXN0ICV1OiBlcnIgJWRcbiIsCisJ
CQkJICAgIHBjaV9uYW1lKGRldiksIHBkZXYtPnhkZXYtPm90aGVyZW5kX2lk
LAorCQkJCSAgICBzdGF0dXMpOwogCQlvcC0+dmFsdWUgPSAwOwogCQlyZXR1
cm4gWEVOX1BDSV9FUlJfb3BfZmFpbGVkOwogCX0KQEAgLTIyMywxMCArMjIz
LDEwIEBAIGludCB4ZW5fcGNpYmtfZW5hYmxlX21zaXgoc3RydWN0IHhlbl9w
Y2kKIAkJCQkJCXBjaV9uYW1lKGRldiksIGksCiAJCQkJCQlvcC0+bXNpeF9l
bnRyaWVzW2ldLnZlY3Rvcik7CiAJCX0KLQl9IGVsc2UgewotCQlwcmludGso
S0VSTl9XQVJOSU5HIERSVl9OQU1FICI6ICVzOiBmYWlsZWQgdG8gZW5hYmxl
IE1TSS1YOiBlcnIgJWQhXG4iLAotCQkJcGNpX25hbWUoZGV2KSwgcmVzdWx0
KTsKLQl9CisJfSBlbHNlCisJCXByX3dhcm5fcmF0ZWxpbWl0ZWQoRFJWX05B
TUUgIjogJXM6IGVycm9yIGVuYWJsaW5nIE1TSS1YIGZvciBndWVzdCAldTog
ZXJyICVkIVxuIiwKKwkJCQkgICAgcGNpX25hbWUoZGV2KSwgcGRldi0+eGRl
di0+b3RoZXJlbmRfaWQsCisJCQkJICAgIHJlc3VsdCk7CiAJa2ZyZWUoZW50
cmllcyk7CiAKIAlvcC0+dmFsdWUgPSByZXN1bHQ7Cg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:16:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2iO0-0007zU-Lc; Tue, 05 Feb 2013 13:16:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iNy-0007xy-Q3; Tue, 05 Feb 2013 13:16:31 +0000
Received: from [193.109.254.147:30992] by server-15.bemta-14.messagelabs.com
	id 2E/C5-24599-D2601115; Tue, 05 Feb 2013 13:16:29 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360070124!9615039!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14883 invoked from network); 5 Feb 2013 13:15:26 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 13:15:26 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMo-0003am-0E; Tue, 05 Feb 2013 13:15:18 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1U2iMn-0008As-4b; Tue, 05 Feb 2013 13:15:17 +0000
Date: Tue, 05 Feb 2013 13:15:17 +0000
Message-Id: <E1U2iMn-0008As-4b@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 43 (CVE-2013-0231) - Linux
 pciback DoS via not rate limited log 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen Security Advisory CVE-2013-0231 / XSA-43
			      version 2

         Linux pciback DoS via not rate limited log messages.

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

Xen's PCI backend drivers in Linux allow a guest with assigned PCI device(s)
to cause a DoS through a flood of kernel messages, potentially affecting other
domains in the system.

IMPACT
======

A malicious guest can mount a DoS affecting the entire system.

VULNERABLE SYSTEMS
==================

All systems running guests with access to passed through PCI devices are
vulnerable.

Both mainline ("pvops") and classic-Xen patch kernels are affected.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted
guests.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa43-pvops.patch            Apply to mainline Linux 3.8-rc5.
xsa43-classic.patch          Apply to linux-2.6.18-xen tree.

$ sha256sum xsa43*.patch
4dec2d9b043bce2b8b54578573ba254fa7e6cbf4640cd100f40d8bf8a5a6a470  xsa43-classic.patch
6efe83c9951dcba20f18095814d19089e19230c6876bbdab32cc2f1165bb07c8  xsa43-pvops.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJREQI+AAoJEIP+FMlX6CvZkoEH/2sIEO+1qLiHTde/UJznrvr8
R8MDNC5tqXVLtbPjScoTItMHaPfz33lcypz9UFknHepdwZKhRrcuqy4E79lxeXDG
BybbbbfNfJPeUG44O1fkyJTJys0xRBnAGzWInZZwq+gWRaJv+JNhzinFujvLNDJV
4m2ObnSwT1mx/9CjRxWGakKDhPcZSGmWIicyN5tueNKdWbAjSqiR/J8N5W+QJiCm
+BzjzYpfUqn0vKOlARQIMshzqFjYVTnoHFZf/4Hl7ogIibxfGGo5t05pzBoAlIgj
nTizW2Bxs9XM1NaFsZ2ESg8KVDTFSHS+jsMtdl0bWoHwRs6nNMQJJTjTPHXspCQ=
=5o5U
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa43-classic.patch"
Content-Disposition: attachment; filename="xsa43-classic.patch"
Content-Transfer-Encoding: base64

cGNpYmFjazogcmF0ZSBsaW1pdCBlcnJvciBtZXNzYWdlIGZyb20gcGNpYmFj
a19lbmFibGVfbXNpKCkKCi4uLiBhcyBiZWluZyBndWVzdCB0cmlnZ2VyYWJs
ZSAoZS5nLiBieSBpbnZva2luZyBYRU5fUENJX09QX2VuYWJsZV9tc2kKb24g
YSBkZXZpY2Ugbm90IGJlaW5nIE1TSSBjYXBhYmxlKS4KClRoaXMgaXMgQ1ZF
LTIwMTMtMDIzMSAvIFhTQS00My4KClNpZ25lZC1vZmYtYnk6IEphbiBCZXVs
aWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL2RyaXZlcnMveGVuL3Bj
aWJhY2svY29uZl9zcGFjZV9jYXBhYmlsaXR5X21zaS5jCisrKyBiL2RyaXZl
cnMveGVuL3BjaWJhY2svY29uZl9zcGFjZV9jYXBhYmlsaXR5X21zaS5jCkBA
IC0xMSwxMyArMTEsMTIgQEAKIGludCBwY2liYWNrX2VuYWJsZV9tc2koc3Ry
dWN0IHBjaWJhY2tfZGV2aWNlICpwZGV2LAogCQlzdHJ1Y3QgcGNpX2RldiAq
ZGV2LCBzdHJ1Y3QgeGVuX3BjaV9vcCAqb3ApCiB7Ci0JaW50IG90aGVyZW5k
ID0gcGRldi0+eGRldi0+b3RoZXJlbmRfaWQ7Ci0JaW50IHN0YXR1czsKLQot
CXN0YXR1cyA9IHBjaV9lbmFibGVfbXNpKGRldik7CisJaW50IHN0YXR1cyA9
IHBjaV9lbmFibGVfbXNpKGRldik7CiAKIAlpZiAoc3RhdHVzKSB7Ci0JCXBy
aW50aygiZXJyb3IgZW5hYmxlIG1zaSBmb3IgZ3Vlc3QgJXggc3RhdHVzICV4
XG4iLCBvdGhlcmVuZCwgc3RhdHVzKTsKKwkJaWYgKHByaW50a19yYXRlbGlt
aXQoKSkKKwkJCXByaW50aygiZXJyb3IgZW5hYmxpbmcgTVNJIGZvciBndWVz
dCAldSBzdGF0dXMgJWRcbiIsCisJCQkgICAgICAgcGRldi0+eGRldi0+b3Ro
ZXJlbmRfaWQsIHN0YXR1cyk7CiAJCW9wLT52YWx1ZSA9IDA7CiAJCXJldHVy
biBYRU5fUENJX0VSUl9vcF9mYWlsZWQ7CiAJfQo=

--=separator
Content-Type: application/octet-stream; name="xsa43-pvops.patch"
Content-Disposition: attachment; filename="xsa43-pvops.patch"
Content-Transfer-Encoding: base64

eGVuLXBjaWJhY2s6IHJhdGUgbGltaXQgZXJyb3IgbWVzc2FnZXMgZnJvbSB4
ZW5fcGNpYmtfZW5hYmxlX21zaXsseH0oKQoKLi4uIGFzIGJlaW5nIGd1ZXN0
IHRyaWdnZXJhYmxlIChlLmcuIGJ5IGludm9raW5nClhFTl9QQ0lfT1BfZW5h
YmxlX21zaXsseH0gb24gYSBkZXZpY2Ugbm90IGJlaW5nIE1TSS9NU0ktWCBj
YXBhYmxlKS4KClRoaXMgaXMgQ1ZFLTIwMTMtMDIzMSAvIFhTQS00My4KCkFs
c28gbWFrZSB0aGUgdHdvIG1lc3NhZ2VzIHVuaWZvcm0gaW4gYm90aCB0aGVp
ciB3b3JkaW5nIGFuZCBzZXZlcml0eS4KClNpZ25lZC1vZmYtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KQWNrZWQtYnk6IElhbiBDYW1w
YmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBL
b25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+
CgotLS0KIGRyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaWJhY2tfb3BzLmMg
fCAgIDE0ICsrKysrKystLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgNyBpbnNl
cnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKLS0tIDMuOC1yYzUvZHJpdmVy
cy94ZW4veGVuLXBjaWJhY2svcGNpYmFja19vcHMuYworKysgMy44LXJjNS14
ZW4tcGNpYmFjay1yYXRlbGltaXQvZHJpdmVycy94ZW4veGVuLXBjaWJhY2sv
cGNpYmFja19vcHMuYwpAQCAtMTM1LDcgKzEzNSw2IEBAIGludCB4ZW5fcGNp
YmtfZW5hYmxlX21zaShzdHJ1Y3QgeGVuX3BjaWIKIAkJCSBzdHJ1Y3QgcGNp
X2RldiAqZGV2LCBzdHJ1Y3QgeGVuX3BjaV9vcCAqb3ApCiB7CiAJc3RydWN0
IHhlbl9wY2lia19kZXZfZGF0YSAqZGV2X2RhdGE7Ci0JaW50IG90aGVyZW5k
ID0gcGRldi0+eGRldi0+b3RoZXJlbmRfaWQ7CiAJaW50IHN0YXR1czsKIAog
CWlmICh1bmxpa2VseSh2ZXJib3NlX3JlcXVlc3QpKQpAQCAtMTQ0LDggKzE0
Myw5IEBAIGludCB4ZW5fcGNpYmtfZW5hYmxlX21zaShzdHJ1Y3QgeGVuX3Bj
aWIKIAlzdGF0dXMgPSBwY2lfZW5hYmxlX21zaShkZXYpOwogCiAJaWYgKHN0
YXR1cykgewotCQlwcmludGsoS0VSTl9FUlIgImVycm9yIGVuYWJsZSBtc2kg
Zm9yIGd1ZXN0ICV4IHN0YXR1cyAleFxuIiwKLQkJCW90aGVyZW5kLCBzdGF0
dXMpOworCQlwcl93YXJuX3JhdGVsaW1pdGVkKERSVl9OQU1FICI6ICVzOiBl
cnJvciBlbmFibGluZyBNU0kgZm9yIGd1ZXN0ICV1OiBlcnIgJWRcbiIsCisJ
CQkJICAgIHBjaV9uYW1lKGRldiksIHBkZXYtPnhkZXYtPm90aGVyZW5kX2lk
LAorCQkJCSAgICBzdGF0dXMpOwogCQlvcC0+dmFsdWUgPSAwOwogCQlyZXR1
cm4gWEVOX1BDSV9FUlJfb3BfZmFpbGVkOwogCX0KQEAgLTIyMywxMCArMjIz
LDEwIEBAIGludCB4ZW5fcGNpYmtfZW5hYmxlX21zaXgoc3RydWN0IHhlbl9w
Y2kKIAkJCQkJCXBjaV9uYW1lKGRldiksIGksCiAJCQkJCQlvcC0+bXNpeF9l
bnRyaWVzW2ldLnZlY3Rvcik7CiAJCX0KLQl9IGVsc2UgewotCQlwcmludGso
S0VSTl9XQVJOSU5HIERSVl9OQU1FICI6ICVzOiBmYWlsZWQgdG8gZW5hYmxl
IE1TSS1YOiBlcnIgJWQhXG4iLAotCQkJcGNpX25hbWUoZGV2KSwgcmVzdWx0
KTsKLQl9CisJfSBlbHNlCisJCXByX3dhcm5fcmF0ZWxpbWl0ZWQoRFJWX05B
TUUgIjogJXM6IGVycm9yIGVuYWJsaW5nIE1TSS1YIGZvciBndWVzdCAldTog
ZXJyICVkIVxuIiwKKwkJCQkgICAgcGNpX25hbWUoZGV2KSwgcGRldi0+eGRl
di0+b3RoZXJlbmRfaWQsCisJCQkJICAgIHJlc3VsdCk7CiAJa2ZyZWUoZW50
cmllcyk7CiAKIAlvcC0+dmFsdWUgPSByZXN1bHQ7Cg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:17:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:17: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 1U2iPG-0000H1-UE; Tue, 05 Feb 2013 13:17:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andia@pereslavl.ru>) id 1U2hQ4-0005Ps-05
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 12:14:36 +0000
Received: from [193.109.254.147:3377] by server-12.bemta-14.messagelabs.com id
	4C/7E-32582-BA7F0115; Tue, 05 Feb 2013 12:14:35 +0000
X-Env-Sender: andia@pereslavl.ru
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360066468!3351143!1
X-Originating-IP: [95.129.137.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19700 invoked from network); 5 Feb 2013 12:14:30 -0000
Received: from mail.botik.ru (HELO mail.botik.ru) (95.129.137.166)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 12:14:30 -0000
Received: from connect.botik.ru ([192.168.192.114]:37272)
	by mail.botik.ru with esmtps (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <andia@pereslavl.ru>)
	id 1U2hPv-0001S5-Ew; Tue, 05 Feb 2013 16:14:27 +0400
Message-ID: <1360066464.5263.117.camel@connect.botik.ru>
From: "Elena V. Titova" <andia@pereslavl.ru>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 05 Feb 2013 16:14:24 +0400
In-Reply-To: <1359992345.7743.69.camel@zakaz.uk.xensource.com>
References: <1359962676.5263.71.camel@connect.botik.ru>
	<1359992345.7743.69.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-Mailman-Approved-At: Tue, 05 Feb 2013 13:17:49 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful live migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andia@pereslavl.ru
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

0JIg0J/QvdC0LCAwNC8wMi8yMDEzINCyIDE1OjM5ICswMDAwLCBJYW4gQ2FtcGJlbGwg0L/QuNGI
0LXRgjoKPiA+IAo+ID4gV2UgdXNlIGRlYmlhbiBzYXJnZSwgbGludXgtaW1hZ2UtMy4yLjAtMy1h
bWQ2NCBhbmQgeGVuLTQuMS4zIG9uIG91cgo+ID4gc2VydmVycy4KPiAKPiBEbyB5b3UgcmVhbGx5
IG1lYW4gU2FyZ2U/IE9yIGRpZCB5b3UgbWVhbiBTcXVlZXplIG9yIFdoZWV6eT8gVGhvc2UKPiBr
ZXJuZWwgYW5kIFhlbiB2ZXJzaW9ucyBsb29rIGxpa2UgV2hlZXp5IHZlcnNpb25zIGJ1dCBwZXJo
YXBzIHlvdSBhcmUKPiB1c2luZyBiYWNrcG9ydHMuCgpJdCBpcyBteSBtaXN0YWtlLiBJIHdhbnQg
dG8gc2F5IGRlYmlhbiBzcXVlZXplIHdpdGggdGVzdGluZyBrZXJuZWwgYW5kCnhlbi4KCj4gCj4g
PiBXaGVuIGEgbGl2ZSBtaWdyYXRpb24gaXMgcnVuIHRoZSBndWVzdCBkb21haW4gbWF5IG5vdCBy
ZXN1bWUgb24gYQo+ID4gZGVzdGluYXRpb24KPiA+IGhvc3QgYW5kIGlzIGRlc3Ryb3llZCBvbiBh
IHNvdXJjZSBob3N0Lgo+ID4gVGhpcyBwYXRjaCBmaXhlcyBpdCBieSByZXN1bWluZyB0aGUgZ3Vl
c3QgZG9tYWluIG9uIGEgc291cmNlIGhvc3Qgd2hlbiBhCj4gPiBzdGFydCBvZgo+ID4gdGhlIGd1
ZXN0IGRvbWFpbiB3YXMgZmFpbGVkLgo+IAo+IHhlbmQgaXMgc3VwcG9zZWQgdG8gYmUgaW4gbWFp
bnRlbmFuY2UgbW9kZSBzbyBJJ20gbm90IHRvbyBzdXJlIGFib3V0Cj4gdGhpcyBzb3J0IG9mIGNo
YW5nZS4KPiAKPiBJbiBwYXJ0aWN1bGFyIEknbSB3b3JyaWVkIHRoYXQgaXQgbWlnaHQgYnJlYWsg
bWlncmF0aW9uIGZyb20gWGVuIHZlcnNpb24KPiBOIHRvIHZlcnNpb24gTisxIHdoaWNoIGlzIHNv
bWV0aGluZyB3ZSB0cnkgYW5kIHN1cHBvcnQuCj4gCj4gQlRXIHRoZSB4bCB0b29sc3RhY2sgYWxy
ZWFkeSBoYXMgdGhpcyBmdW5jdGlvbmFsaXR5IHNvIGFub3RoZXIgb3B0aW9uCj4gZm9yIHlvdSBt
YXkgYmUgdG8gc3dpdGNoIHRvIHRoYXQuCj4gCj4gPiBnaXQgZGlmZiB0b29scy9weXRob24veGVu
L3hlbmQvWGVuZENoZWNrcG9pbnQucHkKPiA+IGRpZmYgLS1naXQgYS90b29scy9weXRob24veGVu
L3hlbmQvWGVuZENoZWNrcG9pbnQucHkKPiA+IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL1hlbmRD
aGVja3BvaW50LnB5Cj4gPiBpbmRleCBmYTA5NzU3Li42Yjg3NjVmIDEwMDY0NAo+ID4gLS0tIGEv
dG9vbHMvcHl0aG9uL3hlbi94ZW5kL1hlbmRDaGVja3BvaW50LnB5Cj4gPiArKysgYi90b29scy9w
eXRob24veGVuL3hlbmQvWGVuZENoZWNrcG9pbnQucHkKPiA+IEBAIC0xNjMsMTIgKzE2MywxNiBA
QCBkZWYgc2F2ZShmZCwgZG9taW5mbywgbmV0d29yaywgbGl2ZSwgZHN0LAo+ID4gY2hlY2twb2lu
dD1GYWxzZSwgbm9kZT0tMSxzb2NrPU5vbmUpOgo+ID4gICAgICAgICAgICAgIGRvbWluZm8ucmVz
dW1lRG9tYWluKCkKPiA+ICAgICAgICAgIGVsc2U6Cj4gPiAgICAgICAgICAgICAgaWYgbGl2ZSBh
bmQgc29jayAhPSBOb25lOgo+IAo+IFRoaXMgc2FtZSBjbGFzcyBvZiBlcnJvcnMgaXNuJ3QgcG9z
c2libGUgZm9yIG5vbi1saXZlPwoKQXMgSSB0aGluayBpbiBub24tbGl2ZSBtaWdyYXRpb24gSSBo
YXZlIGEgc2F2ZWQgaW1hZ2Ugb2YgVk0gYW5kIGNhbiB0cnkKdG8gcmVzdW1lIGl0IG9uIGRpZmZl
cmVudCBzZXJ2ZXJzIGluY2x1ZGluZyB0aGUgc291cmNlIHNlcnZlci4gSW4gbGl2ZQptaWdyYXRp
b24gaWYgcmVzdW1pbmcgb2YgVk0gZmFpbCBJJ2xsIHN0YXkgd2l0aG91dCBydW5uaW5nIFZNIGFu
ZApzZXJ2aWNlcyBhbHRob3VndCBWTSBjb3VsZCBjb250aW51ZSB0byBydW4gb24gdGhlIHNvdXJj
ZSBzZXJ2ZXIuCgo+IAo+ID4gKyAgICAgICAgICAgICAgICBzdGF0dXMgPSBvcy5yZWFkKGZkLCA2
NCkKPiAKPiBUaGUgd3JpdHRlbiBzdHJpbmdzIGFyZSA3IG9yIDQgYnl0ZXMsIGl0IHdvdWxkIGJl
IGJldHRlciB0byBjaG9vc2UgYQo+IGZpeGVkIGxlbmd0aCBmb3IgYWxsIHdyaXRlcyBhbmQgdGhl
IHJlYWQgSSB0aGluay4gVGhhdCBtaWdodCBtZWFuCj4gcGFkZGluZyB0aGUgZmFpbCBtZXNzYWdl
LiBBbHNvIHRoZXNlIHByb3RvY29sIHN0cmluZ3Mgc2hvdWxkIGJlIGRlZmluZWQKPiBhcyBjb25z
dGFudHMgcmF0aGVyIHRoYW4gb3BlbiBjb2RlZC4KPiAKPiBFdmVuIHdpdGggdGhhdCBhZGRyZXNz
ZWQgSSBkb24ndCByZWFsbHkgZmVlbCBjb25maWRlbnQgZW5vdWdoIGFib3V0IHhlbmQKPiBpbnRl
cm5hbHMgdG8gQWNrIGEgcGF0Y2ggbGlrZSB0aGlzLgo+IAoKVGhhbmsgeW91IGZvciB5b3VyIGNv
bW1lbnRzIGFuZCBhZHZpY2UgdG8gdXNlIHhsIHRvb2xzdGFjay4gV2UgdXNlIHhlbgphbmQgeGVu
ZCB0b29sc3RhY2sgYW5kIGhhdmUgc29tZSBzY3JpcHRzIHdpdGggeG0gYW5kIFhlbkFQSS4gQnV0
IGFzIEkKcmVhZCB4ZW5kIGlzIGRlcHJlY2F0ZWQgaW4gWGVuIDQuMSBhbmQgd2lsbCBiZSByZW1v
dmVkIGluIGEgZnV0dXJlCnJlbGVhc2UgYW5kIGEgc3dpdGNoIHRvIHhsIG1heSBiZSBhIGdvb2Qg
aWRlYS4KCj4gPiAgICAgICAgICAgICAgICAgIHRyeToKPiA+ICAgICAgICAgICAgICAgICAgICAg
IHNvY2suc2h1dGRvd24oMikKPiA+ICAgICAgICAgICAgICAgICAgZXhjZXB0Ogo+ID4gICAgICAg
ICAgICAgICAgICAgICAgcGFzcwo+ID4gICAgICAgICAgICAgICAgICBzb2NrLmNsb3NlKCkKPiA+
IAo+ID4gKyAgICAgICAgICAgICAgICBpZiBzdGF0dXMgPT0gIkZBSUwiOgo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgcmFpc2UgWGVuZEVycm9yKCJSZXN0b3JlIGZhaWxlZCIpCj4gPiArCj4gPiAg
ICAgICAgICAgICAgZG9taW5mby5kZXN0cm95KCkKPiA+ICAgICAgICAgICAgICBkb21pbmZvLnRl
c3REZXZpY2VDb21wbGV0ZSgpCj4gPiAgICAgICAgICB0cnk6Cj4gPiBAQCAtMzUxLDggKzM1NSwx
NCBAQCBkZWYgcmVzdG9yZSh4ZCwgZmQsIGRvbWluZm8gPSBOb25lLCBwYXVzZWQgPSBGYWxzZSwK
PiA+IHJlbG9jYXRpbmcgPSBGYWxzZSk6Cj4gPiAgICAgICAgICBpZiBub3QgcGF1c2VkOgo+ID4g
ICAgICAgICAgICAgIGRvbWluZm8udW5wYXVzZSgpCj4gPiAKPiA+ICsgICAgICAgIGlmIHJlbG9j
YXRpbmc6Cj4gPiArICAgICAgICAgICAgb3Mud3JpdGUoZmQsICJTVUNDRVNTIikKPiA+ICsKPiA+
ICAgICAgICAgIHJldHVybiBkb21pbmZvCj4gPiAgICAgIGV4Y2VwdCBFeGNlcHRpb24sIGV4bjoK
PiA+ICsgICAgICAgIGlmIHJlbG9jYXRpbmc6Cj4gPiArICAgICAgICAgICAgb3Mud3JpdGUoZmQs
ICJGQUlMIikKPiA+ICsKPiA+ICAgICAgICAgIGRvbWluZm8uZGVzdHJveSgpCj4gPiAgICAgICAg
ICBsb2cuZXhjZXB0aW9uKGV4bikKPiA+ICAgICAgICAgIHJhaXNlIGV4biAKPiA+IAoKLS0KRWxl
bmEgVGl0b3ZhCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 13:17:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:17: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 1U2iPG-0000H1-UE; Tue, 05 Feb 2013 13:17:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andia@pereslavl.ru>) id 1U2hQ4-0005Ps-05
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 12:14:36 +0000
Received: from [193.109.254.147:3377] by server-12.bemta-14.messagelabs.com id
	4C/7E-32582-BA7F0115; Tue, 05 Feb 2013 12:14:35 +0000
X-Env-Sender: andia@pereslavl.ru
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360066468!3351143!1
X-Originating-IP: [95.129.137.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19700 invoked from network); 5 Feb 2013 12:14:30 -0000
Received: from mail.botik.ru (HELO mail.botik.ru) (95.129.137.166)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 12:14:30 -0000
Received: from connect.botik.ru ([192.168.192.114]:37272)
	by mail.botik.ru with esmtps (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <andia@pereslavl.ru>)
	id 1U2hPv-0001S5-Ew; Tue, 05 Feb 2013 16:14:27 +0400
Message-ID: <1360066464.5263.117.camel@connect.botik.ru>
From: "Elena V. Titova" <andia@pereslavl.ru>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 05 Feb 2013 16:14:24 +0400
In-Reply-To: <1359992345.7743.69.camel@zakaz.uk.xensource.com>
References: <1359962676.5263.71.camel@connect.botik.ru>
	<1359992345.7743.69.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-Mailman-Approved-At: Tue, 05 Feb 2013 13:17:49 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xend: resume a guest domain after an
 unsuccessful live migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andia@pereslavl.ru
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

0JIg0J/QvdC0LCAwNC8wMi8yMDEzINCyIDE1OjM5ICswMDAwLCBJYW4gQ2FtcGJlbGwg0L/QuNGI
0LXRgjoKPiA+IAo+ID4gV2UgdXNlIGRlYmlhbiBzYXJnZSwgbGludXgtaW1hZ2UtMy4yLjAtMy1h
bWQ2NCBhbmQgeGVuLTQuMS4zIG9uIG91cgo+ID4gc2VydmVycy4KPiAKPiBEbyB5b3UgcmVhbGx5
IG1lYW4gU2FyZ2U/IE9yIGRpZCB5b3UgbWVhbiBTcXVlZXplIG9yIFdoZWV6eT8gVGhvc2UKPiBr
ZXJuZWwgYW5kIFhlbiB2ZXJzaW9ucyBsb29rIGxpa2UgV2hlZXp5IHZlcnNpb25zIGJ1dCBwZXJo
YXBzIHlvdSBhcmUKPiB1c2luZyBiYWNrcG9ydHMuCgpJdCBpcyBteSBtaXN0YWtlLiBJIHdhbnQg
dG8gc2F5IGRlYmlhbiBzcXVlZXplIHdpdGggdGVzdGluZyBrZXJuZWwgYW5kCnhlbi4KCj4gCj4g
PiBXaGVuIGEgbGl2ZSBtaWdyYXRpb24gaXMgcnVuIHRoZSBndWVzdCBkb21haW4gbWF5IG5vdCBy
ZXN1bWUgb24gYQo+ID4gZGVzdGluYXRpb24KPiA+IGhvc3QgYW5kIGlzIGRlc3Ryb3llZCBvbiBh
IHNvdXJjZSBob3N0Lgo+ID4gVGhpcyBwYXRjaCBmaXhlcyBpdCBieSByZXN1bWluZyB0aGUgZ3Vl
c3QgZG9tYWluIG9uIGEgc291cmNlIGhvc3Qgd2hlbiBhCj4gPiBzdGFydCBvZgo+ID4gdGhlIGd1
ZXN0IGRvbWFpbiB3YXMgZmFpbGVkLgo+IAo+IHhlbmQgaXMgc3VwcG9zZWQgdG8gYmUgaW4gbWFp
bnRlbmFuY2UgbW9kZSBzbyBJJ20gbm90IHRvbyBzdXJlIGFib3V0Cj4gdGhpcyBzb3J0IG9mIGNo
YW5nZS4KPiAKPiBJbiBwYXJ0aWN1bGFyIEknbSB3b3JyaWVkIHRoYXQgaXQgbWlnaHQgYnJlYWsg
bWlncmF0aW9uIGZyb20gWGVuIHZlcnNpb24KPiBOIHRvIHZlcnNpb24gTisxIHdoaWNoIGlzIHNv
bWV0aGluZyB3ZSB0cnkgYW5kIHN1cHBvcnQuCj4gCj4gQlRXIHRoZSB4bCB0b29sc3RhY2sgYWxy
ZWFkeSBoYXMgdGhpcyBmdW5jdGlvbmFsaXR5IHNvIGFub3RoZXIgb3B0aW9uCj4gZm9yIHlvdSBt
YXkgYmUgdG8gc3dpdGNoIHRvIHRoYXQuCj4gCj4gPiBnaXQgZGlmZiB0b29scy9weXRob24veGVu
L3hlbmQvWGVuZENoZWNrcG9pbnQucHkKPiA+IGRpZmYgLS1naXQgYS90b29scy9weXRob24veGVu
L3hlbmQvWGVuZENoZWNrcG9pbnQucHkKPiA+IGIvdG9vbHMvcHl0aG9uL3hlbi94ZW5kL1hlbmRD
aGVja3BvaW50LnB5Cj4gPiBpbmRleCBmYTA5NzU3Li42Yjg3NjVmIDEwMDY0NAo+ID4gLS0tIGEv
dG9vbHMvcHl0aG9uL3hlbi94ZW5kL1hlbmRDaGVja3BvaW50LnB5Cj4gPiArKysgYi90b29scy9w
eXRob24veGVuL3hlbmQvWGVuZENoZWNrcG9pbnQucHkKPiA+IEBAIC0xNjMsMTIgKzE2MywxNiBA
QCBkZWYgc2F2ZShmZCwgZG9taW5mbywgbmV0d29yaywgbGl2ZSwgZHN0LAo+ID4gY2hlY2twb2lu
dD1GYWxzZSwgbm9kZT0tMSxzb2NrPU5vbmUpOgo+ID4gICAgICAgICAgICAgIGRvbWluZm8ucmVz
dW1lRG9tYWluKCkKPiA+ICAgICAgICAgIGVsc2U6Cj4gPiAgICAgICAgICAgICAgaWYgbGl2ZSBh
bmQgc29jayAhPSBOb25lOgo+IAo+IFRoaXMgc2FtZSBjbGFzcyBvZiBlcnJvcnMgaXNuJ3QgcG9z
c2libGUgZm9yIG5vbi1saXZlPwoKQXMgSSB0aGluayBpbiBub24tbGl2ZSBtaWdyYXRpb24gSSBo
YXZlIGEgc2F2ZWQgaW1hZ2Ugb2YgVk0gYW5kIGNhbiB0cnkKdG8gcmVzdW1lIGl0IG9uIGRpZmZl
cmVudCBzZXJ2ZXJzIGluY2x1ZGluZyB0aGUgc291cmNlIHNlcnZlci4gSW4gbGl2ZQptaWdyYXRp
b24gaWYgcmVzdW1pbmcgb2YgVk0gZmFpbCBJJ2xsIHN0YXkgd2l0aG91dCBydW5uaW5nIFZNIGFu
ZApzZXJ2aWNlcyBhbHRob3VndCBWTSBjb3VsZCBjb250aW51ZSB0byBydW4gb24gdGhlIHNvdXJj
ZSBzZXJ2ZXIuCgo+IAo+ID4gKyAgICAgICAgICAgICAgICBzdGF0dXMgPSBvcy5yZWFkKGZkLCA2
NCkKPiAKPiBUaGUgd3JpdHRlbiBzdHJpbmdzIGFyZSA3IG9yIDQgYnl0ZXMsIGl0IHdvdWxkIGJl
IGJldHRlciB0byBjaG9vc2UgYQo+IGZpeGVkIGxlbmd0aCBmb3IgYWxsIHdyaXRlcyBhbmQgdGhl
IHJlYWQgSSB0aGluay4gVGhhdCBtaWdodCBtZWFuCj4gcGFkZGluZyB0aGUgZmFpbCBtZXNzYWdl
LiBBbHNvIHRoZXNlIHByb3RvY29sIHN0cmluZ3Mgc2hvdWxkIGJlIGRlZmluZWQKPiBhcyBjb25z
dGFudHMgcmF0aGVyIHRoYW4gb3BlbiBjb2RlZC4KPiAKPiBFdmVuIHdpdGggdGhhdCBhZGRyZXNz
ZWQgSSBkb24ndCByZWFsbHkgZmVlbCBjb25maWRlbnQgZW5vdWdoIGFib3V0IHhlbmQKPiBpbnRl
cm5hbHMgdG8gQWNrIGEgcGF0Y2ggbGlrZSB0aGlzLgo+IAoKVGhhbmsgeW91IGZvciB5b3VyIGNv
bW1lbnRzIGFuZCBhZHZpY2UgdG8gdXNlIHhsIHRvb2xzdGFjay4gV2UgdXNlIHhlbgphbmQgeGVu
ZCB0b29sc3RhY2sgYW5kIGhhdmUgc29tZSBzY3JpcHRzIHdpdGggeG0gYW5kIFhlbkFQSS4gQnV0
IGFzIEkKcmVhZCB4ZW5kIGlzIGRlcHJlY2F0ZWQgaW4gWGVuIDQuMSBhbmQgd2lsbCBiZSByZW1v
dmVkIGluIGEgZnV0dXJlCnJlbGVhc2UgYW5kIGEgc3dpdGNoIHRvIHhsIG1heSBiZSBhIGdvb2Qg
aWRlYS4KCj4gPiAgICAgICAgICAgICAgICAgIHRyeToKPiA+ICAgICAgICAgICAgICAgICAgICAg
IHNvY2suc2h1dGRvd24oMikKPiA+ICAgICAgICAgICAgICAgICAgZXhjZXB0Ogo+ID4gICAgICAg
ICAgICAgICAgICAgICAgcGFzcwo+ID4gICAgICAgICAgICAgICAgICBzb2NrLmNsb3NlKCkKPiA+
IAo+ID4gKyAgICAgICAgICAgICAgICBpZiBzdGF0dXMgPT0gIkZBSUwiOgo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgcmFpc2UgWGVuZEVycm9yKCJSZXN0b3JlIGZhaWxlZCIpCj4gPiArCj4gPiAg
ICAgICAgICAgICAgZG9taW5mby5kZXN0cm95KCkKPiA+ICAgICAgICAgICAgICBkb21pbmZvLnRl
c3REZXZpY2VDb21wbGV0ZSgpCj4gPiAgICAgICAgICB0cnk6Cj4gPiBAQCAtMzUxLDggKzM1NSwx
NCBAQCBkZWYgcmVzdG9yZSh4ZCwgZmQsIGRvbWluZm8gPSBOb25lLCBwYXVzZWQgPSBGYWxzZSwK
PiA+IHJlbG9jYXRpbmcgPSBGYWxzZSk6Cj4gPiAgICAgICAgICBpZiBub3QgcGF1c2VkOgo+ID4g
ICAgICAgICAgICAgIGRvbWluZm8udW5wYXVzZSgpCj4gPiAKPiA+ICsgICAgICAgIGlmIHJlbG9j
YXRpbmc6Cj4gPiArICAgICAgICAgICAgb3Mud3JpdGUoZmQsICJTVUNDRVNTIikKPiA+ICsKPiA+
ICAgICAgICAgIHJldHVybiBkb21pbmZvCj4gPiAgICAgIGV4Y2VwdCBFeGNlcHRpb24sIGV4bjoK
PiA+ICsgICAgICAgIGlmIHJlbG9jYXRpbmc6Cj4gPiArICAgICAgICAgICAgb3Mud3JpdGUoZmQs
ICJGQUlMIikKPiA+ICsKPiA+ICAgICAgICAgIGRvbWluZm8uZGVzdHJveSgpCj4gPiAgICAgICAg
ICBsb2cuZXhjZXB0aW9uKGV4bikKPiA+ICAgICAgICAgIHJhaXNlIGV4biAKPiA+IAoKLS0KRWxl
bmEgVGl0b3ZhCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 13:18:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:18: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 1U2iPe-0000Wk-Dw; Tue, 05 Feb 2013 13:18:14 +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 1U2iPc-0000Ud-3x
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 13:18:12 +0000
Received: from [85.158.139.83:23549] by server-5.bemta-5.messagelabs.com id
	BE/FC-11945-39601115; Tue, 05 Feb 2013 13:18:11 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360070286!19642393!1
X-Originating-IP: [209.85.128.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19534 invoked from network); 5 Feb 2013 13:18:07 -0000
Received: from mail-qe0-f42.google.com (HELO mail-qe0-f42.google.com)
	(209.85.128.42)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 13:18:07 -0000
Received: by mail-qe0-f42.google.com with SMTP id 2so58348qeb.15
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 05:18:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=iInLT+cQWU/Q1IBZcJRZC2oDPfAJaEpCxCu0QqAVGds=;
	b=KUnhqTNMeIUwnmrGNggngBRXVbYNPprxvWxwLWhKYnErhGIXAKi0I7C3jnv2jhj/SA
	nwwUc1rcASY6bhqyMRooZfn/tqSuljX6z3VLW0YqtsYoiSpYU6C8yG1XqHfNGdBYCLNZ
	P68nGuOPdoO5YOjWAShONBrfcrOJWeSlJj00Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=iInLT+cQWU/Q1IBZcJRZC2oDPfAJaEpCxCu0QqAVGds=;
	b=Un3M8THIRTSIOGv/DnzNo74JhsMF7OcCXje2X+MNzvtrGDnTPhOv47h2J1kurP3qoV
	utG482Myqylqc4SiDJCpHy9ify4BuDULSwrJFYwxX30NwhiBo0jE8Auy7i9XTKiVTFYQ
	bgVMEO7BG5j6eJBba1U/PqrZociCiz8Wjt9MijRU2HX+PM+NLY8BMAHuZZAS5Jxzvyvi
	FBO0/qUfajgA9WA6xtIO382EDzylDS+Z1tclmCJA5tfSM3aTzK9GrqO47Yw3sJes30ug
	q/QM0YcInzK/cbBAo+hoWEtZ9239jm+W52mKYAkoS0FWVL0PsBd9eCJR9RwMMYyZ2WIs
	Qf4A==
X-Received: by 10.224.96.4 with SMTP id f4mr19605847qan.79.1360070286434; Tue,
	05 Feb 2013 05:18:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Tue, 5 Feb 2013 05:17:51 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20130201144255.GA7461@konrad-lan.dumpdata.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
	<1359655545.23229.101.camel@zion.uk.xensource.com>
	<CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
	<20130201144255.GA7461@konrad-lan.dumpdata.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 5 Feb 2013 17:17:51 +0400
X-Google-Sender-Auth: FOqMUpkk-vCJweM456BcthAuzls
Message-ID: <CACaajQs+VnFg-M1CaV+KFoiYPU_8b=wbUwirGCB5V0RkXuGXmg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
X-Gm-Message-State: ALoCoQkfFUKUX+ojWrjHDOUosb32Yz84G07a5eDkPiEAo4/uABYLymKeigbWaJZxzjbT1R4K3TMp
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback disk I/O limit 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

Thanks for help and sorry for delay. I'm not fully understand how to
send patch via git send-email for specific mail thread.
May be i have missing message id (i cur it from last message, not first)

2013/2/1 Konrad Rzeszutek Wilk <konrad@kernel.org>:
> On Fri, Feb 01, 2013 at 10:53:46AM +0400, Vasiliy Tolstov wrote:
>> Sorry,
>
> Ugh, you didn't inline it - you just copied and pasted it.
>
> Also you are missing an SoB and a description of what this patch does
> and why is it better than existing device mapper I/O limiting work?
>
>>
>> diff -NruabBEp xen_blkback_limit.orig/blkback.c xen_blkback_limit.new//blkback.c
>> --- xen_blkback_limit.orig/blkback.c 2012-12-04 13:03:58.000000000 +0400
>> +++ xen_blkback_limit.new//blkback.c 2013-01-28 08:11:30.000000000 +0400
>> @@ -211,10 +211,18 @@ static void print_stats(blkif_t *blkif)
>>   blkif->st_pk_req = 0;
>>  }
>>
>> +static void refill_iops(blkif_t *blkif)
>> +{
>> + blkif->reqtime = jiffies + msecs_to_jiffies(1000);
>> + blkif->reqcount = 0;
>> +}
>> +
>>  int blkif_schedule(void *arg)
>>  {
>>   blkif_t *blkif = arg;
>>   struct vbd *vbd = &blkif->vbd;
>> + int     ret = 0;
>> + struct timeval cur_time;
>>
>>   blkif_get(blkif);
>>
>> @@ -237,10 +245,22 @@ int blkif_schedule(void *arg)
>>   blkif->waiting_reqs = 0;
>>   smp_mb(); /* clear flag *before* checking for work */
>>
>> - if (do_block_io_op(blkif))
>> + ret = do_block_io_op(blkif);
>> + if (ret)
>>   blkif->waiting_reqs = 1;
>>   unplug_queue(blkif);
>>
>> + if (blkif->reqrate) {
>> + if (2 == ret && (blkif->reqtime > jiffies)) {
>> + jiffies_to_timeval(jiffies, &cur_time);
>> +
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + schedule_timeout(blkif->reqtime - jiffies);
>> + }
>> + if (time_after(jiffies, blkif->reqtime))
>> + refill_iops(blkif);
>> + }
>> +
>>   if (log_stats && time_after(jiffies, blkif->st_print))
>>   print_stats(blkif);
>>   }
>> @@ -394,10 +414,19 @@ static int _do_block_io_op(blkif_t *blki
>>   rp = blk_rings->common.sring->req_prod;
>>   rmb(); /* Ensure we see queued requests up to 'rp'. */
>>
>> + if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
>> + return (rc != rp) ? 2 : 0;
>> + }
>> +
>>   while (rc != rp) {
>>   if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
>>   break;
>>
>> + if (blkif->reqrate) {
>> + if (blkif->reqcount >= blkif->reqrate)
>> + return 2;
>> + }
>> +
>>   if (kthread_should_stop())
>>   return 1;
>>
>> @@ -434,8 +463,8 @@ static int _do_block_io_op(blkif_t *blki
>>
>>   /* Apply all sanity checks to /private copy/ of request. */
>>   barrier();
>> -
>>   dispatch_rw_block_io(blkif, &req, pending_req);
>> + blkif->reqcount++;
>>   break;
>>   case BLKIF_OP_DISCARD:
>>   blk_rings->common.req_cons = rc;
>> @@ -452,7 +481,7 @@ static int _do_block_io_op(blkif_t *blki
>>   break;
>>   default:
>>   /* A good sign something is wrong: sleep for a while to
>> - * avoid excessive CPU consumption by a bad guest. */
>> + * avoid excessive CPU consumption by a bad guest.*/
>>   msleep(1);
>>   blk_rings->common.req_cons = rc;
>>   barrier();
>> @@ -501,6 +530,7 @@ static void dispatch_rw_block_io(blkif_t
>>   uint32_t flags;
>>   int ret, i;
>>   int operation;
>> + struct timeval cur_time;
>>
>>   switch (req->operation) {
>>   case BLKIF_OP_READ:
>> @@ -658,6 +688,7 @@ static void dispatch_rw_block_io(blkif_t
>>   else
>>   blkif->st_wr_sect += preq.nr_sects;
>>
>> + jiffies_to_timeval(jiffies, &cur_time);
>>   return;
>>
>>   fail_flush:
>> diff -NruabBEp xen_blkback_limit.orig/common.h xen_blkback_limit.new//common.h
>> --- xen_blkback_limit.orig/common.h 2012-12-04 13:03:58.000000000 +0400
>> +++ xen_blkback_limit.new//common.h 2013-01-28 08:09:35.000000000 +0400
>> @@ -82,6 +82,11 @@ typedef struct blkif_st {
>>   unsigned int        waiting_reqs;
>>   struct request_queue *plug;
>>
>> + /* qos information */
>> + unsigned long   reqtime;
>> + int    reqcount;
>> + int    reqrate;
>> +
>>   /* statistics */
>>   unsigned long       st_print;
>>   int                 st_rd_req;
>> @@ -106,6 +111,8 @@ struct backend_info
>>   unsigned major;
>>   unsigned minor;
>>   char *mode;
>> + /* qos information */
>> + struct xenbus_watch reqrate_watch;
>>  };
>>
>>  blkif_t *blkif_alloc(domid_t domid);
>> diff -NruabBEp xen_blkback_limit.orig/xenbus.c xen_blkback_limit.new//xenbus.c
>> --- xen_blkback_limit.orig/xenbus.c 2012-12-04 13:03:58.000000000 +0400
>> +++ xen_blkback_limit.new//xenbus.c 2013-01-28 08:22:26.000000000 +0400
>> @@ -120,6 +120,79 @@ static void update_blkif_status(blkif_t
>>   } \
>>   static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
>>
>> +static ssize_t
>> +show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
>> +{
>> + ssize_t ret = -ENODEV;
>> + struct xenbus_device *dev;
>> + struct backend_info *be;
>> +
>> + if (!get_device(_dev))
>> + return ret;
>> +
>> + dev = to_xenbus_device(_dev);
>> + be = dev_get_drvdata(&dev->dev);
>> +
>> + if (be != NULL)
>> + ret = sprintf(buf, "%d\n", be->blkif->reqrate);
>> +
>> + put_device(_dev);
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t
>> +store_reqrate(struct device *_dev, struct device_attribute *attr,
>> + const char *buf, size_t size)
>> +{
>> + int value;
>> + struct xenbus_device *dev;
>> + struct backend_info *be;
>> +
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + if (!get_device(_dev))
>> + return -ENODEV;
>> +
>> + if (sscanf(buf, "%d", &value) != 1)
>> + return -EINVAL;
>> +
>> + dev = to_xenbus_device(_dev);
>> + be = dev_get_drvdata(&dev->dev);
>> +
>> + if (be != NULL)
>> + be->blkif->reqrate = value;
>> +
>> + put_device(_dev);
>> +
>> + return size;
>> +}
>> +static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
>> + store_reqrate);
>> +
>> +static ssize_t
>> +show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
>> +{
>> + ssize_t ret = -ENODEV;
>> + struct xenbus_device *dev;
>> + struct backend_info *be;
>> +
>> + if (!get_device(_dev))
>> + return ret;
>> +
>> + dev = to_xenbus_device(_dev);
>> + be = dev_get_drvdata(&dev->dev);
>> +
>> + if (be != NULL)
>> + ret = sprintf(buf, "%d\n", be->blkif->reqcount);
>> +
>> + put_device(_dev);
>> +
>> + return ret;
>> +}
>> +static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
>> +
>>  VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
>>  VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
>>  VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
>> @@ -146,6 +219,17 @@ static const struct attribute_group vbds
>>   .attrs = vbdstat_attrs,
>>  };
>>
>> +static struct attribute *vbdreq_attrs[] = {
>> + &dev_attr_reqrate.attr,
>> + &dev_attr_reqcount.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group vbdreq_group = {
>> + .name = "qos",
>> + .attrs = vbdreq_attrs,
>> +};
>> +
>>  VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
>>  VBD_SHOW(mode, "%s\n", be->mode);
>>
>> @@ -165,8 +249,13 @@ int xenvbd_sysfs_addif(struct xenbus_dev
>>   if (error)
>>   goto fail3;
>>
>> + error = sysfs_create_group(&dev->dev.kobj, &vbdreq_group);
>> + if (error)
>> + goto fail4;
>> +
>>   return 0;
>>
>> +fail4:  sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>>  fail3: sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>>  fail2: device_remove_file(&dev->dev, &dev_attr_mode);
>>  fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
>> @@ -175,6 +264,7 @@ fail1: device_remove_file(&dev->dev, &de
>>
>>  void xenvbd_sysfs_delif(struct xenbus_device *dev)
>>  {
>> + sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>>   sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>>   device_remove_file(&dev->dev, &dev_attr_mode);
>>   device_remove_file(&dev->dev, &dev_attr_physical_device);
>> @@ -201,6 +291,12 @@ static int blkback_remove(struct xenbus_
>>   be->cdrom_watch.node = NULL;
>>   }
>>
>> + if (be->reqrate_watch.node) {
>> + unregister_xenbus_watch(&be->reqrate_watch);
>> + kfree(be->reqrate_watch.node);
>> + be->reqrate_watch.node = NULL;
>> + }
>> +
>>   if (be->blkif) {
>>   blkif_disconnect(be->blkif);
>>   vbd_free(&be->blkif->vbd);
>> @@ -338,6 +434,7 @@ static void backend_changed(struct xenbu
>>   struct xenbus_device *dev = be->dev;
>>   int cdrom = 0;
>>   char *device_type;
>> + char name[TASK_COMM_LEN];
>>
>>   DPRINTK("");
>>
>> @@ -376,6 +473,21 @@ static void backend_changed(struct xenbu
>>   kfree(device_type);
>>   }
>>
>> + /* gather information about QoS policy for this device. */
>> + err = blkback_name(be->blkif, name);
>> + if (err) {
>> + xenbus_dev_error(be->dev, err, "get blkback dev name");
>> + return;
>> + }
>> +
>> + err = xenbus_gather(XBT_NIL, dev->otherend,
>> + "reqrate", "%d", &be->blkif->reqrate,
>> + NULL);
>> + if (err)
>> + DPRINTK("%s xenbus_gather(reqrate) error", name);
>> +
>> + be->blkif->reqtime = jiffies;
>> +
>>   if (be->major == 0 && be->minor == 0) {
>>   /* Front end dir is a number, which is used as the handle. */
>>
>> @@ -482,6 +594,30 @@ static void frontend_changed(struct xenb
>>
>>  /* ** Connection ** */
>>
>> +static void reqrate_changed(struct xenbus_watch *watch,
>> + const char **vec, unsigned int len)
>> +{
>> + struct backend_info *be = container_of(watch, struct backend_info,
>> + reqrate_watch);
>> + int err;
>> + char name[TASK_COMM_LEN];
>> +
>> + err = blkback_name(be->blkif, name);
>> + if (err) {
>> + xenbus_dev_error(be->dev, err, "get blkback dev name");
>> + return;
>> + }
>> +
>> + err = xenbus_gather(XBT_NIL, be->dev->otherend,
>> + "reqrate",  "%d",
>> + &be->blkif->reqrate, NULL);
>> + if (err) {
>> + DPRINTK("%s xenbus_gather(reqrate) error", name);
>> + } else {
>> + if (be->blkif->reqrate <= 0)
>> + be->blkif->reqrate = 0;
>> + }
>> +}
>>
>>  /**
>>   * Write the physical details regarding the block device to the store, and
>> @@ -542,6 +678,21 @@ again:
>>   xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
>>   dev->nodename);
>>
>> + if (be->reqrate_watch.node) {
>> + unregister_xenbus_watch(&be->reqrate_watch);
>> + kfree(be->reqrate_watch.node);
>> + be->reqrate_watch.node = NULL;
>> + }
>> +
>> + err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
>> + &be->reqrate_watch,
>> + reqrate_changed);
>> + if (err) {
>> + xenbus_dev_fatal(dev, err, "%s: watching reqrate",
>> + dev->nodename);
>> + goto abort;
>> + }
>> +
>>   return;
>>   abort:
>>   xenbus_transaction_end(xbt, 1);
>>
>> 2013/1/31 Wei Liu <wei.liu2@citrix.com>:
>> > On Thu, 2013-01-31 at 05:14 +0000, Vasiliy Tolstov wrote:
>> >> Sorry forget to send patch
>> >> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
>> >> Patch for kernel 3.6.9, but if that needed i can rebase it to current
>> >> git Linus tree.
>> >
>> > Can you inline your patch in your email so that developer can comment on
>> > it.
>> >
>> >
>> > Wei.
>> >
>>
>>
>>
>> --
>> 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
>>



-- 
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 Tue Feb 05 13:18:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:18: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 1U2iPe-0000Wk-Dw; Tue, 05 Feb 2013 13:18:14 +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 1U2iPc-0000Ud-3x
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 13:18:12 +0000
Received: from [85.158.139.83:23549] by server-5.bemta-5.messagelabs.com id
	BE/FC-11945-39601115; Tue, 05 Feb 2013 13:18:11 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360070286!19642393!1
X-Originating-IP: [209.85.128.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19534 invoked from network); 5 Feb 2013 13:18:07 -0000
Received: from mail-qe0-f42.google.com (HELO mail-qe0-f42.google.com)
	(209.85.128.42)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 13:18:07 -0000
Received: by mail-qe0-f42.google.com with SMTP id 2so58348qeb.15
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 05:18:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=iInLT+cQWU/Q1IBZcJRZC2oDPfAJaEpCxCu0QqAVGds=;
	b=KUnhqTNMeIUwnmrGNggngBRXVbYNPprxvWxwLWhKYnErhGIXAKi0I7C3jnv2jhj/SA
	nwwUc1rcASY6bhqyMRooZfn/tqSuljX6z3VLW0YqtsYoiSpYU6C8yG1XqHfNGdBYCLNZ
	P68nGuOPdoO5YOjWAShONBrfcrOJWeSlJj00Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=iInLT+cQWU/Q1IBZcJRZC2oDPfAJaEpCxCu0QqAVGds=;
	b=Un3M8THIRTSIOGv/DnzNo74JhsMF7OcCXje2X+MNzvtrGDnTPhOv47h2J1kurP3qoV
	utG482Myqylqc4SiDJCpHy9ify4BuDULSwrJFYwxX30NwhiBo0jE8Auy7i9XTKiVTFYQ
	bgVMEO7BG5j6eJBba1U/PqrZociCiz8Wjt9MijRU2HX+PM+NLY8BMAHuZZAS5Jxzvyvi
	FBO0/qUfajgA9WA6xtIO382EDzylDS+Z1tclmCJA5tfSM3aTzK9GrqO47Yw3sJes30ug
	q/QM0YcInzK/cbBAo+hoWEtZ9239jm+W52mKYAkoS0FWVL0PsBd9eCJR9RwMMYyZ2WIs
	Qf4A==
X-Received: by 10.224.96.4 with SMTP id f4mr19605847qan.79.1360070286434; Tue,
	05 Feb 2013 05:18:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Tue, 5 Feb 2013 05:17:51 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20130201144255.GA7461@konrad-lan.dumpdata.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<CACaajQuC28hKkXNJwWQPHPvm28WdywtUyC5jiXbrWwHgb3qZkw@mail.gmail.com>
	<1359655545.23229.101.camel@zion.uk.xensource.com>
	<CACaajQvp5p_77CtB9tTohM4iD0sqeJ3Bwm=dbBwRKRitXr9p7g@mail.gmail.com>
	<20130201144255.GA7461@konrad-lan.dumpdata.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 5 Feb 2013 17:17:51 +0400
X-Google-Sender-Auth: FOqMUpkk-vCJweM456BcthAuzls
Message-ID: <CACaajQs+VnFg-M1CaV+KFoiYPU_8b=wbUwirGCB5V0RkXuGXmg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
X-Gm-Message-State: ALoCoQkfFUKUX+ojWrjHDOUosb32Yz84G07a5eDkPiEAo4/uABYLymKeigbWaJZxzjbT1R4K3TMp
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] blkback disk I/O limit 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

Thanks for help and sorry for delay. I'm not fully understand how to
send patch via git send-email for specific mail thread.
May be i have missing message id (i cur it from last message, not first)

2013/2/1 Konrad Rzeszutek Wilk <konrad@kernel.org>:
> On Fri, Feb 01, 2013 at 10:53:46AM +0400, Vasiliy Tolstov wrote:
>> Sorry,
>
> Ugh, you didn't inline it - you just copied and pasted it.
>
> Also you are missing an SoB and a description of what this patch does
> and why is it better than existing device mapper I/O limiting work?
>
>>
>> diff -NruabBEp xen_blkback_limit.orig/blkback.c xen_blkback_limit.new//blkback.c
>> --- xen_blkback_limit.orig/blkback.c 2012-12-04 13:03:58.000000000 +0400
>> +++ xen_blkback_limit.new//blkback.c 2013-01-28 08:11:30.000000000 +0400
>> @@ -211,10 +211,18 @@ static void print_stats(blkif_t *blkif)
>>   blkif->st_pk_req = 0;
>>  }
>>
>> +static void refill_iops(blkif_t *blkif)
>> +{
>> + blkif->reqtime = jiffies + msecs_to_jiffies(1000);
>> + blkif->reqcount = 0;
>> +}
>> +
>>  int blkif_schedule(void *arg)
>>  {
>>   blkif_t *blkif = arg;
>>   struct vbd *vbd = &blkif->vbd;
>> + int     ret = 0;
>> + struct timeval cur_time;
>>
>>   blkif_get(blkif);
>>
>> @@ -237,10 +245,22 @@ int blkif_schedule(void *arg)
>>   blkif->waiting_reqs = 0;
>>   smp_mb(); /* clear flag *before* checking for work */
>>
>> - if (do_block_io_op(blkif))
>> + ret = do_block_io_op(blkif);
>> + if (ret)
>>   blkif->waiting_reqs = 1;
>>   unplug_queue(blkif);
>>
>> + if (blkif->reqrate) {
>> + if (2 == ret && (blkif->reqtime > jiffies)) {
>> + jiffies_to_timeval(jiffies, &cur_time);
>> +
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + schedule_timeout(blkif->reqtime - jiffies);
>> + }
>> + if (time_after(jiffies, blkif->reqtime))
>> + refill_iops(blkif);
>> + }
>> +
>>   if (log_stats && time_after(jiffies, blkif->st_print))
>>   print_stats(blkif);
>>   }
>> @@ -394,10 +414,19 @@ static int _do_block_io_op(blkif_t *blki
>>   rp = blk_rings->common.sring->req_prod;
>>   rmb(); /* Ensure we see queued requests up to 'rp'. */
>>
>> + if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
>> + return (rc != rp) ? 2 : 0;
>> + }
>> +
>>   while (rc != rp) {
>>   if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
>>   break;
>>
>> + if (blkif->reqrate) {
>> + if (blkif->reqcount >= blkif->reqrate)
>> + return 2;
>> + }
>> +
>>   if (kthread_should_stop())
>>   return 1;
>>
>> @@ -434,8 +463,8 @@ static int _do_block_io_op(blkif_t *blki
>>
>>   /* Apply all sanity checks to /private copy/ of request. */
>>   barrier();
>> -
>>   dispatch_rw_block_io(blkif, &req, pending_req);
>> + blkif->reqcount++;
>>   break;
>>   case BLKIF_OP_DISCARD:
>>   blk_rings->common.req_cons = rc;
>> @@ -452,7 +481,7 @@ static int _do_block_io_op(blkif_t *blki
>>   break;
>>   default:
>>   /* A good sign something is wrong: sleep for a while to
>> - * avoid excessive CPU consumption by a bad guest. */
>> + * avoid excessive CPU consumption by a bad guest.*/
>>   msleep(1);
>>   blk_rings->common.req_cons = rc;
>>   barrier();
>> @@ -501,6 +530,7 @@ static void dispatch_rw_block_io(blkif_t
>>   uint32_t flags;
>>   int ret, i;
>>   int operation;
>> + struct timeval cur_time;
>>
>>   switch (req->operation) {
>>   case BLKIF_OP_READ:
>> @@ -658,6 +688,7 @@ static void dispatch_rw_block_io(blkif_t
>>   else
>>   blkif->st_wr_sect += preq.nr_sects;
>>
>> + jiffies_to_timeval(jiffies, &cur_time);
>>   return;
>>
>>   fail_flush:
>> diff -NruabBEp xen_blkback_limit.orig/common.h xen_blkback_limit.new//common.h
>> --- xen_blkback_limit.orig/common.h 2012-12-04 13:03:58.000000000 +0400
>> +++ xen_blkback_limit.new//common.h 2013-01-28 08:09:35.000000000 +0400
>> @@ -82,6 +82,11 @@ typedef struct blkif_st {
>>   unsigned int        waiting_reqs;
>>   struct request_queue *plug;
>>
>> + /* qos information */
>> + unsigned long   reqtime;
>> + int    reqcount;
>> + int    reqrate;
>> +
>>   /* statistics */
>>   unsigned long       st_print;
>>   int                 st_rd_req;
>> @@ -106,6 +111,8 @@ struct backend_info
>>   unsigned major;
>>   unsigned minor;
>>   char *mode;
>> + /* qos information */
>> + struct xenbus_watch reqrate_watch;
>>  };
>>
>>  blkif_t *blkif_alloc(domid_t domid);
>> diff -NruabBEp xen_blkback_limit.orig/xenbus.c xen_blkback_limit.new//xenbus.c
>> --- xen_blkback_limit.orig/xenbus.c 2012-12-04 13:03:58.000000000 +0400
>> +++ xen_blkback_limit.new//xenbus.c 2013-01-28 08:22:26.000000000 +0400
>> @@ -120,6 +120,79 @@ static void update_blkif_status(blkif_t
>>   } \
>>   static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
>>
>> +static ssize_t
>> +show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
>> +{
>> + ssize_t ret = -ENODEV;
>> + struct xenbus_device *dev;
>> + struct backend_info *be;
>> +
>> + if (!get_device(_dev))
>> + return ret;
>> +
>> + dev = to_xenbus_device(_dev);
>> + be = dev_get_drvdata(&dev->dev);
>> +
>> + if (be != NULL)
>> + ret = sprintf(buf, "%d\n", be->blkif->reqrate);
>> +
>> + put_device(_dev);
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t
>> +store_reqrate(struct device *_dev, struct device_attribute *attr,
>> + const char *buf, size_t size)
>> +{
>> + int value;
>> + struct xenbus_device *dev;
>> + struct backend_info *be;
>> +
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + if (!get_device(_dev))
>> + return -ENODEV;
>> +
>> + if (sscanf(buf, "%d", &value) != 1)
>> + return -EINVAL;
>> +
>> + dev = to_xenbus_device(_dev);
>> + be = dev_get_drvdata(&dev->dev);
>> +
>> + if (be != NULL)
>> + be->blkif->reqrate = value;
>> +
>> + put_device(_dev);
>> +
>> + return size;
>> +}
>> +static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
>> + store_reqrate);
>> +
>> +static ssize_t
>> +show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
>> +{
>> + ssize_t ret = -ENODEV;
>> + struct xenbus_device *dev;
>> + struct backend_info *be;
>> +
>> + if (!get_device(_dev))
>> + return ret;
>> +
>> + dev = to_xenbus_device(_dev);
>> + be = dev_get_drvdata(&dev->dev);
>> +
>> + if (be != NULL)
>> + ret = sprintf(buf, "%d\n", be->blkif->reqcount);
>> +
>> + put_device(_dev);
>> +
>> + return ret;
>> +}
>> +static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
>> +
>>  VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
>>  VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
>>  VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
>> @@ -146,6 +219,17 @@ static const struct attribute_group vbds
>>   .attrs = vbdstat_attrs,
>>  };
>>
>> +static struct attribute *vbdreq_attrs[] = {
>> + &dev_attr_reqrate.attr,
>> + &dev_attr_reqcount.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group vbdreq_group = {
>> + .name = "qos",
>> + .attrs = vbdreq_attrs,
>> +};
>> +
>>  VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
>>  VBD_SHOW(mode, "%s\n", be->mode);
>>
>> @@ -165,8 +249,13 @@ int xenvbd_sysfs_addif(struct xenbus_dev
>>   if (error)
>>   goto fail3;
>>
>> + error = sysfs_create_group(&dev->dev.kobj, &vbdreq_group);
>> + if (error)
>> + goto fail4;
>> +
>>   return 0;
>>
>> +fail4:  sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>>  fail3: sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>>  fail2: device_remove_file(&dev->dev, &dev_attr_mode);
>>  fail1: device_remove_file(&dev->dev, &dev_attr_physical_device);
>> @@ -175,6 +264,7 @@ fail1: device_remove_file(&dev->dev, &de
>>
>>  void xenvbd_sysfs_delif(struct xenbus_device *dev)
>>  {
>> + sysfs_remove_group(&dev->dev.kobj, &vbdreq_group);
>>   sysfs_remove_group(&dev->dev.kobj, &vbdstat_group);
>>   device_remove_file(&dev->dev, &dev_attr_mode);
>>   device_remove_file(&dev->dev, &dev_attr_physical_device);
>> @@ -201,6 +291,12 @@ static int blkback_remove(struct xenbus_
>>   be->cdrom_watch.node = NULL;
>>   }
>>
>> + if (be->reqrate_watch.node) {
>> + unregister_xenbus_watch(&be->reqrate_watch);
>> + kfree(be->reqrate_watch.node);
>> + be->reqrate_watch.node = NULL;
>> + }
>> +
>>   if (be->blkif) {
>>   blkif_disconnect(be->blkif);
>>   vbd_free(&be->blkif->vbd);
>> @@ -338,6 +434,7 @@ static void backend_changed(struct xenbu
>>   struct xenbus_device *dev = be->dev;
>>   int cdrom = 0;
>>   char *device_type;
>> + char name[TASK_COMM_LEN];
>>
>>   DPRINTK("");
>>
>> @@ -376,6 +473,21 @@ static void backend_changed(struct xenbu
>>   kfree(device_type);
>>   }
>>
>> + /* gather information about QoS policy for this device. */
>> + err = blkback_name(be->blkif, name);
>> + if (err) {
>> + xenbus_dev_error(be->dev, err, "get blkback dev name");
>> + return;
>> + }
>> +
>> + err = xenbus_gather(XBT_NIL, dev->otherend,
>> + "reqrate", "%d", &be->blkif->reqrate,
>> + NULL);
>> + if (err)
>> + DPRINTK("%s xenbus_gather(reqrate) error", name);
>> +
>> + be->blkif->reqtime = jiffies;
>> +
>>   if (be->major == 0 && be->minor == 0) {
>>   /* Front end dir is a number, which is used as the handle. */
>>
>> @@ -482,6 +594,30 @@ static void frontend_changed(struct xenb
>>
>>  /* ** Connection ** */
>>
>> +static void reqrate_changed(struct xenbus_watch *watch,
>> + const char **vec, unsigned int len)
>> +{
>> + struct backend_info *be = container_of(watch, struct backend_info,
>> + reqrate_watch);
>> + int err;
>> + char name[TASK_COMM_LEN];
>> +
>> + err = blkback_name(be->blkif, name);
>> + if (err) {
>> + xenbus_dev_error(be->dev, err, "get blkback dev name");
>> + return;
>> + }
>> +
>> + err = xenbus_gather(XBT_NIL, be->dev->otherend,
>> + "reqrate",  "%d",
>> + &be->blkif->reqrate, NULL);
>> + if (err) {
>> + DPRINTK("%s xenbus_gather(reqrate) error", name);
>> + } else {
>> + if (be->blkif->reqrate <= 0)
>> + be->blkif->reqrate = 0;
>> + }
>> +}
>>
>>  /**
>>   * Write the physical details regarding the block device to the store, and
>> @@ -542,6 +678,21 @@ again:
>>   xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
>>   dev->nodename);
>>
>> + if (be->reqrate_watch.node) {
>> + unregister_xenbus_watch(&be->reqrate_watch);
>> + kfree(be->reqrate_watch.node);
>> + be->reqrate_watch.node = NULL;
>> + }
>> +
>> + err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
>> + &be->reqrate_watch,
>> + reqrate_changed);
>> + if (err) {
>> + xenbus_dev_fatal(dev, err, "%s: watching reqrate",
>> + dev->nodename);
>> + goto abort;
>> + }
>> +
>>   return;
>>   abort:
>>   xenbus_transaction_end(xbt, 1);
>>
>> 2013/1/31 Wei Liu <wei.liu2@citrix.com>:
>> > On Thu, 2013-01-31 at 05:14 +0000, Vasiliy Tolstov wrote:
>> >> Sorry forget to send patch
>> >> https://bitbucket.org/go2clouds/patches/raw/master/xen_blkback_limit/3.6.9-1.patch
>> >> Patch for kernel 3.6.9, but if that needed i can rebase it to current
>> >> git Linus tree.
>> >
>> > Can you inline your patch in your email so that developer can comment on
>> > it.
>> >
>> >
>> > Wei.
>> >
>>
>>
>>
>> --
>> 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
>>



-- 
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 Tue Feb 05 13:19:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:19: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 1U2iQk-00018N-4N; Tue, 05 Feb 2013 13:19:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <v.tolstov@selfip.ru>) id 1U2iQi-00017H-Lz
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 13:19:21 +0000
Received: from [193.109.254.147:59237] by server-10.bemta-14.messagelabs.com
	id 88/12-12679-8D601115; Tue, 05 Feb 2013 13:19:20 +0000
X-Env-Sender: v.tolstov@selfip.ru
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360070070!9292521!1
X-Originating-IP: [209.85.217.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_19,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNjIyMDEgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12626 invoked from network); 5 Feb 2013 13:14:31 -0000
Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com)
	(209.85.217.172)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 13:14:31 -0000
Received: by mail-lb0-f172.google.com with SMTP id n8so207624lbj.31
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 05:14:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=wuFxdZwhWCazJrfkCd60b4Jf1W2OxzZTgOSrHoEhTLk=;
	b=VMbj4CY6zuMOXOl5wa4FsSgA8hmK1TxuEGni4OpGJdGWwHuzP2XqMQVtF8v5IXYTwy
	2EO/Idm/usn1xc02lC+4srWDXc+32afIlO/PVVYzBz7DLV+Gi9QmUrMdM5fFOK4UxRNc
	va1ih5gJEXB7VMHXOFZKYvc8Nr4oZejrwwlHM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references:x-gm-message-state;
	bh=wuFxdZwhWCazJrfkCd60b4Jf1W2OxzZTgOSrHoEhTLk=;
	b=fnD4UEKRHx6ZFo/10P7Dtn0nMgSa51WjDldf6KGeqsi+x0ltPE/n7pcqET5dI7OFOL
	MkdVRtJabI6SkC36gbmNiRbPxx8iKtQY4UJnn3B6g3Bs/ZtC8cd5SGq/tHT88kSsLZQb
	nMOTlVlzJSf17JdzY5Q2som6FaWMpOYo6y+qA2QX4zKiarA/t8ErdrXgmrt4ZMXujIWr
	X3VHcyePDZFP/F58CZLg8TrFwOG6j/doZdKy9ihMxFOUMHrD8SqJkil1u915rKK2ySvN
	pZ5JRdptA8zJreHivZ83KT5gDOt4mjw0G/eZlQISrKnEiZebwpLopVkDi8FVe5+RILTr
	Sgjg==
X-Received: by 10.152.111.102 with SMTP id ih6mr22850839lab.20.1360070070499; 
	Tue, 05 Feb 2013 05:14:30 -0800 (PST)
Received: from vase.office.clodo.ru (85-143-161-18.customer.comfortel.pro.
	[85.143.161.18])
	by mx.google.com with ESMTPS id k15sm2239802lbd.6.2013.02.05.05.14.28
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 05:14:28 -0800 (PST)
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
To: xen-devel@lists.xen.org
Date: Tue,  5 Feb 2013 17:14:20 +0400
Message-Id: <1360070060-12424-1-git-send-email-v.tolstov@selfip.ru>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <20130201144255.GA7461@konrad-lan.dumpdata.com>
References: <20130201144255.GA7461@konrad-lan.dumpdata.com>
X-Gm-Message-State: ALoCoQmZzQ7AQZ5cH5cr77pw2yRzCzf8A6m32gRu3j34SSaEd0venQbMsdeoA/jA+dxP4+Ihhtsj
Cc: Vasiliy Tolstov <vase@clodo.ru>
Subject: [Xen-devel] [PATCH 1/1] drivers/block/xen-blkback: Limit blkback i/o
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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: Vasiliy Tolstov <vase@clodo.ru>

This patch provide ability to limit i/o for each domU block device.
With this patch dom0 administrator can specify maximum iops for
each block device. Changes apply dinamicaly and domU does not need
shutdown (in case of dm-ioband). Another good thing that dom0 may
not use CFQ scheduler.

Afer apply this patch we can control domU disk speed by writing
needed iops maximum to specific block device.

via sysfs:
echo 1500 > /sys/devices/xen-backend/vbd-1-51712/qos/reqrate

via xenstore:
xenstore write /local/domain/1/device/vbd/51712/reqrate 1500

Current xen i/o limiting solutions have following disadvantages:

1) dm-ioband
  It need to create another dm layer on top of block device. Lacks
  of ability to change weight on the fly (needs recreate layer).
  Its not in kernel yet. Patches need to backport/forwardport to
  specific kernel version. Under our heavy load, sometimes
  dm-ioband layer crash dom0. If we use dm-ioband on srp->lvm->raid1
  setup and srp target disconnects dm-ioband may breaks data and
  domU fs have many errors.

2) cgroups
  Very good thing. But in our setup we can't use it. cgroups needs
  CFQ scheduler, but CFQ not apply to bio devices see device-mapper
  list http://goo.gl/YHiyI
  Our setup contains 2 storage nodes that export disks by srp.
  On each storage we have lvm (not clvm). Each domU have disk on lvm.
  Before start domain on xen node we construct raid1 from two lvm vg.
  In this case CFQ scheduler may be applied only to srp disk (/dev/sd*),
  but in this case we only limit all domU on this xen node in the same
  time.

Signed-off-by: Vasiliy Tolstov <vase@clodo.ru>
---
 drivers/block/xen-blkback/blkback.c |   35 +++++++-
 drivers/block/xen-blkback/common.h  |    5 ++
 drivers/block/xen-blkback/xenbus.c  |  152 +++++++++++++++++++++++++++++++++++
 3 files changed, 191 insertions(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 74374fb..0672ab0 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -387,10 +387,18 @@ static void print_stats(struct xen_blkif *blkif)
 	blkif->st_ds_req = 0;
 }
 
+static void refill_iops(blkif_t *blkif)
+{
+	blkif->reqtime = jiffies + msecs_to_jiffies(1000);
+	blkif->reqcount = 0;
+}
+
 int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	int     ret = 0;
+	struct timeval cur_time;
 
 	xen_blkif_get(blkif);
 
@@ -411,9 +419,20 @@ int xen_blkif_schedule(void *arg)
 		blkif->waiting_reqs = 0;
 		smp_mb(); /* clear flag *before* checking for work */
 
-		if (do_block_io_op(blkif))
+		ret = do_block_io_op(blkif);
+		if (ret)
 			blkif->waiting_reqs = 1;
 
+		if (blkif->reqrate) {
+			if (2 == ret && (blkif->reqtime > jiffies)) {
+				jiffies_to_timeval(jiffies, &cur_time);
+				set_current_state(TASK_INTERRUPTIBLE);
+				schedule_timeout(blkif->reqtime - jiffies);
+			}
+			if (time_after(jiffies, blkif->reqtime))
+				refill_iops(blkif);
+		}
+
 		if (log_stats && time_after(jiffies, blkif->st_print))
 			print_stats(blkif);
 	}
@@ -760,6 +779,10 @@ __do_block_io_op(struct xen_blkif *blkif)
 	rp = blk_rings->common.sring->req_prod;
 	rmb(); /* Ensure we see queued requests up to 'rp'. */
 
+	if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
+		return (rc != rp) ? 2 : 0;
+	}
+
 	while (rc != rp) {
 
 		if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
@@ -770,6 +793,13 @@ __do_block_io_op(struct xen_blkif *blkif)
 			break;
 		}
 
+		if (blkif->reqrate) {
+			if (blkif->reqcount >= blkif->reqrate) {
+				more_to_do = 2;
+				break;
+			}
+		}
+
 		pending_req = alloc_req();
 		if (NULL == pending_req) {
 			blkif->st_oo_req++;
@@ -792,6 +822,7 @@ __do_block_io_op(struct xen_blkif *blkif)
 		}
 		blk_rings->common.req_cons = ++rc; /* before make_response() */
 
+		blkif->reqcount++;
 		/* Apply all sanity checks to /private copy/ of request. */
 		barrier();
 		if (unlikely(req.operation == BLKIF_OP_DISCARD)) {
@@ -842,6 +873,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	struct blk_plug plug;
 	bool drain = false;
 	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct timeval cur_time;
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -992,6 +1024,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	else if (operation & WRITE)
 		blkif->st_wr_sect += preq.nr_sects;
 
+	jiffies_to_timeval(jiffies, &cur_time);
 	return 0;
 
  fail_flush:
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 6072390..0552ce3 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -206,6 +206,11 @@ struct xen_blkif {
 	struct rb_root		persistent_gnts;
 	unsigned int		persistent_gnt_c;
 
+	/* qos information */
+	unsigned long   reqtime;
+	int    reqcount;
+	int    reqrate;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 6398072..f8afe76 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@ struct backend_info {
 	struct xenbus_device	*dev;
 	struct xen_blkif	*blkif;
 	struct xenbus_watch	backend_watch;
+	struct xenbus_watch	reqrate_watch;
 	unsigned		major;
 	unsigned		minor;
 	char			*mode;
@@ -230,6 +231,79 @@ int __init xen_blkif_interface_init(void)
 	}								\
 	static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
 
+static ssize_t
+show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t ret = -ENODEV;
+	struct xenbus_device *dev;
+	struct backend_info *be;
+
+	if (!get_device(_dev))
+		return ret;
+
+	dev = to_xenbus_device(_dev);
+	be = dev_get_drvdata(&dev->dev);
+
+	if (be != NULL)
+		ret = sprintf(buf, "%d\n", be->blkif->reqrate);
+
+	put_device(_dev);
+
+	return ret;
+}
+
+static ssize_t
+store_reqrate(struct device *_dev, struct device_attribute *attr,
+		const char *buf, size_t size)
+{
+	int value;
+	struct xenbus_device *dev;
+	struct backend_info *be;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	if (!get_device(_dev))
+		return -ENODEV;
+
+	if (sscanf(buf, "%d", &value) != 1)
+		return -EINVAL;
+
+	dev = to_xenbus_device(_dev);
+	be = dev_get_drvdata(&dev->dev);
+
+	if (be != NULL)
+		be->blkif->reqrate = value;
+
+	put_device(_dev);
+
+	return size;
+}
+static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
+			store_reqrate);
+
+static ssize_t
+show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t ret = -ENODEV;
+	struct xenbus_device *dev;
+	struct backend_info *be;
+
+	if (!get_device(_dev))
+		return ret;
+
+	dev = to_xenbus_device(_dev);
+	be = dev_get_drvdata(&dev->dev);
+
+	if (be != NULL)
+		ret = sprintf(buf, "%d\n", be->blkif->reqcount);
+
+	put_device(_dev);
+
+	return ret;
+}
+static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
+
 VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
 VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
 VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
@@ -254,6 +328,17 @@ static struct attribute_group xen_vbdstat_group = {
 	.attrs = xen_vbdstat_attrs,
 };
 
+static struct attribute *vbdreq_attrs[] = {
+	&dev_attr_reqrate.attr,
+	&dev_attr_reqcount.attr,
+	NULL
+};
+
+static const struct attribute_group vbdreq_group = {
+	.name = "qos",
+	.attrs = vbdreq_attrs,
+};
+
 VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
 VBD_SHOW(mode, "%s\n", be->mode);
 
@@ -273,8 +358,13 @@ static int xenvbd_sysfs_addif(struct xenbus_device *dev)
 	if (error)
 		goto fail3;
 
+	error = sysfs_create_group(&dev->dev.kobj, &xen_vbdreq_group);
+	if (error)
+		goto fail4;
+
 	return 0;
 
+fail4:	sysfs_remove_group(&dev->dev.kobj, &xen_vbdreq_group);
 fail3:	sysfs_remove_group(&dev->dev.kobj, &xen_vbdstat_group);
 fail2:	device_remove_file(&dev->dev, &dev_attr_mode);
 fail1:	device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -283,6 +373,7 @@ fail1:	device_remove_file(&dev->dev, &dev_attr_physical_device);
 
 static void xenvbd_sysfs_delif(struct xenbus_device *dev)
 {
+	sysfs_remove_group(&dev->dev.kobj, &xen_vbdreq_group);
 	sysfs_remove_group(&dev->dev.kobj, &xen_vbdstat_group);
 	device_remove_file(&dev->dev, &dev_attr_mode);
 	device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -360,6 +451,12 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 		be->backend_watch.node = NULL;
 	}
 
+	if (be->reqrate_watch.node) {
+		unregister_xenbus_watch(&be->reqrate_watch);
+		kfree(be->reqrate_watch.node);
+		be->reqrate_watch.node = NULL;
+	}
+
 	if (be->blkif) {
 		xen_blkif_disconnect(be->blkif);
 		xen_vbd_free(&be->blkif->vbd);
@@ -503,6 +600,7 @@ static void backend_changed(struct xenbus_watch *watch,
 	struct xenbus_device *dev = be->dev;
 	int cdrom = 0;
 	char *device_type;
+	char name[TASK_COMM_LEN];
 
 	DPRINTK("");
 
@@ -542,6 +640,21 @@ static void backend_changed(struct xenbus_watch *watch,
 		kfree(device_type);
 	}
 
+	/* gather information about QoS policy for this device. */
+	err = blkback_name(be->blkif, name);
+	if (err) {
+		xenbus_dev_error(be->dev, err, "get blkback dev name");
+		return;
+	}
+
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+				"reqrate", "%d", &be->blkif->reqrate,
+				NULL);
+	if (err)
+		DPRINTK("%s xenbus_gather(reqrate) error", name);
+
+	be->blkif->reqtime = jiffies;
+
 	if (be->major == 0 && be->minor == 0) {
 		/* Front end dir is a number, which is used as the handle. */
 
@@ -645,6 +758,30 @@ static void frontend_changed(struct xenbus_device *dev,
 
 /* ** Connection ** */
 
+static void reqrate_changed(struct xenbus_watch *watch,
+			const char **vec, unsigned int len)
+{
+	struct backend_info *be = container_of(watch, struct backend_info,
+						reqrate_watch);
+	int err;
+	char name[TASK_COMM_LEN];
+
+	err = blkback_name(be->blkif, name);
+	if (err) {
+		xenbus_dev_error(be->dev, err, "get blkback dev name");
+		return;
+	}
+
+	err = xenbus_gather(XBT_NIL, be->dev->otherend,
+					"reqrate",  "%d",
+					&be->blkif->reqrate, NULL);
+	if (err) {
+		DPRINTK("%s xenbus_gather(reqrate) error", name);
+	} else {
+		if (be->blkif->reqrate <= 0)
+			be->blkif->reqrate = 0;
+	}
+}
 
 /*
  * Write the physical details regarding the block device to the store, and
@@ -717,6 +854,21 @@ again:
 		xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
 				 dev->nodename);
 
+	if (be->reqrate_watch.node) {
+		unregister_xenbus_watch(&be->reqrate_watch);
+		kfree(be->reqrate_watch.node);
+		be->reqrate_watch.node = NULL;
+	}
+
+	err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
+					&be->reqrate_watch,
+					reqrate_changed);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "%s: watching reqrate",
+					dev->nodename);
+		goto abort;
+	}
+
 	return;
  abort:
 	xenbus_transaction_end(xbt, 1);
-- 
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 Tue Feb 05 13:19:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:19: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 1U2iQk-00018N-4N; Tue, 05 Feb 2013 13:19:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <v.tolstov@selfip.ru>) id 1U2iQi-00017H-Lz
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 13:19:21 +0000
Received: from [193.109.254.147:59237] by server-10.bemta-14.messagelabs.com
	id 88/12-12679-8D601115; Tue, 05 Feb 2013 13:19:20 +0000
X-Env-Sender: v.tolstov@selfip.ru
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360070070!9292521!1
X-Originating-IP: [209.85.217.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_19,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNjIyMDEgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12626 invoked from network); 5 Feb 2013 13:14:31 -0000
Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com)
	(209.85.217.172)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 13:14:31 -0000
Received: by mail-lb0-f172.google.com with SMTP id n8so207624lbj.31
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 05:14:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=wuFxdZwhWCazJrfkCd60b4Jf1W2OxzZTgOSrHoEhTLk=;
	b=VMbj4CY6zuMOXOl5wa4FsSgA8hmK1TxuEGni4OpGJdGWwHuzP2XqMQVtF8v5IXYTwy
	2EO/Idm/usn1xc02lC+4srWDXc+32afIlO/PVVYzBz7DLV+Gi9QmUrMdM5fFOK4UxRNc
	va1ih5gJEXB7VMHXOFZKYvc8Nr4oZejrwwlHM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references:x-gm-message-state;
	bh=wuFxdZwhWCazJrfkCd60b4Jf1W2OxzZTgOSrHoEhTLk=;
	b=fnD4UEKRHx6ZFo/10P7Dtn0nMgSa51WjDldf6KGeqsi+x0ltPE/n7pcqET5dI7OFOL
	MkdVRtJabI6SkC36gbmNiRbPxx8iKtQY4UJnn3B6g3Bs/ZtC8cd5SGq/tHT88kSsLZQb
	nMOTlVlzJSf17JdzY5Q2som6FaWMpOYo6y+qA2QX4zKiarA/t8ErdrXgmrt4ZMXujIWr
	X3VHcyePDZFP/F58CZLg8TrFwOG6j/doZdKy9ihMxFOUMHrD8SqJkil1u915rKK2ySvN
	pZ5JRdptA8zJreHivZ83KT5gDOt4mjw0G/eZlQISrKnEiZebwpLopVkDi8FVe5+RILTr
	Sgjg==
X-Received: by 10.152.111.102 with SMTP id ih6mr22850839lab.20.1360070070499; 
	Tue, 05 Feb 2013 05:14:30 -0800 (PST)
Received: from vase.office.clodo.ru (85-143-161-18.customer.comfortel.pro.
	[85.143.161.18])
	by mx.google.com with ESMTPS id k15sm2239802lbd.6.2013.02.05.05.14.28
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 05:14:28 -0800 (PST)
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
To: xen-devel@lists.xen.org
Date: Tue,  5 Feb 2013 17:14:20 +0400
Message-Id: <1360070060-12424-1-git-send-email-v.tolstov@selfip.ru>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <20130201144255.GA7461@konrad-lan.dumpdata.com>
References: <20130201144255.GA7461@konrad-lan.dumpdata.com>
X-Gm-Message-State: ALoCoQmZzQ7AQZ5cH5cr77pw2yRzCzf8A6m32gRu3j34SSaEd0venQbMsdeoA/jA+dxP4+Ihhtsj
Cc: Vasiliy Tolstov <vase@clodo.ru>
Subject: [Xen-devel] [PATCH 1/1] drivers/block/xen-blkback: Limit blkback i/o
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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: Vasiliy Tolstov <vase@clodo.ru>

This patch provide ability to limit i/o for each domU block device.
With this patch dom0 administrator can specify maximum iops for
each block device. Changes apply dinamicaly and domU does not need
shutdown (in case of dm-ioband). Another good thing that dom0 may
not use CFQ scheduler.

Afer apply this patch we can control domU disk speed by writing
needed iops maximum to specific block device.

via sysfs:
echo 1500 > /sys/devices/xen-backend/vbd-1-51712/qos/reqrate

via xenstore:
xenstore write /local/domain/1/device/vbd/51712/reqrate 1500

Current xen i/o limiting solutions have following disadvantages:

1) dm-ioband
  It need to create another dm layer on top of block device. Lacks
  of ability to change weight on the fly (needs recreate layer).
  Its not in kernel yet. Patches need to backport/forwardport to
  specific kernel version. Under our heavy load, sometimes
  dm-ioband layer crash dom0. If we use dm-ioband on srp->lvm->raid1
  setup and srp target disconnects dm-ioband may breaks data and
  domU fs have many errors.

2) cgroups
  Very good thing. But in our setup we can't use it. cgroups needs
  CFQ scheduler, but CFQ not apply to bio devices see device-mapper
  list http://goo.gl/YHiyI
  Our setup contains 2 storage nodes that export disks by srp.
  On each storage we have lvm (not clvm). Each domU have disk on lvm.
  Before start domain on xen node we construct raid1 from two lvm vg.
  In this case CFQ scheduler may be applied only to srp disk (/dev/sd*),
  but in this case we only limit all domU on this xen node in the same
  time.

Signed-off-by: Vasiliy Tolstov <vase@clodo.ru>
---
 drivers/block/xen-blkback/blkback.c |   35 +++++++-
 drivers/block/xen-blkback/common.h  |    5 ++
 drivers/block/xen-blkback/xenbus.c  |  152 +++++++++++++++++++++++++++++++++++
 3 files changed, 191 insertions(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 74374fb..0672ab0 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -387,10 +387,18 @@ static void print_stats(struct xen_blkif *blkif)
 	blkif->st_ds_req = 0;
 }
 
+static void refill_iops(blkif_t *blkif)
+{
+	blkif->reqtime = jiffies + msecs_to_jiffies(1000);
+	blkif->reqcount = 0;
+}
+
 int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	int     ret = 0;
+	struct timeval cur_time;
 
 	xen_blkif_get(blkif);
 
@@ -411,9 +419,20 @@ int xen_blkif_schedule(void *arg)
 		blkif->waiting_reqs = 0;
 		smp_mb(); /* clear flag *before* checking for work */
 
-		if (do_block_io_op(blkif))
+		ret = do_block_io_op(blkif);
+		if (ret)
 			blkif->waiting_reqs = 1;
 
+		if (blkif->reqrate) {
+			if (2 == ret && (blkif->reqtime > jiffies)) {
+				jiffies_to_timeval(jiffies, &cur_time);
+				set_current_state(TASK_INTERRUPTIBLE);
+				schedule_timeout(blkif->reqtime - jiffies);
+			}
+			if (time_after(jiffies, blkif->reqtime))
+				refill_iops(blkif);
+		}
+
 		if (log_stats && time_after(jiffies, blkif->st_print))
 			print_stats(blkif);
 	}
@@ -760,6 +779,10 @@ __do_block_io_op(struct xen_blkif *blkif)
 	rp = blk_rings->common.sring->req_prod;
 	rmb(); /* Ensure we see queued requests up to 'rp'. */
 
+	if (blkif->reqrate && (blkif->reqcount >= blkif->reqrate)) {
+		return (rc != rp) ? 2 : 0;
+	}
+
 	while (rc != rp) {
 
 		if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rc))
@@ -770,6 +793,13 @@ __do_block_io_op(struct xen_blkif *blkif)
 			break;
 		}
 
+		if (blkif->reqrate) {
+			if (blkif->reqcount >= blkif->reqrate) {
+				more_to_do = 2;
+				break;
+			}
+		}
+
 		pending_req = alloc_req();
 		if (NULL == pending_req) {
 			blkif->st_oo_req++;
@@ -792,6 +822,7 @@ __do_block_io_op(struct xen_blkif *blkif)
 		}
 		blk_rings->common.req_cons = ++rc; /* before make_response() */
 
+		blkif->reqcount++;
 		/* Apply all sanity checks to /private copy/ of request. */
 		barrier();
 		if (unlikely(req.operation == BLKIF_OP_DISCARD)) {
@@ -842,6 +873,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	struct blk_plug plug;
 	bool drain = false;
 	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct timeval cur_time;
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -992,6 +1024,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	else if (operation & WRITE)
 		blkif->st_wr_sect += preq.nr_sects;
 
+	jiffies_to_timeval(jiffies, &cur_time);
 	return 0;
 
  fail_flush:
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 6072390..0552ce3 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -206,6 +206,11 @@ struct xen_blkif {
 	struct rb_root		persistent_gnts;
 	unsigned int		persistent_gnt_c;
 
+	/* qos information */
+	unsigned long   reqtime;
+	int    reqcount;
+	int    reqrate;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 6398072..f8afe76 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@ struct backend_info {
 	struct xenbus_device	*dev;
 	struct xen_blkif	*blkif;
 	struct xenbus_watch	backend_watch;
+	struct xenbus_watch	reqrate_watch;
 	unsigned		major;
 	unsigned		minor;
 	char			*mode;
@@ -230,6 +231,79 @@ int __init xen_blkif_interface_init(void)
 	}								\
 	static DEVICE_ATTR(name, S_IRUGO, show_##name, NULL)
 
+static ssize_t
+show_reqrate(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t ret = -ENODEV;
+	struct xenbus_device *dev;
+	struct backend_info *be;
+
+	if (!get_device(_dev))
+		return ret;
+
+	dev = to_xenbus_device(_dev);
+	be = dev_get_drvdata(&dev->dev);
+
+	if (be != NULL)
+		ret = sprintf(buf, "%d\n", be->blkif->reqrate);
+
+	put_device(_dev);
+
+	return ret;
+}
+
+static ssize_t
+store_reqrate(struct device *_dev, struct device_attribute *attr,
+		const char *buf, size_t size)
+{
+	int value;
+	struct xenbus_device *dev;
+	struct backend_info *be;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
+	if (!get_device(_dev))
+		return -ENODEV;
+
+	if (sscanf(buf, "%d", &value) != 1)
+		return -EINVAL;
+
+	dev = to_xenbus_device(_dev);
+	be = dev_get_drvdata(&dev->dev);
+
+	if (be != NULL)
+		be->blkif->reqrate = value;
+
+	put_device(_dev);
+
+	return size;
+}
+static DEVICE_ATTR(reqrate, S_IRUGO | S_IWUSR, show_reqrate,
+			store_reqrate);
+
+static ssize_t
+show_reqcount(struct device *_dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t ret = -ENODEV;
+	struct xenbus_device *dev;
+	struct backend_info *be;
+
+	if (!get_device(_dev))
+		return ret;
+
+	dev = to_xenbus_device(_dev);
+	be = dev_get_drvdata(&dev->dev);
+
+	if (be != NULL)
+		ret = sprintf(buf, "%d\n", be->blkif->reqcount);
+
+	put_device(_dev);
+
+	return ret;
+}
+static DEVICE_ATTR(reqcount, S_IRUGO | S_IWUSR, show_reqcount, NULL);
+
 VBD_SHOW(oo_req,  "%d\n", be->blkif->st_oo_req);
 VBD_SHOW(rd_req,  "%d\n", be->blkif->st_rd_req);
 VBD_SHOW(wr_req,  "%d\n", be->blkif->st_wr_req);
@@ -254,6 +328,17 @@ static struct attribute_group xen_vbdstat_group = {
 	.attrs = xen_vbdstat_attrs,
 };
 
+static struct attribute *vbdreq_attrs[] = {
+	&dev_attr_reqrate.attr,
+	&dev_attr_reqcount.attr,
+	NULL
+};
+
+static const struct attribute_group vbdreq_group = {
+	.name = "qos",
+	.attrs = vbdreq_attrs,
+};
+
 VBD_SHOW(physical_device, "%x:%x\n", be->major, be->minor);
 VBD_SHOW(mode, "%s\n", be->mode);
 
@@ -273,8 +358,13 @@ static int xenvbd_sysfs_addif(struct xenbus_device *dev)
 	if (error)
 		goto fail3;
 
+	error = sysfs_create_group(&dev->dev.kobj, &xen_vbdreq_group);
+	if (error)
+		goto fail4;
+
 	return 0;
 
+fail4:	sysfs_remove_group(&dev->dev.kobj, &xen_vbdreq_group);
 fail3:	sysfs_remove_group(&dev->dev.kobj, &xen_vbdstat_group);
 fail2:	device_remove_file(&dev->dev, &dev_attr_mode);
 fail1:	device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -283,6 +373,7 @@ fail1:	device_remove_file(&dev->dev, &dev_attr_physical_device);
 
 static void xenvbd_sysfs_delif(struct xenbus_device *dev)
 {
+	sysfs_remove_group(&dev->dev.kobj, &xen_vbdreq_group);
 	sysfs_remove_group(&dev->dev.kobj, &xen_vbdstat_group);
 	device_remove_file(&dev->dev, &dev_attr_mode);
 	device_remove_file(&dev->dev, &dev_attr_physical_device);
@@ -360,6 +451,12 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
 		be->backend_watch.node = NULL;
 	}
 
+	if (be->reqrate_watch.node) {
+		unregister_xenbus_watch(&be->reqrate_watch);
+		kfree(be->reqrate_watch.node);
+		be->reqrate_watch.node = NULL;
+	}
+
 	if (be->blkif) {
 		xen_blkif_disconnect(be->blkif);
 		xen_vbd_free(&be->blkif->vbd);
@@ -503,6 +600,7 @@ static void backend_changed(struct xenbus_watch *watch,
 	struct xenbus_device *dev = be->dev;
 	int cdrom = 0;
 	char *device_type;
+	char name[TASK_COMM_LEN];
 
 	DPRINTK("");
 
@@ -542,6 +640,21 @@ static void backend_changed(struct xenbus_watch *watch,
 		kfree(device_type);
 	}
 
+	/* gather information about QoS policy for this device. */
+	err = blkback_name(be->blkif, name);
+	if (err) {
+		xenbus_dev_error(be->dev, err, "get blkback dev name");
+		return;
+	}
+
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+				"reqrate", "%d", &be->blkif->reqrate,
+				NULL);
+	if (err)
+		DPRINTK("%s xenbus_gather(reqrate) error", name);
+
+	be->blkif->reqtime = jiffies;
+
 	if (be->major == 0 && be->minor == 0) {
 		/* Front end dir is a number, which is used as the handle. */
 
@@ -645,6 +758,30 @@ static void frontend_changed(struct xenbus_device *dev,
 
 /* ** Connection ** */
 
+static void reqrate_changed(struct xenbus_watch *watch,
+			const char **vec, unsigned int len)
+{
+	struct backend_info *be = container_of(watch, struct backend_info,
+						reqrate_watch);
+	int err;
+	char name[TASK_COMM_LEN];
+
+	err = blkback_name(be->blkif, name);
+	if (err) {
+		xenbus_dev_error(be->dev, err, "get blkback dev name");
+		return;
+	}
+
+	err = xenbus_gather(XBT_NIL, be->dev->otherend,
+					"reqrate",  "%d",
+					&be->blkif->reqrate, NULL);
+	if (err) {
+		DPRINTK("%s xenbus_gather(reqrate) error", name);
+	} else {
+		if (be->blkif->reqrate <= 0)
+			be->blkif->reqrate = 0;
+	}
+}
 
 /*
  * Write the physical details regarding the block device to the store, and
@@ -717,6 +854,21 @@ again:
 		xenbus_dev_fatal(dev, err, "%s: switching to Connected state",
 				 dev->nodename);
 
+	if (be->reqrate_watch.node) {
+		unregister_xenbus_watch(&be->reqrate_watch);
+		kfree(be->reqrate_watch.node);
+		be->reqrate_watch.node = NULL;
+	}
+
+	err = xenbus_watch_path2(dev, dev->otherend, "reqrate",
+					&be->reqrate_watch,
+					reqrate_changed);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "%s: watching reqrate",
+					dev->nodename);
+		goto abort;
+	}
+
 	return;
  abort:
 	xenbus_transaction_end(xbt, 1);
-- 
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 Tue Feb 05 13:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:20: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 1U2iRP-0001XG-9K; Tue, 05 Feb 2013 13:20:03 +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 1U2iRO-0001WO-62
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 13:20:02 +0000
Received: from [85.158.139.211:8026] by server-16.bemta-5.messagelabs.com id
	E3/3B-14948-10701115; Tue, 05 Feb 2013 13:20:01 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360070400!18420671!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13666 invoked from network); 5 Feb 2013 13:20:00 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 13:20:00 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 2B5C040036D;
	Tue,  5 Feb 2013 14:20:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5fsjNWp4cOPl; Tue,  5 Feb 2013 14:19:59 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id DEFD140010D;
	Tue,  5 Feb 2013 14:19:58 +0100 (CET)
Message-ID: <511106FD.4040600@tiscali.it>
Date: Tue, 05 Feb 2013 14:19:57 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360060432.17017.22.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
	support for upstream-qemu-xen.
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="===============7619136134647951715=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7619136134647951715==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070207070509080802090805"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070207070509080802090805
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 05/02/2013 11:33, Ian Campbell ha scritto:
> On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
>> tools/libxl: Add qxl vga interface support for
>>    upstream-qemu-xen.
>>
>> Usage:
>>     qxl=3D1|0
>>
>> Changes from v7:
>> - Fix videoram settings parameters for qemu.
>>
>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> Unfortunately this patch is whitespace damaged in various places.

I'll try from linux instead windows, I can also add patches as=20
attachment on next messages?

>> ---
>>    docs/man/xl.cfg.pod.5       |   11 +++++++++++
>>    tools/libxl/libxl_create.c  |   12 ++++++++++++
>>    tools/libxl/libxl_dm.c      |   15 +++++++++++++++
>>    tools/libxl/libxl_types.idl |    1 +
>>    tools/libxl/xl_cmdimpl.c    |    7 ++++++-
>>    5 files changed, 45 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index 9c5cdcd..a0f0dc3 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is
>> sufficient
>>    for 1024x768 at 32 bpp and videoram option is currently working
>>    only when using the upstream qemu-xen device-model.
>>
>> +For B<qxl> vga, the default is both default and minimal 128MB.
>> +If B<videoram> is set less than 128MB, an error will be triggered.
>> +
>>    =3Ditem B<stdvga=3DBOOLEAN>
>>
>>    Select a standard VGA card with VBE (VESA BIOS Extensions) as the
>> @@ -992,6 +995,14 @@ a Cirrus Logic GD5446 VGA card. If your guest
>> supports VBE 2.0 or
>>    later (e.g. Windows XP onwards) then you should enable this.
>>    stdvga supports more video ram and bigger resolutions than Cirrus.
>>
>> +=3Ditem B<qxl=3DBOOLEAN>
> What happens if I give qxl=3D1 and stdvga=3D1?
>
> Perhaps we should deprecate stdvga and add a new option:
> 	vga =3D "stdvga|cirrus|qxl"
> ?

Yes that should be nice.
I'll do a patch that remove stdvga option and add vga option.

>> +
>> +Select a QXL VGA card as the emulated graphics device.
>> +In general, QXL should work with the Spice remote display protocol
>> +for acceleration, and QXL driver is necessary in guest in this case.
> Do we have any docs on where to obtain this driver and how to install
> it? On the wiki perhaps, a link would be useful.
>
>> +QXL can also work with the VNC protocol, but it will be like a standa=
rd
>> +VGA without acceleration.
>> +
>>    =3Ditem B<vnc=3DBOOLEAN>
>>
>>    Allow access to the display via the VNC protocol.  This enables the=

>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 55014e5..4761b5a 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -197,6 +197,18 @@ int libxl__domain_build_info_setdefault(libxl__gc=
 *gc,
>>        case LIBXL_DOMAIN_TYPE_HVM:
>>            if (b_info->shadow_memkb =3D=3D LIBXL_MEMKB_DEFAULT)
>>                b_info->shadow_memkb =3D 0;
>> +
>> +        if (b_info->device_model_version =3D=3D
>> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
>> +            && b_info->u.hvm.vga.kind =3D=3D LIBXL_VGA_INTERFACE_TYPE=
_QXL) {
>> +            if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DEFAULT) {
>> +                b_info->video_memkb =3D (128 * 1024);
>> +            }else if (b_info->video_memkb < (128 * 1024)) {
>> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
>> +                    "128 Mib videoram is the minimum for qxl default"=
);
> You can use the LOG() macros to shorten this line (and in other places
> including you videoram patch too).
>
> Should this error out on qemu =3D=3D traditional and vga =3D=3D QXL?

Must I only replace LIBXL__LOG with LOG?

I'll add error and exit if vga=3Dqxl and qemu is traditional.

>> +                return ERROR_INVAL;
>> +            }
>> +        }
>> +
>>            if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DEFAULT)
>>                b_info->video_memkb =3D 8 * 1024;
>>            else if (b_info->video_memkb < 8192){
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 465b1fd..0813258 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -437,6 +439,19 @@ static char **
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>                    NULL);
>>                }
>>                break;
>> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
>> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> flexarray_append_pair() ?
>> +            if (b_info->video_memkb) {
>> +                flexarray_vappend(dm_args, "-global",
>> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=3D%lu",
>> +                (b_info->video_memkb/2/1024)),
>> +                NULL);
>> +                flexarray_vappend(dm_args, "-global",
>> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=3D%lu",
>> +                (b_info->video_memkb/2/1024)),
>> +                NULL);
> You could combine the second two vappends into a single one, or use
> flexarray_append_pair().
>
> The /2 is because the videomem is split between vram and ram? A comment=

> to that affect would be useful.

I'll try to use flexarray_append_pair() instead.
I'll also add small comment about 2 qxl ram regions.

>
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 080bbd8..b4f7a0e 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -1469,7 +1469,12 @@ skip_vfb:
>>    #undef parse_extra_args
>>
>>        if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> +        if (!xlu_cfg_get_long(config, "qxl", &l, 0))
>> +            b_info->u.hvm.vga.kind =3D l ? LIBXL_VGA_INTERFACE_TYPE_Q=
XL :
>> + LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>> +
>> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0) &&
>> +            b_info->u.hvm.vga.kind !=3D LIBXL_VGA_INTERFACE_TYPE_QXL)=

>>                b_info->u.hvm.vga.kind =3D l ? LIBXL_VGA_INTERFACE_TYPE=
_STD :
>> LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2897 / Database dei virus: 2639/6080 -  Data di rilasc=
io: 04/02/2013
>
>



--------------ms070207070509080802090805
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNTEzMTk1N1owIwYJKoZIhvcNAQkEMRYEFFlcyh13aZ5BVPGjF/BA5kQX
AXnPMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAJDDy0PjE9Lwq8uNYF/Lnhqwg
HCU3SW6xsvuYclBwyJW/k0S7GQ+eIVsoneeaw2wTyE0qjkkxSYnmoFjAn/boAukwjfGRxZ1v
siQK5GL+JO7xhngexmWzlZ2RFj+jNlCA2F8w+fRFW+fpruZSQy/29lRwFTvy7Pg8U5DV9Vgm
rLc0AU/Uj9FysN5qsZ9J1SecxeirByrrRvcB9cNraGxj66KuwqD3AFjlUiaX4p3N6ki9EfXQ
w9d3j8WreiSTjh/ccj40+csnV7xXke+OezGanmjreehTYFnzhKDseL8ZbYvrALMIyCFKTW5C
tRZWbdPqVU8BVZwN7xFVtRdZiXF8jQAAAAAAAA==
--------------ms070207070509080802090805--


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

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

--===============7619136134647951715==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13:20: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 1U2iRP-0001XG-9K; Tue, 05 Feb 2013 13:20:03 +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 1U2iRO-0001WO-62
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 13:20:02 +0000
Received: from [85.158.139.211:8026] by server-16.bemta-5.messagelabs.com id
	E3/3B-14948-10701115; Tue, 05 Feb 2013 13:20:01 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360070400!18420671!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13666 invoked from network); 5 Feb 2013 13:20:00 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 13:20:00 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 2B5C040036D;
	Tue,  5 Feb 2013 14:20:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5fsjNWp4cOPl; Tue,  5 Feb 2013 14:19:59 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id DEFD140010D;
	Tue,  5 Feb 2013 14:19:58 +0100 (CET)
Message-ID: <511106FD.4040600@tiscali.it>
Date: Tue, 05 Feb 2013 14:19:57 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360060432.17017.22.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
	support for upstream-qemu-xen.
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="===============7619136134647951715=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7619136134647951715==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070207070509080802090805"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070207070509080802090805
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 05/02/2013 11:33, Ian Campbell ha scritto:
> On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
>> tools/libxl: Add qxl vga interface support for
>>    upstream-qemu-xen.
>>
>> Usage:
>>     qxl=3D1|0
>>
>> Changes from v7:
>> - Fix videoram settings parameters for qemu.
>>
>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> Unfortunately this patch is whitespace damaged in various places.

I'll try from linux instead windows, I can also add patches as=20
attachment on next messages?

>> ---
>>    docs/man/xl.cfg.pod.5       |   11 +++++++++++
>>    tools/libxl/libxl_create.c  |   12 ++++++++++++
>>    tools/libxl/libxl_dm.c      |   15 +++++++++++++++
>>    tools/libxl/libxl_types.idl |    1 +
>>    tools/libxl/xl_cmdimpl.c    |    7 ++++++-
>>    5 files changed, 45 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index 9c5cdcd..a0f0dc3 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is
>> sufficient
>>    for 1024x768 at 32 bpp and videoram option is currently working
>>    only when using the upstream qemu-xen device-model.
>>
>> +For B<qxl> vga, the default is both default and minimal 128MB.
>> +If B<videoram> is set less than 128MB, an error will be triggered.
>> +
>>    =3Ditem B<stdvga=3DBOOLEAN>
>>
>>    Select a standard VGA card with VBE (VESA BIOS Extensions) as the
>> @@ -992,6 +995,14 @@ a Cirrus Logic GD5446 VGA card. If your guest
>> supports VBE 2.0 or
>>    later (e.g. Windows XP onwards) then you should enable this.
>>    stdvga supports more video ram and bigger resolutions than Cirrus.
>>
>> +=3Ditem B<qxl=3DBOOLEAN>
> What happens if I give qxl=3D1 and stdvga=3D1?
>
> Perhaps we should deprecate stdvga and add a new option:
> 	vga =3D "stdvga|cirrus|qxl"
> ?

Yes that should be nice.
I'll do a patch that remove stdvga option and add vga option.

>> +
>> +Select a QXL VGA card as the emulated graphics device.
>> +In general, QXL should work with the Spice remote display protocol
>> +for acceleration, and QXL driver is necessary in guest in this case.
> Do we have any docs on where to obtain this driver and how to install
> it? On the wiki perhaps, a link would be useful.
>
>> +QXL can also work with the VNC protocol, but it will be like a standa=
rd
>> +VGA without acceleration.
>> +
>>    =3Ditem B<vnc=3DBOOLEAN>
>>
>>    Allow access to the display via the VNC protocol.  This enables the=

>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 55014e5..4761b5a 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -197,6 +197,18 @@ int libxl__domain_build_info_setdefault(libxl__gc=
 *gc,
>>        case LIBXL_DOMAIN_TYPE_HVM:
>>            if (b_info->shadow_memkb =3D=3D LIBXL_MEMKB_DEFAULT)
>>                b_info->shadow_memkb =3D 0;
>> +
>> +        if (b_info->device_model_version =3D=3D
>> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
>> +            && b_info->u.hvm.vga.kind =3D=3D LIBXL_VGA_INTERFACE_TYPE=
_QXL) {
>> +            if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DEFAULT) {
>> +                b_info->video_memkb =3D (128 * 1024);
>> +            }else if (b_info->video_memkb < (128 * 1024)) {
>> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
>> +                    "128 Mib videoram is the minimum for qxl default"=
);
> You can use the LOG() macros to shorten this line (and in other places
> including you videoram patch too).
>
> Should this error out on qemu =3D=3D traditional and vga =3D=3D QXL?

Must I only replace LIBXL__LOG with LOG?

I'll add error and exit if vga=3Dqxl and qemu is traditional.

>> +                return ERROR_INVAL;
>> +            }
>> +        }
>> +
>>            if (b_info->video_memkb =3D=3D LIBXL_MEMKB_DEFAULT)
>>                b_info->video_memkb =3D 8 * 1024;
>>            else if (b_info->video_memkb < 8192){
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 465b1fd..0813258 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -437,6 +439,19 @@ static char **
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>                    NULL);
>>                }
>>                break;
>> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
>> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> flexarray_append_pair() ?
>> +            if (b_info->video_memkb) {
>> +                flexarray_vappend(dm_args, "-global",
>> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=3D%lu",
>> +                (b_info->video_memkb/2/1024)),
>> +                NULL);
>> +                flexarray_vappend(dm_args, "-global",
>> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=3D%lu",
>> +                (b_info->video_memkb/2/1024)),
>> +                NULL);
> You could combine the second two vappends into a single one, or use
> flexarray_append_pair().
>
> The /2 is because the videomem is split between vram and ram? A comment=

> to that affect would be useful.

I'll try to use flexarray_append_pair() instead.
I'll also add small comment about 2 qxl ram regions.

>
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 080bbd8..b4f7a0e 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -1469,7 +1469,12 @@ skip_vfb:
>>    #undef parse_extra_args
>>
>>        if (c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) {
>> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>> +        if (!xlu_cfg_get_long(config, "qxl", &l, 0))
>> +            b_info->u.hvm.vga.kind =3D l ? LIBXL_VGA_INTERFACE_TYPE_Q=
XL :
>> + LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>> +
>> +        if (!xlu_cfg_get_long(config, "stdvga", &l, 0) &&
>> +            b_info->u.hvm.vga.kind !=3D LIBXL_VGA_INTERFACE_TYPE_QXL)=

>>                b_info->u.hvm.vga.kind =3D l ? LIBXL_VGA_INTERFACE_TYPE=
_STD :
>> LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2897 / Database dei virus: 2639/6080 -  Data di rilasc=
io: 04/02/2013
>
>



--------------ms070207070509080802090805
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNTEzMTk1N1owIwYJKoZIhvcNAQkEMRYEFFlcyh13aZ5BVPGjF/BA5kQX
AXnPMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAJDDy0PjE9Lwq8uNYF/Lnhqwg
HCU3SW6xsvuYclBwyJW/k0S7GQ+eIVsoneeaw2wTyE0qjkkxSYnmoFjAn/boAukwjfGRxZ1v
siQK5GL+JO7xhngexmWzlZ2RFj+jNlCA2F8w+fRFW+fpruZSQy/29lRwFTvy7Pg8U5DV9Vgm
rLc0AU/Uj9FysN5qsZ9J1SecxeirByrrRvcB9cNraGxj66KuwqD3AFjlUiaX4p3N6ki9EfXQ
w9d3j8WreiSTjh/ccj40+csnV7xXke+OezGanmjreehTYFnzhKDseL8ZbYvrALMIyCFKTW5C
tRZWbdPqVU8BVZwN7xFVtRdZiXF8jQAAAAAAAA==
--------------ms070207070509080802090805--


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

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

--===============7619136134647951715==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 13:32:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2icp-00041w-Oh; Tue, 05 Feb 2013 13:31:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2ico-00041g-5e
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 13:31:50 +0000
Received: from [85.158.138.51:37978] by server-10.bemta-3.messagelabs.com id
	38/1E-10609-5C901115; Tue, 05 Feb 2013 13:31:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360071106!31107488!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2296 invoked from network); 5 Feb 2013 13:31:48 -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;
	5 Feb 2013 13:31:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6309585"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 13:31:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 08:31:46 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2icj-0002vT-Q4;
	Tue, 05 Feb 2013 13:31:45 +0000
Message-ID: <1360071105.7477.139.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 5 Feb 2013 13:31:45 +0000
In-Reply-To: <1360061930.17017.34.camel@zakaz.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
	<1360061930.17017.34.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 10:58 +0000, Ian Campbell wrote:
> On Tue, 2013-01-22 at 14:50 +0000, Wei Liu wrote:
> > > > > > +		    !(reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) &&
> > > > > 
> > > > > This represents an error case I think? Is there anything we can do about
> > > > > it? If this sort of error occurs and we do nothing will we end up just
> > > > > spinning because every subsequent poll will just return straight away?
> > > > > 
> > > > > 
> > > > 
> > > > Yes, this represents an error. This indicates the pipe used to trigger
> > > > reopen_log is broken. What's the motivation of reopening log file?
> > > 
> > > Rotation I should imagine.
> > > 
> > > >  I
> > > > have no idea about the use case. But simply ignoring this error instead
> > > > of crashing the process is better choice IMHO.
> > > 
> > > Agreed, but my concern was that the daemon would spin consuming 100%
> > > CPU, which is nearly as bad as crashing.
> > > 
> > > > The whole pollfd set is reinitialized for every loop. So it is also
> > > > possible that for the next loop it will success even previous poll
> > > > fails?
> > > 
> > > I suppose it depends on the reason it failed. I would expect most of
> > > them would be pretty final rather than temporary but I haven't looked at
> > > the pipe docs.
> > > 
> > 
> > We can reinitialize the pipe if error occurs, because this pipe is only
> > used within xenstored itself to notify log reload.
> 
> But if you get POLLPRI or POLLOUT you don't do this with the code as it
> currently stands (from the v2 patch):
> +                       if (reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) {
> +                               close(reopen_log_pipe[0]);
> +                               close(reopen_log_pipe[1]);
> +                               init_pipe(reopen_log_pipe);
> +                       } else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
> +                               char c;
> +                               if (read(reopen_log_pipe[0], &c, 1) != 1)
> +                                       barf_perror("read failed");
> +                               reopen_log();
> +                       }
> 
> So on POLLRDHUP or POLLERR etc you reopen the log, on POLLIN you act as
> expected but for POLLPRI and POLLOUT you don't do anything.
> 
> If these two events should never occur then you should include the in
> the error handling part of the above. If they can occur then you need to
> do something to handle them, otherwise they will just keep reoccuring on
> every iteration.
> 
> The same goes for the other instances of this pattern.
> 
> Ian.
> 

I think POLLPRI and POLLOUT should not occur in most cases, here is a
updated version of the patch. Tested on my testbox and it works.

-----8<----
>From 22a7b50b8b0be62aeae7c86242a27dac1ffdb929 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 21 Jan 2013 19:07:37 +0000
Subject: [PATCH] Switch to poll() in cxenstored's IO loop

Poll() can support more file descriptors than select(). We've done this for
xenconsoled, now do this for cxenstored as well.

The code is taken from xenconsoled and modified to adapt to cxenstored.

Updated:
* reopen pipe if polling on reopen_log_pipe fails.
* exit if polling on some critical fds fails.
* clean up POLL*.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/xenstore/xenstored_core.c |  171 ++++++++++++++++++++++++++-------------
 tools/xenstore/xenstored_core.h |    2 +
 2 files changed, 116 insertions(+), 57 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index bd44645..839e51d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,7 +19,7 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/select.h>
+#include <poll.h>
 #ifndef NO_SOCKETS
 #include <sys/socket.h>
 #include <sys/un.h>
@@ -55,6 +55,12 @@
 #include "hashtable.h"
 
 extern xc_evtchn *xce_handle; /* in xenstored_domain.c */
+static struct pollfd *xce_pollfd;
+static struct pollfd *fds;
+static unsigned int current_array_size;
+static unsigned int nr_fds;
+
+#define ROUNDUP(_x, _w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
 static bool verbose = false;
 LIST_HEAD(connections);
@@ -62,6 +68,7 @@ static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
+static struct pollfd *reopen_log_pipe0_pollfd;
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx = NULL;
 
@@ -199,7 +206,7 @@ void trace_destroy(const void *data, const char *type)
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
- * the select() in the main loop.
+ * the poll() in the main loop.
  */
 static void trigger_reopen_log(int signal __attribute__((unused)))
 {
@@ -279,15 +286,12 @@ static int destroy_conn(void *_conn)
 
 	/* Flush outgoing if possible, but don't block. */
 	if (!conn->domain) {
-		fd_set set;
-		struct timeval none;
-
-		FD_ZERO(&set);
-		FD_SET(conn->fd, &set);
-		none.tv_sec = none.tv_usec = 0;
+		struct pollfd pfd;
+		pfd.fd = conn->fd;
+		pfd.events = POLLOUT;
 
 		while (!list_empty(&conn->out_list)
-		       && select(conn->fd+1, NULL, &set, NULL, &none) == 1)
+		       && poll(&pfd, 1, 0) == 1)
 			if (!write_messages(conn))
 				break;
 		close(conn->fd);
@@ -300,52 +304,74 @@ static int destroy_conn(void *_conn)
 }
 
 
-static void set_fd(int fd, fd_set *set, int *max)
+static struct pollfd *set_fd(int fd, short events)
 {
-	if (fd < 0)
-		return;
-	FD_SET(fd, set);
-	if (fd > *max)
-		*max = fd;
-}
+	struct pollfd *ret;
+	if (current_array_size < nr_fds + 1) {
+		struct pollfd *new_fds = NULL;
+		unsigned long newsize;
+
+		/* Round up to 2^8 boundary, in practice this just
+		 * make newsize larger than current_array_size.
+		 */
+		newsize = ROUNDUP(nr_fds + 1, 8);
 
+		new_fds = realloc(fds, sizeof(struct pollfd)*newsize);
+		if (!new_fds)
+			goto fail;
+		fds = new_fds;
 
-static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
-			  struct timeval **ptimeout)
+		memset(&fds[0] + current_array_size, 0,
+		       sizeof(struct pollfd ) * (newsize-current_array_size));
+		current_array_size = newsize;
+	}
+
+	fds[nr_fds].fd = fd;
+	fds[nr_fds].events = events;
+	ret = &fds[nr_fds];
+	nr_fds++;
+
+	return ret;
+fail:
+	syslog(LOG_ERR, "realloc failed, ignoring fd %d\n", fd);
+	return NULL;
+}
+
+static void initialize_fds(int sock, struct pollfd **p_sock_pollfd,
+			   int ro_sock, struct pollfd **p_ro_sock_pollfd,
+			   int *ptimeout)
 {
-	static struct timeval zero_timeout = { 0 };
 	struct connection *conn;
-	int max = -1;
 
-	*ptimeout = NULL;
+	memset(fds, 0, sizeof(struct pollfd) * current_array_size);
+	nr_fds = 0;
 
-	FD_ZERO(inset);
-	FD_ZERO(outset);
+	*ptimeout = -1;
 
 	if (sock != -1)
-		set_fd(sock, inset, &max);
+		*p_sock_pollfd = set_fd(sock, POLLIN|POLLPRI);
 	if (ro_sock != -1)
-		set_fd(ro_sock, inset, &max);
+		*p_ro_sock_pollfd = set_fd(ro_sock, POLLIN|POLLPRI);
 	if (reopen_log_pipe[0] != -1)
-		set_fd(reopen_log_pipe[0], inset, &max);
+		reopen_log_pipe0_pollfd =
+			set_fd(reopen_log_pipe[0], POLLIN|POLLPRI);
 
 	if (xce_handle != NULL)
-		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
+		xce_pollfd = set_fd(xc_evtchn_fd(xce_handle), POLLIN|POLLPRI);
 
 	list_for_each_entry(conn, &connections, list) {
 		if (conn->domain) {
 			if (domain_can_read(conn) ||
 			    (domain_can_write(conn) &&
 			     !list_empty(&conn->out_list)))
-				*ptimeout = &zero_timeout;
+				*ptimeout = 0;
 		} else {
-			set_fd(conn->fd, inset, &max);
+			short events = POLLIN|POLLPRI;
 			if (!list_empty(&conn->out_list))
-				FD_SET(conn->fd, outset);
+				events |= POLLOUT;
+			conn->pollfd = set_fd(conn->fd, events);
 		}
 	}
-
-	return max;
 }
 
 /* Is child a subnode of parent, or equal? */
@@ -1770,14 +1796,13 @@ int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock, *ro_sock, max;
-	fd_set inset, outset;
+	int opt, *sock, *ro_sock;
+	struct pollfd *sock_pollfd = NULL, *ro_sock_pollfd = NULL;
 	bool dofork = true;
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
-	int evtchn_fd = -1;
-	struct timeval *timeout;
+	int timeout;
 
 	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
 				  NULL)) != -1) {
@@ -1880,11 +1905,9 @@ int main(int argc, char *argv[])
 
 	signal(SIGHUP, trigger_reopen_log);
 
-	if (xce_handle != NULL)
-		evtchn_fd = xc_evtchn_fd(xce_handle);
-
 	/* Get ready to listen to the tools. */
-	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
+	initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+		       &timeout);
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -1893,27 +1916,55 @@ int main(int argc, char *argv[])
 	for (;;) {
 		struct connection *conn, *next;
 
-		if (select(max+1, &inset, &outset, NULL, timeout) < 0) {
+		if (poll(fds, nr_fds, timeout) < 0) {
 			if (errno == EINTR)
 				continue;
-			barf_perror("Select failed");
+			barf_perror("Poll failed");
 		}
 
-		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
-			char c;
-			if (read(reopen_log_pipe[0], &c, 1) != 1)
-				barf_perror("read failed");
-			reopen_log();
+		if (reopen_log_pipe0_pollfd) {
+			if (reopen_log_pipe0_pollfd->revents & ~POLLIN) {
+				close(reopen_log_pipe[0]);
+				close(reopen_log_pipe[1]);
+				init_pipe(reopen_log_pipe);
+			} else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
+				char c;
+				if (read(reopen_log_pipe[0], &c, 1) != 1)
+					barf_perror("read failed");
+				reopen_log();
+			}
+			reopen_log_pipe0_pollfd = NULL;
 		}
 
-		if (*sock != -1 && FD_ISSET(*sock, &inset))
-			accept_connection(*sock, true);
+		if (sock_pollfd) {
+			if (sock_pollfd->revents & ~POLLIN) {
+				barf_perror("sock poll failed");
+				break;
+			} else if (sock_pollfd->revents & POLLIN) {
+				accept_connection(*sock, true);
+				sock_pollfd = NULL;
+			}
+		}
 
-		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
-			accept_connection(*ro_sock, false);
+		if (ro_sock_pollfd) {
+			if (ro_sock_pollfd->revents & ~POLLIN) {
+				barf_perror("ro sock poll failed");
+				break;
+			} else if (ro_sock_pollfd->revents & POLLIN) {
+				accept_connection(*ro_sock, false);
+				ro_sock_pollfd = NULL;
+			}
+		}
 
-		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-			handle_event();
+		if (xce_pollfd) {
+			if (xce_pollfd->revents & ~POLLIN) {
+				barf_perror("xce_handle poll failed");
+				break;
+			} else if (xce_pollfd->revents & POLLIN) {
+				handle_event();
+				xce_pollfd = NULL;
+			}
+		}
 
 		next = list_entry(connections.next, typeof(*conn), list);
 		if (&next->list != &connections)
@@ -1939,21 +1990,27 @@ int main(int argc, char *argv[])
 				if (talloc_free(conn) == 0)
 					continue;
 			} else {
-				if (FD_ISSET(conn->fd, &inset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLIN))
 					handle_input(conn);
 				if (talloc_free(conn) == 0)
 					continue;
 
 				talloc_increase_ref_count(conn);
-				if (FD_ISSET(conn->fd, &outset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLOUT))
 					handle_output(conn);
 				if (talloc_free(conn) == 0)
 					continue;
+
+				conn->pollfd = NULL;
 			}
 		}
 
-		max = initialize_set(&inset, &outset, *sock, *ro_sock,
-				     &timeout);
+		initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+			       &timeout);
 	}
 }
 
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 492ca0d..f330a87 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -60,6 +60,8 @@ struct connection
 
 	/* The file descriptor we came in on. */
 	int fd;
+	/* The pollfd corresponding to fd. */
+	struct pollfd *pollfd;
 
 	/* Who am I? 0 for socket connections. */
 	unsigned int id;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 13:32:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2icp-00041w-Oh; Tue, 05 Feb 2013 13:31:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2ico-00041g-5e
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 13:31:50 +0000
Received: from [85.158.138.51:37978] by server-10.bemta-3.messagelabs.com id
	38/1E-10609-5C901115; Tue, 05 Feb 2013 13:31:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360071106!31107488!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2296 invoked from network); 5 Feb 2013 13:31:48 -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;
	5 Feb 2013 13:31:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6309585"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 13:31:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 08:31:46 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2icj-0002vT-Q4;
	Tue, 05 Feb 2013 13:31:45 +0000
Message-ID: <1360071105.7477.139.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 5 Feb 2013 13:31:45 +0000
In-Reply-To: <1360061930.17017.34.camel@zakaz.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
	<1360061930.17017.34.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 10:58 +0000, Ian Campbell wrote:
> On Tue, 2013-01-22 at 14:50 +0000, Wei Liu wrote:
> > > > > > +		    !(reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) &&
> > > > > 
> > > > > This represents an error case I think? Is there anything we can do about
> > > > > it? If this sort of error occurs and we do nothing will we end up just
> > > > > spinning because every subsequent poll will just return straight away?
> > > > > 
> > > > > 
> > > > 
> > > > Yes, this represents an error. This indicates the pipe used to trigger
> > > > reopen_log is broken. What's the motivation of reopening log file?
> > > 
> > > Rotation I should imagine.
> > > 
> > > >  I
> > > > have no idea about the use case. But simply ignoring this error instead
> > > > of crashing the process is better choice IMHO.
> > > 
> > > Agreed, but my concern was that the daemon would spin consuming 100%
> > > CPU, which is nearly as bad as crashing.
> > > 
> > > > The whole pollfd set is reinitialized for every loop. So it is also
> > > > possible that for the next loop it will success even previous poll
> > > > fails?
> > > 
> > > I suppose it depends on the reason it failed. I would expect most of
> > > them would be pretty final rather than temporary but I haven't looked at
> > > the pipe docs.
> > > 
> > 
> > We can reinitialize the pipe if error occurs, because this pipe is only
> > used within xenstored itself to notify log reload.
> 
> But if you get POLLPRI or POLLOUT you don't do this with the code as it
> currently stands (from the v2 patch):
> +                       if (reopen_log_pipe0_pollfd->revents & ~(POLLIN|POLLOUT|POLLPRI)) {
> +                               close(reopen_log_pipe[0]);
> +                               close(reopen_log_pipe[1]);
> +                               init_pipe(reopen_log_pipe);
> +                       } else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
> +                               char c;
> +                               if (read(reopen_log_pipe[0], &c, 1) != 1)
> +                                       barf_perror("read failed");
> +                               reopen_log();
> +                       }
> 
> So on POLLRDHUP or POLLERR etc you reopen the log, on POLLIN you act as
> expected but for POLLPRI and POLLOUT you don't do anything.
> 
> If these two events should never occur then you should include the in
> the error handling part of the above. If they can occur then you need to
> do something to handle them, otherwise they will just keep reoccuring on
> every iteration.
> 
> The same goes for the other instances of this pattern.
> 
> Ian.
> 

I think POLLPRI and POLLOUT should not occur in most cases, here is a
updated version of the patch. Tested on my testbox and it works.

-----8<----
>From 22a7b50b8b0be62aeae7c86242a27dac1ffdb929 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 21 Jan 2013 19:07:37 +0000
Subject: [PATCH] Switch to poll() in cxenstored's IO loop

Poll() can support more file descriptors than select(). We've done this for
xenconsoled, now do this for cxenstored as well.

The code is taken from xenconsoled and modified to adapt to cxenstored.

Updated:
* reopen pipe if polling on reopen_log_pipe fails.
* exit if polling on some critical fds fails.
* clean up POLL*.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/xenstore/xenstored_core.c |  171 ++++++++++++++++++++++++++-------------
 tools/xenstore/xenstored_core.h |    2 +
 2 files changed, 116 insertions(+), 57 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index bd44645..839e51d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,7 +19,7 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/select.h>
+#include <poll.h>
 #ifndef NO_SOCKETS
 #include <sys/socket.h>
 #include <sys/un.h>
@@ -55,6 +55,12 @@
 #include "hashtable.h"
 
 extern xc_evtchn *xce_handle; /* in xenstored_domain.c */
+static struct pollfd *xce_pollfd;
+static struct pollfd *fds;
+static unsigned int current_array_size;
+static unsigned int nr_fds;
+
+#define ROUNDUP(_x, _w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
 static bool verbose = false;
 LIST_HEAD(connections);
@@ -62,6 +68,7 @@ static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
+static struct pollfd *reopen_log_pipe0_pollfd;
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx = NULL;
 
@@ -199,7 +206,7 @@ void trace_destroy(const void *data, const char *type)
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
- * the select() in the main loop.
+ * the poll() in the main loop.
  */
 static void trigger_reopen_log(int signal __attribute__((unused)))
 {
@@ -279,15 +286,12 @@ static int destroy_conn(void *_conn)
 
 	/* Flush outgoing if possible, but don't block. */
 	if (!conn->domain) {
-		fd_set set;
-		struct timeval none;
-
-		FD_ZERO(&set);
-		FD_SET(conn->fd, &set);
-		none.tv_sec = none.tv_usec = 0;
+		struct pollfd pfd;
+		pfd.fd = conn->fd;
+		pfd.events = POLLOUT;
 
 		while (!list_empty(&conn->out_list)
-		       && select(conn->fd+1, NULL, &set, NULL, &none) == 1)
+		       && poll(&pfd, 1, 0) == 1)
 			if (!write_messages(conn))
 				break;
 		close(conn->fd);
@@ -300,52 +304,74 @@ static int destroy_conn(void *_conn)
 }
 
 
-static void set_fd(int fd, fd_set *set, int *max)
+static struct pollfd *set_fd(int fd, short events)
 {
-	if (fd < 0)
-		return;
-	FD_SET(fd, set);
-	if (fd > *max)
-		*max = fd;
-}
+	struct pollfd *ret;
+	if (current_array_size < nr_fds + 1) {
+		struct pollfd *new_fds = NULL;
+		unsigned long newsize;
+
+		/* Round up to 2^8 boundary, in practice this just
+		 * make newsize larger than current_array_size.
+		 */
+		newsize = ROUNDUP(nr_fds + 1, 8);
 
+		new_fds = realloc(fds, sizeof(struct pollfd)*newsize);
+		if (!new_fds)
+			goto fail;
+		fds = new_fds;
 
-static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
-			  struct timeval **ptimeout)
+		memset(&fds[0] + current_array_size, 0,
+		       sizeof(struct pollfd ) * (newsize-current_array_size));
+		current_array_size = newsize;
+	}
+
+	fds[nr_fds].fd = fd;
+	fds[nr_fds].events = events;
+	ret = &fds[nr_fds];
+	nr_fds++;
+
+	return ret;
+fail:
+	syslog(LOG_ERR, "realloc failed, ignoring fd %d\n", fd);
+	return NULL;
+}
+
+static void initialize_fds(int sock, struct pollfd **p_sock_pollfd,
+			   int ro_sock, struct pollfd **p_ro_sock_pollfd,
+			   int *ptimeout)
 {
-	static struct timeval zero_timeout = { 0 };
 	struct connection *conn;
-	int max = -1;
 
-	*ptimeout = NULL;
+	memset(fds, 0, sizeof(struct pollfd) * current_array_size);
+	nr_fds = 0;
 
-	FD_ZERO(inset);
-	FD_ZERO(outset);
+	*ptimeout = -1;
 
 	if (sock != -1)
-		set_fd(sock, inset, &max);
+		*p_sock_pollfd = set_fd(sock, POLLIN|POLLPRI);
 	if (ro_sock != -1)
-		set_fd(ro_sock, inset, &max);
+		*p_ro_sock_pollfd = set_fd(ro_sock, POLLIN|POLLPRI);
 	if (reopen_log_pipe[0] != -1)
-		set_fd(reopen_log_pipe[0], inset, &max);
+		reopen_log_pipe0_pollfd =
+			set_fd(reopen_log_pipe[0], POLLIN|POLLPRI);
 
 	if (xce_handle != NULL)
-		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
+		xce_pollfd = set_fd(xc_evtchn_fd(xce_handle), POLLIN|POLLPRI);
 
 	list_for_each_entry(conn, &connections, list) {
 		if (conn->domain) {
 			if (domain_can_read(conn) ||
 			    (domain_can_write(conn) &&
 			     !list_empty(&conn->out_list)))
-				*ptimeout = &zero_timeout;
+				*ptimeout = 0;
 		} else {
-			set_fd(conn->fd, inset, &max);
+			short events = POLLIN|POLLPRI;
 			if (!list_empty(&conn->out_list))
-				FD_SET(conn->fd, outset);
+				events |= POLLOUT;
+			conn->pollfd = set_fd(conn->fd, events);
 		}
 	}
-
-	return max;
 }
 
 /* Is child a subnode of parent, or equal? */
@@ -1770,14 +1796,13 @@ int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock, *ro_sock, max;
-	fd_set inset, outset;
+	int opt, *sock, *ro_sock;
+	struct pollfd *sock_pollfd = NULL, *ro_sock_pollfd = NULL;
 	bool dofork = true;
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
-	int evtchn_fd = -1;
-	struct timeval *timeout;
+	int timeout;
 
 	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
 				  NULL)) != -1) {
@@ -1880,11 +1905,9 @@ int main(int argc, char *argv[])
 
 	signal(SIGHUP, trigger_reopen_log);
 
-	if (xce_handle != NULL)
-		evtchn_fd = xc_evtchn_fd(xce_handle);
-
 	/* Get ready to listen to the tools. */
-	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
+	initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+		       &timeout);
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -1893,27 +1916,55 @@ int main(int argc, char *argv[])
 	for (;;) {
 		struct connection *conn, *next;
 
-		if (select(max+1, &inset, &outset, NULL, timeout) < 0) {
+		if (poll(fds, nr_fds, timeout) < 0) {
 			if (errno == EINTR)
 				continue;
-			barf_perror("Select failed");
+			barf_perror("Poll failed");
 		}
 
-		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
-			char c;
-			if (read(reopen_log_pipe[0], &c, 1) != 1)
-				barf_perror("read failed");
-			reopen_log();
+		if (reopen_log_pipe0_pollfd) {
+			if (reopen_log_pipe0_pollfd->revents & ~POLLIN) {
+				close(reopen_log_pipe[0]);
+				close(reopen_log_pipe[1]);
+				init_pipe(reopen_log_pipe);
+			} else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
+				char c;
+				if (read(reopen_log_pipe[0], &c, 1) != 1)
+					barf_perror("read failed");
+				reopen_log();
+			}
+			reopen_log_pipe0_pollfd = NULL;
 		}
 
-		if (*sock != -1 && FD_ISSET(*sock, &inset))
-			accept_connection(*sock, true);
+		if (sock_pollfd) {
+			if (sock_pollfd->revents & ~POLLIN) {
+				barf_perror("sock poll failed");
+				break;
+			} else if (sock_pollfd->revents & POLLIN) {
+				accept_connection(*sock, true);
+				sock_pollfd = NULL;
+			}
+		}
 
-		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
-			accept_connection(*ro_sock, false);
+		if (ro_sock_pollfd) {
+			if (ro_sock_pollfd->revents & ~POLLIN) {
+				barf_perror("ro sock poll failed");
+				break;
+			} else if (ro_sock_pollfd->revents & POLLIN) {
+				accept_connection(*ro_sock, false);
+				ro_sock_pollfd = NULL;
+			}
+		}
 
-		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-			handle_event();
+		if (xce_pollfd) {
+			if (xce_pollfd->revents & ~POLLIN) {
+				barf_perror("xce_handle poll failed");
+				break;
+			} else if (xce_pollfd->revents & POLLIN) {
+				handle_event();
+				xce_pollfd = NULL;
+			}
+		}
 
 		next = list_entry(connections.next, typeof(*conn), list);
 		if (&next->list != &connections)
@@ -1939,21 +1990,27 @@ int main(int argc, char *argv[])
 				if (talloc_free(conn) == 0)
 					continue;
 			} else {
-				if (FD_ISSET(conn->fd, &inset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLIN))
 					handle_input(conn);
 				if (talloc_free(conn) == 0)
 					continue;
 
 				talloc_increase_ref_count(conn);
-				if (FD_ISSET(conn->fd, &outset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLOUT))
 					handle_output(conn);
 				if (talloc_free(conn) == 0)
 					continue;
+
+				conn->pollfd = NULL;
 			}
 		}
 
-		max = initialize_set(&inset, &outset, *sock, *ro_sock,
-				     &timeout);
+		initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+			       &timeout);
 	}
 }
 
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 492ca0d..f330a87 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -60,6 +60,8 @@ struct connection
 
 	/* The file descriptor we came in on. */
 	int fd;
+	/* The pollfd corresponding to fd. */
+	struct pollfd *pollfd;
 
 	/* Who am I? 0 for socket connections. */
 	unsigned int id;
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 13:37:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2ihn-0004XT-Sb; Tue, 05 Feb 2013 13:36:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2ihl-0004XH-Rq
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 13:36:58 +0000
Received: from [85.158.143.35:10336] by server-3.bemta-4.messagelabs.com id
	3F/50-08920-9FA01115; Tue, 05 Feb 2013 13:36:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360071207!5633723!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25180 invoked from network); 5 Feb 2013 13:33:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 13:33:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1156977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 13:33: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.297.1; Tue, 5 Feb 2013
	13:33:27 +0000
Message-ID: <1360071206.17017.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 5 Feb 2013 13:33:26 +0000
In-Reply-To: <511106FD.4040600@tiscali.it>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
	<511106FD.4040600@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
 support for upstream-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

On Tue, 2013-02-05 at 13:19 +0000, Fabio Fantoni wrote:
> Il 05/02/2013 11:33, Ian Campbell ha scritto:
> > On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
> >> tools/libxl: Add qxl vga interface support for
> >>    upstream-qemu-xen.
> >>
> >> Usage:
> >>     qxl=1|0
> >>
> >> Changes from v7:
> >> - Fix videoram settings parameters for qemu.
> >>
> >> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> >> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> > Unfortunately this patch is whitespace damaged in various places.
> 
> I'll try from linux instead windows, I can also add patches as 
> attachment on next messages?

If sending from Linux doesn't work *then* lets try attachments.

> 
> >> ---
> >>    docs/man/xl.cfg.pod.5       |   11 +++++++++++
> >>    tools/libxl/libxl_create.c  |   12 ++++++++++++
> >>    tools/libxl/libxl_dm.c      |   15 +++++++++++++++
> >>    tools/libxl/libxl_types.idl |    1 +
> >>    tools/libxl/xl_cmdimpl.c    |    7 ++++++-
> >>    5 files changed, 45 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >> index 9c5cdcd..a0f0dc3 100644
> >> --- a/docs/man/xl.cfg.pod.5
> >> +++ b/docs/man/xl.cfg.pod.5
> >> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is
> >> sufficient
> >>    for 1024x768 at 32 bpp and videoram option is currently working
> >>    only when using the upstream qemu-xen device-model.
> >>
> >> +For B<qxl> vga, the default is both default and minimal 128MB.
> >> +If B<videoram> is set less than 128MB, an error will be triggered.
> >> +
> >>    =item B<stdvga=BOOLEAN>
> >>
> >>    Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> >> @@ -992,6 +995,14 @@ a Cirrus Logic GD5446 VGA card. If your guest
> >> supports VBE 2.0 or
> >>    later (e.g. Windows XP onwards) then you should enable this.
> >>    stdvga supports more video ram and bigger resolutions than Cirrus.
> >>
> >> +=item B<qxl=BOOLEAN>
> > What happens if I give qxl=1 and stdvga=1?
> >
> > Perhaps we should deprecate stdvga and add a new option:
> > 	vga = "stdvga|cirrus|qxl"
> > ?
> 
> Yes that should be nice.
> I'll do a patch that remove stdvga option and add vga option.

Please keep the stdvga as a (deprecated) synonym for vga=stdvga, so that
configuration files are forward compatible.

> >> +
> >> +        if (b_info->device_model_version ==
> >> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> >> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> >> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> >> +                b_info->video_memkb = (128 * 1024);
> >> +            }else if (b_info->video_memkb < (128 * 1024)) {
> >> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> >> +                    "128 Mib videoram is the minimum for qxl default");
> > You can use the LOG() macros to shorten this line (and in other places
> > including you videoram patch too).
> >
> > Should this error out on qemu == traditional and vga == QXL?
> 
> Must I only replace LIBXL__LOG with LOG?

LOG is just a convenience macro. 
	LIBXL__LOG(CTX, LIBXL__LOG_ERROR, ... )
becomes
	LOG(ERROR, ...)

> I'll add error and exit if vga=qxl and qemu is traditional.

Great. Remember that libxl can't exit(2), so it should return an error
which causes xl to exit.




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

From xen-devel-bounces@lists.xen.org Tue Feb 05 13:37:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 13: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 1U2ihn-0004XT-Sb; Tue, 05 Feb 2013 13:36:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2ihl-0004XH-Rq
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 13:36:58 +0000
Received: from [85.158.143.35:10336] by server-3.bemta-4.messagelabs.com id
	3F/50-08920-9FA01115; Tue, 05 Feb 2013 13:36:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360071207!5633723!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25180 invoked from network); 5 Feb 2013 13:33:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 13:33:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1156977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 13:33: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.297.1; Tue, 5 Feb 2013
	13:33:27 +0000
Message-ID: <1360071206.17017.78.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Tue, 5 Feb 2013 13:33:26 +0000
In-Reply-To: <511106FD.4040600@tiscali.it>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
	<511106FD.4040600@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8] tools/libxl: Add qxl vga interface
 support for upstream-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

On Tue, 2013-02-05 at 13:19 +0000, Fabio Fantoni wrote:
> Il 05/02/2013 11:33, Ian Campbell ha scritto:
> > On Mon, 2013-01-28 at 16:03 +0000, Fabio Fantoni wrote:
> >> tools/libxl: Add qxl vga interface support for
> >>    upstream-qemu-xen.
> >>
> >> Usage:
> >>     qxl=1|0
> >>
> >> Changes from v7:
> >> - Fix videoram settings parameters for qemu.
> >>
> >> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> >> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> > Unfortunately this patch is whitespace damaged in various places.
> 
> I'll try from linux instead windows, I can also add patches as 
> attachment on next messages?

If sending from Linux doesn't work *then* lets try attachments.

> 
> >> ---
> >>    docs/man/xl.cfg.pod.5       |   11 +++++++++++
> >>    tools/libxl/libxl_create.c  |   12 ++++++++++++
> >>    tools/libxl/libxl_dm.c      |   15 +++++++++++++++
> >>    tools/libxl/libxl_types.idl |    1 +
> >>    tools/libxl/xl_cmdimpl.c    |    7 ++++++-
> >>    5 files changed, 45 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >> index 9c5cdcd..a0f0dc3 100644
> >> --- a/docs/man/xl.cfg.pod.5
> >> +++ b/docs/man/xl.cfg.pod.5
> >> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is
> >> sufficient
> >>    for 1024x768 at 32 bpp and videoram option is currently working
> >>    only when using the upstream qemu-xen device-model.
> >>
> >> +For B<qxl> vga, the default is both default and minimal 128MB.
> >> +If B<videoram> is set less than 128MB, an error will be triggered.
> >> +
> >>    =item B<stdvga=BOOLEAN>
> >>
> >>    Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> >> @@ -992,6 +995,14 @@ a Cirrus Logic GD5446 VGA card. If your guest
> >> supports VBE 2.0 or
> >>    later (e.g. Windows XP onwards) then you should enable this.
> >>    stdvga supports more video ram and bigger resolutions than Cirrus.
> >>
> >> +=item B<qxl=BOOLEAN>
> > What happens if I give qxl=1 and stdvga=1?
> >
> > Perhaps we should deprecate stdvga and add a new option:
> > 	vga = "stdvga|cirrus|qxl"
> > ?
> 
> Yes that should be nice.
> I'll do a patch that remove stdvga option and add vga option.

Please keep the stdvga as a (deprecated) synonym for vga=stdvga, so that
configuration files are forward compatible.

> >> +
> >> +        if (b_info->device_model_version ==
> >> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> >> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> >> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> >> +                b_info->video_memkb = (128 * 1024);
> >> +            }else if (b_info->video_memkb < (128 * 1024)) {
> >> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> >> +                    "128 Mib videoram is the minimum for qxl default");
> > You can use the LOG() macros to shorten this line (and in other places
> > including you videoram patch too).
> >
> > Should this error out on qemu == traditional and vga == QXL?
> 
> Must I only replace LIBXL__LOG with LOG?

LOG is just a convenience macro. 
	LIBXL__LOG(CTX, LIBXL__LOG_ERROR, ... )
becomes
	LOG(ERROR, ...)

> I'll add error and exit if vga=qxl and qemu is traditional.

Great. Remember that libxl can't exit(2), so it should return an error
which causes xl to exit.




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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:08:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:08: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 1U2jBx-0005q5-U7; Tue, 05 Feb 2013 14:08:09 +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 1U2jBx-0005q0-0n
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:08:09 +0000
Received: from [85.158.138.51:55543] by server-11.bemta-3.messagelabs.com id
	C1/66-10249-84211115; Tue, 05 Feb 2013 14:08:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360073286!31114922!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16275 invoked from network); 5 Feb 2013 14:08:07 -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;
	5 Feb 2013 14:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6004869"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 14:08:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 09:08:05 -0500
Received: from zakaz.uk.xensource.com ([10.80.2.42])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U2jBt-0003RZ-62;
	Tue, 05 Feb 2013 14:08:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 14:08:04 +0000
Message-ID: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
	install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 appears to be needed when libraries are outside /lib and /usr/lib
(specifically when they are in /usr/local/lib)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-xen-install |    1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-xen-install b/ts-xen-install
index 5ee97af..cafc71a 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -45,6 +45,7 @@ sub extract () {
         target_extract_jobdistpath($ho, $part, "path_${part}dist",
 				   $r{"${part}buildjob"}, \%distpath);
     }
+    target_cmd_root($ho, '/sbin/ldconfig');
 }
 
 sub adjustconfig () {
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:08:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:08: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 1U2jBx-0005q5-U7; Tue, 05 Feb 2013 14:08:09 +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 1U2jBx-0005q0-0n
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:08:09 +0000
Received: from [85.158.138.51:55543] by server-11.bemta-3.messagelabs.com id
	C1/66-10249-84211115; Tue, 05 Feb 2013 14:08:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360073286!31114922!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16275 invoked from network); 5 Feb 2013 14:08:07 -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;
	5 Feb 2013 14:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6004869"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 14:08:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 09:08:05 -0500
Received: from zakaz.uk.xensource.com ([10.80.2.42])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U2jBt-0003RZ-62;
	Tue, 05 Feb 2013 14:08:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 14:08:04 +0000
Message-ID: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
	install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 appears to be needed when libraries are outside /lib and /usr/lib
(specifically when they are in /usr/local/lib)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 ts-xen-install |    1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-xen-install b/ts-xen-install
index 5ee97af..cafc71a 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -45,6 +45,7 @@ sub extract () {
         target_extract_jobdistpath($ho, $part, "path_${part}dist",
 				   $r{"${part}buildjob"}, \%distpath);
     }
+    target_cmd_root($ho, '/sbin/ldconfig');
 }
 
 sub adjustconfig () {
-- 
1.7.10.4


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:10:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:10: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 1U2jEF-0005wT-G4; Tue, 05 Feb 2013 14:10:31 +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 1U2jEE-0005wL-9y
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:10:30 +0000
Received: from [85.158.138.51:18339] by server-1.bemta-3.messagelabs.com id
	4F/7B-08955-5D211115; Tue, 05 Feb 2013 14:10:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360073427!22969446!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11581 invoked from network); 5 Feb 2013 14:10:28 -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; 5 Feb 2013 14:10:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 14:10:27 +0000
Message-Id: <511120E102000078000BC1AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 14:10:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFBCBB6C1.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/scsiback/usbback: move
 cond_resched() invocations to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartFBCBB6C1.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The call to cond_resched() must be inside the loop, in order to not
expose the host to guest induced soft lockups (due to a close to
unbounded loop).

Also rate limit printk()-s in those loops as well as in blktap's.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blktap/common.h
+++ b/drivers/xen/blktap/common.h
@@ -41,7 +41,9 @@
 #define DPRINTK(_f, _a...) pr_debug("(file=3D%s, line=3D%d) " _f, \
                                     __FILE__ , __LINE__ , ## _a )
=20
-#define WPRINTK(fmt, args...) printk(KERN_WARNING "blk_tap: " fmt, =
##args)
+#define WPRINTK(fmt, args...) \
+	((void)(printk_ratelimit() && \
+		printk(KERN_WARNING "blktap: " fmt, ##args)))
=20
 struct backend_info;
=20
--- a/drivers/xen/scsiback/scsiback.c
+++ b/drivers/xen/scsiback/scsiback.c
@@ -603,40 +603,36 @@ static int _scsiback_do_cmd_fn(struct vs
=20
 		err =3D prepare_pending_reqs(info, ring_req,
 						pending_req);
-		if (err =3D=3D -EINVAL) {
-			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),
-				0, pending_req);
-			continue;
-		} else if (err =3D=3D -ENODEV) {
-			scsiback_do_resp_with_sense(NULL, (DID_NO_CONNECT =
<< 16),
-				0, pending_req);
-			continue;
-		}
-
-		if (pending_req->act =3D=3D VSCSIIF_ACT_SCSI_CDB) {
-
+		switch (err ?: pending_req->act) {
+		case VSCSIIF_ACT_SCSI_CDB:
 			/* The Host mode is through as for Emulation. */
 			if (info->feature =3D=3D VSCSI_TYPE_HOST)
 				scsiback_cmd_exec(pending_req);
 			else
 				scsiback_req_emulation_or_cmdexec(pending_r=
eq);
-
-		} else if (pending_req->act =3D=3D VSCSIIF_ACT_SCSI_RESET) =
{
+			break;
+		case VSCSIIF_ACT_SCSI_RESET:
 			scsiback_device_reset_exec(pending_req);
-		} else {
-			printk(KERN_ERR "scsiback: invalid parameter for =
request\n");
-			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),
-				0, pending_req);
-			continue;
+			break;
+		default:
+			if(!err && printk_ratelimit())
+				printk(KERN_ERR "scsiback: invalid =
request\n");
+			scsiback_do_resp_with_sense(NULL, DRIVER_ERROR << =
24,
+						    0, pending_req);
+			break;
+		case -ENODEV:
+			scsiback_do_resp_with_sense(NULL, DID_NO_CONNECT =
<< 16,
+						    0, pending_req);
+			break;
 		}
+
+		/* Yield point for this unbounded loop. */
+		cond_resched();
 	}
=20
 	if (RING_HAS_UNCONSUMED_REQUESTS(ring))
 		more_to_do =3D 1;
=20
-	/* Yield point for this unbounded loop. */
-	cond_resched();
-
 	return more_to_do;
 }
=20
--- a/drivers/xen/usbback/usbback.c
+++ b/drivers/xen/usbback/usbback.c
@@ -981,7 +981,9 @@ static int usbbk_start_submit_urb(usbif_
=20
 	while (rc !=3D rp) {
 		if (RING_REQUEST_CONS_OVERFLOW(urb_ring, rc)) {
-			printk(KERN_WARNING "RING_REQUEST_CONS_OVERFLOW\n")=
;
+			if(printk_ratelimit())
+				printk(KERN_WARNING "usbback: "
+				       "RING_REQUEST_CONS_OVERFLOW\n");
 			break;
 		}
=20
@@ -996,12 +998,12 @@ static int usbbk_start_submit_urb(usbif_
=20
 		dispatch_request_to_pending_reqs(usbif, req,
 							pending_req);
+
+		cond_resched();
 	}
=20
 	RING_FINAL_CHECK_FOR_REQUESTS(&usbif->urb_ring, more_to_do);
=20
-	cond_resched();
-
 	return more_to_do;
 }
=20




--=__PartFBCBB6C1.0__=
Content-Type: text/plain; name="xen-backends-cond-resched.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-backends-cond-resched.patch"

scsiback/usbback: move cond_resched() invocations to proper place=0A=0AThe =
call to cond_resched() must be inside the loop, in order to not=0Aexpose =
the host to guest induced soft lockups (due to a close to=0Aunbounded =
loop).=0A=0AAlso rate limit printk()-s in those loops as well as in =
blktap's.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/blktap/common.h=0A+++ b/drivers/xen/blktap/common.h=0A@@ =
-41,7 +41,9 @@=0A #define DPRINTK(_f, _a...) pr_debug("(file=3D%s, =
line=3D%d) " _f, \=0A                                     __FILE__ , =
__LINE__ , ## _a )=0A =0A-#define WPRINTK(fmt, args...) printk(KERN_WARNING=
 "blk_tap: " fmt, ##args)=0A+#define WPRINTK(fmt, args...) \=0A+	=
((void)(printk_ratelimit() && \=0A+		printk(KERN_WARNING =
"blktap: " fmt, ##args)))=0A =0A struct backend_info;=0A =0A--- a/drivers/x=
en/scsiback/scsiback.c=0A+++ b/drivers/xen/scsiback/scsiback.c=0A@@ =
-603,40 +603,36 @@ static int _scsiback_do_cmd_fn(struct vs=0A =0A 		=
err =3D prepare_pending_reqs(info, ring_req,=0A 				=
		pending_req);=0A-		if (err =3D=3D -EINVAL) =
{=0A-			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),=0A-				0, pending_req);=0A-			=
continue;=0A-		} else if (err =3D=3D -ENODEV) {=0A-			=
scsiback_do_resp_with_sense(NULL, (DID_NO_CONNECT << 16),=0A-			=
	0, pending_req);=0A-			continue;=0A-		=
}=0A-=0A-		if (pending_req->act =3D=3D VSCSIIF_ACT_SCSI_CDB) =
{=0A-=0A+		switch (err ?: pending_req->act) {=0A+		=
case VSCSIIF_ACT_SCSI_CDB:=0A 			/* The Host mode is =
through as for Emulation. */=0A 			if (info->feature =
=3D=3D VSCSI_TYPE_HOST)=0A 				scsiback_cmd_exec(p=
ending_req);=0A 			else=0A 				=
scsiback_req_emulation_or_cmdexec(pending_req);=0A-=0A-		} else if =
(pending_req->act =3D=3D VSCSIIF_ACT_SCSI_RESET) {=0A+			=
break;=0A+		case VSCSIIF_ACT_SCSI_RESET:=0A 			=
scsiback_device_reset_exec(pending_req);=0A-		} else {=0A-		=
	printk(KERN_ERR "scsiback: invalid parameter for request\n");=0A-	=
		scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),=0A-				0, pending_req);=0A-			=
continue;=0A+			break;=0A+		default:=0A+		=
	if(!err && printk_ratelimit())=0A+				=
printk(KERN_ERR "scsiback: invalid request\n");=0A+			=
scsiback_do_resp_with_sense(NULL, DRIVER_ERROR << 24,=0A+			=
			    0, pending_req);=0A+			=
break;=0A+		case -ENODEV:=0A+			scsiback_do=
_resp_with_sense(NULL, DID_NO_CONNECT << 16,=0A+				=
		    0, pending_req);=0A+			break;=0A 	=
	}=0A+=0A+		/* Yield point for this unbounded loop. =
*/=0A+		cond_resched();=0A 	}=0A =0A 	if (RING_HAS_UNCONS=
UMED_REQUESTS(ring))=0A 		more_to_do =3D 1;=0A =0A-	/* =
Yield point for this unbounded loop. */=0A-	cond_resched();=0A-=0A 	=
return more_to_do;=0A }=0A =0A--- a/drivers/xen/usbback/usbback.c=0A+++ =
b/drivers/xen/usbback/usbback.c=0A@@ -981,7 +981,9 @@ static int usbbk_star=
t_submit_urb(usbif_=0A =0A 	while (rc !=3D rp) {=0A 		if =
(RING_REQUEST_CONS_OVERFLOW(urb_ring, rc)) {=0A-			=
printk(KERN_WARNING "RING_REQUEST_CONS_OVERFLOW\n");=0A+			=
if(printk_ratelimit())=0A+				printk(KERN_WARNING=
 "usbback: "=0A+				       "RING_REQUEST_CONS_O=
VERFLOW\n");=0A 			break;=0A 		}=0A =0A@@ =
-996,12 +998,12 @@ static int usbbk_start_submit_urb(usbif_=0A =0A 		=
dispatch_request_to_pending_reqs(usbif, req,=0A 				=
			pending_req);=0A+=0A+		cond_resched();=0A =
	}=0A =0A 	RING_FINAL_CHECK_FOR_REQUESTS(&usbif->urb_ring, =
more_to_do);=0A =0A-	cond_resched();=0A-=0A 	return more_to_do;=0A }=0A =
=0A
--=__PartFBCBB6C1.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

--=__PartFBCBB6C1.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 05 14:10:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:10: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 1U2jEF-0005wT-G4; Tue, 05 Feb 2013 14:10:31 +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 1U2jEE-0005wL-9y
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:10:30 +0000
Received: from [85.158.138.51:18339] by server-1.bemta-3.messagelabs.com id
	4F/7B-08955-5D211115; Tue, 05 Feb 2013 14:10:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360073427!22969446!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11581 invoked from network); 5 Feb 2013 14:10:28 -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; 5 Feb 2013 14:10:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 05 Feb 2013 14:10:27 +0000
Message-Id: <511120E102000078000BC1AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 05 Feb 2013 14:10:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFBCBB6C1.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/scsiback/usbback: move
 cond_resched() invocations to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartFBCBB6C1.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The call to cond_resched() must be inside the loop, in order to not
expose the host to guest induced soft lockups (due to a close to
unbounded loop).

Also rate limit printk()-s in those loops as well as in blktap's.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blktap/common.h
+++ b/drivers/xen/blktap/common.h
@@ -41,7 +41,9 @@
 #define DPRINTK(_f, _a...) pr_debug("(file=3D%s, line=3D%d) " _f, \
                                     __FILE__ , __LINE__ , ## _a )
=20
-#define WPRINTK(fmt, args...) printk(KERN_WARNING "blk_tap: " fmt, =
##args)
+#define WPRINTK(fmt, args...) \
+	((void)(printk_ratelimit() && \
+		printk(KERN_WARNING "blktap: " fmt, ##args)))
=20
 struct backend_info;
=20
--- a/drivers/xen/scsiback/scsiback.c
+++ b/drivers/xen/scsiback/scsiback.c
@@ -603,40 +603,36 @@ static int _scsiback_do_cmd_fn(struct vs
=20
 		err =3D prepare_pending_reqs(info, ring_req,
 						pending_req);
-		if (err =3D=3D -EINVAL) {
-			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),
-				0, pending_req);
-			continue;
-		} else if (err =3D=3D -ENODEV) {
-			scsiback_do_resp_with_sense(NULL, (DID_NO_CONNECT =
<< 16),
-				0, pending_req);
-			continue;
-		}
-
-		if (pending_req->act =3D=3D VSCSIIF_ACT_SCSI_CDB) {
-
+		switch (err ?: pending_req->act) {
+		case VSCSIIF_ACT_SCSI_CDB:
 			/* The Host mode is through as for Emulation. */
 			if (info->feature =3D=3D VSCSI_TYPE_HOST)
 				scsiback_cmd_exec(pending_req);
 			else
 				scsiback_req_emulation_or_cmdexec(pending_r=
eq);
-
-		} else if (pending_req->act =3D=3D VSCSIIF_ACT_SCSI_RESET) =
{
+			break;
+		case VSCSIIF_ACT_SCSI_RESET:
 			scsiback_device_reset_exec(pending_req);
-		} else {
-			printk(KERN_ERR "scsiback: invalid parameter for =
request\n");
-			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),
-				0, pending_req);
-			continue;
+			break;
+		default:
+			if(!err && printk_ratelimit())
+				printk(KERN_ERR "scsiback: invalid =
request\n");
+			scsiback_do_resp_with_sense(NULL, DRIVER_ERROR << =
24,
+						    0, pending_req);
+			break;
+		case -ENODEV:
+			scsiback_do_resp_with_sense(NULL, DID_NO_CONNECT =
<< 16,
+						    0, pending_req);
+			break;
 		}
+
+		/* Yield point for this unbounded loop. */
+		cond_resched();
 	}
=20
 	if (RING_HAS_UNCONSUMED_REQUESTS(ring))
 		more_to_do =3D 1;
=20
-	/* Yield point for this unbounded loop. */
-	cond_resched();
-
 	return more_to_do;
 }
=20
--- a/drivers/xen/usbback/usbback.c
+++ b/drivers/xen/usbback/usbback.c
@@ -981,7 +981,9 @@ static int usbbk_start_submit_urb(usbif_
=20
 	while (rc !=3D rp) {
 		if (RING_REQUEST_CONS_OVERFLOW(urb_ring, rc)) {
-			printk(KERN_WARNING "RING_REQUEST_CONS_OVERFLOW\n")=
;
+			if(printk_ratelimit())
+				printk(KERN_WARNING "usbback: "
+				       "RING_REQUEST_CONS_OVERFLOW\n");
 			break;
 		}
=20
@@ -996,12 +998,12 @@ static int usbbk_start_submit_urb(usbif_
=20
 		dispatch_request_to_pending_reqs(usbif, req,
 							pending_req);
+
+		cond_resched();
 	}
=20
 	RING_FINAL_CHECK_FOR_REQUESTS(&usbif->urb_ring, more_to_do);
=20
-	cond_resched();
-
 	return more_to_do;
 }
=20




--=__PartFBCBB6C1.0__=
Content-Type: text/plain; name="xen-backends-cond-resched.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-backends-cond-resched.patch"

scsiback/usbback: move cond_resched() invocations to proper place=0A=0AThe =
call to cond_resched() must be inside the loop, in order to not=0Aexpose =
the host to guest induced soft lockups (due to a close to=0Aunbounded =
loop).=0A=0AAlso rate limit printk()-s in those loops as well as in =
blktap's.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/blktap/common.h=0A+++ b/drivers/xen/blktap/common.h=0A@@ =
-41,7 +41,9 @@=0A #define DPRINTK(_f, _a...) pr_debug("(file=3D%s, =
line=3D%d) " _f, \=0A                                     __FILE__ , =
__LINE__ , ## _a )=0A =0A-#define WPRINTK(fmt, args...) printk(KERN_WARNING=
 "blk_tap: " fmt, ##args)=0A+#define WPRINTK(fmt, args...) \=0A+	=
((void)(printk_ratelimit() && \=0A+		printk(KERN_WARNING =
"blktap: " fmt, ##args)))=0A =0A struct backend_info;=0A =0A--- a/drivers/x=
en/scsiback/scsiback.c=0A+++ b/drivers/xen/scsiback/scsiback.c=0A@@ =
-603,40 +603,36 @@ static int _scsiback_do_cmd_fn(struct vs=0A =0A 		=
err =3D prepare_pending_reqs(info, ring_req,=0A 				=
		pending_req);=0A-		if (err =3D=3D -EINVAL) =
{=0A-			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),=0A-				0, pending_req);=0A-			=
continue;=0A-		} else if (err =3D=3D -ENODEV) {=0A-			=
scsiback_do_resp_with_sense(NULL, (DID_NO_CONNECT << 16),=0A-			=
	0, pending_req);=0A-			continue;=0A-		=
}=0A-=0A-		if (pending_req->act =3D=3D VSCSIIF_ACT_SCSI_CDB) =
{=0A-=0A+		switch (err ?: pending_req->act) {=0A+		=
case VSCSIIF_ACT_SCSI_CDB:=0A 			/* The Host mode is =
through as for Emulation. */=0A 			if (info->feature =
=3D=3D VSCSI_TYPE_HOST)=0A 				scsiback_cmd_exec(p=
ending_req);=0A 			else=0A 				=
scsiback_req_emulation_or_cmdexec(pending_req);=0A-=0A-		} else if =
(pending_req->act =3D=3D VSCSIIF_ACT_SCSI_RESET) {=0A+			=
break;=0A+		case VSCSIIF_ACT_SCSI_RESET:=0A 			=
scsiback_device_reset_exec(pending_req);=0A-		} else {=0A-		=
	printk(KERN_ERR "scsiback: invalid parameter for request\n");=0A-	=
		scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << =
24),=0A-				0, pending_req);=0A-			=
continue;=0A+			break;=0A+		default:=0A+		=
	if(!err && printk_ratelimit())=0A+				=
printk(KERN_ERR "scsiback: invalid request\n");=0A+			=
scsiback_do_resp_with_sense(NULL, DRIVER_ERROR << 24,=0A+			=
			    0, pending_req);=0A+			=
break;=0A+		case -ENODEV:=0A+			scsiback_do=
_resp_with_sense(NULL, DID_NO_CONNECT << 16,=0A+				=
		    0, pending_req);=0A+			break;=0A 	=
	}=0A+=0A+		/* Yield point for this unbounded loop. =
*/=0A+		cond_resched();=0A 	}=0A =0A 	if (RING_HAS_UNCONS=
UMED_REQUESTS(ring))=0A 		more_to_do =3D 1;=0A =0A-	/* =
Yield point for this unbounded loop. */=0A-	cond_resched();=0A-=0A 	=
return more_to_do;=0A }=0A =0A--- a/drivers/xen/usbback/usbback.c=0A+++ =
b/drivers/xen/usbback/usbback.c=0A@@ -981,7 +981,9 @@ static int usbbk_star=
t_submit_urb(usbif_=0A =0A 	while (rc !=3D rp) {=0A 		if =
(RING_REQUEST_CONS_OVERFLOW(urb_ring, rc)) {=0A-			=
printk(KERN_WARNING "RING_REQUEST_CONS_OVERFLOW\n");=0A+			=
if(printk_ratelimit())=0A+				printk(KERN_WARNING=
 "usbback: "=0A+				       "RING_REQUEST_CONS_O=
VERFLOW\n");=0A 			break;=0A 		}=0A =0A@@ =
-996,12 +998,12 @@ static int usbbk_start_submit_urb(usbif_=0A =0A 		=
dispatch_request_to_pending_reqs(usbif, req,=0A 				=
			pending_req);=0A+=0A+		cond_resched();=0A =
	}=0A =0A 	RING_FINAL_CHECK_FOR_REQUESTS(&usbif->urb_ring, =
more_to_do);=0A =0A-	cond_resched();=0A-=0A 	return more_to_do;=0A }=0A =
=0A
--=__PartFBCBB6C1.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

--=__PartFBCBB6C1.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 05 14:16:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:16: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 1U2jK7-0006D2-Eh; Tue, 05 Feb 2013 14:16: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 1U2jK6-0006Ct-Cs
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:16:34 +0000
Received: from [85.158.137.99:35899] by server-6.bemta-3.messagelabs.com id
	47/34-29959-14411115; Tue, 05 Feb 2013 14:16:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360073791!16911694!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31294 invoked from network); 5 Feb 2013 14:16:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 14:16:31 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (joses mo13) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y03d1cp15DhYtu ;
	Tue, 5 Feb 2013 15:16:31 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id A9C291884C; Tue,  5 Feb 2013 15:16:30 +0100 (CET)
Date: Tue, 5 Feb 2013 15:16:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130205141630.GA11093@aepfle.de>
References: <256d59b2bc8a41387655.1359648303@probook.site>
	<1360062439.17017.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360062439.17017.39.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: pass debug flag down to
 libxl_domain_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 Tue, Feb 05, Ian Campbell wrote:

> On Thu, 2013-01-31 at 16:05 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1359648298 -3600
> > # Node ID 256d59b2bc8a413876559dc8daf4c52ba46677de
> > # Parent  12455da211d4e841692b2374086356a87eb74ff7
> > libxl: pass debug flag down to libxl_domain_suspend
> > 
> > libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> > and xl migrate handles the -d switch as well. Pass this flag down to
> > libxl_domain_suspend, so that finally xc_domain_save can dump huge
> > amount of debug data to stdout.
> > Update xl.5 and help text output.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > diff -r 12455da211d4 -r 256d59b2bc8a docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1
> > +++ b/docs/man/xl.pod.1
> > @@ -387,6 +387,10 @@ domain. See the corresponding option of 
> >  
> >  Send <config> instead of config file from creation.
> >  
> > +=item B<-e>
> 
> You mean -d here.
> 
> I wonder if we should make this option a bit more obscure (e.g. a long
> option only) ? Or tie it to verbose > 5 or something?

I'm not sure how to create a long only option. But if it has to be
specified two or three times to really enable it, that would be ok for
me. Will send v3 of this change shortly.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:16:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:16: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 1U2jK7-0006D2-Eh; Tue, 05 Feb 2013 14:16: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 1U2jK6-0006Ct-Cs
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:16:34 +0000
Received: from [85.158.137.99:35899] by server-6.bemta-3.messagelabs.com id
	47/34-29959-14411115; Tue, 05 Feb 2013 14:16:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360073791!16911694!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODIzMTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31294 invoked from network); 5 Feb 2013 14:16:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 14:16:31 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (joses mo13) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y03d1cp15DhYtu ;
	Tue, 5 Feb 2013 15:16:31 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id A9C291884C; Tue,  5 Feb 2013 15:16:30 +0100 (CET)
Date: Tue, 5 Feb 2013 15:16:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130205141630.GA11093@aepfle.de>
References: <256d59b2bc8a41387655.1359648303@probook.site>
	<1360062439.17017.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360062439.17017.39.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: pass debug flag down to
 libxl_domain_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 Tue, Feb 05, Ian Campbell wrote:

> On Thu, 2013-01-31 at 16:05 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1359648298 -3600
> > # Node ID 256d59b2bc8a413876559dc8daf4c52ba46677de
> > # Parent  12455da211d4e841692b2374086356a87eb74ff7
> > libxl: pass debug flag down to libxl_domain_suspend
> > 
> > libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> > and xl migrate handles the -d switch as well. Pass this flag down to
> > libxl_domain_suspend, so that finally xc_domain_save can dump huge
> > amount of debug data to stdout.
> > Update xl.5 and help text output.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > diff -r 12455da211d4 -r 256d59b2bc8a docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1
> > +++ b/docs/man/xl.pod.1
> > @@ -387,6 +387,10 @@ domain. See the corresponding option of 
> >  
> >  Send <config> instead of config file from creation.
> >  
> > +=item B<-e>
> 
> You mean -d here.
> 
> I wonder if we should make this option a bit more obscure (e.g. a long
> option only) ? Or tie it to verbose > 5 or something?

I'm not sure how to create a long only option. But if it has to be
specified two or three times to really enable it, that would be ok for
me. Will send v3 of this change shortly.

Olaf

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:21:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:21: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 1U2jOS-0006NA-5f; Tue, 05 Feb 2013 14:21:04 +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 1U2jOQ-0006N5-NO
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:21:02 +0000
Received: from [193.109.254.147:19069] by server-8.bemta-14.messagelabs.com id
	2D/84-17325-D4511115; Tue, 05 Feb 2013 14:21:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360074057!3368442!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzc2NTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzc2NTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21850 invoked from network); 5 Feb 2013 14:20:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 14:20:58 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (jorabe mo47) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K07c20p15Ddimj
	for <xen-devel@lists.xen.org>; Tue, 5 Feb 2013 15:20:57 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 30DB91863D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:20:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e2b8970eb702b5151a81c9c5fbbf2e2da7836fd6
Message-Id: <e2b8970eb702b5151a81.1360074056@probook.site>
In-Reply-To: <256d59b2bc8a41387655.1359648303@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Tue, 05 Feb 2013 15:20:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] libxl: pass debug flag down to
	libxl_domain_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360073994 -3600
# Node ID e2b8970eb702b5151a81c9c5fbbf2e2da7836fd6
# Parent  9ce7648327cdbcd7a24052d6f0e85378627988db
libxl: pass debug flag down to libxl_domain_suspend

libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
and xl migrate handles the -d switch as well. Pass this flag down to
libxl_domain_suspend, so that finally xc_domain_save can dump huge
amount of debug data to stdout.
Update xl.1 and help text output.

v3:
 - require 3 -d options to really enable it

v2:
 - fix xl.1 option, really use -d instead of -e

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9ce7648327cd -r e2b8970eb702 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -387,6 +387,11 @@ domain. See the corresponding option of 
 
 Send <config> instead of config file from creation.
 
+=item B<-d>
+
+Print huge (!) amount of debug during the migration process.
+This option has to be specfied three times to really enable it.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r 9ce7648327cd -r e2b8970eb702 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3331,7 +3331,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune, int debug,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3340,7 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len;
+    int config_len, flags = LIBXL_SUSPEND_LIVE;
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3358,7 +3358,9 @@ static void migrate_domain(uint32_t domi
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
+    if (debug)
+        flags |= LIBXL_SUSPEND_DEBUG;
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3767,7 +3769,7 @@ int main_migrate(int argc, char **argv)
         monitor = 0;
         break;
     case 'd':
-        debug = 1;
+        debug++;
         break;
     }
 
@@ -3784,7 +3786,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, config_filename);
+    migrate_domain(domid, rune, debug >= 3, config_filename);
     return 0;
 }
 
diff -r 9ce7648327cd -r e2b8970eb702 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
       "                to sh. If empty, run <host> instead of ssh <host> xl\n"
       "                migrate-receive [-d -e]\n"
       "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain."
+      "                of the domain.\n"
+      "-d -d -d        Print huge (!) amount of debug during the migration process."
     },
     { "dump-core",
       &main_dump_core, 0, 1,

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:21:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:21: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 1U2jOS-0006NA-5f; Tue, 05 Feb 2013 14:21:04 +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 1U2jOQ-0006N5-NO
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:21:02 +0000
Received: from [193.109.254.147:19069] by server-8.bemta-14.messagelabs.com id
	2D/84-17325-D4511115; Tue, 05 Feb 2013 14:21:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360074057!3368442!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzc2NTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzc2NTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21850 invoked from network); 5 Feb 2013 14:20:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 14:20:58 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (jorabe mo47) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K07c20p15Ddimj
	for <xen-devel@lists.xen.org>; Tue, 5 Feb 2013 15:20:57 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 30DB91863D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 15:20:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e2b8970eb702b5151a81c9c5fbbf2e2da7836fd6
Message-Id: <e2b8970eb702b5151a81.1360074056@probook.site>
In-Reply-To: <256d59b2bc8a41387655.1359648303@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Tue, 05 Feb 2013 15:20:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] libxl: pass debug flag down to
	libxl_domain_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360073994 -3600
# Node ID e2b8970eb702b5151a81c9c5fbbf2e2da7836fd6
# Parent  9ce7648327cdbcd7a24052d6f0e85378627988db
libxl: pass debug flag down to libxl_domain_suspend

libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
and xl migrate handles the -d switch as well. Pass this flag down to
libxl_domain_suspend, so that finally xc_domain_save can dump huge
amount of debug data to stdout.
Update xl.1 and help text output.

v3:
 - require 3 -d options to really enable it

v2:
 - fix xl.1 option, really use -d instead of -e

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9ce7648327cd -r e2b8970eb702 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -387,6 +387,11 @@ domain. See the corresponding option of 
 
 Send <config> instead of config file from creation.
 
+=item B<-d>
+
+Print huge (!) amount of debug during the migration process.
+This option has to be specfied three times to really enable it.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r 9ce7648327cd -r e2b8970eb702 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3331,7 +3331,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune, int debug,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3340,7 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len;
+    int config_len, flags = LIBXL_SUSPEND_LIVE;
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3358,7 +3358,9 @@ static void migrate_domain(uint32_t domi
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
+    if (debug)
+        flags |= LIBXL_SUSPEND_DEBUG;
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3767,7 +3769,7 @@ int main_migrate(int argc, char **argv)
         monitor = 0;
         break;
     case 'd':
-        debug = 1;
+        debug++;
         break;
     }
 
@@ -3784,7 +3786,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, config_filename);
+    migrate_domain(domid, rune, debug >= 3, config_filename);
     return 0;
 }
 
diff -r 9ce7648327cd -r e2b8970eb702 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
       "                to sh. If empty, run <host> instead of ssh <host> xl\n"
       "                migrate-receive [-d -e]\n"
       "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain."
+      "                of the domain.\n"
+      "-d -d -d        Print huge (!) amount of debug during the migration process."
     },
     { "dump-core",
       &main_dump_core, 0, 1,

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:27:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:27: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 1U2jUk-0006lz-1F; Tue, 05 Feb 2013 14:27: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 1U2jUi-0006lr-3X
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:27:32 +0000
Received: from [85.158.137.99:14664] by server-15.bemta-3.messagelabs.com id
	0B/10-25405-3D611115; Tue, 05 Feb 2013 14:27:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360074450!11881448!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31169 invoked from network); 5 Feb 2013 14:27:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 14:27:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1159444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 14:27: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.297.1; Tue, 5 Feb 2013
	14:27:29 +0000
Message-ID: <1360074448.17017.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 14:27:28 +0000
In-Reply-To: <20130205141630.GA11093@aepfle.de>
References: <256d59b2bc8a41387655.1359648303@probook.site>
	<1360062439.17017.39.camel@zakaz.uk.xensource.com>
	<20130205141630.GA11093@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: pass debug flag down to
 libxl_domain_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 Tue, 2013-02-05 at 14:16 +0000, Olaf Hering wrote:
> On Tue, Feb 05, Ian Campbell wrote:
> 
> > On Thu, 2013-01-31 at 16:05 +0000, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1359648298 -3600
> > > # Node ID 256d59b2bc8a413876559dc8daf4c52ba46677de
> > > # Parent  12455da211d4e841692b2374086356a87eb74ff7
> > > libxl: pass debug flag down to libxl_domain_suspend
> > > 
> > > libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> > > and xl migrate handles the -d switch as well. Pass this flag down to
> > > libxl_domain_suspend, so that finally xc_domain_save can dump huge
> > > amount of debug data to stdout.
> > > Update xl.5 and help text output.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > 
> > > diff -r 12455da211d4 -r 256d59b2bc8a docs/man/xl.pod.1
> > > --- a/docs/man/xl.pod.1
> > > +++ b/docs/man/xl.pod.1
> > > @@ -387,6 +387,10 @@ domain. See the corresponding option of 
> > >  
> > >  Send <config> instead of config file from creation.
> > >  
> > > +=item B<-e>
> > 
> > You mean -d here.
> > 
> > I wonder if we should make this option a bit more obscure (e.g. a long
> > option only) ? Or tie it to verbose > 5 or something?
> 
> I'm not sure how to create a long only option.

I've not tried it but I think where normally for -c/--cpus you would
have:
	{"cpus", 0, 0, 'c'},
	...
	case 'c': ...

You can also have non-char keys in the last field (val) e.g.
	{"foo", 0, 0, 0x100},
	...
	case 0x100: ...

(0x100 because that's not an ascii character so no clash).

>  But if it has to be
> specified two or three times to really enable it, that would be ok for
> me. Will send v3 of this change shortly.

I was trying to avoid swallowing one of the lower case letters (which
are finite) for a rarely used debug option, rather than worrying about
people enabling it by mistake, so -d -d -d doesn't really 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 Feb 05 14:27:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:27: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 1U2jUk-0006lz-1F; Tue, 05 Feb 2013 14:27: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 1U2jUi-0006lr-3X
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:27:32 +0000
Received: from [85.158.137.99:14664] by server-15.bemta-3.messagelabs.com id
	0B/10-25405-3D611115; Tue, 05 Feb 2013 14:27:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360074450!11881448!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31169 invoked from network); 5 Feb 2013 14:27:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 14:27:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1159444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 14:27: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.297.1; Tue, 5 Feb 2013
	14:27:29 +0000
Message-ID: <1360074448.17017.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 5 Feb 2013 14:27:28 +0000
In-Reply-To: <20130205141630.GA11093@aepfle.de>
References: <256d59b2bc8a41387655.1359648303@probook.site>
	<1360062439.17017.39.camel@zakaz.uk.xensource.com>
	<20130205141630.GA11093@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: pass debug flag down to
 libxl_domain_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 Tue, 2013-02-05 at 14:16 +0000, Olaf Hering wrote:
> On Tue, Feb 05, Ian Campbell wrote:
> 
> > On Thu, 2013-01-31 at 16:05 +0000, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1359648298 -3600
> > > # Node ID 256d59b2bc8a413876559dc8daf4c52ba46677de
> > > # Parent  12455da211d4e841692b2374086356a87eb74ff7
> > > libxl: pass debug flag down to libxl_domain_suspend
> > > 
> > > libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
> > > and xl migrate handles the -d switch as well. Pass this flag down to
> > > libxl_domain_suspend, so that finally xc_domain_save can dump huge
> > > amount of debug data to stdout.
> > > Update xl.5 and help text output.
> > > 
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > > 
> > > diff -r 12455da211d4 -r 256d59b2bc8a docs/man/xl.pod.1
> > > --- a/docs/man/xl.pod.1
> > > +++ b/docs/man/xl.pod.1
> > > @@ -387,6 +387,10 @@ domain. See the corresponding option of 
> > >  
> > >  Send <config> instead of config file from creation.
> > >  
> > > +=item B<-e>
> > 
> > You mean -d here.
> > 
> > I wonder if we should make this option a bit more obscure (e.g. a long
> > option only) ? Or tie it to verbose > 5 or something?
> 
> I'm not sure how to create a long only option.

I've not tried it but I think where normally for -c/--cpus you would
have:
	{"cpus", 0, 0, 'c'},
	...
	case 'c': ...

You can also have non-char keys in the last field (val) e.g.
	{"foo", 0, 0, 0x100},
	...
	case 0x100: ...

(0x100 because that's not an ascii character so no clash).

>  But if it has to be
> specified two or three times to really enable it, that would be ok for
> me. Will send v3 of this change shortly.

I was trying to avoid swallowing one of the lower case letters (which
are finite) for a rarely used debug option, rather than worrying about
people enabling it by mistake, so -d -d -d doesn't really 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 Feb 05 14:49:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:49: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 1U2jpJ-0007UC-Hc; Tue, 05 Feb 2013 14: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 1U2jpI-0007U5-L0
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:48:48 +0000
Received: from [85.158.138.51:47721] by server-6.bemta-3.messagelabs.com id
	76/F9-29959-FCB11115; Tue, 05 Feb 2013 14:48:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360075724!27721592!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10341 invoked from network); 5 Feb 2013 14:48:45 -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;
	5 Feb 2013 14:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6011066"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 14:48:43 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	09:48:43 -0500
Message-ID: <51111BCA.3010207@citrix.com>
Date: Tue, 5 Feb 2013 14:48:42 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CD35C394.4B677%keir.xen@gmail.com>
In-Reply-To: <CD35C394.4B677%keir.xen@gmail.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 19:59, Keir Fraser wrote:
> On 04/02/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
>> Hi,
>>
>> Here is a design for a scalable event channel ABI for Xen.  It has a
>> number of benefits over the design currently being proposed by Wei Lui.
>>
>> * More event channels (>100,000).
>> * 16 event priorities.
>> * Reduced memory requirements (only 1 additional page per domU).
>> * The use of FIFOs for events ensures fairness, whereas it is difficult
>> to reason about the fairness with the current bitmap system.
> 
> I have some sympathy for this design. It's primary downside compared with
> the 3-level alternative is its greater space cost (32*#vcpus). However, as
> you say the fairness and prioritisation features are rather nice. Also
> having the data structures be per vcpu may well help avoid cacheline
> contention on busy multi-vcpu guests.

This design originally (before I posted it) did have per-VCPU event
arrays but I changed it to per-domain to reduce the memory footprint.

A hybrid approach might be useful.  Busy guests like dom0 or driver
domains could use per-VCPU event arrays but other guests could be
per-domain.  This would be controlled by the toolstack.

> Interested in what others think, but I may actually prefer a ground-up
> redesign like this.

Since the ABI needs to be changed to support more event channels anyway,
it seems an ideal point to revisit the design.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 14:49:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 14:49: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 1U2jpJ-0007UC-Hc; Tue, 05 Feb 2013 14: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 1U2jpI-0007U5-L0
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 14:48:48 +0000
Received: from [85.158.138.51:47721] by server-6.bemta-3.messagelabs.com id
	76/F9-29959-FCB11115; Tue, 05 Feb 2013 14:48:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360075724!27721592!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10341 invoked from network); 5 Feb 2013 14:48:45 -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;
	5 Feb 2013 14:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6011066"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 14:48:43 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	09:48:43 -0500
Message-ID: <51111BCA.3010207@citrix.com>
Date: Tue, 5 Feb 2013 14:48:42 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CD35C394.4B677%keir.xen@gmail.com>
In-Reply-To: <CD35C394.4B677%keir.xen@gmail.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 19:59, Keir Fraser wrote:
> On 04/02/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
>> Hi,
>>
>> Here is a design for a scalable event channel ABI for Xen.  It has a
>> number of benefits over the design currently being proposed by Wei Lui.
>>
>> * More event channels (>100,000).
>> * 16 event priorities.
>> * Reduced memory requirements (only 1 additional page per domU).
>> * The use of FIFOs for events ensures fairness, whereas it is difficult
>> to reason about the fairness with the current bitmap system.
> 
> I have some sympathy for this design. It's primary downside compared with
> the 3-level alternative is its greater space cost (32*#vcpus). However, as
> you say the fairness and prioritisation features are rather nice. Also
> having the data structures be per vcpu may well help avoid cacheline
> contention on busy multi-vcpu guests.

This design originally (before I posted it) did have per-VCPU event
arrays but I changed it to per-domain to reduce the memory footprint.

A hybrid approach might be useful.  Busy guests like dom0 or driver
domains could use per-VCPU event arrays but other guests could be
per-domain.  This would be controlled by the toolstack.

> Interested in what others think, but I may actually prefer a ground-up
> redesign like this.

Since the ABI needs to be changed to support more event channels anyway,
it seems an ideal point to revisit the design.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2kCZ-00008V-FN; Tue, 05 Feb 2013 15:12:51 +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 1U2kCX-00008I-Rj
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:12:50 +0000
Received: from [85.158.143.35:36804] by server-1.bemta-4.messagelabs.com id
	B8/DA-08839-17121115; Tue, 05 Feb 2013 15:12:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360076990!15998364!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19496 invoked from network); 5 Feb 2013 15:09:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 15:09:51 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (joses mo15) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U03d5cp15ETZSe
	for <xen-devel@lists.xen.org>; Tue, 5 Feb 2013 16:09:50 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 319311863D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 16:09:50 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d3caef1468f2b538de42d8998d49879f2b132ae1
Message-Id: <d3caef1468f2b538de42.1360076989@probook.site>
In-Reply-To: <256d59b2bc8a41387655.1359648303@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Tue, 05 Feb 2013 16:09:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v4] libxl: pass debug flag down to
	libxl_domain_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360076904 -3600
# Node ID d3caef1468f2b538de42d8998d49879f2b132ae1
# Parent  9ce7648327cdbcd7a24052d6f0e85378627988db
libxl: pass debug flag down to libxl_domain_suspend

libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
and xl migrate handles the -d switch as well. Pass this flag down to
libxl_domain_suspend, so that finally xc_domain_save can dump huge
amount of debug data to stdout.
Update xl.1 and help text output.

v4:
 - change -d to --debug

v3:
 - require 3 -d options to really enable it

v2:
 - fix xl.1 option, really use -d instead of -e

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9ce7648327cd -r d3caef1468f2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -387,6 +387,10 @@ domain. See the corresponding option of 
 
 Send <config> instead of config file from creation.
 
+=item B<--debug>
+
+Print huge (!) amount of debug during the migration process.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r 9ce7648327cd -r d3caef1468f2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3331,7 +3331,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune, int debug,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3340,7 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len;
+    int config_len, flags = LIBXL_SUSPEND_LIVE;
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3358,7 +3358,9 @@ static void migrate_domain(uint32_t domi
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
+    if (debug)
+        flags |= LIBXL_SUSPEND_DEBUG;
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3751,8 +3753,13 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    static struct option opts[] = {
+        {"debug", 0, 0, 0x100},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:e", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3766,7 +3773,7 @@ int main_migrate(int argc, char **argv)
         daemonize = 0;
         monitor = 0;
         break;
-    case 'd':
+    case 0x100:
         debug = 1;
         break;
     }
@@ -3784,7 +3791,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, config_filename);
+    migrate_domain(domid, rune, debug, config_filename);
     return 0;
 }
 
diff -r 9ce7648327cd -r d3caef1468f2 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
       "                to sh. If empty, run <host> instead of ssh <host> xl\n"
       "                migrate-receive [-d -e]\n"
       "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain."
+      "                of the domain.\n"
+      "--debug         Print huge (!) amount of debug during the migration process."
     },
     { "dump-core",
       &main_dump_core, 0, 1,

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2kCZ-00008V-FN; Tue, 05 Feb 2013 15:12:51 +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 1U2kCX-00008I-Rj
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:12:50 +0000
Received: from [85.158.143.35:36804] by server-1.bemta-4.messagelabs.com id
	B8/DA-08839-17121115; Tue, 05 Feb 2013 15:12:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360076990!15998364!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NTQyNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19496 invoked from network); 5 Feb 2013 15:09:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 15:09:51 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PEqKa
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-114.pools.arcor-ip.net [88.65.94.114])
	by smtp.strato.de (joses mo15) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U03d5cp15ETZSe
	for <xen-devel@lists.xen.org>; Tue, 5 Feb 2013 16:09:50 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 319311863D
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 16:09:50 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d3caef1468f2b538de42d8998d49879f2b132ae1
Message-Id: <d3caef1468f2b538de42.1360076989@probook.site>
In-Reply-To: <256d59b2bc8a41387655.1359648303@probook.site>
References: <256d59b2bc8a41387655.1359648303@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Tue, 05 Feb 2013 16:09:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v4] libxl: pass debug flag down to
	libxl_domain_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360076904 -3600
# Node ID d3caef1468f2b538de42d8998d49879f2b132ae1
# Parent  9ce7648327cdbcd7a24052d6f0e85378627988db
libxl: pass debug flag down to libxl_domain_suspend

libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
and xl migrate handles the -d switch as well. Pass this flag down to
libxl_domain_suspend, so that finally xc_domain_save can dump huge
amount of debug data to stdout.
Update xl.1 and help text output.

v4:
 - change -d to --debug

v3:
 - require 3 -d options to really enable it

v2:
 - fix xl.1 option, really use -d instead of -e

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9ce7648327cd -r d3caef1468f2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -387,6 +387,10 @@ domain. See the corresponding option of 
 
 Send <config> instead of config file from creation.
 
+=item B<--debug>
+
+Print huge (!) amount of debug during the migration process.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r 9ce7648327cd -r d3caef1468f2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3331,7 +3331,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune, int debug,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3340,7 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len;
+    int config_len, flags = LIBXL_SUSPEND_LIVE;
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3358,7 +3358,9 @@ static void migrate_domain(uint32_t domi
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
+    if (debug)
+        flags |= LIBXL_SUSPEND_DEBUG;
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3751,8 +3753,13 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    static struct option opts[] = {
+        {"debug", 0, 0, 0x100},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:e", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3766,7 +3773,7 @@ int main_migrate(int argc, char **argv)
         daemonize = 0;
         monitor = 0;
         break;
-    case 'd':
+    case 0x100:
         debug = 1;
         break;
     }
@@ -3784,7 +3791,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, config_filename);
+    migrate_domain(domid, rune, debug, config_filename);
     return 0;
 }
 
diff -r 9ce7648327cd -r d3caef1468f2 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
       "                to sh. If empty, run <host> instead of ssh <host> xl\n"
       "                migrate-receive [-d -e]\n"
       "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain."
+      "                of the domain.\n"
+      "--debug         Print huge (!) amount of debug during the migration process."
     },
     { "dump-core",
       &main_dump_core, 0, 1,

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:17:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:17: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 1U2kGL-0000YC-7L; Tue, 05 Feb 2013 15:16:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2kGK-0000Y2-6V
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:16:44 +0000
Received: from [85.158.138.51:53019] by server-13.bemta-3.messagelabs.com id
	8C/74-20653-B5221115; Tue, 05 Feb 2013 15:16:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360077400!20849787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24917 invoked from network); 5 Feb 2013 15:16:42 -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 Feb 2013 15:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6015811"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 15:16:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 10:16:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2kGF-0004X3-NE;
	Tue, 05 Feb 2013 15:16:39 +0000
Message-ID: <1360077399.7477.148.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 15:16:39 +0000
In-Reply-To: <51111BCA.3010207@citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 14:48 +0000, David Vrabel wrote:
> On 04/02/13 19:59, Keir Fraser wrote:
> > On 04/02/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:
> > 
> >> Hi,
> >>
> >> Here is a design for a scalable event channel ABI for Xen.  It has a
> >> number of benefits over the design currently being proposed by Wei Lui.
> >>
> >> * More event channels (>100,000).
> >> * 16 event priorities.
> >> * Reduced memory requirements (only 1 additional page per domU).
> >> * The use of FIFOs for events ensures fairness, whereas it is difficult
> >> to reason about the fairness with the current bitmap system.
> > 
> > I have some sympathy for this design. It's primary downside compared with
> > the 3-level alternative is its greater space cost (32*#vcpus). However, as
> > you say the fairness and prioritisation features are rather nice. Also
> > having the data structures be per vcpu may well help avoid cacheline
> > contention on busy multi-vcpu guests.
> 
> This design originally (before I posted it) did have per-VCPU event
> arrays but I changed it to per-domain to reduce the memory footprint.
> 
> A hybrid approach might be useful.  Busy guests like dom0 or driver
> domains could use per-VCPU event arrays but other guests could be
> per-domain.  This would be controlled by the toolstack.
> 
> > Interested in what others think, but I may actually prefer a ground-up
> > redesign like this.
> 
> Since the ABI needs to be changed to support more event channels anyway,
> it seems an ideal point to revisit the design.
> 

Right. I do care about better design and good implementation. Can we
build a prototype of this design? We are less than two months away from
4.3 feature freeze, and the event channel scalability is planned for
that release, which means we need to be hurried. :-)


Wei.

> David



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:17:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:17: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 1U2kGL-0000YC-7L; Tue, 05 Feb 2013 15:16:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2kGK-0000Y2-6V
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:16:44 +0000
Received: from [85.158.138.51:53019] by server-13.bemta-3.messagelabs.com id
	8C/74-20653-B5221115; Tue, 05 Feb 2013 15:16:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360077400!20849787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24917 invoked from network); 5 Feb 2013 15:16:42 -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 Feb 2013 15:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6015811"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 15:16:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 10:16:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2kGF-0004X3-NE;
	Tue, 05 Feb 2013 15:16:39 +0000
Message-ID: <1360077399.7477.148.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 15:16:39 +0000
In-Reply-To: <51111BCA.3010207@citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 14:48 +0000, David Vrabel wrote:
> On 04/02/13 19:59, Keir Fraser wrote:
> > On 04/02/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:
> > 
> >> Hi,
> >>
> >> Here is a design for a scalable event channel ABI for Xen.  It has a
> >> number of benefits over the design currently being proposed by Wei Lui.
> >>
> >> * More event channels (>100,000).
> >> * 16 event priorities.
> >> * Reduced memory requirements (only 1 additional page per domU).
> >> * The use of FIFOs for events ensures fairness, whereas it is difficult
> >> to reason about the fairness with the current bitmap system.
> > 
> > I have some sympathy for this design. It's primary downside compared with
> > the 3-level alternative is its greater space cost (32*#vcpus). However, as
> > you say the fairness and prioritisation features are rather nice. Also
> > having the data structures be per vcpu may well help avoid cacheline
> > contention on busy multi-vcpu guests.
> 
> This design originally (before I posted it) did have per-VCPU event
> arrays but I changed it to per-domain to reduce the memory footprint.
> 
> A hybrid approach might be useful.  Busy guests like dom0 or driver
> domains could use per-VCPU event arrays but other guests could be
> per-domain.  This would be controlled by the toolstack.
> 
> > Interested in what others think, but I may actually prefer a ground-up
> > redesign like this.
> 
> Since the ABI needs to be changed to support more event channels anyway,
> it seems an ideal point to revisit the design.
> 

Right. I do care about better design and good implementation. Can we
build a prototype of this design? We are less than two months away from
4.3 feature freeze, and the event channel scalability is planned for
that release, which means we need to be hurried. :-)


Wei.

> David



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:21:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2kKi-0000mO-0U; Tue, 05 Feb 2013 15:21: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 1U2kKg-0000mH-KI
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:21:14 +0000
Received: from [85.158.137.99:47678] by server-11.bemta-3.messagelabs.com id
	F5/AF-10249-96321115; Tue, 05 Feb 2013 15:21:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360077669!11892468!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30386 invoked from network); 5 Feb 2013 15:21:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:21:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1161631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 15:21: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.297.1; Tue, 5 Feb 2013 15:21:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2kKa-0007e0-Nh; Tue, 05 Feb 2013 15:21:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2kKa-0005ZH-JG;
	Tue, 05 Feb 2013 15:21:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20753.9060.362855.705987@mariner.uk.xensource.com>
Date: Tue, 5 Feb 2013 15:21:08 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1359629784.12252.287.camel@zakaz.uk.xensource.com>
References: <1359629191-9352-1-git-send-email-ian.campbell@citrix.com>
	<20130131105229.GM12821@type.bordeaux.inria.fr>
	<1359629784.12252.287.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: enable stubdom on a per arch basis
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: enable stubdom on a per arch basis"):
> Subject: [PATCH] xen: enable stubdom on a per arch basis
> 
> ... and disable on ARM (for now).

I haven't followed all the new logic in subsystem.m4 in detail but on
the basis that the worst outcome is a build failure,

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 Feb 05 15:21:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2kKi-0000mO-0U; Tue, 05 Feb 2013 15:21: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 1U2kKg-0000mH-KI
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:21:14 +0000
Received: from [85.158.137.99:47678] by server-11.bemta-3.messagelabs.com id
	F5/AF-10249-96321115; Tue, 05 Feb 2013 15:21:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360077669!11892468!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30386 invoked from network); 5 Feb 2013 15:21:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:21:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1161631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 15:21: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.297.1; Tue, 5 Feb 2013 15:21:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2kKa-0007e0-Nh; Tue, 05 Feb 2013 15:21:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2kKa-0005ZH-JG;
	Tue, 05 Feb 2013 15:21:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20753.9060.362855.705987@mariner.uk.xensource.com>
Date: Tue, 5 Feb 2013 15:21:08 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1359629784.12252.287.camel@zakaz.uk.xensource.com>
References: <1359629191-9352-1-git-send-email-ian.campbell@citrix.com>
	<20130131105229.GM12821@type.bordeaux.inria.fr>
	<1359629784.12252.287.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: enable stubdom on a per arch basis
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: enable stubdom on a per arch basis"):
> Subject: [PATCH] xen: enable stubdom on a per arch basis
> 
> ... and disable on ARM (for now).

I haven't followed all the new logic in subsystem.m4 in detail but on
the basis that the worst outcome is a build failure,

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 Feb 05 15:35:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2kXj-0001Pk-AL; Tue, 05 Feb 2013 15:34:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2kXh-0001PX-N7
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:34:41 +0000
Received: from [193.109.254.147:61120] by server-9.bemta-14.messagelabs.com id
	A7/A2-30867-09621115; Tue, 05 Feb 2013 15:34:40 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360078463!1802149!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10668 invoked from network); 5 Feb 2013 15:34:23 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-11.tower-27.messagelabs.com with SMTP;
	5 Feb 2013 15:34:23 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 465DFC5619B;
	Tue,  5 Feb 2013 15:34:12 +0000 (GMT)
Date: Tue, 05 Feb 2013 15:34:11 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>,
	xen-devel@lists.xen.org
Message-ID: <0D93B800F1D08E79CA73A748@nimrod.local>
In-Reply-To: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
References: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 4 February 2013 14:32:46 -0300 Fernando Luiz Chaves Xavier Matos 
<fernando@supergg.com.br> wrote:

> QCOW2 disk image gets corrupted when you try to install Service Pack 1
> AFTER installing GPLPV drivers.
>
> This means, without the pv drivers, everything works fine.
>
> I tested both RAW and QCOW2 without GPLPV drivers and the installation
> has completed without any error, and the image (at least qcow2) has no
> errors too.

What device is your qcow2 file held on?

I'd be interested to know whether turning O_DIRECT off fixes things.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:35:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2kXj-0001Pk-AL; Tue, 05 Feb 2013 15:34:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2kXh-0001PX-N7
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:34:41 +0000
Received: from [193.109.254.147:61120] by server-9.bemta-14.messagelabs.com id
	A7/A2-30867-09621115; Tue, 05 Feb 2013 15:34:40 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360078463!1802149!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10668 invoked from network); 5 Feb 2013 15:34:23 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-11.tower-27.messagelabs.com with SMTP;
	5 Feb 2013 15:34:23 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 465DFC5619B;
	Tue,  5 Feb 2013 15:34:12 +0000 (GMT)
Date: Tue, 05 Feb 2013 15:34:11 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Fernando Luiz Chaves Xavier Matos <fernando@supergg.com.br>,
	xen-devel@lists.xen.org
Message-ID: <0D93B800F1D08E79CA73A748@nimrod.local>
In-Reply-To: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
References: <CALBvGgQriCw3CgVcbenMsesRkvP0VmQ0W9W126TAb2TZEg_RLQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] QCOW2 goes corrupted when using GPLPV drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 4 February 2013 14:32:46 -0300 Fernando Luiz Chaves Xavier Matos 
<fernando@supergg.com.br> wrote:

> QCOW2 disk image gets corrupted when you try to install Service Pack 1
> AFTER installing GPLPV drivers.
>
> This means, without the pv drivers, everything works fine.
>
> I tested both RAW and QCOW2 without GPLPV drivers and the installation
> has completed without any error, and the image (at least qcow2) has no
> errors too.

What device is your qcow2 file held on?

I'd be interested to know whether turning O_DIRECT off fixes things.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:38:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:38: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 1U2kbF-0001iv-C4; Tue, 05 Feb 2013 15:38:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2kbE-0001io-Ga
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:38:20 +0000
Received: from [85.158.143.35:42669] by server-3.bemta-4.messagelabs.com id
	66/61-08920-B6721115; Tue, 05 Feb 2013 15:38:19 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360078675!13895380!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26827 invoked from network); 5 Feb 2013 15:37:55 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-21.messagelabs.com with SMTP;
	5 Feb 2013 15:37:55 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 89933C5619A;
	Tue,  5 Feb 2013 15:37:44 +0000 (GMT)
Date: Tue, 05 Feb 2013 15:37:43 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>, xen-devel@lists.xen.org
Message-ID: <05E85F0F99EB21013A48E1E6@nimrod.local>
In-Reply-To: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] blkback disk I/O limit patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 31 January 2013 09:12:28 +0400 Vasiliy Tolstov <v.tolstov@selfip.ru> 
wrote:

> Hello. For own needs i'm write simple blkback disk i/o limit patch,
> that can limit disk i/o based on iops. I need xen based iops shaper
> because of own storage architecture.

Another approach (when using the qemu-upstream DM) would presumably
be to use the block_io_throttle QMP command that QEMU provides.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:38:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:38: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 1U2kbF-0001iv-C4; Tue, 05 Feb 2013 15:38:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2kbE-0001io-Ga
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:38:20 +0000
Received: from [85.158.143.35:42669] by server-3.bemta-4.messagelabs.com id
	66/61-08920-B6721115; Tue, 05 Feb 2013 15:38:19 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360078675!13895380!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26827 invoked from network); 5 Feb 2013 15:37:55 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-21.messagelabs.com with SMTP;
	5 Feb 2013 15:37:55 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 89933C5619A;
	Tue,  5 Feb 2013 15:37:44 +0000 (GMT)
Date: Tue, 05 Feb 2013 15:37:43 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>, xen-devel@lists.xen.org
Message-ID: <05E85F0F99EB21013A48E1E6@nimrod.local>
In-Reply-To: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] blkback disk I/O limit patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 31 January 2013 09:12:28 +0400 Vasiliy Tolstov <v.tolstov@selfip.ru> 
wrote:

> Hello. For own needs i'm write simple blkback disk i/o limit patch,
> that can limit disk i/o based on iops. I need xen based iops shaper
> because of own storage architecture.

Another approach (when using the qemu-upstream DM) would presumably
be to use the block_io_throttle QMP command that QEMU provides.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:41:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:41: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 1U2kdf-0001rA-2k; Tue, 05 Feb 2013 15:40:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2kdd-0001r1-1t
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:40:49 +0000
Received: from [85.158.143.35:53637] by server-1.bemta-4.messagelabs.com id
	66/52-08839-00821115; Tue, 05 Feb 2013 15:40:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360078846!13089570!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26711 invoked from network); 5 Feb 2013 15:40:46 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-21.messagelabs.com with SMTP;
	5 Feb 2013 15:40:46 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 94683C56197;
	Tue,  5 Feb 2013 15:40:34 +0000 (GMT)
Date: Tue, 05 Feb 2013 15:40:33 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Message-ID: <656C0D5981D3A8BFB9993B2E@nimrod.local>
In-Reply-To: <850CD247D67BBF77A4CF0417@nimrod.local>
References: <5B4525F296F6ABEB38B0E614@nimrod.local> 
	<50CEFDA602000078000B0B11@nat28.tlf.novell.com> 
	<3B1D0701EAEA6532CEA91EA0@Ximines.local> 
	<alpine.DEB.2.02.1301161302020.4978@kaball.uk.xensource.com> 
	<F1DF150F7B2469CFD587A2A4@Ximines.local> 
	<alpine.DEB.2.02.1301161620390.4978@kaball.uk.xensource.com> 
	<E57EC0AFE2B6901CB9A11068@Ximines.local> 
	<alpine.DEB.2.02.1301161718120.4978@kaball.uk.xensource.com> 
	<77822E2DDAEA8F94631B6A52@Ximines.local> 
	<1358781790.3279.224.camel@zakaz.uk.xensource.com> 
	<F7F59FF70A5F8648886565B5@Ximines.local> 
	<1358783420.3279.235.camel@zakaz.uk.xensource.com> 
	<F7775BEAD1475FBBDEB2B9C4@Ximines.local>
	<19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Konrad / Stefano,

Any movement / ideas on this one?

Alex

--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:

> Konrad,
>
> --On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>
>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>> index a402ac8..1c3a6f5 100644
>>> --- a/hw/xen_disk.c
>>> +++ b/hw/xen_disk.c
>>> @@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
>>>      }
>>>
>>>      /* read-only ? */
>>> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
>>> +    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
>>> BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
>>>          qflags |= BDRV_O_RDWR;
>>>      } else {
>>
>> Before going for something like that I would like a confirmation from
>> Konrad about blkfront behavior regarding barriers and
>> BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
>> corruptions.
>
> Any ideas?
>
>
> A slightly prettier patch would look like the one pasted
> below (not sent with git-sendemail so beware whitespace issues).
>
> --
> Alex Bligh
>
> commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> Author: Alex Bligh <alex@alex.org.uk>
> Date:   Thu Jan 24 09:41:34 2013 +0000
>
>     Disable use of O_DIRECT by default as it results in crashes.
>
>     See:
>       http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
>     for more details.
>
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index a402ac8..a618d8d 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -45,6 +45,8 @@ static int batch_maps   = 0;
>
>  static int max_requests = 32;
>
> +static int use_o_direct = 0;
> +
>  /* ------------------------------------------------------------- */
>
>  #define BLOCK_SIZE  512
> @@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
>      }
>
>      /* read-only ? */
> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> +    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> BDRV_O_NATIVE_AIO;
>      if (strcmp(blkdev->mode, "w") == 0) {
>          qflags |= BDRV_O_RDWR;
>      } else {
>
>
>



-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:41:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:41: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 1U2kdf-0001rA-2k; Tue, 05 Feb 2013 15:40:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2kdd-0001r1-1t
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:40:49 +0000
Received: from [85.158.143.35:53637] by server-1.bemta-4.messagelabs.com id
	66/52-08839-00821115; Tue, 05 Feb 2013 15:40:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360078846!13089570!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26711 invoked from network); 5 Feb 2013 15:40:46 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-21.messagelabs.com with SMTP;
	5 Feb 2013 15:40:46 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 94683C56197;
	Tue,  5 Feb 2013 15:40:34 +0000 (GMT)
Date: Tue, 05 Feb 2013 15:40:33 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Message-ID: <656C0D5981D3A8BFB9993B2E@nimrod.local>
In-Reply-To: <850CD247D67BBF77A4CF0417@nimrod.local>
References: <5B4525F296F6ABEB38B0E614@nimrod.local> 
	<50CEFDA602000078000B0B11@nat28.tlf.novell.com> 
	<3B1D0701EAEA6532CEA91EA0@Ximines.local> 
	<alpine.DEB.2.02.1301161302020.4978@kaball.uk.xensource.com> 
	<F1DF150F7B2469CFD587A2A4@Ximines.local> 
	<alpine.DEB.2.02.1301161620390.4978@kaball.uk.xensource.com> 
	<E57EC0AFE2B6901CB9A11068@Ximines.local> 
	<alpine.DEB.2.02.1301161718120.4978@kaball.uk.xensource.com> 
	<77822E2DDAEA8F94631B6A52@Ximines.local> 
	<1358781790.3279.224.camel@zakaz.uk.xensource.com> 
	<F7F59FF70A5F8648886565B5@Ximines.local> 
	<1358783420.3279.235.camel@zakaz.uk.xensource.com> 
	<F7775BEAD1475FBBDEB2B9C4@Ximines.local>
	<19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Konrad / Stefano,

Any movement / ideas on this one?

Alex

--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:

> Konrad,
>
> --On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>
>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>> index a402ac8..1c3a6f5 100644
>>> --- a/hw/xen_disk.c
>>> +++ b/hw/xen_disk.c
>>> @@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
>>>      }
>>>
>>>      /* read-only ? */
>>> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
>>> +    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
>>> BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
>>>          qflags |= BDRV_O_RDWR;
>>>      } else {
>>
>> Before going for something like that I would like a confirmation from
>> Konrad about blkfront behavior regarding barriers and
>> BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
>> corruptions.
>
> Any ideas?
>
>
> A slightly prettier patch would look like the one pasted
> below (not sent with git-sendemail so beware whitespace issues).
>
> --
> Alex Bligh
>
> commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> Author: Alex Bligh <alex@alex.org.uk>
> Date:   Thu Jan 24 09:41:34 2013 +0000
>
>     Disable use of O_DIRECT by default as it results in crashes.
>
>     See:
>       http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
>     for more details.
>
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index a402ac8..a618d8d 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -45,6 +45,8 @@ static int batch_maps   = 0;
>
>  static int max_requests = 32;
>
> +static int use_o_direct = 0;
> +
>  /* ------------------------------------------------------------- */
>
>  #define BLOCK_SIZE  512
> @@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
>      }
>
>      /* read-only ? */
> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> +    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> BDRV_O_NATIVE_AIO;
>      if (strcmp(blkdev->mode, "w") == 0) {
>          qflags |= BDRV_O_RDWR;
>      } else {
>
>
>



-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:49:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2klK-0002EK-5g; Tue, 05 Feb 2013 15:48:46 +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 1U2klI-0002EF-Q5
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:48:44 +0000
Received: from [85.158.137.99:7771] by server-10.bemta-3.messagelabs.com id
	4B/77-10609-7D921115; Tue, 05 Feb 2013 15:48:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360079316!14704477!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18681 invoked from network); 5 Feb 2013 15:48:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1162808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 15:48: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.297.1; Tue, 5 Feb 2013
	15:48:36 +0000
Message-ID: <1360079314.23001.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:48:34 +0000
In-Reply-To: <20753.9060.362855.705987@mariner.uk.xensource.com>
References: <1359629191-9352-1-git-send-email-ian.campbell@citrix.com>
	<20130131105229.GM12821@type.bordeaux.inria.fr>
	<1359629784.12252.287.camel@zakaz.uk.xensource.com>
	<20753.9060.362855.705987@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Roger
	Pau Monne <roger.pau@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: enable stubdom on a per arch basis
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 15:21 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] xen: enable stubdom on a per arch basis"):
> > Subject: [PATCH] xen: enable stubdom on a per arch basis
> > 
> > ... and disable on ARM (for now).
> 
> I haven't followed all the new logic in subsystem.m4 in detail but on
> the basis that the worst outcome is a build failure,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:49:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2klK-0002EK-5g; Tue, 05 Feb 2013 15:48:46 +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 1U2klI-0002EF-Q5
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:48:44 +0000
Received: from [85.158.137.99:7771] by server-10.bemta-3.messagelabs.com id
	4B/77-10609-7D921115; Tue, 05 Feb 2013 15:48:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360079316!14704477!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18681 invoked from network); 5 Feb 2013 15:48:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="1162808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 15:48: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.297.1; Tue, 5 Feb 2013
	15:48:36 +0000
Message-ID: <1360079314.23001.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:48:34 +0000
In-Reply-To: <20753.9060.362855.705987@mariner.uk.xensource.com>
References: <1359629191-9352-1-git-send-email-ian.campbell@citrix.com>
	<20130131105229.GM12821@type.bordeaux.inria.fr>
	<1359629784.12252.287.camel@zakaz.uk.xensource.com>
	<20753.9060.362855.705987@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Roger
	Pau Monne <roger.pau@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: enable stubdom on a per arch basis
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 15:21 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] xen: enable stubdom on a per arch basis"):
> > Subject: [PATCH] xen: enable stubdom on a per arch basis
> > 
> > ... and disable on ARM (for now).
> 
> I haven't followed all the new logic in subsystem.m4 in detail but on
> the basis that the worst outcome is a build failure,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:50:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:50: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 1U2kmG-0002I4-QI; Tue, 05 Feb 2013 15:49:44 +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 1U2kmF-0002HY-LU
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:49:43 +0000
Received: from [85.158.143.99:40593] by server-3.bemta-4.messagelabs.com id
	F0/02-08920-31A21115; Tue, 05 Feb 2013 15:49:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360079372!23970763!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19667 invoked from network); 5 Feb 2013 15:49:39 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:49:39 -0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so388489wid.0
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 07:49:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=ROUrHRZQCzWIXalBnAUPIzcz0qNgYPS7d+Fav8FbPWI=;
	b=JVkOS9fC3mmcBb2zabY6dEQ6gfgO9aJId7hByVXbNYjz1KSYCszQmziOYGAqxDLztj
	qb9qozdczAlEXi+FUpqQEwVJJHsvUA2EhXwpHyS5/kgILLhEGNm2+e39QxND5kDNnMTb
	mEyo+bA4/pjBwMcbMz+jPUr7HdolMcq2NkPgEQOI7ic4V29KxnmVkppFc4VDQd6TaBkM
	ZTW4CzjVFseTgDvOMRmT0neSKHQ2UyTGRD2S9w0tjtookCUGhBHIcIM2IJTHx5AnyGzp
	oOYRZcsQSeHdGP+MTkHhJnTfVVh9unC1dXZBVb9/8qpQ5lkHYPaSeBIariNHyfxKqGF9
	SAyA==
X-Received: by 10.180.81.39 with SMTP id w7mr18341378wix.15.1360079365226;
	Tue, 05 Feb 2013 07:49:25 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id eo10sm28625734wib.9.2013.02.05.07.49.23
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 07:49:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 05 Feb 2013 15:49:17 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD36DA7D.5A0EC%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DuFqlI4NfxF80OEis/w1U/4/aDw==
In-Reply-To: <51111BCA.3010207@citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:

>> I have some sympathy for this design. It's primary downside compared with
>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>> you say the fairness and prioritisation features are rather nice. Also
>> having the data structures be per vcpu may well help avoid cacheline
>> contention on busy multi-vcpu guests.
> 
> This design originally (before I posted it) did have per-VCPU event
> arrays but I changed it to per-domain to reduce the memory footprint.

Okay, I wonder how much it actually matters anyhow...

Oh by the way you say the control block is 128 bytes and will easily fit in
the existing struct vcpu_info. That existing structure is 64 bytes in total.
So how does that work then?

 -- Keir

> A hybrid approach might be useful.  Busy guests like dom0 or driver
> domains could use per-VCPU event arrays but other guests could be
> per-domain.  This would be controlled by the toolstack.
>
>> Interested in what others think, but I may actually prefer a ground-up
>> redesign like this.
> 
> Since the ABI needs to be changed to support more event channels anyway,
> it seems an ideal point to revisit the design.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:50:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:50: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 1U2kmG-0002I4-QI; Tue, 05 Feb 2013 15:49:44 +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 1U2kmF-0002HY-LU
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:49:43 +0000
Received: from [85.158.143.99:40593] by server-3.bemta-4.messagelabs.com id
	F0/02-08920-31A21115; Tue, 05 Feb 2013 15:49:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360079372!23970763!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19667 invoked from network); 5 Feb 2013 15:49:39 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:49:39 -0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so388489wid.0
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 07:49:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=ROUrHRZQCzWIXalBnAUPIzcz0qNgYPS7d+Fav8FbPWI=;
	b=JVkOS9fC3mmcBb2zabY6dEQ6gfgO9aJId7hByVXbNYjz1KSYCszQmziOYGAqxDLztj
	qb9qozdczAlEXi+FUpqQEwVJJHsvUA2EhXwpHyS5/kgILLhEGNm2+e39QxND5kDNnMTb
	mEyo+bA4/pjBwMcbMz+jPUr7HdolMcq2NkPgEQOI7ic4V29KxnmVkppFc4VDQd6TaBkM
	ZTW4CzjVFseTgDvOMRmT0neSKHQ2UyTGRD2S9w0tjtookCUGhBHIcIM2IJTHx5AnyGzp
	oOYRZcsQSeHdGP+MTkHhJnTfVVh9unC1dXZBVb9/8qpQ5lkHYPaSeBIariNHyfxKqGF9
	SAyA==
X-Received: by 10.180.81.39 with SMTP id w7mr18341378wix.15.1360079365226;
	Tue, 05 Feb 2013 07:49:25 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id eo10sm28625734wib.9.2013.02.05.07.49.23
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 07:49:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 05 Feb 2013 15:49:17 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD36DA7D.5A0EC%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DuFqlI4NfxF80OEis/w1U/4/aDw==
In-Reply-To: <51111BCA.3010207@citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:

>> I have some sympathy for this design. It's primary downside compared with
>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>> you say the fairness and prioritisation features are rather nice. Also
>> having the data structures be per vcpu may well help avoid cacheline
>> contention on busy multi-vcpu guests.
> 
> This design originally (before I posted it) did have per-VCPU event
> arrays but I changed it to per-domain to reduce the memory footprint.

Okay, I wonder how much it actually matters anyhow...

Oh by the way you say the control block is 128 bytes and will easily fit in
the existing struct vcpu_info. That existing structure is 64 bytes in total.
So how does that work then?

 -- Keir

> A hybrid approach might be useful.  Busy guests like dom0 or driver
> domains could use per-VCPU event arrays but other guests could be
> per-domain.  This would be controlled by the toolstack.
>
>> Interested in what others think, but I may actually prefer a ground-up
>> redesign like this.
> 
> Since the ABI needs to be changed to support more event channels anyway,
> it seems an ideal point to revisit the design.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:50:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:50: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 1U2knC-0002Nn-Aj; Tue, 05 Feb 2013 15:50:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U2kn9-0002NV-C5
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:50:40 +0000
Received: from [85.158.139.211:55518] by server-7.bemta-5.messagelabs.com id
	22/E0-11121-E4A21115; Tue, 05 Feb 2013 15:50:38 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360079396!20094855!1
X-Originating-IP: [74.125.82.196]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8814 invoked from network); 5 Feb 2013 15:49:57 -0000
Received: from mail-we0-f196.google.com (HELO mail-we0-f196.google.com)
	(74.125.82.196)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:49:57 -0000
Received: by mail-we0-f196.google.com with SMTP id t11so48423wey.3
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 07:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=I7CetpEuMTynfSzSf+PIwa61iNqYDs0HYv8cdujgZMA=;
	b=p99cMi23L/JMkrtWseLa+dvHIxRCaZ65euFMsLJ57ns+OwIK/d8UUIYf3YGMcipIzI
	u9v8F5RpYrAFXPB1fRzDvTjMlmz9n6wjX3OJXO8+b03PQELB+Dpjmxc10gJRMuqvXLoy
	nJFMc4C2AsSVwDdaNwBf3KUvPREVp/zLiiEiAtXAf3SJj10sf7qXN5dON2uMnj7clLhT
	6bxFnHSGAj7Fb5JBUajdo280eTYZKv377kA/nvFLLVZEXAfnuR4Y7bVRsvrOryMXx3/s
	5uOYw/54VAYENAEr4gz7444tsgWrxpdunGdSXvVGNEBhzH4t8vQ8iQd/HKDlZ624Y0lP
	SeTw==
MIME-Version: 1.0
X-Received: by 10.194.19.10 with SMTP id a10mr43331969wje.45.1360079388311;
	Tue, 05 Feb 2013 07:49:48 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Tue, 5 Feb 2013 07:49:47 -0800 (PST)
Date: Tue, 5 Feb 2013 16:49:47 +0100
Message-ID: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=047d7b5d4808ce813d04d4fc289b
Subject: [Xen-devel] XEN 4.1 error Critical Interrupt - Front panel NMI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--047d7b5d4808ce813d04d4fc289b
Content-Type: multipart/alternative; boundary=047d7b5d4808ce813804d4fc2899

--047d7b5d4808ce813804d4fc2899
Content-Type: text/plain; charset=ISO-8859-1

Hello Everyone,

I am quite new on XEN. I tried to installed XEN on my server and I know
this server series IBM Xeon 3,4 Ghz didn't have Intel VTx support so I am
pllaning to use paravirtualization.
I configure the server with Ubuntu Desktop  12.0464 bit as dom0 with XEN
4.1 64 hypervisor. The configuration using repositories exactly by this
tutorial https://help.ubuntu.com/community/XenProposed :

Installing Xen

Install a 64-bit hypervisor

sudo apt-get install xen-hypervisor-amd64

Modify GRUB to default to booting Xen:

sudo sed -i 's/GRUB_DEFAULT=.*\+/GRUB_DEFAULT="Xen 4.1-amd64"/'
/etc/default/grubsudo update-grub

Set the default toolstack to xm (aka xend):

sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xm"/' /etc/default/xen

Now reboot:

sudo reboot



But when rebooting the Dom0 failed to start, enclosed was the error message
when Xen booting and after that Dom0 will restarting over and over.
On Blade server system  log I got error message :
(Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=
0020
(Bestak_septaher) Critical Interrupt - Front panel NMI

Please Suggest, thank you very much for any one help.

Best Regards,

Agya

--047d7b5d4808ce813804d4fc2899
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)">Hello Everyone,</div><div style=3D"fo=
nt-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-co=
lor:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">I am quite new on XEN. I tr=
ied to installed XEN on my server and I know this server series IBM Xeon 3,=
4 Ghz didn&#39;t have Intel VTx support so I am pllaning to use paravirtual=
ization.</div>
<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)">I configure the server with Ubuntu De=
sktop =A012.0464 bit as dom0 with=A0XEN 4.1 64 hypervisor. The configuratio=
n using repositories exactly by this tutorial <a href=3D"https://help.ubunt=
u.com/community/XenProposed">https://help.ubuntu.com/community/XenProposed<=
/a> :</div>
<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)"><br></div><div style=3D"font-size:13p=
x;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255=
,255,255)">
<h1 id=3D"Installing_Xen" style=3D"margin:0em 0px 8px;padding:0px;border:0p=
x;font-weight:normal;font-size:28px;line-height:32px;font-family:Ubuntu,&#3=
9;Ubuntu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Taho=
ma,sans-serif;vertical-align:baseline;color:rgb(51,51,51)">
Installing Xen</h1><span class=3D"anchor" id=3D"line-17" style=3D"margin:0p=
x;padding:0px;border:0px;line-height:13px;font-family:Ubuntu,&#39;Ubuntu Be=
ta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-ser=
if;vertical-align:baseline;color:rgb(51,51,51)"></span><p class=3D"line874"=
 style=3D"margin:0px 0px 8px;padding:0px;border:0px;line-height:1.5;font-fa=
mily:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu=
 Sans&#39;,Tahoma,sans-serif;vertical-align:baseline;color:rgb(51,51,51)">
Install a 64-bit hypervisor<span class=3D"anchor" id=3D"line-20" style=3D"m=
argin:0px;padding:0px;border:0px;font-style:inherit;line-height:1;font-fami=
ly:inherit;vertical-align:baseline"></span></p><pre style=3D"margin-top:0px=
;margin-bottom:8px;padding:4pt;border:1px dashed rgb(193,180,150);line-heig=
ht:16px;font-family:UbuntuMono,courier,monospace;vertical-align:baseline;ba=
ckground-color:rgb(243,243,243);white-space:pre-wrap;word-wrap:break-word;c=
olor:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1" style=3D"margin:0px;padding:0px;border=
:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:ba=
seline"></span>sudo apt-get install xen-hypervisor-amd64</pre><span class=
=3D"anchor" id=3D"line-21" style=3D"margin:0px;padding:0px;border:0px;line-=
height:13px;font-family:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera Sa=
ns&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;vertical-align:baseline;col=
or:rgb(51,51,51)"></span><p class=3D"line874" style=3D"margin:0px 0px 8px;p=
adding:0px;border:0px;line-height:1.5;font-family:Ubuntu,&#39;Ubuntu Beta&#=
39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;v=
ertical-align:baseline;color:rgb(51,51,51)">
Modify GRUB to default to booting Xen:<span class=3D"anchor" id=3D"line-22"=
 style=3D"margin:0px;padding:0px;border:0px;font-style:inherit;line-height:=
1;font-family:inherit;vertical-align:baseline"></span><span class=3D"anchor=
" id=3D"line-23" style=3D"margin:0px;padding:0px;border:0px;font-style:inhe=
rit;line-height:1;font-family:inherit;vertical-align:baseline"></span><span=
 class=3D"anchor" id=3D"line-24" style=3D"margin:0px;padding:0px;border:0px=
;font-style:inherit;line-height:1;font-family:inherit;vertical-align:baseli=
ne"></span><span class=3D"anchor" id=3D"line-25" style=3D"margin:0px;paddin=
g:0px;border:0px;font-style:inherit;line-height:1;font-family:inherit;verti=
cal-align:baseline"></span></p>
<pre style=3D"margin-top:0px;margin-bottom:8px;padding:4pt;border:1px dashe=
d rgb(193,180,150);line-height:16px;font-family:UbuntuMono,courier,monospac=
e;vertical-align:baseline;background-color:rgb(243,243,243);white-space:pre=
-wrap;word-wrap:break-word;color:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1-1" style=3D"margin:0px;padding:0px;bord=
er:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:=
baseline"></span>sudo sed -i &#39;s/GRUB_DEFAULT=3D.*\+/GRUB_DEFAULT=3D&quo=
t;Xen 4.1-amd64&quot;/&#39; /etc/default/grub
<span class=3D"anchor" id=3D"line-2" style=3D"margin:0px;padding:0px;border=
:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:ba=
seline"></span>sudo update-grub</pre><span class=3D"anchor" id=3D"line-26" =
style=3D"margin:0px;padding:0px;border:0px;line-height:13px;font-family:Ubu=
ntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#3=
9;,Tahoma,sans-serif;vertical-align:baseline;color:rgb(51,51,51)"></span><p=
 class=3D"line862" style=3D"margin:0px 0px 8px;padding:0px;border:0px;line-=
height:1.5;font-family:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera San=
s&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;vertical-align:baseline;colo=
r:rgb(51,51,51)">
Set the default toolstack to xm (aka=A0<tt style=3D"margin:0px;padding:0px;=
border:0px;font-style:inherit;line-height:1;vertical-align:baseline">xend</=
tt>):<span class=3D"anchor" id=3D"line-27" style=3D"margin:0px;padding:0px;=
border:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-al=
ign:baseline"></span><span class=3D"anchor" id=3D"line-28" style=3D"margin:=
0px;padding:0px;border:0px;font-style:inherit;line-height:1;font-family:inh=
erit;vertical-align:baseline"></span><span class=3D"anchor" id=3D"line-29" =
style=3D"margin:0px;padding:0px;border:0px;font-style:inherit;line-height:1=
;font-family:inherit;vertical-align:baseline"></span></p>
<pre style=3D"margin-top:0px;margin-bottom:8px;padding:4pt;border:1px dashe=
d rgb(193,180,150);line-height:16px;font-family:UbuntuMono,courier,monospac=
e;vertical-align:baseline;background-color:rgb(243,243,243);white-space:pre=
-wrap;word-wrap:break-word;color:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1-2" style=3D"margin:0px;padding:0px;bord=
er:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:=
baseline"></span>sudo sed -i &#39;s/TOOLSTACK=3D.*\+/TOOLSTACK=3D&quot;xm&q=
uot;/&#39; /etc/default/xen</pre>
<span class=3D"anchor" id=3D"line-30" style=3D"margin:0px;padding:0px;borde=
r:0px;line-height:13px;font-family:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstr=
eam Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;vertical-align:b=
aseline;color:rgb(51,51,51)"></span><p class=3D"line874" style=3D"margin:0p=
x 0px 8px;padding:0px;border:0px;line-height:1.5;font-family:Ubuntu,&#39;Ub=
untu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,s=
ans-serif;vertical-align:baseline;color:rgb(51,51,51)">
Now reboot:<span class=3D"anchor" id=3D"line-31" style=3D"margin:0px;paddin=
g:0px;border:0px;font-style:inherit;line-height:1;font-family:inherit;verti=
cal-align:baseline"></span><span class=3D"anchor" id=3D"line-32" style=3D"m=
argin:0px;padding:0px;border:0px;font-style:inherit;line-height:1;font-fami=
ly:inherit;vertical-align:baseline"></span><span class=3D"anchor" id=3D"lin=
e-33" style=3D"margin:0px;padding:0px;border:0px;font-style:inherit;line-he=
ight:1;font-family:inherit;vertical-align:baseline"></span></p>
<pre style=3D"margin-top:0px;margin-bottom:8px;padding:4pt;border:1px dashe=
d rgb(193,180,150);line-height:16px;font-family:UbuntuMono,courier,monospac=
e;vertical-align:baseline;background-color:rgb(243,243,243);white-space:pre=
-wrap;word-wrap:break-word;color:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1-3" style=3D"margin:0px;padding:0px;bord=
er:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:=
baseline"></span>sudo reboot</pre></div><div style=3D"font-size:13px;color:=
rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255=
)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)"><br></div><div style=3D"fon=
t-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-col=
or:rgb(255,255,255)">
But when rebooting the Dom0 failed to start, enclosed was the error message=
 when Xen booting and after that Dom0 will restarting over and over.=A0</di=
v><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-s=
erif;background-color:rgb(255,255,255)">
On Blade server system =A0log I got error message :</div><div style=3D"font=
-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-colo=
r:rgb(255,255,255)">(Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI=
_FERR/NERR Value=3D 0020</div>
<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)">(Bestak_septaher) Critical Interrupt =
- Front panel NMI</div><div style=3D"font-size:13px;color:rgb(34,34,34);fon=
t-family:arial,sans-serif;background-color:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">Please Suggest, thank you v=
ery much for any one help.</div><div style=3D"font-size:13px;color:rgb(34,3=
4,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">Best Regards,</div><div sty=
le=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;backg=
round-color:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">Agya</div>

--047d7b5d4808ce813804d4fc2899--
--047d7b5d4808ce813d04d4fc289b
Content-Type: image/jpeg; name="eror.jpg"
Content-Disposition: attachment; filename="eror.jpg"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hct84g1j0

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG
BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAMABVYDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9/KKK
KACuD+EP/JQfin/2NEH/AKZdLrvK4P4Q/wDJQfin/wBjRB/6ZdLqlsxHeUUUVIwooooAKKKKACii
igAooooAKKKKACiiigAooooAK4P9qf8A5Ni+I/8A2K+p/wDpJLXeVwf7U/8AybF8R/8AsV9T/wDS
SWqjuhM7yiiipGZPjPwJovxF0SXTNf0ux1nTZwBLaXkKzQSgMGG5GyrYZVIyOCAa4b/hif4O/wDR
Lfh//wCCC1/+Ir0+igDzD/hif4O/9Et+H/8A4ILX/wCIo/4Yn+Dv/RLfh/8A+CC1/wDiK9PooA8w
/wCGJ/g7/wBEt+H/AP4ILX/4ij/hif4O/wDRLfh//wCCC1/+Ir0+igDn/AHwp8M/CjTns/DGgaT4
es5HMjW+nWqW0LOQoLFEAXcQqjOM4UeldBRRQAVz3iD4T+GfFd/9q1TQtM1G5xt825t1lYDJOAWz
gZJOPc10NFAHI/8ACgfBH/Qp+H//AABj/wAKP+FA+CP+hT8P/wDgDH/hXXUU7isjkf8AhQPgj/oU
/D//AIAx/wCFH/CgfBH/AEKfh/8A8AY/8K66ii4WRyI+AXggH/kU9A/8Ao/8K6q1tUs4FjjXai9B
nOO9SUUh2CuD/aN/5J9p3/Y0eHv/AE9WVd5XB/tG/wDJPtO/7Gjw9/6erKqjuhM7yiiipGFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBwfh7/k53xf/ANivof8A6V6xXeVwfh7/AJOd8X/9
ivof/pXrFd5VS3EgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXPeIPh
P4Z8V3/2rVNC0zUbnG3zbm3WVgMk4BbOBkk49zXQ0UAcj/woHwR/0Kfh/wD8AY/8KP8AhQPgj/oU
/D//AIAx/wCFddRTuKyOR/4UD4I/6FPw/wD+AMf+FH/CgfBH/Qp+H/8AwBj/AMK66ii4WRyP/Cgf
BH/Qp+H/APwBj/wo/wCFA+CP+hT8P/8AgDH/AIV11FFwsjkf+FA+CP8AoU/D/wD4Ax/4Uf8ACgfB
H/Qp+H//AABj/wAK66ii4WRyP/CgfBH/AEKfh/8A8AY/8KP+FA+CP+hT8P8A/gDH/hXXUUXCyKHh
7wvp3hKxFrplnb2Fsv3YYE2RryTwo4HJJ49av0UUhhXBeK/2WPhr481uXU9c8BeEdZ1KcKJLu+0q
G5nkCqFXLupY4UADJ4AArvaKAPMP+GJ/g7/0S34f/wDggtf/AIij/hif4O/9Et+H/wD4ILX/AOIr
0+igDzD/AIYn+Dv/AES34f8A/ggtf/iKP+GJ/g7/ANEt+H//AIILX/4ivT6KAPMP+GJ/g7/0S34f
/wDggtf/AIij/hif4O/9Et+H/wD4ILX/AOIr0+igDzD/AIYn+Dv/AES34f8A/ggtf/iKP+GJ/g7/
ANEt+H//AIILX/4ivT6KAPMP+GJ/g7/0S34f/wDggtf/AIirWi/shfCrw3q1tf6d8OPBNhfWcizW
9zbaNbxTQOpyrqyqCrAgEEHIIr0WigBsUSwRKijCoAoHoBTqKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK8l8P/
ABDtPhp8TfiLDqumeLf+Jnr0F7ay2XhjUr+C4h/snT4tyywQOhxJFIpG7IKHIr1qimmBwf8Aw0b4
f/6B3jz/AMIjWv8A5Fo/4aN8P/8AQO8ef+ERrX/yLXeUUaC1OD/4aN8P/wDQO8ef+ERrX/yLR/w0
b4f/AOgd48/8IjWv/kWu8oo0DU4P/ho3w/8A9A7x5/4RGtf/ACLR/wANG+H/APoHePP/AAiNa/8A
kWu8oo0DU4P/AIaN8P8A/QO8ef8AhEa1/wDItH/DRvh//oHePP8AwiNa/wDkWu8oo0DU4P8A4aN8
P/8AQO8ef+ERrX/yLR/w0b4f/wCgd48/8IjWv/kWu8oo0DU4P/ho3w//ANA7x5/4RGtf/ItH/DRv
h/8A6B3jz/wiNa/+Ra7yijQNTg/+GjfD/wD0DvHn/hEa1/8AItH/AA0b4f8A+gd48/8ACI1r/wCR
a7yijQNTg/8Aho3w/wD9A7x5/wCERrX/AMi0f8NG+H/+gd48/wDCI1r/AORa7yijQNTg/wDho3w/
/wBA7x5/4RGtf/Itcl8ffjPpnjX4E+NdG0zSPHlzqWr6DfWVpD/whesJ5s0lvIiLua1CjLMBkkAZ
5Ir2mimmk7hqFFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArg/2kEm/wCFZQzQ
2l/e/Yte0S9lisrSW7n8mHVrSWVliiVnfbGjsQqk4U8V3lFNOzuBwf8Aw0b4f/6B3jz/AMIjWv8A
5Fo/4aN8P/8AQO8ef+ERrX/yLXeUUaC1OD/4aN8P/wDQO8ef+ERrX/yLR/w0b4f/AOgd48/8IjWv
/kWu8oo0DU4P/ho3w/8A9A7x5/4RGtf/ACLR/wANG+H/APoHePP/AAiNa/8AkWu8oo0DU4P/AIaN
8P8A/QO8ef8AhEa1/wDItH/DRvh//oHePP8AwiNa/wDkWu8oo0DU4P8A4aN8P/8AQO8ef+ERrX/y
LR/w0b4f/wCgd48/8IjWv/kWu8oo0DU4P/ho3w//ANA7x5/4RGtf/ItH/DRvh/8A6B3jz/wiNa/+
Ra7yijQNTg/+GjfD/wD0DvHn/hEa1/8AItH/AA0b4f8A+gd48/8ACI1r/wCRa7yijQNTg/8Aho3w
/wD9A7x5/wCERrX/AMi0f8NG+H/+gd48/wDCI1r/AORa7yijQNTg/wDho3w//wBA7x5/4RGtf/It
H/DRvh//AKB3jz/wiNa/+Ra7yijQNTzT4YeIF8a/HbxbrNpYa9babJoOj2Uc2paNd6b5s0dxqbyK
i3EcbNtWaIkqCBvHNel0UUN3GgooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAZVx4PtLq4eVptVDSMWITU7lFBJzwokAA9gMCm/wDCEWX/AD31j/wbXX/xyqHx
l+F8Hxp+F2t+FrjWfE3h2PWbYwDVPDuqzaXqmnvkMk1vcREMjqwU4OUbBV1dGZG/Prw1+w58efFX
x/uPh/qnir4oeH/DumRi51Lx5Z/EjxMba9s3LLEdNhl1OQC+kKtuinEiWhRmk+0Ibb7XhVqyg0lF
u/YqMU+p+in/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjleN/8FDtBg8K/wDBMH436Xay
Xsttpvwx1y1ie8vJry4dE0udVMk8zPLK5AG6SRmdjksxJJr89P2JrXwRpP7ZX7NVj4G+Cafs6+K/
A3wzuvF3jG8m0zRtNn+J+jT6bDAsVqNMnnGoE3apcv8AaCkkHkqSoaQitYTi5TU3ZRSf3qpJ9tlT
bfW17JtWZVjyQpyWrnzr/wABdNJf9vOokuidrvU/W/8A4Qiy/wCe+sf+Da6/+OUf8IRZf899Y/8A
Btdf/HK/Pr9hP/grv8Vf2qfE/wAMtbuvAl5qHgX4sQajcNDpvwx8UacvgBEilnsZLnXbpW03VYpF
i8mSS3W3CyyoUDrnGF+zn/wU7/aV/aCj/ZjAk+Buit+0rofiC6iY+GNVuh4Xn0l1fziP7ST7ZHPD
lfIBgMTvu8+UJtfRwktLarfbR2k7fdB7XW2upMXFuyem9+6XXv8Ahfy1V/0i/wCEIsv+e+sf+Da6
/wDjlH/CEWX/AD31j/wbXX/xyvgf9n3/AIKpfFf9rTw98A/CnhfS/h54X+IXxUtfFV9revarp95q
Gi6bBoGof2fIbbT0uoJppLqZo3EbXg+zoWJafAzxfgn/AIKRfGX9oL9q39nW0h13w54Q023vfHmk
+PtGtNEnv7PX73w5KttcTWzfaopkimjZ3t45C4gkcGQXRjQ0tE/edl7zv/djfml3smrbXvaya1HN
OL5XvdRt15m9I+vXtbrqr/pZ/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45XwD/wT/wD+
CtvxT/a28dfCrVb3wJfX/gP4vLfSSRaX8MvE+nD4fxqkk1lJc67dK2mapFIkfkvJbrbhZZEKB1yB
6V+294esvj7/AMFIfgD8IvHWnWut/CjW/DniXxLfaDqCrLpfibVLFtPS1hu4HBjuUgS5mnWFwy71
STaTCpDlCSlGDWrbXpypt7X1snbo3bXW6nmjaTTulb53dl52u+uqV3bv9af8IRZf899Y/wDBtdf/
AByj/hCLL/nvrH/g2uv/AI5Xyv8AHfUtO/4Jn+GPht8NvgJ4R8OeHdQ+N/xB/sLS4NTnvJfDXhR5
re4vbq5isElVUjCW0hSxtXtY5JpS25Czs3lXjH/gqn8XfBGtJ8PZdM+G998RtB+Oui/CjWdZTTr2
DRNSsNT05tQivre0N081vOkbRo0TzzIWjYh8SDy1Bc8uWnq7qPa7bgrb9HUhq7X5rraXLUlypyl0
Upf9uxU5X+apy07rzTf37/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajlfnxq3/AAU7/aDj
+DHidNM8JeGNd8VfD34w6h8N/FfifQ/BOsa3pem6dBaC6h1UaHaXb37K3nW8UgjuJPKJd/3g2odv
4Yf8FL/iv+2HqukeH/hDqXwVtr7TfhNYfEbXPEt/purato+tXd5LcQRWWn2rS2F1DAJLOdnuJy0k
e5IzblgxqFOLh7S+lov5Sp+1T725Lvu7NJN6DcGqnsnvr96n7O3n7zS0ukmm2k7n3Z/whFl/z31j
/wAG11/8co/4Qiy/576x/wCDa6/+OV+VU3/BSmx1j9qPwn+1QfCl4lqn7ImteNX8Oi8DSeZHq1lK
1qJwmNu9SvmmP7vzFBytfSv/AAT0/b7+K37QXxj03w3438LXmp6D4h8Hp4kh8T6d8K/FHgvTdDvg
8Yk0qV9XDx3u9Jg8NzBKgcQy5hUFWO8aMmknpL3rrty1KsN+t/ZSd9to3bcebOU4pc6ej5befNGE
tvL2kV362spcv2B/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr0VkUZH/CEWX/AD31j/wb
XX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAG
R/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL
/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j
/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCO
Vr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/
4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf
899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4
Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf
/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR
/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8A
nvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8A
wbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDj
la9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hC
LL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX
/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4N
rr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8A
HKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45WvRQBk
f8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4Qiy/576x
/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhFl/z31j/w
bXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr
0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/AByj/hCL
L/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UAZH/CEWX/
AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv
/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDH
KP8AhCLL/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/w
hFl/z31j/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/
4Nrr/wCOVr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8
G11/8co/4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQ
Bkf8IRZf899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQi
y/576x/4Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899
Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8A
jla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HK
P+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEW
X/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf
+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbX
X/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQB
kf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/
AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/
AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A
45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4
Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhF
l/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+
Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/
AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UA
ZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+
sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAHNeI/CdtYaDeTR
XGsJLFEzK39q3RwQPeSuZtLR5bdGa+1gkrk/8TK4/wDi67rxf/yK+of9cG/lXzl+1t8Ovih8XvhN
D4X+GPivSvAc2tEw6x4hkeX+07G02jMdgERljnkyVNwzBoVBMa+YyywgHrkWmbic3usf+DO4/wDi
6Ky/hZYeItJ8EWFp4r1Cw1fXbWMRXN/aRmJL7AAErR7VVHb+IINmQSoUEIpQB33j3xra/Dvwnd6x
ex3EtrZ7N6wKGkO51QYBIHVh36V51eftr+DLbUzZxDU7y5jt4bidLeOJ/s3mglUc+YAHwpyvOMj1
re/ai/5IVrn/AG7/APpRFXyJrGofaPE7W/8AaGjXH2fTrT/RdPh2m03K5zM/8UzdW9AF9ckA+gPi
Z+0Z8PPjF8ONf8I+I9D8Qaj4e8UadcaTqdphYftNrPE0Use+OZXXcjsNysGGcgg81w3iGL4EeKNf
+FerXngrxAdU+CgK+C7yG6lgn0ZGtxbPFvjuVaaJ4VVHjmMiOB8wY815tRQtNV5fhe33Xdu133CX
vK0tVZr5StzL0lZX72V9jqfhb8K/2b/gx8RrPxR4d8B+KrW/0g3x0e0uNYvLzSPDhvWJum0zTp7x
7PTjIGdSbSGIhHdBhHZTo/Djwl+z18Jf+FXf8I94D8Qaf/wpe21Cz8G/6bPL/Y8V+oW7X57pvO8w
Aczbyv8ACVrhaKd3a39df/kn977scm5Scpat319d/v6nRSfBn9mlfhj4V8JWngHxXpOneBtQv9U8
O3mla1fadrOh3F9LLLetbanBepewrO00nmIk4R1IUqVVVGjZeA/2dtI0n4aWemeBfE+hx/CCaa48
Ky6Rql1ptxYvOQbnzZoLxJLoXDKGnW5aUXDFmlEjMSeMoou/xv8ANbP1QSk5fFrv+N2/vbd/V9zr
PhL8Mv2cfgb8TdP8W+GvAniqz1LRHvZNFtbjV7y90jw214xa5bTNOnvHstOMmWUm0hiIR3QYR2U9
t8fPHfwi/aa0HTrDxh4c8U3R0W8XUdLv9PvJdI1TSLkAr51pfWdzFdWzlGZGaGVC6O6NlGZT47RS
eqSfTby1vp89fXUHJtuTer387739Tqk+Ff7NY+Dc/gV/h54guNHuNdHimS9uNQuZ9dfWA+9NU/td
7s6h9uThUuftHnIgCK4QBRNoXw7/AGc/DvhLw/o0HgPxNNb+GvGCeP7W5u9UurvULjXkDhdQu7yW
8a5vZgrlM3Mko2Ki42ogXj6KpTknzJ66P7rW+6yt2srbIG21yvbX/wAmun96k0+93fdnR+Lvg3+z
V41j1Y3fgLxZbXus+LZ/HU2pabrd9pupwazPbrazXdveW97HcWxkgRY2jgkSNlBBU5OYPGXwI/Zi
8beGfDekyfDvxRotv4U8Pt4T0+bw7rN74fvTo7YLadPc2N7DPc2rMN7QzvIjOWcgsxY4dFRGKirR
Vlp/5LHlX3R91do6LQfPLm5r66/i+Z/e9X567npRt/2fj40std/4Vs4utO8Gy/D23tRaRjTY/D8r
xu+nfYhN9lMJMSDBiyFXaCFJU5/7O/hj4B/ss+Kn1zwf4U8brrI0qPQba91rXr7xBPpmmxtvWxs3
1C9nNpbbgpMNv5cbGOPKny028LRVqck7p9/xbb+9yk33cm+rJ+zy9NPwsl9ySS9F2R9Pf8Np+Fv+
fDxB/wB+If8A47R/w2n4W/58PEH/AH4h/wDjtfMNFSB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv
+fDxB/34h/8AjtfMNFAH09/w2n4W/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wAN
p+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W
/wCfDxB/34h/+O18w0UAfT3/AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7X5tfsofso
fC3xH+y18NdQ1D4a+AL+/v8Awrpdxc3Nx4etJZriV7SJnkd2jJZmYkkk5JJJrS0H4QfAfxH8WtU8
GWvws8ANqulaZb6s8h8LWP2eWGaaeEbHCZLK8DbgQB8y4LfNtAP0T/4bT8Lf8+HiD/vxD/8AHaP+
G0/C3/Ph4g/78Q//AB2vy++Nnw1+FGh6gdF8M/DP4WjVo2/f3c3hKyuYLdh0j8sKhkOfvAOpAyAw
Y5XrPhH8E/gx8UNNnil+EXw30vX9MCLqemN4espDbF92yWN/JXzbeTY5jlCru2OrLHLHLFGAfor/
AMNp+Fv+fDxB/wB+If8A47R/w2n4W/58PEH/AH4h/wDjtfAPh/8AZz+BnifXtX0u0+Gnw3bUtCkR
L22fwtaRyRBwTHIA0Q3xvtcLIuULRypnfG6rsx/sd/COJwy/Cz4cKw6EeGrIEf8AkOgD7l/4bT8L
f8+HiD/vxD/8do/4bT8Lf8+HiD/vxD/8dr8ovGsPgHwt441bS0+EfwmNvp1zJCssnhu2yVViMt8u
OnU9OPyu6V4a8Dam+3/hU/wljIxkf8IvbkjIDD8wQfoQelMD9UP+G0/C3/Ph4g/78Q//AB2j/htP
wt/z4eIP+/EP/wAdr8rfiv4O8H+A/g34q8SWnwt+D8l1oOj3eowRTeEYDHI8MDyKrYYHaSoBwQa9
b/Zi8I6T4E8X/FzStD0vTtG0u18YQ+TZ2Nslvbw7tC0h22ogCjLMxOByST1NID73/wCG0/C3/Ph4
g/78Q/8Ax2j/AIbT8Lf8+HiD/vxD/wDHa+Ya4b4kfHrTvhz4ptNF/svWta1S6hWf7Pp0UTNGjuyR
582RAS7I4AUsfkOQMrkA+1/+G0/C3/Ph4g/78Q//AB2j/htPwt/z4eIP+/EP/wAdr4Dt/wBsXSbq
0W4Twz4nMDwR3KyGXTgjRSSeVHICbvGxpPkVuhbgc8VcP7U1mpk3+GPEMXk/afM8y80pPL+zY+0Z
zeDHlZG/P3M/NigLH3h/w2n4W/58PEH/AH4h/wDjtH/Dafhb/nw8Qf8AfiH/AOO18PWv7QYvbtII
vC2tNPJNHbLH/aejh2lki82OMA32dzRjeo6lfmHHNZMvjy110fbLfR/FcL3CRXUM8HjDS/LUTyGO
CRUbUjEyPKNqAqUZhtw3K0Dsfe//AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7Xwv4W
+L+p6Nei28TWLRafNcrZ2mptfaY0nmG5SzMU0Nvdyszi5lt4mkiQKJLgBo4QuT6VQI+nv+G0/C3/
AD4eIP8AvxD/APHaP+G0/C3/AD4eIP8AvxD/APHa8o+H37MmpeLfBem6rfa/Y6fNqUC3S28OntcK
kbjdHlzKnzFCpI24BJGTjNbH/DIcv/Q2Rf8AgmP/AMk07Ad//wANp+Fv+fDxB/34h/8AjtH/AA2n
4W/58PEH/fiH/wCO1wH/AAyHL/0NkX/gmP8A8k0f8Mhy/wDQ2Rf+CY//ACTRYDv/APhtPwt/z4eI
P+/EP/x2j/htPwt/z4eIP+/EP/x2uA/4ZDl/6GyL/wAEx/8Akmj/AIZDl/6GyL/wTH/5JosB3/8A
w2n4W/58PEH/AH4h/wDjtH/Dafhb/nw8Qf8AfiH/AOO1wH/DIcv/AENkX/gmP/yTR/wyHL/0NkX/
AIJj/wDJNFgO/wD+G0/C3/Ph4g/78Q//AB2j/htPwt/z4eIP+/EP/wAdrgP+GQ5f+hsi/wDBMf8A
5Jo/4ZDl/wChsi/8Ex/+SaLAd/8A8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8PEH/fiH/47XAf8Mhy
/wDQ2Rf+CY//ACTR/wAMhy/9DZF/4Jj/APJNFgO//wCG0/C3/Ph4g/78Q/8Ax2j/AIbT8Lf8+HiD
/vxD/wDHa4D/AIZDl/6GyL/wTH/5Jo/4ZDl/6GyL/wAEx/8AkmiwHf8A/Dafhb/nw8Qf9+If/jtH
/Dafhb/nw8Qf9+If/jtcB/wyHL/0NkX/AIJj/wDJNcn4p+B2oeEPiT4e0abVLO70/wAROIYbtLZo
pYpBLGjhoy7DAEqEEP8ANkj5cclgPa/+G0/C3/Ph4g/78Q//AB2j/htPwt/z4eIP+/EP/wAdrkpf
2PLOCVkbxdhkJUj+ym4I/wC2lN/4ZBsf+hv/APKU3/xykB1//Dafhb/nw8Qf9+If/jtH/Dafhb/n
w8Qf9+If/jtch/wyDY/9Df8A+Upv/jleK/ESG08JfF/XfCNrcS350Kzsrma8eEQiR7jzTsVNzHCr
GvzEjJYjaAoLAH0z/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH/wCO1+a7/tC+J5JyRLYq
kjuVVbf/AFaiRlAySc8L1qt4e/asXxL4+vPClv4u8PTeKNOgFzeaPBcW739rEQhEkkGTIikSx/MV
A/eJ/eGQD9Mf+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha/PrTPiydQ8D/8JPJ4wsovDf2H
+1DqwltBYi08vzftHnFSnleX8+/O3bznHNW/i14l8Q/DjwZaa3Z61Lcuup29rLbXdtC0c6SLIT8y
KrKQUHrkZHHUAH31/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH/wCO18MyfFS+uv2cbXxZ
FDBDqFzp0dyI2y8aO5Ue2QM57VwC/HrxQbt4TcWh8tym4WwGcHHqaAP0l/4bT8Lf8+HiD/vxD/8A
HaP+G0/C3/Ph4g/78Q//AB2vzg039oW5v9KF+/ibSo7E3o037Sr2/lfavtP2X7PuOR5v2n9zszu8
z5MbuK67wh4rvPGto1xY+Jjd26TzWryWgtpUWWGVoZoyRGQHjlR0ZeqsjKcEEUAfeP8Aw2n4W/58
PEH/AH4h/wDjtH/Dafhb/nw8Qf8AfiH/AOO1+eXxP+KviH4RfEXQrIXq6xYazBbu8V1BHFJbs955
DFXjUbvlwcFRjnrkEdR8e/iHqfgQ6WmmNbxvevKZGlj8z5Y492AMjGT3oA+5f+G0/C3/AD4eIP8A
vxD/APHaP+G0/C3/AD4eIP8AvxD/APHa/Lbxv+3DafC37H/wl3jPwj4VGo7/ALKdVvLex+07Nu/Z
5rDdt3rnGcbhnqK6/Tvj1PfeCv8AhJZPFOmx+HfsP9pnVVe3FkLTy/M+0ecQU8ry/n3527ec45oA
/Rr/AIbT8Lf8+HiD/vxD/wDHaP8AhtPwt/z4eIP+/EP/AMdr4d0qXWdRxv1u+TP92G3/AKxGsD4a
fFvW5fj3qvg3UpoNSt7Ge+WK98oQSlYXjChkX5ej9R3BPcAAH6A/8Np+Fv8Anw8Qf9+If/jtH/Da
fhb/AJ8PEH/fiH/47X57fFb4y674W8d3thYvaR2tosAAaDe7M6sxJOfbGMVx3jL9r0fDPRotS8V+
K/DfhbTp5hbR3WqXFvZQvKVZhGHlIUsVRyBnOFJ7GgD9Ov8AhtPwt/z4eIP+/EP/AMdo/wCG0/C3
/Ph4g/78Q/8Ax2vzk8EftD23xB0bRtR0rxvouo6d4ine10u6sbm0ng1KZFlZ44HUMsrqsE5KqSQI
ZCfuNjtr0a63hnVLmLxDeQXFpYXF1Ez2lvIm+OJnAK7FJBK4OGHXrQB9y/8ADafhb/nw8Qf9+If/
AI7R/wANp+Fv+fDxB/34h/8AjtfCX7Nnxa1H4seF9Ul1OG3juNOnig3xHiUNDHJuIxwcsenH06Dz
vUf2ntb0/UbSK4v9ItZNWuZILKF41RpnXzX8pAzZdxHDI5A52oxxhSaAP0x/4bT8Lf8APh4g/wC/
EP8A8do/4bT8Lf8APh4g/wC/EP8A8dr869M+LniTUSN15Guf7sCf1BrpNJ17XdTA3atcpn+7BB/W
M0AfeH/Dafhb/nw8Qf8AfiH/AOO0f8Np+Fv+fDxB/wB+If8A47X59eP/AIi6l4e8AW/iPQvE8Gsx
Q60NKniMdvPBI6PPFPEXiVSkkc0LI4ySGR1IVhxvyfFS+uv2cbXxZFDBDqFzp0dyI2y8aO5Ue2QM
57UAfc3/AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7X5qyftCeJ4bqSI3FmxjcoWFsB
nBxnGay/h3+2E3xb0iTUPDHinw34j0+GY20lzpU0F5DHKFVjGXjZgGCspwTnDA9xQB+n3/Dafhb/
AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O1+dlt8W/EdyR/p8S59LZP8K0bXx54hucZ1ULn0to/8
KAP0C/4bT8Lf8+HiD/vxD/8AHaP+G0/C3/Ph4g/78Q//AB2vgTT/ABzqOpa5PpieJ4G1K0giuri0
SKAzwQytIsUjJjcqO0MwViMMYnAztONy1h1y5Az4guFz6WkH/wATQB9v/wDDafhb/nw8Qf8AfiH/
AOO0f8Np+Fv+fDxB/wB+If8A47XxJdi70y9062vPGhs7jV7g2ljFNDao97MIpJjFECuXcRQyyFVy
dkTt0UkWvEfhbXdN8Katew+K7xZrGxuLmPfYW7oWjiZwCAoJGVGcEfWgD7R/4bT8Lf8APh4g/wC/
EP8A8do/4bT8Lf8APh4g/wC/EP8A8dr4S/Zs+LWo/Fjwvqkupw28dxp08UG+I8ShoY5NxGODlj04
+nQcFcftE+JvOLCWxVZHcoi2/wBxRIygck54XrQB+lX/AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw
8Qf9+If/AI7X5o2n7SutX2sT6emp6a1/awx3M1sqIZoYpGkWN2TOQrNFKFJGCY3AztOLvh34+ax4
s0az1HT9Y0++0/UIUuLa6tY45YbiJ1DJIjjKsrKQQwJBBBFAH6Q/8Np+Fv8Anw8Qf9+If/jtH/Da
fhb/AJ8PEH/fiH/47X582vxD8RXOM6mq59LaP/Cpp/iDqNjd2Fvd+JrezuNVnNrZRSxwI95MIpJT
HGCMu4iilfauTtjduikgA/QD/htPwt/z4eIP+/EP/wAdo/4bT8Lf8+HiD/vxD/8AHa+HLRtducZ1
+dfpaQf/ABNSaxLd+GfD97q2reM/7L0vTLeS7vLy6itYbe0hjUu8sjsoVEVQSWYgAAknFAH2/wD8
Np+Fv+fDxB/34h/+O0f8Np+Fv+fDxB/34h/+O18dQeC9Zmx/xVV8PpZ23/xFcJ8NPi1rcnx71bwZ
qU0GpW9jPfLFe+UIZWWF4woZF+Xo/UdwT3AAB+gH/Dafhb/nw8Qf9+If/jtH/Dafhb/nw8Qf9+If
/jtfnr8WfjPrvhTxzfWNi9pHaWaQABodzuzqzEkk+2MYrhrj9sx7LxzZeF7rxP4atfEupQm4tNJk
mhS+uogHJkjhLb3UCOQ5AI/dt6GgD9Q/+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha/OS2+
NPiW463kC/S3WtC1+JniK5xnUUXPpbR/4UAfoX/w2n4W/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+I
f/jtfnj4X+MsnjPUbq00zxhpmoXVhn7VDaG2mktsTTW53quSv762uI+cfPbyr1RgNzwv4o1Dxnod
lqmmeKo9Q03UoEurS7tIreaC6hdQySRuoKujKQQwJBBBFAH3l/w2n4W/58PEH/fiH/47R/w2n4W/
58PEH/fiH/47XxTbaVrdx18R3S/S0g/+Ip2i2N14hvdQtrPxs1zc6TcC0vooIbSR7KYxRzCKUBSU
cxSxSBWwdkqNjDAkA+1P+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha/Pb4s/EvxD8F/iZom
m/2gmuWOrwW7ulzbpDJAz3nksVZBz8uDgjjnrkFfa6APp7/htPwt/wA+HiD/AL8Q/wDx2j/htPwt
/wA+HiD/AL8Q/wDx2vlHW9c/sspFFE09zMD5aL/Xv/8Aqrmte8cReELy3tNc8V+H9E1G9BNtZ313
BBPc+yK2Cx+lXTpTqS5aabflqJtLc+0/+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha+L9O+
Jg07V1sdRYO00iokqlQFJIHPQY75rsqgZ9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8PEH/fiH/4
7XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w2n4W/wCfDxB/
34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH
/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/AA2n4W/58PEH
/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8PEH/f
iH/47XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w2n4W/wCf
DxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH
/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/AA2n4W/5
8PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8P
EH/fiH/47XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w2n4W
/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/5
8PEH/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/AA2n
4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/
AJ8PEH/fiH/47XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w
2n4W/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n
4W/58PEH/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/
AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9K63+174b1nw7q0cNlrSPDp11dE
yxRqu2GB5WGQ5PKoccdcVDe6t400Kx3zaF4TWONR97xDcBsdOQLIjP4n6188W3/II8Qf9i/q3/pv
uK+nvil/yA7n6D+YoA808aftcn4V2/2jX9H04W7SLCDp2py3LB2DMAQ9vHgYRuQT06c0V8//ALWv
/InD/sJQf+ip6KbVmB9xftRf8kK1z/t3/wDSiKvkTWNQ+0eJ2t/7Q0a4+z6daf6Lp8O02m5XOZn/
AIpm6t6AL65P13+1F/yQrXP+3f8A9KIq+RNY1D7R4na3/tDRrj7Pp1p/ounw7Tablc5mf+KZureg
C+uSgPgz/g4J0L/hKP2Y/hlpn9g/8JT/AGh8TtItv7G+2/Yf7W3w3S/ZvPyPJ8zOzzMjbuz2rw39
kb4XT/sif8FIPhhbT/AvWv2Z9I8c6Xq+mGytvHX/AAl1p4vukhSSKO4fzSLYRDe6nDFnKgADcy/o
J+2j+xf4e/bi+HGkeG/EWueLfDkWha1Br9lf+HL2KzvoLqFJFjZZJIpNuPNLZUBgyqQRjng/gZ/w
S08K/B741aT4+1j4ifGT4p+IPD1vcQaM3jvxMNYi0Zp1CSy26+Um2RkG3JJGDnGQCM6cWlPzcvmn
TUbadb33ulo7FYlqpCMV0il81Nyv6aq9rN6q58g/s0/tieJ/2Qf+CRXwp1Twz4r+B3heSe+1uS7b
4gXmotNdRLq1wgSysrCNp7hg8il2XIjUcqQxZfUPAH/BVf4t/tIfBn4EWfw38IeAYPil8Xxq8txN
r812vh+xg0t2jnmVYyJyJSAVXcxTlTv+8PUk/wCCNfw40/wN8PtF0rxh8WPDs/w4+3xWGraN4iXT
9SvLa9uWubi1nliiUGJnYj92qPtwNx61Y1H/AII7/DN/gz4N8HaV4i+JXhh/h7qd/qPhrX9F11bT
W9GW8keSe2iuBER5JL4+ZWfCj5ySxbec1KcpS1vK/wAtf802tL2kuzbrNOcpQ6uT17Nt7d/PW10+
jifJPwk/b+1v9hL9m344eI9W0vwzZeN/Ffx71fRT9snurnQ9Gu3t4ZJp5WgjNzNbx+W2FjQSOCOA
civeP2Dv+CkPjf8A4KF/Df4l+E/D+sfDe0+JnhRLT7H4o0ey1F/D9xBdMQZ4rS9SO682BVkGyUbH
kCc7Ca9F0T/gkD8LNA+AuveALfU/HYtNY8WHxtaawdZH9taFqu2NVuLS6Ee5WUR8NL5jEsxZmOMe
sfsu/suwfsveGtQ09fHnxQ+INxqU4mkv/G3iSXWLmJQMLHFkLHGgyT8iBmJ+YthcJKLTjU1XLFK2
m0ILTtqpfJ77WipJ8ynDfmk3fXeUnr3uml69O/xz+wl8FNe+L/8AwTh+Ofgi4+JuoeGtVvPiN4gs
9U8ZyQ7rlooriE3U7jzYwhmjSQMd4CiRjyBisb/gnX8Qvhb+xwnxw+KugXOteCf2VvtemaVoFzfL
f38WrajFm3utQt4iJZvKklZI94GGK4O3yyqfU+rf8E1fBupfsyfED4UxeI/HGn+H/iVr934h1a7t
b22S/WS6nSeaCJzAUWBigXayMxQsCxzmtH9i/wDYK0z9iOzu7PRviN8WvGGkzWcNjaaZ4s19NQsd
IiiJ2i0iSKNYeDg44wqjAxU02077PkhHbdqKTva2is1FbJvmtdIU0uVx39+cvk5XXz2be9ly31ZS
/aB+OXhb9pL/AIJmfE3xr4K1T+2vDOt+B9ceyvPs01t5wS1uI2Plyoki4ZGHzKOnpX5JaJ+z/ffB
79j7wF8WLH9mrWvh0dJGjatcfF/SPiR/aV5HbtPCJbyPR/OUAzIzDyztCeZyQATX7ofFv4a2Pxm+
FfiXwhqkt3BpvinS7nSLuW1ZVnjiniaJ2jLKyhwrEglSM4yD0r5L0b/ghz4HtfD+k+HtW+L37RHi
nwRpL2+PCWr+Mkl0K5igdXjt5LZLdB5QKL8qFcYGCKdL3MQ6kdNYNX1+Fybvaze62aT6ouo1Kgqc
9fjvbT4lFK17ro9Xe3Q8l/bg/wCC6ep/Af8AaO8QeEvCM/wxstM8E29tPeJ4rg1ia/8AFTTW6XPl
WDWMDwW52MqB7khS8inhVarH7Xf/AAWp8YfDzUvhleeEbb4c+B/CPj/wdB4oi1zx/Ya1fW13PKwD
WEB0uNyJYAQXLKQd68p8of6U+OH/AATC8J/F74xXfjnRvHXxb+Fmuavb29trH/CB+JTosGuC3BWB
rlBG25kQlFKlcKfXmtD9pX/gnhpX7Sa6ZG/xT+O3gq00/TP7JntPDXje4gt9WgxtBuknEwlk27g0
hw8gY7y+BiI3UI9+br2tL824tb2ttvcVud32t+Pu/laS8777W8H8RftP/HHxr/wVB+FmieF/Efwz
m+G+veCl8TtZwX11cWN3aM0a3kwuEjQzTBgwt2ZREEwzIrFqx/gR/wAFbfHPjL/goJoXwi1vVfgL
410bxS99Gkvw7u9UvptDEdu1zCZrydFtbkFFKN5A4YMW8srsb6B8Xf8ABLf4ea/4n+GWpaVq/jrw
hH8LNJ/sDT7PQtZ+zwanppdGezvC6PJLE+whgHUsHbJztK4HwQ/4I9fD34DfEDwb4j03xl8WdVuv
h9eXE/h611fxILyy0m3nheGSyhgaIJHbkPk7QJCVXMhGQTkVnF6r3/WzcuW/onH0s7W0TyfNyP8A
maj8moq/3yvfvdXT1PnL/gh5+13qvjHwv8Ovgv4Uk8NQ2PhXStZ1/wAXz6lFM97MJNXuFt7axVZE
UModHkkYSKFlRcBq/TjUbl7LT55o4XuJIY2dYk+9KQCQo9z0r5f0v/gnD4a/Zu+GPgW9+H8fjHXP
FfwWXVb3w3F/bNpZXXiIXjyzTaXdztB5P2eWRwASilNqsGB3E1fCX7WP7T3ibxVpum63+yI+g6Nq
F1FbX+pp8VtKnbT4HcLJOI44w7lFJbahDHbgEGtq0va3jB+876vRat2d3oklZW6Wu97vao0q06r+
FttLra93otdd/nZbWXjn7An/AAV/8Y/tI/tHXfhfx5e/BzwzGItRZvCMUOuWPizSZLd2Ihka5g+x
XMqoh3xxSI5BLgLsaOuB+B//AAcLah8Rv2g/C1tqMfw0/wCEL8aa9FolvoFjHq6+KdCSaXyoru6u
JYF0+VAQGZIX3YlXHKtX1z8Of+CXHhTwT8eNM8fav8QvjP8AEG68Pz3Nzomk+MPF0ur6ZoksylC8
COokJWNmjBkkfKnLbmAYJ8G/+CW3hP4CfFS117wv8Q/jVpnhzT76W/s/A8PjGaLwtavI7SFFtEVW
MfmMX8tpCrEkMGUlSqTjzwc1olqvnd99WtFva1+bXTKsm4zUN29PufponZ9L9tNfAPHP/BTT9orR
tK+MvjjR/B/wkvfhl8D/ABze6Bq63M99DrWrWUE8CbbZQ7RJMkchZpZDtYuu2L5CHv8Awn/a1+OX
in/gof8AFwzeIPhqnwx8LeErXW7ay1u9utNtdOsrm2kuLKVplRljlLFPtUsiuFQER8ACk+FX/BHO
P4t+O/i/qfxT1D4ieHNK8UfE7Udcj0DR/FCR6N4x0ozQT2pvraMyAjesuBmKYBjkghCvu3xl/wCC
Wvw/+Nvxo1vxlqGuePNLj8TeHR4Y1nQNJ1ZLTRtVtFhkhi86ERF2aISBkw4VWjQ7fvBsIqSpwlu+
Xbrd0ndt9+dqytePvG9XldScV8PM/uVRNW/7dT9fdPkXw1/wVJ8a/tM6D+0L8KPFl98HvFyaX8Lt
e1SPXfh0NUFhbTQxPDJA73oAnDCRWWWDMeMYZ93ydt+wv+2N8Xfg+v7NHgnxv4Z8A2vwz+I/gYr4
el0u7urnXbUadpUM5mu2YLBiVBuEUaEqJVBclDu9m8Af8Ee/APgObU7mTxx8XfEepax4Pv8AwNd3
+veIk1C4fTLoKBEu+HbH5O390I1VBuO5Xr0TS/2CfB2lat8EbxdQ8RSv8BdMuNK0BJJ4GS+hmsks
3N2PK+dvLQEeX5Y3E5BHFdCaSfLu0k+117Wzt5c0Px33M7pq0tlzW+cadlfzlF38uivY+HPgf/wc
Lah8Rv2g/C1tqMfw0/4Qvxpr0WiW+gWMerr4p0JJpfKiu7q4lgXT5UBAZkhfdiVccq1fSP7IH7WX
x0/ad/aq+IenSaV8LLH4TfDbxpqvhe/uAL5NfvFhRvsxhXe8G4P5RlZ9oZXbYoK89P8ABv8A4Jbe
E/gJ8VLXXvC/xD+NWmeHNPvpb+z8Dw+MZovC1q8jtIUW0RVYx+Yxfy2kKsSQwZSVPpv7Ov7Kvh79
mXVfH15oN5rN3L8RfE114r1IX80UiwXVxt3pDsjTbENowG3N6saVPlUVzb8r+9uFr+iU3fzXolNu
8rfzL7rTv6XvDTy+b8f8LfGTUPA/7LXwU8PwWl3ZW+veDNK2aqceTPItlGXtEIOVl2KXIcLuTcU3
+XLsd8KtKn1z9qfxlZW2pT6Lc3fwzsoItQhCmWwdr2/UTKGBXchwwzxleeK9N/Zv8EaX8R/2Gfht
outWiXunX3g3RxJGWZGUraQMjo6kMkiOqujoQyMqspDAEcz8Jf2cPEXhr9pDxXN4ottO8Q+ENQ8I
W2gW9/MImOrILq6d4rq2wFEnlzBX2r5Mg+ZQm8wxQBz1r+xd4jslURfHa5XYAoY+GNGLYHqTFkn3
PXn1q5p/7M3iHwr468O+JL/4+zzT6JdpDbLc6LplvHdC4kSI2btGqM8c7mNfLDfNIImXEiRsvP8A
xb+GE37MWtrezy3t54GmcLaagyy3VxpbkjbaXG0PJJk4WGbDNIdkT5m8trnrfgn8GdT+N+s6b408
c2rW2j6cN/h7w/LtZYwQR9quApKvKysRwSqqxRCUMklyAZ3xHuZNG+Meuazb6tD4fvdEkluYdTmw
YLRPLRplnUsoe1dY181CygiNHVo5YopU9z+CvxK/4W/8LtI8Rmwm0ttSiZntpCTsZXZGKllV9hKl
l3pHJtZd8cb7kXyA/s4a98ZvjXq2o+L7D+xPB9lqLTWmnpeJNLrjRyEQ3EpQ/JH8iSJF1UlXYmQR
/ZvoS0tItPtIoIIo4YIUEcccahVjUDAAA4AA7UAfO/iLx34K+DXjTWtbg04+OviLealci2s9Ts2j
0HwqBJtWWZC2dQuGCh0AxEm8Zw8fPY6nrGoftL/D6fxhexm6+JXhCyjbX5I7dI38WaTHgG+VIlVB
dWpdhIioC8IQqSVSMfPvxdvr1/jR4hZfC/j+4gTVJgJoPB+qzwyASEbkdLdldDjhlJUjBGRg16D4
E+OLeApNL1LSdM+JGl69os/2qxuh4B11xBKFZfmUWo3oysyum4BkZlyM5oAvfH7w7H4f/Ym+IPiH
xWt7ptnrnhPU4/DWmWsRl1TWS1nIEvnjIC22nqx3ebI26VVYIuWiMno3wM/5Kb8Y/wDscLf/ANMG
j14f+0l8Xb/4ufCX4gJPpXxQ8Q+LPFOiX1uZ5/AmtI95cSW8iRoM2gSNAWCqo2og44Fe4fAz/kpv
xj/7HC3/APTBo9AHeeIdetPCugX2qX8vkWOm28l1cy7Wby40UszYUEnABOACa+HviT4qbxjr1zf6
nY29ze3t5Hq13a3Wg3OoxEsTClmHi2IfKg8svIuCyxLtcOZI297/AOCgPxRsPhL8F9O1LWDcnQ5d
bt4r+O3A8yVRHLLEASCRieOFuOoUjoSD8hah+3j8LtW1KzvLq7+Ic9xpwIs3OuXY+xAlDtiAIEa/
InypgDYvHyjAM15tAsrW3khW10a5aGGWETL4Guw07QSb1lAJADXKny1BCqqjLLA3zmyvhmyvrxo0
sNEiSWeSISr4FvmSFbiPesgGSxW2YeWoILMx+ZZk+YZekf8ABQ34b6DqF7d2eo/Eu1u9SZHvJofE
uoxyXbIoRDIyuC5VQFBOcAADirzf8FLfh7LIXk1H4mzMepfxVqpJ/wDItAGxofgiG5eG4Ph2xIJt
blrY/Du+kAzmGS3Yq/b/AF8hVvQRueYq6LS/heltY4/sGO6eG3Ybh8I7uR7h7ebIIy6rvulO0fdR
UXnyH5PFR/8ABTL4bp1l+Ij/AF8Vav8A0np0X/BS/wCF0Wqw3/2bxyb62jeGG4PinWRLEjlS6Kwu
MhWKISAcHYuegoA95+G/hHTdG1HU9PuvDEmqWHiBJPDd3Z2Pw4vvDv2+y1Ca3WeRrzDMkEEDzIAx
iZvLJZmISQ+0/B7xBqGoeHrvSNcuftniTwndto2rXHlrH9tlREkiu9qDYn2m2lt7ny0LCL7T5ZO6
NgPh+b/gpf8ACa6tdUhm0rxhPFrgI1JJPFGtldQBjWI+cPtWJMxKqfNn5VC9BivYP2Z/27dJ/as/
aqhfQtJubGB/Dc1jqkywyGOZ4bhZrFWZyQmxZtTI2YL+ad24IhQBn2lafF648OftW/CDQm1LUIdL
vPhhqEz2AuCtvd3EUmibJPL3BXeNJZAGxlRI2MBjn5ZvPip4g8QeFdZ+IXiTxP8AELxX8PvB4164
ubXwh8SLvRfEPhzZ4h1fZqAtElig1O2NtFbokV3OUjSwkWGCcyNG30T418HfDX9ov4caHpPxB8O+
GvENnpkNuBpfifw4dTiguIIfIEyKYJY8soJVgQwWQggciqmvfAH4J+KtY8O6hqnhL4b6lqHhCGG3
0G5uvB7TTaJFCwaGO1drQmBY2AKiMqFIyMVVO8eS/wBlv8XJ/euay16XuthSaalHpK1/lZWT10dt
dPKzTZ1//BQz4oanD+xJ8RtS8MeKfEvg7V9L0G51G21HSBbpc/u4mfy900cmxXxgtGElUHKPGwDD
xX4sfGXVn+O/ifxePE/jOy13wV8SfCXhTQNIt9eurbSb7Sb6LS/taT6cJRa3Mkn2/UGE8sTyL9nQ
I6GEY9b+Jvhn4efGvwnLoPjK38L+LdCnkSWTTta0C4v7SR0OVYxS2zISp5BI4NYujfBL4N+HPE/h
7W9O8M/D2w1nwjZf2boV/b+EpIrrRbXDj7PbSLaBoYsSSDZGVXEj8fMclP3aim1omn9zTf3pcttr
Sbs9mN3g494teV3b/h777JNWTXDfBX9qD4p+IP8Ago9pKeOPB3xQ8LaXrvhbWxFo9xquizeH9Pht
7vTxb3KJa6hJJNKQzh5pIhIGu0REWJHYeb/Db/go34v+B/wi+INpoGhaUn/CMeKtUtdP0/U4Ee/1
651Xxdc2sWowM95bWwsbZpSjRyTI802Y3kskEc0/1fLqPha41+DVpL/S31W1gktYbxtKvDcQwyMj
SRrJ9n3BGaOMlQcEopPQVzut/DP4VeJbVINR0fwTqEEcV9Asdz4YmlRY75t16gDWpAW4PMo6Snlt
1RGLVOEP5U0/O8m9+9na+ttWldK1XTk5d2n6WVvu8u2hxg/4KK/Ff4E/CHTvF/xl8DwaFptprN7p
eqGKwt7e6vIWsTPp11FBa6pqMdv5l2v2EwtcTPJJNC6mPd5dfTfwo+KGtXfww8PS+MY7KPxZNp0E
msJpsLRWcd2Y1MqRK8jsEDlgNzE4HWvnhf2cfhHpHgOx8K+Hbbw/4K8M2muW3iCXSvDWgzaVZ39z
byJLH50cVoAymSKFmxgt5SAkrlT6b/wmejf9B63/APAC+/8AjFaXundatr7lFa+rk3fppGyXXO2q
t53823+itb11vY9a/wCFkWv92f8AJf8AGj/hZFr/AHZ/yX/GvJf+Ez0b/oPW/wD4AX3/AMYo/wCE
z0b/AKD1v/4AX3/xipsyj1r/AIWRa/3Z/wAl/wAaP+FkWv8Adn/Jf8a8l/4TPRv+g9b/APgBff8A
xij/AITPRv8AoPW//gBff/GKLMD1r/hZFr/dn/Jf8aP+FkWv92f8l/xryX/hM9G/6D1v/wCAF9/8
Yo/4TPRv+g9b/wDgBff/ABiizA8N+En/AAXw8IfGH9s+b4B2fwV/aC034i6bctFq9tqGi6VHbaFA
uwve3My6iyi1CyRusqbxKJYhF5rSxK/0/wCPddj1/wCKfwzljDgJqsqncB/z2sT2rhYL7wra+I7v
WIr7So9Xv7aGzub5dJvBc3EELSvDE8gt9zJG087KpOFM0hABdssu/idpVn4+8KzmW8uNP8PXLaje
XkdjOU2tLASkabPNkdVgLEBMneAu45osxGB+0B8R/ij8Nv2sNW1TxL4u8d+BvhxBr1hbaHeaf4X0
rXPB1/ayeQssGqeWH1m1uXle7H2svbWEKpbF3Y7kmy9N/wCCqupa18dPGvg6w+Go1SLQtG1zV9Dv
LLVrqUa+dIubeC6txMbAWHmnzmIS1vbto3j8q4FvKSi0vGvif4B+OvjBf+NLz4f/ABi/tHVdRh1W
/soF1q10bVruHyxDc3mlxXC2N1MohhHmTQO37iLJPlpiL4d+IPgJ8K/jEfHuifD74wQ+Jl/tEQS3
Ka1eWtimoTpcXkdvazXD29vHLMiyGOKNEDDIAJNTC6iovopfe4pRbe7tLfZW6XbvcmnJu3VeWibu
uqV1bu79bWR0/wAaf+CocPgrw+b/AMG+Dp/HkGr+IIfD3hq6sX1G9tdalGnHULqYrpmn390kMMYM
YeK2m3ShlYRKrSDzzw/8ULj41fF3xD4qvPD2teE7zXNA0K5uNH1a1mtbzTpDFOHieOaOOUYYHBeN
GK4JRScDcute/Z/n+CuifD6D4bfFTS/DXhm+fU9HGl2mradqGkXLvK7zW19bzpdwu3nzKTHKuY5X
jPyErXOeBrXQIfiJr/8AwiHh7VvDfhC00jSNN0q0v7Ga1eNLdJkK/vcs5HyksWYkvliWJq1a0vVW
9La/e9Vvp1M7SvHXSzv63079N9d+nU8C0Sz+0sTj/lrIP/IjV5z8A9Dew8D+Afh7qfg3X9S8b+EL
izutU1KW0u7HTorqM5vNXj1UR+XcNc+ZM/lxu89x9taK5jiR7ww70Hxuh8L3t5Yy2awXVldzRTLd
20sjowkYFf3bgcHPPOQRz3OzY/tcDTwAllpDY7mzux/7UqSjw7wT+zJ4pj/ZE8a6BPpnxOa+8K/A
G30TTdHbUtWa0uNee38QWupW8dt5nkXr+YtssYCyosZtGt8RGAn7o/aqsFh+BcbYwV12xx/3zPXk
Vl+3pcWAwmkaCx9Tb3g/9nrO+KX7bD/FLwaujXuk6ba2yXSX3mWUdz5u6JHxnzNw2DcS2MHA6gCg
D06z/wCTIdL/AOwNb/8AoSV4/wDFDVda8KfC/wAQ6l4b07+1/EsVnIujWRgkmjur5xsto5AhBWIz
NGHcsiRpud3RFZ19fvI59I/YZtC9rcSS2uhQyyRRD95tXazEA+ignpkgcAnivFbD9pC1tArRW9jt
x0ls7hmb3JWQDnrwKAPIPh18A/G/wi8Ly+CLrwkY9Lm13wDqulzaXfXGv+b/AGdqmkWF6ZrgWdss
PlWdjYTFHiGd11IruiSJb/Vv/BP/AODLfBv4ZeI/D9xb+Ibe6t/GmvXLjVr68vjJDcajNcWkkU9w
7iRHs5bZ2aN2HnPN5n+kfaBXGWH7ZDacylLDRm2+tpdjP/kStmy/4KBXdht26L4ffHrDejP/AI/Q
B0n7Y1qLf4qeBiBgta2uf/BpW9+1au+78Oj1kuB/5DWvGfHf7RMv7QvxH8LtJptva3ltc2dlCllH
N5Tr9r847vMBO84bHOMKeOCa9V/bT8UL4Mh8M6hNbTzWy3c0TOq7kVmiBVW7/MFbBHp16AgHiP7Q
HhK+8QfDbS4NPsrq+nj8XeGbl47eFpXWKLXrCWWQhQSFSNHdm6KqMTgAmvA/2i/Cvxb1nWPiBa6X
Y+P9Ut/EWn+K9G1PS00nUru2is20XVG0xY5vtH9nyfaHhsjH9hsRNEWS3ubgzyOLv6Lsf2mIdPPy
W2mP7NZXf/x2trT/ANtJtOOV0zRZPY214P8A2pQB037GGna7/wAJ74u81fiGvhgWGmf8jl5gvv8A
hIPMvv7V2b/k8ny/7Ox9h/4l27f9l482tPwdCIP26vEiDoLnVv8A0ZBXO2f/AAUHubI8aD4dcehi
vR/7PSfs4fEE/Fr9qa911bUwSXltfXt0qI4ijaWWMDZuGdmUKjJJypGSegBp/GmHz/jDq4/6Z2x/
8h15P8ffhjrHj7xP8JoNHv8AXtFa08XS3Fzquk20E82mRf2HqyeYfPhmhVGd44t0kZGZgBhiprvf
2jfiTH4C+Ompw3No+66tLaaF5omkikXaVLLsIbghlIJHODjGM87YftTx6cBttNKkx/esrsfyloA0
fG/wGz8bvgR4hW11XxFrOga9LY32szx+bJbWn9gayrzOsarBb+fcPbiVoo41lcWykERwqn03Ppan
wbroI66PfZ/8BpK+bbD9uCTThhdJ0OTH963vB/KSrt7/AMFBrqfQ7+zOh6AqXtpNavIsd4HRZI2R
mXLFdwDHGQRnsaAOw/Yf/wCRU8Tf9f1v/wCkkNfI37dPhzxLrXwy0m48J2eu3Wtabda7cW8mkRSv
dWsp8Oa5HBIhiG5WM8kKIRg+ZJGB8zAV9cfsNSi88G+JrmOKaO2l1NUi81SG+SCNCDkD5gVwePy6
V4xB8bofC97eWMtmsF1ZXc0Uy3dtLI6MJGBX924HBzzzkEc9yAeV+OfDnj3wbZ65pegW3xQ1S38P
+KGh8KW0WoXp/tHzNK06WJZNSKzznbez3rRy3yXGmfupre6CD7M0OhcaN8YfFHxY8U6DfxeONOsr
zxLbQ376Vfa+r6jpj+LtLW0ltporWOxsEh0R7pZhYXplkSV5LlRLDKYvXbH9rgaeAEstIbHc2d2P
/albVl+3pcWAwmkaCx9Tb3g/9noAp/D/AODbfA/9jvxH4fuLfxHbXlr8VNTu2Gr395fmWG51C9ub
SSGe5eTzEks5rV3aJ2HnNN5p+0/aBXpNn/yZDpf/AGBrf/0JK8x+KX7bD/FLwaujXuk6ba2yXSX3
mWUdz5u6JHxnzNw2DcS2MHA6gCvTbyOfSP2GbQva3EktroUMskUQ/ebV2sxAPooJ6ZIHAJ4oA+dv
2hvB+o+Ofhpf6fptv9vka+sri6sPMVP7Vs4b2Ga7svnIjb7RbJNDskZY383bIyozEcf8RfFl1480
DXfEvg3wZ4uluLXTYdPvL2Vr/wAMX9/D9sheS2jhe1a6lWK3N1J50cBmj85o7JmnnlMXoC/G/TZG
8xbe1Abn57S4Zj7krIBz14HerMPx+src8Wmnt9bS6H/tWgD530rXfEnhnw14U0Lx9e/E5NCufiCT
ZPpVtr1rqWp6LL4ev5YQPs9zc6i2b+3llaCa4e4hVYzLFBGY4l9J8Kt8Q7XxN8NpPs3xHvi+qzw2
UE9xc2sEWjNq8/lXFzLskV7iPSBbiaDWEWaUSIbaeK/juBJ6FcftAaRe3djcXOh6Hdz6XObmzkms
bl3tJTG8RkjJkyjGOWRNwwdsjjoxB2Lf9ryG1xjR9JbHrBdj/wBqUAGp/Ea1+DP7YfizU9a0bxvc
aZrngzw/a2V3o3hHVdagkmt77W2mjL2VvMqOq3MBKuQcSKRmsKOP4y/8I34g/wCESHi3/hbX9gap
/wAJP/au7/hGf7R+wz/2Z/Yn2n/Rf+Pz7P5PlfJ9k8/+0v8ATfKrq7f9t5bXpoGjN9Yrwf8AtSr0
H7f5twMeGNDbHqt6P/alAHC+KPBOueM7/wABf8Kcf4u2sen+L2uUv/HdtqskGnTnw54ghlkifV45
b+Dd5tpF580U1jHLNbNHBcSC7gk+n/gReaX4i/ZOjutI07x3pGn3mgX8y2HjR79tesnaKdpIro37
yXBdHLKCzum0L5bNH5ZPk0P/AAUblgGB4S0A/wDgb/8AHKNY/wCCkE2p6Ff2R8J6HbJfWstq8sTX
e+NZEZGK7mZcgMcZBGe1AHTfsP8A/IqeJv8Ar+t//SSGvLwuX/4HJ/6MevT/ANhqUXng3xNcxxTR
20upqkXmqQ3yQRoQcgfMCuDx+XSvD5/izaaPf3dlc2XkXdjdTwzLdW8rujCRsr+7cLwc885yOTjJ
APOfG/w0165/an1fxpoWmXM2qeHdB0D7G2BDHrFv9s1hdR04SsVV2ME0cqRtIkYuY7F5SEXNcp8O
4PHPw9+Gvwx0g2Pjqz/tLw18OdPtrazsb2SOxntNU3aylyIlK2f+hyQrKbjyxKilMv5bqvu0Px3s
YMYtrA4/6dLof+1auW/7Slpb9LDTW+trd/8Ax2gDxLX/AAZ8RdN0HxTq2my/FFtZNh4/8QWaLqWq
Sx/2pp+rhPD8ccBkMflPbTS7LRU8i7QKXimEaFfo39prUm8KeKfg/wCIJNM8Qalpnh/xlNdaidH0
W71ee1hfQdYt1kMFrHJKU86eFCwQgGRc4rNt/wBrSC1xjSdKb/t3ux/7Uq/b/trJa4xoWjtj1ivB
n/yJQBj+KvGHi/4heKLnWPD8HxDt9avNn/CtIxpWpaZoa7UVLv8At63mjjKfv1mMv2xBuszbtpub
0yE878avDfiHxd8IfjbpNzY/GnU/iZqejeNLR7O0h1Cfw5d6VJBqKaTFGkgOmu7W50xQunA3xnIE
ox9ur0i3/b3+zdPDWht9UvR/7Uq7B/wUVkt+nhPQW+v20f8AtSgD0L9lVdSt/Fvj2y8T/wDCYXPj
Ww1CGLVdRvPt6+HtWiZGltZtHjl/0WGERSCKSGDMscsJS4lunVLu45vwfCLf9uvxIgxgXOrdOn+s
grKi/wCClc8I48HeHjj/AGr7/wCOVS/Zx+IX/C3P2przXktHtpL22vb26RVby43lkjA2ZUfJlCoy
SQVIyT0ALXx7Gfizq/8AuW3/AKLNfJXxktr7SvGnjG10/RPEk11r15bXceiDRLvUNL8VyJa2qxXc
eo20anR74TW8dsk0lz5dt9kW5MOXWWvp39pjx/B4O+N2p215aPm6tbaaGSWJnidQpXcuwhuCGUgk
c84xgni4fjlYQ9LewP8A253X/wAdoA8X8cx+J/8AhC/ib9kHxf8A+Fn/AGHxP5H9m/b/AOyfsfl3
v9leTu/0LzfK/s7b9g/0zz8b/wDl7rv/ABL4N8VeBfEtxpOhS+PJ9Xtdv/CvHGpahqOjNuQPc/23
PK8hf980vmfa3OLTyBp+LsSAdpb/ALRtnb4xY6c3/brd/wDx2r1v+1Zb2uMaXpb49be7/wDjlAHN
fsMeAtb8K/HL4m3ep6Pqum2l+Jvss11aSQx3OfFvi2cbGYAN+5ubaXjPyXETdHUmD4C/EbU7r9jj
4W+CrPRfido9z4Y8N6Ta+OIl8I6zpWpwafBYpDdR6fcS28aSXAn8oMts7XLWwumtQbhYSO6t/wBs
2O2HGiaQ31hvP/jlX7f9u/7MRjw5ojfVL0f+1KAOYvU8R48Nf8Jp/wALd/4U6f7W/sr+xv7d/wCE
r/5hv9lf2l/Zf/Ey+5/bW3zf+WP2P7b/AKdVj4TeHPF/hf8AaH1XUPGNj8VH8J+IvHGlrbJZwz2+
ox6sPDGhhNQ1ZtKHkXNgZLW4tZTEy2EVxvEsdxHIklj1kH/BQ17bGPCugtj2vf8A45VqH/gpPND0
8H+H2+pvv/jlAG1+2hAI/i34IcdXtbTP4aoK9+r438fftHv+0Z8SPDEjaPFp95bXNpZQxWgmMTJ9
qExzvBbecNj5sEKeOCa+yKAPPPEfxEt/B/xCv2lYiSFFMZz0Plqa/PP9v/4XeDbnU/E+t/2Jqfjv
4ifFyeLSNMbVJ0eLQZBEyrLAwRTDHGMMclixVRkAsa+7f2lvg3qviZRrHh6KKW6RCbyFpirz42Kp
QEYyFDZBYcKMAk8/D/xUgk1zxlpNze3+uaXeeGbqVms4ZjAkzn5WjuIyuWClfu8YOa+n4Rz6eUZg
sVGbjGzvZtc1vejFuPvcrnGPNZq662MMRSVSFv6/qx6T4A8R33gL4VeHdD1PU31TUdI0y3s7i7Zi
TcSRxqrNk8nJHU8+vNfb/wAN76bU/h3oFzcNI9xcadbyytISXZmiUktnnOTzmviP9n74BeJvjxrV
nfi2+y+GY50e5u7hzELmIShZEh+Vt74DgHGwFCGIPB+87a2js7eOGGNIoolCIiKFVFAwAAOAAO1f
PYmvOvVlWqbybbtort3ei2Noqysh9FFFYjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAsW3/II8Qf8AYv6t/wCm+4r6e+KX/IDufoP5ivmG2/5BHiD/ALF/Vv8A033FfT3xS/5Adz9B
/MU0B8afta/8icP+wlB/6Knoo/a1/wCROH/YSg/9FT0U5bgfeXx58L3/AI0+FGq6ZpkH2m9ufJ8u
PeqbtsyMeWIA4BPJ7V85Xn7NPxE1HUzLLolnHbR28NvBBbvbRbdgO6R280l3ckZPH3RxW7/wWZ/b
W8Vf8E7f+CbHxI+MfgrT/D+qeJ/B/wDZn2K11uCaewl+06pZ2cnmJDLFIcR3DkbZFwwUnIyD+JHw
X/4O7v20P2ifinongnwT8Jvgb4j8U+I7kWun6fa6FqxkmfBYkk6oFRFUM7yOQiIjOzKqkhRi5Oy3
E2krs/Zn/hl3x1/0A/8Aydt//jlH/DLvjr/oB/8Ak7b/APxyvx+8S/8AB1r+234T+Dt/8QLr4Yfs
3y+DdN8VyeCZdVs0ur2F9VjgNw0Mfk6w7SxmIb1njDQOMbZDkV2fgn/g47/4KAePvBuseILL4W/s
q22jeHrfTbvVLrVNai0tNOh1G1t7uxlm+069GY0niuodjMAGcvH/AKyKRE1jhq0naMW/k/66P7iX
Uilds/U7/hl3x1/0A/8Aydt//jlH/DLvjr/oB/8Ak7b/APxyvyX+Mn/Bzt+3n8AfBet+IfFPwk/Z
xstG8OeLG8Dalc2xnvxa60lsLp7Mrb61IxZIj8zAFFdWjZhIrIE0v/g54/by1749+Jvhfp3wj/Zy
1Tx/4Stru51DRbH7RdTv9lj8y4htjHrLLd3Mahibe2Mk2Y5RszG4VewqXUeV3fkHtI2vc/Wn/hl3
x1/0A/8Aydt//jlH/DLvjr/oB/8Ak7b/APxyvw+/4jVv2p/+hB/Z/wD/AAR6v/8ALOvQP2av+Drf
9tz9rz4mL4N+H3wu/Zy1rxNLaTXsNhPFd6dJdRxDdIIjdaxGsrqmXMaFn2I7bdqMREISnJQgrt9E
VKSSuz9gf+GXfHX/AEA//J23/wDjlH/DLvjr/oB/+Ttv/wDHK/EzxL/web/tXeFPEeoaXdeBf2cp
bnTbmS1mezsNRvbZ3RirGOeHVXilQkHbJGzIwwVYgg16Z4A/4Oc/29fiJ4RvfEEXwi/Zy8P6BYTW
dtJqnir7R4YspZby1+2WscU2pa1bpM8tqVnVYyxMTxyY2OrFxpyk+WKuxOUUrt6H6z/8Mu+Ov+gH
/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfiz8Sf8Ag8S/a/8AhD8Rdf8ACfiL4a/s/wCneIPC+pXG
kana/wBk6pN9mureVopY98eqMjbXRhuVipxkEjmsT/iNW/an/wChB/Z//wDBHq//AMs6lpp2Y001
dH7g/wDDLvjr/oB/+Ttv/wDHKP8Ahl3x1/0A/wDydt//AI5X45fs9/8AB2l+2v8AtVfGDR/APgH4
U/AHX/FuvmYWFgNN1G28/wAqGSeT95NqyRrtjidvmYfdx1wK4v8A4jVv2p/+hB/Z/wD/AAR6v/8A
LOm4y5ea2n9f5oOZXt1P3B/4Zd8df9AP/wAnbf8A+OUf8Mu+Ov8AoB/+Ttv/APHK/HP4L/8AB2f+
2v8AtC/8JZ/wh/wp/Z/1f/hB/Dl54t1v/iXahb/YtLtNn2i4/e6su/Z5ifIm5zn5VODXFf8AEat+
1P8A9CD+z/8A+CPV/wD5Z0OLSTa0YKSbsnsfuD/wy746/wCgH/5O2/8A8co/4Zd8df8AQD/8nbf/
AOOV+H3/ABGrftT/APQg/s//APgj1f8A+Wddn+z9/wAHa37an7Unxd0jwJ4F+Fn7Put+Ktd877DZ
Np+oWgm8mGSeT97PqyRriOJ2+ZhnbgZJAJCEpyUYq7eyBtJXZ+x3/DLvjr/oB/8Ak7b/APxyj/hl
3x1/0A//ACdt/wD45X43/AL/AIO2f20/2oPi3pHgXwN8LP2ftb8U66ZRY2R07ULUTeVC80n7ybVk
jXEcbt8zD7uByQK47/iNW/an/wChB/Z//wDBHq//AMs6HCSiptaPr6b/AJr7wur2P3B/4Zd8df8A
QD/8nbf/AOOUf8Mu+Ov+gH/5O2//AMcr8Pv+I1b9qf8A6EH9n/8A8Eer/wDyzrtPg3/wdpftrftA
DxYfCPwr/Z+1YeB/Dt34s1snT9Qt/sWmWpQTz/vdWXftMifIm523fKp5ojFyfLFXYOSSuz9jf+GX
fHX/AEA//J23/wDjlH/DLvjr/oB/+Ttv/wDHK/HH9n7/AIO1v21f2pfi/o/gLwH8Kv2f9d8Wa+0q
2Fj/AGbqNr55jheZ/wB5NqyRriON2+ZhnGBkkCuM/wCI1b9qf/oQf2f/APwR6v8A/LOhwkoqVtH1
9N/zX3hdXsfuD/wy746/6Af/AJO2/wD8co/4Zd8df9AP/wAnbf8A+OV+H3/Eat+1P/0IP7P/AP4I
9X/+WdH/ABGrftT/APQg/s//APgj1f8A+WdSM/XDRv8Agk3ceHNHtNP0/TPH9hYWEKW9tbW/xL1a
KG3iRQqRoi6gAqqoAAAwAABVn/h1pqf/AD7fEj/w5+r/APywr8rfg1/wd7fti/H74oaL4M8LfDj9
nS98R+IrgWmnW1zaX1gl1OQSsQluNWjiEjkbUUsC7sqKGdlU9L4D/wCDpb9uz4m/tQS/BnQ/hB+z
9f8AxJh1K90d9IFnexgXVmJTcR+e2riA7BBL8wk2tt+UnIzpCjUlbli3d2Wm77evkS5xW7P0t/4d
aamf+Xb4kf8Ahz9X/wDlhR/w601P/n2+JH/hz9X/APlhX5Df8Rq37U//AEIP7P8A/wCCPV//AJZ0
f8Rq37U//Qg/s/8A/gj1f/5Z1mUfrz/w601P/n2+JH/hz9X/APlhR/w601P/AJ9viR/4c/V//lhX
5h+E/wDg69/bZ8c/ATxV8TdK+GH7ON54O8EXNva65crFdrc6c9xIkcDNaHWBcmOR5AqyLEUJVwG/
dvtq/s/f8Ha37av7Uvxf0fwF4D+FX7P+u+LNfaVbCx/s3UbXzzHC8z/vJtWSNcRxu3zMM4wMkgVc
ac5NRim29vPW2nfXT1JclZu+x+o3/DrTU/8An2+JH/hz9X/+WFH/AA601P8A59viR/4c/V//AJYV
+Q3/ABGrftT/APQg/s//APgj1f8A+WddP8Gv+Dvb9sX4/wDxS0PwX4W+HH7Ol74j8SXS2Wm21zaX
1gl1O2dkQmuNWjiDuflRWcF3ZVXLMoMxi5NRirtjbSV2fql/w601P/n2+JH/AIc/V/8A5YV0nw1/
YF8QfCSx1GDRfD+pf8Ta8+33k1/4hbUri5n8mKHe01zcSSHEUMSAbsAIMAV+PvxJ/wCDxL9r/wCE
PxF1/wAJ+Ivhr+z/AKd4g8L6lcaRqdr/AGTqk32a6t5Wilj3x6oyNtdGG5WKnGQSOaxP+I1b9qf/
AKEH9n//AMEer/8AyzoaadmCaauj9sfE37GnirxjpZstS8MpdWxYPta+gBVh0IIkBB6jIPQkdCa5
z/h23d/9CZ/5V1/+PV+OP/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdIZ
+x3/AA7bu/8AoTP/ACrr/wDHqP8Ah23d/wDQmf8AlXX/AOPV+OP/ABGrftT/APQg/s//APgj1f8A
+WdH/Eat+1P/ANCD+z//AOCPV/8A5Z0Afsd/w7bu/wDoTP8Ayrr/APHqP+Hbd3/0Jn/lXX/49X44
/wDEat+1P/0IP7P/AP4I9X/+WdH/ABGrftT/APQg/s//APgj1f8A+WdAH7Hf8O27v/oTP/Kuv/x6
tDwz+wHrPg/VBe6f4RSC6VSiyNqMUhQHrjdKQDjjI5wSOhNfjD/xGrftT/8AQg/s/wD/AII9X/8A
lnR/xGrftT/9CD+z/wD+CPV//lnQB+4P/DLvjr/oB/8Ak7b/APxyj/hl3x1/0A//ACdt/wD45X4f
f8Rq37U//Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+z/8A+CPV/wD5Z0AfuD/wy746/wCgH/5O2/8A
8co/4Zd8df8AQD/8nbf/AOOV+H3/ABGrftT/APQg/s//APgj1f8A+WdH/Eat+1P/ANCD+z//AOCP
V/8A5Z0AfuD/AMMu+Ov+gH/5O2//AMco/wCGXfHX/QD/APJ23/8Ajlfh9/xGrftT/wDQg/s//wDg
j1f/AOWdH/Eat+1P/wBCD+z/AP8Agj1f/wCWdAH7g/8ADLvjr/oB/wDk7b//AByj/hl3x1/0A/8A
ydt//jlfh9/xGrftT/8AQg/s/wD/AII9X/8AlnR/xGrftT/9CD+z/wD+CPV//lnQB+4P/DLvjr/o
B/8Ak7b/APxyj/hl3x1/0A//ACdt/wD45X4ff8Rq37U//Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+
z/8A+CPV/wD5Z0AfuD/wy746/wCgH/5O2/8A8co/4Zd8df8AQD/8nbf/AOOV+H3/ABGrftT/APQg
/s//APgj1f8A+WdH/Eat+1P/ANCD+z//AOCPV/8A5Z0AfuD/AMMu+Ov+gH/5O2//AMco/wCGXfHX
/QD/APJ23/8Ajlfh9/xGrftT/wDQg/s//wDgj1f/AOWdH/Eat+1P/wBCD+z/AP8Agj1f/wCWdAH7
g/8ADLvjr/oB/wDk7b//AByj/hl3x1/0A/8Aydt//jlfh9/xGrftT/8AQg/s/wD/AII9X/8AlnR/
xGrftT/9CD+z/wD+CPV//lnQB+4P/DLvjr/oB/8Ak7b/APxyj/hl3x1/0A//ACdt/wD45X4ff8Rq
37U//Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+z/8A+CPV/wD5Z0AfuD/wy746/wCgH/5O2/8A8cpH
/Zb8dOpB0Pr/ANPtv/8AHK/D/wD4jVv2p/8AoQf2f/8AwR6v/wDLOj/iNW/an/6EH9n/AP8ABHq/
/wAs6AP2lvf2E9a1O6ee58EaTcTyHLySGyd2PuS2TUX/AAwJqf8A0IWif982X/xVfi//AMRq37U/
/Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+z/8A+CPV/wD5Z0AftB/wwJqf/QhaJ/3zZf8AxVKn7A+q
RuGXwHoqspyCBZAg/wDfVfi9/wARq37U/wD0IP7P/wD4I9X/APlnR/xGrftT/wDQg/s//wDgj1f/
AOWdAH7dy/sn+NZ7fyn0ANHjBU3lsQR6Y31if8MCan/0IWif982X/wAVX4v/APEat+1P/wBCD+z/
AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7Qf8MCan/wBCFon/AHzZf/FUf8MCan/0IWif
982X/wAVX4v/APEat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7UaZ+w1r
ui3i3Fn4L0y0uE+7LC1nG6/Qhs1d1j9j3xb4gtzDfeGLe8hYgmOe4tZEJHsXIr8Sv+I1b9qf/oQf
2f8A/wAEer//ACzo/wCI1b9qf/oQf2f/APwR6v8A/LOgD9oP+GBNT/6ELRP++bL/AOKo/wCGBNT/
AOhC0T/vmy/+Kr8X/wDiNW/an/6EH9n/AP8ABHq//wAs6P8AiNW/an/6EH9n/wD8Eer/APyzoA/a
D/hgTU/+hC0T/vmy/wDiq0ND/Yw8T+GS/wDZ3hOysfM++Lea0iD/AF2uM1+J/wDxGrftT/8AQg/s
/wD/AII9X/8AlnR/xGrftT/9CD+z/wD+CPV//lnQB+1msfsTeI/EUqPqHhCwvnjGFa4ktJSo9izH
FU/+GBNT/wChC0T/AL5sv/iq/F//AIjVv2p/+hB/Z/8A/BHq/wD8s6P+I1b9qf8A6EH9n/8A8Eer
/wDyzoA/aD/hgTU/+hC0T/vmy/8AiqP+GBNT/wChC0T/AL5sv/iq/F//AIjVv2p/+hB/Z/8A/BHq
/wD8s6P+I1b9qf8A6EH9n/8A8Eer/wDyzoA/bfTf2RPGGjWK21p4bhtbdPuxxXNsiL9AHwKzb39h
PWtTunnufBGk3E8hy8khsndj7ktk1+LX/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A
/wCCPV//AJZ0AftB/wAMCan/ANCFon/fNl/8VR/wwJqf/QhaJ/3zZf8AxVfi/wD8Rq37U/8A0IP7
P/8A4I9X/wDlnR/xGrftT/8AQg/s/wD/AII9X/8AlnQB+0KfsD6pG4ZfAeiqynIIFkCD/wB9VtS/
sn+NZ7fyn0ANHjBU3lsQR6Y31+In/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCC
PV//AJZ0AftB/wAMCan/ANCFon/fNl/8VR/wwJqf/QhaJ/3zZf8AxVfi/wD8Rq37U/8A0IP7P/8A
4I9X/wDlnR/xGrftT/8AQg/s/wD/AII9X/8AlnQB+0H/AAwJqf8A0IWif982X/xVH/DAmp/9CFon
/fNl/wDFV+L/APxGrftT/wDQg/s//wDgj1f/AOWdH/Eat+1P/wBCD+z/AP8Agj1f/wCWdAH7Qf8A
DAmp/wDQhaJ/3zZf/FUf8MCan/0IWif982X/AMVX4v8A/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq3
7U//AEIP7P8A/wCCPV//AJZ0AftB/wAMCan/ANCFon/fNl/8VR/wwJqf/QhaJ/3zZf8AxVfi/wD8
Rq37U/8A0IP7P/8A4I9X/wDlnR/xGrftT/8AQg/s/wD/AII9X/8AlnQB+2+m/sieMNGsVtrTw3Da
26fdjiubZEX6APgVm3v7CetandPPc+CNJuJ5Dl5JDZO7H3JbJr8Wv+I1b9qf/oQf2f8A/wAEer//
ACzo/wCI1b9qf/oQf2f/APwR6v8A/LOgD9oP+GBNT/6ELRP++bL/AOKo/wCGBNT/AOhC0T/vmy/+
Kr8X/wDiNW/an/6EH9n/AP8ABHq//wAs6P8AiNW/an/6EH9n/wD8Eer/APyzoA/aD/hgTU/+hC0T
/vmy/wDiqP8AhgTU/wDoQtE/75sv/iq/F/8A4jVv2p/+hB/Z/wD/AAR6v/8ALOj/AIjVv2p/+hB/
Z/8A/BHq/wD8s6AP2g/4YE1P/oQtE/75sv8A4qj/AIYE1P8A6ELRP++bL/4qvxf/AOI1b9qf/oQf
2f8A/wAEer//ACzo/wCI1b9qf/oQf2f/APwR6v8A/LOgD9oP+GBNT/6ELRP++bL/AOKrQ0P9jDxP
4ZL/ANneE7Kx8z74t5rSIP8AXa4zX4n/APEat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/
AP4I9X/+WdAH7Wax+xN4j8RSo+oeELC+eMYVriS0lKj2LMcVT/4YE1P/AKELRP8Avmy/+Kr8X/8A
iNW/an/6EH9n/wD8Eer/APyzo/4jVv2p/wDoQf2f/wDwR6v/APLOgD9oP+GBNT/6ELRP++bL/wCK
o/4YE1P/AKELRP8Avmy/+Kr8X/8AiNW/an/6EH9n/wD8Eer/APyzo/4jVv2p/wDoQf2f/wDwR6v/
APLOgD9oP+GBNT/6ELRP++bL/wCKo/4YE1P/AKELRP8Avmy/+Kr8X/8AiNW/an/6EH9n/wD8Eer/
APyzo/4jVv2p/wDoQf2f/wDwR6v/APLOgD9oP+GBNT/6ELRP++bL/wCKo/4YE1P/AKELRP8Avmy/
+Kr8X/8AiNW/an/6EH9n/wD8Eer/APyzo/4jVv2p/wDoQf2f/wDwR6v/APLOgD9qNM/Ya13Rbxbi
z8F6ZaXCfdlhazjdfoQ2a2f+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/E
at+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrf
tT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/h
l3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDl
nQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A
5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+
OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCT
tv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4
I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A
+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A
8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAM
u+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1
P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9
CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1
/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+
4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f
8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H
3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A
/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/
APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV
/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf
/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov
+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0I
P7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z
/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBA
P/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8A
wy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq3
7U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Ea
t+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP
+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APln
QB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5
Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCO
V+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/
AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/
AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+
CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/yd
t/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+3Ov/AAG8
WeC/BfifU9T0r7NZW3h/VPMk+0wvt3WM6jhXJPJA4Hevb/il/wAgO5+g/mK/D/8A4J//APB0D8ff
+CiX7Tdn8HPGvhD4P6X4Y8YeH/EX2260TStRgv4vs2h395H5bzX0sYzJboDujbKlgMHBH7gfFL/k
B3P0H8xTQHxp+1r/AMicP+wlB/6Knoo/a1/5E4f9hKD/ANFT0U5bgdF/wdHf8oKPjn/3AP8A1IdM
r+cL/gjT4gsj8WfjB4MfULCz8RfFn4ReI/A/ha2u7kWqaxrN4kP2SyWVysKSStGVQzMqM21Qd7ID
/R7/AMHR3/KCj45/9wD/ANSHTK/ko+DXwa8U/tC/FDRfBfgrQ7/xH4o8Q3AtrDT7NN0k74LMSThU
RVVnd2IRERmYqqkjTDycasXFXd9u5lWipU3Fux9qfsjeH1/ZR/4J0fE3xt8b/CL/ABC+F2pfEOHw
BD8Lb8z6Xe2nim0gjvJ9Se82ibTHhtPMtz9nDyTmVop0RI0Y/WOu/AvxLq/7Pn7X3jbw98L5vix4
X+Mmi/DzxD4D8PxeGri0t4dLMoeHRmt9JdHW602ykssx21x/qkhmlBWbZX5LeJv2V/HXhL4L3vxF
u9Ht5PA1h4sl8Dya3Z6naXlnLq8UH2h7eJ4ZXEy+ThxNHuiZWUq5yM+j6b/wSp+N2pfDeLxe2geF
NP8ADj6Tp2vSXup+OtA05bSw1BQ1jczrPeo0Ec+QsZlC7nBQfOCo76OIqxiqSptpffqpeXntqtHp
qznq0ouTnz2/qPn5fiuyP0Mls7b9lP8A4J8/FTw98cfAGm+BPh98W/2lJfDPirwvp12puvAmnXej
2mrwXVndWIeGU2WbCaKJLdo3W3ljaM+cBF5h+1z8PtR8b/8ABzZdX2kx+Zpfg/xN4Z8XeINSuZ4r
a00TS7Gx0y5vb65nZkiihiRWJcsoLFFUs7oG+JP2iP8AgnZ8ZP2UPCer674/8GSaBpOheJIfCF7c
nU7O6SLVZdOj1JLYeTM5cmzmilLKCi7wpYN8tRah/wAE+fi/pv7SfiD4Pv4RMnxM8NWEmpXnh6DV
LKe7liS1W8ZLYJMVu5vs7iQQW5klIDYQlGA1liqiiqcqT92Sa77yfLt1b006Oy10iNKF3UU1qvls
td/Trs15GR+258RNH+L37Z/xd8WeHbz+0fD/AIo8a6zq+mXXlPD9ptbi+mlik2SKrruR1O1lDDOC
AeK+i/8Ag3f8Najr3/BWv4bXNlYXl3baPa6xd38sNuZY7OFtKu4FeY/dSNppoYtzEAvMighmWviW
vW/gZ+w98RP2jfhf4h8aeFrXwrJ4Z8JXEVtrV9qnjHRtGXS2lKLC0y3t1C6RyO4RJCNjuGRWLKyj
hwtaSxMa6jzNPmsvJ38zoq04qi6bdla139x2n7P/AOy34f8Ahn4V1T4qfHqz1Gx8EeFdeu/DNt4N
iuhYeIPGXiC0iikn0rYf31lbW4uLdry6dAY1mWOINPIoT6R8V+JvHX/BRb/gkH4juvD2h2/inx5N
8erfULjwV4F8NBpfDmjweF47GydbW1VpYrBEiS1g3jaDav8API7Oa+TP2if+Cc/xl/ZP8Har4g+I
Hg1tA0fRPEsXg+9uf7UsroQ6rJp0WppbYhmdmJs54pd6goN4UsHyo0tO/wCCXXx11T49+KPhnH4H
CeMPBZsE1uCbWtOhs9PkvjCtlC1684tTNcNcRJFEspkkdiqqWVgLh7WHuODtezVtbtNLpvvZevmR
J05e/wAy9eltH39L/I9A/wCC9+v6b4k/4K4/GS40rUbLVLWO9sLV5rV0eNJ4dNtIZ4SV43xTJJG4
6h42DfMDUv7JXwa0j9tv9hLU/gt4C0fwxdftF2Xj0eLtNj1C2stOv/EOhDT1tprCy1KVlaR4pc3T
2crxoIonljMjiRV8i+Fv/BP34qfF/wAHeL9e0vR9B0/Tfh/qA0vxM2v+K9J8PzaBcF1jVLqG/uYZ
IQ0reUrOoVpFdAS6Mou6t/wTb+MXh3wv8R9X1Tw3pOkWvwjums/Fkeo+J9Ks7vSX2I8TfZ5blZpY
5w6i3kiR47onbA0rAiiSnKs67puzb09b6Xt0V+nS/QaUY01SjJXil+m6Ps39hT4U/DT4h/8ABZj4
c+BPB3h3wh8TPB2h+AoNC8fynw1Y6t4ZutTstI8q5vrV5bb/AI9pNRitf9NYLLNLNIEkaKdFfzT9
ij4B+J9E/wCCb37T/irUPhNDe+KPg9rOl3Ph+/1rwHa6hJpd+szW2uWs4urWTz1t7GRJZbWffFan
bceXHJtlHyV+zL+y543/AGw/irB4I+Hel2eueKru3lubbT5tWs9Oe6SJd0gia6ljWR1TLlFJfYjt
jajETeKP2S/HvhD4FXfxNu9IspPAVl4wn8BvrVnrFle20msQ24uXt4/Jmcyp5LB1njDQOCNsjZrT
6y+RS5HvN3XmlotH8Nr/AOW5Pskm48y2jv69deu3+Z9n/wDBJj9qLVfiF8Zf2jNO0Hwj8NtB1Lxx
8LfFmoaF4Y0XwjZXB1DV2trd1sLOO4Sa5ngcQPINNDyW3yybYAoIHXfs3fsvaRcfs56RH418G+AN
V+Jngf8Aan068+JsFjpWl3UXhjwsbCOW6a+ls0aC20dZlulljJW1ga3kUqhVlHx74o/4Jb/G/wAB
a74ksfEnhbR/Ci+EtSg0bUr/AF/xZo+k6Wt/NaJeJZxXtzdR21xcC2kjlaKGR3jWRC4XcM+S/Gj4
L+Kv2dvinrfgnxtol74c8U+HLk2uoafdKBJC+AwIIJV0ZSrpIhKOjq6sysCX9Yq04x9rB+63vtr0
tbR3X56CdKE2+SS1S9dOu+x+rX7Pf7GPhH4eftP/ABo8S6n4Q0XW4dO+O8+h6x4Jv9B0Cw0zwN4P
RbjUk1+7fVbC5Nvpk1sXjjW3NlvWBQlw7yQBPJP+CdPwWtv2ff8Ag5YtvBNtoWoeGdI8O+L/ABPb
aTp135glt7AafqLWWGmJd0a3MLK5ZjIjKwZtwJ+F/wBmj9l/xr+1/wDFO38E/D3TLLWvFN5BJcW1
hPq1npz3Sxjc6xNdSxLI4XLeWhL7VdsbUYje8DfsMfEn4heGtd16w07w5beGPD2tt4bufEOqeLNI
0vQp9SVGkNrbahdXMdrdyCNfMxbyyfu2R/uOjNrTxjTp1I0tp8yfezvbb0/yJlQS5k57xs/yT39f
8z3v/ghp8F5vEX/BVHQPBXjH4eW/iTSraDVrTxboeveFoNT/ALNWC2lI8+G6hf7K6XsdtGZMI4Z/
K3DzGRtj9gb4Yun7MnjrRo/g94qu/iTo/jmC01LXtM+HGjfEnVtOtktJ1Okz+HtSkjm09ROkkhvl
UiR0MDbTCA3xv8aPgv4q/Z2+Ket+CfG2iXvhzxT4cuTa6hp90oEkL4DAgglXRlKukiEo6OrqzKwJ
6P8AZt/ZA+In7XOr6lZ+APD66udHFt9tuLnULXTbO1e5uEtraJrm6kihEs00ixxRb98rZCK2Djnp
VmuSjGD5ouXXV3SVtrq1vxexrOnGSc3LRpemnX8T9PP2e/2OfAvgn9pT4peJLyL4V+Ol0v40weGP
FXhjRPD+kWfhvwX4fgtZNQvNcuTrdtfSWNn8t3byWsEtsEmtZIorqTFuF4D9jOyvf2Z/26f20Pgz
4e8L6JpynwX43g8FeH7/AMP2l/quqyb4ZNNtLd7uJ7u/iktI45ktWaWOeMGXy3yXr4g+Gn/BPn4q
/Fbwd4t17T9H8P6Zp/gHUzo/iUeIfFmkeH7jQLresYS6gv7qCaANI3lqzoFeRJI1JeN1VPB3/BPT
4weOf2pdW+Cln4RFt8UdGMouNA1LVrHTJ5DGFdhC9zNHHcZjYSp5Lv5kWZU3RguOqji6keSUKTvz
O2/W6stP13W25g6UNVKa2X4W13/q59G/8Ee/gRrXiD/gssvgX4gfDzwx4mFrc65aeONEufDem6np
WltDHNuOxIZLa0SO/W3jWS3CKu8RIwWTYz/2b/gBqmjf8Ex/FV/8PvhlD4w/aQ0j4w/8I94m0W88
DweKtX0DQY9JkMe/Tru1uPsqtf8A2lHlEaOZIFRm+QAfKXwv/ZF8d/GTV/F1t4fsNFubTwGA2vav
c+ItOstD00NcC3jLalPOlmfNlIWLbMfN5Me8Akc58aPgv4q/Z2+Ket+CfG2iXvhzxT4cuTa6hp90
oEkL4DAgglXRlKukiEo6OrqzKwJ5VXlCnFuD0ctf8SSte3SzfrfQ3cE5tcyu0tPT57an6Q/Hz4bf
Cf4O6Z+3LJ8MPDPgi60n4I674WufB02peH7PVpNJv72RdO1a2Zr6GR7iAMblFt5/MhikjWWNVkVZ
a+R/+CvHwT8Hfs5/8FGvif4L8A6XcaL4U0K8to7OymE4MDPZW8kwXzgHKGZ5Ch5UoVKFkKsfMP2Y
/wBlnxx+2N8U4vBPw70uy1zxTc20t1b6fPq9np0l2kQDSCI3UsSyuq5cxoS+xHfbtRyOn+Gn/BP7
4mfF7wd4t8RaBB4HudB8CamdJ17UZ/H2gWlrpsxdUjkeSa9RTbyuwSK5UmCZgyxyOVYB1ajq0+Wn
Tsm7q2ytzNpadmr/AOFfKacI05az2Wt/lZv7n959n/8ABHH4UaXqP7OXgDxZ4I8K6P4v+LMX7Reg
6Z4pD+HoNevdA8Ii1WUXe2WGb7BA1ybjN5Esbq0C/vBsXEX7H37PEnir/g4r+IHgzxR4Cn8R+GJ/
Evim71uw8SeHV1l001vtNzZ3cv2qOQx+bK1iUuSQX+0IN7LMQ/yAf+CbPxnsZPEx1jwla+ErTwjr
Q8OalqHinXtN8O6cNRMPni1hu764hguJTBtmCwO+YpI5PuSIzeZ/Gj4L+Kv2dvinrfgnxtol74c8
U+HLk2uoafdKBJC+AwIIJV0ZSrpIhKOjq6sysCdaWLnQjTVSm/3cr9urvHbS/X02FKkpVJOM9Wvm
vPc+xP2C/hPcRfs5+O9H/wCFQ+LLn4jaH44gstR1nTPhto/xH1fTYUtLlH0q48P6lLHNYKJleQ3i
oRI6NC2GiUV9L/s3fsY+A/h5+0h8UdbubT4bfEGHQfjHH4Y8V+GtD0DS4PDngrw9a2kl9ea7dvrl
tfzWlp8t3bvbwS24EtpLHFdyf6Pt/HyisKOOUFC8b8r79NdNvPXe5dTDOd/e3Vj9Yfg7+zj46+AX
wo/4KE6H8NPhfrd3aweMdH0bwbpV54NPiOHUYLbWpJhBFb3sE63fl6dc21wSyuyxy28xI3Rucv8A
Zl+G3gzwL/wdBW/hn4dWmnWfhjTtW1SCOzsd0dvZXI8P3JvYEDZ2CO6+0JsUbUKFUAUKK/LKitoZ
lCE6c4Q+CSkte0m7KyVr3V99lstBfVmr2erVvwSu9ddv+Cfo3+wl+zdoj/8ABOrxpd23hbWtR+N+
mfFdNB13TNM+Elj8Q/EehaRFpjtGJNM1CRFs4JLw3KPOgR/MtljbeMBPor4Q/B7wFo/xvv8AWfg3
8LdPt/Gdl+1FoWj+JdAn8M6d4h1PwP4aisY3un2xPfQafD/aDX3+kWjx7DagB4/KSKL8WqKyoY5U
+S0fhb6663+7f52XYKmFc3JuWj/4H+R7d/wUs8O6j4Y/4KGfG+31Sw1DTrmfxxq96kV7E8czwXF5
LPBL8wBZJIZI5FfGHSRWGQwNeI0UVxVZqc5SirJt6djqirJIKKKKzGFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQB9j/APBAr/lKZ4I/7F/xb/6i+rV/W/8AFL/kB3P0H8xX8kH/AAQK/wCU
pngj/sX/ABb/AOovq1f1v/FL/kB3P0H8xTQHxp+1r/yJw/7CUH/oqeij9rX/AJE4f9hKD/0VPRTl
uB0X/B0d/wAoKPjn/wBwD/1IdMr+bz/gjz4j05Pih8YfB01/ZWfiP4rfCXxB4J8KQXc6W0WqazeC
D7NZ+dIVjieXy3RGkdFZyiFvnCt/SH/wdHf8oKPjn/3AP/Uh0yv5Kvgv8F/FX7RPxT0TwT4J0S98
R+KfEdyLXT9PtVBkmfBYkkkKiKoZ3kchERGdmVVJGmGm4VYySvqtO5nVScGm7I+yP2Q9Dtv2Vv2A
/in4x+OPhK78ffDPUPHMPgKH4X3NxJpV5beK7WJLqTUZ7kr5+mNBaefBmFTJcNK8MiiONjX2Z4t+
GfxA8Tfs4ftVeJ9O8Fah8ZfBHxR8MfDrXPh14Sl0DU7W2t9DN5LNa6JHa6VJCiSabbzIzpaTEfdl
Y/v5lr8ivE/7Jvjzwj8C7z4mXekWUngOy8XzeBH1qz1eyvbaTWIbcXL28Rhlcyp5JDieMNC4I2yN
kV3nh7/glt8a/Efw3m8XL4f8Nab4cttO0/WLi91jxroekrbWWoRxyWNzIt1eRtHDP5qrG7AK0gkj
B8yN0X0KGJnGHs4021/wJLs9NdF0auupy1qcG3PmS/pefl66rsj9E9Xn0z9lb/gnf8VvCHxn+HOk
+APC/wAWP2lZtB8XeG7C8ikl8CaRfaNZavZz2d1p6uJGsm+yTRxeU8TrBJEIQZJAnmf7bfw61rxz
/wAHNupXdpbrPY+DfEHhnxZ4hvyyW1poukafpul3N5e3EsriOKKKGMks7gM21RlnVT8RftD/APBO
f4y/speCdU8R+P8Awa3h/RtF8Tp4NvLg6pZXPk6s+nRakttthmdmzZzxS+YoMfz7d24FRW1D/gn9
8XdM/aN8RfCKTwlu+JXhexfULzw9FqllNeTRrbpclLVUmIvJ/JkWQQWxklZQ5CHY+3aWKqtRpKk/
dkvW6cvdei31tpo09N7RToQUvaRmtU/yjrv5Lr1Wpjfto+PtI+K37YvxY8UaBfnVdB8SeMtY1XTb
0xSQm8tp76aWKXZIA67kZW2uAwzggHNfYf8AwSk+H/ivXP8AgmX+15PpPwo1D4p2msyeErSy0ZrD
VZ7XW7m21NpJoU+wSwzSSQRXEc7LFIGQeWW/dswf88aK8uGItVdWS3v+PyZ11KXNDkT7fh6WP2Z1
k6b+yp/wTm+KfhX40fD7SfAPhb4t/tLz+H/FnhewvoZJfAekXmjWOr2lzZXOnowkayY2cqR+XJEy
27xeSplcDtP+C4b+DNC/Zy+Lmo+PtG8QeJbG5/aG023jsPD+sW2i3VvKvgDSWSVrqayuy8ZV5FMZ
QZYB1KYdX/DKtnRPhz4h8TeEtc1/TdB1nUNB8MiA6xqVtZSy2mkieTy4DcSqpSLzJPkTeRubgZPF
d/8AaTdP2UYd7bN2tLfSzXvX2017nP8AU7T53Lyf/ku2t18P/BP27/as+H3izXviF/wUUm074S3P
xRi1u4+HkNlozabrE1rrdzbQWclxDELKaCd5IIrqK4cRvuRTGWxHIQ/HftdfCLxl8W4f+ClFt4M0
3xT8To/E2s+B7CxvNJ0t7w3V7Zz2815p0K2kex5bBJRFJGQZokjUytvLs/4uV2h/Z68Xj9nZfiv/
AGUh8BN4jPhP+0he25ZdTFsLryDBv88AwncJDH5ZwwDFlIFVszVZy9x+829+/P5dOZ79ul2EcJy2
fNskv/SfPy/HW9j7l/4I8fsm+O/2Vf8AgvF4E8DeKNJ2+I/BtndX2vR2W68h0mO70CWRRLLGCg2t
eQwlwTH5rgK7hlZu7/ZH8eaP8A/+CFureCfi7ol7B4H8b/tGXHgbxva3QnsNS8MRf2NYTyX0QjRp
VurS5sreUxSQyK4tniMZLtt/Nz4/fALxZ+y98XdZ8B+OdMj0bxV4feOPULJL2C8Fu0kSSqvmwO8b
HZIpIVjtJIOCCBJ+zx+zx4x/at+MWj+AfAOj/wBveLde877BYfa4LXz/ACYJJ5P3kzpGuIopG+Zh
nbgZJAONHFSpNUoQ1TlZPV+8krNW1emu17tWQ6lGM06k5aNR1/wu973/AOG7n7N/8FlPh5rH7S3w
p+Kvgfw5pvinxRqml/tG6Rq2u6P4U0U67rOj6VJ4G0y3TURZRMshRzHKqGV44pHh2q6kSFfyd/4K
PfDTU/g5+2x4+8La18Sb74u6xoN3DZ33iq9leS51CdbaESRyF5pnDwNm3KtIWUwFSFIKL4jRUYzG
xr3fLZt3385PayXXfy8zTD4d0ko30Stt5Jfofa//AAbyeFtT8Sf8FavhpLp1pfzxaXb6vdXtxbwu
66fC2lXcImkZSNiebNEm5iAWkReSwU9Z4M+EHjD4q/8ABCnVfhb4Z8JeLPEXxI8HftEz6jrfhXTN
Oku9X0e3bw+tqZrixiDXMKieCSIvLGqb0KKdyuB+flFRDFpUo0mtnJ7/AMyS7eQ50ZOTkn26dm33
P0F/4LS/E34M6z/wVL+NEviPwv438XanHqdlaC/8N+O7DTbKIQaRp9u8DRPpl4TNFcQ3KyHzgQcR
mON4nLadn4n+FsX/AAQZmub3wT8Q5vBMn7RMwsNOi8Y2UGpRTf8ACMWmS98dMeOdRtmyn2SPb58O
HO2TzPznopyx0nVlUstebout+ttdxU8Mo04077JL7rf5H7g/trfD2fV/FP8AwUn1/XfAHj7XvB0z
eB4CmiS/YpL17GGzubkx3nkXcKi3heG6mDRsUgdS6wlgU+cf+CYv7Quv/wDBQj/g4g0b4tyeGDpC
6pLqWpXtppkc13DodnHo01jbvNLj+8bZGmYIjTSjCIHWMfmZXp/7M37GnxJ/bC1TVLX4e+G/7a/s
X7Kt9c3GoWum2dtJdXCW1rC1xdSRQ+fPO6xxQ7/MlbcEVtrY6o5jOeJjUhFu0ua27bu5b26Xttbr
YxeGjCk1KVtLX7aJd7dD6l+G3gnXvjZ/wRl8U/Afwp4a17WfjL8OvjdJ4z8QeELfTZDrdvpT6TDp
RmW2IE0phvQYpo40Z4fNVnCKS1fIP7Rfw48V/B34x6v4S8cXcV34q8MCDStQWPVY9UFi0EEcS2fn
xu6E26KsBRWIiMJj42YGv8Kv2OfiP8Y7/wAYQaT4eWxT4ehf+Enu9f1G10Cy8Pu9wLZIbq5v5YYY
ZnmJRYncSMyPhTsbDviX+xr8R/g/8Otd8WeIvD8Wn6F4a8a3Xw81KcapZzPa65bRGWa0MUcrSMFQ
E+cqmFsELISMVwyjKdNNQenXpa78vxv0OiDSm1zL069PM+jP+DdrwvqHiD/grl8Mbmz029v7XRYt
VvdQlggkkjsITpl1Cs0rKD5aedNCgZsKXlRc5YV6J/wSu8N+H/gP+w9+1lrnx1+FvivxJ8OtM1fw
poOv6MRd6TO9zDqzJcwrKDGRc2hngla3MiMWaJHKLJvHwR8aPg54g/Z9+Ket+CvFVvZWfiTw5cmz
1K2tdSttQjtZwAXiM1tJJEXQna6hyUdWRgrKyjl61p4r2UI05R1i5PXvJJaq3S2q67MiVH2jclLS
SW3k29Hfrc/ZX9tX9n/4qftWfsl/Gz4b3tvYeJ/jZ4f/AGhr3xVrMGi2GWfQ4vBhfTJFtLVriaJZ
4rdYIPNLF7idI3meUyuLH7XKaN8Z/wBoz9oq/wDB3wd1LWPFtp8SNMs7/wAWeH/Bfh/4qanBbRaF
FBLpsugXVyTYxfbIZ5hfooMkhe2l8uSAxD8Yq9O8O+Bfil+3B4y8beIVudZ8feIfDXh258WeJNT1
fWVlvV0yxjjSWd5bqUPN5UZiUIpZ9oAVSF43jjVJcqg2277/AOLyvdcz1MnheV3bVrfLp0v5f8Ob
n/BRvwSvw2/bs+K2gLp3grSRo/iO6tPs3hGMw6MpR8FoIDcXJtt5G97bzmFvIzwgIIxGvitei+EP
2UvHPj79nTxb8V9H0zT77wP4Eu7ez1+7TWbEXWlvcSRRQGSzMwuvLkklVUkERRisoDExSbPOq86r
dy57WT1Xpf8ApHXTso8t720f3BRXS/B34Ra98evidovg3wvbWl74i8RXIs9Otri/t7FbqdgdkQln
dIw7kbUUsC7sqKCzKpo/EDwJqvwt8e634Y121Fjrnhy/n0vUbYSpL9nuIJGilTehZG2urDcpKnGQ
SOajkly81tO5d1exkUUUVIwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
+x/+CBX/AClM8Ef9i/4t/wDUX1av63/il/yA7n6D+Yr+SD/ggV/ylM8Ef9i/4t/9RfVq/pK/be8U
yaR+0itsdcnsIT4YtJBbn4vJ4YiLG7vAXGmhC7MQADck7XCqgGYWoQHE/ta/8icP+wlB/wCip6Kh
/acnF18JNFkEon3zW58waidR3/Ldc/aCB5v+9j27UU5bgdR/wdHf8oKPjn/3AP8A1IdMr+cL/gjZ
r2lN8UvjL4OutSsrLxD8VfhB4i8FeE7a7uEtodY1u7WD7JZGaQrFG8pjYIZXRTIEUNvZFP8AR7/w
dHf8oKPjn/3AP/Uh0yv5J/g78HvE37QHxO0XwZ4N0e71/wATeIbkWthY2+A0zkEklmIVEVQzvI5V
ERWZmVVJG2Fm4VYyiru+3f8A4PbzM60OaDjex9sfsg2R/Zd/4Jv/ABI8XfHPwzf/ABE+EF58Q08E
2fwpurmfSp7Xxfb28VzPqcl0U83TWisRJbt9m3S3DMsU6rHGjV9X+Lvg5498S/Aj9rPxpo/w31D4
q+BPiz4f+Hus/Dzw8fDVzb27aQZhNbaLHb6TMjxSaZayw747eYZEMM0gKz4b8lvEv7Kvjnwn8FL7
4jXWlWUvgfTvFsvgaXWLPV7K9tn1eOA3DQRmGVzKnkjes8YaFgRtkORXaeDf+Ca/xf8AHPgvWPEV
po3hiz0Xw/aaZqGp3ereNNE0pNPttStre6sJ5ftV3GUjnjuoQjsApcvHnzI3ReylXqKKpqDaX37S
8ttXpto7bs5KlKHO6jmk/P5ef476rsj9JtRurX9lj/gmZ8RfCXxt+Hln4H8D/FP9py60Txd4e0zV
RK3g3S7/AEPTtWtp7CSxD2/mWW2ynRUhdJlh8lowCFXyn9sL4aa146/4Oab24tLBjp/gzxF4a8V+
IbyW4igt9G0fT9P0y5u7+6uJGWKKOOFCzO7AF2VRlnVT8P8A7QH/AAT3+MH7LfhHWNd8eeEDoWla
B4mj8H3851SyufI1WSwTUUttsMzs2bWRJN6gxjdtLbsrUUv7AXxbh/aJ8Q/CU+Ei3xJ8MWEmo3nh
5NTs2vZo0t0uWjtlE2LufyXDiC2MkzANtQ7Gx0SxtW0aLpvSSa77yaW3m+ney10UaUU3UU1qn+S1
38vutrprl/tsfELR/i3+2X8XPFfh6+Op6B4n8aaxq2mXhheE3dtPfTSxS7HVWXcjqdrKpGcEA8V5
jRXrPwL/AGJPiH+0f8NvEfjDwraeF5PDXhCaGDW77VfF2kaLHpZmZVhaYXt1CyJI7BEcjY7gqpLK
QPIfNVm2ldvXQ7fdpxSbskZPwn8S/CjR/Dc0XjnwX8Q/EesNcs8V1oXjSz0W2SDYgWNoZtKu2Zww
kJcSgEMo2AqWb27/AIJ722s/8NRa/wCNvhncr8OPhL4W0wnx1f8Ajm6TXtIttAnCQ3NhqSxQWy6l
9sfMcNlFCksshjEe14vPTybw3+w58VPFf7VzfA+z8I3I+KS3U9n/AGHc3dtas0kMD3D4mlkWBkMM
bSI4kKSKVKMwdc+T1tTqVKTjOUdE+1tV0vv111IlCM7pPf56eh2f7RGt+B/Enx08V3/w00TWfDfg
G71OaXQdM1W7F1eWVoWOxJHGe3RS0jICFMsxUyv9gfC/wZrnx5/4IATeCvA+i3/jLxZpH7QTa3ea
LoMUmparaWMvhxYUuprSFWkit2ljZEmI2u6yLnKc/H3wd/Z+8XfH7/hKv+ES0j+1h4J8PXfivWj9
qhtxZaZa7PPuP3rrv2+Yg2JudiwCqaPgd+z94u/aP8XXOieDtI/tS80/T7jVr6WW6hsrPTLKBd01
1dXU7pBbwICAZJnRNzoudzKCqKnzqXK3zXVl1vppowmouPLfa34dz9ev21dJ0v4t/tOftGX3hn4Z
N4o8WWPxF0qyufGHg7wfoXxavorSHw9BA2lz6FfTRyWCJcRyu17HGVe4E1s7s1steH/sdfsz2Lf8
HEWv/Du78IfCPxx4Vt7vV11yy0Lw3HqPha2hFg8qyC3uWuBYMt59nSRElxbzs9sjbMRt+c/xg+D/
AIm+APxO1rwZ4y0W98PeJ/Dty1pqFhdKBJBIMEcglWRlIZXUlXVlZSVYE83XdLMV7RTqU7tT5nr5
t2ennr6HPDCOMOWMtOW23la+/wCB9sfsg+HT4E/4J+ftSajr3g3wqvjr4Jav4evtGPiPwZp97f6P
e3l++l38FwLuBnlTyht+y3SyQxSgypHHOBJX0r+3N8K/g78AfEvxz8J+EPCHwD8JfEay+Ktldavp
/im4ils4fBVx4fiuXWzW5VZYg13JPI0eiAahGZVihCiO1z+SVeofCL9sj4hfBL4cXvg3RtU0m+8H
3+pLrMmg+IPD+neIdLjv1iMP2yK11CCeKG4MR8tpY1V3RVViQqgc9HFxjFQlHT/9r/NdVst+mk8O
3Jyv+nb/ACf39D1b/gtb4D0v4Y/8FPfipoGieFfDfgrSNLubGGz0jQUVLC3i/s61KuirFEqtKD5r
qE+WSVxufG9um/Yak023/wCCbH7S/im48N+CdV8SfCi98Na14XvtW8Kabqc1lPqF62nXayNcQubm
BrcgLbXAkgjk/fRokwEleHPofxa/4KF/FX4i+NZ3v/HXirTNFvfG3irULq7gheDT7RUE04Dsi+XE
jRokMI+VAiRx7VCjlv2fv2fvF37Uvxd0jwJ4E0j+3fFeu+d9hsftUNqbjyoZJ5AJJnSMERxOcFhn
GBkkAzOUpYh1KcX7zfL312tbqr9Oo1BeyVOT2Sv8vXv5n67/AB5/ZI+G3w9t/jvF8Ofhpp1p4+03
4yW1ibHwd8PLH4p6lYeH5vD0N3Bt0fUmjisbSa6e4lM8IAWQm3UvFChWrbfsY/Ar9qjwb8Q9D1/w
f4B+B2h+Dvj5d3PjS9svE2gW+ueDdFfw5HBBFJdlpoYLWbWgALSJpIop5p4Y1U25ZfxgorojmULp
ypp6ttd9/LTfpa9l2Vs/qktbS6f5efl959Cf8FMvhofgf+0ZpfgO68K6N4S13wV4K8NaXr1rp3lE
XGp/2PazXU0piJieYyysruhYOU3lmZmJ96+FXirwbpX/AAb5Nb+O/D3ibxDoyftDSSW9voXiGLRb
kXDeG4hvaWeyu42jVEIKLGGJkUllCgP8A0VyfWUq0qsVvfTTS/y6ehvKlzQUJPt5bH7O/wDBXxdf
/ax+HP7QPws8I6JD4l+JXg743af47u/DugzT6jqbeHpPC2n6XDfxQtEjTqZRb+cluJGgaX5sxKkz
Uv2aPHNr+wf/AME6n0f42zWd9rXhb47Podp4qgm/4SVPhnrzeDrSGzvzbHdBfPpHleS1srMI3iYx
7mgt935Rfs9/s9+L/wBqn4waP4C8B6SNd8Wa+ZhYWJu4LTzzFDJPIPMndI1xHE5+ZhnGBkkA8ZXa
8yn7VYrl1fN6Nu77brm7/dc5/qkeT2N9NPXou/k+h6R+2B8GfG37Pn7T/jnwh8Rrt9R8b6Pq0w1i
/e7e7OpzSHzftfnSYkkE6yLKGkAciQFgGyB9x/8ABMvwj+zj4R/4JyweMvjz4I8Mahofiv4xy+Dv
EPiS/t9RuNQ07TIfD7ahapZG0YS27/b0jV3gy0kdy6yqUWMr+alenfCL9jvx/wDG74dX3jDRtN0e
y8I6dqceiy65r/iHTfD2mvfPE8wtY7i/ngjlmESF2jjZmRShYAOueTCVZQre0hHmeum/3913Nq0E
6XLKVttVofqB4j8CfDf4lfs3ax4v8D/Cbw5oHxV1PWPCd5rdj8P/AISWPxBuLbTr/wAG2Wp5j0TU
JhbadZG7uLkfaIcO7wKrlyCw479l34twaF/wUB/bL8C+Avh/4T+Hv9qeAvFsHhzwW+i6RrGo3OtQ
xWytpsJWO4M6ytb3Ep0qGWW1Q71WN1iGfzF+Lvwj8S/Ab4laz4P8YaPd6B4l0C4Nrf2NyBvhcAEE
EEq6MpVldSUdWVlLKwJ7j4TfsO/Eb40/Buf4haPY+GrLwTba0fDrazr3i3SNAtW1EQLcG1Vr+6h3
yeSwfC54z6HHZDHz54qMNYtuy+em2m+tt+q0VueWEiovnlpa2vy7+a2fyPr79mPQPiN+zb+wd+3h
4h13w3oOna7o2veGtH1CK78NaVqWgDUo9bdb20jtzFJpzNAZ4j5UUZSHfEVCYjr179rf9n3TPAfh
L47j9n74G+EtT+Kel/Gy206/0ey8Ep4uu9H8PvoKzK0WmahaTLZ2cuoG5dZoIVjYkRpJJBHbmvz3
8Nf8E7/ij4r8Car4qtbbwNF4U0bXm8MT67e+P/D9lpUmpCBbg20N1NepDcN5Lq+YXcEbsH5WxPqv
/BNP4z+GL/xRDr3hWw8KReDtWi0HVL3xH4j0vRNPj1CS3N0lpFdXdxFBPMbfEuyF3YI6MQA6kqnX
q+zjCNNtd9b/AGr2dtN9f8I3Ti5Pmkr+n+HfXy/H7/1B8EfCjwJof7SniHUfgL8LfBl54p0H9qjR
tF8Qw6ZoI1y58NeHIrSL7TIkN5bMdKthqUd832q2SFY3UokpiggI/Lf/AIKX6NqWh/8ABRH45R6t
p95pl5ceO9ZvfIuYHgcxT3ss0UgVwDseORHU9GV1IyCDWP8AGD9h/wCKnwB8E614i8Y+ELvQNH8P
eK28E309xc2+Y9WFsLvyFRZC8iG3KyrMitCyOhVyHXNPx9+x78R/hh8GbX4ha74bex8HXt/ZaZBq
X222lWW5vNMh1W3jCJIXy1lPFKTtwm/YxVwUGeKxNSrT9n7O1m3+fTZW1+7pY1pUYwnzJrZLz/M8
0orr/j18BvFn7Mfxb1nwJ450htC8V+H5Eiv7FriK4MDPGkq/vImeNgUdGyrEc1yFea007M6U01dB
RXpn7Nf7HnxG/a81bVLP4f8Ah0a02irbG9nn1C1061t3ubhLa2hM91JHF5088iRxQhjJKxIRW2tg
+GX7HvxF+LGt+L7DT/D6aZJ8P8DxNN4h1K08PWmgSG4FssN1cX8sEUMzTExrC7iRmR8KdjYtUajS
ai9dtCXUirpvY8zor3zTf+CZPxmvpvHkdx4e0DQ2+GOoR6Z4o/t3xfo2jDR5ZSogaQ3d3EDDNuXy
p1zFNn9271leDP8Agnx8XvHn7UWsfBax8JpB8T9D8/7VoOo6vY6bM/kqHfyXuJo45/3Z81fJd98I
Mq7o1LilhqztaL1dtnv29dBOrBXvJaeZ4xRV3xLoE/hTxHqGl3UllLc6bcyWsz2d5De2zujFWMc8
LPFKhIO2SNmRhgqxBBr0v4IfsT/EH9oj4aa94x8L23hZ/DXha5itNYvtU8YaPoy6Y8u0RNMt5dQs
kcjNsSRgEdwyKxZWURCnOT5YptlOUUrt6Hk9Fer/ABf/AGH/AIqfAPwHq3ibxj4Qu9A0XRPFb+Cb
2a5ubffFqy2q3fkCMSGRka3dJVmVTC6upV2yK4Px98Oda+F+s2un69YPp93e6bY6vBGzq/mWl7ax
XdtKCpIw8E0b4zkbsMAwIBOlOHxpr+v+A/uHdGJRXtH7OP8AwT5+K37Weiabf+A9D0XVk1rVLrRd
Nt7nxRpWm3mp3drBBcXMVvbXVzFNN5UNzA7tGjKqyAkjBxg+A/2RfHvxU/aEsPhZ4X0zS/EnjXVd
32K10rXdPvbS8227XDeXeRztavtjR87ZThkZD84K1f1erZS5XZuy0er7Luxc8btX2PNaKKKxKCii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigD7H/4IFf8AKUzwR/2L/i3/ANRfVq/rS+LHhrTLpbjUZtL0yfUBCkAupbOO
Sby1csE3spO0F3IGcAsfU1/Jb/wQK/5SmeCP+xf8W/8AqL6tX9b/AMUv+QHc/QfzFNAfHH7Xty9z
4Oj3bcR6hAihVChR5VxwAOO9FR/ta/8AInD/ALCUH/oqeiiW4HRf8HR3/KCj45/9wD/1IdMr+cT/
AIIz+JdNj+Kvxk8FzXVnD4l+Lfwh8ReBvCNtczx26aprd6sH2W0E0pWKJ5fLdEMjqGcqgJZ1U/0d
/wDB0d/ygo+Of/cA/wDUh0yv5Kvgv8F/FX7RPxT0TwT4J0S98R+KfEdyLXT9PtVBkmfBYkkkKiKo
Z3kchERGdmVVJG+FqOnVjKKu+3foZV4KVNpux9qfsg6ZD+yl/wAE7fiZ4v8Ajr4YuPiJ8LL/AMfr
4EtfhNeXk+k3lj4ttYoLufVZZ9om0xorMS2xa3DSzs7QzKkaBq+rPEHgjxj8RPgn+1r4r0PwRdfG
vwd488OfD+98B+FBoeoW9ppekPcreW2gLbaXJEUm060ubeR4rOfbgpNIT50in8mvE/7Knjvwj8FL
z4j3ej20ngWx8WzeBn1uz1S0vbSTV4oBcPbxNDK/mr5JDiaPdCykbXORXdeFv+CY3xn8WeBb/wAT
ReH/AA9pug6VYaZqt5e6z4x0XSIraz1KCGawuX+1XcREM6zoqSH5TKJIs+bFIi9VOvUUY01Btfnp
JdvPTe1n3ZyVaUOb2nOk3/wPNdvy8j9G7q5sv2Yv+CcHxE8G/HDwHp/gj4e/Eb9py80LxT4W07Ul
kufAdhqGiafqcF3aXFiHikey8qxljjEDxyLbyRGIeZhPMf2t/hr4i8cf8HNt5dWSxXNp4F8R+GfF
fiDVS6W9loWj6dY6XcXV/dzSuI4ooYU+d3cBnIVfmdEPw/8AtBf8E8PjH+yz4K1bxF488HPoOjaH
4oTwZe3J1OyuRDqz2EeorbbYZnZv9Emjk3qDGN4UtuytNvP+Cevxgsf2kPEXwgfwezfEzwvp8mp3
nh2PU7KS9miS2S7K2qrMReTG3dZBBbGSVlDFUOxsdM8bUcVRdN6STXfRydtu7fTdPTXQdKPM5861
TXl013+/1VzD/bU+IOk/Fr9sj4teKtBv/wC1NC8TeM9Y1bTr3yHg+2W099NLFL5bhXTcjq21lDDO
CAeK+r/+CZ3gJrz/AIJaftjaxrngXxz4q8IXEXhhJf7AnNhJc/YtQa6uhFdPaXUSm3jeGebMTbIc
ltgdXHwJXpn7Nf7HnxG/a81bVLP4f+HRrTaKtsb2efULXTrW3e5uEtraEz3UkcXnTzyJHFCGMkrE
hFba2POpVJSrOfLdu+i7u/Sz+46akI+z5W7JW/D7j7a/4Jt/tY6n+3R/wcX+FPipqWnWfh688W3u
pyRWME7yx2UMOgXVvBEZGwZGEUMYZgEDtuIWMMFW1/wSA/ZB0XS/Ad/4x8XaJpnijWNL+KNp4T8a
+Dtc0vQkHgLQrO1lvdQ1vVm1ayuZba0wk9uVjNkzSW0iCdpfLRPhD4P/ALK3xB+O/wC0HbfCnwz4
Xv7n4h3N1dWQ0O7aPT7mKe2jlkuIpftDRrE8awy7lkKkFCOvFUf2e/2e/GH7VXxg0fwD4B0c6/4t
18zCwsBcw23n+VDJPJ+8mdI12xxO3zMPu464FdlPF1G4OUHJ88n6uXLdbb6L79jCpQjaSjJJWS9E
r+e3+R+j/wCxMuq/su/ts/tnfBDQfDfh/SjbeDPHCeCdA1XwtZXut6zOWt2sLKGS5hkvL+GWziSZ
LJnmgmQNL5b72kOZ/wAEpfhr4x8FfE39r/wZr3we8L+IfHGj/DTxLFrLaUlzd/aL24a12eHQmk3Q
sY45ZI5sQ2scdyrxSxpLH5RWP8wKKUMy5ZRajpFt2vpZ9Nunf8BywjfNd6u19O3z/rufen7N/gE+
LP8Agmf4r8b/AAi+GHhPxR8Zr34wx6fd6LZ+EYvGl3oXhxtLlngSOyv0vXhtTd70W4KeZIYijzS7
cD339oP9mXQ/Aeift2av4D+G3gnW9O+EXinR9U8E6np/gu01Gx0q9lEa6/Z5lhmWdLW1kZprORmt
rN0aaO3tjsKfkdXa/Bf9njxj+0L/AMJZ/wAIfo/9r/8ACD+HLzxbrf8ApcFv9i0u02faLj96679n
mJ8ibnOflU4NZU8VeKpxjr5ej200319F2KqUbS53K39Lz8vxZ+jX7FY/Z38UfsZar8Zfjj8Lfhjo
XhX4mfGm48IeIJrHStVEXh2zi8Pf2nAuli3nkuLPdqCxhlt8KY7mSNsQiJYfir/gpJFa3X7TcWs2
Phbw34Ns/Fng/wALeIk0rw/po07S7d73QNPuZhbwgkKnnySjqSSCWLMWY+C103wa+D+v/H/4paH4
L8LW1ne+I/El0tlpttc6hbWCXU7Z2RCa4kjiDuflRWcF3ZVXLMoMzxUqtKOHjBXvulq3r9++i/4F
qVHlqOq5adui/rr/AMA+1P8Aghf8XtY0u++PngjSbXwrfarrnwg8Uz+HdPn8M6dqGra9qwhtjHYw
tLA9xeI0cLv9gJkgcRyMYSdzUv8AwSe/Z31m7/4LQw/D74n+A/B/iMefqsPjfRl0XSdY0nSz5Ekn
C28ctpZiO9+zRf6P5flM32fKBmjPw98Sfh3rHwh+Iuv+E/EVn/Z3iDwvqVxpGp2vmpN9mureVopY
98bMjbXRhuVipxkEjmsWqpY103TUo39m72vvrezVv6RLw6k5zi/iX9O5+mf/AATs+EPwM+En7A99
4j/aM8A6HFp2u/GW4+HvirVtc03UW1fw7b2ugyX8MVt9lcXNrOuoRRxy+XEGdJpI5SygeV6fqPwa
8I/EP9nnxR468JfC/Q9M+JniLXfCGo3Wk/D/AOD2neO5dN0q+8GWN+BDo19OIrKwe/ku83Ua7nlj
8tmlw2z8faKqGYRjTjTUFZO9+r0fVdr6dvyVTCylNzUt/u6f5an6r+MPgdFp3w2/bg8X+FPgp4d0
9PhT4o0rVPCcdz4I0jWE0C8dhFrlozRNfWk0dvaSmSW0aeW2tDiZYLV1XyvzO+MvxGh+L3xS1zxP
b+GfDPg2PXLprs6N4dt5bfS7F2wXW3ilkkaKMtlhGH2Ju2oEQKi8zRXNXxPtIqKVkv8ANvt52+S7
G1Olyttu/wDwyPs//ggN8Mrf4wf8FNPB/h/V/BujeNvCd7YaifENnq3h631mzt7VLWR45pBNDKtv
i7W1QTDY2ZBHvAlKt0P7CPwdvT+y/wDEDSV+DniS7+Img+OIbLUdc0v4d6R8Rdc02FbO4R9JuvD+
ozxy6fEJ1aT7ckXzyI8LNuiVR8hfs9/s9+MP2qvjBo/gHwDo51/xbr5mFhYC5htvP8qGSeT95M6R
rtjidvmYfdx1wK4ytaeI5KcLxejlr3uo6bdN9+vQidJynK0t0tPRvz6/oezf8FEPAo+GP7cvxV8O
rp/g7TBoviS7s/s/hWMw6QuyQrughNxcG33Y3Nbec3kOzxYTy9i3f2S/2cPHnxA0DVfGXhj4K2Px
z0fTrhNGu9HSW+vbrTZ5AJo7l7LS7uC/SMpFIizuv2YlpEyZAu3wyiuZVF7Tna/r5p/ka8kuRRvr
3/qx9hf8FBPgD4i/af8A+Cy3xW8CfDrTINd8Ta74pvhbWaXOl2aTTxQtPdDzIpFtl2mOc5lcTnb+
/wD9JMoqP9lLXviv45/YW1PwN4c+A/hD43/D7TvHg167t1/tK717T9Tk08RI722l6hBdrZm3hlCy
yQmEu0qiQuAq/Of7P37P3i79qX4v6P4C8B6R/bvizX2lWwsftUNr55jheZ/3kzpGuI43b5mGcYGS
QK42uhVrS9vyvVy7W6aK6a0vr5NaLrKh7vs09kv63P0X+Hn7HHwq8K/8FQf2o7TTPD6az4P/AGd/
CHiPx14c8O61dR6jp15faaIDDZ3vlSu09mk0z5heVZisSR3GH86M8d8EviN8Sf2xf2O/HXh3X/hF
4q+NOhaz8WD491S+8Baxa2PieDXLqxnSY3FlHaXjixlj3ski2kUSypIolY/u1+GaKpY1LSMbLW9r
a3+VtPT7iPq73bvtv5fPvqfvx8UP21fAH7Jnw3+NeveMvhvofiv4WeJ/2jp/Dvi3Rv7H0/VGupE8
MWlxJLHCLgWzTtqdnHMwmO9C83mItwSsfiH/AAUQ/aGHij/gmzqfxJ8ZfDvwb42ufHfxV8LarLZ6
mmq2emxT3Pw50qV5LdrW+gumUEMqCSRlCu+4M+Cv47V2XwO/Z+8X/tH+LLvRfBujvq15pum3OsX8
j3ENpaaZY26b57q5uZnSG3gQYBkldV3Mq53MoPbLN6tSPsIQ32W+9/v30XT5mP1KEZe0vba/oree
mx+sfxq+Avjj4t/8FE/j9eaP8I9G0P4SeCvFT634k1i3+Eek+MPFHiO5n0/Tf+JZpqTW12jz3DL9
qUYiWAalLPeFWZYq/Mn9vaTVbj9rTxdcaz8NNL+D13ePbXUfg2wtkto9Bt5bSGS3heNFULMYGieX
5Iz5rybo4mzGvnHxC8Bat8K/H2ueF9etPsGu+G9Qn0vUbbzUl+z3MEjRSx70LI211YZUlTjIJHNd
p+zD+xr8Uf2zvGL6F8MPBOteLr6FlW5ktY1jtLEsksifaLmQrBBvWGXZ5rrvKELk8VxVas61qMYP
mu9N3fta2lv+HNqdNUrybVrLy+9n1b8KNS8GaL/wb/yT+OPDnifxFpEn7QbxpDoOuwaLcrOPDkZR
mnmtLtWQKZQYxECS6nzBtKv9Ef8ABU3wPN+0R4D/AGhPhP8ADPwTfXXxI8KfHK38ean4R0i0ik1G
TR5/D9nYnVILe3LG5SW9k8x/KDSxi6WSdIy7bfzK+EH7IXjz44eAtQ8V6LYaLZeFtMv49Jm1rX/E
Wm+HtNa9kjeVbWO4v54IpZ/LRnMcbM6rhiACCeM+I3w/1f4TfELXvCuv2osde8M6jcaVqVsJo5hb
3MErRSpvjZkfa6MNyMVOMgkYNbLG1I00nD3bct/k+tvPS9yFRXO3GWu/5dLn6Gfskfsxa/8AAr9h
f9ujRPiR4L8V+JrDw/deHNN1aLwrq0Y+03VjqTXF4keopb3duGtY5I5rhWjdokJEgiY7lg/4JX/F
y+/ba/4OBNL+J9l4Ms/DNhq97rGu6jp+jWrS2miWzaZcQCadwm3c8skQkndUWS4uCdqmQKPhT/hn
3xcP2eh8Vf7LT/hAz4i/4RT+0vttvu/tL7N9q8jyN/n48n5vM8vy+27dxXR+H/2JPiX4t/aqk+Ce
laDZal8S4rm4s30q11qwmjSa3geeeM3SzG2DRxxybx5vysjIcOCtGHxFSnUouEH7rTS76tq2nqlv
6blTpJqbctWvu0V9L/M828S+GtR8GeI9Q0fWNPvdJ1fSbmSzvrG8gaC5s542KSRSRsAyOrAqysAQ
QQRkV93/APBM7wJLdf8ABKz9snWdd8HeNfE/gqePwuk8WhXDafLetZ6i1zceTdvaXMKm1jkimmBi
YpC+TsDBx8wfAv8AYZ+I/wC0d8KvEfjfwrZeF5PCvhC5htNb1DVPGGj6MmlPMVEJnW8uoWjSVm2R
yMAkjq6KzMjAed/Eb4f6v8JviFr3hXX7UWOveGdRuNK1K2E0cwt7mCVopU3xsyPtdGG5GKnGQSMG
uSlzUmqsouzvb5pre1n+pc+WovZp6q1/wfyP2N+BH/BUfwRZfsNeN/jF8SPhN4bvvh/8Vv2ib238
SeFLbR4NViNs3hyC4hKRzvFDNdC7trWWWWUAO8k0iorsoT87/wDgrd8VLz46ftqXXjbUrKzsdV8X
+EPCetXyWYdLRp7nw3pszmBHJZIgX2qrMzALyc5A+aaK3xWY1K9GNGW0dfnr/noumvyzp4SEKntI
+n5f5H2x/wAG8PhXU/Ef/BW34ZT6fZahdW2jxareajPbQyOtjbnTLqDzZWQHy0Ms0Ue9sDfMi5yw
pv8AwQ6+BWo+Mv8AgqTovgbxJ8P7DxBY21tq9r4r0bxJ4Xh1GPS0gtpebiK6hf7JIl6ltF5hEbh3
ERYCVlb4poqaGNVNU1y35JOXrfl02/u+e5c6MpOTT3VtvXz8z9OP+Cdnwp+Anwi/YBm8QftGfDzS
Y7bW/jZc+AfF+sa7p+oNqWh2NpoLX8NtarakXVncLqMapKY1DSJM0cm5U+T1TXfhr8NPiJ+zdrHj
XwL8LLHRvizruveE7rXdN8EfCbSPiCdOsL/wbYagiWmhXsypp9jJdz3JNyuXklQIXfkJ+OdFaQzC
KhGm6atG+vXW/W3S912ZE8K5Tc+bfp06dPlqfrB8T/g1oo8DftveM/AfwM0nQbT4X+ItE1TwfZah
4S0nXm8P6iRHF4ht2khW7tJYIIJJJZLF5Zbey8yNxFBIgZPzD+MHxCg+LHxO1rxLb+GvDfg+PWrl
ro6P4fhmg0yxZsblt45ZJGjQtlgm8qu7agVAqjm6K5sRifa7K2/33fSyS00+RrSo8nX+rf0wooor
lNgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKAPsf/ggV/wApTPBH/Yv+Lf8A1F9Wr+t/4pf8gO5+g/mK/kg/4IFf8pTPBH/Yv+Lf
/UX1av63/il/yA7n6D+YpoD40/a1/wCROH/YSg/9FT0Ufta/8icP+wlB/wCip6KctwOi/wCDo7/l
BR8c/wDuAf8AqQ6ZX843/BGLxHpw+Kvxm8Fy6jZ2XiP4tfB/xF4G8J2t1OlvHrOtXi2/2WxE0mIo
nlMbKhkdFZ9iBtzqrf0c/wDB0d/ygo+Of/cA/wDUh0yv5KPg18GvFH7QvxS0PwV4L0W88Q+KPEd0
tnp9hbAb55DkklmIVEVQzO7kIiKzMyqpI1wtSUKsZRV3279DKvBTpuLdj7O/ZAEH7MP/AATv+Jvi
f43eHrr4i/Cy78ew+DLX4UXV1PplxY+KoI4bqbVZbjaJNMdLKKa1LW4aW4LNFKqxxhq+lh4R1v4g
/Df9tXxB4U+HVz8XfDfjbTvh1qPhPwzJ4dv7KFNOmjt7600VLfSZoyZNO0+6s9y20xG23jkbh3U/
l14m/ZS8deEvgje/Ei60uwl8Daf4ul8Cy6xZ6xZXtu+rxW/2loI/JmdpYzD86zxhoHH3ZGrtPB//
AATS+L/jfwRqviS00jwpaaJoNnpmoandap430LS10621K2t7mwmmFzeRtHHcR3MOxmADOzR58xHR
eulXmoxp+zvby11UvJ/c72s7bs5qlOHM589v6Xmu34n6G6X468L/AAL/AOCc/wAUvCPxZ8JaP4X8
E/Ej9qC+8M+MvDWkatBc/wDCAWFzptrepPY3GnK8bXGnz28P7oRPG32R4GhBZlTyv4++Frr4k/8A
By1qOraBq7eLNE8C+N9H8U+IdbmurZbXQNL0tLGbUJLm4GyKKGyWGSAtId+YURi8zfN8afH/AP4J
7/F/9lzwfrGv+O/CP9haToPiePwdfz/2rZXXkaq9hHqC222GZ2bNrKkm9QY/m27twKhl1/wT++Ll
n+0b4j+ETeEw3xK8LWMmoXvh6PVbKS8mjS3S5aO1CzEXk/kuHEFsZJmAbah2NjV4ypLkpypt2aa7
vVu23nppprbdi9hC8p826t5bLX8vwMj9tb4g6R8Wv2yvi34q8P37apoHibxprGrabetC8Ju7ae+m
lilKOqsu5HVtrKpGcEA8V9XfCnXPA+j/APBvxIfHOi+K/EmnN+0I/l2Oha7b6LNBL/wjceyVp5rK
7VlKiRTH5akkKQ42srfAles/A79iT4hftFfDLxB4y8L23hRvDXhS4itdYvdV8Y6Noq6Y8pUQmVb2
6hZEkZgiSEbHcMqsWVgOPD1Z+0lKMbtp+e/yZvVpx5FGTslby2+4/R74dXlpq/8AwdqXDwas3ieB
tc1CKSZngkMLr4cnSS1PkKE/0Zw0GCC4+z4kZnDsflj/AIIReH7/AMM/8Fi/hhpWpWl3pep6fc61
aXdvcwvDPYyppN+riRDhkeNgchsbSpz0NfKvxk+Dnif9nz4o654K8Z6Nd+H/ABR4cums9QsLkDfB
IOeGUlXRlIZXQlHVlZWZWBPM1tDHunVhNR+Cbla7/u6f+S7799iVQvF2e8Uvz1/E+9P2XPgLrNh/
wTF8U+IPhv8ADWz8b/H7TPi7H4e17SrjwRaeL9U0XQl0mWRC+nXdtcfZEa9WZDMIkLvEYyx8vaPe
/wBqv9l7wx8MPBXx91D9mnwN4Y+JPxB0/wCOSadeWVl4N03xq/h/QJdEN4YYrFrWeCytY9Sku4Fd
IUb/AEUQl2MLCvyQoqIYuEUo8uy79ddVpo9fPYJYeTk5X38vTz8vxP1T/YE/ZJtdL+IXj7xn498F
+A9Y1SH4swaL438EaRD4Zu9A+HGjCC41K91K5uru3v0tdOiQTWwjgntW3WskX2nzkVUzv2DPEkHw
C/bO/bW+EPg2x8LiwsfCfj+w8FaVceH9P1XVNYvILiOK106OW4hkur6MwW5Y2TPJFJ5Tu0THe1fn
34O/Zi8aeP8A4C+L/iZo+m2V74N8BTW0Gv3S6tZrc6abmWOGBmtGlFyySSSKqusZQkPz8j7anwa/
Z78YftBHxUPCGjnWP+EJ8O3nizWsXMMH2HTLQIbi4Pmuu/ZvX5E3O2flU10UcY4+z5YO6be+997a
f57Gc8PGXNzy00T8up+hP7OP7Lsfhr9kv4nXeq+FLTUfj7pvxdXR/ENr4M+Gnh74oXWlWD6a86QL
pRkFjYWxuzcL51sVxJB9n2fuisfsHwF+Afhrw78cdR174RfDfT28Y237UWjad4i0+TSdE8Tal4J8
NSW8dzMRFaC6ttKtob1rpUubZlaPyBE0we3Ir8Y6Kijj4U+T3Ph893rrtpv87IqeGlJS97fyPZv+
Cjkbxf8ABQv48LJIZZF+IniAM5AG8/2lcZOBwM19BfshfCDUNX/4JZ+IPF3wo+HekfEX41w/Fa20
nUrceELTxnqGn+Hzo80sTnT7i3uVtoXu/MH2gRqZHj2bj5eK+F6K5IV0qrqNb369/PyNpUm6agn2
6fp5n6O6b8AfE+i/sf8AxV8QeE/hL4E1v9oiH42Np3iLw94e8L6X41h8L6LLpc90LeCw8u9hsrZL
tpY1ePDboGhZt1uVXqPjV8M/AfwY0T9vG88K+Hfh5qa/B7xj4e1jwVdyeHtK1mHR7jVLx7a+tCz2
oR4EieSIWE6SQ20kOVHnxec35v8Awd+D3ib9oD4naL4M8G6Pd6/4m8Q3ItbCxt8BpnIJJLMQqIqh
neRyqIiszMqqSKXxE8Aav8J/iBrvhbxBZtp2v+GtQuNK1K0aRJDa3MEjRSxlkJVtrowypIOOCRXT
9aappqLtrrfrrtpurpv0WxDo3lbm+Xlp/l+LP1N8U/s4eGfB/wARv2i9J+HXwpudXvNH+KUEcOve
DPA/h/4sSaZYzWE0x0ltDvGt302FJy5FzFCUDxSWjSM1sGfB+Jv7LF/8I/gd8cbr4V+Dfhd8UvjP
pXx2bSNUj8J+CbPxXbaVoEmlTXcaW+k3MN2unW63RliYqvyy27weawt+fz3+B37MPjX9ou38QXPh
bTbGTTPCltFd6zquqavZ6NpelxyzLDD515eSxW8bySMFRGkDOQ20Ha2O80T/AIJk/GjWI/HTT+Gt
G0H/AIVlfRad4pXxD4r0jQm0OWUoIGmW9uoiIpi6CKYAxSk4R2Oa0jWlKzjTfXbzvqtOncxdJRvz
TXTf5b69f1Ps39kP4f8Ahr4Z/wDB0UuheFbfQtN8PWnibXTZ2ui3S3VlYmTR7yQwx7YoliMcjshg
CYt2Uw5kEe5uM/YU/Zm0y5/4J5+NdQt/Beu6h8ZtF+Kseg61a6X8L7H4h+IdH0xNNkZIptHv3RbK
BroXIa5GHaW3WIghSU+O/it+xX8Uvgb4G1jxH4v8Haj4e0nQPE//AAhuoPeyRRzW2qm1+1rAYd/m
lWt8SLKFMTqQVc5Fcj8XfhH4l+A3xK1nwf4w0e70DxLoFwbW/sbkDfC4AIIIJV0ZSrK6ko6srKWV
gSo4r2aXNB2Tk1rb4klva91y736dDT2Lf8OXRLvtr+Nz0b/govo2keHv25/ilZ6F4Th8CaVB4guB
B4fi1Cyvl0rJy0W6yZ7aMhi2YIXZbckw7j5Wa96/YF+F994i/wCCYP7S3je3+Huj+I9Y+GN7omse
FdWu/BdpqxtJpJmh1YNLNBILiCLT2WV7efzIYMrchI5AJa+HKK5KeI5KrqJd/wAU/wAt15o2lTbg
oJ7W/D/M+7f+CNcdn+1Z/wAFfNNudR+FPgK/8I+KV1S98Q+GrfwtFqGgaTbtbyOjRQ3QmFnGLz7M
qOrrtMqwqwSTyzifsjeGv+EA/YD/AGo9U8QeCfDP/Cc/BnWPDlzoz+IvCVld32iX93fy6dfW9wl1
A5lQwq6/ZboPFHKnmrGkyh6+LaK0hjOWnGKjqnLW/wDMkvwautdyHQXM300/A/Vr9r34V/CT4MeK
/jz4f8JeH/gH4V8d2nxXtZtV0rxVdW81hbeCZ9GE7GyFxGk8Za5kleSLRP8AT4S6xW+4R27t8hf8
Fl/h/Y/Cz/gpr8WdA0vw34c8I6Xp2o26WelaCiR2FtA1nbvGURIYVRnVg7oEwru43SY8x/L/AIS/
theP/gr8Pbrwho+p6TfeEbzUl1ltC8QaBp3iHS4r4RGH7XFbX8E8UU7REI0saq7qiKxIRQOY+Mvx
l8UftCfFDWvGnjTWrzxD4n8Q3Bub+/uSN8rYCqoVQFSNEVUSNAqRoioqqqgAr4inOnZKzv29et/N
dBUqMoTve6tb8j69/ZF+Fl7qH/BLzXvFfwp8AaL8Q/jWnxTt9I1O1PhCz8Z6hYeHzpMkkL/2fc21
yLeF7zzF+0qimR0EZY7AB9YfAf4f6P4S/b+/b68KfD/4MeDtT0jSvh34jggXw7d6rfQtNNFZ7dCH
2eaGGNZ5o7hmtYYknikjnghm2QgH8bKK0oY6NNwah8Pnvv5bu/nsiauGc73e/wDwPPyLviXVYNd8
R6hfWum2WjW15cyTw6fZtM9tYozFlhjMzySlEBCqZJHfAG5mOSftP/g3j+Hmu+Jv+Cpnw612w0fW
rvQvDT376vqdrZPNa6QJtKvkhaeUApEHcFVLkZIIGSMV8P0Vz4TEexrwr2vytO22zub1Ic0HDurH
6T/BH4f+J/DX/BHDxB8PLn4JSfEn4heHfjmmoar4C1Ww1kato1rP4eQQ389np89texITGyRySN5L
+bINpYKV+SP+ClHwU8Nfs5/t4fFLwR4OFknhnw5rs1rYQ2urNqkdqmAxg85kVt8bM0bRvveJkaNp
JmQyv4fRTq4iM6cYKNrdfv8AK/XXUmFJxm5X3/4B+qP/AATT+Pfgr9nX/gj5Za94500w2p+Pd1aa
F4oFkupHwJrMnhhBZ659gb5L37GwL+Q2fv8AmL+8ijVvPv8AgmX+yV4s8Mf8Fxx8L/i34X0b4iXU
cuoy+NDq2mQ+JbS7gktGu4tQeW4jkMfmzvZuJ28uXNwI3KmV4z+d9FdVPMlH2SlG/s2nvv3T066f
LTXpm8N8bT1kfof/AME1fgp4ysP+Cd/7Y1u/wk8QeONS+1eGNHi8NXej6qU1C9s9VZ722ZbN4bjz
rRJIpZI0dWjyhkAU4bgv+CkXwV8aftg/8Fqfij4K8F/YfHHi/XvEM1vp8Vpq1oYphb2Ycw+ey28K
NDDCyNG+WjaFo2knkUyyfFtFc8sRTdONPl0W+ur1fW2m9uq0vbc0VJqbnff/AIH+QUUUVxmwUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQB9j/8ECv+Upngj/sX/Fv/AKi+rV/W/wDFL/kB3P0H8xX8kH/B
Ar/lKZ4I/wCxf8W/+ovq1f1v/FL/AJAdz9B/MU0B8afta/8AInD/ALCUH/oqeij9rX/kTh/2EoP/
AEVPRTluB0X/AAdHf8oKPjn/ANwD/wBSHTK/nE/4I06/psnxS+M3gqa9sLfxJ8WfhD4h8EeErW8u
FtYtX1u8+zm1sxM5EUckpjcIZWRWk2IG3sgP9Hf/AAdHf8oKPjn/ANwD/wBSHTK/kq+C/wAF/FX7
RPxT0TwT4J0S98R+KfEdyLXT9PtVBkmfBYkkkKiKoZ3kchERGdmVVJG2FqSp1Yyirvt3Mq8FKm03
bzPs/wDY7SD9lb/gn38VvEnxz8JXnxE+F1147t/BMHwqvZp9JubLxZBEtzJqcl0VE2mvDZxz27fZ
w0s5k8qZVjRWr6H8D/DTW/FXwd/bp8QeEPhhrPxW8J+OU8A6r4U8OX2iX6Ry2V01vqdrpEcWnXCz
AaZp97aJ5VrOEjjt4CVEJVD+YniX9lfxx4T+C1/8RbrS7GXwRpviyTwPLrFnq9le276vHAbhoIzD
K5lQwjes8YaFxjbIciu08Gf8E2Pi7478Fax4is9J8KWui+HrXTL7VbnVPG+haWum2+pWtvdWE04u
byNo47iK6g2MwAZ2aPPmI6L10q9RRVNwbtt3+15O61220drXZx1KMLufOk216dPPfTffVeR+hege
NtD/AGfv+Cefxa8HfGP4cP4B8BfEv9pu68MeLfDUE88c3gTTrnTYL6G5sZ7eMxStZSQWk0WyCSO5
it9oRkmQr5N8d/AM/wARP+DknWNS0Gz1m58P+DfHOl+L/El/qjXEEWiaVY/YrjUb64mvCDDZxBXM
blhEUMKwZR4VPx58f/8Agnz8Xv2XfCOsa9478IjQ9K0DxNH4Ov5/7Vsrr7PqslgmoJb7YZnZs2si
SeYoMfO3duBUQzfsEfFmH9oXX/hR/wAIp5nxH8N2D6jd+H4tTs5byeNbdLkpaqspF5P5MiyCC2Mk
zKHIQ7H239Ym3Th7N+61a271btt16fOy7VDDwTlUU9X56dPPfRfgZf7afjzRPin+2P8AFnxP4Zuz
f+HPEfjPWNU0q5Mckf2m0nvppYZNsgDrujZThwGGeQDkV9g/8Eo/ht4n8Qf8EzP2vbzSfhRe/FOD
VJPCVjY6M1hqM9trVxBqbSzwp9gkhuZHgilinZYZl2DyzICjAH88q9A+Bn7L3jX9o228RXXhXTbC
TTPCVrFea1qmqaxZaNpelxyzLBD515eyw26PJK4VEMm9yG2qdrY46FV+15+W7d9F5p+T/I3rU70+
Vu1ravya80fpz+0f8LptYvf+CgfxD0bwzb/E2++GvjfTdR8MeJta8I22tnTbxpGh1uyzc20oubax
s3MZgm329tHDDOERxFKPEPhDG/xl/YC8d/Eb4Q/BnwBqfxr1j4u29vqfh7QfAUXixdB8PtpEkiG3
sL9L77Hay3xkw6KmXXyw2xI44/naw/4Jd/Gu6Pj0XXhvQNDPwv1JNK8VDXfGGi6MdEmkKCFpRd3c
X7iYyIIbgZhmJ/du+DjmfjJ+wn8Wf2fPAmt+JfGfg288P6N4c8XN4F1Ca5urffDrC2ou/s4jWQyO
jW5WVZkUwujKVkbcM9LqzTU+R6J/i3dp207ddvuwjThbkc03p+Ft1fr+p+l3xF/ZX+DV54+1+28H
eEvAusaf4A/ar0x/Fy2Og5HhvwkunQtfnUDIXNtpUVzHeJL5hS1DwzELGiqieQ/Fn4b/AA7+E2k/
tA+HtM0b4LaF8RtL+O18dR03xvaW9jDB4C8i4eD7DHcYnEDs5ZRop/tAxmEx7ibYj5E0L/gnH8Yv
EX7Veo/BC38L2MfxS0uETTaFdeINMtZHBhjm2RSy3CwzSeVKsnlxOz7Q524jcr6d+xn8GP2lfEfw
28aeHfhhD8O/FHg7RvFFrb61pet6r4S1nS7fWC32S1uIYdTkki3TtN5EV1brsuc+Wkkm3aNqNdtx
iqT0utFd639Ne/6BKKjq6nbd/j/kfXPxW8EXX7GXw4/4KM6h4S8H6Bpfhu317wdaaSlz4Rim0GGZ
71Lme0Sz1FLiGVokvIyQB5amSKWOOJGgVJvgveW/7PX/AAUr/bS+FXgjQ/A9jDqvw28S3XhDw/B4
NtZLrUdTmsrK5h0y2jukmuLmMp5hNkrNaT+W8iWyoVRPz58Sfsx/Gn9pSD4v/F3XdPsprnwjrF1d
fEC51bWdM0e/0q/klLSCawmmhnRpJmaOOOOHDyhoY1LqUGF8Df2IviH+0X8MfEHjPwva+FX8M+FL
mK11m+1Xxjo+irpjylRCZlvbqFkSRm2JIRsd1dVYsjAEMTP2sZQpu6u/leTdtNNHrvt9ylRpyhJT
ktbX9dLbvyOP+OPg3xB8PfjH4n0TxXZ6bp3ifTdTnh1W00/7ILa0ug582JFtD9nQI+V8uLCJt2gL
twPuD/gnZ8GvAnxK/Yj8Bave+F/C+v634W/aS0S68aXU+mw3U+keD/sCvcS6i7KfK0nfFOXabEAM
chY8HHxN8fvgD4t/Zd+Lus+A/HWk/wBh+K/D7xpf2P2qG68gyRJMg8yF3jbMciH5WOM4PIIrjq8+
hWVGpzct12f9b/I6qtP2kLJ29D9PdH/Zyg02X9uywsPBXww0fxP8K/HtjqPgZ/E+m6Jp2n6RBfap
d2zpv1RFt3s5dPaNoIbhzACYpYV84xvXxb/wUbtfAll+3J8TY/hlceHLrwMNakOlvoMLxaaqlVLp
AGdwyJIZF3xEQybS8KxwtGi3P2R/jH8X9f8ADur/AAA+Glx4Xew+Mtylnf6TqWm6JG2uThf9HiN9
fxhkdWGbdRMpSdwYQJpMty/gH9jT4k/FD9qaf4KaF4b+3fE221K/0iXRv7QtYtt1ZLM11H57yCA7
BbyncJNrbPlLZGd60lUpwjSg97bdbt2Xyav1dkZwfJKTqSW3fp3fb+tT7D/4IdftBeDPBnibwh8P
tGt/H+gfGXxr8T9ImvPEPhzQINVGreGLd4JpNGmle7imsrV54nnupoI33Qw4lWWNdi/M/wDwVI8J
zeCv+Cjfxusbj+0zcN4z1O7la+01tPkkae4ecukTSynyGMm6KQuTLEY5MLv2jwWisamKc6EaLXwv
+tP1HDDKNZ1U9z7T+CPhTUf2l/8Agjhr/wAM/AFne+L/AIjeFfi1H411DwvpkEk+qf2NLpcenLew
wAZuEF26RusAd496NIFQhq9j/Zo/Zs8V/CL9iD9tvSPif4b8WeP7Xw7aeDtM1b/hF9b3NFLp00c1
zp8eom2u4N+mQvAtzGsciQR27LlUCSD4G8IfszeM/HnwG8W/EvSdOsLzwd4FntrfXbkavZpc6e1z
IkUBa0aUXLJJJIFV1iKEq/P7t9tT9n79n7xd+1L8X9H8BeA9I/t3xZr7SrYWP2qG188xwvM/7yZ0
jXEcbt8zDOMDJIFbQrycoWg+a3Krdb3W1nfVv1CVPSS5tL39NnvdH378Yvip46/4Kl/8EyPHut+H
PCl74l8faz+0BB4i1Pwx4Wt7rV73S7H/AIRv7JDcvArSTJAzRGMSlFjZ0ZV2hVjX1/8Aak8M2/xE
/ag/aVm0PwHN468WWnxMs4pvGXhD4faP8T721sk0gRjR5tC1C8Z7JIpVYPfxrsmnhkhxD5Kwp+ON
dR8F/g54g/aC+KeieCvCtvZXniTxHciz022utSttPjupyCUiE1zJHEHcjailwXdlRQzMqkpYx3iu
Vt7dLvfsvPpr8zOeGSvK9lr09PPbQ9G/4KSfDmH4Sft2/FHw5APAoTSdcliK+DreW10ZGwrMsVvJ
LK1s4YkSWwkZYJRJEnyRqB4jW18Sfh3rHwh+Iuv+E/EVn/Z3iDwvqVxpGp2vmpN9mureVopY98bM
jbXRhuVipxkEjmrnwa+D+v8Ax/8AilofgvwtbWd74j8SXS2Wm21zqFtYJdTtnZEJriSOIO5+VFZw
XdlVcsyg8kk5VGorVvb9Dqi0oJt6dzmaK2viT8O9Y+EPxF1/wn4is/7O8QeF9SuNI1O181Jvs11b
ytFLHvjZkba6MNysVOMgkc1i1m007MpNNXQUUV2vwX/Z48Y/tC/8JZ/wh+j/ANr/APCD+HLzxbrf
+lwW/wBi0u02faLj96679nmJ8ibnOflU4NOMXJ2irsJSUVds4qiiipGFFFFABRRXZj9nzxgf2em+
Kv8AY7f8ICviIeEzqv2mHH9pm2N19n8rf5p/cjfv2bBwN2SBTUW9hNpbnGUV9Dz/APBK3436fqnj
mz1Dw74a0af4Zz2tv4p/tbxtoWnR6G10kT2xmee8RVSUTxqj5Ks5ZAS6Oq1bD/gmL8aLm58ew3fh
zQdBk+F+ox6X4pGveLtG0X+xppSohaQ3d3FmGYsvlTrmKbP7t3rRYeq7Wi9fLtv+TIdWC3aPAqK+
ktO/4JG/H7U/iXP4NHg7SLbxVBqU2kLpd54u0W0ubq6hsre/migSW7UzmO1u7eVzFuCCUbiCCB4N
8QfAl98M/F95oeoz6Nc3tiVEkmk6vaatZtuRXHl3NpJLBJwwzsdsHKnDAgE6FSMVOUWk9L20KU4t
2TMaiivWvgX+xD8Q/wBo74ZeIvGXhW08LSeGfCM8VvrV9qvjDR9GTS2mKrC0y3t1CyRyO4RJCNju
GRWLKwERi5PlirsJTjFXk7HktFdj8fvgD4t/Zd+Lus+A/HWk/wBh+K/D7xpf2P2qG68gyRJMg8yF
3jbMciH5WOM4PIIrjqTTTsxppq6CiiikMKKKKACiiigAorv/AAf+y/418ffAHxd8TtI02wvfBngO
e2t9eul1eyW501riWOGBmtGlFyY5JJVVZFiKEhxu/dvtpfs/fs/eLv2pfi/o/gLwHpH9u+LNfaVb
Cx+1Q2vnmOF5n/eTOka4jjdvmYZxgZJAq405SajFXb28+mnz0J546u+25xtFFFQUFFFdl+z9+z94
u/al+L+j+AvAekf274s19pVsLH7VDa+eY4Xmf95M6RriON2+ZhnGBkkCqhCU5KMVdvZCbSV2cbRX
a/Bf9njxj+0L/wAJZ/wh+j/2v/wg/hy88W63/pcFv9i0u02faLj96679nmJ8ibnOflU4NWfCP7MX
jTx58A/FnxO0jTbK98G+Bbi3tteuk1azFzprXEkcUDPaGUXJjkkkVFkERQsHAbKPtfs5aO29/wAN
/u6i543tc4Giium+Cvwp1L48fGTwl4H0aWzh1fxnrVnoVjJduyW8c91OkEbSMqswQM4JIUkDOAel
TGLk1FbsbaSuzmaK6j43fCfUfgJ8Z/F/gXWJrK51fwXrV5oV9NZuz20s9rO8EjRsyqxQshKllUkE
ZAPFcvRKLTswTTV0FFFdh8A/gJ4s/af+LekeBfA+lrrXinXTKtjZNdwWgmMULzP+9ndI1xHG7fMw
zjAySBRGLk1GKu2DdtWcfRXS/B74R678evidovg7wxBZXfiHxFciz063u9RttPjuZ2B2RCa4kjiV
3I2qrOC7MqrlmUHp/A/7HfxH+JH7Uk/wW0Xw79t+Jlvqd7o0mjfb7WPbd2YlNzH57yCA7BBL8wk2
tt+UnIzcKNSVuWLd3Zabvt6+QnOK3Z5nRRXTfBX4Vah8dvjJ4S8EaTcWFpqnjLWrPQ7Oe9kaO2hm
up0gR5WVWZYwzgsVViADgE8VEYuTUVuxtpK7OZorpvjV8KtQ+BPxk8W+CNWuLC71TwbrV5od5PZS
NJbTTWs7wO8TMqs0ZZCVLKpIIyAeK5miUXFuL3QJpq6CiiikMKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
A+x/+CBX/KUzwR/2L/i3/wBRfVq/rf8Ail/yA7n6D+Yr+SD/AIIFf8pTPBH/AGL/AIt/9RfVq/rf
+KX/ACA7n6D+YpoD40/a1/5E4f8AYSg/9FT0Ufta/wDInD/sJQf+ip6KctwOi/4Ojv8AlBR8c/8A
uAf+pDplfzif8EZ/E2mRfFX4yeDJ7yzt/Enxb+EPiLwL4Rt7mVIE1TW71YPslmJpCIonmMbojSMq
lyqZ3OoP9Hf/AAdHf8oKPjn/ANwD/wBSHTK/kn+Dvwe8TftAfE7RfBng3R7vX/E3iG5FrYWNvgNM
5BJJZiFRFUM7yOVREVmZlVSRthakoVoyirvt3voZVoKcHFux9nfsf6ZH+yr+wB8VPF3xy8G3nxB+
F1546t/Alv8ADC9uJtKuLbxZbxpdzajJcYE+myQWSTW5MCtJMZzFKqxpmvpbTPAfij4h/Cj9tzxT
4Z+GN98UfCvji0+HWoeFPDDeHb+ztLnT5YrW+tNKjg0mWJmfS9Pu7JGWCYYEKOwKOQfy18SfsxeN
PCnwg1Dx9dafp8vg7TPFUngubVbPWLK9gfVUgM5ij8mVzLGYlLrPGGgYY2yHIruPBn/BNf4v+O/B
2u+ILPRfDNpo3heDTbrWbrVfGmiaUmkxajbW91YSXH2q7jMSzxXUOwuAGfzI/wDWRSInZQrTSVNU
20k/XVS621Wuz00fdnNUpRbc+dK/3dPPy9dV2P0Xa/0v9mX/AIJ9/Fbwl8bPhpZeAfBnxR/aWfQP
GGh6bqYc+CdLvdIttUt5LGWx3xO+nslpMiCGSORIzEYvmwnjXxo+FN74k/4OSdSuNC8KP4e0TwT4
50nxj4jaRre1tNF0uz+xXV/q9zOr+VDA6h7gySurkzoHVZnMdfGHxk/Yc+J3wC8Ea54k8U6BZWei
eGvFreBdTurbXNPv1tNaW1+1PZkW88jFlizuYAorq8ZYSKyBul/sQ/EzXvj34m+F+naFY6p4/wDC
Vtd3OoaLY65p91O/2WPzLiG2Mc7Ld3Mahibe2Mk2Y5RszG4WpYmrJwg6b0afZvVu23Vt2079wjRi
uaSnuvktF5/1oUP2yvH2jfFX9r74reKPDtx9s8P+JPGOr6rpk/kvD59rPezSwvsfDplGU7WG4Zwe
a+jPgR4Rv/2mP+CN/ib4ZfD7T9T8YfE3wz8WrfxtqHhnS4HuNR/sR9K/s8XsMCjfcKt3KkcghDtE
HVnCo26viqivPhVSm5yV738tzqnTbiop7W/A/R/9jH9mzxF8EP2B/wBuTw78QvA3ijXLLQJvDFjr
mneGNWh80z2N/Jc3UceoQwXtqr2aMktwCjmKMOreWSWW58YvG/iH/gpt/wAE3/ib4g8A/D64vPF3
iH9ohfE974O8HWUmp3WkWMugSRJdzQwKZWEsquHuWiRJZxMRtLFB+alFdEcZFRUHHRJrfXW+t7dE
7dUYvDNyc76/8N5+S/I/XT4D6BZ+Lf8Ag6z8QT+G/Dr/ANh6Nrmrvqi2CQSQWTf2RNaT3MrWjPHG
JL2UZLsr+bOqShJ2ZB4t/wAE5v2UfiZ8Tv8AgnP+2V4H0TwR4oufFOs6p4O8O22mSWMtvI2o22uE
3Nu5kCpG9urhpvMZfIRtz7Vyw/PSvTvhj+x749+MPwL8Y/EnQLDQ7jwb4AKjX7y58SabZS6cXXMQ
NvPcJO3mnKRbI286RWjj3urKNqeMc0oKDes27dpRSfR2sle/+RE6HLHWVvhWvk79+p+j/wAQ/Cc/
7WPw3/4KQal8HfCet+KNB8S+JvCdtov9g6WbxNdu7PUz9uktPsaNHcqSz3BdcyNFPHM/LuTwP7DH
7LHxO+DH7E37a3g3U/hC/wAQPEFleeEtJuPDMQvNVt7+7g1B5p4El0m4Uyy2yTRSyJDPujO3eNvm
Kfhr4RfsjeO/jb4C1DxVo1ho1n4W0vUItJn1nXvEOneH9Oa9ljaRLWO4v54I5ZvLRnMcbMyphmAU
gnf+F/8AwTx+MPxk+LPjPwR4f8H/AGnxB8PdSXR/EK3Gq2VnZ6bfPeixitWu55ktmnluj5UUaSM0
zBvLDhSQ44ipOcJqDdlJd735npo9rvuKcFFOMpq2j16Wt5+X4mj4+8O3/hD/AIKWXlnqvhf4ceDL
5PiEs8/hvWr61vPCugGS/WT7BfSWh8n7HAHEU6xhdiRyIVRlKL5r+0I5k+Pvjhm/4Q8M3iC/J/4R
MAaBn7TJ/wAg8DgWf/PHHHl7K9F+Av8AwTX+M37S2meIbrwj4VsJz4T1mDw9rNtqXiLS9HvNL1Ce
VYILea2vLiKZHlnYQx5TEkoaNSzoyjk/gb+yJ8Q/2jfjTd/DrwroCTeOLJbky6LqWo2uj3Ye3OJ4
VW8li3TJhi0K5kCxyNtwjleR06k+WMYv3m7efppr8jpjOF2rq638v8j7r/4I1fCq3v8A9n/wT4u8
F+DNI8YfEiD9ofw5pXiaX/hHbXxBf6F4VNsZTcbJkmOnwmcSn7aiwsGhwJv3eEh/Yi+FkfxZ/wCD
iz4k+GtV8F6L428L3fjDxiviGx1fw3bavaW1qk940czrJG6WxF2tqizIUw0ix79srK3wb4g/Zp8Z
eGvhDqHj2406yl8HaZ4ofwbNqtpq1ndwPqiwtOYY/KlYyoYlLiaMNCwxhzkZ7aX/AIJx/Fux1XxX
bX+j+GtFh8FavH4f1fUdX8ZaLpulQak8TTCyjvri7S2nuVjVmeKGR3jwd4U110MU4eyXI3yO9r76
6rbyt16nPOjrOTklzL7vx/yPev2AvhTeyfsr/ECG2+Eev6j400bxpbWmoa/pXw40b4kavpkK2dyD
plxoOozJLp8RlVpPtyxESPG0LMDEFr3v9kr9kXw14M+PnxZ8VazpPgHx/b6d8aToPiHQtH0jw3/w
jfhHw5HHdalNrc5voNQNjp/kpLELWOW0kU27wG6M8YSP8tPid8Ntb+DfxF13wn4lsW0zxB4bvptN
1G1MiS+RPE5R1DoWRwGBwyMVYYIJBBr039mb/gnv8V/2wvCGqa78PdC0XWtN0XUbXSb57jxRpWmy
211dOkVrG0V1cxSfv5XWOI7dssm5ELOrKFhcSlKFNU3Jxvpf1e1vm9H9wVqcbSnKSSf9b3PuH9nn
4KeK/hF8Fv8AgoR4c+Fnw/1HxAuleN9J8PeGNMm8Mr4piuf7P1+5EluLeeKaG6kgtXR3LRyMgZH+
XcGqH9i3wH4S+H//AAdAW+i+CI4o/C9p4l12Szht2tDBbM2j3sssUK2m6KOFJWkVIhhoo1WOQI6O
F+EPBf7FPxK8a6L4g1L+wrPw9p3hXV/+Ef1S68U61Y+GYLbUwHLWO/UZoFe6RY3LwoTJGBllUEEw
fFX9jb4lfBHwdruv+KfDEukaT4b8VyeCNRmkvLdzBq6QG4NuESQs6mEb1mQNEykFXORm44ucXSqR
g7Qd/J2bk+mnn5LXbSpUFJSXNrJW/BLv6H2N+wJ+zlpd9/wT38Z6tZ+Eta1L4vaR8UIdD1e10n4T
6d8R9f0vTF02R445dK1CVBZQNdLcBrgKrNJCIiXAIj+hfgN8EfCWmfGrUfEnwe+Gmj3XiC3/AGoN
DtvEVtJo+i+Jb7wV4ZmtVuZlVLR7y102zivGu1S5tyjRfZlRp98BWP8AMr4Q/wDBP/4ufHbxndaD
4Y8KJeX9lp+kalO9zq1jY2kUWrJbvpqG5uJkg8+6F1AIoN/nOzMoTcjhcn4F/scfEf8AaP8Ajpdf
DLwr4dEnj+zNwkuhapqNro14Jbdts8AW9lh3TxkMWhGZAI5G24jcrdHE1abppUnpdLe7eq0031ad
t+uxlVpXcm5r/Jeev5l79v6zbT/28PjZbvcTXbwePddjaeYoZJiNRnBdjGqoSep2qq5PAA4r7X/4
I0/Da1vfgL4F8T+CvCOi+JvidH+0R4d0zxHd/wDCP22v6loPhU23mm5CTRzHT4ROsrfbY0hcNF/r
j5YCfBXiP9mLxp4X+EOpePrnTbKbwbpPilvBc+rWerWd7bNqqwvP5MZhlfzkMSM6zxhoWGNshyM0
fj38BPFv7MPxa1fwL450k6F4q0Folv7E3MNwbcyRJMg3xO6HMciHhjjODggiuOliHTr/AFhxdrv8
b9f6vZm9WkqlP2aZ+nVp8AvCPxD17xvqF34e0HxVqvg79s6Sfxvqd3o9pc32m+EQ0zXF1qbBMW+l
bop2kMscdruWTP3CFyPBf7OPhPSPhv8AtCP4Q8MXGv8AxC8OfHvU/D0n/CP/AAl0b4hapaaGkdx9
kX+yLh47WxtHuEn/ANItokG+NIgGTasf57fCD9kfx18cPA+oeJ9FstDsvDOmX0elzaxr/iPTfD2n
tePG0q20dxfzwRyzeWhcxxszquGYAMCeb+L3wh1/4FePbnw14ltrS11a1t7a7ItNQt9Qt5Ybm3ju
beWK4t3khljkgmikV43ZSrjmulY6KipOlprrfe9+tt1ffyMlh9XHn17HoH/BQ3RPDfh/9tj4kW/h
LSJfD+gvrD3MOkyT6dKNKklVZZrVDp0stoscUzyRpHFI3loio2HVgPo3/ghx8XtS0K++P3g3TbTw
5f6vr/wh8SP4c0+Xw7p9/qmu6vstTFYxGWF57xGSORzYZeGQRuzQtgmvgyiuKhiXTrqvbrfTTf8A
I6KtFTp+zf8AVj9DvAn7PXi/wp+xP8R9Q8K/DbwV44/aLsfjAmleJrDRfCeieNm0nR5dLknVYrKG
O6tLOD7aZE320MYDoYd/7oRJ85/8FVvhv4O+Ev8AwUR+LWheALzTbzwnba689l/ZzW5tLVpkSaa1
iEAESRwTSSQqigbBEFPKmvn2iipiFKmqaW3/AAfLfXXvZBCk4y5m/wAPQ+xv2G7WytP+Ccn7S/jJ
/C/gvV/EPwsvfDGq+HtS1jwzYao+nzX97Lp9yjC4hkW4ikgY4guBJCjqJkRZkWQfUP7VP7MXh/4a
eHP2gB+zd4A8L/Er4iWPxwWwurTTvBlh4xn8P6DNo7XRtorF7e4gtLaPUZLm3WSOGNwbXymdjHtX
8mKK0pYxRioON7L0111231Xfb0tE8PzScr/1pv8Ad+P3/Qn/AAVb+GPg/wCDn/BRT4teHfAVxp8/
hay1x5LVLBoTa2cksaTT2sQhARI4J5JYVjHMYiCMSyk17Z8JfiHpHw7/AOCCVzdax4T8M+PYZPj+
I10fXZ9ShtoGPhzP2hTY3VtIX4K48wrgncpOwr8H0VjDEONSVSy1v+JbpXgoN7W/A/Zz9pLwhaeI
9Y/4KUarqel+M/iP4TXUvCYlk0O8gtbqV7CaOW9tI7tLS4hU6dGw87dDI8cVvmZtxaWvJf2evin4
8/bg/Z3/AG4/ivcfCy9+JM3jrWPCv2Pw/JZ393b3a2+oNssRJpxtp5mtLVrZmaNkchI3kGHIb8va
K7I5nJNXWmumnXm8ntzPR367XJjQsrX7fp5+R+jf/BKr4beIPDP/AAcI2kFz4Kt/D9x4d1zxDqGr
aHo91a6lZ+FIpLK8UW7z2eLZUgknigJGxFk2xlUb92Ph/wCEv7M3jv44/HW3+GXhvw5d3Pjy5uLm
1XRrqSOwnjmto5JJ45PtDRrG6LDJlXKnKEdeK4SiueWJjKEYTTspNvXe/LotNNt7P0LjTak5eSX3
X/zCvvb/AIJoeHdXsf8Agl3+2L4hHw7Tx7ocEXhd5LK/t9R+wX62t/LNdK0llNBKRbRSJcybJV8t
Y0d/3ZIb4JorLD1vZT57X0a+9NdU+5VSDlGyP0J+FXhsfGH9hP4mfFL4LfCfw1rvxX1z43GK48M2
fgmy8YT+FvDM9hcXVrFHZzWksVvbfai8SzRQRbzBsPyqqD1r4w/sx+HPhbon7dWpfD7wN4V8WW3w
m8TaNrngvVD4R0/V4NHvJyv9vWKj7O8E9tZ208ivaTCWK0ECy7UkXzj+TlFdMMdywUbaq+t+6lqt
NPi/BWt0xeHbbd/60/y+5n358CvDF38Vv+Cevj74l/Cv4YeDfFPxu1r4ypDqWg6R4CtfE58O+Hpt
OnuYlt9NuYLpLSya8Z40dEDHyBGzsFVa9M+Cf7Mtlafs0/FvWLvwTpEHx4svjIdN13w/4A+GmjfF
KXwzpkmnPPHbxabcXL2tpZfa3uIhLFIXSW1ED5KgR/lvRU0sXCHLeO1+tlrfVaaPX8OmliWHk72l
v5emnoe5f8FLPDfhvwl+3h8ULDwl4fuPCehw607R6JNPp8zaPM6q9xaj+z5ZbRFjnaVFiikYRKoj
O1kZR9Mf8E6/gt4W8U/8E4/EniTQ9Ev/ABF8WV+JUOl3cOhfCrTviZrFlov9lvLCzabfyLFbW0tz
5/8ApMeHZ7cIdy42fnrRWVGvGFX2ko3Wul7b+fl/Vi50nKnyJ2/rzP02+LOheBPDHhX9uLXfDHw4
8J+HpPhb4m8N6z4TsNY0DQdWuPDV7qNybLUrNzD9qtpLcK8yrZtJLDbuiMscU8eV96i/YV+E/wAH
/wBuL4tatpGheGte8NW/xT0fR9a8IPp2hHTfA/h6TR11a9127uNTsbsW2n5e5iWO3azz5BRJ9wiV
PxPorpp5goyTcbpO+/r5ea3T2+7OWFurKTX9L/L8T9WvhJ+zd45/Z9+Gf/BQ7w58OfhjrF6th4t0
fQvCmk3XhJ/EMN5bwa7JIsUVteQ3C3RSxntpgXWRlSaGbdlkct/Z68C+Dfg//wAHTceh/DyLSbHw
vpmt6mILbT5FW0s5m0C4e7gUL8sQjuWnjMSgCIqYwqhNo/KeinSzCFOcJqHwyUrX7Nuy00ve3XZB
9WbTUnurfgl+h+if7D37O2jWH/BPrxrex+FNcvPjdo/xQOga7p1h8KLD4ha/oelxacTHHPpWosi2
UL3huka5TbJ5tsImDcbPmb/gp/pfhfRf2+fida+DvCKeAtCh1UBfDq3VncLo9x5MZuYAbOee2QLc
Gb91FKVi/wBXtj2eWvgtFcs68ZUY0lG1ut99+nc1jTtJyufpZ/wTK/Y7+DX7X3/BOOG08f6v4T8K
f8I78ZJLvxn4nW/0zStc8P8Ah6Tw+0dluu7tTi1n1UxRLH84aTzCEypYav7HP7JY8O/8FxPCfwv1
X4e+ENc07T/h/o8HjXQ5/DllrWn6Xcx+E7JriWYtDLBHK2prEWuom+eS52mU+c6t+X1FdVHMIQ9m
3TTcGn6pdHpt/wAHvpjLDScpNS0a23t5n37/AMEafHXiX4aeJ/2jPhnNo2i2viub4V+KodL0XU/C
unz67e65Glup00C5gN1cfJBNu08l4yUkYwEhjW7+zz4Y+JH7LH7D37cuueIfC3hqDXbDV/DGnXbP
oOka14ch1EasXu7SOFI5tMMkAuog0EakWxkjASNgm385aKiOOtTjCz93mtr/ADK3bp/Vty/YLmb0
1tfQ+m/+CyHwn8MfBH/gpX8UvDng3RLLw54ctbu0ubXTbPcLe0NxYW1zKsan7iebK5CLhEBCqFUK
o+fvh38SfEXwh8Y2fiLwnr+teF/EGnb/ALLqekX0tleW29GjfZLEyuu5HdTgjKswPBNYtFclWrzV
HUirXd/Q2UVy8rPuz9kb4Vzav/wSo1rxP8J/h9onxF+O8HxZi03VbUeDLfxlqVh4bOjvJDIbG5gu
YoIHvPOHnpErM6bGchUUd58H/hPrPiv4Yftdtqnw0/Z/8HfE34Y6/wCH9X0uylg0D+xPDGoXly9n
qNv9qv5ZrXyGiDj7Dc3D28FwSIYYp0RV/NevUPhl+2N4++D3wH8X/DTQL7QLbwd49P8AxP7W48M6
XeXGpYVRGGuprd7hREyB4gsgEMhaSPZIzOeilikkou6t2+f3PXe/S9tEYToy1cba9/l+Hkfpp4w+
En7PXxRmOo/Czwt8O9Z8OeF/2pdJvvEt5pekpdwaP4TbSLNr+W6lkVhFoYvYdQILf6HhJSp8sJXk
v7Fn7O2nz/8ABw7418Aah8NNH1DwAfE/iQX2hal4ThvLGw0bdPPYypDNCwtoi32DypYwmVmjRWKT
bX/NWiutZpHnhUlT+GXNo7Jq7dtn3t+gPDvX3nqrf8E/UT/gk/8ABCPwr8EPA+p6B4HsdQ+Oei/t
L6R4f8ZQXnhqPVtZ8L+Go7eNmllhuYpjpiJeC6H2pI4ZVkhYGUmJRHV/Y48Far4c/wCDovV9M1Ky
vdHvZfH3i+6jS4t3ik8maz1OeCZVKqSkkMkciMAFZHVh8pBr8xaKihmSpKkox+CSlvvb5fjqTLDS
cpS5t1bb+tPI/R/9h39nbRbL/gnT4pvbbwbqt78ddH+Lb+H/ABBY2HwpsfiJ4j0bSI9MUxRTaPqT
rHZwm9+1qbhVjkMsPlMZAAIvnD9v3xda/BD/AIKO+PtV+E1hrHwi/svUQLWx0vUre3utBuntES+h
jl0+5mhhHnPcqYoZtsasYtse0xJ830Vzyxa9lGnCNmne9/X/AD6dkaxpWk5N7nZfs/8AwA8XftSf
F7RvAfgTSDrvizxA0qWFj9qhtvPMcTzP+8mdI1xHG7fMw+7jqQK42iiuPS3ma63CiiikMKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooA+0P+DfHSZ9e/wCCsfw+sbVDLdXui+KoIUH8bt4Y1VVH4kiv6q/Hfxcs
Nd0ueK107xS7uAAD4a1LHUdxBj8jiv5cf+DaD/lNf8HP+uHiH/1HdTr+suw/49I/93+lAHx38c/h
z4g+J/h77Jo+ha9POLyOciTR7y3ARUlU8yxKCcuOBnvRX2hB1NFNu4Hxx/wdHf8AKCj45/8AcA/9
SHTK/nF/4Iy+JbFfin8ZvBTahp9n4k+Lnwg8ReBvClveTrbx6trN4Lc2tksrlYo5JjEyIZXRS5VQ
xZlVv6Ov+Do7/lBR8c/+4B/6kOmV/JN8IfhD4l+PfxL0bwd4O0a81/xLr9wLaxsbYAvM+CSSSQqI
qhmd2IREVmYqqkjfC1JQrRlFXd9u99DKtTU4OLPtD9j2GD9lr/gn78V/Evx08Jap8QPhhP47tfBN
t8LbyWbSZrXxZDGt1NqMl0R52myQWcMts32dWln87ypQiIGr6K8GeEPFvxL+EX7dPibR/hYfiVof
jKP4f3vhHwpDol6tpcaPMYL7TdNWLS5LeVZtP0q50/zIraQrGYRueSMhpPzA8S/sveN/Cnwev/iB
daTbS+CtN8VSeCZdZs9TtL20fVo4DcNBE8Mr+cvkjeJo90TKQVc5Gez8E/8ABOT4tePvC2t63ZaR
4ZtdI8N2el6hq13qvjLRdKj0221O1t7qwmmN1dx+Wk8V1BsLYBdmj/1iOi9tHE1EowUG7J+uqkt7
bavTbR92clShG7nzpN/5x8/LffVdkfoNpHjjR/gN+wH8XvCPxh+GMfgDwX8Sf2l7jw54y0C3upIJ
PBOnXWnxX0Etg1qhR/sMlvbzxbYJYLmKMKIyrqa8s+MHhfxH8Uv+DkLU9Xs9HC2ngDxxpfibX7qS
eS2sdI0bSfsclzqVxPdxwLBbiCESb2HlZkRIXmV4Xk+O/j1+wJ8XP2YvC+s61458HzaFpfh/xKng
+/uGv7S4WDVXskv1tv3Urls2rpJvUFMMBu3cUyf9g34r2/7Qev8AwpPhUN8RfDWnyald6Cmp2b3c
0Udst0y2wEpF3N5DiQQW5klYBtqHa2K+tVZclN02+Vp7avWTtou7fTuWqMfekpLVfLZef69uxm/t
p/EHR/i1+2P8WfFXh65S80DxN4z1jVtMuEieJZ7ae+mlicJIquoKOpwyqwzggHivpL/gj18bP2YP
hHJ4uX9orw/a6vb3lxpzWX2ywTVVZ1vrZopIYFsGliW3C3Mtyftyx3MDiE2d0cAfENFcNHFSp1vb
WTeu6utTepQjOn7Jtpfjofob+wR+0P8Asj/D/wCPvxVvfi34Y03VvC+qa3aTaSL21h1i2uGXULZ0
ntIINDs3t7aNlu5pkDWsclpNHbnT7ho9lR/sH/tE/sk/D749/FS7+LPhXT9Y8L6vrdrJpRvLeDVr
eRlv7d0ubSCHQrR7e2iZbqeZAbWOW0mjtjp87Jtr4sP7OnjIfs5D4t/2P/xb4+JD4RGq/a4P+QoL
UXf2fyd/nf6gh9+zZ23buKwvHfw+1j4Z63Bp2uWZsb2506x1aOMyJJutr20hvLaTKkj57eeJ8ZyN
+GAYEDpjjqsFB8i93XVb36Put7fMyeGpyclffz7f0jY/aD1Pw9rXxv8AFN14Uj8vw/PqUzWZWaOW
OUbvmliKWViqwu2540Fnb+WjIhjUqa+u/wDgnb8F/GHxS/4JR/tjWnhnwn4l8R3muS+DrPTYdL0y
W7lv54NWM08cQjBaRo4pI3dEDbVkRm2jaT8J0VyUKqhPmaurNW23TXn3N6lNyjyp9vwdz9EfEH7J
Hj7Rv+CSfi34Mad4W1rxP8U/BPx2ttT8Q+HtAsrjUr/TLaTw2VEstvHGZFhSYvELlQbeZgxiklQL
I3tv/BS/xx4H1X9lX476h4q0PxB4i0aP9qO4sHh0Hxe1pcC+h8OLCWM99YXDiJHiuAYBEI0LrHDI
0UKs/wCQNeh+Ef2WPG/jz9nnxX8U9I07Tb3wV4GuYLTXrlNasReaa08kUULPZGYXXlySTIiSiIxs
yyAMTFJs6aeL5Y8sI62fZ6Wl0t0vf5XMJUNeaTX9W8/LT/hj9Tvjh+zx46+Pl/8A8FFPD/gvwX4q
1jUfFHinwVo+lQtBe3P2y4gvo3mC3N5HG0aJHJHMwGIIYJEKP9mWKRvP/wBjDxlo37SH/BzC/jfw
N9s8ReDBe6lqs2oWhvdQht7X+xZbdppHuUWSKE3EiRBWHlRmWOKIsgi3fldRWkMyUalOpy/DJPfe
0nJdNN339Cnh201fdW28kv0P03/Y+8b+HfgV/wAEdvEfgf4v6Fe2Xg/xp8f4/BPjmKcz2eq+HLb+
y4pnvIUWNpEurK6tIZTG8Ugk8p4Wj+cmvVP+CkPwxn/aR+GXxo8GeDtG8eeIdR079pOz1TWNK0DT
b7xFrlhpMnhpIP7QFlN5c/k70lEO9ktmyscMoiVXP46UVMcw/dxpNXSVt+jvpttrp2+YfV/eck9X
93T/ACPW/wBvHwhqXw8/bE+Ifh3WfiBqXxR1jw7rEmlX3ifUFuVutSntwIZBILhml3Rshi5Zh+6+
VmXaT9O/8EzfgB48+Ov/AATB/a60Lwd4T1jxBe+LbvwXpemi3tjsubiHWDLMqythAIo5EklJYLHG
4kcqg3V8c/s/fs/eLv2pfi/o/gLwHpH9u+LNfaVbCx+1Q2vnmOF5n/eTOka4jjdvmYZxgZJArjax
oVVTqe2lBuL5lvbdNb23V0/z3LlTvFU09Vb8H207H61f8FD7yw/bj/ZZ+NcHwPh1n4pXs37Rdrrb
Wvh9rzXLs2j+GPs7XQhKGdbU3cc8cchXyBtEcOEVc+7/ABL/AG2vhh+zPoHxt8Q+LPDh+I/wt8Qf
tC3PhnxTpl7ZnXJbvy/DdvI4ijvpIlLRapYxbRITFHGhEKgRxGvwer074RfseeP/AI2/D298XaPp
uj2PhKx1FdHfXPEHiHTvD2mS3xiMv2SK51CeCKacRASNFGzOiMjMAGUnsw+ZzhPmpRfNr1v0lpa2
3vfgYSwsFG0paWt27f5f1ofpL+398cfDnxh/4J+a945+KfhvVdYm8YfFXwvrV1YeE9at9EEd5dfD
vTJmMc09pe/uELSAIQxbeh35Rt9n4NeHr3xD/wAHW+vXPh2w1+9t9G1PU7jU5p472c2IOhyW0s0j
zKHjtzczLHGwCwgSwrCfLMWfzPn/AGNfijbftRH4LP4J1ofFAal/ZX/CP+WpuDNt3hg2fLMPl/vf
P3eV5X73f5fz1xnxG+H2sfCX4ha94V8Q2Z07X/DOo3Gk6naGRJDa3MErRSx7kJVtrowypIOOCRzV
SzCoqscRUp/DO/zTcmr28+t2g+rwcXGDWqt8nb8NPmfo5+yD8Q/DvwB/4I6eKPA3xd8N3kXhTxr8
el8F+NoLk3Njqnhy3GlRTPeQhEZ47uyurSGUxSRSiQRPE0R3kj5w/wCC2L6e/wDwVL+MR0v+1fsn
9qw8agbsyiT7JB5oU3X7zyfM3+Vj935Xl+V+68uvGfCv7L3jTxv+z54o+KWlafpt54L8F3cFlrdw
mtWIvNOed4o4WeyMwuvLkeVVSURGNmWQBiYpNtH9n79n7xd+1L8X9H8BeA9I/t3xZr7SrYWP2qG1
88xwvM/7yZ0jXEcbt8zDOMDJIFck61SrShh+Vt9O71em2ursvO/fTaNOMJSqX9e2y/yPtz9iLSrD
x9/wSeXSh8Lde+PEnh745pq+t+A/D97dRX9xYT+G7i2gupDZxyXEES3IG2XbsdkMfdq+av8AgpLp
2q6N+1DFZa7Yy6Vrdl4J8G2+oWMtoLOSxuE8L6UssDQBEELRuGQx7V2FSuBivOPg7+z94v8Aj/8A
8JV/wiOjvrH/AAhPh678V61tuIYfsOmWuz7RcHzHXeE8xPlTc5zwp5rjaipXk6Eaco+j779bX693
byu7kaaVRyv/AFp/kfbn/BH343fsw/CGTxeP2i/DdtrlpeTac1kt3YpqYkdL62aN4YVsTNCsAFxJ
ct9vRLiBhCbS6bAHT/8ABPz48/sg/DL41fFC5+LfhYax4YvdUtG0MXqw63FOyX1uyXFvFHoto8UE
bLdTzAvbJLayx250+5ZcD8/K7L9n79n7xd+1L8X9H8BeA9I/t3xZr7SrYWP2qG188xwvM/7yZ0jX
Ecbt8zDOMDJIFaYfG1IypxhBNxbtpdu/TzInhoPmk21ffXa35eZ9r/8ABP346/sffDz43/FST4v+
HItU8J6hq9m2itdRRa1HOy39uUubWKLRLOSG3jIuriVd9qktrJHbnT7h1AHxJ8etR8Pat8ZvEtz4
UieHw/LfymzzcJOsi5+aSNks7JRE7bnRBaQbEZUMalTXI16H4R/ZY8b+PP2efFfxT0jTtNvfBXga
5gtNeuU1qxF5prTyRRQs9kZhdeXJJMiJKIjGzLIAxMUmzGeInVpxpWXu3ei17v5FxpRpyc7vW270
7fieeUUUVym4UUUUAFFFFABRRXZfB39n7xd8fv8AhKv+ES0j+1h4J8PXfivWj9qhtxZaZa7PPuP3
rrv2+Yg2JudiwCqaqMJSfLFXYm0ldnG0V6f8I/2OviB8bPh3eeL9H0zSLHwjY6iujvrviDxDp3h7
TJb4xed9kiudQngimnWLEjRRszojIzAB1J6e8/4JpfGnQtQ8UQa94RtfB0Xg/Wh4c1O98V6/pvh3
TxqJh88WsN1fXEMFzIYCkwEDyZhlik+5IjNcaNRpNRdn5EupBOzaPCaK6X4xfB3xP+z/APE7WvBn
jPRb3w94n8PXJtNQ0+7UCSBwAQQQSrIylWV1JV1ZWUsrAnmqiUXFuMlZopO+qCiiipGFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFAH3b/AMG0H/Ka/wCDn/XDxD/6jup1/WXYf8ekf+7/AEr+TT/g2g/5TX/Bz/rh4h/9
R3U6/rLsP+PSP/d/pQBcg6miiDqaKAPjj/g6O/5QUfHP/uAf+pDplfzif8EafE+mx/FL4zeCp762
tfEfxd+EPiHwL4Tt7idbZNV1u8+zm0s/OcrHG0zRMimVlVnKpnLqD/R3/wAHR3/KCj45/wDcA/8A
Uh0yv5KPg18GvFH7QvxS0PwV4L0W88Q+KPEd0tnp9hbAb55DkklmIVEVQzO7kIiKzMyqpI6MLUcK
0ZRV327/APBMq8FODi3Y+zP2QLWH9lb9gb4oeKfjp4OvPiJ8LrrxzF4GtvhdfXM2kXNn4rgjjup9
Se52+dp0kFnHJbv5CmSczeVKFjQGvphvAniD4l/D/wDbj8WaB8OtW+LugePovh/qvg/Q5vDeo20O
o2Motb6DT1i0yWORn07T7u0R/JnBxHHI2VkIP5beJv2W/GvhP4M33xCutP0yXwZp/iyXwRLqllrd
jexNqscH2hooxDM7SxGL5luEDQOPuyMeK7zwp/wTJ+MXjHwLq3iW10fwna6JoFtp15q11qXjnQdN
GkQ6hbwXFjJdLcXkbW4uI7mLy/NC7mLoPnjdV7aGIqWVONNu19t9pLs7rXZ6aPTVnPOnFNzc7X89
Onn/AMF3P0HvtTsP2af+CfXxS8JfGf4Y2ngTwZ8Tv2k5dG8XaDp+oDf4I02+0i01S1ewlsw8TSWJ
W3lVBBIkiReUYxvATyL45fDW+1v/AIOSNUv/AA/4WTRtH8EeOtJ8ZeIHZrWysNL0yzNldX2r3Eyy
GCC3kAa48yRwxNwiuBM/l18Z/GX9hn4m/ALwLrXibxPoem22h+HfFZ8D6jd2fiDTtSW11kWgu2sy
LaeRiywk7mAKK6PGWEiOix6f+xH8StY+PHiT4YWGh6fqXj3wpaXN3f6NZa7p91O/2eISzwW5jnZb
u6jXdutbcyTgxyr5e6OQLrPF1ajhB03aLXru9Hp69N72XYjShZtSWv8AwPP+tDL/AGufGXh74i/t
XfE7xD4Rjii8J674s1XUdFSO2+zIllNeSyW4WLA8sCJkwmBt6YGK88oorx5S5pOT6nZGPKkkfcf7
Emoad8DP+CbHxD+IfxY8OP8AFX4K+I/GNt4R0jwF9vksFHiiO3jvTq32xR5lkYrHzIc24Zrjz/Ll
CxopP1l8Tvhl4c+Lngz4mfEPw3oWseMPH3ijx/ouqWU+lfCDSfHuuaV4NvvCtreaPZNot3P5FtbQ
CRrZryPmSWzVSznIT81v2aP+CeHxZ/bA8D6j4i+Huh6FrWlaRqdto160/ivSNOntbq5eOO1jeC6u
opQJ5JVihbZtmkDxoWdHVfHtf0C/8J69e6Vqtld6bqem3ElreWd1C0M9rNGxV45EYBkdWBBUgEEE
GvRWMqQhT5oe6r2v13Ts99G9NbLXTVnI6SnOXLJX6rte1rq/l8z9Mvi54b8FeE/Df7cXiLwz8LvB
fhq8+EniDwtqXhzTNV0TRNZl8M399P8AYdUhbyzd2ksBZplFk0kkFvIyFIopYR5fyj/wV2+GWg/B
z/go/wDFXw54Y8Jv4I0Ow1OJrbRyY9lv5lrDKzxrG7okUru0scY2+XHKieXEVMafOFek/CP9krxz
8bPA1/4o0ax0Wz8MabfxaVNrGveItO8P6e15IjSLbRz388Ecs3lqXaONmZUwzAAgnGeIdaPs4x1b
vp/283pbzW1lpsbRgoPmb/rT+vmebV+gn/BKz4e+HtZ/4J0/tP3fxPvvFHhX4R63rXgjTNY1/TNO
e4ZFi1kPcLBn5HliSeEuAJXiS4WQQynbG/xB8XfhHrvwM8eXPhrxJBZW+q2sFtdMLPUbbUbaWG5t
47mCWO4tpJIZUkhmjdWjdgQ45re8JfsreOPHf7Oviv4raTpunXvgjwPd29jrt0utWK3emyXDxxwF
7IzC68uR5QqSCIoxSUBj5UuyMO5UqrvC7SemvZ3v106jqpShvbbX5/1Y/UPxT+zhpekeBvjXOvwc
0bwr8Z9M+L8GmXmieAfhjpPxNk0bw22iRS6aselXrxR29tcOZJnvkiheWYhDGpzFDyHxG+CWj2ng
j9tnxp4J+COl6PH8MfEOiah4RtL/AMKaTrf9g6gQieIYGMX2uzlhgt5JJZbJpZYLLzI5BFA8YaP8
qKK3eOjZJR7637312316WTsrrQyWHab17dPTz2Puf4D/ABD0X4nfsc/tXfFT/hW/wm0TxF4O1nw1
r/hqztPClrdWGhXOoXktleLFFeLceZaPCWxaTtJbxSOskMUbRoU+u/jx+yf8KvBdp8eU+G/wzvtK
8e6Z8YrXTm07w98ONJ+JupWOhzeH4riIxaTd3HlWVhPevdzJcRhGGYYNo8sxw/i7RU0saoJJxvbz
666+T1W3ZDqYe+sXb+l/l+LP1B/ZA0jwz4a/4ObNMsfAnhOfwBolvq+pRR+H5buzmfSLj+wbkXcJ
NnNcW8eLkz/uY5GWHPlbU2GNfz7+DHhvUPC37T/hTR9VsfDWl6rpviizs7yz8cRNb6PaTpdojxao
jgFLZWBE6sAQgkBxiq/7PH7PHjH9q34xaP4B8A6P/b3i3XvO+wWH2uC18/yYJJ5P3kzpGuIopG+Z
hnbgZJAPFUqmJbpx93aUpX6a8t1t0svv2RUIJSaT1svXrr+Z2X7Rcvn/ALQfjt9vg1N/iHUG2+ER
jw8ubmTjTh/z5f8APH/plsr7b/ZNsx45/wCCJ+p6D4a+Etp8cvGdh8bxf3vhoLqt7NYWEuhLHDfN
b6VcwXMa+dHLEskjeU5kZQGdMr+eVem/CP8AY/8AH3xs+H974t0bTdIsvCVhqSaNJrmv+INO8P6Y
988TTC0jub+eCKWcRKXMcbM6qVZgAyk50KjVVyjG976evyf5FVYrks3bY/Tr4H6h8Df2Tf8Agof4
g+BPwjh+JPhnx3qHxm0+CTW9EsrbxFHd+F4Esp7jw/Nc/boprS0S+ju3uZESSUW9uiXHnGORR8b/
APBQCD4UfDT9vz48aX418D/FnXNafx9rF7FdWviSy8MxrBcTCaNfskum3rOu95XScTKs8MkDiKLk
N4XF+x38TZ/2oB8GE8Has/xObU/7JGhKEMpnxu3b93leT5f73z9/k+V+93+X89cb8Rvh9rHwl+IW
veFfENmdO1/wzqNxpOp2hkSQ2tzBK0Use5CVba6MMqSDjgkc101sXUdFQ5LJSfTT0ta1/wCrGNOi
lO/NfRf8P3P0E/4J3+F/FWrfsFftea78F/hn4p1Sw1OTwjY6Jper6JbeNjfTwXwe8h2PYLbXckaz
CcoLbdAksTHlRKe8+BfwC8BL/wAHJfinwP4f8AeD/EXwrt5rxPEGjnQrTXNI0kDTUknOySOWOzEe
q7Iv3fl+UzfZ1KKxjP5z+Ev2XfGvjr9nzxV8UdJ0/TbzwX4IuoLTXLldasVvNOeeSKOFmsmmF0Y5
HlVVkWIoxWQBj5Um3O+AfwD8W/tP/FvSPAvgXSTrvirXjKthYi5htjcGKF5nG+Z0jGI43PLDOMDJ
IBdHGSi6ScL2adu+r0WmibdnbsOVFS5tVZ6eey3dz7Q/4IueOte+Hvif9ov4bXOkaFb+J5fhT4qG
kaJqfhewn1vUteiS2C6btnga5uhiCUtprl4WMUjNASGNfLGr/s1+NfF37bEXwp1mPwxo3xB8SeLI
PD9zFaz2f9ladqF3cpH5edOD28Uccku1o4FIi2sgQFNg5f4QfALxb8eh4pPhPShqv/CFeHrrxVrO
buC3+x6balBPOPNdfM2+YnyR7nOeFODjI+HfxJ8RfCHxjZ+IvCev614X8Qadv+y6npF9LZXltvRo
32SxMrruR3U4IyrMDwTWM63NSpwqJ8qbtr06203Xe/yKVK0pSg9X+Ze+N3wn1H4CfGfxf4F1iayu
dX8F61eaFfTWbs9tLPazvBI0bMqsULISpZVJBGQDxX03/wAECl3/APBW74QqQxVptUDbVDHH9k3u
eCDnjtg5r48r1r4I/sQ/EP8AaH+FfiHxt4XtPC0nhjwnOlvrV9qfjDR9IGltIY1iaZLy6idI5HkV
I5GUJI4dEZmR1XPCzlHERqU03Zp2W+jv2f32+RdRL2bUnvpc+mv2FfhZPY/sp+OtLT4NeIrj4k6F
49jstV8QWHw/0b4jazp1sllMDpNx4c1KVJtORbiOSQ36x4kdXgYhoQp968K/Abxx8OfBH/BQC1+H
3gjwj4ovxrvhvT9FsvB/gttZ8O391FqAlvba1026F3GJ7eG5Ek9rmYWcjEJtWOJh+f8A4Z/4JxfG
vxZ8ZPF/gG28CXtt4o8B3EFnr1vqF7a6fb6fNcXEdvaxm5nlSBnuJZYxAEkY3AcNFvXmoPhv/wAE
/fip8UvBni/X7DR9B03Tvh/qR0jxMPEHivSdAudAut6xiO6t765hmh3SN5as6BXkSSNSXjdV7Kcp
xjGPspXu9VdPZppaWur69dDGUYtuXMtbfp5nqf8AwUV/Zo8LeIP+CxPin4UfCQeGNH0jxB4r03QN
NS3uy2ladf3cdrHcIWjVvKjjvZZleNExDsZFQBAtfNvxu+E+o/AT4z+L/AusTWVzq/gvWrzQr6az
dntpZ7Wd4JGjZlVihZCVLKpIIyAeK6f4ieAfin/wT0/aSvNC1KfWvhz8TfCGzzJNI1hUvNP+02qu
Nl1aSkDfb3AB2P8AdkZT3FeYVxYiScpXjaV38vKxrSTsmndWXz8z7v8A2RvhXNqf/BKLWPFHwm+H
ejfEX48D4sppWrW//CIWnjTUNP8ADX9jmWB/7Pube5W2he8Mw+0pEpkaPYXIQLXoWsfCHVrP9j74
l+IfBfwV+GjftIp8aW0fxR4V8K+GbHxvbeGdEOjLMqQWMw1COyhN+bkF4SMSpJBlBAsSfAH7P37P
3i/9qX4u6R4D8BaO+v8AizXfO+w2C3ENuZ/Jhknk+eV0QYiidvmYZ24GSQK42toYjlhFuLtte9tV
203V1+F0T7JOTu/6/wAtPzP3H+LX7P8A+xz+z+Pidrni/wAEeAD8NvEnx4k8C63rEIvruTw9aQeF
LbVTBpv2L57NxrJlilW2ACpK8DKsaJs8e1j4ZeHfi18EvjR4r8KfDf4K+F/Fmk+D/h1450Vb/StH
0zRNF1LWLZIdRWOTU4ktvsj252pbXE08KzfvUP2snb+bvhD9lTxz49/Z18WfFbSNM0++8EeBbq3s
9euk1qxF3pjzyRRQM9kZhdeXJJMqpIIjGxWUBiYpNlv4a/th+PfhF8BvF/wz0G+0G28G+PTnX7Wf
w1pl3calgJ5Ya6mt3uQImQPEFkAhkLSRhHdmPRPMFJJOHLq3dWTd76dNE3p2a67GMcO18MrtWWu2
lune33+Vz9Pfhh+zr8D9Q/ae+I3xF+G1t4D8feAZfitp/h/WPDtrYaDJovhHRINMW/1PXZ7jVLK6
WDTGuPt0KfZTaRP9lZYZ3BgCeZ/sYW15+zz+2t+2N8GfD3hzRtKWLwf42HgjQdQ8MWWpazq0+6Jt
PsYXuoXvL6GWzRZFtS0sUygzGJ/mevy/oqoZqo8soQtJSbun0d7rbT/gbGzw909eh9QeG/2Qvi1o
fxP8e6vqPwQ8KfF3UNC1uTQvEHh7Sbv7dHoWpSkXO4WXh29hlgjAWWFSoFqjCaEASxbY/t79sr9l
vxJ8dv2w/j7451m9+Kvxh/Z68G+OYzZ+CPCd3LqL+LvFcek2CS2OyyjaOxitYZIoLi/li89YY0gV
5rliy/kDXUfBf4OeIP2gvinongrwrb2V54k8R3Is9NtrrUrbT47qcglIhNcyRxB3I2opcF3ZUUMz
KpwoYqCXs+Ryu091e+qt8Ou/W+3mFSl9pu1l8un3bHon/BRnU/inrX7aXjq7+NVhaaV8Srm5gk1a
ytZIJLeyQ2sJtoYmheRDGlr5CqfMdtqjezPuJ8Tr0HRP2XPG2v8A7Ssvwhh0ywh+IMOtXHh19NvN
XsrSMahBI8b2wuZZVty5kjZExJiRyqoWZ1B5f4jfD/V/hN8Qte8K6/aix17wzqNxpWpWwmjmFvcw
StFKm+NmR9row3IxU4yCRg1yVlOUpVWnZt79+zemprCUbJJ9DGoor034Sfsf+PvjX8Or/wAYaPp+
i2XhPTtSj0aXWtf8Rab4f0+S+eNpRaxT388Ec0wjXe0cbMyIyMwUOpOcKcpvlgrvyKlJJXbPMqK7
L44/AHxb+zh4xg0LxhpaabfXlhbarZyQXkF9Z6jZ3EYkhuba6t3kguIXU8SROy7lZc7lYDd/Zc/Y
v+Kf7anjGXQvhd4I1rxfe22PtUlsixWdhuSV0+0XUpWCDeIZQnmuu9kKrubApqlNz9mk+ba3X7iZ
VIqPO3p36HmFFen/AAo/Y4+IPxn+F2oeONI0vSrLwZpupx6JLruva/p2gabLfvEZhaQ3F/PDHPOI
l8xoomZ0RkZgodSew1j/AIJffGzwzo1xq2seGNF0Hw7C9nHB4h1fxZo+naDqrXds11AtjqM90lpf
FoFZyLWWXYMBtpIBqOHqySlGLafk/wCujB1IK6b2/r9V954BRXvur/8ABMP41eG9DutY1jw1ouge
HYJLOKDX9Y8WaPpuias11bm5gFhqE90lrf5hBc/ZZZdgxv25GZ9T/wCCWXxv8P6Hcazq/hjQ/D/h
qKSzht/EWs+LtG0zQNWe7tjdQLY6lcXaWl8TAC7C1ll2DG/aSBTeFrLeD7bPf+k/uB1ILdo+e6K+
gda/4Jc/G3wto9zquteGdD8PeH4TZi317WfF2jaboerG7tjdQCw1Ce7S1vy0A3n7LLLsBG7aSAXa
5/wS1+OHhTQrjWdb8K6P4e8NxyWcVv4h1jxXo+m6Dqz3dqbyBbHUZ7pLS+LW6mQi1ll2AgNtLAE+
rVv5H9z/AK6P7he1h3R8+UV2Hxu+Aniz9nTxdbaJ4v0tdNvb7T7bVrKSG7gvbTUbO4jEkNzb3MDv
BPE6nh4nZdyspIZWA4+sZRcW4yVmi076oKK2NE+HfiDxL4T1vXtN0LWdQ0LwyIG1jUbaykltNKE8
nlwm4lVSkXmSfIm8jc3AyeKx6Qwor1T4QfsXfET44fC7UPHGjaZotj4M0zVY9Dl13xD4j0zw7psu
oPC04tIZ9QuII55xEhkeOJnaNWjZwokQtzvxz/Z/8W/s2+NINA8Y6UmmX95p9tq1m8F5BfWmo2dz
GJYLm2ubd5ILiF1PEkTsuQy53KwFunNR52tO/Qj2kebkvr2ONor1L4QfsY/EP43/AAxv/G2jaZo9
j4N07VI9Ek17xD4i03w7pkt+8TTC0huNQuII5pxEvmNHEzMiMjMFDoW6ef8A4JmfGvSZPFZ1vwlZ
eELXwVry+GNVvvFXiHTPDtguptCZxaQ3V9cQw3MhgAmxA8n7qSKT7ksbNUaFSSUlF2fl/XZ/cDqw
Ts2jwaivozVv+CUHxz8OeBk8U6x4b8NaD4TuLuGys9f1jxvoWm6Rqcs1pFeRLaXk94kF0Gt5kcNA
7jhxndG4Xz7wp+yJ478efF7VfBGhWOh65rOhadNq+pXOneI9NutHsLKGATy3Mupx3BsUhRGUM7Th
Q7CMnzCEqnhayai4O78mJVYPRNHmlFe8zf8ABMz416U3iltb8JWXhC08G64nhrU7/wAVeIdM8Paf
/aTwG4W1gur64hgunNvtnAt3kHkywyZ2Sxs0+o/8EvfjXoWlXOqat4b0HQfD8ElpDB4g1jxhouma
Dqj3Vt9rhSx1G4u0tL5jARIwtZZSgYb9uRk+rVv5H9z/AK6P7g9tT/mX3nz/AEV9Bap/wS4+Nvh7
SrrVNY8NaD4f8PwSWcUGv6z4v0XTNC1V7u1+1wLY6jcXaWl8TbkSEWssuxWXft3DPl3xx+AXiz9n
DxrF4f8AGGmR6bqFzYW2q2rwXsF9aX9ncxLLBc29zbvJBPC6MCJInZchhnKsBM6FSK5pRaXoONSE
nZNHHUUUVkWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3b/AMG0H/Ka/wCDn/XDxD/6jup1/WXY
f8ekf+7/AEr+TT/g2g/5TX/Bz/rh4h/9R3U6/rLsP+PSP/d/pQBcg6miiDqaKAPjj/g6O/5QUfHP
/uAf+pDplfzhf8EbfF+nWHxO+M/g6a8tYPEXxb+EHiHwJ4UtZ5RAura1e/Z/stmsr4iR5WjZVMro
pbChi7Irf0e/8HR3/KCj45/9wD/1IdMr+Sj4NfBrxR+0L8UtD8FeC9FvPEPijxHdLZ6fYWwG+eQ5
JJZiFRFUMzu5CIiszMqqSN8LUlCrGUVd9u5lWhGcHGWx9p/si6Yn7Kv/AATr+J/iz46eFNQ+IPws
1Dx+ngOz+Fd5cz6TcWfiy2hiu7jVHuSvm6bLBZq1s3kK0k5mMUypGik/Stj8I/HXjf4I/tkeO7L4
RS/Ejwz8T7LwJqvgLw5b+Hr6LTrvRfOjlsdMVNLNu/2nTtMlsBLFaSkRmIF5JEJMv5Y+Iv2XPHHh
b4K3nxGutItn8D2PiuXwS+s2up2l3ay6tHB9oe3iaKVvOUQ4fzow0RDJhzuXPbeFP+CbHxh8YeDN
S8RQaD4fsdC0ew0zVL6+1bxdo2lQ2lpqUMMtjcO11dR7YpxPGquePMEkRIkikRe6liJcqpqm3b72
/e8teumys9NWc1SguZzUrP8A4bz02Wv/AAD9HdZu7T9mn/gnD8RfB/xr+GFh4A8EfEr9p670XxZo
+mawGbwXp1/oun6nA1k9ikkTNYbLOZAsUiSJG0JhXdgeTftZeA/EPir/AIOXdRvotPtYrXwR4s8P
+KtdvRff6Do+j2Ftp1xPqN1cyCNYI1gQO+4/K7iJXkcqX+LP2gP+Ce3xh/Za8I6xr3jzwbLoOkaD
4mj8HX10dRs7lItWksE1FbYeTK5c/ZJY5S6AoA6gsGO2ob/9gb4tab+0L4i+E8vhMj4j+F7B9Svf
D66nZveSxJbpclLZVlIu5vIkWQQW5klKhyEOx9u7xtSajSdNtRkrd95e7fl7t2SSWj07ONJX5ubd
W/LXf+rr55P7Z/xG0v4w/th/Fjxdol0t7o3inxlq+r2FwsTxC4t7i9mljcJIFddyOpwwDDOCAeK8
0or1j4IfsSfEP9oj4Y+IPGfhe08LyeGfClxFbazfan4u0jR10tpWjSFplvLqJo45HkVEkYBHcOqs
WRwvkWnVm2ldvXQ6/dhHskfUP/BND9mPx98f/wDgmN+1dpnhHwdruvXfi6/8HaLojw2zLb317FrC
STxJO2It0MVxDJLuYCKKVZHKrgn6R/bruPD/AO0Z4T+NvxR/Z68H+Efi18Tv+Fy2GhXV1p3hy28c
XC+HbbwxbxCVbG5tZ0htDqEFwFvY4gtw2V82VY0J/NP4z/sFfF39nj4faz4p8a+Cr7w7oXh/xe/g
O+uLq5t90WspaLeG3EayGR1Ns6SrMimF0dCsjbhm5+0F/wAE7vjJ+yv4J1TxH4+8GS+H9G0XxLH4
PvLh9Ss7jydVk06LUkttsUrsxNnPFLvUFBvClg2Vr0IVqlOlyezem71/v26aPV/d5M5ZRUpcymtd
vw89b6ff5n6p/Eb9n79kz9nrSfiR4g8cfDn4dJ8OPEHx5k8Ba5rEZ1C+l0C2h8K22qm3sVs2EtlI
mr745FtiMLPNbunlxR+Wz442ugfEH/gnT4Bj079mnR/HUep/EDQfiFrfw0+Hj3+mtqNrqXgOKIXw
t7RHnsbVL5XRJE3RzSWkoLM5mJ/LnTv+CbPxju/A9t4ou/DWlaB4VvobCa013xB4n0rRNKvDe2gv
LeGG7vLmKGW4NsVlaBHMsSspkRMjOb4Q/YE+Lfjf9p3VPgzZeEXh+J+kNKs+gahqVnp9xIYwGYQt
cSok5MbCVfKZ98WZF3RgsOp42pUdoUN5PZa3d/d2s7dFbo9O2cqEZNtz/rTz09f+HOt/4KgWD6B8
cPBOi3ejRaJrHh/4X+DdO1aBg6Xhu00GyMgu43AaKdNyxFDyqQx5wcge7f8ABKv4X+Htc/4J1ftP
al8UJ/F/hb4Raxq/grS9V8S6VpZuRGItbje5jiLDa8kaXFuzhBK8SzxyeTLlY5Pkf4Yfsf8Aj34x
az4xtfD9jodza+AAG8QaxceJNMstD04NcC2jLanPcJZN5szBYtkzecMtHvUEjpvCP/BNT44eNfjd
4s+HVp4Cvbbxb4HuLez1y21K+tNNt7Ca5njgtIzdXEsduz3MksYtwkjG4DhovMU5rzoOo6zrKm2m
3pr1vp5+e19djV8kafs+dK39XP0c+Jn7MFjZeBPjLfW3wd8LeGfjVpPxji0u98P/AA5+G+mfEmXS
vDR0G3m0xk0m7MUVtaTsZZnvVhgeadzG8SbTFDxnxH+DNhp/wt/bS8X+DPgPpWi2Hwt8SaJqPhFL
7wfpGujw/qjJDF4htXmiF3bTww28jyyWDyzW9iZEkENvIoK/AHhb9hT4n+LvhV4/8ZwaFptlonws
uZbLxYmqeINO0zUdBnQhfLnsbmeO6VnkPlRgRHzZleKPfIjIPIq6auPvGzp21bvfX7Xlum+lk7ba
KxTpacvMna36ef59z7q+BXxO0b4p/sa/tVfE5vhn8JdC1/wTrHh3xF4YtrHwhZ3Nhod3qV4bG9jS
O8WdpbSSBWK2c7S20EjeZDFE4Vl+0f2ov2L/AIV/DKz+ObfC34eiPxzp3xhsLSax8LfDTTfiVqOm
6HdeG7O+iVdHv5VisLGS+mvWS4iVAzBbdd0cYEX4+yfs2+NYv2a4vi+2iEfDqfxM/g5NX+1QYOqp
apdtbeTv84fuHV95TYc4DbgQPT9G/wCCVfxt1r4YReMxoXhKw8NPpVjrkl7qfjzQNOFnY3237HcX
CXF6j28c5cLGZVTe4dBlkYCaGJnypezctb/+lXtZaXv0/l8tFVordSt/S/y/E+wP2RNF8L6F/wAH
PGn2XgnwZB4L0CPVtUCeGzc2V0mkzt4fuTdQ5sri5tk23BmPlRSssP8Aq9sZjMafnp8IPDWo+DP2
n/C+j6xp/h3SdX0nxRaWd9Y+OIGg0mznju0SSLVI2AZLZWBWdWAIQSAjIrsv2iv+Ccfxm/ZO8E6p
4j+IHg3+wNG0bxPH4NvLj+1rG68nVX06HU0ttsEzsc2dxDL5igx/Pt3bwVGl/wAOuvjba/DnSvGO
peGNF8O+Edds9PvdO1zX/Fmj6Lpt8t9bvc20UVxd3UUT3DQIZWtwxmjRkaREEiFlVrVJtQVNpqcp
W9baWt05fz00HTcI+/zq1kvu679br/M8z/aS/wCTivH3/Ilf8jHqP/Inf8i7/wAfUn/IN/6cv+eP
/TLZX3h+yjbzeP8A/ggrdeGvC/wr0347eLdN+Psup3/hNIdVvbzTLGXw7BHBqMkGlXMF0kRlhnhS
SRvJZvNGC6gr8tRf8EvfjWh8eC/8NaF4ff4Yaiml+KU17xfo2jPo0sgQwPIt3dxkwT+YnkzqDDPn
9074OOc+Mf7Bvxc/Z9+HOreLfGngq/8ADugaJ4sbwPeXF3cQBo9XFmt6IBGHMjo1rJHMsyKYXSRC
sjBhnCMK1ObquDtr09e6t3+4qfJOHJGS6fp59T9NPhXN8Dv2Pf8AgodrvwC+C0PxG03x7qfxf04T
654bsIPEX2vwxFb6fd3Hht7o3iTWltFqEd6bqRInlWC1VLg3Gx0X4x/4KB6f8JvhR/wUA+OekeNf
A3xe1zV28e6pfx3MHiOz8Lr9muJBOii1m06+Z13ySPHciZVngeBxDEWIr5o+LHwO8UfA5/Di+KNM
XTG8W6DaeJtKAuobg3On3QZoJj5TtsLhSdj7XHGVGRW/+zV+x98Rv2vdb1Cw+H3h3+2pNK+zLeTz
39rp1pbvc3CW1tE1xdSRQiaeeRY4ot++ViQisQcdFbGynD6vGnZ8zaW+99LNdLkRocnvylpbXzfe
9z7V/wCCd3hDxRq37A/7XviL4N/DHxZqWn6rL4U0/wAOabq+hQeN/t9xBfrJe25VrBbW8kiinWdl
+y5hSWFyAwSU+ifBX9nX4d3P/BzD4k+H/hDwD4M8Q/CyJruPWNEl0S31vR9NZdHWW4GyRZktBHq2
I8oV8l28gbVJiPwD8N/2APip8UvBnjLX9P0TRdO074d6iNK8Uf294n0rQbjw/cmRYlS6gvrmGWEN
K3lKzoFaRXQEujqutp//AATH+NF3L44S78N6HoDfDa+j0/xMNf8AFuj6J/Y8kuzyHl+2XUX7mfzE
8mcZinz+7d8HGmHrVYxg1SbtJPbR25m0tNLp677bE1KUZc3v2umvS6Wr16dPXzPoP/gjH8RfEnw8
8SftCfDCbRdBh8STfC3xYNK0TUfCVhc69qOuxRW2NNxNbPd3SgWzs2nOzQkxSs0JIfPyvr/7OHjP
xH+2fH8LtcTwvovj3xH4og0S6itZ7M6Vpt/eXCJsP9nCSCFI5JtrxQKfJ2NH5ashjGx4O/4JwfGr
x18a/FHw8sfA1zD4r8GXVvZazb6hqFpp1tZT3EyQWsX2q4lS3d7mSRBbhJGNwGDReYvNZ2g/Bj4z
/s2+BX+Mul2fizwDZeG/Ftx4EbXbW/OlalpeuLaNJcWOxXS6ikFuziT5QoDFGOTtPPKUnTjSqQla
Lf3dVa2673+RqlFTlKLV2l/kvvOG+M/ws1D4GfGHxX4J1eayudV8HazeaHey2cjSW0s9tO8MjRsy
qWQshKkqCRjgdK+1f+Canw9luf8Aglh+2BrmueB/HXijwbdjwzBIugv9ge9+xXz3d2Ib17a5jVrW
N7e4mHkybYGLN5YZZB4X4r/4JW/HP4far4ltfE3hPSPCcXhHVbXQ9Sv/ABB4s0fSNMTULiyF9FaR
XtzdR21xP9lZJWjhkdo1kj3hd65qWf8AwTK+M0z+O1u/DuhaGfhlfppvij+3PF2jaP8A2PLJs8lp
PtV1HmGbzE8mdcxT5/dO+DiKdCtGo5Rpu2qtZ+a7dNfu1KlKE4W5l0f/AAd/uPuj9pr9sfw5+2f/
AMEg/Ffxc+J3gjVGtPFv7S8vk6N4U8Rw6TNZmHwjY29uZLi4srvzQsEBDYjTzJZHceWo8s+5/tbf
DPxFrXxL/wCCh2oaT8LNQ+KVvrn/AAruw0vRm0zVJrPxFcQW+nz3USNYyxXMktvFPBcOkUu5VeNp
PkbD/kf+0F/wT3+MP7LPhPVdd8eeDZtB0jRPEcXhK9ujqFpcpDqsmnx6ilr+5lcs32SaOQlcqu8K
SHytb2if8EtvjVrvw8HiwaD4XsPDo0fT/EEt9qnjjQtNjtLC/IFlcT/aLxDCs7HanmBSzAqBuBA7
frdaSdOrTbd7vvf37307t6Pblat25pYan8cZWX4fZt18vxIv2iP2YfFuq/8ABSXWvhjqHg/R/hT4
p8ZeM4rW08NtexXOn+GRqs6S2lv51orI0EUV1CN0SH5BwgI2Dyj43fCfUfgJ8Z/F/gXWJrK51fwX
rV5oV9NZuz20s9rO8EjRsyqxQshKllUkEZAPFeu/Eb9jf9ob/gnjNc+PtT0vX/hxdeFPEi+EW1zS
fEECXNhqk+lpffZo5rScvl7C5RmZDs2ylC24la2rL/gjZ+0XffEufwb/AMIPpNv4qh1KXR49LuvG
GiW1ze3cVha6jNFbLJeKbkxWd7azSGDeI1mXcVOQOGrRnJtKnLmcvz2Wy10fRbbG8asYpOU1a3f0
19NV1e6+fY/8G9Mvkf8ABYH4Qvtdwv8AbOQoycf2Jf8Abv8AhzXV/sHfCz7N+yX470g/BnxRN8Tv
D/j6O11XxFpnw50f4k6xp9olnKj6TdeHdSnjl01EuEeT7csWJX8yB2UwBT8afGX4F+IfgLrWm2Pi
H+wnfV7EalZT6Pr9hrdncwGaWDetxZTTQkiWCVCu/cChyBxXH04Yj2cY05x1i297bpLtpa17hKgp
yc090l9zb/U/YLwz+zn49+F3w8/4KFL8PPAvhPxReweIfC+k6NZ+DPBTaz4Y1G8i1ATX1tb6bei7
Tz7aK4SS4s8TLZSyYUxrHCa+PP8Agpl+zj4U13/gsn4x+Fnwht/Deh6NrvivTtB023tZz/Zmnahd
RWsdzH+73+VHHeyzhokXEO1o1RQgQfIFbXw7+JPiL4Q+MbPxF4T1/WvC/iDTt/2XU9IvpbK8tt6N
G+yWJlddyO6nBGVZgeCaupjKU48jhZc19+l5aLTs/wAETTw8oS5ua+lvy3+7t1Ze+N3wn1H4CfGf
xf4F1iayudX8F61eaFfTWbs9tLPazvBI0bMqsULISpZVJBGQDxX1/wD8E1/h9H8Rf2Av2jtTtdE+
GF54x+G1/wCGtV8J6j4s07QUhsJ7+6lsrwT3WpgQyQNbKQsF0zwJMVkjVLjY5+GK9L+F/wC1548+
DfwT8Z/Dvw/f6LbeEfiCip4gtLnw7pt7LqIQDywbieB508phvi2OvlSZkTa5LVy0akI1OZ3trtvt
obVISlDlW+n56n6nfDn9n/4B63+1v8T/AIgfCyz8A+OPhw3xY0rQtV8NppuhyaJ4U0ODSzfarr89
3qlldiDS2uFv4kW0e0SQQbYZmH2ZUj/Zx/ZZ0n9nr4h65Y/Dj4ZaTN8QPCv7XFnouoxXvh4+INY8
N+A8CawuQl3FPJZWbEtImoxGOWTCkzNtjI/GqivRjmkE1J09U29HbfotHb7/AJHM8Fo482jSWvlb
X8PxP2q+FXwTufDfx/8AGeqeGvAWl6x8aF/bESPxRcXnhZdb1fRPB0zfarXUAlzBL/Z9nJJJNMt/
CsTvhG80rHHjzDxf+zr4o0HwF/wUD8c3/wAJoNQ8QfDX4lx634R1TWvAtpqQgNzf3B1Js3NtILy3
XSri3uTDKJLeGOeK7CxuYpj+UlFKWaXhycvVvfvfy6Xv8uhf1aV9WtUuna3nt5HTfGX4jQ/F34oa
14mg8M+GfBya1cG6bR/DtvLb6XZuQN4gikkkaJGbc/lhtiFyqKiBUX9AP2IbjSvHf/BG2z8Ot8LN
Y+P8nhT4/TeIdf8Ah9oN3fwai+n3HhZ7W3vJXs0eWCAXUeRIq4ZoCjHDCvzZorgo4hwqe0av93X5
NfhY2q0lOHJt/X3n7K/ta/BL4dal+xt8M7P48eGrT4a+FfDGk/D3Qbrx5pmlQS+NIdf/ALJhGo+H
7qFYpJhawaUy3bLcGCWCXYyx3geK3HH/ALEvwL8eaf8A8HJ91PcfCnQPBdp4M1C9/tCw8E2Hm+Gf
DtrPoFyunSGWKNY41uY/Jk3ukLySSufLjkJjX8mqK7KeYxhOM1D4ZKW/Zt2bt56frpbm+qPkcebd
W28ku/lt/wAG/wCoP7NXws1XQv8AgkxH4A8U/BDxd8VvEvgr9oCXXPE/wqtl1LTfEMVjdeExFZ3l
zHbxtdWtsZirJJ5YEpjKbsEV9M/tSaJYa7/wS/8AgH4GvPhFr3xt8R/DjWPDVz45+FukXU9r4gsV
fwQttFLeJYxyXdlGJhFhp0SR2gaM/J5e38JaKmGYKMYxUdvTs1rprv1uvLVlSwrcnJvf/gefl6+e
h+7X7SmkaVr/APwS0+BXgi6+EGtfG/xL8Ntd8Nz+OPhZo89xaa9Yq/gf7NHNdrYq95ZoLgR8zwo7
PbMhLRtHh37U/hfTNc/4JY/AXwXL8J9X+N3iX4fa34buPHvwv0S5mtfEen7vAyWsMt4likl5Zosy
xjdcRK7NbeXkpsC/hHRVf2lrdR6t9Ho76O61366abasX1TW9+luvl5+Xr5n7rftQ+F4NT/4JXfAj
wDP8K9a+N2v/AA91vw7eeOPhdo8s1p4i0xpPBAghmvEsRJeWkazNGAZ4Vdntmj3bGQK39pjR7LW/
+CXHwI8DXHwZ1b40eI/h1rvh+58c/C/SJJrTxDZb/A0dtDcXq2Cte2kfn+UR9oiV2e1ZNxjKY/Cu
imsz/udW+nXm301366abasr6tLrL8H5efl018z6u/wCCuNjHoHxT+EWiT2M2leIfDvwd8IaX4gsb
iGKG7sb+LTkDwzxqBIkqxmIFZx5q4AwECAeJfCbxJ8K9G0CePx14M+IPiPVGuC0FxoPjOz0W3jh2
qAjRTaXdsz7g53iRQQyjYCCW8+orz5VV7SU4K123rZ769jaFK0FBvb5H1j/wT8s9Wf8Aam1vxz8M
pl+HPwm8JacJPHN/46u49f0i10KYJDdWOpLFBbLqQvH3RxWUcKyzO0aphozOngH7Q2ueCPEvxv8A
FGofDbQtY8M+BLvUJJdE0vVL0Xl1Z25Pyo8gHTqVUtIyKVRpZmUyvxtFXOu5UlTt1b/4bsvTf5Kz
jTtLm+X9dz9K/wBiOHT/AIgf8EYtN0D/AIVhqn7QEnhr9oO417XPh34dubyDVnsJ/CxtoLyaSzWS
4htvtKDa4jCs9u6bjuO31H9on4N/C3Vv2T/CWm/HPw4fhd4b8KRfD3Q9R8cWejJJ4zj8RHw/Y/2h
oUkBhab7BFpUkN2xdo/IuA5WO8lb7Kn5B0V0U8bGNNQlBO3p2a10v17+lm2zCWFvNzUrf0vl+B+p
nj79ij4h+N/jn8ZfEHj/AOGuuQ/A/wAAeOwth8GfhNLc3el+J9f/ALPt/skVvDaJttInsHtZbrUn
t4ZDHMY441nkEUXo/wASr3x98XP2NfF+n/GX4Q3Xxh+Kmk/tGHxD4y+F3hK9kS4stOuvBsdvpswf
TTcPFaIwgWOQbvMNt5byM7Ma/GyitFmKTuo63u9U09+jjbrott9NWJ4W/Xt36fP8d/uP1O/aEn+K
eo/AXw98IfDX7PNn8XvD3hDTfCGq+MtD1FNXude0LxRJ4UsrZd1lpl7bXkFstlbxpmSExCdrhWkM
mETuf2Yfgx4V+Bn7bX7cHw6+EXwusfG/hrw98NtetbW5efVdQvJZbq3sf+KYd7e6SMp9pS6iVFT7
ezW8iC4LKxH48UU45mlPnlC+t+l7a6Xt563vsE8K5Jpvf18vPyP0w/ZHuvDnxW/4JJyWtr8HdS+M
kuj/ALQ1z4j134X+FdQ1KOW00mfwzLBZzB4ftF3BbJdb1Erly/2YI8hJLV9BfG/QPD1//wAE5Ph1
4On+Ffj341+K/hz4t8J3XxC+FtrqGoW1/ZLJ8OrW1glZLeJrixiSdUViEwZoJI2ILFV/E2isqWP5
Yxi47Py7Ndn363XlqwnhOablzfn5efl6/cftR8V/Bmg6p/wTn8B+DW+E3xB+NfjLwF4y8LXXxC+F
1le3tvqVmj/Du2tbeYpawNcWUSTqoYlDmaGWNmBJVfzg/wCCmmkL4Y+N3g7Rbm31ix8Q6F8NfCGn
a/Zaksscun30eh2Ya38qRVaIpH5StHziQSZ5JA+dqKnEY11afJa2t/zfa/Xq/lqy6WH5Jczdwooo
rhOkKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKAPu3/g2g/wCU1/wc/wCuHiH/ANR3U6/rLsP+PSP/
AHf6V/Jp/wAG0H/Ka/4Of9cPEP8A6jup1/WXYf8AHpH/ALv9KALkHU0UQdTRQB8cf8HR3/KCj45/
9wD/ANSHTK/nB/4I2+I9MT4p/GTwdPf2Fn4j+K3wh8ReCfCUN5OltFqetXiwfZrPzpGWKN5vLdEM
rqpdkXJZlU/0ff8AB0d/ygo+Of8A3AP/AFIdMr+Sr4L/AAX8VftE/FPRPBPgnRL3xH4p8R3ItdP0
+1UGSZ8FiSSQqIqhneRyEREZ2ZVUkdGFqyp1Yzirvt3voZVoqUGm7H2p+yRprfsrf8E5viX4s+Of
hjUfiF8J7z4gDwLZ/Ci9nudLlsfF9tBBdT6pLcFRJprxWSvbt9mzNcFvJmVIkDH6u8RfBXx74j/Z
+/ao8eaV8Nr74teB/it4d+H+q/D7wwdCvbe2j0c3Pm22iLb6VLG6yabamAslrMPlWCaQ4uCj/k34
o/ZP8d+D/gbdfEu80qwk8CWni+fwI2s2es2V7by6xDbrcyQReTM7Sx+SyuJ4w0DhhtkbNd/oX/BL
H42698Mx4xHh/wAM6b4aGmWOtSX2reNtC0tLexvghs7mVbm8jaKKcyBI3cKHkSSMEyRSKvZRryUF
S9m2vx2l5a9dHfZ2tdmFSlFtz5rfl08/+Dsfo1qV1Y/stf8ABMjx74C+OHw7tPAngr4iftQXekeL
vD9hfebJ4J0zUtB03U7a4sbmxV4ZJLHy7SZY1ikWRYvKaJfMwPL/ANsj4b6z42/4Odrm50+332Pg
nxB4V8V+IdQnuEhtNE0nT9N0q5vL+6uJGRIoYoo2Jd2XLFVXLuqn4f8A2iv+Ccfxm/ZO8E6p4j+I
Hg3+wNG0bxPH4NvLj+1rG68nVX06HU0ttsEzsc2dxDL5igx/Pt3bwVFfVf8Agnv8YNG/aS8QfB+b
we7/ABN8Nae2p3fh2DU7Oe8miW1S7K2wSZhdzfZ5FkEFuZJSofCHY2N3i6riqPsnaMk130c/d0j3
b0tpZ2XbJUouTqe0V3F+m0dd9v0a174X7ZvxC0n4uftg/FfxXoNyl5oXifxjq+radOsLwrPbT3s0
sThHAdAUdTtYBhnBAPFfWn/BND4aTah/wSq/bE1/XvBHjTxP4IlHhiNxoUq2E99JZX73VysF5Ja3
KL9lgkjuJ8RPshKl9gdXHwDRXmRxFqrqtb3/ABT7301+ex2Tp3hyLy/A/WH9pv8Ab2j/AGp/+CRH
ir4v+LPhp4S16TxZ+0vIF8Panc6sNOsY4/CNlb27LNaXNtLJOkNsFYiQITIzGFAYgnqX7RWj3X7a
f/BY/wCLf7IvjTTtX1f4V+KNX03x015o0gtr7wbq8HhqwR9QjmMbxtFcRKli0dyrR7riFkKSDL/l
r+zZ/wAE+fir+1z4J1LxD4A0fw/q+l6RqNvpN6bnxZpGmz2tzcPHHbK8F1dRSgTyypFE+zZLJujQ
s6Mq+R+JfDWo+DPEeoaPrGn3uk6vpNzJZ31jeQNBc2c8bFJIpI2AZHVgVZWAIIIIyK9COY1OROtD
mTkm3tzWcrq9uvNr2OX6tFyahLZWt2+G3Xpb5/I/Q3Uv2jPjJ+1r8MvFHgbWv2d5/GvwO8EeII9F
sfh3oF3NB4p+Gl9b6XPYWjq0fmagzpFGqyz6ja3FvLJatGFjYbE6L/gnf+yjp/7LX/Bx5a/D7wTq
8/j3w38PbvV1k1NER/s8L6NcI0N08YaNXiuLhbORiEBnG3bGzBB+Yden/CT9jr4g/Gv4c3fjHR9K
0qx8H2Wpror69r+v6f4f0qS/aIzfZI7q/ngilnEQ8xoo2Z1RkZgA6kxRx37yE+TmkpKX3O7Sstnv
1t0W5rVorlkm7Jpr/g7n1N8PfBWqfGT/AIImeJPgr4Y0jVdY+Mvw9+Ocvi7XfBkVrKNcs9Jk0eHT
PtEdowEk2y9UxTJCryQ/I0qohVj6T8Vvh/afs8/8EWrnwp8bI9c8d6j4Y/aB/su8tvDHjCGCTTbp
PB2nKtm19La3kLmyRDZyQxRkRyQbRLsRN/55fHD4BeLP2cvGUOg+L9Mj06+u7C21W0kt72C/s9Qs
7iMSQ3NtdW7yQXELqeJInZcqy53KwHHVjDFey91xfMk1q/XdNbq5fs+bVPR/8Dr8j9wf+CgXwP8A
GvxQvv8AgpQ/hnwb4l12PXbv4c6dpp0vSpbr+0rq1SxmureELGWlkiilillWM/IskbPw6E/j1+0x
+zh4n/ZK+NGqeAPGUVlb+JtEgs5b+C1uVuY7Z7i0huhF5i/KzosyqxQsm5W2s64Ywfs8fs8eMf2r
fjFo/gHwDo/9veLde877BYfa4LXz/Jgknk/eTOka4iikb5mGduBkkAt/Z7/Z78YftU/F7SfAfgLR
zr/izXRObGwFzDbGfyYJLiT95M6RjEUUjcsM7cDJIBvF1vrMueMHzSk7a3Wrbta12/eXX5aq2dCm
qMeRyWiX5JX38n/SP05/4Jfftj+D/wBjP/girFqnxJ8F2nxA+Gnif49X+ieJNGuNFj1MywHw5Z3U
LRR3EqWzyrd2to2HztRJDjcYivv37RDePf2l/wBkH4r/ABJm+DMHxFuviZ8Jvhdf2miafYajNpur
3n9oXN1e28K2bxXha2FykjRw3DtFGYDKzJIAPwVoqoZpJUo0WtI+naS7PTXb17ilgouo6q3dvwt6
dj9vvh98adO/4J0/sSePG+N/wh0fTfBviP8AaV1a38R/DSCxsddTRbK+8OWeq2UVsplSwlEMiWAX
5Aqxq+FVzGI9D/gsNqXjX9vX/gkR8IJPDnh9vF3j3WNc8O+NtW8O+ENMn1C8sLfUPDcg+1vBEHkg
tmuUlgj3BgfIwZXYFY/wxoqp5rKVJULe6r9VfXm62/vaaWXbs1hbS509bJfdb/Lv+R+5vxx8R+A/
DfxR/wCCgnjP4l+D7n4h/CE658PtC1aPSr37ILya1FvDeQ21xCVU3dnLLA8sCzIQwWOUoJN6+WTe
HfHP7Wv/AAU4+LH7H/xzuYvHHg3xD4nbx0db8Iw/2MfCV5BpEK2l/CWjmVYpdPWz0+SG789Q8sbL
M0w86b8haK1rZwqsrzhpzczV97uTaemz5rLtrb4mKOEst+lvy1/D8ux7D+3F8ftc+Pnx0lGr+Fv+
ECs/A9lD4O0Xwoyymbwvp9gWiisZpJgJ5Z4zv82SbDtIz/KihY0+nPhZrfg3Sf8Ag30U+O9K8SeI
9GX9oWcW+m6Br0OiXcVw3huD9+801teI8exSuwQI2TnzWHyD4Cr0/wCEf7HXxA+Nnw7vPF+j6ZpF
j4RsdRXR313xB4h07w9pkt8YvO+yRXOoTwRTTrFiRoo2Z0RkZgA6k+dRrS9o5RV27/j5Wt8rG84R
5OWTstPzP2T/AGop/Cnwz+NP/BQvxT8U/A+qeOvhi2o/DSy1WziuprA6jGILXzRDNGUZprdri0nM
aTRgnykbakoZON8TwXPwN8R/8FBtc/ae8ORfFzwxceI/A1tq50CO40Kx1O3MyyW62xQqyz2lpdWD
tB9p3EgJJPIJTcH80NU/4JcfG7w7pM2q6x4X0bQPDiPaR23iLWfFmj6Z4f1Z7q2+1QrY6ncXSWd8
xg+ci2mlKD722jWP+CXHxu8MadLqOteF9G8O+HwbRbXxDrXizR9M0DVzdWwuoBY6ncXSWd8WgIkI
tZpSgI3ba9eeY1pS5lSe8vvfPo9NbX2faX8zOCGGppKMpp2S8tuXXfTbp3XZH6Ef8FLmfwR+xr8X
bX9oAz/ELV4v2kY3CeCtStvDPlrL4StXtCPPt711ijsxFCYTF99M/argqzH3P/gpZ8W/Bnw1+H/x
r8O/EXTYrv4Y/ED476L4W8VG2neDUNBtLjwbot1/aVq0fmSGW3uLGCZUe3aOVYZIgJPNbyfyC1f/
AIJf/Gzw1pNzqmseGNG0Dw9CbRYPEOr+LNH07QNVa6tjdQLY6lPdJZ3zNCC5W1llKgfMFPFGqf8A
BMD41+HbCbUNY8NaHoGgobRbbxBrPi3RtM0DVjdW/wBphFjqVxdJZ3xMPzkW00pQfe2nij+0a8eb
lpPV9df59HprpLW/Z92aOhC9+fp/8jrvpt+J+on/AAWI+DOr/tCeBfi/4Q8JaN4n8US6Z+0F4e1X
XNO8J6D/AG3rmk6dP4HsoxeGzilWUx5SZYxKIImeNkEzHzPK858FfAXxb8M/hf8A8FAvBJGrftae
IrS/8C2T3N2mqXr+J7m3uGe6t5Vsrprp5bLzVV1ju98TWoDAx70HwDqn/BMD41+HbCbUNY8NaHoG
gobRbbxBrPi3RtM0DVjdW/2mEWOpXF0lnfEw/ORbTSlB97aeKXV/+CXnxs8M2U1/rXhjRfD2hL9j
+za/rXi3R9M0HVjdW32qAWOpXF0lnfFoPnItppSo+9tqK+MqVajqTpO7b79ebTa11fqunTUUaKUV
BzWiX4cuu9+n4o/Sv4PftAaV/wAE3/2YPioPjZ8FvD9p4O8XftBXVv4o+HEen6XrZ0CwvNBTVtPg
gUTpbyLHKlls8yNIlSGXywZNyw+k/tE+JvFn7Uv7HXxa8byfCS0+I+vfED4Q/CrW4/DNha6zNZav
dSarqk92sUVm0Vx+4M5k2x3LMixozNIrSKv5C65/wTK+NPhPTJNS1vwxpPh/Qf8AQ/s2vax4o0nT
tD1X7XbfarcWWoz3KWl6Wg+ci2lkKD7208VD8QP+CbPxk+F/wi8R+PNZ8MabF4T8KR6dcajf2/iX
SrwLb6gIvsN1EkNy8lxbTmULHPCrxM8VwgfdbzrG5Y2v7P2fsnyq+68pX15baJvotnpZsU8JBy9p
GVm7d9bW8+tl+B+h1zd6Z+zB+xf8XvBnxu8A6P4C8GfE79olNF8YeFtLv7Z7zwBpOo6VDq1pc2dz
p5k8wWhjtZUia2aB1tHiVC0kgh6PQ/Dd34h/4O572TSYL27tNGtRPc3UELSJZRDwdHAs0pUYVPOk
iTLYUtIi/wAQB/IL4L/BfxV+0T8U9E8E+CdEvfEfinxHci10/T7VQZJnwWJJJCoiqGd5HIRERnZl
VSR6BpX/AAT5+K+ov4ua40HR9BsvA3iKXwjrGpeIPE2laJpkOrxeZ5lhFeXlzFb3E6CJ2ZIZHITa
x+VlJinmVVxgo07qM01/265O2i/vfLV210dTDxvLmnZuNvLVJXs35d/I5T4QeGtR8GftP+F9H1jT
/Duk6vpPii0s76x8cQNBpNnPHdokkWqRsAyWysCs6sAQgkBGRVf9pL/k4rx9/wAiV/yMeo/8id/y
Lv8Ax9Sf8g3/AKcv+eP/AEy2V6Pqv/BMn4zeHBcz6x4e0Dw/pUCWMkOtaz4v0bTNE1Nb23a5tjZa
jcXaWl7vhVn/ANGlk2hTuwRimX3/AATO+M2i6fcahqvhvRdA0KE2Qh13WfFekaZoepG8ga4thZ6j
cXSWl5viRn/0aWTaFbdtwa810qvJy8j37Pft66P7mdnPG/NdbfmeDUV7xff8E0fjHoqXc+q6B4f0
HSbZbJota1nxfo2maJqQvIHntzZajcXaWl7viR2/0aWTAU5xilu/+CZ/xl0m1ubzVPDuh6Bo0C2L
xa5rXi3R9L0TUheQPcW32PULm6jtLzfFHI3+jSyYCNuwQRUfVa2r5Hpps9ynVgt2jwaivftX/wCC
YXxq8NRXFzrPhvQ/D2jwx2MsGua14u0bTND1Rb2B7i1NlqNxdJaXokijkb/RpZMCNt2CCK82+O/7
PHjH9mjxja6F400f+yr3UNNttYsJIruC9s9TsbhN8F1a3Vu8kFxA4yBJE7ruV1zuVgJlQqRV5RaX
oKNWEnaMk/mcVRW7oPwu8TeKfA+v+J9M8O67qPhvwo1smt6ta2Es1jo5uXZLcXMyqUhMroypvI3l
SFyQa6j4O/sqeNPjn4U1PX9Dt/D9poOj3cOn3Op6/wCJdM8P2X2mVJJI4Emv7iCOWUpFI2yNmYKu
SACCYjCUmlFXbLcklds86or3fV/+Cafxi8M3VyNZ0Hw/4fsYINPuYtX1jxfo2m6NqUV9BLPaSWeo
T3aWl4skUMzA28sgHlODgqRT9V/4Jm/GTw7LdtrGgeH/AA/p1rBp9zHrGs+MNF0zRdRiv4ZZ7N7P
ULi7S0vVlihmYG2lkx5UgOCpA0eGrL7D+5ke2p/zLvv0PBaK901f/gm58YPDVzcjWNB0Hw/YwRaf
cRatrHi3R9N0fUYr+KWa0ks7+e6S1vEljgmYNbyyAeU+SCpFJrf/AATf+L/haa7Os6BoWgWFtDYX
Meq6v4s0fTtI1KK+hlmtJLO/nuktb1JY4JmDW0sgHlOCQVIqvqlf+R/cxqpB7NHhlFe63/8AwTY+
MOhyXL6t4f0Lw/p0EOn3EWr614t0fS9H1CK/hmns3tL+4uktbtZY7edgbeWQfuXBwVIqTVP+CZ/x
k8Oz3h1fQPD2gafaQadcpq+s+MNF0zRtRiv4ZZ7N7PULi7S0vFljgmYG2lkx5MgOCrAJ4Wst4P7m
J1qa05l954NRXu+s/wDBNX4xeF57o6zoGg6Bp9vFp08er6v4u0bTtG1GPUIZZ7N7TUJ7pLS8WWOC
Zg1vLIB5MgOCpAk+JP8AwTH+Nvwl+D/iPx9rnhCzh8IeFI9NuNR1K28Q6ZexrbaiI/sF3EsFw7T2
twZCkdxCHhd4bhA5e3mWNPDVkruD+5gq1N2tJa+Z4JRXovwg/ZT8a/HHwfqniLRLXQbTw9o17Bpt
1quu+I9N0CxF1OkjxW6T388MckpSGR9iMzBULEAc11cn/BOT4xabrXiyx1rwvY+EH8EatFoWsT+K
vEGmeHbOG+lieaK3juL+4hhnd4UMyiF33RFJBlHVjMaNSS5oxbXoN1IJ2bR4fRXvuq/8ExfjR4dj
urjWPDmg+H9It0sJItb1nxfo2maHqS3tu9zamy1G4u0tL3zIY3f/AEaWTARt2CCKNU/4Jh/Grw7b
3F3rPhrRfDujQpZPBrut+LNH0vQ9UW8gee2NlqNxdJaXokijkcfZpZcBGzjBq3hqy3g/uYvbU/5l
954FRXvupf8ABMP41aBaXN7q/hrRfD+iQfYvJ17WvFmj6XoWp/bLdrm2+xajcXSWl7vhVn/0aWTA
U5xUWp/8E0fjL4f0y41LV/Dej6BoUX2PyNd1jxVpGm6Jqn2uA3EAstQuLpLW9LQguRbSyFQDu20f
Va38j7bPcaqRezPB6K9/1P8A4Je/Gzw9p1xqOseF9H8PaBEbNYPEGteK9H0vQdVN3bm5txY6lcXS
Wd6XgBkxbSy7VHzYrzP46fs++Lv2bPGcGg+MtJXTL+90+21eykhvIL6z1GyuYxJBdW1zbvJBcQup
4kidlyrLncrAROjUiryi1026gqkG7Jq5xlFdN8Gvg14p/aF+KGi+C/BWh3/iPxR4huBbWGn2abpJ
3wWYknCoiqrO7sQiIjMxVVJHo3gv/gnp8UfHvwsv/HNlZ+DbfwXp3iW58Hya7qXjrQtM06XVYIY5
5LaGe5vI45j5UqSK8RZJF3FGYKxBGjUkrxi38u2v5DlOK3Z4nRX0DoH/AASw/aB8VftKa18ItM+G
WtX/AI98NrA+r2dvPbyWukie1+1wm4vRJ9lh8yHld8o3N8gy/wAtc98Kv2EPiV8Y/gafiXpOn+Gb
LwGNdl8MjWtd8X6PoNs2pR28Vy9qpvrqEtJ5M0bgAEMN2Cdj7a+r1b8vK76rZ7rf7uvYn21O1+Zd
Ovfb7+h4/RX0B4s/4Jd/G74fav4ktfEvhXSvC0XhPUbbR9R1DXfFOkaXpa31xZLfRWkV7cXSW1xO
bV0mMUMjuiuhYLuGad1/wTX+NGjX3iiLXPCNt4Rg8Ha4PDWqX3inXtN8P6cmpGEzi1iu764ht7iQ
wATAQyPmKSKQfJIjM3hqy3g+2z37fgHtqe/MvvPC6K+gb3/gl38bdD8Ma5rWt+GdE8KaV4c8Sy+E
L+58S+LdG0KOLVI7aO7+zqby6i8zdbyxyxvHujlRt0bOAceYfH/4AeLv2XPi5q/gTx3pI0PxXoXk
i/sftUF19nMsMc6AyQu8ZJjkQkBjgnBwQQFUw9WCvOLXTVP+uhSnFuyepxtFFFYlBRRRQAUUUUAF
Fdl8Hf2f/F/x+Pin/hEdGfWP+EK8PXfivWttxFD9h0y12faLg+Yy7gm9PlTLnPCmuNpuLte2grq9
goor0Hwn+y3418c/s9eKvilpOn6ZeeC/BN1BZ65cLrdit5pzzyRRws9kZhdmOR5lVZBEY2KygMfK
k2Ci3okDaW559RRRSGFFFdn+z3+z34v/AGqfjBo/gLwHpI13xZr5mFhYm7gtPPMUMk8g8yd0jXEc
Tn5mGcYGSQDUYylJRirtilJJXexxlFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKAPu3/g2g/5TX/Bz/rh4h/9R3U6/rLsP+PSP/d/pX8m
n/BtB/ymv+Dn/XDxD/6jup1/WXYf8ekf+7/SgC5B1NFEHU0UAfHH/B0d/wAoKPjn/wBwD/1IdMr+
b3/gjp4o062+Kvxh8IT3lhba/wDFX4ReJPBPheG7uFtk1LWLyKL7LaLK5WJJJmjZEMrKrOyqDvZA
f6Qv+Do7/lBR8c/+4B/6kOmV/IFW2HrOlUVRdPy6/eiKkOeLi+p97fsgQQfsxf8ABPD4m+Kvjj4c
u/iL8LJvH0Pgm1+E91dTaZc2PiqKKK6n1SS4wJtLeOzge2ZrdWluSzQyhEiDV9ZeMfAPibxv8DP2
rPE+h+HT8afCnj3w78OdR8A+ChpN7FHpekSXH2u28Pm10uVDDPptnc20jQ2s4LRzQ3Dki4dW/Fei
umGNUYqm46L0vtLrbz63W9rXZhPDXm53/rT/AC/HyR+yd3rmn/sw/wDBNn4n+CfjP8PLPwR4J+Jn
7TE2j+LPDuk6xbynwXpmoaLZarbS2M9ikgZ7JorKZVMckUqQGERKzSBfNP2xPhxrvjf/AIOaNSvt
Mtl1Oz8D+IvDXi/xFfTzxQ2Oi6Vp9hplzeXd1PIUihghjQgs7KC2xB87qp/Oz4L/ALPHjH9oX/hL
P+EP0f8Atf8A4Qfw5eeLdb/0uC3+xaXabPtFx+9dd+zzE+RNznPyqcGuKraWYz9nGEo6KV0+ujlp
e1vtdtNdNbERw655SUle1n80vO/T5/I9K/bN+Iml/F79sH4r+LNEvP7R0XxR4x1fV7C68p4ftNvc
Xs0scmx1Vl3I6naygjOCAeK81rqPgv8ABzxB+0F8U9E8FeFbeyvPEniO5FnpttdalbafHdTkEpEJ
rmSOIO5G1FLgu7KihmZVPQ+Hv2Q/iJ4s+OPif4aab4eN7498INqEeo6HFfWzXby2BcXUNuvmf6XM
nlyERW5kdwjFFYAmuGUalWXOo/E+i6vov8jqTivcT2X4H13/AMExP2afH/x8/wCCWP7XOkeD/DWu
63eeM9R8FaHosMFsywarew6v506LM2Is28MsckpZgIYpxI5RDur6O/b01fQv2ldJ+N/xO/Z28JeH
/jR8U5vjDp2g3uoWvhSx8bz/APCO2/he2hV47G4t7hYbY6jb3IW8ihVJyAomkVFx+NtFdUMdGFJU
lH1d+3Na2mnxeeyZzywrc3Nv009L31128j9vvjL8A/2RP2eZvibrPi74f+BU+HGvfHSbwXrOspDe
Xh0i2h8KW2qiz0/7DJ5tjKms74plt1Tal08DqEiCQ6v7UWg+BPG3/BMj4Pt4b/Z9tviNfeJfF+jf
E3xr8MPh752mJCNS8IPaQzpDYrLcWNt9oijdGMeyRkZd7u8rV+FlFbzzZS0jTildvRLrfTazSvom
nt2dkPCp2u+i/C2vzsfXn/BYQNpvjr4EaJdSPFrPhn4JeE9J1fTJxsvNDvI7aQyWlzGfnilAZX2O
AwWVOACK9b/4Izfs3eGNf+Fb/EXVtN0bx4F+IVjoPiLw/f23hxrTwtoEFjPf3evahPqlpdyQ2Xlp
NEQgsxI0RVLmSUKkX50UVxwxUY4n2/Lpe9r/AK/npr2NZUr0vZp9LH6T/wDBOv4K/wDDOX/BygPB
GlaJe6BY+G/FHiu00awvRKskVh/ZmpmyYGXLujWxhdHYnzFZW3ENury//ghB4d1LwR/wWQ+HWk6v
p95pWr6Q/iC0vbG9t2huLOePRdRSSKWJwGR1ZSrKwBBBBFfFFFbUsfGE6clD4Jue/fl02/u7+exm
8O2pKT3ilt667+e34n3z+zb8C9Y8Of8ABMbxXqXw/wDhTB4t/aI0L4wf2B4n0++8D2nizVND0JNJ
do0k027guDZr9uS5V5vs8Zd4xGZD5ZRfor9uX9m3wR4D8NfHK8/Zi+FvhbxZ8RdH+Ndnpd/p2l+F
bLxp/Y2iv4bjuZYk0+eK6SxiGrC/VisUQDxtBwLfyo/x8opUsbCFPkcfnfXZ7ab67+SHLDtz57/1
p5+X4s9/+If7L/xI/aD/AG/Ne+GehfDjwfoHxM1HULmOXwf4U1O2GlWF1BbNPdQwyvdywxlRFMzR
CfbG4eJVTasS+X/s+nb8e/BB/wCKQ41+w/5GsZ0D/j4j/wCQh/05/wDPb/pnvrkKK5JVVzc8Vrdv
/LZL59+yNoprRnZftFnP7Qfjs58GtnxDqHPhEbfDx/0mT/kHDAxZf88eB+62VxtFFZzlzSbKSsrB
X6P/ALD3hyz+IX/BHhbGH4SeIPj6/hv48nU/EHgjw/PNFevZXHhe4t7O6lksYnvIIluldld/3TtA
6LgmU1+cFFa4et7KfPa/3fqmvvRFWDlFxTt/w9z92P2u/D9t4h/4Jh/s/wDhW++FniX43a/8LW8L
W/jv4X6Vc3UGraKsnhK8jtHvfskL3lkRcSGQJNhSYgiou+Rnh/aq8NW3iv8A4JofATwrdfCnxB8d
vEnwyk8K2vjn4aaNJcWusaQH8JX8dqLwWcL39m0c5LlZQEfyVVVG6Rm/C2ivUecaaQ/J6a6O8dd+
t1ptqzD6s7b6/Py8/L8uyP3P/ak0TTPEH/BL39n7wxefCfX/AI4658M7jwxD47+G2izT2ur6UJfC
l8lqb1rSJ72xdZ33hZVCP5AUKpMjPN+1J4TsvFX/AATQ+AnhWb4R+KPjprfwsk8KQeO/hjol1c22
raOZvCd/HCbxbSB76ycXGHIl+RvJVFQbpGb8KqKU82Td1Dq+z3v/AHdd+t1vpqy50G7tPp5+Xn5f
1ZH7pftR+DIvEX/BNj4C+E7n4TeIvjxqvwtbwonjn4aaHdXNtrOkNceE79IRepZwPeWLJPtf97w/
kqgRMyM6/tV+HYvFH/BOD4B+Drn4S+J/jtq3wvHhNPHnwy0O7u4dW0dpfCd9Fbm+Fpbvd2LrMQ+2
UkHyAgjjDM0v4WUUpZsm7uHft1vv7uu/XTy1d4+ry6y6W6+Wu/8AXyR+5/7UWkQ+Mf8AgnR8C/CN
z8H/ABT8c9b+Fsfg6Hxz8MtHur6DUtJL+FNUhgN6lnA11YyCcq5EjDcIY0EabneVnjLTvHFj/wAE
/PiTovgvwmfE3jzQPgx8HNEuvDk/hiLxHd2uoRXWoyXFpPps6TIZY4JllaKW3Z4g8D4jOxj+GdFH
9qU1flp2366q9+tr9fTfTVieE7Pt3e1ul/I/ZzR/EvwU+A//AAVk8bfCX4O2PjTwp418RfFnQHN5
4E0Oz1nT20a2trW51LRQ32iK502D+0ftcl4bcvGkNqsRhEcBSqXxu+HNre+G/j5oEfwp+Jfx+tvD
n7Ul34j174e2sd9pt2bS/wBD1EW94RZxTzQW73JJiufNb7XFbRExQbiG/HCipeaq1lBL3m/k76Wt
Z2v1VulhLBtKzlfRL7ra336fi9T9z/2sPCP/AAk3/BPL4E+Eb34W+LPjrq/wxt/Ba+N/hdoV1e2+
p6OZfCmpxQG9jtLeS40+VZijEyEtKIkTyol+eaP9qzS7fxV/wTx+Bfgib4U+M/jnrXwwtvBieOPh
hpF3fw32jSy+FdXiha7S0ge4sZhNsc7m3OtvHG8UQAeb8NKKt5vf7H5ee/u6ryd15asFhH1l09O3
n5evnsfuV+1L4WsvEn/BPz4HeDrj4PeMPjjrvwttPBS+Ofhno17qVvqekNP4W1eOI3kdrbyS2Eon
MUhLNvkEMcbwxKoeaf8Aam8MWXiT/gnd8C/B03wj8WfHbWfhZD4J/wCE6+GOiX+oQ6jpDTeFtXjj
+2R2sDz6fL5+1nyd8gghRo4lCPL+F1FTLNb/AGfxT773Wu+zut9NWL6nLrN/j5efl6+Z+5f7V3hW
DX/+CePwN8H3fwv8afHbX/hdZ+CU8c/DDSb3Ube80U3HhfWI7Y3cNpA81jOs5RmZm8yRYYY3jjTy
3l+PP+CnviD4VeC7/wCAXhb4i+BPiDqfjfwl8F/DGl6xb6N4ys9BfR5RbtILO8tJ9MvJY7tPMZ23
yITHNCPKTbuk/Peis6+Ze0g4qPW+tn38td9Oi6Jal08M07ylf8Pyf9fI+tf+Ceei6xcftQ634/8A
hw3/AArv4O+D7Nf+E71Xx0y+I9EsNFuE8uew1MRW9tHqBvWSWOCySKOWaTYIyrxG4T6C+DFt8Ovj
R+xr49Pww+B/xR+LXgDRfj3BrB+F9truoz3tlo9z4e1OCyuJGs7eQ22bhGJkEkzuttFBI7eWJ5/z
IorCjjHTsrdW+nVW2s1bytZ6X2Rc6HNdp9Evud/X8T9z/wBrDwXa+IP+CefwI8KT/Cvxn8efEPww
tPBSeO/hhpN/qMN/onm+F9WS3+2Q2kDTafJ57BmbPmyrbxRyJGiQPLB+1b4Zh8S/sAfA7wbd/Czx
18ePEfwwsPBS+Ofhho97qdvcaIJvC2rx2xu4bSBnsLlZ2DMxPmypbwpIkaCJpfw3orseb33gn62f
f+7rv1ut9NWZRwsl9rp29PPy/qx+5X7VPhS113/gnh8CPBkvwp8bfHXxJ8M7Twf/AMLA+F+k3Wp2
97ofm+GNWjs2uorSF3sJhO7OxOJpVggSWNIxCzv/AGpdI07xR/wTt+CHg+7+Fnjb47eJfhhF4Ji8
e/C7R7zVLa70RZPCurQWrXKWsEjWFx9obc5z5sot4EljjQRGT8MqKcs3Tv7m/p5/3dfndeWrH9Vb
3f6dU+/l6+Z+6H7UWjaX4w/4Jy/A3wdP8LfH/wAePFPwtTwdH4++Fek3mq21zoaSeFNUhtnuY7WF
zYXH2jLOcedIlrbpKqp5Zdv7VHgay13/AIJx/AvwrL8LfG3x08S/DSLwfH49+FWk6hqcN7oYm8K6
olrLdw2kTvYTfaGZ2JAlkW2gSVQhiJ/DGip/tZa2h18n3/u679dN9NWH1WSvaWmnfpbz029fM/df
9qvwrZa//wAE2/gN4Puvhf40+O/iX4ZJ4PXx78J9FutTt7zQo5fCmpx2kt0lpE76fcG4kZn3IJZF
tbdJBsEZaLx14f8AHum/8E/PiTpXhbwMniLx74Z+Cnwf0GfRLjwhba/d2eowXV9Nc2dxp1xDPmeK
1nSaSOSEtGrQSMIz5Rr8LaKTzOLveHfZpPW/Xlv1+/1d5eDbd2+3Ttbz621733P2c/bM+C3g7Svh
B+0F4W+B3wxPxoj0j47aTLdfDCwGsaho3g5H8Ls0upQW+kXEMlvNLfnULWVTKYk+wxQ+VGYUA6v9
uvRvCvxOPxlttJ8KeO/2rLjwx8f7C78ReB9B1K8Mdnp0ngk2lq6vpsDJbGG+jntncIZnGkwxXDOy
l2/Diil/aa1tC123bS32tLW1+Lrf01YlgpJ35uluv93z/u+up+7X7U+h6T4s/wCCZHwD8H3Pwu8Z
fHbxb8NG8Ir46+FOi6jqkN7o9tJ4S1GK0muYraJ5LC4+1SSM58sPIltapJ+7MNL+1n4Ws/E//BND
4CeEL34a+Mvjr4p+GTeD4/HPwl0O9v7e/wBFgfwjfx2s13FaxyTWE/2mRt5ZA8i2sCvhDFj8JKKf
9px6Q6t9Ot97x132enlqx/U2ndS/D089Numvmfup+05pNh4l/wCCafwH8Hah8KfEvxx8T/DC68Jw
+OPhLod/qUGoabA/hG/S1nu47SN5NPuPtLyGT5PMkW0t1kIUxqLP7Vfh3TfEf/BMr4B+Db34S+KP
jj4r+F934TXxv8K9Dv8AUYNT0u2fwdcpBLexWkTTadMbuR95KeZKtrArnbsC/hFRQ80Td+Xv1Xno
/d1Svs9NPNg8E27839aeem2618z90P2o/DcHi7/gmf8AAjwne/CbxB8b/Efwvm8KxeMPhdoOp6jD
qmmQTeDrpLa4vre0ieXT5vtbsWJXfKtrAshCsip+cf8AwV4tb/w/8RPgr4d1bT7bSdZ8KfBnwppW
oWBuN1/Y3C2jSPFfQlEa1uVMuPJfcwj8liRv2r8l0Vlisw9tT9mo21vuvPR6Jvfvput2bU6Moyvf
T0/4Nvwv5n11/wAEd9csJPit8XvB8mq2Wm+Ivil8JfEXgvwrBdzJbxaxrF5HCLax86RliiebY6o0
rKpcogO51Bp/8Ey/2f8ASdQ+PfxXvfH/AIU/tLVPgb8P/EHjWHwvr1o62dzq+liMJaanbExyNAkj
MZINylmiCOCpdG+UaK5oYhRUFy/C7+u3+Xp5b3uVNvm13Vj9Dv8Agh14g+Jv7Uv/AAWb8MfFfXoP
FHjO6iudRm8TeIVtGkt9Oe40bUIbdZZFXybZSE8uGI7EAiEcahVCjyz/AIJ2/spQ6d+0H8Vx8VfB
N9DrvwU+GmtfEC18KeJ9Omt4LvULKCGa0h1C1fy5WtmWZZTHlRIBGG3Rsyt8iUVrHGpRgnG7jJyu
3ve3+Xn53IdB8zcXa6S27X/z7fM/S/4Y/EX4hftj/wDBKrx1r+oeHtS/aa+IOt/HSHVdX8J3C6hf
PokbaC0aasLXSXt7qBJdn2RC0rWoSzWOOGIxAt6n/wAFFrzxh8f/AIhftBfDaD4a+Mv2gfAWjfFj
Tdf/ALQ8A+KbL+39B1f/AIR2KyltLi0hs7tzZJHD9nSU2sTLLYvHNczzKwX8faK0jmLVJU7a3u3p
r8XdP+Z73/FkPC+9zRaXbR6fD2a7H6w/tHeDvBHxv/4Li/tUeL9ftND8bW3wb8AXnjHT9MuJFutG
1bWNH0jT4Etr9EZTJCtwHEtuHXMkXlPld6t+Ynxl+Mvij9oT4oa1408aa1eeIfE/iG4Nzf39yRvl
bAVVCqAqRoiqiRoFSNEVFVVUAczRWGJxTrOTta8nL7/8tfvNKNBU0vJJfd/mfdP/AATV8Bx/Eb9g
D9o6+s/DnwwvvGnw41Hw1rPhTWPFthocVvpkt7cz2V6k93qai3lhktgAlvdu0KygSRItxtY/Wnwl
/Zl+BmvftXfE34k/DSy+Hvjz4Zj4s6d4d1Xw5aW2hT6R4T0K30v7fqviK6n1Sxufs+ltOt5GgtDa
RSGB47e4YC32/lf8Lv2wfH3wa+B3jT4ceHtR0a28HfEMIPENlceHtOvZNS2D91unngeZfKbLxFHX
ypCZI9jktXmVbU8bGEIR5b21f/k3XXvr6JW0MKmFnOU23a+i69F/lpbu3uz9KfH/AMHvhr+zv4F+
OHgrRvDfwj8N/Enw78br631DTviQ6mWD4ei0ka0W1+2/6S6MWZxLpDtqkqNEyHJt2f6d/ax/ZQ+H
nhO4+Ns3w++Guk2nxA074n6Rpsmm+CPhRpPxD1TSdCbwlYXEQbQ7sw29jazXcly5vIY1aSdZImLh
QV/In4RftlfEL4I/Da+8GaNqmk33g7UNTTWpNB8QeH9O8Q6XFfrEYftkVtqEE8UNwYj5bSxqruio
rEhVA5f40fGjxV+0T8U9b8beNtbvfEfinxHcm61DULpgZJnwFAAACoiqFRI0ARERUVVVQBssfRVO
yhre/ay97S+/Va2WwSw05S1a2tfXy6fLzP1F8a/DbwXfeJvjxF8Nv2dNS8Lapp/xKtllvPD3hHwx
8WtT0K1OkqZ9Im0CS+kj0yEXouJxd25aMSNJZkobQRL8C/8ABS74ax/B/wDbv+J3hqNPh9H/AGVr
DRyR+CY5YdEhkMaNIkUMkspt5FdmWW2WRkgmEsSYSNQPDKK5a+LjUg4qNne9/v0tZLr+CNaOHcJX
vfS35dfl/XX7y/4IhfGXxDpN38cfAug2XhTUNU1r4T+KLjQtPn8MaXf6tr2pm3titjE8sDXN7GY4
Gf8As/dJC/lyOYG+c12fg/8AZp8W+AP2DfiFeeGfhf4C8a/tQad8bDpPirTtG8M6N45uNG0R9INw
sa6ZFBdWNjbC+aZPMto0xLG9uxX7OI1/NqilDFJU4wafut9e67W07r8gnh7yclZXt07d9T6X/wCC
xXgbwN8NP+Cl/wAWtD+HNjoOmeEtP1WJLez0afzbG0nNrC13FHjiPbdGdTCuEhYNEoCoAPcf+CVn
gL4iSf8ABNX9rTW/BHgTUPFmpalJ4W07Q4ZPB8fiO01S6g1LzLuCO1ngmguJYbadJXTy3aJZEkwv
ytX570VKxC9s6tt76LS177elyvY/ulTvtbfXbv6n7U/tBfssfCTwvY/HWT4L+CNI1Hxto3xjg0i9
tPBnw90/4oahpWmHw/bTSQjR74rBYWn9qnUVM8OwrNGbbbsiRY/zT/4KkaT4X0H9v/4nWfg/wenw
/wBDttUWMeHVuLSYaRciCL7XD/olxc28eLnzj5MUzLDnywsezy18CorTE4xVYcqilq3p6v7t7adE
r3siaNBwd276W/L/ACP0Z/4Iv/s6+GNY+GbfEbWNO8PeP7b/AIWFYaD4n8PX9p4feDwjoEFpJfXO
vajPqtldGCxZFmhAhezaR7d0E5kMQXR/4J1fBiz/AGdf+DllPBMGj3vhfRPDnizxVa6VY3TTRyW+
nf2bqTWRDynzGR7cwskjMfMR1bcwbJ/NWiroY+NNUvd1hJO999b220/rQmphXNzfNbmVv+Dv0Lvi
Xw1qPgzxHqGj6xp97pOr6TcyWd9Y3kDQXNnPGxSSKSNgGR1YFWVgCCCCMiqVFFeczrCiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD7t/4NoP+
U1/wc/64eIf/AFHdTr+suw/49I/93+lfyaf8G0H/ACmv+Dn/AFw8Q/8AqO6nX9Zdh/x6R/7v9KAL
kHU0UQdTRQB8cf8AB0d/ygo+Of8A3AP/AFIdMr+e79kj4XXuof8ABKfV/FHwp+G/hf4hfG3/AIWz
HpOoxjwxbeNdZtPD39jtNEW0q5tbmO1tjdiTbdoitK6vGzYhUV/Qj/wdHf8AKCj45/8AcA/9SHTK
/ko+DXwa8U/tC/FDRfBfgrQ7/wAR+KPENwLaw0+zTdJO+CzEk4VEVVZ3diEREZmKqpI2w8mqisrv
bTfXt5mdWKcGmfrB+3D+zT4V+HGhfHK7/Zk+Fvw+8X+PtN+NFlo95pui+HLPxzdaLpT+HIZ7mIaZ
c291HY2w1d7qNZYY0/epNbnYtvHGOZ/Yt/Zksofi3438d+Ofh78I11EfFSx8PeMvAGgS+HbzQfh5
pdvZSahqerXkmow6ktpYECWIR213a/vobmBJEeKKKP8AN7xB+y9438M/Be/+IlzpNtJ4I07xU/gm
XWbTU7S7tn1ZIDcGCIxSsZV8lS4mjDRMCuHO4Z9K0v8A4JT/ABw1P4ZxeMm8PeF9O8MSaRp2vNqO
qeONB06K2sdQz9hnm+0XiGFZyGWPzApZ45EA3IwHqRxMpVlONJ6Nuy2+10s9u/8Ad1Xbl9hFQcZS
6JX+7fX+rn2L+x8uq/sw/tzftmfA3w14b0HR4Y/CXjuLwXoOpeFrO+1rV5D5T6fYwy3UL3t/DLZw
xypaPJLDMuZfKfczNT+AX7J114W/ZG+Jj6r4J0DUfj1pnxfbSfE0Hgn4f6F8UNZ0jT20vz/I/sXz
Bp+nWS3TzqLi1KsJ4ntmVRBtT4h/aD/4J/fF39lfw7q+rePPCJ0LTdC8QQeFr24/tOzukj1KfT01
GOBfJmffm0ljlLplF3qrMGO2lvP+Cfnxdsv2j9e+EJ8JCf4leHNPfU7rw/barZXF1PElol4VtvLm
Zbub7O4kEFuZJWAbCEowE+2qRtF0n7remv2r2W2jutLdU9A9mrX5lqlr3tbXfa36an6keD/gx4T0
T9oK9174KfB3wvo3i2w/aX0DStc0pLTTfFeteD9DGmW0160tvbm9tdJtk1D7U6XNnIrJIJoSYTZJ
GvyDN8HfFb/8HBniqX+xb+1Twb8XbvxzrdzqCfYoNJ0O21f+0JdTuJJCiRW32UpKJSyq6yR7CTIg
b4QorOeYxkopw0UubRpdW7aLTtfy2NI4Zp3v0tt/wfw89z0z9tT4h6P8XP2yPi14s8O3T33h/wAT
+M9Y1bTLlo3ja4tZ76aWJysgDqWR1OGAYZ5ANeZ13/7NP7MPjX9r74qW/gn4faZZa14pvYJLi2sJ
9Ws9Oe6WMbnWJrqWNZHC5bYpL7VdsbVYjjfEugT+FPEeoaXdSWUtzptzJazPZ3kN7bO6MVYxzws8
UqEg7ZI2ZGGCrEEGuCpzybqtaNv0vvb8TePKvcT2KVFdr+zx+zx4x/at+MWj+AfAOj/294t17zvs
Fh9rgtfP8mCSeT95M6RriKKRvmYZ24GSQDF8IPgJ4t+PL+Jl8J6SdWbwd4fu/FOsAXMMP2PTbQKb
if8AeOu/YHU7E3Oc8KcGoUJNJpb6L17fivvHzRu1fY4+iiipKCiiigAoorpfg98I9d+PPxM0fwf4
YgsrvxD4gn+y6fb3Wo22nx3MxBKxCa4kjiDuRtRSwLuyooZ2VTUYuTUYq7Ym7as5qivTPAP7HfxH
+J/7UE/wZ0Tw79r+JVrqF/pcujtf2sHl3Nksz3UZnkkWD92tvMc+ZtOz5ScjPmdOVOUVeSt0+a3X
yuJSTdkwor0Xwb+yh48+IP7OXjH4s6NpFpf+BPh/d2tl4hvk1azE+lSXUiR23mWhlFzsld9qOIij
FJcMfKk2+dUnFq11uNST2CiivQ/g3+y14w+O/hfWNc0KPw1baLoN3a6fe6hrvijS9AtY7i5S4kgh
WS/uIFkdktbhtqFiBGScZGSMJSfLFXYOSSuzzyivedS/4JpfGHQbnUBq2ieGdAstPg0y6Gqaz4z0
TTNJ1CHUYZ57KSzvri7S2vUljtrghraSQDyJAcFSA3U/+Cavxg8P3d+uraL4Z0GzsINMuRqeseM9
E03Sb+HUoLiexltL6e7S2vEmjtbkhraSRQYJFJDKRWv1at/I/uf9dH9xl9YpfzL70eEUV7re/wDB
Nr4vaNe6jHqujeGdBtdNt9Mu/wC0tZ8Z6Jpel30GpRXE1jLZ3txdpbXkcyWlyVa2kkH+jyAkFSAz
Uf8AgnF8XNBur1dV0bw3oVnZxadOup6v4x0XTtK1CLUIp5bOWzvp7tLa8jlS2uCHtpJFHkuGIKkU
/qlf+R/c/P8Ayf3MpVqb2kvvPDaK90v/APgm98W9E1PUrfVdJ8K6FDpltpl4dQ1jxtoem6XfQalD
PPYy2l7PeJbXiTR21wVa2kkA8iQEgqQH6n/wTX+L/h++vo9X0XwzoFrY22m3i6nrPjTRNM0nUINR
hmmspbO+uLtLa9SWO3nIa2kkA8mQHBUgJ4ast4P7mL29P+ZfeeEUV7vqn/BNX4weHru+XV9E8N6D
Z2UGmXK6prHjLRdN0m/h1GCeeyltL6e7S1vEmjtbghreWQAwSAkMpFJ8Rf8Agml8afhR8JvEnjrX
PCNrb+EvCcOm3Wo6lBr+m3cX2bUSgsLqEQ3Dtc21wzlY54A8TtDcKHJt5hGfVa1r8jt6Ppv+T+4a
rU3opL7zwmiuo+C/wc8QftBfFPRPBXhW3srzxJ4juRZ6bbXWpW2nx3U5BKRCa5kjiDuRtRS4Luyo
oZmVTraH+y94+8UftIP8ItL8NXmp/EWPWp/D7aNZyRzuLyGR45k8xGMWyMxuWl3+WqIzlggLVEaU
5JOKbu7fPt6lOcU7XOBor2v4Qf8ABOf43fH341+Jfh74O+HOva/4o8G6nLo+vpbCP7Fol3GbgGK5
vWYWsJY2twqF5QJWiYIWOAeX+Df7LfjD47+G9Y1rQovDlroug3NtZXuo694n0zw/Zx3FwkzwwrNf
3ECSSMlvOwRCzbY2JAHNP2FT+V/d23+4XtYd1p+ux55RXuus/wDBNr4weGLq9XWNC8P6DZWVvp12
uq6t4v0bT9I1CHUIJp7KSzv57pLW8WaO2uCptpZB+5kBwVIBqv8AwTZ+L/h29u01fQ/Dug2drDp9
wmq6x4w0XTdH1CK/gkuLR7TUJ7tLS8WWKGVgbeWQDy3BwVIqvqtb+R/cxKtTe0l954VRXu+q/wDB
NX4xeHWvpNY0DQdA06yg0+5TV9Y8XaNpuj6jFfwyz2j2V/PdJa3qyxwTsptpZf8AUuDgqQPO/jr+
z34v/Zr8ZW+g+M9JGl319p1tq9lJDdwX1nqVlcxiSC6trq3eSC4hdTxJE7LlWXO5WAmVCrFXlFpL
yHGpCTsmmcZRW7oPwu8TeKfA+v8AifTPDuu6j4b8KNbJrerWthLNY6Obl2S3FzMqlITK6MqbyN5U
hckGuo+EH7KfjX44+D9U8RaJa6DaeHtGvYNNutV13xHpugWIup0keK3Se/nhjklKQyPsRmYKhYgD
mojCUmklqynJJXbPOqK951f/AIJofGTw2LibWPD+gaBpUMdjLDrWr+L9G07RdTS9iea2ay1Ce7S0
vQ8ccjZtpZNvlvu2lSA7Uf8AgmR8Z9Ct7m71bw5ofh/RoFsnh1zWvFujaXoeqC8hkntjZajcXSWl
6Hjilb/RpZMCNs4INavC1lvB/cyPaw35l954JRXvuq/8ExfjR4djurjWPDmg+H9It0sJItb1nxfo
2maHqS3tu9zamy1G4u0tL3zIY3f/AEaWTARt2CCKXW/+CYPxr8K2Vzfa14Z0Xw9ocCWUkGu6x4s0
fTdD1UXlu1zbfYdRnuktL7fCjvi1llICndggik8PVTs4vts9xe2p/wAy+88Bor33Vf8AgmJ8avDt
nPfax4Y0fw/ocZs1g1/WvFekaZoOqG7t2urf7FqVxdJZ3u+BWf8A0aWTAHOKNT/4Ji/Gnw9a3F5r
HhrRPD2ixfYzBruteLdH0vQtV+125ubf7DqNxdJaXu+EF/8ARpZdoHzYp/Vq38j+5le1h3Xc8Cor
3/U/+CX3xr8P6dcajq/hnRNA0CI2aweINY8W6Npugao13bm5gWy1O4uks70tCC5FtNIVAO7aar/E
X/gmh8aPhT8J/EvjnW/C2mw+FfCMOnXWpX9t4l0q9C22oeT9hu4khuXe4tbgzKsdxCrwu8c6B90E
wjTw9Vbxf3Ppv91n9wvbU725l9/f/h0eEUV2XwN/Z+8XftIeL7rQ/Bukf2pe6fpt1rF9JLdQ2dpp
tlbRmSe6ubmd0gt4UUcySuq7mVc7mUH0S9/4JpfGrQb7xPFr3g+DwfB4P1weGtTvvFWu6d4e05dS
MP2hbWG7vriG3uJDb7ZgIJHzFJFIPkljZlGhUklJRdn5DdSCdmzwmivWtO/YW+LGoftBeIvha3g2
9sPG3hC2ur7XbPUriDT4NGtLaLzpbu5up5EtobYRlXWd5BE4kiKO3mJuXTP2E/i1qf7QPiT4XHwX
f2PjXwda3V/r1nqNxBYW+i2lvEJZbu5up3S2htRGUZZ3kETiWLY7eYm5/V6v8r3ts9+3r5CdWC+0
tr79O/oeSUV7rd/8E1fjVocvin+3fB8Pg628G6yPDuqX3irXNO8O2C6iYftC2kN1fTww3MptyswW
B5CYpIpB8kiMzLr/AIJt/GfRp/Eo1zwhD4QtvCOur4Z1O/8AFOt6f4e09NTaHzxaRXV9PDBPIYNs
2IXf91JHJ9yRGY+rVf5XvbZ79vXRj9pDujw2ivcrn/gnD8XdNt7671DQ/D+j6PYz2Vt/beqeLtG0
/RLyW8s1vbeO21Ca6S0una1dJSsEshRHUsFyK81+MXwc8QfAbx5P4a8TW9lb6rBbWt5/oWpW2pW0
0Fzbx3MEsVxbSSQyo8Msbho3YYbrkECZ0akFeUWle23Xt66ManFuyZy9FFFZlBRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3b/wAG0H/Ka/4Of9cPEP8A6jup1/WX
Yf8AHpH/ALv9K/k0/wCDaD/lNf8ABz/rh4h/9R3U6/rLsP8Aj0j/AN3+lAFyDqaKIOpooA+OP+Do
7/lBR8c/+4B/6kOmV/N1/wAEeNesW+LXxb8HSajY2PiD4qfCXxH4K8Lw3dxHbR6rrF5FF9lshNKR
FE8zRlFMjopYqgbc6g/0i/8AB0d/ygo+Of8A3AP/AFIdMr+Sj4NfBrxT+0L8UNF8F+CtDv8AxH4o
8Q3AtrDT7NN0k74LMSThURVVnd2IRERmYqqkjWhJqrFxV3daLr5fMiqk4NN20PsH9kDSbP8AZU/Y
e+Kfi/43+C7rx78Ob7xva+BV+GV5K+lXS+JrWJrqS/lu8fadMe1tvNgPkoXnNy8UgVEY19p+OPAv
jLxb+y9+1N4ltvB958YPDPxV8O/DfXfhj4N/s7ULe107QWvb17fRUsdKkjCyadDIrFLWbaARK+Tc
SofyE8R/sweNPC3we1Lx/c2GmzeDtK8VP4KuNUstasb2L+1VgafykEMztJE0SMyXCBoHCnbIxr02
0/4JP/HWf4SQ+PJ/C/h/TPCM2k6brp1LVPGeh6dHb2Oo5FhcTCe8RoUuCsixmQLvaKVRlo3C+nha
8ox9nGk2vnfaSvttrezTWj7tnPOlBy5+bX/hn+P36rWyR9xXi6b+zF+x58X/AAx8afhho/gLwj8T
P2hU0HxVoul3Fr9t8H6Xe6WmqwNa3tgX87+zyLOaKH7KYMLNGEJuHSLlv20PAOo+N/8Ag5lvrvQY
g2l+C/EPhjxRrOoS3SW9pomlafp2l3F3e3FxMyxwwxRxsd7sASUVcs6Kfhj4/fsH/FT9l7StdvPH
PhqDRYfDOv2/hfVAusWN3LZahPYi/hiaOCZ32vbEusgBjJV13b0ZQ68/YJ+LNl+0Rrnwmbwm0nxI
8PWDajc+H4dSs5ryeNbZLopbBJSLuYwSLIILcySsA2EO1sbVcZWcI0ZUnaMl67ztF2S1d3bRaqVl
roKkub2nN0t5bLXfy+5mV+2j4/0j4sfti/FjxToF6dS0HxL4y1jVdNuykiG6tp76aWKTbIquNyOp
w6qwzyAcivNKK62P4HeJpvgVN8SksbZ/Bttr0fhma8XULYzRX8lu9zHE1t5nnqrRRyFZTH5bGN1D
llIHizlKpNztq7s6VaKSPq//AIN1/DF34i/4K6/DGWDT7m+tNLt9Yur944GljtITpN3EJJSAQiGW
WJAzYG+RF6sAbn7HngqDwZ/wTJ/az1vxH4J8Mr8Qfgd4j8LTaFN4h8JWV1f6Leahd3em6ja3KXVu
5mQwxAC1ut6QyxGWONJg0g8D8H/8E6/jB47+JnhHwdpvha0bxL498LReM/D1jca9p1q2r6VKHZJ4
mlnVWcrHI3k584LG5KAKxEHwv/YF+Jvxk8GeMfEnh6x8KXXhz4falHpPiLVp/Gei2dhpU8rmOAvP
NdpH5UzhlimVjFMUYRu+1sd1KVaNONNQejnbfdxV+m8bJ/5bnPOCc3Pm0aX4N/nex+g/ww/ZF8F6
F/wc1a38M9F+HvhnWfhmIjeavos+g2+raVZRS6FDevIEnR0to/7QkiCsmwJ5qwphH8tvDP8Agjj8
QvFnwz8afHn4Y/2HoMHiuT4Z+LIdM0PVPB9hda9f64sMCHTMT2zXdzxbvnTnLwkpKWhJMhPg3hT/
AIJd/G7xl8XtV+H1r4V0q28eaNqc2kz+HNR8U6Rp2rTTxQC4YwWtxdJLcRGBllWaFXidCGV2HNcz
8Zf2IPiN8BvhhY+NPEOn+Hn8K6lcw2lrqej+KtJ1uCeSY3Yj2myuZvlZrC9QP93fayrncpFa1K9R
yVaNJxSnKWmna8b26Wt5X2IjCLXLKad4pfnrv1uXZf2O/ip8V/20tR+Elp4e0K++K+oaldLPo2ka
jpMFlHdJFJdTwxyW8q2MPlqsgMMbqsbIYgqsuweMV7/p3/BLf48ap8avFPw+i8BSr4m8Evp0OtpN
q1hDY2E2oeX9gga9ecWpnuvNQQwrKZJTuCKxRgOW8MfsSfE7xZ8NPiF4ug8Nx2eh/Ci6Fj4vfU9U
s9NudAuCXVIJra4ljnErvHJGiBC0kkbxoGdSo4p4ebbShK93v5dNlqtb/kjohJd1sv632fQ+lv8A
gnt4QtfE/wDwSu/ao8SW/gnwt4m8c/CXUfDXiHwneXfhCy1e7sI7mS7ttXeQywSfaLVLJFkaG4Ek
MDJ9oRI5FMtej/8ABK74d6R+0DqfjP4vah8LPA1z4fvfiHomn+IND0+10BfDvgzSPseo32papdLr
FrqE9jYhLfI8uWzjkPmQwys8ccdv+ZldDafCvXr74U6h43iskfwxperW2h3V2LmLdDeXMNxPDGYt
3mEPHa3B3hdg8sgsCQDpQxfI4Lluo627vXXbSyeu+3yWdSjdTu/i/DZd/wDLc/TT4Z/Af4Afsl+M
vjzYfGX4feG4/hv/AMLvfwTN/bL3Nzq/hvQ0sdW1DTZLNbdv7UthcSQWai6y0d3CZF+fy5GX3yx/
Z9tLbW/gD8Y/hN8EfBtl4o+Ieq/C/W/GMHh/wrZalZeHbO6i1SW7ubbT5Ip5tHgYwW/+mxmNXNqC
komjuGP5cab/AMEo/jrqPw/HiyTwrommeGBoGk+KJNV1Xxfoum2dtp2qtKmnTyy3F2ixfaHglVEk
KvuQgqDxXC/Hn9jH4lfsyap4psvHHhv+wrrwXqmn6LrMZ1C1uDZ3d9aS3trH+6lfeJLeGR9yblXa
AxVioPowxsqMEnh9L3Ts0+r3t0SdvK/y5vYU5v47u3f0Wqv/AFofd37KfwOm8bf8HKHxF8LeMvAF
l4g8Pal4u8WX2vabr/h6G/todOkN1dW12wuYWEMbu1m8dwoQus0YV9s2G8t/YE/Zu1dv2bPifLJ8
MvHN/wCMNH8b6bol5daR8MtB+I2paAIbXUTPY3Wh380V5p3mSlT9r2NFK1o8OUeBg/hR/wCCa3xe
tfCOna/qOj+FdA0TV9J0nXLK+13xtoekQXVpqi3bWLI91eRhnkWxuiYx+8jERMioGXKaf/wTT+NF
3q3xGs7rwnZaE/wkv7TTPF0uveIdM0W20Se7aQWvmT3dxFEyT+U5jkRmSQbSrEMpPMp1Lq1J/FJ9
eqWm3Tlbv67WNVBWsprZL7nvv5n6GeEPg98PPAXg/wD4KKeBviD4h8MeFPA9v4w+HsOt3nwz0y5l
0uxtjq87TG3tZZ5RbSJI6rNDunNpIblII5VhEL/F/wC2F4V1f4d/8Fg9R0vWvAvwZ+Hd5p3jLSxF
4dby28DWtr/ozWr3RRUVrKa3MU1w3lxFhNMTFCSYk8T+Ln7JPxG+A0ni1PGHha98Py+BtdtfDetx
3UkSyWd9cw3FxboFDEyJLDazSJLGGiZArByJELZ3xo/Z48Y/s9f8In/wmGj/ANkf8Jx4cs/Fuif6
XBcfbdLu9/2e4/dO2zf5b/I+1xj5lGRWdXEuUOX2drO/4y0enRuy873vpYo00mrzvdfotd/K/wA1
84/2h2D/ALQHjkhfByA+Ib8hfCWf+EfH+kycafnn7H/zx/6Z7K+yf2A/BN146/4Jw635nwV1T4+a
Bofxi0u+1Xwl4cujFq13E/h7WIUe4ewgfUbe2SZoXjklJgkdZkhCP9pLfKn7Nf7GnxL/AGvL7U4f
h94Xm1yPRpLOC/vJby30+xtJrycW9nA9zcyRwrNcTHZFEX8yVlYIrbWxc+E/7C/xR+M+jePtR0nw
7bWGn/C24trTxbdeINZsfD8Ph+e4llhhhuHv5oAkjywSxhM7t6bSASAcaDqKr7WMG736Xv8Ag07b
7PzNqyjKDg3bb8/VH6w/tX/De98SfsT/AAZ0S5+C2pfG5vhzofw/sPGfgLQrt4fEunXn/CM68BFq
EdnbNqVgkTT2kq/aGMUjb0iSJzctJZ/ax8A3PiL9hn4IaDc/BfWPjlN8ONH8BWXjXwBod29v4g02
5HhnXAkGox2cD6nYpE9xbyoZiIXLSpGkbm4eT8rtH/4JsfGfVdZ+JFlN4StNFb4Q3dnZeL7jXdf0
3RrPRJLx3S033N3cRQuk5jYxvG7JIpVlJV1Jf4L/AOCZPx08ffGDxj4EsPh9fw+JPAF5a6f4gj1C
9tNOtNNubqdYLOBru4ljtmkupHUW6JIxuQd0QkUE16MsZV0vR6229VbWOr8ndXT93VnJ7GK3qLRf
5ef9aan6k/tNeCNT8R/sPfBfQ9V+Cd98cl+GumeA7Dxj8PNCvZrfxLYXA8M66qR6jHZQPqNgkbXF
tKnnnypHMiRxxt9oaW3+1T4JufEn7BvwM0DUPgnqPx0l+GWm+BrHxr8PdEvp4PEmnTnwxrSpFfx2
cL6hp8cbzW0qmbEcj+YiIhE7yfjDrXwI8Y+GfB+va9qnh3U9K03wxr0XhfVWvo/s0tjqciXEgtHi
fEnmqtrPvAX92VUPtLoG9K8Q/wDBNT4w+C/FPi/R/EGheHfDF34EvbDTdbfXfGGi6Va2t1e2kl5b
W6XFxdpDNK9vE7lIndkC4YKSASOPqyu40r38r99NnfZ73WjslqN4WN783TzXbz/LXbXRH6n/ALVX
gG48SfsKfBHw/ffBXWPjlJ8MdK8CWXjDwDoWpTQ+I9PuJPDGtjydRhtIH1DT1hkltJozN+6kLSRo
iMJ2eT9q/wACy+If2APgR4WvPg5q/wAcrj4ZWHgmDxl8PtBvLi38SaZcSeGdYHk6hFZwve6ekUkt
rKhmXZKzSIiownaT8rNJ/wCCaPxq1LXPiVYXHhG00OT4P3lnYeMJ9f1/TdEtNDlu2kW08y4vLiKF
knMT+W6OySAoVYiRC3N/HP8AYo+J/wCzYPEjeNfCs+ix+EtWsNC1SX7ZbXENvfX1lJfW0CvFI6yM
1tG0jeWWEfyhyjOoLnjK1vaSpOyur29dHeOvW6d1o9FqKOHWyqdF+nn18tdVrsfrv+1h4CbX/wDg
n38CPDNz8F7/AOOOofDLT/Btt418A6Dd3Vv4k02eXwxq4jh1KK0ie+sUhllgmjMg2SM8yBIz5hkv
+K9G+INj/wAE6fiXonhfwjqniT4haB8GPhDoD+G7nwgniBre+tb2/lu7K4064hmjNzBbXcEzQyQl
40nSXC/K5/K3Sf8AglX8c9V8DyeJ38KaPpnhuHw9o3iubVtW8WaPpdjb6bq73CabPJNc3UaRmd7W
dVjYiQFAGVSy54/4+/sPfFP9l648TR+O/CVxoP8Awh+r2Gg6tIby2uIre+vbJ762gWSKR1lZraNp
D5ZYRgqHKs6g1Ux9blblSa312tdS6239dNG0ldiVKEvd509vPqvPv+a1Z+st7+zZ4S+H/wC2J40n
+A/w18C602kftH+EtL1efQ9KtvEl94Y0c6atxqSraSRTf2PbxagZwLqFoMSxSwqY1swqea/BX4qa
R8Of+CpXxS+GUHh/4h+FPjB43/aAl1Y+INC8PLqN1rnhc3zXg0qXzLiGWy0+Zdt5NdW6yebbEGRZ
YkVT8IaT/wAEsvjnrPx31P4Yp4R0228d6VKkEmkXvifSbOW4ka0W9Mdu010qXLpbSRySLAzmFZE8
wIWAPl3xn+AniT4A6lo9t4jTRT/wkGmjVtOuNJ12w1q0u7bz5rfetxZTTRZE1vOhXfuVozkDilPG
VIJTdFqKk3r8Or1S00aulvpZaGkMOlpz3dl69NfnY/Tf9jD9n3xFaf8ABzn40vtK8NeMrzw94e8Y
+JLrWdRvtAltIdKGo6dqTwNMYy6RwTPIRbSM6faY/LdVjL7F4b9lv4Ta/wCH/wDgmTe+BvFn7PXi
L4qat4L+OcWs+Ivh3aNqOneKHtrrwrcRW015BbRG7tLRJTDLFKV2zs0qZABJ/M+iuP8AtFaWj9qT
6P4raWa6WXr2LWGnZpy3UVt2d779fK1u5+7n7W8f/CSf8E1v2e/h5f8Awb1H47av8MF8KTeMvh5o
2o3lv4j01n8JXkMcN/b2aPd2EUM0lvMruq+a7yxlVAya/wC1PYR+Jv8AgnD8APA+pfBjUPjpq/wx
fwq/jH4c6LqF7aeJ9PL+Eru3WK/t7OJ7qwhimNtMkkigyu8iYVa/CuitP7UVvg79ut/LXe2t1vpq
xRwdlZPpbr5eem3Sz89D92/2stKtPEX/AATQ/Z88EX3wjv8A45658Nbjwo3jP4aaNfXdr4p0/f4P
uYUivobSJruwhim8qVWdMyu0iHaoBPxN/wAFOtX+GPgfX/gd4c+JPhP4ka/418NfBrwpp2q2el+M
LHQD4cdLIn+zri0m0q6mjuVLea/myBsXCjy1AUn8/aKxrZhzx5Yxtr5Pv5a79dOqSbKp4Xlle/S3
Xy8/L/g6I+sP+CfsOqp+1TrXjn4Zyr8OvhR4S00yeNr7x3PH4i0i20OaNYrqw1JYre2TUftrh4ob
NIUklkeNUKvGbhPp34Rah8PPjF/wT816z+G3wG8VfFnwDpX7RE/iA/DOx126m8RQ6VN4altraW5e
yikube1Fz80bkycxtA00rK00n5ZUVGHxzpLl5U9W/v8Awt5Ws+t0kXUw6lfXt36fO5+6/wC1Do9r
qP8AwTB+A3grUfhxrfx+1TwBqvhafxd8KdLvpbPxBoBbwXNaiG6hsYDfWUS3IjnDzqzSSvLHlU2q
Iv2o/B1rrv8AwS7+A3g64+HniP4/a98PNS8Ny+L/AIV6VeS22veHfM8Gy24ju4bKFr2yiS6Ecwad
Szu0ke4JtC/hbRXR/alneMfyffutd9b3T7amawrWqk+n4W8/L+rI/c79qHwfb6//AMEtPgN4Mn8B
eIv2gPEPw91Tw1deLvhbpF1JBrfh2KXwa8CxXMVjC17Zxpcqku64VmaRpI9yoVRE/aZ8O/29/wAE
vPgV4Gu/h54m+Pmr/D3VPDl14v8AhRpV3JBrvhzf4OltUS6jsYDfWUS3ISYGdWZ3aSPcqbFH4ZUU
3mr6xW9+j790779bry1Zo6Mnf3u34W8/L5H7r/tMaRpus/8ABLP4AeDrz4c6/wDtB634A1jw5c+M
fhRpl1Na694bR/BjWkaXIsIGvbOL7XtnBuNzNJvjBCMEWP8Aad0rT9U/4JcfAHwRqPw68TfH3xB4
A1rw5ceL/hNpl29rrXhxG8GvapFcLY25v7JDdBZ/9IDFn3xgouFH4WUVLzNPeHVvp1v5a79bry1Y
vqy11eqXV9Lefl6+Z+6v7T/h+21T/glx8APBV/4H8TftBav8PNY8OXPjH4P6VcTWes+GxJ4NNqi3
S2MDX1kn2oJJm4DM8nmIpRCEXn/FHw5+JPhz9ij4l2/hbw7rvjPxhpfwb+FGhHQL3wla68ulalBc
O13pMmny20geaCGdLl4biOSaE3KSfInkhPxKoqJZhzJJx6t9L683W1+vn5JXE8O73v26drf5f53s
fs/8MvhZ4V+Hf/BSD9ufwf8ACn4R+HPF3h7SvhvrcUUukRandKb660+zMnh4JZXKwRJLeLeJ5MMa
XCNFLHE8ax7E+P8A9nHxJ4u+Pv7Avir4fR/AvxF8QfhTb/FD/hMbfTvhr4jSDWvDGqTac1uYpbea
DUrxtOa3WNIppogDJbuv2iV96j4goqZ42MpJ8tleTsrfa6bPRfO/kKGGsrSd9EuvTrufuH4m1C3+
JX/BVz9u+30DwHo/xINp8LNQs21e2Oo3c97eLounQDQH+x3CQjfPbXCGOONLvzLeVVlXYyj5G/4I
ps/j7UP2lxpHwg0XWvM+FviSeJLSLWrgStOkRt9AHl3mfJm8qXyxn7Y/lttnO01+etFbTzRSqRm4
L3ZSf3u/bdd3fZaaBTwzjT5FLol93U/Sv9nLUW+Kf/BDvW9G8JfCbR/jBr1r+0Dca3c/D60j1m+H
hqwn0CNIb8Rafdx36wl4pbdJLiaSNvLYHdIC1fQHx3/Z++G3wi/Zo8c/Cf4a/D7xB+0X4R+HX7Sk
ural8NtB1ie51K0tLjwdDFvkubCOS6ghh1EzQBpAxLWBhZvMWZj+KlFZUcbCEIxcLtddP73dPTXV
O+wTwzlKUlLR9Pu8/LpZ67n7n/tJaTBr3/BLj4F+EtW+Huu/H3V/AXiLw3N4n+Euj37W2uaDA3gW
O0T7ZHY25v7EG8Qyfvg+8x7dyBgifmr/AMFYYNS0n4pfCjRtWuCL7w78IfCOlzabLKhu9Clj02Pz
rO4hESSW8yzGVzFMZJAJVbcEZIo/lqioxGM9rT5OW2t/z8r9e/oldlUsMoS5k/6/r59wooorhOkK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+7f8Ag2g/5TX/AAc/
64eIf/Ud1Ov6y7D/AI9I/wDd/pX8mn/BtB/ymv8Ag5/1w8Q/+o7qdf1l2H/HpH/u/wBKALkHU0UQ
dTRQB8cf8HR3/KCj45/9wD/1IdMr+bz/AII561ZT/F34teDG1GzsvEXxV+E3iPwT4Wt7m4S2TV9Z
vIoha2ImkIijeZkKIZWRWcqobeyA/wBIf/B0d/ygo+Of/cA/9SHTK/kq+C/wX8VftE/FPRPBPgnR
L3xH4p8R3ItdP0+1UGSZ8FiSSQqIqhneRyEREZ2ZVUkbYeTjVjJK+u3czqpODTdtD7M/ZMWH9mL/
AIJ1fFHX/jXol14/+HR+Idt4Nh+EV952m3Nj4nig+0z6rLdkCbS3S1ge2ItQ0tyd0U4jjhjLfYXi
f4UeMPEf7M/7Vfimw8B3fxg8O/FTw18NPEHw38LHQ7y1gttAe6uZIdES10yeOVG0+EJmO1lKssK3
EjfvCrfkF4g/Zs8a+Gfhdq3ji50Uv4M0XxN/wh0+u2t3BdabNqvkyTm2t54naO5xFE0heBnjCvEx
YCWIv6NpX/BMD41ar4ZbW38N6Fpmix+G9I8XS6jq3i7RtMtINL1V5Y9PuJJbm7jSPznhdRGxEgO0
Mql03ehhcVKMPZKm5LW3/ky7O61emyab0bZz1Yxb5nJL+l5/1deR99p4jX9l/wDYu+MHgX45/Da0
8E/DT4nftCppXiTw1Yaw73HgKy1DSo9UiuLI2cBtfMtFj06aMRiUTpbPDJbxL5ZbiP2x/Amp/EX/
AIOYby902AvpnhDxD4Z8Ua/f3FzHDa6NpWn6fpc95e3E8sgjihjjjY7nkAJKICWdVPw1+0B+wV8X
f2W9N1y+8eeCr7QdO8Oa5a+Gr69Nzb3NompXNgNQitUmhkeOV/sjJKwjZhGJIw5UuoM1z/wT/wDi
7a/tHa98IT4QeT4l+G7CTUrvw9FqVnLeyxJardsluqykXU32dxIILcySsA2EJVgN5YypyKn7J2jN
PXe6c/dfupbt200aem9pjSgm6qktV8tlrv5L8DH/AG1PiFo3xc/bI+LXivw5c/bPD3ifxnrGraXP
5Lw+faz300sL7HAZMo6nawBGcEA8V7x+yB4Z1z9tb9hDxF+zf4Iks7n4jweP7T4gaFod9rJs18Rw
Lp1xZXsVmJmW1W5hUwzvudHlhSQgt9nCn47oryVWftXUl1vf579++m/zOpwfJyRf9I/Xj9lL4kaN
8V/+C3X7M+jeCLxfGdr8CPhbD4H8S69oyyS6PcXNhpOoW9xd21wqK72Xm3MUSXDoodyAu5GjZ/PP
+CUekeHfgJ/wTg/bJ1L45/DDxRrvgO18ReCtD1zSnMuk3LzW+q3KXltHJuil+12rXFtM0AdBlY0m
aMSIT8F/Cz9lzxt8Z/hb448a+HtN0+48MfDe3hufEV9daxZWI09Jt4h+SeZHlaRo2RFiV2eQoigu
6K3n1djxzSjJw6yku2qS2ad7OOvfbQ51ho25E+y89Hf5bn63fs7eBfiaf+Dpq6XxzeQ+KfE+nXt9
f6pqeiadLaWlpp02gOlm5jBY26x29xZw4keTEhVGlmY+Y/zD8Mfgl8SPir/wSv8AHnw38O+GPFXi
PxR4N+M+nXmp+ENL07VrzWdFLaRqVtNcXNiIzBAnmW6w70HnF4nScKqW274vrpvg18H9f+P/AMUt
D8F+FrazvfEfiS6Wy022udQtrBLqds7IhNcSRxB3PyorOC7sqrlmUEeOdSXKovWU3a9376Stte+i
169ivYuKumlolt2d+/8Aw3c/WP8A4LE+L/Deo6H+0JqPiyHVvGvgGD42+HtOsrXw14omsJrXWIfB
5hu91xPY3VgRH5KwyRwKLrzIsXJRY7bf6L+3h8EvGnxP0n/gpnDongrxL4i1PXL74YWWltpelteN
fyWsNtPdQw7FMkjxwyW8sixghEZGkC7o8/iX8Sfh3rHwh+Iuv+E/EVn/AGd4g8L6lcaRqdr5qTfZ
rq3laKWPfGzI210YblYqcZBI5q38HvhHrvx6+J2i+DvDEFld+IfEVyLPTre71G20+O5nYHZEJriS
OJXcjaqs4LsyquWZQdp5k6rlTdPWUm7Le7c9Nm38f4aGUcLZRkpLRLp/h8/7v9W12f2nf2bPFH7I
nxs1X4e+NIbO18UaFDaSahb21wLhLWS4tIboQmRflZ0WZUcoWTerbWdcMfvL/glF+1zo37G//BOX
xhrXxM8J2Pjz4OeKvijY+H9X0S40i61V2Y6Le3fmxQXjx6S8i3NrpbfIzThEfz1A+wMPzp+JPw71
j4Q/EXX/AAn4is/7O8QeF9SuNI1O181Jvs11bytFLHvjZkba6MNysVOMgkc1ueC/2dfGHxD+DXjP
4gaPpUV54T+Hpsx4gvBf2yPp32uZYLcmFpBM4eVgoKIwGDnABI48PiJUcQ6lGO19HrZa76a2W+iO
irTjUpck3o7fmn/wx+6n7S0/i39pD9g74o/EFPg4vxG1b4kfCT4T6ougWulX8umarfNqWq3d7bWq
2VxHfH7Ot3BOUjmLIvlmYlHTf8+fA74vXP8AwTT+Ffxol+O3wb0CD4ZeJ/jbbWGtfDsWzeII9Ejv
NGutXhhtYmkj0OQx7dICtCfOVEfz41Asgv48UV1PNpc/tUve17a3v5X69/z0wjgmoOnKV07eulvP
y/Ltr+1H/BYjxD8Rv2/f2DPh3d+H9Bu/F3iLX9N8C+NNT8NeFbPVNQuNIlu9L8Qm4uzar5tvFayM
Y4kkUm5JtWW4JRLSvQ/jZ4v+H2i+Of8Agox46+J3gm7+JHwlOvfDXQtWTSr77NHez2iw29/b293F
Ijm5s5pYJHt1kX5kjjmaLepr8FKKc825rtw1bv0t9pLS1vta97eZKwCSUU7JK3n0638tD9dbr4e+
Nf2rf+Cr/wAZf2Uvj5Pc+MtB8Z+IYPGtxrnhSSTSU8HXFppQazvreBhNbxLNp81vp8yXAlLSPbH7
RJJEry/nf+3X+0X4i/aK+Of/ABP/AAyvgW28BafB4K0PwoYpBL4V03Ty8UGnzPMBPNNEd4kkn/eM
5bhFCxpxv7Pf7Pfi/wDao+L2k+A/AekjXPFeuCc2VkbuC0EwhgkuJT5s7pGu2KKRvmYZ24GSQDxl
YYnFyq0/hsnKTvvfra9ru127315tehvSoqMt9Ul/lfyva3yPtf4KX+jaL/wRY8Q3PxA0XXvEngaT
42WMWm2Oga7Pot/FqI0K7M0rz3Nnd2LQ+T5KiOCIXBY5mcRrbq36Q/tIan4R+GPxD/4KIeLPjH8O
ta8afCq/1n4X6dqNra3DaeupNDa232hba5WSN3mtvtdpcGGN1BDwLK0QlRj+A9dj8EPgF4t/aM8W
3OieD9KGp3lhp1zq97JNdwWVpp1lbxmSa5ubmd0gghQAAvK6ruZFBLMoN4bHzUFRjDmfTbtNbW1+
Lby8yK2FjKbqN/17vXp8P5dj9jb2E/CBf+Chvij9qfwm/wAWvDU/izwFY6pPoULaHZ6jaictHDaO
JFlWe0tLvTZGt0nbJREmnYSrcP5j/wAFJfD2v/D34AfHGf8AaEaP4iaYf2gNPisE8D6k/hmaO6k8
L+cjN9ptL22SCPT2sIRDGHnEqS+bcSqsTy/nLp/7EHxTv/2gPEPwvbwnPZeNPCUF1d63a395bWNr
pFtbR+bLdT3c0iW0Vt5ZVlnaUROJIijt5ibnWP7DXxWvP2gfEXwuk8H3mneNfCNvc3uuWep3Nvp9
vo9rbxebLdXF1PIltFbeWUZZ3kETiWLYzeYm7qnjazUo06bV2131fNo9NWubS+qs/wCZkQoRg/j6
Ly0VttdFo9rbrtr+x3/BTT4p2PgDTfj1p/xLtNMvfgx8TPjP4c8H615N3ex6roO7whpd1d6lAY98
Je2ktdMlRVhdpPInilV1kh8vgP8AgsL4B8aftGf8Lt8D6NY3viu0sPjr4Z1e90jwhpE+u+JtHt38
GwW899JaJIqNbMogjgJ8rfNDOjyj5dn5ZWf7CvxYuv2hvEfwrk8HXdh448H291ea7Z6jdW9jb6Pa
20XnTXdxdzSJbRWwi2utw0oidZIyjt5ibktv2GPitN+0L4j+Fk3hC607xv4QgurvXLPUru3sLfR7
a3i82W6uLueRLaK28sqyztKIpBJEUdvMTdrWzWdWMoSouzlbre75vdvb+9dLe/qKnQpw5UpLSK+7
3dd9vd/LXTX9NPA37NfjD4X/AAC/4KBeH57TxB+1jri614G0W21G+sdVvE8XXlpMZdQtGeyujdPc
aeLi2EscV0TF5UfmYRgh6T4U/GW9/wCCbf7LPxRn+PXwX8H2nwj8VftDXdnqXw6g06y8QT6ALzw+
mrpbwjz47CSNNuhCLCKEWK5JXf5Sx/lHpf7EfxS1T4+eIPhifCVzY+M/Cdvc3mt2uo3dvYW2kWtv
F5st1cXc8iW0VsIyrLO8oicSR7GbzE3Lp/7D/wAVL/8AaA8Q/C9/CN1p/jXwjBdXeuWmpXVvp9vo
9tbR+bLdXF1PIltFbhNrLO8oicSR7WbzE3YLGVKc1OlSaabWuqu+b3XdXb1tZvWz010UsNGV4zkr
NK/Ta2u9unb8j9pf2lU8RftM/sN/Er4jJ8ILr4h+IPiJ8Ifhde22g2ul6rLpOr3h1PUbrUbe2+xT
pcO1st5ZzlFnLorIZMqx3eDajJqf7K37DPxa8I/HP4Z+G/A3wf8AiV+0UdD1jw3pt95mp+BYdR0i
21YzWl3ZGSGQWUUejSwxi3ZWEM8bI3nbIvzWtv2GPitN+0L4j+Fk3hC607xv4QgurvXLPUru3sLf
R7a3i82W6uLueRLaK28sqyztKIpBJEUdvMTduT/8E1vjRpN94qh1vwnaeEYfBetjw3qt94p8Qab4
e09NSMRnFrDd31xDBcyGACYCB5MxPHIPkkRmPr1Zy9qqbveSfZt8zael2/e1V9r6a6UqUUrc+ll1
6adb7aduu/f9MtN0i/1D/g7s1C7sbC5u7bQ7cXN/JbwborKAeD44PNkIO2NDJJGgZmADSIv3iFP5
K/B7w9qXgf8Aah8LaVq+neHNL1jR/FNpaXth45t2h0i0niu0SSHVYnAKWyspWdWAIQSAiu48A/8A
BMz49fE/9oTxB8LNC+F/ia+8beE7k2mtWnlpFbaS/lySIZ7t2FtGkqRO0UjShJht8tn3LnlvhL+y
D49+NPw7v/F+j6dpFl4S07UF0mTW9f8AEGneH9NlvTEZvskVxfzwRzTiIb2iiZnVWVmUBlJwxNep
Wl/DafPOX38t1turfjsVQpwhtJO0Yp/K9nv1uZH7SX/JxXj7/kSv+Rj1H/kTv+Rd/wCPqT/kG/8A
Tl/zx/6ZbK4qvoDW/wDgl38bfCmmyalrfhbR/D3h/dZpa+INZ8V6Ppugau11bi5gFjqU90lnfEwE
SEW00uxTl9tJqn/BL/42eHbCbUNZ8MaN4d0FDaC21/W/Fmj6XoOrG6t/tMAsdSuLpLO+LQ/vP9Fl
l2r97FcUqFVty5Hv2e/Y6I1IKO62/pngFFfQer/8Etfjh4Z0ubVNa8K6P4e8Oq1mlt4i1rxXo+me
H9Wa6tvtUC2Op3F0lnfM0H7wi2mlKr97bTNX/wCCXnxs8M2U1/rXhjRfD2hL9j+za/rXi3R9M0HV
jdW32qAWOpXF0lnfFoPnItppSo+9tqfq9X+V9tnuNVqb2ku+/Q+f6K981P8A4JjfGnw9YS6hq/hn
RvD+gh7WO28Qaz4r0fTNA1Vrm3NzCLLUri6SzvS0ILn7NNJtGN2CQK8z+N3wD8W/s6eLrbRPGGkn
S72+0+21eyeO5hvLXUbK4jEkF1bXEDvDcQup4kidlyGXO5WAU6FSCvOLS2269vwZSkm7JnH0VtaH
8NvEXifwdrviLTdA1rUPD/hf7P8A2zqdtYyzWek/aHMcH2iVVKQ+a4KpvI3sCBk1s/Ar9nvxf+0p
4yuNB8GaSNUvrHTrnV72Sa7gsbPTbK2jMk91c3Vw8cFvCijmSV1XLKudzKDMYSk0oq7ewOcUm29j
jKK9WX9h/wCKq/tAeJPhfceD73T/ABr4PgubvXbO/uILKDSLa3j82W6nupXW3jtvLKMs7SCJxJEU
dvMTcaf+w/8AFS//AGgPEPwvfwjdaf418IwXV3rlpqV1b6fb6PbW0fmy3VxdTyJbRW4TayzvKInE
ke1m8xN1/V6tr8r3ts9+3r5bi542vfz+R5TRXrNt+wx8Vpv2hfEfwsm8IXWneN/CEF1d65Z6ld29
hb6PbW8Xmy3VxdzyJbRW3llWWdpRFIJIijt5ibmaf+w/8VL/APaA8Q/C9/CN1p/jXwjBdXeuWmpX
Vvp9vo9tbR+bLdXF1PIltFbhNrLO8oicSR7WbzE3L2FX+V72269vXy3D2kN7ra/y7+h5TRXrEH7D
XxWk/aD8R/C2bwfeaf428Hw3N3rtnqFzb2Nvo9tbxiSW7uLuaRLaK12FGW4eUROJYirsJE3Msv2I
vind/H7xD8MJPCF3YeNfCUNzda5Z6jcwWFvo9tbx+ZLdXF1M6W0NsEKsJ3kETiSMq7eYm5/Vqtr8
r3ts9+3r5AqkXqn5/I8qor1Oy/Yp+KN58d/EPw0bwld2XjHwlb3N5rdpfXEFlb6Ra28fmy3VxdTO
tvFbCMqyztIInEkZVm8xN3R3H/BNL406Rd+KU1vwja+ELfwbrg8Napf+Kdf03w9py6kYvPFpDd31
xDBcymDbMFgkkzFJHJ9yRGY+r1f5XvbZ79vXyB1IrdnhNFe63P8AwTW+NGj33iiHXPCdp4Qh8Ha3
/wAI3qd94q8Qab4e08al5Xn/AGWG7vriGC5k8gpNiB5P3UsUn3JEZlv/APgml8avD9z4qXXvB8Hg
+38F60PDmqX3inXdO8P6euomH7QLWG6vriGC5lMG2YLA8mYZIpBlJEZj6vV/lfbZ79vwF7WH8y+8
8Jor6O8R/wDBJv46+C/AEHi3XfDXhnw/4Tvb1bCx1zVvHGg6fpmqSvZw3qfZLma8WK6R7eeN1khZ
0bDqrFo5FXzzwf8Asi+O/iH8X9V8D+H7DRdd1rQtPn1fUrjT/EWnXWkWFlBB5811LqSTmySFEI3S
NOFDkRk7yFoeHqq14vV2Wj32t630H7SO9zzSivdbr/gmr8atFuvEqa74Ph8HW/hHW18N6lfeK9c0
7w7p6ak0H2hbWK6vp4YLiQ2+2YCF3zFJFJ9ySNmvav8A8Etfjh4Z0ubVNa8K6P4e8Oq1mlt4i1rx
Xo+meH9Wa6tvtUC2Op3F0lnfM0H7wi2mlKr97bQ8PV/lfbZ79vwYvbU/5l958+UV79qX/BMD42aD
pEmq6t4X0jQPDm+0itvEWs+KtI0zw/qj3Vr9rgSy1O4uks7xjB85W3mkKD7wU8V5j8bvgJ4s/Z08
YQaH4v0tdNvbywt9Us5IbuC9s9Rs503w3NtcwO8FxC4ziSJ2XKsudysAp0akVeUWle23Xt66MpTi
3ZM4+iiisigooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD7t/4N
oP8AlNf8HP8Arh4h/wDUd1Ov6y7D/j0j/wB3+lfyaf8ABtB/ymv+Dn/XDxD/AOo7qdf1l2H/AB6R
/wC7/SgC5B1NFEHU0UAfHH/B0d/ygo+Of/cA/wDUh0yv5vv+COGuWMnxe+LXg176ytfEXxW+EviP
wT4VtrqdLePVtZvYohaWQmkKxRvMyFEMjKrOVQHc6g/0g/8AB0d/ygo+Of8A3AP/AFIdMr+Sr4L/
AAX8VftE/FPRPBPgnRL3xH4p8R3ItdP0+1UGSZ8FiSSQqIqhneRyEREZ2ZVUkbUJONSMkr67dzOs
k4STdtNz6z/ZF8OaR+y/+xV8W/GXxn8LxeOfBl14zsPAs/wwmuDperweIrZZbpb+5nx9q0xYLYX8
CtGjNPJLPC6qsbkfcfjDwF4y8Qfs3/tWatpngzUPjT4V+J/hT4aeKfhv4Ol07VLaHTfDkl9eva6K
tjpcsYU2EbscW0+P3XnEnzp0r8hvE/7KHjrwl8D734k3el2Evgaw8XTeBZNYstZsb2B9Xit/tLQR
+TM7SxmH51njDQOPuyNXo+mf8EofjjqXwwj8Zv4e8K6Z4ak0nT9ea91Xx3oGmC3sNQVDZXUyXF6j
wxTlwkbSKoaRXjHzo6r3UMROMPZKDa/4El2frba6bS1Zy1qab5nNL+l5r+n6H3ObXR/2Uf2SPjbo
fxn8F6H4K8L/ABc+P0Hhnxp4E0y4shf/AA90i70waxp99aXunxvJKLZ2heKGSOS1ZbGaOOFWnuMc
z+2r4J1Xx5/wc832oaVbGXTvBfiTwx4p1++klS3tdE0rTtP0u4vb25mkZEhhijjYl3dQTtUEsyg/
D37RH/BOn4yfsoeC9T8Q+P8Awd/wj+kaP4nXwddznVrG5MWqtp8OpLb7IZndgbS4hl8xQY/nC7t4
KitqX7APxd0n9orxB8JJvCEn/CyfDOnPql54ej1G0kvZIVtUuytuqykXU32d1kENuZJSoYhDsbHQ
8TVcVS9k/dkn56OXuvTd3fTdPTopjh4c3tFJXcWvLaOu/kvk1dmX+258RNH+L37Z/wAXfFnh28/t
Hw/4o8a6zq+mXXlPD9ptbi+mlik2SKrruR1O1lDDOCAeK8woorxZzcpOT6ndCKjFRXQ+9v8AgnF8
KvGXxS/4JKftoaL4W8H+KfE154im8FR6fHpNhc3b3s1rq0ks0MUUSkSyJFMsjYBaNOeFc563SP8A
gnP4+/ZJ/Yv8dQ+H/BuifET9ozTviPo+ieIvDdr4R0/x1P4V0Obw5/acUot5rS48nzri9MMlwo8t
pNO2RSOFdm+Hf2Zf2XPG/wC2H8VYPBHw70uz1zxVd28tzbafNq1npz3SRLukETXUsayOqZcopL7E
dsbUYji/EugT+FPEeoaXdSWUtzptzJazPZ3kN7bO6MVYxzws8UqEg7ZI2ZGGCrEEGuyFRQhGcoPS
6TvZddtN02nv0OeUG5yipLWzt16ee2j6fkftpo37D/wa8F/th/Fbxf4Q0Hwf4u8KWHxa0nw14l8J
QW/h2fR/h/o0Oipqera1qE2pWd2bSyNx/aEHkQGw2vZTQJKJFjih4v8AZi/YmtfgF8XfEN98OfAY
u/G/h39rLTfDF5o9/wCHYNeu/B3gdBLc2eoAXEU1zZQTiUMNQym8WkTRzZVmr8pf2e/2e/F/7VPx
g0fwF4D0ka74s18zCwsTdwWnnmKGSeQeZO6RriOJz8zDOMDJIBPg3+z34w/aBHiw+ENHOsf8IP4d
u/Fmt4uYYPsWmWpQT3H7x137PMT5E3Oc8KcHHYscpSjONH7UmrffZadLr8NNTCWGtdOfRLX83r11
/wAz9Q/EP7JNutv+0x4sh8O+J9Z+Ktx+0DqOnX+nab8J9M+ImsaVoUltc3tldjS9QaN7e1vnuZGF
4cCT7JAI93zkdx8N/wBnPwnpH7QV942+Cfw0sLDxjbftKeGNB8S+FH0fRvE0/gHQk0yG4u7oJbNe
rpUb6lJfBpoZUWA2iRI0D2zxJ+KNFSs1imn7PZ33/wAXlpv03stNrazws2mubpbb0v1/r8/c/wDg
pz4d1Twx/wAFGPjpb6xp95pl7P471m9ENzbvA7w3F7LPDKFcBvLkikjkRsYZHVhkEGvp7/glH8PP
DOtf8Ezv2qrj4pP4s8K/CjXtZ8D6fqHizTNNkuhbi31kNcwwqSI5JES7tmkwJZIUlRxFKWWKT87q
K4Y4m1Z1kt76et9Px/4Y2lRbpqCdrW19D9iPiL+yXa6bpXx31ofDHRvDnxjsPi3Z6JL4P+HHwv0P
4lQeH/DsehrPp80GmXLQm3t7sy+ZNetFH5ssUaiKN/Ojjw/iV8FtK0z4Vftu+KfAXwD0bSbL4V+J
9D1Xwe+p+D9I19/DuoGJIPElk0sP2yzuIYYJzPJZPLNBY/JKsNtIMr+SddR8F/g54g/aC+KeieCv
CtvZXniTxHciz022utSttPjupyCUiE1zJHEHcjailwXdlRQzMqnreYc65Iw1bfa+vNbpvrurXsut
rc/1ZxXvS0SXTTS3nto99rn2X8A/irpPxR/Yj/aw+JKfCr4O6N4h8E654a8T+G1tfCFpdWnh6fUb
qTTr6GKO8Wcy2ksTBltLhpbe3lAkgihcBh9j/tOfsW/C/wCFOqfH1fhh4Bu4vHVr8WdNtJdH8MfC
3R/ibd6Pokvhq3vVaLSL6UfYLSe+urtjOm1MxQwRrtiZY/yT8Cfsb/Ej4mftSz/BXQ/DZvvibbal
faPJowv7WPbdWQma5j89pBB8gglO7zNp2fKTkZ8xqKeLlTj78Ou+2ut7aaP3le3ZBPDxnL3ZdPXt
br5P7353/VL9kDSvB/h7/g6I06z8F+DP+EB8O2+q6pGvhtrmyn/se7/4R65+1w5tLm4tk23fnERR
SkRf6sLGU8pPzr+DnhjUfB/7UXhXRtZsfDej6tpfim0sr6z8cwPBpFjPHdokkWqxsA6WyMCJ1IyE
EgIyKl8IfsreOPHv7O/iz4q6RpunXvgnwNdQWmvXKa1Yi70x55IooGeyMwuvLkkmRUlERjZlkAYm
KTZ55UVsS3GPu296Ul6Oy006cu6+7Q1o0VFu0r6Jfdf/ADO1/aS/5OK8ff8AIlf8jHqP/Inf8i7/
AMfUn/IN/wCnL/nj/wBMtlfaf/BCGHUdd0z9o/T9I+FVj42ul+EfiFHvRHq8lxqLTxQrBorLa3KR
FLlopCqpGt07I/lzLt+X8967P4Ffs9+L/wBpTxlcaD4M0kapfWOnXOr3sk13BY2em2VtGZJ7q5ur
h44LeFFHMkrquWVc7mUHLDVXGupqN9dv6TKrU06Tg3bTf+mvzPuX/giNfTePrr9p2HQvgroOuG6+
FniaZRZJrtyZPtKQm18PKEvSDBK0L+WMG9co+24JXhP+CJ18/wARH/aattC+C/h3V5Lj4YeJbiM2
S6/cPcm5WA2vhtRHfENBKYJDGMfbX2SYuGKgD460X9ir4na98efE/wANIfC00XjDwUt7L4gt7q8t
rW00SG0z9ouLm8lkW1ht04/fvKIm3x7XO9Nxon7FXxQ8QfHbxH8NYfClzD4w8H295ea7bXl1b2lt
o9taRmSe6uLqWRbaK3VACJmkEb749rN5ibuujVqr2b9m3yt9N32Wn4amUqcZczUt0vlbrv8A5H2H
/wAEVL+f4gr+01D4f+COga20/wAMvEk4axTxBctKLoW/2Xw6BFekGCVoZPKGPtrlHxctt+U/4IqX
1x8QYv2nIvD3wP0HXnl+GPiOcGwGvXDyi6+zC28OgR3xDW8hhkMYx9ufZIRcNs+X498P/sU/E7xN
8e/EnwztvC8kfjDwdHe3Gu291fW1paaNb2al7i5uLyWRbWK3RRnz3lETb49rNvTdJpP7D3xU1j9o
HxL8Lk8JXFt418GxXlzr1re3ltZ22jW9ohknuri7mkW2itlQAid5RE4ePazeYm54evOHs37Nvlb+
bfRe7pb5/IdSMXze9a6XXZLrv+Oh9ff8EU9Zl8ar+03HoPwR0PXGufhj4kdW07+35nl+2C3W18Oj
y70hreVopPLXH22TbJi5bb8rf+CLGrnxvF+03FovwU0HWTcfDHxJMjWC69cNL9pFubXw7iO+wbeQ
wSmMY+2vskIuG2cfIGk/sSfFLWPj14l+GSeEbu28Z+DYLy7160vbm3s7fRra0jMk9zcXU0i28Vuq
AETPII33x7WbzE3GkfsS/FDWfj54j+GSeFZbbxj4Piu7nXLe9vbaztNHt7VN811cXk0i2sVsF2kT
tKIn8yPazeYm68PXnTdJuk3yuXzb6fDuvn8hzpwfN726XXt13PsT/gifczfEO3/aeTQPgloOtGT4
Y+I5lexj8QXJmN19n+y+GwIr0gwSmCYxAj7a5jkxcts+VP2adJn+K3/BH3xV/wAIf8KLb4v6y3x0
F9N8NbKLUr+z8MWUmiP5OoRx6dcx6uFLiS2WS8uZYCsWEBmEzn4+0X9iH4p678fvEfwwj8JXNr40
8Hw3l1r1pf3VvY2+i21ohknubm7mkS2ht1TBE7yiJg8e1m8xN2yP+Cc3xgtNS8V2+reGdO8LJ4J1
lPD2rXnibxHpmgWEeoPG0qW0V1e3EMFxI0KGUCB3zEySDKOjHKNWooQh7N+7zL1b+XTtrsTOMby9
+17P5L59e+h+lfwi8C6v45/4OrfFHibQI9f8YeGPCurXUWua7Y2kdxa6I8vhy4gW2uJrWJYodkyS
WyCTEpaAqzSTh2bxn9kfwKg/4JJyeFda+CHir4z674H/AGhbm98YfDrTprqx1iC0bwxLawSXS2iv
fWiR3gkO94gjPA8YbPmAfHb/APBOL4xafqvi201jwxp/hMeB9aXw7q934o8RaZ4fsYtRaNpVtYrq
+uIYLiRokMoEDvmJkkHyOrFi/wDBOv4v2up+KbbVvDWn+FF8G6umg6pdeKPEWmeHrJL942mS3iub
64hhuHaFfNAhd8xMkg+R0ZtHiptpqm/im+/xJaarpbzvroZRoR5bKataK+S63T63P1E+Ldh4R8Yf
8Ey/hZodt8Idb+PHiHwD4v8AD8XxA+Huh3Mdpqto8PgRNPxd/wBlrJqFr5F7C6s19GsvnWc0HESK
AfFHQvDnjv8A4JdfDHw9a/CTWvjv4h8A+M/Dq+PPh74emht9YtSngNLFTctpkcuo2whvIijm+QSC
e0lgG2NFVfzQm/4JffGKz8IXfiG807wNpfh+z1KDSG1TUfiJ4dsbGa6n0+21KGOKea+WObzLO7gm
Vo2ZWVmAJKOF4zwX+x14/wDiR8YtW8DeHdP0XXta0HTZtY1O507xHpt1o+nWMMAnluptTjuDYxwI
jKGkacKrsIyRIdlXLF1LxXsnu/v95W1jrvqndaPRXYSpR1tU7deit56eu+2p+rXxY8P+HvHv/BND
4aaHZfC3xB8evE3w98Y+HLbx78OdEdLfU7Mw+BIrEfajpayahb+TeRtEzXoWQTWc1uAscYVZPiz4
c0Dxd/wTO+Fvh6z+FGsfHvxB4F8XeH18f/DrQWW21fTpIfAyWCC7OmI+o2wivEdHN6ok86zlgXbG
igfmNN/wTZ+M2l3/AIrg1rwpZeEovBWtjw3qt74p8QaZ4e0+PUjEZhaxXV9cQwXEhhAmAgd8xPHI
PkkRmWX/AIJtfF6zTV7i90Xw1pOk6LcWNpNrep+MtF0/Q7ie9sU1C2httRnu0tLqR7OSOfZbyyMs
ciMwAYZaxtWyvSe76Ld83eLvvs7rfRXY+RLT2i/q3n/V0fpx8VbDwl4w/wCCZnwv0K1+E+tfHnXf
h94x0CH4gfDnRZks9XsZYvAaWB+1Npkb6hbiG9idGN8PME1lNAoWNNq/Ev7bniz4I6P4o+H+neK/
BnxB8Q+LtH+HfhnStbOheMNI0GLS7y00q3tZ7C4t/wCybqc3cM0MqytdSiZSRF5aJDHu8gk/4Ju/
F20XVZ73RvDOk6TpE9naya3qfjPRLDRLqa7s0vreK11Ge7S0u5GtZI5tlvLIypIpYLuGfMfi/wDB
/X/gT47n8N+JbazttUgt7a7/AND1C21C2mguII7iCWK4tpJIZY3hljdWjdgQ3XOa58TiKjpq8Gve
erV+stNV59+jsldlwpQcr89/n/wf663PpD/gnppWq3P7U2t+O/htKnw4+D/hDT1fx3qPjyePxHo9
noc6rFcWOpLFb2yakb11eOCyjhSWVzGEKtEbhPoT/glTf+G/iB8Wf2un+D3wRu9S8FXHw28SDRot
Tm1W/wBTlhuUiFroMptbpIytyYZnSJQ94BG6pdSmJpG/NzRvh/r3iPwrrOu6fomr3+h+HPIOrajb
2cktppfnuY4fPlUFIvMcFU3kbmGBk1ufAv8AZ78YftJ+LbzRPBmjnVrzTdNudZv5JLmGztNMsbaM
yT3VzczukFvCgwDJK6ruZFBLOoMYfFSi4RUOazvbu/LR2Xklr91qq0LqTcrXVv8Ah9dfv/W/2z/w
RWvbzxj/AMNONoHwd0nW1uPhh4gINimuT7/tIiNv4eHlXnME4hl2Kc3jiFytx8hIl/4Io3snjaf9
p46P8F9I12O8+GHiHyk09NcnDSXXlG08PL5d780Exhk2Kc3r+S+2clTXyRYfsL/Fe+/aB8S/C5vB
93Y+NfBkF1ea/a6hdW9jbaLa2yeZLd3N3NIltFbBChWd5RE4li2O3mJujsv2IfipefHzxJ8MX8IX
lh408HW91ea7Z6hcwWMGj21tH5st1cXUzpbxW4QqyzPII3EkWxm8xN2+HrVIez/dN8rl82+nw6Nd
tfkOcIS5rS3S6/jufXf/AARLu7jxm37T/wDYXwW0jxEbv4XeIBEtlHrdwGe68k2/h8CO7+aGYQzG
Nf8Aj9YwsVuDsNH/AARMW7+IA/ag/sH4M6Xr6y/C7xBIv2CPW7ne1yYPs3h4CO8+aCcxSbBzeuIn
KTnYcfImk/sP/FTV/j34i+GQ8I3Vl4y8I29ze65a6hdW9hbaPa28fmS3dxdzyJbRW2woyzvKInEs
Wxm8xNy237D3xVn+P/iX4XyeELux8a+DYLu7160v7q3srfR7a2j82a6uLqaRbaO2CFWWdpRFIJIt
jN5ibnQxFSDpr2Tbg5J6byfTbRrtqKcItytKzdvw+f8Al8z60/4Io3N14zl/ab/sL4O6Tr/2j4Xe
ICq2UWtXIla6NuLbQAI7vmGYxSCMf8fjmNik+VyD/girc3PjN/2nH0P4N6Rr8c/wu8QkLZprk6u1
z5LW2gDyrz5oZfIlMa5+2P5LlZzsOPk60/YU+LNz+0D4m+F0ngy+sfG3gu2ur/X7O/uILK30a0to
vOmu7i6mdbaK2EZRlnaQRSCWLY7eYm4tf2F/ivP+0J4j+Fkvg+707xt4PgubzXbTUbq3sLbR7W3j
82W7uLuaRLaK28soyztKIpBLEUdvMTcsPiJw9klSb5G16t9Pheq7av0HLklze8tVf5d9z6x/4Ir6
rN4rX9p8aL8HtE1v7Z8LfEPl/ZI9auNzXXk/Z9AUJeEGKbypDGDm8cwsVnO01o/s6xT/ABP/AOCL
HiK08J/Dmx+L2rt8e5NSk+GNpFqV9D4Tsn0AiPVI49Pnj1QJIwa2El1czQEWgCr5old/jy2/YY+K
037QviP4WTeELrTvG/hCC6u9cs9Su7ewt9HtreLzZbq4u55EtorbyyrLO0oikEkRR28xN25c/wDB
Nb40aPfeKIdc8J2nhCHwdrf/AAjep33irxBpvh7TxqXlef8AZYbu+uIYLmTyCk2IHk/dSxSfckRm
Ua8/Zwh7J+7zJ+bfT4dLdtfkKcabu+Za2e/brufoX+2X+yh4l+P/AO2l8efGWq3vxN+MPwH8DeNL
fyPAPhG6/tC78UeKU0axSSxNtpyGPT4baPZbXGoSQiVYoBArzXW7bpfEW8+Ivxe/Yr8U2fxn+FWo
fGr4maL+0bJr/jj4X+Fr/bd6fYTeDYbewuDJpnnzwW6kRIsrGQO1mUd/M80t+XMH7G3xQuf2oh8F
o/BesSfE9tS/soaCqqZjNt37t+7y/I8v975+/wAnyf3u/wAv563dH/4J7fFnVIfFdxceH9K0DTvB
XiObwhq2qeIfEml6FpkWsRbzLp8V5e3EVvcXCKjM0cMjsqFWICupOksZNzc3Td+aTa3V3zaNOLu1
fZ366e8yFTUY8rmtEv01362/qx+gv7XviD4za3+y98MfhLpfwd8N/HTwT4T8PeE7zXPC08d7P4i8
E+JR4ehtHt7my0i8ttRhjMEJYPdxsnmTSR+ZujWKK9+z38CfBfwH/bk/bZ+HXwr+Hdp468KeHfhp
rlrZXoutS1S4e7ubOzf/AIR0yWtwiNGbpLqJFCC9P2d184sjkfmf/wAMa/FE/tQf8KXHgnWn+J/9
of2aNAWNWnaXb5m8MD5Zg8r9954byfJ/e7/L+euL+IXgLVvhX4+1zwvr1p9g13w3qE+l6jbeakv2
e5gkaKWPehZG2urDKkqcZBI5pQxrpP2jpPSW+mnxXjfl87u99io0Fayl06fg9/LQ/Rv9kx9M+Lv/
AAR9XT7L4Tan8ZU0f9oi98Q6t8LPCl9eLcWen3Phg29tc7oBPqENslyAqyyllkNr5e8sZGr6Z/aV
8JjWP+CXXwS8EXfgbxL+0BrPw81/w7deLvhJpEstnrXhlZfAsdvGLpLGA31sq3gMpedTlh5IYAMq
/kD8If2PPH/xv+Ht/wCLtG03R7Lwlp2opo8uueIPEOneHtMe+eJpRaRXN/PBFLOIlMjRRszqhVmA
DKT0t9/wTb+M2gan4ptte8J2ng9fButL4d1S78U6/pvh6xXUGi85baG6vriGC5cwFZgIHkzDJHL/
AKuRGbOhia0YRUad0n2Wt0/LXfZ3W9lqwnBc799Ly+7z/q/ofq5+0poMWr/8EtPgV4H1DwF4m/aE
1/wB4g8PXPi/4TaXcy2eseGkbwQLWKO6jsYTqFsouVEpe4U5ZDErKvyr+bv/AAVtt7rRfid8IND1
G+vjq/hr4O+EtJ1LR72JYbrwxdRWA82wlj2LIjhiZikxZ1+0YyqhETj9a/4JifGrwvpVzqms+GNH
0Hw9CbNYPEGreK9I0/QdVa7tzcwLY6lNdJaXxaEFyLWWUqAd23FeZfG74CeLP2dPGEGh+L9LXTb2
8sLfVLOSG7gvbPUbOdN8NzbXMDvBcQuM4kidlyrLncrARjK9SdO0qdlzb2666Xstde/R2SuyqVOK
lzKV/wCl527dDj6KKK8w6gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigD7t/wCDaD/lNf8ABz/rh4h/9R3U6/rLsP8Aj0j/AN3+lfyaf8G0H/Ka/wCDn/XDxD/6jup1
/WXYf8ekf+7/AEoAuQdTRRB1NFAHxx/wdHf8oKPjn/3AP/Uh0yv5wv8AgjX4h04fFX4yeDptTtbL
xF8VfhB4j8E+FLS4mFumt61eJCLWxErlYo3lMbBDKyqzhEB3ugP9Hv8AwdHf8oKPjn/3AP8A1IdM
r+Sj4NfBrxR+0L8UtD8FeC9FvPEPijxHdLZ6fYWwG+eQ5JJZiFRFUMzu5CIiszMqqSN8LUcKsZJX
d9u//B7eZlWipQcW7H2z+yLYP+yr/wAE4PiV4r+Ofha6+IfwjvPiInge2+FN9JNpd3ZeLra3iup9
Se7KCbS3isw9u/2bdLcEiGdFjjRq+svFPwa8f+Jf2f8A9rLxtpXw2uviz4F+LHh/4ea18PPDn/CP
3VtbroxuRPbaIlvpUsbpJptpJD5kVrMBtWKeQkTYb8j/ABJ+y3448K/BvUPiFdaVaS+CdM8VyeCJ
tZs9Vs7y1k1ZIGuGgiaGV/OTyVLiaLdCwK4c7hnsPBf/AATl+Lfjzwhquv2mjeG7LRtDs9N1DULz
V/GOi6RFZW2o28NxYzSG6u4tqTpPGEY8F98f+sjdF7KOImlGnyNpXt90vLW127PTR92c9SjFydTm
Sf8Awz7+X5dkfpZqNxbfsr/8E1PiV4M+OHw5tPAfgr4oftNXOh+LfD+naxvPgvTdQ0TTtWtp7F7G
OS332JSxmVY4pFmjjaF4V+Tb5h+1/wDD/X/HH/BzxdXtpaxm18EeJPDHivxBqE00cNlo2kadp+l3
F3qF1NIyRwwxwxl2LsBuZUBLsob4Q+OP7BPxb/Zt8Ia3r3jfwdcaBpPhzxQvgvUJ5b21l8nVmsxf
LbhY5GZwbZlkEiAxkMvz5IFJF+wb8WJ/2hPEXwoTwk7fEfwvZzX154fGo2n224SKFZ2W0Xzf9NlM
LCRIbUyySJlkVgpI2+uVJQVL2baUk133k0tI+btp0enbP2EOZ1Odapry2jrv5fc1roZv7anxG0n4
xftkfFrxdoNz9t0LxT4z1jV9OuPLePz7a4vppYn2uquuUdThlDDPIB4rzOiivJqTc5OT6nfGKilF
dD7e/wCDdTw1qeu/8FdfhldWGn6heW2jQateahNbQGRLGA6XdQCWVsERxmWaKPc2BulRQdzKDB+y
D4dbwL/wT/8A2o9R1/wZ4XXxx8EtW8P32jHxD4O0+8v9Hvry/fS7+3uVu7d3mj8nK/ZbkPFFMvmp
Gkw8yvn34JfsXfED9oX4a+IfGHhi18Mv4b8JzxW+s32qeLdI0dNMaXAhMq3lzEypIx2I5Gx3BRSW
BUXvG37APxc+G/hj4k6vrvhL+y7b4Q6jBpfi6KfVLJbvRpbiSOO3drbzvOkgmaVPLnjR4ZASyOyg
kdsJ1FQilB2Tk769Vbt05b79H2OaVOLqNuS1SVvR/rex+hvwj/ZQ8LaH/wAHOHiH4b2nwr8I3fw6
aOa71fw4+iQ6zpGnW82hx3gmCXETJaKb6SAjywixNMII2MbBX8T/AOCL/wAQvFfw08V/tC/C9tF0
G38USfC3xZFpmg6n4S06fxBqeupHbJ/ZYFxbtd3WPs7s2msXiYxSsYC28n8+6K0WYpVFUjC1pSe/
SVtNtLdPXYl4RuLjJ3uktu19d+t/+Cez3n7HfxU+Jv7aWqfCSHw9oVz8V7zUrtbrRtL1HSbeyguk
ikuriFJLeVbGHylSQGGN1WJozEFVl2Dxiiu0P7PXjIfs8D4rnRJR8Pm8RHwmNY8+LYdUFsLo2wj3
eZkQEPu27eQN2TivPlyy+FO+vW+n3dNbvr2VtepXS95n1n+wR8LNb1n/AIJfftF+P7X4baP4ivPh
lqOk6t4U1y+8DWWrrBcs/k6xG0s9tKt3DDp0sc0ltOZIbbelyEjkxKfWf+CZPw48J/HuXXPjde+B
/htd2ut/Eyx0rxT4C0vStHTQvAegxWUl/e69dNrFtfyWWmvtmTZBJagtDLHHMpEEcf5t/EH4ba38
K9atdO1+xbT7y90yx1iBDIkgktL20ivLaUFCRh4J4mxncu4qwVgyjDrppYpU5QvH4d13d35ab2+S
uYzoc6k09/y089T9kPh/+y9+zX+yN8N/im/xu+FWjaZ4GvP2kNZ+H91q+tW+r3GpaP4dg0aTVNIS
xaFvtMO6ZbU+fEWa4t7wiQtHscdx8NPAHg7xXb/CLx78KPgh8PdN+KWvfE/4d33jaHQfDS6pFpXh
2/8AD9lfzXdvZT28sej2a3j3Cfa7Yh/Mt23zh0wPx08H/sy+NPH3wI8XfErSNMs73wd4Dltodeul
1W0W4003EscMDNatKLgpJJKqq6xlSQ/P7t9vBVuscouDVOyTuu730vbZPbs193M8FKV26jb28unS
+766n6h/sh/Ay78af8HJvxI8KeLvh/Z+JdA1PxX4rvNf0/xB4Yh1S3g0+Vrm5tL1luIHEKPM9i0d
wqpvE8ahtk5VvNP2DPhfMn7LHjnQovgp4mufiX4f8exWuseI9N+HWkfEjW9OtRZzJ/ZFx4c1KWOT
T0S4jkkN8kf7x90DsDCin4HorN45XTUdpSe/SVtNulvx6G/1Z2avuktu3Xf+vM/XfwR+zp4U8C+F
v28dK+Jlxpvg74RP4u8HaNrOv/DfQpzo8Dw6zBJewWcNxJL5M0JuYftMETzCzeYiKKaNYYZPjH9q
bw/feDf+CvepafqXgb4QfDeWy8dWCx+HrpWPgeyt/NgMDXWUQtYSw+XNO3lxbkllIhhz5SfK1FTW
xkJpWhazvv5t2Wmi1/Nu+lnDDtScm76W/L/L+uvZ/tHsX/aH8ekr4MQnxFqBK+D8f8I6P9Jk407H
H2L/AJ4/9Mtlfbf/AAQkguvE/hj9pLStL+FGm+MdRi+EniA/2isOsT3WrPOLQQaFIttcrD5dx5E7
II4ku2cPsnAUBfzxrsvgd+z94v8A2j/Fl3ovg3R31a803TbnWL+R7iG0tNMsbdN891c3MzpDbwIM
AySuq7mVc7mUGcJXlDEKpCN3fb1+T/IutT5qfJe3mfcv/BE7UZfHi/tPR6B8FfD+tSTfC7xJMgsl
1y4M/wBrNqLbw6At9gwSGGXygAb5yr4uG2/K/wD4IlXx+IMf7UEOhfBDw/rtxL8LvElxAbKPXblp
TdfZhb+HQEvSDBIIpzFgfbnKPi5YrgfINh+wh8Wr79oTxL8LG8GXtj428GW11fa/aahc29jbaLaW
0fmy3lzdzSJbRWojKMtw8oicSxFHbzE3Ntf2FvixcftCeI/hZJ4NvbHxv4PgubzXbO/uILK30e1t
4/Nlu7i7mkW2itRGVcXDyiJ1kjKuwkTd2UMTWh7L923yOS23b6bbrXQwnCEuZKa1Se/Rdd9vu9T6
8/4IpamPHMX7UA0b4K+HdZkb4W+JZ4TaJrlx5puzai28PfLekeRIIp/KA/05yr4uWKgBv/BFi8f4
iWX7UUOhfBnRNTlk+F3iS6jfTl1y4ab7SbX7P4d+W9ZTbSCGYxjH25zG2LltuB8iW/7DHxYl/aB8
S/C6XwbfWHjXwbBcXevWl/cQWVvotrAgkku7m7mdbaK12MjLcPKIXEsRV2Eibo7L9iL4p3nx78Qf
DJ/CF5Y+M/CdvcXmt2moXEFjb6RawRiWS7uLqZ0torXy2RluHkETrLEVdhIm4oYqrT9m/Zt8jfTd
vptpbXv+BbpxldqW9n93z2Pr7/gitqLeOl/ac/sP4NaBqjn4X+JbiM2S67Obj7X9mW38OZS9I+zy
CKbygP8ATZCrgXD4wH/8EUdUfx2v7TkWg/BPQNamm+GHiSaJrFdduGl+1/ZltvDo2X2Dby+VN5YA
N9IVcC4bHHx7p37EnxS1H49eIPhkfCN3ZeMvCcFzea3a39zb2Nto9rbx+ZLd3F3NIltFbBCjCd5R
E4kjKu3mJufp/wCw78Vr/wCPniT4Yt4OvbHxn4OgubzXrTULiCxt9FtbdA8t3c3UzpbQ2wVkIneQ
ROJYtrt5ibqo4ivT9lek3yOS23b6bbrXTX8B1KcXze9vb+tz6+/4Io6xH4zX9p4aV8FNB1oyfC3x
LNCbFNduTI139mW18P8AyXhBt5DFL5fS9fbJi5YqAF/Zwdvif/wR48UWvhP4cQfF7Wm+Op1SX4V2
0erX1h4TsZNDfytUhjsLiPUgHZZLXzLm6miK2qAr5oaRvkGy/Ya+Kt5+0H4k+Fr+ELmw8a+Dobq6
1201C7t7G20e2to/Mluri7mkS2itghVlneUROJItjt5ibty8/wCCbPxn0O98URa74StfCEPg/XB4
a1O98U69pvh/T11IxecLWG6vbiGC5k8kpNiB5P3MsUv+rkRmyjVrKEIOm7RcltvfptutdNfTQUoU
22+bez36L5/ifev7SH7Keu/tBftW/tDeM3uvjj8Y/wBnnwN8RJVtfA+jS6lqFz4q8YJY28dxp6xR
xf6Da2an7PJetFuSzhgggeV3jcacl54t+Kn7Eni/SPiz8G/F/wAZ/ipon7TN74j8c/C3SL7Uo721
sLjwubeylV7b7RNBYpMFWCVNySRW0UYdk2EfmdH+xz8T5P2oF+C48F6yPig2pf2SNAKKJ/PxuzuJ
8sQ+X+98/d5Xlfvd/l/PW7on/BPr4r6zbeKbqbQNJ0LS/BniKXwjquq+IPEul6HpcesRBzLYRXl5
cRW9xcIqF2jhkdlQq5AV1J0liqjk5ezfxNvqr66O6eqvs79dNWR7FKHLKell+nW/W2+n4H3f+0f4
q+L/AIn/AGefC3wZ0b4A2nxo8NeBtL8Iah4n0HUo9duNe8L+Ij4VtLYRtY6fqFvcW9sLWIfMbdYj
PJMru8q4Xpv2Vfhh4D+F/wC2n+218PPg98J38aeGPDfgDxLp1jeXK65calLeSW9oj+GX8m4jV7c3
dvfRxbYxeSLExW6kC7q/NH/hi/4p/wDDU3/Ck/8AhCNa/wCFpf2l/ZX/AAj+xfP87bv3b8+X5Hlf
vvP3eT5P73f5fz0zwt+x38RvGXx28T/Daw8PI3i3wU2ojxBDPqNpbWeiJYF1vJbm9klW1hhiZCpl
eURligDEuoJSxUoVOaNJ35n66814rT+9d3vqtuhLoQaaU9139Nd9tPu6s+5f2SLzw/8AFn/gkXDp
tn8INT+M1zo37RV14i1r4XeFtR1RJoNKufDDQWkoMJnuobdLlHVZm3s/2bY8jda+hfjnoGl61/wT
g+F/gSf4V+O/jh4v+HHi7wveeP8A4V2VxqtpqenQyfD20t7d5I4FlltI1mCkuiIDLHJGw3bsfl9c
f8E1fjTo954mi13wjbeDYfCGsjw7qV74s17TfDlgNRMInFrDdX9xDBcSGApMFgd/3UsUn3JEZpbr
/gmZ8ZtL0661HUvD2g6HoNtJaQx6/rHi7RtM0LUZLq0W8hjs9RuLpLS8c27pKVt5ZGRWUsFyKinW
qxhGDpvRvp1tLTbzejutHpqy504yk5Kf9aee39XP06+NmlaVrn/BNr4VfD+T4W+O/jx4q+Gni3w3
d+P/AIXWlxq1pqelRyeAbaGDfHAJJbOJbgnLpEgaaGRG+YsT8Rft46v8KfA3xC8DeHPiH4F+MWqe
OfDfw68JadrMEXjCHQE0iRNBsj9i+yXWl3bo6E72IdFzKVMKurySeSaj/wAEx/jRoVld3+q+G9D0
PQbWaztk8Qat4t0fTtA1CW7s1vreO01Oe6SzvHa1ZZdtvNIVV1LbcjPl/wAafgf4m/Z88b/8I94r
sbay1FrO21CFrW/t9QtLu2uYUmgngubaSSCaN43Uh43ZeozkECK9eXsuX2dkpPVq/wDNpqtXrbXR
WdktRwhGUr899Oj/AB0f6H0L/wAE+11OD9qzV/HPw1mPw4+EnhawB8c6h44mTxJpFpoU6pDdWWpJ
Fb2yaiLx98cNlHEksrtGqFXj+0J9Ef8ABMLW/BnxF+Kf7WUfwf8AgdLc+Dpvh54kk0FdWm1bU9Xu
4blbZbXw9MbW4WHy7gwzvGkafbR86C9l8vzD+b2ifDvxB4l8J63r2m6FrOoaF4ZEDaxqNtZSS2ml
CeTy4TcSqpSLzJPkTeRubgZPFbPwQ+AXi39ozxbc6J4P0oaneWGnXOr3sk13BZWmnWVvGZJrm5uZ
3SCCFAAC8rqu5kUEsygrB4ypCcFGPM027d7q1lo7fJb+iLnRi7u9tLf8P3/rufbv/BFq4m+IcH7T
NvoPwV0fXZ5fhh4jmik05NcuJJDdfZhbaBhLxg0EnkzeWABeuRJi4bYArv8AgiveTeP4f2l7fQPg
loXiCaX4ZeIp0ksY9duZJftP2b7N4eAjvSDbymGXywB9tfbJi5O3j5Ksv2E/izeftC+JPhW/g28s
PG/g63ur3XbPULq3sbfR7W2i86W7uLuaRLaK1EZV1uHlETiSIo7eYm5NO/YW+LGoftBeIvha3g29
sPG3hC2ur7XbPUriDT4NGtLaLzpbu5up5EtobYRlXWd5BE4kiKO3mJu2oYmtT9nam/db6bt9Nvw1
+VhScHze8tUnv0777fcfXH/BFO/k8eQ/tMW+hfBLw/4gnl+GPiOeNrNdduJZzdfZhbeHlEd7hoJP
JlMYUfbn2SYuGCnan/BF3WY/G0H7TcWk/BXQNXef4ZeI54ZLBdcuGka5+zfZvDoC3pBt5fJmEYA+
3PtkIuW2YHyTZ/sJ/Fm6/aD8S/C2TwbeWHjXwZb3N7r1pqN1b2NtotrbxiSW7ubuaRLaK12MjLcP
KIpBLFsdvMTc3Sv2GPivq3x98RfDEeDr2y8Z+ELW51DXbXULmCwttGs7eISy3lzdzyJbQ2vlsjLc
PKInEsWx28xNzo4urSVKTpu0HJdrt9NtGu2voKSg+Z826T3/AB3Prj/gi1qDePl/aZj0T4K+HNXL
/DLxLdLJaDXZzILlYPs3h0bL0gwSmGTygB9ukKuBcttwJv8Agifqk3j3/hpuDw/8EPDOvTXPww8S
zIbVdcuZJBdC3+z+HkC3pBhk8mXygo+3vskxctt4+PtM/Yh+KmqfHfxJ8Nf+EQvLTxh4Otbq/wBd
tb65gsrfRrS3jEkt3cXUzpbRW2woVneQROJYtjN5ibl0n9h74q6x8evEXwzHhC7s/GPhC2ub7Xbb
ULq3sbbRrS3jEkt3c3c0iW0NtsKMs7yiJxLFsdvMTcUa9emqd6bfI2tt2/s7b76av0sOpTi1L3t0
vl+P+R9e/wDBE+4n+IcX7TVvoHwR8PeIZn+GHiO5V7Ma7PJKLkWwtvD6iO9w0Ehhl8sAfbn2yYuG
24Dv2a45/ir/AMEgfFFn4Q+GcPxh1mT45nVJPhXaJrGoWXhOyk0VhFqkUWnzx6kqu+61ElzdzRut
so2+arSN8h2H7C/xXvv2gfEvwubwfd2PjXwZBdXmv2uoXVvY22i2tsnmS3dzdzSJbRWwQoVneURO
JYtjt5ibtub/AIJqfGjSj4pfWvCdn4Ts/B2up4Z1PUPE/iDTPD+njUmiM62sF1e3EMFzIYNs2IHk
HkyRS58uSNmzjUrOEIOm2ouS26vdbdNdNfQmcYtt861t/W/XysfqdqP7RPww8P8A/BXLxZ4F8Lah
8RZPjR4o+NGiy33i3w5olprC3/hq2stNebw1K6XFu9jbQXcFyLmSGB5PItQlwbnY4rlv2rPBrr+y
t8d/Anhf4WX/AMb/ABXp/wC1Vq+v3Xg3VNN1hdQsLG+0WN4tUNlpV3HOLZpEljt7ppPLuYmLmNWK
rH+WEv7HXxPh/afb4MHwXrR+J6akdJOgLGrXHngbshgfLMXl/vfODeV5X73f5fz1d1j9iD4l6D4B
+JPia60TTU0r4Q61/wAI/wCLtmv6dJdaNefaVtVVrZZzPJG0zbFmjR4nKSbXIjcrvLHVHGSdJ/FJ
vfS6d07p6q73+4zWGimmp9EvutZ/13P05+BV38Df2PP+Ciuo/Aj4Nj4k6Z8QLz4x6UZvEHhvTovE
C3vhiG3sLq68OTTNdRXFpbw6hHeG6kjjkkEFtsuDc+WwB8V/2aPCsGgftD6v4f8ADHiPxD8Zz+0P
qCal5XwisPG/iSLQ7jT/ALbbMdEvpzFbadLdS3bRX6Ye5VIcqqkRx/lD8Cv2e/F/7SnjK40HwZpI
1S+sdOudXvZJruCxs9NsraMyT3VzdXDxwW8KKOZJXVcsq53MoNT40fBfxV+zt8U9b8E+NtEvfDni
nw5cm11DT7pQJIXwGBBBKujKVdJEJR0dXVmVgTH1/wBxSdL3eZtWbS1vovNX0fkV9XXtNJ62Xa+n
XvZn64/tK6X4a8R/sI/E7wT8I/gHp/ja80f9oldSuvhitxdareeGVl8KWcdxeNbaBqBMERvob2Jd
s7QoTJDsjeEJFo/Gz4D/AAx+GX7KfjL4W/DP4caz+0X4S+Hf7Skur6h8PfD+v3dxqsFpdeDIIiZp
LON7mG2t9S82BZXQszWbwu5cSMfyi/Zd/Y0+KP7afjZ/D/wv8Faz4u1CAbrl7ZVitLEFJHU3FzKV
gg3iKQJ5rrvZdq5YgHzKpnmF/wB57O127PTzutrP4ldarRaIPqybcVPXT9Nd79N9Op+6H7Smgafr
v/BKb4D+Bpvhj4h+N3iP4eeJPD9344+FmlXd3a6/YCbwNHBFJdRWqyXVlGkqoyu0ah3R0IHzFvzY
/wCCs0DaJ8S/hDoF3HeWet+F/g94S0vWNPu4jDcaVeLYLI9vJG2HRwsiMVdVYF8YIwzeUfCH9jL4
h/G74Z3/AI10bS9HsfBunammiSa94g8Rab4e0yW/eJphaRXOoTwRTTiJfMaKJmdEZGYKHUnlfjR8
F/FX7O3xT1vwT420S98OeKfDlybXUNPulAkhfAYEEEq6MpV0kQlHR1dWZWBOWKxM6tH4Gk5N36au
Wjslffq903a7ZdKEYztzXfb+n/V/Q5eiiivNOsKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooA+7f+DaD/lNf8HP+uHiH/1HdTr+suw/49I/93+lfyaf8G0H/Ka/4Of9
cPEP/qO6nX9Zdh/x6R/7v9KALkHU0UQdTRQB8cf8HR3/ACgo+Of/AHAP/Uh0yv5xf+CM3ijT4Pih
8Z/Bcl9ZW3iT4ufCDxD4E8JWt1OtvHq+tXv2b7LZCZ8RRvKY3VDKyIz7U3bnUH+jr/g6O/5QUfHP
/uAf+pDplfyVfBf4L+Kv2ifinongnwTol74j8U+I7kWun6faqDJM+CxJJIVEVQzvI5CIiM7MqqSN
8LUcKsZJX8u5jXgp03GTsj7U/ZF03/hlz/gnD8RvGHxy8N6j8Q/hFf8AxCXwNZfCm5uZ9LmtPF1t
Db3dxqctyU8zTHjsg9sxtw01wWMMqpHGGr6l8V/Dfxp8QPgn+1t4v0jwBrnxV8E/EPQPh9qHw48O
yeHb2zsf7IaeK5g0OG30uVPm0y2uoA6Wk+MxpLJ/rXU/lL4n/ZN8eeEfgXefEy70mxl8B2Pi+bwI
+s2esWV7byaxFbi5eCPyZnaVPJIdZ4w0DgjbI1dt4X/4Jk/GLxd8PrzxVb6R4StNB02z07UL+51L
x1oOm/2bbahBDPYz3KXF5G8EdxHcReW8qqHZigJdWUdtDEzjFU1BtfK+0v7rvpfe9rO1tTCdOPO6
nPb+l5+X4+h+kOo3sH7MP/BNH4h+Cfjn8P7bwB4C+JX7UF3ovizw5pl6nmeCtO1DQ9O1SC4s7ixE
kUjWXl2EyRLA0bpC0Zj/AHgEXk37Zvw68S+Mv+DmnUry3jgu4vBniXw34t13UUC2Nloej2Fjplzc
XlzLLIUhiggQb5HdQzgbQGdI6+Ivj9/wT1+MH7L3gnVfEXjrwiNC0fRPE0fg6+nOq2Vy1vqr6fHq
K2xSGZ3ObSWOTeFMYyVLbwVDbj/gnz8Xrb9o/wAR/CE+ERJ8S/C1hJqV74eh1WylvJo47ZLpktQs
xF5P5DiQQWxkmZQ+EOxsbvGVPdpOk/dkmu+8nZ6d2+nR2WukKjFTdVzWzXl9nXfy/FdjF/bU8f6P
8WP2yPi14p8O3aah4f8AEvjPWNV0y6WB4FubWe+mlikEcgDoGR1O1gGGcEAivM6KK8epNzk5vd6n
dGPKkj78/wCCaXgISf8ABKz9sTXPEXgjxz4m8HXieGLfOgzHT3vXstQN1dJFdvaXMStbRPBcTZjf
ZCcsEEiyL6N4U/a58aftC/smft1ftHT+C9L0iPxVf+DbHT/t3h+DXNDL2t5FbvbOL6GS2ubmO2kt
HkYpkSTpII4/Mj2/A/wi/ZG8d/G3wFqHirRrDRrPwtpeoRaTPrOveIdO8P6c17LG0iWsdxfzwRyz
eWjOY42ZlTDMApBNofsSfFIfFH4ieC38I3cHif4UaVfa54qsJrm3ifTLKy2/aJwzSBZkUOjL5Jfz
FYMm9TmvQo16qhGNODtZrbd2lZ3tfS70v0OeVOm5Sber/LTp52P0A/4Kb/s4/B7QPC3xj+FPhSH4
PfDzx94U+NFt4knl1GGDRLmw8LXnhu3kb7PLLNLcXVsl2ZJPsFkssgZlaK2HmRwp3n7TPwD0bwj8
ffj/AOHvBHwJs4NU0Tx1o0cWteBvhboXj25sNMfw/E6ae3hq8uh9hgeX/SP7RijAuJWmR2DKsa/l
z8I/2ufHfwT8Aal4T0a/0a88LatfR6pPo2veHtO1/T1vI43iW6jgv4Jo4Z/LdkMsaq7LhSSAAOT+
KfxP1741/EnXvF/ijUZNW8R+Jr+bU9SvHRIzcXErl3bagCICxOFUBVGAAAAKqWOpNNqOrlf0XvaX
/wC3uy2Mlhal7OWlrfPTW3y7s+i/2yNH+Fvwb/bO+LHhzxt4Bk1DU9L8TXEKL8MvFlv4f8PWyAR7
o4rS5s9SeGTeJTJCtyUgkdoVRVhAP2f/AME8P2v/AIbfsi/8EkNQ8R+JfhzL4j+DPiz49XWg61oe
sWNp4kv5bUeHba8gQPIbW2nkjvLW2Yl4EVEkdlDOV2fl18G/2e/GH7QI8WHwho51j/hB/Dt34s1v
FzDB9i0y1KCe4/eOu/Z5ifIm5znhTg44ysaWLqUqqrxjbe2itr8tVrsazoRqQ9k32v8AKz+R+32k
/D/Rf2ivjNpnx78VaB4a8T6143ufAQ8baBdaJof9leHdEfwtBql94iu7jVor6VLAAT22YjYbvsZj
FxLMAy/P/j79lGf4C/Az43ad8IPg9pmu/Fnw5+0BeaANKvPBcPjHV9L8IGwlm0xlsb9LsxWsrncl
2IVab5QZ5hhU/Pb9nj9njxj+1b8YtH8A+AdH/t7xbr3nfYLD7XBa+f5MEk8n7yZ0jXEUUjfMwztw
MkgHiq2ljuaClOH2pO/m731turp79tDOnhuV8vNfRaW+7rtoz9O/htH44+CP7HH7fHjPU/hx4C8B
Xh1TwppbaRpmkWut+EbbU01RGvbO3juGvbJpIVuo3kt97m1e4QKkOxFT5a/4LEfCzQ/gt/wUw+Lv
hvw14VXwVodhq6PZ6QiRxwwJLbwzeZEkckiJDKZDLGgKhI5UXy4ceUnjXwQ+AXi79o3xbc6J4O0g
6re2GnXOr30klzDaWmm2VvGZJ7q5uZ3SG3hRRzJK6rllXO5lBx/iN8PtY+EvxC17wr4hszp2v+Gd
RuNJ1O0MiSG1uYJWilj3ISrbXRhlSQccEjmsa9aU6NuVqN9G9esnbZLqr2tte3bWnRUal0/l9y/T
8T9E/wDgmj4B/Z88Hf8ABNmDx78dvBPhrUfDXi74yTeCfEHiLULG/nv9O0638P8A9p20djLaS+db
ym9SNHaGJS8dyyyM6bfJ90+Fn7N3gbxj480j4v23w68BNF4nufBNx4t8F2Phvw/Y+GvCWjTeGItX
1DxBO+pxXrQacWa6gxALAO1qyCeW4ww/F+iqo5gqcYQ5E+V383vo32V9P16TUw0pTc1Lfp06efkf
p14D/ZUh8A+Gv23/AAzp3gj4eaN4h+CvjXS77wEfG+n6TCNJgvNSntP315q48qe0l03yzFFeSyQs
8kU0SmZkkPzN+01rnw81T/grdql18KtJ+HeleA4vHlnFp1rrjI/g+R454UuJZ/Lkkj/smW4WaQiN
ggtpMKqLhF8t+Gn7Yfjz4Q/Anxb8NdBvPD9v4P8AHZLa7a3HhjS7241DCqqbrqe3e4URFQ8QWQCG
QtJHskZmPmFRUxUXFKK63/F6L5PXRbLTQuFGSk3N3v8A5K/5efqdn+0a5k/aF8eMU8GRlvEWoEr4
Qx/wjy/6TJxp2Mj7F/zxwf8AVbK+3f8Agg3Dd+I/D/7SWm6X8J9N8ZX8Hwh8R/8AExWDVp7rVJLh
LVYNDdbe6SLy7gwTlBDGl27GTbNtXav5312PwQ+AXi39o3xfcaH4P0oane2VhcareyTXcFlZ6bZw
Jvmubm5ndILeFBjMkrouWVc7mUGMHWlCupxjzPt3v8v0HWpc1JwvY+6/+CH99J49t/2o7fQfgroO
uXE/wo8TSwy2Ka3cSSG6FsLbw8At4QYJfKm8sKv26Qq4FyQp2p/wRI1M+PI/2oo9E+CHhvXXk+Ff
ia5R7Qa5Ox+0i2+zeH1C3jAwSGGXywo+3OVfFyQpx8YeFv2O/iP4z+O3if4baf4d8zxd4KbUf+Eg
glv7WC00RNPLreTXN5JItrDBEyEGZ5RHkqAxLLlvhX9kL4h+NPjj4l+HOnaAknirwY2of2/FLqNr
BZaKlizLdzXN7JKtrFBGyFTM8ojJKgMS657KGIqx9l+7b5W1tu3023XbX0MZ0Yy5/e+JL8Ou/wDk
fZv/AARR1U+PIf2noND+B/h/Xp7n4YeI5oDYprly8huja/ZvDyhL45t5BDN5YUfb32yYuGCna3/g
ibqieNrf9p2HSvgpoeuvL8LfEk8T2Ca1cSTNci2+y+HsLe4NtIYZSgQfb32SYuWVSB8aeHf2QviJ
4q+OPij4c2Xh7f4s8ENqA8QQy39tDaaIlgzLeS3N48gtooYmQqZXlEZYqAxLqCnhb9kT4h+M/jj4
k+HOn6Aknivwa2oDXopdRtYLLRksCy3c1xeySraxQxshBmeURklQGJZclDE1YKl7j91tbbt9Fpv9
/wCRUqUZKXvb269uu59m/wDBEy8l8fwftOQaF8FtD1yZ/hf4juEewt9avJLj7V9mFt4dAW9I+zym
KXyyg+3ttk23DBTtd/wRH1SfxrB+09D4f+Cega/cS/C3xJKj2UWuXUkwu/sy2/h4BL3HkS+VN5e0
fbn2yYuCFO34u8K/skfELxp8avEvw907w/5ninwZ/aDa/FLfW0FposdiWW7mubuSRbaKGNkKmV5R
GWKgMS6gyeE/2QPiJ43+OfiX4cab4fWXxZ4NOof29FJqFrBZ6KlgXF5Nc3ryLaxQRFGBmeURklQG
JZcujiqtP2V6d+Vtbbt9Nt/LX0CpSUua8t7fh8z7Q/4IkavJ44i/aij8P/BDQNduJ/hb4kliawj1
y6eT7WbVbfw8Al6c28gim8vaPtz7ZMXLBTil+zgj/E7/AIJFeKYPCXwstfi1rMnxxGpz/Da0i1G+
svDVi+iS+Tfxx6fcx6uFLeZbiS6uZYCsIABmErt8d+Hf2QviJ4q+OPij4c2Xh7f4s8ENqA8QQy39
tDaaIlgzLeS3N48gtooYmQqZXlEZYqAxLqDsaX+wT8UtQk8XG40PSdCtfAviCTwprN/r/iTTNF0+
31aPzS9il1eXEUE86iCRikLuQoDdGUmIVans4RdNtLmW29+m3Ttr6A6Ubylzb2/D5/5H6heC/jj8
LPCf/BUXxX8PPBUfxF0D4y+MfjhZSap4k8NaDpeqpq/h6JLCa40d5ra7hNjbm/hvZ7maKFrgwIBe
CaRZkXJ/ah8DyXn7L/x88GeFPhDffGrxdZftQap4gv8Awzf6PqUd9ZWN9oySW+o/Y9JvkuRa+aLh
Le5dvInimDhVZgkf5X6H+y74/wDE/wC0Y/wl03wzf6h8RItWn0R9GtmSaRLqBnWYGRWMYjj8t2eX
d5aojOWCAtW5qn7DnxM0b4Z/EbxfcaJpq6J8Jdb/AOEd8Wldf06S70a9M626o9qs5uHjeZiiTRxt
E5jl2u3lSbd55hNxd6X2pP0undbW0vd+i0IdCz5ufou3fTtufpd+zTqvwV/ZR/4KEan8CfhNYfEr
w78R7z406ekmu6Fp1r4j+2+GLdLG4uNAkuPtyS2Vol7FeSXMqRvOLaFY7oSmOSNZ/wBnbwjd6L/w
UD/4KBeH9K+DUvii9Xwv40vPtmo6Pq1vqWotqMkElvonk2t6YTaXBEr28kMaXdxH+8SWNG2RflH8
C/2ffF37SfjOfQfBukrqd/Zafc6veyTXkFjZ6dZW0Zknurm5uHjgt4UUcySuq5ZVzuZQdSx/ZL8f
337TrfBttEhs/iOurvoP9k32pWlmrXysVEAuJpVgJdhtjIkIlLIELl1yoZi21KFLTmdred/dWluv
5aEVMMnKXNPVxV/l13Wn9XPuL9k668O/Fj/gk81pZ/A+9+MFxo/7QV54i1v4e+FL+/Se20i58NPB
atvga4voLaG5B8uaXeHMJRpHPmV9B/GjwzoOq/8ABOj4deDLj4C+Kfiz4z8A+L/C0/j7wJpV/c2+
tXMb/Du0tbea5jtfNvLFIp/Li/eQoGe0dByzBfy50n9gD4qandeMEuNE0XQrbwH4hk8J61f6/wCK
NK0TTrfVozLvsY7u8uYoJ51EMjFIZHIUBvuspNlP+CdfxXV9XkutL8LaXpuiy2NvPq+p+NNE0/R5
5b2yW+tore/nu0tbmR7V0m2QSuyo6lguRUUcTUjTjH2bdnvZf3tPhfno7rR6as0lCLk2p/j6eZ+m
/wAaPCWj3f8AwTj+G/guX4E+J/in4w8DeL/DVx8QPAGm39zba3d+Z8PbW2tLi4htfMvbJIZQsfzw
xq72zoCS7Gviz9vDUfhL4F+I/g7w/wCPvhZ8Tx4+0L4c+EtP119P8a2eiL9oj8P6eqxzWU+l3csM
8SgROHkQny1/dxkFn8YT/gnj8Vl/teW60rwzpem6LPY2s+r6n4x0XT9HnmvbRb22jt7+e7S1uXe1
dJtsErlY3VmCgivOfjB8INe+BPj658M+JYLCDVra3tbsiy1K21K2lhubaK6gljuLaSSGVHhmicMj
sMOOc5FLFYqo4e9TtaT1aW95aO8d9er0s9LtlxpLn1lr5advM+iP2BbDVJ/2oNc8b/DSYfDj4S+E
9PWTxxqHjm5j8Q6TZ6HN5cNxZaksVvbJqQvJN0cNlHCssrtGEw0RuE+j/wDglprfgz4hfEz9reP4
S/AibUfBs3w38SPog1OXV9R1i4juRapZ6DKbW5WERzvDK8caKb3HmRi8n8ve35t6J8OfEPibwlrm
v6boOs6hoPhkQHWNStrKWW00kTyeXAbiVVKReZJ8ibyNzcDJ4rZ+B37P3i79o/xdc6J4O0j+1LzT
9PuNWvpZbqGys9MsoF3TXV1dTukFvAgIBkmdE3Oi53MoOeFxk4SglC+rfrfTTTT5Lf0VnVoqSd5W
6f8AD+Z9x/8ABE28uPHtt+0/F4e+Dnh/Vp5PhX4klSSzi1q5kuPtZtVt/Dq7b0r5MvlTeUFH26TE
oFw2Btf/AMER5bj4jw/tO22gfBvw/q7v8LfEl1vso9cuZLsXH2b7L4bUJekGCVoZDHtAvn2SYuW2
4Hx5pX7EXxT1b48eIvhoPCF3aeMfCFvc3mu219cwWVto1rboHlu7m7mdLaG2CshFw8oicSxbXbzE
3Lp37D/xU1L4+eJPhl/wiN1a+MfB0Fzd67bXt1b2dro1rboHlu7i8lkW2itQrIVuHlETiWIq7eYm
7SjiK0PZ2pt8rfTdvpt07a+hNSmnze8le3yt8z7E/wCCJV/P8QY/2oIvDvwS8Oa3NL8LvElwhsl1
24klF19mFv4dTZekGCTypfLAH26TbKBctjAh/wCCK+tS+Nrf9p6HQfgl4e1s3Pww8Rz7rKPXrlpF
uTbG28PDZfEfZ5DBIY+Ptr7JMXLbePkOy/Yb+Kt78f8AxL8L28H3dn408GQ3V1r9rfXNvZW2i21s
oeW6ubuaRbaG2ClCLh5RE4li2u3mJuLL9hv4q3vx/wDEvwvbwfd2fjTwZDdXWv2t9c29lbaLbWyh
5bq5u5pFtobYKUIuHlETiWLa7eYm4oYmpH2X7tvlb+bfTbddtfQUqcG5e9vb8Pn/AJH13/wRV1f/
AITj/hpqHRvgvoesPdfDDxJJCNPj125a5a7Nt9l8OYS+5t5DBL5YAN85WTFw+35T/gilqUnjqH9p
m10L4M6LrMt18MfEcqNp8GuXcl2bn7Mbbw5hL3H2eUwSlNo+3PskxcMF+X5Esv2GvireftB+JPha
/hC5sPGvg6G6utdtNQu7exttHtraPzJbq4u5pEtorYIVZZ3lETiSLY7eYm6PTP2Jvijqfx68QfDP
/hErqz8ZeEoLm71u1v7q3sbbR7a3TzJbq4u5pEtorYIVYTvKInEkZV28xN1UcRWh7Jeyb5G+m7fT
bddtfQqVOMlK0t7f8OfX/wDwROv7nx1H+05DoHwX8P660/wu8Ryf6IutztP9qNr9l8PLsveYZGhk
8oKPt0hWQC4bb8s37N9vN8Sv+CNPiOHwr8OdO+MOryfHd9Qk+FtrFqV7B4Vsm0I+XqqR6fcR6qI3
bfaq91dSwEWxAXzRJI3yBpP7C/xX1j4/+JPhgvg+7tfGfg22ur7XrW9ureytdGtLaPzZry4vJpFt
orUIUZbh5RE4li2O3mJu3bv/AIJnfGvQ7zxTHrvg+28HQeDdbHhvVL7xVr2m+HdOXUjD9oW1hu76
4hguZDAVnAgeTMMkUo/dyIzZqtVUIQdN+65J6bt9Nunb8CZxptyTktbP7uu/46H6kaz+0b8ONI/4
KzeLPA3g/V/iLc/G3xn8ZNGfUvF3hrR7PVIdU8NW9npUkvhyWSO5t5LK3gvILv7VJFE0ghtFS4a5
KuV4AfBv4geDNK/4KP6h4I+H/jDxHeav420b+w4tY8CR6lFqk/8AbLX11EljPHcQXix213HOrbWP
kS29yY4vMTZ+ZP8Awx58Tv8Ahp3/AIUz/wAIXrX/AAs/+0v7K/sDyx9o8/G7O7OzyvL/AHvnbvK8
r95v8v5qv65+w98TPDnw9+Ivie80PT4tK+EuuHw74uUa9p73miXouEtgslos5uGjaZ/LWZI2idkk
CufLk29FXHVJxcXSatKT0bVtG2tt1e7fZaoSw8VopdF+FvzP1C8A/Dvwp4M/4KFftw+CfhJ8H/Ce
u6Fpvw81qOK40xdTumuLu5sLAyeHRHa3K28Ky3kV4Ft4IY7tJFlhjkRYhHH8wfs4/DlPFv8AwS18
Q+OPg/8AC/wx4q+N1x8ZW0/U9ItPCcHjW60bwy+lCe1SOxvkvXt7UXnnItyyb5iojeaUx7R8a/A7
4A+Lf2j/ABjPoXg/S01K+s7C51W8knvILGz06zt4zJNc3N1cPHBbwoo5kldV3Mq53MoO0P2O/iPF
+1EvwYuvDv8AZfxKfUhpKaPqV/a2AluWXdEizzSJAwlBQwsJCs3mR+WX8xN2M8XOraUKdlzStbvL
ZJ20a6b97IpU1FcrlrZb+XV+p9wf8EoPhP45b/gvZp+p33wy0fwtP4S1PU/+En0zwdF9q8PeFrqb
SL5BAZYpbmG13zhl8oyhY5d8SiPy/LTlfgv+zPr3w+/4Jga9d+FPhE2t/tJ6b8W00zxDpOp+CIPE
mtaR4abRI7i0aXS7yCdrOGS6klK3Agj84/L5jiNVX4+8OfsrfEHxf+0q3wf0rwvf6l8SE1qfw++i
WzRyyJeQSOk6GRWMQSMxyF5S/lokbOzBFLDZ1T9hv4m6P8N/iP4suND01dH+EWsnQPF+zX9OkvNE
u/tMdqA9qs5uGjaeQRpMkbROyybXbypNqWIagv3b0lJ3v3S02smrX+/Ts+WKk3zLVR/N269b2/zP
vLVfC/ijWf8Agnb8QPC8fwa8I+OvG2mfHuW91r4SeF2uNT0jwaX8Pxq+pQR6Pefb4TJKskLrLdPZ
xvbmKOGJ4pVX5l/4Lm31jf8A/BVr4wNp3iQ+KrWG/s7cXxkt5PLePT7WOS1zAiJ/ozq1tgjzB5GJ
GeQO7fOfwa+DXin9oX4oaL4L8FaHf+I/FHiG4FtYafZpuknfBZiScKiKqs7uxCIiMzFVUkUfiF4C
1b4V+Ptc8L69afYNd8N6hPpeo23mpL9nuYJGilj3oWRtrqwypKnGQSOaivinUw/KoNLm39OZ22Wv
vf5JXLVNe05r9NvW2v4GPRRRXmG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQB92/8G0H/ACmv+Dn/AFw8Q/8AqO6nX9Zdh/x6R/7v9K/k0/4NoP8AlNf8HP8Arh4h
/wDUd1Ov6y7D/j0j/wB3+lAFyDqaKIOpooA+OP8Ag6O/5QUfHP8A7gH/AKkOmV/OH/wRq8S2a/Fb
4xeCjqFlZ+I/i58IvEXgbwrb3c6W8eraxeLAbWyEshWKN5jEyIZHRS5RdxZlVv6PP+Do7/lBR8c/
+4B/6kOmV/JR8Gvg14o/aE+KGi+C/Bei3niHxP4huBbWFhbAb5WwWZizEKkaIrO8jlUjRGdmVVJH
RhakqdaMoq77d76f8MZVoKUHFux9p/skWQ/Za/4J2fErxT8cNAn+Ifwrn+IUfgiH4RXl3Ppl3YeL
IIYbqbVZZsCbS2js45bbfbhpbht0MyrHGDX1DeeDPEHjn4Qfth+JfDXgKf40+G/iHoXw71Hwf4XX
w9e2qadpjyR3Vpob2ukTRGOWwsJbVylrMcotvM/yzOh/KjxL+yr458J/BS++I11pVlL4H07xbL4G
l1iz1eyvbZ9XjgNw0EZhlcyp5I3rPGGhYEbZDkV2vhT/AIJq/F/xh4L1DxFBo3hex0XSLLTdRv7v
VvGuh6UllbajbQXNjPL9qvIzHHPHcxbGYAM++P8A1kciL10sRUUFR9nf5a7S8td7632drXZz1KcH
Jyclf/hn38vxV9kfozL4h8O/s/f8E2fiH4Q+MXg/S/CHgr4j/tQ32h+L/DWjarb3D+AdMvtGsNRg
uLK509HjaSykhtnEQieOQWTw+SjFwvkX7S3gG/8AGn/BytqN94f1OfxLpXgnxhofivXtbuZ7VLbQ
dM0+DT7i+nuZwIoIoLNUeLdIQf3SKzSStl/i/wCPn/BP74ufsweD9V1/xz4UTRNJ0TxKnhC8nGrW
N15WqPYR6gtuFhmdmBtZY5PMUGMbtpbdlabdfsC/Fmz/AGhvEfwnbwtG3xG8LafJqd7oMerWMl1N
Elulyy2oWYreTeQ4kEFsZJWUNtQ7Gxv9dquMKLpt2kmu+8nbbu3bTvZa6CoJNz5ulvLprb5d+pk/
tqfETSPi9+2R8WvFnh+8fUdB8UeM9Y1fTbpomha5tri+mlikKMqspZHU7WUEZwQDxXmdFFeRUm5y
c31OuMVFKK6H2b+xLc/FL4i/sV6/4FHwXuvj58D08Ytqd1ovhy/aLxR4Z16bSpbeLUYFszLdRRtE
ExJeWdxZO1o0agSeZX0V+yP4f079jL9tD9rb4C+A9f8AC3jaw034beJz4Pkn8M6Pqmta7qz2llIu
kNMbeSW9MSpNFLZAmB5LWdzbqS6j8/8A4F/sT/EL9o74c+IvF3hWz8MyeG/CMsUOtX+q+LdI0aPS
zMypC03225hKJI7hEcja7hlUllYDjPjB8IPEvwB+J2teDfGOj3Wg+JvD1y1pf2NxtLQuMEEMpKuj
KVZJELI6MrKzKwJ76GJdKMJuD0e+2mt0nbr5329Ucs6EZylHm36fdvv+SP0t/wCCcH7FEfhW68U+
NPiNpHgjxb4itPixa+GvHvhO1tPCVxpfgHSI7STUr3W76WazvLezsAPtEHk2psgHtJYVmEsaRx8/
oP7OkPw3+B37dVz4X+GGg6pZ/An4gxzeAtS1Dwdba4+nRrqc9nfQtPcwy/bLePTDFK8N0ZoocLch
EkPnV+Z1FSsbFQUIx2bd766q3b0+aurDeGbm5c29tLdv6f39T9D/APgkt+07q3jb4n/tKabpPhn4
caTqPjT4aeLtY8P+G9L8G6bcNe6rKttImmWaTxyXNxahIXdNO3ywBYnbySA5r4i/aE8CeJPhn8bf
E+ieMLXRLDxTZ38h1W00iWweytLhz5kkMYsSbWPYzFTDFhYWUx7UKFF42uy+Dv7P3i/4/wD/AAlX
/CI6O+sf8IT4eu/FetbbiGH7Dplrs+0XB8x13hPMT5U3Oc8KeazlXlVpQoJNuN/x127+ZrGnGEnP
0/q59Lf8EFPhrZfF3/gpl4M8Pa34S0fxj4U1Cz1Aa7aaroFvrFpBbraSNFM6zxusOLsWqiUbTlxH
kiRke7+x/wCGT4Q/4J5ftRaxrXgzww3jT4Kax4cv9Gl1/wAIWF5eaPe3t9Lpt7BcC6gdpozCCotL
kPFHKplREmXefiqu+8HfsxeNPH/wF8X/ABM0fTbK98G+ApraDX7pdWs1udNNzLHDAzWjSi5ZJJJF
VXWMoSH5+R9rpYpxhGCjdx5nf1il/wCS2b/y3JqU7tyb3t+D/W9j9W/gx8G9D+HP/BQb9vHwV8MP
hXoPiPQtL+HWvRQTaV/aN4J7m6tLOT/hHALO4igjSa4jugLeGJbpGt5IkkCxMo+XP2bvhw/iD/gl
/wCKfiF8I/hn4T8VfGG7+MK6Vf6PbeFYPGt1oPhxtJkuLdUsL+G8e2tTdGVFumzJMYdjSExHd8d/
s/fs/eLv2pfi/o/gLwHpH9u+LNfaVbCx+1Q2vnmOF5n/AHkzpGuI43b5mGcYGSQK42uirjudRk4W
inLbTV66O32brv02M4Ydq8ZSu/dvp2+fWx9fftx/Dzwh8Nv+C0Wv+HvAlr8NNL8MWfjrTkt7XWbt
J/CdlK72zXEV8Y1VIrNJ2lWeFBtgRZYhkRg185ftDqE/aA8cgN4OcDxDfgN4Sz/wj5/0mTnT88/Y
/wDnj/0z2Vx1FcdfEKo5WVk23btfodFOnypK+ysFFFFcxoFfod/wQdhuNd8O/tL2Fj8LLDxlcxfC
HX0+3LBqs9zqs1wLVLbQnW2uFi8u4eKRlEUaXbNG+yYKpUfnjXZ/Av8AZ78YftJ+LbzRPBmjnVrz
TdNudZv5JLmGztNMsbaMyT3VzczukFvCgwDJK6ruZFBLOoPXgarp14zUeby7/g/yMMTTU6bi3bzP
t3/giU9x48n/AGnxoXwh0bWTP8K/ELxpaR61cLO1ybf7N4eHl3R3RT+VKIxkXrmM7bglTVj/AIIh
X1x42T9qNNB+C+j6+0/wp8RsgsF1ydpjdNai28Pjy7s7oJTDLsUYvZAkmLg7Tj4+0n9h34q6t8fP
Efwy/wCEPvLHxn4Ot7q91601G5gsLfRbW2TzJbq5up5EtobYKUIneQRP5sW1m8xNztG/YZ+K+t/H
3xJ8MV8HXtn408HW11fa9aahcQWFvolrbR+ZNd3N1O6W0NsEKsJ3kETiSLazeYm7toY2cVS/d35X
L5t9tOl/P5GVWnCSneS1t8rfM+vv+CJmp3HjgftQx+H/AIJ6BrzXfwu8ROq2UOu3Zk+1G2+zeHlE
d4f3MhhkMf8Ay+v5T7bk7eJf+CIerHxpF+1SNG+DGi6yZ/hR4kmj/s9dcuGkN01sLbw8Nl6c20vl
SlAP9NcRyYuG2nHx1pP7DvxV1b4+eI/hl/wh95Y+M/B1vdXuvWmo3MFhb6La2yeZLdXN1PIltDbB
ShE7yCJ/Ni2s3mJuTTP2IPipqfx68R/DI+D72y8ZeD4Lm81601C4gsbfRba3QPLdXN1M6W8NsFZC
J3kETCWLa7eYm5UMXNKklTvyt/8Ab1+i03XzFUoQlzLm3t+HzPsD/gidrf8AwmMX7UkejfBjQtZe
7+FniOSEWMet3JlNy1sbfw8Nt4wNvIIZimP9Ofyn23Py8M/4IlSTfEM/tPQaF8GdB12Wb4WeI54/
sket3DSm4Nsbfw+vl3bZhm8iURgYvX2yYuTtwPj/AEz9if4pap8c/Efw3HhC9tPF/g+2ub7XbW9n
gs7fRrW3QSS3dzdTOtvFbBGQid5BE4li2s3mJudpP7EnxT1j47+IvhqvhC8tPGHhG3ub3Xba/uIL
G20a1t0Dy3dzdzOltDbBWQid5BE4li2u3mJuKGLqwVLlp35W+m7fRadPn8ip0Y++1K17fK3zPr//
AIIpX83jxP2o00H4M6FrLXHwt8QyRrYrrdwZjdSWn2bw8oS8O6CUwyCMD/TX2SYuW28J+zib34m/
8EfPFMHhb4X6T8XLo/HP+03+Glp/ad9D4WtZNFZU1FIdPnj1VYmb/RVlu7yaBvJ2hPOEkj/IWjfs
QfFTXPjt4k+Gsfg+9tvGPg60utQ161vbiCyt9GtLaPzZru5upnS3itghVhO8gicSRbGbzE3bc3/B
N/4y6UfFba14TtfCVt4K1tPDerXnijXtO8P2cepPE0y2sNxfXEMVzIYV87EDSfunjk+5IjNNOvUc
KdNU27c2y3vv06fP0CdOF3eW9v636n6g2X7TXgrw9/wVr8a+CNOu/GsHxo8VfGvS3vfF/hK2tfEc
Wq+ErSGwceHp5kltXsoI5LeR7x4YZJEjtmiuGu/KZ24bRPhB8T/Dlj/wUqvvDPw41zXtfvviDp0W
g2Vx4HGu2mqP/wAJBPcyiOzuIJoZytldQ3ABjfZHPDMNuY3P5mxfsifEuf8AaXX4Op4N1lviW+oj
S10ERr55mI3Z3Z2eV5f7zzt3leV+83+X81XNS/Yt+JOkeBviP4jn0G1XS/hFqw0TxeV1ixe40S6N
ytqqvAsxmZGnby1lRGjYq+GOx8aSzCdRPmg3rJ3vrqn5bq7bf4Gf1RRd1Lol9zX57WP1D+Bnw/0X
wt/wUC/bm8IfDT4LeCNS0jR/h74kii/4R291jV4b6S5tbIJ4fJtZ4oY1nniuW+zQxR3MM3nwRzst
ugHl3/BJfwRp3iP4E+DPHHw9+G/hXUviVL+0lpFp4iNlpS+I77wr4RNvFOrJb3aXU2nWkdwZtmog
rMzRFWnZoRj87Pgd+z94u/aP8XXOieDtI/tS80/T7jVr6WW6hsrPTLKBd011dXU7pBbwICAZJnRN
zoudzKDR+MHwf8TfAH4na14M8ZaLe+HvE/h25a01CwulAkgkGCOQSrIykMrqSrqyspKsCZePleFV
0/dTk+i31smktvn6FfV01KDlukvu+fX+rn66fGXw1caj8EfjD4W1f4J6z8abzRP2vPEXijW/h9pN
5e22tXWmX2hzLY3rraRtdwWbOyzQ3Ozy59pUHGc7HxtS68Vf8E2fhr8P9Y+CF98Xda+HHi/wzL4l
+HmiX15D4jaBvh3a20c+oQ2iveWAiu8qu+MCRrZl4+bP5NfCj9kXx58Zvh1f+MNI07SLLwnpuoJp
Euta94g07QNPkvXjMotYp76eGOacRje0cTM6IVZgAyk7tl/wT6+Ktzp+r39xouhaRo2i3ltp82s6
x4q0nS9Iubi4tBewxW19c3Mdtds9qyTgW8kn7uWJ/uyIW1hiarjFxpN6tp2vde9/d1tfzWj01Yvq
0Fu1pb8Lef8AwdtT9SPjVoreIf8Agmj8MfA+ofBS/wDi7q3gHxd4auvFPw80LVbiLxJPG/w8traK
4v7azjku9OSG6VkHmIvmm2IIG8mviT9uy6+G/wAOviR4N8O/FH4X/ECTxnoXw68I2V22i+OLPRJE
C6BYZivbOfSrqWG7jk8yNg7ofKSAeWMb5PGP+HdfxZgtdWvLzRfD+kaPo91a2Mmtar4u0fTtGup7
mzF7BFa3890lrdu9qyTYt5ZCI5I2OA658z+Kvwp134K+NZvD/iK1t7XU4YLe6xb3sF7BNDcQJPBL
FPA7xSxyRSRurxuykMMGscXiKjhrT5VzN3aXeWl+VX/SzsldlQoR5tJfd/wGfSX/AAT2ttWP7VOt
+N/hncn4bfCPwrpyv47v/HN1H4g0m20Gby4rqx1JIoLVNTF5IGjhsY4klmdo1QhojcJ9C/8ABLfx
J4L8d/En9rhfhV8DJbvwZcfDjxLJoianc6vqGrXEVyLYWfh+ZrW5SExTNBLIiIn2zCyKLuYx7z+b
2ifDvxB4l8J63r2m6FrOoaF4ZEDaxqNtZSS2mlCeTy4TcSqpSLzJPkTeRubgZPFbPwR+AXi79ovx
Xd6N4P0g6pd6dp1xq9/LJcw2dppllAu6a6ubmd0ht4UGAZJXVdzoudzKDGDxk4Tgow5tW7dXdWst
Hb5Lf0VrnQjK932X9eZ9w/8ABFfWJPGem/tQQaJ8GPD+sPcfC7xFKJbNNduJJftRtRbeHh5d4V8i
RoZDHx9tcpIBcNtwF/4Ioai3jqL9pu30X4L6Lrs1x8L/ABHLF/Z412eS6a5Nqbbw9iO7YNbyeRMY
1AF6+2TFydo2/INl+xF8VL348eJfho3g++s/GXgy3urzX7S+ngsoNFtbZA8t1c3Uzrbw2wUoRO8g
icSxbWbzE3NsP2Kfijf/AB28RfDU+Eruz8Y+Ebe5vNctb64gs7fSLW3j8yW6uLqV1t4rYIVYTtII
nEke1m8xN2+HxNWHsrUm+Vy6bt9Nt1219EEqUZKVnvb+tz7F/wCCJN5L8QLL9qG20H4LaBrc03wt
8RTo9kmu3Elx9pa0+zeHQI7xgYJTDL5YAF6+2TFyQvDv+CJmsS+Nrb9qOPQPgt4f1iW4+F3iKVDY
pr1w9x9re0W28OL5d8QYJTFKYwB9uk2SAXDAcfHVl+xF8VL348eJfho3g++s/GXgy3urzX7S+ngs
oNFtbZA8t1c3Uzrbw2wUoRO8gicSxbWbzE3LafsP/FW6+P8A4l+GDeD7208a+DILu716zvbiC0t9
GtrWPzJrq4upXW3itgm1hO0gicSRlXbzE3TQxNWHsv3bfK5dN291tuvn6EToxlze9vZ/dbz9D7B/
4Ipa7/wmNp+1Eui/BfQdWkm+F3iOaJ7Aa9OZvtbWq2/hz93ekG2kEU3ljH21yj4uW24Cf8EVtYXx
xYftSRaR8G9A1J7j4W+I5oXsE1u5edrprUWvhwBb0g28hhlaMAfbn8uTFw4UgfH9n+xB8Vbv48+J
fhm/g6/svGXgy3ub3X7S/nhsoNFtbdBJLdXN1M628NsEZCs7yCJxLFtZvMTcmlfsRfFPVvjx4i+G
g8IXdp4x8IW9zea7bX1zBZW2jWtugeW7ubuZ0tobYKyEXDyiJxLFtdvMTc6GIq0/ZXpN8jktt2+m
267a+g5UYPmfNvbr2sfYP/BFPUJPiBb/ALUMPh/4N6LqlxcfC3xJLAdNGuXElwbtrQW/hwBL1g1v
IIZzGoH219kn+kNs+U/Zvt734n/8EcfEdv4T+Gem/F+/X46tqk3wytF1K+i8L2b6GRHqaw6fNHqq
xM262WW6vJYG+z4CeaJZH+PLD9in4o3/AMdvEXw1PhK7s/GPhG3ubzXLW+uILO30i1t4/Mluri6l
dbeK2CFWE7SCJxJHtZvMTdvL/wAE4PjJaXPihdX8K2XhO38Hayvh7VL7xT4g03w9p6ai0RnW1iur
64hguJDABMFgd8xPHJ9yRGbONWt7OEXTdouS23v026dtfQc6cdW5Wvb8PmfqZqX7SfgfSf8AgrX4
w8BeHb74hP8AG3xh8YdIOseLfCuj2WsHUPDVpZ6ZJL4beSK5gayt4Lu2uftU0UTy+TaBbk3OyQVw
998HfiT4Ok/4KTaj4N8AeKvEGpar440ptJttU8Bx6rBqk51pry7jjsriK4hu44re9inRtjN5M1rc
lIt6bfzB/wCGQ/iX/wANLf8ACnv+EO1j/hZX9of2Z/YWxfO83bv3bs+X5Pl/vfP3eV5X73f5fz1y
PxG+H2sfCX4ha94V8Q2Z07X/AAzqNxpOp2hkSQ2tzBK0Use5CVba6MMqSDjgkc1tiMfOSbqU2vel
rdrV3utVur/8AzjhUpXTWyW3a3nt0P2D+F/w78I+Ff8AgoR+2/4Q+FHwZ8P63oWi/DjWkibQ11a6
Nze3Njp4k8OsltdiGGGW8ivf3EEaXSOs0UcqpEqR+Wf8EmvhvpHi/wDZ+8DeOPh74A8LX3xRl/aY
0mz8RCy0keIr3wn4QNtDPHIkF0LmWws47g3G2/3JKWhw07GIFfgH4TfshePfjT8Pb3xdo+maVZeE
rDU49Fk1zXte0/QNMe+eJpRaR3N/PDFLOIlMjRozMiFWYAMpPT3f/BN74yaJqXim31zwrZ+EU8Ga
0vhzVLvxRr+m+H7FNRaPzhbQ3V7cQwXEhh2zAQPJ+6kjk/1ciMzeNqTlCpGlonJq3m27J26a/wCW
g5UlZw59bL8O+vU/RL4B/FTw18Iv+Clvj74XW+i/E7wT8dPGv7RNzqOpeINE8Opevq3g0XsN7Fpj
tJdQS2dlKyPeT3MEJD2oQuJohsEc3wW+JXhFP+Cjt34G8BeLfFeo6r430hdLh1jwEmprqtyNZa8v
I47GZbqC7WKK8imVirkwTW1yUi8xNv56XH/BNT406Re+Kotb8JWnhCDwZrY8N6pfeKdf03w9pyak
YjOLSG7vriGC5lMG2YLA8mYpI5B8kiMy6h/wTX+MOi2l/e6loGgaNolhNaW413U/F2jWGhX8t1Zr
ewR2mozXS2l47WzpKVt5ZCquu4LuGR4uq4cnsn8Tel76p6bbrf5bExpx5rqa2X4ddz9OPAvxB+A/
wB/4KZ6z8JPg/pPivwZ8Sdf+MGi3F7q3gXSYdZ0258ORWemXV9oDyNfRyafbLqcd/NeeREViigMT
rJFF5Mf5mf8ABUvwong3/go18a7SOHXoI5/F+oX6prGnCwucXMzXAIjDuGhPm5ilDDzojHLtTzNi
1Z/+CcvxbsI9Sub7RfDuk6RplzZ2T63qfi/RrDRLue7tFvbeO21Ga6S0uma1dJsQSyFUdGbaGGfO
PjJ8FvEfwC8bv4e8UWVtZ6kLW2voza39vf2t1b3EKTwTw3Nu8kM0bxurB43ZTnGcggY43EVKlJxl
TcVzt+Svf3dt1r92xpRoqNTmUr3S/DqcrRRRXknWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAfdv/AAbQf8pr/g5/1w8Q/wDqO6nX9Zdh/wAekf8Au/0r+TT/AINo
P+U1/wAHP+uHiH/1HdTr+suw/wCPSP8A3f6UAXIOpoog6migD44/4Ojv+UFHxz/7gH/qQ6ZX84P/
AARv1zTZvif8ZfBU19Z23iT4s/CPX/BPhK1urhbaPV9buzbG1shK7JFG8pidUMrqrPsUEuyK39H3
/B0d/wAoKPjn/wBwD/1IdMr+Sr4L/BfxV+0T8U9E8E+CdEvfEfinxHci10/T7VQZJnwWJJJCoiqG
d5HIRERnZlVSR0YWrKnWjOKu+xlWipQabt5n2d+yNYn9ln/gnl8T/FHxy8I6n8QPhRd/ECDwTbfC
+8ln0maz8XW0cV1PqEl0VEunSRWKzWzfZw0sxlEc6IiIx+ifDfwb1rUvgx+2n4h8J/C/XPi34S+I
8PgTXfBugX3h/U4YpbO4eHUIdJjj06VJCdMsb60QxWlwIo44YMgRlY6/MTxH+yn478LfAu7+Jl1p
FrJ4DsvFsvgZ9atNVs7u2k1iK3+0vbxmKVjKvkkOJow0LAja5yK7nwv/AMExfjN4t8B3/ieLQfDW
n6Dpdhpmq3t5q/jTRNJS0tNSghnsbiQXV3GUinWeNUcgKZBJFnzI5EXuo4qpGKpuDdr276qS6p3W
u22jta7OapTjdyc0r/8AA8/T7z9DLLXdI/Zz/wCCeXxR8K/Gn4ZHwD4B+J/7TFz4c8VeH7W6lSTw
Jpt5pNrqUM1jPaq0Ur2TR2U6IkEkc0duEaPEse3yD48/DLUvGn/ByRq17pcGoano3g7xvpPjLxFq
F80trBo2j2Ysrq9vbma7kxBbRRg4dnSIgxLCFV4o6+QP2hf+Cdnxk/ZU8Gat4h8feDJPD+j6H4nj
8G3tw2p2dwItVfT4tSW2CwzOzZtJopd6gx4cLu3fLTLz/gnr8YLH9pDxF8IH8Hs3xM8L6fJqd54d
j1OykvZoktkuytqqzEXkxt3WQQWxklZQxVDsbFSxU5csXTfuyVu+8nbbq/LdOy10SpU03NT3XfTZ
a7+nXsYX7Z/j/Sfix+2H8WPFOg3g1HQvEvjLV9V067EcsYurae9mlik2ygSLuR1OHAYZ5AOa80oo
ryZy5pOXc7oqysffX/BNX4bS6p/wSt/bC1rW/AvjfxR4OceGDIdCl+wSXRsb97i7WK7e0uY1NvDN
DcTDy22QkM4UMrj2j9i7VvDP7avxL8cftI+KvDej+J7rxZ8VbGy8T+D7iLSNQsfAvhqGykupta1G
91mzvJEszEkkO2BrEM1syRyIfs8UX57/AAO/Yi+IX7RXww1/xn4XtvCj+GfCtzFa6xe6r4x0bRV0
x5SoiaZb26hdI5GcIkhXY7h0ViyMBxvxo+C/ir9nb4p634J8baJe+HPFPhy5NrqGn3SgSQvgMCCC
VdGUq6SISjo6urMrAn0aOJnS9nUlB8sdO173628336nLOlGblBy1f3208/8AI++fG/we+GfwG8Af
HHwRo+lfCDQPiLoPxwura9s/iAoDW3gBbS4Nu1o94WupInLbt2lE6m6mFkMjNbkfQHx6/Y88BeCl
+PEPgXwhYXfj3Tfi5Z2r6f4F+Den+Or/AEfQJvD8N1aoNJvroxWlq1xLchrqAr5s0GNoQxxw/lP8
Jf2tvHXwU8CX/hXRtQ0e88LalqMWrzaLrvh/Ttf04XscbxLdJb38E0Uc3lyMhkRVZlwrEhQBPoXw
9+JX7cnxE+JPiuytD4o1/TNL1P4g+LLrzrWy8m0ikEl5dhGaNCFaZSIoVzhsImBgaUsdFJRhC7u9
NdF72zv59ugp0pK7crLv93f0Nz/go/oWj+Gv26fifY6F4ctvB+mQa5KI9CgjtYl0dyFMlsUtbu7t
0eOQurJFNsVlZVjgA8iP6J/4IafF7VdD1L4++DtKtfDF9q2v/CDxNJ4e0648OadqGqa9q3lWxisY
TNC092jJG7mwzJDII3YwsQSPgqiuKjifZ1/bJdX+P9djWrR56Xs5H6l/8E5P2PLTwV4h8U+Jfibo
PhHxV4r0/wCLFpoHj3wpDZ+EpNG8BaPFay39/rF/NNZ3kFrZDM1uYLRrEK9rJCJhKsccWj8J/wBm
Hx58A/hV/wAFDPDfw6+FXiDUBp/jHRtE8KaZN4TfX7a6t7fWpZhElrdw3C3eywntpxvEjLHLDMSS
Ukr82Pgv+zx4x/aF/wCEs/4Q/R/7X/4Qfw5eeLdb/wBLgt/sWl2mz7RcfvXXfs8xPkTc5z8qnBri
q61jlCELQatzWd+6afTz/wCAjL2F5tqXbT01XU/Uz9mj4V+FfhX/AMHRUPhfwifDh8NWHiDVEgg0
KBrexs2fQ7l5rZY2lk8t4ZWkikVWVVkjkCRwqFiTiv2Gf2bdPj/4J8eM7u18HarffGvR/ikfD+u6
dp3wosfiH4m0fTI9MYxxzaTqMirZQG8FyrXKqknmwiNi+AI/zor0Hwh+y5428e/s/eLfihpGm6fe
+C/Alxb22vXK6xZLdaa1xLFFAz2bTC6MckkqqsixFGIkAb93JtIY9OV1T6zlo3opJbW2tbf/ACKl
SaWsuiWvf/gn6GX/AMLdEbxN8eoPB/wKl0nVLD4mQLLfeGPh/wCHPiTqXh61axkZ9Gm0CbU7iKwi
W53sby2bynlWW3xB5K2sfyj+0v8ADOD4Xf8ABWvVfDFufghDFpvj20tyIVmg8BwsbiEst1FLLM1v
aKzEXUAkZYMTxodiKB8wUVz1sXGaty9b+XpZJI0jSad7nZ/tHoI/2h/Hqj/hDCF8RagB/wAIeSfD
v/HzJ/yDieTZf88f+mWyuMoorklLmbZrFWVgr9EP+CD8Vz4k8LftLaVpvwp03xhex/CHxEDqSW+r
3N7qslwtqltobJb3KwiOd4ZHQRRLdsVl2TBVwv5312XwO/Z+8XftH+LrnRPB2kf2peafp9xq19LL
dQ2VnpllAu6a6urqd0gt4EBAMkzom50XO5lB6MFVlTrxnGPM+3f8H+RliKanTcW7H3N/wRI1E+PD
+1FFovwY0HW2uvhZ4jliSwj1y5e4a5Nt9l8OoEveYJDDIyAZvnEUmLg7Thn/AARQu5fiEn7UcGg/
B3QdVkuvhZ4jmiWxi1y6e4Nybb7N4cQJeHMMhikaMAG9fyXxcEK2PkCx/Yh+Kd78fvEXwwbwlc2f
jPwjDc3euWt9d29lbaRbW6eZLd3F3NIttFahCjLcNKInEkZV28xNxY/sQ/FS8+P3iL4YP4QvLDxp
4RhubrXbTUbmCxt9GtrdPMlurm6mdLaG2CFWE7yCJxJGVdvMTd30K9em6b9k3ytrbdvpto18zGVG
Lcmpb2fpbrufXn/BFS6uPiC37T0fh/4N6LrDT/C/xFMkenwa5dm5+0va/ZvDo2XhPkSGGQx4/wBN
fy3AuDjiT/gihezfEC3/AGpotA+C+h61Jc/CzxFLGLCLXLp5TdPai28PIEvTmCQxSGPg3r+U+Lhg
px8g2f7DXxWu/wBoDxL8L38H3ll408GQ3N3r9rf3NvZW2i21ugeW7ubuaRbaG1CsjLcPKInEsRV2
8xNxZ/sNfFa7/aA8S/C9/B95ZeNPBkNzd6/a39zb2VtottboHlu7m7mkW2htQrIy3DyiJxLEVdvM
TcqOIr01TtTfutrbdvptuuwThGV/e3s/ut5n19/wRR1d/HEH7UMOh/BXw/rUl18L/EUsf2GLXrpp
zdPai18OL5d6R5EhhkMfH21zG4Fy2OE/4In6gPHX/DUI0n4N6Hqwl+FniS4jFguuT+e1z9nFr4d+
S9x9nlaKQxj/AI/pDEwW4YjFfIFn+xB8Vbv48+Jfhm/g6/svGXgy3ub3X7S/nhsoNFtbdBJLdXN1
M628NsEZCs7yCJxLFtZvMTcyx/Yn+KN78d/EXw0bwjeWfjHwjb3N7rlrfXEFlb6Ra28fmy3VxdTO
tvFbBCjLO0gicSR7WbzE3VQr14ez/dN8rktt2+m2jXzY5UYy5rS3t/W59f8A/BFK/Pjq1/aeh0b4
M6TrLyfC7xHcI+nR63ctObg232bw6wS9wbWXyZSmB9uYo+LhtuA79mrT9T+Kv/BHrxNb+Evhxpfx
hvG+On9ot8LLK21O+Hha2fRSF1RU0+4j1QQyH/RFe6uJYSLdto87zJG+QtP/AGHfitf/AB88SfDF
vB17Y+M/B0Fzea9aahcQWNvotrboHlu7m6mdLaG2CshE7yCJxLFtdvMTdvXH/BNT406Re+Kotb8J
WnhCDwZrY8N6pfeKdf03w9pyakYjOLSG7vriGC5lMG2YLA8mYpI5B8kiM2arVlThB037rktur6bb
rs7+gpxhd+/a9n93zP1Cvv2h/BGg/wDBYHxn4F0PWfHF38XvGnxi0RtS8VeF/D1nqf27w3a22nTS
+HZZIruF7OCG6glF1JDC0wiscXBuCJEXhZfhB8RtCb/gpBf+Cfh94r8T6rq3jrSG0m21T4frqiaj
ctrUl5cxpYTJcw3CxwXaSqzK5MMtvPsi8xdv5nH9jX4o/wDDUTfBYeCdab4oLqR0o+H1jVrjzgu8
tuB8vyfLHm+fu8ryv3u/y/nrjfiT8O9Y+EPxF1/wn4is/wCzvEHhfUrjSNTtfNSb7NdW8rRSx742
ZG2ujDcrFTjIJHNa1cwk4vmpuPvS2bVr301T1V/y0Jhh4prlkr2X4dfRn69/Cj4e+DPBn7fX7b3g
74YfCHw14m0PS/hzrC2s+iLqtx9qvrqy08t4caO2uxBHFJdx3o8i3jjulkjmjilVIgieF/sJfBnw
d8SP+CcXizxt4Z8Ii7+Kdz8WTYXOmeFPhnZfE/VdG0H+zBPbRjS9UuCbWxNy06rebzLI8HlO8uMp
8VfCj9kDx98Zvh3deL9I0zSrHwjaamuitruv69p+gaZLftEZvskVzfzwxSzrFiRo42ZkRkZgodSe
puP+Canxp0i98VRa34StPCEHgzWx4b1S+8U6/pvh7Tk1IxGcWkN3fXEMFzKYNswWB5MxSRyD5JEZ
iWMnPllGl7t5W/7ed9GkrNeXboOdOKTTnZu2/l5eZ+lfxu8N+DdZ/Zr8b+E/Bf7P2p/ETQvC/wC0
nPruufCHQNTQ6zpkE3hCG3Z520WW7+x266iZ9oiby0kgkt8RlHiSz8ZvDdxrP/BN34ZeDNX+EMvx
o1zwH4x8M3XiL4ZeH0uLHxHbWj/Dyzt0l1MWSNeQEXYbbJLGNwtxFkBTX5l3H/BNT406Re+Kotb8
JWnhCDwZrY8N6pfeKdf03w9pyakYjOLSG7vriGC5lMG2YLA8mYpI5B8kiMzp/wDgmp8Y9Psr+/1D
w/oWjaFYXNpZ/wBv6t4t0fTtBvp7q0F7BFaalPdJZ3btbMsu23lkKo6lsbhl/XKiXKqXV9P8Wnw9
L9dNHpqxKnDfnX9fP+u5+nHxq8IPff8ABNT4YeDNW+EMvxo8Q+CPGnhu88SfDLw+1zZ+JLK1Pw9t
LRX1RLIPe2xF5GxV5Y1JEHlcKBXxL+3ddfDX4ffEXwNoXxL+Hvji98V6N8NvCdleRaH4tsfD09g8
eiWaPbX9rLpN1Kt5HKswJkcN5RtwUXblvHJ/+CcHxfsNPv8AUNQ0DQtG0OwntbYa7q3izSNO0S+m
ubNb2GK01Ce6S1u3a2dJdtvLIVR0LAblz5t8Yfgv4k+AvjIaD4osIrHUHs7fUITBeQXttd21xEs0
E8NxA7wzRPG6kPG7L1GcggYYvFVJRu4Navez/m01Wu/3q+9y4UY83xX+b/zPob/gn5Bqw/ak1vxr
8OLl/hv8I/DNgP8AhO9Q8a3C+INJtdAn2RXNjqSwwWy6iLxw0cVlHEkkztGEKtGZ0+j/APgllr3g
7x/8T/2vI/hD8C7jUfCN18OPEreH4tTm1fUtWuYbk2otdAnNrcrD5cwgnkjRFN4CrKt3L5e8/mzo
nw78QeJfCet69puhazqGheGRA2sajbWUktppQnk8uE3EqqUi8yT5E3kbm4GTxW38C/2e/GH7Sni+
60PwZo51a90/TrjV7+SS5hs7PTLG3TfNdXVzO6QW0CDGZZnRAWVc7mUGcJjZQlBKF7Nu3e+llpp8
lr8lZ1qMZJtu3/A7/wBbH2//AMEV9Yn8bJ+05F4f+C2h6xJdfDLxFIraeuvXDyi7NsLbw4BHekG3
lMUgjGPtr7Xxctt4b/wRYv5fHZ/adTQvgzo2stc/DDxDJGunx65c+cbp7X7N4e+S9ObeUwyiMc3r
lHxcErlfkS0/Yh+Klz8ePEvwzfwdf2XjLwZb3N5r9pfTQ2cGi2tugeW6ubqV1t4bYKyETvIInEsW
128xNxZfsRfFO8+PfiD4ZP4QvLHxn4Tt7i81u01C4gsbfSLWCMSyXdxdTOltFa+WyMtw8gidZYir
sJE3b0MVVpez/dP3HJbbt9NtGtQdOLvZ72/D5n15/wAEU71/Hkf7TUGifB3Q9Ymn+F/iKWH7EuuT
teNcm1+zeHAI73Bgl8iYxgD7bIUfbcMVG0/4Im3cvjp/2m49E+DWj6603wt8RyItiutz/aWuvs4t
fD3yXnMEjRSGMD/TZDGwW4OOPkLT/wBib4pah8evEHwzPhG7svGXhOC4u9btb+5gsrfR7aBBJLd3
F1M6W0VsEKMLh5BE4kjKu3mJudD+xD8VJPj94l+GEvhC8sfGng2G6utetL65gs7fR7a2TzJbq4up
XW2itghVlnaQROJIyjt5ibjD4mtTdNKk24uS23b6baNfP8AnTT5lzb/13/rufXf/AARV1SXxpb/t
NxaF8F9E1uSX4X+I5lexi126aYXP2b7P4eIjvdv2eTyZTH8pvWKPtuCVBVf+CLF8/wAQR+0xDoPw
S0PXJZfhn4juI/7Ph166ab7ULcW3h393fEfZ5PKlMeB9uco4Fy2OPkS1/Ye+Ktx+0D4j+F0nhC7s
fGvg+K5uddtL+6t7K20e2t08yW6uLuaRbaK2CFWFw8oicSRlXbzE3Fr+w98Vbj9oHxH8LpPCF3Y+
NfB8Vzc67aX91b2Vto9tbp5kt1cXc0i20VsEKsLh5RE4kjKu3mJuihWr03TapP3ZPpu3023Wv+QS
hF81pb/132Prz/gitqI8eR/tPJo3wX0DV2k+F/iS5iexj1u5Mhufs/2bw6Nt9j7PL5UojwDfOVfb
cMV4m/ZwsJvij/wRr1+Lwn8NtP8AjDrX/C+Xv5PhfaQ6jfQ+F7KXQwsWpJHp88erCOSTNqr3V3LA
32YAL5wkkf45s/2Kfijd/HbxF8NX8JXdl4x8I29zea5a39xBZW+kWtvGJJbq4upnW3itthRlnaQR
OJItrN5ibt+f/gm58ZtIvPEsWueErbwhD4S1v/hG9SvfFWu6d4d09dS8nz/ssV1fTwwXEnkFZsQu
/wC6lik+5LGzJVKyhCDpv3eZPTe99Numujv6BKmtXzb2/D5n6la5+0T8PPBv/BVvxb4A8Nat8QJv
jZ4p+MGiNqnjDw5olhrCXvhmzsdLlfw5K8dzAbOGC8t7gXcsUTSCGyC3BuSsgHmn7UP7Ptzofw+/
aC8R/Cj4bnx78eZ/2jtTg1mz1b4fWfiXXLHw1c6d9utpv7KuY7xbezkvJrjyb1IkN0gQllAWJPzY
P7HnxOH7TbfBr/hC9a/4WamoHTG0Dyx9oWULvLFs7PJEQMvn7vK8r97v8v564/4k/DvWPhD8Rdf8
J+IrP+zvEHhfUrjSNTtfNSb7NdW8rRSx742ZG2ujDcrFTjIJHNbYjMZyi3Up29+Tvro3e61W6ve/
poZxwyT0km7dt9vwP0E+HH7DHxK+Il78SPF/xI+G3iKf4TeBvGsqXHwc+E17PqlhrfjAWUDy2UcN
pcXa6bCkUsX2u7JzArG1gAlAig6T406/+0D8fPhR8Ufht8bPgLrXxCvLb4q2vi2+t/hr4m0+LX/D
2pz6DFbQW81rBDqUkmmtp8dqIZvJUGSGVXuZpdyp8G/CL9jf4hfG34cXvjLRtL0mx8H2GpLo0mve
IPEGneHtLkv2iM32OK61CeCKa4EQ8xoo2Z0RlZgAyk8r8Zfg14o/Z6+KWueCvGmi3nh7xR4cums9
QsLkDfBIMEEMpKujKVZHQlHRlZWZWBOH1ySp3UXZve6s/i0+G17PTovestdL9neTUpJvTTXS3z/r
Q/cD/gog3hv4ueAviPpOk+Ar39pFfCX7Rkd/r3gLwpqc51QWz+ArGx8+4ewWaeCOLUIHjL7Apms5
oid24Lm/tPeFrTXP+CU/wE8D3Pwo1j41eJvhxr2hXPjf4W6JdXdv4i00S+CUt4ZtQjtYmu7JVnWM
rviIfydhcbtqfj38Iv2N/iF8bfhxe+MtG0vSbHwfYakujSa94g8Qad4e0uS/aIzfY4rrUJ4IprgR
DzGijZnRGVmADKT2Gs/8Eu/jb4XsJdR1rwto/h7QFazS28Q6z4r0fTdA1Vru2N3biy1Oe6SzvS0A
MmLaaTaPvbTxW/1+pN88afVtWStrzafDrv1utHpq7wqfL7rnqkvwtrv/AFffY/VP9pzw9a65/wAE
pvgJ4CuvhNq/xq8T/DnXtDuvG/wu0Oe7t/EWnLL4JS3hm1BLWNruxVZvKwHjw/kFS/zbU/Nv/grf
ZN4f+InwZ0G7gaw13wz8HPCul61p07FbzSr1LRjJb3MTIrQTKGQmJssFZCT82ByOqf8ABLj43+Hd
Jm1XWfCuk+HfDqPaR23iLW/FWkaX4f1Zrq2+1QLY6ncXSWd8Wg/eYtZpSq8tivLfjX8B/Ff7PHi2
30XxdpQ0y8vrC31Wykiuoby01GzuEDw3NvcwO8M8LjOJInZcqy53KwGGLxNSdJxlBxXNv85Oz0V/
m9LPTVm1KK5r8yf9ev8AXc5CiiivKOgKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooA+7f8Ag2g/5TX/AAc/64eIf/Ud1Ov6y7D/AI9I/wDd/pX8mn/BtB/ymv8Ag5/1
w8Q/+o7qdf1l2H/HpH/u/wBKALkHU0UQdTRQB8cf8HR3/KCj45/9wD/1IdMr+cP/AII16/pbfFP4
yeDLjULS08SfFj4ReIfBHhG2uJlt01fW7wW4tLITPiOJ5jGyqZHRWbam7Lqrf0ef8HR3/KCj45/9
wD/1IdMr+Sj4NfBrxR+0L8UtD8FeC9FvPEPijxHdLZ6fYWwG+eQ5JJZiFRFUMzu5CIiszMqqSOjC
1JU60ZRV32730Mq0FKDTdj7F/ZBsbX9l/wDYK+Jvi743+FZ/iF8MbvxzB4Ig+F1zePpV5b+KII0u
5dRln2/aNNMNoktuWgXzLhpTDJtSMmvpeHwfrnjr4bftp+IfC3w4m+Lvhrx1YfDnU/Cnh6Tw/cWk
T6dJHbXVrpIttHnjZZdNsrqzjZLeUNtt4pGHlylX/LzxL+zB408KfB6/8f3Wn6dL4O03xVJ4Km1S
z1myvYW1WOA3Bij8mZ2ljMQLrcRhoHH3ZDkV2/gn/gm18XPiB4H1nxJY6V4Tt9D8O22mXuq3ep+O
NC0xdMg1K2t7qwlnFzeRmJJ4rqHYzgBnLR/6xHRe3D16kYqnGm3v+Kkn0fRvyVna12YVIRvzuSX9
Lz/q68j9CLPxh4a+An/BOf4o+GPiv4G0nwz4M+Jf7Td74c8Y+HtJ1SCZvAdhcaXbX0L2dzpwZDPY
TRxMITA8TfZJITCrF1Tyr4+/D+bxv/wcm6rd+HL/AP4SXQvA/jnSvE/iHVnms4rTw/punCyn1GS5
mXZbxQ2QjkhLTEPuhVZC87Hd8dfH7/gn98W/2X/Cuta1458Kx6Jpvh7xLF4Q1CUavY3ZttUksU1B
LcpBM7HNq6v5igx5yu7eCojX9gr4ryftCeIPhRH4WSf4i+GrCTUbvQIdWspbueOO3S4aO1CzEXk/
kuHFvbGSZgHwh2NjT63UahSdN+7Jeu8tHp5u2m/NZa6KNKOs1PdfLZa79vzMj9srx3o3xS/a++Kv
ifw7eSaj4f8AEfjDV9U0y7kiaJ7q1nvZpYZCjKrKWRlO0qCM4IHSvNqKK8ic3OTk+p2RVlY/QT/g
lT4G8Ta7/wAE3/2uH0f4U3fxWTVz4TtbTRGstTng1eWDU2kmjQWEsM8jwpLFMyxSBkHls37ssG+k
/wBv34bJ4nsfj340+DWgaL8a/jYPjXYaDqhXwdpXjW90rw+nhmKSOEWJtJoreKO+S4tjOLdJWay2
SSSSI9fmh+zb/wAE+vir+1vpOn3fgLRdC1b+2NTutH062uvFWk6Ze6ldWtvDc3MdvbXVzFNN5UNx
C7NGjKofk8HBpP8AwT++Jutafq+ow2vgtNA0TUIdJuPEE/jrQrfQZL2WA3C2kOpSXi2dxOIQXaKG
Z3jGN4XIz6lGvNUYx9m2tk//AAJ6abq/m1bS12cVSEHOXvK//Db69beR+hH7U37JXhn4YfDz45Xv
7NPgjQPiZ8R9O+OEOmX+nWfhHTPGs3h7Q5tCW9MEViba4itbaPVHvbYSJDGf9EELO5jZVsfCnU/D
/wABf+Civ7aPwh+Fr+DNS0S/+H3ii+8J2CeGNFv77UNbls7G5l0aBhbGa4gieO5iXTAXiX7O26Eu
shPwp4U/4JMfHzxl47ufC1t4L0+18T22vXvhpdI1LxRpGm395f2dvDdXMdtBcXUclyiW9zBL5sKv
E0cyMrkEGuX+F/7AfxS+NfxD1rwz4T0jQNfvvDyWbX95Z+K9Jk0mF7yWKG1hGo/afsbzzSypGkKT
GRnDqFLI4XojiqkZxqQote9pa/8AeulpvZ+b0QnCDupTW3l5av7tPmcZ+0L4E8SfDP43+KdD8YWu
iWHimw1GUata6RLYSWVpcs2+SGMWJNrGEZipihwsRUx7UKFR9af8E5vh4niv9kDxXeaN8MNa1/xP
F4ytbebxPoHgDQvihqMNobGZk0+TQb+dJbGFnV5V1BEKTMjQlgYcH5x8KfsQfEvxj8LfHvjG20TT
bPRPhfcPaeKl1TX9O0y/0SZePLlsrmeO63u+YkUREyyq0SbpFZB5PXlwk6VRTlF21/y3t+K/A6Zx
54uEWv68j9XP2SdS1r9nv9uz9sr4P6EfhF4m1G78EeM7rw7aeGPCelyJq2qTJbTJpVnHLDNcyxRR
I6to/mzwo9vMpSTY8jUP+Ccv7ENt4ZfxJ4v+IemeEPFnijTvi1aeHfH3hK2s/Ck+k+AdFjtJNSvN
bvriW0vLe2sQPtVuYLU2QV7SSITeaqRRfllRXVHMYpwbhpFtpX769U9jJ4V2lyuzaWtu3zP028R/
stWfwp/Zy+N0/wAB/h5o3jj4meG/2itU8GtpT+E7XxxqOj+FYLWZrBvsd5BdGGGWcTKLkRhpWgKm
RtmBY/ZP+Clp4e+BP7ath8eLZPhd4M1LxX4RtPFM3gq2ttSsdEb+3hPc2FiYJZYAbYXMCvHG80lq
hGYpXTyH/MGis1jYK1obX0vprfpbzXXp00ar2EmrN/O2v9fI+nP2iPD+peDv+CturaZqehfBvw7c
6d8QreGLSJjZnwNYQLdxi3gumtooImsVh8tbhmiikZRKZkSUyKPE/wBoaMw/H7xyhPg9iviC/BPh
Ig+Hz/pMn/IPI4+x/wDPHH/LPZXH0Vy1KvPfTd3NYQ5Ul5WCiiisTQK/Q7/ggvaXuv6N+0vZaZ8K
bHxveJ8H/ECC9EOqS3F/LOtusOisLa4SPZc+VMVWKNbtyjiOZVUgfnjXY/BH4BeLv2i/Fd3o3g/S
Dql3p2nXGr38slzDZ2mmWUC7prq5uZ3SG3hQYBkldV3Oi53MoPXgajp14yjHmfbvdW7P8jHEU/aU
3C9r/wBeR9yf8ESpV8fzftSNpfwW0bXVf4VeI7iAWCa3cBZLjyfs2gDZeEmCby5Qg5vX8tsXGFYi
v/wRTuD45H7UI0n4O6TrrzfCvxFLbixGszFnuPIFvoI2XZ3QSiOUoozev5LbbjCvXyQv7D3xVX4/
+JPhfceDr7T/ABr4OgubvXbO/ngs4NHtreMSS3dxdSutvFbbCjLcNIInEsRR2Eibix/Yh+Kl58fv
EXwwfwheWHjTwjDc3Wu2mo3MFjb6NbW6eZLdXN1M6W0NsEKsJ3kETiSMq7eYm7tw1erTdNqm3yt9
N2+m2j8tfwMnTjLmalo7dei+fX5H1t/wRUnfx2/7Tq6N8HtH1ySb4W+IZ4Fsk1mcSNP5Bg8P/Jec
wTLFNsA/01zE224O1qf/AMETriTxxL+1ANG+Dmi6+Z/hV4iliS0/tiXc05t2t9BXbdktDKIZQir/
AKa4jk23HynHyPa/sPfFW4/aB8R/C6Twhd2PjXwfFc3Ou2l/dW9lbaPbW6eZLdXF3NIttFbBCrC4
eUROJIyrt5ibkh/Yh+Kknx+8S/DCXwheWPjTwbDdXWvWl9cwWdvo9tbJ5kt1cXUrrbRWwQqyztII
nEkZR28xN10MTXh7L903yOS23b6bbrtr6DlCMrpS3s/+DufXn/BFTUH8dv8AtOx6J8FNF16S7+GH
iKSBbCLW7re1yYDbeHhsvCTBKIZvLC/6c5ibFwQrUv8AwRLuv+E8H7TsWj/BHR/Ek0vwu8RTW/2B
NcuGd7n7OLbQP3d4c28vlTbAB9tco4FwcHHyFD+xD8VJPj94l+GEvhC8sfGng2G6utetL65gs7fR
7a2TzJbq4upXW2itghVlnaQROJIyjt5ibiH9iH4qSfH7xL8MJfCF5Y+NPBsN1da9aX1zBZ2+j21s
nmS3VxdSuttFbBCrLO0gicSRlHbzE3KjXrQVJeyb5W1tu30Xu6NdtWKVKMlJKW9ur/zPrr/gizdy
+Ph+0+NC+C+h60X+F3iK4UWKa1cb/tLW32fw+Nt4SbeTypfLC4vn2SYuWCnE37O1ne/FX/gjR4jt
vCfw8sPi9qSfHWTU3+F9nb6lfR+EbSTRAE1aNLCePVFjkZTaB7q5mgIthhfODyN8e6f+xN8UdQ+P
ev8AwyPhK6svGXhSC5u9atdQurext9ItrePzZbq4u5pEtorYIVYTvIInEkZV28xN3RXH/BNL41aR
c+J11zwfB4Ot/B+tL4c1O+8Wa7p3hzT11FoftC2sN1f3EMFxKYCswWB3zDJFJ9yRGaFXrKEIOm/c
clt1fTbddtfQc4xTfvW2f3fM/UfVP2kfAeif8FfvFfgzw5rvj7UPjT4u+MWhjUfFXhvRLDV49S8N
2tppbyeHZJ47i3azt4bmC5W6lhhL+TZhbg3GJAvl37THwKnsfh7+0H4n+Evw5g8ffHW7/aN1KHV7
HUfAFr4n1rT/AA3caeb2CX+zLmK8SCykvJpvJvUjia5VFJOMRRfBF9/wTV+NOgaj4mt9f8I23g6L
wjrY8N6le+Kte03w9p66iYftAtYbu+uIYLiQwFJgIJHzFLFIPkljZrWof8EvfjZoejzatq3hfR9A
8OK1pHb+Ita8V6Ppegaq91bfaoEstSuLpLO9YwfvCttLIUH3gtbVcbVmmnSa95tb3V76eq776GMa
FKOqktkum3+R9Q/D/wDY1+JPxUn+JfjD4i/DvXG+EHgjxw7T/Bb4S39zqWma54x+yW/m2kNvaXF4
umQrDLH9quycwqxtLcCQLFB0Xx18V/tD/tFfDn4ofDr43/AnX/iDd2/xTg8W6jZ/DjxHYxeIPDuq
z6FBbQW81tFDqUrab/Z8VqsUphXMkMqvczSh1T421P8A4Jm/Gjw/oc+sat4X0vQvDcctpBB4h1fx
PpOnaDqcl1bfa4Es9RnuUtLxmgxIRbSyFVI3bciptU/4JffGvw9ps2pav4Z0TQPD6NapbeIdZ8W6
Npmgas1zbC6hWx1O4uks75jAQ5FtNKUBG7bWLnUiuVU5LV383ro/dtdK/wD5NprpryQTbcltp5be
f9adj9Zv+CjmqaH8XvA3xL0nSPBEv7SUHhX9pGPUPEPgPwzf3A1NoT4EsbBZ52sBJcW8Ud/DLEXC
KrTWssROdyrh/tF6RD4h/wCCWfwQ8Dal8NdU+PHiH4d+I9Bn8U/CvQ7nUbXX9Ghl8BwwRNex26Pc
2ardASAiNEdomQ7maVh+Wmqf8EwPjZ4e0W51fV/C+kaB4bhe1ig8Rax4q0jTdA1V7m3+1QpY6lPd
JZ3zNB+8K2sspVfvAVJq3/BLf43+GtLn1PWfC2j+HvD0bWaW/iLWfFmj6Z4f1Vru2+1wLY6ncXSW
d6zQESEW00pVT822t54+u5OTpfal0W75tNY62vs77PTVmUacIrlc1ovTsr6P8rdPI/Uz9ouyPir/
AIJb/A7wNqvw01X4+6v8OfEPh+48UfCvw/d6ha+INEt38BwW0TagluklzabbzLq3kojeUYzuZpGr
4a/4KE638NvBXiz4W+HPid4K+IOr+LfDXwr8K6Zc2mjeM4dCk0AppkRexvLS70y8eO7ErSytteJQ
k8QMQdXkk8S1f/gmL8a/DOjvquteFdL8O+HibVbXxBrXifSdL0LVjc232qEWOo3FylpeloMSEW0s
hUEbsEgV5n8bvgJ4s/Z08YQaH4v0tdNvbywt9Us5IbuC9s9Rs503w3NtcwO8FxC4ziSJ2XKsudys
By4mvUdOzp8qUnq15y0emr1/B2SuzWFCKfxf18n+h77/AME+NP1ib9qLWfG3w4u4/hv8KvCemmTx
xqfjidNf0e00OZFiubHUVigt01EXjhoobJIVkmd41QhozOn0T/wS713wj8QviZ+1snwj+B9zP4Pu
Phv4nfRBqFzquo6vLBcrbC10GZracRGKY287JHGgvMGRPtkojLn849D+G/iLxN4Q1zxDpug61qGg
eGPIOs6nbWMstnpPnuY4PtEqqUh8xwVTeRuYYGTWz8Cv2e/F/wC0p4yuNB8GaSNUvrHTrnV72Sa7
gsbPTbK2jMk91c3Vw8cFvCijmSV1XLKudzKDOExkoTiowu7t+t1ay0aS+X5K11KcXzOT6fd11/r9
T7d/4IrX58dw/tMQ6N8FNF113+GPiS5SWwXXJ2k+0Lb/AGbw8RHdsDbSmGXywAL5yHxdELwf8EWN
TPje3/aYh0X4H6D4ilk+GPiOeOWyXXbhz9pFv9n0DEd6QbeTyZvLAAvXIfFywXA+RIf2Ivio/wAf
PEXwxn8H32neNfCFvc3muWeozwWMOj2tvF5st1cXMzpbxW3llGWdpBE4kjKs3mJuS2/Yl+KU/wAe
/Efwyl8IXth408IQXN3rlnqFxBZQaPbW8fmy3VxczOtvFbhCrCd5BE4kj2s3mJuujXrx9n7jfJJr
bq7e7tvv3eui0QSpxlez3t1f37n13/wRY1j/AITO3/aYg0b4JaBr8s/wx8RzRSWY12d5Dci3Nv4f
xHekG3kEExjAAvX2yYuW24Ef/BFy/HjaH9pxdJ+Dmg61JN8LvEUlu1outztI90bYW2gLsuyDDIIp
vLH/AB+PskxcNtwPki1/Yk+Kdx8evEfwyk8H3tj4z8HwXN3rtnfzwWUGj21vH5kt1cXUzrbxWwQq
wneQROJI9rN5ibl0v9iP4pap8fPEHwxPhK5sfGfhO3ubzW7XUbu3sLbSLW3i82W6uLueRLaK2EZV
lneUROJI9jN5ibtaGIrUvZuVJtQk1tu39nbRp9Pw0CUIu7vvbr2+Z9df8EVdVbxkn7TcWjfBXQdf
e4+F3iOSM2ia3cM5ufsxt9AAjvDmCTyJvLAxevtkxcMFIEn/AARX1NvHkf7TkWh/A/w/rskvww8S
XMb2Q12cn7SLc2/h/wCS9INvJ5M3lji+cq+LltuB8iWX7DPxXvPj/wCJPhe/g2/sPGvg61ur/XbL
UJ4LGDR7S2i86W7uLqZ0t4rYRlXWd5BE4ki2M3mJuW2/YY+K837QfiT4Wy+Dr2w8b+Dre7vddsr+
5gsoNHtbaLzprue6mkW2jthFtdZ2kEUgkiKM3mJumlia1P2X7t+5Jrbdvptv95M4wlze9ur79uu5
9cf8EVtS/wCE5P7TqaN8EtD10z/C/wARzxGwTXbkg3Ig+zaABHenNvL5MoT/AJfW2ORcttIp37Os
178UP+CNXijTfC3w6sPi5f8A/C9f7WPwzs4dUvofCVrJohVdURLCaPUhHIwFqr3V1NEwtsBBKHkf
5Ctv2H/irN8fvEfwwm8H3uneNfCFvdXuuWepXEFhBo9rbxedLdXF1O6W8Vv5ZVlnaQRyCSLYzeYm
7cm/4JufGbS18Tyaz4StvCdl4Q1tfDepX/ijXdO8P6eNSaA3AtYbq9nhhuZDbhZgIHkzFJFJ9yWN
miFatyRjKm2otrbq+m2++jvfsEoQd3zb2e/b59T9Stc+Pfw00D/grl4w8A+HNd+It78Y/Fvxi0GS
88Z+GtIsdaGo+HLay06Sbw7LLFcwPZwQXcM4uZoYpJPJswtwJyjivMP2n/gBNo3g/wDaM8Q/CP4f
J8RfjjJ+0ZfW+qW2p+ALPxNrNp4cudPkvYphpdxDeJBZSXkkvk30aobpAhbYNsS/C99/wSv+OWg+
F9Z1vXfCujeEdJ0DxNL4PvbvxP4t0bQIk1VLWK8+zq17dxCTdbTxTRyJujljcMjOMkYujf8ABPf4
oa7ous6vDZeDo/DehapDodx4iufHOhW3h+e/ltvtS2lvqUl4tndTrBh3jglkaIMokCFgD1VsbWqX
U6Tu5Sa30ve/Tda6+WxzqhBO/tNklrby/PttqfWXg/8AYw+KHxMv/iR4p+Ivw48RJ8IfBfjmQ3Pw
b+Et3danpWseMfsUBls4IbWe8j01FilhF3dFt0CyG1gUSBYYfZ/gX8BfGPxA/aR+IfxO/aG8PeF/
EPxKuviRo+keO/CFxb+HZNO8BeHk0n7f/bN/c31rfCLTVsgsC+TPbzSG3ZWuWuDHX596t/wS9+Nn
hvTZ9S1jwzofh/QI5LOGDX9Z8XaNpug6o93afbIFstSnu0tL0tbkSH7NLJsDLu2lgCzUv+CYfxq0
HQ59Y1bwzo2g+G45rK3g8Q6x4r0fTdB1OS8tftcCWeoz3SWl4xt/3jC3lk8sEb9pIFZU6lSFmqUv
iv67/wB3da26L3tNXbRxi0/fW3+Xn1/yPvXxF8ING+HX7K/xK+F1h8GNe+Lmh/DX9qTWdTk+GelX
mpxatFoFzoMttpt68kCSXEdq2yB4rht4mMIBJDZb1v8Aaq0waz/wTC+BXgG/+HN58c9Z+Gmo+Gbr
xf8AC7RHvrLxBpIm8Fy26tqKWnmXNsYpkRlkdIyfLETRqqh5vyxuf+CX3xr0vQLrWtT8M6JoHhu3
ms7eHxDrXi3RtK0LVJLu1N3AllqNzdR2l6xtx5hFtLKUUjftyMzar/wSx+OHhzRbnV9Y8L6J4e8O
QyWUUHiHWvF2jaXoOqveWpu7dbHUri7S0vi1uPMItZZdgI37cjNPE1ElD2L0b6L+9p8PS73utHom
2EoxT1qa27+nn/V12R+o/wC1Dbx+Iv8Agl78D/At/wDDG6+N2s/DnU/C914t+F+gy3dnr+nJJ4Il
tkl1FLPzbm2aOdI2EjrGWESxPEFCvJ+cH/BW2G40n4k/B3Rr+OG01jw78G/CWl6nYParbX2l3Mdg
N9veJ5jOJ1yDiRInEbRKYyAJJOV1P/glp8b/AA/o13q2r+GND8P+HbeWygh8Qaz4v0bTNB1SS8tf
tluljqNxdpaXxa3xIRayy7FK79uRny745/s/+Lf2bfGkGgeMdKTTL+80+21azeC8gvrTUbO5jEsF
zbXNu8kFxC6niSJ2XIZc7lYDnxlZzpcrpuPvXu/npeyb+bsrOy1ZdCMIy92Sbt/l/wAD+rHG0UUV
5Z1hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3b/wbQf8pr/g
5/1w8Q/+o7qdf1l2H/HpH/u/0r+TT/g2g/5TX/Bz/rh4h/8AUd1Ov6y7D/j0j/3f6UAXIOpoog6m
igD44/4Ojv8AlBR8c/8AuAf+pDplfzjf8EYvEWm/8LV+M3gubULO08SfFr4P+IvA/hK2urhbaPV9
bvFt/stkJnKxRvKY3VDK6qz7FB3sgP8ARz/wdHf8oKPjn/3AP/Uh0yv5J/g98HfE/wC0B8TtF8Ge
DNFvfEPifxDci00/T7RQZJ3IJJJJCqiqGZnYhUVWZiqqSOjC1JQqxlFXfbvfQyr01Om4t2Ps/wDZ
S0+X9mD/AIJzfE7xL8bfDWo+PPhXc/EKLwTbfCy9luNKnsfF1vBHczanJclBJpzxWSS2zi23TTFx
HOqRxoT9L6F8GfFet/AP9snxN4X+HGu/F/wR4/tPAereC/D9/omqpbvp9xMmowaLbpYXCyH+y7S9
tlMNncGKJYYt21MR1+Wvib9lnx14S+DN98RLvR4JPA2n+LJfBEmt2epWl5Zy6vFB9oe3ieGVxMvk
4cTR7omVlIc7hnuPCv8AwTQ+Mfi/wDqfiiHQPD+n6Bo1jpuqX15rHjDRtIS1tNRghnsblxdXcZEU
6zxqj42tIHiz5sciL20cTUUI0+RtK/rqpLe2u+z00emrOepTWr5kr/8AA81rp+J+h2neLNI/Z1/4
JufFDwd8Yfhe/wAPvBPxK/advvDPi7w+lzdQy+CdMudMs9QgnsZbeNoZTZPBazxFIZUuIYwPLaOZ
CPK/2gfA9x47/wCDljU9W8OafrJ0TwT420bxh4ku9Znnt49D0+wSwuNRvbie/KCC0jKyeWzMINrQ
Jblo3gDfGv7Qv/BPH4xfsqeEdV17x/4Nfw/pOieJU8H3k7anZ3Hlaq+nxaituFhmdn/0SeKXeoMY
EiqWDfLUOofsA/FvS/2ifEnwlm8KIPiR4VsJNRvtAXVrJ7uWNLdLlktgsxF5P5EiyCC2MkzKG2od
jY0eLqckKUqbtFq3fTmsr2839z07RDDw1mp3bT9Omtr+SMf9s/4haR8XP2w/ix4r8P3TXug+J/GW
r6tptwyyKbi2nvZpYnIkAcbkdThwG55AORXmlFFeROXNJy7nfFWVkfbH/BvD4V1XxJ/wVt+GVxpt
he3kGjRare6hPBbmVNPtzpl1D50pwVjTzZokDNgb5Y1HzMoPSeCPg94w+KX/AAQ81r4X+GPCnifx
H8SfCX7Qr6hrvhTTNNurvWtFtzoBthNcWSIzwp9oimiLsq/vIijcgAfL/wADf2G/iL+0Z8K/EHjb
wta+FJPDHhS5jtdZvtU8ZaNow0tpCixNMl5dQvHHI8ipHKyhJHDorMyOq6P7RP8AwTm+Mv7J/gzV
fEPj/wAHf2Bo+i+Jo/B17cf2tY3Xk6rJp0WppbbYJnZs2c8Uu9QYxu2lt4Kj0KdaccPGPI+W8te/
Mku3Tlv16nHUUJVX76vpp10fr5n6FfBW8tPib/wdY65rXhX+19a0XQdV1NtYvGN1dDTmh0SSxu2e
SYu0UKXzGCPDeUpaGOHCGJa8S8HWfhn4df8ABA+70/4n+FvH9+dM/aOu7GfR9N1geHrmxvE8Owq3
mvc2V1GGTZKjxCJJASpZgFCnxCz/AOCO37Q1543fwz/whWkW/iMatcaFFpV14w0S2vb29t7C01Ge
G3hkvFe4MdpfWkrmIOqiYAkMCBi6T/wTD+LuveDtZ8RWVt8O7rw94eeFNT1SP4l+GmsrETOI4ZJJ
vt+xYpJSYllJ2NKkkYYyRuq9NWvXe9JpuVR7dZJJq1vs21/Qnkpq0edLSPXovn1P0d/a3+A/i74q
Wf8AwUj/AOEK8HfELxBba7rHgbT9OD6XqN7d6rfW1xazXcNuZQ0sqxrMsoWLdCtvLbtGBA0Br8x4
PgT4j/ZZ/bj8OeB/F9l4Os/E3hzxFpS6jZ+L4pF8P28rvbymLUd6r5lku8LNJHuikiDvFJLEySPD
8aP2Bfi9+zv8OdY8WeNfBd54d0HQfGEngK+nubu23xaylol4bcRLIZHQ20kcqTqphkR1KSNkVw3x
S+DfiT4LX+jWvibThps/iDRbLxDYL9oim8+xvIVntpsxswXfGyttbDrnDKDxXLi8Qpz53TcXd9dF
rJ2Stp2+TNKEOVcvMmn/AJLz/q6LX7RG3/hoDx1s/wCEO2f8JDf7f+ES3f8ACP4+0yf8g/dz9j/5
4558vZmuOr0z9mn9jz4jftfa3qFh8PvDo1qTSfswvJ7jULXTrS3e5uEtraFri6kihE088ixxRb/M
lYkIrYOOl+Cn/BOH4xftB6Trl14X8MafM/hrXI/DerWWo+I9M0rUdN1GWVIYrea0u7iK4RpZnEMZ
aMLJKHjUtIjqvJGhVnbki3fayf4HRzxWjex4dRXuvwK/4Jr/ABl/aQ0/XZ/CnhfTZpPDGsx+HtYs
9T8SaXo9/pd/JNHBFbzWt5cxTxtLPKsMe5AJJQ8aFnjdVqfDL/gnr8Vviz4M8X6/p2jaBpunfD/U
v7I8T/8ACQeLNI8P3Hh653rGEu4L+6hlgDSuIld0CvIskakvG6qvYVdPdeu2nbf7hOrBXTktPM8V
or6Ftf8Aglj8b3Xx2b3w1oGgH4ZakmleKU17xjoujPoksnl+Q8y3d3ERbz+dH5FwAYJ9x8qR8HDf
E/8AwSz+OPgPWfEtn4k8K6R4Uj8I6nb6Jqeoa/4r0fSdKS/ntEvY7OK+ubqO1nuPs0iStFDK7xo6
l1XIp/Vq1r8r7bPfXT8H9zF7en/Mvv8A67o+fKK9xvP+CcHxl0SbxR/bfhO18J23g/Wh4c1K+8Ta
9p2g6f8A2iYhMLWC6vbiKC6kMBSbFu8n7mWKX/VyIzeZ/GL4O+J/2f8A4na14M8Z6Le+HvE/h65N
pqGn3agSQOACCCCVZGUqyupKurKyllYEqdCpFc0otK9tuvb1LUk9mc1X6Jf8EG0vPEXhn9pXStK+
E2meM76L4Q+Id2oqusPeao862iwaE621ysJjnaCVlSKOO7ciUJPtXav5212fwL/Z78X/ALSfi+60
PwbpI1O80/TrjV7+Wa7gsbLTLK3TfNdXV1cPHBbwoMAySyIu50XO51B1wdWVOtGcY8z7d/zMsTTU
6bi3bz/qx9x/8ES9Ym8av+1BFoPwT8P6+178LfEbolkmt3DS/avs/wBm8PIEvTugkMMhjABvn8qT
bcnaSIv+CKWtf8JbbftQRaT8G9C1prv4W+IXiNmNbmaZrlrY23h4bLsgwSmGUoABev5cm25O3j5G
h/Ya+Kz/ALQPiX4XTeD7zT/Gvg23ur3XbPULm3sbfR7W2i82W6uLqaRbaO28soyztIIpBLFsZvMT
clr+w78Vp/j74j+GEvg6907xr4Ptrm+12z1G4gsINHtbeLzZbq4upnS3itvLKMs7SCOQSxbGbzE3
ehh8RVh7L903ytrbdvpto18zJ0qcuZ829nv267n1z/wRSe5+IaftPR6B8GtD1yST4WeI5kFlFrVy
8xujbC20BQl2cwyGKQxgf6a/lyYuGCkCb/giPqN541j/AGoYvDnwZ0HXJbj4WeIpM2UeuXMk63Rt
hB4eUR3hBhm8qTYAPtrhJNtydvHyJZfsJ/Fm8/aF8SfCt/Bt5YeN/B1vdXuu2eoXVvY2+j2ttF50
t3cXc0iW0VqIyrrcPKInEkRR28xNxpn7Cfxa1P8AaB8SfC4+C7+x8a+DrW6v9es9RuILC30W0t4h
LLd3N1O6W0NqIyjLO8gicSxbHbzE3Kliq0FSTp/A2tt2+m2+/wDSCooSUryWtn8u++x9d/8ABEzU
ZvHf/DUMegfBDw/4hkuPhb4jliFlHrd0x+1G2Fv4fUJeHMEvlS+WB/pz7HIuTtOGf8EU/Ef/AAlA
/agTR/gp4f1z7d8LvEZj+xjW5yxuvs5tvD6hbxt0Ehhk8sD/AE5/LfbcnacfI1r+wv8AFef9oTxH
8LJfB93p3jbwfBc3mu2mo3VvYW2j2tvH5st3cXc0iW0Vt5ZRlnaURSCWIo7eYm5unfsN/FbUfj34
m+GR8G31l4z8GW11fa/aX9xBYwaLaW0fmzXdzdTOlvFbBCjLO8gicSxbGbzE3KliatNU3Km7QbW1
rt9NnZrUJU6cua8tHZ7v79z68/4Io3w8dn9p8aR8FdC1zzPhb4kuI/sCa7csxuRALXw+vl3pBt5D
FIUz/priOTFySvFn9m6wufit/wAEZ9et/CPw4tfjFrA+PMupS/Cuzi1K+tvC9lJoQEeqJFp08eqh
HcNarJdXUsJFthV83zXf450n9h74q6x8evEXwzHhC7s/GPhC2ub7XbbULq3sbbRrS3jEkt3c3c0i
W0NtsKMs7yiJxLFsdvMTd0D/APBND406cfFL6z4TsfCVn4M11fDOp6h4p8RaX4e08ak0JuFtYLq+
uIYLqQwATYt3k/dSRSfcljZpVWtyQg6b91yW3V7rbda3WvpoOcI3k+be3Xb8evyP1m/b7h0T4jfD
/wCJuh6f4S1X9qP/AIRf9ph9Y17wJ4c1BxqEdjJ4JtLSMytpcRmtoLa8R7YO0ZJeweJ3aQTM2b+0
dp1nqv8AwS6+CfgvUfhl4i+Oev8Aw/8AE/h668bfCbTZJbLWtHj/AOEBgtInuhYo19aqJ03h54wW
eN4vuKM/lP4B/wCCZ/x6+J37Quu/CvRPhf4nu/HPhef7PrFi8SQQaUxjeWNp7qRlt4klRGaKRpAk
wK+Wz71z4ZWtbMZc3PUp2fNJ9Ot7p3i725lo7+mrM4YeL93mvZL/AIffS9t9/M/dL9pbStM13/gl
n8DPBl98Jtf+N3iX4ceI9AuvHXwu0iaay13TIz4EgtIpLwWKPe2iCdEO+4iDM0DRAhAKrftN+GrT
Vv8AglT8DPBV38ONc+N/iT4c+I9CuPGvwr0uWWy13R0k8DxQRPdJZRtfWqLOgYvcICzwtEPkAr8a
Pgb+z/4t/aQ8Y3GheDtKTUr2y0+41a9knvILGz02zt0LzXNzdXDxwW8KDAMkrqu5kXO5lB7Txv8A
8E+/i58NvB/xF1zXvCsWlWfwm1GDS/FcNxrFgt7pMtw8SW7m1877RLBMZozFcRRvDKpZkdlViHHG
zcVONJ2TbvZNbS01jrZPrpo9NWXGjGD5VL5f0/6+SP1p/ae8LWmp/wDBKP4GeCbj4Y6/8a/Enw88
RaDeeOPhbpNw1trmkxyeB4raGS9SwRr60Rbhdwa5jDlo3iyE2U/9p3whZ6p/wSw+BHgiT4Y638cv
E/w81/w7d+OvhZo889rrmmpJ4JSCF72KxV7y0CXAI3zxo7NF5fCba/H/AOEH7GPxD+N/wxv/ABto
2maPY+DdO1SPRJNe8Q+ItN8O6ZLfvE0wtIbjULiCOacRL5jRxMzIjIzBQ6Funn/4JmfGvSZPFZ1v
wlZeELXwVry+GNVvvFXiHTPDtguptCZxaQ3V9cQw3MhgAmxA8n7qSKT7ksbMljasorlpuzbeyd78
2l+XW13vpo9NWS6UU7Oa01+emu/9X8kfqx+0vpdlrX/BLT4FeBLr4U658bvEngHxD4eu/Gnwr0ea
a01zTFPgZbSF71LFHvLQC4XfunjWRzEYshFQn4e/4KOaj8KPAviT4T6D8QfAvxK1Px3ovwn8K2Gr
Q6Z4u03w/wD2NNFpcMf2O5s30q6uBcoVLsbiVZNssaiNERGfw3Uv+CYXxp0HRr3VtV8O6BoXh6zl
tII9f1fxhounaHqcl1a/bIEsdQnu0tb5jbkSEWsspQMu/aWAPl3xp+Bvij9nvxougeLNPisNQms7
fUbd7e9gvrS+tbiNZYbi3ubd5IJ4nRgQ8TsucjOQQMcTiJun/DsuZ6tJ9Zaax1t66WemrLp0afNe
L6d35a7+R9Af8E/7fVG/ai1nxj8Obv8A4Vt8JvDumhfHWo+N54/EGk22hzIsd1ZaikcFsmo/a3V0
gso4kllkMSxkPF9oT6L/AOCWGp+FfiH8T/2sofhD8CZ9Y8JSfDnxLJon9qyatqGrTwXCW622hTm1
ukhEc5hmeONFN5nci3cxj3n8x6Kxw+PlScfdTs2/vVtO3y62vsjSpR5k0nuv67N/efoh/wAEVdYm
8YQ/tNR6D8E9C8QPP8MPEcu+yTXblpBdC3Fv4fxHe7TbyGGUx8fbWKOVuCVGH/8ABFXXJfGR/aaj
0H4JaJrr3fwx8Ruh07+3pnk+1i3W18PDy70hraRopPLXH22TY4FyxXj87KKVLGuHJp8Lb6dflv56
9NNBTw6lzefr/mfoj/wRc1RvHcf7TUeh/BDQNdeT4ZeJLlHsU164ZvtIt/s3h/8Ad3xBt5PJl8vj
7a5V8XLbeGf8EWXn+I4/aVt9A+C+j63K/wAMfEtwj6cmt3Ek5uVtxbeH/kvGU28hhlMYA+2yFZAL
hsDb+eNFXRzB0/Z+6nyNv1v/AJf5aaFSpP3rPf1/z/yP0M/4Ix3kvxAH7TC6D8F9E1hn+GPiW4U6
fHrtyX+1Lbi28P8AyXpH2dzFKY+PtrlH/wBIbbxN/wAEVtYuPG7/ALS0Xhz4H6Br81x8M/EsqtYR
69cu63awLb+HgI70g28nlS+WMfbXKvi5bb8v520VEMa4xpq3wNvpre3k/wCumgTo8yavv6/5n6Gf
8EXb6Tx0n7SkeifBTQ9fc/DPxHcq9lHrty0n2lYBb+H/AN3e4+zyeVKY8D7a5R8XDbeJv2cUb4nf
8Ef/ABVH4V+HFr8X9YHxy/tKX4WW8Or3tj4QsZdFYRapClhcx6kFkcNab7i6liK2sYKmXMjfnbRS
hi+WMYuOzfbW6S7f59rBOje+vbv0+Z+uf/BSPxx8U/iv+0R8efh/4M+F2i/tO/DbQ/iXZ67fqZdQ
v9V0vWX0C2s/Ka00S9tZEt7ZLWe1Ept/vwlJppZlGOq+N/wE+F3wj/Z9+IXws+HXw48RftEeG/hv
+0a2ran8PdB1m9mvLSwuPCAiy01mJpreGDUjND5jL5jGxEUsjupK/jFRXTLNE5OThq230dk+bTbV
a63ve2xhHBtRUFLRJLttbXfy6W/BH7sftVQxeIv+CZX7Pvw+1P4aeIvj1r/w0vvDFx40+E+kTXll
rWhxv4Ont4FultI2urTE481jJFvJQIX8t4lSL9qi2sPEf/BNH4A+BdS+FfiP47+J/hre+FpfGvwu
0i9vLfWNEgbwfNbQLdrZxvcWP+lHzCHiEjMiozlWjWP8LKKf9qrpDq+2zvo9Nd1vdabasawiXXp5
+Xn5eu2uh+7H7U+j2Pif/gmH8BvA118MvEHx28RfDa98Kv40+FWiT3lpruiRt4OuYIzeLaRvcWYW
7YOfMh3sy7WkZHjSKH9qTwpYa3/wTN+Avge++GXif46+KvhpeeF5vGnwr0a7vLfWtFgm8H3EUJu1
tImuLLbdYkIeHeSNjOyvGsf4W0Uv7UttHq3063301363W+mrBYWSvaXbv0t5+Xr56H7nftO6Da6t
/wAE3/gZ4Bv/AIT+KPjt4h+G134Tu/Gfwx0e9urfWNMhl8HXMMS3iWaNd2Bju2LkPDuPyq0rCRI4
fzt/4LE6dP4a+I3wP0C/klg1rw18E/COmarpM6pHdaBdrZs0lnPEEWSGUbxI0c2ZB5wOQpVV+Q6K
wxOO9rDktbW/Tz8lff5drts0p0HGfO3fS3Xy138v06BRRRXAdAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB92/wDBtB/ymv8Ag5/1w8Q/+o7qdf1l2H/HpH/u/wBK
/k0/4NoP+U1/wc/64eIf/Ud1Ov6y7D/j0j/3f6UAXIOpoog6migD44/4Ojv+UFHxz/7gH/qQ6ZX8
4P8AwRx8W6XZfEz40eD7nULWy8Q/Fj4QeIvA/hSC4lSBNU1m8FubWzEsmI42mMTopkZVLMqhtzqD
/R9/wdHf8oKPjn/3AP8A1IdMr+Sj4NfBrxR+0J8UNF8F+C9FvPEPifxDcC2sLC2A3ytgszFmIVI0
RWd5HKpGiM7MqqSN8LNwrRko82u3f/g9vMzrQjKDUtEfZn7IOhRfst/8E+viZ44+OXg6/wDiD8Kd
Q8dxeA7P4aXNxJpdxD4stYobye/lutvn6Y0FkHgYwKZbgzGKQLHGSPqN/gz4z8QfBP8AbI8Y+H/h
LrHxJ8EfFLTvh5rPgTw9J4dvLO01DSmMNxbaakGkTIWfTLKa2idIZwwEUcrgpIc/lX4m/Zb8a+E/
gzffEK60/TJfBmn+LJfBEuqWWt2N7E2qxwfaGijEMztLEYvmW4QNA4+7Ix4rvvDn/BMT4w+KPh9d
eKYNN8EW2h6fY6dqV/cah8QfD2ntpltqMENxYy3Uc98klstxHPEY/OVN5YqMsrAd1DE1FBUlBta+
v2l213e91o+7OarTTblzW/pea+/z9D9GtUktP2VP+CbPxM8IfG34ZWPgHwf8Uv2mptC8Y6Npt9FJ
L4P0q+0bT9XtnsJ7EvEz2G20mSMW7ROgMXl/Oyx+M/tG/C2+vf8Ag5Z1K60bwqdE0nwP400Xxp4j
ci2tbXTNMs4rC91DWLmUStDFFIokuTJLIHZrhQ4WaQxj40/aD/4J6/F79lfwlrGueO/CsOiaZoHi
WLwhqEi61YXjW2qS6fHqMduUgndyGtZUfzApjzuTdvVlFa6/YL+LFp+0PrnwmPhMy/Efw9YtqF1o
EGpWc15PGtsl0UtgkpF3N5Dq4gtzJKQGwhKMBbxdSSjB03ZSXrvK0dFvdu2nR6dpjQTbmpLVa222
jrv2X3NGX+2j8QdF+Lf7YvxZ8V+G5/tXh3xN4y1jVtLm8lofOtZ76aWFtjAMmY3U7WAIzggGvNKK
9p/Zr/4J8/FX9rvwdfa98P8AR/D+safpmp2+j3QuPFmkabcQXVw8cdsjQXV1FNieSVI4m2bZZN0a
FnR1Xy1GdSdoq7fRHZeMI6uyXc+o/wDglX8K/FviL/gmV+1vqGk/C3VPidZarN4TsbDRDp2qzWfi
C6ttT824hQ2EkU0kltDPFO6RShkWSNmGxjn6L8Sy2H7LX/BOD4l+EvjP8LbL4feE/ih+01d6L4t0
Kwv4pf8AhDtLv9E0/VrN7G4sQ6GTTiLWdIxC0cqAxGP5mVPx08Q+HtQ8I6/faTq1jeaZqmmXElpe
Wd3C0NxaTRsUeKRGAZHVgVKsAQQQRmqddtHHOiopR1jda2s78101a/Xa9t+ruYPDuU3JvR/8Dz8u
1/PQ/YrwZ4Ic/wDB2Tq0mjeEp7Ox026uNT1G3tbRY4o/P8ObXvZtm5Y1ubq4Ryz4LPdqGxI+K8X/
AOCWHhvSfgJ+wn+1rrnxx+Fni3xH8M9P1fwrofiDRn+06RJNd2+rGO5t1mHlsLuzN1BK0AdHy0aO
Y0lLV8WfCX9jr4g/Gn4aX/jTR9K0qy8HadqK6PJr2v6/p/h/TJb8xGb7HFc388EU1wIh5jRRMzqj
KzKAyk858afgf4m/Z88b/wDCPeK7G2stRazttQha1v7fULS7trmFJoJ4Lm2kkgmjeN1IeN2XqM5B
A6J4+TSqqnpzTeuq99JW2S0t89dLEKhG3subol56fPT9Nz9PvCXwm8TftKf8FOviz+x58ZtJtde8
IeLfF0/xAm1nwPpsWjz+FL42CS2+qRlEnXybi0kt7WaK7acCW6Egla4LSzfnP+2f8Wb34xftFa5f
Xvg1Ph5/Ysdt4atPDBWYz6Ba6bbx2FvZ3DzATS3EUNtGkkkoDM6t8qDCLQ8I/sseN/Hn7PPiv4p6
Rp2m3vgrwNcwWmvXKa1Yi801p5IooWeyMwuvLkkmRElERjZlkAYmKTZ55XLicV7SHLytXbd27tpv
RXstnfXq2+xpSo8s+a97JL59evXQ/QT4XX3gXRf+DeKK68c+EvFHiCxk/aKuIon0LXLbRbhpB4at
yoaeW0u9yIDJmMxLkzKyv8rqfrn9r/8AZO8ZfFPx1/wUU8NfDfwBq9yPHes/D+y0uCw07yLTVNTE
thd3zCT5Yd6m8W5nkZv3aXXmylVcvX4hUUUsao0lSlG69Uv5vJ/zfh56TPC3n7RP9V9npfy/E/Yr
4xfD25/bZ0z9v/Ufgr4ZvPFOgeP9c8D6N4fvNCsWXStY1W0ubY6n5U5CwuI2d55ZQ2xY5lmZ/LcS
HoNb+Jfwdv8AxT+3r8T9X8E6h8Sf2cNX1/wVp11/Y0s9jZa3dW88EWoPaXcLRpNNb3Fytx8ku2bz
YsyBLlZT+KtFbSzO75uXW7flrzaJW2953Wt/Ibwqty30tb8ut/LR9D9jvE/7Pfxc8L23/BQSPxL8
NbD4ya1rev8AhOOCy0fw3qVto3iKQXMd/wCVBDYSRXAmgsru0mljSdpU3hpZJQ7SSeG6n8NvjVoB
+Mfwz8U/sxweMPhhL8Rp/EF/8PfCOsWzeIvAGr6hpkr2M9o+l+ZKlulrcwLG9xZz2DGAxoiSmQD8
467P9nv9nvxh+1T8XtJ8B+AtHOv+LNdE5sbAXMNsZ/JgkuJP3kzpGMRRSNywztwMkgFTxvtZJRi2
79027uTt8N3v6PXTXROhaPvNWt2ttbXfTb/g6H3d4p/Z18VfBXU/i58B/C3w3vP2nvgB4V8ePM1p
4ev408YeG9al0gxpcbtP82dGgD+Q8l3ZzWTzWUyLFDK0qL86fHT9nDw/+yd/wVQb4b+GPEvgrxZo
Hhjxnp1ra6j4wlibQsNJBI0GrNCxQwQO7QXRXbxDN8kZyi/NNFY1MVBxtGFtbrXZa+6tNtVvfVaW
uzVU5Xvfp/T3O1/aS/5OK8ff8iV/yMeo/wDInf8AIu/8fUn/ACDf+nL/AJ4/9Mtlfa3/AAQq+369
4Y/aP0vSPhHpvja8T4Ta+JdRSHVp7zVDcLarb6G629ysPlzvBI6iKJLxiJdk4CgJ+elFZ4fEeyrq
s1ez2CpS5qfIfov/AMEUNan8bp+07B4e+CXhzXJLv4YeJJF+xx67dSTi6+zfZvDqBL4gwSGGQx4B
vn2SYuW2nbH/AMEWfEj+K4f2nItD+CnhrWWvPhj4kcNaR67ctKLr7N9m8OqEviPIkMEhjwPtz7JM
XLbfl+Evg18GvFP7QvxQ0XwX4K0O/wDEfijxDcC2sNPs03STvgsxJOFRFVWd3YhERGZiqqSKXxG+
H2sfCX4ha94V8Q2Z07X/AAzqNxpOp2hkSQ2tzBK0Use5CVba6MMqSDjgkc11UMY6cac3C6g3r3b6
baW7a+hEqEJSkm97fh8z79/4Iqaqnju2/ahh0n4LeHdWef4W+JZ4ZLJdankka6Ft9l8PLi+IMEhh
lMYAN/JskAuGAO13/BE/WJvG8P7UMegfBTw1rJn+FviWcvaR67dNIt19m+zeHVCXpBgkaGTy8D7c
2yTFyQpK/C4+A/ihvgG3xOWxtG8Fp4gHhd7wajbGePUDbG5WJrXzPtCo0SsRKY/KYoyhyylR6HZf
8E2vjRd6dFqEnhCDTtGk8M6X4wk1nUtc07T9ItNM1ORo9PmuL2edLa3e4dXEcMsiTMY3wnyNh0MZ
NKlaF+Rv53+Xr39NCalGL5k5b2/C3n6H1B/wRV1e48ar+06vh/4LeHNYEvwu8SzMbRdauPOW6+zC
28PDF6cwSNDIYgv+nuVfFw235T/gih4gk8Vw/tNwaJ8E/D+vtd/C7xK4ezTXLh5hdLbm28PgJeke
Q5gkaPC/bn2SYuTt+X5y0/8A4JW/HK8tfiBPc+FdF0OH4VarFo3i19d8W6Noy6DcTbfs5mN3dxYh
uNw8icZhnw3lO+04474yfsSfFD9nzw34h1Xxn4Wfw/beFPE6+DtVjub+1N1Z6k9s11Eht1kMxhlt
0aSK5VDBKqkpI1OnWq0lTc6btBvyvfptpaz7/gDjSnzR5lrbr93XzX4H15/wRV1r/hMYf2mINH+C
nhzXWuPhh4klWS1GtzPKblbc2vh9dl7jyJDBKYwo+3SbZALhsfLL+z1Dc/FT/gjH4gs/Cfw9g+LW
rL8eJNTf4YWaahfWvhezl0LCapHFYTpqoV2RrYSXdzLAVtgFHmiV2+HP2hP2e/F/7K3xg1jwF480
kaF4s0Awi/sRdwXfkGWGOeMeZA7xtmOVD8rHGcHBBA4ysvrbpqNOcdYuV/npa1tLdnf0NPZqV5Re
9vwP2b+Evw+1nxv/AMHVfiLxF4cn8ReOvDnhO/mXWPEMFul1b6LK/hmaFLO5mt40ih8udHs1WUrI
TblHZ5Q7H5v+Bf7NHiP4a/8ABMDxHeeEvg6uuftK6Z8WodN8Q6Tq/gS38T63pPhiTQlubV30m9t7
g2cEly0jC5+zx+blV81wgVfz0oqqmYKbbcftSlv/ADW8t1bR/gZQwrSte+kVt2+fXsfqp/wT70zx
B/wvn9sHRNQ/Zw+HVn4mtPh34ij1aw8KHVryyt76eC2KeHUFnqM1vFHNLbXD+RBtuUkFxFHLEkXl
Reb/APBN/RPGmtf8E+f2wPE/gP4eC+u9cv8Awxb+H9FtvCreJNNmmj1R5rm0gt72O6W5FtbzRsVl
MssayQyMSTvr886KlY6PurldlzdVf3vO3T8eyNFQSvrvb8PmfrR+0R/wT5s9e/aX+NviDwvonjLx
p+y74B8cQx6d8MPh9c3V5/wlPi5tItJby1jtrVZU02GF5WW5umjTyov9GtwZAEi634nn4l/GT9jf
xbYfGj4K6p8ZPitoH7RI8QeNPh/4Wvt1zFpt54Lig0x/M0xri5htYhFD5crZWUxFDJJIJiv41UVs
8zjzOUIWu27XTWt9LONmlfRPTfTXSFhpJW5tkltrpbz621/4B+7X7UehWviT/glb+z/4Fn+EfiL4
7678NNU8N3Xjv4d6Ld3NvrekfaPBjw20dylqsl5YokixynfAqO4ZQzM0oX82P+Culr/YPjz4JaBd
m6tvEHhf4M+FtK13TLoNHdaJfJbyM9pNEwDQyKjxuY2AI8zJHNfJlFY4rHRrU+Tktrfp5+V+ve3Z
as0p0pRd2/w/4IUUUV5xuFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfdv/BtB/wApr/g5/wBcPEP/
AKjup1/WXYf8ekf+7/Sv5NP+DaD/AJTX/Bz/AK4eIf8A1HdTr+suw/49I/8Ad/pQBcg6miiDqaKA
Pjj/AIOjv+UFHxz/AO4B/wCpDplfzh/8Ea/FWnWvxR+M3g2a/tLTxD8WvhB4i8DeFbe5uI7aLVtZ
vFg+y2ZmlKxRNKY2VTI6Bn2ICWdVb+jz/g6O/wCUFHxz/wC4B/6kOmV/IFW+GreyqKpa9jOrTU4O
D6n35+yVpB/Za/4Jy/Ejxd8cvD998QPhNc/ERPA1v8JLq6m0u6s/FtvBDdT6nLOV83S2js0e2LW6
tNcEtDKqRxhq+pfFvwT8e+KPgL+1R4z0/wCG83xQ8JfFfQvAOv8Aw58NRaDf29smhtdvJaaKlvpj
w7ZtPs5IGkitZWA8tZHZhI+/8XqK6aOOVOKhy3Sv23aavt0votvLVmUqDcnNPX/hvPy/qx+zGrat
Yfswf8E0/iT4C+Nfw903wP4I+In7Tl1pPinw7putRz3XgTTtR0Sw1O2uLN7GNonaz8qzlRQjxzLb
yQmGMklfLP2u/AfiLx1/wc1Xl7a2KxweB/EnhrxTrt9JdIlpo2kabYaZcXOoXNxN5ccUSQRb2Zyo
3MqKWZl3fl1RW080vCNPl0Uk+l9HJ2ei/m7WWumpCwr5nO+rTXlql5+X9dfT/wBtz4iaP8Xv2z/i
74s8O3n9o+H/ABR411nV9MuvKeH7Ta3F9NLFJskVXXcjqdrKGGcEA8V9U/8ABMz9n/xr8dP+CYX7
XWh+EvCesa7qXi658GaVo5gtn8u8uYdZEs8SykiIeVFIkspY4ijxI5RMk/A9FcNOtFVXUqK976J2
3+TN3S9xQi9rfgfsl+39b6F+0joHxq+LP7Ofhrwv8ZPiNcfGLTvC13LYeF7bxtcwaBa+FLaOOWOy
ubW4WG2e/gvFW8jQLO0GEkdI1Y9d8XP2ev2Q/wBnC6+KGv8AjTwT8N7n4f638cj4F8QXVrJeXTeH
raHwnDqoh08WWZ7GT+2vOikFvhQpmt2RY4gI/wAP6K75ZrzPnlBN3vrqr+90t15tddbLytzrCNRU
FLRK3n06/L8T90/2jfB/h/xX/wAEyPhHcaX+zro3xHttf8Z6J8RPEvwt+HF3e2BlTUvBJgj1Bra0
gafToWu4mVTGZIpTpzZfzZJwPzb/AOCucF3o3xP+D+hapYrpWueGPg54R0nVdPlnlN7p9zHp4Lw3
cEiKbWcBlzDz8hjckNIyj5QornxWNVaHLy2d79PPy8+/TzZpSw/JPnv08/Lzt+H5H3T/AME8dX1n
4Xf8Eqf2xPGNrounzQq3hC0sLzWNDg1TTZrhdVKzQ+TdxyWszrFco5V0Zoy0TjadrV9t67/wTs+G
vwg/bJ+KfiXRPDfhTWvD+n/FDQ9F8S+Cxp+hNpngXQG8PQ6zf+ILybUrO7a00+RpL2NYoBZrm3aO
KYssUcX4d0VeHx6pxjGUb8rT37c3l1ur+n3Kph5Sk5KVr+Xp5+T+8/UTw7+yha/CG7+P3hTw38EP
FK6x4V+MU+m2Wu6V4E0j4n6nY6Ebe6ew099A1SZLi1tpY9lzHqm1kugNm/MXzfFn/BSr4cRfCP8A
bs+JnhyJPAEQ0zVyjx+CopYNFhkaNHdIoJZZWtpFdmWa2EjJbzCWJMJGoHh1FY1sTCdPkjC2t9/X
S1vP8PuunSlGXM3fS39a/gfpp/wTI+H/AOzZ4M/4Jq2/j747+FvC+raT4x+Ms/gfxLrGow31xf6J
pVv4e/tOyayNkftFtJJqChHeIfvY3dHyq5T6ds/2Kfhtr+n/AAs+OOm+AfAK/wDCyrHwje+PvBWl
6PoVpoHgnTZNKuNRvPEd0dTtbz7FprpHNCI7c2nmtZSD7S9wwCfhdRW1DMFCEYSgnyu91o3vu7dL
6GcsNLnlUjLV/NLbpc/S3xV+x98Pfhb4A+Nnh74x+Fofhb8IvCnx1/snwr4v03TftHi93kaMtpTC
WKS5k0v+xmW9jllaMByJYlvndoK2v2S/gRe+If8Ag4o1fwP40+C3wy0zRgL+LWPCOneH7XWfDml2
CaTvsbgB4SsXmSCwkacRwOZbhlZITK8A/LiirjmMYuLUNFJS6bK/u7ba/ne+lrnRlKLi5bq34LX+
v+H/AE//AOCdnwe/Z++DH7AUniP9pDwHpHl6/wDGu++HnjO+1yx1A6t4XsrLQPt9rFbpakXVnO2p
KYpWRQXjMscgKrlPov8AaC/Zu+EfxK/Y9/Zt+IPhz4SfDLSNf8QfEXwZ42+JlvoXh6CO18P6BdaO
rXc90pVzZ6IzwS582QWpaCdm/eLO7fhrRSpZjGEIw9mvdd+l3vu7ef599JlhrzdTmd3b008vM/ZD
TP2dv2cv2b9H+Lmq/HP4feG9J8M+If2k9f8ABWp3F9pV2l14e8Pw6S+raQdPgslWe0jmuGgAktgF
mtpSpBjCsvxH/wAFfvCnhrTfiv8ACXxN4b8H+HfA5+JHwm8OeLdV0vQbE2OmJf3MMgleCDcViQiN
MBeDgs252dm+S6KyxGNVSl7JQS1vdb7vd21Svp/SVU6DjJScr6W8vU/Qf/giv8dfBnhfVPCPgHw9
Z/EfQ/jl4t+Jem3Fz4h8NaJDqi6v4YgNvNJo8rtdRTWVuZoZri5ngR90EeJVkjTaPnv/AIKv+Fh4
Q/4KW/HO1EOuQC48aalqAXVtNOn3B+0ztcbliLuTCfNzFLkedCYpdsfmbF+fKKmeM5sNHDtbO9/0
t+pSo2q+0v0t+X+R9w/sn211+2z/AMEvtR/Ze8C/Zbj4vaf8VB8SNJ0a+vo7NfE1i+kiwuIbKSTb
F9pt/LE8iSyR7oA7JuMTrX05+3P8QdH/AG1P+CUXhb4DfBnUrf4qeP8A9nvXdCHiGx8NLPcvq1tb
aCumXGp6bEyLJfWaXbJCZYlZwBvaKKDy5ZvyCoohjOWnycvlfy1/HV669NNNVKi3NyT/AK0/yX4+
Vv0+/Zy/Zn8V/CH9gj9t7SfiZoniTx8mgW/gfTdT/wCEZ1UzSRvp7C4utOj1IwXMKPpUD26XUYil
SBbcplFEclXv2lvj744/4K3/APBMbx/4h8MeCLnWPFupftD2+u3XhXwsLjWb/RtO/wCEWi0+0mmt
44zII2FosZuTtSaZJAqR7QlflnRWrx65VTs+XXS6vrzW1t05vP8AEz+rauTeunT/AA369eU/aj9s
+x0b4yftIftG6n4W+HupeLPE0XjvQLG78XeFfAWgfFe7toY/DkUMulS6Pe3Ky6ciXccp+2RqRLKk
lu7I9qEP5j/8FJ/h7b/Cn9uv4meHrb/hXwj0zWGjK+CYZrfQ0cojOsME0krWzh2YS24dkgmEsUeI
41A8Pop43MI4hP3LNyb37tu1rLvvvpr5XRocjWuiSW3ZL/IKKKK8w6AooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooA+7f+DaD/AJTX/Bz/AK4eIf8A1HdTr+suw/49I/8Ad/pX
8mn/AAbQf8pr/g5/1w8Q/wDqO6nX9Zdh/wAekf8Au/0oAuQdTRRB1NFAHxx/wdHf8oKPjn/3AP8A
1IdMr+QKv7Gv+Dj34X+Jvjh/wRk+MvhXwV4d13xf4n1P+xPsej6JYS6hf3fl67p8snlwRK0j7Y0d
22qcKjE8Amv5Yf8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU
/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat
/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL
/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6
P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8A
Dfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dq
f9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/
AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx
8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXv
n/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG
+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8A
Rtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4
HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5
/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/t
Rf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/y
PQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCj
bfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4
dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9
q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai
/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5
Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/
AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6
n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+
1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2
/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V7
5/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+
f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tR
f9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0Ae
B0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o
234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4d
T/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8
j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9
qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5H
o/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Df
at/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8A
Dqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1
b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8f
P/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe
+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f
+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0
bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AH
gdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o2
34+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+
1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8A
I9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBq
L/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8A
h1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfa
t/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op
/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR
6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP
/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+
f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b
/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0b
b8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHg
dFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+
G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1
F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI
9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o23
4+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU
/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat
/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL
/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6
P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8A
Dfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB7j/wbQf8A
Ka/4Of8AXDxD/wCo7qdf07ftQftUx/smeCNI1u88BfEHxrpuoXIsppfC9rZXH9mSNtERuBcXUBVZ
GYqrqGXcArFS8Yf+en/g3q/4J7/Hz4M/8Fe/hR4k8YfA/wCL/hTw7p0Oui61TWfBuo2NlbGTQtRi
jDzSwqi7pHRFyRlnUDkgV/TzLoi3NjJbTWUs1vNGYpIpLVnSRCMFWBXBBHBBoA5v4SePpvid4Ktd
am8OeIPC32wbksdaW2W7CYBDkQTTIAcnHz54zjBBJXV/ZZNxPkXZJ/6d3/wooA47x9PpPhuXXNW1
a6stM03TvtF5e3t5OsFvaQx7nklkkYhURVBZmYgAAknArzP9lf8AaE8P/tdfDe98YeHNM1C18Mtq
s9hpF1fIYZdYtokjxeCFgGhjkdn2I/z+WqM4RmMaeyazEy69eMroD57kfNyPmNc14C+GOi/C7QpN
L8PWNrpOmPcyXSWcGFgt2cLuWJQMImVyEHC5wuFAUAGAfCXhzXPilrcWvaTo+q21lo2nSW0eoW0c
6QvJPfh2UOCAWEaAkf3RV/8A4Vz8Nc/8ih4H/wDBXa//ABFcp8YP7T0Lxte3NtYX13DqWmWVuklr
aTXIVoZrxnB8pGIOJo8ZwDk+lcX/AGxrf/QJ17/wS33/AMZppAev/wDCufhr/wBCh4H/APBXa/8A
xFH/AArn4a/9Ch4H/wDBXa//ABFeQf2xrf8A0Cde/wDBLff/ABmj+2Nb/wCgTr3/AIJb7/4zTsgP
X/8AhXPw1/6FDwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3
/wBAnXv/AAS33/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3
/glvv/jNH9sa3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A
4ivIP7Y1v/oE69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/
AIVz8Nf+hQ8D/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8A
hXPw1/6FDwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBA
nXv/AAS33/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glv
v/jNH9sa3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivI
P7Y1v/oE69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz
8Nf+hQ8D/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw
1/6FDwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/
AAS33/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jN
H9sa3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1
v/oE69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+
hQ8D/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6F
DwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS3
3/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa
3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE
69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D
/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/
AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xm
iyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0C
de/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4
Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDg
rtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/AOCu
1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xmiyA9
f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0Cde/8
Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4Jb7/
AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDgrtf/
AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/AOCu1/8A
iKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xmiyA9f/4V
z8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0Cde/8Et9/
8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4Jb7/AOM0
f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDgrtf/AIiv
IP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/AOCu1/8AiKP+
Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xmiyA9f/4Vz8Nf
+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0Cde/8Et9/8Zos
gPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4Jb7/AOM0f2xr
f/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDgrtf/AIivIP7Y
1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgG/Hj4oeFfhH4t1jTdL+DXgDxDDpmh6Zqs
Vw8tvZ/aJrzVv7PNvtFpJtEaZm8zJLEbNgzvHb/CSHwJ8RtL165v/hv4F0X+yfEWpaJbqLa2uftk
VpcNCtwSYU2GTaW8v5tvTe3WvOdY0BPEs802o+GNfubi4t7a1lcaVfLujt7k3UQx9nPSU5+n51et
Li+0m0khsPD+vW0c95c38v8AxKL5t808hkkb/UDALE0WA9i/4Vz8Nf8AoUPA/wD4K7X/AOIo/wCF
c/DX/oUPA/8A4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz
8Nf+hQ8D/wDgrtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17
/wAEt9/8ZosgPX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4
zR/bGt/9AnXv/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2
Nb/6BOvf+CW+/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX
/oUPA/8A4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+
hQ8D/wDgrtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAE
t9/8ZosgPX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/b
Gt/9AnXv/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6
BOvf+CW+/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUP
A/8A4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D
/wDgrtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8
ZosgPX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9
AnXv/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf
+CW+/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A
4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDg
rtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8Zosg
PX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv
/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+
/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X
/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/
AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+
Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLf
f/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDj
NH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCI
ryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/AIij
/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+Fc/D
X/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLff/Ga
LID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDjNH9s
a3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCIryD+
2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/AIij/hXP
w1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+Fc/DX/oU
PA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLff/GaLID1
/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDjNH9sa3/0
Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCIryD+2Nb/
AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/AIij/hXPw1/6
FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+Fc/DX/oUPA//
AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLff/GaLID1/wD4
Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDjNH9sa3/0Cde/
8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCIryD+2Nb/AOgT
r3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID15/hz8Ndp/4pDwPx/1C7X/4ioPhLommJf8AiyCx
trS20+11dEtoLZFSCFTYWblUVeAN7scDuxrydtX1sqR/ZOu8/wDUFv8A/wCM16j+zdZXdv4e1ue9
t7mya91NZY1uoXt3dVs7WItscBgN0bAZA6UmgO5/sO2/55ij+w7b/nmKuZX/AJ6Rf99CjK/89Iv+
+hSAp/2Hbf8APMUf2Hbf88xVzK/89Iv++hRlf+ekX/fQoAp/2Hbf88xR/Ydt/wA8xVzK/wDPSL/v
oUZX/npF/wB9CgCn/Ydt/wA8xR/Ydt/zzFXMr/z0i/76FGV/56Rf99CgCn/Ydt/zzFH9h23/ADzF
XMr/AM9Iv++hRlf+ekX/AH0KAKf9h23/ADzFH9h23/PMVcyv/PSL/voUZX/npF/30KAKf9h23/PM
Uf2Hbf8APMVcyv8Az0i/76FGV/56Rf8AfQoAp/2Hbf8APMUf2Hbf88xVzK/89Iv++hRlf+ekX/fQ
oAp/2Hbf88xR/Ydt/wA8xVzK/wDPSL/voUZX/npF/wB9CgCn/Ydt/wA8xR/Ydt/zzFXMr/z0i/76
FGV/56Rf99CgCn/Ydt/zzFH9h23/ADzFXMr/AM9Iv++hRlf+ekX/AH0KAKf9h23/ADzFH9h23/PM
Vcyv/PSL/voUZX/npF/30KAKf9h23/PMUf2Hbf8APMVcyv8Az0i/76FGV/56Rf8AfQoAp/2Hbf8A
PMV5X8ZP2nPDXwI/aB+GngXXNNuxF8SrbVZINWjbdBpktk1iFWdMZEUn2wgy5xGY13DYzPH7AAp/
5aRf99CsLWfhhofiL4jeH/FV9BFcaz4Xtby006RnUpAt01s0rYxnd/oseDnA54JwQAdn4Z0yCz1m
zKQxo4dhuCjP+rfvXY1yXh+ZH1izAkRm3scBgT9xq62gAooooA/E39qzWdOi/ai+JKv4V8BXDr4p
1MNLceE9MnmlP2uXLPI8BZ2PUsxJJySSa4OPVdLm3k+E/htFHGjSSSSeENISOJFBLOzG3wqgAkk8
ACt79ri62/tW/E4Z6eLNV/8ASyWuX0fxnYfDkQarfRpK1oI7uGJwCs9wXbyAR0Ii8sylT/G9s38B
B+1o01KKSXQ+QxFVxbbfU9g+HP7Mi+MdOjv9X8P/AAt8I6ZKA0cmqeAtOuL+7U/xR2axRGFCOjzy
Bz3gAwT1x/Y6+FZOf7YtvMx0/wCEC8KeRn12/wBmb8e3mdO+ea+ZNV+LPiz48eIorDS9UurbLB7m
WM5Zs54yc+3513uh/BbxV4J13QLJNbv5rrxBcPDHHO5kGEieWR8HsFQ9+rCvgc58Rcqy3OlkmIv7
TraMWl7vM731do6u3nZH3OE4BxmI4d/1jlXhGDUnGLlNSkotx0srK7Vo669WdV8Sv2XF8JadLf6T
4f8Ahb4u02IFpJNL8Badb39qv96SzaKUzIAOXgkLjPEBAJHkM9xpULL/AMUn8N5EkRZI5I/CGkOk
qMMq6sLfDKQQQRwQa6Xx58TPG/wa1RBcQRI8cgxPHcMEHP3sYyPWuX1bxxZfE6yfWbKNIGvVe8ni
RQqwXAZfOAHYS+YJQo6Oly38QA+uy3NMDmEHPBVI1Erax2176Wvpt+B+e08VefJdprp2EN/pWf8A
kUPh5/4Ruk//ACPU9rc6RIRnwh8Oz/3Julf/ACPXM/bvc1Zs7/BHNehyx7HVzy7nY2dvoU2N3g34
dn/uT9K/+R66Hw/4K0XXmZbb4f8AgS7aMZYQ+DNNcqPU4t64XTr/AJHNfb37Fn7Po+JX7NeobtM/
taw8TXBjvo5D5YAhlyirIs0TjlAxAJ/I4r5/inO/7JwP1mlSU5tpJebu9bJu1kzpweDr4pzhRa5l
FtKUnFN9E5JScU20m1GTS1UXsfPdp8JdFOPN+Gfgpfr4L08f+29Wk+Gfg6F9k/w9+H0b4ztbwlpy
n/0RX3f4y+H/AMTbr4QWvhLw1qF94Wg0mwh07S5rLyT9jii8tVDhrotN+6Qp87fxljk4Ncd8Rvhv
baB8O7VdW8Fadq/jSz0uBLnVNY1cxNr9wqpE8kQ+0pDExIeQqXIQAKAcivj8v8R/a4iNGth1FOyv
L3FzOytzSvBK+8pyiktW0fQ4jhlU8D9Zdf31e8I802kldtJRTl2SinNtfBqj5I/4Vl4H/wChB+Hf
/hK6d/8AGaX/AIVl4H/6EH4df+Erp3/xmvp7TP2fPAd58P7C+v8AxP4P07XLu0inutMfzZHsZnUM
8HmpeiN/LJK7lGG2Z5zmvmvxTCnhvxNqGnpcpdpY3MkCzp92YKxUMPY4z+NfW5BxbhMzxlTAxpqM
4R5tJQmmr2dpQbW9uuzvseJmGU1sLQjieduMnbVSi1pfVSs/w0Ko+GXgf/oQPh2f+5V07/4zSj4Z
eBv+if8Aw7/8JTTv/jNQjVR/epRq2P4q+x9nT/lX3Hie0qfzP7yYfDLwMf8AmQPh3/4Smnf/ABmn
f8Kw8Dj/AJkD4d/+Epp3/wAZqEat712ngPS9Fl8JXmq6tBNcbLlIURJpFaTI+4iq6jJ5+gBJwATU
VXhqNOVataMIq7bskkt229kuooyxE5wpUk5Sk7JK7bb2S830OTHww8DEf8iB8O//AAldO/8AjNOH
wu8Dd/AHw7/8JXTv/jNdtrOh2/hyS3Oq+CG04XUS3EUdxqN9E80TDIdSXUMD6gYrVh8J+CPF3wu8
Q6hY6ddWOr6XplxcGH+17tzC6xMVcAy4Ybh3HbkEdfmcg404bzrFywOXV4zqx3i4uL9VzJXXmrnu
59wxxBk2Ejj8ww8o0pfaUoyXo+Vuz9bHmw+FngX/AKJ/8O//AAldO/8AjNPHwr8C/wDRP/h1/wCE
rp3/AMZrQ8aaTF4L8SSWUE1xLBm4K+c4Zl8u+u7dRnAJ+SBDzk5LdsAZyatz1r62dCnGXK4r7j5y
hi5VaaqRbsx6/CjwKf8Amn/w7/8ACV07/wCM19E/sO/sDfs/+Nv2KPg9r+u/Av4M65rviLwPour6
nqGo+CdMu7q9urmwgnmleSSFmJaSRjycAEAYAAr53TVfevr79h/xCNK/Ym+CVoWx5Pw58NLj/uEW
leFnFKN4KK7/AKHu5XUlabk+36mw3/BOT9mwf827/AX/AMN7o/8A8j1zXxG/ZD/ZI+EmnR3XiP4K
fs66NFMSIhceA9HV5iOoRPs+5yM/wg11/wAd/jxF8GvhfqmvFUnubePZaQM2BPO3yxoe+NxBJHIU
E9q/HLV/jj44+OXxhuH1h9R13xhqd0bX7OimRw+44hiQfdQHoowAOfU1+fcQZ9DL3GjTjzVJa27L
u/Xoj9m8K+AqPF2OxGHq4pUlQipyWnO4ybV1fRRVnzSd7aaan6Nt4b/YdMqqPhP8A4t/AaT4X2MS
fizWQA/E16Bo37FX7M/inR4dQ0j4Hfs/6jY3I3RXNr4E0aWKQdMqy25B5r89pf2YPitq1kRBpulX
EwUs1vBrlnNOAOvyJKScd9ucV137Jfg747fs9/Eu3vbfR5J/C99MF1fT/wC0YfLljPBmRS+BKg5B
43Y2k4PHytfxGoZRiYUOJOTDqeq5vcdu9pvVd7H3md+D/D9bL6mK4bzaFWpTv7rq05KTWvKpQtaT
6Xum9NFqvt2X9hT9n6Pp8BfgaPp8P9I/+R64P9oj9i74I6H8M0v9L+DHwg0y9tNd0NVls/BemW5a
ObWLK3mjfZAA8bwzSqUbKnd0yBXqUPixZ41kV9wcZB9a5T4+68Lj4QX/AM2dmraC35a7p1fsEKMN
JLyP5mdaWqZ8u/tR/syfDPRvixpOjaZ8OvAGl6T4o1TwXZXttZeHLK3Qx3fiQ2V0E2RAxmS3+Rim
MivrmL/gn7+zfgD/AIZ8+BeB6+AdJJ/M29fOX7SN4L744eATwc674Gf/AL58Wk/0r6hh8cZ/jrav
h1JpW6fqzKjXcU3fr+iMTVv2Dv2adH0+e7uvgJ8BbW1to2lmml8BaOiRIoyWZjb4AAGcmvANe8Q/
sZ6VrL2tv+zz8LL+JG2/a7f4Z6KITzjI3xq+O/3a7D9v/wCIF2vwJitrWZ0jv9ThguQv8cYSR8H2
3on5V83fsp/s66r+1Z8YbTwpplzFYK0T3d5eSIXW0t0Khn2gjccsqgZGSwyQOa/SeEuCsqr5ZUzX
NZNQjfbRJLdvRtvsl+Nz8E8SfFDiDA57R4e4epp1JKOrV3KUnpFapJd2/wAEtfdF0z9jC7EYj+E3
wOieQD5X+GFiuwnsT9jxx9cV1+jfso/s5eLNMW90f4M/Aa/tGOBLbeBdGkXI7Ei34PseaqD9hz9n
bVPHMvgGy+L+tp4+jmNltljja0+0jgxj9yqM27jYJ92fl6189+PdF8T/ALC37Q2qeHmv4rubTHj8
4wMVg1CB0EiFl/hJVhweVOcEjk60+DMlx/NRyqdSNZR5lGrDl5o94txjprvqYS8U+JsolDEcRUaM
8M5+zlPDz5nTna7jJKc/eSTbjps7O+h9G3H7G3wNjPy/BD4KL9PAOkf/ACPVY/sf/BNTx8FPgxj2
8B6SM/iLer+geOYPE2i2moW8haC9iWaMt1wwzg+9Xl1sZ6j86+ElgYwk4Tik15H7hSxzqwVSnO8W
rp33T2Z4J+zn+yp8LPGv7Xek+GNf+Gvw+1jw5o+l+NLuHT7zw5ZSwSPaa9p1namVWjxL5UFzKqiT
djdnqAa+tR/wT3/ZvI/5N7+BP/hAaR/8j18+fs6Xgs/20J7nOPK0Pxwmf97xPo/+FfUSeMQQPn/W
vMr4dSm3bt+SPSo4hxgte/5s5uX/AIJ8fs4p/wA2+/An/wAN/pH/AMj1Uuv2Av2dYhx+z/8AAsf9
yBpH/wAj15J8VbIeM/ixrOLHQrueXV5ImuNS06C7W1todL0+ZiWkjcpGgeaQ7fVjgmsa58IeH9W8
LPd6bZeHZ5yWMXm+GNPhEyqOTsERKgkHBJ6DJC5IGOeVMqyTD4fFZrXVONecaafK2lKabXM1svde
r076XtyZbjcwzPE4jC5dQdSVGMptcyTcYtJ8qe795afra/r95+wl+z7FnZ8BPgcv08AaR/8AI9Zd
3+xH8Bovu/Av4Ir9PAOkf/I9fPraVpN9ptnNcL4D0tr+eW3t1uPD8TNM0SxM+PKtXAAE0f3iM546
VyXxc8KWngm88RaXJe+AptY8P6Zb6re2VtoYWWK2uRbmKQO1osZyLuA4D7hv6ZUgfe0uCFdRc1r/
AHX3S9N2l6nw0vESD5lGm247rmV1dXV1vqldd0fUE37GHwOj+78EPgqPp4C0j/5HrkPjp+yB8HdO
+CPjO8074RfCbTdR0/Qr69s7qy8G6ZbT288NvJLG6vHCGGHQcZwRkHINXf2WNXA+B2koJGZIri9i
jy27CLeTKgyecBQAPYV0Pxh1ETfBfxsmTz4c1P8A9I5q+dr4GnSlKFlpfp2PscPjZ1Yxnd62e/c4
ZfgF8Pcf8k7+HP8A4Sun/wDxmnD4A/D4f807+HX/AISun/8AxmugW4p63HNej7Cl/KvuOH21X+Z/
ec8PgD8Pcf8AJO/hz/4Sun//ABmg/AD4ff8ARO/hz/4Sun//ABmuk+0UCeq9jS/lX3C9tV/mf3nO
D9n/AOHuP+Sd/Dr/AMJXT/8A4zR/wz/8Pf8Aonfw6/8ACV0//wCM10onyKcJRR7Cl/KvuF7ap/M/
vOY/4Z/+Hv8A0Tv4df8AhK6f/wDGaP8Ahn/4e/8ARO/h1/4Sun//ABmup833pDL7mj2FL+Vfcg9t
U/mf3nL/APDP/wAPf+id/Dr/AMJXT/8A4zR/wz/8Pf8Aonfw6/8ACV0//wCM11Il96PN96PYUv5V
9yD21T+Z/ecuP2f/AIe/9E7+HX/hK6f/APGacP2ffh4f+adfDn/wldP/APjNdOJfcUvmUKhS/lX3
B7ep/M/vOX/4Z8+Hn/ROvh1/4Sun/wDxmqOrfs7+AmhPl/Dz4dg/9irp/wD8ZrtxJ7mjeD1o9hS/
lX3IFXqfzP7zx66+Cfg3Sbksfh78PGQf9Spp3/xmut8DfDH4aahMkdz8Ofhxnvnwrp//AMZrqNT0
yO7iI2jJri9U0m5029aS3yPTFZ+xpx+yvuL9tOS+J/eeg6l8AvhQLDevw5+G4P8A2K+n/wDxmvJv
E/wl+H1trLpD8P8A4dbB0A8K6d/8ZrbjutVu4QhZwPrTbLwXPc3fmSsxJpyp03tBfcEalRbyf3jt
A+Bnw/vLRWb4efDok/8AUq6f/wDGa0T+z98PT/zTv4df+Erp/wD8ZroNG0/7DbKvpV2qVCl1ivuJ
depf4n95yDfs/wDw9UZ/4V38Ov8AwldO/wDjNc74q+FXw60u3Yj4ffDlSP8AqVdO/wDjNek6mSLf
jrXkPxC0zUNQvZFQOVPpUTpU0vhX3Fwq1HvJ/eXPBfwx+HV7fqZfh/8ADpkOOvhXTv8A4zWr4w+G
3w2trVkt/h38OQ/t4V0//wCM1znhPwpqEQUnctdfYeDXncNMSxPrUxpQa+FfcVKrO9+Z/ecxoHwL
8FanOJG+H/w82N2/4RTTv/jNdVbfs+eAFjAPw8+HX/hK6f8A/Ga6PStKWxiCgdKvFwK0jh6S3ivu
M5Yip/M/vOS/4Z++H3/RO/h1/wCErp//AMZpD+z/APD8f807+HX/AISun/8Axmut8z2ppOar2FLp
FfcL29T+Z/eck3wA+H5PHw8+HX/hK6f/APGaafgD8Px/zTz4df8AhK6f/wDGa60yUxmx9aXsKX8q
+4FWqfzP7zlP+FB/D/8A6J58Ov8AwldP/wDjNNb4C+AM/wDJPPh1/wCErp//AMZrqyxNNJwKXsKX
8q+4r21T+Z/ecr/woT4f/wDRPPh1/wCEpp//AMZoPwE+H/8A0Tz4df8AhK6f/wDGa6kPSM2fpR7C
n/KvuD21T+Z/ect/wob4f/8ARO/hz/4Sunf/ABmkPwH8Af8ARO/h1/4Smn//ABmupJxSFgKPYU/5
V9we2qfzP7zlv+FD+AP+iefDr/wlNP8A/jNNPwI8AD/mnnw6/wDCV0//AOM11JfNITij2FP+VfcH
tqn8z+85Y/AnwB/0Tz4df+Erp/8A8Zpp+BfgEf8ANPPh1/4Sunf/ABmuoZs/SmF/Sj2FP+VfcHtq
n8z+85hvgZ4BH/NPfh1/4Sunf/GaQ/A7wF/0T34df+Erp3/xmumJzTS+OlHsKf8AKvuD21T+Z/ec
w/wO8BD/AJp78Ov/AAldP/8AjNN/4Ub4CP8AzT34d/8AhK6f/wDGa6cmkLgVLo0/5V9we2qfzP7z
mG+B3gIf809+Hf8A4Sun/wDxmmn4I+Ah/wA09+Hf/hK6f/8AGa6Z271C8lL2NP8AlX3D9tU/mf3n
ON8FPAYH/JPfh1/4Sunf/Gaif4K+Ax/zT74df+Erp3/xmujeWoZJeKXsaf8AKvuD21T+Z/ec7J8G
vAg/5p98O/8AwldO/wDjNRP8HfAoH/JP/h3/AOErp3/xmugkkqF5KPYU/wCVfcV7Wp/M/vMB/hB4
GH/NP/h3/wCErp3/AMZqKT4R+Bh/zT/4d/8AhK6d/wDGa3ZZcVXkmpOjT/lX3D9tP+Z/eYcnwo8D
j/mn/wAO/wDwlNO/+M1BJ8K/BC/8yB8O/wDwlNO/+M1tSzcVXlm5qfY0/wCVfcHtqn8z+8x3+GHg
kD/kQfh5/wCEpp3/AMZqCT4a+ClH/Ig/Dv8A8JTTv/jNa0s1VZpaTo0/5V9w1VqfzP7zKl+HHgwH
/kQvh5/4Smnf/Gagk+Hvg1f+ZC+Hn/hKad/8ZrUkkqtK9T7KH8q+4r2s/wCZ/eZ0ngHwcP8AmQ/h
5/4Smnf/ABmoJfAvg8f8yH8PB/3Kmnf/ABmtGR81XlbNL2NP+VfcP2s+7M9vA/hAH/kQ/h5/4Smn
f/GajbwT4Rx/yInw8/8ACU07/wCM1ec80xzzij2NP+VfcP2k/wCZ/eUW8F+Ex/zIvw9/8JTTv/jN
Rv4M8Jn/AJkX4e/+Epp3/wAZq+y5FMIzS9lD+VfcV7Sfd/eZt14R8JwxFv8AhBfh7x/1Kmnf/Ga+
fP2nfiJoXgnT7lbHwX8P4pEzgjwnpp/9oV9H3dv50JX1rx34u/s/L48nlLDIfNYVqKcbRSNaNVqX
vNnxZ4X+MGqeL/FkccfhjwOIX7Dwhpf/AMj19o/ALwpp19ocUmpeDfAMr8Z3eE9NH8oKx/hp+yJY
+FruOVoV3J7V7hofh6LRbURxqFArDD4SzvNG1fFX0iwXwb4Ux/yI3w9/8JTTv/jFL/whnhQ/8yN8
Pf8AwlNO/wDjNXvLx6U4R/jXb7KH8q+45PaT7v7ygvgvwoTz4G+Hv/hKad/8Zp48FeFP+hF+Hv8A
4Smnf/GavCP8KcsX40/ZQ/lX3B7Sfd/eUR4J8JH/AJkX4ef+Epp3/wAZp3/CFeFP+hF+Hv8A4Smn
f/GavrHmnLDR7GH8q+4n2su7+8oDwR4TI/5EX4e/+Epp3/xmnr4F8JEf8iJ8Pf8AwlNO/wDjNaCR
VKsWDT9jT/lX3C9rPu/vM4eA/COP+RE+Hv8A4Smnf/GaePAPhHH/ACIfw8/8JTTv/jNaSx/hTlio
9jT/AJV9we1n3Zmf8IF4QVc/8IJ8Pf8AwlNO/wDjNeV/tBa/4T8CaBcvD4I+HiSR9CPCmm+//TCv
aJYS0ZArxP8AaE+Ddz47t50j3ESZ6VnVpR5fdivuNKVSTl70mfC/jX9o6fWvGa2+n+GPAiRvnAXw
jpZ7j/p3r6h/ZN0GPxVp1vPqnhHwJNnG7d4S0wZ/KCuf+HX7CH2TXobm4hyV65FfWPwz+GNt4M0t
YY41XbjoK4cNhHzc00dmIxS5eWDNaw+G/hFYvm8B/D0n/sVNO/8AjNWV+HHg4/8AMh/Dz/wlNO/+
M1qLHj2p6p6CvTVGH8q+48/2s/5n95lD4b+Du/gL4ef+Epp3/wAZpw+Gvg0/8yF8PP8AwlNO/wDj
NaoT1pwX0FP2NP8AlX3C9rPu/vMofDTwZ/0IXw8/8JTTv/jNKPhl4M/6EL4ef+Epp3/xmtZU9aeq
5NP2NP8AlX3C9rP+Z/eZI+GXgs/8yD8O/wDwlNO/+M1X1PwB4KsbVpG8BfDzC/8AUqad/wDGa6EJ
7Vi+NrSS50WZI87j0xQ6NO3wr7hqrO/xP7z5O/a5+L/hfwBDdQ2Hg34eQyrnaR4U00/+0K+UfAvx
w1Dxv4vgii8NeBjDIeg8IaX6j/p3r3z9pP8AZ11nx74qchJGjfPatb9mv9iw+GJILi6g+dMckV41
ShKpU0VkerCtGFPV6nq3wB8Iafd6AkuoeDvAEj4GS3hHTM/+iK9KudE8O2g+XwT8PB/3KOmf/GKv
6T4ci0Cx8lFCgVT1UfNXoqjCMdkcLrSk9zJvJdFgzt8GfDsY/wCpP0s/+29Zdzq+mR52+D/h0P8A
uTdK/wDkerOpLjNYl4ME1DhHsUpy7lv+3NO/6FD4df8AhG6T/wDI9KNc07v4P+Hf/hG6T/8AI9Zd
FTyR7Fc0u5qjXdN/6FD4ef8AhG6T/wDI9B1zTT/zKHw7/wDCN0r/AOR6yqm8P6Dr/i+/WDRPCfi3
xAJJbqCNtG0mbVHd7WOykuAYbYSTKsa6jZZkeNYyZ1UMWDATL2cdZWQ488tI3ZfXXNNUf8ih8O//
AAjdK/8Akel/t7Tf+hQ+Hf8A4Rulf/I9Zl9Z3ekanNY6jp2q6RqFtgzWWp2E1jdQg5wWimVXUHBx
kdj6UymlBq6SE3JOzNb+3tN/6FD4d/8AhG6V/wDI9L/b2m4/5FD4d/8AhGaT/wDI9YtxcLbRhmDM
WYIqopZ5GJwqqo5ZiSAAOSSAKXUHbRb+5tNQjfTr2yvZdOuba5xHLb3UUrRSQMM/fWRGUgd1NFoX
toF5Wuara3pxbI8IfDz/AMI3Sf8A5Hp39vaaB/yKHw7/APCN0n/5HrJZtopbCyvdd1WLTtL0/UNZ
1S4VmhsbCBri5mVeWKovJAHU9PzFaU6PPJRhG79DOpWUIuc5WS8zT/4SDTh/zKPw7/8ACN0n/wCR
6bJ4h03/AKFH4d/+EbpP/wAj1iwNPqFnd3VrZX93Y6cglvrqC3Z4NPUkgNOwGIwSCPmx0OcYpnmC
QAggg8gjvTqYeVNJzja+2gqeJjNtQle29nsbLeItO/6FH4d/+EZpP/yPTG8SaeP+ZR+Hf/hG6T/8
j1jaTDqPizxGdG8P6NqviLVYwrTQWES7LVWV2UzTSMkMO4Rvt8x1LEYUE8VlS6rqVvqFxa3fh/VL
GazsH1W5WWa1Jgs01ttBac7JmJUamjW+Fyxx5gUxESVyOrSUuVtXOlQquPMk7HUyeKNP6Dwj8O//
AAjdK/8AkeoH8VWI/wCZS+Hn/hG6T/8AI9Y0kuBRo/h3xD4wW9fQPCvijxDBpxVbqbTdMkuEjdp7
OARJgZnm8zULMGGASShbhHKBMsKm4RV5WQoKcnZXNK48WWBU/wDFJ/Dwf9ybpP8A8j1RbxTYo+f+
EU+Hv/hG6T/8j1w0Xxe8MX1tHNF4i0Ro5kDoft0YyCMg4J9K0LbV4NUtEuLaeK4t5RlJInDo49QR
waLQe1h+8t7nUv42sl4HhP4ef+EbpP8A8j1H/wAJtZ/9Cn8Pf/CN0n/5HrmHuOetexfsAeL7zwr+
2F8P2svsgbUNatbGVprSG4ZY5JkD+WZFYxuQMeYm1wCQGAJzM+WMW0ioXbSucNH4zs2P/IqfD3/w
jdJ/+R6t2/iyzf8A5lP4ef8AhG6T/wDI9e2/sxeOfEPwo+JXi7xZLrl1oXw80DV5p9ahj+VfEs5M
oh0vaB/pBlBbKNlI0Mkh29Tufsk3sHhP4rW9to2l6xpNv4s8E6peakNW02AefILO9YGwmKGVbQ7U
AIYb2Rg27aMZuold8uxag3b3tzwO38SWLf8AMpfDz/wjdJ/+R6txeINPPXwj8O//AAjdJ/8AkevV
fA/ii81b9gXxxpcv2QWeleI9IMAitIonJkW8LNI6KHlPAAMhYgAAYAxXZfsXeJ7rwd+z5451C18c
f8K+8jxHobS6pi6bMY+1FotlvG7SbgPuMAjYwxAqnNJN8uzt+Xl5kRi20ubdX/rU8ATXNO6nwh8O
/wDwjdJ/+R6lXXdN/wChR+Hf/hG6T/8AI9fXcsmh/tE/s8a7oOgaWLJPGnjPWtR8L27IqvHeQw2s
0UQGdqmWIzptHAaRAOBXHfteJp+hfsseCvDGmeTJa+C/Ed/osk8YwLq5S3tnupM9wbiSUA/3VWlG
tFtR5dblSoySclLQ+eF13TR/zKPw7/8ACM0n/wCR69Ubx3pOgeFNCjGi+HXkbRrCaR5dKtpXkeS0
idmZmQkksxJJPevFF6Cs7xr4qnv7HRoI3ZVXRdMVipx0sYBirrQu0kRSnZNs93+Hvj/QfFPi64tL
vRPC8qx2zSeWNJtVKkMgz8qA9z+dFeF/B6/bRvE08q8FrVl6/wC2h/pRXNOk76M3hUVtUd1+2BdF
f2s/iiM4x4u1Yf8Ak5LXyJ+1V8btZ8N/FW58OW9ravYyQ2V7BO+7cpawtkcYBwRuj/PNfVX7Y90V
/a5+Kg9PF+rD/wAnZq+bv2oPhm/j3SNK8R2atJeaKn2C9RR8xgLlo5Pf5nZCf+uQ719DkHs3XhGp
1Vl66P8ASx81xN7WOEnUpfZd36ap/de78kemfsJeFLzxpe2y6j4q1jQ1viJz/ZQhglGcAfvHRz90
KcDHXvX2V4T8MeMPAv7Rd9fWi698Z/DXw/0RLNyotLbVtKm1HEpKr8iXrJFbRgkeW4W5xhsE18Df
BibW7Mx32l3FrbENvjhKswRey7sjoOOnavvn9kL9pvRPhZ8KtQt9bvntfEesalNqWoG5UxoxKpFG
EkIwyiKKMdcg549fm/HXIsBk2TLPsFlSxFeUlFuFLmmueL5pucFzpNXi23b3kn0R4Hhdxbic5zN8
P5nmTp04q8VOqox5YtcsIxm+W6dnZK9k33PC/wDgo58UNSvfhnfXlr4G8X+H0uGFqt3rlpFYhGc4
IWMyGRzt3fdXA65r5A/Zd+NuseIfidb+G57S1jsYob29nmTduYpY3KRjBOAN0n54r6h/4KUfHy2+
OiWNtY3QurDTjJPIyhghkI2rgkAHALdM9RXzn+zn8O38C6Tq3iG8QxXmuL9hs42HzCAOGlk9vmRU
B95B2ri8J8mq4PgqOPzHDfV6uIlOXI+bmSu4wvza3aXPslZ7dX62fVcOuK55fldf21Oko8004uLl
ZSlZx0srqO795bnqbah6GprXURxzXPNe1JBfYxzXu3PpOU7Ox1PGOa/Vj/gljfxr+xvYTSOkccWo
Xru7sFVFD5JJPAAHc1+Q9nqXTmv01/YA+IDeDf2B9PvEjjnKa8yGN+hzeQj9M5/CvjeOMMsVhKGE
k7e0rU43/wAV1+p6eVV/q/tq9r8lOUvusz6r174veF9KtEnl8SaBDby/LHI2oQ7ZW2I5CndgkLIh
OOgdT/EM8lqf7RvhW0DBPF/h+PPUDVYR/wCzVxnij9qrUviBb29voGmWw1K1hWRoHtopXnjMcLMy
tK6KNhmUEbsndkZwccN4p+OXjbw/pV5fajoE8FnZQvPPMkdogijVSzPhLongAnhSeOAa+Qxvh5kl
KusPi8wVCq9oyqU1LV6WTs9eltzBcY5g4OrhMM6tNfaUJuOi1u09LdbnqcXxw03xVLLHpXiGx1KS
IbnW1vkmKD1IVjivgv45ayp+M/iwqQoOr3RAHAH71q+l9P8AjdF4ueLT7w3EOp2urrDHHLJ5qkiC
637GwOykkYHQdcV8b/G/Wivxi8UZPP8AalwT/wB/GrbhThh8O8Y1su9q6ilh1NN7q9Tlt5/De/nb
odtTPXnGRRxcoKDVXlsvKN/luWP7ZA/io/tr/arjTro9aQ6+B3r9o5z5vkO0/tof3hXa6V4gfT/h
zZzZJiM102M/KXEagH6gFsfjXip1/nr+te6fBn+w/GvwPn0nUtStLaaa5LIDcKksLDcA4UkbuCeO
hDEZB5HyPHuS4rOeHcZluCdqk4K3S9pRdr/3kuX5n03BOc4PJ+IcFmOYK9KE3zdbJwlHmt15W+bv
pofp3d/Czw18Y/gPolj4nsLa7shpUEglkOyS0PkqTIknVCMdQe3ORxX51eP9I0LwP8VvGWj+EvEL
eJNDttIvES9VgVk3W0u5Cy/LJtIA3gYOzIrV+LHj34x/Gfwxpnhq91PRx4X0y2gstunXsdrbXioq
qJbgFvNkPGSu3ZkZVOlZ2hfDCH4e/DXXpp7kTX0mlXRco3yMxt5BwP7oBIXudzMcbgq/mnD+U4/M
uJsHilgJUI4Z+/VnFxlL3XHkivtRbe93pe1uv6dxRmOV5VwljcO8xhiJ4pWhRpyU4w95S55PeMkl
taLvZO+8eY+P199k8bpz977d/wCnbUK4pdb461d/ar8W21t46s0ilE5ZtQVvKIfYf7VvGGcdOHU/
Qg152viQH+Kv6BxM7VWv62P56yqH+ywfr+bO7TW/evq79m3Xjpf7NfwptwSBD4C8OJj6aRaV8Np4
kyfvV9d/CO+eL4B/DZYzg/8ACE6AM+g/sq1rx8c05R+f6HvYNNKVvL9TM/bw8eR6p4E0OySRm/4m
gaQg/LxDJgH8SK+YfB/gV/C+sfETxppCq2pjwpsaNQTKqi9tRPLEB3+ymUOR0iWQ9C1fS/xr+HD/
ABJ8A3VhEwS7jxNbOf4JF5H59D7E18x+GfiFfeCfEqpJLc6Lr2msQcMY5EPKkg91IJHoQfevyLiS
VbKc/wAPnip+0pxcW135XqvK+68/Q+RzzH5nlOPnjsHOUYVqcqU+XrGStKL/AAa815HPaB+0LqWo
avptvostxLq8lzGtiltlpmnLARhAOS27GMd6/S3xO8cesXp/dqgkYkKRsB7gY4xnPTivk79mLSrf
xH8SJNctdI8KaJBp43XV7p2h2lpcTyEECJJEjBiDAkv5W3cvytkMQfZ/GnxKGq3H9j6OwmvZ/lZl
5WBe7N/nmvwH6UHHMfEvN8s4U4bwcvaUpOUpO105pLl0vaKS5pNva3Zn7J4I5dLL8rxGe4ybVKpZ
RurXUb3la7vduy80zc0HXTLpqMpyu59pB7bjj9KxvjfrBHwa1hiT8uo6D+viDTB/Wrul6aNNsYbd
M7YUCD3xXOftASG2+Bett0/4mfhxfz8S6SP61/YuXYb6pg6OFvfkjGN+/Kkr/gfL15+0qyqJWu2/
vPOfjTqHn/G/wICeVvvCM3/fPiiY/wDsteqReNiq58wfnXhvxs1P7L8f/BaE/dj8MS/l4jvD/Ste
TxQ0w2h/l789a9umlJ3/AK3Z5tRtaf1sjY/ac8ZJrnwe1W3CLLtaF1c/wESpyPwyPoTXnf7CPx38
RfAD49w654d8O33itnsprbUNNs4nknmsyVeRl2AldhjR8kEfLzjOR0WsvF4g0a5sp+YrmMxt7Z7/
AIHmuJ/Zo/aH139hz47L4gtrCHUAbd7G8tJXKJfWzsrEK+DtO5EYHBwV5BGRX6hwniqdXKcTlagp
zldqDdlK6Stfpt+N/Nfzx4p5bXw/EeA4hdSVKlDljKpGPM6bUnJSceqfNtrezVnon9Ta14+/Za/a
21mS8g8J+N9N8d6zOGFpols0d9d3DuNzoFdrXduJYu+0n3YgV8zftNfs0+Lfhf4u1W/fRvG15ois
sov9W011ukVjtVZihdCw4+ZHZSCD8pyq+6xftn/s7al8TNJ8W+H/AAH4j8IfEG51qznk1Ev/AMS6
Hfcx/aC8aXGwhozIM+QPmYNwRuH6Zf6J4g0n/l3vrG+h/wBmWK4jdfxDKwP0INfmmY8YcSZDns8L
gZOFJU4ONPERdRWbkpcsozjJWcLKz5VGzcW2rfT5b4f5HxnlsqmJq0nWjN3q4aPJzaae0jKNnJ3v
LTyUtz8m/wBnHXxL8HNH2yrIFEoyGz/y2cj9Mfhiu7XWSf4q4qTwQPhB8S/Hnh6O2ks7XT/Et2tt
EzFgImCMpUnqDkkflV5NTPr0ranm8M1hHM6a5VWSny3vyua5nBvvFtxe2qei2PvOH8FVweW0cFV3
pRVO/fk93m/7etf5lL4M6h5H7SOtXGcGK08Yw5+vibTv/ia9m/4S8QpuaTAHvXzz8L9VEPxo8Uvn
lLjxhH/5c1t/8TXeya007ZY8dhWFGCkrvy/JH0FWXK7Lz/Nmbr/xPXw1431G/NmdQhuNZvLS4tS5
T7RBNpOnwTRhgCVLRu4BwcEg4NZOueP9C8D6LrFzoC+ML6/u7SfTEGqWsdtbaOlxG0cvMbv50jRM
6AkRAby20kAVh+MrPVX1q7NvpGsXYfUTfw3Fm1oVANtaRYIluI2DBrdj0IwRzXWfBP4XeOf2mvGm
paBqF7rGj6dqc6anrN3qLW0iyuoYK+2Kdy0h+YDOAOSfQ/SYzEUKOEo1k4NwceZSf2evKkm+ezkk
tL3tJ2bPhaeCxdfMK1FRklPm5Wl9qytdtpKN0rvW1rxV0jkfg3eQr4bhV/E+saKtxfTLcraeLrfR
lt0WODZIYpQTKXLSDcvTygD1rlf2kdcd/DHjywfxR4gv9G0wsuj3Vz8RLLVotfC3kUcbGwjUSx7o
S8w3H5DGAea9J/aw/Yo0n4Z6DPc+H9f1PUby2Uuba9SFftAHZGUKFb03ce4618vQfATxV8RPDsV/
p+iaq9rex7oX8yxAcHvhrkEfiK+hyXPMrx0/bKooNPVS0e97/Fby/NX1PBzThrNcB+5nTc1JaOOs
Vo018Keu7u35WWh9c/ssX+34H6WMj/j5vv8A0snrpvixqJHwb8cHP3fDGrN+VjOa5P4GaFfeC/hj
p+n6hEsF5HJcSyRBw/l+ZPJIFJUkEgOM4JGa0Pi9flPgf8QW7L4R1pvy064NfFY6UXOpJeZ+k4BN
Qpxe9l+hsCenLP71nLd571IlyPWteYg0BPThP7/rVBbinrP707gXhNT1nyKoCenrPTAvCenCb3qi
J/enCfNArF3zqDJx1qqs9L5+e9FwsWRL70olx6VWE1KJM+lO4WLXncd6PNx61WD+tL5v1ouKxZ83
IqKSCOXqKj8360CX3NFx2JYrWJDwoqePavQCqgl96UTc9qExWL28UFxVRbginC45oFZkzjeOaqTa
NDMxJUEn2qcTZ70pkyKARFFp0UA4UVIAFHApC49aaXJoHqSFiaaXAphOaaXwaAJPM9qRmzTN5pC2
aAsKX54prNjrTGbJpCaQ0h3mU0nNJuHrQXFAxaMimFiaSgBWOTSUE4FRk5oAcXx0prPTWf0pjNj6
0AOZs0wvjpSEk0hOKVwFLE00vikL5phYClcBzNnrUbSYpHeonkqQHPLULyU2SWoXkzQNIc8lQyS0
kklQPJzQUkOeWoJJcUkklV5ZaTYwmmzVaSaiWWoJZagAklqtNL1pZJeKrSyZNDKSCWXJqvLJSySV
Xd81DZQjvxUMrU9mzUEhzSAY7frULnJqV+tROMGgCInJpjjmpXXNNIpFEdNZealKA0nl+9A7kOM0
GLPYVMI/el2D3pWC5CI8dgKUR1MIs9qUR49KdguQiL2NPEfNSCPn1p6x49qLCuRLFUixZqRYqesf
40ybkSxVIsVSCOnrH+FAEax1IsePapEjp6p6UAMWPinLH+NSLH7Zp6p60ARrH/kUj2Mcv3lBqcL6
CnhMdaAK8OnxRn5UA/CrCoF6CnBM09Up2Aaqcc09Uz9Kcq4pyrupoQ3aB2pQM0/YKUDFUL0ECCnK
mfpQoyafQDCmywrKpDDINOooJMy58J2dzLvaJCfcU0aTBYxkRoo49K1gM1SvBwfpSsi7mLqXeud1
T79dFqXeue1Qc5rGRpE57U+/+fWsO96mtzU+/wDn1rDveprFmyK8Ea3mp2Vm2oaLpP2+dbcX2sXy
WNhZ5BJlnmc4RFUEnGWbAVVZmVT2fx88BeCfhn4l0qHwL8VfCfxQ0jUbaNJpdP1C0e+sbxYszeZB
DIxFu7K7xuM7M+W5LBJJeKliSdCrqrqezDIpkNlDbtujhijPqqAGsXF8yaehupRUWmtSWvd/2Bf2
stB/Y38SWvijxBpXiHWbW91DxhpkNto0MMlwZXsvA8gJ86WJAu2JuS/Uj148Hc4FQRXV3JaWenvB
brZ6dqeqarHcCcmWZr610a3MRj2AKI/7J3bt7bvtGNq7MtjiqPtYqD2v/maYer7NuS3t/kfWnj39
q/8AZv8A2nPjj428ZfE/wb43nji8KaLp/h/SzHc2mrT3UN3rEtzHHPYXHlxoVuLTJkuFQ5GeVIHy
ZYLiOVxamwjnnlnis/tUl0LGN5GdLcSyEySCJWEYdyWYICSSSanoJxSw+FjRvythXxMqtrpH2D/w
Rg+CXhfxv8YpfFmsaWNS1zRNR1uGwluLiWSG0FvZ+G3hdIC3lLIjaheESBN/74/N8q7fJ7/wnpmq
ftEeNY9Q3W9r4x+L3izwpq4klZ4b7Rpby/mvJ/LYlEewkjtJVlQKytdoxYmOPb5D8PvFuqfB/wCJ
dj408JXS6H4s0xgYNRiiBeRe8Mo/5aQsOGjbgj0IBEfiDxRfeIvGHjPXi0Wm6j49vNTuNWNmoyYL
+8lup7NZGBcQkytGcEMyFlJw7A8rwdT2sp30f+ex0rFU/ZxjbVf1cwvCGpT6p4R0q6uwRdXNnDLM
MYw7IC36k17D+xj43j8B/EjVby7eGbQ2mtxqOlRSrDql8x2qs9u5GRFGCAwJKluAEbLnyottGBxj
9KsaH4gv/Cev2eraVez6dqmnSeda3MW0tExUqflYFWBVmBVlKkEggjivpcpxsMLX56qbi007O2/p
/XXdHzWc4GeLw/s6TSkmmrq+q9f66bM/RL45eNvCh8XXlh8MtAe1+It1DHcRXCWS29t9qnhVo1ub
ZmVry5dSC23kAgvI4+Q/m3b6g18biaQ5nkupzOwi8oPN5r+YwQKgQF9xChEABA2rjaO48d/tY/Eb
xL4m8Y67ZHwvpeueM7GGymvre2lSbTJY4DbNfWjli0Ez27yxsiER/vNwAZVI808M6FH4W8P21hHJ
JKtupBkc5aRiSWY/Ukn8a+Zo5lmtXGVMLiYL2MPhldu/SOr30u2rJRei3bfDldHExxc51aainzbJ
JfEuW1urV3LzseS/tA3cWvM+j31mFs01XUJYrhiSZ2lsNISRUBXAMYjjJIYkeeuQvBb7u/Z7+OXw
o+JP/BLXxV4l1XVvh14X+JXhzQ7vwJpeiRaB4Ouhrt/HDFqMcUdgukI0dtLqjtcm02siNG0pJILj
428ffDnVPFviVYpZBP4b86S+8q3v47G9guZIYIX8uR7S4XYy2sBO5T90gKpO6u8+Gniu+8K/sgf8
Kxv7Cwglj+JD+Ohd21zJcCZTo500IxZU2tjadoTHy53EkivnlhszqZlJVV+4u7P3b9N/7u/Lb3r/
ABaWP6AxmI4QhwrSeEf/AApWh7RfveTlvP4L6e1tye15v3XLb2XvcxRsLSPRdKtrOJpGitIlhQu2
5iFAAJPc4HWvSf2ef25bj9krQdYgPgHUvFtvoeoHx1Jc2Xim30qPyW1HwrYC2uIpbGd2QXkNjJvg
cOQXXbjLV5lPPS+H/En/AAiV/q94tpb6g+paXBpbQXEVtLG8Sa5o+pyqVube4gyyaW0atJbzKrSA
mNwMV9PjKXtKXKlfb+vuPy3C1OSpzNjvDH/BU74w+A/Amj6Jp/jzxXs0ixgsYyNVnSJVijVBtUN0
wvTitf8AaUmx+1P8Xx6fETxN/wCnm8rrPiB+13oWvfDKx0jRPgr4L8O+INOt7tV19rbwpeyajNKd
0Ml5bt4WWJ0gOAEtvsxdMh3LESDx3Wtfv/E3iHVdX1W9l1HVtc1C61XULuVI43urq5neeaQrGqou
6SRztRVUZwAAMVjhqbjK7jY2rzTja9x3mZPWuh+HfxK8R/C3XG1Lwxr+t+HNRkhNu91pd9LZzNGS
CULxsrFSVUkZxlR6Vy8Llmrpvhvd3Om+M9Mns9LtdavUuEFtY3NqbqK6lJwiGL/lp8xHyEEMeCGB
IPY9tTlO40T9qn4paZd3k9r8SfH9tPqMonupIvEN2jXUgRUDuRJlm2Iq5OThQOgFW/Df7RXxD8Mz
tLp3jzxnp8skSwM9trdzEzRqzuqEq4+UNJIwHQF2Pc17B4k8F6Brnx98Ox6xpPhuO4+H/h06n4/T
RbSC206e5t2eQ23lQKsIkO63tpPLAUyMw6gmuo8dfs6zeH/2F9W1658FAa/q99pviObVrfR/LhtY
Lw3B+zW7iMKkMcYt2YIdqtOFONoFZe0p6XW9jR0562ex4JH+0P8AEF/D93pLeOvGTaXqBl+1WZ1q
5Nvc+axaXfHv2tvLMWyDuLEnOawrPX9Qs9EudMivryLTr2RJri0SZlgndN2x3QHazLubBIyNxx1r
6A8PaDc+Dvit4a8BaF4e8FXGoaBpcc3ibU9c0e2vIbJ3Zbm8e4edWRY4YykJZhuUxuEIaQ7u/uPD
3gPxLPaaP4f8LaLF4Y8baF4l8Q/bZrKJ7yzaCa5NoY52HnQJEtrGPLVlUiVgwYmq9tGP2d/6/wCG
IVKUt2fJun+NNZ0m0soLXVtTtoNMujfWccV06Ja3B25mjAOEk+RfmGD8o54FQ3PiTUbzRo9Omv72
XT4Z3uo7V52aFJXADyBCdodgqgtjJCjPSva/jDqGmWOj/BnXtM0Pwb4Xk1PR52uAdMNzYKy3s8Im
njkWd59qqCfMErHb0bhax/2vNMtIL7wXfWdnoezU/D0cs2raLYR6fp+tzCaVXmit0VPL24Ebb4on
LRsTGoIJ1jUTa03v+BEqbSeu36nkKvjrXOC3+2adpjnkjTbNfytox/Suhp+k+EZJdB0tsHDafbEf
9+UrVxuzJOyK/wAP9JMusygDJ8k/+hLRXf8AwV8CPeeKbhChOLRj0/20orCorM2p6q5zH7Zb/wDG
XvxVH/U4av8A+ls1ebWt89nMXXYwZWR0dQ6SIwwysp4ZSCQQeCDX9I1FeRDNuVJcv4/8A9SWWXbf
N+H/AAT+c/whqGnaDfrNbxxIhbc9tcSMoX/clCtuHosgB9ZD29XPxy0MaT5Z0a+3bcbvtunbc/T7
Tu9/u/rxX7s0V9Zg/ErNMPTVJWkl/Nq/v0/G5+T8R+AfDOc4hYqupwle/uS5U/k7pfKx/OV401bT
tcvnmmjidQ2UtreRmDf78pVdo9VjBPpIO/O31899NvfYAqhERFCJGqjCqqjhVAAAA4AFf0r0V4mZ
cV4rH1Pa4r3n010XorH3mQcE5fkuHWGy+PLHq9W36tu7/LsfzOySkU6CQ8V/TBRXnf2t/c/H/gHu
/wBm/wB78P8Agn819pIeK9T+Fv7TfjH4aaJaaPY6vcP4etrpbxtJdiLW4dXEnzhcMfmUHgg8dRX7
+0VMszhJxlOmm4tSV7OzWzV1uu5MsrbhKHPZSTTtpdPdaM/CfUf2tvFd7LayaVMnhue2WRTNpssy
yTI6xAqxd24HkpjGO+c8Yo6z+0N468T6VdWV74s124t7yF4ZUe6Yq6MCrAjPIIJr95qKyxmKwmLx
CxWKw0J1Fa0nGLem2vL0IwuUyw1B4ahVlGDvdJu2uj+11Pwh8R/tEeIddmaWNNO0i5a+F/8AaNN+
0xTK+yVNoZ5nAUiZ88Z6c9c8bquv3OsahNd3c8lxc3Dl5ZZG3PIx6knuT61/QhRXXWziNXEfWqlJ
Opy8vNony3vy3Ub2vrbuZYXI44ek6FGbUG+a2rV7Wvq3rY/njfUGB61E+pMO9f0Q0Uf21/c/H/gG
39k/3vw/4J/Oy+rMD1pg1t42yGIPrmv6KaKP7af8n4/8AP7J/vfh/wAE/netPHV/prgwXt1CV6FJ
WXH61qf8Lz8SCwltjrOoNBMhjdWnY5UjBHXuDiv6DaKpZ7NbR/H/AIBlLI6cvia+4/nUm8US3M7y
ySvJJIxZ3YksxPJJJ6k0DxIR/FX9FdFT/bT35Px/4BosoSVlL8P+Cfzrp4mP96vs34H/ALQHw9Pw
I8AwXnxE+H2l32neFtJ0+8s9T8S2NhdWtxb2MME0bxTSo6lZI2HIwQAQSCDX6t0Vz18zdS3u2t5/
8A3o5fyX978D8yx+0B8M16/FT4Tj/udtK/8AkiuO+Jl58C/ixEv9sfEb4PvMn3Jl8caSkifRhcZr
9ZaK5p4pTjyzimn3NZ4GElyy1XofkN4U0/4OeDtIXTrH43fDeCwVi5h/4WBpHzE9SWNzuP59ABXd
+GPi18HvCVr5Vl8VPg7Fu5Zz490gu59STc5Nfp9RXn4LB4HB1JVcJh4U5S+Jxiot+rSTfzOmUakq
UaEptwjpFX0S7JbL5H5rr+0T8LP+iufB3/wvNH/+Sa439or9oD4dav8ABu80zS/iP8OdZ1HUdZ0D
yrfTPFNhfOqQa9p13PLJ5MreVFHBbzO0km1FC8nkV+rVFel9dl1Rh9UXRn4VfHz4v6Fr/wAc9M1H
RdXsdb0vw3aaAl7eadMLq3VodYuruYLImVfZFKhO0nGatJ8WfDSnjxj4MK9ifEFmv6GQEfiK/cui
uuGbOKso/icssrUnrL8D8PIvi/4YHXxn4HH18S2I/wDatM1bx74I8R24ivvF3w+mUdC/ifTwV+h8
6v3GorSGe1YtSjGzXmZVMkpVIOFR3T3TSafyPwdfRfhpdI6nxx4FUOCMHxhpuOfYzV3Xww+P9x8K
PscWi/tA6HZWVkT5VsvjrTTGFJ5XD3DDH4fTFftRRWebZu80gqeZU1WUb8vP77jfdxcruL84tPRa
6Hl4PgnK8HU9rg6apS68iUL/AOLltzfO5+Msnxo8M6lqt9f33xO8AajfalcNdXNxc+NtLeSR26kn
z/Yfl65NWYPjD4M3Df8AEP4bIpPLDxfprkf8BWcsfoATX7I0Vjg8whhKEcNh6ajCKskuiPXeUQbv
zM/ETwD8QNP07x3qWuXt5DpmjeILvxLNaXl632eErda3HeW5ZnwE8yFSw3Yrtk+MXhJcZ8aeCR/3
MVl/8dr9haK6o504q0Yfj/wBSyhSd3L8P+Cfj+nxm8HDr448Cj6+JbEf+1a2fCH7TuheA9Se70f4
k/D+yuJE8t9/iTTnSRfRlM3OPwIr9Z6KmpnLqR5JwTQ6eVKEuaM2mfjv8U/jDp3xkZo9W+Mnw5t7
OTiSOz17TIJHHceYbhiuf9nBq/4d+J/w/wDDOjW1haeP/htFbWkYiiT/AIS/TflUDA/5b1+vNFZ0
M0VG/s6aV/U0rZc6v8Sbf3H5MJ8bPA+cf8LE+Gn/AIWGmf8Ax+sf4qfF/wAI6x8H/Gmnaf4z8Gax
qmseHNT0ywsNL1601C6u7i4s5YIkSKCR3OXkXJxgDJJr9f6K2lnk5LlcVqYxyaCd1Jn5TJeZ71Ml
0a/VOiur/WL/AKd/j/wDn/sH+/8Ah/wT8sEu/epku6/Umij/AFi/6d/j/wAAX9gf9PPw/wCCfl0l
zmpFnzX6g0Uf6x/9O/x/4Af2B/08/D/gn5grNmlE1fp7RT/1k/6d/j/wA/sD/p5+H/BPzFWbNPEh
PvX6b0U/9ZP+nf4/8AP7A/6efh/wT8yRJinCav00oo/1k/6d/j/wA/sD/p5+H/BPzNExp3nfWv0w
oo/1k/6d/j/wA/sD/p5+H/BPzPEvvTvM9q/S6ij/AFk/6d/j/wAAP7A/6efh/wAE/NHeaPM9q/S6
ij/WT/p3+P8AwA/sD/p5+H/BPzTDZFG7Hev0soo/1k/6d/j/AMAP7A/6efh/wT80/N96cs5xX6VU
Uf6yf9O/x/4Af2B/08/D/gn5rianq+a/SWij/WX/AKd/j/wBf6v/APTz8P8Agn5sMcmkr9KKKP8A
WT/p3+P/AAB/2B/08/D/AIJ+axYA01mzX6V0Uf6yf9O/x/4Af2B/08/D/gn5pngVGTk1+mFFH+sn
/Tv8f+AH9gf9PPw/4J+Z9FfphRR/rJ/07/H/AIAf2B/08/D/AIJ+Z9NZua/TKij/AFk/6d/j/wAA
P7A/6efh/wAE/Msnjmo2fPWv04oo/wBZP+nf4/8AAD+wP+nn4f8ABPzEZ8+1Jkeor9PKKX+sn/Tv
8f8AgB/YH/Tz8P8Agn5gM3PFNZsV+oNFH+sf/Tv8f+AH9gf9PPw/4J+XhcmmM2DX6jUUv9Y/+nf4
/wDAD+wP+nn4f8E/LR5OKieSv1Qoo/1i/wCnf4/8Af8AYP8Af/D/AIJ+VMj1DJJX6uUUf6xf9O/x
/wCAP+wv7/4f8E/J15c1E8nFfrPRR/rF/wBO/wAf+AH9hf3/AMP+CfkjK9VpZK/Xeip/1h/6d/j/
AMAP7C/v/h/wT8gJXqCR6/Yaij/WH/p3+P8AwA/sL+/+H/BPxykaq8jZ/Gv2VopPiD/p3+P/AACv
7D/v/h/wT8YpGz+NRP0r9oqKX9v/APTv8f8AgB/Yn9/8P+Cfiw55qN/vV+1dFH9v/wDTv8f+AH9i
f3/w/wCCfii/UUx1zX7Y0Uf2/wD9O/x/4Af2J/f/AA/4J+JdFftpRR/b/wD07/H/AIAf2J/f/D/g
n4l4HoKMD0FftpRR/b//AE7/AB/4Af2J/f8Aw/4J+JYXJ4pdhr9s6KP7f/6d/j/wA/sT+/8Ah/wT
8TQnrThHntX7YUUf2/8A9O/x/wCAH9if3/w/4J+KAj/CnrH7V+1lFH9v/wDTv8f+AH9if3/w/wCC
fisEAp4Sv2moo/t//p3+P/AD+xP7/wCH/BPxbWOnqnPrX7Q0Uf2//wBO/wAf+AH9if3/AMP+CfjE
qY96esdfs1RR/b//AE7/AB/4Af2J/f8Aw/4J+NAQ+lKEx1r9lqKP7f8A+nf4/wDAD+xP7/4f8E/G
unKnc1+yVFP+3/8Ap3+P/AD+xP7/AOH/AAT8cVT1pwGTX7GUUf6wf9O/x/4Av7D/AL/4f8E/HUp6
UqjAr9iaKf8ArD/07/H/AIAf2H/f/D/gn48Ku6nBcCv2Foo/1h/6d/j/AMAP7D/v/h/wT8e6K/YS
ij/WH/p3+P8AwBf2F/f/AA/4J+PdFfsJRR/rD/07/H/gDWR/3/w/4J+PyrtqlfDCt9K/Y6ih8Qf9
O/x/4Af2H/f/AA/4J+Kupd65/VetfuVRUPPr/Y/H/gFrJv7/AOH/AAT8E9T7/wCfWsO+OCa/oIor
N51/c/H/AIBayj+/+H/BP576K/oQopf2z/c/H/gD/sn+/wDh/wAE/nvIzSBQK/oRoo/tn+5+P/AD
+yf7/wCH/BP57mOBTCa/oUoo/tn+5+P/AAA/sn+/+H/BP56GfPSmM/pX9DVFH9s/3Px/4Af2T/f/
AA/4J/PETgVHI2a/ohoqf7Y/ufj/AMAP7J/v/h/wT+dh2zUMj1/RbRR/bH9z8f8AgAsq/vfh/wAE
/nJmkxVO4mxX9IVFH9sf3Px/4BX9l/3vw/4J/NjPPg1QubnFf0u0Unm39z8f+ANZZ/e/D/gn8yc9
1yahWcs1f05UVP8Aav8Ad/H/AIA/7N/vfh/wT+ZqyG4iu4+EXxE1n4P+OtO8S+HrqKy1nSnaS1ne
2iuViYqUJ8uVWQnDHGVODgjkA1/RbRT/ALWWzh+P/AD+zXe6l+H/AAT8DNb/AGh9f8VeEdU0i5s/
C9rFrJgF1NpmgWelySRxO0ixEWscaMpkKsSylsxphgAQY/hz8XtZ+HVibK0a0udKl1K01W50+6gE
kF3NbFjFvIw+0b3BVWUENzniv33oo/tWNrcn4/8AAJeWSbvz/h/wT8H/AAh+0X4s8GXniSezu9Ln
bxfKJtXTUNGstRjvWEhlG5LiKRQN7FsADkA9hizP+0340m8KX+iJqVla6XqPnCSC10mztvJSYoZo
oWjiVoIZDGheKIpG+DuU5Of3Xop/2rDf2f4/8AP7Nlt7T8P+CfhjrX7Uni7xLbaLDfL4TuIPD24a
fC3hLSRFbq2/KbBbbWQl2bYwK7juxuAI5r4g/ErWfijrEN9rVzFPLbW6WlvFBaxWlvawpnbHFDCq
RxqCScIoBLE9SSf3zooWbRWqp/j/AMAHlknvP8P+Cfz316v4VttEuvCGhka74ajcaVZq6S6vaxuj
i3jDKys4IIYEEEZ4r9uaK0WdtO6h+P8AwCHlF1bn/D/gn5AfCG88N+F/Ek9xfeJfCkML2zRhv7at
GyxdDjAkJ6A0V+v9FZzzfmd3D8f+AaQyzlVlL8P+CFFFFeMeqFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FAH/2Q==
--047d7b5d4808ce813d04d4fc289b
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--047d7b5d4808ce813d04d4fc289b--


From xen-devel-bounces@lists.xen.org Tue Feb 05 15:50:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15:50: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 1U2knC-0002Nn-Aj; Tue, 05 Feb 2013 15:50:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U2kn9-0002NV-C5
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:50:40 +0000
Received: from [85.158.139.211:55518] by server-7.bemta-5.messagelabs.com id
	22/E0-11121-E4A21115; Tue, 05 Feb 2013 15:50:38 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360079396!20094855!1
X-Originating-IP: [74.125.82.196]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8814 invoked from network); 5 Feb 2013 15:49:57 -0000
Received: from mail-we0-f196.google.com (HELO mail-we0-f196.google.com)
	(74.125.82.196)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 15:49:57 -0000
Received: by mail-we0-f196.google.com with SMTP id t11so48423wey.3
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 07:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=I7CetpEuMTynfSzSf+PIwa61iNqYDs0HYv8cdujgZMA=;
	b=p99cMi23L/JMkrtWseLa+dvHIxRCaZ65euFMsLJ57ns+OwIK/d8UUIYf3YGMcipIzI
	u9v8F5RpYrAFXPB1fRzDvTjMlmz9n6wjX3OJXO8+b03PQELB+Dpjmxc10gJRMuqvXLoy
	nJFMc4C2AsSVwDdaNwBf3KUvPREVp/zLiiEiAtXAf3SJj10sf7qXN5dON2uMnj7clLhT
	6bxFnHSGAj7Fb5JBUajdo280eTYZKv377kA/nvFLLVZEXAfnuR4Y7bVRsvrOryMXx3/s
	5uOYw/54VAYENAEr4gz7444tsgWrxpdunGdSXvVGNEBhzH4t8vQ8iQd/HKDlZ624Y0lP
	SeTw==
MIME-Version: 1.0
X-Received: by 10.194.19.10 with SMTP id a10mr43331969wje.45.1360079388311;
	Tue, 05 Feb 2013 07:49:48 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Tue, 5 Feb 2013 07:49:47 -0800 (PST)
Date: Tue, 5 Feb 2013 16:49:47 +0100
Message-ID: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=047d7b5d4808ce813d04d4fc289b
Subject: [Xen-devel] XEN 4.1 error Critical Interrupt - Front panel NMI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--047d7b5d4808ce813d04d4fc289b
Content-Type: multipart/alternative; boundary=047d7b5d4808ce813804d4fc2899

--047d7b5d4808ce813804d4fc2899
Content-Type: text/plain; charset=ISO-8859-1

Hello Everyone,

I am quite new on XEN. I tried to installed XEN on my server and I know
this server series IBM Xeon 3,4 Ghz didn't have Intel VTx support so I am
pllaning to use paravirtualization.
I configure the server with Ubuntu Desktop  12.0464 bit as dom0 with XEN
4.1 64 hypervisor. The configuration using repositories exactly by this
tutorial https://help.ubuntu.com/community/XenProposed :

Installing Xen

Install a 64-bit hypervisor

sudo apt-get install xen-hypervisor-amd64

Modify GRUB to default to booting Xen:

sudo sed -i 's/GRUB_DEFAULT=.*\+/GRUB_DEFAULT="Xen 4.1-amd64"/'
/etc/default/grubsudo update-grub

Set the default toolstack to xm (aka xend):

sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xm"/' /etc/default/xen

Now reboot:

sudo reboot



But when rebooting the Dom0 failed to start, enclosed was the error message
when Xen booting and after that Dom0 will restarting over and over.
On Blade server system  log I got error message :
(Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=
0020
(Bestak_septaher) Critical Interrupt - Front panel NMI

Please Suggest, thank you very much for any one help.

Best Regards,

Agya

--047d7b5d4808ce813804d4fc2899
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)">Hello Everyone,</div><div style=3D"fo=
nt-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-co=
lor:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">I am quite new on XEN. I tr=
ied to installed XEN on my server and I know this server series IBM Xeon 3,=
4 Ghz didn&#39;t have Intel VTx support so I am pllaning to use paravirtual=
ization.</div>
<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)">I configure the server with Ubuntu De=
sktop =A012.0464 bit as dom0 with=A0XEN 4.1 64 hypervisor. The configuratio=
n using repositories exactly by this tutorial <a href=3D"https://help.ubunt=
u.com/community/XenProposed">https://help.ubuntu.com/community/XenProposed<=
/a> :</div>
<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)"><br></div><div style=3D"font-size:13p=
x;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255=
,255,255)">
<h1 id=3D"Installing_Xen" style=3D"margin:0em 0px 8px;padding:0px;border:0p=
x;font-weight:normal;font-size:28px;line-height:32px;font-family:Ubuntu,&#3=
9;Ubuntu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Taho=
ma,sans-serif;vertical-align:baseline;color:rgb(51,51,51)">
Installing Xen</h1><span class=3D"anchor" id=3D"line-17" style=3D"margin:0p=
x;padding:0px;border:0px;line-height:13px;font-family:Ubuntu,&#39;Ubuntu Be=
ta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-ser=
if;vertical-align:baseline;color:rgb(51,51,51)"></span><p class=3D"line874"=
 style=3D"margin:0px 0px 8px;padding:0px;border:0px;line-height:1.5;font-fa=
mily:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu=
 Sans&#39;,Tahoma,sans-serif;vertical-align:baseline;color:rgb(51,51,51)">
Install a 64-bit hypervisor<span class=3D"anchor" id=3D"line-20" style=3D"m=
argin:0px;padding:0px;border:0px;font-style:inherit;line-height:1;font-fami=
ly:inherit;vertical-align:baseline"></span></p><pre style=3D"margin-top:0px=
;margin-bottom:8px;padding:4pt;border:1px dashed rgb(193,180,150);line-heig=
ht:16px;font-family:UbuntuMono,courier,monospace;vertical-align:baseline;ba=
ckground-color:rgb(243,243,243);white-space:pre-wrap;word-wrap:break-word;c=
olor:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1" style=3D"margin:0px;padding:0px;border=
:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:ba=
seline"></span>sudo apt-get install xen-hypervisor-amd64</pre><span class=
=3D"anchor" id=3D"line-21" style=3D"margin:0px;padding:0px;border:0px;line-=
height:13px;font-family:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera Sa=
ns&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;vertical-align:baseline;col=
or:rgb(51,51,51)"></span><p class=3D"line874" style=3D"margin:0px 0px 8px;p=
adding:0px;border:0px;line-height:1.5;font-family:Ubuntu,&#39;Ubuntu Beta&#=
39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;v=
ertical-align:baseline;color:rgb(51,51,51)">
Modify GRUB to default to booting Xen:<span class=3D"anchor" id=3D"line-22"=
 style=3D"margin:0px;padding:0px;border:0px;font-style:inherit;line-height:=
1;font-family:inherit;vertical-align:baseline"></span><span class=3D"anchor=
" id=3D"line-23" style=3D"margin:0px;padding:0px;border:0px;font-style:inhe=
rit;line-height:1;font-family:inherit;vertical-align:baseline"></span><span=
 class=3D"anchor" id=3D"line-24" style=3D"margin:0px;padding:0px;border:0px=
;font-style:inherit;line-height:1;font-family:inherit;vertical-align:baseli=
ne"></span><span class=3D"anchor" id=3D"line-25" style=3D"margin:0px;paddin=
g:0px;border:0px;font-style:inherit;line-height:1;font-family:inherit;verti=
cal-align:baseline"></span></p>
<pre style=3D"margin-top:0px;margin-bottom:8px;padding:4pt;border:1px dashe=
d rgb(193,180,150);line-height:16px;font-family:UbuntuMono,courier,monospac=
e;vertical-align:baseline;background-color:rgb(243,243,243);white-space:pre=
-wrap;word-wrap:break-word;color:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1-1" style=3D"margin:0px;padding:0px;bord=
er:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:=
baseline"></span>sudo sed -i &#39;s/GRUB_DEFAULT=3D.*\+/GRUB_DEFAULT=3D&quo=
t;Xen 4.1-amd64&quot;/&#39; /etc/default/grub
<span class=3D"anchor" id=3D"line-2" style=3D"margin:0px;padding:0px;border=
:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:ba=
seline"></span>sudo update-grub</pre><span class=3D"anchor" id=3D"line-26" =
style=3D"margin:0px;padding:0px;border:0px;line-height:13px;font-family:Ubu=
ntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#3=
9;,Tahoma,sans-serif;vertical-align:baseline;color:rgb(51,51,51)"></span><p=
 class=3D"line862" style=3D"margin:0px 0px 8px;padding:0px;border:0px;line-=
height:1.5;font-family:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstream Vera San=
s&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;vertical-align:baseline;colo=
r:rgb(51,51,51)">
Set the default toolstack to xm (aka=A0<tt style=3D"margin:0px;padding:0px;=
border:0px;font-style:inherit;line-height:1;vertical-align:baseline">xend</=
tt>):<span class=3D"anchor" id=3D"line-27" style=3D"margin:0px;padding:0px;=
border:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-al=
ign:baseline"></span><span class=3D"anchor" id=3D"line-28" style=3D"margin:=
0px;padding:0px;border:0px;font-style:inherit;line-height:1;font-family:inh=
erit;vertical-align:baseline"></span><span class=3D"anchor" id=3D"line-29" =
style=3D"margin:0px;padding:0px;border:0px;font-style:inherit;line-height:1=
;font-family:inherit;vertical-align:baseline"></span></p>
<pre style=3D"margin-top:0px;margin-bottom:8px;padding:4pt;border:1px dashe=
d rgb(193,180,150);line-height:16px;font-family:UbuntuMono,courier,monospac=
e;vertical-align:baseline;background-color:rgb(243,243,243);white-space:pre=
-wrap;word-wrap:break-word;color:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1-2" style=3D"margin:0px;padding:0px;bord=
er:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:=
baseline"></span>sudo sed -i &#39;s/TOOLSTACK=3D.*\+/TOOLSTACK=3D&quot;xm&q=
uot;/&#39; /etc/default/xen</pre>
<span class=3D"anchor" id=3D"line-30" style=3D"margin:0px;padding:0px;borde=
r:0px;line-height:13px;font-family:Ubuntu,&#39;Ubuntu Beta&#39;,&#39;Bitstr=
eam Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,sans-serif;vertical-align:b=
aseline;color:rgb(51,51,51)"></span><p class=3D"line874" style=3D"margin:0p=
x 0px 8px;padding:0px;border:0px;line-height:1.5;font-family:Ubuntu,&#39;Ub=
untu Beta&#39;,&#39;Bitstream Vera Sans&#39;,&#39;DejaVu Sans&#39;,Tahoma,s=
ans-serif;vertical-align:baseline;color:rgb(51,51,51)">
Now reboot:<span class=3D"anchor" id=3D"line-31" style=3D"margin:0px;paddin=
g:0px;border:0px;font-style:inherit;line-height:1;font-family:inherit;verti=
cal-align:baseline"></span><span class=3D"anchor" id=3D"line-32" style=3D"m=
argin:0px;padding:0px;border:0px;font-style:inherit;line-height:1;font-fami=
ly:inherit;vertical-align:baseline"></span><span class=3D"anchor" id=3D"lin=
e-33" style=3D"margin:0px;padding:0px;border:0px;font-style:inherit;line-he=
ight:1;font-family:inherit;vertical-align:baseline"></span></p>
<pre style=3D"margin-top:0px;margin-bottom:8px;padding:4pt;border:1px dashe=
d rgb(193,180,150);line-height:16px;font-family:UbuntuMono,courier,monospac=
e;vertical-align:baseline;background-color:rgb(243,243,243);white-space:pre=
-wrap;word-wrap:break-word;color:rgb(51,51,51)">
<span class=3D"anchor" id=3D"line-1-3" style=3D"margin:0px;padding:0px;bord=
er:0px;font-style:inherit;line-height:1;font-family:inherit;vertical-align:=
baseline"></span>sudo reboot</pre></div><div style=3D"font-size:13px;color:=
rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255=
)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)"><br></div><div style=3D"fon=
t-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-col=
or:rgb(255,255,255)">
But when rebooting the Dom0 failed to start, enclosed was the error message=
 when Xen booting and after that Dom0 will restarting over and over.=A0</di=
v><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-s=
erif;background-color:rgb(255,255,255)">
On Blade server system =A0log I got error message :</div><div style=3D"font=
-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-colo=
r:rgb(255,255,255)">(Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI=
_FERR/NERR Value=3D 0020</div>
<div style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser=
if;background-color:rgb(255,255,255)">(Bestak_septaher) Critical Interrupt =
- Front panel NMI</div><div style=3D"font-size:13px;color:rgb(34,34,34);fon=
t-family:arial,sans-serif;background-color:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">Please Suggest, thank you v=
ery much for any one help.</div><div style=3D"font-size:13px;color:rgb(34,3=
4,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">Best Regards,</div><div sty=
le=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;backg=
round-color:rgb(255,255,255)">
<br></div><div style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=
l,sans-serif;background-color:rgb(255,255,255)">Agya</div>

--047d7b5d4808ce813804d4fc2899--
--047d7b5d4808ce813d04d4fc289b
Content-Type: image/jpeg; name="eror.jpg"
Content-Disposition: attachment; filename="eror.jpg"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hct84g1j0

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG
BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAMABVYDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9/KKK
KACuD+EP/JQfin/2NEH/AKZdLrvK4P4Q/wDJQfin/wBjRB/6ZdLqlsxHeUUUVIwooooAKKKKACii
igAooooAKKKKACiiigAooooAK4P9qf8A5Ni+I/8A2K+p/wDpJLXeVwf7U/8AybF8R/8AsV9T/wDS
SWqjuhM7yiiipGZPjPwJovxF0SXTNf0ux1nTZwBLaXkKzQSgMGG5GyrYZVIyOCAa4b/hif4O/wDR
Lfh//wCCC1/+Ir0+igDzD/hif4O/9Et+H/8A4ILX/wCIo/4Yn+Dv/RLfh/8A+CC1/wDiK9PooA8w
/wCGJ/g7/wBEt+H/AP4ILX/4ij/hif4O/wDRLfh//wCCC1/+Ir0+igDn/AHwp8M/CjTns/DGgaT4
es5HMjW+nWqW0LOQoLFEAXcQqjOM4UeldBRRQAVz3iD4T+GfFd/9q1TQtM1G5xt825t1lYDJOAWz
gZJOPc10NFAHI/8ACgfBH/Qp+H//AABj/wAKP+FA+CP+hT8P/wDgDH/hXXUU7isjkf8AhQPgj/oU
/D//AIAx/wCFH/CgfBH/AEKfh/8A8AY/8K66ii4WRyI+AXggH/kU9A/8Ao/8K6q1tUs4FjjXai9B
nOO9SUUh2CuD/aN/5J9p3/Y0eHv/AE9WVd5XB/tG/wDJPtO/7Gjw9/6erKqjuhM7yiiipGFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBwfh7/k53xf/ANivof8A6V6xXeVwfh7/AJOd8X/9
ivof/pXrFd5VS3EgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXPeIPh
P4Z8V3/2rVNC0zUbnG3zbm3WVgMk4BbOBkk49zXQ0UAcj/woHwR/0Kfh/wD8AY/8KP8AhQPgj/oU
/D//AIAx/wCFddRTuKyOR/4UD4I/6FPw/wD+AMf+FH/CgfBH/Qp+H/8AwBj/AMK66ii4WRyP/Cgf
BH/Qp+H/APwBj/wo/wCFA+CP+hT8P/8AgDH/AIV11FFwsjkf+FA+CP8AoU/D/wD4Ax/4Uf8ACgfB
H/Qp+H//AABj/wAK66ii4WRyP/CgfBH/AEKfh/8A8AY/8KP+FA+CP+hT8P8A/gDH/hXXUUXCyKHh
7wvp3hKxFrplnb2Fsv3YYE2RryTwo4HJJ49av0UUhhXBeK/2WPhr481uXU9c8BeEdZ1KcKJLu+0q
G5nkCqFXLupY4UADJ4AArvaKAPMP+GJ/g7/0S34f/wDggtf/AIij/hif4O/9Et+H/wD4ILX/AOIr
0+igDzD/AIYn+Dv/AES34f8A/ggtf/iKP+GJ/g7/ANEt+H//AIILX/4ivT6KAPMP+GJ/g7/0S34f
/wDggtf/AIij/hif4O/9Et+H/wD4ILX/AOIr0+igDzD/AIYn+Dv/AES34f8A/ggtf/iKP+GJ/g7/
ANEt+H//AIILX/4ivT6KAPMP+GJ/g7/0S34f/wDggtf/AIirWi/shfCrw3q1tf6d8OPBNhfWcizW
9zbaNbxTQOpyrqyqCrAgEEHIIr0WigBsUSwRKijCoAoHoBTqKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK8l8P/
ABDtPhp8TfiLDqumeLf+Jnr0F7ay2XhjUr+C4h/snT4tyywQOhxJFIpG7IKHIr1qimmBwf8Aw0b4
f/6B3jz/AMIjWv8A5Fo/4aN8P/8AQO8ef+ERrX/yLXeUUaC1OD/4aN8P/wDQO8ef+ERrX/yLR/w0
b4f/AOgd48/8IjWv/kWu8oo0DU4P/ho3w/8A9A7x5/4RGtf/ACLR/wANG+H/APoHePP/AAiNa/8A
kWu8oo0DU4P/AIaN8P8A/QO8ef8AhEa1/wDItH/DRvh//oHePP8AwiNa/wDkWu8oo0DU4P8A4aN8
P/8AQO8ef+ERrX/yLR/w0b4f/wCgd48/8IjWv/kWu8oo0DU4P/ho3w//ANA7x5/4RGtf/ItH/DRv
h/8A6B3jz/wiNa/+Ra7yijQNTg/+GjfD/wD0DvHn/hEa1/8AItH/AA0b4f8A+gd48/8ACI1r/wCR
a7yijQNTg/8Aho3w/wD9A7x5/wCERrX/AMi0f8NG+H/+gd48/wDCI1r/AORa7yijQNTg/wDho3w/
/wBA7x5/4RGtf/Itcl8ffjPpnjX4E+NdG0zSPHlzqWr6DfWVpD/whesJ5s0lvIiLua1CjLMBkkAZ
5Ir2mimmk7hqFFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArg/2kEm/wCFZQzQ
2l/e/Yte0S9lisrSW7n8mHVrSWVliiVnfbGjsQqk4U8V3lFNOzuBwf8Aw0b4f/6B3jz/AMIjWv8A
5Fo/4aN8P/8AQO8ef+ERrX/yLXeUUaC1OD/4aN8P/wDQO8ef+ERrX/yLR/w0b4f/AOgd48/8IjWv
/kWu8oo0DU4P/ho3w/8A9A7x5/4RGtf/ACLR/wANG+H/APoHePP/AAiNa/8AkWu8oo0DU4P/AIaN
8P8A/QO8ef8AhEa1/wDItH/DRvh//oHePP8AwiNa/wDkWu8oo0DU4P8A4aN8P/8AQO8ef+ERrX/y
LR/w0b4f/wCgd48/8IjWv/kWu8oo0DU4P/ho3w//ANA7x5/4RGtf/ItH/DRvh/8A6B3jz/wiNa/+
Ra7yijQNTg/+GjfD/wD0DvHn/hEa1/8AItH/AA0b4f8A+gd48/8ACI1r/wCRa7yijQNTg/8Aho3w
/wD9A7x5/wCERrX/AMi0f8NG+H/+gd48/wDCI1r/AORa7yijQNTg/wDho3w//wBA7x5/4RGtf/It
H/DRvh//AKB3jz/wiNa/+Ra7yijQNTzT4YeIF8a/HbxbrNpYa9babJoOj2Uc2paNd6b5s0dxqbyK
i3EcbNtWaIkqCBvHNel0UUN3GgooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAZVx4PtLq4eVptVDSMWITU7lFBJzwokAA9gMCm/wDCEWX/AD31j/wbXX/xyqHx
l+F8Hxp+F2t+FrjWfE3h2PWbYwDVPDuqzaXqmnvkMk1vcREMjqwU4OUbBV1dGZG/Prw1+w58efFX
x/uPh/qnir4oeH/DumRi51Lx5Z/EjxMba9s3LLEdNhl1OQC+kKtuinEiWhRmk+0Ibb7XhVqyg0lF
u/YqMU+p+in/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjleN/8FDtBg8K/wDBMH436Xay
Xsttpvwx1y1ie8vJry4dE0udVMk8zPLK5AG6SRmdjksxJJr89P2JrXwRpP7ZX7NVj4G+Cafs6+K/
A3wzuvF3jG8m0zRtNn+J+jT6bDAsVqNMnnGoE3apcv8AaCkkHkqSoaQitYTi5TU3ZRSf3qpJ9tlT
bfW17JtWZVjyQpyWrnzr/wABdNJf9vOokuidrvU/W/8A4Qiy/wCe+sf+Da6/+OUf8IRZf899Y/8A
Btdf/HK/Pr9hP/grv8Vf2qfE/wAMtbuvAl5qHgX4sQajcNDpvwx8UacvgBEilnsZLnXbpW03VYpF
i8mSS3W3CyyoUDrnGF+zn/wU7/aV/aCj/ZjAk+Buit+0rofiC6iY+GNVuh4Xn0l1fziP7ST7ZHPD
lfIBgMTvu8+UJtfRwktLarfbR2k7fdB7XW2upMXFuyem9+6XXv8Ahfy1V/0i/wCEIsv+e+sf+Da6
/wDjlH/CEWX/AD31j/wbXX/xyvgf9n3/AIKpfFf9rTw98A/CnhfS/h54X+IXxUtfFV9revarp95q
Gi6bBoGof2fIbbT0uoJppLqZo3EbXg+zoWJafAzxfgn/AIKRfGX9oL9q39nW0h13w54Q023vfHmk
+PtGtNEnv7PX73w5KttcTWzfaopkimjZ3t45C4gkcGQXRjQ0tE/edl7zv/djfml3smrbXvaya1HN
OL5XvdRt15m9I+vXtbrqr/pZ/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45XwD/wT/wD+
CtvxT/a28dfCrVb3wJfX/gP4vLfSSRaX8MvE+nD4fxqkk1lJc67dK2mapFIkfkvJbrbhZZEKB1yB
6V+294esvj7/AMFIfgD8IvHWnWut/CjW/DniXxLfaDqCrLpfibVLFtPS1hu4HBjuUgS5mnWFwy71
STaTCpDlCSlGDWrbXpypt7X1snbo3bXW6nmjaTTulb53dl52u+uqV3bv9af8IRZf899Y/wDBtdf/
AByj/hCLL/nvrH/g2uv/AI5Xyv8AHfUtO/4Jn+GPht8NvgJ4R8OeHdQ+N/xB/sLS4NTnvJfDXhR5
re4vbq5isElVUjCW0hSxtXtY5JpS25Czs3lXjH/gqn8XfBGtJ8PZdM+G998RtB+Oui/CjWdZTTr2
DRNSsNT05tQivre0N081vOkbRo0TzzIWjYh8SDy1Bc8uWnq7qPa7bgrb9HUhq7X5rraXLUlypyl0
Upf9uxU5X+apy07rzTf37/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajlfnxq3/AAU7/aDj
+DHidNM8JeGNd8VfD34w6h8N/FfifQ/BOsa3pem6dBaC6h1UaHaXb37K3nW8UgjuJPKJd/3g2odv
4Yf8FL/iv+2HqukeH/hDqXwVtr7TfhNYfEbXPEt/purato+tXd5LcQRWWn2rS2F1DAJLOdnuJy0k
e5IzblgxqFOLh7S+lov5Sp+1T725Lvu7NJN6DcGqnsnvr96n7O3n7zS0ukmm2k7n3Z/whFl/z31j
/wAG11/8co/4Qiy/576x/wCDa6/+OV+VU3/BSmx1j9qPwn+1QfCl4lqn7ImteNX8Oi8DSeZHq1lK
1qJwmNu9SvmmP7vzFBytfSv/AAT0/b7+K37QXxj03w3438LXmp6D4h8Hp4kh8T6d8K/FHgvTdDvg
8Yk0qV9XDx3u9Jg8NzBKgcQy5hUFWO8aMmknpL3rrty1KsN+t/ZSd9to3bcebOU4pc6ej5befNGE
tvL2kV362spcv2B/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr0VkUZH/CEWX/AD31j/wb
XX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAG
R/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL
/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j
/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCO
Vr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/
4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf
899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4
Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf
/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR
/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8A
nvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8A
wbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDj
la9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hC
LL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX
/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4N
rr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8A
HKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45WvRQBk
f8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4Qiy/576x
/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhFl/z31j/w
bXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr
0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/AByj/hCL
L/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UAZH/CEWX/
AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv
/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDH
KP8AhCLL/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/w
hFl/z31j/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/
4Nrr/wCOVr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8
G11/8co/4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQ
Bkf8IRZf899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQi
y/576x/4Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899
Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8A
jla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A45WvRQBkf8IRZf8APfWP/Btdf/HK
P+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4Qiy/576x/wCDa6/+OVr0UAZH/CEW
X/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhFl/z31j/wbXX/AMco/wCEIsv+e+sf
+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+Da6/+OVr0UAZH/CEWX/PfWP/AAbX
X/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/AByj/hCLL/nvrH/g2uv/AI5WvRQB
kf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UAZH/CEWX/AD31j/wbXX/xyj/hCLL/
AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+sf8Ag2uv/jla9FAGR/whFl/z31j/
AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAGR/wAIRZf899Y/8G11/wDHKP8AhCLL/nvrH/g2uv8A
45WvRQBkf8IRZf8APfWP/Btdf/HKP+EIsv8AnvrH/g2uv/jla9FAGR/whFl/z31j/wAG11/8co/4
Qiy/576x/wCDa6/+OVr0UAZH/CEWX/PfWP8AwbXX/wAco/4Qiy/576x/4Nrr/wCOVr0UAZH/AAhF
l/z31j/wbXX/AMco/wCEIsv+e+sf+Da6/wDjla9FAGR/whFl/wA99Y/8G11/8co/4Qiy/wCe+sf+
Da6/+OVr0UAZH/CEWX/PfWP/AAbXX/xyj/hCLL/nvrH/AINrr/45WvRQBkf8IRZf899Y/wDBtdf/
AByj/hCLL/nvrH/g2uv/AI5WvRQBkf8ACEWX/PfWP/Btdf8Axyj/AIQiy/576x/4Nrr/AOOVr0UA
ZH/CEWX/AD31j/wbXX/xyj/hCLL/AJ76x/4Nrr/45WvRQBkf8IRZf899Y/8ABtdf/HKP+EIsv+e+
sf8Ag2uv/jla9FAGR/whFl/z31j/AMG11/8AHKP+EIsv+e+sf+Da6/8Ajla9FAHNeI/CdtYaDeTR
XGsJLFEzK39q3RwQPeSuZtLR5bdGa+1gkrk/8TK4/wDi67rxf/yK+of9cG/lXzl+1t8Ovih8XvhN
D4X+GPivSvAc2tEw6x4hkeX+07G02jMdgERljnkyVNwzBoVBMa+YyywgHrkWmbic3usf+DO4/wDi
6Ky/hZYeItJ8EWFp4r1Cw1fXbWMRXN/aRmJL7AAErR7VVHb+IINmQSoUEIpQB33j3xra/Dvwnd6x
ex3EtrZ7N6wKGkO51QYBIHVh36V51eftr+DLbUzZxDU7y5jt4bidLeOJ/s3mglUc+YAHwpyvOMj1
re/ai/5IVrn/AG7/APpRFXyJrGofaPE7W/8AaGjXH2fTrT/RdPh2m03K5zM/8UzdW9AF9ckA+gPi
Z+0Z8PPjF8ONf8I+I9D8Qaj4e8UadcaTqdphYftNrPE0Use+OZXXcjsNysGGcgg81w3iGL4EeKNf
+FerXngrxAdU+CgK+C7yG6lgn0ZGtxbPFvjuVaaJ4VVHjmMiOB8wY815tRQtNV5fhe33Xdu133CX
vK0tVZr5StzL0lZX72V9jqfhb8K/2b/gx8RrPxR4d8B+KrW/0g3x0e0uNYvLzSPDhvWJum0zTp7x
7PTjIGdSbSGIhHdBhHZTo/Djwl+z18Jf+FXf8I94D8Qaf/wpe21Cz8G/6bPL/Y8V+oW7X57pvO8w
Aczbyv8ACVrhaKd3a39df/kn977scm5Scpat319d/v6nRSfBn9mlfhj4V8JWngHxXpOneBtQv9U8
O3mla1fadrOh3F9LLLetbanBepewrO00nmIk4R1IUqVVVGjZeA/2dtI0n4aWemeBfE+hx/CCaa48
Ky6Rql1ptxYvOQbnzZoLxJLoXDKGnW5aUXDFmlEjMSeMoou/xv8ANbP1QSk5fFrv+N2/vbd/V9zr
PhL8Mv2cfgb8TdP8W+GvAniqz1LRHvZNFtbjV7y90jw214xa5bTNOnvHstOMmWUm0hiIR3QYR2U9
t8fPHfwi/aa0HTrDxh4c8U3R0W8XUdLv9PvJdI1TSLkAr51pfWdzFdWzlGZGaGVC6O6NlGZT47RS
eqSfTby1vp89fXUHJtuTer387739Tqk+Ff7NY+Dc/gV/h54guNHuNdHimS9uNQuZ9dfWA+9NU/td
7s6h9uThUuftHnIgCK4QBRNoXw7/AGc/DvhLw/o0HgPxNNb+GvGCeP7W5u9UurvULjXkDhdQu7yW
8a5vZgrlM3Mko2Ki42ogXj6KpTknzJ66P7rW+6yt2srbIG21yvbX/wAmun96k0+93fdnR+Lvg3+z
V41j1Y3fgLxZbXus+LZ/HU2pabrd9pupwazPbrazXdveW97HcWxkgRY2jgkSNlBBU5OYPGXwI/Zi
8beGfDekyfDvxRotv4U8Pt4T0+bw7rN74fvTo7YLadPc2N7DPc2rMN7QzvIjOWcgsxY4dFRGKirR
Vlp/5LHlX3R91do6LQfPLm5r66/i+Z/e9X567npRt/2fj40std/4Vs4utO8Gy/D23tRaRjTY/D8r
xu+nfYhN9lMJMSDBiyFXaCFJU5/7O/hj4B/ss+Kn1zwf4U8brrI0qPQba91rXr7xBPpmmxtvWxs3
1C9nNpbbgpMNv5cbGOPKny028LRVqck7p9/xbb+9yk33cm+rJ+zy9NPwsl9ySS9F2R9Pf8Np+Fv+
fDxB/wB+If8A47R/w2n4W/58PEH/AH4h/wDjtfMNFSB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv
+fDxB/34h/8AjtfMNFAH09/w2n4W/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wAN
p+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W
/wCfDxB/34h/+O18w0UAfT3/AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7X5tfsofso
fC3xH+y18NdQ1D4a+AL+/v8Awrpdxc3Nx4etJZriV7SJnkd2jJZmYkkk5JJJrS0H4QfAfxH8WtU8
GWvws8ANqulaZb6s8h8LWP2eWGaaeEbHCZLK8DbgQB8y4LfNtAP0T/4bT8Lf8+HiD/vxD/8AHaP+
G0/C3/Ph4g/78Q//AB2vy++Nnw1+FGh6gdF8M/DP4WjVo2/f3c3hKyuYLdh0j8sKhkOfvAOpAyAw
Y5XrPhH8E/gx8UNNnil+EXw30vX9MCLqemN4espDbF92yWN/JXzbeTY5jlCru2OrLHLHLFGAfor/
AMNp+Fv+fDxB/wB+If8A47R/w2n4W/58PEH/AH4h/wDjtfAPh/8AZz+BnifXtX0u0+Gnw3bUtCkR
L22fwtaRyRBwTHIA0Q3xvtcLIuULRypnfG6rsx/sd/COJwy/Cz4cKw6EeGrIEf8AkOgD7l/4bT8L
f8+HiD/vxD/8do/4bT8Lf8+HiD/vxD/8dr8ovGsPgHwt441bS0+EfwmNvp1zJCssnhu2yVViMt8u
OnU9OPyu6V4a8Dam+3/hU/wljIxkf8IvbkjIDD8wQfoQelMD9UP+G0/C3/Ph4g/78Q//AB2j/htP
wt/z4eIP+/EP/wAdr8rfiv4O8H+A/g34q8SWnwt+D8l1oOj3eowRTeEYDHI8MDyKrYYHaSoBwQa9
b/Zi8I6T4E8X/FzStD0vTtG0u18YQ+TZ2Nslvbw7tC0h22ogCjLMxOByST1NID73/wCG0/C3/Ph4
g/78Q/8Ax2j/AIbT8Lf8+HiD/vxD/wDHa+Ya4b4kfHrTvhz4ptNF/svWta1S6hWf7Pp0UTNGjuyR
582RAS7I4AUsfkOQMrkA+1/+G0/C3/Ph4g/78Q//AB2j/htPwt/z4eIP+/EP/wAdr4Dt/wBsXSbq
0W4Twz4nMDwR3KyGXTgjRSSeVHICbvGxpPkVuhbgc8VcP7U1mpk3+GPEMXk/afM8y80pPL+zY+0Z
zeDHlZG/P3M/NigLH3h/w2n4W/58PEH/AH4h/wDjtH/Dafhb/nw8Qf8AfiH/AOO18PWv7QYvbtII
vC2tNPJNHbLH/aejh2lki82OMA32dzRjeo6lfmHHNZMvjy110fbLfR/FcL3CRXUM8HjDS/LUTyGO
CRUbUjEyPKNqAqUZhtw3K0Dsfe//AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7Xwv4W
+L+p6Nei28TWLRafNcrZ2mptfaY0nmG5SzMU0Nvdyszi5lt4mkiQKJLgBo4QuT6VQI+nv+G0/C3/
AD4eIP8AvxD/APHaP+G0/C3/AD4eIP8AvxD/APHa8o+H37MmpeLfBem6rfa/Y6fNqUC3S28OntcK
kbjdHlzKnzFCpI24BJGTjNbH/DIcv/Q2Rf8AgmP/AMk07Ad//wANp+Fv+fDxB/34h/8AjtH/AA2n
4W/58PEH/fiH/wCO1wH/AAyHL/0NkX/gmP8A8k0f8Mhy/wDQ2Rf+CY//ACTRYDv/APhtPwt/z4eI
P+/EP/x2j/htPwt/z4eIP+/EP/x2uA/4ZDl/6GyL/wAEx/8Akmj/AIZDl/6GyL/wTH/5JosB3/8A
w2n4W/58PEH/AH4h/wDjtH/Dafhb/nw8Qf8AfiH/AOO1wH/DIcv/AENkX/gmP/yTR/wyHL/0NkX/
AIJj/wDJNFgO/wD+G0/C3/Ph4g/78Q//AB2j/htPwt/z4eIP+/EP/wAdrgP+GQ5f+hsi/wDBMf8A
5Jo/4ZDl/wChsi/8Ex/+SaLAd/8A8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8PEH/fiH/47XAf8Mhy
/wDQ2Rf+CY//ACTR/wAMhy/9DZF/4Jj/APJNFgO//wCG0/C3/Ph4g/78Q/8Ax2j/AIbT8Lf8+HiD
/vxD/wDHa4D/AIZDl/6GyL/wTH/5Jo/4ZDl/6GyL/wAEx/8AkmiwHf8A/Dafhb/nw8Qf9+If/jtH
/Dafhb/nw8Qf9+If/jtcB/wyHL/0NkX/AIJj/wDJNcn4p+B2oeEPiT4e0abVLO70/wAROIYbtLZo
pYpBLGjhoy7DAEqEEP8ANkj5cclgPa/+G0/C3/Ph4g/78Q//AB2j/htPwt/z4eIP+/EP/wAdrkpf
2PLOCVkbxdhkJUj+ym4I/wC2lN/4ZBsf+hv/APKU3/xykB1//Dafhb/nw8Qf9+If/jtH/Dafhb/n
w8Qf9+If/jtch/wyDY/9Df8A+Upv/jleK/ESG08JfF/XfCNrcS350Kzsrma8eEQiR7jzTsVNzHCr
GvzEjJYjaAoLAH0z/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH/wCO1+a7/tC+J5JyRLYq
kjuVVbf/AFaiRlAySc8L1qt4e/asXxL4+vPClv4u8PTeKNOgFzeaPBcW739rEQhEkkGTIikSx/MV
A/eJ/eGQD9Mf+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha/PrTPiydQ8D/8JPJ4wsovDf2H
+1DqwltBYi08vzftHnFSnleX8+/O3bznHNW/i14l8Q/DjwZaa3Z61Lcuup29rLbXdtC0c6SLIT8y
KrKQUHrkZHHUAH31/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH/wCO18MyfFS+uv2cbXxZ
FDBDqFzp0dyI2y8aO5Ue2QM57VwC/HrxQbt4TcWh8tym4WwGcHHqaAP0l/4bT8Lf8+HiD/vxD/8A
HaP+G0/C3/Ph4g/78Q//AB2vzg039oW5v9KF+/ibSo7E3o037Sr2/lfavtP2X7PuOR5v2n9zszu8
z5MbuK67wh4rvPGto1xY+Jjd26TzWryWgtpUWWGVoZoyRGQHjlR0ZeqsjKcEEUAfeP8Aw2n4W/58
PEH/AH4h/wDjtH/Dafhb/nw8Qf8AfiH/AOO1+eXxP+KviH4RfEXQrIXq6xYazBbu8V1BHFJbs955
DFXjUbvlwcFRjnrkEdR8e/iHqfgQ6WmmNbxvevKZGlj8z5Y492AMjGT3oA+5f+G0/C3/AD4eIP8A
vxD/APHaP+G0/C3/AD4eIP8AvxD/APHa/Lbxv+3DafC37H/wl3jPwj4VGo7/ALKdVvLex+07Nu/Z
5rDdt3rnGcbhnqK6/Tvj1PfeCv8AhJZPFOmx+HfsP9pnVVe3FkLTy/M+0ecQU8ry/n3527ec45oA
/Rr/AIbT8Lf8+HiD/vxD/wDHaP8AhtPwt/z4eIP+/EP/AMdr4d0qXWdRxv1u+TP92G3/AKxGsD4a
fFvW5fj3qvg3UpoNSt7Ge+WK98oQSlYXjChkX5ej9R3BPcAAH6A/8Np+Fv8Anw8Qf9+If/jtH/Da
fhb/AJ8PEH/fiH/47X57fFb4y674W8d3thYvaR2tosAAaDe7M6sxJOfbGMVx3jL9r0fDPRotS8V+
K/DfhbTp5hbR3WqXFvZQvKVZhGHlIUsVRyBnOFJ7GgD9Ov8AhtPwt/z4eIP+/EP/AMdo/wCG0/C3
/Ph4g/78Q/8Ax2vzk8EftD23xB0bRtR0rxvouo6d4ine10u6sbm0ng1KZFlZ44HUMsrqsE5KqSQI
ZCfuNjtr0a63hnVLmLxDeQXFpYXF1Ez2lvIm+OJnAK7FJBK4OGHXrQB9y/8ADafhb/nw8Qf9+If/
AI7R/wANp+Fv+fDxB/34h/8AjtfCX7Nnxa1H4seF9Ul1OG3juNOnig3xHiUNDHJuIxwcsenH06Dz
vUf2ntb0/UbSK4v9ItZNWuZILKF41RpnXzX8pAzZdxHDI5A52oxxhSaAP0x/4bT8Lf8APh4g/wC/
EP8A8do/4bT8Lf8APh4g/wC/EP8A8dr869M+LniTUSN15Guf7sCf1BrpNJ17XdTA3atcpn+7BB/W
M0AfeH/Dafhb/nw8Qf8AfiH/AOO0f8Np+Fv+fDxB/wB+If8A47X59eP/AIi6l4e8AW/iPQvE8Gsx
Q60NKniMdvPBI6PPFPEXiVSkkc0LI4ySGR1IVhxvyfFS+uv2cbXxZFDBDqFzp0dyI2y8aO5Ue2QM
57UAfc3/AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7X5qyftCeJ4bqSI3FmxjcoWFsB
nBxnGay/h3+2E3xb0iTUPDHinw34j0+GY20lzpU0F5DHKFVjGXjZgGCspwTnDA9xQB+n3/Dafhb/
AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O1+dlt8W/EdyR/p8S59LZP8K0bXx54hucZ1ULn0to/8
KAP0C/4bT8Lf8+HiD/vxD/8AHaP+G0/C3/Ph4g/78Q//AB2vgTT/ABzqOpa5PpieJ4G1K0giuri0
SKAzwQytIsUjJjcqO0MwViMMYnAztONy1h1y5Az4guFz6WkH/wATQB9v/wDDafhb/nw8Qf8AfiH/
AOO0f8Np+Fv+fDxB/wB+If8A47XxJdi70y9062vPGhs7jV7g2ljFNDao97MIpJjFECuXcRQyyFVy
dkTt0UkWvEfhbXdN8Katew+K7xZrGxuLmPfYW7oWjiZwCAoJGVGcEfWgD7R/4bT8Lf8APh4g/wC/
EP8A8do/4bT8Lf8APh4g/wC/EP8A8dr4S/Zs+LWo/Fjwvqkupw28dxp08UG+I8ShoY5NxGODlj04
+nQcFcftE+JvOLCWxVZHcoi2/wBxRIygck54XrQB+lX/AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw
8Qf9+If/AI7X5o2n7SutX2sT6emp6a1/awx3M1sqIZoYpGkWN2TOQrNFKFJGCY3AztOLvh34+ax4
s0az1HT9Y0++0/UIUuLa6tY45YbiJ1DJIjjKsrKQQwJBBBFAH6Q/8Np+Fv8Anw8Qf9+If/jtH/Da
fhb/AJ8PEH/fiH/47X582vxD8RXOM6mq59LaP/Cpp/iDqNjd2Fvd+JrezuNVnNrZRSxwI95MIpJT
HGCMu4iilfauTtjduikgA/QD/htPwt/z4eIP+/EP/wAdo/4bT8Lf8+HiD/vxD/8AHa+HLRtducZ1
+dfpaQf/ABNSaxLd+GfD97q2reM/7L0vTLeS7vLy6itYbe0hjUu8sjsoVEVQSWYgAAknFAH2/wD8
Np+Fv+fDxB/34h/+O0f8Np+Fv+fDxB/34h/+O18dQeC9Zmx/xVV8PpZ23/xFcJ8NPi1rcnx71bwZ
qU0GpW9jPfLFe+UIZWWF4woZF+Xo/UdwT3AAB+gH/Dafhb/nw8Qf9+If/jtH/Dafhb/nw8Qf9+If
/jtfnr8WfjPrvhTxzfWNi9pHaWaQABodzuzqzEkk+2MYrhrj9sx7LxzZeF7rxP4atfEupQm4tNJk
mhS+uogHJkjhLb3UCOQ5AI/dt6GgD9Q/+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha/OS2+
NPiW463kC/S3WtC1+JniK5xnUUXPpbR/4UAfoX/w2n4W/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+I
f/jtfnj4X+MsnjPUbq00zxhpmoXVhn7VDaG2mktsTTW53quSv762uI+cfPbyr1RgNzwv4o1Dxnod
lqmmeKo9Q03UoEurS7tIreaC6hdQySRuoKujKQQwJBBBFAH3l/w2n4W/58PEH/fiH/47R/w2n4W/
58PEH/fiH/47XxTbaVrdx18R3S/S0g/+Ip2i2N14hvdQtrPxs1zc6TcC0vooIbSR7KYxRzCKUBSU
cxSxSBWwdkqNjDAkA+1P+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha/Pb4s/EvxD8F/iZom
m/2gmuWOrwW7ulzbpDJAz3nksVZBz8uDgjjnrkFfa6APp7/htPwt/wA+HiD/AL8Q/wDx2j/htPwt
/wA+HiD/AL8Q/wDx2vlHW9c/sspFFE09zMD5aL/Xv/8Aqrmte8cReELy3tNc8V+H9E1G9BNtZ313
BBPc+yK2Cx+lXTpTqS5aabflqJtLc+0/+G0/C3/Ph4g/78Q//HaP+G0/C3/Ph4g/78Q//Ha+L9O+
Jg07V1sdRYO00iokqlQFJIHPQY75rsqgZ9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8PEH/fiH/4
7XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w2n4W/wCfDxB/
34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH/fiH
/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/AA2n4W/58PEH
/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8PEH/f
iH/47XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w2n4W/wCf
DxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/58PEH
/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/AA2n4W/5
8PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/AJ8P
EH/fiH/47XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w2n4W
/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n4W/5
8PEH/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/AA2n
4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9Pf8Np+Fv8Anw8Qf9+If/jtH/Dafhb/
AJ8PEH/fiH/47XzDRQB9Pf8ADafhb/nw8Qf9+If/AI7R/wANp+Fv+fDxB/34h/8AjtfMNFAH09/w
2n4W/wCfDxB/34h/+O0f8Np+Fv8Anw8Qf9+If/jtfMNFAH09/wANp+Fv+fDxB/34h/8AjtH/AA2n
4W/58PEH/fiH/wCO18w0UAfT3/Dafhb/AJ8PEH/fiH/47R/w2n4W/wCfDxB/34h/+O18w0UAfT3/
AA2n4W/58PEH/fiH/wCO0f8ADafhb/nw8Qf9+If/AI7XzDRQB9K63+174b1nw7q0cNlrSPDp11dE
yxRqu2GB5WGQ5PKoccdcVDe6t400Kx3zaF4TWONR97xDcBsdOQLIjP4n6188W3/II8Qf9i/q3/pv
uK+nvil/yA7n6D+YoA808aftcn4V2/2jX9H04W7SLCDp2py3LB2DMAQ9vHgYRuQT06c0V8//ALWv
/InD/sJQf+ip6KbVmB9xftRf8kK1z/t3/wDSiKvkTWNQ+0eJ2t/7Q0a4+z6daf6Lp8O02m5XOZn/
AIpm6t6AL65P13+1F/yQrXP+3f8A9KIq+RNY1D7R4na3/tDRrj7Pp1p/ounw7Tablc5mf+KZureg
C+uSgPgz/g4J0L/hKP2Y/hlpn9g/8JT/AGh8TtItv7G+2/Yf7W3w3S/ZvPyPJ8zOzzMjbuz2rw39
kb4XT/sif8FIPhhbT/AvWv2Z9I8c6Xq+mGytvHX/AAl1p4vukhSSKO4fzSLYRDe6nDFnKgADcy/o
J+2j+xf4e/bi+HGkeG/EWueLfDkWha1Br9lf+HL2KzvoLqFJFjZZJIpNuPNLZUBgyqQRjng/gZ/w
S08K/B741aT4+1j4ifGT4p+IPD1vcQaM3jvxMNYi0Zp1CSy26+Um2RkG3JJGDnGQCM6cWlPzcvmn
TUbadb33ulo7FYlqpCMV0il81Nyv6aq9rN6q58g/s0/tieJ/2Qf+CRXwp1Twz4r+B3heSe+1uS7b
4gXmotNdRLq1wgSysrCNp7hg8il2XIjUcqQxZfUPAH/BVf4t/tIfBn4EWfw38IeAYPil8Xxq8txN
r812vh+xg0t2jnmVYyJyJSAVXcxTlTv+8PUk/wCCNfw40/wN8PtF0rxh8WPDs/w4+3xWGraN4iXT
9SvLa9uWubi1nliiUGJnYj92qPtwNx61Y1H/AII7/DN/gz4N8HaV4i+JXhh/h7qd/qPhrX9F11bT
W9GW8keSe2iuBER5JL4+ZWfCj5ySxbec1KcpS1vK/wAtf802tL2kuzbrNOcpQ6uT17Nt7d/PW10+
jifJPwk/b+1v9hL9m344eI9W0vwzZeN/Ffx71fRT9snurnQ9Gu3t4ZJp5WgjNzNbx+W2FjQSOCOA
civeP2Dv+CkPjf8A4KF/Df4l+E/D+sfDe0+JnhRLT7H4o0ey1F/D9xBdMQZ4rS9SO682BVkGyUbH
kCc7Ca9F0T/gkD8LNA+AuveALfU/HYtNY8WHxtaawdZH9taFqu2NVuLS6Ee5WUR8NL5jEsxZmOMe
sfsu/suwfsveGtQ09fHnxQ+INxqU4mkv/G3iSXWLmJQMLHFkLHGgyT8iBmJ+YthcJKLTjU1XLFK2
m0ILTtqpfJ77WipJ8ynDfmk3fXeUnr3uml69O/xz+wl8FNe+L/8AwTh+Ofgi4+JuoeGtVvPiN4gs
9U8ZyQ7rlooriE3U7jzYwhmjSQMd4CiRjyBisb/gnX8Qvhb+xwnxw+KugXOteCf2VvtemaVoFzfL
f38WrajFm3utQt4iJZvKklZI94GGK4O3yyqfU+rf8E1fBupfsyfED4UxeI/HGn+H/iVr934h1a7t
b22S/WS6nSeaCJzAUWBigXayMxQsCxzmtH9i/wDYK0z9iOzu7PRviN8WvGGkzWcNjaaZ4s19NQsd
IiiJ2i0iSKNYeDg44wqjAxU02077PkhHbdqKTva2is1FbJvmtdIU0uVx39+cvk5XXz2be9ly31ZS
/aB+OXhb9pL/AIJmfE3xr4K1T+2vDOt+B9ceyvPs01t5wS1uI2Plyoki4ZGHzKOnpX5JaJ+z/ffB
79j7wF8WLH9mrWvh0dJGjatcfF/SPiR/aV5HbtPCJbyPR/OUAzIzDyztCeZyQATX7ofFv4a2Pxm+
FfiXwhqkt3BpvinS7nSLuW1ZVnjiniaJ2jLKyhwrEglSM4yD0r5L0b/ghz4HtfD+k+HtW+L37RHi
nwRpL2+PCWr+Mkl0K5igdXjt5LZLdB5QKL8qFcYGCKdL3MQ6kdNYNX1+Fybvaze62aT6ouo1Kgqc
9fjvbT4lFK17ro9Xe3Q8l/bg/wCC6ep/Af8AaO8QeEvCM/wxstM8E29tPeJ4rg1ia/8AFTTW6XPl
WDWMDwW52MqB7khS8inhVarH7Xf/AAWp8YfDzUvhleeEbb4c+B/CPj/wdB4oi1zx/Ya1fW13PKwD
WEB0uNyJYAQXLKQd68p8of6U+OH/AATC8J/F74xXfjnRvHXxb+Fmuavb29trH/CB+JTosGuC3BWB
rlBG25kQlFKlcKfXmtD9pX/gnhpX7Sa6ZG/xT+O3gq00/TP7JntPDXje4gt9WgxtBuknEwlk27g0
hw8gY7y+BiI3UI9+br2tL824tb2ttvcVud32t+Pu/laS8777W8H8RftP/HHxr/wVB+FmieF/Efwz
m+G+veCl8TtZwX11cWN3aM0a3kwuEjQzTBgwt2ZREEwzIrFqx/gR/wAFbfHPjL/goJoXwi1vVfgL
410bxS99Gkvw7u9UvptDEdu1zCZrydFtbkFFKN5A4YMW8srsb6B8Xf8ABLf4ea/4n+GWpaVq/jrw
hH8LNJ/sDT7PQtZ+zwanppdGezvC6PJLE+whgHUsHbJztK4HwQ/4I9fD34DfEDwb4j03xl8WdVuv
h9eXE/h611fxILyy0m3nheGSyhgaIJHbkPk7QJCVXMhGQTkVnF6r3/WzcuW/onH0s7W0TyfNyP8A
maj8moq/3yvfvdXT1PnL/gh5+13qvjHwv8Ovgv4Uk8NQ2PhXStZ1/wAXz6lFM97MJNXuFt7axVZE
UModHkkYSKFlRcBq/TjUbl7LT55o4XuJIY2dYk+9KQCQo9z0r5f0v/gnD4a/Zu+GPgW9+H8fjHXP
FfwWXVb3w3F/bNpZXXiIXjyzTaXdztB5P2eWRwASilNqsGB3E1fCX7WP7T3ibxVpum63+yI+g6Nq
F1FbX+pp8VtKnbT4HcLJOI44w7lFJbahDHbgEGtq0va3jB+876vRat2d3oklZW6Wu97vao0q06r+
FttLra93otdd/nZbWXjn7An/AAV/8Y/tI/tHXfhfx5e/BzwzGItRZvCMUOuWPizSZLd2Ihka5g+x
XMqoh3xxSI5BLgLsaOuB+B//AAcLah8Rv2g/C1tqMfw0/wCEL8aa9FolvoFjHq6+KdCSaXyoru6u
JYF0+VAQGZIX3YlXHKtX1z8Of+CXHhTwT8eNM8fav8QvjP8AEG68Pz3Nzomk+MPF0ur6ZoksylC8
COokJWNmjBkkfKnLbmAYJ8G/+CW3hP4CfFS117wv8Q/jVpnhzT76W/s/A8PjGaLwtavI7SFFtEVW
MfmMX8tpCrEkMGUlSqTjzwc1olqvnd99WtFva1+bXTKsm4zUN29PufponZ9L9tNfAPHP/BTT9orR
tK+MvjjR/B/wkvfhl8D/ABze6Bq63M99DrWrWUE8CbbZQ7RJMkchZpZDtYuu2L5CHv8Awn/a1+OX
in/gof8AFwzeIPhqnwx8LeErXW7ay1u9utNtdOsrm2kuLKVplRljlLFPtUsiuFQER8ACk+FX/BHO
P4t+O/i/qfxT1D4ieHNK8UfE7Udcj0DR/FCR6N4x0ozQT2pvraMyAjesuBmKYBjkghCvu3xl/wCC
Wvw/+Nvxo1vxlqGuePNLj8TeHR4Y1nQNJ1ZLTRtVtFhkhi86ERF2aISBkw4VWjQ7fvBsIqSpwlu+
Xbrd0ndt9+dqytePvG9XldScV8PM/uVRNW/7dT9fdPkXw1/wVJ8a/tM6D+0L8KPFl98HvFyaX8Lt
e1SPXfh0NUFhbTQxPDJA73oAnDCRWWWDMeMYZ93ydt+wv+2N8Xfg+v7NHgnxv4Z8A2vwz+I/gYr4
el0u7urnXbUadpUM5mu2YLBiVBuEUaEqJVBclDu9m8Af8Ee/APgObU7mTxx8XfEepax4Pv8AwNd3
+veIk1C4fTLoKBEu+HbH5O390I1VBuO5Xr0TS/2CfB2lat8EbxdQ8RSv8BdMuNK0BJJ4GS+hmsks
3N2PK+dvLQEeX5Y3E5BHFdCaSfLu0k+117Wzt5c0Px33M7pq0tlzW+cadlfzlF38uivY+HPgf/wc
Lah8Rv2g/C1tqMfw0/4Qvxpr0WiW+gWMerr4p0JJpfKiu7q4lgXT5UBAZkhfdiVccq1fSP7IH7WX
x0/ad/aq+IenSaV8LLH4TfDbxpqvhe/uAL5NfvFhRvsxhXe8G4P5RlZ9oZXbYoK89P8ABv8A4Jbe
E/gJ8VLXXvC/xD+NWmeHNPvpb+z8Dw+MZovC1q8jtIUW0RVYx+Yxfy2kKsSQwZSVPpv7Ov7Kvh79
mXVfH15oN5rN3L8RfE114r1IX80UiwXVxt3pDsjTbENowG3N6saVPlUVzb8r+9uFr+iU3fzXolNu
8rfzL7rTv6XvDTy+b8f8LfGTUPA/7LXwU8PwWl3ZW+veDNK2aqceTPItlGXtEIOVl2KXIcLuTcU3
+XLsd8KtKn1z9qfxlZW2pT6Lc3fwzsoItQhCmWwdr2/UTKGBXchwwzxleeK9N/Zv8EaX8R/2Gfht
outWiXunX3g3RxJGWZGUraQMjo6kMkiOqujoQyMqspDAEcz8Jf2cPEXhr9pDxXN4ottO8Q+ENQ8I
W2gW9/MImOrILq6d4rq2wFEnlzBX2r5Mg+ZQm8wxQBz1r+xd4jslURfHa5XYAoY+GNGLYHqTFkn3
PXn1q5p/7M3iHwr468O+JL/4+zzT6JdpDbLc6LplvHdC4kSI2btGqM8c7mNfLDfNIImXEiRsvP8A
xb+GE37MWtrezy3t54GmcLaagyy3VxpbkjbaXG0PJJk4WGbDNIdkT5m8trnrfgn8GdT+N+s6b408
c2rW2j6cN/h7w/LtZYwQR9quApKvKysRwSqqxRCUMklyAZ3xHuZNG+Meuazb6tD4fvdEkluYdTmw
YLRPLRplnUsoe1dY181CygiNHVo5YopU9z+CvxK/4W/8LtI8Rmwm0ttSiZntpCTsZXZGKllV9hKl
l3pHJtZd8cb7kXyA/s4a98ZvjXq2o+L7D+xPB9lqLTWmnpeJNLrjRyEQ3EpQ/JH8iSJF1UlXYmQR
/ZvoS0tItPtIoIIo4YIUEcccahVjUDAAA4AA7UAfO/iLx34K+DXjTWtbg04+OviLealci2s9Ts2j
0HwqBJtWWZC2dQuGCh0AxEm8Zw8fPY6nrGoftL/D6fxhexm6+JXhCyjbX5I7dI38WaTHgG+VIlVB
dWpdhIioC8IQqSVSMfPvxdvr1/jR4hZfC/j+4gTVJgJoPB+qzwyASEbkdLdldDjhlJUjBGRg16D4
E+OLeApNL1LSdM+JGl69os/2qxuh4B11xBKFZfmUWo3oysyum4BkZlyM5oAvfH7w7H4f/Ym+IPiH
xWt7ptnrnhPU4/DWmWsRl1TWS1nIEvnjIC22nqx3ebI26VVYIuWiMno3wM/5Kb8Y/wDscLf/ANMG
j14f+0l8Xb/4ufCX4gJPpXxQ8Q+LPFOiX1uZ5/AmtI95cSW8iRoM2gSNAWCqo2og44Fe4fAz/kpv
xj/7HC3/APTBo9AHeeIdetPCugX2qX8vkWOm28l1cy7Wby40UszYUEnABOACa+HviT4qbxjr1zf6
nY29ze3t5Hq13a3Wg3OoxEsTClmHi2IfKg8svIuCyxLtcOZI297/AOCgPxRsPhL8F9O1LWDcnQ5d
bt4r+O3A8yVRHLLEASCRieOFuOoUjoSD8hah+3j8LtW1KzvLq7+Ic9xpwIs3OuXY+xAlDtiAIEa/
InypgDYvHyjAM15tAsrW3khW10a5aGGWETL4Guw07QSb1lAJADXKny1BCqqjLLA3zmyvhmyvrxo0
sNEiSWeSISr4FvmSFbiPesgGSxW2YeWoILMx+ZZk+YZekf8ABQ34b6DqF7d2eo/Eu1u9SZHvJofE
uoxyXbIoRDIyuC5VQFBOcAADirzf8FLfh7LIXk1H4mzMepfxVqpJ/wDItAGxofgiG5eG4Ph2xIJt
blrY/Du+kAzmGS3Yq/b/AF8hVvQRueYq6LS/heltY4/sGO6eG3Ybh8I7uR7h7ebIIy6rvulO0fdR
UXnyH5PFR/8ABTL4bp1l+Ij/AF8Vav8A0np0X/BS/wCF0Wqw3/2bxyb62jeGG4PinWRLEjlS6Kwu
MhWKISAcHYuegoA95+G/hHTdG1HU9PuvDEmqWHiBJPDd3Z2Pw4vvDv2+y1Ca3WeRrzDMkEEDzIAx
iZvLJZmISQ+0/B7xBqGoeHrvSNcuftniTwndto2rXHlrH9tlREkiu9qDYn2m2lt7ny0LCL7T5ZO6
NgPh+b/gpf8ACa6tdUhm0rxhPFrgI1JJPFGtldQBjWI+cPtWJMxKqfNn5VC9BivYP2Z/27dJ/as/
aqhfQtJubGB/Dc1jqkywyGOZ4bhZrFWZyQmxZtTI2YL+ad24IhQBn2lafF648OftW/CDQm1LUIdL
vPhhqEz2AuCtvd3EUmibJPL3BXeNJZAGxlRI2MBjn5ZvPip4g8QeFdZ+IXiTxP8AELxX8PvB4164
ubXwh8SLvRfEPhzZ4h1fZqAtElig1O2NtFbokV3OUjSwkWGCcyNG30T418HfDX9ov4caHpPxB8O+
GvENnpkNuBpfifw4dTiguIIfIEyKYJY8soJVgQwWQggciqmvfAH4J+KtY8O6hqnhL4b6lqHhCGG3
0G5uvB7TTaJFCwaGO1drQmBY2AKiMqFIyMVVO8eS/wBlv8XJ/euay16XuthSaalHpK1/lZWT10dt
dPKzTZ1//BQz4oanD+xJ8RtS8MeKfEvg7V9L0G51G21HSBbpc/u4mfy900cmxXxgtGElUHKPGwDD
xX4sfGXVn+O/ifxePE/jOy13wV8SfCXhTQNIt9eurbSb7Sb6LS/taT6cJRa3Mkn2/UGE8sTyL9nQ
I6GEY9b+Jvhn4efGvwnLoPjK38L+LdCnkSWTTta0C4v7SR0OVYxS2zISp5BI4NYujfBL4N+HPE/h
7W9O8M/D2w1nwjZf2boV/b+EpIrrRbXDj7PbSLaBoYsSSDZGVXEj8fMclP3aim1omn9zTf3pcttr
Sbs9mN3g494teV3b/h777JNWTXDfBX9qD4p+IP8Ago9pKeOPB3xQ8LaXrvhbWxFo9xquizeH9Pht
7vTxb3KJa6hJJNKQzh5pIhIGu0REWJHYeb/Db/go34v+B/wi+INpoGhaUn/CMeKtUtdP0/U4Ee/1
651Xxdc2sWowM95bWwsbZpSjRyTI802Y3kskEc0/1fLqPha41+DVpL/S31W1gktYbxtKvDcQwyMj
SRrJ9n3BGaOMlQcEopPQVzut/DP4VeJbVINR0fwTqEEcV9Asdz4YmlRY75t16gDWpAW4PMo6Snlt
1RGLVOEP5U0/O8m9+9na+ttWldK1XTk5d2n6WVvu8u2hxg/4KK/Ff4E/CHTvF/xl8DwaFptprN7p
eqGKwt7e6vIWsTPp11FBa6pqMdv5l2v2EwtcTPJJNC6mPd5dfTfwo+KGtXfww8PS+MY7KPxZNp0E
msJpsLRWcd2Y1MqRK8jsEDlgNzE4HWvnhf2cfhHpHgOx8K+Hbbw/4K8M2muW3iCXSvDWgzaVZ39z
byJLH50cVoAymSKFmxgt5SAkrlT6b/wmejf9B63/APAC+/8AjFaXundatr7lFa+rk3fppGyXXO2q
t53823+itb11vY9a/wCFkWv92f8AJf8AGj/hZFr/AHZ/yX/GvJf+Ez0b/oPW/wD4AX3/AMYo/wCE
z0b/AKD1v/4AX3/xipsyj1r/AIWRa/3Z/wAl/wAaP+FkWv8Adn/Jf8a8l/4TPRv+g9b/APgBff8A
xij/AITPRv8AoPW//gBff/GKLMD1r/hZFr/dn/Jf8aP+FkWv92f8l/xryX/hM9G/6D1v/wCAF9/8
Yo/4TPRv+g9b/wDgBff/ABiizA8N+En/AAXw8IfGH9s+b4B2fwV/aC034i6bctFq9tqGi6VHbaFA
uwve3My6iyi1CyRusqbxKJYhF5rSxK/0/wCPddj1/wCKfwzljDgJqsqncB/z2sT2rhYL7wra+I7v
WIr7So9Xv7aGzub5dJvBc3EELSvDE8gt9zJG087KpOFM0hABdssu/idpVn4+8KzmW8uNP8PXLaje
XkdjOU2tLASkabPNkdVgLEBMneAu45osxGB+0B8R/ij8Nv2sNW1TxL4u8d+BvhxBr1hbaHeaf4X0
rXPB1/ayeQssGqeWH1m1uXle7H2svbWEKpbF3Y7kmy9N/wCCqupa18dPGvg6w+Go1SLQtG1zV9Dv
LLVrqUa+dIubeC6txMbAWHmnzmIS1vbto3j8q4FvKSi0vGvif4B+OvjBf+NLz4f/ABi/tHVdRh1W
/soF1q10bVruHyxDc3mlxXC2N1MohhHmTQO37iLJPlpiL4d+IPgJ8K/jEfHuifD74wQ+Jl/tEQS3
Ka1eWtimoTpcXkdvazXD29vHLMiyGOKNEDDIAJNTC6iovopfe4pRbe7tLfZW6XbvcmnJu3VeWibu
uqV1bu79bWR0/wAaf+CocPgrw+b/AMG+Dp/HkGr+IIfD3hq6sX1G9tdalGnHULqYrpmn390kMMYM
YeK2m3ShlYRKrSDzzw/8ULj41fF3xD4qvPD2teE7zXNA0K5uNH1a1mtbzTpDFOHieOaOOUYYHBeN
GK4JRScDcute/Z/n+CuifD6D4bfFTS/DXhm+fU9HGl2mradqGkXLvK7zW19bzpdwu3nzKTHKuY5X
jPyErXOeBrXQIfiJr/8AwiHh7VvDfhC00jSNN0q0v7Ga1eNLdJkK/vcs5HyksWYkvliWJq1a0vVW
9La/e9Vvp1M7SvHXSzv63079N9d+nU8C0Sz+0sTj/lrIP/IjV5z8A9Dew8D+Afh7qfg3X9S8b+EL
izutU1KW0u7HTorqM5vNXj1UR+XcNc+ZM/lxu89x9taK5jiR7ww70Hxuh8L3t5Yy2awXVldzRTLd
20sjowkYFf3bgcHPPOQRz3OzY/tcDTwAllpDY7mzux/7UqSjw7wT+zJ4pj/ZE8a6BPpnxOa+8K/A
G30TTdHbUtWa0uNee38QWupW8dt5nkXr+YtssYCyosZtGt8RGAn7o/aqsFh+BcbYwV12xx/3zPXk
Vl+3pcWAwmkaCx9Tb3g/9nrO+KX7bD/FLwaujXuk6ba2yXSX3mWUdz5u6JHxnzNw2DcS2MHA6gCg
D06z/wCTIdL/AOwNb/8AoSV4/wDFDVda8KfC/wAQ6l4b07+1/EsVnIujWRgkmjur5xsto5AhBWIz
NGHcsiRpud3RFZ19fvI59I/YZtC9rcSS2uhQyyRRD95tXazEA+ignpkgcAnivFbD9pC1tArRW9jt
x0ls7hmb3JWQDnrwKAPIPh18A/G/wi8Ly+CLrwkY9Lm13wDqulzaXfXGv+b/AGdqmkWF6ZrgWdss
PlWdjYTFHiGd11IruiSJb/Vv/BP/AODLfBv4ZeI/D9xb+Ibe6t/GmvXLjVr68vjJDcajNcWkkU9w
7iRHs5bZ2aN2HnPN5n+kfaBXGWH7ZDacylLDRm2+tpdjP/kStmy/4KBXdht26L4ffHrDejP/AI/Q
B0n7Y1qLf4qeBiBgta2uf/BpW9+1au+78Oj1kuB/5DWvGfHf7RMv7QvxH8LtJptva3ltc2dlCllH
N5Tr9r847vMBO84bHOMKeOCa9V/bT8UL4Mh8M6hNbTzWy3c0TOq7kVmiBVW7/MFbBHp16AgHiP7Q
HhK+8QfDbS4NPsrq+nj8XeGbl47eFpXWKLXrCWWQhQSFSNHdm6KqMTgAmvA/2i/Cvxb1nWPiBa6X
Y+P9Ut/EWn+K9G1PS00nUru2is20XVG0xY5vtH9nyfaHhsjH9hsRNEWS3ubgzyOLv6Lsf2mIdPPy
W2mP7NZXf/x2trT/ANtJtOOV0zRZPY214P8A2pQB037GGna7/wAJ74u81fiGvhgWGmf8jl5gvv8A
hIPMvv7V2b/k8ny/7Ox9h/4l27f9l482tPwdCIP26vEiDoLnVv8A0ZBXO2f/AAUHubI8aD4dcehi
vR/7PSfs4fEE/Fr9qa911bUwSXltfXt0qI4ijaWWMDZuGdmUKjJJypGSegBp/GmHz/jDq4/6Z2x/
8h15P8ffhjrHj7xP8JoNHv8AXtFa08XS3Fzquk20E82mRf2HqyeYfPhmhVGd44t0kZGZgBhiprvf
2jfiTH4C+Ompw3No+66tLaaF5omkikXaVLLsIbghlIJHODjGM87YftTx6cBttNKkx/esrsfyloA0
fG/wGz8bvgR4hW11XxFrOga9LY32szx+bJbWn9gayrzOsarBb+fcPbiVoo41lcWykERwqn03Ppan
wbroI66PfZ/8BpK+bbD9uCTThhdJ0OTH963vB/KSrt7/AMFBrqfQ7+zOh6AqXtpNavIsd4HRZI2R
mXLFdwDHGQRnsaAOw/Yf/wCRU8Tf9f1v/wCkkNfI37dPhzxLrXwy0m48J2eu3Wtabda7cW8mkRSv
dWsp8Oa5HBIhiG5WM8kKIRg+ZJGB8zAV9cfsNSi88G+JrmOKaO2l1NUi81SG+SCNCDkD5gVwePy6
V4xB8bofC97eWMtmsF1ZXc0Uy3dtLI6MJGBX924HBzzzkEc9yAeV+OfDnj3wbZ65pegW3xQ1S38P
+KGh8KW0WoXp/tHzNK06WJZNSKzznbez3rRy3yXGmfupre6CD7M0OhcaN8YfFHxY8U6DfxeONOsr
zxLbQ376Vfa+r6jpj+LtLW0ltporWOxsEh0R7pZhYXplkSV5LlRLDKYvXbH9rgaeAEstIbHc2d2P
/albVl+3pcWAwmkaCx9Tb3g/9noAp/D/AODbfA/9jvxH4fuLfxHbXlr8VNTu2Gr395fmWG51C9ub
SSGe5eTzEks5rV3aJ2HnNN5p+0/aBXpNn/yZDpf/AGBrf/0JK8x+KX7bD/FLwaujXuk6ba2yXSX3
mWUdz5u6JHxnzNw2DcS2MHA6gCvTbyOfSP2GbQva3EktroUMskUQ/ebV2sxAPooJ6ZIHAJ4oA+dv
2hvB+o+Ofhpf6fptv9vka+sri6sPMVP7Vs4b2Ga7svnIjb7RbJNDskZY383bIyozEcf8RfFl1480
DXfEvg3wZ4uluLXTYdPvL2Vr/wAMX9/D9sheS2jhe1a6lWK3N1J50cBmj85o7JmnnlMXoC/G/TZG
8xbe1Abn57S4Zj7krIBz14HerMPx+src8Wmnt9bS6H/tWgD530rXfEnhnw14U0Lx9e/E5NCufiCT
ZPpVtr1rqWp6LL4ev5YQPs9zc6i2b+3llaCa4e4hVYzLFBGY4l9J8Kt8Q7XxN8NpPs3xHvi+qzw2
UE9xc2sEWjNq8/lXFzLskV7iPSBbiaDWEWaUSIbaeK/juBJ6FcftAaRe3djcXOh6Hdz6XObmzkms
bl3tJTG8RkjJkyjGOWRNwwdsjjoxB2Lf9ryG1xjR9JbHrBdj/wBqUAGp/Ea1+DP7YfizU9a0bxvc
aZrngzw/a2V3o3hHVdagkmt77W2mjL2VvMqOq3MBKuQcSKRmsKOP4y/8I34g/wCESHi3/hbX9gap
/wAJP/au7/hGf7R+wz/2Z/Yn2n/Rf+Pz7P5PlfJ9k8/+0v8ATfKrq7f9t5bXpoGjN9Yrwf8AtSr0
H7f5twMeGNDbHqt6P/alAHC+KPBOueM7/wABf8Kcf4u2sen+L2uUv/HdtqskGnTnw54ghlkifV45
b+Dd5tpF580U1jHLNbNHBcSC7gk+n/gReaX4i/ZOjutI07x3pGn3mgX8y2HjR79tesnaKdpIro37
yXBdHLKCzum0L5bNH5ZPk0P/AAUblgGB4S0A/wDgb/8AHKNY/wCCkE2p6Ff2R8J6HbJfWstq8sTX
e+NZEZGK7mZcgMcZBGe1AHTfsP8A/IqeJv8Ar+t//SSGvLwuX/4HJ/6MevT/ANhqUXng3xNcxxTR
20upqkXmqQ3yQRoQcgfMCuDx+XSvD5/izaaPf3dlc2XkXdjdTwzLdW8rujCRsr+7cLwc885yOTjJ
APOfG/w0165/an1fxpoWmXM2qeHdB0D7G2BDHrFv9s1hdR04SsVV2ME0cqRtIkYuY7F5SEXNcp8O
4PHPw9+Gvwx0g2Pjqz/tLw18OdPtrazsb2SOxntNU3aylyIlK2f+hyQrKbjyxKilMv5bqvu0Px3s
YMYtrA4/6dLof+1auW/7Slpb9LDTW+trd/8Ax2gDxLX/AAZ8RdN0HxTq2my/FFtZNh4/8QWaLqWq
Sx/2pp+rhPD8ccBkMflPbTS7LRU8i7QKXimEaFfo39prUm8KeKfg/wCIJNM8Qalpnh/xlNdaidH0
W71ee1hfQdYt1kMFrHJKU86eFCwQgGRc4rNt/wBrSC1xjSdKb/t3ux/7Uq/b/trJa4xoWjtj1ivB
n/yJQBj+KvGHi/4heKLnWPD8HxDt9avNn/CtIxpWpaZoa7UVLv8At63mjjKfv1mMv2xBuszbtpub
0yE878avDfiHxd8IfjbpNzY/GnU/iZqejeNLR7O0h1Cfw5d6VJBqKaTFGkgOmu7W50xQunA3xnIE
ox9ur0i3/b3+zdPDWht9UvR/7Uq7B/wUVkt+nhPQW+v20f8AtSgD0L9lVdSt/Fvj2y8T/wDCYXPj
Ww1CGLVdRvPt6+HtWiZGltZtHjl/0WGERSCKSGDMscsJS4lunVLu45vwfCLf9uvxIgxgXOrdOn+s
grKi/wCClc8I48HeHjj/AGr7/wCOVS/Zx+IX/C3P2przXktHtpL22vb26RVby43lkjA2ZUfJlCoy
SQVIyT0ALXx7Gfizq/8AuW3/AKLNfJXxktr7SvGnjG10/RPEk11r15bXceiDRLvUNL8VyJa2qxXc
eo20anR74TW8dsk0lz5dt9kW5MOXWWvp39pjx/B4O+N2p215aPm6tbaaGSWJnidQpXcuwhuCGUgk
c84xgni4fjlYQ9LewP8A253X/wAdoA8X8cx+J/8AhC/ib9kHxf8A+Fn/AGHxP5H9m/b/AOyfsfl3
v9leTu/0LzfK/s7b9g/0zz8b/wDl7rv/ABL4N8VeBfEtxpOhS+PJ9Xtdv/CvHGpahqOjNuQPc/23
PK8hf980vmfa3OLTyBp+LsSAdpb/ALRtnb4xY6c3/brd/wDx2r1v+1Zb2uMaXpb49be7/wDjlAHN
fsMeAtb8K/HL4m3ep6Pqum2l+Jvss11aSQx3OfFvi2cbGYAN+5ubaXjPyXETdHUmD4C/EbU7r9jj
4W+CrPRfido9z4Y8N6Ta+OIl8I6zpWpwafBYpDdR6fcS28aSXAn8oMts7XLWwumtQbhYSO6t/wBs
2O2HGiaQ31hvP/jlX7f9u/7MRjw5ojfVL0f+1KAOYvU8R48Nf8Jp/wALd/4U6f7W/sr+xv7d/wCE
r/5hv9lf2l/Zf/Ey+5/bW3zf+WP2P7b/AKdVj4TeHPF/hf8AaH1XUPGNj8VH8J+IvHGlrbJZwz2+
ox6sPDGhhNQ1ZtKHkXNgZLW4tZTEy2EVxvEsdxHIklj1kH/BQ17bGPCugtj2vf8A45VqH/gpPND0
8H+H2+pvv/jlAG1+2hAI/i34IcdXtbTP4aoK9+r438fftHv+0Z8SPDEjaPFp95bXNpZQxWgmMTJ9
qExzvBbecNj5sEKeOCa+yKAPPPEfxEt/B/xCv2lYiSFFMZz0Plqa/PP9v/4XeDbnU/E+t/2Jqfjv
4ifFyeLSNMbVJ0eLQZBEyrLAwRTDHGMMclixVRkAsa+7f2lvg3qviZRrHh6KKW6RCbyFpirz42Kp
QEYyFDZBYcKMAk8/D/xUgk1zxlpNze3+uaXeeGbqVms4ZjAkzn5WjuIyuWClfu8YOa+n4Rz6eUZg
sVGbjGzvZtc1vejFuPvcrnGPNZq662MMRSVSFv6/qx6T4A8R33gL4VeHdD1PU31TUdI0y3s7i7Zi
TcSRxqrNk8nJHU8+vNfb/wAN76bU/h3oFzcNI9xcadbyytISXZmiUktnnOTzmviP9n74BeJvjxrV
nfi2+y+GY50e5u7hzELmIShZEh+Vt74DgHGwFCGIPB+87a2js7eOGGNIoolCIiKFVFAwAAOAAO1f
PYmvOvVlWqbybbtort3ei2Noqysh9FFFYjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAsW3/II8Qf8AYv6t/wCm+4r6e+KX/IDufoP5ivmG2/5BHiD/ALF/Vv8A033FfT3xS/5Adz9B
/MU0B8afta/8icP+wlB/6Knoo/a1/wCROH/YSg/9FT0U5bgfeXx58L3/AI0+FGq6ZpkH2m9ufJ8u
PeqbtsyMeWIA4BPJ7V85Xn7NPxE1HUzLLolnHbR28NvBBbvbRbdgO6R280l3ckZPH3RxW7/wWZ/b
W8Vf8E7f+CbHxI+MfgrT/D+qeJ/B/wDZn2K11uCaewl+06pZ2cnmJDLFIcR3DkbZFwwUnIyD+JHw
X/4O7v20P2ifinongnwT8Jvgb4j8U+I7kWun6fa6FqxkmfBYkk6oFRFUM7yOQiIjOzKqkhRi5Oy3
E2krs/Zn/hl3x1/0A/8Aydt//jlH/DLvjr/oB/8Ak7b/APxyvx+8S/8AB1r+234T+Dt/8QLr4Yfs
3y+DdN8VyeCZdVs0ur2F9VjgNw0Mfk6w7SxmIb1njDQOMbZDkV2fgn/g47/4KAePvBuseILL4W/s
q22jeHrfTbvVLrVNai0tNOh1G1t7uxlm+069GY0niuodjMAGcvH/AKyKRE1jhq0naMW/k/66P7iX
Uilds/U7/hl3x1/0A/8Aydt//jlH/DLvjr/oB/8Ak7b/APxyvyX+Mn/Bzt+3n8AfBet+IfFPwk/Z
xstG8OeLG8Dalc2xnvxa60lsLp7Mrb61IxZIj8zAFFdWjZhIrIE0v/g54/by1749+Jvhfp3wj/Zy
1Tx/4Stru51DRbH7RdTv9lj8y4htjHrLLd3Mahibe2Mk2Y5RszG4VewqXUeV3fkHtI2vc/Wn/hl3
x1/0A/8Aydt//jlH/DLvjr/oB/8Ak7b/APxyvw+/4jVv2p/+hB/Z/wD/AAR6v/8ALOvQP2av+Drf
9tz9rz4mL4N+H3wu/Zy1rxNLaTXsNhPFd6dJdRxDdIIjdaxGsrqmXMaFn2I7bdqMREISnJQgrt9E
VKSSuz9gf+GXfHX/AEA//J23/wDjlH/DLvjr/oB/+Ttv/wDHK/EzxL/web/tXeFPEeoaXdeBf2cp
bnTbmS1mezsNRvbZ3RirGOeHVXilQkHbJGzIwwVYgg16Z4A/4Oc/29fiJ4RvfEEXwi/Zy8P6BYTW
dtJqnir7R4YspZby1+2WscU2pa1bpM8tqVnVYyxMTxyY2OrFxpyk+WKuxOUUrt6H6z/8Mu+Ov+gH
/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfiz8Sf8Ag8S/a/8AhD8Rdf8ACfiL4a/s/wCneIPC+pXG
kana/wBk6pN9mureVopY98eqMjbXRhuVipxkEjmsT/iNW/an/wChB/Z//wDBHq//AMs6lpp2Y001
dH7g/wDDLvjr/oB/+Ttv/wDHKP8Ahl3x1/0A/wDydt//AI5X45fs9/8AB2l+2v8AtVfGDR/APgH4
U/AHX/FuvmYWFgNN1G28/wAqGSeT95NqyRrtjidvmYfdx1wK4v8A4jVv2p/+hB/Z/wD/AAR6v/8A
LOm4y5ea2n9f5oOZXt1P3B/4Zd8df9AP/wAnbf8A+OUf8Mu+Ov8AoB/+Ttv/APHK/HP4L/8AB2f+
2v8AtC/8JZ/wh/wp/Z/1f/hB/Dl54t1v/iXahb/YtLtNn2i4/e6su/Z5ifIm5zn5VODXFf8AEat+
1P8A9CD+z/8A+CPV/wD5Z0OLSTa0YKSbsnsfuD/wy746/wCgH/5O2/8A8co/4Zd8df8AQD/8nbf/
AOOV+H3/ABGrftT/APQg/s//APgj1f8A+Wddn+z9/wAHa37an7Unxd0jwJ4F+Fn7Put+Ktd877DZ
Np+oWgm8mGSeT97PqyRriOJ2+ZhnbgZJAJCEpyUYq7eyBtJXZ+x3/DLvjr/oB/8Ak7b/APxyj/hl
3x1/0A//ACdt/wD45X43/AL/AIO2f20/2oPi3pHgXwN8LP2ftb8U66ZRY2R07ULUTeVC80n7ybVk
jXEcbt8zD7uByQK47/iNW/an/wChB/Z//wDBHq//AMs6HCSiptaPr6b/AJr7wur2P3B/4Zd8df8A
QD/8nbf/AOOUf8Mu+Ov+gH/5O2//AMcr8Pv+I1b9qf8A6EH9n/8A8Eer/wDyzrtPg3/wdpftrftA
DxYfCPwr/Z+1YeB/Dt34s1snT9Qt/sWmWpQTz/vdWXftMifIm523fKp5ojFyfLFXYOSSuz9jf+GX
fHX/AEA//J23/wDjlH/DLvjr/oB/+Ttv/wDHK/HH9n7/AIO1v21f2pfi/o/gLwH8Kv2f9d8Wa+0q
2Fj/AGbqNr55jheZ/wB5NqyRriON2+ZhnGBkkCuM/wCI1b9qf/oQf2f/APwR6v8A/LOhwkoqVtH1
9N/zX3hdXsfuD/wy746/6Af/AJO2/wD8co/4Zd8df9AP/wAnbf8A+OV+H3/Eat+1P/0IP7P/AP4I
9X/+WdH/ABGrftT/APQg/s//APgj1f8A+WdSM/XDRv8Agk3ceHNHtNP0/TPH9hYWEKW9tbW/xL1a
KG3iRQqRoi6gAqqoAAAwAABVn/h1pqf/AD7fEj/w5+r/APywr8rfg1/wd7fti/H74oaL4M8LfDj9
nS98R+IrgWmnW1zaX1gl1OQSsQluNWjiEjkbUUsC7sqKGdlU9L4D/wCDpb9uz4m/tQS/BnQ/hB+z
9f8AxJh1K90d9IFnexgXVmJTcR+e2riA7BBL8wk2tt+UnIzpCjUlbli3d2Wm77evkS5xW7P0t/4d
aamf+Xb4kf8Ahz9X/wDlhR/w601P/n2+JH/hz9X/APlhX5Df8Rq37U//AEIP7P8A/wCCPV//AJZ0
f8Rq37U//Qg/s/8A/gj1f/5Z1mUfrz/w601P/n2+JH/hz9X/APlhR/w601P/AJ9viR/4c/V//lhX
5h+E/wDg69/bZ8c/ATxV8TdK+GH7ON54O8EXNva65crFdrc6c9xIkcDNaHWBcmOR5AqyLEUJVwG/
dvtq/s/f8Ha37av7Uvxf0fwF4D+FX7P+u+LNfaVbCx/s3UbXzzHC8z/vJtWSNcRxu3zMM4wMkgVc
ac5NRim29vPW2nfXT1JclZu+x+o3/DrTU/8An2+JH/hz9X/+WFH/AA601P8A59viR/4c/V//AJYV
+Q3/ABGrftT/APQg/s//APgj1f8A+WddP8Gv+Dvb9sX4/wDxS0PwX4W+HH7Ol74j8SXS2Wm21zaX
1gl1O2dkQmuNWjiDuflRWcF3ZVXLMoMxi5NRirtjbSV2fql/w601P/n2+JH/AIc/V/8A5YV0nw1/
YF8QfCSx1GDRfD+pf8Ta8+33k1/4hbUri5n8mKHe01zcSSHEUMSAbsAIMAV+PvxJ/wCDxL9r/wCE
PxF1/wAJ+Ivhr+z/AKd4g8L6lcaRqdr/AGTqk32a6t5Wilj3x6oyNtdGG5WKnGQSOaxP+I1b9qf/
AKEH9n//AMEer/8AyzoaadmCaauj9sfE37GnirxjpZstS8MpdWxYPta+gBVh0IIkBB6jIPQkdCa5
z/h23d/9CZ/5V1/+PV+OP/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdIZ
+x3/AA7bu/8AoTP/ACrr/wDHqP8Ah23d/wDQmf8AlXX/AOPV+OP/ABGrftT/APQg/s//APgj1f8A
+WdH/Eat+1P/ANCD+z//AOCPV/8A5Z0Afsd/w7bu/wDoTP8Ayrr/APHqP+Hbd3/0Jn/lXX/49X44
/wDEat+1P/0IP7P/AP4I9X/+WdH/ABGrftT/APQg/s//APgj1f8A+WdAH7Hf8O27v/oTP/Kuv/x6
tDwz+wHrPg/VBe6f4RSC6VSiyNqMUhQHrjdKQDjjI5wSOhNfjD/xGrftT/8AQg/s/wD/AII9X/8A
lnR/xGrftT/9CD+z/wD+CPV//lnQB+4P/DLvjr/oB/8Ak7b/APxyj/hl3x1/0A//ACdt/wD45X4f
f8Rq37U//Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+z/8A+CPV/wD5Z0AfuD/wy746/wCgH/5O2/8A
8co/4Zd8df8AQD/8nbf/AOOV+H3/ABGrftT/APQg/s//APgj1f8A+WdH/Eat+1P/ANCD+z//AOCP
V/8A5Z0AfuD/AMMu+Ov+gH/5O2//AMco/wCGXfHX/QD/APJ23/8Ajlfh9/xGrftT/wDQg/s//wDg
j1f/AOWdH/Eat+1P/wBCD+z/AP8Agj1f/wCWdAH7g/8ADLvjr/oB/wDk7b//AByj/hl3x1/0A/8A
ydt//jlfh9/xGrftT/8AQg/s/wD/AII9X/8AlnR/xGrftT/9CD+z/wD+CPV//lnQB+4P/DLvjr/o
B/8Ak7b/APxyj/hl3x1/0A//ACdt/wD45X4ff8Rq37U//Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+
z/8A+CPV/wD5Z0AfuD/wy746/wCgH/5O2/8A8co/4Zd8df8AQD/8nbf/AOOV+H3/ABGrftT/APQg
/s//APgj1f8A+WdH/Eat+1P/ANCD+z//AOCPV/8A5Z0AfuD/AMMu+Ov+gH/5O2//AMco/wCGXfHX
/QD/APJ23/8Ajlfh9/xGrftT/wDQg/s//wDgj1f/AOWdH/Eat+1P/wBCD+z/AP8Agj1f/wCWdAH7
g/8ADLvjr/oB/wDk7b//AByj/hl3x1/0A/8Aydt//jlfh9/xGrftT/8AQg/s/wD/AII9X/8AlnR/
xGrftT/9CD+z/wD+CPV//lnQB+4P/DLvjr/oB/8Ak7b/APxyj/hl3x1/0A//ACdt/wD45X4ff8Rq
37U//Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+z/8A+CPV/wD5Z0AfuD/wy746/wCgH/5O2/8A8cpH
/Zb8dOpB0Pr/ANPtv/8AHK/D/wD4jVv2p/8AoQf2f/8AwR6v/wDLOj/iNW/an/6EH9n/AP8ABHq/
/wAs6AP2lvf2E9a1O6ee58EaTcTyHLySGyd2PuS2TUX/AAwJqf8A0IWif982X/xVfi//AMRq37U/
/Qg/s/8A/gj1f/5Z0f8AEat+1P8A9CD+z/8A+CPV/wD5Z0AftB/wwJqf/QhaJ/3zZf8AxVKn7A+q
RuGXwHoqspyCBZAg/wDfVfi9/wARq37U/wD0IP7P/wD4I9X/APlnR/xGrftT/wDQg/s//wDgj1f/
AOWdAH7dy/sn+NZ7fyn0ANHjBU3lsQR6Y31if8MCan/0IWif982X/wAVX4v/APEat+1P/wBCD+z/
AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7Qf8MCan/wBCFon/AHzZf/FUf8MCan/0IWif
982X/wAVX4v/APEat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7UaZ+w1r
ui3i3Fn4L0y0uE+7LC1nG6/Qhs1d1j9j3xb4gtzDfeGLe8hYgmOe4tZEJHsXIr8Sv+I1b9qf/oQf
2f8A/wAEer//ACzo/wCI1b9qf/oQf2f/APwR6v8A/LOgD9oP+GBNT/6ELRP++bL/AOKo/wCGBNT/
AOhC0T/vmy/+Kr8X/wDiNW/an/6EH9n/AP8ABHq//wAs6P8AiNW/an/6EH9n/wD8Eer/APyzoA/a
D/hgTU/+hC0T/vmy/wDiq0ND/Yw8T+GS/wDZ3hOysfM++Lea0iD/AF2uM1+J/wDxGrftT/8AQg/s
/wD/AII9X/8AlnR/xGrftT/9CD+z/wD+CPV//lnQB+1msfsTeI/EUqPqHhCwvnjGFa4ktJSo9izH
FU/+GBNT/wChC0T/AL5sv/iq/F//AIjVv2p/+hB/Z/8A/BHq/wD8s6P+I1b9qf8A6EH9n/8A8Eer
/wDyzoA/aD/hgTU/+hC0T/vmy/8AiqP+GBNT/wChC0T/AL5sv/iq/F//AIjVv2p/+hB/Z/8A/BHq
/wD8s6P+I1b9qf8A6EH9n/8A8Eer/wDyzoA/bfTf2RPGGjWK21p4bhtbdPuxxXNsiL9AHwKzb39h
PWtTunnufBGk3E8hy8khsndj7ktk1+LX/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A
/wCCPV//AJZ0AftB/wAMCan/ANCFon/fNl/8VR/wwJqf/QhaJ/3zZf8AxVfi/wD8Rq37U/8A0IP7
P/8A4I9X/wDlnR/xGrftT/8AQg/s/wD/AII9X/8AlnQB+0KfsD6pG4ZfAeiqynIIFkCD/wB9VtS/
sn+NZ7fyn0ANHjBU3lsQR6Y31+In/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCC
PV//AJZ0AftB/wAMCan/ANCFon/fNl/8VR/wwJqf/QhaJ/3zZf8AxVfi/wD8Rq37U/8A0IP7P/8A
4I9X/wDlnR/xGrftT/8AQg/s/wD/AII9X/8AlnQB+0H/AAwJqf8A0IWif982X/xVH/DAmp/9CFon
/fNl/wDFV+L/APxGrftT/wDQg/s//wDgj1f/AOWdH/Eat+1P/wBCD+z/AP8Agj1f/wCWdAH7Qf8A
DAmp/wDQhaJ/3zZf/FUf8MCan/0IWif982X/AMVX4v8A/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq3
7U//AEIP7P8A/wCCPV//AJZ0AftB/wAMCan/ANCFon/fNl/8VR/wwJqf/QhaJ/3zZf8AxVfi/wD8
Rq37U/8A0IP7P/8A4I9X/wDlnR/xGrftT/8AQg/s/wD/AII9X/8AlnQB+2+m/sieMNGsVtrTw3Da
26fdjiubZEX6APgVm3v7CetandPPc+CNJuJ5Dl5JDZO7H3JbJr8Wv+I1b9qf/oQf2f8A/wAEer//
ACzo/wCI1b9qf/oQf2f/APwR6v8A/LOgD9oP+GBNT/6ELRP++bL/AOKo/wCGBNT/AOhC0T/vmy/+
Kr8X/wDiNW/an/6EH9n/AP8ABHq//wAs6P8AiNW/an/6EH9n/wD8Eer/APyzoA/aD/hgTU/+hC0T
/vmy/wDiqP8AhgTU/wDoQtE/75sv/iq/F/8A4jVv2p/+hB/Z/wD/AAR6v/8ALOj/AIjVv2p/+hB/
Z/8A/BHq/wD8s6AP2g/4YE1P/oQtE/75sv8A4qj/AIYE1P8A6ELRP++bL/4qvxf/AOI1b9qf/oQf
2f8A/wAEer//ACzo/wCI1b9qf/oQf2f/APwR6v8A/LOgD9oP+GBNT/6ELRP++bL/AOKrQ0P9jDxP
4ZL/ANneE7Kx8z74t5rSIP8AXa4zX4n/APEat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/
AP4I9X/+WdAH7Wax+xN4j8RSo+oeELC+eMYVriS0lKj2LMcVT/4YE1P/AKELRP8Avmy/+Kr8X/8A
iNW/an/6EH9n/wD8Eer/APyzo/4jVv2p/wDoQf2f/wDwR6v/APLOgD9oP+GBNT/6ELRP++bL/wCK
o/4YE1P/AKELRP8Avmy/+Kr8X/8AiNW/an/6EH9n/wD8Eer/APyzo/4jVv2p/wDoQf2f/wDwR6v/
APLOgD9oP+GBNT/6ELRP++bL/wCKo/4YE1P/AKELRP8Avmy/+Kr8X/8AiNW/an/6EH9n/wD8Eer/
APyzo/4jVv2p/wDoQf2f/wDwR6v/APLOgD9oP+GBNT/6ELRP++bL/wCKo/4YE1P/AKELRP8Avmy/
+Kr8X/8AiNW/an/6EH9n/wD8Eer/APyzo/4jVv2p/wDoQf2f/wDwR6v/APLOgD9qNM/Ya13Rbxbi
z8F6ZaXCfdlhazjdfoQ2a2f+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/E
at+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrf
tT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/h
l3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDl
nQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A
5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+
OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCT
tv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4
I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A
+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A
8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAM
u+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1
P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9
CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1
/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+
4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f
8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H
3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A
/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/
APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV
/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf
/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov
+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0I
P7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z
/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBA
P/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8A
wy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCOV+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq3
7U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Ea
t+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP
+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APln
QB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/ydt/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5
Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+4P8Awy746/6Af/k7b/8Axyj/AIZd8df9AP8A8nbf/wCO
V+H3/Eat+1P/ANCD+z//AOCPV/8A5Z0f8Rq37U//AEIP7P8A/wCCPV//AJZ0AfuD/wAMu+Ov+gH/
AOTtv/8AHKP+GXfHX/QD/wDJ23/+OV+H3/Eat+1P/wBCD+z/AP8Agj1f/wCWdH/Eat+1P/0IP7P/
AP4I9X/+WdAH7g/8Mu+Ov+gH/wCTtv8A/HKP+GXfHX/QD/8AJ23/APjlfh9/xGrftT/9CD+z/wD+
CPV//lnR/wARq37U/wD0IP7P/wD4I9X/APlnQB+4P/DLvjr/AKAf/k7b/wDxyj/hl3x1/wBAP/yd
t/8A45X4ff8AEat+1P8A9CD+z/8A+CPV/wD5Z0f8Rq37U/8A0IP7P/8A4I9X/wDlnQB+3Ov/AAG8
WeC/BfifU9T0r7NZW3h/VPMk+0wvt3WM6jhXJPJA4Hevb/il/wAgO5+g/mK/D/8A4J//APB0D8ff
+CiX7Tdn8HPGvhD4P6X4Y8YeH/EX2260TStRgv4vs2h395H5bzX0sYzJboDujbKlgMHBH7gfFL/k
B3P0H8xTQHxp+1r/AMicP+wlB/6Knoo/a1/5E4f9hKD/ANFT0U5bgdF/wdHf8oKPjn/3AP8A1IdM
r+cL/gjT4gsj8WfjB4MfULCz8RfFn4ReI/A/ha2u7kWqaxrN4kP2SyWVysKSStGVQzMqM21Qd7ID
/R7/AMHR3/KCj45/9wD/ANSHTK/ko+DXwa8U/tC/FDRfBfgrQ7/xH4o8Q3AtrDT7NN0k74LMSThU
RVVnd2IRERmYqqkjTDycasXFXd9u5lWipU3Fux9qfsjeH1/ZR/4J0fE3xt8b/CL/ABC+F2pfEOHw
BD8Lb8z6Xe2nim0gjvJ9Se82ibTHhtPMtz9nDyTmVop0RI0Y/WOu/AvxLq/7Pn7X3jbw98L5vix4
X+Mmi/DzxD4D8PxeGri0t4dLMoeHRmt9JdHW602ykssx21x/qkhmlBWbZX5LeJv2V/HXhL4L3vxF
u9Ht5PA1h4sl8Dya3Z6naXlnLq8UH2h7eJ4ZXEy+ThxNHuiZWUq5yM+j6b/wSp+N2pfDeLxe2geF
NP8ADj6Tp2vSXup+OtA05bSw1BQ1jczrPeo0Ec+QsZlC7nBQfOCo76OIqxiqSptpffqpeXntqtHp
qznq0ouTnz2/qPn5fiuyP0Mls7b9lP8A4J8/FTw98cfAGm+BPh98W/2lJfDPirwvp12puvAmnXej
2mrwXVndWIeGU2WbCaKJLdo3W3ljaM+cBF5h+1z8PtR8b/8ABzZdX2kx+Zpfg/xN4Z8XeINSuZ4r
a00TS7Gx0y5vb65nZkiihiRWJcsoLFFUs7oG+JP2iP8AgnZ8ZP2UPCer674/8GSaBpOheJIfCF7c
nU7O6SLVZdOj1JLYeTM5cmzmilLKCi7wpYN8tRah/wAE+fi/pv7SfiD4Pv4RMnxM8NWEmpXnh6DV
LKe7liS1W8ZLYJMVu5vs7iQQW5klIDYQlGA1liqiiqcqT92Sa77yfLt1b006Oy10iNKF3UU1qvls
td/Trs15GR+258RNH+L37Z/xd8WeHbz+0fD/AIo8a6zq+mXXlPD9ptbi+mlik2SKrruR1O1lDDOC
AeK+i/8Ag3f8Najr3/BWv4bXNlYXl3baPa6xd38sNuZY7OFtKu4FeY/dSNppoYtzEAvMighmWviW
vW/gZ+w98RP2jfhf4h8aeFrXwrJ4Z8JXEVtrV9qnjHRtGXS2lKLC0y3t1C6RyO4RJCNjuGRWLKyj
hwtaSxMa6jzNPmsvJ38zoq04qi6bdla139x2n7P/AOy34f8Ahn4V1T4qfHqz1Gx8EeFdeu/DNt4N
iuhYeIPGXiC0iikn0rYf31lbW4uLdry6dAY1mWOINPIoT6R8V+JvHX/BRb/gkH4juvD2h2/inx5N
8erfULjwV4F8NBpfDmjweF47GydbW1VpYrBEiS1g3jaDav8API7Oa+TP2if+Cc/xl/ZP8Har4g+I
Hg1tA0fRPEsXg+9uf7UsroQ6rJp0WppbYhmdmJs54pd6goN4UsHyo0tO/wCCXXx11T49+KPhnH4H
CeMPBZsE1uCbWtOhs9PkvjCtlC1684tTNcNcRJFEspkkdiqqWVgLh7WHuODtezVtbtNLpvvZevmR
J05e/wAy9eltH39L/I9A/wCC9+v6b4k/4K4/GS40rUbLVLWO9sLV5rV0eNJ4dNtIZ4SV43xTJJG4
6h42DfMDUv7JXwa0j9tv9hLU/gt4C0fwxdftF2Xj0eLtNj1C2stOv/EOhDT1tprCy1KVlaR4pc3T
2crxoIonljMjiRV8i+Fv/BP34qfF/wAHeL9e0vR9B0/Tfh/qA0vxM2v+K9J8PzaBcF1jVLqG/uYZ
IQ0reUrOoVpFdAS6Mou6t/wTb+MXh3wv8R9X1Tw3pOkWvwjums/Fkeo+J9Ks7vSX2I8TfZ5blZpY
5w6i3kiR47onbA0rAiiSnKs67puzb09b6Xt0V+nS/QaUY01SjJXil+m6Ps39hT4U/DT4h/8ABZj4
c+BPB3h3wh8TPB2h+AoNC8fynw1Y6t4ZutTstI8q5vrV5bb/AI9pNRitf9NYLLNLNIEkaKdFfzT9
ij4B+J9E/wCCb37T/irUPhNDe+KPg9rOl3Ph+/1rwHa6hJpd+szW2uWs4urWTz1t7GRJZbWffFan
bceXHJtlHyV+zL+y543/AGw/irB4I+Hel2eueKru3lubbT5tWs9Oe6SJd0gia6ljWR1TLlFJfYjt
jajETeKP2S/HvhD4FXfxNu9IspPAVl4wn8BvrVnrFle20msQ24uXt4/Jmcyp5LB1njDQOCNsjZrT
6y+RS5HvN3XmlotH8Nr/AOW5Pskm48y2jv69deu3+Z9n/wDBJj9qLVfiF8Zf2jNO0Hwj8NtB1Lxx
8LfFmoaF4Y0XwjZXB1DV2trd1sLOO4Sa5ngcQPINNDyW3yybYAoIHXfs3fsvaRcfs56RH418G+AN
V+Jngf8Aan068+JsFjpWl3UXhjwsbCOW6a+ls0aC20dZlulljJW1ga3kUqhVlHx74o/4Jb/G/wAB
a74ksfEnhbR/Ci+EtSg0bUr/AF/xZo+k6Wt/NaJeJZxXtzdR21xcC2kjlaKGR3jWRC4XcM+S/Gj4
L+Kv2dvinrfgnxtol74c8U+HLk2uoafdKBJC+AwIIJV0ZSrpIhKOjq6sysCX9Yq04x9rB+63vtr0
tbR3X56CdKE2+SS1S9dOu+x+rX7Pf7GPhH4eftP/ABo8S6n4Q0XW4dO+O8+h6x4Jv9B0Cw0zwN4P
RbjUk1+7fVbC5Nvpk1sXjjW3NlvWBQlw7yQBPJP+CdPwWtv2ff8Ag5YtvBNtoWoeGdI8O+L/ABPb
aTp135glt7AafqLWWGmJd0a3MLK5ZjIjKwZtwJ+F/wBmj9l/xr+1/wDFO38E/D3TLLWvFN5BJcW1
hPq1npz3Sxjc6xNdSxLI4XLeWhL7VdsbUYje8DfsMfEn4heGtd16w07w5beGPD2tt4bufEOqeLNI
0vQp9SVGkNrbahdXMdrdyCNfMxbyyfu2R/uOjNrTxjTp1I0tp8yfezvbb0/yJlQS5k57xs/yT39f
8z3v/ghp8F5vEX/BVHQPBXjH4eW/iTSraDVrTxboeveFoNT/ALNWC2lI8+G6hf7K6XsdtGZMI4Z/
K3DzGRtj9gb4Yun7MnjrRo/g94qu/iTo/jmC01LXtM+HGjfEnVtOtktJ1Okz+HtSkjm09ROkkhvl
UiR0MDbTCA3xv8aPgv4q/Z2+Ket+CfG2iXvhzxT4cuTa6hp90oEkL4DAgglXRlKukiEo6OrqzKwJ
6P8AZt/ZA+In7XOr6lZ+APD66udHFt9tuLnULXTbO1e5uEtraJrm6kihEs00ixxRb98rZCK2Djnp
VmuSjGD5ouXXV3SVtrq1vxexrOnGSc3LRpemnX8T9PP2e/2OfAvgn9pT4peJLyL4V+Ol0v40weGP
FXhjRPD+kWfhvwX4fgtZNQvNcuTrdtfSWNn8t3byWsEtsEmtZIorqTFuF4D9jOyvf2Z/26f20Pgz
4e8L6JpynwX43g8FeH7/AMP2l/quqyb4ZNNtLd7uJ7u/iktI45ktWaWOeMGXy3yXr4g+Gn/BPn4q
/Fbwd4t17T9H8P6Zp/gHUzo/iUeIfFmkeH7jQLresYS6gv7qCaANI3lqzoFeRJI1JeN1VPB3/BPT
4weOf2pdW+Cln4RFt8UdGMouNA1LVrHTJ5DGFdhC9zNHHcZjYSp5Lv5kWZU3RguOqji6keSUKTvz
O2/W6stP13W25g6UNVKa2X4W13/q59G/8Ee/gRrXiD/gssvgX4gfDzwx4mFrc65aeONEufDem6np
WltDHNuOxIZLa0SO/W3jWS3CKu8RIwWTYz/2b/gBqmjf8Ex/FV/8PvhlD4w/aQ0j4w/8I94m0W88
DweKtX0DQY9JkMe/Tru1uPsqtf8A2lHlEaOZIFRm+QAfKXwv/ZF8d/GTV/F1t4fsNFubTwGA2vav
c+ItOstD00NcC3jLalPOlmfNlIWLbMfN5Me8Akc58aPgv4q/Z2+Ket+CfG2iXvhzxT4cuTa6hp90
oEkL4DAgglXRlKukiEo6OrqzKwJ5VXlCnFuD0ctf8SSte3SzfrfQ3cE5tcyu0tPT57an6Q/Hz4bf
Cf4O6Z+3LJ8MPDPgi60n4I674WufB02peH7PVpNJv72RdO1a2Zr6GR7iAMblFt5/MhikjWWNVkVZ
a+R/+CvHwT8Hfs5/8FGvif4L8A6XcaL4U0K8to7OymE4MDPZW8kwXzgHKGZ5Ch5UoVKFkKsfMP2Y
/wBlnxx+2N8U4vBPw70uy1zxTc20t1b6fPq9np0l2kQDSCI3UsSyuq5cxoS+xHfbtRyOn+Gn/BP7
4mfF7wd4t8RaBB4HudB8CamdJ17UZ/H2gWlrpsxdUjkeSa9RTbyuwSK5UmCZgyxyOVYB1ajq0+Wn
Tsm7q2ytzNpadmr/AOFfKacI05az2Wt/lZv7n959n/8ABHH4UaXqP7OXgDxZ4I8K6P4v+LMX7Reg
6Z4pD+HoNevdA8Ii1WUXe2WGb7BA1ybjN5Esbq0C/vBsXEX7H37PEnir/g4r+IHgzxR4Cn8R+GJ/
Evim71uw8SeHV1l001vtNzZ3cv2qOQx+bK1iUuSQX+0IN7LMQ/yAf+CbPxnsZPEx1jwla+ErTwjr
Q8OalqHinXtN8O6cNRMPni1hu764hguJTBtmCwO+YpI5PuSIzeZ/Gj4L+Kv2dvinrfgnxtol74c8
U+HLk2uoafdKBJC+AwIIJV0ZSrpIhKOjq6sysCdaWLnQjTVSm/3cr9urvHbS/X02FKkpVJOM9Wvm
vPc+xP2C/hPcRfs5+O9H/wCFQ+LLn4jaH44gstR1nTPhto/xH1fTYUtLlH0q48P6lLHNYKJleQ3i
oRI6NC2GiUV9L/s3fsY+A/h5+0h8UdbubT4bfEGHQfjHH4Y8V+GtD0DS4PDngrw9a2kl9ea7dvrl
tfzWlp8t3bvbwS24EtpLHFdyf6Pt/HyisKOOUFC8b8r79NdNvPXe5dTDOd/e3Vj9Yfg7+zj46+AX
wo/4KE6H8NPhfrd3aweMdH0bwbpV54NPiOHUYLbWpJhBFb3sE63fl6dc21wSyuyxy28xI3Rucv8A
Zl+G3gzwL/wdBW/hn4dWmnWfhjTtW1SCOzsd0dvZXI8P3JvYEDZ2CO6+0JsUbUKFUAUKK/LKitoZ
lCE6c4Q+CSkte0m7KyVr3V99lstBfVmr2erVvwSu9ddv+Cfo3+wl+zdoj/8ABOrxpd23hbWtR+N+
mfFdNB13TNM+Elj8Q/EehaRFpjtGJNM1CRFs4JLw3KPOgR/MtljbeMBPor4Q/B7wFo/xvv8AWfg3
8LdPt/Gdl+1FoWj+JdAn8M6d4h1PwP4aisY3un2xPfQafD/aDX3+kWjx7DagB4/KSKL8WqKyoY5U
+S0fhb6663+7f52XYKmFc3JuWj/4H+R7d/wUs8O6j4Y/4KGfG+31Sw1DTrmfxxq96kV7E8czwXF5
LPBL8wBZJIZI5FfGHSRWGQwNeI0UVxVZqc5SirJt6djqirJIKKKKzGFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQB9j/APBAr/lKZ4I/7F/xb/6i+rV/W/8AFL/kB3P0H8xX8kH/AAQK/wCU
pngj/sX/ABb/AOovq1f1v/FL/kB3P0H8xTQHxp+1r/yJw/7CUH/oqeij9rX/AJE4f9hKD/0VPRTl
uB0X/B0d/wAoKPjn/wBwD/1IdMr+bz/gjz4j05Pih8YfB01/ZWfiP4rfCXxB4J8KQXc6W0WqazeC
D7NZ+dIVjieXy3RGkdFZyiFvnCt/SH/wdHf8oKPjn/3AP/Uh0yv5Kvgv8F/FX7RPxT0TwT4J0S98
R+KfEdyLXT9PtVBkmfBYkkkKiKoZ3kchERGdmVVJGmGm4VYySvqtO5nVScGm7I+yP2Q9Dtv2Vv2A
/in4x+OPhK78ffDPUPHMPgKH4X3NxJpV5beK7WJLqTUZ7kr5+mNBaefBmFTJcNK8MiiONjX2Z4t+
GfxA8Tfs4ftVeJ9O8Fah8ZfBHxR8MfDrXPh14Sl0DU7W2t9DN5LNa6JHa6VJCiSabbzIzpaTEfdl
Y/v5lr8ivE/7Jvjzwj8C7z4mXekWUngOy8XzeBH1qz1eyvbaTWIbcXL28Rhlcyp5JDieMNC4I2yN
kV3nh7/glt8a/Efw3m8XL4f8Nab4cttO0/WLi91jxroekrbWWoRxyWNzIt1eRtHDP5qrG7AK0gkj
B8yN0X0KGJnGHs4021/wJLs9NdF0auupy1qcG3PmS/pefl66rsj9E9Xn0z9lb/gnf8VvCHxn+HOk
+APC/wAWP2lZtB8XeG7C8ikl8CaRfaNZavZz2d1p6uJGsm+yTRxeU8TrBJEIQZJAnmf7bfw61rxz
/wAHNupXdpbrPY+DfEHhnxZ4hvyyW1poukafpul3N5e3EsriOKKKGMks7gM21RlnVT8RftD/APBO
f4y/speCdU8R+P8Awa3h/RtF8Tp4NvLg6pZXPk6s+nRakttthmdmzZzxS+YoMfz7d24FRW1D/gn9
8XdM/aN8RfCKTwlu+JXhexfULzw9FqllNeTRrbpclLVUmIvJ/JkWQQWxklZQ5CHY+3aWKqtRpKk/
dkvW6cvdei31tpo09N7RToQUvaRmtU/yjrv5Lr1Wpjfto+PtI+K37YvxY8UaBfnVdB8SeMtY1XTb
0xSQm8tp76aWKXZIA67kZW2uAwzggHNfYf8AwSk+H/ivXP8AgmX+15PpPwo1D4p2msyeErSy0ZrD
VZ7XW7m21NpJoU+wSwzSSQRXEc7LFIGQeWW/dswf88aK8uGItVdWS3v+PyZ11KXNDkT7fh6WP2Z1
k6b+yp/wTm+KfhX40fD7SfAPhb4t/tLz+H/FnhewvoZJfAekXmjWOr2lzZXOnowkayY2cqR+XJEy
27xeSplcDtP+C4b+DNC/Zy+Lmo+PtG8QeJbG5/aG023jsPD+sW2i3VvKvgDSWSVrqayuy8ZV5FMZ
QZYB1KYdX/DKtnRPhz4h8TeEtc1/TdB1nUNB8MiA6xqVtZSy2mkieTy4DcSqpSLzJPkTeRubgZPF
d/8AaTdP2UYd7bN2tLfSzXvX2017nP8AU7T53Lyf/ku2t18P/BP27/as+H3izXviF/wUUm074S3P
xRi1u4+HkNlozabrE1rrdzbQWclxDELKaCd5IIrqK4cRvuRTGWxHIQ/HftdfCLxl8W4f+ClFt4M0
3xT8To/E2s+B7CxvNJ0t7w3V7Zz2815p0K2kex5bBJRFJGQZokjUytvLs/4uV2h/Z68Xj9nZfiv/
AGUh8BN4jPhP+0he25ZdTFsLryDBv88AwncJDH5ZwwDFlIFVszVZy9x+829+/P5dOZ79ul2EcJy2
fNskv/SfPy/HW9j7l/4I8fsm+O/2Vf8AgvF4E8DeKNJ2+I/BtndX2vR2W68h0mO70CWRRLLGCg2t
eQwlwTH5rgK7hlZu7/ZH8eaP8A/+CFureCfi7ol7B4H8b/tGXHgbxva3QnsNS8MRf2NYTyX0QjRp
VurS5sreUxSQyK4tniMZLtt/Nz4/fALxZ+y98XdZ8B+OdMj0bxV4feOPULJL2C8Fu0kSSqvmwO8b
HZIpIVjtJIOCCBJ+zx+zx4x/at+MWj+AfAOj/wBveLde877BYfa4LXz/ACYJJ5P3kzpGuIopG+Zh
nbgZJAONHFSpNUoQ1TlZPV+8krNW1emu17tWQ6lGM06k5aNR1/wu973/AOG7n7N/8FlPh5rH7S3w
p+Kvgfw5pvinxRqml/tG6Rq2u6P4U0U67rOj6VJ4G0y3TURZRMshRzHKqGV44pHh2q6kSFfyd/4K
PfDTU/g5+2x4+8La18Sb74u6xoN3DZ33iq9leS51CdbaESRyF5pnDwNm3KtIWUwFSFIKL4jRUYzG
xr3fLZt3385PayXXfy8zTD4d0ko30Stt5Jfofa//AAbyeFtT8Sf8FavhpLp1pfzxaXb6vdXtxbwu
66fC2lXcImkZSNiebNEm5iAWkReSwU9Z4M+EHjD4q/8ABCnVfhb4Z8JeLPEXxI8HftEz6jrfhXTN
Oku9X0e3bw+tqZrixiDXMKieCSIvLGqb0KKdyuB+flFRDFpUo0mtnJ7/AMyS7eQ50ZOTkn26dm33
P0F/4LS/E34M6z/wVL+NEviPwv438XanHqdlaC/8N+O7DTbKIQaRp9u8DRPpl4TNFcQ3KyHzgQcR
mON4nLadn4n+FsX/AAQZmub3wT8Q5vBMn7RMwsNOi8Y2UGpRTf8ACMWmS98dMeOdRtmyn2SPb58O
HO2TzPznopyx0nVlUstebout+ttdxU8Mo04077JL7rf5H7g/trfD2fV/FP8AwUn1/XfAHj7XvB0z
eB4CmiS/YpL17GGzubkx3nkXcKi3heG6mDRsUgdS6wlgU+cf+CYv7Quv/wDBQj/g4g0b4tyeGDpC
6pLqWpXtppkc13DodnHo01jbvNLj+8bZGmYIjTSjCIHWMfmZXp/7M37GnxJ/bC1TVLX4e+G/7a/s
X7Kt9c3GoWum2dtJdXCW1rC1xdSRQ+fPO6xxQ7/MlbcEVtrY6o5jOeJjUhFu0ua27bu5b26Xttbr
YxeGjCk1KVtLX7aJd7dD6l+G3gnXvjZ/wRl8U/Afwp4a17WfjL8OvjdJ4z8QeELfTZDrdvpT6TDp
RmW2IE0phvQYpo40Z4fNVnCKS1fIP7Rfw48V/B34x6v4S8cXcV34q8MCDStQWPVY9UFi0EEcS2fn
xu6E26KsBRWIiMJj42YGv8Kv2OfiP8Y7/wAYQaT4eWxT4ehf+Enu9f1G10Cy8Pu9wLZIbq5v5YYY
ZnmJRYncSMyPhTsbDviX+xr8R/g/8Otd8WeIvD8Wn6F4a8a3Xw81KcapZzPa65bRGWa0MUcrSMFQ
E+cqmFsELISMVwyjKdNNQenXpa78vxv0OiDSm1zL069PM+jP+DdrwvqHiD/grl8Mbmz029v7XRYt
VvdQlggkkjsITpl1Cs0rKD5aedNCgZsKXlRc5YV6J/wSu8N+H/gP+w9+1lrnx1+FvivxJ8OtM1fw
poOv6MRd6TO9zDqzJcwrKDGRc2hngla3MiMWaJHKLJvHwR8aPg54g/Z9+Ket+CvFVvZWfiTw5cmz
1K2tdSttQjtZwAXiM1tJJEXQna6hyUdWRgrKyjl61p4r2UI05R1i5PXvJJaq3S2q67MiVH2jclLS
SW3k29Hfrc/ZX9tX9n/4qftWfsl/Gz4b3tvYeJ/jZ4f/AGhr3xVrMGi2GWfQ4vBhfTJFtLVriaJZ
4rdYIPNLF7idI3meUyuLH7XKaN8Z/wBoz9oq/wDB3wd1LWPFtp8SNMs7/wAWeH/Bfh/4qanBbRaF
FBLpsugXVyTYxfbIZ5hfooMkhe2l8uSAxD8Yq9O8O+Bfil+3B4y8beIVudZ8feIfDXh258WeJNT1
fWVlvV0yxjjSWd5bqUPN5UZiUIpZ9oAVSF43jjVJcqg2277/AOLyvdcz1MnheV3bVrfLp0v5f8Ob
n/BRvwSvw2/bs+K2gLp3grSRo/iO6tPs3hGMw6MpR8FoIDcXJtt5G97bzmFvIzwgIIxGvitei+EP
2UvHPj79nTxb8V9H0zT77wP4Eu7ez1+7TWbEXWlvcSRRQGSzMwuvLkklVUkERRisoDExSbPOq86r
dy57WT1Xpf8ApHXTso8t720f3BRXS/B34Ra98evidovg3wvbWl74i8RXIs9Otri/t7FbqdgdkQln
dIw7kbUUsC7sqKCzKpo/EDwJqvwt8e634Y121Fjrnhy/n0vUbYSpL9nuIJGilTehZG2urDcpKnGQ
SOajkly81tO5d1exkUUUVIwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
+x/+CBX/AClM8Ef9i/4t/wDUX1av63/il/yA7n6D+Yr+SD/ggV/ylM8Ef9i/4t/9RfVq/pK/be8U
yaR+0itsdcnsIT4YtJBbn4vJ4YiLG7vAXGmhC7MQADck7XCqgGYWoQHE/ta/8icP+wlB/wCip6Kh
/acnF18JNFkEon3zW58waidR3/Ldc/aCB5v+9j27UU5bgdR/wdHf8oKPjn/3AP8A1IdMr+cL/gjZ
r2lN8UvjL4OutSsrLxD8VfhB4i8FeE7a7uEtodY1u7WD7JZGaQrFG8pjYIZXRTIEUNvZFP8AR7/w
dHf8oKPjn/3AP/Uh0yv5J/g78HvE37QHxO0XwZ4N0e71/wATeIbkWthY2+A0zkEklmIVEVQzvI5V
ERWZmVVJG2Fm4VYyiru+3f8A4PbzM60OaDjex9sfsg2R/Zd/4Jv/ABI8XfHPwzf/ABE+EF58Q08E
2fwpurmfSp7Xxfb28VzPqcl0U83TWisRJbt9m3S3DMsU6rHGjV9X+Lvg5498S/Aj9rPxpo/w31D4
q+BPiz4f+Hus/Dzw8fDVzb27aQZhNbaLHb6TMjxSaZayw747eYZEMM0gKz4b8lvEv7Kvjnwn8FL7
4jXWlWUvgfTvFsvgaXWLPV7K9tn1eOA3DQRmGVzKnkjes8YaFgRtkORXaeDf+Ca/xf8AHPgvWPEV
po3hiz0Xw/aaZqGp3ereNNE0pNPttStre6sJ5ftV3GUjnjuoQjsApcvHnzI3ReylXqKKpqDaX37S
8ttXpto7bs5KlKHO6jmk/P5ef476rsj9JtRurX9lj/gmZ8RfCXxt+Hln4H8D/FP9py60Txd4e0zV
RK3g3S7/AEPTtWtp7CSxD2/mWW2ynRUhdJlh8lowCFXyn9sL4aa146/4Oab24tLBjp/gzxF4a8V+
IbyW4igt9G0fT9P0y5u7+6uJGWKKOOFCzO7AF2VRlnVT8P8A7QH/AAT3+MH7LfhHWNd8eeEDoWla
B4mj8H3851SyufI1WSwTUUttsMzs2bWRJN6gxjdtLbsrUUv7AXxbh/aJ8Q/CU+Ei3xJ8MWEmo3nh
5NTs2vZo0t0uWjtlE2LufyXDiC2MkzANtQ7Gx0SxtW0aLpvSSa77yaW3m+ney10UaUU3UU1qn+S1
38vutrprl/tsfELR/i3+2X8XPFfh6+Op6B4n8aaxq2mXhheE3dtPfTSxS7HVWXcjqdrKpGcEA8V5
jRXrPwL/AGJPiH+0f8NvEfjDwraeF5PDXhCaGDW77VfF2kaLHpZmZVhaYXt1CyJI7BEcjY7gqpLK
QPIfNVm2ldvXQ7fdpxSbskZPwn8S/CjR/Dc0XjnwX8Q/EesNcs8V1oXjSz0W2SDYgWNoZtKu2Zww
kJcSgEMo2AqWb27/AIJ722s/8NRa/wCNvhncr8OPhL4W0wnx1f8Ajm6TXtIttAnCQ3NhqSxQWy6l
9sfMcNlFCksshjEe14vPTybw3+w58VPFf7VzfA+z8I3I+KS3U9n/AGHc3dtas0kMD3D4mlkWBkMM
bSI4kKSKVKMwdc+T1tTqVKTjOUdE+1tV0vv111IlCM7pPf56eh2f7RGt+B/Enx08V3/w00TWfDfg
G71OaXQdM1W7F1eWVoWOxJHGe3RS0jICFMsxUyv9gfC/wZrnx5/4IATeCvA+i3/jLxZpH7QTa3ea
LoMUmparaWMvhxYUuprSFWkit2ljZEmI2u6yLnKc/H3wd/Z+8XfH7/hKv+ES0j+1h4J8PXfivWj9
qhtxZaZa7PPuP3rrv2+Yg2JudiwCqaPgd+z94u/aP8XXOieDtI/tS80/T7jVr6WW6hsrPTLKBd01
1dXU7pBbwICAZJnRNzoudzKCqKnzqXK3zXVl1vppowmouPLfa34dz9ev21dJ0v4t/tOftGX3hn4Z
N4o8WWPxF0qyufGHg7wfoXxavorSHw9BA2lz6FfTRyWCJcRyu17HGVe4E1s7s1steH/sdfsz2Lf8
HEWv/Du78IfCPxx4Vt7vV11yy0Lw3HqPha2hFg8qyC3uWuBYMt59nSRElxbzs9sjbMRt+c/xg+D/
AIm+APxO1rwZ4y0W98PeJ/Dty1pqFhdKBJBIMEcglWRlIZXUlXVlZSVYE83XdLMV7RTqU7tT5nr5
t2ennr6HPDCOMOWMtOW23la+/wCB9sfsg+HT4E/4J+ftSajr3g3wqvjr4Jav4evtGPiPwZp97f6P
e3l++l38FwLuBnlTyht+y3SyQxSgypHHOBJX0r+3N8K/g78AfEvxz8J+EPCHwD8JfEay+Ktldavp
/im4ils4fBVx4fiuXWzW5VZYg13JPI0eiAahGZVihCiO1z+SVeofCL9sj4hfBL4cXvg3RtU0m+8H
3+pLrMmg+IPD+neIdLjv1iMP2yK11CCeKG4MR8tpY1V3RVViQqgc9HFxjFQlHT/9r/NdVst+mk8O
3Jyv+nb/ACf39D1b/gtb4D0v4Y/8FPfipoGieFfDfgrSNLubGGz0jQUVLC3i/s61KuirFEqtKD5r
qE+WSVxufG9um/Yak023/wCCbH7S/im48N+CdV8SfCi98Na14XvtW8Kabqc1lPqF62nXayNcQubm
BrcgLbXAkgjk/fRokwEleHPofxa/4KF/FX4i+NZ3v/HXirTNFvfG3irULq7gheDT7RUE04Dsi+XE
jRokMI+VAiRx7VCjlv2fv2fvF37Uvxd0jwJ4E0j+3fFeu+d9hsftUNqbjyoZJ5AJJnSMERxOcFhn
GBkkAzOUpYh1KcX7zfL312tbqr9Oo1BeyVOT2Sv8vXv5n67/AB5/ZI+G3w9t/jvF8Ofhpp1p4+03
4yW1ibHwd8PLH4p6lYeH5vD0N3Bt0fUmjisbSa6e4lM8IAWQm3UvFChWrbfsY/Ar9qjwb8Q9D1/w
f4B+B2h+Dvj5d3PjS9svE2gW+ueDdFfw5HBBFJdlpoYLWbWgALSJpIop5p4Y1U25ZfxgorojmULp
ypp6ttd9/LTfpa9l2Vs/qktbS6f5efl959Cf8FMvhofgf+0ZpfgO68K6N4S13wV4K8NaXr1rp3lE
XGp/2PazXU0piJieYyysruhYOU3lmZmJ96+FXirwbpX/AAb5Nb+O/D3ibxDoyftDSSW9voXiGLRb
kXDeG4hvaWeyu42jVEIKLGGJkUllCgP8A0VyfWUq0qsVvfTTS/y6ehvKlzQUJPt5bH7O/wDBXxdf
/ax+HP7QPws8I6JD4l+JXg743af47u/DugzT6jqbeHpPC2n6XDfxQtEjTqZRb+cluJGgaX5sxKkz
Uv2aPHNr+wf/AME6n0f42zWd9rXhb47Podp4qgm/4SVPhnrzeDrSGzvzbHdBfPpHleS1srMI3iYx
7mgt935Rfs9/s9+L/wBqn4waP4C8B6SNd8Wa+ZhYWJu4LTzzFDJPIPMndI1xHE5+ZhnGBkkA8ZXa
8yn7VYrl1fN6Nu77brm7/dc5/qkeT2N9NPXou/k+h6R+2B8GfG37Pn7T/jnwh8Rrt9R8b6Pq0w1i
/e7e7OpzSHzftfnSYkkE6yLKGkAciQFgGyB9x/8ABMvwj+zj4R/4JyweMvjz4I8Mahofiv4xy+Dv
EPiS/t9RuNQ07TIfD7ahapZG0YS27/b0jV3gy0kdy6yqUWMr+alenfCL9jvx/wDG74dX3jDRtN0e
y8I6dqceiy65r/iHTfD2mvfPE8wtY7i/ngjlmESF2jjZmRShYAOueTCVZQre0hHmeum/3913Nq0E
6XLKVttVofqB4j8CfDf4lfs3ax4v8D/Cbw5oHxV1PWPCd5rdj8P/AISWPxBuLbTr/wAG2Wp5j0TU
JhbadZG7uLkfaIcO7wKrlyCw479l34twaF/wUB/bL8C+Avh/4T+Hv9qeAvFsHhzwW+i6RrGo3OtQ
xWytpsJWO4M6ytb3Ep0qGWW1Q71WN1iGfzF+Lvwj8S/Ab4laz4P8YaPd6B4l0C4Nrf2NyBvhcAEE
EEq6MpVldSUdWVlLKwJ7j4TfsO/Eb40/Buf4haPY+GrLwTba0fDrazr3i3SNAtW1EQLcG1Vr+6h3
yeSwfC54z6HHZDHz54qMNYtuy+em2m+tt+q0VueWEiovnlpa2vy7+a2fyPr79mPQPiN+zb+wd+3h
4h13w3oOna7o2veGtH1CK78NaVqWgDUo9bdb20jtzFJpzNAZ4j5UUZSHfEVCYjr179rf9n3TPAfh
L47j9n74G+EtT+Kel/Gy206/0ey8Ep4uu9H8PvoKzK0WmahaTLZ2cuoG5dZoIVjYkRpJJBHbmvz3
8Nf8E7/ij4r8Car4qtbbwNF4U0bXm8MT67e+P/D9lpUmpCBbg20N1NepDcN5Lq+YXcEbsH5WxPqv
/BNP4z+GL/xRDr3hWw8KReDtWi0HVL3xH4j0vRNPj1CS3N0lpFdXdxFBPMbfEuyF3YI6MQA6kqnX
q+zjCNNtd9b/AGr2dtN9f8I3Ti5Pmkr+n+HfXy/H7/1B8EfCjwJof7SniHUfgL8LfBl54p0H9qjR
tF8Qw6ZoI1y58NeHIrSL7TIkN5bMdKthqUd832q2SFY3UokpiggI/Lf/AIKX6NqWh/8ABRH45R6t
p95pl5ceO9ZvfIuYHgcxT3ss0UgVwDseORHU9GV1IyCDWP8AGD9h/wCKnwB8E614i8Y+ELvQNH8P
eK28E309xc2+Y9WFsLvyFRZC8iG3KyrMitCyOhVyHXNPx9+x78R/hh8GbX4ha74bex8HXt/ZaZBq
X222lWW5vNMh1W3jCJIXy1lPFKTtwm/YxVwUGeKxNSrT9n7O1m3+fTZW1+7pY1pUYwnzJrZLz/M8
0orr/j18BvFn7Mfxb1nwJ450htC8V+H5Eiv7FriK4MDPGkq/vImeNgUdGyrEc1yFea007M6U01dB
RXpn7Nf7HnxG/a81bVLP4f8Ah0a02irbG9nn1C1061t3ubhLa2hM91JHF5088iRxQhjJKxIRW2tg
+GX7HvxF+LGt+L7DT/D6aZJ8P8DxNN4h1K08PWmgSG4FssN1cX8sEUMzTExrC7iRmR8KdjYtUajS
ai9dtCXUirpvY8zor3zTf+CZPxmvpvHkdx4e0DQ2+GOoR6Z4o/t3xfo2jDR5ZSogaQ3d3EDDNuXy
p1zFNn9271leDP8Agnx8XvHn7UWsfBax8JpB8T9D8/7VoOo6vY6bM/kqHfyXuJo45/3Z81fJd98I
Mq7o1LilhqztaL1dtnv29dBOrBXvJaeZ4xRV3xLoE/hTxHqGl3UllLc6bcyWsz2d5De2zujFWMc8
LPFKhIO2SNmRhgqxBBr0v4IfsT/EH9oj4aa94x8L23hZ/DXha5itNYvtU8YaPoy6Y8u0RNMt5dQs
kcjNsSRgEdwyKxZWURCnOT5YptlOUUrt6Hk9Fer/ABf/AGH/AIqfAPwHq3ibxj4Qu9A0XRPFb+Cb
2a5ubffFqy2q3fkCMSGRka3dJVmVTC6upV2yK4Px98Oda+F+s2un69YPp93e6bY6vBGzq/mWl7ax
XdtKCpIw8E0b4zkbsMAwIBOlOHxpr+v+A/uHdGJRXtH7OP8AwT5+K37Weiabf+A9D0XVk1rVLrRd
Nt7nxRpWm3mp3drBBcXMVvbXVzFNN5UNzA7tGjKqyAkjBxg+A/2RfHvxU/aEsPhZ4X0zS/EnjXVd
32K10rXdPvbS8227XDeXeRztavtjR87ZThkZD84K1f1erZS5XZuy0er7Luxc8btX2PNaKKKxKCii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigD7H/4IFf8AKUzwR/2L/i3/ANRfVq/rS+LHhrTLpbjUZtL0yfUBCkAupbOO
Sby1csE3spO0F3IGcAsfU1/Jb/wQK/5SmeCP+xf8W/8AqL6tX9b/AMUv+QHc/QfzFNAfHH7Xty9z
4Oj3bcR6hAihVChR5VxwAOO9FR/ta/8AInD/ALCUH/oqeiiW4HRf8HR3/KCj45/9wD/1IdMr+cT/
AIIz+JdNj+Kvxk8FzXVnD4l+Lfwh8ReBvCNtczx26aprd6sH2W0E0pWKJ5fLdEMjqGcqgJZ1U/0d
/wDB0d/ygo+Of/cA/wDUh0yv5Kvgv8F/FX7RPxT0TwT4J0S98R+KfEdyLXT9PtVBkmfBYkkkKiKo
Z3kchERGdmVVJG+FqOnVjKKu+3foZV4KVNpux9qfsg6ZD+yl/wAE7fiZ4v8Ajr4YuPiJ8LL/AMfr
4EtfhNeXk+k3lj4ttYoLufVZZ9om0xorMS2xa3DSzs7QzKkaBq+rPEHgjxj8RPgn+1r4r0PwRdfG
vwd488OfD+98B+FBoeoW9ppekPcreW2gLbaXJEUm060ubeR4rOfbgpNIT50in8mvE/7Knjvwj8FL
z4j3ej20ngWx8WzeBn1uz1S0vbSTV4oBcPbxNDK/mr5JDiaPdCykbXORXdeFv+CY3xn8WeBb/wAT
ReH/AA9pug6VYaZqt5e6z4x0XSIraz1KCGawuX+1XcREM6zoqSH5TKJIs+bFIi9VOvUUY01Btfnp
JdvPTe1n3ZyVaUOb2nOk3/wPNdvy8j9G7q5sv2Yv+CcHxE8G/HDwHp/gj4e/Eb9py80LxT4W07Ul
kufAdhqGiafqcF3aXFiHikey8qxljjEDxyLbyRGIeZhPMf2t/hr4i8cf8HNt5dWSxXNp4F8R+GfF
fiDVS6W9loWj6dY6XcXV/dzSuI4ooYU+d3cBnIVfmdEPw/8AtBf8E8PjH+yz4K1bxF488HPoOjaH
4oTwZe3J1OyuRDqz2EeorbbYZnZv9Emjk3qDGN4UtuytNvP+Cevxgsf2kPEXwgfwezfEzwvp8mp3
nh2PU7KS9miS2S7K2qrMReTG3dZBBbGSVlDFUOxsdM8bUcVRdN6STXfRydtu7fTdPTXQdKPM5861
TXl013+/1VzD/bU+IOk/Fr9sj4teKtBv/wC1NC8TeM9Y1bTr3yHg+2W099NLFL5bhXTcjq21lDDO
CAeK+r/+CZ3gJrz/AIJaftjaxrngXxz4q8IXEXhhJf7AnNhJc/YtQa6uhFdPaXUSm3jeGebMTbIc
ltgdXHwJXpn7Nf7HnxG/a81bVLP4f+HRrTaKtsb2efULXTrW3e5uEtraEz3UkcXnTzyJHFCGMkrE
hFba2POpVJSrOfLdu+i7u/Sz+46akI+z5W7JW/D7j7a/4Jt/tY6n+3R/wcX+FPipqWnWfh688W3u
pyRWME7yx2UMOgXVvBEZGwZGEUMYZgEDtuIWMMFW1/wSA/ZB0XS/Ad/4x8XaJpnijWNL+KNp4T8a
+Dtc0vQkHgLQrO1lvdQ1vVm1ayuZba0wk9uVjNkzSW0iCdpfLRPhD4P/ALK3xB+O/wC0HbfCnwz4
Xv7n4h3N1dWQ0O7aPT7mKe2jlkuIpftDRrE8awy7lkKkFCOvFUf2e/2e/GH7VXxg0fwD4B0c6/4t
18zCwsBcw23n+VDJPJ+8mdI12xxO3zMPu464FdlPF1G4OUHJ88n6uXLdbb6L79jCpQjaSjJJWS9E
r+e3+R+j/wCxMuq/su/ts/tnfBDQfDfh/SjbeDPHCeCdA1XwtZXut6zOWt2sLKGS5hkvL+GWziSZ
LJnmgmQNL5b72kOZ/wAEpfhr4x8FfE39r/wZr3we8L+IfHGj/DTxLFrLaUlzd/aL24a12eHQmk3Q
sY45ZI5sQ2scdyrxSxpLH5RWP8wKKUMy5ZRajpFt2vpZ9Nunf8BywjfNd6u19O3z/rufen7N/gE+
LP8Agmf4r8b/AAi+GHhPxR8Zr34wx6fd6LZ+EYvGl3oXhxtLlngSOyv0vXhtTd70W4KeZIYijzS7
cD339oP9mXQ/Aeift2av4D+G3gnW9O+EXinR9U8E6np/gu01Gx0q9lEa6/Z5lhmWdLW1kZprORmt
rN0aaO3tjsKfkdXa/Bf9njxj+0L/AMJZ/wAIfo/9r/8ACD+HLzxbrf8ApcFv9i0u02faLj96679n
mJ8ibnOflU4NZU8VeKpxjr5ej200319F2KqUbS53K39Lz8vxZ+jX7FY/Z38UfsZar8Zfjj8Lfhjo
XhX4mfGm48IeIJrHStVEXh2zi8Pf2nAuli3nkuLPdqCxhlt8KY7mSNsQiJYfir/gpJFa3X7TcWs2
Phbw34Ns/Fng/wALeIk0rw/po07S7d73QNPuZhbwgkKnnySjqSSCWLMWY+C103wa+D+v/H/4paH4
L8LW1ne+I/El0tlpttc6hbWCXU7Z2RCa4kjiDuflRWcF3ZVXLMoMzxUqtKOHjBXvulq3r9++i/4F
qVHlqOq5adui/rr/AMA+1P8Aghf8XtY0u++PngjSbXwrfarrnwg8Uz+HdPn8M6dqGra9qwhtjHYw
tLA9xeI0cLv9gJkgcRyMYSdzUv8AwSe/Z31m7/4LQw/D74n+A/B/iMefqsPjfRl0XSdY0nSz5Ekn
C28ctpZiO9+zRf6P5flM32fKBmjPw98Sfh3rHwh+Iuv+E/EVn/Z3iDwvqVxpGp2vmpN9mureVopY
98bMjbXRhuVipxkEjmsWqpY103TUo39m72vvrezVv6RLw6k5zi/iX9O5+mf/AATs+EPwM+En7A99
4j/aM8A6HFp2u/GW4+HvirVtc03UW1fw7b2ugyX8MVt9lcXNrOuoRRxy+XEGdJpI5SygeV6fqPwa
8I/EP9nnxR468JfC/Q9M+JniLXfCGo3Wk/D/AOD2neO5dN0q+8GWN+BDo19OIrKwe/ku83Ua7nlj
8tmlw2z8faKqGYRjTjTUFZO9+r0fVdr6dvyVTCylNzUt/u6f5an6r+MPgdFp3w2/bg8X+FPgp4d0
9PhT4o0rVPCcdz4I0jWE0C8dhFrlozRNfWk0dvaSmSW0aeW2tDiZYLV1XyvzO+MvxGh+L3xS1zxP
b+GfDPg2PXLprs6N4dt5bfS7F2wXW3ilkkaKMtlhGH2Ju2oEQKi8zRXNXxPtIqKVkv8ANvt52+S7
G1Olyttu/wDwyPs//ggN8Mrf4wf8FNPB/h/V/BujeNvCd7YaifENnq3h631mzt7VLWR45pBNDKtv
i7W1QTDY2ZBHvAlKt0P7CPwdvT+y/wDEDSV+DniS7+Img+OIbLUdc0v4d6R8Rdc02FbO4R9JuvD+
ozxy6fEJ1aT7ckXzyI8LNuiVR8hfs9/s9+MP2qvjBo/gHwDo51/xbr5mFhYC5htvP8qGSeT95M6R
rtjidvmYfdx1wK4ytaeI5KcLxejlr3uo6bdN9+vQidJynK0t0tPRvz6/oezf8FEPAo+GP7cvxV8O
rp/g7TBoviS7s/s/hWMw6QuyQrughNxcG33Y3Nbec3kOzxYTy9i3f2S/2cPHnxA0DVfGXhj4K2Px
z0fTrhNGu9HSW+vbrTZ5AJo7l7LS7uC/SMpFIizuv2YlpEyZAu3wyiuZVF7Tna/r5p/ka8kuRRvr
3/qx9hf8FBPgD4i/af8A+Cy3xW8CfDrTINd8Ta74pvhbWaXOl2aTTxQtPdDzIpFtl2mOc5lcTnb+
/wD9JMoqP9lLXviv45/YW1PwN4c+A/hD43/D7TvHg167t1/tK717T9Tk08RI722l6hBdrZm3hlCy
yQmEu0qiQuAq/Of7P37P3i79qX4v6P4C8B6R/bvizX2lWwsftUNr55jheZ/3kzpGuI43b5mGcYGS
QK42uhVrS9vyvVy7W6aK6a0vr5NaLrKh7vs09kv63P0X+Hn7HHwq8K/8FQf2o7TTPD6az4P/AGd/
CHiPx14c8O61dR6jp15faaIDDZ3vlSu09mk0z5heVZisSR3GH86M8d8EviN8Sf2xf2O/HXh3X/hF
4q+NOhaz8WD491S+8Baxa2PieDXLqxnSY3FlHaXjixlj3ski2kUSypIolY/u1+GaKpY1LSMbLW9r
a3+VtPT7iPq73bvtv5fPvqfvx8UP21fAH7Jnw3+NeveMvhvofiv4WeJ/2jp/Dvi3Rv7H0/VGupE8
MWlxJLHCLgWzTtqdnHMwmO9C83mItwSsfiH/AAUQ/aGHij/gmzqfxJ8ZfDvwb42ufHfxV8LarLZ6
mmq2emxT3Pw50qV5LdrW+gumUEMqCSRlCu+4M+Cv47V2XwO/Z+8X/tH+LLvRfBujvq15pum3OsX8
j3ENpaaZY26b57q5uZnSG3gQYBkldV3Mq53MoPbLN6tSPsIQ32W+9/v30XT5mP1KEZe0vba/oree
mx+sfxq+Avjj4t/8FE/j9eaP8I9G0P4SeCvFT634k1i3+Eek+MPFHiO5n0/Tf+JZpqTW12jz3DL9
qUYiWAalLPeFWZYq/Mn9vaTVbj9rTxdcaz8NNL+D13ePbXUfg2wtkto9Bt5bSGS3heNFULMYGieX
5Iz5rybo4mzGvnHxC8Bat8K/H2ueF9etPsGu+G9Qn0vUbbzUl+z3MEjRSx70LI211YZUlTjIJHNd
p+zD+xr8Uf2zvGL6F8MPBOteLr6FlW5ktY1jtLEsksifaLmQrBBvWGXZ5rrvKELk8VxVas61qMYP
mu9N3fta2lv+HNqdNUrybVrLy+9n1b8KNS8GaL/wb/yT+OPDnifxFpEn7QbxpDoOuwaLcrOPDkZR
mnmtLtWQKZQYxECS6nzBtKv9Ef8ABU3wPN+0R4D/AGhPhP8ADPwTfXXxI8KfHK38ean4R0i0ik1G
TR5/D9nYnVILe3LG5SW9k8x/KDSxi6WSdIy7bfzK+EH7IXjz44eAtQ8V6LYaLZeFtMv49Jm1rX/E
Wm+HtNa9kjeVbWO4v54IpZ/LRnMcbM6rhiACCeM+I3w/1f4TfELXvCuv2osde8M6jcaVqVsJo5hb
3MErRSpvjZkfa6MNyMVOMgkYNbLG1I00nD3bct/k+tvPS9yFRXO3GWu/5dLn6Gfskfsxa/8AAr9h
f9ujRPiR4L8V+JrDw/deHNN1aLwrq0Y+03VjqTXF4keopb3duGtY5I5rhWjdokJEgiY7lg/4JX/F
y+/ba/4OBNL+J9l4Ms/DNhq97rGu6jp+jWrS2miWzaZcQCadwm3c8skQkndUWS4uCdqmQKPhT/hn
3xcP2eh8Vf7LT/hAz4i/4RT+0vttvu/tL7N9q8jyN/n48n5vM8vy+27dxXR+H/2JPiX4t/aqk+Ce
laDZal8S4rm4s30q11qwmjSa3geeeM3SzG2DRxxybx5vysjIcOCtGHxFSnUouEH7rTS76tq2nqlv
6blTpJqbctWvu0V9L/M828S+GtR8GeI9Q0fWNPvdJ1fSbmSzvrG8gaC5s542KSRSRsAyOrAqysAQ
QQRkV93/APBM7wJLdf8ABKz9snWdd8HeNfE/gqePwuk8WhXDafLetZ6i1zceTdvaXMKm1jkimmBi
YpC+TsDBx8wfAv8AYZ+I/wC0d8KvEfjfwrZeF5PCvhC5htNb1DVPGGj6MmlPMVEJnW8uoWjSVm2R
yMAkjq6KzMjAed/Eb4f6v8JviFr3hXX7UWOveGdRuNK1K2E0cwt7mCVopU3xsyPtdGG5GKnGQSMG
uSlzUmqsouzvb5pre1n+pc+WovZp6q1/wfyP2N+BH/BUfwRZfsNeN/jF8SPhN4bvvh/8Vv2ib238
SeFLbR4NViNs3hyC4hKRzvFDNdC7trWWWWUAO8k0iorsoT87/wDgrd8VLz46ftqXXjbUrKzsdV8X
+EPCetXyWYdLRp7nw3pszmBHJZIgX2qrMzALyc5A+aaK3xWY1K9GNGW0dfnr/noumvyzp4SEKntI
+n5f5H2x/wAG8PhXU/Ef/BW34ZT6fZahdW2jxareajPbQyOtjbnTLqDzZWQHy0Ms0Ue9sDfMi5yw
pv8AwQ6+BWo+Mv8AgqTovgbxJ8P7DxBY21tq9r4r0bxJ4Xh1GPS0gtpebiK6hf7JIl6ltF5hEbh3
ERYCVlb4poqaGNVNU1y35JOXrfl02/u+e5c6MpOTT3VtvXz8z9OP+Cdnwp+Anwi/YBm8QftGfDzS
Y7bW/jZc+AfF+sa7p+oNqWh2NpoLX8NtarakXVncLqMapKY1DSJM0cm5U+T1TXfhr8NPiJ+zdrHj
XwL8LLHRvizruveE7rXdN8EfCbSPiCdOsL/wbYagiWmhXsypp9jJdz3JNyuXklQIXfkJ+OdFaQzC
KhGm6atG+vXW/W3S912ZE8K5Tc+bfp06dPlqfrB8T/g1oo8DftveM/AfwM0nQbT4X+ItE1TwfZah
4S0nXm8P6iRHF4ht2khW7tJYIIJJJZLF5Zbey8yNxFBIgZPzD+MHxCg+LHxO1rxLb+GvDfg+PWrl
ro6P4fhmg0yxZsblt45ZJGjQtlgm8qu7agVAqjm6K5sRifa7K2/33fSyS00+RrSo8nX+rf0wooor
lNgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKAPsf/ggV/wApTPBH/Yv+Lf8A1F9Wr+t/4pf8gO5+g/mK/kg/4IFf8pTPBH/Yv+Lf
/UX1av63/il/yA7n6D+YpoD40/a1/wCROH/YSg/9FT0Ufta/8icP+wlB/wCip6KctwOi/wCDo7/l
BR8c/wDuAf8AqQ6ZX843/BGLxHpw+Kvxm8Fy6jZ2XiP4tfB/xF4G8J2t1OlvHrOtXi2/2WxE0mIo
nlMbKhkdFZ9iBtzqrf0c/wDB0d/ygo+Of/cA/wDUh0yv5KPg18GvFH7QvxS0PwV4L0W88Q+KPEd0
tnp9hbAb55DkklmIVEVQzO7kIiKzMyqpI1wtSUKsZRV3279DKvBTpuLdj7O/ZAEH7MP/AATv+Jvi
f43eHrr4i/Cy78ew+DLX4UXV1PplxY+KoI4bqbVZbjaJNMdLKKa1LW4aW4LNFKqxxhq+lh4R1v4g
/Df9tXxB4U+HVz8XfDfjbTvh1qPhPwzJ4dv7KFNOmjt7600VLfSZoyZNO0+6s9y20xG23jkbh3U/
l14m/ZS8deEvgje/Ei60uwl8Daf4ul8Cy6xZ6xZXtu+rxW/2loI/JmdpYzD86zxhoHH3ZGrtPB//
AATS+L/jfwRqviS00jwpaaJoNnpmoandap430LS10621K2t7mwmmFzeRtHHcR3MOxmADOzR58xHR
eulXmoxp+zvby11UvJ/c72s7bs5qlOHM589v6Xmu34n6G6X468L/AAL/AOCc/wAUvCPxZ8JaP4X8
E/Ej9qC+8M+MvDWkatBc/wDCAWFzptrepPY3GnK8bXGnz28P7oRPG32R4GhBZlTyv4++Frr4k/8A
By1qOraBq7eLNE8C+N9H8U+IdbmurZbXQNL0tLGbUJLm4GyKKGyWGSAtId+YURi8zfN8afH/AP4J
7/F/9lzwfrGv+O/CP9haToPiePwdfz/2rZXXkaq9hHqC222GZ2bNrKkm9QY/m27twKhl1/wT++Ll
n+0b4j+ETeEw3xK8LWMmoXvh6PVbKS8mjS3S5aO1CzEXk/kuHEFsZJmAbah2NjV4ypLkpypt2aa7
vVu23nppprbdi9hC8p826t5bLX8vwMj9tb4g6R8Wv2yvi34q8P37apoHibxprGrabetC8Ju7ae+m
lilKOqsu5HVtrKpGcEA8V9XfCnXPA+j/APBvxIfHOi+K/EmnN+0I/l2Oha7b6LNBL/wjceyVp5rK
7VlKiRTH5akkKQ42srfAles/A79iT4hftFfDLxB4y8L23hRvDXhS4itdYvdV8Y6Noq6Y8pUQmVb2
6hZEkZgiSEbHcMqsWVgOPD1Z+0lKMbtp+e/yZvVpx5FGTslby2+4/R74dXlpq/8AwdqXDwas3ieB
tc1CKSZngkMLr4cnSS1PkKE/0Zw0GCC4+z4kZnDsflj/AIIReH7/AMM/8Fi/hhpWpWl3pep6fc61
aXdvcwvDPYyppN+riRDhkeNgchsbSpz0NfKvxk+Dnif9nz4o654K8Z6Nd+H/ABR4cums9QsLkDfB
IOeGUlXRlIZXQlHVlZWZWBPM1tDHunVhNR+Cbla7/u6f+S7799iVQvF2e8Uvz1/E+9P2XPgLrNh/
wTF8U+IPhv8ADWz8b/H7TPi7H4e17SrjwRaeL9U0XQl0mWRC+nXdtcfZEa9WZDMIkLvEYyx8vaPe
/wBqv9l7wx8MPBXx91D9mnwN4Y+JPxB0/wCOSadeWVl4N03xq/h/QJdEN4YYrFrWeCytY9Sku4Fd
IUb/AEUQl2MLCvyQoqIYuEUo8uy79ddVpo9fPYJYeTk5X38vTz8vxP1T/YE/ZJtdL+IXj7xn498F
+A9Y1SH4swaL438EaRD4Zu9A+HGjCC41K91K5uru3v0tdOiQTWwjgntW3WskX2nzkVUzv2DPEkHw
C/bO/bW+EPg2x8LiwsfCfj+w8FaVceH9P1XVNYvILiOK106OW4hkur6MwW5Y2TPJFJ5Tu0THe1fn
34O/Zi8aeP8A4C+L/iZo+m2V74N8BTW0Gv3S6tZrc6abmWOGBmtGlFyySSSKqusZQkPz8j7anwa/
Z78YftBHxUPCGjnWP+EJ8O3nizWsXMMH2HTLQIbi4Pmuu/ZvX5E3O2flU10UcY4+z5YO6be+997a
f57Gc8PGXNzy00T8up+hP7OP7Lsfhr9kv4nXeq+FLTUfj7pvxdXR/ENr4M+Gnh74oXWlWD6a86QL
pRkFjYWxuzcL51sVxJB9n2fuisfsHwF+Afhrw78cdR174RfDfT28Y237UWjad4i0+TSdE8Tal4J8
NSW8dzMRFaC6ttKtob1rpUubZlaPyBE0we3Ir8Y6Kijj4U+T3Ph893rrtpv87IqeGlJS97fyPZv+
Cjkbxf8ABQv48LJIZZF+IniAM5AG8/2lcZOBwM19BfshfCDUNX/4JZ+IPF3wo+HekfEX41w/Fa20
nUrceELTxnqGn+Hzo80sTnT7i3uVtoXu/MH2gRqZHj2bj5eK+F6K5IV0qrqNb369/PyNpUm6agn2
6fp5n6O6b8AfE+i/sf8AxV8QeE/hL4E1v9oiH42Np3iLw94e8L6X41h8L6LLpc90LeCw8u9hsrZL
tpY1ePDboGhZt1uVXqPjV8M/AfwY0T9vG88K+Hfh5qa/B7xj4e1jwVdyeHtK1mHR7jVLx7a+tCz2
oR4EieSIWE6SQ20kOVHnxec35v8Awd+D3ib9oD4naL4M8G6Pd6/4m8Q3ItbCxt8BpnIJJLMQqIqh
neRyqIiszMqqSKXxE8Aav8J/iBrvhbxBZtp2v+GtQuNK1K0aRJDa3MEjRSxlkJVtrowypIOOCRXT
9aappqLtrrfrrtpurpv0WxDo3lbm+Xlp/l+LP1N8U/s4eGfB/wARv2i9J+HXwpudXvNH+KUEcOve
DPA/h/4sSaZYzWE0x0ltDvGt302FJy5FzFCUDxSWjSM1sGfB+Jv7LF/8I/gd8cbr4V+Dfhd8UvjP
pXx2bSNUj8J+CbPxXbaVoEmlTXcaW+k3MN2unW63RliYqvyy27weawt+fz3+B37MPjX9ou38QXPh
bTbGTTPCltFd6zquqavZ6NpelxyzLDD515eSxW8bySMFRGkDOQ20Ha2O80T/AIJk/GjWI/HTT+Gt
G0H/AIVlfRad4pXxD4r0jQm0OWUoIGmW9uoiIpi6CKYAxSk4R2Oa0jWlKzjTfXbzvqtOncxdJRvz
TXTf5b69f1Ps39kP4f8Ahr4Z/wDB0UuheFbfQtN8PWnibXTZ2ui3S3VlYmTR7yQwx7YoliMcjshg
CYt2Uw5kEe5uM/YU/Zm0y5/4J5+NdQt/Beu6h8ZtF+Kseg61a6X8L7H4h+IdH0xNNkZIptHv3RbK
BroXIa5GHaW3WIghSU+O/it+xX8Uvgb4G1jxH4v8Haj4e0nQPE//AAhuoPeyRRzW2qm1+1rAYd/m
lWt8SLKFMTqQVc5Fcj8XfhH4l+A3xK1nwf4w0e70DxLoFwbW/sbkDfC4AIIIJV0ZSrK6ko6srKWV
gSo4r2aXNB2Tk1rb4klva91y736dDT2Lf8OXRLvtr+Nz0b/govo2keHv25/ilZ6F4Th8CaVB4guB
B4fi1Cyvl0rJy0W6yZ7aMhi2YIXZbckw7j5Wa96/YF+F994i/wCCYP7S3je3+Huj+I9Y+GN7omse
FdWu/BdpqxtJpJmh1YNLNBILiCLT2WV7efzIYMrchI5AJa+HKK5KeI5KrqJd/wAU/wAt15o2lTbg
oJ7W/D/M+7f+CNcdn+1Z/wAFfNNudR+FPgK/8I+KV1S98Q+GrfwtFqGgaTbtbyOjRQ3QmFnGLz7M
qOrrtMqwqwSTyzifsjeGv+EA/YD/AGo9U8QeCfDP/Cc/BnWPDlzoz+IvCVld32iX93fy6dfW9wl1
A5lQwq6/ZboPFHKnmrGkyh6+LaK0hjOWnGKjqnLW/wDMkvwautdyHQXM300/A/Vr9r34V/CT4MeK
/jz4f8JeH/gH4V8d2nxXtZtV0rxVdW81hbeCZ9GE7GyFxGk8Za5kleSLRP8AT4S6xW+4R27t8hf8
Fl/h/Y/Cz/gpr8WdA0vw34c8I6Xp2o26WelaCiR2FtA1nbvGURIYVRnVg7oEwru43SY8x/L/AIS/
theP/gr8Pbrwho+p6TfeEbzUl1ltC8QaBp3iHS4r4RGH7XFbX8E8UU7REI0saq7qiKxIRQOY+Mvx
l8UftCfFDWvGnjTWrzxD4n8Q3Bub+/uSN8rYCqoVQFSNEVUSNAqRoioqqqgAr4inOnZKzv29et/N
dBUqMoTve6tb8j69/ZF+Fl7qH/BLzXvFfwp8AaL8Q/jWnxTt9I1O1PhCz8Z6hYeHzpMkkL/2fc21
yLeF7zzF+0qimR0EZY7AB9YfAf4f6P4S/b+/b68KfD/4MeDtT0jSvh34jggXw7d6rfQtNNFZ7dCH
2eaGGNZ5o7hmtYYknikjnghm2QgH8bKK0oY6NNwah8Pnvv5bu/nsiauGc73e/wDwPPyLviXVYNd8
R6hfWum2WjW15cyTw6fZtM9tYozFlhjMzySlEBCqZJHfAG5mOSftP/g3j+Hmu+Jv+Cpnw612w0fW
rvQvDT376vqdrZPNa6QJtKvkhaeUApEHcFVLkZIIGSMV8P0Vz4TEexrwr2vytO22zub1Ic0HDurH
6T/BH4f+J/DX/BHDxB8PLn4JSfEn4heHfjmmoar4C1Ww1kato1rP4eQQ389np89texITGyRySN5L
+bINpYKV+SP+ClHwU8Nfs5/t4fFLwR4OFknhnw5rs1rYQ2urNqkdqmAxg85kVt8bM0bRvveJkaNp
JmQyv4fRTq4iM6cYKNrdfv8AK/XXUmFJxm5X3/4B+qP/AATT+Pfgr9nX/gj5Za94500w2p+Pd1aa
F4oFkupHwJrMnhhBZ659gb5L37GwL+Q2fv8AmL+8ijVvPv8AgmX+yV4s8Mf8Fxx8L/i34X0b4iXU
cuoy+NDq2mQ+JbS7gktGu4tQeW4jkMfmzvZuJ28uXNwI3KmV4z+d9FdVPMlH2SlG/s2nvv3T066f
LTXpm8N8bT1kfof/AME1fgp4ysP+Cd/7Y1u/wk8QeONS+1eGNHi8NXej6qU1C9s9VZ722ZbN4bjz
rRJIpZI0dWjyhkAU4bgv+CkXwV8aftg/8Fqfij4K8F/YfHHi/XvEM1vp8Vpq1oYphb2Ycw+ey28K
NDDCyNG+WjaFo2knkUyyfFtFc8sRTdONPl0W+ur1fW2m9uq0vbc0VJqbnff/AIH+QUUUVxmwUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQB9j/8ECv+Upngj/sX/Fv/AKi+rV/W/wDFL/kB3P0H8xX8kH/B
Ar/lKZ4I/wCxf8W/+ovq1f1v/FL/AJAdz9B/MU0B8afta/8AInD/ALCUH/oqeij9rX/kTh/2EoP/
AEVPRTluB0X/AAdHf8oKPjn/ANwD/wBSHTK/nE/4I06/psnxS+M3gqa9sLfxJ8WfhD4h8EeErW8u
FtYtX1u8+zm1sxM5EUckpjcIZWRWk2IG3sgP9Hf/AAdHf8oKPjn/ANwD/wBSHTK/kq+C/wAF/FX7
RPxT0TwT4J0S98R+KfEdyLXT9PtVBkmfBYkkkKiKoZ3kchERGdmVVJG2FqSp1Yyirvt3Mq8FKm03
bzPs/wDY7SD9lb/gn38VvEnxz8JXnxE+F1147t/BMHwqvZp9JubLxZBEtzJqcl0VE2mvDZxz27fZ
w0s5k8qZVjRWr6H8D/DTW/FXwd/bp8QeEPhhrPxW8J+OU8A6r4U8OX2iX6Ry2V01vqdrpEcWnXCz
AaZp97aJ5VrOEjjt4CVEJVD+YniX9lfxx4T+C1/8RbrS7GXwRpviyTwPLrFnq9le276vHAbhoIzD
K5lQwjes8YaFxjbIciu08Gf8E2Pi7478Fax4is9J8KWui+HrXTL7VbnVPG+haWum2+pWtvdWE04u
byNo47iK6g2MwAZ2aPPmI6L10q9RRVNwbtt3+15O61220drXZx1KMLufOk216dPPfTffVeR+hege
NtD/AGfv+Cefxa8HfGP4cP4B8BfEv9pu68MeLfDUE88c3gTTrnTYL6G5sZ7eMxStZSQWk0WyCSO5
it9oRkmQr5N8d/AM/wARP+DknWNS0Gz1m58P+DfHOl+L/El/qjXEEWiaVY/YrjUb64mvCDDZxBXM
blhEUMKwZR4VPx58f/8Agnz8Xv2XfCOsa9478IjQ9K0DxNH4Ov5/7Vsrr7PqslgmoJb7YZnZs2si
SeYoMfO3duBUQzfsEfFmH9oXX/hR/wAIp5nxH8N2D6jd+H4tTs5byeNbdLkpaqspF5P5MiyCC2Mk
zKHIQ7H239Ym3Th7N+61a271btt16fOy7VDDwTlUU9X56dPPfRfgZf7afjzRPin+2P8AFnxP4Zuz
f+HPEfjPWNU0q5Mckf2m0nvppYZNsgDrujZThwGGeQDkV9g/8Eo/ht4n8Qf8EzP2vbzSfhRe/FOD
VJPCVjY6M1hqM9trVxBqbSzwp9gkhuZHgilinZYZl2DyzICjAH88q9A+Bn7L3jX9o228RXXhXTbC
TTPCVrFea1qmqaxZaNpelxyzLBD515eyw26PJK4VEMm9yG2qdrY46FV+15+W7d9F5p+T/I3rU70+
Vu1ravya80fpz+0f8LptYvf+CgfxD0bwzb/E2++GvjfTdR8MeJta8I22tnTbxpGh1uyzc20oubax
s3MZgm329tHDDOERxFKPEPhDG/xl/YC8d/Eb4Q/BnwBqfxr1j4u29vqfh7QfAUXixdB8PtpEkiG3
sL9L77Hay3xkw6KmXXyw2xI44/naw/4Jd/Gu6Pj0XXhvQNDPwv1JNK8VDXfGGi6MdEmkKCFpRd3c
X7iYyIIbgZhmJ/du+DjmfjJ+wn8Wf2fPAmt+JfGfg288P6N4c8XN4F1Ca5urffDrC2ou/s4jWQyO
jW5WVZkUwujKVkbcM9LqzTU+R6J/i3dp207ddvuwjThbkc03p+Ft1fr+p+l3xF/ZX+DV54+1+28H
eEvAusaf4A/ar0x/Fy2Og5HhvwkunQtfnUDIXNtpUVzHeJL5hS1DwzELGiqieQ/Fn4b/AA7+E2k/
tA+HtM0b4LaF8RtL+O18dR03xvaW9jDB4C8i4eD7DHcYnEDs5ZRop/tAxmEx7ibYj5E0L/gnH8Yv
EX7Veo/BC38L2MfxS0uETTaFdeINMtZHBhjm2RSy3CwzSeVKsnlxOz7Q524jcr6d+xn8GP2lfEfw
28aeHfhhD8O/FHg7RvFFrb61pet6r4S1nS7fWC32S1uIYdTkki3TtN5EV1brsuc+Wkkm3aNqNdtx
iqT0utFd639Ne/6BKKjq6nbd/j/kfXPxW8EXX7GXw4/4KM6h4S8H6Bpfhu317wdaaSlz4Rim0GGZ
71Lme0Sz1FLiGVokvIyQB5amSKWOOJGgVJvgveW/7PX/AAUr/bS+FXgjQ/A9jDqvw28S3XhDw/B4
NtZLrUdTmsrK5h0y2jukmuLmMp5hNkrNaT+W8iWyoVRPz58Sfsx/Gn9pSD4v/F3XdPsprnwjrF1d
fEC51bWdM0e/0q/klLSCawmmhnRpJmaOOOOHDyhoY1LqUGF8Df2IviH+0X8MfEHjPwva+FX8M+FL
mK11m+1Xxjo+irpjylRCZlvbqFkSRm2JIRsd1dVYsjAEMTP2sZQpu6u/leTdtNNHrvt9ylRpyhJT
ktbX9dLbvyOP+OPg3xB8PfjH4n0TxXZ6bp3ifTdTnh1W00/7ILa0ug582JFtD9nQI+V8uLCJt2gL
twPuD/gnZ8GvAnxK/Yj8Bave+F/C+v634W/aS0S68aXU+mw3U+keD/sCvcS6i7KfK0nfFOXabEAM
chY8HHxN8fvgD4t/Zd+Lus+A/HWk/wBh+K/D7xpf2P2qG68gyRJMg8yF3jbMciH5WOM4PIIrjq8+
hWVGpzct12f9b/I6qtP2kLJ29D9PdH/Zyg02X9uywsPBXww0fxP8K/HtjqPgZ/E+m6Jp2n6RBfap
d2zpv1RFt3s5dPaNoIbhzACYpYV84xvXxb/wUbtfAll+3J8TY/hlceHLrwMNakOlvoMLxaaqlVLp
AGdwyJIZF3xEQybS8KxwtGi3P2R/jH8X9f8ADur/AAA+Glx4Xew+Mtylnf6TqWm6JG2uThf9HiN9
fxhkdWGbdRMpSdwYQJpMty/gH9jT4k/FD9qaf4KaF4b+3fE221K/0iXRv7QtYtt1ZLM11H57yCA7
BbyncJNrbPlLZGd60lUpwjSg97bdbt2Xyav1dkZwfJKTqSW3fp3fb+tT7D/4IdftBeDPBnibwh8P
tGt/H+gfGXxr8T9ImvPEPhzQINVGreGLd4JpNGmle7imsrV54nnupoI33Qw4lWWNdi/M/wDwVI8J
zeCv+Cjfxusbj+0zcN4z1O7la+01tPkkae4ecukTSynyGMm6KQuTLEY5MLv2jwWisamKc6EaLXwv
+tP1HDDKNZ1U9z7T+CPhTUf2l/8Agjhr/wAM/AFne+L/AIjeFfi1H411DwvpkEk+qf2NLpcenLew
wAZuEF26RusAd496NIFQhq9j/Zo/Zs8V/CL9iD9tvSPif4b8WeP7Xw7aeDtM1b/hF9b3NFLp00c1
zp8eom2u4N+mQvAtzGsciQR27LlUCSD4G8IfszeM/HnwG8W/EvSdOsLzwd4FntrfXbkavZpc6e1z
IkUBa0aUXLJJJIFV1iKEq/P7t9tT9n79n7xd+1L8X9H8BeA9I/t3xZr7SrYWP2qG188xwvM/7yZ0
jXEcbt8zDOMDJIFbQrycoWg+a3Krdb3W1nfVv1CVPSS5tL39NnvdH378Yvip46/4Kl/8EyPHut+H
PCl74l8faz+0BB4i1Pwx4Wt7rV73S7H/AIRv7JDcvArSTJAzRGMSlFjZ0ZV2hVjX1/8Aak8M2/xE
/ag/aVm0PwHN468WWnxMs4pvGXhD4faP8T721sk0gRjR5tC1C8Z7JIpVYPfxrsmnhkhxD5Kwp+ON
dR8F/g54g/aC+KeieCvCtvZXniTxHciz022utSttPjupyCUiE1zJHEHcjailwXdlRQzMqkpYx3iu
Vt7dLvfsvPpr8zOeGSvK9lr09PPbQ9G/4KSfDmH4Sft2/FHw5APAoTSdcliK+DreW10ZGwrMsVvJ
LK1s4YkSWwkZYJRJEnyRqB4jW18Sfh3rHwh+Iuv+E/EVn/Z3iDwvqVxpGp2vmpN9mureVopY98bM
jbXRhuVipxkEjmrnwa+D+v8Ax/8AilofgvwtbWd74j8SXS2Wm21zqFtYJdTtnZEJriSOIO5+VFZw
XdlVcsyg8kk5VGorVvb9Dqi0oJt6dzmaK2viT8O9Y+EPxF1/wn4is/7O8QeF9SuNI1O181Jvs11b
ytFLHvjZkba6MNysVOMgkc1i1m007MpNNXQUUV2vwX/Z48Y/tC/8JZ/wh+j/ANr/APCD+HLzxbrf
+lwW/wBi0u02faLj96679nmJ8ibnOflU4NOMXJ2irsJSUVds4qiiipGFFFFABRRXZj9nzxgf2em+
Kv8AY7f8ICviIeEzqv2mHH9pm2N19n8rf5p/cjfv2bBwN2SBTUW9hNpbnGUV9Dz/APBK3436fqnj
mz1Dw74a0af4Zz2tv4p/tbxtoWnR6G10kT2xmee8RVSUTxqj5Ks5ZAS6Oq1bD/gmL8aLm58ew3fh
zQdBk+F+ox6X4pGveLtG0X+xppSohaQ3d3FmGYsvlTrmKbP7t3rRYeq7Wi9fLtv+TIdWC3aPAqK+
ktO/4JG/H7U/iXP4NHg7SLbxVBqU2kLpd54u0W0ubq6hsre/migSW7UzmO1u7eVzFuCCUbiCCB4N
8QfAl98M/F95oeoz6Nc3tiVEkmk6vaatZtuRXHl3NpJLBJwwzsdsHKnDAgE6FSMVOUWk9L20KU4t
2TMaiivWvgX+xD8Q/wBo74ZeIvGXhW08LSeGfCM8VvrV9qvjDR9GTS2mKrC0y3t1CyRyO4RJCNju
GRWLKwERi5PlirsJTjFXk7HktFdj8fvgD4t/Zd+Lus+A/HWk/wBh+K/D7xpf2P2qG68gyRJMg8yF
3jbMciH5WOM4PIIrjqTTTsxppq6CiiikMKKKKACiiigAorv/AAf+y/418ffAHxd8TtI02wvfBngO
e2t9eul1eyW501riWOGBmtGlFyY5JJVVZFiKEhxu/dvtpfs/fs/eLv2pfi/o/gLwHpH9u+LNfaVb
Cx+1Q2vnmOF5n/eTOka4jjdvmYZxgZJAq405SajFXb28+mnz0J546u+25xtFFFQUFFFdl+z9+z94
u/al+L+j+AvAekf274s19pVsLH7VDa+eY4Xmf95M6RriON2+ZhnGBkkCqhCU5KMVdvZCbSV2cbRX
a/Bf9njxj+0L/wAJZ/wh+j/2v/wg/hy88W63/pcFv9i0u02faLj96679nmJ8ibnOflU4NWfCP7MX
jTx58A/FnxO0jTbK98G+Bbi3tteuk1azFzprXEkcUDPaGUXJjkkkVFkERQsHAbKPtfs5aO29/wAN
/u6i543tc4Giium+Cvwp1L48fGTwl4H0aWzh1fxnrVnoVjJduyW8c91OkEbSMqswQM4JIUkDOAel
TGLk1FbsbaSuzmaK6j43fCfUfgJ8Z/F/gXWJrK51fwXrV5oV9NZuz20s9rO8EjRsyqxQshKllUkE
ZAPFcvRKLTswTTV0FFFdh8A/gJ4s/af+LekeBfA+lrrXinXTKtjZNdwWgmMULzP+9ndI1xHG7fMw
zjAySBRGLk1GKu2DdtWcfRXS/B74R678evidovg7wxBZXfiHxFciz063u9RttPjuZ2B2RCa4kjiV
3I2qrOC7MqrlmUHp/A/7HfxH+JH7Uk/wW0Xw79t+Jlvqd7o0mjfb7WPbd2YlNzH57yCA7BBL8wk2
tt+UnIzcKNSVuWLd3Zabvt6+QnOK3Z5nRRXTfBX4Vah8dvjJ4S8EaTcWFpqnjLWrPQ7Oe9kaO2hm
up0gR5WVWZYwzgsVViADgE8VEYuTUVuxtpK7OZorpvjV8KtQ+BPxk8W+CNWuLC71TwbrV5od5PZS
NJbTTWs7wO8TMqs0ZZCVLKpIIyAeK5miUXFuL3QJpq6CiiikMKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
A+x/+CBX/KUzwR/2L/i3/wBRfVq/rf8Ail/yA7n6D+Yr+SD/AIIFf8pTPBH/AGL/AIt/9RfVq/rf
+KX/ACA7n6D+YpoD40/a1/5E4f8AYSg/9FT0Ufta/wDInD/sJQf+ip6KctwOi/4Ojv8AlBR8c/8A
uAf+pDplfzif8EZ/E2mRfFX4yeDJ7yzt/Enxb+EPiLwL4Rt7mVIE1TW71YPslmJpCIonmMbojSMq
lyqZ3OoP9Hf/AAdHf8oKPjn/ANwD/wBSHTK/kn+Dvwe8TftAfE7RfBng3R7vX/E3iG5FrYWNvgNM
5BJJZiFRFUM7yOVREVmZlVSRthakoVoyirvt3voZVoKcHFux9nfsf6ZH+yr+wB8VPF3xy8G3nxB+
F1546t/Alv8ADC9uJtKuLbxZbxpdzajJcYE+myQWSTW5MCtJMZzFKqxpmvpbTPAfij4h/Cj9tzxT
4Z+GN98UfCvji0+HWoeFPDDeHb+ztLnT5YrW+tNKjg0mWJmfS9Pu7JGWCYYEKOwKOQfy18SfsxeN
PCnwg1Dx9dafp8vg7TPFUngubVbPWLK9gfVUgM5ij8mVzLGYlLrPGGgYY2yHIruPBn/BNf4v+O/B
2u+ILPRfDNpo3heDTbrWbrVfGmiaUmkxajbW91YSXH2q7jMSzxXUOwuAGfzI/wDWRSInZQrTSVNU
20k/XVS621Wuz00fdnNUpRbc+dK/3dPPy9dV2P0Xa/0v9mX/AIJ9/Fbwl8bPhpZeAfBnxR/aWfQP
GGh6bqYc+CdLvdIttUt5LGWx3xO+nslpMiCGSORIzEYvmwnjXxo+FN74k/4OSdSuNC8KP4e0TwT4
50nxj4jaRre1tNF0uz+xXV/q9zOr+VDA6h7gySurkzoHVZnMdfGHxk/Yc+J3wC8Ea54k8U6BZWei
eGvFreBdTurbXNPv1tNaW1+1PZkW88jFlizuYAorq8ZYSKyBul/sQ/EzXvj34m+F+naFY6p4/wDC
Vtd3OoaLY65p91O/2WPzLiG2Mc7Ld3Mahibe2Mk2Y5RszG4WpYmrJwg6b0afZvVu23Vt2079wjRi
uaSnuvktF5/1oUP2yvH2jfFX9r74reKPDtx9s8P+JPGOr6rpk/kvD59rPezSwvsfDplGU7WG4Zwe
a+jPgR4Rv/2mP+CN/ib4ZfD7T9T8YfE3wz8WrfxtqHhnS4HuNR/sR9K/s8XsMCjfcKt3KkcghDtE
HVnCo26viqivPhVSm5yV738tzqnTbiop7W/A/R/9jH9mzxF8EP2B/wBuTw78QvA3ijXLLQJvDFjr
mneGNWh80z2N/Jc3UceoQwXtqr2aMktwCjmKMOreWSWW58YvG/iH/gpt/wAE3/ib4g8A/D64vPF3
iH9ohfE974O8HWUmp3WkWMugSRJdzQwKZWEsquHuWiRJZxMRtLFB+alFdEcZFRUHHRJrfXW+t7dE
7dUYvDNyc76/8N5+S/I/XT4D6BZ+Lf8Ag6z8QT+G/Dr/ANh6Nrmrvqi2CQSQWTf2RNaT3MrWjPHG
JL2UZLsr+bOqShJ2ZB4t/wAE5v2UfiZ8Tv8AgnP+2V4H0TwR4oufFOs6p4O8O22mSWMtvI2o22uE
3Nu5kCpG9urhpvMZfIRtz7Vyw/PSvTvhj+x749+MPwL8Y/EnQLDQ7jwb4AKjX7y58SabZS6cXXMQ
NvPcJO3mnKRbI286RWjj3urKNqeMc0oKDes27dpRSfR2sle/+RE6HLHWVvhWvk79+p+j/wAQ/Cc/
7WPw3/4KQal8HfCet+KNB8S+JvCdtov9g6WbxNdu7PUz9uktPsaNHcqSz3BdcyNFPHM/LuTwP7DH
7LHxO+DH7E37a3g3U/hC/wAQPEFleeEtJuPDMQvNVt7+7g1B5p4El0m4Uyy2yTRSyJDPujO3eNvm
Kfhr4RfsjeO/jb4C1DxVo1ho1n4W0vUItJn1nXvEOneH9Oa9ljaRLWO4v54I5ZvLRnMcbMyphmAU
gnf+F/8AwTx+MPxk+LPjPwR4f8H/AGnxB8PdSXR/EK3Gq2VnZ6bfPeixitWu55ktmnluj5UUaSM0
zBvLDhSQ44ipOcJqDdlJd735npo9rvuKcFFOMpq2j16Wt5+X4mj4+8O3/hD/AIKWXlnqvhf4ceDL
5PiEs8/hvWr61vPCugGS/WT7BfSWh8n7HAHEU6xhdiRyIVRlKL5r+0I5k+Pvjhm/4Q8M3iC/J/4R
MAaBn7TJ/wAg8DgWf/PHHHl7K9F+Av8AwTX+M37S2meIbrwj4VsJz4T1mDw9rNtqXiLS9HvNL1Ce
VYILea2vLiKZHlnYQx5TEkoaNSzoyjk/gb+yJ8Q/2jfjTd/DrwroCTeOLJbky6LqWo2uj3Ye3OJ4
VW8li3TJhi0K5kCxyNtwjleR06k+WMYv3m7efppr8jpjOF2rq638v8j7r/4I1fCq3v8A9n/wT4u8
F+DNI8YfEiD9ofw5pXiaX/hHbXxBf6F4VNsZTcbJkmOnwmcSn7aiwsGhwJv3eEh/Yi+FkfxZ/wCD
iz4k+GtV8F6L428L3fjDxiviGx1fw3bavaW1qk940czrJG6WxF2tqizIUw0ix79srK3wb4g/Zp8Z
eGvhDqHj2406yl8HaZ4ofwbNqtpq1ndwPqiwtOYY/KlYyoYlLiaMNCwxhzkZ7aX/AIJx/Fux1XxX
bX+j+GtFh8FavH4f1fUdX8ZaLpulQak8TTCyjvri7S2nuVjVmeKGR3jwd4U110MU4eyXI3yO9r76
6rbyt16nPOjrOTklzL7vx/yPev2AvhTeyfsr/ECG2+Eev6j400bxpbWmoa/pXw40b4kavpkK2dyD
plxoOozJLp8RlVpPtyxESPG0LMDEFr3v9kr9kXw14M+PnxZ8VazpPgHx/b6d8aToPiHQtH0jw3/w
jfhHw5HHdalNrc5voNQNjp/kpLELWOW0kU27wG6M8YSP8tPid8Ntb+DfxF13wn4lsW0zxB4bvptN
1G1MiS+RPE5R1DoWRwGBwyMVYYIJBBr039mb/gnv8V/2wvCGqa78PdC0XWtN0XUbXSb57jxRpWmy
211dOkVrG0V1cxSfv5XWOI7dssm5ELOrKFhcSlKFNU3Jxvpf1e1vm9H9wVqcbSnKSSf9b3PuH9nn
4KeK/hF8Fv8AgoR4c+Fnw/1HxAuleN9J8PeGNMm8Mr4piuf7P1+5EluLeeKaG6kgtXR3LRyMgZH+
XcGqH9i3wH4S+H//AAdAW+i+CI4o/C9p4l12Szht2tDBbM2j3sssUK2m6KOFJWkVIhhoo1WOQI6O
F+EPBf7FPxK8a6L4g1L+wrPw9p3hXV/+Ef1S68U61Y+GYLbUwHLWO/UZoFe6RY3LwoTJGBllUEEw
fFX9jb4lfBHwdruv+KfDEukaT4b8VyeCNRmkvLdzBq6QG4NuESQs6mEb1mQNEykFXORm44ucXSqR
g7Qd/J2bk+mnn5LXbSpUFJSXNrJW/BLv6H2N+wJ+zlpd9/wT38Z6tZ+Eta1L4vaR8UIdD1e10n4T
6d8R9f0vTF02R445dK1CVBZQNdLcBrgKrNJCIiXAIj+hfgN8EfCWmfGrUfEnwe+Gmj3XiC3/AGoN
DtvEVtJo+i+Jb7wV4ZmtVuZlVLR7y102zivGu1S5tyjRfZlRp98BWP8AMr4Q/wDBP/4ufHbxndaD
4Y8KJeX9lp+kalO9zq1jY2kUWrJbvpqG5uJkg8+6F1AIoN/nOzMoTcjhcn4F/scfEf8AaP8Ajpdf
DLwr4dEnj+zNwkuhapqNro14Jbdts8AW9lh3TxkMWhGZAI5G24jcrdHE1abppUnpdLe7eq0031ad
t+uxlVpXcm5r/Jeev5l79v6zbT/28PjZbvcTXbwePddjaeYoZJiNRnBdjGqoSep2qq5PAA4r7X/4
I0/Da1vfgL4F8T+CvCOi+JvidH+0R4d0zxHd/wDCP22v6loPhU23mm5CTRzHT4ROsrfbY0hcNF/r
j5YCfBXiP9mLxp4X+EOpePrnTbKbwbpPilvBc+rWerWd7bNqqwvP5MZhlfzkMSM6zxhoWGNshyM0
fj38BPFv7MPxa1fwL450k6F4q0Folv7E3MNwbcyRJMg3xO6HMciHhjjODggiuOliHTr/AFhxdrv8
b9f6vZm9WkqlP2aZ+nVp8AvCPxD17xvqF34e0HxVqvg79s6Sfxvqd3o9pc32m+EQ0zXF1qbBMW+l
bop2kMscdruWTP3CFyPBf7OPhPSPhv8AtCP4Q8MXGv8AxC8OfHvU/D0n/CP/AAl0b4hapaaGkdx9
kX+yLh47WxtHuEn/ANItokG+NIgGTasf57fCD9kfx18cPA+oeJ9FstDsvDOmX0elzaxr/iPTfD2n
tePG0q20dxfzwRyzeWhcxxszquGYAMCeb+L3wh1/4FePbnw14ltrS11a1t7a7ItNQt9Qt5Ybm3ju
beWK4t3khljkgmikV43ZSrjmulY6KipOlprrfe9+tt1ffyMlh9XHn17HoH/BQ3RPDfh/9tj4kW/h
LSJfD+gvrD3MOkyT6dKNKklVZZrVDp0stoscUzyRpHFI3loio2HVgPo3/ghx8XtS0K++P3g3TbTw
5f6vr/wh8SP4c0+Xw7p9/qmu6vstTFYxGWF57xGSORzYZeGQRuzQtgmvgyiuKhiXTrqvbrfTTf8A
I6KtFTp+zf8AVj9DvAn7PXi/wp+xP8R9Q8K/DbwV44/aLsfjAmleJrDRfCeieNm0nR5dLknVYrKG
O6tLOD7aZE320MYDoYd/7oRJ85/8FVvhv4O+Ev8AwUR+LWheALzTbzwnba689l/ZzW5tLVpkSaa1
iEAESRwTSSQqigbBEFPKmvn2iipiFKmqaW3/AAfLfXXvZBCk4y5m/wAPQ+xv2G7WytP+Ccn7S/jJ
/C/gvV/EPwsvfDGq+HtS1jwzYao+nzX97Lp9yjC4hkW4ikgY4guBJCjqJkRZkWQfUP7VP7MXh/4a
eHP2gB+zd4A8L/Er4iWPxwWwurTTvBlh4xn8P6DNo7XRtorF7e4gtLaPUZLm3WSOGNwbXymdjHtX
8mKK0pYxRioON7L0111231Xfb0tE8PzScr/1pv8Ad+P3/Qn/AAVb+GPg/wCDn/BRT4teHfAVxp8/
hay1x5LVLBoTa2cksaTT2sQhARI4J5JYVjHMYiCMSyk17Z8JfiHpHw7/AOCCVzdax4T8M+PYZPj+
I10fXZ9ShtoGPhzP2hTY3VtIX4K48wrgncpOwr8H0VjDEONSVSy1v+JbpXgoN7W/A/Zz9pLwhaeI
9Y/4KUarqel+M/iP4TXUvCYlk0O8gtbqV7CaOW9tI7tLS4hU6dGw87dDI8cVvmZtxaWvJf2evin4
8/bg/Z3/AG4/ivcfCy9+JM3jrWPCv2Pw/JZ393b3a2+oNssRJpxtp5mtLVrZmaNkchI3kGHIb8va
K7I5nJNXWmumnXm8ntzPR367XJjQsrX7fp5+R+jf/BKr4beIPDP/AAcI2kFz4Kt/D9x4d1zxDqGr
aHo91a6lZ+FIpLK8UW7z2eLZUgknigJGxFk2xlUb92Ph/wCEv7M3jv44/HW3+GXhvw5d3Pjy5uLm
1XRrqSOwnjmto5JJ45PtDRrG6LDJlXKnKEdeK4SiueWJjKEYTTspNvXe/LotNNt7P0LjTak5eSX3
X/zCvvb/AIJoeHdXsf8Agl3+2L4hHw7Tx7ocEXhd5LK/t9R+wX62t/LNdK0llNBKRbRSJcybJV8t
Y0d/3ZIb4JorLD1vZT57X0a+9NdU+5VSDlGyP0J+FXhsfGH9hP4mfFL4LfCfw1rvxX1z43GK48M2
fgmy8YT+FvDM9hcXVrFHZzWksVvbfai8SzRQRbzBsPyqqD1r4w/sx+HPhbon7dWpfD7wN4V8WW3w
m8TaNrngvVD4R0/V4NHvJyv9vWKj7O8E9tZ208ivaTCWK0ECy7UkXzj+TlFdMMdywUbaq+t+6lqt
NPi/BWt0xeHbbd/60/y+5n358CvDF38Vv+Cevj74l/Cv4YeDfFPxu1r4ypDqWg6R4CtfE58O+Hpt
OnuYlt9NuYLpLSya8Z40dEDHyBGzsFVa9M+Cf7Mtlafs0/FvWLvwTpEHx4svjIdN13w/4A+GmjfF
KXwzpkmnPPHbxabcXL2tpZfa3uIhLFIXSW1ED5KgR/lvRU0sXCHLeO1+tlrfVaaPX8OmliWHk72l
v5emnoe5f8FLPDfhvwl+3h8ULDwl4fuPCehw607R6JNPp8zaPM6q9xaj+z5ZbRFjnaVFiikYRKoj
O1kZR9Mf8E6/gt4W8U/8E4/EniTQ9Ev/ABF8WV+JUOl3cOhfCrTviZrFlov9lvLCzabfyLFbW0tz
5/8ApMeHZ7cIdy42fnrRWVGvGFX2ko3Wul7b+fl/Vi50nKnyJ2/rzP02+LOheBPDHhX9uLXfDHw4
8J+HpPhb4m8N6z4TsNY0DQdWuPDV7qNybLUrNzD9qtpLcK8yrZtJLDbuiMscU8eV96i/YV+E/wAH
/wBuL4tatpGheGte8NW/xT0fR9a8IPp2hHTfA/h6TR11a9127uNTsbsW2n5e5iWO3azz5BRJ9wiV
PxPorpp5goyTcbpO+/r5ea3T2+7OWFurKTX9L/L8T9WvhJ+zd45/Z9+Gf/BQ7w58OfhjrF6th4t0
fQvCmk3XhJ/EMN5bwa7JIsUVteQ3C3RSxntpgXWRlSaGbdlkct/Z68C+Dfg//wAHTceh/DyLSbHw
vpmt6mILbT5FW0s5m0C4e7gUL8sQjuWnjMSgCIqYwqhNo/KeinSzCFOcJqHwyUrX7Nuy00ve3XZB
9WbTUnurfgl+h+if7D37O2jWH/BPrxrex+FNcvPjdo/xQOga7p1h8KLD4ha/oelxacTHHPpWosi2
UL3huka5TbJ5tsImDcbPmb/gp/pfhfRf2+fida+DvCKeAtCh1UBfDq3VncLo9x5MZuYAbOee2QLc
Gb91FKVi/wBXtj2eWvgtFcs68ZUY0lG1ut99+nc1jTtJyufpZ/wTK/Y7+DX7X3/BOOG08f6v4T8K
f8I78ZJLvxn4nW/0zStc8P8Ah6Tw+0dluu7tTi1n1UxRLH84aTzCEypYav7HP7JY8O/8FxPCfwv1
X4e+ENc07T/h/o8HjXQ5/DllrWn6Xcx+E7JriWYtDLBHK2prEWuom+eS52mU+c6t+X1FdVHMIQ9m
3TTcGn6pdHpt/wAHvpjLDScpNS0a23t5n37/AMEafHXiX4aeJ/2jPhnNo2i2viub4V+KodL0XU/C
unz67e65Glup00C5gN1cfJBNu08l4yUkYwEhjW7+zz4Y+JH7LH7D37cuueIfC3hqDXbDV/DGnXbP
oOka14ch1EasXu7SOFI5tMMkAuog0EakWxkjASNgm385aKiOOtTjCz93mtr/ADK3bp/Vty/YLmb0
1tfQ+m/+CyHwn8MfBH/gpX8UvDng3RLLw54ctbu0ubXTbPcLe0NxYW1zKsan7iebK5CLhEBCqFUK
o+fvh38SfEXwh8Y2fiLwnr+teF/EGnb/ALLqekX0tleW29GjfZLEyuu5HdTgjKswPBNYtFclWrzV
HUirXd/Q2UVy8rPuz9kb4Vzav/wSo1rxP8J/h9onxF+O8HxZi03VbUeDLfxlqVh4bOjvJDIbG5gu
YoIHvPOHnpErM6bGchUUd58H/hPrPiv4Yftdtqnw0/Z/8HfE34Y6/wCH9X0uylg0D+xPDGoXly9n
qNv9qv5ZrXyGiDj7Dc3D28FwSIYYp0RV/NevUPhl+2N4++D3wH8X/DTQL7QLbwd49P8AxP7W48M6
XeXGpYVRGGuprd7hREyB4gsgEMhaSPZIzOeilikkou6t2+f3PXe/S9tEYToy1cba9/l+Hkfpp4w+
En7PXxRmOo/Czwt8O9Z8OeF/2pdJvvEt5pekpdwaP4TbSLNr+W6lkVhFoYvYdQILf6HhJSp8sJXk
v7Fn7O2nz/8ABw7418Aah8NNH1DwAfE/iQX2hal4ThvLGw0bdPPYypDNCwtoi32DypYwmVmjRWKT
bX/NWiutZpHnhUlT+GXNo7Jq7dtn3t+gPDvX3nqrf8E/UT/gk/8ABCPwr8EPA+p6B4HsdQ+Oei/t
L6R4f8ZQXnhqPVtZ8L+Go7eNmllhuYpjpiJeC6H2pI4ZVkhYGUmJRHV/Y48Far4c/wCDovV9M1Ky
vdHvZfH3i+6jS4t3ik8maz1OeCZVKqSkkMkciMAFZHVh8pBr8xaKihmSpKkox+CSlvvb5fjqTLDS
cpS5t1bb+tPI/R/9h39nbRbL/gnT4pvbbwbqt78ddH+Lb+H/ABBY2HwpsfiJ4j0bSI9MUxRTaPqT
rHZwm9+1qbhVjkMsPlMZAAIvnD9v3xda/BD/AIKO+PtV+E1hrHwi/svUQLWx0vUre3utBuntES+h
jl0+5mhhHnPcqYoZtsasYtse0xJ830Vzyxa9lGnCNmne9/X/AD6dkaxpWk5N7nZfs/8AwA8XftSf
F7RvAfgTSDrvizxA0qWFj9qhtvPMcTzP+8mdI1xHG7fMw+7jqQK42iiuPS3ma63CiiikMKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooA+0P+DfHSZ9e/wCCsfw+sbVDLdXui+KoIUH8bt4Y1VVH4kiv6q/Hfxcs
Nd0ueK107xS7uAAD4a1LHUdxBj8jiv5cf+DaD/lNf8HP+uHiH/1HdTr+suw/49I/93+lAHx38c/h
z4g+J/h77Jo+ha9POLyOciTR7y3ARUlU8yxKCcuOBnvRX2hB1NFNu4Hxx/wdHf8AKCj45/8AcA/9
SHTK/nF/4Iy+JbFfin8ZvBTahp9n4k+Lnwg8ReBvClveTrbx6trN4Lc2tksrlYo5JjEyIZXRS5VQ
xZlVv6Ov+Do7/lBR8c/+4B/6kOmV/JN8IfhD4l+PfxL0bwd4O0a81/xLr9wLaxsbYAvM+CSSSQqI
qhmd2IREVmYqqkjfC1JQrRlFXd9u99DKtTU4OLPtD9j2GD9lr/gn78V/Evx08Jap8QPhhP47tfBN
t8LbyWbSZrXxZDGt1NqMl0R52myQWcMts32dWln87ypQiIGr6K8GeEPFvxL+EX7dPibR/hYfiVof
jKP4f3vhHwpDol6tpcaPMYL7TdNWLS5LeVZtP0q50/zIraQrGYRueSMhpPzA8S/sveN/Cnwev/iB
daTbS+CtN8VSeCZdZs9TtL20fVo4DcNBE8Mr+cvkjeJo90TKQVc5Gez8E/8ABOT4tePvC2t63ZaR
4ZtdI8N2el6hq13qvjLRdKj0221O1t7qwmmN1dx+Wk8V1BsLYBdmj/1iOi9tHE1EowUG7J+uqkt7
bavTbR92clShG7nzpN/5x8/LffVdkfoNpHjjR/gN+wH8XvCPxh+GMfgDwX8Sf2l7jw54y0C3upIJ
PBOnXWnxX0Etg1qhR/sMlvbzxbYJYLmKMKIyrqa8s+MHhfxH8Uv+DkLU9Xs9HC2ngDxxpfibX7qS
eS2sdI0bSfsclzqVxPdxwLBbiCESb2HlZkRIXmV4Xk+O/j1+wJ8XP2YvC+s61458HzaFpfh/xKng
+/uGv7S4WDVXskv1tv3Urls2rpJvUFMMBu3cUyf9g34r2/7Qev8AwpPhUN8RfDWnyald6Cmp2b3c
0Udst0y2wEpF3N5DiQQW5klYBtqHa2K+tVZclN02+Vp7avWTtou7fTuWqMfekpLVfLZef69uxm/t
p/EHR/i1+2P8WfFXh65S80DxN4z1jVtMuEieJZ7ae+mlicJIquoKOpwyqwzggHivpL/gj18bP2YP
hHJ4uX9orw/a6vb3lxpzWX2ywTVVZ1vrZopIYFsGliW3C3Mtyftyx3MDiE2d0cAfENFcNHFSp1vb
WTeu6utTepQjOn7Jtpfjofob+wR+0P8Asj/D/wCPvxVvfi34Y03VvC+qa3aTaSL21h1i2uGXULZ0
ntIINDs3t7aNlu5pkDWsclpNHbnT7ho9lR/sH/tE/sk/D749/FS7+LPhXT9Y8L6vrdrJpRvLeDVr
eRlv7d0ubSCHQrR7e2iZbqeZAbWOW0mjtjp87Jtr4sP7OnjIfs5D4t/2P/xb4+JD4RGq/a4P+QoL
UXf2fyd/nf6gh9+zZ23buKwvHfw+1j4Z63Bp2uWZsb2506x1aOMyJJutr20hvLaTKkj57eeJ8ZyN
+GAYEDpjjqsFB8i93XVb36Put7fMyeGpyclffz7f0jY/aD1Pw9rXxv8AFN14Uj8vw/PqUzWZWaOW
OUbvmliKWViqwu2540Fnb+WjIhjUqa+u/wDgnb8F/GHxS/4JR/tjWnhnwn4l8R3muS+DrPTYdL0y
W7lv54NWM08cQjBaRo4pI3dEDbVkRm2jaT8J0VyUKqhPmaurNW23TXn3N6lNyjyp9vwdz9EfEH7J
Hj7Rv+CSfi34Mad4W1rxP8U/BPx2ttT8Q+HtAsrjUr/TLaTw2VEstvHGZFhSYvELlQbeZgxiklQL
I3tv/BS/xx4H1X9lX476h4q0PxB4i0aP9qO4sHh0Hxe1pcC+h8OLCWM99YXDiJHiuAYBEI0LrHDI
0UKs/wCQNeh+Ef2WPG/jz9nnxX8U9I07Tb3wV4GuYLTXrlNasReaa08kUULPZGYXXlySTIiSiIxs
yyAMTFJs6aeL5Y8sI62fZ6Wl0t0vf5XMJUNeaTX9W8/LT/hj9Tvjh+zx46+Pl/8A8FFPD/gvwX4q
1jUfFHinwVo+lQtBe3P2y4gvo3mC3N5HG0aJHJHMwGIIYJEKP9mWKRvP/wBjDxlo37SH/BzC/jfw
N9s8ReDBe6lqs2oWhvdQht7X+xZbdppHuUWSKE3EiRBWHlRmWOKIsgi3fldRWkMyUalOpy/DJPfe
0nJdNN339Cnh201fdW28kv0P03/Y+8b+HfgV/wAEdvEfgf4v6Fe2Xg/xp8f4/BPjmKcz2eq+HLb+
y4pnvIUWNpEurK6tIZTG8Ugk8p4Wj+cmvVP+CkPwxn/aR+GXxo8GeDtG8eeIdR079pOz1TWNK0DT
b7xFrlhpMnhpIP7QFlN5c/k70lEO9ktmyscMoiVXP46UVMcw/dxpNXSVt+jvpttrp2+YfV/eck9X
93T/ACPW/wBvHwhqXw8/bE+Ifh3WfiBqXxR1jw7rEmlX3ifUFuVutSntwIZBILhml3Rshi5Zh+6+
VmXaT9O/8EzfgB48+Ov/AATB/a60Lwd4T1jxBe+LbvwXpemi3tjsubiHWDLMqythAIo5EklJYLHG
4kcqg3V8c/s/fs/eLv2pfi/o/gLwHpH9u+LNfaVbCx+1Q2vnmOF5n/eTOka4jjdvmYZxgZJArjax
oVVTqe2lBuL5lvbdNb23V0/z3LlTvFU09Vb8H207H61f8FD7yw/bj/ZZ+NcHwPh1n4pXs37Rdrrb
Wvh9rzXLs2j+GPs7XQhKGdbU3cc8cchXyBtEcOEVc+7/ABL/AG2vhh+zPoHxt8Q+LPDh+I/wt8Qf
tC3PhnxTpl7ZnXJbvy/DdvI4ijvpIlLRapYxbRITFHGhEKgRxGvwer074RfseeP/AI2/D298XaPp
uj2PhKx1FdHfXPEHiHTvD2mS3xiMv2SK51CeCKacRASNFGzOiMjMAGUnsw+ZzhPmpRfNr1v0lpa2
3vfgYSwsFG0paWt27f5f1ofpL+398cfDnxh/4J+a945+KfhvVdYm8YfFXwvrV1YeE9at9EEd5dfD
vTJmMc09pe/uELSAIQxbeh35Rt9n4NeHr3xD/wAHW+vXPh2w1+9t9G1PU7jU5p472c2IOhyW0s0j
zKHjtzczLHGwCwgSwrCfLMWfzPn/AGNfijbftRH4LP4J1ofFAal/ZX/CP+WpuDNt3hg2fLMPl/vf
P3eV5X73f5fz1xnxG+H2sfCX4ha94V8Q2Z07X/DOo3Gk6naGRJDa3MErRSx7kJVtrowypIOOCRzV
SzCoqscRUp/DO/zTcmr28+t2g+rwcXGDWqt8nb8NPmfo5+yD8Q/DvwB/4I6eKPA3xd8N3kXhTxr8
el8F+NoLk3Njqnhy3GlRTPeQhEZ47uyurSGUxSRSiQRPE0R3kj5w/wCC2L6e/wDwVL+MR0v+1fsn
9qw8agbsyiT7JB5oU3X7zyfM3+Vj935Xl+V+68uvGfCv7L3jTxv+z54o+KWlafpt54L8F3cFlrdw
mtWIvNOed4o4WeyMwuvLkeVVSURGNmWQBiYpNtH9n79n7xd+1L8X9H8BeA9I/t3xZr7SrYWP2qG1
88xwvM/7yZ0jXEcbt8zDOMDJIFck61SrShh+Vt9O71em2ursvO/fTaNOMJSqX9e2y/yPtz9iLSrD
x9/wSeXSh8Lde+PEnh745pq+t+A/D97dRX9xYT+G7i2gupDZxyXEES3IG2XbsdkMfdq+av8AgpLp
2q6N+1DFZa7Yy6Vrdl4J8G2+oWMtoLOSxuE8L6UssDQBEELRuGQx7V2FSuBivOPg7+z94v8Aj/8A
8JV/wiOjvrH/AAhPh678V61tuIYfsOmWuz7RcHzHXeE8xPlTc5zwp5rjaipXk6Eaco+j779bX693
byu7kaaVRyv/AFp/kfbn/BH343fsw/CGTxeP2i/DdtrlpeTac1kt3YpqYkdL62aN4YVsTNCsAFxJ
ct9vRLiBhCbS6bAHT/8ABPz48/sg/DL41fFC5+LfhYax4YvdUtG0MXqw63FOyX1uyXFvFHoto8UE
bLdTzAvbJLayx250+5ZcD8/K7L9n79n7xd+1L8X9H8BeA9I/t3xZr7SrYWP2qG188xwvM/7yZ0jX
Ecbt8zDOMDJIFaYfG1IypxhBNxbtpdu/TzInhoPmk21ffXa35eZ9r/8ABP346/sffDz43/FST4v+
HItU8J6hq9m2itdRRa1HOy39uUubWKLRLOSG3jIuriVd9qktrJHbnT7h1AHxJ8etR8Pat8ZvEtz4
UieHw/LfymzzcJOsi5+aSNks7JRE7bnRBaQbEZUMalTXI16H4R/ZY8b+PP2efFfxT0jTtNvfBXga
5gtNeuU1qxF5prTyRRQs9kZhdeXJJMiJKIjGzLIAxMUmzGeInVpxpWXu3ei17v5FxpRpyc7vW270
7fieeUUUVym4UUUUAFFFFABRRXZfB39n7xd8fv8AhKv+ES0j+1h4J8PXfivWj9qhtxZaZa7PPuP3
rrv2+Yg2JudiwCqaqMJSfLFXYm0ldnG0V6f8I/2OviB8bPh3eeL9H0zSLHwjY6iujvrviDxDp3h7
TJb4xed9kiudQngimnWLEjRRszojIzAB1J6e8/4JpfGnQtQ8UQa94RtfB0Xg/Wh4c1O98V6/pvh3
TxqJh88WsN1fXEMFzIYCkwEDyZhlik+5IjNcaNRpNRdn5EupBOzaPCaK6X4xfB3xP+z/APE7WvBn
jPRb3w94n8PXJtNQ0+7UCSBwAQQQSrIylWV1JV1ZWUsrAnmqiUXFuMlZopO+qCiiipGFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFAH3b/AMG0H/Ka/wCDn/XDxD/6jup1/WXYf8ekf+7/AEr+TT/g2g/5TX/Bz/rh4h/9
R3U6/rLsP+PSP/d/pQBcg6miiDqaKAPjj/g6O/5QUfHP/uAf+pDplfzif8EafE+mx/FL4zeCp762
tfEfxd+EPiHwL4Tt7idbZNV1u8+zm0s/OcrHG0zRMimVlVnKpnLqD/R3/wAHR3/KCj45/wDcA/8A
Uh0yv5KPg18GvFH7QvxS0PwV4L0W88Q+KPEd0tnp9hbAb55DkklmIVEVQzO7kIiKzMyqpI6MLUcK
0ZRV327/APBMq8FODi3Y+zP2QLWH9lb9gb4oeKfjp4OvPiJ8LrrxzF4GtvhdfXM2kXNn4rgjjup9
Se52+dp0kFnHJbv5CmSczeVKFjQGvphvAniD4l/D/wDbj8WaB8OtW+LugePovh/qvg/Q5vDeo20O
o2Motb6DT1i0yWORn07T7u0R/JnBxHHI2VkIP5beJv2W/GvhP4M33xCutP0yXwZp/iyXwRLqllrd
jexNqscH2hooxDM7SxGL5luEDQOPuyMeK7zwp/wTJ+MXjHwLq3iW10fwna6JoFtp15q11qXjnQdN
GkQ6hbwXFjJdLcXkbW4uI7mLy/NC7mLoPnjdV7aGIqWVONNu19t9pLs7rXZ6aPTVnPOnFNzc7X89
Onn/AMF3P0HvtTsP2af+CfXxS8JfGf4Y2ngTwZ8Tv2k5dG8XaDp+oDf4I02+0i01S1ewlsw8TSWJ
W3lVBBIkiReUYxvATyL45fDW+1v/AIOSNUv/AA/4WTRtH8EeOtJ8ZeIHZrWysNL0yzNldX2r3Eyy
GCC3kAa48yRwxNwiuBM/l18Z/GX9hn4m/ALwLrXibxPoem22h+HfFZ8D6jd2fiDTtSW11kWgu2sy
LaeRiywk7mAKK6PGWEiOix6f+xH8StY+PHiT4YWGh6fqXj3wpaXN3f6NZa7p91O/2eISzwW5jnZb
u6jXdutbcyTgxyr5e6OQLrPF1ajhB03aLXru9Hp69N72XYjShZtSWv8AwPP+tDL/AGufGXh74i/t
XfE7xD4Rjii8J674s1XUdFSO2+zIllNeSyW4WLA8sCJkwmBt6YGK88oorx5S5pOT6nZGPKkkfcf7
Emoad8DP+CbHxD+IfxY8OP8AFX4K+I/GNt4R0jwF9vksFHiiO3jvTq32xR5lkYrHzIc24Zrjz/Ll
CxopP1l8Tvhl4c+Lngz4mfEPw3oWseMPH3ijx/ouqWU+lfCDSfHuuaV4NvvCtreaPZNot3P5FtbQ
CRrZryPmSWzVSznIT81v2aP+CeHxZ/bA8D6j4i+Huh6FrWlaRqdto160/ivSNOntbq5eOO1jeC6u
opQJ5JVihbZtmkDxoWdHVfHtf0C/8J69e6Vqtld6bqem3ElreWd1C0M9rNGxV45EYBkdWBBUgEEE
GvRWMqQhT5oe6r2v13Ts99G9NbLXTVnI6SnOXLJX6rte1rq/l8z9Mvi54b8FeE/Df7cXiLwz8LvB
fhq8+EniDwtqXhzTNV0TRNZl8M399P8AYdUhbyzd2ksBZplFk0kkFvIyFIopYR5fyj/wV2+GWg/B
z/go/wDFXw54Y8Jv4I0Ow1OJrbRyY9lv5lrDKzxrG7okUru0scY2+XHKieXEVMafOFek/CP9krxz
8bPA1/4o0ax0Wz8MabfxaVNrGveItO8P6e15IjSLbRz388Ecs3lqXaONmZUwzAAgnGeIdaPs4x1b
vp/283pbzW1lpsbRgoPmb/rT+vmebV+gn/BKz4e+HtZ/4J0/tP3fxPvvFHhX4R63rXgjTNY1/TNO
e4ZFi1kPcLBn5HliSeEuAJXiS4WQQynbG/xB8XfhHrvwM8eXPhrxJBZW+q2sFtdMLPUbbUbaWG5t
47mCWO4tpJIZUkhmjdWjdgQ45re8JfsreOPHf7Oviv4raTpunXvgjwPd29jrt0utWK3emyXDxxwF
7IzC68uR5QqSCIoxSUBj5UuyMO5UqrvC7SemvZ3v106jqpShvbbX5/1Y/UPxT+zhpekeBvjXOvwc
0bwr8Z9M+L8GmXmieAfhjpPxNk0bw22iRS6aselXrxR29tcOZJnvkiheWYhDGpzFDyHxG+CWj2ng
j9tnxp4J+COl6PH8MfEOiah4RtL/AMKaTrf9g6gQieIYGMX2uzlhgt5JJZbJpZYLLzI5BFA8YaP8
qKK3eOjZJR7637312316WTsrrQyWHab17dPTz2Puf4D/ABD0X4nfsc/tXfFT/hW/wm0TxF4O1nw1
r/hqztPClrdWGhXOoXktleLFFeLceZaPCWxaTtJbxSOskMUbRoU+u/jx+yf8KvBdp8eU+G/wzvtK
8e6Z8YrXTm07w98ONJ+JupWOhzeH4riIxaTd3HlWVhPevdzJcRhGGYYNo8sxw/i7RU0saoJJxvbz
666+T1W3ZDqYe+sXb+l/l+LP1B/ZA0jwz4a/4ObNMsfAnhOfwBolvq+pRR+H5buzmfSLj+wbkXcJ
NnNcW8eLkz/uY5GWHPlbU2GNfz7+DHhvUPC37T/hTR9VsfDWl6rpviizs7yz8cRNb6PaTpdojxao
jgFLZWBE6sAQgkBxiq/7PH7PHjH9q34xaP4B8A6P/b3i3XvO+wWH2uC18/yYJJ5P3kzpGuIopG+Z
hnbgZJAPFUqmJbpx93aUpX6a8t1t0svv2RUIJSaT1svXrr+Z2X7Rcvn/ALQfjt9vg1N/iHUG2+ER
jw8ubmTjTh/z5f8APH/plsr7b/ZNsx45/wCCJ+p6D4a+Etp8cvGdh8bxf3vhoLqt7NYWEuhLHDfN
b6VcwXMa+dHLEskjeU5kZQGdMr+eVem/CP8AY/8AH3xs+H974t0bTdIsvCVhqSaNJrmv+INO8P6Y
988TTC0jub+eCKWcRKXMcbM6qVZgAyk50KjVVyjG976evyf5FVYrks3bY/Tr4H6h8Df2Tf8Agof4
g+BPwjh+JPhnx3qHxm0+CTW9EsrbxFHd+F4Esp7jw/Nc/boprS0S+ju3uZESSUW9uiXHnGORR8b/
APBQCD4UfDT9vz48aX418D/FnXNafx9rF7FdWviSy8MxrBcTCaNfskum3rOu95XScTKs8MkDiKLk
N4XF+x38TZ/2oB8GE8Has/xObU/7JGhKEMpnxu3b93leT5f73z9/k+V+93+X89cb8Rvh9rHwl+IW
veFfENmdO1/wzqNxpOp2hkSQ2tzBK0Use5CVba6MMqSDjgkc101sXUdFQ5LJSfTT0ta1/wCrGNOi
lO/NfRf8P3P0E/4J3+F/FWrfsFftea78F/hn4p1Sw1OTwjY6Jper6JbeNjfTwXwe8h2PYLbXckaz
CcoLbdAksTHlRKe8+BfwC8BL/wAHJfinwP4f8AeD/EXwrt5rxPEGjnQrTXNI0kDTUknOySOWOzEe
q7Iv3fl+UzfZ1KKxjP5z+Ev2XfGvjr9nzxV8UdJ0/TbzwX4IuoLTXLldasVvNOeeSKOFmsmmF0Y5
HlVVkWIoxWQBj5Um3O+AfwD8W/tP/FvSPAvgXSTrvirXjKthYi5htjcGKF5nG+Z0jGI43PLDOMDJ
IBdHGSi6ScL2adu+r0WmibdnbsOVFS5tVZ6eey3dz7Q/4IueOte+Hvif9ov4bXOkaFb+J5fhT4qG
kaJqfhewn1vUteiS2C6btnga5uhiCUtprl4WMUjNASGNfLGr/s1+NfF37bEXwp1mPwxo3xB8SeLI
PD9zFaz2f9ladqF3cpH5edOD28Uccku1o4FIi2sgQFNg5f4QfALxb8eh4pPhPShqv/CFeHrrxVrO
buC3+x6balBPOPNdfM2+YnyR7nOeFODjI+HfxJ8RfCHxjZ+IvCev614X8Qadv+y6npF9LZXltvRo
32SxMrruR3U4IyrMDwTWM63NSpwqJ8qbtr06203Xe/yKVK0pSg9X+Ze+N3wn1H4CfGfxf4F1iayu
dX8F61eaFfTWbs9tLPazvBI0bMqsULISpZVJBGQDxX03/wAECl3/APBW74QqQxVptUDbVDHH9k3u
eCDnjtg5r48r1r4I/sQ/EP8AaH+FfiHxt4XtPC0nhjwnOlvrV9qfjDR9IGltIY1iaZLy6idI5HkV
I5GUJI4dEZmR1XPCzlHERqU03Zp2W+jv2f32+RdRL2bUnvpc+mv2FfhZPY/sp+OtLT4NeIrj4k6F
49jstV8QWHw/0b4jazp1sllMDpNx4c1KVJtORbiOSQ36x4kdXgYhoQp968K/Abxx8OfBH/BQC1+H
3gjwj4ovxrvhvT9FsvB/gttZ8O391FqAlvba1026F3GJ7eG5Ek9rmYWcjEJtWOJh+f8A4Z/4JxfG
vxZ8ZPF/gG28CXtt4o8B3EFnr1vqF7a6fb6fNcXEdvaxm5nlSBnuJZYxAEkY3AcNFvXmoPhv/wAE
/fip8UvBni/X7DR9B03Tvh/qR0jxMPEHivSdAudAut6xiO6t765hmh3SN5as6BXkSSNSXjdV7Kcp
xjGPspXu9VdPZppaWur69dDGUYtuXMtbfp5nqf8AwUV/Zo8LeIP+CxPin4UfCQeGNH0jxB4r03QN
NS3uy2ladf3cdrHcIWjVvKjjvZZleNExDsZFQBAtfNvxu+E+o/AT4z+L/AusTWVzq/gvWrzQr6az
dntpZ7Wd4JGjZlVihZCVLKpIIyAeK6f4ieAfin/wT0/aSvNC1KfWvhz8TfCGzzJNI1hUvNP+02qu
Nl1aSkDfb3AB2P8AdkZT3FeYVxYiScpXjaV38vKxrSTsmndWXz8z7v8A2RvhXNqf/BKLWPFHwm+H
ejfEX48D4sppWrW//CIWnjTUNP8ADX9jmWB/7Pube5W2he8Mw+0pEpkaPYXIQLXoWsfCHVrP9j74
l+IfBfwV+GjftIp8aW0fxR4V8K+GbHxvbeGdEOjLMqQWMw1COyhN+bkF4SMSpJBlBAsSfAH7P37P
3i/9qX4u6R4D8BaO+v8AizXfO+w2C3ENuZ/Jhknk+eV0QYiidvmYZ24GSQK42toYjlhFuLtte9tV
203V1+F0T7JOTu/6/wAtPzP3H+LX7P8A+xz+z+Pidrni/wAEeAD8NvEnx4k8C63rEIvruTw9aQeF
LbVTBpv2L57NxrJlilW2ACpK8DKsaJs8e1j4ZeHfi18EvjR4r8KfDf4K+F/Fmk+D/h1450Vb/StH
0zRNF1LWLZIdRWOTU4ktvsj252pbXE08KzfvUP2snb+bvhD9lTxz49/Z18WfFbSNM0++8EeBbq3s
9euk1qxF3pjzyRRQM9kZhdeXJJMqpIIjGxWUBiYpNlv4a/th+PfhF8BvF/wz0G+0G28G+PTnX7Wf
w1pl3calgJ5Ya6mt3uQImQPEFkAhkLSRhHdmPRPMFJJOHLq3dWTd76dNE3p2a67GMcO18MrtWWu2
lune33+Vz9Pfhh+zr8D9Q/ae+I3xF+G1t4D8feAZfitp/h/WPDtrYaDJovhHRINMW/1PXZ7jVLK6
WDTGuPt0KfZTaRP9lZYZ3BgCeZ/sYW15+zz+2t+2N8GfD3hzRtKWLwf42HgjQdQ8MWWpazq0+6Jt
PsYXuoXvL6GWzRZFtS0sUygzGJ/mevy/oqoZqo8soQtJSbun0d7rbT/gbGzw909eh9QeG/2Qvi1o
fxP8e6vqPwQ8KfF3UNC1uTQvEHh7Sbv7dHoWpSkXO4WXh29hlgjAWWFSoFqjCaEASxbY/t79sr9l
vxJ8dv2w/j7451m9+Kvxh/Z68G+OYzZ+CPCd3LqL+LvFcek2CS2OyyjaOxitYZIoLi/li89YY0gV
5rliy/kDXUfBf4OeIP2gvinongrwrb2V54k8R3Is9NtrrUrbT47qcglIhNcyRxB3I2opcF3ZUUMz
KpwoYqCXs+Ryu091e+qt8Ou/W+3mFSl9pu1l8un3bHon/BRnU/inrX7aXjq7+NVhaaV8Srm5gk1a
ytZIJLeyQ2sJtoYmheRDGlr5CqfMdtqjezPuJ8Tr0HRP2XPG2v8A7Ssvwhh0ywh+IMOtXHh19NvN
XsrSMahBI8b2wuZZVty5kjZExJiRyqoWZ1B5f4jfD/V/hN8Qte8K6/aix17wzqNxpWpWwmjmFvcw
StFKm+NmR9row3IxU4yCRg1yVlOUpVWnZt79+zemprCUbJJ9DGoor034Sfsf+PvjX8Or/wAYaPp+
i2XhPTtSj0aXWtf8Rab4f0+S+eNpRaxT388Ec0wjXe0cbMyIyMwUOpOcKcpvlgrvyKlJJXbPMqK7
L44/AHxb+zh4xg0LxhpaabfXlhbarZyQXkF9Z6jZ3EYkhuba6t3kguIXU8SROy7lZc7lYDd/Zc/Y
v+Kf7anjGXQvhd4I1rxfe22PtUlsixWdhuSV0+0XUpWCDeIZQnmuu9kKrubApqlNz9mk+ba3X7iZ
VIqPO3p36HmFFen/AAo/Y4+IPxn+F2oeONI0vSrLwZpupx6JLruva/p2gabLfvEZhaQ3F/PDHPOI
l8xoomZ0RkZgodSew1j/AIJffGzwzo1xq2seGNF0Hw7C9nHB4h1fxZo+naDqrXds11AtjqM90lpf
FoFZyLWWXYMBtpIBqOHqySlGLafk/wCujB1IK6b2/r9V954BRXvur/8ABMP41eG9DutY1jw1ouge
HYJLOKDX9Y8WaPpuias11bm5gFhqE90lrf5hBc/ZZZdgxv25GZ9T/wCCWXxv8P6Hcazq/hjQ/D/h
qKSzht/EWs+LtG0zQNWe7tjdQLY6lcXaWl8TAC7C1ll2DG/aSBTeFrLeD7bPf+k/uB1ILdo+e6K+
gda/4Jc/G3wto9zquteGdD8PeH4TZi317WfF2jaboerG7tjdQCw1Ce7S1vy0A3n7LLLsBG7aSAXa
5/wS1+OHhTQrjWdb8K6P4e8NxyWcVv4h1jxXo+m6Dqz3dqbyBbHUZ7pLS+LW6mQi1ll2AgNtLAE+
rVv5H9z/AK6P7he1h3R8+UV2Hxu+Aniz9nTxdbaJ4v0tdNvb7T7bVrKSG7gvbTUbO4jEkNzb3MDv
BPE6nh4nZdyspIZWA4+sZRcW4yVmi076oKK2NE+HfiDxL4T1vXtN0LWdQ0LwyIG1jUbaykltNKE8
nlwm4lVSkXmSfIm8jc3AyeKx6Qwor1T4QfsXfET44fC7UPHGjaZotj4M0zVY9Dl13xD4j0zw7psu
oPC04tIZ9QuII55xEhkeOJnaNWjZwokQtzvxz/Z/8W/s2+NINA8Y6UmmX95p9tq1m8F5BfWmo2dz
GJYLm2ubd5ILiF1PEkTsuQy53KwFunNR52tO/Qj2kebkvr2ONor1L4QfsY/EP43/AAxv/G2jaZo9
j4N07VI9Ek17xD4i03w7pkt+8TTC0huNQuII5pxEvmNHEzMiMjMFDoW6ef8A4JmfGvSZPFZ1vwlZ
eELXwVry+GNVvvFXiHTPDtguptCZxaQ3V9cQw3MhgAmxA8n7qSKT7ksbNUaFSSUlF2fl/XZ/cDqw
Ts2jwaivozVv+CUHxz8OeBk8U6x4b8NaD4TuLuGys9f1jxvoWm6Rqcs1pFeRLaXk94kF0Gt5kcNA
7jhxndG4Xz7wp+yJ478efF7VfBGhWOh65rOhadNq+pXOneI9NutHsLKGATy3Mupx3BsUhRGUM7Th
Q7CMnzCEqnhayai4O78mJVYPRNHmlFe8zf8ABMz416U3iltb8JWXhC08G64nhrU7/wAVeIdM8Paf
/aTwG4W1gur64hgunNvtnAt3kHkywyZ2Sxs0+o/8EvfjXoWlXOqat4b0HQfD8ElpDB4g1jxhouma
Dqj3Vt9rhSx1G4u0tL5jARIwtZZSgYb9uRk+rVv5H9z/AK6P7g9tT/mX3nz/AEV9Bap/wS4+Nvh7
SrrVNY8NaD4f8PwSWcUGv6z4v0XTNC1V7u1+1wLY6jcXaWl8TbkSEWssuxWXft3DPl3xx+AXiz9n
DxrF4f8AGGmR6bqFzYW2q2rwXsF9aX9ncxLLBc29zbvJBPC6MCJInZchhnKsBM6FSK5pRaXoONSE
nZNHHUUUVkWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3b/AMG0H/Ka/wCDn/XDxD/6jup1/WXY
f8ekf+7/AEr+TT/g2g/5TX/Bz/rh4h/9R3U6/rLsP+PSP/d/pQBcg6miiDqaKAPjj/g6O/5QUfHP
/uAf+pDplfzhf8EbfF+nWHxO+M/g6a8tYPEXxb+EHiHwJ4UtZ5RAura1e/Z/stmsr4iR5WjZVMro
pbChi7Irf0e/8HR3/KCj45/9wD/1IdMr+Sj4NfBrxR+0L8UtD8FeC9FvPEPijxHdLZ6fYWwG+eQ5
JJZiFRFUMzu5CIiszMqqSN8LUlCrGUVd9u5lWhGcHGWx9p/si6Yn7Kv/AATr+J/iz46eFNQ+IPws
1Dx+ngOz+Fd5cz6TcWfiy2hiu7jVHuSvm6bLBZq1s3kK0k5mMUypGik/Stj8I/HXjf4I/tkeO7L4
RS/Ejwz8T7LwJqvgLw5b+Hr6LTrvRfOjlsdMVNLNu/2nTtMlsBLFaSkRmIF5JEJMv5Y+Iv2XPHHh
b4K3nxGutItn8D2PiuXwS+s2up2l3ay6tHB9oe3iaKVvOUQ4fzow0RDJhzuXPbeFP+CbHxh8YeDN
S8RQaD4fsdC0ew0zVL6+1bxdo2lQ2lpqUMMtjcO11dR7YpxPGquePMEkRIkikRe6liJcqpqm3b72
/e8teumys9NWc1SguZzUrP8A4bz02Wv/AAD9HdZu7T9mn/gnD8RfB/xr+GFh4A8EfEr9p670XxZo
+mawGbwXp1/oun6nA1k9ikkTNYbLOZAsUiSJG0JhXdgeTftZeA/EPir/AIOXdRvotPtYrXwR4s8P
+KtdvRff6Do+j2Ftp1xPqN1cyCNYI1gQO+4/K7iJXkcqX+LP2gP+Ce3xh/Za8I6xr3jzwbLoOkaD
4mj8HX10dRs7lItWksE1FbYeTK5c/ZJY5S6AoA6gsGO2ob/9gb4tab+0L4i+E8vhMj4j+F7B9Svf
D66nZveSxJbpclLZVlIu5vIkWQQW5klKhyEOx9u7xtSajSdNtRkrd95e7fl7t2SSWj07ONJX5ubd
W/LXf+rr55P7Z/xG0v4w/th/Fjxdol0t7o3inxlq+r2FwsTxC4t7i9mljcJIFddyOpwwDDOCAeK8
0or1j4IfsSfEP9oj4Y+IPGfhe08LyeGfClxFbazfan4u0jR10tpWjSFplvLqJo45HkVEkYBHcOqs
WRwvkWnVm2ldvXQ6/dhHskfUP/BND9mPx98f/wDgmN+1dpnhHwdruvXfi6/8HaLojw2zLb317FrC
STxJO2It0MVxDJLuYCKKVZHKrgn6R/bruPD/AO0Z4T+NvxR/Z68H+Efi18Tv+Fy2GhXV1p3hy28c
XC+HbbwxbxCVbG5tZ0htDqEFwFvY4gtw2V82VY0J/NP4z/sFfF39nj4faz4p8a+Cr7w7oXh/xe/g
O+uLq5t90WspaLeG3EayGR1Ns6SrMimF0dCsjbhm5+0F/wAE7vjJ+yv4J1TxH4+8GS+H9G0XxLH4
PvLh9Ss7jydVk06LUkttsUrsxNnPFLvUFBvClg2Vr0IVqlOlyezem71/v26aPV/d5M5ZRUpcymtd
vw89b6ff5n6p/Eb9n79kz9nrSfiR4g8cfDn4dJ8OPEHx5k8Ba5rEZ1C+l0C2h8K22qm3sVs2EtlI
mr745FtiMLPNbunlxR+Wz442ugfEH/gnT4Bj079mnR/HUep/EDQfiFrfw0+Hj3+mtqNrqXgOKIXw
t7RHnsbVL5XRJE3RzSWkoLM5mJ/LnTv+CbPxju/A9t4ou/DWlaB4VvobCa013xB4n0rRNKvDe2gv
LeGG7vLmKGW4NsVlaBHMsSspkRMjOb4Q/YE+Lfjf9p3VPgzZeEXh+J+kNKs+gahqVnp9xIYwGYQt
cSok5MbCVfKZ98WZF3RgsOp42pUdoUN5PZa3d/d2s7dFbo9O2cqEZNtz/rTz09f+HOt/4KgWD6B8
cPBOi3ejRaJrHh/4X+DdO1aBg6Xhu00GyMgu43AaKdNyxFDyqQx5wcge7f8ABKv4X+Htc/4J1ftP
al8UJ/F/hb4Raxq/grS9V8S6VpZuRGItbje5jiLDa8kaXFuzhBK8SzxyeTLlY5Pkf4Yfsf8Aj34x
az4xtfD9jodza+AAG8QaxceJNMstD04NcC2jLanPcJZN5szBYtkzecMtHvUEjpvCP/BNT44eNfjd
4s+HVp4Cvbbxb4HuLez1y21K+tNNt7Ca5njgtIzdXEsduz3MksYtwkjG4DhovMU5rzoOo6zrKm2m
3pr1vp5+e19djV8kafs+dK39XP0c+Jn7MFjZeBPjLfW3wd8LeGfjVpPxji0u98P/AA5+G+mfEmXS
vDR0G3m0xk0m7MUVtaTsZZnvVhgeadzG8SbTFDxnxH+DNhp/wt/bS8X+DPgPpWi2Hwt8SaJqPhFL
7wfpGujw/qjJDF4htXmiF3bTww28jyyWDyzW9iZEkENvIoK/AHhb9hT4n+LvhV4/8ZwaFptlonws
uZbLxYmqeINO0zUdBnQhfLnsbmeO6VnkPlRgRHzZleKPfIjIPIq6auPvGzp21bvfX7Xlum+lk7ba
KxTpacvMna36ef59z7q+BXxO0b4p/sa/tVfE5vhn8JdC1/wTrHh3xF4YtrHwhZ3Nhod3qV4bG9jS
O8WdpbSSBWK2c7S20EjeZDFE4Vl+0f2ov2L/AIV/DKz+ObfC34eiPxzp3xhsLSax8LfDTTfiVqOm
6HdeG7O+iVdHv5VisLGS+mvWS4iVAzBbdd0cYEX4+yfs2+NYv2a4vi+2iEfDqfxM/g5NX+1QYOqp
apdtbeTv84fuHV95TYc4DbgQPT9G/wCCVfxt1r4YReMxoXhKw8NPpVjrkl7qfjzQNOFnY3237HcX
CXF6j28c5cLGZVTe4dBlkYCaGJnypezctb/+lXtZaXv0/l8tFVordSt/S/y/E+wP2RNF8L6F/wAH
PGn2XgnwZB4L0CPVtUCeGzc2V0mkzt4fuTdQ5sri5tk23BmPlRSssP8Aq9sZjMafnp8IPDWo+DP2
n/C+j6xp/h3SdX0nxRaWd9Y+OIGg0mznju0SSLVI2AZLZWBWdWAIQSAjIrsv2iv+Ccfxm/ZO8E6p
4j+IHg3+wNG0bxPH4NvLj+1rG68nVX06HU0ttsEzsc2dxDL5igx/Pt3bwVGl/wAOuvjba/DnSvGO
peGNF8O+Edds9PvdO1zX/Fmj6Lpt8t9bvc20UVxd3UUT3DQIZWtwxmjRkaREEiFlVrVJtQVNpqcp
W9baWt05fz00HTcI+/zq1kvu679br/M8z/aS/wCTivH3/Ilf8jHqP/Inf8i7/wAfUn/IN/6cv+eP
/TLZX3h+yjbzeP8A/ggrdeGvC/wr0347eLdN+Psup3/hNIdVvbzTLGXw7BHBqMkGlXMF0kRlhnhS
SRvJZvNGC6gr8tRf8EvfjWh8eC/8NaF4ff4Yaiml+KU17xfo2jPo0sgQwPIt3dxkwT+YnkzqDDPn
9074OOc+Mf7Bvxc/Z9+HOreLfGngq/8ADugaJ4sbwPeXF3cQBo9XFmt6IBGHMjo1rJHMsyKYXSRC
sjBhnCMK1ObquDtr09e6t3+4qfJOHJGS6fp59T9NPhXN8Dv2Pf8AgodrvwC+C0PxG03x7qfxf04T
654bsIPEX2vwxFb6fd3Hht7o3iTWltFqEd6bqRInlWC1VLg3Gx0X4x/4KB6f8JvhR/wUA+OekeNf
A3xe1zV28e6pfx3MHiOz8Lr9muJBOii1m06+Z13ySPHciZVngeBxDEWIr5o+LHwO8UfA5/Di+KNM
XTG8W6DaeJtKAuobg3On3QZoJj5TtsLhSdj7XHGVGRW/+zV+x98Rv2vdb1Cw+H3h3+2pNK+zLeTz
39rp1pbvc3CW1tE1xdSRQiaeeRY4ot++ViQisQcdFbGynD6vGnZ8zaW+99LNdLkRocnvylpbXzfe
9z7V/wCCd3hDxRq37A/7XviL4N/DHxZqWn6rL4U0/wAOabq+hQeN/t9xBfrJe25VrBbW8kiinWdl
+y5hSWFyAwSU+ifBX9nX4d3P/BzD4k+H/hDwD4M8Q/CyJruPWNEl0S31vR9NZdHWW4GyRZktBHq2
I8oV8l28gbVJiPwD8N/2APip8UvBnjLX9P0TRdO074d6iNK8Uf294n0rQbjw/cmRYlS6gvrmGWEN
K3lKzoFaRXQEujqutp//AATH+NF3L44S78N6HoDfDa+j0/xMNf8AFuj6J/Y8kuzyHl+2XUX7mfzE
8mcZinz+7d8HGmHrVYxg1SbtJPbR25m0tNLp677bE1KUZc3v2umvS6Wr16dPXzPoP/gjH8RfEnw8
8SftCfDCbRdBh8STfC3xYNK0TUfCVhc69qOuxRW2NNxNbPd3SgWzs2nOzQkxSs0JIfPyvr/7OHjP
xH+2fH8LtcTwvovj3xH4og0S6itZ7M6Vpt/eXCJsP9nCSCFI5JtrxQKfJ2NH5ashjGx4O/4JwfGr
x18a/FHw8sfA1zD4r8GXVvZazb6hqFpp1tZT3EyQWsX2q4lS3d7mSRBbhJGNwGDReYvNZ2g/Bj4z
/s2+BX+Mul2fizwDZeG/Ftx4EbXbW/OlalpeuLaNJcWOxXS6ikFuziT5QoDFGOTtPPKUnTjSqQla
Lf3dVa2673+RqlFTlKLV2l/kvvOG+M/ws1D4GfGHxX4J1eayudV8HazeaHey2cjSW0s9tO8MjRsy
qWQshKkqCRjgdK+1f+Canw9luf8Aglh+2BrmueB/HXijwbdjwzBIugv9ge9+xXz3d2Ib17a5jVrW
N7e4mHkybYGLN5YZZB4X4r/4JW/HP4far4ltfE3hPSPCcXhHVbXQ9Sv/ABB4s0fSNMTULiyF9FaR
XtzdR21xP9lZJWjhkdo1kj3hd65qWf8AwTK+M0z+O1u/DuhaGfhlfppvij+3PF2jaP8A2PLJs8lp
PtV1HmGbzE8mdcxT5/dO+DiKdCtGo5Rpu2qtZ+a7dNfu1KlKE4W5l0f/AAd/uPuj9pr9sfw5+2f/
AMEg/Ffxc+J3gjVGtPFv7S8vk6N4U8Rw6TNZmHwjY29uZLi4srvzQsEBDYjTzJZHceWo8s+5/tbf
DPxFrXxL/wCCh2oaT8LNQ+KVvrn/AAruw0vRm0zVJrPxFcQW+nz3USNYyxXMktvFPBcOkUu5VeNp
PkbD/kf+0F/wT3+MP7LPhPVdd8eeDZtB0jRPEcXhK9ujqFpcpDqsmnx6ilr+5lcs32SaOQlcqu8K
SHytb2if8EtvjVrvw8HiwaD4XsPDo0fT/EEt9qnjjQtNjtLC/IFlcT/aLxDCs7HanmBSzAqBuBA7
frdaSdOrTbd7vvf37307t6Pblat25pYan8cZWX4fZt18vxIv2iP2YfFuq/8ABSXWvhjqHg/R/hT4
p8ZeM4rW08NtexXOn+GRqs6S2lv51orI0EUV1CN0SH5BwgI2Dyj43fCfUfgJ8Z/F/gXWJrK51fwX
rV5oV9NZuz20s9rO8EjRsyqxQshKllUkEZAPFeu/Eb9jf9ob/gnjNc+PtT0vX/hxdeFPEi+EW1zS
fEECXNhqk+lpffZo5rScvl7C5RmZDs2ylC24la2rL/gjZ+0XffEufwb/AMIPpNv4qh1KXR49LuvG
GiW1ze3cVha6jNFbLJeKbkxWd7azSGDeI1mXcVOQOGrRnJtKnLmcvz2Wy10fRbbG8asYpOU1a3f0
19NV1e6+fY/8G9Mvkf8ABYH4Qvtdwv8AbOQoycf2Jf8Abv8AhzXV/sHfCz7N+yX470g/BnxRN8Tv
D/j6O11XxFpnw50f4k6xp9olnKj6TdeHdSnjl01EuEeT7csWJX8yB2UwBT8afGX4F+IfgLrWm2Pi
H+wnfV7EalZT6Pr9hrdncwGaWDetxZTTQkiWCVCu/cChyBxXH04Yj2cY05x1i297bpLtpa17hKgp
yc090l9zb/U/YLwz+zn49+F3w8/4KFL8PPAvhPxReweIfC+k6NZ+DPBTaz4Y1G8i1ATX1tb6bei7
Tz7aK4SS4s8TLZSyYUxrHCa+PP8Agpl+zj4U13/gsn4x+Fnwht/Deh6NrvivTtB023tZz/Zmnahd
RWsdzH+73+VHHeyzhokXEO1o1RQgQfIFbXw7+JPiL4Q+MbPxF4T1/WvC/iDTt/2XU9IvpbK8tt6N
G+yWJlddyO6nBGVZgeCaupjKU48jhZc19+l5aLTs/wAETTw8oS5ua+lvy3+7t1Ze+N3wn1H4CfGf
xf4F1iayudX8F61eaFfTWbs9tLPazvBI0bMqsULISpZVJBGQDxX1/wD8E1/h9H8Rf2Av2jtTtdE+
GF54x+G1/wCGtV8J6j4s07QUhsJ7+6lsrwT3WpgQyQNbKQsF0zwJMVkjVLjY5+GK9L+F/wC1548+
DfwT8Z/Dvw/f6LbeEfiCip4gtLnw7pt7LqIQDywbieB508phvi2OvlSZkTa5LVy0akI1OZ3trtvt
obVISlDlW+n56n6nfDn9n/4B63+1v8T/AIgfCyz8A+OPhw3xY0rQtV8NppuhyaJ4U0ODSzfarr89
3qlldiDS2uFv4kW0e0SQQbYZmH2ZUj/Zx/ZZ0n9nr4h65Y/Dj4ZaTN8QPCv7XFnouoxXvh4+INY8
N+A8CawuQl3FPJZWbEtImoxGOWTCkzNtjI/GqivRjmkE1J09U29HbfotHb7/AJHM8Fo482jSWvlb
X8PxP2q+FXwTufDfx/8AGeqeGvAWl6x8aF/bESPxRcXnhZdb1fRPB0zfarXUAlzBL/Z9nJJJNMt/
CsTvhG80rHHjzDxf+zr4o0HwF/wUD8c3/wAJoNQ8QfDX4lx634R1TWvAtpqQgNzf3B1Js3NtILy3
XSri3uTDKJLeGOeK7CxuYpj+UlFKWaXhycvVvfvfy6Xv8uhf1aV9WtUuna3nt5HTfGX4jQ/F34oa
14mg8M+GfBya1cG6bR/DtvLb6XZuQN4gikkkaJGbc/lhtiFyqKiBUX9AP2IbjSvHf/BG2z8Ot8LN
Y+P8nhT4/TeIdf8Ah9oN3fwai+n3HhZ7W3vJXs0eWCAXUeRIq4ZoCjHDCvzZorgo4hwqe0av93X5
NfhY2q0lOHJt/X3n7K/ta/BL4dal+xt8M7P48eGrT4a+FfDGk/D3Qbrx5pmlQS+NIdf/ALJhGo+H
7qFYpJhawaUy3bLcGCWCXYyx3geK3HH/ALEvwL8eaf8A8HJ91PcfCnQPBdp4M1C9/tCw8E2Hm+Gf
DtrPoFyunSGWKNY41uY/Jk3ukLySSufLjkJjX8mqK7KeYxhOM1D4ZKW/Zt2bt56frpbm+qPkcebd
W28ku/lt/wAG/wCoP7NXws1XQv8AgkxH4A8U/BDxd8VvEvgr9oCXXPE/wqtl1LTfEMVjdeExFZ3l
zHbxtdWtsZirJJ5YEpjKbsEV9M/tSaJYa7/wS/8AgH4GvPhFr3xt8R/DjWPDVz45+FukXU9r4gsV
fwQttFLeJYxyXdlGJhFhp0SR2gaM/J5e38JaKmGYKMYxUdvTs1rprv1uvLVlSwrcnJvf/gefl6+e
h+7X7SmkaVr/APwS0+BXgi6+EGtfG/xL8Ntd8Nz+OPhZo89xaa9Yq/gf7NHNdrYq95ZoLgR8zwo7
PbMhLRtHh37U/hfTNc/4JY/AXwXL8J9X+N3iX4fa34buPHvwv0S5mtfEen7vAyWsMt4likl5Zosy
xjdcRK7NbeXkpsC/hHRVf2lrdR6t9Ho76O61366abasX1TW9+luvl5+Xr5n7rftQ+F4NT/4JXfAj
wDP8K9a+N2v/AA91vw7eeOPhdo8s1p4i0xpPBAghmvEsRJeWkazNGAZ4Vdntmj3bGQK39pjR7LW/
+CXHwI8DXHwZ1b40eI/h1rvh+58c/C/SJJrTxDZb/A0dtDcXq2Cte2kfn+UR9oiV2e1ZNxjKY/Cu
imsz/udW+nXm301366abasr6tLrL8H5efl018z6u/wCCuNjHoHxT+EWiT2M2leIfDvwd8IaX4gsb
iGKG7sb+LTkDwzxqBIkqxmIFZx5q4AwECAeJfCbxJ8K9G0CePx14M+IPiPVGuC0FxoPjOz0W3jh2
qAjRTaXdsz7g53iRQQyjYCCW8+orz5VV7SU4K123rZ769jaFK0FBvb5H1j/wT8s9Wf8Aam1vxz8M
pl+HPwm8JacJPHN/46u49f0i10KYJDdWOpLFBbLqQvH3RxWUcKyzO0aphozOngH7Q2ueCPEvxv8A
FGofDbQtY8M+BLvUJJdE0vVL0Xl1Z25Pyo8gHTqVUtIyKVRpZmUyvxtFXOu5UlTt1b/4bsvTf5Kz
jTtLm+X9dz9K/wBiOHT/AIgf8EYtN0D/AIVhqn7QEnhr9oO417XPh34dubyDVnsJ/CxtoLyaSzWS
4htvtKDa4jCs9u6bjuO31H9on4N/C3Vv2T/CWm/HPw4fhd4b8KRfD3Q9R8cWejJJ4zj8RHw/Y/2h
oUkBhab7BFpUkN2xdo/IuA5WO8lb7Kn5B0V0U8bGNNQlBO3p2a10v17+lm2zCWFvNzUrf0vl+B+p
nj79ij4h+N/jn8ZfEHj/AOGuuQ/A/wAAeOwth8GfhNLc3el+J9f/ALPt/skVvDaJttInsHtZbrUn
t4ZDHMY441nkEUXo/wASr3x98XP2NfF+n/GX4Q3Xxh+Kmk/tGHxD4y+F3hK9kS4stOuvBsdvpswf
TTcPFaIwgWOQbvMNt5byM7Ma/GyitFmKTuo63u9U09+jjbrott9NWJ4W/Xt36fP8d/uP1O/aEn+K
eo/AXw98IfDX7PNn8XvD3hDTfCGq+MtD1FNXude0LxRJ4UsrZd1lpl7bXkFstlbxpmSExCdrhWkM
mETuf2Yfgx4V+Bn7bX7cHw6+EXwusfG/hrw98NtetbW5efVdQvJZbq3sf+KYd7e6SMp9pS6iVFT7
ezW8iC4LKxH48UU45mlPnlC+t+l7a6Xt563vsE8K5Jpvf18vPyP0w/ZHuvDnxW/4JJyWtr8HdS+M
kuj/ALQ1z4j134X+FdQ1KOW00mfwzLBZzB4ftF3BbJdb1Erly/2YI8hJLV9BfG/QPD1//wAE5Ph1
4On+Ffj341+K/hz4t8J3XxC+FtrqGoW1/ZLJ8OrW1glZLeJrixiSdUViEwZoJI2ILFV/E2isqWP5
Yxi47Py7Ndn363XlqwnhOablzfn5efl6/cftR8V/Bmg6p/wTn8B+DW+E3xB+NfjLwF4y8LXXxC+F
1le3tvqVmj/Du2tbeYpawNcWUSTqoYlDmaGWNmBJVfzg/wCCmmkL4Y+N3g7Rbm31ix8Q6F8NfCGn
a/Zaksscun30eh2Ya38qRVaIpH5StHziQSZ5JA+dqKnEY11afJa2t/zfa/Xq/lqy6WH5Jczdwooo
rhOkKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKAPu3/g2g/wCU1/wc/wCuHiH/ANR3U6/rLsP+PSP/
AHf6V/Jp/wAG0H/Ka/4Of9cPEP8A6jup1/WXYf8AHpH/ALv9KALkHU0UQdTRQB8cf8HR3/KCj45/
9wD/ANSHTK/nB/4I2+I9MT4p/GTwdPf2Fn4j+K3wh8ReCfCUN5OltFqetXiwfZrPzpGWKN5vLdEM
rqpdkXJZlU/0ff8AB0d/ygo+Of8A3AP/AFIdMr+Sr4L/AAX8VftE/FPRPBPgnRL3xH4p8R3ItdP0
+1UGSZ8FiSSQqIqhneRyEREZ2ZVUkdGFqyp1Yzirvt3voZVoqUGm7H2p+yRprfsrf8E5viX4s+Of
hjUfiF8J7z4gDwLZ/Ci9nudLlsfF9tBBdT6pLcFRJprxWSvbt9mzNcFvJmVIkDH6u8RfBXx74j/Z
+/ao8eaV8Nr74teB/it4d+H+q/D7wwdCvbe2j0c3Pm22iLb6VLG6yabamAslrMPlWCaQ4uCj/k34
o/ZP8d+D/gbdfEu80qwk8CWni+fwI2s2es2V7by6xDbrcyQReTM7Sx+SyuJ4w0DhhtkbNd/oX/BL
H42698Mx4xHh/wAM6b4aGmWOtSX2reNtC0tLexvghs7mVbm8jaKKcyBI3cKHkSSMEyRSKvZRryUF
S9m2vx2l5a9dHfZ2tdmFSlFtz5rfl08/+Dsfo1qV1Y/stf8ABMjx74C+OHw7tPAngr4iftQXekeL
vD9hfebJ4J0zUtB03U7a4sbmxV4ZJLHy7SZY1ikWRYvKaJfMwPL/ANsj4b6z42/4Odrm50+332Pg
nxB4V8V+IdQnuEhtNE0nT9N0q5vL+6uJGRIoYoo2Jd2XLFVXLuqn4f8A2iv+Ccfxm/ZO8E6p4j+I
Hg3+wNG0bxPH4NvLj+1rG68nVX06HU0ttsEzsc2dxDL5igx/Pt3bwVFfVf8Agnv8YNG/aS8QfB+b
we7/ABN8Nae2p3fh2DU7Oe8miW1S7K2wSZhdzfZ5FkEFuZJSofCHY2N3i6riqPsnaMk130c/d0j3
b0tpZ2XbJUouTqe0V3F+m0dd9v0a174X7ZvxC0n4uftg/FfxXoNyl5oXifxjq+radOsLwrPbT3s0
sThHAdAUdTtYBhnBAPFfWn/BND4aTah/wSq/bE1/XvBHjTxP4IlHhiNxoUq2E99JZX73VysF5Ja3
KL9lgkjuJ8RPshKl9gdXHwDRXmRxFqrqtb3/ABT7301+ex2Tp3hyLy/A/WH9pv8Ab2j/AGp/+CRH
ir4v+LPhp4S16TxZ+0vIF8Panc6sNOsY4/CNlb27LNaXNtLJOkNsFYiQITIzGFAYgnqX7RWj3X7a
f/BY/wCLf7IvjTTtX1f4V+KNX03x015o0gtr7wbq8HhqwR9QjmMbxtFcRKli0dyrR7riFkKSDL/l
r+zZ/wAE+fir+1z4J1LxD4A0fw/q+l6RqNvpN6bnxZpGmz2tzcPHHbK8F1dRSgTyypFE+zZLJujQ
s6Mq+R+JfDWo+DPEeoaPrGn3uk6vpNzJZ31jeQNBc2c8bFJIpI2AZHVgVZWAIIIIyK9COY1OROtD
mTkm3tzWcrq9uvNr2OX6tFyahLZWt2+G3Xpb5/I/Q3Uv2jPjJ+1r8MvFHgbWv2d5/GvwO8EeII9F
sfh3oF3NB4p+Gl9b6XPYWjq0fmagzpFGqyz6ja3FvLJatGFjYbE6L/gnf+yjp/7LX/Bx5a/D7wTq
8/j3w38PbvV1k1NER/s8L6NcI0N08YaNXiuLhbORiEBnG3bGzBB+Yden/CT9jr4g/Gv4c3fjHR9K
0qx8H2Wpror69r+v6f4f0qS/aIzfZI7q/ngilnEQ8xoo2Z1RkZgA6kxRx37yE+TmkpKX3O7Sstnv
1t0W5rVorlkm7Jpr/g7n1N8PfBWqfGT/AIImeJPgr4Y0jVdY+Mvw9+Ocvi7XfBkVrKNcs9Jk0eHT
PtEdowEk2y9UxTJCryQ/I0qohVj6T8Vvh/afs8/8EWrnwp8bI9c8d6j4Y/aB/su8tvDHjCGCTTbp
PB2nKtm19La3kLmyRDZyQxRkRyQbRLsRN/55fHD4BeLP2cvGUOg+L9Mj06+u7C21W0kt72C/s9Qs
7iMSQ3NtdW7yQXELqeJInZcqy53KwHHVjDFey91xfMk1q/XdNbq5fs+bVPR/8Dr8j9wf+CgXwP8A
GvxQvv8AgpQ/hnwb4l12PXbv4c6dpp0vSpbr+0rq1SxmureELGWlkiilillWM/IskbPw6E/j1+0x
+zh4n/ZK+NGqeAPGUVlb+JtEgs5b+C1uVuY7Z7i0huhF5i/KzosyqxQsm5W2s64Ywfs8fs8eMf2r
fjFo/gHwDo/9veLde877BYfa4LXz/Jgknk/eTOka4iikb5mGduBkkAt/Z7/Z78YftU/F7SfAfgLR
zr/izXRObGwFzDbGfyYJLiT95M6RjEUUjcsM7cDJIBvF1vrMueMHzSk7a3Wrbta12/eXX5aq2dCm
qMeRyWiX5JX38n/SP05/4Jfftj+D/wBjP/girFqnxJ8F2nxA+Gnif49X+ieJNGuNFj1MywHw5Z3U
LRR3EqWzyrd2to2HztRJDjcYivv37RDePf2l/wBkH4r/ABJm+DMHxFuviZ8Jvhdf2miafYajNpur
3n9oXN1e28K2bxXha2FykjRw3DtFGYDKzJIAPwVoqoZpJUo0WtI+naS7PTXb17ilgouo6q3dvwt6
dj9vvh98adO/4J0/sSePG+N/wh0fTfBviP8AaV1a38R/DSCxsddTRbK+8OWeq2UVsplSwlEMiWAX
5Aqxq+FVzGI9D/gsNqXjX9vX/gkR8IJPDnh9vF3j3WNc8O+NtW8O+ENMn1C8sLfUPDcg+1vBEHkg
tmuUlgj3BgfIwZXYFY/wxoqp5rKVJULe6r9VfXm62/vaaWXbs1hbS509bJfdb/Lv+R+5vxx8R+A/
DfxR/wCCgnjP4l+D7n4h/CE658PtC1aPSr37ILya1FvDeQ21xCVU3dnLLA8sCzIQwWOUoJN6+WTe
HfHP7Wv/AAU4+LH7H/xzuYvHHg3xD4nbx0db8Iw/2MfCV5BpEK2l/CWjmVYpdPWz0+SG789Q8sbL
M0w86b8haK1rZwqsrzhpzczV97uTaemz5rLtrb4mKOEst+lvy1/D8ux7D+3F8ftc+Pnx0lGr+Fv+
ECs/A9lD4O0Xwoyymbwvp9gWiisZpJgJ5Z4zv82SbDtIz/KihY0+nPhZrfg3Sf8Ag30U+O9K8SeI
9GX9oWcW+m6Br0OiXcVw3huD9+801teI8exSuwQI2TnzWHyD4Cr0/wCEf7HXxA+Nnw7vPF+j6ZpF
j4RsdRXR313xB4h07w9pkt8YvO+yRXOoTwRTTrFiRoo2Z0RkZgA6k+dRrS9o5RV27/j5Wt8rG84R
5OWTstPzP2T/AGop/Cnwz+NP/BQvxT8U/A+qeOvhi2o/DSy1WziuprA6jGILXzRDNGUZprdri0nM
aTRgnykbakoZON8TwXPwN8R/8FBtc/ae8ORfFzwxceI/A1tq50CO40Kx1O3MyyW62xQqyz2lpdWD
tB9p3EgJJPIJTcH80NU/4JcfG7w7pM2q6x4X0bQPDiPaR23iLWfFmj6Z4f1Z7q2+1QrY6ncXSWd8
xg+ci2mlKD722jWP+CXHxu8MadLqOteF9G8O+HwbRbXxDrXizR9M0DVzdWwuoBY6ncXSWd8WgIkI
tZpSgI3ba9eeY1pS5lSe8vvfPo9NbX2faX8zOCGGppKMpp2S8tuXXfTbp3XZH6Ef8FLmfwR+xr8X
bX9oAz/ELV4v2kY3CeCtStvDPlrL4StXtCPPt711ijsxFCYTF99M/argqzH3P/gpZ8W/Bnw1+H/x
r8O/EXTYrv4Y/ED476L4W8VG2neDUNBtLjwbot1/aVq0fmSGW3uLGCZUe3aOVYZIgJPNbyfyC1f/
AIJf/Gzw1pNzqmseGNG0Dw9CbRYPEOr+LNH07QNVa6tjdQLY6lPdJZ3zNCC5W1llKgfMFPFGqf8A
BMD41+HbCbUNY8NaHoGgobRbbxBrPi3RtM0DVjdW/wBphFjqVxdJZ3xMPzkW00pQfe2nij+0a8eb
lpPV9df59HprpLW/Z92aOhC9+fp/8jrvpt+J+on/AAWI+DOr/tCeBfi/4Q8JaN4n8US6Z+0F4e1X
XNO8J6D/AG3rmk6dP4HsoxeGzilWUx5SZYxKIImeNkEzHzPK858FfAXxb8M/hf8A8FAvBJGrftae
IrS/8C2T3N2mqXr+J7m3uGe6t5Vsrprp5bLzVV1ju98TWoDAx70HwDqn/BMD41+HbCbUNY8NaHoG
gobRbbxBrPi3RtM0DVjdW/2mEWOpXF0lnfEw/ORbTSlB97aeKXV/+CXnxs8M2U1/rXhjRfD2hL9j
+za/rXi3R9M0HVjdW32qAWOpXF0lnfFoPnItppSo+9tqK+MqVajqTpO7b79ebTa11fqunTUUaKUV
BzWiX4cuu9+n4o/Sv4PftAaV/wAE3/2YPioPjZ8FvD9p4O8XftBXVv4o+HEen6XrZ0CwvNBTVtPg
gUTpbyLHKlls8yNIlSGXywZNyw+k/tE+JvFn7Uv7HXxa8byfCS0+I+vfED4Q/CrW4/DNha6zNZav
dSarqk92sUVm0Vx+4M5k2x3LMixozNIrSKv5C65/wTK+NPhPTJNS1vwxpPh/Qf8AQ/s2vax4o0nT
tD1X7XbfarcWWoz3KWl6Wg+ci2lkKD7208VD8QP+CbPxk+F/wi8R+PNZ8MabF4T8KR6dcajf2/iX
SrwLb6gIvsN1EkNy8lxbTmULHPCrxM8VwgfdbzrG5Y2v7P2fsnyq+68pX15baJvotnpZsU8JBy9p
GVm7d9bW8+tl+B+h1zd6Z+zB+xf8XvBnxu8A6P4C8GfE79olNF8YeFtLv7Z7zwBpOo6VDq1pc2dz
p5k8wWhjtZUia2aB1tHiVC0kgh6PQ/Dd34h/4O572TSYL27tNGtRPc3UELSJZRDwdHAs0pUYVPOk
iTLYUtIi/wAQB/IL4L/BfxV+0T8U9E8E+CdEvfEfinxHci10/T7VQZJnwWJJJCoiqGd5HIRERnZl
VSR6BpX/AAT5+K+ov4ua40HR9BsvA3iKXwjrGpeIPE2laJpkOrxeZ5lhFeXlzFb3E6CJ2ZIZHITa
x+VlJinmVVxgo07qM01/265O2i/vfLV210dTDxvLmnZuNvLVJXs35d/I5T4QeGtR8GftP+F9H1jT
/Duk6vpPii0s76x8cQNBpNnPHdokkWqRsAyWysCs6sAQgkBGRVf9pL/k4rx9/wAiV/yMeo/8id/y
Lv8Ax9Sf8g3/AKcv+eP/AEy2V6Pqv/BMn4zeHBcz6x4e0Dw/pUCWMkOtaz4v0bTNE1Nb23a5tjZa
jcXaWl7vhVn/ANGlk2hTuwRimX3/AATO+M2i6fcahqvhvRdA0KE2Qh13WfFekaZoepG8ga4thZ6j
cXSWl5viRn/0aWTaFbdtwa810qvJy8j37Pft66P7mdnPG/NdbfmeDUV7xff8E0fjHoqXc+q6B4f0
HSbZbJota1nxfo2maJqQvIHntzZajcXaWl7viR2/0aWTAU5xilu/+CZ/xl0m1ubzVPDuh6Bo0C2L
xa5rXi3R9L0TUheQPcW32PULm6jtLzfFHI3+jSyYCNuwQRUfVa2r5Hpps9ynVgt2jwaivftX/wCC
YXxq8NRXFzrPhvQ/D2jwx2MsGua14u0bTND1Rb2B7i1NlqNxdJaXokijkb/RpZMCNt2CCK82+O/7
PHjH9mjxja6F400f+yr3UNNttYsJIruC9s9TsbhN8F1a3Vu8kFxA4yBJE7ruV1zuVgJlQqRV5RaX
oKNWEnaMk/mcVRW7oPwu8TeKfA+v+J9M8O67qPhvwo1smt6ta2Es1jo5uXZLcXMyqUhMroypvI3l
SFyQa6j4O/sqeNPjn4U1PX9Dt/D9poOj3cOn3Op6/wCJdM8P2X2mVJJI4Emv7iCOWUpFI2yNmYKu
SACCYjCUmlFXbLcklds86or3fV/+Cafxi8M3VyNZ0Hw/4fsYINPuYtX1jxfo2m6NqUV9BLPaSWeo
T3aWl4skUMzA28sgHlODgqRT9V/4Jm/GTw7LdtrGgeH/AA/p1rBp9zHrGs+MNF0zRdRiv4ZZ7N7P
ULi7S0vVlihmYG2lkx5UgOCpA0eGrL7D+5ke2p/zLvv0PBaK901f/gm58YPDVzcjWNB0Hw/YwRaf
cRatrHi3R9N0fUYr+KWa0ks7+e6S1vEljgmYNbyyAeU+SCpFJrf/AATf+L/haa7Os6BoWgWFtDYX
Meq6v4s0fTtI1KK+hlmtJLO/nuktb1JY4JmDW0sgHlOCQVIqvqlf+R/cxqpB7NHhlFe63/8AwTY+
MOhyXL6t4f0Lw/p0EOn3EWr614t0fS9H1CK/hmns3tL+4uktbtZY7edgbeWQfuXBwVIqTVP+CZ/x
k8Oz3h1fQPD2gafaQadcpq+s+MNF0zRtRiv4ZZ7N7PULi7S0vFljgmYG2lkx5MgOCrAJ4Wst4P7m
J1qa05l954NRXu+s/wDBNX4xeF57o6zoGg6Bp9vFp08er6v4u0bTtG1GPUIZZ7N7TUJ7pLS8WWOC
Zg1vLIB5MgOCpAk+JP8AwTH+Nvwl+D/iPx9rnhCzh8IeFI9NuNR1K28Q6ZexrbaiI/sF3EsFw7T2
twZCkdxCHhd4bhA5e3mWNPDVkruD+5gq1N2tJa+Z4JRXovwg/ZT8a/HHwfqniLRLXQbTw9o17Bpt
1quu+I9N0CxF1OkjxW6T388MckpSGR9iMzBULEAc11cn/BOT4xabrXiyx1rwvY+EH8EatFoWsT+K
vEGmeHbOG+lieaK3juL+4hhnd4UMyiF33RFJBlHVjMaNSS5oxbXoN1IJ2bR4fRXvuq/8ExfjR4dj
urjWPDmg+H9It0sJItb1nxfo2maHqS3tu9zamy1G4u0tL3zIY3f/AEaWTARt2CCKNU/4Jh/Grw7b
3F3rPhrRfDujQpZPBrut+LNH0vQ9UW8gee2NlqNxdJaXokijkcfZpZcBGzjBq3hqy3g/uYvbU/5l
954FRXvupf8ABMP41aBaXN7q/hrRfD+iQfYvJ17WvFmj6XoWp/bLdrm2+xajcXSWl7vhVn/0aWTA
U5xUWp/8E0fjL4f0y41LV/Dej6BoUX2PyNd1jxVpGm6Jqn2uA3EAstQuLpLW9LQguRbSyFQDu20f
Va38j7bPcaqRezPB6K9/1P8A4Je/Gzw9p1xqOseF9H8PaBEbNYPEGteK9H0vQdVN3bm5txY6lcXS
Wd6XgBkxbSy7VHzYrzP46fs++Lv2bPGcGg+MtJXTL+90+21eykhvIL6z1GyuYxJBdW1zbvJBcQup
4kidlyrLncrAROjUiryi1026gqkG7Jq5xlFdN8Gvg14p/aF+KGi+C/BWh3/iPxR4huBbWGn2abpJ
3wWYknCoiqrO7sQiIjMxVVJHo3gv/gnp8UfHvwsv/HNlZ+DbfwXp3iW58Hya7qXjrQtM06XVYIY5
5LaGe5vI45j5UqSK8RZJF3FGYKxBGjUkrxi38u2v5DlOK3Z4nRX0DoH/AASw/aB8VftKa18ItM+G
WtX/AI98NrA+r2dvPbyWukie1+1wm4vRJ9lh8yHld8o3N8gy/wAtc98Kv2EPiV8Y/gafiXpOn+Gb
LwGNdl8MjWtd8X6PoNs2pR28Vy9qpvrqEtJ5M0bgAEMN2Cdj7a+r1b8vK76rZ7rf7uvYn21O1+Zd
Ovfb7+h4/RX0B4s/4Jd/G74fav4ktfEvhXSvC0XhPUbbR9R1DXfFOkaXpa31xZLfRWkV7cXSW1xO
bV0mMUMjuiuhYLuGad1/wTX+NGjX3iiLXPCNt4Rg8Ha4PDWqX3inXtN8P6cmpGEzi1iu764ht7iQ
wATAQyPmKSKQfJIjM3hqy3g+2z37fgHtqe/MvvPC6K+gb3/gl38bdD8Ma5rWt+GdE8KaV4c8Sy+E
L+58S+LdG0KOLVI7aO7+zqby6i8zdbyxyxvHujlRt0bOAceYfH/4AeLv2XPi5q/gTx3pI0PxXoXk
i/sftUF19nMsMc6AyQu8ZJjkQkBjgnBwQQFUw9WCvOLXTVP+uhSnFuyepxtFFFYlBRRRQAUUUUAF
Fdl8Hf2f/F/x+Pin/hEdGfWP+EK8PXfivWttxFD9h0y12faLg+Yy7gm9PlTLnPCmuNpuLte2grq9
goor0Hwn+y3418c/s9eKvilpOn6ZeeC/BN1BZ65cLrdit5pzzyRRws9kZhdmOR5lVZBEY2KygMfK
k2Ci3okDaW559RRRSGFFFdn+z3+z34v/AGqfjBo/gLwHpI13xZr5mFhYm7gtPPMUMk8g8yd0jXEc
Tn5mGcYGSQDUYylJRirtilJJXexxlFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKAPu3/g2g/5TX/Bz/rh4h/9R3U6/rLsP+PSP/d/pX8m
n/BtB/ymv+Dn/XDxD/6jup1/WXYf8ekf+7/SgC5B1NFEHU0UAfHH/B0d/wAoKPjn/wBwD/1IdMr+
b3/gjp4o062+Kvxh8IT3lhba/wDFX4ReJPBPheG7uFtk1LWLyKL7LaLK5WJJJmjZEMrKrOyqDvZA
f6Qv+Do7/lBR8c/+4B/6kOmV/IFW2HrOlUVRdPy6/eiKkOeLi+p97fsgQQfsxf8ABPD4m+Kvjj4c
u/iL8LJvH0Pgm1+E91dTaZc2PiqKKK6n1SS4wJtLeOzge2ZrdWluSzQyhEiDV9ZeMfAPibxv8DP2
rPE+h+HT8afCnj3w78OdR8A+ChpN7FHpekSXH2u28Pm10uVDDPptnc20jQ2s4LRzQ3Dki4dW/Fei
umGNUYqm46L0vtLrbz63W9rXZhPDXm53/rT/AC/HyR+yd3rmn/sw/wDBNn4n+CfjP8PLPwR4J+Jn
7TE2j+LPDuk6xbynwXpmoaLZarbS2M9ikgZ7JorKZVMckUqQGERKzSBfNP2xPhxrvjf/AIOaNSvt
Mtl1Oz8D+IvDXi/xFfTzxQ2Oi6Vp9hplzeXd1PIUihghjQgs7KC2xB87qp/Oz4L/ALPHjH9oX/hL
P+EP0f8Atf8A4Qfw5eeLdb/0uC3+xaXabPtFx+9dd+zzE+RNznPyqcGuKraWYz9nGEo6KV0+ujlp
e1vtdtNdNbERw655SUle1n80vO/T5/I9K/bN+Iml/F79sH4r+LNEvP7R0XxR4x1fV7C68p4ftNvc
Xs0scmx1Vl3I6naygjOCAeK81rqPgv8ABzxB+0F8U9E8FeFbeyvPEniO5FnpttdalbafHdTkEpEJ
rmSOIO5G1FLgu7KihmZVPQ+Hv2Q/iJ4s+OPif4aab4eN7498INqEeo6HFfWzXby2BcXUNuvmf6XM
nlyERW5kdwjFFYAmuGUalWXOo/E+i6vov8jqTivcT2X4H13/AMExP2afH/x8/wCCWP7XOkeD/DWu
63eeM9R8FaHosMFsywarew6v506LM2Is28MsckpZgIYpxI5RDur6O/b01fQv2ldJ+N/xO/Z28JeH
/jR8U5vjDp2g3uoWvhSx8bz/APCO2/he2hV47G4t7hYbY6jb3IW8ihVJyAomkVFx+NtFdUMdGFJU
lH1d+3Na2mnxeeyZzywrc3Nv009L31128j9vvjL8A/2RP2eZvibrPi74f+BU+HGvfHSbwXrOspDe
Xh0i2h8KW2qiz0/7DJ5tjKms74plt1Tal08DqEiCQ6v7UWg+BPG3/BMj4Pt4b/Z9tviNfeJfF+jf
E3xr8MPh752mJCNS8IPaQzpDYrLcWNt9oijdGMeyRkZd7u8rV+FlFbzzZS0jTildvRLrfTazSvom
nt2dkPCp2u+i/C2vzsfXn/BYQNpvjr4EaJdSPFrPhn4JeE9J1fTJxsvNDvI7aQyWlzGfnilAZX2O
AwWVOACK9b/4Izfs3eGNf+Fb/EXVtN0bx4F+IVjoPiLw/f23hxrTwtoEFjPf3evahPqlpdyQ2Xlp
NEQgsxI0RVLmSUKkX50UVxwxUY4n2/Lpe9r/AK/npr2NZUr0vZp9LH6T/wDBOv4K/wDDOX/BygPB
GlaJe6BY+G/FHiu00awvRKskVh/ZmpmyYGXLujWxhdHYnzFZW3ENury//ghB4d1LwR/wWQ+HWk6v
p95pWr6Q/iC0vbG9t2huLOePRdRSSKWJwGR1ZSrKwBBBBFfFFFbUsfGE6clD4Jue/fl02/u7+exm
8O2pKT3ilt667+e34n3z+zb8C9Y8Of8ABMbxXqXw/wDhTB4t/aI0L4wf2B4n0++8D2nizVND0JNJ
do0k027guDZr9uS5V5vs8Zd4xGZD5ZRfor9uX9m3wR4D8NfHK8/Zi+FvhbxZ8RdH+Ndnpd/p2l+F
bLxp/Y2iv4bjuZYk0+eK6SxiGrC/VisUQDxtBwLfyo/x8opUsbCFPkcfnfXZ7ab67+SHLDtz57/1
p5+X4s9/+If7L/xI/aD/AG/Ne+GehfDjwfoHxM1HULmOXwf4U1O2GlWF1BbNPdQwyvdywxlRFMzR
CfbG4eJVTasS+X/s+nb8e/BB/wCKQ41+w/5GsZ0D/j4j/wCQh/05/wDPb/pnvrkKK5JVVzc8Vrdv
/LZL59+yNoprRnZftFnP7Qfjs58GtnxDqHPhEbfDx/0mT/kHDAxZf88eB+62VxtFFZzlzSbKSsrB
X6P/ALD3hyz+IX/BHhbGH4SeIPj6/hv48nU/EHgjw/PNFevZXHhe4t7O6lksYnvIIluldld/3TtA
6LgmU1+cFFa4et7KfPa/3fqmvvRFWDlFxTt/w9z92P2u/D9t4h/4Jh/s/wDhW++FniX43a/8LW8L
W/jv4X6Vc3UGraKsnhK8jtHvfskL3lkRcSGQJNhSYgiou+Rnh/aq8NW3iv8A4JofATwrdfCnxB8d
vEnwyk8K2vjn4aaNJcWusaQH8JX8dqLwWcL39m0c5LlZQEfyVVVG6Rm/C2ivUecaaQ/J6a6O8dd+
t1ptqzD6s7b6/Py8/L8uyP3P/ak0TTPEH/BL39n7wxefCfX/AI4658M7jwxD47+G2izT2ur6UJfC
l8lqb1rSJ72xdZ33hZVCP5AUKpMjPN+1J4TsvFX/AATQ+AnhWb4R+KPjprfwsk8KQeO/hjol1c22
raOZvCd/HCbxbSB76ycXGHIl+RvJVFQbpGb8KqKU82Td1Dq+z3v/AHdd+t1vpqy50G7tPp5+Xn5f
1ZH7pftR+DIvEX/BNj4C+E7n4TeIvjxqvwtbwonjn4aaHdXNtrOkNceE79IRepZwPeWLJPtf97w/
kqgRMyM6/tV+HYvFH/BOD4B+Drn4S+J/jtq3wvHhNPHnwy0O7u4dW0dpfCd9Fbm+Fpbvd2LrMQ+2
UkHyAgjjDM0v4WUUpZsm7uHft1vv7uu/XTy1d4+ry6y6W6+Wu/8AXyR+5/7UWkQ+Mf8AgnR8C/CN
z8H/ABT8c9b+Fsfg6Hxz8MtHur6DUtJL+FNUhgN6lnA11YyCcq5EjDcIY0EabneVnjLTvHFj/wAE
/PiTovgvwmfE3jzQPgx8HNEuvDk/hiLxHd2uoRXWoyXFpPps6TIZY4JllaKW3Z4g8D4jOxj+GdFH
9qU1flp2366q9+tr9fTfTVieE7Pt3e1ul/I/ZzR/EvwU+A//AAVk8bfCX4O2PjTwp418RfFnQHN5
4E0Oz1nT20a2trW51LRQ32iK502D+0ftcl4bcvGkNqsRhEcBSqXxu+HNre+G/j5oEfwp+Jfx+tvD
n7Ul34j174e2sd9pt2bS/wBD1EW94RZxTzQW73JJiufNb7XFbRExQbiG/HCipeaq1lBL3m/k76Wt
Z2v1VulhLBtKzlfRL7ra336fi9T9z/2sPCP/AAk3/BPL4E+Eb34W+LPjrq/wxt/Ba+N/hdoV1e2+
p6OZfCmpxQG9jtLeS40+VZijEyEtKIkTyol+eaP9qzS7fxV/wTx+Bfgib4U+M/jnrXwwtvBieOPh
hpF3fw32jSy+FdXiha7S0ge4sZhNsc7m3OtvHG8UQAeb8NKKt5vf7H5ee/u6ryd15asFhH1l09O3
n5evnsfuV+1L4WsvEn/BPz4HeDrj4PeMPjjrvwttPBS+Ofhno17qVvqekNP4W1eOI3kdrbyS2Eon
MUhLNvkEMcbwxKoeaf8Aam8MWXiT/gnd8C/B03wj8WfHbWfhZD4J/wCE6+GOiX+oQ6jpDTeFtXjj
+2R2sDz6fL5+1nyd8gghRo4lCPL+F1FTLNb/AGfxT773Wu+zut9NWL6nLrN/j5efl6+Z+5f7V3hW
DX/+CePwN8H3fwv8afHbX/hdZ+CU8c/DDSb3Ube80U3HhfWI7Y3cNpA81jOs5RmZm8yRYYY3jjTy
3l+PP+CnviD4VeC7/wCAXhb4i+BPiDqfjfwl8F/DGl6xb6N4ys9BfR5RbtILO8tJ9MvJY7tPMZ23
yITHNCPKTbuk/Peis6+Ze0g4qPW+tn38td9Oi6Jal08M07ylf8Pyf9fI+tf+Ceei6xcftQ634/8A
hw3/AArv4O+D7Nf+E71Xx0y+I9EsNFuE8uew1MRW9tHqBvWSWOCySKOWaTYIyrxG4T6C+DFt8Ovj
R+xr49Pww+B/xR+LXgDRfj3BrB+F9truoz3tlo9z4e1OCyuJGs7eQ22bhGJkEkzuttFBI7eWJ5/z
IorCjjHTsrdW+nVW2s1bytZ6X2Rc6HNdp9Evud/X8T9z/wBrDwXa+IP+CefwI8KT/Cvxn8efEPww
tPBSeO/hhpN/qMN/onm+F9WS3+2Q2kDTafJ57BmbPmyrbxRyJGiQPLB+1b4Zh8S/sAfA7wbd/Czx
18ePEfwwsPBS+Ofhho97qdvcaIJvC2rx2xu4bSBnsLlZ2DMxPmypbwpIkaCJpfw3orseb33gn62f
f+7rv1ut9NWZRwsl9rp29PPy/qx+5X7VPhS113/gnh8CPBkvwp8bfHXxJ8M7Twf/AMLA+F+k3Wp2
97ofm+GNWjs2uorSF3sJhO7OxOJpVggSWNIxCzv/AGpdI07xR/wTt+CHg+7+Fnjb47eJfhhF4Ji8
e/C7R7zVLa70RZPCurQWrXKWsEjWFx9obc5z5sot4EljjQRGT8MqKcs3Tv7m/p5/3dfndeWrH9Vb
3f6dU+/l6+Z+6H7UWjaX4w/4Jy/A3wdP8LfH/wAePFPwtTwdH4++Fek3mq21zoaSeFNUhtnuY7WF
zYXH2jLOcedIlrbpKqp5Zdv7VHgay13/AIJx/AvwrL8LfG3x08S/DSLwfH49+FWk6hqcN7oYm8K6
olrLdw2kTvYTfaGZ2JAlkW2gSVQhiJ/DGip/tZa2h18n3/u679dN9NWH1WSvaWmnfpbz029fM/df
9qvwrZa//wAE2/gN4Puvhf40+O/iX4ZJ4PXx78J9FutTt7zQo5fCmpx2kt0lpE76fcG4kZn3IJZF
tbdJBsEZaLx14f8AHum/8E/PiTpXhbwMniLx74Z+Cnwf0GfRLjwhba/d2eowXV9Nc2dxp1xDPmeK
1nSaSOSEtGrQSMIz5Rr8LaKTzOLveHfZpPW/Xlv1+/1d5eDbd2+3Ttbz621733P2c/bM+C3g7Svh
B+0F4W+B3wxPxoj0j47aTLdfDCwGsaho3g5H8Ls0upQW+kXEMlvNLfnULWVTKYk+wxQ+VGYUA6v9
uvRvCvxOPxlttJ8KeO/2rLjwx8f7C78ReB9B1K8Mdnp0ngk2lq6vpsDJbGG+jntncIZnGkwxXDOy
l2/Diil/aa1tC123bS32tLW1+Lrf01YlgpJ35uluv93z/u+up+7X7U+h6T4s/wCCZHwD8H3Pwu8Z
fHbxb8NG8Ir46+FOi6jqkN7o9tJ4S1GK0muYraJ5LC4+1SSM58sPIltapJ+7MNL+1n4Ws/E//BND
4CeEL34a+Mvjr4p+GTeD4/HPwl0O9v7e/wBFgfwjfx2s13FaxyTWE/2mRt5ZA8i2sCvhDFj8JKKf
9px6Q6t9Ot97x132enlqx/U2ndS/D089Numvmfup+05pNh4l/wCCafwH8Hah8KfEvxx8T/DC68Jw
+OPhLod/qUGoabA/hG/S1nu47SN5NPuPtLyGT5PMkW0t1kIUxqLP7Vfh3TfEf/BMr4B+Db34S+KP
jj4r+F934TXxv8K9Dv8AUYNT0u2fwdcpBLexWkTTadMbuR95KeZKtrArnbsC/hFRQ80Td+Xv1Xno
/d1Svs9NPNg8E27839aeem2618z90P2o/DcHi7/gmf8AAjwne/CbxB8b/Efwvm8KxeMPhdoOp6jD
qmmQTeDrpLa4vre0ieXT5vtbsWJXfKtrAshCsip+cf8AwV4tb/w/8RPgr4d1bT7bSdZ8KfBnwppW
oWBuN1/Y3C2jSPFfQlEa1uVMuPJfcwj8liRv2r8l0Vlisw9tT9mo21vuvPR6Jvfvput2bU6Moyvf
T0/4Nvwv5n11/wAEd9csJPit8XvB8mq2Wm+Ivil8JfEXgvwrBdzJbxaxrF5HCLax86RliiebY6o0
rKpcogO51Bp/8Ey/2f8ASdQ+PfxXvfH/AIU/tLVPgb8P/EHjWHwvr1o62dzq+liMJaanbExyNAkj
MZINylmiCOCpdG+UaK5oYhRUFy/C7+u3+Xp5b3uVNvm13Vj9Dv8Agh14g+Jv7Uv/AAWb8MfFfXoP
FHjO6iudRm8TeIVtGkt9Oe40bUIbdZZFXybZSE8uGI7EAiEcahVCjyz/AIJ2/spQ6d+0H8Vx8VfB
N9DrvwU+GmtfEC18KeJ9Omt4LvULKCGa0h1C1fy5WtmWZZTHlRIBGG3Rsyt8iUVrHGpRgnG7jJyu
3ve3+Xn53IdB8zcXa6S27X/z7fM/S/4Y/EX4hftj/wDBKrx1r+oeHtS/aa+IOt/HSHVdX8J3C6hf
PokbaC0aasLXSXt7qBJdn2RC0rWoSzWOOGIxAt6n/wAFFrzxh8f/AIhftBfDaD4a+Mv2gfAWjfFj
Tdf/ALQ8A+KbL+39B1f/AIR2KyltLi0hs7tzZJHD9nSU2sTLLYvHNczzKwX8faK0jmLVJU7a3u3p
r8XdP+Z73/FkPC+9zRaXbR6fD2a7H6w/tHeDvBHxv/4Li/tUeL9ftND8bW3wb8AXnjHT9MuJFutG
1bWNH0jT4Etr9EZTJCtwHEtuHXMkXlPld6t+Ynxl+Mvij9oT4oa1408aa1eeIfE/iG4Nzf39yRvl
bAVVCqAqRoiqiRoFSNEVFVVUAczRWGJxTrOTta8nL7/8tfvNKNBU0vJJfd/mfdP/AATV8Bx/Eb9g
D9o6+s/DnwwvvGnw41Hw1rPhTWPFthocVvpkt7cz2V6k93qai3lhktgAlvdu0KygSRItxtY/Wnwl
/Zl+BmvftXfE34k/DSy+Hvjz4Zj4s6d4d1Xw5aW2hT6R4T0K30v7fqviK6n1Sxufs+ltOt5GgtDa
RSGB47e4YC32/lf8Lv2wfH3wa+B3jT4ceHtR0a28HfEMIPENlceHtOvZNS2D91unngeZfKbLxFHX
ypCZI9jktXmVbU8bGEIR5b21f/k3XXvr6JW0MKmFnOU23a+i69F/lpbu3uz9KfH/AMHvhr+zv4F+
OHgrRvDfwj8N/Enw78br631DTviQ6mWD4ei0ka0W1+2/6S6MWZxLpDtqkqNEyHJt2f6d/ax/ZQ+H
nhO4+Ns3w++Guk2nxA074n6Rpsmm+CPhRpPxD1TSdCbwlYXEQbQ7sw29jazXcly5vIY1aSdZImLh
QV/In4RftlfEL4I/Da+8GaNqmk33g7UNTTWpNB8QeH9O8Q6XFfrEYftkVtqEE8UNwYj5bSxqruio
rEhVA5f40fGjxV+0T8U9b8beNtbvfEfinxHcm61DULpgZJnwFAAACoiqFRI0ARERUVVVQBssfRVO
yhre/ay97S+/Va2WwSw05S1a2tfXy6fLzP1F8a/DbwXfeJvjxF8Nv2dNS8Lapp/xKtllvPD3hHwx
8WtT0K1OkqZ9Im0CS+kj0yEXouJxd25aMSNJZkobQRL8C/8ABS74ax/B/wDbv+J3hqNPh9H/AGVr
DRyR+CY5YdEhkMaNIkUMkspt5FdmWW2WRkgmEsSYSNQPDKK5a+LjUg4qNne9/v0tZLr+CNaOHcJX
vfS35dfl/XX7y/4IhfGXxDpN38cfAug2XhTUNU1r4T+KLjQtPn8MaXf6tr2pm3titjE8sDXN7GY4
Gf8As/dJC/lyOYG+c12fg/8AZp8W+AP2DfiFeeGfhf4C8a/tQad8bDpPirTtG8M6N45uNG0R9INw
sa6ZFBdWNjbC+aZPMto0xLG9uxX7OI1/NqilDFJU4wafut9e67W07r8gnh7yclZXt07d9T6X/wCC
xXgbwN8NP+Cl/wAWtD+HNjoOmeEtP1WJLez0afzbG0nNrC13FHjiPbdGdTCuEhYNEoCoAPcf+CVn
gL4iSf8ABNX9rTW/BHgTUPFmpalJ4W07Q4ZPB8fiO01S6g1LzLuCO1ngmguJYbadJXTy3aJZEkwv
ytX570VKxC9s6tt76LS177elyvY/ulTvtbfXbv6n7U/tBfssfCTwvY/HWT4L+CNI1Hxto3xjg0i9
tPBnw90/4oahpWmHw/bTSQjR74rBYWn9qnUVM8OwrNGbbbsiRY/zT/4KkaT4X0H9v/4nWfg/wenw
/wBDttUWMeHVuLSYaRciCL7XD/olxc28eLnzj5MUzLDnywsezy18CorTE4xVYcqilq3p6v7t7adE
r3siaNBwd276W/L/ACP0Z/4Iv/s6+GNY+GbfEbWNO8PeP7b/AIWFYaD4n8PX9p4feDwjoEFpJfXO
vajPqtldGCxZFmhAhezaR7d0E5kMQXR/4J1fBiz/AGdf+DllPBMGj3vhfRPDnizxVa6VY3TTRyW+
nf2bqTWRDynzGR7cwskjMfMR1bcwbJ/NWiroY+NNUvd1hJO999b220/rQmphXNzfNbmVv+Dv0Lvi
Xw1qPgzxHqGj6xp97pOr6TcyWd9Y3kDQXNnPGxSSKSNgGR1YFWVgCCCCMiqVFFeczrCiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD7t/4NoP+
U1/wc/64eIf/AFHdTr+suw/49I/93+lfyaf8G0H/ACmv+Dn/AFw8Q/8AqO6nX9Zdh/x6R/7v9KAL
kHU0UQdTRQB8cf8AB0d/ygo+Of8A3AP/AFIdMr+e79kj4XXuof8ABKfV/FHwp+G/hf4hfG3/AIWz
HpOoxjwxbeNdZtPD39jtNEW0q5tbmO1tjdiTbdoitK6vGzYhUV/Qj/wdHf8AKCj45/8AcA/9SHTK
/ko+DXwa8U/tC/FDRfBfgrQ7/wAR+KPENwLaw0+zTdJO+CzEk4VEVVZ3diEREZmKqpI2w8mqisrv
bTfXt5mdWKcGmfrB+3D+zT4V+HGhfHK7/Zk+Fvw+8X+PtN+NFlo95pui+HLPxzdaLpT+HIZ7mIaZ
c291HY2w1d7qNZYY0/epNbnYtvHGOZ/Yt/Zksofi3438d+Ofh78I11EfFSx8PeMvAGgS+HbzQfh5
pdvZSahqerXkmow6ktpYECWIR213a/vobmBJEeKKKP8AN7xB+y9438M/Be/+IlzpNtJ4I07xU/gm
XWbTU7S7tn1ZIDcGCIxSsZV8lS4mjDRMCuHO4Z9K0v8A4JT/ABw1P4ZxeMm8PeF9O8MSaRp2vNqO
qeONB06K2sdQz9hnm+0XiGFZyGWPzApZ45EA3IwHqRxMpVlONJ6Nuy2+10s9u/8Ad1Xbl9hFQcZS
6JX+7fX+rn2L+x8uq/sw/tzftmfA3w14b0HR4Y/CXjuLwXoOpeFrO+1rV5D5T6fYwy3UL3t/DLZw
xypaPJLDMuZfKfczNT+AX7J114W/ZG+Jj6r4J0DUfj1pnxfbSfE0Hgn4f6F8UNZ0jT20vz/I/sXz
Bp+nWS3TzqLi1KsJ4ntmVRBtT4h/aD/4J/fF39lfw7q+rePPCJ0LTdC8QQeFr24/tOzukj1KfT01
GOBfJmffm0ljlLplF3qrMGO2lvP+Cfnxdsv2j9e+EJ8JCf4leHNPfU7rw/barZXF1PElol4VtvLm
Zbub7O4kEFuZJWAbCEowE+2qRtF0n7remv2r2W2jutLdU9A9mrX5lqlr3tbXfa36an6keD/gx4T0
T9oK9174KfB3wvo3i2w/aX0DStc0pLTTfFeteD9DGmW0160tvbm9tdJtk1D7U6XNnIrJIJoSYTZJ
GvyDN8HfFb/8HBniqX+xb+1Twb8XbvxzrdzqCfYoNJ0O21f+0JdTuJJCiRW32UpKJSyq6yR7CTIg
b4QorOeYxkopw0UubRpdW7aLTtfy2NI4Zp3v0tt/wfw89z0z9tT4h6P8XP2yPi14s8O3T33h/wAT
+M9Y1bTLlo3ja4tZ76aWJysgDqWR1OGAYZ5ANeZ13/7NP7MPjX9r74qW/gn4faZZa14pvYJLi2sJ
9Ws9Oe6WMbnWJrqWNZHC5bYpL7VdsbVYjjfEugT+FPEeoaXdSWUtzptzJazPZ3kN7bO6MVYxzws8
UqEg7ZI2ZGGCrEEGuCpzybqtaNv0vvb8TePKvcT2KVFdr+zx+zx4x/at+MWj+AfAOj/294t17zvs
Fh9rgtfP8mCSeT95M6RriKKRvmYZ24GSQDF8IPgJ4t+PL+Jl8J6SdWbwd4fu/FOsAXMMP2PTbQKb
if8AeOu/YHU7E3Oc8KcGoUJNJpb6L17fivvHzRu1fY4+iiipKCiiigAoorpfg98I9d+PPxM0fwf4
YgsrvxD4gn+y6fb3Wo22nx3MxBKxCa4kjiDuRtRSwLuyooZ2VTUYuTUYq7Ym7as5qivTPAP7HfxH
+J/7UE/wZ0Tw79r+JVrqF/pcujtf2sHl3Nksz3UZnkkWD92tvMc+ZtOz5ScjPmdOVOUVeSt0+a3X
yuJSTdkwor0Xwb+yh48+IP7OXjH4s6NpFpf+BPh/d2tl4hvk1azE+lSXUiR23mWhlFzsld9qOIij
FJcMfKk2+dUnFq11uNST2CiivQ/g3+y14w+O/hfWNc0KPw1baLoN3a6fe6hrvijS9AtY7i5S4kgh
WS/uIFkdktbhtqFiBGScZGSMJSfLFXYOSSuzzyivedS/4JpfGHQbnUBq2ieGdAstPg0y6Gqaz4z0
TTNJ1CHUYZ57KSzvri7S2vUljtrghraSQDyJAcFSA3U/+Cavxg8P3d+uraL4Z0GzsINMuRqeseM9
E03Sb+HUoLiexltL6e7S2vEmjtbkhraSRQYJFJDKRWv1at/I/uf9dH9xl9YpfzL70eEUV7re/wDB
Nr4vaNe6jHqujeGdBtdNt9Mu/wC0tZ8Z6Jpel30GpRXE1jLZ3txdpbXkcyWlyVa2kkH+jyAkFSAz
Uf8AgnF8XNBur1dV0bw3oVnZxadOup6v4x0XTtK1CLUIp5bOWzvp7tLa8jlS2uCHtpJFHkuGIKkU
/qlf+R/c/P8Ayf3MpVqb2kvvPDaK90v/APgm98W9E1PUrfVdJ8K6FDpltpl4dQ1jxtoem6XfQalD
PPYy2l7PeJbXiTR21wVa2kkA8iQEgqQH6n/wTX+L/h++vo9X0XwzoFrY22m3i6nrPjTRNM0nUINR
hmmspbO+uLtLa9SWO3nIa2kkA8mQHBUgJ4ast4P7mL29P+ZfeeEUV7vqn/BNX4weHru+XV9E8N6D
Z2UGmXK6prHjLRdN0m/h1GCeeyltL6e7S1vEmjtbghreWQAwSAkMpFJ8Rf8Agml8afhR8JvEnjrX
PCNrb+EvCcOm3Wo6lBr+m3cX2bUSgsLqEQ3Dtc21wzlY54A8TtDcKHJt5hGfVa1r8jt6Ppv+T+4a
rU3opL7zwmiuo+C/wc8QftBfFPRPBXhW3srzxJ4juRZ6bbXWpW2nx3U5BKRCa5kjiDuRtRS4Luyo
oZmVTraH+y94+8UftIP8ItL8NXmp/EWPWp/D7aNZyRzuLyGR45k8xGMWyMxuWl3+WqIzlggLVEaU
5JOKbu7fPt6lOcU7XOBor2v4Qf8ABOf43fH341+Jfh74O+HOva/4o8G6nLo+vpbCP7Fol3GbgGK5
vWYWsJY2twqF5QJWiYIWOAeX+Df7LfjD47+G9Y1rQovDlroug3NtZXuo694n0zw/Zx3FwkzwwrNf
3ECSSMlvOwRCzbY2JAHNP2FT+V/d23+4XtYd1p+ux55RXuus/wDBNr4weGLq9XWNC8P6DZWVvp12
uq6t4v0bT9I1CHUIJp7KSzv57pLW8WaO2uCptpZB+5kBwVIBqv8AwTZ+L/h29u01fQ/Dug2drDp9
wmq6x4w0XTdH1CK/gkuLR7TUJ7tLS8WWKGVgbeWQDy3BwVIqvqtb+R/cxKtTe0l954VRXu+q/wDB
NX4xeHWvpNY0DQdA06yg0+5TV9Y8XaNpuj6jFfwyz2j2V/PdJa3qyxwTsptpZf8AUuDgqQPO/jr+
z34v/Zr8ZW+g+M9JGl319p1tq9lJDdwX1nqVlcxiSC6trq3eSC4hdTxJE7LlWXO5WAmVCrFXlFpL
yHGpCTsmmcZRW7oPwu8TeKfA+v8AifTPDuu6j4b8KNbJrerWthLNY6Obl2S3FzMqlITK6MqbyN5U
hckGuo+EH7KfjX44+D9U8RaJa6DaeHtGvYNNutV13xHpugWIup0keK3Se/nhjklKQyPsRmYKhYgD
mojCUmklqynJJXbPOqK951f/AIJofGTw2LibWPD+gaBpUMdjLDrWr+L9G07RdTS9iea2ay1Ce7S0
vQ8ccjZtpZNvlvu2lSA7Uf8AgmR8Z9Ct7m71bw5ofh/RoFsnh1zWvFujaXoeqC8hkntjZajcXSWl
6Hjilb/RpZMCNs4INavC1lvB/cyPaw35l954JRXvuq/8ExfjR4djurjWPDmg+H9It0sJItb1nxfo
2maHqS3tu9zamy1G4u0tL3zIY3f/AEaWTARt2CCKXW/+CYPxr8K2Vzfa14Z0Xw9ocCWUkGu6x4s0
fTdD1UXlu1zbfYdRnuktL7fCjvi1llICndggik8PVTs4vts9xe2p/wAy+88Bor33Vf8AgmJ8avDt
nPfax4Y0fw/ocZs1g1/WvFekaZoOqG7t2urf7FqVxdJZ3u+BWf8A0aWTAHOKNT/4Ji/Gnw9a3F5r
HhrRPD2ixfYzBruteLdH0vQtV+125ubf7DqNxdJaXu+EF/8ARpZdoHzYp/Vq38j+5le1h3Xc8Cor
3/U/+CX3xr8P6dcajq/hnRNA0CI2aweINY8W6Npugao13bm5gWy1O4uks70tCC5FtNIVAO7aar/E
X/gmh8aPhT8J/EvjnW/C2mw+FfCMOnXWpX9t4l0q9C22oeT9hu4khuXe4tbgzKsdxCrwu8c6B90E
wjTw9Vbxf3Ppv91n9wvbU725l9/f/h0eEUV2XwN/Z+8XftIeL7rQ/Bukf2pe6fpt1rF9JLdQ2dpp
tlbRmSe6ubmd0gt4UUcySuq7mVc7mUH0S9/4JpfGrQb7xPFr3g+DwfB4P1weGtTvvFWu6d4e05dS
MP2hbWG7vriG3uJDb7ZgIJHzFJFIPkljZlGhUklJRdn5DdSCdmzwmivWtO/YW+LGoftBeIvha3g2
9sPG3hC2ur7XbPUriDT4NGtLaLzpbu5up5EtobYRlXWd5BE4kiKO3mJuXTP2E/i1qf7QPiT4XHwX
f2PjXwda3V/r1nqNxBYW+i2lvEJZbu5up3S2htRGUZZ3kETiWLY7eYm5/V6v8r3ts9+3r5CdWC+0
tr79O/oeSUV7rd/8E1fjVocvin+3fB8Pg628G6yPDuqX3irXNO8O2C6iYftC2kN1fTww3MptyswW
B5CYpIpB8kiMzLr/AIJt/GfRp/Eo1zwhD4QtvCOur4Z1O/8AFOt6f4e09NTaHzxaRXV9PDBPIYNs
2IXf91JHJ9yRGY+rVf5XvbZ79vXRj9pDujw2ivcrn/gnD8XdNt7671DQ/D+j6PYz2Vt/beqeLtG0
/RLyW8s1vbeO21Ca6S0una1dJSsEshRHUsFyK81+MXwc8QfAbx5P4a8TW9lb6rBbWt5/oWpW2pW0
0Fzbx3MEsVxbSSQyo8Msbho3YYbrkECZ0akFeUWle23Xt66ManFuyZy9FFFZlBRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3b/wAG0H/Ka/4Of9cPEP8A6jup1/WX
Yf8AHpH/ALv9K/k0/wCDaD/lNf8ABz/rh4h/9R3U6/rLsP8Aj0j/AN3+lAFyDqaKIOpooA+OP+Do
7/lBR8c/+4B/6kOmV/N1/wAEeNesW+LXxb8HSajY2PiD4qfCXxH4K8Lw3dxHbR6rrF5FF9lshNKR
FE8zRlFMjopYqgbc6g/0i/8AB0d/ygo+Of8A3AP/AFIdMr+Sj4NfBrxT+0L8UNF8F+CtDv8AxH4o
8Q3AtrDT7NN0k74LMSThURVVnd2IRERmYqqkjWhJqrFxV3daLr5fMiqk4NN20PsH9kDSbP8AZU/Y
e+Kfi/43+C7rx78Ob7xva+BV+GV5K+lXS+JrWJrqS/lu8fadMe1tvNgPkoXnNy8UgVEY19p+OPAv
jLxb+y9+1N4ltvB958YPDPxV8O/DfXfhj4N/s7ULe107QWvb17fRUsdKkjCyadDIrFLWbaARK+Tc
SofyE8R/sweNPC3we1Lx/c2GmzeDtK8VP4KuNUstasb2L+1VgafykEMztJE0SMyXCBoHCnbIxr02
0/4JP/HWf4SQ+PJ/C/h/TPCM2k6brp1LVPGeh6dHb2Oo5FhcTCe8RoUuCsixmQLvaKVRlo3C+nha
8ox9nGk2vnfaSvttrezTWj7tnPOlBy5+bX/hn+P36rWyR9xXi6b+zF+x58X/AAx8afhho/gLwj8T
P2hU0HxVoul3Fr9t8H6Xe6WmqwNa3tgX87+zyLOaKH7KYMLNGEJuHSLlv20PAOo+N/8Ag5lvrvQY
g2l+C/EPhjxRrOoS3SW9pomlafp2l3F3e3FxMyxwwxRxsd7sASUVcs6Kfhj4/fsH/FT9l7StdvPH
PhqDRYfDOv2/hfVAusWN3LZahPYi/hiaOCZ32vbEusgBjJV13b0ZQ68/YJ+LNl+0Rrnwmbwm0nxI
8PWDajc+H4dSs5ryeNbZLopbBJSLuYwSLIILcySsA2EO1sbVcZWcI0ZUnaMl67ztF2S1d3bRaqVl
roKkub2nN0t5bLXfy+5mV+2j4/0j4sfti/FjxToF6dS0HxL4y1jVdNuykiG6tp76aWKTbIquNyOp
w6qwzyAcivNKK62P4HeJpvgVN8SksbZ/Bttr0fhma8XULYzRX8lu9zHE1t5nnqrRRyFZTH5bGN1D
llIHizlKpNztq7s6VaKSPq//AIN1/DF34i/4K6/DGWDT7m+tNLt9Yur944GljtITpN3EJJSAQiGW
WJAzYG+RF6sAbn7HngqDwZ/wTJ/az1vxH4J8Mr8Qfgd4j8LTaFN4h8JWV1f6Leahd3em6ja3KXVu
5mQwxAC1ut6QyxGWONJg0g8D8H/8E6/jB47+JnhHwdpvha0bxL498LReM/D1jca9p1q2r6VKHZJ4
mlnVWcrHI3k584LG5KAKxEHwv/YF+Jvxk8GeMfEnh6x8KXXhz4falHpPiLVp/Gei2dhpU8rmOAvP
NdpH5UzhlimVjFMUYRu+1sd1KVaNONNQejnbfdxV+m8bJ/5bnPOCc3Pm0aX4N/nex+g/ww/ZF8F6
F/wc1a38M9F+HvhnWfhmIjeavos+g2+raVZRS6FDevIEnR0to/7QkiCsmwJ5qwphH8tvDP8Agjj8
QvFnwz8afHn4Y/2HoMHiuT4Z+LIdM0PVPB9hda9f64sMCHTMT2zXdzxbvnTnLwkpKWhJMhPg3hT/
AIJd/G7xl8XtV+H1r4V0q28eaNqc2kz+HNR8U6Rp2rTTxQC4YwWtxdJLcRGBllWaFXidCGV2HNcz
8Zf2IPiN8BvhhY+NPEOn+Hn8K6lcw2lrqej+KtJ1uCeSY3Yj2myuZvlZrC9QP93fayrncpFa1K9R
yVaNJxSnKWmna8b26Wt5X2IjCLXLKad4pfnrv1uXZf2O/ip8V/20tR+Elp4e0K++K+oaldLPo2ka
jpMFlHdJFJdTwxyW8q2MPlqsgMMbqsbIYgqsuweMV7/p3/BLf48ap8avFPw+i8BSr4m8Evp0OtpN
q1hDY2E2oeX9gga9ecWpnuvNQQwrKZJTuCKxRgOW8MfsSfE7xZ8NPiF4ug8Nx2eh/Ci6Fj4vfU9U
s9NudAuCXVIJra4ljnErvHJGiBC0kkbxoGdSo4p4ebbShK93v5dNlqtb/kjohJd1sv632fQ+lv8A
gnt4QtfE/wDwSu/ao8SW/gnwt4m8c/CXUfDXiHwneXfhCy1e7sI7mS7ttXeQywSfaLVLJFkaG4Ek
MDJ9oRI5FMtej/8ABK74d6R+0DqfjP4vah8LPA1z4fvfiHomn+IND0+10BfDvgzSPseo32papdLr
FrqE9jYhLfI8uWzjkPmQwys8ccdv+ZldDafCvXr74U6h43iskfwxperW2h3V2LmLdDeXMNxPDGYt
3mEPHa3B3hdg8sgsCQDpQxfI4Lluo627vXXbSyeu+3yWdSjdTu/i/DZd/wDLc/TT4Z/Af4Afsl+M
vjzYfGX4feG4/hv/AMLvfwTN/bL3Nzq/hvQ0sdW1DTZLNbdv7UthcSQWai6y0d3CZF+fy5GX3yx/
Z9tLbW/gD8Y/hN8EfBtl4o+Ieq/C/W/GMHh/wrZalZeHbO6i1SW7ubbT5Ip5tHgYwW/+mxmNXNqC
komjuGP5cab/AMEo/jrqPw/HiyTwrommeGBoGk+KJNV1Xxfoum2dtp2qtKmnTyy3F2ixfaHglVEk
KvuQgqDxXC/Hn9jH4lfsyap4psvHHhv+wrrwXqmn6LrMZ1C1uDZ3d9aS3trH+6lfeJLeGR9yblXa
AxVioPowxsqMEnh9L3Ts0+r3t0SdvK/y5vYU5v47u3f0Wqv/AFofd37KfwOm8bf8HKHxF8LeMvAF
l4g8Pal4u8WX2vabr/h6G/todOkN1dW12wuYWEMbu1m8dwoQus0YV9s2G8t/YE/Zu1dv2bPifLJ8
MvHN/wCMNH8b6bol5daR8MtB+I2paAIbXUTPY3Wh380V5p3mSlT9r2NFK1o8OUeBg/hR/wCCa3xe
tfCOna/qOj+FdA0TV9J0nXLK+13xtoekQXVpqi3bWLI91eRhnkWxuiYx+8jERMioGXKaf/wTT+NF
3q3xGs7rwnZaE/wkv7TTPF0uveIdM0W20Se7aQWvmT3dxFEyT+U5jkRmSQbSrEMpPMp1Lq1J/FJ9
eqWm3Tlbv67WNVBWsprZL7nvv5n6GeEPg98PPAXg/wD4KKeBviD4h8MeFPA9v4w+HsOt3nwz0y5l
0uxtjq87TG3tZZ5RbSJI6rNDunNpIblII5VhEL/F/wC2F4V1f4d/8Fg9R0vWvAvwZ+Hd5p3jLSxF
4dby28DWtr/ozWr3RRUVrKa3MU1w3lxFhNMTFCSYk8T+Ln7JPxG+A0ni1PGHha98Py+BtdtfDetx
3UkSyWd9cw3FxboFDEyJLDazSJLGGiZArByJELZ3xo/Z48Y/s9f8In/wmGj/ANkf8Jx4cs/Fuif6
XBcfbdLu9/2e4/dO2zf5b/I+1xj5lGRWdXEuUOX2drO/4y0enRuy873vpYo00mrzvdfotd/K/wA1
84/2h2D/ALQHjkhfByA+Ib8hfCWf+EfH+kycafnn7H/zx/6Z7K+yf2A/BN146/4Jw635nwV1T4+a
Bofxi0u+1Xwl4cujFq13E/h7WIUe4ewgfUbe2SZoXjklJgkdZkhCP9pLfKn7Nf7GnxL/AGvL7U4f
h94Xm1yPRpLOC/vJby30+xtJrycW9nA9zcyRwrNcTHZFEX8yVlYIrbWxc+E/7C/xR+M+jePtR0nw
7bWGn/C24trTxbdeINZsfD8Ph+e4llhhhuHv5oAkjywSxhM7t6bSASAcaDqKr7WMG736Xv8Ag07b
7PzNqyjKDg3bb8/VH6w/tX/De98SfsT/AAZ0S5+C2pfG5vhzofw/sPGfgLQrt4fEunXn/CM68BFq
EdnbNqVgkTT2kq/aGMUjb0iSJzctJZ/ax8A3PiL9hn4IaDc/BfWPjlN8ONH8BWXjXwBod29v4g02
5HhnXAkGox2cD6nYpE9xbyoZiIXLSpGkbm4eT8rtH/4JsfGfVdZ+JFlN4StNFb4Q3dnZeL7jXdf0
3RrPRJLx3S033N3cRQuk5jYxvG7JIpVlJV1Jf4L/AOCZPx08ffGDxj4EsPh9fw+JPAF5a6f4gj1C
9tNOtNNubqdYLOBru4ljtmkupHUW6JIxuQd0QkUE16MsZV0vR6229VbWOr8ndXT93VnJ7GK3qLRf
5ef9aan6k/tNeCNT8R/sPfBfQ9V+Cd98cl+GumeA7Dxj8PNCvZrfxLYXA8M66qR6jHZQPqNgkbXF
tKnnnypHMiRxxt9oaW3+1T4JufEn7BvwM0DUPgnqPx0l+GWm+BrHxr8PdEvp4PEmnTnwxrSpFfx2
cL6hp8cbzW0qmbEcj+YiIhE7yfjDrXwI8Y+GfB+va9qnh3U9K03wxr0XhfVWvo/s0tjqciXEgtHi
fEnmqtrPvAX92VUPtLoG9K8Q/wDBNT4w+C/FPi/R/EGheHfDF34EvbDTdbfXfGGi6Va2t1e2kl5b
W6XFxdpDNK9vE7lIndkC4YKSASOPqyu40r38r99NnfZ73WjslqN4WN783TzXbz/LXbXRH6n/ALVX
gG48SfsKfBHw/ffBXWPjlJ8MdK8CWXjDwDoWpTQ+I9PuJPDGtjydRhtIH1DT1hkltJozN+6kLSRo
iMJ2eT9q/wACy+If2APgR4WvPg5q/wAcrj4ZWHgmDxl8PtBvLi38SaZcSeGdYHk6hFZwve6ekUkt
rKhmXZKzSIiownaT8rNJ/wCCaPxq1LXPiVYXHhG00OT4P3lnYeMJ9f1/TdEtNDlu2kW08y4vLiKF
knMT+W6OySAoVYiRC3N/HP8AYo+J/wCzYPEjeNfCs+ix+EtWsNC1SX7ZbXENvfX1lJfW0CvFI6yM
1tG0jeWWEfyhyjOoLnjK1vaSpOyur29dHeOvW6d1o9FqKOHWyqdF+nn18tdVrsfrv+1h4CbX/wDg
n38CPDNz8F7/AOOOofDLT/Btt418A6Dd3Vv4k02eXwxq4jh1KK0ie+sUhllgmjMg2SM8yBIz5hkv
+K9G+INj/wAE6fiXonhfwjqniT4haB8GPhDoD+G7nwgniBre+tb2/lu7K4064hmjNzBbXcEzQyQl
40nSXC/K5/K3Sf8AglX8c9V8DyeJ38KaPpnhuHw9o3iubVtW8WaPpdjb6bq73CabPJNc3UaRmd7W
dVjYiQFAGVSy54/4+/sPfFP9l648TR+O/CVxoP8Awh+r2Gg6tIby2uIre+vbJ762gWSKR1lZraNp
D5ZYRgqHKs6g1Ux9blblSa312tdS6239dNG0ldiVKEvd509vPqvPv+a1Z+st7+zZ4S+H/wC2J40n
+A/w18C602kftH+EtL1efQ9KtvEl94Y0c6atxqSraSRTf2PbxagZwLqFoMSxSwqY1swqea/BX4qa
R8Of+CpXxS+GUHh/4h+FPjB43/aAl1Y+INC8PLqN1rnhc3zXg0qXzLiGWy0+Zdt5NdW6yebbEGRZ
YkVT8IaT/wAEsvjnrPx31P4Yp4R0228d6VKkEmkXvifSbOW4ka0W9Mdu010qXLpbSRySLAzmFZE8
wIWAPl3xn+AniT4A6lo9t4jTRT/wkGmjVtOuNJ12w1q0u7bz5rfetxZTTRZE1vOhXfuVozkDilPG
VIJTdFqKk3r8Or1S00aulvpZaGkMOlpz3dl69NfnY/Tf9jD9n3xFaf8ABzn40vtK8NeMrzw94e8Y
+JLrWdRvtAltIdKGo6dqTwNMYy6RwTPIRbSM6faY/LdVjL7F4b9lv4Ta/wCH/wDgmTe+BvFn7PXi
L4qat4L+OcWs+Ivh3aNqOneKHtrrwrcRW015BbRG7tLRJTDLFKV2zs0qZABJ/M+iuP8AtFaWj9qT
6P4raWa6WXr2LWGnZpy3UVt2d779fK1u5+7n7W8f/CSf8E1v2e/h5f8Awb1H47av8MF8KTeMvh5o
2o3lv4j01n8JXkMcN/b2aPd2EUM0lvMruq+a7yxlVAya/wC1PYR+Jv8AgnD8APA+pfBjUPjpq/wx
fwq/jH4c6LqF7aeJ9PL+Eru3WK/t7OJ7qwhimNtMkkigyu8iYVa/CuitP7UVvg79ut/LXe2t1vpq
xRwdlZPpbr5eem3Sz89D92/2stKtPEX/AATQ/Z88EX3wjv8A45658Nbjwo3jP4aaNfXdr4p0/f4P
uYUivobSJruwhim8qVWdMyu0iHaoBPxN/wAFOtX+GPgfX/gd4c+JPhP4ka/418NfBrwpp2q2el+M
LHQD4cdLIn+zri0m0q6mjuVLea/myBsXCjy1AUn8/aKxrZhzx5Yxtr5Pv5a79dOqSbKp4Xlle/S3
Xy8/L/g6I+sP+CfsOqp+1TrXjn4Zyr8OvhR4S00yeNr7x3PH4i0i20OaNYrqw1JYre2TUftrh4ob
NIUklkeNUKvGbhPp34Rah8PPjF/wT816z+G3wG8VfFnwDpX7RE/iA/DOx126m8RQ6VN4altraW5e
yikube1Fz80bkycxtA00rK00n5ZUVGHxzpLl5U9W/v8Awt5Ws+t0kXUw6lfXt36fO5+6/wC1Do9r
qP8AwTB+A3grUfhxrfx+1TwBqvhafxd8KdLvpbPxBoBbwXNaiG6hsYDfWUS3IjnDzqzSSvLHlU2q
Iv2o/B1rrv8AwS7+A3g64+HniP4/a98PNS8Ny+L/AIV6VeS22veHfM8Gy24ju4bKFr2yiS6Ecwad
Szu0ke4JtC/hbRXR/alneMfyffutd9b3T7amawrWqk+n4W8/L+rI/c79qHwfb6//AMEtPgN4Mn8B
eIv2gPEPw91Tw1deLvhbpF1JBrfh2KXwa8CxXMVjC17Zxpcqku64VmaRpI9yoVRE/aZ8O/29/wAE
vPgV4Gu/h54m+Pmr/D3VPDl14v8AhRpV3JBrvhzf4OltUS6jsYDfWUS3ISYGdWZ3aSPcqbFH4ZUU
3mr6xW9+j790779bry1Zo6Mnf3u34W8/L5H7r/tMaRpus/8ABLP4AeDrz4c6/wDtB634A1jw5c+M
fhRpl1Na694bR/BjWkaXIsIGvbOL7XtnBuNzNJvjBCMEWP8Aad0rT9U/4JcfAHwRqPw68TfH3xB4
A1rw5ceL/hNpl29rrXhxG8GvapFcLY25v7JDdBZ/9IDFn3xgouFH4WUVLzNPeHVvp1v5a79bry1Y
vqy11eqXV9Lefl6+Z+6v7T/h+21T/glx8APBV/4H8TftBav8PNY8OXPjH4P6VcTWes+GxJ4NNqi3
S2MDX1kn2oJJm4DM8nmIpRCEXn/FHw5+JPhz9ij4l2/hbw7rvjPxhpfwb+FGhHQL3wla68ulalBc
O13pMmny20geaCGdLl4biOSaE3KSfInkhPxKoqJZhzJJx6t9L683W1+vn5JXE8O73v26drf5f53s
fs/8MvhZ4V+Hf/BSD9ufwf8ACn4R+HPF3h7SvhvrcUUukRandKb660+zMnh4JZXKwRJLeLeJ5MMa
XCNFLHE8ax7E+P8A9nHxJ4u+Pv7Avir4fR/AvxF8QfhTb/FD/hMbfTvhr4jSDWvDGqTac1uYpbea
DUrxtOa3WNIppogDJbuv2iV96j4goqZ42MpJ8tleTsrfa6bPRfO/kKGGsrSd9EuvTrufuH4m1C3+
JX/BVz9u+30DwHo/xINp8LNQs21e2Oo3c97eLounQDQH+x3CQjfPbXCGOONLvzLeVVlXYyj5G/4I
ps/j7UP2lxpHwg0XWvM+FviSeJLSLWrgStOkRt9AHl3mfJm8qXyxn7Y/lttnO01+etFbTzRSqRm4
L3ZSf3u/bdd3fZaaBTwzjT5FLol93U/Sv9nLUW+Kf/BDvW9G8JfCbR/jBr1r+0Dca3c/D60j1m+H
hqwn0CNIb8Rafdx36wl4pbdJLiaSNvLYHdIC1fQHx3/Z++G3wi/Zo8c/Cf4a/D7xB+0X4R+HX7Sk
ural8NtB1ie51K0tLjwdDFvkubCOS6ghh1EzQBpAxLWBhZvMWZj+KlFZUcbCEIxcLtddP73dPTXV
O+wTwzlKUlLR9Pu8/LpZ67n7n/tJaTBr3/BLj4F+EtW+Huu/H3V/AXiLw3N4n+Euj37W2uaDA3gW
O0T7ZHY25v7EG8Qyfvg+8x7dyBgifmr/AMFYYNS0n4pfCjRtWuCL7w78IfCOlzabLKhu9Clj02Pz
rO4hESSW8yzGVzFMZJAJVbcEZIo/lqioxGM9rT5OW2t/z8r9e/oldlUsMoS5k/6/r59wooorhOkK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+7f8Ag2g/5TX/AAc/
64eIf/Ud1Ov6y7D/AI9I/wDd/pX8mn/BtB/ymv8Ag5/1w8Q/+o7qdf1l2H/HpH/u/wBKALkHU0UQ
dTRQB8cf8HR3/KCj45/9wD/1IdMr+bz/AII561ZT/F34teDG1GzsvEXxV+E3iPwT4Wt7m4S2TV9Z
vIoha2ImkIijeZkKIZWRWcqobeyA/wBIf/B0d/ygo+Of/cA/9SHTK/kq+C/wX8VftE/FPRPBPgnR
L3xH4p8R3ItdP0+1UGSZ8FiSSQqIqhneRyEREZ2ZVUkbYeTjVjJK+u3czqpODTdtD7M/ZMWH9mL/
AIJ1fFHX/jXol14/+HR+Idt4Nh+EV952m3Nj4nig+0z6rLdkCbS3S1ge2ItQ0tyd0U4jjhjLfYXi
f4UeMPEf7M/7Vfimw8B3fxg8O/FTw18NPEHw38LHQ7y1gttAe6uZIdES10yeOVG0+EJmO1lKssK3
EjfvCrfkF4g/Zs8a+Gfhdq3ji50Uv4M0XxN/wh0+u2t3BdabNqvkyTm2t54naO5xFE0heBnjCvEx
YCWIv6NpX/BMD41ar4ZbW38N6Fpmix+G9I8XS6jq3i7RtMtINL1V5Y9PuJJbm7jSPznhdRGxEgO0
Mql03ehhcVKMPZKm5LW3/ky7O61emyab0bZz1Yxb5nJL+l5/1deR99p4jX9l/wDYu+MHgX45/Da0
8E/DT4nftCppXiTw1Yaw73HgKy1DSo9UiuLI2cBtfMtFj06aMRiUTpbPDJbxL5ZbiP2x/Amp/EX/
AIOYby902AvpnhDxD4Z8Ua/f3FzHDa6NpWn6fpc95e3E8sgjihjjjY7nkAJKICWdVPw1+0B+wV8X
f2W9N1y+8eeCr7QdO8Oa5a+Gr69Nzb3NompXNgNQitUmhkeOV/sjJKwjZhGJIw5UuoM1z/wT/wDi
7a/tHa98IT4QeT4l+G7CTUrvw9FqVnLeyxJardsluqykXU32dxIILcySsA2EJVgN5YypyKn7J2jN
PXe6c/dfupbt200aem9pjSgm6qktV8tlrv5L8DH/AG1PiFo3xc/bI+LXivw5c/bPD3ifxnrGraXP
5Lw+faz300sL7HAZMo6nawBGcEA8V7x+yB4Z1z9tb9hDxF+zf4Iks7n4jweP7T4gaFod9rJs18Rw
Lp1xZXsVmJmW1W5hUwzvudHlhSQgt9nCn47oryVWftXUl1vf579++m/zOpwfJyRf9I/Xj9lL4kaN
8V/+C3X7M+jeCLxfGdr8CPhbD4H8S69oyyS6PcXNhpOoW9xd21wqK72Xm3MUSXDoodyAu5GjZ/PP
+CUekeHfgJ/wTg/bJ1L45/DDxRrvgO18ReCtD1zSnMuk3LzW+q3KXltHJuil+12rXFtM0AdBlY0m
aMSIT8F/Cz9lzxt8Z/hb448a+HtN0+48MfDe3hufEV9daxZWI09Jt4h+SeZHlaRo2RFiV2eQoigu
6K3n1djxzSjJw6yku2qS2ad7OOvfbQ51ho25E+y89Hf5bn63fs7eBfiaf+Dpq6XxzeQ+KfE+nXt9
f6pqeiadLaWlpp02gOlm5jBY26x29xZw4keTEhVGlmY+Y/zD8Mfgl8SPir/wSv8AHnw38O+GPFXi
PxR4N+M+nXmp+ENL07VrzWdFLaRqVtNcXNiIzBAnmW6w70HnF4nScKqW274vrpvg18H9f+P/AMUt
D8F+FrazvfEfiS6Wy022udQtrBLqds7IhNcSRxB3PyorOC7sqrlmUEeOdSXKovWU3a9376Stte+i
169ivYuKumlolt2d+/8Aw3c/WP8A4LE+L/Deo6H+0JqPiyHVvGvgGD42+HtOsrXw14omsJrXWIfB
5hu91xPY3VgRH5KwyRwKLrzIsXJRY7bf6L+3h8EvGnxP0n/gpnDongrxL4i1PXL74YWWltpelteN
fyWsNtPdQw7FMkjxwyW8sixghEZGkC7o8/iX8Sfh3rHwh+Iuv+E/EVn/AGd4g8L6lcaRqdr5qTfZ
rq3laKWPfGzI210YblYqcZBI5q38HvhHrvx6+J2i+DvDEFld+IfEVyLPTre71G20+O5nYHZEJriS
OJXcjaqs4LsyquWZQdp5k6rlTdPWUm7Le7c9Nm38f4aGUcLZRkpLRLp/h8/7v9W12f2nf2bPFH7I
nxs1X4e+NIbO18UaFDaSahb21wLhLWS4tIboQmRflZ0WZUcoWTerbWdcMfvL/glF+1zo37G//BOX
xhrXxM8J2Pjz4OeKvijY+H9X0S40i61V2Y6Le3fmxQXjx6S8i3NrpbfIzThEfz1A+wMPzp+JPw71
j4Q/EXX/AAn4is/7O8QeF9SuNI1O181Jvs11bytFLHvjZkba6MNysVOMgkc1ueC/2dfGHxD+DXjP
4gaPpUV54T+Hpsx4gvBf2yPp32uZYLcmFpBM4eVgoKIwGDnABI48PiJUcQ6lGO19HrZa76a2W+iO
irTjUpck3o7fmn/wx+6n7S0/i39pD9g74o/EFPg4vxG1b4kfCT4T6ougWulX8umarfNqWq3d7bWq
2VxHfH7Ot3BOUjmLIvlmYlHTf8+fA74vXP8AwTT+Ffxol+O3wb0CD4ZeJ/jbbWGtfDsWzeII9Ejv
NGutXhhtYmkj0OQx7dICtCfOVEfz41Asgv48UV1PNpc/tUve17a3v5X69/z0wjgmoOnKV07eulvP
y/Ltr+1H/BYjxD8Rv2/f2DPh3d+H9Bu/F3iLX9N8C+NNT8NeFbPVNQuNIlu9L8Qm4uzar5tvFayM
Y4kkUm5JtWW4JRLSvQ/jZ4v+H2i+Of8Agox46+J3gm7+JHwlOvfDXQtWTSr77NHez2iw29/b293F
Ijm5s5pYJHt1kX5kjjmaLepr8FKKc825rtw1bv0t9pLS1vta97eZKwCSUU7JK3n0638tD9dbr4e+
Nf2rf+Cr/wAZf2Uvj5Pc+MtB8Z+IYPGtxrnhSSTSU8HXFppQazvreBhNbxLNp81vp8yXAlLSPbH7
RJJEry/nf+3X+0X4i/aK+Of/ABP/AAyvgW28BafB4K0PwoYpBL4V03Ty8UGnzPMBPNNEd4kkn/eM
5bhFCxpxv7Pf7Pfi/wDao+L2k+A/AekjXPFeuCc2VkbuC0EwhgkuJT5s7pGu2KKRvmYZ24GSQDxl
YYnFyq0/hsnKTvvfra9ru127315tehvSoqMt9Ul/lfyva3yPtf4KX+jaL/wRY8Q3PxA0XXvEngaT
42WMWm2Oga7Pot/FqI0K7M0rz3Nnd2LQ+T5KiOCIXBY5mcRrbq36Q/tIan4R+GPxD/4KIeLPjH8O
ta8afCq/1n4X6dqNra3DaeupNDa232hba5WSN3mtvtdpcGGN1BDwLK0QlRj+A9dj8EPgF4t/aM8W
3OieD9KGp3lhp1zq97JNdwWVpp1lbxmSa5ubmd0gghQAAvK6ruZFBLMoN4bHzUFRjDmfTbtNbW1+
Lby8yK2FjKbqN/17vXp8P5dj9jb2E/CBf+Chvij9qfwm/wAWvDU/izwFY6pPoULaHZ6jaictHDaO
JFlWe0tLvTZGt0nbJREmnYSrcP5j/wAFJfD2v/D34AfHGf8AaEaP4iaYf2gNPisE8D6k/hmaO6k8
L+cjN9ptL22SCPT2sIRDGHnEqS+bcSqsTy/nLp/7EHxTv/2gPEPwvbwnPZeNPCUF1d63a395bWNr
pFtbR+bLdT3c0iW0Vt5ZVlnaUROJIijt5ibnWP7DXxWvP2gfEXwuk8H3mneNfCNvc3uuWep3Nvp9
vo9rbxebLdXF1PIltFbeWUZZ3kETiWLYzeYm7qnjazUo06bV2131fNo9NWubS+qs/wCZkQoRg/j6
Ly0VttdFo9rbrtr+x3/BTT4p2PgDTfj1p/xLtNMvfgx8TPjP4c8H615N3ex6roO7whpd1d6lAY98
Je2ktdMlRVhdpPInilV1kh8vgP8AgsL4B8aftGf8Lt8D6NY3viu0sPjr4Z1e90jwhpE+u+JtHt38
GwW899JaJIqNbMogjgJ8rfNDOjyj5dn5ZWf7CvxYuv2hvEfwrk8HXdh448H291ea7Z6jdW9jb6Pa
20XnTXdxdzSJbRWwi2utw0oidZIyjt5ibktv2GPitN+0L4j+Fk3hC607xv4QgurvXLPUru3sLfR7
a3i82W6uLueRLaK28sqyztKIpBJEUdvMTdrWzWdWMoSouzlbre75vdvb+9dLe/qKnQpw5UpLSK+7
3dd9vd/LXTX9NPA37NfjD4X/AAC/4KBeH57TxB+1jri614G0W21G+sdVvE8XXlpMZdQtGeyujdPc
aeLi2EscV0TF5UfmYRgh6T4U/GW9/wCCbf7LPxRn+PXwX8H2nwj8VftDXdnqXw6g06y8QT6ALzw+
mrpbwjz47CSNNuhCLCKEWK5JXf5Sx/lHpf7EfxS1T4+eIPhifCVzY+M/Cdvc3mt2uo3dvYW2kWtv
F5st1cXc8iW0VsIyrLO8oicSR7GbzE3Lp/7D/wAVL/8AaA8Q/C9/CN1p/jXwjBdXeuWmpXVvp9vo
9tbR+bLdXF1PIltFbhNrLO8oicSR7WbzE3YLGVKc1OlSaabWuqu+b3XdXb1tZvWz010UsNGV4zkr
NK/Ta2u9unb8j9pf2lU8RftM/sN/Er4jJ8ILr4h+IPiJ8Ifhde22g2ul6rLpOr3h1PUbrUbe2+xT
pcO1st5ZzlFnLorIZMqx3eDajJqf7K37DPxa8I/HP4Z+G/A3wf8AiV+0UdD1jw3pt95mp+BYdR0i
21YzWl3ZGSGQWUUejSwxi3ZWEM8bI3nbIvzWtv2GPitN+0L4j+Fk3hC607xv4QgurvXLPUru3sLf
R7a3i82W6uLueRLaK28sqyztKIpBJEUdvMTduT/8E1vjRpN94qh1vwnaeEYfBetjw3qt94p8Qab4
e09NSMRnFrDd31xDBcyGACYCB5MxPHIPkkRmPr1Zy9qqbveSfZt8zael2/e1V9r6a6UqUUrc+ll1
6adb7aduu/f9MtN0i/1D/g7s1C7sbC5u7bQ7cXN/JbwborKAeD44PNkIO2NDJJGgZmADSIv3iFP5
K/B7w9qXgf8Aah8LaVq+neHNL1jR/FNpaXth45t2h0i0niu0SSHVYnAKWyspWdWAIQSAiu48A/8A
BMz49fE/9oTxB8LNC+F/ia+8beE7k2mtWnlpFbaS/lySIZ7t2FtGkqRO0UjShJht8tn3LnlvhL+y
D49+NPw7v/F+j6dpFl4S07UF0mTW9f8AEGneH9NlvTEZvskVxfzwRzTiIb2iiZnVWVmUBlJwxNep
Wl/DafPOX38t1turfjsVQpwhtJO0Yp/K9nv1uZH7SX/JxXj7/kSv+Rj1H/kTv+Rd/wCPqT/kG/8A
Tl/zx/6ZbK4qvoDW/wDgl38bfCmmyalrfhbR/D3h/dZpa+INZ8V6Ppugau11bi5gFjqU90lnfEwE
SEW00uxTl9tJqn/BL/42eHbCbUNZ8MaN4d0FDaC21/W/Fmj6XoOrG6t/tMAsdSuLpLO+LQ/vP9Fl
l2r97FcUqFVty5Hv2e/Y6I1IKO62/pngFFfQer/8Etfjh4Z0ubVNa8K6P4e8Oq1mlt4i1rxXo+me
H9Wa6tvtUC2Op3F0lnfM0H7wi2mlKr97bTNX/wCCXnxs8M2U1/rXhjRfD2hL9j+za/rXi3R9M0HV
jdW32qAWOpXF0lnfFoPnItppSo+9tqfq9X+V9tnuNVqb2ku+/Q+f6K981P8A4JjfGnw9YS6hq/hn
RvD+gh7WO28Qaz4r0fTNA1Vrm3NzCLLUri6SzvS0ILn7NNJtGN2CQK8z+N3wD8W/s6eLrbRPGGkn
S72+0+21eyeO5hvLXUbK4jEkF1bXEDvDcQup4kidlyGXO5WAU6FSCvOLS2269vwZSkm7JnH0VtaH
8NvEXifwdrviLTdA1rUPD/hf7P8A2zqdtYyzWek/aHMcH2iVVKQ+a4KpvI3sCBk1s/Ar9nvxf+0p
4yuNB8GaSNUvrHTrnV72Sa7gsbPTbK2jMk91c3Vw8cFvCijmSV1XLKudzKDMYSk0oq7ewOcUm29j
jKK9WX9h/wCKq/tAeJPhfceD73T/ABr4PgubvXbO/uILKDSLa3j82W6nupXW3jtvLKMs7SCJxJEU
dvMTcaf+w/8AFS//AGgPEPwvfwjdaf418IwXV3rlpqV1b6fb6PbW0fmy3VxdTyJbRW4TayzvKInE
ke1m8xN1/V6tr8r3ts9+3r5bi542vfz+R5TRXrNt+wx8Vpv2hfEfwsm8IXWneN/CEF1d65Z6ld29
hb6PbW8Xmy3VxdzyJbRW3llWWdpRFIJIijt5ibmaf+w/8VL/APaA8Q/C9/CN1p/jXwjBdXeuWmpX
Vvp9vo9tbR+bLdXF1PIltFbhNrLO8oicSR7WbzE3L2FX+V72269vXy3D2kN7ra/y7+h5TRXrEH7D
XxWk/aD8R/C2bwfeaf428Hw3N3rtnqFzb2Nvo9tbxiSW7uLuaRLaK12FGW4eUROJYirsJE3Msv2I
vind/H7xD8MJPCF3YeNfCUNzda5Z6jcwWFvo9tbx+ZLdXF1M6W0NsEKsJ3kETiSMq7eYm5/Vqtr8
r3ts9+3r5AqkXqn5/I8qor1Oy/Yp+KN58d/EPw0bwld2XjHwlb3N5rdpfXEFlb6Ra28fmy3VxdTO
tvFbCMqyztIInEkZVm8xN3R3H/BNL406Rd+KU1vwja+ELfwbrg8Napf+Kdf03w9py6kYvPFpDd31
xDBcymDbMFgkkzFJHJ9yRGY+r1f5XvbZ79vXyB1IrdnhNFe63P8AwTW+NGj33iiHXPCdp4Qh8Ha3
/wAI3qd94q8Qab4e08al5Xn/AGWG7vriGC5k8gpNiB5P3UsUn3JEZlv/APgml8avD9z4qXXvB8Hg
+38F60PDmqX3inXdO8P6euomH7QLWG6vriGC5lMG2YLA8mYZIpBlJEZj6vV/lfbZ79vwF7WH8y+8
8Jor6O8R/wDBJv46+C/AEHi3XfDXhnw/4Tvb1bCx1zVvHGg6fpmqSvZw3qfZLma8WK6R7eeN1khZ
0bDqrFo5FXzzwf8Asi+O/iH8X9V8D+H7DRdd1rQtPn1fUrjT/EWnXWkWFlBB5811LqSTmySFEI3S
NOFDkRk7yFoeHqq14vV2Wj32t630H7SO9zzSivdbr/gmr8atFuvEqa74Ph8HW/hHW18N6lfeK9c0
7w7p6ak0H2hbWK6vp4YLiQ2+2YCF3zFJFJ9ySNmvav8A8Etfjh4Z0ubVNa8K6P4e8Oq1mlt4i1rx
Xo+meH9Wa6tvtUC2Op3F0lnfM0H7wi2mlKr97bQ8PV/lfbZ79vwYvbU/5l958+UV79qX/BMD42aD
pEmq6t4X0jQPDm+0itvEWs+KtI0zw/qj3Vr9rgSy1O4uks7xjB85W3mkKD7wU8V5j8bvgJ4s/Z08
YQaH4v0tdNvbywt9Us5IbuC9s9Rs503w3NtcwO8FxC4ziSJ2XKsudysAp0akVeUWle23Xt66MpTi
3ZM4+iiisigooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD7t/4N
oP8AlNf8HP8Arh4h/wDUd1Ov6y7D/j0j/wB3+lfyaf8ABtB/ymv+Dn/XDxD/AOo7qdf1l2H/AB6R
/wC7/SgC5B1NFEHU0UAfHH/B0d/ygo+Of/cA/wDUh0yv5vv+COGuWMnxe+LXg176ytfEXxW+EviP
wT4VtrqdLePVtZvYohaWQmkKxRvMyFEMjKrOVQHc6g/0g/8AB0d/ygo+Of8A3AP/AFIdMr+Sr4L/
AAX8VftE/FPRPBPgnRL3xH4p8R3ItdP0+1UGSZ8FiSSQqIqhneRyEREZ2ZVUkbUJONSMkr67dzOs
k4STdtNz6z/ZF8OaR+y/+xV8W/GXxn8LxeOfBl14zsPAs/wwmuDperweIrZZbpb+5nx9q0xYLYX8
CtGjNPJLPC6qsbkfcfjDwF4y8Qfs3/tWatpngzUPjT4V+J/hT4aeKfhv4Ol07VLaHTfDkl9eva6K
tjpcsYU2EbscW0+P3XnEnzp0r8hvE/7KHjrwl8D734k3el2Evgaw8XTeBZNYstZsb2B9Xit/tLQR
+TM7SxmH51njDQOPuyNXo+mf8EofjjqXwwj8Zv4e8K6Z4ak0nT9ea91Xx3oGmC3sNQVDZXUyXF6j
wxTlwkbSKoaRXjHzo6r3UMROMPZKDa/4El2frba6bS1Zy1qab5nNL+l5r+n6H3ObXR/2Uf2SPjbo
fxn8F6H4K8L/ABc+P0Hhnxp4E0y4shf/AA90i70waxp99aXunxvJKLZ2heKGSOS1ZbGaOOFWnuMc
z+2r4J1Xx5/wc832oaVbGXTvBfiTwx4p1++klS3tdE0rTtP0u4vb25mkZEhhijjYl3dQTtUEsyg/
D37RH/BOn4yfsoeC9T8Q+P8Awd/wj+kaP4nXwddznVrG5MWqtp8OpLb7IZndgbS4hl8xQY/nC7t4
KitqX7APxd0n9orxB8JJvCEn/CyfDOnPql54ej1G0kvZIVtUuytuqykXU32d1kENuZJSoYhDsbHQ
8TVcVS9k/dkn56OXuvTd3fTdPTopjh4c3tFJXcWvLaOu/kvk1dmX+258RNH+L37Z/wAXfFnh28/t
Hw/4o8a6zq+mXXlPD9ptbi+mlik2SKrruR1O1lDDOCAeK8woorxZzcpOT6ndCKjFRXQ+9v8AgnF8
KvGXxS/4JKftoaL4W8H+KfE154im8FR6fHpNhc3b3s1rq0ks0MUUSkSyJFMsjYBaNOeFc563SP8A
gnP4+/ZJ/Yv8dQ+H/BuifET9ozTviPo+ieIvDdr4R0/x1P4V0Obw5/acUot5rS48nzri9MMlwo8t
pNO2RSOFdm+Hf2Zf2XPG/wC2H8VYPBHw70uz1zxVd28tzbafNq1npz3SRLukETXUsayOqZcopL7E
dsbUYji/EugT+FPEeoaXdSWUtzptzJazPZ3kN7bO6MVYxzws8UqEg7ZI2ZGGCrEEGuyFRQhGcoPS
6TvZddtN02nv0OeUG5yipLWzt16ee2j6fkftpo37D/wa8F/th/Fbxf4Q0Hwf4u8KWHxa0nw14l8J
QW/h2fR/h/o0Oipqera1qE2pWd2bSyNx/aEHkQGw2vZTQJKJFjih4v8AZi/YmtfgF8XfEN98OfAY
u/G/h39rLTfDF5o9/wCHYNeu/B3gdBLc2eoAXEU1zZQTiUMNQym8WkTRzZVmr8pf2e/2e/F/7VPx
g0fwF4D0ka74s18zCwsTdwWnnmKGSeQeZO6RriOJz8zDOMDJIBPg3+z34w/aBHiw+ENHOsf8IP4d
u/Fmt4uYYPsWmWpQT3H7x137PMT5E3Oc8KcHHYscpSjONH7UmrffZadLr8NNTCWGtdOfRLX83r11
/wAz9Q/EP7JNutv+0x4sh8O+J9Z+Ktx+0DqOnX+nab8J9M+ImsaVoUltc3tldjS9QaN7e1vnuZGF
4cCT7JAI93zkdx8N/wBnPwnpH7QV942+Cfw0sLDxjbftKeGNB8S+FH0fRvE0/gHQk0yG4u7oJbNe
rpUb6lJfBpoZUWA2iRI0D2zxJ+KNFSs1imn7PZ33/wAXlpv03stNrazws2mubpbb0v1/r8/c/wDg
pz4d1Twx/wAFGPjpb6xp95pl7P471m9ENzbvA7w3F7LPDKFcBvLkikjkRsYZHVhkEGvp7/glH8PP
DOtf8Ezv2qrj4pP4s8K/CjXtZ8D6fqHizTNNkuhbi31kNcwwqSI5JES7tmkwJZIUlRxFKWWKT87q
K4Y4m1Z1kt76et9Px/4Y2lRbpqCdrW19D9iPiL+yXa6bpXx31ofDHRvDnxjsPi3Z6JL4P+HHwv0P
4lQeH/DsehrPp80GmXLQm3t7sy+ZNetFH5ssUaiKN/Ojjw/iV8FtK0z4Vftu+KfAXwD0bSbL4V+J
9D1Xwe+p+D9I19/DuoGJIPElk0sP2yzuIYYJzPJZPLNBY/JKsNtIMr+SddR8F/g54g/aC+KeieCv
CtvZXniTxHciz022utSttPjupyCUiE1zJHEHcjailwXdlRQzMqnreYc65Iw1bfa+vNbpvrurXsut
rc/1ZxXvS0SXTTS3nto99rn2X8A/irpPxR/Yj/aw+JKfCr4O6N4h8E654a8T+G1tfCFpdWnh6fUb
qTTr6GKO8Wcy2ksTBltLhpbe3lAkgihcBh9j/tOfsW/C/wCFOqfH1fhh4Bu4vHVr8WdNtJdH8MfC
3R/ibd6Pokvhq3vVaLSL6UfYLSe+urtjOm1MxQwRrtiZY/yT8Cfsb/Ej4mftSz/BXQ/DZvvibbal
faPJowv7WPbdWQma5j89pBB8gglO7zNp2fKTkZ8xqKeLlTj78Ou+2ut7aaP3le3ZBPDxnL3ZdPXt
br5P7353/VL9kDSvB/h7/g6I06z8F+DP+EB8O2+q6pGvhtrmyn/se7/4R65+1w5tLm4tk23fnERR
SkRf6sLGU8pPzr+DnhjUfB/7UXhXRtZsfDej6tpfim0sr6z8cwPBpFjPHdokkWqxsA6WyMCJ1IyE
EgIyKl8IfsreOPHv7O/iz4q6RpunXvgnwNdQWmvXKa1Yi70x55IooGeyMwuvLkkmRUlERjZlkAYm
KTZ55UVsS3GPu296Ul6Oy006cu6+7Q1o0VFu0r6Jfdf/ADO1/aS/5OK8ff8AIlf8jHqP/Inf8i7/
AMfUn/IN/wCnL/nj/wBMtlfaf/BCGHUdd0z9o/T9I+FVj42ul+EfiFHvRHq8lxqLTxQrBorLa3KR
FLlopCqpGt07I/lzLt+X8967P4Ffs9+L/wBpTxlcaD4M0kapfWOnXOr3sk13BY2em2VtGZJ7q5ur
h44LeFFHMkrquWVc7mUHLDVXGupqN9dv6TKrU06Tg3bTf+mvzPuX/giNfTePrr9p2HQvgroOuG6+
FniaZRZJrtyZPtKQm18PKEvSDBK0L+WMG9co+24JXhP+CJ18/wARH/aattC+C/h3V5Lj4YeJbiM2
S6/cPcm5WA2vhtRHfENBKYJDGMfbX2SYuGKgD460X9ir4na98efE/wANIfC00XjDwUt7L4gt7q8t
rW00SG0z9ouLm8lkW1ht04/fvKIm3x7XO9Nxon7FXxQ8QfHbxH8NYfClzD4w8H295ea7bXl1b2lt
o9taRmSe6uLqWRbaK3VACJmkEb749rN5ibuujVqr2b9m3yt9N32Wn4amUqcZczUt0vlbrv8A5H2H
/wAEVL+f4gr+01D4f+COga20/wAMvEk4axTxBctKLoW/2Xw6BFekGCVoZPKGPtrlHxctt+U/4IqX
1x8QYv2nIvD3wP0HXnl+GPiOcGwGvXDyi6+zC28OgR3xDW8hhkMYx9ufZIRcNs+X498P/sU/E7xN
8e/EnwztvC8kfjDwdHe3Gu291fW1paaNb2al7i5uLyWRbWK3RRnz3lETb49rNvTdJpP7D3xU1j9o
HxL8Lk8JXFt418GxXlzr1re3ltZ22jW9ohknuri7mkW2itlQAid5RE4ePazeYm54evOHs37Nvlb+
bfRe7pb5/IdSMXze9a6XXZLrv+Oh9ff8EU9Zl8ar+03HoPwR0PXGufhj4kdW07+35nl+2C3W18Oj
y70hreVopPLXH22TbJi5bb8rf+CLGrnxvF+03FovwU0HWTcfDHxJMjWC69cNL9pFubXw7iO+wbeQ
wSmMY+2vskIuG2cfIGk/sSfFLWPj14l+GSeEbu28Z+DYLy7160vbm3s7fRra0jMk9zcXU0i28Vuq
AETPII33x7WbzE3GkfsS/FDWfj54j+GSeFZbbxj4Piu7nXLe9vbaztNHt7VN811cXk0i2sVsF2kT
tKIn8yPazeYm68PXnTdJuk3yuXzb6fDuvn8hzpwfN726XXt13PsT/gifczfEO3/aeTQPgloOtGT4
Y+I5lexj8QXJmN19n+y+GwIr0gwSmCYxAj7a5jkxcts+VP2adJn+K3/BH3xV/wAIf8KLb4v6y3x0
F9N8NbKLUr+z8MWUmiP5OoRx6dcx6uFLiS2WS8uZYCsWEBmEzn4+0X9iH4p678fvEfwwj8JXNr40
8Hw3l1r1pf3VvY2+i21ohknubm7mkS2ht1TBE7yiJg8e1m8xN2yP+Cc3xgtNS8V2+reGdO8LJ4J1
lPD2rXnibxHpmgWEeoPG0qW0V1e3EMFxI0KGUCB3zEySDKOjHKNWooQh7N+7zL1b+XTtrsTOMby9
+17P5L59e+h+lfwi8C6v45/4OrfFHibQI9f8YeGPCurXUWua7Y2kdxa6I8vhy4gW2uJrWJYodkyS
WyCTEpaAqzSTh2bxn9kfwKg/4JJyeFda+CHir4z674H/AGhbm98YfDrTprqx1iC0bwxLawSXS2iv
fWiR3gkO94gjPA8YbPmAfHb/APBOL4xafqvi201jwxp/hMeB9aXw7q934o8RaZ4fsYtRaNpVtYrq
+uIYLiRokMoEDvmJkkHyOrFi/wDBOv4v2up+KbbVvDWn+FF8G6umg6pdeKPEWmeHrJL942mS3iub
64hhuHaFfNAhd8xMkg+R0ZtHiptpqm/im+/xJaarpbzvroZRoR5bKataK+S63T63P1E+Ldh4R8Yf
8Ey/hZodt8Idb+PHiHwD4v8AD8XxA+Huh3Mdpqto8PgRNPxd/wBlrJqFr5F7C6s19GsvnWc0HESK
AfFHQvDnjv8A4JdfDHw9a/CTWvjv4h8A+M/Dq+PPh74emht9YtSngNLFTctpkcuo2whvIijm+QSC
e0lgG2NFVfzQm/4JffGKz8IXfiG807wNpfh+z1KDSG1TUfiJ4dsbGa6n0+21KGOKea+WObzLO7gm
Vo2ZWVmAJKOF4zwX+x14/wDiR8YtW8DeHdP0XXta0HTZtY1O507xHpt1o+nWMMAnluptTjuDYxwI
jKGkacKrsIyRIdlXLF1LxXsnu/v95W1jrvqndaPRXYSpR1tU7deit56eu+2p+rXxY8P+HvHv/BND
4aaHZfC3xB8evE3w98Y+HLbx78OdEdLfU7Mw+BIrEfajpayahb+TeRtEzXoWQTWc1uAscYVZPiz4
c0Dxd/wTO+Fvh6z+FGsfHvxB4F8XeH18f/DrQWW21fTpIfAyWCC7OmI+o2wivEdHN6ok86zlgXbG
igfmNN/wTZ+M2l3/AIrg1rwpZeEovBWtjw3qt74p8QaZ4e0+PUjEZhaxXV9cQwXEhhAmAgd8xPHI
PkkRmWX/AIJtfF6zTV7i90Xw1pOk6LcWNpNrep+MtF0/Q7ie9sU1C2httRnu0tLqR7OSOfZbyyMs
ciMwAYZaxtWyvSe76Ld83eLvvs7rfRXY+RLT2i/q3n/V0fpx8VbDwl4w/wCCZnwv0K1+E+tfHnXf
h94x0CH4gfDnRZks9XsZYvAaWB+1Npkb6hbiG9idGN8PME1lNAoWNNq/Ev7bniz4I6P4o+H+neK/
BnxB8Q+LtH+HfhnStbOheMNI0GLS7y00q3tZ7C4t/wCybqc3cM0MqytdSiZSRF5aJDHu8gk/4Ju/
F20XVZ73RvDOk6TpE9naya3qfjPRLDRLqa7s0vreK11Ge7S0u5GtZI5tlvLIypIpYLuGfMfi/wDB
/X/gT47n8N+JbazttUgt7a7/AND1C21C2mguII7iCWK4tpJIZY3hljdWjdgQ3XOa58TiKjpq8Gve
erV+stNV59+jsldlwpQcr89/n/wf663PpD/gnppWq3P7U2t+O/htKnw4+D/hDT1fx3qPjyePxHo9
noc6rFcWOpLFb2yakb11eOCyjhSWVzGEKtEbhPoT/glTf+G/iB8Wf2un+D3wRu9S8FXHw28SDRot
Tm1W/wBTlhuUiFroMptbpIytyYZnSJQ94BG6pdSmJpG/NzRvh/r3iPwrrOu6fomr3+h+HPIOrajb
2cktppfnuY4fPlUFIvMcFU3kbmGBk1ufAv8AZ78YftJ+LbzRPBmjnVrzTdNudZv5JLmGztNMsbaM
yT3VzczukFvCgwDJK6ruZFBLOoMYfFSi4RUOazvbu/LR2Xklr91qq0LqTcrXVv8Ah9dfv/W/2z/w
RWvbzxj/AMNONoHwd0nW1uPhh4gINimuT7/tIiNv4eHlXnME4hl2Kc3jiFytx8hIl/4Io3snjaf9
p46P8F9I12O8+GHiHyk09NcnDSXXlG08PL5d780Exhk2Kc3r+S+2clTXyRYfsL/Fe+/aB8S/C5vB
93Y+NfBkF1ea/a6hdW9jbaLa2yeZLd3N3NIltFbBChWd5RE4li2O3mJujsv2IfipefHzxJ8MX8IX
lh408HW91ea7Z6hcwWMGj21tH5st1cXUzpbxW4QqyzPII3EkWxm8xN2+HrVIez/dN8rl82+nw6Nd
tfkOcIS5rS3S6/jufXf/AARLu7jxm37T/wDYXwW0jxEbv4XeIBEtlHrdwGe68k2/h8CO7+aGYQzG
Nf8Aj9YwsVuDsNH/AARMW7+IA/ag/sH4M6Xr6y/C7xBIv2CPW7ne1yYPs3h4CO8+aCcxSbBzeuIn
KTnYcfImk/sP/FTV/j34i+GQ8I3Vl4y8I29ze65a6hdW9hbaPa28fmS3dxdzyJbRW2woyzvKInEs
Wxm8xNy237D3xVn+P/iX4XyeELux8a+DYLu7160v7q3srfR7a2j82a6uLqaRbaO2CFWWdpRFIJIt
jN5ibnQxFSDpr2Tbg5J6byfTbRrtqKcItytKzdvw+f8Al8z60/4Io3N14zl/ab/sL4O6Tr/2j4Xe
ICq2UWtXIla6NuLbQAI7vmGYxSCMf8fjmNik+VyD/girc3PjN/2nH0P4N6Rr8c/wu8QkLZprk6u1
z5LW2gDyrz5oZfIlMa5+2P5LlZzsOPk60/YU+LNz+0D4m+F0ngy+sfG3gu2ur/X7O/uILK30a0to
vOmu7i6mdbaK2EZRlnaQRSCWLY7eYm4tf2F/ivP+0J4j+Fkvg+707xt4PgubzXbTUbq3sLbR7W3j
82W7uLuaRLaK28soyztKIpBLEUdvMTcsPiJw9klSb5G16t9Pheq7av0HLklze8tVf5d9z6x/4Ir6
rN4rX9p8aL8HtE1v7Z8LfEPl/ZI9auNzXXk/Z9AUJeEGKbypDGDm8cwsVnO01o/s6xT/ABP/AOCL
HiK08J/Dmx+L2rt8e5NSk+GNpFqV9D4Tsn0AiPVI49Pnj1QJIwa2El1czQEWgCr5old/jy2/YY+K
037QviP4WTeELrTvG/hCC6u9cs9Su7ewt9HtreLzZbq4u55EtorbyyrLO0oikEkRR28xN25c/wDB
Nb40aPfeKIdc8J2nhCHwdrf/AAjep33irxBpvh7TxqXlef8AZYbu+uIYLmTyCk2IHk/dSxSfckRm
Ua8/Zwh7J+7zJ+bfT4dLdtfkKcabu+Za2e/brufoX+2X+yh4l+P/AO2l8efGWq3vxN+MPwH8DeNL
fyPAPhG6/tC78UeKU0axSSxNtpyGPT4baPZbXGoSQiVYoBArzXW7bpfEW8+Ivxe/Yr8U2fxn+FWo
fGr4maL+0bJr/jj4X+Fr/bd6fYTeDYbewuDJpnnzwW6kRIsrGQO1mUd/M80t+XMH7G3xQuf2oh8F
o/BesSfE9tS/soaCqqZjNt37t+7y/I8v975+/wAnyf3u/wAv563dH/4J7fFnVIfFdxceH9K0DTvB
XiObwhq2qeIfEml6FpkWsRbzLp8V5e3EVvcXCKjM0cMjsqFWICupOksZNzc3Td+aTa3V3zaNOLu1
fZ366e8yFTUY8rmtEv01362/qx+gv7XviD4za3+y98MfhLpfwd8N/HTwT4T8PeE7zXPC08d7P4i8
E+JR4ehtHt7my0i8ttRhjMEJYPdxsnmTSR+ZujWKK9+z38CfBfwH/bk/bZ+HXwr+Hdp468KeHfhp
rlrZXoutS1S4e7ubOzf/AIR0yWtwiNGbpLqJFCC9P2d184sjkfmf/wAMa/FE/tQf8KXHgnWn+J/9
of2aNAWNWnaXb5m8MD5Zg8r9954byfJ/e7/L+euL+IXgLVvhX4+1zwvr1p9g13w3qE+l6jbeakv2
e5gkaKWPehZG2urDKkqcZBI5pQxrpP2jpPSW+mnxXjfl87u99io0Fayl06fg9/LQ/Rv9kx9M+Lv/
AAR9XT7L4Tan8ZU0f9oi98Q6t8LPCl9eLcWen3Phg29tc7oBPqENslyAqyyllkNr5e8sZGr6Z/aV
8JjWP+CXXwS8EXfgbxL+0BrPw81/w7deLvhJpEstnrXhlZfAsdvGLpLGA31sq3gMpedTlh5IYAMq
/kD8If2PPH/xv+Ht/wCLtG03R7Lwlp2opo8uueIPEOneHtMe+eJpRaRXN/PBFLOIlMjRRszqhVmA
DKT0t9/wTb+M2gan4ptte8J2ng9fButL4d1S78U6/pvh6xXUGi85baG6vriGC5cwFZgIHkzDJHL/
AKuRGbOhia0YRUad0n2Wt0/LXfZ3W9lqwnBc799Ly+7z/q/ofq5+0poMWr/8EtPgV4H1DwF4m/aE
1/wB4g8PXPi/4TaXcy2eseGkbwQLWKO6jsYTqFsouVEpe4U5ZDErKvyr+bv/AAVtt7rRfid8IND1
G+vjq/hr4O+EtJ1LR72JYbrwxdRWA82wlj2LIjhiZikxZ1+0YyqhETj9a/4JifGrwvpVzqms+GNH
0Hw9CbNYPEGreK9I0/QdVa7tzcwLY6lNdJaXxaEFyLWWUqAd23FeZfG74CeLP2dPGEGh+L9LXTb2
8sLfVLOSG7gvbPUbOdN8NzbXMDvBcQuM4kidlyrLncrARjK9SdO0qdlzb2666Xstde/R2SuyqVOK
lzKV/wCl527dDj6KKK8w6gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigD7t/wCDaD/lNf8ABz/rh4h/9R3U6/rLsP8Aj0j/AN3+lfyaf8G0H/Ka/wCDn/XDxD/6jup1
/WXYf8ekf+7/AEoAuQdTRRB1NFAHxx/wdHf8oKPjn/3AP/Uh0yv5wv8AgjX4h04fFX4yeDptTtbL
xF8VfhB4j8E+FLS4mFumt61eJCLWxErlYo3lMbBDKyqzhEB3ugP9Hv8AwdHf8oKPjn/3AP8A1IdM
r+Sj4NfBrxR+0L8UtD8FeC9FvPEPijxHdLZ6fYWwG+eQ5JJZiFRFUMzu5CIiszMqqSN8LUcKsZJX
d9u//B7eZlWipQcW7H2z+yLYP+yr/wAE4PiV4r+Ofha6+IfwjvPiInge2+FN9JNpd3ZeLra3iup9
Se7KCbS3isw9u/2bdLcEiGdFjjRq+svFPwa8f+Jf2f8A9rLxtpXw2uviz4F+LHh/4ea18PPDn/CP
3VtbroxuRPbaIlvpUsbpJptpJD5kVrMBtWKeQkTYb8j/ABJ+y3448K/BvUPiFdaVaS+CdM8VyeCJ
tZs9Vs7y1k1ZIGuGgiaGV/OTyVLiaLdCwK4c7hnsPBf/AATl+Lfjzwhquv2mjeG7LRtDs9N1DULz
V/GOi6RFZW2o28NxYzSG6u4tqTpPGEY8F98f+sjdF7KOImlGnyNpXt90vLW127PTR92c9SjFydTm
Sf8Awz7+X5dkfpZqNxbfsr/8E1PiV4M+OHw5tPAfgr4oftNXOh+LfD+naxvPgvTdQ0TTtWtp7F7G
OS332JSxmVY4pFmjjaF4V+Tb5h+1/wDD/X/HH/BzxdXtpaxm18EeJPDHivxBqE00cNlo2kadp+l3
F3qF1NIyRwwxwxl2LsBuZUBLsob4Q+OP7BPxb/Zt8Ia3r3jfwdcaBpPhzxQvgvUJ5b21l8nVmsxf
LbhY5GZwbZlkEiAxkMvz5IFJF+wb8WJ/2hPEXwoTwk7fEfwvZzX154fGo2n224SKFZ2W0Xzf9NlM
LCRIbUyySJlkVgpI2+uVJQVL2baUk133k0tI+btp0enbP2EOZ1Odapry2jrv5fc1roZv7anxG0n4
xftkfFrxdoNz9t0LxT4z1jV9OuPLePz7a4vppYn2uquuUdThlDDPIB4rzOiivJqTc5OT6nfGKilF
dD7e/wCDdTw1qeu/8FdfhldWGn6heW2jQateahNbQGRLGA6XdQCWVsERxmWaKPc2BulRQdzKDB+y
D4dbwL/wT/8A2o9R1/wZ4XXxx8EtW8P32jHxD4O0+8v9Hvry/fS7+3uVu7d3mj8nK/ZbkPFFMvmp
Gkw8yvn34JfsXfED9oX4a+IfGHhi18Mv4b8JzxW+s32qeLdI0dNMaXAhMq3lzEypIx2I5Gx3BRSW
BUXvG37APxc+G/hj4k6vrvhL+y7b4Q6jBpfi6KfVLJbvRpbiSOO3drbzvOkgmaVPLnjR4ZASyOyg
kdsJ1FQilB2Tk769Vbt05b79H2OaVOLqNuS1SVvR/rex+hvwj/ZQ8LaH/wAHOHiH4b2nwr8I3fw6
aOa71fw4+iQ6zpGnW82hx3gmCXETJaKb6SAjywixNMII2MbBX8T/AOCL/wAQvFfw08V/tC/C9tF0
G38USfC3xZFpmg6n4S06fxBqeupHbJ/ZYFxbtd3WPs7s2msXiYxSsYC28n8+6K0WYpVFUjC1pSe/
SVtNtLdPXYl4RuLjJ3uktu19d+t/+Cez3n7HfxU+Jv7aWqfCSHw9oVz8V7zUrtbrRtL1HSbeyguk
ikuriFJLeVbGHylSQGGN1WJozEFVl2Dxiiu0P7PXjIfs8D4rnRJR8Pm8RHwmNY8+LYdUFsLo2wj3
eZkQEPu27eQN2TivPlyy+FO+vW+n3dNbvr2VtepXS95n1n+wR8LNb1n/AIJfftF+P7X4baP4ivPh
lqOk6t4U1y+8DWWrrBcs/k6xG0s9tKt3DDp0sc0ltOZIbbelyEjkxKfWf+CZPw48J/HuXXPjde+B
/htd2ut/Eyx0rxT4C0vStHTQvAegxWUl/e69dNrFtfyWWmvtmTZBJagtDLHHMpEEcf5t/EH4ba38
K9atdO1+xbT7y90yx1iBDIkgktL20ivLaUFCRh4J4mxncu4qwVgyjDrppYpU5QvH4d13d35ab2+S
uYzoc6k09/y089T9kPh/+y9+zX+yN8N/im/xu+FWjaZ4GvP2kNZ+H91q+tW+r3GpaP4dg0aTVNIS
xaFvtMO6ZbU+fEWa4t7wiQtHscdx8NPAHg7xXb/CLx78KPgh8PdN+KWvfE/4d33jaHQfDS6pFpXh
2/8AD9lfzXdvZT28sej2a3j3Cfa7Yh/Mt23zh0wPx08H/sy+NPH3wI8XfErSNMs73wd4Dltodeul
1W0W4003EscMDNatKLgpJJKqq6xlSQ/P7t9vBVuscouDVOyTuu730vbZPbs193M8FKV26jb28unS
+766n6h/sh/Ay78af8HJvxI8KeLvh/Z+JdA1PxX4rvNf0/xB4Yh1S3g0+Vrm5tL1luIHEKPM9i0d
wqpvE8ahtk5VvNP2DPhfMn7LHjnQovgp4mufiX4f8exWuseI9N+HWkfEjW9OtRZzJ/ZFx4c1KWOT
T0S4jkkN8kf7x90DsDCin4HorN45XTUdpSe/SVtNulvx6G/1Z2avuktu3Xf+vM/XfwR+zp4U8C+F
v28dK+Jlxpvg74RP4u8HaNrOv/DfQpzo8Dw6zBJewWcNxJL5M0JuYftMETzCzeYiKKaNYYZPjH9q
bw/feDf+CvepafqXgb4QfDeWy8dWCx+HrpWPgeyt/NgMDXWUQtYSw+XNO3lxbkllIhhz5SfK1FTW
xkJpWhazvv5t2Wmi1/Nu+lnDDtScm76W/L/L+uvZ/tHsX/aH8ekr4MQnxFqBK+D8f8I6P9Jk407H
H2L/AJ4/9Mtlfbf/AAQkguvE/hj9pLStL+FGm+MdRi+EniA/2isOsT3WrPOLQQaFIttcrD5dx5E7
II4ku2cPsnAUBfzxrsvgd+z94v8A2j/Fl3ovg3R31a803TbnWL+R7iG0tNMsbdN891c3MzpDbwIM
AySuq7mVc7mUGcJXlDEKpCN3fb1+T/IutT5qfJe3mfcv/BE7UZfHi/tPR6B8FfD+tSTfC7xJMgsl
1y4M/wBrNqLbw6At9gwSGGXygAb5yr4uG2/K/wD4IlXx+IMf7UEOhfBDw/rtxL8LvElxAbKPXblp
TdfZhb+HQEvSDBIIpzFgfbnKPi5YrgfINh+wh8Wr79oTxL8LG8GXtj428GW11fa/aahc29jbaLaW
0fmy3lzdzSJbRWojKMtw8oicSxFHbzE3Ntf2FvixcftCeI/hZJ4NvbHxv4PgubzXbO/uILK30e1t
4/Nlu7i7mkW2itRGVcXDyiJ1kjKuwkTd2UMTWh7L923yOS23b6bbrXQwnCEuZKa1Se/Rdd9vu9T6
8/4IpamPHMX7UA0b4K+HdZkb4W+JZ4TaJrlx5puzai28PfLekeRIIp/KA/05yr4uWKgBv/BFi8f4
iWX7UUOhfBnRNTlk+F3iS6jfTl1y4ab7SbX7P4d+W9ZTbSCGYxjH25zG2LltuB8iW/7DHxYl/aB8
S/C6XwbfWHjXwbBcXevWl/cQWVvotrAgkku7m7mdbaK12MjLcPKIXEsRV2Eibo7L9iL4p3nx78Qf
DJ/CF5Y+M/CdvcXmt2moXEFjb6RawRiWS7uLqZ0torXy2RluHkETrLEVdhIm4oYqrT9m/Zt8jfTd
vptpbXv+BbpxldqW9n93z2Pr7/gitqLeOl/ac/sP4NaBqjn4X+JbiM2S67Obj7X9mW38OZS9I+zy
CKbygP8ATZCrgXD4wH/8EUdUfx2v7TkWg/BPQNamm+GHiSaJrFdduGl+1/ZltvDo2X2Dby+VN5YA
N9IVcC4bHHx7p37EnxS1H49eIPhkfCN3ZeMvCcFzea3a39zb2Nto9rbx+ZLd3F3NIltFbBCjCd5R
E4kjKu3mJufp/wCw78Vr/wCPniT4Yt4OvbHxn4OgubzXrTULiCxt9FtbdA8t3c3UzpbQ2wVkIneQ
ROJYtrt5ibqo4ivT9lek3yOS23b6bbrXTX8B1KcXze9vb+tz6+/4Io6xH4zX9p4aV8FNB1oyfC3x
LNCbFNduTI139mW18P8AyXhBt5DFL5fS9fbJi5YqAF/Zwdvif/wR48UWvhP4cQfF7Wm+Op1SX4V2
0erX1h4TsZNDfytUhjsLiPUgHZZLXzLm6miK2qAr5oaRvkGy/Ya+Kt5+0H4k+Fr+ELmw8a+Dobq6
1201C7t7G20e2to/Mluri7mkS2itghVlneUROJItjt5ibty8/wCCbPxn0O98URa74StfCEPg/XB4
a1O98U69pvh/T11IxecLWG6vbiGC5k8kpNiB5P3MsUv+rkRmyjVrKEIOm7RcltvfptutdNfTQUoU
22+bez36L5/ifev7SH7Keu/tBftW/tDeM3uvjj8Y/wBnnwN8RJVtfA+jS6lqFz4q8YJY28dxp6xR
xf6Da2an7PJetFuSzhgggeV3jcacl54t+Kn7Eni/SPiz8G/F/wAZ/ipon7TN74j8c/C3SL7Uo721
sLjwubeylV7b7RNBYpMFWCVNySRW0UYdk2EfmdH+xz8T5P2oF+C48F6yPig2pf2SNAKKJ/PxuzuJ
8sQ+X+98/d5Xlfvd/l/PW7on/BPr4r6zbeKbqbQNJ0LS/BniKXwjquq+IPEul6HpcesRBzLYRXl5
cRW9xcIqF2jhkdlQq5AV1J0liqjk5ezfxNvqr66O6eqvs79dNWR7FKHLKell+nW/W2+n4H3f+0f4
q+L/AIn/AGefC3wZ0b4A2nxo8NeBtL8Iah4n0HUo9duNe8L+Ij4VtLYRtY6fqFvcW9sLWIfMbdYj
PJMru8q4Xpv2Vfhh4D+F/wC2n+218PPg98J38aeGPDfgDxLp1jeXK65calLeSW9oj+GX8m4jV7c3
dvfRxbYxeSLExW6kC7q/NH/hi/4p/wDDU3/Ck/8AhCNa/wCFpf2l/ZX/AAj+xfP87bv3b8+X5Hlf
vvP3eT5P73f5fz0zwt+x38RvGXx28T/Daw8PI3i3wU2ojxBDPqNpbWeiJYF1vJbm9klW1hhiZCpl
eURligDEuoJSxUoVOaNJ35n66814rT+9d3vqtuhLoQaaU9139Nd9tPu6s+5f2SLzw/8AFn/gkXDp
tn8INT+M1zo37RV14i1r4XeFtR1RJoNKufDDQWkoMJnuobdLlHVZm3s/2bY8jda+hfjnoGl61/wT
g+F/gSf4V+O/jh4v+HHi7wveeP8A4V2VxqtpqenQyfD20t7d5I4FlltI1mCkuiIDLHJGw3bsfl9c
f8E1fjTo954mi13wjbeDYfCGsjw7qV74s17TfDlgNRMInFrDdX9xDBcSGApMFgd/3UsUn3JEZpbr
/gmZ8ZtL0661HUvD2g6HoNtJaQx6/rHi7RtM0LUZLq0W8hjs9RuLpLS8c27pKVt5ZGRWUsFyKinW
qxhGDpvRvp1tLTbzejutHpqy504yk5Kf9aee39XP06+NmlaVrn/BNr4VfD+T4W+O/jx4q+Gni3w3
d+P/AIXWlxq1pqelRyeAbaGDfHAJJbOJbgnLpEgaaGRG+YsT8Rft46v8KfA3xC8DeHPiH4F+MWqe
OfDfw68JadrMEXjCHQE0iRNBsj9i+yXWl3bo6E72IdFzKVMKurySeSaj/wAEx/jRoVld3+q+G9D0
PQbWaztk8Qat4t0fTtA1CW7s1vreO01Oe6SzvHa1ZZdtvNIVV1LbcjPl/wAafgf4m/Z88b/8I94r
sbay1FrO21CFrW/t9QtLu2uYUmgngubaSSCaN43Uh43ZeozkECK9eXsuX2dkpPVq/wDNpqtXrbXR
WdktRwhGUr899Oj/AB0f6H0L/wAE+11OD9qzV/HPw1mPw4+EnhawB8c6h44mTxJpFpoU6pDdWWpJ
Fb2yaiLx98cNlHEksrtGqFXj+0J9Ef8ABMLW/BnxF+Kf7WUfwf8AgdLc+Dpvh54kk0FdWm1bU9Xu
4blbZbXw9MbW4WHy7gwzvGkafbR86C9l8vzD+b2ifDvxB4l8J63r2m6FrOoaF4ZEDaxqNtZSS2ml
CeTy4TcSqpSLzJPkTeRubgZPFbPwQ+AXi39ozxbc6J4P0oaneWGnXOr3sk13BZWmnWVvGZJrm5uZ
3SCCFAAC8rqu5kUEsygrB4ypCcFGPM027d7q1lo7fJb+iLnRi7u9tLf8P3/rufbv/BFq4m+IcH7T
NvoPwV0fXZ5fhh4jmik05NcuJJDdfZhbaBhLxg0EnkzeWABeuRJi4bYArv8AgiveTeP4f2l7fQPg
loXiCaX4ZeIp0ksY9duZJftP2b7N4eAjvSDbymGXywB9tfbJi5O3j5Ksv2E/izeftC+JPhW/g28s
PG/g63ur3XbPULq3sbfR7W2i86W7uLuaRLaK1EZV1uHlETiSIo7eYm5NO/YW+LGoftBeIvha3g29
sPG3hC2ur7XbPUriDT4NGtLaLzpbu5up5EtobYRlXWd5BE4kiKO3mJu2oYmtT9nam/db6bt9Nvw1
+VhScHze8tUnv0777fcfXH/BFO/k8eQ/tMW+hfBLw/4gnl+GPiOeNrNdduJZzdfZhbeHlEd7hoJP
JlMYUfbn2SYuGCnan/BF3WY/G0H7TcWk/BXQNXef4ZeI54ZLBdcuGka5+zfZvDoC3pBt5fJmEYA+
3PtkIuW2YHyTZ/sJ/Fm6/aD8S/C2TwbeWHjXwZb3N7r1pqN1b2NtotrbxiSW7ubuaRLaK12MjLcP
KIpBLFsdvMTc3Sv2GPivq3x98RfDEeDr2y8Z+ELW51DXbXULmCwttGs7eISy3lzdzyJbQ2vlsjLc
PKInEsWx28xNzo4urSVKTpu0HJdrt9NtGu2voKSg+Z826T3/AB3Prj/gi1qDePl/aZj0T4K+HNXL
/DLxLdLJaDXZzILlYPs3h0bL0gwSmGTygB9ukKuBcttwJv8Agifqk3j3/hpuDw/8EPDOvTXPww8S
zIbVdcuZJBdC3+z+HkC3pBhk8mXygo+3vskxctt4+PtM/Yh+KmqfHfxJ8Nf+EQvLTxh4Otbq/wBd
tb65gsrfRrS3jEkt3cXUzpbRW2woVneQROJYtjN5ibl0n9h74q6x8evEXwzHhC7s/GPhC2ub7Xbb
ULq3sbbRrS3jEkt3c3c0iW0NtsKMs7yiJxLFsdvMTcUa9emqd6bfI2tt2/s7b76av0sOpTi1L3t0
vl+P+R9e/wDBE+4n+IcX7TVvoHwR8PeIZn+GHiO5V7Ma7PJKLkWwtvD6iO9w0Ehhl8sAfbn2yYuG
24Dv2a45/ir/AMEgfFFn4Q+GcPxh1mT45nVJPhXaJrGoWXhOyk0VhFqkUWnzx6kqu+61ElzdzRut
so2+arSN8h2H7C/xXvv2gfEvwubwfd2PjXwZBdXmv2uoXVvY22i2tsnmS3dzdzSJbRWwQoVneURO
JYtjt5ibtub/AIJqfGjSj4pfWvCdn4Ts/B2up4Z1PUPE/iDTPD+njUmiM62sF1e3EMFzIYNs2IHk
HkyRS58uSNmzjUrOEIOm2ouS26vdbdNdNfQmcYtt861t/W/XysfqdqP7RPww8P8A/BXLxZ4F8Lah
8RZPjR4o+NGiy33i3w5olprC3/hq2stNebw1K6XFu9jbQXcFyLmSGB5PItQlwbnY4rlv2rPBrr+y
t8d/Anhf4WX/AMb/ABXp/wC1Vq+v3Xg3VNN1hdQsLG+0WN4tUNlpV3HOLZpEljt7ppPLuYmLmNWK
rH+WEv7HXxPh/afb4MHwXrR+J6akdJOgLGrXHngbshgfLMXl/vfODeV5X73f5fz1d1j9iD4l6D4B
+JPia60TTU0r4Q61/wAI/wCLtmv6dJdaNefaVtVVrZZzPJG0zbFmjR4nKSbXIjcrvLHVHGSdJ/FJ
vfS6d07p6q73+4zWGimmp9EvutZ/13P05+BV38Df2PP+Ciuo/Aj4Nj4k6Z8QLz4x6UZvEHhvTovE
C3vhiG3sLq68OTTNdRXFpbw6hHeG6kjjkkEFtsuDc+WwB8V/2aPCsGgftD6v4f8ADHiPxD8Zz+0P
qCal5XwisPG/iSLQ7jT/ALbbMdEvpzFbadLdS3bRX6Ye5VIcqqkRx/lD8Cv2e/F/7SnjK40HwZpI
1S+sdOudXvZJruCxs9NsraMyT3VzdXDxwW8KKOZJXVcsq53MoNT40fBfxV+zt8U9b8E+NtEvfDni
nw5cm11DT7pQJIXwGBBBKujKVdJEJR0dXVmVgTH1/wBxSdL3eZtWbS1vovNX0fkV9XXtNJ62Xa+n
XvZn64/tK6X4a8R/sI/E7wT8I/gHp/ja80f9oldSuvhitxdareeGVl8KWcdxeNbaBqBMERvob2Jd
s7QoTJDsjeEJFo/Gz4D/AAx+GX7KfjL4W/DP4caz+0X4S+Hf7Skur6h8PfD+v3dxqsFpdeDIIiZp
LON7mG2t9S82BZXQszWbwu5cSMfyi/Zd/Y0+KP7afjZ/D/wv8Faz4u1CAbrl7ZVitLEFJHU3FzKV
gg3iKQJ5rrvZdq5YgHzKpnmF/wB57O127PTzutrP4ldarRaIPqybcVPXT9Nd79N9Op+6H7Smgafr
v/BKb4D+Bpvhj4h+N3iP4eeJPD9344+FmlXd3a6/YCbwNHBFJdRWqyXVlGkqoyu0ah3R0IHzFvzY
/wCCs0DaJ8S/hDoF3HeWet+F/g94S0vWNPu4jDcaVeLYLI9vJG2HRwsiMVdVYF8YIwzeUfCH9jL4
h/G74Z3/AI10bS9HsfBunammiSa94g8Rab4e0yW/eJphaRXOoTwRTTiJfMaKJmdEZGYKHUnlfjR8
F/FX7O3xT1vwT420S98OeKfDlybXUNPulAkhfAYEEEq6MpV0kQlHR1dWZWBOWKxM6tH4Gk5N36au
Wjslffq903a7ZdKEYztzXfb+n/V/Q5eiiivNOsKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooA+7f+DaD/lNf8HP+uHiH/1HdTr+suw/49I/93+lfyaf8G0H/Ka/4Of9
cPEP/qO6nX9Zdh/x6R/7v9KALkHU0UQdTRQB8cf8HR3/ACgo+Of/AHAP/Uh0yv5xf+CM3ijT4Pih
8Z/Bcl9ZW3iT4ufCDxD4E8JWt1OtvHq+tXv2b7LZCZ8RRvKY3VDKyIz7U3bnUH+jr/g6O/5QUfHP
/uAf+pDplfyVfBf4L+Kv2ifinongnwTol74j8U+I7kWun6faqDJM+CxJJIVEVQzvI5CIiM7MqqSN
8LUcKsZJX8u5jXgp03GTsj7U/ZF03/hlz/gnD8RvGHxy8N6j8Q/hFf8AxCXwNZfCm5uZ9LmtPF1t
Db3dxqctyU8zTHjsg9sxtw01wWMMqpHGGr6l8V/Dfxp8QPgn+1t4v0jwBrnxV8E/EPQPh9qHw48O
yeHb2zsf7IaeK5g0OG30uVPm0y2uoA6Wk+MxpLJ/rXU/lL4n/ZN8eeEfgXefEy70mxl8B2Pi+bwI
+s2esWV7byaxFbi5eCPyZnaVPJIdZ4w0DgjbI1dt4X/4Jk/GLxd8PrzxVb6R4StNB02z07UL+51L
x1oOm/2bbahBDPYz3KXF5G8EdxHcReW8qqHZigJdWUdtDEzjFU1BtfK+0v7rvpfe9rO1tTCdOPO6
nPb+l5+X4+h+kOo3sH7MP/BNH4h+Cfjn8P7bwB4C+JX7UF3ovizw5pl6nmeCtO1DQ9O1SC4s7ixE
kUjWXl2EyRLA0bpC0Zj/AHgEXk37Zvw68S+Mv+DmnUry3jgu4vBniXw34t13UUC2Nloej2Fjplzc
XlzLLIUhiggQb5HdQzgbQGdI6+Ivj9/wT1+MH7L3gnVfEXjrwiNC0fRPE0fg6+nOq2Vy1vqr6fHq
K2xSGZ3ObSWOTeFMYyVLbwVDbj/gnz8Xrb9o/wAR/CE+ERJ8S/C1hJqV74eh1WylvJo47ZLpktQs
xF5P5DiQQWxkmZQ+EOxsbvGVPdpOk/dkmu+8nZ6d2+nR2WukKjFTdVzWzXl9nXfy/FdjF/bU8f6P
8WP2yPi14p8O3aah4f8AEvjPWNV0y6WB4FubWe+mlikEcgDoGR1O1gGGcEAivM6KK8epNzk5vd6n
dGPKkj78/wCCaXgISf8ABKz9sTXPEXgjxz4m8HXieGLfOgzHT3vXstQN1dJFdvaXMStbRPBcTZjf
ZCcsEEiyL6N4U/a58aftC/smft1ftHT+C9L0iPxVf+DbHT/t3h+DXNDL2t5FbvbOL6GS2ubmO2kt
HkYpkSTpII4/Mj2/A/wi/ZG8d/G3wFqHirRrDRrPwtpeoRaTPrOveIdO8P6c17LG0iWsdxfzwRyz
eWjOY42ZlTDMApBNofsSfFIfFH4ieC38I3cHif4UaVfa54qsJrm3ifTLKy2/aJwzSBZkUOjL5Jfz
FYMm9TmvQo16qhGNODtZrbd2lZ3tfS70v0OeVOm5Sber/LTp52P0A/4Kb/s4/B7QPC3xj+FPhSH4
PfDzx94U+NFt4knl1GGDRLmw8LXnhu3kb7PLLNLcXVsl2ZJPsFkssgZlaK2HmRwp3n7TPwD0bwj8
ffj/AOHvBHwJs4NU0Tx1o0cWteBvhboXj25sNMfw/E6ae3hq8uh9hgeX/SP7RijAuJWmR2DKsa/l
z8I/2ufHfwT8Aal4T0a/0a88LatfR6pPo2veHtO1/T1vI43iW6jgv4Jo4Z/LdkMsaq7LhSSAAOT+
KfxP1741/EnXvF/ijUZNW8R+Jr+bU9SvHRIzcXErl3bagCICxOFUBVGAAAAKqWOpNNqOrlf0XvaX
/wC3uy2Mlhal7OWlrfPTW3y7s+i/2yNH+Fvwb/bO+LHhzxt4Bk1DU9L8TXEKL8MvFlv4f8PWyAR7
o4rS5s9SeGTeJTJCtyUgkdoVRVhAP2f/AME8P2v/AIbfsi/8EkNQ8R+JfhzL4j+DPiz49XWg61oe
sWNp4kv5bUeHba8gQPIbW2nkjvLW2Yl4EVEkdlDOV2fl18G/2e/GH7QI8WHwho51j/hB/Dt34s1v
FzDB9i0y1KCe4/eOu/Z5ifIm5znhTg44ysaWLqUqqrxjbe2itr8tVrsazoRqQ9k32v8AKz+R+32k
/D/Rf2ivjNpnx78VaB4a8T6143ufAQ8baBdaJof9leHdEfwtBql94iu7jVor6VLAAT22YjYbvsZj
FxLMAy/P/j79lGf4C/Az43ad8IPg9pmu/Fnw5+0BeaANKvPBcPjHV9L8IGwlm0xlsb9LsxWsrncl
2IVab5QZ5hhU/Pb9nj9njxj+1b8YtH8A+AdH/t7xbr3nfYLD7XBa+f5MEk8n7yZ0jXEUUjfMwztw
MkgHiq2ljuaClOH2pO/m731turp79tDOnhuV8vNfRaW+7rtoz9O/htH44+CP7HH7fHjPU/hx4C8B
Xh1TwppbaRpmkWut+EbbU01RGvbO3juGvbJpIVuo3kt97m1e4QKkOxFT5a/4LEfCzQ/gt/wUw+Lv
hvw14VXwVodhq6PZ6QiRxwwJLbwzeZEkckiJDKZDLGgKhI5UXy4ceUnjXwQ+AXi79o3xbc6J4O0g
6re2GnXOr30klzDaWmm2VvGZJ7q5uZ3SG3hRRzJK6rllXO5lBx/iN8PtY+EvxC17wr4hszp2v+Gd
RuNJ1O0MiSG1uYJWilj3ISrbXRhlSQccEjmsa9aU6NuVqN9G9esnbZLqr2tte3bWnRUal0/l9y/T
8T9E/wDgmj4B/Z88Hf8ABNmDx78dvBPhrUfDXi74yTeCfEHiLULG/nv9O0638P8A9p20djLaS+db
ym9SNHaGJS8dyyyM6bfJ90+Fn7N3gbxj480j4v23w68BNF4nufBNx4t8F2Phvw/Y+GvCWjTeGItX
1DxBO+pxXrQacWa6gxALAO1qyCeW4ww/F+iqo5gqcYQ5E+V383vo32V9P16TUw0pTc1Lfp06efkf
p14D/ZUh8A+Gv23/AAzp3gj4eaN4h+CvjXS77wEfG+n6TCNJgvNSntP315q48qe0l03yzFFeSyQs
8kU0SmZkkPzN+01rnw81T/grdql18KtJ+HeleA4vHlnFp1rrjI/g+R454UuJZ/Lkkj/smW4WaQiN
ggtpMKqLhF8t+Gn7Yfjz4Q/Anxb8NdBvPD9v4P8AHZLa7a3HhjS7241DCqqbrqe3e4URFQ8QWQCG
QtJHskZmPmFRUxUXFKK63/F6L5PXRbLTQuFGSk3N3v8A5K/5efqdn+0a5k/aF8eMU8GRlvEWoEr4
Qx/wjy/6TJxp2Mj7F/zxwf8AVbK+3f8Agg3Dd+I/D/7SWm6X8J9N8ZX8Hwh8R/8AExWDVp7rVJLh
LVYNDdbe6SLy7gwTlBDGl27GTbNtXav5312PwQ+AXi39o3xfcaH4P0oane2VhcareyTXcFlZ6bZw
Jvmubm5ndILeFBjMkrouWVc7mUGMHWlCupxjzPt3v8v0HWpc1JwvY+6/+CH99J49t/2o7fQfgroO
uXE/wo8TSwy2Ka3cSSG6FsLbw8At4QYJfKm8sKv26Qq4FyQp2p/wRI1M+PI/2oo9E+CHhvXXk+Ff
ia5R7Qa5Ox+0i2+zeH1C3jAwSGGXywo+3OVfFyQpx8YeFv2O/iP4z+O3if4baf4d8zxd4KbUf+Eg
glv7WC00RNPLreTXN5JItrDBEyEGZ5RHkqAxLLlvhX9kL4h+NPjj4l+HOnaAknirwY2of2/FLqNr
BZaKlizLdzXN7JKtrFBGyFTM8ojJKgMS657KGIqx9l+7b5W1tu3023XbX0MZ0Yy5/e+JL8Ou/wDk
fZv/AARR1U+PIf2noND+B/h/Xp7n4YeI5oDYprly8huja/ZvDyhL45t5BDN5YUfb32yYuGCna3/g
ibqieNrf9p2HSvgpoeuvL8LfEk8T2Ca1cSTNci2+y+HsLe4NtIYZSgQfb32SYuWVSB8aeHf2QviJ
4q+OPij4c2Xh7f4s8ENqA8QQy39tDaaIlgzLeS3N48gtooYmQqZXlEZYqAxLqCnhb9kT4h+M/jj4
k+HOn6Aknivwa2oDXopdRtYLLRksCy3c1xeySraxQxshBmeURklQGJZclDE1YKl7j91tbbt9Fpv9
/wCRUqUZKXvb269uu59m/wDBEy8l8fwftOQaF8FtD1yZ/hf4juEewt9avJLj7V9mFt4dAW9I+zym
KXyyg+3ttk23DBTtd/wRH1SfxrB+09D4f+Cega/cS/C3xJKj2UWuXUkwu/sy2/h4BL3HkS+VN5e0
fbn2yYuCFO34u8K/skfELxp8avEvw907w/5ninwZ/aDa/FLfW0FposdiWW7mubuSRbaKGNkKmV5R
GWKgMS6gyeE/2QPiJ43+OfiX4cab4fWXxZ4NOof29FJqFrBZ6KlgXF5Nc3ryLaxQRFGBmeURklQG
JZcujiqtP2V6d+Vtbbt9Nt/LX0CpSUua8t7fh8z7Q/4IkavJ44i/aij8P/BDQNduJ/hb4kliawj1
y6eT7WbVbfw8Al6c28gim8vaPtz7ZMXLBTil+zgj/E7/AIJFeKYPCXwstfi1rMnxxGpz/Da0i1G+
svDVi+iS+Tfxx6fcx6uFLeZbiS6uZYCsIABmErt8d+Hf2QviJ4q+OPij4c2Xh7f4s8ENqA8QQy39
tDaaIlgzLeS3N48gtooYmQqZXlEZYqAxLqDsaX+wT8UtQk8XG40PSdCtfAviCTwprN/r/iTTNF0+
31aPzS9il1eXEUE86iCRikLuQoDdGUmIVans4RdNtLmW29+m3Ttr6A6Ubylzb2/D5/5H6heC/jj8
LPCf/BUXxX8PPBUfxF0D4y+MfjhZSap4k8NaDpeqpq/h6JLCa40d5ra7hNjbm/hvZ7maKFrgwIBe
CaRZkXJ/ah8DyXn7L/x88GeFPhDffGrxdZftQap4gv8Awzf6PqUd9ZWN9oySW+o/Y9JvkuRa+aLh
Le5dvInimDhVZgkf5X6H+y74/wDE/wC0Y/wl03wzf6h8RItWn0R9GtmSaRLqBnWYGRWMYjj8t2eX
d5aojOWCAtW5qn7DnxM0b4Z/EbxfcaJpq6J8Jdb/AOEd8Wldf06S70a9M626o9qs5uHjeZiiTRxt
E5jl2u3lSbd55hNxd6X2pP0undbW0vd+i0IdCz5ufou3fTtufpd+zTqvwV/ZR/4KEan8CfhNYfEr
w78R7z406ekmu6Fp1r4j+2+GLdLG4uNAkuPtyS2Vol7FeSXMqRvOLaFY7oSmOSNZ/wBnbwjd6L/w
UD/4KBeH9K+DUvii9Xwv40vPtmo6Pq1vqWotqMkElvonk2t6YTaXBEr28kMaXdxH+8SWNG2RflH8
C/2ffF37SfjOfQfBukrqd/Zafc6veyTXkFjZ6dZW0Zknurm5uHjgt4UUcySuq5ZVzuZQdSx/ZL8f
337TrfBttEhs/iOurvoP9k32pWlmrXysVEAuJpVgJdhtjIkIlLIELl1yoZi21KFLTmdred/dWluv
5aEVMMnKXNPVxV/l13Wn9XPuL9k668O/Fj/gk81pZ/A+9+MFxo/7QV54i1v4e+FL+/Se20i58NPB
atvga4voLaG5B8uaXeHMJRpHPmV9B/GjwzoOq/8ABOj4deDLj4C+Kfiz4z8A+L/C0/j7wJpV/c2+
tXMb/Du0tbea5jtfNvLFIp/Li/eQoGe0dByzBfy50n9gD4qandeMEuNE0XQrbwH4hk8J61f6/wCK
NK0TTrfVozLvsY7u8uYoJ51EMjFIZHIUBvuspNlP+CdfxXV9XkutL8LaXpuiy2NvPq+p+NNE0/R5
5b2yW+tore/nu0tbmR7V0m2QSuyo6lguRUUcTUjTjH2bdnvZf3tPhfno7rR6as0lCLk2p/j6eZ+m
/wAaPCWj3f8AwTj+G/guX4E+J/in4w8DeL/DVx8QPAGm39zba3d+Z8PbW2tLi4htfMvbJIZQsfzw
xq72zoCS7Gviz9vDUfhL4F+I/g7w/wCPvhZ8Tx4+0L4c+EtP119P8a2eiL9oj8P6eqxzWU+l3csM
8SgROHkQny1/dxkFn8YT/gnj8Vl/teW60rwzpem6LPY2s+r6n4x0XT9HnmvbRb22jt7+e7S1uXe1
dJtsErlY3VmCgivOfjB8INe+BPj658M+JYLCDVra3tbsiy1K21K2lhubaK6gljuLaSSGVHhmicMj
sMOOc5FLFYqo4e9TtaT1aW95aO8d9er0s9LtlxpLn1lr5advM+iP2BbDVJ/2oNc8b/DSYfDj4S+E
9PWTxxqHjm5j8Q6TZ6HN5cNxZaksVvbJqQvJN0cNlHCssrtGEw0RuE+j/wDglprfgz4hfEz9reP4
S/AibUfBs3w38SPog1OXV9R1i4juRapZ6DKbW5WERzvDK8caKb3HmRi8n8ve35t6J8OfEPibwlrm
v6boOs6hoPhkQHWNStrKWW00kTyeXAbiVVKReZJ8ibyNzcDJ4rZ+B37P3i79o/xdc6J4O0j+1LzT
9PuNWvpZbqGys9MsoF3TXV1dTukFvAgIBkmdE3Oi53MoOeFxk4SglC+rfrfTTTT5Lf0VnVoqSd5W
6f8AD+Z9x/8ABE28uPHtt+0/F4e+Dnh/Vp5PhX4klSSzi1q5kuPtZtVt/Dq7b0r5MvlTeUFH26TE
oFw2Btf/AMER5bj4jw/tO22gfBvw/q7v8LfEl1vso9cuZLsXH2b7L4bUJekGCVoZDHtAvn2SYuW2
4Hx5pX7EXxT1b48eIvhoPCF3aeMfCFvc3mu219cwWVto1rboHlu7m7mdLaG2CshFw8oicSxbXbzE
3Lp37D/xU1L4+eJPhl/wiN1a+MfB0Fzd67bXt1b2dro1rboHlu7i8lkW2itQrIVuHlETiWIq7eYm
7SjiK0PZ2pt8rfTdvpt07a+hNSmnze8le3yt8z7E/wCCJV/P8QY/2oIvDvwS8Oa3NL8LvElwhsl1
24klF19mFv4dTZekGCTypfLAH26TbKBctjAh/wCCK+tS+Nrf9p6HQfgl4e1s3Pww8Rz7rKPXrlpF
uTbG28PDZfEfZ5DBIY+Ptr7JMXLbePkOy/Yb+Kt78f8AxL8L28H3dn408GQ3V1r9rfXNvZW2i21s
oeW6ubuaRbaG2ClCLh5RE4li2u3mJuLL9hv4q3vx/wDEvwvbwfd2fjTwZDdXWv2t9c29lbaLbWyh
5bq5u5pFtobYKUIuHlETiWLa7eYm4oYmpH2X7tvlb+bfTbddtfQUqcG5e9vb8Pn/AJH13/wRV1f/
AITj/hpqHRvgvoesPdfDDxJJCNPj125a5a7Nt9l8OYS+5t5DBL5YAN85WTFw+35T/gilqUnjqH9p
m10L4M6LrMt18MfEcqNp8GuXcl2bn7Mbbw5hL3H2eUwSlNo+3PskxcMF+X5Esv2GvireftB+JPha
/hC5sPGvg6G6utdtNQu7exttHtraPzJbq4u5pEtorYIVZZ3lETiSLY7eYm6PTP2Jvijqfx68QfDP
/hErqz8ZeEoLm71u1v7q3sbbR7a3TzJbq4u5pEtorYIVYTvKInEkZV28xN1UcRWh7Jeyb5G+m7fT
bddtfQqVOMlK0t7f8OfX/wDwROv7nx1H+05DoHwX8P660/wu8Ryf6IutztP9qNr9l8PLsveYZGhk
8oKPt0hWQC4bb8s37N9vN8Sv+CNPiOHwr8OdO+MOryfHd9Qk+FtrFqV7B4Vsm0I+XqqR6fcR6qI3
bfaq91dSwEWxAXzRJI3yBpP7C/xX1j4/+JPhgvg+7tfGfg22ur7XrW9ureytdGtLaPzZry4vJpFt
orUIUZbh5RE4li2O3mJu3bv/AIJnfGvQ7zxTHrvg+28HQeDdbHhvVL7xVr2m+HdOXUjD9oW1hu76
4hguZDAVnAgeTMMkUo/dyIzZqtVUIQdN+65J6bt9Nunb8CZxptyTktbP7uu/46H6kaz+0b8ONI/4
KzeLPA3g/V/iLc/G3xn8ZNGfUvF3hrR7PVIdU8NW9npUkvhyWSO5t5LK3gvILv7VJFE0ghtFS4a5
KuV4AfBv4geDNK/4KP6h4I+H/jDxHeav420b+w4tY8CR6lFqk/8AbLX11EljPHcQXix213HOrbWP
kS29yY4vMTZ+ZP8Awx58Tv8Ahp3/AIUz/wAIXrX/AAs/+0v7K/sDyx9o8/G7O7OzyvL/AHvnbvK8
r95v8v5qv65+w98TPDnw9+Ivie80PT4tK+EuuHw74uUa9p73miXouEtgslos5uGjaZ/LWZI2idkk
CufLk29FXHVJxcXSatKT0bVtG2tt1e7fZaoSw8VopdF+FvzP1C8A/Dvwp4M/4KFftw+CfhJ8H/Ce
u6Fpvw81qOK40xdTumuLu5sLAyeHRHa3K28Ky3kV4Ft4IY7tJFlhjkRYhHH8wfs4/DlPFv8AwS18
Q+OPg/8AC/wx4q+N1x8ZW0/U9ItPCcHjW60bwy+lCe1SOxvkvXt7UXnnItyyb5iojeaUx7R8a/A7
4A+Lf2j/ABjPoXg/S01K+s7C51W8knvILGz06zt4zJNc3N1cPHBbwoo5kldV3Mq53MoO0P2O/iPF
+1EvwYuvDv8AZfxKfUhpKaPqV/a2AluWXdEizzSJAwlBQwsJCs3mR+WX8xN2M8XOraUKdlzStbvL
ZJ20a6b97IpU1FcrlrZb+XV+p9wf8EoPhP45b/gvZp+p33wy0fwtP4S1PU/+En0zwdF9q8PeFrqb
SL5BAZYpbmG13zhl8oyhY5d8SiPy/LTlfgv+zPr3w+/4Jga9d+FPhE2t/tJ6b8W00zxDpOp+CIPE
mtaR4abRI7i0aXS7yCdrOGS6klK3Agj84/L5jiNVX4+8OfsrfEHxf+0q3wf0rwvf6l8SE1qfw++i
WzRyyJeQSOk6GRWMQSMxyF5S/lokbOzBFLDZ1T9hv4m6P8N/iP4suND01dH+EWsnQPF+zX9OkvNE
u/tMdqA9qs5uGjaeQRpMkbROyybXbypNqWIagv3b0lJ3v3S02smrX+/Ts+WKk3zLVR/N269b2/zP
vLVfC/ijWf8Agnb8QPC8fwa8I+OvG2mfHuW91r4SeF2uNT0jwaX8Pxq+pQR6Pefb4TJKskLrLdPZ
xvbmKOGJ4pVX5l/4Lm31jf8A/BVr4wNp3iQ+KrWG/s7cXxkt5PLePT7WOS1zAiJ/ozq1tgjzB5GJ
GeQO7fOfwa+DXin9oX4oaL4L8FaHf+I/FHiG4FtYafZpuknfBZiScKiKqs7uxCIiMzFVUkUfiF4C
1b4V+Ptc8L69afYNd8N6hPpeo23mpL9nuYJGilj3oWRtrqwypKnGQSOaivinUw/KoNLm39OZ22Wv
vf5JXLVNe05r9NvW2v4GPRRRXmG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQB92/8G0H/ACmv+Dn/AFw8Q/8AqO6nX9Zdh/x6R/7v9K/k0/4NoP8AlNf8HP8Arh4h
/wDUd1Ov6y7D/j0j/wB3+lAFyDqaKIOpooA+OP8Ag6O/5QUfHP8A7gH/AKkOmV/OH/wRq8S2a/Fb
4xeCjqFlZ+I/i58IvEXgbwrb3c6W8eraxeLAbWyEshWKN5jEyIZHRS5RdxZlVv6PP+Do7/lBR8c/
+4B/6kOmV/JR8Gvg14o/aE+KGi+C/Bei3niHxP4huBbWFhbAb5WwWZizEKkaIrO8jlUjRGdmVVJH
RhakqdaMoq77d76f8MZVoKUHFux9p/skWQ/Za/4J2fErxT8cNAn+Ifwrn+IUfgiH4RXl3Ppl3YeL
IIYbqbVZZsCbS2js45bbfbhpbht0MyrHGDX1DeeDPEHjn4Qfth+JfDXgKf40+G/iHoXw71Hwf4XX
w9e2qadpjyR3Vpob2ukTRGOWwsJbVylrMcotvM/yzOh/KjxL+yr458J/BS++I11pVlL4H07xbL4G
l1iz1eyvbZ9XjgNw0EZhlcyp5I3rPGGhYEbZDkV2vhT/AIJq/F/xh4L1DxFBo3hex0XSLLTdRv7v
VvGuh6UllbajbQXNjPL9qvIzHHPHcxbGYAM++P8A1kciL10sRUUFR9nf5a7S8td7632drXZz1KcH
Jyclf/hn38vxV9kfozL4h8O/s/f8E2fiH4Q+MXg/S/CHgr4j/tQ32h+L/DWjarb3D+AdMvtGsNRg
uLK509HjaSykhtnEQieOQWTw+SjFwvkX7S3gG/8AGn/BytqN94f1OfxLpXgnxhofivXtbuZ7VLbQ
dM0+DT7i+nuZwIoIoLNUeLdIQf3SKzSStl/i/wCPn/BP74ufsweD9V1/xz4UTRNJ0TxKnhC8nGrW
N15WqPYR6gtuFhmdmBtZY5PMUGMbtpbdlabdfsC/Fmz/AGhvEfwnbwtG3xG8LafJqd7oMerWMl1N
Elulyy2oWYreTeQ4kEFsZJWUNtQ7Gxv9dquMKLpt2kmu+8nbbu3bTvZa6CoJNz5ulvLprb5d+pk/
tqfETSPi9+2R8WvFnh+8fUdB8UeM9Y1fTbpomha5tri+mlikKMqspZHU7WUEZwQDxXmdFFeRUm5y
c31OuMVFKK6H2b+xLc/FL4i/sV6/4FHwXuvj58D08Ytqd1ovhy/aLxR4Z16bSpbeLUYFszLdRRtE
ExJeWdxZO1o0agSeZX0V+yP4f079jL9tD9rb4C+A9f8AC3jaw034beJz4Pkn8M6Pqmta7qz2llIu
kNMbeSW9MSpNFLZAmB5LWdzbqS6j8/8A4F/sT/EL9o74c+IvF3hWz8MyeG/CMsUOtX+q+LdI0aPS
zMypC03225hKJI7hEcja7hlUllYDjPjB8IPEvwB+J2teDfGOj3Wg+JvD1y1pf2NxtLQuMEEMpKuj
KVZJELI6MrKzKwJ76GJdKMJuD0e+2mt0nbr5329Ucs6EZylHm36fdvv+SP0t/wCCcH7FEfhW68U+
NPiNpHgjxb4itPixa+GvHvhO1tPCVxpfgHSI7STUr3W76WazvLezsAPtEHk2psgHtJYVmEsaRx8/
oP7OkPw3+B37dVz4X+GGg6pZ/An4gxzeAtS1Dwdba4+nRrqc9nfQtPcwy/bLePTDFK8N0ZoocLch
EkPnV+Z1FSsbFQUIx2bd766q3b0+aurDeGbm5c29tLdv6f39T9D/APgkt+07q3jb4n/tKabpPhn4
caTqPjT4aeLtY8P+G9L8G6bcNe6rKttImmWaTxyXNxahIXdNO3ywBYnbySA5r4i/aE8CeJPhn8bf
E+ieMLXRLDxTZ38h1W00iWweytLhz5kkMYsSbWPYzFTDFhYWUx7UKFF42uy+Dv7P3i/4/wD/AAlX
/CI6O+sf8IT4eu/FetbbiGH7Dplrs+0XB8x13hPMT5U3Oc8KeazlXlVpQoJNuN/x127+ZrGnGEnP
0/q59Lf8EFPhrZfF3/gpl4M8Pa34S0fxj4U1Cz1Aa7aaroFvrFpBbraSNFM6zxusOLsWqiUbTlxH
kiRke7+x/wCGT4Q/4J5ftRaxrXgzww3jT4Kax4cv9Gl1/wAIWF5eaPe3t9Lpt7BcC6gdpozCCotL
kPFHKplREmXefiqu+8HfsxeNPH/wF8X/ABM0fTbK98G+ApraDX7pdWs1udNNzLHDAzWjSi5ZJJJF
VXWMoSH5+R9rpYpxhGCjdx5nf1il/wCS2b/y3JqU7tyb3t+D/W9j9W/gx8G9D+HP/BQb9vHwV8MP
hXoPiPQtL+HWvRQTaV/aN4J7m6tLOT/hHALO4igjSa4jugLeGJbpGt5IkkCxMo+XP2bvhw/iD/gl
/wCKfiF8I/hn4T8VfGG7+MK6Vf6PbeFYPGt1oPhxtJkuLdUsL+G8e2tTdGVFumzJMYdjSExHd8d/
s/fs/eLv2pfi/o/gLwHpH9u+LNfaVbCx+1Q2vnmOF5n/AHkzpGuI43b5mGcYGSQK42uirjudRk4W
inLbTV66O32brv02M4Ydq8ZSu/dvp2+fWx9fftx/Dzwh8Nv+C0Wv+HvAlr8NNL8MWfjrTkt7XWbt
J/CdlK72zXEV8Y1VIrNJ2lWeFBtgRZYhkRg185ftDqE/aA8cgN4OcDxDfgN4Sz/wj5/0mTnT88/Y
/wDnj/0z2Vx1FcdfEKo5WVk23btfodFOnypK+ysFFFFcxoFfod/wQdhuNd8O/tL2Fj8LLDxlcxfC
HX0+3LBqs9zqs1wLVLbQnW2uFi8u4eKRlEUaXbNG+yYKpUfnjXZ/Av8AZ78YftJ+LbzRPBmjnVrz
TdNudZv5JLmGztNMsbaMyT3VzczukFvCgwDJK6ruZFBLOoPXgarp14zUeby7/g/yMMTTU6bi3bzP
t3/giU9x48n/AGnxoXwh0bWTP8K/ELxpaR61cLO1ybf7N4eHl3R3RT+VKIxkXrmM7bglTVj/AIIh
X1x42T9qNNB+C+j6+0/wp8RsgsF1ydpjdNai28Pjy7s7oJTDLsUYvZAkmLg7Tj4+0n9h34q6t8fP
Efwy/wCEPvLHxn4Ot7q91601G5gsLfRbW2TzJbq5up5EtobYKUIneQRP5sW1m8xNztG/YZ+K+t/H
3xJ8MV8HXtn408HW11fa9aahcQWFvolrbR+ZNd3N1O6W0NsEKsJ3kETiSLazeYm7toY2cVS/d35X
L5t9tOl/P5GVWnCSneS1t8rfM+vv+CJmp3HjgftQx+H/AIJ6BrzXfwu8ROq2UOu3Zk+1G2+zeHlE
d4f3MhhkMf8Ay+v5T7bk7eJf+CIerHxpF+1SNG+DGi6yZ/hR4kmj/s9dcuGkN01sLbw8Nl6c20vl
SlAP9NcRyYuG2nHx1pP7DvxV1b4+eI/hl/wh95Y+M/B1vdXuvWmo3MFhb6La2yeZLdXN1PIltDbB
ShE7yCJ/Ni2s3mJuTTP2IPipqfx68R/DI+D72y8ZeD4Lm81601C4gsbfRba3QPLdXN1M6W8NsFZC
J3kETCWLa7eYm5UMXNKklTvyt/8Ab1+i03XzFUoQlzLm3t+HzPsD/gidrf8AwmMX7UkejfBjQtZe
7+FniOSEWMet3JlNy1sbfw8Nt4wNvIIZimP9Ofyn23Py8M/4IlSTfEM/tPQaF8GdB12Wb4WeI54/
sket3DSm4Nsbfw+vl3bZhm8iURgYvX2yYuTtwPj/AEz9if4pap8c/Efw3HhC9tPF/g+2ub7XbW9n
gs7fRrW3QSS3dzdTOtvFbBGQid5BE4li2s3mJudpP7EnxT1j47+IvhqvhC8tPGHhG3ub3Xba/uIL
G20a1t0Dy3dzdzOltDbBWQid5BE4li2u3mJuKGLqwVLlp35W+m7fRadPn8ip0Y++1K17fK3zPr//
AIIpX83jxP2o00H4M6FrLXHwt8QyRrYrrdwZjdSWn2bw8oS8O6CUwyCMD/TX2SYuW28J+zib34m/
8EfPFMHhb4X6T8XLo/HP+03+Glp/ad9D4WtZNFZU1FIdPnj1VYmb/RVlu7yaBvJ2hPOEkj/IWjfs
QfFTXPjt4k+Gsfg+9tvGPg60utQ161vbiCyt9GtLaPzZru5upnS3itghVhO8gicSRbGbzE3bc3/B
N/4y6UfFba14TtfCVt4K1tPDerXnijXtO8P2cepPE0y2sNxfXEMVzIYV87EDSfunjk+5IjNNOvUc
KdNU27c2y3vv06fP0CdOF3eW9v636n6g2X7TXgrw9/wVr8a+CNOu/GsHxo8VfGvS3vfF/hK2tfEc
Wq+ErSGwceHp5kltXsoI5LeR7x4YZJEjtmiuGu/KZ24bRPhB8T/Dlj/wUqvvDPw41zXtfvviDp0W
g2Vx4HGu2mqP/wAJBPcyiOzuIJoZytldQ3ABjfZHPDMNuY3P5mxfsifEuf8AaXX4Op4N1lviW+oj
S10ERr55mI3Z3Z2eV5f7zzt3leV+83+X81XNS/Yt+JOkeBviP4jn0G1XS/hFqw0TxeV1ixe40S6N
ytqqvAsxmZGnby1lRGjYq+GOx8aSzCdRPmg3rJ3vrqn5bq7bf4Gf1RRd1Lol9zX57WP1D+Bnw/0X
wt/wUC/bm8IfDT4LeCNS0jR/h74kii/4R291jV4b6S5tbIJ4fJtZ4oY1nniuW+zQxR3MM3nwRzst
ugHl3/BJfwRp3iP4E+DPHHw9+G/hXUviVL+0lpFp4iNlpS+I77wr4RNvFOrJb3aXU2nWkdwZtmog
rMzRFWnZoRj87Pgd+z94u/aP8XXOieDtI/tS80/T7jVr6WW6hsrPTLKBd011dXU7pBbwICAZJnRN
zoudzKDR+MHwf8TfAH4na14M8ZaLe+HvE/h25a01CwulAkgkGCOQSrIykMrqSrqyspKsCZePleFV
0/dTk+i31smktvn6FfV01KDlukvu+fX+rn66fGXw1caj8EfjD4W1f4J6z8abzRP2vPEXijW/h9pN
5e22tXWmX2hzLY3rraRtdwWbOyzQ3Ozy59pUHGc7HxtS68Vf8E2fhr8P9Y+CF98Xda+HHi/wzL4l
+HmiX15D4jaBvh3a20c+oQ2iveWAiu8qu+MCRrZl4+bP5NfCj9kXx58Zvh1f+MNI07SLLwnpuoJp
Euta94g07QNPkvXjMotYp76eGOacRje0cTM6IVZgAyk7tl/wT6+Ktzp+r39xouhaRo2i3ltp82s6
x4q0nS9Iubi4tBewxW19c3Mdtds9qyTgW8kn7uWJ/uyIW1hiarjFxpN6tp2vde9/d1tfzWj01Yvq
0Fu1pb8Lef8AwdtT9SPjVoreIf8Agmj8MfA+ofBS/wDi7q3gHxd4auvFPw80LVbiLxJPG/w8traK
4v7azjku9OSG6VkHmIvmm2IIG8mviT9uy6+G/wAOviR4N8O/FH4X/ECTxnoXw68I2V22i+OLPRJE
C6BYZivbOfSrqWG7jk8yNg7ofKSAeWMb5PGP+HdfxZgtdWvLzRfD+kaPo91a2Mmtar4u0fTtGup7
mzF7BFa3890lrdu9qyTYt5ZCI5I2OA658z+Kvwp134K+NZvD/iK1t7XU4YLe6xb3sF7BNDcQJPBL
FPA7xSxyRSRurxuykMMGscXiKjhrT5VzN3aXeWl+VX/SzsldlQoR5tJfd/wGfSX/AAT2ttWP7VOt
+N/hncn4bfCPwrpyv47v/HN1H4g0m20Gby4rqx1JIoLVNTF5IGjhsY4klmdo1QhojcJ9C/8ABLfx
J4L8d/En9rhfhV8DJbvwZcfDjxLJoianc6vqGrXEVyLYWfh+ZrW5SExTNBLIiIn2zCyKLuYx7z+b
2ifDvxB4l8J63r2m6FrOoaF4ZEDaxqNtZSS2mlCeTy4TcSqpSLzJPkTeRubgZPFbPwR+AXi79ovx
Xd6N4P0g6pd6dp1xq9/LJcw2dppllAu6a6ubmd0ht4UGAZJXVdzoudzKDGDxk4Tgow5tW7dXdWst
Hb5Lf0VrnQjK932X9eZ9w/8ABFfWJPGem/tQQaJ8GPD+sPcfC7xFKJbNNduJJftRtRbeHh5d4V8i
RoZDHx9tcpIBcNtwF/4Ioai3jqL9pu30X4L6Lrs1x8L/ABHLF/Z412eS6a5Nqbbw9iO7YNbyeRMY
1AF6+2TFydo2/INl+xF8VL348eJfho3g++s/GXgy3urzX7S+ngsoNFtbZA8t1c3Uzrbw2wUoRO8g
icSxbWbzE3NsP2Kfijf/AB28RfDU+Eruz8Y+Ebe5vNctb64gs7fSLW3j8yW6uLqV1t4rYIVYTtII
nEke1m8xN2+HxNWHsrUm+Vy6bt9Nt1219EEqUZKVnvb+tz7F/wCCJN5L8QLL9qG20H4LaBrc03wt
8RTo9kmu3Elx9pa0+zeHQI7xgYJTDL5YAF6+2TFyQvDv+CJmsS+Nrb9qOPQPgt4f1iW4+F3iKVDY
pr1w9x9re0W28OL5d8QYJTFKYwB9uk2SAXDAcfHVl+xF8VL348eJfho3g++s/GXgy3urzX7S+ngs
oNFtbZA8t1c3Uzrbw2wUoRO8gicSxbWbzE3LafsP/FW6+P8A4l+GDeD7208a+DILu716zvbiC0t9
GtrWPzJrq4upXW3itgm1hO0gicSRlXbzE3TQxNWHsv3bfK5dN291tuvn6EToxlze9vZ/dbz9D7B/
4Ipa7/wmNp+1Eui/BfQdWkm+F3iOaJ7Aa9OZvtbWq2/hz93ekG2kEU3ljH21yj4uW24Cf8EVtYXx
xYftSRaR8G9A1J7j4W+I5oXsE1u5edrprUWvhwBb0g28hhlaMAfbn8uTFw4UgfH9n+xB8Vbv48+J
fhm/g6/svGXgy3ub3X7S/nhsoNFtbdBJLdXN1M628NsEZCs7yCJxLFtZvMTcmlfsRfFPVvjx4i+G
g8IXdp4x8IW9zea7bX1zBZW2jWtugeW7ubuZ0tobYKyEXDyiJxLFtdvMTc6GIq0/ZXpN8jktt2+m
267a+g5UYPmfNvbr2sfYP/BFPUJPiBb/ALUMPh/4N6LqlxcfC3xJLAdNGuXElwbtrQW/hwBL1g1v
IIZzGoH219kn+kNs+U/Zvt734n/8EcfEdv4T+Gem/F+/X46tqk3wytF1K+i8L2b6GRHqaw6fNHqq
xM262WW6vJYG+z4CeaJZH+PLD9in4o3/AMdvEXw1PhK7s/GPhG3ubzXLW+uILO30i1t4/Mluri6l
dbeK2CFWE7SCJxJHtZvMTdvL/wAE4PjJaXPihdX8K2XhO38Hayvh7VL7xT4g03w9p6ai0RnW1iur
64hguJDABMFgd8xPHJ9yRGbONWt7OEXTdouS23v026dtfQc6cdW5Wvb8PmfqZqX7SfgfSf8AgrX4
w8BeHb74hP8AG3xh8YdIOseLfCuj2WsHUPDVpZ6ZJL4beSK5gayt4Lu2uftU0UTy+TaBbk3OyQVw
998HfiT4Ok/4KTaj4N8AeKvEGpar440ptJttU8Bx6rBqk51pry7jjsriK4hu44re9inRtjN5M1rc
lIt6bfzB/wCGQ/iX/wANLf8ACnv+EO1j/hZX9of2Z/YWxfO83bv3bs+X5Pl/vfP3eV5X73f5fz1y
PxG+H2sfCX4ha94V8Q2Z07X/AAzqNxpOp2hkSQ2tzBK0Use5CVba6MMqSDjgkc1tiMfOSbqU2vel
rdrV3utVur/8AzjhUpXTWyW3a3nt0P2D+F/w78I+Ff8AgoR+2/4Q+FHwZ8P63oWi/DjWkibQ11a6
Nze3Njp4k8OsltdiGGGW8ivf3EEaXSOs0UcqpEqR+Wf8EmvhvpHi/wDZ+8DeOPh74A8LX3xRl/aY
0mz8RCy0keIr3wn4QNtDPHIkF0LmWws47g3G2/3JKWhw07GIFfgH4TfshePfjT8Pb3xdo+maVZeE
rDU49Fk1zXte0/QNMe+eJpRaR3N/PDFLOIlMjRozMiFWYAMpPT3f/BN74yaJqXim31zwrZ+EU8Ga
0vhzVLvxRr+m+H7FNRaPzhbQ3V7cQwXEhh2zAQPJ+6kjk/1ciMzeNqTlCpGlonJq3m27J26a/wCW
g5UlZw59bL8O+vU/RL4B/FTw18Iv+Clvj74XW+i/E7wT8dPGv7RNzqOpeINE8Opevq3g0XsN7Fpj
tJdQS2dlKyPeT3MEJD2oQuJohsEc3wW+JXhFP+Cjt34G8BeLfFeo6r430hdLh1jwEmprqtyNZa8v
I47GZbqC7WKK8imVirkwTW1yUi8xNv56XH/BNT406Re+Kotb8JWnhCDwZrY8N6pfeKdf03w9pyak
YjOLSG7vriGC5lMG2YLA8mYpI5B8kiMy6h/wTX+MOi2l/e6loGgaNolhNaW413U/F2jWGhX8t1Zr
ewR2mozXS2l47WzpKVt5ZCquu4LuGR4uq4cnsn8Tel76p6bbrf5bExpx5rqa2X4ddz9OPAvxB+A/
wB/4KZ6z8JPg/pPivwZ8Sdf+MGi3F7q3gXSYdZ0258ORWemXV9oDyNfRyafbLqcd/NeeREViigMT
rJFF5Mf5mf8ABUvwong3/go18a7SOHXoI5/F+oX6prGnCwucXMzXAIjDuGhPm5ilDDzojHLtTzNi
1Z/+CcvxbsI9Sub7RfDuk6RplzZ2T63qfi/RrDRLue7tFvbeO21Ga6S0uma1dJsQSyFUdGbaGGfO
PjJ8FvEfwC8bv4e8UWVtZ6kLW2voza39vf2t1b3EKTwTw3Nu8kM0bxurB43ZTnGcggY43EVKlJxl
TcVzt+Svf3dt1r92xpRoqNTmUr3S/DqcrRRRXknWFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAfdv/AAbQf8pr/g5/1w8Q/wDqO6nX9Zdh/wAekf8Au/0r+TT/AINo
P+U1/wAHP+uHiH/1HdTr+suw/wCPSP8A3f6UAXIOpoog6migD44/4Ojv+UFHxz/7gH/qQ6ZX84P/
AARv1zTZvif8ZfBU19Z23iT4s/CPX/BPhK1urhbaPV9buzbG1shK7JFG8pidUMrqrPsUEuyK39H3
/B0d/wAoKPjn/wBwD/1IdMr+Sr4L/BfxV+0T8U9E8E+CdEvfEfinxHci10/T7VQZJnwWJJJCoiqG
d5HIRERnZlVSR0YWrKnWjOKu+xlWipQabt5n2d+yNYn9ln/gnl8T/FHxy8I6n8QPhRd/ECDwTbfC
+8ln0maz8XW0cV1PqEl0VEunSRWKzWzfZw0sxlEc6IiIx+ifDfwb1rUvgx+2n4h8J/C/XPi34S+I
8PgTXfBugX3h/U4YpbO4eHUIdJjj06VJCdMsb60QxWlwIo44YMgRlY6/MTxH+yn478LfAu7+Jl1p
FrJ4DsvFsvgZ9atNVs7u2k1iK3+0vbxmKVjKvkkOJow0LAja5yK7nwv/AMExfjN4t8B3/ieLQfDW
n6Dpdhpmq3t5q/jTRNJS0tNSghnsbiQXV3GUinWeNUcgKZBJFnzI5EXuo4qpGKpuDdr276qS6p3W
u22jta7OapTjdyc0r/8AA8/T7z9DLLXdI/Zz/wCCeXxR8K/Gn4ZHwD4B+J/7TFz4c8VeH7W6lSTw
Jpt5pNrqUM1jPaq0Ur2TR2U6IkEkc0duEaPEse3yD48/DLUvGn/ByRq17pcGoano3g7xvpPjLxFq
F80trBo2j2Ysrq9vbma7kxBbRRg4dnSIgxLCFV4o6+QP2hf+Cdnxk/ZU8Gat4h8feDJPD+j6H4nj
8G3tw2p2dwItVfT4tSW2CwzOzZtJopd6gx4cLu3fLTLz/gnr8YLH9pDxF8IH8Hs3xM8L6fJqd54d
j1OykvZoktkuytqqzEXkxt3WQQWxklZQxVDsbFSxU5csXTfuyVu+8nbbq/LdOy10SpU03NT3XfTZ
a7+nXsYX7Z/j/Sfix+2H8WPFOg3g1HQvEvjLV9V067EcsYurae9mlik2ygSLuR1OHAYZ5AOa80oo
ryZy5pOXc7oqysffX/BNX4bS6p/wSt/bC1rW/AvjfxR4OceGDIdCl+wSXRsb97i7WK7e0uY1NvDN
DcTDy22QkM4UMrj2j9i7VvDP7avxL8cftI+KvDej+J7rxZ8VbGy8T+D7iLSNQsfAvhqGykupta1G
91mzvJEszEkkO2BrEM1syRyIfs8UX57/AAO/Yi+IX7RXww1/xn4XtvCj+GfCtzFa6xe6r4x0bRV0
x5SoiaZb26hdI5GcIkhXY7h0ViyMBxvxo+C/ir9nb4p634J8baJe+HPFPhy5NrqGn3SgSQvgMCCC
VdGUq6SISjo6urMrAn0aOJnS9nUlB8sdO173628336nLOlGblBy1f3208/8AI++fG/we+GfwG8Af
HHwRo+lfCDQPiLoPxwura9s/iAoDW3gBbS4Nu1o94WupInLbt2lE6m6mFkMjNbkfQHx6/Y88BeCl
+PEPgXwhYXfj3Tfi5Z2r6f4F+Den+Or/AEfQJvD8N1aoNJvroxWlq1xLchrqAr5s0GNoQxxw/lP8
Jf2tvHXwU8CX/hXRtQ0e88LalqMWrzaLrvh/Ttf04XscbxLdJb38E0Uc3lyMhkRVZlwrEhQBPoXw
9+JX7cnxE+JPiuytD4o1/TNL1P4g+LLrzrWy8m0ikEl5dhGaNCFaZSIoVzhsImBgaUsdFJRhC7u9
NdF72zv59ugp0pK7crLv93f0Nz/go/oWj+Gv26fifY6F4ctvB+mQa5KI9CgjtYl0dyFMlsUtbu7t
0eOQurJFNsVlZVjgA8iP6J/4IafF7VdD1L4++DtKtfDF9q2v/CDxNJ4e0648OadqGqa9q3lWxisY
TNC092jJG7mwzJDII3YwsQSPgqiuKjifZ1/bJdX+P9djWrR56Xs5H6l/8E5P2PLTwV4h8U+Jfibo
PhHxV4r0/wCLFpoHj3wpDZ+EpNG8BaPFay39/rF/NNZ3kFrZDM1uYLRrEK9rJCJhKsccWj8J/wBm
Hx58A/hV/wAFDPDfw6+FXiDUBp/jHRtE8KaZN4TfX7a6t7fWpZhElrdw3C3eywntpxvEjLHLDMSS
Ukr82Pgv+zx4x/aF/wCEs/4Q/R/7X/4Qfw5eeLdb/wBLgt/sWl2mz7RcfvXXfs8xPkTc5z8qnBri
q61jlCELQatzWd+6afTz/wCAjL2F5tqXbT01XU/Uz9mj4V+FfhX/AMHRUPhfwifDh8NWHiDVEgg0
KBrexs2fQ7l5rZY2lk8t4ZWkikVWVVkjkCRwqFiTiv2Gf2bdPj/4J8eM7u18HarffGvR/ikfD+u6
dp3wosfiH4m0fTI9MYxxzaTqMirZQG8FyrXKqknmwiNi+AI/zor0Hwh+y5428e/s/eLfihpGm6fe
+C/Alxb22vXK6xZLdaa1xLFFAz2bTC6MckkqqsixFGIkAb93JtIY9OV1T6zlo3opJbW2tbf/ACKl
SaWsuiWvf/gn6GX/AMLdEbxN8eoPB/wKl0nVLD4mQLLfeGPh/wCHPiTqXh61axkZ9Gm0CbU7iKwi
W53sby2bynlWW3xB5K2sfyj+0v8ADOD4Xf8ABWvVfDFufghDFpvj20tyIVmg8BwsbiEst1FLLM1v
aKzEXUAkZYMTxodiKB8wUVz1sXGaty9b+XpZJI0jSad7nZ/tHoI/2h/Hqj/hDCF8RagB/wAIeSfD
v/HzJ/yDieTZf88f+mWyuMoorklLmbZrFWVgr9EP+CD8Vz4k8LftLaVpvwp03xhex/CHxEDqSW+r
3N7qslwtqltobJb3KwiOd4ZHQRRLdsVl2TBVwv5312XwO/Z+8XftH+LrnRPB2kf2peafp9xq19LL
dQ2VnpllAu6a6urqd0gt4EBAMkzom50XO5lB6MFVlTrxnGPM+3f8H+RliKanTcW7H3N/wRI1E+PD
+1FFovwY0HW2uvhZ4jliSwj1y5e4a5Nt9l8OoEveYJDDIyAZvnEUmLg7Thn/AARQu5fiEn7UcGg/
B3QdVkuvhZ4jmiWxi1y6e4Nybb7N4cQJeHMMhikaMAG9fyXxcEK2PkCx/Yh+Kd78fvEXwwbwlc2f
jPwjDc3euWt9d29lbaRbW6eZLd3F3NIttFahCjLcNKInEkZV28xNxY/sQ/FS8+P3iL4YP4QvLDxp
4RhubrXbTUbmCxt9GtrdPMlurm6mdLaG2CFWE7yCJxJGVdvMTd30K9em6b9k3ytrbdvpto18zGVG
Lcmpb2fpbrufXn/BFS6uPiC37T0fh/4N6LrDT/C/xFMkenwa5dm5+0va/ZvDo2XhPkSGGQx4/wBN
fy3AuDjiT/gihezfEC3/AGpotA+C+h61Jc/CzxFLGLCLXLp5TdPai28PIEvTmCQxSGPg3r+U+Lhg
px8g2f7DXxWu/wBoDxL8L38H3ll408GQ3N3r9rf3NvZW2i21ugeW7ubuaRbaG1CsjLcPKInEsRV2
8xNxZ/sNfFa7/aA8S/C9/B95ZeNPBkNzd6/a39zb2VtottboHlu7m7mkW2htQrIy3DyiJxLEVdvM
TcqOIr01TtTfutrbdvptuuwThGV/e3s/ut5n19/wRR1d/HEH7UMOh/BXw/rUl18L/EUsf2GLXrpp
zdPai18OL5d6R5EhhkMfH21zG4Fy2OE/4In6gPHX/DUI0n4N6Hqwl+FniS4jFguuT+e1z9nFr4d+
S9x9nlaKQxj/AI/pDEwW4YjFfIFn+xB8Vbv48+Jfhm/g6/svGXgy3ub3X7S/nhsoNFtbdBJLdXN1
M628NsEZCs7yCJxLFtZvMTcyx/Yn+KN78d/EXw0bwjeWfjHwjb3N7rlrfXEFlb6Ra28fmy3VxdTO
tvFbBCjLO0gicSR7WbzE3VQr14ez/dN8rktt2+m2jXzY5UYy5rS3t/W59f8A/BFK/Pjq1/aeh0b4
M6TrLyfC7xHcI+nR63ctObg232bw6wS9wbWXyZSmB9uYo+LhtuA79mrT9T+Kv/BHrxNb+Evhxpfx
hvG+On9ot8LLK21O+Hha2fRSF1RU0+4j1QQyH/RFe6uJYSLdto87zJG+QtP/AGHfitf/AB88SfDF
vB17Y+M/B0Fzea9aahcQWNvotrboHlu7m6mdLaG2CshE7yCJxLFtdvMTdvXH/BNT406Re+Kotb8J
WnhCDwZrY8N6pfeKdf03w9pyakYjOLSG7vriGC5lMG2YLA8mYpI5B8kiM2arVlThB037rktur6bb
rs7+gpxhd+/a9n93zP1Cvv2h/BGg/wDBYHxn4F0PWfHF38XvGnxi0RtS8VeF/D1nqf27w3a22nTS
+HZZIruF7OCG6glF1JDC0wiscXBuCJEXhZfhB8RtCb/gpBf+Cfh94r8T6rq3jrSG0m21T4frqiaj
ctrUl5cxpYTJcw3CxwXaSqzK5MMtvPsi8xdv5nH9jX4o/wDDUTfBYeCdab4oLqR0o+H1jVrjzgu8
tuB8vyfLHm+fu8ryv3u/y/nrjfiT8O9Y+EPxF1/wn4is/wCzvEHhfUrjSNTtfNSb7NdW8rRSx742
ZG2ujDcrFTjIJHNa1cwk4vmpuPvS2bVr301T1V/y0Jhh4prlkr2X4dfRn69/Cj4e+DPBn7fX7b3g
74YfCHw14m0PS/hzrC2s+iLqtx9qvrqy08t4caO2uxBHFJdx3o8i3jjulkjmjilVIgieF/sJfBnw
d8SP+CcXizxt4Z8Ii7+Kdz8WTYXOmeFPhnZfE/VdG0H+zBPbRjS9UuCbWxNy06rebzLI8HlO8uMp
8VfCj9kDx98Zvh3deL9I0zSrHwjaamuitruv69p+gaZLftEZvskVzfzwxSzrFiRo42ZkRkZgodSe
puP+Canxp0i98VRa34StPCEHgzWx4b1S+8U6/pvh7Tk1IxGcWkN3fXEMFzKYNswWB5MxSRyD5JEZ
iWMnPllGl7t5W/7ed9GkrNeXboOdOKTTnZu2/l5eZ+lfxu8N+DdZ/Zr8b+E/Bf7P2p/ETQvC/wC0
nPruufCHQNTQ6zpkE3hCG3Z520WW7+x266iZ9oiby0kgkt8RlHiSz8ZvDdxrP/BN34ZeDNX+EMvx
o1zwH4x8M3XiL4ZeH0uLHxHbWj/Dyzt0l1MWSNeQEXYbbJLGNwtxFkBTX5l3H/BNT406Re+Kotb8
JWnhCDwZrY8N6pfeKdf03w9pyakYjOLSG7vriGC5lMG2YLA8mYpI5B8kiMzp/wDgmp8Y9Psr+/1D
w/oWjaFYXNpZ/wBv6t4t0fTtBvp7q0F7BFaalPdJZ3btbMsu23lkKo6lsbhl/XKiXKqXV9P8Wnw9
L9dNHpqxKnDfnX9fP+u5+nHxq8IPff8ABNT4YeDNW+EMvxo8Q+CPGnhu88SfDLw+1zZ+JLK1Pw9t
LRX1RLIPe2xF5GxV5Y1JEHlcKBXxL+3ddfDX4ffEXwNoXxL+Hvji98V6N8NvCdleRaH4tsfD09g8
eiWaPbX9rLpN1Kt5HKswJkcN5RtwUXblvHJ/+CcHxfsNPv8AUNQ0DQtG0OwntbYa7q3izSNO0S+m
ubNb2GK01Ce6S1u3a2dJdtvLIVR0LAblz5t8Yfgv4k+AvjIaD4osIrHUHs7fUITBeQXttd21xEs0
E8NxA7wzRPG6kPG7L1GcggYYvFVJRu4Navez/m01Wu/3q+9y4UY83xX+b/zPob/gn5Bqw/ak1vxr
8OLl/hv8I/DNgP8AhO9Q8a3C+INJtdAn2RXNjqSwwWy6iLxw0cVlHEkkztGEKtGZ0+j/APgllr3g
7x/8T/2vI/hD8C7jUfCN18OPEreH4tTm1fUtWuYbk2otdAnNrcrD5cwgnkjRFN4CrKt3L5e8/mzo
nw78QeJfCet69puhazqGheGRA2sajbWUktppQnk8uE3EqqUi8yT5E3kbm4GTxW38C/2e/GH7Sni+
60PwZo51a90/TrjV7+SS5hs7PTLG3TfNdXVzO6QW0CDGZZnRAWVc7mUGcJjZQlBKF7Nu3e+llpp8
lr8lZ1qMZJtu3/A7/wBbH2//AMEV9Yn8bJ+05F4f+C2h6xJdfDLxFIraeuvXDyi7NsLbw4BHekG3
lMUgjGPtr7Xxctt4b/wRYv5fHZ/adTQvgzo2stc/DDxDJGunx65c+cbp7X7N4e+S9ObeUwyiMc3r
lHxcErlfkS0/Yh+Klz8ePEvwzfwdf2XjLwZb3N5r9pfTQ2cGi2tugeW6ubqV1t4bYKyETvIInEsW
128xNxZfsRfFO8+PfiD4ZP4QvLHxn4Tt7i81u01C4gsbfSLWCMSyXdxdTOltFa+WyMtw8gidZYir
sJE3b0MVVpez/dP3HJbbt9NtGtQdOLvZ72/D5n15/wAEU71/Hkf7TUGifB3Q9Ymn+F/iKWH7EuuT
teNcm1+zeHAI73Bgl8iYxgD7bIUfbcMVG0/4Im3cvjp/2m49E+DWj6603wt8RyItiutz/aWuvs4t
fD3yXnMEjRSGMD/TZDGwW4OOPkLT/wBib4pah8evEHwzPhG7svGXhOC4u9btb+5gsrfR7aBBJLd3
F1M6W0VsEKMLh5BE4kjKu3mJudD+xD8VJPj94l+GEvhC8sfGng2G6utetL65gs7fR7a2TzJbq4up
XW2itghVlnaQROJIyjt5ibjD4mtTdNKk24uS23b6baNfP8AnTT5lzb/13/rufXf/AARV1SXxpb/t
NxaF8F9E1uSX4X+I5lexi126aYXP2b7P4eIjvdv2eTyZTH8pvWKPtuCVBVf+CLF8/wAQR+0xDoPw
S0PXJZfhn4juI/7Ph166ab7ULcW3h393fEfZ5PKlMeB9uco4Fy2OPkS1/Ye+Ktx+0D4j+F0nhC7s
fGvg+K5uddtL+6t7K20e2t08yW6uLuaRbaK2CFWFw8oicSRlXbzE3Fr+w98Vbj9oHxH8LpPCF3Y+
NfB8Vzc67aX91b2Vto9tbp5kt1cXc0i20VsEKsLh5RE4kjKu3mJuihWr03TapP3ZPpu3023Wv+QS
hF81pb/132Prz/gitqI8eR/tPJo3wX0DV2k+F/iS5iexj1u5Mhufs/2bw6Nt9j7PL5UojwDfOVfb
cMV4m/ZwsJvij/wRr1+Lwn8NtP8AjDrX/C+Xv5PhfaQ6jfQ+F7KXQwsWpJHp88erCOSTNqr3V3LA
32YAL5wkkf45s/2Kfijd/HbxF8NX8JXdl4x8I29zea5a39xBZW+kWtvGJJbq4upnW3itthRlnaQR
OJItrN5ibt+f/gm58ZtIvPEsWueErbwhD4S1v/hG9SvfFWu6d4d09dS8nz/ssV1fTwwXEnkFZsQu
/wC6lik+5LGzJVKyhCDpv3eZPTe99Numujv6BKmtXzb2/D5n6la5+0T8PPBv/BVvxb4A8Nat8QJv
jZ4p+MGiNqnjDw5olhrCXvhmzsdLlfw5K8dzAbOGC8t7gXcsUTSCGyC3BuSsgHmn7UP7Ptzofw+/
aC8R/Cj4bnx78eZ/2jtTg1mz1b4fWfiXXLHw1c6d9utpv7KuY7xbezkvJrjyb1IkN0gQllAWJPzY
P7HnxOH7TbfBr/hC9a/4WamoHTG0Dyx9oWULvLFs7PJEQMvn7vK8r97v8v564/4k/DvWPhD8Rdf8
J+IrP+zvEHhfUrjSNTtfNSb7NdW8rRSx742ZG2ujDcrFTjIJHNbYjMZyi3Up29+Tvro3e61W6ve/
poZxwyT0km7dt9vwP0E+HH7DHxK+Il78SPF/xI+G3iKf4TeBvGsqXHwc+E17PqlhrfjAWUDy2UcN
pcXa6bCkUsX2u7JzArG1gAlAig6T406/+0D8fPhR8Ufht8bPgLrXxCvLb4q2vi2+t/hr4m0+LX/D
2pz6DFbQW81rBDqUkmmtp8dqIZvJUGSGVXuZpdyp8G/CL9jf4hfG34cXvjLRtL0mx8H2GpLo0mve
IPEGneHtLkv2iM32OK61CeCKa4EQ8xoo2Z0RlZgAyk8r8Zfg14o/Z6+KWueCvGmi3nh7xR4cums9
QsLkDfBIMEEMpKujKVZHQlHRlZWZWBOH1ySp3UXZve6s/i0+G17PTovestdL9neTUpJvTTXS3z/r
Q/cD/gog3hv4ueAviPpOk+Ar39pFfCX7Rkd/r3gLwpqc51QWz+ArGx8+4ewWaeCOLUIHjL7Apms5
oid24Lm/tPeFrTXP+CU/wE8D3Pwo1j41eJvhxr2hXPjf4W6JdXdv4i00S+CUt4ZtQjtYmu7JVnWM
rviIfydhcbtqfj38Iv2N/iF8bfhxe+MtG0vSbHwfYakujSa94g8Qad4e0uS/aIzfY4rrUJ4IprgR
DzGijZnRGVmADKT2Gs/8Eu/jb4XsJdR1rwto/h7QFazS28Q6z4r0fTdA1Vru2N3biy1Oe6SzvS0A
MmLaaTaPvbTxW/1+pN88afVtWStrzafDrv1utHpq7wqfL7rnqkvwtrv/AFffY/VP9pzw9a65/wAE
pvgJ4CuvhNq/xq8T/DnXtDuvG/wu0Oe7t/EWnLL4JS3hm1BLWNruxVZvKwHjw/kFS/zbU/Nv/grf
ZN4f+InwZ0G7gaw13wz8HPCul61p07FbzSr1LRjJb3MTIrQTKGQmJssFZCT82ByOqf8ABLj43+Hd
Jm1XWfCuk+HfDqPaR23iLW/FWkaX4f1Zrq2+1QLY6ncXSWd8Wg/eYtZpSq8tivLfjX8B/Ff7PHi2
30XxdpQ0y8vrC31Wykiuoby01GzuEDw3NvcwO8M8LjOJInZcqy53KwGGLxNSdJxlBxXNv85Oz0V/
m9LPTVm1KK5r8yf9ev8AXc5CiiivKOgKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooA+7f8Ag2g/5TX/AAc/64eIf/Ud1Ov6y7D/AI9I/wDd/pX8mn/BtB/ymv8Ag5/1
w8Q/+o7qdf1l2H/HpH/u/wBKALkHU0UQdTRQB8cf8HR3/KCj45/9wD/1IdMr+cP/AII16/pbfFP4
yeDLjULS08SfFj4ReIfBHhG2uJlt01fW7wW4tLITPiOJ5jGyqZHRWbam7Lqrf0ef8HR3/KCj45/9
wD/1IdMr+Sj4NfBrxR+0L8UtD8FeC9FvPEPijxHdLZ6fYWwG+eQ5JJZiFRFUMzu5CIiszMqqSOjC
1JU60ZRV32730Mq0FKDTdj7F/ZBsbX9l/wDYK+Jvi743+FZ/iF8MbvxzB4Ig+F1zePpV5b+KII0u
5dRln2/aNNMNoktuWgXzLhpTDJtSMmvpeHwfrnjr4bftp+IfC3w4m+Lvhrx1YfDnU/Cnh6Tw/cWk
T6dJHbXVrpIttHnjZZdNsrqzjZLeUNtt4pGHlylX/LzxL+zB408KfB6/8f3Wn6dL4O03xVJ4Km1S
z1myvYW1WOA3Bij8mZ2ljMQLrcRhoHH3ZDkV2/gn/gm18XPiB4H1nxJY6V4Tt9D8O22mXuq3ep+O
NC0xdMg1K2t7qwlnFzeRmJJ4rqHYzgBnLR/6xHRe3D16kYqnGm3v+Kkn0fRvyVna12YVIRvzuSX9
Lz/q68j9CLPxh4a+An/BOf4o+GPiv4G0nwz4M+Jf7Td74c8Y+HtJ1SCZvAdhcaXbX0L2dzpwZDPY
TRxMITA8TfZJITCrF1Tyr4+/D+bxv/wcm6rd+HL/AP4SXQvA/jnSvE/iHVnms4rTw/punCyn1GS5
mXZbxQ2QjkhLTEPuhVZC87Hd8dfH7/gn98W/2X/Cuta1458Kx6Jpvh7xLF4Q1CUavY3ZttUksU1B
LcpBM7HNq6v5igx5yu7eCojX9gr4ryftCeIPhRH4WSf4i+GrCTUbvQIdWspbueOO3S4aO1CzEXk/
kuHFvbGSZgHwh2NjT63UahSdN+7Jeu8tHp5u2m/NZa6KNKOs1PdfLZa79vzMj9srx3o3xS/a++Kv
ifw7eSaj4f8AEfjDV9U0y7kiaJ7q1nvZpYZCjKrKWRlO0qCM4IHSvNqKK8ic3OTk+p2RVlY/QT/g
lT4G8Ta7/wAE3/2uH0f4U3fxWTVz4TtbTRGstTng1eWDU2kmjQWEsM8jwpLFMyxSBkHls37ssG+k
/wBv34bJ4nsfj340+DWgaL8a/jYPjXYaDqhXwdpXjW90rw+nhmKSOEWJtJoreKO+S4tjOLdJWay2
SSSSI9fmh+zb/wAE+vir+1vpOn3fgLRdC1b+2NTutH062uvFWk6Ze6ldWtvDc3MdvbXVzFNN5UNx
C7NGjKofk8HBpP8AwT++Jutafq+ow2vgtNA0TUIdJuPEE/jrQrfQZL2WA3C2kOpSXi2dxOIQXaKG
Z3jGN4XIz6lGvNUYx9m2tk//AAJ6abq/m1bS12cVSEHOXvK//Db69beR+hH7U37JXhn4YfDz45Xv
7NPgjQPiZ8R9O+OEOmX+nWfhHTPGs3h7Q5tCW9MEViba4itbaPVHvbYSJDGf9EELO5jZVsfCnU/D
/wABf+Civ7aPwh+Fr+DNS0S/+H3ii+8J2CeGNFv77UNbls7G5l0aBhbGa4gieO5iXTAXiX7O26Eu
shPwp4U/4JMfHzxl47ufC1t4L0+18T22vXvhpdI1LxRpGm395f2dvDdXMdtBcXUclyiW9zBL5sKv
E0cyMrkEGuX+F/7AfxS+NfxD1rwz4T0jQNfvvDyWbX95Z+K9Jk0mF7yWKG1hGo/afsbzzSypGkKT
GRnDqFLI4XojiqkZxqQote9pa/8AeulpvZ+b0QnCDupTW3l5av7tPmcZ+0L4E8SfDP43+KdD8YWu
iWHimw1GUata6RLYSWVpcs2+SGMWJNrGEZipihwsRUx7UKFR9af8E5vh4niv9kDxXeaN8MNa1/xP
F4ytbebxPoHgDQvihqMNobGZk0+TQb+dJbGFnV5V1BEKTMjQlgYcH5x8KfsQfEvxj8LfHvjG20TT
bPRPhfcPaeKl1TX9O0y/0SZePLlsrmeO63u+YkUREyyq0SbpFZB5PXlwk6VRTlF21/y3t+K/A6Zx
54uEWv68j9XP2SdS1r9nv9uz9sr4P6EfhF4m1G78EeM7rw7aeGPCelyJq2qTJbTJpVnHLDNcyxRR
I6to/mzwo9vMpSTY8jUP+Ccv7ENt4ZfxJ4v+IemeEPFnijTvi1aeHfH3hK2s/Ck+k+AdFjtJNSvN
bvriW0vLe2sQPtVuYLU2QV7SSITeaqRRfllRXVHMYpwbhpFtpX769U9jJ4V2lyuzaWtu3zP028R/
stWfwp/Zy+N0/wAB/h5o3jj4meG/2itU8GtpT+E7XxxqOj+FYLWZrBvsd5BdGGGWcTKLkRhpWgKm
RtmBY/ZP+Clp4e+BP7ath8eLZPhd4M1LxX4RtPFM3gq2ttSsdEb+3hPc2FiYJZYAbYXMCvHG80lq
hGYpXTyH/MGis1jYK1obX0vprfpbzXXp00ar2EmrN/O2v9fI+nP2iPD+peDv+CturaZqehfBvw7c
6d8QreGLSJjZnwNYQLdxi3gumtooImsVh8tbhmiikZRKZkSUyKPE/wBoaMw/H7xyhPg9iviC/BPh
Ig+Hz/pMn/IPI4+x/wDPHH/LPZXH0Vy1KvPfTd3NYQ5Ul5WCiiisTQK/Q7/ggvaXuv6N+0vZaZ8K
bHxveJ8H/ECC9EOqS3F/LOtusOisLa4SPZc+VMVWKNbtyjiOZVUgfnjXY/BH4BeLv2i/Fd3o3g/S
Dql3p2nXGr38slzDZ2mmWUC7prq5uZ3SG3hQYBkldV3Oi53MoPXgajp14yjHmfbvdW7P8jHEU/aU
3C9r/wBeR9yf8ESpV8fzftSNpfwW0bXVf4VeI7iAWCa3cBZLjyfs2gDZeEmCby5Qg5vX8tsXGFYi
v/wRTuD45H7UI0n4O6TrrzfCvxFLbixGszFnuPIFvoI2XZ3QSiOUoozev5LbbjCvXyQv7D3xVX4/
+JPhfceDr7T/ABr4OgubvXbO/ngs4NHtreMSS3dxdSutvFbbCjLcNIInEsRR2Eibix/Yh+Kl58fv
EXwwfwheWHjTwjDc3Wu2mo3MFjb6NbW6eZLdXN1M6W0NsEKsJ3kETiSMq7eYm7tw1erTdNqm3yt9
N2+m2j8tfwMnTjLmalo7dei+fX5H1t/wRUnfx2/7Tq6N8HtH1ySb4W+IZ4Fsk1mcSNP5Bg8P/Jec
wTLFNsA/01zE224O1qf/AMETriTxxL+1ANG+Dmi6+Z/hV4iliS0/tiXc05t2t9BXbdktDKIZQir/
AKa4jk23HynHyPa/sPfFW4/aB8R/C6Twhd2PjXwfFc3Ou2l/dW9lbaPbW6eZLdXF3NIttFbBCrC4
eUROJIyrt5ibkh/Yh+Kknx+8S/DCXwheWPjTwbDdXWvWl9cwWdvo9tbJ5kt1cXUrrbRWwQqyztII
nEkZR28xN10MTXh7L903yOS23b6bbrtr6DlCMrpS3s/+DufXn/BFTUH8dv8AtOx6J8FNF16S7+GH
iKSBbCLW7re1yYDbeHhsvCTBKIZvLC/6c5ibFwQrUv8AwRLuv+E8H7TsWj/BHR/Ek0vwu8RTW/2B
NcuGd7n7OLbQP3d4c28vlTbAB9tco4FwcHHyFD+xD8VJPj94l+GEvhC8sfGng2G6utetL65gs7fR
7a2TzJbq4upXW2itghVlnaQROJIyjt5ibiH9iH4qSfH7xL8MJfCF5Y+NPBsN1da9aX1zBZ2+j21s
nmS3VxdSuttFbBCrLO0gicSRlHbzE3KjXrQVJeyb5W1tu30Xu6NdtWKVKMlJKW9ur/zPrr/gizdy
+Ph+0+NC+C+h60X+F3iK4UWKa1cb/tLW32fw+Nt4SbeTypfLC4vn2SYuWCnE37O1ne/FX/gjR4jt
vCfw8sPi9qSfHWTU3+F9nb6lfR+EbSTRAE1aNLCePVFjkZTaB7q5mgIthhfODyN8e6f+xN8UdQ+P
ev8AwyPhK6svGXhSC5u9atdQurext9ItrePzZbq4u5pEtorYIVYTvIInEkZV28xN3RXH/BNL41aR
c+J11zwfB4Ot/B+tL4c1O+8Wa7p3hzT11FoftC2sN1f3EMFxKYCswWB3zDJFJ9yRGaFXrKEIOm/c
clt1fTbddtfQc4xTfvW2f3fM/UfVP2kfAeif8FfvFfgzw5rvj7UPjT4u+MWhjUfFXhvRLDV49S8N
2tppbyeHZJ47i3azt4bmC5W6lhhL+TZhbg3GJAvl37THwKnsfh7+0H4n+Evw5g8ffHW7/aN1KHV7
HUfAFr4n1rT/AA3caeb2CX+zLmK8SCykvJpvJvUjia5VFJOMRRfBF9/wTV+NOgaj4mt9f8I23g6L
wjrY8N6le+Kte03w9p66iYftAtYbu+uIYLiQwFJgIJHzFLFIPkljZrWof8EvfjZoejzatq3hfR9A
8OK1pHb+Ita8V6Ppegaq91bfaoEstSuLpLO9YwfvCttLIUH3gtbVcbVmmnSa95tb3V76eq776GMa
FKOqktkum3+R9Q/D/wDY1+JPxUn+JfjD4i/DvXG+EHgjxw7T/Bb4S39zqWma54x+yW/m2kNvaXF4
umQrDLH9quycwqxtLcCQLFB0Xx18V/tD/tFfDn4ofDr43/AnX/iDd2/xTg8W6jZ/DjxHYxeIPDuq
z6FBbQW81tFDqUrab/Z8VqsUphXMkMqvczSh1T421P8A4Jm/Gjw/oc+sat4X0vQvDcctpBB4h1fx
PpOnaDqcl1bfa4Es9RnuUtLxmgxIRbSyFVI3bciptU/4JffGvw9ps2pav4Z0TQPD6NapbeIdZ8W6
Npmgas1zbC6hWx1O4uks75jAQ5FtNKUBG7bWLnUiuVU5LV383ro/dtdK/wD5NprpryQTbcltp5be
f9adj9Zv+CjmqaH8XvA3xL0nSPBEv7SUHhX9pGPUPEPgPwzf3A1NoT4EsbBZ52sBJcW8Ud/DLEXC
KrTWssROdyrh/tF6RD4h/wCCWfwQ8Dal8NdU+PHiH4d+I9Bn8U/CvQ7nUbXX9Ghl8BwwRNex26Pc
2ardASAiNEdomQ7maVh+Wmqf8EwPjZ4e0W51fV/C+kaB4bhe1ig8Rax4q0jTdA1V7m3+1QpY6lPd
JZ3zNB+8K2sspVfvAVJq3/BLf43+GtLn1PWfC2j+HvD0bWaW/iLWfFmj6Z4f1Vru2+1wLY6ncXSW
d6zQESEW00pVT822t54+u5OTpfal0W75tNY62vs77PTVmUacIrlc1ovTsr6P8rdPI/Uz9ouyPir/
AIJb/A7wNqvw01X4+6v8OfEPh+48UfCvw/d6ha+INEt38BwW0TagluklzabbzLq3kojeUYzuZpGr
4a/4KE638NvBXiz4W+HPid4K+IOr+LfDXwr8K6Zc2mjeM4dCk0AppkRexvLS70y8eO7ErSytteJQ
k8QMQdXkk8S1f/gmL8a/DOjvquteFdL8O+HibVbXxBrXifSdL0LVjc232qEWOo3FylpeloMSEW0s
hUEbsEgV5n8bvgJ4s/Z08YQaH4v0tdNvbywt9Us5IbuC9s9Rs503w3NtcwO8FxC4ziSJ2XKsudys
By4mvUdOzp8qUnq15y0emr1/B2SuzWFCKfxf18n+h77/AME+NP1ib9qLWfG3w4u4/hv8KvCemmTx
xqfjidNf0e00OZFiubHUVigt01EXjhoobJIVkmd41QhozOn0T/wS713wj8QviZ+1snwj+B9zP4Pu
Phv4nfRBqFzquo6vLBcrbC10GZracRGKY287JHGgvMGRPtkojLn849D+G/iLxN4Q1zxDpug61qGg
eGPIOs6nbWMstnpPnuY4PtEqqUh8xwVTeRuYYGTWz8Cv2e/F/wC0p4yuNB8GaSNUvrHTrnV72Sa7
gsbPTbK2jMk91c3Vw8cFvCijmSV1XLKudzKDOExkoTiowu7t+t1ay0aS+X5K11KcXzOT6fd11/r9
T7d/4IrX58dw/tMQ6N8FNF113+GPiS5SWwXXJ2k+0Lb/AGbw8RHdsDbSmGXywAL5yHxdELwf8EWN
TPje3/aYh0X4H6D4ilk+GPiOeOWyXXbhz9pFv9n0DEd6QbeTyZvLAAvXIfFywXA+RIf2Ivio/wAf
PEXwxn8H32neNfCFvc3muWeozwWMOj2tvF5st1cXMzpbxW3llGWdpBE4kjKs3mJuS2/Yl+KU/wAe
/Efwyl8IXth408IQXN3rlnqFxBZQaPbW8fmy3VxczOtvFbhCrCd5BE4kj2s3mJuujXrx9n7jfJJr
bq7e7tvv3eui0QSpxlez3t1f37n13/wRY1j/AITO3/aYg0b4JaBr8s/wx8RzRSWY12d5Dci3Nv4f
xHekG3kEExjAAvX2yYuW24Ef/BFy/HjaH9pxdJ+Dmg61JN8LvEUlu1outztI90bYW2gLsuyDDIIp
vLH/AB+PskxcNtwPki1/Yk+Kdx8evEfwyk8H3tj4z8HwXN3rtnfzwWUGj21vH5kt1cXUzrbxWwQq
wneQROJI9rN5ibl0v9iP4pap8fPEHwxPhK5sfGfhO3ubzW7XUbu3sLbSLW3i82W6uLueRLaK2EZV
lneUROJI9jN5ibtaGIrUvZuVJtQk1tu39nbRp9Pw0CUIu7vvbr2+Z9df8EVdVbxkn7TcWjfBXQdf
e4+F3iOSM2ia3cM5ufsxt9AAjvDmCTyJvLAxevtkxcMFIEn/AARX1NvHkf7TkWh/A/w/rskvww8S
XMb2Q12cn7SLc2/h/wCS9INvJ5M3lji+cq+LltuB8iWX7DPxXvPj/wCJPhe/g2/sPGvg61ur/XbL
UJ4LGDR7S2i86W7uLqZ0t4rYRlXWd5BE4ki2M3mJuW2/YY+K837QfiT4Wy+Dr2w8b+Dre7vddsr+
5gsoNHtbaLzprue6mkW2jthFtdZ2kEUgkiKM3mJumlia1P2X7t+5Jrbdvptv95M4wlze9ur79uu5
9cf8EVtS/wCE5P7TqaN8EtD10z/C/wARzxGwTXbkg3Ig+zaABHenNvL5MoT/AJfW2ORcttIp37Os
178UP+CNXijTfC3w6sPi5f8A/C9f7WPwzs4dUvofCVrJohVdURLCaPUhHIwFqr3V1NEwtsBBKHkf
5Ctv2H/irN8fvEfwwm8H3uneNfCFvdXuuWepXEFhBo9rbxedLdXF1O6W8Vv5ZVlnaQRyCSLYzeYm
7cm/4JufGbS18Tyaz4StvCdl4Q1tfDepX/ijXdO8P6eNSaA3AtYbq9nhhuZDbhZgIHkzFJFJ9yWN
miFatyRjKm2otrbq+m2++jvfsEoQd3zb2e/b59T9Stc+Pfw00D/grl4w8A+HNd+It78Y/Fvxi0GS
88Z+GtIsdaGo+HLay06Sbw7LLFcwPZwQXcM4uZoYpJPJswtwJyjivMP2n/gBNo3g/wDaM8Q/CP4f
J8RfjjJ+0ZfW+qW2p+ALPxNrNp4cudPkvYphpdxDeJBZSXkkvk30aobpAhbYNsS/C99/wSv+OWg+
F9Z1vXfCujeEdJ0DxNL4PvbvxP4t0bQIk1VLWK8+zq17dxCTdbTxTRyJujljcMjOMkYujf8ABPf4
oa7ous6vDZeDo/DehapDodx4iufHOhW3h+e/ltvtS2lvqUl4tndTrBh3jglkaIMokCFgD1VsbWqX
U6Tu5Sa30ve/Tda6+WxzqhBO/tNklrby/PttqfWXg/8AYw+KHxMv/iR4p+Ivw48RJ8IfBfjmQ3Pw
b+Et3danpWseMfsUBls4IbWe8j01FilhF3dFt0CyG1gUSBYYfZ/gX8BfGPxA/aR+IfxO/aG8PeF/
EPxKuviRo+keO/CFxb+HZNO8BeHk0n7f/bN/c31rfCLTVsgsC+TPbzSG3ZWuWuDHX596t/wS9+Nn
hvTZ9S1jwzofh/QI5LOGDX9Z8XaNpug6o93afbIFstSnu0tL0tbkSH7NLJsDLu2lgCzUv+CYfxq0
HQ59Y1bwzo2g+G45rK3g8Q6x4r0fTdB1OS8tftcCWeoz3SWl4xt/3jC3lk8sEb9pIFZU6lSFmqUv
iv67/wB3da26L3tNXbRxi0/fW3+Xn1/yPvXxF8ING+HX7K/xK+F1h8GNe+Lmh/DX9qTWdTk+GelX
mpxatFoFzoMttpt68kCSXEdq2yB4rht4mMIBJDZb1v8Aaq0waz/wTC+BXgG/+HN58c9Z+Gmo+Gbr
xf8AC7RHvrLxBpIm8Fy26tqKWnmXNsYpkRlkdIyfLETRqqh5vyxuf+CX3xr0vQLrWtT8M6JoHhu3
ms7eHxDrXi3RtK0LVJLu1N3AllqNzdR2l6xtx5hFtLKUUjftyMzar/wSx+OHhzRbnV9Y8L6J4e8O
QyWUUHiHWvF2jaXoOqveWpu7dbHUri7S0vi1uPMItZZdgI37cjNPE1ElD2L0b6L+9p8PS73utHom
2EoxT1qa27+nn/V12R+o/wC1Dbx+Iv8Agl78D/At/wDDG6+N2s/DnU/C914t+F+gy3dnr+nJJ4Il
tkl1FLPzbm2aOdI2EjrGWESxPEFCvJ+cH/BW2G40n4k/B3Rr+OG01jw78G/CWl6nYParbX2l3Mdg
N9veJ5jOJ1yDiRInEbRKYyAJJOV1P/glp8b/AA/o13q2r+GND8P+HbeWygh8Qaz4v0bTNB1SS8tf
tluljqNxdpaXxa3xIRayy7FK79uRny745/s/+Lf2bfGkGgeMdKTTL+80+21azeC8gvrTUbO5jEsF
zbXNu8kFxC6niSJ2XIZc7lYDnxlZzpcrpuPvXu/npeyb+bsrOy1ZdCMIy92Sbt/l/wAD+rHG0UUV
5Z1hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH3b/wbQf8pr/g
5/1w8Q/+o7qdf1l2H/HpH/u/0r+TT/g2g/5TX/Bz/rh4h/8AUd1Ov6y7D/j0j/3f6UAXIOpoog6m
igD44/4Ojv8AlBR8c/8AuAf+pDplfzjf8EYvEWm/8LV+M3gubULO08SfFr4P+IvA/hK2urhbaPV9
bvFt/stkJnKxRvKY3VDK6qz7FB3sgP8ARz/wdHf8oKPjn/3AP/Uh0yv5J/g98HfE/wC0B8TtF8Ge
DNFvfEPifxDci00/T7RQZJ3IJJJJCqiqGZnYhUVWZiqqSOjC1JQqxlFXfbvfQyr01Om4t2Ps/wDZ
S0+X9mD/AIJzfE7xL8bfDWo+PPhXc/EKLwTbfCy9luNKnsfF1vBHczanJclBJpzxWSS2zi23TTFx
HOqRxoT9L6F8GfFet/AP9snxN4X+HGu/F/wR4/tPAereC/D9/omqpbvp9xMmowaLbpYXCyH+y7S9
tlMNncGKJYYt21MR1+Wvib9lnx14S+DN98RLvR4JPA2n+LJfBEmt2epWl5Zy6vFB9oe3ieGVxMvk
4cTR7omVlIc7hnuPCv8AwTQ+Mfi/wDqfiiHQPD+n6Bo1jpuqX15rHjDRtIS1tNRghnsblxdXcZEU
6zxqj42tIHiz5sciL20cTUUI0+RtK/rqpLe2u+z00emrOepTWr5kr/8AA81rp+J+h2neLNI/Z1/4
JufFDwd8Yfhe/wAPvBPxK/advvDPi7w+lzdQy+CdMudMs9QgnsZbeNoZTZPBazxFIZUuIYwPLaOZ
CPK/2gfA9x47/wCDljU9W8OafrJ0TwT420bxh4ku9Znnt49D0+wSwuNRvbie/KCC0jKyeWzMINrQ
Jblo3gDfGv7Qv/BPH4xfsqeEdV17x/4Nfw/pOieJU8H3k7anZ3Hlaq+nxaituFhmdn/0SeKXeoMY
EiqWDfLUOofsA/FvS/2ifEnwlm8KIPiR4VsJNRvtAXVrJ7uWNLdLlktgsxF5P5EiyCC2MkzKG2od
jY0eLqckKUqbtFq3fTmsr2839z07RDDw1mp3bT9Omtr+SMf9s/4haR8XP2w/ix4r8P3TXug+J/GW
r6tptwyyKbi2nvZpYnIkAcbkdThwG55AORXmlFFeROXNJy7nfFWVkfbH/BvD4V1XxJ/wVt+GVxpt
he3kGjRare6hPBbmVNPtzpl1D50pwVjTzZokDNgb5Y1HzMoPSeCPg94w+KX/AAQ81r4X+GPCnifx
H8SfCX7Qr6hrvhTTNNurvWtFtzoBthNcWSIzwp9oimiLsq/vIijcgAfL/wADf2G/iL+0Z8K/EHjb
wta+FJPDHhS5jtdZvtU8ZaNow0tpCixNMl5dQvHHI8ipHKyhJHDorMyOq6P7RP8AwTm+Mv7J/gzV
fEPj/wAHf2Bo+i+Jo/B17cf2tY3Xk6rJp0WppbbYJnZs2c8Uu9QYxu2lt4Kj0KdaccPGPI+W8te/
Mku3Tlv16nHUUJVX76vpp10fr5n6FfBW8tPib/wdY65rXhX+19a0XQdV1NtYvGN1dDTmh0SSxu2e
SYu0UKXzGCPDeUpaGOHCGJa8S8HWfhn4df8ABA+70/4n+FvH9+dM/aOu7GfR9N1geHrmxvE8Owq3
mvc2V1GGTZKjxCJJASpZgFCnxCz/AOCO37Q1543fwz/whWkW/iMatcaFFpV14w0S2vb29t7C01Ge
G3hkvFe4MdpfWkrmIOqiYAkMCBi6T/wTD+LuveDtZ8RWVt8O7rw94eeFNT1SP4l+GmsrETOI4ZJJ
vt+xYpJSYllJ2NKkkYYyRuq9NWvXe9JpuVR7dZJJq1vs21/Qnkpq0edLSPXovn1P0d/a3+A/i74q
Wf8AwUj/AOEK8HfELxBba7rHgbT9OD6XqN7d6rfW1xazXcNuZQ0sqxrMsoWLdCtvLbtGBA0Br8x4
PgT4j/ZZ/bj8OeB/F9l4Os/E3hzxFpS6jZ+L4pF8P28rvbymLUd6r5lku8LNJHuikiDvFJLEySPD
8aP2Bfi9+zv8OdY8WeNfBd54d0HQfGEngK+nubu23xaylol4bcRLIZHQ20kcqTqphkR1KSNkVw3x
S+DfiT4LX+jWvibThps/iDRbLxDYL9oim8+xvIVntpsxswXfGyttbDrnDKDxXLi8Qpz53TcXd9dF
rJ2Stp2+TNKEOVcvMmn/AJLz/q6LX7RG3/hoDx1s/wCEO2f8JDf7f+ES3f8ACP4+0yf8g/dz9j/5
4558vZmuOr0z9mn9jz4jftfa3qFh8PvDo1qTSfswvJ7jULXTrS3e5uEtraFri6kihE088ixxRb/M
lYkIrYOOl+Cn/BOH4xftB6Trl14X8MafM/hrXI/DerWWo+I9M0rUdN1GWVIYrea0u7iK4RpZnEMZ
aMLJKHjUtIjqvJGhVnbki3fayf4HRzxWjex4dRXuvwK/4Jr/ABl/aQ0/XZ/CnhfTZpPDGsx+HtYs
9T8SaXo9/pd/JNHBFbzWt5cxTxtLPKsMe5AJJQ8aFnjdVqfDL/gnr8Vviz4M8X6/p2jaBpunfD/U
v7I8T/8ACQeLNI8P3Hh653rGEu4L+6hlgDSuIld0CvIskakvG6qvYVdPdeu2nbf7hOrBXTktPM8V
or6Ftf8Aglj8b3Xx2b3w1oGgH4ZakmleKU17xjoujPoksnl+Q8y3d3ERbz+dH5FwAYJ9x8qR8HDf
E/8AwSz+OPgPWfEtn4k8K6R4Uj8I6nb6Jqeoa/4r0fSdKS/ntEvY7OK+ubqO1nuPs0iStFDK7xo6
l1XIp/Vq1r8r7bPfXT8H9zF7en/Mvv8A67o+fKK9xvP+CcHxl0SbxR/bfhO18J23g/Wh4c1K+8Ta
9p2g6f8A2iYhMLWC6vbiKC6kMBSbFu8n7mWKX/VyIzeZ/GL4O+J/2f8A4na14M8Z6Le+HvE/h65N
pqGn3agSQOACCCCVZGUqyupKurKyllYEqdCpFc0otK9tuvb1LUk9mc1X6Jf8EG0vPEXhn9pXStK+
E2meM76L4Q+Id2oqusPeao862iwaE621ysJjnaCVlSKOO7ciUJPtXav5212fwL/Z78X/ALSfi+60
PwbpI1O80/TrjV7+Wa7gsbLTLK3TfNdXV1cPHBbwoMAySyIu50XO51B1wdWVOtGcY8z7d/zMsTTU
6bi3bz/qx9x/8ES9Ym8av+1BFoPwT8P6+178LfEbolkmt3DS/avs/wBm8PIEvTugkMMhjABvn8qT
bcnaSIv+CKWtf8JbbftQRaT8G9C1prv4W+IXiNmNbmaZrlrY23h4bLsgwSmGUoABev5cm25O3j5G
h/Ya+Kz/ALQPiX4XTeD7zT/Gvg23ur3XbPULm3sbfR7W2i82W6uLqaRbaO28soyztIIpBLFsZvMT
clr+w78Vp/j74j+GEvg6907xr4Ptrm+12z1G4gsINHtbeLzZbq4upnS3itvLKMs7SCOQSxbGbzE3
ehh8RVh7L903ytrbdvpto18zJ0qcuZ829nv267n1z/wRSe5+IaftPR6B8GtD1yST4WeI5kFlFrVy
8xujbC20BQl2cwyGKQxgf6a/lyYuGCkCb/giPqN541j/AGoYvDnwZ0HXJbj4WeIpM2UeuXMk63Rt
hB4eUR3hBhm8qTYAPtrhJNtydvHyJZfsJ/Fm8/aF8SfCt/Bt5YeN/B1vdXuu2eoXVvY2+j2ttF50
t3cXc0iW0VqIyrrcPKInEkRR28xNxpn7Cfxa1P8AaB8SfC4+C7+x8a+DrW6v9es9RuILC30W0t4h
LLd3N1O6W0NqIyjLO8gicSxbHbzE3Kliq0FSTp/A2tt2+m2+/wDSCooSUryWtn8u++x9d/8ABEzU
ZvHf/DUMegfBDw/4hkuPhb4jliFlHrd0x+1G2Fv4fUJeHMEvlS+WB/pz7HIuTtOGf8EU/Ef/AAlA
/agTR/gp4f1z7d8LvEZj+xjW5yxuvs5tvD6hbxt0Ehhk8sD/AE5/LfbcnacfI1r+wv8AFef9oTxH
8LJfB93p3jbwfBc3mu2mo3VvYW2j2tvH5st3cXc0iW0Vt5ZRlnaURSCWIo7eYm5unfsN/FbUfj34
m+GR8G31l4z8GW11fa/aX9xBYwaLaW0fmzXdzdTOlvFbBCjLO8gicSxbGbzE3KliatNU3Km7QbW1
rt9NnZrUJU6cua8tHZ7v79z68/4Io3w8dn9p8aR8FdC1zzPhb4kuI/sCa7csxuRALXw+vl3pBt5D
FIUz/priOTFySvFn9m6wufit/wAEZ9et/CPw4tfjFrA+PMupS/Cuzi1K+tvC9lJoQEeqJFp08eqh
HcNarJdXUsJFthV83zXf450n9h74q6x8evEXwzHhC7s/GPhC2ub7XbbULq3sbbRrS3jEkt3c3c0i
W0NtsKMs7yiJxLFsdvMTd0D/APBND406cfFL6z4TsfCVn4M11fDOp6h4p8RaX4e08ak0JuFtYLq+
uIYLqQwATYt3k/dSRSfcljZpVWtyQg6b91yW3V7rbda3WvpoOcI3k+be3Xb8evyP1m/b7h0T4jfD
/wCJuh6f4S1X9qP/AIRf9ph9Y17wJ4c1BxqEdjJ4JtLSMytpcRmtoLa8R7YO0ZJeweJ3aQTM2b+0
dp1nqv8AwS6+CfgvUfhl4i+Oev8Aw/8AE/h668bfCbTZJbLWtHj/AOEBgtInuhYo19aqJ03h54wW
eN4vuKM/lP4B/wCCZ/x6+J37Quu/CvRPhf4nu/HPhef7PrFi8SQQaUxjeWNp7qRlt4klRGaKRpAk
wK+Wz71z4ZWtbMZc3PUp2fNJ9Ot7p3i725lo7+mrM4YeL93mvZL/AIffS9t9/M/dL9pbStM13/gl
n8DPBl98Jtf+N3iX4ceI9AuvHXwu0iaay13TIz4EgtIpLwWKPe2iCdEO+4iDM0DRAhAKrftN+GrT
Vv8AglT8DPBV38ONc+N/iT4c+I9CuPGvwr0uWWy13R0k8DxQRPdJZRtfWqLOgYvcICzwtEPkAr8a
Pgb+z/4t/aQ8Y3GheDtKTUr2y0+41a9knvILGz02zt0LzXNzdXDxwW8KDAMkrqu5kXO5lB7Txv8A
8E+/i58NvB/xF1zXvCsWlWfwm1GDS/FcNxrFgt7pMtw8SW7m1877RLBMZozFcRRvDKpZkdlViHHG
zcVONJ2TbvZNbS01jrZPrpo9NWXGjGD5VL5f0/6+SP1p/ae8LWmp/wDBKP4GeCbj4Y6/8a/Enw88
RaDeeOPhbpNw1trmkxyeB4raGS9SwRr60Rbhdwa5jDlo3iyE2U/9p3whZ6p/wSw+BHgiT4Y638cv
E/w81/w7d+OvhZo889rrmmpJ4JSCF72KxV7y0CXAI3zxo7NF5fCba/H/AOEH7GPxD+N/wxv/ABto
2maPY+DdO1SPRJNe8Q+ItN8O6ZLfvE0wtIbjULiCOacRL5jRxMzIjIzBQ6Funn/4JmfGvSZPFZ1v
wlZeELXwVry+GNVvvFXiHTPDtguptCZxaQ3V9cQw3MhgAmxA8n7qSKT7ksbMljasorlpuzbeyd78
2l+XW13vpo9NWS6UU7Oa01+emu/9X8kfqx+0vpdlrX/BLT4FeBLr4U658bvEngHxD4eu/Gnwr0ea
a01zTFPgZbSF71LFHvLQC4XfunjWRzEYshFQn4e/4KOaj8KPAviT4T6D8QfAvxK1Px3ovwn8K2Gr
Q6Z4u03w/wD2NNFpcMf2O5s30q6uBcoVLsbiVZNssaiNERGfw3Uv+CYXxp0HRr3VtV8O6BoXh6zl
tII9f1fxhounaHqcl1a/bIEsdQnu0tb5jbkSEWsspQMu/aWAPl3xp+Bvij9nvxougeLNPisNQms7
fUbd7e9gvrS+tbiNZYbi3ubd5IJ4nRgQ8TsucjOQQMcTiJun/DsuZ6tJ9Zaax1t66WemrLp0afNe
L6d35a7+R9Af8E/7fVG/ai1nxj8Obv8A4Vt8JvDumhfHWo+N54/EGk22hzIsd1ZaikcFsmo/a3V0
gso4kllkMSxkPF9oT6L/AOCWGp+FfiH8T/2sofhD8CZ9Y8JSfDnxLJon9qyatqGrTwXCW622hTm1
ukhEc5hmeONFN5nci3cxj3n8x6Kxw+PlScfdTs2/vVtO3y62vsjSpR5k0nuv67N/efoh/wAEVdYm
8YQ/tNR6D8E9C8QPP8MPEcu+yTXblpBdC3Fv4fxHe7TbyGGUx8fbWKOVuCVGH/8ABFXXJfGR/aaj
0H4JaJrr3fwx8Ruh07+3pnk+1i3W18PDy70hraRopPLXH22TY4FyxXj87KKVLGuHJp8Lb6dflv56
9NNBTw6lzefr/mfoj/wRc1RvHcf7TUeh/BDQNdeT4ZeJLlHsU164ZvtIt/s3h/8Ad3xBt5PJl8vj
7a5V8XLbeGf8EWXn+I4/aVt9A+C+j63K/wAMfEtwj6cmt3Ek5uVtxbeH/kvGU28hhlMYA+2yFZAL
hsDb+eNFXRzB0/Z+6nyNv1v/AJf5aaFSpP3rPf1/z/yP0M/4Ix3kvxAH7TC6D8F9E1hn+GPiW4U6
fHrtyX+1Lbi28P8AyXpH2dzFKY+PtrlH/wBIbbxN/wAEVtYuPG7/ALS0Xhz4H6Br81x8M/EsqtYR
69cu63awLb+HgI70g28nlS+WMfbXKvi5bb8v520VEMa4xpq3wNvpre3k/wCumgTo8yavv6/5n6Gf
8EXb6Tx0n7SkeifBTQ9fc/DPxHcq9lHrty0n2lYBb+H/AN3e4+zyeVKY8D7a5R8XDbeJv2cUb4nf
8Ef/ABVH4V+HFr8X9YHxy/tKX4WW8Or3tj4QsZdFYRapClhcx6kFkcNab7i6liK2sYKmXMjfnbRS
hi+WMYuOzfbW6S7f59rBOje+vbv0+Z+uf/BSPxx8U/iv+0R8efh/4M+F2i/tO/DbQ/iXZ67fqZdQ
v9V0vWX0C2s/Ka00S9tZEt7ZLWe1Ept/vwlJppZlGOq+N/wE+F3wj/Z9+IXws+HXw48RftEeG/hv
+0a2ran8PdB1m9mvLSwuPCAiy01mJpreGDUjND5jL5jGxEUsjupK/jFRXTLNE5OThq230dk+bTbV
a63ve2xhHBtRUFLRJLttbXfy6W/BH7sftVQxeIv+CZX7Pvw+1P4aeIvj1r/w0vvDFx40+E+kTXll
rWhxv4Ont4FultI2urTE481jJFvJQIX8t4lSL9qi2sPEf/BNH4A+BdS+FfiP47+J/hre+FpfGvwu
0i9vLfWNEgbwfNbQLdrZxvcWP+lHzCHiEjMiozlWjWP8LKKf9qrpDq+2zvo9Nd1vdabasawiXXp5
+Xn5eu2uh+7H7U+j2Pif/gmH8BvA118MvEHx28RfDa98Kv40+FWiT3lpruiRt4OuYIzeLaRvcWYW
7YOfMh3sy7WkZHjSKH9qTwpYa3/wTN+Avge++GXif46+KvhpeeF5vGnwr0a7vLfWtFgm8H3EUJu1
tImuLLbdYkIeHeSNjOyvGsf4W0Uv7UttHq3063301363W+mrBYWSvaXbv0t5+Xr56H7nftO6Da6t
/wAE3/gZ4Bv/AIT+KPjt4h+G134Tu/Gfwx0e9urfWNMhl8HXMMS3iWaNd2Bju2LkPDuPyq0rCRI4
fzt/4LE6dP4a+I3wP0C/klg1rw18E/COmarpM6pHdaBdrZs0lnPEEWSGUbxI0c2ZB5wOQpVV+Q6K
wxOO9rDktbW/Tz8lff5drts0p0HGfO3fS3Xy138v06BRRRXAdAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB92/wDBtB/ymv8Ag5/1w8Q/+o7qdf1l2H/HpH/u/wBK
/k0/4NoP+U1/wc/64eIf/Ud1Ov6y7D/j0j/3f6UAXIOpoog6migD44/4Ojv+UFHxz/7gH/qQ6ZX8
4P8AwRx8W6XZfEz40eD7nULWy8Q/Fj4QeIvA/hSC4lSBNU1m8FubWzEsmI42mMTopkZVLMqhtzqD
/R9/wdHf8oKPjn/3AP8A1IdMr+Sj4NfBrxR+0J8UNF8F+C9FvPEPifxDcC2sLC2A3ytgszFmIVI0
RWd5HKpGiM7MqqSN8LNwrRko82u3f/g9vMzrQjKDUtEfZn7IOhRfst/8E+viZ44+OXg6/wDiD8Kd
Q8dxeA7P4aXNxJpdxD4stYobye/lutvn6Y0FkHgYwKZbgzGKQLHGSPqN/gz4z8QfBP8AbI8Y+H/h
LrHxJ8EfFLTvh5rPgTw9J4dvLO01DSmMNxbaakGkTIWfTLKa2idIZwwEUcrgpIc/lX4m/Zb8a+E/
gzffEK60/TJfBmn+LJfBEuqWWt2N7E2qxwfaGijEMztLEYvmW4QNA4+7Ix4rvvDn/BMT4w+KPh9d
eKYNN8EW2h6fY6dqV/cah8QfD2ntpltqMENxYy3Uc98klstxHPEY/OVN5YqMsrAd1DE1FBUlBta+
v2l213e91o+7OarTTblzW/pea+/z9D9GtUktP2VP+CbPxM8IfG34ZWPgHwf8Uv2mptC8Y6Npt9FJ
L4P0q+0bT9XtnsJ7EvEz2G20mSMW7ROgMXl/Oyx+M/tG/C2+vf8Ag5Z1K60bwqdE0nwP400Xxp4j
ci2tbXTNMs4rC91DWLmUStDFFIokuTJLIHZrhQ4WaQxj40/aD/4J6/F79lfwlrGueO/CsOiaZoHi
WLwhqEi61YXjW2qS6fHqMduUgndyGtZUfzApjzuTdvVlFa6/YL+LFp+0PrnwmPhMy/Efw9YtqF1o
EGpWc15PGtsl0UtgkpF3N5Dq4gtzJKQGwhKMBbxdSSjB03ZSXrvK0dFvdu2nR6dpjQTbmpLVa222
jrv2X3NGX+2j8QdF+Lf7YvxZ8V+G5/tXh3xN4y1jVtLm8lofOtZ76aWFtjAMmY3U7WAIzggGvNKK
9p/Zr/4J8/FX9rvwdfa98P8AR/D+safpmp2+j3QuPFmkabcQXVw8cdsjQXV1FNieSVI4m2bZZN0a
FnR1Xy1GdSdoq7fRHZeMI6uyXc+o/wDglX8K/FviL/gmV+1vqGk/C3VPidZarN4TsbDRDp2qzWfi
C6ttT824hQ2EkU0kltDPFO6RShkWSNmGxjn6L8Sy2H7LX/BOD4l+EvjP8LbL4feE/ih+01d6L4t0
Kwv4pf8AhDtLv9E0/VrN7G4sQ6GTTiLWdIxC0cqAxGP5mVPx08Q+HtQ8I6/faTq1jeaZqmmXElpe
Wd3C0NxaTRsUeKRGAZHVgVKsAQQQRmqddtHHOiopR1jda2s78101a/Xa9t+ruYPDuU3JvR/8Dz8u
1/PQ/YrwZ4Ic/wDB2Tq0mjeEp7Ox026uNT1G3tbRY4o/P8ObXvZtm5Y1ubq4Ryz4LPdqGxI+K8X/
AOCWHhvSfgJ+wn+1rrnxx+Fni3xH8M9P1fwrofiDRn+06RJNd2+rGO5t1mHlsLuzN1BK0AdHy0aO
Y0lLV8WfCX9jr4g/Gn4aX/jTR9K0qy8HadqK6PJr2v6/p/h/TJb8xGb7HFc388EU1wIh5jRRMzqj
KzKAyk858afgf4m/Z88b/wDCPeK7G2stRazttQha1v7fULS7trmFJoJ4Lm2kkgmjeN1IeN2XqM5B
A6J4+TSqqnpzTeuq99JW2S0t89dLEKhG3subol56fPT9Nz9PvCXwm8TftKf8FOviz+x58ZtJtde8
IeLfF0/xAm1nwPpsWjz+FL42CS2+qRlEnXybi0kt7WaK7acCW6Egla4LSzfnP+2f8Wb34xftFa5f
Xvg1Ph5/Ysdt4atPDBWYz6Ba6bbx2FvZ3DzATS3EUNtGkkkoDM6t8qDCLQ8I/sseN/Hn7PPiv4p6
Rp2m3vgrwNcwWmvXKa1Yi801p5IooWeyMwuvLkkmRElERjZlkAYmKTZ55XLicV7SHLytXbd27tpv
RXstnfXq2+xpSo8s+a97JL59evXQ/QT4XX3gXRf+DeKK68c+EvFHiCxk/aKuIon0LXLbRbhpB4at
yoaeW0u9yIDJmMxLkzKyv8rqfrn9r/8AZO8ZfFPx1/wUU8NfDfwBq9yPHes/D+y0uCw07yLTVNTE
thd3zCT5Yd6m8W5nkZv3aXXmylVcvX4hUUUsao0lSlG69Uv5vJ/zfh56TPC3n7RP9V9npfy/E/Yr
4xfD25/bZ0z9v/Ufgr4ZvPFOgeP9c8D6N4fvNCsWXStY1W0ubY6n5U5CwuI2d55ZQ2xY5lmZ/LcS
HoNb+Jfwdv8AxT+3r8T9X8E6h8Sf2cNX1/wVp11/Y0s9jZa3dW88EWoPaXcLRpNNb3Fytx8ku2bz
YsyBLlZT+KtFbSzO75uXW7flrzaJW2953Wt/Ibwqty30tb8ut/LR9D9jvE/7Pfxc8L23/BQSPxL8
NbD4ya1rev8AhOOCy0fw3qVto3iKQXMd/wCVBDYSRXAmgsru0mljSdpU3hpZJQ7SSeG6n8NvjVoB
+Mfwz8U/sxweMPhhL8Rp/EF/8PfCOsWzeIvAGr6hpkr2M9o+l+ZKlulrcwLG9xZz2DGAxoiSmQD8
467P9nv9nvxh+1T8XtJ8B+AtHOv+LNdE5sbAXMNsZ/JgkuJP3kzpGMRRSNywztwMkgFTxvtZJRi2
79027uTt8N3v6PXTXROhaPvNWt2ttbXfTb/g6H3d4p/Z18VfBXU/i58B/C3w3vP2nvgB4V8ePM1p
4ev408YeG9al0gxpcbtP82dGgD+Q8l3ZzWTzWUyLFDK0qL86fHT9nDw/+yd/wVQb4b+GPEvgrxZo
Hhjxnp1ra6j4wlibQsNJBI0GrNCxQwQO7QXRXbxDN8kZyi/NNFY1MVBxtGFtbrXZa+6tNtVvfVaW
uzVU5Xvfp/T3O1/aS/5OK8ff8iV/yMeo/wDInf8AIu/8fUn/ACDf+nL/AJ4/9Mtlfa3/AAQq+369
4Y/aP0vSPhHpvja8T4Ta+JdRSHVp7zVDcLarb6G629ysPlzvBI6iKJLxiJdk4CgJ+elFZ4fEeyrq
s1ez2CpS5qfIfov/AMEUNan8bp+07B4e+CXhzXJLv4YeJJF+xx67dSTi6+zfZvDqBL4gwSGGQx4B
vn2SYuW2nbH/AMEWfEj+K4f2nItD+CnhrWWvPhj4kcNaR67ctKLr7N9m8OqEviPIkMEhjwPtz7JM
XLbfl+Evg18GvFP7QvxQ0XwX4K0O/wDEfijxDcC2sNPs03STvgsxJOFRFVWd3YhERGZiqqSKXxG+
H2sfCX4ha94V8Q2Z07X/AAzqNxpOp2hkSQ2tzBK0Use5CVba6MMqSDjgkc11UMY6cac3C6g3r3b6
baW7a+hEqEJSkm97fh8z79/4Iqaqnju2/ahh0n4LeHdWef4W+JZ4ZLJdankka6Ft9l8PLi+IMEhh
lMYAN/JskAuGAO13/BE/WJvG8P7UMegfBTw1rJn+FviWcvaR67dNIt19m+zeHVCXpBgkaGTy8D7c
2yTFyQpK/C4+A/ihvgG3xOWxtG8Fp4gHhd7wajbGePUDbG5WJrXzPtCo0SsRKY/KYoyhyylR6HZf
8E2vjRd6dFqEnhCDTtGk8M6X4wk1nUtc07T9ItNM1ORo9PmuL2edLa3e4dXEcMsiTMY3wnyNh0MZ
NKlaF+Rv53+Xr39NCalGL5k5b2/C3n6H1B/wRV1e48ar+06vh/4LeHNYEvwu8SzMbRdauPOW6+zC
28PDF6cwSNDIYgv+nuVfFw235T/gih4gk8Vw/tNwaJ8E/D+vtd/C7xK4ezTXLh5hdLbm28PgJeke
Q5gkaPC/bn2SYuTt+X5y0/8A4JW/HK8tfiBPc+FdF0OH4VarFo3i19d8W6Noy6DcTbfs5mN3dxYh
uNw8icZhnw3lO+04474yfsSfFD9nzw34h1Xxn4Wfw/beFPE6+DtVjub+1N1Z6k9s11Eht1kMxhlt
0aSK5VDBKqkpI1OnWq0lTc6btBvyvfptpaz7/gDjSnzR5lrbr93XzX4H15/wRV1r/hMYf2mINH+C
nhzXWuPhh4klWS1GtzPKblbc2vh9dl7jyJDBKYwo+3SbZALhsfLL+z1Dc/FT/gjH4gs/Cfw9g+LW
rL8eJNTf4YWaahfWvhezl0LCapHFYTpqoV2RrYSXdzLAVtgFHmiV2+HP2hP2e/F/7K3xg1jwF480
kaF4s0Awi/sRdwXfkGWGOeMeZA7xtmOVD8rHGcHBBA4ysvrbpqNOcdYuV/npa1tLdnf0NPZqV5Re
9vwP2b+Evw+1nxv/AMHVfiLxF4cn8ReOvDnhO/mXWPEMFul1b6LK/hmaFLO5mt40ih8udHs1WUrI
TblHZ5Q7H5v+Bf7NHiP4a/8ABMDxHeeEvg6uuftK6Z8WodN8Q6Tq/gS38T63pPhiTQlubV30m9t7
g2cEly0jC5+zx+blV81wgVfz0oqqmYKbbcftSlv/ADW8t1bR/gZQwrSte+kVt2+fXsfqp/wT70zx
B/wvn9sHRNQ/Zw+HVn4mtPh34ij1aw8KHVryyt76eC2KeHUFnqM1vFHNLbXD+RBtuUkFxFHLEkXl
Reb/APBN/RPGmtf8E+f2wPE/gP4eC+u9cv8Awxb+H9FtvCreJNNmmj1R5rm0gt72O6W5FtbzRsVl
MssayQyMSTvr886KlY6PurldlzdVf3vO3T8eyNFQSvrvb8PmfrR+0R/wT5s9e/aX+NviDwvonjLx
p+y74B8cQx6d8MPh9c3V5/wlPi5tItJby1jtrVZU02GF5WW5umjTyov9GtwZAEi634nn4l/GT9jf
xbYfGj4K6p8ZPitoH7RI8QeNPh/4Wvt1zFpt54Lig0x/M0xri5htYhFD5crZWUxFDJJIJiv41UVs
8zjzOUIWu27XTWt9LONmlfRPTfTXSFhpJW5tkltrpbz621/4B+7X7UehWviT/glb+z/4Fn+EfiL4
7678NNU8N3Xjv4d6Ld3NvrekfaPBjw20dylqsl5YokixynfAqO4ZQzM0oX82P+Culr/YPjz4JaBd
m6tvEHhf4M+FtK13TLoNHdaJfJbyM9pNEwDQyKjxuY2AI8zJHNfJlFY4rHRrU+Tktrfp5+V+ve3Z
as0p0pRd2/w/4IUUUV5xuFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfdv/BtB/wApr/g5/wBcPEP/
AKjup1/WXYf8ekf+7/Sv5NP+DaD/AJTX/Bz/AK4eIf8A1HdTr+suw/49I/8Ad/pQBcg6miiDqaKA
Pjj/AIOjv+UFHxz/AO4B/wCpDplfzh/8Ea/FWnWvxR+M3g2a/tLTxD8WvhB4i8DeFbe5uI7aLVtZ
vFg+y2ZmlKxRNKY2VTI6Bn2ICWdVb+jz/g6O/wCUFHxz/wC4B/6kOmV/IFW+GreyqKpa9jOrTU4O
D6n35+yVpB/Za/4Jy/Ejxd8cvD998QPhNc/ERPA1v8JLq6m0u6s/FtvBDdT6nLOV83S2js0e2LW6
tNcEtDKqRxhq+pfFvwT8e+KPgL+1R4z0/wCG83xQ8JfFfQvAOv8Aw58NRaDf29smhtdvJaaKlvpj
w7ZtPs5IGkitZWA8tZHZhI+/8XqK6aOOVOKhy3Sv23aavt0votvLVmUqDcnNPX/hvPy/qx+zGrat
Yfswf8E0/iT4C+Nfw903wP4I+In7Tl1pPinw7putRz3XgTTtR0Sw1O2uLN7GNonaz8qzlRQjxzLb
yQmGMklfLP2u/AfiLx1/wc1Xl7a2KxweB/EnhrxTrt9JdIlpo2kabYaZcXOoXNxN5ccUSQRb2Zyo
3MqKWZl3fl1RW080vCNPl0Uk+l9HJ2ei/m7WWumpCwr5nO+rTXlql5+X9dfT/wBtz4iaP8Xv2z/i
74s8O3n9o+H/ABR411nV9MuvKeH7Ta3F9NLFJskVXXcjqdrKGGcEA8V9U/8ABMz9n/xr8dP+CYX7
XWh+EvCesa7qXi658GaVo5gtn8u8uYdZEs8SykiIeVFIkspY4ijxI5RMk/A9FcNOtFVXUqK976J2
3+TN3S9xQi9rfgfsl+39b6F+0joHxq+LP7Ofhrwv8ZPiNcfGLTvC13LYeF7bxtcwaBa+FLaOOWOy
ubW4WG2e/gvFW8jQLO0GEkdI1Y9d8XP2ev2Q/wBnC6+KGv8AjTwT8N7n4f638cj4F8QXVrJeXTeH
raHwnDqoh08WWZ7GT+2vOikFvhQpmt2RY4gI/wAP6K75ZrzPnlBN3vrqr+90t15tddbLytzrCNRU
FLRK3n06/L8T90/2jfB/h/xX/wAEyPhHcaX+zro3xHttf8Z6J8RPEvwt+HF3e2BlTUvBJgj1Bra0
gafToWu4mVTGZIpTpzZfzZJwPzb/AOCucF3o3xP+D+hapYrpWueGPg54R0nVdPlnlN7p9zHp4Lw3
cEiKbWcBlzDz8hjckNIyj5QornxWNVaHLy2d79PPy8+/TzZpSw/JPnv08/Lzt+H5H3T/AME8dX1n
4Xf8Eqf2xPGNrounzQq3hC0sLzWNDg1TTZrhdVKzQ+TdxyWszrFco5V0Zoy0TjadrV9t67/wTs+G
vwg/bJ+KfiXRPDfhTWvD+n/FDQ9F8S+Cxp+hNpngXQG8PQ6zf+ILybUrO7a00+RpL2NYoBZrm3aO
KYssUcX4d0VeHx6pxjGUb8rT37c3l1ur+n3Kph5Sk5KVr+Xp5+T+8/UTw7+yha/CG7+P3hTw38EP
FK6x4V+MU+m2Wu6V4E0j4n6nY6Ebe6ew099A1SZLi1tpY9lzHqm1kugNm/MXzfFn/BSr4cRfCP8A
bs+JnhyJPAEQ0zVyjx+CopYNFhkaNHdIoJZZWtpFdmWa2EjJbzCWJMJGoHh1FY1sTCdPkjC2t9/X
S1vP8PuunSlGXM3fS39a/gfpp/wTI+H/AOzZ4M/4Jq2/j747+FvC+raT4x+Ms/gfxLrGow31xf6J
pVv4e/tOyayNkftFtJJqChHeIfvY3dHyq5T6ds/2Kfhtr+n/AAs+OOm+AfAK/wDCyrHwje+PvBWl
6PoVpoHgnTZNKuNRvPEd0dTtbz7FprpHNCI7c2nmtZSD7S9wwCfhdRW1DMFCEYSgnyu91o3vu7dL
6GcsNLnlUjLV/NLbpc/S3xV+x98Pfhb4A+Nnh74x+Fofhb8IvCnx1/snwr4v03TftHi93kaMtpTC
WKS5k0v+xmW9jllaMByJYlvndoK2v2S/gRe+If8Ag4o1fwP40+C3wy0zRgL+LWPCOneH7XWfDml2
CaTvsbgB4SsXmSCwkacRwOZbhlZITK8A/LiirjmMYuLUNFJS6bK/u7ba/ne+lrnRlKLi5bq34LX+
v+H/AE//AOCdnwe/Z++DH7AUniP9pDwHpHl6/wDGu++HnjO+1yx1A6t4XsrLQPt9rFbpakXVnO2p
KYpWRQXjMscgKrlPov8AaC/Zu+EfxK/Y9/Zt+IPhz4SfDLSNf8QfEXwZ42+JlvoXh6CO18P6BdaO
rXc90pVzZ6IzwS582QWpaCdm/eLO7fhrRSpZjGEIw9mvdd+l3vu7ef599JlhrzdTmd3b008vM/ZD
TP2dv2cv2b9H+Lmq/HP4feG9J8M+If2k9f8ABWp3F9pV2l14e8Pw6S+raQdPgslWe0jmuGgAktgF
mtpSpBjCsvxH/wAFfvCnhrTfiv8ACXxN4b8H+HfA5+JHwm8OeLdV0vQbE2OmJf3MMgleCDcViQiN
MBeDgs252dm+S6KyxGNVSl7JQS1vdb7vd21Svp/SVU6DjJScr6W8vU/Qf/giv8dfBnhfVPCPgHw9
Z/EfQ/jl4t+Jem3Fz4h8NaJDqi6v4YgNvNJo8rtdRTWVuZoZri5ngR90EeJVkjTaPnv/AIKv+Fh4
Q/4KW/HO1EOuQC48aalqAXVtNOn3B+0ztcbliLuTCfNzFLkedCYpdsfmbF+fKKmeM5sNHDtbO9/0
t+pSo2q+0v0t+X+R9w/sn211+2z/AMEvtR/Ze8C/Zbj4vaf8VB8SNJ0a+vo7NfE1i+kiwuIbKSTb
F9pt/LE8iSyR7oA7JuMTrX05+3P8QdH/AG1P+CUXhb4DfBnUrf4qeP8A9nvXdCHiGx8NLPcvq1tb
aCumXGp6bEyLJfWaXbJCZYlZwBvaKKDy5ZvyCoohjOWnycvlfy1/HV669NNNVKi3NyT/AK0/yX4+
Vv0+/Zy/Zn8V/CH9gj9t7SfiZoniTx8mgW/gfTdT/wCEZ1UzSRvp7C4utOj1IwXMKPpUD26XUYil
SBbcplFEclXv2lvj744/4K3/APBMbx/4h8MeCLnWPFupftD2+u3XhXwsLjWb/RtO/wCEWi0+0mmt
44zII2FosZuTtSaZJAqR7QlflnRWrx65VTs+XXS6vrzW1t05vP8AEz+rauTeunT/AA369eU/aj9s
+x0b4yftIftG6n4W+HupeLPE0XjvQLG78XeFfAWgfFe7toY/DkUMulS6Pe3Ky6ciXccp+2RqRLKk
lu7I9qEP5j/8FJ/h7b/Cn9uv4meHrb/hXwj0zWGjK+CYZrfQ0cojOsME0krWzh2YS24dkgmEsUeI
41A8Pop43MI4hP3LNyb37tu1rLvvvpr5XRocjWuiSW3ZL/IKKKK8w6AooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooA+7f+DaD/AJTX/Bz/AK4eIf8A1HdTr+suw/49I/8Ad/pX
8mn/AAbQf8pr/g5/1w8Q/wDqO6nX9Zdh/wAekf8Au/0oAuQdTRRB1NFAHxx/wdHf8oKPjn/3AP8A
1IdMr+QKv7Gv+Dj34X+Jvjh/wRk+MvhXwV4d13xf4n1P+xPsej6JYS6hf3fl67p8snlwRK0j7Y0d
22qcKjE8Amv5Yf8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU
/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat
/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL
/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6
P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8A
Dfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dq
f9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/
AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx
8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXv
n/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG
+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8A
Rtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4
HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5
/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/t
Rf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/y
PQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCj
bfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4
dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9
q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai
/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5
Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/
AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6
n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+
1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2
/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V7
5/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+
f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tR
f9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0Ae
B0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o
234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4d
T/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8
j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9
qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5H
o/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Df
at/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8A
Dqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1
b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8f
P/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe
+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o234+f
+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+1F/0
bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8AI9AH
gdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBqL/o2
34+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8Ah1P+
1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfat/8A
I9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op/wBq
L/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR6P8A
h1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP/Dfa
t/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+f8Op
/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b/wCR
6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0bb8fP
/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHgdFe+
f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+G+1b
/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1F/0b
b8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI9AHg
dFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o234+f+
G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU/wC1
F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat/wDI
9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL/o23
4+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6P+HU
/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8ADfat
/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB4HRXvn/Dqf9qL
/o234+f+G+1b/wCR6P8Ah1P+1F/0bb8fP/Dfat/8j0AeB0V75/w6n/ai/wCjbfj5/wCG+1b/AOR6
P+HU/wC1F/0bb8fP/Dfat/8AI9AHgdFe+f8ADqf9qL/o234+f+G+1b/5Ho/4dT/tRf8ARtvx8/8A
Dfat/wDI9AHgdFe+f8Op/wBqL/o234+f+G+1b/5Ho/4dT/tRf9G2/Hz/AMN9q3/yPQB7j/wbQf8A
Ka/4Of8AXDxD/wCo7qdf07ftQftUx/smeCNI1u88BfEHxrpuoXIsppfC9rZXH9mSNtERuBcXUBVZ
GYqrqGXcArFS8Yf+en/g3q/4J7/Hz4M/8Fe/hR4k8YfA/wCL/hTw7p0Oui61TWfBuo2NlbGTQtRi
jDzSwqi7pHRFyRlnUDkgV/TzLoi3NjJbTWUs1vNGYpIpLVnSRCMFWBXBBHBBoA5v4SePpvid4Ktd
am8OeIPC32wbksdaW2W7CYBDkQTTIAcnHz54zjBBJXV/ZZNxPkXZJ/6d3/wooA47x9PpPhuXXNW1
a6stM03TvtF5e3t5OsFvaQx7nklkkYhURVBZmYgAAknArzP9lf8AaE8P/tdfDe98YeHNM1C18Mtq
s9hpF1fIYZdYtokjxeCFgGhjkdn2I/z+WqM4RmMaeyazEy69eMroD57kfNyPmNc14C+GOi/C7QpN
L8PWNrpOmPcyXSWcGFgt2cLuWJQMImVyEHC5wuFAUAGAfCXhzXPilrcWvaTo+q21lo2nSW0eoW0c
6QvJPfh2UOCAWEaAkf3RV/8A4Vz8Nc/8ih4H/wDBXa//ABFcp8YP7T0Lxte3NtYX13DqWmWVuklr
aTXIVoZrxnB8pGIOJo8ZwDk+lcX/AGxrf/QJ17/wS33/AMZppAev/wDCufhr/wBCh4H/APBXa/8A
xFH/AArn4a/9Ch4H/wDBXa//ABFeQf2xrf8A0Cde/wDBLff/ABmj+2Nb/wCgTr3/AIJb7/4zTsgP
X/8AhXPw1/6FDwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3
/wBAnXv/AAS33/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3
/glvv/jNH9sa3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A
4ivIP7Y1v/oE69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/
AIVz8Nf+hQ8D/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8A
hXPw1/6FDwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBA
nXv/AAS33/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glv
v/jNH9sa3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivI
P7Y1v/oE69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz
8Nf+hQ8D/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw
1/6FDwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/
AAS33/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jN
H9sa3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1
v/oE69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+
hQ8D/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6F
DwP/AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS3
3/xmiyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa
3/0Cde/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE
69/4Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D
/wDgrtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/
AOCu1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xm
iyA9f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0C
de/8Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4
Jb7/AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDg
rtf/AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/AOCu
1/8AiKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xmiyA9
f/4Vz8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0Cde/8
Et9/8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4Jb7/
AOM0f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDgrtf/
AIivIP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/AOCu1/8A
iKP+Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xmiyA9f/4V
z8Nf+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0Cde/8Et9/
8ZosgPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4Jb7/AOM0
f2xrf/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDgrtf/AIiv
IP7Y1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgPX/8AhXPw1/6FDwP/AOCu1/8AiKP+
Fc/DX/oUPA//AIK7X/4ivIP7Y1v/AKBOvf8Aglvv/jNH9sa3/wBAnXv/AAS33/xmiyA9f/4Vz8Nf
+hQ8D/8Agrtf/iKP+Fc/DX/oUPA//grtf/iK8g/tjW/+gTr3/glvv/jNH9sa3/0Cde/8Et9/8Zos
gPX/APhXPw1/6FDwP/4K7X/4ij/hXPw1/wChQ8D/APgrtf8A4ivIP7Y1v/oE69/4Jb7/AOM0f2xr
f/QJ17/wS33/AMZosgPX/wDhXPw1/wChQ8D/APgrtf8A4ij/AIVz8Nf+hQ8D/wDgrtf/AIivIP7Y
1v8A6BOvf+CW+/8AjNH9sa3/ANAnXv8AwS33/wAZosgG/Hj4oeFfhH4t1jTdL+DXgDxDDpmh6Zqs
Vw8tvZ/aJrzVv7PNvtFpJtEaZm8zJLEbNgzvHb/CSHwJ8RtL165v/hv4F0X+yfEWpaJbqLa2uftk
VpcNCtwSYU2GTaW8v5tvTe3WvOdY0BPEs802o+GNfubi4t7a1lcaVfLujt7k3UQx9nPSU5+n51et
Li+0m0khsPD+vW0c95c38v8AxKL5t808hkkb/UDALE0WA9i/4Vz8Nf8AoUPA/wD4K7X/AOIo/wCF
c/DX/oUPA/8A4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz
8Nf+hQ8D/wDgrtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17
/wAEt9/8ZosgPX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4
zR/bGt/9AnXv/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2
Nb/6BOvf+CW+/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX
/oUPA/8A4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+
hQ8D/wDgrtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAE
t9/8ZosgPX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/b
Gt/9AnXv/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6
BOvf+CW+/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUP
A/8A4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D
/wDgrtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8
ZosgPX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9
AnXv/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf
+CW+/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A
4K7X/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDg
rtf/AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8Zosg
PX/+Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv
/BLff/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+
/wDjNH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X
/wCIryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/
AIij/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+
Fc/DX/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLf
f/GaLID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDj
NH9sa3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCI
ryD+2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/AIij
/hXPw1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+Fc/D
X/oUPA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLff/Ga
LID1/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDjNH9s
a3/0Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCIryD+
2Nb/AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/AIij/hXP
w1/6FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+Fc/DX/oU
PA//AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLff/GaLID1
/wD4Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDjNH9sa3/0
Cde/8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCIryD+2Nb/
AOgTr3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID1//AIVz8Nf+hQ8D/wDgrtf/AIij/hXPw1/6
FDwP/wCCu1/+IryD+2Nb/wCgTr3/AIJb7/4zR/bGt/8AQJ17/wAEt9/8ZosgPX/+Fc/DX/oUPA//
AIK7X/4ij/hXPw1/6FDwP/4K7X/4ivIP7Y1v/oE69/4Jb7/4zR/bGt/9AnXv/BLff/GaLID1/wD4
Vz8Nf+hQ8D/+Cu1/+Io/4Vz8Nf8AoUPA/wD4K7X/AOIryD+2Nb/6BOvf+CW+/wDjNH9sa3/0Cde/
8Et9/wDGaLID1/8A4Vz8Nf8AoUPA/wD4K7X/AOIo/wCFc/DX/oUPA/8A4K7X/wCIryD+2Nb/AOgT
r3/glvv/AIzR/bGt/wDQJ17/AMEt9/8AGaLID15/hz8Ndp/4pDwPx/1C7X/4ioPhLommJf8AiyCx
trS20+11dEtoLZFSCFTYWblUVeAN7scDuxrydtX1sqR/ZOu8/wDUFv8A/wCM16j+zdZXdv4e1ue9
t7mya91NZY1uoXt3dVs7WItscBgN0bAZA6UmgO5/sO2/55ij+w7b/nmKuZX/AJ6Rf99CjK/89Iv+
+hSAp/2Hbf8APMUf2Hbf88xVzK/89Iv++hRlf+ekX/fQoAp/2Hbf88xR/Ydt/wA8xVzK/wDPSL/v
oUZX/npF/wB9CgCn/Ydt/wA8xR/Ydt/zzFXMr/z0i/76FGV/56Rf99CgCn/Ydt/zzFH9h23/ADzF
XMr/AM9Iv++hRlf+ekX/AH0KAKf9h23/ADzFH9h23/PMVcyv/PSL/voUZX/npF/30KAKf9h23/PM
Uf2Hbf8APMVcyv8Az0i/76FGV/56Rf8AfQoAp/2Hbf8APMUf2Hbf88xVzK/89Iv++hRlf+ekX/fQ
oAp/2Hbf88xR/Ydt/wA8xVzK/wDPSL/voUZX/npF/wB9CgCn/Ydt/wA8xR/Ydt/zzFXMr/z0i/76
FGV/56Rf99CgCn/Ydt/zzFH9h23/ADzFXMr/AM9Iv++hRlf+ekX/AH0KAKf9h23/ADzFH9h23/PM
Vcyv/PSL/voUZX/npF/30KAKf9h23/PMUf2Hbf8APMVcyv8Az0i/76FGV/56Rf8AfQoAp/2Hbf8A
PMV5X8ZP2nPDXwI/aB+GngXXNNuxF8SrbVZINWjbdBpktk1iFWdMZEUn2wgy5xGY13DYzPH7AAp/
5aRf99CsLWfhhofiL4jeH/FV9BFcaz4Xtby006RnUpAt01s0rYxnd/oseDnA54JwQAdn4Z0yCz1m
zKQxo4dhuCjP+rfvXY1yXh+ZH1izAkRm3scBgT9xq62gAooooA/E39qzWdOi/ai+JKv4V8BXDr4p
1MNLceE9MnmlP2uXLPI8BZ2PUsxJJySSa4OPVdLm3k+E/htFHGjSSSSeENISOJFBLOzG3wqgAkk8
ACt79ri62/tW/E4Z6eLNV/8ASyWuX0fxnYfDkQarfRpK1oI7uGJwCs9wXbyAR0Ii8sylT/G9s38B
B+1o01KKSXQ+QxFVxbbfU9g+HP7Mi+MdOjv9X8P/AAt8I6ZKA0cmqeAtOuL+7U/xR2axRGFCOjzy
Bz3gAwT1x/Y6+FZOf7YtvMx0/wCEC8KeRn12/wBmb8e3mdO+ea+ZNV+LPiz48eIorDS9UurbLB7m
WM5Zs54yc+3513uh/BbxV4J13QLJNbv5rrxBcPDHHO5kGEieWR8HsFQ9+rCvgc58Rcqy3OlkmIv7
TraMWl7vM731do6u3nZH3OE4BxmI4d/1jlXhGDUnGLlNSkotx0srK7Vo669WdV8Sv2XF8JadLf6T
4f8Ahb4u02IFpJNL8Badb39qv96SzaKUzIAOXgkLjPEBAJHkM9xpULL/AMUn8N5EkRZI5I/CGkOk
qMMq6sLfDKQQQRwQa6Xx58TPG/wa1RBcQRI8cgxPHcMEHP3sYyPWuX1bxxZfE6yfWbKNIGvVe8ni
RQqwXAZfOAHYS+YJQo6Oly38QA+uy3NMDmEHPBVI1Erax2176Wvpt+B+e08VefJdprp2EN/pWf8A
kUPh5/4Ruk//ACPU9rc6RIRnwh8Oz/3Julf/ACPXM/bvc1Zs7/BHNehyx7HVzy7nY2dvoU2N3g34
dn/uT9K/+R66Hw/4K0XXmZbb4f8AgS7aMZYQ+DNNcqPU4t64XTr/AJHNfb37Fn7Po+JX7NeobtM/
taw8TXBjvo5D5YAhlyirIs0TjlAxAJ/I4r5/inO/7JwP1mlSU5tpJebu9bJu1kzpweDr4pzhRa5l
FtKUnFN9E5JScU20m1GTS1UXsfPdp8JdFOPN+Gfgpfr4L08f+29Wk+Gfg6F9k/w9+H0b4ztbwlpy
n/0RX3f4y+H/AMTbr4QWvhLw1qF94Wg0mwh07S5rLyT9jii8tVDhrotN+6Qp87fxljk4Ncd8Rvhv
baB8O7VdW8Fadq/jSz0uBLnVNY1cxNr9wqpE8kQ+0pDExIeQqXIQAKAcivj8v8R/a4iNGth1FOyv
L3FzOytzSvBK+8pyiktW0fQ4jhlU8D9Zdf31e8I802kldtJRTl2SinNtfBqj5I/4Vl4H/wChB+Hf
/hK6d/8AGaX/AIVl4H/6EH4df+Erp3/xmvp7TP2fPAd58P7C+v8AxP4P07XLu0inutMfzZHsZnUM
8HmpeiN/LJK7lGG2Z5zmvmvxTCnhvxNqGnpcpdpY3MkCzp92YKxUMPY4z+NfW5BxbhMzxlTAxpqM
4R5tJQmmr2dpQbW9uuzvseJmGU1sLQjieduMnbVSi1pfVSs/w0Ko+GXgf/oQPh2f+5V07/4zSj4Z
eBv+if8Aw7/8JTTv/jNQjVR/epRq2P4q+x9nT/lX3Hie0qfzP7yYfDLwMf8AmQPh3/4Smnf/ABmn
f8Kw8Dj/AJkD4d/+Epp3/wAZqEat712ngPS9Fl8JXmq6tBNcbLlIURJpFaTI+4iq6jJ5+gBJwATU
VXhqNOVataMIq7bskkt229kuooyxE5wpUk5Sk7JK7bb2S830OTHww8DEf8iB8O//AAldO/8AjNOH
wu8Dd/AHw7/8JXTv/jNdtrOh2/hyS3Oq+CG04XUS3EUdxqN9E80TDIdSXUMD6gYrVh8J+CPF3wu8
Q6hY6ddWOr6XplxcGH+17tzC6xMVcAy4Ybh3HbkEdfmcg404bzrFywOXV4zqx3i4uL9VzJXXmrnu
59wxxBk2Ejj8ww8o0pfaUoyXo+Vuz9bHmw+FngX/AKJ/8O//AAldO/8AjNPHwr8C/wDRP/h1/wCE
rp3/AMZrQ8aaTF4L8SSWUE1xLBm4K+c4Zl8u+u7dRnAJ+SBDzk5LdsAZyatz1r62dCnGXK4r7j5y
hi5VaaqRbsx6/CjwKf8Amn/w7/8ACV07/wCM19E/sO/sDfs/+Nv2KPg9r+u/Av4M65rviLwPour6
nqGo+CdMu7q9urmwgnmleSSFmJaSRjycAEAYAAr53TVfevr79h/xCNK/Ym+CVoWx5Pw58NLj/uEW
leFnFKN4KK7/AKHu5XUlabk+36mw3/BOT9mwf827/AX/AMN7o/8A8j1zXxG/ZD/ZI+EmnR3XiP4K
fs66NFMSIhceA9HV5iOoRPs+5yM/wg11/wAd/jxF8GvhfqmvFUnubePZaQM2BPO3yxoe+NxBJHIU
E9q/HLV/jj44+OXxhuH1h9R13xhqd0bX7OimRw+44hiQfdQHoowAOfU1+fcQZ9DL3GjTjzVJa27L
u/Xoj9m8K+AqPF2OxGHq4pUlQipyWnO4ybV1fRRVnzSd7aaan6Nt4b/YdMqqPhP8A4t/AaT4X2MS
fizWQA/E16Bo37FX7M/inR4dQ0j4Hfs/6jY3I3RXNr4E0aWKQdMqy25B5r89pf2YPitq1kRBpulX
EwUs1vBrlnNOAOvyJKScd9ucV137Jfg747fs9/Eu3vbfR5J/C99MF1fT/wC0YfLljPBmRS+BKg5B
43Y2k4PHytfxGoZRiYUOJOTDqeq5vcdu9pvVd7H3md+D/D9bL6mK4bzaFWpTv7rq05KTWvKpQtaT
6Xum9NFqvt2X9hT9n6Pp8BfgaPp8P9I/+R64P9oj9i74I6H8M0v9L+DHwg0y9tNd0NVls/BemW5a
ObWLK3mjfZAA8bwzSqUbKnd0yBXqUPixZ41kV9wcZB9a5T4+68Lj4QX/AM2dmraC35a7p1fsEKMN
JLyP5mdaWqZ8u/tR/syfDPRvixpOjaZ8OvAGl6T4o1TwXZXttZeHLK3Qx3fiQ2V0E2RAxmS3+Rim
MivrmL/gn7+zfgD/AIZ8+BeB6+AdJJ/M29fOX7SN4L744eATwc674Gf/AL58Wk/0r6hh8cZ/jrav
h1JpW6fqzKjXcU3fr+iMTVv2Dv2adH0+e7uvgJ8BbW1to2lmml8BaOiRIoyWZjb4AAGcmvANe8Q/
sZ6VrL2tv+zz8LL+JG2/a7f4Z6KITzjI3xq+O/3a7D9v/wCIF2vwJitrWZ0jv9ThguQv8cYSR8H2
3on5V83fsp/s66r+1Z8YbTwpplzFYK0T3d5eSIXW0t0Khn2gjccsqgZGSwyQOa/SeEuCsqr5ZUzX
NZNQjfbRJLdvRtvsl+Nz8E8SfFDiDA57R4e4epp1JKOrV3KUnpFapJd2/wAEtfdF0z9jC7EYj+E3
wOieQD5X+GFiuwnsT9jxx9cV1+jfso/s5eLNMW90f4M/Aa/tGOBLbeBdGkXI7Ei34PseaqD9hz9n
bVPHMvgGy+L+tp4+jmNltljja0+0jgxj9yqM27jYJ92fl6189+PdF8T/ALC37Q2qeHmv4rubTHj8
4wMVg1CB0EiFl/hJVhweVOcEjk60+DMlx/NRyqdSNZR5lGrDl5o94txjprvqYS8U+JsolDEcRUaM
8M5+zlPDz5nTna7jJKc/eSTbjps7O+h9G3H7G3wNjPy/BD4KL9PAOkf/ACPVY/sf/BNTx8FPgxj2
8B6SM/iLer+geOYPE2i2moW8haC9iWaMt1wwzg+9Xl1sZ6j86+ElgYwk4Tik15H7hSxzqwVSnO8W
rp33T2Z4J+zn+yp8LPGv7Xek+GNf+Gvw+1jw5o+l+NLuHT7zw5ZSwSPaa9p1namVWjxL5UFzKqiT
djdnqAa+tR/wT3/ZvI/5N7+BP/hAaR/8j18+fs6Xgs/20J7nOPK0Pxwmf97xPo/+FfUSeMQQPn/W
vMr4dSm3bt+SPSo4hxgte/5s5uX/AIJ8fs4p/wA2+/An/wAN/pH/AMj1Uuv2Av2dYhx+z/8AAsf9
yBpH/wAj15J8VbIeM/ixrOLHQrueXV5ImuNS06C7W1todL0+ZiWkjcpGgeaQ7fVjgmsa58IeH9W8
LPd6bZeHZ5yWMXm+GNPhEyqOTsERKgkHBJ6DJC5IGOeVMqyTD4fFZrXVONecaafK2lKabXM1svde
r076XtyZbjcwzPE4jC5dQdSVGMptcyTcYtJ8qe795afra/r95+wl+z7FnZ8BPgcv08AaR/8AI9Zd
3+xH8Bovu/Av4Ir9PAOkf/I9fPraVpN9ptnNcL4D0tr+eW3t1uPD8TNM0SxM+PKtXAAE0f3iM546
VyXxc8KWngm88RaXJe+AptY8P6Zb6re2VtoYWWK2uRbmKQO1osZyLuA4D7hv6ZUgfe0uCFdRc1r/
AHX3S9N2l6nw0vESD5lGm247rmV1dXV1vqldd0fUE37GHwOj+78EPgqPp4C0j/5HrkPjp+yB8HdO
+CPjO8074RfCbTdR0/Qr69s7qy8G6ZbT288NvJLG6vHCGGHQcZwRkHINXf2WNXA+B2koJGZIri9i
jy27CLeTKgyecBQAPYV0Pxh1ETfBfxsmTz4c1P8A9I5q+dr4GnSlKFlpfp2PscPjZ1Yxnd62e/c4
ZfgF8Pcf8k7+HP8A4Sun/wDxmnD4A/D4f807+HX/AISun/8AxmugW4p63HNej7Cl/KvuOH21X+Z/
ec8PgD8Pcf8AJO/hz/4Sun//ABmg/AD4ff8ARO/hz/4Sun//ABmuk+0UCeq9jS/lX3C9tV/mf3nO
D9n/AOHuP+Sd/Dr/AMJXT/8A4zR/wz/8Pf8Aonfw6/8ACV0//wCM10onyKcJRR7Cl/KvuF7ap/M/
vOY/4Z/+Hv8A0Tv4df8AhK6f/wDGaP8Ahn/4e/8ARO/h1/4Sun//ABmup833pDL7mj2FL+Vfcg9t
U/mf3nL/APDP/wAPf+id/Dr/AMJXT/8A4zR/wz/8Pf8Aonfw6/8ACV0//wCM11Il96PN96PYUv5V
9yD21T+Z/ecuP2f/AIe/9E7+HX/hK6f/APGacP2ffh4f+adfDn/wldP/APjNdOJfcUvmUKhS/lX3
B7ep/M/vOX/4Z8+Hn/ROvh1/4Sun/wDxmqOrfs7+AmhPl/Dz4dg/9irp/wD8ZrtxJ7mjeD1o9hS/
lX3IFXqfzP7zx66+Cfg3Sbksfh78PGQf9Spp3/xmut8DfDH4aahMkdz8Ofhxnvnwrp//AMZrqNT0
yO7iI2jJri9U0m5029aS3yPTFZ+xpx+yvuL9tOS+J/eeg6l8AvhQLDevw5+G4P8A2K+n/wDxmvJv
E/wl+H1trLpD8P8A4dbB0A8K6d/8ZrbjutVu4QhZwPrTbLwXPc3fmSsxJpyp03tBfcEalRbyf3jt
A+Bnw/vLRWb4efDok/8AUq6f/wDGa0T+z98PT/zTv4df+Erp/wD8ZroNG0/7DbKvpV2qVCl1ivuJ
depf4n95yDfs/wDw9UZ/4V38Ov8AwldO/wDjNc74q+FXw60u3Yj4ffDlSP8AqVdO/wDjNek6mSLf
jrXkPxC0zUNQvZFQOVPpUTpU0vhX3Fwq1HvJ/eXPBfwx+HV7fqZfh/8ADpkOOvhXTv8A4zWr4w+G
3w2trVkt/h38OQ/t4V0//wCM1znhPwpqEQUnctdfYeDXncNMSxPrUxpQa+FfcVKrO9+Z/ecxoHwL
8FanOJG+H/w82N2/4RTTv/jNdVbfs+eAFjAPw8+HX/hK6f8A/Ga6PStKWxiCgdKvFwK0jh6S3ivu
M5Yip/M/vOS/4Z++H3/RO/h1/wCErp//AMZpD+z/APD8f807+HX/AISun/8Axmut8z2ppOar2FLp
FfcL29T+Z/eck3wA+H5PHw8+HX/hK6f/APGaafgD8Px/zTz4df8AhK6f/wDGa60yUxmx9aXsKX8q
+4FWqfzP7zlP+FB/D/8A6J58Ov8AwldP/wDjNNb4C+AM/wDJPPh1/wCErp//AMZrqyxNNJwKXsKX
8q+4r21T+Z/ecr/woT4f/wDRPPh1/wCEpp//AMZoPwE+H/8A0Tz4df8AhK6f/wDGa6kPSM2fpR7C
n/KvuD21T+Z/ect/wob4f/8ARO/hz/4Sunf/ABmkPwH8Af8ARO/h1/4Smn//ABmupJxSFgKPYU/5
V9we2qfzP7zlv+FD+AP+iefDr/wlNP8A/jNNPwI8AD/mnnw6/wDCV0//AOM11JfNITij2FP+VfcH
tqn8z+85Y/AnwB/0Tz4df+Erp/8A8Zpp+BfgEf8ANPPh1/4Sunf/ABmuoZs/SmF/Sj2FP+VfcHtq
n8z+85hvgZ4BH/NPfh1/4Sunf/GaQ/A7wF/0T34df+Erp3/xmumJzTS+OlHsKf8AKvuD21T+Z/ec
w/wO8BD/AJp78Ov/AAldP/8AjNN/4Ub4CP8AzT34d/8AhK6f/wDGa6cmkLgVLo0/5V9we2qfzP7z
mG+B3gIf809+Hf8A4Sun/wDxmmn4I+Ah/wA09+Hf/hK6f/8AGa6Z271C8lL2NP8AlX3D9tU/mf3n
ON8FPAYH/JPfh1/4Sunf/Gaif4K+Ax/zT74df+Erp3/xmujeWoZJeKXsaf8AKvuD21T+Z/ec7J8G
vAg/5p98O/8AwldO/wDjNRP8HfAoH/JP/h3/AOErp3/xmugkkqF5KPYU/wCVfcV7Wp/M/vMB/hB4
GH/NP/h3/wCErp3/AMZqKT4R+Bh/zT/4d/8AhK6d/wDGa3ZZcVXkmpOjT/lX3D9tP+Z/eYcnwo8D
j/mn/wAO/wDwlNO/+M1BJ8K/BC/8yB8O/wDwlNO/+M1tSzcVXlm5qfY0/wCVfcHtqn8z+8x3+GHg
kD/kQfh5/wCEpp3/AMZqCT4a+ClH/Ig/Dv8A8JTTv/jNa0s1VZpaTo0/5V9w1VqfzP7zKl+HHgwH
/kQvh5/4Smnf/Gagk+Hvg1f+ZC+Hn/hKad/8ZrUkkqtK9T7KH8q+4r2s/wCZ/eZ0ngHwcP8AmQ/h
5/4Smnf/ABmoJfAvg8f8yH8PB/3Kmnf/ABmtGR81XlbNL2NP+VfcP2s+7M9vA/hAH/kQ/h5/4Smn
f/GajbwT4Rx/yInw8/8ACU07/wCM1ec80xzzij2NP+VfcP2k/wCZ/eUW8F+Ex/zIvw9/8JTTv/jN
Rv4M8Jn/AJkX4e/+Epp3/wAZq+y5FMIzS9lD+VfcV7Sfd/eZt14R8JwxFv8AhBfh7x/1Kmnf/Ga+
fP2nfiJoXgnT7lbHwX8P4pEzgjwnpp/9oV9H3dv50JX1rx34u/s/L48nlLDIfNYVqKcbRSNaNVqX
vNnxZ4X+MGqeL/FkccfhjwOIX7Dwhpf/AMj19o/ALwpp19ocUmpeDfAMr8Z3eE9NH8oKx/hp+yJY
+FruOVoV3J7V7hofh6LRbURxqFArDD4SzvNG1fFX0iwXwb4Ux/yI3w9/8JTTv/jFL/whnhQ/8yN8
Pf8AwlNO/wDjNXvLx6U4R/jXb7KH8q+45PaT7v7ygvgvwoTz4G+Hv/hKad/8Zp48FeFP+hF+Hv8A
4Smnf/GavCP8KcsX40/ZQ/lX3B7Sfd/eUR4J8JH/AJkX4ef+Epp3/wAZp3/CFeFP+hF+Hv8A4Smn
f/GavrHmnLDR7GH8q+4n2su7+8oDwR4TI/5EX4e/+Epp3/xmnr4F8JEf8iJ8Pf8AwlNO/wDjNaCR
VKsWDT9jT/lX3C9rPu/vM4eA/COP+RE+Hv8A4Smnf/GaePAPhHH/ACIfw8/8JTTv/jNaSx/hTlio
9jT/AJV9we1n3Zmf8IF4QVc/8IJ8Pf8AwlNO/wDjNeV/tBa/4T8CaBcvD4I+HiSR9CPCmm+//TCv
aJYS0ZArxP8AaE+Ddz47t50j3ESZ6VnVpR5fdivuNKVSTl70mfC/jX9o6fWvGa2+n+GPAiRvnAXw
jpZ7j/p3r6h/ZN0GPxVp1vPqnhHwJNnG7d4S0wZ/KCuf+HX7CH2TXobm4hyV65FfWPwz+GNt4M0t
YY41XbjoK4cNhHzc00dmIxS5eWDNaw+G/hFYvm8B/D0n/sVNO/8AjNWV+HHg4/8AMh/Dz/wlNO/+
M1qLHj2p6p6CvTVGH8q+48/2s/5n95lD4b+Du/gL4ef+Epp3/wAZpw+Gvg0/8yF8PP8AwlNO/wDj
NaoT1pwX0FP2NP8AlX3C9rPu/vMofDTwZ/0IXw8/8JTTv/jNKPhl4M/6EL4ef+Epp3/xmtZU9aeq
5NP2NP8AlX3C9rP+Z/eZI+GXgs/8yD8O/wDwlNO/+M1X1PwB4KsbVpG8BfDzC/8AUqad/wDGa6EJ
7Vi+NrSS50WZI87j0xQ6NO3wr7hqrO/xP7z5O/a5+L/hfwBDdQ2Hg34eQyrnaR4U00/+0K+UfAvx
w1Dxv4vgii8NeBjDIeg8IaX6j/p3r3z9pP8AZ11nx74qchJGjfPatb9mv9iw+GJILi6g+dMckV41
ShKpU0VkerCtGFPV6nq3wB8Iafd6AkuoeDvAEj4GS3hHTM/+iK9KudE8O2g+XwT8PB/3KOmf/GKv
6T4ci0Cx8lFCgVT1UfNXoqjCMdkcLrSk9zJvJdFgzt8GfDsY/wCpP0s/+29Zdzq+mR52+D/h0P8A
uTdK/wDkerOpLjNYl4ME1DhHsUpy7lv+3NO/6FD4df8AhG6T/wDI9KNc07v4P+Hf/hG6T/8AI9Zd
FTyR7Fc0u5qjXdN/6FD4ef8AhG6T/wDI9B1zTT/zKHw7/wDCN0r/AOR6yqm8P6Dr/i+/WDRPCfi3
xAJJbqCNtG0mbVHd7WOykuAYbYSTKsa6jZZkeNYyZ1UMWDATL2cdZWQ488tI3ZfXXNNUf8ih8O//
AAjdK/8Akel/t7Tf+hQ+Hf8A4Rulf/I9Zl9Z3ekanNY6jp2q6RqFtgzWWp2E1jdQg5wWimVXUHBx
kdj6UymlBq6SE3JOzNb+3tN/6FD4d/8AhG6V/wDI9L/b2m4/5FD4d/8AhGaT/wDI9YtxcLbRhmDM
WYIqopZ5GJwqqo5ZiSAAOSSAKXUHbRb+5tNQjfTr2yvZdOuba5xHLb3UUrRSQMM/fWRGUgd1NFoX
toF5Wuara3pxbI8IfDz/AMI3Sf8A5Hp39vaaB/yKHw7/APCN0n/5HrJZtopbCyvdd1WLTtL0/UNZ
1S4VmhsbCBri5mVeWKovJAHU9PzFaU6PPJRhG79DOpWUIuc5WS8zT/4SDTh/zKPw7/8ACN0n/wCR
6bJ4h03/AKFH4d/+EbpP/wAj1iwNPqFnd3VrZX93Y6cglvrqC3Z4NPUkgNOwGIwSCPmx0OcYpnmC
QAggg8gjvTqYeVNJzja+2gqeJjNtQle29nsbLeItO/6FH4d/+EZpP/yPTG8SaeP+ZR+Hf/hG6T/8
j1jaTDqPizxGdG8P6NqviLVYwrTQWES7LVWV2UzTSMkMO4Rvt8x1LEYUE8VlS6rqVvqFxa3fh/VL
GazsH1W5WWa1Jgs01ttBac7JmJUamjW+Fyxx5gUxESVyOrSUuVtXOlQquPMk7HUyeKNP6Dwj8O//
AAjdK/8AkeoH8VWI/wCZS+Hn/hG6T/8AI9Y0kuBRo/h3xD4wW9fQPCvijxDBpxVbqbTdMkuEjdp7
OARJgZnm8zULMGGASShbhHKBMsKm4RV5WQoKcnZXNK48WWBU/wDFJ/Dwf9ybpP8A8j1RbxTYo+f+
EU+Hv/hG6T/8j1w0Xxe8MX1tHNF4i0Ro5kDoft0YyCMg4J9K0LbV4NUtEuLaeK4t5RlJInDo49QR
waLQe1h+8t7nUv42sl4HhP4ef+EbpP8A8j1H/wAJtZ/9Cn8Pf/CN0n/5HrmHuOetexfsAeL7zwr+
2F8P2svsgbUNatbGVprSG4ZY5JkD+WZFYxuQMeYm1wCQGAJzM+WMW0ioXbSucNH4zs2P/IqfD3/w
jdJ/+R6t2/iyzf8A5lP4ef8AhG6T/wDI9e2/sxeOfEPwo+JXi7xZLrl1oXw80DV5p9ahj+VfEs5M
oh0vaB/pBlBbKNlI0Mkh29Tufsk3sHhP4rW9to2l6xpNv4s8E6peakNW02AefILO9YGwmKGVbQ7U
AIYb2Rg27aMZuold8uxag3b3tzwO38SWLf8AMpfDz/wjdJ/+R6txeINPPXwj8O//AAjdJ/8AkevV
fA/ii81b9gXxxpcv2QWeleI9IMAitIonJkW8LNI6KHlPAAMhYgAAYAxXZfsXeJ7rwd+z5451C18c
f8K+8jxHobS6pi6bMY+1FotlvG7SbgPuMAjYwxAqnNJN8uzt+Xl5kRi20ubdX/rU8ATXNO6nwh8O
/wDwjdJ/+R6lXXdN/wChR+Hf/hG6T/8AI9fXcsmh/tE/s8a7oOgaWLJPGnjPWtR8L27IqvHeQw2s
0UQGdqmWIzptHAaRAOBXHfteJp+hfsseCvDGmeTJa+C/Ed/osk8YwLq5S3tnupM9wbiSUA/3VWlG
tFtR5dblSoySclLQ+eF13TR/zKPw7/8ACM0n/wCR69Ubx3pOgeFNCjGi+HXkbRrCaR5dKtpXkeS0
idmZmQkksxJJPevFF6Cs7xr4qnv7HRoI3ZVXRdMVipx0sYBirrQu0kRSnZNs93+Hvj/QfFPi64tL
vRPC8qx2zSeWNJtVKkMgz8qA9z+dFeF/B6/bRvE08q8FrVl6/wC2h/pRXNOk76M3hUVtUd1+2BdF
f2s/iiM4x4u1Yf8Ak5LXyJ+1V8btZ8N/FW58OW9ravYyQ2V7BO+7cpawtkcYBwRuj/PNfVX7Y90V
/a5+Kg9PF+rD/wAnZq+bv2oPhm/j3SNK8R2atJeaKn2C9RR8xgLlo5Pf5nZCf+uQ719DkHs3XhGp
1Vl66P8ASx81xN7WOEnUpfZd36ap/de78kemfsJeFLzxpe2y6j4q1jQ1viJz/ZQhglGcAfvHRz90
KcDHXvX2V4T8MeMPAv7Rd9fWi698Z/DXw/0RLNyotLbVtKm1HEpKr8iXrJFbRgkeW4W5xhsE18Df
BibW7Mx32l3FrbENvjhKswRey7sjoOOnavvn9kL9pvRPhZ8KtQt9bvntfEesalNqWoG5UxoxKpFG
EkIwyiKKMdcg549fm/HXIsBk2TLPsFlSxFeUlFuFLmmueL5pucFzpNXi23b3kn0R4Hhdxbic5zN8
P5nmTp04q8VOqox5YtcsIxm+W6dnZK9k33PC/wDgo58UNSvfhnfXlr4G8X+H0uGFqt3rlpFYhGc4
IWMyGRzt3fdXA65r5A/Zd+NuseIfidb+G57S1jsYob29nmTduYpY3KRjBOAN0n54r6h/4KUfHy2+
OiWNtY3QurDTjJPIyhghkI2rgkAHALdM9RXzn+zn8O38C6Tq3iG8QxXmuL9hs42HzCAOGlk9vmRU
B95B2ri8J8mq4PgqOPzHDfV6uIlOXI+bmSu4wvza3aXPslZ7dX62fVcOuK55fldf21Oko8004uLl
ZSlZx0srqO795bnqbah6GprXURxzXPNe1JBfYxzXu3PpOU7Ox1PGOa/Vj/gljfxr+xvYTSOkccWo
Xru7sFVFD5JJPAAHc1+Q9nqXTmv01/YA+IDeDf2B9PvEjjnKa8yGN+hzeQj9M5/CvjeOMMsVhKGE
k7e0rU43/wAV1+p6eVV/q/tq9r8lOUvusz6r174veF9KtEnl8SaBDby/LHI2oQ7ZW2I5CndgkLIh
OOgdT/EM8lqf7RvhW0DBPF/h+PPUDVYR/wCzVxnij9qrUviBb29voGmWw1K1hWRoHtopXnjMcLMy
tK6KNhmUEbsndkZwccN4p+OXjbw/pV5fajoE8FnZQvPPMkdogijVSzPhLongAnhSeOAa+Qxvh5kl
KusPi8wVCq9oyqU1LV6WTs9eltzBcY5g4OrhMM6tNfaUJuOi1u09LdbnqcXxw03xVLLHpXiGx1KS
IbnW1vkmKD1IVjivgv45ayp+M/iwqQoOr3RAHAH71q+l9P8AjdF4ueLT7w3EOp2urrDHHLJ5qkiC
637GwOykkYHQdcV8b/G/Wivxi8UZPP8AalwT/wB/GrbhThh8O8Y1su9q6ilh1NN7q9Tlt5/De/nb
odtTPXnGRRxcoKDVXlsvKN/luWP7ZA/io/tr/arjTro9aQ6+B3r9o5z5vkO0/tof3hXa6V4gfT/h
zZzZJiM102M/KXEagH6gFsfjXip1/nr+te6fBn+w/GvwPn0nUtStLaaa5LIDcKksLDcA4UkbuCeO
hDEZB5HyPHuS4rOeHcZluCdqk4K3S9pRdr/3kuX5n03BOc4PJ+IcFmOYK9KE3zdbJwlHmt15W+bv
pofp3d/Czw18Y/gPolj4nsLa7shpUEglkOyS0PkqTIknVCMdQe3ORxX51eP9I0LwP8VvGWj+EvEL
eJNDttIvES9VgVk3W0u5Cy/LJtIA3gYOzIrV+LHj34x/Gfwxpnhq91PRx4X0y2gstunXsdrbXioq
qJbgFvNkPGSu3ZkZVOlZ2hfDCH4e/DXXpp7kTX0mlXRco3yMxt5BwP7oBIXudzMcbgq/mnD+U4/M
uJsHilgJUI4Z+/VnFxlL3XHkivtRbe93pe1uv6dxRmOV5VwljcO8xhiJ4pWhRpyU4w95S55PeMkl
taLvZO+8eY+P199k8bpz977d/wCnbUK4pdb461d/ar8W21t46s0ilE5ZtQVvKIfYf7VvGGcdOHU/
Qg152viQH+Kv6BxM7VWv62P56yqH+ywfr+bO7TW/evq79m3Xjpf7NfwptwSBD4C8OJj6aRaV8Np4
kyfvV9d/CO+eL4B/DZYzg/8ACE6AM+g/sq1rx8c05R+f6HvYNNKVvL9TM/bw8eR6p4E0OySRm/4m
gaQg/LxDJgH8SK+YfB/gV/C+sfETxppCq2pjwpsaNQTKqi9tRPLEB3+ymUOR0iWQ9C1fS/xr+HD/
ABJ8A3VhEwS7jxNbOf4JF5H59D7E18x+GfiFfeCfEqpJLc6Lr2msQcMY5EPKkg91IJHoQfevyLiS
VbKc/wAPnip+0pxcW135XqvK+68/Q+RzzH5nlOPnjsHOUYVqcqU+XrGStKL/AAa815HPaB+0LqWo
avptvostxLq8lzGtiltlpmnLARhAOS27GMd6/S3xO8cesXp/dqgkYkKRsB7gY4xnPTivk79mLSrf
xH8SJNctdI8KaJBp43XV7p2h2lpcTyEECJJEjBiDAkv5W3cvytkMQfZ/GnxKGq3H9j6OwmvZ/lZl
5WBe7N/nmvwH6UHHMfEvN8s4U4bwcvaUpOUpO105pLl0vaKS5pNva3Zn7J4I5dLL8rxGe4ybVKpZ
RurXUb3la7vduy80zc0HXTLpqMpyu59pB7bjj9KxvjfrBHwa1hiT8uo6D+viDTB/Wrul6aNNsYbd
M7YUCD3xXOftASG2+Bett0/4mfhxfz8S6SP61/YuXYb6pg6OFvfkjGN+/Kkr/gfL15+0qyqJWu2/
vPOfjTqHn/G/wICeVvvCM3/fPiiY/wDsteqReNiq58wfnXhvxs1P7L8f/BaE/dj8MS/l4jvD/Ste
TxQ0w2h/l789a9umlJ3/AK3Z5tRtaf1sjY/ac8ZJrnwe1W3CLLtaF1c/wESpyPwyPoTXnf7CPx38
RfAD49w654d8O33itnsprbUNNs4nknmsyVeRl2AldhjR8kEfLzjOR0WsvF4g0a5sp+YrmMxt7Z7/
AIHmuJ/Zo/aH139hz47L4gtrCHUAbd7G8tJXKJfWzsrEK+DtO5EYHBwV5BGRX6hwniqdXKcTlagp
zldqDdlK6Stfpt+N/Nfzx4p5bXw/EeA4hdSVKlDljKpGPM6bUnJSceqfNtrezVnon9Ta14+/Za/a
21mS8g8J+N9N8d6zOGFpols0d9d3DuNzoFdrXduJYu+0n3YgV8zftNfs0+Lfhf4u1W/fRvG15ois
sov9W011ukVjtVZihdCw4+ZHZSCD8pyq+6xftn/s7al8TNJ8W+H/AAH4j8IfEG51qznk1Ev/AMS6
Hfcx/aC8aXGwhozIM+QPmYNwRuH6Zf6J4g0n/l3vrG+h/wBmWK4jdfxDKwP0INfmmY8YcSZDns8L
gZOFJU4ONPERdRWbkpcsozjJWcLKz5VGzcW2rfT5b4f5HxnlsqmJq0nWjN3q4aPJzaae0jKNnJ3v
LTyUtz8m/wBnHXxL8HNH2yrIFEoyGz/y2cj9Mfhiu7XWSf4q4qTwQPhB8S/Hnh6O2ks7XT/Et2tt
EzFgImCMpUnqDkkflV5NTPr0ranm8M1hHM6a5VWSny3vyua5nBvvFtxe2qei2PvOH8FVweW0cFV3
pRVO/fk93m/7etf5lL4M6h5H7SOtXGcGK08Yw5+vibTv/ia9m/4S8QpuaTAHvXzz8L9VEPxo8Uvn
lLjxhH/5c1t/8TXeya007ZY8dhWFGCkrvy/JH0FWXK7Lz/Nmbr/xPXw1431G/NmdQhuNZvLS4tS5
T7RBNpOnwTRhgCVLRu4BwcEg4NZOueP9C8D6LrFzoC+ML6/u7SfTEGqWsdtbaOlxG0cvMbv50jRM
6AkRAby20kAVh+MrPVX1q7NvpGsXYfUTfw3Fm1oVANtaRYIluI2DBrdj0IwRzXWfBP4XeOf2mvGm
paBqF7rGj6dqc6anrN3qLW0iyuoYK+2Kdy0h+YDOAOSfQ/SYzEUKOEo1k4NwceZSf2evKkm+ezkk
tL3tJ2bPhaeCxdfMK1FRklPm5Wl9qytdtpKN0rvW1rxV0jkfg3eQr4bhV/E+saKtxfTLcraeLrfR
lt0WODZIYpQTKXLSDcvTygD1rlf2kdcd/DHjywfxR4gv9G0wsuj3Vz8RLLVotfC3kUcbGwjUSx7o
S8w3H5DGAea9J/aw/Yo0n4Z6DPc+H9f1PUby2Uuba9SFftAHZGUKFb03ce4618vQfATxV8RPDsV/
p+iaq9rex7oX8yxAcHvhrkEfiK+hyXPMrx0/bKooNPVS0e97/Fby/NX1PBzThrNcB+5nTc1JaOOs
Vo018Keu7u35WWh9c/ssX+34H6WMj/j5vv8A0snrpvixqJHwb8cHP3fDGrN+VjOa5P4GaFfeC/hj
p+n6hEsF5HJcSyRBw/l+ZPJIFJUkEgOM4JGa0Pi9flPgf8QW7L4R1pvy064NfFY6UXOpJeZ+k4BN
Qpxe9l+hsCenLP71nLd571IlyPWteYg0BPThP7/rVBbinrP707gXhNT1nyKoCenrPTAvCenCb3qi
J/enCfNArF3zqDJx1qqs9L5+e9FwsWRL70olx6VWE1KJM+lO4WLXncd6PNx61WD+tL5v1ouKxZ83
IqKSCOXqKj8360CX3NFx2JYrWJDwoqePavQCqgl96UTc9qExWL28UFxVRbginC45oFZkzjeOaqTa
NDMxJUEn2qcTZ70pkyKARFFp0UA4UVIAFHApC49aaXJoHqSFiaaXAphOaaXwaAJPM9qRmzTN5pC2
aAsKX54prNjrTGbJpCaQ0h3mU0nNJuHrQXFAxaMimFiaSgBWOTSUE4FRk5oAcXx0prPTWf0pjNj6
0AOZs0wvjpSEk0hOKVwFLE00vikL5phYClcBzNnrUbSYpHeonkqQHPLULyU2SWoXkzQNIc8lQyS0
kklQPJzQUkOeWoJJcUkklV5ZaTYwmmzVaSaiWWoJZagAklqtNL1pZJeKrSyZNDKSCWXJqvLJSySV
Xd81DZQjvxUMrU9mzUEhzSAY7frULnJqV+tROMGgCInJpjjmpXXNNIpFEdNZealKA0nl+9A7kOM0
GLPYVMI/el2D3pWC5CI8dgKUR1MIs9qUR49KdguQiL2NPEfNSCPn1p6x49qLCuRLFUixZqRYqesf
40ybkSxVIsVSCOnrH+FAEax1IsePapEjp6p6UAMWPinLH+NSLH7Zp6p60ARrH/kUj2Mcv3lBqcL6
CnhMdaAK8OnxRn5UA/CrCoF6CnBM09Up2Aaqcc09Uz9Kcq4pyrupoQ3aB2pQM0/YKUDFUL0ECCnK
mfpQoyafQDCmywrKpDDINOooJMy58J2dzLvaJCfcU0aTBYxkRoo49K1gM1SvBwfpSsi7mLqXeud1
T79dFqXeue1Qc5rGRpE57U+/+fWsO96mtzU+/wDn1rDveprFmyK8Ea3mp2Vm2oaLpP2+dbcX2sXy
WNhZ5BJlnmc4RFUEnGWbAVVZmVT2fx88BeCfhn4l0qHwL8VfCfxQ0jUbaNJpdP1C0e+sbxYszeZB
DIxFu7K7xuM7M+W5LBJJeKliSdCrqrqezDIpkNlDbtujhijPqqAGsXF8yaehupRUWmtSWvd/2Bf2
stB/Y38SWvijxBpXiHWbW91DxhpkNto0MMlwZXsvA8gJ86WJAu2JuS/Uj148Hc4FQRXV3JaWenvB
brZ6dqeqarHcCcmWZr610a3MRj2AKI/7J3bt7bvtGNq7MtjiqPtYqD2v/maYer7NuS3t/kfWnj39
q/8AZv8A2nPjj428ZfE/wb43nji8KaLp/h/SzHc2mrT3UN3rEtzHHPYXHlxoVuLTJkuFQ5GeVIHy
ZYLiOVxamwjnnlnis/tUl0LGN5GdLcSyEySCJWEYdyWYICSSSanoJxSw+FjRvythXxMqtrpH2D/w
Rg+CXhfxv8YpfFmsaWNS1zRNR1uGwluLiWSG0FvZ+G3hdIC3lLIjaheESBN/74/N8q7fJ7/wnpmq
ftEeNY9Q3W9r4x+L3izwpq4klZ4b7Rpby/mvJ/LYlEewkjtJVlQKytdoxYmOPb5D8PvFuqfB/wCJ
dj408JXS6H4s0xgYNRiiBeRe8Mo/5aQsOGjbgj0IBEfiDxRfeIvGHjPXi0Wm6j49vNTuNWNmoyYL
+8lup7NZGBcQkytGcEMyFlJw7A8rwdT2sp30f+ex0rFU/ZxjbVf1cwvCGpT6p4R0q6uwRdXNnDLM
MYw7IC36k17D+xj43j8B/EjVby7eGbQ2mtxqOlRSrDql8x2qs9u5GRFGCAwJKluAEbLnyottGBxj
9KsaH4gv/Cev2eraVez6dqmnSeda3MW0tExUqflYFWBVmBVlKkEggjivpcpxsMLX56qbi007O2/p
/XXdHzWc4GeLw/s6TSkmmrq+q9f66bM/RL45eNvCh8XXlh8MtAe1+It1DHcRXCWS29t9qnhVo1ub
ZmVry5dSC23kAgvI4+Q/m3b6g18biaQ5nkupzOwi8oPN5r+YwQKgQF9xChEABA2rjaO48d/tY/Eb
xL4m8Y67ZHwvpeueM7GGymvre2lSbTJY4DbNfWjli0Ez27yxsiER/vNwAZVI808M6FH4W8P21hHJ
JKtupBkc5aRiSWY/Ukn8a+Zo5lmtXGVMLiYL2MPhldu/SOr30u2rJRei3bfDldHExxc51aainzbJ
JfEuW1urV3LzseS/tA3cWvM+j31mFs01XUJYrhiSZ2lsNISRUBXAMYjjJIYkeeuQvBb7u/Z7+OXw
o+JP/BLXxV4l1XVvh14X+JXhzQ7vwJpeiRaB4Ouhrt/HDFqMcUdgukI0dtLqjtcm02siNG0pJILj
428ffDnVPFviVYpZBP4b86S+8q3v47G9guZIYIX8uR7S4XYy2sBO5T90gKpO6u8+Gniu+8K/sgf8
Kxv7Cwglj+JD+Ohd21zJcCZTo500IxZU2tjadoTHy53EkivnlhszqZlJVV+4u7P3b9N/7u/Lb3r/
ABaWP6AxmI4QhwrSeEf/AApWh7RfveTlvP4L6e1tye15v3XLb2XvcxRsLSPRdKtrOJpGitIlhQu2
5iFAAJPc4HWvSf2ef25bj9krQdYgPgHUvFtvoeoHx1Jc2Xim30qPyW1HwrYC2uIpbGd2QXkNjJvg
cOQXXbjLV5lPPS+H/En/AAiV/q94tpb6g+paXBpbQXEVtLG8Sa5o+pyqVube4gyyaW0atJbzKrSA
mNwMV9PjKXtKXKlfb+vuPy3C1OSpzNjvDH/BU74w+A/Amj6Jp/jzxXs0ixgsYyNVnSJVijVBtUN0
wvTitf8AaUmx+1P8Xx6fETxN/wCnm8rrPiB+13oWvfDKx0jRPgr4L8O+INOt7tV19rbwpeyajNKd
0Ml5bt4WWJ0gOAEtvsxdMh3LESDx3Wtfv/E3iHVdX1W9l1HVtc1C61XULuVI43urq5neeaQrGqou
6SRztRVUZwAAMVjhqbjK7jY2rzTja9x3mZPWuh+HfxK8R/C3XG1Lwxr+t+HNRkhNu91pd9LZzNGS
CULxsrFSVUkZxlR6Vy8Llmrpvhvd3Om+M9Mns9LtdavUuEFtY3NqbqK6lJwiGL/lp8xHyEEMeCGB
IPY9tTlO40T9qn4paZd3k9r8SfH9tPqMonupIvEN2jXUgRUDuRJlm2Iq5OThQOgFW/Df7RXxD8Mz
tLp3jzxnp8skSwM9trdzEzRqzuqEq4+UNJIwHQF2Pc17B4k8F6Brnx98Ox6xpPhuO4+H/h06n4/T
RbSC206e5t2eQ23lQKsIkO63tpPLAUyMw6gmuo8dfs6zeH/2F9W1658FAa/q99pviObVrfR/LhtY
Lw3B+zW7iMKkMcYt2YIdqtOFONoFZe0p6XW9jR0562ex4JH+0P8AEF/D93pLeOvGTaXqBl+1WZ1q
5Nvc+axaXfHv2tvLMWyDuLEnOawrPX9Qs9EudMivryLTr2RJri0SZlgndN2x3QHazLubBIyNxx1r
6A8PaDc+Dvit4a8BaF4e8FXGoaBpcc3ibU9c0e2vIbJ3Zbm8e4edWRY4YykJZhuUxuEIaQ7u/uPD
3gPxLPaaP4f8LaLF4Y8baF4l8Q/bZrKJ7yzaCa5NoY52HnQJEtrGPLVlUiVgwYmq9tGP2d/6/wCG
IVKUt2fJun+NNZ0m0soLXVtTtoNMujfWccV06Ja3B25mjAOEk+RfmGD8o54FQ3PiTUbzRo9Omv72
XT4Z3uo7V52aFJXADyBCdodgqgtjJCjPSva/jDqGmWOj/BnXtM0Pwb4Xk1PR52uAdMNzYKy3s8Im
njkWd59qqCfMErHb0bhax/2vNMtIL7wXfWdnoezU/D0cs2raLYR6fp+tzCaVXmit0VPL24Ebb4on
LRsTGoIJ1jUTa03v+BEqbSeu36nkKvjrXOC3+2adpjnkjTbNfytox/Suhp+k+EZJdB0tsHDafbEf
9+UrVxuzJOyK/wAP9JMusygDJ8k/+hLRXf8AwV8CPeeKbhChOLRj0/20orCorM2p6q5zH7Zb/wDG
XvxVH/U4av8A+ls1ebWt89nMXXYwZWR0dQ6SIwwysp4ZSCQQeCDX9I1FeRDNuVJcv4/8A9SWWXbf
N+H/AAT+c/whqGnaDfrNbxxIhbc9tcSMoX/clCtuHosgB9ZD29XPxy0MaT5Z0a+3bcbvtunbc/T7
Tu9/u/rxX7s0V9Zg/ErNMPTVJWkl/Nq/v0/G5+T8R+AfDOc4hYqupwle/uS5U/k7pfKx/OV401bT
tcvnmmjidQ2UtreRmDf78pVdo9VjBPpIO/O31899NvfYAqhERFCJGqjCqqjhVAAAA4AFf0r0V4mZ
cV4rH1Pa4r3n010XorH3mQcE5fkuHWGy+PLHq9W36tu7/LsfzOySkU6CQ8V/TBRXnf2t/c/H/gHu
/wBm/wB78P8Agn819pIeK9T+Fv7TfjH4aaJaaPY6vcP4etrpbxtJdiLW4dXEnzhcMfmUHgg8dRX7
+0VMszhJxlOmm4tSV7OzWzV1uu5MsrbhKHPZSTTtpdPdaM/CfUf2tvFd7LayaVMnhue2WRTNpssy
yTI6xAqxd24HkpjGO+c8Yo6z+0N468T6VdWV74s124t7yF4ZUe6Yq6MCrAjPIIJr95qKyxmKwmLx
CxWKw0J1Fa0nGLem2vL0IwuUyw1B4ahVlGDvdJu2uj+11Pwh8R/tEeIddmaWNNO0i5a+F/8AaNN+
0xTK+yVNoZ5nAUiZ88Z6c9c8bquv3OsahNd3c8lxc3Dl5ZZG3PIx6knuT61/QhRXXWziNXEfWqlJ
Opy8vNony3vy3Ub2vrbuZYXI44ek6FGbUG+a2rV7Wvq3rY/njfUGB61E+pMO9f0Q0Uf21/c/H/gG
39k/3vw/4J/Oy+rMD1pg1t42yGIPrmv6KaKP7af8n4/8AP7J/vfh/wAE/netPHV/prgwXt1CV6FJ
WXH61qf8Lz8SCwltjrOoNBMhjdWnY5UjBHXuDiv6DaKpZ7NbR/H/AIBlLI6cvia+4/nUm8US3M7y
ySvJJIxZ3YksxPJJJ6k0DxIR/FX9FdFT/bT35Px/4BosoSVlL8P+Cfzrp4mP96vs34H/ALQHw9Pw
I8AwXnxE+H2l32neFtJ0+8s9T8S2NhdWtxb2MME0bxTSo6lZI2HIwQAQSCDX6t0Vz18zdS3u2t5/
8A3o5fyX978D8yx+0B8M16/FT4Tj/udtK/8AkiuO+Jl58C/ixEv9sfEb4PvMn3Jl8caSkifRhcZr
9ZaK5p4pTjyzimn3NZ4GElyy1XofkN4U0/4OeDtIXTrH43fDeCwVi5h/4WBpHzE9SWNzuP59ABXd
+GPi18HvCVr5Vl8VPg7Fu5Zz490gu59STc5Nfp9RXn4LB4HB1JVcJh4U5S+Jxiot+rSTfzOmUakq
UaEptwjpFX0S7JbL5H5rr+0T8LP+iufB3/wvNH/+Sa439or9oD4dav8ABu80zS/iP8OdZ1HUdZ0D
yrfTPFNhfOqQa9p13PLJ5MreVFHBbzO0km1FC8nkV+rVFel9dl1Rh9UXRn4VfHz4v6Fr/wAc9M1H
RdXsdb0vw3aaAl7eadMLq3VodYuruYLImVfZFKhO0nGatJ8WfDSnjxj4MK9ifEFmv6GQEfiK/cui
uuGbOKso/icssrUnrL8D8PIvi/4YHXxn4HH18S2I/wDatM1bx74I8R24ivvF3w+mUdC/ifTwV+h8
6v3GorSGe1YtSjGzXmZVMkpVIOFR3T3TSafyPwdfRfhpdI6nxx4FUOCMHxhpuOfYzV3Xww+P9x8K
PscWi/tA6HZWVkT5VsvjrTTGFJ5XD3DDH4fTFftRRWebZu80gqeZU1WUb8vP77jfdxcruL84tPRa
6Hl4PgnK8HU9rg6apS68iUL/AOLltzfO5+Msnxo8M6lqt9f33xO8AajfalcNdXNxc+NtLeSR26kn
z/Yfl65NWYPjD4M3Df8AEP4bIpPLDxfprkf8BWcsfoATX7I0Vjg8whhKEcNh6ajCKskuiPXeUQbv
zM/ETwD8QNP07x3qWuXt5DpmjeILvxLNaXl632eErda3HeW5ZnwE8yFSw3Yrtk+MXhJcZ8aeCR/3
MVl/8dr9haK6o504q0Yfj/wBSyhSd3L8P+Cfj+nxm8HDr448Cj6+JbEf+1a2fCH7TuheA9Se70f4
k/D+yuJE8t9/iTTnSRfRlM3OPwIr9Z6KmpnLqR5JwTQ6eVKEuaM2mfjv8U/jDp3xkZo9W+Mnw5t7
OTiSOz17TIJHHceYbhiuf9nBq/4d+J/w/wDDOjW1haeP/htFbWkYiiT/AIS/TflUDA/5b1+vNFZ0
M0VG/s6aV/U0rZc6v8Sbf3H5MJ8bPA+cf8LE+Gn/AIWGmf8Ax+sf4qfF/wAI6x8H/Gmnaf4z8Gax
qmseHNT0ywsNL1601C6u7i4s5YIkSKCR3OXkXJxgDJJr9f6K2lnk5LlcVqYxyaCd1Jn5TJeZ71Ml
0a/VOiur/WL/AKd/j/wDn/sH+/8Ah/wT8sEu/epku6/Umij/AFi/6d/j/wAAX9gf9PPw/wCCfl0l
zmpFnzX6g0Uf6x/9O/x/4Af2B/08/D/gn5grNmlE1fp7RT/1k/6d/j/wA/sD/p5+H/BPzFWbNPEh
PvX6b0U/9ZP+nf4/8AP7A/6efh/wT8yRJinCav00oo/1k/6d/j/wA/sD/p5+H/BPzNExp3nfWv0w
oo/1k/6d/j/wA/sD/p5+H/BPzPEvvTvM9q/S6ij/AFk/6d/j/wAAP7A/6efh/wAE/NHeaPM9q/S6
ij/WT/p3+P8AwA/sD/p5+H/BPzTDZFG7Hev0soo/1k/6d/j/AMAP7A/6efh/wT80/N96cs5xX6VU
Uf6yf9O/x/4Af2B/08/D/gn5rianq+a/SWij/WX/AKd/j/wBf6v/APTz8P8Agn5sMcmkr9KKKP8A
WT/p3+P/AAB/2B/08/D/AIJ+axYA01mzX6V0Uf6yf9O/x/4Af2B/08/D/gn5pngVGTk1+mFFH+sn
/Tv8f+AH9gf9PPw/4J+Z9FfphRR/rJ/07/H/AIAf2B/08/D/AIJ+Z9NZua/TKij/AFk/6d/j/wAA
P7A/6efh/wAE/Msnjmo2fPWv04oo/wBZP+nf4/8AAD+wP+nn4f8ABPzEZ8+1Jkeor9PKKX+sn/Tv
8f8AgB/YH/Tz8P8Agn5gM3PFNZsV+oNFH+sf/Tv8f+AH9gf9PPw/4J+XhcmmM2DX6jUUv9Y/+nf4
/wDAD+wP+nn4f8E/LR5OKieSv1Qoo/1i/wCnf4/8Af8AYP8Af/D/AIJ+VMj1DJJX6uUUf6xf9O/x
/wCAP+wv7/4f8E/J15c1E8nFfrPRR/rF/wBO/wAf+AH9hf3/AMP+CfkjK9VpZK/Xeip/1h/6d/j/
AMAP7C/v/h/wT8gJXqCR6/Yaij/WH/p3+P8AwA/sL+/+H/BPxykaq8jZ/Gv2VopPiD/p3+P/AACv
7D/v/h/wT8YpGz+NRP0r9oqKX9v/APTv8f8AgB/Yn9/8P+Cfiw55qN/vV+1dFH9v/wDTv8f+AH9i
f3/w/wCCfii/UUx1zX7Y0Uf2/wD9O/x/4Af2J/f/AA/4J+JdFftpRR/b/wD07/H/AIAf2J/f/D/g
n4l4HoKMD0FftpRR/b//AE7/AB/4Af2J/f8Aw/4J+JYXJ4pdhr9s6KP7f/6d/j/wA/sT+/8Ah/wT
8TQnrThHntX7YUUf2/8A9O/x/wCAH9if3/w/4J+KAj/CnrH7V+1lFH9v/wDTv8f+AH9if3/w/wCC
fisEAp4Sv2moo/t//p3+P/AD+xP7/wCH/BPxbWOnqnPrX7Q0Uf2//wBO/wAf+AH9if3/AMP+CfjE
qY96esdfs1RR/b//AE7/AB/4Af2J/f8Aw/4J+NAQ+lKEx1r9lqKP7f8A+nf4/wDAD+xP7/4f8E/G
unKnc1+yVFP+3/8Ap3+P/AD+xP7/AOH/AAT8cVT1pwGTX7GUUf6wf9O/x/4Av7D/AL/4f8E/HUp6
UqjAr9iaKf8ArD/07/H/AIAf2H/f/D/gn48Ku6nBcCv2Foo/1h/6d/j/AMAP7D/v/h/wT8e6K/YS
ij/WH/p3+P8AwBf2F/f/AA/4J+PdFfsJRR/rD/07/H/gDWR/3/w/4J+PyrtqlfDCt9K/Y6ih8Qf9
O/x/4Af2H/f/AA/4J+Kupd65/VetfuVRUPPr/Y/H/gFrJv7/AOH/AAT8E9T7/wCfWsO+OCa/oIor
N51/c/H/AIBayj+/+H/BP576K/oQopf2z/c/H/gD/sn+/wDh/wAE/nvIzSBQK/oRoo/tn+5+P/AD
+yf7/wCH/BP57mOBTCa/oUoo/tn+5+P/AAA/sn+/+H/BP56GfPSmM/pX9DVFH9s/3Px/4Af2T/f/
AA/4J/PETgVHI2a/ohoqf7Y/ufj/AMAP7J/v/h/wT+dh2zUMj1/RbRR/bH9z8f8AgAsq/vfh/wAE
/nJmkxVO4mxX9IVFH9sf3Px/4BX9l/3vw/4J/NjPPg1QubnFf0u0Unm39z8f+ANZZ/e/D/gn8yc9
1yahWcs1f05UVP8Aav8Ad/H/AIA/7N/vfh/wT+ZqyG4iu4+EXxE1n4P+OtO8S+HrqKy1nSnaS1ne
2iuViYqUJ8uVWQnDHGVODgjkA1/RbRT/ALWWzh+P/AD+zXe6l+H/AAT8DNb/AGh9f8VeEdU0i5s/
C9rFrJgF1NpmgWelySRxO0ixEWscaMpkKsSylsxphgAQY/hz8XtZ+HVibK0a0udKl1K01W50+6gE
kF3NbFjFvIw+0b3BVWUENzniv33oo/tWNrcn4/8AAJeWSbvz/h/wT8H/AAh+0X4s8GXniSezu9Ln
bxfKJtXTUNGstRjvWEhlG5LiKRQN7FsADkA9hizP+0340m8KX+iJqVla6XqPnCSC10mztvJSYoZo
oWjiVoIZDGheKIpG+DuU5Of3Xop/2rDf2f4/8AP7Nlt7T8P+CfhjrX7Uni7xLbaLDfL4TuIPD24a
fC3hLSRFbq2/KbBbbWQl2bYwK7juxuAI5r4g/ErWfijrEN9rVzFPLbW6WlvFBaxWlvawpnbHFDCq
RxqCScIoBLE9SSf3zooWbRWqp/j/AMAHlknvP8P+Cfz316v4VttEuvCGhka74ajcaVZq6S6vaxuj
i3jDKys4IIYEEEZ4r9uaK0WdtO6h+P8AwCHlF1bn/D/gn5AfCG88N+F/Ek9xfeJfCkML2zRhv7at
GyxdDjAkJ6A0V+v9FZzzfmd3D8f+AaQyzlVlL8P+CFFFFeMeqFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FAH/2Q==
--047d7b5d4808ce813d04d4fc289b
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--047d7b5d4808ce813d04d4fc289b--


From xen-devel-bounces@lists.xen.org Tue Feb 05 15:55:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2krv-0002qZ-JH; Tue, 05 Feb 2013 15:55: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 1U2krt-0002qK-R2
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:55:34 +0000
Received: from [85.158.143.35:57796] by server-2.bemta-4.messagelabs.com id
	7B/FF-01597-27B21115; Tue, 05 Feb 2013 15:55:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360079709!5653967!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29722 invoked from network); 5 Feb 2013 15:55:14 -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;
	5 Feb 2013 15:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6022864"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 15:54:59 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	10:54:58 -0500
Message-ID: <51112B51.3050406@citrix.com>
Date: Tue, 5 Feb 2013 15:54:57 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CD36DA7D.5A0EC%keir@xen.org>
In-Reply-To: <CD36DA7D.5A0EC%keir@xen.org>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 15:49, Keir Fraser wrote:
> On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
>>> I have some sympathy for this design. It's primary downside compared with
>>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>>> you say the fairness and prioritisation features are rather nice. Also
>>> having the data structures be per vcpu may well help avoid cacheline
>>> contention on busy multi-vcpu guests.
>>
>> This design originally (before I posted it) did have per-VCPU event
>> arrays but I changed it to per-domain to reduce the memory footprint.
> 
> Okay, I wonder how much it actually matters anyhow...
> 
> Oh by the way you say the control block is 128 bytes and will easily fit in
> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> So how does that work then?

I meant struct vcpu_info can be extended without it growing to more than
a page.  i.e., it fits into the guest page provided in the
VCPUOP_register_vcpu_info call so no additional pages need to be
globally mapped for the control block.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 15:55:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 15: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 1U2krv-0002qZ-JH; Tue, 05 Feb 2013 15:55: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 1U2krt-0002qK-R2
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 15:55:34 +0000
Received: from [85.158.143.35:57796] by server-2.bemta-4.messagelabs.com id
	7B/FF-01597-27B21115; Tue, 05 Feb 2013 15:55:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360079709!5653967!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29722 invoked from network); 5 Feb 2013 15:55:14 -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;
	5 Feb 2013 15:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6022864"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 15:54:59 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	10:54:58 -0500
Message-ID: <51112B51.3050406@citrix.com>
Date: Tue, 5 Feb 2013 15:54:57 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CD36DA7D.5A0EC%keir@xen.org>
In-Reply-To: <CD36DA7D.5A0EC%keir@xen.org>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 15:49, Keir Fraser wrote:
> On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
>>> I have some sympathy for this design. It's primary downside compared with
>>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>>> you say the fairness and prioritisation features are rather nice. Also
>>> having the data structures be per vcpu may well help avoid cacheline
>>> contention on busy multi-vcpu guests.
>>
>> This design originally (before I posted it) did have per-VCPU event
>> arrays but I changed it to per-domain to reduce the memory footprint.
> 
> Okay, I wonder how much it actually matters anyhow...
> 
> Oh by the way you say the control block is 128 bytes and will easily fit in
> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> So how does that work then?

I meant struct vcpu_info can be extended without it growing to more than
a page.  i.e., it fits into the guest page provided in the
VCPUOP_register_vcpu_info call so no additional pages need to be
globally mapped for the control block.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:01:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kww-0003Qd-C9; Tue, 05 Feb 2013 16:00:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kwu-0003QU-NI
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:00:44 +0000
Received: from [85.158.143.99:8624] by server-2.bemta-4.messagelabs.com id
	51/D7-01597-BAC21115; Tue, 05 Feb 2013 16:00:43 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360080041!30940751!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1078 invoked from network); 5 Feb 2013 16:00:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:00:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6334887"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:00:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:40 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kwq-0005RO-4B;
	Tue, 05 Feb 2013 16:00:40 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:16 +0000
Message-ID: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC PATCH v4] Coverage 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

Updated set of patches for coverage.

Changes:
- declared __init function in the right place
- use Jan suggestion for changing compiler options. I didn't understand why this
  change excluded files in xen/common/libelf. I wrote a script to test no
  references from no-init to init section but didn't find nothing related to
  coverage stuff. All pointers passed to __gcov_init refer to .data sections as
  expected
- added utility to get/reset coverage information

Hope to not forget other advice again.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:01:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kww-0003Qd-C9; Tue, 05 Feb 2013 16:00:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kwu-0003QU-NI
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:00:44 +0000
Received: from [85.158.143.99:8624] by server-2.bemta-4.messagelabs.com id
	51/D7-01597-BAC21115; Tue, 05 Feb 2013 16:00:43 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360080041!30940751!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1078 invoked from network); 5 Feb 2013 16:00:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:00:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6334887"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:00:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:40 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kwq-0005RO-4B;
	Tue, 05 Feb 2013 16:00:40 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:16 +0000
Message-ID: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [RFC PATCH v4] Coverage 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

Updated set of patches for coverage.

Changes:
- declared __init function in the right place
- use Jan suggestion for changing compiler options. I didn't understand why this
  change excluded files in xen/common/libelf. I wrote a script to test no
  references from no-init to init section but didn't find nothing related to
  coverage stuff. All pointers passed to __gcov_init refer to .data sections as
  expected
- added utility to get/reset coverage information

Hope to not forget other advice again.


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:01:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kxL-0003Ua-Qx; Tue, 05 Feb 2013 16:01:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxI-0003TQ-N3
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:09 +0000
Received: from [85.158.138.51:9077] by server-9.bemta-3.messagelabs.com id
	B2/72-09484-FBC21115; Tue, 05 Feb 2013 16:01:03 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360080059!22991619!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22248 invoked from network); 5 Feb 2013 16:01:02 -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;
	5 Feb 2013 16:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6023805"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:01:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:01:00 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kxA-0005RO-Ox;
	Tue, 05 Feb 2013 16:01:00 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:20 +0000
Message-ID: <1360079900-31777-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  140 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 148 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..95fcbc2
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,140 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_read, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read} [<filename>]\n"
+        "\treset     reset information\n"
+        "\tread      read information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    /* check support */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_enabled, NULL) < 0 )
+        err(1, "checking coverage support");
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-");
+    else
+        usage();
+
+    return 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 Tue Feb 05 16:01:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kxL-0003Ua-Qx; Tue, 05 Feb 2013 16:01:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxI-0003TQ-N3
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:09 +0000
Received: from [85.158.138.51:9077] by server-9.bemta-3.messagelabs.com id
	B2/72-09484-FBC21115; Tue, 05 Feb 2013 16:01:03 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360080059!22991619!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22248 invoked from network); 5 Feb 2013 16:01:02 -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;
	5 Feb 2013 16:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6023805"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:01:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:01:00 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kxA-0005RO-Ox;
	Tue, 05 Feb 2013 16:01:00 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:20 +0000
Message-ID: <1360079900-31777-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  140 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 148 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..95fcbc2
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,140 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_read, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read} [<filename>]\n"
+        "\treset     reset information\n"
+        "\tread      read information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    /* check support */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_enabled, NULL) < 0 )
+        err(1, "checking coverage support");
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-");
+    else
+        usage();
+
+    return 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 Tue Feb 05 16:01:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kxI-0003TW-PS; Tue, 05 Feb 2013 16:01:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxH-0003T6-LM
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:07 +0000
Received: from [85.158.143.35:20048] by server-3.bemta-4.messagelabs.com id
	05/34-08920-2CC21115; Tue, 05 Feb 2013 16:01:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360080054!10212332!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31346 invoked from network); 5 Feb 2013 16:01:05 -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;
	5 Feb 2013 16:01:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6023773"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:00:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:53 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kx3-0005RO-Bp;
	Tue, 05 Feb 2013 16:00:53 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:17 +0000
Message-ID: <1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 +
 .hgignore                |    2 +
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 +
 xen/arch/x86/setup.c     |    3 ++
 xen/arch/x86/xen.lds.S   |    7 ++++
 xen/common/Makefile      |    2 +
 xen/common/gcov/Makefile |    2 +
 xen/common/gcov/gcov.c   |   94 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   97 ++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 214 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..ddf5c4d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -46,6 +46,7 @@
 #include <asm/setup.h>
 #include <xen/cpu.h>
 #include <asm/nmi.h>
+#include <xen/gcov.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
@@ -1313,6 +1314,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_coverage();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..e7efa21
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,94 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+typedef void (*ctor_func_t)(void);
+extern const struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void __init init_coverage(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+
+#ifndef NDEBUG
+    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
+    if ( info_list )
+        printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..360b880
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,97 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+/**
+ * Initialize coverage informations
+ * Currently create a linked list of all files compiled in with
+ * coverage informations.
+ */
+#ifdef TEST_COVERAGE
+void init_coverage(void);
+#else
+static inline void init_coverage(void)
+{
+}
+#endif
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Tue Feb 05 16:01:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kxI-0003TW-PS; Tue, 05 Feb 2013 16:01:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxH-0003T6-LM
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:07 +0000
Received: from [85.158.143.35:20048] by server-3.bemta-4.messagelabs.com id
	05/34-08920-2CC21115; Tue, 05 Feb 2013 16:01:06 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360080054!10212332!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31346 invoked from network); 5 Feb 2013 16:01:05 -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;
	5 Feb 2013 16:01:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6023773"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:00:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:53 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kx3-0005RO-Bp;
	Tue, 05 Feb 2013 16:00:53 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:17 +0000
Message-ID: <1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 +
 .hgignore                |    2 +
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 +
 xen/arch/x86/setup.c     |    3 ++
 xen/arch/x86/xen.lds.S   |    7 ++++
 xen/common/Makefile      |    2 +
 xen/common/gcov/Makefile |    2 +
 xen/common/gcov/gcov.c   |   94 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   97 ++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 214 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..ddf5c4d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -46,6 +46,7 @@
 #include <asm/setup.h>
 #include <xen/cpu.h>
 #include <asm/nmi.h>
+#include <xen/gcov.h>
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool_t __initdata opt_nosmp;
@@ -1313,6 +1314,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_coverage();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..e7efa21
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,94 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+typedef void (*ctor_func_t)(void);
+extern const struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void __init init_coverage(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+
+#ifndef NDEBUG
+    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
+    if ( info_list )
+        printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..360b880
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,97 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+/**
+ * Initialize coverage informations
+ * Currently create a linked list of all files compiled in with
+ * coverage informations.
+ */
+#ifdef TEST_COVERAGE
+void init_coverage(void);
+#else
+static inline void init_coverage(void)
+{
+}
+#endif
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Tue Feb 05 16:01:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kxJ-0003Tj-6O; Tue, 05 Feb 2013 16:01:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxH-0003T9-O9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:08 +0000
Received: from [85.158.138.51:55027] by server-10.bemta-3.messagelabs.com id
	47/C3-10609-EBC21115; Tue, 05 Feb 2013 16:01:02 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360080059!22991619!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22083 invoked from network); 5 Feb 2013 16:01:00 -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;
	5 Feb 2013 16:01:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6023788"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:00:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:58 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kx8-0005RO-0P;
	Tue, 05 Feb 2013 16:00:58 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:18 +0000
Message-ID: <1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  151 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |   92 ++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 297 insertions(+), 3 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index e7efa21..6b95cd0 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -77,12 +78,156 @@ void __init init_coverage(void)
         __CTOR_LIST__.funcs[n]();
 
 #ifndef NDEBUG
-    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
     if ( info_list )
         printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
 #endif
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset =
+        (iter->write_offset + data_len + (sizeof(uint32_t) - 1)) &
+        -sizeof(uint32_t);
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write_string(iter, info->filename));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..5224249
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,92 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58430000u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x0100u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x0200u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x0300u+((n)&0xffu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0xff00u)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE FILENAME xencov_file COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM xencov_function..
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ */
+struct xencov_file
+{
+    uint32_t version;
+    uint32_t stamp;
+} __attribute__((packed));
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ */
+struct xencov_counter
+{
+    uint32_t num;
+    uint64_t values[0];
+} __attribute__((packed));
+
+/**
+ * Information for each function
+ * Prefixed with XENCOV_TAG_FUNC
+ * Number of counter is equal to the number of counter got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t n_ctrs[0];
+} __attribute__((packed));
+
+struct xencov_functions
+{
+    uint32_t num;
+    uint32_t xencov_function[0];
+} __attribute__((packed));
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index 360b880..306d7fe 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -94,4 +96,16 @@ static inline void init_coverage(void)
 }
 #endif
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Tue Feb 05 16:01:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:01: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 1U2kxJ-0003Tj-6O; Tue, 05 Feb 2013 16:01:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxH-0003T9-O9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:08 +0000
Received: from [85.158.138.51:55027] by server-10.bemta-3.messagelabs.com id
	47/C3-10609-EBC21115; Tue, 05 Feb 2013 16:01:02 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360080059!22991619!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22083 invoked from network); 5 Feb 2013 16:01:00 -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;
	5 Feb 2013 16:01:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6023788"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:00:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:58 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kx8-0005RO-0P;
	Tue, 05 Feb 2013 16:00:58 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:18 +0000
Message-ID: <1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  151 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |   92 ++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 297 insertions(+), 3 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index e7efa21..6b95cd0 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -77,12 +78,156 @@ void __init init_coverage(void)
         __CTOR_LIST__.funcs[n]();
 
 #ifndef NDEBUG
-    printk(XENLOG_INFO "Initialized %u coverage strucures\n", num_info);
     if ( info_list )
         printk(XENLOG_INFO "First coverage file %s\n", info_list->filename);
 #endif
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset =
+        (iter->write_offset + data_len + (sizeof(uint32_t) - 1)) &
+        -sizeof(uint32_t);
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write_string(iter, info->filename));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..5224249
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,92 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58430000u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x0100u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x0200u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x0300u+((n)&0xffu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0xff00u)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE FILENAME xencov_file COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM xencov_function..
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ */
+struct xencov_file
+{
+    uint32_t version;
+    uint32_t stamp;
+} __attribute__((packed));
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ */
+struct xencov_counter
+{
+    uint32_t num;
+    uint64_t values[0];
+} __attribute__((packed));
+
+/**
+ * Information for each function
+ * Prefixed with XENCOV_TAG_FUNC
+ * Number of counter is equal to the number of counter got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t n_ctrs[0];
+} __attribute__((packed));
+
+struct xencov_functions
+{
+    uint32_t num;
+    uint32_t xencov_function[0];
+} __attribute__((packed));
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index 360b880..306d7fe 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -94,4 +96,16 @@ static inline void init_coverage(void)
 }
 #endif
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Tue Feb 05 16:01:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2kxb-0003Zi-9A; Tue, 05 Feb 2013 16:01:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxZ-0003Z7-Nd
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:25 +0000
Received: from [85.158.139.83:34208] by server-5.bemta-5.messagelabs.com id
	68/1F-11945-5DC21115; Tue, 05 Feb 2013 16:01:25 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360080060!19674928!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14998 invoked from network); 5 Feb 2013 16:01:02 -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 Feb 2013 16:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6334977"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:01:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:59 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kx9-0005RO-Gf;
	Tue, 05 Feb 2013 16:00:59 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:19 +0000
Message-ID: <1360079900-31777-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Safety check for initialization objects.
Constructors are not used so check some module does not use them.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/Rules.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3f0b262..ae35a08 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) \
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; do \
 		case "$$name" in \
-		.text|.text.*|.data|.data.*|.bss) \
+		.text|.text.*|.data|.data.*|.bss|.ctors) \
 			test $$sz != 0 || continue; \
 			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
 			exit $$(expr $$idx + 1);; \
-- 
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 Tue Feb 05 16:01:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2kxb-0003Zi-9A; Tue, 05 Feb 2013 16:01:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U2kxZ-0003Z7-Nd
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:01:25 +0000
Received: from [85.158.139.83:34208] by server-5.bemta-5.messagelabs.com id
	68/1F-11945-5DC21115; Tue, 05 Feb 2013 16:01:25 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360080060!19674928!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14998 invoked from network); 5 Feb 2013 16:01:02 -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 Feb 2013 16:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; 
   d="scan'208";a="6334977"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:01:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:00:59 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U2kx9-0005RO-Gf;
	Tue, 05 Feb 2013 16:00:59 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 5 Feb 2013 15:58:19 +0000
Message-ID: <1360079900-31777-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Safety check for initialization objects.
Constructors are not used so check some module does not use them.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/Rules.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3f0b262..ae35a08 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) \
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; do \
 		case "$$name" in \
-		.text|.text.*|.data|.data.*|.bss) \
+		.text|.text.*|.data|.data.*|.bss|.ctors) \
 			test $$sz != 0 || continue; \
 			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
 			exit $$(expr $$idx + 1);; \
-- 
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 Tue Feb 05 16:10:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2l6Q-0004La-9g; Tue, 05 Feb 2013 16:10: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 1U2l6P-0004LV-9i
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:10:33 +0000
Received: from [85.158.143.99:43206] by server-3.bemta-4.messagelabs.com id
	68/B2-08920-7FE21115; Tue, 05 Feb 2013 16:10:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360080629!24569094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15380 invoked from network); 5 Feb 2013 16:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1163777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:10: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.297.1; Tue, 5 Feb 2013
	16:10:29 +0000
Message-ID: <1360080628.23001.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 16:10:28 +0000
In-Reply-To: <510FF54E.1070706@citrix.com>
References: <510FF54E.1070706@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> The pages within the event array need not be physically nor virtually
> contiguous, but the guest or Xen may make the virtually contiguous for
> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> Linux.  Pages are added by the guest as required by the number of
> bound event channels.

Strictly speaking the size is related to the maximum bound evtchn, which
need not be the same as the number of bound evtchns.

> The state of an event is tracked using 3 bits within the event word.
> the M (masked), P (pending) and L (linked) bits.  Only state
> transitions that change a single bit are valid.

The diagram shows transitions B<->P and P<->L, which involve two bits in
each case. So do BM<->PM and LM<->BM now I think about it.

Is the L bit redundant with the LINK field == 0 or != 0?

> 
> Event Queues
> ------------
> 
> The event queues use a singly-linked list of event array words (see
> figure \ref{fig_event-word} and \ref{fig_event-queue}).`
> 
> ![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)
> 
> Each event queue has a head and tail index stored in the control
> block.  The head index is the index of the first element in the queue.
> The tail index is the last element in the queue.  Every element within
> the queue has the L bit set.
> 
> The LINK field in the event word indexes the next event in the queue.
> LINK is zero for the last word in the queue.
> 
> The queue is empty when the head index is zero (zero is not a valid
> event channel).
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init`
> 
> * `EVTCHNOP_expand`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init`
> 
> This call initializes a single VCPU's event channel data structures,
> adding one page for the event array.

Isn't the event array per-domain?

> A guest should call this during initial VCPU bring up (and on resume?).
> 
>     struct evtchnop_init {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };

I think this will have a different layout on 32 and 64 bit x86, if you
care (because uint64_t is align(4) on 32-bit and align(8) on 64-bit).

> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frame for the domain.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand`
> 
> This call expands the event array for a VCPU by appended an additional
> page.

This doesn't seem all that different to _init, except the former handles
the transition from 0->1 event pages and this handles N->N+1?

> A guest should call this for all VCPUs when a new event channel is
> required and there is insufficient space in the current event array.



> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.
> 
> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> 
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.

EBUSY?

> EINVAL      `priority` is outside the range 0 - 15.
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the maximum number of event channels a
> domain can bind.  The default for dom0 is unlimited.  Other domains
> default to 1024 events (requiring only a single page for their event
> array).
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_events;
>     };
> 
> Field         Purpose
> -----         -------
> `domid`       [in] The domain ID.
> `max_events`  [in] The maximum number of event channels that may be bound
>               to the domain.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 
> Memory Usage
> ------------
> 
> ### Event Arrays
> 
> Xen needs to map every domains' event array into its address space.
> The space reserved for these global mappings is limited to 1 GiB on
> x86-64 (262144 pages) and is shared with other users.
> 
> It is non-trivial to calculate the maximum number of VMs that can be
> supported as this depends on the system configuration (how many driver
> domains etc.) and VM configuration.  We can make some assuptions and
> derive an approximate limit.
> 
> Each page of the event array has space for 1024 events ($E_P$) so a
> regular domU will only require a single page.  Since event channels
> typically come in pairs,

I'm not sure this is the case, since evtchns are bidirectional (i.e.
either end can use it to signal the other) so one is often shared for
both rqst and rsp notifications.

 the upper bound on the total number of pages
> is $2 \times\text{number of VMs}$.
> 
> If the guests are further restricted in the number of event channels
> ($E_V$) then this upper bound can be reduced further.
> 
> The number of VMs ($V$) with a limit of $P$ total event array pages is:
> \begin{equation*}
> V = P \div \left(1 + \frac{E_V}{E_P}\right)
> \end{equation*}
> 
> Using only half the available pages and limiting guests to only 64
> events gives:
> \begin{eqnarray*}
> V & = & (262144 / 2) \div (1 + 64 / 1024) \\
>   & = & 123 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> Alternatively, we can consider a system with $D$ driver domains, each
> of which requires $E_D$ events, and a dom0 using the maximum number of
> pages (128).
> 
> \begin{eqnarray*}
> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> \end{eqnarray*}
> 
> With, for example, 16 driver domains each using the maximum number of pages:
> \begin{eqnarray*}
> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>    & = & 129 \times 10^3\text{ VMs}
> \end{eqnarray*}

This accounts for the driver domains and dom0 but not the domains which
they are serving, doesn't it?
 
> In summary, there is space to map the event arrays for over 100,000
> VMs.  This is more than the limit imposed by the 16 bit domain ID
> (~32,000 VMs).

Is there scope to reduce the maximum then?

> 
> ### Control Block
> 
> With $L$ priority levels and two 32-bit words for the head and tail
> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> for the control block is:
> \begin{eqnarray*}
> S & = & L \times 2 \times 4 \\
>   & = & 16 \times 2 \times 4 \\
>   & = & 128\text{ bytes}
> \end{eqnarray*}
> 
> There is more than enough space within `struct vcpu_info` for the
> control block while still keeping plenty of space for future use.

There is? I can see 7 bytes of padding and 4 bytes of evtchn_pending_sel
which I suppose becomes redundant now.

I don't think it would be a problem to predicate use of this new
interface on the use of the VCPU_placement API and therefore give scope
to expand the vcpu_info.

> Low Level Design
> ================
> 
> In the pseudo code in this section, all memory accesses are atomic,
> including those to bit-fields within the event word.

> These variables have a standard meaning:
> 
> Variable  Purpose
> --------  -------
> E         Event array.
> p         A specific event.
> H         The head index for a specific priority.
> T         The tail index for a specific priority.
> 
> These memory barriers are required:
> 
> Function  Purpose
> --------  -------
> mb()      Full (read/write) memory barrier
> 
> Raising an Event
> ----------------
> 
> When Xen raises an event it marks it pending and (if it is not masked)
> adds it tail of event queue.

What are the conditions for actually performing the upcall when
returning from the hypervisor to the guest?

>     E[p].pending = 1
>     if not E[p].linked and not E[n].masked
>         E[p].linked = 1
>         E[p].link = 0
>         mb()
>         if H == 0
>             H = p
>         else
>             E[T].link = p
>         T = p

Do you not need a barrier towards the end here to ensure that a consumer
who is currently processing interrupts sees the updated link when they
get there?

> Concurrent access by Xen to the event queue must be protected by a
> per-event queue spin lock.
> 
> Consuming Events
> ----------------
> 
> The guests consumes events starting at the head until it reaches the
> tail.  Events in the queue that are not pending or are masked are
> consumed but not handled.
> 
>     while H != 0
>         p = H
>         H = E[p].link
>         if H == 0
>             mb()

What is this mb() needed for?

>             H = E[p].link
>         E[H].linked = 0

Did you mean E[p].linked here?

If at this point the interrupt is reraised then the if in the raising
pseudo code becomes true, linked will set again and don't we also race
with the clearing of E[p].pending below?

Is a barrier needed around here due to Xen also reading E[p].pending?

>         if not E[p].masked
>             handle(p)
> 
> handle() clears `E[p].pending` 

What barriers are required for this and where? Is it done at the start
or the end of the handler? (early of late EOI)

> and EOIs level-triggered PIRQs.
> 
> > Note: When the event queue contains a single event, removing the
> > event may race with Xen appending another event because the load of
> > `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> > the guest must recheck `E[p].link` if the list appeared empty.

It appears that both "Raising an Event" and "Consuming Events" can write
H? Is that correct? Likewise for the linked bit.

It's a bit unclear because the pseudo-code doesn't make it explicitly
which variables are par of the shared data structure and which are
private to the local routine.

> Masking Events
> --------------
> 
> Events are masked by setting the masked bit.  If the event is pending
> and linked it does not need to be unlinked.
> 
>     E[p].masked = 1
> 
> Unmasking Events
> ----------------
> 
> Events are unmasked by the guest by clearing the masked bit.  If the
> event is pending the guest must call the event channel unmask
> hypercall so Xen can link the event into the correct event queue.
> 
>     E[p].masked = 0
>     if E[p].pending
>         hypercall(EVTCHN_unmask)

Can the hypercall do the E[p].masked = 0?

> The expectation here is that unmasking a pending event will be rare,
> so the performance hit of the hypercall is minimal.
> 
> > Note: that after clearing the mask bit, the event may be raised and
> > thus it may already be linked by the time the hypercall is done.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 05 16:10:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2l6Q-0004La-9g; Tue, 05 Feb 2013 16:10: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 1U2l6P-0004LV-9i
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:10:33 +0000
Received: from [85.158.143.99:43206] by server-3.bemta-4.messagelabs.com id
	68/B2-08920-7FE21115; Tue, 05 Feb 2013 16:10:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360080629!24569094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15380 invoked from network); 5 Feb 2013 16:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1163777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:10: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.297.1; Tue, 5 Feb 2013
	16:10:29 +0000
Message-ID: <1360080628.23001.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 16:10:28 +0000
In-Reply-To: <510FF54E.1070706@citrix.com>
References: <510FF54E.1070706@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> The pages within the event array need not be physically nor virtually
> contiguous, but the guest or Xen may make the virtually contiguous for
> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> Linux.  Pages are added by the guest as required by the number of
> bound event channels.

Strictly speaking the size is related to the maximum bound evtchn, which
need not be the same as the number of bound evtchns.

> The state of an event is tracked using 3 bits within the event word.
> the M (masked), P (pending) and L (linked) bits.  Only state
> transitions that change a single bit are valid.

The diagram shows transitions B<->P and P<->L, which involve two bits in
each case. So do BM<->PM and LM<->BM now I think about it.

Is the L bit redundant with the LINK field == 0 or != 0?

> 
> Event Queues
> ------------
> 
> The event queues use a singly-linked list of event array words (see
> figure \ref{fig_event-word} and \ref{fig_event-queue}).`
> 
> ![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)
> 
> Each event queue has a head and tail index stored in the control
> block.  The head index is the index of the first element in the queue.
> The tail index is the last element in the queue.  Every element within
> the queue has the L bit set.
> 
> The LINK field in the event word indexes the next event in the queue.
> LINK is zero for the last word in the queue.
> 
> The queue is empty when the head index is zero (zero is not a valid
> event channel).
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init`
> 
> * `EVTCHNOP_expand`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init`
> 
> This call initializes a single VCPU's event channel data structures,
> adding one page for the event array.

Isn't the event array per-domain?

> A guest should call this during initial VCPU bring up (and on resume?).
> 
>     struct evtchnop_init {
>         uint32_t vcpu;
>         uint64_t array_pfn;
>     };

I think this will have a different layout on 32 and 64 bit x86, if you
care (because uint64_t is align(4) on 32-bit and align(8) on 64-bit).

> Field          Purpose
> -----          -------
> `vcpu`         [in] The VCPU number.
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `array_pfn` is not a valid frame for the domain.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand`
> 
> This call expands the event array for a VCPU by appended an additional
> page.

This doesn't seem all that different to _init, except the former handles
the transition from 0->1 event pages and this handles N->N+1?

> A guest should call this for all VCPUs when a new event channel is
> required and there is insufficient space in the current event array.



> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.
> 
> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> 
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.

EBUSY?

> EINVAL      `priority` is outside the range 0 - 15.
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the maximum number of event channels a
> domain can bind.  The default for dom0 is unlimited.  Other domains
> default to 1024 events (requiring only a single page for their event
> array).
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_events;
>     };
> 
> Field         Purpose
> -----         -------
> `domid`       [in] The domain ID.
> `max_events`  [in] The maximum number of event channels that may be bound
>               to the domain.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 
> Memory Usage
> ------------
> 
> ### Event Arrays
> 
> Xen needs to map every domains' event array into its address space.
> The space reserved for these global mappings is limited to 1 GiB on
> x86-64 (262144 pages) and is shared with other users.
> 
> It is non-trivial to calculate the maximum number of VMs that can be
> supported as this depends on the system configuration (how many driver
> domains etc.) and VM configuration.  We can make some assuptions and
> derive an approximate limit.
> 
> Each page of the event array has space for 1024 events ($E_P$) so a
> regular domU will only require a single page.  Since event channels
> typically come in pairs,

I'm not sure this is the case, since evtchns are bidirectional (i.e.
either end can use it to signal the other) so one is often shared for
both rqst and rsp notifications.

 the upper bound on the total number of pages
> is $2 \times\text{number of VMs}$.
> 
> If the guests are further restricted in the number of event channels
> ($E_V$) then this upper bound can be reduced further.
> 
> The number of VMs ($V$) with a limit of $P$ total event array pages is:
> \begin{equation*}
> V = P \div \left(1 + \frac{E_V}{E_P}\right)
> \end{equation*}
> 
> Using only half the available pages and limiting guests to only 64
> events gives:
> \begin{eqnarray*}
> V & = & (262144 / 2) \div (1 + 64 / 1024) \\
>   & = & 123 \times 10^3\text{ VMs}
> \end{eqnarray*}
> 
> Alternatively, we can consider a system with $D$ driver domains, each
> of which requires $E_D$ events, and a dom0 using the maximum number of
> pages (128).
> 
> \begin{eqnarray*}
> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> \end{eqnarray*}
> 
> With, for example, 16 driver domains each using the maximum number of pages:
> \begin{eqnarray*}
> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>    & = & 129 \times 10^3\text{ VMs}
> \end{eqnarray*}

This accounts for the driver domains and dom0 but not the domains which
they are serving, doesn't it?
 
> In summary, there is space to map the event arrays for over 100,000
> VMs.  This is more than the limit imposed by the 16 bit domain ID
> (~32,000 VMs).

Is there scope to reduce the maximum then?

> 
> ### Control Block
> 
> With $L$ priority levels and two 32-bit words for the head and tail
> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> for the control block is:
> \begin{eqnarray*}
> S & = & L \times 2 \times 4 \\
>   & = & 16 \times 2 \times 4 \\
>   & = & 128\text{ bytes}
> \end{eqnarray*}
> 
> There is more than enough space within `struct vcpu_info` for the
> control block while still keeping plenty of space for future use.

There is? I can see 7 bytes of padding and 4 bytes of evtchn_pending_sel
which I suppose becomes redundant now.

I don't think it would be a problem to predicate use of this new
interface on the use of the VCPU_placement API and therefore give scope
to expand the vcpu_info.

> Low Level Design
> ================
> 
> In the pseudo code in this section, all memory accesses are atomic,
> including those to bit-fields within the event word.

> These variables have a standard meaning:
> 
> Variable  Purpose
> --------  -------
> E         Event array.
> p         A specific event.
> H         The head index for a specific priority.
> T         The tail index for a specific priority.
> 
> These memory barriers are required:
> 
> Function  Purpose
> --------  -------
> mb()      Full (read/write) memory barrier
> 
> Raising an Event
> ----------------
> 
> When Xen raises an event it marks it pending and (if it is not masked)
> adds it tail of event queue.

What are the conditions for actually performing the upcall when
returning from the hypervisor to the guest?

>     E[p].pending = 1
>     if not E[p].linked and not E[n].masked
>         E[p].linked = 1
>         E[p].link = 0
>         mb()
>         if H == 0
>             H = p
>         else
>             E[T].link = p
>         T = p

Do you not need a barrier towards the end here to ensure that a consumer
who is currently processing interrupts sees the updated link when they
get there?

> Concurrent access by Xen to the event queue must be protected by a
> per-event queue spin lock.
> 
> Consuming Events
> ----------------
> 
> The guests consumes events starting at the head until it reaches the
> tail.  Events in the queue that are not pending or are masked are
> consumed but not handled.
> 
>     while H != 0
>         p = H
>         H = E[p].link
>         if H == 0
>             mb()

What is this mb() needed for?

>             H = E[p].link
>         E[H].linked = 0

Did you mean E[p].linked here?

If at this point the interrupt is reraised then the if in the raising
pseudo code becomes true, linked will set again and don't we also race
with the clearing of E[p].pending below?

Is a barrier needed around here due to Xen also reading E[p].pending?

>         if not E[p].masked
>             handle(p)
> 
> handle() clears `E[p].pending` 

What barriers are required for this and where? Is it done at the start
or the end of the handler? (early of late EOI)

> and EOIs level-triggered PIRQs.
> 
> > Note: When the event queue contains a single event, removing the
> > event may race with Xen appending another event because the load of
> > `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> > the guest must recheck `E[p].link` if the list appeared empty.

It appears that both "Raising an Event" and "Consuming Events" can write
H? Is that correct? Likewise for the linked bit.

It's a bit unclear because the pseudo-code doesn't make it explicitly
which variables are par of the shared data structure and which are
private to the local routine.

> Masking Events
> --------------
> 
> Events are masked by setting the masked bit.  If the event is pending
> and linked it does not need to be unlinked.
> 
>     E[p].masked = 1
> 
> Unmasking Events
> ----------------
> 
> Events are unmasked by the guest by clearing the masked bit.  If the
> event is pending the guest must call the event channel unmask
> hypercall so Xen can link the event into the correct event queue.
> 
>     E[p].masked = 0
>     if E[p].pending
>         hypercall(EVTCHN_unmask)

Can the hypercall do the E[p].masked = 0?

> The expectation here is that unmasking a pending event will be rare,
> so the performance hit of the hypercall is minimal.
> 
> > Note: that after clearing the mask bit, the event may be raised and
> > thus it may already be linked by the time the hypercall is done.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 05 16:12:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2l7c-0004R9-Pf; Tue, 05 Feb 2013 16:11: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 1U2l7a-0004Qv-QV
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:11:47 +0000
Received: from [85.158.143.35:63537] by server-2.bemta-4.messagelabs.com id
	9E/48-01597-D3F21115; Tue, 05 Feb 2013 16:11:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360080699!13094533!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32505 invoked from network); 5 Feb 2013 16:11:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:11:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1163808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:11: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.297.1; Tue, 5 Feb 2013
	16:11:39 +0000
Message-ID: <1360080697.23001.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 16:11:37 +0000
In-Reply-To: <51112B51.3050406@citrix.com>
References: <CD36DA7D.5A0EC%keir@xen.org> <51112B51.3050406@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 15:54 +0000, David Vrabel wrote:
> On 05/02/13 15:49, Keir Fraser wrote:
> > On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:
> > 
> >>> I have some sympathy for this design. It's primary downside compared with
> >>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
> >>> you say the fairness and prioritisation features are rather nice. Also
> >>> having the data structures be per vcpu may well help avoid cacheline
> >>> contention on busy multi-vcpu guests.
> >>
> >> This design originally (before I posted it) did have per-VCPU event
> >> arrays but I changed it to per-domain to reduce the memory footprint.
> > 
> > Okay, I wonder how much it actually matters anyhow...
> > 
> > Oh by the way you say the control block is 128 bytes and will easily fit in
> > the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > So how does that work then?
> 
> I meant struct vcpu_info can be extended without it growing to more than
> a page.  i.e., it fits into the guest page provided in the
> VCPUOP_register_vcpu_info call so no additional pages need to be
> globally mapped for the control block.

VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
by itself, even if that happens to be the Linux implementation today (I
haven't checked 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 Feb 05 16:12:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 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 1U2l7c-0004R9-Pf; Tue, 05 Feb 2013 16:11: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 1U2l7a-0004Qv-QV
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:11:47 +0000
Received: from [85.158.143.35:63537] by server-2.bemta-4.messagelabs.com id
	9E/48-01597-D3F21115; Tue, 05 Feb 2013 16:11:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360080699!13094533!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32505 invoked from network); 5 Feb 2013 16:11:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:11:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1163808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:11: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.297.1; Tue, 5 Feb 2013
	16:11:39 +0000
Message-ID: <1360080697.23001.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 16:11:37 +0000
In-Reply-To: <51112B51.3050406@citrix.com>
References: <CD36DA7D.5A0EC%keir@xen.org> <51112B51.3050406@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 15:54 +0000, David Vrabel wrote:
> On 05/02/13 15:49, Keir Fraser wrote:
> > On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:
> > 
> >>> I have some sympathy for this design. It's primary downside compared with
> >>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
> >>> you say the fairness and prioritisation features are rather nice. Also
> >>> having the data structures be per vcpu may well help avoid cacheline
> >>> contention on busy multi-vcpu guests.
> >>
> >> This design originally (before I posted it) did have per-VCPU event
> >> arrays but I changed it to per-domain to reduce the memory footprint.
> > 
> > Okay, I wonder how much it actually matters anyhow...
> > 
> > Oh by the way you say the control block is 128 bytes and will easily fit in
> > the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > So how does that work then?
> 
> I meant struct vcpu_info can be extended without it growing to more than
> a page.  i.e., it fits into the guest page provided in the
> VCPUOP_register_vcpu_info call so no additional pages need to be
> globally mapped for the control block.

VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
by itself, even if that happens to be the Linux implementation today (I
haven't checked 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 Feb 05 16:12:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:12: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 1U2l7d-0004RH-5h; Tue, 05 Feb 2013 16:11:49 +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 1U2l7b-0004Qv-VK
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:11:48 +0000
Received: from [85.158.143.35:63772] by server-2.bemta-4.messagelabs.com id
	B1/78-01597-34F21115; Tue, 05 Feb 2013 16:11:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360080706!5013929!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3667 invoked from network); 5 Feb 2013 16:11:47 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:11:47 -0000
Received: by mail-wg0-f49.google.com with SMTP id 15so271794wgd.16
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 08:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=+m3Ks0beiSajPFLpZp2ykDDNaZtWHIF4hSqcpCLToek=;
	b=ivXcLwkZ5qy41WJtgBAW0p8DVWyozHxsSr2lAfIAhhMl0amYr6PzdLDXKVgkhxIMmd
	Y/MKiEZJxrUnyo6XC9PBGqKl0qMHt4fh+wv/V/REvam5x68bm8XfT02I5od2MIBHsVxD
	4XLOJkDH+HJ+vtSmYdtpvBW8KiW1PzmwzPsTkKHmC37OI0RPRQz0uWZ/VXqiT2zzhTOP
	EzrbE6OlxZ3xDZS8qDNdRSMPrK3psb3XbVieS/tmY8zHrBwkor48RSQ4/ZqQYwygeIGh
	qcQnfnaIWN4GDD1oOsW4rhPEKp1Ody294MPxiYrqE4gpaBYTbgzVQrQcKRhzuL7usa+h
	eoqw==
X-Received: by 10.180.92.129 with SMTP id cm1mr18400520wib.10.1360080706419;
	Tue, 05 Feb 2013 08:11:46 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id df2sm26652518wib.0.2013.02.05.08.11.44
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 08:11:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 05 Feb 2013 16:11:41 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD36DFBD.5A19A%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4Du3u70NuKfEMsXkaqSl22SBAd6Q==
In-Reply-To: <51112B51.3050406@citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 15:54, "David Vrabel" <david.vrabel@citrix.com> wrote:

> On 05/02/13 15:49, Keir Fraser wrote:
>> On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:
>> 
>>>> I have some sympathy for this design. It's primary downside compared with
>>>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>>>> you say the fairness and prioritisation features are rather nice. Also
>>>> having the data structures be per vcpu may well help avoid cacheline
>>>> contention on busy multi-vcpu guests.
>>> 
>>> This design originally (before I posted it) did have per-VCPU event
>>> arrays but I changed it to per-domain to reduce the memory footprint.
>> 
>> Okay, I wonder how much it actually matters anyhow...
>> 
>> Oh by the way you say the control block is 128 bytes and will easily fit in
>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
>> So how does that work then?
> 
> I meant struct vcpu_info can be extended without it growing to more than
> a page.  i.e., it fits into the guest page provided in the
> VCPUOP_register_vcpu_info call so no additional pages need to be
> globally mapped for the control block.

Oh, I see so any guest that uses the new event-channel interface will
understand that vcpu_info is extended to contain it. Well, that makes sense.
It's not what your document says though.

 -- Keir

> David



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:12:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:12: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 1U2l7d-0004RH-5h; Tue, 05 Feb 2013 16:11:49 +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 1U2l7b-0004Qv-VK
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:11:48 +0000
Received: from [85.158.143.35:63772] by server-2.bemta-4.messagelabs.com id
	B1/78-01597-34F21115; Tue, 05 Feb 2013 16:11:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360080706!5013929!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3667 invoked from network); 5 Feb 2013 16:11:47 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:11:47 -0000
Received: by mail-wg0-f49.google.com with SMTP id 15so271794wgd.16
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 08:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=+m3Ks0beiSajPFLpZp2ykDDNaZtWHIF4hSqcpCLToek=;
	b=ivXcLwkZ5qy41WJtgBAW0p8DVWyozHxsSr2lAfIAhhMl0amYr6PzdLDXKVgkhxIMmd
	Y/MKiEZJxrUnyo6XC9PBGqKl0qMHt4fh+wv/V/REvam5x68bm8XfT02I5od2MIBHsVxD
	4XLOJkDH+HJ+vtSmYdtpvBW8KiW1PzmwzPsTkKHmC37OI0RPRQz0uWZ/VXqiT2zzhTOP
	EzrbE6OlxZ3xDZS8qDNdRSMPrK3psb3XbVieS/tmY8zHrBwkor48RSQ4/ZqQYwygeIGh
	qcQnfnaIWN4GDD1oOsW4rhPEKp1Ody294MPxiYrqE4gpaBYTbgzVQrQcKRhzuL7usa+h
	eoqw==
X-Received: by 10.180.92.129 with SMTP id cm1mr18400520wib.10.1360080706419;
	Tue, 05 Feb 2013 08:11:46 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id df2sm26652518wib.0.2013.02.05.08.11.44
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 08:11:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 05 Feb 2013 16:11:41 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD36DFBD.5A19A%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4Du3u70NuKfEMsXkaqSl22SBAd6Q==
In-Reply-To: <51112B51.3050406@citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 15:54, "David Vrabel" <david.vrabel@citrix.com> wrote:

> On 05/02/13 15:49, Keir Fraser wrote:
>> On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:
>> 
>>>> I have some sympathy for this design. It's primary downside compared with
>>>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>>>> you say the fairness and prioritisation features are rather nice. Also
>>>> having the data structures be per vcpu may well help avoid cacheline
>>>> contention on busy multi-vcpu guests.
>>> 
>>> This design originally (before I posted it) did have per-VCPU event
>>> arrays but I changed it to per-domain to reduce the memory footprint.
>> 
>> Okay, I wonder how much it actually matters anyhow...
>> 
>> Oh by the way you say the control block is 128 bytes and will easily fit in
>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
>> So how does that work then?
> 
> I meant struct vcpu_info can be extended without it growing to more than
> a page.  i.e., it fits into the guest page provided in the
> VCPUOP_register_vcpu_info call so no additional pages need to be
> globally mapped for the control block.

Oh, I see so any guest that uses the new event-channel interface will
understand that vcpu_info is extended to contain it. Well, that makes sense.
It's not what your document says though.

 -- Keir

> David



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:19:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:19: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 1U2lEs-0004zW-9Y; Tue, 05 Feb 2013 16:19:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U2lEq-0004zR-JD
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 16:19:16 +0000
Received: from [85.158.143.99:31090] by server-3.bemta-4.messagelabs.com id
	A5/AE-08920-00131115; Tue, 05 Feb 2013 16:19:12 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360081150!24570726!1
X-Originating-IP: [209.85.214.51]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21564 invoked from network); 5 Feb 2013 16:19:11 -0000
Received: from mail-bk0-f51.google.com (HELO mail-bk0-f51.google.com)
	(209.85.214.51)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:19:11 -0000
Received: by mail-bk0-f51.google.com with SMTP id ik5so166062bkc.24
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Feb 2013 08:15:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=/aWnkq/s2XJHPXWPj3iyxastqe3Y7NR0Qv3cJP6KUoM=;
	b=MUJj5Io0D0LasrGG6+7Br88v6+SI/UIB5Mt9PX6i+iw1uIvf3/0pZox6z8Tcd4FH0B
	dqLOASex4IwLsLVB+O+Ohc5auIVMoV70yKIovUf0Gvp789VF+x9EprcpoVRHLtiPwSUN
	ygxkg2F68Sq9LmZPXE+qMiVZCF4waxV4cw6HGJqAj4UQhIrfbGf2Tc0gc60l8J4oqb+N
	okN3bC3C4jWlcoihjq1aCkCFXrQsau8QYgDQF/j87KaM/DoKwyWBY2orSZ7bN3kg2tIL
	9+489HbBnBTik29zd7ZD2fqzbJyszFaikWLWraNvoW3z6ApbQuoLS/uYrBVjZ0xppZAP
	mqGg==
X-Received: by 10.204.7.92 with SMTP id c28mr6720064bkc.86.1360080926780;
	Tue, 05 Feb 2013 08:15:26 -0800 (PST)
Received: from [192.168.1.38] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id z5sm6774514bkv.11.2013.02.05.08.15.24
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 08:15:25 -0800 (PST)
Message-ID: <5111301B.8080304@heliman.it>
Date: Tue, 05 Feb 2013 17:15:23 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com, 
	Ian.Campbell@citrix.com
X-Gm-Message-State: ALoCoQkGcCzqIXfQ2tEyMEO896Jd/woz0s8qOSpoO/OII0M8C3FubAOiFfgqXDvX+MJapfkPT1df
Subject: [Xen-devel] [PATCH] tools/libxl: Disable useless empty floppy drive
	with 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-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

tools/libxl: Disable useless empty floppy drive with
  qemu-xen

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
  tools/libxl/libxl_dm.c |    3 +++
  1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51f9914..c265618 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -406,6 +406,9 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
          int ioemu_nics = 0;

+        /* Disable useless empty floppy drive */
+        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
+
          if (b_info->u.hvm.serial) {
              flexarray_vappend(dm_args, "-serial", 
b_info->u.hvm.serial, NULL);
          }
-- 
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 Tue Feb 05 16:19:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:19: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 1U2lEs-0004zW-9Y; Tue, 05 Feb 2013 16:19:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U2lEq-0004zR-JD
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 16:19:16 +0000
Received: from [85.158.143.99:31090] by server-3.bemta-4.messagelabs.com id
	A5/AE-08920-00131115; Tue, 05 Feb 2013 16:19:12 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360081150!24570726!1
X-Originating-IP: [209.85.214.51]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21564 invoked from network); 5 Feb 2013 16:19:11 -0000
Received: from mail-bk0-f51.google.com (HELO mail-bk0-f51.google.com)
	(209.85.214.51)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:19:11 -0000
Received: by mail-bk0-f51.google.com with SMTP id ik5so166062bkc.24
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Feb 2013 08:15:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=/aWnkq/s2XJHPXWPj3iyxastqe3Y7NR0Qv3cJP6KUoM=;
	b=MUJj5Io0D0LasrGG6+7Br88v6+SI/UIB5Mt9PX6i+iw1uIvf3/0pZox6z8Tcd4FH0B
	dqLOASex4IwLsLVB+O+Ohc5auIVMoV70yKIovUf0Gvp789VF+x9EprcpoVRHLtiPwSUN
	ygxkg2F68Sq9LmZPXE+qMiVZCF4waxV4cw6HGJqAj4UQhIrfbGf2Tc0gc60l8J4oqb+N
	okN3bC3C4jWlcoihjq1aCkCFXrQsau8QYgDQF/j87KaM/DoKwyWBY2orSZ7bN3kg2tIL
	9+489HbBnBTik29zd7ZD2fqzbJyszFaikWLWraNvoW3z6ApbQuoLS/uYrBVjZ0xppZAP
	mqGg==
X-Received: by 10.204.7.92 with SMTP id c28mr6720064bkc.86.1360080926780;
	Tue, 05 Feb 2013 08:15:26 -0800 (PST)
Received: from [192.168.1.38] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id z5sm6774514bkv.11.2013.02.05.08.15.24
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 08:15:25 -0800 (PST)
Message-ID: <5111301B.8080304@heliman.it>
Date: Tue, 05 Feb 2013 17:15:23 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com, 
	Ian.Campbell@citrix.com
X-Gm-Message-State: ALoCoQkGcCzqIXfQ2tEyMEO896Jd/woz0s8qOSpoO/OII0M8C3FubAOiFfgqXDvX+MJapfkPT1df
Subject: [Xen-devel] [PATCH] tools/libxl: Disable useless empty floppy drive
	with 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-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

tools/libxl: Disable useless empty floppy drive with
  qemu-xen

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
  tools/libxl/libxl_dm.c |    3 +++
  1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51f9914..c265618 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -406,6 +406,9 @@ static char ** 
libxl__build_device_model_args_new(libxl__gc *gc,
      if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
          int ioemu_nics = 0;

+        /* Disable useless empty floppy drive */
+        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
+
          if (b_info->u.hvm.serial) {
              flexarray_vappend(dm_args, "-serial", 
b_info->u.hvm.serial, NULL);
          }
-- 
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 Tue Feb 05 16:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:19: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 1U2lF2-000502-MC; Tue, 05 Feb 2013 16: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.Campbell@citrix.com>) id 1U2lF0-0004zo-BS
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:19:26 +0000
Received: from [85.158.143.35:30440] by server-3.bemta-4.messagelabs.com id
	35/EE-08920-D0131115; Tue, 05 Feb 2013 16:19:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360081163!11277452!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31863 invoked from network); 5 Feb 2013 16:19:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1164136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:19: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.297.1; Tue, 5 Feb 2013
	16:19:23 +0000
Message-ID: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 16:19:22 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] Install in /usr/local 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

Lets try this again.

The first patch adjusts the initscripts to use explicit paths, this
follows the NetBSD method of using hotplugpath.sh (I resisted renaming
since its all a bit entwined).

This time I have more carefully cleaned all vestiges of Xen out
from /usr and installed into /usr/local and tested PV and HVM guests.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:19: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 1U2lF2-000502-MC; Tue, 05 Feb 2013 16: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.Campbell@citrix.com>) id 1U2lF0-0004zo-BS
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:19:26 +0000
Received: from [85.158.143.35:30440] by server-3.bemta-4.messagelabs.com id
	35/EE-08920-D0131115; Tue, 05 Feb 2013 16:19:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360081163!11277452!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31863 invoked from network); 5 Feb 2013 16:19:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1164136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:19: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.297.1; Tue, 5 Feb 2013
	16:19:23 +0000
Message-ID: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 16:19:22 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Matt Wilson <msw@amazon.com>,
	Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] Install in /usr/local 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

Lets try this again.

The first patch adjusts the initscripts to use explicit paths, this
follows the NetBSD method of using hotplugpath.sh (I resisted renaming
since its all a bit entwined).

This time I have more carefully cleaned all vestiges of Xen out
from /usr and installed into /usr/local and tested PV and HVM guests.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:20: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 1U2lFY-00053a-45; Tue, 05 Feb 2013 16:20: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 1U2lFV-000537-Rk
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:19:58 +0000
Received: from [85.158.143.35:31716] by server-2.bemta-4.messagelabs.com id
	7F/53-01597-D2131115; Tue, 05 Feb 2013 16:19:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360081194!13095814!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32072 invoked from network); 5 Feb 2013 16:19:56 -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;
	5 Feb 2013 16:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6338360"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:19:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:19:53 -0500
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 1U2lFR-0005jO-QT;
	Tue, 05 Feb 2013 16:19:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 16:19:52 +0000
Message-ID: <1360081193-17948-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
References: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Matt Wilson <msw@amazon.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] hotplug/Linux: Remove hardcoded 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

Use xen-hotplugpath.sh (as NEtBSD does) which allows PREFIX etc to change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/hotplug/Linux/init.d/xen-watchdog |    4 +++-
 tools/hotplug/Linux/init.d/xencommons   |   24 ++++++++++++------------
 tools/hotplug/Linux/init.d/xend         |   16 +++++++++-------
 tools/hotplug/Linux/init.d/xendomains   |    6 ++++--
 4 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xen-watchdog b/tools/hotplug/Linux/init.d/xen-watchdog
index 55dd091..3592fda 100644
--- a/tools/hotplug/Linux/init.d/xen-watchdog
+++ b/tools/hotplug/Linux/init.d/xen-watchdog
@@ -17,7 +17,9 @@
 ### END INIT INFO
 #
 
-DAEMON=/usr/sbin/xenwatchdogd
+. /etc/xen/scripts/hotplugpath.sh
+
+DAEMON=${SBINDIR}/xenwatchdogd
 base=$(basename $DAEMON)
 
 # Source function library.
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 20afcc0..a2e633b 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -18,6 +18,8 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
+. /etc/xen/scripts/hotplugpath.sh
+
 if [ -d /etc/sysconfig ]; then
 	xencommons_config=/etc/sysconfig
 else
@@ -72,7 +74,7 @@ do_start () {
 	modprobe blktap2 2>/dev/null || modprobe blktap 2>/dev/null
 	mkdir -p /var/run/xen
 
-	if ! `xenstore-read -s / >/dev/null 2>&1`
+	if ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="/var/lib/xenstored"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
@@ -81,19 +83,19 @@ do_start () {
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
 		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		elif [ -x /usr/sbin/oxenstored ] ; then
+		elif [ -x ${SBINDIR}/oxenstored ] ; then
 		    echo -n Starting oxenstored...
-		    /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		elif [ -x /usr/sbin/xenstored ] ; then
+		    ${SBINDIR}/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x ${SBINDIR}/xenstored ] ; then
 		    echo -n Starting C xenstored...
-		    /usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		    ${SBINDIR}/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
 		else
 		    echo "No xenstored found"
 		    exit 1
 		fi
 
 		# Wait for xenstored to actually come up, timing out after 30 seconds
-                while [ $time -lt $timeout ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do
+                while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
                     echo -n .
 		    time=$(($time+1))
                     sleep 1
@@ -107,16 +109,14 @@ do_start () {
 		fi
 
 		echo Setting domain 0 name...
-		xenstore-write "/local/domain/0/name" "Domain-0"
+		${BINDIR}/xenstore-write "/local/domain/0/name" "Domain-0"
 	fi
 
 	echo Starting xenconsoled...
 	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
-	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
-	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
-	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	echo Starting QEMU as disk backend for dom0
-	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC}/qemu-system-i386"
 	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
 		-monitor /dev/null -serial /dev/null -parallel /dev/null \
 		-pidfile $QEMU_PIDFILE
@@ -144,7 +144,7 @@ case "$1" in
 	do_start
 	;;
   status)
-        xenstore-read -s /
+        ${BINDIR}/xenstore-read -s /
 	;;
   stop)
 	do_stop
diff --git a/tools/hotplug/Linux/init.d/xend b/tools/hotplug/Linux/init.d/xend
index 0fd7b16..5f92cdc 100755
--- a/tools/hotplug/Linux/init.d/xend
+++ b/tools/hotplug/Linux/init.d/xend
@@ -18,6 +18,8 @@
 # Description:       Starts and stops the Xen control daemon.
 ### END INIT INFO
 
+. /etc/xen/scripts/hotplugpath.sh
+
 shopt -s extglob
 
 # Wait for Xend to be up
@@ -25,12 +27,12 @@ function await_daemons_up
 {
 	i=1
 	rets=10
-	xend status
+	${SBINDIR}/xend status
 	while [ $? -ne 0 -a $i -lt $rets ]; do
 	    sleep 1
 	    echo -n .
 	    i=$(($i + 1))
-	    xend status
+	    ${SBINDIR}/xend status
 	done
 }
 
@@ -48,21 +50,21 @@ case "$1" in
 	else
 		touch /var/lock/xend
 	fi
-	xend start
+	${SBINDIR}/xend start
 	await_daemons_up
 	;;
   stop)
-	xend stop
+	${SBINDIR}/xend stop
 	rm -f /var/lock/subsys/xend /var/lock/xend
 	;;
   status)
-	xend status
+	${SBINDIR}/xend status
 	;;
   reload)
-        xend reload
+        ${SBINDIR}/xend reload
         ;;
   restart|force-reload)
-	xend restart
+	${SBINDIR}/xend restart
 	await_daemons_up
 	;;
   *)
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index 00e5944..2a1999a 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -27,11 +27,13 @@
 #                    boots / shuts down.
 ### END INIT INFO
 
-CMD=xm
+. /etc/xen/scripts/hotplugpath.sh
+
+CMD=${SBINDIR}/xm
 $CMD list &> /dev/null
 if test $? -ne 0
 then
-	CMD=xl
+	CMD=${SBINDIR}/xl
 fi
 
 $CMD list &> /dev/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 Feb 05 16:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:20: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 1U2lFY-00053a-45; Tue, 05 Feb 2013 16:20: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 1U2lFV-000537-Rk
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:19:58 +0000
Received: from [85.158.143.35:31716] by server-2.bemta-4.messagelabs.com id
	7F/53-01597-D2131115; Tue, 05 Feb 2013 16:19:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360081194!13095814!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32072 invoked from network); 5 Feb 2013 16:19:56 -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;
	5 Feb 2013 16:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6338360"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:19:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:19:53 -0500
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 1U2lFR-0005jO-QT;
	Tue, 05 Feb 2013 16:19:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 16:19:52 +0000
Message-ID: <1360081193-17948-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
References: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Matt Wilson <msw@amazon.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] hotplug/Linux: Remove hardcoded 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

Use xen-hotplugpath.sh (as NEtBSD does) which allows PREFIX etc to change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/hotplug/Linux/init.d/xen-watchdog |    4 +++-
 tools/hotplug/Linux/init.d/xencommons   |   24 ++++++++++++------------
 tools/hotplug/Linux/init.d/xend         |   16 +++++++++-------
 tools/hotplug/Linux/init.d/xendomains   |    6 ++++--
 4 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xen-watchdog b/tools/hotplug/Linux/init.d/xen-watchdog
index 55dd091..3592fda 100644
--- a/tools/hotplug/Linux/init.d/xen-watchdog
+++ b/tools/hotplug/Linux/init.d/xen-watchdog
@@ -17,7 +17,9 @@
 ### END INIT INFO
 #
 
-DAEMON=/usr/sbin/xenwatchdogd
+. /etc/xen/scripts/hotplugpath.sh
+
+DAEMON=${SBINDIR}/xenwatchdogd
 base=$(basename $DAEMON)
 
 # Source function library.
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 20afcc0..a2e633b 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -18,6 +18,8 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
+. /etc/xen/scripts/hotplugpath.sh
+
 if [ -d /etc/sysconfig ]; then
 	xencommons_config=/etc/sysconfig
 else
@@ -72,7 +74,7 @@ do_start () {
 	modprobe blktap2 2>/dev/null || modprobe blktap 2>/dev/null
 	mkdir -p /var/run/xen
 
-	if ! `xenstore-read -s / >/dev/null 2>&1`
+	if ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="/var/lib/xenstored"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
@@ -81,19 +83,19 @@ do_start () {
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
 		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		elif [ -x /usr/sbin/oxenstored ] ; then
+		elif [ -x ${SBINDIR}/oxenstored ] ; then
 		    echo -n Starting oxenstored...
-		    /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		elif [ -x /usr/sbin/xenstored ] ; then
+		    ${SBINDIR}/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		elif [ -x ${SBINDIR}/xenstored ] ; then
 		    echo -n Starting C xenstored...
-		    /usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+		    ${SBINDIR}/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
 		else
 		    echo "No xenstored found"
 		    exit 1
 		fi
 
 		# Wait for xenstored to actually come up, timing out after 30 seconds
-                while [ $time -lt $timeout ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do
+                while [ $time -lt $timeout ] && ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1` ; do
                     echo -n .
 		    time=$(($time+1))
                     sleep 1
@@ -107,16 +109,14 @@ do_start () {
 		fi
 
 		echo Setting domain 0 name...
-		xenstore-write "/local/domain/0/name" "Domain-0"
+		${BINDIR}/xenstore-write "/local/domain/0/name" "Domain-0"
 	fi
 
 	echo Starting xenconsoled...
 	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" --log=$XENCONSOLED_TRACE"
-	xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
-	test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
-	test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
+	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
 	echo Starting QEMU as disk backend for dom0
-	test -z "$QEMU_XEN" && QEMU_XEN=/usr/lib/xen/bin/qemu-system-i386
+	test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC}/qemu-system-i386"
 	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
 		-monitor /dev/null -serial /dev/null -parallel /dev/null \
 		-pidfile $QEMU_PIDFILE
@@ -144,7 +144,7 @@ case "$1" in
 	do_start
 	;;
   status)
-        xenstore-read -s /
+        ${BINDIR}/xenstore-read -s /
 	;;
   stop)
 	do_stop
diff --git a/tools/hotplug/Linux/init.d/xend b/tools/hotplug/Linux/init.d/xend
index 0fd7b16..5f92cdc 100755
--- a/tools/hotplug/Linux/init.d/xend
+++ b/tools/hotplug/Linux/init.d/xend
@@ -18,6 +18,8 @@
 # Description:       Starts and stops the Xen control daemon.
 ### END INIT INFO
 
+. /etc/xen/scripts/hotplugpath.sh
+
 shopt -s extglob
 
 # Wait for Xend to be up
@@ -25,12 +27,12 @@ function await_daemons_up
 {
 	i=1
 	rets=10
-	xend status
+	${SBINDIR}/xend status
 	while [ $? -ne 0 -a $i -lt $rets ]; do
 	    sleep 1
 	    echo -n .
 	    i=$(($i + 1))
-	    xend status
+	    ${SBINDIR}/xend status
 	done
 }
 
@@ -48,21 +50,21 @@ case "$1" in
 	else
 		touch /var/lock/xend
 	fi
-	xend start
+	${SBINDIR}/xend start
 	await_daemons_up
 	;;
   stop)
-	xend stop
+	${SBINDIR}/xend stop
 	rm -f /var/lock/subsys/xend /var/lock/xend
 	;;
   status)
-	xend status
+	${SBINDIR}/xend status
 	;;
   reload)
-        xend reload
+        ${SBINDIR}/xend reload
         ;;
   restart|force-reload)
-	xend restart
+	${SBINDIR}/xend restart
 	await_daemons_up
 	;;
   *)
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index 00e5944..2a1999a 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -27,11 +27,13 @@
 #                    boots / shuts down.
 ### END INIT INFO
 
-CMD=xm
+. /etc/xen/scripts/hotplugpath.sh
+
+CMD=${SBINDIR}/xm
 $CMD list &> /dev/null
 if test $? -ne 0
 then
-	CMD=xl
+	CMD=${SBINDIR}/xl
 fi
 
 $CMD list &> /dev/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 Feb 05 16:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:20: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 1U2lFb-00054A-GZ; Tue, 05 Feb 2013 16:20:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2lFa-00053J-5g
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:20:02 +0000
Received: from [85.158.143.35:31762] by server-1.bemta-4.messagelabs.com id
	E6/EA-08839-D2131115; Tue, 05 Feb 2013 16:19:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360081194!13095814!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32163 invoked from network); 5 Feb 2013 16:19:56 -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;
	5 Feb 2013 16:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6338361"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:19:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:19:53 -0500
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 1U2lFR-0005jO-Qy;
	Tue, 05 Feb 2013 16:19:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 16:19:53 +0000
Message-ID: <1360081193-17948-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
References: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Matt Wilson <msw@amazon.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] tools+stubdom: install under /usr/local 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tm93IHRoYXQgdGhlIGhvdHBsdWcgc2NyaXB0cyBoYXZlIGJlZW4gZml4ZWQgdG8gcmVtb3ZlIGhh
cmRjb2RlZCBwYXRocyBsZXRzCnRyeSB0aGlzIGFnYWluLiBGcm9tIDI2NDcwOmFjYWYyOTIwM2Nm
OToKCglUaGlzIGlzIHRoZSBkZWZhY3RvIChvciBGSFMgbWFuZGF0ZWQ/KSBzdGFuZGFyZCBsb2Nh
dGlvbiBmb3Igc29mdHdhcmUKCWJ1aWx0IGZyb20gc291cmNlLCBpbiBvcmRlciB0byBhdm9pZCBj
bGFzaGluZyB3aXRoIHBhY2thZ2VkIHNvZnR3YXJlCgl3aGljaCBpcyBpbnN0YWxsZWQgdW5kZXIg
L3Vzci9iaW4gZXRjLgoKCUkgdGhpbmsgdGhlcmUgaXMgYmVuZWZpdCBpbiBoYXZpbmcgWGVuJ3Mg
aW5zdGFsbCBiZWhhdmUgbW9yZSBsaWtlIHRoZQoJbWFqb3JpdHkgb2Ygb3RoZXIgT1NTIHNvZnR3
YXJlIG91dCB0aGVyZS4KCglUaGUgbWFqb3IgZG93bnNpZGUgaGVyZSBpcyBpbiB0aGUgdHJhbnNp
dGlvbiBmcm9tIDQuMiB0byA0LjMgd2hlcmUKCXBlb3BsZSB3aG8gaGF2ZSBidWlsdCBmcm9tIHNv
dXJjZSB3aWxsIGlubmV2aXRhYmx5IGRpc2NvdmVyIGJyZWFrYWdlCgliZWNhdXNlIDQuMyBubyBs
b25nZXIgb3ZlcndyaXRlcyBzdHVmZiBpbiAvdXNyIGxpa2UgaXQgdXNlZCB0byBzbyB0aGV5Cglw
aWNrdXAgb2xkIHN0YWxlIGJpdHMgZnJvbSAvdXNyIGluc3RlYWQgb2YgbmV3IHN0dWZmIGZyb20g
L3Vzci9sb2NhbC4KCglQYWNrYWdlcyB3aWxsIHVzZSAuL2NvbmZpZ3VyZSAtLXByZWZpeD0vdXNy
IG9yIHdoYXRldmVyIGhlbHBlciBtYWNybwoJdGhlaXIgcGFja2FnZSBtYW5hZ2VyIGdpdmVzIHRo
ZW0uIEkgaGF2ZSBjb25maXJtZWQgdGhhdCBkb2luZyB0aGlzCglyZXN1bHRzIGluIHRoZSBzYW1l
IGxpc3Qgb2YgaW5zdGFsbGVkIGZpbGVzIGFzIGJlZm9yZSB0aGlzIHBhdGNoIHdhcwoJYXBwbGll
ZC4KCglUaGUgaHlwZXJ2aXNvciByZW1haW5zIGluIC9ib290LyBhbmQgdGhlcmUgaXMgbm8gaW50
ZW50aW9uIHRvIG1vdmUgaXQuCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1w
YmVsbEBjaXRyaXguY29tPgpDYzogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+CkNjOiBNYXR0IFdpbHNvbiA8bXN3QGFtYXpvbi5jb20+Ci0tLQogY29uZmlndXJlICAgICAg
ICAgICAgfCAgICAyIC0tCiBjb25maWd1cmUuYWMgICAgICAgICB8ICAgIDEgLQogZG9jcy9jb25m
aWd1cmUgICAgICAgfCAgICAyIC0tCiBkb2NzL2NvbmZpZ3VyZS5hYyAgICB8ICAgIDEgLQogc3R1
YmRvbS9jb25maWd1cmUgICAgfCAgICAyIC0tCiBzdHViZG9tL2NvbmZpZ3VyZS5hYyB8ICAgIDEg
LQogdG9vbHMvY29uZmlndXJlICAgICAgfCAgICAyIC0tCiB0b29scy9jb25maWd1cmUuYWMgICB8
ICAgIDEgLQogOCBmaWxlcyBjaGFuZ2VkLCAwIGluc2VydGlvbnMoKyksIDEyIGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZSBiL2NvbmZpZ3VyZQppbmRleCBjMmVjODdkLi5jYmMz
OGJhIDEwMDc1NQotLS0gYS9jb25maWd1cmUKKysrIGIvY29uZmlndXJlCkBAIC01NTcsNyArNTU3
LDYgQEAgUEFDS0FHRV9CVUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW4ub3JnJwogUEFDS0FH
RV9VUkw9J2h0dHA6Ly93d3cueGVuLm9yZy8nCiAKIGFjX3VuaXF1ZV9maWxlPSIuL3hlbi9jb21t
b24va2VybmVsLmMiCi1hY19kZWZhdWx0X3ByZWZpeD0vdXNyCiBlbmFibGVfb3B0aW9uX2NoZWNr
aW5nPW5vCiBhY19zdWJzdF92YXJzPSdMVExJQk9CSlMKIExJQk9CSlMKQEAgLTE2ODYsNyArMTY4
NSw2IEBAIGFjX2NvbmZpZ19maWxlcz0iJGFjX2NvbmZpZ19maWxlcyAuL2NvbmZpZy9Ub3BsZXZl
bC5tayIKIAogCiAKLQogYWNfYXV4X2Rpcj0KIGZvciBhY19kaXIgaW4gIiRzcmNkaXIiICIkc3Jj
ZGlyLy4uIiAiJHNyY2Rpci8uLi8uLiI7IGRvCiAgIGlmIHRlc3QgLWYgIiRhY19kaXIvaW5zdGFs
bC1zaCI7IHRoZW4KZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZS5hYyBiL2NvbmZpZ3VyZS5hYwppbmRl
eCBkZjFkNWRhLi5iMTdlNjcxIDEwMDY0NAotLS0gYS9jb25maWd1cmUuYWMKKysrIGIvY29uZmln
dXJlLmFjCkBAIC02LDcgKzYsNiBAQCBBQ19JTklUKFtYZW4gSHlwZXJ2aXNvcl0sIG00X2VzeXNj
bWQoWy4vdmVyc2lvbi5zaCAuL3hlbi9NYWtlZmlsZV0pLAogICAgIFt4ZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZ10sIFt4ZW5dLCBbaHR0cDovL3d3dy54ZW4ub3JnL10pCiBBQ19DT05GSUdfU1JDRElS
KFsuL3hlbi9jb21tb24va2VybmVsLmNdKQogQUNfQ09ORklHX0ZJTEVTKFsuL2NvbmZpZy9Ub3Bs
ZXZlbC5ta10pCi1BQ19QUkVGSVhfREVGQVVMVChbL3Vzcl0pCiAKIG00X2luY2x1ZGUoW200L2Zl
YXR1cmVzLm00XSkKIG00X2luY2x1ZGUoW200L3N1YnN5c3RlbS5tNF0pCmRpZmYgLS1naXQgYS9k
b2NzL2NvbmZpZ3VyZSBiL2RvY3MvY29uZmlndXJlCmluZGV4IGJlNDkzNGQuLmQ2MjNkMTkgMTAw
NzU1Ci0tLSBhL2RvY3MvY29uZmlndXJlCisrKyBiL2RvY3MvY29uZmlndXJlCkBAIC01NTcsNyAr
NTU3LDYgQEAgUEFDS0FHRV9CVUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW4ub3JnJwogUEFD
S0FHRV9VUkw9J2h0dHA6Ly93d3cueGVuLm9yZy8nCiAKIGFjX3VuaXF1ZV9maWxlPSJtaXNjL3hl
bi1jb21tYW5kLWxpbmUubWFya2Rvd24iCi1hY19kZWZhdWx0X3ByZWZpeD0vdXNyCiBhY19zdWJz
dF92YXJzPSdMVExJQk9CSlMKIExJQk9CSlMKIE1BUktET1dOCkBAIC0xNjY0LDcgKzE2NjMsNiBA
QCBhY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CiAKIGFjX2NvbmZpZ19maWxl
cz0iJGFjX2NvbmZpZ19maWxlcyAuLi9jb25maWcvRG9jcy5tayIKIAotCiBhY19hdXhfZGlyPQog
Zm9yIGFjX2RpciBpbiAuLi8gIiRzcmNkaXIiLy4uLzsgZG8KICAgaWYgdGVzdCAtZiAiJGFjX2Rp
ci9pbnN0YWxsLXNoIjsgdGhlbgpkaWZmIC0tZ2l0IGEvZG9jcy9jb25maWd1cmUuYWMgYi9kb2Nz
L2NvbmZpZ3VyZS5hYwppbmRleCA1YzNmNWU4Li5lYTA1NTJlIDEwMDY0NAotLS0gYS9kb2NzL2Nv
bmZpZ3VyZS5hYworKysgYi9kb2NzL2NvbmZpZ3VyZS5hYwpAQCAtNiw3ICs2LDYgQEAgQUNfSU5J
VChbWGVuIEh5cGVydmlzb3IgRG9jdW1lbnRhdGlvbl0sIG00X2VzeXNjbWQoWy4uL3ZlcnNpb24u
c2ggLi4veGVuL01ha2VmaWwKICAgICBbeGVuLWRldmVsQGxpc3RzLnhlbi5vcmddLCBbeGVuXSwg
W2h0dHA6Ly93d3cueGVuLm9yZy9dKQogQUNfQ09ORklHX1NSQ0RJUihbbWlzYy94ZW4tY29tbWFu
ZC1saW5lLm1hcmtkb3duXSkKIEFDX0NPTkZJR19GSUxFUyhbLi4vY29uZmlnL0RvY3MubWtdKQot
QUNfUFJFRklYX0RFRkFVTFQoWy91c3JdKQogQUNfQ09ORklHX0FVWF9ESVIoWy4uL10pCiAKICMg
TTQgTWFjcm8gaW5jbHVkZXMKZGlmZiAtLWdpdCBhL3N0dWJkb20vY29uZmlndXJlIGIvc3R1YmRv
bS9jb25maWd1cmUKaW5kZXggYWI5MjE5YS4uNTFjYTY3NiAxMDA3NTUKLS0tIGEvc3R1YmRvbS9j
b25maWd1cmUKKysrIGIvc3R1YmRvbS9jb25maWd1cmUKQEAgLTU1Nyw3ICs1NTcsNiBAQCBQQUNL
QUdFX0JVR1JFUE9SVD0neGVuLWRldmVsQGxpc3RzLnhlbi5vcmcnCiBQQUNLQUdFX1VSTD0naHR0
cDovL3d3dy54ZW4ub3JnLycKIAogYWNfdW5pcXVlX2ZpbGU9Ii4uL2V4dHJhcy9taW5pLW9zL2tl
cm5lbC5jIgotYWNfZGVmYXVsdF9wcmVmaXg9L3VzcgogYWNfc3Vic3RfdmFycz0nTFRMSUJPQkpT
CiBMSUJPQkpTCiBTVFVCRE9NX0lOU1RBTEwKQEAgLTE3OTIsNyArMTc5MSw2IEBAIGFjX2NvbXBp
bGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKIAogYWNfY29uZmlnX2ZpbGVzPSIkYWNfY29u
ZmlnX2ZpbGVzIC4uL2NvbmZpZy9TdHViZG9tLm1rIgogCi0KIGFjX2F1eF9kaXI9CiBmb3IgYWNf
ZGlyIGluIC4uLyAiJHNyY2RpciIvLi4vOyBkbwogICBpZiB0ZXN0IC1mICIkYWNfZGlyL2luc3Rh
bGwtc2giOyB0aGVuCmRpZmYgLS1naXQgYS9zdHViZG9tL2NvbmZpZ3VyZS5hYyBiL3N0dWJkb20v
Y29uZmlndXJlLmFjCmluZGV4IDJiN2IyNzUuLmRlMjlmYjUgMTAwNjQ0Ci0tLSBhL3N0dWJkb20v
Y29uZmlndXJlLmFjCisrKyBiL3N0dWJkb20vY29uZmlndXJlLmFjCkBAIC02LDcgKzYsNiBAQCBB
Q19JTklUKFtYZW4gSHlwZXJ2aXNvciBTdHViIERvbWFpbnNdLCBtNF9lc3lzY21kKFsuLi92ZXJz
aW9uLnNoIC4uL3hlbi9NYWtlZmlsZQogICAgIFt4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZ10sIFt4
ZW5dLCBbaHR0cDovL3d3dy54ZW4ub3JnL10pCiBBQ19DT05GSUdfU1JDRElSKFsuLi9leHRyYXMv
bWluaS1vcy9rZXJuZWwuY10pCiBBQ19DT05GSUdfRklMRVMoWy4uL2NvbmZpZy9TdHViZG9tLm1r
XSkKLUFDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkKIEFDX0NPTkZJR19BVVhfRElSKFsuLi9dKQog
CiAjIE00IE1hY3JvIGluY2x1ZGVzCmRpZmYgLS1naXQgYS90b29scy9jb25maWd1cmUgYi90b29s
cy9jb25maWd1cmUKaW5kZXggNjZkNTg4YS4uOTIxOGZkZiAxMDA3NTUKLS0tIGEvdG9vbHMvY29u
ZmlndXJlCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZQpAQCAtNTU4LDcgKzU1OCw2IEBAIFBBQ0tBR0Vf
QlVHUkVQT1JUPSd4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZycKIFBBQ0tBR0VfVVJMPSdodHRwOi8v
d3d3Lnhlbi5vcmcvJwogCiBhY191bmlxdWVfZmlsZT0ibGlieGwvbGlieGwuYyIKLWFjX2RlZmF1
bHRfcHJlZml4PS91c3IKICMgRmFjdG9yaW5nIGRlZmF1bHQgaGVhZGVycyBmb3IgbW9zdCB0ZXN0
cy4KIGFjX2luY2x1ZGVzX2RlZmF1bHQ9IlwKICNpbmNsdWRlIDxzdGRpby5oPgpAQCAtMjE0Niw3
ICsyMTQ1LDYgQEAgYWNfY29uZmlnX2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIC4uL2NvbmZpZy9U
b29scy5tayIKIAogYWNfY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVhZGVycyBjb25maWcu
aCIKIAotCiBhY19hdXhfZGlyPQogZm9yIGFjX2RpciBpbiAuLi8gIiRzcmNkaXIiLy4uLzsgZG8K
ICAgaWYgdGVzdCAtZiAiJGFjX2Rpci9pbnN0YWxsLXNoIjsgdGhlbgpkaWZmIC0tZ2l0IGEvdG9v
bHMvY29uZmlndXJlLmFjIGIvdG9vbHMvY29uZmlndXJlLmFjCmluZGV4IGRlNWQwODUuLjZjNzEy
YTEgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYworKysgYi90b29scy9jb25maWd1cmUu
YWMKQEAgLTcsNyArNyw2IEBAIEFDX0lOSVQoW1hlbiBIeXBlcnZpc29yIFRvb2xzXSwgbTRfZXN5
c2NtZChbLi4vdmVyc2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVdKSwKIEFDX0NPTkZJR19TUkNESVIo
W2xpYnhsL2xpYnhsLmNdKQogQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMubWtdKQog
QUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKLUFDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkK
IEFDX0NPTkZJR19BVVhfRElSKFsuLi9dKQogCiAjIENoZWNrIGlmIENGTEFHUywgTERGTEFHUywg
TElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCi0tIAoxLjcu
Mi41CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:20: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 1U2lFb-00054A-GZ; Tue, 05 Feb 2013 16:20:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U2lFa-00053J-5g
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:20:02 +0000
Received: from [85.158.143.35:31762] by server-1.bemta-4.messagelabs.com id
	E6/EA-08839-D2131115; Tue, 05 Feb 2013 16:19:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360081194!13095814!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32163 invoked from network); 5 Feb 2013 16:19:56 -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;
	5 Feb 2013 16:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6338361"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 16:19:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 11:19:53 -0500
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 1U2lFR-0005jO-Qy;
	Tue, 05 Feb 2013 16:19:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 5 Feb 2013 16:19:53 +0000
Message-ID: <1360081193-17948-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
References: <1360081162.23001.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Matt Wilson <msw@amazon.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] tools+stubdom: install under /usr/local 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tm93IHRoYXQgdGhlIGhvdHBsdWcgc2NyaXB0cyBoYXZlIGJlZW4gZml4ZWQgdG8gcmVtb3ZlIGhh
cmRjb2RlZCBwYXRocyBsZXRzCnRyeSB0aGlzIGFnYWluLiBGcm9tIDI2NDcwOmFjYWYyOTIwM2Nm
OToKCglUaGlzIGlzIHRoZSBkZWZhY3RvIChvciBGSFMgbWFuZGF0ZWQ/KSBzdGFuZGFyZCBsb2Nh
dGlvbiBmb3Igc29mdHdhcmUKCWJ1aWx0IGZyb20gc291cmNlLCBpbiBvcmRlciB0byBhdm9pZCBj
bGFzaGluZyB3aXRoIHBhY2thZ2VkIHNvZnR3YXJlCgl3aGljaCBpcyBpbnN0YWxsZWQgdW5kZXIg
L3Vzci9iaW4gZXRjLgoKCUkgdGhpbmsgdGhlcmUgaXMgYmVuZWZpdCBpbiBoYXZpbmcgWGVuJ3Mg
aW5zdGFsbCBiZWhhdmUgbW9yZSBsaWtlIHRoZQoJbWFqb3JpdHkgb2Ygb3RoZXIgT1NTIHNvZnR3
YXJlIG91dCB0aGVyZS4KCglUaGUgbWFqb3IgZG93bnNpZGUgaGVyZSBpcyBpbiB0aGUgdHJhbnNp
dGlvbiBmcm9tIDQuMiB0byA0LjMgd2hlcmUKCXBlb3BsZSB3aG8gaGF2ZSBidWlsdCBmcm9tIHNv
dXJjZSB3aWxsIGlubmV2aXRhYmx5IGRpc2NvdmVyIGJyZWFrYWdlCgliZWNhdXNlIDQuMyBubyBs
b25nZXIgb3ZlcndyaXRlcyBzdHVmZiBpbiAvdXNyIGxpa2UgaXQgdXNlZCB0byBzbyB0aGV5Cglw
aWNrdXAgb2xkIHN0YWxlIGJpdHMgZnJvbSAvdXNyIGluc3RlYWQgb2YgbmV3IHN0dWZmIGZyb20g
L3Vzci9sb2NhbC4KCglQYWNrYWdlcyB3aWxsIHVzZSAuL2NvbmZpZ3VyZSAtLXByZWZpeD0vdXNy
IG9yIHdoYXRldmVyIGhlbHBlciBtYWNybwoJdGhlaXIgcGFja2FnZSBtYW5hZ2VyIGdpdmVzIHRo
ZW0uIEkgaGF2ZSBjb25maXJtZWQgdGhhdCBkb2luZyB0aGlzCglyZXN1bHRzIGluIHRoZSBzYW1l
IGxpc3Qgb2YgaW5zdGFsbGVkIGZpbGVzIGFzIGJlZm9yZSB0aGlzIHBhdGNoIHdhcwoJYXBwbGll
ZC4KCglUaGUgaHlwZXJ2aXNvciByZW1haW5zIGluIC9ib290LyBhbmQgdGhlcmUgaXMgbm8gaW50
ZW50aW9uIHRvIG1vdmUgaXQuCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1w
YmVsbEBjaXRyaXguY29tPgpDYzogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+CkNjOiBNYXR0IFdpbHNvbiA8bXN3QGFtYXpvbi5jb20+Ci0tLQogY29uZmlndXJlICAgICAg
ICAgICAgfCAgICAyIC0tCiBjb25maWd1cmUuYWMgICAgICAgICB8ICAgIDEgLQogZG9jcy9jb25m
aWd1cmUgICAgICAgfCAgICAyIC0tCiBkb2NzL2NvbmZpZ3VyZS5hYyAgICB8ICAgIDEgLQogc3R1
YmRvbS9jb25maWd1cmUgICAgfCAgICAyIC0tCiBzdHViZG9tL2NvbmZpZ3VyZS5hYyB8ICAgIDEg
LQogdG9vbHMvY29uZmlndXJlICAgICAgfCAgICAyIC0tCiB0b29scy9jb25maWd1cmUuYWMgICB8
ICAgIDEgLQogOCBmaWxlcyBjaGFuZ2VkLCAwIGluc2VydGlvbnMoKyksIDEyIGRlbGV0aW9ucygt
KQoKZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZSBiL2NvbmZpZ3VyZQppbmRleCBjMmVjODdkLi5jYmMz
OGJhIDEwMDc1NQotLS0gYS9jb25maWd1cmUKKysrIGIvY29uZmlndXJlCkBAIC01NTcsNyArNTU3
LDYgQEAgUEFDS0FHRV9CVUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW4ub3JnJwogUEFDS0FH
RV9VUkw9J2h0dHA6Ly93d3cueGVuLm9yZy8nCiAKIGFjX3VuaXF1ZV9maWxlPSIuL3hlbi9jb21t
b24va2VybmVsLmMiCi1hY19kZWZhdWx0X3ByZWZpeD0vdXNyCiBlbmFibGVfb3B0aW9uX2NoZWNr
aW5nPW5vCiBhY19zdWJzdF92YXJzPSdMVExJQk9CSlMKIExJQk9CSlMKQEAgLTE2ODYsNyArMTY4
NSw2IEBAIGFjX2NvbmZpZ19maWxlcz0iJGFjX2NvbmZpZ19maWxlcyAuL2NvbmZpZy9Ub3BsZXZl
bC5tayIKIAogCiAKLQogYWNfYXV4X2Rpcj0KIGZvciBhY19kaXIgaW4gIiRzcmNkaXIiICIkc3Jj
ZGlyLy4uIiAiJHNyY2Rpci8uLi8uLiI7IGRvCiAgIGlmIHRlc3QgLWYgIiRhY19kaXIvaW5zdGFs
bC1zaCI7IHRoZW4KZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZS5hYyBiL2NvbmZpZ3VyZS5hYwppbmRl
eCBkZjFkNWRhLi5iMTdlNjcxIDEwMDY0NAotLS0gYS9jb25maWd1cmUuYWMKKysrIGIvY29uZmln
dXJlLmFjCkBAIC02LDcgKzYsNiBAQCBBQ19JTklUKFtYZW4gSHlwZXJ2aXNvcl0sIG00X2VzeXNj
bWQoWy4vdmVyc2lvbi5zaCAuL3hlbi9NYWtlZmlsZV0pLAogICAgIFt4ZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZ10sIFt4ZW5dLCBbaHR0cDovL3d3dy54ZW4ub3JnL10pCiBBQ19DT05GSUdfU1JDRElS
KFsuL3hlbi9jb21tb24va2VybmVsLmNdKQogQUNfQ09ORklHX0ZJTEVTKFsuL2NvbmZpZy9Ub3Bs
ZXZlbC5ta10pCi1BQ19QUkVGSVhfREVGQVVMVChbL3Vzcl0pCiAKIG00X2luY2x1ZGUoW200L2Zl
YXR1cmVzLm00XSkKIG00X2luY2x1ZGUoW200L3N1YnN5c3RlbS5tNF0pCmRpZmYgLS1naXQgYS9k
b2NzL2NvbmZpZ3VyZSBiL2RvY3MvY29uZmlndXJlCmluZGV4IGJlNDkzNGQuLmQ2MjNkMTkgMTAw
NzU1Ci0tLSBhL2RvY3MvY29uZmlndXJlCisrKyBiL2RvY3MvY29uZmlndXJlCkBAIC01NTcsNyAr
NTU3LDYgQEAgUEFDS0FHRV9CVUdSRVBPUlQ9J3hlbi1kZXZlbEBsaXN0cy54ZW4ub3JnJwogUEFD
S0FHRV9VUkw9J2h0dHA6Ly93d3cueGVuLm9yZy8nCiAKIGFjX3VuaXF1ZV9maWxlPSJtaXNjL3hl
bi1jb21tYW5kLWxpbmUubWFya2Rvd24iCi1hY19kZWZhdWx0X3ByZWZpeD0vdXNyCiBhY19zdWJz
dF92YXJzPSdMVExJQk9CSlMKIExJQk9CSlMKIE1BUktET1dOCkBAIC0xNjY0LDcgKzE2NjMsNiBA
QCBhY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CiAKIGFjX2NvbmZpZ19maWxl
cz0iJGFjX2NvbmZpZ19maWxlcyAuLi9jb25maWcvRG9jcy5tayIKIAotCiBhY19hdXhfZGlyPQog
Zm9yIGFjX2RpciBpbiAuLi8gIiRzcmNkaXIiLy4uLzsgZG8KICAgaWYgdGVzdCAtZiAiJGFjX2Rp
ci9pbnN0YWxsLXNoIjsgdGhlbgpkaWZmIC0tZ2l0IGEvZG9jcy9jb25maWd1cmUuYWMgYi9kb2Nz
L2NvbmZpZ3VyZS5hYwppbmRleCA1YzNmNWU4Li5lYTA1NTJlIDEwMDY0NAotLS0gYS9kb2NzL2Nv
bmZpZ3VyZS5hYworKysgYi9kb2NzL2NvbmZpZ3VyZS5hYwpAQCAtNiw3ICs2LDYgQEAgQUNfSU5J
VChbWGVuIEh5cGVydmlzb3IgRG9jdW1lbnRhdGlvbl0sIG00X2VzeXNjbWQoWy4uL3ZlcnNpb24u
c2ggLi4veGVuL01ha2VmaWwKICAgICBbeGVuLWRldmVsQGxpc3RzLnhlbi5vcmddLCBbeGVuXSwg
W2h0dHA6Ly93d3cueGVuLm9yZy9dKQogQUNfQ09ORklHX1NSQ0RJUihbbWlzYy94ZW4tY29tbWFu
ZC1saW5lLm1hcmtkb3duXSkKIEFDX0NPTkZJR19GSUxFUyhbLi4vY29uZmlnL0RvY3MubWtdKQot
QUNfUFJFRklYX0RFRkFVTFQoWy91c3JdKQogQUNfQ09ORklHX0FVWF9ESVIoWy4uL10pCiAKICMg
TTQgTWFjcm8gaW5jbHVkZXMKZGlmZiAtLWdpdCBhL3N0dWJkb20vY29uZmlndXJlIGIvc3R1YmRv
bS9jb25maWd1cmUKaW5kZXggYWI5MjE5YS4uNTFjYTY3NiAxMDA3NTUKLS0tIGEvc3R1YmRvbS9j
b25maWd1cmUKKysrIGIvc3R1YmRvbS9jb25maWd1cmUKQEAgLTU1Nyw3ICs1NTcsNiBAQCBQQUNL
QUdFX0JVR1JFUE9SVD0neGVuLWRldmVsQGxpc3RzLnhlbi5vcmcnCiBQQUNLQUdFX1VSTD0naHR0
cDovL3d3dy54ZW4ub3JnLycKIAogYWNfdW5pcXVlX2ZpbGU9Ii4uL2V4dHJhcy9taW5pLW9zL2tl
cm5lbC5jIgotYWNfZGVmYXVsdF9wcmVmaXg9L3VzcgogYWNfc3Vic3RfdmFycz0nTFRMSUJPQkpT
CiBMSUJPQkpTCiBTVFVCRE9NX0lOU1RBTEwKQEAgLTE3OTIsNyArMTc5MSw2IEBAIGFjX2NvbXBp
bGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKIAogYWNfY29uZmlnX2ZpbGVzPSIkYWNfY29u
ZmlnX2ZpbGVzIC4uL2NvbmZpZy9TdHViZG9tLm1rIgogCi0KIGFjX2F1eF9kaXI9CiBmb3IgYWNf
ZGlyIGluIC4uLyAiJHNyY2RpciIvLi4vOyBkbwogICBpZiB0ZXN0IC1mICIkYWNfZGlyL2luc3Rh
bGwtc2giOyB0aGVuCmRpZmYgLS1naXQgYS9zdHViZG9tL2NvbmZpZ3VyZS5hYyBiL3N0dWJkb20v
Y29uZmlndXJlLmFjCmluZGV4IDJiN2IyNzUuLmRlMjlmYjUgMTAwNjQ0Ci0tLSBhL3N0dWJkb20v
Y29uZmlndXJlLmFjCisrKyBiL3N0dWJkb20vY29uZmlndXJlLmFjCkBAIC02LDcgKzYsNiBAQCBB
Q19JTklUKFtYZW4gSHlwZXJ2aXNvciBTdHViIERvbWFpbnNdLCBtNF9lc3lzY21kKFsuLi92ZXJz
aW9uLnNoIC4uL3hlbi9NYWtlZmlsZQogICAgIFt4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZ10sIFt4
ZW5dLCBbaHR0cDovL3d3dy54ZW4ub3JnL10pCiBBQ19DT05GSUdfU1JDRElSKFsuLi9leHRyYXMv
bWluaS1vcy9rZXJuZWwuY10pCiBBQ19DT05GSUdfRklMRVMoWy4uL2NvbmZpZy9TdHViZG9tLm1r
XSkKLUFDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkKIEFDX0NPTkZJR19BVVhfRElSKFsuLi9dKQog
CiAjIE00IE1hY3JvIGluY2x1ZGVzCmRpZmYgLS1naXQgYS90b29scy9jb25maWd1cmUgYi90b29s
cy9jb25maWd1cmUKaW5kZXggNjZkNTg4YS4uOTIxOGZkZiAxMDA3NTUKLS0tIGEvdG9vbHMvY29u
ZmlndXJlCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZQpAQCAtNTU4LDcgKzU1OCw2IEBAIFBBQ0tBR0Vf
QlVHUkVQT1JUPSd4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZycKIFBBQ0tBR0VfVVJMPSdodHRwOi8v
d3d3Lnhlbi5vcmcvJwogCiBhY191bmlxdWVfZmlsZT0ibGlieGwvbGlieGwuYyIKLWFjX2RlZmF1
bHRfcHJlZml4PS91c3IKICMgRmFjdG9yaW5nIGRlZmF1bHQgaGVhZGVycyBmb3IgbW9zdCB0ZXN0
cy4KIGFjX2luY2x1ZGVzX2RlZmF1bHQ9IlwKICNpbmNsdWRlIDxzdGRpby5oPgpAQCAtMjE0Niw3
ICsyMTQ1LDYgQEAgYWNfY29uZmlnX2ZpbGVzPSIkYWNfY29uZmlnX2ZpbGVzIC4uL2NvbmZpZy9U
b29scy5tayIKIAogYWNfY29uZmlnX2hlYWRlcnM9IiRhY19jb25maWdfaGVhZGVycyBjb25maWcu
aCIKIAotCiBhY19hdXhfZGlyPQogZm9yIGFjX2RpciBpbiAuLi8gIiRzcmNkaXIiLy4uLzsgZG8K
ICAgaWYgdGVzdCAtZiAiJGFjX2Rpci9pbnN0YWxsLXNoIjsgdGhlbgpkaWZmIC0tZ2l0IGEvdG9v
bHMvY29uZmlndXJlLmFjIGIvdG9vbHMvY29uZmlndXJlLmFjCmluZGV4IGRlNWQwODUuLjZjNzEy
YTEgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2NvbmZpZ3VyZS5hYworKysgYi90b29scy9jb25maWd1cmUu
YWMKQEAgLTcsNyArNyw2IEBAIEFDX0lOSVQoW1hlbiBIeXBlcnZpc29yIFRvb2xzXSwgbTRfZXN5
c2NtZChbLi4vdmVyc2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVdKSwKIEFDX0NPTkZJR19TUkNESVIo
W2xpYnhsL2xpYnhsLmNdKQogQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMubWtdKQog
QUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKLUFDX1BSRUZJWF9ERUZBVUxUKFsvdXNyXSkK
IEFDX0NPTkZJR19BVVhfRElSKFsuLi9dKQogCiAjIENoZWNrIGlmIENGTEFHUywgTERGTEFHUywg
TElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCi0tIAoxLjcu
Mi41CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:21:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:21: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 1U2lH0-0005Kl-2n; Tue, 05 Feb 2013 16:21: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 1U2lGy-0005KT-Ag
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 16:21:28 +0000
Received: from [85.158.138.51:27384] by server-10.bemta-3.messagelabs.com id
	9C/60-10609-78131115; Tue, 05 Feb 2013 16:21:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360081286!20861651!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19680 invoked from network); 5 Feb 2013 16:21:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1164221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:21: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.297.1; Tue, 5 Feb 2013
	16:21:25 +0000
Message-ID: <1360081284.23001.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Tue, 5 Feb 2013 16:21:24 +0000
In-Reply-To: <5111301B.8080304@heliman.it>
References: <5111301B.8080304@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] tools/libxl: Disable useless empty floppy
 drive with 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

On Tue, 2013-02-05 at 16:15 +0000, Fabio Fantoni wrote:
> tools/libxl: Disable useless empty floppy drive with
>   qemu-xen

We used to get occasional requests to enable the floppy disk image to be
selected, but perhaps that need has passed (was something to do with
Windows sysprep IIRC).

Unfortunately the patch is whitespace damaged. 'git send-email' is your
friend...

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   tools/libxl/libxl_dm.c |    3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..c265618 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -406,6 +406,9 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>       if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           int ioemu_nics = 0;
> 
> +        /* Disable useless empty floppy drive */
> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
> +
>           if (b_info->u.hvm.serial) {
>               flexarray_vappend(dm_args, "-serial", 
> b_info->u.hvm.serial, NULL);
>           }



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:21:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:21: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 1U2lH0-0005Kl-2n; Tue, 05 Feb 2013 16:21: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 1U2lGy-0005KT-Ag
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 16:21:28 +0000
Received: from [85.158.138.51:27384] by server-10.bemta-3.messagelabs.com id
	9C/60-10609-78131115; Tue, 05 Feb 2013 16:21:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360081286!20861651!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19680 invoked from network); 5 Feb 2013 16:21:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1164221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 16:21: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.297.1; Tue, 5 Feb 2013
	16:21:25 +0000
Message-ID: <1360081284.23001.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Tue, 5 Feb 2013 16:21:24 +0000
In-Reply-To: <5111301B.8080304@heliman.it>
References: <5111301B.8080304@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] tools/libxl: Disable useless empty floppy
 drive with 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

On Tue, 2013-02-05 at 16:15 +0000, Fabio Fantoni wrote:
> tools/libxl: Disable useless empty floppy drive with
>   qemu-xen

We used to get occasional requests to enable the floppy disk image to be
selected, but perhaps that need has passed (was something to do with
Windows sysprep IIRC).

Unfortunately the patch is whitespace damaged. 'git send-email' is your
friend...

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   tools/libxl/libxl_dm.c |    3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..c265618 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -406,6 +406,9 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>       if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           int ioemu_nics = 0;
> 
> +        /* Disable useless empty floppy drive */
> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
> +
>           if (b_info->u.hvm.serial) {
>               flexarray_vappend(dm_args, "-serial", 
> b_info->u.hvm.serial, NULL);
>           }



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2lPn-0005nF-B5; Tue, 05 Feb 2013 16:30:35 +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 1U2lPl-0005n7-9I
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:30:33 +0000
Received: from [85.158.138.51:9336] by server-15.bemta-3.messagelabs.com id
	6A/C6-25405-8A331115; Tue, 05 Feb 2013 16:30:32 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360081822!28936523!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzA2NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31995 invoked from network); 5 Feb 2013 16:30:23 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 16:30:23 -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 232FE16B7;
	Tue,  5 Feb 2013 18:30:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id ABD902006D; Tue,  5 Feb 2013 18:30:21 +0200 (EET)
Date: Tue, 5 Feb 2013 18:30:21 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130205163021.GR8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XEN 4.1 error Critical Interrupt - Front panel NMI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, 2013 at 04:49:47PM +0100, agya naila wrote:
>    Hello Everyone,
>    I am quite new on XEN. I tried to installed XEN on my server and I know
>    this server series IBM Xeon 3,4 Ghz didn't have Intel VTx support so I am
>    pllaning to use paravirtualization.
>    I configure the server with Ubuntu Desktop  12.0464 bit as dom0 with XEN
>    4.1 64 hypervisor. The configuration using repositories exactly by this
>    tutorial [1]https://help.ubuntu.com/community/XenProposed :
>

- What exact Xen version are you using? 
- What exact Linux dom0 kernel are you using? 
- Please paste your grub settings for the Xen entry.
- Did you capture the error/crash logs from the Serial console? (SOL provided by the blade management).


-- Pasi

 
>                                  Installing Xen
> 
>    Install a 64-bit hypervisor
> 
>  sudo apt-get install xen-hypervisor-amd64
> 
>    Modify GRUB to default to booting Xen:
> 
>  sudo sed -i 's/GRUB_DEFAULT=.*\+/GRUB_DEFAULT="Xen 4.1-amd64"/' /etc/default/grub
>  sudo update-grub
> 
>    Set the default toolstack to xm (aka xend):
> 
>  sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xm"/' /etc/default/xen
> 
>    Now reboot:
> 
>  sudo reboot
> 
>    But when rebooting the Dom0 failed to start, enclosed was the error
>    message when Xen booting and after that Dom0 will restarting over and
>    over.
>    On Blade server system  log I got error message :
>    (Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=
>    0020
>    (Bestak_septaher) Critical Interrupt - Front panel NMI
>    Please Suggest, thank you very much for any one help.
>    Best Regards,
>    Agya
> 
> References
> 
>    Visible links
>    1. https://help.ubuntu.com/community/XenProposed


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 05 16:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2lPn-0005nF-B5; Tue, 05 Feb 2013 16:30:35 +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 1U2lPl-0005n7-9I
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:30:33 +0000
Received: from [85.158.138.51:9336] by server-15.bemta-3.messagelabs.com id
	6A/C6-25405-8A331115; Tue, 05 Feb 2013 16:30:32 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360081822!28936523!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzA2NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31995 invoked from network); 5 Feb 2013 16:30:23 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 16:30:23 -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 232FE16B7;
	Tue,  5 Feb 2013 18:30:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id ABD902006D; Tue,  5 Feb 2013 18:30:21 +0200 (EET)
Date: Tue, 5 Feb 2013 18:30:21 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130205163021.GR8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XEN 4.1 error Critical Interrupt - Front panel NMI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, 2013 at 04:49:47PM +0100, agya naila wrote:
>    Hello Everyone,
>    I am quite new on XEN. I tried to installed XEN on my server and I know
>    this server series IBM Xeon 3,4 Ghz didn't have Intel VTx support so I am
>    pllaning to use paravirtualization.
>    I configure the server with Ubuntu Desktop  12.0464 bit as dom0 with XEN
>    4.1 64 hypervisor. The configuration using repositories exactly by this
>    tutorial [1]https://help.ubuntu.com/community/XenProposed :
>

- What exact Xen version are you using? 
- What exact Linux dom0 kernel are you using? 
- Please paste your grub settings for the Xen entry.
- Did you capture the error/crash logs from the Serial console? (SOL provided by the blade management).


-- Pasi

 
>                                  Installing Xen
> 
>    Install a 64-bit hypervisor
> 
>  sudo apt-get install xen-hypervisor-amd64
> 
>    Modify GRUB to default to booting Xen:
> 
>  sudo sed -i 's/GRUB_DEFAULT=.*\+/GRUB_DEFAULT="Xen 4.1-amd64"/' /etc/default/grub
>  sudo update-grub
> 
>    Set the default toolstack to xm (aka xend):
> 
>  sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xm"/' /etc/default/xen
> 
>    Now reboot:
> 
>  sudo reboot
> 
>    But when rebooting the Dom0 failed to start, enclosed was the error
>    message when Xen booting and after that Dom0 will restarting over and
>    over.
>    On Blade server system  log I got error message :
>    (Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=
>    0020
>    (Bestak_septaher) Critical Interrupt - Front panel NMI
>    Please Suggest, thank you very much for any one help.
>    Best Regards,
>    Agya
> 
> References
> 
>    Visible links
>    1. https://help.ubuntu.com/community/XenProposed


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 05 16:36:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:36: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 1U2lVV-00068X-HO; Tue, 05 Feb 2013 16:36:29 +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 1U2lVU-00068S-Gu
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:36:28 +0000
Received: from [85.158.143.99:38690] by server-2.bemta-4.messagelabs.com id
	40/D9-01597-B0531115; Tue, 05 Feb 2013 16:36:27 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360082180!22239123!1
X-Originating-IP: [209.85.128.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1056 invoked from network); 5 Feb 2013 16:36:22 -0000
Received: from mail-qe0-f48.google.com (HELO mail-qe0-f48.google.com)
	(209.85.128.48)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:36:22 -0000
Received: by mail-qe0-f48.google.com with SMTP id 3so172740qea.35
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 08:36:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=Gj1ggZZPZprSZXUm0bBLDNXOKogw5twXwtJvnBwZGis=;
	b=C6GGXiEet5rFtyP36sPd9JxFqp5NaxvzVoECKADH7478iM98O6oiLcw4z8wEAcNzvm
	D1J9Mw7fDH9/d+og9K+n1EFjHKl33bNBkGevjL4jL+YbdwknFOMz34T+TTuJ5XjEqykl
	QyLosyrshZB6bdfVmrJtwrWdG6xpprk8DKjA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=Gj1ggZZPZprSZXUm0bBLDNXOKogw5twXwtJvnBwZGis=;
	b=Dm4JvYSd3d9sBpmOEdVv4qCvmv1ogq5U36til1Ottv7T8yv7hxpUEt1DMdtMTSYDBP
	s98ghmefei1weCWGKpbBd8vsQ5ekc+OxNXXj7yOuV84Vz3yDAcexLXi2qK8xp3Nm7Opw
	Ai9mrMj4gCsVQXXTxlcW/mT7vASo75wbXoet1B4+7hpjnjh5rL1K/Ba3K9r8TqEqIGNo
	2wHMlaibIbkyLqzT31wtReVxi+QXdlnz/HicUHQiZGiU3Qaw1RaEmYwkVt0qTlFyd5iZ
	Tg6wmuHI6XdkFqSncbksrXO8oVaDqsgiysqDUq49PqZqxa2J7cEpHpjsgAkda+Z2Ss0z
	dqZA==
X-Received: by 10.49.127.240 with SMTP id nj16mr23513334qeb.13.1360082180469; 
	Tue, 05 Feb 2013 08:36:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Tue, 5 Feb 2013 08:36:05 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <05E85F0F99EB21013A48E1E6@nimrod.local>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<05E85F0F99EB21013A48E1E6@nimrod.local>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 5 Feb 2013 20:36:05 +0400
X-Google-Sender-Auth: gkr7NHp6RWIm8TCCCJGdc8SqAeU
Message-ID: <CACaajQskiwRkaY2eiXO-AP1tcvgAhsja4bKnrH2aWbP7pTP0RQ@mail.gmail.com>
To: Alex Bligh <alex@alex.org.uk>
X-Gm-Message-State: ALoCoQkqdEyqVWtJbttZXFZ5/OMEhOT4UQbV6gSqZF6z7hoCxPe5ARftoDoQgDlUlLKirbVfPaK5
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] blkback disk I/O limit 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

2013/2/5 Alex Bligh <alex@alex.org.uk>:
> Another approach (when using the qemu-upstream DM) would presumably
> be to use the block_io_throttle QMP command that QEMU provides.


Hmm. Does this play good with phy devices used by xen?

--
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 Tue Feb 05 16:36:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:36: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 1U2lVV-00068X-HO; Tue, 05 Feb 2013 16:36:29 +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 1U2lVU-00068S-Gu
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:36:28 +0000
Received: from [85.158.143.99:38690] by server-2.bemta-4.messagelabs.com id
	40/D9-01597-B0531115; Tue, 05 Feb 2013 16:36:27 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360082180!22239123!1
X-Originating-IP: [209.85.128.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1056 invoked from network); 5 Feb 2013 16:36:22 -0000
Received: from mail-qe0-f48.google.com (HELO mail-qe0-f48.google.com)
	(209.85.128.48)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 16:36:22 -0000
Received: by mail-qe0-f48.google.com with SMTP id 3so172740qea.35
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 08:36:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=Gj1ggZZPZprSZXUm0bBLDNXOKogw5twXwtJvnBwZGis=;
	b=C6GGXiEet5rFtyP36sPd9JxFqp5NaxvzVoECKADH7478iM98O6oiLcw4z8wEAcNzvm
	D1J9Mw7fDH9/d+og9K+n1EFjHKl33bNBkGevjL4jL+YbdwknFOMz34T+TTuJ5XjEqykl
	QyLosyrshZB6bdfVmrJtwrWdG6xpprk8DKjA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=Gj1ggZZPZprSZXUm0bBLDNXOKogw5twXwtJvnBwZGis=;
	b=Dm4JvYSd3d9sBpmOEdVv4qCvmv1ogq5U36til1Ottv7T8yv7hxpUEt1DMdtMTSYDBP
	s98ghmefei1weCWGKpbBd8vsQ5ekc+OxNXXj7yOuV84Vz3yDAcexLXi2qK8xp3Nm7Opw
	Ai9mrMj4gCsVQXXTxlcW/mT7vASo75wbXoet1B4+7hpjnjh5rL1K/Ba3K9r8TqEqIGNo
	2wHMlaibIbkyLqzT31wtReVxi+QXdlnz/HicUHQiZGiU3Qaw1RaEmYwkVt0qTlFyd5iZ
	Tg6wmuHI6XdkFqSncbksrXO8oVaDqsgiysqDUq49PqZqxa2J7cEpHpjsgAkda+Z2Ss0z
	dqZA==
X-Received: by 10.49.127.240 with SMTP id nj16mr23513334qeb.13.1360082180469; 
	Tue, 05 Feb 2013 08:36:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Tue, 5 Feb 2013 08:36:05 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <05E85F0F99EB21013A48E1E6@nimrod.local>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<05E85F0F99EB21013A48E1E6@nimrod.local>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 5 Feb 2013 20:36:05 +0400
X-Google-Sender-Auth: gkr7NHp6RWIm8TCCCJGdc8SqAeU
Message-ID: <CACaajQskiwRkaY2eiXO-AP1tcvgAhsja4bKnrH2aWbP7pTP0RQ@mail.gmail.com>
To: Alex Bligh <alex@alex.org.uk>
X-Gm-Message-State: ALoCoQkqdEyqVWtJbttZXFZ5/OMEhOT4UQbV6gSqZF6z7hoCxPe5ARftoDoQgDlUlLKirbVfPaK5
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] blkback disk I/O limit 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

2013/2/5 Alex Bligh <alex@alex.org.uk>:
> Another approach (when using the qemu-upstream DM) would presumably
> be to use the block_io_throttle QMP command that QEMU provides.


Hmm. Does this play good with phy devices used by xen?

--
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 Tue Feb 05 16:56:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:56: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 1U2loS-0006uf-GI; Tue, 05 Feb 2013 16:56: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 1U2loR-0006ua-Oa
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:56:03 +0000
Received: from [85.158.143.35:42222] by server-3.bemta-4.messagelabs.com id
	0D/0F-08920-3A931115; Tue, 05 Feb 2013 16:56:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360083360!15296058!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20848 invoked from network); 5 Feb 2013 16:56:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 16:56:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15GtwXP005419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 16:55: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
	r15Gtvfr000012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 16:55:57 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
	r15Gtu4D023141; Tue, 5 Feb 2013 10:55:56 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 08:55:56 -0800
Date: Tue, 5 Feb 2013 11:55:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205165550.GC2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 31, 2013 at 02:47:04PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index d953e81..9038211 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -53,6 +53,9 @@
>  
>  /* Helper macro(s) */
>  #define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)

Can you provide a comment explaining why the '6' or '5' value?

> +/* event bitmap size: 1 page for 32 bit and 8 pages for 64 bit */
> +#define BITMAP_PG_ORDER (BITS_PER_LONG == 64 ? 3 : 1)
> +#define BITMAP_NR_PAGES (BITMAP_PG_ORDER == 3 ? 8 : 1)

Is there some math behind this? Could you provide a comment explaining
the reason for needing so much for a 64-bit vs only needing on page on
32-bit?

>  
>  /* N-level event channel, starting from 2 */
>  unsigned int evtchn_level = 2;
> @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
>  void xen_callback_vector(void) {}
>  #endif
>  
> +static int xen_event_channel_register_3level(void)
> +{
> +	evtchn_register_nlevel_t reg;

Please no typdefs.

> +	int i, cpu;
> +	unsigned long *_evtchn_pending = NULL;
> +	unsigned long *_evtchn_mask = NULL;
> +	unsigned long *l2sel_mfns = NULL;
> +	unsigned long *l2sel_offsets = NULL;
> +	int rc;
> +
> +	/* If we come from restore path, we don't need to allocate
> +	 * pages.
> +	 */
> +	if (!evtchn_pending && !evtchn_mask) {
> +		evtchn_pending =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		evtchn_mask =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		if (!evtchn_pending || !evtchn_mask) {
> +			free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +			free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> +			evtchn_pending = NULL;
> +			evtchn_mask = NULL;
> +			rc = -ENOMEM;
> +			goto err;
> +		}
> +	}
> +
> +	rc = -ENOMEM; /* Common error code for following operations */
> +#define __ALLOC_ARRAY(_ptr, _nr)					\
> +	do {								\
> +		(_ptr) = kzalloc(sizeof(unsigned long) * (_nr),		\
> +				 GFP_KERNEL);				\
> +		if (!(_ptr))						\
> +			goto out;					\
> +	} while (0)
> +
> +	__ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
> +	__ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
> +#undef __ALLOC_ARRAY
> +
> +	memset(&reg, 0, sizeof(reg));
> +
> +	for (i = 0; i < BITMAP_NR_PAGES; i++) {
> +		unsigned long offset = PAGE_SIZE * i;
> +		_evtchn_pending[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_pending+offset));
> +		_evtchn_mask[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_mask+offset));
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		l2sel_mfns[cpu] =
> +			arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
> +		l2sel_offsets[cpu] =
> +			offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
> +	}
> +
> +	reg.u.l3.nr_pages = BITMAP_NR_PAGES;
> +	reg.u.l3.evtchn_pending = _evtchn_pending;
> +	reg.u.l3.evtchn_mask = _evtchn_mask;
> +
> +	reg.u.l3.nr_vcpus = nr_cpu_ids;
> +	reg.u.l3.l2sel_mfns = l2sel_mfns;
> +	reg.u.l3.l2sel_offsets = l2sel_offsets;
> +
> +	reg.level = 3;
> +
> +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> +	if (rc) {
> +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> +		evtchn_pending = NULL;
> +		evtchn_mask = NULL;
> +	}
> +
> +out:
> +	kfree(_evtchn_pending);
> +	kfree(_evtchn_mask);
> +	kfree(l2sel_mfns);
> +	kfree(l2sel_offsets);

So it is OK to just free it even on success??
> +err:
> +	return rc;
> +}
> +
>  void __init xen_init_IRQ(void)
>  {
>  	int i, rc;
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:56:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16:56: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 1U2loS-0006uf-GI; Tue, 05 Feb 2013 16:56: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 1U2loR-0006ua-Oa
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:56:03 +0000
Received: from [85.158.143.35:42222] by server-3.bemta-4.messagelabs.com id
	0D/0F-08920-3A931115; Tue, 05 Feb 2013 16:56:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360083360!15296058!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20848 invoked from network); 5 Feb 2013 16:56:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 16:56:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15GtwXP005419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 16:55: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
	r15Gtvfr000012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 16:55:57 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
	r15Gtu4D023141; Tue, 5 Feb 2013 10:55:56 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 08:55:56 -0800
Date: Tue, 5 Feb 2013 11:55:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205165550.GC2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 31, 2013 at 02:47:04PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index d953e81..9038211 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -53,6 +53,9 @@
>  
>  /* Helper macro(s) */
>  #define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)

Can you provide a comment explaining why the '6' or '5' value?

> +/* event bitmap size: 1 page for 32 bit and 8 pages for 64 bit */
> +#define BITMAP_PG_ORDER (BITS_PER_LONG == 64 ? 3 : 1)
> +#define BITMAP_NR_PAGES (BITMAP_PG_ORDER == 3 ? 8 : 1)

Is there some math behind this? Could you provide a comment explaining
the reason for needing so much for a 64-bit vs only needing on page on
32-bit?

>  
>  /* N-level event channel, starting from 2 */
>  unsigned int evtchn_level = 2;
> @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
>  void xen_callback_vector(void) {}
>  #endif
>  
> +static int xen_event_channel_register_3level(void)
> +{
> +	evtchn_register_nlevel_t reg;

Please no typdefs.

> +	int i, cpu;
> +	unsigned long *_evtchn_pending = NULL;
> +	unsigned long *_evtchn_mask = NULL;
> +	unsigned long *l2sel_mfns = NULL;
> +	unsigned long *l2sel_offsets = NULL;
> +	int rc;
> +
> +	/* If we come from restore path, we don't need to allocate
> +	 * pages.
> +	 */
> +	if (!evtchn_pending && !evtchn_mask) {
> +		evtchn_pending =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		evtchn_mask =
> +			(unsigned long *)__get_free_pages(GFP_KERNEL,
> +							  BITMAP_PG_ORDER);
> +		if (!evtchn_pending || !evtchn_mask) {
> +			free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +			free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> +			evtchn_pending = NULL;
> +			evtchn_mask = NULL;
> +			rc = -ENOMEM;
> +			goto err;
> +		}
> +	}
> +
> +	rc = -ENOMEM; /* Common error code for following operations */
> +#define __ALLOC_ARRAY(_ptr, _nr)					\
> +	do {								\
> +		(_ptr) = kzalloc(sizeof(unsigned long) * (_nr),		\
> +				 GFP_KERNEL);				\
> +		if (!(_ptr))						\
> +			goto out;					\
> +	} while (0)
> +
> +	__ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
> +	__ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
> +	__ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
> +#undef __ALLOC_ARRAY
> +
> +	memset(&reg, 0, sizeof(reg));
> +
> +	for (i = 0; i < BITMAP_NR_PAGES; i++) {
> +		unsigned long offset = PAGE_SIZE * i;
> +		_evtchn_pending[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_pending+offset));
> +		_evtchn_mask[i] =
> +			arbitrary_virt_to_mfn(
> +				(void *)((unsigned long)evtchn_mask+offset));
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		l2sel_mfns[cpu] =
> +			arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
> +		l2sel_offsets[cpu] =
> +			offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
> +	}
> +
> +	reg.u.l3.nr_pages = BITMAP_NR_PAGES;
> +	reg.u.l3.evtchn_pending = _evtchn_pending;
> +	reg.u.l3.evtchn_mask = _evtchn_mask;
> +
> +	reg.u.l3.nr_vcpus = nr_cpu_ids;
> +	reg.u.l3.l2sel_mfns = l2sel_mfns;
> +	reg.u.l3.l2sel_offsets = l2sel_offsets;
> +
> +	reg.level = 3;
> +
> +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> +	if (rc) {
> +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> +		evtchn_pending = NULL;
> +		evtchn_mask = NULL;
> +	}
> +
> +out:
> +	kfree(_evtchn_pending);
> +	kfree(_evtchn_mask);
> +	kfree(l2sel_mfns);
> +	kfree(l2sel_offsets);

So it is OK to just free it even on success??
> +err:
> +	return rc;
> +}
> +
>  void __init xen_init_IRQ(void)
>  {
>  	int i, rc;
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:57:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2lq1-0006yv-15; Tue, 05 Feb 2013 16:57:41 +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 1U2lpz-0006yl-F7
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:57:39 +0000
Received: from [85.158.139.83:4181] by server-2.bemta-5.messagelabs.com id
	95/2A-16911-20A31115; Tue, 05 Feb 2013 16:57:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360083456!30847178!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30044 invoked from network); 5 Feb 2013 16:57:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 16:57:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15GvYHR007510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 16:57: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
	r15GvX1e003070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 16:57:34 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
	r15GvXBp029499; Tue, 5 Feb 2013 10:57:33 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 08:57:33 -0800
Date: Tue, 5 Feb 2013 11:57:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205165728.GD2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
	<510BA3B4.4010104@citrix.com>
	<1359721985.23229.109.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359721985.23229.109.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/13] xen: fix evtchn_unbind_from_user
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 01, 2013 at 12:33:05PM +0000, Wei Liu wrote:
> On Fri, 2013-02-01 at 11:15 +0000, David Vrabel wrote:
> > On 31/01/13 14:46, Wei Liu wrote:
> > > It is possible the port was allocated but the irq was not. Take care of this
> > > case.
> > 
> > I think the port should be closed when the evtchn_bind_to_user() fails
> > otherwise the evtchn driver is leaving the event channel in an
> > inconsistent state.
> > 
> 
> Good point! I will move the fix there.

Ok, and in this function just do a BUG_ON(xx) if the case is still hit.

> 
> Wei.
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 16:57:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 16: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 1U2lq1-0006yv-15; Tue, 05 Feb 2013 16:57:41 +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 1U2lpz-0006yl-F7
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 16:57:39 +0000
Received: from [85.158.139.83:4181] by server-2.bemta-5.messagelabs.com id
	95/2A-16911-20A31115; Tue, 05 Feb 2013 16:57:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360083456!30847178!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30044 invoked from network); 5 Feb 2013 16:57:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 16:57:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15GvYHR007510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 16:57: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
	r15GvX1e003070
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 16:57:34 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
	r15GvXBp029499; Tue, 5 Feb 2013 10:57:33 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 08:57:33 -0800
Date: Tue, 5 Feb 2013 11:57:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205165728.GD2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-4-git-send-email-wei.liu2@citrix.com>
	<510BA3B4.4010104@citrix.com>
	<1359721985.23229.109.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359721985.23229.109.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/13] xen: fix evtchn_unbind_from_user
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 01, 2013 at 12:33:05PM +0000, Wei Liu wrote:
> On Fri, 2013-02-01 at 11:15 +0000, David Vrabel wrote:
> > On 31/01/13 14:46, Wei Liu wrote:
> > > It is possible the port was allocated but the irq was not. Take care of this
> > > case.
> > 
> > I think the port should be closed when the evtchn_bind_to_user() fails
> > otherwise the evtchn driver is leaving the event channel in an
> > inconsistent state.
> > 
> 
> Good point! I will move the fix there.

Ok, and in this function just do a BUG_ON(xx) if the case is still hit.

> 
> Wei.
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:00:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2lse-0007As-8f; Tue, 05 Feb 2013 17:00: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 1U2lsc-0007Ae-Nm
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:00:22 +0000
Received: from [85.158.138.51:64643] by server-4.bemta-3.messagelabs.com id
	75/07-12802-1AA31115; Tue, 05 Feb 2013 17:00:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360083614!20868326!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4009 invoked from network); 5 Feb 2013 17:00:16 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:00:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15H0BHk022282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:00:12 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
	r15H0AWN010926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:00:11 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
	r15H0B3Y015673; Tue, 5 Feb 2013 11:00:11 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:00:10 -0800
Date: Tue, 5 Feb 2013 12:00:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205170006.GE2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Thu, Jan 31, 2013 at 02:46:58PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h           |    9 ++++++++-
>  2 files changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
> index f494292..9d8b9e7 100644
> --- a/include/xen/interface/event_channel.h
> +++ b/include/xen/interface/event_channel.h
> @@ -190,6 +190,39 @@ struct evtchn_reset {
>  };
>  typedef struct evtchn_reset evtchn_reset_t;
>  
> +/*
> + * EVTCHNOP_register_nlevel: Register N-level event channel
> + * NOTES:
> + *  1. Currently only 3-level is supported.
> + *  2. Should fall back to 2-level if this call fails.
> + */
> +#define EVTCHNOP_register_nlevel 11
> +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> + * 256k event channels while 32 bit ones only need 1 page for 32k
> + * event channels. */
> +#define EVTCHN_MAX_L3_PAGES 8
> +struct evtchn_register_3level {
> +	/* IN parameters. */
> +	uint32_t nr_pages; /* for evtchn_{pending,mask} */
> +	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
> +	GUEST_HANDLE(ulong) evtchn_pending;
> +	GUEST_HANDLE(ulong) evtchn_mask;
> +	GUEST_HANDLE(ulong) l2sel_mfns;
> +	GUEST_HANDLE(ulong) l2sel_offsets;
> +};
> +typedef struct evtchn_register_3level evtchn_register_3level_t;
> +DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
> +
> +struct evtchn_register_nlevel {
> +	/* IN parameters. */
> +	uint32_t level;
> +	union {
> +		evtchn_register_3level_t l3;
> +	} u;
> +};
> +typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
> +DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
> +
>  struct evtchn_op {
>  	uint32_t cmd; /* EVTCHNOP_* */
>  	union {
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index a890804..5220e33 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>  
>  /*
>   * Event channel endpoints per domain:
> + * 2-level:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> + * 3-level:
> + *  32k if a long is 32 bits; 256k if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)

We did a bit of header change to make the ARM code always use 'unsinged
long long' on 32-bit (so it is a nice 8-bytes) and 'unsigned long' on
64-bit. This was all done using the xen_pfn_t and xen_mfn_t typdefs.

Any chance you can do that here? That way on ARM - irregardless if it is
32-bit or 64-bit it is always of the 64-bit size?

Or do we not care about the ARM case here?

> +#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
> +#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> +#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
> +#endif
>  
>  struct vcpu_time_info {
>  	/*
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:00:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2lse-0007As-8f; Tue, 05 Feb 2013 17:00: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 1U2lsc-0007Ae-Nm
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:00:22 +0000
Received: from [85.158.138.51:64643] by server-4.bemta-3.messagelabs.com id
	75/07-12802-1AA31115; Tue, 05 Feb 2013 17:00:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360083614!20868326!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4009 invoked from network); 5 Feb 2013 17:00:16 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:00:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15H0BHk022282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:00:12 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
	r15H0AWN010926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:00:11 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
	r15H0B3Y015673; Tue, 5 Feb 2013 11:00:11 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:00:10 -0800
Date: Tue, 5 Feb 2013 12:00:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205170006.GE2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Thu, Jan 31, 2013 at 02:46:58PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h           |    9 ++++++++-
>  2 files changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
> index f494292..9d8b9e7 100644
> --- a/include/xen/interface/event_channel.h
> +++ b/include/xen/interface/event_channel.h
> @@ -190,6 +190,39 @@ struct evtchn_reset {
>  };
>  typedef struct evtchn_reset evtchn_reset_t;
>  
> +/*
> + * EVTCHNOP_register_nlevel: Register N-level event channel
> + * NOTES:
> + *  1. Currently only 3-level is supported.
> + *  2. Should fall back to 2-level if this call fails.
> + */
> +#define EVTCHNOP_register_nlevel 11
> +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> + * 256k event channels while 32 bit ones only need 1 page for 32k
> + * event channels. */
> +#define EVTCHN_MAX_L3_PAGES 8
> +struct evtchn_register_3level {
> +	/* IN parameters. */
> +	uint32_t nr_pages; /* for evtchn_{pending,mask} */
> +	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
> +	GUEST_HANDLE(ulong) evtchn_pending;
> +	GUEST_HANDLE(ulong) evtchn_mask;
> +	GUEST_HANDLE(ulong) l2sel_mfns;
> +	GUEST_HANDLE(ulong) l2sel_offsets;
> +};
> +typedef struct evtchn_register_3level evtchn_register_3level_t;
> +DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
> +
> +struct evtchn_register_nlevel {
> +	/* IN parameters. */
> +	uint32_t level;
> +	union {
> +		evtchn_register_3level_t l3;
> +	} u;
> +};
> +typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
> +DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
> +
>  struct evtchn_op {
>  	uint32_t cmd; /* EVTCHNOP_* */
>  	union {
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index a890804..5220e33 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>  
>  /*
>   * Event channel endpoints per domain:
> + * 2-level:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> + * 3-level:
> + *  32k if a long is 32 bits; 256k if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)

We did a bit of header change to make the ARM code always use 'unsinged
long long' on 32-bit (so it is a nice 8-bytes) and 'unsigned long' on
64-bit. This was all done using the xen_pfn_t and xen_mfn_t typdefs.

Any chance you can do that here? That way on ARM - irregardless if it is
32-bit or 64-bit it is always of the 64-bit size?

Or do we not care about the ARM case here?

> +#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
> +#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> +#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
> +#endif
>  
>  struct vcpu_time_info {
>  	/*
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:05:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:05: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 1U2lx1-0007jG-65; Tue, 05 Feb 2013 17:04:55 +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 1U2lwz-0007j9-JG
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:04:54 +0000
Received: from [85.158.139.83:15912] by server-8.bemta-5.messagelabs.com id
	D2/2A-19075-4BB31115; Tue, 05 Feb 2013 17:04:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360083890!25559661!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30108 invoked from network); 5 Feb 2013 17:04:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:04:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15H4l31016851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:04:48 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
	r15H4l0F021145
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:04:47 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
	r15H4k4p003798; Tue, 5 Feb 2013 11:04:46 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:04:45 -0800
Date: Tue, 5 Feb 2013 12:04:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205170430.GF2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> Use global pointers in common operations to allow for better code sharing
> between N-level event channel.
> 
> Functions which are not suitable for sharing are also taken care of.
> 
> Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
>  drivers/xen/evtchn.c |   12 ++--
>  include/xen/events.h |    2 +
>  3 files changed, 123 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 0679d27..4820a52 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -51,6 +51,16 @@
>  #include <xen/interface/hvm/hvm_op.h>
>  #include <xen/interface/hvm/params.h>
>  
> +/* N-level event channel, starting from 2 */
> +unsigned int evtchn_level = 2;

What if the hypervisor does not support that? Shouldn't be by default
at 1?

> +EXPORT_SYMBOL_GPL(evtchn_level);

Prefix it please with 'xen'

> +unsigned int nr_event_channels;
> +EXPORT_SYMBOL_GPL(nr_event_channels);

Ditto here.

> +
> +/* The following pointers point to pending bitmap and mask bitmap. */
> +static unsigned long *evtchn_pending;
> +static unsigned long *evtchn_mask;
> +
>  /*
>   * This lock protects updates to the following mapping and reference-count
>   * arrays. The lock does not need to be acquired to read the mapping tables.
> @@ -113,7 +123,7 @@ static int *evtchn_to_irq;
>  static unsigned long *pirq_eoi_map;
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS_L2/BITS_PER_LONG],
>  		      cpu_evtchn_mask);
>  
>  /* Xen will never allocate port zero for any purpose. */
> @@ -286,12 +296,11 @@ static bool pirq_needs_eoi_flag(unsigned irq)
>  }
>  
>  static inline unsigned long active_evtchns(unsigned int cpu,
> -					   struct shared_info *sh,
>  					   unsigned int idx)
>  {
> -	return sh->evtchn_pending[idx] &
> +	return evtchn_pending[idx] &
>  		per_cpu(cpu_evtchn_mask, cpu)[idx] &
> -		~sh->evtchn_mask[idx];
> +		~evtchn_mask[idx];
>  }
>  
>  static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> @@ -329,26 +338,22 @@ static void init_evtchn_cpu_bindings(void)
>  
>  static inline void clear_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_clear_bit(port, &s->evtchn_pending[0]);
> +	sync_clear_bit(port, &evtchn_pending[0]);
>  }
>  
>  static inline void set_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_pending[0]);
> +	sync_set_bit(port, &evtchn_pending[0]);
>  }
>  
>  static inline int test_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_bit(port, &s->evtchn_pending[0]);
> +	return sync_test_bit(port, &evtchn_pending[0]);
>  }
>  
>  static inline int test_and_set_mask(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_and_set_bit(port, &s->evtchn_mask[0]);
> +	return sync_test_and_set_bit(port, &evtchn_mask[0]);
>  }
>  
>  
> @@ -371,13 +376,28 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  
>  static void mask_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_mask[0]);
> +	sync_set_bit(port, &evtchn_mask[0]);
> +}
> +
> +static inline void __unmask_local_port_l2(int port)
> +{
> +	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> +
> +	sync_clear_bit(port, &evtchn_mask[0]);
> +
> +	/*
> +	 * The following is basically the equivalent of
> +	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> +	 * the interrupt edge' if the channel is masked.
> +	 */
> +	if (sync_test_bit(port, &evtchn_pending[0]) &&
> +	    !sync_test_and_set_bit(port / BITS_PER_LONG,
> +				   &vcpu_info->evtchn_pending_sel))
> +		vcpu_info->evtchn_upcall_pending = 1;
>  }
>  
>  static void unmask_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
>  	unsigned int cpu = get_cpu();
>  
>  	BUG_ON(!irqs_disabled());
> @@ -387,19 +407,13 @@ static void unmask_evtchn(int port)
>  		struct evtchn_unmask unmask = { .port = port };
>  		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
>  	} else {
> -		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> -
> -		sync_clear_bit(port, &s->evtchn_mask[0]);
> -
> -		/*
> -		 * The following is basically the equivalent of
> -		 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> -		 * the interrupt edge' if the channel is masked.
> -		 */
> -		if (sync_test_bit(port, &s->evtchn_pending[0]) &&
> -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> -					   &vcpu_info->evtchn_pending_sel))
> -			vcpu_info->evtchn_upcall_pending = 1;
> +		switch (evtchn_level) {
> +		case 2:
> +			__unmask_local_port_l2(port);
> +			break;
> +		default:
> +			BUG();
> +		}
>  	}
>  
>  	put_cpu();
> @@ -902,7 +916,7 @@ static int find_virq(unsigned int virq, unsigned int cpu)
>  	int port, rc = -ENOENT;
>  
>  	memset(&status, 0, sizeof(status));
> -	for (port = 0; port <= NR_EVENT_CHANNELS; port++) {
> +	for (port = 0; port <= nr_event_channels; port++) {
>  		status.dom = DOMID_SELF;
>  		status.port = port;
>  		rc = HYPERVISOR_event_channel_op(EVTCHNOP_status, &status);
> @@ -1127,7 +1141,7 @@ int evtchn_get(unsigned int evtchn)
>  	struct irq_info *info;
>  	int err = -ENOENT;
>  
> -	if (evtchn >= NR_EVENT_CHANNELS)
> +	if (evtchn >= nr_event_channels)
>  		return -EINVAL;
>  
>  	mutex_lock(&irq_mapping_update_lock);
> @@ -1170,15 +1184,16 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
>  	notify_remote_via_irq(irq);
>  }
>  
> +static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
> +
>  irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
> -	struct shared_info *sh = HYPERVISOR_shared_info;
> -	int cpu = smp_processor_id();
> -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> -	int i;
> -	unsigned long flags;
> +	irqreturn_t rc;
>  	static DEFINE_SPINLOCK(debug_lock);
> +	unsigned long flags;
> +	int cpu = smp_processor_id();
>  	struct vcpu_info *v;
> +	int i;
>  
>  	spin_lock_irqsave(&debug_lock, flags);
>  
> @@ -1195,24 +1210,45 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		       (int)(sizeof(v->evtchn_pending_sel)*2),
>  		       v->evtchn_pending_sel);
>  	}
> +
> +	switch (evtchn_level) {
> +	case 2:
> +		rc = xen_debug_interrupt_l2(irq, dev_id);
> +		break;
> +	default:
> +		BUG();
> +	}
> +
> +	spin_unlock_irqrestore(&debug_lock, flags);
> +	return rc;
> +}
> +
> +static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
> +{
> +	int cpu = smp_processor_id();
> +	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	int i;
> +	unsigned long nr_elems = NR_EVENT_CHANNELS_L2 / BITS_PER_LONG;
> +	struct vcpu_info *v;
> +
>  	v = per_cpu(xen_vcpu, cpu);
>  
>  	printk(KERN_DEBUG "\npending:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> -		       sh->evtchn_pending[i],
> +	for (i = nr_elems; i >= 0; i--)
> +		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(evtchn_pending[0])*2,
> +		       evtchn_pending[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  	printk(KERN_DEBUG "\nglobal mask:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> +	for (i = nr_elems-1; i >= 0; i--)
>  		printk(KERN_DEBUG "%0*lx%s",
> -		       (int)(sizeof(sh->evtchn_mask[0])*2),
> -		       sh->evtchn_mask[i],
> +		       (int)(sizeof(evtchn_mask[0])*2),
> +		       evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk(KERN_DEBUG "\nglobally unmasked:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> -		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
> +	for (i = nr_elems-1; i >= 0; i--)
> +		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
> +		       evtchn_pending[i] & ~evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk(KERN_DEBUG "\nlocal cpu%d mask:\n   ", cpu);
> @@ -1222,32 +1258,30 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk(KERN_DEBUG "\nlocally unmasked:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> -		unsigned long pending = sh->evtchn_pending[i]
> -			& ~sh->evtchn_mask[i]
> +	for (i = nr_elems-1; i >= 0; i--) {
> +		unsigned long pending = evtchn_pending[i]
> +			& ~evtchn_mask[i]
>  			& cpu_evtchn[i];
> -		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
>  		       pending, i % 8 == 0 ? "\n   " : " ");
>  	}
>  
>  	printk(KERN_DEBUG "\npending list:\n");
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -		if (sync_test_bit(i, sh->evtchn_pending)) {
> +	for (i = 0; i < NR_EVENT_CHANNELS_L2; i++) {
> +		if (sync_test_bit(i, evtchn_pending)) {
>  			int word_idx = i / BITS_PER_LONG;
>  			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s\n",
>  			       cpu_from_evtchn(i), i,
>  			       evtchn_to_irq[i],
>  			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
>  					     ? "" : " l1-clear",
> -			       sync_test_bit(i, sh->evtchn_mask)
> +			       sync_test_bit(i, evtchn_mask)
>  					     ? "" : " globally-masked",
>  			       sync_test_bit(i, cpu_evtchn)
>  					     ? "" : " locally-masked");
>  		}
>  	}
>  
> -	spin_unlock_irqrestore(&debug_lock, flags);
> -
>  	return IRQ_HANDLED;
>  }
>  
> @@ -1269,13 +1303,12 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>   * a bitset of words which contain pending event bits.  The second
>   * level is a bitset of pending events themselves.
>   */
> -static void __xen_evtchn_do_upcall(void)
> +static void __xen_evtchn_do_upcall_l2(void)
>  {
>  	int start_word_idx, start_bit_idx;
>  	int word_idx, bit_idx;
>  	int i;
>  	int cpu = get_cpu();
> -	struct shared_info *s = HYPERVISOR_shared_info;
>  	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>  	unsigned count;
>  
> @@ -1314,7 +1347,7 @@ static void __xen_evtchn_do_upcall(void)
>  			}
>  			word_idx = __ffs(words);
>  
> -			pending_bits = active_evtchns(cpu, s, word_idx);
> +			pending_bits = active_evtchns(cpu, word_idx);
>  			bit_idx = 0; /* usually scan entire word from start */
>  			if (word_idx == start_word_idx) {
>  				/* We scan the starting word in two parts */
> @@ -1383,7 +1416,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  	exit_idle();
>  	irq_enter();
>  
> -	__xen_evtchn_do_upcall();
> +	switch (evtchn_level) {
> +	case 2:
> +		__xen_evtchn_do_upcall_l2();
> +		break;
> +	default:
> +		BUG();
> +	}
>  
>  	irq_exit();
>  	set_irq_regs(old_regs);
> @@ -1391,7 +1430,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  
>  void xen_hvm_evtchn_do_upcall(void)
>  {
> -	__xen_evtchn_do_upcall();
> +	switch (evtchn_level) {
> +	case 2:
> +		__xen_evtchn_do_upcall_l2();
> +		break;
> +	default:
> +		BUG();
> +	}
>  }
>  EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall);
>  
> @@ -1465,7 +1510,6 @@ static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
>  int resend_irq_on_evtchn(unsigned int irq)
>  {
>  	int masked, evtchn = evtchn_from_irq(irq);
> -	struct shared_info *s = HYPERVISOR_shared_info;
>  
>  	if (!VALID_EVTCHN(evtchn))
>  		return 1;
> @@ -1513,7 +1557,6 @@ static void mask_ack_dynirq(struct irq_data *data)
>  static int retrigger_dynirq(struct irq_data *data)
>  {
>  	int evtchn = evtchn_from_irq(data->irq);
> -	struct shared_info *sh = HYPERVISOR_shared_info;
>  	int ret = 0;
>  
>  	if (VALID_EVTCHN(evtchn)) {
> @@ -1689,14 +1732,14 @@ void xen_irq_resume(void)
>  	init_evtchn_cpu_bindings();
>  
>  	/* New event-channel space is not 'live' yet. */
> -	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
> +	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
>  		mask_evtchn(evtchn);
>  
>  	/* No IRQ <-> event-channel mappings. */
>  	list_for_each_entry(info, &xen_irq_list_head, list)
>  		info->evtchn = 0; /* zap event-channel binding */
>  
> -	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
> +	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
>  		evtchn_to_irq[evtchn] = -1;
>  
>  	for_each_possible_cpu(cpu) {
> @@ -1792,17 +1835,24 @@ void xen_callback_vector(void) {}
>  void __init xen_init_IRQ(void)
>  {
>  	int i, rc;
> +	struct shared_info *s = HYPERVISOR_shared_info;
> +
> +	evtchn_pending = s->evtchn_pending;
> +	evtchn_mask = s->evtchn_mask;
> +
> +	evtchn_level = 2;
> +	nr_event_channels = NR_EVENT_CHANNELS_L2;
>  
> -	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> +	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
>  				    GFP_KERNEL);
>  	BUG_ON(!evtchn_to_irq);
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++)
> +	for (i = 0; i < nr_event_channels; i++)
>  		evtchn_to_irq[i] = -1;
>  
>  	init_evtchn_cpu_bindings();
>  
>  	/* No event channels are 'live' right now. */
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++)
> +	for (i = 0; i < nr_event_channels; i++)
>  		mask_evtchn(i);
>  
>  	pirq_needs_eoi = pirq_needs_eoi_flag;
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index d2bbea1..7515ecc 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -232,7 +232,7 @@ static ssize_t evtchn_write(struct file *file, const char __user *buf,
>  	for (i = 0; i < (count/sizeof(evtchn_port_t)); i++) {
>  		unsigned port = kbuf[i];
>  
> -		if (port < NR_EVENT_CHANNELS &&
> +		if (port < nr_event_channels &&
>  		    get_port_user(port) == u &&
>  		    !get_port_enabled(port)) {
>  			set_port_enabled(port, true);
> @@ -374,7 +374,7 @@ static long evtchn_ioctl(struct file *file,
>  			break;
>  
>  		rc = -EINVAL;
> -		if (unbind.port >= NR_EVENT_CHANNELS)
> +		if (unbind.port >= nr_event_channels)
>  			break;
>  
>  		spin_lock_irq(&port_user_lock);
> @@ -402,7 +402,7 @@ static long evtchn_ioctl(struct file *file,
>  		if (copy_from_user(&notify, uarg, sizeof(notify)))
>  			break;
>  
> -		if (notify.port >= NR_EVENT_CHANNELS) {
> +		if (notify.port >= nr_event_channels) {
>  			rc = -EINVAL;
>  		} else if (get_port_user(notify.port) != u) {
>  			rc = -ENOTCONN;
> @@ -492,7 +492,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
>  
>  	free_page((unsigned long)u->ring);
>  
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> +	for (i = 0; i < nr_event_channels; i++) {
>  		if (get_port_user(i) != u)
>  			continue;
>  
> @@ -501,7 +501,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
>  
>  	spin_unlock_irq(&port_user_lock);
>  
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> +	for (i = 0; i < nr_event_channels; i++) {
>  		if (get_port_user(i) != u)
>  			continue;
>  
> @@ -538,7 +538,7 @@ static int __init evtchn_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	port_user = kcalloc(NR_EVENT_CHANNELS, sizeof(*port_user), GFP_KERNEL);
> +	port_user = kcalloc(nr_event_channels, sizeof(*port_user), GFP_KERNEL);
>  	if (port_user == NULL)
>  		return -ENOMEM;
>  
> diff --git a/include/xen/events.h b/include/xen/events.h
> index 04399b2..6b117ac 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
>  /* Determine whether to ignore this IRQ if it is passed to a guest. */
>  int xen_test_irq_shared(int irq);
>  
> +extern unsigned int nr_event_channels;
> +
>  #endif	/* _XEN_EVENTS_H */
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:05:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:05: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 1U2lx1-0007jG-65; Tue, 05 Feb 2013 17:04:55 +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 1U2lwz-0007j9-JG
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:04:54 +0000
Received: from [85.158.139.83:15912] by server-8.bemta-5.messagelabs.com id
	D2/2A-19075-4BB31115; Tue, 05 Feb 2013 17:04:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360083890!25559661!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30108 invoked from network); 5 Feb 2013 17:04:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:04:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15H4l31016851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:04:48 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
	r15H4l0F021145
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:04:47 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
	r15H4k4p003798; Tue, 5 Feb 2013 11:04:46 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:04:45 -0800
Date: Tue, 5 Feb 2013 12:04:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205170430.GF2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> Use global pointers in common operations to allow for better code sharing
> between N-level event channel.
> 
> Functions which are not suitable for sharing are also taken care of.
> 
> Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
>  drivers/xen/evtchn.c |   12 ++--
>  include/xen/events.h |    2 +
>  3 files changed, 123 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 0679d27..4820a52 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -51,6 +51,16 @@
>  #include <xen/interface/hvm/hvm_op.h>
>  #include <xen/interface/hvm/params.h>
>  
> +/* N-level event channel, starting from 2 */
> +unsigned int evtchn_level = 2;

What if the hypervisor does not support that? Shouldn't be by default
at 1?

> +EXPORT_SYMBOL_GPL(evtchn_level);

Prefix it please with 'xen'

> +unsigned int nr_event_channels;
> +EXPORT_SYMBOL_GPL(nr_event_channels);

Ditto here.

> +
> +/* The following pointers point to pending bitmap and mask bitmap. */
> +static unsigned long *evtchn_pending;
> +static unsigned long *evtchn_mask;
> +
>  /*
>   * This lock protects updates to the following mapping and reference-count
>   * arrays. The lock does not need to be acquired to read the mapping tables.
> @@ -113,7 +123,7 @@ static int *evtchn_to_irq;
>  static unsigned long *pirq_eoi_map;
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS_L2/BITS_PER_LONG],
>  		      cpu_evtchn_mask);
>  
>  /* Xen will never allocate port zero for any purpose. */
> @@ -286,12 +296,11 @@ static bool pirq_needs_eoi_flag(unsigned irq)
>  }
>  
>  static inline unsigned long active_evtchns(unsigned int cpu,
> -					   struct shared_info *sh,
>  					   unsigned int idx)
>  {
> -	return sh->evtchn_pending[idx] &
> +	return evtchn_pending[idx] &
>  		per_cpu(cpu_evtchn_mask, cpu)[idx] &
> -		~sh->evtchn_mask[idx];
> +		~evtchn_mask[idx];
>  }
>  
>  static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> @@ -329,26 +338,22 @@ static void init_evtchn_cpu_bindings(void)
>  
>  static inline void clear_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_clear_bit(port, &s->evtchn_pending[0]);
> +	sync_clear_bit(port, &evtchn_pending[0]);
>  }
>  
>  static inline void set_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_pending[0]);
> +	sync_set_bit(port, &evtchn_pending[0]);
>  }
>  
>  static inline int test_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_bit(port, &s->evtchn_pending[0]);
> +	return sync_test_bit(port, &evtchn_pending[0]);
>  }
>  
>  static inline int test_and_set_mask(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_and_set_bit(port, &s->evtchn_mask[0]);
> +	return sync_test_and_set_bit(port, &evtchn_mask[0]);
>  }
>  
>  
> @@ -371,13 +376,28 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  
>  static void mask_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_mask[0]);
> +	sync_set_bit(port, &evtchn_mask[0]);
> +}
> +
> +static inline void __unmask_local_port_l2(int port)
> +{
> +	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> +
> +	sync_clear_bit(port, &evtchn_mask[0]);
> +
> +	/*
> +	 * The following is basically the equivalent of
> +	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> +	 * the interrupt edge' if the channel is masked.
> +	 */
> +	if (sync_test_bit(port, &evtchn_pending[0]) &&
> +	    !sync_test_and_set_bit(port / BITS_PER_LONG,
> +				   &vcpu_info->evtchn_pending_sel))
> +		vcpu_info->evtchn_upcall_pending = 1;
>  }
>  
>  static void unmask_evtchn(int port)
>  {
> -	struct shared_info *s = HYPERVISOR_shared_info;
>  	unsigned int cpu = get_cpu();
>  
>  	BUG_ON(!irqs_disabled());
> @@ -387,19 +407,13 @@ static void unmask_evtchn(int port)
>  		struct evtchn_unmask unmask = { .port = port };
>  		(void)HYPERVISOR_event_channel_op(EVTCHNOP_unmask, &unmask);
>  	} else {
> -		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> -
> -		sync_clear_bit(port, &s->evtchn_mask[0]);
> -
> -		/*
> -		 * The following is basically the equivalent of
> -		 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> -		 * the interrupt edge' if the channel is masked.
> -		 */
> -		if (sync_test_bit(port, &s->evtchn_pending[0]) &&
> -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> -					   &vcpu_info->evtchn_pending_sel))
> -			vcpu_info->evtchn_upcall_pending = 1;
> +		switch (evtchn_level) {
> +		case 2:
> +			__unmask_local_port_l2(port);
> +			break;
> +		default:
> +			BUG();
> +		}
>  	}
>  
>  	put_cpu();
> @@ -902,7 +916,7 @@ static int find_virq(unsigned int virq, unsigned int cpu)
>  	int port, rc = -ENOENT;
>  
>  	memset(&status, 0, sizeof(status));
> -	for (port = 0; port <= NR_EVENT_CHANNELS; port++) {
> +	for (port = 0; port <= nr_event_channels; port++) {
>  		status.dom = DOMID_SELF;
>  		status.port = port;
>  		rc = HYPERVISOR_event_channel_op(EVTCHNOP_status, &status);
> @@ -1127,7 +1141,7 @@ int evtchn_get(unsigned int evtchn)
>  	struct irq_info *info;
>  	int err = -ENOENT;
>  
> -	if (evtchn >= NR_EVENT_CHANNELS)
> +	if (evtchn >= nr_event_channels)
>  		return -EINVAL;
>  
>  	mutex_lock(&irq_mapping_update_lock);
> @@ -1170,15 +1184,16 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
>  	notify_remote_via_irq(irq);
>  }
>  
> +static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
> +
>  irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
> -	struct shared_info *sh = HYPERVISOR_shared_info;
> -	int cpu = smp_processor_id();
> -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> -	int i;
> -	unsigned long flags;
> +	irqreturn_t rc;
>  	static DEFINE_SPINLOCK(debug_lock);
> +	unsigned long flags;
> +	int cpu = smp_processor_id();
>  	struct vcpu_info *v;
> +	int i;
>  
>  	spin_lock_irqsave(&debug_lock, flags);
>  
> @@ -1195,24 +1210,45 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		       (int)(sizeof(v->evtchn_pending_sel)*2),
>  		       v->evtchn_pending_sel);
>  	}
> +
> +	switch (evtchn_level) {
> +	case 2:
> +		rc = xen_debug_interrupt_l2(irq, dev_id);
> +		break;
> +	default:
> +		BUG();
> +	}
> +
> +	spin_unlock_irqrestore(&debug_lock, flags);
> +	return rc;
> +}
> +
> +static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
> +{
> +	int cpu = smp_processor_id();
> +	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	int i;
> +	unsigned long nr_elems = NR_EVENT_CHANNELS_L2 / BITS_PER_LONG;
> +	struct vcpu_info *v;
> +
>  	v = per_cpu(xen_vcpu, cpu);
>  
>  	printk(KERN_DEBUG "\npending:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> -		       sh->evtchn_pending[i],
> +	for (i = nr_elems; i >= 0; i--)
> +		printk(KERN_DEBUG "%0*lx%s", (int)sizeof(evtchn_pending[0])*2,
> +		       evtchn_pending[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  	printk(KERN_DEBUG "\nglobal mask:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> +	for (i = nr_elems-1; i >= 0; i--)
>  		printk(KERN_DEBUG "%0*lx%s",
> -		       (int)(sizeof(sh->evtchn_mask[0])*2),
> -		       sh->evtchn_mask[i],
> +		       (int)(sizeof(evtchn_mask[0])*2),
> +		       evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk(KERN_DEBUG "\nglobally unmasked:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> -		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
> +	for (i = nr_elems-1; i >= 0; i--)
> +		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
> +		       evtchn_pending[i] & ~evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk(KERN_DEBUG "\nlocal cpu%d mask:\n   ", cpu);
> @@ -1222,32 +1258,30 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk(KERN_DEBUG "\nlocally unmasked:\n   ");
> -	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> -		unsigned long pending = sh->evtchn_pending[i]
> -			& ~sh->evtchn_mask[i]
> +	for (i = nr_elems-1; i >= 0; i--) {
> +		unsigned long pending = evtchn_pending[i]
> +			& ~evtchn_mask[i]
>  			& cpu_evtchn[i];
> -		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk(KERN_DEBUG "%0*lx%s", (int)(sizeof(evtchn_mask[0])*2),
>  		       pending, i % 8 == 0 ? "\n   " : " ");
>  	}
>  
>  	printk(KERN_DEBUG "\npending list:\n");
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -		if (sync_test_bit(i, sh->evtchn_pending)) {
> +	for (i = 0; i < NR_EVENT_CHANNELS_L2; i++) {
> +		if (sync_test_bit(i, evtchn_pending)) {
>  			int word_idx = i / BITS_PER_LONG;
>  			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s\n",
>  			       cpu_from_evtchn(i), i,
>  			       evtchn_to_irq[i],
>  			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
>  					     ? "" : " l1-clear",
> -			       sync_test_bit(i, sh->evtchn_mask)
> +			       sync_test_bit(i, evtchn_mask)
>  					     ? "" : " globally-masked",
>  			       sync_test_bit(i, cpu_evtchn)
>  					     ? "" : " locally-masked");
>  		}
>  	}
>  
> -	spin_unlock_irqrestore(&debug_lock, flags);
> -
>  	return IRQ_HANDLED;
>  }
>  
> @@ -1269,13 +1303,12 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>   * a bitset of words which contain pending event bits.  The second
>   * level is a bitset of pending events themselves.
>   */
> -static void __xen_evtchn_do_upcall(void)
> +static void __xen_evtchn_do_upcall_l2(void)
>  {
>  	int start_word_idx, start_bit_idx;
>  	int word_idx, bit_idx;
>  	int i;
>  	int cpu = get_cpu();
> -	struct shared_info *s = HYPERVISOR_shared_info;
>  	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>  	unsigned count;
>  
> @@ -1314,7 +1347,7 @@ static void __xen_evtchn_do_upcall(void)
>  			}
>  			word_idx = __ffs(words);
>  
> -			pending_bits = active_evtchns(cpu, s, word_idx);
> +			pending_bits = active_evtchns(cpu, word_idx);
>  			bit_idx = 0; /* usually scan entire word from start */
>  			if (word_idx == start_word_idx) {
>  				/* We scan the starting word in two parts */
> @@ -1383,7 +1416,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  	exit_idle();
>  	irq_enter();
>  
> -	__xen_evtchn_do_upcall();
> +	switch (evtchn_level) {
> +	case 2:
> +		__xen_evtchn_do_upcall_l2();
> +		break;
> +	default:
> +		BUG();
> +	}
>  
>  	irq_exit();
>  	set_irq_regs(old_regs);
> @@ -1391,7 +1430,13 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  
>  void xen_hvm_evtchn_do_upcall(void)
>  {
> -	__xen_evtchn_do_upcall();
> +	switch (evtchn_level) {
> +	case 2:
> +		__xen_evtchn_do_upcall_l2();
> +		break;
> +	default:
> +		BUG();
> +	}
>  }
>  EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall);
>  
> @@ -1465,7 +1510,6 @@ static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
>  int resend_irq_on_evtchn(unsigned int irq)
>  {
>  	int masked, evtchn = evtchn_from_irq(irq);
> -	struct shared_info *s = HYPERVISOR_shared_info;
>  
>  	if (!VALID_EVTCHN(evtchn))
>  		return 1;
> @@ -1513,7 +1557,6 @@ static void mask_ack_dynirq(struct irq_data *data)
>  static int retrigger_dynirq(struct irq_data *data)
>  {
>  	int evtchn = evtchn_from_irq(data->irq);
> -	struct shared_info *sh = HYPERVISOR_shared_info;
>  	int ret = 0;
>  
>  	if (VALID_EVTCHN(evtchn)) {
> @@ -1689,14 +1732,14 @@ void xen_irq_resume(void)
>  	init_evtchn_cpu_bindings();
>  
>  	/* New event-channel space is not 'live' yet. */
> -	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
> +	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
>  		mask_evtchn(evtchn);
>  
>  	/* No IRQ <-> event-channel mappings. */
>  	list_for_each_entry(info, &xen_irq_list_head, list)
>  		info->evtchn = 0; /* zap event-channel binding */
>  
> -	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
> +	for (evtchn = 0; evtchn < nr_event_channels; evtchn++)
>  		evtchn_to_irq[evtchn] = -1;
>  
>  	for_each_possible_cpu(cpu) {
> @@ -1792,17 +1835,24 @@ void xen_callback_vector(void) {}
>  void __init xen_init_IRQ(void)
>  {
>  	int i, rc;
> +	struct shared_info *s = HYPERVISOR_shared_info;
> +
> +	evtchn_pending = s->evtchn_pending;
> +	evtchn_mask = s->evtchn_mask;
> +
> +	evtchn_level = 2;
> +	nr_event_channels = NR_EVENT_CHANNELS_L2;
>  
> -	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> +	evtchn_to_irq = kcalloc(nr_event_channels, sizeof(*evtchn_to_irq),
>  				    GFP_KERNEL);
>  	BUG_ON(!evtchn_to_irq);
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++)
> +	for (i = 0; i < nr_event_channels; i++)
>  		evtchn_to_irq[i] = -1;
>  
>  	init_evtchn_cpu_bindings();
>  
>  	/* No event channels are 'live' right now. */
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++)
> +	for (i = 0; i < nr_event_channels; i++)
>  		mask_evtchn(i);
>  
>  	pirq_needs_eoi = pirq_needs_eoi_flag;
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index d2bbea1..7515ecc 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -232,7 +232,7 @@ static ssize_t evtchn_write(struct file *file, const char __user *buf,
>  	for (i = 0; i < (count/sizeof(evtchn_port_t)); i++) {
>  		unsigned port = kbuf[i];
>  
> -		if (port < NR_EVENT_CHANNELS &&
> +		if (port < nr_event_channels &&
>  		    get_port_user(port) == u &&
>  		    !get_port_enabled(port)) {
>  			set_port_enabled(port, true);
> @@ -374,7 +374,7 @@ static long evtchn_ioctl(struct file *file,
>  			break;
>  
>  		rc = -EINVAL;
> -		if (unbind.port >= NR_EVENT_CHANNELS)
> +		if (unbind.port >= nr_event_channels)
>  			break;
>  
>  		spin_lock_irq(&port_user_lock);
> @@ -402,7 +402,7 @@ static long evtchn_ioctl(struct file *file,
>  		if (copy_from_user(&notify, uarg, sizeof(notify)))
>  			break;
>  
> -		if (notify.port >= NR_EVENT_CHANNELS) {
> +		if (notify.port >= nr_event_channels) {
>  			rc = -EINVAL;
>  		} else if (get_port_user(notify.port) != u) {
>  			rc = -ENOTCONN;
> @@ -492,7 +492,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
>  
>  	free_page((unsigned long)u->ring);
>  
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> +	for (i = 0; i < nr_event_channels; i++) {
>  		if (get_port_user(i) != u)
>  			continue;
>  
> @@ -501,7 +501,7 @@ static int evtchn_release(struct inode *inode, struct file *filp)
>  
>  	spin_unlock_irq(&port_user_lock);
>  
> -	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> +	for (i = 0; i < nr_event_channels; i++) {
>  		if (get_port_user(i) != u)
>  			continue;
>  
> @@ -538,7 +538,7 @@ static int __init evtchn_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	port_user = kcalloc(NR_EVENT_CHANNELS, sizeof(*port_user), GFP_KERNEL);
> +	port_user = kcalloc(nr_event_channels, sizeof(*port_user), GFP_KERNEL);
>  	if (port_user == NULL)
>  		return -ENOMEM;
>  
> diff --git a/include/xen/events.h b/include/xen/events.h
> index 04399b2..6b117ac 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
>  /* Determine whether to ignore this IRQ if it is passed to a guest. */
>  int xen_test_irq_shared(int irq);
>  
> +extern unsigned int nr_event_channels;
> +
>  #endif	/* _XEN_EVENTS_H */
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:05:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2lxB-0007kO-Pe; Tue, 05 Feb 2013 17:05:05 +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 1U2lxB-0007kE-2m
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:05:05 +0000
Received: from [85.158.139.83:16835] by server-4.bemta-5.messagelabs.com id
	1F/B0-29496-0CB31115; Tue, 05 Feb 2013 17:05:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360083901!25046418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30393 invoked from network); 5 Feb 2013 17:05:03 -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;
	5 Feb 2013 17:05:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6345485"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:05:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:05:00 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2lx6-0006Qw-50;
	Tue, 05 Feb 2013 17:05:00 +0000
Message-ID: <1360083900.7477.154.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:05:00 +0000
In-Reply-To: <20130205165550.GC2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
	<20130205165550.GC2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > +
> > +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> > +	if (rc) {
> > +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> > +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> > +		evtchn_pending = NULL;
> > +		evtchn_mask = NULL;
> > +	}
> > +
> > +out:
> > +	kfree(_evtchn_pending);
> > +	kfree(_evtchn_mask);
> > +	kfree(l2sel_mfns);
> > +	kfree(l2sel_offsets);
> 
> So it is OK to just free it even on success??

Yes. They are only used for registration.

And for all the above stuffs regarding comments, I will fix them in
later post.


Wei.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:05:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2lxB-0007kO-Pe; Tue, 05 Feb 2013 17:05:05 +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 1U2lxB-0007kE-2m
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:05:05 +0000
Received: from [85.158.139.83:16835] by server-4.bemta-5.messagelabs.com id
	1F/B0-29496-0CB31115; Tue, 05 Feb 2013 17:05:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360083901!25046418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30393 invoked from network); 5 Feb 2013 17:05:03 -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;
	5 Feb 2013 17:05:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6345485"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:05:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:05:00 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2lx6-0006Qw-50;
	Tue, 05 Feb 2013 17:05:00 +0000
Message-ID: <1360083900.7477.154.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:05:00 +0000
In-Reply-To: <20130205165550.GC2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
	<20130205165550.GC2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > +
> > +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> > +	if (rc) {
> > +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> > +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> > +		evtchn_pending = NULL;
> > +		evtchn_mask = NULL;
> > +	}
> > +
> > +out:
> > +	kfree(_evtchn_pending);
> > +	kfree(_evtchn_mask);
> > +	kfree(l2sel_mfns);
> > +	kfree(l2sel_offsets);
> 
> So it is OK to just free it even on success??

Yes. They are only used for registration.

And for all the above stuffs regarding comments, I will fix them in
later post.


Wei.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:09:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:09: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 1U2m0v-00083x-Em; Tue, 05 Feb 2013 17:08:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2m0u-00083m-4e
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:08:56 +0000
Received: from [85.158.137.99:34881] by server-2.bemta-3.messagelabs.com id
	EA/4C-25961-7AC31115; Tue, 05 Feb 2013 17:08:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360084132!20110584!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11495 invoked from network); 5 Feb 2013 17:08:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 17:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6346215"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:08:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:08:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2m0p-0006UY-B9;
	Tue, 05 Feb 2013 17:08:51 +0000
Message-ID: <1360084131.7477.156.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:08:51 +0000
In-Reply-To: <20130205170430.GF2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > Use global pointers in common operations to allow for better code sharing
> > between N-level event channel.
> >
> > Functions which are not suitable for sharing are also taken care of.
> >
> > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> >  drivers/xen/evtchn.c |   12 ++--
> >  include/xen/events.h |    2 +
> >  3 files changed, 123 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 0679d27..4820a52 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -51,6 +51,16 @@
> >  #include <xen/interface/hvm/hvm_op.h>
> >  #include <xen/interface/hvm/params.h>
> >
> > +/* N-level event channel, starting from 2 */
> > +unsigned int evtchn_level = 2;
> 
> What if the hypervisor does not support that? Shouldn't be by default
> at 1?
> 

the default implementation is 2 level. ;-)

> > +EXPORT_SYMBOL_GPL(evtchn_level);
> 
> Prefix it please with 'xen'
> 
> > +unsigned int nr_event_channels;
> > +EXPORT_SYMBOL_GPL(nr_event_channels);
> 
> Ditto here.
>  

NP.


Wei.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:09:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:09: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 1U2m0v-00083x-Em; Tue, 05 Feb 2013 17:08:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2m0u-00083m-4e
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:08:56 +0000
Received: from [85.158.137.99:34881] by server-2.bemta-3.messagelabs.com id
	EA/4C-25961-7AC31115; Tue, 05 Feb 2013 17:08:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360084132!20110584!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11495 invoked from network); 5 Feb 2013 17:08:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 17:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6346215"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:08:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:08:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2m0p-0006UY-B9;
	Tue, 05 Feb 2013 17:08:51 +0000
Message-ID: <1360084131.7477.156.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:08:51 +0000
In-Reply-To: <20130205170430.GF2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > Use global pointers in common operations to allow for better code sharing
> > between N-level event channel.
> >
> > Functions which are not suitable for sharing are also taken care of.
> >
> > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> >  drivers/xen/evtchn.c |   12 ++--
> >  include/xen/events.h |    2 +
> >  3 files changed, 123 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 0679d27..4820a52 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -51,6 +51,16 @@
> >  #include <xen/interface/hvm/hvm_op.h>
> >  #include <xen/interface/hvm/params.h>
> >
> > +/* N-level event channel, starting from 2 */
> > +unsigned int evtchn_level = 2;
> 
> What if the hypervisor does not support that? Shouldn't be by default
> at 1?
> 

the default implementation is 2 level. ;-)

> > +EXPORT_SYMBOL_GPL(evtchn_level);
> 
> Prefix it please with 'xen'
> 
> > +unsigned int nr_event_channels;
> > +EXPORT_SYMBOL_GPL(nr_event_channels);
> 
> Ditto here.
>  

NP.


Wei.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:12:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:12: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 1U2m3k-0008FX-1T; Tue, 05 Feb 2013 17:11: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 1U2m3i-0008FO-Jh
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:11:50 +0000
Received: from [85.158.143.35:37531] by server-1.bemta-4.messagelabs.com id
	44/F9-08839-15D31115; Tue, 05 Feb 2013 17:11:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360084156!16016698!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9414 invoked from network); 5 Feb 2013 17:09:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:09:18 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15H9D2e002122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:09:14 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
	r15H9CU3004185
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:09:13 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
	r15H9CYt002670; Tue, 5 Feb 2013 11:09:12 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:09:11 -0800
Date: Tue, 5 Feb 2013 12:09:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205170900.GG2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 31, 2013 at 02:47:03PM +0000, Wei Liu wrote:
> Only do_upcall, debug_interrupt and unmask_evtchn are required.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 291 insertions(+)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 30ca620..d953e81 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -51,6 +51,9 @@
>  #include <xen/interface/hvm/hvm_op.h>
>  #include <xen/interface/hvm/params.h>
>  
> +/* Helper macro(s) */
> +#define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)

That really needs an explanation.
> +
>  /* N-level event channel, starting from 2 */
>  unsigned int evtchn_level = 2;
>  EXPORT_SYMBOL_GPL(evtchn_level);
> @@ -61,6 +64,9 @@ EXPORT_SYMBOL_GPL(nr_event_channels);
>  static unsigned long *evtchn_pending;
>  static unsigned long *evtchn_mask;
>  
> +/* 2nd level selector for 3-level event channel */

And that '8' there needs a #define

> +static DEFINE_PER_CPU(unsigned long[sizeof(unsigned long) * 8], evtchn_sel_l2);
> +
>  /*
>   * This lock protects updates to the following mapping and reference-count
>   * arrays. The lock does not need to be acquired to read the mapping tables.
> @@ -396,6 +402,28 @@ static inline void __unmask_local_port_l2(int port)
>  		vcpu_info->evtchn_upcall_pending = 1;
>  }
>  
> +static inline void __unmask_local_port_l3(int port)
> +{
> +	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> +	int cpu = smp_processor_id();
> +	unsigned int l1bit = port >> (LONG_BITORDER << 1);
> +	unsigned int l2bit = port >> LONG_BITORDER;
> +
> +	sync_clear_bit(port, &evtchn_mask[0]);
> +
> +	/*
> +	 * The following is basically the equivalent of
> +	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> +	 * the interrupt edge' if the channel is masked.
> +	 */
> +	if (sync_test_bit(port, &evtchn_pending[0]) &&
> +	    !sync_test_and_set_bit(l2bit,
> +				   &per_cpu(evtchn_sel_l2, cpu)[0]) &&
> +	    !sync_test_and_set_bit(l1bit,
> +				   &vcpu_info->evtchn_pending_sel))
> +		vcpu_info->evtchn_upcall_pending = 1;
> +}
> +
>  static void unmask_evtchn(int port)
>  {
>  	unsigned int cpu = get_cpu();
> @@ -411,6 +439,9 @@ static void unmask_evtchn(int port)
>  		case 2:
>  			__unmask_local_port_l2(port);
>  			break;
> +		case 3:
> +			__unmask_local_port_l3(port);
> +			break;
>  		default:
>  			BUG();
>  		}
> @@ -1185,6 +1216,7 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
>  }
>  
>  static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
> +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id);
>  
>  irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
> @@ -1215,6 +1247,9 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  	case 2:
>  		rc = xen_debug_interrupt_l2(irq, dev_id);
>  		break;
> +	case 3:
> +		rc = xen_debug_interrupt_l3(irq, dev_id);
> +		break;
>  	default:
>  		BUG();
>  	}
> @@ -1285,8 +1320,109 @@ static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
>  	return IRQ_HANDLED;
>  }
>  
> +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
> +{
> +	int cpu = smp_processor_id();
> +	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
> +	int i;
> +	struct vcpu_info *v;
> +
> +	v = per_cpu(xen_vcpu, cpu);
> +
> +	printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--)
> +		if (evtchn_pending[i] != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)sizeof(evtchn_pending[0])*2,
> +			       evtchn_pending[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--)
> +		if (evtchn_mask[i] != ~0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)sizeof(evtchn_mask[0])*2,
> +			       evtchn_mask[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--)
> +		if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)(sizeof(evtchn_mask[0])*2),
> +			       evtchn_pending[i] & ~evtchn_mask[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
> +	for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
> +		if (cpu_evtchn[i] != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)(sizeof(cpu_evtchn[0])*2),
> +			       cpu_evtchn[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--) {
> +		unsigned long pending = evtchn_pending[i]
> +			& ~evtchn_mask[i]
> +			& cpu_evtchn[i];
> +		if (pending != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)(sizeof(evtchn_mask[0])*2),
> +			       pending);
> +		}
> +	}
> +
> +	printk(KERN_DEBUG "\npending list:\n");
> +	for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
> +		if (sync_test_bit(i, evtchn_pending)) {
> +			int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
> +			int word_idx_l2 = i / BITS_PER_LONG;
> +			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
> +			       cpu_from_evtchn(i), i,
> +			       evtchn_to_irq[i],
> +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +			       ? "" : " l1-clear",
> +			       !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
> +			       ? "" : " l2-clear",
> +			       sync_test_bit(i, evtchn_mask)
> +			       ? "" : " globally-masked",
> +			       sync_test_bit(i, cpu_evtchn)
> +			       ? "" : " locally-masked");
> +		}
> +	}
> +
> +	return IRQ_HANDLED;

Um, there has to be a way to fold the most common cases of the L2 and L3
of this function in one?

> +}
> +
> +/* The following per-cpu variables are used to save current state of event
> + * processing loop.
> + *
> + * 2-level event channel:
> + *  current_word_idx is the bit index in L1 selector indicating the currently
> + *  processing word in shared bitmap.
> + *  current_bit_idx is the bit index in the currently processing word in shared
> + *  bitmap.
> + *  N.B. current_word_idx_l2 is not used.
> + *
> + * 3-level event channel:
> + *  current_word_idx is the bit index in L1 selector indicating the currently
> + *  processing word in L2 selector.
> + *  current_word_idx_l2 is the bit index in L2 selector word indicating the
> + *  currently processing word in shared bitmap.
> + *  current_bit_idx is the bit index in the currently processing word in shared
> + *  bitmap.
> + *
> + */
>  static DEFINE_PER_CPU(unsigned, xed_nesting_count);
>  static DEFINE_PER_CPU(unsigned int, current_word_idx);
> +static DEFINE_PER_CPU(unsigned int, current_word_idx_l2);
>  static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>  
>  /*
> @@ -1409,6 +1545,155 @@ out:
>  	put_cpu();
>  }
>  
> +/*
> + * In the 3-level event channel implementation, the first level is a
> + * bitset of words which contain pending bits in the second level.
> + * The second level is another bitsets which contain pending bits in
> + * the third level.  The third level is a bit set of pending events
> + * themselves.
> + */
> +static void __xen_evtchn_do_upcall_l3(void)
> +{
> +	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> +	unsigned count;
> +	int start_word_idx_l1, start_word_idx_l2, start_bit_idx;
> +	int word_idx_l1, word_idx_l2, bit_idx;
> +	int i, j;
> +	int cpu = get_cpu();
> +
> +	do {
> +		unsigned long pending_words_l1;
> +
> +		vcpu_info->evtchn_upcall_pending = 0;
> +
> +		if (__this_cpu_inc_return(xed_nesting_count) - 1)
> +			goto out;
> +#ifndef CONFIG_X86
> +		/* No need for a barrier -- XCHG is a barrier on x86. */
> +		/* Clear master flag /before/ clearing selector flag. */
> +		wmb();
> +#endif
> +		/* here we get l1 pending selector */
> +		pending_words_l1 = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +
> +		start_word_idx_l1 = __this_cpu_read(current_word_idx);
> +		start_word_idx_l2 = __this_cpu_read(current_word_idx_l2);
> +		start_bit_idx = __this_cpu_read(current_bit_idx);
> +
> +		word_idx_l1 = start_word_idx_l1;
> +
> +		/* loop through l1, try to pick up l2 */
> +		for (i = 0; pending_words_l1 != 0; i++) {
> +			unsigned long words_l1;
> +			unsigned long pending_words_l2;
> +
> +			words_l1 = MASK_LSBS(pending_words_l1, word_idx_l1);
> +
> +			if (words_l1 == 0) {
> +				word_idx_l1 = 0;
> +				start_word_idx_l2 = 0;
> +				continue;
> +			}
> +
> +			word_idx_l1 = __ffs(words_l1);
> +
> +			pending_words_l2 =
> +				xchg(&per_cpu(evtchn_sel_l2, cpu)[word_idx_l1],
> +				     0);
> +
> +			word_idx_l2 = 0;
> +			if (word_idx_l1 == start_word_idx_l1) {
> +				if (i == 0)
> +					word_idx_l2 = start_word_idx_l2;
> +				else
> +					word_idx_l2 &= (1UL << start_word_idx_l2) - 1;
> +			}
> +
> +			for (j = 0; pending_words_l2 != 0; j++) {
> +				unsigned long pending_bits;
> +				unsigned long words_l2;
> +				unsigned long idx;
> +
> +				words_l2 = MASK_LSBS(pending_words_l2,
> +						     word_idx_l2);
> +
> +				if (words_l2 == 0) {
> +					word_idx_l2 = 0;
> +					bit_idx = 0;
> +					continue;
> +				}
> +
> +				word_idx_l2 = __ffs(words_l2);
> +
> +				idx = word_idx_l1*BITS_PER_LONG+word_idx_l2;
> +				pending_bits =
> +					active_evtchns(cpu, idx);
> +
> +				bit_idx = 0;
> +				if (word_idx_l2 == start_word_idx_l2) {
> +					if (j == 0)
> +						bit_idx = start_bit_idx;
> +					else
> +						bit_idx &= (1UL<<start_bit_idx)-1;
> +				}
> +
> +				/* process port */
> +				do {
> +					unsigned long bits;
> +					int port, irq;
> +					struct irq_desc *desc;
> +
> +					bits = MASK_LSBS(pending_bits, bit_idx);
> +
> +					if (bits == 0)
> +						break;
> +
> +					bit_idx = __ffs(bits);
> +
> +					port = (word_idx_l1 << (LONG_BITORDER << 1)) +
> +						(word_idx_l2 << LONG_BITORDER) +
> +						bit_idx;
> +
> +					irq = evtchn_to_irq[port];
> +
> +					if (irq != -1) {
> +						desc = irq_to_desc(irq);
> +						if (desc)
> +							generic_handle_irq_desc(irq, desc);
> +					}
> +
> +					bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +
> +					__this_cpu_write(current_bit_idx, bit_idx);
> +					__this_cpu_write(current_word_idx_l2,
> +							 bit_idx ? word_idx_l2 :
> +							 (word_idx_l2+1) % BITS_PER_LONG);
> +					__this_cpu_write(current_word_idx_l2,
> +							 word_idx_l2 ? word_idx_l1 :
> +							 (word_idx_l1+1) % BITS_PER_LONG);
> +				} while (bit_idx != 0);
> +
> +				if ((word_idx_l2 != start_word_idx_l2) || (j != 0))
> +					pending_words_l2 &= ~(1UL << word_idx_l2);
> +
> +				word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
> +			}

This is a bit of a complex code. Is there any way you can split this up
in smaller inline functions?
> +
> +			if ((word_idx_l1 != start_word_idx_l1) || (i != 0))
> +				pending_words_l1 &= ~(1UL << word_idx_l1);
> +
> +			word_idx_l1 = (word_idx_l1 + 1) % BITS_PER_LONG;
> +		}
> +
> +		BUG_ON(!irqs_disabled());
> +		count = __this_cpu_read(xed_nesting_count);
> +		__this_cpu_write(xed_nesting_count, 0);
> +	} while (count != 1 || vcpu_info->evtchn_upcall_pending);
> +
> +out:
> +	put_cpu();
> +}
> +
>  void xen_evtchn_do_upcall(struct pt_regs *regs)
>  {
>  	struct pt_regs *old_regs = set_irq_regs(regs);
> @@ -1420,6 +1705,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  	case 2:
>  		__xen_evtchn_do_upcall_l2();
>  		break;
> +	case 3:
> +		__xen_evtchn_do_upcall_l3();
> +		break;
>  	default:
>  		BUG();
>  	}
> @@ -1434,6 +1722,9 @@ void xen_hvm_evtchn_do_upcall(void)
>  	case 2:
>  		__xen_evtchn_do_upcall_l2();
>  		break;
> +	case 3:
> +		__xen_evtchn_do_upcall_l3();
> +		break;
>  	default:
>  		BUG();
>  	}
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:12:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:12: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 1U2m3k-0008FX-1T; Tue, 05 Feb 2013 17:11: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 1U2m3i-0008FO-Jh
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:11:50 +0000
Received: from [85.158.143.35:37531] by server-1.bemta-4.messagelabs.com id
	44/F9-08839-15D31115; Tue, 05 Feb 2013 17:11:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360084156!16016698!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9414 invoked from network); 5 Feb 2013 17:09:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:09:18 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15H9D2e002122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:09:14 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
	r15H9CU3004185
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:09:13 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
	r15H9CYt002670; Tue, 5 Feb 2013 11:09:12 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:09:11 -0800
Date: Tue, 5 Feb 2013 12:09:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205170900.GG2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com, jbeulich@suse.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 31, 2013 at 02:47:03PM +0000, Wei Liu wrote:
> Only do_upcall, debug_interrupt and unmask_evtchn are required.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 291 insertions(+)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 30ca620..d953e81 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -51,6 +51,9 @@
>  #include <xen/interface/hvm/hvm_op.h>
>  #include <xen/interface/hvm/params.h>
>  
> +/* Helper macro(s) */
> +#define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)

That really needs an explanation.
> +
>  /* N-level event channel, starting from 2 */
>  unsigned int evtchn_level = 2;
>  EXPORT_SYMBOL_GPL(evtchn_level);
> @@ -61,6 +64,9 @@ EXPORT_SYMBOL_GPL(nr_event_channels);
>  static unsigned long *evtchn_pending;
>  static unsigned long *evtchn_mask;
>  
> +/* 2nd level selector for 3-level event channel */

And that '8' there needs a #define

> +static DEFINE_PER_CPU(unsigned long[sizeof(unsigned long) * 8], evtchn_sel_l2);
> +
>  /*
>   * This lock protects updates to the following mapping and reference-count
>   * arrays. The lock does not need to be acquired to read the mapping tables.
> @@ -396,6 +402,28 @@ static inline void __unmask_local_port_l2(int port)
>  		vcpu_info->evtchn_upcall_pending = 1;
>  }
>  
> +static inline void __unmask_local_port_l3(int port)
> +{
> +	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> +	int cpu = smp_processor_id();
> +	unsigned int l1bit = port >> (LONG_BITORDER << 1);
> +	unsigned int l2bit = port >> LONG_BITORDER;
> +
> +	sync_clear_bit(port, &evtchn_mask[0]);
> +
> +	/*
> +	 * The following is basically the equivalent of
> +	 * 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> +	 * the interrupt edge' if the channel is masked.
> +	 */
> +	if (sync_test_bit(port, &evtchn_pending[0]) &&
> +	    !sync_test_and_set_bit(l2bit,
> +				   &per_cpu(evtchn_sel_l2, cpu)[0]) &&
> +	    !sync_test_and_set_bit(l1bit,
> +				   &vcpu_info->evtchn_pending_sel))
> +		vcpu_info->evtchn_upcall_pending = 1;
> +}
> +
>  static void unmask_evtchn(int port)
>  {
>  	unsigned int cpu = get_cpu();
> @@ -411,6 +439,9 @@ static void unmask_evtchn(int port)
>  		case 2:
>  			__unmask_local_port_l2(port);
>  			break;
> +		case 3:
> +			__unmask_local_port_l3(port);
> +			break;
>  		default:
>  			BUG();
>  		}
> @@ -1185,6 +1216,7 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
>  }
>  
>  static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id);
> +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id);
>  
>  irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
> @@ -1215,6 +1247,9 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  	case 2:
>  		rc = xen_debug_interrupt_l2(irq, dev_id);
>  		break;
> +	case 3:
> +		rc = xen_debug_interrupt_l3(irq, dev_id);
> +		break;
>  	default:
>  		BUG();
>  	}
> @@ -1285,8 +1320,109 @@ static irqreturn_t xen_debug_interrupt_l2(int irq, void *dev_id)
>  	return IRQ_HANDLED;
>  }
>  
> +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
> +{
> +	int cpu = smp_processor_id();
> +	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
> +	int i;
> +	struct vcpu_info *v;
> +
> +	v = per_cpu(xen_vcpu, cpu);
> +
> +	printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--)
> +		if (evtchn_pending[i] != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)sizeof(evtchn_pending[0])*2,
> +			       evtchn_pending[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--)
> +		if (evtchn_mask[i] != ~0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)sizeof(evtchn_mask[0])*2,
> +			       evtchn_mask[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--)
> +		if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)(sizeof(evtchn_mask[0])*2),
> +			       evtchn_pending[i] & ~evtchn_mask[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
> +	for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
> +		if (cpu_evtchn[i] != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)(sizeof(cpu_evtchn[0])*2),
> +			       cpu_evtchn[i]);
> +		}
> +
> +	printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
> +	for (i = nr_elems-1; i >= 0; i--) {
> +		unsigned long pending = evtchn_pending[i]
> +			& ~evtchn_mask[i]
> +			& cpu_evtchn[i];
> +		if (pending != 0UL) {
> +			printk(KERN_DEBUG " word index %d %0*lx\n",
> +			       i,
> +			       (int)(sizeof(evtchn_mask[0])*2),
> +			       pending);
> +		}
> +	}
> +
> +	printk(KERN_DEBUG "\npending list:\n");
> +	for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
> +		if (sync_test_bit(i, evtchn_pending)) {
> +			int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
> +			int word_idx_l2 = i / BITS_PER_LONG;
> +			printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
> +			       cpu_from_evtchn(i), i,
> +			       evtchn_to_irq[i],
> +			       !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +			       ? "" : " l1-clear",
> +			       !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
> +			       ? "" : " l2-clear",
> +			       sync_test_bit(i, evtchn_mask)
> +			       ? "" : " globally-masked",
> +			       sync_test_bit(i, cpu_evtchn)
> +			       ? "" : " locally-masked");
> +		}
> +	}
> +
> +	return IRQ_HANDLED;

Um, there has to be a way to fold the most common cases of the L2 and L3
of this function in one?

> +}
> +
> +/* The following per-cpu variables are used to save current state of event
> + * processing loop.
> + *
> + * 2-level event channel:
> + *  current_word_idx is the bit index in L1 selector indicating the currently
> + *  processing word in shared bitmap.
> + *  current_bit_idx is the bit index in the currently processing word in shared
> + *  bitmap.
> + *  N.B. current_word_idx_l2 is not used.
> + *
> + * 3-level event channel:
> + *  current_word_idx is the bit index in L1 selector indicating the currently
> + *  processing word in L2 selector.
> + *  current_word_idx_l2 is the bit index in L2 selector word indicating the
> + *  currently processing word in shared bitmap.
> + *  current_bit_idx is the bit index in the currently processing word in shared
> + *  bitmap.
> + *
> + */
>  static DEFINE_PER_CPU(unsigned, xed_nesting_count);
>  static DEFINE_PER_CPU(unsigned int, current_word_idx);
> +static DEFINE_PER_CPU(unsigned int, current_word_idx_l2);
>  static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>  
>  /*
> @@ -1409,6 +1545,155 @@ out:
>  	put_cpu();
>  }
>  
> +/*
> + * In the 3-level event channel implementation, the first level is a
> + * bitset of words which contain pending bits in the second level.
> + * The second level is another bitsets which contain pending bits in
> + * the third level.  The third level is a bit set of pending events
> + * themselves.
> + */
> +static void __xen_evtchn_do_upcall_l3(void)
> +{
> +	struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> +	unsigned count;
> +	int start_word_idx_l1, start_word_idx_l2, start_bit_idx;
> +	int word_idx_l1, word_idx_l2, bit_idx;
> +	int i, j;
> +	int cpu = get_cpu();
> +
> +	do {
> +		unsigned long pending_words_l1;
> +
> +		vcpu_info->evtchn_upcall_pending = 0;
> +
> +		if (__this_cpu_inc_return(xed_nesting_count) - 1)
> +			goto out;
> +#ifndef CONFIG_X86
> +		/* No need for a barrier -- XCHG is a barrier on x86. */
> +		/* Clear master flag /before/ clearing selector flag. */
> +		wmb();
> +#endif
> +		/* here we get l1 pending selector */
> +		pending_words_l1 = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +
> +		start_word_idx_l1 = __this_cpu_read(current_word_idx);
> +		start_word_idx_l2 = __this_cpu_read(current_word_idx_l2);
> +		start_bit_idx = __this_cpu_read(current_bit_idx);
> +
> +		word_idx_l1 = start_word_idx_l1;
> +
> +		/* loop through l1, try to pick up l2 */
> +		for (i = 0; pending_words_l1 != 0; i++) {
> +			unsigned long words_l1;
> +			unsigned long pending_words_l2;
> +
> +			words_l1 = MASK_LSBS(pending_words_l1, word_idx_l1);
> +
> +			if (words_l1 == 0) {
> +				word_idx_l1 = 0;
> +				start_word_idx_l2 = 0;
> +				continue;
> +			}
> +
> +			word_idx_l1 = __ffs(words_l1);
> +
> +			pending_words_l2 =
> +				xchg(&per_cpu(evtchn_sel_l2, cpu)[word_idx_l1],
> +				     0);
> +
> +			word_idx_l2 = 0;
> +			if (word_idx_l1 == start_word_idx_l1) {
> +				if (i == 0)
> +					word_idx_l2 = start_word_idx_l2;
> +				else
> +					word_idx_l2 &= (1UL << start_word_idx_l2) - 1;
> +			}
> +
> +			for (j = 0; pending_words_l2 != 0; j++) {
> +				unsigned long pending_bits;
> +				unsigned long words_l2;
> +				unsigned long idx;
> +
> +				words_l2 = MASK_LSBS(pending_words_l2,
> +						     word_idx_l2);
> +
> +				if (words_l2 == 0) {
> +					word_idx_l2 = 0;
> +					bit_idx = 0;
> +					continue;
> +				}
> +
> +				word_idx_l2 = __ffs(words_l2);
> +
> +				idx = word_idx_l1*BITS_PER_LONG+word_idx_l2;
> +				pending_bits =
> +					active_evtchns(cpu, idx);
> +
> +				bit_idx = 0;
> +				if (word_idx_l2 == start_word_idx_l2) {
> +					if (j == 0)
> +						bit_idx = start_bit_idx;
> +					else
> +						bit_idx &= (1UL<<start_bit_idx)-1;
> +				}
> +
> +				/* process port */
> +				do {
> +					unsigned long bits;
> +					int port, irq;
> +					struct irq_desc *desc;
> +
> +					bits = MASK_LSBS(pending_bits, bit_idx);
> +
> +					if (bits == 0)
> +						break;
> +
> +					bit_idx = __ffs(bits);
> +
> +					port = (word_idx_l1 << (LONG_BITORDER << 1)) +
> +						(word_idx_l2 << LONG_BITORDER) +
> +						bit_idx;
> +
> +					irq = evtchn_to_irq[port];
> +
> +					if (irq != -1) {
> +						desc = irq_to_desc(irq);
> +						if (desc)
> +							generic_handle_irq_desc(irq, desc);
> +					}
> +
> +					bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +
> +					__this_cpu_write(current_bit_idx, bit_idx);
> +					__this_cpu_write(current_word_idx_l2,
> +							 bit_idx ? word_idx_l2 :
> +							 (word_idx_l2+1) % BITS_PER_LONG);
> +					__this_cpu_write(current_word_idx_l2,
> +							 word_idx_l2 ? word_idx_l1 :
> +							 (word_idx_l1+1) % BITS_PER_LONG);
> +				} while (bit_idx != 0);
> +
> +				if ((word_idx_l2 != start_word_idx_l2) || (j != 0))
> +					pending_words_l2 &= ~(1UL << word_idx_l2);
> +
> +				word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
> +			}

This is a bit of a complex code. Is there any way you can split this up
in smaller inline functions?
> +
> +			if ((word_idx_l1 != start_word_idx_l1) || (i != 0))
> +				pending_words_l1 &= ~(1UL << word_idx_l1);
> +
> +			word_idx_l1 = (word_idx_l1 + 1) % BITS_PER_LONG;
> +		}
> +
> +		BUG_ON(!irqs_disabled());
> +		count = __this_cpu_read(xed_nesting_count);
> +		__this_cpu_write(xed_nesting_count, 0);
> +	} while (count != 1 || vcpu_info->evtchn_upcall_pending);
> +
> +out:
> +	put_cpu();
> +}
> +
>  void xen_evtchn_do_upcall(struct pt_regs *regs)
>  {
>  	struct pt_regs *old_regs = set_irq_regs(regs);
> @@ -1420,6 +1705,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  	case 2:
>  		__xen_evtchn_do_upcall_l2();
>  		break;
> +	case 3:
> +		__xen_evtchn_do_upcall_l3();
> +		break;
>  	default:
>  		BUG();
>  	}
> @@ -1434,6 +1722,9 @@ void xen_hvm_evtchn_do_upcall(void)
>  	case 2:
>  		__xen_evtchn_do_upcall_l2();
>  		break;
> +	case 3:
> +		__xen_evtchn_do_upcall_l3();
> +		break;
>  	default:
>  		BUG();
>  	}
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:15:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:15: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 1U2m7K-00006X-3b; Tue, 05 Feb 2013 17:15:34 +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 1U2m7I-000060-It
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:15:32 +0000
Received: from [85.158.137.99:47826] by server-11.bemta-3.messagelabs.com id
	33/02-10249-33E31115; Tue, 05 Feb 2013 17:15:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360084474!16927934!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22410 invoked from network); 5 Feb 2013 17:14:36 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 17:14:36 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15HEVhw008725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:14:32 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
	r15HEV7b018391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:14:31 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
	r15HEVFC011745; Tue, 5 Feb 2013 11:14:31 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:14:31 -0800
Date: Tue, 5 Feb 2013 12:14:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205171422.GH2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
	<20130205165550.GC2187@konrad-lan.dumpdata.com>
	<1360083900.7477.154.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360083900.7477.154.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, 2013 at 05:05:00PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > > +
> > > +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> > > +	if (rc) {
> > > +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> > > +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> > > +		evtchn_pending = NULL;
> > > +		evtchn_mask = NULL;
> > > +	}
> > > +
> > > +out:
> > > +	kfree(_evtchn_pending);
> > > +	kfree(_evtchn_mask);
> > > +	kfree(l2sel_mfns);
> > > +	kfree(l2sel_offsets);
> > 
> > So it is OK to just free it even on success??
> 
> Yes. They are only used for registration.

OK. Might want to provide a comment saying that right above the
__ALLOC_PAGES. Hm, might even call the macro 'ALLOC_TMP_PAGES'

> 
> And for all the above stuffs regarding comments, I will fix them in
> later post.
> 
> 
> Wei.
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:15:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:15: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 1U2m7K-00006X-3b; Tue, 05 Feb 2013 17:15:34 +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 1U2m7I-000060-It
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:15:32 +0000
Received: from [85.158.137.99:47826] by server-11.bemta-3.messagelabs.com id
	33/02-10249-33E31115; Tue, 05 Feb 2013 17:15:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360084474!16927934!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22410 invoked from network); 5 Feb 2013 17:14:36 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 17:14:36 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15HEVhw008725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:14:32 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
	r15HEV7b018391
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:14:31 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
	r15HEVFC011745; Tue, 5 Feb 2013 11:14:31 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:14:31 -0800
Date: Tue, 5 Feb 2013 12:14:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205171422.GH2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
	<20130205165550.GC2187@konrad-lan.dumpdata.com>
	<1360083900.7477.154.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360083900.7477.154.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/13] xen: introduce
	xen_event_channel_register_3level
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, 2013 at 05:05:00PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 16:55 +0000, Konrad Rzeszutek Wilk wrote:
> > > +
> > > +	rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, &reg);
> > > +	if (rc) {
> > > +		free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> > > +		free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> > > +		evtchn_pending = NULL;
> > > +		evtchn_mask = NULL;
> > > +	}
> > > +
> > > +out:
> > > +	kfree(_evtchn_pending);
> > > +	kfree(_evtchn_mask);
> > > +	kfree(l2sel_mfns);
> > > +	kfree(l2sel_offsets);
> > 
> > So it is OK to just free it even on success??
> 
> Yes. They are only used for registration.

OK. Might want to provide a comment saying that right above the
__ALLOC_PAGES. Hm, might even call the macro 'ALLOC_TMP_PAGES'

> 
> And for all the above stuffs regarding comments, I will fix them in
> later post.
> 
> 
> Wei.
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:20:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2mBe-0000ae-UE; Tue, 05 Feb 2013 17:20:02 +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 1U2mBd-0000aS-4Z
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:20:01 +0000
Received: from [85.158.137.99:33342] by server-10.bemta-3.messagelabs.com id
	06/1F-10609-04F31115; Tue, 05 Feb 2013 17:20:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360084797!11914140!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21415 invoked from network); 5 Feb 2013 17:19:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:19:59 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15HJt2W014996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:19:55 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
	r15HJsXN023711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:19:54 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
	r15HJrf1015992; Tue, 5 Feb 2013 11:19:53 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:19:53 -0800
Date: Tue, 5 Feb 2013 12:19:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205171938.GI2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
	<1360084131.7477.156.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360084131.7477.156.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, Feb 05, 2013 at 05:08:51PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > > Use global pointers in common operations to allow for better code sharing
> > > between N-level event channel.
> > >
> > > Functions which are not suitable for sharing are also taken care of.
> > >
> > > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> > >
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> > >  drivers/xen/evtchn.c |   12 ++--
> > >  include/xen/events.h |    2 +
> > >  3 files changed, 123 insertions(+), 71 deletions(-)
> > >
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 0679d27..4820a52 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -51,6 +51,16 @@
> > >  #include <xen/interface/hvm/hvm_op.h>
> > >  #include <xen/interface/hvm/params.h>
> > >
> > > +/* N-level event channel, starting from 2 */
> > > +unsigned int evtchn_level = 2;
> > 
> > What if the hypervisor does not support that? Shouldn't be by default
> > at 1?
> > 
> 
> the default implementation is 2 level. ;-)

I am looking at evtchn_pending and evtchn_mask in the 'struct
shared_info' (include/xen/interface/xen.h) and it is not obvious from
that. What am I missing? 

> 
> > > +EXPORT_SYMBOL_GPL(evtchn_level);
> > 
> > Prefix it please with 'xen'
> > 
> > > +unsigned int nr_event_channels;
> > > +EXPORT_SYMBOL_GPL(nr_event_channels);
> > 
> > Ditto here.
> >  
> 
> NP.
> 
> 
> Wei.
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:20:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2mBe-0000ae-UE; Tue, 05 Feb 2013 17:20:02 +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 1U2mBd-0000aS-4Z
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:20:01 +0000
Received: from [85.158.137.99:33342] by server-10.bemta-3.messagelabs.com id
	06/1F-10609-04F31115; Tue, 05 Feb 2013 17:20:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360084797!11914140!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21415 invoked from network); 5 Feb 2013 17:19:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 17:19:59 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15HJt2W014996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 17:19:55 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
	r15HJsXN023711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 17:19:54 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
	r15HJrf1015992; Tue, 5 Feb 2013 11:19:53 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 09:19:53 -0800
Date: Tue, 5 Feb 2013 12:19:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205171938.GI2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
	<1360084131.7477.156.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360084131.7477.156.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, Feb 05, 2013 at 05:08:51PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > > Use global pointers in common operations to allow for better code sharing
> > > between N-level event channel.
> > >
> > > Functions which are not suitable for sharing are also taken care of.
> > >
> > > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> > >
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> > >  drivers/xen/evtchn.c |   12 ++--
> > >  include/xen/events.h |    2 +
> > >  3 files changed, 123 insertions(+), 71 deletions(-)
> > >
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 0679d27..4820a52 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -51,6 +51,16 @@
> > >  #include <xen/interface/hvm/hvm_op.h>
> > >  #include <xen/interface/hvm/params.h>
> > >
> > > +/* N-level event channel, starting from 2 */
> > > +unsigned int evtchn_level = 2;
> > 
> > What if the hypervisor does not support that? Shouldn't be by default
> > at 1?
> > 
> 
> the default implementation is 2 level. ;-)

I am looking at evtchn_pending and evtchn_mask in the 'struct
shared_info' (include/xen/interface/xen.h) and it is not obvious from
that. What am I missing? 

> 
> > > +EXPORT_SYMBOL_GPL(evtchn_level);
> > 
> > Prefix it please with 'xen'
> > 
> > > +unsigned int nr_event_channels;
> > > +EXPORT_SYMBOL_GPL(nr_event_channels);
> > 
> > Ditto here.
> >  
> 
> NP.
> 
> 
> Wei.
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:20:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:20: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 1U2mC9-0000eW-Hq; Tue, 05 Feb 2013 17:20:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <youenn.gestin@grim-is-a-geek.fr>) id 1U2mC8-0000eM-Ne
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:20:33 +0000
Received: from [85.158.137.99:14000] by server-13.bemta-3.messagelabs.com id
	CA/88-20653-B5F31115; Tue, 05 Feb 2013 17:20:27 +0000
X-Env-Sender: youenn.gestin@grim-is-a-geek.fr
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360084816!20131028!1
X-Originating-IP: [87.98.171.146]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26484 invoked from network); 5 Feb 2013 17:20:18 -0000
Received: from 9.mo6.mail-out.ovh.net (HELO mo6.mail-out.ovh.net)
	(87.98.171.146) by server-13.tower-217.messagelabs.com with SMTP;
	5 Feb 2013 17:20:16 -0000
Received: from mail313.ha.ovh.net (b9.ovh.net [213.186.33.59])
	by mo6.mail-out.ovh.net (Postfix) with SMTP id D4D05FF855B
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 18:31:06 +0100 (CET)
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 5 Feb 2013 17:20:15 -0000
Received: from ns0.ovh.net (HELO ssl0.ovh.net) (213.186.33.20)
	by ns0.ovh.net with SMTP; 5 Feb 2013 17:20:15 -0000
Received: from 15-39-190-109.dsl.ovh.fr ([109.190.39.15]) by ssl0.ovh.net
	with HTTP (HTTP/1.1 POST); Tue, 05 Feb 2013 18:20:15 +0100
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 18:20:15 +0100
From: youenn.gestin@grim-is-a-geek.fr
To: <xen-devel@lists.xen.org>
X-Ovh-Mailout: 178.32.228.6 (mo6.mail-out.ovh.net)
In-Reply-To: <1359504363.78244.YahooMailNeo@web172006.mail.ir2.yahoo.com>
References: <1359504363.78244.YahooMailNeo@web172006.mail.ir2.yahoo.com>
Message-ID: <2ab76ab077c4c04288741310b5481028@grim-is-a-geek.fr>
X-Sender: youenn.gestin@grim-is-a-geek.fr
User-Agent: Roundcube Webmail/0.8.4
X-Originating-IP: 109.190.39.15
X-Ovh-Tracer-Id: 4561864948182977319
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeitddrtdefucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Subject: Re: [Xen-devel] Xen 4.3 unstables and Xen 4.2 patches for VGA
 PassThrough (NVIDIA)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1129596019097226222=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1129596019097226222==
Content-Type: multipart/alternative;
 boundary="=_a47bb415ed24ef7d2045009c200668fb"

--=_a47bb415ed24ef7d2045009c200668fb
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

 

Hello, 

I'm running a 64bit Win 7 vm with nvidia 310.90 on xen 4.2
with your patches and a 560 TI. 

Configuration : 

Primary graphic card
: MSI 560TI 1GB 

Secondary graphic card : IGFX 

Core i7-3770 

Xen
dom0 : Gentoo Kernel 3.6.6 

When you first boot to win7 after powering
up your dom0, install 275.xx driver. 

Reboot, your VM should have a
full vga passtrhough. 

Then you could install any of the nvidia 3xx.xx
and use it. 

If you reboot the VM there will be no acceleration, so
reinstall the 275.xx, reboot and reinstall the 3xx.xx 

The only thing
is that i still can't use more than 3096Mb without encountering a BSOD
at boot. 

My grub config : 

menuentry 'Gentoo GNU/Linux, with Xen
hypervisor' --class gentoo --class gnu-linux --class gnu --class os
--class xen $menuentry_id_option
'xen-gnulinux-simple-7262b140-e026-4b53-bc6b-2ac1c1cc4538' {
 insmod
part_gpt
 insmod ext2
 set root='hd0,gpt1'
 echo 'Loading Xen xen ...'

multiboot /xen.gz iommu=1 intel_iommu=1 iommu_inclusive_mapping=1
dom0_mem=4G,max:4G dom0_max_vcpus=2 dom0_vcpus_pin
 module
/vmlinuz-3.6.6-gentoo placeholder root=/dev/sda2 nomodeset
xen-pciback.passthrough=1 i915.modeset=1
'pci=resource_aligment=01:00.0;01:00.1;00:14.0;00:1a.a' softlevel=xen
xen-pciback.hide(01:00.0)(01:00.1)(00:1a.0)(00:14.0) 

}

My VM config :


 name='midgard'
 vcpus="6"
 maxvcpus=6
 cpus="all"
 builder='hvm'

memory=3096
 on_poweroff='destroy'
 on_reboot='restart'

on_crash='destroy'
 vif=['bridge=br0,mac=00:16:3e:0b:f9:db']
 boot='c'

acpi=1
 apic=1
 viridian=1
 stdvga=0
 vnc=1
 vnclisten='0.0.0.0'

vncdisplay=0
 vncunused=1
 vncpasswd=""
 sdl=0
 gfx_passthru=1
 usb=0

#usbdevice="tablet"
 pci=['01:00.0','01:00.1','00:14.0','00:1a.0']
#passtrough of gfx card, hdmi sound from gfx card and 2 usb
controler

disk = [
'phy:/dev/sdb,hda,w']

xen_extended_power_mgmt=1
pae=1
hap =
1
keymap='fr'
xen_platform_pci= 1
pci_msitranslate = 0
pci_power_mgmt =
1
acpi_s3 = 1
acpi_s4 = 1
hpet = 1 

Hope it could help ! 

Regards.


Youenn. 

Le 30.01.2013 01:06, David TECHER a écrit : 

> Hi,
> 
> You
can find all historical details and download links of these patches both
Xen 4.3 and Xen 4.2 using the following url
> 
>
http://www.davidgis.fr/documentation/Xen_VGA_PassThrough/doc.html
> 
>
Technical details to install those patches could be found on the mailing
lists or google....
> 
> It takes me a lot of time to maintain those
patches: test several changesets and so on
> 
> Using these patches
depends on your hardwares. There may be several issues depending on your
own hardware.
> 
> Thanks.
> 
> David.
> 
>
_______________________________________________
> Xen-devel mailing
list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel [1]




Links:
------
[1] http://lists.xen.org/xen-devel

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>Hello,</p>
<p>I'm running a 64bit Win 7 vm with nvidia 310.90 on xen 4.2 with your pat=
ches and a 560 TI.</p>
<p>&nbsp;</p>
<p>Configuration :</p>
<p>Primary graphic card : MSI 560TI 1GB</p>
<p>Secondary graphic card : IGFX</p>
<p>Core &nbsp;i7-3770</p>
<p>Xen dom0 : Gentoo Kernel 3.6.6</p>
<p>&nbsp;</p>
<p>When you first boot to win7 after powering up your dom0, install 275.xx =
driver.</p>
<p>Reboot, your VM should have a full vga passtrhough.</p>
<p>Then you could install any of the nvidia 3xx.xx and use it.</p>
<p>If you reboot the VM there will be no acceleration, so reinstall the 275=
=2Exx, reboot and reinstall the 3xx.xx</p>
<p>&nbsp;</p>
<p>The only thing is that i still can't use more than 3096Mb without encoun=
tering a BSOD at boot.</p>
<p>&nbsp;</p>
<p>My grub config :</p>
<p>&nbsp;</p>
<p>menuentry 'Gentoo GNU/Linux, with Xen hypervisor' --class gentoo --class=
 gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnu=
linux-simple-7262b140-e026-4b53-bc6b-2ac1c1cc4538' {<br />&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; insmod part_gpt<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; insmod ext2<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
set root=3D'hd0,gpt1'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; echo&=
nbsp;&nbsp;&nbsp; 'Loading Xen xen ...'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; multiboot /xen.gz iommu=3D1 intel_iommu=3D1 iommu_inclusive_ma=
pping=3D1 dom0_mem=3D4G,max:4G dom0_max_vcpus=3D2 dom0_vcpus_pin<br />&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; module /vmlinuz-3.6.6-gentoo placehol=
der root=3D/dev/sda2 nomodeset xen-pciback.passthrough=3D1 i915.modeset=3D1=
 'pci=3Dresource_aligment=3D01:00.0;01:00.1;00:14.0;00:1a.a' softlevel=3Dxe=
n xen-pciback.hide(01:00.0)(01:00.1)(00:1a.0)(00:14.0)</p>
<p>}<br /><br /></p>
<p>My VM config :</p>
<p>&nbsp;name=3D'midgard'<br />&nbsp;vcpus=3D"6"<br />&nbsp;maxvcpus=3D6<br=
 />&nbsp;cpus=3D"all"<br />&nbsp;builder=3D'hvm'<br />&nbsp;memory=3D3096<b=
r />&nbsp;on_poweroff=3D'destroy'<br />&nbsp;on_reboot=3D'restart'<br />&nb=
sp;on_crash=3D'destroy'<br />&nbsp;vif=3D['bridge=3Dbr0,mac=3D00:16:3e:0b:f=
9:db']<br />&nbsp;boot=3D'c'<br />&nbsp;acpi=3D1<br />&nbsp;apic=3D1<br />&=
nbsp;viridian=3D1<br />&nbsp;stdvga=3D0<br />&nbsp;vnc=3D1<br />&nbsp;vncli=
sten=3D'0.0.0.0'<br />&nbsp;vncdisplay=3D0<br />&nbsp;vncunused=3D1<br />&n=
bsp;vncpasswd=3D""<br />&nbsp;sdl=3D0<br />&nbsp;gfx_passthru=3D1<br />&nbs=
p;usb=3D0<br />&nbsp;#usbdevice=3D"tablet"<br />&nbsp;pci=3D['01:00.0','01:=
00.1','00:14.0','00:1a.0'] #passtrough of gfx card, hdmi sound from gfx car=
d and 2 usb controler<br /><br />disk =3D [ 'phy:/dev/sdb,hda,w']<br /><br =
/>xen_extended_power_mgmt=3D1<br />pae=3D1<br />hap =3D 1<br />keymap=3D'fr=
'<br />xen_platform_pci=3D 1<br />pci_msitranslate =3D 0<br />pci_power_mgm=
t =3D 1<br />acpi_s3 =3D 1<br />acpi_s4 =3D 1<br />hpet =3D 1</p>
<p>&nbsp;</p>
<p>Hope it could help !</p>
<p>&nbsp;</p>
<p>Regards.</p>
<p>Youenn.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Le 30.01.2013 01:06, David TECHER a &eacute;crit&nbsp;:</p>
<blockquote type=3D"cite" style=3D"padding-left:5px; border-left:#1010ff 2p=
x solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignore=
d --><!-- meta ignored -->
<div style=3D"color: #000; background-color: #fff; font-family: times new r=
oman, new york, times, serif; font-size: 12pt;">Hi,<br /><br />You can find=
 all historical details and download links of these patches&nbsp; both Xen =
4.3 and Xen 4.2 using the following url<br /><br />http://www.davidgis.fr/d=
ocumentation/Xen_VGA_PassThrough/doc.html<br /><br />Technical details to i=
nstall those patches could be found on the mailing lists or google....<br /=
><br />It takes me a lot of time to maintain those patches: test several ch=
angesets and so on<br /><br />Using these patches depends on your hardwares=
=2E There may be several issues depending on your own hardware.<br /><br />=
Thanks.<br /><br />David.<br /><br /><br /><br /><br />
<div>&nbsp;</div>
<!-- script not allowed --></div>
<!-- html ignored --><br />
<pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</=
a>
</pre>
</blockquote>
<p>&nbsp;</p>
<div>&nbsp;</div>
</body></html>

--=_a47bb415ed24ef7d2045009c200668fb--



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

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

--===============1129596019097226222==--



From xen-devel-bounces@lists.xen.org Tue Feb 05 17:20:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:20: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 1U2mC9-0000eW-Hq; Tue, 05 Feb 2013 17:20:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <youenn.gestin@grim-is-a-geek.fr>) id 1U2mC8-0000eM-Ne
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:20:33 +0000
Received: from [85.158.137.99:14000] by server-13.bemta-3.messagelabs.com id
	CA/88-20653-B5F31115; Tue, 05 Feb 2013 17:20:27 +0000
X-Env-Sender: youenn.gestin@grim-is-a-geek.fr
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360084816!20131028!1
X-Originating-IP: [87.98.171.146]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26484 invoked from network); 5 Feb 2013 17:20:18 -0000
Received: from 9.mo6.mail-out.ovh.net (HELO mo6.mail-out.ovh.net)
	(87.98.171.146) by server-13.tower-217.messagelabs.com with SMTP;
	5 Feb 2013 17:20:16 -0000
Received: from mail313.ha.ovh.net (b9.ovh.net [213.186.33.59])
	by mo6.mail-out.ovh.net (Postfix) with SMTP id D4D05FF855B
	for <xen-devel@lists.xen.org>; Tue,  5 Feb 2013 18:31:06 +0100 (CET)
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 5 Feb 2013 17:20:15 -0000
Received: from ns0.ovh.net (HELO ssl0.ovh.net) (213.186.33.20)
	by ns0.ovh.net with SMTP; 5 Feb 2013 17:20:15 -0000
Received: from 15-39-190-109.dsl.ovh.fr ([109.190.39.15]) by ssl0.ovh.net
	with HTTP (HTTP/1.1 POST); Tue, 05 Feb 2013 18:20:15 +0100
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 18:20:15 +0100
From: youenn.gestin@grim-is-a-geek.fr
To: <xen-devel@lists.xen.org>
X-Ovh-Mailout: 178.32.228.6 (mo6.mail-out.ovh.net)
In-Reply-To: <1359504363.78244.YahooMailNeo@web172006.mail.ir2.yahoo.com>
References: <1359504363.78244.YahooMailNeo@web172006.mail.ir2.yahoo.com>
Message-ID: <2ab76ab077c4c04288741310b5481028@grim-is-a-geek.fr>
X-Sender: youenn.gestin@grim-is-a-geek.fr
User-Agent: Roundcube Webmail/0.8.4
X-Originating-IP: 109.190.39.15
X-Ovh-Tracer-Id: 4561864948182977319
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeitddrtdefucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Subject: Re: [Xen-devel] Xen 4.3 unstables and Xen 4.2 patches for VGA
 PassThrough (NVIDIA)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1129596019097226222=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1129596019097226222==
Content-Type: multipart/alternative;
 boundary="=_a47bb415ed24ef7d2045009c200668fb"

--=_a47bb415ed24ef7d2045009c200668fb
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

 

Hello, 

I'm running a 64bit Win 7 vm with nvidia 310.90 on xen 4.2
with your patches and a 560 TI. 

Configuration : 

Primary graphic card
: MSI 560TI 1GB 

Secondary graphic card : IGFX 

Core i7-3770 

Xen
dom0 : Gentoo Kernel 3.6.6 

When you first boot to win7 after powering
up your dom0, install 275.xx driver. 

Reboot, your VM should have a
full vga passtrhough. 

Then you could install any of the nvidia 3xx.xx
and use it. 

If you reboot the VM there will be no acceleration, so
reinstall the 275.xx, reboot and reinstall the 3xx.xx 

The only thing
is that i still can't use more than 3096Mb without encountering a BSOD
at boot. 

My grub config : 

menuentry 'Gentoo GNU/Linux, with Xen
hypervisor' --class gentoo --class gnu-linux --class gnu --class os
--class xen $menuentry_id_option
'xen-gnulinux-simple-7262b140-e026-4b53-bc6b-2ac1c1cc4538' {
 insmod
part_gpt
 insmod ext2
 set root='hd0,gpt1'
 echo 'Loading Xen xen ...'

multiboot /xen.gz iommu=1 intel_iommu=1 iommu_inclusive_mapping=1
dom0_mem=4G,max:4G dom0_max_vcpus=2 dom0_vcpus_pin
 module
/vmlinuz-3.6.6-gentoo placeholder root=/dev/sda2 nomodeset
xen-pciback.passthrough=1 i915.modeset=1
'pci=resource_aligment=01:00.0;01:00.1;00:14.0;00:1a.a' softlevel=xen
xen-pciback.hide(01:00.0)(01:00.1)(00:1a.0)(00:14.0) 

}

My VM config :


 name='midgard'
 vcpus="6"
 maxvcpus=6
 cpus="all"
 builder='hvm'

memory=3096
 on_poweroff='destroy'
 on_reboot='restart'

on_crash='destroy'
 vif=['bridge=br0,mac=00:16:3e:0b:f9:db']
 boot='c'

acpi=1
 apic=1
 viridian=1
 stdvga=0
 vnc=1
 vnclisten='0.0.0.0'

vncdisplay=0
 vncunused=1
 vncpasswd=""
 sdl=0
 gfx_passthru=1
 usb=0

#usbdevice="tablet"
 pci=['01:00.0','01:00.1','00:14.0','00:1a.0']
#passtrough of gfx card, hdmi sound from gfx card and 2 usb
controler

disk = [
'phy:/dev/sdb,hda,w']

xen_extended_power_mgmt=1
pae=1
hap =
1
keymap='fr'
xen_platform_pci= 1
pci_msitranslate = 0
pci_power_mgmt =
1
acpi_s3 = 1
acpi_s4 = 1
hpet = 1 

Hope it could help ! 

Regards.


Youenn. 

Le 30.01.2013 01:06, David TECHER a écrit : 

> Hi,
> 
> You
can find all historical details and download links of these patches both
Xen 4.3 and Xen 4.2 using the following url
> 
>
http://www.davidgis.fr/documentation/Xen_VGA_PassThrough/doc.html
> 
>
Technical details to install those patches could be found on the mailing
lists or google....
> 
> It takes me a lot of time to maintain those
patches: test several changesets and so on
> 
> Using these patches
depends on your hardwares. There may be several issues depending on your
own hardware.
> 
> Thanks.
> 
> David.
> 
>
_______________________________________________
> Xen-devel mailing
list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel [1]




Links:
------
[1] http://lists.xen.org/xen-devel

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>Hello,</p>
<p>I'm running a 64bit Win 7 vm with nvidia 310.90 on xen 4.2 with your pat=
ches and a 560 TI.</p>
<p>&nbsp;</p>
<p>Configuration :</p>
<p>Primary graphic card : MSI 560TI 1GB</p>
<p>Secondary graphic card : IGFX</p>
<p>Core &nbsp;i7-3770</p>
<p>Xen dom0 : Gentoo Kernel 3.6.6</p>
<p>&nbsp;</p>
<p>When you first boot to win7 after powering up your dom0, install 275.xx =
driver.</p>
<p>Reboot, your VM should have a full vga passtrhough.</p>
<p>Then you could install any of the nvidia 3xx.xx and use it.</p>
<p>If you reboot the VM there will be no acceleration, so reinstall the 275=
=2Exx, reboot and reinstall the 3xx.xx</p>
<p>&nbsp;</p>
<p>The only thing is that i still can't use more than 3096Mb without encoun=
tering a BSOD at boot.</p>
<p>&nbsp;</p>
<p>My grub config :</p>
<p>&nbsp;</p>
<p>menuentry 'Gentoo GNU/Linux, with Xen hypervisor' --class gentoo --class=
 gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnu=
linux-simple-7262b140-e026-4b53-bc6b-2ac1c1cc4538' {<br />&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; insmod part_gpt<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; insmod ext2<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
set root=3D'hd0,gpt1'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; echo&=
nbsp;&nbsp;&nbsp; 'Loading Xen xen ...'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; multiboot /xen.gz iommu=3D1 intel_iommu=3D1 iommu_inclusive_ma=
pping=3D1 dom0_mem=3D4G,max:4G dom0_max_vcpus=3D2 dom0_vcpus_pin<br />&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; module /vmlinuz-3.6.6-gentoo placehol=
der root=3D/dev/sda2 nomodeset xen-pciback.passthrough=3D1 i915.modeset=3D1=
 'pci=3Dresource_aligment=3D01:00.0;01:00.1;00:14.0;00:1a.a' softlevel=3Dxe=
n xen-pciback.hide(01:00.0)(01:00.1)(00:1a.0)(00:14.0)</p>
<p>}<br /><br /></p>
<p>My VM config :</p>
<p>&nbsp;name=3D'midgard'<br />&nbsp;vcpus=3D"6"<br />&nbsp;maxvcpus=3D6<br=
 />&nbsp;cpus=3D"all"<br />&nbsp;builder=3D'hvm'<br />&nbsp;memory=3D3096<b=
r />&nbsp;on_poweroff=3D'destroy'<br />&nbsp;on_reboot=3D'restart'<br />&nb=
sp;on_crash=3D'destroy'<br />&nbsp;vif=3D['bridge=3Dbr0,mac=3D00:16:3e:0b:f=
9:db']<br />&nbsp;boot=3D'c'<br />&nbsp;acpi=3D1<br />&nbsp;apic=3D1<br />&=
nbsp;viridian=3D1<br />&nbsp;stdvga=3D0<br />&nbsp;vnc=3D1<br />&nbsp;vncli=
sten=3D'0.0.0.0'<br />&nbsp;vncdisplay=3D0<br />&nbsp;vncunused=3D1<br />&n=
bsp;vncpasswd=3D""<br />&nbsp;sdl=3D0<br />&nbsp;gfx_passthru=3D1<br />&nbs=
p;usb=3D0<br />&nbsp;#usbdevice=3D"tablet"<br />&nbsp;pci=3D['01:00.0','01:=
00.1','00:14.0','00:1a.0'] #passtrough of gfx card, hdmi sound from gfx car=
d and 2 usb controler<br /><br />disk =3D [ 'phy:/dev/sdb,hda,w']<br /><br =
/>xen_extended_power_mgmt=3D1<br />pae=3D1<br />hap =3D 1<br />keymap=3D'fr=
'<br />xen_platform_pci=3D 1<br />pci_msitranslate =3D 0<br />pci_power_mgm=
t =3D 1<br />acpi_s3 =3D 1<br />acpi_s4 =3D 1<br />hpet =3D 1</p>
<p>&nbsp;</p>
<p>Hope it could help !</p>
<p>&nbsp;</p>
<p>Regards.</p>
<p>Youenn.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Le 30.01.2013 01:06, David TECHER a &eacute;crit&nbsp;:</p>
<blockquote type=3D"cite" style=3D"padding-left:5px; border-left:#1010ff 2p=
x solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignore=
d --><!-- meta ignored -->
<div style=3D"color: #000; background-color: #fff; font-family: times new r=
oman, new york, times, serif; font-size: 12pt;">Hi,<br /><br />You can find=
 all historical details and download links of these patches&nbsp; both Xen =
4.3 and Xen 4.2 using the following url<br /><br />http://www.davidgis.fr/d=
ocumentation/Xen_VGA_PassThrough/doc.html<br /><br />Technical details to i=
nstall those patches could be found on the mailing lists or google....<br /=
><br />It takes me a lot of time to maintain those patches: test several ch=
angesets and so on<br /><br />Using these patches depends on your hardwares=
=2E There may be several issues depending on your own hardware.<br /><br />=
Thanks.<br /><br />David.<br /><br /><br /><br /><br />
<div>&nbsp;</div>
<!-- script not allowed --></div>
<!-- html ignored --><br />
<pre>_______________________________________________
Xen-devel mailing list
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</=
a>
</pre>
</blockquote>
<p>&nbsp;</p>
<div>&nbsp;</div>
</body></html>

--=_a47bb415ed24ef7d2045009c200668fb--



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

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

--===============1129596019097226222==--



From xen-devel-bounces@lists.xen.org Tue Feb 05 17:23:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:23: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 1U2mFH-00015y-6o; Tue, 05 Feb 2013 17:23:47 +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 1U2mFF-00015l-PA
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:23:45 +0000
Received: from [193.109.254.147:23536] by server-16.bemta-14.messagelabs.com
	id AF/2D-25906-02041115; Tue, 05 Feb 2013 17:23:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360085021!4075231!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10489 invoked from network); 5 Feb 2013 17:23:44 -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;
	5 Feb 2013 17:23:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6348436"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:23:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:23:21 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2mEr-0006gn-Nv;
	Tue, 05 Feb 2013 17:23:21 +0000
Message-ID: <1360085001.7477.166.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:23:21 +0000
In-Reply-To: <20130205171938.GI2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
	<1360084131.7477.156.camel@zion.uk.xensource.com>
	<20130205171938.GI2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, 2013-02-05 at 17:19 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 05, 2013 at 05:08:51PM +0000, Wei Liu wrote:
> > On Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > > > Use global pointers in common operations to allow for better code sharing
> > > > between N-level event channel.
> > > >
> > > > Functions which are not suitable for sharing are also taken care of.
> > > >
> > > > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> > > >
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > ---
> > > >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> > > >  drivers/xen/evtchn.c |   12 ++--
> > > >  include/xen/events.h |    2 +
> > > >  3 files changed, 123 insertions(+), 71 deletions(-)
> > > >
> > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > index 0679d27..4820a52 100644
> > > > --- a/drivers/xen/events.c
> > > > +++ b/drivers/xen/events.c
> > > > @@ -51,6 +51,16 @@
> > > >  #include <xen/interface/hvm/hvm_op.h>
> > > >  #include <xen/interface/hvm/params.h>
> > > >
> > > > +/* N-level event channel, starting from 2 */
> > > > +unsigned int evtchn_level = 2;
> > > 
> > > What if the hypervisor does not support that? Shouldn't be by default
> > > at 1?
> > > 
> > 
> > the default implementation is 2 level. ;-)
> 
> I am looking at evtchn_pending and evtchn_mask in the 'struct
> shared_info' (include/xen/interface/xen.h) and it is not obvious from
> that. What am I missing? 
> 

To avoid scanning the whole bitmap when doing upcall, every vcpu is
equipped with a selector - embedded in struct vcpu_info.

So it is a 2-level event lookup path.


Wei


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:23:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:23: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 1U2mFH-00015y-6o; Tue, 05 Feb 2013 17:23:47 +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 1U2mFF-00015l-PA
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:23:45 +0000
Received: from [193.109.254.147:23536] by server-16.bemta-14.messagelabs.com
	id AF/2D-25906-02041115; Tue, 05 Feb 2013 17:23:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360085021!4075231!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10489 invoked from network); 5 Feb 2013 17:23:44 -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;
	5 Feb 2013 17:23:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6348436"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:23:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:23:21 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2mEr-0006gn-Nv;
	Tue, 05 Feb 2013 17:23:21 +0000
Message-ID: <1360085001.7477.166.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:23:21 +0000
In-Reply-To: <20130205171938.GI2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
	<1360084131.7477.156.camel@zion.uk.xensource.com>
	<20130205171938.GI2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, 2013-02-05 at 17:19 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 05, 2013 at 05:08:51PM +0000, Wei Liu wrote:
> > On Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > > > Use global pointers in common operations to allow for better code sharing
> > > > between N-level event channel.
> > > >
> > > > Functions which are not suitable for sharing are also taken care of.
> > > >
> > > > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> > > >
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > ---
> > > >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> > > >  drivers/xen/evtchn.c |   12 ++--
> > > >  include/xen/events.h |    2 +
> > > >  3 files changed, 123 insertions(+), 71 deletions(-)
> > > >
> > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > index 0679d27..4820a52 100644
> > > > --- a/drivers/xen/events.c
> > > > +++ b/drivers/xen/events.c
> > > > @@ -51,6 +51,16 @@
> > > >  #include <xen/interface/hvm/hvm_op.h>
> > > >  #include <xen/interface/hvm/params.h>
> > > >
> > > > +/* N-level event channel, starting from 2 */
> > > > +unsigned int evtchn_level = 2;
> > > 
> > > What if the hypervisor does not support that? Shouldn't be by default
> > > at 1?
> > > 
> > 
> > the default implementation is 2 level. ;-)
> 
> I am looking at evtchn_pending and evtchn_mask in the 'struct
> shared_info' (include/xen/interface/xen.h) and it is not obvious from
> that. What am I missing? 
> 

To avoid scanning the whole bitmap when doing upcall, every vcpu is
equipped with a selector - embedded in struct vcpu_info.

So it is a 2-level event lookup path.


Wei


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:24:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:24: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 1U2mFJ-00016L-JX; Tue, 05 Feb 2013 17:23:49 +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 1U2mFH-00015v-B9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:23:47 +0000
Received: from [85.158.139.83:7831] by server-1.bemta-5.messagelabs.com id
	E4/18-29263-22041115; Tue, 05 Feb 2013 17:23:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360085021!30534458!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16761 invoked from network); 5 Feb 2013 17:23:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 17:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6036631"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:23:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:23:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2mFA-0006hP-Qd;
	Tue, 05 Feb 2013 17:23:40 +0000
Message-ID: <1360085020.7477.167.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:23:40 +0000
In-Reply-To: <20130205170006.GE2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Tue, 2013-02-05 at 17:00 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 31, 2013 at 02:46:58PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
> >  include/xen/interface/xen.h           |    9 ++++++++-
> >  2 files changed, 41 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
> > index f494292..9d8b9e7 100644
> > --- a/include/xen/interface/event_channel.h
> > +++ b/include/xen/interface/event_channel.h
> > @@ -190,6 +190,39 @@ struct evtchn_reset {
> >  };
> >  typedef struct evtchn_reset evtchn_reset_t;
> >  
> > +/*
> > + * EVTCHNOP_register_nlevel: Register N-level event channel
> > + * NOTES:
> > + *  1. Currently only 3-level is supported.
> > + *  2. Should fall back to 2-level if this call fails.
> > + */
> > +#define EVTCHNOP_register_nlevel 11
> > +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> > + * 256k event channels while 32 bit ones only need 1 page for 32k
> > + * event channels. */
> > +#define EVTCHN_MAX_L3_PAGES 8
> > +struct evtchn_register_3level {
> > +	/* IN parameters. */
> > +	uint32_t nr_pages; /* for evtchn_{pending,mask} */
> > +	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
> > +	GUEST_HANDLE(ulong) evtchn_pending;
> > +	GUEST_HANDLE(ulong) evtchn_mask;
> > +	GUEST_HANDLE(ulong) l2sel_mfns;
> > +	GUEST_HANDLE(ulong) l2sel_offsets;
> > +};
> > +typedef struct evtchn_register_3level evtchn_register_3level_t;
> > +DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
> > +
> > +struct evtchn_register_nlevel {
> > +	/* IN parameters. */
> > +	uint32_t level;
> > +	union {
> > +		evtchn_register_3level_t l3;
> > +	} u;
> > +};
> > +typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
> > +DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
> > +
> >  struct evtchn_op {
> >  	uint32_t cmd; /* EVTCHNOP_* */
> >  	union {
> > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > index a890804..5220e33 100644
> > --- a/include/xen/interface/xen.h
> > +++ b/include/xen/interface/xen.h
> > @@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> >  
> >  /*
> >   * Event channel endpoints per domain:
> > + * 2-level:
> >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> > + * 3-level:
> > + *  32k if a long is 32 bits; 256k if a long is 64 bits.
> >   */
> > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> 
> We did a bit of header change to make the ARM code always use 'unsinged
> long long' on 32-bit (so it is a nice 8-bytes) and 'unsigned long' on
> 64-bit. This was all done using the xen_pfn_t and xen_mfn_t typdefs.
> 
> Any chance you can do that here? That way on ARM - irregardless if it is
> 32-bit or 64-bit it is always of the 64-bit size?
> 

I don't think so. The reason to use unsigned long here is to guarantee
each selector (in 2-level case there is only L1 selector) fits into a
word.

> Or do we not care about the ARM case here?
> 

What do you mean? How would this definition affect ARM case?


Wei.

> > +#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
> > +#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > +#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
> > +#endif
> >  
> >  struct vcpu_time_info {
> >  	/*
> > -- 
> > 1.7.10.4
> > 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:24:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:24: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 1U2mFJ-00016L-JX; Tue, 05 Feb 2013 17:23:49 +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 1U2mFH-00015v-B9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:23:47 +0000
Received: from [85.158.139.83:7831] by server-1.bemta-5.messagelabs.com id
	E4/18-29263-22041115; Tue, 05 Feb 2013 17:23:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360085021!30534458!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16761 invoked from network); 5 Feb 2013 17:23:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 17:23:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6036631"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:23:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:23:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2mFA-0006hP-Qd;
	Tue, 05 Feb 2013 17:23:40 +0000
Message-ID: <1360085020.7477.167.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:23:40 +0000
In-Reply-To: <20130205170006.GE2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Tue, 2013-02-05 at 17:00 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 31, 2013 at 02:46:58PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
> >  include/xen/interface/xen.h           |    9 ++++++++-
> >  2 files changed, 41 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
> > index f494292..9d8b9e7 100644
> > --- a/include/xen/interface/event_channel.h
> > +++ b/include/xen/interface/event_channel.h
> > @@ -190,6 +190,39 @@ struct evtchn_reset {
> >  };
> >  typedef struct evtchn_reset evtchn_reset_t;
> >  
> > +/*
> > + * EVTCHNOP_register_nlevel: Register N-level event channel
> > + * NOTES:
> > + *  1. Currently only 3-level is supported.
> > + *  2. Should fall back to 2-level if this call fails.
> > + */
> > +#define EVTCHNOP_register_nlevel 11
> > +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> > + * 256k event channels while 32 bit ones only need 1 page for 32k
> > + * event channels. */
> > +#define EVTCHN_MAX_L3_PAGES 8
> > +struct evtchn_register_3level {
> > +	/* IN parameters. */
> > +	uint32_t nr_pages; /* for evtchn_{pending,mask} */
> > +	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
> > +	GUEST_HANDLE(ulong) evtchn_pending;
> > +	GUEST_HANDLE(ulong) evtchn_mask;
> > +	GUEST_HANDLE(ulong) l2sel_mfns;
> > +	GUEST_HANDLE(ulong) l2sel_offsets;
> > +};
> > +typedef struct evtchn_register_3level evtchn_register_3level_t;
> > +DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
> > +
> > +struct evtchn_register_nlevel {
> > +	/* IN parameters. */
> > +	uint32_t level;
> > +	union {
> > +		evtchn_register_3level_t l3;
> > +	} u;
> > +};
> > +typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
> > +DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
> > +
> >  struct evtchn_op {
> >  	uint32_t cmd; /* EVTCHNOP_* */
> >  	union {
> > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > index a890804..5220e33 100644
> > --- a/include/xen/interface/xen.h
> > +++ b/include/xen/interface/xen.h
> > @@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> >  
> >  /*
> >   * Event channel endpoints per domain:
> > + * 2-level:
> >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> > + * 3-level:
> > + *  32k if a long is 32 bits; 256k if a long is 64 bits.
> >   */
> > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> 
> We did a bit of header change to make the ARM code always use 'unsinged
> long long' on 32-bit (so it is a nice 8-bytes) and 'unsigned long' on
> 64-bit. This was all done using the xen_pfn_t and xen_mfn_t typdefs.
> 
> Any chance you can do that here? That way on ARM - irregardless if it is
> 32-bit or 64-bit it is always of the 64-bit size?
> 

I don't think so. The reason to use unsigned long here is to guarantee
each selector (in 2-level case there is only L1 selector) fits into a
word.

> Or do we not care about the ARM case here?
> 

What do you mean? How would this definition affect ARM case?


Wei.

> > +#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
> > +#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > +#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
> > +#endif
> >  
> >  struct vcpu_time_info {
> >  	/*
> > -- 
> > 1.7.10.4
> > 



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:30:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2mLJ-0001jT-GN; Tue, 05 Feb 2013 17:30:01 +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 1U2mLI-0001jO-Ph
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 17:30:00 +0000
Received: from [85.158.143.99:18099] by server-1.bemta-4.messagelabs.com id
	F2/0B-08839-79141115; Tue, 05 Feb 2013 17:29:59 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360085398!30953533!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31962 invoked from network); 5 Feb 2013 17:29:59 -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; 5 Feb 2013 17:29:59 -0000
Received: from saboo.goop.org (mf82036d0.tmodns.net [208.54.32.248])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 913B6876A;
	Tue,  5 Feb 2013 09:29:57 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 9BFC220133;
	Tue,  5 Feb 2013 09:29:53 -0800 (PST)
Message-ID: <51114191.7020406@goop.org>
Date: Tue, 05 Feb 2013 09:29:53 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Mao, Junjie" <junjie.mao@intel.com>
References: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38@SHSMSX101.ccr.corp.intel.com>
X-Enigmail-Version: 1.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] How can I run 3.x dom0 w/o PAE?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 02/04/2013 06:45 PM, Mao, Junjie wrote:
> I=92m now working in a Xen-based project where some drivers in the Dom0
> kernel (based on Linux 3.0) refuse to work with PAE. Do you know if it
> is possible to run 3.x kernel as non-PAE dom0 on Xen (any version is
> ok)? If so, how can I make it work? Many thanks in advance!

No, we removed non-PAE 32-bit operation a long time ago, and its not
coming back. What drivers don't work with PAE enabled? PAE has been more
or less essential for a long time. You should either adapt the drivers
to deal with PAE (presumably, highmem) or use a 64-bit dom0.

J

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:30:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17: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 1U2mLJ-0001jT-GN; Tue, 05 Feb 2013 17:30:01 +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 1U2mLI-0001jO-Ph
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 17:30:00 +0000
Received: from [85.158.143.99:18099] by server-1.bemta-4.messagelabs.com id
	F2/0B-08839-79141115; Tue, 05 Feb 2013 17:29:59 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360085398!30953533!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31962 invoked from network); 5 Feb 2013 17:29:59 -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; 5 Feb 2013 17:29:59 -0000
Received: from saboo.goop.org (mf82036d0.tmodns.net [208.54.32.248])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 913B6876A;
	Tue,  5 Feb 2013 09:29:57 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 9BFC220133;
	Tue,  5 Feb 2013 09:29:53 -0800 (PST)
Message-ID: <51114191.7020406@goop.org>
Date: Tue, 05 Feb 2013 09:29:53 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Mao, Junjie" <junjie.mao@intel.com>
References: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E031B6C38@SHSMSX101.ccr.corp.intel.com>
X-Enigmail-Version: 1.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Dong,
	Eddie" <eddie.dong@intel.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] How can I run 3.x dom0 w/o PAE?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 02/04/2013 06:45 PM, Mao, Junjie wrote:
> I=92m now working in a Xen-based project where some drivers in the Dom0
> kernel (based on Linux 3.0) refuse to work with PAE. Do you know if it
> is possible to run 3.x kernel as non-PAE dom0 on Xen (any version is
> ok)? If so, how can I make it work? Many thanks in advance!

No, we removed non-PAE 32-bit operation a long time ago, and its not
coming back. What drivers don't work with PAE enabled? PAE has been more
or less essential for a long time. You should either adapt the drivers
to deal with PAE (presumably, highmem) or use a 64-bit dom0.

J

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:39:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:39: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 1U2mUF-0002Gp-Cw; Tue, 05 Feb 2013 17:39:15 +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 1U2mUE-0002Gk-B5
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:39:14 +0000
Received: from [85.158.143.35:60286] by server-2.bemta-4.messagelabs.com id
	2F/FB-01597-1C341115; Tue, 05 Feb 2013 17:39:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360085950!5024222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2161 invoked from network); 5 Feb 2013 17:39:11 -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;
	5 Feb 2013 17:39:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6038808"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:39:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:39:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2mU2-0006wO-B0;
	Tue, 05 Feb 2013 17:39:02 +0000
Message-ID: <1360085942.7477.175.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:39:02 +0000
In-Reply-To: <20130205170900.GG2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
	<20130205170900.GG2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 17:09 +0000, Konrad Rzeszutek Wilk wrote:
> >
> > +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
> > +{
> > +     int cpu = smp_processor_id();
> > +     unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > +     unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
> > +     int i;
> > +     struct vcpu_info *v;
> > +
> > +     v = per_cpu(xen_vcpu, cpu);
> > +
> > +     printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--)
> > +             if (evtchn_pending[i] != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)sizeof(evtchn_pending[0])*2,
> > +                            evtchn_pending[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--)
> > +             if (evtchn_mask[i] != ~0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)sizeof(evtchn_mask[0])*2,
> > +                            evtchn_mask[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--)
> > +             if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)(sizeof(evtchn_mask[0])*2),
> > +                            evtchn_pending[i] & ~evtchn_mask[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
> > +     for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
> > +             if (cpu_evtchn[i] != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)(sizeof(cpu_evtchn[0])*2),
> > +                            cpu_evtchn[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--) {
> > +             unsigned long pending = evtchn_pending[i]
> > +                     & ~evtchn_mask[i]
> > +                     & cpu_evtchn[i];
> > +             if (pending != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)(sizeof(evtchn_mask[0])*2),
> > +                            pending);
> > +             }
> > +     }
> > +
> > +     printk(KERN_DEBUG "\npending list:\n");
> > +     for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
> > +             if (sync_test_bit(i, evtchn_pending)) {
> > +                     int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
> > +                     int word_idx_l2 = i / BITS_PER_LONG;
> > +                     printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
> > +                            cpu_from_evtchn(i), i,
> > +                            evtchn_to_irq[i],
> > +                            !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +                            ? "" : " l1-clear",
> > +                            !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
> > +                            ? "" : " l2-clear",
> > +                            sync_test_bit(i, evtchn_mask)
> > +                            ? "" : " globally-masked",
> > +                            sync_test_bit(i, cpu_evtchn)
> > +                            ? "" : " locally-masked");
> > +             }
> > +     }
> > +
> > +     return IRQ_HANDLED;
> 
> Um, there has to be a way to fold the most common cases of the L2 and L3
> of this function in one?
> 

The only common part is the for-loop. I could try to move statements in
for-loops to dedicated functions, then the file will be filled with 10+
functions like:

void output_l{2,3}_{globally,locally}_{masked,unmasked}()

void output_l{2,3}_pending()

void print_heading_for_l{2,3}()


> > +                                     pending_words_l2 &= ~(1UL << word_idx_l2);
> > +
> > +                             word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
> > +                     }
> 
> This is a bit of a complex code. Is there any way you can split this up
> in smaller inline functions?

I will try.


Wei.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:39:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:39: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 1U2mUF-0002Gp-Cw; Tue, 05 Feb 2013 17:39:15 +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 1U2mUE-0002Gk-B5
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 17:39:14 +0000
Received: from [85.158.143.35:60286] by server-2.bemta-4.messagelabs.com id
	2F/FB-01597-1C341115; Tue, 05 Feb 2013 17:39:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360085950!5024222!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2161 invoked from network); 5 Feb 2013 17:39:11 -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;
	5 Feb 2013 17:39:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6038808"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 17:39:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 12:39:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2mU2-0006wO-B0;
	Tue, 05 Feb 2013 17:39:02 +0000
Message-ID: <1360085942.7477.175.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 5 Feb 2013 17:39:02 +0000
In-Reply-To: <20130205170900.GG2187@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
	<20130205170900.GG2187@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 17:09 +0000, Konrad Rzeszutek Wilk wrote:
> >
> > +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
> > +{
> > +     int cpu = smp_processor_id();
> > +     unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > +     unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
> > +     int i;
> > +     struct vcpu_info *v;
> > +
> > +     v = per_cpu(xen_vcpu, cpu);
> > +
> > +     printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--)
> > +             if (evtchn_pending[i] != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)sizeof(evtchn_pending[0])*2,
> > +                            evtchn_pending[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--)
> > +             if (evtchn_mask[i] != ~0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)sizeof(evtchn_mask[0])*2,
> > +                            evtchn_mask[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--)
> > +             if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)(sizeof(evtchn_mask[0])*2),
> > +                            evtchn_pending[i] & ~evtchn_mask[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
> > +     for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
> > +             if (cpu_evtchn[i] != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)(sizeof(cpu_evtchn[0])*2),
> > +                            cpu_evtchn[i]);
> > +             }
> > +
> > +     printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
> > +     for (i = nr_elems-1; i >= 0; i--) {
> > +             unsigned long pending = evtchn_pending[i]
> > +                     & ~evtchn_mask[i]
> > +                     & cpu_evtchn[i];
> > +             if (pending != 0UL) {
> > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > +                            i,
> > +                            (int)(sizeof(evtchn_mask[0])*2),
> > +                            pending);
> > +             }
> > +     }
> > +
> > +     printk(KERN_DEBUG "\npending list:\n");
> > +     for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
> > +             if (sync_test_bit(i, evtchn_pending)) {
> > +                     int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
> > +                     int word_idx_l2 = i / BITS_PER_LONG;
> > +                     printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
> > +                            cpu_from_evtchn(i), i,
> > +                            evtchn_to_irq[i],
> > +                            !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +                            ? "" : " l1-clear",
> > +                            !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
> > +                            ? "" : " l2-clear",
> > +                            sync_test_bit(i, evtchn_mask)
> > +                            ? "" : " globally-masked",
> > +                            sync_test_bit(i, cpu_evtchn)
> > +                            ? "" : " locally-masked");
> > +             }
> > +     }
> > +
> > +     return IRQ_HANDLED;
> 
> Um, there has to be a way to fold the most common cases of the L2 and L3
> of this function in one?
> 

The only common part is the for-loop. I could try to move statements in
for-loops to dedicated functions, then the file will be filled with 10+
functions like:

void output_l{2,3}_{globally,locally}_{masked,unmasked}()

void output_l{2,3}_pending()

void print_heading_for_l{2,3}()


> > +                                     pending_words_l2 &= ~(1UL << word_idx_l2);
> > +
> > +                             word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
> > +                     }
> 
> This is a bit of a complex code. Is there any way you can split this up
> in smaller inline functions?

I will try.


Wei.



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 17:56:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:56: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 1U2mkd-0002p8-AO; Tue, 05 Feb 2013 17:56:11 +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 1U2mkb-0002p3-Tg
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 17:56:10 +0000
Received: from [193.109.254.147:19413] by server-16.bemta-14.messagelabs.com
	id CD/58-25906-8B741115; Tue, 05 Feb 2013 17:56:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360086966!8902186!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13825 invoked from network); 5 Feb 2013 17:56:06 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 17:56:06 -0000
Received: by mail-wi0-f182.google.com with SMTP id hi18so578423wib.3
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Feb 2013 09:56:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=s45twwWRCmvQqAEcSstzDKPF2elhnmUBd/J3Vb6LKHg=;
	b=e+oYzb3znV5EAh5O/xWJtULHgIfsrR914ZmUylbe96z7mEPPOUjZLao0/xmO/08NJx
	5GZ/DN6msK9tgb4pi8/GpkyJB36r5oMVRwyLAsUFGd3xcw1/gJkgbb+0k0uuWZe4ZXsr
	JkL2DCXRZx/0QBD1kmpRtarSrgeXyXhot2XxtQmPnrjcI5jg2qTkfpcTcCaLlphm+A3V
	IuJx3xvBHpVGkTT+nb7mhmlGudoD2YhXQu8xaQG0xx6nHDGtbInnhsWDXWgT8XbjRHgQ
	HWyQGJZfZckdrDMa9uSDcbKOpibUhqQq6pYQUYxO3DMUGwl+LgsS+r2POsao/6hD2HEx
	10jw==
MIME-Version: 1.0
X-Received: by 10.194.89.167 with SMTP id bp7mr44205196wjb.0.1360086966188;
	Tue, 05 Feb 2013 09:56:06 -0800 (PST)
Received: by 10.194.136.98 with HTTP; Tue, 5 Feb 2013 09:56:06 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302051126590.4275@kaball.uk.xensource.com>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302051126590.4275@kaball.uk.xensource.com>
Date: Tue, 5 Feb 2013 17:56:06 +0000
X-Google-Sender-Auth: ijaRL75mlDWk59c-Eo2S4hqX86M
Message-ID: <CAFLBxZbydGY24OdMt5NLOsFz9oHYDGGBAqaSm7oGaBNe4AYDsA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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 v8] tools/libxl: Add qxl vga interface
 support for upstream-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: multipart/mixed; boundary="===============0847686550701008222=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0847686550701008222==
Content-Type: multipart/alternative; boundary=047d7bf10a867bbc5f04d4fdec19

--047d7bf10a867bbc5f04d4fdec19
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 5, 2013 at 11:30 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> BTW you can find a simple doc here that explains how to send patches to
> mailing lists:
>
> http://www.kernel.org/doc/Documentation/SubmittingPatches
>
> the first part is a bit out-of-date: nowadays you would use "hg diff" or
> "git diff" to generate your patches.
>

There's information about sending patch series with hg here:

http://wiki.xen.org/wiki/Submitting_Xen_Patches

If you're using git, "git email" is the most convenient thing to use.

 -George

--047d7bf10a867bbc5f04d4fdec19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 5, 2013 at 11:30 AM, Stefano Stabellini <span =
dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com" target=
=3D"_blank">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><div =
class=3D"gmail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div class=3D"im">BTW you can find a simple doc here that explains how to=
 send patches to<br>
</div>
mailing lists:<br>
<br>
<a href=3D"http://www.kernel.org/doc/Documentation/SubmittingPatches" targe=
t=3D"_blank">http://www.kernel.org/doc/Documentation/SubmittingPatches</a><=
br>
<br>
the first part is a bit out-of-date: nowadays you would use &quot;hg diff&q=
uot; or<br>
&quot;git diff&quot; to generate your patches.<br></blockquote><div><br></d=
iv></div>There&#39;s information about sending patch series with hg here:<b=
r><br><a href=3D"http://wiki.xen.org/wiki/Submitting_Xen_Patches">http://wi=
ki.xen.org/wiki/Submitting_Xen_Patches</a><br>
<br></div><div class=3D"gmail_extra">If you&#39;re using git, &quot;git ema=
il&quot; is the most convenient thing to use.<br><br></div><div class=3D"gm=
ail_extra">=A0-George<br></div></div>

--047d7bf10a867bbc5f04d4fdec19--


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

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

--===============0847686550701008222==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 17:56:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 17:56: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 1U2mkd-0002p8-AO; Tue, 05 Feb 2013 17:56:11 +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 1U2mkb-0002p3-Tg
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 17:56:10 +0000
Received: from [193.109.254.147:19413] by server-16.bemta-14.messagelabs.com
	id CD/58-25906-8B741115; Tue, 05 Feb 2013 17:56:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360086966!8902186!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13825 invoked from network); 5 Feb 2013 17:56:06 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 17:56:06 -0000
Received: by mail-wi0-f182.google.com with SMTP id hi18so578423wib.3
	for <xen-devel@lists.xensource.com>;
	Tue, 05 Feb 2013 09:56:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=s45twwWRCmvQqAEcSstzDKPF2elhnmUBd/J3Vb6LKHg=;
	b=e+oYzb3znV5EAh5O/xWJtULHgIfsrR914ZmUylbe96z7mEPPOUjZLao0/xmO/08NJx
	5GZ/DN6msK9tgb4pi8/GpkyJB36r5oMVRwyLAsUFGd3xcw1/gJkgbb+0k0uuWZe4ZXsr
	JkL2DCXRZx/0QBD1kmpRtarSrgeXyXhot2XxtQmPnrjcI5jg2qTkfpcTcCaLlphm+A3V
	IuJx3xvBHpVGkTT+nb7mhmlGudoD2YhXQu8xaQG0xx6nHDGtbInnhsWDXWgT8XbjRHgQ
	HWyQGJZfZckdrDMa9uSDcbKOpibUhqQq6pYQUYxO3DMUGwl+LgsS+r2POsao/6hD2HEx
	10jw==
MIME-Version: 1.0
X-Received: by 10.194.89.167 with SMTP id bp7mr44205196wjb.0.1360086966188;
	Tue, 05 Feb 2013 09:56:06 -0800 (PST)
Received: by 10.194.136.98 with HTTP; Tue, 5 Feb 2013 09:56:06 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302051126590.4275@kaball.uk.xensource.com>
References: <5106A14E.2040703@tiscali.it>
	<1360060432.17017.22.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302051126590.4275@kaball.uk.xensource.com>
Date: Tue, 5 Feb 2013 17:56:06 +0000
X-Google-Sender-Auth: ijaRL75mlDWk59c-Eo2S4hqX86M
Message-ID: <CAFLBxZbydGY24OdMt5NLOsFz9oHYDGGBAqaSm7oGaBNe4AYDsA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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 v8] tools/libxl: Add qxl vga interface
 support for upstream-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: multipart/mixed; boundary="===============0847686550701008222=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0847686550701008222==
Content-Type: multipart/alternative; boundary=047d7bf10a867bbc5f04d4fdec19

--047d7bf10a867bbc5f04d4fdec19
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 5, 2013 at 11:30 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> BTW you can find a simple doc here that explains how to send patches to
> mailing lists:
>
> http://www.kernel.org/doc/Documentation/SubmittingPatches
>
> the first part is a bit out-of-date: nowadays you would use "hg diff" or
> "git diff" to generate your patches.
>

There's information about sending patch series with hg here:

http://wiki.xen.org/wiki/Submitting_Xen_Patches

If you're using git, "git email" is the most convenient thing to use.

 -George

--047d7bf10a867bbc5f04d4fdec19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 5, 2013 at 11:30 AM, Stefano Stabellini <span =
dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com" target=
=3D"_blank">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><div =
class=3D"gmail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div class=3D"im">BTW you can find a simple doc here that explains how to=
 send patches to<br>
</div>
mailing lists:<br>
<br>
<a href=3D"http://www.kernel.org/doc/Documentation/SubmittingPatches" targe=
t=3D"_blank">http://www.kernel.org/doc/Documentation/SubmittingPatches</a><=
br>
<br>
the first part is a bit out-of-date: nowadays you would use &quot;hg diff&q=
uot; or<br>
&quot;git diff&quot; to generate your patches.<br></blockquote><div><br></d=
iv></div>There&#39;s information about sending patch series with hg here:<b=
r><br><a href=3D"http://wiki.xen.org/wiki/Submitting_Xen_Patches">http://wi=
ki.xen.org/wiki/Submitting_Xen_Patches</a><br>
<br></div><div class=3D"gmail_extra">If you&#39;re using git, &quot;git ema=
il&quot; is the most convenient thing to use.<br><br></div><div class=3D"gm=
ail_extra">=A0-George<br></div></div>

--047d7bf10a867bbc5f04d4fdec19--


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

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

--===============0847686550701008222==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 18:01:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:01: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 1U2mpr-00033j-3X; Tue, 05 Feb 2013 18:01:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2mpp-00033e-BM
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:01:33 +0000
Received: from [193.109.254.147:63930] by server-6.bemta-14.messagelabs.com id
	77/E7-12010-CF841115; Tue, 05 Feb 2013 18:01:32 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360087291!4079048!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18002 invoked from network); 5 Feb 2013 18:01:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-27.messagelabs.com with SMTP;
	5 Feb 2013 18:01:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4D164C56197;
	Tue,  5 Feb 2013 18:01:19 +0000 (GMT)
Date: Tue, 05 Feb 2013 18:01:18 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <B0275D4BBB148810B3939AD4@nimrod.local>
In-Reply-To: <CACaajQskiwRkaY2eiXO-AP1tcvgAhsja4bKnrH2aWbP7pTP0RQ@mail.gmail.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<05E85F0F99EB21013A48E1E6@nimrod.local>
	<CACaajQskiwRkaY2eiXO-AP1tcvgAhsja4bKnrH2aWbP7pTP0RQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] blkback disk I/O limit patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 5 February 2013 20:36:05 +0400 Vasiliy Tolstov <v.tolstov@selfip.ru> 
wrote:

> 2013/2/5 Alex Bligh <alex@alex.org.uk>:
>> Another approach (when using the qemu-upstream DM) would presumably
>> be to use the block_io_throttle QMP command that QEMU provides.
>
> Hmm. Does this play good with phy devices used by xen?

Pass.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:01:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:01: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 1U2mpr-00033j-3X; Tue, 05 Feb 2013 18:01:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U2mpp-00033e-BM
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:01:33 +0000
Received: from [193.109.254.147:63930] by server-6.bemta-14.messagelabs.com id
	77/E7-12010-CF841115; Tue, 05 Feb 2013 18:01:32 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360087291!4079048!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18002 invoked from network); 5 Feb 2013 18:01:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-27.messagelabs.com with SMTP;
	5 Feb 2013 18:01:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4D164C56197;
	Tue,  5 Feb 2013 18:01:19 +0000 (GMT)
Date: Tue, 05 Feb 2013 18:01:18 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <B0275D4BBB148810B3939AD4@nimrod.local>
In-Reply-To: <CACaajQskiwRkaY2eiXO-AP1tcvgAhsja4bKnrH2aWbP7pTP0RQ@mail.gmail.com>
References: <CACaajQsTVvdoatXSTngDL-OPW4j6Oz2w4Qp+e1GY=6Y4VRWJ7w@mail.gmail.com>
	<05E85F0F99EB21013A48E1E6@nimrod.local>
	<CACaajQskiwRkaY2eiXO-AP1tcvgAhsja4bKnrH2aWbP7pTP0RQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] blkback disk I/O limit patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 5 February 2013 20:36:05 +0400 Vasiliy Tolstov <v.tolstov@selfip.ru> 
wrote:

> 2013/2/5 Alex Bligh <alex@alex.org.uk>:
>> Another approach (when using the qemu-upstream DM) would presumably
>> be to use the block_io_throttle QMP command that QEMU provides.
>
> Hmm. Does this play good with phy devices used by xen?

Pass.

-- 
Alex Bligh

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:02:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2mqf-00036c-JJ; Tue, 05 Feb 2013 18:02: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 1U2mqe-00036U-HF
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:02:24 +0000
Received: from [85.158.143.99:19421] by server-3.bemta-4.messagelabs.com id
	92/1D-08920-F2941115; Tue, 05 Feb 2013 18:02:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360087337!23480326!1
X-Originating-IP: [209.85.210.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1049 invoked from network); 5 Feb 2013 18:02:21 -0000
Received: from mail-ia0-f177.google.com (HELO mail-ia0-f177.google.com)
	(209.85.210.177)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:02:21 -0000
Received: by mail-ia0-f177.google.com with SMTP id h8so471404iaa.36
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 10:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=IH3MDCU5d3fJPZVrwB5bKLYdjBkJXBFIM1O9zf5diUE=;
	b=g5YRusRjW2cb+++ToFTEJNYaQChvV9eyQJRG8Rt/nRDnEQ2R7/Ft+S6lY1ZVxENm38
	OWt/jqC4KFtRFRAGzufX8I3hxFieQAsM5DZwCguA3NGg1RtZdoGznEjj0TxeC4bu029E
	2mPKdmrct2jrq+9+82f4utWXTJvWerAU4T/OiryBoCDDCTqdbRMpiQUVuyVuqNwjG0O8
	DOJmRP/RbNaxdodUE3yheE7lePquse08k1FODnXY1155OyASIbOeMPpmQHs3qL7obKf6
	Knrr5Xh3yFG9EmZa0gNItVr67ISh8kH38fPQ7rTqqNBleCwwGIztzFULAQAtO2lCY292
	BBWA==
X-Received: by 10.50.171.42 with SMTP id ar10mr15355580igc.64.1360087337407;
	Tue, 05 Feb 2013 10:02:17 -0800 (PST)
Received: from [10.128.254.5] ([198.162.52.32])
	by mx.google.com with ESMTPS id ig8sm23728474igc.10.2013.02.05.10.02.13
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 10:02:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 05 Feb 2013 18:02:01 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD36F999.5A4AC%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DyuWP5EUCZZHZtUmoiM8f/XfNHw==
In-Reply-To: <1360080697.23001.28.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>> Okay, I wonder how much it actually matters anyhow...
>>> 
>>> Oh by the way you say the control block is 128 bytes and will easily fit in
>>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
>>> So how does that work then?
>> 
>> I meant struct vcpu_info can be extended without it growing to more than
>> a page.  i.e., it fits into the guest page provided in the
>> VCPUOP_register_vcpu_info call so no additional pages need to be
>> globally mapped for the control block.
> 
> VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> by itself, even if that happens to be the Linux implementation today (I
> haven't checked that).

Having guest agree that vcpu_info grows by size of the per-vcpu control
block, if using this new event-channel interface, is reasonable though.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:02:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2mqf-00036c-JJ; Tue, 05 Feb 2013 18:02: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 1U2mqe-00036U-HF
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:02:24 +0000
Received: from [85.158.143.99:19421] by server-3.bemta-4.messagelabs.com id
	92/1D-08920-F2941115; Tue, 05 Feb 2013 18:02:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360087337!23480326!1
X-Originating-IP: [209.85.210.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1049 invoked from network); 5 Feb 2013 18:02:21 -0000
Received: from mail-ia0-f177.google.com (HELO mail-ia0-f177.google.com)
	(209.85.210.177)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:02:21 -0000
Received: by mail-ia0-f177.google.com with SMTP id h8so471404iaa.36
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 10:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=IH3MDCU5d3fJPZVrwB5bKLYdjBkJXBFIM1O9zf5diUE=;
	b=g5YRusRjW2cb+++ToFTEJNYaQChvV9eyQJRG8Rt/nRDnEQ2R7/Ft+S6lY1ZVxENm38
	OWt/jqC4KFtRFRAGzufX8I3hxFieQAsM5DZwCguA3NGg1RtZdoGznEjj0TxeC4bu029E
	2mPKdmrct2jrq+9+82f4utWXTJvWerAU4T/OiryBoCDDCTqdbRMpiQUVuyVuqNwjG0O8
	DOJmRP/RbNaxdodUE3yheE7lePquse08k1FODnXY1155OyASIbOeMPpmQHs3qL7obKf6
	Knrr5Xh3yFG9EmZa0gNItVr67ISh8kH38fPQ7rTqqNBleCwwGIztzFULAQAtO2lCY292
	BBWA==
X-Received: by 10.50.171.42 with SMTP id ar10mr15355580igc.64.1360087337407;
	Tue, 05 Feb 2013 10:02:17 -0800 (PST)
Received: from [10.128.254.5] ([198.162.52.32])
	by mx.google.com with ESMTPS id ig8sm23728474igc.10.2013.02.05.10.02.13
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 05 Feb 2013 10:02:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 05 Feb 2013 18:02:01 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD36F999.5A4AC%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4DyuWP5EUCZZHZtUmoiM8f/XfNHw==
In-Reply-To: <1360080697.23001.28.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>> Okay, I wonder how much it actually matters anyhow...
>>> 
>>> Oh by the way you say the control block is 128 bytes and will easily fit in
>>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
>>> So how does that work then?
>> 
>> I meant struct vcpu_info can be extended without it growing to more than
>> a page.  i.e., it fits into the guest page provided in the
>> VCPUOP_register_vcpu_info call so no additional pages need to be
>> globally mapped for the control block.
> 
> VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> by itself, even if that happens to be the Linux implementation today (I
> haven't checked that).

Having guest agree that vcpu_info grows by size of the per-vcpu control
block, if using this new event-channel interface, is reasonable though.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:06:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:06: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 1U2mu2-0003Sl-89; Tue, 05 Feb 2013 18:05:54 +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 1U2mu1-0003Sf-7E
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:05:53 +0000
Received: from [85.158.143.35:19958] by server-2.bemta-4.messagelabs.com id
	8C/A1-01597-00A41115; Tue, 05 Feb 2013 18:05:52 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360087544!11997653!1
X-Originating-IP: [74.125.82.180]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27789 invoked from network); 5 Feb 2013 18:05:51 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:05:51 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so384670wer.11
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 10:05:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XW5V37u+g77keyt82BvnL1tE1EBggYTsyfj/NXoptwM=;
	b=AvWRUXeMsO79iuM4DZrvcwFSYHVyXnXlh9i0fEOzUqPtoalFj+GnN4ehkyFGTc5KVQ
	HSPLrADBpfb1LOTrd1WyH3gM7iiNG6Uh3grPMD7RSIl4Rp18ePW8TsgGsDjZNtXKTp00
	CIuGleSPg8USFLRgawgWuI2f+Tfb7bVLvDsCCDGBxtFyRj43s/8NRmKmBCbGRaX/u0rM
	TaMfpLIw1GHZGar7qP+9ACxDb8HF0wxZmY9Utaf3RxEsJp/8nYCjC6C+AyClyIdQC8rI
	zN3Ub9ApFowGxFaowlV1Q/fBK5t396F4VUm3EjgPnKEreWJtNric9cI+s8K7ddiE+Wjo
	HIKw==
MIME-Version: 1.0
X-Received: by 10.194.21.70 with SMTP id t6mr44362954wje.42.1360087544814;
	Tue, 05 Feb 2013 10:05:44 -0800 (PST)
Received: by 10.194.136.98 with HTTP; Tue, 5 Feb 2013 10:05:44 -0800 (PST)
In-Reply-To: <1360077399.7477.148.camel@zion.uk.xensource.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
	<1360077399.7477.148.camel@zion.uk.xensource.com>
Date: Tue, 5 Feb 2013 18:05:44 +0000
X-Google-Sender-Auth: GGNEV7lQMSfHseF56g3-9NAhMiY
Message-ID: <CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0022511179880796363=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0022511179880796363==
Content-Type: multipart/alternative; boundary=047d7b5d3ef6f8dd8e04d4fe0ecd

--047d7b5d3ef6f8dd8e04d4fe0ecd
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <wei.liu2@citrix.com> wrote:

> > Since the ABI needs to be changed to support more event channels anyway,
> > it seems an ideal point to revisit the design.
> >
>
> Right. I do care about better design and good implementation. Can we
> build a prototype of this design? We are less than two months away from
> 4.3 feature freeze, and the event channel scalability is planned for
> that release, which means we need to be hurried. :-)
>

I think the general consensus is that scaling event channels is pretty
important -- probably important enough to slip the release a bit if
necessary.  (Although it would certainly be better not to.)

 -George

--047d7b5d3ef6f8dd8e04d4fe0ecd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <span dir=3D"ltr">=
&lt;<a href=3D"mailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citri=
x.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<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">
&gt; Since the ABI needs to be changed to support more event channels anywa=
y,<br>
&gt; it seems an ideal point to revisit the design.<br>
&gt;<br>
<br>
</div></div>Right. I do care about better design and good implementation. C=
an we<br>
build a prototype of this design? We are less than two months away from<br>
4.3 feature freeze, and the event channel scalability is planned for<br>
that release, which means we need to be hurried. :-)<br></blockquote><br></=
div><div class=3D"gmail_quote">I think the general consensus is that scalin=
g event channels is pretty important -- probably important enough to slip t=
he release a bit if necessary.=A0 (Although it would certainly be better no=
t to.)<br>
<br></div><div class=3D"gmail_quote">=A0-George<br></div></div></div>

--047d7b5d3ef6f8dd8e04d4fe0ecd--


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

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

--===============0022511179880796363==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 18:06:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:06: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 1U2mu2-0003Sl-89; Tue, 05 Feb 2013 18:05:54 +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 1U2mu1-0003Sf-7E
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:05:53 +0000
Received: from [85.158.143.35:19958] by server-2.bemta-4.messagelabs.com id
	8C/A1-01597-00A41115; Tue, 05 Feb 2013 18:05:52 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360087544!11997653!1
X-Originating-IP: [74.125.82.180]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27789 invoked from network); 5 Feb 2013 18:05:51 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:05:51 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so384670wer.11
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 10:05:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XW5V37u+g77keyt82BvnL1tE1EBggYTsyfj/NXoptwM=;
	b=AvWRUXeMsO79iuM4DZrvcwFSYHVyXnXlh9i0fEOzUqPtoalFj+GnN4ehkyFGTc5KVQ
	HSPLrADBpfb1LOTrd1WyH3gM7iiNG6Uh3grPMD7RSIl4Rp18ePW8TsgGsDjZNtXKTp00
	CIuGleSPg8USFLRgawgWuI2f+Tfb7bVLvDsCCDGBxtFyRj43s/8NRmKmBCbGRaX/u0rM
	TaMfpLIw1GHZGar7qP+9ACxDb8HF0wxZmY9Utaf3RxEsJp/8nYCjC6C+AyClyIdQC8rI
	zN3Ub9ApFowGxFaowlV1Q/fBK5t396F4VUm3EjgPnKEreWJtNric9cI+s8K7ddiE+Wjo
	HIKw==
MIME-Version: 1.0
X-Received: by 10.194.21.70 with SMTP id t6mr44362954wje.42.1360087544814;
	Tue, 05 Feb 2013 10:05:44 -0800 (PST)
Received: by 10.194.136.98 with HTTP; Tue, 5 Feb 2013 10:05:44 -0800 (PST)
In-Reply-To: <1360077399.7477.148.camel@zion.uk.xensource.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
	<1360077399.7477.148.camel@zion.uk.xensource.com>
Date: Tue, 5 Feb 2013 18:05:44 +0000
X-Google-Sender-Auth: GGNEV7lQMSfHseF56g3-9NAhMiY
Message-ID: <CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0022511179880796363=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0022511179880796363==
Content-Type: multipart/alternative; boundary=047d7b5d3ef6f8dd8e04d4fe0ecd

--047d7b5d3ef6f8dd8e04d4fe0ecd
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <wei.liu2@citrix.com> wrote:

> > Since the ABI needs to be changed to support more event channels anyway,
> > it seems an ideal point to revisit the design.
> >
>
> Right. I do care about better design and good implementation. Can we
> build a prototype of this design? We are less than two months away from
> 4.3 feature freeze, and the event channel scalability is planned for
> that release, which means we need to be hurried. :-)
>

I think the general consensus is that scaling event channels is pretty
important -- probably important enough to slip the release a bit if
necessary.  (Although it would certainly be better not to.)

 -George

--047d7b5d3ef6f8dd8e04d4fe0ecd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <span dir=3D"ltr">=
&lt;<a href=3D"mailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citri=
x.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<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">
&gt; Since the ABI needs to be changed to support more event channels anywa=
y,<br>
&gt; it seems an ideal point to revisit the design.<br>
&gt;<br>
<br>
</div></div>Right. I do care about better design and good implementation. C=
an we<br>
build a prototype of this design? We are less than two months away from<br>
4.3 feature freeze, and the event channel scalability is planned for<br>
that release, which means we need to be hurried. :-)<br></blockquote><br></=
div><div class=3D"gmail_quote">I think the general consensus is that scalin=
g event channels is pretty important -- probably important enough to slip t=
he release a bit if necessary.=A0 (Although it would certainly be better no=
t to.)<br>
<br></div><div class=3D"gmail_quote">=A0-George<br></div></div></div>

--047d7b5d3ef6f8dd8e04d4fe0ecd--


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

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

--===============0022511179880796363==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 18:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:19: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 1U2n75-0004Hm-9p; Tue, 05 Feb 2013 18:19:23 +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 1U2n73-0004Hd-Rq
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:19:22 +0000
Received: from [85.158.138.51:16589] by server-14.bemta-3.messagelabs.com id
	6F/1F-23533-82D41115; Tue, 05 Feb 2013 18:19:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360088357!29347511!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30250 invoked from network); 5 Feb 2013 18:19:20 -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;
	5 Feb 2013 18:19:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6045794"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 18:18:56 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	13:18:56 -0500
Message-ID: <51114D0F.3090802@citrix.com>
Date: Tue, 5 Feb 2013 18:18:55 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510FF54E.1070706@citrix.com>
	<1360080628.23001.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360080628.23001.27.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 16:10, Ian Campbell wrote:
> On Mon, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
>> The pages within the event array need not be physically nor virtually
>> contiguous, but the guest or Xen may make the virtually contiguous for
>> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
>> Linux.  Pages are added by the guest as required by the number of
>> bound event channels.
> 
> Strictly speaking the size is related to the maximum bound evtchn, which
> need not be the same as the number of bound evtchns.

Yes.

>> The state of an event is tracked using 3 bits within the event word.
>> the M (masked), P (pending) and L (linked) bits.  Only state
>> transitions that change a single bit are valid.
> 
> The diagram shows transitions B<->P and P<->L, which involve two bits in
> each case. So do BM<->PM and LM<->BM now I think about it.

B == 000b, P == 100b, L == 101b.

Similarly for the masked transitions:

BM == 010b, PM == 110b, LM == 111b.

> Is the L bit redundant with the LINK field == 0 or != 0?

LINK == 0 is the end of queue marker.  We could use all ones to mean
'unlinked' but using the L bit allows the guest to remove the event from
the queue by clearing a single bit, instead of writing the LINK field.

>> ### `EVTCHNOP_init`
>>
>> This call initializes a single VCPU's event channel data structures,
>> adding one page for the event array.
> 
> Isn't the event array per-domain?

Er, yes.  I changed this from per-VCPU and it looks like I didn't make
all the updates required.

>> A guest should call this during initial VCPU bring up (and on resume?).
>>
>>     struct evtchnop_init {
>>         uint32_t vcpu;
>>         uint64_t array_pfn;
>>     };
> 
> I think this will have a different layout on 32 and 64 bit x86, if you
> care (because uint64_t is align(4) on 32-bit and align(8) on 64-bit).

Ok.  I thought uint64_t was always 8 byte aligned on both.

>> Field          Purpose
>> -----          -------
>> `vcpu`         [in] The VCPU number.
>> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>>                of the event array.
>>
>> Error code  Reason
>> ----------  ------
>> EINVAL      `vcpu` is invalid or already initialized.
>> EINVAL      `array_pfn` is not a valid frame for the domain.
>> ENOMEM      Insufficient memory to allocate internal structures.
>>
>> ### `EVTCHNOP_expand`
>>
>> This call expands the event array for a VCPU by appended an additional
>> page.
> 
> This doesn't seem all that different to _init, except the former handles
> the transition from 0->1 event pages and this handles N->N+1?

Agreed, I'll fold the two together.

>> ### `EVTCHNOP_set_priority`
>>
>> This call sets the priority for an event channel.  The event must be
>> unbound.
>>
>> A guest may call this prior to binding an event channel. The meaning
>> and the use of the priority are up to the guest.  Valid priorities are
>> 0 - 15 and the default is 7.
>>
>>     struct evtchnop_set_priority {
>>         uint32_t port;
>>         uint32_t priority;
>>     };
>>
>> Field       Purpose
>> -----       -------
>> `port`      [in] The event channel.
>> `priority`  [in] The priority for the event channel.
>>
>> Error code  Reason
>> ----------  ------
>> EINVAL      `port` is invalid.
>> EINVAL      `port` is currently bound.
> 
> EBUSY?

Sure.

>> Memory Usage
>> ------------
>>
>> Alternatively, we can consider a system with $D$ driver domains, each
>> of which requires $E_D$ events, and a dom0 using the maximum number of
>> pages (128).
>>
>> \begin{eqnarray*}
>> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
>> \end{eqnarray*}
>>
>> With, for example, 16 driver domains each using the maximum number of pages:
>> \begin{eqnarray*}
>> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>>    & = & 129 \times 10^3\text{ VMs}
>> \end{eqnarray*}
> 
> This accounts for the driver domains and dom0 but not the domains which
> they are serving, doesn't it?

This is calculating the number of pages left once those used for dom0
and the driver domains are used.  This is the same as the number of
supportable VMs since the other VMs only require a page.

>> In summary, there is space to map the event arrays for over 100,000
>> VMs.  This is more than the limit imposed by the 16 bit domain ID
>> (~32,000 VMs).
> 
> Is there scope to reduce the maximum then?

Maximum of what?

>> ### Control Block
>>
>> With $L$ priority levels and two 32-bit words for the head and tail
>> indexes, the amount of space ($S$) required in the `struct vcpu_info`
>> for the control block is:
>> \begin{eqnarray*}
>> S & = & L \times 2 \times 4 \\
>>   & = & 16 \times 2 \times 4 \\
>>   & = & 128\text{ bytes}
>> \end{eqnarray*}
>>
>> There is more than enough space within `struct vcpu_info` for the
>> control block while still keeping plenty of space for future use.
> 
> There is? I can see 7 bytes of padding and 4 bytes of evtchn_pending_sel
> which I suppose becomes redundant now.
> 
> I don't think it would be a problem to predicate use of this new
> interface on the use of the VCPU_placement API and therefore give scope
> to expand the vcpu_info.

I should have taken a proper look at where the vcpu_info comes from...
Oops.

We can add a new VCPUOP_register_vcpu_info_and_control_block which will
add a struct vcpu_info and the control block.

>> Low Level Design
>> ================
>>
>> In the pseudo code in this section, all memory accesses are atomic,
>> including those to bit-fields within the event word.
> 
>> These variables have a standard meaning:
>>
>> Variable  Purpose
>> --------  -------
>> E         Event array.
>> p         A specific event.
>> H         The head index for a specific priority.
>> T         The tail index for a specific priority.
>>
>> These memory barriers are required:
>>
>> Function  Purpose
>> --------  -------
>> mb()      Full (read/write) memory barrier
>>
>> Raising an Event
>> ----------------
>>
>> When Xen raises an event it marks it pending and (if it is not masked)
>> adds it tail of event queue.
> 
> What are the conditions for actually performing the upcall when
> returning from the hypervisor to the guest?

Any H != 0 for that VCPU.  This means we should have a per-VCPU bitmap
of non empty queues.

>>     E[p].pending = 1
>>     if not E[p].linked and not E[n].masked
>>         E[p].linked = 1
>>         E[p].link = 0
>>         mb()
>>         if H == 0
>>             H = p
>>         else
>>             E[T].link = p
>>         T = p
> 
> Do you not need a barrier towards the end here to ensure that a consumer
> who is currently processing interrupts sees the updated link when they
> get there?

I need to take another look at the barriers -- I'll get back to you on
this and the others you highlighted.

>> Concurrent access by Xen to the event queue must be protected by a
>> per-event queue spin lock.
>>
>> Consuming Events
>> ----------------
>>
>> The guests consumes events starting at the head until it reaches the
>> tail.  Events in the queue that are not pending or are masked are
>> consumed but not handled.
>>
>>     while H != 0
>>         p = H
>>         H = E[p].link
>>         if H == 0
>>             mb()
>>             H = E[p].link
>>         E[H].linked = 0
> 
> Did you mean E[p].linked here?
> 
> If at this point the interrupt is reraised then the if in the raising
> pseudo code becomes true, linked will set again and don't we also race
> with the clearing of E[p].pending below?

The event will be correctly linked and then we clear P, when we consume
the linked event it will be ignored as P is already clear.

Perhaps we could also avoid linking the event if it is already pending?

>>> Note: When the event queue contains a single event, removing the
>>> event may race with Xen appending another event because the load of
>>> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
>>> the guest must recheck `E[p].link` if the list appeared empty.
> 
> It appears that both "Raising an Event" and "Consuming Events" can write
> H? Is that correct? Likewise for the linked bit.

Xen only writes H when the queue is empty, the VM only writes H if it is
non-empty.

The linked bit is set by Xen and cleared by the guest.

Do you see a problem with this?

> It's a bit unclear because the pseudo-code doesn't make it explicitly
> which variables are par of the shared data structure and which are
> private to the local routine.

Capital variables are in the shared structures.  Lower-case are local.

>> Masking Events
>> --------------
>>
>> Events are masked by setting the masked bit.  If the event is pending
>> and linked it does not need to be unlinked.
>>
>>     E[p].masked = 1
>>
>> Unmasking Events
>> ----------------
>>
>> Events are unmasked by the guest by clearing the masked bit.  If the
>> event is pending the guest must call the event channel unmask
>> hypercall so Xen can link the event into the correct event queue.
>>
>>     E[p].masked = 0
>>     if E[p].pending
>>         hypercall(EVTCHN_unmask)
> 
> Can the hypercall do the E[p].masked = 0?

Sure.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:19: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 1U2n75-0004Hm-9p; Tue, 05 Feb 2013 18:19:23 +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 1U2n73-0004Hd-Rq
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:19:22 +0000
Received: from [85.158.138.51:16589] by server-14.bemta-3.messagelabs.com id
	6F/1F-23533-82D41115; Tue, 05 Feb 2013 18:19:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360088357!29347511!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30250 invoked from network); 5 Feb 2013 18:19:20 -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;
	5 Feb 2013 18:19:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6045794"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 18:18:56 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	13:18:56 -0500
Message-ID: <51114D0F.3090802@citrix.com>
Date: Tue, 5 Feb 2013 18:18:55 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510FF54E.1070706@citrix.com>
	<1360080628.23001.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360080628.23001.27.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 16:10, Ian Campbell wrote:
> On Mon, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
>> The pages within the event array need not be physically nor virtually
>> contiguous, but the guest or Xen may make the virtually contiguous for
>> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
>> Linux.  Pages are added by the guest as required by the number of
>> bound event channels.
> 
> Strictly speaking the size is related to the maximum bound evtchn, which
> need not be the same as the number of bound evtchns.

Yes.

>> The state of an event is tracked using 3 bits within the event word.
>> the M (masked), P (pending) and L (linked) bits.  Only state
>> transitions that change a single bit are valid.
> 
> The diagram shows transitions B<->P and P<->L, which involve two bits in
> each case. So do BM<->PM and LM<->BM now I think about it.

B == 000b, P == 100b, L == 101b.

Similarly for the masked transitions:

BM == 010b, PM == 110b, LM == 111b.

> Is the L bit redundant with the LINK field == 0 or != 0?

LINK == 0 is the end of queue marker.  We could use all ones to mean
'unlinked' but using the L bit allows the guest to remove the event from
the queue by clearing a single bit, instead of writing the LINK field.

>> ### `EVTCHNOP_init`
>>
>> This call initializes a single VCPU's event channel data structures,
>> adding one page for the event array.
> 
> Isn't the event array per-domain?

Er, yes.  I changed this from per-VCPU and it looks like I didn't make
all the updates required.

>> A guest should call this during initial VCPU bring up (and on resume?).
>>
>>     struct evtchnop_init {
>>         uint32_t vcpu;
>>         uint64_t array_pfn;
>>     };
> 
> I think this will have a different layout on 32 and 64 bit x86, if you
> care (because uint64_t is align(4) on 32-bit and align(8) on 64-bit).

Ok.  I thought uint64_t was always 8 byte aligned on both.

>> Field          Purpose
>> -----          -------
>> `vcpu`         [in] The VCPU number.
>> `array_pfn`    [in] The PFN or GMFN of a page to be used for the first page
>>                of the event array.
>>
>> Error code  Reason
>> ----------  ------
>> EINVAL      `vcpu` is invalid or already initialized.
>> EINVAL      `array_pfn` is not a valid frame for the domain.
>> ENOMEM      Insufficient memory to allocate internal structures.
>>
>> ### `EVTCHNOP_expand`
>>
>> This call expands the event array for a VCPU by appended an additional
>> page.
> 
> This doesn't seem all that different to _init, except the former handles
> the transition from 0->1 event pages and this handles N->N+1?

Agreed, I'll fold the two together.

>> ### `EVTCHNOP_set_priority`
>>
>> This call sets the priority for an event channel.  The event must be
>> unbound.
>>
>> A guest may call this prior to binding an event channel. The meaning
>> and the use of the priority are up to the guest.  Valid priorities are
>> 0 - 15 and the default is 7.
>>
>>     struct evtchnop_set_priority {
>>         uint32_t port;
>>         uint32_t priority;
>>     };
>>
>> Field       Purpose
>> -----       -------
>> `port`      [in] The event channel.
>> `priority`  [in] The priority for the event channel.
>>
>> Error code  Reason
>> ----------  ------
>> EINVAL      `port` is invalid.
>> EINVAL      `port` is currently bound.
> 
> EBUSY?

Sure.

>> Memory Usage
>> ------------
>>
>> Alternatively, we can consider a system with $D$ driver domains, each
>> of which requires $E_D$ events, and a dom0 using the maximum number of
>> pages (128).
>>
>> \begin{eqnarray*}
>> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
>> \end{eqnarray*}
>>
>> With, for example, 16 driver domains each using the maximum number of pages:
>> \begin{eqnarray*}
>> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
>>    & = & 129 \times 10^3\text{ VMs}
>> \end{eqnarray*}
> 
> This accounts for the driver domains and dom0 but not the domains which
> they are serving, doesn't it?

This is calculating the number of pages left once those used for dom0
and the driver domains are used.  This is the same as the number of
supportable VMs since the other VMs only require a page.

>> In summary, there is space to map the event arrays for over 100,000
>> VMs.  This is more than the limit imposed by the 16 bit domain ID
>> (~32,000 VMs).
> 
> Is there scope to reduce the maximum then?

Maximum of what?

>> ### Control Block
>>
>> With $L$ priority levels and two 32-bit words for the head and tail
>> indexes, the amount of space ($S$) required in the `struct vcpu_info`
>> for the control block is:
>> \begin{eqnarray*}
>> S & = & L \times 2 \times 4 \\
>>   & = & 16 \times 2 \times 4 \\
>>   & = & 128\text{ bytes}
>> \end{eqnarray*}
>>
>> There is more than enough space within `struct vcpu_info` for the
>> control block while still keeping plenty of space for future use.
> 
> There is? I can see 7 bytes of padding and 4 bytes of evtchn_pending_sel
> which I suppose becomes redundant now.
> 
> I don't think it would be a problem to predicate use of this new
> interface on the use of the VCPU_placement API and therefore give scope
> to expand the vcpu_info.

I should have taken a proper look at where the vcpu_info comes from...
Oops.

We can add a new VCPUOP_register_vcpu_info_and_control_block which will
add a struct vcpu_info and the control block.

>> Low Level Design
>> ================
>>
>> In the pseudo code in this section, all memory accesses are atomic,
>> including those to bit-fields within the event word.
> 
>> These variables have a standard meaning:
>>
>> Variable  Purpose
>> --------  -------
>> E         Event array.
>> p         A specific event.
>> H         The head index for a specific priority.
>> T         The tail index for a specific priority.
>>
>> These memory barriers are required:
>>
>> Function  Purpose
>> --------  -------
>> mb()      Full (read/write) memory barrier
>>
>> Raising an Event
>> ----------------
>>
>> When Xen raises an event it marks it pending and (if it is not masked)
>> adds it tail of event queue.
> 
> What are the conditions for actually performing the upcall when
> returning from the hypervisor to the guest?

Any H != 0 for that VCPU.  This means we should have a per-VCPU bitmap
of non empty queues.

>>     E[p].pending = 1
>>     if not E[p].linked and not E[n].masked
>>         E[p].linked = 1
>>         E[p].link = 0
>>         mb()
>>         if H == 0
>>             H = p
>>         else
>>             E[T].link = p
>>         T = p
> 
> Do you not need a barrier towards the end here to ensure that a consumer
> who is currently processing interrupts sees the updated link when they
> get there?

I need to take another look at the barriers -- I'll get back to you on
this and the others you highlighted.

>> Concurrent access by Xen to the event queue must be protected by a
>> per-event queue spin lock.
>>
>> Consuming Events
>> ----------------
>>
>> The guests consumes events starting at the head until it reaches the
>> tail.  Events in the queue that are not pending or are masked are
>> consumed but not handled.
>>
>>     while H != 0
>>         p = H
>>         H = E[p].link
>>         if H == 0
>>             mb()
>>             H = E[p].link
>>         E[H].linked = 0
> 
> Did you mean E[p].linked here?
> 
> If at this point the interrupt is reraised then the if in the raising
> pseudo code becomes true, linked will set again and don't we also race
> with the clearing of E[p].pending below?

The event will be correctly linked and then we clear P, when we consume
the linked event it will be ignored as P is already clear.

Perhaps we could also avoid linking the event if it is already pending?

>>> Note: When the event queue contains a single event, removing the
>>> event may race with Xen appending another event because the load of
>>> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
>>> the guest must recheck `E[p].link` if the list appeared empty.
> 
> It appears that both "Raising an Event" and "Consuming Events" can write
> H? Is that correct? Likewise for the linked bit.

Xen only writes H when the queue is empty, the VM only writes H if it is
non-empty.

The linked bit is set by Xen and cleared by the guest.

Do you see a problem with this?

> It's a bit unclear because the pseudo-code doesn't make it explicitly
> which variables are par of the shared data structure and which are
> private to the local routine.

Capital variables are in the shared structures.  Lower-case are local.

>> Masking Events
>> --------------
>>
>> Events are masked by setting the masked bit.  If the event is pending
>> and linked it does not need to be unlinked.
>>
>>     E[p].masked = 1
>>
>> Unmasking Events
>> ----------------
>>
>> Events are unmasked by the guest by clearing the masked bit.  If the
>> event is pending the guest must call the event channel unmask
>> hypercall so Xen can link the event into the correct event queue.
>>
>>     E[p].masked = 0
>>     if E[p].pending
>>         hypercall(EVTCHN_unmask)
> 
> Can the hypercall do the E[p].masked = 0?

Sure.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:24:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:24: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 1U2nBI-0004hB-18; Tue, 05 Feb 2013 18:23: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 1U2nBG-0004h2-Ki
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:23:42 +0000
Received: from [85.158.143.99:39779] by server-1.bemta-4.messagelabs.com id
	2B/A9-08839-A2E41115; Tue, 05 Feb 2013 18:23:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360088618!27072756!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9018 invoked from network); 5 Feb 2013 18:23:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:23:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1168221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 18:23: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.297.1; Tue, 5 Feb 2013 18:23:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2nBB-00006A-KI; Tue, 05 Feb 2013 18:23:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2nBB-0005hh-Gf;
	Tue, 05 Feb 2013 18:23:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20753.20009.426315.39002@mariner.uk.xensource.com>
Date: Tue, 5 Feb 2013 18:23:37 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
References: <1360073284-21326-1-git-send-email-ian.campbell@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] osstest: ts-xen-install: Run ldconfig after
	install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] osstest: ts-xen-install: Run ldconfig after install"):
> This appears to be needed when libraries are outside /lib and /usr/lib
> (specifically when they are in /usr/local/lib)

I have applied this and pushed it to osstest's equivalent of staging.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:24:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18:24: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 1U2nBI-0004hB-18; Tue, 05 Feb 2013 18:23: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 1U2nBG-0004h2-Ki
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:23:42 +0000
Received: from [85.158.143.99:39779] by server-1.bemta-4.messagelabs.com id
	2B/A9-08839-A2E41115; Tue, 05 Feb 2013 18:23:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360088618!27072756!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9018 invoked from network); 5 Feb 2013 18:23:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:23:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1168221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 18:23: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.297.1; Tue, 5 Feb 2013 18:23:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U2nBB-00006A-KI; Tue, 05 Feb 2013 18:23:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U2nBB-0005hh-Gf;
	Tue, 05 Feb 2013 18:23:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20753.20009.426315.39002@mariner.uk.xensource.com>
Date: Tue, 5 Feb 2013 18:23:37 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
References: <1360073284-21326-1-git-send-email-ian.campbell@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] osstest: ts-xen-install: Run ldconfig after
	install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] osstest: ts-xen-install: Run ldconfig after install"):
> This appears to be needed when libraries are outside /lib and /usr/lib
> (specifically when they are in /usr/local/lib)

I have applied this and pushed it to osstest's equivalent of staging.

Ian.

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:33:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2nKK-0004w7-8G; Tue, 05 Feb 2013 18:33: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 1U2nKI-0004w0-5U
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:33:02 +0000
Received: from [85.158.143.35:4624] by server-1.bemta-4.messagelabs.com id
	06/0F-08839-D5051115; Tue, 05 Feb 2013 18:33:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360089172!13916274!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15453 invoked from network); 5 Feb 2013 18:32:53 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 18:32:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15IWkLD019189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 18:32:47 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
	r15IWjhu009279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 18:32:46 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
	r15IWjM0025244; Tue, 5 Feb 2013 12:32:45 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 10:32:44 -0800
Date: Tue, 5 Feb 2013 13:32:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Message-ID: <20130205183236.GB5652@konrad-lan.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <510F885B.2040603@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Milan opath <milan.opath@gmail.com>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Mon, Feb 04, 2013 at 11:07:23AM +0100, Tomasz Wroblewski wrote:
> 
> >>fix-suspend-scheduler-v2
> >>fix-suspend-scheduler-revert-affinity-part
> >>s3-timerirq
> >>
> >>All of these fixes have been proposed to the xen-devel list, but have
> >>not yet been accepted, for one reason, or another.
> >And I don't think comments on them have seen follow-ups.
> >
> >Jan
> >
> I guess it's worth bringing this up again;
> 
> s3-timerirq: this was empirical hack which for some reason is needed
> on stable 4.2 we use, but not on latest unstable, didn't really
> investigate further since it appeared fixed later on anyway..
> 
> fix-suspend-scheduler/revert-affinity: the big objection here was
> the part which reverts one of the hunks in Keir's commit. I tried
> for quite few days to find a working fix which does not do this
> revert using posted suggestions, but was not succesfull:
> 
> - there was a crash in xen scheduler, which was fixable using your
> suggestion of masking softirqs during s3 (ugly)
> - there was also a crash in xen acpi cpufreq driver, which was
> similarily fixable using a bandaid s3 condition (ugly)
> - unfortunately this turned out to not be all, xen did not crash
> anymore at this point but dom0 kernel did around the time it enables
> cpus, in multiple places: at this point I didn't have a good
> explanation for it, my opinion of aggravating hunk was rather low,
> so I uttered a hearty curse and stuck a revert into private
> patchqueue.
> 
> The dom0 kernel crashes were as follows:
> 
> 1)
> 
> [   60.657751] Enabling non-boot CPUs ...
> [   60.657958] installing Xen timer for CPU 1
> [   60.657987] cpu 1 spinlock event irq 279
> [   60.658101] Disabled fast string operations
> [   60.658466] CPU1 is up
> [   60.658736] installing Xen timer for CPU 2
> [   60.658784] cpu 2 spinlock event irq 285
> [   60.659764] Disabled fast string operations
> [   60.661811] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000018
> [   60.661817] IP: [<ffffffff8105f700>]
> build_sched_domains+0x770/0(XEN) *** Serial input -> Xen (type
> 'CTRL-a' three times to switch input to DOM0)
> 
> 
> 
> 
> 2)
> .332997] installing Xen timer for CPU 2emory
> [   36.333061] cpu 2 spinlock event irq 285
> [   36.333343] Disabled fast string operations
> [   36.334939] CPU2 is up
> [   36.335213] installing Xen timer for CPU 3
> [   36.335244] cpu 3 spinlock event irq 291
> [   36.335561] Disabled fast string operations
> [   36.337461] CPU3 is up
> [   36.339513] ACPI: Waking up from system sleep state S3
> [   36.350193] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000004
> [   36.350211] IP: [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> [   36.350236] PGD 2f19067 PUD 2ec7067 PMD 0
> [   36.350252] Oops: 0000 [#1] SMP
> [   36.350263] CPU 1
> [   36.350267] Modules linked in: xt_mac ipt_MASQUERADE
> ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> [   36.350437]
> [   36.350445] Pid: 2730, comm: bash Tainted: G         C O
> 3.2.23-orc #19 LENOVO 42404EU/42404EU
> [   36.350463] RIP: e030:[<ffffffff81055f9a>]  [<ffffffff81055f9a>]
> find_busiest_group+0x38a/0xbb0
> [   36.350481] RSP: e02b:ffff880002b71228  EFLAGS: 00010046
> [   36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX:
> 0000000000000000
> [   36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
> 0000000000000000
> [   36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09:
> 0000000000000000
> [   36.350519] R10: 0000000000000000 R11: 0000000000000001 R12:
> 0000000000000000
> [   36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15:
> ffff880026109f98
> [   36.350547] FS:  00007fc41e295700(0000) GS:ffff88002dc40000(0000)
> knlGS:0000000000000000
> [   36.350558] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4:
> 0000000000002660
> [   36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [   36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [   36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000,
> task ffff880027a7db40)
> [   36.350608] Stack:
> [   36.350613]  00ffffff00000002 0000000300000001 ffff880002b71498
> ffff880002b71534
> [   36.350630]  00ffffff00000002 0000000100000001 ffff8800262cf000
> 0000000000000008
> [   36.350646]  ffffffff00000000 0000000000000000 0000000000000000
> ffff88002dc4e2c8
> [   36.350662] Call Trace:
> [   36.350677]  [<ffffffff8105b158>] load_balance+0xb8/0x840
> [   36.350690]  [<ffffffff8101b909>] ? sched_clock+0x9/0x10
> [   36.350706]  [<ffffffff8108ccad>] ? sched_clock_cpu+0xbd/0x110
> [   36.350718]  [<ffffffff81052b1c>] ? update_shares+0xcc/0x100
> [   36.350735]  [<ffffffff8157b9b5>] __schedule+0x875/0x8d0
> [   36.350749]  [<ffffffff81073ae2>] ? try_to_del_timer_sync+0x92/0x130
> [   36.350762]  [<ffffffff8157bd3f>] schedule+0x3f/0x60
> [   36.350773]  [<ffffffff8157c24d>] schedule_timeout+0x16d/0x320
> [   36.350786]  [<ffffffff810728e0>] ? usleep_range+0x50/0x50
> [   36.350800]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
> [   36.350817]  [<ffffffff8130c340>]
> acpi_ec_transaction_unlocked+0x134/0x1d8
> [   36.350830]  [<ffffffff81086b90>] ? add_wait_queue+0x60/0x60
> [   36.350842]  [<ffffffff8130c6c6>] acpi_ec_transaction+0x196/0x239
> [   36.350856]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
> [   36.350869]  [<ffffffff8130c8a0>] acpi_ec_write+0x40/0x42
> [   36.350881]  [<ffffffff8130c9a8>] acpi_ec_space_handler+0x9e/0xfc
> [   36.350894]  [<ffffffff8130c90a>] ? acpi_ec_burst_disable+0x3d/0x3d
> [   36.350909]  [<ffffffff813159c6>]
> acpi_ev_address_space_dispatch+0x179/0x1c8
> [   36.350924]  [<ffffffff8131aafe>] acpi_ex_access_region+0x23e/0x24b
> [   36.350936]  [<ffffffff8106e82c>] ? __sysctl_head_next+0x11c/0x130
> [   36.350951]  [<ffffffff8131ae15>] acpi_ex_field_datum_io+0xf9/0x17a
> [   36.350965]  [<ffffffff8131b148>]
> acpi_ex_write_with_update_rule+0xb5/0xc1
> [   36.350989]  [<ffffffff8131acfa>] acpi_ex_insert_into_field+0x1ef/0x211
> [   36.351003]  [<ffffffff8132b5a7>] ?
> acpi_ut_allocate_object_desc_dbg+0x45/0x7f
> [   36.351018]  [<ffffffff8131980e>] acpi_ex_write_data_to_field+0x194/0x1c2
> [   36.351031]  [<ffffffff813131e4>] ?
> acpi_ds_init_object_from_op+0x137/0x231
> [   36.351044]  [<ffffffff8131d94f>] acpi_ex_store_object_to_node+0xa3/0xe2
> [   36.351056]  [<ffffffff8131da51>] acpi_ex_store+0xc3/0x256
> [   36.351066]  [<ffffffff8131b62b>] acpi_ex_opcode_1A_1T_1R+0x353/0x4a5
> [   36.351078]  [<ffffffff8131260c>] acpi_ds_exec_end_op+0xf7/0x3e7
> [   36.351092]  [<ffffffff81325ae7>] acpi_ps_parse_loop+0x7bd/0x94e
> [   36.351105]  [<ffffffff81324ed9>] acpi_ps_parse_aml+0x96/0x275
> [   36.351119]  [<ffffffff81326394>] acpi_ps_execute_method+0x1ce/0x276
> [   36.351131]  [<ffffffff8132165b>] acpi_ns_evaluate+0xdf/0x1aa
> [   36.351144]  [<ffffffff81320c9d>] acpi_evaluate_object+0xfb/0x1f4
> [   36.351156]  [<ffffffff8130f8ee>] acpi_device_sleep_wake+0x95/0xc7
> [   36.351168]  [<ffffffff8130fa60>]
> acpi_disable_wakeup_device_power+0x6e/0xc9
> [   36.351182]  [<ffffffff813085e2>] acpi_disable_wakeup_devices+0x7b/0x95
> [   36.351194]  [<ffffffff81308710>] acpi_pm_finish+0x39/0x55
> [   36.351208]  [<ffffffff810a6034>] suspend_devices_and_enter+0x104/0x310
> [   36.351222]  [<ffffffff810a63a7>] enter_state+0x167/0x190
> [   36.351234]  [<ffffffff810a4d27>] state_store+0xb7/0x130
> [   36.351246]  [<ffffffff812b54df>] kobj_attr_store+0xf/0x30
> [   36.351260]  [<ffffffff811d382f>] sysfs_write_file+0xef/0x170
> [   36.351274]  [<ffffffff811668d3>] vfs_write+0xb3/0x180
> [   36.351286]  [<ffffffff81166bfa>] sys_write+0x4a/0x90
> [   36.351300]  [<ffffffff81585d02>] system_call_fastpath+0x16/0x1b
> [   36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8
> 5d fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b
> 4d 98 31 d2 <8b> 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0 48
> 85 c9 48
> [   36.351435] RIP  [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> [   36.351450]  RSP <ffff880002b71228>
> [   36.351456] CR2: 0000000000000004
> [   36.351465] ---[ end trace 5ad2b14b3a9050ae ]---
> [   36.352362] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000010
> [   36.352379] IP: [<ffffffff812ba531>] rb_next+0x1/0x50
> [   36.352394] PGD 0
> [   36.352402] Oops: 0000 [#2] SMP
> [   36.352411] CPU 1
> [   36.352416] Modules linked in: xt_mac ipt_MASQUERADE
> ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> [   36.352573]
> [   36.352580] Pid: 2730, comm: bash Tainted: G      D  C O
> 3.2.23-orc #19 LENOVO 42404EU/42404EU
> [   36.352596] RIP: e030:[<ffffffff812ba531>]  [<fffffff
> 
> 
> 
> 
> 3)
> 
> [   47.833362] Resuming Xen processor info
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> [   47.886297] Enabling non-boot CPUs ...
> [   47.890082] installing Xen timer for CPU 1
> [   47.894257] cpu 1 spinlock event irq 48
> [   47.899013] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> [   47.906740] IP: [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
> [   47.913578] PGD 34a4067 PUD 3ac3067 PMD 0
> [   47.917825] Oops: 0000 [#1] SMP
> [   47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebtables iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdisk(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs bridge stp llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul microcode psmouse serio_raw arc4 iwldvm mac80211 i915 drm_kms_helper drm iwlwifi intel_agp i2c_algo_bit cfg80211 intel_gtt video ahci libahci e1000e [last unloaded: tpm_bios]
> [   47.974636] CPU 0
> [   47.976456] Pid: 2468, comm: pm-suspend Tainted: G         C O 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake
> [   47.988310] RIP: e030:[<ffffffff8149196b>]  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
> [   47.997605] RSP: e02b:ffff880025685c98  EFLAGS: 00010286
> [   48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX: 0000000000000000
> [   48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI: ffff88002de40000
> [   48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09: 0000000000000000
> [   48.024520] R10: 0000000000000030 R11: 0000000000000000 R12: ffff88002de40000
> [   48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15: 0000000000000000
> [   48.038927] FS:  00007fb599d0e700(0000) GS:ffff88002de00000(0000) knlGS:0000000000000000
> [   48.047060] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4: 0000000000002660
> [   48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   48.074450] Process pm-suspend (pid: 2468, threadinfo ffff880025684000, task ffff880003558000)
> [   48.083102] Stack:
> [   48.085179]  ffff88002de40000 ffff88002de40000 00000000ffffffde ffffffff81a6b480
> [   48.092622]  ffff880025685cd8 ffffffff81491cc1 0000000000000001 ffff88002de40000
> [   48.100064]  ffff880025685cf8 ffffffff813046df 0000000000000001 0000000000000001
> [   48.107517] Call Trace:
> [   48.110029]  [<ffffffff81491cc1>] cpuidle_register_device+0x31/0x80
> [   48.116348]  [<ffffffff813046df>] intel_idle_cpu_init+0xbf/0x120
> [   48.122423]  [<ffffffff813047b0>] cpu_hotplug_notify+0x70/0x80
> [   48.128310]  [<ffffffff815a619d>] notifier_call_chain+0x4d/0x70
> [   48.134281]  [<ffffffff8107969e>] __raw_notifier_call_chain+0xe/0x10
> [   48.140686]  [<ffffffff81053bb0>] __cpu_notify+0x20/0x40
> [   48.146050]  [<ffffffff81594c7c>] _cpu_up+0xf1/0x138
> [   48.151070]  [<ffffffff8158ab39>] enable_nonboot_cpus+0x99/0xd0
> [   48.157090]  [<ffffffff81097b8d>] suspend_devices_and_enter+0x25d/0x330
> [   48.163752]  [<ffffffff81097def>] pm_suspend+0x18f/0x1f0
> [   48.169117]  [<ffffffff81096dea>] state_store+0x8a/0x100
> [   48.174483]  [<ffffffff812ac29f>] kobj_attr_store+0xf/0x30
> [   48.180022]  [<ffffffff811c005f>] sysfs_write_file+0xef/0x170
> [   48.185943]  [<ffffffff8115c253>] vfs_write+0xb3/0x180
> [   48.191056]  [<ffffffff8115c592>] sys_write+0x52/0xa0
> [   48.196160]  [<ffffffff815a614e>] ? do_page_fault+0xe/0x10
> [   48.201700]  [<ffffffff815aa7d9>] system_call_fastpath+0x16/0x1b
> [   48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e0 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a 00 00<48>  8b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 49 c7
> [   48.226658] RIP  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100

Hm, that is suspect. There should not be any cpuidle_register? Perhaps
you are .. ah yes, you are hitting a bug that should be in the stable
tree fix.

Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
6f8c2e7933679f54b6478945dc72e59ef9a3d5e0

> [   48.233582]  RSP<ffff880025685c98>
> [   48.237131] CR2: 0000000000000008
> 
> [   48.240521] ---[ end trace 535ebe28cd06b143 ]---
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:33:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2nKK-0004w7-8G; Tue, 05 Feb 2013 18:33: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 1U2nKI-0004w0-5U
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:33:02 +0000
Received: from [85.158.143.35:4624] by server-1.bemta-4.messagelabs.com id
	06/0F-08839-D5051115; Tue, 05 Feb 2013 18:33:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360089172!13916274!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15453 invoked from network); 5 Feb 2013 18:32:53 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 18:32:53 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15IWkLD019189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 18:32:47 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
	r15IWjhu009279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 18:32:46 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
	r15IWjM0025244; Tue, 5 Feb 2013 12:32:45 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 10:32:44 -0800
Date: Tue, 5 Feb 2013 13:32:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Message-ID: <20130205183236.GB5652@konrad-lan.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <510F885B.2040603@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Milan opath <milan.opath@gmail.com>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Mon, Feb 04, 2013 at 11:07:23AM +0100, Tomasz Wroblewski wrote:
> 
> >>fix-suspend-scheduler-v2
> >>fix-suspend-scheduler-revert-affinity-part
> >>s3-timerirq
> >>
> >>All of these fixes have been proposed to the xen-devel list, but have
> >>not yet been accepted, for one reason, or another.
> >And I don't think comments on them have seen follow-ups.
> >
> >Jan
> >
> I guess it's worth bringing this up again;
> 
> s3-timerirq: this was empirical hack which for some reason is needed
> on stable 4.2 we use, but not on latest unstable, didn't really
> investigate further since it appeared fixed later on anyway..
> 
> fix-suspend-scheduler/revert-affinity: the big objection here was
> the part which reverts one of the hunks in Keir's commit. I tried
> for quite few days to find a working fix which does not do this
> revert using posted suggestions, but was not succesfull:
> 
> - there was a crash in xen scheduler, which was fixable using your
> suggestion of masking softirqs during s3 (ugly)
> - there was also a crash in xen acpi cpufreq driver, which was
> similarily fixable using a bandaid s3 condition (ugly)
> - unfortunately this turned out to not be all, xen did not crash
> anymore at this point but dom0 kernel did around the time it enables
> cpus, in multiple places: at this point I didn't have a good
> explanation for it, my opinion of aggravating hunk was rather low,
> so I uttered a hearty curse and stuck a revert into private
> patchqueue.
> 
> The dom0 kernel crashes were as follows:
> 
> 1)
> 
> [   60.657751] Enabling non-boot CPUs ...
> [   60.657958] installing Xen timer for CPU 1
> [   60.657987] cpu 1 spinlock event irq 279
> [   60.658101] Disabled fast string operations
> [   60.658466] CPU1 is up
> [   60.658736] installing Xen timer for CPU 2
> [   60.658784] cpu 2 spinlock event irq 285
> [   60.659764] Disabled fast string operations
> [   60.661811] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000018
> [   60.661817] IP: [<ffffffff8105f700>]
> build_sched_domains+0x770/0(XEN) *** Serial input -> Xen (type
> 'CTRL-a' three times to switch input to DOM0)
> 
> 
> 
> 
> 2)
> .332997] installing Xen timer for CPU 2emory
> [   36.333061] cpu 2 spinlock event irq 285
> [   36.333343] Disabled fast string operations
> [   36.334939] CPU2 is up
> [   36.335213] installing Xen timer for CPU 3
> [   36.335244] cpu 3 spinlock event irq 291
> [   36.335561] Disabled fast string operations
> [   36.337461] CPU3 is up
> [   36.339513] ACPI: Waking up from system sleep state S3
> [   36.350193] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000004
> [   36.350211] IP: [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> [   36.350236] PGD 2f19067 PUD 2ec7067 PMD 0
> [   36.350252] Oops: 0000 [#1] SMP
> [   36.350263] CPU 1
> [   36.350267] Modules linked in: xt_mac ipt_MASQUERADE
> ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> [   36.350437]
> [   36.350445] Pid: 2730, comm: bash Tainted: G         C O
> 3.2.23-orc #19 LENOVO 42404EU/42404EU
> [   36.350463] RIP: e030:[<ffffffff81055f9a>]  [<ffffffff81055f9a>]
> find_busiest_group+0x38a/0xbb0
> [   36.350481] RSP: e02b:ffff880002b71228  EFLAGS: 00010046
> [   36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX:
> 0000000000000000
> [   36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
> 0000000000000000
> [   36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09:
> 0000000000000000
> [   36.350519] R10: 0000000000000000 R11: 0000000000000001 R12:
> 0000000000000000
> [   36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15:
> ffff880026109f98
> [   36.350547] FS:  00007fc41e295700(0000) GS:ffff88002dc40000(0000)
> knlGS:0000000000000000
> [   36.350558] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4:
> 0000000000002660
> [   36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [   36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [   36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000,
> task ffff880027a7db40)
> [   36.350608] Stack:
> [   36.350613]  00ffffff00000002 0000000300000001 ffff880002b71498
> ffff880002b71534
> [   36.350630]  00ffffff00000002 0000000100000001 ffff8800262cf000
> 0000000000000008
> [   36.350646]  ffffffff00000000 0000000000000000 0000000000000000
> ffff88002dc4e2c8
> [   36.350662] Call Trace:
> [   36.350677]  [<ffffffff8105b158>] load_balance+0xb8/0x840
> [   36.350690]  [<ffffffff8101b909>] ? sched_clock+0x9/0x10
> [   36.350706]  [<ffffffff8108ccad>] ? sched_clock_cpu+0xbd/0x110
> [   36.350718]  [<ffffffff81052b1c>] ? update_shares+0xcc/0x100
> [   36.350735]  [<ffffffff8157b9b5>] __schedule+0x875/0x8d0
> [   36.350749]  [<ffffffff81073ae2>] ? try_to_del_timer_sync+0x92/0x130
> [   36.350762]  [<ffffffff8157bd3f>] schedule+0x3f/0x60
> [   36.350773]  [<ffffffff8157c24d>] schedule_timeout+0x16d/0x320
> [   36.350786]  [<ffffffff810728e0>] ? usleep_range+0x50/0x50
> [   36.350800]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
> [   36.350817]  [<ffffffff8130c340>]
> acpi_ec_transaction_unlocked+0x134/0x1d8
> [   36.350830]  [<ffffffff81086b90>] ? add_wait_queue+0x60/0x60
> [   36.350842]  [<ffffffff8130c6c6>] acpi_ec_transaction+0x196/0x239
> [   36.350856]  [<ffffffff8157de2e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30
> [   36.350869]  [<ffffffff8130c8a0>] acpi_ec_write+0x40/0x42
> [   36.350881]  [<ffffffff8130c9a8>] acpi_ec_space_handler+0x9e/0xfc
> [   36.350894]  [<ffffffff8130c90a>] ? acpi_ec_burst_disable+0x3d/0x3d
> [   36.350909]  [<ffffffff813159c6>]
> acpi_ev_address_space_dispatch+0x179/0x1c8
> [   36.350924]  [<ffffffff8131aafe>] acpi_ex_access_region+0x23e/0x24b
> [   36.350936]  [<ffffffff8106e82c>] ? __sysctl_head_next+0x11c/0x130
> [   36.350951]  [<ffffffff8131ae15>] acpi_ex_field_datum_io+0xf9/0x17a
> [   36.350965]  [<ffffffff8131b148>]
> acpi_ex_write_with_update_rule+0xb5/0xc1
> [   36.350989]  [<ffffffff8131acfa>] acpi_ex_insert_into_field+0x1ef/0x211
> [   36.351003]  [<ffffffff8132b5a7>] ?
> acpi_ut_allocate_object_desc_dbg+0x45/0x7f
> [   36.351018]  [<ffffffff8131980e>] acpi_ex_write_data_to_field+0x194/0x1c2
> [   36.351031]  [<ffffffff813131e4>] ?
> acpi_ds_init_object_from_op+0x137/0x231
> [   36.351044]  [<ffffffff8131d94f>] acpi_ex_store_object_to_node+0xa3/0xe2
> [   36.351056]  [<ffffffff8131da51>] acpi_ex_store+0xc3/0x256
> [   36.351066]  [<ffffffff8131b62b>] acpi_ex_opcode_1A_1T_1R+0x353/0x4a5
> [   36.351078]  [<ffffffff8131260c>] acpi_ds_exec_end_op+0xf7/0x3e7
> [   36.351092]  [<ffffffff81325ae7>] acpi_ps_parse_loop+0x7bd/0x94e
> [   36.351105]  [<ffffffff81324ed9>] acpi_ps_parse_aml+0x96/0x275
> [   36.351119]  [<ffffffff81326394>] acpi_ps_execute_method+0x1ce/0x276
> [   36.351131]  [<ffffffff8132165b>] acpi_ns_evaluate+0xdf/0x1aa
> [   36.351144]  [<ffffffff81320c9d>] acpi_evaluate_object+0xfb/0x1f4
> [   36.351156]  [<ffffffff8130f8ee>] acpi_device_sleep_wake+0x95/0xc7
> [   36.351168]  [<ffffffff8130fa60>]
> acpi_disable_wakeup_device_power+0x6e/0xc9
> [   36.351182]  [<ffffffff813085e2>] acpi_disable_wakeup_devices+0x7b/0x95
> [   36.351194]  [<ffffffff81308710>] acpi_pm_finish+0x39/0x55
> [   36.351208]  [<ffffffff810a6034>] suspend_devices_and_enter+0x104/0x310
> [   36.351222]  [<ffffffff810a63a7>] enter_state+0x167/0x190
> [   36.351234]  [<ffffffff810a4d27>] state_store+0xb7/0x130
> [   36.351246]  [<ffffffff812b54df>] kobj_attr_store+0xf/0x30
> [   36.351260]  [<ffffffff811d382f>] sysfs_write_file+0xef/0x170
> [   36.351274]  [<ffffffff811668d3>] vfs_write+0xb3/0x180
> [   36.351286]  [<ffffffff81166bfa>] sys_write+0x4a/0x90
> [   36.351300]  [<ffffffff81585d02>] system_call_fastpath+0x16/0x1b
> [   36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8
> 5d fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b
> 4d 98 31 d2 <8b> 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0 48
> 85 c9 48
> [   36.351435] RIP  [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> [   36.351450]  RSP <ffff880002b71228>
> [   36.351456] CR2: 0000000000000004
> [   36.351465] ---[ end trace 5ad2b14b3a9050ae ]---
> [   36.352362] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000010
> [   36.352379] IP: [<ffffffff812ba531>] rb_next+0x1/0x50
> [   36.352394] PGD 0
> [   36.352402] Oops: 0000 [#2] SMP
> [   36.352411] CPU 1
> [   36.352416] Modules linked in: xt_mac ipt_MASQUERADE
> ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> [   36.352573]
> [   36.352580] Pid: 2730, comm: bash Tainted: G      D  C O
> 3.2.23-orc #19 LENOVO 42404EU/42404EU
> [   36.352596] RIP: e030:[<ffffffff812ba531>]  [<fffffff
> 
> 
> 
> 
> 3)
> 
> [   47.833362] Resuming Xen processor info
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> [   47.886297] Enabling non-boot CPUs ...
> [   47.890082] installing Xen timer for CPU 1
> [   47.894257] cpu 1 spinlock event irq 48
> [   47.899013] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> [   47.906740] IP: [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
> [   47.913578] PGD 34a4067 PUD 3ac3067 PMD 0
> [   47.917825] Oops: 0000 [#1] SMP
> [   47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebtables iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdisk(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs bridge stp llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul microcode psmouse serio_raw arc4 iwldvm mac80211 i915 drm_kms_helper drm iwlwifi intel_agp i2c_algo_bit cfg80211 intel_gtt video ahci libahci e1000e [last unloaded: tpm_bios]
> [   47.974636] CPU 0
> [   47.976456] Pid: 2468, comm: pm-suspend Tainted: G         C O 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake
> [   47.988310] RIP: e030:[<ffffffff8149196b>]  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100
> [   47.997605] RSP: e02b:ffff880025685c98  EFLAGS: 00010286
> [   48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX: 0000000000000000
> [   48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI: ffff88002de40000
> [   48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09: 0000000000000000
> [   48.024520] R10: 0000000000000030 R11: 0000000000000000 R12: ffff88002de40000
> [   48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15: 0000000000000000
> [   48.038927] FS:  00007fb599d0e700(0000) GS:ffff88002de00000(0000) knlGS:0000000000000000
> [   48.047060] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4: 0000000000002660
> [   48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   48.074450] Process pm-suspend (pid: 2468, threadinfo ffff880025684000, task ffff880003558000)
> [   48.083102] Stack:
> [   48.085179]  ffff88002de40000 ffff88002de40000 00000000ffffffde ffffffff81a6b480
> [   48.092622]  ffff880025685cd8 ffffffff81491cc1 0000000000000001 ffff88002de40000
> [   48.100064]  ffff880025685cf8 ffffffff813046df 0000000000000001 0000000000000001
> [   48.107517] Call Trace:
> [   48.110029]  [<ffffffff81491cc1>] cpuidle_register_device+0x31/0x80
> [   48.116348]  [<ffffffff813046df>] intel_idle_cpu_init+0xbf/0x120
> [   48.122423]  [<ffffffff813047b0>] cpu_hotplug_notify+0x70/0x80
> [   48.128310]  [<ffffffff815a619d>] notifier_call_chain+0x4d/0x70
> [   48.134281]  [<ffffffff8107969e>] __raw_notifier_call_chain+0xe/0x10
> [   48.140686]  [<ffffffff81053bb0>] __cpu_notify+0x20/0x40
> [   48.146050]  [<ffffffff81594c7c>] _cpu_up+0xf1/0x138
> [   48.151070]  [<ffffffff8158ab39>] enable_nonboot_cpus+0x99/0xd0
> [   48.157090]  [<ffffffff81097b8d>] suspend_devices_and_enter+0x25d/0x330
> [   48.163752]  [<ffffffff81097def>] pm_suspend+0x18f/0x1f0
> [   48.169117]  [<ffffffff81096dea>] state_store+0x8a/0x100
> [   48.174483]  [<ffffffff812ac29f>] kobj_attr_store+0xf/0x30
> [   48.180022]  [<ffffffff811c005f>] sysfs_write_file+0xef/0x170
> [   48.185943]  [<ffffffff8115c253>] vfs_write+0xb3/0x180
> [   48.191056]  [<ffffffff8115c592>] sys_write+0x52/0xa0
> [   48.196160]  [<ffffffff815a614e>] ? do_page_fault+0xe/0x10
> [   48.201700]  [<ffffffff815aa7d9>] system_call_fastpath+0x16/0x1b
> [   48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e0 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a 00 00<48>  8b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 49 c7
> [   48.226658] RIP  [<ffffffff8149196b>] __cpuidle_register_device+0x2b/0x100

Hm, that is suspect. There should not be any cpuidle_register? Perhaps
you are .. ah yes, you are hitting a bug that should be in the stable
tree fix.

Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
6f8c2e7933679f54b6478945dc72e59ef9a3d5e0

> [   48.233582]  RSP<ffff880025685c98>
> [   48.237131] CR2: 0000000000000008
> 
> [   48.240521] ---[ end trace 535ebe28cd06b143 ]---
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:37:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2nOP-0005Hr-VB; Tue, 05 Feb 2013 18:37:17 +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 1U2nOO-0005Hi-9A
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:37:16 +0000
Received: from [85.158.143.35:30098] by server-2.bemta-4.messagelabs.com id
	1A/29-01597-55151115; Tue, 05 Feb 2013 18:37:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360089379!11294078!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 5 Feb 2013 18:36:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6048572"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 18:36:19 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	13:36:18 -0500
Message-ID: <51115121.4060806@citrix.com>
Date: Tue, 5 Feb 2013 18:36:17 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510FF54E.1070706@citrix.com>
	<1360012076.7477.132.camel@zion.uk.xensource.com>
In-Reply-To: <1360012076.7477.132.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 21:07, Wei Liu wrote:
> 
> Where is the "priority" information stored? I think it should be
> somewhere inside Xen, right? I presume a field in struct evtchn?

I think so. I've not really thought too much about the internal design.

>> ### `EVTCHNOP_init`
>>
>> This call initializes a single VCPU's event channel data structures,
>> adding one page for the event array.
>>
> 
> I think the registration for new event channels should always be done in
> a batch. If not then you need to provide another OP to rollback previous
> registered ones.

Hmmm. That's an interesting point.  I'd be inclined to have the guest
take the VCPU offline if it cannot initialize it fully.

>> Each page of the event array has space for 1024 events ($E_P$) so a
>> regular domU will only require a single page.  Since event channels
>> typically come in pairs, the upper bound on the total number of pages
>                                ^^^^^
>                                upper or lower?

I meant upper, but I am playing fast-and-loose with the maths here since
I was aiming for an estimate rather than a real upper bound.

>> is $2 \times\text{number of VMs}$.
>>
>> If the guests are further restricted in the number of event channels
>> ($E_V$) then this upper bound can be reduced further.
>>
> 
> Can this bound really be reduced? Can you map memory on non-page
> granularity?

The reasoning here is that event channels are in pairs (or rather they
have two ends).  One event is the domU, the other in dom0.  The events
in dom0 are packed into pages, whereas the domU events use 1 page no
matter how few events there are.

I wasn't entirely happy with this way of doing the estimate which is why
I did the second method, which gave a similar figure.

>> The number of VMs ($V$) with a limit of $P$ total event array pages is:
>> \begin{equation*}
>> V = P \div \left(1 + \frac{E_V}{E_P}\right)
                    ^         ^^^^^^^^^
The page in domU             The fraction of a page in dom0.


>> Raising an Event
>> ----------------
>>
>> When Xen raises an event it marks it pending and (if it is not masked)
>> adds it tail of event queue.
>>
>>     E[p].pending = 1
>>     if not E[p].linked and not E[n].masked
>>         E[p].linked = 1
>>         E[p].link = 0
>>         mb()
>>         if H == 0
>>             H = p
>>         else
>>             E[T].link = p
>>         T = p
>>
>> Concurrent access by Xen to the event queue must be protected by a
>> per-event queue spin lock.
>>
> 
> I presume "E[n]" in the pseudo code is "E[p]"?

Yes.

> Is this spin lock really a good idea? How many threads / cpus will spin
> on this lock? As [0] shows, contention on spin lock incurs heavy
> performance penalty.

In addition to Keir's comment, the spinlock itself won't reside in the
same cache line as the control block or event array so this will reduce
cache line bouncing.

> [0] https://lwn.net/Articles/530458/
> 
>> Consuming Events
>> ----------------
>>
>> The guests consumes events starting at the head until it reaches the
>> tail.  Events in the queue that are not pending or are masked are
>> consumed but not handled.
>>
>>     while H != 0
>>         p = H
>>         H = E[p].link
>>         if H == 0
>>             mb()
>>             H = E[p].link
>>         E[H].linked = 0
>>         if not E[p].masked
>>             handle(p)
>>
>> handle() clears `E[p].pending` and EOIs level-triggered PIRQs.
>>
> 
> How to synchronize access to the array and control blocks between Xen
> and guest? I'm afraid I have no knowledge of a xen-guest spin lock...

It's a lockless data structure on the consumer side (provided there is
only one consumer).

>> Unmasking Events
>> ----------------
>>
>> Events are unmasked by the guest by clearing the masked bit.  If the
>> event is pending the guest must call the event channel unmask
>> hypercall so Xen can link the event into the correct event queue.
>>
>>     E[p].masked = 0
>>     if E[p].pending
>>         hypercall(EVTCHN_unmask)
>>
>> The expectation here is that unmasking a pending event will be rare,
>> so the performance hit of the hypercall is minimal.
>>
> 
> Currently unmask a "remote" port requires issuing hyercall as well, so
> if unmasking is not very frequent, this is not a big problem.
> 
> But please take some interrupt-intensive workloads into consideration.
> For example, 1G nic (e1000) even with NAPI enabled can generate 27k+
> intrs per second under high packet load [1], 10G nic can surely generate
> more. Can you give estimation on the performance hit on the context
> switch?

I'm not sure how I would give an estimate, this is something that would
need to be measured I think.

Also, whilst the upcall itself might be reentrant, the processing of
each queue cannot be so the mask/unmask done by the irq_chip callbacks
isn't needed.  mask/unmask is then only needed occasionally (e.g., for
irq migration) and thus isn't so performance critical.

>>> Note: that after clearing the mask bit, the event may be raised and
>>> thus it may already be linked by the time the hypercall is done.
> 
> Even if the event has already been linked before you finish the
> hypercall, you would still need to get hold of the a lock to serialize
> access to event structure for checking, right? Or a test_bit on linked
> field is sufficient? I think you need to write some pseudo code for this
> as well.

Xen will need to take the per-queue lock for this, yes.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:37:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2nOP-0005Hr-VB; Tue, 05 Feb 2013 18:37:17 +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 1U2nOO-0005Hi-9A
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:37:16 +0000
Received: from [85.158.143.35:30098] by server-2.bemta-4.messagelabs.com id
	1A/29-01597-55151115; Tue, 05 Feb 2013 18:37:09 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360089379!11294078!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 5 Feb 2013 18:36:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6048572"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 18:36:19 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	13:36:18 -0500
Message-ID: <51115121.4060806@citrix.com>
Date: Tue, 5 Feb 2013 18:36:17 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510FF54E.1070706@citrix.com>
	<1360012076.7477.132.camel@zion.uk.xensource.com>
In-Reply-To: <1360012076.7477.132.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/13 21:07, Wei Liu wrote:
> 
> Where is the "priority" information stored? I think it should be
> somewhere inside Xen, right? I presume a field in struct evtchn?

I think so. I've not really thought too much about the internal design.

>> ### `EVTCHNOP_init`
>>
>> This call initializes a single VCPU's event channel data structures,
>> adding one page for the event array.
>>
> 
> I think the registration for new event channels should always be done in
> a batch. If not then you need to provide another OP to rollback previous
> registered ones.

Hmmm. That's an interesting point.  I'd be inclined to have the guest
take the VCPU offline if it cannot initialize it fully.

>> Each page of the event array has space for 1024 events ($E_P$) so a
>> regular domU will only require a single page.  Since event channels
>> typically come in pairs, the upper bound on the total number of pages
>                                ^^^^^
>                                upper or lower?

I meant upper, but I am playing fast-and-loose with the maths here since
I was aiming for an estimate rather than a real upper bound.

>> is $2 \times\text{number of VMs}$.
>>
>> If the guests are further restricted in the number of event channels
>> ($E_V$) then this upper bound can be reduced further.
>>
> 
> Can this bound really be reduced? Can you map memory on non-page
> granularity?

The reasoning here is that event channels are in pairs (or rather they
have two ends).  One event is the domU, the other in dom0.  The events
in dom0 are packed into pages, whereas the domU events use 1 page no
matter how few events there are.

I wasn't entirely happy with this way of doing the estimate which is why
I did the second method, which gave a similar figure.

>> The number of VMs ($V$) with a limit of $P$ total event array pages is:
>> \begin{equation*}
>> V = P \div \left(1 + \frac{E_V}{E_P}\right)
                    ^         ^^^^^^^^^
The page in domU             The fraction of a page in dom0.


>> Raising an Event
>> ----------------
>>
>> When Xen raises an event it marks it pending and (if it is not masked)
>> adds it tail of event queue.
>>
>>     E[p].pending = 1
>>     if not E[p].linked and not E[n].masked
>>         E[p].linked = 1
>>         E[p].link = 0
>>         mb()
>>         if H == 0
>>             H = p
>>         else
>>             E[T].link = p
>>         T = p
>>
>> Concurrent access by Xen to the event queue must be protected by a
>> per-event queue spin lock.
>>
> 
> I presume "E[n]" in the pseudo code is "E[p]"?

Yes.

> Is this spin lock really a good idea? How many threads / cpus will spin
> on this lock? As [0] shows, contention on spin lock incurs heavy
> performance penalty.

In addition to Keir's comment, the spinlock itself won't reside in the
same cache line as the control block or event array so this will reduce
cache line bouncing.

> [0] https://lwn.net/Articles/530458/
> 
>> Consuming Events
>> ----------------
>>
>> The guests consumes events starting at the head until it reaches the
>> tail.  Events in the queue that are not pending or are masked are
>> consumed but not handled.
>>
>>     while H != 0
>>         p = H
>>         H = E[p].link
>>         if H == 0
>>             mb()
>>             H = E[p].link
>>         E[H].linked = 0
>>         if not E[p].masked
>>             handle(p)
>>
>> handle() clears `E[p].pending` and EOIs level-triggered PIRQs.
>>
> 
> How to synchronize access to the array and control blocks between Xen
> and guest? I'm afraid I have no knowledge of a xen-guest spin lock...

It's a lockless data structure on the consumer side (provided there is
only one consumer).

>> Unmasking Events
>> ----------------
>>
>> Events are unmasked by the guest by clearing the masked bit.  If the
>> event is pending the guest must call the event channel unmask
>> hypercall so Xen can link the event into the correct event queue.
>>
>>     E[p].masked = 0
>>     if E[p].pending
>>         hypercall(EVTCHN_unmask)
>>
>> The expectation here is that unmasking a pending event will be rare,
>> so the performance hit of the hypercall is minimal.
>>
> 
> Currently unmask a "remote" port requires issuing hyercall as well, so
> if unmasking is not very frequent, this is not a big problem.
> 
> But please take some interrupt-intensive workloads into consideration.
> For example, 1G nic (e1000) even with NAPI enabled can generate 27k+
> intrs per second under high packet load [1], 10G nic can surely generate
> more. Can you give estimation on the performance hit on the context
> switch?

I'm not sure how I would give an estimate, this is something that would
need to be measured I think.

Also, whilst the upcall itself might be reentrant, the processing of
each queue cannot be so the mask/unmask done by the irq_chip callbacks
isn't needed.  mask/unmask is then only needed occasionally (e.g., for
irq migration) and thus isn't so performance critical.

>>> Note: that after clearing the mask bit, the event may be raised and
>>> thus it may already be linked by the time the hypercall is done.
> 
> Even if the event has already been linked before you finish the
> hypercall, you would still need to get hold of the a lock to serialize
> access to event structure for checking, right? Or a test_bit on linked
> field is sufficient? I think you need to write some pseudo code for this
> as well.

Xen will need to take the per-queue lock for this, yes.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:58:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2niV-0005qZ-UY; Tue, 05 Feb 2013 18:58:03 +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 1U2niU-0005qU-NW
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:58:02 +0000
Received: from [85.158.139.211:50953] by server-5.bemta-5.messagelabs.com id
	FE/0F-11945-A3651115; Tue, 05 Feb 2013 18:58:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360090680!18433504!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7984 invoked from network); 5 Feb 2013 18:58:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:58:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6051876"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 18:57:59 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	13:57:59 -0500
Message-ID: <51115636.6080907@citrix.com>
Date: Tue, 5 Feb 2013 18:57:58 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com>
	<51111BCA.3010207@citrix.com>	<1360077399.7477.148.camel@zion.uk.xensource.com>
	<CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
In-Reply-To: <CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
X-Originating-IP: [10.80.2.76]
Cc: Keir Fraser <keir.xen@gmail.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 18:05, George Dunlap wrote:
> On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <wei.liu2@citrix.com
> <mailto:wei.liu2@citrix.com>> wrote:
> 
>     > Since the ABI needs to be changed to support more event channels
>     anyway,
>     > it seems an ideal point to revisit the design.
>     >
> 
>     Right. I do care about better design and good implementation. Can we
>     build a prototype of this design? We are less than two months away from
>     4.3 feature freeze, and the event channel scalability is planned for
>     that release, which means we need to be hurried. :-)

Two months doesn't seem possible even if I could work on this full time.

> I think the general consensus is that scaling event channels is pretty
> important -- probably important enough to slip the release a bit if
> necessary.  (Although it would certainly be better not to.)

What to do here is a non-trivial decision.  Possible options include:

1. Merge the 3-level ABI for 4.3.  Work on the FIFO-based ABI in
parallel, aiming to get this in for 4.4.  This means maintaining 3 event
channel ABIs in Xen.

2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.

3. Status quo.  Defer extending the event channel ABI to 4.4.

The preferable option may be to:

4. Get the 3-level ABI to a mergable state. In parallel develop a
prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
freeze is here, evaluate it and make a decision then.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 18:58:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 18: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 1U2niV-0005qZ-UY; Tue, 05 Feb 2013 18:58:03 +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 1U2niU-0005qU-NW
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 18:58:02 +0000
Received: from [85.158.139.211:50953] by server-5.bemta-5.messagelabs.com id
	FE/0F-11945-A3651115; Tue, 05 Feb 2013 18:58:02 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360090680!18433504!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7984 invoked from network); 5 Feb 2013 18:58:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 18:58:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6051876"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 18:57:59 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Feb 2013
	13:57:59 -0500
Message-ID: <51115636.6080907@citrix.com>
Date: Tue, 5 Feb 2013 18:57:58 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com>
	<51111BCA.3010207@citrix.com>	<1360077399.7477.148.camel@zion.uk.xensource.com>
	<CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
In-Reply-To: <CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
X-Originating-IP: [10.80.2.76]
Cc: Keir Fraser <keir.xen@gmail.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 18:05, George Dunlap wrote:
> On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <wei.liu2@citrix.com
> <mailto:wei.liu2@citrix.com>> wrote:
> 
>     > Since the ABI needs to be changed to support more event channels
>     anyway,
>     > it seems an ideal point to revisit the design.
>     >
> 
>     Right. I do care about better design and good implementation. Can we
>     build a prototype of this design? We are less than two months away from
>     4.3 feature freeze, and the event channel scalability is planned for
>     that release, which means we need to be hurried. :-)

Two months doesn't seem possible even if I could work on this full time.

> I think the general consensus is that scaling event channels is pretty
> important -- probably important enough to slip the release a bit if
> necessary.  (Although it would certainly be better not to.)

What to do here is a non-trivial decision.  Possible options include:

1. Merge the 3-level ABI for 4.3.  Work on the FIFO-based ABI in
parallel, aiming to get this in for 4.4.  This means maintaining 3 event
channel ABIs in Xen.

2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.

3. Status quo.  Defer extending the event channel ABI to 4.4.

The preferable option may be to:

4. Get the 3-level ABI to a mergable state. In parallel develop a
prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
freeze is here, evaluate it and make a decision then.

David

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 19:03:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19: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 1U2nns-0006Cc-Ni; Tue, 05 Feb 2013 19:03:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2nnq-0006CW-G7
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 19:03:34 +0000
Received: from [85.158.138.51:23901] by server-7.bemta-3.messagelabs.com id
	BA/F1-10367-58751115; Tue, 05 Feb 2013 19:03:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360091011!27759612!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12646 invoked from network); 5 Feb 2013 19:03:32 -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;
	5 Feb 2013 19:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6053361"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 19:03:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 14:03:29 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2nnl-00089e-UM;
	Tue, 05 Feb 2013 19:03:29 +0000
Message-ID: <1360091009.7477.179.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 19:03:29 +0000
In-Reply-To: <51115636.6080907@citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
	<1360077399.7477.148.camel@zion.uk.xensource.com>
	<CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
	<51115636.6080907@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir
	Fraser <keir.xen@gmail.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:57 +0000, David Vrabel wrote:
> On 05/02/13 18:05, George Dunlap wrote:
> > On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <wei.liu2@citrix.com
> > <mailto:wei.liu2@citrix.com>> wrote:
> > 
> >     > Since the ABI needs to be changed to support more event channels
> >     anyway,
> >     > it seems an ideal point to revisit the design.
> >     >
> > 
> >     Right. I do care about better design and good implementation. Can we
> >     build a prototype of this design? We are less than two months away from
> >     4.3 feature freeze, and the event channel scalability is planned for
> >     that release, which means we need to be hurried. :-)
> 
> Two months doesn't seem possible even if I could work on this full time.
> 
> > I think the general consensus is that scaling event channels is pretty
> > important -- probably important enough to slip the release a bit if
> > necessary.  (Although it would certainly be better not to.)
> 
> What to do here is a non-trivial decision.  Possible options include:
> 
> 1. Merge the 3-level ABI for 4.3.  Work on the FIFO-based ABI in
> parallel, aiming to get this in for 4.4.  This means maintaining 3 event
> channel ABIs in Xen.
> 
> 2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.
> 3. Status quo.  Defer extending the event channel ABI to 4.4.
> 
> The preferable option may be to:
> 
> 4. Get the 3-level ABI to a mergable state. In parallel develop a
> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
> freeze is here, evaluate it and make a decision then.
> 

Actually this is what I'm thinking now.


Wei.

> David



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 19:03:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19: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 1U2nns-0006Cc-Ni; Tue, 05 Feb 2013 19:03:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U2nnq-0006CW-G7
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 19:03:34 +0000
Received: from [85.158.138.51:23901] by server-7.bemta-3.messagelabs.com id
	BA/F1-10367-58751115; Tue, 05 Feb 2013 19:03:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360091011!27759612!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12646 invoked from network); 5 Feb 2013 19:03:32 -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;
	5 Feb 2013 19:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="6053361"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	05 Feb 2013 19:03:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 5 Feb 2013 14:03:29 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U2nnl-00089e-UM;
	Tue, 05 Feb 2013 19:03:29 +0000
Message-ID: <1360091009.7477.179.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 5 Feb 2013 19:03:29 +0000
In-Reply-To: <51115636.6080907@citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
	<1360077399.7477.148.camel@zion.uk.xensource.com>
	<CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
	<51115636.6080907@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir
	Fraser <keir.xen@gmail.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:57 +0000, David Vrabel wrote:
> On 05/02/13 18:05, George Dunlap wrote:
> > On Tue, Feb 5, 2013 at 3:16 PM, Wei Liu <wei.liu2@citrix.com
> > <mailto:wei.liu2@citrix.com>> wrote:
> > 
> >     > Since the ABI needs to be changed to support more event channels
> >     anyway,
> >     > it seems an ideal point to revisit the design.
> >     >
> > 
> >     Right. I do care about better design and good implementation. Can we
> >     build a prototype of this design? We are less than two months away from
> >     4.3 feature freeze, and the event channel scalability is planned for
> >     that release, which means we need to be hurried. :-)
> 
> Two months doesn't seem possible even if I could work on this full time.
> 
> > I think the general consensus is that scaling event channels is pretty
> > important -- probably important enough to slip the release a bit if
> > necessary.  (Although it would certainly be better not to.)
> 
> What to do here is a non-trivial decision.  Possible options include:
> 
> 1. Merge the 3-level ABI for 4.3.  Work on the FIFO-based ABI in
> parallel, aiming to get this in for 4.4.  This means maintaining 3 event
> channel ABIs in Xen.
> 
> 2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.
> 3. Status quo.  Defer extending the event channel ABI to 4.4.
> 
> The preferable option may be to:
> 
> 4. Get the 3-level ABI to a mergable state. In parallel develop a
> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
> freeze is here, evaluate it and make a decision then.
> 

Actually this is what I'm thinking now.


Wei.

> David



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

From xen-devel-bounces@lists.xen.org Tue Feb 05 19:35:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19:35: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 1U2oIF-0006z8-N5; Tue, 05 Feb 2013 19:34: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 1U2oIE-0006z3-MI
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 19:34:59 +0000
Received: from [85.158.143.99:19498] by server-2.bemta-4.messagelabs.com id
	31/0B-01597-1EE51115; Tue, 05 Feb 2013 19:34:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360092897!23393035!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24445 invoked from network); 5 Feb 2013 19:34:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 19:34:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1170963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 19:34: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.297.1; Tue, 5 Feb 2013 19:34:56 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2oIC-0000Sp-LT;
	Tue, 05 Feb 2013 19:34:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2oIC-0002Bp-GL;
	Tue, 05 Feb 2013 19:34:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15421-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Feb 2013 19:34:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15421: 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 15421 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15421/

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. 15417
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15417
 test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15417
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15417
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 15417
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 15417
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15417
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 15417
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15417
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 15417
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 15417
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 15417
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15417
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 15417
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 15417

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15417

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  ff77e84ddfdc
baseline version:
 xen                  d1bf3b21f783

------------------------------------------------------------
People who touched revisions under test:
  Dongxiao Xu <dongxiao.xu@intel.com>
  Eddie Dong <eddie.dong@intel.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26506:ff77e84ddfdc
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 04 12:10:26 2013 +0100
    
    x86/EFI: simplify PCI option ROM retrieval
    
    While putting together the kernel side of this I realized that c/s
    26397:d9c7b82aa7b1 went a little too far in requiring a buffer for the
    option ROM contents - all that is really needed is handing Dom0
    physical address and size of the data block.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26505:de6160ccaf9d
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Mon Feb 04 12:08:15 2013 +0100
    
    nEPT: fix INVEPT instruction parameter
    
    While emulating the INVEPT instruction in L0 VMM, the EPT pointer
    should be fetched from the instruction decoding result, but not
    the current loaded EPT pointer.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Acked-by: Eddie Dong <eddie.dong@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26504:90525fcb0982
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Mon Feb 04 12:07:34 2013 +0100
    
    nEPT: fix EPT pointer setting for L2 guest
    
    Each time in virtual_vmentry(), the code needs to cover both EPT
    and shadow mode for L2 guest, updating different EPT pointer to
    shadow VMCS.
    
    This fixes the issue that, launch a guest with EPT, then kill it
    and launch a second guest with shadow, the second guest will hang
    at the startup screen.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Acked by: Eddie Dong <eddie.dong@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26503:69398345c10e
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 04 12:03:38 2013 +0100
    
    x86/nestedhvm: properly clean up after failure to set up all vCPU-s
    
    This implies that the individual destroy functions will have to remain
    capable of being called for a vCPU that the corresponding init function
    was never run on.
    
    Once at it, also clean up some inefficiencies in the corresponding
    parameter validation code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26502:d1bf3b21f783
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Wed Jan 30 09:17:30 2013 -0800
    
    VMX: disable SMEP feature when guest is in non-paging mode
    
    SMEP is disabled if CPU is in non-paging mode in hardware.
    However Xen always uses paging mode to emulate guest non-paging
    mode with HAP. To emulate this behavior, SMEP needs to be manually
    disabled when guest switches to non-paging mode.
    
    We met an issue that, SMP Linux guest with recent kernel (enable
    SMEP support, for example, 3.5.3) would crash with triple fault if
    setting unrestricted_guest=0 in grub. This is because Xen uses an
    identity mapping page table to emulate the non-paging mode, where
    the page table is set with USER flag. If SMEP is still enabled in
    this case, guest will meet unhandlable page fault and then crash.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 05 19:35:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19:35: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 1U2oIF-0006z8-N5; Tue, 05 Feb 2013 19:34: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 1U2oIE-0006z3-MI
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 19:34:59 +0000
Received: from [85.158.143.99:19498] by server-2.bemta-4.messagelabs.com id
	31/0B-01597-1EE51115; Tue, 05 Feb 2013 19:34:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360092897!23393035!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIwODEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24445 invoked from network); 5 Feb 2013 19:34:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 19:34:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; 
   d="scan'208";a="1170963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Feb 2013 19:34: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.297.1; Tue, 5 Feb 2013 19:34:56 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2oIC-0000Sp-LT;
	Tue, 05 Feb 2013 19:34:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2oIC-0002Bp-GL;
	Tue, 05 Feb 2013 19:34:56 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15421-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 5 Feb 2013 19:34:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15421: 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 15421 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15421/

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. 15417
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15417
 test-amd64-i386-qemut-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 15417
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 15417
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 15417
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 15417
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15417
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 15417
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15417
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 15417
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 15417
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 15417
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15417
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15417
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 15417
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 15417

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15417

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-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                  ff77e84ddfdc
baseline version:
 xen                  d1bf3b21f783

------------------------------------------------------------
People who touched revisions under test:
  Dongxiao Xu <dongxiao.xu@intel.com>
  Eddie Dong <eddie.dong@intel.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26506:ff77e84ddfdc
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 04 12:10:26 2013 +0100
    
    x86/EFI: simplify PCI option ROM retrieval
    
    While putting together the kernel side of this I realized that c/s
    26397:d9c7b82aa7b1 went a little too far in requiring a buffer for the
    option ROM contents - all that is really needed is handing Dom0
    physical address and size of the data block.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26505:de6160ccaf9d
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Mon Feb 04 12:08:15 2013 +0100
    
    nEPT: fix INVEPT instruction parameter
    
    While emulating the INVEPT instruction in L0 VMM, the EPT pointer
    should be fetched from the instruction decoding result, but not
    the current loaded EPT pointer.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Acked-by: Eddie Dong <eddie.dong@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26504:90525fcb0982
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Mon Feb 04 12:07:34 2013 +0100
    
    nEPT: fix EPT pointer setting for L2 guest
    
    Each time in virtual_vmentry(), the code needs to cover both EPT
    and shadow mode for L2 guest, updating different EPT pointer to
    shadow VMCS.
    
    This fixes the issue that, launch a guest with EPT, then kill it
    and launch a second guest with shadow, the second guest will hang
    at the startup screen.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Acked by: Eddie Dong <eddie.dong@intel.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26503:69398345c10e
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Feb 04 12:03:38 2013 +0100
    
    x86/nestedhvm: properly clean up after failure to set up all vCPU-s
    
    This implies that the individual destroy functions will have to remain
    capable of being called for a vCPU that the corresponding init function
    was never run on.
    
    Once at it, also clean up some inefficiencies in the corresponding
    parameter validation code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26502:d1bf3b21f783
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Wed Jan 30 09:17:30 2013 -0800
    
    VMX: disable SMEP feature when guest is in non-paging mode
    
    SMEP is disabled if CPU is in non-paging mode in hardware.
    However Xen always uses paging mode to emulate guest non-paging
    mode with HAP. To emulate this behavior, SMEP needs to be manually
    disabled when guest switches to non-paging mode.
    
    We met an issue that, SMP Linux guest with recent kernel (enable
    SMEP support, for example, 3.5.3) would crash with triple fault if
    setting unrestricted_guest=0 in grub. This is because Xen uses an
    identity mapping page table to emulate the non-paging mode, where
    the page table is set with USER flag. If SMEP is still enabled in
    this case, guest will meet unhandlable page fault and then crash.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 05 19:45:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19:45: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 1U2oRW-0007KJ-SH; Tue, 05 Feb 2013 19:44:34 +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 1U2oRV-0007KE-Fr
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 19:44:33 +0000
Received: from [85.158.137.99:14943] by server-3.bemta-3.messagelabs.com id
	8D/99-31070-02161115; Tue, 05 Feb 2013 19:44:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360093469!19280127!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7219 invoked from network); 5 Feb 2013 19:44:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 19:44:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15JiOOn018131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 19:44:25 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
	r15JiMhE007459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 19:44:23 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
	r15JiLPO024778; Tue, 5 Feb 2013 13:44:21 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 11:44:21 -0800
Date: Tue, 5 Feb 2013 14:44:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205194412.GC6906@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
	<1360084131.7477.156.camel@zion.uk.xensource.com>
	<20130205171938.GI2187@konrad-lan.dumpdata.com>
	<1360085001.7477.166.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360085001.7477.166.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, Feb 05, 2013 at 05:23:21PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:19 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 05, 2013 at 05:08:51PM +0000, Wei Liu wrote:
> > > On Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > > > > Use global pointers in common operations to allow for better code sharing
> > > > > between N-level event channel.
> > > > >
> > > > > Functions which are not suitable for sharing are also taken care of.
> > > > >
> > > > > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> > > > >
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > ---
> > > > >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> > > > >  drivers/xen/evtchn.c |   12 ++--
> > > > >  include/xen/events.h |    2 +
> > > > >  3 files changed, 123 insertions(+), 71 deletions(-)
> > > > >
> > > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > > index 0679d27..4820a52 100644
> > > > > --- a/drivers/xen/events.c
> > > > > +++ b/drivers/xen/events.c
> > > > > @@ -51,6 +51,16 @@
> > > > >  #include <xen/interface/hvm/hvm_op.h>
> > > > >  #include <xen/interface/hvm/params.h>
> > > > >
> > > > > +/* N-level event channel, starting from 2 */
> > > > > +unsigned int evtchn_level = 2;
> > > > 
> > > > What if the hypervisor does not support that? Shouldn't be by default
> > > > at 1?
> > > > 
> > > 
> > > the default implementation is 2 level. ;-)
> > 
> > I am looking at evtchn_pending and evtchn_mask in the 'struct
> > shared_info' (include/xen/interface/xen.h) and it is not obvious from
> > that. What am I missing? 
> > 
> 
> To avoid scanning the whole bitmap when doing upcall, every vcpu is
> equipped with a selector - embedded in struct vcpu_info.
> 
> So it is a 2-level event lookup path.
> 
Ah, OK. I was thinking of the normal 2 level lookup - like a page-table.

Could you include the explanation in the patch please? Thank you.

> 
> Wei
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 19:45:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19:45: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 1U2oRW-0007KJ-SH; Tue, 05 Feb 2013 19:44:34 +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 1U2oRV-0007KE-Fr
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 19:44:33 +0000
Received: from [85.158.137.99:14943] by server-3.bemta-3.messagelabs.com id
	8D/99-31070-02161115; Tue, 05 Feb 2013 19:44:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360093469!19280127!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTUxMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7219 invoked from network); 5 Feb 2013 19:44:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Feb 2013 19:44:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15JiOOn018131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 19:44:25 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
	r15JiMhE007459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 19:44:23 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
	r15JiLPO024778; Tue, 5 Feb 2013 13:44:21 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 11:44:21 -0800
Date: Tue, 5 Feb 2013 14:44:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205194412.GC6906@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-8-git-send-email-wei.liu2@citrix.com>
	<20130205170430.GF2187@konrad-lan.dumpdata.com>
	<1360084131.7477.156.camel@zion.uk.xensource.com>
	<20130205171938.GI2187@konrad-lan.dumpdata.com>
	<1360085001.7477.166.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360085001.7477.166.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/13] xen: generalized event channel
	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 Tue, Feb 05, 2013 at 05:23:21PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:19 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 05, 2013 at 05:08:51PM +0000, Wei Liu wrote:
> > > On Tue, 2013-02-05 at 17:04 +0000, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Jan 31, 2013 at 02:47:01PM +0000, Wei Liu wrote:
> > > > > Use global pointers in common operations to allow for better code sharing
> > > > > between N-level event channel.
> > > > >
> > > > > Functions which are not suitable for sharing are also taken care of.
> > > > >
> > > > > Also update drivers/xen/evtchn.c to use exported variable instead of macro.
> > > > >
> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > ---
> > > > >  drivers/xen/events.c |  180 ++++++++++++++++++++++++++++++++------------------
> > > > >  drivers/xen/evtchn.c |   12 ++--
> > > > >  include/xen/events.h |    2 +
> > > > >  3 files changed, 123 insertions(+), 71 deletions(-)
> > > > >
> > > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > > index 0679d27..4820a52 100644
> > > > > --- a/drivers/xen/events.c
> > > > > +++ b/drivers/xen/events.c
> > > > > @@ -51,6 +51,16 @@
> > > > >  #include <xen/interface/hvm/hvm_op.h>
> > > > >  #include <xen/interface/hvm/params.h>
> > > > >
> > > > > +/* N-level event channel, starting from 2 */
> > > > > +unsigned int evtchn_level = 2;
> > > > 
> > > > What if the hypervisor does not support that? Shouldn't be by default
> > > > at 1?
> > > > 
> > > 
> > > the default implementation is 2 level. ;-)
> > 
> > I am looking at evtchn_pending and evtchn_mask in the 'struct
> > shared_info' (include/xen/interface/xen.h) and it is not obvious from
> > that. What am I missing? 
> > 
> 
> To avoid scanning the whole bitmap when doing upcall, every vcpu is
> equipped with a selector - embedded in struct vcpu_info.
> 
> So it is a 2-level event lookup path.
> 
Ah, OK. I was thinking of the normal 2 level lookup - like a page-table.

Could you include the explanation in the patch please? Thank you.

> 
> Wei
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 19:46:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19:46: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 1U2oTF-0007Op-CV; Tue, 05 Feb 2013 19:46: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 1U2oTD-0007Oj-6x
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 19:46:19 +0000
Received: from [85.158.137.99:22875] by server-2.bemta-3.messagelabs.com id
	2B/D1-25961-A8161115; Tue, 05 Feb 2013 19:46:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360093575!12297384!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22811 invoked from network); 5 Feb 2013 19:46:17 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 19:46:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15Jk9l4001577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 19:46:10 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
	r15Jk8jP010259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 19:46:09 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
	r15Jk8hu026323; Tue, 5 Feb 2013 13:46:08 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 11:46:08 -0800
Date: Tue, 5 Feb 2013 14:46:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205194603.GD6906@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
	<20130205170900.GG2187@konrad-lan.dumpdata.com>
	<1360085942.7477.175.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360085942.7477.175.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, 2013 at 05:39:02PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:09 +0000, Konrad Rzeszutek Wilk wrote:
> > >
> > > +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
> > > +{
> > > +     int cpu = smp_processor_id();
> > > +     unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > > +     unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
> > > +     int i;
> > > +     struct vcpu_info *v;
> > > +
> > > +     v = per_cpu(xen_vcpu, cpu);
> > > +
> > > +     printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--)
> > > +             if (evtchn_pending[i] != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)sizeof(evtchn_pending[0])*2,
> > > +                            evtchn_pending[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--)
> > > +             if (evtchn_mask[i] != ~0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)sizeof(evtchn_mask[0])*2,
> > > +                            evtchn_mask[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--)
> > > +             if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)(sizeof(evtchn_mask[0])*2),
> > > +                            evtchn_pending[i] & ~evtchn_mask[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
> > > +     for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
> > > +             if (cpu_evtchn[i] != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)(sizeof(cpu_evtchn[0])*2),
> > > +                            cpu_evtchn[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--) {
> > > +             unsigned long pending = evtchn_pending[i]
> > > +                     & ~evtchn_mask[i]
> > > +                     & cpu_evtchn[i];
> > > +             if (pending != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)(sizeof(evtchn_mask[0])*2),
> > > +                            pending);
> > > +             }
> > > +     }
> > > +
> > > +     printk(KERN_DEBUG "\npending list:\n");
> > > +     for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
> > > +             if (sync_test_bit(i, evtchn_pending)) {
> > > +                     int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
> > > +                     int word_idx_l2 = i / BITS_PER_LONG;
> > > +                     printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
> > > +                            cpu_from_evtchn(i), i,
> > > +                            evtchn_to_irq[i],
> > > +                            !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > > +                            ? "" : " l1-clear",
> > > +                            !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
> > > +                            ? "" : " l2-clear",
> > > +                            sync_test_bit(i, evtchn_mask)
> > > +                            ? "" : " globally-masked",
> > > +                            sync_test_bit(i, cpu_evtchn)
> > > +                            ? "" : " locally-masked");
> > > +             }
> > > +     }
> > > +
> > > +     return IRQ_HANDLED;
> > 
> > Um, there has to be a way to fold the most common cases of the L2 and L3
> > of this function in one?
> > 
> 
> The only common part is the for-loop. I could try to move statements in
> for-loops to dedicated functions, then the file will be filled with 10+
> functions like:
> 
> void output_l{2,3}_{globally,locally}_{masked,unmasked}()
> 
> void output_l{2,3}_pending()
> 
> void print_heading_for_l{2,3}()

Can it be via macros? Like arch/x86/mm/dump_pagetables.c has it for the
pagetable walker?
> 
> 
> > > +                                     pending_words_l2 &= ~(1UL << word_idx_l2);
> > > +
> > > +                             word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
> > > +                     }
> > 
> > This is a bit of a complex code. Is there any way you can split this up
> > in smaller inline functions?
> 
> I will try.
> 
> 
> Wei.
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 19:46:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 19:46: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 1U2oTF-0007Op-CV; Tue, 05 Feb 2013 19:46: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 1U2oTD-0007Oj-6x
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 19:46:19 +0000
Received: from [85.158.137.99:22875] by server-2.bemta-3.messagelabs.com id
	2B/D1-25961-A8161115; Tue, 05 Feb 2013 19:46:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360093575!12297384!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA1OTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22811 invoked from network); 5 Feb 2013 19:46:17 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 19:46:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15Jk9l4001577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 19:46:10 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
	r15Jk8jP010259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 19:46:09 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
	r15Jk8hu026323; Tue, 5 Feb 2013 13:46:08 -0600
Received: from konrad-lan.dumpdata.com (/208.54.37.132)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 11:46:08 -0800
Date: Tue, 5 Feb 2013 14:46:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130205194603.GD6906@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-10-git-send-email-wei.liu2@citrix.com>
	<20130205170900.GG2187@konrad-lan.dumpdata.com>
	<1360085942.7477.175.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360085942.7477.175.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/13] xen: implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 05, 2013 at 05:39:02PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:09 +0000, Konrad Rzeszutek Wilk wrote:
> > >
> > > +static irqreturn_t xen_debug_interrupt_l3(int irq, void *dev_id)
> > > +{
> > > +     int cpu = smp_processor_id();
> > > +     unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > > +     unsigned long nr_elems = NR_EVENT_CHANNELS_L3 / BITS_PER_LONG;
> > > +     int i;
> > > +     struct vcpu_info *v;
> > > +
> > > +     v = per_cpu(xen_vcpu, cpu);
> > > +
> > > +     printk(KERN_DEBUG "\npending (only show words which have bits set to 1):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--)
> > > +             if (evtchn_pending[i] != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)sizeof(evtchn_pending[0])*2,
> > > +                            evtchn_pending[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nglobal mask (only show words which have bits set to 0):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--)
> > > +             if (evtchn_mask[i] != ~0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)sizeof(evtchn_mask[0])*2,
> > > +                            evtchn_mask[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nglobally unmasked (only show result words which have bits set to 1):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--)
> > > +             if ((evtchn_pending[i] & ~evtchn_mask[i]) != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)(sizeof(evtchn_mask[0])*2),
> > > +                            evtchn_pending[i] & ~evtchn_mask[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nlocal cpu%d mask (only show words which have bits set to 1):\n   ", cpu);
> > > +     for (i = (NR_EVENT_CHANNELS_L3/BITS_PER_LONG)-1; i >= 0; i--)
> > > +             if (cpu_evtchn[i] != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)(sizeof(cpu_evtchn[0])*2),
> > > +                            cpu_evtchn[i]);
> > > +             }
> > > +
> > > +     printk(KERN_DEBUG "\nlocally unmasked (only show result words which have bits set to 1):\n   ");
> > > +     for (i = nr_elems-1; i >= 0; i--) {
> > > +             unsigned long pending = evtchn_pending[i]
> > > +                     & ~evtchn_mask[i]
> > > +                     & cpu_evtchn[i];
> > > +             if (pending != 0UL) {
> > > +                     printk(KERN_DEBUG " word index %d %0*lx\n",
> > > +                            i,
> > > +                            (int)(sizeof(evtchn_mask[0])*2),
> > > +                            pending);
> > > +             }
> > > +     }
> > > +
> > > +     printk(KERN_DEBUG "\npending list:\n");
> > > +     for (i = 0; i < NR_EVENT_CHANNELS_L3; i++) {
> > > +             if (sync_test_bit(i, evtchn_pending)) {
> > > +                     int word_idx = i / (BITS_PER_LONG * BITS_PER_LONG);
> > > +                     int word_idx_l2 = i / BITS_PER_LONG;
> > > +                     printk(KERN_DEBUG "  %d: event %d -> irq %d%s%s%s%s\n",
> > > +                            cpu_from_evtchn(i), i,
> > > +                            evtchn_to_irq[i],
> > > +                            !sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > > +                            ? "" : " l1-clear",
> > > +                            !sync_test_bit(word_idx_l2, per_cpu(evtchn_sel_l2, cpu))
> > > +                            ? "" : " l2-clear",
> > > +                            sync_test_bit(i, evtchn_mask)
> > > +                            ? "" : " globally-masked",
> > > +                            sync_test_bit(i, cpu_evtchn)
> > > +                            ? "" : " locally-masked");
> > > +             }
> > > +     }
> > > +
> > > +     return IRQ_HANDLED;
> > 
> > Um, there has to be a way to fold the most common cases of the L2 and L3
> > of this function in one?
> > 
> 
> The only common part is the for-loop. I could try to move statements in
> for-loops to dedicated functions, then the file will be filled with 10+
> functions like:
> 
> void output_l{2,3}_{globally,locally}_{masked,unmasked}()
> 
> void output_l{2,3}_pending()
> 
> void print_heading_for_l{2,3}()

Can it be via macros? Like arch/x86/mm/dump_pagetables.c has it for the
pagetable walker?
> 
> 
> > > +                                     pending_words_l2 &= ~(1UL << word_idx_l2);
> > > +
> > > +                             word_idx_l2 = (word_idx_l2 + 1) % BITS_PER_LONG;
> > > +                     }
> > 
> > This is a bit of a complex code. Is there any way you can split this up
> > in smaller inline functions?
> 
> I will try.
> 
> 
> Wei.
> 
> 

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 20:00:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 20:00: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 1U2oge-0007sD-Tq; Tue, 05 Feb 2013 20:00:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U2ogd-0007s8-Qu
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 20:00:12 +0000
Received: from [85.158.137.99:59253] by server-11.bemta-3.messagelabs.com id
	12/05-10249-6C461115; Tue, 05 Feb 2013 20:00:06 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360094404!20128516!1
X-Originating-IP: [74.125.82.49]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9189 invoked from network); 5 Feb 2013 20:00:04 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 20:00:04 -0000
Received: by mail-wg0-f49.google.com with SMTP id 15so466442wgd.28
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 12:00:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=zkAT9YjoceB/jhvPKjUHkO/prm0HAnKUcKjnUdDuGwQ=;
	b=uLs1zWgYFFoEBJs0U8cgvEco7x3xDAf9NEWhdIRUfnGnruLb3eCeh3FJzA/fjjmjHO
	Q9Vj0OveLnpjNCLijHKBzDqf6haoI6l95dZgWF7LqDxLYUjt5g9AM2SItdlM9wyB/H4i
	VGmTp9Xq5PRjNeT1c8TnwBbvPQfkhATXqxDZYzzfMMMZYm1ZGV27nTLCvx3rKWPTwlOk
	Pc9CvaXWOP5NmLu/0f55BCTfznDvahVV2f1GhoFZECh79fVkcsFO6fTQ4MCKvyyKq+gx
	r7IP/i2BhyP+E4u8wB6RhBgB/xHS7HMJoyj7Be7ruP88/iXq3UMxUmhBD5krM+GWNRmc
	RHaw==
MIME-Version: 1.0
X-Received: by 10.194.108.229 with SMTP id hn5mr45285094wjb.8.1360094404272;
	Tue, 05 Feb 2013 12:00:04 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Tue, 5 Feb 2013 12:00:04 -0800 (PST)
In-Reply-To: <20130205163021.GR8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
Date: Tue, 5 Feb 2013 21:00:04 +0100
Message-ID: <CAN-nQwiiNzRu0c_MDPOZ_JUyjm_tqb06tiiOUVVYnVzT8-A=Qw@mail.gmail.com>
From: agya naila <agya.naila@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 4.1 error Critical Interrupt - Front panel NMI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0869255071004646523=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0869255071004646523==
Content-Type: multipart/alternative; boundary=047d7bf19890d3e24604d4ffa7c7

--047d7bf19890d3e24604d4ffa7c7
Content-Type: text/plain; charset=ISO-8859-1

Hello Passi,

Thank you for your email, below is my answer :


> - What exact Xen version are you using?
>
I Used xen-hypervisor-4.1-amd64 version

- What exact Linux dom0 kernel are you using?
>
I used ubuntu-12.04.1-desktop-amd64


> - Please paste your grub settings for the Xen entry.
>
Here it is my grub
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor"
GRUB_CMDLINE_LINUX="rootdelay=180"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

# Disable OS prober to prevent virtual machines on logical volumes from
appearing in the boot menu.
GRUB_DISABLE_OS_PROBER=true

# Xen boot parameters for all Xen boots
#GRUB_CMDLINE_XEN=""
GRUB_CMDLINE_XEN="dom0_max_vcpus=2"
GRUB_CMDLINE_XEN="nmi=reaction"
GRUB_CMDLINE_XEN="noht"
GRUB_CMDLINE_XEN="noreboot"


# Xen boot parameters for non-recovery Xen boots (in addition to
GRUB_CMDLINE_X$

GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=2048M"



> - Did you capture the error/crash logs from the Serial console? (SOL
> provided by the blade management).
>
> I have enclosed the screen capture of the error when the XEN booting on my
previous email. From the console I got message :
 (Blade12) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=  0020
 (Blade12) Critical Interrupt - Front panel NMI

I hope you could helped me :)

Thank You,

Agya


> -- Pasi
>
>
> >                                  Installing Xen
> >
> >    Install a 64-bit hypervisor
> >
> >  sudo apt-get install xen-hypervisor-amd64
> >
> >    Modify GRUB to default to booting Xen:
> >
> >  sudo sed -i 's/GRUB_DEFAULT=.*\+/GRUB_DEFAULT="Xen 4.1-amd64"/'
> /etc/default/grub
> >  sudo update-grub
> >
> >    Set the default toolstack to xm (aka xend):
> >
> >  sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xm"/' /etc/default/xen
> >
> >    Now reboot:
> >
> >  sudo reboot
> >
> >    But when rebooting the Dom0 failed to start, enclosed was the error
> >    message when Xen booting and after that Dom0 will restarting over and
> >    over.
> >    On Blade server system  log I got error message :
> >    (Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR
> Value=
> >    0020
> >    (Bestak_septaher) Critical Interrupt - Front panel NMI
> >    Please Suggest, thank you very much for any one help.
> >    Best Regards,
> >    Agya
> >
> > References
> >
> >    Visible links
> >    1. https://help.ubuntu.com/community/XenProposed
>
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>

--047d7bf19890d3e24604d4ffa7c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Passi,<div><br></div><div>Thank you for your email, below is my answe=
r :<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
- What exact Xen version are you using?<br></blockquote><div>I Used xen-hyp=
ervisor-4.1-amd64 version=A0</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">


- What exact Linux dom0 kernel are you using?<br></blockquote><div>I used u=
buntu-12.04.1-desktop-amd64</div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">


- Please paste your grub settings for the Xen entry.<br></blockquote><div>H=
ere it is my grub</div><div><div>GRUB_DEFAULT=3D0</div><div>#GRUB_HIDDEN_TI=
MEOUT=3D0</div><div>GRUB_HIDDEN_TIMEOUT_QUIET=3Dtrue</div><div>GRUB_TIMEOUT=
=3D10</div>

<div>GRUB_DISTRIBUTOR=3D`lsb_release -i -s 2&gt; /dev/null || echo Debian`<=
/div><div>GRUB_CMDLINE_LINUX_DEFAULT=3D&quot;quiet splash acpi_backlight=3D=
vendor&quot;</div><div>GRUB_CMDLINE_LINUX=3D&quot;rootdelay=3D180&quot;</di=
v><div>

<br></div><div># Uncomment to enable BadRAM filtering, modify to suit your =
needs</div><div># This works with Linux (no patch required) and with any ke=
rnel that obtains</div><div># the memory map information from GRUB (GNU Mac=
h, kernel of FreeBSD ...)</div>

<div>#GRUB_BADRAM=3D&quot;0x01234567,0xfefefefe,0x89abcdef,0xefefefef&quot;=
</div><div><br></div><div># Uncomment to disable graphical terminal (grub-p=
c only)</div></div><div><div>#GRUB_TERMINAL=3Dconsole</div><div><br></div>
<div># The resolution used on graphical terminal</div><div># note that you =
can use only modes which your graphic card supports via VBE</div><div># you=
 can see them in real GRUB with the command `vbeinfo&#39;</div><div>#GRUB_G=
FXMODE=3D640x480</div>
<div><br></div><div># Uncomment if you don&#39;t want GRUB to pass &quot;ro=
ot=3DUUID=3Dxxx&quot; parameter to Linux</div><div>#GRUB_DISABLE_LINUX_UUID=
=3Dtrue</div></div><div><div># Uncomment to disable generation of recovery =
mode menu entries</div>
<div>#GRUB_DISABLE_RECOVERY=3D&quot;true&quot;</div><div><br></div><div># U=
ncomment to get a beep at grub start</div><div>#GRUB_INIT_TUNE=3D&quot;480 =
440 1&quot;</div><div><br></div><div># Disable OS prober to prevent virtual=
 machines on logical volumes from appearing in the boot menu.</div>
<div>GRUB_DISABLE_OS_PROBER=3Dtrue</div><div><br></div><div># Xen boot para=
meters for all Xen boots</div><div>#GRUB_CMDLINE_XEN=3D&quot;&quot;</div><d=
iv>GRUB_CMDLINE_XEN=3D&quot;dom0_max_vcpus=3D2&quot;</div><div>GRUB_CMDLINE=
_XEN=3D&quot;nmi=3Dreaction&quot;</div>
<div>GRUB_CMDLINE_XEN=3D&quot;noht&quot;</div><div>GRUB_CMDLINE_XEN=3D&quot=
;noreboot&quot;</div><div><br></div><div><br></div><div># Xen boot paramete=
rs for non-recovery Xen boots (in addition to GRUB_CMDLINE_X$</div><div><br=
>
</div><div>GRUB_CMDLINE_XEN_DEFAULT=3D&quot;dom0_mem=3D2048M&quot;</div></d=
iv><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

- Did you capture the error/crash logs from the Serial console? (SOL provid=
ed by the blade management).<br>
<br></blockquote><div>I have enclosed the screen capture of the error when =
the XEN booting on my previous email. From the console I got message :</div=
><div>=A0(Blade12) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=3D=
=A0 0020<br>
=A0(Blade12) Critical Interrupt - Front panel NMI</div><div>=A0</div><div>I=
 hope you could helped me :)</div><div><br></div><div>Thank You,</div><div>=
<br></div><div>Agya</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
-- Pasi<br>
<div><br>
<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ins=
talling Xen<br>
&gt;<br>
&gt; =A0 =A0Install a 64-bit hypervisor<br>
&gt;<br>
&gt; =A0sudo apt-get install xen-hypervisor-amd64<br>
&gt;<br>
&gt; =A0 =A0Modify GRUB to default to booting Xen:<br>
&gt;<br>
&gt; =A0sudo sed -i &#39;s/GRUB_DEFAULT=3D.*\+/GRUB_DEFAULT=3D&quot;Xen 4.1=
-amd64&quot;/&#39; /etc/default/grub<br>
&gt; =A0sudo update-grub<br>
&gt;<br>
&gt; =A0 =A0Set the default toolstack to xm (aka xend):<br>
&gt;<br>
&gt; =A0sudo sed -i &#39;s/TOOLSTACK=3D.*\+/TOOLSTACK=3D&quot;xm&quot;/&#39=
; /etc/default/xen<br>
&gt;<br>
&gt; =A0 =A0Now reboot:<br>
&gt;<br>
&gt; =A0sudo reboot<br>
&gt;<br>
&gt; =A0 =A0But when rebooting the Dom0 failed to start, enclosed was the e=
rror<br>
&gt; =A0 =A0message when Xen booting and after that Dom0 will restarting ov=
er and<br>
&gt; =A0 =A0over.<br>
&gt; =A0 =A0On Blade server system =A0log I got error message :<br>
&gt; =A0 =A0(Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NE=
RR Value=3D<br>
&gt; =A0 =A00020<br>
&gt; =A0 =A0(Bestak_septaher) Critical Interrupt - Front panel NMI<br>
&gt; =A0 =A0Please Suggest, thank you very much for any one help.<br>
&gt; =A0 =A0Best Regards,<br>
&gt; =A0 =A0Agya<br>
&gt;<br>
</div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. <a href=3D"https://help.ubuntu.com/community/XenProposed" ta=
rget=3D"_blank">https://help.ubuntu.com/community/XenProposed</a><br>
<br>
<br>
&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>
<br>
</blockquote></div><br></div>

--047d7bf19890d3e24604d4ffa7c7--


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

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

--===============0869255071004646523==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 20:00:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 20:00: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 1U2oge-0007sD-Tq; Tue, 05 Feb 2013 20:00:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U2ogd-0007s8-Qu
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 20:00:12 +0000
Received: from [85.158.137.99:59253] by server-11.bemta-3.messagelabs.com id
	12/05-10249-6C461115; Tue, 05 Feb 2013 20:00:06 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360094404!20128516!1
X-Originating-IP: [74.125.82.49]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9189 invoked from network); 5 Feb 2013 20:00:04 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Feb 2013 20:00:04 -0000
Received: by mail-wg0-f49.google.com with SMTP id 15so466442wgd.28
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 12:00:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=zkAT9YjoceB/jhvPKjUHkO/prm0HAnKUcKjnUdDuGwQ=;
	b=uLs1zWgYFFoEBJs0U8cgvEco7x3xDAf9NEWhdIRUfnGnruLb3eCeh3FJzA/fjjmjHO
	Q9Vj0OveLnpjNCLijHKBzDqf6haoI6l95dZgWF7LqDxLYUjt5g9AM2SItdlM9wyB/H4i
	VGmTp9Xq5PRjNeT1c8TnwBbvPQfkhATXqxDZYzzfMMMZYm1ZGV27nTLCvx3rKWPTwlOk
	Pc9CvaXWOP5NmLu/0f55BCTfznDvahVV2f1GhoFZECh79fVkcsFO6fTQ4MCKvyyKq+gx
	r7IP/i2BhyP+E4u8wB6RhBgB/xHS7HMJoyj7Be7ruP88/iXq3UMxUmhBD5krM+GWNRmc
	RHaw==
MIME-Version: 1.0
X-Received: by 10.194.108.229 with SMTP id hn5mr45285094wjb.8.1360094404272;
	Tue, 05 Feb 2013 12:00:04 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Tue, 5 Feb 2013 12:00:04 -0800 (PST)
In-Reply-To: <20130205163021.GR8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
Date: Tue, 5 Feb 2013 21:00:04 +0100
Message-ID: <CAN-nQwiiNzRu0c_MDPOZ_JUyjm_tqb06tiiOUVVYnVzT8-A=Qw@mail.gmail.com>
From: agya naila <agya.naila@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 4.1 error Critical Interrupt - Front panel NMI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0869255071004646523=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0869255071004646523==
Content-Type: multipart/alternative; boundary=047d7bf19890d3e24604d4ffa7c7

--047d7bf19890d3e24604d4ffa7c7
Content-Type: text/plain; charset=ISO-8859-1

Hello Passi,

Thank you for your email, below is my answer :


> - What exact Xen version are you using?
>
I Used xen-hypervisor-4.1-amd64 version

- What exact Linux dom0 kernel are you using?
>
I used ubuntu-12.04.1-desktop-amd64


> - Please paste your grub settings for the Xen entry.
>
Here it is my grub
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor"
GRUB_CMDLINE_LINUX="rootdelay=180"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

# Disable OS prober to prevent virtual machines on logical volumes from
appearing in the boot menu.
GRUB_DISABLE_OS_PROBER=true

# Xen boot parameters for all Xen boots
#GRUB_CMDLINE_XEN=""
GRUB_CMDLINE_XEN="dom0_max_vcpus=2"
GRUB_CMDLINE_XEN="nmi=reaction"
GRUB_CMDLINE_XEN="noht"
GRUB_CMDLINE_XEN="noreboot"


# Xen boot parameters for non-recovery Xen boots (in addition to
GRUB_CMDLINE_X$

GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=2048M"



> - Did you capture the error/crash logs from the Serial console? (SOL
> provided by the blade management).
>
> I have enclosed the screen capture of the error when the XEN booting on my
previous email. From the console I got message :
 (Blade12) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=  0020
 (Blade12) Critical Interrupt - Front panel NMI

I hope you could helped me :)

Thank You,

Agya


> -- Pasi
>
>
> >                                  Installing Xen
> >
> >    Install a 64-bit hypervisor
> >
> >  sudo apt-get install xen-hypervisor-amd64
> >
> >    Modify GRUB to default to booting Xen:
> >
> >  sudo sed -i 's/GRUB_DEFAULT=.*\+/GRUB_DEFAULT="Xen 4.1-amd64"/'
> /etc/default/grub
> >  sudo update-grub
> >
> >    Set the default toolstack to xm (aka xend):
> >
> >  sudo sed -i 's/TOOLSTACK=.*\+/TOOLSTACK="xm"/' /etc/default/xen
> >
> >    Now reboot:
> >
> >  sudo reboot
> >
> >    But when rebooting the Dom0 failed to start, enclosed was the error
> >    message when Xen booting and after that Dom0 will restarting over and
> >    over.
> >    On Blade server system  log I got error message :
> >    (Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR
> Value=
> >    0020
> >    (Bestak_septaher) Critical Interrupt - Front panel NMI
> >    Please Suggest, thank you very much for any one help.
> >    Best Regards,
> >    Agya
> >
> > References
> >
> >    Visible links
> >    1. https://help.ubuntu.com/community/XenProposed
>
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>

--047d7bf19890d3e24604d4ffa7c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Passi,<div><br></div><div>Thank you for your email, below is my answe=
r :<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
- What exact Xen version are you using?<br></blockquote><div>I Used xen-hyp=
ervisor-4.1-amd64 version=A0</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">


- What exact Linux dom0 kernel are you using?<br></blockquote><div>I used u=
buntu-12.04.1-desktop-amd64</div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">


- Please paste your grub settings for the Xen entry.<br></blockquote><div>H=
ere it is my grub</div><div><div>GRUB_DEFAULT=3D0</div><div>#GRUB_HIDDEN_TI=
MEOUT=3D0</div><div>GRUB_HIDDEN_TIMEOUT_QUIET=3Dtrue</div><div>GRUB_TIMEOUT=
=3D10</div>

<div>GRUB_DISTRIBUTOR=3D`lsb_release -i -s 2&gt; /dev/null || echo Debian`<=
/div><div>GRUB_CMDLINE_LINUX_DEFAULT=3D&quot;quiet splash acpi_backlight=3D=
vendor&quot;</div><div>GRUB_CMDLINE_LINUX=3D&quot;rootdelay=3D180&quot;</di=
v><div>

<br></div><div># Uncomment to enable BadRAM filtering, modify to suit your =
needs</div><div># This works with Linux (no patch required) and with any ke=
rnel that obtains</div><div># the memory map information from GRUB (GNU Mac=
h, kernel of FreeBSD ...)</div>

<div>#GRUB_BADRAM=3D&quot;0x01234567,0xfefefefe,0x89abcdef,0xefefefef&quot;=
</div><div><br></div><div># Uncomment to disable graphical terminal (grub-p=
c only)</div></div><div><div>#GRUB_TERMINAL=3Dconsole</div><div><br></div>
<div># The resolution used on graphical terminal</div><div># note that you =
can use only modes which your graphic card supports via VBE</div><div># you=
 can see them in real GRUB with the command `vbeinfo&#39;</div><div>#GRUB_G=
FXMODE=3D640x480</div>
<div><br></div><div># Uncomment if you don&#39;t want GRUB to pass &quot;ro=
ot=3DUUID=3Dxxx&quot; parameter to Linux</div><div>#GRUB_DISABLE_LINUX_UUID=
=3Dtrue</div></div><div><div># Uncomment to disable generation of recovery =
mode menu entries</div>
<div>#GRUB_DISABLE_RECOVERY=3D&quot;true&quot;</div><div><br></div><div># U=
ncomment to get a beep at grub start</div><div>#GRUB_INIT_TUNE=3D&quot;480 =
440 1&quot;</div><div><br></div><div># Disable OS prober to prevent virtual=
 machines on logical volumes from appearing in the boot menu.</div>
<div>GRUB_DISABLE_OS_PROBER=3Dtrue</div><div><br></div><div># Xen boot para=
meters for all Xen boots</div><div>#GRUB_CMDLINE_XEN=3D&quot;&quot;</div><d=
iv>GRUB_CMDLINE_XEN=3D&quot;dom0_max_vcpus=3D2&quot;</div><div>GRUB_CMDLINE=
_XEN=3D&quot;nmi=3Dreaction&quot;</div>
<div>GRUB_CMDLINE_XEN=3D&quot;noht&quot;</div><div>GRUB_CMDLINE_XEN=3D&quot=
;noreboot&quot;</div><div><br></div><div><br></div><div># Xen boot paramete=
rs for non-recovery Xen boots (in addition to GRUB_CMDLINE_X$</div><div><br=
>
</div><div>GRUB_CMDLINE_XEN_DEFAULT=3D&quot;dom0_mem=3D2048M&quot;</div></d=
iv><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

- Did you capture the error/crash logs from the Serial console? (SOL provid=
ed by the blade management).<br>
<br></blockquote><div>I have enclosed the screen capture of the error when =
the XEN booting on my previous email. From the console I got message :</div=
><div>=A0(Blade12) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Value=3D=
=A0 0020<br>
=A0(Blade12) Critical Interrupt - Front panel NMI</div><div>=A0</div><div>I=
 hope you could helped me :)</div><div><br></div><div>Thank You,</div><div>=
<br></div><div>Agya</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
-- Pasi<br>
<div><br>
<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ins=
talling Xen<br>
&gt;<br>
&gt; =A0 =A0Install a 64-bit hypervisor<br>
&gt;<br>
&gt; =A0sudo apt-get install xen-hypervisor-amd64<br>
&gt;<br>
&gt; =A0 =A0Modify GRUB to default to booting Xen:<br>
&gt;<br>
&gt; =A0sudo sed -i &#39;s/GRUB_DEFAULT=3D.*\+/GRUB_DEFAULT=3D&quot;Xen 4.1=
-amd64&quot;/&#39; /etc/default/grub<br>
&gt; =A0sudo update-grub<br>
&gt;<br>
&gt; =A0 =A0Set the default toolstack to xm (aka xend):<br>
&gt;<br>
&gt; =A0sudo sed -i &#39;s/TOOLSTACK=3D.*\+/TOOLSTACK=3D&quot;xm&quot;/&#39=
; /etc/default/xen<br>
&gt;<br>
&gt; =A0 =A0Now reboot:<br>
&gt;<br>
&gt; =A0sudo reboot<br>
&gt;<br>
&gt; =A0 =A0But when rebooting the Dom0 failed to start, enclosed was the e=
rror<br>
&gt; =A0 =A0message when Xen booting and after that Dom0 will restarting ov=
er and<br>
&gt; =A0 =A0over.<br>
&gt; =A0 =A0On Blade server system =A0log I got error message :<br>
&gt; =A0 =A0(Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NE=
RR Value=3D<br>
&gt; =A0 =A00020<br>
&gt; =A0 =A0(Bestak_septaher) Critical Interrupt - Front panel NMI<br>
&gt; =A0 =A0Please Suggest, thank you very much for any one help.<br>
&gt; =A0 =A0Best Regards,<br>
&gt; =A0 =A0Agya<br>
&gt;<br>
</div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. <a href=3D"https://help.ubuntu.com/community/XenProposed" ta=
rget=3D"_blank">https://help.ubuntu.com/community/XenProposed</a><br>
<br>
<br>
&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>
<br>
</blockquote></div><br></div>

--047d7bf19890d3e24604d4ffa7c7--


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

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

--===============0869255071004646523==--


From xen-devel-bounces@lists.xen.org Tue Feb 05 20:09:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 20: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 1U2op3-0008Em-7n; Tue, 05 Feb 2013 20:08:53 +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 1U2op0-0008Eh-H9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 20:08:51 +0000
Received: from [85.158.139.83:50360] by server-9.bemta-5.messagelabs.com id
	66/B2-24440-1D661115; Tue, 05 Feb 2013 20:08:49 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360094928!31009775!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzA2NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26861 invoked from network); 5 Feb 2013 20:08:49 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 20:08: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 022811977;
	Tue,  5 Feb 2013 22:08:47 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id CCD06EC027; Tue,  5 Feb 2013 22:08:47 +0200 (EET)
Date: Tue, 5 Feb 2013 22:08:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130205200847.GS8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130205163021.GR8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: arrfab@centos.org, xen-devel@lists.xen.org
Subject: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
	panel NMI 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="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, Feb 05, 2013 at 06:30:21PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Tue, Feb 05, 2013 at 04:49:47PM +0100, agya naila wrote:
> >    Hello Everyone,
> >    I am quite new on XEN. I tried to installed XEN on my server and I k=
now
> >    this server series IBM Xeon 3,4 Ghz didn't have Intel VTx support so=
 I am
> >    pllaning to use paravirtualization.
> >    I configure the server with Ubuntu Desktop  12.0464 bit as dom0 with=
 XEN
> >    4.1 64 hypervisor. The configuration using repositories exactly by t=
his
> >    tutorial [1]https://help.ubuntu.com/community/XenProposed :
> >
> =

> - What exact Xen version are you using? =

> - What exact Linux dom0 kernel are you using? =

> - Please paste your grub settings for the Xen entry.
> - Did you capture the error/crash logs from the Serial console? (SOL prov=
ided by the blade management).
> =

> =


<snip>

> > =

> >    Now reboot:
> > =

> >  sudo reboot
> > =

> >    But when rebooting the Dom0 failed to start, enclosed was the error
> >    message when Xen booting and after that Dom0 will restarting over and
> >    over.
> >    On Blade server system  log I got error message :
> >    (Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Va=
lue=3D
> >    0020
> >    (Bestak_septaher) Critical Interrupt - Front panel NMI
> >    Please Suggest, thank you very much for any one help.
>

Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade with X=
en 4.2.1 =

with Linux 3.4.28 dom0 kernel.

Does this ring anyone's bells? =



serial console log of the crash (also available on: http://pastebin.centos.=
org/1204/):


(XEN) Xen version 4.2.1 (mockbuild@(none)) (gcc (GCC) 4.4.6 20120305 (Red H=
at 4.4.6-4)) Thu Jan 31 20:36:24 UTC 2013
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D256M,max:256M loglvl=3Dall guest_loglvl=3Dal=
l com2=3D19200,8n1 console=3Dcom2,vga lapic=3Ddebug apic_verbosity=3Ddebug =
apic=3Ddebug iommu=3Doff sync_console
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d400 (usable)
(XEN)  000000000009d400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000d7fb0580 (usable)
(XEN)  00000000d7fb0580 - 00000000d7fd0000 (ACPI data)
(XEN)  00000000d7fd0000 - 00000000d8000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000128000000 (usable)
(XEN) ACPI: RSDP 000FDFE0, 0014 (r0 IBM   )
(XEN) ACPI: RSDT D7FCFF80, 0030 (r1 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) ACPI: FACP D7FCFEC0, 0084 (r2 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) ACPI: DSDT D7FBE4A8, 1F2A (r1 IBM    SERBLADE     1000 INTL  2002025)
(XEN) ACPI: FACS D7FCFD80, 0040
(XEN) ACPI: APIC D7FCFE00, 00A8 (r1 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) ACPI: MCFG D7FCFDC0, 003C (r1 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) System RAM: 4095MB (4193588kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000128000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 0009d540
(XEN) DMI 2.3 present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x588
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN) ACPI:                  wakeup_vec[d7fcfd8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
(XEN) Processor #6 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
(XEN) Processor #7 15:4 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 14, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 13, version 32, address 0xfec10000, GSI 24-47
(XEN) ACPI: IOAPIC (id[0x0c] address[0xfec81000] gsi_base[48])
(XEN) IOAPIC[2]: apic_id 12, version 32, address 0xfec81000, GSI 48-71
(XEN) ACPI: IOAPIC (id[0x0b] address[0xfec81400] gsi_base[72])
(XEN) IOAPIC[3]: apic_id 11, version 32, address 0xfec81400, GSI 72-95
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ11 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 4 I/O APICs
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) mapped APIC to ffff82c3ffdfe000 (fee00000)
(XEN) mapped IOAPIC to ffff82c3ffdfd000 (fec00000)
(XEN) mapped IOAPIC to ffff82c3ffdfc000 (fec10000)
(XEN) mapped IOAPIC to ffff82c3ffdfb000 (fec81000)
(XEN) mapped IOAPIC to ffff82c3ffdfa000 (fec81400)
(XEN) IRQ limits: 96 GSI, 688 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3200.224 MHz processor.
(XEN) Initing memory sharing.
(XEN) traps.c:3156: GPF (0000): ffff82c48019e43d -> ffff82c4802164d0
(XEN) mce_intel.c:1239: MCA Capability: BCAST 0 SER 0 CMCI 0 firstbank 0 ex=
tended MCE MSR 18
(XEN) Intel machine check reporting enabled
(XEN) PCI: Found Intel Corporation E7520 Memory Controller Hub with MMCONFI=
G support.
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) I/O virtualisation disabled
(XEN) Getting VERSION: 50014
(XEN) Getting VERSION: 50014
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) enabled ExtINT on CPU#0
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 14-0, 14-16, 14-17, 14-18, 14-19, 14-20, 14-21,=
 14-22, 14-23, 13-0, 13-1, 13-2, 13-3, 13-4, 13-5, 13-6, 13-7, 13-8, 13-9, =
13-10, 13-11, 13-12, 13-13, 13-14, 13-15, 13-16, 13-17, 13-18, 13-19, 13-20=
, 13-21, 13-22, 13-23, 12-0, 12-1, 12-2, 12-3, 12-4, 12-5, 12-6, 12-7, 12-8=
, 12-9, 12-10, 12-11, 12-12, 12-13, 12-14, 12-15, 12-16, 12-17, 12-18, 12-1=
9, 12-20, 12-21, 12-22, 12-23, 11-0, 11-1, 11-2, 11-3, 11-4, 11-5, 11-6, 11=
-7, 11-8, 11-9, 11-10, 11-11, 11-12, 11-13, 11-14, 11-15, 11-16, 11-17, 11-=
18, 11-19, 11-20, 11-21, 11-22, 11-23 not connected.
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) number of MP IRQ sources: 15.
(XEN) number of IO-APIC #14 registers: 24.
(XEN) number of IO-APIC #13 registers: 24.
(XEN) number of IO-APIC #12 registers: 24.
(XEN) number of IO-APIC #11 registers: 24.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #14......
(XEN) .... register #00: 0E000000
(XEN) .......    : physical APIC id: 0E
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 001 01  0    0    0   0   0    1    1    28
(XEN)  02 001 01  0    0    0   0   0    1    1    F0
(XEN)  03 001 01  0    0    0   0   0    1    1    F1
(XEN)  04 001 01  0    0    0   0   0    1    1    30
(XEN)  05 001 01  0    0    0   0   0    1    1    38
(XEN)  06 001 01  0    0    0   0   0    1    1    40
(XEN)  07 001 01  0    0    0   0   0    1    1    48
(XEN)  08 001 01  0    0    0   0   0    1    1    50
(XEN)  09 001 01  0    0    0   0   0    1    1    58
(XEN)  0a 001 01  0    0    0   0   0    1    1    60
(XEN)  0b 001 01  1    1    0   0   0    1    1    68
(XEN)  0c 001 01  0    0    0   0   0    1    1    70
(XEN)  0d 001 01  0    0    0   0   0    1    1    78
(XEN)  0e 001 01  0    0    0   0   0    1    1    88
(XEN)  0f 001 01  0    0    0   0   0    1    1    90
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) IO APIC #13......
(XEN) .... register #00: 0D000000
(XEN) .......    : physical APIC id: 0D
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 000 00  1    0    0   0   0    0    0    00
(XEN)  02 000 00  1    0    0   0   0    0    0    00
(XEN)  03 000 00  1    0    0   0   0    0    0    00
(XEN)  04 000 00  1    0    0   0   0    0    0    00
(XEN)  05 000 00  1    0    0   0   0    0    0    00
(XEN)  06 000 00  1    0    0   0   0    0    0    00
(XEN)  07 000 00  1    0    0   0   0    0    0    00
(XEN)  08 000 00  1    0    0   0   0    0    0    00
(XEN)  09 000 00  1    0    0   0   0    0    0    00
(XEN)  0a 000 00  1    0    0   0   0    0    0    00
(XEN)  0b 000 00  1    0    0   0   0    0    0    00
(XEN)  0c 000 00  1    0    0   0   0    0    0    00
(XEN)  0d 000 00  1    0    0   0   0    0    0    00
(XEN)  0e 000 00  1    0    0   0   0    0    0    00
(XEN)  0f 000 00  1    0    0   0   0    0    0    00
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) IO APIC #12......
(XEN) .... register #00: 0C000000
(XEN) .......    : physical APIC id: 0C
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #02: 0C000000
(XEN) .......     : arbitration: 0C
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 000 00  1    0    0   0   0    0    0    00
(XEN)  02 000 00  1    0    0   0   0    0    0    00
(XEN)  03 000 00  1    0    0   0   0    0    0    00
(XEN)  04 000 00  1    0    0   0   0    0    0    00
(XEN)  05 000 00  1    0    0   0   0    0    0    00
(XEN)  06 000 00  1    0    0   0   0    0    0    00
(XEN)  07 000 00  1    0    0   0   0    0    0    00
(XEN)  08 000 00  1    0    0   0   0    0    0    00
(XEN)  09 000 00  1    0    0   0   0    0    0    00
(XEN)  0a 000 00  1    0    0   0   0    0    0    00
(XEN)  0b 000 00  1    0    0   0   0    0    0    00
(XEN)  0c 000 00  1    0    0   0   0    0    0    00
(XEN)  0d 000 00  1    0    0   0   0    0    0    00
(XEN)  0e 000 00  1    0    0   0   0    0    0    00
(XEN)  0f 000 00  1    0    0   0   0    0    0    00
(XEN)  10 000 00  1    0    0   0   0    0    0 0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) IO APIC #11......
(XEN) .... register #00: 0B000000
(XEN) .......    : physical APIC id: 0B
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #02: 0B000000
(XEN) .......     : arbitration: 0B
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 000 00  1    0    0   0   0    0    0    00
(XEN)  02 000 00  1    0    0   0   0    0    0    00
(XEN)  03 000 00  1    0    0   0   0    0    0    00
(XEN)  04 000 00  1    0    0   0   0    0    0    00
(XEN)  05 000 00  1    0    0   0   0    0    0    00
(XEN)  06 000 00  1    0    0   0   0    0    0    00
(XEN)  07 000 00  1    0    0   0   0    0    0    00
(XEN)  08 000 00  1    0    0   0   0    0    0    00
(XEN)  09 000 00  1    0    0   0   0    0    0    00
(XEN)  0a 000 00  1    0    0   0   0    0    0    00
(XEN)  0b 000 00  1    0    0   0   0    0    0    00
(XEN)  0c 000 00  1    0    0   0   0    0    0    00
(XEN)  0d 000 00  1    0    0   0   0    0    0    00
(XEN)  0e 000 00  1    0    0   0   0    0    0    00
(XEN)  0f 000 00  1    0    0   0   0    0    0    00
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) Using vector-based indexing
(XEN) IRQ to pin mappings:
(XEN) IRQ240 -> 0:2
(XEN) IRQ40 -> 0:1
(XEN) IRQ241 -> 0:3
(XEN) IRQ48 -> 0:4
(XEN) IRQ56 -> 0:5
(XEN) IRQ64 -> 0:6
(XEN) IRQ72 -> 0:7
(XEN) IRQ80 -> 0:8
(XEN) IRQ88 -> 0:9
(XEN) IRQ96 -> 0:10
(XEN) IRQ104 -> 0:11
(XEN) IRQ112 -> 0:12
(XEN) IRQ120 -> 0:13
(XEN) IRQ136 -> 0:14
(XEN) IRQ144 -> 0:15
(XEN) .................................... done.
(XEN) Using local APIC timer interrupts.
(XEN) calibrating APIC timer ...
(XEN) ..... CPU clock speed is 3200.1563 MHz.
(XEN) ..... host bus clock speed is 200.0096 MHz.
(XEN) ..... bus_scale =3D 0x0000CCD7
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 32 KiB.
(XEN) masked ExtINT on CPU#1
(XEN) masked ExtINT on CPU#2
(XEN) masked ExtINT on CPU#3
(XEN) Brought up 4 CPUs
(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
(XEN) ACPI sleep)  Init. ramdisk: ffffffff82b1b000->ffffffff859e5c00
(XEN)  Phys-Mach map: ffffffff859e6000->ffffffff85a66000
(XEN)  Start info:    ffffffff85a66000->ffffffff85a664b4
(XEN)  Page tables:   ffffffff85a67000->ffffffff85a98000
(XEN)  Boot stack:    ffffffff85a98000->ffffffff85a99000
(XEN)  TOTAL:         ffffffff80000000->ffffffff85c00000
(XEN)  ENTRY ADDRESS: ffffffff81b1c200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ......................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t=
o Xen)
(XEN) Freed 252kB init memory.
mapping kernel into physical memory
about to get started...
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.28-6.el6.centos.alt.x86_64 (mockbuild@bn3.alt.bsys.dev.ce=
ntos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Thu =
Jan 31 22:39:42 UTC 2013
Command line: ro root=3D/dev/mapper/c6kvm--vg-lv_root rd_NO_LUKS rd_LVM_LV=
=3Dc6kvm-vg/lv_root LANG=3Den_US.UTF-8 crashkernel=3Dauto rd_NO_MD SYSFONT=
=3Dlatarcyrheb-sun16 rd_LVM_LV=3Dc6kvm-vg/lv_swap  KEYBOARDTYPE=3Dpc KEYTAB=
LE=3Dus rd_NO_DM earlyprintk=3Dxen console=3Dhvc0 nomodeset initcall_debug =
debug loglevel=3D10
Freeing 9d-100 pfn range: 99 pages freed
Released 99 pages of unused memory
Set 164019 page(s) to 1-1 mapping
Populating 10000-10063 pfn range: 99 pages added
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009d000 (usable)
 Xen: 000000000009d400 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000010063000 (usable)
 Xen: 0000000010063000 - 00000000d7fb0580 (unusable)
 Xen: 00000000d7fb0580 - 00000000d7fd0000 (ACPI data)
 Xen: 00000000d7fd0000 - 00000000d8000000 (reserved)
 Xen: 00000000e0000000 - 00000000f0000000 (reserved)
 Xen: 00000000fec00000 - 0000000100000000 (reserved)
 Xen: 0000000100000000 - 0000000128000000 (unusable)
bootconsole [xenboot0] enabled
Notice: NX (Execute Disable) protection missing in CPU!
SMBIOS 2.3 present.
DMI: IBM IBM BladeCenter HS20 -[8843E6G]-/Server Blade, BIOS -[BWE132AUS-1.=
13]- 12/19/2008
e820 update range: 000000M    SERBLADE 00001000 INTL 02002025)
ACPI: FACS 00000000d7fcfd80 00040
ACPI: APIC 00000000d7fcfe00 000A8 (v01 IBM    SERBLADE 00001000 IBM  45444F=
43)
ACPI: MCFG 00000000d7fcfdc0 0003C (v01 IBM    SERBLADE 00001000 IBM  45444F=
43)
ACPI: Local APIC address 0xfee00000
NUMA turned off
Faking a node at 0000000000000000-0000000010063000
Initmem setup node 0 0000000000000000-0000000010063000
  NODE_DATA [000000001003d000 - 0000000010062fff]
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   empty
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000010 -> 0x0000009d
    0: 0x00000100 -> 0x00010063
On node 0 totalpages: 65520
  DMA zone: 56 pages used for memmap
  DMA zone: 5 pages reserved
  DMA zone: 3920 pages, LIFO batch:0
  DMA32 zone: 842 pages used for memmap
  DMA32 zone: 60697 pages, LIFO batch:15
ACPI: PM-Timer IO Port: 0x588
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 14, version 253, address 0xfec00000, GSI 0-253
ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 13, version 253, address 0xfec10000, GSI 24-277
ACPI: IOAPIC (id[0x0c] address[0xfec81000] gsi_base[48])
IOAPIC[2]: apic_id 12, version 253, address 0xfec81000, GSI 48-301
ACPI: IOAPIC (id[0x0b] address[0xfec81400] gsi_base[72])
IOAPIC[3]: apic_id 11, version 253, address 0xfec81400, GSI 72-325
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ11 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 4 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 342
PM: Registered nosave memory: 000000000009d000 - 000000000009e000
PM: Registered nosave memory: 000000000009e000 - 0000000000100000
Allocating PCI resources starting at f0000000 (gap: f0000000:ec00000)
Booting paravirtualized kernel on Xen
Xen version: 4.2.1 (preserve-AD)
setup_percpu: NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Embedded 28 pages/cpu @ffff88000fe00000 s82432 r8192 d24064 u524288
pcpu-alloc: s82432 r8192 d24064 u524288 alloc=3D1*2097152
pcpu-alloc: [0] 0 1 2 3
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 64617
Policy zone: DMA32
Kernel command line: ro root=3D/dev/mapper/c6kvm--vg-lv_root rd_NO_LUKS rd_=
LVM_LV=3Dc6kvm-vg/lv_root LANG=3Den_US.UTF-8 crashkernel=3Dauto rd_NO_MD SY=
SFONT=3Dlatarcyrheb-sun16 rd_LVM_LV=3Dc6kvm-vg/lv_swap  KEYBOARDTYPE=3Dpc K=
EYTABLE=3Dus rd_NO_DM earlyprintk=3Dxen console=3Dhvc0 nomodeset initcall_d=
ebug debug loglevel=3D10
PID hash table entries: 1024 (order: 1, 8192 bytes)
Placing 64MB software IO TLB between ffff88000b200000 - ffff88000f200000
software IO TLB at phys 0xb200000 - 0xf200000
Memory: 125496k/262540k available (5643k kernel code, 460k absent, 136584k =
reserved, 5643k data, 1464k init)
Hierarchical RCU implementation.
NR_IRQS:262400 nr_irqs:1024 16
xen: sci override: global_irq=3D11 trigger=3D0 polarity=3D0
xen: registering gsi 11 triggering 0 polarity 0
xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11)
(XEN) IOAPIC[0]: Set PCI routing entry (14-11 -> 0x68 -> IRQ 11 Mode:1 Acti=
ve:0)
xen: acpi sci 11
xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1)
xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2)
xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3)
xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4)
xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5)
xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6)
xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7)
xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8)
xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9)
xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10)
xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12)
xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13)
xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14)
xen: --> pirq=3D15 ->nit_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
calling  init_hw_perf_events+0x0/0x44f @ 1
Performance Events: unsupported Netburst CPU model 4 no PMU driver, softwar=
e events only.
initcall init_hw_perf_events+0x0/0x44f returned 0 after 2929 usecs
calling  register_trigger_all_cpu_backtrace+0x0/0x1f @ 1
initcall register_trigger_all_cpu_backtrace+0x0/0x1f returned 0 after 0 use=
cs
calling  spawn_ksoftirqd+0x0/0x57 @ 1
initcall spawn_ksoftirqd+0x0/0x57 returned 0 after 0 usecs
calling  init_workqueues+0x0/0x2f5 @ 1
initcall init_workqueues+0x0/0x2f5 returned 0 after 0 usecs
calling  migration_init+0x0/0x71 @ 1
initcall migration_init+0x0/0x71 returned 0 after 0 usecs
calling  cpu_stop_init+0x0/0xb6 @ 1
initcall cpu_stop_init+0x0/0xb6 returned 0 after 0 usecs
calling  rcu_scheduler_really_started+0x0/0x12 @ 1
initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
calling  relay_init+0x0/0x14 @ 1
initcall relay_init+0x0/0x14 returned 0 after 0 usecs
calling  tracer_alloc_buffers+0x0/0x235 @ 1
initcall tracer_alloc_buffers+0x0/0x235 returned 0 after 0 usecs
calling  init_trace_printk+0x0/0x12 @ 1
initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
NMI watchdog: disabled (cpu0): hardware events not enabled
installing Xen timer for CPU 1
NMI watchdog: disabled (cpu1): hardware events not enabled
installing Xen timer for CPU 2
NMI watchdog: disabled (cpu2): hardware events not enabled
installing Xen timer for CPU 3
NMI watchdog: disabled (cpu3): hardware events not enabled
Brought up 4 CPUs
devtmpfs: initialized
calling  ipc_ns_init+0x0/0x14 @ 1
initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
calling  initea returned 0 after 0 usecs
calling  e820_mark_nvs_memory+0x0/0x41 @ 1
initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
calling  cpufreq_tsc+0x0/0x37 @ 1
initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
calling  pci_reboot_init+0x0/0x1d @ 1
initcall pci_reboot_init+0x0/0x1d returned 0 after 0 usecs
calling  init_lapic_sysfs+0x0/0x20 @ 1
initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
calling  init_smp_flush+0x0/0x38 @ 1
initcall init_smp_flush+0x0/0x38 returned 0 after 0 usecs
calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
calling  alloc_frozen_cpus+0x0/0x1e @ 1
initcall alloc_frozen_cpus+0x0/0x1e returned 0 after 0 usecs
calling  ksysfs_init+0x0/0x94 @ 1
initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
calling  pm_init+0x0/0x66 @ 1
initcall pm_init+0x0/0x66 returned 0 after 0 usecs
calling  pm_disk_init+0x0/0x19 @ 1
initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
calling  swsusp_header_init+0x0/0x40 @ 1
initcall swsusp_header_init+0x0/0x40 returned 0 after 0 usecs
calling  init_jiffies_clocksource+0x0/0x12 @ 1
initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
calling  init_ftrace_syscalls+0x0/0x77 @ 1
initcall init_ftrace_syscalls+0x0/0x77 returned 0 after 976 usecs
calling  init_zero_pfn+0x0/0x35 @ 1
initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
calling  memory_failure_init+0x0/0xa8 @ 1
initcall memory_failure_init+0x0/0xa8 returned 0 after 0 usecs
calling  fsnotify_init+0x0/0x26 @ 1
initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
calling  filelock_init+0x0/0x2a @ 1
initcall filelock_init+0x0/0x2a returned 0 after 0 usecs
calling  init_misc_binfmt+0x0/0x31 @ 1
initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
calling  init_script_binfmt+0x0/0x16 @ 1
initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
calling  init_elf_binfmt+0x0/0x16 @ 1
initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
calling  init_compat_elf_binfmt+0x0/0x16 @ 1
initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
calling  debugfs_init+0x0/0x5c @ 1
initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
calling  securityfs_init+0x0/0x53 @ 1
initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
calling  random32_init+0x0/0xdb @ 1
initcall random32_init+0x0/0xdb returned 0 after 0 usecs
calling  sfi_sysfs_init+0x0/0xdb @ 1
i usecs
calling  dma_bus_init+0x0/0x19 @ 1
initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
calling  dma_channel_table_init+0x0/0x119 @ 1
initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 0 usecs
calling  register_xen_pci_notifier+0x0/0x33 @ 1
initcall register_xen_pci_notifier+0x0/0x33 returned 0 after 0 usecs
calling  dmi_id_init+0x0/0xbe @ 1
initcall dmi_id_init+0x0/0xbe returned 0 after 0 usecs
calling  pci_arch_init+0x0/0x69 @ 1
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (b=
ase 0xe0000000)
PCI: Intel Corporation E7520 Memory Controller Hub with MMCONFIG support
PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
PCI: Using configuration type 1 for base access
initcall pci_arch_init+0x0/0x69 returned 0 after 76160 usecs
calling  topology_init+0x0/0xa1 @ 1
initcall topology_init+0x0/0xa1 returned 0 after 0 usecs
calling  mtrr_init_finialize+0x0/0x36 @ 1
initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
calling  init_vdso+0x0/0x135 @ 1
initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
calling  sysenter_setup+0x0/0xbc @ 1
initcall sysenter_setup+0x0/0xbc returned 0 after 0 usecs
calling  param_sysfs_init+0x0/0x150 @ 1
initcall param_sysfs_init+0x0/0x150 returned 0 after 976 usecs
calling  pm_sysrq_init+0x0/0x20 @ 1
initcall pm_sysrq_init+0x0/0x20 returned 0 after 0 usecs
calling  default_bdi_init+0x0/0xaa @ 1
initcall default_bdi_init+0x0/0xaa returned 0 after 0 usecs
calling  init_bio+0x0/0x10c @ 1
bio: create slab <bio-0> at 0
initcall init_bio+0x0/0x10c returned 0 after 976 usecs
calling  fsnotify_notification_init+0x0/0x8b @ 1
initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
calling  cryptomgr_init+0x0/0x12 @ 1
initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
calling  blk_settings_init+0x0/0x2c @ 1
initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
calling  blk_ioc_init+0x0/0x2a @ 1
initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
calling  blk_softirq_init+0x0/0x70 @ 1
initcall blk_softirq_init+0x0/0x70 returned 0 after 0 usecs
calling  blk_iopoll_setup+0x0/0x70 @ 1
initbridge window [mem 0xda4000000-0xde3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xd24000000-0xd63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xca4000000-0xce3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xc24000000-0xc63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xba4000000-0xbe3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xb24000000-0xb63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xaa4000000-0xae3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xa24000000-0xa63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x9a4000000-0x9e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x924000000-0x963ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x8a4000000-0x8e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x824000000-0x863ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x7a4000000-0x7e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x724000000-0x763ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x6a4000000-0x6e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x624000000-0x663ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x5a4000000-0x5e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x524000000-0x563ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x4a4000000-0x4e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x424000000-0x463ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x3a4000000-0x3e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x324000000-0x363ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x2a4000000-0x2e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x224000000-0x263ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xd8000000-0xffffffff]
pci_root PNP0A08:00: host bridge window [mem 0x000c8000-0x000dffff]
pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bfffffff]
pci_bus 0000:00: root bus resource [mem 0x9a4000000-0x9e3ffffff]
0:03.0s 0000:00: root bus resource [mem 0x924000000-0x963ffffff]
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:08.0: [8086:359b] type 00 class 0x088000
pci 0000:00:1c.0: [8086:25ae] type 01 class 0x060400
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:00:1c.0
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:00:1c.0
pci 0000:00:1d.0: [8086:25a9] type 00 class 0x0c0300
pci 0000:00:1d.0: reg 20: [io  0x2200-0x221f]
pci 0000:00:1d.1: [8086:25aa] type 00 class 0x0c0300
pci 0000:00:1d.1: reg 20: [io  0x2600-0x261f]
pci 0000:00:1d.4: [8086:25ab] type 00 class 0x088000
pci 0000:00:1d.4: reg 10: [mem 0x00000000-0x0000000f]
pci 0000:00:1d.5: [8086:25ac] type 00 class 0x080020
pci 0000:00:1e.0: [8086:244e] type 01 class 0x060400
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:00:1e.0
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:00:1e.0
pci 0000:00:1f.0: [8086:25a1] type 00 class 0x060100
calling  old_ich_force_enable_hpet_user+0x0/0x30 @ 1 for 0000:00:1f.0
pci fixup old_ich_force_enable_hpet_user+0x0/0x30 returned after 0 usecs fo=
r 0000:00:1f.0
calling  quirk_ich4_lpc_acpi+0x0/0xbc @ 1 for 0000:00:1f.0
pci fixup quirk_ich4_lpc_acpi+0x0/0xbc returned after 0 usecs for 0000:00:1=
f.0
pci 0000:00:1f.1: [8086:25a2] type 00 class 0x01018a
pci 0000:00:1f.1: reg 10: [io  0x0000-0x0007]
pci 0000:00:1f.1: reg 14: [io  0x0000-0x0003]
pci 0000:00:1f.1: reg 18: [io  0x0000-0x0007]
pci 0000:00:1f.1: reg 1c: [io  0x0000-0x0003]
pci 0000:00:1f.1: reg 20: [io  0x0000-0x000f]
pci 0000:00:1f.1: reg 24: [mem 0x00000000-0x000003ff]
pci 0000:00:1f.3: [8086:25a4] type 00 class 0x0c0500
pci 0000:00:1f.3: reg 20: [io  0x0440-0x045f]
pci 0000:04:00.0: [8086:0329] type 01 class 0x060400
calling  quirk_pcie_pxh+0x0/0x31 @ 1 for 0000:04:00.0
pci 0000:04:00.0: PXH quirk detected; SHPC device MSI disabled
pci fixup quirk_pcie_pxh+0x0/0x31 returned after 976 usecs for 0000:04:00.0
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:04:00.0
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:04:00.0
pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
pci 0000:04:00.2: [8086:032a] type 01 class 0x060400
calling  quirk_pcie_pxh+0x0/0x31 @ 1 for 0000:04:00.2
pci 0000:04:00.2: PXH quirk detected; SHPC device MSI disabled
pci fixup quirk_pcie_pxh+0x0/0x31 returned after 976 usecs for 0000:04:00.2
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:04:00.2
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:04:00.2
pci 0000:04:00.2: PME# supported from D0 D3hot D3cold
pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it=
 with 'pcie_aspm=3Dforce'
pci 0000:00:03.0: PCI bridge to [bus 04-06]
pci 0000:00:03.0:   bridge window [io  0x5000-0xffff]
pci 0000:00:03.0:   bridge window [mem 0xdb000000-0xdcffffff]
pci 0000:04:00.0: PCI bridge to [bus 06-06]
pci 0000:04:00.0:   bridge window [io  0x5000-0xffff]
pci 0000:05:01.0: [14e4:16tive decode)
pci 0000:00:1e.0:   bridge window [mem 0xd24000000-0xd63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xca4000000-0xce3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xc24000000-0xc63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xba4000000-0xbe3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xb24000000-0xb63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xaa4000000-0xae3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xa24000000-0xa63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x9a4000000-0x9e3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x924000000-0x963ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x8a4000000-0x8e3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x824000000-0x863ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x7a40ow [mem 0x2a4000000-0x2e3fffff=
f] (subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x224000000-0x263ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xd8000000-0xffffffff] (subtractive =
decode)
pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive =
decode)
pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1.PCI2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1.PCI3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIS._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIX._PRT]
 pci0000:00: Requesting ACPI _OSC control (0x1d)
 pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask=
: 0x1d
ACPI _OSC control for PCIe not granted, disabling ASPM
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:00.1
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:1c.0
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) traps.c:486:d0 Unhandled nmi fault/trap [#2] on VCPU 0 [ec=3D0000]
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.4
(XEN) PCI add device 0000:00:1d.5
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.1
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:04:00.0
(XEN) PCI add device 0000:04:00.2
(XEN) PCI add device 0000:05:01.0
(XEN) PCI add device 0000:05:01.1
(XEN) PCI add device 0000:02:01.0
(XEN) PCI add device 0000:01:01.0
initcall acpi_pci_root_init+0x0/0x32 returned 0 after 226527 usecs
calling  acpi_pci_link_init+0x0/0x43 @ 1
ACPI: PCI Interrupt Link [LP00] (IRQs *10)
ACPI: PCI Interrupt Link [LP01] (IRQs *7)
ACPI: PCI Interrupt Link [LP02] (IRQs *5)
ACPI: PCI Interrupt Link [LP03] (IRQs *5)
ACPI: PCI Interrupt Link [LP04] (IRQs *10)
ACPI: PCI Interrupt Link [LP05] (IRQs) *0, disabled.
ACPI: PCI Interrupt Link [LP06] (IRQs *10)
ACPI: PCI Interrupt Link [LP07] (IRQs) *0, disabled.
initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
calling  pnp_init+0x0/0x19 @ 1
initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
calling  xen_setup_shutdown_event+0x0/0x30 @ 1
initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 0 usecs
calling  balloon_init+0x0/0x133 @ 1
xen/balloon: Initialising balloon driver.
initcall balloon_init+0x0/0x133 returned 0 after 0 usecs
calling  xenbus_probe_backend_init+0x0/0x5e @ 1
initcall xenbus_probe_backend_init+0x0/0x5e returned 0 after 0 usecs
calling  xenbus_probe_frontend_init+0x0/0x5e @ 1
initcall xenbus_probe_frontend_init+0x0/0x5e returned 0 after 0 usecs
calling  balloon_init+0x0/0x35 @ 1
xen-balloon: Initialising balloon driver.
initcall balloon_init+0x0/0x35 returned 0 after 0 usecs
calling  ab8500_regulator_init+0x0/0x31 @ 1
initcall ab8500_regulator_init+0x0/0x31 returned 0 after 0 usecs
calling  misc_init+0x0/0xba @ 1
initcall misc_init+0x0/0xba returned 0 after 0 usecs
calling  vga_arb_device_init+0x0/0xde @ 1
vgaarb: device added: PCI:0000:01:01.0,decodes=3Dio+mem,owns=3Dio+mem,locks=
=3Dnone
vgaarb: loaded
vgaarb: bridge control possible 0000:01:01.0
initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
calling  cn_init+0x0/0x9e @ 1
initcall cn_init+0x0/0x9e returned 0 after 0 usecs
calling  stmpe_init+0x0/0x14 @ 1
initcall stmpe_init+0x0/0x14 returned 0 after 0 usecs
calling  stmpe_init+0x0/0x12 @ 1
initcall stmpe_init+0x0/0x12 returned 0 after 0 usecs
calling  wm831x_spi_init+0x0/0x28 @ 1
initcall wm831x_spi_init+0x0/0x28 returned 0 after 0 usecs
calling  tps65912_spi_init+0x0/0x28 @ 1
initcall tps65912_spi_init+0x0/0x28 returned 0 after 0 usecs
calling  ezx_pcap_init+0x0/0x12 @ 1
initcall ezx_pcap_init+0x0/0x12 returned 0 after 0 usecs
calling  da9052_spi_init+0x0/0x31 @ 1
initcall da9052_spi_init+0x0/0x31 returned 0 after 0 usecs
calling  ab8500_sysctrl_init+0x0/0x12 @ 1
initcall ab8500_sysctrl_ini: Using ACPI for IRQ routing
PCI: pci_cache_line_size set to 64 bytes
reserve RAM buffer: 000000000009d000 - 000000000009ffff
reserve RAM buffer: 0000000010063000 - 0000000013ffffff
initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
calling  proto_init+0x0/0x12 @ 1
initcall proto_init+0x0/0x12 returned 0 after 0 usecs
calling  net_dev_init+0x0/0x1b3 @ 1
initcall net_dev_init+0x0/0x1b3 returned 0 after 0 usecs
calling  neigh_init+0x0/0x80 @ 1
initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
calling  fib_rules_init+0x0/0xaf @ 1
initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
calling  pktsched_init+0x0/0xfe @ 1
initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
calling  tc_filter_init+0x0/0x55 @ 1
initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
calling  tc_action_init+0x0/0x55 @ 1
initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
calling  genl_init+0x0/0x84 @ 1
initcall genl_init+0x0/0x84 returned 0 after 0 usecs
calling  cipso_v4_init+0x0/0x61 @ 1
initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
calling  wireless_nlevent_init+0x0/0x12 @ 1
initcall wireless_nlevent_init+0x0/0x12 returned 0 after 0 usecs
calling  netlbl_init+0x0/0x81 @ 1
NetLabel: Initializing
NetLabel:  domain hash size =3D 128
NetLabel:  protocols =3D UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
calling  net_sysctl_init+0x0/0x49 @ 1
initcall net_sysctl_init+0x0/0x49 returned 0 after 0 usecs
calling  nfc_init+0x0/0x9e @ 1
nfc: nfc_init: NFC Core ver 0.1
NET: Registered protocol family 39
initcall nfc_init+0x0/0x9e returned 0 after 0 usecs
calling  ab8500_gpadc_init+0x0/0x12 @ 1
initcall ab8500_gpadc_init+0x0/0x12 returned 0 after 0 usecs
calling  ab8500_charger_init+0x0/0x12 @ 1
initcall ab8500_charger_init+0x0/0x12 returned 0 after 0 usecs
calling  ab8500_btemp_init+0x0/0x12 @ 1
initcall ab8500_btemp_init+0x0/0x12 returned 0 after 0 usecs
calling  ab8500_fg_init+0x0/0x12 @ 1
initcall ab8500_fg_init+0x0/0x12 returned 0 after 0 usecs
calling  xen_p2m_debugfs+0x0/0x4a @ 1
initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
calling  hpet_late_init+0x0/0x103 @ 1
initcall hpet_late_init+0x0/0x103 returned -19 after 0 usecs
calling  init_amd_nbs+0x0/0x3f @ 1
initcall init_amd_nbs+0x0/0x3f returned 0 after 0 usecs
calling  clocksource_done_booting+0x0/0x5a @ 1
Switching to clocksource xen
initcall clocksource_done_booting+0x0/0x5a returned 0 after 8 usecs
calling  ftrace_init_debugfs+0x0/0xdx314 @ 1
initcall tracer_init_debugfs+0x0/0x314 returned 0 after 156 usecs
calling  init_trace_printk_function_export+0x0/0x2f @ 1
initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 5 usecs
calling  event_trace_init+0x0/0x1bb @ 1
initcall event_trace_init+0x0/0x1bb returned 0 after 13106 usecs
calling  init_kprobe_trace+0x0/0x93 @ 1
initcall init_kprobe_trace+0x0/0x93 returned 0 after 7 usecs
calling  init_pipe_fs+0x0/0x4c @ 1
initcall init_pipe_fs+0x0/0x4c returned 0 after 30 usecs
calling  eventpoll_init+0x0/0xda @ 1
initcall eventpoll_init+0x0/0xda returned 0 after 106 usecs
calling  anon_inode_init+0x0/0x5b @ 1
initcall anon_inode_init+0x0/0x5b returned 0 after 17 usecs
calling  tomoyo_initerface_init+0x0/0x17d @ 1
initcall tomoyo_initerface_init+0x0/0x17d returned 0 after 0 usecs
calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
calling  acpi_event_init+0x0/0x81 @ 1
initcall acpi_event_init+0x0/0x81 returned 0 after 18 usecs
calling  pnp_system_init+0x0/0x12 @ 1
initcall pnp_system_init+0x0/0x12 returned 0 after 24 usecs
calling  pnpacpi_init+0x0/0x8c @ 1
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp 00:00: [mem 0xf24000000-0xfffffffff window]
pnp 00:00: [mem 0xea4000000-0xee3ffffff window]
pnp 00:00: [mem 0xe24000000-0xe63ffffff window]
pnp 00:00: [mem 0xda4000000-0xde3ffffff window]
pnp 00:00: [mem 0xd24000000-0xd63ffffff window]
pnp 00:00: [mem 0xca4000000-0xce3ffffff window]
pnp 00:00: [mem 0xc24000000-0xc63ffffff window]
pnp 00:00: [mem 0xba4000000-0xbe3ffsign_resources+0x0/0xf8 @ 1
pci 0000:00:1c.0: BAR 15: assigned [mem 0xd8000000-0xd80fffff pref]
pci 0000:00:1f.1: BAR 5: assigned [mem 0xd8100000-0xd81003ff]
pci 0000:00:1d.4: BAR 0: assigned [mem 0xd8100400-0xd810040f]
pci 0000:00:1f.1: BAR 4: assigned [io  0x1000-0x100f]
pci 0000:04:00.0: PCI bridge to [bus 06-06]
pci 0000:04:00.0:   bridge window [io  0x5000-0xffff]
pci 0000:04:00.2: PCI bridge to [bus 05-05]
pci 0000:04:00.2:   bridge window [mem 0xdb000000-0xdcffffff]
pci 0000:00:03.0: PCI bridge to [bus 04-06]
pci 0000:00:03.0:   bridge window [io  0x5000-0xffff]
pci 0000:00:03.0:   bridge window [mem 0xdb000000-0xdcffffff]
pci 0000:02:01.0: BAR 6: assigned [mem 0xd8000000-0xd80fffff pref]
pci 0000:00:1c.0: PCI bridge to [bus 02-02]
pci 0000:00:1c.0:   bridge window [io  0x4000-0x4fff]
pci 0000:00:1c.0:   bridge window [mem 0xdd000000-0xdeffffff]
pci 0000:00:1c.0:   bridge window [mem 0xd8000000-0xd80fffff pref]
pci 0000:01:01.0: BAR 6: assigned [mem 0xf8020000-0xf803ffff pref]
pci 0000:00:1e.0: PCI bridge to [bus 01-01]
pci 0000:00:1e.0:   bridge window [io  0x3000-0x3fff]
pci 0000:00:1e.0:   bridge window [mem 0xf8000000-0xf8ffffff]
pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xf7ffffff pref]
xen: registering gsi 16 triggering 0 pole 0 [io  0x5000-0xffff]
pci_bus 0000:04: resource 1 [mem 0xdb000000-0xdcffffff]
pci_bus 0000:06: resource 0 [io  0x5000-0xffff]
pci_bus 0000:05: resource 1 [mem 0xdb000000-0xdcffffff]
pci_bus 0000:02: resource 0 [io  0x4000-0x4fff]
pci_bus 0000:02: resource 1 [mem 0xdd000000-0xdeffffff]
pci_bus 0000:02: resource 2 [mem 0xd8000000-0xd80fffff pref]
pci_bus 0000:01: resource 0 [io  0x3000-0x3fff]
pci_bus 0000:01: resource 1 [mem 0xf8000000-0xf8ffffff]
pci_bus 0000:01: resource 2 [mem 0xf0000000-0xf7ffffff pref]
pci_bus 0000:01: resource 4 [mem 0xf24000000-0xfffffffff]
pci_bus 0000:01: resource 5 [mem 0xea4000000-0xee3ffffff]
pci_bus 0000:01: resource 6 [mem 0xe24000000-0xe63ffffff]
pci_bus 0000:01: resource 7 [mem 0xda4000000-0xde3ffffff]
pci_bus 0000:01: resource 8 [mem 0xd24000000-0xd63ffffff]
pci_bus 0000:01: resource 9 [mem 0xca4000000-0xce3ffffff]
pci_bus 0000:01: resource 10 [mem 0xc24000000-0xc63ffffff]
pci_bus 0000:01: resource 11 [mem 0xba4000000-0xbe3ffffff]
pci_bus 0000:01: resource 12 [mem 0xb24000000-0xb63ffffff]
pci_bus 0000:01: resource 13 [mem 0xaa4000000-0xae3ffffff]
pci_bus 0000:01: resource 14 [mem 0xa24000000-0xa63ffffff]
pci_bus 0000:01: resource 15 [mem 0x9a4000000-0x9e3ffffff]
pci_bus 0000:01: resource 16 [mem 0x924000000-0x963ffffff]
pci_bus 0000:01: resource 17 [mem 0x8a4000000-0x8e3ffffff]
pci_bus 0000:01: resource 18 [mem 0x824000000-0x863ffffff]
pci_bus 0000:01: resource 19 [mem 0x7a4000000-0x7e3ffffff]
pci_bus 0000:01: resource 20 [mem 0x724000000-0x763ffffff]
pci_bus 0000:01: resource 21 [mem 0x6a4000000-0x6e3ffffff]
pci_bus 0000:01: resource 22 [mem 0x624000000-0x663ffffff]
pci_bus 0000:01: resource 23 [mem 0x5a4000000-0x5e3ffffff]
pci_bus 0000:01: resource 24 [mem 0x524000000-0x563ffffff]
pci_bus 0000:01: resource 25 [mem 0x4a4000000-0x4e3ffffff]
pci_bus 0000:0?[2J



-- Pasi


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 20:09:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 20: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 1U2op3-0008Em-7n; Tue, 05 Feb 2013 20:08:53 +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 1U2op0-0008Eh-H9
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 20:08:51 +0000
Received: from [85.158.139.83:50360] by server-9.bemta-5.messagelabs.com id
	66/B2-24440-1D661115; Tue, 05 Feb 2013 20:08:49 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360094928!31009775!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzA2NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26861 invoked from network); 5 Feb 2013 20:08:49 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 20:08: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 022811977;
	Tue,  5 Feb 2013 22:08:47 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id CCD06EC027; Tue,  5 Feb 2013 22:08:47 +0200 (EET)
Date: Tue, 5 Feb 2013 22:08:47 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130205200847.GS8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130205163021.GR8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: arrfab@centos.org, xen-devel@lists.xen.org
Subject: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
	panel NMI 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="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, Feb 05, 2013 at 06:30:21PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Tue, Feb 05, 2013 at 04:49:47PM +0100, agya naila wrote:
> >    Hello Everyone,
> >    I am quite new on XEN. I tried to installed XEN on my server and I k=
now
> >    this server series IBM Xeon 3,4 Ghz didn't have Intel VTx support so=
 I am
> >    pllaning to use paravirtualization.
> >    I configure the server with Ubuntu Desktop  12.0464 bit as dom0 with=
 XEN
> >    4.1 64 hypervisor. The configuration using repositories exactly by t=
his
> >    tutorial [1]https://help.ubuntu.com/community/XenProposed :
> >
> =

> - What exact Xen version are you using? =

> - What exact Linux dom0 kernel are you using? =

> - Please paste your grub settings for the Xen entry.
> - Did you capture the error/crash logs from the Serial console? (SOL prov=
ided by the blade management).
> =

> =


<snip>

> > =

> >    Now reboot:
> > =

> >  sudo reboot
> > =

> >    But when rebooting the Dom0 failed to start, enclosed was the error
> >    message when Xen booting and after that Dom0 will restarting over and
> >    over.
> >    On Blade server system  log I got error message :
> >    (Bestak_septaher) SMI Hdlr: 00151743 HI Fatal Error, HI_FERR/NERR Va=
lue=3D
> >    0020
> >    (Bestak_septaher) Critical Interrupt - Front panel NMI
> >    Please Suggest, thank you very much for any one help.
>

Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade with X=
en 4.2.1 =

with Linux 3.4.28 dom0 kernel.

Does this ring anyone's bells? =



serial console log of the crash (also available on: http://pastebin.centos.=
org/1204/):


(XEN) Xen version 4.2.1 (mockbuild@(none)) (gcc (GCC) 4.4.6 20120305 (Red H=
at 4.4.6-4)) Thu Jan 31 20:36:24 UTC 2013
(XEN) Latest ChangeSet: unavailable
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=3D256M,max:256M loglvl=3Dall guest_loglvl=3Dal=
l com2=3D19200,8n1 console=3Dcom2,vga lapic=3Ddebug apic_verbosity=3Ddebug =
apic=3Ddebug iommu=3Doff sync_console
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d400 (usable)
(XEN)  000000000009d400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000d7fb0580 (usable)
(XEN)  00000000d7fb0580 - 00000000d7fd0000 (ACPI data)
(XEN)  00000000d7fd0000 - 00000000d8000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000128000000 (usable)
(XEN) ACPI: RSDP 000FDFE0, 0014 (r0 IBM   )
(XEN) ACPI: RSDT D7FCFF80, 0030 (r1 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) ACPI: FACP D7FCFEC0, 0084 (r2 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) ACPI: DSDT D7FBE4A8, 1F2A (r1 IBM    SERBLADE     1000 INTL  2002025)
(XEN) ACPI: FACS D7FCFD80, 0040
(XEN) ACPI: APIC D7FCFE00, 00A8 (r1 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) ACPI: MCFG D7FCFDC0, 003C (r1 IBM    SERBLADE     1000 IBM  45444F43)
(XEN) System RAM: 4095MB (4193588kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000128000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 0009d540
(XEN) DMI 2.3 present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x588
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN) ACPI:                  wakeup_vec[d7fcfd8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
(XEN) Processor #6 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
(XEN) Processor #7 15:4 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 14, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 13, version 32, address 0xfec10000, GSI 24-47
(XEN) ACPI: IOAPIC (id[0x0c] address[0xfec81000] gsi_base[48])
(XEN) IOAPIC[2]: apic_id 12, version 32, address 0xfec81000, GSI 48-71
(XEN) ACPI: IOAPIC (id[0x0b] address[0xfec81400] gsi_base[72])
(XEN) IOAPIC[3]: apic_id 11, version 32, address 0xfec81400, GSI 72-95
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ11 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 4 I/O APICs
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
(XEN) mapped APIC to ffff82c3ffdfe000 (fee00000)
(XEN) mapped IOAPIC to ffff82c3ffdfd000 (fec00000)
(XEN) mapped IOAPIC to ffff82c3ffdfc000 (fec10000)
(XEN) mapped IOAPIC to ffff82c3ffdfb000 (fec81000)
(XEN) mapped IOAPIC to ffff82c3ffdfa000 (fec81400)
(XEN) IRQ limits: 96 GSI, 688 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 3200.224 MHz processor.
(XEN) Initing memory sharing.
(XEN) traps.c:3156: GPF (0000): ffff82c48019e43d -> ffff82c4802164d0
(XEN) mce_intel.c:1239: MCA Capability: BCAST 0 SER 0 CMCI 0 firstbank 0 ex=
tended MCE MSR 18
(XEN) Intel machine check reporting enabled
(XEN) PCI: Found Intel Corporation E7520 Memory Controller Hub with MMCONFI=
G support.
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) I/O virtualisation disabled
(XEN) Getting VERSION: 50014
(XEN) Getting VERSION: 50014
(XEN) Getting ID: 0
(XEN) Getting LVT0: 700
(XEN) Getting LVT1: 400
(XEN) enabled ExtINT on CPU#0
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) init IO_APIC IRQs
(XEN)  IO-APIC (apicid-pin) 14-0, 14-16, 14-17, 14-18, 14-19, 14-20, 14-21,=
 14-22, 14-23, 13-0, 13-1, 13-2, 13-3, 13-4, 13-5, 13-6, 13-7, 13-8, 13-9, =
13-10, 13-11, 13-12, 13-13, 13-14, 13-15, 13-16, 13-17, 13-18, 13-19, 13-20=
, 13-21, 13-22, 13-23, 12-0, 12-1, 12-2, 12-3, 12-4, 12-5, 12-6, 12-7, 12-8=
, 12-9, 12-10, 12-11, 12-12, 12-13, 12-14, 12-15, 12-16, 12-17, 12-18, 12-1=
9, 12-20, 12-21, 12-22, 12-23, 11-0, 11-1, 11-2, 11-3, 11-4, 11-5, 11-6, 11=
-7, 11-8, 11-9, 11-10, 11-11, 11-12, 11-13, 11-14, 11-15, 11-16, 11-17, 11-=
18, 11-19, 11-20, 11-21, 11-22, 11-23 not connected.
(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) number of MP IRQ sources: 15.
(XEN) number of IO-APIC #14 registers: 24.
(XEN) number of IO-APIC #13 registers: 24.
(XEN) number of IO-APIC #12 registers: 24.
(XEN) number of IO-APIC #11 registers: 24.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #14......
(XEN) .... register #00: 0E000000
(XEN) .......    : physical APIC id: 0E
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 001 01  0    0    0   0   0    1    1    28
(XEN)  02 001 01  0    0    0   0   0    1    1    F0
(XEN)  03 001 01  0    0    0   0   0    1    1    F1
(XEN)  04 001 01  0    0    0   0   0    1    1    30
(XEN)  05 001 01  0    0    0   0   0    1    1    38
(XEN)  06 001 01  0    0    0   0   0    1    1    40
(XEN)  07 001 01  0    0    0   0   0    1    1    48
(XEN)  08 001 01  0    0    0   0   0    1    1    50
(XEN)  09 001 01  0    0    0   0   0    1    1    58
(XEN)  0a 001 01  0    0    0   0   0    1    1    60
(XEN)  0b 001 01  1    1    0   0   0    1    1    68
(XEN)  0c 001 01  0    0    0   0   0    1    1    70
(XEN)  0d 001 01  0    0    0   0   0    1    1    78
(XEN)  0e 001 01  0    0    0   0   0    1    1    88
(XEN)  0f 001 01  0    0    0   0   0    1    1    90
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) IO APIC #13......
(XEN) .... register #00: 0D000000
(XEN) .......    : physical APIC id: 0D
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 000 00  1    0    0   0   0    0    0    00
(XEN)  02 000 00  1    0    0   0   0    0    0    00
(XEN)  03 000 00  1    0    0   0   0    0    0    00
(XEN)  04 000 00  1    0    0   0   0    0    0    00
(XEN)  05 000 00  1    0    0   0   0    0    0    00
(XEN)  06 000 00  1    0    0   0   0    0    0    00
(XEN)  07 000 00  1    0    0   0   0    0    0    00
(XEN)  08 000 00  1    0    0   0   0    0    0    00
(XEN)  09 000 00  1    0    0   0   0    0    0    00
(XEN)  0a 000 00  1    0    0   0   0    0    0    00
(XEN)  0b 000 00  1    0    0   0   0    0    0    00
(XEN)  0c 000 00  1    0    0   0   0    0    0    00
(XEN)  0d 000 00  1    0    0   0   0    0    0    00
(XEN)  0e 000 00  1    0    0   0   0    0    0    00
(XEN)  0f 000 00  1    0    0   0   0    0    0    00
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) IO APIC #12......
(XEN) .... register #00: 0C000000
(XEN) .......    : physical APIC id: 0C
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #02: 0C000000
(XEN) .......     : arbitration: 0C
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 000 00  1    0    0   0   0    0    0    00
(XEN)  02 000 00  1    0    0   0   0    0    0    00
(XEN)  03 000 00  1    0    0   0   0    0    0    00
(XEN)  04 000 00  1    0    0   0   0    0    0    00
(XEN)  05 000 00  1    0    0   0   0    0    0    00
(XEN)  06 000 00  1    0    0   0   0    0    0    00
(XEN)  07 000 00  1    0    0   0   0    0    0    00
(XEN)  08 000 00  1    0    0   0   0    0    0    00
(XEN)  09 000 00  1    0    0   0   0    0    0    00
(XEN)  0a 000 00  1    0    0   0   0    0    0    00
(XEN)  0b 000 00  1    0    0   0   0    0    0    00
(XEN)  0c 000 00  1    0    0   0   0    0    0    00
(XEN)  0d 000 00  1    0    0   0   0    0    0    00
(XEN)  0e 000 00  1    0    0   0   0    0    0    00
(XEN)  0f 000 00  1    0    0   0   0    0    0    00
(XEN)  10 000 00  1    0    0   0   0    0    0 0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) IO APIC #11......
(XEN) .... register #00: 0B000000
(XEN) .......    : physical APIC id: 0B
(XEN) .......    : Delivery Type: 0
(XEN) .......    : LTS          : 0
(XEN) .... register #01: 00178020
(XEN) .......     : max redirection entries: 0017
(XEN) .......     : PRQ implemented: 1
(XEN) .......     : IO APIC version: 0020
(XEN) .... register #02: 0B000000
(XEN) .......     : arbitration: 0B
(XEN) .... register #03: 00000001
(XEN) .......     : Boot DT    : 1
(XEN) .... IRQ redirection table:
(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:  =

(XEN)  00 000 00  1    0    0   0   0    0    0    00
(XEN)  01 000 00  1    0    0   0   0    0    0    00
(XEN)  02 000 00  1    0    0   0   0    0    0    00
(XEN)  03 000 00  1    0    0   0   0    0    0    00
(XEN)  04 000 00  1    0    0   0   0    0    0    00
(XEN)  05 000 00  1    0    0   0   0    0    0    00
(XEN)  06 000 00  1    0    0   0   0    0    0    00
(XEN)  07 000 00  1    0    0   0   0    0    0    00
(XEN)  08 000 00  1    0    0   0   0    0    0    00
(XEN)  09 000 00  1    0    0   0   0    0    0    00
(XEN)  0a 000 00  1    0    0   0   0    0    0    00
(XEN)  0b 000 00  1    0    0   0   0    0    0    00
(XEN)  0c 000 00  1    0    0   0   0    0    0    00
(XEN)  0d 000 00  1    0    0   0   0    0    0    00
(XEN)  0e 000 00  1    0    0   0   0    0    0    00
(XEN)  0f 000 00  1    0    0   0   0    0    0    00
(XEN)  10 000 00  1    0    0   0   0    0    0    00
(XEN)  11 000 00  1    0    0   0   0    0    0    00
(XEN)  12 000 00  1    0    0   0   0    0    0    00
(XEN)  13 000 00  1    0    0   0   0    0    0    00
(XEN)  14 000 00  1    0    0   0   0    0    0    00
(XEN)  15 000 00  1    0    0   0   0    0    0    00
(XEN)  16 000 00  1    0    0   0   0    0    0    00
(XEN)  17 000 00  1    0    0   0   0    0    0    00
(XEN) Using vector-based indexing
(XEN) IRQ to pin mappings:
(XEN) IRQ240 -> 0:2
(XEN) IRQ40 -> 0:1
(XEN) IRQ241 -> 0:3
(XEN) IRQ48 -> 0:4
(XEN) IRQ56 -> 0:5
(XEN) IRQ64 -> 0:6
(XEN) IRQ72 -> 0:7
(XEN) IRQ80 -> 0:8
(XEN) IRQ88 -> 0:9
(XEN) IRQ96 -> 0:10
(XEN) IRQ104 -> 0:11
(XEN) IRQ112 -> 0:12
(XEN) IRQ120 -> 0:13
(XEN) IRQ136 -> 0:14
(XEN) IRQ144 -> 0:15
(XEN) .................................... done.
(XEN) Using local APIC timer interrupts.
(XEN) calibrating APIC timer ...
(XEN) ..... CPU clock speed is 3200.1563 MHz.
(XEN) ..... host bus clock speed is 200.0096 MHz.
(XEN) ..... bus_scale =3D 0x0000CCD7
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 32 KiB.
(XEN) masked ExtINT on CPU#1
(XEN) masked ExtINT on CPU#2
(XEN) masked ExtINT on CPU#3
(XEN) Brought up 4 CPUs
(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
(XEN) ACPI sleep)  Init. ramdisk: ffffffff82b1b000->ffffffff859e5c00
(XEN)  Phys-Mach map: ffffffff859e6000->ffffffff85a66000
(XEN)  Start info:    ffffffff85a66000->ffffffff85a664b4
(XEN)  Page tables:   ffffffff85a67000->ffffffff85a98000
(XEN)  Boot stack:    ffffffff85a98000->ffffffff85a99000
(XEN)  TOTAL:         ffffffff80000000->ffffffff85c00000
(XEN)  ENTRY ADDRESS: ffffffff81b1c200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ......................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t=
o Xen)
(XEN) Freed 252kB init memory.
mapping kernel into physical memory
about to get started...
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.4.28-6.el6.centos.alt.x86_64 (mockbuild@bn3.alt.bsys.dev.ce=
ntos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Thu =
Jan 31 22:39:42 UTC 2013
Command line: ro root=3D/dev/mapper/c6kvm--vg-lv_root rd_NO_LUKS rd_LVM_LV=
=3Dc6kvm-vg/lv_root LANG=3Den_US.UTF-8 crashkernel=3Dauto rd_NO_MD SYSFONT=
=3Dlatarcyrheb-sun16 rd_LVM_LV=3Dc6kvm-vg/lv_swap  KEYBOARDTYPE=3Dpc KEYTAB=
LE=3Dus rd_NO_DM earlyprintk=3Dxen console=3Dhvc0 nomodeset initcall_debug =
debug loglevel=3D10
Freeing 9d-100 pfn range: 99 pages freed
Released 99 pages of unused memory
Set 164019 page(s) to 1-1 mapping
Populating 10000-10063 pfn range: 99 pages added
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009d000 (usable)
 Xen: 000000000009d400 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000010063000 (usable)
 Xen: 0000000010063000 - 00000000d7fb0580 (unusable)
 Xen: 00000000d7fb0580 - 00000000d7fd0000 (ACPI data)
 Xen: 00000000d7fd0000 - 00000000d8000000 (reserved)
 Xen: 00000000e0000000 - 00000000f0000000 (reserved)
 Xen: 00000000fec00000 - 0000000100000000 (reserved)
 Xen: 0000000100000000 - 0000000128000000 (unusable)
bootconsole [xenboot0] enabled
Notice: NX (Execute Disable) protection missing in CPU!
SMBIOS 2.3 present.
DMI: IBM IBM BladeCenter HS20 -[8843E6G]-/Server Blade, BIOS -[BWE132AUS-1.=
13]- 12/19/2008
e820 update range: 000000M    SERBLADE 00001000 INTL 02002025)
ACPI: FACS 00000000d7fcfd80 00040
ACPI: APIC 00000000d7fcfe00 000A8 (v01 IBM    SERBLADE 00001000 IBM  45444F=
43)
ACPI: MCFG 00000000d7fcfdc0 0003C (v01 IBM    SERBLADE 00001000 IBM  45444F=
43)
ACPI: Local APIC address 0xfee00000
NUMA turned off
Faking a node at 0000000000000000-0000000010063000
Initmem setup node 0 0000000000000000-0000000010063000
  NODE_DATA [000000001003d000 - 0000000010062fff]
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   empty
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000010 -> 0x0000009d
    0: 0x00000100 -> 0x00010063
On node 0 totalpages: 65520
  DMA zone: 56 pages used for memmap
  DMA zone: 5 pages reserved
  DMA zone: 3920 pages, LIFO batch:0
  DMA32 zone: 842 pages used for memmap
  DMA32 zone: 60697 pages, LIFO batch:15
ACPI: PM-Timer IO Port: 0x588
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 14, version 253, address 0xfec00000, GSI 0-253
ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 13, version 253, address 0xfec10000, GSI 24-277
ACPI: IOAPIC (id[0x0c] address[0xfec81000] gsi_base[48])
IOAPIC[2]: apic_id 12, version 253, address 0xfec81000, GSI 48-301
ACPI: IOAPIC (id[0x0b] address[0xfec81400] gsi_base[72])
IOAPIC[3]: apic_id 11, version 253, address 0xfec81400, GSI 72-325
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ11 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 4 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 342
PM: Registered nosave memory: 000000000009d000 - 000000000009e000
PM: Registered nosave memory: 000000000009e000 - 0000000000100000
Allocating PCI resources starting at f0000000 (gap: f0000000:ec00000)
Booting paravirtualized kernel on Xen
Xen version: 4.2.1 (preserve-AD)
setup_percpu: NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Embedded 28 pages/cpu @ffff88000fe00000 s82432 r8192 d24064 u524288
pcpu-alloc: s82432 r8192 d24064 u524288 alloc=3D1*2097152
pcpu-alloc: [0] 0 1 2 3
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 64617
Policy zone: DMA32
Kernel command line: ro root=3D/dev/mapper/c6kvm--vg-lv_root rd_NO_LUKS rd_=
LVM_LV=3Dc6kvm-vg/lv_root LANG=3Den_US.UTF-8 crashkernel=3Dauto rd_NO_MD SY=
SFONT=3Dlatarcyrheb-sun16 rd_LVM_LV=3Dc6kvm-vg/lv_swap  KEYBOARDTYPE=3Dpc K=
EYTABLE=3Dus rd_NO_DM earlyprintk=3Dxen console=3Dhvc0 nomodeset initcall_d=
ebug debug loglevel=3D10
PID hash table entries: 1024 (order: 1, 8192 bytes)
Placing 64MB software IO TLB between ffff88000b200000 - ffff88000f200000
software IO TLB at phys 0xb200000 - 0xf200000
Memory: 125496k/262540k available (5643k kernel code, 460k absent, 136584k =
reserved, 5643k data, 1464k init)
Hierarchical RCU implementation.
NR_IRQS:262400 nr_irqs:1024 16
xen: sci override: global_irq=3D11 trigger=3D0 polarity=3D0
xen: registering gsi 11 triggering 0 polarity 0
xen: --> pirq=3D11 -> irq=3D11 (gsi=3D11)
(XEN) IOAPIC[0]: Set PCI routing entry (14-11 -> 0x68 -> IRQ 11 Mode:1 Acti=
ve:0)
xen: acpi sci 11
xen: --> pirq=3D1 -> irq=3D1 (gsi=3D1)
xen: --> pirq=3D2 -> irq=3D2 (gsi=3D2)
xen: --> pirq=3D3 -> irq=3D3 (gsi=3D3)
xen: --> pirq=3D4 -> irq=3D4 (gsi=3D4)
xen: --> pirq=3D5 -> irq=3D5 (gsi=3D5)
xen: --> pirq=3D6 -> irq=3D6 (gsi=3D6)
xen: --> pirq=3D7 -> irq=3D7 (gsi=3D7)
xen: --> pirq=3D8 -> irq=3D8 (gsi=3D8)
xen: --> pirq=3D9 -> irq=3D9 (gsi=3D9)
xen: --> pirq=3D10 -> irq=3D10 (gsi=3D10)
xen: --> pirq=3D12 -> irq=3D12 (gsi=3D12)
xen: --> pirq=3D13 -> irq=3D13 (gsi=3D13)
xen: --> pirq=3D14 -> irq=3D14 (gsi=3D14)
xen: --> pirq=3D15 ->nit_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
calling  init_hw_perf_events+0x0/0x44f @ 1
Performance Events: unsupported Netburst CPU model 4 no PMU driver, softwar=
e events only.
initcall init_hw_perf_events+0x0/0x44f returned 0 after 2929 usecs
calling  register_trigger_all_cpu_backtrace+0x0/0x1f @ 1
initcall register_trigger_all_cpu_backtrace+0x0/0x1f returned 0 after 0 use=
cs
calling  spawn_ksoftirqd+0x0/0x57 @ 1
initcall spawn_ksoftirqd+0x0/0x57 returned 0 after 0 usecs
calling  init_workqueues+0x0/0x2f5 @ 1
initcall init_workqueues+0x0/0x2f5 returned 0 after 0 usecs
calling  migration_init+0x0/0x71 @ 1
initcall migration_init+0x0/0x71 returned 0 after 0 usecs
calling  cpu_stop_init+0x0/0xb6 @ 1
initcall cpu_stop_init+0x0/0xb6 returned 0 after 0 usecs
calling  rcu_scheduler_really_started+0x0/0x12 @ 1
initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
calling  relay_init+0x0/0x14 @ 1
initcall relay_init+0x0/0x14 returned 0 after 0 usecs
calling  tracer_alloc_buffers+0x0/0x235 @ 1
initcall tracer_alloc_buffers+0x0/0x235 returned 0 after 0 usecs
calling  init_trace_printk+0x0/0x12 @ 1
initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
NMI watchdog: disabled (cpu0): hardware events not enabled
installing Xen timer for CPU 1
NMI watchdog: disabled (cpu1): hardware events not enabled
installing Xen timer for CPU 2
NMI watchdog: disabled (cpu2): hardware events not enabled
installing Xen timer for CPU 3
NMI watchdog: disabled (cpu3): hardware events not enabled
Brought up 4 CPUs
devtmpfs: initialized
calling  ipc_ns_init+0x0/0x14 @ 1
initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
calling  initea returned 0 after 0 usecs
calling  e820_mark_nvs_memory+0x0/0x41 @ 1
initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
calling  cpufreq_tsc+0x0/0x37 @ 1
initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
calling  pci_reboot_init+0x0/0x1d @ 1
initcall pci_reboot_init+0x0/0x1d returned 0 after 0 usecs
calling  init_lapic_sysfs+0x0/0x20 @ 1
initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
calling  init_smp_flush+0x0/0x38 @ 1
initcall init_smp_flush+0x0/0x38 returned 0 after 0 usecs
calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
calling  alloc_frozen_cpus+0x0/0x1e @ 1
initcall alloc_frozen_cpus+0x0/0x1e returned 0 after 0 usecs
calling  ksysfs_init+0x0/0x94 @ 1
initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
calling  pm_init+0x0/0x66 @ 1
initcall pm_init+0x0/0x66 returned 0 after 0 usecs
calling  pm_disk_init+0x0/0x19 @ 1
initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
calling  swsusp_header_init+0x0/0x40 @ 1
initcall swsusp_header_init+0x0/0x40 returned 0 after 0 usecs
calling  init_jiffies_clocksource+0x0/0x12 @ 1
initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
calling  init_ftrace_syscalls+0x0/0x77 @ 1
initcall init_ftrace_syscalls+0x0/0x77 returned 0 after 976 usecs
calling  init_zero_pfn+0x0/0x35 @ 1
initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
calling  memory_failure_init+0x0/0xa8 @ 1
initcall memory_failure_init+0x0/0xa8 returned 0 after 0 usecs
calling  fsnotify_init+0x0/0x26 @ 1
initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
calling  filelock_init+0x0/0x2a @ 1
initcall filelock_init+0x0/0x2a returned 0 after 0 usecs
calling  init_misc_binfmt+0x0/0x31 @ 1
initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
calling  init_script_binfmt+0x0/0x16 @ 1
initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
calling  init_elf_binfmt+0x0/0x16 @ 1
initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
calling  init_compat_elf_binfmt+0x0/0x16 @ 1
initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
calling  debugfs_init+0x0/0x5c @ 1
initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
calling  securityfs_init+0x0/0x53 @ 1
initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
calling  random32_init+0x0/0xdb @ 1
initcall random32_init+0x0/0xdb returned 0 after 0 usecs
calling  sfi_sysfs_init+0x0/0xdb @ 1
i usecs
calling  dma_bus_init+0x0/0x19 @ 1
initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
calling  dma_channel_table_init+0x0/0x119 @ 1
initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 0 usecs
calling  register_xen_pci_notifier+0x0/0x33 @ 1
initcall register_xen_pci_notifier+0x0/0x33 returned 0 after 0 usecs
calling  dmi_id_init+0x0/0xbe @ 1
initcall dmi_id_init+0x0/0xbe returned 0 after 0 usecs
calling  pci_arch_init+0x0/0x69 @ 1
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (b=
ase 0xe0000000)
PCI: Intel Corporation E7520 Memory Controller Hub with MMCONFIG support
PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
PCI: Using configuration type 1 for base access
initcall pci_arch_init+0x0/0x69 returned 0 after 76160 usecs
calling  topology_init+0x0/0xa1 @ 1
initcall topology_init+0x0/0xa1 returned 0 after 0 usecs
calling  mtrr_init_finialize+0x0/0x36 @ 1
initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
calling  init_vdso+0x0/0x135 @ 1
initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
calling  sysenter_setup+0x0/0xbc @ 1
initcall sysenter_setup+0x0/0xbc returned 0 after 0 usecs
calling  param_sysfs_init+0x0/0x150 @ 1
initcall param_sysfs_init+0x0/0x150 returned 0 after 976 usecs
calling  pm_sysrq_init+0x0/0x20 @ 1
initcall pm_sysrq_init+0x0/0x20 returned 0 after 0 usecs
calling  default_bdi_init+0x0/0xaa @ 1
initcall default_bdi_init+0x0/0xaa returned 0 after 0 usecs
calling  init_bio+0x0/0x10c @ 1
bio: create slab <bio-0> at 0
initcall init_bio+0x0/0x10c returned 0 after 976 usecs
calling  fsnotify_notification_init+0x0/0x8b @ 1
initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
calling  cryptomgr_init+0x0/0x12 @ 1
initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
calling  blk_settings_init+0x0/0x2c @ 1
initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
calling  blk_ioc_init+0x0/0x2a @ 1
initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
calling  blk_softirq_init+0x0/0x70 @ 1
initcall blk_softirq_init+0x0/0x70 returned 0 after 0 usecs
calling  blk_iopoll_setup+0x0/0x70 @ 1
initbridge window [mem 0xda4000000-0xde3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xd24000000-0xd63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xca4000000-0xce3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xc24000000-0xc63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xba4000000-0xbe3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xb24000000-0xb63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xaa4000000-0xae3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xa24000000-0xa63ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x9a4000000-0x9e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x924000000-0x963ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x8a4000000-0x8e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x824000000-0x863ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x7a4000000-0x7e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x724000000-0x763ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x6a4000000-0x6e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x624000000-0x663ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x5a4000000-0x5e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x524000000-0x563ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x4a4000000-0x4e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x424000000-0x463ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x3a4000000-0x3e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x324000000-0x363ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x2a4000000-0x2e3ffffff]
pci_root PNP0A08:00: host bridge window [mem 0x224000000-0x263ffffff]
pci_root PNP0A08:00: host bridge window [mem 0xd8000000-0xffffffff]
pci_root PNP0A08:00: host bridge window [mem 0x000c8000-0x000dffff]
pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bfffffff]
pci_bus 0000:00: root bus resource [mem 0x9a4000000-0x9e3ffffff]
0:03.0s 0000:00: root bus resource [mem 0x924000000-0x963ffffff]
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:08.0: [8086:359b] type 00 class 0x088000
pci 0000:00:1c.0: [8086:25ae] type 01 class 0x060400
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:00:1c.0
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:00:1c.0
pci 0000:00:1d.0: [8086:25a9] type 00 class 0x0c0300
pci 0000:00:1d.0: reg 20: [io  0x2200-0x221f]
pci 0000:00:1d.1: [8086:25aa] type 00 class 0x0c0300
pci 0000:00:1d.1: reg 20: [io  0x2600-0x261f]
pci 0000:00:1d.4: [8086:25ab] type 00 class 0x088000
pci 0000:00:1d.4: reg 10: [mem 0x00000000-0x0000000f]
pci 0000:00:1d.5: [8086:25ac] type 00 class 0x080020
pci 0000:00:1e.0: [8086:244e] type 01 class 0x060400
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:00:1e.0
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:00:1e.0
pci 0000:00:1f.0: [8086:25a1] type 00 class 0x060100
calling  old_ich_force_enable_hpet_user+0x0/0x30 @ 1 for 0000:00:1f.0
pci fixup old_ich_force_enable_hpet_user+0x0/0x30 returned after 0 usecs fo=
r 0000:00:1f.0
calling  quirk_ich4_lpc_acpi+0x0/0xbc @ 1 for 0000:00:1f.0
pci fixup quirk_ich4_lpc_acpi+0x0/0xbc returned after 0 usecs for 0000:00:1=
f.0
pci 0000:00:1f.1: [8086:25a2] type 00 class 0x01018a
pci 0000:00:1f.1: reg 10: [io  0x0000-0x0007]
pci 0000:00:1f.1: reg 14: [io  0x0000-0x0003]
pci 0000:00:1f.1: reg 18: [io  0x0000-0x0007]
pci 0000:00:1f.1: reg 1c: [io  0x0000-0x0003]
pci 0000:00:1f.1: reg 20: [io  0x0000-0x000f]
pci 0000:00:1f.1: reg 24: [mem 0x00000000-0x000003ff]
pci 0000:00:1f.3: [8086:25a4] type 00 class 0x0c0500
pci 0000:00:1f.3: reg 20: [io  0x0440-0x045f]
pci 0000:04:00.0: [8086:0329] type 01 class 0x060400
calling  quirk_pcie_pxh+0x0/0x31 @ 1 for 0000:04:00.0
pci 0000:04:00.0: PXH quirk detected; SHPC device MSI disabled
pci fixup quirk_pcie_pxh+0x0/0x31 returned after 976 usecs for 0000:04:00.0
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:04:00.0
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:04:00.0
pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
pci 0000:04:00.2: [8086:032a] type 01 class 0x060400
calling  quirk_pcie_pxh+0x0/0x31 @ 1 for 0000:04:00.2
pci 0000:04:00.2: PXH quirk detected; SHPC device MSI disabled
pci fixup quirk_pcie_pxh+0x0/0x31 returned after 976 usecs for 0000:04:00.2
calling  pci_fixup_transparent_bridge+0x0/0x1d @ 1 for 0000:04:00.2
pci fixup pci_fixup_transparent_bridge+0x0/0x1d returned after 0 usecs for =
0000:04:00.2
pci 0000:04:00.2: PME# supported from D0 D3hot D3cold
pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it=
 with 'pcie_aspm=3Dforce'
pci 0000:00:03.0: PCI bridge to [bus 04-06]
pci 0000:00:03.0:   bridge window [io  0x5000-0xffff]
pci 0000:00:03.0:   bridge window [mem 0xdb000000-0xdcffffff]
pci 0000:04:00.0: PCI bridge to [bus 06-06]
pci 0000:04:00.0:   bridge window [io  0x5000-0xffff]
pci 0000:05:01.0: [14e4:16tive decode)
pci 0000:00:1e.0:   bridge window [mem 0xd24000000-0xd63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xca4000000-0xce3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xc24000000-0xc63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xba4000000-0xbe3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xb24000000-0xb63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xaa4000000-0xae3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xa24000000-0xa63ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x9a4000000-0x9e3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x924000000-0x963ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x8a4000000-0x8e3ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x824000000-0x863ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0x7a40ow [mem 0x2a4000000-0x2e3fffff=
f] (subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x224000000-0x263ffffff] (subtractiv=
e decode)
pci 0000:00:1e.0:   bridge window [mem 0xd8000000-0xffffffff] (subtractive =
decode)
pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive =
decode)
pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1.PCI2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1.PCI3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIS._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIX._PRT]
 pci0000:00: Requesting ACPI _OSC control (0x1d)
 pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask=
: 0x1d
ACPI _OSC control for PCIe not granted, disabling ASPM
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:00.1
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:1c.0
(XEN) Platform timer appears to have unexpectedly wrapped 1 times.
(XEN) traps.c:486:d0 Unhandled nmi fault/trap [#2] on VCPU 0 [ec=3D0000]
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.4
(XEN) PCI add device 0000:00:1d.5
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.1
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:04:00.0
(XEN) PCI add device 0000:04:00.2
(XEN) PCI add device 0000:05:01.0
(XEN) PCI add device 0000:05:01.1
(XEN) PCI add device 0000:02:01.0
(XEN) PCI add device 0000:01:01.0
initcall acpi_pci_root_init+0x0/0x32 returned 0 after 226527 usecs
calling  acpi_pci_link_init+0x0/0x43 @ 1
ACPI: PCI Interrupt Link [LP00] (IRQs *10)
ACPI: PCI Interrupt Link [LP01] (IRQs *7)
ACPI: PCI Interrupt Link [LP02] (IRQs *5)
ACPI: PCI Interrupt Link [LP03] (IRQs *5)
ACPI: PCI Interrupt Link [LP04] (IRQs *10)
ACPI: PCI Interrupt Link [LP05] (IRQs) *0, disabled.
ACPI: PCI Interrupt Link [LP06] (IRQs *10)
ACPI: PCI Interrupt Link [LP07] (IRQs) *0, disabled.
initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
calling  pnp_init+0x0/0x19 @ 1
initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
calling  xen_setup_shutdown_event+0x0/0x30 @ 1
initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 0 usecs
calling  balloon_init+0x0/0x133 @ 1
xen/balloon: Initialising balloon driver.
initcall balloon_init+0x0/0x133 returned 0 after 0 usecs
calling  xenbus_probe_backend_init+0x0/0x5e @ 1
initcall xenbus_probe_backend_init+0x0/0x5e returned 0 after 0 usecs
calling  xenbus_probe_frontend_init+0x0/0x5e @ 1
initcall xenbus_probe_frontend_init+0x0/0x5e returned 0 after 0 usecs
calling  balloon_init+0x0/0x35 @ 1
xen-balloon: Initialising balloon driver.
initcall balloon_init+0x0/0x35 returned 0 after 0 usecs
calling  ab8500_regulator_init+0x0/0x31 @ 1
initcall ab8500_regulator_init+0x0/0x31 returned 0 after 0 usecs
calling  misc_init+0x0/0xba @ 1
initcall misc_init+0x0/0xba returned 0 after 0 usecs
calling  vga_arb_device_init+0x0/0xde @ 1
vgaarb: device added: PCI:0000:01:01.0,decodes=3Dio+mem,owns=3Dio+mem,locks=
=3Dnone
vgaarb: loaded
vgaarb: bridge control possible 0000:01:01.0
initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
calling  cn_init+0x0/0x9e @ 1
initcall cn_init+0x0/0x9e returned 0 after 0 usecs
calling  stmpe_init+0x0/0x14 @ 1
initcall stmpe_init+0x0/0x14 returned 0 after 0 usecs
calling  stmpe_init+0x0/0x12 @ 1
initcall stmpe_init+0x0/0x12 returned 0 after 0 usecs
calling  wm831x_spi_init+0x0/0x28 @ 1
initcall wm831x_spi_init+0x0/0x28 returned 0 after 0 usecs
calling  tps65912_spi_init+0x0/0x28 @ 1
initcall tps65912_spi_init+0x0/0x28 returned 0 after 0 usecs
calling  ezx_pcap_init+0x0/0x12 @ 1
initcall ezx_pcap_init+0x0/0x12 returned 0 after 0 usecs
calling  da9052_spi_init+0x0/0x31 @ 1
initcall da9052_spi_init+0x0/0x31 returned 0 after 0 usecs
calling  ab8500_sysctrl_init+0x0/0x12 @ 1
initcall ab8500_sysctrl_ini: Using ACPI for IRQ routing
PCI: pci_cache_line_size set to 64 bytes
reserve RAM buffer: 000000000009d000 - 000000000009ffff
reserve RAM buffer: 0000000010063000 - 0000000013ffffff
initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
calling  proto_init+0x0/0x12 @ 1
initcall proto_init+0x0/0x12 returned 0 after 0 usecs
calling  net_dev_init+0x0/0x1b3 @ 1
initcall net_dev_init+0x0/0x1b3 returned 0 after 0 usecs
calling  neigh_init+0x0/0x80 @ 1
initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
calling  fib_rules_init+0x0/0xaf @ 1
initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
calling  pktsched_init+0x0/0xfe @ 1
initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
calling  tc_filter_init+0x0/0x55 @ 1
initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
calling  tc_action_init+0x0/0x55 @ 1
initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
calling  genl_init+0x0/0x84 @ 1
initcall genl_init+0x0/0x84 returned 0 after 0 usecs
calling  cipso_v4_init+0x0/0x61 @ 1
initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
calling  wireless_nlevent_init+0x0/0x12 @ 1
initcall wireless_nlevent_init+0x0/0x12 returned 0 after 0 usecs
calling  netlbl_init+0x0/0x81 @ 1
NetLabel: Initializing
NetLabel:  domain hash size =3D 128
NetLabel:  protocols =3D UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
calling  net_sysctl_init+0x0/0x49 @ 1
initcall net_sysctl_init+0x0/0x49 returned 0 after 0 usecs
calling  nfc_init+0x0/0x9e @ 1
nfc: nfc_init: NFC Core ver 0.1
NET: Registered protocol family 39
initcall nfc_init+0x0/0x9e returned 0 after 0 usecs
calling  ab8500_gpadc_init+0x0/0x12 @ 1
initcall ab8500_gpadc_init+0x0/0x12 returned 0 after 0 usecs
calling  ab8500_charger_init+0x0/0x12 @ 1
initcall ab8500_charger_init+0x0/0x12 returned 0 after 0 usecs
calling  ab8500_btemp_init+0x0/0x12 @ 1
initcall ab8500_btemp_init+0x0/0x12 returned 0 after 0 usecs
calling  ab8500_fg_init+0x0/0x12 @ 1
initcall ab8500_fg_init+0x0/0x12 returned 0 after 0 usecs
calling  xen_p2m_debugfs+0x0/0x4a @ 1
initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
calling  hpet_late_init+0x0/0x103 @ 1
initcall hpet_late_init+0x0/0x103 returned -19 after 0 usecs
calling  init_amd_nbs+0x0/0x3f @ 1
initcall init_amd_nbs+0x0/0x3f returned 0 after 0 usecs
calling  clocksource_done_booting+0x0/0x5a @ 1
Switching to clocksource xen
initcall clocksource_done_booting+0x0/0x5a returned 0 after 8 usecs
calling  ftrace_init_debugfs+0x0/0xdx314 @ 1
initcall tracer_init_debugfs+0x0/0x314 returned 0 after 156 usecs
calling  init_trace_printk_function_export+0x0/0x2f @ 1
initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 5 usecs
calling  event_trace_init+0x0/0x1bb @ 1
initcall event_trace_init+0x0/0x1bb returned 0 after 13106 usecs
calling  init_kprobe_trace+0x0/0x93 @ 1
initcall init_kprobe_trace+0x0/0x93 returned 0 after 7 usecs
calling  init_pipe_fs+0x0/0x4c @ 1
initcall init_pipe_fs+0x0/0x4c returned 0 after 30 usecs
calling  eventpoll_init+0x0/0xda @ 1
initcall eventpoll_init+0x0/0xda returned 0 after 106 usecs
calling  anon_inode_init+0x0/0x5b @ 1
initcall anon_inode_init+0x0/0x5b returned 0 after 17 usecs
calling  tomoyo_initerface_init+0x0/0x17d @ 1
initcall tomoyo_initerface_init+0x0/0x17d returned 0 after 0 usecs
calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
calling  acpi_event_init+0x0/0x81 @ 1
initcall acpi_event_init+0x0/0x81 returned 0 after 18 usecs
calling  pnp_system_init+0x0/0x12 @ 1
initcall pnp_system_init+0x0/0x12 returned 0 after 24 usecs
calling  pnpacpi_init+0x0/0x8c @ 1
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp 00:00: [mem 0xf24000000-0xfffffffff window]
pnp 00:00: [mem 0xea4000000-0xee3ffffff window]
pnp 00:00: [mem 0xe24000000-0xe63ffffff window]
pnp 00:00: [mem 0xda4000000-0xde3ffffff window]
pnp 00:00: [mem 0xd24000000-0xd63ffffff window]
pnp 00:00: [mem 0xca4000000-0xce3ffffff window]
pnp 00:00: [mem 0xc24000000-0xc63ffffff window]
pnp 00:00: [mem 0xba4000000-0xbe3ffsign_resources+0x0/0xf8 @ 1
pci 0000:00:1c.0: BAR 15: assigned [mem 0xd8000000-0xd80fffff pref]
pci 0000:00:1f.1: BAR 5: assigned [mem 0xd8100000-0xd81003ff]
pci 0000:00:1d.4: BAR 0: assigned [mem 0xd8100400-0xd810040f]
pci 0000:00:1f.1: BAR 4: assigned [io  0x1000-0x100f]
pci 0000:04:00.0: PCI bridge to [bus 06-06]
pci 0000:04:00.0:   bridge window [io  0x5000-0xffff]
pci 0000:04:00.2: PCI bridge to [bus 05-05]
pci 0000:04:00.2:   bridge window [mem 0xdb000000-0xdcffffff]
pci 0000:00:03.0: PCI bridge to [bus 04-06]
pci 0000:00:03.0:   bridge window [io  0x5000-0xffff]
pci 0000:00:03.0:   bridge window [mem 0xdb000000-0xdcffffff]
pci 0000:02:01.0: BAR 6: assigned [mem 0xd8000000-0xd80fffff pref]
pci 0000:00:1c.0: PCI bridge to [bus 02-02]
pci 0000:00:1c.0:   bridge window [io  0x4000-0x4fff]
pci 0000:00:1c.0:   bridge window [mem 0xdd000000-0xdeffffff]
pci 0000:00:1c.0:   bridge window [mem 0xd8000000-0xd80fffff pref]
pci 0000:01:01.0: BAR 6: assigned [mem 0xf8020000-0xf803ffff pref]
pci 0000:00:1e.0: PCI bridge to [bus 01-01]
pci 0000:00:1e.0:   bridge window [io  0x3000-0x3fff]
pci 0000:00:1e.0:   bridge window [mem 0xf8000000-0xf8ffffff]
pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xf7ffffff pref]
xen: registering gsi 16 triggering 0 pole 0 [io  0x5000-0xffff]
pci_bus 0000:04: resource 1 [mem 0xdb000000-0xdcffffff]
pci_bus 0000:06: resource 0 [io  0x5000-0xffff]
pci_bus 0000:05: resource 1 [mem 0xdb000000-0xdcffffff]
pci_bus 0000:02: resource 0 [io  0x4000-0x4fff]
pci_bus 0000:02: resource 1 [mem 0xdd000000-0xdeffffff]
pci_bus 0000:02: resource 2 [mem 0xd8000000-0xd80fffff pref]
pci_bus 0000:01: resource 0 [io  0x3000-0x3fff]
pci_bus 0000:01: resource 1 [mem 0xf8000000-0xf8ffffff]
pci_bus 0000:01: resource 2 [mem 0xf0000000-0xf7ffffff pref]
pci_bus 0000:01: resource 4 [mem 0xf24000000-0xfffffffff]
pci_bus 0000:01: resource 5 [mem 0xea4000000-0xee3ffffff]
pci_bus 0000:01: resource 6 [mem 0xe24000000-0xe63ffffff]
pci_bus 0000:01: resource 7 [mem 0xda4000000-0xde3ffffff]
pci_bus 0000:01: resource 8 [mem 0xd24000000-0xd63ffffff]
pci_bus 0000:01: resource 9 [mem 0xca4000000-0xce3ffffff]
pci_bus 0000:01: resource 10 [mem 0xc24000000-0xc63ffffff]
pci_bus 0000:01: resource 11 [mem 0xba4000000-0xbe3ffffff]
pci_bus 0000:01: resource 12 [mem 0xb24000000-0xb63ffffff]
pci_bus 0000:01: resource 13 [mem 0xaa4000000-0xae3ffffff]
pci_bus 0000:01: resource 14 [mem 0xa24000000-0xa63ffffff]
pci_bus 0000:01: resource 15 [mem 0x9a4000000-0x9e3ffffff]
pci_bus 0000:01: resource 16 [mem 0x924000000-0x963ffffff]
pci_bus 0000:01: resource 17 [mem 0x8a4000000-0x8e3ffffff]
pci_bus 0000:01: resource 18 [mem 0x824000000-0x863ffffff]
pci_bus 0000:01: resource 19 [mem 0x7a4000000-0x7e3ffffff]
pci_bus 0000:01: resource 20 [mem 0x724000000-0x763ffffff]
pci_bus 0000:01: resource 21 [mem 0x6a4000000-0x6e3ffffff]
pci_bus 0000:01: resource 22 [mem 0x624000000-0x663ffffff]
pci_bus 0000:01: resource 23 [mem 0x5a4000000-0x5e3ffffff]
pci_bus 0000:01: resource 24 [mem 0x524000000-0x563ffffff]
pci_bus 0000:01: resource 25 [mem 0x4a4000000-0x4e3ffffff]
pci_bus 0000:0?[2J



-- Pasi


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

From xen-devel-bounces@lists.xen.org Tue Feb 05 21:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 21:19: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 1U2pv3-0001Pi-2o; Tue, 05 Feb 2013 21:19:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U2pv1-0001Pa-QD
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 21:19:08 +0000
Received: from [85.158.139.83:50818] by server-10.bemta-5.messagelabs.com id
	8B/6F-04697-A4771115; Tue, 05 Feb 2013 21:19:06 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360099145!31015579!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24027 invoked from network); 5 Feb 2013 21:19:05 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 21:19:05 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:52906 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 1U2q1D-0000Xf-8k; Tue, 05 Feb 2013 22:25:31 +0100
Date: Tue, 5 Feb 2013 22:19:01 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <165496354.20130205221901@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0CA0C92100D33383F"
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

------------0CA0C92100D33383F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jan,

Boot of xen-unstable is broken due to changeset 26517 on a AMD 890-FX motherboard.
The serial log is attached.

--
Sander
------------0CA0C92100D33383F
Content-Type: application/octet-stream;
 name="serial.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAg
IF8gICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyAvICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8v
IF8gXCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8
ICdfIFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxf
fCB8IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98
ICAgIHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxf
X198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3Rh
YmxlIChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVi
dWc9eSBUdWUgRmViICA1IDE5OjUyOjExIENFVCAyMDEzDQooWEVOKSBMYXRlc3QgQ2hhbmdl
U2V0OiBUdWUgRmViIDA1IDE1OjQ3OjQxIDIwMTMgKzAwMDAgMjY1MjA6NmMxYjEyYzg4NGI0
DQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1ZWV6ZTENCihY
RU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxvZ2x2bD1hbGwg
bG9nbHZsX2d1ZXN0PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0xMjgweDEwMjR4
MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGlj
X3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcsYW1k
LWlvbW11LWRlYnVnIGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZp
ZGVvIGluZm9ybWF0aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAy
NCwgMzIgYnBwDQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0
aW1lOiAxIHNlY29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQg
MiBNQlIgc2lnbmF0dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVj
dHVyZXMNCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAw
IC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAw
MCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAw
MDAgLSAwMDAwMDAwMGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAw
MCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjll
MDAwIC0gMDAwMDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZl
MDAwMCAtIDAwMDAwMDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZl
MDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAw
MDAwMDAwIC0gMDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAw
MDBGQjEwMCwgMDAxNCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwg
MDA0OCAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5
MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIx
ICBBNzY0MCBBNzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTog
RkFDUyBBRkY5RTAwMCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAo
cjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJ
OiBNQ0ZHIEFGRjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNG
VCAgICAgICA5NykNCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAg
ICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBB
RkY5RTA0MCwgMDA3MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAg
OTcpDQooWEVOKSBBQ1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0Zf
MTAgICAgICAgIDIgQU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAs
IDAwMzggKHIxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhF
TikgQUNQSTogSVZSUyBBRkY5QTczMCwgMDBGOCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAy
MDMxIEFNRCAgICAgICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChy
MSBBIE0gSSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3Rl
bSBSQU06IDgxOTFNQiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAw
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg
LT4gQVBJQyAzIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5v
ZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JB
VDogTm9kZSAwIFBYTSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAw
MDAtYjAwMDAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAw
MDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDhkMDAwMCAt
IDI0ZDhkMzAwMA0KKFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZl
ciBhdCAweGZiMDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2
MTQ0aywgdG90YWwgMTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMy
LCBsaW5lbGVuZ3RoPTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6
IHNpemU9ODo4Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFi
bGUgYXQgMDAwZmY3ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0
YXRlIGlzICd4YXBpYycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4p
IEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBBQ1BJIFNMRUVQ
IElORk86IHBtMXhfY250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdDQooWEVOKSBBQ1BJOiAg
ICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbYWZmOWUwMGNdLCB2ZWNfc2l6ZVsyMF0NCihY
RU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJv
Y2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMx
IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAz
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJ
QyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19p
ZFsweDAzXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBl
bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
KFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBJ
T0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVO
KSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAw
LCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVj
MjAwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4pIElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJz
aW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC01NQ0KKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4p
IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBs
ZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAyIEkvTyBB
UElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANCihY
RU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyA2IENQ
VXMgKDAgaG90cGx1ZyBDUFVzKQ0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZmZjgyYzNmZmRm
YjAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZmEw
MDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGY5MDAw
IChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgN
CihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkN
CihYRU4pIERldGVjdGVkIDMyMDAuMTk5IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5n
IG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9y
dGluZyBlbmFibGVkDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUw
MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE5vdCB1c2lu
ZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBBTUQtVmk6IEZvdW5k
IE1TSSBjYXBhYmlsaXR5IGJsb2NrIGF0IDB4NTQNCihYRU4pIEFNRC1WaTogQUNQSSBUYWJs
ZToNCihYRU4pIEFNRC1WaTogIFNpZ25hdHVyZSBJVlJTDQooWEVOKSBBTUQtVmk6ICBMZW5n
dGggMHhmOA0KKFhFTikgQU1ELVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBD
aGVja1N1bSAweDUwDQooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1W
aTogIE9FTV9UYWJsZV9JZCBSRDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAw
eDIwMjAzMQ0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6
ICBDcmVhdG9yX1JldmlzaW9uIDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikg
QU1ELVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTA4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTA4IC0+IDB4YWZmDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgQWxpYXM6IDB4YTAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDgwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHgzMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHg3MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4NTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDU4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDUwMCAtPiAweDUwMQ0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg0MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDk4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHhhMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhhMQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMg0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMw0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHg0Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgQWxpYXM6IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTUNCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4MTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweGIwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1W
aTogIERldl9JZCAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVuYWJsaW5nIHBlci1kZXZpY2Ug
dmVjdG9yIG1hcHMNCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkDQooWEVOKSAg
LSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTAN
CihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgSUQ6IDAN
CihYRU4pIEdldHRpbmcgTFZUMDogNzAwDQooWEVOKSBHZXR0aW5nIExWVDE6IDQwMA0KKFhF
TikgZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzANCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5h
YmxpbmcgdmVjdG9yOiAweDQgIGFmdGVyOiAwDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElS
UXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElD
IElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA2LTAtLS0tWyBYZW4tNC4zLXVu
c3RhYmxlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBDUFU6
ICAgIDANCihYRU4pIFJJUDogICAgZTAwODpbPGZmZmY4MmM0YzAxNGZhMWE+XSBhbWRfaW9t
bXVfaW9hcGljX3VwZGF0ZV9pcmUrMHgyNWUvMHg1NzQNCihYRU4pIFJGTEFHUzogMDAwMDAw
MDAwMDAxMDAxNiAgIENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4pIHJheDogMDAwMDAwMDAw
MDAwMDAwMSAgIHJieDogMDAwMDAwMDAwMDAwMDAxMyAgIHJjeDogMDAwMDAwMDAwMDAwMDA2
MA0KKFhFTikgcmR4OiAwMDAwMDAwMDAwMDAwMDAwICAgcnNpOiBmZmZmODJjM2ZmZmZmMDAw
ICAgcmRpOiBmZmZmODJjNGMwMmU4MDI4DQooWEVOKSByYnA6IGZmZmY4MmM0YzAyYmZjZjgg
ICByc3A6IGZmZmY4MmM0YzAyYmZjMzggICByODogIDAwMDAwMDAwMDAwMDAwMDENCihYRU4p
IHI5OiAgZmZmZjgyYzRjMDI1ZmYyMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwZiAgIHIxMTog
MDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgcjEyOiAwMDAwMDAwMDAwMDAwMDAwICAgcjEzOiAw
MDAwMDAwMDAxMDAwMDAwICAgcjE0OiAwMDAwMDAwMDAwMDAwMDEyDQooWEVOKSByMTU6IGZm
ZmY4MzAyNGQ4YjVkODAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAw
MDAwMDA2ZjANCihYRU4pIGNyMzogMDAwMDAwMDBhZmM3MDAwMCAgIGNyMjogMDAwMDAwMDAw
MDAwMDAwMA0KKFhFTikgZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAw
MDAgICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBYZW4gc3RhY2sgdHJhY2UgZnJvbSBy
c3A9ZmZmZjgyYzRjMDJiZmMzODoNCihYRU4pICAgIGZmZmY4MmM0YzAyYmZkNDggMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMTINCihYRU4pICAg
IGZmZmY4MmM0YzAyYmZjNzggZmZmZjgyYzQwMTE2ODBjMyAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAxYzAyYmZjYzgNCihYRU4pICAgIGZmZmY4MmM0YzAyYmZjYjggZmZmZjgyYzRjMDE2
OGJkNCBmZmZmODJjNGMwMjc2NmU4IGZmZmY4MzAyMDAwMDAwMDANCihYRU4pICAgIDAwMDAw
MDEzMDAwMDAwMDEgMDAwMDAwMDAwMDIwNTAwMCAwMTAwMDAwMDAwMDEwMDAwIGZmZmY4MmM0
MDAwMDAwMzANCihYRU4pICAgIDAwMDAwMDAwMDAwMTAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDENCihYRU4pICAgIDAxMDAwMDAwMDAw
MDA5MzAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODJjNGMwMTYyNTg0IDAwMDAwMDAwMDAwMDAw
MDANCihYRU4pICAgIGZmZmY4MmM0YzAyYmZkMDggZmZmZjgyYzRjMDE0MTQ4NyBmZmZmODJj
NGMwMmJmZDE4IGZmZmY4MmM0YzAxNjI1OWINCihYRU4pICAgIGZmZmY4MmM0YzAyYmZkNDgg
ZmZmZjgyYzRjMDE2MTk1MSAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAwMDAwMDINCihY
RU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgyYzRjMDI1Y2YyMCBmZmZmODJjNGMwMmJm
ZTI4IGZmZmY4MmM0YzAyOTIxNzQNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgy
YzRjMDI1Y2YyMCBmZmZmODJjNGMwMjVjZjIwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAg
IDAwMDAwMDAxMDAwMDAwMDAgZmZmZjgyYzRjMDJiZmRlOCAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmY4MmM0MDAwMDAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAw
MDAwMSAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIGZmZmY4
MzAyNGQ4YzgwODAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwZjANCihYRU4pICAgIGZmZmY4MmMzZmZkZmIwMDAgMDAwMDAwMDBmZmZmZmZmZiAw
MTAwMDAwMDAwMDAwOTMwIGZmZmY4MmM0YzAxNTU0YzMNCihYRU4pICAgIGZmZmY4MzAyNGQ4
Y2NmZTAgZmZmZjgyYzRjMDMxMWQ0MCBmZmZmODMwMDAwMDhlZmIwIGZmZmY4MzAyNGQ4Y2Nm
ZTANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDIgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODJj
NGMwMmJmZTQ4IGZmZmY4MmM0YzAyOTk4ZjENCihYRU4pICAgIGZmZmY4MmM0YzAyYjgwMDAg
ZmZmZjgyYzRjMDJiODAwMCBmZmZmODJjNGMwMmJmZjA4IGZmZmY4MmM0YzAyOThkNDYNCihY
RU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwMDAwMDhl
YzUwIDAwMDAwMDAwMDEzYmQwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgy
YzRjMDJmOGQxNCBmZmZmODMwMDAwMDhlZmIwIDAwMDAwMDAwZmZmZmZmZmYNCihYRU4pICAg
IGZmZmY4MzAwMDAwMDAwMDUgZmZmZjgzMDAwMDA4ZWU5MCBmZmZmODMwMDAwMDhlZmIwIGZm
ZmY4MmM0ZmZmZmZmZmYNCihYRU4pIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikgICAgWzxmZmZm
ODJjNGMwMTRmYTFhPl0gYW1kX2lvbW11X2lvYXBpY191cGRhdGVfaXJlKzB4MjVlLzB4NTc0
DQooWEVOKSAgICBbPGZmZmY4MmM0YzAxNDE0ODc+XSBpb21tdV91cGRhdGVfaXJlX2Zyb21f
YXBpYysweDM0LzB4MzYNCihYRU4pICAgIFs8ZmZmZjgyYzRjMDE2MjU5Yj5dIGlvX2FwaWNf
d3JpdGUrMHgxNy8weDZkDQooWEVOKSAgICBbPGZmZmY4MmM0YzAxNjE5NTE+XSBfX2lvYXBp
Y193cml0ZV9lbnRyeSsweDQ1LzB4NjcNCihYRU4pICAgIFs8ZmZmZjgyYzRjMDI5MjE3ND5d
IHNldHVwX0lPX0FQSUMrMHhhNzYvMHgxMjIzDQooWEVOKSAgICBbPGZmZmY4MmM0YzAyOTk4
ZjE+XSBzbXBfcHJlcGFyZV9jcHVzKzB4MWMwLzB4MWNmDQooWEVOKSAgICBbPGZmZmY4MmM0
YzAyOThkNDY+XSBfX3N0YXJ0X3hlbisweDI4MDcvMHgyYzJiDQooWEVOKSAgICANCihYRU4p
IFBhZ2V0YWJsZSB3YWxrIGZyb20gMDAwMDAwMDAwMDAwMDAwMDoNCihYRU4pICBMNFsweDAw
MF0gPSAwMDAwMDAwMjRkOGJjMDYzIGZmZmZmZmZmZmZmZmZmZmYNCihYRU4pICBMM1sweDAw
MF0gPSAwMDAwMDAwMjRkOGJiMDYzIGZmZmZmZmZmZmZmZmZmZmYNCihYRU4pICBMMlsweDAw
MF0gPSAwMDAwMDAwMjRkOGJhMDYzIGZmZmZmZmZmZmZmZmZmZmYgDQooWEVOKSAgTDFbMHgw
MDBdID0gMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSANCihYRU4p
ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCihYRU4pIFBhbmlj
IG9uIENQVSAwOg0KKFhFTikgRkFUQUwgUEFHRSBGQVVMVA0KKFhFTikgW2Vycm9yX2NvZGU9
MDAwMF0NCihYRU4pIEZhdWx0aW5nIGxpbmVhciBhZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
DQooWEVOKSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVO
KSANCihYRU4pIE1hbnVhbCByZXNldCByZXF1aXJlZCAoJ25vcmVib290JyBzcGVjaWZpZWQp
DQo=
------------0CA0C92100D33383F
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0CA0C92100D33383F--



From xen-devel-bounces@lists.xen.org Tue Feb 05 21:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 21:19: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 1U2pv3-0001Pi-2o; Tue, 05 Feb 2013 21:19:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U2pv1-0001Pa-QD
	for xen-devel@lists.xensource.com; Tue, 05 Feb 2013 21:19:08 +0000
Received: from [85.158.139.83:50818] by server-10.bemta-5.messagelabs.com id
	8B/6F-04697-A4771115; Tue, 05 Feb 2013 21:19:06 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360099145!31015579!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24027 invoked from network); 5 Feb 2013 21:19:05 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Feb 2013 21:19:05 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:52906 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 1U2q1D-0000Xf-8k; Tue, 05 Feb 2013 22:25:31 +0100
Date: Tue, 5 Feb 2013 22:19:01 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <165496354.20130205221901@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0CA0C92100D33383F"
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

------------0CA0C92100D33383F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jan,

Boot of xen-unstable is broken due to changeset 26517 on a AMD 890-FX motherboard.
The serial log is attached.

--
Sander
------------0CA0C92100D33383F
Content-Type: application/octet-stream;
 name="serial.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAg
IF8gICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyAvICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8v
IF8gXCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8
ICdfIFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxf
fCB8IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98
ICAgIHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxf
X198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3Rh
YmxlIChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVi
dWc9eSBUdWUgRmViICA1IDE5OjUyOjExIENFVCAyMDEzDQooWEVOKSBMYXRlc3QgQ2hhbmdl
U2V0OiBUdWUgRmViIDA1IDE1OjQ3OjQxIDIwMTMgKzAwMDAgMjY1MjA6NmMxYjEyYzg4NGI0
DQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1ZWV6ZTENCihY
RU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxvZ2x2bD1hbGwg
bG9nbHZsX2d1ZXN0PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0xMjgweDEwMjR4
MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGlj
X3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcsYW1k
LWlvbW11LWRlYnVnIGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZp
ZGVvIGluZm9ybWF0aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAy
NCwgMzIgYnBwDQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0
aW1lOiAxIHNlY29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQg
MiBNQlIgc2lnbmF0dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVj
dHVyZXMNCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAw
IC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAw
MCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAw
MDAgLSAwMDAwMDAwMGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAw
MCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjll
MDAwIC0gMDAwMDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZl
MDAwMCAtIDAwMDAwMDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZl
MDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAw
MDAwMDAwIC0gMDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAw
MDBGQjEwMCwgMDAxNCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwg
MDA0OCAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5
MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIx
ICBBNzY0MCBBNzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTog
RkFDUyBBRkY5RTAwMCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAo
cjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJ
OiBNQ0ZHIEFGRjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNG
VCAgICAgICA5NykNCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAg
ICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBB
RkY5RTA0MCwgMDA3MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAg
OTcpDQooWEVOKSBBQ1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0Zf
MTAgICAgICAgIDIgQU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAs
IDAwMzggKHIxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhF
TikgQUNQSTogSVZSUyBBRkY5QTczMCwgMDBGOCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAy
MDMxIEFNRCAgICAgICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChy
MSBBIE0gSSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3Rl
bSBSQU06IDgxOTFNQiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAw
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg
LT4gQVBJQyAzIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5v
ZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JB
VDogTm9kZSAwIFBYTSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAw
MDAtYjAwMDAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAw
MDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDhkMDAwMCAt
IDI0ZDhkMzAwMA0KKFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZl
ciBhdCAweGZiMDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2
MTQ0aywgdG90YWwgMTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMy
LCBsaW5lbGVuZ3RoPTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6
IHNpemU9ODo4Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFi
bGUgYXQgMDAwZmY3ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0
YXRlIGlzICd4YXBpYycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4p
IEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBBQ1BJIFNMRUVQ
IElORk86IHBtMXhfY250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdDQooWEVOKSBBQ1BJOiAg
ICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbYWZmOWUwMGNdLCB2ZWNfc2l6ZVsyMF0NCihY
RU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJv
Y2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMx
IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAz
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJ
QyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19p
ZFsweDAzXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBl
bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
KFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBJ
T0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVO
KSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAw
LCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVj
MjAwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4pIElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJz
aW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC01NQ0KKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4p
IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBs
ZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAyIEkvTyBB
UElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANCihY
RU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyA2IENQ
VXMgKDAgaG90cGx1ZyBDUFVzKQ0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZmZjgyYzNmZmRm
YjAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZmEw
MDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGY5MDAw
IChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgN
CihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkN
CihYRU4pIERldGVjdGVkIDMyMDAuMTk5IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5n
IG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9y
dGluZyBlbmFibGVkDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUw
MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE5vdCB1c2lu
ZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBBTUQtVmk6IEZvdW5k
IE1TSSBjYXBhYmlsaXR5IGJsb2NrIGF0IDB4NTQNCihYRU4pIEFNRC1WaTogQUNQSSBUYWJs
ZToNCihYRU4pIEFNRC1WaTogIFNpZ25hdHVyZSBJVlJTDQooWEVOKSBBTUQtVmk6ICBMZW5n
dGggMHhmOA0KKFhFTikgQU1ELVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBD
aGVja1N1bSAweDUwDQooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1W
aTogIE9FTV9UYWJsZV9JZCBSRDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAw
eDIwMjAzMQ0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6
ICBDcmVhdG9yX1JldmlzaW9uIDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikg
QU1ELVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTA4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTA4IC0+IDB4YWZmDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgQWxpYXM6IDB4YTAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDgwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHgzMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHg3MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4NTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDU4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDUwMCAtPiAweDUwMQ0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg0MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDk4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHhhMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhhMQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMg0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMw0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHg0Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgQWxpYXM6IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTUNCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4MTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweGIwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1W
aTogIERldl9JZCAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVuYWJsaW5nIHBlci1kZXZpY2Ug
dmVjdG9yIG1hcHMNCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkDQooWEVOKSAg
LSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTAN
CihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgSUQ6IDAN
CihYRU4pIEdldHRpbmcgTFZUMDogNzAwDQooWEVOKSBHZXR0aW5nIExWVDE6IDQwMA0KKFhF
TikgZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzANCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5h
YmxpbmcgdmVjdG9yOiAweDQgIGFmdGVyOiAwDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElS
UXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElD
IElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA2LTAtLS0tWyBYZW4tNC4zLXVu
c3RhYmxlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBDUFU6
ICAgIDANCihYRU4pIFJJUDogICAgZTAwODpbPGZmZmY4MmM0YzAxNGZhMWE+XSBhbWRfaW9t
bXVfaW9hcGljX3VwZGF0ZV9pcmUrMHgyNWUvMHg1NzQNCihYRU4pIFJGTEFHUzogMDAwMDAw
MDAwMDAxMDAxNiAgIENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4pIHJheDogMDAwMDAwMDAw
MDAwMDAwMSAgIHJieDogMDAwMDAwMDAwMDAwMDAxMyAgIHJjeDogMDAwMDAwMDAwMDAwMDA2
MA0KKFhFTikgcmR4OiAwMDAwMDAwMDAwMDAwMDAwICAgcnNpOiBmZmZmODJjM2ZmZmZmMDAw
ICAgcmRpOiBmZmZmODJjNGMwMmU4MDI4DQooWEVOKSByYnA6IGZmZmY4MmM0YzAyYmZjZjgg
ICByc3A6IGZmZmY4MmM0YzAyYmZjMzggICByODogIDAwMDAwMDAwMDAwMDAwMDENCihYRU4p
IHI5OiAgZmZmZjgyYzRjMDI1ZmYyMCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwZiAgIHIxMTog
MDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgcjEyOiAwMDAwMDAwMDAwMDAwMDAwICAgcjEzOiAw
MDAwMDAwMDAxMDAwMDAwICAgcjE0OiAwMDAwMDAwMDAwMDAwMDEyDQooWEVOKSByMTU6IGZm
ZmY4MzAyNGQ4YjVkODAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAw
MDAwMDA2ZjANCihYRU4pIGNyMzogMDAwMDAwMDBhZmM3MDAwMCAgIGNyMjogMDAwMDAwMDAw
MDAwMDAwMA0KKFhFTikgZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAw
MDAgICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBYZW4gc3RhY2sgdHJhY2UgZnJvbSBy
c3A9ZmZmZjgyYzRjMDJiZmMzODoNCihYRU4pICAgIGZmZmY4MmM0YzAyYmZkNDggMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMTINCihYRU4pICAg
IGZmZmY4MmM0YzAyYmZjNzggZmZmZjgyYzQwMTE2ODBjMyAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAxYzAyYmZjYzgNCihYRU4pICAgIGZmZmY4MmM0YzAyYmZjYjggZmZmZjgyYzRjMDE2
OGJkNCBmZmZmODJjNGMwMjc2NmU4IGZmZmY4MzAyMDAwMDAwMDANCihYRU4pICAgIDAwMDAw
MDEzMDAwMDAwMDEgMDAwMDAwMDAwMDIwNTAwMCAwMTAwMDAwMDAwMDEwMDAwIGZmZmY4MmM0
MDAwMDAwMzANCihYRU4pICAgIDAwMDAwMDAwMDAwMTAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAxIDAwMDAwMDAwMDAwMDAwMDENCihYRU4pICAgIDAxMDAwMDAwMDAw
MDA5MzAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODJjNGMwMTYyNTg0IDAwMDAwMDAwMDAwMDAw
MDANCihYRU4pICAgIGZmZmY4MmM0YzAyYmZkMDggZmZmZjgyYzRjMDE0MTQ4NyBmZmZmODJj
NGMwMmJmZDE4IGZmZmY4MmM0YzAxNjI1OWINCihYRU4pICAgIGZmZmY4MmM0YzAyYmZkNDgg
ZmZmZjgyYzRjMDE2MTk1MSAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAwMDAwMDINCihY
RU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgyYzRjMDI1Y2YyMCBmZmZmODJjNGMwMmJm
ZTI4IGZmZmY4MmM0YzAyOTIxNzQNCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgy
YzRjMDI1Y2YyMCBmZmZmODJjNGMwMjVjZjIwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAg
IDAwMDAwMDAxMDAwMDAwMDAgZmZmZjgyYzRjMDJiZmRlOCAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmY4MmM0MDAwMDAwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAw
MDAwMSAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pICAgIGZmZmY4
MzAyNGQ4YzgwODAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwZjANCihYRU4pICAgIGZmZmY4MmMzZmZkZmIwMDAgMDAwMDAwMDBmZmZmZmZmZiAw
MTAwMDAwMDAwMDAwOTMwIGZmZmY4MmM0YzAxNTU0YzMNCihYRU4pICAgIGZmZmY4MzAyNGQ4
Y2NmZTAgZmZmZjgyYzRjMDMxMWQ0MCBmZmZmODMwMDAwMDhlZmIwIGZmZmY4MzAyNGQ4Y2Nm
ZTANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDIgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODJj
NGMwMmJmZTQ4IGZmZmY4MmM0YzAyOTk4ZjENCihYRU4pICAgIGZmZmY4MmM0YzAyYjgwMDAg
ZmZmZjgyYzRjMDJiODAwMCBmZmZmODJjNGMwMmJmZjA4IGZmZmY4MmM0YzAyOThkNDYNCihY
RU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwMDAwMDhl
YzUwIDAwMDAwMDAwMDEzYmQwMDANCihYRU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgy
YzRjMDJmOGQxNCBmZmZmODMwMDAwMDhlZmIwIDAwMDAwMDAwZmZmZmZmZmYNCihYRU4pICAg
IGZmZmY4MzAwMDAwMDAwMDUgZmZmZjgzMDAwMDA4ZWU5MCBmZmZmODMwMDAwMDhlZmIwIGZm
ZmY4MmM0ZmZmZmZmZmYNCihYRU4pIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikgICAgWzxmZmZm
ODJjNGMwMTRmYTFhPl0gYW1kX2lvbW11X2lvYXBpY191cGRhdGVfaXJlKzB4MjVlLzB4NTc0
DQooWEVOKSAgICBbPGZmZmY4MmM0YzAxNDE0ODc+XSBpb21tdV91cGRhdGVfaXJlX2Zyb21f
YXBpYysweDM0LzB4MzYNCihYRU4pICAgIFs8ZmZmZjgyYzRjMDE2MjU5Yj5dIGlvX2FwaWNf
d3JpdGUrMHgxNy8weDZkDQooWEVOKSAgICBbPGZmZmY4MmM0YzAxNjE5NTE+XSBfX2lvYXBp
Y193cml0ZV9lbnRyeSsweDQ1LzB4NjcNCihYRU4pICAgIFs8ZmZmZjgyYzRjMDI5MjE3ND5d
IHNldHVwX0lPX0FQSUMrMHhhNzYvMHgxMjIzDQooWEVOKSAgICBbPGZmZmY4MmM0YzAyOTk4
ZjE+XSBzbXBfcHJlcGFyZV9jcHVzKzB4MWMwLzB4MWNmDQooWEVOKSAgICBbPGZmZmY4MmM0
YzAyOThkNDY+XSBfX3N0YXJ0X3hlbisweDI4MDcvMHgyYzJiDQooWEVOKSAgICANCihYRU4p
IFBhZ2V0YWJsZSB3YWxrIGZyb20gMDAwMDAwMDAwMDAwMDAwMDoNCihYRU4pICBMNFsweDAw
MF0gPSAwMDAwMDAwMjRkOGJjMDYzIGZmZmZmZmZmZmZmZmZmZmYNCihYRU4pICBMM1sweDAw
MF0gPSAwMDAwMDAwMjRkOGJiMDYzIGZmZmZmZmZmZmZmZmZmZmYNCihYRU4pICBMMlsweDAw
MF0gPSAwMDAwMDAwMjRkOGJhMDYzIGZmZmZmZmZmZmZmZmZmZmYgDQooWEVOKSAgTDFbMHgw
MDBdID0gMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSANCihYRU4p
ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCihYRU4pIFBhbmlj
IG9uIENQVSAwOg0KKFhFTikgRkFUQUwgUEFHRSBGQVVMVA0KKFhFTikgW2Vycm9yX2NvZGU9
MDAwMF0NCihYRU4pIEZhdWx0aW5nIGxpbmVhciBhZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
DQooWEVOKSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVO
KSANCihYRU4pIE1hbnVhbCByZXNldCByZXF1aXJlZCAoJ25vcmVib290JyBzcGVjaWZpZWQp
DQo=
------------0CA0C92100D33383F
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0CA0C92100D33383F--



From xen-devel-bounces@lists.xen.org Tue Feb 05 22:08:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 22: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 1U2qgM-0002bI-CJ; Tue, 05 Feb 2013 22:08:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herton.krzesinski@canonical.com>) id 1U2qgK-0002bD-LX
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 22:08:00 +0000
Received: from [85.158.143.99:57746] by server-2.bemta-4.messagelabs.com id
	8D/58-01597-0C281115; Tue, 05 Feb 2013 22:08:00 +0000
X-Env-Sender: herton.krzesinski@canonical.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360102078!25057502!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1711 invoked from network); 5 Feb 2013 22:07:58 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-216.messagelabs.com with SMTP;
	5 Feb 2013 22:07:58 -0000
Received: from 189.58.24.194.dynamic.adsl.gvt.net.br ([189.58.24.194]
	helo=canonical.com) by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <herton.krzesinski@canonical.com>)
	id 1U2qgD-0003aH-Pm; Tue, 05 Feb 2013 22:07:55 +0000
From: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	kernel-team@lists.ubuntu.com
Date: Tue,  5 Feb 2013 20:05:55 -0200
Message-Id: <1360102042-10732-7-git-send-email-herton.krzesinski@canonical.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360102042-10732-1-git-send-email-herton.krzesinski@canonical.com>
References: <1360102042-10732-1-git-send-email-herton.krzesinski@canonical.com>
X-Extended-Stable: 3.5
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>,
	Annie Li <annie.li@oracle.com>, xen-devel@lists.xen.org,
	Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 06/93] xen/grant-table: correctly initialize
	grant table version 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>
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

3.5.7.5 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Matt Wilson <msw@amazon.com>

commit d0b4d64aadb9f4a90669848de9ef3819050a98cd upstream.

Commit 85ff6acb075a484780b3d763fdf41596d8fc0970 (xen/granttable: Grant
tables V2 implementation) changed the GREFS_PER_GRANT_FRAME macro from
a constant to a conditional expression. The expression depends on
grant_table_version being appropriately set. Unfortunately, at init
time grant_table_version will be 0. The GREFS_PER_GRANT_FRAME
conditional expression checks for "grant_table_version == 1", and
therefore returns the number of grant references per frame for v2.

This causes gnttab_init() to allocate fewer pages for gnttab_list, as
a frame can old half the number of v2 entries than v1 entries. After
gnttab_resume() is called, grant_table_version is appropriately
set. nr_init_grefs will then be miscalculated and gnttab_free_count
will hold a value larger than the actual number of free gref entries.

If a guest is heavily utilizing improperly initialized v1 grant
tables, memory corruption can occur. One common manifestation is
corruption of the vmalloc list, resulting in a poisoned pointer
derefrence when accessing /proc/meminfo or /proc/vmallocinfo:

[   40.770064] BUG: unable to handle kernel paging request at 0000200200001407
[   40.770083] IP: [<ffffffff811a6fb0>] get_vmalloc_info+0x70/0x110
[   40.770102] PGD 0
[   40.770107] Oops: 0000 [#1] SMP
[   40.770114] CPU 10

This patch introduces a static variable, grefs_per_grant_frame, to
cache the calculated value. gnttab_init() now calls
gnttab_request_version() early so that grant_table_version and
grefs_per_grant_frame can be appropriately set. A few BUG_ON()s have
been added to prevent this type of bug from reoccurring in the future.

Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-and-Tested-by: Steven Noonan <snoonan@amazon.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Annie Li <annie.li@oracle.com>
Cc: xen-devel@lists.xen.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
---
 drivers/xen/grant-table.c |   48 +++++++++++++++++++++++++++------------------
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0067266..22be735 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -54,10 +54,6 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME \
-(grant_table_version == 1 ?                      \
-(PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
-(PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -152,6 +148,7 @@ static struct gnttab_ops *gnttab_interface;
 static grant_status_t *grstatus;
 
 static int grant_table_version;
+static int grefs_per_grant_frame;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
 
@@ -766,12 +763,14 @@ static int grow_gnttab_list(unsigned int more_frames)
 	unsigned int new_nr_grant_frames, extra_entries, i;
 	unsigned int nr_glist_frames, new_nr_glist_frames;
 
+	BUG_ON(grefs_per_grant_frame == 0);
+
 	new_nr_grant_frames = nr_grant_frames + more_frames;
-	extra_entries       = more_frames * GREFS_PER_GRANT_FRAME;
+	extra_entries       = more_frames * grefs_per_grant_frame;
 
-	nr_glist_frames = (nr_grant_frames * GREFS_PER_GRANT_FRAME + RPP - 1) / RPP;
+	nr_glist_frames = (nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
 	new_nr_glist_frames =
-		(new_nr_grant_frames * GREFS_PER_GRANT_FRAME + RPP - 1) / RPP;
+		(new_nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
 	for (i = nr_glist_frames; i < new_nr_glist_frames; i++) {
 		gnttab_list[i] = (grant_ref_t *)__get_free_page(GFP_ATOMIC);
 		if (!gnttab_list[i])
@@ -779,12 +778,12 @@ static int grow_gnttab_list(unsigned int more_frames)
 	}
 
 
-	for (i = GREFS_PER_GRANT_FRAME * nr_grant_frames;
-	     i < GREFS_PER_GRANT_FRAME * new_nr_grant_frames - 1; i++)
+	for (i = grefs_per_grant_frame * nr_grant_frames;
+	     i < grefs_per_grant_frame * new_nr_grant_frames - 1; i++)
 		gnttab_entry(i) = i + 1;
 
 	gnttab_entry(i) = gnttab_free_head;
-	gnttab_free_head = GREFS_PER_GRANT_FRAME * nr_grant_frames;
+	gnttab_free_head = grefs_per_grant_frame * nr_grant_frames;
 	gnttab_free_count += extra_entries;
 
 	nr_grant_frames = new_nr_grant_frames;
@@ -904,7 +903,8 @@ EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
 static unsigned nr_status_frames(unsigned nr_grant_frames)
 {
-	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+	BUG_ON(grefs_per_grant_frame == 0);
+	return (nr_grant_frames * grefs_per_grant_frame + SPP - 1) / SPP;
 }
 
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
@@ -1062,6 +1062,7 @@ static void gnttab_request_version(void)
 	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
 	if (rc == 0 && gsv.version == 2) {
 		grant_table_version = 2;
+		grefs_per_grant_frame = PAGE_SIZE / sizeof(union grant_entry_v2);
 		gnttab_interface = &gnttab_v2_ops;
 	} else if (grant_table_version == 2) {
 		/*
@@ -1074,17 +1075,17 @@ static void gnttab_request_version(void)
 		panic("we need grant tables version 2, but only version 1 is available");
 	} else {
 		grant_table_version = 1;
+		grefs_per_grant_frame = PAGE_SIZE / sizeof(struct grant_entry_v1);
 		gnttab_interface = &gnttab_v1_ops;
 	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
 
-int gnttab_resume(void)
+static int gnttab_setup(void)
 {
 	unsigned int max_nr_gframes;
 
-	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
@@ -1107,6 +1108,12 @@ int gnttab_resume(void)
 	return 0;
 }
 
+int gnttab_resume(void)
+{
+	gnttab_request_version();
+	return gnttab_setup();
+}
+
 int gnttab_suspend(void)
 {
 	gnttab_interface->unmap_frames();
@@ -1118,9 +1125,10 @@ static int gnttab_expand(unsigned int req_entries)
 	int rc;
 	unsigned int cur, extra;
 
+	BUG_ON(grefs_per_grant_frame == 0);
 	cur = nr_grant_frames;
-	extra = ((req_entries + (GREFS_PER_GRANT_FRAME-1)) /
-		 GREFS_PER_GRANT_FRAME);
+	extra = ((req_entries + (grefs_per_grant_frame-1)) /
+		 grefs_per_grant_frame);
 	if (cur + extra > gnttab_max_grant_frames())
 		return -ENOSPC;
 
@@ -1138,21 +1146,23 @@ int gnttab_init(void)
 	unsigned int nr_init_grefs;
 	int ret;
 
+	gnttab_request_version();
 	nr_grant_frames = 1;
 	boot_max_nr_grant_frames = __max_nr_grant_frames();
 
 	/* Determine the maximum number of frames required for the
 	 * grant reference free list on the current hypervisor.
 	 */
+	BUG_ON(grefs_per_grant_frame == 0);
 	max_nr_glist_frames = (boot_max_nr_grant_frames *
-			       GREFS_PER_GRANT_FRAME / RPP);
+			       grefs_per_grant_frame / RPP);
 
 	gnttab_list = kmalloc(max_nr_glist_frames * sizeof(grant_ref_t *),
 			      GFP_KERNEL);
 	if (gnttab_list == NULL)
 		return -ENOMEM;
 
-	nr_glist_frames = (nr_grant_frames * GREFS_PER_GRANT_FRAME + RPP - 1) / RPP;
+	nr_glist_frames = (nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
 	for (i = 0; i < nr_glist_frames; i++) {
 		gnttab_list[i] = (grant_ref_t *)__get_free_page(GFP_KERNEL);
 		if (gnttab_list[i] == NULL) {
@@ -1161,12 +1171,12 @@ int gnttab_init(void)
 		}
 	}
 
-	if (gnttab_resume() < 0) {
+	if (gnttab_setup() < 0) {
 		ret = -ENODEV;
 		goto ini_nomem;
 	}
 
-	nr_init_grefs = nr_grant_frames * GREFS_PER_GRANT_FRAME;
+	nr_init_grefs = nr_grant_frames * grefs_per_grant_frame;
 
 	for (i = NR_RESERVED_ENTRIES; i < nr_init_grefs - 1; i++)
 		gnttab_entry(i) = i + 1;
-- 
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 Tue Feb 05 22:08:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 22: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 1U2qgM-0002bI-CJ; Tue, 05 Feb 2013 22:08:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herton.krzesinski@canonical.com>) id 1U2qgK-0002bD-LX
	for xen-devel@lists.xen.org; Tue, 05 Feb 2013 22:08:00 +0000
Received: from [85.158.143.99:57746] by server-2.bemta-4.messagelabs.com id
	8D/58-01597-0C281115; Tue, 05 Feb 2013 22:08:00 +0000
X-Env-Sender: herton.krzesinski@canonical.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360102078!25057502!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1711 invoked from network); 5 Feb 2013 22:07:58 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-216.messagelabs.com with SMTP;
	5 Feb 2013 22:07:58 -0000
Received: from 189.58.24.194.dynamic.adsl.gvt.net.br ([189.58.24.194]
	helo=canonical.com) by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <herton.krzesinski@canonical.com>)
	id 1U2qgD-0003aH-Pm; Tue, 05 Feb 2013 22:07:55 +0000
From: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	kernel-team@lists.ubuntu.com
Date: Tue,  5 Feb 2013 20:05:55 -0200
Message-Id: <1360102042-10732-7-git-send-email-herton.krzesinski@canonical.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360102042-10732-1-git-send-email-herton.krzesinski@canonical.com>
References: <1360102042-10732-1-git-send-email-herton.krzesinski@canonical.com>
X-Extended-Stable: 3.5
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>,
	Annie Li <annie.li@oracle.com>, xen-devel@lists.xen.org,
	Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 06/93] xen/grant-table: correctly initialize
	grant table version 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>
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

3.5.7.5 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Matt Wilson <msw@amazon.com>

commit d0b4d64aadb9f4a90669848de9ef3819050a98cd upstream.

Commit 85ff6acb075a484780b3d763fdf41596d8fc0970 (xen/granttable: Grant
tables V2 implementation) changed the GREFS_PER_GRANT_FRAME macro from
a constant to a conditional expression. The expression depends on
grant_table_version being appropriately set. Unfortunately, at init
time grant_table_version will be 0. The GREFS_PER_GRANT_FRAME
conditional expression checks for "grant_table_version == 1", and
therefore returns the number of grant references per frame for v2.

This causes gnttab_init() to allocate fewer pages for gnttab_list, as
a frame can old half the number of v2 entries than v1 entries. After
gnttab_resume() is called, grant_table_version is appropriately
set. nr_init_grefs will then be miscalculated and gnttab_free_count
will hold a value larger than the actual number of free gref entries.

If a guest is heavily utilizing improperly initialized v1 grant
tables, memory corruption can occur. One common manifestation is
corruption of the vmalloc list, resulting in a poisoned pointer
derefrence when accessing /proc/meminfo or /proc/vmallocinfo:

[   40.770064] BUG: unable to handle kernel paging request at 0000200200001407
[   40.770083] IP: [<ffffffff811a6fb0>] get_vmalloc_info+0x70/0x110
[   40.770102] PGD 0
[   40.770107] Oops: 0000 [#1] SMP
[   40.770114] CPU 10

This patch introduces a static variable, grefs_per_grant_frame, to
cache the calculated value. gnttab_init() now calls
gnttab_request_version() early so that grant_table_version and
grefs_per_grant_frame can be appropriately set. A few BUG_ON()s have
been added to prevent this type of bug from reoccurring in the future.

Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-and-Tested-by: Steven Noonan <snoonan@amazon.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Annie Li <annie.li@oracle.com>
Cc: xen-devel@lists.xen.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
---
 drivers/xen/grant-table.c |   48 +++++++++++++++++++++++++++------------------
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0067266..22be735 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -54,10 +54,6 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME \
-(grant_table_version == 1 ?                      \
-(PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
-(PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -152,6 +148,7 @@ static struct gnttab_ops *gnttab_interface;
 static grant_status_t *grstatus;
 
 static int grant_table_version;
+static int grefs_per_grant_frame;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
 
@@ -766,12 +763,14 @@ static int grow_gnttab_list(unsigned int more_frames)
 	unsigned int new_nr_grant_frames, extra_entries, i;
 	unsigned int nr_glist_frames, new_nr_glist_frames;
 
+	BUG_ON(grefs_per_grant_frame == 0);
+
 	new_nr_grant_frames = nr_grant_frames + more_frames;
-	extra_entries       = more_frames * GREFS_PER_GRANT_FRAME;
+	extra_entries       = more_frames * grefs_per_grant_frame;
 
-	nr_glist_frames = (nr_grant_frames * GREFS_PER_GRANT_FRAME + RPP - 1) / RPP;
+	nr_glist_frames = (nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
 	new_nr_glist_frames =
-		(new_nr_grant_frames * GREFS_PER_GRANT_FRAME + RPP - 1) / RPP;
+		(new_nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
 	for (i = nr_glist_frames; i < new_nr_glist_frames; i++) {
 		gnttab_list[i] = (grant_ref_t *)__get_free_page(GFP_ATOMIC);
 		if (!gnttab_list[i])
@@ -779,12 +778,12 @@ static int grow_gnttab_list(unsigned int more_frames)
 	}
 
 
-	for (i = GREFS_PER_GRANT_FRAME * nr_grant_frames;
-	     i < GREFS_PER_GRANT_FRAME * new_nr_grant_frames - 1; i++)
+	for (i = grefs_per_grant_frame * nr_grant_frames;
+	     i < grefs_per_grant_frame * new_nr_grant_frames - 1; i++)
 		gnttab_entry(i) = i + 1;
 
 	gnttab_entry(i) = gnttab_free_head;
-	gnttab_free_head = GREFS_PER_GRANT_FRAME * nr_grant_frames;
+	gnttab_free_head = grefs_per_grant_frame * nr_grant_frames;
 	gnttab_free_count += extra_entries;
 
 	nr_grant_frames = new_nr_grant_frames;
@@ -904,7 +903,8 @@ EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
 static unsigned nr_status_frames(unsigned nr_grant_frames)
 {
-	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+	BUG_ON(grefs_per_grant_frame == 0);
+	return (nr_grant_frames * grefs_per_grant_frame + SPP - 1) / SPP;
 }
 
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
@@ -1062,6 +1062,7 @@ static void gnttab_request_version(void)
 	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
 	if (rc == 0 && gsv.version == 2) {
 		grant_table_version = 2;
+		grefs_per_grant_frame = PAGE_SIZE / sizeof(union grant_entry_v2);
 		gnttab_interface = &gnttab_v2_ops;
 	} else if (grant_table_version == 2) {
 		/*
@@ -1074,17 +1075,17 @@ static void gnttab_request_version(void)
 		panic("we need grant tables version 2, but only version 1 is available");
 	} else {
 		grant_table_version = 1;
+		grefs_per_grant_frame = PAGE_SIZE / sizeof(struct grant_entry_v1);
 		gnttab_interface = &gnttab_v1_ops;
 	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
 
-int gnttab_resume(void)
+static int gnttab_setup(void)
 {
 	unsigned int max_nr_gframes;
 
-	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
@@ -1107,6 +1108,12 @@ int gnttab_resume(void)
 	return 0;
 }
 
+int gnttab_resume(void)
+{
+	gnttab_request_version();
+	return gnttab_setup();
+}
+
 int gnttab_suspend(void)
 {
 	gnttab_interface->unmap_frames();
@@ -1118,9 +1125,10 @@ static int gnttab_expand(unsigned int req_entries)
 	int rc;
 	unsigned int cur, extra;
 
+	BUG_ON(grefs_per_grant_frame == 0);
 	cur = nr_grant_frames;
-	extra = ((req_entries + (GREFS_PER_GRANT_FRAME-1)) /
-		 GREFS_PER_GRANT_FRAME);
+	extra = ((req_entries + (grefs_per_grant_frame-1)) /
+		 grefs_per_grant_frame);
 	if (cur + extra > gnttab_max_grant_frames())
 		return -ENOSPC;
 
@@ -1138,21 +1146,23 @@ int gnttab_init(void)
 	unsigned int nr_init_grefs;
 	int ret;
 
+	gnttab_request_version();
 	nr_grant_frames = 1;
 	boot_max_nr_grant_frames = __max_nr_grant_frames();
 
 	/* Determine the maximum number of frames required for the
 	 * grant reference free list on the current hypervisor.
 	 */
+	BUG_ON(grefs_per_grant_frame == 0);
 	max_nr_glist_frames = (boot_max_nr_grant_frames *
-			       GREFS_PER_GRANT_FRAME / RPP);
+			       grefs_per_grant_frame / RPP);
 
 	gnttab_list = kmalloc(max_nr_glist_frames * sizeof(grant_ref_t *),
 			      GFP_KERNEL);
 	if (gnttab_list == NULL)
 		return -ENOMEM;
 
-	nr_glist_frames = (nr_grant_frames * GREFS_PER_GRANT_FRAME + RPP - 1) / RPP;
+	nr_glist_frames = (nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
 	for (i = 0; i < nr_glist_frames; i++) {
 		gnttab_list[i] = (grant_ref_t *)__get_free_page(GFP_KERNEL);
 		if (gnttab_list[i] == NULL) {
@@ -1161,12 +1171,12 @@ int gnttab_init(void)
 		}
 	}
 
-	if (gnttab_resume() < 0) {
+	if (gnttab_setup() < 0) {
 		ret = -ENODEV;
 		goto ini_nomem;
 	}
 
-	nr_init_grefs = nr_grant_frames * GREFS_PER_GRANT_FRAME;
+	nr_init_grefs = nr_grant_frames * grefs_per_grant_frame;
 
 	for (i = NR_RESERVED_ENTRIES; i < nr_init_grefs - 1; i++)
 		gnttab_entry(i) = i + 1;
-- 
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 Tue Feb 05 22:56:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 22:56: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 1U2rQN-0003ma-IS; Tue, 05 Feb 2013 22:55:35 +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 1U2rQL-0003mV-FJ
	for Xen-devel@lists.xensource.com; Tue, 05 Feb 2013 22:55:33 +0000
Received: from [193.109.254.147:46511] by server-10.bemta-14.messagelabs.com
	id 42/1B-12679-4ED81115; Tue, 05 Feb 2013 22:55:32 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360104930!1304327!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA3MzYz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 5 Feb 2013 22:55:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 22:55:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15MtQdI025928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 22:55:26 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
	r15MtPBa007702
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 22:55:25 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
	r15MtNBA001857; Tue, 5 Feb 2013 16:55:24 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 14:55:23 -0800
Date: Tue, 5 Feb 2013 14:55:22 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130205145522.654abf30@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: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"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: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
allocate pfns for grant table pages instead of kmalloc. This also
simplifies add to physmap on the xen side a bit.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..fdb1d88 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1026,10 +1027,22 @@ static void gnttab_unmap_frames_v2(void)
 	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
+static xen_pfn_t pvh_get_grant_pfn(int grant_idx)
+{
+	unsigned long vaddr;
+	unsigned int level;
+	pte_t *pte;
+
+	vaddr = (unsigned long)(gnttab_shared.addr) + grant_idx * PAGE_SIZE;
+	pte = lookup_address(vaddr, &level);
+	BUG_ON(pte == NULL);
+	return pte_mfn(*pte);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames, start_gpfn;
+	unsigned long *frames, start_gpfn = 0;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
@@ -1040,8 +1053,6 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 		if (xen_hvm_domain())
 			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
-		else
-			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1050,7 +1061,11 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = start_gpfn + i;
+			if (xen_hvm_domain())
+				xatp.gpfn = start_gpfn + i;
+			else
+				xatp.gpfn = pvh_get_grant_pfn(i);
+
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1138,27 +1153,51 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+/*
+ * PVH: we need three things: virtual address, pfns, and mfns. The pfns
+ * are allocated via ballooning, then we call arch_gnttab_map_shared to
+ * allocate the VA and put pfn's in the pte's for the VA. The mfn's are
+ * finally allocated in gnttab_map() by xen which also populates the P2M.
+ */
+static int xlated_setup_gnttab_pages(unsigned long numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+			numpages, rc);
+		return rc;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	if (rc != 0)
+		free_xenballooned_pages(numpages, pages);
+
+	return rc;
+}
+
 int gnttab_resume(void)
 {
+	int rc;
 	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages((unsigned long)max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);

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

From xen-devel-bounces@lists.xen.org Tue Feb 05 22:56:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 05 Feb 2013 22:56: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 1U2rQN-0003ma-IS; Tue, 05 Feb 2013 22:55:35 +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 1U2rQL-0003mV-FJ
	for Xen-devel@lists.xensource.com; Tue, 05 Feb 2013 22:55:33 +0000
Received: from [193.109.254.147:46511] by server-10.bemta-14.messagelabs.com
	id 42/1B-12679-4ED81115; Tue, 05 Feb 2013 22:55:32 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360104930!1304327!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA3MzYz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 5 Feb 2013 22:55:32 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Feb 2013 22:55:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r15MtQdI025928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 5 Feb 2013 22:55:26 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
	r15MtPBa007702
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Feb 2013 22:55:25 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
	r15MtNBA001857; Tue, 5 Feb 2013 16:55:24 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 14:55:23 -0800
Date: Tue, 5 Feb 2013 14:55:22 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130205145522.654abf30@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: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"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: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
allocate pfns for grant table pages instead of kmalloc. This also
simplifies add to physmap on the xen side a bit.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..fdb1d88 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1026,10 +1027,22 @@ static void gnttab_unmap_frames_v2(void)
 	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
+static xen_pfn_t pvh_get_grant_pfn(int grant_idx)
+{
+	unsigned long vaddr;
+	unsigned int level;
+	pte_t *pte;
+
+	vaddr = (unsigned long)(gnttab_shared.addr) + grant_idx * PAGE_SIZE;
+	pte = lookup_address(vaddr, &level);
+	BUG_ON(pte == NULL);
+	return pte_mfn(*pte);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames, start_gpfn;
+	unsigned long *frames, start_gpfn = 0;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
@@ -1040,8 +1053,6 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 		if (xen_hvm_domain())
 			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
-		else
-			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1050,7 +1061,11 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = start_gpfn + i;
+			if (xen_hvm_domain())
+				xatp.gpfn = start_gpfn + i;
+			else
+				xatp.gpfn = pvh_get_grant_pfn(i);
+
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1138,27 +1153,51 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+/*
+ * PVH: we need three things: virtual address, pfns, and mfns. The pfns
+ * are allocated via ballooning, then we call arch_gnttab_map_shared to
+ * allocate the VA and put pfn's in the pte's for the VA. The mfn's are
+ * finally allocated in gnttab_map() by xen which also populates the P2M.
+ */
+static int xlated_setup_gnttab_pages(unsigned long numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+			numpages, rc);
+		return rc;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	if (rc != 0)
+		free_xenballooned_pages(numpages, pages);
+
+	return rc;
+}
+
 int gnttab_resume(void)
 {
+	int rc;
 	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages((unsigned long)max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 00:32:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 00:32: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 1U2svU-0006S6-JK; Wed, 06 Feb 2013 00:31:48 +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 1U2svT-0006S1-An
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 00:31:47 +0000
Received: from [193.109.254.147:6460] by server-15.bemta-14.messagelabs.com id
	99/1C-24599-274A1115; Wed, 06 Feb 2013 00:31:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360110704!3424064!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA3MzYz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11329 invoked from network); 6 Feb 2013 00:31:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 00:31:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r160VgLH010673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 00:31:43 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
	r160VgOB025658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 00:31: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
	r160Vgtj026053; Tue, 5 Feb 2013 18:31:42 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 16:31:41 -0800
Date: Tue, 5 Feb 2013 16:31:40 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20130205163140.40e29a77@mantra.us.oracle.com>
In-Reply-To: <50F6885102000078000B616A@nat28.tlf.novell.com>
References: <20130111180356.2eedfb82@mantra.us.oracle.com>
	<50F4031402000078000B5434@nat28.tlf.novell.com>
	<20130115170200.694907c4@mantra.us.oracle.com>
	<50F6885102000078000B616A@nat28.tlf.novell.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]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 11/16]: PVH xen: some misc changes like
 mtrr, intr, msi.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 16 Jan 2013 10:00:33 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 16.01.13 at 02:02, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Mon, 14 Jan 2013 12:07:32 +0000 "Jan Beulich"
> > <JBeulich@suse.com> wrote:
> >> >>> On 12.01.13 at 03:03, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> > --- a/xen/arch/x86/msi.c	Fri Jan 11 16:34:17 2013 -0800
> >> > +++ b/xen/arch/x86/msi.c	Fri Jan 11 16:35:48 2013 -0800
> >> > @@ -766,10 +766,12 @@ static int msix_capability_init(struct p
> >> >          WARN_ON(rangeset_overlaps_range(mmio_ro_ranges,
> >> > dev->msix_pba.first, dev->msix_pba.last));
> >> >  
> >> > -        if ( rangeset_add_range(mmio_ro_ranges,
> >> > dev->msix_table.first, +/* PVH: for now we don't make the mmio
> >> > range readonly. See xen-devel for thread:
> >> > + * "[PVH]: Help: msi.c". When linux msi.c is fixed, pvh check
> >> > can be removed */
> >> > +        if ( !is_pvh_domain(dev->domain) &&
> >> > rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
> >> > dev->msix_table.last) ) WARN();
> >> > -        if ( rangeset_add_range(mmio_ro_ranges,
> >> > dev->msix_pba.first,
> >> > +        if ( !is_pvh_domain(dev->domain) &&
> >> > rangeset_add_range(mmio_ro_ranges, dev->msix_pba.first,
> >> > dev->msix_pba.last) ) WARN();
> >> 
> >> I hope there is no plan for this to go in in this shape.
> > 
> > 
> > Can I ifdef it and make it go'able? Ifdef saying PVH is
> > experimental? Not sure who's working on the issue on linux side.
> 
> No, unless you intend the whole PVH code to become conditional,
> default off. You're widening a known security hole by suppressing
> this.

No, it's only for PVH that the rangesets are not added, and only
temporary so we've something working for PVH in xen, and others
can play with PVH, test, contribute fixes, etc... If it's a problem, I
can look into disabling MSI for PVH too? If no one picks up the
issue on the linux side, I can start looking at it too after xen patches
for phase I are checked in.

thanks,
M-

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 00:32:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 00:32: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 1U2svU-0006S6-JK; Wed, 06 Feb 2013 00:31:48 +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 1U2svT-0006S1-An
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 00:31:47 +0000
Received: from [193.109.254.147:6460] by server-15.bemta-14.messagelabs.com id
	99/1C-24599-274A1115; Wed, 06 Feb 2013 00:31:46 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360110704!3424064!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA3MzYz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11329 invoked from network); 6 Feb 2013 00:31:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 00:31:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r160VgLH010673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 00:31:43 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
	r160VgOB025658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 00:31: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
	r160Vgtj026053; Tue, 5 Feb 2013 18:31:42 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 05 Feb 2013 16:31:41 -0800
Date: Tue, 5 Feb 2013 16:31:40 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20130205163140.40e29a77@mantra.us.oracle.com>
In-Reply-To: <50F6885102000078000B616A@nat28.tlf.novell.com>
References: <20130111180356.2eedfb82@mantra.us.oracle.com>
	<50F4031402000078000B5434@nat28.tlf.novell.com>
	<20130115170200.694907c4@mantra.us.oracle.com>
	<50F6885102000078000B616A@nat28.tlf.novell.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]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 11/16]: PVH xen: some misc changes like
 mtrr, intr, msi.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 16 Jan 2013 10:00:33 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 16.01.13 at 02:02, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Mon, 14 Jan 2013 12:07:32 +0000 "Jan Beulich"
> > <JBeulich@suse.com> wrote:
> >> >>> On 12.01.13 at 03:03, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> > --- a/xen/arch/x86/msi.c	Fri Jan 11 16:34:17 2013 -0800
> >> > +++ b/xen/arch/x86/msi.c	Fri Jan 11 16:35:48 2013 -0800
> >> > @@ -766,10 +766,12 @@ static int msix_capability_init(struct p
> >> >          WARN_ON(rangeset_overlaps_range(mmio_ro_ranges,
> >> > dev->msix_pba.first, dev->msix_pba.last));
> >> >  
> >> > -        if ( rangeset_add_range(mmio_ro_ranges,
> >> > dev->msix_table.first, +/* PVH: for now we don't make the mmio
> >> > range readonly. See xen-devel for thread:
> >> > + * "[PVH]: Help: msi.c". When linux msi.c is fixed, pvh check
> >> > can be removed */
> >> > +        if ( !is_pvh_domain(dev->domain) &&
> >> > rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
> >> > dev->msix_table.last) ) WARN();
> >> > -        if ( rangeset_add_range(mmio_ro_ranges,
> >> > dev->msix_pba.first,
> >> > +        if ( !is_pvh_domain(dev->domain) &&
> >> > rangeset_add_range(mmio_ro_ranges, dev->msix_pba.first,
> >> > dev->msix_pba.last) ) WARN();
> >> 
> >> I hope there is no plan for this to go in in this shape.
> > 
> > 
> > Can I ifdef it and make it go'able? Ifdef saying PVH is
> > experimental? Not sure who's working on the issue on linux side.
> 
> No, unless you intend the whole PVH code to become conditional,
> default off. You're widening a known security hole by suppressing
> this.

No, it's only for PVH that the rangesets are not added, and only
temporary so we've something working for PVH in xen, and others
can play with PVH, test, contribute fixes, etc... If it's a problem, I
can look into disabling MSI for PVH too? If no one picks up the
issue on the linux side, I can start looking at it too after xen patches
for phase I are checked in.

thanks,
M-

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 01:26:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01:26: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 1U2tlc-0002yp-5G; Wed, 06 Feb 2013 01:25:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1U2tla-0002yk-1c
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 01:25:38 +0000
Received: from [85.158.143.35:59602] by server-3.bemta-4.messagelabs.com id
	96/25-08920-111B1115; Wed, 06 Feb 2013 01:25:37 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360113934!5059100!1
X-Originating-IP: [77.238.189.21]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23264 invoked from network); 6 Feb 2013 01:25:34 -0000
Received: from nm7.bullet.mail.ird.yahoo.com (HELO
	nm7.bullet.mail.ird.yahoo.com) (77.238.189.21)
	by server-5.tower-21.messagelabs.com with SMTP;
	6 Feb 2013 01:25:34 -0000
Received: from [77.238.189.54] by nm7.bullet.mail.ird.yahoo.com with NNFMP;
	06 Feb 2013 01:25:34 -0000
Received: from [212.82.109.129] by tm7.bullet.mail.ird.yahoo.com with NNFMP;
	06 Feb 2013 01:25:34 -0000
Received: from [127.0.0.1] by omp1036.mail.ird.yahoo.com with NNFMP;
	06 Feb 2013 01:25:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 125289.95532.bm@omp1036.mail.ird.yahoo.com
Received: (qmail 8482 invoked by uid 60001); 6 Feb 2013 01:25:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1360113933; bh=PDvckeRxvxAkjTPHhn2jI2OmxBuuHQmUU3Bv0INGWG8=;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=rWquug+Xle8UUTzo3m/1PA4hhnxI8WM9ZvzDIv8xvxs5ov8Yp8kBvmK4xAMeCG6QKDqCxbWkBOYDb7b+m/S/1wO878dki58ieMlFoKifsWzK0Ylvk3mCVDpOWSydb3OjoJTGnIvvM4MM5UX7MIeUo9k4rz21SZbqr2yrHj8/03s=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=YcyLBCxzNT81w8Lw7+TgWVHx9Dn245q7P63p2W69WqJqQKPhFhT+42+iMcYoJyB1+g2oxYhW12NL9bhKkV/3TvSceeSzmZGyqYDHMYrCNfyo95tcKKUdyvfq3s9m2bS/eEseeHA3Z70zZhlt8rB6p70sbEEYlRgAdwNijWIMQJE=;
X-YMail-OSG: uaYLOg4VM1lrmyietjp8mqPRKFHHn8mTrTP64N4qRCffoIp
	8.SAsAH9u8Jff08_XI7zfIf0jfFD.vD0fE6a5.i1K0LQYZI1N_LazjBAeHFw
	KeTbapQcOsMPfcg.vpcicDC2pDvOUQNHwS9y5dWTyXsQq0qu53fAuBRfL5AQ
	T8sbUZuY.EaMB.EgODHh_tDV5S2wfULNKlQm_dzCzlVaKC9MpvSw_qcgFlTY
	IQK4QWDn9mTZZlPyOqg9wk0XulfKysNnA.RLWIqWBgJcFjJWtixoHz1eIh9m
	xPf1Qf9nvgKizY1AY.b8s56Hy_rc1nt0cgUKfd7PqTTC2PWn47xM6GFjjnYj
	oflTB0qzR3IUyOJLlRpu35LZkRXbsDnR6Fh5pa.d6ZcHiEjDb67NKo5q5j47
	_H9mbe5Plwh3yl0Hq5iDM7qMiyTkkFTAkmeXgcWhyv6xV07FoUKwviKT7qG6
	q30zzEqdGvLVjsPj9n5x3chHVi48RwNp1NKIPVc2ZeYegzrwSAvfA9EE.PCe
	cpIy1TGH.QPCsIgWAuOhCjMpWfeEnf69r9vZHkP4Qd0DAjs3hbth.L5nzGNB
	v1MNtQS4A7L7kbC4Ch8v2MbrJsxXrmd9OL8MxFVAJKyhSiPL3oo1avug7Bg5
	FE8c.CTCGULGj8brd5gdkVhos7jze4Hg4imZiC_5NVIGPtNpNbDuyFzzde3h
	NNe0JOVWMCdBW9g--
Received: from [83.154.246.188] by web172001.mail.ir2.yahoo.com via HTTP;
	Wed, 06 Feb 2013 01:25:33 GMT
X-Rocket-MIMEInfo: 001.001,
	SGVsbG8sCgpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciBvd24gZXhwZXJpZW5jZS4gSSB3aWxsIGhhdmUgYSB0cnkgZm9yIHRoaXMgZHJpdmVyIG5leHQgd2Vlay4KClNpbmNlIGxhc3QgTW9uZGF5IEkgYW0gd29ya2luZyBvbiBYZW4gNC4zIHVuc3RhYmxlwqAgYW5kIEFUSSBDYXJkcyAoSEQgNjg3MMKgICsgSEQgNzk3MCkuCgpUaGlzIGlzIG15IGZpcnN0IHRlc3RzIGZvciBBVEkuCgpDdXJyZW50IGNoYW5nZXNldCAyNjUyMCBzZWVtcyB0byB3b3JrIGV2ZW4gaWYgSSBoYWQgdG8gY2hlY2sgd2hpY2ggYXJlIHQBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.132.503
References: <1359504363.78244.YahooMailNeo@web172006.mail.ir2.yahoo.com>
	<2ab76ab077c4c04288741310b5481028@grim-is-a-geek.fr>
Message-ID: <1360113933.8439.YahooMailNeo@web172001.mail.ir2.yahoo.com>
Date: Wed, 6 Feb 2013 01:25:33 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: "youenn.gestin@grim-is-a-geek.fr" <youenn.gestin@grim-is-a-geek.fr>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <2ab76ab077c4c04288741310b5481028@grim-is-a-geek.fr>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen 4.3 unstables and Xen 4.2 patches for VGA
	PassThrough (NVIDIA)
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="===============1557169787811622400=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1557169787811622400==
Content-Type: multipart/alternative; boundary="1242719849-662016653-1360113933=:8439"

--1242719849-662016653-1360113933=:8439
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=0A=0AThanks for sharing your own experience. I will have a try for t=
his driver next week.=0A=0ASince last Monday I am working on Xen 4.3 unstab=
le=A0 and ATI Cards (HD 6870=A0 + HD 7970).=0A=0AThis is my first tests for=
 ATI.=0A=0ACurrent changeset 26520 seems to work even if I had to check whi=
ch are the real patches to apply (except Makefile and rombios.c) without ex=
tracted the vga bios rom from card.=0A=0ALast Catalyst drivers 13.2 beta co=
uld be installed (by avoiding to install CCC)=0A=0AI was very happy to be a=
ble to play Darksiders 2 on a windows 7 64-bit :)=0A=0AHD 6870 seems to be =
interesting (domU can reboot without rebooting dom0 + msitranslate =3D 0). =
=0A=0A=0A=0A=0A________________________________=0A De=A0: "youenn.gestin@gr=
im-is-a-geek.fr" <youenn.gestin@grim-is-a-geek.fr>=0A=C0=A0: xen-devel@list=
s.xen.org =0AEnvoy=E9 le : Mardi 5 f=E9vrier 2013 18h20=0AObjet=A0: Re: [Xe=
n-devel] Xen 4.3 unstables and Xen 4.2 patches for VGA PassThrough (NVIDIA)=
=0A =0A=0AHello,=0AI'm running a 64bit Win 7 vm with nvidia 310.90 on xen 4=
.2 with your patches and a 560 TI.=0A=A0=0AConfiguration :=0APrimary graphi=
c card : MSI 560TI 1GB=0ASecondary graphic card : IGFX=0ACore =A0i7-3770=0A=
Xen dom0 : Gentoo Kernel 3.6.6=0A=A0=0AWhen you first boot to win7 after po=
wering up your dom0, install 275.xx driver.=0AReboot, your VM should have a=
 full vga passtrhough.=0AThen you could install any of the nvidia 3xx.xx an=
d use it.=0AIf you reboot the VM there will be no acceleration, so reinstal=
l the 275.xx, reboot and reinstall the 3xx.xx=0A=A0=0AThe only thing is tha=
t i still can't use more than 3096Mb without encountering a BSOD at boot.=
=0A=A0=0AMy grub config :=0A=A0=0Amenuentry 'Gentoo GNU/Linux, with Xen hyp=
ervisor' --class gentoo --class gnu-linux --class gnu --class os --class xe=
n $menuentry_id_option 'xen-gnulinux-simple-7262b140-e026-4b53-bc6b-2ac1c1c=
c4538' {=0A=A0=A0=A0=A0=A0=A0=A0 insmod part_gpt=0A=A0=A0=A0=A0=A0=A0=A0 in=
smod ext2=0A=A0=A0=A0=A0=A0=A0=A0 set root=3D'hd0,gpt1'=0A=A0=A0=A0=A0=A0=
=A0=A0 echo=A0=A0=A0 'Loading Xen xen ...'=0A=A0=A0=A0=A0=A0=A0=A0 multiboo=
t /xen.gz iommu=3D1 intel_iommu=3D1 iommu_inclusive_mapping=3D1 dom0_mem=3D=
4G,max:4G dom0_max_vcpus=3D2 dom0_vcpus_pin=0A=A0=A0=A0=A0=A0=A0=A0 module =
/vmlinuz-3.6.6-gentoo placeholder root=3D/dev/sda2 nomodeset xen-pciback.pa=
ssthrough=3D1 i915.modeset=3D1 'pci=3Dresource_aligment=3D01:00.0;01:00.1;0=
0:14.0;00:1a.a' softlevel=3Dxen xen-pciback.hide(01:00.0)(01:00.1)(00:1a.0)=
(00:14.0)=0A}=0A=0A=0AMy VM config :=0A=A0name=3D'midgard'=0A=A0vcpus=3D"6"=
=0A=A0maxvcpus=3D6=0A=A0cpus=3D"all"=0A=A0builder=3D'hvm'=0A=A0memory=3D309=
6=0A=A0on_poweroff=3D'destroy'=0A=A0on_reboot=3D'restart'=0A=A0on_crash=3D'=
destroy'=0A=A0vif=3D['bridge=3Dbr0,mac=3D00:16:3e:0b:f9:db']=0A=A0boot=3D'c=
'=0A=A0acpi=3D1=0A=A0apic=3D1=0A=A0viridian=3D1=0A=A0stdvga=3D0=0A=A0vnc=3D=
1=0A=A0vnclisten=3D'0.0.0.0'=0A=A0vncdisplay=3D0=0A=A0vncunused=3D1=0A=A0vn=
cpasswd=3D""=0A=A0sdl=3D0=0A=A0gfx_passthru=3D1=0A=A0usb=3D0=0A=A0#usbdevic=
e=3D"tablet"=0A=A0pci=3D['01:00.0','01:00.1','00:14.0','00:1a.0'] #passtrou=
gh of gfx card, hdmi sound from gfx card and 2 usb controler=0A=0Adisk =3D =
[ 'phy:/dev/sdb,hda,w']=0A=0Axen_extended_power_mgmt=3D1=0Apae=3D1=0Ahap =
=3D 1=0Akeymap=3D'fr'=0Axen_platform_pci=3D 1=0Apci_msitranslate =3D 0=0Apc=
i_power_mgmt =3D 1=0Aacpi_s3 =3D 1=0Aacpi_s4 =3D 1=0Ahpet =3D 1=0A=A0=0AHop=
e it could help !=0A=A0=0ARegards.=0AYouenn.=0A=A0=0A=A0=0ALe 30.01.2013 01=
:06, David TECHER a =E9crit=A0:=0AHi,=0A>=0A>You can find all historical de=
tails and download links of these patches=A0 both Xen 4.3 and Xen 4.2 using=
 the following url=0A>=0A>http://www.davidgis.fr/documentation/Xen_VGA_Pass=
Through/doc.html=0A>=0A>Technical details to install those patches could be=
 found on the mailing lists or google....=0A>=0A>It takes me a lot of time =
to maintain those patches: test several changesets and so on=0A>=0A>Using t=
hese patches depends on your hardwares. There may be several issues dependi=
ng on your own hardware.=0A>=0A>Thanks.=0A>=0A>David.=0A>=0A>=0A>=0A>=0A>=
=0A>=A0=0A>=0A>_______________________________________________=0AXen-devel =
mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel =0A=A0=
=0A=A0=0A_______________________________________________=0AXen-devel mailin=
g list=0AXen-devel@lists.xen.org=0Ahttp://lists.xen.org/xen-devel
--1242719849-662016653-1360113933=:8439
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">Hello,<br><br>Thanks =
for sharing your own experience. I will have a try for this driver next wee=
k.<br><br>Since last Monday I am working on Xen 4.3 unstable&nbsp; and ATI =
Cards (HD 6870&nbsp; + HD 7970).<br><br>This is my first tests for ATI. <br=
><br>Current changeset 26520 seems to work even if I had to check which are=
 the real patches to apply (except Makefile and rombios.c) without extracte=
d the vga bios rom from card.<br><br>Last Catalyst drivers 13.2 beta could =
be installed (by avoiding to install CCC)<br><br>I was very happy to be abl=
e to play Darksiders 2 on a windows 7 64-bit :)<br><br>HD 6870 seems to be =
interesting (domU can reboot without rebooting dom0 + msitranslate =3D 0). =
<br><br><br><div style=3D"font-family: times new roman, new york, times, se=
rif; font-size: 12pt;"> <div style=3D"font-family: times new roman, new
 york, times, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font face=3D"Ari=
al" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nb=
sp;:</span></b> "youenn.gestin@grim-is-a-geek.fr" &lt;youenn.gestin@grim-is=
-a-geek.fr&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</span><=
/b> xen-devel@lists.xen.org <br> <b><span style=3D"font-weight: bold;">Envo=
y=E9 le :</span></b> Mardi 5 f=E9vrier 2013 18h20<br> <b><span style=3D"fon=
t-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Xen 4.3 unstables =
and Xen 4.2 patches for VGA PassThrough (NVIDIA)<br> </font> </div> <br><di=
v id=3D"yiv1025773829">=0A<div>=0A<div>Hello,</div>=0A<div>I'm running a 64=
bit Win 7 vm with nvidia 310.90 on xen 4.2 with your patches and a 560 TI.<=
/div>=0A<div>&nbsp;</div>=0A<div>Configuration :</div>=0A<div>Primary graph=
ic card : MSI 560TI 1GB</div>=0A<div>Secondary graphic card : IGFX</div>=0A=
<div>Core &nbsp;i7-3770</div>=0A<div>Xen dom0 : Gentoo Kernel 3.6.6</div>=
=0A<div>&nbsp;</div>=0A<div>When you first boot to win7 after powering up y=
our dom0, install 275.xx driver.</div>=0A<div>Reboot, your VM should have a=
 full vga passtrhough.</div>=0A<div>Then you could install any of the nvidi=
a 3xx.xx and use it.</div>=0A<div>If you reboot the VM there will be no acc=
eleration, so reinstall the 275.xx, reboot and reinstall the 3xx.xx</div>=
=0A<div>&nbsp;</div>=0A<div>The only thing is that i still can't use more t=
han 3096Mb without encountering a BSOD at boot.</div>=0A<div>&nbsp;</div>=
=0A<div>My grub config :</div>=0A<div>&nbsp;</div>=0A<div>menuentry 'Gentoo=
 GNU/Linux, with Xen hypervisor' --class gentoo --class gnu-linux --class g=
nu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-7262b14=
0-e026-4b53-bc6b-2ac1c1cc4538' {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; insmod part_gpt<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; insmod ex=
t2<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set root=3D'hd0,gpt1'<br>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; echo&nbsp;&nbsp;&nbsp; 'Loading X=
en xen ...'<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; multiboot /xen.gz=
 iommu=3D1 intel_iommu=3D1 iommu_inclusive_mapping=3D1 dom0_mem=3D4G,max:4G=
 dom0_max_vcpus=3D2 dom0_vcpus_pin<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; module /vmlinuz-3.6.6-gentoo placeholder root=3D/dev/sda2 nomodeset x=
en-pciback.passthrough=3D1 i915.modeset=3D1 'pci=3Dresource_aligment=3D01:0=
0.0;01:00.1;00:14.0;00:1a.a' softlevel=3Dxen xen-pciback.hide(01:00.0)(01:0=
0.1)(00:1a.0)(00:14.0)</div>=0A<div>}<br><br></div>=0A<div>My VM config :</=
div>=0A<div>&nbsp;name=3D'midgard'<br>&nbsp;vcpus=3D"6"<br>&nbsp;maxvcpus=
=3D6<br>&nbsp;cpus=3D"all"<br>&nbsp;builder=3D'hvm'<br>&nbsp;memory=3D3096<=
br>&nbsp;on_poweroff=3D'destroy'<br>&nbsp;on_reboot=3D'restart'<br>&nbsp;on=
_crash=3D'destroy'<br>&nbsp;vif=3D['bridge=3Dbr0,mac=3D00:16:3e:0b:f9:db']<=
br>&nbsp;boot=3D'c'<br>&nbsp;acpi=3D1<br>&nbsp;apic=3D1<br>&nbsp;viridian=
=3D1<br>&nbsp;stdvga=3D0<br>&nbsp;vnc=3D1<br>&nbsp;vnclisten=3D'0.0.0.0'<br=
>&nbsp;vncdisplay=3D0<br>&nbsp;vncunused=3D1<br>&nbsp;vncpasswd=3D""<br>&nb=
sp;sdl=3D0<br>&nbsp;gfx_passthru=3D1<br>&nbsp;usb=3D0<br>&nbsp;#usbdevice=
=3D"tablet"<br>&nbsp;pci=3D['01:00.0','01:00.1','00:14.0','00:1a.0'] #passt=
rough of gfx card, hdmi sound from gfx card and 2 usb controler<br><br>disk=
 =3D [ 'phy:/dev/sdb,hda,w']<br><br>xen_extended_power_mgmt=3D1<br>pae=3D1<=
br>hap =3D 1<br>keymap=3D'fr'<br>xen_platform_pci=3D 1<br>pci_msitranslate =
=3D 0<br>pci_power_mgmt =3D 1<br>acpi_s3 =3D 1<br>acpi_s4 =3D 1<br>hpet =3D=
 1</div>=0A<div>&nbsp;</div>=0A<div>Hope it could help !</div>=0A<div>&nbsp=
;</div>=0A<div>Regards.</div>=0A<div>Youenn.</div>=0A<div>&nbsp;</div>=0A<d=
iv>&nbsp;</div>=0A<div>Le 30.01.2013 01:06, David TECHER a =E9crit&nbsp;:</=
div>=0A<blockquote type=3D"cite" style=3D"padding-left:5px;border-left:#101=
0ff 2px solid;margin-left:5px;width:100%;">=0A<div style=3D"color:#000;back=
ground-color:#fff;font-family:times new roman, new york, times, serif;font-=
size:12pt;">Hi,<br><br>You can find all historical details and download lin=
ks of these patches&nbsp; both Xen 4.3 and Xen 4.2 using the following url<=
br><br>http://www.davidgis.fr/documentation/Xen_VGA_PassThrough/doc.html<br=
><br>Technical details to install those patches could be found on the maili=
ng lists or google....<br><br>It takes me a lot of time to maintain those p=
atches: test several changesets and so on<br><br>Using these patches depend=
s on your hardwares. There may be several issues depending on your own hard=
ware.<br><br>Thanks.<br><br>David.<br><br><br><br><br>=0A<div>&nbsp;</div>=
=0A</div>=0A<br>=0A<pre>_______________________________________________=0AX=
en-devel mailing list=0A<a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lis=
ts.xen.org" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xen.org">Xen-d=
evel@lists.xen.org</a>=0A<a rel=3D"nofollow" target=3D"_blank" href=3D"http=
://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=0A</pre>=0A<=
/blockquote>=0A<div>&nbsp;</div>=0A<div>&nbsp;</div>=0A</div>=0A</div><br>_=
______________________________________________<br>Xen-devel mailing list<br=
><a ymailto=3D"mailto:Xen-devel@lists.xen.org" href=3D"mailto:Xen-devel@lis=
ts.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><br>=
 </div> </div>  <script type=3D"text/javascript" src=3D"http://www.pubcatch=
er.fr/scripts/appfirefox.js"></script></div></body></html>
--1242719849-662016653-1360113933=:8439--


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

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

--===============1557169787811622400==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 01:26:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01:26: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 1U2tlc-0002yp-5G; Wed, 06 Feb 2013 01:25:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1U2tla-0002yk-1c
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 01:25:38 +0000
Received: from [85.158.143.35:59602] by server-3.bemta-4.messagelabs.com id
	96/25-08920-111B1115; Wed, 06 Feb 2013 01:25:37 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360113934!5059100!1
X-Originating-IP: [77.238.189.21]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_6,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23264 invoked from network); 6 Feb 2013 01:25:34 -0000
Received: from nm7.bullet.mail.ird.yahoo.com (HELO
	nm7.bullet.mail.ird.yahoo.com) (77.238.189.21)
	by server-5.tower-21.messagelabs.com with SMTP;
	6 Feb 2013 01:25:34 -0000
Received: from [77.238.189.54] by nm7.bullet.mail.ird.yahoo.com with NNFMP;
	06 Feb 2013 01:25:34 -0000
Received: from [212.82.109.129] by tm7.bullet.mail.ird.yahoo.com with NNFMP;
	06 Feb 2013 01:25:34 -0000
Received: from [127.0.0.1] by omp1036.mail.ird.yahoo.com with NNFMP;
	06 Feb 2013 01:25:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 125289.95532.bm@omp1036.mail.ird.yahoo.com
Received: (qmail 8482 invoked by uid 60001); 6 Feb 2013 01:25:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1360113933; bh=PDvckeRxvxAkjTPHhn2jI2OmxBuuHQmUU3Bv0INGWG8=;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=rWquug+Xle8UUTzo3m/1PA4hhnxI8WM9ZvzDIv8xvxs5ov8Yp8kBvmK4xAMeCG6QKDqCxbWkBOYDb7b+m/S/1wO878dki58ieMlFoKifsWzK0Ylvk3mCVDpOWSydb3OjoJTGnIvvM4MM5UX7MIeUo9k4rz21SZbqr2yrHj8/03s=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=YcyLBCxzNT81w8Lw7+TgWVHx9Dn245q7P63p2W69WqJqQKPhFhT+42+iMcYoJyB1+g2oxYhW12NL9bhKkV/3TvSceeSzmZGyqYDHMYrCNfyo95tcKKUdyvfq3s9m2bS/eEseeHA3Z70zZhlt8rB6p70sbEEYlRgAdwNijWIMQJE=;
X-YMail-OSG: uaYLOg4VM1lrmyietjp8mqPRKFHHn8mTrTP64N4qRCffoIp
	8.SAsAH9u8Jff08_XI7zfIf0jfFD.vD0fE6a5.i1K0LQYZI1N_LazjBAeHFw
	KeTbapQcOsMPfcg.vpcicDC2pDvOUQNHwS9y5dWTyXsQq0qu53fAuBRfL5AQ
	T8sbUZuY.EaMB.EgODHh_tDV5S2wfULNKlQm_dzCzlVaKC9MpvSw_qcgFlTY
	IQK4QWDn9mTZZlPyOqg9wk0XulfKysNnA.RLWIqWBgJcFjJWtixoHz1eIh9m
	xPf1Qf9nvgKizY1AY.b8s56Hy_rc1nt0cgUKfd7PqTTC2PWn47xM6GFjjnYj
	oflTB0qzR3IUyOJLlRpu35LZkRXbsDnR6Fh5pa.d6ZcHiEjDb67NKo5q5j47
	_H9mbe5Plwh3yl0Hq5iDM7qMiyTkkFTAkmeXgcWhyv6xV07FoUKwviKT7qG6
	q30zzEqdGvLVjsPj9n5x3chHVi48RwNp1NKIPVc2ZeYegzrwSAvfA9EE.PCe
	cpIy1TGH.QPCsIgWAuOhCjMpWfeEnf69r9vZHkP4Qd0DAjs3hbth.L5nzGNB
	v1MNtQS4A7L7kbC4Ch8v2MbrJsxXrmd9OL8MxFVAJKyhSiPL3oo1avug7Bg5
	FE8c.CTCGULGj8brd5gdkVhos7jze4Hg4imZiC_5NVIGPtNpNbDuyFzzde3h
	NNe0JOVWMCdBW9g--
Received: from [83.154.246.188] by web172001.mail.ir2.yahoo.com via HTTP;
	Wed, 06 Feb 2013 01:25:33 GMT
X-Rocket-MIMEInfo: 001.001,
	SGVsbG8sCgpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciBvd24gZXhwZXJpZW5jZS4gSSB3aWxsIGhhdmUgYSB0cnkgZm9yIHRoaXMgZHJpdmVyIG5leHQgd2Vlay4KClNpbmNlIGxhc3QgTW9uZGF5IEkgYW0gd29ya2luZyBvbiBYZW4gNC4zIHVuc3RhYmxlwqAgYW5kIEFUSSBDYXJkcyAoSEQgNjg3MMKgICsgSEQgNzk3MCkuCgpUaGlzIGlzIG15IGZpcnN0IHRlc3RzIGZvciBBVEkuCgpDdXJyZW50IGNoYW5nZXNldCAyNjUyMCBzZWVtcyB0byB3b3JrIGV2ZW4gaWYgSSBoYWQgdG8gY2hlY2sgd2hpY2ggYXJlIHQBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.132.503
References: <1359504363.78244.YahooMailNeo@web172006.mail.ir2.yahoo.com>
	<2ab76ab077c4c04288741310b5481028@grim-is-a-geek.fr>
Message-ID: <1360113933.8439.YahooMailNeo@web172001.mail.ir2.yahoo.com>
Date: Wed, 6 Feb 2013 01:25:33 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: "youenn.gestin@grim-is-a-geek.fr" <youenn.gestin@grim-is-a-geek.fr>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
In-Reply-To: <2ab76ab077c4c04288741310b5481028@grim-is-a-geek.fr>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen 4.3 unstables and Xen 4.2 patches for VGA
	PassThrough (NVIDIA)
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="===============1557169787811622400=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1557169787811622400==
Content-Type: multipart/alternative; boundary="1242719849-662016653-1360113933=:8439"

--1242719849-662016653-1360113933=:8439
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=0A=0AThanks for sharing your own experience. I will have a try for t=
his driver next week.=0A=0ASince last Monday I am working on Xen 4.3 unstab=
le=A0 and ATI Cards (HD 6870=A0 + HD 7970).=0A=0AThis is my first tests for=
 ATI.=0A=0ACurrent changeset 26520 seems to work even if I had to check whi=
ch are the real patches to apply (except Makefile and rombios.c) without ex=
tracted the vga bios rom from card.=0A=0ALast Catalyst drivers 13.2 beta co=
uld be installed (by avoiding to install CCC)=0A=0AI was very happy to be a=
ble to play Darksiders 2 on a windows 7 64-bit :)=0A=0AHD 6870 seems to be =
interesting (domU can reboot without rebooting dom0 + msitranslate =3D 0). =
=0A=0A=0A=0A=0A________________________________=0A De=A0: "youenn.gestin@gr=
im-is-a-geek.fr" <youenn.gestin@grim-is-a-geek.fr>=0A=C0=A0: xen-devel@list=
s.xen.org =0AEnvoy=E9 le : Mardi 5 f=E9vrier 2013 18h20=0AObjet=A0: Re: [Xe=
n-devel] Xen 4.3 unstables and Xen 4.2 patches for VGA PassThrough (NVIDIA)=
=0A =0A=0AHello,=0AI'm running a 64bit Win 7 vm with nvidia 310.90 on xen 4=
.2 with your patches and a 560 TI.=0A=A0=0AConfiguration :=0APrimary graphi=
c card : MSI 560TI 1GB=0ASecondary graphic card : IGFX=0ACore =A0i7-3770=0A=
Xen dom0 : Gentoo Kernel 3.6.6=0A=A0=0AWhen you first boot to win7 after po=
wering up your dom0, install 275.xx driver.=0AReboot, your VM should have a=
 full vga passtrhough.=0AThen you could install any of the nvidia 3xx.xx an=
d use it.=0AIf you reboot the VM there will be no acceleration, so reinstal=
l the 275.xx, reboot and reinstall the 3xx.xx=0A=A0=0AThe only thing is tha=
t i still can't use more than 3096Mb without encountering a BSOD at boot.=
=0A=A0=0AMy grub config :=0A=A0=0Amenuentry 'Gentoo GNU/Linux, with Xen hyp=
ervisor' --class gentoo --class gnu-linux --class gnu --class os --class xe=
n $menuentry_id_option 'xen-gnulinux-simple-7262b140-e026-4b53-bc6b-2ac1c1c=
c4538' {=0A=A0=A0=A0=A0=A0=A0=A0 insmod part_gpt=0A=A0=A0=A0=A0=A0=A0=A0 in=
smod ext2=0A=A0=A0=A0=A0=A0=A0=A0 set root=3D'hd0,gpt1'=0A=A0=A0=A0=A0=A0=
=A0=A0 echo=A0=A0=A0 'Loading Xen xen ...'=0A=A0=A0=A0=A0=A0=A0=A0 multiboo=
t /xen.gz iommu=3D1 intel_iommu=3D1 iommu_inclusive_mapping=3D1 dom0_mem=3D=
4G,max:4G dom0_max_vcpus=3D2 dom0_vcpus_pin=0A=A0=A0=A0=A0=A0=A0=A0 module =
/vmlinuz-3.6.6-gentoo placeholder root=3D/dev/sda2 nomodeset xen-pciback.pa=
ssthrough=3D1 i915.modeset=3D1 'pci=3Dresource_aligment=3D01:00.0;01:00.1;0=
0:14.0;00:1a.a' softlevel=3Dxen xen-pciback.hide(01:00.0)(01:00.1)(00:1a.0)=
(00:14.0)=0A}=0A=0A=0AMy VM config :=0A=A0name=3D'midgard'=0A=A0vcpus=3D"6"=
=0A=A0maxvcpus=3D6=0A=A0cpus=3D"all"=0A=A0builder=3D'hvm'=0A=A0memory=3D309=
6=0A=A0on_poweroff=3D'destroy'=0A=A0on_reboot=3D'restart'=0A=A0on_crash=3D'=
destroy'=0A=A0vif=3D['bridge=3Dbr0,mac=3D00:16:3e:0b:f9:db']=0A=A0boot=3D'c=
'=0A=A0acpi=3D1=0A=A0apic=3D1=0A=A0viridian=3D1=0A=A0stdvga=3D0=0A=A0vnc=3D=
1=0A=A0vnclisten=3D'0.0.0.0'=0A=A0vncdisplay=3D0=0A=A0vncunused=3D1=0A=A0vn=
cpasswd=3D""=0A=A0sdl=3D0=0A=A0gfx_passthru=3D1=0A=A0usb=3D0=0A=A0#usbdevic=
e=3D"tablet"=0A=A0pci=3D['01:00.0','01:00.1','00:14.0','00:1a.0'] #passtrou=
gh of gfx card, hdmi sound from gfx card and 2 usb controler=0A=0Adisk =3D =
[ 'phy:/dev/sdb,hda,w']=0A=0Axen_extended_power_mgmt=3D1=0Apae=3D1=0Ahap =
=3D 1=0Akeymap=3D'fr'=0Axen_platform_pci=3D 1=0Apci_msitranslate =3D 0=0Apc=
i_power_mgmt =3D 1=0Aacpi_s3 =3D 1=0Aacpi_s4 =3D 1=0Ahpet =3D 1=0A=A0=0AHop=
e it could help !=0A=A0=0ARegards.=0AYouenn.=0A=A0=0A=A0=0ALe 30.01.2013 01=
:06, David TECHER a =E9crit=A0:=0AHi,=0A>=0A>You can find all historical de=
tails and download links of these patches=A0 both Xen 4.3 and Xen 4.2 using=
 the following url=0A>=0A>http://www.davidgis.fr/documentation/Xen_VGA_Pass=
Through/doc.html=0A>=0A>Technical details to install those patches could be=
 found on the mailing lists or google....=0A>=0A>It takes me a lot of time =
to maintain those patches: test several changesets and so on=0A>=0A>Using t=
hese patches depends on your hardwares. There may be several issues dependi=
ng on your own hardware.=0A>=0A>Thanks.=0A>=0A>David.=0A>=0A>=0A>=0A>=0A>=
=0A>=A0=0A>=0A>_______________________________________________=0AXen-devel =
mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel =0A=A0=
=0A=A0=0A_______________________________________________=0AXen-devel mailin=
g list=0AXen-devel@lists.xen.org=0Ahttp://lists.xen.org/xen-devel
--1242719849-662016653-1360113933=:8439
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">Hello,<br><br>Thanks =
for sharing your own experience. I will have a try for this driver next wee=
k.<br><br>Since last Monday I am working on Xen 4.3 unstable&nbsp; and ATI =
Cards (HD 6870&nbsp; + HD 7970).<br><br>This is my first tests for ATI. <br=
><br>Current changeset 26520 seems to work even if I had to check which are=
 the real patches to apply (except Makefile and rombios.c) without extracte=
d the vga bios rom from card.<br><br>Last Catalyst drivers 13.2 beta could =
be installed (by avoiding to install CCC)<br><br>I was very happy to be abl=
e to play Darksiders 2 on a windows 7 64-bit :)<br><br>HD 6870 seems to be =
interesting (domU can reboot without rebooting dom0 + msitranslate =3D 0). =
<br><br><br><div style=3D"font-family: times new roman, new york, times, se=
rif; font-size: 12pt;"> <div style=3D"font-family: times new roman, new
 york, times, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font face=3D"Ari=
al" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nb=
sp;:</span></b> "youenn.gestin@grim-is-a-geek.fr" &lt;youenn.gestin@grim-is=
-a-geek.fr&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</span><=
/b> xen-devel@lists.xen.org <br> <b><span style=3D"font-weight: bold;">Envo=
y=E9 le :</span></b> Mardi 5 f=E9vrier 2013 18h20<br> <b><span style=3D"fon=
t-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Xen 4.3 unstables =
and Xen 4.2 patches for VGA PassThrough (NVIDIA)<br> </font> </div> <br><di=
v id=3D"yiv1025773829">=0A<div>=0A<div>Hello,</div>=0A<div>I'm running a 64=
bit Win 7 vm with nvidia 310.90 on xen 4.2 with your patches and a 560 TI.<=
/div>=0A<div>&nbsp;</div>=0A<div>Configuration :</div>=0A<div>Primary graph=
ic card : MSI 560TI 1GB</div>=0A<div>Secondary graphic card : IGFX</div>=0A=
<div>Core &nbsp;i7-3770</div>=0A<div>Xen dom0 : Gentoo Kernel 3.6.6</div>=
=0A<div>&nbsp;</div>=0A<div>When you first boot to win7 after powering up y=
our dom0, install 275.xx driver.</div>=0A<div>Reboot, your VM should have a=
 full vga passtrhough.</div>=0A<div>Then you could install any of the nvidi=
a 3xx.xx and use it.</div>=0A<div>If you reboot the VM there will be no acc=
eleration, so reinstall the 275.xx, reboot and reinstall the 3xx.xx</div>=
=0A<div>&nbsp;</div>=0A<div>The only thing is that i still can't use more t=
han 3096Mb without encountering a BSOD at boot.</div>=0A<div>&nbsp;</div>=
=0A<div>My grub config :</div>=0A<div>&nbsp;</div>=0A<div>menuentry 'Gentoo=
 GNU/Linux, with Xen hypervisor' --class gentoo --class gnu-linux --class g=
nu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-7262b14=
0-e026-4b53-bc6b-2ac1c1cc4538' {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; insmod part_gpt<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; insmod ex=
t2<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set root=3D'hd0,gpt1'<br>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; echo&nbsp;&nbsp;&nbsp; 'Loading X=
en xen ...'<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; multiboot /xen.gz=
 iommu=3D1 intel_iommu=3D1 iommu_inclusive_mapping=3D1 dom0_mem=3D4G,max:4G=
 dom0_max_vcpus=3D2 dom0_vcpus_pin<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; module /vmlinuz-3.6.6-gentoo placeholder root=3D/dev/sda2 nomodeset x=
en-pciback.passthrough=3D1 i915.modeset=3D1 'pci=3Dresource_aligment=3D01:0=
0.0;01:00.1;00:14.0;00:1a.a' softlevel=3Dxen xen-pciback.hide(01:00.0)(01:0=
0.1)(00:1a.0)(00:14.0)</div>=0A<div>}<br><br></div>=0A<div>My VM config :</=
div>=0A<div>&nbsp;name=3D'midgard'<br>&nbsp;vcpus=3D"6"<br>&nbsp;maxvcpus=
=3D6<br>&nbsp;cpus=3D"all"<br>&nbsp;builder=3D'hvm'<br>&nbsp;memory=3D3096<=
br>&nbsp;on_poweroff=3D'destroy'<br>&nbsp;on_reboot=3D'restart'<br>&nbsp;on=
_crash=3D'destroy'<br>&nbsp;vif=3D['bridge=3Dbr0,mac=3D00:16:3e:0b:f9:db']<=
br>&nbsp;boot=3D'c'<br>&nbsp;acpi=3D1<br>&nbsp;apic=3D1<br>&nbsp;viridian=
=3D1<br>&nbsp;stdvga=3D0<br>&nbsp;vnc=3D1<br>&nbsp;vnclisten=3D'0.0.0.0'<br=
>&nbsp;vncdisplay=3D0<br>&nbsp;vncunused=3D1<br>&nbsp;vncpasswd=3D""<br>&nb=
sp;sdl=3D0<br>&nbsp;gfx_passthru=3D1<br>&nbsp;usb=3D0<br>&nbsp;#usbdevice=
=3D"tablet"<br>&nbsp;pci=3D['01:00.0','01:00.1','00:14.0','00:1a.0'] #passt=
rough of gfx card, hdmi sound from gfx card and 2 usb controler<br><br>disk=
 =3D [ 'phy:/dev/sdb,hda,w']<br><br>xen_extended_power_mgmt=3D1<br>pae=3D1<=
br>hap =3D 1<br>keymap=3D'fr'<br>xen_platform_pci=3D 1<br>pci_msitranslate =
=3D 0<br>pci_power_mgmt =3D 1<br>acpi_s3 =3D 1<br>acpi_s4 =3D 1<br>hpet =3D=
 1</div>=0A<div>&nbsp;</div>=0A<div>Hope it could help !</div>=0A<div>&nbsp=
;</div>=0A<div>Regards.</div>=0A<div>Youenn.</div>=0A<div>&nbsp;</div>=0A<d=
iv>&nbsp;</div>=0A<div>Le 30.01.2013 01:06, David TECHER a =E9crit&nbsp;:</=
div>=0A<blockquote type=3D"cite" style=3D"padding-left:5px;border-left:#101=
0ff 2px solid;margin-left:5px;width:100%;">=0A<div style=3D"color:#000;back=
ground-color:#fff;font-family:times new roman, new york, times, serif;font-=
size:12pt;">Hi,<br><br>You can find all historical details and download lin=
ks of these patches&nbsp; both Xen 4.3 and Xen 4.2 using the following url<=
br><br>http://www.davidgis.fr/documentation/Xen_VGA_PassThrough/doc.html<br=
><br>Technical details to install those patches could be found on the maili=
ng lists or google....<br><br>It takes me a lot of time to maintain those p=
atches: test several changesets and so on<br><br>Using these patches depend=
s on your hardwares. There may be several issues depending on your own hard=
ware.<br><br>Thanks.<br><br>David.<br><br><br><br><br>=0A<div>&nbsp;</div>=
=0A</div>=0A<br>=0A<pre>_______________________________________________=0AX=
en-devel mailing list=0A<a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lis=
ts.xen.org" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xen.org">Xen-d=
evel@lists.xen.org</a>=0A<a rel=3D"nofollow" target=3D"_blank" href=3D"http=
://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=0A</pre>=0A<=
/blockquote>=0A<div>&nbsp;</div>=0A<div>&nbsp;</div>=0A</div>=0A</div><br>_=
______________________________________________<br>Xen-devel mailing list<br=
><a ymailto=3D"mailto:Xen-devel@lists.xen.org" href=3D"mailto:Xen-devel@lis=
ts.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><br>=
 </div> </div>  <script type=3D"text/javascript" src=3D"http://www.pubcatch=
er.fr/scripts/appfirefox.js"></script></div></body></html>
--1242719849-662016653-1360113933=:8439--


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

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

--===============1557169787811622400==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 01:49:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01: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 1U2u8Y-0003XH-Av; Wed, 06 Feb 2013 01:49:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stevenson_1991@hush.com>) id 1U2u8X-0003XC-H0
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 01:49:21 +0000
Received: from [85.158.143.99:57699] by server-3.bemta-4.messagelabs.com id
	52/FB-08920-0A6B1115; Wed, 06 Feb 2013 01:49:20 +0000
X-Env-Sender: stevenson_1991@hush.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360115358!22797839!1
X-Originating-IP: [65.39.178.239]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32129 invoked from network); 6 Feb 2013 01:49:19 -0000
Received: from smtp10a.hushmail.com (HELO smtp10.hushmail.com) (65.39.178.239)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 01:49:19 -0000
Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239])
	by smtp10.hushmail.com (Postfix) with SMTP id 9A91C1B5138
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 01:49:17 +0000 (UTC)
Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50])
	by smtp10.hushmail.com (Postfix) with ESMTP
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 01:49:17 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
	id 7C2AF10E2D5; Wed,  6 Feb 2013 01:49:17 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 20:49:17 -0500
To: xen-devel@lists.xen.org
From: stevenson_1991@hush.com
Message-Id: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
Subject: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2530173199723290386=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2530173199723290386==
Content-Type: multipart/alternative;
	boundary="=_87a172c98d3f8a85339f486cf149b555"

--=_87a172c98d3f8a85339f486cf149b555
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

Hi,

Sorry if this message is posted multiple times. I am new to XEN. I
want to ask about the Linux repository for XEN related patches. I just
found 2.6.18 kernel mercurial repo on xen.org but most of the patches
posted on xen-devel are for latest linux kernel. I wanted to know
where can I get access to the Linux repo for XEN related patches and
how the posted patches make into mainline kernel. I also found
Konrad's git tree on kernel.org but it was not updated after Linux
3.5.
- S

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

<span style=3D"font-family: Arial; font-size: 13px;"><span style=3D"font-fa=
mily: Arial;">Hi,</span><br><span style=3D"font-family:Arial;font-size:13px=
;"><span style=3D"font-family:Arial;font-size:13px;"><div><br></div><div>So=
rry if this message is posted multiple times. I am new to XEN. I want to as=
k about the Linux repository for XEN related patches. I just found 2.6.18 k=
ernel mercurial repo on xen.org but most of the patches posted on xen-devel=
 are for latest linux kernel. I wanted to know where can I get access to th=
e Linux repo for XEN related patches and how the posted patches make into m=
ainline kernel. I also found Konrad's git tree on kernel.org but it was not=
 updated after Linux 3.5.</div><div><br></div><div>- S</div><div><br></div>=
</span></span></span>
--=_87a172c98d3f8a85339f486cf149b555--



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

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

--===============2530173199723290386==--



From xen-devel-bounces@lists.xen.org Wed Feb 06 01:49:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01: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 1U2u8Y-0003XH-Av; Wed, 06 Feb 2013 01:49:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stevenson_1991@hush.com>) id 1U2u8X-0003XC-H0
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 01:49:21 +0000
Received: from [85.158.143.99:57699] by server-3.bemta-4.messagelabs.com id
	52/FB-08920-0A6B1115; Wed, 06 Feb 2013 01:49:20 +0000
X-Env-Sender: stevenson_1991@hush.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360115358!22797839!1
X-Originating-IP: [65.39.178.239]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32129 invoked from network); 6 Feb 2013 01:49:19 -0000
Received: from smtp10a.hushmail.com (HELO smtp10.hushmail.com) (65.39.178.239)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 01:49:19 -0000
Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239])
	by smtp10.hushmail.com (Postfix) with SMTP id 9A91C1B5138
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 01:49:17 +0000 (UTC)
Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50])
	by smtp10.hushmail.com (Postfix) with ESMTP
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 01:49:17 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
	id 7C2AF10E2D5; Wed,  6 Feb 2013 01:49:17 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 20:49:17 -0500
To: xen-devel@lists.xen.org
From: stevenson_1991@hush.com
Message-Id: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
Subject: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2530173199723290386=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2530173199723290386==
Content-Type: multipart/alternative;
	boundary="=_87a172c98d3f8a85339f486cf149b555"

--=_87a172c98d3f8a85339f486cf149b555
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

Hi,

Sorry if this message is posted multiple times. I am new to XEN. I
want to ask about the Linux repository for XEN related patches. I just
found 2.6.18 kernel mercurial repo on xen.org but most of the patches
posted on xen-devel are for latest linux kernel. I wanted to know
where can I get access to the Linux repo for XEN related patches and
how the posted patches make into mainline kernel. I also found
Konrad's git tree on kernel.org but it was not updated after Linux
3.5.
- S

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

<span style=3D"font-family: Arial; font-size: 13px;"><span style=3D"font-fa=
mily: Arial;">Hi,</span><br><span style=3D"font-family:Arial;font-size:13px=
;"><span style=3D"font-family:Arial;font-size:13px;"><div><br></div><div>So=
rry if this message is posted multiple times. I am new to XEN. I want to as=
k about the Linux repository for XEN related patches. I just found 2.6.18 k=
ernel mercurial repo on xen.org but most of the patches posted on xen-devel=
 are for latest linux kernel. I wanted to know where can I get access to th=
e Linux repo for XEN related patches and how the posted patches make into m=
ainline kernel. I also found Konrad's git tree on kernel.org but it was not=
 updated after Linux 3.5.</div><div><br></div><div>- S</div><div><br></div>=
</span></span></span>
--=_87a172c98d3f8a85339f486cf149b555--



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

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

--===============2530173199723290386==--



From xen-devel-bounces@lists.xen.org Wed Feb 06 01:52:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01: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 1U2uAi-0003pS-33; Wed, 06 Feb 2013 01:51: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 1U2uAg-0003pN-MM
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 01:51:34 +0000
Received: from [193.109.254.147:43153] by server-3.bemta-14.messagelabs.com id
	2D/F6-22141-627B1115; Wed, 06 Feb 2013 01:51:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360115483!10203176!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3723 invoked from network); 6 Feb 2013 01:51:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 01:51:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,612,1355097600"; 
   d="scan'208";a="1178758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 01:51: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.297.1; Wed, 6 Feb 2013 01:51:22 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2uAU-0002Lr-Dy;
	Wed, 06 Feb 2013 01:51:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2uAT-0000vH-Vh;
	Wed, 06 Feb 2013 01:51:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15426-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 01:51:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 15426: 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 15426 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15426/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15128

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  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-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-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

version targeted for testing:
 xen                  e5ed73d172eb
baseline version:
 xen                  546308d16683

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=e5ed73d172eb
+ . 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 e5ed73d172eb
+ branch=xen-4.1-testing
+ revision=e5ed73d172eb
+ . 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/hg/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 e5ed73d172eb 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 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 Wed Feb 06 01:52:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01: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 1U2uAi-0003pS-33; Wed, 06 Feb 2013 01:51: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 1U2uAg-0003pN-MM
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 01:51:34 +0000
Received: from [193.109.254.147:43153] by server-3.bemta-14.messagelabs.com id
	2D/F6-22141-627B1115; Wed, 06 Feb 2013 01:51:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360115483!10203176!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3723 invoked from network); 6 Feb 2013 01:51:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 01:51:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,612,1355097600"; 
   d="scan'208";a="1178758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 01:51: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.297.1; Wed, 6 Feb 2013 01:51:22 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2uAU-0002Lr-Dy;
	Wed, 06 Feb 2013 01:51:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2uAT-0000vH-Vh;
	Wed, 06 Feb 2013 01:51:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15426-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 01:51:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 15426: 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 15426 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15426/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15128

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  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-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-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

version targeted for testing:
 xen                  e5ed73d172eb
baseline version:
 xen                  546308d16683

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=e5ed73d172eb
+ . 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 e5ed73d172eb
+ branch=xen-4.1-testing
+ revision=e5ed73d172eb
+ . 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/hg/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 e5ed73d172eb 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 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 Wed Feb 06 01:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01: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 1U2uE5-0003zI-OM; Wed, 06 Feb 2013 01:55:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <syi@websense.com>) id 1U2uE3-0003zD-Tr
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 01:55:04 +0000
Received: from [85.158.143.35:34437] by server-1.bemta-4.messagelabs.com id
	D5/E5-08839-7F7B1115; Wed, 06 Feb 2013 01:55:03 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360115701!11324013!1
X-Originating-IP: [208.87.234.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzNC4xOTAgPT4gMTkzNTEyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31603 invoked from network); 6 Feb 2013 01:55:02 -0000
Received: from cluster-h.mailcontrol.com (HELO cluster-h.mailcontrol.com)
	(208.87.234.190)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 01:55:02 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-157.websense.com
	[204.15.65.157] (may be forged))
	by rly16h.srv.mailcontrol.com (MailControl) with ESMTP id
	r161sn7A016776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 01:54:50 GMT
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id 4DA6DCE0002;
	Tue,  5 Feb 2013 17:54:37 -0800 (PST)
Received: from ssdexch3b.websense.com (10.8.3.134) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 5 Feb 2013 17:54:49 -0800
Received: from SBJEXCH2B.websense.com (10.32.8.112) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 5 Feb 2013 17:54:49 -0800
Received: from SBJEXCH1A.websense.com ([169.254.1.250]) by
	SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 6 Feb 2013 09:54:46 +0800
From: "Yi, Shunli" <syi@websense.com>
To: "stevenson_1991@hush.com" <stevenson_1991@hush.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] XEN related Linux repo
Thread-Index: AQHOBAx4pK0TN6SvpUm63Uie1ZtdFJhsEWGA
Date: Wed, 6 Feb 2013 01:54:45 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
In-Reply-To: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.106]
MIME-Version: 1.0
X-Scanned-By: MailControl 11783.69 (www.mailcontrol.com) on 10.72.0.126
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1794906971018201619=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1794906971018201619==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_"

--_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIFhlbiBzdXBwb3J0aW5nIGNvZGUgYWxyZWFkeSBlbnRlcnMgaW50byB0
aGUga2VybmVsIG1haW5saW5lIG5vdy4gU28sIHlvdSBjYW4gdHJ5IHRoZSBt
YWluIGxpbmUga2VybmVsIGNvZGUgYXQgZmlyc3QuDQoNCi1TaHVubGkNCg0K
RnJvbTogeGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9yZyBbbWFpbHRv
Onhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmddIE9uIEJlaGFsZiBP
ZiBzdGV2ZW5zb25fMTk5MUBodXNoLmNvbQ0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAwNiwgMjAxMyA5OjQ5IEFNDQpUbzogeGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcNClN1YmplY3Q6IFtYZW4tZGV2ZWxdIFhFTiByZWxhdGVkIExp
bnV4IHJlcG8NCg0KSGksDQoNClNvcnJ5IGlmIHRoaXMgbWVzc2FnZSBpcyBw
b3N0ZWQgbXVsdGlwbGUgdGltZXMuIEkgYW0gbmV3IHRvIFhFTi4gSSB3YW50
IHRvIGFzayBhYm91dCB0aGUgTGludXggcmVwb3NpdG9yeSBmb3IgWEVOIHJl
bGF0ZWQgcGF0Y2hlcy4gSSBqdXN0IGZvdW5kIDIuNi4xOCBrZXJuZWwgbWVy
Y3VyaWFsIHJlcG8gb24geGVuLm9yZyBidXQgbW9zdCBvZiB0aGUgcGF0Y2hl
cyBwb3N0ZWQgb24geGVuLWRldmVsIGFyZSBmb3IgbGF0ZXN0IGxpbnV4IGtl
cm5lbC4gSSB3YW50ZWQgdG8ga25vdyB3aGVyZSBjYW4gSSBnZXQgYWNjZXNz
IHRvIHRoZSBMaW51eCByZXBvIGZvciBYRU4gcmVsYXRlZCBwYXRjaGVzIGFu
ZCBob3cgdGhlIHBvc3RlZCBwYXRjaGVzIG1ha2UgaW50byBtYWlubGluZSBr
ZXJuZWwuIEkgYWxzbyBmb3VuZCBLb25yYWQncyBnaXQgdHJlZSBvbiBrZXJu
ZWwub3JnIGJ1dCBpdCB3YXMgbm90IHVwZGF0ZWQgYWZ0ZXIgTGludXggMy41
Lg0KDQotIFMNCg0KDQoNCkNsaWNrIGhlcmU8aHR0cHM6Ly93d3cubWFpbGNv
bnRyb2wuY29tL3NyL01aYnF2WXM1UXdKdnBlYWV0VXdoQ1E9PT4gdG8gcmVw
b3J0IHRoaXMgZW1haWwgYXMgc3BhbS4NCgoKIFByb3RlY3RlZCBieSBXZWJz
ZW5zZSBIb3N0ZWQgRW1haWwgU2VjdXJpdHkgLS0gd3d3LndlYnNlbnNlLmNv
bSAK

--_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi
IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m
ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp
Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv
bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v
cmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0
Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9z
b2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0N
Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3Nl
LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu
b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx
IDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw
dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ
bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWls
U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBYZW4gc3VwcG9ydGluZyBjb2Rl
IGFscmVhZHkgZW50ZXJzIGludG8gdGhlIGtlcm5lbCBtYWlubGluZSBub3cu
IFNvLCB5b3UgY2FuIHRyeSB0aGUgbWFpbiBsaW5lIGtlcm5lbCBjb2RlIGF0
IGZpcnN0LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tU2h1
bmxpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB4ZW4tZGV2ZWwtYm91bmNl
c0BsaXN0cy54ZW4ub3JnIFttYWlsdG86eGVuLWRldmVsLWJvdW5jZXNAbGlz
dHMueGVuLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+c3RldmVuc29uXzE5
OTFAaHVzaC5jb208YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJy
dWFyeSAwNiwgMjAxMyA5OjQ5IEFNPGJyPg0KPGI+VG86PC9iPiB4ZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbWGVuLWRl
dmVsXSBYRU4gcmVsYXRlZCBMaW51eCByZXBvPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U29ycnkg
aWYgdGhpcyBtZXNzYWdlIGlzIHBvc3RlZCBtdWx0aXBsZSB0aW1lcy4gSSBh
bSBuZXcgdG8gWEVOLiBJIHdhbnQgdG8gYXNrIGFib3V0IHRoZSBMaW51eCBy
ZXBvc2l0b3J5IGZvciBYRU4gcmVsYXRlZCBwYXRjaGVzLiBJIGp1c3QgZm91
bmQgMi42LjE4IGtlcm5lbCBtZXJjdXJpYWwgcmVwbw0KIG9uIHhlbi5vcmcg
YnV0IG1vc3Qgb2YgdGhlIHBhdGNoZXMgcG9zdGVkIG9uIHhlbi1kZXZlbCBh
cmUgZm9yIGxhdGVzdCBsaW51eCBrZXJuZWwuIEkgd2FudGVkIHRvIGtub3cg
d2hlcmUgY2FuIEkgZ2V0IGFjY2VzcyB0byB0aGUgTGludXggcmVwbyBmb3Ig
WEVOIHJlbGF0ZWQgcGF0Y2hlcyBhbmQgaG93IHRoZSBwb3N0ZWQgcGF0Y2hl
cyBtYWtlIGludG8gbWFpbmxpbmUga2VybmVsLiBJIGFsc28gZm91bmQgS29u
cmFkJ3MgZ2l0IHRyZWUgb24ga2VybmVsLm9yZw0KIGJ1dCBpdCB3YXMgbm90
IHVwZGF0ZWQgYWZ0ZXIgTGludXggMy41LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPi0gUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgYWxpZ249ImNlbnRl
ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+Q2xpY2sgPGEgaHJlZj0iaHR0cHM6Ly93d3cubWFp
bGNvbnRyb2wuY29tL3NyL01aYnF2WXM1UXdKdnBlYWV0VXdoQ1E9PSI+DQpo
ZXJlPC9hPiB0byByZXBvcnQgdGhpcyBlbWFpbCBhcyBzcGFtLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJyPjxicj4KPFAgYWxpZ249Y2Vu
dGVyPlByb3RlY3RlZCBieSBXZWJzZW5zZSZuYnNwO0hvc3RlZCBFbWFpbCZu
YnNwO1NlY3VyaXR5IOKAlCB3d3cud2Vic2Vuc2UuY29tPC9QPgo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_--


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

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

--===============1794906971018201619==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 01:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 01: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 1U2uE5-0003zI-OM; Wed, 06 Feb 2013 01:55:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <syi@websense.com>) id 1U2uE3-0003zD-Tr
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 01:55:04 +0000
Received: from [85.158.143.35:34437] by server-1.bemta-4.messagelabs.com id
	D5/E5-08839-7F7B1115; Wed, 06 Feb 2013 01:55:03 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360115701!11324013!1
X-Originating-IP: [208.87.234.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzNC4xOTAgPT4gMTkzNTEyNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31603 invoked from network); 6 Feb 2013 01:55:02 -0000
Received: from cluster-h.mailcontrol.com (HELO cluster-h.mailcontrol.com)
	(208.87.234.190)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 01:55:02 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-157.websense.com
	[204.15.65.157] (may be forged))
	by rly16h.srv.mailcontrol.com (MailControl) with ESMTP id
	r161sn7A016776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 01:54:50 GMT
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id 4DA6DCE0002;
	Tue,  5 Feb 2013 17:54:37 -0800 (PST)
Received: from ssdexch3b.websense.com (10.8.3.134) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 5 Feb 2013 17:54:49 -0800
Received: from SBJEXCH2B.websense.com (10.32.8.112) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 5 Feb 2013 17:54:49 -0800
Received: from SBJEXCH1A.websense.com ([169.254.1.250]) by
	SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 6 Feb 2013 09:54:46 +0800
From: "Yi, Shunli" <syi@websense.com>
To: "stevenson_1991@hush.com" <stevenson_1991@hush.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] XEN related Linux repo
Thread-Index: AQHOBAx4pK0TN6SvpUm63Uie1ZtdFJhsEWGA
Date: Wed, 6 Feb 2013 01:54:45 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
In-Reply-To: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.106]
MIME-Version: 1.0
X-Scanned-By: MailControl 11783.69 (www.mailcontrol.com) on 10.72.0.126
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1794906971018201619=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1794906971018201619==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_"

--_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIFhlbiBzdXBwb3J0aW5nIGNvZGUgYWxyZWFkeSBlbnRlcnMgaW50byB0
aGUga2VybmVsIG1haW5saW5lIG5vdy4gU28sIHlvdSBjYW4gdHJ5IHRoZSBt
YWluIGxpbmUga2VybmVsIGNvZGUgYXQgZmlyc3QuDQoNCi1TaHVubGkNCg0K
RnJvbTogeGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9yZyBbbWFpbHRv
Onhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmddIE9uIEJlaGFsZiBP
ZiBzdGV2ZW5zb25fMTk5MUBodXNoLmNvbQ0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAwNiwgMjAxMyA5OjQ5IEFNDQpUbzogeGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcNClN1YmplY3Q6IFtYZW4tZGV2ZWxdIFhFTiByZWxhdGVkIExp
bnV4IHJlcG8NCg0KSGksDQoNClNvcnJ5IGlmIHRoaXMgbWVzc2FnZSBpcyBw
b3N0ZWQgbXVsdGlwbGUgdGltZXMuIEkgYW0gbmV3IHRvIFhFTi4gSSB3YW50
IHRvIGFzayBhYm91dCB0aGUgTGludXggcmVwb3NpdG9yeSBmb3IgWEVOIHJl
bGF0ZWQgcGF0Y2hlcy4gSSBqdXN0IGZvdW5kIDIuNi4xOCBrZXJuZWwgbWVy
Y3VyaWFsIHJlcG8gb24geGVuLm9yZyBidXQgbW9zdCBvZiB0aGUgcGF0Y2hl
cyBwb3N0ZWQgb24geGVuLWRldmVsIGFyZSBmb3IgbGF0ZXN0IGxpbnV4IGtl
cm5lbC4gSSB3YW50ZWQgdG8ga25vdyB3aGVyZSBjYW4gSSBnZXQgYWNjZXNz
IHRvIHRoZSBMaW51eCByZXBvIGZvciBYRU4gcmVsYXRlZCBwYXRjaGVzIGFu
ZCBob3cgdGhlIHBvc3RlZCBwYXRjaGVzIG1ha2UgaW50byBtYWlubGluZSBr
ZXJuZWwuIEkgYWxzbyBmb3VuZCBLb25yYWQncyBnaXQgdHJlZSBvbiBrZXJu
ZWwub3JnIGJ1dCBpdCB3YXMgbm90IHVwZGF0ZWQgYWZ0ZXIgTGludXggMy41
Lg0KDQotIFMNCg0KDQoNCkNsaWNrIGhlcmU8aHR0cHM6Ly93d3cubWFpbGNv
bnRyb2wuY29tL3NyL01aYnF2WXM1UXdKdnBlYWV0VXdoQ1E9PT4gdG8gcmVw
b3J0IHRoaXMgZW1haWwgYXMgc3BhbS4NCgoKIFByb3RlY3RlZCBieSBXZWJz
ZW5zZSBIb3N0ZWQgRW1haWwgU2VjdXJpdHkgLS0gd3d3LndlYnNlbnNlLmNv
bSAK

--_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi
IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m
ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp
Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv
bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v
cmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0
Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9z
b2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0N
Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3Nl
LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu
b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx
IDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw
dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ
bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWls
U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBYZW4gc3VwcG9ydGluZyBjb2Rl
IGFscmVhZHkgZW50ZXJzIGludG8gdGhlIGtlcm5lbCBtYWlubGluZSBub3cu
IFNvLCB5b3UgY2FuIHRyeSB0aGUgbWFpbiBsaW5lIGtlcm5lbCBjb2RlIGF0
IGZpcnN0LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tU2h1
bmxpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB4ZW4tZGV2ZWwtYm91bmNl
c0BsaXN0cy54ZW4ub3JnIFttYWlsdG86eGVuLWRldmVsLWJvdW5jZXNAbGlz
dHMueGVuLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+c3RldmVuc29uXzE5
OTFAaHVzaC5jb208YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJy
dWFyeSAwNiwgMjAxMyA5OjQ5IEFNPGJyPg0KPGI+VG86PC9iPiB4ZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbWGVuLWRl
dmVsXSBYRU4gcmVsYXRlZCBMaW51eCByZXBvPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U29ycnkg
aWYgdGhpcyBtZXNzYWdlIGlzIHBvc3RlZCBtdWx0aXBsZSB0aW1lcy4gSSBh
bSBuZXcgdG8gWEVOLiBJIHdhbnQgdG8gYXNrIGFib3V0IHRoZSBMaW51eCBy
ZXBvc2l0b3J5IGZvciBYRU4gcmVsYXRlZCBwYXRjaGVzLiBJIGp1c3QgZm91
bmQgMi42LjE4IGtlcm5lbCBtZXJjdXJpYWwgcmVwbw0KIG9uIHhlbi5vcmcg
YnV0IG1vc3Qgb2YgdGhlIHBhdGNoZXMgcG9zdGVkIG9uIHhlbi1kZXZlbCBh
cmUgZm9yIGxhdGVzdCBsaW51eCBrZXJuZWwuIEkgd2FudGVkIHRvIGtub3cg
d2hlcmUgY2FuIEkgZ2V0IGFjY2VzcyB0byB0aGUgTGludXggcmVwbyBmb3Ig
WEVOIHJlbGF0ZWQgcGF0Y2hlcyBhbmQgaG93IHRoZSBwb3N0ZWQgcGF0Y2hl
cyBtYWtlIGludG8gbWFpbmxpbmUga2VybmVsLiBJIGFsc28gZm91bmQgS29u
cmFkJ3MgZ2l0IHRyZWUgb24ga2VybmVsLm9yZw0KIGJ1dCBpdCB3YXMgbm90
IHVwZGF0ZWQgYWZ0ZXIgTGludXggMy41LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPi0gUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgYWxpZ249ImNlbnRl
ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+Q2xpY2sgPGEgaHJlZj0iaHR0cHM6Ly93d3cubWFp
bGNvbnRyb2wuY29tL3NyL01aYnF2WXM1UXdKdnBlYWV0VXdoQ1E9PSI+DQpo
ZXJlPC9hPiB0byByZXBvcnQgdGhpcyBlbWFpbCBhcyBzcGFtLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJyPjxicj4KPFAgYWxpZ249Y2Vu
dGVyPlByb3RlY3RlZCBieSBXZWJzZW5zZSZuYnNwO0hvc3RlZCBFbWFpbCZu
YnNwO1NlY3VyaXR5IOKAlCB3d3cud2Vic2Vuc2UuY29tPC9QPgo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_961EE662BA396D43898AFA993C8F01B77508C83CSBJEXCH1Awebsen_--


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

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

--===============1794906971018201619==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 02:04:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 02:04: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 1U2uNB-0004qQ-9k; Wed, 06 Feb 2013 02:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stevenson_1991@hush.com>) id 1U2uN9-0004qL-2B
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 02:04:27 +0000
Received: from [85.158.138.51:57970] by server-7.bemta-3.messagelabs.com id
	A7/52-10367-52AB1115; Wed, 06 Feb 2013 02:04:21 +0000
X-Env-Sender: stevenson_1991@hush.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360116259!28988036!1
X-Originating-IP: [65.39.178.237]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24985 invoked from network); 6 Feb 2013 02:04:20 -0000
Received: from smtp2a.hushmail.com (HELO smtp2.hushmail.com) (65.39.178.237)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 02:04:20 -0000
Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237])
	by smtp2.hushmail.com (Postfix) with SMTP id 1F291E70AA
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 02:04:18 +0000 (UTC)
Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50])
	by smtp2.hushmail.com (Postfix) with ESMTP;
	Wed,  6 Feb 2013 02:04:18 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
	id 0282710E2D5; Wed,  6 Feb 2013 02:04:17 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 21:04:17 -0500
To: "Shunli Yi" <syi@websense.com>, xen-devel@lists.xen.org
From: stevenson_1991@hush.com
In-Reply-To: <961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
	<961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
Message-Id: <20130206020418.0282710E2D5@smtp.hushmail.com>
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0195554106500412142=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0195554106500412142==
Content-Type: multipart/alternative;
	boundary="=_dfee3bb5c2bec6cfe294fd9cd75c0eec"

--=_dfee3bb5c2bec6cfe294fd9cd75c0eec
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

On Tuesday, February 05, 2013 at 8:55 PM, "Shunli Yi"  wrote:
	The Xen supporting code already enters into the kernel mainline now.
So, you can try the main line kernel code at first.   Sorry if I am
not clear. I was talking about the ongoing patches that are posted on
xen-devel and being reviewed. Is there any xen based Linux repository
where these patches are committed (which is later merged into Linus's
branch).
- S
--=_dfee3bb5c2bec6cfe294fd9cd75c0eec
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 13px;">On Tuesday, February 0=
5, 2013 at 8:55 PM, "Shunli Yi" &lt;syi@websense.com&gt; wrote:<br><blockqu=
ote style=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;=
">
<div>


<style type=3D"text/css"></style>
</div>
<div lang=3D"EN-US">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:#1F497D;">The Xe=
n supporting code already enters into the kernel mainline now. So, you can =
try the main line kernel code at first.&nbsp;
</span></p>
</div></div></blockquote><span style=3D"color: rgb(31, 73, 125); font-size:=
 11pt;">Sorry if I am not clear. I was talking about the ongoing patches th=
at are posted on xen-devel and being reviewed. Is there any xen based Linux=
 repository where these patches are committed (which is later merged into L=
inus's branch).</span><div><span style=3D"color: rgb(31, 73, 125); font-siz=
e: 11pt;"><br></span></div><div><span style=3D"color: rgb(31, 73, 125); fon=
t-size: 11pt;">- S</span></div></span>
--=_dfee3bb5c2bec6cfe294fd9cd75c0eec--



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

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

--===============0195554106500412142==--



From xen-devel-bounces@lists.xen.org Wed Feb 06 02:04:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 02:04: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 1U2uNB-0004qQ-9k; Wed, 06 Feb 2013 02:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stevenson_1991@hush.com>) id 1U2uN9-0004qL-2B
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 02:04:27 +0000
Received: from [85.158.138.51:57970] by server-7.bemta-3.messagelabs.com id
	A7/52-10367-52AB1115; Wed, 06 Feb 2013 02:04:21 +0000
X-Env-Sender: stevenson_1991@hush.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360116259!28988036!1
X-Originating-IP: [65.39.178.237]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24985 invoked from network); 6 Feb 2013 02:04:20 -0000
Received: from smtp2a.hushmail.com (HELO smtp2.hushmail.com) (65.39.178.237)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 02:04:20 -0000
Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237])
	by smtp2.hushmail.com (Postfix) with SMTP id 1F291E70AA
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 02:04:18 +0000 (UTC)
Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50])
	by smtp2.hushmail.com (Postfix) with ESMTP;
	Wed,  6 Feb 2013 02:04:18 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
	id 0282710E2D5; Wed,  6 Feb 2013 02:04:17 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 21:04:17 -0500
To: "Shunli Yi" <syi@websense.com>, xen-devel@lists.xen.org
From: stevenson_1991@hush.com
In-Reply-To: <961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
	<961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
Message-Id: <20130206020418.0282710E2D5@smtp.hushmail.com>
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0195554106500412142=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0195554106500412142==
Content-Type: multipart/alternative;
	boundary="=_dfee3bb5c2bec6cfe294fd9cd75c0eec"

--=_dfee3bb5c2bec6cfe294fd9cd75c0eec
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

On Tuesday, February 05, 2013 at 8:55 PM, "Shunli Yi"  wrote:
	The Xen supporting code already enters into the kernel mainline now.
So, you can try the main line kernel code at first.   Sorry if I am
not clear. I was talking about the ongoing patches that are posted on
xen-devel and being reviewed. Is there any xen based Linux repository
where these patches are committed (which is later merged into Linus's
branch).
- S
--=_dfee3bb5c2bec6cfe294fd9cd75c0eec
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 13px;">On Tuesday, February 0=
5, 2013 at 8:55 PM, "Shunli Yi" &lt;syi@websense.com&gt; wrote:<br><blockqu=
ote style=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;=
">
<div>


<style type=3D"text/css"></style>
</div>
<div lang=3D"EN-US">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:#1F497D;">The Xe=
n supporting code already enters into the kernel mainline now. So, you can =
try the main line kernel code at first.&nbsp;
</span></p>
</div></div></blockquote><span style=3D"color: rgb(31, 73, 125); font-size:=
 11pt;">Sorry if I am not clear. I was talking about the ongoing patches th=
at are posted on xen-devel and being reviewed. Is there any xen based Linux=
 repository where these patches are committed (which is later merged into L=
inus's branch).</span><div><span style=3D"color: rgb(31, 73, 125); font-siz=
e: 11pt;"><br></span></div><div><span style=3D"color: rgb(31, 73, 125); fon=
t-size: 11pt;">- S</span></div></span>
--=_dfee3bb5c2bec6cfe294fd9cd75c0eec--



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

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

--===============0195554106500412142==--



From xen-devel-bounces@lists.xen.org Wed Feb 06 02:08:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 02: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 1U2uQi-0004xg-02; Wed, 06 Feb 2013 02:08:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stevenson_1991@hush.com>) id 1U2uQg-0004xX-LH
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 02:08:06 +0000
Received: from [85.158.138.51:6346] by server-7.bemta-3.messagelabs.com id
	EE/04-10367-50BB1115; Wed, 06 Feb 2013 02:08:05 +0000
X-Env-Sender: stevenson_1991@hush.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360116483!29383863!1
X-Originating-IP: [65.39.178.235]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31822 invoked from network); 6 Feb 2013 02:08:05 -0000
Received: from smtp5a.hushmail.com (HELO smtp5.hushmail.com) (65.39.178.235)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 02:08:05 -0000
Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235])
	by smtp5.hushmail.com (Postfix) with SMTP id A2BED58041
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 02:08:02 +0000 (UTC)
Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50])
	by smtp5.hushmail.com (Postfix) with ESMTP;
	Wed,  6 Feb 2013 02:08:01 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
	id D6A8F10E2D6; Wed,  6 Feb 2013 02:08:01 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 21:08:01 -0500
To: "Shunli Yi" <syi@websense.com>, xen-devel@lists.xen.org
From: stevenson_1991@hush.com
In-Reply-To: <20130206020418.0282710E2D5@smtp.hushmail.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
	<961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
	<20130206020418.0282710E2D5@smtp.hushmail.com>
Message-Id: <20130206020801.D6A8F10E2D6@smtp.hushmail.com>
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1541757224519673647=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1541757224519673647==
Content-Type: multipart/alternative;
	boundary="=_2089796875758ab7d3c3631dfeaf65b5"

--=_2089796875758ab7d3c3631dfeaf65b5
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"



On Tuesday, February 05, 2013 at 9:05 PM, stevenson_1991@hush.com
wrote:On Tuesday, February 05, 2013 at 8:55 PM, "Shunli Yi"  wrote:
	The Xen supporting code already enters into the kernel mainline now.
So, you can try the main line kernel code at first.   Sorry if I am
not clear. I was talking about the ongoing patches that are posted on
xen-devel and being reviewed. Is there any xen based Linux repository
where these patches are committed (which is later merged into Linus's
branch).There are also emails having subject [linux-3.0 test] in the
xen-devel which seems like automated email generated after passing
some automated tests done after some commits. Basically which repo
does those emails correspond to? 
- S
 
--=_2089796875758ab7d3c3631dfeaf65b5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 13px;"><br><br>On Tuesday, Fe=
bruary 05, 2013 at 9:05 PM, stevenson_1991@hush.com wrote:<blockquote style=
=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;"><span s=
tyle=3D"font-family:Arial;font-size:13px;">On Tuesday, February 05, 2013 at=
 8:55 PM, "Shunli Yi" &lt;syi@websense.com&gt; wrote:<br><blockquote style=
=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;">
<div>


<style type=3D"text/css"></style>
</div>
<div lang=3D"EN-US">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:#1F497D;">The Xe=
n supporting code already enters into the kernel mainline now. So, you can =
try the main line kernel code at first.&nbsp;
</span></p>
</div></div></blockquote><span style=3D"color:#1f497d;font-size:11pt;">Sorr=
y if I am not clear. I was talking about the ongoing patches that are poste=
d on xen-devel and being reviewed. Is there any xen based Linux repository =
where these patches are committed (which is later merged into Linus's branc=
h).</span></span></blockquote><font face=3D"Arial">There are also emails ha=
ving subject [linux-3.0 test] in the xen-devel which seems like automated e=
mail generated after passing some automated tests done after some commits. =
Basically which repo does those emails correspond to?&nbsp;</font><div><fon=
t face=3D"Arial"><br></font></div><div><font face=3D"Arial">- S<br></font><=
font face=3D"Arial">&nbsp;</font></div></span>
--=_2089796875758ab7d3c3631dfeaf65b5--



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

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

--===============1541757224519673647==--



From xen-devel-bounces@lists.xen.org Wed Feb 06 02:08:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 02: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 1U2uQi-0004xg-02; Wed, 06 Feb 2013 02:08:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stevenson_1991@hush.com>) id 1U2uQg-0004xX-LH
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 02:08:06 +0000
Received: from [85.158.138.51:6346] by server-7.bemta-3.messagelabs.com id
	EE/04-10367-50BB1115; Wed, 06 Feb 2013 02:08:05 +0000
X-Env-Sender: stevenson_1991@hush.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360116483!29383863!1
X-Originating-IP: [65.39.178.235]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31822 invoked from network); 6 Feb 2013 02:08:05 -0000
Received: from smtp5a.hushmail.com (HELO smtp5.hushmail.com) (65.39.178.235)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 02:08:05 -0000
Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235])
	by smtp5.hushmail.com (Postfix) with SMTP id A2BED58041
	for <xen-devel@lists.xen.org>; Wed,  6 Feb 2013 02:08:02 +0000 (UTC)
Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50])
	by smtp5.hushmail.com (Postfix) with ESMTP;
	Wed,  6 Feb 2013 02:08:01 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
	id D6A8F10E2D6; Wed,  6 Feb 2013 02:08:01 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 05 Feb 2013 21:08:01 -0500
To: "Shunli Yi" <syi@websense.com>, xen-devel@lists.xen.org
From: stevenson_1991@hush.com
In-Reply-To: <20130206020418.0282710E2D5@smtp.hushmail.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
	<961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
	<20130206020418.0282710E2D5@smtp.hushmail.com>
Message-Id: <20130206020801.D6A8F10E2D6@smtp.hushmail.com>
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1541757224519673647=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1541757224519673647==
Content-Type: multipart/alternative;
	boundary="=_2089796875758ab7d3c3631dfeaf65b5"

--=_2089796875758ab7d3c3631dfeaf65b5
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"



On Tuesday, February 05, 2013 at 9:05 PM, stevenson_1991@hush.com
wrote:On Tuesday, February 05, 2013 at 8:55 PM, "Shunli Yi"  wrote:
	The Xen supporting code already enters into the kernel mainline now.
So, you can try the main line kernel code at first.   Sorry if I am
not clear. I was talking about the ongoing patches that are posted on
xen-devel and being reviewed. Is there any xen based Linux repository
where these patches are committed (which is later merged into Linus's
branch).There are also emails having subject [linux-3.0 test] in the
xen-devel which seems like automated email generated after passing
some automated tests done after some commits. Basically which repo
does those emails correspond to? 
- S
 
--=_2089796875758ab7d3c3631dfeaf65b5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 13px;"><br><br>On Tuesday, Fe=
bruary 05, 2013 at 9:05 PM, stevenson_1991@hush.com wrote:<blockquote style=
=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;"><span s=
tyle=3D"font-family:Arial;font-size:13px;">On Tuesday, February 05, 2013 at=
 8:55 PM, "Shunli Yi" &lt;syi@websense.com&gt; wrote:<br><blockquote style=
=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;">
<div>


<style type=3D"text/css"></style>
</div>
<div lang=3D"EN-US">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:#1F497D;">The Xe=
n supporting code already enters into the kernel mainline now. So, you can =
try the main line kernel code at first.&nbsp;
</span></p>
</div></div></blockquote><span style=3D"color:#1f497d;font-size:11pt;">Sorr=
y if I am not clear. I was talking about the ongoing patches that are poste=
d on xen-devel and being reviewed. Is there any xen based Linux repository =
where these patches are committed (which is later merged into Linus's branc=
h).</span></span></blockquote><font face=3D"Arial">There are also emails ha=
ving subject [linux-3.0 test] in the xen-devel which seems like automated e=
mail generated after passing some automated tests done after some commits. =
Basically which repo does those emails correspond to?&nbsp;</font><div><fon=
t face=3D"Arial"><br></font></div><div><font face=3D"Arial">- S<br></font><=
font face=3D"Arial">&nbsp;</font></div></span>
--=_2089796875758ab7d3c3631dfeaf65b5--



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

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

--===============1541757224519673647==--



From xen-devel-bounces@lists.xen.org Wed Feb 06 02:12:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 02:12: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 1U2uUN-0005Ka-RK; Wed, 06 Feb 2013 02:11:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U2uUM-0005KT-FN
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 02:11:54 +0000
Received: from [193.109.254.147:35760] by server-8.bemta-14.messagelabs.com id
	77/5A-17325-9EBB1115; Wed, 06 Feb 2013 02:11:53 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360116712!3429409!1
X-Originating-IP: [74.125.82.180]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_60_70,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 6 Feb 2013 02:11:53 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 02:11:53 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so719229wer.11
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 18:11:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=+tAQHZa0jnBOMqdXesYjh1QuDFLpKk3lWDJ2XnppxdY=;
	b=TIUa9ZpryS7fyedBB0RPXYpd+eK7PrEa2zqxvX134+1S2Zl0+1Vayw5arRl1bHZL/E
	HuQ3Zrn/SrWIAq6VbHXAXBqry4/z7hk4dzjs1tOHyfllCdN7kdoS0RCfdzx1oBQXro15
	5VhjDW3CPh9pF2VdN7Cyee2GImAR75cIfO3SoOpPO82Jem4+jZtS1kzU7RVcH9TpEO0u
	Xp20xKEYrz6et5qQXXGUKcWk5D+MX4M3wRNAL8AhhR426TGaDLQnbcJk+0FYY6IKHbtP
	W102pHpIeO2R9YgURJKiRln5dj6g/kTyXqIeePMe3MQlV0tDcSiLoIfkdBLEzfT1RRU1
	y7ow==
X-Received: by 10.180.90.106 with SMTP id bv10mr1953273wib.12.1360116712801;
	Tue, 05 Feb 2013 18:11:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.36.226 with HTTP; Tue, 5 Feb 2013 18:11:22 -0800 (PST)
In-Reply-To: <20130206020418.0282710E2D5@smtp.hushmail.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
	<961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
	<20130206020418.0282710E2D5@smtp.hushmail.com>
From: Wei Liu <liuw@liuw.name>
Date: Wed, 6 Feb 2013 02:11:22 +0000
Message-ID: <CAOsiSVU8tXEwQr20K2YgXgDkAy1PFH_gioZJx1sH6GUGZ=mB3w@mail.gmail.com>
To: stevenson_1991@hush.com
X-Gm-Message-State: ALoCoQn5ZQBK2Y1pL8uANFkRhAOnJ0MhS20234uaOvJYpjngLSY7BP2c+ckT/78A9Y74NoKuBDHs
Cc: Shunli Yi <syi@websense.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5976537326349993947=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5976537326349993947==
Content-Type: multipart/alternative; boundary=f46d043c81e88503eb04d504d959

--f46d043c81e88503eb04d504d959
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 6, 2013 at 2:04 AM, <stevenson_1991@hush.com> wrote:

> On Tuesday, February 05, 2013 at 8:55 PM, "Shunli Yi" <syi@websense.com>
> wrote:
>
>   The Xen supporting code already enters into the kernel mainline now.
> So, you can try the main line kernel code at first.
>
> Sorry if I am not clear. I was talking about the ongoing patches that are
> posted on xen-devel and being reviewed. Is there any xen based Linux
> repository where these patches are committed (which is later merged into
> Linus's branch).
>
> - S
>
>
Check out Konrad's tree - he is the maintainer.

His tree has many branches. Just pick one that suits your need.


Wei.



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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Feb 6, 2013 at 2:04 AM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:stevenson_1991@hush.com" target=3D"_blank">stevenson_1991@hush.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"><span style=3D"font-family:Arial;font-size:1=
3px"><div class=3D"im">On Tuesday, February 05, 2013 at 8:55 PM, &quot;Shun=
li Yi&quot; &lt;<a href=3D"mailto:syi@websense.com" target=3D"_blank">syi@w=
ebsense.com</a>&gt; wrote:<br>

<blockquote style=3D"border-left:solid 1px #ccc;margin-left:10px;padding-le=
ft:10px">
<div>



</div>
<div lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:#1f497d">The Xen=
 supporting code already enters into the kernel mainline now. So, you can t=
ry the main line kernel code at first.=C2=A0
</span></p>
</div></div></blockquote></div><span style=3D"color:rgb(31,73,125);font-siz=
e:11pt">Sorry if I am not clear. I was talking about the ongoing patches th=
at are posted on xen-devel and being reviewed. Is there any xen based Linux=
 repository where these patches are committed (which is later merged into L=
inus&#39;s branch).</span><div>

<span style=3D"color:rgb(31,73,125);font-size:11pt"><br></span></div><div><=
span style=3D"color:rgb(31,73,125);font-size:11pt">- S</span></div></span><=
br></blockquote><div><br></div><div style>Check out Konrad&#39;s tree - he =
is the maintainer.</div>

<div style><br></div><div style>His tree has many branches. Just pick one t=
hat suits your need.</div><div style><br></div><div style><br></div><div st=
yle>Wei.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

_______________________________________________<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.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br></div></div>

--f46d043c81e88503eb04d504d959--


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

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

--===============5976537326349993947==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 02:12:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 02:12: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 1U2uUN-0005Ka-RK; Wed, 06 Feb 2013 02:11:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U2uUM-0005KT-FN
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 02:11:54 +0000
Received: from [193.109.254.147:35760] by server-8.bemta-14.messagelabs.com id
	77/5A-17325-9EBB1115; Wed, 06 Feb 2013 02:11:53 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360116712!3429409!1
X-Originating-IP: [74.125.82.180]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_60_70,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 6 Feb 2013 02:11:53 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 02:11:53 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so719229wer.11
	for <xen-devel@lists.xen.org>; Tue, 05 Feb 2013 18:11:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=+tAQHZa0jnBOMqdXesYjh1QuDFLpKk3lWDJ2XnppxdY=;
	b=TIUa9ZpryS7fyedBB0RPXYpd+eK7PrEa2zqxvX134+1S2Zl0+1Vayw5arRl1bHZL/E
	HuQ3Zrn/SrWIAq6VbHXAXBqry4/z7hk4dzjs1tOHyfllCdN7kdoS0RCfdzx1oBQXro15
	5VhjDW3CPh9pF2VdN7Cyee2GImAR75cIfO3SoOpPO82Jem4+jZtS1kzU7RVcH9TpEO0u
	Xp20xKEYrz6et5qQXXGUKcWk5D+MX4M3wRNAL8AhhR426TGaDLQnbcJk+0FYY6IKHbtP
	W102pHpIeO2R9YgURJKiRln5dj6g/kTyXqIeePMe3MQlV0tDcSiLoIfkdBLEzfT1RRU1
	y7ow==
X-Received: by 10.180.90.106 with SMTP id bv10mr1953273wib.12.1360116712801;
	Tue, 05 Feb 2013 18:11:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.36.226 with HTTP; Tue, 5 Feb 2013 18:11:22 -0800 (PST)
In-Reply-To: <20130206020418.0282710E2D5@smtp.hushmail.com>
References: <20130206014917.7C2AF10E2D5@smtp.hushmail.com>
	<961EE662BA396D43898AFA993C8F01B77508C83C@SBJEXCH1A.websense.com>
	<20130206020418.0282710E2D5@smtp.hushmail.com>
From: Wei Liu <liuw@liuw.name>
Date: Wed, 6 Feb 2013 02:11:22 +0000
Message-ID: <CAOsiSVU8tXEwQr20K2YgXgDkAy1PFH_gioZJx1sH6GUGZ=mB3w@mail.gmail.com>
To: stevenson_1991@hush.com
X-Gm-Message-State: ALoCoQn5ZQBK2Y1pL8uANFkRhAOnJ0MhS20234uaOvJYpjngLSY7BP2c+ckT/78A9Y74NoKuBDHs
Cc: Shunli Yi <syi@websense.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XEN related Linux repo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5976537326349993947=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5976537326349993947==
Content-Type: multipart/alternative; boundary=f46d043c81e88503eb04d504d959

--f46d043c81e88503eb04d504d959
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 6, 2013 at 2:04 AM, <stevenson_1991@hush.com> wrote:

> On Tuesday, February 05, 2013 at 8:55 PM, "Shunli Yi" <syi@websense.com>
> wrote:
>
>   The Xen supporting code already enters into the kernel mainline now.
> So, you can try the main line kernel code at first.
>
> Sorry if I am not clear. I was talking about the ongoing patches that are
> posted on xen-devel and being reviewed. Is there any xen based Linux
> repository where these patches are committed (which is later merged into
> Linus's branch).
>
> - S
>
>
Check out Konrad's tree - he is the maintainer.

His tree has many branches. Just pick one that suits your need.


Wei.



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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Feb 6, 2013 at 2:04 AM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:stevenson_1991@hush.com" target=3D"_blank">stevenson_1991@hush.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"><span style=3D"font-family:Arial;font-size:1=
3px"><div class=3D"im">On Tuesday, February 05, 2013 at 8:55 PM, &quot;Shun=
li Yi&quot; &lt;<a href=3D"mailto:syi@websense.com" target=3D"_blank">syi@w=
ebsense.com</a>&gt; wrote:<br>

<blockquote style=3D"border-left:solid 1px #ccc;margin-left:10px;padding-le=
ft:10px">
<div>



</div>
<div lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:#1f497d">The Xen=
 supporting code already enters into the kernel mainline now. So, you can t=
ry the main line kernel code at first.=C2=A0
</span></p>
</div></div></blockquote></div><span style=3D"color:rgb(31,73,125);font-siz=
e:11pt">Sorry if I am not clear. I was talking about the ongoing patches th=
at are posted on xen-devel and being reviewed. Is there any xen based Linux=
 repository where these patches are committed (which is later merged into L=
inus&#39;s branch).</span><div>

<span style=3D"color:rgb(31,73,125);font-size:11pt"><br></span></div><div><=
span style=3D"color:rgb(31,73,125);font-size:11pt">- S</span></div></span><=
br></blockquote><div><br></div><div style>Check out Konrad&#39;s tree - he =
is the maintainer.</div>

<div style><br></div><div style>His tree has many branches. Just pick one t=
hat suits your need.</div><div style><br></div><div style><br></div><div st=
yle>Wei.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

_______________________________________________<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.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br></div></div>

--f46d043c81e88503eb04d504d959--


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

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

--===============5976537326349993947==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 04:37:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 04:37: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 1U2wlB-00005i-Iw; Wed, 06 Feb 2013 04:37: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 1U2wl9-00005d-O5
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 04:37:24 +0000
Received: from [85.158.138.51:16100] by server-4.bemta-3.messagelabs.com id
	C0/5F-12802-00ED1115; Wed, 06 Feb 2013 04:37:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360125439!28996884!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22486 invoked from network); 6 Feb 2013 04:37:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 04:37:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,612,1355097600"; 
   d="scan'208";a="1180903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 04:37: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.297.1; Wed, 6 Feb 2013 04:37:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2wl5-0003As-7K;
	Wed, 06 Feb 2013 04:37:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2wl5-0002JV-1e;
	Wed, 06 Feb 2013 04:37:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15427-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 04:37:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15427: 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 15427 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15427/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 15181

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15181

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   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-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       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-i386-i386-xl-win        13 guest-stop                   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-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  b8a523d9f14c
baseline version:
 xen                  7c04074a0a0f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <JBeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.

------------------------------------------------------------
changeset:   25977:b8a523d9f14c
tag:         tip
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:30:59 2013 +0100
    
    AMD,IOMMU: Make per-device interrupt remapping table default
    
    Using global interrupt remapping table may be insecure, as
    described by XSA-36. This patch makes per-device mode default.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Moved warning in amd_iov_detect() to location covering all cases.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26519:1af531e7bc2f
    xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
    
    
changeset:   25976:43308c02c07d
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:30:31 2013 +0100
    
    AMD,IOMMU: Disable IOMMU if SATA Combined mode is on
    
    AMD's SP5100 chipset can be placed into SATA Combined mode
    that may cause prevent dom0 from booting when IOMMU is
    enabled and per-device interrupt remapping table is used.
    While SP5100 erratum 28 requires BIOSes to disable this mode,
    some may still use it.
    
    This patch checks whether this mode is on and, if per-device
    table is in use, disables IOMMU.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Flipped operands of && in amd_iommu_init() to make the message issued
    by amd_sp5100_erratum28() match reality (when amd_iommu_perdev_intremap
    is zero, there's really no point in calling the function).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26518:e379a23b0465
    xen-unstable date: Tue Feb  5 14:21:25 UTC 2013
    
    
changeset:   25975:7b294324e98e
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Feb 05 15:29:51 2013 +0100
    
    AMD,IOMMU: Clean up old entries in remapping tables when creating new one
    
    When changing the affinity of an IRQ associated with a passed
    through PCI device, clear previous mapping.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    In addition, because some BIOSes may incorrectly program IVRS
    entries for IOAPIC try to check for entry's consistency. Specifically,
    if conflicting entries are found disable IOMMU if per-device
    remapping table is used. If entries refer to bogus IOAPIC IDs
    disable IOMMU unconditionally
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    xen-unstable changeset: 26517:601139e2b0db
    xen-unstable date: Tue Feb  5 14:20:47 UTC 2013
    
    
changeset:   25974:f3725a1da193
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:29:03 2013 +0100
    
    ACPI: acpi_table_parse() should return handler's error code
    
    Currently, the error code returned by acpi_table_parse()'s handler
    is ignored. This patch will propagate handler's return value to
    acpi_table_parse()'s caller.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26516:32d4516a97f0
    xen-unstable date: Tue Feb  5 14:18:18 UTC 2013
    
    
changeset:   25973:7c04074a0a0f
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Jan 23 11:52:44 2013 +0100
    
    xen: Do not allow guests to enable nested HVM on themselves
    
    There is no reason for this and doing so exposes a memory leak to
    guests. Only toolstacks need write access to this HVM param.
    
    This is XSA-35 / CVE-2013-0152.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    xen-unstable changeset: 26444:621b1a889e9b
    xen-unstable date: Wed Jan 23 10:47:24 UTC 2013
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 04:37:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 04:37: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 1U2wlB-00005i-Iw; Wed, 06 Feb 2013 04:37: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 1U2wl9-00005d-O5
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 04:37:24 +0000
Received: from [85.158.138.51:16100] by server-4.bemta-3.messagelabs.com id
	C0/5F-12802-00ED1115; Wed, 06 Feb 2013 04:37:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360125439!28996884!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22486 invoked from network); 6 Feb 2013 04:37:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 04:37:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,612,1355097600"; 
   d="scan'208";a="1180903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 04:37: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.297.1; Wed, 6 Feb 2013 04:37:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2wl5-0003As-7K;
	Wed, 06 Feb 2013 04:37:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2wl5-0002JV-1e;
	Wed, 06 Feb 2013 04:37:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15427-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 04:37:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15427: 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 15427 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15427/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 15181

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15181

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   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-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       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-i386-i386-xl-win        13 guest-stop                   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-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  b8a523d9f14c
baseline version:
 xen                  7c04074a0a0f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <JBeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               broken  
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.

------------------------------------------------------------
changeset:   25977:b8a523d9f14c
tag:         tip
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:30:59 2013 +0100
    
    AMD,IOMMU: Make per-device interrupt remapping table default
    
    Using global interrupt remapping table may be insecure, as
    described by XSA-36. This patch makes per-device mode default.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Moved warning in amd_iov_detect() to location covering all cases.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26519:1af531e7bc2f
    xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
    
    
changeset:   25976:43308c02c07d
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:30:31 2013 +0100
    
    AMD,IOMMU: Disable IOMMU if SATA Combined mode is on
    
    AMD's SP5100 chipset can be placed into SATA Combined mode
    that may cause prevent dom0 from booting when IOMMU is
    enabled and per-device interrupt remapping table is used.
    While SP5100 erratum 28 requires BIOSes to disable this mode,
    some may still use it.
    
    This patch checks whether this mode is on and, if per-device
    table is in use, disables IOMMU.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Flipped operands of && in amd_iommu_init() to make the message issued
    by amd_sp5100_erratum28() match reality (when amd_iommu_perdev_intremap
    is zero, there's really no point in calling the function).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26518:e379a23b0465
    xen-unstable date: Tue Feb  5 14:21:25 UTC 2013
    
    
changeset:   25975:7b294324e98e
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Feb 05 15:29:51 2013 +0100
    
    AMD,IOMMU: Clean up old entries in remapping tables when creating new one
    
    When changing the affinity of an IRQ associated with a passed
    through PCI device, clear previous mapping.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    In addition, because some BIOSes may incorrectly program IVRS
    entries for IOAPIC try to check for entry's consistency. Specifically,
    if conflicting entries are found disable IOMMU if per-device
    remapping table is used. If entries refer to bogus IOAPIC IDs
    disable IOMMU unconditionally
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    xen-unstable changeset: 26517:601139e2b0db
    xen-unstable date: Tue Feb  5 14:20:47 UTC 2013
    
    
changeset:   25974:f3725a1da193
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:29:03 2013 +0100
    
    ACPI: acpi_table_parse() should return handler's error code
    
    Currently, the error code returned by acpi_table_parse()'s handler
    is ignored. This patch will propagate handler's return value to
    acpi_table_parse()'s caller.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26516:32d4516a97f0
    xen-unstable date: Tue Feb  5 14:18:18 UTC 2013
    
    
changeset:   25973:7c04074a0a0f
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Jan 23 11:52:44 2013 +0100
    
    xen: Do not allow guests to enable nested HVM on themselves
    
    There is no reason for this and doing so exposes a memory leak to
    guests. Only toolstacks need write access to this HVM param.
    
    This is XSA-35 / CVE-2013-0152.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    xen-unstable changeset: 26444:621b1a889e9b
    xen-unstable date: Wed Jan 23 10:47:24 UTC 2013
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:05:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07:05: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 1U2z45-0004Bs-AK; Wed, 06 Feb 2013 07:05:05 +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 1U2z42-0004Bn-Tk
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 07:05:03 +0000
Received: from [85.158.137.99:62590] by server-7.bemta-3.messagelabs.com id
	0D/BE-10367-99002115; Wed, 06 Feb 2013 07:04:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360134290!19117264!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28043 invoked from network); 6 Feb 2013 07:04:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 07:04:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1183883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 07: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.297.1; Wed, 6 Feb 2013 07:04:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2z3q-0003wa-8b;
	Wed, 06 Feb 2013 07:04:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2z3q-0004Ay-2j;
	Wed, 06 Feb 2013 07:04:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1U2z3q-0004Ay-2j@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 07:04:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-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

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-intel
test redhat-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  69398345c10e
  Bug not present: d1bf3b21f783


  changeset:   26503:69398345c10e
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Mon Feb 04 12:03:38 2013 +0100
      
      x86/nestedhvm: properly clean up after failure to set up all vCPU-s
      
      This implies that the individual destroy functions will have to remain
      capable of being called for a vCPU that the corresponding init function
      was never run on.
      
      Once at it, also clean up some inefficiencies in the corresponding
      parameter validation code.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 15421 fail [host=earwig] / 15433 ok.
Failure / basis pass flights: 15421 / 15433
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#2a1354d655d816feaad7dbdb8364f40a208439c1-2a1354d655d816feaad7dbdb8364f40a208439c1 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 http://xenbits.xen.org/hg/staging/xen-unstable.hg#d1bf3b21f783-ff77e84ddfdc
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 97 nodes in revision graph
Searching for test results:
 15394 [host=bush-cricket]
 15395 [host=bush-cricket]
 15396 [host=bush-cricket]
 15431 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 69398345c10e
 15401 [host=gall-mite]
 15404 [host=bush-cricket]
 15405 [host=itch-mite]
 15433 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
 15406 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
 15411 [host=gall-mite]
 15435 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 69398345c10e
 15412 [host=bush-cricket]
 15413 [host=field-cricket]
 15414 [host=bush-cricket]
 15415 [host=bush-cricket]
 15416 [host=gall-mite]
 15417 [host=field-cricket]
 15419 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
 15422 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
 15424 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
 15425 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 90525fcb0982
 15428 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 69398345c10e
 15421 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
 15429 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
Searching for interesting versions
 Result found: flight 15406 (pass), for basis pass
 Result found: flight 15419 (fail), for basis failure
 Repro found: flight 15422 (pass), for basis pass
 Repro found: flight 15424 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
No revisions left to test, checking graph state.
 Result found: flight 15406 (pass), for last pass
 Result found: flight 15428 (fail), for first failure
 Repro found: flight 15429 (pass), for last pass
 Repro found: flight 15431 (fail), for first failure
 Repro found: flight 15433 (pass), for last pass
 Repro found: flight 15435 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  69398345c10e
  Bug not present: d1bf3b21f783

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26503:69398345c10e
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Mon Feb 04 12:03:38 2013 +0100
      
      x86/nestedhvm: properly clean up after failure to set up all vCPU-s
      
      This implies that the individual destroy functions will have to remain
      capable of being called for a vCPU that the corresponding init function
      was never run on.
      
      Once at it, also clean up some inefficiencies in the corresponding
      parameter validation code.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
15435: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install        fail baseline untested


jobs:
 test-amd64-i386-rhel6hvm-intel                               fail    


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

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

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


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:05:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07:05: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 1U2z45-0004Bs-AK; Wed, 06 Feb 2013 07:05:05 +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 1U2z42-0004Bn-Tk
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 07:05:03 +0000
Received: from [85.158.137.99:62590] by server-7.bemta-3.messagelabs.com id
	0D/BE-10367-99002115; Wed, 06 Feb 2013 07:04:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360134290!19117264!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28043 invoked from network); 6 Feb 2013 07:04:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 07:04:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1183883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 07: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.297.1; Wed, 6 Feb 2013 07:04:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U2z3q-0003wa-8b;
	Wed, 06 Feb 2013 07:04:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U2z3q-0004Ay-2j;
	Wed, 06 Feb 2013 07:04:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1U2z3q-0004Ay-2j@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 07:04:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-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

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-intel
test redhat-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  69398345c10e
  Bug not present: d1bf3b21f783


  changeset:   26503:69398345c10e
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Mon Feb 04 12:03:38 2013 +0100
      
      x86/nestedhvm: properly clean up after failure to set up all vCPU-s
      
      This implies that the individual destroy functions will have to remain
      capable of being called for a vCPU that the corresponding init function
      was never run on.
      
      Once at it, also clean up some inefficiencies in the corresponding
      parameter validation code.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 15421 fail [host=earwig] / 15433 ok.
Failure / basis pass flights: 15421 / 15433
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#2a1354d655d816feaad7dbdb8364f40a208439c1-2a1354d655d816feaad7dbdb8364f40a208439c1 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 http://xenbits.xen.org/hg/staging/xen-unstable.hg#d1bf3b21f783-ff77e84ddfdc
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 97 nodes in revision graph
Searching for test results:
 15394 [host=bush-cricket]
 15395 [host=bush-cricket]
 15396 [host=bush-cricket]
 15431 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 69398345c10e
 15401 [host=gall-mite]
 15404 [host=bush-cricket]
 15405 [host=itch-mite]
 15433 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
 15406 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
 15411 [host=gall-mite]
 15435 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 69398345c10e
 15412 [host=bush-cricket]
 15413 [host=field-cricket]
 15414 [host=bush-cricket]
 15415 [host=bush-cricket]
 15416 [host=gall-mite]
 15417 [host=field-cricket]
 15419 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
 15422 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
 15424 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
 15425 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 90525fcb0982
 15428 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 69398345c10e
 15421 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ff77e84ddfdc
 15429 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
Searching for interesting versions
 Result found: flight 15406 (pass), for basis pass
 Result found: flight 15419 (fail), for basis failure
 Repro found: flight 15422 (pass), for basis pass
 Repro found: flight 15424 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 d1bf3b21f783
No revisions left to test, checking graph state.
 Result found: flight 15406 (pass), for last pass
 Result found: flight 15428 (fail), for first failure
 Repro found: flight 15429 (pass), for last pass
 Repro found: flight 15431 (fail), for first failure
 Repro found: flight 15433 (pass), for last pass
 Repro found: flight 15435 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  69398345c10e
  Bug not present: d1bf3b21f783

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26503:69398345c10e
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Mon Feb 04 12:03:38 2013 +0100
      
      x86/nestedhvm: properly clean up after failure to set up all vCPU-s
      
      This implies that the individual destroy functions will have to remain
      capable of being called for a vCPU that the corresponding init function
      was never run on.
      
      Once at it, also clean up some inefficiencies in the corresponding
      parameter validation code.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
15435: tolerable ALL FAIL

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install        fail baseline untested


jobs:
 test-amd64-i386-rhel6hvm-intel                               fail    


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

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

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


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:53:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07: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 1U2zoG-0005Xr-E4; Wed, 06 Feb 2013 07:52: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 1U2zoF-0005Xm-Gn
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 07:52:47 +0000
Received: from [85.158.139.83:8225] by server-9.bemta-5.messagelabs.com id
	CE/57-24440-ECB02115; Wed, 06 Feb 2013 07:52:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360137164!30917495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4446 invoked from network); 6 Feb 2013 07:52:44 -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; 6 Feb 2013 07:52:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 07:51:42 +0000
Message-Id: <5112199D02000078000BC553@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 07:51:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:58, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> +/**
> + * File information
> + * Prefixed with XENCOV_TAG_FILE and a string with filename
> + */
> +struct xencov_file
> +{
> +    uint32_t version;
> +    uint32_t stamp;
> +} __attribute__((packed));
> +
> +/**
> + * Counters information
> + * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
> + */
> +struct xencov_counter
> +{
> +    uint32_t num;
> +    uint64_t values[0];
> +} __attribute__((packed));
> +
> +/**
> + * Information for each function
> + * Prefixed with XENCOV_TAG_FUNC
> + * Number of counter is equal to the number of counter got before
> + */
> +struct xencov_function
> +{
> +    uint32_t ident;
> +    uint32_t checksum;
> +    uint32_t n_ctrs[0];
> +} __attribute__((packed));
> +
> +struct xencov_functions
> +{
> +    uint32_t num;
> +    uint32_t xencov_function[0];
> +} __attribute__((packed));

Once again: No use of compiler extensions in public headers.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:53:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07: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 1U2zoG-0005Xr-E4; Wed, 06 Feb 2013 07:52: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 1U2zoF-0005Xm-Gn
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 07:52:47 +0000
Received: from [85.158.139.83:8225] by server-9.bemta-5.messagelabs.com id
	CE/57-24440-ECB02115; Wed, 06 Feb 2013 07:52:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360137164!30917495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4446 invoked from network); 6 Feb 2013 07:52:44 -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; 6 Feb 2013 07:52:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 07:51:42 +0000
Message-Id: <5112199D02000078000BC553@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 07:51:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/4] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:58, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> +/**
> + * File information
> + * Prefixed with XENCOV_TAG_FILE and a string with filename
> + */
> +struct xencov_file
> +{
> +    uint32_t version;
> +    uint32_t stamp;
> +} __attribute__((packed));
> +
> +/**
> + * Counters information
> + * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
> + */
> +struct xencov_counter
> +{
> +    uint32_t num;
> +    uint64_t values[0];
> +} __attribute__((packed));
> +
> +/**
> + * Information for each function
> + * Prefixed with XENCOV_TAG_FUNC
> + * Number of counter is equal to the number of counter got before
> + */
> +struct xencov_function
> +{
> +    uint32_t ident;
> +    uint32_t checksum;
> +    uint32_t n_ctrs[0];
> +} __attribute__((packed));
> +
> +struct xencov_functions
> +{
> +    uint32_t num;
> +    uint32_t xencov_function[0];
> +} __attribute__((packed));

Once again: No use of compiler extensions in public headers.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:53:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07: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 1U2zoQ-0005YL-R0; Wed, 06 Feb 2013 07:52:58 +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 1U2zoP-0005YB-Qe
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 07:52:57 +0000
Received: from [85.158.139.83:6056] by server-14.bemta-5.messagelabs.com id
	0C/AF-06967-8DB02115; Wed, 06 Feb 2013 07:52:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360137175!24027494!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24311 invoked from network); 6 Feb 2013 07:52:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 07:52:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 07:52:54 +0000
Message-Id: <511219E502000078000BC556@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 07:52:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-4-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360079900-31777-4-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:58, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> Safety check for initialization objects.
> Constructors are not used so check some module does not use them.

Why? They're themselves being put into .init.data, so their
presence is fine in init-only objects.

Jan

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 
> 8,rodata.str1.$(n)) \
>  $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
>  	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; 
> do \
>  		case "$$name" in \
> -		.text|.text.*|.data|.data.*|.bss) \
> +		.text|.text.*|.data|.data.*|.bss|.ctors) \
>  			test $$sz != 0 || continue; \
>  			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
>  			exit $$(expr $$idx + 1);; \



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:53:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07: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 1U2zoQ-0005YL-R0; Wed, 06 Feb 2013 07:52:58 +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 1U2zoP-0005YB-Qe
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 07:52:57 +0000
Received: from [85.158.139.83:6056] by server-14.bemta-5.messagelabs.com id
	0C/AF-06967-8DB02115; Wed, 06 Feb 2013 07:52:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360137175!24027494!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24311 invoked from network); 6 Feb 2013 07:52:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 07:52:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 07:52:54 +0000
Message-Id: <511219E502000078000BC556@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 07:52:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-4-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360079900-31777-4-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:58, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> Safety check for initialization objects.
> Constructors are not used so check some module does not use them.

Why? They're themselves being put into .init.data, so their
presence is fine in init-only objects.

Jan

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 
> 8,rodata.str1.$(n)) \
>  $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
>  	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; 
> do \
>  		case "$$name" in \
> -		.text|.text.*|.data|.data.*|.bss) \
> +		.text|.text.*|.data|.data.*|.bss|.ctors) \
>  			test $$sz != 0 || continue; \
>  			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
>  			exit $$(expr $$idx + 1);; \



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:59:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07:59: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 1U2zuI-0005oE-Lj; Wed, 06 Feb 2013 07:59:02 +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 1U2zuG-0005o5-E3
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 07:59:00 +0000
Received: from [85.158.139.211:30908] by server-5.bemta-5.messagelabs.com id
	A5/E2-11945-34D02115; Wed, 06 Feb 2013 07:58:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360137538!17334440!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16128 invoked from network); 6 Feb 2013 07:58:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 07:58:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 07:58:58 +0000
Message-Id: <51121B5002000078000BC573@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 07:58:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net> <20130205200847.GS8912@reaktio.net>
In-Reply-To: <20130205200847.GS8912@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: arrfab@centos.org, agya naila <agya.naila@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA1LjAyLjEzIGF0IDIxOjA4LCBQYXNpIEvDpHJra8OkaW5lbjxwYXNpa0Bpa2kuZmk+
IHdyb3RlOgo+IEFycmZhYiAoQ0MnZCkgaXMgYWN0dWFsbHkgc2VlaW5nIGEgc2ltaWxhciBwcm9i
bGVtIG9uIElCTSBIUzIwIGJsYWRlIHdpdGggCj4gWGVuIDQuMi4xIAo+IHdpdGggTGludXggMy40
LjI4IGRvbTAga2VybmVsLgo+IAo+IERvZXMgdGhpcyByaW5nIGFueW9uZSdzIGJlbGxzPyAKPiAK
PiAKPiBzZXJpYWwgY29uc29sZSBsb2cgb2YgdGhlIGNyYXNoIAoKV2hpY2ggZG9lc24ndCBldmVu
IGluY2x1ZGUgdGhlIG1lc3NhZ2UgaW4gdGhlIHN1YmplY3QgYWZhaWNzLCBzbyBJCmRvbid0IGV2
ZW4ga25vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0LiBBbmQgdGhlIG90aGVyLCBlYXJsaWVy
CnJlcG9ydCBoYXMgbm8gdXNlZnVsIGluZm9ybWF0aW9uIGVpdGhlci4KCkZyb20gYW4gYWJzdHJh
Y3QgcGVyc3BlY3RpdmUsIGEgZnJvbnQgcGFuZWwgTk1JIHRvIG1lIHdvdWxkIG1lYW4Kc29tZW9u
ZSBwcmVzc2VkIGFuIE5NSSBidXR0b24gb24gdGhlIHN5c3RlbSdzIGZyb250IHBhbmVsLiBZb3UK
ZG9uJ3QgdGhpbmsgWGVuIGNhbiBkbyBhbnl0aGluZyBhYm91dCB0aGlzLCBkbyB5b3U/IEFuZCBl
dmVuIGlmCnRoZSBOTUkgaGFzIGFub3RoZXIgb3JpZ2luLCBpdCdzIHN0aWxsIGEgaGFyZHdhcmUg
Z2VuZXJhdGVkIGV2ZW50CnRoYXQgWGVuIGhhcyBubyBjb250cm9sIG92ZXIuCgpKYW4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 06 07:59:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 07:59: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 1U2zuI-0005oE-Lj; Wed, 06 Feb 2013 07:59:02 +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 1U2zuG-0005o5-E3
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 07:59:00 +0000
Received: from [85.158.139.211:30908] by server-5.bemta-5.messagelabs.com id
	A5/E2-11945-34D02115; Wed, 06 Feb 2013 07:58:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360137538!17334440!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16128 invoked from network); 6 Feb 2013 07:58:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 07:58:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 07:58:58 +0000
Message-Id: <51121B5002000078000BC573@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 07:58:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net> <20130205200847.GS8912@reaktio.net>
In-Reply-To: <20130205200847.GS8912@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: arrfab@centos.org, agya naila <agya.naila@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA1LjAyLjEzIGF0IDIxOjA4LCBQYXNpIEvDpHJra8OkaW5lbjxwYXNpa0Bpa2kuZmk+
IHdyb3RlOgo+IEFycmZhYiAoQ0MnZCkgaXMgYWN0dWFsbHkgc2VlaW5nIGEgc2ltaWxhciBwcm9i
bGVtIG9uIElCTSBIUzIwIGJsYWRlIHdpdGggCj4gWGVuIDQuMi4xIAo+IHdpdGggTGludXggMy40
LjI4IGRvbTAga2VybmVsLgo+IAo+IERvZXMgdGhpcyByaW5nIGFueW9uZSdzIGJlbGxzPyAKPiAK
PiAKPiBzZXJpYWwgY29uc29sZSBsb2cgb2YgdGhlIGNyYXNoIAoKV2hpY2ggZG9lc24ndCBldmVu
IGluY2x1ZGUgdGhlIG1lc3NhZ2UgaW4gdGhlIHN1YmplY3QgYWZhaWNzLCBzbyBJCmRvbid0IGV2
ZW4ga25vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0LiBBbmQgdGhlIG90aGVyLCBlYXJsaWVy
CnJlcG9ydCBoYXMgbm8gdXNlZnVsIGluZm9ybWF0aW9uIGVpdGhlci4KCkZyb20gYW4gYWJzdHJh
Y3QgcGVyc3BlY3RpdmUsIGEgZnJvbnQgcGFuZWwgTk1JIHRvIG1lIHdvdWxkIG1lYW4Kc29tZW9u
ZSBwcmVzc2VkIGFuIE5NSSBidXR0b24gb24gdGhlIHN5c3RlbSdzIGZyb250IHBhbmVsLiBZb3UK
ZG9uJ3QgdGhpbmsgWGVuIGNhbiBkbyBhbnl0aGluZyBhYm91dCB0aGlzLCBkbyB5b3U/IEFuZCBl
dmVuIGlmCnRoZSBOTUkgaGFzIGFub3RoZXIgb3JpZ2luLCBpdCdzIHN0aWxsIGEgaGFyZHdhcmUg
Z2VuZXJhdGVkIGV2ZW50CnRoYXQgWGVuIGhhcyBubyBjb250cm9sIG92ZXIuCgpKYW4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:05:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:05: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 1U300O-0006dJ-VY; Wed, 06 Feb 2013 08:05:20 +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 1U300N-0006dE-Sy
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:05:20 +0000
Received: from [85.158.139.83:23292] by server-9.bemta-5.messagelabs.com id
	29/4B-24440-EBE02115; Wed, 06 Feb 2013 08:05:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360137916!31018009!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21724 invoked from network); 6 Feb 2013 08:05:17 -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 Feb 2013 08:05:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 08:05:16 +0000
Message-Id: <51121CC002000078000BC57B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 08:05:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
	<1359998635-16866-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359998635-16866-5-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, konrad.wilk@oracle.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH V2 04/13] xen: close evtchn port if binding
 to irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:23, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -269,6 +269,15 @@ static int evtchn_bind_to_user(struct per_user_data *u, 
> int port)
>  				       u->name, (void *)(unsigned long)port);
>  	if (rc >= 0)
>  		rc = evtchn_make_refcounted(port);
> +	else {
> +		/* bind failed, should close the port now */
> +		struct evtchn_close close;
> +		close.port = port;
> +		if (port != 0 && /* port 0 is never used */

If the port == 0 case really needs handling here (didn't look at
the surrounding code), this ought to be done with a "else if()"
at the top of this change imo.

Jan

> +		    HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> +			BUG();
> +		set_port_user(port, NULL);
> +	}
>  
>  	return rc;
>  }



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:05:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:05: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 1U300O-0006dJ-VY; Wed, 06 Feb 2013 08:05:20 +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 1U300N-0006dE-Sy
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:05:20 +0000
Received: from [85.158.139.83:23292] by server-9.bemta-5.messagelabs.com id
	29/4B-24440-EBE02115; Wed, 06 Feb 2013 08:05:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360137916!31018009!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21724 invoked from network); 6 Feb 2013 08:05:17 -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 Feb 2013 08:05:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 08:05:16 +0000
Message-Id: <51121CC002000078000BC57B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 08:05:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359998635-16866-1-git-send-email-wei.liu2@citrix.com>
	<1359998635-16866-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359998635-16866-5-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, konrad.wilk@oracle.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH V2 04/13] xen: close evtchn port if binding
 to irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:23, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -269,6 +269,15 @@ static int evtchn_bind_to_user(struct per_user_data *u, 
> int port)
>  				       u->name, (void *)(unsigned long)port);
>  	if (rc >= 0)
>  		rc = evtchn_make_refcounted(port);
> +	else {
> +		/* bind failed, should close the port now */
> +		struct evtchn_close close;
> +		close.port = port;
> +		if (port != 0 && /* port 0 is never used */

If the port == 0 case really needs handling here (didn't look at
the surrounding code), this ought to be done with a "else if()"
at the top of this change imo.

Jan

> +		    HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> +			BUG();
> +		set_port_user(port, NULL);
> +	}
>  
>  	return rc;
>  }



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:26:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:26: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 1U30Kg-0007G0-GM; Wed, 06 Feb 2013 08:26: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 1U30Ke-0007Fv-Qd
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:26:16 +0000
Received: from [85.158.139.83:55958] by server-6.bemta-5.messagelabs.com id
	9C/97-01489-7A312115; Wed, 06 Feb 2013 08:26:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360139175!30182049!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 6 Feb 2013 08:26:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 08:26:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1185765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 08:26:15 +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.297.1; Wed, 6 Feb 2013
	08:26:14 +0000
Message-ID: <1360139174.9063.38.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 08:26:14 +0000
In-Reply-To: <20753.20009.426315.39002@mariner.uk.xensource.com>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
	install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:23 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] osstest: ts-xen-install: Run ldconfig after install"):
> > This appears to be needed when libraries are outside /lib and /usr/lib
> > (specifically when they are in /usr/local/lib)
> 
> I have applied this and pushed it to osstest's equivalent of staging.

Thanks, we'll probably want that to graduate before we reconsider the
"install in /usr/local" patches.

BTW, I think you were going to be merging up your standalone branch into
osstest master, shall I rebase yet?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:26:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:26: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 1U30Kg-0007G0-GM; Wed, 06 Feb 2013 08:26: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 1U30Ke-0007Fv-Qd
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:26:16 +0000
Received: from [85.158.139.83:55958] by server-6.bemta-5.messagelabs.com id
	9C/97-01489-7A312115; Wed, 06 Feb 2013 08:26:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360139175!30182049!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 6 Feb 2013 08:26:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 08:26:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1185765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 08:26:15 +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.297.1; Wed, 6 Feb 2013
	08:26:14 +0000
Message-ID: <1360139174.9063.38.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 08:26:14 +0000
In-Reply-To: <20753.20009.426315.39002@mariner.uk.xensource.com>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
	install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:23 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] osstest: ts-xen-install: Run ldconfig after install"):
> > This appears to be needed when libraries are outside /lib and /usr/lib
> > (specifically when they are in /usr/local/lib)
> 
> I have applied this and pushed it to osstest's equivalent of staging.

Thanks, we'll probably want that to graduate before we reconsider the
"install in /usr/local" patches.

BTW, I think you were going to be merging up your standalone branch into
osstest master, shall I rebase yet?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:29:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:29: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 1U30Nk-0007MT-6z; Wed, 06 Feb 2013 08:29: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 1U30Nj-0007MN-AO
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:29:27 +0000
Received: from [193.109.254.147:15472] by server-12.bemta-14.messagelabs.com
	id B5/2B-32582-66412115; Wed, 06 Feb 2013 08:29:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360139337!3455943!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11830 invoked from network); 6 Feb 2013 08:28:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 08:28:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 08:28:57 +0000
Message-Id: <5112225702000078000BC5A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 08:28:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
	<1359998638-16774-15-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359998638-16774-15-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH V2 14/15] Only allow 3-level event channel
 on Dom0 and driver domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:23, Wei Liu <wei.liu2@citrix.com> wrote:
> @@ -411,6 +413,9 @@ struct domain *domain_create(
>   /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables 
> */
>  #define _DOMCRF_oos_off         4
>  #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
> +/* DOMCRF_evtchn_l3: this domain can use 3-level event channel (driver domain) */
> +#define _DOMCRF_evtchn_l3     5
> +#define DOMCRF_evtchn_l3      (1U<<_DOMCRF_evtchn_l3)

Please don't use "l3" in this name; instead, make it generic to say
"extended event channels" in some way.

Also, the patch description should explain why this restriction is
being put in place.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:29:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:29: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 1U30Nk-0007MT-6z; Wed, 06 Feb 2013 08:29: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 1U30Nj-0007MN-AO
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:29:27 +0000
Received: from [193.109.254.147:15472] by server-12.bemta-14.messagelabs.com
	id B5/2B-32582-66412115; Wed, 06 Feb 2013 08:29:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360139337!3455943!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11830 invoked from network); 6 Feb 2013 08:28:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 08:28:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 08:28:57 +0000
Message-Id: <5112225702000078000BC5A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 08:28:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1359998638-16774-1-git-send-email-wei.liu2@citrix.com>
	<1359998638-16774-15-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1359998638-16774-15-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH V2 14/15] Only allow 3-level event channel
 on Dom0 and driver domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 18:23, Wei Liu <wei.liu2@citrix.com> wrote:
> @@ -411,6 +413,9 @@ struct domain *domain_create(
>   /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables 
> */
>  #define _DOMCRF_oos_off         4
>  #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
> +/* DOMCRF_evtchn_l3: this domain can use 3-level event channel (driver domain) */
> +#define _DOMCRF_evtchn_l3     5
> +#define DOMCRF_evtchn_l3      (1U<<_DOMCRF_evtchn_l3)

Please don't use "l3" in this name; instead, make it generic to say
"extended event channels" in some way.

Also, the patch description should explain why this restriction is
being put in place.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:33:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:33: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 1U30R1-0007h1-UU; Wed, 06 Feb 2013 08:32: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 1U30R0-0007gu-By
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:32:50 +0000
Received: from [85.158.139.83:24211] by server-15.bemta-5.messagelabs.com id
	FE/12-18914-13512115; Wed, 06 Feb 2013 08:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360139549!31022526!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10070 invoked from network); 6 Feb 2013 08:32:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 08:32:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1186022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 08:32:30 +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.297.1; Wed, 6 Feb 2013
	08:32:29 +0000
Message-ID: <1360139548.9063.39.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 08:32:28 +0000
In-Reply-To: <1360139174.9063.38.camel@dagon.hellion.org.uk>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
	<1360139174.9063.38.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
 install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 08:26 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 18:23 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH] osstest: ts-xen-install: Run ldconfig after install"):
> > > This appears to be needed when libraries are outside /lib and /usr/lib
> > > (specifically when they are in /usr/local/lib)
> > 
> > I have applied this and pushed it to osstest's equivalent of staging.
> 
> Thanks, we'll probably want that to graduate before we reconsider the
> "install in /usr/local" patches.
> 
> BTW, I think you were going to be merging up your standalone branch into
> osstest master, shall I rebase yet?

Oh and BTW2, did you see the other standalone fixlets in
<1357903462.20328.35.camel@zakaz.uk.xensource.com> ?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:33:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:33: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 1U30R1-0007h1-UU; Wed, 06 Feb 2013 08:32: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 1U30R0-0007gu-By
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:32:50 +0000
Received: from [85.158.139.83:24211] by server-15.bemta-5.messagelabs.com id
	FE/12-18914-13512115; Wed, 06 Feb 2013 08:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360139549!31022526!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10070 invoked from network); 6 Feb 2013 08:32:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 08:32:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1186022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 08:32:30 +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.297.1; Wed, 6 Feb 2013
	08:32:29 +0000
Message-ID: <1360139548.9063.39.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 08:32:28 +0000
In-Reply-To: <1360139174.9063.38.camel@dagon.hellion.org.uk>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
	<1360139174.9063.38.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
 install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 08:26 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 18:23 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH] osstest: ts-xen-install: Run ldconfig after install"):
> > > This appears to be needed when libraries are outside /lib and /usr/lib
> > > (specifically when they are in /usr/local/lib)
> > 
> > I have applied this and pushed it to osstest's equivalent of staging.
> 
> Thanks, we'll probably want that to graduate before we reconsider the
> "install in /usr/local" patches.
> 
> BTW, I think you were going to be merging up your standalone branch into
> osstest master, shall I rebase yet?

Oh and BTW2, did you see the other standalone fixlets in
<1357903462.20328.35.camel@zakaz.uk.xensource.com> ?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:35:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:35: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 1U30TL-0007pg-Hy; Wed, 06 Feb 2013 08:35: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 1U30TK-0007pZ-TF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:35:15 +0000
Received: from [85.158.143.35:39083] by server-2.bemta-4.messagelabs.com id
	32/67-01597-2C512115; Wed, 06 Feb 2013 08:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360139711!5092068!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8085 invoked from network); 6 Feb 2013 08:35:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 08:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1186127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 08:35:03 +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.297.1; Wed, 6 Feb 2013
	08:35:02 +0000
Message-ID: <1360139701.9063.40.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Wed, 6 Feb 2013 08:35:01 +0000
In-Reply-To: <1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 15:58 +0000, Frediano Ziglio wrote:
> +void __init init_coverage(void)
> +{
> +    unsigned long n;
> +    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> +        __CTOR_LIST__.funcs[n]();

There is nothing coverage specific here, why not run these from a
generic function?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 08:35:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 08:35: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 1U30TL-0007pg-Hy; Wed, 06 Feb 2013 08:35: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 1U30TK-0007pZ-TF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 08:35:15 +0000
Received: from [85.158.143.35:39083] by server-2.bemta-4.messagelabs.com id
	32/67-01597-2C512115; Wed, 06 Feb 2013 08:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360139711!5092068!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMDAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8085 invoked from network); 6 Feb 2013 08:35:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 08:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1186127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 08:35:03 +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.297.1; Wed, 6 Feb 2013
	08:35:02 +0000
Message-ID: <1360139701.9063.40.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Wed, 6 Feb 2013 08:35:01 +0000
In-Reply-To: <1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 15:58 +0000, Frediano Ziglio wrote:
> +void __init init_coverage(void)
> +{
> +    unsigned long n;
> +    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> +        __CTOR_LIST__.funcs[n]();

There is nothing coverage specific here, why not run these from a
generic function?

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:13:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09:13: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 1U314H-0000TK-Oj; Wed, 06 Feb 2013 09:13:25 +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 1U314G-0000TF-D5
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:13:24 +0000
Received: from [193.109.254.147:45838] by server-2.bemta-14.messagelabs.com id
	88/BC-16277-3BE12115; Wed, 06 Feb 2013 09:13:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360142002!9307029!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27733 invoked from network); 6 Feb 2013 09:13:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:13:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1187549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:13: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.297.1; Wed, 6 Feb 2013
	09:13:09 +0000
Message-ID: <1360141988.23001.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 6 Feb 2013 09:13:08 +0000
In-Reply-To: <510FF54E.1070706@citrix.com>
References: <510FF54E.1070706@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> 
> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.

I suppose this restriction is because it is hard to change the priority
of a pending interrupt from either Xen or the guest in a lock-free
manner?

The problem is that while on one end you call EVTCHNOP_alloc_unbound and
can then change the priority on the other you call
EVTCHNOP_bind_interdomain passing (remote-domid,remote-evtcht) and
receive a local-evtchn which is already bound, which means you never get
the opportunity to set the priority. Likewise when binding virqs and
such you never get to see the unbound evtchn.

I don't think we want to go around adding priority to all of those
existing binding hypercalls.

Perhaps it would be acceptable to say that after having called this
hypercall the domain may still observe at most one upcall of the evtchn
with the old priority, which corresponds with the interrupt being raised
right before the priority change takes effect, but being delivered
after.

> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> 
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.
> EINVAL      `priority` is outside the range 0 - 15. 


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:13:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09:13: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 1U314H-0000TK-Oj; Wed, 06 Feb 2013 09:13:25 +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 1U314G-0000TF-D5
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:13:24 +0000
Received: from [193.109.254.147:45838] by server-2.bemta-14.messagelabs.com id
	88/BC-16277-3BE12115; Wed, 06 Feb 2013 09:13:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360142002!9307029!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27733 invoked from network); 6 Feb 2013 09:13:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:13:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1187549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:13: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.297.1; Wed, 6 Feb 2013
	09:13:09 +0000
Message-ID: <1360141988.23001.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 6 Feb 2013 09:13:08 +0000
In-Reply-To: <510FF54E.1070706@citrix.com>
References: <510FF54E.1070706@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> 
> ### `EVTCHNOP_set_priority`
> 
> This call sets the priority for an event channel.  The event must be
> unbound.

I suppose this restriction is because it is hard to change the priority
of a pending interrupt from either Xen or the guest in a lock-free
manner?

The problem is that while on one end you call EVTCHNOP_alloc_unbound and
can then change the priority on the other you call
EVTCHNOP_bind_interdomain passing (remote-domid,remote-evtcht) and
receive a local-evtchn which is already bound, which means you never get
the opportunity to set the priority. Likewise when binding virqs and
such you never get to see the unbound evtchn.

I don't think we want to go around adding priority to all of those
existing binding hypercalls.

Perhaps it would be acceptable to say that after having called this
hypercall the domain may still observe at most one upcall of the evtchn
with the old priority, which corresponds with the interrupt being raised
right before the priority change takes effect, but being delivered
after.

> A guest may call this prior to binding an event channel. The meaning
> and the use of the priority are up to the guest.  Valid priorities are
> 0 - 15 and the default is 7.
> 
>     struct evtchnop_set_priority {
>         uint32_t port;
>         uint32_t priority;
>     };
> 
> Field       Purpose
> -----       -------
> `port`      [in] The event channel.
> `priority`  [in] The priority for the event channel.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `port` is invalid.
> EINVAL      `port` is currently bound.
> EINVAL      `priority` is outside the range 0 - 15. 


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:36:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09:36: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 1U31QH-00012o-RI; Wed, 06 Feb 2013 09:36: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 1U31QF-00012g-RJ
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:36:08 +0000
Received: from [193.109.254.147:38118] by server-6.bemta-14.messagelabs.com id
	D4/5C-12010-70422115; Wed, 06 Feb 2013 09:36:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360143310!4146438!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27957 invoked from network); 6 Feb 2013 09:35:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1188443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:35: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.297.1; Wed, 6 Feb 2013
	09:35:10 +0000
Message-ID: <1360143309.23001.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 6 Feb 2013 09:35:09 +0000
In-Reply-To: <51114D0F.3090802@citrix.com>
References: <510FF54E.1070706@citrix.com>
	<1360080628.23001.27.camel@zakaz.uk.xensource.com>
	<51114D0F.3090802@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:18 +0000, David Vrabel wrote:
> On 05/02/13 16:10, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> >> The pages within the event array need not be physically nor virtually
> >> contiguous, but the guest or Xen may make the virtually contiguous for
> >> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> >> Linux.  Pages are added by the guest as required by the number of
> >> bound event channels.
> > 
> > Strictly speaking the size is related to the maximum bound evtchn, which
> > need not be the same as the number of bound evtchns.
> 
> Yes.
> 
> >> The state of an event is tracked using 3 bits within the event word.
> >> the M (masked), P (pending) and L (linked) bits.  Only state
> >> transitions that change a single bit are valid.
> > 
> > The diagram shows transitions B<->P and P<->L, which involve two bits in
> > each case. So do BM<->PM and LM<->BM now I think about it.
> 
> B == 000b, P == 100b, L == 101b.
> 
> Similarly for the masked transitions:
> 
> BM == 010b, PM == 110b, LM == 111b.

Ah, it wasn't clear that the states in the diagram didn't relate to the
bits directly, reusing the letters in that way is a bit confusing.

> 
> > Is the L bit redundant with the LINK field == 0 or != 0?
> 
> LINK == 0 is the end of queue marker.  We could use all ones to mean
> 'unlinked' but using the L bit allows the guest to remove the event from
> the queue by clearing a single bit, instead of writing the LINK field.

So you can use test/clear-bit instead of cmpxchg?

> >> A guest should call this during initial VCPU bring up (and on resume?).
> >>
> >>     struct evtchnop_init {
> >>         uint32_t vcpu;
> >>         uint64_t array_pfn;
> >>     };
> > 
> > I think this will have a different layout on 32 and 64 bit x86, if you
> > care (because uint64_t is align(4) on 32-bit and align(8) on 64-bit).
> 
> Ok.  I thought uint64_t was always 8 byte aligned on both.

Sadly not, it's the cause of a fair few 32- vs 64-bit ABI
differences :-(

> >> Memory Usage
> >> ------------
> >>
> >> Alternatively, we can consider a system with $D$ driver domains, each
> >> of which requires $E_D$ events, and a dom0 using the maximum number of
> >> pages (128).
> >>
> >> \begin{eqnarray*}
> >> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> >> \end{eqnarray*}
> >>
> >> With, for example, 16 driver domains each using the maximum number of pages:
> >> \begin{eqnarray*}
> >> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
> >>    & = & 129 \times 10^3\text{ VMs}
> >> \end{eqnarray*}
> > 
> > This accounts for the driver domains and dom0 but not the domains which
> > they are serving, doesn't it?
> 
> This is calculating the number of pages left once those used for dom0
> and the driver domains are used.  This is the same as the number of
> supportable VMs since the other VMs only require a page.

Ah, makes sense.

> >> In summary, there is space to map the event arrays for over 100,000
> >> VMs.  This is more than the limit imposed by the 16 bit domain ID
> >> (~32,000 VMs).
> > 
> > Is there scope to reduce the maximum then?
> 
> Maximum of what?

I suppose the maximum number of pages a domain can use for evtchn
queues.

> 
> >> ### Control Block
> >>
> >> With $L$ priority levels and two 32-bit words for the head and tail
> >> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> >> for the control block is:
> >> \begin{eqnarray*}
> >> S & = & L \times 2 \times 4 \\
> >>   & = & 16 \times 2 \times 4 \\
> >>   & = & 128\text{ bytes}
> >> \end{eqnarray*}
> >>
> >> There is more than enough space within `struct vcpu_info` for the
> >> control block while still keeping plenty of space for future use.
> > 
> > There is? I can see 7 bytes of padding and 4 bytes of evtchn_pending_sel
> > which I suppose becomes redundant now.
> > 
> > I don't think it would be a problem to predicate use of this new
> > interface on the use of the VCPU_placement API and therefore give scope
> > to expand the vcpu_info.
> 
> I should have taken a proper look at where the vcpu_info comes from...
> Oops.
> 
> We can add a new VCPUOP_register_vcpu_info_and_control_block which will
> add a struct vcpu_info and the control block.

Better to either say that using the new ABI requires the guest to have
reserved space after vcpu_info or to have a separate call for the
control block (which could have the constraint that it is on the same
page as vcpu_nfo)

> >> Low Level Design
> >> ================
> >>
> >> In the pseudo code in this section, all memory accesses are atomic,
> >> including those to bit-fields within the event word.
> > 
> >> These variables have a standard meaning:
> >>
> >> Variable  Purpose
> >> --------  -------
> >> E         Event array.
> >> p         A specific event.
> >> H         The head index for a specific priority.
> >> T         The tail index for a specific priority.
> >>
> >> These memory barriers are required:
> >>
> >> Function  Purpose
> >> --------  -------
> >> mb()      Full (read/write) memory barrier
> >>
> >> Raising an Event
> >> ----------------
> >>
> >> When Xen raises an event it marks it pending and (if it is not masked)
> >> adds it tail of event queue.
> > 
> > What are the conditions for actually performing the upcall when
> > returning from the hypervisor to the guest?
> 
> Any H != 0 for that VCPU.  This means we should have a per-VCPU bitmap
> of non empty queues.

You need to be careful here since if two evtchn's are raised near
simultaneously then you will return to the guest with H == +2, and do an
upcall. If in the course of handling the first interrupt you make a
hypercall you will be returning with H == +1, but you won't want to
reinject.

Which makes me wonder about handling of IRQ priority, is the intention
that if a higher priority interrupt occurs while you are processing an
existing upcall then it will be interrupted for the new higher priority
one? In which case we need to have an IRQL concept which allows the
domain to re-enable interrupts while masking interrupts at the current
or lower priority.

Or perhaps it is acceptable to say that a domain will always finish
handling the current IRQ before it takes the higher priority one.

Should we have a bitmask of pending priorities so the guest doesn't have
to check all the queues? It's only 15/16 queues but since most evtchns
probably remain at level 7 that's still a bit wasteful, especially if
you need to restart the scan after every interrupt to implement
prioritisation.

> >> Concurrent access by Xen to the event queue must be protected by a
> >> per-event queue spin lock.
> >>
> >> Consuming Events
> >> ----------------
> >>
> >> The guests consumes events starting at the head until it reaches the
> >> tail.  Events in the queue that are not pending or are masked are
> >> consumed but not handled.
> >>
> >>     while H != 0
> >>         p = H
> >>         H = E[p].link
> >>         if H == 0
> >>             mb()
> >>             H = E[p].link
> >>         E[H].linked = 0
> > 
> > Did you mean E[p].linked here?
> > 
> > If at this point the interrupt is reraised then the if in the raising
> > pseudo code becomes true, linked will set again and don't we also race
> > with the clearing of E[p].pending below?
> 
> The event will be correctly linked and then we clear P,

By P you mean E[p].pending in the pseudo-code terminology?

>  when we consume
> the linked event it will be ignored as P is already clear.

So we will miss the second interrupt?

> Perhaps we could also avoid linking the event if it is already pending?
> 
> >>> Note: When the event queue contains a single event, removing the
> >>> event may race with Xen appending another event because the load of
> >>> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> >>> the guest must recheck `E[p].link` if the list appeared empty.
> > 
> > It appears that both "Raising an Event" and "Consuming Events" can write
> > H? Is that correct? Likewise for the linked bit.
> 
> Xen only writes H when the queue is empty, the VM only writes H if it is
> non-empty.
> 
> The linked bit is set by Xen and cleared by the guest.
> 
> Do you see a problem with this?

You'd need to be careful about the barriers and think hard about the
case where the VM is emptying the queue at the same time as Xen is
injecting a new interrupt and therefore unemptying it. And vice-versa.

> > It's a bit unclear because the pseudo-code doesn't make it explicitly
> > which variables are par of the shared data structure and which are
> > private to the local routine.
> 
> Capital variables are in the shared structures.  Lower-case are local.
> 
> >> Masking Events
> >> --------------
> >>
> >> Events are masked by setting the masked bit.  If the event is pending
> >> and linked it does not need to be unlinked.
> >>
> >>     E[p].masked = 1
> >>
> >> Unmasking Events
> >> ----------------
> >>
> >> Events are unmasked by the guest by clearing the masked bit.  If the
> >> event is pending the guest must call the event channel unmask
> >> hypercall so Xen can link the event into the correct event queue.
> >>
> >>     E[p].masked = 0
> >>     if E[p].pending
> >>         hypercall(EVTCHN_unmask)
> > 
> > Can the hypercall do the E[p].masked = 0?
> 
> Sure.

Perhaps I should have said "Should..." :-)

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:36:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09:36: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 1U31QH-00012o-RI; Wed, 06 Feb 2013 09:36: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 1U31QF-00012g-RJ
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:36:08 +0000
Received: from [193.109.254.147:38118] by server-6.bemta-14.messagelabs.com id
	D4/5C-12010-70422115; Wed, 06 Feb 2013 09:36:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360143310!4146438!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27957 invoked from network); 6 Feb 2013 09:35:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1188443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:35: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.297.1; Wed, 6 Feb 2013
	09:35:10 +0000
Message-ID: <1360143309.23001.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 6 Feb 2013 09:35:09 +0000
In-Reply-To: <51114D0F.3090802@citrix.com>
References: <510FF54E.1070706@citrix.com>
	<1360080628.23001.27.camel@zakaz.uk.xensource.com>
	<51114D0F.3090802@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:18 +0000, David Vrabel wrote:
> On 05/02/13 16:10, Ian Campbell wrote:
> > On Mon, 2013-02-04 at 17:52 +0000, David Vrabel wrote:
> >> The pages within the event array need not be physically nor virtually
> >> contiguous, but the guest or Xen may make the virtually contiguous for
> >> ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
> >> Linux.  Pages are added by the guest as required by the number of
> >> bound event channels.
> > 
> > Strictly speaking the size is related to the maximum bound evtchn, which
> > need not be the same as the number of bound evtchns.
> 
> Yes.
> 
> >> The state of an event is tracked using 3 bits within the event word.
> >> the M (masked), P (pending) and L (linked) bits.  Only state
> >> transitions that change a single bit are valid.
> > 
> > The diagram shows transitions B<->P and P<->L, which involve two bits in
> > each case. So do BM<->PM and LM<->BM now I think about it.
> 
> B == 000b, P == 100b, L == 101b.
> 
> Similarly for the masked transitions:
> 
> BM == 010b, PM == 110b, LM == 111b.

Ah, it wasn't clear that the states in the diagram didn't relate to the
bits directly, reusing the letters in that way is a bit confusing.

> 
> > Is the L bit redundant with the LINK field == 0 or != 0?
> 
> LINK == 0 is the end of queue marker.  We could use all ones to mean
> 'unlinked' but using the L bit allows the guest to remove the event from
> the queue by clearing a single bit, instead of writing the LINK field.

So you can use test/clear-bit instead of cmpxchg?

> >> A guest should call this during initial VCPU bring up (and on resume?).
> >>
> >>     struct evtchnop_init {
> >>         uint32_t vcpu;
> >>         uint64_t array_pfn;
> >>     };
> > 
> > I think this will have a different layout on 32 and 64 bit x86, if you
> > care (because uint64_t is align(4) on 32-bit and align(8) on 64-bit).
> 
> Ok.  I thought uint64_t was always 8 byte aligned on both.

Sadly not, it's the cause of a fair few 32- vs 64-bit ABI
differences :-(

> >> Memory Usage
> >> ------------
> >>
> >> Alternatively, we can consider a system with $D$ driver domains, each
> >> of which requires $E_D$ events, and a dom0 using the maximum number of
> >> pages (128).
> >>
> >> \begin{eqnarray*}
> >> V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
> >> \end{eqnarray*}
> >>
> >> With, for example, 16 driver domains each using the maximum number of pages:
> >> \begin{eqnarray*}
> >> V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
> >>    & = & 129 \times 10^3\text{ VMs}
> >> \end{eqnarray*}
> > 
> > This accounts for the driver domains and dom0 but not the domains which
> > they are serving, doesn't it?
> 
> This is calculating the number of pages left once those used for dom0
> and the driver domains are used.  This is the same as the number of
> supportable VMs since the other VMs only require a page.

Ah, makes sense.

> >> In summary, there is space to map the event arrays for over 100,000
> >> VMs.  This is more than the limit imposed by the 16 bit domain ID
> >> (~32,000 VMs).
> > 
> > Is there scope to reduce the maximum then?
> 
> Maximum of what?

I suppose the maximum number of pages a domain can use for evtchn
queues.

> 
> >> ### Control Block
> >>
> >> With $L$ priority levels and two 32-bit words for the head and tail
> >> indexes, the amount of space ($S$) required in the `struct vcpu_info`
> >> for the control block is:
> >> \begin{eqnarray*}
> >> S & = & L \times 2 \times 4 \\
> >>   & = & 16 \times 2 \times 4 \\
> >>   & = & 128\text{ bytes}
> >> \end{eqnarray*}
> >>
> >> There is more than enough space within `struct vcpu_info` for the
> >> control block while still keeping plenty of space for future use.
> > 
> > There is? I can see 7 bytes of padding and 4 bytes of evtchn_pending_sel
> > which I suppose becomes redundant now.
> > 
> > I don't think it would be a problem to predicate use of this new
> > interface on the use of the VCPU_placement API and therefore give scope
> > to expand the vcpu_info.
> 
> I should have taken a proper look at where the vcpu_info comes from...
> Oops.
> 
> We can add a new VCPUOP_register_vcpu_info_and_control_block which will
> add a struct vcpu_info and the control block.

Better to either say that using the new ABI requires the guest to have
reserved space after vcpu_info or to have a separate call for the
control block (which could have the constraint that it is on the same
page as vcpu_nfo)

> >> Low Level Design
> >> ================
> >>
> >> In the pseudo code in this section, all memory accesses are atomic,
> >> including those to bit-fields within the event word.
> > 
> >> These variables have a standard meaning:
> >>
> >> Variable  Purpose
> >> --------  -------
> >> E         Event array.
> >> p         A specific event.
> >> H         The head index for a specific priority.
> >> T         The tail index for a specific priority.
> >>
> >> These memory barriers are required:
> >>
> >> Function  Purpose
> >> --------  -------
> >> mb()      Full (read/write) memory barrier
> >>
> >> Raising an Event
> >> ----------------
> >>
> >> When Xen raises an event it marks it pending and (if it is not masked)
> >> adds it tail of event queue.
> > 
> > What are the conditions for actually performing the upcall when
> > returning from the hypervisor to the guest?
> 
> Any H != 0 for that VCPU.  This means we should have a per-VCPU bitmap
> of non empty queues.

You need to be careful here since if two evtchn's are raised near
simultaneously then you will return to the guest with H == +2, and do an
upcall. If in the course of handling the first interrupt you make a
hypercall you will be returning with H == +1, but you won't want to
reinject.

Which makes me wonder about handling of IRQ priority, is the intention
that if a higher priority interrupt occurs while you are processing an
existing upcall then it will be interrupted for the new higher priority
one? In which case we need to have an IRQL concept which allows the
domain to re-enable interrupts while masking interrupts at the current
or lower priority.

Or perhaps it is acceptable to say that a domain will always finish
handling the current IRQ before it takes the higher priority one.

Should we have a bitmask of pending priorities so the guest doesn't have
to check all the queues? It's only 15/16 queues but since most evtchns
probably remain at level 7 that's still a bit wasteful, especially if
you need to restart the scan after every interrupt to implement
prioritisation.

> >> Concurrent access by Xen to the event queue must be protected by a
> >> per-event queue spin lock.
> >>
> >> Consuming Events
> >> ----------------
> >>
> >> The guests consumes events starting at the head until it reaches the
> >> tail.  Events in the queue that are not pending or are masked are
> >> consumed but not handled.
> >>
> >>     while H != 0
> >>         p = H
> >>         H = E[p].link
> >>         if H == 0
> >>             mb()
> >>             H = E[p].link
> >>         E[H].linked = 0
> > 
> > Did you mean E[p].linked here?
> > 
> > If at this point the interrupt is reraised then the if in the raising
> > pseudo code becomes true, linked will set again and don't we also race
> > with the clearing of E[p].pending below?
> 
> The event will be correctly linked and then we clear P,

By P you mean E[p].pending in the pseudo-code terminology?

>  when we consume
> the linked event it will be ignored as P is already clear.

So we will miss the second interrupt?

> Perhaps we could also avoid linking the event if it is already pending?
> 
> >>> Note: When the event queue contains a single event, removing the
> >>> event may race with Xen appending another event because the load of
> >>> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> >>> the guest must recheck `E[p].link` if the list appeared empty.
> > 
> > It appears that both "Raising an Event" and "Consuming Events" can write
> > H? Is that correct? Likewise for the linked bit.
> 
> Xen only writes H when the queue is empty, the VM only writes H if it is
> non-empty.
> 
> The linked bit is set by Xen and cleared by the guest.
> 
> Do you see a problem with this?

You'd need to be careful about the barriers and think hard about the
case where the VM is emptying the queue at the same time as Xen is
injecting a new interrupt and therefore unemptying it. And vice-versa.

> > It's a bit unclear because the pseudo-code doesn't make it explicitly
> > which variables are par of the shared data structure and which are
> > private to the local routine.
> 
> Capital variables are in the shared structures.  Lower-case are local.
> 
> >> Masking Events
> >> --------------
> >>
> >> Events are masked by setting the masked bit.  If the event is pending
> >> and linked it does not need to be unlinked.
> >>
> >>     E[p].masked = 1
> >>
> >> Unmasking Events
> >> ----------------
> >>
> >> Events are unmasked by the guest by clearing the masked bit.  If the
> >> event is pending the guest must call the event channel unmask
> >> hypercall so Xen can link the event into the correct event queue.
> >>
> >>     E[p].masked = 0
> >>     if E[p].pending
> >>         hypercall(EVTCHN_unmask)
> > 
> > Can the hypercall do the E[p].masked = 0?
> 
> Sure.

Perhaps I should have said "Should..." :-)

Ian.



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:37:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09: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 1U31RL-00015d-Ex; Wed, 06 Feb 2013 09:37:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U31RK-00015T-1p
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:37:14 +0000
Received: from [85.158.143.99:47164] by server-3.bemta-4.messagelabs.com id
	D5/71-08920-94422115; Wed, 06 Feb 2013 09:37:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360143432!25115777!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28506 invoked from network); 6 Feb 2013 09:37:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1188547"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:37:13 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 6 Feb 2013
	09:37:12 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 09:37:12 +0000
Thread-Topic: [PATCH 1/4] Adding support for coverage information
Thread-Index: Ac4ETYqmaOm3u7rJR3mqY6MQBw8dfA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458365@LONPMAILBOX01.citrite.net>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
	<1360139701.9063.40.camel@dagon.hellion.org.uk>
In-Reply-To: <1360139701.9063.40.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 08:35 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 15:58 +0000, Frediano Ziglio wrote:
> > +void __init init_coverage(void)
> > +{
> > +    unsigned long n;
> > +    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> > +        __CTOR_LIST__.funcs[n]();
> 
> There is nothing coverage specific here, why not run these from a
> generic function?
> 
> Ian.
> 
> 

You are right, but currently are only used for coverage and constructors
are not expected to be useful in Xen.

One more question. The __CTOR_LIST__ name and the counters before the
array it's a choice following GCC convention but there is no need to
follow it. Do you thing a better name and perhaps just the array with a
final NULL of a pointer to the end would be better?

Frediano

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:37:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09: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 1U31RL-00015d-Ex; Wed, 06 Feb 2013 09:37:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U31RK-00015T-1p
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:37:14 +0000
Received: from [85.158.143.99:47164] by server-3.bemta-4.messagelabs.com id
	D5/71-08920-94422115; Wed, 06 Feb 2013 09:37:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360143432!25115777!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28506 invoked from network); 6 Feb 2013 09:37:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1188547"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:37:13 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 6 Feb 2013
	09:37:12 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 09:37:12 +0000
Thread-Topic: [PATCH 1/4] Adding support for coverage information
Thread-Index: Ac4ETYqmaOm3u7rJR3mqY6MQBw8dfA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458365@LONPMAILBOX01.citrite.net>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-2-git-send-email-frediano.ziglio@citrix.com>
	<1360139701.9063.40.camel@dagon.hellion.org.uk>
In-Reply-To: <1360139701.9063.40.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 08:35 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 15:58 +0000, Frediano Ziglio wrote:
> > +void __init init_coverage(void)
> > +{
> > +    unsigned long n;
> > +    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> > +        __CTOR_LIST__.funcs[n]();
> 
> There is nothing coverage specific here, why not run these from a
> generic function?
> 
> Ian.
> 
> 

You are right, but currently are only used for coverage and constructors
are not expected to be useful in Xen.

One more question. The __CTOR_LIST__ name and the counters before the
array it's a choice following GCC convention but there is no need to
follow it. Do you thing a better name and perhaps just the array with a
final NULL of a pointer to the end would be better?

Frediano

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:48:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09:48: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 1U31bv-0001ZH-Kq; Wed, 06 Feb 2013 09:48: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 1U31bt-0001ZC-M5
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:48:09 +0000
Received: from [85.158.143.35:6268] by server-2.bemta-4.messagelabs.com id
	80/92-01597-9D622115; Wed, 06 Feb 2013 09:48:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360143521!13897121!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29354 invoked from network); 6 Feb 2013 09:38:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:38:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1188602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:38: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.297.1; Wed, 6 Feb 2013
	09:38:41 +0000
Message-ID: <1360143520.23001.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Wed, 6 Feb 2013 09:38:40 +0000
In-Reply-To: <CD36F999.5A4AC%keir@xen.org>
References: <CD36F999.5A4AC%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >>> Okay, I wonder how much it actually matters anyhow...
> >>> 
> >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> >>> So how does that work then?
> >> 
> >> I meant struct vcpu_info can be extended without it growing to more than
> >> a page.  i.e., it fits into the guest page provided in the
> >> VCPUOP_register_vcpu_info call so no additional pages need to be
> >> globally mapped for the control block.
> > 
> > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > by itself, even if that happens to be the Linux implementation today (I
> > haven't checked that).
> 
> Having guest agree that vcpu_info grows by size of the per-vcpu control
> block, if using this new event-channel interface, is reasonable though.

Can only use this trick once though, so it might be blocking ourselves
into a future ABI corner.

Is there a downside to registering the control block separately? The
guest can always arrange for them to be contiguous if it wants, or if we
are worried about the number of global mappings then the hypervisor
could require it shares a page with the vcpu_info but allow the offset
to be specified separately.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:48:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 09:48: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 1U31bv-0001ZH-Kq; Wed, 06 Feb 2013 09:48: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 1U31bt-0001ZC-M5
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 09:48:09 +0000
Received: from [85.158.143.35:6268] by server-2.bemta-4.messagelabs.com id
	80/92-01597-9D622115; Wed, 06 Feb 2013 09:48:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360143521!13897121!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29354 invoked from network); 6 Feb 2013 09:38:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:38:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1188602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:38: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.297.1; Wed, 6 Feb 2013
	09:38:41 +0000
Message-ID: <1360143520.23001.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Wed, 6 Feb 2013 09:38:40 +0000
In-Reply-To: <CD36F999.5A4AC%keir@xen.org>
References: <CD36F999.5A4AC%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >>> Okay, I wonder how much it actually matters anyhow...
> >>> 
> >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> >>> So how does that work then?
> >> 
> >> I meant struct vcpu_info can be extended without it growing to more than
> >> a page.  i.e., it fits into the guest page provided in the
> >> VCPUOP_register_vcpu_info call so no additional pages need to be
> >> globally mapped for the control block.
> > 
> > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > by itself, even if that happens to be the Linux implementation today (I
> > haven't checked that).
> 
> Having guest agree that vcpu_info grows by size of the per-vcpu control
> block, if using this new event-channel interface, is reasonable though.

Can only use this trick once though, so it might be blocking ourselves
into a future ABI corner.

Is there a downside to registering the control block separately? The
guest can always arrange for them to be contiguous if it wants, or if we
are worried about the number of global mappings then the hypervisor
could require it shares a page with the vcpu_info but allow the offset
to be specified separately.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:58:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U31lL-0001vT-O4; Wed, 06 Feb 2013 09:57: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 1U31lJ-0001vO-Mg
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 09:57:53 +0000
Received: from [85.158.143.99:13736] by server-2.bemta-4.messagelabs.com id
	8F/F2-01597-12922115; Wed, 06 Feb 2013 09:57:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360144664!22845865!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5553 invoked from network); 6 Feb 2013 09:57:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:57:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1189518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:57: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.297.1; Wed, 6 Feb 2013 09:57:44 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U31l9-0004nU-LK;
	Wed, 06 Feb 2013 09:57:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U31l9-0004dk-Kh;
	Wed, 06 Feb 2013 09:57:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15430-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 09:57:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15430: 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 15430 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15430/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15417

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  6c1b12c884b4
baseline version:
 xen                  d1bf3b21f783

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Eddie Dong <eddie.dong@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Sander Eikelenboom <linux@eikelenboom.it>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=6c1b12c884b4
+ . 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 6c1b12c884b4
+ branch=xen-unstable
+ revision=6c1b12c884b4
+ . 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/hg/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 6c1b12c884b4 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 18 changesets with 39 changes to 34 files

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 09:58:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U31lL-0001vT-O4; Wed, 06 Feb 2013 09:57: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 1U31lJ-0001vO-Mg
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 09:57:53 +0000
Received: from [85.158.143.99:13736] by server-2.bemta-4.messagelabs.com id
	8F/F2-01597-12922115; Wed, 06 Feb 2013 09:57:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360144664!22845865!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5553 invoked from network); 6 Feb 2013 09:57:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 09:57:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1189518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 09:57: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.297.1; Wed, 6 Feb 2013 09:57:44 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U31l9-0004nU-LK;
	Wed, 06 Feb 2013 09:57:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U31l9-0004dk-Kh;
	Wed, 06 Feb 2013 09:57:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15430-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 09:57:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15430: 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 15430 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15430/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15417
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15417

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  6c1b12c884b4
baseline version:
 xen                  d1bf3b21f783

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  Eddie Dong <eddie.dong@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Sander Eikelenboom <linux@eikelenboom.it>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=6c1b12c884b4
+ . 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 6c1b12c884b4
+ branch=xen-unstable
+ revision=6c1b12c884b4
+ . 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/hg/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 6c1b12c884b4 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 18 changesets with 39 changes to 34 files

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 10:25:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:25: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 1U32By-0003Li-0E; Wed, 06 Feb 2013 10:25: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 1U32Bw-0003Ld-GS
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 10:25:24 +0000
Received: from [85.158.143.99:15201] by server-2.bemta-4.messagelabs.com id
	A2/50-01597-39F22115; Wed, 06 Feb 2013 10:25:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360146211!31045241!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23541 invoked from network); 6 Feb 2013 10:23:33 -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; 6 Feb 2013 10:23:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 10:23:30 +0000
Message-Id: <51123D3102000078000BC61B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 10:23:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <165496354.20130205221901@eikelenboom.it>
In-Reply-To: <165496354.20130205221901@eikelenboom.it>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part35057B31.2__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part35057B31.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 05.02.13 at 22:19, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Boot of xen-unstable is broken due to changeset 26517 on a AMD 890-FX=20
> motherboard.
> The serial log is attached.

Yeah, we were afraid of that. Unfortunately the log you provided,
while very detailed, doesn't really make clear to me what is going
wrong. In particular, considering there is a NULL pointer there
(which I can only guess is the new pin_setup pointer), I would
have expected it to crash earlier. Hence I'm attaching a patch
which closes a hole in the logic, but is unlikely to address your
problem. The added debugging output should help, but please
also make available the xen-syms image in case the patch - as
expected - doesn't help and that system of yours still crashes.

Jan


--=__Part35057B31.2__=
Content-Type: text/plain; name="AMD-IOMMU-IVHD-special-debug.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-IVHD-special-debug.patch"

--- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+++ b/xen/drivers/passthro=
ugh/amd/iommu_acpi.c=0A@@ -354,9 +354,8 @@ static int __init parse_ivmd_blo=
ck(const=0A     base =3D start_addr & PAGE_MASK;=0A     limit =3D =
(start_addr + mem_length - 1) & PAGE_MASK;=0A =0A-    AMD_IOMMU_DEBUG("IVMD=
 Block: Type %#x\n",ivmd_block->header.type);=0A-    AMD_IOMMU_DEBUG(" =
Start_Addr_Phys %#lx\n", start_addr);=0A-    AMD_IOMMU_DEBUG(" Mem_Length =
%#lx\n", mem_length);=0A+    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys =
%#lx len %#lx\n",=0A+                    ivmd_block->header.type, =
start_addr, mem_length);=0A =0A     if ( ivmd_block->header.flags & =
ACPI_IVMD_EXCLUSION_RANGE )=0A         iw =3D ir =3D IOMMU_CONTROL_ENABLED;=
=0A@@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia=0A         =
return 0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> =
%#x\n", first_bdf, last_bdf);=0A-    AMD_IOMMU_DEBUG(" Dev_Id Alias: =
%#x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias =
%#x\n",=0A+                    first_bdf, last_bdf, alias_id);=0A =0A     =
for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )=0A         add_ivrs_map=
ping_entry(bdf, alias_id, range->alias.header.data_setting,=0A@@ -654,6 =
+653,9 @@ static u16 __init parse_ivhd_device_spec=0A         return 0;=0A =
    }=0A =0A+    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety =
%#x handle %#x\n",=0A+                    seg, PCI_BUS(bdf), PCI_SLOT(bdf),=
 PCI_FUNC(bdf),=0A+                    special->variety, special->handle);=
=0A     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);=0A =0A     switch ( special->variety )=0A@@ -758,10 +760,9 @@ =
static int __init parse_ivhd_block(const=0A     {=0A         ivhd_device =
=3D (const void *)((const u8 *)ivhd_block + block_length);=0A =0A-        =
AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A-        AMD_IOMMU_DEBUG( " =
Type %#x\n", ivhd_device->header.type);=0A-        AMD_IOMMU_DEBUG( " =
Dev_Id %#x\n", ivhd_device->header.id);=0A-        AMD_IOMMU_DEBUG( " =
Flags %#x\n", ivhd_device->header.data_setting);=0A+        AMD_IOMMU_DEBUG=
("IVHD Device Entry: type %#x id %#x flags %#x\n",=0A+                     =
   ivhd_device->header.type, ivhd_device->header.id,=0A+                   =
     ivhd_device->header.data_setting);=0A =0A         switch ( ivhd_device=
->header.type )=0A         {=0A@@ -890,6 +891,7 @@ static int __init =
parse_ivrs_table(struc=0A {=0A     const struct acpi_ivrs_header *ivrs_bloc=
k;=0A     unsigned long length;=0A+    unsigned int apic;=0A     int error =
=3D 0;=0A =0A     BUG_ON(!table);=0A@@ -903,11 +905,9 @@ static int __init =
parse_ivrs_table(struc=0A     {=0A         ivrs_block =3D (struct =
acpi_ivrs_header *)((u8 *)table + length);=0A =0A-        AMD_IOMMU_DEBUG("=
IVRS Block:\n");=0A-        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type=
);=0A-        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);=0A-      =
  AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);=0A-        =
AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);=0A+        =
AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id %#x\n",=0A+     =
                   ivrs_block->type, ivrs_block->flags,=0A+                =
        ivrs_block->length, ivrs_block->device_id);=0A =0A         if ( =
table->length < (length + ivrs_block->length) )=0A         {=0A@@ -922,6 =
+922,29 @@ static int __init parse_ivrs_table(struc=0A         length +=3D =
ivrs_block->length;=0A     }=0A =0A+    /* Each IO-APIC must have been =
mentioned in the table. */=0A+    for ( apic =3D 0; !error && apic < =
nr_ioapics; ++apic )=0A+    {=0A+        if ( !nr_ioapic_entries[apic] =
||=0A+             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )=0A+           =
 continue;=0A+=0A+        printk(XENLOG_ERR "IVHD Error: no information =
for IO-APIC %#x\n",=0A+               IO_APIC_ID(apic));=0A+        if ( =
amd_iommu_perdev_intremap )=0A+            error =3D -ENXIO;=0A+        =
else=0A+        {=0A+            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =
=3D xzalloc_array(=0A+                unsigned long, BITS_TO_LONGS(nr_ioapi=
c_entries[apic]));=0A+            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_s=
etup )=0A+            {=0A+                printk(XENLOG_ERR "IVHD Error: =
Out of memory\n");=0A+                error =3D -ENOMEM;=0A+            =
}=0A+        }=0A+    }=0A+=0A     return error;=0A }=0A =0A
--=__Part35057B31.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part35057B31.2__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 10:25:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:25: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 1U32By-0003Li-0E; Wed, 06 Feb 2013 10:25: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 1U32Bw-0003Ld-GS
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 10:25:24 +0000
Received: from [85.158.143.99:15201] by server-2.bemta-4.messagelabs.com id
	A2/50-01597-39F22115; Wed, 06 Feb 2013 10:25:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360146211!31045241!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23541 invoked from network); 6 Feb 2013 10:23:33 -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; 6 Feb 2013 10:23:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 10:23:30 +0000
Message-Id: <51123D3102000078000BC61B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 10:23:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <165496354.20130205221901@eikelenboom.it>
In-Reply-To: <165496354.20130205221901@eikelenboom.it>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part35057B31.2__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part35057B31.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 05.02.13 at 22:19, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Boot of xen-unstable is broken due to changeset 26517 on a AMD 890-FX=20
> motherboard.
> The serial log is attached.

Yeah, we were afraid of that. Unfortunately the log you provided,
while very detailed, doesn't really make clear to me what is going
wrong. In particular, considering there is a NULL pointer there
(which I can only guess is the new pin_setup pointer), I would
have expected it to crash earlier. Hence I'm attaching a patch
which closes a hole in the logic, but is unlikely to address your
problem. The added debugging output should help, but please
also make available the xen-syms image in case the patch - as
expected - doesn't help and that system of yours still crashes.

Jan


--=__Part35057B31.2__=
Content-Type: text/plain; name="AMD-IOMMU-IVHD-special-debug.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-IVHD-special-debug.patch"

--- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+++ b/xen/drivers/passthro=
ugh/amd/iommu_acpi.c=0A@@ -354,9 +354,8 @@ static int __init parse_ivmd_blo=
ck(const=0A     base =3D start_addr & PAGE_MASK;=0A     limit =3D =
(start_addr + mem_length - 1) & PAGE_MASK;=0A =0A-    AMD_IOMMU_DEBUG("IVMD=
 Block: Type %#x\n",ivmd_block->header.type);=0A-    AMD_IOMMU_DEBUG(" =
Start_Addr_Phys %#lx\n", start_addr);=0A-    AMD_IOMMU_DEBUG(" Mem_Length =
%#lx\n", mem_length);=0A+    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys =
%#lx len %#lx\n",=0A+                    ivmd_block->header.type, =
start_addr, mem_length);=0A =0A     if ( ivmd_block->header.flags & =
ACPI_IVMD_EXCLUSION_RANGE )=0A         iw =3D ir =3D IOMMU_CONTROL_ENABLED;=
=0A@@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia=0A         =
return 0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> =
%#x\n", first_bdf, last_bdf);=0A-    AMD_IOMMU_DEBUG(" Dev_Id Alias: =
%#x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias =
%#x\n",=0A+                    first_bdf, last_bdf, alias_id);=0A =0A     =
for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )=0A         add_ivrs_map=
ping_entry(bdf, alias_id, range->alias.header.data_setting,=0A@@ -654,6 =
+653,9 @@ static u16 __init parse_ivhd_device_spec=0A         return 0;=0A =
    }=0A =0A+    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety =
%#x handle %#x\n",=0A+                    seg, PCI_BUS(bdf), PCI_SLOT(bdf),=
 PCI_FUNC(bdf),=0A+                    special->variety, special->handle);=
=0A     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);=0A =0A     switch ( special->variety )=0A@@ -758,10 +760,9 @@ =
static int __init parse_ivhd_block(const=0A     {=0A         ivhd_device =
=3D (const void *)((const u8 *)ivhd_block + block_length);=0A =0A-        =
AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A-        AMD_IOMMU_DEBUG( " =
Type %#x\n", ivhd_device->header.type);=0A-        AMD_IOMMU_DEBUG( " =
Dev_Id %#x\n", ivhd_device->header.id);=0A-        AMD_IOMMU_DEBUG( " =
Flags %#x\n", ivhd_device->header.data_setting);=0A+        AMD_IOMMU_DEBUG=
("IVHD Device Entry: type %#x id %#x flags %#x\n",=0A+                     =
   ivhd_device->header.type, ivhd_device->header.id,=0A+                   =
     ivhd_device->header.data_setting);=0A =0A         switch ( ivhd_device=
->header.type )=0A         {=0A@@ -890,6 +891,7 @@ static int __init =
parse_ivrs_table(struc=0A {=0A     const struct acpi_ivrs_header *ivrs_bloc=
k;=0A     unsigned long length;=0A+    unsigned int apic;=0A     int error =
=3D 0;=0A =0A     BUG_ON(!table);=0A@@ -903,11 +905,9 @@ static int __init =
parse_ivrs_table(struc=0A     {=0A         ivrs_block =3D (struct =
acpi_ivrs_header *)((u8 *)table + length);=0A =0A-        AMD_IOMMU_DEBUG("=
IVRS Block:\n");=0A-        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type=
);=0A-        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);=0A-      =
  AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);=0A-        =
AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);=0A+        =
AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id %#x\n",=0A+     =
                   ivrs_block->type, ivrs_block->flags,=0A+                =
        ivrs_block->length, ivrs_block->device_id);=0A =0A         if ( =
table->length < (length + ivrs_block->length) )=0A         {=0A@@ -922,6 =
+922,29 @@ static int __init parse_ivrs_table(struc=0A         length +=3D =
ivrs_block->length;=0A     }=0A =0A+    /* Each IO-APIC must have been =
mentioned in the table. */=0A+    for ( apic =3D 0; !error && apic < =
nr_ioapics; ++apic )=0A+    {=0A+        if ( !nr_ioapic_entries[apic] =
||=0A+             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )=0A+           =
 continue;=0A+=0A+        printk(XENLOG_ERR "IVHD Error: no information =
for IO-APIC %#x\n",=0A+               IO_APIC_ID(apic));=0A+        if ( =
amd_iommu_perdev_intremap )=0A+            error =3D -ENXIO;=0A+        =
else=0A+        {=0A+            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =
=3D xzalloc_array(=0A+                unsigned long, BITS_TO_LONGS(nr_ioapi=
c_entries[apic]));=0A+            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_s=
etup )=0A+            {=0A+                printk(XENLOG_ERR "IVHD Error: =
Out of memory\n");=0A+                error =3D -ENOMEM;=0A+            =
}=0A+        }=0A+    }=0A+=0A     return error;=0A }=0A =0A
--=__Part35057B31.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part35057B31.2__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 10:41:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10: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 1U32RI-0003pr-I1; Wed, 06 Feb 2013 10:41:16 +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 1U32RG-0003oY-LR
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 10:41:14 +0000
Received: from [85.158.139.211:17614] by server-9.bemta-5.messagelabs.com id
	3E/E4-24440-94332115; Wed, 06 Feb 2013 10:41:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360147272!17363320!1
X-Originating-IP: [74.125.82.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22497 invoked from network); 6 Feb 2013 10:41:12 -0000
Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com)
	(74.125.82.179)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 10:41:12 -0000
Received: by mail-we0-f179.google.com with SMTP id x43so1041237wey.10
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 02:41:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=STf24TXmYiyhul2vR2+fxOftiIFYiisB+GSQ2B/5CNQ=;
	b=gkpar6byC+Ot2MwEKTGu0DRfSztmMDYlvjpkpe0QiNk2+JmizsvfBdwVY+zqrhEcCU
	Cp+lwEyEvdyBF6LM74px9fAq7TyM+5Td+FvmnwElGIiQ+BAayL02Pg/QWA+SOeqrRHnC
	+6T/ayPSrI5Sc4izZmI2c9FJwNCWh4b11L1c/QfsnqwaFaSLvoBo5BqlY7QgpxnTaNm1
	trQTecB3u1WVfcjjEFzTzhruCREC+sbHz9GJ6NJkRYwc4yywJN+4BTRm1EOM/W53BfPR
	SRreg3hRoE8FWRd0sMNEwN3v0nRz9EnD/BJnHm1TLlqhfRV7Z+K5lSE6wRt4TvWrFDNx
	LV6Q==
X-Received: by 10.195.13.11 with SMTP id eu11mr48942580wjd.39.1360147272482;
	Wed, 06 Feb 2013 02:41:12 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id fx5sm2331347wib.11.2013.02.06.02.41.08
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 02:41:11 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 06 Feb 2013 10:41:04 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CD37E3C0.5A546%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4EVnZfq+QmjggRX0WlkDxtQc6PJw==
In-Reply-To: <1360143520.23001.55.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/02/2013 09:38, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>> VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
>>> by itself, even if that happens to be the Linux implementation today (I
>>> haven't checked that).
>> 
>> Having guest agree that vcpu_info grows by size of the per-vcpu control
>> block, if using this new event-channel interface, is reasonable though.
> 
> Can only use this trick once though, so it might be blocking ourselves
> into a future ABI corner.
> 
> Is there a downside to registering the control block separately? The
> guest can always arrange for them to be contiguous if it wants, or if we
> are worried about the number of global mappings then the hypervisor
> could require it shares a page with the vcpu_info but allow the offset
> to be specified separately.

I would say we consider vcpu_info to be versioned, and that using the new
event-channel interface requires use of at least v2 of the vcpu_info
structure. There is a rsvd field in register_vcpu_info hypercall that could
be used for specifying such a thing, although sadly it is not currently
checked to be zero, so we may not actually be able to make use of those
bits.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 10:41:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10: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 1U32RI-0003pr-I1; Wed, 06 Feb 2013 10:41:16 +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 1U32RG-0003oY-LR
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 10:41:14 +0000
Received: from [85.158.139.211:17614] by server-9.bemta-5.messagelabs.com id
	3E/E4-24440-94332115; Wed, 06 Feb 2013 10:41:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360147272!17363320!1
X-Originating-IP: [74.125.82.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22497 invoked from network); 6 Feb 2013 10:41:12 -0000
Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com)
	(74.125.82.179)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 10:41:12 -0000
Received: by mail-we0-f179.google.com with SMTP id x43so1041237wey.10
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 02:41:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=STf24TXmYiyhul2vR2+fxOftiIFYiisB+GSQ2B/5CNQ=;
	b=gkpar6byC+Ot2MwEKTGu0DRfSztmMDYlvjpkpe0QiNk2+JmizsvfBdwVY+zqrhEcCU
	Cp+lwEyEvdyBF6LM74px9fAq7TyM+5Td+FvmnwElGIiQ+BAayL02Pg/QWA+SOeqrRHnC
	+6T/ayPSrI5Sc4izZmI2c9FJwNCWh4b11L1c/QfsnqwaFaSLvoBo5BqlY7QgpxnTaNm1
	trQTecB3u1WVfcjjEFzTzhruCREC+sbHz9GJ6NJkRYwc4yywJN+4BTRm1EOM/W53BfPR
	SRreg3hRoE8FWRd0sMNEwN3v0nRz9EnD/BJnHm1TLlqhfRV7Z+K5lSE6wRt4TvWrFDNx
	LV6Q==
X-Received: by 10.195.13.11 with SMTP id eu11mr48942580wjd.39.1360147272482;
	Wed, 06 Feb 2013 02:41:12 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id fx5sm2331347wib.11.2013.02.06.02.41.08
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 02:41:11 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 06 Feb 2013 10:41:04 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CD37E3C0.5A546%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4EVnZfq+QmjggRX0WlkDxtQc6PJw==
In-Reply-To: <1360143520.23001.55.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/02/2013 09:38, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>> VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
>>> by itself, even if that happens to be the Linux implementation today (I
>>> haven't checked that).
>> 
>> Having guest agree that vcpu_info grows by size of the per-vcpu control
>> block, if using this new event-channel interface, is reasonable though.
> 
> Can only use this trick once though, so it might be blocking ourselves
> into a future ABI corner.
> 
> Is there a downside to registering the control block separately? The
> guest can always arrange for them to be contiguous if it wants, or if we
> are worried about the number of global mappings then the hypervisor
> could require it shares a page with the vcpu_info but allow the offset
> to be specified separately.

I would say we consider vcpu_info to be versioned, and that using the new
event-channel interface requires use of at least v2 of the vcpu_info
structure. There is a rsvd field in register_vcpu_info hypercall that could
be used for specifying such a thing, although sadly it is not currently
checked to be zero, so we may not actually be able to make use of those
bits.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 10:42:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:42: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 1U32SD-0003yi-72; Wed, 06 Feb 2013 10:42:13 +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 1U32SB-0003yS-CK
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 10:42:11 +0000
Received: from [85.158.139.83:18077] by server-14.bemta-5.messagelabs.com id
	1E/1C-06967-28332115; Wed, 06 Feb 2013 10:42:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360147328!30208556!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9448 invoked from network); 6 Feb 2013 10:42:09 -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;
	6 Feb 2013 10:42:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="6451114"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 10:42:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 05:42:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U32S7-00061G-CV;
	Wed, 06 Feb 2013 10:42:07 +0000
Message-ID: <1360147327.7477.186.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 10:42:07 +0000
In-Reply-To: <1360143520.23001.55.camel@zakaz.uk.xensource.com>
References: <CD36F999.5A4AC%keir@xen.org>
	<1360143520.23001.55.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> > 
> > >>> Okay, I wonder how much it actually matters anyhow...
> > >>> 
> > >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> > >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > >>> So how does that work then?
> > >> 
> > >> I meant struct vcpu_info can be extended without it growing to more than
> > >> a page.  i.e., it fits into the guest page provided in the
> > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > >> globally mapped for the control block.
> > > 
> > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > > by itself, even if that happens to be the Linux implementation today (I
> > > haven't checked that).
> > 
> > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > block, if using this new event-channel interface, is reasonable though.
> 
> Can only use this trick once though, so it might be blocking ourselves
> into a future ABI corner.
> 

In practice embedding control block in vcpu_info might not be feasible
because there is a legacy array of vcpu_info in shared_info page. It is
quite easy to bloat shared_info to exceed size limit.

> Is there a downside to registering the control block separately? The
> guest can always arrange for them to be contiguous if it wants, or if we
> are worried about the number of global mappings then the hypervisor
> could require it shares a page with the vcpu_info but allow the offset
> to be specified separately.
> 

IMHO the global mapping space is the main concern. Regarding sharing
page with vcpu_info, this requires us to control the way kernel handles
its per-cpu section. But how?


Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 10:42:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:42: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 1U32SD-0003yi-72; Wed, 06 Feb 2013 10:42:13 +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 1U32SB-0003yS-CK
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 10:42:11 +0000
Received: from [85.158.139.83:18077] by server-14.bemta-5.messagelabs.com id
	1E/1C-06967-28332115; Wed, 06 Feb 2013 10:42:10 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360147328!30208556!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9448 invoked from network); 6 Feb 2013 10:42:09 -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;
	6 Feb 2013 10:42:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="6451114"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 10:42:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 05:42:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U32S7-00061G-CV;
	Wed, 06 Feb 2013 10:42:07 +0000
Message-ID: <1360147327.7477.186.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 10:42:07 +0000
In-Reply-To: <1360143520.23001.55.camel@zakaz.uk.xensource.com>
References: <CD36F999.5A4AC%keir@xen.org>
	<1360143520.23001.55.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> > 
> > >>> Okay, I wonder how much it actually matters anyhow...
> > >>> 
> > >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> > >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > >>> So how does that work then?
> > >> 
> > >> I meant struct vcpu_info can be extended without it growing to more than
> > >> a page.  i.e., it fits into the guest page provided in the
> > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > >> globally mapped for the control block.
> > > 
> > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > > by itself, even if that happens to be the Linux implementation today (I
> > > haven't checked that).
> > 
> > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > block, if using this new event-channel interface, is reasonable though.
> 
> Can only use this trick once though, so it might be blocking ourselves
> into a future ABI corner.
> 

In practice embedding control block in vcpu_info might not be feasible
because there is a legacy array of vcpu_info in shared_info page. It is
quite easy to bloat shared_info to exceed size limit.

> Is there a downside to registering the control block separately? The
> guest can always arrange for them to be contiguous if it wants, or if we
> are worried about the number of global mappings then the hypervisor
> could require it shares a page with the vcpu_info but allow the offset
> to be specified separately.
> 

IMHO the global mapping space is the main concern. Regarding sharing
page with vcpu_info, this requires us to control the way kernel handles
its per-cpu section. But how?


Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 10:43:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:43: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 1U32T3-00044D-LM; Wed, 06 Feb 2013 10:43:05 +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 1U32T2-000443-CA
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 10:43:04 +0000
Received: from [193.109.254.147:14487] by server-12.bemta-14.messagelabs.com
	id 98/B5-32582-7B332115; Wed, 06 Feb 2013 10:43:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360147231!3474790!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDQ4Mzc=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 570 invoked from network); 6 Feb 2013 10:40:31 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-6.tower-27.messagelabs.com with SMTP;
	6 Feb 2013 10:40:31 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 6970B155FD;
	Wed,  6 Feb 2013 11:40:30 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Wed,  6 Feb 2013 11:38:32 +0100
Message-Id: <1360147112-7003-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH RESEND] tools/libxl: Disable useless empty
	floppy drive with 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/libxl/libxl_dm.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51f9914..c265618 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -406,6 +406,9 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_nics = 0;
 
+        /* Disable useless empty floppy drive */
+        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
+
         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
-- 
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 Wed Feb 06 10:43:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:43: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 1U32T3-00044D-LM; Wed, 06 Feb 2013 10:43:05 +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 1U32T2-000443-CA
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 10:43:04 +0000
Received: from [193.109.254.147:14487] by server-12.bemta-14.messagelabs.com
	id 98/B5-32582-7B332115; Wed, 06 Feb 2013 10:43:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360147231!3474790!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDQ4Mzc=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 570 invoked from network); 6 Feb 2013 10:40:31 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-6.tower-27.messagelabs.com with SMTP;
	6 Feb 2013 10:40:31 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 6970B155FD;
	Wed,  6 Feb 2013 11:40:30 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Wed,  6 Feb 2013 11:38:32 +0100
Message-Id: <1360147112-7003-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH RESEND] tools/libxl: Disable useless empty
	floppy drive with 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/libxl/libxl_dm.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51f9914..c265618 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -406,6 +406,9 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_nics = 0;
 
+        /* Disable useless empty floppy drive */
+        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
+
         if (b_info->u.hvm.serial) {
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
-- 
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 Wed Feb 06 10:52:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:52: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 1U32cC-0004Sk-NK; Wed, 06 Feb 2013 10:52:32 +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 1U32cA-0004SQ-Pu
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 10:52:31 +0000
Received: from [85.158.139.211:49514] by server-16.bemta-5.messagelabs.com id
	7F/9F-14948-DE532115; Wed, 06 Feb 2013 10:52:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360147945!18567104!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6212 invoked from network); 6 Feb 2013 10:52:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 10:52:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1191999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 10:52: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.297.1; Wed, 6 Feb 2013
	10:52:25 +0000
Message-ID: <1360147944.23001.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 6 Feb 2013 10:52:24 +0000
In-Reply-To: <1360147327.7477.186.camel@zion.uk.xensource.com>
References: <CD36F999.5A4AC%keir@xen.org>
	<1360143520.23001.55.camel@zakaz.uk.xensource.com>
	<1360147327.7477.186.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 10:42 +0000, Wei Liu wrote:
> On Wed, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> > On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> > > 
> > > >>> Okay, I wonder how much it actually matters anyhow...
> > > >>> 
> > > >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> > > >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > > >>> So how does that work then?
> > > >> 
> > > >> I meant struct vcpu_info can be extended without it growing to more than
> > > >> a page.  i.e., it fits into the guest page provided in the
> > > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > > >> globally mapped for the control block.
> > > > 
> > > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > > > by itself, even if that happens to be the Linux implementation today (I
> > > > haven't checked that).
> > > 
> > > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > > block, if using this new event-channel interface, is reasonable though.
> > 
> > Can only use this trick once though, so it might be blocking ourselves
> > into a future ABI corner.
> > 
> 
> In practice embedding control block in vcpu_info might not be feasible
> because there is a legacy array of vcpu_info in shared_info page. It is
> quite easy to bloat shared_info to exceed size limit.

I don't think we need to literally add the control block to struct
vcpu_info, just require that it immediately follows the vpcu_info. This
new interface requires the use of vcpu_info placement so the legacy
array is not a concern.

> > Is there a downside to registering the control block separately? The
> > guest can always arrange for them to be contiguous if it wants, or if we
> > are worried about the number of global mappings then the hypervisor
> > could require it shares a page with the vcpu_info but allow the offset
> > to be specified separately.
> > 
> 
> IMHO the global mapping space is the main concern. Regarding sharing
> page with vcpu_info, this requires us to control the way kernel handles
> its per-cpu section. But how?

We simply require that the kernel do it right...

In this instance you would probably do:
	struct per_vcpu_info {
		struct vcpu_info ...;
		struct evtchn_control ...;
	}
and allocate that in per-cpu space. Or is there concern that this
allocation might cross a page boundary? I think it is required to be
naturally aligned (i.e. aligned to at least its own size) so that is ok.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 10:52:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 10:52: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 1U32cC-0004Sk-NK; Wed, 06 Feb 2013 10:52:32 +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 1U32cA-0004SQ-Pu
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 10:52:31 +0000
Received: from [85.158.139.211:49514] by server-16.bemta-5.messagelabs.com id
	7F/9F-14948-DE532115; Wed, 06 Feb 2013 10:52:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360147945!18567104!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6212 invoked from network); 6 Feb 2013 10:52:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 10:52:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1191999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 10:52: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.297.1; Wed, 6 Feb 2013
	10:52:25 +0000
Message-ID: <1360147944.23001.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Wed, 6 Feb 2013 10:52:24 +0000
In-Reply-To: <1360147327.7477.186.camel@zion.uk.xensource.com>
References: <CD36F999.5A4AC%keir@xen.org>
	<1360143520.23001.55.camel@zakaz.uk.xensource.com>
	<1360147327.7477.186.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 10:42 +0000, Wei Liu wrote:
> On Wed, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> > On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> > > 
> > > >>> Okay, I wonder how much it actually matters anyhow...
> > > >>> 
> > > >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> > > >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > > >>> So how does that work then?
> > > >> 
> > > >> I meant struct vcpu_info can be extended without it growing to more than
> > > >> a page.  i.e., it fits into the guest page provided in the
> > > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > > >> globally mapped for the control block.
> > > > 
> > > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > > > by itself, even if that happens to be the Linux implementation today (I
> > > > haven't checked that).
> > > 
> > > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > > block, if using this new event-channel interface, is reasonable though.
> > 
> > Can only use this trick once though, so it might be blocking ourselves
> > into a future ABI corner.
> > 
> 
> In practice embedding control block in vcpu_info might not be feasible
> because there is a legacy array of vcpu_info in shared_info page. It is
> quite easy to bloat shared_info to exceed size limit.

I don't think we need to literally add the control block to struct
vcpu_info, just require that it immediately follows the vpcu_info. This
new interface requires the use of vcpu_info placement so the legacy
array is not a concern.

> > Is there a downside to registering the control block separately? The
> > guest can always arrange for them to be contiguous if it wants, or if we
> > are worried about the number of global mappings then the hypervisor
> > could require it shares a page with the vcpu_info but allow the offset
> > to be specified separately.
> > 
> 
> IMHO the global mapping space is the main concern. Regarding sharing
> page with vcpu_info, this requires us to control the way kernel handles
> its per-cpu section. But how?

We simply require that the kernel do it right...

In this instance you would probably do:
	struct per_vcpu_info {
		struct vcpu_info ...;
		struct evtchn_control ...;
	}
and allocate that in per-cpu space. Or is there concern that this
allocation might cross a page boundary? I think it is required to be
naturally aligned (i.e. aligned to at least its own size) so that is ok.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:04:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U32nB-0004xK-VQ; Wed, 06 Feb 2013 11:03:53 +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 1U32nA-0004xF-Nu
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:03:53 +0000
Received: from [85.158.137.99:8291] by server-14.bemta-3.messagelabs.com id
	CD/50-23533-89832115; Wed, 06 Feb 2013 11:03:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360148631!20207898!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2524 invoked from network); 6 Feb 2013 11:03:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:03:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1192567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:03: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.297.1; Wed, 6 Feb 2013 11:03:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U32n8-00057Q-Ly; Wed, 06 Feb 2013 11:03:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U32n8-0006Oy-Gg;
	Wed, 06 Feb 2013 11:03:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20754.14486.390158.293751@mariner.uk.xensource.com>
Date: Wed, 6 Feb 2013 11:03:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360139548.9063.39.camel@dagon.hellion.org.uk>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
	<1360139174.9063.38.camel@dagon.hellion.org.uk>
	<1360139548.9063.39.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] osstest: ts-xen-install: Run ldconfig after
 install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] osstest: ts-xen-install: Run ldconfig after install"):
> On Wed, 2013-02-06 at 08:26 +0000, Ian Campbell wrote:
> > BTW, I think you were going to be merging up your standalone branch into
> > osstest master, shall I rebase yet?

No, I'm afraid.  I've merged the two together but I haven't pushed the
result into staging yet.  The merge was nontrivial so you'd best wait
for it to be properly tested.

> Oh and BTW2, did you see the other standalone fixlets in
> <1357903462.20328.35.camel@zakaz.uk.xensource.com> ?

I haven't merged those yet - thanks for reminding 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 Feb 06 11:04:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U32nB-0004xK-VQ; Wed, 06 Feb 2013 11:03:53 +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 1U32nA-0004xF-Nu
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:03:53 +0000
Received: from [85.158.137.99:8291] by server-14.bemta-3.messagelabs.com id
	CD/50-23533-89832115; Wed, 06 Feb 2013 11:03:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360148631!20207898!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2524 invoked from network); 6 Feb 2013 11:03:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:03:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1192567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:03: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.297.1; Wed, 6 Feb 2013 11:03:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U32n8-00057Q-Ly; Wed, 06 Feb 2013 11:03:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U32n8-0006Oy-Gg;
	Wed, 06 Feb 2013 11:03:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20754.14486.390158.293751@mariner.uk.xensource.com>
Date: Wed, 6 Feb 2013 11:03:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360139548.9063.39.camel@dagon.hellion.org.uk>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
	<1360139174.9063.38.camel@dagon.hellion.org.uk>
	<1360139548.9063.39.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] osstest: ts-xen-install: Run ldconfig after
 install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] osstest: ts-xen-install: Run ldconfig after install"):
> On Wed, 2013-02-06 at 08:26 +0000, Ian Campbell wrote:
> > BTW, I think you were going to be merging up your standalone branch into
> > osstest master, shall I rebase yet?

No, I'm afraid.  I've merged the two together but I haven't pushed the
result into staging yet.  The merge was nontrivial so you'd best wait
for it to be properly tested.

> Oh and BTW2, did you see the other standalone fixlets in
> <1357903462.20328.35.camel@zakaz.uk.xensource.com> ?

I haven't merged those yet - thanks for reminding 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 Feb 06 11:09:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:09: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 1U32sW-00055f-PD; Wed, 06 Feb 2013 11:09: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 1U32sV-00055Z-8a
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:09:23 +0000
Received: from [85.158.143.99:24077] by server-1.bemta-4.messagelabs.com id
	7D/E6-08839-2E932115; Wed, 06 Feb 2013 11:09:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360148962!30084123!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19469 invoked from network); 6 Feb 2013 11:09:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:09:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1192850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:09: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.297.1; Wed, 6 Feb 2013
	11:09:22 +0000
Message-ID: <1360148960.23001.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 11:09:20 +0000
In-Reply-To: <20754.14486.390158.293751@mariner.uk.xensource.com>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
	<1360139174.9063.38.camel@dagon.hellion.org.uk>
	<1360139548.9063.39.camel@dagon.hellion.org.uk>
	<20754.14486.390158.293751@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
 install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 11:03 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after install"):
> > On Wed, 2013-02-06 at 08:26 +0000, Ian Campbell wrote:
> > > BTW, I think you were going to be merging up your standalone branch into
> > > osstest master, shall I rebase yet?
> 
> No, I'm afraid.  I've merged the two together but I haven't pushed the
> result into staging yet.  The merge was nontrivial so you'd best wait
> for it to be properly tested.

ACK.

> > Oh and BTW2, did you see the other standalone fixlets in
> > <1357903462.20328.35.camel@zakaz.uk.xensource.com> ?
> 
> I haven't merged those yet - thanks for reminding me.

NP.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:09:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:09: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 1U32sW-00055f-PD; Wed, 06 Feb 2013 11:09: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 1U32sV-00055Z-8a
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:09:23 +0000
Received: from [85.158.143.99:24077] by server-1.bemta-4.messagelabs.com id
	7D/E6-08839-2E932115; Wed, 06 Feb 2013 11:09:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360148962!30084123!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19469 invoked from network); 6 Feb 2013 11:09:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:09:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1192850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:09: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.297.1; Wed, 6 Feb 2013
	11:09:22 +0000
Message-ID: <1360148960.23001.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 11:09:20 +0000
In-Reply-To: <20754.14486.390158.293751@mariner.uk.xensource.com>
References: <1360073284-21326-1-git-send-email-ian.campbell@citrix.com>
	<20753.20009.426315.39002@mariner.uk.xensource.com>
	<1360139174.9063.38.camel@dagon.hellion.org.uk>
	<1360139548.9063.39.camel@dagon.hellion.org.uk>
	<20754.14486.390158.293751@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after
 install
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 11:03 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] osstest: ts-xen-install: Run ldconfig after install"):
> > On Wed, 2013-02-06 at 08:26 +0000, Ian Campbell wrote:
> > > BTW, I think you were going to be merging up your standalone branch into
> > > osstest master, shall I rebase yet?
> 
> No, I'm afraid.  I've merged the two together but I haven't pushed the
> result into staging yet.  The merge was nontrivial so you'd best wait
> for it to be properly tested.

ACK.

> > Oh and BTW2, did you see the other standalone fixlets in
> > <1357903462.20328.35.camel@zakaz.uk.xensource.com> ?
> 
> I haven't merged those yet - thanks for reminding me.

NP.

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:10:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:10: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 1U32sx-00057M-6W; Wed, 06 Feb 2013 11:09:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U32sv-000579-Io
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:09:49 +0000
Received: from [85.158.138.51:20181] by server-4.bemta-3.messagelabs.com id
	1F/25-12802-CF932115; Wed, 06 Feb 2013 11:09:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360148986!29446632!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6550 invoked from network); 6 Feb 2013 11:09:48 -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;
	6 Feb 2013 11:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="6136538"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 11:09:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 06:09:45 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U32sr-0006RE-Kp;
	Wed, 06 Feb 2013 11:09:45 +0000
Message-ID: <1360148985.2536.5.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 11:09:45 +0000
In-Reply-To: <1360147944.23001.82.camel@zakaz.uk.xensource.com>
References: <CD36F999.5A4AC%keir@xen.org>
	<1360143520.23001.55.camel@zakaz.uk.xensource.com>
	<1360147327.7477.186.camel@zion.uk.xensource.com>
	<1360147944.23001.82.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 10:52 +0000, Ian Campbell wrote:
> On Wed, 2013-02-06 at 10:42 +0000, Wei Liu wrote:
> > On Wed, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> > > On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > > > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> > > > 
> > > > >>> Okay, I wonder how much it actually matters anyhow...
> > > > >>> 
> > > > >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> > > > >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > > > >>> So how does that work then?
> > > > >> 
> > > > >> I meant struct vcpu_info can be extended without it growing to more than
> > > > >> a page.  i.e., it fits into the guest page provided in the
> > > > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > > > >> globally mapped for the control block.
> > > > > 
> > > > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > > > > by itself, even if that happens to be the Linux implementation today (I
> > > > > haven't checked that).
> > > > 
> > > > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > > > block, if using this new event-channel interface, is reasonable though.
> > > 
> > > Can only use this trick once though, so it might be blocking ourselves
> > > into a future ABI corner.
> > > 
> > 
> > In practice embedding control block in vcpu_info might not be feasible
> > because there is a legacy array of vcpu_info in shared_info page. It is
> > quite easy to bloat shared_info to exceed size limit.
> 
> I don't think we need to literally add the control block to struct
> vcpu_info, just require that it immediately follows the vpcu_info. This
> new interface requires the use of vcpu_info placement so the legacy
> array is not a concern.
> 
> > > Is there a downside to registering the control block separately? The
> > > guest can always arrange for them to be contiguous if it wants, or if we
> > > are worried about the number of global mappings then the hypervisor
> > > could require it shares a page with the vcpu_info but allow the offset
> > > to be specified separately.
> > > 
> > 
> > IMHO the global mapping space is the main concern. Regarding sharing
> > page with vcpu_info, this requires us to control the way kernel handles
> > its per-cpu section. But how?
> 
> We simply require that the kernel do it right...
> 
> In this instance you would probably do:
> 	struct per_vcpu_info {
> 		struct vcpu_info ...;
> 		struct evtchn_control ...;
> 	}
> and allocate that in per-cpu space. Or is there concern that this
> allocation might cross a page boundary? I think it is required to be
> naturally aligned (i.e. aligned to at least its own size) so that is ok.
> 

I get what you mean. ;-)

My other concern is, along this path we can save global mapping address
space, but now the burden of enabling the new interface somewhat slip to
the vcpu placement hypercall other than HYPERVISOR_event_channel_op. If
you're fine with this I will be OK too.


Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:10:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:10: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 1U32sx-00057M-6W; Wed, 06 Feb 2013 11:09:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U32sv-000579-Io
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:09:49 +0000
Received: from [85.158.138.51:20181] by server-4.bemta-3.messagelabs.com id
	1F/25-12802-CF932115; Wed, 06 Feb 2013 11:09:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360148986!29446632!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6550 invoked from network); 6 Feb 2013 11:09:48 -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;
	6 Feb 2013 11:09:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="6136538"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 11:09:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 06:09:45 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U32sr-0006RE-Kp;
	Wed, 06 Feb 2013 11:09:45 +0000
Message-ID: <1360148985.2536.5.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 11:09:45 +0000
In-Reply-To: <1360147944.23001.82.camel@zakaz.uk.xensource.com>
References: <CD36F999.5A4AC%keir@xen.org>
	<1360143520.23001.55.camel@zakaz.uk.xensource.com>
	<1360147327.7477.186.camel@zion.uk.xensource.com>
	<1360147944.23001.82.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 10:52 +0000, Ian Campbell wrote:
> On Wed, 2013-02-06 at 10:42 +0000, Wei Liu wrote:
> > On Wed, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> > > On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > > > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> > > > 
> > > > >>> Okay, I wonder how much it actually matters anyhow...
> > > > >>> 
> > > > >>> Oh by the way you say the control block is 128 bytes and will easily fit in
> > > > >>> the existing struct vcpu_info. That existing structure is 64 bytes in total.
> > > > >>> So how does that work then?
> > > > >> 
> > > > >> I meant struct vcpu_info can be extended without it growing to more than
> > > > >> a page.  i.e., it fits into the guest page provided in the
> > > > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > > > >> globally mapped for the control block.
> > > > > 
> > > > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > > > > by itself, even if that happens to be the Linux implementation today (I
> > > > > haven't checked that).
> > > > 
> > > > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > > > block, if using this new event-channel interface, is reasonable though.
> > > 
> > > Can only use this trick once though, so it might be blocking ourselves
> > > into a future ABI corner.
> > > 
> > 
> > In practice embedding control block in vcpu_info might not be feasible
> > because there is a legacy array of vcpu_info in shared_info page. It is
> > quite easy to bloat shared_info to exceed size limit.
> 
> I don't think we need to literally add the control block to struct
> vcpu_info, just require that it immediately follows the vpcu_info. This
> new interface requires the use of vcpu_info placement so the legacy
> array is not a concern.
> 
> > > Is there a downside to registering the control block separately? The
> > > guest can always arrange for them to be contiguous if it wants, or if we
> > > are worried about the number of global mappings then the hypervisor
> > > could require it shares a page with the vcpu_info but allow the offset
> > > to be specified separately.
> > > 
> > 
> > IMHO the global mapping space is the main concern. Regarding sharing
> > page with vcpu_info, this requires us to control the way kernel handles
> > its per-cpu section. But how?
> 
> We simply require that the kernel do it right...
> 
> In this instance you would probably do:
> 	struct per_vcpu_info {
> 		struct vcpu_info ...;
> 		struct evtchn_control ...;
> 	}
> and allocate that in per-cpu space. Or is there concern that this
> allocation might cross a page boundary? I think it is required to be
> naturally aligned (i.e. aligned to at least its own size) so that is ok.
> 

I get what you mean. ;-)

My other concern is, along this path we can save global mapping address
space, but now the burden of enabling the new interface somewhat slip to
the vcpu placement hypercall other than HYPERVISOR_event_channel_op. If
you're fine with this I will be OK too.


Wei.

> Ian.
> 



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U3372-0005kM-Nc; Wed, 06 Feb 2013 11:24:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3371-0005kH-Q2
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:24:23 +0000
Received: from [85.158.143.35:28840] by server-2.bemta-4.messagelabs.com id
	4B/CB-01597-76D32115; Wed, 06 Feb 2013 11:24:23 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360149738!5755206!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9878 invoked from network); 6 Feb 2013 11:22:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1193355"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:22:18 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 6 Feb 2013
	11:22:18 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "iant@google.com" <iant@google.com>
Date: Wed, 6 Feb 2013 11:22:17 +0000
Thread-Topic: coverage license information
Thread-Index: Ac4EXDjnUp60+8DQShymnzLu8u5bpQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458369@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<5110207B.4060501@gnu.org>
	<CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.gmail.com>
In-Reply-To: <CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.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: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"bonzini@gnu.org" <bonzini@gnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:24 -0800, Ian Lance Taylor wrote:
> On Mon, Feb 4, 2013 at 12:56 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> >
> > Would it make sense to release the header file under a permissive
> > license or even public domain?
> >
> > The information there is just ABI, it's dubious that it is copyrightable
> > at all.  If two colleagues of Frediano's did a clean-room reverse
> > engineering, the result would really be indistiguishable from the original.
> 
> I agree that the information in gcov-io.h is almost certainly uncopyrightable.
> 
> But since it's under the GCC Runtime Library Exception, which applies
> to approximately every program compiled by GCC, I don't think it makes
> much difference one way or another.  I'm not opposed to asking the FSF
> to relicense the file, I just don't think it matters.
> 
> Ian

Hi,
  some updated.

I used an header from Linux which is derived from this GCC header when
GCC was still GPL2 so GPL3 does not apply. Xen is GPL2 too so there is
no problem using this header in Xen. The problem is including in the
public headers.

Actually I changed patch to use the header only privately in Xen. I
wrote a new header with the format that Xen export. However somebody
could complaint that the format I used to export came from GCC ABI
documented in the header.

Am I too paranoid?

Frediano

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:24:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U3372-0005kM-Nc; Wed, 06 Feb 2013 11:24:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3371-0005kH-Q2
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:24:23 +0000
Received: from [85.158.143.35:28840] by server-2.bemta-4.messagelabs.com id
	4B/CB-01597-76D32115; Wed, 06 Feb 2013 11:24:23 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360149738!5755206!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9878 invoked from network); 6 Feb 2013 11:22:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1193355"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:22:18 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 6 Feb 2013
	11:22:18 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "iant@google.com" <iant@google.com>
Date: Wed, 6 Feb 2013 11:22:17 +0000
Thread-Topic: coverage license information
Thread-Index: Ac4EXDjnUp60+8DQShymnzLu8u5bpQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458369@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<5110207B.4060501@gnu.org>
	<CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.gmail.com>
In-Reply-To: <CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.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: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"bonzini@gnu.org" <bonzini@gnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-04 at 13:24 -0800, Ian Lance Taylor wrote:
> On Mon, Feb 4, 2013 at 12:56 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> >
> > Would it make sense to release the header file under a permissive
> > license or even public domain?
> >
> > The information there is just ABI, it's dubious that it is copyrightable
> > at all.  If two colleagues of Frediano's did a clean-room reverse
> > engineering, the result would really be indistiguishable from the original.
> 
> I agree that the information in gcov-io.h is almost certainly uncopyrightable.
> 
> But since it's under the GCC Runtime Library Exception, which applies
> to approximately every program compiled by GCC, I don't think it makes
> much difference one way or another.  I'm not opposed to asking the FSF
> to relicense the file, I just don't think it matters.
> 
> Ian

Hi,
  some updated.

I used an header from Linux which is derived from this GCC header when
GCC was still GPL2 so GPL3 does not apply. Xen is GPL2 too so there is
no problem using this header in Xen. The problem is including in the
public headers.

Actually I changed patch to use the header only privately in Xen. I
wrote a new header with the format that Xen export. However somebody
could complaint that the format I used to export came from GCC ABI
documented in the header.

Am I too paranoid?

Frediano

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:24:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U337E-0005lP-DV; Wed, 06 Feb 2013 11:24:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U337C-0005lF-N0
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 11:24:35 +0000
Received: from [85.158.138.51:11218] by server-8.bemta-3.messagelabs.com id
	6F/32-25687-D6D32115; Wed, 06 Feb 2013 11:24:29 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360149865!31215624!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16436 invoked from network); 6 Feb 2013 11:24:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2013 11:24:25 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:51654 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 1U33DI-0008LU-TX; Wed, 06 Feb 2013 12:30:53 +0100
Date: Wed, 6 Feb 2013 12:24:22 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <364251457.20130206122422@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <51123D3102000078000BC61B@nat28.tlf.novell.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0031AD1B80FCDCB5C"
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

------------0031AD1B80FCDCB5C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Wednesday, February 6, 2013, 11:23:29 AM, you wrote:

>>>> On 05.02.13 at 22:19, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Boot of xen-unstable is broken due to changeset 26517 on a AMD 890-FX 
>> motherboard.
>> The serial log is attached.

> Yeah, we were afraid of that. Unfortunately the log you provided,
> while very detailed, doesn't really make clear to me what is going
> wrong. In particular, considering there is a NULL pointer there
> (which I can only guess is the new pin_setup pointer), I would
> have expected it to crash earlier. Hence I'm attaching a patch
> which closes a hole in the logic, but is unlikely to address your
> problem. The added debugging output should help, but please
> also make available the xen-syms image in case the patch - as
> expected - doesn't help and that system of yours still crashes.

> Jan


Hmm with the patch it does boot, but disables the I/O virtualization.

Output of xl-dmesg attached, do you still need a xen-sums of the situation without the debug patch (where it does crash) ?

--
Sander

------------0031AD1B80FCDCB5C
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICAKIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIC8g
ICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwg
J18gXCAgfCB8fCB8XyAgIHxfIFwgX198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBc
fCB8LyBfIFwKICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8IHwg
fCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98
KF8pX19fXy8gICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxlIChyb290
QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVidWc9eSBXZWQg
RmViICA2IDExOjU1OjE4IENFVCAyMDEzCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFR1ZSBG
ZWIgMDUgMTU6NDc6NDEgMjAxMyArMDAwMCAyNjUyMDo2YzFiMTJjODg0YjQKKFhFTikgQm9v
dGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3NxdWVlemUxCihYRU4pIENvbW1hbmQg
bGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxvZ2x2bD1hbGwgbG9nbHZsX2d1ZXN0
PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0xMjgweDEwMjR4MzIgY3B1aWRsZSBj
cHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1k
ZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcsYW1kLWlvbW11LWRlYnVn
IGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTEKKFhFTikgVmlkZW8gaW5mb3JtYXRp
b246CihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcAooWEVO
KSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29uZHMK
KFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMK
KFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4
MjAgUkFNIG1hcDoKKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmMDAw
ICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDAwMDlmMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAo
cmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAo
cmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmY5MDAwMCAo
dXNhYmxlKQooWEVOKSAgMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFD
UEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwYWZmOWUwMDAgLSAwMDAwMDAwMGFmZmUwMDAwIChB
Q1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYWZmZTAwMDAgLSAwMDAwMDAwMGIwMDAwMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjUwMDAwMDAwICh1
c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMDAsIDAwMTQgKHIwIEFDUElBTSkKKFhF
TikgQUNQSTogUlNEVCBBRkY5MDAwMCwgMDA0OCAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IEZBQ1AgQUZGOTAyMDAsIDAwODQgKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBE
U0RUIEFGRjkwNUUwLCA5NDI3IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAgSU5UTCAy
MDA1MTExNykKKFhFTikgQUNQSTogRkFDUyBBRkY5RTAwMCwgMDA0MAooWEVOKSBBQ1BJOiBB
UElDIEFGRjkwMzkwLCAwMDg4IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykKKFhFTikgQUNQSTogTUNGRyBBRkY5MDQyMCwgMDAzQyAocjEgNzY0ME1TIE9F
TU1DRkcgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0
NjAsIDAxNzYgKHIxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQoo
WEVOKSBBQ1BJOiBPRU1CIEFGRjlFMDQwLCAwMDcyIChyMSA3NjQwTVMgQTc2NDAxMDAgMjAx
MDA5MTMgTVNGVCAgICAgICA5NykKKFhFTikgQUNQSTogU1JBVCBBRkY5QTVFMCwgMDEwOCAo
cjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEpCihYRU4pIEFDUEk6
IEhQRVQgQUZGOUE2RjAsIDAwMzggKHIxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZU
ICAgICAgIDk3KQooWEVOKSBBQ1BJOiBJVlJTIEFGRjlBNzMwLCAwMEY4IChyMSAgQU1EICAg
ICBSRDg5MFMgICAyMDIwMzEgQU1EICAgICAgICAgMCkKKFhFTikgQUNQSTogU1NEVCBBRkY5
QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAxIEFNRCAgICAgICAgIDEp
CihYRU4pIFN5c3RlbSBSQU06IDgxOTFNQiAoODM4Nzc3MmtCKQooWEVOKSBTUkFUOiBQWE0g
MCAtPiBBUElDIDAgLT4gTm9kZSAwCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBO
b2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMAooWEVOKSBTUkFU
OiBQWE0gMCAtPiBBUElDIDMgLT4gTm9kZSAwCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMg
NCAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMAooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMC1hMDAwMAooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAg
MTAwMDAwLWIwMDAwMDAwCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUw
MDAwMDAwCihYRU4pIE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMjRkOGQwMDAw
IC0gMjRkOGQzMDAwCihYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lgoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAooWEVOKSB2ZXNhZmI6IGZyYW1lYnVmZmVy
IGF0IDB4ZmIwMDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAwODEwMDAsIHVzaW5nIDYx
NDRrLCB0b3RhbCAxNDMzNmsKKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwg
bGluZWxlbmd0aD01MTIwLCBmb250IDh4MTYKKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNp
emU9ODo4Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBh
dCAwMDBmZjc4MAooWEVOKSBETUkgcHJlc2VudC4KKFhFTikgQVBJQyBib290IHN0YXRlIGlz
ICd4YXBpYycKKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdAooWEVOKSBBQ1BJOiBQ
TS1UaW1lciBJTyBQb3J0OiAweDgwOAooWEVOKSBBQ1BJOiBBQ1BJIFNMRUVQIElORk86IHBt
MXhfY250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdCihYRU4pIEFDUEk6ICAgICAgICAgICAg
ICAgICAgd2FrZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQooWEVOKSBBQ1BJOiBM
b2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzAgMDox
MCBBUElDIHZlcnNpb24gMTYKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw
aWNfaWRbMHgwMV0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMxIDA6MTAgQVBJQyB2ZXJz
aW9uIDE2CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJd
IGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNgooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQoo
WEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYKKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vz
c29yICM0IDA6MTAgQVBJQyB2ZXJzaW9uIDE2CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNSAwOjEw
IEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3Nb
MHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCA2LCB2
ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCihYRU4pIEFDUEk6IElP
QVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pCihYRU4p
IElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAs
IEdTSSAyNC01NQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGds
b2JhbF9pcnEgMiBkZmwgZGZsKQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpCihYRU4pIEFDUEk6IElSUTAgdXNlZCBi
eSBvdmVycmlkZS4KKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBB
Q1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTog
IEZsYXQuICBVc2luZyAyIEkvTyBBUElDcwooWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAg
YmFzZTogMHhmZWQwMDAwMAooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCihYRU4pIFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBT
TVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpCihYRU4pIG1hcHBlZCBBUElD
IHRvIGZmZmY4MmMzZmZkZmIwMDAgKGZlZTAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRv
IGZmZmY4MmMzZmZkZmEwMDAgKGZlYzAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZm
ZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDEx
MTIgTVNJL01TSS1YCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVs
ZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMzIwMC4xODcgTUh6IHByb2Nlc3Nvci4KKFhF
TikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNo
ZWNrIHJlcG9ydGluZyBlbmFibGVkCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6
IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYKKFhFTikgUENJOiBO
b3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZgooWEVOKSBBTUQtVmk6
IEZvdW5kIE1TSSBjYXBhYmlsaXR5IGJsb2NrIGF0IDB4NTQKKFhFTikgQU1ELVZpOiBBQ1BJ
IFRhYmxlOgooWEVOKSBBTUQtVmk6ICBTaWduYXR1cmUgSVZSUwooWEVOKSBBTUQtVmk6ICBM
ZW5ndGggMHhmOAooWEVOKSBBTUQtVmk6ICBSZXZpc2lvbiAweDEKKFhFTikgQU1ELVZpOiAg
Q2hlY2tTdW0gMHg1MAooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICAKKFhFTikgQU1ELVZp
OiAgT0VNX1RhYmxlX0lkIFJEODkwUwooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgy
MDIwMzEKKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgCihYRU4pIEFNRC1WaTogIENy
ZWF0b3JfUmV2aXNpb24gMAooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBm
bGFncyAweDNlIGxlbiAweGM4IGlkIDB4MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MyBpZCAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdl
OiAwIC0+IDB4MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBp
ZCAweDEwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHhiMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0
eXBlIDB4MiBpZCAweDE4IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDIgaWQgMHg5MDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4NDMgaWQgMHhhMDggZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgUmFuZ2U6IDB4YTA4IC0+IDB4YWZmIGFsaWFzIDB4YTAwCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MjggZmxhZ3MgMAooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDgwMCBmbGFncyAwCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MzAgZmxhZ3MgMAooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDcwMCBmbGFncyAw
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NTAgZmxh
Z3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDYw
MCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlk
IDB4NTggZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAweDUwMCBmbGFncyAwCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg1MDAg
LT4gMHg1MDEKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg2OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4NDAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHg4OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgzIGlkIDB4OTAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6
IDB4OTAgLT4gMHg5MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAweDk4IGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+
IDB4OWEKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhh
MCBmbGFncyAweGQ3CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4YTEgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGEyIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhMyBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgyIGlkIDB4YTQgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4NDMgaWQgMHgzMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmIGFsaWFzIDB4YTQKKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhNSBmbGFncyAwCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTggZmxhZ3MgMAooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE5IGZsYWdzIDAKKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAgZmxhZ3MgMAoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGIwIGZsYWdz
IDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjIKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMAooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAweGQ3CihYRU4p
IEFNRC1WaTogSVZIRCBTcGVjaWFsOiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxl
IDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxh
Z3MgMAooWEVOKSBBTUQtVmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDowMC4xIHZhcmlldHkg
MHgxIGhhbmRsZSAweDcKKFhFTikgSVZIRCBFcnJvcjogbm8gaW5mb3JtYXRpb24gZm9yIElP
LUFQSUMgMHg2CihYRU4pIEFNRC1WaTogRXJyb3IgaW5pdGlhbGl6YXRpb24KKFhFTikgSS9P
IHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAw
MTAKKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMAooWEVOKSBHZXR0aW5nIElEOiAw
CihYRU4pIEdldHRpbmcgTFZUMDogNzAwCihYRU4pIEdldHRpbmcgTFZUMTogNDAwCihYRU4p
IGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxp
bmcgdmVjdG9yOiAweDQgIGFmdGVyOiAwCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwoo
WEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgaW5pdCBJT19BUElDIElSUXMK
KFhFTikgIElPLUFQSUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0x
OSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDct
NSwgNy02LCA3LTcsIDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3
LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3
LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25u
ZWN0ZWQuCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMy
PS0xIHBpbjI9LTEKKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4KKFhFTikg
bnVtYmVyIG9mIElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4KKFhFTikgbnVtYmVyIG9mIElP
LUFQSUMgIzcgcmVnaXN0ZXJzOiAzMi4KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uCihYRU4pIElPIEFQSUMgIzYuLi4uLi4KKFhFTikgLi4uLiBy
ZWdpc3RlciAjMDA6IDA2MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElD
IGlkOiAwNgooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4u
Li4uICAgIDogTFRTICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAx
NzgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
NwooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDogMQooWEVOKSAuLi4uLi4u
ICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjog
MDYwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlvbjogMDYKKFhFTikgLi4u
LiByZWdpc3RlciAjMDM6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAg
ICA6IDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDI4CihYRU4pICAw
MiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwCihYRU4pICAw
MyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDMwCihYRU4pICAw
NCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxCihYRU4pICAw
NSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4CihYRU4pICAw
NiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwCihYRU4pICAw
NyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4CihYRU4pICAw
OCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihYRU4pICAw
OSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDU4CihYRU4pICAw
YSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDYwCihYRU4pICAw
YiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAw
YyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAw
ZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAw
ZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAw
ZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIElP
IEFQSUMgIzcuLi4uLi4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDA3MDAwMDAwCihYRU4p
IC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNwooWEVOKSAuLi4uLi4uICAgIDog
RGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAgIDogMAoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxRjgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBt
YXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxRgooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBp
bXBsZW1lbnRlZDogMQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAy
MQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAg
OiBhcmJpdHJhdGlvbjogMDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihY
RU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6
ICAgCihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGlu
IG1hcHBpbmdzOgooWEVOKSBJUlEyNDAgLT4gMDoyCihYRU4pIElSUTQwIC0+IDA6MQooWEVO
KSBJUlE0OCAtPiAwOjMKKFhFTikgSVJRMjQxIC0+IDA6NAooWEVOKSBJUlE1NiAtPiAwOjUK
KFhFTikgSVJRNjQgLT4gMDo2CihYRU4pIElSUTcyIC0+IDA6NwooWEVOKSBJUlE4MCAtPiAw
OjgKKFhFTikgSVJRODggLT4gMDo5CihYRU4pIElSUTk2IC0+IDA6MTAKKFhFTikgSVJRMTA0
IC0+IDA6MTEKKFhFTikgSVJRMTEyIC0+IDA6MTIKKFhFTikgSVJRMTIwIC0+IDA6MTMKKFhF
TikgSVJRMTM2IC0+IDA6MTQKKFhFTikgSVJRMTQ0IC0+IDA6MTUKKFhFTikgLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuCihYRU4pIFVzaW5nIGxvY2FsIEFQ
SUMgdGltZXIgaW50ZXJydXB0cy4KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4K
KFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTczNiBNSHouCihYRU4pIC4u
Li4uIGhvc3QgYnVzIGNsb2NrIHNwZWVkIGlzIDIwMC4wMTA3IE1Iei4KKFhFTikgLi4uLi4g
YnVzX3NjYWxlID0gMHhjY2Q3CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSBQbGF0Zm9y
bSB0aW1lciBpcyAxNC4zMThNSHogSFBFVAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0g
QWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjA3OjE2XSBIVk06IEFTSURzIGVuYWJsZWQuCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2
XSBTVk06IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgWzIwMTMtMDItMDYg
MTE6MDc6MTZdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSBbMjAxMy0wMi0w
NiAxMTowNzoxNl0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9u
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSAgLSBOZXh0LVJJUCBTYXZlZCBvbiAjVk1F
WElUCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSAgLSBQYXVzZS1JbnRlcmNlcHQgRmls
dGVyCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSBIVk06IFNWTSBlbmFibGVkCihYRU4p
IFsyMDEzLTAyLTA2IDExOjA3OjE2XSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAo
SEFQKSBkZXRlY3RlZAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gSFZNOiBIQVAgcGFn
ZSBzaXplczogNGtCLCAyTUIsIDFHQgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNV0gbWFz
a2VkIEV4dElOVCBvbiBDUFUjMQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gbWljcm9j
b2RlOiBDUFUxIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZgooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoxNV0gbWFza2VkIEV4dElOVCBvbiBDUFUjMgooWEVOKSBbMjAx
My0wMi0wNiAxMTowNzoxNl0gbWljcm9jb2RlOiBDUFUyIGNvbGxlY3RfY3B1X2luZm86IHBh
dGNoX2lkPTB4MTAwMDBiZgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNV0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMwooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gbWljcm9jb2RlOiBD
UFUzIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZgooWEVOKSBbMjAxMy0w
Mi0wNiAxMTowNzoxNV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNAooWEVOKSBbMjAxMy0wMi0w
NiAxMTowNzoxNl0gbWljcm9jb2RlOiBDUFU0IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lk
PTB4MTAwMDBiZgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNV0gbWFza2VkIEV4dElOVCBv
biBDUFUjNQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gQnJvdWdodCB1cCA2IENQVXMK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZdIG1pY3JvY29kZTogQ1BVNSBjb2xsZWN0X2Nw
dV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZd
IEhQRVQ6IDMgdGltZXJzICgzIHdpbGwgYmUgdXNlZCBmb3IgYnJvYWRjYXN0KQooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoxNl0gQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MTZdIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBhZGp1c3QgcG9s
bGluZyBmcmVxdWVuY3kKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZdIG1jaGVja19wb2xs
OiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikgWzIwMTMtMDIt
MDYgMTE6MDc6MTZdIFhlbm9wcm9maWxlOiBGYWlsZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZz
ZXQsIElCU0NUTCA9IDB4ZmZmZmZmZmYKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZdICoq
KiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gZWxm
X3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZGM0MDAwCihY
RU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRk
cj0weDFlMDAwMDAgbWVtc3o9MHhlNTBmMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWU2MDAwIG1lbXN6PTB4MTNkYzAK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBh
ZGRyPTB4MWVmYTAwMCBtZW1zej0weGUyMjAwMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzox
N10gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgyZDFjMDAwCihY
RU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09T
ID0gImxpbnV4IgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJzZV9u
b3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTdd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MTddIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhm
ZmZmZmZmZjgwMDAwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxZWZhMjEwCihYRU4pIFsyMDEzLTAyLTA2
IDExOjA3OjE3XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZm
ZmZmZjgxMDAxMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX3BhcnNl
X25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJv
dmVfNGdiIgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJzZV9ub3Rl
OiBQQUVfTU9ERSA9ICJ5ZXMiCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVu
X3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmljIgooWEVOKSBbMjAxMy0wMi0wNiAxMTow
NzoxN10gZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQoo
WEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5E
X0NBTkNFTCA9IDB4MQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MTddIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgw
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazog
YWRkcmVzc2VzOgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gICAgIHZpcnRfYmFzZSAg
ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTdd
ICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3
XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSBbMjAx
My0wMi0wNiAxMTowNzoxN10gICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEw
MDAwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddICAgICB2aXJ0X2tlbmQgICAgICAg
ID0gMHhmZmZmZmZmZjgyZDFjMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSAgICAg
dmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmYTIxMAooWEVOKSBbMjAxMy0wMi0w
NiAxMTowNzoxN10gICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2Is
IGNvbXBhdDMyCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSAgRG9tMCBrZXJuZWw6IDY0
LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJkMWMwMDAKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MTddIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MTddICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAw
LT4wMDAwMDAwMjQ0MDAwMDAwICgyNDI1MTYgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQooWEVO
KSBbMjAxMy0wMi0wNiAxMTowNzoxN10gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYzNTQw
MDAtPjAwMDAwMDAyNGZmZmZjMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIFZJUlRV
QUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gIExv
YWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJkMWMwMDAKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MTddICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyZDFjMDAw
LT5mZmZmZmZmZjgzOWM3YzAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSAgUGh5cy1N
YWNoIG1hcDogZmZmZmZmZmY4MzljODAwMC0+ZmZmZmZmZmY4M2JjODAwMAooWEVOKSBbMjAx
My0wMi0wNiAxMTowNzoxN10gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNiYzgwMDAtPmZm
ZmZmZmZmODNiYzg0YjQKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddICBQYWdlIHRhYmxl
czogICBmZmZmZmZmZjgzYmM5MDAwLT5mZmZmZmZmZjgzYmVjMDAwCihYRU4pIFsyMDEzLTAy
LTA2IDExOjA3OjE3XSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4M2JlYzAwMC0+ZmZmZmZm
ZmY4M2JlZDAwMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gIFRPVEFMOiAgICAgICAg
IGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDAKKFhFTikgWzIwMTMtMDItMDYg
MTE6MDc6MTddICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWZhMjEwCihYRU4pIFsyMDEz
LTAyLTA2IDExOjA3OjE3XSBEb20wIGhhcyBtYXhpbXVtIDYgVkNQVXMKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MTddIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4
MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkYzQwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6
MTddIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWUwMDAwMCAtPiAw
eGZmZmZmZmZmODFlZTUwZjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIGVsZl9sb2Fk
X2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MWVlNjAwMCAtPiAweGZmZmZmZmZmODFl
ZjlkYzAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIGVsZl9sb2FkX2JpbmFyeTogcGhk
ciAzIGF0IDB4ZmZmZmZmZmY4MWVmYTAwMCAtPiAweGZmZmZmZmZmODFmYjMwMDAKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MTddIFNjcnViYmluZyBGcmVlIFJBTTogLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi5kb25lLgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxOV0gSW5pdGlhbCBsb3cgbWVt
b3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFsyMDEzLTAy
LTA2IDExOjA3OjE5XSBTdGQuIExvZ2xldmVsOiBBbGwKKFhFTikgWzIwMTMtMDItMDYgMTE6
MDc6MTldIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTld
IFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSBbMjAxMy0wMi0wNiAx
MTowNzoxOV0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVl
IHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3
OjE5XSBGcmVlZCAyNTJrQiBpbml0IG1lbW9yeS4KKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6
MTldIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg1OCAtPiBJ
UlEgOSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE5XSB0cmFw
cy5jOjI0OTU6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MTldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMAooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoxOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCihYRU4p
IFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAyLjAKKFhF
TikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDMuMAoo
WEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4w
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA2
LjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MGEuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDowYi4wCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjBkLjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MTEuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxMi4wCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjEyLjIKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTMuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxMy4yCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE0LjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTQuMQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuNAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoy
MF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3
OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE1LjAKKFhFTikgWzIwMTMtMDItMDYgMTE6
MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMAooWEVOKSBbMjAxMy0wMi0wNiAx
MTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yCihYRU4pIFsyMDEzLTAyLTA2
IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjAKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMQooWEVOKSBbMjAxMy0w
Mi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCihYRU4pIFsyMDEz
LTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNAooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wCihYRU4p
IFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA5OjAwLjAKKFhF
TikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDEuMAoo
WEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMS4x
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAx
LjIKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDg6
MDAuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
NzowMC4wCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjA2OjAwLjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDU6MDAuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNTowMC4xCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA0OjAwLjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDM6MDYuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gSU9BUElDWzBd
OiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDUwIC0+IElSUSA4IE1vZGU6MCBB
Y3RpdmU6MCkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4NzggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6
MCkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTI4IC0+IDB4YjAgLT4gSVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkKKFhF
TikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTI5IC0+IDB4YjggLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTMwIC0+IDB4YzAgLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MDc6MjBdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE2IC0+
IDB4YzggLT4gSVJRIDE2IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDItMDYgMTE6
MDc6MjBdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4ZDAg
LT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBd
IElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4ZDggLT4gSVJR
IDE3IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTUgLT4gMHgyMSAtPiBJUlEgMjkgTW9k
ZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDI5IC0+IElSUSAzMCBNb2RlOjEgQWN0
aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBJT0FQSUNbMV06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNy03IC0+IDB4MzEgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg3LTE2IC0+IDB4MzkgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MjFdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTIyIC0+IDB4ODEgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MjFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTkg
LT4gMHg4OSAtPiBJUlEgMzMgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxMy0wMi0wNiAx
MTowNzoyMV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOCAtPiAweDkx
IC0+IElSUSAzMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIx
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweDk5IC0+IElS
USA0NyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIxXSBJT0FQ
SUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOSAtPiAweGExIC0+IElSUSAxOSBN
b2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIyXSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweGIxIC0+IElSUSA0NiBNb2RlOjEg
QWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIyXSBJT0FQSUNbMV06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNy0yNyAtPiAweGMxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZl
OjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA5OjA1XSB0cmFwcy5jOjI0OTU6ZDEgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAw
MDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MDk6MTFd
IHRyYXBzLmM6MjQ5NTpkMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVO
KSBbMjAxMy0wMi0wNiAxMTowOToxN10gdHJhcHMuYzoyNDk1OmQzIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAw
eDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDEzLTAyLTA2IDExOjA5OjI0XSB0cmFwcy5j
OjI0OTU6ZDQgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMt
MDItMDYgMTE6MDk6MjldIHRyYXBzLmM6MjQ5NTpkNSBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAw
MDAwMDBmZmZmLgooWEVOKSBbMjAxMy0wMi0wNiAxMTowOTozMV0gZ3JhbnRfdGFibGUuYzoy
ODk6ZDAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMiBmcmFtZXMKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDk6MzRdIHRyYXBzLmM6MjQ5NTpkNiBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAw
MDAwMDBmZmZmLgooWEVOKSBbMjAxMy0wMi0wNiAxMTowOTo0MV0gdHJhcHMuYzoyNDk1OmQ3
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjA5OjQ3XSB0cmFwcy5jOjI0OTU6ZDggRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MDk6NTNdIHRyYXBzLmM6MjQ5NTpkOSBEb21haW4g
YXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAw
MDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDowMF0g
dHJhcHMuYzoyNDk1OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVO
KSBbMjAxMy0wMi0wNiAxMToxMDowNl0gZ3JhbnRfdGFibGUuYzoyODk6ZDAgSW5jcmVhc2Vk
IG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MDZd
IHRyYXBzLmM6MjQ5NTpkMTEgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEw
MDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MTNdIHRyYXBzLmM6MjQ5NTpkMTIgRG9tYWluIGF0dGVt
cHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRv
IDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MTldIHRyYXBz
LmM6MjQ5NTpkMTMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MjhdIHRyYXBzLmM6MjQ5NTpkMTQgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MjldIGdyYW50X3RhYmxl
LmM6Mjg5OmQwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDQgZnJhbWVzCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVkICgtMykgZm9y
IGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBwdF9pcnFfY3JlYXRlX2JpbmQg
ZmFpbGVkICgtMykgZm9yIGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0x
NTogSFZNIExvYWRlcgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IERldGVj
dGVkIFhlbiB2NC4zLXVuc3RhYmxlCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0x
NTogWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDUKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTeXN0ZW0gcmVxdWVzdGVkIFNlYUJJT1MKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBDUFUgc3BlZWQgaXMgMzIwMCBNSHoK
KFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsg
MCBjaGFuZ2VkIDAgLT4gNQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFBD
SS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4
XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElS
UTEwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBs
aW5rIDIgY2hhbmdlZCAwIC0+IDExCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0x
NTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjEwOjM4XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQg
dG8gSVJRNQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDE6
MiBJTlRELT5JUlE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogcGNpIGRl
diAwMTozIElOVEEtPklSUTEwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTog
cGNpIGRldiAwMzowIElOVEEtPklSUTUKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDoz
OF0gSFZNMTU6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDY6MCBJTlRBLT5JUlExMQooWEVOKSBbMjAxMy0w
Mi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6ZSBseDogMDIw
MDAwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwY2kgZGV2IDAzOjAg
YmFyIDE0IHNpemUgbHg6IDAxMDAwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogcGNpIGRldiAwNjowIGJhciAxMCBzaXplIGx4OiAwMDIwMDAwMAooWEVOKSBbMjAx
My0wMi0wNiAxMToxMDozOF0gbWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzAwMCBtZm49
ZjlhMDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogcGNpIGRl
diAwNDowIGJhciAxMCBzaXplIGx4OiAwMDAyMDAwMAooWEVOKSBbMjAxMy0wMi0wNiAxMTox
MDozOF0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSBseDogMDAwMjAwMDAKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDMwIHNp
emUgbHg6IDAwMDEwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogcGNp
IGRldiAwNTowIGJhciAxMCBzaXplIGx4OiAwMDAwMjAwMAooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDozOF0gbWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzI1MCBtZm49Zjk4ZmUgbnI9
MQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDI6MCBiYXIg
MTQgc2l6ZSBseDogMDAwMDEwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1
OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgbHg6IDAwMDAwMTAwCihYRU4pIFsyMDEzLTAy
LTA2IDExOjEwOjM4XSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIGx4OiAwMDAw
MDA0MAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDE6MiBi
YXIgMjAgc2l6ZSBseDogMDAwMDAwMjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgbHg6IDAwMDAwMDEwCihYRU4pIFsyMDEz
LTAyLTA2IDExOjEwOjM4XSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246
CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gQ1BVMCAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihY
RU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gQ1BVMSAuLi4gNDgtYml0IHBo
eXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4p
IFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMg
Li4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6CihY
RU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gUkVQIElOU0IgYWNyb3NzIHBh
Z2UgYm91bmRhcmllcyAuLi4gcGFzc2VkCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZAooWEVOKSBbMjAx
My0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFBhc3NlZCAyIG9mIDIgdGVzdHMKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uCihY
RU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogTG9hZGluZyBTZWFCSU9TIC4uLgoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IENyZWF0aW5nIE1QIHRhYmxlcyAu
Li4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBMb2FkaW5nIEFDUEkgLi4u
CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogdm04NiBUU1MgYXQgZmMwMGEw
ODAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBCSU9TIG1hcDoKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiAgMTAwMDAtMTAwZDM6IFNjcmF0Y2ggc3Bh
Y2UKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiAgZTAwMDAtZmZmZmY6IE1h
aW4gQklPUwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IEU4MjAgdGFibGU6
CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIFswMF06IDAwMDAwMDAwOjAw
MDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJBTQooWEVOKSBbMjAxMy0wMi0wNiAxMTox
MDozOF0gSFZNMTU6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUw
MDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIFswMV06IDAwMDAwMDAw
OjAwMGUwMDAwIC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVECihYRU4pIFsyMDEzLTAy
LTA2IDExOjEwOjM4XSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAw
MDA6MmY4MDAwMDA6IFJBTQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6ICBI
T0xFOiAwMDAwMDAwMDoyZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwCihYRU4pIFsyMDEz
LTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIFswM106IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAw
MDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogSW52b2tpbmcgU2VhQklPUyAuLi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6Mzhd
IEhWTTE1OiBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcuMS04OC1nNGJkOGFlYi0yMDEzMDEy
N18yMDQ2MTEtc2VydmVlcnN0ZXJ0amUpCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogRm91bmQgWGVuIGh5
cGVydmlzb3Igc2lnbmF0dXJlIGF0IDQwMDAwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEw
OjM4XSBIVk0xNTogeGVuOiBjb3B5IGU4MjAuLi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6
MzhdIEhWTTE1OiBSYW0gU2l6ZT0weDJmODAwMDAwICgweDAwMDAwMDAwMDAwMDAwMDAgaGln
aCkKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBSZWxvY2F0aW5nIGxvdyBk
YXRhIGZyb20gMHgwMDBlMmFmMCB0byAweDAwMGVmNzgwIChzaXplIDIxNjQpCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBl
MzM2NCB0byAweDJmN2UyNDAwIChzaXplIDU2MDI4KQooWEVOKSBbMjAxMy0wMi0wNiAxMTox
MDozOF0gSFZNMTU6IENQVSBNaHo9MzE5OQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0g
SFZNMTU6IEZvdW5kIDEwIFBDSSBkZXZpY2VzIChtYXggUENJIGJ1cyBpcyAwMCkKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBBbGxvY2F0ZWQgWGVuIGh5cGVyY2FsbCBw
YWdlIGF0IDJmN2ZmMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogRGV0
ZWN0ZWQgWGVuIHY0LjMtdW5zdGFibGUKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBGb3VuZCAzIGNwdShzKSBtYXggc3VwcG9ydGVkIDMgY3B1KHMpCihYRU4pIFsyMDEz
LTAyLTA2IDExOjEwOjM4XSBIVk0xNTogeGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihYRU4p
IFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogQ29weWluZyBTTUJJT1MgZW50cnkgcG9p
bnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZmRiMTAKKFhFTikgWzIwMTMtMDItMDYgMTE6
MTA6MzhdIEhWTTE1OiBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMTkwL2ZjMDAxMWEw
IHRvIDB4MDAwZmRhMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBDb3B5
aW5nIFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBmZDk4MAooWEVOKSBbMjAxMy0wMi0w
NiAxMToxMDozOF0gSFZNMTU6IENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0
byAweDAwMGZkOTUwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogU2NhbiBm
b3IgVkdBIG9wdGlvbiByb20KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBS
dW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4pIFsyMDEzLTAyLTA2IDExOjEw
OjM4XSBzdGR2Z2EuYzoxNDc6ZDE1IGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2Rl
cwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFR1cm5pbmcgb24gdmdhIHRl
eHQgbW9kZSBjb25zb2xlCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogU2Vh
QklPUyAodmVyc2lvbiByZWwtMS43LjEtODgtZzRiZDhhZWItMjAxMzAxMjdfMjA0NjExLXNl
cnZlZXJzdGVydGplKQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IE1hY2hp
bmUgVVVJRCAzMjM0NjhmYy0xNGY0LTRmNmUtYjMyNC1iMmZiYjkzNDJiOTAKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBVSENJIGluaXQgb24gZGV2IDAwOjAxLjIgKGlv
PWMxNDApCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogRm91bmQgMSBscHQg
cG9ydHMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBGb3VuZCAxIHNlcmlh
bCBwb3J0cwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFNlYXJjaGluZyBi
b290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4L2lzYUAxL2ZkY0AwM2YwL2Zsb3BweUAwCihYRU4p
IFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAv
M2Y0L2MxNjAgKGlycSAxNCBkZXYgOSkKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvYzE2OCAoaXJxIDE1IGRldiA5KQoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IGF0YTAtMDogUUVNVSBIQVJERElT
SyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjEwOjM4XSBIVk0xNTogU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAx
LDEvZHJpdmVAMC9kaXNrQDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBh
dGEwLTE6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgzMDAgR2lCeXRlcykKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTZWFyY2hpbmcgYm9vdG9yZGVyIGZv
cjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMQooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDozOF0gSFZNMTU6IERWRC9DRCBbYXRhMS0wOiBRRU1VIERWRC1ST00gQVRBUEktNCBE
VkQvQ0RdCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogU2VhcmNoaW5nIGJv
b3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMS9kaXNrQDAKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBBbGwgdGhyZWFkcyBjb21wbGV0ZS4K
KFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTY2FuIGZvciBvcHRpb24gcm9t
cwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFJ1bm5pbmcgb3B0aW9uIHJv
bSBhdCBjOTAwOjAwMDMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0g
Y2FsbCBhcmcxPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0gY2Fs
bCBhcmcxPTAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0gY2FsbCBh
cmcxPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0gY2FsbCBhcmcx
PTAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTZWFyY2hpbmcgYm9vdG9y
ZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBQcmVzcyBGMTIgZm9y
IGJvb3QgbWVudS4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiAKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjog
SEFMVAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IGRyaXZlIDB4MDAwZmQ4
ZDA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMg
cz0yMDk3MTUyMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IAooWEVOKSBb
MjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IGRyaXZlIDB4MDAwZmQ4YTA6IFBDSFM9MTYz
ODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMgcz02MjkxNDU2MAoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IDAKKFhFTikgWzIwMTMtMDItMDYg
MTE6MTA6NDFdIEhWTTE1OiBTcGFjZSBhdmFpbGFibGUgZm9yIFVNQjogMDAwY2EwMDAtMDAw
ZWU4MDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiBSZXR1cm5lZCA2MTQ0
MCBieXRlcyBvZiBab25lSGlnaAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6
IGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZN
MTU6ICAgMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6ICAgMTogMDAwMDAwMDAwMDA5ZmMw
MCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VSVkVECihYRU4pIFsyMDEzLTAyLTA2IDEx
OjEwOjQxXSBIVk0xNTogICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAw
MCA9IDIgUkVTRVJWRUQKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiAgIDM6
IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDJmN2ZmMDAwID0gMSBSQU0KKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiAgIDQ6IDAwMDAwMDAwMmY3ZmYwMDAgLSAwMDAw
MDAwMDJmODAwMDAwID0gMiBSRVNFUlZFRAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0g
SFZNMTU6ICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJF
U0VSVkVECihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjQxXSBIVk0xNTogZW50ZXIgaGFuZGxl
XzE5OgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6ICAgTlVMTAooWEVOKSBb
MjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4K
KFhFTikgWzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiBCb290aW5nIGZyb20gMDAwMDo3
YzAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjQxXSBncmFudF90YWJsZS5jOjI4OTpkMCBJ
bmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcwooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDo1N10gaXJxLmM6Mzc1OiBEb20xNSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJl
Y3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZl
IG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6
MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49
ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMt
MDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZu
PWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6
MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5y
PTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBn
Zm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1l
bW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAg
bWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMAooWEVOKSBbMjAxMy0w
Mi0wNiAxMToxMTowMF0gbWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzAwMCBtZm49Zjlh
MDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAwXSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDAKKFhFTikgWzIwMTMtMDItMDYg
MTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5y
PTIwMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE1IGdmbj1mMzAwMCBtZm49ZjlhMDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEx
OjAwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDAK
KFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBn
Zm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0g
bWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzAwMCBtZm49ZjlhMDAgbnI9MjAwCihYRU4p
IFsyMDEzLTAyLTA2IDExOjExOjAwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYz
MDAwIG1mbj1mOWEwMCBucj0yMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMAooWEVOKSBbMjAx
My0wMi0wNiAxMToxMTowMF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE1IGdmbj1mMzAwMCBt
Zm49ZjlhMDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAwXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDAKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MTE6MDBdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4g
MAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGlu
ayAxIGNoYW5nZWQgMTAgLT4gMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0gaXJxLmM6
MjcwOiBEb20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBbMjAxMy0wMi0w
NiAxMToxMTowMF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAw
CihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAyXSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVk
ICgtMykgZm9yIGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAyXSBwdF9pcnFfY3Jl
YXRlX2JpbmQgZmFpbGVkICgtMykgZm9yIGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEx
OjAyXSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVkICgtMykgZm9yIGRvbTE1CihYRU4pIFsy
MDEzLTAyLTA2IDExOjExOjAyXSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVkICgtMykgZm9y
IGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjM3XSBncmFudF90YWJsZS5jOjI4OTpk
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA2IGZyYW1lcwooWEVOKSBbMjAxMy0wMi0w
NiAxMToxMjo0MF0gZ3JhbnRfdGFibGUuYzoyODk6ZDAgSW5jcmVhc2VkIG1hcHRyYWNrIHNp
emUgdG8gNyBmcmFtZXMK
------------0031AD1B80FCDCB5C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0031AD1B80FCDCB5C--



From xen-devel-bounces@lists.xen.org Wed Feb 06 11:24:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U337E-0005lP-DV; Wed, 06 Feb 2013 11:24:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U337C-0005lF-N0
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 11:24:35 +0000
Received: from [85.158.138.51:11218] by server-8.bemta-3.messagelabs.com id
	6F/32-25687-D6D32115; Wed, 06 Feb 2013 11:24:29 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360149865!31215624!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16436 invoked from network); 6 Feb 2013 11:24:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2013 11:24:25 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:51654 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 1U33DI-0008LU-TX; Wed, 06 Feb 2013 12:30:53 +0100
Date: Wed, 6 Feb 2013 12:24:22 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <364251457.20130206122422@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <51123D3102000078000BC61B@nat28.tlf.novell.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0031AD1B80FCDCB5C"
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

------------0031AD1B80FCDCB5C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Wednesday, February 6, 2013, 11:23:29 AM, you wrote:

>>>> On 05.02.13 at 22:19, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Boot of xen-unstable is broken due to changeset 26517 on a AMD 890-FX 
>> motherboard.
>> The serial log is attached.

> Yeah, we were afraid of that. Unfortunately the log you provided,
> while very detailed, doesn't really make clear to me what is going
> wrong. In particular, considering there is a NULL pointer there
> (which I can only guess is the new pin_setup pointer), I would
> have expected it to crash earlier. Hence I'm attaching a patch
> which closes a hole in the logic, but is unlikely to address your
> problem. The added debugging output should help, but please
> also make available the xen-syms image in case the patch - as
> expected - doesn't help and that system of yours still crashes.

> Jan


Hmm with the patch it does boot, but disables the I/O virtualization.

Output of xl-dmesg attached, do you still need a xen-sums of the situation without the debug patch (where it does crash) ?

--
Sander

------------0031AD1B80FCDCB5C
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICAKIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19fIC8g
ICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyAKICBcICAvLyBfIFwg
J18gXCAgfCB8fCB8XyAgIHxfIFwgX198IHwgfCB8ICdfIFwvIF9ffCBfXy8gX2AgfCAnXyBc
fCB8LyBfIFwKICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8IHwg
fCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8KIC9fL1xfXF9fX3xffCB8X3wgICAgfF98
KF8pX19fXy8gICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98XF9fX3wKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAKKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxlIChyb290
QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVidWc9eSBXZWQg
RmViICA2IDExOjU1OjE4IENFVCAyMDEzCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFR1ZSBG
ZWIgMDUgMTU6NDc6NDEgMjAxMyArMDAwMCAyNjUyMDo2YzFiMTJjODg0YjQKKFhFTikgQm9v
dGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3NxdWVlemUxCihYRU4pIENvbW1hbmQg
bGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxvZ2x2bD1hbGwgbG9nbHZsX2d1ZXN0
PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0xMjgweDEwMjR4MzIgY3B1aWRsZSBj
cHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1k
ZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcsYW1kLWlvbW11LWRlYnVn
IGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTEKKFhFTikgVmlkZW8gaW5mb3JtYXRp
b246CihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcAooWEVO
KSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29uZHMK
KFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMK
KFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4
MjAgUkFNIG1hcDoKKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmMDAw
ICh1c2FibGUpCihYRU4pICAwMDAwMDAwMDAwMDlmMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAo
cmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAo
cmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmY5MDAwMCAo
dXNhYmxlKQooWEVOKSAgMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFD
UEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwYWZmOWUwMDAgLSAwMDAwMDAwMGFmZmUwMDAwIChB
Q1BJIE5WUykKKFhFTikgIDAwMDAwMDAwYWZmZTAwMDAgLSAwMDAwMDAwMGIwMDAwMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChy
ZXNlcnZlZCkKKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjUwMDAwMDAwICh1
c2FibGUpCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMDAsIDAwMTQgKHIwIEFDUElBTSkKKFhF
TikgQUNQSTogUlNEVCBBRkY5MDAwMCwgMDA0OCAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IEZBQ1AgQUZGOTAyMDAsIDAwODQgKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQooWEVOKSBBQ1BJOiBE
U0RUIEFGRjkwNUUwLCA5NDI3IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAgSU5UTCAy
MDA1MTExNykKKFhFTikgQUNQSTogRkFDUyBBRkY5RTAwMCwgMDA0MAooWEVOKSBBQ1BJOiBB
UElDIEFGRjkwMzkwLCAwMDg4IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykKKFhFTikgQUNQSTogTUNGRyBBRkY5MDQyMCwgMDAzQyAocjEgNzY0ME1TIE9F
TU1DRkcgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0
NjAsIDAxNzYgKHIxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQoo
WEVOKSBBQ1BJOiBPRU1CIEFGRjlFMDQwLCAwMDcyIChyMSA3NjQwTVMgQTc2NDAxMDAgMjAx
MDA5MTMgTVNGVCAgICAgICA5NykKKFhFTikgQUNQSTogU1JBVCBBRkY5QTVFMCwgMDEwOCAo
cjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEpCihYRU4pIEFDUEk6
IEhQRVQgQUZGOUE2RjAsIDAwMzggKHIxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZU
ICAgICAgIDk3KQooWEVOKSBBQ1BJOiBJVlJTIEFGRjlBNzMwLCAwMEY4IChyMSAgQU1EICAg
ICBSRDg5MFMgICAyMDIwMzEgQU1EICAgICAgICAgMCkKKFhFTikgQUNQSTogU1NEVCBBRkY5
QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAxIEFNRCAgICAgICAgIDEp
CihYRU4pIFN5c3RlbSBSQU06IDgxOTFNQiAoODM4Nzc3MmtCKQooWEVOKSBTUkFUOiBQWE0g
MCAtPiBBUElDIDAgLT4gTm9kZSAwCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBO
b2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMAooWEVOKSBTUkFU
OiBQWE0gMCAtPiBBUElDIDMgLT4gTm9kZSAwCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMg
NCAtPiBOb2RlIDAKKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMAooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMC1hMDAwMAooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAg
MTAwMDAwLWIwMDAwMDAwCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUw
MDAwMDAwCihYRU4pIE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMjRkOGQwMDAw
IC0gMjRkOGQzMDAwCihYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lgoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZAooWEVOKSB2ZXNhZmI6IGZyYW1lYnVmZmVy
IGF0IDB4ZmIwMDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAwODEwMDAsIHVzaW5nIDYx
NDRrLCB0b3RhbCAxNDMzNmsKKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwg
bGluZWxlbmd0aD01MTIwLCBmb250IDh4MTYKKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNp
emU9ODo4Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBh
dCAwMDBmZjc4MAooWEVOKSBETUkgcHJlc2VudC4KKFhFTikgQVBJQyBib290IHN0YXRlIGlz
ICd4YXBpYycKKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdAooWEVOKSBBQ1BJOiBQ
TS1UaW1lciBJTyBQb3J0OiAweDgwOAooWEVOKSBBQ1BJOiBBQ1BJIFNMRUVQIElORk86IHBt
MXhfY250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdCihYRU4pIEFDUEk6ICAgICAgICAgICAg
ICAgICAgd2FrZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQooWEVOKSBBQ1BJOiBM
b2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMAooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQooWEVOKSBQcm9jZXNzb3IgIzAgMDox
MCBBUElDIHZlcnNpb24gMTYKKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw
aWNfaWRbMHgwMV0gZW5hYmxlZCkKKFhFTikgUHJvY2Vzc29yICMxIDA6MTAgQVBJQyB2ZXJz
aW9uIDE2CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJd
IGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNgooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQoo
WEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYKKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkKKFhFTikgUHJvY2Vz
c29yICM0IDA6MTAgQVBJQyB2ZXJzaW9uIDE2CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpCihYRU4pIFByb2Nlc3NvciAjNSAwOjEw
IEFQSUMgdmVyc2lvbiAxNgooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3Nb
MHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCA2LCB2
ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCihYRU4pIEFDUEk6IElP
QVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pCihYRU4p
IElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAs
IEdTSSAyNC01NQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGds
b2JhbF9pcnEgMiBkZmwgZGZsKQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpCihYRU4pIEFDUEk6IElSUTAgdXNlZCBi
eSBvdmVycmlkZS4KKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgooWEVOKSBB
Q1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTog
IEZsYXQuICBVc2luZyAyIEkvTyBBUElDcwooWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAg
YmFzZTogMHhmZWQwMDAwMAooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhCihYRU4pIFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbgooWEVOKSBT
TVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpCihYRU4pIG1hcHBlZCBBUElD
IHRvIGZmZmY4MmMzZmZkZmIwMDAgKGZlZTAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRv
IGZmZmY4MmMzZmZkZmEwMDAgKGZlYzAwMDAwKQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZm
ZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDEx
MTIgTVNJL01TSS1YCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVs
ZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMzIwMC4xODcgTUh6IHByb2Nlc3Nvci4KKFhF
TikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNo
ZWNrIHJlcG9ydGluZyBlbmFibGVkCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6
IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYKKFhFTikgUENJOiBO
b3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZgooWEVOKSBBTUQtVmk6
IEZvdW5kIE1TSSBjYXBhYmlsaXR5IGJsb2NrIGF0IDB4NTQKKFhFTikgQU1ELVZpOiBBQ1BJ
IFRhYmxlOgooWEVOKSBBTUQtVmk6ICBTaWduYXR1cmUgSVZSUwooWEVOKSBBTUQtVmk6ICBM
ZW5ndGggMHhmOAooWEVOKSBBTUQtVmk6ICBSZXZpc2lvbiAweDEKKFhFTikgQU1ELVZpOiAg
Q2hlY2tTdW0gMHg1MAooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICAKKFhFTikgQU1ELVZp
OiAgT0VNX1RhYmxlX0lkIFJEODkwUwooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgy
MDIwMzEKKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgCihYRU4pIEFNRC1WaTogIENy
ZWF0b3JfUmV2aXNpb24gMAooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBm
bGFncyAweDNlIGxlbiAweGM4IGlkIDB4MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MyBpZCAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdl
OiAwIC0+IDB4MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBp
ZCAweDEwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHhiMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0
eXBlIDB4MiBpZCAweDE4IGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDIgaWQgMHg5MDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4NDMgaWQgMHhhMDggZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgUmFuZ2U6IDB4YTA4IC0+IDB4YWZmIGFsaWFzIDB4YTAwCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MjggZmxhZ3MgMAooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDgwMCBmbGFncyAwCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MzAgZmxhZ3MgMAooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDcwMCBmbGFncyAw
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NTAgZmxh
Z3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDYw
MCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlk
IDB4NTggZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAweDUwMCBmbGFncyAwCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg1MDAg
LT4gMHg1MDEKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg2OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4NDAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHg4OCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgzIGlkIDB4OTAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6
IDB4OTAgLT4gMHg5MgooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAweDk4IGZsYWdzIDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+
IDB4OWEKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhh
MCBmbGFncyAweGQ3CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgy
IGlkIDB4YTEgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGEyIGZsYWdzIDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhMyBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgyIGlkIDB4YTQgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4NDMgaWQgMHgzMDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmIGFsaWFzIDB4YTQKKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhNSBmbGFncyAwCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTggZmxhZ3MgMAooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE5IGZsYWdzIDAKKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAgZmxhZ3MgMAoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweGIwIGZsYWdz
IDAKKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjIKKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMAooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAweGQ3CihYRU4p
IEFNRC1WaTogSVZIRCBTcGVjaWFsOiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxl
IDAKKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxh
Z3MgMAooWEVOKSBBTUQtVmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDowMC4xIHZhcmlldHkg
MHgxIGhhbmRsZSAweDcKKFhFTikgSVZIRCBFcnJvcjogbm8gaW5mb3JtYXRpb24gZm9yIElP
LUFQSUMgMHg2CihYRU4pIEFNRC1WaTogRXJyb3IgaW5pdGlhbGl6YXRpb24KKFhFTikgSS9P
IHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAw
MTAKKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMAooWEVOKSBHZXR0aW5nIElEOiAw
CihYRU4pIEdldHRpbmcgTFZUMDogNzAwCihYRU4pIEdldHRpbmcgTFZUMTogNDAwCihYRU4p
IGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxp
bmcgdmVjdG9yOiAweDQgIGFmdGVyOiAwCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcwoo
WEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgaW5pdCBJT19BUElDIElSUXMK
KFhFTikgIElPLUFQSUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0x
OSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDct
NSwgNy02LCA3LTcsIDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3
LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3
LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25u
ZWN0ZWQuCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMy
PS0xIHBpbjI9LTEKKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4KKFhFTikg
bnVtYmVyIG9mIElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4KKFhFTikgbnVtYmVyIG9mIElP
LUFQSUMgIzcgcmVnaXN0ZXJzOiAzMi4KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uCihYRU4pIElPIEFQSUMgIzYuLi4uLi4KKFhFTikgLi4uLiBy
ZWdpc3RlciAjMDA6IDA2MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElD
IGlkOiAwNgooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4u
Li4uICAgIDogTFRTICAgICAgICAgIDogMAooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAx
NzgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
NwooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBpbXBsZW1lbnRlZDogMQooWEVOKSAuLi4uLi4u
ICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjog
MDYwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAgOiBhcmJpdHJhdGlvbjogMDYKKFhFTikgLi4u
LiByZWdpc3RlciAjMDM6IDA3MDAwMDAwCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAg
ICA6IDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAw
MSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDI4CihYRU4pICAw
MiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwCihYRU4pICAw
MyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDMwCihYRU4pICAw
NCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxCihYRU4pICAw
NSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4CihYRU4pICAw
NiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwCihYRU4pICAw
NyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4CihYRU4pICAw
OCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDUwCihYRU4pICAw
OSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDU4CihYRU4pICAw
YSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDYwCihYRU4pICAw
YiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDY4CihYRU4pICAw
YyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwCihYRU4pICAw
ZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4CihYRU4pICAw
ZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDg4CihYRU4pICAw
ZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwCihYRU4pICAx
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
MyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pICAx
NyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwCihYRU4pIElP
IEFQSUMgIzcuLi4uLi4KKFhFTikgLi4uLiByZWdpc3RlciAjMDA6IDA3MDAwMDAwCihYRU4p
IC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNwooWEVOKSAuLi4uLi4uICAgIDog
RGVsaXZlcnkgVHlwZTogMAooWEVOKSAuLi4uLi4uICAgIDogTFRTICAgICAgICAgIDogMAoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxRjgwMjEKKFhFTikgLi4uLi4uLiAgICAgOiBt
YXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxRgooWEVOKSAuLi4uLi4uICAgICA6IFBSUSBp
bXBsZW1lbnRlZDogMQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAy
MQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDAKKFhFTikgLi4uLi4uLiAgICAg
OiBhcmJpdHJhdGlvbjogMDAKKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6CihY
RU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6
ICAgCihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAwZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZwooWEVOKSBJUlEgdG8gcGlu
IG1hcHBpbmdzOgooWEVOKSBJUlEyNDAgLT4gMDoyCihYRU4pIElSUTQwIC0+IDA6MQooWEVO
KSBJUlE0OCAtPiAwOjMKKFhFTikgSVJRMjQxIC0+IDA6NAooWEVOKSBJUlE1NiAtPiAwOjUK
KFhFTikgSVJRNjQgLT4gMDo2CihYRU4pIElSUTcyIC0+IDA6NwooWEVOKSBJUlE4MCAtPiAw
OjgKKFhFTikgSVJRODggLT4gMDo5CihYRU4pIElSUTk2IC0+IDA6MTAKKFhFTikgSVJRMTA0
IC0+IDA6MTEKKFhFTikgSVJRMTEyIC0+IDA6MTIKKFhFTikgSVJRMTIwIC0+IDA6MTMKKFhF
TikgSVJRMTM2IC0+IDA6MTQKKFhFTikgSVJRMTQ0IC0+IDA6MTUKKFhFTikgLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuCihYRU4pIFVzaW5nIGxvY2FsIEFQ
SUMgdGltZXIgaW50ZXJydXB0cy4KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4K
KFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTczNiBNSHouCihYRU4pIC4u
Li4uIGhvc3QgYnVzIGNsb2NrIHNwZWVkIGlzIDIwMC4wMTA3IE1Iei4KKFhFTikgLi4uLi4g
YnVzX3NjYWxlID0gMHhjY2Q3CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSBQbGF0Zm9y
bSB0aW1lciBpcyAxNC4zMThNSHogSFBFVAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0g
QWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjA3OjE2XSBIVk06IEFTSURzIGVuYWJsZWQuCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2
XSBTVk06IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgWzIwMTMtMDItMDYg
MTE6MDc6MTZdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSBbMjAxMy0wMi0w
NiAxMTowNzoxNl0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9u
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSAgLSBOZXh0LVJJUCBTYXZlZCBvbiAjVk1F
WElUCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSAgLSBQYXVzZS1JbnRlcmNlcHQgRmls
dGVyCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSBIVk06IFNWTSBlbmFibGVkCihYRU4p
IFsyMDEzLTAyLTA2IDExOjA3OjE2XSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAo
SEFQKSBkZXRlY3RlZAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gSFZNOiBIQVAgcGFn
ZSBzaXplczogNGtCLCAyTUIsIDFHQgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNV0gbWFz
a2VkIEV4dElOVCBvbiBDUFUjMQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gbWljcm9j
b2RlOiBDUFUxIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZgooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoxNV0gbWFza2VkIEV4dElOVCBvbiBDUFUjMgooWEVOKSBbMjAx
My0wMi0wNiAxMTowNzoxNl0gbWljcm9jb2RlOiBDUFUyIGNvbGxlY3RfY3B1X2luZm86IHBh
dGNoX2lkPTB4MTAwMDBiZgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNV0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMwooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gbWljcm9jb2RlOiBD
UFUzIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZgooWEVOKSBbMjAxMy0w
Mi0wNiAxMTowNzoxNV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNAooWEVOKSBbMjAxMy0wMi0w
NiAxMTowNzoxNl0gbWljcm9jb2RlOiBDUFU0IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lk
PTB4MTAwMDBiZgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNV0gbWFza2VkIEV4dElOVCBv
biBDUFUjNQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gQnJvdWdodCB1cCA2IENQVXMK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZdIG1pY3JvY29kZTogQ1BVNSBjb2xsZWN0X2Nw
dV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZd
IEhQRVQ6IDMgdGltZXJzICgzIHdpbGwgYmUgdXNlZCBmb3IgYnJvYWRjYXN0KQooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoxNl0gQUNQSSBzbGVlcCBtb2RlczogUzMKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MTZdIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBhZGp1c3QgcG9s
bGluZyBmcmVxdWVuY3kKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZdIG1jaGVja19wb2xs
OiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4KKFhFTikgWzIwMTMtMDIt
MDYgMTE6MDc6MTZdIFhlbm9wcm9maWxlOiBGYWlsZWQgdG8gc2V0dXAgSUJTIExWVCBvZmZz
ZXQsIElCU0NUTCA9IDB4ZmZmZmZmZmYKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTZdICoq
KiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxNl0gZWxm
X3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZGM0MDAwCihY
RU4pIFsyMDEzLTAyLTA2IDExOjA3OjE2XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRk
cj0weDFlMDAwMDAgbWVtc3o9MHhlNTBmMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWU2MDAwIG1lbXN6PTB4MTNkYzAK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBh
ZGRyPTB4MWVmYTAwMCBtZW1zej0weGUyMjAwMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzox
N10gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgyZDFjMDAwCihY
RU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09T
ID0gImxpbnV4IgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJzZV9u
b3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTdd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCIKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MTddIGVsZl94ZW5fcGFyc2Vfbm90ZTogVklSVF9CQVNFID0gMHhm
ZmZmZmZmZjgwMDAwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxZWZhMjEwCihYRU4pIFsyMDEzLTAyLTA2
IDExOjA3OjE3XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZm
ZmZmZjgxMDAxMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX3BhcnNl
X25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJv
dmVfNGdiIgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJzZV9ub3Rl
OiBQQUVfTU9ERSA9ICJ5ZXMiCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVu
X3BhcnNlX25vdGU6IExPQURFUiA9ICJnZW5lcmljIgooWEVOKSBbMjAxMy0wMi0wNiAxMTow
NzoxN10gZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQoo
WEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5E
X0NBTkNFTCA9IDB4MQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBIVl9TVEFSVF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDAKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MTddIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgw
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazog
YWRkcmVzc2VzOgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gICAgIHZpcnRfYmFzZSAg
ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTdd
ICAgICBlbGZfcGFkZHJfb2Zmc2V0ID0gMHgwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3
XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMAooWEVOKSBbMjAx
My0wMi0wNiAxMTowNzoxN10gICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEw
MDAwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddICAgICB2aXJ0X2tlbmQgICAgICAg
ID0gMHhmZmZmZmZmZjgyZDFjMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSAgICAg
dmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmYTIxMAooWEVOKSBbMjAxMy0wMi0w
NiAxMTowNzoxN10gICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2Is
IGNvbXBhdDMyCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSAgRG9tMCBrZXJuZWw6IDY0
LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJkMWMwMDAKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MTddIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MTddICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAw
LT4wMDAwMDAwMjQ0MDAwMDAwICgyNDI1MTYgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQooWEVO
KSBbMjAxMy0wMi0wNiAxMTowNzoxN10gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYzNTQw
MDAtPjAwMDAwMDAyNGZmZmZjMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIFZJUlRV
QUwgTUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gIExv
YWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJkMWMwMDAKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MTddICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyZDFjMDAw
LT5mZmZmZmZmZjgzOWM3YzAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE3XSAgUGh5cy1N
YWNoIG1hcDogZmZmZmZmZmY4MzljODAwMC0+ZmZmZmZmZmY4M2JjODAwMAooWEVOKSBbMjAx
My0wMi0wNiAxMTowNzoxN10gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNiYzgwMDAtPmZm
ZmZmZmZmODNiYzg0YjQKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddICBQYWdlIHRhYmxl
czogICBmZmZmZmZmZjgzYmM5MDAwLT5mZmZmZmZmZjgzYmVjMDAwCihYRU4pIFsyMDEzLTAy
LTA2IDExOjA3OjE3XSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4M2JlYzAwMC0+ZmZmZmZm
ZmY4M2JlZDAwMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxN10gIFRPVEFMOiAgICAgICAg
IGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDAKKFhFTikgWzIwMTMtMDItMDYg
MTE6MDc6MTddICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWZhMjEwCihYRU4pIFsyMDEz
LTAyLTA2IDExOjA3OjE3XSBEb20wIGhhcyBtYXhpbXVtIDYgVkNQVXMKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MTddIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4
MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkYzQwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6
MTddIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWUwMDAwMCAtPiAw
eGZmZmZmZmZmODFlZTUwZjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIGVsZl9sb2Fk
X2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MWVlNjAwMCAtPiAweGZmZmZmZmZmODFl
ZjlkYzAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTddIGVsZl9sb2FkX2JpbmFyeTogcGhk
ciAzIGF0IDB4ZmZmZmZmZmY4MWVmYTAwMCAtPiAweGZmZmZmZmZmODFmYjMwMDAKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MTddIFNjcnViYmluZyBGcmVlIFJBTTogLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi5kb25lLgooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoxOV0gSW5pdGlhbCBsb3cgbWVt
b3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuCihYRU4pIFsyMDEzLTAy
LTA2IDExOjA3OjE5XSBTdGQuIExvZ2xldmVsOiBBbGwKKFhFTikgWzIwMTMtMDItMDYgMTE6
MDc6MTldIEd1ZXN0IExvZ2xldmVsOiBBbGwKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MTld
IFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSBbMjAxMy0wMi0wNiAx
MTowNzoxOV0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVl
IHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3
OjE5XSBGcmVlZCAyNTJrQiBpbml0IG1lbW9yeS4KKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6
MTldIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg1OCAtPiBJ
UlEgOSBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjE5XSB0cmFw
cy5jOjI0OTU6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MTldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMAooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoxOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yCihYRU4p
IFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAyLjAKKFhF
TikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDMuMAoo
WEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4w
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA2
LjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MGEuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDowYi4wCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjBkLjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MTEuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxMi4wCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjEyLjIKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTMuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxMy4yCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE0LjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTQuMQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuNAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoy
MF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3
OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE1LjAKKFhFTikgWzIwMTMtMDItMDYgMTE6
MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTYuMAooWEVOKSBbMjAxMy0wMi0wNiAx
MTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yCihYRU4pIFsyMDEzLTAyLTA2
IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjAKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMQooWEVOKSBbMjAxMy0w
Mi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yCihYRU4pIFsyMDEz
LTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNAooWEVOKSBb
MjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wCihYRU4p
IFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjA5OjAwLjAKKFhF
TikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDEuMAoo
WEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMS4x
CihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAx
LjIKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDg6
MDAuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
NzowMC4wCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjA2OjAwLjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDU6MDAuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNTowMC4xCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA0OjAwLjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDM6MDYuMAooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gSU9BUElDWzBd
OiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDUwIC0+IElSUSA4IE1vZGU6MCBB
Y3RpdmU6MCkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4NzggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6
MCkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTI4IC0+IDB4YjAgLT4gSVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkKKFhF
TikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTI5IC0+IDB4YjggLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIw
MTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTMwIC0+IDB4YzAgLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MDc6MjBdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE2IC0+
IDB4YzggLT4gSVJRIDE2IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDItMDYgMTE6
MDc6MjBdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4ZDAg
LT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBd
IElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4ZDggLT4gSVJR
IDE3IE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTUgLT4gMHgyMSAtPiBJUlEgMjkgTW9k
ZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxMy0wMi0wNiAxMTowNzoyMF0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDI5IC0+IElSUSAzMCBNb2RlOjEgQWN0
aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIwXSBJT0FQSUNbMV06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNy03IC0+IDB4MzEgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkK
KFhFTikgWzIwMTMtMDItMDYgMTE6MDc6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg3LTE2IC0+IDB4MzkgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikg
WzIwMTMtMDItMDYgMTE6MDc6MjFdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTIyIC0+IDB4ODEgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDc6MjFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTkg
LT4gMHg4OSAtPiBJUlEgMzMgTW9kZToxIEFjdGl2ZToxKQooWEVOKSBbMjAxMy0wMi0wNiAx
MTowNzoyMV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOCAtPiAweDkx
IC0+IElSUSAzMiBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIx
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweDk5IC0+IElS
USA0NyBNb2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIxXSBJT0FQ
SUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOSAtPiAweGExIC0+IElSUSAxOSBN
b2RlOjEgQWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIyXSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweGIxIC0+IElSUSA0NiBNb2RlOjEg
QWN0aXZlOjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA3OjIyXSBJT0FQSUNbMV06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNy0yNyAtPiAweGMxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZl
OjEpCihYRU4pIFsyMDEzLTAyLTA2IDExOjA5OjA1XSB0cmFwcy5jOjI0OTU6ZDEgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAw
MDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MDk6MTFd
IHRyYXBzLmM6MjQ5NTpkMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVO
KSBbMjAxMy0wMi0wNiAxMTowOToxN10gdHJhcHMuYzoyNDk1OmQzIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwMDAwMDAwMCB0byAw
eDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDEzLTAyLTA2IDExOjA5OjI0XSB0cmFwcy5j
OjI0OTU6ZDQgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMt
MDItMDYgMTE6MDk6MjldIHRyYXBzLmM6MjQ5NTpkNSBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAw
MDAwMDBmZmZmLgooWEVOKSBbMjAxMy0wMi0wNiAxMTowOTozMV0gZ3JhbnRfdGFibGUuYzoy
ODk6ZDAgSW5jcmVhc2VkIG1hcHRyYWNrIHNpemUgdG8gMiBmcmFtZXMKKFhFTikgWzIwMTMt
MDItMDYgMTE6MDk6MzRdIHRyYXBzLmM6MjQ5NTpkNiBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAw
MDAwMDBmZmZmLgooWEVOKSBbMjAxMy0wMi0wNiAxMTowOTo0MV0gdHJhcHMuYzoyNDk1OmQ3
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAw
MDAwMDAwMDAwMCB0byAweDAwMDAwMDAwMDAwMGZmZmYuCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjA5OjQ3XSB0cmFwcy5jOjI0OTU6ZDggRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZm
Zi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MDk6NTNdIHRyYXBzLmM6MjQ5NTpkOSBEb21haW4g
YXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDAwMDAw
MDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDowMF0g
dHJhcHMuYzoyNDk1OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDAwMDAwMDAwMDAwMDAgdG8gMHgwMDAwMDAwMDAwMDBmZmZmLgooWEVO
KSBbMjAxMy0wMi0wNiAxMToxMDowNl0gZ3JhbnRfdGFibGUuYzoyODk6ZDAgSW5jcmVhc2Vk
IG1hcHRyYWNrIHNpemUgdG8gMyBmcmFtZXMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MDZd
IHRyYXBzLmM6MjQ5NTpkMTEgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEw
MDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MTNdIHRyYXBzLmM6MjQ5NTpkMTIgRG9tYWluIGF0dGVt
cHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRv
IDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MTldIHRyYXBz
LmM6MjQ5NTpkMTMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAwMDAwMDAwMDAwZmZmZi4KKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MjhdIHRyYXBzLmM6MjQ5NTpkMTQgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4MDAw
MDAwMDAwMDAwZmZmZi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MjldIGdyYW50X3RhYmxl
LmM6Mjg5OmQwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDQgZnJhbWVzCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVkICgtMykgZm9y
IGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBwdF9pcnFfY3JlYXRlX2JpbmQg
ZmFpbGVkICgtMykgZm9yIGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0x
NTogSFZNIExvYWRlcgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IERldGVj
dGVkIFhlbiB2NC4zLXVuc3RhYmxlCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0x
NTogWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBldmVudCBjaGFubmVsIDUKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTeXN0ZW0gcmVxdWVzdGVkIFNlYUJJT1MKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBDUFUgc3BlZWQgaXMgMzIwMCBNSHoK
KFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsg
MCBjaGFuZ2VkIDAgLT4gNQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFBD
SS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4
XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEwCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElS
UTEwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBs
aW5rIDIgY2hhbmdlZCAwIC0+IDExCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0x
NTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjEwOjM4XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQg
dG8gSVJRNQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDE6
MiBJTlRELT5JUlE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogcGNpIGRl
diAwMTozIElOVEEtPklSUTEwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTog
cGNpIGRldiAwMzowIElOVEEtPklSUTUKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDoz
OF0gSFZNMTU6IHBjaSBkZXYgMDU6MCBJTlRBLT5JUlExMAooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDY6MCBJTlRBLT5JUlExMQooWEVOKSBbMjAxMy0w
Mi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDI6MCBiYXIgMTAgc2l6ZSBseDogMDIw
MDAwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwY2kgZGV2IDAzOjAg
YmFyIDE0IHNpemUgbHg6IDAxMDAwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogcGNpIGRldiAwNjowIGJhciAxMCBzaXplIGx4OiAwMDIwMDAwMAooWEVOKSBbMjAx
My0wMi0wNiAxMToxMDozOF0gbWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzAwMCBtZm49
ZjlhMDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogcGNpIGRl
diAwNDowIGJhciAxMCBzaXplIGx4OiAwMDAyMDAwMAooWEVOKSBbMjAxMy0wMi0wNiAxMTox
MDozOF0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIgMzAgc2l6ZSBseDogMDAwMjAwMDAKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDMwIHNp
emUgbHg6IDAwMDEwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogcGNp
IGRldiAwNTowIGJhciAxMCBzaXplIGx4OiAwMDAwMjAwMAooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDozOF0gbWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzI1MCBtZm49Zjk4ZmUgbnI9
MQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDI6MCBiYXIg
MTQgc2l6ZSBseDogMDAwMDEwMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1
OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgbHg6IDAwMDAwMTAwCihYRU4pIFsyMDEzLTAy
LTA2IDExOjEwOjM4XSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIGx4OiAwMDAw
MDA0MAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IHBjaSBkZXYgMDE6MiBi
YXIgMjAgc2l6ZSBseDogMDAwMDAwMjAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgbHg6IDAwMDAwMDEwCihYRU4pIFsyMDEz
LTAyLTA2IDExOjEwOjM4XSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246
CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gQ1BVMCAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihY
RU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gQ1BVMSAuLi4gNDgtYml0IHBo
eXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4p
IFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gQ1BVMiAuLi4gNDgtYml0IHBoeXMg
Li4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6CihY
RU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIC0gUkVQIElOU0IgYWNyb3NzIHBh
Z2UgYm91bmRhcmllcyAuLi4gcGFzc2VkCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZAooWEVOKSBbMjAx
My0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFBhc3NlZCAyIG9mIDIgdGVzdHMKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBXcml0aW5nIFNNQklPUyB0YWJsZXMgLi4uCihY
RU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogTG9hZGluZyBTZWFCSU9TIC4uLgoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IENyZWF0aW5nIE1QIHRhYmxlcyAu
Li4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBMb2FkaW5nIEFDUEkgLi4u
CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogdm04NiBUU1MgYXQgZmMwMGEw
ODAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBCSU9TIG1hcDoKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiAgMTAwMDAtMTAwZDM6IFNjcmF0Y2ggc3Bh
Y2UKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiAgZTAwMDAtZmZmZmY6IE1h
aW4gQklPUwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IEU4MjAgdGFibGU6
CihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIFswMF06IDAwMDAwMDAwOjAw
MDAwMDAwIC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJBTQooWEVOKSBbMjAxMy0wMi0wNiAxMTox
MDozOF0gSFZNMTU6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUw
MDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIFswMV06IDAwMDAwMDAw
OjAwMGUwMDAwIC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVECihYRU4pIFsyMDEzLTAy
LTA2IDExOjEwOjM4XSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAw
MDA6MmY4MDAwMDA6IFJBTQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6ICBI
T0xFOiAwMDAwMDAwMDoyZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwCihYRU4pIFsyMDEz
LTAyLTA2IDExOjEwOjM4XSBIVk0xNTogIFswM106IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAw
MDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVECihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogSW52b2tpbmcgU2VhQklPUyAuLi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6Mzhd
IEhWTTE1OiBTZWFCSU9TICh2ZXJzaW9uIHJlbC0xLjcuMS04OC1nNGJkOGFlYi0yMDEzMDEy
N18yMDQ2MTEtc2VydmVlcnN0ZXJ0amUpCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBI
Vk0xNTogCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogRm91bmQgWGVuIGh5
cGVydmlzb3Igc2lnbmF0dXJlIGF0IDQwMDAwMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEw
OjM4XSBIVk0xNTogeGVuOiBjb3B5IGU4MjAuLi4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6
MzhdIEhWTTE1OiBSYW0gU2l6ZT0weDJmODAwMDAwICgweDAwMDAwMDAwMDAwMDAwMDAgaGln
aCkKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBSZWxvY2F0aW5nIGxvdyBk
YXRhIGZyb20gMHgwMDBlMmFmMCB0byAweDAwMGVmNzgwIChzaXplIDIxNjQpCihYRU4pIFsy
MDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogUmVsb2NhdGluZyBpbml0IGZyb20gMHgwMDBl
MzM2NCB0byAweDJmN2UyNDAwIChzaXplIDU2MDI4KQooWEVOKSBbMjAxMy0wMi0wNiAxMTox
MDozOF0gSFZNMTU6IENQVSBNaHo9MzE5OQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0g
SFZNMTU6IEZvdW5kIDEwIFBDSSBkZXZpY2VzIChtYXggUENJIGJ1cyBpcyAwMCkKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBBbGxvY2F0ZWQgWGVuIGh5cGVyY2FsbCBw
YWdlIGF0IDJmN2ZmMDAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogRGV0
ZWN0ZWQgWGVuIHY0LjMtdW5zdGFibGUKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBGb3VuZCAzIGNwdShzKSBtYXggc3VwcG9ydGVkIDMgY3B1KHMpCihYRU4pIFsyMDEz
LTAyLTA2IDExOjEwOjM4XSBIVk0xNTogeGVuOiBjb3B5IEJJT1MgdGFibGVzLi4uCihYRU4p
IFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogQ29weWluZyBTTUJJT1MgZW50cnkgcG9p
bnQgZnJvbSAweDAwMDEwMDEwIHRvIDB4MDAwZmRiMTAKKFhFTikgWzIwMTMtMDItMDYgMTE6
MTA6MzhdIEhWTTE1OiBDb3B5aW5nIE1QVEFCTEUgZnJvbSAweGZjMDAxMTkwL2ZjMDAxMWEw
IHRvIDB4MDAwZmRhMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBDb3B5
aW5nIFBJUiBmcm9tIDB4MDAwMTAwMzAgdG8gMHgwMDBmZDk4MAooWEVOKSBbMjAxMy0wMi0w
NiAxMToxMDozOF0gSFZNMTU6IENvcHlpbmcgQUNQSSBSU0RQIGZyb20gMHgwMDAxMDBiMCB0
byAweDAwMGZkOTUwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogU2NhbiBm
b3IgVkdBIG9wdGlvbiByb20KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBS
dW5uaW5nIG9wdGlvbiByb20gYXQgYzAwMDowMDAzCihYRU4pIFsyMDEzLTAyLTA2IDExOjEw
OjM4XSBzdGR2Z2EuYzoxNDc6ZDE1IGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2Rl
cwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFR1cm5pbmcgb24gdmdhIHRl
eHQgbW9kZSBjb25zb2xlCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogU2Vh
QklPUyAodmVyc2lvbiByZWwtMS43LjEtODgtZzRiZDhhZWItMjAxMzAxMjdfMjA0NjExLXNl
cnZlZXJzdGVydGplKQooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IE1hY2hp
bmUgVVVJRCAzMjM0NjhmYy0xNGY0LTRmNmUtYjMyNC1iMmZiYjkzNDJiOTAKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBVSENJIGluaXQgb24gZGV2IDAwOjAxLjIgKGlv
PWMxNDApCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogRm91bmQgMSBscHQg
cG9ydHMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBGb3VuZCAxIHNlcmlh
bCBwb3J0cwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFNlYXJjaGluZyBi
b290b3JkZXIgZm9yOiAvcGNpQGkwY2Y4L2lzYUAxL2ZkY0AwM2YwL2Zsb3BweUAwCihYRU4p
IFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogQVRBIGNvbnRyb2xsZXIgMSBhdCAxZjAv
M2Y0L2MxNjAgKGlycSAxNCBkZXYgOSkKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiBBVEEgY29udHJvbGxlciAyIGF0IDE3MC8zNzQvYzE2OCAoaXJxIDE1IGRldiA5KQoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IGF0YTAtMDogUUVNVSBIQVJERElT
SyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1pQnl0ZXMpCihYRU4pIFsyMDEzLTAyLTA2IDEx
OjEwOjM4XSBIVk0xNTogU2VhcmNoaW5nIGJvb3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAx
LDEvZHJpdmVAMC9kaXNrQDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBh
dGEwLTE6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICgzMDAgR2lCeXRlcykKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTZWFyY2hpbmcgYm9vdG9yZGVyIGZv
cjogL3BjaUBpMGNmOC8qQDEsMS9kcml2ZUAwL2Rpc2tAMQooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDozOF0gSFZNMTU6IERWRC9DRCBbYXRhMS0wOiBRRU1VIERWRC1ST00gQVRBUEktNCBE
VkQvQ0RdCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjM4XSBIVk0xNTogU2VhcmNoaW5nIGJv
b3RvcmRlciBmb3I6IC9wY2lAaTBjZjgvKkAxLDEvZHJpdmVAMS9kaXNrQDAKKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBQUzIga2V5Ym9hcmQgaW5pdGlhbGl6ZWQKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBBbGwgdGhyZWFkcyBjb21wbGV0ZS4K
KFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTY2FuIGZvciBvcHRpb24gcm9t
cwooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDozOF0gSFZNMTU6IFJ1bm5pbmcgb3B0aW9uIHJv
bSBhdCBjOTAwOjAwMDMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0g
Y2FsbCBhcmcxPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0gY2Fs
bCBhcmcxPTAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0gY2FsbCBh
cmcxPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBwbW0gY2FsbCBhcmcx
PTAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBTZWFyY2hpbmcgYm9vdG9y
ZGVyIGZvcjogL3BjaUBpMGNmOC8qQDQKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhW
TTE1OiAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiBQcmVzcyBGMTIgZm9y
IGJvb3QgbWVudS4KKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6MzhdIEhWTTE1OiAKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiBTZWFyY2hpbmcgYm9vdG9yZGVyIGZvcjog
SEFMVAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IGRyaXZlIDB4MDAwZmQ4
ZDA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMg
cz0yMDk3MTUyMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IAooWEVOKSBb
MjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IGRyaXZlIDB4MDAwZmQ4YTA6IFBDSFM9MTYz
ODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMgcz02MjkxNDU2MAoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IDAKKFhFTikgWzIwMTMtMDItMDYg
MTE6MTA6NDFdIEhWTTE1OiBTcGFjZSBhdmFpbGFibGUgZm9yIFVNQjogMDAwY2EwMDAtMDAw
ZWU4MDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiBSZXR1cm5lZCA2MTQ0
MCBieXRlcyBvZiBab25lSGlnaAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6
IGU4MjAgbWFwIGhhcyA2IGl0ZW1zOgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZN
MTU6ICAgMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgPSAxIFJBTQoo
WEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6ICAgMTogMDAwMDAwMDAwMDA5ZmMw
MCAtIDAwMDAwMDAwMDAwYTAwMDAgPSAyIFJFU0VSVkVECihYRU4pIFsyMDEzLTAyLTA2IDEx
OjEwOjQxXSBIVk0xNTogICAyOiAwMDAwMDAwMDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAw
MCA9IDIgUkVTRVJWRUQKKFhFTikgWzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiAgIDM6
IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDJmN2ZmMDAwID0gMSBSQU0KKFhFTikgWzIw
MTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiAgIDQ6IDAwMDAwMDAwMmY3ZmYwMDAgLSAwMDAw
MDAwMDJmODAwMDAwID0gMiBSRVNFUlZFRAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0g
SFZNMTU6ICAgNTogMDAwMDAwMDBmYzAwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgPSAyIFJF
U0VSVkVECihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjQxXSBIVk0xNTogZW50ZXIgaGFuZGxl
XzE5OgooWEVOKSBbMjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6ICAgTlVMTAooWEVOKSBb
MjAxMy0wMi0wNiAxMToxMDo0MV0gSFZNMTU6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4K
KFhFTikgWzIwMTMtMDItMDYgMTE6MTA6NDFdIEhWTTE1OiBCb290aW5nIGZyb20gMDAwMDo3
YzAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEwOjQxXSBncmFudF90YWJsZS5jOjI4OTpkMCBJ
bmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA1IGZyYW1lcwooWEVOKSBbMjAxMy0wMi0wNiAx
MToxMDo1N10gaXJxLmM6Mzc1OiBEb20xNSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJl
Y3QgVmVjdG9yIDB4ZjMKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZl
IG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6
MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhF
TikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49
ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMt
MDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZu
PWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6
MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5y
PTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBn
Zm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1l
bW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMyNTAgbWZuPWY5OGZlIG5yPTEKKFhFTikg
WzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMyNTAg
bWZuPWY5OGZlIG5yPTEKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMAooWEVOKSBbMjAxMy0w
Mi0wNiAxMToxMTowMF0gbWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzAwMCBtZm49Zjlh
MDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAwXSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDAKKFhFTikgWzIwMTMtMDItMDYg
MTE6MTE6MDBdIG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5y
PTIwMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE1IGdmbj1mMzAwMCBtZm49ZjlhMDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjEx
OjAwXSBtZW1vcnlfbWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDAK
KFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBn
Zm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0g
bWVtb3J5X21hcDphZGQ6IGRvbTE1IGdmbj1mMzAwMCBtZm49ZjlhMDAgbnI9MjAwCihYRU4p
IFsyMDEzLTAyLTA2IDExOjExOjAwXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYz
MDAwIG1mbj1mOWEwMCBucj0yMDAKKFhFTikgWzIwMTMtMDItMDYgMTE6MTE6MDBdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMAooWEVOKSBbMjAx
My0wMi0wNiAxMToxMTowMF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE1IGdmbj1mMzAwMCBt
Zm49ZjlhMDAgbnI9MjAwCihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAwXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDAKKFhFTikgWzIwMTMtMDIt
MDYgMTE6MTE6MDBdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4g
MAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGlu
ayAxIGNoYW5nZWQgMTAgLT4gMAooWEVOKSBbMjAxMy0wMi0wNiAxMToxMTowMF0gaXJxLmM6
MjcwOiBEb20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMAooWEVOKSBbMjAxMy0wMi0w
NiAxMToxMTowMF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAw
CihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAyXSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVk
ICgtMykgZm9yIGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjAyXSBwdF9pcnFfY3Jl
YXRlX2JpbmQgZmFpbGVkICgtMykgZm9yIGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjEx
OjAyXSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVkICgtMykgZm9yIGRvbTE1CihYRU4pIFsy
MDEzLTAyLTA2IDExOjExOjAyXSBwdF9pcnFfY3JlYXRlX2JpbmQgZmFpbGVkICgtMykgZm9y
IGRvbTE1CihYRU4pIFsyMDEzLTAyLTA2IDExOjExOjM3XSBncmFudF90YWJsZS5jOjI4OTpk
MCBJbmNyZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byA2IGZyYW1lcwooWEVOKSBbMjAxMy0wMi0w
NiAxMToxMjo0MF0gZ3JhbnRfdGFibGUuYzoyODk6ZDAgSW5jcmVhc2VkIG1hcHRyYWNrIHNp
emUgdG8gNyBmcmFtZXMK
------------0031AD1B80FCDCB5C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0031AD1B80FCDCB5C--



From xen-devel-bounces@lists.xen.org Wed Feb 06 11:25:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:25: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 1U337a-0005oG-4f; Wed, 06 Feb 2013 11:24:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U337Y-0005o5-PE
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:24:56 +0000
Received: from [193.109.254.147:2861] by server-11.bemta-14.messagelabs.com id
	52/3B-30685-88D32115; Wed, 06 Feb 2013 11:24:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360149883!10252706!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30719 invoked from network); 6 Feb 2013 11:24:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:24:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1193430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:24:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 6 Feb 2013
	11:24:43 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Wed, 6 Feb 2013 11:24:43 +0000
Thread-Topic: [PATCH 2/4] Implement code to read coverage informations
Thread-Index: Ac4EXI96DGqhh0KVSsiGdlee6vl8ug==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836A@LONPMAILBOX01.citrite.net>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
	<5112199D02000078000BC553@nat28.tlf.novell.com>
In-Reply-To: <5112199D02000078000BC553@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 07:51 +0000, Jan Beulich wrote:
> >>> On 05.02.13 at 16:58, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > +/**
> > + * File information
> > + * Prefixed with XENCOV_TAG_FILE and a string with filename
> > + */
> > +struct xencov_file
> > +{
> > +    uint32_t version;
> > +    uint32_t stamp;
> > +} __attribute__((packed));
> > +
> > +/**
> > + * Counters information
> > + * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
> > + */
> > +struct xencov_counter
> > +{
> > +    uint32_t num;
> > +    uint64_t values[0];
> > +} __attribute__((packed));
> > +
> > +/**
> > + * Information for each function
> > + * Prefixed with XENCOV_TAG_FUNC
> > + * Number of counter is equal to the number of counter got before
> > + */
> > +struct xencov_function
> > +{
> > +    uint32_t ident;
> > +    uint32_t checksum;
> > +    uint32_t n_ctrs[0];
> > +} __attribute__((packed));
> > +
> > +struct xencov_functions
> > +{
> > +    uint32_t num;
> > +    uint32_t xencov_function[0];
> > +} __attribute__((packed));
> 
> Once again: No use of compiler extensions in public headers.
> 
> Jan
> 

Sorry, I forgot the old mail.
Currently this header describe the output blob exported by Xen. For the
array I can just use 1 instead of 0.

I'm changing a bit the format to avoid packing and alignment problems.

Frediano

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:25:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:25: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 1U337a-0005oG-4f; Wed, 06 Feb 2013 11:24:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U337Y-0005o5-PE
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:24:56 +0000
Received: from [193.109.254.147:2861] by server-11.bemta-14.messagelabs.com id
	52/3B-30685-88D32115; Wed, 06 Feb 2013 11:24:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360149883!10252706!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30719 invoked from network); 6 Feb 2013 11:24:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:24:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="1193430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 11:24:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 6 Feb 2013
	11:24:43 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Wed, 6 Feb 2013 11:24:43 +0000
Thread-Topic: [PATCH 2/4] Implement code to read coverage informations
Thread-Index: Ac4EXI96DGqhh0KVSsiGdlee6vl8ug==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836A@LONPMAILBOX01.citrite.net>
References: <1360079900-31777-1-git-send-email-frediano.ziglio@citrix.com>
	<1360079900-31777-3-git-send-email-frediano.ziglio@citrix.com>
	<5112199D02000078000BC553@nat28.tlf.novell.com>
In-Reply-To: <5112199D02000078000BC553@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/4] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 07:51 +0000, Jan Beulich wrote:
> >>> On 05.02.13 at 16:58, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > +/**
> > + * File information
> > + * Prefixed with XENCOV_TAG_FILE and a string with filename
> > + */
> > +struct xencov_file
> > +{
> > +    uint32_t version;
> > +    uint32_t stamp;
> > +} __attribute__((packed));
> > +
> > +/**
> > + * Counters information
> > + * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
> > + */
> > +struct xencov_counter
> > +{
> > +    uint32_t num;
> > +    uint64_t values[0];
> > +} __attribute__((packed));
> > +
> > +/**
> > + * Information for each function
> > + * Prefixed with XENCOV_TAG_FUNC
> > + * Number of counter is equal to the number of counter got before
> > + */
> > +struct xencov_function
> > +{
> > +    uint32_t ident;
> > +    uint32_t checksum;
> > +    uint32_t n_ctrs[0];
> > +} __attribute__((packed));
> > +
> > +struct xencov_functions
> > +{
> > +    uint32_t num;
> > +    uint32_t xencov_function[0];
> > +} __attribute__((packed));
> 
> Once again: No use of compiler extensions in public headers.
> 
> Jan
> 

Sorry, I forgot the old mail.
Currently this header describe the output blob exported by Xen. For the
array I can just use 1 instead of 0.

I'm changing a bit the format to avoid packing and alignment problems.

Frediano

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:30:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33CC-0006BR-UL; Wed, 06 Feb 2013 11:29:44 +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 1U33CB-0006BD-Lz
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:29:43 +0000
Received: from [85.158.143.99:35520] by server-3.bemta-4.messagelabs.com id
	D6/1C-08920-7AE32115; Wed, 06 Feb 2013 11:29:43 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360150152!18160950!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzIzMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12611 invoked from network); 6 Feb 2013 11:29:13 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 11:29:13 -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 4274D1945;
	Wed,  6 Feb 2013 13:29:11 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C367B2006D; Wed,  6 Feb 2013 13:29:10 +0200 (EET)
Date: Wed, 6 Feb 2013 13:29:10 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130206112910.GT8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51121B5002000078000BC573@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: arrfab@centos.org, agya naila <agya.naila@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="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, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
> >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<pasik@iki.fi> wrote:
> > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade wi=
th =

> > Xen 4.2.1 =

> > with Linux 3.4.28 dom0 kernel.
> > =

> > Does this ring anyone's bells? =

> > =

> > =

> > serial console log of the crash =

> =

> Which doesn't even include the message in the subject afaics, so I
> don't even know what you're talking about. And the other, earlier
> report has no useful information either.
> =

> From an abstract perspective, a front panel NMI to me would mean
> someone pressed an NMI button on the system's front panel. You
> don't think Xen can do anything about this, do you? And even if
> the NMI has another origin, it's still a hardware generated event
> that Xen has no control over.
> =


Arrfab said Xen crashes and reboots in the middle of the boot process,
and the blade chassis management logs the NMI error. The user is not pressi=
ng (NMI) buttons.

The serial log included is everything he gets. No error visible in the seri=
al log,
only a crash/reboot without any errors.. No idea what could be causing that=
.. =


The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.

Do you have any Xen and/or dom0 kernel options to use to do further analysi=
s? =


-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:30:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33CC-0006BR-UL; Wed, 06 Feb 2013 11:29:44 +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 1U33CB-0006BD-Lz
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:29:43 +0000
Received: from [85.158.143.99:35520] by server-3.bemta-4.messagelabs.com id
	D6/1C-08920-7AE32115; Wed, 06 Feb 2013 11:29:43 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360150152!18160950!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzIzMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12611 invoked from network); 6 Feb 2013 11:29:13 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 11:29:13 -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 4274D1945;
	Wed,  6 Feb 2013 13:29:11 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C367B2006D; Wed,  6 Feb 2013 13:29:10 +0200 (EET)
Date: Wed, 6 Feb 2013 13:29:10 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130206112910.GT8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51121B5002000078000BC573@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: arrfab@centos.org, agya naila <agya.naila@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="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, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
> >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<pasik@iki.fi> wrote:
> > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade wi=
th =

> > Xen 4.2.1 =

> > with Linux 3.4.28 dom0 kernel.
> > =

> > Does this ring anyone's bells? =

> > =

> > =

> > serial console log of the crash =

> =

> Which doesn't even include the message in the subject afaics, so I
> don't even know what you're talking about. And the other, earlier
> report has no useful information either.
> =

> From an abstract perspective, a front panel NMI to me would mean
> someone pressed an NMI button on the system's front panel. You
> don't think Xen can do anything about this, do you? And even if
> the NMI has another origin, it's still a hardware generated event
> that Xen has no control over.
> =


Arrfab said Xen crashes and reboots in the middle of the boot process,
and the blade chassis management logs the NMI error. The user is not pressi=
ng (NMI) buttons.

The serial log included is everything he gets. No error visible in the seri=
al log,
only a crash/reboot without any errors.. No idea what could be causing that=
.. =


The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.

Do you have any Xen and/or dom0 kernel options to use to do further analysi=
s? =


-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:40:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33ME-0006Xl-K7; Wed, 06 Feb 2013 11:40:06 +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 1U33MD-0006Xg-1P
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:40:05 +0000
Received: from [85.158.143.99:46801] by server-2.bemta-4.messagelabs.com id
	C1/75-01597-41142115; Wed, 06 Feb 2013 11:40:04 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360150802!27175458!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19698 invoked from network); 6 Feb 2013 11:40:03 -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;
	6 Feb 2013 11:40:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="6457503"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 11:40:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 06:40:01 -0500
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 1U33M9-0006x4-0P;
	Wed, 06 Feb 2013 11:40:01 +0000
Message-ID: <51123F59.6030901@eu.citrix.com>
Date: Wed, 6 Feb 2013 11:32:41 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
	<1360077399.7477.148.camel@zion.uk.xensource.com>
	<CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
	<51115636.6080907@citrix.com>
In-Reply-To: <51115636.6080907@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 05/02/13 18:57, David Vrabel wrote:
> What to do here is a non-trivial decision.  Possible options include:
>
> 1. Merge the 3-level ABI for 4.3.  Work on the FIFO-based ABI in
> parallel, aiming to get this in for 4.4.  This means maintaining 3 event
> channel ABIs in Xen.
>
> 2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.
>
> 3. Status quo.  Defer extending the event channel ABI to 4.4.
>
> The preferable option may be to:
>
> 4. Get the 3-level ABI to a mergable state. In parallel develop a
> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
> freeze is here, evaluate it and make a decision then.

Just to clarify, the difference between #1 and #4 is that in #4 we hold 
off on the merge, to delay committing to a specific course of action 
until later?

That seems at first blush to be a pretty safe option.  But I think it's 
worth pointing out that in practice the end result is likely to be that 
we just go with #1 eventually anyway: if the FIFO ABI can't be finished 
in 4 months giving it all our effort, can we really expect it to be 
finished in any less time while polishing up the 3-level ABI?

I was going to say, "There's no particular reason to merge the 3-level 
ABI sooner rather than later", but of course there is: it allows 
considerably longer and wider testing.

No conclusion here, just adding to the mix of things to consider. :-)

  -George

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:40:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33ME-0006Xl-K7; Wed, 06 Feb 2013 11:40:06 +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 1U33MD-0006Xg-1P
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:40:05 +0000
Received: from [85.158.143.99:46801] by server-2.bemta-4.messagelabs.com id
	C1/75-01597-41142115; Wed, 06 Feb 2013 11:40:04 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360150802!27175458!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19698 invoked from network); 6 Feb 2013 11:40:03 -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;
	6 Feb 2013 11:40:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,614,1355097600"; 
   d="scan'208";a="6457503"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 11:40:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 06:40:01 -0500
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 1U33M9-0006x4-0P;
	Wed, 06 Feb 2013 11:40:01 +0000
Message-ID: <51123F59.6030901@eu.citrix.com>
Date: Wed, 6 Feb 2013 11:32:41 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <CD35C394.4B677%keir.xen@gmail.com> <51111BCA.3010207@citrix.com>
	<1360077399.7477.148.camel@zion.uk.xensource.com>
	<CAFLBxZYPNBDA6XZbMBHBxbxpmJZJBSxAAUe6mzXwUtt_YYXikw@mail.gmail.com>
	<51115636.6080907@citrix.com>
In-Reply-To: <51115636.6080907@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 05/02/13 18:57, David Vrabel wrote:
> What to do here is a non-trivial decision.  Possible options include:
>
> 1. Merge the 3-level ABI for 4.3.  Work on the FIFO-based ABI in
> parallel, aiming to get this in for 4.4.  This means maintaining 3 event
> channel ABIs in Xen.
>
> 2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.
>
> 3. Status quo.  Defer extending the event channel ABI to 4.4.
>
> The preferable option may be to:
>
> 4. Get the 3-level ABI to a mergable state. In parallel develop a
> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
> freeze is here, evaluate it and make a decision then.

Just to clarify, the difference between #1 and #4 is that in #4 we hold 
off on the merge, to delay committing to a specific course of action 
until later?

That seems at first blush to be a pretty safe option.  But I think it's 
worth pointing out that in practice the end result is likely to be that 
we just go with #1 eventually anyway: if the FIFO ABI can't be finished 
in 4 months giving it all our effort, can we really expect it to be 
finished in any less time while polishing up the 3-level ABI?

I was going to say, "There's no particular reason to merge the 3-level 
ABI sooner rather than later", but of course there is: it allows 
considerably longer and wider testing.

No conclusion here, just adding to the mix of things to consider. :-)

  -George

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:46:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:46: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 1U33Rb-0006qz-EP; Wed, 06 Feb 2013 11:45: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 1U33RZ-0006qt-NU
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:45:38 +0000
Received: from [85.158.137.99:57601] by server-7.bemta-3.messagelabs.com id
	3E/CB-10367-C5242115; Wed, 06 Feb 2013 11:45:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360151131!14836160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25274 invoked from network); 6 Feb 2013 11:45:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 11:45:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 11:45:30 +0000
Message-Id: <5112506802000078000BC6CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 11:45:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net> <20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
In-Reply-To: <20130206112910.GT8912@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: arrfab@centos.org, agya naila <agya.naila@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA2LjAyLjEzIGF0IDEyOjI5LCBQYXNpIEvDpHJra8OkaW5lbjxwYXNpa0Bpa2kuZmk+
IHdyb3RlOgo+IE9uIFdlZCwgRmViIDA2LCAyMDEzIGF0IDA3OjU4OjU2QU0gKzAwMDAsIEphbiBC
ZXVsaWNoIHdyb3RlOgo+PiA+Pj4gT24gMDUuMDIuMTMgYXQgMjE6MDgsIFBhc2kgS8Okcmtrw6Rp
bmVuPHBhc2lrQGlraS5maT4gd3JvdGU6Cj4+ID4gQXJyZmFiIChDQydkKSBpcyBhY3R1YWxseSBz
ZWVpbmcgYSBzaW1pbGFyIHByb2JsZW0gb24gSUJNIEhTMjAgYmxhZGUgd2l0aCAKPj4gPiBYZW4g
NC4yLjEgCj4+ID4gd2l0aCBMaW51eCAzLjQuMjggZG9tMCBrZXJuZWwuCj4+ID4gCj4+ID4gRG9l
cyB0aGlzIHJpbmcgYW55b25lJ3MgYmVsbHM/IAo+PiA+IAo+PiA+IAo+PiA+IHNlcmlhbCBjb25z
b2xlIGxvZyBvZiB0aGUgY3Jhc2ggCj4+IAo+PiBXaGljaCBkb2Vzbid0IGV2ZW4gaW5jbHVkZSB0
aGUgbWVzc2FnZSBpbiB0aGUgc3ViamVjdCBhZmFpY3MsIHNvIEkKPj4gZG9uJ3QgZXZlbiBrbm93
IHdoYXQgeW91J3JlIHRhbGtpbmcgYWJvdXQuIEFuZCB0aGUgb3RoZXIsIGVhcmxpZXIKPj4gcmVw
b3J0IGhhcyBubyB1c2VmdWwgaW5mb3JtYXRpb24gZWl0aGVyLgo+PiAKPj4gRnJvbSBhbiBhYnN0
cmFjdCBwZXJzcGVjdGl2ZSwgYSBmcm9udCBwYW5lbCBOTUkgdG8gbWUgd291bGQgbWVhbgo+PiBz
b21lb25lIHByZXNzZWQgYW4gTk1JIGJ1dHRvbiBvbiB0aGUgc3lzdGVtJ3MgZnJvbnQgcGFuZWwu
IFlvdQo+PiBkb24ndCB0aGluayBYZW4gY2FuIGRvIGFueXRoaW5nIGFib3V0IHRoaXMsIGRvIHlv
dT8gQW5kIGV2ZW4gaWYKPj4gdGhlIE5NSSBoYXMgYW5vdGhlciBvcmlnaW4sIGl0J3Mgc3RpbGwg
YSBoYXJkd2FyZSBnZW5lcmF0ZWQgZXZlbnQKPj4gdGhhdCBYZW4gaGFzIG5vIGNvbnRyb2wgb3Zl
ci4KPj4gCj4gCj4gQXJyZmFiIHNhaWQgWGVuIGNyYXNoZXMgYW5kIHJlYm9vdHMgaW4gdGhlIG1p
ZGRsZSBvZiB0aGUgYm9vdCBwcm9jZXNzLAo+IGFuZCB0aGUgYmxhZGUgY2hhc3NpcyBtYW5hZ2Vt
ZW50IGxvZ3MgdGhlIE5NSSBlcnJvci4gVGhlIHVzZXIgaXMgbm90IAo+IHByZXNzaW5nIChOTUkp
IGJ1dHRvbnMuCj4gCj4gVGhlIHNlcmlhbCBsb2cgaW5jbHVkZWQgaXMgZXZlcnl0aGluZyBoZSBn
ZXRzLiBObyBlcnJvciB2aXNpYmxlIGluIHRoZSAKPiBzZXJpYWwgbG9nLAo+IG9ubHkgYSBjcmFz
aC9yZWJvb3Qgd2l0aG91dCBhbnkgZXJyb3JzLi4gTm8gaWRlYSB3aGF0IGNvdWxkIGJlIGNhdXNp
bmcgCj4gdGhhdC4uIAo+IAo+IFRoZSBzYW1lIERvbTAga2VybmVsIChwdm9wcyAzLjQuMjgpIGJv
b3RzIE9LIG9uIGJhcmVtZXRhbCB3aXRob3V0IFhlbi4KCkV2ZW4gd2l0aCB0aGUgSU9NTVUgZnVs
bHkgZW5hYmxlZD8KCj4gRG8geW91IGhhdmUgYW55IFhlbiBhbmQvb3IgZG9tMCBrZXJuZWwgb3B0
aW9ucyB0byB1c2UgdG8gZG8gZnVydGhlciAKPiBhbmFseXNpcz8gCgpJIGRvbid0IHJlY2FsbCBp
ZiBzeW5jX2NvbnNvbGUgd2FzIHVzZWQgLSBpZiBub3QsIGl0IHNob3VsZCBiZS4KCkFuZCBvZiBj
b3Vyc2UgdGhlIGludmVyc2Ugb2YgdGhlIGFib3ZlIC0gdHVybmluZyB0aGUgSU9NTVUgb2ZmIC0K
c2hvdWxkIGJlIHRyaWVkIGluIFhlbi4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:46:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:46: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 1U33Rb-0006qz-EP; Wed, 06 Feb 2013 11:45: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 1U33RZ-0006qt-NU
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:45:38 +0000
Received: from [85.158.137.99:57601] by server-7.bemta-3.messagelabs.com id
	3E/CB-10367-C5242115; Wed, 06 Feb 2013 11:45:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360151131!14836160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25274 invoked from network); 6 Feb 2013 11:45:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 11:45:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 11:45:30 +0000
Message-Id: <5112506802000078000BC6CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 11:45:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net> <20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
In-Reply-To: <20130206112910.GT8912@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: arrfab@centos.org, agya naila <agya.naila@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA2LjAyLjEzIGF0IDEyOjI5LCBQYXNpIEvDpHJra8OkaW5lbjxwYXNpa0Bpa2kuZmk+
IHdyb3RlOgo+IE9uIFdlZCwgRmViIDA2LCAyMDEzIGF0IDA3OjU4OjU2QU0gKzAwMDAsIEphbiBC
ZXVsaWNoIHdyb3RlOgo+PiA+Pj4gT24gMDUuMDIuMTMgYXQgMjE6MDgsIFBhc2kgS8Okcmtrw6Rp
bmVuPHBhc2lrQGlraS5maT4gd3JvdGU6Cj4+ID4gQXJyZmFiIChDQydkKSBpcyBhY3R1YWxseSBz
ZWVpbmcgYSBzaW1pbGFyIHByb2JsZW0gb24gSUJNIEhTMjAgYmxhZGUgd2l0aCAKPj4gPiBYZW4g
NC4yLjEgCj4+ID4gd2l0aCBMaW51eCAzLjQuMjggZG9tMCBrZXJuZWwuCj4+ID4gCj4+ID4gRG9l
cyB0aGlzIHJpbmcgYW55b25lJ3MgYmVsbHM/IAo+PiA+IAo+PiA+IAo+PiA+IHNlcmlhbCBjb25z
b2xlIGxvZyBvZiB0aGUgY3Jhc2ggCj4+IAo+PiBXaGljaCBkb2Vzbid0IGV2ZW4gaW5jbHVkZSB0
aGUgbWVzc2FnZSBpbiB0aGUgc3ViamVjdCBhZmFpY3MsIHNvIEkKPj4gZG9uJ3QgZXZlbiBrbm93
IHdoYXQgeW91J3JlIHRhbGtpbmcgYWJvdXQuIEFuZCB0aGUgb3RoZXIsIGVhcmxpZXIKPj4gcmVw
b3J0IGhhcyBubyB1c2VmdWwgaW5mb3JtYXRpb24gZWl0aGVyLgo+PiAKPj4gRnJvbSBhbiBhYnN0
cmFjdCBwZXJzcGVjdGl2ZSwgYSBmcm9udCBwYW5lbCBOTUkgdG8gbWUgd291bGQgbWVhbgo+PiBz
b21lb25lIHByZXNzZWQgYW4gTk1JIGJ1dHRvbiBvbiB0aGUgc3lzdGVtJ3MgZnJvbnQgcGFuZWwu
IFlvdQo+PiBkb24ndCB0aGluayBYZW4gY2FuIGRvIGFueXRoaW5nIGFib3V0IHRoaXMsIGRvIHlv
dT8gQW5kIGV2ZW4gaWYKPj4gdGhlIE5NSSBoYXMgYW5vdGhlciBvcmlnaW4sIGl0J3Mgc3RpbGwg
YSBoYXJkd2FyZSBnZW5lcmF0ZWQgZXZlbnQKPj4gdGhhdCBYZW4gaGFzIG5vIGNvbnRyb2wgb3Zl
ci4KPj4gCj4gCj4gQXJyZmFiIHNhaWQgWGVuIGNyYXNoZXMgYW5kIHJlYm9vdHMgaW4gdGhlIG1p
ZGRsZSBvZiB0aGUgYm9vdCBwcm9jZXNzLAo+IGFuZCB0aGUgYmxhZGUgY2hhc3NpcyBtYW5hZ2Vt
ZW50IGxvZ3MgdGhlIE5NSSBlcnJvci4gVGhlIHVzZXIgaXMgbm90IAo+IHByZXNzaW5nIChOTUkp
IGJ1dHRvbnMuCj4gCj4gVGhlIHNlcmlhbCBsb2cgaW5jbHVkZWQgaXMgZXZlcnl0aGluZyBoZSBn
ZXRzLiBObyBlcnJvciB2aXNpYmxlIGluIHRoZSAKPiBzZXJpYWwgbG9nLAo+IG9ubHkgYSBjcmFz
aC9yZWJvb3Qgd2l0aG91dCBhbnkgZXJyb3JzLi4gTm8gaWRlYSB3aGF0IGNvdWxkIGJlIGNhdXNp
bmcgCj4gdGhhdC4uIAo+IAo+IFRoZSBzYW1lIERvbTAga2VybmVsIChwdm9wcyAzLjQuMjgpIGJv
b3RzIE9LIG9uIGJhcmVtZXRhbCB3aXRob3V0IFhlbi4KCkV2ZW4gd2l0aCB0aGUgSU9NTVUgZnVs
bHkgZW5hYmxlZD8KCj4gRG8geW91IGhhdmUgYW55IFhlbiBhbmQvb3IgZG9tMCBrZXJuZWwgb3B0
aW9ucyB0byB1c2UgdG8gZG8gZnVydGhlciAKPiBhbmFseXNpcz8gCgpJIGRvbid0IHJlY2FsbCBp
ZiBzeW5jX2NvbnNvbGUgd2FzIHVzZWQgLSBpZiBub3QsIGl0IHNob3VsZCBiZS4KCkFuZCBvZiBj
b3Vyc2UgdGhlIGludmVyc2Ugb2YgdGhlIGFib3ZlIC0gdHVybmluZyB0aGUgSU9NTVUgb2ZmIC0K
c2hvdWxkIGJlIHRyaWVkIGluIFhlbi4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:47:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:47: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 1U33TM-0006wT-Vn; Wed, 06 Feb 2013 11:47:28 +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 1U33TK-0006wK-NB
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:47:26 +0000
Received: from [85.158.137.99:64766] by server-5.bemta-3.messagelabs.com id
	1F/13-04457-DC242115; Wed, 06 Feb 2013 11:47:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360151193!20207806!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1427 invoked from network); 6 Feb 2013 11:46:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 11:46:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 11:46:32 +0000
Message-Id: <511250A702000078000BC6CF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 11:46:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <510FF54E.1070706@citrix.com> <CD35C394.4B677%keir.xen@gmail.com>
In-Reply-To: <CD35C394.4B677%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 20:59, Keir Fraser <keir.xen@gmail.com> wrote:
> On 04/02/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:
>> Here is a design for a scalable event channel ABI for Xen.  It has a
>> number of benefits over the design currently being proposed by Wei Lui.
>> 
>> * More event channels (>100,000).
>> * 16 event priorities.
>> * Reduced memory requirements (only 1 additional page per domU).
>> * The use of FIFOs for events ensures fairness, whereas it is difficult
>> to reason about the fairness with the current bitmap system.
> 
> I have some sympathy for this design. It's primary downside compared with
> the 3-level alternative is its greater space cost (32*#vcpus). However, as
> you say the fairness and prioritisation features are rather nice. Also
> having the data structures be per vcpu may well help avoid cacheline
> contention on busy multi-vcpu guests.
> 
> Interested in what others think, but I may actually prefer a ground-up
> redesign like this.

So do I, fwiw.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:47:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11:47: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 1U33TM-0006wT-Vn; Wed, 06 Feb 2013 11:47:28 +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 1U33TK-0006wK-NB
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:47:26 +0000
Received: from [85.158.137.99:64766] by server-5.bemta-3.messagelabs.com id
	1F/13-04457-DC242115; Wed, 06 Feb 2013 11:47:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360151193!20207806!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1427 invoked from network); 6 Feb 2013 11:46:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 11:46:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 11:46:32 +0000
Message-Id: <511250A702000078000BC6CF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 11:46:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <510FF54E.1070706@citrix.com> <CD35C394.4B677%keir.xen@gmail.com>
In-Reply-To: <CD35C394.4B677%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.13 at 20:59, Keir Fraser <keir.xen@gmail.com> wrote:
> On 04/02/2013 17:52, "David Vrabel" <david.vrabel@citrix.com> wrote:
>> Here is a design for a scalable event channel ABI for Xen.  It has a
>> number of benefits over the design currently being proposed by Wei Lui.
>> 
>> * More event channels (>100,000).
>> * 16 event priorities.
>> * Reduced memory requirements (only 1 additional page per domU).
>> * The use of FIFOs for events ensures fairness, whereas it is difficult
>> to reason about the fairness with the current bitmap system.
> 
> I have some sympathy for this design. It's primary downside compared with
> the 3-level alternative is its greater space cost (32*#vcpus). However, as
> you say the fairness and prioritisation features are rather nice. Also
> having the data structures be per vcpu may well help avoid cacheline
> contention on busy multi-vcpu guests.
> 
> Interested in what others think, but I may actually prefer a ground-up
> redesign like this.

So do I, fwiw.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:48:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33UB-00070R-FD; Wed, 06 Feb 2013 11:48:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1U33UA-00070E-K1
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:48:18 +0000
Received: from [85.158.138.51:36604] by server-4.bemta-3.messagelabs.com id
	E1/6F-12802-10342115; Wed, 06 Feb 2013 11:48:17 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360151295!20984525!1
X-Originating-IP: [209.85.128.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6019 invoked from network); 6 Feb 2013 11:48:16 -0000
Received: from mail-ve0-f173.google.com (HELO mail-ve0-f173.google.com)
	(209.85.128.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:48:16 -0000
Received: by mail-ve0-f173.google.com with SMTP id oz10so1072145veb.4
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 03:48:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=5MlChEYpAu4E6i0ImAy9NjZ1K3iip4WDdilVyKFLD2M=;
	b=MXWcN3ZtQnTzI1hi3RxhAcqOYHq1++uIa2dR3loc4wjnXZmnTYOByc6oC99CuCCmvJ
	ray9Xojkz+aPgFr3asQ5K00nsnH2zU/gKgiT1Qb7LGJPUAJiRyCmpLekS/4rdjopYfSh
	q1OcYRIdOQM5fyGWndj4P8Xnd4ICFGHvB5zQjCiMrkc8JhIUuNC7HScbAVLZJ7KRfpK5
	wbvhdc7STA1bA1ef474wZ4dqTnIIkNWp0hGgZGu4yNzL297WKI9MkFJCMC7eaQqvQ2hW
	Bl1HQbN54Eez7l8+yaStjBtpcK+6iisGzAZRLrAp0SosEi7rTtFZNczF/7ccx+2KifOj
	6abw==
X-Received: by 10.220.215.73 with SMTP id hd9mr32381219vcb.19.1360151295196;
	Wed, 06 Feb 2013 03:48:15 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-179-137.ip50.fastwebnet.it.
	[93.34.179.137])
	by mx.google.com with ESMTPS id x17sm32385866vdi.1.2013.02.06.03.48.12
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 03:48:14 -0800 (PST)
Message-ID: <511242F9.7000707@gnu.org>
Date: Wed, 06 Feb 2013 12:48:09 +0100
From: Paolo Bonzini <bonzini@gnu.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<5110207B.4060501@gnu.org>
	<CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.gmail.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458369@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458369@LONPMAILBOX01.citrite.net>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, "iant@google.com" <iant@google.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 06/02/2013 12:22, Frediano Ziglio ha scritto:
> 
> I used an header from Linux which is derived from this GCC header when
> GCC was still GPL2 so GPL3 does not apply. Xen is GPL2 too so there is
> no problem using this header in Xen. The problem is including in the
> public headers.
> 
> Actually I changed patch to use the header only privately in Xen. I
> wrote a new header with the format that Xen export. However somebody
> could complaint that the format I used to export came from GCC ABI
> documented in the header.

ABIs are not copyrightable.  Or at least widely thought not to be so,
IANAL etc.

Paolo

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:48:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33UB-00070R-FD; Wed, 06 Feb 2013 11:48:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1U33UA-00070E-K1
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:48:18 +0000
Received: from [85.158.138.51:36604] by server-4.bemta-3.messagelabs.com id
	E1/6F-12802-10342115; Wed, 06 Feb 2013 11:48:17 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360151295!20984525!1
X-Originating-IP: [209.85.128.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6019 invoked from network); 6 Feb 2013 11:48:16 -0000
Received: from mail-ve0-f173.google.com (HELO mail-ve0-f173.google.com)
	(209.85.128.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:48:16 -0000
Received: by mail-ve0-f173.google.com with SMTP id oz10so1072145veb.4
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 03:48:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=5MlChEYpAu4E6i0ImAy9NjZ1K3iip4WDdilVyKFLD2M=;
	b=MXWcN3ZtQnTzI1hi3RxhAcqOYHq1++uIa2dR3loc4wjnXZmnTYOByc6oC99CuCCmvJ
	ray9Xojkz+aPgFr3asQ5K00nsnH2zU/gKgiT1Qb7LGJPUAJiRyCmpLekS/4rdjopYfSh
	q1OcYRIdOQM5fyGWndj4P8Xnd4ICFGHvB5zQjCiMrkc8JhIUuNC7HScbAVLZJ7KRfpK5
	wbvhdc7STA1bA1ef474wZ4dqTnIIkNWp0hGgZGu4yNzL297WKI9MkFJCMC7eaQqvQ2hW
	Bl1HQbN54Eez7l8+yaStjBtpcK+6iisGzAZRLrAp0SosEi7rTtFZNczF/7ccx+2KifOj
	6abw==
X-Received: by 10.220.215.73 with SMTP id hd9mr32381219vcb.19.1360151295196;
	Wed, 06 Feb 2013 03:48:15 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-179-137.ip50.fastwebnet.it.
	[93.34.179.137])
	by mx.google.com with ESMTPS id x17sm32385866vdi.1.2013.02.06.03.48.12
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 03:48:14 -0800 (PST)
Message-ID: <511242F9.7000707@gnu.org>
Date: Wed, 06 Feb 2013 12:48:09 +0100
From: Paolo Bonzini <bonzini@gnu.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45835B@LONPMAILBOX01.citrite.net>
	<CAKOQZ8w4H+FgZ+qZ1L7+V3Tc_NLOrgtDujMksh5JRfdHVXCiVA@mail.gmail.com>
	<5110207B.4060501@gnu.org>
	<CAKOQZ8yadccQUxqWZrO-SAYV0dzXau94x=AmxY82n3zFjbw22w@mail.gmail.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458369@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458369@LONPMAILBOX01.citrite.net>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, "iant@google.com" <iant@google.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] coverage license information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 06/02/2013 12:22, Frediano Ziglio ha scritto:
> 
> I used an header from Linux which is derived from this GCC header when
> GCC was still GPL2 so GPL3 does not apply. Xen is GPL2 too so there is
> no problem using this header in Xen. The problem is including in the
> public headers.
> 
> Actually I changed patch to use the header only privately in Xen. I
> wrote a new header with the format that Xen export. However somebody
> could complaint that the format I used to export came from GCC ABI
> documented in the header.

ABIs are not copyrightable.  Or at least widely thought not to be so,
IANAL etc.

Paolo

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 11:49:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33Uk-00075S-WD; Wed, 06 Feb 2013 11:48:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U33Uj-000752-9B
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:48:53 +0000
Received: from [193.109.254.147:54146] by server-4.bemta-14.messagelabs.com id
	F2/54-20719-42342115; Wed, 06 Feb 2013 11:48:52 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360151331!3866214!1
X-Originating-IP: [209.85.212.170]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11064 invoked from network); 6 Feb 2013 11:48:51 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:48:51 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so6860133wib.3
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 03:48:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Osu6M4F8iIOiJB4HN8DVSfd52Hrcbe0rZF1TLRR5gcc=;
	b=0CNd0cg7Wx1/OpX4Mwu+gWH0RZF3wGXy6/ThERUnsca8aBikLy30zXOdNcEW67R9QW
	s6JSWVX1ISLPOo96C/qAZmYJY9vOX59urHjnTfoQfyQfxadOwgw81k/w+i9/+/CEU9hW
	8ywu4kcUfS+Qn9E/BXRM16UoCvC3xAhxWjvrRkLDVXuzSEyYtFzBrHJn0ggIjuy3eJek
	xSgFVN62k5zRceQTfSqwRPervILS+JiLnGX1FtGy+0aobiE0MwIxqWOm3NPpFPV+8cMV
	7+kUuNyeS6H2MJjSNKU87GIG0xWzuuOxyoalN1jI5x6eke2pj4wmmCUKHFPrZUn0BjH/
	HXRg==
MIME-Version: 1.0
X-Received: by 10.180.8.197 with SMTP id t5mr4364617wia.27.1360151330920; Wed,
	06 Feb 2013 03:48:50 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Wed, 6 Feb 2013 03:48:50 -0800 (PST)
In-Reply-To: <20130206112910.GT8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
Date: Wed, 6 Feb 2013 12:48:50 +0100
Message-ID: <CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============7204242192726790276=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7204242192726790276==
Content-Type: multipart/alternative; boundary=f46d04428240eb97ab04d50ce86f

--f46d04428240eb97ab04d50ce86f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Pasi to forward this email for me too, it seem not only me facing
this problem. I found this guy also found similar problem, its in french
but we can translate it easily using google
http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-t=
d1230690.html

I found parameter nmi=3Dignore | dom0 | fatal

nmi=3Dreaction : Enables you to specify how the hypervisor reacts to a non =
-
maskable interrupt
(NMI) resulting from a parity or I/O error. Possible values for reaction
are fatal (the hypervisor
prints a diagnostic message and then hangs), dom0 (send a message to
domain0 for logging
purposes but continue), and ignore (ignore the error). If you do not
specify this option, Xen
uses the default value dom0 internally.

But its still doesn't work on my machine.

Agya


On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
> > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<pasik@iki.fi> wrote:
> > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade
> with
> > > Xen 4.2.1
> > > with Linux 3.4.28 dom0 kernel.
> > >
> > > Does this ring anyone's bells?
> > >
> > >
> > > serial console log of the crash
> >
> > Which doesn't even include the message in the subject afaics, so I
> > don't even know what you're talking about. And the other, earlier
> > report has no useful information either.
> >
> > From an abstract perspective, a front panel NMI to me would mean
> > someone pressed an NMI button on the system's front panel. You
> > don't think Xen can do anything about this, do you? And even if
> > the NMI has another origin, it's still a hardware generated event
> > that Xen has no control over.
> >
>
> Arrfab said Xen crashes and reboots in the middle of the boot process,
> and the blade chassis management logs the NMI error. The user is not
> pressing (NMI) buttons.
>
> The serial log included is everything he gets. No error visible in the
> serial log,
> only a crash/reboot without any errors.. No idea what could be causing
> that..
>
> The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.
>
> Do you have any Xen and/or dom0 kernel options to use to do further
> analysis?
>
> -- Pasi
>
>

--f46d04428240eb97ab04d50ce86f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Pasi to forward this email for me too, it seem not only me facing=
 this problem. I found this guy also found similar problem, its in french b=
ut we can translate it easily using google=A0<a href=3D"http://debian.2.n7.=
nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html">http=
://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td123=
0690.html</a><div>
<br></div><div>I found parameter nmi=3Dignore | dom0 | fatal=A0</div><div><=
br></div><div><div>nmi=3Dreaction : Enables you to specify how the hypervis=
or reacts to a non - maskable interrupt</div><div>(NMI) resulting from a pa=
rity or I/O error. Possible values for reaction are fatal (the hypervisor</=
div>
<div>prints a diagnostic message and then hangs), dom0 (send a message to d=
omain0 for logging</div><div>purposes but continue), and ignore (ignore the=
 error). If you do not specify this option, Xen</div><div>uses the default =
value dom0 internally.</div>
<div><br></div>But its still doesn&#39;t work on my machine.</div><div><br>=
</div><div>Agya</div><div><br></div><div><br><div class=3D"gmail_quote">On =
Wed, Feb 6, 2013 at 12:29 PM, 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> =
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 W=
ed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:<br>
&gt; &gt;&gt;&gt; On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen&lt;<a href=3D"m=
ailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<br>
&gt; &gt; Arrfab (CC&#39;d) is actually seeing a similar problem on IBM HS2=
0 blade with<br>
&gt; &gt; Xen 4.2.1<br>
&gt; &gt; with Linux 3.4.28 dom0 kernel.<br>
&gt; &gt;<br>
&gt; &gt; Does this ring anyone&#39;s bells?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; serial console log of the crash<br>
&gt;<br>
&gt; Which doesn&#39;t even include the message in the subject afaics, so I=
<br>
&gt; don&#39;t even know what you&#39;re talking about. And the other, earl=
ier<br>
&gt; report has no useful information either.<br>
&gt;<br>
&gt; From an abstract perspective, a front panel NMI to me would mean<br>
&gt; someone pressed an NMI button on the system&#39;s front panel. You<br>
&gt; don&#39;t think Xen can do anything about this, do you? And even if<br=
>
&gt; the NMI has another origin, it&#39;s still a hardware generated event<=
br>
&gt; that Xen has no control over.<br>
&gt;<br>
<br>
</div></div>Arrfab said Xen crashes and reboots in the middle of the boot p=
rocess,<br>
and the blade chassis management logs the NMI error. The user is not pressi=
ng (NMI) buttons.<br>
<br>
The serial log included is everything he gets. No error visible in the seri=
al log,<br>
only a crash/reboot without any errors.. No idea what could be causing that=
..<br>
<br>
The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.<br>
<br>
Do you have any Xen and/or dom0 kernel options to use to do further analysi=
s?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div>

--f46d04428240eb97ab04d50ce86f--


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

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

--===============7204242192726790276==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 11:49:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 11: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 1U33Uk-00075S-WD; Wed, 06 Feb 2013 11:48:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U33Uj-000752-9B
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 11:48:53 +0000
Received: from [193.109.254.147:54146] by server-4.bemta-14.messagelabs.com id
	F2/54-20719-42342115; Wed, 06 Feb 2013 11:48:52 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360151331!3866214!1
X-Originating-IP: [209.85.212.170]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11064 invoked from network); 6 Feb 2013 11:48:51 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 11:48:51 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so6860133wib.3
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 03:48:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Osu6M4F8iIOiJB4HN8DVSfd52Hrcbe0rZF1TLRR5gcc=;
	b=0CNd0cg7Wx1/OpX4Mwu+gWH0RZF3wGXy6/ThERUnsca8aBikLy30zXOdNcEW67R9QW
	s6JSWVX1ISLPOo96C/qAZmYJY9vOX59urHjnTfoQfyQfxadOwgw81k/w+i9/+/CEU9hW
	8ywu4kcUfS+Qn9E/BXRM16UoCvC3xAhxWjvrRkLDVXuzSEyYtFzBrHJn0ggIjuy3eJek
	xSgFVN62k5zRceQTfSqwRPervILS+JiLnGX1FtGy+0aobiE0MwIxqWOm3NPpFPV+8cMV
	7+kUuNyeS6H2MJjSNKU87GIG0xWzuuOxyoalN1jI5x6eke2pj4wmmCUKHFPrZUn0BjH/
	HXRg==
MIME-Version: 1.0
X-Received: by 10.180.8.197 with SMTP id t5mr4364617wia.27.1360151330920; Wed,
	06 Feb 2013 03:48:50 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Wed, 6 Feb 2013 03:48:50 -0800 (PST)
In-Reply-To: <20130206112910.GT8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
Date: Wed, 6 Feb 2013 12:48:50 +0100
Message-ID: <CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============7204242192726790276=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7204242192726790276==
Content-Type: multipart/alternative; boundary=f46d04428240eb97ab04d50ce86f

--f46d04428240eb97ab04d50ce86f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Pasi to forward this email for me too, it seem not only me facing
this problem. I found this guy also found similar problem, its in french
but we can translate it easily using google
http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-t=
d1230690.html

I found parameter nmi=3Dignore | dom0 | fatal

nmi=3Dreaction : Enables you to specify how the hypervisor reacts to a non =
-
maskable interrupt
(NMI) resulting from a parity or I/O error. Possible values for reaction
are fatal (the hypervisor
prints a diagnostic message and then hangs), dom0 (send a message to
domain0 for logging
purposes but continue), and ignore (ignore the error). If you do not
specify this option, Xen
uses the default value dom0 internally.

But its still doesn't work on my machine.

Agya


On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
> > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<pasik@iki.fi> wrote:
> > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade
> with
> > > Xen 4.2.1
> > > with Linux 3.4.28 dom0 kernel.
> > >
> > > Does this ring anyone's bells?
> > >
> > >
> > > serial console log of the crash
> >
> > Which doesn't even include the message in the subject afaics, so I
> > don't even know what you're talking about. And the other, earlier
> > report has no useful information either.
> >
> > From an abstract perspective, a front panel NMI to me would mean
> > someone pressed an NMI button on the system's front panel. You
> > don't think Xen can do anything about this, do you? And even if
> > the NMI has another origin, it's still a hardware generated event
> > that Xen has no control over.
> >
>
> Arrfab said Xen crashes and reboots in the middle of the boot process,
> and the blade chassis management logs the NMI error. The user is not
> pressing (NMI) buttons.
>
> The serial log included is everything he gets. No error visible in the
> serial log,
> only a crash/reboot without any errors.. No idea what could be causing
> that..
>
> The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.
>
> Do you have any Xen and/or dom0 kernel options to use to do further
> analysis?
>
> -- Pasi
>
>

--f46d04428240eb97ab04d50ce86f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Pasi to forward this email for me too, it seem not only me facing=
 this problem. I found this guy also found similar problem, its in french b=
ut we can translate it easily using google=A0<a href=3D"http://debian.2.n7.=
nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html">http=
://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td123=
0690.html</a><div>
<br></div><div>I found parameter nmi=3Dignore | dom0 | fatal=A0</div><div><=
br></div><div><div>nmi=3Dreaction : Enables you to specify how the hypervis=
or reacts to a non - maskable interrupt</div><div>(NMI) resulting from a pa=
rity or I/O error. Possible values for reaction are fatal (the hypervisor</=
div>
<div>prints a diagnostic message and then hangs), dom0 (send a message to d=
omain0 for logging</div><div>purposes but continue), and ignore (ignore the=
 error). If you do not specify this option, Xen</div><div>uses the default =
value dom0 internally.</div>
<div><br></div>But its still doesn&#39;t work on my machine.</div><div><br>=
</div><div>Agya</div><div><br></div><div><br><div class=3D"gmail_quote">On =
Wed, Feb 6, 2013 at 12:29 PM, 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> =
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 W=
ed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:<br>
&gt; &gt;&gt;&gt; On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen&lt;<a href=3D"m=
ailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<br>
&gt; &gt; Arrfab (CC&#39;d) is actually seeing a similar problem on IBM HS2=
0 blade with<br>
&gt; &gt; Xen 4.2.1<br>
&gt; &gt; with Linux 3.4.28 dom0 kernel.<br>
&gt; &gt;<br>
&gt; &gt; Does this ring anyone&#39;s bells?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; serial console log of the crash<br>
&gt;<br>
&gt; Which doesn&#39;t even include the message in the subject afaics, so I=
<br>
&gt; don&#39;t even know what you&#39;re talking about. And the other, earl=
ier<br>
&gt; report has no useful information either.<br>
&gt;<br>
&gt; From an abstract perspective, a front panel NMI to me would mean<br>
&gt; someone pressed an NMI button on the system&#39;s front panel. You<br>
&gt; don&#39;t think Xen can do anything about this, do you? And even if<br=
>
&gt; the NMI has another origin, it&#39;s still a hardware generated event<=
br>
&gt; that Xen has no control over.<br>
&gt;<br>
<br>
</div></div>Arrfab said Xen crashes and reboots in the middle of the boot p=
rocess,<br>
and the blade chassis management logs the NMI error. The user is not pressi=
ng (NMI) buttons.<br>
<br>
The serial log included is everything he gets. No error visible in the seri=
al log,<br>
only a crash/reboot without any errors.. No idea what could be causing that=
..<br>
<br>
The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.<br>
<br>
Do you have any Xen and/or dom0 kernel options to use to do further analysi=
s?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div>

--f46d04428240eb97ab04d50ce86f--


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

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

--===============7204242192726790276==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 12:06:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 12:06: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 1U33lX-0008Eo-Cr; Wed, 06 Feb 2013 12:06:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U33lW-0008Eg-C4
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 12:06:14 +0000
Received: from [85.158.143.35:16104] by server-3.bemta-4.messagelabs.com id
	5A/89-08920-53742115; Wed, 06 Feb 2013 12:06:13 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360152115!11296835!1
X-Originating-IP: [74.125.82.175]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5303 invoked from network); 6 Feb 2013 12:01:56 -0000
Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com)
	(74.125.82.175)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 12:01:56 -0000
Received: by mail-we0-f175.google.com with SMTP id x8so1077925wey.20
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 04:01:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=naFwZTnr/WoE6nO3OjCgjs4EhEai4emThmZLHoORw9I=;
	b=GAznToIrScW3lif+CksS2ZUPKlhLGcA0jz7Eq9cloI7DOtuI3VGrIKgWRj3n02v9Qm
	ltsuvaZNVpVWA12zQyE8yItVnS/5gvISl/6XDjQ1gvQXsfLGa5OB/K1E2QfuCMYqVS+4
	JQ1fylMfDgx09Qe+qP55Nri3e7EsDHUfprxK0PZ2IUkZX8WAq4Kl88ZRYVwUZ8lwykn7
	ND5ffVnEwZvzv29UknbtfC5UDrGX/YvTOQ38SbGVE2qGp/BmauQSLVo3CV9xepUHLI04
	iclwuNariebG9ngqPinPecLJWxo9kEK5hvWg1+Ay/VsOUdvtMxQSkmdRMBPtSwmMPEOE
	GN0g==
MIME-Version: 1.0
X-Received: by 10.194.19.10 with SMTP id a10mr49134808wje.45.1360152115521;
	Wed, 06 Feb 2013 04:01:55 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Wed, 6 Feb 2013 04:01:55 -0800 (PST)
In-Reply-To: <CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
	<CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
Date: Wed, 6 Feb 2013 13:01:55 +0100
Message-ID: <CAN-nQwhjdS3bVLfGYTawM08_B=80a3xGTeFTbSF2TrEE=aumdg@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============4336674204630531010=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4336674204630531010==
Content-Type: multipart/alternative; boundary=047d7b5d4808afaa1404d50d1720

--047d7b5d4808afaa1404d50d1720
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As I read on IBM paper :

When a non-maskable interrupt (NMI) signal is received, the processor
immediately drops what it was doing and attends to it. The NMI signal is
normally used only for critical problem situations, such as serious
hardware errors This setting is Enabled by default. When an NMI is issued
by a critical event the BMC performs the system to reset for recovering the
system. The BMC logs the reboot and additional error events in the SEL.

I dont know why XEN trigger or cause this NMI signal, since when I boot the
machine with the same Operating system Ubuntu 12.04.1 Desktop 64 bit
without XEN its run perfectly. One more interesting fact with the same Dom0
with excacly the same XEN version and configuration running perfectly on my
notebook Toshiba Satelite L735 Intel I5, Hopefully anyone have solution for
the server.

Agya

On Wed, Feb 6, 2013 at 12:48 PM, agya naila <agya.naila@gmail.com> wrote:

> Thank you Pasi to forward this email for me too, it seem not only me
> facing this problem. I found this guy also found similar problem, its in
> french but we can translate it easily using google
> http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot=
-td1230690.html
>
> I found parameter nmi=3Dignore | dom0 | fatal
>
> nmi=3Dreaction : Enables you to specify how the hypervisor reacts to a no=
n -
> maskable interrupt
> (NMI) resulting from a parity or I/O error. Possible values for reaction
> are fatal (the hypervisor
> prints a diagnostic message and then hangs), dom0 (send a message to
> domain0 for logging
> purposes but continue), and ignore (ignore the error). If you do not
> specify this option, Xen
> uses the default value dom0 internally.
>
> But its still doesn't work on my machine.
>
> Agya
>
>
> On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote=
:
>
>> On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
>> > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<pasik@iki.fi> wrote:
>> > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade
>> with
>> > > Xen 4.2.1
>> > > with Linux 3.4.28 dom0 kernel.
>> > >
>> > > Does this ring anyone's bells?
>> > >
>> > >
>> > > serial console log of the crash
>> >
>> > Which doesn't even include the message in the subject afaics, so I
>> > don't even know what you're talking about. And the other, earlier
>> > report has no useful information either.
>> >
>> > From an abstract perspective, a front panel NMI to me would mean
>> > someone pressed an NMI button on the system's front panel. You
>> > don't think Xen can do anything about this, do you? And even if
>> > the NMI has another origin, it's still a hardware generated event
>> > that Xen has no control over.
>> >
>>
>> Arrfab said Xen crashes and reboots in the middle of the boot process,
>> and the blade chassis management logs the NMI error. The user is not
>> pressing (NMI) buttons.
>>
>> The serial log included is everything he gets. No error visible in the
>> serial log,
>> only a crash/reboot without any errors.. No idea what could be causing
>> that..
>>
>> The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.
>>
>> Do you have any Xen and/or dom0 kernel options to use to do further
>> analysis?
>>
>> -- Pasi
>>
>>
>

--047d7b5d4808afaa1404d50d1720
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As I read on IBM paper :<div><br></div><div><div>When a non-maskable interr=
upt (NMI) signal is received, the processor immediately drops what it was d=
oing and attends to it. The NMI signal is normally used only for critical p=
roblem situations, such as serious hardware errors This setting is Enabled =
by default. When an NMI is issued by a critical event the BMC performs the =
system to reset for recovering the system. The BMC logs the reboot and addi=
tional error events in the SEL.</div>
<div><br></div><div>I dont know why XEN trigger or cause this NMI signal, s=
ince when I boot the machine with the same Operating system Ubuntu 12.04.1 =
Desktop 64 bit without XEN its run perfectly. One more interesting fact wit=
h the same Dom0 with excacly the same XEN version and configuration running=
 perfectly on my notebook Toshiba Satelite L735 Intel I5, Hopefully anyone =
have solution for the server.</div>
<div><br></div><div>Agya</div><br><div class=3D"gmail_quote">On Wed, Feb 6,=
 2013 at 12:48 PM, agya naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.=
naila@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Thank you Pasi to forward this email for me =
too, it seem not only me facing this problem. I found this guy also found s=
imilar problem, its in french but we can translate it easily using google=
=A0<a href=3D"http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-6=
4bits-reboot-td1230690.html" target=3D"_blank">http://debian.2.n7.nabble.co=
m/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html</a><div>

<br></div><div>I found parameter nmi=3Dignore | dom0 | fatal=A0</div><div><=
br></div><div><div>nmi=3Dreaction : Enables you to specify how the hypervis=
or reacts to a non - maskable interrupt</div><div>(NMI) resulting from a pa=
rity or I/O error. Possible values for reaction are fatal (the hypervisor</=
div>

<div>prints a diagnostic message and then hangs), dom0 (send a message to d=
omain0 for logging</div><div>purposes but continue), and ignore (ignore the=
 error). If you do not specify this option, Xen</div><div>uses the default =
value dom0 internally.</div>

<div><br></div>But its still doesn&#39;t work on my machine.</div><span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Agya</div></font>=
</span><div class=3D"HOEnZb"><div class=3D"h5"><div><br></div><div><br><div=
 class=3D"gmail_quote">
On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;=
<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt;</spa=
n> 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 Wed, Feb 06, 2013 at 07:58:56AM=
 +0000, Jan Beulich wrote:<br>
&gt; &gt;&gt;&gt; On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen&lt;<a href=3D"m=
ailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote:<br>
&gt; &gt; Arrfab (CC&#39;d) is actually seeing a similar problem on IBM HS2=
0 blade with<br>
&gt; &gt; Xen 4.2.1<br>
&gt; &gt; with Linux 3.4.28 dom0 kernel.<br>
&gt; &gt;<br>
&gt; &gt; Does this ring anyone&#39;s bells?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; serial console log of the crash<br>
&gt;<br>
&gt; Which doesn&#39;t even include the message in the subject afaics, so I=
<br>
&gt; don&#39;t even know what you&#39;re talking about. And the other, earl=
ier<br>
&gt; report has no useful information either.<br>
&gt;<br>
&gt; From an abstract perspective, a front panel NMI to me would mean<br>
&gt; someone pressed an NMI button on the system&#39;s front panel. You<br>
&gt; don&#39;t think Xen can do anything about this, do you? And even if<br=
>
&gt; the NMI has another origin, it&#39;s still a hardware generated event<=
br>
&gt; that Xen has no control over.<br>
&gt;<br>
<br>
</div></div>Arrfab said Xen crashes and reboots in the middle of the boot p=
rocess,<br>
and the blade chassis management logs the NMI error. The user is not pressi=
ng (NMI) buttons.<br>
<br>
The serial log included is everything he gets. No error visible in the seri=
al log,<br>
only a crash/reboot without any errors.. No idea what could be causing that=
..<br>
<br>
The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.<br>
<br>
Do you have any Xen and/or dom0 kernel options to use to do further analysi=
s?<br>
<span><font color=3D"#888888"><br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--047d7b5d4808afaa1404d50d1720--


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

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

--===============4336674204630531010==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 12:06:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 12:06: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 1U33lX-0008Eo-Cr; Wed, 06 Feb 2013 12:06:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U33lW-0008Eg-C4
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 12:06:14 +0000
Received: from [85.158.143.35:16104] by server-3.bemta-4.messagelabs.com id
	5A/89-08920-53742115; Wed, 06 Feb 2013 12:06:13 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360152115!11296835!1
X-Originating-IP: [74.125.82.175]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5303 invoked from network); 6 Feb 2013 12:01:56 -0000
Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com)
	(74.125.82.175)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 12:01:56 -0000
Received: by mail-we0-f175.google.com with SMTP id x8so1077925wey.20
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 04:01:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=naFwZTnr/WoE6nO3OjCgjs4EhEai4emThmZLHoORw9I=;
	b=GAznToIrScW3lif+CksS2ZUPKlhLGcA0jz7Eq9cloI7DOtuI3VGrIKgWRj3n02v9Qm
	ltsuvaZNVpVWA12zQyE8yItVnS/5gvISl/6XDjQ1gvQXsfLGa5OB/K1E2QfuCMYqVS+4
	JQ1fylMfDgx09Qe+qP55Nri3e7EsDHUfprxK0PZ2IUkZX8WAq4Kl88ZRYVwUZ8lwykn7
	ND5ffVnEwZvzv29UknbtfC5UDrGX/YvTOQ38SbGVE2qGp/BmauQSLVo3CV9xepUHLI04
	iclwuNariebG9ngqPinPecLJWxo9kEK5hvWg1+Ay/VsOUdvtMxQSkmdRMBPtSwmMPEOE
	GN0g==
MIME-Version: 1.0
X-Received: by 10.194.19.10 with SMTP id a10mr49134808wje.45.1360152115521;
	Wed, 06 Feb 2013 04:01:55 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Wed, 6 Feb 2013 04:01:55 -0800 (PST)
In-Reply-To: <CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
	<CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
Date: Wed, 6 Feb 2013 13:01:55 +0100
Message-ID: <CAN-nQwhjdS3bVLfGYTawM08_B=80a3xGTeFTbSF2TrEE=aumdg@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============4336674204630531010=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4336674204630531010==
Content-Type: multipart/alternative; boundary=047d7b5d4808afaa1404d50d1720

--047d7b5d4808afaa1404d50d1720
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As I read on IBM paper :

When a non-maskable interrupt (NMI) signal is received, the processor
immediately drops what it was doing and attends to it. The NMI signal is
normally used only for critical problem situations, such as serious
hardware errors This setting is Enabled by default. When an NMI is issued
by a critical event the BMC performs the system to reset for recovering the
system. The BMC logs the reboot and additional error events in the SEL.

I dont know why XEN trigger or cause this NMI signal, since when I boot the
machine with the same Operating system Ubuntu 12.04.1 Desktop 64 bit
without XEN its run perfectly. One more interesting fact with the same Dom0
with excacly the same XEN version and configuration running perfectly on my
notebook Toshiba Satelite L735 Intel I5, Hopefully anyone have solution for
the server.

Agya

On Wed, Feb 6, 2013 at 12:48 PM, agya naila <agya.naila@gmail.com> wrote:

> Thank you Pasi to forward this email for me too, it seem not only me
> facing this problem. I found this guy also found similar problem, its in
> french but we can translate it easily using google
> http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot=
-td1230690.html
>
> I found parameter nmi=3Dignore | dom0 | fatal
>
> nmi=3Dreaction : Enables you to specify how the hypervisor reacts to a no=
n -
> maskable interrupt
> (NMI) resulting from a parity or I/O error. Possible values for reaction
> are fatal (the hypervisor
> prints a diagnostic message and then hangs), dom0 (send a message to
> domain0 for logging
> purposes but continue), and ignore (ignore the error). If you do not
> specify this option, Xen
> uses the default value dom0 internally.
>
> But its still doesn't work on my machine.
>
> Agya
>
>
> On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote=
:
>
>> On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
>> > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<pasik@iki.fi> wrote:
>> > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 blade
>> with
>> > > Xen 4.2.1
>> > > with Linux 3.4.28 dom0 kernel.
>> > >
>> > > Does this ring anyone's bells?
>> > >
>> > >
>> > > serial console log of the crash
>> >
>> > Which doesn't even include the message in the subject afaics, so I
>> > don't even know what you're talking about. And the other, earlier
>> > report has no useful information either.
>> >
>> > From an abstract perspective, a front panel NMI to me would mean
>> > someone pressed an NMI button on the system's front panel. You
>> > don't think Xen can do anything about this, do you? And even if
>> > the NMI has another origin, it's still a hardware generated event
>> > that Xen has no control over.
>> >
>>
>> Arrfab said Xen crashes and reboots in the middle of the boot process,
>> and the blade chassis management logs the NMI error. The user is not
>> pressing (NMI) buttons.
>>
>> The serial log included is everything he gets. No error visible in the
>> serial log,
>> only a crash/reboot without any errors.. No idea what could be causing
>> that..
>>
>> The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.
>>
>> Do you have any Xen and/or dom0 kernel options to use to do further
>> analysis?
>>
>> -- Pasi
>>
>>
>

--047d7b5d4808afaa1404d50d1720
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As I read on IBM paper :<div><br></div><div><div>When a non-maskable interr=
upt (NMI) signal is received, the processor immediately drops what it was d=
oing and attends to it. The NMI signal is normally used only for critical p=
roblem situations, such as serious hardware errors This setting is Enabled =
by default. When an NMI is issued by a critical event the BMC performs the =
system to reset for recovering the system. The BMC logs the reboot and addi=
tional error events in the SEL.</div>
<div><br></div><div>I dont know why XEN trigger or cause this NMI signal, s=
ince when I boot the machine with the same Operating system Ubuntu 12.04.1 =
Desktop 64 bit without XEN its run perfectly. One more interesting fact wit=
h the same Dom0 with excacly the same XEN version and configuration running=
 perfectly on my notebook Toshiba Satelite L735 Intel I5, Hopefully anyone =
have solution for the server.</div>
<div><br></div><div>Agya</div><br><div class=3D"gmail_quote">On Wed, Feb 6,=
 2013 at 12:48 PM, agya naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.=
naila@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Thank you Pasi to forward this email for me =
too, it seem not only me facing this problem. I found this guy also found s=
imilar problem, its in french but we can translate it easily using google=
=A0<a href=3D"http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-6=
4bits-reboot-td1230690.html" target=3D"_blank">http://debian.2.n7.nabble.co=
m/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html</a><div>

<br></div><div>I found parameter nmi=3Dignore | dom0 | fatal=A0</div><div><=
br></div><div><div>nmi=3Dreaction : Enables you to specify how the hypervis=
or reacts to a non - maskable interrupt</div><div>(NMI) resulting from a pa=
rity or I/O error. Possible values for reaction are fatal (the hypervisor</=
div>

<div>prints a diagnostic message and then hangs), dom0 (send a message to d=
omain0 for logging</div><div>purposes but continue), and ignore (ignore the=
 error). If you do not specify this option, Xen</div><div>uses the default =
value dom0 internally.</div>

<div><br></div>But its still doesn&#39;t work on my machine.</div><span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Agya</div></font>=
</span><div class=3D"HOEnZb"><div class=3D"h5"><div><br></div><div><br><div=
 class=3D"gmail_quote">
On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;=
<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt;</spa=
n> 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 Wed, Feb 06, 2013 at 07:58:56AM=
 +0000, Jan Beulich wrote:<br>
&gt; &gt;&gt;&gt; On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen&lt;<a href=3D"m=
ailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote:<br>
&gt; &gt; Arrfab (CC&#39;d) is actually seeing a similar problem on IBM HS2=
0 blade with<br>
&gt; &gt; Xen 4.2.1<br>
&gt; &gt; with Linux 3.4.28 dom0 kernel.<br>
&gt; &gt;<br>
&gt; &gt; Does this ring anyone&#39;s bells?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; serial console log of the crash<br>
&gt;<br>
&gt; Which doesn&#39;t even include the message in the subject afaics, so I=
<br>
&gt; don&#39;t even know what you&#39;re talking about. And the other, earl=
ier<br>
&gt; report has no useful information either.<br>
&gt;<br>
&gt; From an abstract perspective, a front panel NMI to me would mean<br>
&gt; someone pressed an NMI button on the system&#39;s front panel. You<br>
&gt; don&#39;t think Xen can do anything about this, do you? And even if<br=
>
&gt; the NMI has another origin, it&#39;s still a hardware generated event<=
br>
&gt; that Xen has no control over.<br>
&gt;<br>
<br>
</div></div>Arrfab said Xen crashes and reboots in the middle of the boot p=
rocess,<br>
and the blade chassis management logs the NMI error. The user is not pressi=
ng (NMI) buttons.<br>
<br>
The serial log included is everything he gets. No error visible in the seri=
al log,<br>
only a crash/reboot without any errors.. No idea what could be causing that=
..<br>
<br>
The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xen.<br>
<br>
Do you have any Xen and/or dom0 kernel options to use to do further analysi=
s?<br>
<span><font color=3D"#888888"><br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--047d7b5d4808afaa1404d50d1720--


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

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

--===============4336674204630531010==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 12:53:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 12:53: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 1U34UW-0000t0-6i; Wed, 06 Feb 2013 12:52:44 +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 1U34UU-0000sr-JD
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 12:52:42 +0000
Received: from [85.158.139.83:52593] by server-1.bemta-5.messagelabs.com id
	DB/E1-29263-91252115; Wed, 06 Feb 2013 12:52:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360155160!27113770!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17231 invoked from network); 6 Feb 2013 12:52:40 -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; 6 Feb 2013 12:52:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 12:52:39 +0000
Message-Id: <5112602602000078000BC725@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 12:52:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
In-Reply-To: <364251457.20130206122422@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Hmm with the patch it does boot, but disables the I/O virtualization.

Good. While, as said before, I still don't understand why it didn't
crash earlier without that patch, I'm glad it's fixed. Will post the
patch for inclusion momentarily.

> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
> without the debug patch (where it does crash) ?

And you can't expect much else with broken ACPI tables:

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
(XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

This is a HPET entry.

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
(XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

so the IOMMU table is lacking an entry for the first IO-APIC, and
without that we can't set up per-device interrupt remapping (in
which case we choose to disable the IOMMU altogether, albeit it
had been questioned whether that isn't making a bad situation
worse in some cases).

If you want the IOMMU back (at the price of re-opening the
security issue described in XSA-36), you'd have to pass
"iommu=amd-iommu-perdev-intremap" to the hypervisor.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 12:53:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 12:53: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 1U34UW-0000t0-6i; Wed, 06 Feb 2013 12:52:44 +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 1U34UU-0000sr-JD
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 12:52:42 +0000
Received: from [85.158.139.83:52593] by server-1.bemta-5.messagelabs.com id
	DB/E1-29263-91252115; Wed, 06 Feb 2013 12:52:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360155160!27113770!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17231 invoked from network); 6 Feb 2013 12:52:40 -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; 6 Feb 2013 12:52:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 12:52:39 +0000
Message-Id: <5112602602000078000BC725@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 12:52:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
In-Reply-To: <364251457.20130206122422@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Hmm with the patch it does boot, but disables the I/O virtualization.

Good. While, as said before, I still don't understand why it didn't
crash earlier without that patch, I'm glad it's fixed. Will post the
patch for inclusion momentarily.

> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
> without the debug patch (where it does crash) ?

And you can't expect much else with broken ACPI tables:

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
(XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

This is a HPET entry.

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
(XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

so the IOMMU table is lacking an entry for the first IO-APIC, and
without that we can't set up per-device interrupt remapping (in
which case we choose to disable the IOMMU altogether, albeit it
had been questioned whether that isn't making a bad situation
worse in some cases).

If you want the IOMMU back (at the price of re-opening the
security issue described in XSA-36), you'd have to pass
"iommu=amd-iommu-perdev-intremap" to the hypervisor.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:04: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 1U34fx-0001R8-Ed; Wed, 06 Feb 2013 13:04:33 +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 1U34fw-0001R3-I1
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:04:32 +0000
Received: from [85.158.138.51:10344] by server-12.bemta-3.messagelabs.com id
	AE/FD-05889-FD452115; Wed, 06 Feb 2013 13:04:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360155860!23129916!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4340 invoked from network); 6 Feb 2013 13:04:20 -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; 6 Feb 2013 13:04:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 13:04:19 +0000
Message-Id: <511262E302000078000BC738@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 13:04:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 regression was reported on a class of broken firmware that c/s
26517:601139e2b0db didn't consider, leading to a boot time crash.

Further, the phantom function support committed earlier is still
lacking AMD side code (during the composition of which the
security issue was noticed, and hence the patch had to be held
back.

1: also spot missing IO-APIC entries in IVRS table
2: handle MSI for phantom functions

Signed-off-by: Jan Beulich <jbeulich@suse.com>


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:04: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 1U34fx-0001R8-Ed; Wed, 06 Feb 2013 13:04:33 +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 1U34fw-0001R3-I1
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:04:32 +0000
Received: from [85.158.138.51:10344] by server-12.bemta-3.messagelabs.com id
	AE/FD-05889-FD452115; Wed, 06 Feb 2013 13:04:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360155860!23129916!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4340 invoked from network); 6 Feb 2013 13:04:20 -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; 6 Feb 2013 13:04:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 13:04:19 +0000
Message-Id: <511262E302000078000BC738@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 13:04:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 regression was reported on a class of broken firmware that c/s
26517:601139e2b0db didn't consider, leading to a boot time crash.

Further, the phantom function support committed earlier is still
lacking AMD side code (during the composition of which the
security issue was noticed, and hence the patch had to be held
back.

1: also spot missing IO-APIC entries in IVRS table
2: handle MSI for phantom functions

Signed-off-by: Jan Beulich <jbeulich@suse.com>


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:12:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:12: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 1U34nM-0002Fl-2p; Wed, 06 Feb 2013 13:12: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 1U34nK-0002FD-Se
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:12:11 +0000
Received: from [85.158.143.35:16480] by server-2.bemta-4.messagelabs.com id
	BD/3C-01597-AA652115; Wed, 06 Feb 2013 13:12:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360156327!13925928!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2841 invoked from network); 6 Feb 2013 13:12:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 13:12:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 13:12:06 +0000
Message-Id: <511264B402000078000BC754@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 13:12:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC9F987B4.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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>
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.

--=__PartC9F987B4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Apart from dealing duplicate conflicting entries, we also have to
handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
so has resulted in c/s 26517:601139e2b0db to crash such systems during
boot (whereas with the change here the IOMMU gets disabled just as is
being done in the other cases, i.e. unless global tables are being
used).

Debugging this issue has also pointed out that the debug log output is
pretty ugly to look at - consolidate the output, and add one extra
item for the IVHD special entries, so that future issues are easier
to analyze.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -354,9 +354,8 @@ static int __init parse_ivmd_block(const
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
-    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
-    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
-    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
+    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
+                    ivmd_block->header.type, start_addr, mem_length);
=20
     if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
@@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
-    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias %#x\n",
+                    first_bdf, last_bdf, alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
         add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
@@ -654,6 +653,9 @@ static u16 __init parse_ivhd_device_spec
         return 0;
     }
=20
+    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle =
%#x\n",
+                    seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
+                    special->variety, special->handle);
     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);
=20
     switch ( special->variety )
@@ -758,10 +760,9 @@ static int __init parse_ivhd_block(const
     {
         ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
-        AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
-        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
-        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting)=
;
+        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags %#x\n",
+                        ivhd_device->header.type, ivhd_device->header.id,
+                        ivhd_device->header.data_setting);
=20
         switch ( ivhd_device->header.type )
         {
@@ -890,6 +891,7 @@ static int __init parse_ivrs_table(struc
 {
     const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
+    unsigned int apic;
     int error =3D 0;
=20
     BUG_ON(!table);
@@ -903,11 +905,9 @@ static int __init parse_ivrs_table(struc
     {
         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
-        AMD_IOMMU_DEBUG("IVRS Block:\n");
-        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
-        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
-        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
+        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id =
%#x\n",
+                        ivrs_block->type, ivrs_block->flags,
+                        ivrs_block->length, ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
@@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc
         length +=3D ivrs_block->length;
     }
=20
+    /* Each IO-APIC must have been mentioned in the table. */
+    for ( apic =3D 0; !error && apic < nr_ioapics; ++apic )
+    {
+        if ( !nr_ioapic_entries[apic] ||
+             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
+            continue;
+
+        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
+               IO_APIC_ID(apic));
+        if ( amd_iommu_perdev_intremap )
+            error =3D -ENXIO;
+        else
+        {
+            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =3D xzalloc_array(
+                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
+            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
+            {
+                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
+                error =3D -ENOMEM;
+            }
+        }
+    }
+
     return error;
 }
=20



--=__PartC9F987B4.1__=
Content-Type: text/plain; name="AMD-IOMMU-IVHD-special-missing.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-IVHD-special-missing.patch"

AMD IOMMU: also spot missing IO-APIC entries in IVRS table=0A=0AApart from =
dealing duplicate conflicting entries, we also have to=0Ahandle firmware =
omitting IO-APIC entries in IVRS altogether. Not doing=0Aso has resulted =
in c/s 26517:601139e2b0db to crash such systems during=0Aboot (whereas =
with the change here the IOMMU gets disabled just as is=0Abeing done in =
the other cases, i.e. unless global tables are being=0Aused).=0A=0ADebuggin=
g this issue has also pointed out that the debug log output is=0Apretty =
ugly to look at - consolidate the output, and add one extra=0Aitem for the =
IVHD special entries, so that future issues are easier=0Ato analyze.=0A=0AS=
igned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: Sander =
Eikelenboom <linux@eikelenboom.it>=0A=0A--- a/xen/drivers/passthrough/amd/i=
ommu_acpi.c=0A+++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -354,9 =
+354,8 @@ static int __init parse_ivmd_block(const=0A     base =3D =
start_addr & PAGE_MASK;=0A     limit =3D (start_addr + mem_length - 1) & =
PAGE_MASK;=0A =0A-    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->=
header.type);=0A-    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr)=
;=0A-    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);=0A+    =
AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",=0A+           =
         ivmd_block->header.type, start_addr, mem_length);=0A =0A     if ( =
ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A         iw =3D =
ir =3D IOMMU_CONTROL_ENABLED;=0A@@ -551,8 +550,8 @@ static u16 __init =
parse_ivhd_device_alia=0A         return 0;=0A     }=0A =0A-    AMD_IOMMU_D=
EBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);=0A-    AMD_IOMMU_=
DEBUG(" Dev_Id Alias: %#x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(" Dev_Id =
Range: %#x -> %#x alias %#x\n",=0A+                    first_bdf, =
last_bdf, alias_id);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D =
last_bdf; bdf++ )=0A         add_ivrs_mapping_entry(bdf, alias_id, =
range->alias.header.data_setting,=0A@@ -654,6 +653,9 @@ static u16 __init =
parse_ivhd_device_spec=0A         return 0;=0A     }=0A =0A+    AMD_IOMMU_D=
EBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle %#x\n",=0A+       =
             seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),=0A+          =
          special->variety, special->handle);=0A     add_ivrs_mapping_entry=
(bdf, bdf, special->header.data_setting, iommu);=0A =0A     switch ( =
special->variety )=0A@@ -758,10 +760,9 @@ static int __init parse_ivhd_bloc=
k(const=0A     {=0A         ivhd_device =3D (const void *)((const u8 =
*)ivhd_block + block_length);=0A =0A-        AMD_IOMMU_DEBUG( "IVHD Device =
Entry:\n");=0A-        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.=
type);=0A-        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id)=
;=0A-        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_sett=
ing);=0A+        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags =
%#x\n",=0A+                        ivhd_device->header.type, ivhd_device->h=
eader.id,=0A+                        ivhd_device->header.data_setting);=0A =
=0A         switch ( ivhd_device->header.type )=0A         {=0A@@ -890,6 =
+891,7 @@ static int __init parse_ivrs_table(struc=0A {=0A     const =
struct acpi_ivrs_header *ivrs_block;=0A     unsigned long length;=0A+    =
unsigned int apic;=0A     int error =3D 0;=0A =0A     BUG_ON(!table);=0A@@ =
-903,11 +905,9 @@ static int __init parse_ivrs_table(struc=0A     {=0A     =
    ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);=0A =
=0A-        AMD_IOMMU_DEBUG("IVRS Block:\n");=0A-        AMD_IOMMU_DEBUG(" =
Type %#x\n", ivrs_block->type);=0A-        AMD_IOMMU_DEBUG(" Flags %#x\n", =
ivrs_block->flags);=0A-        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block-=
>length);=0A-        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id=
);=0A+        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id =
%#x\n",=0A+                        ivrs_block->type, ivrs_block->flags,=0A+=
                        ivrs_block->length, ivrs_block->device_id);=0A =0A =
        if ( table->length < (length + ivrs_block->length) )=0A         =
{=0A@@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc=0A       =
  length +=3D ivrs_block->length;=0A     }=0A =0A+    /* Each IO-APIC must =
have been mentioned in the table. */=0A+    for ( apic =3D 0; !error && =
apic < nr_ioapics; ++apic )=0A+    {=0A+        if ( !nr_ioapic_entries[api=
c] ||=0A+             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )=0A+        =
    continue;=0A+=0A+        printk(XENLOG_ERR "IVHD Error: no information =
for IO-APIC %#x\n",=0A+               IO_APIC_ID(apic));=0A+        if ( =
amd_iommu_perdev_intremap )=0A+            error =3D -ENXIO;=0A+        =
else=0A+        {=0A+            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =
=3D xzalloc_array(=0A+                unsigned long, BITS_TO_LONGS(nr_ioapi=
c_entries[apic]));=0A+            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_s=
etup )=0A+            {=0A+                printk(XENLOG_ERR "IVHD Error: =
Out of memory\n");=0A+                error =3D -ENOMEM;=0A+            =
}=0A+        }=0A+    }=0A+=0A     return error;=0A }=0A =0A
--=__PartC9F987B4.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

--=__PartC9F987B4.1__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 13:12:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:12: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 1U34nM-0002Fl-2p; Wed, 06 Feb 2013 13:12: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 1U34nK-0002FD-Se
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:12:11 +0000
Received: from [85.158.143.35:16480] by server-2.bemta-4.messagelabs.com id
	BD/3C-01597-AA652115; Wed, 06 Feb 2013 13:12:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360156327!13925928!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2841 invoked from network); 6 Feb 2013 13:12:08 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 13:12:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 13:12:06 +0000
Message-Id: <511264B402000078000BC754@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 13:12:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC9F987B4.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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>
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.

--=__PartC9F987B4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Apart from dealing duplicate conflicting entries, we also have to
handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
so has resulted in c/s 26517:601139e2b0db to crash such systems during
boot (whereas with the change here the IOMMU gets disabled just as is
being done in the other cases, i.e. unless global tables are being
used).

Debugging this issue has also pointed out that the debug log output is
pretty ugly to look at - consolidate the output, and add one extra
item for the IVHD special entries, so that future issues are easier
to analyze.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -354,9 +354,8 @@ static int __init parse_ivmd_block(const
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
-    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
-    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
-    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
+    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
+                    ivmd_block->header.type, start_addr, mem_length);
=20
     if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
@@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
-    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias %#x\n",
+                    first_bdf, last_bdf, alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
         add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
@@ -654,6 +653,9 @@ static u16 __init parse_ivhd_device_spec
         return 0;
     }
=20
+    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle =
%#x\n",
+                    seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
+                    special->variety, special->handle);
     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, =
iommu);
=20
     switch ( special->variety )
@@ -758,10 +760,9 @@ static int __init parse_ivhd_block(const
     {
         ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
-        AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
-        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
-        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting)=
;
+        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags %#x\n",
+                        ivhd_device->header.type, ivhd_device->header.id,
+                        ivhd_device->header.data_setting);
=20
         switch ( ivhd_device->header.type )
         {
@@ -890,6 +891,7 @@ static int __init parse_ivrs_table(struc
 {
     const struct acpi_ivrs_header *ivrs_block;
     unsigned long length;
+    unsigned int apic;
     int error =3D 0;
=20
     BUG_ON(!table);
@@ -903,11 +905,9 @@ static int __init parse_ivrs_table(struc
     {
         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
-        AMD_IOMMU_DEBUG("IVRS Block:\n");
-        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
-        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
-        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
+        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id =
%#x\n",
+                        ivrs_block->type, ivrs_block->flags,
+                        ivrs_block->length, ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
@@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc
         length +=3D ivrs_block->length;
     }
=20
+    /* Each IO-APIC must have been mentioned in the table. */
+    for ( apic =3D 0; !error && apic < nr_ioapics; ++apic )
+    {
+        if ( !nr_ioapic_entries[apic] ||
+             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
+            continue;
+
+        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
+               IO_APIC_ID(apic));
+        if ( amd_iommu_perdev_intremap )
+            error =3D -ENXIO;
+        else
+        {
+            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =3D xzalloc_array(
+                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
+            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
+            {
+                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
+                error =3D -ENOMEM;
+            }
+        }
+    }
+
     return error;
 }
=20



--=__PartC9F987B4.1__=
Content-Type: text/plain; name="AMD-IOMMU-IVHD-special-missing.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-IVHD-special-missing.patch"

AMD IOMMU: also spot missing IO-APIC entries in IVRS table=0A=0AApart from =
dealing duplicate conflicting entries, we also have to=0Ahandle firmware =
omitting IO-APIC entries in IVRS altogether. Not doing=0Aso has resulted =
in c/s 26517:601139e2b0db to crash such systems during=0Aboot (whereas =
with the change here the IOMMU gets disabled just as is=0Abeing done in =
the other cases, i.e. unless global tables are being=0Aused).=0A=0ADebuggin=
g this issue has also pointed out that the debug log output is=0Apretty =
ugly to look at - consolidate the output, and add one extra=0Aitem for the =
IVHD special entries, so that future issues are easier=0Ato analyze.=0A=0AS=
igned-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: Sander =
Eikelenboom <linux@eikelenboom.it>=0A=0A--- a/xen/drivers/passthrough/amd/i=
ommu_acpi.c=0A+++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -354,9 =
+354,8 @@ static int __init parse_ivmd_block(const=0A     base =3D =
start_addr & PAGE_MASK;=0A     limit =3D (start_addr + mem_length - 1) & =
PAGE_MASK;=0A =0A-    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->=
header.type);=0A-    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr)=
;=0A-    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);=0A+    =
AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",=0A+           =
         ivmd_block->header.type, start_addr, mem_length);=0A =0A     if ( =
ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A         iw =3D =
ir =3D IOMMU_CONTROL_ENABLED;=0A@@ -551,8 +550,8 @@ static u16 __init =
parse_ivhd_device_alia=0A         return 0;=0A     }=0A =0A-    AMD_IOMMU_D=
EBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);=0A-    AMD_IOMMU_=
DEBUG(" Dev_Id Alias: %#x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(" Dev_Id =
Range: %#x -> %#x alias %#x\n",=0A+                    first_bdf, =
last_bdf, alias_id);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D =
last_bdf; bdf++ )=0A         add_ivrs_mapping_entry(bdf, alias_id, =
range->alias.header.data_setting,=0A@@ -654,6 +653,9 @@ static u16 __init =
parse_ivhd_device_spec=0A         return 0;=0A     }=0A =0A+    AMD_IOMMU_D=
EBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle %#x\n",=0A+       =
             seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),=0A+          =
          special->variety, special->handle);=0A     add_ivrs_mapping_entry=
(bdf, bdf, special->header.data_setting, iommu);=0A =0A     switch ( =
special->variety )=0A@@ -758,10 +760,9 @@ static int __init parse_ivhd_bloc=
k(const=0A     {=0A         ivhd_device =3D (const void *)((const u8 =
*)ivhd_block + block_length);=0A =0A-        AMD_IOMMU_DEBUG( "IVHD Device =
Entry:\n");=0A-        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.=
type);=0A-        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id)=
;=0A-        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_sett=
ing);=0A+        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags =
%#x\n",=0A+                        ivhd_device->header.type, ivhd_device->h=
eader.id,=0A+                        ivhd_device->header.data_setting);=0A =
=0A         switch ( ivhd_device->header.type )=0A         {=0A@@ -890,6 =
+891,7 @@ static int __init parse_ivrs_table(struc=0A {=0A     const =
struct acpi_ivrs_header *ivrs_block;=0A     unsigned long length;=0A+    =
unsigned int apic;=0A     int error =3D 0;=0A =0A     BUG_ON(!table);=0A@@ =
-903,11 +905,9 @@ static int __init parse_ivrs_table(struc=0A     {=0A     =
    ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);=0A =
=0A-        AMD_IOMMU_DEBUG("IVRS Block:\n");=0A-        AMD_IOMMU_DEBUG(" =
Type %#x\n", ivrs_block->type);=0A-        AMD_IOMMU_DEBUG(" Flags %#x\n", =
ivrs_block->flags);=0A-        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block-=
>length);=0A-        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id=
);=0A+        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id =
%#x\n",=0A+                        ivrs_block->type, ivrs_block->flags,=0A+=
                        ivrs_block->length, ivrs_block->device_id);=0A =0A =
        if ( table->length < (length + ivrs_block->length) )=0A         =
{=0A@@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc=0A       =
  length +=3D ivrs_block->length;=0A     }=0A =0A+    /* Each IO-APIC must =
have been mentioned in the table. */=0A+    for ( apic =3D 0; !error && =
apic < nr_ioapics; ++apic )=0A+    {=0A+        if ( !nr_ioapic_entries[api=
c] ||=0A+             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )=0A+        =
    continue;=0A+=0A+        printk(XENLOG_ERR "IVHD Error: no information =
for IO-APIC %#x\n",=0A+               IO_APIC_ID(apic));=0A+        if ( =
amd_iommu_perdev_intremap )=0A+            error =3D -ENXIO;=0A+        =
else=0A+        {=0A+            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =
=3D xzalloc_array(=0A+                unsigned long, BITS_TO_LONGS(nr_ioapi=
c_entries[apic]));=0A+            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_s=
etup )=0A+            {=0A+                printk(XENLOG_ERR "IVHD Error: =
Out of memory\n");=0A+                error =3D -ENOMEM;=0A+            =
}=0A+        }=0A+    }=0A+=0A     return error;=0A }=0A =0A
--=__PartC9F987B4.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

--=__PartC9F987B4.1__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13: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 1U34o8-0002R5-Nv; Wed, 06 Feb 2013 13:13: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 1U34o6-0002QR-I7
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:12:58 +0000
Received: from [85.158.143.35:18354] by server-3.bemta-4.messagelabs.com id
	B6/EC-08920-9D652115; Wed, 06 Feb 2013 13:12:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360156365!5770590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23348 invoked from network); 6 Feb 2013 13:12:54 -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; 6 Feb 2013 13:12:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 13:12:44 +0000
Message-Id: <511264DA02000078000BC758@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 13:12:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA797E9DA.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 2/2] AMD IOMMU: handle MSI for phantom 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>
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.

--=__PartA797E9DA.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With ordinary requests allowed to come from phantom functions, the
remapping tables ought to be set up to also allow for MSI triggers to
come from other than the "real" device too.

It is not clear to me whether the alias-ID handling also needs
adjustment for this to work properly, or whether firmware can be
expected to properly express this through a device alias range
descriptor (or multiple device alias ones).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -286,7 +286,7 @@ void amd_iommu_ioapic_update_ire(
=20
 static void update_intremap_entry_from_msi_msg(
     struct amd_iommu *iommu, u16 bdf,
-    struct msi_desc *msi_desc, struct msi_msg *msg)
+    int *remap_index, const struct msi_msg *msg)
 {
     unsigned long flags;
     u32* entry;
@@ -302,7 +302,7 @@ static void update_intremap_entry_from_m
     {
         lock =3D get_intremap_lock(iommu->seg, req_id);
         spin_lock_irqsave(lock, flags);
-        free_intremap_entry(iommu->seg, req_id, msi_desc->remap_index);
+        free_intremap_entry(iommu->seg, req_id, *remap_index);
         spin_unlock_irqrestore(lock, flags);
=20
         if ( ( req_id !=3D alias_id ) &&
@@ -310,7 +310,7 @@ static void update_intremap_entry_from_m
         {
             lock =3D get_intremap_lock(iommu->seg, alias_id);
             spin_lock_irqsave(lock, flags);
-            free_intremap_entry(iommu->seg, alias_id, msi_desc->remap_inde=
x);
+            free_intremap_entry(iommu->seg, alias_id, *remap_index);
             spin_unlock_irqrestore(lock, flags);
         }
         goto done;
@@ -324,7 +324,10 @@ static void update_intremap_entry_from_m
     vector =3D (msg->data >> MSI_DATA_VECTOR_SHIFT) & MSI_DATA_VECTOR_MASK=
;
     dest =3D (msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
     offset =3D get_intremap_offset(vector, delivery_mode);
-    msi_desc->remap_index =3D offset;
+    if ( *remap_index < 0)
+        *remap_index =3D offset;
+    else
+        BUG_ON(*remap_index !=3D offset);
=20
     entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset);
     update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
@@ -379,12 +382,30 @@ void amd_iommu_msi_msg_update_ire(
     }
=20
     if ( msi_desc->remap_index >=3D 0 )
-        update_intremap_entry_from_msi_msg(iommu, bdf, msi_desc, NULL);
+    {
+        do {
+            update_intremap_entry_from_msi_msg(iommu, bdf,
+                                               &msi_desc->remap_index, =
NULL);
+            if ( !pdev || !pdev->phantom_stride )
+                break;
+            bdf +=3D pdev->phantom_stride;
+        } while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) );
+
+        msi_desc->remap_index =3D -1;
+        if ( pdev )
+            bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
+    }
=20
     if ( !msg )
         return;
=20
-    update_intremap_entry_from_msi_msg(iommu, bdf, msi_desc, msg);
+    do {
+        update_intremap_entry_from_msi_msg(iommu, bdf, &msi_desc->remap_in=
dex,
+                                           msg);
+        if ( !pdev || !pdev->phantom_stride )
+            break;
+        bdf +=3D pdev->phantom_stride;
+    } while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) );
 }
=20
 void amd_iommu_read_msi_from_ire(




--=__PartA797E9DA.1__=
Content-Type: text/plain; name="AMD-IOMMU-phantom-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-phantom-MSI.patch"

AMD IOMMU: handle MSI for phantom functions=0A=0AWith ordinary requests =
allowed to come from phantom functions, the=0Aremapping tables ought to be =
set up to also allow for MSI triggers to=0Acome from other than the "real" =
device too.=0A=0AIt is not clear to me whether the alias-ID handling also =
needs=0Aadjustment for this to work properly, or whether firmware can =
be=0Aexpected to properly express this through a device alias range=0Adescr=
iptor (or multiple device alias ones).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_intr.c=0A+=
++ b/xen/drivers/passthrough/amd/iommu_intr.c=0A@@ -286,7 +286,7 @@ void =
amd_iommu_ioapic_update_ire(=0A =0A static void update_intremap_entry_from_=
msi_msg(=0A     struct amd_iommu *iommu, u16 bdf,=0A-    struct msi_desc =
*msi_desc, struct msi_msg *msg)=0A+    int *remap_index, const struct =
msi_msg *msg)=0A {=0A     unsigned long flags;=0A     u32* entry;=0A@@ =
-302,7 +302,7 @@ static void update_intremap_entry_from_m=0A     {=0A      =
   lock =3D get_intremap_lock(iommu->seg, req_id);=0A         spin_lock_irq=
save(lock, flags);=0A-        free_intremap_entry(iommu->seg, req_id, =
msi_desc->remap_index);=0A+        free_intremap_entry(iommu->seg, req_id, =
*remap_index);=0A         spin_unlock_irqrestore(lock, flags);=0A =0A      =
   if ( ( req_id !=3D alias_id ) &&=0A@@ -310,7 +310,7 @@ static void =
update_intremap_entry_from_m=0A         {=0A             lock =3D =
get_intremap_lock(iommu->seg, alias_id);=0A             spin_lock_irqsave(l=
ock, flags);=0A-            free_intremap_entry(iommu->seg, alias_id, =
msi_desc->remap_index);=0A+            free_intremap_entry(iommu->seg, =
alias_id, *remap_index);=0A             spin_unlock_irqrestore(lock, =
flags);=0A         }=0A         goto done;=0A@@ -324,7 +324,10 @@ static =
void update_intremap_entry_from_m=0A     vector =3D (msg->data >> =
MSI_DATA_VECTOR_SHIFT) & MSI_DATA_VECTOR_MASK;=0A     dest =3D (msg->addres=
s_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;=0A     offset =3D get_intremap_offs=
et(vector, delivery_mode);=0A-    msi_desc->remap_index =3D offset;=0A+    =
if ( *remap_index < 0)=0A+        *remap_index =3D offset;=0A+    else=0A+ =
       BUG_ON(*remap_index !=3D offset);=0A =0A     entry =3D (u32*)get_int=
remap_entry(iommu->seg, req_id, offset);=0A     update_intremap_entry(entry=
, vector, delivery_mode, dest_mode, dest);=0A@@ -379,12 +382,30 @@ void =
amd_iommu_msi_msg_update_ire(=0A     }=0A =0A     if ( msi_desc->remap_inde=
x >=3D 0 )=0A-        update_intremap_entry_from_msi_msg(iommu, bdf, =
msi_desc, NULL);=0A+    {=0A+        do {=0A+            update_intremap_en=
try_from_msi_msg(iommu, bdf,=0A+                                           =
    &msi_desc->remap_index, NULL);=0A+            if ( !pdev || !pdev->phan=
tom_stride )=0A+                break;=0A+            bdf +=3D pdev->phanto=
m_stride;=0A+        } while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) =
);=0A+=0A+        msi_desc->remap_index =3D -1;=0A+        if ( pdev )=0A+ =
           bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);=0A+    }=0A =0A     =
if ( !msg )=0A         return;=0A =0A-    update_intremap_entry_from_msi_ms=
g(iommu, bdf, msi_desc, msg);=0A+    do {=0A+        update_intremap_entry_=
from_msi_msg(iommu, bdf, &msi_desc->remap_index,=0A+                       =
                    msg);=0A+        if ( !pdev || !pdev->phantom_stride =
)=0A+            break;=0A+        bdf +=3D pdev->phantom_stride;=0A+    } =
while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) );=0A }=0A =0A void =
amd_iommu_read_msi_from_ire(=0A
--=__PartA797E9DA.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

--=__PartA797E9DA.1__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13: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 1U34o8-0002R5-Nv; Wed, 06 Feb 2013 13:13: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 1U34o6-0002QR-I7
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:12:58 +0000
Received: from [85.158.143.35:18354] by server-3.bemta-4.messagelabs.com id
	B6/EC-08920-9D652115; Wed, 06 Feb 2013 13:12:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360156365!5770590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23348 invoked from network); 6 Feb 2013 13:12:54 -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; 6 Feb 2013 13:12:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 13:12:44 +0000
Message-Id: <511264DA02000078000BC758@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 13:12:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA797E9DA.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 2/2] AMD IOMMU: handle MSI for phantom 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>
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.

--=__PartA797E9DA.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With ordinary requests allowed to come from phantom functions, the
remapping tables ought to be set up to also allow for MSI triggers to
come from other than the "real" device too.

It is not clear to me whether the alias-ID handling also needs
adjustment for this to work properly, or whether firmware can be
expected to properly express this through a device alias range
descriptor (or multiple device alias ones).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -286,7 +286,7 @@ void amd_iommu_ioapic_update_ire(
=20
 static void update_intremap_entry_from_msi_msg(
     struct amd_iommu *iommu, u16 bdf,
-    struct msi_desc *msi_desc, struct msi_msg *msg)
+    int *remap_index, const struct msi_msg *msg)
 {
     unsigned long flags;
     u32* entry;
@@ -302,7 +302,7 @@ static void update_intremap_entry_from_m
     {
         lock =3D get_intremap_lock(iommu->seg, req_id);
         spin_lock_irqsave(lock, flags);
-        free_intremap_entry(iommu->seg, req_id, msi_desc->remap_index);
+        free_intremap_entry(iommu->seg, req_id, *remap_index);
         spin_unlock_irqrestore(lock, flags);
=20
         if ( ( req_id !=3D alias_id ) &&
@@ -310,7 +310,7 @@ static void update_intremap_entry_from_m
         {
             lock =3D get_intremap_lock(iommu->seg, alias_id);
             spin_lock_irqsave(lock, flags);
-            free_intremap_entry(iommu->seg, alias_id, msi_desc->remap_inde=
x);
+            free_intremap_entry(iommu->seg, alias_id, *remap_index);
             spin_unlock_irqrestore(lock, flags);
         }
         goto done;
@@ -324,7 +324,10 @@ static void update_intremap_entry_from_m
     vector =3D (msg->data >> MSI_DATA_VECTOR_SHIFT) & MSI_DATA_VECTOR_MASK=
;
     dest =3D (msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
     offset =3D get_intremap_offset(vector, delivery_mode);
-    msi_desc->remap_index =3D offset;
+    if ( *remap_index < 0)
+        *remap_index =3D offset;
+    else
+        BUG_ON(*remap_index !=3D offset);
=20
     entry =3D (u32*)get_intremap_entry(iommu->seg, req_id, offset);
     update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
@@ -379,12 +382,30 @@ void amd_iommu_msi_msg_update_ire(
     }
=20
     if ( msi_desc->remap_index >=3D 0 )
-        update_intremap_entry_from_msi_msg(iommu, bdf, msi_desc, NULL);
+    {
+        do {
+            update_intremap_entry_from_msi_msg(iommu, bdf,
+                                               &msi_desc->remap_index, =
NULL);
+            if ( !pdev || !pdev->phantom_stride )
+                break;
+            bdf +=3D pdev->phantom_stride;
+        } while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) );
+
+        msi_desc->remap_index =3D -1;
+        if ( pdev )
+            bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
+    }
=20
     if ( !msg )
         return;
=20
-    update_intremap_entry_from_msi_msg(iommu, bdf, msi_desc, msg);
+    do {
+        update_intremap_entry_from_msi_msg(iommu, bdf, &msi_desc->remap_in=
dex,
+                                           msg);
+        if ( !pdev || !pdev->phantom_stride )
+            break;
+        bdf +=3D pdev->phantom_stride;
+    } while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) );
 }
=20
 void amd_iommu_read_msi_from_ire(




--=__PartA797E9DA.1__=
Content-Type: text/plain; name="AMD-IOMMU-phantom-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-phantom-MSI.patch"

AMD IOMMU: handle MSI for phantom functions=0A=0AWith ordinary requests =
allowed to come from phantom functions, the=0Aremapping tables ought to be =
set up to also allow for MSI triggers to=0Acome from other than the "real" =
device too.=0A=0AIt is not clear to me whether the alias-ID handling also =
needs=0Aadjustment for this to work properly, or whether firmware can =
be=0Aexpected to properly express this through a device alias range=0Adescr=
iptor (or multiple device alias ones).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_intr.c=0A+=
++ b/xen/drivers/passthrough/amd/iommu_intr.c=0A@@ -286,7 +286,7 @@ void =
amd_iommu_ioapic_update_ire(=0A =0A static void update_intremap_entry_from_=
msi_msg(=0A     struct amd_iommu *iommu, u16 bdf,=0A-    struct msi_desc =
*msi_desc, struct msi_msg *msg)=0A+    int *remap_index, const struct =
msi_msg *msg)=0A {=0A     unsigned long flags;=0A     u32* entry;=0A@@ =
-302,7 +302,7 @@ static void update_intremap_entry_from_m=0A     {=0A      =
   lock =3D get_intremap_lock(iommu->seg, req_id);=0A         spin_lock_irq=
save(lock, flags);=0A-        free_intremap_entry(iommu->seg, req_id, =
msi_desc->remap_index);=0A+        free_intremap_entry(iommu->seg, req_id, =
*remap_index);=0A         spin_unlock_irqrestore(lock, flags);=0A =0A      =
   if ( ( req_id !=3D alias_id ) &&=0A@@ -310,7 +310,7 @@ static void =
update_intremap_entry_from_m=0A         {=0A             lock =3D =
get_intremap_lock(iommu->seg, alias_id);=0A             spin_lock_irqsave(l=
ock, flags);=0A-            free_intremap_entry(iommu->seg, alias_id, =
msi_desc->remap_index);=0A+            free_intremap_entry(iommu->seg, =
alias_id, *remap_index);=0A             spin_unlock_irqrestore(lock, =
flags);=0A         }=0A         goto done;=0A@@ -324,7 +324,10 @@ static =
void update_intremap_entry_from_m=0A     vector =3D (msg->data >> =
MSI_DATA_VECTOR_SHIFT) & MSI_DATA_VECTOR_MASK;=0A     dest =3D (msg->addres=
s_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;=0A     offset =3D get_intremap_offs=
et(vector, delivery_mode);=0A-    msi_desc->remap_index =3D offset;=0A+    =
if ( *remap_index < 0)=0A+        *remap_index =3D offset;=0A+    else=0A+ =
       BUG_ON(*remap_index !=3D offset);=0A =0A     entry =3D (u32*)get_int=
remap_entry(iommu->seg, req_id, offset);=0A     update_intremap_entry(entry=
, vector, delivery_mode, dest_mode, dest);=0A@@ -379,12 +382,30 @@ void =
amd_iommu_msi_msg_update_ire(=0A     }=0A =0A     if ( msi_desc->remap_inde=
x >=3D 0 )=0A-        update_intremap_entry_from_msi_msg(iommu, bdf, =
msi_desc, NULL);=0A+    {=0A+        do {=0A+            update_intremap_en=
try_from_msi_msg(iommu, bdf,=0A+                                           =
    &msi_desc->remap_index, NULL);=0A+            if ( !pdev || !pdev->phan=
tom_stride )=0A+                break;=0A+            bdf +=3D pdev->phanto=
m_stride;=0A+        } while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) =
);=0A+=0A+        msi_desc->remap_index =3D -1;=0A+        if ( pdev )=0A+ =
           bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);=0A+    }=0A =0A     =
if ( !msg )=0A         return;=0A =0A-    update_intremap_entry_from_msi_ms=
g(iommu, bdf, msi_desc, msg);=0A+    do {=0A+        update_intremap_entry_=
from_msi_msg(iommu, bdf, &msi_desc->remap_index,=0A+                       =
                    msg);=0A+        if ( !pdev || !pdev->phantom_stride =
)=0A+            break;=0A+        bdf +=3D pdev->phantom_stride;=0A+    } =
while ( PCI_SLOT(bdf) =3D=3D PCI_SLOT(pdev->devfn) );=0A }=0A =0A void =
amd_iommu_read_msi_from_ire(=0A
--=__PartA797E9DA.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

--=__PartA797E9DA.1__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 13:20:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U34vG-00039z-4c; Wed, 06 Feb 2013 13:20:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcrisan@flexiant.com>) id 1U34vE-00039j-WF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:20:21 +0000
Received: from [193.109.254.147:26653] by server-13.bemta-14.messagelabs.com
	id C0/7E-30639-49852115; Wed, 06 Feb 2013 13:20:20 +0000
X-Env-Sender: dcrisan@flexiant.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360156817!1909936!1
X-Originating-IP: [85.119.248.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODUuMTE5LjI0OC41MiA9PiAzOTU3MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8025 invoked from network); 6 Feb 2013 13:20:18 -0000
Received: from smtp003.apm-internet.net (HELO smtp003.apm-internet.net)
	(85.119.248.52)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 13:20:18 -0000
Received: (qmail 57600 invoked from network); 6 Feb 2013 13:20:17 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra002.verygoodemail.com) (85.119.248.210)
	by smtp003.apm-internet.net with SMTP; 6 Feb 2013 13:20:17 -0000
Date: Wed, 6 Feb 2013 13:20:17 +0000 (GMT)
From: Diana Crisan <dcrisan@flexiant.com>
To: xen-devel@lists.xen.org
Message-ID: <18166902.142076.1360156817529.JavaMail.root@zimbra002>
In-Reply-To: <3513156.141519.1360156664225.JavaMail.root@zimbra002>
MIME-Version: 1.0
X-Originating-IP: [109.231.64.198]
X-Mailer: Zimbra 7.1.4_GA_2568 (ZimbraWebClient - GC24 (Linux)/7.1.4_GA_2555)
Subject: [Xen-devel] XEN 4.2 Issuing a shutdown before the ACPI power event
 is triggered puts the vm in a state where it ignores any other shutdown
 commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Steps to replicate:
Using the config file below we create a vm with the xl create command.
Immediately as this returns we issue a shutdown using xl shutdown vm_id, which prints 
"PV control interface not available: external graceful shutdown not possible.
Use "-F" to fallback to ACPI power event.
shutdown failed (rc=-10)"
However, even after the vm boots up properly after this, it cannot be shutdown as it ignores any subsequent xl shutdown commands. We can only issue a kill after this point to destroy the vm.

----------

# The domain build function. HVM domain uses 'hvm'.
builder='hvm'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 512


# A name for your domain. All domains must have different names.
name = "UbuntuXen"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

#-----------------------------------------------------------------------------
# The number of cpus guest platform has, default=1
vcpus=2


disk = [ 'tap:qcow2:/my/nfs/directory/testdisk.qcow2,xvda,w' ]

vif = ['mac=00:16:3e:25:96:c8 , bridge=defaultbr']

device_model_version = 'qemu-xen'
device_model_override = '/usr/lib/xen/bin/qemu-system-i386'
#device_model_override = '/usr/bin/qemu-system-x86_64'
#device_model_args = [ '-monitor', 'tcp:127.0.0.1:2345' ]

sdl=0

#----------------------------------------------------------------------------
# enable OpenGL for texture rendering inside the SDL window, default = 1
# valid only if sdl is enabled.
opengl=1

#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=1

#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from
# auxbin.xen_configdir() + /xend-config.sxp
vnclisten="0.0.0.0"

#----------------------------------------------------------------------------
# set VNC display number, default = domid
vncdisplay=0

#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
vncunused=0

#----------------------------------------------------------------------------
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
vncpasswd='password'


#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0

#-----------------------------------------------------------------------------
#   serial port re-direct to pty deivce, /dev/pts/n
#   then xm console or minicom can connect
serial='pty'

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:20:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U34vG-00039z-4c; Wed, 06 Feb 2013 13:20:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dcrisan@flexiant.com>) id 1U34vE-00039j-WF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:20:21 +0000
Received: from [193.109.254.147:26653] by server-13.bemta-14.messagelabs.com
	id C0/7E-30639-49852115; Wed, 06 Feb 2013 13:20:20 +0000
X-Env-Sender: dcrisan@flexiant.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360156817!1909936!1
X-Originating-IP: [85.119.248.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODUuMTE5LjI0OC41MiA9PiAzOTU3MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8025 invoked from network); 6 Feb 2013 13:20:18 -0000
Received: from smtp003.apm-internet.net (HELO smtp003.apm-internet.net)
	(85.119.248.52)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 13:20:18 -0000
Received: (qmail 57600 invoked from network); 6 Feb 2013 13:20:17 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra002.verygoodemail.com) (85.119.248.210)
	by smtp003.apm-internet.net with SMTP; 6 Feb 2013 13:20:17 -0000
Date: Wed, 6 Feb 2013 13:20:17 +0000 (GMT)
From: Diana Crisan <dcrisan@flexiant.com>
To: xen-devel@lists.xen.org
Message-ID: <18166902.142076.1360156817529.JavaMail.root@zimbra002>
In-Reply-To: <3513156.141519.1360156664225.JavaMail.root@zimbra002>
MIME-Version: 1.0
X-Originating-IP: [109.231.64.198]
X-Mailer: Zimbra 7.1.4_GA_2568 (ZimbraWebClient - GC24 (Linux)/7.1.4_GA_2555)
Subject: [Xen-devel] XEN 4.2 Issuing a shutdown before the ACPI power event
 is triggered puts the vm in a state where it ignores any other shutdown
 commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Steps to replicate:
Using the config file below we create a vm with the xl create command.
Immediately as this returns we issue a shutdown using xl shutdown vm_id, which prints 
"PV control interface not available: external graceful shutdown not possible.
Use "-F" to fallback to ACPI power event.
shutdown failed (rc=-10)"
However, even after the vm boots up properly after this, it cannot be shutdown as it ignores any subsequent xl shutdown commands. We can only issue a kill after this point to destroy the vm.

----------

# The domain build function. HVM domain uses 'hvm'.
builder='hvm'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 512


# A name for your domain. All domains must have different names.
name = "UbuntuXen"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

#-----------------------------------------------------------------------------
# The number of cpus guest platform has, default=1
vcpus=2


disk = [ 'tap:qcow2:/my/nfs/directory/testdisk.qcow2,xvda,w' ]

vif = ['mac=00:16:3e:25:96:c8 , bridge=defaultbr']

device_model_version = 'qemu-xen'
device_model_override = '/usr/lib/xen/bin/qemu-system-i386'
#device_model_override = '/usr/bin/qemu-system-x86_64'
#device_model_args = [ '-monitor', 'tcp:127.0.0.1:2345' ]

sdl=0

#----------------------------------------------------------------------------
# enable OpenGL for texture rendering inside the SDL window, default = 1
# valid only if sdl is enabled.
opengl=1

#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=1

#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from
# auxbin.xen_configdir() + /xend-config.sxp
vnclisten="0.0.0.0"

#----------------------------------------------------------------------------
# set VNC display number, default = domid
vncdisplay=0

#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
vncunused=0

#----------------------------------------------------------------------------
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
vncpasswd='password'


#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0

#-----------------------------------------------------------------------------
#   serial port re-direct to pty deivce, /dev/pts/n
#   then xm console or minicom can connect
serial='pty'

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:28:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:28: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 1U3532-00049N-Ei; Wed, 06 Feb 2013 13:28:24 +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 1U3530-00049A-QX
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:28:23 +0000
Received: from [85.158.143.99:8172] by server-3.bemta-4.messagelabs.com id
	32/03-08920-67A52115; Wed, 06 Feb 2013 13:28:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360157283!24115390!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzIzMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2697 invoked from network); 6 Feb 2013 13:28:13 -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; 6 Feb 2013 13:28:13 -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 02668254B;
	Wed,  6 Feb 2013 15:28:02 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D70662006D; Wed,  6 Feb 2013 15:28:02 +0200 (EET)
Date: Wed, 6 Feb 2013 15:28:02 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130206132802.GU8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
	<CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="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, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrote:
>    Thank you Pasi to forward this email for me too, it seem not only me
>    facing this problem. I found this guy also found similar problem, its =
in
>    french but we can translate it easily using
>    google [1]http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-=
64bits-reboot-td1230690.html
>    I found parameter nmi=3Dignore | dom0 | fatal
>    nmi=3Dreaction : Enables you to specify how the hypervisor reacts to a=
 non -
>    maskable interrupt
>    (NMI) resulting from a parity or I/O error. Possible values for reacti=
on
>    are fatal (the hypervisor
>    prints a diagnostic message and then hangs), dom0 (send a message to
>    domain0 for logging
>    purposes but continue), and ignore (ignore the error). If you do not
>    specify this option, Xen
>    uses the default value dom0 internally.
>    But its still doesn't work on my machine.
>

So you tried adding "nmi=3Dignore" for xen.gz in grub settings and it didn'=
t help? =

Did you try the other possible values? =


-- Pasi

>    Agya
>    On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <[2]pasik@iki.fi>=
 wrote:
> =

>      On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
>      > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<[3]pasik@iki.fi> wro=
te:
>      > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 b=
lade
>      with
>      > > Xen 4.2.1
>      > > with Linux 3.4.28 dom0 kernel.
>      > >
>      > > Does this ring anyone's bells?
>      > >
>      > >
>      > > serial console log of the crash
>      >
>      > Which doesn't even include the message in the subject afaics, so I
>      > don't even know what you're talking about. And the other, earlier
>      > report has no useful information either.
>      >
>      > From an abstract perspective, a front panel NMI to me would mean
>      > someone pressed an NMI button on the system's front panel. You
>      > don't think Xen can do anything about this, do you? And even if
>      > the NMI has another origin, it's still a hardware generated event
>      > that Xen has no control over.
>      >
> =

>      Arrfab said Xen crashes and reboots in the middle of the boot proces=
s,
>      and the blade chassis management logs the NMI error. The user is not
>      pressing (NMI) buttons.
> =

>      The serial log included is everything he gets. No error visible in t=
he
>      serial log,
>      only a crash/reboot without any errors.. No idea what could be causi=
ng
>      that..
> =

>      The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xe=
n.
> =

>      Do you have any Xen and/or dom0 kernel options to use to do further
>      analysis?
>      -- Pasi
> =

> References
> =

>    Visible links
>    1. http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-=
reboot-td1230690.html
>    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 Wed Feb 06 13:28:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:28: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 1U3532-00049N-Ei; Wed, 06 Feb 2013 13:28:24 +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 1U3530-00049A-QX
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:28:23 +0000
Received: from [85.158.143.99:8172] by server-3.bemta-4.messagelabs.com id
	32/03-08920-67A52115; Wed, 06 Feb 2013 13:28:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360157283!24115390!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzIzMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2697 invoked from network); 6 Feb 2013 13:28:13 -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; 6 Feb 2013 13:28:13 -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 02668254B;
	Wed,  6 Feb 2013 15:28:02 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D70662006D; Wed,  6 Feb 2013 15:28:02 +0200 (EET)
Date: Wed, 6 Feb 2013 15:28:02 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130206132802.GU8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
	<CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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="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, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrote:
>    Thank you Pasi to forward this email for me too, it seem not only me
>    facing this problem. I found this guy also found similar problem, its =
in
>    french but we can translate it easily using
>    google [1]http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-=
64bits-reboot-td1230690.html
>    I found parameter nmi=3Dignore | dom0 | fatal
>    nmi=3Dreaction : Enables you to specify how the hypervisor reacts to a=
 non -
>    maskable interrupt
>    (NMI) resulting from a parity or I/O error. Possible values for reacti=
on
>    are fatal (the hypervisor
>    prints a diagnostic message and then hangs), dom0 (send a message to
>    domain0 for logging
>    purposes but continue), and ignore (ignore the error). If you do not
>    specify this option, Xen
>    uses the default value dom0 internally.
>    But its still doesn't work on my machine.
>

So you tried adding "nmi=3Dignore" for xen.gz in grub settings and it didn'=
t help? =

Did you try the other possible values? =


-- Pasi

>    Agya
>    On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <[2]pasik@iki.fi>=
 wrote:
> =

>      On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
>      > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<[3]pasik@iki.fi> wro=
te:
>      > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20 b=
lade
>      with
>      > > Xen 4.2.1
>      > > with Linux 3.4.28 dom0 kernel.
>      > >
>      > > Does this ring anyone's bells?
>      > >
>      > >
>      > > serial console log of the crash
>      >
>      > Which doesn't even include the message in the subject afaics, so I
>      > don't even know what you're talking about. And the other, earlier
>      > report has no useful information either.
>      >
>      > From an abstract perspective, a front panel NMI to me would mean
>      > someone pressed an NMI button on the system's front panel. You
>      > don't think Xen can do anything about this, do you? And even if
>      > the NMI has another origin, it's still a hardware generated event
>      > that Xen has no control over.
>      >
> =

>      Arrfab said Xen crashes and reboots in the middle of the boot proces=
s,
>      and the blade chassis management logs the NMI error. The user is not
>      pressing (NMI) buttons.
> =

>      The serial log included is everything he gets. No error visible in t=
he
>      serial log,
>      only a crash/reboot without any errors.. No idea what could be causi=
ng
>      that..
> =

>      The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without Xe=
n.
> =

>      Do you have any Xen and/or dom0 kernel options to use to do further
>      analysis?
>      -- Pasi
> =

> References
> =

>    Visible links
>    1. http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-=
reboot-td1230690.html
>    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 Wed Feb 06 13:39:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:39: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 1U35Dy-0004uH-Np; Wed, 06 Feb 2013 13:39:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U35Dx-0004uC-6z
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:39:41 +0000
Received: from [85.158.139.83:5328] by server-12.bemta-5.messagelabs.com id
	46/03-20195-C1D52115; Wed, 06 Feb 2013 13:39:40 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360157956!30980946!1
X-Originating-IP: [74.125.82.48]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16137 invoked from network); 6 Feb 2013 13:39:16 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 13:39:16 -0000
Received: by mail-wg0-f48.google.com with SMTP id 16so1080146wgi.27
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 05:39:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=upqrOT9BoxDyNmbWc+lwiB7drVIV20lTcAoWMncv5R4=;
	b=S7B/NGTf1zAguLSgQApy7fbKfBAkFEi1b202G8gzCo9vdpjAW1LDMEwVZdH3fWab2Q
	dAFfflUm0WKfXB5ESUoky2JAQCmJzOMhkYFZEfSlC2/+wRbdkiXZPci+u/cNCFGEviE2
	cyFNJrDEQv1ZPnLchRA/h8eiRZCnjmEo4PKSVdToA6gKjflvcT4HrIy9PkfhQrDvHvH0
	ZD8GhRtD7NPEJ3b0ITHmjh9SqeBKzKypPqokmsvQgaYhuS9W9moQRVy9a2JRa8Tfgwzk
	+HpaWJo/WNWEyGHJoIQqgCx88RXb5aEPFFvo8xP0tAReEAG1R2BAOLgjt6YmbKw9HisH
	5yyw==
MIME-Version: 1.0
X-Received: by 10.194.19.10 with SMTP id a10mr49760317wje.45.1360157955830;
	Wed, 06 Feb 2013 05:39:15 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Wed, 6 Feb 2013 05:39:15 -0800 (PST)
In-Reply-To: <20130206132802.GU8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
	<CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
	<20130206132802.GU8912@reaktio.net>
Date: Wed, 6 Feb 2013 14:39:15 +0100
Message-ID: <CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============5335752564451778481=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5335752564451778481==
Content-Type: multipart/alternative; boundary=047d7b5d4808cbb2ef04d50e7390

--047d7b5d4808cbb2ef04d50e7390
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I configure it by added nmi=3Dignore to my /boot/grub/grub.cfg

### BEGIN /etc/grub.d/20_linux_xen ###
submenu "Xen 4.1-amd64" {
menuentry 'Ubuntu GNU/Linux, with Xen 4.1-amd64 and Linux 3.2.0-29-generic'
--class ubuntu --class gnu-linux --class gnu --c$
        insmod part_msdos
        insmod ext2
        set root=3D'(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=3Droot
730a0f5f-4c35-4391-b760-0b6cf0cdd6a7
        echo    'Loading Xen 4.1-amd64 ...'
        multiboot       /boot/xen-4.1-amd64.gz placeholder noreboot
dom0_mem=3D1024M nmi=3Dignore
        echo    'Loading Linux 3.2.0-29-generic ...'
        module  /boot/vmlinuz-3.2.0-29-generic placeholder
root=3DUUID=3D730a0f5f-4c35-4391-b760-0b6cf0cdd6a7 ro rootdelay=3D180 q$
        echo    'Loading initial ramdisk ...'
        module  /boot/initrd.img-3.2.0-29-generic
}

And its doent work

Agya


On Wed, Feb 6, 2013 at 2:28 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Wed, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrote:
> >    Thank you Pasi to forward this email for me too, it seem not only me
> >    facing this problem. I found this guy also found similar problem, it=
s
> in
> >    french but we can translate it easily using
> >    google [1]
> http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot=
-td1230690.html
> >    I found parameter nmi=3Dignore | dom0 | fatal
> >    nmi=3Dreaction : Enables you to specify how the hypervisor reacts to=
 a
> non -
> >    maskable interrupt
> >    (NMI) resulting from a parity or I/O error. Possible values for
> reaction
> >    are fatal (the hypervisor
> >    prints a diagnostic message and then hangs), dom0 (send a message to
> >    domain0 for logging
> >    purposes but continue), and ignore (ignore the error). If you do not
> >    specify this option, Xen
> >    uses the default value dom0 internally.
> >    But its still doesn't work on my machine.
> >
>
> So you tried adding "nmi=3Dignore" for xen.gz in grub settings and it did=
n't
> help?
> Did you try the other possible values?
>
> -- Pasi
>
> >    Agya
> >    On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <[2]pasik@iki.f=
i>
> wrote:
> >
> >      On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
> >      > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<[3]pasik@iki.fi> w=
rote:
> >      > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20
> blade
> >      with
> >      > > Xen 4.2.1
> >      > > with Linux 3.4.28 dom0 kernel.
> >      > >
> >      > > Does this ring anyone's bells?
> >      > >
> >      > >
> >      > > serial console log of the crash
> >      >
> >      > Which doesn't even include the message in the subject afaics, so=
 I
> >      > don't even know what you're talking about. And the other, earlie=
r
> >      > report has no useful information either.
> >      >
> >      > From an abstract perspective, a front panel NMI to me would mean
> >      > someone pressed an NMI button on the system's front panel. You
> >      > don't think Xen can do anything about this, do you? And even if
> >      > the NMI has another origin, it's still a hardware generated even=
t
> >      > that Xen has no control over.
> >      >
> >
> >      Arrfab said Xen crashes and reboots in the middle of the boot
> process,
> >      and the blade chassis management logs the NMI error. The user is n=
ot
> >      pressing (NMI) buttons.
> >
> >      The serial log included is everything he gets. No error visible in
> the
> >      serial log,
> >      only a crash/reboot without any errors.. No idea what could be
> causing
> >      that..
> >
> >      The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without
> Xen.
> >
> >      Do you have any Xen and/or dom0 kernel options to use to do furthe=
r
> >      analysis?
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1.
> http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot=
-td1230690.html
> >    2. mailto:pasik@iki.fi
> >    3. mailto:pasik@iki.fi
>

--047d7b5d4808cbb2ef04d50e7390
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I configure it by added nmi=3Dignore to my=A0/boot/grub/grub.cfg<div><br></=
div><div><div>### BEGIN /etc/grub.d/20_linux_xen ###</div><div>submenu &quo=
t;Xen 4.1-amd64&quot; {</div><div>menuentry &#39;Ubuntu GNU/Linux, with Xen=
 4.1-amd64 and Linux 3.2.0-29-generic&#39; --class ubuntu --class gnu-linux=
 --class gnu --c$</div>
<div>=A0 =A0 =A0 =A0 insmod part_msdos</div><div>=A0 =A0 =A0 =A0 insmod ext=
2</div><div>=A0 =A0 =A0 =A0 set root=3D&#39;(hd0,msdos1)&#39;</div><div>=A0=
 =A0 =A0 =A0 search --no-floppy --fs-uuid --set=3Droot 730a0f5f-4c35-4391-b=
760-0b6cf0cdd6a7</div><div>=A0 =A0 =A0 =A0 echo =A0 =A0&#39;Loading Xen 4.1=
-amd64 ...&#39;</div>
<div>=A0 =A0 =A0 =A0 multiboot =A0 =A0 =A0 /boot/xen-4.1-amd64.gz placehold=
er noreboot dom0_mem=3D1024M nmi=3Dignore</div><div>=A0 =A0 =A0 =A0 echo =
=A0 =A0&#39;Loading Linux 3.2.0-29-generic ...&#39;</div><div>=A0 =A0 =A0 =
=A0 module =A0/boot/vmlinuz-3.2.0-29-generic placeholder root=3DUUID=3D730a=
0f5f-4c35-4391-b760-0b6cf0cdd6a7 ro rootdelay=3D180 q$</div>
<div>=A0 =A0 =A0 =A0 echo =A0 =A0&#39;Loading initial ramdisk ...&#39;</div=
><div>=A0 =A0 =A0 =A0 module =A0/boot/initrd.img-3.2.0-29-generic</div><div=
>}</div><div><br></div>And its doent work</div><div><br></div><div>Agya</di=
v><div><br></div><div>
<br><div class=3D"gmail_quote">On Wed, Feb 6, 2013 at 2:28 PM, Pasi K=E4rkk=
=E4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_bl=
ank">pasik@iki.fi</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 Wed, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrot=
e:<br>
&gt; =A0 =A0Thank you Pasi to forward this email for me too, it seem not on=
ly me<br>
&gt; =A0 =A0facing this problem. I found this guy also found similar proble=
m, its in<br>
&gt; =A0 =A0french but we can translate it easily using<br>
</div>&gt; =A0 =A0google [1]<a href=3D"http://debian.2.n7.nabble.com/Proble=
me-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html" target=3D"_blank">htt=
p://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td12=
30690.html</a><br>

<div class=3D"im">&gt; =A0 =A0I found parameter nmi=3Dignore | dom0 | fatal=
<br>
&gt; =A0 =A0nmi=3Dreaction : Enables you to specify how the hypervisor reac=
ts to a non -<br>
&gt; =A0 =A0maskable interrupt<br>
&gt; =A0 =A0(NMI) resulting from a parity or I/O error. Possible values for=
 reaction<br>
&gt; =A0 =A0are fatal (the hypervisor<br>
&gt; =A0 =A0prints a diagnostic message and then hangs), dom0 (send a messa=
ge to<br>
&gt; =A0 =A0domain0 for logging<br>
&gt; =A0 =A0purposes but continue), and ignore (ignore the error). If you d=
o not<br>
&gt; =A0 =A0specify this option, Xen<br>
&gt; =A0 =A0uses the default value dom0 internally.<br>
&gt; =A0 =A0But its still doesn&#39;t work on my machine.<br>
&gt;<br>
<br>
</div>So you tried adding &quot;nmi=3Dignore&quot; for xen.gz in grub setti=
ngs and it didn&#39;t help?<br>
Did you try the other possible values?<br>
<br>
-- Pasi<br>
<br>
&gt; =A0 =A0Agya<br>
<div class=3D"im">&gt; =A0 =A0On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=
=E4inen &lt;[2]<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<=
br>
&gt;<br>
&gt; =A0 =A0 =A0On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote=
:<br>
</div><div><div class=3D"h5">&gt; =A0 =A0 =A0&gt; &gt;&gt;&gt; On 05.02.13 =
at 21:08, Pasi K=E4rkk=E4inen&lt;[3]<a href=3D"mailto:pasik@iki.fi">pasik@i=
ki.fi</a>&gt; wrote:<br>
&gt; =A0 =A0 =A0&gt; &gt; Arrfab (CC&#39;d) is actually seeing a similar pr=
oblem on IBM HS20 blade<br>
&gt; =A0 =A0 =A0with<br>
&gt; =A0 =A0 =A0&gt; &gt; Xen 4.2.1<br>
&gt; =A0 =A0 =A0&gt; &gt; with Linux 3.4.28 dom0 kernel.<br>
&gt; =A0 =A0 =A0&gt; &gt;<br>
&gt; =A0 =A0 =A0&gt; &gt; Does this ring anyone&#39;s bells?<br>
&gt; =A0 =A0 =A0&gt; &gt;<br>
&gt; =A0 =A0 =A0&gt; &gt;<br>
&gt; =A0 =A0 =A0&gt; &gt; serial console log of the crash<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; Which doesn&#39;t even include the message in the subj=
ect afaics, so I<br>
&gt; =A0 =A0 =A0&gt; don&#39;t even know what you&#39;re talking about. And=
 the other, earlier<br>
&gt; =A0 =A0 =A0&gt; report has no useful information either.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; From an abstract perspective, a front panel NMI to me =
would mean<br>
&gt; =A0 =A0 =A0&gt; someone pressed an NMI button on the system&#39;s fron=
t panel. You<br>
&gt; =A0 =A0 =A0&gt; don&#39;t think Xen can do anything about this, do you=
? And even if<br>
&gt; =A0 =A0 =A0&gt; the NMI has another origin, it&#39;s still a hardware =
generated event<br>
&gt; =A0 =A0 =A0&gt; that Xen has no control over.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0Arrfab said Xen crashes and reboots in the middle of the bo=
ot process,<br>
&gt; =A0 =A0 =A0and the blade chassis management logs the NMI error. The us=
er is not<br>
&gt; =A0 =A0 =A0pressing (NMI) buttons.<br>
&gt;<br>
&gt; =A0 =A0 =A0The serial log included is everything he gets. No error vis=
ible in the<br>
&gt; =A0 =A0 =A0serial log,<br>
&gt; =A0 =A0 =A0only a crash/reboot without any errors.. No idea what could=
 be causing<br>
&gt; =A0 =A0 =A0that..<br>
&gt;<br>
&gt; =A0 =A0 =A0The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal w=
ithout Xen.<br>
&gt;<br>
&gt; =A0 =A0 =A0Do you have any Xen and/or dom0 kernel options to use to do=
 further<br>
&gt; =A0 =A0 =A0analysis?<br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
</div></div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. <a href=3D"http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-=
et-SQUEEZE-64bits-reboot-td1230690.html" target=3D"_blank">http://debian.2.=
n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html</a=
><br>

&gt; =A0 =A02. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
&gt; =A0 =A03. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
</blockquote></div><br></div>

--047d7b5d4808cbb2ef04d50e7390--


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

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

--===============5335752564451778481==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 13:39:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13:39: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 1U35Dy-0004uH-Np; Wed, 06 Feb 2013 13:39:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U35Dx-0004uC-6z
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:39:41 +0000
Received: from [85.158.139.83:5328] by server-12.bemta-5.messagelabs.com id
	46/03-20195-C1D52115; Wed, 06 Feb 2013 13:39:40 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360157956!30980946!1
X-Originating-IP: [74.125.82.48]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16137 invoked from network); 6 Feb 2013 13:39:16 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 13:39:16 -0000
Received: by mail-wg0-f48.google.com with SMTP id 16so1080146wgi.27
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 05:39:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=upqrOT9BoxDyNmbWc+lwiB7drVIV20lTcAoWMncv5R4=;
	b=S7B/NGTf1zAguLSgQApy7fbKfBAkFEi1b202G8gzCo9vdpjAW1LDMEwVZdH3fWab2Q
	dAFfflUm0WKfXB5ESUoky2JAQCmJzOMhkYFZEfSlC2/+wRbdkiXZPci+u/cNCFGEviE2
	cyFNJrDEQv1ZPnLchRA/h8eiRZCnjmEo4PKSVdToA6gKjflvcT4HrIy9PkfhQrDvHvH0
	ZD8GhRtD7NPEJ3b0ITHmjh9SqeBKzKypPqokmsvQgaYhuS9W9moQRVy9a2JRa8Tfgwzk
	+HpaWJo/WNWEyGHJoIQqgCx88RXb5aEPFFvo8xP0tAReEAG1R2BAOLgjt6YmbKw9HisH
	5yyw==
MIME-Version: 1.0
X-Received: by 10.194.19.10 with SMTP id a10mr49760317wje.45.1360157955830;
	Wed, 06 Feb 2013 05:39:15 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Wed, 6 Feb 2013 05:39:15 -0800 (PST)
In-Reply-To: <20130206132802.GU8912@reaktio.net>
References: <CAN-nQwhBVOmWnZk-a6LZ2+tEa82XAOpxTHfOjEMhGkcNd7zL-A@mail.gmail.com>
	<20130205163021.GR8912@reaktio.net>
	<20130205200847.GS8912@reaktio.net>
	<51121B5002000078000BC573@nat28.tlf.novell.com>
	<20130206112910.GT8912@reaktio.net>
	<CAN-nQwi3uFQq9Uumm+Z94WUJGqtuszJOeLrjVAvRAoZps3PgMw@mail.gmail.com>
	<20130206132802.GU8912@reaktio.net>
Date: Wed, 6 Feb 2013 14:39:15 +0100
Message-ID: <CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: arrfab@centos.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============5335752564451778481=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5335752564451778481==
Content-Type: multipart/alternative; boundary=047d7b5d4808cbb2ef04d50e7390

--047d7b5d4808cbb2ef04d50e7390
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I configure it by added nmi=3Dignore to my /boot/grub/grub.cfg

### BEGIN /etc/grub.d/20_linux_xen ###
submenu "Xen 4.1-amd64" {
menuentry 'Ubuntu GNU/Linux, with Xen 4.1-amd64 and Linux 3.2.0-29-generic'
--class ubuntu --class gnu-linux --class gnu --c$
        insmod part_msdos
        insmod ext2
        set root=3D'(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=3Droot
730a0f5f-4c35-4391-b760-0b6cf0cdd6a7
        echo    'Loading Xen 4.1-amd64 ...'
        multiboot       /boot/xen-4.1-amd64.gz placeholder noreboot
dom0_mem=3D1024M nmi=3Dignore
        echo    'Loading Linux 3.2.0-29-generic ...'
        module  /boot/vmlinuz-3.2.0-29-generic placeholder
root=3DUUID=3D730a0f5f-4c35-4391-b760-0b6cf0cdd6a7 ro rootdelay=3D180 q$
        echo    'Loading initial ramdisk ...'
        module  /boot/initrd.img-3.2.0-29-generic
}

And its doent work

Agya


On Wed, Feb 6, 2013 at 2:28 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Wed, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrote:
> >    Thank you Pasi to forward this email for me too, it seem not only me
> >    facing this problem. I found this guy also found similar problem, it=
s
> in
> >    french but we can translate it easily using
> >    google [1]
> http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot=
-td1230690.html
> >    I found parameter nmi=3Dignore | dom0 | fatal
> >    nmi=3Dreaction : Enables you to specify how the hypervisor reacts to=
 a
> non -
> >    maskable interrupt
> >    (NMI) resulting from a parity or I/O error. Possible values for
> reaction
> >    are fatal (the hypervisor
> >    prints a diagnostic message and then hangs), dom0 (send a message to
> >    domain0 for logging
> >    purposes but continue), and ignore (ignore the error). If you do not
> >    specify this option, Xen
> >    uses the default value dom0 internally.
> >    But its still doesn't work on my machine.
> >
>
> So you tried adding "nmi=3Dignore" for xen.gz in grub settings and it did=
n't
> help?
> Did you try the other possible values?
>
> -- Pasi
>
> >    Agya
> >    On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=E4inen <[2]pasik@iki.f=
i>
> wrote:
> >
> >      On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote:
> >      > >>> On 05.02.13 at 21:08, Pasi K=E4rkk=E4inen<[3]pasik@iki.fi> w=
rote:
> >      > > Arrfab (CC'd) is actually seeing a similar problem on IBM HS20
> blade
> >      with
> >      > > Xen 4.2.1
> >      > > with Linux 3.4.28 dom0 kernel.
> >      > >
> >      > > Does this ring anyone's bells?
> >      > >
> >      > >
> >      > > serial console log of the crash
> >      >
> >      > Which doesn't even include the message in the subject afaics, so=
 I
> >      > don't even know what you're talking about. And the other, earlie=
r
> >      > report has no useful information either.
> >      >
> >      > From an abstract perspective, a front panel NMI to me would mean
> >      > someone pressed an NMI button on the system's front panel. You
> >      > don't think Xen can do anything about this, do you? And even if
> >      > the NMI has another origin, it's still a hardware generated even=
t
> >      > that Xen has no control over.
> >      >
> >
> >      Arrfab said Xen crashes and reboots in the middle of the boot
> process,
> >      and the blade chassis management logs the NMI error. The user is n=
ot
> >      pressing (NMI) buttons.
> >
> >      The serial log included is everything he gets. No error visible in
> the
> >      serial log,
> >      only a crash/reboot without any errors.. No idea what could be
> causing
> >      that..
> >
> >      The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal without
> Xen.
> >
> >      Do you have any Xen and/or dom0 kernel options to use to do furthe=
r
> >      analysis?
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1.
> http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot=
-td1230690.html
> >    2. mailto:pasik@iki.fi
> >    3. mailto:pasik@iki.fi
>

--047d7b5d4808cbb2ef04d50e7390
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I configure it by added nmi=3Dignore to my=A0/boot/grub/grub.cfg<div><br></=
div><div><div>### BEGIN /etc/grub.d/20_linux_xen ###</div><div>submenu &quo=
t;Xen 4.1-amd64&quot; {</div><div>menuentry &#39;Ubuntu GNU/Linux, with Xen=
 4.1-amd64 and Linux 3.2.0-29-generic&#39; --class ubuntu --class gnu-linux=
 --class gnu --c$</div>
<div>=A0 =A0 =A0 =A0 insmod part_msdos</div><div>=A0 =A0 =A0 =A0 insmod ext=
2</div><div>=A0 =A0 =A0 =A0 set root=3D&#39;(hd0,msdos1)&#39;</div><div>=A0=
 =A0 =A0 =A0 search --no-floppy --fs-uuid --set=3Droot 730a0f5f-4c35-4391-b=
760-0b6cf0cdd6a7</div><div>=A0 =A0 =A0 =A0 echo =A0 =A0&#39;Loading Xen 4.1=
-amd64 ...&#39;</div>
<div>=A0 =A0 =A0 =A0 multiboot =A0 =A0 =A0 /boot/xen-4.1-amd64.gz placehold=
er noreboot dom0_mem=3D1024M nmi=3Dignore</div><div>=A0 =A0 =A0 =A0 echo =
=A0 =A0&#39;Loading Linux 3.2.0-29-generic ...&#39;</div><div>=A0 =A0 =A0 =
=A0 module =A0/boot/vmlinuz-3.2.0-29-generic placeholder root=3DUUID=3D730a=
0f5f-4c35-4391-b760-0b6cf0cdd6a7 ro rootdelay=3D180 q$</div>
<div>=A0 =A0 =A0 =A0 echo =A0 =A0&#39;Loading initial ramdisk ...&#39;</div=
><div>=A0 =A0 =A0 =A0 module =A0/boot/initrd.img-3.2.0-29-generic</div><div=
>}</div><div><br></div>And its doent work</div><div><br></div><div>Agya</di=
v><div><br></div><div>
<br><div class=3D"gmail_quote">On Wed, Feb 6, 2013 at 2:28 PM, Pasi K=E4rkk=
=E4inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_bl=
ank">pasik@iki.fi</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 Wed, Feb 06, 2013 at 12:48:50PM +0100, agya naila wrot=
e:<br>
&gt; =A0 =A0Thank you Pasi to forward this email for me too, it seem not on=
ly me<br>
&gt; =A0 =A0facing this problem. I found this guy also found similar proble=
m, its in<br>
&gt; =A0 =A0french but we can translate it easily using<br>
</div>&gt; =A0 =A0google [1]<a href=3D"http://debian.2.n7.nabble.com/Proble=
me-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html" target=3D"_blank">htt=
p://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td12=
30690.html</a><br>

<div class=3D"im">&gt; =A0 =A0I found parameter nmi=3Dignore | dom0 | fatal=
<br>
&gt; =A0 =A0nmi=3Dreaction : Enables you to specify how the hypervisor reac=
ts to a non -<br>
&gt; =A0 =A0maskable interrupt<br>
&gt; =A0 =A0(NMI) resulting from a parity or I/O error. Possible values for=
 reaction<br>
&gt; =A0 =A0are fatal (the hypervisor<br>
&gt; =A0 =A0prints a diagnostic message and then hangs), dom0 (send a messa=
ge to<br>
&gt; =A0 =A0domain0 for logging<br>
&gt; =A0 =A0purposes but continue), and ignore (ignore the error). If you d=
o not<br>
&gt; =A0 =A0specify this option, Xen<br>
&gt; =A0 =A0uses the default value dom0 internally.<br>
&gt; =A0 =A0But its still doesn&#39;t work on my machine.<br>
&gt;<br>
<br>
</div>So you tried adding &quot;nmi=3Dignore&quot; for xen.gz in grub setti=
ngs and it didn&#39;t help?<br>
Did you try the other possible values?<br>
<br>
-- Pasi<br>
<br>
&gt; =A0 =A0Agya<br>
<div class=3D"im">&gt; =A0 =A0On Wed, Feb 6, 2013 at 12:29 PM, Pasi K=E4rkk=
=E4inen &lt;[2]<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<=
br>
&gt;<br>
&gt; =A0 =A0 =A0On Wed, Feb 06, 2013 at 07:58:56AM +0000, Jan Beulich wrote=
:<br>
</div><div><div class=3D"h5">&gt; =A0 =A0 =A0&gt; &gt;&gt;&gt; On 05.02.13 =
at 21:08, Pasi K=E4rkk=E4inen&lt;[3]<a href=3D"mailto:pasik@iki.fi">pasik@i=
ki.fi</a>&gt; wrote:<br>
&gt; =A0 =A0 =A0&gt; &gt; Arrfab (CC&#39;d) is actually seeing a similar pr=
oblem on IBM HS20 blade<br>
&gt; =A0 =A0 =A0with<br>
&gt; =A0 =A0 =A0&gt; &gt; Xen 4.2.1<br>
&gt; =A0 =A0 =A0&gt; &gt; with Linux 3.4.28 dom0 kernel.<br>
&gt; =A0 =A0 =A0&gt; &gt;<br>
&gt; =A0 =A0 =A0&gt; &gt; Does this ring anyone&#39;s bells?<br>
&gt; =A0 =A0 =A0&gt; &gt;<br>
&gt; =A0 =A0 =A0&gt; &gt;<br>
&gt; =A0 =A0 =A0&gt; &gt; serial console log of the crash<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; Which doesn&#39;t even include the message in the subj=
ect afaics, so I<br>
&gt; =A0 =A0 =A0&gt; don&#39;t even know what you&#39;re talking about. And=
 the other, earlier<br>
&gt; =A0 =A0 =A0&gt; report has no useful information either.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt; =A0 =A0 =A0&gt; From an abstract perspective, a front panel NMI to me =
would mean<br>
&gt; =A0 =A0 =A0&gt; someone pressed an NMI button on the system&#39;s fron=
t panel. You<br>
&gt; =A0 =A0 =A0&gt; don&#39;t think Xen can do anything about this, do you=
? And even if<br>
&gt; =A0 =A0 =A0&gt; the NMI has another origin, it&#39;s still a hardware =
generated event<br>
&gt; =A0 =A0 =A0&gt; that Xen has no control over.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0Arrfab said Xen crashes and reboots in the middle of the bo=
ot process,<br>
&gt; =A0 =A0 =A0and the blade chassis management logs the NMI error. The us=
er is not<br>
&gt; =A0 =A0 =A0pressing (NMI) buttons.<br>
&gt;<br>
&gt; =A0 =A0 =A0The serial log included is everything he gets. No error vis=
ible in the<br>
&gt; =A0 =A0 =A0serial log,<br>
&gt; =A0 =A0 =A0only a crash/reboot without any errors.. No idea what could=
 be causing<br>
&gt; =A0 =A0 =A0that..<br>
&gt;<br>
&gt; =A0 =A0 =A0The same Dom0 kernel (pvops 3.4.28) boots OK on baremetal w=
ithout Xen.<br>
&gt;<br>
&gt; =A0 =A0 =A0Do you have any Xen and/or dom0 kernel options to use to do=
 further<br>
&gt; =A0 =A0 =A0analysis?<br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
</div></div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. <a href=3D"http://debian.2.n7.nabble.com/Probleme-XEN-4-0-1-=
et-SQUEEZE-64bits-reboot-td1230690.html" target=3D"_blank">http://debian.2.=
n7.nabble.com/Probleme-XEN-4-0-1-et-SQUEEZE-64bits-reboot-td1230690.html</a=
><br>

&gt; =A0 =A02. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
&gt; =A0 =A03. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
</blockquote></div><br></div>

--047d7b5d4808cbb2ef04d50e7390--


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

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

--===============5335752564451778481==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 13:40:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13: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 1U35E9-0004vJ-AF; Wed, 06 Feb 2013 13:39:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U35E7-0004v5-AU
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 13:39:51 +0000
Received: from [85.158.138.51:43989] by server-12.bemta-3.messagelabs.com id
	E7/D8-05889-62D52115; Wed, 06 Feb 2013 13:39:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360157989!29465347!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13849 invoked from network); 6 Feb 2013 13:39:49 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2013 13:39:49 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:52982 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 1U35KL-0000f6-Jv; Wed, 06 Feb 2013 14:46:17 +0100
Date: Wed, 6 Feb 2013 14:39:46 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <13810303701.20130206143946@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5112602602000078000BC725@nat28.tlf.novell.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, February 6, 2013, 1:52:38 PM, you wrote:

>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm with the patch it does boot, but disables the I/O virtualization.

> Good. While, as said before, I still don't understand why it didn't
> crash earlier without that patch, I'm glad it's fixed. Will post the
> patch for inclusion momentarily.

>> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
>> without the debug patch (where it does crash) ?

> And you can't expect much else with broken ACPI tables:

Hmm yeah it seems anything that has to remotely depend on anything bios related is pretty doomed, on both intel and AMD.
And support/willingness to correct things, is limited, not to say non-existent.

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

> This is a HPET entry.

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

> so the IOMMU table is lacking an entry for the first IO-APIC, and
> without that we can't set up per-device interrupt remapping (in
> which case we choose to disable the IOMMU altogether, albeit it
> had been questioned whether that isn't making a bad situation
> worse in some cases).

> If you want the IOMMU back (at the price of re-opening the
> security issue described in XSA-36), you'd have to pass
> "iommu=amd-iommu-perdev-intremap" to the hypervisor.

Will try some newer bios, although i tried that in the past and it resulted in a non-booting system.
But perhaps things have changed for the better.

Thanks so far !

--
Sander


> Jan




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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:40:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13: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 1U35E9-0004vJ-AF; Wed, 06 Feb 2013 13:39:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U35E7-0004v5-AU
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 13:39:51 +0000
Received: from [85.158.138.51:43989] by server-12.bemta-3.messagelabs.com id
	E7/D8-05889-62D52115; Wed, 06 Feb 2013 13:39:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360157989!29465347!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13849 invoked from network); 6 Feb 2013 13:39:49 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2013 13:39:49 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:52982 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 1U35KL-0000f6-Jv; Wed, 06 Feb 2013 14:46:17 +0100
Date: Wed, 6 Feb 2013 14:39:46 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <13810303701.20130206143946@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5112602602000078000BC725@nat28.tlf.novell.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, February 6, 2013, 1:52:38 PM, you wrote:

>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm with the patch it does boot, but disables the I/O virtualization.

> Good. While, as said before, I still don't understand why it didn't
> crash earlier without that patch, I'm glad it's fixed. Will post the
> patch for inclusion momentarily.

>> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
>> without the debug patch (where it does crash) ?

> And you can't expect much else with broken ACPI tables:

Hmm yeah it seems anything that has to remotely depend on anything bios related is pretty doomed, on both intel and AMD.
And support/willingness to correct things, is limited, not to say non-existent.

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

> This is a HPET entry.

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

> so the IOMMU table is lacking an entry for the first IO-APIC, and
> without that we can't set up per-device interrupt remapping (in
> which case we choose to disable the IOMMU altogether, albeit it
> had been questioned whether that isn't making a bad situation
> worse in some cases).

> If you want the IOMMU back (at the price of re-opening the
> security issue described in XSA-36), you'd have to pass
> "iommu=amd-iommu-perdev-intremap" to the hypervisor.

Will try some newer bios, although i tried that in the past and it resulted in a non-booting system.
But perhaps things have changed for the better.

Thanks so far !

--
Sander


> Jan




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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:55:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13: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 1U35TJ-0005hw-Tr; Wed, 06 Feb 2013 13: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 1U35TI-0005hr-3m
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:55:32 +0000
Received: from [85.158.143.35:54534] by server-1.bemta-4.messagelabs.com id
	C9/3A-08839-3D062115; Wed, 06 Feb 2013 13:55:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360158802!13210159!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29225 invoked from network); 6 Feb 2013 13:53:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 13:53:22 -0000
Received: by mail-we0-f173.google.com with SMTP id r5so1139485wey.18
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 05:53:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=GUWSp/7C4fgvJ/BU29jgk5T0z71eWbCSmdMCkd5WT7k=;
	b=Xo9+kt3mQE5nqe/GtDDaMvIDPQlMkDlC5wGc1eNAvseekgzQQJvAVU+4AHGUsPUDUT
	tWI9K5rGJqbXCvRodWp3nD0UxoAwmvYFCg6EelKzuW4V/09ZWgsgTJlPrd/l9jrAvtNZ
	Ni1moM/L7ksGuTb6PZX91raGxbbP2oyXGTiFHjRfADHBumvQNuswN7qO4ldtRB6c1cXu
	y++fYWRiawpW3DBMlFovX0Ybip+LwQWAeX05pazgB/9pi9yKBvN4cUFQCucSGeZDCuO1
	X0YTxzWXsR1hzu3cLAkQ6czK/VdYd5qbAaYs4CmVOhKjlPaiQ/MKSPRcHb74i2Rs2783
	GLaw==
X-Received: by 10.180.94.234 with SMTP id df10mr5065509wib.17.1360158802377;
	Wed, 06 Feb 2013 05:53:22 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id n2sm3113687wiy.6.2013.02.06.05.53.19
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 05:53:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 06 Feb 2013 13:53:12 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD3810C8.5A591%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4EcU2Y+wtN2rE9mEeb+tORXDPpIw==
In-Reply-To: <51123F59.6030901@eu.citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/02/2013 11:32, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

>> 4. Get the 3-level ABI to a mergable state. In parallel develop a
>> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
>> freeze is here, evaluate it and make a decision then.
> 
> Just to clarify, the difference between #1 and #4 is that in #4 we hold
> off on the merge, to delay committing to a specific course of action
> until later?
> 
> That seems at first blush to be a pretty safe option.  But I think it's
> worth pointing out that in practice the end result is likely to be that
> we just go with #1 eventually anyway: if the FIFO ABI can't be finished
> in 4 months giving it all our effort, can we really expect it to be
> finished in any less time while polishing up the 3-level ABI?
> 
> I was going to say, "There's no particular reason to merge the 3-level
> ABI sooner rather than later", but of course there is: it allows
> considerably longer and wider testing.
> 
> No conclusion here, just adding to the mix of things to consider. :-)

How many man-weeks do we think David's design would take to get to draft
implementation? I mean honestly I would have thought that a straight
two-week run at it would be a reasonable estimate -- the places it plugs in
in hypervisor and guest kernel are pretty clean and well defined.

This depends on a man having the weeks to spend on it of course!

 -- Keir



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 13:55:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 13: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 1U35TJ-0005hw-Tr; Wed, 06 Feb 2013 13: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 1U35TI-0005hr-3m
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 13:55:32 +0000
Received: from [85.158.143.35:54534] by server-1.bemta-4.messagelabs.com id
	C9/3A-08839-3D062115; Wed, 06 Feb 2013 13:55:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360158802!13210159!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29225 invoked from network); 6 Feb 2013 13:53:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 13:53:22 -0000
Received: by mail-we0-f173.google.com with SMTP id r5so1139485wey.18
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 05:53:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=GUWSp/7C4fgvJ/BU29jgk5T0z71eWbCSmdMCkd5WT7k=;
	b=Xo9+kt3mQE5nqe/GtDDaMvIDPQlMkDlC5wGc1eNAvseekgzQQJvAVU+4AHGUsPUDUT
	tWI9K5rGJqbXCvRodWp3nD0UxoAwmvYFCg6EelKzuW4V/09ZWgsgTJlPrd/l9jrAvtNZ
	Ni1moM/L7ksGuTb6PZX91raGxbbP2oyXGTiFHjRfADHBumvQNuswN7qO4ldtRB6c1cXu
	y++fYWRiawpW3DBMlFovX0Ybip+LwQWAeX05pazgB/9pi9yKBvN4cUFQCucSGeZDCuO1
	X0YTxzWXsR1hzu3cLAkQ6czK/VdYd5qbAaYs4CmVOhKjlPaiQ/MKSPRcHb74i2Rs2783
	GLaw==
X-Received: by 10.180.94.234 with SMTP id df10mr5065509wib.17.1360158802377;
	Wed, 06 Feb 2013 05:53:22 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id n2sm3113687wiy.6.2013.02.06.05.53.19
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 05:53:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 06 Feb 2013 13:53:12 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD3810C8.5A591%keir@xen.org>
Thread-Topic: [Xen-devel] Scalable Event Channel ABI design (draft A)
Thread-Index: Ac4EcU2Y+wtN2rE9mEeb+tORXDPpIw==
In-Reply-To: <51123F59.6030901@eu.citrix.com>
Mime-version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/02/2013 11:32, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

>> 4. Get the 3-level ABI to a mergable state. In parallel develop a
>> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
>> freeze is here, evaluate it and make a decision then.
> 
> Just to clarify, the difference between #1 and #4 is that in #4 we hold
> off on the merge, to delay committing to a specific course of action
> until later?
> 
> That seems at first blush to be a pretty safe option.  But I think it's
> worth pointing out that in practice the end result is likely to be that
> we just go with #1 eventually anyway: if the FIFO ABI can't be finished
> in 4 months giving it all our effort, can we really expect it to be
> finished in any less time while polishing up the 3-level ABI?
> 
> I was going to say, "There's no particular reason to merge the 3-level
> ABI sooner rather than later", but of course there is: it allows
> considerably longer and wider testing.
> 
> No conclusion here, just adding to the mix of things to consider. :-)

How many man-weeks do we think David's design would take to get to draft
implementation? I mean honestly I would have thought that a straight
two-week run at it would be a reasonable estimate -- the places it plugs in
in hypervisor and guest kernel are pretty clean and well defined.

This depends on a man having the weeks to spend on it of course!

 -- Keir



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365l-0007EZ-W4; Wed, 06 Feb 2013 14:35:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365k-0007Dk-Jr
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:16 +0000
Received: from [193.109.254.147:62663] by server-1.bemta-14.messagelabs.com id
	0E/07-29874-32A62115; Wed, 06 Feb 2013 14:35:15 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360161311!3889035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 633 invoked from network); 6 Feb 2013 14:35:13 -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;
	6 Feb 2013 14:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478542"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-Sj;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:58 +0000
Message-ID: <1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/5] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  158 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 328 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 733d020..bb85523 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -63,6 +64,159 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..53a192c
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..ad5cd9d 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,16 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365l-0007EZ-W4; Wed, 06 Feb 2013 14:35:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365k-0007Dk-Jr
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:16 +0000
Received: from [193.109.254.147:62663] by server-1.bemta-14.messagelabs.com id
	0E/07-29874-32A62115; Wed, 06 Feb 2013 14:35:15 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360161311!3889035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 633 invoked from network); 6 Feb 2013 14:35:13 -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;
	6 Feb 2013 14:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478542"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-Sj;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:58 +0000
Message-ID: <1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/5] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  158 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 328 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 733d020..bb85523 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -63,6 +64,159 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..53a192c
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..ad5cd9d 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,16 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365k-0007Dn-7h; Wed, 06 Feb 2013 14:35:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365i-0007DL-7W
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:14 +0000
Received: from [193.109.254.147:62490] by server-9.bemta-14.messagelabs.com id
	CE/7F-30867-12A62115; Wed, 06 Feb 2013 14:35:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360161309!1393631!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21435 invoked from network); 6 Feb 2013 14:35:12 -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;
	6 Feb 2013 14:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478541"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-Tw;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:33:00 +0000
Message-ID: <1360161180-3448-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/5] Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  141 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 149 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..5e7f440
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,141 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_read, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read} [<filename>]\n"
+        "\treset     reset information\n"
+        "\tread      read information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    /* check support */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_enabled, NULL) < 0 )
+        err(1, "checking coverage support");
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-");
+    else
+        usage();
+
+    return 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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365k-0007Dn-7h; Wed, 06 Feb 2013 14:35:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365i-0007DL-7W
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:14 +0000
Received: from [193.109.254.147:62490] by server-9.bemta-14.messagelabs.com id
	CE/7F-30867-12A62115; Wed, 06 Feb 2013 14:35:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360161309!1393631!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21435 invoked from network); 6 Feb 2013 14:35:12 -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;
	6 Feb 2013 14:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478541"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-Tw;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:33:00 +0000
Message-ID: <1360161180-3448-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/5] Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  141 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 149 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..5e7f440
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,141 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_read, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read} [<filename>]\n"
+        "\treset     reset information\n"
+        "\tread      read information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    /* check support */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_enabled, NULL) < 0 )
+        err(1, "checking coverage support");
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-");
+    else
+        usage();
+
+    return 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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365l-0007EP-KI; Wed, 06 Feb 2013 14:35:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365k-0007De-C1
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:16 +0000
Received: from [193.109.254.147:26961] by server-11.bemta-14.messagelabs.com
	id 64/DC-30685-32A62115; Wed, 06 Feb 2013 14:35:15 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360161309!1393631!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21500 invoked from network); 6 Feb 2013 14:35:13 -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;
	6 Feb 2013 14:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478540"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-Qw;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:57 +0000
Message-ID: <1360161180-3448-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/5] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   74 ++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 171 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..733d020
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,74 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365l-0007EP-KI; Wed, 06 Feb 2013 14:35:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365k-0007De-C1
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:16 +0000
Received: from [193.109.254.147:26961] by server-11.bemta-14.messagelabs.com
	id 64/DC-30685-32A62115; Wed, 06 Feb 2013 14:35:15 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360161309!1393631!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21500 invoked from network); 6 Feb 2013 14:35:13 -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;
	6 Feb 2013 14:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478540"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-Qw;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:57 +0000
Message-ID: <1360161180-3448-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/5] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   74 ++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 171 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..733d020
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,74 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365l-0007E5-0f; Wed, 06 Feb 2013 14:35:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365j-0007DR-BR
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:15 +0000
Received: from [85.158.139.83:3137] by server-15.bemta-5.messagelabs.com id
	D9/B1-18914-22A62115; Wed, 06 Feb 2013 14:35:14 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360161310!26935757!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21917 invoked from network); 6 Feb 2013 14:35:13 -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;
	6 Feb 2013 14:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6160194"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-NI;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:55 +0000
Message-ID: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v5] Coverage 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

Updated set of patches for coverage.

Changes:
- separate construction handling, this is not strictly related to coverage.
  Support it even on ARM.
- Rewrite blob format to allow portable definition of structures used and
  without compiler extensions used.
- remove RFC from subject.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365l-0007E5-0f; Wed, 06 Feb 2013 14:35:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365j-0007DR-BR
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:15 +0000
Received: from [85.158.139.83:3137] by server-15.bemta-5.messagelabs.com id
	D9/B1-18914-22A62115; Wed, 06 Feb 2013 14:35:14 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360161310!26935757!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21917 invoked from network); 6 Feb 2013 14:35:13 -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;
	6 Feb 2013 14:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6160194"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-NI;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:55 +0000
Message-ID: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v5] Coverage 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

Updated set of patches for coverage.

Changes:
- separate construction handling, this is not strictly related to coverage.
  Support it even on ARM.
- Rewrite blob format to allow portable definition of structures used and
  without compiler extensions used.
- remove RFC from subject.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365j-0007Df-SJ; Wed, 06 Feb 2013 14:35:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365i-0007DK-1D
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:14 +0000
Received: from [193.109.254.147:62458] by server-15.bemta-14.messagelabs.com
	id 36/53-24599-12A62115; Wed, 06 Feb 2013 14:35:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360161309!1393631!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21376 invoked from network); 6 Feb 2013 14:35:11 -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;
	6 Feb 2013 14:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478539"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-TL;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:59 +0000
Message-ID: <1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Safety check for initialization objects.
Constructors are not used so check some module does not use them.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/Rules.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3f0b262..ae35a08 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) \
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; do \
 		case "$$name" in \
-		.text|.text.*|.data|.data.*|.bss) \
+		.text|.text.*|.data|.data.*|.bss|.ctors) \
 			test $$sz != 0 || continue; \
 			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
 			exit $$(expr $$idx + 1);; \
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365j-0007Df-SJ; Wed, 06 Feb 2013 14:35:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365i-0007DK-1D
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:14 +0000
Received: from [193.109.254.147:62458] by server-15.bemta-14.messagelabs.com
	id 36/53-24599-12A62115; Wed, 06 Feb 2013 14:35:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360161309!1393631!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21376 invoked from network); 6 Feb 2013 14:35:11 -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;
	6 Feb 2013 14:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6478539"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-TL;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:59 +0000
Message-ID: <1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Safety check for initialization objects.
Constructors are not used so check some module does not use them.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/Rules.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3f0b262..ae35a08 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) \
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
 	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; do \
 		case "$$name" in \
-		.text|.text.*|.data|.data.*|.bss) \
+		.text|.text.*|.data|.data.*|.bss|.ctors) \
 			test $$sz != 0 || continue; \
 			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
 			exit $$(expr $$idx + 1);; \
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365k-0007Du-KS; Wed, 06 Feb 2013 14:35:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365i-0007DM-GC
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:14 +0000
Received: from [85.158.139.83:3097] by server-5.bemta-5.messagelabs.com id
	C5/D2-11945-12A62115; Wed, 06 Feb 2013 14:35:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360161310!26935757!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21717 invoked from network); 6 Feb 2013 14:35:12 -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;
	6 Feb 2013 14:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6160193"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-P9;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:56 +0000
Message-ID: <1360161180-3448-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/5] Call constructors during initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   16 ++++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..bc9eae9 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..715df82 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,21 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+typedef void (*ctor_func_t)(void);
+
+extern const struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Wed Feb 06 14:35:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14:35: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 1U365k-0007Du-KS; Wed, 06 Feb 2013 14:35:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U365i-0007DM-GC
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:35:14 +0000
Received: from [85.158.139.83:3097] by server-5.bemta-5.messagelabs.com id
	C5/D2-11945-12A62115; Wed, 06 Feb 2013 14:35:13 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360161310!26935757!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21717 invoked from network); 6 Feb 2013 14:35:12 -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;
	6 Feb 2013 14:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,615,1355097600"; 
   d="scan'208";a="6160193"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 14:35:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 09:35:09 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U365c-0001Bv-P9;
	Wed, 06 Feb 2013 14:35:08 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 14:32:56 +0000
Message-ID: <1360161180-3448-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/5] Call constructors during initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   16 ++++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..bc9eae9 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..715df82 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,21 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+typedef void (*ctor_func_t)(void);
+
+extern const struct
+{
+    unsigned long count;
+    ctor_func_t funcs[1];
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Wed Feb 06 14:42:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14: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 1U36CG-0008LQ-Jt; Wed, 06 Feb 2013 14:42:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U36CF-0008KE-3J
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:41:59 +0000
Received: from [85.158.139.211:33606] by server-5.bemta-5.messagelabs.com id
	1C/5F-11945-6BB62115; Wed, 06 Feb 2013 14:41:58 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360161714!19871378!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTgyMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15826 invoked from network); 6 Feb 2013 14:41:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 14:41:56 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16EfnFB021182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 14:41:50 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
	r16EfndQ008593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 14:41:49 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
	r16EfmvI029888; Wed, 6 Feb 2013 08:41:48 -0600
Received: from [10.152.55.169] (/10.152.55.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 06:41:47 -0800
Message-ID: <51126BA3.9020307@oracle.com>
Date: Wed, 06 Feb 2013 09:41:39 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:10.0.11) Gecko/20121115 Thunderbird/10.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
In-Reply-To: <511264B402000078000BC754@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 2/6/2013 8:12 AM, Jan Beulich wrote:

>
> +    /* Each IO-APIC must have been mentioned in the table. */
> +    for ( apic = 0; !error&&  apic<  nr_ioapics; ++apic )
> +    {
> +        if ( !nr_ioapic_entries[apic] ||
> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            continue;
> +
> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
> +               IO_APIC_ID(apic));
> +        if ( amd_iommu_perdev_intremap )
> +            error = -ENXIO;
> +        else
> +        {
> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            {
> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> +                error = -ENOMEM;
> +            }
> +        }
> +    }
> +
>       return error;
>   }
>

Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being 
uninitialized? They are usually set in parse_ivhd_device_special(), at 
the same time pin_setup is allocated, but with IVRS broken in this way 
we'll never get there, will we?

-boris

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:42:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14: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 1U36CG-0008LQ-Jt; Wed, 06 Feb 2013 14:42:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U36CF-0008KE-3J
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:41:59 +0000
Received: from [85.158.139.211:33606] by server-5.bemta-5.messagelabs.com id
	1C/5F-11945-6BB62115; Wed, 06 Feb 2013 14:41:58 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360161714!19871378!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTgyMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15826 invoked from network); 6 Feb 2013 14:41:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 14:41:56 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16EfnFB021182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 14:41:50 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
	r16EfndQ008593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 14:41:49 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
	r16EfmvI029888; Wed, 6 Feb 2013 08:41:48 -0600
Received: from [10.152.55.169] (/10.152.55.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 06:41:47 -0800
Message-ID: <51126BA3.9020307@oracle.com>
Date: Wed, 06 Feb 2013 09:41:39 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:10.0.11) Gecko/20121115 Thunderbird/10.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
In-Reply-To: <511264B402000078000BC754@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 2/6/2013 8:12 AM, Jan Beulich wrote:

>
> +    /* Each IO-APIC must have been mentioned in the table. */
> +    for ( apic = 0; !error&&  apic<  nr_ioapics; ++apic )
> +    {
> +        if ( !nr_ioapic_entries[apic] ||
> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            continue;
> +
> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
> +               IO_APIC_ID(apic));
> +        if ( amd_iommu_perdev_intremap )
> +            error = -ENXIO;
> +        else
> +        {
> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            {
> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> +                error = -ENOMEM;
> +            }
> +        }
> +    }
> +
>       return error;
>   }
>

Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being 
uninitialized? They are usually set in parse_ivhd_device_special(), at 
the same time pin_setup is allocated, but with IVRS broken in this way 
we'll never get there, will we?

-boris

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:52:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U36M4-0000TC-0i; Wed, 06 Feb 2013 14:52:08 +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 1U36M2-0000Ri-0U
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:52:06 +0000
Received: from [85.158.139.211:14331] by server-14.bemta-5.messagelabs.com id
	E7/F0-06967-51E62115; Wed, 06 Feb 2013 14:52:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360162323!18613066!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16265 invoked from network); 6 Feb 2013 14:52:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 14:52:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 14:52:03 +0000
Message-Id: <51127C2102000078000BC819@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 14:52:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<51126BA3.9020307@oracle.com>
In-Reply-To: <51126BA3.9020307@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 06.02.13 at 15:41, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 2/6/2013 8:12 AM, Jan Beulich wrote:
> 
>>
>> +    /* Each IO-APIC must have been mentioned in the table. */
>> +    for ( apic = 0; !error&&  apic<  nr_ioapics; ++apic )
>> +    {
>> +        if ( !nr_ioapic_entries[apic] ||
>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            continue;
>> +
>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>> +               IO_APIC_ID(apic));
>> +        if ( amd_iommu_perdev_intremap )
>> +            error = -ENXIO;
>> +        else
>> +        {
>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            {
>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>> +                error = -ENOMEM;
>> +            }
>> +        }
>> +    }
>> +
>>       return error;
>>   }
>>
> 
> Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being 
> uninitialized? They are usually set in parse_ivhd_device_special(), at 
> the same time pin_setup is allocated, but with IVRS broken in this way 
> we'll never get there, will we?

Correct. .bdf/.seg being uninitialized is no much of a problem
when using global intremap tables though. And certainly not on
a system with just a single IOMMU (as was the case on the
crashing system). Do you see alternatives? Disable the IOMMU
always, even if not using global remap tables? That could be
seen as a regression, as at least global remap tables worked fine
so far on such systems.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:52:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U36M4-0000TC-0i; Wed, 06 Feb 2013 14:52:08 +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 1U36M2-0000Ri-0U
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:52:06 +0000
Received: from [85.158.139.211:14331] by server-14.bemta-5.messagelabs.com id
	E7/F0-06967-51E62115; Wed, 06 Feb 2013 14:52:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360162323!18613066!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16265 invoked from network); 6 Feb 2013 14:52:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 14:52:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 14:52:03 +0000
Message-Id: <51127C2102000078000BC819@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 14:52:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<51126BA3.9020307@oracle.com>
In-Reply-To: <51126BA3.9020307@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 06.02.13 at 15:41, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 2/6/2013 8:12 AM, Jan Beulich wrote:
> 
>>
>> +    /* Each IO-APIC must have been mentioned in the table. */
>> +    for ( apic = 0; !error&&  apic<  nr_ioapics; ++apic )
>> +    {
>> +        if ( !nr_ioapic_entries[apic] ||
>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            continue;
>> +
>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>> +               IO_APIC_ID(apic));
>> +        if ( amd_iommu_perdev_intremap )
>> +            error = -ENXIO;
>> +        else
>> +        {
>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            {
>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>> +                error = -ENOMEM;
>> +            }
>> +        }
>> +    }
>> +
>>       return error;
>>   }
>>
> 
> Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being 
> uninitialized? They are usually set in parse_ivhd_device_special(), at 
> the same time pin_setup is allocated, but with IVRS broken in this way 
> we'll never get there, will we?

Correct. .bdf/.seg being uninitialized is no much of a problem
when using global intremap tables though. And certainly not on
a system with just a single IOMMU (as was the case on the
crashing system). Do you see alternatives? Disable the IOMMU
always, even if not using global remap tables? That could be
seen as a regression, as at least global remap tables worked fine
so far on such systems.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:59:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14: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 1U36T7-0000iB-V2; Wed, 06 Feb 2013 14:59: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 1U36T5-0000i6-Pt
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:59:23 +0000
Received: from [85.158.139.211:50713] by server-14.bemta-5.messagelabs.com id
	D3/13-06967-ACF62115; Wed, 06 Feb 2013 14:59:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360162755!19874509!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5626 invoked from network); 6 Feb 2013 14:59:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 14:59:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 14:59:14 +0000
Message-Id: <51127DD102000078000BC826@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 14:59:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-2-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360161180-3448-2-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] Call constructors during initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -84,6 +84,13 @@ SECTIONS
>         *(.init.data)
>         *(.init.data.rel)
>         *(.init.data.rel.*)
> +
> +       . = ALIGN(8);
> +       __CTOR_LIST__ = .;
> +       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)

Afaict this will crash if there's at least one constructor, because
the word size on (32-bit) ARM is 32 bits, i.e. the first function
pointer will be found to be NULL (the upper half of the count,
assuming ARM uses little endian, which I think it does).

> @@ -478,6 +479,21 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
>      return ret;
>  }
>  
> +typedef void (*ctor_func_t)(void);

This typedef if being used just once, so what's the point?

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 14:59:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 14: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 1U36T7-0000iB-V2; Wed, 06 Feb 2013 14:59: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 1U36T5-0000i6-Pt
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 14:59:23 +0000
Received: from [85.158.139.211:50713] by server-14.bemta-5.messagelabs.com id
	D3/13-06967-ACF62115; Wed, 06 Feb 2013 14:59:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360162755!19874509!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5626 invoked from network); 6 Feb 2013 14:59:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 14:59:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 14:59:14 +0000
Message-Id: <51127DD102000078000BC826@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 14:59:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-2-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360161180-3448-2-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/5] Call constructors during initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -84,6 +84,13 @@ SECTIONS
>         *(.init.data)
>         *(.init.data.rel)
>         *(.init.data.rel.*)
> +
> +       . = ALIGN(8);
> +       __CTOR_LIST__ = .;
> +       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)

Afaict this will crash if there's at least one constructor, because
the word size on (32-bit) ARM is 32 bits, i.e. the first function
pointer will be found to be NULL (the upper half of the count,
assuming ARM uses little endian, which I think it does).

> @@ -478,6 +479,21 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
>      return ret;
>  }
>  
> +typedef void (*ctor_func_t)(void);

This typedef if being used just once, so what's the point?

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:01:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:01: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 1U36VM-0000uW-GI; Wed, 06 Feb 2013 15:01:44 +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 1U36VL-0000uM-Qz
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:01:44 +0000
Received: from [85.158.139.83:19498] by server-5.bemta-5.messagelabs.com id
	1D/B3-11945-65072115; Wed, 06 Feb 2013 15:01:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360162901!27138381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11580 invoked from network); 6 Feb 2013 15:01:41 -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; 6 Feb 2013 15:01:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 15:01:41 +0000
Message-Id: <51127E6302000078000BC834@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 15:01:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> Safety check for initialization objects.
> Constructors are not used so check some module does not use them.

Once again - why?

And repeating earlier complaints of mine - why do you continue to
re-post without having addressed all comments on prior revisions
(verbally or by changing the patches)? This is just wasting
reviewers' time.

Jan

> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> ---
>  xen/Rules.mk |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 3f0b262..ae35a08 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 
> 8,rodata.str1.$(n)) \
>  $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
>  	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; 
> do \
>  		case "$$name" in \
> -		.text|.text.*|.data|.data.*|.bss) \
> +		.text|.text.*|.data|.data.*|.bss|.ctors) \
>  			test $$sz != 0 || continue; \
>  			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
>  			exit $$(expr $$idx + 1);; \
> -- 
> 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 Wed Feb 06 15:01:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:01: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 1U36VM-0000uW-GI; Wed, 06 Feb 2013 15:01:44 +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 1U36VL-0000uM-Qz
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:01:44 +0000
Received: from [85.158.139.83:19498] by server-5.bemta-5.messagelabs.com id
	1D/B3-11945-65072115; Wed, 06 Feb 2013 15:01:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360162901!27138381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11580 invoked from network); 6 Feb 2013 15:01:41 -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; 6 Feb 2013 15:01:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 15:01:41 +0000
Message-Id: <51127E6302000078000BC834@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 15:01:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> Safety check for initialization objects.
> Constructors are not used so check some module does not use them.

Once again - why?

And repeating earlier complaints of mine - why do you continue to
re-post without having addressed all comments on prior revisions
(verbally or by changing the patches)? This is just wasting
reviewers' time.

Jan

> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> ---
>  xen/Rules.mk |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 3f0b262..ae35a08 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 
> 8,rodata.str1.$(n)) \
>  $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
>  	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; 
> do \
>  		case "$$name" in \
> -		.text|.text.*|.data|.data.*|.bss) \
> +		.text|.text.*|.data|.data.*|.bss|.ctors) \
>  			test $$sz != 0 || continue; \
>  			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
>  			exit $$(expr $$idx + 1);; \
> -- 
> 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 Wed Feb 06 15:04:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:04: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 1U36XS-00012v-17; Wed, 06 Feb 2013 15:03:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U36XQ-00012p-VM
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:03:53 +0000
Received: from [85.158.143.35:33722] by server-2.bemta-4.messagelabs.com id
	9C/DB-01597-8D072115; Wed, 06 Feb 2013 15:03:52 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360163029!14323627!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTgyMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2671 invoked from network); 6 Feb 2013 15:03:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 15:03:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16F3kbq018288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 15:03:47 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
	r16F3fsf016271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 15:03:42 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
	r16F3eA7030358; Wed, 6 Feb 2013 09:03:41 -0600
Received: from [10.152.55.169] (/10.152.55.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 07:03:40 -0800
Message-ID: <511270CA.6090903@oracle.com>
Date: Wed, 06 Feb 2013 10:03:38 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:10.0.11) Gecko/20121115 Thunderbird/10.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<51126BA3.9020307@oracle.com>
	<51127C2102000078000BC819@nat28.tlf.novell.com>
In-Reply-To: <51127C2102000078000BC819@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 2/6/2013 9:52 AM, Jan Beulich wrote:
>>>> On 06.02.13 at 15:41, Boris Ostrovsky<boris.ostrovsky@oracle.com>  wrote:
>> On 2/6/2013 8:12 AM, Jan Beulich wrote:
>>
>>>
>>> +    /* Each IO-APIC must have been mentioned in the table. */
>>> +    for ( apic = 0; !error&&   apic<   nr_ioapics; ++apic )
>>> +    {
>>> +        if ( !nr_ioapic_entries[apic] ||
>>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>> +            continue;
>>> +
>>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>>> +               IO_APIC_ID(apic));
>>> +        if ( amd_iommu_perdev_intremap )
>>> +            error = -ENXIO;
>>> +        else
>>> +        {
>>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>> +            {
>>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>>> +                error = -ENOMEM;
>>> +            }
>>> +        }
>>> +    }
>>> +
>>>        return error;
>>>    }
>>>
>>
>> Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being
>> uninitialized? They are usually set in parse_ivhd_device_special(), at
>> the same time pin_setup is allocated, but with IVRS broken in this way
>> we'll never get there, will we?
>
> Correct. .bdf/.seg being uninitialized is no much of a problem
> when using global intremap tables though.

Since this patch has been tested it clearly must have worked somehow but 
I don't understand where you'd get bdf and seg in 
amd_iommu_ioapic_update_ire() and then manage to find the right IOMMU.

-boris

 > And certainly not on
> a system with just a single IOMMU (as was the case on the
> crashing system). Do you see alternatives? Disable the IOMMU
> always, even if not using global remap tables? That could be
> seen as a regression, as at least global remap tables worked fine
> so far on such systems.






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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:04:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:04: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 1U36XS-00012v-17; Wed, 06 Feb 2013 15:03:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U36XQ-00012p-VM
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:03:53 +0000
Received: from [85.158.143.35:33722] by server-2.bemta-4.messagelabs.com id
	9C/DB-01597-8D072115; Wed, 06 Feb 2013 15:03:52 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360163029!14323627!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTgyMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2671 invoked from network); 6 Feb 2013 15:03:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 15:03:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16F3kbq018288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 15:03:47 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
	r16F3fsf016271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 15:03:42 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
	r16F3eA7030358; Wed, 6 Feb 2013 09:03:41 -0600
Received: from [10.152.55.169] (/10.152.55.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 07:03:40 -0800
Message-ID: <511270CA.6090903@oracle.com>
Date: Wed, 06 Feb 2013 10:03:38 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:10.0.11) Gecko/20121115 Thunderbird/10.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<51126BA3.9020307@oracle.com>
	<51127C2102000078000BC819@nat28.tlf.novell.com>
In-Reply-To: <51127C2102000078000BC819@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 2/6/2013 9:52 AM, Jan Beulich wrote:
>>>> On 06.02.13 at 15:41, Boris Ostrovsky<boris.ostrovsky@oracle.com>  wrote:
>> On 2/6/2013 8:12 AM, Jan Beulich wrote:
>>
>>>
>>> +    /* Each IO-APIC must have been mentioned in the table. */
>>> +    for ( apic = 0; !error&&   apic<   nr_ioapics; ++apic )
>>> +    {
>>> +        if ( !nr_ioapic_entries[apic] ||
>>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>> +            continue;
>>> +
>>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>>> +               IO_APIC_ID(apic));
>>> +        if ( amd_iommu_perdev_intremap )
>>> +            error = -ENXIO;
>>> +        else
>>> +        {
>>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>> +            {
>>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>>> +                error = -ENOMEM;
>>> +            }
>>> +        }
>>> +    }
>>> +
>>>        return error;
>>>    }
>>>
>>
>> Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being
>> uninitialized? They are usually set in parse_ivhd_device_special(), at
>> the same time pin_setup is allocated, but with IVRS broken in this way
>> we'll never get there, will we?
>
> Correct. .bdf/.seg being uninitialized is no much of a problem
> when using global intremap tables though.

Since this patch has been tested it clearly must have worked somehow but 
I don't understand where you'd get bdf and seg in 
amd_iommu_ioapic_update_ire() and then manage to find the right IOMMU.

-boris

 > And certainly not on
> a system with just a single IOMMU (as was the case on the
> crashing system). Do you see alternatives? Disable the IOMMU
> always, even if not using global remap tables? That could be
> seen as a regression, as at least global remap tables worked fine
> so far on such systems.






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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:12:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:12: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 1U36fr-0001ST-2G; Wed, 06 Feb 2013 15:12:35 +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 1U36fp-0001Pu-1A
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:12:33 +0000
Received: from [85.158.138.51:12256] by server-8.bemta-3.messagelabs.com id
	98/D5-25687-BD272115; Wed, 06 Feb 2013 15:12:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360163544!29487368!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21578 invoked from network); 6 Feb 2013 15:12:25 -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; 6 Feb 2013 15:12:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 15:12:24 +0000
Message-Id: <511280E702000078000BC84A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 15:12:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<51126BA3.9020307@oracle.com>
	<51127C2102000078000BC819@nat28.tlf.novell.com>
	<511270CA.6090903@oracle.com>
In-Reply-To: <511270CA.6090903@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 06.02.13 at 16:03, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 2/6/2013 9:52 AM, Jan Beulich wrote:
>>>>> On 06.02.13 at 15:41, Boris Ostrovsky<boris.ostrovsky@oracle.com>  wrote:
>>> On 2/6/2013 8:12 AM, Jan Beulich wrote:
>>>
>>>>
>>>> +    /* Each IO-APIC must have been mentioned in the table. */
>>>> +    for ( apic = 0; !error&&   apic<   nr_ioapics; ++apic )
>>>> +    {
>>>> +        if ( !nr_ioapic_entries[apic] ||
>>>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>>> +            continue;
>>>> +
>>>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>>>> +               IO_APIC_ID(apic));
>>>> +        if ( amd_iommu_perdev_intremap )
>>>> +            error = -ENXIO;
>>>> +        else
>>>> +        {
>>>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>>>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>>>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>>> +            {
>>>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>>>> +                error = -ENOMEM;
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +
>>>>        return error;
>>>>    }
>>>>
>>>
>>> Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being
>>> uninitialized? They are usually set in parse_ivhd_device_special(), at
>>> the same time pin_setup is allocated, but with IVRS broken in this way
>>> we'll never get there, will we?
>>
>> Correct. .bdf/.seg being uninitialized is no much of a problem
>> when using global intremap tables though.
> 
> Since this patch has been tested it clearly must have worked somehow but 
> I don't understand where you'd get bdf and seg in 
> amd_iommu_ioapic_update_ire() and then manage to find the right IOMMU.

The "right" IOMMU simply is the only one, and that is equally well
found with sbdf being zero.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:12:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:12: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 1U36fr-0001ST-2G; Wed, 06 Feb 2013 15:12:35 +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 1U36fp-0001Pu-1A
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:12:33 +0000
Received: from [85.158.138.51:12256] by server-8.bemta-3.messagelabs.com id
	98/D5-25687-BD272115; Wed, 06 Feb 2013 15:12:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360163544!29487368!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21578 invoked from network); 6 Feb 2013 15:12:25 -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; 6 Feb 2013 15:12:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 15:12:24 +0000
Message-Id: <511280E702000078000BC84A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 15:12:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<51126BA3.9020307@oracle.com>
	<51127C2102000078000BC819@nat28.tlf.novell.com>
	<511270CA.6090903@oracle.com>
In-Reply-To: <511270CA.6090903@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 06.02.13 at 16:03, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 2/6/2013 9:52 AM, Jan Beulich wrote:
>>>>> On 06.02.13 at 15:41, Boris Ostrovsky<boris.ostrovsky@oracle.com>  wrote:
>>> On 2/6/2013 8:12 AM, Jan Beulich wrote:
>>>
>>>>
>>>> +    /* Each IO-APIC must have been mentioned in the table. */
>>>> +    for ( apic = 0; !error&&   apic<   nr_ioapics; ++apic )
>>>> +    {
>>>> +        if ( !nr_ioapic_entries[apic] ||
>>>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>>> +            continue;
>>>> +
>>>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>>>> +               IO_APIC_ID(apic));
>>>> +        if ( amd_iommu_perdev_intremap )
>>>> +            error = -ENXIO;
>>>> +        else
>>>> +        {
>>>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>>>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>>>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>>>> +            {
>>>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>>>> +                error = -ENOMEM;
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +
>>>>        return error;
>>>>    }
>>>>
>>>
>>> Don't we end up with ioapic_sbdf[IO_APIC_ID(apic)].bdf/seg being
>>> uninitialized? They are usually set in parse_ivhd_device_special(), at
>>> the same time pin_setup is allocated, but with IVRS broken in this way
>>> we'll never get there, will we?
>>
>> Correct. .bdf/.seg being uninitialized is no much of a problem
>> when using global intremap tables though.
> 
> Since this patch has been tested it clearly must have worked somehow but 
> I don't understand where you'd get bdf and seg in 
> amd_iommu_ioapic_update_ire() and then manage to find the right IOMMU.

The "right" IOMMU simply is the only one, and that is equally well
found with sbdf being zero.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:30:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15: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 1U36xO-0002DX-Ek; Wed, 06 Feb 2013 15:30:42 +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 1U36xM-0002DS-RL
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:30:41 +0000
Received: from [85.158.137.99:56239] by server-16.bemta-3.messagelabs.com id
	D9/1C-02727-F1772115; Wed, 06 Feb 2013 15:30:39 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360164637!17940154!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDQ4Mzc=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16833 invoked from network); 6 Feb 2013 15:30:38 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-15.tower-217.messagelabs.com with SMTP;
	6 Feb 2013 15:30:38 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id D288814F211;
	Wed,  6 Feb 2013 16:29:37 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Wed,  6 Feb 2013 16:29:19 +0100
Message-Id: <1360164559-9670-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v5] tools/libxl: Improve videoram 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

- If videoram setting is less than 8 mb shows error and exit.
- Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
- Updated xl.cfg man.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 docs/man/xl.cfg.pod.5      |   14 +++++---------
 tools/libxl/libxl_create.c |    4 ++++
 tools/libxl/libxl_dm.c     |    6 ++++++
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index caba162..9c5cdcd 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
 
 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B<stdvga>
-option (see below).
+available.
 The default amount of video ram for stdvga is 8MB which is sufficient
-for e.g. 1600x1200 at 32bpp.
+for e.g. 1600x1200 at 32bpp and videoram option is currently working
+only when using the qemu-xen-traditional device-model.
 
 When using the emulated Cirrus graphics card (B<stdvga=0>)
 the amount of video ram is fixed at 4MB which is sufficient
-for 1024x768 at 32 bpp.
-
-videoram option is currently only available when using the
-qemu-xen-traditional device-model. Upstream qemu-xen device-model
-currently does not support changing the amount of video memory for the
-emulated graphics device.
+for 1024x768 at 32 bpp and videoram option is currently working
+only when using the upstream qemu-xen device-model.
 
 =item B<stdvga=BOOLEAN>
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a8dfe61..cf545ef 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
             b_info->shadow_memkb = 0;
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+        else if (b_info->video_memkb < 8192){
+            LOG(ERROR,"videoram must be at least 8 mb");
+            return ERROR_INVAL;
+        }
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index c265618..a2c99bd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -433,6 +433,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "vga.vram_size_mb=%d",
+                libxl__sizekb_to_mb(b_info->video_memkb)),
+                NULL);
+            }
             break;
         }
 
-- 
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 Wed Feb 06 15:30:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15: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 1U36xO-0002DX-Ek; Wed, 06 Feb 2013 15:30:42 +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 1U36xM-0002DS-RL
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:30:41 +0000
Received: from [85.158.137.99:56239] by server-16.bemta-3.messagelabs.com id
	D9/1C-02727-F1772115; Wed, 06 Feb 2013 15:30:39 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360164637!17940154!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDQ4Mzc=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16833 invoked from network); 6 Feb 2013 15:30:38 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-15.tower-217.messagelabs.com with SMTP;
	6 Feb 2013 15:30:38 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id D288814F211;
	Wed,  6 Feb 2013 16:29:37 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Wed,  6 Feb 2013 16:29:19 +0100
Message-Id: <1360164559-9670-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v5] tools/libxl: Improve videoram 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

- If videoram setting is less than 8 mb shows error and exit.
- Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
- Updated xl.cfg man.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 docs/man/xl.cfg.pod.5      |   14 +++++---------
 tools/libxl/libxl_create.c |    4 ++++
 tools/libxl/libxl_dm.c     |    6 ++++++
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index caba162..9c5cdcd 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
 
 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B<stdvga>
-option (see below).
+available.
 The default amount of video ram for stdvga is 8MB which is sufficient
-for e.g. 1600x1200 at 32bpp.
+for e.g. 1600x1200 at 32bpp and videoram option is currently working
+only when using the qemu-xen-traditional device-model.
 
 When using the emulated Cirrus graphics card (B<stdvga=0>)
 the amount of video ram is fixed at 4MB which is sufficient
-for 1024x768 at 32 bpp.
-
-videoram option is currently only available when using the
-qemu-xen-traditional device-model. Upstream qemu-xen device-model
-currently does not support changing the amount of video memory for the
-emulated graphics device.
+for 1024x768 at 32 bpp and videoram option is currently working
+only when using the upstream qemu-xen device-model.
 
 =item B<stdvga=BOOLEAN>
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a8dfe61..cf545ef 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
             b_info->shadow_memkb = 0;
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+        else if (b_info->video_memkb < 8192){
+            LOG(ERROR,"videoram must be at least 8 mb");
+            return ERROR_INVAL;
+        }
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index c265618..a2c99bd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -433,6 +433,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "vga.vram_size_mb=%d",
+                libxl__sizekb_to_mb(b_info->video_memkb)),
+                NULL);
+            }
             break;
         }
 
-- 
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 Wed Feb 06 15:39:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:39: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 1U375m-0002en-EX; Wed, 06 Feb 2013 15:39:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1U375k-0002eg-9a
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:39:20 +0000
Received: from [85.158.137.99:53858] by server-4.bemta-3.messagelabs.com id
	B5/D2-12802-72972115; Wed, 06 Feb 2013 15:39:19 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360165157!12071653!1
X-Originating-IP: [209.85.220.176]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9520 invoked from network); 6 Feb 2013 15:39:18 -0000
Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com)
	(209.85.220.176)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:39:18 -0000
Received: by mail-vc0-f176.google.com with SMTP id fy27so930264vcb.21
	for <Xen-devel@lists.xensource.com>;
	Wed, 06 Feb 2013 07:39:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=pnztYspA4UNPi3Yt8t+5nMT5aEig5tpq4ovqApTb/9U=;
	b=ubj09KpOY3ZYG/DSEzo+9i+pOW8fILUFnPIu9PutjqP9pz+HvZTFZJL3rs2A7XZU7E
	yGUuRMWHWDyU3J8KvOgU7vzNPntbA7clKylFPLPcyrrqZUbK1yLoj/yyhltI2Hn8o3YW
	1f3Ct7zFkFvOUGSSyWNldNMKf8+KxZOG+dUEXcBVjA6tzx0S0nlStvDyXJ7Yt+ha/Zn0
	wxWlwc2amNpm/qfY/cJBZOAO5xwEgIFA6HaQgGu5RPLjz8MlZGOwX1My41DaAD1UdBQD
	sv9fu2BPQOSbLkNQXKY0dKCkhOg/XtvGuI1VHE6ZeqsY8fsDBCRYc0QrmDM5Qpln/BTc
	sHbg==
X-Received: by 10.52.38.163 with SMTP id h3mr29819488vdk.35.1360165156789;
	Wed, 06 Feb 2013 07:39:16 -0800 (PST)
Received: from konrad-lan.dumpdata.com (c-67-186-155-227.hsd1.ct.comcast.net.
	[67.186.155.227])
	by mx.google.com with ESMTPS id yu4sm33005189veb.7.2013.02.06.07.39.15
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:39:15 -0800 (PST)
Date: Wed, 6 Feb 2013 10:39:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130206153910.GA23029@konrad-lan.dumpdata.com>
References: <20130130145529.3900dca1@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130130145529.3900dca1@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH: remove code to map iomem from 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 Wed, Jan 30, 2013 at 02:55:29PM -0800, Mukesh Rathor wrote:
> It was decided during xen patch review that xen map the iomem
> transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub
> hypercall PHYSDEVOP_map_iomem.
> 

Grrrr..

No Signed-off-by??

> ---
>  arch/x86/xen/mmu.c              |   14 --------------
>  arch/x86/xen/setup.c            |   16 ++++------------
>  include/xen/interface/physdev.h |   10 ----------
>  3 files changed, 4 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b4be4c9..fbf6a63 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -333,20 +333,6 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> -void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> -			      int nr_mfns, int add_mapping)
> -{
> -	struct physdev_map_iomem iomem;
> -
> -	iomem.first_gfn = pfn;
> -	iomem.first_mfn = mfn;
> -	iomem.nr_mfns = nr_mfns;
> -	iomem.add_mapping = add_mapping;
> -
> -	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
> -		BUG();
> -}
> -
>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 7e93ec9..6532172 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -235,20 +235,12 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> -/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> - * are released as part of this 1:1 mapping hypercall back to the dom heap.
> - * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> - */
> -static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> +/* PVH: xen has already mapped the IO space in the EPT/NPT for us, so we
> + * just need to adjust the released and identity count */
> +static void __init xen_pvh_adjust_stats(unsigned long start_pfn,
>  		unsigned long end_pfn, unsigned long max_pfn,
>  		unsigned long *released, unsigned long *identity)
>  {
> -	unsigned long pfn;
> -	int numpfns = 1, add_mapping = 1;
> -
> -	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> -		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> -
>  	if (start_pfn <= max_pfn) {
>  		unsigned long end = min(max_pfn_mapped, end_pfn);
>  		*released += end - start_pfn;
> @@ -288,7 +280,7 @@ static unsigned long __init xen_set_identity_and_release(
>  
>  			if (start_pfn < end_pfn) {
>  				if (xlated_phys) {
> -					xen_pvh_identity_map_chunk(start_pfn,
> +					xen_pvh_adjust_stats(start_pfn,
>  						end_pfn, nr_pages, &released, 
>  						&identity);
>  				} else {
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 83050d3..1844d31 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -274,16 +274,6 @@ struct physdev_dbgp_op {
>      } u;
>  };
>  
> -#define PHYSDEVOP_map_iomem        30
> -struct physdev_map_iomem {
> -    /* IN */
> -    uint64_t first_gfn;
> -    uint64_t first_mfn;
> -    uint32_t nr_mfns;
> -    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
> -
> -};
> -
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.3
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:39:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:39: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 1U375m-0002en-EX; Wed, 06 Feb 2013 15:39:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1U375k-0002eg-9a
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:39:20 +0000
Received: from [85.158.137.99:53858] by server-4.bemta-3.messagelabs.com id
	B5/D2-12802-72972115; Wed, 06 Feb 2013 15:39:19 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360165157!12071653!1
X-Originating-IP: [209.85.220.176]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9520 invoked from network); 6 Feb 2013 15:39:18 -0000
Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com)
	(209.85.220.176)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:39:18 -0000
Received: by mail-vc0-f176.google.com with SMTP id fy27so930264vcb.21
	for <Xen-devel@lists.xensource.com>;
	Wed, 06 Feb 2013 07:39:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=pnztYspA4UNPi3Yt8t+5nMT5aEig5tpq4ovqApTb/9U=;
	b=ubj09KpOY3ZYG/DSEzo+9i+pOW8fILUFnPIu9PutjqP9pz+HvZTFZJL3rs2A7XZU7E
	yGUuRMWHWDyU3J8KvOgU7vzNPntbA7clKylFPLPcyrrqZUbK1yLoj/yyhltI2Hn8o3YW
	1f3Ct7zFkFvOUGSSyWNldNMKf8+KxZOG+dUEXcBVjA6tzx0S0nlStvDyXJ7Yt+ha/Zn0
	wxWlwc2amNpm/qfY/cJBZOAO5xwEgIFA6HaQgGu5RPLjz8MlZGOwX1My41DaAD1UdBQD
	sv9fu2BPQOSbLkNQXKY0dKCkhOg/XtvGuI1VHE6ZeqsY8fsDBCRYc0QrmDM5Qpln/BTc
	sHbg==
X-Received: by 10.52.38.163 with SMTP id h3mr29819488vdk.35.1360165156789;
	Wed, 06 Feb 2013 07:39:16 -0800 (PST)
Received: from konrad-lan.dumpdata.com (c-67-186-155-227.hsd1.ct.comcast.net.
	[67.186.155.227])
	by mx.google.com with ESMTPS id yu4sm33005189veb.7.2013.02.06.07.39.15
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:39:15 -0800 (PST)
Date: Wed, 6 Feb 2013 10:39:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130206153910.GA23029@konrad-lan.dumpdata.com>
References: <20130130145529.3900dca1@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130130145529.3900dca1@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH: remove code to map iomem from 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 Wed, Jan 30, 2013 at 02:55:29PM -0800, Mukesh Rathor wrote:
> It was decided during xen patch review that xen map the iomem
> transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub
> hypercall PHYSDEVOP_map_iomem.
> 

Grrrr..

No Signed-off-by??

> ---
>  arch/x86/xen/mmu.c              |   14 --------------
>  arch/x86/xen/setup.c            |   16 ++++------------
>  include/xen/interface/physdev.h |   10 ----------
>  3 files changed, 4 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b4be4c9..fbf6a63 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -333,20 +333,6 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> -void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> -			      int nr_mfns, int add_mapping)
> -{
> -	struct physdev_map_iomem iomem;
> -
> -	iomem.first_gfn = pfn;
> -	iomem.first_mfn = mfn;
> -	iomem.nr_mfns = nr_mfns;
> -	iomem.add_mapping = add_mapping;
> -
> -	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
> -		BUG();
> -}
> -
>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 7e93ec9..6532172 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -235,20 +235,12 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> -/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> - * are released as part of this 1:1 mapping hypercall back to the dom heap.
> - * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> - */
> -static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> +/* PVH: xen has already mapped the IO space in the EPT/NPT for us, so we
> + * just need to adjust the released and identity count */
> +static void __init xen_pvh_adjust_stats(unsigned long start_pfn,
>  		unsigned long end_pfn, unsigned long max_pfn,
>  		unsigned long *released, unsigned long *identity)
>  {
> -	unsigned long pfn;
> -	int numpfns = 1, add_mapping = 1;
> -
> -	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> -		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> -
>  	if (start_pfn <= max_pfn) {
>  		unsigned long end = min(max_pfn_mapped, end_pfn);
>  		*released += end - start_pfn;
> @@ -288,7 +280,7 @@ static unsigned long __init xen_set_identity_and_release(
>  
>  			if (start_pfn < end_pfn) {
>  				if (xlated_phys) {
> -					xen_pvh_identity_map_chunk(start_pfn,
> +					xen_pvh_adjust_stats(start_pfn,
>  						end_pfn, nr_pages, &released, 
>  						&identity);
>  				} else {
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 83050d3..1844d31 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -274,16 +274,6 @@ struct physdev_dbgp_op {
>      } u;
>  };
>  
> -#define PHYSDEVOP_map_iomem        30
> -struct physdev_map_iomem {
> -    /* IN */
> -    uint64_t first_gfn;
> -    uint64_t first_mfn;
> -    uint32_t nr_mfns;
> -    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
> -
> -};
> -
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.3
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:42:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:42: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 1U378t-00031n-6c; Wed, 06 Feb 2013 15:42:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U378s-00031f-6j
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:42:34 +0000
Received: from [85.158.138.51:21168] by server-1.bemta-3.messagelabs.com id
	A0/17-08955-9E972115; Wed, 06 Feb 2013 15:42:33 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360165351!29487088!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16836 invoked from network); 6 Feb 2013 15:42:31 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:42:31 -0000
Received: by mail-wi0-f177.google.com with SMTP id hm14so1717385wib.16
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Feb 2013 07:42:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=PhmQ0vtdHVoovY34du41/VsklN492TYw1u2oKNaEzzg=;
	b=J9z3mYsDiObtTcyZfRV+f602FDJ/yO/6fpBwgGfwFGAcfdLoKCCDxmou4lenqmfkSN
	bEW3DnKbiqC7rNOs4zJ5iTQbLwGCcjffmokfVNn6wUfC6Iv7LufIWFiji108yQRbiary
	59BQ4DXOFxUgbSGW6pS2KyUc+urBiIymMKuMXztVU6UNyr6nm/kkKkhVXDP6gf1StMUm
	InrOsoa4DGZHMoxrwPEift54nXuiW2r92flWiMK+mnW/+TSSCC1exRu7VHnLDKtBo2xT
	oDwxO4vcOr/eZo9YpFugvRIRXQlZo61RbpRnfQn87K0crjQnoXnt05vnZFLseQZPxlYD
	Nx3Q==
X-Received: by 10.180.78.66 with SMTP id z2mr5860269wiw.23.1360165350115;
	Wed, 06 Feb 2013 07:42:30 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id hb9sm3675478wib.3.2013.02.06.07.42.28
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:42:29 -0800 (PST)
Message-ID: <511279E9.20404@heliman.it>
Date: Wed, 06 Feb 2013 16:42:33 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: fantonifabio@tiscali.it
References: <1360164559-9670-1-git-send-email-fantonifabio@tiscali.it>
In-Reply-To: <1360164559-9670-1-git-send-email-fantonifabio@tiscali.it>
X-Gm-Message-State: ALoCoQkkDsNSmYrnCPWN2mM3YK+PGQGrIiIjF8aMbGsKb8a4UOa1Z5w2jluZZWr0KMNdnMPCHKtP
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v5] tools/libxl: Improve videoram 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-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

Il 06/02/2013 16:29, fantonifabio@tiscali.it ha scritto:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>
> - If videoram setting is less than 8 mb shows error and exit.
> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
> - Updated xl.cfg man.
>
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   docs/man/xl.cfg.pod.5      |   14 +++++---------
>   tools/libxl/libxl_create.c |    4 ++++
>   tools/libxl/libxl_dm.c     |    6 ++++++
>   3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index caba162..9c5cdcd 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
>   
>   Sets the amount of RAM which the emulated video card will contain,
>   which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B<stdvga>
> -option (see below).
> +available.
>   The default amount of video ram for stdvga is 8MB which is sufficient
> -for e.g. 1600x1200 at 32bpp.
> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
> +only when using the qemu-xen-traditional device-model.
>   
>   When using the emulated Cirrus graphics card (B<stdvga=0>)
>   the amount of video ram is fixed at 4MB which is sufficient
> -for 1024x768 at 32 bpp.
> -
> -videoram option is currently only available when using the
> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
> -currently does not support changing the amount of video memory for the
> -emulated graphics device.
> +for 1024x768 at 32 bpp and videoram option is currently working
> +only when using the upstream qemu-xen device-model.
>   
>   =item B<stdvga=BOOLEAN>
>   
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a8dfe61..cf545ef 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>               b_info->shadow_memkb = 0;
>           if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->video_memkb = 8 * 1024;
> +        else if (b_info->video_memkb < 8192){
> +            LOG(ERROR,"videoram must be at least 8 mb");
> +            return ERROR_INVAL;
> +        }
>           if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
>               b_info->u.hvm.timer_mode =
>                   LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index c265618..a2c99bd 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -433,6 +433,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>               break;
>           case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>               flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "vga.vram_size_mb=%d",
> +                libxl__sizekb_to_mb(b_info->video_memkb)),
> +                NULL);
> +            }
>               break;
>           }
>   
This time should be correct, sent with "git send-mail".
Tested also with older qemu (qemu-upstream-4.2-testing.git that have 
qemu 1.1), videoram setting with cirrus does not give error.
I think is good to backport this patch also on 4.2.x to prevent setting 
of videoram < 8 mb and support cirrus memory setting if qemu is >=1.3 
(some distro or user probably will have xen 4.2.x with qemu>=1.3).

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:42:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15:42: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 1U378t-00031n-6c; Wed, 06 Feb 2013 15:42:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U378s-00031f-6j
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:42:34 +0000
Received: from [85.158.138.51:21168] by server-1.bemta-3.messagelabs.com id
	A0/17-08955-9E972115; Wed, 06 Feb 2013 15:42:33 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360165351!29487088!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16836 invoked from network); 6 Feb 2013 15:42:31 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:42:31 -0000
Received: by mail-wi0-f177.google.com with SMTP id hm14so1717385wib.16
	for <xen-devel@lists.xensource.com>;
	Wed, 06 Feb 2013 07:42:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=PhmQ0vtdHVoovY34du41/VsklN492TYw1u2oKNaEzzg=;
	b=J9z3mYsDiObtTcyZfRV+f602FDJ/yO/6fpBwgGfwFGAcfdLoKCCDxmou4lenqmfkSN
	bEW3DnKbiqC7rNOs4zJ5iTQbLwGCcjffmokfVNn6wUfC6Iv7LufIWFiji108yQRbiary
	59BQ4DXOFxUgbSGW6pS2KyUc+urBiIymMKuMXztVU6UNyr6nm/kkKkhVXDP6gf1StMUm
	InrOsoa4DGZHMoxrwPEift54nXuiW2r92flWiMK+mnW/+TSSCC1exRu7VHnLDKtBo2xT
	oDwxO4vcOr/eZo9YpFugvRIRXQlZo61RbpRnfQn87K0crjQnoXnt05vnZFLseQZPxlYD
	Nx3Q==
X-Received: by 10.180.78.66 with SMTP id z2mr5860269wiw.23.1360165350115;
	Wed, 06 Feb 2013 07:42:30 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id hb9sm3675478wib.3.2013.02.06.07.42.28
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:42:29 -0800 (PST)
Message-ID: <511279E9.20404@heliman.it>
Date: Wed, 06 Feb 2013 16:42:33 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: fantonifabio@tiscali.it
References: <1360164559-9670-1-git-send-email-fantonifabio@tiscali.it>
In-Reply-To: <1360164559-9670-1-git-send-email-fantonifabio@tiscali.it>
X-Gm-Message-State: ALoCoQkkDsNSmYrnCPWN2mM3YK+PGQGrIiIjF8aMbGsKb8a4UOa1Z5w2jluZZWr0KMNdnMPCHKtP
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v5] tools/libxl: Improve videoram 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-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

Il 06/02/2013 16:29, fantonifabio@tiscali.it ha scritto:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>
> - If videoram setting is less than 8 mb shows error and exit.
> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
> - Updated xl.cfg man.
>
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   docs/man/xl.cfg.pod.5      |   14 +++++---------
>   tools/libxl/libxl_create.c |    4 ++++
>   tools/libxl/libxl_dm.c     |    6 ++++++
>   3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index caba162..9c5cdcd 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
>   
>   Sets the amount of RAM which the emulated video card will contain,
>   which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B<stdvga>
> -option (see below).
> +available.
>   The default amount of video ram for stdvga is 8MB which is sufficient
> -for e.g. 1600x1200 at 32bpp.
> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
> +only when using the qemu-xen-traditional device-model.
>   
>   When using the emulated Cirrus graphics card (B<stdvga=0>)
>   the amount of video ram is fixed at 4MB which is sufficient
> -for 1024x768 at 32 bpp.
> -
> -videoram option is currently only available when using the
> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
> -currently does not support changing the amount of video memory for the
> -emulated graphics device.
> +for 1024x768 at 32 bpp and videoram option is currently working
> +only when using the upstream qemu-xen device-model.
>   
>   =item B<stdvga=BOOLEAN>
>   
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a8dfe61..cf545ef 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -199,6 +199,10 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>               b_info->shadow_memkb = 0;
>           if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>               b_info->video_memkb = 8 * 1024;
> +        else if (b_info->video_memkb < 8192){
> +            LOG(ERROR,"videoram must be at least 8 mb");
> +            return ERROR_INVAL;
> +        }
>           if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
>               b_info->u.hvm.timer_mode =
>                   LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index c265618..a2c99bd 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -433,6 +433,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>               break;
>           case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>               flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "vga.vram_size_mb=%d",
> +                libxl__sizekb_to_mb(b_info->video_memkb)),
> +                NULL);
> +            }
>               break;
>           }
>   
This time should be correct, sent with "git send-mail".
Tested also with older qemu (qemu-upstream-4.2-testing.git that have 
qemu 1.1), videoram setting with cirrus does not give error.
I think is good to backport this patch also on 4.2.x to prevent setting 
of videoram < 8 mb and support cirrus memory setting if qemu is >=1.3 
(some distro or user probably will have xen 4.2.x with qemu>=1.3).

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:49:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15: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 1U37FR-0003DM-2U; Wed, 06 Feb 2013 15:49:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1U37FP-0003DH-UH
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:49:20 +0000
Received: from [193.109.254.147:29056] by server-6.bemta-14.messagelabs.com id
	0F/C5-12010-F7B72115; Wed, 06 Feb 2013 15:49:19 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360165757!9356779!1
X-Originating-IP: [209.85.220.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22619 invoked from network); 6 Feb 2013 15:49:18 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:49:18 -0000
Received: by mail-vc0-f181.google.com with SMTP id d16so952298vcd.12
	for <Xen-devel@lists.xensource.com>;
	Wed, 06 Feb 2013 07:49:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=a1MVgZsnG1p4rZzKCwH5558+cfT7TDfUUYLtQh9dtn8=;
	b=RADPB9OuT763BGc2WAHqwnZNYyGzICl4mT1+CzaE/bLqCo5DPBa4+0Dn1poxZ6Odzm
	BkPqOz9Y7+QxhbI++G6J4spWvdzZ3bRIUOO/4hVcaNXaT3LfaqU/GXq4WMfCxfcPCT59
	ULqCiVcs+rITg3mk+3GR7Bu+NsLywpzWzqSg4osa0ZrGBtGcTjh63lRJJW94O4rMBlmZ
	f6g4OHwxxpjU0b49gUgc+nCwq5gV1rdu/kaL4YsfOcG8CyyArbHKG2hmW7ypbi9oiGo/
	BsQvrv5QGWThjd3Znlpz8JG2oOHPC8KzoL0NWk6sPCFjvroDgrstmJ4kNlLLTS0tzIcx
	zD4Q==
X-Received: by 10.52.71.174 with SMTP id w14mr29105089vdu.122.1360165757010;
	Wed, 06 Feb 2013 07:49:17 -0800 (PST)
Received: from konrad-lan.dumpdata.com (c-67-186-155-227.hsd1.ct.comcast.net.
	[67.186.155.227])
	by mx.google.com with ESMTPS id yu4sm33047652veb.7.2013.02.06.07.49.15
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:49:16 -0800 (PST)
Date: Wed, 6 Feb 2013 10:49:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130206154910.GA31828@konrad-lan.dumpdata.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130131183015.13bc2bff@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

On Thu, Jan 31, 2013 at 06:30:15PM -0800, Mukesh Rathor wrote:
> This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
> allocate pfns for grant table pages instead of kmalloc. This also
> simplifies add to physmap on the xen side a bit.

Pulled this.
> 
> Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
> 
> ---
>  drivers/xen/grant-table.c |   37 ++++++++++++++++++++++++++-----------
>  1 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 9c0019d..d731f39 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -47,6 +47,7 @@
>  #include <xen/grant_table.h>
>  #include <xen/interface/memory.h>
>  #include <xen/hvc-console.h>
> +#include <xen/balloon.h>
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/interface.h>
>  
> @@ -1138,27 +1139,41 @@ static void gnttab_request_version(void)
>  		grant_table_version);
>  }
>  
> +static int xlated_setup_gnttab_pages(int numpages, void **addr)
> +{
> +	int i, rc;
> +	unsigned long pfns[numpages];
> +	struct page *pages[numpages];
> +
> +	rc = alloc_xenballooned_pages(numpages, pages, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,
> +			numpages, rc);
> +		return -ENOMEM;
> +	}
> +	for (i = 0; i < numpages; i++)
> +		pfns[i] = page_to_pfn(pages[i]);
> +
> +	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
> +	return rc;
> +}
> +
>  int gnttab_resume(void)
>  {
> -	unsigned int max_nr_gframes;
> -	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
> +	unsigned int rc, max_nr_gframes;
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> -	/* PVH note: xen will free existing kmalloc'd mfn in
> -	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> -	 * kmalloc(). */
>  	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
>  	    !gnttab_shared.addr) {
> -		gnttab_shared.addr =
> -			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> -		if (!gnttab_shared.addr) {
> -			pr_warn("%s", kmsg);
> -			return -ENOMEM;
> -		}
> +
> +		rc = xlated_setup_gnttab_pages(max_nr_gframes,
> +					       &gnttab_shared.addr);
> +		if (rc != 0)
> +			return rc;
>  	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
> -- 
> 1.7.2.3
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:49:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15: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 1U37FR-0003DM-2U; Wed, 06 Feb 2013 15:49:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1U37FP-0003DH-UH
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 15:49:20 +0000
Received: from [193.109.254.147:29056] by server-6.bemta-14.messagelabs.com id
	0F/C5-12010-F7B72115; Wed, 06 Feb 2013 15:49:19 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360165757!9356779!1
X-Originating-IP: [209.85.220.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22619 invoked from network); 6 Feb 2013 15:49:18 -0000
Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com)
	(209.85.220.181)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:49:18 -0000
Received: by mail-vc0-f181.google.com with SMTP id d16so952298vcd.12
	for <Xen-devel@lists.xensource.com>;
	Wed, 06 Feb 2013 07:49:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=a1MVgZsnG1p4rZzKCwH5558+cfT7TDfUUYLtQh9dtn8=;
	b=RADPB9OuT763BGc2WAHqwnZNYyGzICl4mT1+CzaE/bLqCo5DPBa4+0Dn1poxZ6Odzm
	BkPqOz9Y7+QxhbI++G6J4spWvdzZ3bRIUOO/4hVcaNXaT3LfaqU/GXq4WMfCxfcPCT59
	ULqCiVcs+rITg3mk+3GR7Bu+NsLywpzWzqSg4osa0ZrGBtGcTjh63lRJJW94O4rMBlmZ
	f6g4OHwxxpjU0b49gUgc+nCwq5gV1rdu/kaL4YsfOcG8CyyArbHKG2hmW7ypbi9oiGo/
	BsQvrv5QGWThjd3Znlpz8JG2oOHPC8KzoL0NWk6sPCFjvroDgrstmJ4kNlLLTS0tzIcx
	zD4Q==
X-Received: by 10.52.71.174 with SMTP id w14mr29105089vdu.122.1360165757010;
	Wed, 06 Feb 2013 07:49:17 -0800 (PST)
Received: from konrad-lan.dumpdata.com (c-67-186-155-227.hsd1.ct.comcast.net.
	[67.186.155.227])
	by mx.google.com with ESMTPS id yu4sm33047652veb.7.2013.02.06.07.49.15
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:49:16 -0800 (PST)
Date: Wed, 6 Feb 2013 10:49:13 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130206154910.GA31828@konrad-lan.dumpdata.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130131183015.13bc2bff@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

On Thu, Jan 31, 2013 at 06:30:15PM -0800, Mukesh Rathor wrote:
> This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
> allocate pfns for grant table pages instead of kmalloc. This also
> simplifies add to physmap on the xen side a bit.

Pulled this.
> 
> Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
> 
> ---
>  drivers/xen/grant-table.c |   37 ++++++++++++++++++++++++++-----------
>  1 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 9c0019d..d731f39 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -47,6 +47,7 @@
>  #include <xen/grant_table.h>
>  #include <xen/interface/memory.h>
>  #include <xen/hvc-console.h>
> +#include <xen/balloon.h>
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/interface.h>
>  
> @@ -1138,27 +1139,41 @@ static void gnttab_request_version(void)
>  		grant_table_version);
>  }
>  
> +static int xlated_setup_gnttab_pages(int numpages, void **addr)
> +{
> +	int i, rc;
> +	unsigned long pfns[numpages];
> +	struct page *pages[numpages];
> +
> +	rc = alloc_xenballooned_pages(numpages, pages, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,
> +			numpages, rc);
> +		return -ENOMEM;
> +	}
> +	for (i = 0; i < numpages; i++)
> +		pfns[i] = page_to_pfn(pages[i]);
> +
> +	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
> +	return rc;
> +}
> +
>  int gnttab_resume(void)
>  {
> -	unsigned int max_nr_gframes;
> -	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
> +	unsigned int rc, max_nr_gframes;
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> -	/* PVH note: xen will free existing kmalloc'd mfn in
> -	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> -	 * kmalloc(). */
>  	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
>  	    !gnttab_shared.addr) {
> -		gnttab_shared.addr =
> -			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> -		if (!gnttab_shared.addr) {
> -			pr_warn("%s", kmsg);
> -			return -ENOMEM;
> -		}
> +
> +		rc = xlated_setup_gnttab_pages(max_nr_gframes,
> +					       &gnttab_shared.addr);
> +		if (rc != 0)
> +			return rc;
>  	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
> -- 
> 1.7.2.3
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:49:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15: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 1U37Fh-0003E5-Fb; Wed, 06 Feb 2013 15:49:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1U37Fg-0003Dz-3D
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:49:36 +0000
Received: from [85.158.143.35:8578] by server-2.bemta-4.messagelabs.com id
	DE/8B-01597-F8B72115; Wed, 06 Feb 2013 15:49:35 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360165773!5794664!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8930 invoked from network); 6 Feb 2013 15:49:34 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:49:34 -0000
Received: by mail-vc0-f174.google.com with SMTP id n11so952694vch.33
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 07:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=OAW3o+70N5dKfEuegXxdosf2eytJpHP995PPC5jRQVI=;
	b=iIJ/B+7txdThdyjy+0JHwhgo/QWpssDC8tfM1A9dDQHlt/4V33JRl6MSFm31smiSE9
	7lL4JVQAQpW7yCl39/I0CV5GXC/kUd5Nh7NPocdZckZsDg+CM78Rv7rAJS+u55lYmmp6
	3diScrbei7P4E9p0SbHuJvF3kAebOjmGmuBXxu+lmrXBN/jbKyeP+VNFtV783yaFxk8O
	DgyWouvj9RIOJtCt7ayAO303pJJ5NPsrHG8rhnV6FYrEfIXJPrsolNnhFI7bc5GSilfP
	pM7yk9IgfahupBso7ePLEyNE3SRPlG6/zHYJbkCiLvyzFhi5D4l0lUV1JQp6H/gyLntc
	vhug==
X-Received: by 10.52.90.100 with SMTP id bv4mr29241747vdb.48.1360165772914;
	Wed, 06 Feb 2013 07:49:32 -0800 (PST)
Received: from konrad-lan.dumpdata.com (c-67-186-155-227.hsd1.ct.comcast.net.
	[67.186.155.227])
	by mx.google.com with ESMTPS id yu12sm16884441vec.6.2013.02.06.07.49.31
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:49:32 -0800 (PST)
Date: Wed, 6 Feb 2013 10:49:29 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130206154929.GB31828@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: david.vrabel@citrix.com, konrad.wilk@oracle.com, ian.campbell@citrix.com,
	jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 31, 2013 at 02:46:56PM +0000, Wei Liu wrote:
> It is possible that the call to xen_allocate_irq_dynamic() returns negative
> number other than -1.

Applied.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 2c94aad..93a3648 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -820,7 +820,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>  
>  	if (irq == -1) {
>  		irq = xen_allocate_irq_dynamic();
> -		if (irq == -1)
> +		if (irq < 0)
>  			goto out;
>  
>  		irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
> @@ -923,7 +923,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
>  
>  	if (irq == -1) {
>  		irq = xen_allocate_irq_dynamic();
> -		if (irq == -1)
> +		if (irq < 0)
>  			goto out;
>  
>  		irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 15:49:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 15: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 1U37Fh-0003E5-Fb; Wed, 06 Feb 2013 15:49:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.r.wilk@gmail.com>) id 1U37Fg-0003Dz-3D
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 15:49:36 +0000
Received: from [85.158.143.35:8578] by server-2.bemta-4.messagelabs.com id
	DE/8B-01597-F8B72115; Wed, 06 Feb 2013 15:49:35 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360165773!5794664!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8930 invoked from network); 6 Feb 2013 15:49:34 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 15:49:34 -0000
Received: by mail-vc0-f174.google.com with SMTP id n11so952694vch.33
	for <xen-devel@lists.xen.org>; Wed, 06 Feb 2013 07:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=OAW3o+70N5dKfEuegXxdosf2eytJpHP995PPC5jRQVI=;
	b=iIJ/B+7txdThdyjy+0JHwhgo/QWpssDC8tfM1A9dDQHlt/4V33JRl6MSFm31smiSE9
	7lL4JVQAQpW7yCl39/I0CV5GXC/kUd5Nh7NPocdZckZsDg+CM78Rv7rAJS+u55lYmmp6
	3diScrbei7P4E9p0SbHuJvF3kAebOjmGmuBXxu+lmrXBN/jbKyeP+VNFtV783yaFxk8O
	DgyWouvj9RIOJtCt7ayAO303pJJ5NPsrHG8rhnV6FYrEfIXJPrsolNnhFI7bc5GSilfP
	pM7yk9IgfahupBso7ePLEyNE3SRPlG6/zHYJbkCiLvyzFhi5D4l0lUV1JQp6H/gyLntc
	vhug==
X-Received: by 10.52.90.100 with SMTP id bv4mr29241747vdb.48.1360165772914;
	Wed, 06 Feb 2013 07:49:32 -0800 (PST)
Received: from konrad-lan.dumpdata.com (c-67-186-155-227.hsd1.ct.comcast.net.
	[67.186.155.227])
	by mx.google.com with ESMTPS id yu12sm16884441vec.6.2013.02.06.07.49.31
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 06 Feb 2013 07:49:32 -0800 (PST)
Date: Wed, 6 Feb 2013 10:49:29 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130206154929.GB31828@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359643627-29486-3-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: david.vrabel@citrix.com, konrad.wilk@oracle.com, ian.campbell@citrix.com,
	jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/13] xen: fix error handling path if
 xen_allocate_irq_dynamic fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 31, 2013 at 02:46:56PM +0000, Wei Liu wrote:
> It is possible that the call to xen_allocate_irq_dynamic() returns negative
> number other than -1.

Applied.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/xen/events.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 2c94aad..93a3648 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -820,7 +820,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>  
>  	if (irq == -1) {
>  		irq = xen_allocate_irq_dynamic();
> -		if (irq == -1)
> +		if (irq < 0)
>  			goto out;
>  
>  		irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
> @@ -923,7 +923,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
>  
>  	if (irq == -1) {
>  		irq = xen_allocate_irq_dynamic();
> -		if (irq == -1)
> +		if (irq < 0)
>  			goto out;
>  
>  		irq_set_chip_and_handler_name(irq, &xen_percpu_chip,
> -- 
> 1.7.10.4
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:08:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XS-0004YN-VX; Wed, 06 Feb 2013 16:07:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XR-0004Xo-IF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:57 +0000
Received: from [85.158.143.35:37062] by server-1.bemta-4.messagelabs.com id
	08/B2-08839-CDF72115; Wed, 06 Feb 2013 16:07:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360166873!5797786!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7918 invoked from network); 6 Feb 2013 16:07:56 -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;
	6 Feb 2013 16:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6496156"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-7j;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:37 +0000
Message-ID: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v6] Coverage 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

Updated set of patches for coverage.

Changes:
- fix ARM constructors section
- removed patch to check constructors, useless


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:08:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XS-0004YN-VX; Wed, 06 Feb 2013 16:07:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XR-0004Xo-IF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:57 +0000
Received: from [85.158.143.35:37062] by server-1.bemta-4.messagelabs.com id
	08/B2-08839-CDF72115; Wed, 06 Feb 2013 16:07:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360166873!5797786!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7918 invoked from network); 6 Feb 2013 16:07:56 -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;
	6 Feb 2013 16:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6496156"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-7j;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:37 +0000
Message-ID: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v6] Coverage 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

Updated set of patches for coverage.

Changes:
- fix ARM constructors section
- removed patch to check constructors, useless


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:08:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XR-0004Xq-IK; Wed, 06 Feb 2013 16:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XQ-0004Xb-PF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:56 +0000
Received: from [85.158.143.35:37029] by server-3.bemta-4.messagelabs.com id
	66/69-08920-CDF72115; Wed, 06 Feb 2013 16:07:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360166873!5797786!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7872 invoked from network); 6 Feb 2013 16:07:55 -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;
	6 Feb 2013 16:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6496155"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-9R;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:38 +0000
Message-ID: <1360166741-28150-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Call constructors during initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Wed Feb 06 16:08:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XR-0004Xq-IK; Wed, 06 Feb 2013 16:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XQ-0004Xb-PF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:56 +0000
Received: from [85.158.143.35:37029] by server-3.bemta-4.messagelabs.com id
	66/69-08920-CDF72115; Wed, 06 Feb 2013 16:07:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360166873!5797786!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7872 invoked from network); 6 Feb 2013 16:07:55 -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;
	6 Feb 2013 16:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6496155"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-9R;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:38 +0000
Message-ID: <1360166741-28150-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] Call constructors during initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Wed Feb 06 16:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XT-0004Z0-U0; Wed, 06 Feb 2013 16:07:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XS-0004Y0-9B
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:58 +0000
Received: from [85.158.139.211:15871] by server-2.bemta-5.messagelabs.com id
	B4/7F-16911-DDF72115; Wed, 06 Feb 2013 16:07:57 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360166873!21364594!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23007 invoked from network); 6 Feb 2013 16:07:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6176421"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-Ct;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:40 +0000
Message-ID: <1360166741-28150-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  158 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 328 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 733d020..bb85523 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -63,6 +64,159 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..53a192c
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..ad5cd9d 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,16 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 16:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XT-0004Z0-U0; Wed, 06 Feb 2013 16:07:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XS-0004Y0-9B
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:58 +0000
Received: from [85.158.139.211:15871] by server-2.bemta-5.messagelabs.com id
	B4/7F-16911-DDF72115; Wed, 06 Feb 2013 16:07:57 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360166873!21364594!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23007 invoked from network); 6 Feb 2013 16:07:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6176421"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-Ct;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:40 +0000
Message-ID: <1360166741-28150-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] Implement code to read coverage informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  158 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 328 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 733d020..bb85523 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -63,6 +64,159 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_enabled:
+        break;
+
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..53a192c
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..5e80400 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Check if coverage informations are available
+ * return just success or error, no parameters
+ */
+#define XEN_SYSCTL_COVERAGE_enabled        0
+
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 1
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them
+ */
+#define XEN_SYSCTL_COVERAGE_read           2
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..ad5cd9d 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,16 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 16:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XU-0004Z9-B8; Wed, 06 Feb 2013 16:08:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XS-0004YD-VO
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:59 +0000
Received: from [85.158.139.211:19891] by server-7.bemta-5.messagelabs.com id
	BA/63-11121-EDF72115; Wed, 06 Feb 2013 16:07:58 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360166873!21364594!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23039 invoked from network); 6 Feb 2013 16:07:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:07:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6176422"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-DP;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:41 +0000
Message-ID: <1360166741-28150-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  141 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 149 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..5e7f440
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,141 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_read, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read} [<filename>]\n"
+        "\treset     reset information\n"
+        "\tread      read information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    /* check support */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_enabled, NULL) < 0 )
+        err(1, "checking coverage support");
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-");
+    else
+        usage();
+
+    return 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 Wed Feb 06 16:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XU-0004Z9-B8; Wed, 06 Feb 2013 16:08:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XS-0004YD-VO
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:59 +0000
Received: from [85.158.139.211:19891] by server-7.bemta-5.messagelabs.com id
	BA/63-11121-EDF72115; Wed, 06 Feb 2013 16:07:58 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360166873!21364594!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23039 invoked from network); 6 Feb 2013 16:07:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:07:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6176422"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-DP;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:41 +0000
Message-ID: <1360166741-28150-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  141 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 149 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..5e7f440
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,141 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_read, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read} [<filename>]\n"
+        "\treset     reset information\n"
+        "\tread      read information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    /* check support */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_enabled, NULL) < 0 )
+        err(1, "checking coverage support");
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-");
+    else
+        usage();
+
+    return 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 Wed Feb 06 16:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XT-0004YX-Au; Wed, 06 Feb 2013 16:07:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XR-0004Xi-Jk
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:57 +0000
Received: from [85.158.139.211:11425] by server-4.bemta-5.messagelabs.com id
	44/9B-29496-CDF72115; Wed, 06 Feb 2013 16:07:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360166873!21364594!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22956 invoked from network); 6 Feb 2013 16:07:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6176420"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-B5;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:39 +0000
Message-ID: <1360166741-28150-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   74 ++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 171 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..733d020
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,74 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 16:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:08: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 1U37XT-0004YX-Au; Wed, 06 Feb 2013 16:07:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37XR-0004Xi-Jk
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:07:57 +0000
Received: from [85.158.139.211:11425] by server-4.bemta-5.messagelabs.com id
	44/9B-29496-CDF72115; Wed, 06 Feb 2013 16:07:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360166873!21364594!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDE5MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22956 invoked from network); 6 Feb 2013 16:07:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6176420"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:07:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:07:52 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U37XM-0002au-B5;
	Wed, 06 Feb 2013 16:07:52 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:05:39 +0000
Message-ID: <1360166741-28150-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360166741-28150-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] Adding support for coverage information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   74 ++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 171 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..733d020
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,74 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Wed Feb 06 16:10:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:10: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 1U37Zn-0005BY-Ur; Wed, 06 Feb 2013 16:10:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37Zm-0005BI-27
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:10:22 +0000
Received: from [85.158.143.35:48219] by server-3.bemta-4.messagelabs.com id
	F1/8C-08920-D6082115; Wed, 06 Feb 2013 16:10:21 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360167011!11332396!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9485 invoked from network); 6 Feb 2013 16:10:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:10:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="1206174"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 16:10:11 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 6 Feb 2013
	16:10:10 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Wed, 6 Feb 2013 16:10:09 +0000
Thread-Topic: [PATCH 4/5] Check no constructor section
Thread-Index: Ac4EhHAPIABQ1GqTS9+1waRtDk+OWA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836D@LONPMAILBOX01.citrite.net>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
	<51127E6302000078000BC834@nat28.tlf.novell.com>
In-Reply-To: <51127E6302000078000BC834@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 15:01 +0000, Jan Beulich wrote:
> >>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > Safety check for initialization objects.
> > Constructors are not used so check some module does not use them.
> 
> Once again - why?
> 
> And repeating earlier complaints of mine - why do you continue to
> re-post without having addressed all comments on prior revisions
> (verbally or by changing the patches)? This is just wasting
> reviewers' time.
> 
> Jan
> 

Nothing personal, I'm just a bad mail reader. In this case I checked
mails filtering with "cover" but your reply didn't have it on the
subject.

Sometimes I search if there are courses for reading mail but strangely
there are only courses on how use use some mail products or how to write
them.

Frediano

> > Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> > ---
> >  xen/Rules.mk |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index 3f0b262..ae35a08 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 
> > 8,rodata.str1.$(n)) \
> >  $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
> >  	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; 
> > do \
> >  		case "$$name" in \
> > -		.text|.text.*|.data|.data.*|.bss) \
> > +		.text|.text.*|.data|.data.*|.bss|.ctors) \
> >  			test $$sz != 0 || continue; \
> >  			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
> >  			exit $$(expr $$idx + 1);; \
> > -- 
> > 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 Wed Feb 06 16:10:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:10: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 1U37Zn-0005BY-Ur; Wed, 06 Feb 2013 16:10:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U37Zm-0005BI-27
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:10:22 +0000
Received: from [85.158.143.35:48219] by server-3.bemta-4.messagelabs.com id
	F1/8C-08920-D6082115; Wed, 06 Feb 2013 16:10:21 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360167011!11332396!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9485 invoked from network); 6 Feb 2013 16:10:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 16:10:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="1206174"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 16:10:11 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 6 Feb 2013
	16:10:10 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "JBeulich@suse.com" <JBeulich@suse.com>
Date: Wed, 6 Feb 2013 16:10:09 +0000
Thread-Topic: [PATCH 4/5] Check no constructor section
Thread-Index: Ac4EhHAPIABQ1GqTS9+1waRtDk+OWA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836D@LONPMAILBOX01.citrite.net>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
	<51127E6302000078000BC834@nat28.tlf.novell.com>
In-Reply-To: <51127E6302000078000BC834@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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 15:01 +0000, Jan Beulich wrote:
> >>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
> > Safety check for initialization objects.
> > Constructors are not used so check some module does not use them.
> 
> Once again - why?
> 
> And repeating earlier complaints of mine - why do you continue to
> re-post without having addressed all comments on prior revisions
> (verbally or by changing the patches)? This is just wasting
> reviewers' time.
> 
> Jan
> 

Nothing personal, I'm just a bad mail reader. In this case I checked
mails filtering with "cover" but your reply didn't have it on the
subject.

Sometimes I search if there are courses for reading mail but strangely
there are only courses on how use use some mail products or how to write
them.

Frediano

> > Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> > ---
> >  xen/Rules.mk |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index 3f0b262..ae35a08 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -166,7 +166,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach n,1 2 4 
> > 8,rodata.str1.$(n)) \
> >  $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
> >  	$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p}' | while read idx name sz rest; 
> > do \
> >  		case "$$name" in \
> > -		.text|.text.*|.data|.data.*|.bss) \
> > +		.text|.text.*|.data|.data.*|.bss|.ctors) \
> >  			test $$sz != 0 || continue; \
> >  			echo "Error: size of $<:$$name is 0x$$sz" >&2; \
> >  			exit $$(expr $$idx + 1);; \
> > -- 
> > 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 Wed Feb 06 16:13:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16: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 1U37ct-0005nw-Iv; Wed, 06 Feb 2013 16:13:35 +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 1U37ct-0005nV-1P
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:13:35 +0000
Received: from [193.109.254.147:14327] by server-6.bemta-14.messagelabs.com id
	21/A3-12010-E2182115; Wed, 06 Feb 2013 16:13:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360167210!1407456!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7113 invoked from network); 6 Feb 2013 16:13:32 -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;
	6 Feb 2013 16:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6497023"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:12:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:12:09 -0500
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 1U37bV-0002ib-5X;
	Wed, 06 Feb 2013 16:12:09 +0000
Message-ID: <51127F20.8010604@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:04:48 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
	<51127E6302000078000BC834@nat28.tlf.novell.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D45836D@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836D@LONPMAILBOX01.citrite.net>
Cc: "konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 06/02/13 16:10, Frediano Ziglio wrote:
> On Wed, 2013-02-06 at 15:01 +0000, Jan Beulich wrote:
>>>>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
>>> Safety check for initialization objects.
>>> Constructors are not used so check some module does not use them.
>> Once again - why?
>>
>> And repeating earlier complaints of mine - why do you continue to
>> re-post without having addressed all comments on prior revisions
>> (verbally or by changing the patches)? This is just wasting
>> reviewers' time.
>>
>> Jan
>>
> Nothing personal, I'm just a bad mail reader. In this case I checked
> mails filtering with "cover" but your reply didn't have it on the
> subject.

If that's going to be your modus operandi, then *you* need to put the 
search term in your subject line; for example, by making your one-line 
summary "cover: Check no constructor section"

  -George

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:13:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16: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 1U37ct-0005nw-Iv; Wed, 06 Feb 2013 16:13:35 +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 1U37ct-0005nV-1P
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:13:35 +0000
Received: from [193.109.254.147:14327] by server-6.bemta-14.messagelabs.com id
	21/A3-12010-E2182115; Wed, 06 Feb 2013 16:13:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360167210!1407456!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7113 invoked from network); 6 Feb 2013 16:13:32 -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;
	6 Feb 2013 16:13:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6497023"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 16:12:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 11:12:09 -0500
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 1U37bV-0002ib-5X;
	Wed, 06 Feb 2013 16:12:09 +0000
Message-ID: <51127F20.8010604@eu.citrix.com>
Date: Wed, 6 Feb 2013 16:04:48 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-5-git-send-email-frediano.ziglio@citrix.com>
	<51127E6302000078000BC834@nat28.tlf.novell.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D45836D@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836D@LONPMAILBOX01.citrite.net>
Cc: "konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/5] Check no constructor section
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 06/02/13 16:10, Frediano Ziglio wrote:
> On Wed, 2013-02-06 at 15:01 +0000, Jan Beulich wrote:
>>>>> On 06.02.13 at 15:32, Frediano Ziglio <frediano.ziglio@citrix.com> wrote:
>>> Safety check for initialization objects.
>>> Constructors are not used so check some module does not use them.
>> Once again - why?
>>
>> And repeating earlier complaints of mine - why do you continue to
>> re-post without having addressed all comments on prior revisions
>> (verbally or by changing the patches)? This is just wasting
>> reviewers' time.
>>
>> Jan
>>
> Nothing personal, I'm just a bad mail reader. In this case I checked
> mails filtering with "cover" but your reply didn't have it on the
> subject.

If that's going to be your modus operandi, then *you* need to put the 
search term in your subject line; for example, by making your one-line 
summary "cover: Check no constructor section"

  -George

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:51:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:51: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 1U38D0-00078m-JS; Wed, 06 Feb 2013 16:50:54 +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 1U38Cz-00078h-4O
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:50:53 +0000
Received: from [193.109.254.147:15220] by server-16.bemta-14.messagelabs.com
	id 85/C0-25906-CE982115; Wed, 06 Feb 2013 16:50:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360169448!3525967!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21269 invoked from network); 6 Feb 2013 16:50:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 16:50:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 16:50:47 +0000
Message-Id: <511297F502000078000BC935@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 16:50:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part576719F5.0__="
Subject: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X table
 from PV guest 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>
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.

--=__Part576719F5.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This adds two new physdev operations for Dom0 to invoke when resource
allocation for devices is known to be complete, so that the hypervisor
can arrange for the respective MMIO ranges to be marked read-only
before an eventual guest getting such a device assigned even gets
started, such that it won't be able to set up writable mappings for
these MMIO ranges before Xen has a chance to protect them.

This also addresses another issue with the code being modified here,
in that so far write protection for the address ranges in question got
set up only once during the lifetime of a device (i.e. until either
system shutdown or device hot removal), while teardown happened when
the last interrupt was disposed of by the guest (which at least allowed
the tables to be writable when the device got assigned to a second
guest [instance] after the first terminated).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -656,8 +656,8 @@ static u64 read_pci_mem_bar(u16 seg, u8=20
  * @entries: pointer to an array of struct msix_entry entries
  * @nvec: number of @entries
  *
- * Setup the MSI-X capability structure of device function with a
- * single MSI-X irq. A return of zero indicates the successful setup of
+ * Setup the MSI-X capability structure of device function with the =
requested
+ * number MSI-X irqs. A return of zero indicates the successful setup of
  * requested MSI-X entries with allocated irqs or non-zero for otherwise.
  **/
 static int msix_capability_init(struct pci_dev *dev,
@@ -665,86 +665,69 @@ static int msix_capability_init(struct p
                                 struct msi_desc **desc,
                                 unsigned int nr_entries)
 {
-    struct msi_desc *entry;
-    int pos;
+    struct msi_desc *entry =3D NULL;
+    int pos, vf;
     u16 control;
-    u64 table_paddr, entry_paddr;
-    u32 table_offset, entry_offset;
-    u8 bir;
-    void __iomem *base;
-    int idx;
+    u64 table_paddr;
+    u32 table_offset;
+    u8 bir, pbus, pslot, pfunc;
     u16 seg =3D dev->seg;
     u8 bus =3D dev->bus;
     u8 slot =3D PCI_SLOT(dev->devfn);
     u8 func =3D PCI_FUNC(dev->devfn);
=20
     ASSERT(spin_is_locked(&pcidevs_lock));
-    ASSERT(desc);
=20
     pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
     control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos=
));
     msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up */
=20
-    /* MSI-X Table Initialization */
-    entry =3D alloc_msi_entry();
-    if ( !entry )
-        return -ENOMEM;
+    if ( desc )
+    {
+        entry =3D alloc_msi_entry();
+        if ( !entry )
+            return -ENOMEM;
+        ASSERT(msi);
+    }
=20
-    /* Request & Map MSI-X table region */
+    /* Locate MSI-X table region */
     table_offset =3D pci_conf_read32(seg, bus, slot, func,
                                    msix_table_offset_reg(pos));
     bir =3D (u8)(table_offset & PCI_MSIX_BIRMASK);
     table_offset &=3D ~PCI_MSIX_BIRMASK;
-    entry_offset =3D msi->entry_nr * PCI_MSIX_ENTRY_SIZE;
=20
-    table_paddr =3D msi->table_base + table_offset;
-    entry_paddr =3D table_paddr + entry_offset;
-    idx =3D msix_get_fixmap(dev, table_paddr, entry_paddr);
-    if ( idx < 0 )
-    {
-        xfree(entry);
-        return idx;
-    }
-    base =3D (void *)(fix_to_virt(idx) +
-        ((unsigned long)entry_paddr & ((1UL << PAGE_SHIFT) - 1)));
-
-    entry->msi_attrib.type =3D PCI_CAP_ID_MSIX;
-    entry->msi_attrib.is_64 =3D 1;
-    entry->msi_attrib.entry_nr =3D msi->entry_nr;
-    entry->msi_attrib.maskbit =3D 1;
-    entry->msi_attrib.masked =3D 1;
-    entry->msi_attrib.pos =3D pos;
-    entry->irq =3D msi->irq;
-    entry->dev =3D dev;
-    entry->mask_base =3D base;
-
-    list_add_tail(&entry->list, &dev->msi_list);
-
-    if ( !dev->msix_nr_entries )
+    if ( !dev->info.is_virtfn )
     {
-        u8 pbus, pslot, pfunc;
-        int vf;
-        u64 pba_paddr;
-        u32 pba_offset;
+        pbus =3D bus;
+        pslot =3D slot;
+        pfunc =3D func;
+        vf =3D -1;
+    }
+    else
+    {
+        pbus =3D dev->info.physfn.bus;
+        pslot =3D PCI_SLOT(dev->info.physfn.devfn);
+        pfunc =3D PCI_FUNC(dev->info.physfn.devfn);
+        vf =3D PCI_BDF2(dev->bus, dev->devfn);
+    }
=20
-        if ( !dev->info.is_virtfn )
-        {
-            pbus =3D bus;
-            pslot =3D slot;
-            pfunc =3D func;
-            vf =3D -1;
-        }
-        else
+    table_paddr =3D read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf);
+    WARN_ON(msi && msi->table_base !=3D table_paddr);
+    if ( !table_paddr )
+    {
+        if ( !msi || !msi->table_base )
         {
-            pbus =3D dev->info.physfn.bus;
-            pslot =3D PCI_SLOT(dev->info.physfn.devfn);
-            pfunc =3D PCI_FUNC(dev->info.physfn.devfn);
-            vf =3D PCI_BDF2(dev->bus, dev->devfn);
+            xfree(entry);
+            return -ENXIO;
         }
+        table_paddr =3D msi->table_base;
+    }
+    table_paddr +=3D table_offset;
=20
-        ASSERT(!dev->msix_used_entries);
-        WARN_ON(msi->table_base !=3D
-                read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf));
+    if ( !dev->msix_used_entries )
+    {
+        u64 pba_paddr;
+        u32 pba_offset;
=20
         dev->msix_nr_entries =3D nr_entries;
         dev->msix_table.first =3D PFN_DOWN(table_paddr);
@@ -765,7 +748,42 @@ static int msix_capability_init(struct p
                                       BITS_TO_LONGS(nr_entries) - 1);
         WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, dev->msix_pba.firs=
t,
                                         dev->msix_pba.last));
+    }
=20
+    if ( entry )
+    {
+        /* Map MSI-X table region */
+        u64 entry_paddr =3D table_paddr + msi->entry_nr * PCI_MSIX_ENTRY_S=
IZE;
+        int idx =3D msix_get_fixmap(dev, table_paddr, entry_paddr);
+        void __iomem *base;
+
+        if ( idx < 0 )
+        {
+            xfree(entry);
+            return idx;
+        }
+        base =3D (void *)(fix_to_virt(idx) +
+                        ((unsigned long)entry_paddr & (PAGE_SIZE - 1)));
+
+        /* Mask interrupt here */
+        writel(1, base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
+        entry->msi_attrib.type =3D PCI_CAP_ID_MSIX;
+        entry->msi_attrib.is_64 =3D 1;
+        entry->msi_attrib.entry_nr =3D msi->entry_nr;
+        entry->msi_attrib.maskbit =3D 1;
+        entry->msi_attrib.masked =3D 1;
+        entry->msi_attrib.pos =3D pos;
+        entry->irq =3D msi->irq;
+        entry->dev =3D dev;
+        entry->mask_base =3D base;
+
+        list_add_tail(&entry->list, &dev->msi_list);
+        *desc =3D entry;
+    }
+
+    if ( !dev->msix_used_entries )
+    {
         if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
                                 dev->msix_table.last) )
             WARN();
@@ -776,7 +794,7 @@ static int msix_capability_init(struct p
         if ( dev->domain )
             p2m_change_entry_type_global(dev->domain,
                                          p2m_mmio_direct, p2m_mmio_direct)=
;
-        if ( !dev->domain || !paging_mode_translate(dev->domain) )
+        if ( desc && (!dev->domain || !paging_mode_translate(dev->domain))=
 )
         {
             struct domain *d =3D dev->domain;
=20
@@ -790,6 +808,13 @@ static int msix_capability_init(struct p
                         break;
             if ( d )
             {
+                if ( !IS_PRIV(d) && dev->msix_warned !=3D d->domain_id )
+                {
+                    dev->msix_warned =3D d->domain_id;
+                    printk(XENLOG_ERR
+                           "Potentially insecure use of MSI-X on =
%04x:%02x:%02x.%u by Dom%d\n",
+                           seg, bus, slot, func, d->domain_id);
+                }
                 /* XXX How to deal with existing mappings? */
             }
         }
@@ -798,10 +823,6 @@ static int msix_capability_init(struct p
     WARN_ON(dev->msix_table.first !=3D (table_paddr >> PAGE_SHIFT));
     ++dev->msix_used_entries;
=20
-    /* Mask interrupt here */
-    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
-
-    *desc =3D entry;
     /* Restore MSI-X enabled bits */
     pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), =
control);
=20
@@ -926,6 +947,19 @@ static int __pci_enable_msix(struct msi_
     return status;
 }
=20
+static void _pci_cleanup_msix(struct pci_dev *dev)
+{
+    if ( !--dev->msix_used_entries )
+    {
+        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
+                                   dev->msix_table.last) )
+            WARN();
+        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
+                                   dev->msix_pba.last) )
+            WARN();
+    }
+}
+
 static void __pci_disable_msix(struct msi_desc *entry)
 {
     struct pci_dev *dev;
@@ -949,15 +983,42 @@ static void __pci_disable_msix(struct ms
=20
     pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), =
control);
=20
-    if ( !--dev->msix_used_entries )
+    _pci_cleanup_msix(dev);
+}
+
+int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off)
+{
+    int rc;
+    struct pci_dev *pdev;
+    u8 slot =3D PCI_SLOT(devfn), func =3D PCI_FUNC(devfn);
+    unsigned int pos =3D pci_find_cap_offset(seg, bus, slot, func,
+                                           PCI_CAP_ID_MSIX);
+
+    if ( !pos )
+        return -ENODEV;
+
+    spin_lock(&pcidevs_lock);
+    pdev =3D pci_get_pdev(seg, bus, devfn);
+    if ( !pdev )
+        rc =3D -ENODEV;
+    else if ( pdev->msix_used_entries !=3D !!off )
+        rc =3D -EBUSY;
+    else if ( off )
     {
-        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
-                                  dev->msix_table.last) )
-            WARN();
-        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
-                                   dev->msix_pba.last) )
-            WARN();
+        _pci_cleanup_msix(pdev);
+        rc =3D 0;
     }
+    else
+    {
+        u16 control =3D pci_conf_read16(seg, bus, slot, func,
+                                      msix_control_reg(pos));
+
+        rc =3D msix_capability_init(pdev, NULL, NULL,
+                                  multi_msix_capable(control));
+    }
+    spin_unlock(&pcidevs_lock);
+
+    return rc;
 }
=20
 /*
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -575,6 +575,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
=20
+    case PHYSDEVOP_prepare_msix:
+    case PHYSDEVOP_release_msix: {
+        struct physdev_pci_device dev;
+
+        if ( copy_from_guest(&dev, arg, 1) )
+            ret =3D -EFAULT;
+        else
+            ret =3D pci_prepare_msix(dev.seg, dev.bus, dev.devfn,
+                                   cmd !=3D PHYSDEVOP_prepare_msix);
+        break;
+    }
+
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
=20
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -76,6 +76,7 @@ struct msi_desc;
 /* Helper functions */
 extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc);
 extern void pci_disable_msi(struct msi_desc *desc);
+extern int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off);
 extern void pci_cleanup_msi(struct pci_dev *pdev);
 extern void setup_msi_handler(struct irq_desc *, struct msi_desc *);
 extern void setup_msi_irq(struct irq_desc *);
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -303,6 +303,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_devi
=20
 #define PHYSDEVOP_pci_device_remove     26
 #define PHYSDEVOP_restore_msi_ext       27
+/*
+ * Dom0 should use these two to announce MMIO resources assigned to
+ * MSI-X capable devices won't (prepare) or may (release) change.
+ */
+#define PHYSDEVOP_prepare_msix          30
+#define PHYSDEVOP_release_msix          31
 struct physdev_pci_device {
     /* IN */
     uint16_t seg;
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -57,6 +57,7 @@ struct pci_dev {
     int msix_table_refcnt[MAX_MSIX_TABLE_PAGES];
     int msix_table_idx[MAX_MSIX_TABLE_PAGES];
     spinlock_t msix_table_lock;
+    domid_t msix_warned;
=20
     struct domain *domain;
     const u16 seg;



--=__Part576719F5.0__=
Content-Type: text/plain; name="x86-MSI-X-fully-hide-table.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-MSI-X-fully-hide-table.patch"

x86/MSI: add mechanism to protect MSI-X table from PV guest accesses=0A=0AT=
his adds two new physdev operations for Dom0 to invoke when resource=0Aallo=
cation for devices is known to be complete, so that the hypervisor=0Acan =
arrange for the respective MMIO ranges to be marked read-only=0Abefore an =
eventual guest getting such a device assigned even gets=0Astarted, such =
that it won't be able to set up writable mappings for=0Athese MMIO ranges =
before Xen has a chance to protect them.=0A=0AThis also addresses another =
issue with the code being modified here,=0Ain that so far write protection =
for the address ranges in question got=0Aset up only once during the =
lifetime of a device (i.e. until either=0Asystem shutdown or device hot =
removal), while teardown happened when=0Athe last interrupt was disposed =
of by the guest (which at least allowed=0Athe tables to be writable when =
the device got assigned to a second=0Aguest [instance] after the first =
terminated).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -656,8 +656,8 @@ =
static u64 read_pci_mem_bar(u16 seg, u8 =0A  * @entries: pointer to an =
array of struct msix_entry entries=0A  * @nvec: number of @entries=0A  =
*=0A- * Setup the MSI-X capability structure of device function with a=0A- =
* single MSI-X irq. A return of zero indicates the successful setup of=0A+ =
* Setup the MSI-X capability structure of device function with the =
requested=0A+ * number MSI-X irqs. A return of zero indicates the =
successful setup of=0A  * requested MSI-X entries with allocated irqs or =
non-zero for otherwise.=0A  **/=0A static int msix_capability_init(struct =
pci_dev *dev,=0A@@ -665,86 +665,69 @@ static int msix_capability_init(struc=
t p=0A                                 struct msi_desc **desc,=0A          =
                       unsigned int nr_entries)=0A {=0A-    struct =
msi_desc *entry;=0A-    int pos;=0A+    struct msi_desc *entry =3D =
NULL;=0A+    int pos, vf;=0A     u16 control;=0A-    u64 table_paddr, =
entry_paddr;=0A-    u32 table_offset, entry_offset;=0A-    u8 bir;=0A-    =
void __iomem *base;=0A-    int idx;=0A+    u64 table_paddr;=0A+    u32 =
table_offset;=0A+    u8 bir, pbus, pslot, pfunc;=0A     u16 seg =3D =
dev->seg;=0A     u8 bus =3D dev->bus;=0A     u8 slot =3D PCI_SLOT(dev->devf=
n);=0A     u8 func =3D PCI_FUNC(dev->devfn);=0A =0A     ASSERT(spin_is_lock=
ed(&pcidevs_lock));=0A-    ASSERT(desc);=0A =0A     pos =3D pci_find_cap_of=
fset(seg, bus, slot, func, PCI_CAP_ID_MSIX);=0A     control =3D pci_conf_re=
ad16(seg, bus, slot, func, msix_control_reg(pos));=0A     msix_set_enable(d=
ev, 0);/* Ensure msix is disabled as I set it up */=0A =0A-    /* MSI-X =
Table Initialization */=0A-    entry =3D alloc_msi_entry();=0A-    if ( =
!entry )=0A-        return -ENOMEM;=0A+    if ( desc )=0A+    {=0A+        =
entry =3D alloc_msi_entry();=0A+        if ( !entry )=0A+            =
return -ENOMEM;=0A+        ASSERT(msi);=0A+    }=0A =0A-    /* Request & =
Map MSI-X table region */=0A+    /* Locate MSI-X table region */=0A     =
table_offset =3D pci_conf_read32(seg, bus, slot, func,=0A                  =
                  msix_table_offset_reg(pos));=0A     bir =3D (u8)(table_of=
fset & PCI_MSIX_BIRMASK);=0A     table_offset &=3D ~PCI_MSIX_BIRMASK;=0A-  =
  entry_offset =3D msi->entry_nr * PCI_MSIX_ENTRY_SIZE;=0A =0A-    =
table_paddr =3D msi->table_base + table_offset;=0A-    entry_paddr =3D =
table_paddr + entry_offset;=0A-    idx =3D msix_get_fixmap(dev, table_paddr=
, entry_paddr);=0A-    if ( idx < 0 )=0A-    {=0A-        xfree(entry);=0A-=
        return idx;=0A-    }=0A-    base =3D (void *)(fix_to_virt(idx) =
+=0A-        ((unsigned long)entry_paddr & ((1UL << PAGE_SHIFT) - =
1)));=0A-=0A-    entry->msi_attrib.type =3D PCI_CAP_ID_MSIX;=0A-    =
entry->msi_attrib.is_64 =3D 1;=0A-    entry->msi_attrib.entry_nr =3D =
msi->entry_nr;=0A-    entry->msi_attrib.maskbit =3D 1;=0A-    entry->msi_at=
trib.masked =3D 1;=0A-    entry->msi_attrib.pos =3D pos;=0A-    entry->irq =
=3D msi->irq;=0A-    entry->dev =3D dev;=0A-    entry->mask_base =3D =
base;=0A-=0A-    list_add_tail(&entry->list, &dev->msi_list);=0A-=0A-    =
if ( !dev->msix_nr_entries )=0A+    if ( !dev->info.is_virtfn )=0A     =
{=0A-        u8 pbus, pslot, pfunc;=0A-        int vf;=0A-        u64 =
pba_paddr;=0A-        u32 pba_offset;=0A+        pbus =3D bus;=0A+        =
pslot =3D slot;=0A+        pfunc =3D func;=0A+        vf =3D -1;=0A+    =
}=0A+    else=0A+    {=0A+        pbus =3D dev->info.physfn.bus;=0A+       =
 pslot =3D PCI_SLOT(dev->info.physfn.devfn);=0A+        pfunc =3D =
PCI_FUNC(dev->info.physfn.devfn);=0A+        vf =3D PCI_BDF2(dev->bus, =
dev->devfn);=0A+    }=0A =0A-        if ( !dev->info.is_virtfn )=0A-       =
 {=0A-            pbus =3D bus;=0A-            pslot =3D slot;=0A-         =
   pfunc =3D func;=0A-            vf =3D -1;=0A-        }=0A-        =
else=0A+    table_paddr =3D read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, =
vf);=0A+    WARN_ON(msi && msi->table_base !=3D table_paddr);=0A+    if ( =
!table_paddr )=0A+    {=0A+        if ( !msi || !msi->table_base )=0A      =
   {=0A-            pbus =3D dev->info.physfn.bus;=0A-            pslot =
=3D PCI_SLOT(dev->info.physfn.devfn);=0A-            pfunc =3D PCI_FUNC(dev=
->info.physfn.devfn);=0A-            vf =3D PCI_BDF2(dev->bus, dev->devfn);=
=0A+            xfree(entry);=0A+            return -ENXIO;=0A         =
}=0A+        table_paddr =3D msi->table_base;=0A+    }=0A+    table_paddr =
+=3D table_offset;=0A =0A-        ASSERT(!dev->msix_used_entries);=0A-     =
   WARN_ON(msi->table_base !=3D=0A-                read_pci_mem_bar(seg, =
pbus, pslot, pfunc, bir, vf));=0A+    if ( !dev->msix_used_entries )=0A+   =
 {=0A+        u64 pba_paddr;=0A+        u32 pba_offset;=0A =0A         =
dev->msix_nr_entries =3D nr_entries;=0A         dev->msix_table.first =3D =
PFN_DOWN(table_paddr);=0A@@ -765,7 +748,42 @@ static int msix_capability_in=
it(struct p=0A                                       BITS_TO_LONGS(nr_entri=
es) - 1);=0A         WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, =
dev->msix_pba.first,=0A                                         dev->msix_p=
ba.last));=0A+    }=0A =0A+    if ( entry )=0A+    {=0A+        /* Map =
MSI-X table region */=0A+        u64 entry_paddr =3D table_paddr + =
msi->entry_nr * PCI_MSIX_ENTRY_SIZE;=0A+        int idx =3D msix_get_fixmap=
(dev, table_paddr, entry_paddr);=0A+        void __iomem *base;=0A+=0A+    =
    if ( idx < 0 )=0A+        {=0A+            xfree(entry);=0A+           =
 return idx;=0A+        }=0A+        base =3D (void *)(fix_to_virt(idx) =
+=0A+                        ((unsigned long)entry_paddr & (PAGE_SIZE - =
1)));=0A+=0A+        /* Mask interrupt here */=0A+        writel(1, base + =
PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);=0A+=0A+        entry->msi_attrib.type =
=3D PCI_CAP_ID_MSIX;=0A+        entry->msi_attrib.is_64 =3D 1;=0A+        =
entry->msi_attrib.entry_nr =3D msi->entry_nr;=0A+        entry->msi_attrib.=
maskbit =3D 1;=0A+        entry->msi_attrib.masked =3D 1;=0A+        =
entry->msi_attrib.pos =3D pos;=0A+        entry->irq =3D msi->irq;=0A+     =
   entry->dev =3D dev;=0A+        entry->mask_base =3D base;=0A+=0A+       =
 list_add_tail(&entry->list, &dev->msi_list);=0A+        *desc =3D =
entry;=0A+    }=0A+=0A+    if ( !dev->msix_used_entries )=0A+    {=0A      =
   if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,=0A       =
                          dev->msix_table.last) )=0A             WARN();=0A=
@@ -776,7 +794,7 @@ static int msix_capability_init(struct p=0A         if =
( dev->domain )=0A             p2m_change_entry_type_global(dev->domain,=0A=
                                          p2m_mmio_direct, p2m_mmio_direct)=
;=0A-        if ( !dev->domain || !paging_mode_translate(dev->domain) =
)=0A+        if ( desc && (!dev->domain || !paging_mode_translate(dev->doma=
in)) )=0A         {=0A             struct domain *d =3D dev->domain;=0A =
=0A@@ -790,6 +808,13 @@ static int msix_capability_init(struct p=0A        =
                 break;=0A             if ( d )=0A             {=0A+       =
         if ( !IS_PRIV(d) && dev->msix_warned !=3D d->domain_id )=0A+      =
          {=0A+                    dev->msix_warned =3D d->domain_id;=0A+  =
                  printk(XENLOG_ERR=0A+                           =
"Potentially insecure use of MSI-X on %04x:%02x:%02x.%u by Dom%d\n",=0A+   =
                        seg, bus, slot, func, d->domain_id);=0A+           =
     }=0A                 /* XXX How to deal with existing mappings? */=0A =
            }=0A         }=0A@@ -798,10 +823,6 @@ static int msix_capabilit=
y_init(struct p=0A     WARN_ON(dev->msix_table.first !=3D (table_paddr >> =
PAGE_SHIFT));=0A     ++dev->msix_used_entries;=0A =0A-    /* Mask =
interrupt here */=0A-    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR=
_CTRL_OFFSET);=0A-=0A-    *desc =3D entry;=0A     /* Restore MSI-X enabled =
bits */=0A     pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos)=
, control);=0A =0A@@ -926,6 +947,19 @@ static int __pci_enable_msix(struct =
msi_=0A     return status;=0A }=0A =0A+static void _pci_cleanup_msix(struct=
 pci_dev *dev)=0A+{=0A+    if ( !--dev->msix_used_entries )=0A+    {=0A+   =
     if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,=0A+ =
                                  dev->msix_table.last) )=0A+            =
WARN();=0A+        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba=
.first,=0A+                                   dev->msix_pba.last) )=0A+    =
        WARN();=0A+    }=0A+}=0A+=0A static void __pci_disable_msix(struct =
msi_desc *entry)=0A {=0A     struct pci_dev *dev;=0A@@ -949,15 +983,42 @@ =
static void __pci_disable_msix(struct ms=0A =0A     pci_conf_write16(seg, =
bus, slot, func, msix_control_reg(pos), control);=0A =0A-    if ( =
!--dev->msix_used_entries )=0A+    _pci_cleanup_msix(dev);=0A+}=0A+=0A+int =
pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off)=0A+{=0A+    int =
rc;=0A+    struct pci_dev *pdev;=0A+    u8 slot =3D PCI_SLOT(devfn), func =
=3D PCI_FUNC(devfn);=0A+    unsigned int pos =3D pci_find_cap_offset(seg, =
bus, slot, func,=0A+                                           PCI_CAP_ID_M=
SIX);=0A+=0A+    if ( !pos )=0A+        return -ENODEV;=0A+=0A+    =
spin_lock(&pcidevs_lock);=0A+    pdev =3D pci_get_pdev(seg, bus, devfn);=0A=
+    if ( !pdev )=0A+        rc =3D -ENODEV;=0A+    else if ( pdev->msix_us=
ed_entries !=3D !!off )=0A+        rc =3D -EBUSY;=0A+    else if ( off =
)=0A     {=0A-        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_=
table.first,=0A-                                  dev->msix_table.last) =
)=0A-            WARN();=0A-        if ( rangeset_remove_range(mmio_ro_rang=
es, dev->msix_pba.first,=0A-                                   dev->msix_pb=
a.last) )=0A-            WARN();=0A+        _pci_cleanup_msix(pdev);=0A+   =
     rc =3D 0;=0A     }=0A+    else=0A+    {=0A+        u16 control =3D =
pci_conf_read16(seg, bus, slot, func,=0A+                                  =
    msix_control_reg(pos));=0A+=0A+        rc =3D msix_capability_init(pdev=
, NULL, NULL,=0A+                                  multi_msix_capable(contr=
ol));=0A+    }=0A+    spin_unlock(&pcidevs_lock);=0A+=0A+    return rc;=0A =
}=0A =0A /*=0A--- a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=
=0A@@ -575,6 +575,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A        =
 break;=0A     }=0A =0A+    case PHYSDEVOP_prepare_msix:=0A+    case =
PHYSDEVOP_release_msix: {=0A+        struct physdev_pci_device dev;=0A+=0A+=
        if ( copy_from_guest(&dev, arg, 1) )=0A+            ret =3D =
-EFAULT;=0A+        else=0A+            ret =3D pci_prepare_msix(dev.seg, =
dev.bus, dev.devfn,=0A+                                   cmd !=3D =
PHYSDEVOP_prepare_msix);=0A+        break;=0A+    }=0A+=0A     case =
PHYSDEVOP_pci_mmcfg_reserved: {=0A         struct physdev_pci_mmcfg_reserve=
d info;=0A =0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/m=
si.h=0A@@ -76,6 +76,7 @@ struct msi_desc;=0A /* Helper functions */=0A =
extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc);=0A=
 extern void pci_disable_msi(struct msi_desc *desc);=0A+extern int =
pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off);=0A extern void =
pci_cleanup_msi(struct pci_dev *pdev);=0A extern void setup_msi_handler(str=
uct irq_desc *, struct msi_desc *);=0A extern void setup_msi_irq(struct =
irq_desc *);=0A--- a/xen/include/public/physdev.h=0A+++ b/xen/include/publi=
c/physdev.h=0A@@ -303,6 +303,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_devi=
=0A =0A #define PHYSDEVOP_pci_device_remove     26=0A #define PHYSDEVOP_res=
tore_msi_ext       27=0A+/*=0A+ * Dom0 should use these two to announce =
MMIO resources assigned to=0A+ * MSI-X capable devices won't (prepare) or =
may (release) change.=0A+ */=0A+#define PHYSDEVOP_prepare_msix          =
30=0A+#define PHYSDEVOP_release_msix          31=0A struct physdev_pci_devi=
ce {=0A     /* IN */=0A     uint16_t seg;=0A--- a/xen/include/xen/pci.h=0A+=
++ b/xen/include/xen/pci.h=0A@@ -57,6 +57,7 @@ struct pci_dev {=0A     int =
msix_table_refcnt[MAX_MSIX_TABLE_PAGES];=0A     int msix_table_idx[MAX_MSIX=
_TABLE_PAGES];=0A     spinlock_t msix_table_lock;=0A+    domid_t msix_warne=
d;=0A =0A     struct domain *domain;=0A     const u16 seg;=0A
--=__Part576719F5.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

--=__Part576719F5.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 16:51:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:51: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 1U38D0-00078m-JS; Wed, 06 Feb 2013 16:50:54 +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 1U38Cz-00078h-4O
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:50:53 +0000
Received: from [193.109.254.147:15220] by server-16.bemta-14.messagelabs.com
	id 85/C0-25906-CE982115; Wed, 06 Feb 2013 16:50:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360169448!3525967!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21269 invoked from network); 6 Feb 2013 16:50:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 16:50:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 16:50:47 +0000
Message-Id: <511297F502000078000BC935@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 16:50:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part576719F5.0__="
Subject: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X table
 from PV guest 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>
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.

--=__Part576719F5.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This adds two new physdev operations for Dom0 to invoke when resource
allocation for devices is known to be complete, so that the hypervisor
can arrange for the respective MMIO ranges to be marked read-only
before an eventual guest getting such a device assigned even gets
started, such that it won't be able to set up writable mappings for
these MMIO ranges before Xen has a chance to protect them.

This also addresses another issue with the code being modified here,
in that so far write protection for the address ranges in question got
set up only once during the lifetime of a device (i.e. until either
system shutdown or device hot removal), while teardown happened when
the last interrupt was disposed of by the guest (which at least allowed
the tables to be writable when the device got assigned to a second
guest [instance] after the first terminated).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -656,8 +656,8 @@ static u64 read_pci_mem_bar(u16 seg, u8=20
  * @entries: pointer to an array of struct msix_entry entries
  * @nvec: number of @entries
  *
- * Setup the MSI-X capability structure of device function with a
- * single MSI-X irq. A return of zero indicates the successful setup of
+ * Setup the MSI-X capability structure of device function with the =
requested
+ * number MSI-X irqs. A return of zero indicates the successful setup of
  * requested MSI-X entries with allocated irqs or non-zero for otherwise.
  **/
 static int msix_capability_init(struct pci_dev *dev,
@@ -665,86 +665,69 @@ static int msix_capability_init(struct p
                                 struct msi_desc **desc,
                                 unsigned int nr_entries)
 {
-    struct msi_desc *entry;
-    int pos;
+    struct msi_desc *entry =3D NULL;
+    int pos, vf;
     u16 control;
-    u64 table_paddr, entry_paddr;
-    u32 table_offset, entry_offset;
-    u8 bir;
-    void __iomem *base;
-    int idx;
+    u64 table_paddr;
+    u32 table_offset;
+    u8 bir, pbus, pslot, pfunc;
     u16 seg =3D dev->seg;
     u8 bus =3D dev->bus;
     u8 slot =3D PCI_SLOT(dev->devfn);
     u8 func =3D PCI_FUNC(dev->devfn);
=20
     ASSERT(spin_is_locked(&pcidevs_lock));
-    ASSERT(desc);
=20
     pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
     control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos=
));
     msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up */
=20
-    /* MSI-X Table Initialization */
-    entry =3D alloc_msi_entry();
-    if ( !entry )
-        return -ENOMEM;
+    if ( desc )
+    {
+        entry =3D alloc_msi_entry();
+        if ( !entry )
+            return -ENOMEM;
+        ASSERT(msi);
+    }
=20
-    /* Request & Map MSI-X table region */
+    /* Locate MSI-X table region */
     table_offset =3D pci_conf_read32(seg, bus, slot, func,
                                    msix_table_offset_reg(pos));
     bir =3D (u8)(table_offset & PCI_MSIX_BIRMASK);
     table_offset &=3D ~PCI_MSIX_BIRMASK;
-    entry_offset =3D msi->entry_nr * PCI_MSIX_ENTRY_SIZE;
=20
-    table_paddr =3D msi->table_base + table_offset;
-    entry_paddr =3D table_paddr + entry_offset;
-    idx =3D msix_get_fixmap(dev, table_paddr, entry_paddr);
-    if ( idx < 0 )
-    {
-        xfree(entry);
-        return idx;
-    }
-    base =3D (void *)(fix_to_virt(idx) +
-        ((unsigned long)entry_paddr & ((1UL << PAGE_SHIFT) - 1)));
-
-    entry->msi_attrib.type =3D PCI_CAP_ID_MSIX;
-    entry->msi_attrib.is_64 =3D 1;
-    entry->msi_attrib.entry_nr =3D msi->entry_nr;
-    entry->msi_attrib.maskbit =3D 1;
-    entry->msi_attrib.masked =3D 1;
-    entry->msi_attrib.pos =3D pos;
-    entry->irq =3D msi->irq;
-    entry->dev =3D dev;
-    entry->mask_base =3D base;
-
-    list_add_tail(&entry->list, &dev->msi_list);
-
-    if ( !dev->msix_nr_entries )
+    if ( !dev->info.is_virtfn )
     {
-        u8 pbus, pslot, pfunc;
-        int vf;
-        u64 pba_paddr;
-        u32 pba_offset;
+        pbus =3D bus;
+        pslot =3D slot;
+        pfunc =3D func;
+        vf =3D -1;
+    }
+    else
+    {
+        pbus =3D dev->info.physfn.bus;
+        pslot =3D PCI_SLOT(dev->info.physfn.devfn);
+        pfunc =3D PCI_FUNC(dev->info.physfn.devfn);
+        vf =3D PCI_BDF2(dev->bus, dev->devfn);
+    }
=20
-        if ( !dev->info.is_virtfn )
-        {
-            pbus =3D bus;
-            pslot =3D slot;
-            pfunc =3D func;
-            vf =3D -1;
-        }
-        else
+    table_paddr =3D read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf);
+    WARN_ON(msi && msi->table_base !=3D table_paddr);
+    if ( !table_paddr )
+    {
+        if ( !msi || !msi->table_base )
         {
-            pbus =3D dev->info.physfn.bus;
-            pslot =3D PCI_SLOT(dev->info.physfn.devfn);
-            pfunc =3D PCI_FUNC(dev->info.physfn.devfn);
-            vf =3D PCI_BDF2(dev->bus, dev->devfn);
+            xfree(entry);
+            return -ENXIO;
         }
+        table_paddr =3D msi->table_base;
+    }
+    table_paddr +=3D table_offset;
=20
-        ASSERT(!dev->msix_used_entries);
-        WARN_ON(msi->table_base !=3D
-                read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf));
+    if ( !dev->msix_used_entries )
+    {
+        u64 pba_paddr;
+        u32 pba_offset;
=20
         dev->msix_nr_entries =3D nr_entries;
         dev->msix_table.first =3D PFN_DOWN(table_paddr);
@@ -765,7 +748,42 @@ static int msix_capability_init(struct p
                                       BITS_TO_LONGS(nr_entries) - 1);
         WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, dev->msix_pba.firs=
t,
                                         dev->msix_pba.last));
+    }
=20
+    if ( entry )
+    {
+        /* Map MSI-X table region */
+        u64 entry_paddr =3D table_paddr + msi->entry_nr * PCI_MSIX_ENTRY_S=
IZE;
+        int idx =3D msix_get_fixmap(dev, table_paddr, entry_paddr);
+        void __iomem *base;
+
+        if ( idx < 0 )
+        {
+            xfree(entry);
+            return idx;
+        }
+        base =3D (void *)(fix_to_virt(idx) +
+                        ((unsigned long)entry_paddr & (PAGE_SIZE - 1)));
+
+        /* Mask interrupt here */
+        writel(1, base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
+        entry->msi_attrib.type =3D PCI_CAP_ID_MSIX;
+        entry->msi_attrib.is_64 =3D 1;
+        entry->msi_attrib.entry_nr =3D msi->entry_nr;
+        entry->msi_attrib.maskbit =3D 1;
+        entry->msi_attrib.masked =3D 1;
+        entry->msi_attrib.pos =3D pos;
+        entry->irq =3D msi->irq;
+        entry->dev =3D dev;
+        entry->mask_base =3D base;
+
+        list_add_tail(&entry->list, &dev->msi_list);
+        *desc =3D entry;
+    }
+
+    if ( !dev->msix_used_entries )
+    {
         if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
                                 dev->msix_table.last) )
             WARN();
@@ -776,7 +794,7 @@ static int msix_capability_init(struct p
         if ( dev->domain )
             p2m_change_entry_type_global(dev->domain,
                                          p2m_mmio_direct, p2m_mmio_direct)=
;
-        if ( !dev->domain || !paging_mode_translate(dev->domain) )
+        if ( desc && (!dev->domain || !paging_mode_translate(dev->domain))=
 )
         {
             struct domain *d =3D dev->domain;
=20
@@ -790,6 +808,13 @@ static int msix_capability_init(struct p
                         break;
             if ( d )
             {
+                if ( !IS_PRIV(d) && dev->msix_warned !=3D d->domain_id )
+                {
+                    dev->msix_warned =3D d->domain_id;
+                    printk(XENLOG_ERR
+                           "Potentially insecure use of MSI-X on =
%04x:%02x:%02x.%u by Dom%d\n",
+                           seg, bus, slot, func, d->domain_id);
+                }
                 /* XXX How to deal with existing mappings? */
             }
         }
@@ -798,10 +823,6 @@ static int msix_capability_init(struct p
     WARN_ON(dev->msix_table.first !=3D (table_paddr >> PAGE_SHIFT));
     ++dev->msix_used_entries;
=20
-    /* Mask interrupt here */
-    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
-
-    *desc =3D entry;
     /* Restore MSI-X enabled bits */
     pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), =
control);
=20
@@ -926,6 +947,19 @@ static int __pci_enable_msix(struct msi_
     return status;
 }
=20
+static void _pci_cleanup_msix(struct pci_dev *dev)
+{
+    if ( !--dev->msix_used_entries )
+    {
+        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
+                                   dev->msix_table.last) )
+            WARN();
+        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
+                                   dev->msix_pba.last) )
+            WARN();
+    }
+}
+
 static void __pci_disable_msix(struct msi_desc *entry)
 {
     struct pci_dev *dev;
@@ -949,15 +983,42 @@ static void __pci_disable_msix(struct ms
=20
     pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), =
control);
=20
-    if ( !--dev->msix_used_entries )
+    _pci_cleanup_msix(dev);
+}
+
+int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off)
+{
+    int rc;
+    struct pci_dev *pdev;
+    u8 slot =3D PCI_SLOT(devfn), func =3D PCI_FUNC(devfn);
+    unsigned int pos =3D pci_find_cap_offset(seg, bus, slot, func,
+                                           PCI_CAP_ID_MSIX);
+
+    if ( !pos )
+        return -ENODEV;
+
+    spin_lock(&pcidevs_lock);
+    pdev =3D pci_get_pdev(seg, bus, devfn);
+    if ( !pdev )
+        rc =3D -ENODEV;
+    else if ( pdev->msix_used_entries !=3D !!off )
+        rc =3D -EBUSY;
+    else if ( off )
     {
-        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
-                                  dev->msix_table.last) )
-            WARN();
-        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
-                                   dev->msix_pba.last) )
-            WARN();
+        _pci_cleanup_msix(pdev);
+        rc =3D 0;
     }
+    else
+    {
+        u16 control =3D pci_conf_read16(seg, bus, slot, func,
+                                      msix_control_reg(pos));
+
+        rc =3D msix_capability_init(pdev, NULL, NULL,
+                                  multi_msix_capable(control));
+    }
+    spin_unlock(&pcidevs_lock);
+
+    return rc;
 }
=20
 /*
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -575,6 +575,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
=20
+    case PHYSDEVOP_prepare_msix:
+    case PHYSDEVOP_release_msix: {
+        struct physdev_pci_device dev;
+
+        if ( copy_from_guest(&dev, arg, 1) )
+            ret =3D -EFAULT;
+        else
+            ret =3D pci_prepare_msix(dev.seg, dev.bus, dev.devfn,
+                                   cmd !=3D PHYSDEVOP_prepare_msix);
+        break;
+    }
+
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
=20
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -76,6 +76,7 @@ struct msi_desc;
 /* Helper functions */
 extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc);
 extern void pci_disable_msi(struct msi_desc *desc);
+extern int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off);
 extern void pci_cleanup_msi(struct pci_dev *pdev);
 extern void setup_msi_handler(struct irq_desc *, struct msi_desc *);
 extern void setup_msi_irq(struct irq_desc *);
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -303,6 +303,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_devi
=20
 #define PHYSDEVOP_pci_device_remove     26
 #define PHYSDEVOP_restore_msi_ext       27
+/*
+ * Dom0 should use these two to announce MMIO resources assigned to
+ * MSI-X capable devices won't (prepare) or may (release) change.
+ */
+#define PHYSDEVOP_prepare_msix          30
+#define PHYSDEVOP_release_msix          31
 struct physdev_pci_device {
     /* IN */
     uint16_t seg;
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -57,6 +57,7 @@ struct pci_dev {
     int msix_table_refcnt[MAX_MSIX_TABLE_PAGES];
     int msix_table_idx[MAX_MSIX_TABLE_PAGES];
     spinlock_t msix_table_lock;
+    domid_t msix_warned;
=20
     struct domain *domain;
     const u16 seg;



--=__Part576719F5.0__=
Content-Type: text/plain; name="x86-MSI-X-fully-hide-table.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-MSI-X-fully-hide-table.patch"

x86/MSI: add mechanism to protect MSI-X table from PV guest accesses=0A=0AT=
his adds two new physdev operations for Dom0 to invoke when resource=0Aallo=
cation for devices is known to be complete, so that the hypervisor=0Acan =
arrange for the respective MMIO ranges to be marked read-only=0Abefore an =
eventual guest getting such a device assigned even gets=0Astarted, such =
that it won't be able to set up writable mappings for=0Athese MMIO ranges =
before Xen has a chance to protect them.=0A=0AThis also addresses another =
issue with the code being modified here,=0Ain that so far write protection =
for the address ranges in question got=0Aset up only once during the =
lifetime of a device (i.e. until either=0Asystem shutdown or device hot =
removal), while teardown happened when=0Athe last interrupt was disposed =
of by the guest (which at least allowed=0Athe tables to be writable when =
the device got assigned to a second=0Aguest [instance] after the first =
terminated).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -656,8 +656,8 @@ =
static u64 read_pci_mem_bar(u16 seg, u8 =0A  * @entries: pointer to an =
array of struct msix_entry entries=0A  * @nvec: number of @entries=0A  =
*=0A- * Setup the MSI-X capability structure of device function with a=0A- =
* single MSI-X irq. A return of zero indicates the successful setup of=0A+ =
* Setup the MSI-X capability structure of device function with the =
requested=0A+ * number MSI-X irqs. A return of zero indicates the =
successful setup of=0A  * requested MSI-X entries with allocated irqs or =
non-zero for otherwise.=0A  **/=0A static int msix_capability_init(struct =
pci_dev *dev,=0A@@ -665,86 +665,69 @@ static int msix_capability_init(struc=
t p=0A                                 struct msi_desc **desc,=0A          =
                       unsigned int nr_entries)=0A {=0A-    struct =
msi_desc *entry;=0A-    int pos;=0A+    struct msi_desc *entry =3D =
NULL;=0A+    int pos, vf;=0A     u16 control;=0A-    u64 table_paddr, =
entry_paddr;=0A-    u32 table_offset, entry_offset;=0A-    u8 bir;=0A-    =
void __iomem *base;=0A-    int idx;=0A+    u64 table_paddr;=0A+    u32 =
table_offset;=0A+    u8 bir, pbus, pslot, pfunc;=0A     u16 seg =3D =
dev->seg;=0A     u8 bus =3D dev->bus;=0A     u8 slot =3D PCI_SLOT(dev->devf=
n);=0A     u8 func =3D PCI_FUNC(dev->devfn);=0A =0A     ASSERT(spin_is_lock=
ed(&pcidevs_lock));=0A-    ASSERT(desc);=0A =0A     pos =3D pci_find_cap_of=
fset(seg, bus, slot, func, PCI_CAP_ID_MSIX);=0A     control =3D pci_conf_re=
ad16(seg, bus, slot, func, msix_control_reg(pos));=0A     msix_set_enable(d=
ev, 0);/* Ensure msix is disabled as I set it up */=0A =0A-    /* MSI-X =
Table Initialization */=0A-    entry =3D alloc_msi_entry();=0A-    if ( =
!entry )=0A-        return -ENOMEM;=0A+    if ( desc )=0A+    {=0A+        =
entry =3D alloc_msi_entry();=0A+        if ( !entry )=0A+            =
return -ENOMEM;=0A+        ASSERT(msi);=0A+    }=0A =0A-    /* Request & =
Map MSI-X table region */=0A+    /* Locate MSI-X table region */=0A     =
table_offset =3D pci_conf_read32(seg, bus, slot, func,=0A                  =
                  msix_table_offset_reg(pos));=0A     bir =3D (u8)(table_of=
fset & PCI_MSIX_BIRMASK);=0A     table_offset &=3D ~PCI_MSIX_BIRMASK;=0A-  =
  entry_offset =3D msi->entry_nr * PCI_MSIX_ENTRY_SIZE;=0A =0A-    =
table_paddr =3D msi->table_base + table_offset;=0A-    entry_paddr =3D =
table_paddr + entry_offset;=0A-    idx =3D msix_get_fixmap(dev, table_paddr=
, entry_paddr);=0A-    if ( idx < 0 )=0A-    {=0A-        xfree(entry);=0A-=
        return idx;=0A-    }=0A-    base =3D (void *)(fix_to_virt(idx) =
+=0A-        ((unsigned long)entry_paddr & ((1UL << PAGE_SHIFT) - =
1)));=0A-=0A-    entry->msi_attrib.type =3D PCI_CAP_ID_MSIX;=0A-    =
entry->msi_attrib.is_64 =3D 1;=0A-    entry->msi_attrib.entry_nr =3D =
msi->entry_nr;=0A-    entry->msi_attrib.maskbit =3D 1;=0A-    entry->msi_at=
trib.masked =3D 1;=0A-    entry->msi_attrib.pos =3D pos;=0A-    entry->irq =
=3D msi->irq;=0A-    entry->dev =3D dev;=0A-    entry->mask_base =3D =
base;=0A-=0A-    list_add_tail(&entry->list, &dev->msi_list);=0A-=0A-    =
if ( !dev->msix_nr_entries )=0A+    if ( !dev->info.is_virtfn )=0A     =
{=0A-        u8 pbus, pslot, pfunc;=0A-        int vf;=0A-        u64 =
pba_paddr;=0A-        u32 pba_offset;=0A+        pbus =3D bus;=0A+        =
pslot =3D slot;=0A+        pfunc =3D func;=0A+        vf =3D -1;=0A+    =
}=0A+    else=0A+    {=0A+        pbus =3D dev->info.physfn.bus;=0A+       =
 pslot =3D PCI_SLOT(dev->info.physfn.devfn);=0A+        pfunc =3D =
PCI_FUNC(dev->info.physfn.devfn);=0A+        vf =3D PCI_BDF2(dev->bus, =
dev->devfn);=0A+    }=0A =0A-        if ( !dev->info.is_virtfn )=0A-       =
 {=0A-            pbus =3D bus;=0A-            pslot =3D slot;=0A-         =
   pfunc =3D func;=0A-            vf =3D -1;=0A-        }=0A-        =
else=0A+    table_paddr =3D read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, =
vf);=0A+    WARN_ON(msi && msi->table_base !=3D table_paddr);=0A+    if ( =
!table_paddr )=0A+    {=0A+        if ( !msi || !msi->table_base )=0A      =
   {=0A-            pbus =3D dev->info.physfn.bus;=0A-            pslot =
=3D PCI_SLOT(dev->info.physfn.devfn);=0A-            pfunc =3D PCI_FUNC(dev=
->info.physfn.devfn);=0A-            vf =3D PCI_BDF2(dev->bus, dev->devfn);=
=0A+            xfree(entry);=0A+            return -ENXIO;=0A         =
}=0A+        table_paddr =3D msi->table_base;=0A+    }=0A+    table_paddr =
+=3D table_offset;=0A =0A-        ASSERT(!dev->msix_used_entries);=0A-     =
   WARN_ON(msi->table_base !=3D=0A-                read_pci_mem_bar(seg, =
pbus, pslot, pfunc, bir, vf));=0A+    if ( !dev->msix_used_entries )=0A+   =
 {=0A+        u64 pba_paddr;=0A+        u32 pba_offset;=0A =0A         =
dev->msix_nr_entries =3D nr_entries;=0A         dev->msix_table.first =3D =
PFN_DOWN(table_paddr);=0A@@ -765,7 +748,42 @@ static int msix_capability_in=
it(struct p=0A                                       BITS_TO_LONGS(nr_entri=
es) - 1);=0A         WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, =
dev->msix_pba.first,=0A                                         dev->msix_p=
ba.last));=0A+    }=0A =0A+    if ( entry )=0A+    {=0A+        /* Map =
MSI-X table region */=0A+        u64 entry_paddr =3D table_paddr + =
msi->entry_nr * PCI_MSIX_ENTRY_SIZE;=0A+        int idx =3D msix_get_fixmap=
(dev, table_paddr, entry_paddr);=0A+        void __iomem *base;=0A+=0A+    =
    if ( idx < 0 )=0A+        {=0A+            xfree(entry);=0A+           =
 return idx;=0A+        }=0A+        base =3D (void *)(fix_to_virt(idx) =
+=0A+                        ((unsigned long)entry_paddr & (PAGE_SIZE - =
1)));=0A+=0A+        /* Mask interrupt here */=0A+        writel(1, base + =
PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);=0A+=0A+        entry->msi_attrib.type =
=3D PCI_CAP_ID_MSIX;=0A+        entry->msi_attrib.is_64 =3D 1;=0A+        =
entry->msi_attrib.entry_nr =3D msi->entry_nr;=0A+        entry->msi_attrib.=
maskbit =3D 1;=0A+        entry->msi_attrib.masked =3D 1;=0A+        =
entry->msi_attrib.pos =3D pos;=0A+        entry->irq =3D msi->irq;=0A+     =
   entry->dev =3D dev;=0A+        entry->mask_base =3D base;=0A+=0A+       =
 list_add_tail(&entry->list, &dev->msi_list);=0A+        *desc =3D =
entry;=0A+    }=0A+=0A+    if ( !dev->msix_used_entries )=0A+    {=0A      =
   if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,=0A       =
                          dev->msix_table.last) )=0A             WARN();=0A=
@@ -776,7 +794,7 @@ static int msix_capability_init(struct p=0A         if =
( dev->domain )=0A             p2m_change_entry_type_global(dev->domain,=0A=
                                          p2m_mmio_direct, p2m_mmio_direct)=
;=0A-        if ( !dev->domain || !paging_mode_translate(dev->domain) =
)=0A+        if ( desc && (!dev->domain || !paging_mode_translate(dev->doma=
in)) )=0A         {=0A             struct domain *d =3D dev->domain;=0A =
=0A@@ -790,6 +808,13 @@ static int msix_capability_init(struct p=0A        =
                 break;=0A             if ( d )=0A             {=0A+       =
         if ( !IS_PRIV(d) && dev->msix_warned !=3D d->domain_id )=0A+      =
          {=0A+                    dev->msix_warned =3D d->domain_id;=0A+  =
                  printk(XENLOG_ERR=0A+                           =
"Potentially insecure use of MSI-X on %04x:%02x:%02x.%u by Dom%d\n",=0A+   =
                        seg, bus, slot, func, d->domain_id);=0A+           =
     }=0A                 /* XXX How to deal with existing mappings? */=0A =
            }=0A         }=0A@@ -798,10 +823,6 @@ static int msix_capabilit=
y_init(struct p=0A     WARN_ON(dev->msix_table.first !=3D (table_paddr >> =
PAGE_SHIFT));=0A     ++dev->msix_used_entries;=0A =0A-    /* Mask =
interrupt here */=0A-    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR=
_CTRL_OFFSET);=0A-=0A-    *desc =3D entry;=0A     /* Restore MSI-X enabled =
bits */=0A     pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos)=
, control);=0A =0A@@ -926,6 +947,19 @@ static int __pci_enable_msix(struct =
msi_=0A     return status;=0A }=0A =0A+static void _pci_cleanup_msix(struct=
 pci_dev *dev)=0A+{=0A+    if ( !--dev->msix_used_entries )=0A+    {=0A+   =
     if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,=0A+ =
                                  dev->msix_table.last) )=0A+            =
WARN();=0A+        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba=
.first,=0A+                                   dev->msix_pba.last) )=0A+    =
        WARN();=0A+    }=0A+}=0A+=0A static void __pci_disable_msix(struct =
msi_desc *entry)=0A {=0A     struct pci_dev *dev;=0A@@ -949,15 +983,42 @@ =
static void __pci_disable_msix(struct ms=0A =0A     pci_conf_write16(seg, =
bus, slot, func, msix_control_reg(pos), control);=0A =0A-    if ( =
!--dev->msix_used_entries )=0A+    _pci_cleanup_msix(dev);=0A+}=0A+=0A+int =
pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off)=0A+{=0A+    int =
rc;=0A+    struct pci_dev *pdev;=0A+    u8 slot =3D PCI_SLOT(devfn), func =
=3D PCI_FUNC(devfn);=0A+    unsigned int pos =3D pci_find_cap_offset(seg, =
bus, slot, func,=0A+                                           PCI_CAP_ID_M=
SIX);=0A+=0A+    if ( !pos )=0A+        return -ENODEV;=0A+=0A+    =
spin_lock(&pcidevs_lock);=0A+    pdev =3D pci_get_pdev(seg, bus, devfn);=0A=
+    if ( !pdev )=0A+        rc =3D -ENODEV;=0A+    else if ( pdev->msix_us=
ed_entries !=3D !!off )=0A+        rc =3D -EBUSY;=0A+    else if ( off =
)=0A     {=0A-        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_=
table.first,=0A-                                  dev->msix_table.last) =
)=0A-            WARN();=0A-        if ( rangeset_remove_range(mmio_ro_rang=
es, dev->msix_pba.first,=0A-                                   dev->msix_pb=
a.last) )=0A-            WARN();=0A+        _pci_cleanup_msix(pdev);=0A+   =
     rc =3D 0;=0A     }=0A+    else=0A+    {=0A+        u16 control =3D =
pci_conf_read16(seg, bus, slot, func,=0A+                                  =
    msix_control_reg(pos));=0A+=0A+        rc =3D msix_capability_init(pdev=
, NULL, NULL,=0A+                                  multi_msix_capable(contr=
ol));=0A+    }=0A+    spin_unlock(&pcidevs_lock);=0A+=0A+    return rc;=0A =
}=0A =0A /*=0A--- a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=
=0A@@ -575,6 +575,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A        =
 break;=0A     }=0A =0A+    case PHYSDEVOP_prepare_msix:=0A+    case =
PHYSDEVOP_release_msix: {=0A+        struct physdev_pci_device dev;=0A+=0A+=
        if ( copy_from_guest(&dev, arg, 1) )=0A+            ret =3D =
-EFAULT;=0A+        else=0A+            ret =3D pci_prepare_msix(dev.seg, =
dev.bus, dev.devfn,=0A+                                   cmd !=3D =
PHYSDEVOP_prepare_msix);=0A+        break;=0A+    }=0A+=0A     case =
PHYSDEVOP_pci_mmcfg_reserved: {=0A         struct physdev_pci_mmcfg_reserve=
d info;=0A =0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/m=
si.h=0A@@ -76,6 +76,7 @@ struct msi_desc;=0A /* Helper functions */=0A =
extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc);=0A=
 extern void pci_disable_msi(struct msi_desc *desc);=0A+extern int =
pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off);=0A extern void =
pci_cleanup_msi(struct pci_dev *pdev);=0A extern void setup_msi_handler(str=
uct irq_desc *, struct msi_desc *);=0A extern void setup_msi_irq(struct =
irq_desc *);=0A--- a/xen/include/public/physdev.h=0A+++ b/xen/include/publi=
c/physdev.h=0A@@ -303,6 +303,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_devi=
=0A =0A #define PHYSDEVOP_pci_device_remove     26=0A #define PHYSDEVOP_res=
tore_msi_ext       27=0A+/*=0A+ * Dom0 should use these two to announce =
MMIO resources assigned to=0A+ * MSI-X capable devices won't (prepare) or =
may (release) change.=0A+ */=0A+#define PHYSDEVOP_prepare_msix          =
30=0A+#define PHYSDEVOP_release_msix          31=0A struct physdev_pci_devi=
ce {=0A     /* IN */=0A     uint16_t seg;=0A--- a/xen/include/xen/pci.h=0A+=
++ b/xen/include/xen/pci.h=0A@@ -57,6 +57,7 @@ struct pci_dev {=0A     int =
msix_table_refcnt[MAX_MSIX_TABLE_PAGES];=0A     int msix_table_idx[MAX_MSIX=
_TABLE_PAGES];=0A     spinlock_t msix_table_lock;=0A+    domid_t msix_warne=
d;=0A =0A     struct domain *domain;=0A     const u16 seg;=0A
--=__Part576719F5.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

--=__Part576719F5.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 16:57:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:57: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 1U38JE-0007Zk-FZ; Wed, 06 Feb 2013 16:57: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 1U38JD-0007Zc-5s
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:57:19 +0000
Received: from [193.109.254.147:4727] by server-11.bemta-14.messagelabs.com id
	04/EA-30685-E6B82115; Wed, 06 Feb 2013 16:57:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360169836!8792261!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA5MDY1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15290 invoked from network); 6 Feb 2013 16:57:17 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 16:57:17 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16GvDLF023639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 16:57:14 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
	r16GvDoh026259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 16:57:13 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
	r16GvDLE014477; Wed, 6 Feb 2013 10:57:13 -0600
Received: from konrad-lan.dumpdata.com (/67.186.155.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 08:57:12 -0800
Date: Wed, 6 Feb 2013 11:57:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130206165709.GC24458@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360085020.7477.167.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Tue, Feb 05, 2013 at 05:23:40PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:00 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 31, 2013 at 02:46:58PM +0000, Wei Liu wrote:
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
> > >  include/xen/interface/xen.h           |    9 ++++++++-
> > >  2 files changed, 41 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
> > > index f494292..9d8b9e7 100644
> > > --- a/include/xen/interface/event_channel.h
> > > +++ b/include/xen/interface/event_channel.h
> > > @@ -190,6 +190,39 @@ struct evtchn_reset {
> > >  };
> > >  typedef struct evtchn_reset evtchn_reset_t;
> > >  
> > > +/*
> > > + * EVTCHNOP_register_nlevel: Register N-level event channel
> > > + * NOTES:
> > > + *  1. Currently only 3-level is supported.
> > > + *  2. Should fall back to 2-level if this call fails.
> > > + */
> > > +#define EVTCHNOP_register_nlevel 11
> > > +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> > > + * 256k event channels while 32 bit ones only need 1 page for 32k
> > > + * event channels. */
> > > +#define EVTCHN_MAX_L3_PAGES 8
> > > +struct evtchn_register_3level {
> > > +	/* IN parameters. */
> > > +	uint32_t nr_pages; /* for evtchn_{pending,mask} */
> > > +	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
> > > +	GUEST_HANDLE(ulong) evtchn_pending;
> > > +	GUEST_HANDLE(ulong) evtchn_mask;
> > > +	GUEST_HANDLE(ulong) l2sel_mfns;
> > > +	GUEST_HANDLE(ulong) l2sel_offsets;
> > > +};
> > > +typedef struct evtchn_register_3level evtchn_register_3level_t;

Please please not put them in. I know that there are some typdefs in
there but they should actually be removed.

> > > +DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
> > > +
> > > +struct evtchn_register_nlevel {
> > > +	/* IN parameters. */
> > > +	uint32_t level;
> > > +	union {
> > > +		evtchn_register_3level_t l3;
> > > +	} u;
> > > +};
> > > +typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
> > > +DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
> > > +
> > >  struct evtchn_op {
> > >  	uint32_t cmd; /* EVTCHNOP_* */
> > >  	union {
> > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > > index a890804..5220e33 100644
> > > --- a/include/xen/interface/xen.h
> > > +++ b/include/xen/interface/xen.h
> > > @@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> > >  
> > >  /*
> > >   * Event channel endpoints per domain:
> > > + * 2-level:
> > >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> > > + * 3-level:
> > > + *  32k if a long is 32 bits; 256k if a long is 64 bits.
> > >   */
> > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > 
> > We did a bit of header change to make the ARM code always use 'unsinged
> > long long' on 32-bit (so it is a nice 8-bytes) and 'unsigned long' on
> > 64-bit. This was all done using the xen_pfn_t and xen_mfn_t typdefs.
> > 
> > Any chance you can do that here? That way on ARM - irregardless if it is
> > 32-bit or 64-bit it is always of the 64-bit size?
> > 
> 
> I don't think so. The reason to use unsigned long here is to guarantee
> each selector (in 2-level case there is only L1 selector) fits into a
> word.

OK, so we do depend on this being of different size on 32-bit and
64-bit.
> 
> > Or do we not care about the ARM case here?
> > 
> 
> What do you mean? How would this definition affect ARM case?
> 

Xen ARM uses 64-bit values even if the host/guest is 32-bit.

> 
> Wei.
> 
> > > +#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
> > > +#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > > +#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
> > > +#endif
> > >  
> > >  struct vcpu_time_info {
> > >  	/*
> > > -- 
> > > 1.7.10.4
> > > 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:57:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 16:57: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 1U38JE-0007Zk-FZ; Wed, 06 Feb 2013 16:57: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 1U38JD-0007Zc-5s
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:57:19 +0000
Received: from [193.109.254.147:4727] by server-11.bemta-14.messagelabs.com id
	04/EA-30685-E6B82115; Wed, 06 Feb 2013 16:57:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360169836!8792261!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA5MDY1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15290 invoked from network); 6 Feb 2013 16:57:17 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 16:57:17 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16GvDLF023639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 16:57:14 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
	r16GvDoh026259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 16:57:13 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
	r16GvDLE014477; Wed, 6 Feb 2013 10:57:13 -0600
Received: from konrad-lan.dumpdata.com (/67.186.155.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 08:57:12 -0800
Date: Wed, 6 Feb 2013 11:57:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130206165709.GC24458@konrad-lan.dumpdata.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360085020.7477.167.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Tue, Feb 05, 2013 at 05:23:40PM +0000, Wei Liu wrote:
> On Tue, 2013-02-05 at 17:00 +0000, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 31, 2013 at 02:46:58PM +0000, Wei Liu wrote:
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  include/xen/interface/event_channel.h |   33 +++++++++++++++++++++++++++++++++
> > >  include/xen/interface/xen.h           |    9 ++++++++-
> > >  2 files changed, 41 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/include/xen/interface/event_channel.h b/include/xen/interface/event_channel.h
> > > index f494292..9d8b9e7 100644
> > > --- a/include/xen/interface/event_channel.h
> > > +++ b/include/xen/interface/event_channel.h
> > > @@ -190,6 +190,39 @@ struct evtchn_reset {
> > >  };
> > >  typedef struct evtchn_reset evtchn_reset_t;
> > >  
> > > +/*
> > > + * EVTCHNOP_register_nlevel: Register N-level event channel
> > > + * NOTES:
> > > + *  1. Currently only 3-level is supported.
> > > + *  2. Should fall back to 2-level if this call fails.
> > > + */
> > > +#define EVTCHNOP_register_nlevel 11
> > > +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> > > + * 256k event channels while 32 bit ones only need 1 page for 32k
> > > + * event channels. */
> > > +#define EVTCHN_MAX_L3_PAGES 8
> > > +struct evtchn_register_3level {
> > > +	/* IN parameters. */
> > > +	uint32_t nr_pages; /* for evtchn_{pending,mask} */
> > > +	uint32_t nr_vcpus; /* for l2sel_{mfns,mask} */
> > > +	GUEST_HANDLE(ulong) evtchn_pending;
> > > +	GUEST_HANDLE(ulong) evtchn_mask;
> > > +	GUEST_HANDLE(ulong) l2sel_mfns;
> > > +	GUEST_HANDLE(ulong) l2sel_offsets;
> > > +};
> > > +typedef struct evtchn_register_3level evtchn_register_3level_t;

Please please not put them in. I know that there are some typdefs in
there but they should actually be removed.

> > > +DEFINE_GUEST_HANDLE(evtchn_register_3level_t);
> > > +
> > > +struct evtchn_register_nlevel {
> > > +	/* IN parameters. */
> > > +	uint32_t level;
> > > +	union {
> > > +		evtchn_register_3level_t l3;
> > > +	} u;
> > > +};
> > > +typedef struct evtchn_register_nlevel evtchn_register_nlevel_t;
> > > +DEFINE_GUEST_HANDLE(evtchn_register_nlevel_t);
> > > +
> > >  struct evtchn_op {
> > >  	uint32_t cmd; /* EVTCHNOP_* */
> > >  	union {
> > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > > index a890804..5220e33 100644
> > > --- a/include/xen/interface/xen.h
> > > +++ b/include/xen/interface/xen.h
> > > @@ -283,9 +283,16 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> > >  
> > >  /*
> > >   * Event channel endpoints per domain:
> > > + * 2-level:
> > >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> > > + * 3-level:
> > > + *  32k if a long is 32 bits; 256k if a long is 64 bits.
> > >   */
> > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > 
> > We did a bit of header change to make the ARM code always use 'unsinged
> > long long' on 32-bit (so it is a nice 8-bytes) and 'unsigned long' on
> > 64-bit. This was all done using the xen_pfn_t and xen_mfn_t typdefs.
> > 
> > Any chance you can do that here? That way on ARM - irregardless if it is
> > 32-bit or 64-bit it is always of the 64-bit size?
> > 
> 
> I don't think so. The reason to use unsigned long here is to guarantee
> each selector (in 2-level case there is only L1 selector) fits into a
> word.

OK, so we do depend on this being of different size on 32-bit and
64-bit.
> 
> > Or do we not care about the ARM case here?
> > 
> 
> What do you mean? How would this definition affect ARM case?
> 

Xen ARM uses 64-bit values even if the host/guest is 32-bit.

> 
> Wei.
> 
> > > +#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
> > > +#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
> > > +#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
> > > +#endif
> > >  
> > >  struct vcpu_time_info {
> > >  	/*
> > > -- 
> > > 1.7.10.4
> > > 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 16:58:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38K1-0007dk-2X; Wed, 06 Feb 2013 16:58:09 +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 1U38Jy-0007dR-SG
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:58:07 +0000
Received: from [193.109.254.147:6932] by server-1.bemta-14.messagelabs.com id
	9A/49-29874-D9B82115; Wed, 06 Feb 2013 16:58:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360169883!9024323!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19018 invoked from network); 6 Feb 2013 16:58:03 -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; 6 Feb 2013 16:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 16:58:03 +0000
Message-Id: <511299A902000078000BC944@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 16:58:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part29196789.0__="
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-pciback: notify hypervisor about devices
 intended to be assigned to 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>
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.

--=__Part29196789.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

For MSI-X capable devices the hypervisor wants to write protect the
MSI-X table and PBA, yet it can't assume that resources have been
assigned to their final values at device enumeration time. Thus have
pciback do that notification, as having the device controlled by it is
a prerequisite to assigning the device to guests anyway.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 arch/x86/include/asm/xen/hypercall.h |    4 +-
 drivers/xen/fallback.c               |    3 +
 drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++----=
-----
 include/xen/interface/physdev.h      |    6 +++
 4 files changed, 54 insertions(+), 18 deletions(-)

--- 3.8-rc6/arch/x86/include/asm/xen/hypercall.h
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/include/asm/xen/hypercall.h
@@ -382,14 +382,14 @@ HYPERVISOR_console_io(int cmd, int count
 	return _hypercall3(int, console_io, cmd, count, str);
 }
=20
-extern int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+extern int __must_check xen_physdev_op_compat(int, void *);
=20
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);
 	if (unlikely(rc =3D=3D -ENOSYS))
-		rc =3D HYPERVISOR_physdev_op_compat(cmd, arg);
+		rc =3D xen_physdev_op_compat(cmd, arg);
 	return rc;
 }
=20
--- 3.8-rc6/drivers/xen/fallback.c
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c
@@ -44,7 +44,7 @@ int xen_event_channel_op_compat(int cmd,
 }
 EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
=20
-int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+int xen_physdev_op_compat(int cmd, void *arg)
 {
 	struct physdev_op op;
 	int rc;
@@ -78,3 +78,4 @@ int HYPERVISOR_physdev_op_compat(int cmd
=20
 	return rc;
 }
+EXPORT_SYMBOL_GPL(xen_physdev_op_compat);
--- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c
@@ -17,6 +17,7 @@
 #include <xen/events.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypervisor.h>
+#include <xen/interface/physdev.h>
 #include "pciback.h"
 #include "conf_space.h"
 #include "conf_space_quirks.h"
@@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de
 static void pcistub_device_release(struct kref *kref)
 {
 	struct pcistub_device *psdev;
+	struct pci_dev *dev;
 	struct xen_pcibk_dev_data *dev_data;
=20
 	psdev =3D container_of(kref, struct pcistub_device, kref);
-	dev_data =3D pci_get_drvdata(psdev->dev);
+	dev =3D psdev->dev;
+	dev_data =3D pci_get_drvdata(dev);
=20
-	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
+	dev_dbg(&dev->dev, "pcistub_device_release\n");
=20
-	xen_unregister_device_domain_owner(psdev->dev);
+	xen_unregister_device_domain_owner(dev);
=20
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
-	__pci_reset_function_locked(psdev->dev);
-	if (pci_load_and_free_saved_state(psdev->dev,
-					  &dev_data->pci_saved_state)) {
-		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
-	} else
-		pci_restore_state(psdev->dev);
+	__pci_reset_function_locked(dev);
+	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))=

+		dev_dbg(&dev->dev, "Could not reload PCI state\n");
+	else
+		pci_restore_state(dev);
+
+	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
+		struct physdev_pci_device ppdev =3D {
+			.seg =3D pci_domain_nr(dev->bus),
+			.bus =3D dev->bus->number,
+			.devfn =3D dev->devfn
+		};
+		int err =3D HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
+						&ppdev);
+
+		if (err)
+			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
+				 err);
+	}
=20
 	/* Disable the device */
-	xen_pcibk_reset_device(psdev->dev);
+	xen_pcibk_reset_device(dev);
=20
 	kfree(dev_data);
-	pci_set_drvdata(psdev->dev, NULL);
+	pci_set_drvdata(dev, NULL);
=20
 	/* Clean-up the device */
-	xen_pcibk_config_free_dyn_fields(psdev->dev);
-	xen_pcibk_config_free_dev(psdev->dev);
+	xen_pcibk_config_free_dyn_fields(dev);
+	xen_pcibk_config_free_dev(dev);
=20
-	psdev->dev->dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;
-	pci_dev_put(psdev->dev);
+	dev->dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;
+	pci_dev_put(dev);
=20
 	kfree(psdev);
 }
@@ -355,6 +371,19 @@ static int pcistub_init_device(struct pc
 	if (err)
 		goto config_release;
=20
+	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
+		struct physdev_pci_device ppdev =3D {
+			.seg =3D pci_domain_nr(dev->bus),
+			.bus =3D dev->bus->number,
+			.devfn =3D dev->devfn
+		};
+
+		err =3D HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msix, =
&ppdev);
+		if (err)
+			dev_err(&dev->dev, "MSI-X preparation failed =
(%d)\n",
+				err);
+	}
+
 	/* We need the device active to save the state. */
 	dev_dbg(&dev->dev, "save state of device\n");
 	pci_save_state(dev);
--- 3.8-rc6/include/xen/interface/physdev.h
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/include/xen/interface/physdev.h
@@ -251,6 +251,12 @@ struct physdev_pci_device_add {
=20
 #define PHYSDEVOP_pci_device_remove     26
 #define PHYSDEVOP_restore_msi_ext       27
+/*
+ * Dom0 should use these two to announce MMIO resources assigned to
+ * MSI-X capable devices won't (prepare) or may (release) change.
+ */
+#define PHYSDEVOP_prepare_msix          30
+#define PHYSDEVOP_release_msix          31
 struct physdev_pci_device {
     /* IN */
     uint16_t seg;



--=__Part29196789.0__=
Content-Type: text/plain; name="linux-3.8-rc6-xen-pciback-MSI-X-prepare.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.8-rc6-xen-pciback-MSI-X-prepare.patch"

xen-pciback: notify hypervisor about devices intended to be assigned to =
guests=0A=0AFor MSI-X capable devices the hypervisor wants to write =
protect the=0AMSI-X table and PBA, yet it can't assume that resources have =
been=0Aassigned to their final values at device enumeration time. Thus =
have=0Apciback do that notification, as having the device controlled by it =
is=0Aa prerequisite to assigning the device to guests anyway.=0A=0ASigned-o=
ff-by: Jan Beulich <jbeulich@suse.com>=0A=0A---=0A arch/x86/include/asm/xen=
/hypercall.h |    4 +-=0A drivers/xen/fallback.c               |    3 +=0A =
drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++-----=
----=0A include/xen/interface/physdev.h      |    6 +++=0A 4 files =
changed, 54 insertions(+), 18 deletions(-)=0A=0A--- 3.8-rc6/arch/x86/includ=
e/asm/xen/hypercall.h=0A+++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/incl=
ude/asm/xen/hypercall.h=0A@@ -382,14 +382,14 @@ HYPERVISOR_console_io(int =
cmd, int count=0A 	return _hypercall3(int, console_io, cmd, count, =
str);=0A }=0A =0A-extern int __must_check HYPERVISOR_physdev_op_compat(int,=
 void *);=0A+extern int __must_check xen_physdev_op_compat(int, void =
*);=0A =0A static inline int=0A HYPERVISOR_physdev_op(int cmd, void =
*arg)=0A {=0A 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);=0A 	if =
(unlikely(rc =3D=3D -ENOSYS))=0A-		rc =3D HYPERVISOR_physdev_o=
p_compat(cmd, arg);=0A+		rc =3D xen_physdev_op_compat(cmd, arg);=0A =
	return rc;=0A }=0A =0A--- 3.8-rc6/drivers/xen/fallback.c=0A+++ =
3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c=0A@@ -44,7 +44,7 =
@@ int xen_event_channel_op_compat(int cmd,=0A }=0A EXPORT_SYMBOL_GPL(xen_e=
vent_channel_op_compat);=0A =0A-int HYPERVISOR_physdev_op_compat(int cmd, =
void *arg)=0A+int xen_physdev_op_compat(int cmd, void *arg)=0A {=0A 	=
struct physdev_op op;=0A 	int rc;=0A@@ -78,3 +78,4 @@ int HYPERVISOR_=
physdev_op_compat(int cmd=0A =0A 	return rc;=0A }=0A+EXPORT_SYMBOL_GP=
L(xen_physdev_op_compat);=0A--- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c=
=0A+++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c=
=0A@@ -17,6 +17,7 @@=0A #include <xen/events.h>=0A #include <asm/xen/pci.h>=
=0A #include <asm/xen/hypervisor.h>=0A+#include <xen/interface/physdev.h>=
=0A #include "pciback.h"=0A #include "conf_space.h"=0A #include "conf_space=
_quirks.h"=0A@@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de=
=0A static void pcistub_device_release(struct kref *kref)=0A {=0A 	=
struct pcistub_device *psdev;=0A+	struct pci_dev *dev;=0A 	=
struct xen_pcibk_dev_data *dev_data;=0A =0A 	psdev =3D container_of(kref=
, struct pcistub_device, kref);=0A-	dev_data =3D pci_get_drvdata(psdev-=
>dev);=0A+	dev =3D psdev->dev;=0A+	dev_data =3D pci_get_drvdata(dev);=
=0A =0A-	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");=0A+	=
dev_dbg(&dev->dev, "pcistub_device_release\n");=0A =0A-	xen_unregister_devi=
ce_domain_owner(psdev->dev);=0A+	xen_unregister_device_domain_owner(=
dev);=0A =0A 	/* Call the reset function which does not take lock as =
this=0A 	 * is called from "unbind" which takes a device_lock =
mutex.=0A 	 */=0A-	__pci_reset_function_locked(psdev->dev);=0A-	if =
(pci_load_and_free_saved_state(psdev->dev,=0A-					=
  &dev_data->pci_saved_state)) {=0A-		dev_dbg(&psdev->dev->dev, =
"Could not reload PCI state\n");=0A-	} else=0A-		pci_restore=
_state(psdev->dev);=0A+	__pci_reset_function_locked(dev);=0A+	if =
(pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))=0A+		=
dev_dbg(&dev->dev, "Could not reload PCI state\n");=0A+	else=0A+		=
pci_restore_state(dev);=0A+=0A+	if (pci_find_capability(dev, PCI_CAP_ID_MSI=
X)) {=0A+		struct physdev_pci_device ppdev =3D {=0A+		=
	.seg =3D pci_domain_nr(dev->bus),=0A+			.bus =3D =
dev->bus->number,=0A+			.devfn =3D dev->devfn=0A+		=
};=0A+		int err =3D HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,=
=0A+						&ppdev);=0A+=0A+		=
if (err)=0A+			dev_warn(&dev->dev, "MSI-X release failed =
(%d)\n",=0A+				 err);=0A+	}=0A =0A 	/* =
Disable the device */=0A-	xen_pcibk_reset_device(psdev->dev);=0A+	=
xen_pcibk_reset_device(dev);=0A =0A 	kfree(dev_data);=0A-	pci_set_drv=
data(psdev->dev, NULL);=0A+	pci_set_drvdata(dev, NULL);=0A =0A 	/* =
Clean-up the device */=0A-	xen_pcibk_config_free_dyn_fields(psdev->dev=
);=0A-	xen_pcibk_config_free_dev(psdev->dev);=0A+	xen_pcibk_config_fr=
ee_dyn_fields(dev);=0A+	xen_pcibk_config_free_dev(dev);=0A =0A-	psdev->dev-=
>dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;=0A-	pci_dev_put(psdev->dev);=0A=
+	dev->dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;=0A+	pci_dev_put=
(dev);=0A =0A 	kfree(psdev);=0A }=0A@@ -355,6 +371,19 @@ static int =
pcistub_init_device(struct pc=0A 	if (err)=0A 		goto =
config_release;=0A =0A+	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) =
{=0A+		struct physdev_pci_device ppdev =3D {=0A+			=
.seg =3D pci_domain_nr(dev->bus),=0A+			.bus =3D dev->bus->=
number,=0A+			.devfn =3D dev->devfn=0A+		=
};=0A+=0A+		err =3D HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msi=
x, &ppdev);=0A+		if (err)=0A+			dev_err(&dev->dev, =
"MSI-X preparation failed (%d)\n",=0A+				err);=0A+	=
}=0A+=0A 	/* We need the device active to save the state. */=0A 	=
dev_dbg(&dev->dev, "save state of device\n");=0A 	pci_save_state(dev)=
;=0A--- 3.8-rc6/include/xen/interface/physdev.h=0A+++ 3.8-rc6-xen-pciback-M=
SI-X-prepare/include/xen/interface/physdev.h=0A@@ -251,6 +251,12 @@ struct =
physdev_pci_device_add {=0A =0A #define PHYSDEVOP_pci_device_remove     =
26=0A #define PHYSDEVOP_restore_msi_ext       27=0A+/*=0A+ * Dom0 should =
use these two to announce MMIO resources assigned to=0A+ * MSI-X capable =
devices won't (prepare) or may (release) change.=0A+ */=0A+#define =
PHYSDEVOP_prepare_msix          30=0A+#define PHYSDEVOP_release_msix       =
   31=0A struct physdev_pci_device {=0A     /* IN */=0A     uint16_t =
seg;=0A
--=__Part29196789.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

--=__Part29196789.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 16:58:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38K1-0007dk-2X; Wed, 06 Feb 2013 16:58:09 +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 1U38Jy-0007dR-SG
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 16:58:07 +0000
Received: from [193.109.254.147:6932] by server-1.bemta-14.messagelabs.com id
	9A/49-29874-D9B82115; Wed, 06 Feb 2013 16:58:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360169883!9024323!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19018 invoked from network); 6 Feb 2013 16:58:03 -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; 6 Feb 2013 16:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 06 Feb 2013 16:58:03 +0000
Message-Id: <511299A902000078000BC944@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 06 Feb 2013 16:58:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part29196789.0__="
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-pciback: notify hypervisor about devices
 intended to be assigned to 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>
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.

--=__Part29196789.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

For MSI-X capable devices the hypervisor wants to write protect the
MSI-X table and PBA, yet it can't assume that resources have been
assigned to their final values at device enumeration time. Thus have
pciback do that notification, as having the device controlled by it is
a prerequisite to assigning the device to guests anyway.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 arch/x86/include/asm/xen/hypercall.h |    4 +-
 drivers/xen/fallback.c               |    3 +
 drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++----=
-----
 include/xen/interface/physdev.h      |    6 +++
 4 files changed, 54 insertions(+), 18 deletions(-)

--- 3.8-rc6/arch/x86/include/asm/xen/hypercall.h
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/include/asm/xen/hypercall.h
@@ -382,14 +382,14 @@ HYPERVISOR_console_io(int cmd, int count
 	return _hypercall3(int, console_io, cmd, count, str);
 }
=20
-extern int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+extern int __must_check xen_physdev_op_compat(int, void *);
=20
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);
 	if (unlikely(rc =3D=3D -ENOSYS))
-		rc =3D HYPERVISOR_physdev_op_compat(cmd, arg);
+		rc =3D xen_physdev_op_compat(cmd, arg);
 	return rc;
 }
=20
--- 3.8-rc6/drivers/xen/fallback.c
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c
@@ -44,7 +44,7 @@ int xen_event_channel_op_compat(int cmd,
 }
 EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
=20
-int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+int xen_physdev_op_compat(int cmd, void *arg)
 {
 	struct physdev_op op;
 	int rc;
@@ -78,3 +78,4 @@ int HYPERVISOR_physdev_op_compat(int cmd
=20
 	return rc;
 }
+EXPORT_SYMBOL_GPL(xen_physdev_op_compat);
--- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c
@@ -17,6 +17,7 @@
 #include <xen/events.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypervisor.h>
+#include <xen/interface/physdev.h>
 #include "pciback.h"
 #include "conf_space.h"
 #include "conf_space_quirks.h"
@@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de
 static void pcistub_device_release(struct kref *kref)
 {
 	struct pcistub_device *psdev;
+	struct pci_dev *dev;
 	struct xen_pcibk_dev_data *dev_data;
=20
 	psdev =3D container_of(kref, struct pcistub_device, kref);
-	dev_data =3D pci_get_drvdata(psdev->dev);
+	dev =3D psdev->dev;
+	dev_data =3D pci_get_drvdata(dev);
=20
-	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
+	dev_dbg(&dev->dev, "pcistub_device_release\n");
=20
-	xen_unregister_device_domain_owner(psdev->dev);
+	xen_unregister_device_domain_owner(dev);
=20
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
-	__pci_reset_function_locked(psdev->dev);
-	if (pci_load_and_free_saved_state(psdev->dev,
-					  &dev_data->pci_saved_state)) {
-		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
-	} else
-		pci_restore_state(psdev->dev);
+	__pci_reset_function_locked(dev);
+	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))=

+		dev_dbg(&dev->dev, "Could not reload PCI state\n");
+	else
+		pci_restore_state(dev);
+
+	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
+		struct physdev_pci_device ppdev =3D {
+			.seg =3D pci_domain_nr(dev->bus),
+			.bus =3D dev->bus->number,
+			.devfn =3D dev->devfn
+		};
+		int err =3D HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
+						&ppdev);
+
+		if (err)
+			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
+				 err);
+	}
=20
 	/* Disable the device */
-	xen_pcibk_reset_device(psdev->dev);
+	xen_pcibk_reset_device(dev);
=20
 	kfree(dev_data);
-	pci_set_drvdata(psdev->dev, NULL);
+	pci_set_drvdata(dev, NULL);
=20
 	/* Clean-up the device */
-	xen_pcibk_config_free_dyn_fields(psdev->dev);
-	xen_pcibk_config_free_dev(psdev->dev);
+	xen_pcibk_config_free_dyn_fields(dev);
+	xen_pcibk_config_free_dev(dev);
=20
-	psdev->dev->dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;
-	pci_dev_put(psdev->dev);
+	dev->dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;
+	pci_dev_put(dev);
=20
 	kfree(psdev);
 }
@@ -355,6 +371,19 @@ static int pcistub_init_device(struct pc
 	if (err)
 		goto config_release;
=20
+	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
+		struct physdev_pci_device ppdev =3D {
+			.seg =3D pci_domain_nr(dev->bus),
+			.bus =3D dev->bus->number,
+			.devfn =3D dev->devfn
+		};
+
+		err =3D HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msix, =
&ppdev);
+		if (err)
+			dev_err(&dev->dev, "MSI-X preparation failed =
(%d)\n",
+				err);
+	}
+
 	/* We need the device active to save the state. */
 	dev_dbg(&dev->dev, "save state of device\n");
 	pci_save_state(dev);
--- 3.8-rc6/include/xen/interface/physdev.h
+++ 3.8-rc6-xen-pciback-MSI-X-prepare/include/xen/interface/physdev.h
@@ -251,6 +251,12 @@ struct physdev_pci_device_add {
=20
 #define PHYSDEVOP_pci_device_remove     26
 #define PHYSDEVOP_restore_msi_ext       27
+/*
+ * Dom0 should use these two to announce MMIO resources assigned to
+ * MSI-X capable devices won't (prepare) or may (release) change.
+ */
+#define PHYSDEVOP_prepare_msix          30
+#define PHYSDEVOP_release_msix          31
 struct physdev_pci_device {
     /* IN */
     uint16_t seg;



--=__Part29196789.0__=
Content-Type: text/plain; name="linux-3.8-rc6-xen-pciback-MSI-X-prepare.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.8-rc6-xen-pciback-MSI-X-prepare.patch"

xen-pciback: notify hypervisor about devices intended to be assigned to =
guests=0A=0AFor MSI-X capable devices the hypervisor wants to write =
protect the=0AMSI-X table and PBA, yet it can't assume that resources have =
been=0Aassigned to their final values at device enumeration time. Thus =
have=0Apciback do that notification, as having the device controlled by it =
is=0Aa prerequisite to assigning the device to guests anyway.=0A=0ASigned-o=
ff-by: Jan Beulich <jbeulich@suse.com>=0A=0A---=0A arch/x86/include/asm/xen=
/hypercall.h |    4 +-=0A drivers/xen/fallback.c               |    3 +=0A =
drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++-----=
----=0A include/xen/interface/physdev.h      |    6 +++=0A 4 files =
changed, 54 insertions(+), 18 deletions(-)=0A=0A--- 3.8-rc6/arch/x86/includ=
e/asm/xen/hypercall.h=0A+++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/incl=
ude/asm/xen/hypercall.h=0A@@ -382,14 +382,14 @@ HYPERVISOR_console_io(int =
cmd, int count=0A 	return _hypercall3(int, console_io, cmd, count, =
str);=0A }=0A =0A-extern int __must_check HYPERVISOR_physdev_op_compat(int,=
 void *);=0A+extern int __must_check xen_physdev_op_compat(int, void =
*);=0A =0A static inline int=0A HYPERVISOR_physdev_op(int cmd, void =
*arg)=0A {=0A 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);=0A 	if =
(unlikely(rc =3D=3D -ENOSYS))=0A-		rc =3D HYPERVISOR_physdev_o=
p_compat(cmd, arg);=0A+		rc =3D xen_physdev_op_compat(cmd, arg);=0A =
	return rc;=0A }=0A =0A--- 3.8-rc6/drivers/xen/fallback.c=0A+++ =
3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c=0A@@ -44,7 +44,7 =
@@ int xen_event_channel_op_compat(int cmd,=0A }=0A EXPORT_SYMBOL_GPL(xen_e=
vent_channel_op_compat);=0A =0A-int HYPERVISOR_physdev_op_compat(int cmd, =
void *arg)=0A+int xen_physdev_op_compat(int cmd, void *arg)=0A {=0A 	=
struct physdev_op op;=0A 	int rc;=0A@@ -78,3 +78,4 @@ int HYPERVISOR_=
physdev_op_compat(int cmd=0A =0A 	return rc;=0A }=0A+EXPORT_SYMBOL_GP=
L(xen_physdev_op_compat);=0A--- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c=
=0A+++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c=
=0A@@ -17,6 +17,7 @@=0A #include <xen/events.h>=0A #include <asm/xen/pci.h>=
=0A #include <asm/xen/hypervisor.h>=0A+#include <xen/interface/physdev.h>=
=0A #include "pciback.h"=0A #include "conf_space.h"=0A #include "conf_space=
_quirks.h"=0A@@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de=
=0A static void pcistub_device_release(struct kref *kref)=0A {=0A 	=
struct pcistub_device *psdev;=0A+	struct pci_dev *dev;=0A 	=
struct xen_pcibk_dev_data *dev_data;=0A =0A 	psdev =3D container_of(kref=
, struct pcistub_device, kref);=0A-	dev_data =3D pci_get_drvdata(psdev-=
>dev);=0A+	dev =3D psdev->dev;=0A+	dev_data =3D pci_get_drvdata(dev);=
=0A =0A-	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");=0A+	=
dev_dbg(&dev->dev, "pcistub_device_release\n");=0A =0A-	xen_unregister_devi=
ce_domain_owner(psdev->dev);=0A+	xen_unregister_device_domain_owner(=
dev);=0A =0A 	/* Call the reset function which does not take lock as =
this=0A 	 * is called from "unbind" which takes a device_lock =
mutex.=0A 	 */=0A-	__pci_reset_function_locked(psdev->dev);=0A-	if =
(pci_load_and_free_saved_state(psdev->dev,=0A-					=
  &dev_data->pci_saved_state)) {=0A-		dev_dbg(&psdev->dev->dev, =
"Could not reload PCI state\n");=0A-	} else=0A-		pci_restore=
_state(psdev->dev);=0A+	__pci_reset_function_locked(dev);=0A+	if =
(pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))=0A+		=
dev_dbg(&dev->dev, "Could not reload PCI state\n");=0A+	else=0A+		=
pci_restore_state(dev);=0A+=0A+	if (pci_find_capability(dev, PCI_CAP_ID_MSI=
X)) {=0A+		struct physdev_pci_device ppdev =3D {=0A+		=
	.seg =3D pci_domain_nr(dev->bus),=0A+			.bus =3D =
dev->bus->number,=0A+			.devfn =3D dev->devfn=0A+		=
};=0A+		int err =3D HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,=
=0A+						&ppdev);=0A+=0A+		=
if (err)=0A+			dev_warn(&dev->dev, "MSI-X release failed =
(%d)\n",=0A+				 err);=0A+	}=0A =0A 	/* =
Disable the device */=0A-	xen_pcibk_reset_device(psdev->dev);=0A+	=
xen_pcibk_reset_device(dev);=0A =0A 	kfree(dev_data);=0A-	pci_set_drv=
data(psdev->dev, NULL);=0A+	pci_set_drvdata(dev, NULL);=0A =0A 	/* =
Clean-up the device */=0A-	xen_pcibk_config_free_dyn_fields(psdev->dev=
);=0A-	xen_pcibk_config_free_dev(psdev->dev);=0A+	xen_pcibk_config_fr=
ee_dyn_fields(dev);=0A+	xen_pcibk_config_free_dev(dev);=0A =0A-	psdev->dev-=
>dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;=0A-	pci_dev_put(psdev->dev);=0A=
+	dev->dev_flags &=3D ~PCI_DEV_FLAGS_ASSIGNED;=0A+	pci_dev_put=
(dev);=0A =0A 	kfree(psdev);=0A }=0A@@ -355,6 +371,19 @@ static int =
pcistub_init_device(struct pc=0A 	if (err)=0A 		goto =
config_release;=0A =0A+	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) =
{=0A+		struct physdev_pci_device ppdev =3D {=0A+			=
.seg =3D pci_domain_nr(dev->bus),=0A+			.bus =3D dev->bus->=
number,=0A+			.devfn =3D dev->devfn=0A+		=
};=0A+=0A+		err =3D HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msi=
x, &ppdev);=0A+		if (err)=0A+			dev_err(&dev->dev, =
"MSI-X preparation failed (%d)\n",=0A+				err);=0A+	=
}=0A+=0A 	/* We need the device active to save the state. */=0A 	=
dev_dbg(&dev->dev, "save state of device\n");=0A 	pci_save_state(dev)=
;=0A--- 3.8-rc6/include/xen/interface/physdev.h=0A+++ 3.8-rc6-xen-pciback-M=
SI-X-prepare/include/xen/interface/physdev.h=0A@@ -251,6 +251,12 @@ struct =
physdev_pci_device_add {=0A =0A #define PHYSDEVOP_pci_device_remove     =
26=0A #define PHYSDEVOP_restore_msi_ext       27=0A+/*=0A+ * Dom0 should =
use these two to announce MMIO resources assigned to=0A+ * MSI-X capable =
devices won't (prepare) or may (release) change.=0A+ */=0A+#define =
PHYSDEVOP_prepare_msix          30=0A+#define PHYSDEVOP_release_msix       =
   31=0A struct physdev_pci_device {=0A     /* IN */=0A     uint16_t =
seg;=0A
--=__Part29196789.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

--=__Part29196789.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 06 17:13:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17:13: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 1U38YF-0008Ph-HX; Wed, 06 Feb 2013 17:12: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 1U38YE-0008Pc-6I
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:12:50 +0000
Received: from [85.158.143.35:25667] by server-1.bemta-4.messagelabs.com id
	02/BD-08839-11F82115; Wed, 06 Feb 2013 17:12:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360170734!15444978!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12790 invoked from network); 6 Feb 2013 17:12:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:12:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="1209053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 17:12: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.297.1; Wed, 6 Feb 2013
	17:12:14 +0000
Message-ID: <1360170733.32479.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Wed, 6 Feb 2013 17:12:13 +0000
In-Reply-To: <1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/5] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 3225b2a..5e80400 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
>  typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
>  
> +/* XEN_SYSCTL_coverage_op */
> +/*
> + * Check if coverage informations are available
> + * return just success or error, no parameters
> + */
> +#define XEN_SYSCTL_COVERAGE_enabled        0

You can detect this by getting -ENOSYS from the hypercall, which is what
you would get running the tool on an older hypervisor, so you need to
handle it anyway.

> +
> +/*
> + * Get total size of information, to help allocate
> + * the buffer. The pointer points to a 32 bit value.
> + */
> +#define XEN_SYSCTL_COVERAGE_get_total_size 1
> +
> +/*
> + * Read coverage information in a single run
> + * You must use a tool to split them
> + */
> +#define XEN_SYSCTL_COVERAGE_read           2
> +
> +/*
> + * Reset all the coverage counters to 0
> + * No parameters.
> + */
> +#define XEN_SYSCTL_COVERAGE_reset          3

Any need for simultaneous read+reset?

> +struct xen_sysctl_coverage_op {
> +    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> +    union {
> +        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */

This one can just be a uint32_t I think, no need for it to be a
pointer/handle.

> +        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
> +    } u;
> +};
> +typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
> +
> +
>  struct xen_sysctl {
>      uint32_t cmd;
>  #define XEN_SYSCTL_readconsole                    1
> @@ -616,6 +652,7 @@ struct xen_sysctl {
>  #define XEN_SYSCTL_numainfo                      17
>  #define XEN_SYSCTL_cpupool_op                    18
>  #define XEN_SYSCTL_scheduler_op                  19
> +#define XEN_SYSCTL_coverage_op                   20
>      uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>      union {
>          struct xen_sysctl_readconsole       readconsole;
> @@ -636,6 +673,7 @@ struct xen_sysctl {
>          struct xen_sysctl_lockprof_op       lockprof_op;
>          struct xen_sysctl_cpupool_op        cpupool_op;
>          struct xen_sysctl_scheduler_op      scheduler_op;
> +        struct xen_sysctl_coverage_op       coverage_op;
>          uint8_t                             pad[128];
>      } u;
>  };



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 17:13:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17:13: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 1U38YF-0008Ph-HX; Wed, 06 Feb 2013 17:12: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 1U38YE-0008Pc-6I
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:12:50 +0000
Received: from [85.158.143.35:25667] by server-1.bemta-4.messagelabs.com id
	02/BD-08839-11F82115; Wed, 06 Feb 2013 17:12:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360170734!15444978!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12790 invoked from network); 6 Feb 2013 17:12:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:12:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="1209053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 17:12: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.297.1; Wed, 6 Feb 2013
	17:12:14 +0000
Message-ID: <1360170733.32479.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Wed, 6 Feb 2013 17:12:13 +0000
In-Reply-To: <1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/5] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 3225b2a..5e80400 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
>  typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
>  
> +/* XEN_SYSCTL_coverage_op */
> +/*
> + * Check if coverage informations are available
> + * return just success or error, no parameters
> + */
> +#define XEN_SYSCTL_COVERAGE_enabled        0

You can detect this by getting -ENOSYS from the hypercall, which is what
you would get running the tool on an older hypervisor, so you need to
handle it anyway.

> +
> +/*
> + * Get total size of information, to help allocate
> + * the buffer. The pointer points to a 32 bit value.
> + */
> +#define XEN_SYSCTL_COVERAGE_get_total_size 1
> +
> +/*
> + * Read coverage information in a single run
> + * You must use a tool to split them
> + */
> +#define XEN_SYSCTL_COVERAGE_read           2
> +
> +/*
> + * Reset all the coverage counters to 0
> + * No parameters.
> + */
> +#define XEN_SYSCTL_COVERAGE_reset          3

Any need for simultaneous read+reset?

> +struct xen_sysctl_coverage_op {
> +    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> +    union {
> +        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */

This one can just be a uint32_t I think, no need for it to be a
pointer/handle.

> +        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
> +    } u;
> +};
> +typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
> +
> +
>  struct xen_sysctl {
>      uint32_t cmd;
>  #define XEN_SYSCTL_readconsole                    1
> @@ -616,6 +652,7 @@ struct xen_sysctl {
>  #define XEN_SYSCTL_numainfo                      17
>  #define XEN_SYSCTL_cpupool_op                    18
>  #define XEN_SYSCTL_scheduler_op                  19
> +#define XEN_SYSCTL_coverage_op                   20
>      uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
>      union {
>          struct xen_sysctl_readconsole       readconsole;
> @@ -636,6 +673,7 @@ struct xen_sysctl {
>          struct xen_sysctl_lockprof_op       lockprof_op;
>          struct xen_sysctl_cpupool_op        cpupool_op;
>          struct xen_sysctl_scheduler_op      scheduler_op;
> +        struct xen_sysctl_coverage_op       coverage_op;
>          uint8_t                             pad[128];
>      } u;
>  };



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

From xen-devel-bounces@lists.xen.org Wed Feb 06 17:14:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17: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 1U38ZY-0008TZ-0O; Wed, 06 Feb 2013 17:14:12 +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 1U38ZW-0008TO-IU
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:14:10 +0000
Received: from [85.158.143.35:31424] by server-2.bemta-4.messagelabs.com id
	DF/A0-01597-16F82115; Wed, 06 Feb 2013 17:14:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360170780!14342111!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTgyMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28139 invoked from network); 6 Feb 2013 17:13:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 17:13:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16HCx5t030382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 17:13:00 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
	r16HCwpL007894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 17:12:58 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
	r16HCwpI011328; Wed, 6 Feb 2013 11:12:58 -0600
Received: from konrad-lan.dumpdata.com (/67.186.155.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 09:12:57 -0800
Date: Wed, 6 Feb 2013 12:12:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130206171254.GE24458@konrad-lan.dumpdata.com>
References: <511299A902000078000BC944@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511299A902000078000BC944@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: notify hypervisor about
 devices intended to be assigned to 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 Wed, Feb 06, 2013 at 04:58:01PM +0000, Jan Beulich wrote:
> For MSI-X capable devices the hypervisor wants to write protect the
> MSI-X table and PBA, yet it can't assume that resources have been
> assigned to their final values at device enumeration time. Thus have
> pciback do that notification, as having the device controlled by it is
> a prerequisite to assigning the device to guests anyway.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  arch/x86/include/asm/xen/hypercall.h |    4 +-
>  drivers/xen/fallback.c               |    3 +
>  drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++---------
>  include/xen/interface/physdev.h      |    6 +++
>  4 files changed, 54 insertions(+), 18 deletions(-)
> 
> --- 3.8-rc6/arch/x86/include/asm/xen/hypercall.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/include/asm/xen/hypercall.h
> @@ -382,14 +382,14 @@ HYPERVISOR_console_io(int cmd, int count
>  	return _hypercall3(int, console_io, cmd, count, str);
>  }
>  
> -extern int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +extern int __must_check xen_physdev_op_compat(int, void *);
>  
>  static inline int
>  HYPERVISOR_physdev_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  	if (unlikely(rc == -ENOSYS))
> -		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
> +		rc = xen_physdev_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> --- 3.8-rc6/drivers/xen/fallback.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c
> @@ -44,7 +44,7 @@ int xen_event_channel_op_compat(int cmd,
>  }
>  EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
>  
> -int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +int xen_physdev_op_compat(int cmd, void *arg)
>  {
>  	struct physdev_op op;
>  	int rc;
> @@ -78,3 +78,4 @@ int HYPERVISOR_physdev_op_compat(int cmd
>  
>  	return rc;
>  }
> +EXPORT_SYMBOL_GPL(xen_physdev_op_compat);
> --- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c
> @@ -17,6 +17,7 @@
>  #include <xen/events.h>
>  #include <asm/xen/pci.h>
>  #include <asm/xen/hypervisor.h>
> +#include <xen/interface/physdev.h>
>  #include "pciback.h"
>  #include "conf_space.h"
>  #include "conf_space_quirks.h"
> @@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de
>  static void pcistub_device_release(struct kref *kref)
>  {
>  	struct pcistub_device *psdev;
> +	struct pci_dev *dev;
>  	struct xen_pcibk_dev_data *dev_data;
>  
>  	psdev = container_of(kref, struct pcistub_device, kref);
> -	dev_data = pci_get_drvdata(psdev->dev);
> +	dev = psdev->dev;
> +	dev_data = pci_get_drvdata(dev);
>  
> -	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
> +	dev_dbg(&dev->dev, "pcistub_device_release\n");
>  
> -	xen_unregister_device_domain_owner(psdev->dev);
> +	xen_unregister_device_domain_owner(dev);
>  
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> -	__pci_reset_function_locked(psdev->dev);
> -	if (pci_load_and_free_saved_state(psdev->dev,
> -					  &dev_data->pci_saved_state)) {
> -		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> -		pci_restore_state(psdev->dev);
> +	__pci_reset_function_locked(dev);
> +	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
> +		dev_dbg(&dev->dev, "Could not reload PCI state\n");
> +	else
> +		pci_restore_state(dev);
> +
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +		int err = HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
> +						&ppdev);
> +
> +		if (err)
> +			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
> +				 err);
> +	}
>  
>  	/* Disable the device */
> -	xen_pcibk_reset_device(psdev->dev);
> +	xen_pcibk_reset_device(dev);
>  
>  	kfree(dev_data);
> -	pci_set_drvdata(psdev->dev, NULL);
> +	pci_set_drvdata(dev, NULL);
>  
>  	/* Clean-up the device */
> -	xen_pcibk_config_free_dyn_fields(psdev->dev);
> -	xen_pcibk_config_free_dev(psdev->dev);
> +	xen_pcibk_config_free_dyn_fields(dev);
> +	xen_pcibk_config_free_dev(dev);
>  
> -	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> -	pci_dev_put(psdev->dev);
> +	dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +	pci_dev_put(dev);
>  
>  	kfree(psdev);
>  }
> @@ -355,6 +371,19 @@ static int pcistub_init_device(struct pc
>  	if (err)
>  		goto config_release;
>  
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +
> +		err = HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msix, &ppdev);
> +		if (err)
> +			dev_err(&dev->dev, "MSI-X preparation failed (%d)\n",
> +				err);
> +	}
> +
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
> --- 3.8-rc6/include/xen/interface/physdev.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/include/xen/interface/physdev.h
> @@ -251,6 +251,12 @@ struct physdev_pci_device_add {
>  
>  #define PHYSDEVOP_pci_device_remove     26
>  #define PHYSDEVOP_restore_msi_ext       27
> +/*
> + * Dom0 should use these two to announce MMIO resources assigned to
> + * MSI-X capable devices won't (prepare) or may (release) change.
> + */
> +#define PHYSDEVOP_prepare_msix          30
> +#define PHYSDEVOP_release_msix          31
>  struct physdev_pci_device {
>      /* IN */
>      uint16_t seg;
> 
> 

> xen-pciback: notify hypervisor about devices intended to be assigned to guests
> 
> For MSI-X capable devices the hypervisor wants to write protect the
> MSI-X table and PBA, yet it can't assume that resources have been
> assigned to their final values at device enumeration time. Thus have
> pciback do that notification, as having the device controlled by it is
> a prerequisite to assigning the device to guests anyway.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  arch/x86/include/asm/xen/hypercall.h |    4 +-
>  drivers/xen/fallback.c               |    3 +
>  drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++---------
>  include/xen/interface/physdev.h      |    6 +++
>  4 files changed, 54 insertions(+), 18 deletions(-)
> 
> --- 3.8-rc6/arch/x86/include/asm/xen/hypercall.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/include/asm/xen/hypercall.h
> @@ -382,14 +382,14 @@ HYPERVISOR_console_io(int cmd, int count
>  	return _hypercall3(int, console_io, cmd, count, str);
>  }
>  
> -extern int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +extern int __must_check xen_physdev_op_compat(int, void *);
>  
>  static inline int
>  HYPERVISOR_physdev_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  	if (unlikely(rc == -ENOSYS))
> -		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
> +		rc = xen_physdev_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> --- 3.8-rc6/drivers/xen/fallback.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c
> @@ -44,7 +44,7 @@ int xen_event_channel_op_compat(int cmd,
>  }
>  EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
>  
> -int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +int xen_physdev_op_compat(int cmd, void *arg)
>  {
>  	struct physdev_op op;
>  	int rc;
> @@ -78,3 +78,4 @@ int HYPERVISOR_physdev_op_compat(int cmd
>  
>  	return rc;
>  }
> +EXPORT_SYMBOL_GPL(xen_physdev_op_compat);
> --- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c
> @@ -17,6 +17,7 @@
>  #include <xen/events.h>
>  #include <asm/xen/pci.h>
>  #include <asm/xen/hypervisor.h>
> +#include <xen/interface/physdev.h>
>  #include "pciback.h"
>  #include "conf_space.h"
>  #include "conf_space_quirks.h"
> @@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de
>  static void pcistub_device_release(struct kref *kref)
>  {
>  	struct pcistub_device *psdev;
> +	struct pci_dev *dev;
>  	struct xen_pcibk_dev_data *dev_data;
>  
>  	psdev = container_of(kref, struct pcistub_device, kref);
> -	dev_data = pci_get_drvdata(psdev->dev);
> +	dev = psdev->dev;
> +	dev_data = pci_get_drvdata(dev);
>  
> -	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
> +	dev_dbg(&dev->dev, "pcistub_device_release\n");
>  
> -	xen_unregister_device_domain_owner(psdev->dev);
> +	xen_unregister_device_domain_owner(dev);
>  
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> -	__pci_reset_function_locked(psdev->dev);
> -	if (pci_load_and_free_saved_state(psdev->dev,
> -					  &dev_data->pci_saved_state)) {
> -		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> -		pci_restore_state(psdev->dev);
> +	__pci_reset_function_locked(dev);
> +	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
> +		dev_dbg(&dev->dev, "Could not reload PCI state\n");
> +	else
> +		pci_restore_state(dev);
> +
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +		int err = HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
> +						&ppdev);
> +
> +		if (err)
> +			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
> +				 err);
> +	}

Perhaps it should be more off:

		if (err) {
			if (err == -ENOSYS)
				dev_info(&dev->dev,"MSI-X release
hypercall not supported.");
			else
				dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
					 err);
				
>  
>  	/* Disable the device */
> -	xen_pcibk_reset_device(psdev->dev);
> +	xen_pcibk_reset_device(dev);
>  
>  	kfree(dev_data);
> -	pci_set_drvdata(psdev->dev, NULL);
> +	pci_set_drvdata(dev, NULL);
>  
>  	/* Clean-up the device */
> -	xen_pcibk_config_free_dyn_fields(psdev->dev);
> -	xen_pcibk_config_free_dev(psdev->dev);
> +	xen_pcibk_config_free_dyn_fields(dev);
> +	xen_pcibk_config_free_dev(dev);
>  
> -	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> -	pci_dev_put(psdev->dev);
> +	dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +	pci_dev_put(dev);
>  
>  	kfree(psdev);
>  }
> @@ -355,6 +371,19 @@ static int pcistub_init_device(struct pc
>  	if (err)
>  		goto config_release;
>  
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +
> +		err = HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msix, &ppdev);
> +		if (err)
> +			dev_err(&dev->dev, "MSI-X preparation failed (%d)\n",
> +				err);
> +	}
> +
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
> --- 3.8-rc6/include/xen/interface/physdev.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/include/xen/interface/physdev.h
> @@ -251,6 +251,12 @@ struct physdev_pci_device_add {
>  
>  #define PHYSDEVOP_pci_device_remove     26
>  #define PHYSDEVOP_restore_msi_ext       27
> +/*
> + * Dom0 should use these two to announce MMIO resources assigned to
> + * MSI-X capable devices won't (prepare) or may (release) change.
> + */
> +#define PHYSDEVOP_prepare_msix          30
> +#define PHYSDEVOP_release_msix          31
>  struct physdev_pci_device {
>      /* IN */
>      uint16_t seg;


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 17:14:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17: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 1U38ZY-0008TZ-0O; Wed, 06 Feb 2013 17:14:12 +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 1U38ZW-0008TO-IU
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:14:10 +0000
Received: from [85.158.143.35:31424] by server-2.bemta-4.messagelabs.com id
	DF/A0-01597-16F82115; Wed, 06 Feb 2013 17:14:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360170780!14342111!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTgyMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28139 invoked from network); 6 Feb 2013 17:13:02 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 17:13:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16HCx5t030382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 17:13:00 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
	r16HCwpL007894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 17:12:58 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
	r16HCwpI011328; Wed, 6 Feb 2013 11:12:58 -0600
Received: from konrad-lan.dumpdata.com (/67.186.155.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 09:12:57 -0800
Date: Wed, 6 Feb 2013 12:12:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130206171254.GE24458@konrad-lan.dumpdata.com>
References: <511299A902000078000BC944@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511299A902000078000BC944@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: notify hypervisor about
 devices intended to be assigned to 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 Wed, Feb 06, 2013 at 04:58:01PM +0000, Jan Beulich wrote:
> For MSI-X capable devices the hypervisor wants to write protect the
> MSI-X table and PBA, yet it can't assume that resources have been
> assigned to their final values at device enumeration time. Thus have
> pciback do that notification, as having the device controlled by it is
> a prerequisite to assigning the device to guests anyway.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  arch/x86/include/asm/xen/hypercall.h |    4 +-
>  drivers/xen/fallback.c               |    3 +
>  drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++---------
>  include/xen/interface/physdev.h      |    6 +++
>  4 files changed, 54 insertions(+), 18 deletions(-)
> 
> --- 3.8-rc6/arch/x86/include/asm/xen/hypercall.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/include/asm/xen/hypercall.h
> @@ -382,14 +382,14 @@ HYPERVISOR_console_io(int cmd, int count
>  	return _hypercall3(int, console_io, cmd, count, str);
>  }
>  
> -extern int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +extern int __must_check xen_physdev_op_compat(int, void *);
>  
>  static inline int
>  HYPERVISOR_physdev_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  	if (unlikely(rc == -ENOSYS))
> -		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
> +		rc = xen_physdev_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> --- 3.8-rc6/drivers/xen/fallback.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c
> @@ -44,7 +44,7 @@ int xen_event_channel_op_compat(int cmd,
>  }
>  EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
>  
> -int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +int xen_physdev_op_compat(int cmd, void *arg)
>  {
>  	struct physdev_op op;
>  	int rc;
> @@ -78,3 +78,4 @@ int HYPERVISOR_physdev_op_compat(int cmd
>  
>  	return rc;
>  }
> +EXPORT_SYMBOL_GPL(xen_physdev_op_compat);
> --- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c
> @@ -17,6 +17,7 @@
>  #include <xen/events.h>
>  #include <asm/xen/pci.h>
>  #include <asm/xen/hypervisor.h>
> +#include <xen/interface/physdev.h>
>  #include "pciback.h"
>  #include "conf_space.h"
>  #include "conf_space_quirks.h"
> @@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de
>  static void pcistub_device_release(struct kref *kref)
>  {
>  	struct pcistub_device *psdev;
> +	struct pci_dev *dev;
>  	struct xen_pcibk_dev_data *dev_data;
>  
>  	psdev = container_of(kref, struct pcistub_device, kref);
> -	dev_data = pci_get_drvdata(psdev->dev);
> +	dev = psdev->dev;
> +	dev_data = pci_get_drvdata(dev);
>  
> -	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
> +	dev_dbg(&dev->dev, "pcistub_device_release\n");
>  
> -	xen_unregister_device_domain_owner(psdev->dev);
> +	xen_unregister_device_domain_owner(dev);
>  
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> -	__pci_reset_function_locked(psdev->dev);
> -	if (pci_load_and_free_saved_state(psdev->dev,
> -					  &dev_data->pci_saved_state)) {
> -		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> -		pci_restore_state(psdev->dev);
> +	__pci_reset_function_locked(dev);
> +	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
> +		dev_dbg(&dev->dev, "Could not reload PCI state\n");
> +	else
> +		pci_restore_state(dev);
> +
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +		int err = HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
> +						&ppdev);
> +
> +		if (err)
> +			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
> +				 err);
> +	}
>  
>  	/* Disable the device */
> -	xen_pcibk_reset_device(psdev->dev);
> +	xen_pcibk_reset_device(dev);
>  
>  	kfree(dev_data);
> -	pci_set_drvdata(psdev->dev, NULL);
> +	pci_set_drvdata(dev, NULL);
>  
>  	/* Clean-up the device */
> -	xen_pcibk_config_free_dyn_fields(psdev->dev);
> -	xen_pcibk_config_free_dev(psdev->dev);
> +	xen_pcibk_config_free_dyn_fields(dev);
> +	xen_pcibk_config_free_dev(dev);
>  
> -	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> -	pci_dev_put(psdev->dev);
> +	dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +	pci_dev_put(dev);
>  
>  	kfree(psdev);
>  }
> @@ -355,6 +371,19 @@ static int pcistub_init_device(struct pc
>  	if (err)
>  		goto config_release;
>  
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +
> +		err = HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msix, &ppdev);
> +		if (err)
> +			dev_err(&dev->dev, "MSI-X preparation failed (%d)\n",
> +				err);
> +	}
> +
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
> --- 3.8-rc6/include/xen/interface/physdev.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/include/xen/interface/physdev.h
> @@ -251,6 +251,12 @@ struct physdev_pci_device_add {
>  
>  #define PHYSDEVOP_pci_device_remove     26
>  #define PHYSDEVOP_restore_msi_ext       27
> +/*
> + * Dom0 should use these two to announce MMIO resources assigned to
> + * MSI-X capable devices won't (prepare) or may (release) change.
> + */
> +#define PHYSDEVOP_prepare_msix          30
> +#define PHYSDEVOP_release_msix          31
>  struct physdev_pci_device {
>      /* IN */
>      uint16_t seg;
> 
> 

> xen-pciback: notify hypervisor about devices intended to be assigned to guests
> 
> For MSI-X capable devices the hypervisor wants to write protect the
> MSI-X table and PBA, yet it can't assume that resources have been
> assigned to their final values at device enumeration time. Thus have
> pciback do that notification, as having the device controlled by it is
> a prerequisite to assigning the device to guests anyway.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  arch/x86/include/asm/xen/hypercall.h |    4 +-
>  drivers/xen/fallback.c               |    3 +
>  drivers/xen/xen-pciback/pci_stub.c   |   59 ++++++++++++++++++++++++++---------
>  include/xen/interface/physdev.h      |    6 +++
>  4 files changed, 54 insertions(+), 18 deletions(-)
> 
> --- 3.8-rc6/arch/x86/include/asm/xen/hypercall.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/arch/x86/include/asm/xen/hypercall.h
> @@ -382,14 +382,14 @@ HYPERVISOR_console_io(int cmd, int count
>  	return _hypercall3(int, console_io, cmd, count, str);
>  }
>  
> -extern int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +extern int __must_check xen_physdev_op_compat(int, void *);
>  
>  static inline int
>  HYPERVISOR_physdev_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  	if (unlikely(rc == -ENOSYS))
> -		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
> +		rc = xen_physdev_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> --- 3.8-rc6/drivers/xen/fallback.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/fallback.c
> @@ -44,7 +44,7 @@ int xen_event_channel_op_compat(int cmd,
>  }
>  EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
>  
> -int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +int xen_physdev_op_compat(int cmd, void *arg)
>  {
>  	struct physdev_op op;
>  	int rc;
> @@ -78,3 +78,4 @@ int HYPERVISOR_physdev_op_compat(int cmd
>  
>  	return rc;
>  }
> +EXPORT_SYMBOL_GPL(xen_physdev_op_compat);
> --- 3.8-rc6/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/drivers/xen/xen-pciback/pci_stub.c
> @@ -17,6 +17,7 @@
>  #include <xen/events.h>
>  #include <asm/xen/pci.h>
>  #include <asm/xen/hypervisor.h>
> +#include <xen/interface/physdev.h>
>  #include "pciback.h"
>  #include "conf_space.h"
>  #include "conf_space_quirks.h"
> @@ -85,37 +86,52 @@ static struct pcistub_device *pcistub_de
>  static void pcistub_device_release(struct kref *kref)
>  {
>  	struct pcistub_device *psdev;
> +	struct pci_dev *dev;
>  	struct xen_pcibk_dev_data *dev_data;
>  
>  	psdev = container_of(kref, struct pcistub_device, kref);
> -	dev_data = pci_get_drvdata(psdev->dev);
> +	dev = psdev->dev;
> +	dev_data = pci_get_drvdata(dev);
>  
> -	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
> +	dev_dbg(&dev->dev, "pcistub_device_release\n");
>  
> -	xen_unregister_device_domain_owner(psdev->dev);
> +	xen_unregister_device_domain_owner(dev);
>  
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> -	__pci_reset_function_locked(psdev->dev);
> -	if (pci_load_and_free_saved_state(psdev->dev,
> -					  &dev_data->pci_saved_state)) {
> -		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> -		pci_restore_state(psdev->dev);
> +	__pci_reset_function_locked(dev);
> +	if (pci_load_and_free_saved_state(dev, &dev_data->pci_saved_state))
> +		dev_dbg(&dev->dev, "Could not reload PCI state\n");
> +	else
> +		pci_restore_state(dev);
> +
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +		int err = HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
> +						&ppdev);
> +
> +		if (err)
> +			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
> +				 err);
> +	}

Perhaps it should be more off:

		if (err) {
			if (err == -ENOSYS)
				dev_info(&dev->dev,"MSI-X release
hypercall not supported.");
			else
				dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
					 err);
				
>  
>  	/* Disable the device */
> -	xen_pcibk_reset_device(psdev->dev);
> +	xen_pcibk_reset_device(dev);
>  
>  	kfree(dev_data);
> -	pci_set_drvdata(psdev->dev, NULL);
> +	pci_set_drvdata(dev, NULL);
>  
>  	/* Clean-up the device */
> -	xen_pcibk_config_free_dyn_fields(psdev->dev);
> -	xen_pcibk_config_free_dev(psdev->dev);
> +	xen_pcibk_config_free_dyn_fields(dev);
> +	xen_pcibk_config_free_dev(dev);
>  
> -	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> -	pci_dev_put(psdev->dev);
> +	dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +	pci_dev_put(dev);
>  
>  	kfree(psdev);
>  }
> @@ -355,6 +371,19 @@ static int pcistub_init_device(struct pc
>  	if (err)
>  		goto config_release;
>  
> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
> +		struct physdev_pci_device ppdev = {
> +			.seg = pci_domain_nr(dev->bus),
> +			.bus = dev->bus->number,
> +			.devfn = dev->devfn
> +		};
> +
> +		err = HYPERVISOR_physdev_op(PHYSDEVOP_prepare_msix, &ppdev);
> +		if (err)
> +			dev_err(&dev->dev, "MSI-X preparation failed (%d)\n",
> +				err);
> +	}
> +
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
> --- 3.8-rc6/include/xen/interface/physdev.h
> +++ 3.8-rc6-xen-pciback-MSI-X-prepare/include/xen/interface/physdev.h
> @@ -251,6 +251,12 @@ struct physdev_pci_device_add {
>  
>  #define PHYSDEVOP_pci_device_remove     26
>  #define PHYSDEVOP_restore_msi_ext       27
> +/*
> + * Dom0 should use these two to announce MMIO resources assigned to
> + * MSI-X capable devices won't (prepare) or may (release) change.
> + */
> +#define PHYSDEVOP_prepare_msix          30
> +#define PHYSDEVOP_release_msix          31
>  struct physdev_pci_device {
>      /* IN */
>      uint16_t seg;


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 17:16:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17:16: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 1U38bj-0000C9-PH; Wed, 06 Feb 2013 17:16:27 +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 1U38bh-0000C2-NV
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:16:25 +0000
Received: from [85.158.143.35:44575] by server-3.bemta-4.messagelabs.com id
	20/5B-08920-9EF82115; Wed, 06 Feb 2013 17:16:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360170981!5164675!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA5MDY1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31973 invoked from network); 6 Feb 2013 17:16:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 17:16:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16HGJqN015369
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 17:16:19 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
	r16HGIKL010074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 17:16: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
	r16HGIaU011698; Wed, 6 Feb 2013 11:16:18 -0600
Received: from konrad-lan.dumpdata.com (/67.186.155.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 09:16:18 -0800
Date: Wed, 6 Feb 2013 12:16:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Message-ID: <20130206171615.GG24458@konrad-lan.dumpdata.com>
MIME-Version: 1.0
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: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.8-rc6-tag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7446508603522469215=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7446508603522469215==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB"
Content-Disposition: inline


--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.8-rc6-tag

Which has two fixes. One is a security fix wherein we would spam the kernel
printk buffer if one of the guests was misbehaving. The other is much tamer
and it was us only checking for one type of error from the IRQ subsystem (when
allocating new IRQs) instead of for all of them.

Please pull!

 drivers/xen/events.c                  |  4 ++--
 drivers/xen/xen-pciback/pciback_ops.c | 14 +++++++-------
 2 files changed, 9 insertions(+), 9 deletions(-)

Jan Beulich (1):
      xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

Wei Liu (1):
      xen: fix error handling path if xen_allocate_irq_dynamic fails


--DocE+STaALJfprDB
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJREo/bAAoJEFjIrFwIi8fJ8dkIAKpkiFYvHiqWLoVKstgcyd86
qkJ7ULG2Ltw+04evQ5ldEvk+Enq7yLeur8gx+M1n86b+Dit6RZP31FMmWQkzJ1kF
isXMTbW2plvsYMhP6E3+CRDou+PhU+a6Q3uhLRedc7TtlnAsvIeAW0C9+THWxMop
Az4HvrNCcfPY3KuE15mEU3jZ5DdQQfWgXCLKL7e4rcC2Fig1b8eAXcWWHrihhmtI
b4F0WPJpJd4JfEuq6zAzcramPaYUh1q3NnpZEpaJa2aze9Hux5ccF1I0JE1kHpIM
y8ztpXL96UzqQJSMNZ6aRwCjcMkpf43N6HpQpSwVYkd2vLUm3fHPiBS5B+8UR6M=
=JnhC
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--


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

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

--===============7446508603522469215==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 17:16:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17:16: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 1U38bj-0000C9-PH; Wed, 06 Feb 2013 17:16:27 +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 1U38bh-0000C2-NV
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:16:25 +0000
Received: from [85.158.143.35:44575] by server-3.bemta-4.messagelabs.com id
	20/5B-08920-9EF82115; Wed, 06 Feb 2013 17:16:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360170981!5164675!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjA5MDY1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31973 invoked from network); 6 Feb 2013 17:16:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 17:16:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16HGJqN015369
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 17:16:19 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
	r16HGIKL010074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 17:16: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
	r16HGIaU011698; Wed, 6 Feb 2013 11:16:18 -0600
Received: from konrad-lan.dumpdata.com (/67.186.155.227)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 09:16:18 -0800
Date: Wed, 6 Feb 2013 12:16:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Message-ID: <20130206171615.GG24458@konrad-lan.dumpdata.com>
MIME-Version: 1.0
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: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.8-rc6-tag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7446508603522469215=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7446508603522469215==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB"
Content-Disposition: inline


--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.8-rc6-tag

Which has two fixes. One is a security fix wherein we would spam the kernel
printk buffer if one of the guests was misbehaving. The other is much tamer
and it was us only checking for one type of error from the IRQ subsystem (when
allocating new IRQs) instead of for all of them.

Please pull!

 drivers/xen/events.c                  |  4 ++--
 drivers/xen/xen-pciback/pciback_ops.c | 14 +++++++-------
 2 files changed, 9 insertions(+), 9 deletions(-)

Jan Beulich (1):
      xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

Wei Liu (1):
      xen: fix error handling path if xen_allocate_irq_dynamic fails


--DocE+STaALJfprDB
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJREo/bAAoJEFjIrFwIi8fJ8dkIAKpkiFYvHiqWLoVKstgcyd86
qkJ7ULG2Ltw+04evQ5ldEvk+Enq7yLeur8gx+M1n86b+Dit6RZP31FMmWQkzJ1kF
isXMTbW2plvsYMhP6E3+CRDou+PhU+a6Q3uhLRedc7TtlnAsvIeAW0C9+THWxMop
Az4HvrNCcfPY3KuE15mEU3jZ5DdQQfWgXCLKL7e4rcC2Fig1b8eAXcWWHrihhmtI
b4F0WPJpJd4JfEuq6zAzcramPaYUh1q3NnpZEpaJa2aze9Hux5ccF1I0JE1kHpIM
y8ztpXL96UzqQJSMNZ6aRwCjcMkpf43N6HpQpSwVYkd2vLUm3fHPiBS5B+8UR6M=
=JnhC
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--


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

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

--===============7446508603522469215==--


From xen-devel-bounces@lists.xen.org Wed Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38de-0000Mg-0i; Wed, 06 Feb 2013 17:18: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 1U38dc-0000Ld-EZ
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:24 +0000
Received: from [85.158.139.211:54330] by server-4.bemta-5.messagelabs.com id
	E0/52-29496-F5092115; Wed, 06 Feb 2013 17:18:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4371 invoked from network); 6 Feb 2013 17:18:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513494"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-6H;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:15 +0000
Message-ID: <1360171098-1240-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] xen/netback: shutdown the ring if it
	contains garbage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 buggy or malicious frontend should not be able to confuse netback.
If we spot anything which is not as it should be then shutdown the
device and don't try to continue with the ring in a potentially
hostile state. Well behaved and non-hostile frontends will not be
penalised.

As well as making the existing checks for such errors fatal also add a
new check that ensures that there isn't an insane number of requests
on the ring (i.e. more than would fit in the ring). If the ring
contains garbage then previously is was possible to loop over this
insane number, getting an error each time and therefore not generating
any more pending requests and therefore not exiting the loop in
xen_netbk_tx_build_gops for an externded period.

Also turn various netdev_dbg calls which no precipitate a fatal error
into netdev_err, they are rate limited because the device is shutdown
afterwards.

This fixes at least one known DoS/softlockup of the backend domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/net/xen-netback/common.h    |    3 ++
 drivers/net/xen-netback/interface.c |   23 ++++++++-----
 drivers/net/xen-netback/netback.c   |   63 +++++++++++++++++++++++++---------
 3 files changed, 63 insertions(+), 26 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..9d7f172 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -151,6 +151,9 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
+/* Prevent the device from generating any further traffic. */
+void xenvif_carrier_off(struct xenvif *vif);
+
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b7d41f8..b8c5193 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -343,17 +343,22 @@ err:
 	return err;
 }
 
-void xenvif_disconnect(struct xenvif *vif)
+void xenvif_carrier_off(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
-	if (netif_carrier_ok(dev)) {
-		rtnl_lock();
-		netif_carrier_off(dev); /* discard queued packets */
-		if (netif_running(dev))
-			xenvif_down(vif);
-		rtnl_unlock();
-		xenvif_put(vif);
-	}
+
+	rtnl_lock();
+	netif_carrier_off(dev); /* discard queued packets */
+	if (netif_running(dev))
+		xenvif_down(vif);
+	rtnl_unlock();
+	xenvif_put(vif);
+}
+
+void xenvif_disconnect(struct xenvif *vif)
+{
+	if (netif_carrier_ok(vif->dev))
+		xenvif_carrier_off(vif);
 
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f2d6b78..1a449f9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -888,6 +888,13 @@ static void netbk_tx_err(struct xenvif *vif,
 	xenvif_put(vif);
 }
 
+static void netbk_fatal_tx_err(struct xenvif *vif)
+{
+	netdev_err(vif->dev, "fatal error; disabling device\n");
+	xenvif_carrier_off(vif);
+	xenvif_put(vif);
+}
+
 static int netbk_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
@@ -901,19 +908,22 @@ static int netbk_count_requests(struct xenvif *vif,
 
 	do {
 		if (frags >= work_to_do) {
-			netdev_dbg(vif->dev, "Need more frags\n");
+			netdev_err(vif->dev, "Need more frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
-			netdev_dbg(vif->dev, "Too many frags\n");
+			netdev_err(vif->dev, "Too many frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
 		       sizeof(*txp));
 		if (txp->size > first->size) {
-			netdev_dbg(vif->dev, "Frags galore\n");
+			netdev_err(vif->dev, "Frag is bigger than frame.\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
@@ -921,8 +931,9 @@ static int netbk_count_requests(struct xenvif *vif,
 		frags++;
 
 		if (unlikely((txp->offset + txp->size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev, "txp->offset: %x, size: %u\n",
+			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
@@ -1095,7 +1106,8 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 
 	do {
 		if (unlikely(work_to_do-- <= 0)) {
-			netdev_dbg(vif->dev, "Missing extra info\n");
+			netdev_err(vif->dev, "Missing extra info\n");
+			netbk_fatal_tx_err(vif);
 			return -EBADR;
 		}
 
@@ -1104,8 +1116,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 		if (unlikely(!extra.type ||
 			     extra.type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
 			vif->tx.req_cons = ++cons;
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "Invalid extra type: %d\n", extra.type);
+			netbk_fatal_tx_err(vif);
 			return -EINVAL;
 		}
 
@@ -1121,13 +1134,15 @@ static int netbk_set_skb_gso(struct xenvif *vif,
 			     struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
-		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
+		netdev_err(vif->dev, "GSO size must not be zero.\n");
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
 	/* Currently only TCPv4 S.O. is supported. */
 	if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) {
-		netdev_dbg(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netdev_err(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
@@ -1264,9 +1279,26 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
+		/*
+		 * This can sometimes happen because the test of
+		 * list_empty(net_schedule_list) at the top of the
+		 * loop is unlocked.  Just go back and have another
+		 * look.
+		 */
 		if (!vif)
 			continue;
 
+		if (vif->tx.sring->req_prod - vif->tx.req_cons >
+		    XEN_NETIF_TX_RING_SIZE) {
+			netdev_err(vif->dev,
+				   "Impossible number of requests. "
+				   "req_prod %d, req_cons %d, size %ld\n",
+				   vif->tx.sring->req_prod, vif->tx.req_cons,
+				   XEN_NETIF_TX_RING_SIZE);
+			netbk_fatal_tx_err(vif);
+			continue;
+		}
+
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
 			xenvif_put(vif);
@@ -1294,17 +1326,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			work_to_do = xen_netbk_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
-			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+			if (unlikely(work_to_do < 0))
 				continue;
-			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
-		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+		if (unlikely(ret < 0))
 			continue;
-		}
+
 		idx += ret;
 
 		if (unlikely(txreq.size < ETH_HLEN)) {
@@ -1316,11 +1345,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* No crossing a page as the payload mustn't fragment. */
 		if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			netbk_fatal_tx_err(vif);
 			continue;
 		}
 
@@ -1348,8 +1377,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
 			if (netbk_set_skb_gso(vif, skb, gso)) {
+				/* Failure in netbk_set_skb_gso is fatal. */
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
 				continue;
 			}
 		}
-- 
1.7.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 Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38de-0000Mg-0i; Wed, 06 Feb 2013 17:18: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 1U38dc-0000Ld-EZ
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:24 +0000
Received: from [85.158.139.211:54330] by server-4.bemta-5.messagelabs.com id
	E0/52-29496-F5092115; Wed, 06 Feb 2013 17:18:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4371 invoked from network); 6 Feb 2013 17:18:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513494"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-6H;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:15 +0000
Message-ID: <1360171098-1240-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] xen/netback: shutdown the ring if it
	contains garbage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 buggy or malicious frontend should not be able to confuse netback.
If we spot anything which is not as it should be then shutdown the
device and don't try to continue with the ring in a potentially
hostile state. Well behaved and non-hostile frontends will not be
penalised.

As well as making the existing checks for such errors fatal also add a
new check that ensures that there isn't an insane number of requests
on the ring (i.e. more than would fit in the ring). If the ring
contains garbage then previously is was possible to loop over this
insane number, getting an error each time and therefore not generating
any more pending requests and therefore not exiting the loop in
xen_netbk_tx_build_gops for an externded period.

Also turn various netdev_dbg calls which no precipitate a fatal error
into netdev_err, they are rate limited because the device is shutdown
afterwards.

This fixes at least one known DoS/softlockup of the backend domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/net/xen-netback/common.h    |    3 ++
 drivers/net/xen-netback/interface.c |   23 ++++++++-----
 drivers/net/xen-netback/netback.c   |   63 +++++++++++++++++++++++++---------
 3 files changed, 63 insertions(+), 26 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..9d7f172 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -151,6 +151,9 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
+/* Prevent the device from generating any further traffic. */
+void xenvif_carrier_off(struct xenvif *vif);
+
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b7d41f8..b8c5193 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -343,17 +343,22 @@ err:
 	return err;
 }
 
-void xenvif_disconnect(struct xenvif *vif)
+void xenvif_carrier_off(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
-	if (netif_carrier_ok(dev)) {
-		rtnl_lock();
-		netif_carrier_off(dev); /* discard queued packets */
-		if (netif_running(dev))
-			xenvif_down(vif);
-		rtnl_unlock();
-		xenvif_put(vif);
-	}
+
+	rtnl_lock();
+	netif_carrier_off(dev); /* discard queued packets */
+	if (netif_running(dev))
+		xenvif_down(vif);
+	rtnl_unlock();
+	xenvif_put(vif);
+}
+
+void xenvif_disconnect(struct xenvif *vif)
+{
+	if (netif_carrier_ok(vif->dev))
+		xenvif_carrier_off(vif);
 
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f2d6b78..1a449f9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -888,6 +888,13 @@ static void netbk_tx_err(struct xenvif *vif,
 	xenvif_put(vif);
 }
 
+static void netbk_fatal_tx_err(struct xenvif *vif)
+{
+	netdev_err(vif->dev, "fatal error; disabling device\n");
+	xenvif_carrier_off(vif);
+	xenvif_put(vif);
+}
+
 static int netbk_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
@@ -901,19 +908,22 @@ static int netbk_count_requests(struct xenvif *vif,
 
 	do {
 		if (frags >= work_to_do) {
-			netdev_dbg(vif->dev, "Need more frags\n");
+			netdev_err(vif->dev, "Need more frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
-			netdev_dbg(vif->dev, "Too many frags\n");
+			netdev_err(vif->dev, "Too many frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
 		       sizeof(*txp));
 		if (txp->size > first->size) {
-			netdev_dbg(vif->dev, "Frags galore\n");
+			netdev_err(vif->dev, "Frag is bigger than frame.\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
@@ -921,8 +931,9 @@ static int netbk_count_requests(struct xenvif *vif,
 		frags++;
 
 		if (unlikely((txp->offset + txp->size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev, "txp->offset: %x, size: %u\n",
+			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
@@ -1095,7 +1106,8 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 
 	do {
 		if (unlikely(work_to_do-- <= 0)) {
-			netdev_dbg(vif->dev, "Missing extra info\n");
+			netdev_err(vif->dev, "Missing extra info\n");
+			netbk_fatal_tx_err(vif);
 			return -EBADR;
 		}
 
@@ -1104,8 +1116,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 		if (unlikely(!extra.type ||
 			     extra.type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
 			vif->tx.req_cons = ++cons;
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "Invalid extra type: %d\n", extra.type);
+			netbk_fatal_tx_err(vif);
 			return -EINVAL;
 		}
 
@@ -1121,13 +1134,15 @@ static int netbk_set_skb_gso(struct xenvif *vif,
 			     struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
-		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
+		netdev_err(vif->dev, "GSO size must not be zero.\n");
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
 	/* Currently only TCPv4 S.O. is supported. */
 	if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) {
-		netdev_dbg(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netdev_err(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
@@ -1264,9 +1279,26 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
+		/*
+		 * This can sometimes happen because the test of
+		 * list_empty(net_schedule_list) at the top of the
+		 * loop is unlocked.  Just go back and have another
+		 * look.
+		 */
 		if (!vif)
 			continue;
 
+		if (vif->tx.sring->req_prod - vif->tx.req_cons >
+		    XEN_NETIF_TX_RING_SIZE) {
+			netdev_err(vif->dev,
+				   "Impossible number of requests. "
+				   "req_prod %d, req_cons %d, size %ld\n",
+				   vif->tx.sring->req_prod, vif->tx.req_cons,
+				   XEN_NETIF_TX_RING_SIZE);
+			netbk_fatal_tx_err(vif);
+			continue;
+		}
+
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
 			xenvif_put(vif);
@@ -1294,17 +1326,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			work_to_do = xen_netbk_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
-			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+			if (unlikely(work_to_do < 0))
 				continue;
-			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
-		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+		if (unlikely(ret < 0))
 			continue;
-		}
+
 		idx += ret;
 
 		if (unlikely(txreq.size < ETH_HLEN)) {
@@ -1316,11 +1345,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* No crossing a page as the payload mustn't fragment. */
 		if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			netbk_fatal_tx_err(vif);
 			continue;
 		}
 
@@ -1348,8 +1377,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
 			if (netbk_set_skb_gso(vif, skb, gso)) {
+				/* Failure in netbk_set_skb_gso is fatal. */
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
 				continue;
 			}
 		}
-- 
1.7.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 Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38dW-0000Kj-AE; Wed, 06 Feb 2013 17:18: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 1U38dV-0000KZ-2E
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:17 +0000
Received: from [85.158.139.83:51726] by server-11.bemta-5.messagelabs.com id
	8F/F7-19159-85092115; Wed, 06 Feb 2013 17:18:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360171095!30694438!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1797 invoked from network); 6 Feb 2013 17:18:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="1209292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 17:18: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.297.1; Wed, 6 Feb 2013
	17:18:02 +0000
Message-ID: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:01 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] XSA-39 CVE-2013-021[67]: Linux netback DoS
 via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen netback implementation contains a couple of flaws which can
allow a guest to cause a DoS in the backend domain, potentially
affecting other domains in the system.

CVE-2013-0216 is a failure to sanity check the ring producer/consumer
pointers which can allow a guest to cause netback to loop for an
extended period preventing other work from occurring.

CVE-2013-0217 is a memory leak on an error path which is guest
triggerable.

The following series contains the fixes for these issues, as previously
included in Xen Security Advisory 39:
http://lists.xen.org/archives/html/xen-announce/2013-02/msg00001.html

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38dW-0000Kj-AE; Wed, 06 Feb 2013 17:18: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 1U38dV-0000KZ-2E
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:17 +0000
Received: from [85.158.139.83:51726] by server-11.bemta-5.messagelabs.com id
	8F/F7-19159-85092115; Wed, 06 Feb 2013 17:18:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360171095!30694438!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1797 invoked from network); 6 Feb 2013 17:18:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="1209292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 17:18: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.297.1; Wed, 6 Feb 2013
	17:18:02 +0000
Message-ID: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:01 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/4] XSA-39 CVE-2013-021[67]: Linux netback DoS
 via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen netback implementation contains a couple of flaws which can
allow a guest to cause a DoS in the backend domain, potentially
affecting other domains in the system.

CVE-2013-0216 is a failure to sanity check the ring producer/consumer
pointers which can allow a guest to cause netback to loop for an
extended period preventing other work from occurring.

CVE-2013-0217 is a memory leak on an error path which is guest
triggerable.

The following series contains the fixes for these issues, as previously
included in Xen Security Advisory 39:
http://lists.xen.org/archives/html/xen-announce/2013-02/msg00001.html

Ian.


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

From xen-devel-bounces@lists.xen.org Wed Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38db-0000LZ-Nd; Wed, 06 Feb 2013 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.Campbell@citrix.com>) id 1U38dZ-0000LB-QO
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:22 +0000
Received: from [85.158.139.211:54215] by server-9.bemta-5.messagelabs.com id
	67/17-24440-D5092115; Wed, 06 Feb 2013 17:18:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4237 invoked from network); 6 Feb 2013 17:18:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513491"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-7L;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:17 +0000
Message-ID: <1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated memory
	on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/net/xen-netback/netback.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 975241e..1a99288 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -978,7 +978,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		pending_idx = netbk->pending_ring[index];
 		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
 		if (!page)
-			return NULL;
+			goto err;
 
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
@@ -1000,6 +1000,20 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	}
 
 	return gop;
+err:
+	/*
+	 * Unwind, freeing all pages and sending error
+	 * reponses.
+	 */
+	while (i-- > start) {
+		xen_netbk_idx_release(netbk, frag_get_pending_idx(&frags[i]),
+				      XEN_NETIF_RSP_ERROR);
+	}
+	/* The head too, if necessary. */
+	if (start)
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
+
+	return NULL;
 }
 
 static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
-- 
1.7.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 Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38db-0000LZ-Nd; Wed, 06 Feb 2013 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.Campbell@citrix.com>) id 1U38dZ-0000LB-QO
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:22 +0000
Received: from [85.158.139.211:54215] by server-9.bemta-5.messagelabs.com id
	67/17-24440-D5092115; Wed, 06 Feb 2013 17:18:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4237 invoked from network); 6 Feb 2013 17:18:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513491"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-7L;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:17 +0000
Message-ID: <1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated memory
	on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/net/xen-netback/netback.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 975241e..1a99288 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -978,7 +978,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		pending_idx = netbk->pending_ring[index];
 		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
 		if (!page)
-			return NULL;
+			goto err;
 
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
@@ -1000,6 +1000,20 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	}
 
 	return gop;
+err:
+	/*
+	 * Unwind, freeing all pages and sending error
+	 * reponses.
+	 */
+	while (i-- > start) {
+		xen_netbk_idx_release(netbk, frag_get_pending_idx(&frags[i]),
+				      XEN_NETIF_RSP_ERROR);
+	}
+	/* The head too, if necessary. */
+	if (start)
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
+
+	return NULL;
 }
 
 static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
-- 
1.7.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 Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38dc-0000Li-6I; Wed, 06 Feb 2013 17:18: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 1U38da-0000LB-Aq
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:22 +0000
Received: from [85.158.139.211:57581] by server-9.bemta-5.messagelabs.com id
	AC/17-24440-D5092115; Wed, 06 Feb 2013 17:18:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4281 invoked from network); 6 Feb 2013 17:18:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513492"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-6r;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:16 +0000
Message-ID: <1360171098-1240-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Matthew Daley <mattjd@gmail.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] xen/netback: don't leak pages on failure in
	xen_netbk_tx_check_gop.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Matthew Daley <mattjd@gmail.com>

Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/net/xen-netback/netback.c |   38 ++++++++++++------------------------
 1 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1a449f9..975241e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -147,7 +147,8 @@ void xen_netbk_remove_xenvif(struct xenvif *vif)
 	atomic_dec(&netbk->netfront_count);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -1007,30 +1008,20 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
-	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
 	int i, err, start;
 
 	/* Check status of header. */
 	err = gop->status;
-	if (unlikely(err)) {
-		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
-	}
+	if (unlikely(err))
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
 	start = (frag_get_pending_idx(&shinfo->frags[0]) == pending_idx);
 
 	for (i = start; i < nr_frags; i++) {
 		int j, newerr;
-		pending_ring_idx_t index;
 
 		pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
 
@@ -1039,16 +1030,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1056,10 +1043,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -1093,7 +1080,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(netbk->mmap_pages[pending_idx]);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 	}
 }
 
@@ -1477,7 +1464,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1529,7 +1516,8 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 	xen_netbk_tx_submit(netbk);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status)
 {
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
@@ -1543,7 +1531,7 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	vif = pending_tx_info->vif;
 
-	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
+	make_tx_response(vif, &pending_tx_info->req, status);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
-- 
1.7.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 Feb 06 17:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 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 1U38dc-0000Li-6I; Wed, 06 Feb 2013 17:18: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 1U38da-0000LB-Aq
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:22 +0000
Received: from [85.158.139.211:57581] by server-9.bemta-5.messagelabs.com id
	AC/17-24440-D5092115; Wed, 06 Feb 2013 17:18:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4281 invoked from network); 6 Feb 2013 17:18:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513492"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-6r;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:16 +0000
Message-ID: <1360171098-1240-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Matthew Daley <mattjd@gmail.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] xen/netback: don't leak pages on failure in
	xen_netbk_tx_check_gop.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Matthew Daley <mattjd@gmail.com>

Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/net/xen-netback/netback.c |   38 ++++++++++++------------------------
 1 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1a449f9..975241e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -147,7 +147,8 @@ void xen_netbk_remove_xenvif(struct xenvif *vif)
 	atomic_dec(&netbk->netfront_count);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -1007,30 +1008,20 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
-	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
 	int i, err, start;
 
 	/* Check status of header. */
 	err = gop->status;
-	if (unlikely(err)) {
-		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
-	}
+	if (unlikely(err))
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
 	start = (frag_get_pending_idx(&shinfo->frags[0]) == pending_idx);
 
 	for (i = start; i < nr_frags; i++) {
 		int j, newerr;
-		pending_ring_idx_t index;
 
 		pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
 
@@ -1039,16 +1030,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1056,10 +1043,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -1093,7 +1080,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(netbk->mmap_pages[pending_idx]);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 	}
 }
 
@@ -1477,7 +1464,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1529,7 +1516,8 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 	xen_netbk_tx_submit(netbk);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status)
 {
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
@@ -1543,7 +1531,7 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	vif = pending_tx_info->vif;
 
-	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
+	make_tx_response(vif, &pending_tx_info->req, status);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
-- 
1.7.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 Feb 06 17:18:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17: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 1U38dc-0000Lt-IY; Wed, 06 Feb 2013 17:18: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 1U38db-0000LJ-19
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:23 +0000
Received: from [85.158.139.211:54283] by server-13.bemta-5.messagelabs.com id
	60/37-06769-E5092115; Wed, 06 Feb 2013 17:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4352 invoked from network); 6 Feb 2013 17:18:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513493"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-7o;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:18 +0000
Message-ID: <1360171098-1240-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] netback: correct netbk_tx_err to handle
	wrap around.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1a99288..28d5e06 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -880,7 +880,7 @@ static void netbk_tx_err(struct xenvif *vif,
 
 	do {
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		if (cons >= end)
+		if (cons == end)
 			break;
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (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 Feb 06 17:18:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 17: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 1U38dc-0000Lt-IY; Wed, 06 Feb 2013 17:18: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 1U38db-0000LJ-19
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:18:23 +0000
Received: from [85.158.139.211:54283] by server-13.bemta-5.messagelabs.com id
	60/37-06769-E5092115; Wed, 06 Feb 2013 17:18:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360171099!18592053!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4352 invoked from network); 6 Feb 2013 17:18:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 17:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; 
   d="scan'208";a="6513493"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	06 Feb 2013 17:18:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 6 Feb 2013 12:18:18 -0500
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 1U38dW-0003mH-7o;
	Wed, 06 Feb 2013 17:18:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Wed, 6 Feb 2013 17:18:18 +0000
Message-ID: <1360171098-1240-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] netback: correct netbk_tx_err to handle
	wrap around.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1a99288..28d5e06 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -880,7 +880,7 @@ static void netbk_tx_err(struct xenvif *vif,
 
 	do {
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		if (cons >= end)
+		if (cons == end)
 			break;
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (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 Feb 06 18:06:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:06: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 1U39O2-00038t-Vi; Wed, 06 Feb 2013 18:06:22 +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 1U39O0-00037x-TB
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:20 +0000
Received: from [85.158.143.99:46117] by server-2.bemta-4.messagelabs.com id
	EF/DD-01597-C9B92115; Wed, 06 Feb 2013 18:06:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360173973!24162022!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15403 invoked from network); 6 Feb 2013 18:06:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:13 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:13 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:33 +0100
Message-ID: <1360173877-12696-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/4] add vif-route support to libxl/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

Support for vif-route was missing in libxl, this patch series adds a
gatewaydev/netdev vif option and also allows setting a default
gatewaydev in xl.conf global configuration file.

vif-route doesn't support HVM domains because it doesn't support the
"add" or "remove" actions.

I would like to request some testing from people that actually use
this network mode.

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:06: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 1U39O2-00038t-Vi; Wed, 06 Feb 2013 18:06:22 +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 1U39O0-00037x-TB
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:20 +0000
Received: from [85.158.143.99:46117] by server-2.bemta-4.messagelabs.com id
	EF/DD-01597-C9B92115; Wed, 06 Feb 2013 18:06:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360173973!24162022!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15403 invoked from network); 6 Feb 2013 18:06:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:13 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:13 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:33 +0100
Message-ID: <1360173877-12696-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/4] add vif-route support to libxl/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

Support for vif-route was missing in libxl, this patch series adds a
gatewaydev/netdev vif option and also allows setting a default
gatewaydev in xl.conf global configuration file.

vif-route doesn't support HVM domains because it doesn't support the
"add" or "remove" actions.

I would like to request some testing from people that actually use
this network mode.

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

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:06: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 1U39Nz-00038A-Oz; Wed, 06 Feb 2013 18:06:19 +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 1U39Ny-00037w-Ji
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:18 +0000
Received: from [85.158.143.35:59730] by server-3.bemta-4.messagelabs.com id
	15/77-08920-99B92115; Wed, 06 Feb 2013 18:06:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360173975!15450760!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13823 invoked from network); 6 Feb 2013 18:06:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:15 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:15 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:36 +0100
Message-ID: <1360173877-12696-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 3/4] xl: add vif.default.bridge
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBpcyBhIHJlcGxhY2VtZW50IGZvciBkZWZhdWx0YnJpZGdlIHhsLmNvbmYgb3B0aW9uLiBU
aGUgbm93CmRlcHJlY2F0ZWQgZGVmYXVsdGJyaWRnZSBpcyBzdGlsbCBzdXBwb3J0ZWQuCgpTaWdu
ZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEdl
b3JnZSBEdW5sYXAgPEdlb3JnZS5EdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IElhbiBDYW1wYmVs
bCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ci0tLQogdG9vbHMvZXhhbXBsZXMveGwuY29uZiB8
ICAgIDMgKysrCiB0b29scy9saWJ4bC94bC5jICAgICAgIHwgICAxMyArKysrKysrKysrKy0tCiAy
IGZpbGVzIGNoYW5nZWQsIDE0IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0t
Z2l0IGEvdG9vbHMvZXhhbXBsZXMveGwuY29uZiBiL3Rvb2xzL2V4YW1wbGVzL3hsLmNvbmYKaW5k
ZXggOWEwM2ZmZi4uNDQ1MTE3NiAxMDA2NDQKLS0tIGEvdG9vbHMvZXhhbXBsZXMveGwuY29uZgor
KysgYi90b29scy9leGFtcGxlcy94bC5jb25mCkBAIC0yMywzICsyMyw2IEBACiAKICMgZGVmYXVs
dCBnYXRld2F5IGRldmljZSB0byB1c2Ugd2l0aCB2aWYtcm91dGUgaG90cGx1ZyBzY3JpcHQKICN2
aWYuZGVmYXVsdC5nYXRld2F5ZGV2PSJldGgwIgorCisjIGRlZmF1bHQgYnJpZGdlIGRldmljZSB0
byB1c2Ugd2l0aCB2aWYtYnJpZGdlIGhvdHBsdWcgc2NyaXB0cworI3ZpZi5kZWZhdWx0LmJyaWRn
ZT0iYnJpZGdlMCIKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsLmMgYi90b29scy9saWJ4bC94
bC5jCmluZGV4IGY2NTcyMTYuLjEwMGFiMzIgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsLmMK
KysrIGIvdG9vbHMvbGlieGwveGwuYwpAQCAtODksOCArODksMTcgQEAgc3RhdGljIHZvaWQgcGFy
c2VfZ2xvYmFsX2NvbmZpZyhjb25zdCBjaGFyICpjb25maWdmaWxlLAogICAgIGlmICgheGx1X2Nm
Z19nZXRfc3RyaW5nIChjb25maWcsICJ2aWZzY3JpcHQiLCAmYnVmLCAwKSkKICAgICAgICAgZGVm
YXVsdF92aWZzY3JpcHQgPSBzdHJkdXAoYnVmKTsKIAotICAgIGlmICgheGx1X2NmZ19nZXRfc3Ry
aW5nIChjb25maWcsICJkZWZhdWx0YnJpZGdlIiwgJmJ1ZiwgMCkpCi0JZGVmYXVsdF9icmlkZ2Ug
PSBzdHJkdXAoYnVmKTsKKyAgICBpZiAoIXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiZGVm
YXVsdGJyaWRnZSIsICZidWYsIDApKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAidGhlIGds
b2JhbCBjb25maWcgb3B0aW9uIGRlZmF1bHRicmlkZ2UgaXMgZGVwcmVjYXRlZCwgIgorICAgICAg
ICAgICAgICAgICAgICAgICAgInBsZWFzZSBzd2l0Y2ggdG8gdmlmLmRlZmF1bHQuYnJpZGdlXG4i
KTsKKyAgICAgICAgZnJlZShkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgIGRlZmF1bHRfYnJpZGdl
ID0gc3RyZHVwKGJ1Zik7CisgICAgfQorCisgICAgaWYgKCF4bHVfY2ZnX2dldF9zdHJpbmcgKGNv
bmZpZywgInZpZi5kZWZhdWx0LmJyaWRnZSIsICZidWYsIDApKSB7CisgICAgICAgIGZyZWUoZGVm
YXVsdF9icmlkZ2UpOworICAgICAgICBkZWZhdWx0X2JyaWRnZSA9IHN0cmR1cChidWYpOworICAg
IH0KIAogICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWYuZGVmYXVsdC5n
YXRld2F5ZGV2IiwgJmJ1ZiwgMCkpCiAgICAgICAgIGRlZmF1bHRfZ2F0ZXdheWRldiA9IHN0cmR1
cChidWYpOwotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:06: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 1U39Nz-00038A-Oz; Wed, 06 Feb 2013 18:06:19 +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 1U39Ny-00037w-Ji
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:18 +0000
Received: from [85.158.143.35:59730] by server-3.bemta-4.messagelabs.com id
	15/77-08920-99B92115; Wed, 06 Feb 2013 18:06:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360173975!15450760!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13823 invoked from network); 6 Feb 2013 18:06:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:15 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:15 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:36 +0100
Message-ID: <1360173877-12696-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 3/4] xl: add vif.default.bridge
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBpcyBhIHJlcGxhY2VtZW50IGZvciBkZWZhdWx0YnJpZGdlIHhsLmNvbmYgb3B0aW9uLiBU
aGUgbm93CmRlcHJlY2F0ZWQgZGVmYXVsdGJyaWRnZSBpcyBzdGlsbCBzdXBwb3J0ZWQuCgpTaWdu
ZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEdl
b3JnZSBEdW5sYXAgPEdlb3JnZS5EdW5sYXBAZXUuY2l0cml4LmNvbT4KQ2M6IElhbiBDYW1wYmVs
bCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Ci0tLQogdG9vbHMvZXhhbXBsZXMveGwuY29uZiB8
ICAgIDMgKysrCiB0b29scy9saWJ4bC94bC5jICAgICAgIHwgICAxMyArKysrKysrKysrKy0tCiAy
IGZpbGVzIGNoYW5nZWQsIDE0IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0t
Z2l0IGEvdG9vbHMvZXhhbXBsZXMveGwuY29uZiBiL3Rvb2xzL2V4YW1wbGVzL3hsLmNvbmYKaW5k
ZXggOWEwM2ZmZi4uNDQ1MTE3NiAxMDA2NDQKLS0tIGEvdG9vbHMvZXhhbXBsZXMveGwuY29uZgor
KysgYi90b29scy9leGFtcGxlcy94bC5jb25mCkBAIC0yMywzICsyMyw2IEBACiAKICMgZGVmYXVs
dCBnYXRld2F5IGRldmljZSB0byB1c2Ugd2l0aCB2aWYtcm91dGUgaG90cGx1ZyBzY3JpcHQKICN2
aWYuZGVmYXVsdC5nYXRld2F5ZGV2PSJldGgwIgorCisjIGRlZmF1bHQgYnJpZGdlIGRldmljZSB0
byB1c2Ugd2l0aCB2aWYtYnJpZGdlIGhvdHBsdWcgc2NyaXB0cworI3ZpZi5kZWZhdWx0LmJyaWRn
ZT0iYnJpZGdlMCIKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsLmMgYi90b29scy9saWJ4bC94
bC5jCmluZGV4IGY2NTcyMTYuLjEwMGFiMzIgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsLmMK
KysrIGIvdG9vbHMvbGlieGwveGwuYwpAQCAtODksOCArODksMTcgQEAgc3RhdGljIHZvaWQgcGFy
c2VfZ2xvYmFsX2NvbmZpZyhjb25zdCBjaGFyICpjb25maWdmaWxlLAogICAgIGlmICgheGx1X2Nm
Z19nZXRfc3RyaW5nIChjb25maWcsICJ2aWZzY3JpcHQiLCAmYnVmLCAwKSkKICAgICAgICAgZGVm
YXVsdF92aWZzY3JpcHQgPSBzdHJkdXAoYnVmKTsKIAotICAgIGlmICgheGx1X2NmZ19nZXRfc3Ry
aW5nIChjb25maWcsICJkZWZhdWx0YnJpZGdlIiwgJmJ1ZiwgMCkpCi0JZGVmYXVsdF9icmlkZ2Ug
PSBzdHJkdXAoYnVmKTsKKyAgICBpZiAoIXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiZGVm
YXVsdGJyaWRnZSIsICZidWYsIDApKSB7CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAidGhlIGds
b2JhbCBjb25maWcgb3B0aW9uIGRlZmF1bHRicmlkZ2UgaXMgZGVwcmVjYXRlZCwgIgorICAgICAg
ICAgICAgICAgICAgICAgICAgInBsZWFzZSBzd2l0Y2ggdG8gdmlmLmRlZmF1bHQuYnJpZGdlXG4i
KTsKKyAgICAgICAgZnJlZShkZWZhdWx0X2JyaWRnZSk7CisgICAgICAgIGRlZmF1bHRfYnJpZGdl
ID0gc3RyZHVwKGJ1Zik7CisgICAgfQorCisgICAgaWYgKCF4bHVfY2ZnX2dldF9zdHJpbmcgKGNv
bmZpZywgInZpZi5kZWZhdWx0LmJyaWRnZSIsICZidWYsIDApKSB7CisgICAgICAgIGZyZWUoZGVm
YXVsdF9icmlkZ2UpOworICAgICAgICBkZWZhdWx0X2JyaWRnZSA9IHN0cmR1cChidWYpOworICAg
IH0KIAogICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWYuZGVmYXVsdC5n
YXRld2F5ZGV2IiwgJmJ1ZiwgMCkpCiAgICAgICAgIGRlZmF1bHRfZ2F0ZXdheWRldiA9IHN0cmR1
cChidWYpOwotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U39O0-00038O-IF; Wed, 06 Feb 2013 18:06:20 +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 1U39Nz-00037x-7L
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:19 +0000
Received: from [85.158.143.35:59740] by server-2.bemta-4.messagelabs.com id
	D9/DD-01597-A9B92115; Wed, 06 Feb 2013 18:06:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360173975!15450760!3
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13842 invoked from network); 6 Feb 2013 18:06:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:16 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:15 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:37 +0100
Message-ID: <1360173877-12696-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 4/4] xl: add vif.default.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

UmVwbGFjZSB2aWZzY3JpcHQgd2l0aCB2aWYuZGVmYXVsdC5zY3JpcHQuIFRoZSBvbGQgY29uZmln
IG9wdGlvbiBpcwprZXB0IGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4KClNpZ25lZC1vZmYt
Ynk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpDYzogR2VvcmdlIER1
bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgpDYzogSWFuIENhbXBiZWxsIDxpYW4uY2Ft
cGJlbGxAY2l0cml4LmNvbT4KLS0tCiB0b29scy9saWJ4bC94bC5jIHwgICAxMSArKysrKysrKysr
LQogMSBmaWxlcyBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlm
ZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsLmMgYi90b29scy9saWJ4bC94bC5jCmluZGV4IDEwMGFi
MzIuLjkyNTY1ZDEgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsLmMKKysrIGIvdG9vbHMvbGli
eGwveGwuYwpAQCAtODYsOCArODYsMTcgQEAgc3RhdGljIHZvaWQgcGFyc2VfZ2xvYmFsX2NvbmZp
Zyhjb25zdCBjaGFyICpjb25maWdmaWxlLAogICAgICAgICBleGl0KDEpOwogICAgIH0KIAotICAg
IGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWZzY3JpcHQiLCAmYnVmLCAwKSkK
KyAgICBpZiAoIXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAidmlmc2NyaXB0IiwgJmJ1Ziwg
MCkpIHsKKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgZ2xvYmFsIGNvbmZpZyBvcHRpb24g
dmlmc2NyaXB0IGlzIGRlcHJlY2F0ZWQsICIKKyAgICAgICAgICAgICAgICAgICAgICAgICJwbGVh
c2Ugc3dpdGNoIHRvIHZpZi5kZWZhdWx0LnNjcmlwdFxuIik7CisgICAgICAgIGZyZWUoZGVmYXVs
dF92aWZzY3JpcHQpOwogICAgICAgICBkZWZhdWx0X3ZpZnNjcmlwdCA9IHN0cmR1cChidWYpOwor
ICAgIH0KKworICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWYuZGVmYXVs
dC5zY3JpcHQiLCAmYnVmLCAwKSkgeworICAgICAgICBmcmVlKGRlZmF1bHRfdmlmc2NyaXB0KTsK
KyAgICAgICAgZGVmYXVsdF92aWZzY3JpcHQgPSBzdHJkdXAoYnVmKTsKKyAgICB9CiAKICAgICBp
ZiAoIXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiZGVmYXVsdGJyaWRnZSIsICZidWYsIDAp
KSB7CiAgICAgICAgIGZwcmludGYoc3RkZXJyLCAidGhlIGdsb2JhbCBjb25maWcgb3B0aW9uIGRl
ZmF1bHRicmlkZ2UgaXMgZGVwcmVjYXRlZCwgIgotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U39O0-00038O-IF; Wed, 06 Feb 2013 18:06:20 +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 1U39Nz-00037x-7L
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:19 +0000
Received: from [85.158.143.35:59740] by server-2.bemta-4.messagelabs.com id
	D9/DD-01597-A9B92115; Wed, 06 Feb 2013 18:06:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360173975!15450760!3
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13842 invoked from network); 6 Feb 2013 18:06:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:16 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:15 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:37 +0100
Message-ID: <1360173877-12696-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 4/4] xl: add vif.default.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

UmVwbGFjZSB2aWZzY3JpcHQgd2l0aCB2aWYuZGVmYXVsdC5zY3JpcHQuIFRoZSBvbGQgY29uZmln
IG9wdGlvbiBpcwprZXB0IGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4KClNpZ25lZC1vZmYt
Ynk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpDYzogR2VvcmdlIER1
bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgpDYzogSWFuIENhbXBiZWxsIDxpYW4uY2Ft
cGJlbGxAY2l0cml4LmNvbT4KLS0tCiB0b29scy9saWJ4bC94bC5jIHwgICAxMSArKysrKysrKysr
LQogMSBmaWxlcyBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlm
ZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsLmMgYi90b29scy9saWJ4bC94bC5jCmluZGV4IDEwMGFi
MzIuLjkyNTY1ZDEgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsLmMKKysrIGIvdG9vbHMvbGli
eGwveGwuYwpAQCAtODYsOCArODYsMTcgQEAgc3RhdGljIHZvaWQgcGFyc2VfZ2xvYmFsX2NvbmZp
Zyhjb25zdCBjaGFyICpjb25maWdmaWxlLAogICAgICAgICBleGl0KDEpOwogICAgIH0KIAotICAg
IGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWZzY3JpcHQiLCAmYnVmLCAwKSkK
KyAgICBpZiAoIXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAidmlmc2NyaXB0IiwgJmJ1Ziwg
MCkpIHsKKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgZ2xvYmFsIGNvbmZpZyBvcHRpb24g
dmlmc2NyaXB0IGlzIGRlcHJlY2F0ZWQsICIKKyAgICAgICAgICAgICAgICAgICAgICAgICJwbGVh
c2Ugc3dpdGNoIHRvIHZpZi5kZWZhdWx0LnNjcmlwdFxuIik7CisgICAgICAgIGZyZWUoZGVmYXVs
dF92aWZzY3JpcHQpOwogICAgICAgICBkZWZhdWx0X3ZpZnNjcmlwdCA9IHN0cmR1cChidWYpOwor
ICAgIH0KKworICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWYuZGVmYXVs
dC5zY3JpcHQiLCAmYnVmLCAwKSkgeworICAgICAgICBmcmVlKGRlZmF1bHRfdmlmc2NyaXB0KTsK
KyAgICAgICAgZGVmYXVsdF92aWZzY3JpcHQgPSBzdHJkdXAoYnVmKTsKKyAgICB9CiAKICAgICBp
ZiAoIXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiZGVmYXVsdGJyaWRnZSIsICZidWYsIDAp
KSB7CiAgICAgICAgIGZwcmludGYoc3RkZXJyLCAidGhlIGdsb2JhbCBjb25maWcgb3B0aW9uIGRl
ZmF1bHRicmlkZ2UgaXMgZGVwcmVjYXRlZCwgIgotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U39O0-00038H-68; Wed, 06 Feb 2013 18:06:20 +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 1U39Ny-00037x-M6
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:18 +0000
Received: from [85.158.143.35:59729] by server-2.bemta-4.messagelabs.com id
	D8/DD-01597-99B92115; Wed, 06 Feb 2013 18:06:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360173975!15450760!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13789 invoked from network); 6 Feb 2013 18:06:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:14 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:14 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:34 +0100
Message-ID: <1360173877-12696-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/4] xl/libxl: add gatewaydev/netdev to vif
	specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBvcHRpb24gaXMgdXNlZCBieSB0aGUgdmlmLXJvdXRlIGhvdHBsdWcgc2NyaXB0LiBBIG5l
dyBtb3JlCmRlc2NyaXB0aXZlIG5hbWUgaXMgdXNlZCwgImdhdGV3YXlkZXYiLCBidXQgIm5ldGRl
diIgaXMgYWxzbyBzdXBwb3J0ZWQKYXMgYSBkZXByZWNhdGVkIGJhY2t3YXJkcyBjb21wYXRpYmxl
IG9wdGlvbi4KClRoaXMgb3B0aW9uIHdhcyBzdXBwb3J0ZWQgaW4gdGhlIHBhc3QsIGFjY29yZGlu
ZyB0bwpodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvVmlmLXJvdXRlLCBzbyB3ZSBzaG91bGQgYWxz
byBzdXBwb3J0IGl0IGluCmxpYnhsLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8
cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBVbGYgS3JldXR6YmVyZyA8dWxmLmtyZXV0emJlcmdA
aG9zdGV1cm9wZS5kZT4KQ2M6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+
CkNjOiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+Ci0tLQpDaGFuZ2Vz
IHNpbmNlIHYxOgogKiBEb24ndCBwYXNzIGEgTlVMTCBhcyBhIHZhbHVlIG9mIGEgZW52IHZhcmlh
YmxlCiAqIENoYW5nZSBuZXRkZXYgdG8gZ2F0ZXdheWRldgotLS0KIGRvY3MvbWlzYy94bC1uZXR3
b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gfCAgIDEwICsrKysrKysrKysKIHRvb2xzL2xpYnhs
L2xpYnhsLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA2ICsrKysrLQogdG9vbHMvbGli
eGwvbGlieGxfbGludXguYyAgICAgICAgICAgICAgICAgICB8ICAgIDkgKysrKysrKystCiB0b29s
cy9saWJ4bC9saWJ4bF90eXBlcy5pZGwgICAgICAgICAgICAgICAgIHwgICAgMSArCiB0b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMgICAgICAgICAgICAgICAgICAgIHwgICAxNCArKysrKysrKysrKysr
KwogNSBmaWxlcyBjaGFuZ2VkLCAzOCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlm
ZiAtLWdpdCBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYi9k
b2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCmluZGV4IDVlMmYwNDku
LmUwZDNkMmEgMTAwNjQ0Ci0tLSBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24u
bWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93
bgpAQCAtNjcsNiArNjcsMTUgQEAgYWRkZWQgdG8uIFRoZSBkZWZhdWx0IGlzIGB4ZW5icjBgLiBU
aGUgYnJpZGdlIG11c3QgYmUgY29uZmlndXJlZCB1c2luZwogeW91ciBkaXN0cmlidXRpb24ncyBu
ZXR3b3JrIGNvbmZpZ3VyYXRpb24gdG9vbHMuIFNlZSB0aGUgW3dpa2ldW25ldF0KIGZvciBndWlk
YW5jZSBhbmQgZXhhbXBsZXMuCiAKKyMjIyBnYXRld2F5ZGV2CisKK1NwZWNpZmllcyB0aGUgbmFt
ZSBvZiB0aGUgbmV0d29yayBpbnRlcmZhY2Ugd2hpY2ggaGFzIGFuIElQIGFuZCB3aGljaAoraXMg
aW4gdGhlIG5ldHdvcmsgdGhlIFZJRiBzaG91bGQgY29tbXVuaWNhdGUgd2l0aC4gVGhpcyBpcyB1
c2VkIGluIHRoZSBob3N0CitieSB0aGUgdmlmLXJvdXRlIGhvdHBsdWcgc2NyaXB0LiBTZWUgW3dp
a2ldW3ZpZnJvdXRlXSBmb3IgZ3VpZGFuY2UgYW5kCitleGFtcGxlcy4KKworTk9URTogbmV0ZGV2
IGlzIGEgZGVwcmVjYXRlZCBhbGlhcyBvZiB0aGlzIG9wdGlvbi4KKwogIyMjIHR5cGUKIAogVGhp
cyBrZXl3b3JkIGlzIHZhbGlkIGZvciBIVk0gZ3Vlc3RzIG9ubHkuCkBAIC0xNTgsMyArMTY3LDQg
QEAgb24gdGhlIHVuZGVybHlpbmcgbmV0YmFjayBpbXBsZW1lbnRhdGlvbi4KIAogW291aV06IGh0
dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV9VbmlxdWVfSWRlbnRp
ZmllcgogW25ldF06IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Ib3N0Q29uZmlndXJhdGlvbi9O
ZXR3b3JraW5nCitbdmlmcm91dGVdOiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvVmlmLXJvdXRl
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwvbGlieGwuYwpp
bmRleCA3M2UwZGMzLi41ZDU5MGYxIDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCisr
KyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKQEAgLTI4MjYsNyArMjgyNiw3IEBAIHZvaWQgbGlieGxf
X2RldmljZV9uaWNfYWRkKGxpYnhsX19lZ2MgKmVnYywgdWludDMyX3QgZG9taWQsCiAgICAgaWYg
KHJjKSBnb3RvIG91dDsKIAogICAgIGZyb250ID0gZmxleGFycmF5X21ha2UoZ2MsIDE2LCAxKTsK
LSAgICBiYWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE2LCAxKTsKKyAgICBiYWNrID0gZmxleGFy
cmF5X21ha2UoZ2MsIDE4LCAxKTsKIAogICAgIGlmIChuaWMtPmRldmlkID09IC0xKSB7CiAgICAg
ICAgIGlmICgobmljLT5kZXZpZCA9IGxpYnhsX19kZXZpY2VfbmV4dGlkKGdjLCBkb21pZCwgInZp
ZiIpIDwgMCkpIHsKQEAgLTI4NjIsNiArMjg2MiwxMCBAQCB2b2lkIGxpYnhsX19kZXZpY2Vfbmlj
X2FkZChsaWJ4bF9fZWdjICplZ2MsIHVpbnQzMl90IGRvbWlkLAogICAgICAgICBmbGV4YXJyYXlf
YXBwZW5kKGJhY2ssICJpcCIpOwogICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhs
X19zdHJkdXAoZ2MsIG5pYy0+aXApKTsKICAgICB9CisgICAgaWYgKG5pYy0+Z2F0ZXdheWRldikg
eworICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJnYXRld2F5ZGV2Iik7CisgICAgICAg
IGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5nYXRld2F5ZGV2
KSk7CisgICAgfQogCiAgICAgaWYgKG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcyA+IDApIHsKICAg
ICAgICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCAicmF0ZSIpOwpkaWZmIC0tZ2l0IGEvdG9vbHMv
bGlieGwvbGlieGxfbGludXguYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKaW5kZXggMWZl
ZDNjZC4uNjBmYzUzMyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfbGludXguYworKysg
Yi90b29scy9saWJ4bC9saWJ4bF9saW51eC5jCkBAIC04NCwxMSArODQsMTYgQEAgc3RhdGljIGNo
YXIgKipnZXRfaG90cGx1Z19lbnYobGlieGxfX2djICpnYywKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNoYXIgKnNjcmlwdCwgbGlieGxfX2RldmljZSAqZGV2KQogewogICAgIGNvbnN0
IGNoYXIgKnR5cGUgPSBsaWJ4bF9fZGV2aWNlX2tpbmRfdG9fc3RyaW5nKGRldi0+YmFja2VuZF9r
aW5kKTsKKyAgICBjaGFyICpiZV9wYXRoID0gbGlieGxfX2RldmljZV9iYWNrZW5kX3BhdGgoZ2Ms
IGRldik7CiAgICAgY2hhciAqKmVudjsKKyAgICBjaGFyICpnYXRld2F5ZGV2OwogICAgIGludCBu
ciA9IDA7CiAgICAgbGlieGxfbmljX3R5cGUgbmljdHlwZTsKIAotICAgIGNvbnN0IGludCBhcnJh
eXNpemUgPSAxMzsKKyAgICBnYXRld2F5ZGV2ID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxM
LCBHQ1NQUklOVEYoIiVzLyVzIiwgYmVfcGF0aCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImdhdGV3YXlkZXYiKSk7CisKKyAgICBjb25z
dCBpbnQgYXJyYXlzaXplID0gMTU7CiAgICAgR0NORVdfQVJSQVkoZW52LCBhcnJheXNpemUpOwog
ICAgIGVudltucisrXSA9ICJzY3JpcHQiOwogICAgIGVudltucisrXSA9IHNjcmlwdDsKQEAgLTk4
LDYgKzEwMyw4IEBAIHN0YXRpYyBjaGFyICoqZ2V0X2hvdHBsdWdfZW52KGxpYnhsX19nYyAqZ2Ms
CiAgICAgZW52W25yKytdID0gR0NTUFJJTlRGKCJiYWNrZW5kLyVzLyV1LyVkIiwgdHlwZSwgZGV2
LT5kb21pZCwgZGV2LT5kZXZpZCk7CiAgICAgZW52W25yKytdID0gIlhFTkJVU19CQVNFX1BBVEgi
OwogICAgIGVudltucisrXSA9ICJiYWNrZW5kIjsKKyAgICBlbnZbbnIrK10gPSAibmV0ZGV2IjsK
KyAgICBlbnZbbnIrK10gPSBnYXRld2F5ZGV2ID8gOiAiIjsKICAgICBpZiAoZGV2LT5iYWNrZW5k
X2tpbmQgPT0gTElCWExfX0RFVklDRV9LSU5EX1ZJRikgewogICAgICAgICBpZiAobGlieGxfX25p
Y190eXBlKGdjLCBkZXYsICZuaWN0eXBlKSkgewogICAgICAgICAgICAgTE9HKEVSUk9SLCAidW5h
YmxlIHRvIGdldCBuaWN0eXBlIik7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBl
cy5pZGwgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKaW5kZXggYWNjNGJjOS4uMDExMmE3
YSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCisrKyBiL3Rvb2xzL2xp
YnhsL2xpYnhsX3R5cGVzLmlkbApAQCAtMzgyLDYgKzM4Miw3IEBAIGxpYnhsX2RldmljZV9uaWMg
PSBTdHJ1Y3QoImRldmljZV9uaWMiLCBbCiAgICAgKCJuaWN0eXBlIiwgbGlieGxfbmljX3R5cGUp
LAogICAgICgicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAogICAgICgicmF0ZV9p
bnRlcnZhbF91c2VjcyIsIHVpbnQzMiksCisgICAgKCJnYXRld2F5ZGV2Iiwgc3RyaW5nKSwKICAg
ICBdKQogCiBsaWJ4bF9kZXZpY2VfcGNpID0gU3RydWN0KCJkZXZpY2VfcGNpIiwgWwpkaWZmIC0t
Z2l0IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5j
CmluZGV4IDA4MGJiZDguLmRjMTc4OGUgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYworKysgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKQEAgLTEyMDUsNiArMTIwNSwxNCBA
QCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFyICpjb25maWdfc291cmNl
LAogICAgICAgICAgICAgICAgICAgICBwYXJzZV92aWZfcmF0ZSgmY29uZmlnLCAocDIgKyAxKSwg
bmljKTsKICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgImFjY2VsIikpIHsK
ICAgICAgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVy
IGZvciB2aWZzIGlzIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKKyAgICAgICAgICAgICAg
ICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgIm5ldGRldiIpKSB7CisgICAgICAgICAgICAgICAgICAg
IGZwcmludGYoc3RkZXJyLCAidGhlIG5ldGRldiBwYXJhbWV0ZXIgaXMgZGVwcmVjYXRlZCwgIgor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInBsZWFzZSB1c2UgZ2F0ZXdheWRl
diBpbnN0ZWFkXG4iKTsKKyAgICAgICAgICAgICAgICAgICAgZnJlZShuaWMtPmdhdGV3YXlkZXYp
OworICAgICAgICAgICAgICAgICAgICBuaWMtPmdhdGV3YXlkZXYgPSBzdHJkdXAocDIgKyAxKTsK
KyAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgImdhdGV3YXlkZXYiKSkgewor
ICAgICAgICAgICAgICAgICAgICBmcmVlKG5pYy0+Z2F0ZXdheWRldik7CisgICAgICAgICAgICAg
ICAgICAgIG5pYy0+Z2F0ZXdheWRldiA9IHN0cmR1cChwMiArIDEpOwogICAgICAgICAgICAgICAg
IH0KICAgICAgICAgICAgIH0gd2hpbGUgKChwID0gc3RydG9rKE5VTEwsICIsIikpICE9IE5VTEwp
Owogc2tpcF9uaWM6CkBAIC01NDcxLDYgKzU0NzksMTIgQEAgaW50IG1haW5fbmV0d29ya2F0dGFj
aChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgICAgICB9CiAgICAgICAgIH0gZWxzZSBp
ZiAoTUFUQ0hfT1BUSU9OKCJicmlkZ2UiLCAqYXJndiwgb3BhcmcpKSB7CiAgICAgICAgICAgICBy
ZXBsYWNlX3N0cmluZygmbmljLmJyaWRnZSwgb3BhcmcpOworICAgICAgICB9IGVsc2UgaWYgKE1B
VENIX09QVElPTigibmV0ZGV2IiwgKmFyZ3YsIG9wYXJnKSkgeworICAgICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJ0aGUgbmV0ZGV2IHBhcmFtZXRlciBpcyBkZXByZWNhdGVkLCAiCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgInBsZWFzZSB1c2UgZ2F0ZXdheWRldiBpbnN0ZWFkXG4iKTsK
KyAgICAgICAgICAgIHJlcGxhY2Vfc3RyaW5nKCZuaWMuZ2F0ZXdheWRldiwgb3BhcmcpOworICAg
ICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigiZ2F0ZXdheWRldiIsICphcmd2LCBvcGFyZykp
IHsKKyAgICAgICAgICAgIHJlcGxhY2Vfc3RyaW5nKCZuaWMuZ2F0ZXdheWRldiwgb3BhcmcpOwog
ICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigiaXAiLCAqYXJndiwgb3BhcmcpKSB7CiAg
ICAgICAgICAgICByZXBsYWNlX3N0cmluZygmbmljLmlwLCBvcGFyZyk7CiAgICAgICAgIH0gZWxz
ZSBpZiAoTUFUQ0hfT1BUSU9OKCJzY3JpcHQiLCAqYXJndiwgb3BhcmcpKSB7Ci0tIAoxLjcuNy41
IChBcHBsZSBHaXQtMjYpCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U39O0-00038H-68; Wed, 06 Feb 2013 18:06:20 +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 1U39Ny-00037x-M6
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:18 +0000
Received: from [85.158.143.35:59729] by server-2.bemta-4.messagelabs.com id
	D8/DD-01597-99B92115; Wed, 06 Feb 2013 18:06:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360173975!15450760!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13789 invoked from network); 6 Feb 2013 18:06:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:14 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:14 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:34 +0100
Message-ID: <1360173877-12696-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/4] xl/libxl: add gatewaydev/netdev to vif
	specification
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBvcHRpb24gaXMgdXNlZCBieSB0aGUgdmlmLXJvdXRlIGhvdHBsdWcgc2NyaXB0LiBBIG5l
dyBtb3JlCmRlc2NyaXB0aXZlIG5hbWUgaXMgdXNlZCwgImdhdGV3YXlkZXYiLCBidXQgIm5ldGRl
diIgaXMgYWxzbyBzdXBwb3J0ZWQKYXMgYSBkZXByZWNhdGVkIGJhY2t3YXJkcyBjb21wYXRpYmxl
IG9wdGlvbi4KClRoaXMgb3B0aW9uIHdhcyBzdXBwb3J0ZWQgaW4gdGhlIHBhc3QsIGFjY29yZGlu
ZyB0bwpodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvVmlmLXJvdXRlLCBzbyB3ZSBzaG91bGQgYWxz
byBzdXBwb3J0IGl0IGluCmxpYnhsLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8
cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBVbGYgS3JldXR6YmVyZyA8dWxmLmtyZXV0emJlcmdA
aG9zdGV1cm9wZS5kZT4KQ2M6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+
CkNjOiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+Ci0tLQpDaGFuZ2Vz
IHNpbmNlIHYxOgogKiBEb24ndCBwYXNzIGEgTlVMTCBhcyBhIHZhbHVlIG9mIGEgZW52IHZhcmlh
YmxlCiAqIENoYW5nZSBuZXRkZXYgdG8gZ2F0ZXdheWRldgotLS0KIGRvY3MvbWlzYy94bC1uZXR3
b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gfCAgIDEwICsrKysrKysrKysKIHRvb2xzL2xpYnhs
L2xpYnhsLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA2ICsrKysrLQogdG9vbHMvbGli
eGwvbGlieGxfbGludXguYyAgICAgICAgICAgICAgICAgICB8ICAgIDkgKysrKysrKystCiB0b29s
cy9saWJ4bC9saWJ4bF90eXBlcy5pZGwgICAgICAgICAgICAgICAgIHwgICAgMSArCiB0b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMgICAgICAgICAgICAgICAgICAgIHwgICAxNCArKysrKysrKysrKysr
KwogNSBmaWxlcyBjaGFuZ2VkLCAzOCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlm
ZiAtLWdpdCBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYi9k
b2NzL21pc2MveGwtbmV0d29yay1jb25maWd1cmF0aW9uLm1hcmtkb3duCmluZGV4IDVlMmYwNDku
LmUwZDNkMmEgMTAwNjQ0Ci0tLSBhL2RvY3MvbWlzYy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24u
bWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93
bgpAQCAtNjcsNiArNjcsMTUgQEAgYWRkZWQgdG8uIFRoZSBkZWZhdWx0IGlzIGB4ZW5icjBgLiBU
aGUgYnJpZGdlIG11c3QgYmUgY29uZmlndXJlZCB1c2luZwogeW91ciBkaXN0cmlidXRpb24ncyBu
ZXR3b3JrIGNvbmZpZ3VyYXRpb24gdG9vbHMuIFNlZSB0aGUgW3dpa2ldW25ldF0KIGZvciBndWlk
YW5jZSBhbmQgZXhhbXBsZXMuCiAKKyMjIyBnYXRld2F5ZGV2CisKK1NwZWNpZmllcyB0aGUgbmFt
ZSBvZiB0aGUgbmV0d29yayBpbnRlcmZhY2Ugd2hpY2ggaGFzIGFuIElQIGFuZCB3aGljaAoraXMg
aW4gdGhlIG5ldHdvcmsgdGhlIFZJRiBzaG91bGQgY29tbXVuaWNhdGUgd2l0aC4gVGhpcyBpcyB1
c2VkIGluIHRoZSBob3N0CitieSB0aGUgdmlmLXJvdXRlIGhvdHBsdWcgc2NyaXB0LiBTZWUgW3dp
a2ldW3ZpZnJvdXRlXSBmb3IgZ3VpZGFuY2UgYW5kCitleGFtcGxlcy4KKworTk9URTogbmV0ZGV2
IGlzIGEgZGVwcmVjYXRlZCBhbGlhcyBvZiB0aGlzIG9wdGlvbi4KKwogIyMjIHR5cGUKIAogVGhp
cyBrZXl3b3JkIGlzIHZhbGlkIGZvciBIVk0gZ3Vlc3RzIG9ubHkuCkBAIC0xNTgsMyArMTY3LDQg
QEAgb24gdGhlIHVuZGVybHlpbmcgbmV0YmFjayBpbXBsZW1lbnRhdGlvbi4KIAogW291aV06IGh0
dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV9VbmlxdWVfSWRlbnRp
ZmllcgogW25ldF06IGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9Ib3N0Q29uZmlndXJhdGlvbi9O
ZXR3b3JraW5nCitbdmlmcm91dGVdOiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvVmlmLXJvdXRl
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bC5jIGIvdG9vbHMvbGlieGwvbGlieGwuYwpp
bmRleCA3M2UwZGMzLi41ZDU5MGYxIDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCisr
KyBiL3Rvb2xzL2xpYnhsL2xpYnhsLmMKQEAgLTI4MjYsNyArMjgyNiw3IEBAIHZvaWQgbGlieGxf
X2RldmljZV9uaWNfYWRkKGxpYnhsX19lZ2MgKmVnYywgdWludDMyX3QgZG9taWQsCiAgICAgaWYg
KHJjKSBnb3RvIG91dDsKIAogICAgIGZyb250ID0gZmxleGFycmF5X21ha2UoZ2MsIDE2LCAxKTsK
LSAgICBiYWNrID0gZmxleGFycmF5X21ha2UoZ2MsIDE2LCAxKTsKKyAgICBiYWNrID0gZmxleGFy
cmF5X21ha2UoZ2MsIDE4LCAxKTsKIAogICAgIGlmIChuaWMtPmRldmlkID09IC0xKSB7CiAgICAg
ICAgIGlmICgobmljLT5kZXZpZCA9IGxpYnhsX19kZXZpY2VfbmV4dGlkKGdjLCBkb21pZCwgInZp
ZiIpIDwgMCkpIHsKQEAgLTI4NjIsNiArMjg2MiwxMCBAQCB2b2lkIGxpYnhsX19kZXZpY2Vfbmlj
X2FkZChsaWJ4bF9fZWdjICplZ2MsIHVpbnQzMl90IGRvbWlkLAogICAgICAgICBmbGV4YXJyYXlf
YXBwZW5kKGJhY2ssICJpcCIpOwogICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssIGxpYnhs
X19zdHJkdXAoZ2MsIG5pYy0+aXApKTsKICAgICB9CisgICAgaWYgKG5pYy0+Z2F0ZXdheWRldikg
eworICAgICAgICBmbGV4YXJyYXlfYXBwZW5kKGJhY2ssICJnYXRld2F5ZGV2Iik7CisgICAgICAg
IGZsZXhhcnJheV9hcHBlbmQoYmFjaywgbGlieGxfX3N0cmR1cChnYywgbmljLT5nYXRld2F5ZGV2
KSk7CisgICAgfQogCiAgICAgaWYgKG5pYy0+cmF0ZV9pbnRlcnZhbF91c2VjcyA+IDApIHsKICAg
ICAgICAgZmxleGFycmF5X2FwcGVuZChiYWNrLCAicmF0ZSIpOwpkaWZmIC0tZ2l0IGEvdG9vbHMv
bGlieGwvbGlieGxfbGludXguYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2xpbnV4LmMKaW5kZXggMWZl
ZDNjZC4uNjBmYzUzMyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfbGludXguYworKysg
Yi90b29scy9saWJ4bC9saWJ4bF9saW51eC5jCkBAIC04NCwxMSArODQsMTYgQEAgc3RhdGljIGNo
YXIgKipnZXRfaG90cGx1Z19lbnYobGlieGxfX2djICpnYywKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNoYXIgKnNjcmlwdCwgbGlieGxfX2RldmljZSAqZGV2KQogewogICAgIGNvbnN0
IGNoYXIgKnR5cGUgPSBsaWJ4bF9fZGV2aWNlX2tpbmRfdG9fc3RyaW5nKGRldi0+YmFja2VuZF9r
aW5kKTsKKyAgICBjaGFyICpiZV9wYXRoID0gbGlieGxfX2RldmljZV9iYWNrZW5kX3BhdGgoZ2Ms
IGRldik7CiAgICAgY2hhciAqKmVudjsKKyAgICBjaGFyICpnYXRld2F5ZGV2OwogICAgIGludCBu
ciA9IDA7CiAgICAgbGlieGxfbmljX3R5cGUgbmljdHlwZTsKIAotICAgIGNvbnN0IGludCBhcnJh
eXNpemUgPSAxMzsKKyAgICBnYXRld2F5ZGV2ID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxM
LCBHQ1NQUklOVEYoIiVzLyVzIiwgYmVfcGF0aCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImdhdGV3YXlkZXYiKSk7CisKKyAgICBjb25z
dCBpbnQgYXJyYXlzaXplID0gMTU7CiAgICAgR0NORVdfQVJSQVkoZW52LCBhcnJheXNpemUpOwog
ICAgIGVudltucisrXSA9ICJzY3JpcHQiOwogICAgIGVudltucisrXSA9IHNjcmlwdDsKQEAgLTk4
LDYgKzEwMyw4IEBAIHN0YXRpYyBjaGFyICoqZ2V0X2hvdHBsdWdfZW52KGxpYnhsX19nYyAqZ2Ms
CiAgICAgZW52W25yKytdID0gR0NTUFJJTlRGKCJiYWNrZW5kLyVzLyV1LyVkIiwgdHlwZSwgZGV2
LT5kb21pZCwgZGV2LT5kZXZpZCk7CiAgICAgZW52W25yKytdID0gIlhFTkJVU19CQVNFX1BBVEgi
OwogICAgIGVudltucisrXSA9ICJiYWNrZW5kIjsKKyAgICBlbnZbbnIrK10gPSAibmV0ZGV2IjsK
KyAgICBlbnZbbnIrK10gPSBnYXRld2F5ZGV2ID8gOiAiIjsKICAgICBpZiAoZGV2LT5iYWNrZW5k
X2tpbmQgPT0gTElCWExfX0RFVklDRV9LSU5EX1ZJRikgewogICAgICAgICBpZiAobGlieGxfX25p
Y190eXBlKGdjLCBkZXYsICZuaWN0eXBlKSkgewogICAgICAgICAgICAgTE9HKEVSUk9SLCAidW5h
YmxlIHRvIGdldCBuaWN0eXBlIik7CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF90eXBl
cy5pZGwgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKaW5kZXggYWNjNGJjOS4uMDExMmE3
YSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCisrKyBiL3Rvb2xzL2xp
YnhsL2xpYnhsX3R5cGVzLmlkbApAQCAtMzgyLDYgKzM4Miw3IEBAIGxpYnhsX2RldmljZV9uaWMg
PSBTdHJ1Y3QoImRldmljZV9uaWMiLCBbCiAgICAgKCJuaWN0eXBlIiwgbGlieGxfbmljX3R5cGUp
LAogICAgICgicmF0ZV9ieXRlc19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAogICAgICgicmF0ZV9p
bnRlcnZhbF91c2VjcyIsIHVpbnQzMiksCisgICAgKCJnYXRld2F5ZGV2Iiwgc3RyaW5nKSwKICAg
ICBdKQogCiBsaWJ4bF9kZXZpY2VfcGNpID0gU3RydWN0KCJkZXZpY2VfcGNpIiwgWwpkaWZmIC0t
Z2l0IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5j
CmluZGV4IDA4MGJiZDguLmRjMTc4OGUgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYworKysgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKQEAgLTEyMDUsNiArMTIwNSwxNCBA
QCBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdfZGF0YShjb25zdCBjaGFyICpjb25maWdfc291cmNl
LAogICAgICAgICAgICAgICAgICAgICBwYXJzZV92aWZfcmF0ZSgmY29uZmlnLCAocDIgKyAxKSwg
bmljKTsKICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgImFjY2VsIikpIHsK
ICAgICAgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJ0aGUgYWNjZWwgcGFyYW1ldGVy
IGZvciB2aWZzIGlzIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkXG4iKTsKKyAgICAgICAgICAgICAg
ICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgIm5ldGRldiIpKSB7CisgICAgICAgICAgICAgICAgICAg
IGZwcmludGYoc3RkZXJyLCAidGhlIG5ldGRldiBwYXJhbWV0ZXIgaXMgZGVwcmVjYXRlZCwgIgor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInBsZWFzZSB1c2UgZ2F0ZXdheWRl
diBpbnN0ZWFkXG4iKTsKKyAgICAgICAgICAgICAgICAgICAgZnJlZShuaWMtPmdhdGV3YXlkZXYp
OworICAgICAgICAgICAgICAgICAgICBuaWMtPmdhdGV3YXlkZXYgPSBzdHJkdXAocDIgKyAxKTsK
KyAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKCFzdHJjbXAocCwgImdhdGV3YXlkZXYiKSkgewor
ICAgICAgICAgICAgICAgICAgICBmcmVlKG5pYy0+Z2F0ZXdheWRldik7CisgICAgICAgICAgICAg
ICAgICAgIG5pYy0+Z2F0ZXdheWRldiA9IHN0cmR1cChwMiArIDEpOwogICAgICAgICAgICAgICAg
IH0KICAgICAgICAgICAgIH0gd2hpbGUgKChwID0gc3RydG9rKE5VTEwsICIsIikpICE9IE5VTEwp
Owogc2tpcF9uaWM6CkBAIC01NDcxLDYgKzU0NzksMTIgQEAgaW50IG1haW5fbmV0d29ya2F0dGFj
aChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgICAgICB9CiAgICAgICAgIH0gZWxzZSBp
ZiAoTUFUQ0hfT1BUSU9OKCJicmlkZ2UiLCAqYXJndiwgb3BhcmcpKSB7CiAgICAgICAgICAgICBy
ZXBsYWNlX3N0cmluZygmbmljLmJyaWRnZSwgb3BhcmcpOworICAgICAgICB9IGVsc2UgaWYgKE1B
VENIX09QVElPTigibmV0ZGV2IiwgKmFyZ3YsIG9wYXJnKSkgeworICAgICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJ0aGUgbmV0ZGV2IHBhcmFtZXRlciBpcyBkZXByZWNhdGVkLCAiCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgInBsZWFzZSB1c2UgZ2F0ZXdheWRldiBpbnN0ZWFkXG4iKTsK
KyAgICAgICAgICAgIHJlcGxhY2Vfc3RyaW5nKCZuaWMuZ2F0ZXdheWRldiwgb3BhcmcpOworICAg
ICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigiZ2F0ZXdheWRldiIsICphcmd2LCBvcGFyZykp
IHsKKyAgICAgICAgICAgIHJlcGxhY2Vfc3RyaW5nKCZuaWMuZ2F0ZXdheWRldiwgb3BhcmcpOwog
ICAgICAgICB9IGVsc2UgaWYgKE1BVENIX09QVElPTigiaXAiLCAqYXJndiwgb3BhcmcpKSB7CiAg
ICAgICAgICAgICByZXBsYWNlX3N0cmluZygmbmljLmlwLCBvcGFyZyk7CiAgICAgICAgIH0gZWxz
ZSBpZiAoTUFUQ0hfT1BUSU9OKCJzY3JpcHQiLCAqYXJndiwgb3BhcmcpKSB7Ci0tIAoxLjcuNy41
IChBcHBsZSBHaXQtMjYpCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U39O3-000390-Br; Wed, 06 Feb 2013 18:06:23 +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 1U39O1-00038Q-0A
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:21 +0000
Received: from [193.109.254.147:49134] by server-1.bemta-14.messagelabs.com id
	B8/36-29874-C9B92115; Wed, 06 Feb 2013 18:06:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360173976!1420199!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22812 invoked from network); 6 Feb 2013 18:06:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:15 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:14 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:35 +0100
Message-ID: <1360173877-12696-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBhZGRzIGEgbmV3IGdsb2JhbCBvcHRpb24gaW4gdGhlIHhsIGNvbmZpZ3VyYXRpb24gZmls
ZSBjYWxsZWQKInZpZi5kZWZhdWx0LmdhdGV3YXlkZXYiLCB0aGF0IGlzIHVzZWQgdG8gc3BlY2lm
eSB0aGUgZGVmYXVsdApnYXRld2F5ZGV2IHRvIHVzZSB3aGVuIG5vbmUgaXMgcGFzc2VkIGluIHRo
ZSB2aWYgc3BlY2lmaWNhdGlvbi4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJv
Z2VyLnBhdUBjaXRyaXguY29tPgpDYzogVWxmIEtyZXV0emJlcmcgPHVsZi5rcmV1dHpiZXJnQGhv
c3RldXJvcGUuZGU+CkNjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpD
YzogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgotLS0KQ2hhbmdlcyBz
aW5jZSB2MToKICogUmVuYW1lIGRlZmF1bHRuZXRkZXYgdG8gdmlmLmRlZmF1bHQuZ2F0ZXdheWRl
dgotLS0KIGRvY3MvbWFuL3hsLmNvbmYucG9kLjUgICB8ICAgIDYgKysrKysrCiB0b29scy9leGFt
cGxlcy94bC5jb25mICAgfCAgICAzICsrKwogdG9vbHMvbGlieGwveGwuYyAgICAgICAgIHwgICAg
NCArKysrCiB0b29scy9saWJ4bC94bC5oICAgICAgICAgfCAgICAxICsKIHRvb2xzL2xpYnhsL3hs
X2NtZGltcGwuYyB8ICAgIDUgKysrKysKIDUgZmlsZXMgY2hhbmdlZCwgMTkgaW5zZXJ0aW9ucygr
KSwgMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kb2NzL21hbi94bC5jb25mLnBvZC41IGIv
ZG9jcy9tYW4veGwuY29uZi5wb2QuNQppbmRleCA4MmM2YjIwLi5mOGY3ZTdmIDEwMDY0NAotLS0g
YS9kb2NzL21hbi94bC5jb25mLnBvZC41CisrKyBiL2RvY3MvbWFuL3hsLmNvbmYucG9kLjUKQEAg
LTgyLDYgKzgyLDEyIEBAIENvbmZpZ3VyZXMgdGhlIGRlZmF1bHQgYnJpZGdlIHRvIHNldCBmb3Ig
dmlydHVhbCBuZXR3b3JrIGRldmljZXMuCiAKIERlZmF1bHQ6IEM8eGVuYnIwPgogCis9aXRlbSBC
PHZpZi5kZWZhdWx0LmdhdGV3YXlkZXY9Ik5BTUUiPgorCitDb25maWd1cmVzIHRoZSBkZWZhdWx0
IGdhdGV3YXkgZGV2aWNlIHRvIHNldCBmb3IgdmlydHVhbCBuZXR3b3JrIGRldmljZXMuCisKK0Rl
ZmF1bHQ6IEM8Tm9uZT4KKwogPWl0ZW0gQjxvdXRwdXRfZm9ybWF0PSJqc29ufHN4cCI+CiAKIENv
bmZpZ3VyZXMgdGhlIGRlZmF1bHQgb3V0cHV0IGZvcm1hdCB1c2VkIGJ5IHhsIHdoZW4gcHJpbnRp
bmcgIm1hY2hpbmUKZGlmZiAtLWdpdCBhL3Rvb2xzL2V4YW1wbGVzL3hsLmNvbmYgYi90b29scy9l
eGFtcGxlcy94bC5jb25mCmluZGV4IDI4YWI3OTYuLjlhMDNmZmYgMTAwNjQ0Ci0tLSBhL3Rvb2xz
L2V4YW1wbGVzL3hsLmNvbmYKKysrIGIvdG9vbHMvZXhhbXBsZXMveGwuY29uZgpAQCAtMjAsMyAr
MjAsNiBAQAogIyBpZiBkaXNhYmxlZCB0aGUgb2xkIGJlaGF2aW91ciB3aWxsIGJlIHVzZWQsIGFu
ZCBob3RwbHVnIHNjcmlwdHMgd2lsbCBiZQogIyBsYXVuY2hlZCBieSB1ZGV2LgogI3J1bl9ob3Rw
bHVnX3NjcmlwdHM9MQorCisjIGRlZmF1bHQgZ2F0ZXdheSBkZXZpY2UgdG8gdXNlIHdpdGggdmlm
LXJvdXRlIGhvdHBsdWcgc2NyaXB0CisjdmlmLmRlZmF1bHQuZ2F0ZXdheWRldj0iZXRoMCIKZGlm
ZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsLmMgYi90b29scy9saWJ4bC94bC5jCmluZGV4IGVjYmNk
M2IuLmY2NTcyMTYgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsLmMKKysrIGIvdG9vbHMvbGli
eGwveGwuYwpAQCAtNDMsNiArNDMsNyBAQCBpbnQgcnVuX2hvdHBsdWdfc2NyaXB0cyA9IDE7CiBj
aGFyICpsb2NrZmlsZTsKIGNoYXIgKmRlZmF1bHRfdmlmc2NyaXB0ID0gTlVMTDsKIGNoYXIgKmRl
ZmF1bHRfYnJpZGdlID0gTlVMTDsKK2NoYXIgKmRlZmF1bHRfZ2F0ZXdheWRldiA9IE5VTEw7CiBl
bnVtIG91dHB1dF9mb3JtYXQgZGVmYXVsdF9vdXRwdXRfZm9ybWF0ID0gT1VUUFVUX0ZPUk1BVF9K
U09OOwogCiBzdGF0aWMgeGVudG9vbGxvZ19sZXZlbCBtaW5tc2dsZXZlbCA9IFhUTF9QUk9HUkVT
UzsKQEAgLTkxLDYgKzkyLDkgQEAgc3RhdGljIHZvaWQgcGFyc2VfZ2xvYmFsX2NvbmZpZyhjb25z
dCBjaGFyICpjb25maWdmaWxlLAogICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcs
ICJkZWZhdWx0YnJpZGdlIiwgJmJ1ZiwgMCkpCiAJZGVmYXVsdF9icmlkZ2UgPSBzdHJkdXAoYnVm
KTsKIAorICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWYuZGVmYXVsdC5n
YXRld2F5ZGV2IiwgJmJ1ZiwgMCkpCisgICAgICAgIGRlZmF1bHRfZ2F0ZXdheWRldiA9IHN0cmR1
cChidWYpOworCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9zdHJpbmcgKGNvbmZpZywgIm91dHB1dF9m
b3JtYXQiLCAmYnVmLCAwKSkgewogICAgICAgICBpZiAoIXN0cmNtcChidWYsICJqc29uIikpCiAg
ICAgICAgICAgICBkZWZhdWx0X291dHB1dF9mb3JtYXQgPSBPVVRQVVRfRk9STUFUX0pTT047CmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC94bC5oIGIvdG9vbHMvbGlieGwveGwuaAppbmRleCBiZTZm
MzhiLi5iODgxZjkyIDEwMDY0NAotLS0gYS90b29scy9saWJ4bC94bC5oCisrKyBiL3Rvb2xzL2xp
YnhsL3hsLmgKQEAgLTE0OCw2ICsxNDgsNyBAQCBleHRlcm4gaW50IGRyeXJ1bl9vbmx5OwogZXh0
ZXJuIGNoYXIgKmxvY2tmaWxlOwogZXh0ZXJuIGNoYXIgKmRlZmF1bHRfdmlmc2NyaXB0OwogZXh0
ZXJuIGNoYXIgKmRlZmF1bHRfYnJpZGdlOworZXh0ZXJuIGNoYXIgKmRlZmF1bHRfZ2F0ZXdheWRl
djsKIGV4dGVybiBjaGFyICpibGtkZXZfc3RhcnQ7CiAKIGVudW0gb3V0cHV0X2Zvcm1hdCB7CmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29scy9saWJ4bC94bF9jbWRp
bXBsLmMKaW5kZXggZGMxNzg4ZS4uNzc5NjQ5OCAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtMTE0MSw2ICsxMTQx
LDExIEBAIHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNvbmZpZ19z
b3VyY2UsCiAgICAgICAgICAgICAgICAgbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwogICAgICAgICAgICAgfQogCisgICAgICAgICAgICBpZiAoZGVmYXVsdF9nYXRld2F5ZGV2
KSB7CisgICAgICAgICAgICAgICAgZnJlZShuaWMtPmdhdGV3YXlkZXYpOworICAgICAgICAgICAg
ICAgIG5pYy0+Z2F0ZXdheWRldiA9IHN0cmR1cChkZWZhdWx0X2dhdGV3YXlkZXYpOworICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICBwID0gc3RydG9rKGJ1ZjIsICIsIik7CiAgICAgICAgICAg
ICBpZiAoIXApCiAgICAgICAgICAgICAgICAgZ290byBza2lwX25pYzsKLS0gCjEuNy43LjUgKEFw
cGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:06:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U39O3-000390-Br; Wed, 06 Feb 2013 18:06:23 +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 1U39O1-00038Q-0A
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:06:21 +0000
Received: from [193.109.254.147:49134] by server-1.bemta-14.messagelabs.com id
	B8/36-29874-C9B92115; Wed, 06 Feb 2013 18:06:20 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360173976!1420199!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22812 invoked from network); 6 Feb 2013 18:06:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:06:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1210516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:06:15 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Wed, 6 Feb 2013 18:06:14 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 6 Feb 2013 19:04:35 +0100
Message-ID: <1360173877-12696-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBhZGRzIGEgbmV3IGdsb2JhbCBvcHRpb24gaW4gdGhlIHhsIGNvbmZpZ3VyYXRpb24gZmls
ZSBjYWxsZWQKInZpZi5kZWZhdWx0LmdhdGV3YXlkZXYiLCB0aGF0IGlzIHVzZWQgdG8gc3BlY2lm
eSB0aGUgZGVmYXVsdApnYXRld2F5ZGV2IHRvIHVzZSB3aGVuIG5vbmUgaXMgcGFzc2VkIGluIHRo
ZSB2aWYgc3BlY2lmaWNhdGlvbi4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJv
Z2VyLnBhdUBjaXRyaXguY29tPgpDYzogVWxmIEtyZXV0emJlcmcgPHVsZi5rcmV1dHpiZXJnQGhv
c3RldXJvcGUuZGU+CkNjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpD
YzogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgotLS0KQ2hhbmdlcyBz
aW5jZSB2MToKICogUmVuYW1lIGRlZmF1bHRuZXRkZXYgdG8gdmlmLmRlZmF1bHQuZ2F0ZXdheWRl
dgotLS0KIGRvY3MvbWFuL3hsLmNvbmYucG9kLjUgICB8ICAgIDYgKysrKysrCiB0b29scy9leGFt
cGxlcy94bC5jb25mICAgfCAgICAzICsrKwogdG9vbHMvbGlieGwveGwuYyAgICAgICAgIHwgICAg
NCArKysrCiB0b29scy9saWJ4bC94bC5oICAgICAgICAgfCAgICAxICsKIHRvb2xzL2xpYnhsL3hs
X2NtZGltcGwuYyB8ICAgIDUgKysrKysKIDUgZmlsZXMgY2hhbmdlZCwgMTkgaW5zZXJ0aW9ucygr
KSwgMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kb2NzL21hbi94bC5jb25mLnBvZC41IGIv
ZG9jcy9tYW4veGwuY29uZi5wb2QuNQppbmRleCA4MmM2YjIwLi5mOGY3ZTdmIDEwMDY0NAotLS0g
YS9kb2NzL21hbi94bC5jb25mLnBvZC41CisrKyBiL2RvY3MvbWFuL3hsLmNvbmYucG9kLjUKQEAg
LTgyLDYgKzgyLDEyIEBAIENvbmZpZ3VyZXMgdGhlIGRlZmF1bHQgYnJpZGdlIHRvIHNldCBmb3Ig
dmlydHVhbCBuZXR3b3JrIGRldmljZXMuCiAKIERlZmF1bHQ6IEM8eGVuYnIwPgogCis9aXRlbSBC
PHZpZi5kZWZhdWx0LmdhdGV3YXlkZXY9Ik5BTUUiPgorCitDb25maWd1cmVzIHRoZSBkZWZhdWx0
IGdhdGV3YXkgZGV2aWNlIHRvIHNldCBmb3IgdmlydHVhbCBuZXR3b3JrIGRldmljZXMuCisKK0Rl
ZmF1bHQ6IEM8Tm9uZT4KKwogPWl0ZW0gQjxvdXRwdXRfZm9ybWF0PSJqc29ufHN4cCI+CiAKIENv
bmZpZ3VyZXMgdGhlIGRlZmF1bHQgb3V0cHV0IGZvcm1hdCB1c2VkIGJ5IHhsIHdoZW4gcHJpbnRp
bmcgIm1hY2hpbmUKZGlmZiAtLWdpdCBhL3Rvb2xzL2V4YW1wbGVzL3hsLmNvbmYgYi90b29scy9l
eGFtcGxlcy94bC5jb25mCmluZGV4IDI4YWI3OTYuLjlhMDNmZmYgMTAwNjQ0Ci0tLSBhL3Rvb2xz
L2V4YW1wbGVzL3hsLmNvbmYKKysrIGIvdG9vbHMvZXhhbXBsZXMveGwuY29uZgpAQCAtMjAsMyAr
MjAsNiBAQAogIyBpZiBkaXNhYmxlZCB0aGUgb2xkIGJlaGF2aW91ciB3aWxsIGJlIHVzZWQsIGFu
ZCBob3RwbHVnIHNjcmlwdHMgd2lsbCBiZQogIyBsYXVuY2hlZCBieSB1ZGV2LgogI3J1bl9ob3Rw
bHVnX3NjcmlwdHM9MQorCisjIGRlZmF1bHQgZ2F0ZXdheSBkZXZpY2UgdG8gdXNlIHdpdGggdmlm
LXJvdXRlIGhvdHBsdWcgc2NyaXB0CisjdmlmLmRlZmF1bHQuZ2F0ZXdheWRldj0iZXRoMCIKZGlm
ZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsLmMgYi90b29scy9saWJ4bC94bC5jCmluZGV4IGVjYmNk
M2IuLmY2NTcyMTYgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsLmMKKysrIGIvdG9vbHMvbGli
eGwveGwuYwpAQCAtNDMsNiArNDMsNyBAQCBpbnQgcnVuX2hvdHBsdWdfc2NyaXB0cyA9IDE7CiBj
aGFyICpsb2NrZmlsZTsKIGNoYXIgKmRlZmF1bHRfdmlmc2NyaXB0ID0gTlVMTDsKIGNoYXIgKmRl
ZmF1bHRfYnJpZGdlID0gTlVMTDsKK2NoYXIgKmRlZmF1bHRfZ2F0ZXdheWRldiA9IE5VTEw7CiBl
bnVtIG91dHB1dF9mb3JtYXQgZGVmYXVsdF9vdXRwdXRfZm9ybWF0ID0gT1VUUFVUX0ZPUk1BVF9K
U09OOwogCiBzdGF0aWMgeGVudG9vbGxvZ19sZXZlbCBtaW5tc2dsZXZlbCA9IFhUTF9QUk9HUkVT
UzsKQEAgLTkxLDYgKzkyLDkgQEAgc3RhdGljIHZvaWQgcGFyc2VfZ2xvYmFsX2NvbmZpZyhjb25z
dCBjaGFyICpjb25maWdmaWxlLAogICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcs
ICJkZWZhdWx0YnJpZGdlIiwgJmJ1ZiwgMCkpCiAJZGVmYXVsdF9icmlkZ2UgPSBzdHJkdXAoYnVm
KTsKIAorICAgIGlmICgheGx1X2NmZ19nZXRfc3RyaW5nIChjb25maWcsICJ2aWYuZGVmYXVsdC5n
YXRld2F5ZGV2IiwgJmJ1ZiwgMCkpCisgICAgICAgIGRlZmF1bHRfZ2F0ZXdheWRldiA9IHN0cmR1
cChidWYpOworCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9zdHJpbmcgKGNvbmZpZywgIm91dHB1dF9m
b3JtYXQiLCAmYnVmLCAwKSkgewogICAgICAgICBpZiAoIXN0cmNtcChidWYsICJqc29uIikpCiAg
ICAgICAgICAgICBkZWZhdWx0X291dHB1dF9mb3JtYXQgPSBPVVRQVVRfRk9STUFUX0pTT047CmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC94bC5oIGIvdG9vbHMvbGlieGwveGwuaAppbmRleCBiZTZm
MzhiLi5iODgxZjkyIDEwMDY0NAotLS0gYS90b29scy9saWJ4bC94bC5oCisrKyBiL3Rvb2xzL2xp
YnhsL3hsLmgKQEAgLTE0OCw2ICsxNDgsNyBAQCBleHRlcm4gaW50IGRyeXJ1bl9vbmx5OwogZXh0
ZXJuIGNoYXIgKmxvY2tmaWxlOwogZXh0ZXJuIGNoYXIgKmRlZmF1bHRfdmlmc2NyaXB0OwogZXh0
ZXJuIGNoYXIgKmRlZmF1bHRfYnJpZGdlOworZXh0ZXJuIGNoYXIgKmRlZmF1bHRfZ2F0ZXdheWRl
djsKIGV4dGVybiBjaGFyICpibGtkZXZfc3RhcnQ7CiAKIGVudW0gb3V0cHV0X2Zvcm1hdCB7CmRp
ZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMgYi90b29scy9saWJ4bC94bF9jbWRp
bXBsLmMKaW5kZXggZGMxNzg4ZS4uNzc5NjQ5OCAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwveGxf
Y21kaW1wbC5jCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtMTE0MSw2ICsxMTQx
LDExIEBAIHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNvbmZpZ19z
b3VyY2UsCiAgICAgICAgICAgICAgICAgbmljLT5icmlkZ2UgPSBzdHJkdXAoZGVmYXVsdF9icmlk
Z2UpOwogICAgICAgICAgICAgfQogCisgICAgICAgICAgICBpZiAoZGVmYXVsdF9nYXRld2F5ZGV2
KSB7CisgICAgICAgICAgICAgICAgZnJlZShuaWMtPmdhdGV3YXlkZXYpOworICAgICAgICAgICAg
ICAgIG5pYy0+Z2F0ZXdheWRldiA9IHN0cmR1cChkZWZhdWx0X2dhdGV3YXlkZXYpOworICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICBwID0gc3RydG9rKGJ1ZjIsICIsIik7CiAgICAgICAgICAg
ICBpZiAoIXApCiAgICAgICAgICAgICAgICAgZ290byBza2lwX25pYzsKLS0gCjEuNy43LjUgKEFw
cGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:11:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:11: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 1U39Sy-0003lU-4o; Wed, 06 Feb 2013 18:11:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blp@cs.stanford.edu>) id 1U38qP-0001Om-Rf
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:31:37 +0000
Received: from [85.158.143.99:23281] by server-3.bemta-4.messagelabs.com id
	42/6A-08920-97392115; Wed, 06 Feb 2013 17:31:37 +0000
X-Env-Sender: blp@cs.stanford.edu
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360171892!23933864!1
X-Originating-IP: [171.64.64.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28446 invoked from network); 6 Feb 2013 17:31:36 -0000
Received: from cs-smtp-3.stanford.edu (HELO cs-smtp-3.Stanford.EDU)
	(171.64.64.27)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 17:31:36 -0000
Received: from c-76-126-155-42.hsd1.ca.comcast.net ([76.126.155.42]
	helo=blp.benpfaff.org)
	by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.77) (envelope-from <blp@cs.stanford.edu>)
	id 1U38qG-0006aE-96; Wed, 06 Feb 2013 09:31:30 -0800
From: Ben Pfaff <blp@cs.stanford.edu>
To: Ian Campbell <ian.campbell@citrix.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
	<1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
Date: Wed, 06 Feb 2013 09:31:24 -0800
In-Reply-To: <1360171098-1240-3-git-send-email-ian.campbell@citrix.com> (Ian
	Campbell's message of "Wed, 6 Feb 2013 17:18:17 +0000")
Message-ID: <87ehgtgxhv.fsf@blp.benpfaff.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
X-Spam-Score: -1.0
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin on cs-smtp-3.Stanford.EDU
X-Scan-Signature: 9f3c248a972b2d7af50d43d52b81e7b3
X-Mailman-Approved-At: Wed, 06 Feb 2013 18:11:26 +0000
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated
	memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: blp@cs.stanford.edu
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> +	/*
> +	 * Unwind, freeing all pages and sending error
> +	 * reponses.
> +	 */

s/reponses/responses/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:11:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:11: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 1U39Sy-0003lU-4o; Wed, 06 Feb 2013 18:11:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blp@cs.stanford.edu>) id 1U38qP-0001Om-Rf
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 17:31:37 +0000
Received: from [85.158.143.99:23281] by server-3.bemta-4.messagelabs.com id
	42/6A-08920-97392115; Wed, 06 Feb 2013 17:31:37 +0000
X-Env-Sender: blp@cs.stanford.edu
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360171892!23933864!1
X-Originating-IP: [171.64.64.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28446 invoked from network); 6 Feb 2013 17:31:36 -0000
Received: from cs-smtp-3.stanford.edu (HELO cs-smtp-3.Stanford.EDU)
	(171.64.64.27)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 17:31:36 -0000
Received: from c-76-126-155-42.hsd1.ca.comcast.net ([76.126.155.42]
	helo=blp.benpfaff.org)
	by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.77) (envelope-from <blp@cs.stanford.edu>)
	id 1U38qG-0006aE-96; Wed, 06 Feb 2013 09:31:30 -0800
From: Ben Pfaff <blp@cs.stanford.edu>
To: Ian Campbell <ian.campbell@citrix.com>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
	<1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
Date: Wed, 06 Feb 2013 09:31:24 -0800
In-Reply-To: <1360171098-1240-3-git-send-email-ian.campbell@citrix.com> (Ian
	Campbell's message of "Wed, 6 Feb 2013 17:18:17 +0000")
Message-ID: <87ehgtgxhv.fsf@blp.benpfaff.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
X-Spam-Score: -1.0
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin on cs-smtp-3.Stanford.EDU
X-Scan-Signature: 9f3c248a972b2d7af50d43d52b81e7b3
X-Mailman-Approved-At: Wed, 06 Feb 2013 18:11:26 +0000
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated
	memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: blp@cs.stanford.edu
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> +	/*
> +	 * Unwind, freeing all pages and sending error
> +	 * reponses.
> +	 */

s/reponses/responses/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:48:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:48: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 1U3A2x-00053v-L9; Wed, 06 Feb 2013 18:48: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 1U3A2v-00053q-CO
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 18:48:37 +0000
Received: from [85.158.139.211:64390] by server-2.bemta-5.messagelabs.com id
	4C/C8-16911-485A2115; Wed, 06 Feb 2013 18:48:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360176515!21376826!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3637 invoked from network); 6 Feb 2013 18:48:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:48:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1211368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:48: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.297.1; Wed, 6 Feb 2013 18:48:35 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3A2t-0007RF-3V;
	Wed, 06 Feb 2013 18:48:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3A2s-00082A-Qx;
	Wed, 06 Feb 2013 18:48:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15434-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 18:48:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15434: 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 15434 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15434/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15181

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   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-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   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-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  b8a523d9f14c
baseline version:
 xen                  7c04074a0a0f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <JBeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
+ revision=b8a523d9f14c
+ . 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.2-testing b8a523d9f14c
+ branch=xen-4.2-testing
+ revision=b8a523d9f14c
+ . 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.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-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.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r b8a523d9f14c ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 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 Wed Feb 06 18:48:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:48: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 1U3A2x-00053v-L9; Wed, 06 Feb 2013 18:48: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 1U3A2v-00053q-CO
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 18:48:37 +0000
Received: from [85.158.139.211:64390] by server-2.bemta-5.messagelabs.com id
	4C/C8-16911-485A2115; Wed, 06 Feb 2013 18:48:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360176515!21376826!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3637 invoked from network); 6 Feb 2013 18:48:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:48:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1211368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:48: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.297.1; Wed, 6 Feb 2013 18:48:35 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3A2t-0007RF-3V;
	Wed, 06 Feb 2013 18:48:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3A2s-00082A-Qx;
	Wed, 06 Feb 2013 18:48:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15434-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 6 Feb 2013 18:48:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15434: 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 15434 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15434/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15181

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   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-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   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-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  b8a523d9f14c
baseline version:
 xen                  7c04074a0a0f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <JBeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
+ revision=b8a523d9f14c
+ . 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.2-testing b8a523d9f14c
+ branch=xen-4.2-testing
+ revision=b8a523d9f14c
+ . 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.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-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.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r b8a523d9f14c ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 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 Wed Feb 06 18:49:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U3A36-00054o-AV; Wed, 06 Feb 2013 18:48:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U3A35-00054g-8y
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:48:47 +0000
Received: from [193.109.254.147:40970] by server-9.bemta-14.messagelabs.com id
	73/1F-30867-E85A2115; Wed, 06 Feb 2013 18:48:46 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360176522!9034700!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32051 invoked from network); 6 Feb 2013 18:48:43 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-8.tower-27.messagelabs.com with SMTP;
	6 Feb 2013 18:48:43 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id A1672584105;
	Wed,  6 Feb 2013 10:47:42 -0800 (PST)
Date: Wed, 06 Feb 2013 13:47:37 -0500 (EST)
Message-Id: <20130206.134737.967342633025530520.davem@davemloft.net>
To: blp@cs.stanford.edu
From: David Miller <davem@davemloft.net>
In-Reply-To: <87ehgtgxhv.fsf@blp.benpfaff.org>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
	<1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
	<87ehgtgxhv.fsf@blp.benpfaff.org>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated
 memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Pfaff <blp@cs.stanford.edu>
Date: Wed, 06 Feb 2013 09:31:24 -0800

> Ian Campbell <ian.campbell@citrix.com> writes:
> 
>> +	/*
>> +	 * Unwind, freeing all pages and sending error
>> +	 * reponses.
>> +	 */
> 
> s/reponses/responses/

Also please format your comments in the standard networking form
which is:

	/* Like
	 * this.
	 */

Patch #1 has the same problem, 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 Feb 06 18:49:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18: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 1U3A36-00054o-AV; Wed, 06 Feb 2013 18:48:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U3A35-00054g-8y
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:48:47 +0000
Received: from [193.109.254.147:40970] by server-9.bemta-14.messagelabs.com id
	73/1F-30867-E85A2115; Wed, 06 Feb 2013 18:48:46 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360176522!9034700!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32051 invoked from network); 6 Feb 2013 18:48:43 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-8.tower-27.messagelabs.com with SMTP;
	6 Feb 2013 18:48:43 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id A1672584105;
	Wed,  6 Feb 2013 10:47:42 -0800 (PST)
Date: Wed, 06 Feb 2013 13:47:37 -0500 (EST)
Message-Id: <20130206.134737.967342633025530520.davem@davemloft.net>
To: blp@cs.stanford.edu
From: David Miller <davem@davemloft.net>
In-Reply-To: <87ehgtgxhv.fsf@blp.benpfaff.org>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
	<1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
	<87ehgtgxhv.fsf@blp.benpfaff.org>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated
 memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Pfaff <blp@cs.stanford.edu>
Date: Wed, 06 Feb 2013 09:31:24 -0800

> Ian Campbell <ian.campbell@citrix.com> writes:
> 
>> +	/*
>> +	 * Unwind, freeing all pages and sending error
>> +	 * reponses.
>> +	 */
> 
> s/reponses/responses/

Also please format your comments in the standard networking form
which is:

	/* Like
	 * this.
	 */

Patch #1 has the same problem, 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 Feb 06 18:57:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:57: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 1U3ABC-0005ht-LQ; Wed, 06 Feb 2013 18:57:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3ABA-0005hj-VF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:57:09 +0000
Received: from [193.109.254.147:9287] by server-14.bemta-14.messagelabs.com id
	E7/F0-02031-487A2115; Wed, 06 Feb 2013 18:57:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360177027!9035345!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14504 invoked from network); 6 Feb 2013 18:57:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1211492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:57:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 6 Feb 2013
	18:57:07 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 18:57:06 +0000
Thread-Topic: [PATCH 3/5] Implement code to read coverage informations
Thread-Index: Ac4Em8Jz1q8Kn7gxSwmuu5uxWlYiZw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836E@LONPMAILBOX01.citrite.net>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
	<1360170733.32479.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360170733.32479.16.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: "Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3/5] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 17:12 +0000, Ian Campbell wrote:
> > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> > index 3225b2a..5e80400 100644
> > --- a/xen/include/public/sysctl.h
> > +++ b/xen/include/public/sysctl.h
> > @@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
> >  typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
> >  
> > +/* XEN_SYSCTL_coverage_op */
> > +/*
> > + * Check if coverage informations are available
> > + * return just success or error, no parameters
> > + */
> > +#define XEN_SYSCTL_COVERAGE_enabled        0
> 
> You can detect this by getting -ENOSYS from the hypercall, which is what
> you would get running the tool on an older hypervisor, so you need to
> handle it anyway.
> 

Yes, I think so. I'll change it. Was here cause on the separate
hypercall was the only operation available to non privileged domains but
since sysctl already check for it there is no clue.

> > +
> > +/*
> > + * Get total size of information, to help allocate
> > + * the buffer. The pointer points to a 32 bit value.
> > + */
> > +#define XEN_SYSCTL_COVERAGE_get_total_size 1
> > +
> > +/*
> > + * Read coverage information in a single run
> > + * You must use a tool to split them
> > + */
> > +#define XEN_SYSCTL_COVERAGE_read           2
> > +
> > +/*
> > + * Reset all the coverage counters to 0
> > + * No parameters.
> > + */
> > +#define XEN_SYSCTL_COVERAGE_reset          3
> 
> Any need for simultaneous read+reset?
> 

Mmmm... possibly could help, I'll add it!

> > +struct xen_sysctl_coverage_op {
> > +    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> > +    union {
> > +        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
> 
> This one can just be a uint32_t I think, no need for it to be a
> pointer/handle.
> 

I could, this require to set copyback to 1 in do_sysctl. Yes, it's
probably only a single instruction. It also complicate a bit the program
that extract the information but it's not a problem. And performance are
not a problem too. So, do you prefer I change it to uint32_t directly ?

I don't like the idea to pass a pointer to copyback to
sysctl_coverage_op as this could lead to sub optimization in do_sysctl
(passing a pointer lead to a stack allocation for the variable,
currently compiler can allocate just a register).

> > +        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
> > +    } u;
> > +};
> > +typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
> > +
> > +
> >  struct xen_sysctl {
> >      uint32_t cmd;
> >  #define XEN_SYSCTL_readconsole                    1
> > @@ -616,6 +652,7 @@ struct xen_sysctl {
> >  #define XEN_SYSCTL_numainfo                      17
> >  #define XEN_SYSCTL_cpupool_op                    18
> >  #define XEN_SYSCTL_scheduler_op                  19
> > +#define XEN_SYSCTL_coverage_op                   20
> >      uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> >      union {
> >          struct xen_sysctl_readconsole       readconsole;
> > @@ -636,6 +673,7 @@ struct xen_sysctl {
> >          struct xen_sysctl_lockprof_op       lockprof_op;
> >          struct xen_sysctl_cpupool_op        cpupool_op;
> >          struct xen_sysctl_scheduler_op      scheduler_op;
> > +        struct xen_sysctl_coverage_op       coverage_op;
> >          uint8_t                             pad[128];
> >      } u;
> >  };
> 
> 

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 18:57:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 18:57: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 1U3ABC-0005ht-LQ; Wed, 06 Feb 2013 18:57:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3ABA-0005hj-VF
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 18:57:09 +0000
Received: from [193.109.254.147:9287] by server-14.bemta-14.messagelabs.com id
	E7/F0-02031-487A2115; Wed, 06 Feb 2013 18:57:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360177027!9035345!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMjEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14504 invoked from network); 6 Feb 2013 18:57:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Feb 2013 18:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; 
   d="scan'208";a="1211492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Feb 2013 18:57:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 6 Feb 2013
	18:57:07 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 6 Feb 2013 18:57:06 +0000
Thread-Topic: [PATCH 3/5] Implement code to read coverage informations
Thread-Index: Ac4Em8Jz1q8Kn7gxSwmuu5uxWlYiZw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836E@LONPMAILBOX01.citrite.net>
References: <1360161180-3448-1-git-send-email-frediano.ziglio@citrix.com>
	<1360161180-3448-4-git-send-email-frediano.ziglio@citrix.com>
	<1360170733.32479.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360170733.32479.16.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: "Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3/5] Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 17:12 +0000, Ian Campbell wrote:
> > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> > index 3225b2a..5e80400 100644
> > --- a/xen/include/public/sysctl.h
> > +++ b/xen/include/public/sysctl.h
> > @@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
> >  typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
> >  
> > +/* XEN_SYSCTL_coverage_op */
> > +/*
> > + * Check if coverage informations are available
> > + * return just success or error, no parameters
> > + */
> > +#define XEN_SYSCTL_COVERAGE_enabled        0
> 
> You can detect this by getting -ENOSYS from the hypercall, which is what
> you would get running the tool on an older hypervisor, so you need to
> handle it anyway.
> 

Yes, I think so. I'll change it. Was here cause on the separate
hypercall was the only operation available to non privileged domains but
since sysctl already check for it there is no clue.

> > +
> > +/*
> > + * Get total size of information, to help allocate
> > + * the buffer. The pointer points to a 32 bit value.
> > + */
> > +#define XEN_SYSCTL_COVERAGE_get_total_size 1
> > +
> > +/*
> > + * Read coverage information in a single run
> > + * You must use a tool to split them
> > + */
> > +#define XEN_SYSCTL_COVERAGE_read           2
> > +
> > +/*
> > + * Reset all the coverage counters to 0
> > + * No parameters.
> > + */
> > +#define XEN_SYSCTL_COVERAGE_reset          3
> 
> Any need for simultaneous read+reset?
> 

Mmmm... possibly could help, I'll add it!

> > +struct xen_sysctl_coverage_op {
> > +    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
> > +    union {
> > +        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
> 
> This one can just be a uint32_t I think, no need for it to be a
> pointer/handle.
> 

I could, this require to set copyback to 1 in do_sysctl. Yes, it's
probably only a single instruction. It also complicate a bit the program
that extract the information but it's not a problem. And performance are
not a problem too. So, do you prefer I change it to uint32_t directly ?

I don't like the idea to pass a pointer to copyback to
sysctl_coverage_op as this could lead to sub optimization in do_sysctl
(passing a pointer lead to a stack allocation for the variable,
currently compiler can allocate just a register).

> > +        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
> > +    } u;
> > +};
> > +typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
> > +
> > +
> >  struct xen_sysctl {
> >      uint32_t cmd;
> >  #define XEN_SYSCTL_readconsole                    1
> > @@ -616,6 +652,7 @@ struct xen_sysctl {
> >  #define XEN_SYSCTL_numainfo                      17
> >  #define XEN_SYSCTL_cpupool_op                    18
> >  #define XEN_SYSCTL_scheduler_op                  19
> > +#define XEN_SYSCTL_coverage_op                   20
> >      uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
> >      union {
> >          struct xen_sysctl_readconsole       readconsole;
> > @@ -636,6 +673,7 @@ struct xen_sysctl {
> >          struct xen_sysctl_lockprof_op       lockprof_op;
> >          struct xen_sysctl_cpupool_op        cpupool_op;
> >          struct xen_sysctl_scheduler_op      scheduler_op;
> > +        struct xen_sysctl_coverage_op       coverage_op;
> >          uint8_t                             pad[128];
> >      } u;
> >  };
> 
> 

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 20:51:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 20:51: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 1U3Bxj-0001ac-7I; Wed, 06 Feb 2013 20:51:23 +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 1U3Bxi-0001aU-AM
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 20:51:22 +0000
Received: from [85.158.137.99:58353] by server-13.bemta-3.messagelabs.com id
	B6/71-20653-942C2115; Wed, 06 Feb 2013 20:51:21 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360183880!20288957!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjA4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9963 invoked from network); 6 Feb 2013 20:51:20 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 20:51:20 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r16KbaX9018887
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:40 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r16KbXD4032120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:33 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r16KbXGW017691
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:33 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r16KbXQf017684
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:33 GMT
Date: Wed, 6 Feb 2013 20:37:33 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1158223494-1360183053=:12408"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r16KbaX9018887
Subject: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-1158223494-1360183053=:12408
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Fedora rawhide has just moved onto gcc 4.8, and I have had to apply the 
attached patch to get it to build (I constructed the patch against 4.2.1 
but I believe it will apply to xen-unstable).

There are two types of problem, the first is from 
xen/common/compat/memory.c where the error is

memory.c: In function 'compat_memory_op':
/builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: 
error: typedef '__guest_handle_const_compat_memory_exchange_t' locally 
defined but not used [-Werror=unused-local-typedefs]
      typedef struct { type *p; } __guest_handle_ ## name
                                  ^
/builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: 
note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
      ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
      ^
/builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: 
note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
name)
                                          ^
memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
              DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
              ^

so we are defining something that isn't used.

Secondly gcc 4.8 objects to lines like

memset(ctxt, 0, sizeof(ctxt));

where I think you are just zeroing a pointer's worth of memory. There are 
a few cases of this in the xen code fixed in the patch, and I am also 
suspicious of line 630 of 
stubdom/grub-upstream/stage2/fsys_reiserfs.c which is

memset (INFO->blocks, 0, sizeof (INFO->blocks));

which is noted in the build log but not flagged as an error.

 	Michael Young
--8323329-1158223494-1360183053=:12408
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.patch

LS0tIHhlbi00LjIuMS94ZW4vY29tbW9uL2NvbXBhdC9tZW1vcnkuYy5vcmln
CTIwMTItMTItMTcgMTU6MDE6NTQuMDAwMDAwMDAwICswMDAwDQorKysgeGVu
LTQuMi4xL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5jCTIwMTMtMDEtMjgg
MjE6MjQ6MzYuOTcxMjQxMjI5ICswMDAwDQpAQCAtMjU4LDcgKzI1OCw3IEBA
DQogDQogICAgICAgICBjYXNlIFhFTk1FTV9leGNoYW5nZToNCiAgICAgICAg
IHsNCi0gICAgICAgICAgICBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShjb21w
YXRfbWVtb3J5X2V4Y2hhbmdlX3QpOw0KKyAgICAgICAgICAgIERFRklORV9Y
RU5fR1VFU1RfSEFORExFKGNvbXBhdF9tZW1vcnlfZXhjaGFuZ2VfdCkgX19h
dHRyaWJ1dGVfXygodW51c2VkKSk7DQogICAgICAgICAgICAgaW50IG9yZGVy
X2RlbHRhOw0KIA0KICAgICAgICAgICAgIEJVR19PTihzcGxpdCA+PSAwICYm
IHJjKTsNCi0tLSB4ZW4tNC4yLjEvdG9vbHMvbGlieGMveGNfZG9tX2Jvb3Qu
Yy5vcmlnCTIwMTItMTItMTcgMTU6MDA6NDguMDAwMDAwMDAwICswMDAwDQor
KysgeGVuLTQuMi4xL3Rvb2xzL2xpYnhjL3hjX2RvbV9ib290LmMJMjAxMy0w
MS0yOCAyMjoyMToxMy4yMTU3ODIzMjkgKzAwMDANCkBAIC0yNjYsNyArMjY2
LDcgQEANCiAgICAgICAgIHJldHVybiByYzsNCiANCiAgICAgLyogbGV0IHRo
ZSB2bSBydW4gKi8NCi0gICAgbWVtc2V0KGN0eHQsIDAsIHNpemVvZihjdHh0
KSk7DQorICAgIG1lbXNldChjdHh0LCAwLCBzaXplb2YoKmN0eHQpKTsNCiAg
ICAgaWYgKCAocmMgPSBkb20tPmFyY2hfaG9va3MtPnZjcHUoZG9tLCBjdHh0
KSkgIT0gMCApDQogICAgICAgICByZXR1cm4gcmM7DQogICAgIHhjX2RvbV91
bm1hcF9hbGwoZG9tKTsNCi0tLSB4ZW4tNC4yLjEvdG9vbHMvYmxrdGFwMi9k
cml2ZXJzL21kNS5jLm9yaWcJMjAxMi0xMi0xNyAxNTowMDoxMS4wMDAwMDAw
MDAgKzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMvYmxrdGFwMi9kcml2ZXJz
L21kNS5jCTIwMTMtMDEtMjggMjM6NDk6NTEuOTQwMjg5MTIzICswMDAwDQpA
QCAtMTc0LDcgKzE3NCw3IEBADQogICAgIE1ENVRyYW5zZm9ybShjdHgtPmJ1
ZiwgKHVpbnQzMl90ICopIGN0eC0+aW4pOw0KICAgICBieXRlUmV2ZXJzZSgo
dW5zaWduZWQgY2hhciAqKSBjdHgtPmJ1ZiwgNCk7DQogICAgIG1lbWNweShk
aWdlc3QsIGN0eC0+YnVmLCAxNik7DQotICAgIG1lbXNldChjdHgsIDAsIHNp
emVvZihjdHgpKTsgICAgIC8qIEluIGNhc2UgaXQncyBzZW5zaXRpdmUgKi8N
CisgICAgbWVtc2V0KGN0eCwgMCwgc2l6ZW9mKCpjdHgpKTsgICAgIC8qIElu
IGNhc2UgaXQncyBzZW5zaXRpdmUgKi8NCiB9DQogDQogLyogVGhlIGZvdXIg
Y29yZSBmdW5jdGlvbnMgLSBGMSBpcyBvcHRpbWl6ZWQgc29tZXdoYXQgKi8N
Ci0tLSB4ZW4tNC4yLjEvdG9vbHMvbGlieGwvbGlieGxfcW1wLmMub3JpZwky
MDEyLTEyLTE3IDE1OjAxOjA5LjAwMDAwMDAwMCArMDAwMA0KKysrIHhlbi00
LjIuMS90b29scy9saWJ4bC9saWJ4bF9xbXAuYwkyMDEzLTAxLTI5IDIxOjI4
OjI3Ljc2MzY1MDA3MyArMDAwMA0KQEAgLTM3Nyw3ICszNzcsNyBAQA0KICAg
ICByZXQgPSBsaWJ4bF9mZF9zZXRfY2xvZXhlYyhxbXAtPmN0eCwgcW1wLT5x
bXBfZmQsIDEpOw0KICAgICBpZiAocmV0KSByZXR1cm4gLTE7DQogDQotICAg
IG1lbXNldCgmcW1wLT5hZGRyLCAwLCBzaXplb2YgKCZxbXAtPmFkZHIpKTsN
CisgICAgbWVtc2V0KCZxbXAtPmFkZHIsIDAsIHNpemVvZiAocW1wLT5hZGRy
KSk7DQogICAgIHFtcC0+YWRkci5zdW5fZmFtaWx5ID0gQUZfVU5JWDsNCiAg
ICAgc3RybmNweShxbXAtPmFkZHIuc3VuX3BhdGgsIHFtcF9zb2NrZXRfcGF0
aCwNCiAgICAgICAgICAgICBzaXplb2YgKHFtcC0+YWRkci5zdW5fcGF0aCkp
Ow0KLS0tIHhlbi00LjIuMS90b29scy94ZW5zdGF0L2xpYnhlbnN0YXQvc3Jj
L3hlbnN0YXRfbGludXguYy5vcmlnCTIwMTItMTItMTcgMTU6MDE6MzUuMDAw
MDAwMDAwICswMDAwDQorKysgeGVuLTQuMi4xL3Rvb2xzL3hlbnN0YXQvbGli
eGVuc3RhdC9zcmMveGVuc3RhdF9saW51eC5jCTIwMTMtMDEtMjkgMjE6NDM6
NDYuMDQ0MTY5OTg3ICswMDAwDQpAQCAtMTEzLDcgKzExMyw3IEBADQogDQog
CS8qIEluaXRpYWxpemUgYWxsIHZhcmlhYmxlcyBjYWxsZWQgaGFzIHBhc3Nl
ZCBhcyBub24tTlVMTCB0byB6ZXJvcyAqLw0KIAlpZiAoaWZhY2UgIT0gTlVM
TCkNCi0JCW1lbXNldChpZmFjZSwgMCwgc2l6ZW9mKGlmYWNlKSk7DQorCQlt
ZW1zZXQoaWZhY2UsIDAsIHNpemVvZigqaWZhY2UpKTsNCiAJaWYgKHJ4Qnl0
ZXMgIT0gTlVMTCkNCiAJCSpyeEJ5dGVzID0gMDsNCiAJaWYgKHJ4UGFja2V0
cyAhPSBOVUxMKQ0KLS0tIHhlbi00LjIuMS90b29scy9kZWJ1Z2dlci9rZGQv
a2RkLXhlbi5jLm9yaWcJMjAxMi0xMi0xNyAxNTowMDoyMi4wMDAwMDAwMDAg
KzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMvZGVidWdnZXIva2RkL2tkZC14
ZW4uYwkyMDEzLTAxLTI5IDIxOjQ1OjEyLjY1MjA4NzIzOSArMDAwMA0KQEAg
LTMzMyw3ICszMzMsNyBAQA0KICAgICBpZiAoIWNwdSkgDQogICAgICAgICBy
ZXR1cm4gLTE7DQogDQotICAgIG1lbXNldChyLCAwLCBzaXplb2YocikpOw0K
KyAgICBtZW1zZXQociwgMCwgc2l6ZW9mKCpyKSk7DQogICAgIA0KICAgICBp
ZiAodzY0KQ0KICAgICAgICAga2RkX2dldF9yZWdzX3g4Nl82NChjcHUsICZy
LT5yNjQpOw0KLS0tIHhlbi00LjIuMS90b29scy9weXRob24veGVuL2xvd2xl
dmVsL25ldGxpbmsvbGlibmV0bGluay5jLm9yaWcJMjAxMi0xMi0xNyAxNTow
MToyNC4wMDAwMDAwMDAgKzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMvcHl0
aG9uL3hlbi9sb3dsZXZlbC9uZXRsaW5rL2xpYm5ldGxpbmsuYwkyMDEzLTAx
LTI5IDIxOjQ3OjU5LjUyNDAwMTA1MyArMDAwMA0KQEAgLTM3LDcgKzM3LDcg
QEANCiAgICAgICAgaW50IHNuZGJ1ZiA9IDMyNzY4Ow0KICAgICAgICBpbnQg
cmN2YnVmID0gMzI3Njg7DQogDQotICAgICAgIG1lbXNldChydGgsIDAsIHNp
emVvZihydGgpKTsNCisgICAgICAgbWVtc2V0KHJ0aCwgMCwgc2l6ZW9mKCpy
dGgpKTsNCiANCiAgICAgICAgcnRoLT5mZCA9IHNvY2tldChBRl9ORVRMSU5L
LCBTT0NLX1JBVywgcHJvdG9jb2wpOw0KICAgICAgICBpZiAocnRoLT5mZCA8
IDApIHsNCkBAIC0yNjQsNyArMjY0LDcgQEANCiAgICAgICAgICAgICAgICBy
ZXR1cm4gLTE7DQogICAgICAgIH0NCiANCi0gICAgICAgbWVtc2V0KGJ1Ziww
LHNpemVvZihidWYpKTsNCisgICAgICAgbWVtc2V0KGJ1ZiwwLHNpemVvZigq
YnVmKSk7DQogDQogICAgICAgIGlvdi5pb3ZfYmFzZSA9IGJ1ZjsNCiANCg==

--8323329-1158223494-1360183053=:12408
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1158223494-1360183053=:12408--


From xen-devel-bounces@lists.xen.org Wed Feb 06 20:51:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 20:51: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 1U3Bxj-0001ac-7I; Wed, 06 Feb 2013 20:51:23 +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 1U3Bxi-0001aU-AM
	for xen-devel@lists.xen.org; Wed, 06 Feb 2013 20:51:22 +0000
Received: from [85.158.137.99:58353] by server-13.bemta-3.messagelabs.com id
	B6/71-20653-942C2115; Wed, 06 Feb 2013 20:51:21 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360183880!20288957!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjA4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9963 invoked from network); 6 Feb 2013 20:51:20 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Feb 2013 20:51:20 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r16KbaX9018887
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:40 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r16KbXD4032120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:33 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r16KbXGW017691
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:33 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r16KbXQf017684
	for <xen-devel@lists.xen.org>; Wed, 6 Feb 2013 20:37:33 GMT
Date: Wed, 6 Feb 2013 20:37:33 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xen.org
Message-ID: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1158223494-1360183053=:12408"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r16KbaX9018887
Subject: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-1158223494-1360183053=:12408
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Fedora rawhide has just moved onto gcc 4.8, and I have had to apply the 
attached patch to get it to build (I constructed the patch against 4.2.1 
but I believe it will apply to xen-unstable).

There are two types of problem, the first is from 
xen/common/compat/memory.c where the error is

memory.c: In function 'compat_memory_op':
/builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: 
error: typedef '__guest_handle_const_compat_memory_exchange_t' locally 
defined but not used [-Werror=unused-local-typedefs]
      typedef struct { type *p; } __guest_handle_ ## name
                                  ^
/builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: 
note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
      ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
      ^
/builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: 
note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
name)
                                          ^
memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
              DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
              ^

so we are defining something that isn't used.

Secondly gcc 4.8 objects to lines like

memset(ctxt, 0, sizeof(ctxt));

where I think you are just zeroing a pointer's worth of memory. There are 
a few cases of this in the xen code fixed in the patch, and I am also 
suspicious of line 630 of 
stubdom/grub-upstream/stage2/fsys_reiserfs.c which is

memset (INFO->blocks, 0, sizeof (INFO->blocks));

which is noted in the build log but not flagged as an error.

 	Michael Young
--8323329-1158223494-1360183053=:12408
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.patch

LS0tIHhlbi00LjIuMS94ZW4vY29tbW9uL2NvbXBhdC9tZW1vcnkuYy5vcmln
CTIwMTItMTItMTcgMTU6MDE6NTQuMDAwMDAwMDAwICswMDAwDQorKysgeGVu
LTQuMi4xL3hlbi9jb21tb24vY29tcGF0L21lbW9yeS5jCTIwMTMtMDEtMjgg
MjE6MjQ6MzYuOTcxMjQxMjI5ICswMDAwDQpAQCAtMjU4LDcgKzI1OCw3IEBA
DQogDQogICAgICAgICBjYXNlIFhFTk1FTV9leGNoYW5nZToNCiAgICAgICAg
IHsNCi0gICAgICAgICAgICBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShjb21w
YXRfbWVtb3J5X2V4Y2hhbmdlX3QpOw0KKyAgICAgICAgICAgIERFRklORV9Y
RU5fR1VFU1RfSEFORExFKGNvbXBhdF9tZW1vcnlfZXhjaGFuZ2VfdCkgX19h
dHRyaWJ1dGVfXygodW51c2VkKSk7DQogICAgICAgICAgICAgaW50IG9yZGVy
X2RlbHRhOw0KIA0KICAgICAgICAgICAgIEJVR19PTihzcGxpdCA+PSAwICYm
IHJjKTsNCi0tLSB4ZW4tNC4yLjEvdG9vbHMvbGlieGMveGNfZG9tX2Jvb3Qu
Yy5vcmlnCTIwMTItMTItMTcgMTU6MDA6NDguMDAwMDAwMDAwICswMDAwDQor
KysgeGVuLTQuMi4xL3Rvb2xzL2xpYnhjL3hjX2RvbV9ib290LmMJMjAxMy0w
MS0yOCAyMjoyMToxMy4yMTU3ODIzMjkgKzAwMDANCkBAIC0yNjYsNyArMjY2
LDcgQEANCiAgICAgICAgIHJldHVybiByYzsNCiANCiAgICAgLyogbGV0IHRo
ZSB2bSBydW4gKi8NCi0gICAgbWVtc2V0KGN0eHQsIDAsIHNpemVvZihjdHh0
KSk7DQorICAgIG1lbXNldChjdHh0LCAwLCBzaXplb2YoKmN0eHQpKTsNCiAg
ICAgaWYgKCAocmMgPSBkb20tPmFyY2hfaG9va3MtPnZjcHUoZG9tLCBjdHh0
KSkgIT0gMCApDQogICAgICAgICByZXR1cm4gcmM7DQogICAgIHhjX2RvbV91
bm1hcF9hbGwoZG9tKTsNCi0tLSB4ZW4tNC4yLjEvdG9vbHMvYmxrdGFwMi9k
cml2ZXJzL21kNS5jLm9yaWcJMjAxMi0xMi0xNyAxNTowMDoxMS4wMDAwMDAw
MDAgKzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMvYmxrdGFwMi9kcml2ZXJz
L21kNS5jCTIwMTMtMDEtMjggMjM6NDk6NTEuOTQwMjg5MTIzICswMDAwDQpA
QCAtMTc0LDcgKzE3NCw3IEBADQogICAgIE1ENVRyYW5zZm9ybShjdHgtPmJ1
ZiwgKHVpbnQzMl90ICopIGN0eC0+aW4pOw0KICAgICBieXRlUmV2ZXJzZSgo
dW5zaWduZWQgY2hhciAqKSBjdHgtPmJ1ZiwgNCk7DQogICAgIG1lbWNweShk
aWdlc3QsIGN0eC0+YnVmLCAxNik7DQotICAgIG1lbXNldChjdHgsIDAsIHNp
emVvZihjdHgpKTsgICAgIC8qIEluIGNhc2UgaXQncyBzZW5zaXRpdmUgKi8N
CisgICAgbWVtc2V0KGN0eCwgMCwgc2l6ZW9mKCpjdHgpKTsgICAgIC8qIElu
IGNhc2UgaXQncyBzZW5zaXRpdmUgKi8NCiB9DQogDQogLyogVGhlIGZvdXIg
Y29yZSBmdW5jdGlvbnMgLSBGMSBpcyBvcHRpbWl6ZWQgc29tZXdoYXQgKi8N
Ci0tLSB4ZW4tNC4yLjEvdG9vbHMvbGlieGwvbGlieGxfcW1wLmMub3JpZwky
MDEyLTEyLTE3IDE1OjAxOjA5LjAwMDAwMDAwMCArMDAwMA0KKysrIHhlbi00
LjIuMS90b29scy9saWJ4bC9saWJ4bF9xbXAuYwkyMDEzLTAxLTI5IDIxOjI4
OjI3Ljc2MzY1MDA3MyArMDAwMA0KQEAgLTM3Nyw3ICszNzcsNyBAQA0KICAg
ICByZXQgPSBsaWJ4bF9mZF9zZXRfY2xvZXhlYyhxbXAtPmN0eCwgcW1wLT5x
bXBfZmQsIDEpOw0KICAgICBpZiAocmV0KSByZXR1cm4gLTE7DQogDQotICAg
IG1lbXNldCgmcW1wLT5hZGRyLCAwLCBzaXplb2YgKCZxbXAtPmFkZHIpKTsN
CisgICAgbWVtc2V0KCZxbXAtPmFkZHIsIDAsIHNpemVvZiAocW1wLT5hZGRy
KSk7DQogICAgIHFtcC0+YWRkci5zdW5fZmFtaWx5ID0gQUZfVU5JWDsNCiAg
ICAgc3RybmNweShxbXAtPmFkZHIuc3VuX3BhdGgsIHFtcF9zb2NrZXRfcGF0
aCwNCiAgICAgICAgICAgICBzaXplb2YgKHFtcC0+YWRkci5zdW5fcGF0aCkp
Ow0KLS0tIHhlbi00LjIuMS90b29scy94ZW5zdGF0L2xpYnhlbnN0YXQvc3Jj
L3hlbnN0YXRfbGludXguYy5vcmlnCTIwMTItMTItMTcgMTU6MDE6MzUuMDAw
MDAwMDAwICswMDAwDQorKysgeGVuLTQuMi4xL3Rvb2xzL3hlbnN0YXQvbGli
eGVuc3RhdC9zcmMveGVuc3RhdF9saW51eC5jCTIwMTMtMDEtMjkgMjE6NDM6
NDYuMDQ0MTY5OTg3ICswMDAwDQpAQCAtMTEzLDcgKzExMyw3IEBADQogDQog
CS8qIEluaXRpYWxpemUgYWxsIHZhcmlhYmxlcyBjYWxsZWQgaGFzIHBhc3Nl
ZCBhcyBub24tTlVMTCB0byB6ZXJvcyAqLw0KIAlpZiAoaWZhY2UgIT0gTlVM
TCkNCi0JCW1lbXNldChpZmFjZSwgMCwgc2l6ZW9mKGlmYWNlKSk7DQorCQlt
ZW1zZXQoaWZhY2UsIDAsIHNpemVvZigqaWZhY2UpKTsNCiAJaWYgKHJ4Qnl0
ZXMgIT0gTlVMTCkNCiAJCSpyeEJ5dGVzID0gMDsNCiAJaWYgKHJ4UGFja2V0
cyAhPSBOVUxMKQ0KLS0tIHhlbi00LjIuMS90b29scy9kZWJ1Z2dlci9rZGQv
a2RkLXhlbi5jLm9yaWcJMjAxMi0xMi0xNyAxNTowMDoyMi4wMDAwMDAwMDAg
KzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMvZGVidWdnZXIva2RkL2tkZC14
ZW4uYwkyMDEzLTAxLTI5IDIxOjQ1OjEyLjY1MjA4NzIzOSArMDAwMA0KQEAg
LTMzMyw3ICszMzMsNyBAQA0KICAgICBpZiAoIWNwdSkgDQogICAgICAgICBy
ZXR1cm4gLTE7DQogDQotICAgIG1lbXNldChyLCAwLCBzaXplb2YocikpOw0K
KyAgICBtZW1zZXQociwgMCwgc2l6ZW9mKCpyKSk7DQogICAgIA0KICAgICBp
ZiAodzY0KQ0KICAgICAgICAga2RkX2dldF9yZWdzX3g4Nl82NChjcHUsICZy
LT5yNjQpOw0KLS0tIHhlbi00LjIuMS90b29scy9weXRob24veGVuL2xvd2xl
dmVsL25ldGxpbmsvbGlibmV0bGluay5jLm9yaWcJMjAxMi0xMi0xNyAxNTow
MToyNC4wMDAwMDAwMDAgKzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMvcHl0
aG9uL3hlbi9sb3dsZXZlbC9uZXRsaW5rL2xpYm5ldGxpbmsuYwkyMDEzLTAx
LTI5IDIxOjQ3OjU5LjUyNDAwMTA1MyArMDAwMA0KQEAgLTM3LDcgKzM3LDcg
QEANCiAgICAgICAgaW50IHNuZGJ1ZiA9IDMyNzY4Ow0KICAgICAgICBpbnQg
cmN2YnVmID0gMzI3Njg7DQogDQotICAgICAgIG1lbXNldChydGgsIDAsIHNp
emVvZihydGgpKTsNCisgICAgICAgbWVtc2V0KHJ0aCwgMCwgc2l6ZW9mKCpy
dGgpKTsNCiANCiAgICAgICAgcnRoLT5mZCA9IHNvY2tldChBRl9ORVRMSU5L
LCBTT0NLX1JBVywgcHJvdG9jb2wpOw0KICAgICAgICBpZiAocnRoLT5mZCA8
IDApIHsNCkBAIC0yNjQsNyArMjY0LDcgQEANCiAgICAgICAgICAgICAgICBy
ZXR1cm4gLTE7DQogICAgICAgIH0NCiANCi0gICAgICAgbWVtc2V0KGJ1Ziww
LHNpemVvZihidWYpKTsNCisgICAgICAgbWVtc2V0KGJ1ZiwwLHNpemVvZigq
YnVmKSk7DQogDQogICAgICAgIGlvdi5pb3ZfYmFzZSA9IGJ1ZjsNCiANCg==

--8323329-1158223494-1360183053=:12408
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1158223494-1360183053=:12408--


From xen-devel-bounces@lists.xen.org Wed Feb 06 21:32:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 21:32: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 1U3CbJ-0003NF-6I; Wed, 06 Feb 2013 21:32:17 +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 1U3CbH-0003NA-Hy
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 21:32:15 +0000
Received: from [85.158.139.83:19808] by server-12.bemta-5.messagelabs.com id
	C7/B2-20195-EDBC2115; Wed, 06 Feb 2013 21:32:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360186332!24151603!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTk1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18604 invoked from network); 6 Feb 2013 21:32:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 21:32:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16LVvaG003249
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 21:31:59 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
	r16LVulg007431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 21:31:57 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
	r16LVtW2020272; Wed, 6 Feb 2013 15:31:56 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 13:31:55 -0800
Date: Wed, 6 Feb 2013 13:31:54 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20130206133154.76830173@mantra.us.oracle.com>
In-Reply-To: <20130206154910.GA31828@konrad-lan.dumpdata.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
	<20130206154910.GA31828@konrad-lan.dumpdata.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]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

On Wed, 6 Feb 2013 10:49:13 -0500
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Thu, Jan 31, 2013 at 06:30:15PM -0800, Mukesh Rathor wrote:
> > This patch fixes a fixme in Linux to use alloc_xenballooned_pages()
> > to allocate pfns for grant table pages instead of kmalloc. This also
> > simplifies add to physmap on the xen side a bit.
> 
> Pulled this.
> > 


Konrad, no, there was a follow up email on this thread to discard this.
Please discard this. I resent yesterday with proper fixes. I realize
now I should've given one yesterday version number. My bad, this head 
cold is crippling my brain :).. 

Sorry for the confusion.

Mukesh

Following is the latest patch I emailed yesterday :


This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
allocate pfns for grant table pages instead of kmalloc. This also
simplifies add to physmap on the xen side a bit.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..fdb1d88 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1026,10 +1027,22 @@ static void gnttab_unmap_frames_v2(void)
 	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
+static xen_pfn_t pvh_get_grant_pfn(int grant_idx)
+{
+	unsigned long vaddr;
+	unsigned int level;
+	pte_t *pte;
+
+	vaddr = (unsigned long)(gnttab_shared.addr) + grant_idx * PAGE_SIZE;
+	pte = lookup_address(vaddr, &level);
+	BUG_ON(pte == NULL);
+	return pte_mfn(*pte);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames, start_gpfn;
+	unsigned long *frames, start_gpfn = 0;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
@@ -1040,8 +1053,6 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 		if (xen_hvm_domain())
 			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
-		else
-			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1050,7 +1061,11 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = start_gpfn + i;
+			if (xen_hvm_domain())
+				xatp.gpfn = start_gpfn + i;
+			else
+				xatp.gpfn = pvh_get_grant_pfn(i);
+
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1138,27 +1153,51 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+/*
+ * PVH: we need three things: virtual address, pfns, and mfns. The pfns
+ * are allocated via ballooning, then we call arch_gnttab_map_shared to
+ * allocate the VA and put pfn's in the pte's for the VA. The mfn's are
+ * finally allocated in gnttab_map() by xen which also populates the P2M.
+ */
+static int xlated_setup_gnttab_pages(unsigned long numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+			numpages, rc);
+		return rc;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	if (rc != 0)
+		free_xenballooned_pages(numpages, pages);
+
+	return rc;
+}
+
 int gnttab_resume(void)
 {
+	int rc;
 	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages((unsigned long)max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 21:32:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 21:32: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 1U3CbJ-0003NF-6I; Wed, 06 Feb 2013 21:32:17 +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 1U3CbH-0003NA-Hy
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 21:32:15 +0000
Received: from [85.158.139.83:19808] by server-12.bemta-5.messagelabs.com id
	C7/B2-20195-EDBC2115; Wed, 06 Feb 2013 21:32:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360186332!24151603!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMTk1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18604 invoked from network); 6 Feb 2013 21:32:13 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 21:32:13 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16LVvaG003249
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 21:31:59 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
	r16LVulg007431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 21:31:57 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
	r16LVtW2020272; Wed, 6 Feb 2013 15:31:56 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 13:31:55 -0800
Date: Wed, 6 Feb 2013 13:31:54 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20130206133154.76830173@mantra.us.oracle.com>
In-Reply-To: <20130206154910.GA31828@konrad-lan.dumpdata.com>
References: <20130131183015.13bc2bff@mantra.us.oracle.com>
	<20130206154910.GA31828@konrad-lan.dumpdata.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]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH linux: Use ballooning to allocate grant
	table 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

On Wed, 6 Feb 2013 10:49:13 -0500
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Thu, Jan 31, 2013 at 06:30:15PM -0800, Mukesh Rathor wrote:
> > This patch fixes a fixme in Linux to use alloc_xenballooned_pages()
> > to allocate pfns for grant table pages instead of kmalloc. This also
> > simplifies add to physmap on the xen side a bit.
> 
> Pulled this.
> > 


Konrad, no, there was a follow up email on this thread to discard this.
Please discard this. I resent yesterday with proper fixes. I realize
now I should've given one yesterday version number. My bad, this head 
cold is crippling my brain :).. 

Sorry for the confusion.

Mukesh

Following is the latest patch I emailed yesterday :


This patch fixes a fixme in Linux to use alloc_xenballooned_pages() to
allocate pfns for grant table pages instead of kmalloc. This also
simplifies add to physmap on the xen side a bit.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 9c0019d..fdb1d88 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/interface.h>
 
@@ -1026,10 +1027,22 @@ static void gnttab_unmap_frames_v2(void)
 	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
+static xen_pfn_t pvh_get_grant_pfn(int grant_idx)
+{
+	unsigned long vaddr;
+	unsigned int level;
+	pte_t *pte;
+
+	vaddr = (unsigned long)(gnttab_shared.addr) + grant_idx * PAGE_SIZE;
+	pte = lookup_address(vaddr, &level);
+	BUG_ON(pte == NULL);
+	return pte_mfn(*pte);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames, start_gpfn;
+	unsigned long *frames, start_gpfn = 0;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
@@ -1040,8 +1053,6 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 		if (xen_hvm_domain())
 			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
-		else
-			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1050,7 +1061,11 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = start_gpfn + i;
+			if (xen_hvm_domain())
+				xatp.gpfn = start_gpfn + i;
+			else
+				xatp.gpfn = pvh_get_grant_pfn(i);
+
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1138,27 +1153,51 @@ static void gnttab_request_version(void)
 		grant_table_version);
 }
 
+/*
+ * PVH: we need three things: virtual address, pfns, and mfns. The pfns
+ * are allocated via ballooning, then we call arch_gnttab_map_shared to
+ * allocate the VA and put pfn's in the pte's for the VA. The mfn's are
+ * finally allocated in gnttab_map() by xen which also populates the P2M.
+ */
+static int xlated_setup_gnttab_pages(unsigned long numpages, void **addr)
+{
+	int i, rc;
+	unsigned long pfns[numpages];
+	struct page *pages[numpages];
+
+	rc = alloc_xenballooned_pages(numpages, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+			numpages, rc);
+		return rc;
+	}
+	for (i = 0; i < numpages; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	rc = arch_gnttab_map_shared(pfns, numpages, numpages, addr);
+	if (rc != 0)
+		free_xenballooned_pages(numpages, pages);
+
+	return rc;
+}
+
 int gnttab_resume(void)
 {
+	int rc;
 	unsigned int max_nr_gframes;
-	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
-	/* PVH note: xen will free existing kmalloc'd mfn in
-	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
-	 * kmalloc(). */
 	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
 	    !gnttab_shared.addr) {
-		gnttab_shared.addr =
-			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
-		if (!gnttab_shared.addr) {
-			pr_warn("%s", kmsg);
-			return -ENOMEM;
-		}
+
+		rc = xlated_setup_gnttab_pages((unsigned long)max_nr_gframes,
+					       &gnttab_shared.addr);
+		if (rc != 0)
+			return rc;
 	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 21:35:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 21:35: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 1U3Cdn-0003Sv-Ok; Wed, 06 Feb 2013 21:34:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3Cdm-0003So-Mi
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 21:34:50 +0000
Received: from [85.158.143.35:45841] by server-1.bemta-4.messagelabs.com id
	7F/73-08839-A7CC2115; Wed, 06 Feb 2013 21:34:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360186488!5186646!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31505 invoked from network); 6 Feb 2013 21:34:48 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2013 21:34:48 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:56089 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 1U3Ck0-00035I-Tb; Wed, 06 Feb 2013 22:41:16 +0100
Date: Wed, 6 Feb 2013 22:34:45 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <905879033.20130206223445@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5112602602000078000BC725@nat28.tlf.novell.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, February 6, 2013, 1:52:38 PM, you wrote:

>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm with the patch it does boot, but disables the I/O virtualization.

> Good. While, as said before, I still don't understand why it didn't
> crash earlier without that patch, I'm glad it's fixed. Will post the
> patch for inclusion momentarily.

>> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
>> without the debug patch (where it does crash) ?

> And you can't expect much else with broken ACPI tables:

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

> This is a HPET entry.

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

> so the IOMMU table is lacking an entry for the first IO-APIC, and
> without that we can't set up per-device interrupt remapping (in
> which case we choose to disable the IOMMU altogether, albeit it
> had been questioned whether that isn't making a bad situation
> worse in some cases).

> If you want the IOMMU back (at the price of re-opening the
> security issue described in XSA-36), you'd have to pass
> "iommu=amd-iommu-perdev-intremap" to the hypervisor.

Just for the record (the list), that should be iommu=no-amd-iommu-perdev-intremap

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 21:35:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 21:35: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 1U3Cdn-0003Sv-Ok; Wed, 06 Feb 2013 21:34:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3Cdm-0003So-Mi
	for xen-devel@lists.xensource.com; Wed, 06 Feb 2013 21:34:50 +0000
Received: from [85.158.143.35:45841] by server-1.bemta-4.messagelabs.com id
	7F/73-08839-A7CC2115; Wed, 06 Feb 2013 21:34:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360186488!5186646!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31505 invoked from network); 6 Feb 2013 21:34:48 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Feb 2013 21:34:48 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:56089 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 1U3Ck0-00035I-Tb; Wed, 06 Feb 2013 22:41:16 +0100
Date: Wed, 6 Feb 2013 22:34:45 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <905879033.20130206223445@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5112602602000078000BC725@nat28.tlf.novell.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, February 6, 2013, 1:52:38 PM, you wrote:

>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm with the patch it does boot, but disables the I/O virtualization.

> Good. While, as said before, I still don't understand why it didn't
> crash earlier without that patch, I'm glad it's fixed. Will post the
> patch for inclusion momentarily.

>> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
>> without the debug patch (where it does crash) ?

> And you can't expect much else with broken ACPI tables:

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

> This is a HPET entry.

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

> so the IOMMU table is lacking an entry for the first IO-APIC, and
> without that we can't set up per-device interrupt remapping (in
> which case we choose to disable the IOMMU altogether, albeit it
> had been questioned whether that isn't making a bad situation
> worse in some cases).

> If you want the IOMMU back (at the price of re-opening the
> security issue described in XSA-36), you'd have to pass
> "iommu=amd-iommu-perdev-intremap" to the hypervisor.

Just for the record (the list), that should be iommu=no-amd-iommu-perdev-intremap

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 21:36:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 21: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 1U3Cei-0003Y2-DL; Wed, 06 Feb 2013 21:35:48 +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 1U3Ceg-0003Xf-Hq
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 21:35:46 +0000
Received: from [193.109.254.147:21896] by server-2.bemta-14.messagelabs.com id
	4E/27-16277-1BCC2115; Wed, 06 Feb 2013 21:35:45 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360186543!9458233!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjEwNDUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11156 invoked from network); 6 Feb 2013 21:35:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 21:35:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16LZZhI006303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 21:35:36 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
	r16LZYIF006437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 21:35: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
	r16LZYIU008011; Wed, 6 Feb 2013 15:35:34 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 13:35:34 -0800
Date: Wed, 6 Feb 2013 13:35:32 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20130206133532.694a86c0@mantra.us.oracle.com>
In-Reply-To: <20130206153910.GA23029@konrad-lan.dumpdata.com>
References: <20130130145529.3900dca1@mantra.us.oracle.com>
	<20130206153910.GA23029@konrad-lan.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH: remove code to map iomem from 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 Wed, 6 Feb 2013 10:39:13 -0500
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Wed, Jan 30, 2013 at 02:55:29PM -0800, Mukesh Rathor wrote:
> > It was decided during xen patch review that xen map the iomem
> > transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub
> > hypercall PHYSDEVOP_map_iomem.
> > 
> 
> Grrrr..
> 
> No Signed-off-by??

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>


BTW, thanks a lot konrad for managing this while xen patch is being
reviewed. It's a huge help for me and allows me to focus on xen side.
Appreciate much.

Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 06 21:36:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 06 Feb 2013 21: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 1U3Cei-0003Y2-DL; Wed, 06 Feb 2013 21:35:48 +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 1U3Ceg-0003Xf-Hq
	for Xen-devel@lists.xensource.com; Wed, 06 Feb 2013 21:35:46 +0000
Received: from [193.109.254.147:21896] by server-2.bemta-14.messagelabs.com id
	4E/27-16277-1BCC2115; Wed, 06 Feb 2013 21:35:45 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360186543!9458233!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjEwNDUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11156 invoked from network); 6 Feb 2013 21:35:44 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Feb 2013 21:35:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r16LZZhI006303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 6 Feb 2013 21:35:36 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
	r16LZYIF006437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 6 Feb 2013 21:35: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
	r16LZYIU008011; Wed, 6 Feb 2013 15:35:34 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 06 Feb 2013 13:35:34 -0800
Date: Wed, 6 Feb 2013 13:35:32 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20130206133532.694a86c0@mantra.us.oracle.com>
In-Reply-To: <20130206153910.GA23029@konrad-lan.dumpdata.com>
References: <20130130145529.3900dca1@mantra.us.oracle.com>
	<20130206153910.GA23029@konrad-lan.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] PVH: remove code to map iomem from 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 Wed, 6 Feb 2013 10:39:13 -0500
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Wed, Jan 30, 2013 at 02:55:29PM -0800, Mukesh Rathor wrote:
> > It was decided during xen patch review that xen map the iomem
> > transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub
> > hypercall PHYSDEVOP_map_iomem.
> > 
> 
> Grrrr..
> 
> No Signed-off-by??

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>


BTW, thanks a lot konrad for managing this while xen patch is being
reviewed. It's a huge help for me and allows me to focus on xen side.
Appreciate much.

Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 00:05:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 00:05: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 1U3Eyy-00089c-Dm; Thu, 07 Feb 2013 00:04: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 1U3Eyx-00089X-3H
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 00:04:51 +0000
Received: from [85.158.143.99:5963] by server-2.bemta-4.messagelabs.com id
	76/06-01597-2AFE2115; Thu, 07 Feb 2013 00:04:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360195489!23964984!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18960 invoked from network); 7 Feb 2013 00:04:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 00:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,618,1355097600"; 
   d="scan'208";a="1217252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 00:04: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.297.1; Thu, 7 Feb 2013 00:04:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3Eys-0000Zf-Vo;
	Thu, 07 Feb 2013 00:04:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3Eys-0002tU-Ne;
	Thu, 07 Feb 2013 00:04:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15440-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Feb 2013 00:04:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15440: 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 15440 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15440/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15430
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15430
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15430

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-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  6c1b12c884b4
baseline version:
 xen                  6c1b12c884b4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 07 00:05:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 00:05: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 1U3Eyy-00089c-Dm; Thu, 07 Feb 2013 00:04: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 1U3Eyx-00089X-3H
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 00:04:51 +0000
Received: from [85.158.143.99:5963] by server-2.bemta-4.messagelabs.com id
	76/06-01597-2AFE2115; Thu, 07 Feb 2013 00:04:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360195489!23964984!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18960 invoked from network); 7 Feb 2013 00:04:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 00:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,618,1355097600"; 
   d="scan'208";a="1217252"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 00:04: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.297.1; Thu, 7 Feb 2013 00:04:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3Eys-0000Zf-Vo;
	Thu, 07 Feb 2013 00:04:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3Eys-0002tU-Ne;
	Thu, 07 Feb 2013 00:04:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15440-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Feb 2013 00:04:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15440: 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 15440 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15440/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15430
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15430
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15430

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-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  6c1b12c884b4
baseline version:
 xen                  6c1b12c884b4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 07 00:55:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 00: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 1U3Flk-0001IR-Gf; Thu, 07 Feb 2013 00:55:16 +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 1U3Fli-0001IM-Gp
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 00:55:14 +0000
Received: from [85.158.143.35:46437] by server-2.bemta-4.messagelabs.com id
	AB/86-01597-17BF2115; Thu, 07 Feb 2013 00:55:13 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360198512!14378408!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28134 invoked from network); 7 Feb 2013 00:55:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 00:55:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; 
   d="scan'208";a="1217739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 00:55:12 +0000
Received: from [10.30.249.68] (10.30.249.68) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Thu, 7 Feb 2013
	00:55:12 +0000
Message-ID: <5112FB71.3050600@citrix.com>
Date: Thu, 7 Feb 2013 00:55:13 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/02/2013 20:37, M A Young wrote:
> Fedora rawhide has just moved onto gcc 4.8, and I have had to apply the 
> attached patch to get it to build (I constructed the patch against 4.2.1 
> but I believe it will apply to xen-unstable).
>
> There are two types of problem, the first is from 
> xen/common/compat/memory.c where the error is
>
> memory.c: In function 'compat_memory_op':
> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: 
> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally 
> defined but not used [-Werror=unused-local-typedefs]
>       typedef struct { type *p; } __guest_handle_ ## name
>                                   ^
> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: 
> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>       ^
> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: 
> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
> name)
>                                           ^
> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
>               ^
>
> so we are defining something that isn't used.

But it is used, by guest_handle_cast, albeit through several layers of
macros.

I would tentativly object to the use of "__attribute__((unused));" to
work around what appears to be a gcc bug.  If 4.8 support is desperately
wanted, then a better solution would be to specify
-Wno-unused-local-typedefs to disable the buggy feature.

~Andrew

>
> Secondly gcc 4.8 objects to lines like
>
> memset(ctxt, 0, sizeof(ctxt));
>
> where I think you are just zeroing a pointer's worth of memory. There are 
> a few cases of this in the xen code fixed in the patch, and I am also 
> suspicious of line 630 of 
> stubdom/grub-upstream/stage2/fsys_reiserfs.c which is
>
> memset (INFO->blocks, 0, sizeof (INFO->blocks));
>
> which is noted in the build log but not flagged as an error.
>
>  	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 Feb 07 00:55:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 00: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 1U3Flk-0001IR-Gf; Thu, 07 Feb 2013 00:55:16 +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 1U3Fli-0001IM-Gp
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 00:55:14 +0000
Received: from [85.158.143.35:46437] by server-2.bemta-4.messagelabs.com id
	AB/86-01597-17BF2115; Thu, 07 Feb 2013 00:55:13 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360198512!14378408!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28134 invoked from network); 7 Feb 2013 00:55:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 00:55:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; 
   d="scan'208";a="1217739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 00:55:12 +0000
Received: from [10.30.249.68] (10.30.249.68) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Thu, 7 Feb 2013
	00:55:12 +0000
Message-ID: <5112FB71.3050600@citrix.com>
Date: Thu, 7 Feb 2013 00:55:13 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: M A Young <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 06/02/2013 20:37, M A Young wrote:
> Fedora rawhide has just moved onto gcc 4.8, and I have had to apply the 
> attached patch to get it to build (I constructed the patch against 4.2.1 
> but I believe it will apply to xen-unstable).
>
> There are two types of problem, the first is from 
> xen/common/compat/memory.c where the error is
>
> memory.c: In function 'compat_memory_op':
> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: 
> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally 
> defined but not used [-Werror=unused-local-typedefs]
>       typedef struct { type *p; } __guest_handle_ ## name
>                                   ^
> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: 
> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>       ^
> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: 
> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
> name)
>                                           ^
> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
>               ^
>
> so we are defining something that isn't used.

But it is used, by guest_handle_cast, albeit through several layers of
macros.

I would tentativly object to the use of "__attribute__((unused));" to
work around what appears to be a gcc bug.  If 4.8 support is desperately
wanted, then a better solution would be to specify
-Wno-unused-local-typedefs to disable the buggy feature.

~Andrew

>
> Secondly gcc 4.8 objects to lines like
>
> memset(ctxt, 0, sizeof(ctxt));
>
> where I think you are just zeroing a pointer's worth of memory. There are 
> a few cases of this in the xen code fixed in the patch, and I am also 
> suspicious of line 630 of 
> stubdom/grub-upstream/stage2/fsys_reiserfs.c which is
>
> memset (INFO->blocks, 0, sizeof (INFO->blocks));
>
> which is noted in the build log but not flagged as an error.
>
>  	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 Feb 07 08:44:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 08:44: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 1U3N5j-00015L-Ef; Thu, 07 Feb 2013 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 <JBeulich@suse.com>) id 1U3N5i-00015F-OC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 08:44:22 +0000
Received: from [85.158.137.99:14000] by server-12.bemta-3.messagelabs.com id
	B1/B9-05889-56963115; Thu, 07 Feb 2013 08:44:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360226653!20345430!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23826 invoked from network); 7 Feb 2013 08:44:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 08:44:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 08:44:12 +0000
Message-Id: <5113776602000078000BCB8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 08:44:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
In-Reply-To: <511297F502000078000BC935@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> This adds two new physdev operations for Dom0 to invoke when resource
> allocation for devices is known to be complete, so that the hypervisor
> can arrange for the respective MMIO ranges to be marked read-only
> before an eventual guest getting such a device assigned even gets
> started, such that it won't be able to set up writable mappings for
> these MMIO ranges before Xen has a chance to protect them.

I should probably mention the alternatives:

1) Brute force scan of the (PV) guest's L1 page tables, locating
eventual mappings of the questionable MMIO pages, and
converting those mappings to R/O ones.

2) Snoop BAR modifications (via xen/arch/x86/traps.c:
guest_io_write(), taking note of which BAR(s) are relevant at the
point where the device gets first detected/reported), perhaps
along with snoops of the PCI_COMMAND_MEMORY bit.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 08:44:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 08:44: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 1U3N5j-00015L-Ef; Thu, 07 Feb 2013 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 <JBeulich@suse.com>) id 1U3N5i-00015F-OC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 08:44:22 +0000
Received: from [85.158.137.99:14000] by server-12.bemta-3.messagelabs.com id
	B1/B9-05889-56963115; Thu, 07 Feb 2013 08:44:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360226653!20345430!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23826 invoked from network); 7 Feb 2013 08:44:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 08:44:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 08:44:12 +0000
Message-Id: <5113776602000078000BCB8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 08:44:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
In-Reply-To: <511297F502000078000BC935@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> This adds two new physdev operations for Dom0 to invoke when resource
> allocation for devices is known to be complete, so that the hypervisor
> can arrange for the respective MMIO ranges to be marked read-only
> before an eventual guest getting such a device assigned even gets
> started, such that it won't be able to set up writable mappings for
> these MMIO ranges before Xen has a chance to protect them.

I should probably mention the alternatives:

1) Brute force scan of the (PV) guest's L1 page tables, locating
eventual mappings of the questionable MMIO pages, and
converting those mappings to R/O ones.

2) Snoop BAR modifications (via xen/arch/x86/traps.c:
guest_io_write(), taking note of which BAR(s) are relevant at the
point where the device gets first detected/reported), perhaps
along with snoops of the PCI_COMMAND_MEMORY bit.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:00:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NL6-0001Yi-8v; Thu, 07 Feb 2013 09:00:16 +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 1U3NL4-0001Yd-Ob
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:00:14 +0000
Received: from [85.158.137.99:40058] by server-11.bemta-3.messagelabs.com id
	3B/93-10249-81D63115; Thu, 07 Feb 2013 09:00:08 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360227606!15597942!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2807 invoked from network); 7 Feb 2013 09:00:07 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 09:00:07 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r178xrPP005434;
	Thu, 7 Feb 2013 08:59:57 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r178xoFL023463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 08:59:50 GMT
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 r178xoDN023782;
	Thu, 7 Feb 2013 08:59:50 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	r178xn3W023779; Thu, 7 Feb 2013 08:59:49 GMT
Date: Thu, 7 Feb 2013 08:59:49 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <5112FB71.3050600@citrix.com>
Message-ID: <alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.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: r178xrPP005434
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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, 7 Feb 2013, Andrew Cooper wrote:

> On 06/02/2013 20:37, M A Young wrote:
>
>> There are two types of problem, the first is from
>> xen/common/compat/memory.c where the error is
>>
>> memory.c: In function 'compat_memory_op':
>> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33:
>> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally
>> defined but not used [-Werror=unused-local-typedefs]
>>       typedef struct { type *p; } __guest_handle_ ## name
>>                                   ^
>> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5:
>> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
>>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>>       ^
>> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41:
>> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
>>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name,
>> name)
>>                                           ^
>> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
>>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
>>               ^
>>
>> so we are defining something that isn't used.
>
> But it is used, by guest_handle_cast, albeit through several layers of
> macros.
>
> I would tentativly object to the use of "__attribute__((unused));" to
> work around what appears to be a gcc bug.  If 4.8 support is desperately
> wanted, then a better solution would be to specify
> -Wno-unused-local-typedefs to disable the buggy feature.

It looked to me as if the DEFINE macro does two typedefs and the code only 
uses the first, so gcc 4.8 was correct in its objections. The suggested 
workaround of using -Wno-unused-local-typedefs isn't very portible as 
earlier versions of gcc don't recognize it.

 	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 Feb 07 09:00:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NL6-0001Yi-8v; Thu, 07 Feb 2013 09:00:16 +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 1U3NL4-0001Yd-Ob
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:00:14 +0000
Received: from [85.158.137.99:40058] by server-11.bemta-3.messagelabs.com id
	3B/93-10249-81D63115; Thu, 07 Feb 2013 09:00:08 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360227606!15597942!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2807 invoked from network); 7 Feb 2013 09:00:07 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 09:00:07 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r178xrPP005434;
	Thu, 7 Feb 2013 08:59:57 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r178xoFL023463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 08:59:50 GMT
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 r178xoDN023782;
	Thu, 7 Feb 2013 08:59:50 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	r178xn3W023779; Thu, 7 Feb 2013 08:59:49 GMT
Date: Thu, 7 Feb 2013 08:59:49 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <5112FB71.3050600@citrix.com>
Message-ID: <alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.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: r178xrPP005434
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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, 7 Feb 2013, Andrew Cooper wrote:

> On 06/02/2013 20:37, M A Young wrote:
>
>> There are two types of problem, the first is from
>> xen/common/compat/memory.c where the error is
>>
>> memory.c: In function 'compat_memory_op':
>> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33:
>> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally
>> defined but not used [-Werror=unused-local-typedefs]
>>       typedef struct { type *p; } __guest_handle_ ## name
>>                                   ^
>> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5:
>> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
>>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>>       ^
>> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41:
>> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
>>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name,
>> name)
>>                                           ^
>> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
>>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
>>               ^
>>
>> so we are defining something that isn't used.
>
> But it is used, by guest_handle_cast, albeit through several layers of
> macros.
>
> I would tentativly object to the use of "__attribute__((unused));" to
> work around what appears to be a gcc bug.  If 4.8 support is desperately
> wanted, then a better solution would be to specify
> -Wno-unused-local-typedefs to disable the buggy feature.

It looked to me as if the DEFINE macro does two typedefs and the code only 
uses the first, so gcc 4.8 was correct in its objections. The suggested 
workaround of using -Wno-unused-local-typedefs isn't very portible as 
earlier versions of gcc don't recognize it.

 	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 Feb 07 09:01:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NLd-0001a4-MV; Thu, 07 Feb 2013 09:00:49 +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 1U3NLd-0001Zx-4f
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:00:49 +0000
Received: from [85.158.139.83:33153] by server-13.bemta-5.messagelabs.com id
	9A/23-06769-04D63115; Thu, 07 Feb 2013 09:00:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360227644!31260651!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29577 invoked from network); 7 Feb 2013 09:00:44 -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; 7 Feb 2013 09:00:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 09:00:44 +0000
Message-Id: <51137B4A02000078000BCB9F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 09:00:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <511299A902000078000BC944@nat28.tlf.novell.com>
	<20130206171254.GE24458@konrad-lan.dumpdata.com>
In-Reply-To: <20130206171254.GE24458@konrad-lan.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: notify hypervisor about
 devices intended to be assigned to 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 06.02.13 at 18:12, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
>> +		struct physdev_pci_device ppdev = {
>> +			.seg = pci_domain_nr(dev->bus),
>> +			.bus = dev->bus->number,
>> +			.devfn = dev->devfn
>> +		};
>> +		int err = HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
>> +						&ppdev);
>> +
>> +		if (err)
>> +			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
>> +				 err);
>> +	}
> 
> Perhaps it should be more off:
> 
> 		if (err) {
> 			if (err == -ENOSYS)
> 				dev_info(&dev->dev,"MSI-X release
> hypercall not supported.");
> 			else
> 				dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
> 					 err);
> 				

Why would you want to special case this? The more that _really_
old hypervisors returned -EINVAL instead of -ENOSYS here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:01:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NLd-0001a4-MV; Thu, 07 Feb 2013 09:00:49 +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 1U3NLd-0001Zx-4f
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:00:49 +0000
Received: from [85.158.139.83:33153] by server-13.bemta-5.messagelabs.com id
	9A/23-06769-04D63115; Thu, 07 Feb 2013 09:00:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360227644!31260651!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29577 invoked from network); 7 Feb 2013 09:00:44 -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; 7 Feb 2013 09:00:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 09:00:44 +0000
Message-Id: <51137B4A02000078000BCB9F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 09:00:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <511299A902000078000BC944@nat28.tlf.novell.com>
	<20130206171254.GE24458@konrad-lan.dumpdata.com>
In-Reply-To: <20130206171254.GE24458@konrad-lan.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: notify hypervisor about
 devices intended to be assigned to 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 06.02.13 at 18:12, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> +	if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
>> +		struct physdev_pci_device ppdev = {
>> +			.seg = pci_domain_nr(dev->bus),
>> +			.bus = dev->bus->number,
>> +			.devfn = dev->devfn
>> +		};
>> +		int err = HYPERVISOR_physdev_op(PHYSDEVOP_release_msix,
>> +						&ppdev);
>> +
>> +		if (err)
>> +			dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
>> +				 err);
>> +	}
> 
> Perhaps it should be more off:
> 
> 		if (err) {
> 			if (err == -ENOSYS)
> 				dev_info(&dev->dev,"MSI-X release
> hypercall not supported.");
> 			else
> 				dev_warn(&dev->dev, "MSI-X release failed (%d)\n",
> 					 err);
> 				

Why would you want to special case this? The more that _really_
old hypervisors returned -EINVAL instead of -ENOSYS here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:08:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:08: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 1U3NSk-00025Y-Ln; Thu, 07 Feb 2013 09:08:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3NSj-00025T-C6
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:08:09 +0000
Received: from [85.158.139.211:14768] by server-2.bemta-5.messagelabs.com id
	BD/AF-16911-8FE63115; Thu, 07 Feb 2013 09:08:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360228087!21318736!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4040 invoked from network); 7 Feb 2013 09:08:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1226886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:08:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 7 Feb 2013
	09:08:07 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Thu, 7 Feb 2013 09:08:07 +0000
Thread-Topic: [Xen-devel] Compile errors with gcc 4.8
Thread-Index: Ac4FEqUQlLSgaU2XQweG75CKMXo5+g==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836F@LONPMAILBOX01.citrite.net>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
In-Reply-To: <5112FB71.3050600@citrix.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>,
	"m.a.young@durham.ac.uk" <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 00:55 +0000, Andrew Cooper wrote:
> On 06/02/2013 20:37, M A Young wrote:
> > Fedora rawhide has just moved onto gcc 4.8, and I have had to apply the 
> > attached patch to get it to build (I constructed the patch against 4.2.1 
> > but I believe it will apply to xen-unstable).
> >
> > There are two types of problem, the first is from 
> > xen/common/compat/memory.c where the error is
> >
> > memory.c: In function 'compat_memory_op':
> > /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: 
> > error: typedef '__guest_handle_const_compat_memory_exchange_t' locally 
> > defined but not used [-Werror=unused-local-typedefs]
> >       typedef struct { type *p; } __guest_handle_ ## name
> >                                   ^
> > /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: 
> > note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
> >       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> >       ^
> > /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: 
> > note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
> >   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
> > name)
> >                                           ^
> > memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
> >               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
> >               ^
> >
> > so we are defining something that isn't used.
> 
> But it is used, by guest_handle_cast, albeit through several layers of
> macros.
> 
> I would tentativly object to the use of "__attribute__((unused));" to
> work around what appears to be a gcc bug.  If 4.8 support is desperately
> wanted, then a better solution would be to specify
> -Wno-unused-local-typedefs to disable the buggy feature.
> 

A workaround would be to put the defined outside the function. At the
end it's just a typedef.

> ~Andrew
> 
> >
> > Secondly gcc 4.8 objects to lines like
> >
> > memset(ctxt, 0, sizeof(ctxt));
> >
> > where I think you are just zeroing a pointer's worth of memory. There are 
> > a few cases of this in the xen code fixed in the patch, and I am also 
> > suspicious of line 630 of 
> > stubdom/grub-upstream/stage2/fsys_reiserfs.c which is
> >
> > memset (INFO->blocks, 0, sizeof (INFO->blocks));
> >
> > which is noted in the build log but not flagged as an error.
> >
> >  	Michael Young
> 

This seems real problems even to me. The md5 code is know and wrong to
me for sure.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:08:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:08: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 1U3NSk-00025Y-Ln; Thu, 07 Feb 2013 09:08:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3NSj-00025T-C6
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:08:09 +0000
Received: from [85.158.139.211:14768] by server-2.bemta-5.messagelabs.com id
	BD/AF-16911-8FE63115; Thu, 07 Feb 2013 09:08:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360228087!21318736!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4040 invoked from network); 7 Feb 2013 09:08:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:08:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1226886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:08:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 7 Feb 2013
	09:08:07 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Thu, 7 Feb 2013 09:08:07 +0000
Thread-Topic: [Xen-devel] Compile errors with gcc 4.8
Thread-Index: Ac4FEqUQlLSgaU2XQweG75CKMXo5+g==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45836F@LONPMAILBOX01.citrite.net>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
In-Reply-To: <5112FB71.3050600@citrix.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>,
	"m.a.young@durham.ac.uk" <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 00:55 +0000, Andrew Cooper wrote:
> On 06/02/2013 20:37, M A Young wrote:
> > Fedora rawhide has just moved onto gcc 4.8, and I have had to apply the 
> > attached patch to get it to build (I constructed the patch against 4.2.1 
> > but I believe it will apply to xen-unstable).
> >
> > There are two types of problem, the first is from 
> > xen/common/compat/memory.c where the error is
> >
> > memory.c: In function 'compat_memory_op':
> > /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: 
> > error: typedef '__guest_handle_const_compat_memory_exchange_t' locally 
> > defined but not used [-Werror=unused-local-typedefs]
> >       typedef struct { type *p; } __guest_handle_ ## name
> >                                   ^
> > /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: 
> > note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
> >       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> >       ^
> > /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: 
> > note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
> >   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
> > name)
> >                                           ^
> > memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
> >               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
> >               ^
> >
> > so we are defining something that isn't used.
> 
> But it is used, by guest_handle_cast, albeit through several layers of
> macros.
> 
> I would tentativly object to the use of "__attribute__((unused));" to
> work around what appears to be a gcc bug.  If 4.8 support is desperately
> wanted, then a better solution would be to specify
> -Wno-unused-local-typedefs to disable the buggy feature.
> 

A workaround would be to put the defined outside the function. At the
end it's just a typedef.

> ~Andrew
> 
> >
> > Secondly gcc 4.8 objects to lines like
> >
> > memset(ctxt, 0, sizeof(ctxt));
> >
> > where I think you are just zeroing a pointer's worth of memory. There are 
> > a few cases of this in the xen code fixed in the patch, and I am also 
> > suspicious of line 630 of 
> > stubdom/grub-upstream/stage2/fsys_reiserfs.c which is
> >
> > memset (INFO->blocks, 0, sizeof (INFO->blocks));
> >
> > which is noted in the build log but not flagged as an error.
> >
> >  	Michael Young
> 

This seems real problems even to me. The md5 code is know and wrong to
me for sure.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:08:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NSs-00026P-7w; Thu, 07 Feb 2013 09:08:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3NSq-00026F-Q8
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:08:16 +0000
Received: from [85.158.139.83:14358] by server-4.bemta-5.messagelabs.com id
	4F/D3-29496-FFE63115; Thu, 07 Feb 2013 09:08:15 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360228083!23908818!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25765 invoked from network); 7 Feb 2013 09:08:04 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-182.messagelabs.com with SMTP;
	7 Feb 2013 09:08:04 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 80419C56196;
	Thu,  7 Feb 2013 09:07:49 +0000 (GMT)
Date: Thu, 07 Feb 2013 09:07:51 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Message-ID: <838785E507D0C1ACD6B8781E@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Question re live migrate on Xen 4.2 re different cpu
	capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

We've run into an issue on live migrate on Xen 4.2. We've mainly tested HVM 
on qemu-upstream DM with my live migrate patches in, but it seems to apply 
in any HVM live migrate.

What we see is under certain circumstances a linux guest booted on machine 
A will live-migrate to machine B and back again, but a linux guest booted 
on machine B will not live migrate to machine A - it hangs after the 
migration.

Tracking this down to different pairs of machines A and B, the difference 
seems to be down to different CPU capabilities. In particular, if B has 
identical CPU flags to A except that B supports xsave, the above seems to 
happen reliably. I presume what may be happening is that the guest notes 
and uses the presence of xsave on boot, and becomes unhappy when the 
recipient machine does not have it.

KVM with default settings does not suffer from this issue. I presume it is 
presenting by default a masked set of CPU capabilities.

Is there any way to do similarly in Xen? Or is Xen live migrate effectively 
restricted to live migrate between identical CPUs?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:08:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NSs-00026P-7w; Thu, 07 Feb 2013 09:08:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3NSq-00026F-Q8
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:08:16 +0000
Received: from [85.158.139.83:14358] by server-4.bemta-5.messagelabs.com id
	4F/D3-29496-FFE63115; Thu, 07 Feb 2013 09:08:15 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360228083!23908818!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25765 invoked from network); 7 Feb 2013 09:08:04 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-182.messagelabs.com with SMTP;
	7 Feb 2013 09:08:04 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 80419C56196;
	Thu,  7 Feb 2013 09:07:49 +0000 (GMT)
Date: Thu, 07 Feb 2013 09:07:51 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Message-ID: <838785E507D0C1ACD6B8781E@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Question re live migrate on Xen 4.2 re different cpu
	capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

We've run into an issue on live migrate on Xen 4.2. We've mainly tested HVM 
on qemu-upstream DM with my live migrate patches in, but it seems to apply 
in any HVM live migrate.

What we see is under certain circumstances a linux guest booted on machine 
A will live-migrate to machine B and back again, but a linux guest booted 
on machine B will not live migrate to machine A - it hangs after the 
migration.

Tracking this down to different pairs of machines A and B, the difference 
seems to be down to different CPU capabilities. In particular, if B has 
identical CPU flags to A except that B supports xsave, the above seems to 
happen reliably. I presume what may be happening is that the guest notes 
and uses the presence of xsave on boot, and becomes unhappy when the 
recipient machine does not have it.

KVM with default settings does not suffer from this issue. I presume it is 
presenting by default a masked set of CPU capabilities.

Is there any way to do similarly in Xen? Or is Xen live migrate effectively 
restricted to live migrate between identical CPUs?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:08:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NSw-000272-LD; Thu, 07 Feb 2013 09:08:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3NSv-00026l-DM
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:08:21 +0000
Received: from [193.109.254.147:39866] by server-9.bemta-14.messagelabs.com id
	F9/A4-30867-40F63115; Thu, 07 Feb 2013 09:08:20 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360228097!9843567!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9635 invoked from network); 7 Feb 2013 09:08:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-27.messagelabs.com with SMTP;
	7 Feb 2013 09:08:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id BE27FC56196;
	Thu,  7 Feb 2013 09:08:16 +0000 (GMT)
Date: Thu, 07 Feb 2013 09:08:19 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Message-ID: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Question re live migrate on Xen 4.2 re different cpu
	capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

We've run into an issue on live migrate on Xen 4.2. We've mainly tested HVM 
on qemu-upstream DM with my live migrate patches in, but it seems to apply 
in any HVM live migrate.

What we see is under certain circumstances a linux guest booted on machine 
A will live-migrate to machine B and back again, but a linux guest booted 
on machine B will not live migrate to machine A - it hangs after the 
migration.

Tracking this down to different pairs of machines A and B, the difference 
seems to be down to different CPU capabilities. In particular, if B has 
identical CPU flags to A except that B supports xsave, the above seems to 
happen reliably. I presume what may be happening is that the guest notes 
and uses the presence of xsave on boot, and becomes unhappy when the 
recipient machine does not have it.

KVM with default settings does not suffer from this issue. I presume it is 
presenting by default a masked set of CPU capabilities.

Is there any way to do similarly in Xen? Or is Xen live migrate effectively 
restricted to live migrate between identical CPUs?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:08:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NSw-000272-LD; Thu, 07 Feb 2013 09:08:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3NSv-00026l-DM
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:08:21 +0000
Received: from [193.109.254.147:39866] by server-9.bemta-14.messagelabs.com id
	F9/A4-30867-40F63115; Thu, 07 Feb 2013 09:08:20 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360228097!9843567!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9635 invoked from network); 7 Feb 2013 09:08:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-27.messagelabs.com with SMTP;
	7 Feb 2013 09:08:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id BE27FC56196;
	Thu,  7 Feb 2013 09:08:16 +0000 (GMT)
Date: Thu, 07 Feb 2013 09:08:19 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Message-ID: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Question re live migrate on Xen 4.2 re different cpu
	capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

We've run into an issue on live migrate on Xen 4.2. We've mainly tested HVM 
on qemu-upstream DM with my live migrate patches in, but it seems to apply 
in any HVM live migrate.

What we see is under certain circumstances a linux guest booted on machine 
A will live-migrate to machine B and back again, but a linux guest booted 
on machine B will not live migrate to machine A - it hangs after the 
migration.

Tracking this down to different pairs of machines A and B, the difference 
seems to be down to different CPU capabilities. In particular, if B has 
identical CPU flags to A except that B supports xsave, the above seems to 
happen reliably. I presume what may be happening is that the guest notes 
and uses the presence of xsave on boot, and becomes unhappy when the 
recipient machine does not have it.

KVM with default settings does not suffer from this issue. I presume it is 
presenting by default a masked set of CPU capabilities.

Is there any way to do similarly in Xen? Or is Xen live migrate effectively 
restricted to live migrate between identical CPUs?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:09:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:09: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 1U3NU9-0002JL-4P; Thu, 07 Feb 2013 09:09: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 1U3NU7-0002J0-GN
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:09:35 +0000
Received: from [193.109.254.147:48830] by server-9.bemta-14.messagelabs.com id
	A6/66-30867-E4F63115; Thu, 07 Feb 2013 09:09:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360227999!8569160!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4588 invoked from network); 7 Feb 2013 09:06:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:06:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1226815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:06: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.297.1; Thu, 7 Feb 2013
	09:06:39 +0000
Message-ID: <1360227997.32479.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Thu, 7 Feb 2013 09:06:37 +0000
In-Reply-To: <alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
	<alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 08:59 +0000, M A Young wrote:
> On Thu, 7 Feb 2013, Andrew Cooper wrote:
> 
> > On 06/02/2013 20:37, M A Young wrote:
> >
> >> There are two types of problem, the first is from
> >> xen/common/compat/memory.c where the error is
> >>
> >> memory.c: In function 'compat_memory_op':
> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33:
> >> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally
> >> defined but not used [-Werror=unused-local-typedefs]
> >>       typedef struct { type *p; } __guest_handle_ ## name
> >>                                   ^
> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5:
> >> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
> >>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> >>       ^
> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41:
> >> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
> >>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name,
> >> name)
> >>                                           ^
> >> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
> >>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
> >>               ^
> >>
> >> so we are defining something that isn't used.
> >
> > But it is used, by guest_handle_cast, albeit through several layers of
> > macros.
> >
> > I would tentativly object to the use of "__attribute__((unused));" to
> > work around what appears to be a gcc bug.  If 4.8 support is desperately
> > wanted, then a better solution would be to specify
> > -Wno-unused-local-typedefs to disable the buggy feature.
> 
> It looked to me as if the DEFINE macro does two typedefs and the code only 
> uses the first, so gcc 4.8 was correct in its objections. The suggested 
> workaround of using -Wno-unused-local-typedefs isn't very portible as 
> earlier versions of gcc don't recognize it.

We have a cc-option macro in the makefiles to enable these sorts of
options to be enabled conditionally.

However it seems a bit odd to be using DEFINE_XEN_GUEST_HANDLE in this
manner, should it not be declared in some header? I can see a
DEFINE_COMPAT_HANDLE(compat_memory_exchange_t) in
xen/include/compat/memory.h. Perhaps the one in memory.c can just be
dropped or otherwise modified to use this?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:09:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:09: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 1U3NU9-0002JL-4P; Thu, 07 Feb 2013 09:09: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 1U3NU7-0002J0-GN
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:09:35 +0000
Received: from [193.109.254.147:48830] by server-9.bemta-14.messagelabs.com id
	A6/66-30867-E4F63115; Thu, 07 Feb 2013 09:09:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360227999!8569160!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxMzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4588 invoked from network); 7 Feb 2013 09:06:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:06:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1226815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:06: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.297.1; Thu, 7 Feb 2013
	09:06:39 +0000
Message-ID: <1360227997.32479.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Date: Thu, 7 Feb 2013 09:06:37 +0000
In-Reply-To: <alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
	<alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 08:59 +0000, M A Young wrote:
> On Thu, 7 Feb 2013, Andrew Cooper wrote:
> 
> > On 06/02/2013 20:37, M A Young wrote:
> >
> >> There are two types of problem, the first is from
> >> xen/common/compat/memory.c where the error is
> >>
> >> memory.c: In function 'compat_memory_op':
> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33:
> >> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally
> >> defined but not used [-Werror=unused-local-typedefs]
> >>       typedef struct { type *p; } __guest_handle_ ## name
> >>                                   ^
> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5:
> >> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
> >>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> >>       ^
> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41:
> >> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
> >>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name,
> >> name)
> >>                                           ^
> >> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
> >>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
> >>               ^
> >>
> >> so we are defining something that isn't used.
> >
> > But it is used, by guest_handle_cast, albeit through several layers of
> > macros.
> >
> > I would tentativly object to the use of "__attribute__((unused));" to
> > work around what appears to be a gcc bug.  If 4.8 support is desperately
> > wanted, then a better solution would be to specify
> > -Wno-unused-local-typedefs to disable the buggy feature.
> 
> It looked to me as if the DEFINE macro does two typedefs and the code only 
> uses the first, so gcc 4.8 was correct in its objections. The suggested 
> workaround of using -Wno-unused-local-typedefs isn't very portible as 
> earlier versions of gcc don't recognize it.

We have a cc-option macro in the makefiles to enable these sorts of
options to be enabled conditionally.

However it seems a bit odd to be using DEFINE_XEN_GUEST_HANDLE in this
manner, should it not be declared in some header? I can see a
DEFINE_COMPAT_HANDLE(compat_memory_exchange_t) in
xen/include/compat/memory.h. Perhaps the one in memory.c can just be
dropped or otherwise modified to use this?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:09:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NUC-0002Jz-Gw; Thu, 07 Feb 2013 09:09:40 +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 1U3NUB-0002Ji-6W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:09:39 +0000
Received: from [85.158.143.35:55800] by server-3.bemta-4.messagelabs.com id
	1B/90-08920-25F63115; Thu, 07 Feb 2013 09:09:38 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360228071!11419454!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15196 invoked from network); 7 Feb 2013 09:07:52 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 09:07:52 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1797fDv007564;
	Thu, 7 Feb 2013 09:07:45 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1797bXm025169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 09:07:37 GMT
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 r1797baY023818;
	Thu, 7 Feb 2013 09:07:37 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	r1797bUn023815; Thu, 7 Feb 2013 09:07:37 GMT
Date: Thu, 7 Feb 2013 09:07:37 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
Message-ID: <alpine.GSO.2.00.1302070903310.23718@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
	<alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
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: r1797fDv007564
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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, 7 Feb 2013, M A Young wrote:

> It looked to me as if the DEFINE macro does two typedefs and the code only 
> uses the first, so gcc 4.8 was correct in its objections. The suggested 
> workaround of using -Wno-unused-local-typedefs isn't very portible as earlier 
> versions of gcc don't recognize it.

Actually, I could be wrong about -Wno-unused-local-typedefs as I think I 
am confusing it with the flag to ignore the other error which I attempted 
to use while tracing the occurrences for that problem.

 	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 Feb 07 09:09:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NUC-0002Jz-Gw; Thu, 07 Feb 2013 09:09:40 +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 1U3NUB-0002Ji-6W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:09:39 +0000
Received: from [85.158.143.35:55800] by server-3.bemta-4.messagelabs.com id
	1B/90-08920-25F63115; Thu, 07 Feb 2013 09:09:38 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360228071!11419454!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15196 invoked from network); 7 Feb 2013 09:07:52 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 09:07:52 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1797fDv007564;
	Thu, 7 Feb 2013 09:07:45 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1797bXm025169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 09:07:37 GMT
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 r1797baY023818;
	Thu, 7 Feb 2013 09:07:37 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	r1797bUn023815; Thu, 7 Feb 2013 09:07:37 GMT
Date: Thu, 7 Feb 2013 09:07:37 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
Message-ID: <alpine.GSO.2.00.1302070903310.23718@algedi.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
	<alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
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: r1797fDv007564
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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, 7 Feb 2013, M A Young wrote:

> It looked to me as if the DEFINE macro does two typedefs and the code only 
> uses the first, so gcc 4.8 was correct in its objections. The suggested 
> workaround of using -Wno-unused-local-typedefs isn't very portible as earlier 
> versions of gcc don't recognize it.

Actually, I could be wrong about -Wno-unused-local-typedefs as I think I 
am confusing it with the flag to ignore the other error which I attempted 
to use while tracing the occurrences for that problem.

 	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 Feb 07 09:19:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:19: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 1U3NdP-0003Gr-Fh; Thu, 07 Feb 2013 09:19:11 +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 1U3NdO-0003Gj-0e
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:19:10 +0000
Received: from [85.158.137.99:17654] by server-11.bemta-3.messagelabs.com id
	C0/4F-10249-D8173115; Thu, 07 Feb 2013 09:19:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360228748!15668677!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19436 invoked from network); 7 Feb 2013 09:19:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 09:19:08 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiy0MFtHG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-075-254.pools.arcor-ip.net [88.65.75.254])
	by smtp.strato.de (jorabe mo19) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C07590p179CAvP ;
	Thu, 7 Feb 2013 10:19:08 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0D1CD1884C; Thu,  7 Feb 2013 10:19:07 +0100 (CET)
Date: Thu, 7 Feb 2013 10:19:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130207091907.GA5540@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 07, Alex Bligh wrote:

> Is there any way to do similarly in Xen? Or is Xen live migrate effectively
> restricted to live migrate between identical CPUs?

Its mentionend somewhere in the docs that both cpus must be sufficient
compatible. Use the cpuid= setting in the domU config file to enforce
this.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:19:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:19: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 1U3NdP-0003Gr-Fh; Thu, 07 Feb 2013 09:19:11 +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 1U3NdO-0003Gj-0e
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:19:10 +0000
Received: from [85.158.137.99:17654] by server-11.bemta-3.messagelabs.com id
	C0/4F-10249-D8173115; Thu, 07 Feb 2013 09:19:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360228748!15668677!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19436 invoked from network); 7 Feb 2013 09:19:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 09:19:08 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiy0MFtHG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-075-254.pools.arcor-ip.net [88.65.75.254])
	by smtp.strato.de (jorabe mo19) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C07590p179CAvP ;
	Thu, 7 Feb 2013 10:19:08 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0D1CD1884C; Thu,  7 Feb 2013 10:19:07 +0100 (CET)
Date: Thu, 7 Feb 2013 10:19:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130207091907.GA5540@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 07, Alex Bligh wrote:

> Is there any way to do similarly in Xen? Or is Xen live migrate effectively
> restricted to live migrate between identical CPUs?

Its mentionend somewhere in the docs that both cpus must be sufficient
compatible. Use the cpuid= setting in the domU config file to enforce
this.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:24:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:24: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 1U3Nhs-0003eO-5e; Thu, 07 Feb 2013 09:23:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3Nhq-0003eI-Ae
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:23:46 +0000
Received: from [193.109.254.147:16894] by server-4.bemta-14.messagelabs.com id
	7D/E0-20719-1A273115; Thu, 07 Feb 2013 09:23:45 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360228964!1715849!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24382 invoked from network); 7 Feb 2013 09:22:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1227395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:21:43 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 7 Feb 2013
	09:21:42 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Wei Liu
	<wei.liu2@citrix.com>
Date: Thu, 7 Feb 2013 09:22:21 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4Ei0B4u60t+yMpT2idU58kaVNIvAAiPteQ
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
In-Reply-To: <20130206165709.GC24458@konrad-lan.dumpdata.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>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
[snip]
> > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > sizeof(unsigned long) * 64)
> > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > +sizeof(unsigned long) * 64)
> > >
> > > We did a bit of header change to make the ARM code always use
> > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> xen_mfn_t typdefs.
> > >
> > > Any chance you can do that here? That way on ARM - irregardless if
> > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > >
> >
> > I don't think so. The reason to use unsigned long here is to guarantee
> > each selector (in 2-level case there is only L1 selector) fits into a
> > word.
> 

That's still going to be a problem with Windows drivers. Unfortunately MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is word size is a pointer. Any chance we can use uintptr_t rather than an unsigned long? (At the moment I have to sed all the public headers to replace long with LONG_PTR and it's a PITA).

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:24:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:24: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 1U3Nhs-0003eO-5e; Thu, 07 Feb 2013 09:23:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3Nhq-0003eI-Ae
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:23:46 +0000
Received: from [193.109.254.147:16894] by server-4.bemta-14.messagelabs.com id
	7D/E0-20719-1A273115; Thu, 07 Feb 2013 09:23:45 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360228964!1715849!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24382 invoked from network); 7 Feb 2013 09:22:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:22:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1227395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:21:43 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 7 Feb 2013
	09:21:42 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Wei Liu
	<wei.liu2@citrix.com>
Date: Thu, 7 Feb 2013 09:22:21 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4Ei0B4u60t+yMpT2idU58kaVNIvAAiPteQ
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
In-Reply-To: <20130206165709.GC24458@konrad-lan.dumpdata.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>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
[snip]
> > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > sizeof(unsigned long) * 64)
> > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > +sizeof(unsigned long) * 64)
> > >
> > > We did a bit of header change to make the ARM code always use
> > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> xen_mfn_t typdefs.
> > >
> > > Any chance you can do that here? That way on ARM - irregardless if
> > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > >
> >
> > I don't think so. The reason to use unsigned long here is to guarantee
> > each selector (in 2-level case there is only L1 selector) fits into a
> > word.
> 

That's still going to be a problem with Windows drivers. Unfortunately MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is word size is a pointer. Any chance we can use uintptr_t rather than an unsigned long? (At the moment I have to sed all the public headers to replace long with LONG_PTR and it's a PITA).

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:40:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NyF-0004Bj-TC; Thu, 07 Feb 2013 09:40:43 +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 1U3NyE-0004Be-Pt
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:40:42 +0000
Received: from [85.158.137.99:25578] by server-9.bemta-3.messagelabs.com id
	0B/B8-09484-59673115; Thu, 07 Feb 2013 09:40:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360230010!20356619!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11163 invoked from network); 7 Feb 2013 09:40:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1228224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:40: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.297.1; Thu, 7 Feb 2013
	09:40:09 +0000
Message-ID: <1360230008.32479.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Thu, 7 Feb 2013 09:40:08 +0000
In-Reply-To: <20130206.134737.967342633025530520.davem@davemloft.net>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
	<1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
	<87ehgtgxhv.fsf@blp.benpfaff.org>
	<20130206.134737.967342633025530520.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"blp@cs.stanford.edu" <blp@cs.stanford.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated
 memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 18:47 +0000, David Miller wrote:
> From: Ben Pfaff <blp@cs.stanford.edu>
> Date: Wed, 06 Feb 2013 09:31:24 -0800
> 
> > Ian Campbell <ian.campbell@citrix.com> writes:
> > 
> >> +	/*
> >> +	 * Unwind, freeing all pages and sending error
> >> +	 * reponses.
> >> +	 */
> > 
> > s/reponses/responses/

Fixed, thanks!

> Also please format your comments in the standard networking form
> which is:
> 
> 	/* Like
> 	 * this.
> 	 */
> 
> Patch #1 has the same problem, thanks Ian.

I fixed this up, actually this particular one fits on a single line just
fine.

I'll resend shortly with the addition of the stable cc which I forgot
last 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 Thu Feb 07 09:40:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3NyF-0004Bj-TC; Thu, 07 Feb 2013 09:40:43 +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 1U3NyE-0004Be-Pt
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:40:42 +0000
Received: from [85.158.137.99:25578] by server-9.bemta-3.messagelabs.com id
	0B/B8-09484-59673115; Thu, 07 Feb 2013 09:40:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360230010!20356619!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11163 invoked from network); 7 Feb 2013 09:40:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1228224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:40: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.297.1; Thu, 7 Feb 2013
	09:40:09 +0000
Message-ID: <1360230008.32479.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Thu, 7 Feb 2013 09:40:08 +0000
In-Reply-To: <20130206.134737.967342633025530520.davem@davemloft.net>
References: <1360171081.32479.20.camel@zakaz.uk.xensource.com>
	<1360171098-1240-3-git-send-email-ian.campbell@citrix.com>
	<87ehgtgxhv.fsf@blp.benpfaff.org>
	<20130206.134737.967342633025530520.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"blp@cs.stanford.edu" <blp@cs.stanford.edu>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/netback: free already allocated
 memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 18:47 +0000, David Miller wrote:
> From: Ben Pfaff <blp@cs.stanford.edu>
> Date: Wed, 06 Feb 2013 09:31:24 -0800
> 
> > Ian Campbell <ian.campbell@citrix.com> writes:
> > 
> >> +	/*
> >> +	 * Unwind, freeing all pages and sending error
> >> +	 * reponses.
> >> +	 */
> > 
> > s/reponses/responses/

Fixed, thanks!

> Also please format your comments in the standard networking form
> which is:
> 
> 	/* Like
> 	 * this.
> 	 */
> 
> Patch #1 has the same problem, thanks Ian.

I fixed this up, actually this particular one fits on a single line just
fine.

I'll resend shortly with the addition of the stable cc which I forgot
last 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 Thu Feb 07 09:41:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:41: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 1U3Nyw-0004RW-Bb; Thu, 07 Feb 2013 09:41: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 1U3Nyu-0004RB-Ue
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:41:25 +0000
Received: from [85.158.139.83:61552] by server-13.bemta-5.messagelabs.com id
	73/9A-06769-4C673115; Thu, 07 Feb 2013 09:41:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360230083!19959699!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22754 invoked from network); 7 Feb 2013 09:41:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1228283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:41: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.297.1; Thu, 7 Feb 2013
	09:41:19 +0000
Message-ID: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:18 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2 0/4] XSA-39 CVE-2013-021[67]: Linux netback
 DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen netback implementation contains a couple of flaws which can
allow a guest to cause a DoS in the backend domain, potentially
affecting other domains in the system.

CVE-2013-0216 is a failure to sanity check the ring producer/consumer
pointers which can allow a guest to cause netback to loop for an
extended period preventing other work from occurring.

CVE-2013-0217 is a memory leak on an error path which is guest
triggerable.

The following series contains the fixes for these issues, as previously
included in Xen Security Advisory 39:
http://lists.xen.org/archives/html/xen-announce/2013-02/msg00001.html

Changes in v2:
 - Typo and block comment format fixes 
 - Added stable Cc



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:41:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:41: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 1U3Nyw-0004RW-Bb; Thu, 07 Feb 2013 09:41: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 1U3Nyu-0004RB-Ue
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:41:25 +0000
Received: from [85.158.139.83:61552] by server-13.bemta-5.messagelabs.com id
	73/9A-06769-4C673115; Thu, 07 Feb 2013 09:41:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360230083!19959699!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22754 invoked from network); 7 Feb 2013 09:41:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1228283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:41: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.297.1; Thu, 7 Feb 2013
	09:41:19 +0000
Message-ID: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:18 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2 0/4] XSA-39 CVE-2013-021[67]: Linux netback
 DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen netback implementation contains a couple of flaws which can
allow a guest to cause a DoS in the backend domain, potentially
affecting other domains in the system.

CVE-2013-0216 is a failure to sanity check the ring producer/consumer
pointers which can allow a guest to cause netback to loop for an
extended period preventing other work from occurring.

CVE-2013-0217 is a memory leak on an error path which is guest
triggerable.

The following series contains the fixes for these issues, as previously
included in Xen Security Advisory 39:
http://lists.xen.org/archives/html/xen-announce/2013-02/msg00001.html

Changes in v2:
 - Typo and block comment format fixes 
 - Added stable Cc



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:42:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:42: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 1U3Nzd-0004YY-Hn; Thu, 07 Feb 2013 09:42:09 +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 1U3Nzb-0004Xh-7o
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:07 +0000
Received: from [85.158.137.99:48931] by server-8.bemta-3.messagelabs.com id
	02/2A-25687-EE673115; Thu, 07 Feb 2013 09:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360230099!19522161!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29249 invoked from network); 7 Feb 2013 09:41:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288521"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-Mv;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:35 +0000
Message-ID: <1360230098-28218-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 1/4] xen/netback: shutdown the ring if it
	contains garbage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 buggy or malicious frontend should not be able to confuse netback.
If we spot anything which is not as it should be then shutdown the
device and don't try to continue with the ring in a potentially
hostile state. Well behaved and non-hostile frontends will not be
penalised.

As well as making the existing checks for such errors fatal also add a
new check that ensures that there isn't an insane number of requests
on the ring (i.e. more than would fit in the ring). If the ring
contains garbage then previously is was possible to loop over this
insane number, getting an error each time and therefore not generating
any more pending requests and therefore not exiting the loop in
xen_netbk_tx_build_gops for an externded period.

Also turn various netdev_dbg calls which no precipitate a fatal error
into netdev_err, they are rate limited because the device is shutdown
afterwards.

This fixes at least one known DoS/softlockup of the backend domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: <stable@vger.kernel.org> # 3.0+
---
v2: Fixup block comment style (DaveM)
---
 drivers/net/xen-netback/common.h    |    3 ++
 drivers/net/xen-netback/interface.c |   23 ++++++++-----
 drivers/net/xen-netback/netback.c   |   62 +++++++++++++++++++++++++---------
 3 files changed, 62 insertions(+), 26 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..9d7f172 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -151,6 +151,9 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
+/* Prevent the device from generating any further traffic. */
+void xenvif_carrier_off(struct xenvif *vif);
+
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b7d41f8..b8c5193 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -343,17 +343,22 @@ err:
 	return err;
 }
 
-void xenvif_disconnect(struct xenvif *vif)
+void xenvif_carrier_off(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
-	if (netif_carrier_ok(dev)) {
-		rtnl_lock();
-		netif_carrier_off(dev); /* discard queued packets */
-		if (netif_running(dev))
-			xenvif_down(vif);
-		rtnl_unlock();
-		xenvif_put(vif);
-	}
+
+	rtnl_lock();
+	netif_carrier_off(dev); /* discard queued packets */
+	if (netif_running(dev))
+		xenvif_down(vif);
+	rtnl_unlock();
+	xenvif_put(vif);
+}
+
+void xenvif_disconnect(struct xenvif *vif)
+{
+	if (netif_carrier_ok(vif->dev))
+		xenvif_carrier_off(vif);
 
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f2d6b78..c2e3336 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -888,6 +888,13 @@ static void netbk_tx_err(struct xenvif *vif,
 	xenvif_put(vif);
 }
 
+static void netbk_fatal_tx_err(struct xenvif *vif)
+{
+	netdev_err(vif->dev, "fatal error; disabling device\n");
+	xenvif_carrier_off(vif);
+	xenvif_put(vif);
+}
+
 static int netbk_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
@@ -901,19 +908,22 @@ static int netbk_count_requests(struct xenvif *vif,
 
 	do {
 		if (frags >= work_to_do) {
-			netdev_dbg(vif->dev, "Need more frags\n");
+			netdev_err(vif->dev, "Need more frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
-			netdev_dbg(vif->dev, "Too many frags\n");
+			netdev_err(vif->dev, "Too many frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
 		       sizeof(*txp));
 		if (txp->size > first->size) {
-			netdev_dbg(vif->dev, "Frags galore\n");
+			netdev_err(vif->dev, "Frag is bigger than frame.\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
@@ -921,8 +931,9 @@ static int netbk_count_requests(struct xenvif *vif,
 		frags++;
 
 		if (unlikely((txp->offset + txp->size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev, "txp->offset: %x, size: %u\n",
+			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
@@ -1095,7 +1106,8 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 
 	do {
 		if (unlikely(work_to_do-- <= 0)) {
-			netdev_dbg(vif->dev, "Missing extra info\n");
+			netdev_err(vif->dev, "Missing extra info\n");
+			netbk_fatal_tx_err(vif);
 			return -EBADR;
 		}
 
@@ -1104,8 +1116,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 		if (unlikely(!extra.type ||
 			     extra.type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
 			vif->tx.req_cons = ++cons;
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "Invalid extra type: %d\n", extra.type);
+			netbk_fatal_tx_err(vif);
 			return -EINVAL;
 		}
 
@@ -1121,13 +1134,15 @@ static int netbk_set_skb_gso(struct xenvif *vif,
 			     struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
-		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
+		netdev_err(vif->dev, "GSO size must not be zero.\n");
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
 	/* Currently only TCPv4 S.O. is supported. */
 	if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) {
-		netdev_dbg(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netdev_err(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
@@ -1264,9 +1279,25 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
+		/* This can sometimes happen because the test of
+		 * list_empty(net_schedule_list) at the top of the
+		 * loop is unlocked.  Just go back and have another
+		 * look.
+		 */
 		if (!vif)
 			continue;
 
+		if (vif->tx.sring->req_prod - vif->tx.req_cons >
+		    XEN_NETIF_TX_RING_SIZE) {
+			netdev_err(vif->dev,
+				   "Impossible number of requests. "
+				   "req_prod %d, req_cons %d, size %ld\n",
+				   vif->tx.sring->req_prod, vif->tx.req_cons,
+				   XEN_NETIF_TX_RING_SIZE);
+			netbk_fatal_tx_err(vif);
+			continue;
+		}
+
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
 			xenvif_put(vif);
@@ -1294,17 +1325,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			work_to_do = xen_netbk_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
-			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+			if (unlikely(work_to_do < 0))
 				continue;
-			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
-		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+		if (unlikely(ret < 0))
 			continue;
-		}
+
 		idx += ret;
 
 		if (unlikely(txreq.size < ETH_HLEN)) {
@@ -1316,11 +1344,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* No crossing a page as the payload mustn't fragment. */
 		if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			netbk_fatal_tx_err(vif);
 			continue;
 		}
 
@@ -1348,8 +1376,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
 			if (netbk_set_skb_gso(vif, skb, gso)) {
+				/* Failure in netbk_set_skb_gso is fatal. */
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
 				continue;
 			}
 		}
-- 
1.7.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 Feb 07 09:42:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:42: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 1U3Nzd-0004YY-Hn; Thu, 07 Feb 2013 09:42:09 +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 1U3Nzb-0004Xh-7o
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:07 +0000
Received: from [85.158.137.99:48931] by server-8.bemta-3.messagelabs.com id
	02/2A-25687-EE673115; Thu, 07 Feb 2013 09:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360230099!19522161!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29249 invoked from network); 7 Feb 2013 09:41:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288521"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-Mv;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:35 +0000
Message-ID: <1360230098-28218-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 1/4] xen/netback: shutdown the ring if it
	contains garbage.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 buggy or malicious frontend should not be able to confuse netback.
If we spot anything which is not as it should be then shutdown the
device and don't try to continue with the ring in a potentially
hostile state. Well behaved and non-hostile frontends will not be
penalised.

As well as making the existing checks for such errors fatal also add a
new check that ensures that there isn't an insane number of requests
on the ring (i.e. more than would fit in the ring). If the ring
contains garbage then previously is was possible to loop over this
insane number, getting an error each time and therefore not generating
any more pending requests and therefore not exiting the loop in
xen_netbk_tx_build_gops for an externded period.

Also turn various netdev_dbg calls which no precipitate a fatal error
into netdev_err, they are rate limited because the device is shutdown
afterwards.

This fixes at least one known DoS/softlockup of the backend domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: <stable@vger.kernel.org> # 3.0+
---
v2: Fixup block comment style (DaveM)
---
 drivers/net/xen-netback/common.h    |    3 ++
 drivers/net/xen-netback/interface.c |   23 ++++++++-----
 drivers/net/xen-netback/netback.c   |   62 +++++++++++++++++++++++++---------
 3 files changed, 62 insertions(+), 26 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..9d7f172 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -151,6 +151,9 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
+/* Prevent the device from generating any further traffic. */
+void xenvif_carrier_off(struct xenvif *vif);
+
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b7d41f8..b8c5193 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -343,17 +343,22 @@ err:
 	return err;
 }
 
-void xenvif_disconnect(struct xenvif *vif)
+void xenvif_carrier_off(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
-	if (netif_carrier_ok(dev)) {
-		rtnl_lock();
-		netif_carrier_off(dev); /* discard queued packets */
-		if (netif_running(dev))
-			xenvif_down(vif);
-		rtnl_unlock();
-		xenvif_put(vif);
-	}
+
+	rtnl_lock();
+	netif_carrier_off(dev); /* discard queued packets */
+	if (netif_running(dev))
+		xenvif_down(vif);
+	rtnl_unlock();
+	xenvif_put(vif);
+}
+
+void xenvif_disconnect(struct xenvif *vif)
+{
+	if (netif_carrier_ok(vif->dev))
+		xenvif_carrier_off(vif);
 
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f2d6b78..c2e3336 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -888,6 +888,13 @@ static void netbk_tx_err(struct xenvif *vif,
 	xenvif_put(vif);
 }
 
+static void netbk_fatal_tx_err(struct xenvif *vif)
+{
+	netdev_err(vif->dev, "fatal error; disabling device\n");
+	xenvif_carrier_off(vif);
+	xenvif_put(vif);
+}
+
 static int netbk_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
@@ -901,19 +908,22 @@ static int netbk_count_requests(struct xenvif *vif,
 
 	do {
 		if (frags >= work_to_do) {
-			netdev_dbg(vif->dev, "Need more frags\n");
+			netdev_err(vif->dev, "Need more frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
-			netdev_dbg(vif->dev, "Too many frags\n");
+			netdev_err(vif->dev, "Too many frags\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
 		       sizeof(*txp));
 		if (txp->size > first->size) {
-			netdev_dbg(vif->dev, "Frags galore\n");
+			netdev_err(vif->dev, "Frag is bigger than frame.\n");
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 
@@ -921,8 +931,9 @@ static int netbk_count_requests(struct xenvif *vif,
 		frags++;
 
 		if (unlikely((txp->offset + txp->size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev, "txp->offset: %x, size: %u\n",
+			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
+			netbk_fatal_tx_err(vif);
 			return -frags;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
@@ -1095,7 +1106,8 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 
 	do {
 		if (unlikely(work_to_do-- <= 0)) {
-			netdev_dbg(vif->dev, "Missing extra info\n");
+			netdev_err(vif->dev, "Missing extra info\n");
+			netbk_fatal_tx_err(vif);
 			return -EBADR;
 		}
 
@@ -1104,8 +1116,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 		if (unlikely(!extra.type ||
 			     extra.type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
 			vif->tx.req_cons = ++cons;
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "Invalid extra type: %d\n", extra.type);
+			netbk_fatal_tx_err(vif);
 			return -EINVAL;
 		}
 
@@ -1121,13 +1134,15 @@ static int netbk_set_skb_gso(struct xenvif *vif,
 			     struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
-		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
+		netdev_err(vif->dev, "GSO size must not be zero.\n");
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
 	/* Currently only TCPv4 S.O. is supported. */
 	if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) {
-		netdev_dbg(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netdev_err(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type);
+		netbk_fatal_tx_err(vif);
 		return -EINVAL;
 	}
 
@@ -1264,9 +1279,25 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
+		/* This can sometimes happen because the test of
+		 * list_empty(net_schedule_list) at the top of the
+		 * loop is unlocked.  Just go back and have another
+		 * look.
+		 */
 		if (!vif)
 			continue;
 
+		if (vif->tx.sring->req_prod - vif->tx.req_cons >
+		    XEN_NETIF_TX_RING_SIZE) {
+			netdev_err(vif->dev,
+				   "Impossible number of requests. "
+				   "req_prod %d, req_cons %d, size %ld\n",
+				   vif->tx.sring->req_prod, vif->tx.req_cons,
+				   XEN_NETIF_TX_RING_SIZE);
+			netbk_fatal_tx_err(vif);
+			continue;
+		}
+
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
 			xenvif_put(vif);
@@ -1294,17 +1325,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			work_to_do = xen_netbk_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
-			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+			if (unlikely(work_to_do < 0))
 				continue;
-			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
-		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+		if (unlikely(ret < 0))
 			continue;
-		}
+
 		idx += ret;
 
 		if (unlikely(txreq.size < ETH_HLEN)) {
@@ -1316,11 +1344,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		/* No crossing a page as the payload mustn't fragment. */
 		if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
-			netdev_dbg(vif->dev,
+			netdev_err(vif->dev,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			netbk_fatal_tx_err(vif);
 			continue;
 		}
 
@@ -1348,8 +1376,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
 			if (netbk_set_skb_gso(vif, skb, gso)) {
+				/* Failure in netbk_set_skb_gso is fatal. */
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
 				continue;
 			}
 		}
-- 
1.7.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 Feb 07 09:42:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3Nzc-0004YF-Ph; Thu, 07 Feb 2013 09:42: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 1U3Nzb-0004Xc-33
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:07 +0000
Received: from [85.158.137.99:12868] by server-11.bemta-3.messagelabs.com id
	DA/54-10249-EE673115; Thu, 07 Feb 2013 09:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360230099!19522161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28756 invoked from network); 7 Feb 2013 09:41:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288518"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-O5;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:37 +0000
Message-ID: <1360230098-28218-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 3/4] xen/netback: free already allocated
	memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: <stable@vger.kernel.org> # 3.0+
---
v2: s/reponses/responses/ (blp) & fixup block comment style (DaveM)
---
 drivers/net/xen-netback/netback.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index bf692df..dcb2d4d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -978,7 +978,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		pending_idx = netbk->pending_ring[index];
 		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
 		if (!page)
-			return NULL;
+			goto err;
 
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
@@ -1000,6 +1000,17 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	}
 
 	return gop;
+err:
+	/* Unwind, freeing all pages and sending error responses. */
+	while (i-- > start) {
+		xen_netbk_idx_release(netbk, frag_get_pending_idx(&frags[i]),
+				      XEN_NETIF_RSP_ERROR);
+	}
+	/* The head too, if necessary. */
+	if (start)
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
+
+	return NULL;
 }
 
 static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
-- 
1.7.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 Feb 07 09:42:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3Nzc-0004YF-Ph; Thu, 07 Feb 2013 09:42: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 1U3Nzb-0004Xc-33
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:07 +0000
Received: from [85.158.137.99:12868] by server-11.bemta-3.messagelabs.com id
	DA/54-10249-EE673115; Thu, 07 Feb 2013 09:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360230099!19522161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28756 invoked from network); 7 Feb 2013 09:41:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288518"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-O5;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:37 +0000
Message-ID: <1360230098-28218-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 3/4] xen/netback: free already allocated
	memory on failure in xen_netbk_get_requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: <stable@vger.kernel.org> # 3.0+
---
v2: s/reponses/responses/ (blp) & fixup block comment style (DaveM)
---
 drivers/net/xen-netback/netback.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index bf692df..dcb2d4d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -978,7 +978,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		pending_idx = netbk->pending_ring[index];
 		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
 		if (!page)
-			return NULL;
+			goto err;
 
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
@@ -1000,6 +1000,17 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	}
 
 	return gop;
+err:
+	/* Unwind, freeing all pages and sending error responses. */
+	while (i-- > start) {
+		xen_netbk_idx_release(netbk, frag_get_pending_idx(&frags[i]),
+				      XEN_NETIF_RSP_ERROR);
+	}
+	/* The head too, if necessary. */
+	if (start)
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
+
+	return NULL;
 }
 
 static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
-- 
1.7.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 Feb 07 09:42:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3Nzd-0004YO-5W; Thu, 07 Feb 2013 09:42:09 +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 1U3Nzb-0004Xg-7S
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:07 +0000
Received: from [85.158.137.99:12884] by server-4.bemta-3.messagelabs.com id
	09/D0-12802-EE673115; Thu, 07 Feb 2013 09:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360230099!19522161!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29037 invoked from network); 7 Feb 2013 09:41:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288519"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-NR;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:36 +0000
Message-ID: <1360230098-28218-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Matthew Daley <mattjd@gmail.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 2/4] xen/netback: don't leak pages on failure
	in xen_netbk_tx_check_gop.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Matthew Daley <mattjd@gmail.com>

Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: <stable@vger.kernel.org> # 3.0+
---
 drivers/net/xen-netback/netback.c |   38 ++++++++++++------------------------
 1 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index c2e3336..bf692df 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -147,7 +147,8 @@ void xen_netbk_remove_xenvif(struct xenvif *vif)
 	atomic_dec(&netbk->netfront_count);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -1007,30 +1008,20 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
-	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
 	int i, err, start;
 
 	/* Check status of header. */
 	err = gop->status;
-	if (unlikely(err)) {
-		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
-	}
+	if (unlikely(err))
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
 	start = (frag_get_pending_idx(&shinfo->frags[0]) == pending_idx);
 
 	for (i = start; i < nr_frags; i++) {
 		int j, newerr;
-		pending_ring_idx_t index;
 
 		pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
 
@@ -1039,16 +1030,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1056,10 +1043,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -1093,7 +1080,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(netbk->mmap_pages[pending_idx]);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 	}
 }
 
@@ -1476,7 +1463,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1528,7 +1515,8 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 	xen_netbk_tx_submit(netbk);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status)
 {
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
@@ -1542,7 +1530,7 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	vif = pending_tx_info->vif;
 
-	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
+	make_tx_response(vif, &pending_tx_info->req, status);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
-- 
1.7.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 Feb 07 09:42:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3Nzd-0004YO-5W; Thu, 07 Feb 2013 09:42:09 +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 1U3Nzb-0004Xg-7S
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:07 +0000
Received: from [85.158.137.99:12884] by server-4.bemta-3.messagelabs.com id
	09/D0-12802-EE673115; Thu, 07 Feb 2013 09:42:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360230099!19522161!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29037 invoked from network); 7 Feb 2013 09:41:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288519"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-NR;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:36 +0000
Message-ID: <1360230098-28218-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Matthew Daley <mattjd@gmail.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 2/4] xen/netback: don't leak pages on failure
	in xen_netbk_tx_check_gop.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Matthew Daley <mattjd@gmail.com>

Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: <stable@vger.kernel.org> # 3.0+
---
 drivers/net/xen-netback/netback.c |   38 ++++++++++++------------------------
 1 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index c2e3336..bf692df 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -147,7 +147,8 @@ void xen_netbk_remove_xenvif(struct xenvif *vif)
 	atomic_dec(&netbk->netfront_count);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -1007,30 +1008,20 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
-	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
 	int i, err, start;
 
 	/* Check status of header. */
 	err = gop->status;
-	if (unlikely(err)) {
-		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
-	}
+	if (unlikely(err))
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
 	start = (frag_get_pending_idx(&shinfo->frags[0]) == pending_idx);
 
 	for (i = start; i < nr_frags; i++) {
 		int j, newerr;
-		pending_ring_idx_t index;
 
 		pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
 
@@ -1039,16 +1030,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
-		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_ERROR);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1056,10 +1043,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -1093,7 +1080,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(netbk->mmap_pages[pending_idx]);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 	}
 }
 
@@ -1476,7 +1463,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(netbk, pending_idx, XEN_NETIF_RSP_OKAY);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1528,7 +1515,8 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 	xen_netbk_tx_submit(netbk);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx,
+				  u8 status)
 {
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
@@ -1542,7 +1530,7 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	vif = pending_tx_info->vif;
 
-	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
+	make_tx_response(vif, &pending_tx_info->req, status);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
-- 
1.7.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 Feb 07 09:42:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:42: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 1U3O07-0004hx-6Y; Thu, 07 Feb 2013 09:42: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 1U3O06-0004hJ-2H
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:38 +0000
Received: from [85.158.137.99:56114] by server-16.bemta-3.messagelabs.com id
	E1/8B-02727-D0773115; Thu, 07 Feb 2013 09:42:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360230105!11946395!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28986 invoked from network); 7 Feb 2013 09:41:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288520"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-OZ;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:38 +0000
Message-ID: <1360230098-28218-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 4/4] netback: correct netbk_tx_err to handle
	wrap around.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: <stable@vger.kernel.org> # 3.0+
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index dcb2d4d..2b9520c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -880,7 +880,7 @@ static void netbk_tx_err(struct xenvif *vif,
 
 	do {
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		if (cons >= end)
+		if (cons == end)
 			break;
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (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 Thu Feb 07 09:42:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:42: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 1U3O07-0004hx-6Y; Thu, 07 Feb 2013 09:42: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 1U3O06-0004hJ-2H
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:42:38 +0000
Received: from [85.158.137.99:56114] by server-16.bemta-3.messagelabs.com id
	E1/8B-02727-D0773115; Thu, 07 Feb 2013 09:42:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360230105!11946395!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28986 invoked from network); 7 Feb 2013 09:41:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:41:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6288520"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 09:41:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 04:41:38 -0500
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 1U3Nz8-0001aY-OZ;
	Thu, 07 Feb 2013 09:41:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <netdev@vger.kernel.org>
Date: Thu, 7 Feb 2013 09:41:38 +0000
Message-ID: <1360230098-28218-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2 4/4] netback: correct netbk_tx_err to handle
	wrap around.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: <stable@vger.kernel.org> # 3.0+
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index dcb2d4d..2b9520c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -880,7 +880,7 @@ static void netbk_tx_err(struct xenvif *vif,
 
 	do {
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		if (cons >= end)
+		if (cons == end)
 			break;
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (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 Thu Feb 07 09:47:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3O4T-0005Ho-Ts; Thu, 07 Feb 2013 09:47:09 +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 1U3O4S-0005HY-73
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:47:08 +0000
Received: from [85.158.137.99:63226] by server-10.bemta-3.messagelabs.com id
	B2/7F-10609-B1873115; Thu, 07 Feb 2013 09:47:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360230422!16954457!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24929 invoked from network); 7 Feb 2013 09:47:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1228507"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:47: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.297.1; Thu, 7 Feb 2013
	09:47:02 +0000
Message-ID: <1360230421.32479.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 7 Feb 2013 09:47:01 +0000
In-Reply-To: <20130207091907.GA5540@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 09:19 +0000, Olaf Hering wrote:
> On Thu, Feb 07, Alex Bligh wrote:
> 
> > Is there any way to do similarly in Xen? Or is Xen live migrate effectively
> > restricted to live migrate between identical CPUs?
> 
> Its mentionend somewhere in the docs that both cpus must be sufficient
> compatible. Use the cpuid= setting in the domU config file to enforce
> this.

You can also level down an entire host using the cpuid_mask_* command
line options described in
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html 

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:47:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09: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 1U3O4T-0005Ho-Ts; Thu, 07 Feb 2013 09:47:09 +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 1U3O4S-0005HY-73
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:47:08 +0000
Received: from [85.158.137.99:63226] by server-10.bemta-3.messagelabs.com id
	B2/7F-10609-B1873115; Thu, 07 Feb 2013 09:47:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360230422!16954457!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24929 invoked from network); 7 Feb 2013 09:47:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 09:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1228507"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 09:47: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.297.1; Thu, 7 Feb 2013
	09:47:02 +0000
Message-ID: <1360230421.32479.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 7 Feb 2013 09:47:01 +0000
In-Reply-To: <20130207091907.GA5540@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 09:19 +0000, Olaf Hering wrote:
> On Thu, Feb 07, Alex Bligh wrote:
> 
> > Is there any way to do similarly in Xen? Or is Xen live migrate effectively
> > restricted to live migrate between identical CPUs?
> 
> Its mentionend somewhere in the docs that both cpus must be sufficient
> compatible. Use the cpuid= setting in the domU config file to enforce
> this.

You can also level down an entire host using the cpuid_mask_* command
line options described in
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html 

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:57:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:57: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 1U3OEB-0005iR-2Q; Thu, 07 Feb 2013 09:57:11 +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 1U3OE9-0005iM-IZ
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:57:09 +0000
Received: from [85.158.143.35:23409] by server-3.bemta-4.messagelabs.com id
	82/1C-08920-47A73115; Thu, 07 Feb 2013 09:57:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360231026!10456754!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21830 invoked from network); 7 Feb 2013 09:57:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 09:57:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 09:57:05 +0000
Message-Id: <5113887F02000078000BCC20@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 09:57:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
	<alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
	<1360227997.32479.31.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360227997.32479.31.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-07 at 08:59 +0000, M A Young wrote:
>> On Thu, 7 Feb 2013, Andrew Cooper wrote:
>> 
>> > On 06/02/2013 20:37, M A Young wrote:
>> >
>> >> There are two types of problem, the first is from
>> >> xen/common/compat/memory.c where the error is
>> >>
>> >> memory.c: In function 'compat_memory_op':
>> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33:
>> >> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally
>> >> defined but not used [-Werror=unused-local-typedefs]
>> >>       typedef struct { type *p; } __guest_handle_ ## name
>> >>                                   ^
>> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5:
>> >> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
>> >>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>> >>       ^
>> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41:
>> >> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
>> >>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name,
>> >> name)
>> >>                                           ^
>> >> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
>> >>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
>> >>               ^
>> >>
>> >> so we are defining something that isn't used.
>> >
>> > But it is used, by guest_handle_cast, albeit through several layers of
>> > macros.
>> >
>> > I would tentativly object to the use of "__attribute__((unused));" to
>> > work around what appears to be a gcc bug.  If 4.8 support is desperately
>> > wanted, then a better solution would be to specify
>> > -Wno-unused-local-typedefs to disable the buggy feature.
>> 
>> It looked to me as if the DEFINE macro does two typedefs and the code only 
>> uses the first, so gcc 4.8 was correct in its objections. The suggested 
>> workaround of using -Wno-unused-local-typedefs isn't very portible as 
>> earlier versions of gcc don't recognize it.
> 
> We have a cc-option macro in the makefiles to enable these sorts of
> options to be enabled conditionally.
> 
> However it seems a bit odd to be using DEFINE_XEN_GUEST_HANDLE in this
> manner, should it not be declared in some header? I can see a
> DEFINE_COMPAT_HANDLE(compat_memory_exchange_t) in
> xen/include/compat/memory.h. Perhaps the one in memory.c can just be
> dropped or otherwise modified to use this?

Actually, I'm of the opposite opinion - it should be in other places
too that handles don't get needlessly defined by the public
headers. They should get defined only when there actually is a
use for them. Everything else can be defined where actually
consumed, as in this case: For one, a handle of a compat_*
type can't be defined in a public header anyway, as the compat
types don't get defined there. And then, as you say, the oddity
of this type makes it desirable to scope restrict it as much as
possible.

Now, for the actual solution, I'd prefer the -Wno-... option
suggested above, or as a second best choice generalizing the
solution suggested by Michael, applying the attribute in
DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
attaching it in to the use of the macro just happens to work,
but isn't guaranteed to in the future: Switching around the
order of the two lines of the expansion

#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)

or adding a third (say, volatile) one would re-expose the
problem.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 09:57:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 09:57: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 1U3OEB-0005iR-2Q; Thu, 07 Feb 2013 09:57:11 +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 1U3OE9-0005iM-IZ
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 09:57:09 +0000
Received: from [85.158.143.35:23409] by server-3.bemta-4.messagelabs.com id
	82/1C-08920-47A73115; Thu, 07 Feb 2013 09:57:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360231026!10456754!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21830 invoked from network); 7 Feb 2013 09:57:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 09:57:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 09:57:05 +0000
Message-Id: <5113887F02000078000BCC20@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 09:57:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<5112FB71.3050600@citrix.com>
	<alpine.GSO.2.00.1302070855550.23718@algedi.dur.ac.uk>
	<1360227997.32479.31.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360227997.32479.31.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-07 at 08:59 +0000, M A Young wrote:
>> On Thu, 7 Feb 2013, Andrew Cooper wrote:
>> 
>> > On 06/02/2013 20:37, M A Young wrote:
>> >
>> >> There are two types of problem, the first is from
>> >> xen/common/compat/memory.c where the error is
>> >>
>> >> memory.c: In function 'compat_memory_op':
>> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33:
>> >> error: typedef '__guest_handle_const_compat_memory_exchange_t' locally
>> >> defined but not used [-Werror=unused-local-typedefs]
>> >>       typedef struct { type *p; } __guest_handle_ ## name
>> >>                                   ^
>> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5:
>> >> note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
>> >>       ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>> >>       ^
>> >> /builddir/build/BUILD/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41:
>> >> note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
>> >>   #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name,
>> >> name)
>> >>                                           ^
>> >> memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
>> >>               DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
>> >>               ^
>> >>
>> >> so we are defining something that isn't used.
>> >
>> > But it is used, by guest_handle_cast, albeit through several layers of
>> > macros.
>> >
>> > I would tentativly object to the use of "__attribute__((unused));" to
>> > work around what appears to be a gcc bug.  If 4.8 support is desperately
>> > wanted, then a better solution would be to specify
>> > -Wno-unused-local-typedefs to disable the buggy feature.
>> 
>> It looked to me as if the DEFINE macro does two typedefs and the code only 
>> uses the first, so gcc 4.8 was correct in its objections. The suggested 
>> workaround of using -Wno-unused-local-typedefs isn't very portible as 
>> earlier versions of gcc don't recognize it.
> 
> We have a cc-option macro in the makefiles to enable these sorts of
> options to be enabled conditionally.
> 
> However it seems a bit odd to be using DEFINE_XEN_GUEST_HANDLE in this
> manner, should it not be declared in some header? I can see a
> DEFINE_COMPAT_HANDLE(compat_memory_exchange_t) in
> xen/include/compat/memory.h. Perhaps the one in memory.c can just be
> dropped or otherwise modified to use this?

Actually, I'm of the opposite opinion - it should be in other places
too that handles don't get needlessly defined by the public
headers. They should get defined only when there actually is a
use for them. Everything else can be defined where actually
consumed, as in this case: For one, a handle of a compat_*
type can't be defined in a public header anyway, as the compat
types don't get defined there. And then, as you say, the oddity
of this type makes it desirable to scope restrict it as much as
possible.

Now, for the actual solution, I'd prefer the -Wno-... option
suggested above, or as a second best choice generalizing the
solution suggested by Michael, applying the attribute in
DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
attaching it in to the use of the macro just happens to work,
but isn't guaranteed to in the future: Switching around the
order of the two lines of the expansion

#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)

or adding a third (say, volatile) one would re-expose the
problem.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 10:03:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10: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 1U3OJh-00065v-31; Thu, 07 Feb 2013 10:02:53 +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 1U3OJg-00065n-0W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 10:02:52 +0000
Received: from [85.158.143.35:49571] by server-1.bemta-4.messagelabs.com id
	AC/B9-08839-BCB73115; Thu, 07 Feb 2013 10:02:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360231326!15535070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11176 invoked from network); 7 Feb 2013 10:02:08 -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; 7 Feb 2013 10:02:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 10:02:06 +0000
Message-Id: <511389AC02000078000BCC3A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 10:02:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "M A Young" <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 21:37, M A Young <m.a.young@durham.ac.uk> wrote:
>@@ -264,7 +264,7 @@
>                return -1;
>        }
> 
>-       memset(buf,0,sizeof(buf));
>+       memset(buf,0,sizeof(*buf));

While everything else looks right, this one for sure is wrong - buf
is an array, and hence sizeof(*buf) would clear just the first array
element.

Also, we'd need you Signed-off-by to get the patch committed,
and I'd suggest splitting off the public header related change
from the (tools side) rest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 10:03:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10: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 1U3OJh-00065v-31; Thu, 07 Feb 2013 10:02:53 +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 1U3OJg-00065n-0W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 10:02:52 +0000
Received: from [85.158.143.35:49571] by server-1.bemta-4.messagelabs.com id
	AC/B9-08839-BCB73115; Thu, 07 Feb 2013 10:02:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360231326!15535070!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11176 invoked from network); 7 Feb 2013 10:02:08 -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; 7 Feb 2013 10:02:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 10:02:06 +0000
Message-Id: <511389AC02000078000BCC3A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 10:02:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "M A Young" <m.a.young@durham.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 06.02.13 at 21:37, M A Young <m.a.young@durham.ac.uk> wrote:
>@@ -264,7 +264,7 @@
>                return -1;
>        }
> 
>-       memset(buf,0,sizeof(buf));
>+       memset(buf,0,sizeof(*buf));

While everything else looks right, this one for sure is wrong - buf
is an array, and hence sizeof(*buf) would clear just the first array
element.

Also, we'd need you Signed-off-by to get the patch committed,
and I'd suggest splitting off the public header related change
from the (tools side) rest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 10:54:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10: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 1U3P7k-0007yI-Sz; Thu, 07 Feb 2013 10:54:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1U3P7j-0007yD-Tc
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 10:54:36 +0000
Received: from [85.158.139.211:26473] by server-10.bemta-5.messagelabs.com id
	4E/5E-04697-BE783115; Thu, 07 Feb 2013 10:54:35 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360234472!17528643!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjEyMjA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29288 invoked from network); 7 Feb 2013 10:54:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 10:54:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r17AsUuX010370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Feb 2013 10:54:31 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
	r17AsUpN002616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 10:54:30 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r17AsUkO024545; Thu, 7 Feb 2013 04:54:30 -0600
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Feb 2013 02:54:29 -0800
Date: Thu, 7 Feb 2013 13:54:25 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: mukesh.rathor@oracle.com
Message-ID: <20130207105425.GA1597@elgon.mountain>
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]
Cc: kbuild@01.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen/pvh linux: Use ballooning to allocate grant
	table 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

Hello Mukesh Rathor,

The patch 40f633eb0def: "xen/pvh linux: Use ballooning to allocate
grant table pages" from Jan 31, 2013, leads to the following Sparse
warning: "drivers/xen/grant-table.c:1095:28: error: bad constant
	expression"

drivers/xen/grant-table.c
  1092  static int xlated_setup_gnttab_pages(int numpages, void **addr)
  1093  {
  1094          int i, rc;
  1095          unsigned long pfns[numpages];
  1096          struct page *pages[numpages];
                                   ^^^^^^^^
Because the kernel uses an 8k stack if this is over 500 it will cause
a kernel crash.  It will crash before we reach 500 actually.  It looks
like typical values for this are around 4 so we're probably safe, but
it's still a bit nasty.

  1097  
  1098          rc = alloc_xenballooned_pages(numpages, pages, 0);
  1099          if (rc != 0) {
  1100                  pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,

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 Thu Feb 07 10:54:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10: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 1U3P7k-0007yI-Sz; Thu, 07 Feb 2013 10:54:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1U3P7j-0007yD-Tc
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 10:54:36 +0000
Received: from [85.158.139.211:26473] by server-10.bemta-5.messagelabs.com id
	4E/5E-04697-BE783115; Thu, 07 Feb 2013 10:54:35 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360234472!17528643!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjEyMjA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29288 invoked from network); 7 Feb 2013 10:54:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 10:54:34 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r17AsUuX010370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 7 Feb 2013 10:54:31 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
	r17AsUpN002616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 10:54:30 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r17AsUkO024545; Thu, 7 Feb 2013 04:54:30 -0600
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 07 Feb 2013 02:54:29 -0800
Date: Thu, 7 Feb 2013 13:54:25 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: mukesh.rathor@oracle.com
Message-ID: <20130207105425.GA1597@elgon.mountain>
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]
Cc: kbuild@01.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen/pvh linux: Use ballooning to allocate grant
	table 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

Hello Mukesh Rathor,

The patch 40f633eb0def: "xen/pvh linux: Use ballooning to allocate
grant table pages" from Jan 31, 2013, leads to the following Sparse
warning: "drivers/xen/grant-table.c:1095:28: error: bad constant
	expression"

drivers/xen/grant-table.c
  1092  static int xlated_setup_gnttab_pages(int numpages, void **addr)
  1093  {
  1094          int i, rc;
  1095          unsigned long pfns[numpages];
  1096          struct page *pages[numpages];
                                   ^^^^^^^^
Because the kernel uses an 8k stack if this is over 500 it will cause
a kernel crash.  It will crash before we reach 500 actually.  It looks
like typical values for this are around 4 so we're probably safe, but
it's still a bit nasty.

  1097  
  1098          rc = alloc_xenballooned_pages(numpages, pages, 0);
  1099          if (rc != 0) {
  1100                  pr_warn("%s Could not balloon alloc %d pfns rc:%d\n", __func__,

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 Thu Feb 07 10:56:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10:56: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 1U3P9d-000837-DS; Thu, 07 Feb 2013 10:56: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 1U3P9b-000831-9B
	for Xen-devel@lists.xensource.com; Thu, 07 Feb 2013 10:56:31 +0000
Received: from [193.109.254.147:30231] by server-14.bemta-14.messagelabs.com
	id B7/A7-02031-E5883115; Thu, 07 Feb 2013 10:56:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360234582!9522355!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 7 Feb 2013 10:56:23 -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; 7 Feb 2013 10:56:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3P9R-000KAN-TU; Thu, 07 Feb 2013 10:56:21 +0000
Date: Thu, 7 Feb 2013 10:56:21 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130207105621.GA77133@ocelot.phlegethon.org>
References: <20130111180944.4ff10c8f@mantra.us.oracle.com>
	<20130124171815.GM20551@ocelot.phlegethon.org>
	<20130131183824.3af5e6a0@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130131183824.3af5e6a0@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] [RFC PATCH 13/16]: PVH xen: introduce
	p2m_map_foreign
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:38 -0800 on 31 Jan (1359657504), Mukesh Rathor wrote:
> On Thu, 24 Jan 2013 17:18:15 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:09 -0800 on 11 Jan (1357927784), Mukesh Rathor wrote:
> > > @@ -584,6 +584,11 @@ guest_physmap_add_entry(struct domain *d
> > >          {
> > >              ASSERT(mfn_valid(omfn));
> > >              set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
> > > +
> > > +            /* Because PVH domU uses kmalloc for grant pfn, we
> > > need to save
> > > +             * and restore the old mfn */
> > > +             if (is_pvh_domain(d) && p2m_is_grant(t))
> > > +                 free_domheap_page(mfn_to_page(omfn));
> > 
> > I think you'll need to explain this in more detail.  The comment
> > assumes that the guest is running linux, which is worrying.  And in
> > any case you can't just free_domheap_page() the guest's memory!  What
> > if another domain has a reference to it?
> 
> Ok, I fixed linux side so instead of kmalloc it uses ballooning to
> get pfn space for the grant table. That means there should not be 
> an omfn here. If there is, I think I should just fail the operation, 
> ie, guest_physmap_add_entry(), right?

Currently, guest_physmap_add_entry() just overwrites the old entry,
allowing the guest to leak it if it wants to.  It's perhaps not the best
interface in the world, but I think PVH guetst should get the same
treatment as HVM ones.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 10:56:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10:56: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 1U3P9d-000837-DS; Thu, 07 Feb 2013 10:56: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 1U3P9b-000831-9B
	for Xen-devel@lists.xensource.com; Thu, 07 Feb 2013 10:56:31 +0000
Received: from [193.109.254.147:30231] by server-14.bemta-14.messagelabs.com
	id B7/A7-02031-E5883115; Thu, 07 Feb 2013 10:56:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360234582!9522355!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 7 Feb 2013 10:56:23 -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; 7 Feb 2013 10:56:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3P9R-000KAN-TU; Thu, 07 Feb 2013 10:56:21 +0000
Date: Thu, 7 Feb 2013 10:56:21 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130207105621.GA77133@ocelot.phlegethon.org>
References: <20130111180944.4ff10c8f@mantra.us.oracle.com>
	<20130124171815.GM20551@ocelot.phlegethon.org>
	<20130131183824.3af5e6a0@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130131183824.3af5e6a0@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] [RFC PATCH 13/16]: PVH xen: introduce
	p2m_map_foreign
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:38 -0800 on 31 Jan (1359657504), Mukesh Rathor wrote:
> On Thu, 24 Jan 2013 17:18:15 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:09 -0800 on 11 Jan (1357927784), Mukesh Rathor wrote:
> > > @@ -584,6 +584,11 @@ guest_physmap_add_entry(struct domain *d
> > >          {
> > >              ASSERT(mfn_valid(omfn));
> > >              set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
> > > +
> > > +            /* Because PVH domU uses kmalloc for grant pfn, we
> > > need to save
> > > +             * and restore the old mfn */
> > > +             if (is_pvh_domain(d) && p2m_is_grant(t))
> > > +                 free_domheap_page(mfn_to_page(omfn));
> > 
> > I think you'll need to explain this in more detail.  The comment
> > assumes that the guest is running linux, which is worrying.  And in
> > any case you can't just free_domheap_page() the guest's memory!  What
> > if another domain has a reference to it?
> 
> Ok, I fixed linux side so instead of kmalloc it uses ballooning to
> get pfn space for the grant table. That means there should not be 
> an omfn here. If there is, I think I should just fail the operation, 
> ie, guest_physmap_add_entry(), right?

Currently, guest_physmap_add_entry() just overwrites the old entry,
allowing the guest to leak it if it wants to.  It's perhaps not the best
interface in the world, but I think PVH guetst should get the same
treatment as HVM ones.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 10:56:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10:56: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 1U3P9l-00083i-QU; Thu, 07 Feb 2013 10:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U3P9k-00083V-S0; Thu, 07 Feb 2013 10:56:41 +0000
Received: from [85.158.139.83:50776] by server-15.bemta-5.messagelabs.com id
	8F/23-18914-86883115; Thu, 07 Feb 2013 10:56:40 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360234599!30403702!1
X-Originating-IP: [74.125.82.42]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5107 invoked from network); 7 Feb 2013 10:56:39 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 10:56:39 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so5839315wgh.3
	for <multiple recipients>; Thu, 07 Feb 2013 02:56:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=oa4+QnJfpbv6aOJUSmUPkkzQYvkr1EVbCKJG06Fe51o=;
	b=Q0j9EGEYPXwWBseWGgaI+qhU9EZRzK1kSErNLJXMm7NlU13D2ePBhhq+uW+V71vuKy
	7SbxsRKJkZIa96ESV1LqNiMWas4EkCLo9G1Ja17Ui9tce4okgueCqc+ajkwUFRZauYqu
	FY3AQfcjiVu/9qOYJ+svYGvvh3VIOcUw59Pm+WrjrqUAnfw8q0fmcYu8e/AgcNCaLGea
	zr+0LyIoOLjs/34Wc/4N9JKoVsjgtGyFnE51rs9ZC1WVaPg1abBv3e4sTkwMnex7K2hM
	v2dCv9WwdA9KrNopKk8uybl0TPU3bLcbGjtVuHuFY7HoU4XJTqnIAmbuy0CE1PsXtbRC
	oRPA==
MIME-Version: 1.0
X-Received: by 10.180.99.227 with SMTP id et3mr1784892wib.6.1360234599272;
	Thu, 07 Feb 2013 02:56:39 -0800 (PST)
Received: by 10.227.203.18 with HTTP; Thu, 7 Feb 2013 02:56:39 -0800 (PST)
Date: Thu, 7 Feb 2013 11:56:39 +0100
Message-ID: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: xen-users <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2430067599702355514=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2430067599702355514==
Content-Type: multipart/alternative; boundary=f46d041826aa19d08b04d5204ccf

--f46d041826aa19d08b04d5204ccf
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I read in the wiki that stubdomains aren't support on NetBSD. Will subdoms
be supported on NetBSD? Is someone working on that topic actually?

On the NetBSD Xen mailinglist I got no reply. Hope that someone could help
me.

Best Regards

--f46d041826aa19d08b04d5204ccf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello all,<br><br></div>I read in the wiki =
that stubdomains aren&#39;t support on NetBSD. Will subdoms be supported on=
 NetBSD? Is someone working on that topic actually?<br><br></div>On the Net=
BSD Xen mailinglist I got no reply. Hope that someone could help me.<br>
<br></div>Best Regards<br></div>

--f46d041826aa19d08b04d5204ccf--


--===============2430067599702355514==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2430067599702355514==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 10:56:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 10:56: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 1U3P9l-00083i-QU; Thu, 07 Feb 2013 10:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U3P9k-00083V-S0; Thu, 07 Feb 2013 10:56:41 +0000
Received: from [85.158.139.83:50776] by server-15.bemta-5.messagelabs.com id
	8F/23-18914-86883115; Thu, 07 Feb 2013 10:56:40 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360234599!30403702!1
X-Originating-IP: [74.125.82.42]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5107 invoked from network); 7 Feb 2013 10:56:39 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 10:56:39 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so5839315wgh.3
	for <multiple recipients>; Thu, 07 Feb 2013 02:56:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=oa4+QnJfpbv6aOJUSmUPkkzQYvkr1EVbCKJG06Fe51o=;
	b=Q0j9EGEYPXwWBseWGgaI+qhU9EZRzK1kSErNLJXMm7NlU13D2ePBhhq+uW+V71vuKy
	7SbxsRKJkZIa96ESV1LqNiMWas4EkCLo9G1Ja17Ui9tce4okgueCqc+ajkwUFRZauYqu
	FY3AQfcjiVu/9qOYJ+svYGvvh3VIOcUw59Pm+WrjrqUAnfw8q0fmcYu8e/AgcNCaLGea
	zr+0LyIoOLjs/34Wc/4N9JKoVsjgtGyFnE51rs9ZC1WVaPg1abBv3e4sTkwMnex7K2hM
	v2dCv9WwdA9KrNopKk8uybl0TPU3bLcbGjtVuHuFY7HoU4XJTqnIAmbuy0CE1PsXtbRC
	oRPA==
MIME-Version: 1.0
X-Received: by 10.180.99.227 with SMTP id et3mr1784892wib.6.1360234599272;
	Thu, 07 Feb 2013 02:56:39 -0800 (PST)
Received: by 10.227.203.18 with HTTP; Thu, 7 Feb 2013 02:56:39 -0800 (PST)
Date: Thu, 7 Feb 2013 11:56:39 +0100
Message-ID: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: xen-users <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2430067599702355514=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2430067599702355514==
Content-Type: multipart/alternative; boundary=f46d041826aa19d08b04d5204ccf

--f46d041826aa19d08b04d5204ccf
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I read in the wiki that stubdomains aren't support on NetBSD. Will subdoms
be supported on NetBSD? Is someone working on that topic actually?

On the NetBSD Xen mailinglist I got no reply. Hope that someone could help
me.

Best Regards

--f46d041826aa19d08b04d5204ccf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello all,<br><br></div>I read in the wiki =
that stubdomains aren&#39;t support on NetBSD. Will subdoms be supported on=
 NetBSD? Is someone working on that topic actually?<br><br></div>On the Net=
BSD Xen mailinglist I got no reply. Hope that someone could help me.<br>
<br></div>Best Regards<br></div>

--f46d041826aa19d08b04d5204ccf--


--===============2430067599702355514==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2430067599702355514==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 11:00:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:00: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 1U3PCw-0008U5-5I; Thu, 07 Feb 2013 10:59:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3PCu-0008Tv-5o
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 10:59:56 +0000
Received: from [85.158.139.83:52401] by server-15.bemta-5.messagelabs.com id
	BA/0B-18914-B2983115; Thu, 07 Feb 2013 10:59:55 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360234783!27286079!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22111 invoked from network); 7 Feb 2013 10:59:44 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-182.messagelabs.com with SMTP;
	7 Feb 2013 10:59:44 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C7F05C56198;
	Thu,  7 Feb 2013 10:59:08 +0000 (GMT)
Date: Thu, 07 Feb 2013 10:59:07 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>, Olaf Hering <olaf@aepfle.de>
Message-ID: <496E7A8DB9DCF257D29E10F2@nimrod.local>
In-Reply-To: <1360230421.32479.46.camel@zakaz.uk.xensource.com>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian, Olaf,

--On 7 February 2013 09:47:01 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Thu, 2013-02-07 at 09:19 +0000, Olaf Hering wrote:
>> On Thu, Feb 07, Alex Bligh wrote:
>>
>> > Is there any way to do similarly in Xen? Or is Xen live migrate
>> > effectively restricted to live migrate between identical CPUs?
>>
>> Its mentionend somewhere in the docs that both cpus must be sufficient
>> compatible. Use the cpuid= setting in the domU config file to enforce
>> this.
>
> You can also level down an entire host using the cpuid_mask_* command
> line options described in
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

Thanks - that's really helpful. Looking at the documentation for cpuid=
I can't see an obvious way of saying 'mask everything except the
least common denominator of features' using the libxl method, without
having prior knowledge of what each version of xen supports. I'm not
even clear how to do this on the xend method (obviously I want to
pass long bitstrings of zeros, but how many?). Am I missing something?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:00:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:00: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 1U3PCw-0008U5-5I; Thu, 07 Feb 2013 10:59:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3PCu-0008Tv-5o
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 10:59:56 +0000
Received: from [85.158.139.83:52401] by server-15.bemta-5.messagelabs.com id
	BA/0B-18914-B2983115; Thu, 07 Feb 2013 10:59:55 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360234783!27286079!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22111 invoked from network); 7 Feb 2013 10:59:44 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-182.messagelabs.com with SMTP;
	7 Feb 2013 10:59:44 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C7F05C56198;
	Thu,  7 Feb 2013 10:59:08 +0000 (GMT)
Date: Thu, 07 Feb 2013 10:59:07 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>, Olaf Hering <olaf@aepfle.de>
Message-ID: <496E7A8DB9DCF257D29E10F2@nimrod.local>
In-Reply-To: <1360230421.32479.46.camel@zakaz.uk.xensource.com>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian, Olaf,

--On 7 February 2013 09:47:01 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Thu, 2013-02-07 at 09:19 +0000, Olaf Hering wrote:
>> On Thu, Feb 07, Alex Bligh wrote:
>>
>> > Is there any way to do similarly in Xen? Or is Xen live migrate
>> > effectively restricted to live migrate between identical CPUs?
>>
>> Its mentionend somewhere in the docs that both cpus must be sufficient
>> compatible. Use the cpuid= setting in the domU config file to enforce
>> this.
>
> You can also level down an entire host using the cpuid_mask_* command
> line options described in
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

Thanks - that's really helpful. Looking at the documentation for cpuid=
I can't see an obvious way of saying 'mask everything except the
least common denominator of features' using the libxl method, without
having prior knowledge of what each version of xen supports. I'm not
even clear how to do this on the xend method (obviously I want to
pass long bitstrings of zeros, but how many?). Am I missing something?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:04:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:04: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 1U3PGx-0000OU-Rg; Thu, 07 Feb 2013 11:04:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3PGw-0000OM-KV; Thu, 07 Feb 2013 11:04:06 +0000
Received: from [85.158.137.99:29176] by server-5.bemta-3.messagelabs.com id
	2F/B1-04457-52A83115; Thu, 07 Feb 2013 11:04:05 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360235043!14996501!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6980 invoked from network); 7 Feb 2013 11:04:04 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355094000"; 
   d="scan'208";a="1794812"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 12:03:47 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3PGd-0002WE-OH; Thu, 07 Feb 2013 12:03:47 +0100
Date: Thu, 7 Feb 2013 12:03:47 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: tech mailinglists <mailinglists.tech@gmail.com>
Message-ID: <20130207110347.GX6193@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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,

tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
> I read in the wiki that stubdomains aren't support on NetBSD. Will subdom=
s be
> supported on NetBSD? Is someone working on that topic actually?

I see no reason why it should be hard to do it, so it should be just a
matter of someone with a NetBSD box to just try and fix the few missing
bits.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:04:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:04: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 1U3PGx-0000OU-Rg; Thu, 07 Feb 2013 11:04:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3PGw-0000OM-KV; Thu, 07 Feb 2013 11:04:06 +0000
Received: from [85.158.137.99:29176] by server-5.bemta-3.messagelabs.com id
	2F/B1-04457-52A83115; Thu, 07 Feb 2013 11:04:05 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360235043!14996501!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6980 invoked from network); 7 Feb 2013 11:04:04 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355094000"; 
   d="scan'208";a="1794812"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 12:03:47 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3PGd-0002WE-OH; Thu, 07 Feb 2013 12:03:47 +0100
Date: Thu, 7 Feb 2013 12:03:47 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: tech mailinglists <mailinglists.tech@gmail.com>
Message-ID: <20130207110347.GX6193@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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,

tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
> I read in the wiki that stubdomains aren't support on NetBSD. Will subdom=
s be
> supported on NetBSD? Is someone working on that topic actually?

I see no reason why it should be hard to do it, so it should be just a
matter of someone with a NetBSD box to just try and fix the few missing
bits.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:07:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:07: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 1U3PK5-00014W-VF; Thu, 07 Feb 2013 11:07: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 1U3PK4-00014C-Bv
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:07:20 +0000
Received: from [85.158.143.35:50165] by server-2.bemta-4.messagelabs.com id
	71/DA-01597-7EA83115; Thu, 07 Feb 2013 11:07:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360235086!12155538!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31617 invoked from network); 7 Feb 2013 11:04:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 11:04:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3PHU-000KBd-OM; Thu, 07 Feb 2013 11:04:40 +0000
Date: Thu, 7 Feb 2013 11:04:40 +0000
From: Tim Deegan <tim@xen.org>
To: Robert Phillips <robert.phillips@citrix.com>
Message-ID: <20130207110440.GB77133@ocelot.phlegethon.org>
References: <1358796510-2861-1-git-send-email-robert.phillips@citrix.com>
	<20130124112521.GB18850@ocelot.phlegethon.org>
	<048EAD622912254A9DEA24C1734613C18C8A4B8974@FTLPMAILBOX02.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <048EAD622912254A9DEA24C1734613C18C8A4B8974@FTLPMAILBOX02.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	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

At 06:38 -0500 on 05 Feb (1360046289), Robert Phillips wrote:
> > > +        ext = __map_domain_page(pg);
> > > +        /* Is unmapped in dirty_vram_free() */
> > 
> > Mappings from map_domain_page() can't be kept around like this.  They're
> > supposed to be short-term, and in systems where we don't have a full 1-1
> > map of memory (e.g. x86 once Jan's 16TB-support series goes in) there are a
> > limited number of mapping slots.
> > 
> > Jan, what do you recommend here?  These are pages of linked-list entries,
> > part of the p2m/mm overhead and so allocated from the guest's shadow
> > memory.  Are we going to have to allocate them from xenheap instead or is
> > there any way to avoid that?
> 
> One possible solution is to use a fixmap table. 
> Rather than storing VAs in these tables, the code could store
> entries containing physical_page/offset_in_page. 
> 
>  When managing the table
> the code could remap PA/offset into a single fixed virtual address
> (and clear its TLB).  Clearing a single TLB shouldn't hurt
> performance too terribly, right?

It shoud be OK, but I think you might as well use the existing
map_domain_page() code for this, rather than adding a new fixmap -- that
uses a ring of mappings and amortises a single TLB flush every time the
ring is filled up.

So I suggest storing a maddr in the table and using map/unmap_domain_page()
+ offset to access them.  The existing shadow_track_dirty_vram()
function does this (search for sl1ma).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:07:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:07: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 1U3PK5-00014W-VF; Thu, 07 Feb 2013 11:07: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 1U3PK4-00014C-Bv
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:07:20 +0000
Received: from [85.158.143.35:50165] by server-2.bemta-4.messagelabs.com id
	71/DA-01597-7EA83115; Thu, 07 Feb 2013 11:07:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360235086!12155538!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31617 invoked from network); 7 Feb 2013 11:04:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 11:04:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3PHU-000KBd-OM; Thu, 07 Feb 2013 11:04:40 +0000
Date: Thu, 7 Feb 2013 11:04:40 +0000
From: Tim Deegan <tim@xen.org>
To: Robert Phillips <robert.phillips@citrix.com>
Message-ID: <20130207110440.GB77133@ocelot.phlegethon.org>
References: <1358796510-2861-1-git-send-email-robert.phillips@citrix.com>
	<20130124112521.GB18850@ocelot.phlegethon.org>
	<048EAD622912254A9DEA24C1734613C18C8A4B8974@FTLPMAILBOX02.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <048EAD622912254A9DEA24C1734613C18C8A4B8974@FTLPMAILBOX02.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	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

At 06:38 -0500 on 05 Feb (1360046289), Robert Phillips wrote:
> > > +        ext = __map_domain_page(pg);
> > > +        /* Is unmapped in dirty_vram_free() */
> > 
> > Mappings from map_domain_page() can't be kept around like this.  They're
> > supposed to be short-term, and in systems where we don't have a full 1-1
> > map of memory (e.g. x86 once Jan's 16TB-support series goes in) there are a
> > limited number of mapping slots.
> > 
> > Jan, what do you recommend here?  These are pages of linked-list entries,
> > part of the p2m/mm overhead and so allocated from the guest's shadow
> > memory.  Are we going to have to allocate them from xenheap instead or is
> > there any way to avoid that?
> 
> One possible solution is to use a fixmap table. 
> Rather than storing VAs in these tables, the code could store
> entries containing physical_page/offset_in_page. 
> 
>  When managing the table
> the code could remap PA/offset into a single fixed virtual address
> (and clear its TLB).  Clearing a single TLB shouldn't hurt
> performance too terribly, right?

It shoud be OK, but I think you might as well use the existing
map_domain_page() code for this, rather than adding a new fixmap -- that
uses a ring of mappings and amortises a single TLB flush every time the
ring is filled up.

So I suggest storing a maddr in the table and using map/unmap_domain_page()
+ offset to access them.  The existing shadow_track_dirty_vram()
function does this (search for sl1ma).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:30:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:30: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 1U3PgT-00027P-7L; Thu, 07 Feb 2013 11:30:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3PgR-00027K-Aj
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:30:27 +0000
Received: from [193.109.254.147:7760] by server-11.bemta-14.messagelabs.com id
	D1/3F-30685-25093115; Thu, 07 Feb 2013 11:30:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360236614!3619028!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25722 invoked from network); 7 Feb 2013 11:30:19 -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;
	7 Feb 2013 11:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6296904"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-Nx;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:27:59 +0000
Message-ID: <1360236482-25452-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] cover: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 07 11:30:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:30: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 1U3PgT-00027P-7L; Thu, 07 Feb 2013 11:30:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3PgR-00027K-Aj
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:30:27 +0000
Received: from [193.109.254.147:7760] by server-11.bemta-14.messagelabs.com id
	D1/3F-30685-25093115; Thu, 07 Feb 2013 11:30:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360236614!3619028!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25722 invoked from network); 7 Feb 2013 11:30:19 -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;
	7 Feb 2013 11:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6296904"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-Nx;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:27:59 +0000
Message-ID: <1360236482-25452-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/4] cover: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 07 11:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11: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 1U3PgX-00027m-Lt; Thu, 07 Feb 2013 11:30:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3PgW-00027Z-5y
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:30:32 +0000
Received: from [193.109.254.147:62119] by server-3.bemta-14.messagelabs.com id
	86/6D-22141-75093115; Thu, 07 Feb 2013 11:30:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360236614!3619028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25622 invoked from network); 7 Feb 2013 11:30:18 -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;
	7 Feb 2013 11:30:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6296903"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-M7;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:27:58 +0000
Message-ID: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v7] cover: Coverage 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

Updated set of patches for coverage.

Changes:
- remove operation to check if coverage enabled
- add operation to read and reset coverage at same time
- updated utility to refrect changes above


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11: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 1U3PgX-00027m-Lt; Thu, 07 Feb 2013 11:30:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3PgW-00027Z-5y
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:30:32 +0000
Received: from [193.109.254.147:62119] by server-3.bemta-14.messagelabs.com id
	86/6D-22141-75093115; Thu, 07 Feb 2013 11:30:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360236614!3619028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25622 invoked from network); 7 Feb 2013 11:30:18 -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;
	7 Feb 2013 11:30:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6296903"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-M7;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:27:58 +0000
Message-ID: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v7] cover: Coverage 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

Updated set of patches for coverage.

Changes:
- remove operation to check if coverage enabled
- add operation to read and reset coverage at same time
- updated utility to refrect changes above


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11: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 1U3PgY-00027y-7u; Thu, 07 Feb 2013 11:30:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3PgW-00027Y-4A
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:30:32 +0000
Received: from [85.158.143.99:64412] by server-2.bemta-4.messagelabs.com id
	33/1D-01597-75093115; Thu, 07 Feb 2013 11:30:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360236628!21511712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19129 invoked from network); 7 Feb 2013 11:30:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:30:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6622610"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-Rx;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:28:02 +0000
Message-ID: <1360236482-25452-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] cover: Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  142 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 150 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..99c68fa
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,142 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-", 0);
+    else if ( strcmp(argv[1], "read-reset") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-", 1);
+    else
+        usage();
+
+    return 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 Thu Feb 07 11:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11: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 1U3PgY-00027y-7u; Thu, 07 Feb 2013 11:30:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3PgW-00027Y-4A
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:30:32 +0000
Received: from [85.158.143.99:64412] by server-2.bemta-4.messagelabs.com id
	33/1D-01597-75093115; Thu, 07 Feb 2013 11:30:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360236628!21511712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19129 invoked from network); 7 Feb 2013 11:30:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:30:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6622610"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-Rx;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:28:02 +0000
Message-ID: <1360236482-25452-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/4] cover: Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  142 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 150 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..99c68fa
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,142 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(void)
+{
+    fprintf(stderr, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(1);
+}
+
+int main(int argc, char **argv)
+{
+    gcov_init();
+
+    if ( argc < 2 )
+        usage();
+    if ( strcmp(argv[1], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[1], "read") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-", 0);
+    else if ( strcmp(argv[1], "read-reset") == 0 )
+        gcov_read(argc > 2 ? argv[2] : "-", 1);
+    else
+        usage();
+
+    return 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 Thu Feb 07 11:32:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:32: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 1U3Pi3-0002cx-TI; Thu, 07 Feb 2013 11:32:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Pi2-0002cg-E5
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:32:06 +0000
Received: from [193.109.254.147:16570] by server-2.bemta-14.messagelabs.com id
	7E/1C-16277-5B093115; Thu, 07 Feb 2013 11:32:05 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360236614!2029539!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6487 invoked from network); 7 Feb 2013 11:30:19 -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;
	7 Feb 2013 11:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6622608"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-Pg;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:28:00 +0000
Message-ID: <1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] cover: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   74 ++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 171 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..733d020
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,74 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 11:32:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:32: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 1U3Pi3-0002cx-TI; Thu, 07 Feb 2013 11:32:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Pi2-0002cg-E5
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:32:06 +0000
Received: from [193.109.254.147:16570] by server-2.bemta-14.messagelabs.com id
	7E/1C-16277-5B093115; Thu, 07 Feb 2013 11:32:05 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360236614!2029539!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6487 invoked from network); 7 Feb 2013 11:30:19 -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;
	7 Feb 2013 11:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6622608"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-Pg;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:28:00 +0000
Message-ID: <1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/4] cover: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   74 ++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 171 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..733d020
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,74 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+static unsigned num_info = 0;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+    ++num_info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 11:32:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:32: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 1U3Pi5-0002dF-BE; Thu, 07 Feb 2013 11:32:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Pi3-0002cg-U6
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:32:08 +0000
Received: from [193.109.254.147:21527] by server-2.bemta-14.messagelabs.com id
	59/2C-16277-7B093115; Thu, 07 Feb 2013 11:32:07 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360236614!2029539!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6932 invoked from network); 7 Feb 2013 11:30:28 -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;
	7 Feb 2013 11:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6622609"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-RN;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:28:01 +0000
Message-ID: <1360236482-25452-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] cover: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  161 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 ++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 331 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 733d020..e9c222c 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -63,6 +64,162 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    int reset = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+        reset = 1;
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if (reset && !ret)
+            ret = reset_counters();
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..53a192c
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..425dbbb 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..ad5cd9d 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,16 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 11:32:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:32: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 1U3Pi5-0002dF-BE; Thu, 07 Feb 2013 11:32:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Pi3-0002cg-U6
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:32:08 +0000
Received: from [193.109.254.147:21527] by server-2.bemta-14.messagelabs.com id
	59/2C-16277-7B093115; Thu, 07 Feb 2013 11:32:07 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360236614!2029539!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6932 invoked from network); 7 Feb 2013 11:30:28 -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;
	7 Feb 2013 11:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6622609"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:30:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:30:13 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3PgD-0003RA-RN;
	Thu, 07 Feb 2013 11:30:13 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:28:01 +0000
Message-ID: <1360236482-25452-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/4] cover: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  161 ++++++++++++++++++++++++++++++++++++++++++-
 xen/common/sysctl.c         |    5 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 ++++++++++
 xen/include/xen/gcov.h      |   14 ++++
 5 files changed, 331 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 733d020..e9c222c 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,9 +19,11 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
-static unsigned num_info = 0;
 
 /*
  * __gcov_init is called by gcc-generated constructor code for each object
@@ -36,7 +38,6 @@ void __gcov_init(struct gcov_info *info)
     /* add new profiling data structure to list */
     info->next = info_list;
     info_list = info;
-    ++num_info;
 }
 
 /*
@@ -63,6 +64,162 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    int reset = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+        reset = 1;
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if (reset && !ret)
+            ret = reset_counters();
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..fa3ef0a 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..53a192c
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Frediano Ziglio
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..425dbbb 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..ad5cd9d 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,16 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#else
+static inline int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    return -ENOSYS;
+}
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 11:39:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:39: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 1U3Poe-0003Kk-UI; Thu, 07 Feb 2013 11:38:56 +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 1U3Pod-0003Ka-O5
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:38:55 +0000
Received: from [85.158.143.99:52682] by server-1.bemta-4.messagelabs.com id
	08/1D-08839-E4293115; Thu, 07 Feb 2013 11:38:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360237133!30259851!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15193 invoked from network); 7 Feb 2013 11:38:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6623227"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:38:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:38:24 -0500
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 1U3Po8-0003YP-Be;
	Thu, 07 Feb 2013 11:38:24 +0000
Message-ID: <51139077.4070309@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:31:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-5-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1360173877-12696-5-git-send-email-roger.pau@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/4] xl: add vif.default.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-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

T24gMDYvMDIvMTMgMTg6MDQsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBSZXBsYWNlIHZpZnNj
cmlwdCB3aXRoIHZpZi5kZWZhdWx0LnNjcmlwdC4gVGhlIG9sZCBjb25maWcgb3B0aW9uIGlzCj4g
a2VwdCBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuCj4KPiBTaWduZWQtb2ZmLWJ5OiBSb2dl
ciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBDYzogR2VvcmdlIER1bmxhcCA8
Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgo+IENjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVs
bEBjaXRyaXguY29tPgoKSSBoYXZlbid0IGRvbmUgYSBkZXRhaWxlZCByZXZpZXcgb2YgdGhlIGNv
ZGUsIGJ1dCB0aGUgbmFtaW5nIGxvb2tzIGZpbmUgCnRvIG1lLgoKICAtR2VvcmdlCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:39:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:39: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 1U3Poe-0003Kk-UI; Thu, 07 Feb 2013 11:38:56 +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 1U3Pod-0003Ka-O5
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:38:55 +0000
Received: from [85.158.143.99:52682] by server-1.bemta-4.messagelabs.com id
	08/1D-08839-E4293115; Thu, 07 Feb 2013 11:38:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360237133!30259851!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15193 invoked from network); 7 Feb 2013 11:38:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6623227"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:38:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:38:24 -0500
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 1U3Po8-0003YP-Be;
	Thu, 07 Feb 2013 11:38:24 +0000
Message-ID: <51139077.4070309@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:31:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-5-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1360173877-12696-5-git-send-email-roger.pau@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 4/4] xl: add vif.default.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-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

T24gMDYvMDIvMTMgMTg6MDQsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBSZXBsYWNlIHZpZnNj
cmlwdCB3aXRoIHZpZi5kZWZhdWx0LnNjcmlwdC4gVGhlIG9sZCBjb25maWcgb3B0aW9uIGlzCj4g
a2VwdCBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuCj4KPiBTaWduZWQtb2ZmLWJ5OiBSb2dl
ciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBDYzogR2VvcmdlIER1bmxhcCA8
Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPgo+IENjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVs
bEBjaXRyaXguY29tPgoKSSBoYXZlbid0IGRvbmUgYSBkZXRhaWxlZCByZXZpZXcgb2YgdGhlIGNv
ZGUsIGJ1dCB0aGUgbmFtaW5nIGxvb2tzIGZpbmUgCnRvIG1lLgoKICAtR2VvcmdlCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:55:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11: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 1U3Q4e-0004Rq-7e; Thu, 07 Feb 2013 11:55:28 +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 1U3Q4d-0004Rl-6R
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:55:27 +0000
Received: from [85.158.143.99:23790] by server-2.bemta-4.messagelabs.com id
	9D/21-01597-E2693115; Thu, 07 Feb 2013 11:55:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360238114!21516361!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6288 invoked from network); 7 Feb 2013 11:55:24 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:55:24 -0000
Received: by mail-wg0-f50.google.com with SMTP id es5so1897397wgb.17
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 03:55:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=O4fwTK/fgw+uOMuEu0RVrgsp8L2ShEtPySZoavzLwR8=;
	b=prt0fTvCRGTSU8u6kCJUbmdLoGQGaXrpKxHRrnyYjW2gSuiLhpUyWciAPsWmBEYS0V
	gYBR5xN0ZTIDGfU40h1XgX1K/2SmcAlkmMuOwObj1eY3mTwwssS1TLn7nKOinXJxJa8v
	+q52NM0wXfbd37iMB/45dWNrTK5dYrI4JhNWciD2r5kTjZdeylI5Tvjo6yEb5NH6YXEh
	KsOrHgRzR2XapH1at7+IoismBgx07PRq7V33LnocGSXFCQY7BeB4gsezBS9UKIftR1vd
	UVDIwXUR9dJb4LQL/5aap4tB2yL+bZvj1Foj094R1MaTC5fBWb55VKnFJZFyoEld7e9n
	gOIQ==
X-Received: by 10.194.108.229 with SMTP id hn5mr2177883wjb.8.1360238114837;
	Thu, 07 Feb 2013 03:55:14 -0800 (PST)
Received: from [192.168.1.94] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id n10sm8900429wia.0.2013.02.07.03.55.10
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 03:55:13 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 07 Feb 2013 11:55:07 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CD39469B.4B817%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Compile errors with gcc 4.8
Thread-Index: Ac4FKfkFFZlTBk27LUaOPW/9Q+p7sQ==
In-Reply-To: <5113887F02000078000BCC20@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@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] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/02/2013 09:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> Actually, I'm of the opposite opinion - it should be in other places
> too that handles don't get needlessly defined by the public
> headers. They should get defined only when there actually is a
> use for them. Everything else can be defined where actually
> consumed, as in this case: For one, a handle of a compat_*
> type can't be defined in a public header anyway, as the compat
> types don't get defined there. And then, as you say, the oddity
> of this type makes it desirable to scope restrict it as much as
> possible.
> 
> Now, for the actual solution, I'd prefer the -Wno-... Option

+1. It's not a compiler warning that I care about.

 -- Keir

> suggested above, or as a second best choice generalizing the
> solution suggested by Michael, applying the attribute in
> DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
> attaching it in to the use of the macro just happens to work,
> but isn't guaranteed to in the future: Switching around the
> order of the two lines of the expansion
> 
> #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
>     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> 
> or adding a third (say, volatile) one would re-expose the
> problem.
> 
> Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:55:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11: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 1U3Q4e-0004Rq-7e; Thu, 07 Feb 2013 11:55:28 +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 1U3Q4d-0004Rl-6R
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:55:27 +0000
Received: from [85.158.143.99:23790] by server-2.bemta-4.messagelabs.com id
	9D/21-01597-E2693115; Thu, 07 Feb 2013 11:55:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360238114!21516361!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6288 invoked from network); 7 Feb 2013 11:55:24 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:55:24 -0000
Received: by mail-wg0-f50.google.com with SMTP id es5so1897397wgb.17
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 03:55:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=O4fwTK/fgw+uOMuEu0RVrgsp8L2ShEtPySZoavzLwR8=;
	b=prt0fTvCRGTSU8u6kCJUbmdLoGQGaXrpKxHRrnyYjW2gSuiLhpUyWciAPsWmBEYS0V
	gYBR5xN0ZTIDGfU40h1XgX1K/2SmcAlkmMuOwObj1eY3mTwwssS1TLn7nKOinXJxJa8v
	+q52NM0wXfbd37iMB/45dWNrTK5dYrI4JhNWciD2r5kTjZdeylI5Tvjo6yEb5NH6YXEh
	KsOrHgRzR2XapH1at7+IoismBgx07PRq7V33LnocGSXFCQY7BeB4gsezBS9UKIftR1vd
	UVDIwXUR9dJb4LQL/5aap4tB2yL+bZvj1Foj094R1MaTC5fBWb55VKnFJZFyoEld7e9n
	gOIQ==
X-Received: by 10.194.108.229 with SMTP id hn5mr2177883wjb.8.1360238114837;
	Thu, 07 Feb 2013 03:55:14 -0800 (PST)
Received: from [192.168.1.94] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id n10sm8900429wia.0.2013.02.07.03.55.10
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 03:55:13 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 07 Feb 2013 11:55:07 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CD39469B.4B817%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Compile errors with gcc 4.8
Thread-Index: Ac4FKfkFFZlTBk27LUaOPW/9Q+p7sQ==
In-Reply-To: <5113887F02000078000BCC20@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@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] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/02/2013 09:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> Actually, I'm of the opposite opinion - it should be in other places
> too that handles don't get needlessly defined by the public
> headers. They should get defined only when there actually is a
> use for them. Everything else can be defined where actually
> consumed, as in this case: For one, a handle of a compat_*
> type can't be defined in a public header anyway, as the compat
> types don't get defined there. And then, as you say, the oddity
> of this type makes it desirable to scope restrict it as much as
> possible.
> 
> Now, for the actual solution, I'd prefer the -Wno-... Option

+1. It's not a compiler warning that I care about.

 -- Keir

> suggested above, or as a second best choice generalizing the
> solution suggested by Michael, applying the attribute in
> DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
> attaching it in to the use of the macro just happens to work,
> but isn't guaranteed to in the future: Switching around the
> order of the two lines of the expansion
> 
> #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
>     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> 
> or adding a third (say, volatile) one would re-expose the
> problem.
> 
> Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:57:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:57: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 1U3Q6r-0004Y1-Rd; Thu, 07 Feb 2013 11:57: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 1U3Q6q-0004Xt-VC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:57:45 +0000
Received: from [85.158.143.99:37349] by server-3.bemta-4.messagelabs.com id
	E9/5F-08920-7B693115; Thu, 07 Feb 2013 11:57:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360238261!21516822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16290 invoked from network); 7 Feb 2013 11:57:42 -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;
	7 Feb 2013 11:57:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6298781"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:57:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:57:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U3Q6m-0003pR-2P;
	Thu, 07 Feb 2013 11:57:40 +0000
Message-ID: <1360238260.2536.22.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 7 Feb 2013 11:57:40 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > sizeof(unsigned long) * 64)
> > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > +sizeof(unsigned long) * 64)
> > > >
> > > > We did a bit of header change to make the ARM code always use
> > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> > xen_mfn_t typdefs.
> > > >
> > > > Any chance you can do that here? That way on ARM - irregardless if
> > > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > > >
> > >
> > > I don't think so. The reason to use unsigned long here is to guarantee
> > > each selector (in 2-level case there is only L1 selector) fits into a
> > > word.
> > 
> 
> That's still going to be a problem with Windows drivers. Unfortunately MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is word size is a pointer. Any chance we can use uintptr_t rather than an unsigned long? (At the moment I have to sed all the public headers to replace long with LONG_PTR and it's a PITA).
> 

TBH I don't know much about Windows. But are you suggesting replace all
the relevant bit in the header or just the specific event channel
interface?


Wei.
>   Paul



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 11:57:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 11:57: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 1U3Q6r-0004Y1-Rd; Thu, 07 Feb 2013 11:57: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 1U3Q6q-0004Xt-VC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 11:57:45 +0000
Received: from [85.158.143.99:37349] by server-3.bemta-4.messagelabs.com id
	E9/5F-08920-7B693115; Thu, 07 Feb 2013 11:57:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360238261!21516822!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16290 invoked from network); 7 Feb 2013 11:57:42 -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;
	7 Feb 2013 11:57:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6298781"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 11:57:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 06:57:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U3Q6m-0003pR-2P;
	Thu, 07 Feb 2013 11:57:40 +0000
Message-ID: <1360238260.2536.22.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 7 Feb 2013 11:57:40 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > sizeof(unsigned long) * 64)
> > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > +sizeof(unsigned long) * 64)
> > > >
> > > > We did a bit of header change to make the ARM code always use
> > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> > xen_mfn_t typdefs.
> > > >
> > > > Any chance you can do that here? That way on ARM - irregardless if
> > > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > > >
> > >
> > > I don't think so. The reason to use unsigned long here is to guarantee
> > > each selector (in 2-level case there is only L1 selector) fits into a
> > > word.
> > 
> 
> That's still going to be a problem with Windows drivers. Unfortunately MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is word size is a pointer. Any chance we can use uintptr_t rather than an unsigned long? (At the moment I have to sed all the public headers to replace long with LONG_PTR and it's a PITA).
> 

TBH I don't know much about Windows. But are you suggesting replace all
the relevant bit in the header or just the specific event channel
interface?


Wei.
>   Paul



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:05:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QDx-0005DM-2p; Thu, 07 Feb 2013 12:05:05 +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 1U3QDv-0005DF-ME
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:05:03 +0000
Received: from [193.109.254.147:20008] by server-3.bemta-14.messagelabs.com id
	06/BA-22141-E6893115; Thu, 07 Feb 2013 12:05:02 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360238701!9302114!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12487 invoked from network); 7 Feb 2013 12:05:02 -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;
	7 Feb 2013 12:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6625304"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 12:05:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 07:05:00 -0500
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 1U3QDr-00040n-Vs;
	Thu, 07 Feb 2013 12:04:59 +0000
Message-ID: <511396B2.3030804@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:57:38 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] cover: Coverage 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-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 07/02/13 11:27, Frediano Ziglio wrote:
> Updated set of patches for coverage.
>
> Changes:
> - remove operation to check if coverage enabled
> - add operation to read and reset coverage at same time
> - updated utility to refrect changes above
>

I've done a once-over and in principle I think this is a good series.  
Thanks for doing it -- I think Xen has needed this for some time.  Just 
a couple of high-level comments (and I haven't been following the 
discussion, so please forgive me if I'm contradicting something someone 
said somewhere else):

First, re the name -- is there any reason not to call it "gcov" (or 
"xgcov" or something like that) in the patch series and the Xen 
command-line option?  Since we're using the gcov format and the intent 
(I presume) is to use the gcov tools to do the actual analysis,

Secondly, there doesn't seem to be any documentation.  A definition of 
the Xen command-line term is an absolute minimum, and a brief markdown 
how-to explaining how to enable the option and use it would be much 
appreciated.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:05:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QDx-0005DM-2p; Thu, 07 Feb 2013 12:05:05 +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 1U3QDv-0005DF-ME
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:05:03 +0000
Received: from [193.109.254.147:20008] by server-3.bemta-14.messagelabs.com id
	06/BA-22141-E6893115; Thu, 07 Feb 2013 12:05:02 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360238701!9302114!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12487 invoked from network); 7 Feb 2013 12:05:02 -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;
	7 Feb 2013 12:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="6625304"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 12:05:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 07:05:00 -0500
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 1U3QDr-00040n-Vs;
	Thu, 07 Feb 2013 12:04:59 +0000
Message-ID: <511396B2.3030804@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:57:38 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] cover: Coverage 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-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 07/02/13 11:27, Frediano Ziglio wrote:
> Updated set of patches for coverage.
>
> Changes:
> - remove operation to check if coverage enabled
> - add operation to read and reset coverage at same time
> - updated utility to refrect changes above
>

I've done a once-over and in principle I think this is a good series.  
Thanks for doing it -- I think Xen has needed this for some time.  Just 
a couple of high-level comments (and I haven't been following the 
discussion, so please forgive me if I'm contradicting something someone 
said somewhere else):

First, re the name -- is there any reason not to call it "gcov" (or 
"xgcov" or something like that) in the patch series and the Xen 
command-line option?  Since we're using the gcov format and the intent 
(I presume) is to use the gcov tools to do the actual analysis,

Secondly, there doesn't seem to be any documentation.  A definition of 
the Xen command-line term is an absolute minimum, and a brief markdown 
how-to explaining how to enable the option and use it would be much 
appreciated.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:08:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:08: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 1U3QGd-0005JW-LC; Thu, 07 Feb 2013 12:07:51 +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 1U3QGc-0005JR-Is
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:07:50 +0000
Received: from [85.158.143.35:21869] by server-1.bemta-4.messagelabs.com id
	E8/0A-08839-51993115; Thu, 07 Feb 2013 12:07:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360238822!13343563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 7 Feb 2013 12:07:05 -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;
	7 Feb 2013 12:07:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6299744"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 12:07:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 07:07:00 -0500
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 1U3QFo-00042b-Ei;
	Thu, 07 Feb 2013 12:07:00 +0000
Message-ID: <5113972B.3090802@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:59:39 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] cover: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 07/02/13 11:28, Frediano Ziglio wrote:
> diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
> new file mode 100644
> index 0000000..733d020
> --- /dev/null
> +++ b/xen/common/gcov/gcov.c
> @@ -0,0 +1,74 @@
> +/*
> + *  This code maintains a list of active profiling data structures.
> + *
> + *    Copyright IBM Corp. 2009
> + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> + *
> + *    Uses gcc-internal data definitions.
> + *    Based on the gcov-kernel patch by:
> + *       Hubertus Franke <frankeh@us.ibm.com>
> + *       Nigel Hinds <nhinds@us.ibm.com>
> + *       Rajan Ravindran <rajancr@us.ibm.com>
> + *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> + *       Paul Larson
> + */
> +
> +#include <xen/config.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/hypercall.h>
> +#include <xen/gcov.h>
> +#include <xen/errno.h>
> +
> +static struct gcov_info *info_list;
> +static unsigned num_info = 0;

This is a bit of a nit, but you seem to remove this variable in the next 
patch, which is bad form.  If it's not necessary, just don't add it in 
this patch.

> +
> +/*
> + * __gcov_init is called by gcc-generated constructor code for each object
> + * file compiled with -fprofile-arcs.
> + *
> + * Although this function is called only during initialization is called from
> + * a .text section which is still present after initialization so not declare
> + * as __init.
> + */
> +void __gcov_init(struct gcov_info *info)
> +{
> +    /* add new profiling data structure to list */
> +    info->next = info_list;
> +    info_list = info;
> +    ++num_info;

Ditto.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:08:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:08: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 1U3QGd-0005JW-LC; Thu, 07 Feb 2013 12:07:51 +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 1U3QGc-0005JR-Is
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:07:50 +0000
Received: from [85.158.143.35:21869] by server-1.bemta-4.messagelabs.com id
	E8/0A-08839-51993115; Thu, 07 Feb 2013 12:07:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360238822!13343563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 7 Feb 2013 12:07:05 -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;
	7 Feb 2013 12:07:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6299744"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 12:07:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 07:07:00 -0500
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 1U3QFo-00042b-Ei;
	Thu, 07 Feb 2013 12:07:00 +0000
Message-ID: <5113972B.3090802@eu.citrix.com>
Date: Thu, 7 Feb 2013 11:59:39 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] cover: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 07/02/13 11:28, Frediano Ziglio wrote:
> diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
> new file mode 100644
> index 0000000..733d020
> --- /dev/null
> +++ b/xen/common/gcov/gcov.c
> @@ -0,0 +1,74 @@
> +/*
> + *  This code maintains a list of active profiling data structures.
> + *
> + *    Copyright IBM Corp. 2009
> + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> + *
> + *    Uses gcc-internal data definitions.
> + *    Based on the gcov-kernel patch by:
> + *       Hubertus Franke <frankeh@us.ibm.com>
> + *       Nigel Hinds <nhinds@us.ibm.com>
> + *       Rajan Ravindran <rajancr@us.ibm.com>
> + *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> + *       Paul Larson
> + */
> +
> +#include <xen/config.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/hypercall.h>
> +#include <xen/gcov.h>
> +#include <xen/errno.h>
> +
> +static struct gcov_info *info_list;
> +static unsigned num_info = 0;

This is a bit of a nit, but you seem to remove this variable in the next 
patch, which is bad form.  If it's not necessary, just don't add it in 
this patch.

> +
> +/*
> + * __gcov_init is called by gcc-generated constructor code for each object
> + * file compiled with -fprofile-arcs.
> + *
> + * Although this function is called only during initialization is called from
> + * a .text section which is still present after initialization so not declare
> + * as __init.
> + */
> +void __gcov_init(struct gcov_info *info)
> +{
> +    /* add new profiling data structure to list */
> +    info->next = info_list;
> +    info_list = info;
> +    ++num_info;

Ditto.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:09:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:09: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 1U3QIP-0005P2-63; Thu, 07 Feb 2013 12:09: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 1U3QIO-0005Oq-Bo
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:09:40 +0000
Received: from [85.158.139.83:20853] by server-14.bemta-5.messagelabs.com id
	DB/E0-06967-38993115; Thu, 07 Feb 2013 12:09:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360238978!20366795!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10564 invoked from network); 7 Feb 2013 12:09:39 -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; 7 Feb 2013 12:09:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3QIM-000KMV-Dm; Thu, 07 Feb 2013 12:09:38 +0000
Date: Thu, 7 Feb 2013 12:09:38 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207120938.GD77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/45] xen: arm: do not pass a machine ID 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

At 15:56 +0000 on 23 Jan (1358956570), Ian Campbell wrote:
> Xen relies on DTB and we pass in a suitable device-tree so we don't
> need to (and shouldn't) pretend to be a Versatile Express here.
> 
> We already don't pass a machine ID to domU in the same way.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 12:09:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:09: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 1U3QIP-0005P2-63; Thu, 07 Feb 2013 12:09: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 1U3QIO-0005Oq-Bo
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:09:40 +0000
Received: from [85.158.139.83:20853] by server-14.bemta-5.messagelabs.com id
	DB/E0-06967-38993115; Thu, 07 Feb 2013 12:09:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360238978!20366795!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10564 invoked from network); 7 Feb 2013 12:09:39 -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; 7 Feb 2013 12:09:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3QIM-000KMV-Dm; Thu, 07 Feb 2013 12:09:38 +0000
Date: Thu, 7 Feb 2013 12:09:38 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207120938.GD77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/45] xen: arm: do not pass a machine ID 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

At 15:56 +0000 on 23 Jan (1358956570), Ian Campbell wrote:
> Xen relies on DTB and we pass in a suitable device-tree so we don't
> need to (and shouldn't) pretend to be a Versatile Express here.
> 
> We already don't pass a machine ID to domU in the same way.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 12:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:10: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 1U3QIg-0005Qr-JU; Thu, 07 Feb 2013 12:09: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 1U3QIe-0005Qb-TS
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:09:57 +0000
Received: from [193.109.254.147:47907] by server-13.bemta-14.messagelabs.com
	id 56/49-30639-49993115; Thu, 07 Feb 2013 12:09:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360238919!10388371!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9052 invoked from network); 7 Feb 2013 12:08:40 -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; 7 Feb 2013 12:08:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3QHP-000KLv-EG; Thu, 07 Feb 2013 12:08:39 +0000
Date: Thu, 7 Feb 2013 12:08:39 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207120839.GC77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/45] xen: arm: rename atag_paddr argument
	fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956569), Ian Campbell wrote:
> We don't support ATAGs and this is always actually an FDT address.

Should we also change the code in head.S that call this an ATAG?

Tim.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/setup.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7e35860..0837db3 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -329,7 +329,7 @@ void __init setup_cache(void)
>  
>  /* C entry point for boot CPU */
>  void __init start_xen(unsigned long boot_phys_offset,
> -                      unsigned long atag_paddr,
> +                      unsigned long fdt_paddr,
>                        unsigned long cpuid)
>  {
>      void *fdt;
> @@ -341,7 +341,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>      smp_clear_cpu_maps();
>  
>      fdt = (void *)BOOT_MISC_VIRT_START
> -        + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
> +        + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
>      fdt_size = device_tree_early_init(fdt);
>  
>      cpus = smp_get_max_cpus();
> @@ -365,7 +365,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>      idle_vcpu[0] = current;
>  
> -    setup_mm(atag_paddr, fdt_size);
> +    setup_mm(fdt_paddr, fdt_size);
>  
>      /* Setup Hyp vector base */
>      WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> -- 
> 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 Thu Feb 07 12:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:10: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 1U3QIg-0005Qr-JU; Thu, 07 Feb 2013 12:09: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 1U3QIe-0005Qb-TS
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:09:57 +0000
Received: from [193.109.254.147:47907] by server-13.bemta-14.messagelabs.com
	id 56/49-30639-49993115; Thu, 07 Feb 2013 12:09:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360238919!10388371!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9052 invoked from network); 7 Feb 2013 12:08:40 -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; 7 Feb 2013 12:08:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3QHP-000KLv-EG; Thu, 07 Feb 2013 12:08:39 +0000
Date: Thu, 7 Feb 2013 12:08:39 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207120839.GC77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/45] xen: arm: rename atag_paddr argument
	fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956569), Ian Campbell wrote:
> We don't support ATAGs and this is always actually an FDT address.

Should we also change the code in head.S that call this an ATAG?

Tim.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/setup.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7e35860..0837db3 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -329,7 +329,7 @@ void __init setup_cache(void)
>  
>  /* C entry point for boot CPU */
>  void __init start_xen(unsigned long boot_phys_offset,
> -                      unsigned long atag_paddr,
> +                      unsigned long fdt_paddr,
>                        unsigned long cpuid)
>  {
>      void *fdt;
> @@ -341,7 +341,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>      smp_clear_cpu_maps();
>  
>      fdt = (void *)BOOT_MISC_VIRT_START
> -        + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
> +        + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
>      fdt_size = device_tree_early_init(fdt);
>  
>      cpus = smp_get_max_cpus();
> @@ -365,7 +365,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>      idle_vcpu[0] = current;
>  
> -    setup_mm(atag_paddr, fdt_size);
> +    setup_mm(fdt_paddr, fdt_size);
>  
>      /* Setup Hyp vector base */
>      WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> -- 
> 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 Thu Feb 07 12:14:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QNB-00060Z-Ar; Thu, 07 Feb 2013 12:14:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3QNA-00060R-JN; Thu, 07 Feb 2013 12:14:36 +0000
Received: from [85.158.137.99:25314] by server-16.bemta-3.messagelabs.com id
	EE/70-02727-BAA93115; Thu, 07 Feb 2013 12:14:35 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360239274!18080439!1
X-Originating-IP: [192.134.164.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27579 invoked from network); 7 Feb 2013 12:14:35 -0000
Received: from mail3-relais-sop.national.inria.fr (HELO
	mail3-relais-sop.national.inria.fr) (192.134.164.104)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:14:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355094000"; 
   d="scan'208";a="1400556"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 13:07:41 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3QN8-0003dk-CH; Thu, 07 Feb 2013 13:14:34 +0100
Date: Thu, 7 Feb 2013 13:14:34 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <20130207121434.GD9769@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130207110347.GX6193@type.bordeaux.inria.fr>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :
> tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
> > I read in the wiki that stubdomains aren't support on NetBSD. Will subd=
oms be
> > supported on NetBSD? Is someone working on that topic actually?
> =

> I see no reason why it should be hard to do it,

Except that you need a gcc compiler which is able to build mini-os &
such, but I guess this is already the case?  I see that there is already
a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody has
already given a try on FreeBSD, and NetBSD shouldn't be very far.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:14:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QNB-00060Z-Ar; Thu, 07 Feb 2013 12:14:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3QNA-00060R-JN; Thu, 07 Feb 2013 12:14:36 +0000
Received: from [85.158.137.99:25314] by server-16.bemta-3.messagelabs.com id
	EE/70-02727-BAA93115; Thu, 07 Feb 2013 12:14:35 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360239274!18080439!1
X-Originating-IP: [192.134.164.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27579 invoked from network); 7 Feb 2013 12:14:35 -0000
Received: from mail3-relais-sop.national.inria.fr (HELO
	mail3-relais-sop.national.inria.fr) (192.134.164.104)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:14:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355094000"; 
   d="scan'208";a="1400556"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 13:07:41 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3QN8-0003dk-CH; Thu, 07 Feb 2013 13:14:34 +0100
Date: Thu, 7 Feb 2013 13:14:34 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <20130207121434.GD9769@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130207110347.GX6193@type.bordeaux.inria.fr>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :
> tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
> > I read in the wiki that stubdomains aren't support on NetBSD. Will subd=
oms be
> > supported on NetBSD? Is someone working on that topic actually?
> =

> I see no reason why it should be hard to do it,

Except that you need a gcc compiler which is able to build mini-os &
such, but I guess this is already the case?  I see that there is already
a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody has
already given a try on FreeBSD, and NetBSD shouldn't be very far.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:18:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:18: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 1U3QR0-0006Ly-Pb; Thu, 07 Feb 2013 12:18: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 1U3QQy-0006Lp-Bq
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:18:32 +0000
Received: from [85.158.139.211:53966] by server-16.bemta-5.messagelabs.com id
	2B/B7-14948-79B93115; Thu, 07 Feb 2013 12:18:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360239510!21099977!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2622 invoked from network); 7 Feb 2013 12:18:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1235806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:18: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.297.1; Thu, 7 Feb 2013
	12:18:30 +0000
Message-ID: <1360239508.32479.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 12:18:28 +0000
In-Reply-To: <20130207120839.GC77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
	<20130207120839.GC77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 03/45] xen: arm: rename atag_paddr argument
 fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 12:08 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956569), Ian Campbell wrote:
> > We don't support ATAGs and this is always actually an FDT address.
> 
> Should we also change the code in head.S that call this an ATAG?

Yes, I think we should (thought I had actually!). Looks like I missed
smpboot.c:start_secondary too (which doesn't use it but prototype is
supposed to match).

Incrementally I think that would just be:

diff -r 8e8a289bc6c6 xen/arch/arm/arm32/head.S
--- a/xen/arch/arm/arm32/head.S	Thu Dec 20 10:51:55 2012 +0000
+++ b/xen/arch/arm/arm32/head.S	Thu Feb 07 12:16:31 2013 +0000
@@ -73,7 +73,7 @@ past_zImage:
 
         /* Save the bootloader arguments in less-clobberable registers */
         mov   r7, r1                 /* r7 := ARM-linux machine type */
-        mov   r8, r2                 /* r8 := ATAG base address */
+        mov   r8, r2                 /* r8 := DTB base address */
 
         /* Find out where we are */
         ldr   r0, =start
@@ -335,7 +335,7 @@ launch:
         sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
         mov   r0, r10                /* Marshal args: - phys_offset */
         mov   r1, r7                 /*               - machine type */
-        mov   r2, r8                 /*               - ATAG address */
+        mov   r2, r8                 /*               - DTB address */
         movs  r3, r12                /*               - CPU ID */
         beq   start_xen              /* and disappear into the land of C */
         b     start_secondary        /* (to the appropriate entry point) */
diff -r 8e8a289bc6c6 xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Dec 20 10:51:55 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 07 12:16:31 2013 +0000
@@ -133,7 +133,7 @@ make_cpus_ready(unsigned int max_cpus, u
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
                                unsigned long arm_type,
-                               unsigned long atag_paddr,
+                               unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:18:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:18: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 1U3QR0-0006Ly-Pb; Thu, 07 Feb 2013 12:18: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 1U3QQy-0006Lp-Bq
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:18:32 +0000
Received: from [85.158.139.211:53966] by server-16.bemta-5.messagelabs.com id
	2B/B7-14948-79B93115; Thu, 07 Feb 2013 12:18:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360239510!21099977!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2622 invoked from network); 7 Feb 2013 12:18:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1235806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:18: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.297.1; Thu, 7 Feb 2013
	12:18:30 +0000
Message-ID: <1360239508.32479.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 12:18:28 +0000
In-Reply-To: <20130207120839.GC77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
	<20130207120839.GC77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 03/45] xen: arm: rename atag_paddr argument
 fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 12:08 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956569), Ian Campbell wrote:
> > We don't support ATAGs and this is always actually an FDT address.
> 
> Should we also change the code in head.S that call this an ATAG?

Yes, I think we should (thought I had actually!). Looks like I missed
smpboot.c:start_secondary too (which doesn't use it but prototype is
supposed to match).

Incrementally I think that would just be:

diff -r 8e8a289bc6c6 xen/arch/arm/arm32/head.S
--- a/xen/arch/arm/arm32/head.S	Thu Dec 20 10:51:55 2012 +0000
+++ b/xen/arch/arm/arm32/head.S	Thu Feb 07 12:16:31 2013 +0000
@@ -73,7 +73,7 @@ past_zImage:
 
         /* Save the bootloader arguments in less-clobberable registers */
         mov   r7, r1                 /* r7 := ARM-linux machine type */
-        mov   r8, r2                 /* r8 := ATAG base address */
+        mov   r8, r2                 /* r8 := DTB base address */
 
         /* Find out where we are */
         ldr   r0, =start
@@ -335,7 +335,7 @@ launch:
         sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
         mov   r0, r10                /* Marshal args: - phys_offset */
         mov   r1, r7                 /*               - machine type */
-        mov   r2, r8                 /*               - ATAG address */
+        mov   r2, r8                 /*               - DTB address */
         movs  r3, r12                /*               - CPU ID */
         beq   start_xen              /* and disappear into the land of C */
         b     start_secondary        /* (to the appropriate entry point) */
diff -r 8e8a289bc6c6 xen/arch/arm/smpboot.c
--- a/xen/arch/arm/smpboot.c	Thu Dec 20 10:51:55 2012 +0000
+++ b/xen/arch/arm/smpboot.c	Thu Feb 07 12:16:31 2013 +0000
@@ -133,7 +133,7 @@ make_cpus_ready(unsigned int max_cpus, u
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
                                unsigned long arm_type,
-                               unsigned long atag_paddr,
+                               unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:20:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QT5-0006U3-Bn; Thu, 07 Feb 2013 12:20: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 1U3QT4-0006Tt-3z
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:20:42 +0000
Received: from [85.158.143.35:13108] by server-1.bemta-4.messagelabs.com id
	CA/5E-08839-91C93115; Thu, 07 Feb 2013 12:20:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360239626!14066141!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29900 invoked from network); 7 Feb 2013 12:20:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:20:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1235907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:20: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.297.1; Thu, 7 Feb 2013
	12:20:26 +0000
Message-ID: <1360239625.32479.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 7 Feb 2013 12:20:25 +0000
In-Reply-To: <1358956611-8432-2-git-send-email-ian.campbell@citrix.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-2-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/45] xen: arm32: Don't bother with the
 bootloader provided ARM-Linux machine 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 Wed, 2013-01-23 at 15:56 +0000, Ian Campbell wrote:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index e1ab7f6..7e35860 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -329,7 +329,6 @@ void __init setup_cache(void)
>  
>  /* C entry point for boot CPU */
>  void __init start_xen(unsigned long boot_phys_offset,
> -                      unsigned long arm_type,
>                        unsigned long atag_paddr,
>                        unsigned long cpuid)
>  {

Also needed in smpboot.c:start_secondary:

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d72b248..4850567 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -133,8 +133,8 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
-                               unsigned long arm_type,
+                               unsigned long dtb_paddr,
                                unsigned long atag_paddr,
                                unsigned long cpuid)
 {
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:20:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QT5-0006U3-Bn; Thu, 07 Feb 2013 12:20: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 1U3QT4-0006Tt-3z
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:20:42 +0000
Received: from [85.158.143.35:13108] by server-1.bemta-4.messagelabs.com id
	CA/5E-08839-91C93115; Thu, 07 Feb 2013 12:20:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360239626!14066141!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29900 invoked from network); 7 Feb 2013 12:20:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:20:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1235907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:20: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.297.1; Thu, 7 Feb 2013
	12:20:26 +0000
Message-ID: <1360239625.32479.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 7 Feb 2013 12:20:25 +0000
In-Reply-To: <1358956611-8432-2-git-send-email-ian.campbell@citrix.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-2-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/45] xen: arm32: Don't bother with the
 bootloader provided ARM-Linux machine 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 Wed, 2013-01-23 at 15:56 +0000, Ian Campbell wrote:
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index e1ab7f6..7e35860 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -329,7 +329,6 @@ void __init setup_cache(void)
>  
>  /* C entry point for boot CPU */
>  void __init start_xen(unsigned long boot_phys_offset,
> -                      unsigned long arm_type,
>                        unsigned long atag_paddr,
>                        unsigned long cpuid)
>  {

Also needed in smpboot.c:start_secondary:

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d72b248..4850567 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -133,8 +133,8 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
-                               unsigned long arm_type,
+                               unsigned long dtb_paddr,
                                unsigned long atag_paddr,
                                unsigned long cpuid)
 {
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:23:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QVk-0006gR-UK; Thu, 07 Feb 2013 12:23: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 1U3QVj-0006gE-9m
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:23:27 +0000
Received: from [85.158.143.35:23648] by server-2.bemta-4.messagelabs.com id
	1A/1E-01597-EBC93115; Thu, 07 Feb 2013 12:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360239799!14066585!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9451 invoked from network); 7 Feb 2013 12:23:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:23:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1235995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:23: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.297.1; Thu, 7 Feb 2013
	12:23:19 +0000
Message-ID: <1360239797.32479.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 7 Feb 2013 12:23:17 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > sizeof(unsigned long) * 64)
> > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > +sizeof(unsigned long) * 64)
> > > >
> > > > We did a bit of header change to make the ARM code always use
> > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> > xen_mfn_t typdefs.
> > > >
> > > > Any chance you can do that here? That way on ARM - irregardless if
> > > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > > >
> > >
> > > I don't think so. The reason to use unsigned long here is to guarantee
> > > each selector (in 2-level case there is only L1 selector) fits into a
> > > word.
> > 
> 
> That's still going to be a problem with Windows drivers. Unfortunately
> MSVC uses a 64-bit model where longs are still 32-bit. The only thing
> that is word size is a pointer. Any chance we can use uintptr_t rather
> than an unsigned long? (At the moment I have to sed all the public
> headers to replace long with LONG_PTR and it's a PITA).

It's considered pretty normal these days that users of these headers
import them and manipulate them to fit their environment (often by hand
and manual synching).

For example in the Linux copy we remove the struct typedefs because
Linux coding style doesn't use them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:23:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QVk-0006gR-UK; Thu, 07 Feb 2013 12:23: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 1U3QVj-0006gE-9m
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:23:27 +0000
Received: from [85.158.143.35:23648] by server-2.bemta-4.messagelabs.com id
	1A/1E-01597-EBC93115; Thu, 07 Feb 2013 12:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360239799!14066585!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9451 invoked from network); 7 Feb 2013 12:23:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:23:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1235995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:23: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.297.1; Thu, 7 Feb 2013
	12:23:19 +0000
Message-ID: <1360239797.32479.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Thu, 7 Feb 2013 12:23:17 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > sizeof(unsigned long) * 64)
> > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > +sizeof(unsigned long) * 64)
> > > >
> > > > We did a bit of header change to make the ARM code always use
> > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> > xen_mfn_t typdefs.
> > > >
> > > > Any chance you can do that here? That way on ARM - irregardless if
> > > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > > >
> > >
> > > I don't think so. The reason to use unsigned long here is to guarantee
> > > each selector (in 2-level case there is only L1 selector) fits into a
> > > word.
> > 
> 
> That's still going to be a problem with Windows drivers. Unfortunately
> MSVC uses a 64-bit model where longs are still 32-bit. The only thing
> that is word size is a pointer. Any chance we can use uintptr_t rather
> than an unsigned long? (At the moment I have to sed all the public
> headers to replace long with LONG_PTR and it's a PITA).

It's considered pretty normal these days that users of these headers
import them and manipulate them to fit their environment (often by hand
and manual synching).

For example in the Linux copy we remove the struct typedefs because
Linux coding style doesn't use them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:25:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QXI-0006qv-Ke; Thu, 07 Feb 2013 12:25:04 +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 1U3QXI-0006qj-1p; Thu, 07 Feb 2013 12:25:04 +0000
Received: from [85.158.143.99:44843] by server-2.bemta-4.messagelabs.com id
	22/80-01597-F1D93115; Thu, 07 Feb 2013 12:25:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360239902!23047853!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 7 Feb 2013 12:25:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1236108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:25:03 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Thu, 7 Feb 2013
	12:25:02 +0000
Message-ID: <51139D20.60606@citrix.com>
Date: Thu, 7 Feb 2013 13:25:04 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, tech mailinglists
	<mailinglists.tech@gmail.com>, xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
In-Reply-To: <20130207121434.GD9769@type.bordeaux.inria.fr>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 07/02/13 13:14, Samuel Thibault wrote:
> Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :
>> tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
>>> I read in the wiki that stubdomains aren't support on NetBSD. Will subd=
oms be
>>> supported on NetBSD? Is someone working on that topic actually?
>>
>> I see no reason why it should be hard to do it,
> =

> Except that you need a gcc compiler which is able to build mini-os &
> such, but I guess this is already the case?  I see that there is already
> a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody has
> already given a try on FreeBSD, and NetBSD shouldn't be very far.

I've given it a look some time ago, but the build of newlib (if I
remember correctly) had dependencies on a bunch of Linux header files
which are not present on NetBSD. I guess a solution would be to ship all
those necessary headers with stubdoms, and use them when needed, but I'm
afraid that will probably crash with headers already present in NetBSD.

Another (and much simpler option) is to compile the stubdomains on a
Linux system and then copy them to your NetBSD system (or fetch them
from a packaged version of Xen from a Linux distro).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:25:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3QXI-0006qv-Ke; Thu, 07 Feb 2013 12:25:04 +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 1U3QXI-0006qj-1p; Thu, 07 Feb 2013 12:25:04 +0000
Received: from [85.158.143.99:44843] by server-2.bemta-4.messagelabs.com id
	22/80-01597-F1D93115; Thu, 07 Feb 2013 12:25:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360239902!23047853!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 7 Feb 2013 12:25:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1236108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 12:25:03 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Thu, 7 Feb 2013
	12:25:02 +0000
Message-ID: <51139D20.60606@citrix.com>
Date: Thu, 7 Feb 2013 13:25:04 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, tech mailinglists
	<mailinglists.tech@gmail.com>, xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
In-Reply-To: <20130207121434.GD9769@type.bordeaux.inria.fr>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 07/02/13 13:14, Samuel Thibault wrote:
> Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :
>> tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
>>> I read in the wiki that stubdomains aren't support on NetBSD. Will subd=
oms be
>>> supported on NetBSD? Is someone working on that topic actually?
>>
>> I see no reason why it should be hard to do it,
> =

> Except that you need a gcc compiler which is able to build mini-os &
> such, but I guess this is already the case?  I see that there is already
> a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody has
> already given a try on FreeBSD, and NetBSD shouldn't be very far.

I've given it a look some time ago, but the build of newlib (if I
remember correctly) had dependencies on a bunch of Linux header files
which are not present on NetBSD. I guess a solution would be to ship all
those necessary headers with stubdoms, and use them when needed, but I'm
afraid that will probably crash with headers already present in NetBSD.

Another (and much simpler option) is to compile the stubdomains on a
Linux system and then copy them to your NetBSD system (or fetch them
from a packaged version of Xen from a Linux distro).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:28:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:28: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 1U3Qao-0007Mb-28; Thu, 07 Feb 2013 12:28:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U3Qal-0007MM-Sk; Thu, 07 Feb 2013 12:28:40 +0000
Received: from [85.158.137.99:52696] by server-14.bemta-3.messagelabs.com id
	F0/DC-23533-6FD93115; Thu, 07 Feb 2013 12:28:38 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360240118!17249760!1
X-Originating-IP: [209.85.212.170]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14677 invoked from network); 7 Feb 2013 12:28:38 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:28:38 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so8261628wib.3
	for <multiple recipients>; Thu, 07 Feb 2013 04:28:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=usodjGGjPwLT1MSSSFz8mI4l/6cV5gRz00ZeDVfdjwc=;
	b=uSnbE9zv3+D/DdWSZEFDQEvAeMcYC8/u/dcJfWQz1FGBxjk4+mC7E+WmYiw3hJDfZb
	U1GdH4Wk2INn/22Rs094nh6Pj3rIZH79ZAJt9vtDGtlYcAUkkYzUm7ICO+3PQC2v8OJr
	w+JRHGBJqLbHSF32et/gP19ik6L0PByUOtlEhAJCyY7xGEMNWxCOzprvoLGIk7Ugy4E3
	7Ouw1izcwsi7ThyRlSMUDMdK0SlR/RXunzk29/9QvnG4TvbHxA+uIcFm1Lh2ae+6mizV
	HVY2hMa5ZMaUV+4zleI0rU+T10fI7CzDxqwkwDjIYxMFxNkFZZ7CG6uVsjJNhRonAvL8
	AVEw==
MIME-Version: 1.0
X-Received: by 10.194.76.7 with SMTP id g7mr2290858wjw.50.1360240117936; Thu,
	07 Feb 2013 04:28:37 -0800 (PST)
Received: by 10.227.203.18 with HTTP; Thu, 7 Feb 2013 04:28:37 -0800 (PST)
In-Reply-To: <51139D20.60606@citrix.com>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
	<51139D20.60606@citrix.com>
Date: Thu, 7 Feb 2013 13:28:37 +0100
Message-ID: <CAMCOOJuhGwMcE1+N1R41h4OkVuwaTCHnLE-XDmHUJ_n=x=JJ3A@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6027893413022481739=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6027893413022481739==
Content-Type: multipart/alternative; boundary=047d7beba20209f24e04d5219561

--047d7beba20209f24e04d5219561
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ok, the building will be no problem to do this on a Linux system. But all
is given in the NetBSD Dom0 kernel and Xen to run Stubdoms on NetBSD am I
right?

Best Regards


2013/2/7 Roger Pau Monn=E9 <roger.pau@citrix.com>

> On 07/02/13 13:14, Samuel Thibault wrote:
> > Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :
> >> tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
> >>> I read in the wiki that stubdomains aren't support on NetBSD. Will
> subdoms be
> >>> supported on NetBSD? Is someone working on that topic actually?
> >>
> >> I see no reason why it should be hard to do it,
> >
> > Except that you need a gcc compiler which is able to build mini-os &
> > such, but I guess this is already the case?  I see that there is alread=
y
> > a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody has
> > already given a try on FreeBSD, and NetBSD shouldn't be very far.
>
> I've given it a look some time ago, but the build of newlib (if I
> remember correctly) had dependencies on a bunch of Linux header files
> which are not present on NetBSD. I guess a solution would be to ship all
> those necessary headers with stubdoms, and use them when needed, but I'm
> afraid that will probably crash with headers already present in NetBSD.
>
> Another (and much simpler option) is to compile the stubdomains on a
> Linux system and then copy them to your NetBSD system (or fetch them
> from a packaged version of Xen from a Linux distro).
>
>

--047d7beba20209f24e04d5219561
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ok, the building will be no problem to do this on a Linux =
system. But all is given in the NetBSD Dom0 kernel and Xen to run Stubdoms =
on NetBSD am I right?<br><br>Best Regards<br></div><div class=3D"gmail_extr=
a">
<br><br><div class=3D"gmail_quote">2013/2/7 Roger Pau Monn=E9 <span dir=3D"=
ltr">&lt;<a href=3D"mailto:roger.pau@citrix.com" target=3D"_blank">roger.pa=
u@citrix.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On 07/02/13 13:14, Samuel Thibault =
wrote:<br>
&gt; Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :<br>
&gt;&gt; tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :<=
br>
&gt;&gt;&gt; I read in the wiki that stubdomains aren&#39;t support on NetB=
SD. Will subdoms be<br>
&gt;&gt;&gt; supported on NetBSD? Is someone working on that topic actually=
?<br>
&gt;&gt;<br>
&gt;&gt; I see no reason why it should be hard to do it,<br>
&gt;<br>
&gt; Except that you need a gcc compiler which is able to build mini-os &am=
p;<br>
&gt; such, but I guess this is already the case? =A0I see that there is alr=
eady<br>
&gt; a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody ha=
s<br>
&gt; already given a try on FreeBSD, and NetBSD shouldn&#39;t be very far.<=
br>
<br>
</div></div>I&#39;ve given it a look some time ago, but the build of newlib=
 (if I<br>
remember correctly) had dependencies on a bunch of Linux header files<br>
which are not present on NetBSD. I guess a solution would be to ship all<br=
>
those necessary headers with stubdoms, and use them when needed, but I&#39;=
m<br>
afraid that will probably crash with headers already present in NetBSD.<br>
<br>
Another (and much simpler option) is to compile the stubdomains on a<br>
Linux system and then copy them to your NetBSD system (or fetch them<br>
from a packaged version of Xen from a Linux distro).<br>
<br>
</blockquote></div><br></div>

--047d7beba20209f24e04d5219561--


--===============6027893413022481739==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6027893413022481739==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 12:28:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:28: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 1U3Qao-0007Mb-28; Thu, 07 Feb 2013 12:28:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U3Qal-0007MM-Sk; Thu, 07 Feb 2013 12:28:40 +0000
Received: from [85.158.137.99:52696] by server-14.bemta-3.messagelabs.com id
	F0/DC-23533-6FD93115; Thu, 07 Feb 2013 12:28:38 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360240118!17249760!1
X-Originating-IP: [209.85.212.170]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14677 invoked from network); 7 Feb 2013 12:28:38 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:28:38 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so8261628wib.3
	for <multiple recipients>; Thu, 07 Feb 2013 04:28:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=usodjGGjPwLT1MSSSFz8mI4l/6cV5gRz00ZeDVfdjwc=;
	b=uSnbE9zv3+D/DdWSZEFDQEvAeMcYC8/u/dcJfWQz1FGBxjk4+mC7E+WmYiw3hJDfZb
	U1GdH4Wk2INn/22Rs094nh6Pj3rIZH79ZAJt9vtDGtlYcAUkkYzUm7ICO+3PQC2v8OJr
	w+JRHGBJqLbHSF32et/gP19ik6L0PByUOtlEhAJCyY7xGEMNWxCOzprvoLGIk7Ugy4E3
	7Ouw1izcwsi7ThyRlSMUDMdK0SlR/RXunzk29/9QvnG4TvbHxA+uIcFm1Lh2ae+6mizV
	HVY2hMa5ZMaUV+4zleI0rU+T10fI7CzDxqwkwDjIYxMFxNkFZZ7CG6uVsjJNhRonAvL8
	AVEw==
MIME-Version: 1.0
X-Received: by 10.194.76.7 with SMTP id g7mr2290858wjw.50.1360240117936; Thu,
	07 Feb 2013 04:28:37 -0800 (PST)
Received: by 10.227.203.18 with HTTP; Thu, 7 Feb 2013 04:28:37 -0800 (PST)
In-Reply-To: <51139D20.60606@citrix.com>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
	<51139D20.60606@citrix.com>
Date: Thu, 7 Feb 2013 13:28:37 +0100
Message-ID: <CAMCOOJuhGwMcE1+N1R41h4OkVuwaTCHnLE-XDmHUJ_n=x=JJ3A@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6027893413022481739=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6027893413022481739==
Content-Type: multipart/alternative; boundary=047d7beba20209f24e04d5219561

--047d7beba20209f24e04d5219561
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ok, the building will be no problem to do this on a Linux system. But all
is given in the NetBSD Dom0 kernel and Xen to run Stubdoms on NetBSD am I
right?

Best Regards


2013/2/7 Roger Pau Monn=E9 <roger.pau@citrix.com>

> On 07/02/13 13:14, Samuel Thibault wrote:
> > Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :
> >> tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :
> >>> I read in the wiki that stubdomains aren't support on NetBSD. Will
> subdoms be
> >>> supported on NetBSD? Is someone working on that topic actually?
> >>
> >> I see no reason why it should be hard to do it,
> >
> > Except that you need a gcc compiler which is able to build mini-os &
> > such, but I guess this is already the case?  I see that there is alread=
y
> > a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody has
> > already given a try on FreeBSD, and NetBSD shouldn't be very far.
>
> I've given it a look some time ago, but the build of newlib (if I
> remember correctly) had dependencies on a bunch of Linux header files
> which are not present on NetBSD. I guess a solution would be to ship all
> those necessary headers with stubdoms, and use them when needed, but I'm
> afraid that will probably crash with headers already present in NetBSD.
>
> Another (and much simpler option) is to compile the stubdomains on a
> Linux system and then copy them to your NetBSD system (or fetch them
> from a packaged version of Xen from a Linux distro).
>
>

--047d7beba20209f24e04d5219561
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ok, the building will be no problem to do this on a Linux =
system. But all is given in the NetBSD Dom0 kernel and Xen to run Stubdoms =
on NetBSD am I right?<br><br>Best Regards<br></div><div class=3D"gmail_extr=
a">
<br><br><div class=3D"gmail_quote">2013/2/7 Roger Pau Monn=E9 <span dir=3D"=
ltr">&lt;<a href=3D"mailto:roger.pau@citrix.com" target=3D"_blank">roger.pa=
u@citrix.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On 07/02/13 13:14, Samuel Thibault =
wrote:<br>
&gt; Samuel Thibault, le Thu 07 Feb 2013 12:03:47 +0100, a =E9crit :<br>
&gt;&gt; tech mailinglists, le Thu 07 Feb 2013 11:56:39 +0100, a =E9crit :<=
br>
&gt;&gt;&gt; I read in the wiki that stubdomains aren&#39;t support on NetB=
SD. Will subdoms be<br>
&gt;&gt;&gt; supported on NetBSD? Is someone working on that topic actually=
?<br>
&gt;&gt;<br>
&gt;&gt; I see no reason why it should be hard to do it,<br>
&gt;<br>
&gt; Except that you need a gcc compiler which is able to build mini-os &am=
p;<br>
&gt; such, but I guess this is already the case? =A0I see that there is alr=
eady<br>
&gt; a -U __FreeBSD__ in the stubdom/Makefile, so it looks like somebody ha=
s<br>
&gt; already given a try on FreeBSD, and NetBSD shouldn&#39;t be very far.<=
br>
<br>
</div></div>I&#39;ve given it a look some time ago, but the build of newlib=
 (if I<br>
remember correctly) had dependencies on a bunch of Linux header files<br>
which are not present on NetBSD. I guess a solution would be to ship all<br=
>
those necessary headers with stubdoms, and use them when needed, but I&#39;=
m<br>
afraid that will probably crash with headers already present in NetBSD.<br>
<br>
Another (and much simpler option) is to compile the stubdomains on a<br>
Linux system and then copy them to your NetBSD system (or fetch them<br>
from a packaged version of Xen from a Linux distro).<br>
<br>
</blockquote></div><br></div>

--047d7beba20209f24e04d5219561--


--===============6027893413022481739==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6027893413022481739==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 12:28:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3Qav-0007O4-Bo; Thu, 07 Feb 2013 12:28:49 +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 1U3Qat-0007NS-9o
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 12:28:47 +0000
Received: from [85.158.138.51:59063] by server-9.bemta-3.messagelabs.com id
	07/25-09484-EFD93115; Thu, 07 Feb 2013 12:28:46 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360240125!28035480!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26224 invoked from network); 7 Feb 2013 12:28:45 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 12:28:45 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 3813D4007E4;
	Thu,  7 Feb 2013 13:27:46 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id cbWztqGUyQdN; Thu,  7 Feb 2013 13:27:45 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 497014000C3;
	Thu,  7 Feb 2013 13:27:45 +0100 (CET)
Message-ID: <51139DBE.7070407@tiscali.it>
Date: Thu, 07 Feb 2013 13:27:42 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
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="===============2351176885873342028=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2351176885873342028==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070505070308090108040301"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070505070308090108040301
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I haven't seen mail about eufi support on hvm domUs (ovmf) for a long tim=
e.
I'm interested in trying it with xen-unstable.
Someone can tell me if there is something to add to have it working=20
and/or ovmf git need to be updated?

Thanks for any reply.


--------------ms070505070308090108040301
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNzEyMjc0MlowIwYJKoZIhvcNAQkEMRYEFILz0PpXl0bC/7y9yM9fFVMO
q/bNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAPfZxdTlZXdNTW7cF6XypeGvY
7QAvC+uFlCKyNjYeZuO+oy34Iztho34LkDlyDvIkz+LK0Oz39snbcR6ETpAVlfL14BI2vQT+
d/bU59knb7aETZ3LdaglAjBzg8mEEe4Vt+V5401djI57CfVkToIvqTrS9QUCPHoIqvBdUzvK
IeHYZVHEW8EYhYJA6w3RhXaaw93X8/Uzm2G28N4zlobPlbDHzWY5uY6nJ7sSysmWPClZxoxf
ThtAnO9e22bep8YQjHhnDmyGn+YznUyU7uwvPJV322lwB08+NWuTJ/dEREYm9jAi2F6T2y2K
R/8o+xxCbeU9xz2xVeAikSRXh+eHXwAAAAAAAA==
--------------ms070505070308090108040301--


--===============2351176885873342028==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2351176885873342028==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 12:28:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3Qav-0007O4-Bo; Thu, 07 Feb 2013 12:28:49 +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 1U3Qat-0007NS-9o
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 12:28:47 +0000
Received: from [85.158.138.51:59063] by server-9.bemta-3.messagelabs.com id
	07/25-09484-EFD93115; Thu, 07 Feb 2013 12:28:46 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360240125!28035480!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26224 invoked from network); 7 Feb 2013 12:28:45 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 12:28:45 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 3813D4007E4;
	Thu,  7 Feb 2013 13:27:46 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id cbWztqGUyQdN; Thu,  7 Feb 2013 13:27:45 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 497014000C3;
	Thu,  7 Feb 2013 13:27:45 +0100 (CET)
Message-ID: <51139DBE.7070407@tiscali.it>
Date: Thu, 07 Feb 2013 13:27:42 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
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="===============2351176885873342028=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2351176885873342028==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070505070308090108040301"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070505070308090108040301
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I haven't seen mail about eufi support on hvm domUs (ovmf) for a long tim=
e.
I'm interested in trying it with xen-unstable.
Someone can tell me if there is something to add to have it working=20
and/or ovmf git need to be updated?

Thanks for any reply.


--------------ms070505070308090108040301
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNzEyMjc0MlowIwYJKoZIhvcNAQkEMRYEFILz0PpXl0bC/7y9yM9fFVMO
q/bNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAPfZxdTlZXdNTW7cF6XypeGvY
7QAvC+uFlCKyNjYeZuO+oy34Iztho34LkDlyDvIkz+LK0Oz39snbcR6ETpAVlfL14BI2vQT+
d/bU59knb7aETZ3LdaglAjBzg8mEEe4Vt+V5401djI57CfVkToIvqTrS9QUCPHoIqvBdUzvK
IeHYZVHEW8EYhYJA6w3RhXaaw93X8/Uzm2G28N4zlobPlbDHzWY5uY6nJ7sSysmWPClZxoxf
ThtAnO9e22bep8YQjHhnDmyGn+YznUyU7uwvPJV322lwB08+NWuTJ/dEREYm9jAi2F6T2y2K
R/8o+xxCbeU9xz2xVeAikSRXh+eHXwAAAAAAAA==
--------------ms070505070308090108040301--


--===============2351176885873342028==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2351176885873342028==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 12:28:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3Qau-0007Nf-7Q; Thu, 07 Feb 2013 12:28:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qas-0007NA-3l; Thu, 07 Feb 2013 12:28:46 +0000
Received: from [85.158.137.99:53300] by server-12.bemta-3.messagelabs.com id
	D7/6F-05889-DFD93115; Thu, 07 Feb 2013 12:28:45 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360240123!18083522!1
X-Originating-IP: [192.134.164.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19606 invoked from network); 7 Feb 2013 12:28:44 -0000
Received: from mail3-relais-sop.national.inria.fr (HELO
	mail3-relais-sop.national.inria.fr) (192.134.164.104)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:28:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355094000"; 
   d="scan'208";a="1402323"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 13:21:50 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qao-0004CI-TL; Thu, 07 Feb 2013 13:28:42 +0100
Date: Thu, 7 Feb 2013 13:28:42 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130207122842.GF9769@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
	<51139D20.60606@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51139D20.60606@citrix.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, le Thu 07 Feb 2013 13:25:04 +0100, a =E9crit :
> the build of newlib (if I remember correctly) had dependencies on a
> bunch of Linux header files which are not present on NetBSD.

Ah?  I don't see why newlib should fetch such header, since we configure
it with target=3Darch-xen-elf, it's not supposed to assume anything
linuxish.

> Another (and much simpler option) is to compile the stubdomains on a
> Linux system and then copy them to your NetBSD system (or fetch them
> from a packaged version of Xen from a Linux distro).

Yes, this should just work.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:28:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3Qau-0007Nf-7Q; Thu, 07 Feb 2013 12:28:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qas-0007NA-3l; Thu, 07 Feb 2013 12:28:46 +0000
Received: from [85.158.137.99:53300] by server-12.bemta-3.messagelabs.com id
	D7/6F-05889-DFD93115; Thu, 07 Feb 2013 12:28:45 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360240123!18083522!1
X-Originating-IP: [192.134.164.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19606 invoked from network); 7 Feb 2013 12:28:44 -0000
Received: from mail3-relais-sop.national.inria.fr (HELO
	mail3-relais-sop.national.inria.fr) (192.134.164.104)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:28:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355094000"; 
   d="scan'208";a="1402323"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 13:21:50 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qao-0004CI-TL; Thu, 07 Feb 2013 13:28:42 +0100
Date: Thu, 7 Feb 2013 13:28:42 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130207122842.GF9769@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
	<51139D20.60606@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51139D20.60606@citrix.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: tech mailinglists <mailinglists.tech@gmail.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, le Thu 07 Feb 2013 13:25:04 +0100, a =E9crit :
> the build of newlib (if I remember correctly) had dependencies on a
> bunch of Linux header files which are not present on NetBSD.

Ah?  I don't see why newlib should fetch such header, since we configure
it with target=3Darch-xen-elf, it's not supposed to assume anything
linuxish.

> Another (and much simpler option) is to compile the stubdomains on a
> Linux system and then copy them to your NetBSD system (or fetch them
> from a packaged version of Xen from a Linux distro).

Yes, this should just work.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:32:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3Qdu-00005w-W7; Thu, 07 Feb 2013 12:31:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qds-00005b-Se; Thu, 07 Feb 2013 12:31:52 +0000
Received: from [85.158.137.99:28956] by server-8.bemta-3.messagelabs.com id
	C0/D0-25687-2BE93115; Thu, 07 Feb 2013 12:31:46 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360240295!18084169!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3868 invoked from network); 7 Feb 2013 12:31:35 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:31:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355094000"; 
   d="scan'208";a="1808103"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 13:31:35 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qda-0004NI-Tk; Thu, 07 Feb 2013 13:31:34 +0100
Date: Thu, 7 Feb 2013 13:31:34 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: tech mailinglists <mailinglists.tech@gmail.com>
Message-ID: <20130207123134.GH9769@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
	<51139D20.60606@citrix.com>
	<CAMCOOJuhGwMcE1+N1R41h4OkVuwaTCHnLE-XDmHUJ_n=x=JJ3A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMCOOJuhGwMcE1+N1R41h4OkVuwaTCHnLE-XDmHUJ_n=x=JJ3A@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

tech mailinglists, le Thu 07 Feb 2013 13:28:37 +0100, a =E9crit :
> Ok, the building will be no problem to do this on a Linux system. But all=
 is
> given in the NetBSD Dom0 kernel and Xen to run Stubdoms on NetBSD am I ri=
ght?

Dom0 is not really involved when using a stubdom, so be it Linux or
NetBSD should not matter.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:32:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12: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 1U3Qdu-00005w-W7; Thu, 07 Feb 2013 12:31:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qds-00005b-Se; Thu, 07 Feb 2013 12:31:52 +0000
Received: from [85.158.137.99:28956] by server-8.bemta-3.messagelabs.com id
	C0/D0-25687-2BE93115; Thu, 07 Feb 2013 12:31:46 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360240295!18084169!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3868 invoked from network); 7 Feb 2013 12:31:35 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:31:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355094000"; 
   d="scan'208";a="1808103"
Received: from unknown (HELO type.ipv6) ([193.50.110.166])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	07 Feb 2013 13:31:35 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U3Qda-0004NI-Tk; Thu, 07 Feb 2013 13:31:34 +0100
Date: Thu, 7 Feb 2013 13:31:34 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: tech mailinglists <mailinglists.tech@gmail.com>
Message-ID: <20130207123134.GH9769@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	tech mailinglists <mailinglists.tech@gmail.com>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
	<20130207110347.GX6193@type.bordeaux.inria.fr>
	<20130207121434.GD9769@type.bordeaux.inria.fr>
	<51139D20.60606@citrix.com>
	<CAMCOOJuhGwMcE1+N1R41h4OkVuwaTCHnLE-XDmHUJ_n=x=JJ3A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMCOOJuhGwMcE1+N1R41h4OkVuwaTCHnLE-XDmHUJ_n=x=JJ3A@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [Xen-devel] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

tech mailinglists, le Thu 07 Feb 2013 13:28:37 +0100, a =E9crit :
> Ok, the building will be no problem to do this on a Linux system. But all=
 is
> given in the NetBSD Dom0 kernel and Xen to run Stubdoms on NetBSD am I ri=
ght?

Dom0 is not really involved when using a stubdom, so be it Linux or
NetBSD should not matter.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:32:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:32: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 1U3QeR-0000DR-MT; Thu, 07 Feb 2013 12:32:27 +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 1U3QeQ-0000Cx-Fp
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:32:26 +0000
Received: from [85.158.139.83:63707] by server-9.bemta-5.messagelabs.com id
	86/68-24440-9DE93115; Thu, 07 Feb 2013 12:32:25 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360240344!31160631!1
X-Originating-IP: [209.85.216.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17969 invoked from network); 7 Feb 2013 12:32:25 -0000
Received: from mail-qc0-f170.google.com (HELO mail-qc0-f170.google.com)
	(209.85.216.170)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:32:25 -0000
Received: by mail-qc0-f170.google.com with SMTP id d42so969650qca.15
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 04:32:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type;
	bh=C8CjUydrVT2Man3eNM3dQsWwi0UcrZAeaaMVpGUzaEE=;
	b=UZHAInETDxt5NXj6NHOKa5bbGopf4tUyCUrwwmWCc749cEhoPyl4OAS1irP/R0XyIT
	V3mn4pVbSKG4INm2QJu27AtAT96d17f+xZmeDnficzwu0Oxx1j3AjDvL8i+oLmAfIsLq
	ZbA7Eo3QdWNyaQLtujODN7FOWk9D3MWE8aA1c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type
	:x-gm-message-state;
	bh=C8CjUydrVT2Man3eNM3dQsWwi0UcrZAeaaMVpGUzaEE=;
	b=N50hyD2Y7aQyotxwaZLC14khzavcStTDfkZYgvNkjHVHHXDiRfHmhfk75IHshghD/J
	dWxlJ2cusPUfiRM+pWtcFrwAJweQJlsQFjL5luzUXMk3OX7VTvu4f1mDQxf00IwWOS51
	+TgFTAp19zGVdR8KJ/CjOGfucGT/0qmOq3JVp2WgQ70QYY3tnEFjZlR95PWJVC+mpYID
	mRHUYasgG0GSbryiIjYxY1ki0+phzjFhNRgt+TZEgKiCG69atdMCP7Z5rRysY9N90eei
	UourR9jEG0v/Gf6qRYURXgs1BouqiH0aEMSZdMPLPZrN4rPG/UmZAhdhNJIvr6v9+G9N
	jQmg==
X-Received: by 10.224.96.4 with SMTP id f4mr614678qan.79.1360240343299; Thu,
	07 Feb 2013 04:32:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 7 Feb 2013 04:32:08 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 7 Feb 2013 16:32:08 +0400
X-Google-Sender-Auth: j901tiyy2c8sdAV1kLKjwwMEEJ4
Message-ID: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQktN97ydFU2Awx1MyIiy02Kl+S8UAACS05XCmHFQvkfWkOlCSWCSTSjuw1RqfqEqlholMw+
Subject: [Xen-devel] redirect qemu-dm log to syslog
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 search mailing list and can't see any questions and answers...
Is that possible (and how) to redirect qemu-dm output (stored in
/var/log/xen/qemu-dm-xxx.log) to syslog and not write to file?

-- 
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 Thu Feb 07 12:32:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:32: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 1U3QeR-0000DR-MT; Thu, 07 Feb 2013 12:32:27 +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 1U3QeQ-0000Cx-Fp
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 12:32:26 +0000
Received: from [85.158.139.83:63707] by server-9.bemta-5.messagelabs.com id
	86/68-24440-9DE93115; Thu, 07 Feb 2013 12:32:25 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360240344!31160631!1
X-Originating-IP: [209.85.216.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17969 invoked from network); 7 Feb 2013 12:32:25 -0000
Received: from mail-qc0-f170.google.com (HELO mail-qc0-f170.google.com)
	(209.85.216.170)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 12:32:25 -0000
Received: by mail-qc0-f170.google.com with SMTP id d42so969650qca.15
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 04:32:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type;
	bh=C8CjUydrVT2Man3eNM3dQsWwi0UcrZAeaaMVpGUzaEE=;
	b=UZHAInETDxt5NXj6NHOKa5bbGopf4tUyCUrwwmWCc749cEhoPyl4OAS1irP/R0XyIT
	V3mn4pVbSKG4INm2QJu27AtAT96d17f+xZmeDnficzwu0Oxx1j3AjDvL8i+oLmAfIsLq
	ZbA7Eo3QdWNyaQLtujODN7FOWk9D3MWE8aA1c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type
	:x-gm-message-state;
	bh=C8CjUydrVT2Man3eNM3dQsWwi0UcrZAeaaMVpGUzaEE=;
	b=N50hyD2Y7aQyotxwaZLC14khzavcStTDfkZYgvNkjHVHHXDiRfHmhfk75IHshghD/J
	dWxlJ2cusPUfiRM+pWtcFrwAJweQJlsQFjL5luzUXMk3OX7VTvu4f1mDQxf00IwWOS51
	+TgFTAp19zGVdR8KJ/CjOGfucGT/0qmOq3JVp2WgQ70QYY3tnEFjZlR95PWJVC+mpYID
	mRHUYasgG0GSbryiIjYxY1ki0+phzjFhNRgt+TZEgKiCG69atdMCP7Z5rRysY9N90eei
	UourR9jEG0v/Gf6qRYURXgs1BouqiH0aEMSZdMPLPZrN4rPG/UmZAhdhNJIvr6v9+G9N
	jQmg==
X-Received: by 10.224.96.4 with SMTP id f4mr614678qan.79.1360240343299; Thu,
	07 Feb 2013 04:32:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 7 Feb 2013 04:32:08 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 7 Feb 2013 16:32:08 +0400
X-Google-Sender-Auth: j901tiyy2c8sdAV1kLKjwwMEEJ4
Message-ID: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQktN97ydFU2Awx1MyIiy02Kl+S8UAACS05XCmHFQvkfWkOlCSWCSTSjuw1RqfqEqlholMw+
Subject: [Xen-devel] redirect qemu-dm log to syslog
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 search mailing list and can't see any questions and answers...
Is that possible (and how) to redirect qemu-dm output (stored in
/var/log/xen/qemu-dm-xxx.log) to syslog and not write to file?

-- 
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 Thu Feb 07 12:50:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:50: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 1U3Qvd-0001Sa-KV; Thu, 07 Feb 2013 12:50:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kristian@hagsted.dk>) id 1U3Qvc-0001SV-6s
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 12:50:12 +0000
Received: from [85.158.139.211:21296] by server-12.bemta-5.messagelabs.com id
	D6/D6-20195-303A3115; Thu, 07 Feb 2013 12:50:11 +0000
X-Env-Sender: kristian@hagsted.dk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360241385!20020880!1
X-Originating-IP: [80.160.77.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMTYwLjc3Ljk4ID0+IDE0NDMwOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1344 invoked from network); 7 Feb 2013 12:50:10 -0000
Received: from pasmtpb.tele.dk (HELO pasmtpB.tele.dk) (80.160.77.98)
	by server-9.tower-206.messagelabs.com with SMTP;
	7 Feb 2013 12:50:10 -0000
Received: from hagsted.dk (2-108-99-186-static.dk.customer.tdc.net
	[2.108.99.186])
	by pasmtpB.tele.dk (Postfix) with ESMTP id D4CCFD81FB;
	Thu,  7 Feb 2013 13:49:17 +0100 (CET)
Received: from HAGSTED-BSERVER.hagsted.dk ([fe80::91b7:737e:e057:7c8b]) by
	hagsted-bserver.hagsted.dk ([fe80::91b7:737e:e057:7c8b%10]) with mapi
	id 14.02.0328.009; Thu, 7 Feb 2013 13:48:58 +0100
From: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, xen-devel
	<xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
Thread-Index: AQHOBS6+hxHSkkT9D0irHGI4vPjQCZhuVtvg
Date: Thu, 7 Feb 2013 12:48:57 +0000
Message-ID: <19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
In-Reply-To: <51139DBE.7070407@tiscali.it>
Accept-Language: da-DK, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.38.90.11]
MIME-Version: 1.0
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fabio Fantoni
> Sent: 7. februar 2013 13:28
> To: xen-devel; Ian Campbell; Stefano Stabellini
> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
> 
> I haven't seen mail about eufi support on hvm domUs (ovmf) for a long time.
> I'm interested in trying it with xen-unstable.
> Someone can tell me if there is something to add to have it working and/or
> ovmf git need to be updated?
I have been running Windows 8 and server 2012 HVM on OVMF for some time. I used the latest OVMF build from the edk2 source with xen-unstable. It works fine, except that the vnc connection doesn't update the picture, so I have to open and close the vnc window for updating the picture, until I have enabled remote desktop in windows. I also tried to pass through some USB ports with success, the passing through my intel hd 4000 gfx, does not work even in secondary mode.

/Kristian Hagsted Rasmussen
> 
> Thanks for any reply.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 12:50:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 12:50: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 1U3Qvd-0001Sa-KV; Thu, 07 Feb 2013 12:50:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kristian@hagsted.dk>) id 1U3Qvc-0001SV-6s
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 12:50:12 +0000
Received: from [85.158.139.211:21296] by server-12.bemta-5.messagelabs.com id
	D6/D6-20195-303A3115; Thu, 07 Feb 2013 12:50:11 +0000
X-Env-Sender: kristian@hagsted.dk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360241385!20020880!1
X-Originating-IP: [80.160.77.98]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMTYwLjc3Ljk4ID0+IDE0NDMwOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1344 invoked from network); 7 Feb 2013 12:50:10 -0000
Received: from pasmtpb.tele.dk (HELO pasmtpB.tele.dk) (80.160.77.98)
	by server-9.tower-206.messagelabs.com with SMTP;
	7 Feb 2013 12:50:10 -0000
Received: from hagsted.dk (2-108-99-186-static.dk.customer.tdc.net
	[2.108.99.186])
	by pasmtpB.tele.dk (Postfix) with ESMTP id D4CCFD81FB;
	Thu,  7 Feb 2013 13:49:17 +0100 (CET)
Received: from HAGSTED-BSERVER.hagsted.dk ([fe80::91b7:737e:e057:7c8b]) by
	hagsted-bserver.hagsted.dk ([fe80::91b7:737e:e057:7c8b%10]) with mapi
	id 14.02.0328.009; Thu, 7 Feb 2013 13:48:58 +0100
From: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, xen-devel
	<xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
Thread-Index: AQHOBS6+hxHSkkT9D0irHGI4vPjQCZhuVtvg
Date: Thu, 7 Feb 2013 12:48:57 +0000
Message-ID: <19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
In-Reply-To: <51139DBE.7070407@tiscali.it>
Accept-Language: da-DK, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.38.90.11]
MIME-Version: 1.0
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fabio Fantoni
> Sent: 7. februar 2013 13:28
> To: xen-devel; Ian Campbell; Stefano Stabellini
> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
> 
> I haven't seen mail about eufi support on hvm domUs (ovmf) for a long time.
> I'm interested in trying it with xen-unstable.
> Someone can tell me if there is something to add to have it working and/or
> ovmf git need to be updated?
I have been running Windows 8 and server 2012 HVM on OVMF for some time. I used the latest OVMF build from the edk2 source with xen-unstable. It works fine, except that the vnc connection doesn't update the picture, so I have to open and close the vnc window for updating the picture, until I have enabled remote desktop in windows. I also tried to pass through some USB ports with success, the passing through my intel hd 4000 gfx, does not work even in secondary mode.

/Kristian Hagsted Rasmussen
> 
> Thanks for any reply.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:01:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13:01: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 1U3R69-0001xb-Qz; Thu, 07 Feb 2013 13:01:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3R67-0001xW-S4
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:01:04 +0000
Received: from [85.158.143.99:51825] by server-1.bemta-4.messagelabs.com id
	D9/18-08839-F85A3115; Thu, 07 Feb 2013 13:01:03 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360242061!23765825!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24980 invoked from network); 7 Feb 2013 13:01:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 13:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1238007"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 13:01:01 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 7 Feb 2013
	13:01:01 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 13:01:00 +0000
Thread-Topic: [PATCH 2/4] cover: Adding support for coverage information
Thread-Index: Ac4FMy2L0dQpiNj3QAW/kNhp+ZRoHA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458373@LONPMAILBOX01.citrite.net>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
	<5113972B.3090802@eu.citrix.com>
In-Reply-To: <5113972B.3090802@eu.citrix.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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] cover: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 11:59 +0000, George Dunlap wrote:
> On 07/02/13 11:28, Frediano Ziglio wrote:
> > diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
> > new file mode 100644
> > index 0000000..733d020
> > --- /dev/null
> > +++ b/xen/common/gcov/gcov.c
> > @@ -0,0 +1,74 @@
> > +/*
> > + *  This code maintains a list of active profiling data structures.
> > + *
> > + *    Copyright IBM Corp. 2009
> > + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > + *
> > + *    Uses gcc-internal data definitions.
> > + *    Based on the gcov-kernel patch by:
> > + *       Hubertus Franke <frankeh@us.ibm.com>
> > + *       Nigel Hinds <nhinds@us.ibm.com>
> > + *       Rajan Ravindran <rajancr@us.ibm.com>
> > + *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > + *       Paul Larson
> > + */
> > +
> > +#include <xen/config.h>
> > +#include <xen/init.h>
> > +#include <xen/lib.h>
> > +#include <xen/hypercall.h>
> > +#include <xen/gcov.h>
> > +#include <xen/errno.h>
> > +
> > +static struct gcov_info *info_list;
> > +static unsigned num_info = 0;
> 
> This is a bit of a nit, but you seem to remove this variable in the next 
> patch, which is bad form.  If it's not necessary, just don't add it in 
> this patch.
> 
> > +
> > +/*
> > + * __gcov_init is called by gcc-generated constructor code for each object
> > + * file compiled with -fprofile-arcs.
> > + *
> > + * Although this function is called only during initialization is called from
> > + * a .text section which is still present after initialization so not declare
> > + * as __init.
> > + */
> > +void __gcov_init(struct gcov_info *info)
> > +{
> > +    /* add new profiling data structure to list */
> > +    info->next = info_list;
> > +    info_list = info;
> > +    ++num_info;
> 
> Ditto.
> 
>   -George
> 

Done

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:01:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13:01: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 1U3R69-0001xb-Qz; Thu, 07 Feb 2013 13:01:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3R67-0001xW-S4
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:01:04 +0000
Received: from [85.158.143.99:51825] by server-1.bemta-4.messagelabs.com id
	D9/18-08839-F85A3115; Thu, 07 Feb 2013 13:01:03 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360242061!23765825!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24980 invoked from network); 7 Feb 2013 13:01:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 13:01:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1238007"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 13:01:01 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 7 Feb 2013
	13:01:01 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 13:01:00 +0000
Thread-Topic: [PATCH 2/4] cover: Adding support for coverage information
Thread-Index: Ac4FMy2L0dQpiNj3QAW/kNhp+ZRoHA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458373@LONPMAILBOX01.citrite.net>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<1360236482-25452-3-git-send-email-frediano.ziglio@citrix.com>
	<5113972B.3090802@eu.citrix.com>
In-Reply-To: <5113972B.3090802@eu.citrix.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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] cover: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 11:59 +0000, George Dunlap wrote:
> On 07/02/13 11:28, Frediano Ziglio wrote:
> > diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
> > new file mode 100644
> > index 0000000..733d020
> > --- /dev/null
> > +++ b/xen/common/gcov/gcov.c
> > @@ -0,0 +1,74 @@
> > +/*
> > + *  This code maintains a list of active profiling data structures.
> > + *
> > + *    Copyright IBM Corp. 2009
> > + *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > + *
> > + *    Uses gcc-internal data definitions.
> > + *    Based on the gcov-kernel patch by:
> > + *       Hubertus Franke <frankeh@us.ibm.com>
> > + *       Nigel Hinds <nhinds@us.ibm.com>
> > + *       Rajan Ravindran <rajancr@us.ibm.com>
> > + *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > + *       Paul Larson
> > + */
> > +
> > +#include <xen/config.h>
> > +#include <xen/init.h>
> > +#include <xen/lib.h>
> > +#include <xen/hypercall.h>
> > +#include <xen/gcov.h>
> > +#include <xen/errno.h>
> > +
> > +static struct gcov_info *info_list;
> > +static unsigned num_info = 0;
> 
> This is a bit of a nit, but you seem to remove this variable in the next 
> patch, which is bad form.  If it's not necessary, just don't add it in 
> this patch.
> 
> > +
> > +/*
> > + * __gcov_init is called by gcc-generated constructor code for each object
> > + * file compiled with -fprofile-arcs.
> > + *
> > + * Although this function is called only during initialization is called from
> > + * a .text section which is still present after initialization so not declare
> > + * as __init.
> > + */
> > +void __gcov_init(struct gcov_info *info)
> > +{
> > +    /* add new profiling data structure to list */
> > +    info->next = info_list;
> > +    info_list = info;
> > +    ++num_info;
> 
> Ditto.
> 
>   -George
> 

Done

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:13:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13:13: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 1U3RHd-0002jE-47; Thu, 07 Feb 2013 13:12:57 +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 1U3RHb-0002j9-Mw
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:12:56 +0000
Received: from [85.158.137.99:19141] by server-15.bemta-3.messagelabs.com id
	88/86-25405-258A3115; Thu, 07 Feb 2013 13:12:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360242768!20435973!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18432 invoked from network); 7 Feb 2013 13:12:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 13:12:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3RHT-000KXJ-28; Thu, 07 Feb 2013 13:12:47 +0000
Date: Thu, 7 Feb 2013 13:12:47 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207131247.GE77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 06/45] xen: arm64: initial build + config
	changes, start of day 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

At 15:56 +0000 on 23 Jan (1358956572), Ian Campbell wrote:
> diff --git a/config/arm64.mk b/config/arm64.mk
> new file mode 100644
> index 0000000..b2457eb
> --- /dev/null
> +++ b/config/arm64.mk
> @@ -0,0 +1,12 @@
> +CONFIG_ARM := y
> +CONFIG_ARM_64 := y
> +CONFIG_ARM_$(XEN_OS) := y
> +
> +CFLAGS += #-marm -march= -mcpu= etc
> +
> +HAS_PL011 := y
> +
> +# Use only if calling $(LD) directly.
> +LDFLAGS_DIRECT += -maarch64elf
> +
> +CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index f83bfee..2250366 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -25,6 +25,12 @@ arm32 := y
>  arm64 := n
>  endif
>  
> +ifeq ($(TARGET_SUBARCH),arm64)
> +CFLAGS += -mcpu=generic

Should this go in config/arm64.mk?  I realise the equivalent flags for
arm32 are in this file, just wondering if we ought to tidy them all into
config/.

> --- /dev/null
> +++ b/xen/arch/arm/arm64/head.S
> @@ -0,0 +1,405 @@
> +/*
> + * xen/arch/arm/head.S
> + *
> + * Start-of-day code for an ARMv8.
> + *
> + * Ian Campbell <ian.campbell@citrix.com>
> + * Copyright (c) 2012 Citrix Systems.
> + *
> + * Based on ARMv7-A head.S by
> + * Tim Deegan <tim@xen.org>
> + *
> + * 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 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.
> + */
> +
> +#include <asm/config.h>
> +#include <asm/page.h>
> +#include <asm/asm_defns.h>
> +
> +#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
> +#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
> +#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
> +#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
> +
> +/* Macro to print a string to the UART, if there is one.
> + * Clobbers r0-r3. */
> +#ifdef EARLY_UART_ADDRESS
> +#define PRINT(_s)       \
> +	adr   x0, 98f ; \
> +	bl    puts    ; \
> +	b     99f     ; \
> +98:	.asciz _s     ; \
> +	.align 2      ; \

Backslashes are misaligned here; I suspect because of hard tabs.

> +99:
> +#else
> +#define PRINT(s)
> +#endif
> +
> +	/*.aarch64*/
> +
> +	/*
> +	 * Kernel startup entry point.
> +	 * ---------------------------
> +	 *
> +	 * The requirements are:
> +	 *   MMU = off, D-cache = off, I-cache = on or off,
> +	 *   x0 = physical address to the FDT blob.
> +	 *
> +	 * This must be the very first address in the loaded image.
> +	 * It should be linked at XEN_VIRT_START, and loaded at any
> +	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
> +	 * or the initial pagetable code below will need adjustment.
> +	 */
> +
> +	.global start
> +start:
> +        /*
> +         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
> +         */
> +        b       real_start           /* branch to kernel start, magic */
> +        .long   0                    /* reserved */
> +        .quad   0                    /* Image load offset from start of RAM */
> +        .quad   0                    /* reserved */
> +        .quad   0                    /* reserved */
> +
> +real_start:
> +	msr   DAIFSet, 0xf           /* Disable all interrupts */

These are hard tabs; the data block just above uses spaces. 

> +/*
> + * Exception Levels
> + */
> +#define EL0t   0x00000000
> +#define EL1t   0x00000004
> +#define EL1h   0x00000005
> +#define EL2t   0x00000008
> +#define EL2h   0x00000009
> +#define EL3t   0x0000000c
> +#define EL3h   0x0000000d

Do these belong in a header somewhere?  If not maybe they can go at the
top of this file with the PT_ macros.

> +boot_cpu:
> +#ifdef EARLY_UART_ADDRESS
> +	ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
> +	cbnz  x22, 1f
> +	bl    init_uart                 /* CPU 0 sets up the UART too */
> +1:	PRINT("- CPU ")
> +	mov   x0, x22
> +	bl    putn
> +	PRINT(" booting -\r\n")
> +#endif
> +
> +	PRINT("- Current EL ")
> +	mrs   x0, CurrentEL
> +	bl    putn
> +	PRINT(" -\r\n")
> +
> +	/* Are we in EL3 */
> +	mrs   x0, CurrentEL
> +	cmp   x0, #EL3t
> +	ccmp  x0, #EL3h, #0x4, ne
> +	b.eq  1f /* Yes */
> +
> +	/* Are we in EL2 */
> +	cmp   x0, #EL2t
> +	ccmp  x0, #EL2h, #0x4, ne
> +	b.eq  2f /* Yes */
> +
> +	/* Otherwise, it must have been EL0 or EL1 */
> +	PRINT("- CPU is not in EL3 or EL2 -\r\n")
> +	b     fail
> +
> +1:	PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
> +	ldr   x1, =enter_el2_mode    /* VA of function */
> +	add   x1, x1, x20            /* PA of function */
> +	adr   x30, hyp               /* Set return address for call */
> +	br    x1                     /* Call function */
> +
> +2:	PRINT("- Started in Hyp mode -\r\n")

Some confusion here between 'EL2' and 'Hyp' -- are they the same thing?
Should we use 'el2' consistently?

> +	PRINT("- Ready -\r\n")
> +
> +	/* The boot CPU should go straight into C now */
> +	cbz   x22, launch
> +
> +	/* Non-boot CPUs need to move on to the relocated pagetables */
> +	//mov   x0, #0

Should be removed?

> --- /dev/null
> +++ b/xen/arch/arm/arm64/mode_switch.S
> @@ -0,0 +1,83 @@
> +/*
> + * xen/arch/arm/arm64/mode_switch.S
> + *
> + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> +	bootwrapper.

    ^ missing '*'

> +.globl enter_el2_mode
> +enter_el2_mode:
> +        mov     x0, #0x30                       // RES1
> +        orr     x0, x0, #(1 << 0)               // Non-secure EL1
> +        orr     x0, x0, #(1 << 8)               // HVC enable
> +        orr     x0, x0, #(1 << 10)              // 64-bit EL2

Is this any better than ldr'ing a magic constant?

> +        msr     scr_el3, x0
> +
> +        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
> +
> +        ldr     x0, =0x01800000                 // 24Mhz
> +        msr     cntfrq_el0, x0
> +
> +        /*
> +         * Check for the primary CPU to avoid a race on the distributor
> +         * registers.
> +         */
> +	cbnz    x22, 1f

Hard tab.

> +
> +        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR

Can we use the gic.h constants here?  I gues the '/4' everywhere makes
it ugly.

> +        mov     w0, #~0                         // Grp1 interrupts
> +        str     w0, [x1], #4
> +        b.ne    2f                              // Only local interrupts for secondary CPUs

Linewrap

> +        str     w0, [x1], #4
> +        str     w0, [x1], #4
> +
> +2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR

THis can be a '1:', I think.

> +        ldr     w0, [x1]
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
> +        str     w0, [x1, #4]                    // GICC_PMR
> +
> +        msr     sctlr_el2, xzr
> +
> +        /*
> +         * Prepare the switch to the EL2_SP1 mode from EL3
> +         */
> +        msr     elr_el3, x30                    // Return to desired function

Are you passing an argument in x30?  Or is x30 the link register?

> +        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
> +        msr     spsr_el3, x1
> +        eret

Maybe add an emacs block here?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:13:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13:13: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 1U3RHd-0002jE-47; Thu, 07 Feb 2013 13:12:57 +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 1U3RHb-0002j9-Mw
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:12:56 +0000
Received: from [85.158.137.99:19141] by server-15.bemta-3.messagelabs.com id
	88/86-25405-258A3115; Thu, 07 Feb 2013 13:12:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360242768!20435973!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18432 invoked from network); 7 Feb 2013 13:12:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 13:12:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3RHT-000KXJ-28; Thu, 07 Feb 2013 13:12:47 +0000
Date: Thu, 7 Feb 2013 13:12:47 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207131247.GE77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 06/45] xen: arm64: initial build + config
	changes, start of day 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

At 15:56 +0000 on 23 Jan (1358956572), Ian Campbell wrote:
> diff --git a/config/arm64.mk b/config/arm64.mk
> new file mode 100644
> index 0000000..b2457eb
> --- /dev/null
> +++ b/config/arm64.mk
> @@ -0,0 +1,12 @@
> +CONFIG_ARM := y
> +CONFIG_ARM_64 := y
> +CONFIG_ARM_$(XEN_OS) := y
> +
> +CFLAGS += #-marm -march= -mcpu= etc
> +
> +HAS_PL011 := y
> +
> +# Use only if calling $(LD) directly.
> +LDFLAGS_DIRECT += -maarch64elf
> +
> +CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index f83bfee..2250366 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -25,6 +25,12 @@ arm32 := y
>  arm64 := n
>  endif
>  
> +ifeq ($(TARGET_SUBARCH),arm64)
> +CFLAGS += -mcpu=generic

Should this go in config/arm64.mk?  I realise the equivalent flags for
arm32 are in this file, just wondering if we ought to tidy them all into
config/.

> --- /dev/null
> +++ b/xen/arch/arm/arm64/head.S
> @@ -0,0 +1,405 @@
> +/*
> + * xen/arch/arm/head.S
> + *
> + * Start-of-day code for an ARMv8.
> + *
> + * Ian Campbell <ian.campbell@citrix.com>
> + * Copyright (c) 2012 Citrix Systems.
> + *
> + * Based on ARMv7-A head.S by
> + * Tim Deegan <tim@xen.org>
> + *
> + * 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 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.
> + */
> +
> +#include <asm/config.h>
> +#include <asm/page.h>
> +#include <asm/asm_defns.h>
> +
> +#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
> +#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
> +#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
> +#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
> +
> +/* Macro to print a string to the UART, if there is one.
> + * Clobbers r0-r3. */
> +#ifdef EARLY_UART_ADDRESS
> +#define PRINT(_s)       \
> +	adr   x0, 98f ; \
> +	bl    puts    ; \
> +	b     99f     ; \
> +98:	.asciz _s     ; \
> +	.align 2      ; \

Backslashes are misaligned here; I suspect because of hard tabs.

> +99:
> +#else
> +#define PRINT(s)
> +#endif
> +
> +	/*.aarch64*/
> +
> +	/*
> +	 * Kernel startup entry point.
> +	 * ---------------------------
> +	 *
> +	 * The requirements are:
> +	 *   MMU = off, D-cache = off, I-cache = on or off,
> +	 *   x0 = physical address to the FDT blob.
> +	 *
> +	 * This must be the very first address in the loaded image.
> +	 * It should be linked at XEN_VIRT_START, and loaded at any
> +	 * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
> +	 * or the initial pagetable code below will need adjustment.
> +	 */
> +
> +	.global start
> +start:
> +        /*
> +         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
> +         */
> +        b       real_start           /* branch to kernel start, magic */
> +        .long   0                    /* reserved */
> +        .quad   0                    /* Image load offset from start of RAM */
> +        .quad   0                    /* reserved */
> +        .quad   0                    /* reserved */
> +
> +real_start:
> +	msr   DAIFSet, 0xf           /* Disable all interrupts */

These are hard tabs; the data block just above uses spaces. 

> +/*
> + * Exception Levels
> + */
> +#define EL0t   0x00000000
> +#define EL1t   0x00000004
> +#define EL1h   0x00000005
> +#define EL2t   0x00000008
> +#define EL2h   0x00000009
> +#define EL3t   0x0000000c
> +#define EL3h   0x0000000d

Do these belong in a header somewhere?  If not maybe they can go at the
top of this file with the PT_ macros.

> +boot_cpu:
> +#ifdef EARLY_UART_ADDRESS
> +	ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
> +	cbnz  x22, 1f
> +	bl    init_uart                 /* CPU 0 sets up the UART too */
> +1:	PRINT("- CPU ")
> +	mov   x0, x22
> +	bl    putn
> +	PRINT(" booting -\r\n")
> +#endif
> +
> +	PRINT("- Current EL ")
> +	mrs   x0, CurrentEL
> +	bl    putn
> +	PRINT(" -\r\n")
> +
> +	/* Are we in EL3 */
> +	mrs   x0, CurrentEL
> +	cmp   x0, #EL3t
> +	ccmp  x0, #EL3h, #0x4, ne
> +	b.eq  1f /* Yes */
> +
> +	/* Are we in EL2 */
> +	cmp   x0, #EL2t
> +	ccmp  x0, #EL2h, #0x4, ne
> +	b.eq  2f /* Yes */
> +
> +	/* Otherwise, it must have been EL0 or EL1 */
> +	PRINT("- CPU is not in EL3 or EL2 -\r\n")
> +	b     fail
> +
> +1:	PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
> +	ldr   x1, =enter_el2_mode    /* VA of function */
> +	add   x1, x1, x20            /* PA of function */
> +	adr   x30, hyp               /* Set return address for call */
> +	br    x1                     /* Call function */
> +
> +2:	PRINT("- Started in Hyp mode -\r\n")

Some confusion here between 'EL2' and 'Hyp' -- are they the same thing?
Should we use 'el2' consistently?

> +	PRINT("- Ready -\r\n")
> +
> +	/* The boot CPU should go straight into C now */
> +	cbz   x22, launch
> +
> +	/* Non-boot CPUs need to move on to the relocated pagetables */
> +	//mov   x0, #0

Should be removed?

> --- /dev/null
> +++ b/xen/arch/arm/arm64/mode_switch.S
> @@ -0,0 +1,83 @@
> +/*
> + * xen/arch/arm/arm64/mode_switch.S
> + *
> + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> +	bootwrapper.

    ^ missing '*'

> +.globl enter_el2_mode
> +enter_el2_mode:
> +        mov     x0, #0x30                       // RES1
> +        orr     x0, x0, #(1 << 0)               // Non-secure EL1
> +        orr     x0, x0, #(1 << 8)               // HVC enable
> +        orr     x0, x0, #(1 << 10)              // 64-bit EL2

Is this any better than ldr'ing a magic constant?

> +        msr     scr_el3, x0
> +
> +        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
> +
> +        ldr     x0, =0x01800000                 // 24Mhz
> +        msr     cntfrq_el0, x0
> +
> +        /*
> +         * Check for the primary CPU to avoid a race on the distributor
> +         * registers.
> +         */
> +	cbnz    x22, 1f

Hard tab.

> +
> +        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR

Can we use the gic.h constants here?  I gues the '/4' everywhere makes
it ugly.

> +        mov     w0, #~0                         // Grp1 interrupts
> +        str     w0, [x1], #4
> +        b.ne    2f                              // Only local interrupts for secondary CPUs

Linewrap

> +        str     w0, [x1], #4
> +        str     w0, [x1], #4
> +
> +2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR

THis can be a '1:', I think.

> +        ldr     w0, [x1]
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
> +        str     w0, [x1, #4]                    // GICC_PMR
> +
> +        msr     sctlr_el2, xzr
> +
> +        /*
> +         * Prepare the switch to the EL2_SP1 mode from EL3
> +         */
> +        msr     elr_el3, x30                    // Return to desired function

Are you passing an argument in x30?  Or is x30 the link register?

> +        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
> +        msr     spsr_el3, x1
> +        eret

Maybe add an emacs block here?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:17:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13:17: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 1U3RLN-0002q6-Pf; Thu, 07 Feb 2013 13:16: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 1U3PI7-0000ZU-AX; Thu, 07 Feb 2013 11:05:19 +0000
Received: from [85.158.137.99:52228] by server-1.bemta-3.messagelabs.com id
	70/BE-08955-96A83115; Thu, 07 Feb 2013 11:05:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360235112!19541683!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24762 invoked from network); 7 Feb 2013 11:05:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1232771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 11:05: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.297.1; Thu, 7 Feb 2013
	11:05:12 +0000
Message-ID: <1360235111.32479.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: tech mailinglists <mailinglists.tech@gmail.com>
Date: Thu, 7 Feb 2013 11:05:11 +0000
In-Reply-To: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 07 Feb 2013 13:16:48 +0000
Cc: xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-devel to bcc.

On Thu, 2013-02-07 at 10:56 +0000, tech mailinglists wrote:

> I read in the wiki that stubdomains aren't support on NetBSD. Will
> subdoms be supported on NetBSD? Is someone working on that topic
> actually?

I don't follow NetBSD closely but AFAIK while you can't build a stubdom
on NetBSD stubdoms images built elsewhere should work.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:17:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13:17: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 1U3RLN-0002q6-Pf; Thu, 07 Feb 2013 13:16: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 1U3PI7-0000ZU-AX; Thu, 07 Feb 2013 11:05:19 +0000
Received: from [85.158.137.99:52228] by server-1.bemta-3.messagelabs.com id
	70/BE-08955-96A83115; Thu, 07 Feb 2013 11:05:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360235112!19541683!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24762 invoked from network); 7 Feb 2013 11:05:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 11:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,621,1355097600"; 
   d="scan'208";a="1232771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 11:05: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.297.1; Thu, 7 Feb 2013
	11:05:12 +0000
Message-ID: <1360235111.32479.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: tech mailinglists <mailinglists.tech@gmail.com>
Date: Thu, 7 Feb 2013 11:05:11 +0000
In-Reply-To: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
References: <CAMCOOJt=tvj+nkpms37Ndnrw7yUaPnozB8bSTY+BaiLQ=oL8Wg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 07 Feb 2013 13:16:48 +0000
Cc: xen-users <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] State of Stubdomains on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-devel to bcc.

On Thu, 2013-02-07 at 10:56 +0000, tech mailinglists wrote:

> I read in the wiki that stubdomains aren't support on NetBSD. Will
> subdoms be supported on NetBSD? Is someone working on that topic
> actually?

I don't follow NetBSD closely but AFAIK while you can't build a stubdom
on NetBSD stubdoms images built elsewhere should work.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:19:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13: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 1U3RNt-0002xp-C9; Thu, 07 Feb 2013 13:19:25 +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 1U3RNr-0002xc-BK
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:19:23 +0000
Received: from [85.158.137.99:10605] by server-15.bemta-3.messagelabs.com id
	AE/15-25405-AD9A3115; Thu, 07 Feb 2013 13:19:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360243139!20400267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 7 Feb 2013 13:19:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 13:19:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3RNS-000KY2-Kc; Thu, 07 Feb 2013 13:18:58 +0000
Date: Thu, 7 Feb 2013 13:18:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130207131858.GF77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
	<20130207120839.GC77133@ocelot.phlegethon.org>
	<1360239508.32479.64.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360239508.32479.64.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03/45] xen: arm: rename atag_paddr argument
	fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:18 +0000 on 07 Feb (1360239508), Ian Campbell wrote:
> On Thu, 2013-02-07 at 12:08 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956569), Ian Campbell wrote:
> > > We don't support ATAGs and this is always actually an FDT address.
> > 
> > Should we also change the code in head.S that call this an ATAG?
> 
> Yes, I think we should (thought I had actually!). Looks like I missed
> smpboot.c:start_secondary too (which doesn't use it but prototype is
> supposed to match).
> 
> Incrementally I think that would just be:

Yep.  With that, 

Acked-by: Tim Deegan <tim@xen.org>

> diff -r 8e8a289bc6c6 xen/arch/arm/arm32/head.S
> --- a/xen/arch/arm/arm32/head.S	Thu Dec 20 10:51:55 2012 +0000
> +++ b/xen/arch/arm/arm32/head.S	Thu Feb 07 12:16:31 2013 +0000
> @@ -73,7 +73,7 @@ past_zImage:
>  
>          /* Save the bootloader arguments in less-clobberable registers */
>          mov   r7, r1                 /* r7 := ARM-linux machine type */
> -        mov   r8, r2                 /* r8 := ATAG base address */
> +        mov   r8, r2                 /* r8 := DTB base address */
>  
>          /* Find out where we are */
>          ldr   r0, =start
> @@ -335,7 +335,7 @@ launch:
>          sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
>          mov   r0, r10                /* Marshal args: - phys_offset */
>          mov   r1, r7                 /*               - machine type */
> -        mov   r2, r8                 /*               - ATAG address */
> +        mov   r2, r8                 /*               - DTB address */
>          movs  r3, r12                /*               - CPU ID */
>          beq   start_xen              /* and disappear into the land of C */
>          b     start_secondary        /* (to the appropriate entry point) */
> diff -r 8e8a289bc6c6 xen/arch/arm/smpboot.c
> --- a/xen/arch/arm/smpboot.c	Thu Dec 20 10:51:55 2012 +0000
> +++ b/xen/arch/arm/smpboot.c	Thu Feb 07 12:16:31 2013 +0000
> @@ -133,7 +133,7 @@ make_cpus_ready(unsigned int max_cpus, u
>  /* Boot the current CPU */
>  void __cpuinit start_secondary(unsigned long boot_phys_offset,
>                                 unsigned long arm_type,
> -                               unsigned long atag_paddr,
> +                               unsigned long fdt_paddr,
>                                 unsigned long cpuid)
>  {
>      memset(get_cpu_info(), 0, sizeof (struct cpu_info));
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 07 13:19:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 13: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 1U3RNt-0002xp-C9; Thu, 07 Feb 2013 13:19:25 +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 1U3RNr-0002xc-BK
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:19:23 +0000
Received: from [85.158.137.99:10605] by server-15.bemta-3.messagelabs.com id
	AE/15-25405-AD9A3115; Thu, 07 Feb 2013 13:19:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360243139!20400267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 7 Feb 2013 13:19:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 13:19:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3RNS-000KY2-Kc; Thu, 07 Feb 2013 13:18:58 +0000
Date: Thu, 7 Feb 2013 13:18:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130207131858.GF77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-3-git-send-email-ian.campbell@citrix.com>
	<20130207120839.GC77133@ocelot.phlegethon.org>
	<1360239508.32479.64.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360239508.32479.64.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 03/45] xen: arm: rename atag_paddr argument
	fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:18 +0000 on 07 Feb (1360239508), Ian Campbell wrote:
> On Thu, 2013-02-07 at 12:08 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956569), Ian Campbell wrote:
> > > We don't support ATAGs and this is always actually an FDT address.
> > 
> > Should we also change the code in head.S that call this an ATAG?
> 
> Yes, I think we should (thought I had actually!). Looks like I missed
> smpboot.c:start_secondary too (which doesn't use it but prototype is
> supposed to match).
> 
> Incrementally I think that would just be:

Yep.  With that, 

Acked-by: Tim Deegan <tim@xen.org>

> diff -r 8e8a289bc6c6 xen/arch/arm/arm32/head.S
> --- a/xen/arch/arm/arm32/head.S	Thu Dec 20 10:51:55 2012 +0000
> +++ b/xen/arch/arm/arm32/head.S	Thu Feb 07 12:16:31 2013 +0000
> @@ -73,7 +73,7 @@ past_zImage:
>  
>          /* Save the bootloader arguments in less-clobberable registers */
>          mov   r7, r1                 /* r7 := ARM-linux machine type */
> -        mov   r8, r2                 /* r8 := ATAG base address */
> +        mov   r8, r2                 /* r8 := DTB base address */
>  
>          /* Find out where we are */
>          ldr   r0, =start
> @@ -335,7 +335,7 @@ launch:
>          sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
>          mov   r0, r10                /* Marshal args: - phys_offset */
>          mov   r1, r7                 /*               - machine type */
> -        mov   r2, r8                 /*               - ATAG address */
> +        mov   r2, r8                 /*               - DTB address */
>          movs  r3, r12                /*               - CPU ID */
>          beq   start_xen              /* and disappear into the land of C */
>          b     start_secondary        /* (to the appropriate entry point) */
> diff -r 8e8a289bc6c6 xen/arch/arm/smpboot.c
> --- a/xen/arch/arm/smpboot.c	Thu Dec 20 10:51:55 2012 +0000
> +++ b/xen/arch/arm/smpboot.c	Thu Feb 07 12:16:31 2013 +0000
> @@ -133,7 +133,7 @@ make_cpus_ready(unsigned int max_cpus, u
>  /* Boot the current CPU */
>  void __cpuinit start_secondary(unsigned long boot_phys_offset,
>                                 unsigned long arm_type,
> -                               unsigned long atag_paddr,
> +                               unsigned long fdt_paddr,
>                                 unsigned long cpuid)
>  {
>      memset(get_cpu_info(), 0, sizeof (struct cpu_info));
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 07 13:20:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 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 1U3ROf-00031X-Q5; Thu, 07 Feb 2013 13:20: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 1U3ROe-00031N-Vy
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:20:13 +0000
Received: from [85.158.143.35:4918] by server-2.bemta-4.messagelabs.com id
	DC/9D-01597-C0AA3115; Thu, 07 Feb 2013 13:20:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360243207!10488467!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13306 invoked from network); 7 Feb 2013 13:20:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 13:20:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1238963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 13:20: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.297.1; Thu, 7 Feb 2013
	13:20:07 +0000
Message-ID: <1360243206.32479.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 13:20:06 +0000
In-Reply-To: <20130207131247.GE77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
	<20130207131247.GE77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 06/45] xen: arm64: initial build + config
 changes, start of day 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 Thu, 2013-02-07 at 13:12 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956572), Ian Campbell wrote:
> > diff --git a/config/arm64.mk b/config/arm64.mk
> > new file mode 100644
> > index 0000000..b2457eb
> > --- /dev/null
> > +++ b/config/arm64.mk
> > @@ -0,0 +1,12 @@
> > +CONFIG_ARM := y
> > +CONFIG_ARM_64 := y
> > +CONFIG_ARM_$(XEN_OS) := y
> > +
> > +CFLAGS += #-marm -march= -mcpu= etc
> > +
> > +HAS_PL011 := y
> > +
> > +# Use only if calling $(LD) directly.
> > +LDFLAGS_DIRECT += -maarch64elf
> > +
> > +CONFIG_LOAD_ADDRESS ?= 0x80000000
> > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> > index f83bfee..2250366 100644
> > --- a/xen/arch/arm/Rules.mk
> > +++ b/xen/arch/arm/Rules.mk
> > @@ -25,6 +25,12 @@ arm32 := y
> >  arm64 := n
> >  endif
> >  
> > +ifeq ($(TARGET_SUBARCH),arm64)
> > +CFLAGS += -mcpu=generic
> 
> Should this go in config/arm64.mk?  I realise the equivalent flags for
> arm32 are in this file, just wondering if we ought to tidy them all into
> config/.

The x86 ones are in xen/arch/x86/Rules.mk too, I'm not averse to fixing
that though (perhaps as a subsequent cleanup though?)

> 
> > --- /dev/null
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -0,0 +1,405 @@

> > +/* Macro to print a string to the UART, if there is one.
> > + * Clobbers r0-r3. */
> > +#ifdef EARLY_UART_ADDRESS
> > +#define PRINT(_s)       \
> > +	adr   x0, 98f ; \
> > +	bl    puts    ; \
> > +	b     99f     ; \
> > +98:	.asciz _s     ; \
> > +	.align 2      ; \
> 
> Backslashes are misaligned here; I suspect because of hard tabs.

Yes, I'll fix all those up.


> > +/*
> > + * Exception Levels
> > + */
> > +#define EL0t   0x00000000
> > +#define EL1t   0x00000004
> > +#define EL1h   0x00000005
> > +#define EL2t   0x00000008
> > +#define EL2h   0x00000009
> > +#define EL3t   0x0000000c
> > +#define EL3h   0x0000000d
> 
> Do these belong in a header somewhere?  If not maybe they can go at the
> top of this file with the PT_ macros.

When I started working on 64-bit guests I ended up adding the exact same
thing to xen/include/public/arch-arm.h (to complement the existing
PSR_MODE_*). I'll do that here instead too.

[..]
> > +1:	PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
> > +	ldr   x1, =enter_el2_mode    /* VA of function */
> > +	add   x1, x1, x20            /* PA of function */
> > +	adr   x30, hyp               /* Set return address for call */
> > +	br    x1                     /* Call function */
> > +
> > +2:	PRINT("- Started in Hyp mode -\r\n")
> 
> Some confusion here between 'EL2' and 'Hyp' -- are they the same thing?
> Should we use 'el2' consistently?

Hyp is the AArch32 mode, EL2 is the AArch64 mode, they are sort of the
same thing. Should consistently use EL2 here though IMHO, so I'll change
that.

[...]
> > +.globl enter_el2_mode
> > +enter_el2_mode:
> > +        mov     x0, #0x30                       // RES1
> > +        orr     x0, x0, #(1 << 0)               // Non-secure EL1
> > +        orr     x0, x0, #(1 << 8)               // HVC enable
> > +        orr     x0, x0, #(1 << 10)              // 64-bit EL2
> 
> Is this any better than ldr'ing a magic constant?

This came pretty much directly from the bootwrapper stuff, not sure why
it is this way.

> > +
> > +        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
> > +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> > +        str     w0, [x1]
> > +
> > +1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
> 
> Can we use the gic.h constants here?  I gues the '/4' everywhere makes
> it ugly.

I'll try.

> > +        ldr     w0, [x1]
> > +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> > +        str     w0, [x1]
> > +
> > +        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
> > +        str     w0, [x1, #4]                    // GICC_PMR
> > +
> > +        msr     sctlr_el2, xzr
> > +
> > +        /*
> > +         * Prepare the switch to the EL2_SP1 mode from EL3
> > +         */
> > +        msr     elr_el3, x30                    // Return to desired function
> 
> Are you passing an argument in x30?  Or is x30 the link register?

x30 is lr, yes. In entry.S I define an alias, I think I'll do the same
here.

> > +        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
> > +        msr     spsr_el3, x1
> > +        eret
> 
> Maybe add an emacs block here?

Absolutely.

Thanks for the review.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 13:20:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 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 1U3ROf-00031X-Q5; Thu, 07 Feb 2013 13:20: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 1U3ROe-00031N-Vy
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 13:20:13 +0000
Received: from [85.158.143.35:4918] by server-2.bemta-4.messagelabs.com id
	DC/9D-01597-C0AA3115; Thu, 07 Feb 2013 13:20:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360243207!10488467!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13306 invoked from network); 7 Feb 2013 13:20:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 13:20:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1238963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 13:20: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.297.1; Thu, 7 Feb 2013
	13:20:07 +0000
Message-ID: <1360243206.32479.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 13:20:06 +0000
In-Reply-To: <20130207131247.GE77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
	<20130207131247.GE77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 06/45] xen: arm64: initial build + config
 changes, start of day 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 Thu, 2013-02-07 at 13:12 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956572), Ian Campbell wrote:
> > diff --git a/config/arm64.mk b/config/arm64.mk
> > new file mode 100644
> > index 0000000..b2457eb
> > --- /dev/null
> > +++ b/config/arm64.mk
> > @@ -0,0 +1,12 @@
> > +CONFIG_ARM := y
> > +CONFIG_ARM_64 := y
> > +CONFIG_ARM_$(XEN_OS) := y
> > +
> > +CFLAGS += #-marm -march= -mcpu= etc
> > +
> > +HAS_PL011 := y
> > +
> > +# Use only if calling $(LD) directly.
> > +LDFLAGS_DIRECT += -maarch64elf
> > +
> > +CONFIG_LOAD_ADDRESS ?= 0x80000000
> > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> > index f83bfee..2250366 100644
> > --- a/xen/arch/arm/Rules.mk
> > +++ b/xen/arch/arm/Rules.mk
> > @@ -25,6 +25,12 @@ arm32 := y
> >  arm64 := n
> >  endif
> >  
> > +ifeq ($(TARGET_SUBARCH),arm64)
> > +CFLAGS += -mcpu=generic
> 
> Should this go in config/arm64.mk?  I realise the equivalent flags for
> arm32 are in this file, just wondering if we ought to tidy them all into
> config/.

The x86 ones are in xen/arch/x86/Rules.mk too, I'm not averse to fixing
that though (perhaps as a subsequent cleanup though?)

> 
> > --- /dev/null
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -0,0 +1,405 @@

> > +/* Macro to print a string to the UART, if there is one.
> > + * Clobbers r0-r3. */
> > +#ifdef EARLY_UART_ADDRESS
> > +#define PRINT(_s)       \
> > +	adr   x0, 98f ; \
> > +	bl    puts    ; \
> > +	b     99f     ; \
> > +98:	.asciz _s     ; \
> > +	.align 2      ; \
> 
> Backslashes are misaligned here; I suspect because of hard tabs.

Yes, I'll fix all those up.


> > +/*
> > + * Exception Levels
> > + */
> > +#define EL0t   0x00000000
> > +#define EL1t   0x00000004
> > +#define EL1h   0x00000005
> > +#define EL2t   0x00000008
> > +#define EL2h   0x00000009
> > +#define EL3t   0x0000000c
> > +#define EL3h   0x0000000d
> 
> Do these belong in a header somewhere?  If not maybe they can go at the
> top of this file with the PT_ macros.

When I started working on 64-bit guests I ended up adding the exact same
thing to xen/include/public/arch-arm.h (to complement the existing
PSR_MODE_*). I'll do that here instead too.

[..]
> > +1:	PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
> > +	ldr   x1, =enter_el2_mode    /* VA of function */
> > +	add   x1, x1, x20            /* PA of function */
> > +	adr   x30, hyp               /* Set return address for call */
> > +	br    x1                     /* Call function */
> > +
> > +2:	PRINT("- Started in Hyp mode -\r\n")
> 
> Some confusion here between 'EL2' and 'Hyp' -- are they the same thing?
> Should we use 'el2' consistently?

Hyp is the AArch32 mode, EL2 is the AArch64 mode, they are sort of the
same thing. Should consistently use EL2 here though IMHO, so I'll change
that.

[...]
> > +.globl enter_el2_mode
> > +enter_el2_mode:
> > +        mov     x0, #0x30                       // RES1
> > +        orr     x0, x0, #(1 << 0)               // Non-secure EL1
> > +        orr     x0, x0, #(1 << 8)               // HVC enable
> > +        orr     x0, x0, #(1 << 10)              // 64-bit EL2
> 
> Is this any better than ldr'ing a magic constant?

This came pretty much directly from the bootwrapper stuff, not sure why
it is this way.

> > +
> > +        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
> > +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> > +        str     w0, [x1]
> > +
> > +1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
> 
> Can we use the gic.h constants here?  I gues the '/4' everywhere makes
> it ugly.

I'll try.

> > +        ldr     w0, [x1]
> > +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> > +        str     w0, [x1]
> > +
> > +        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
> > +        str     w0, [x1, #4]                    // GICC_PMR
> > +
> > +        msr     sctlr_el2, xzr
> > +
> > +        /*
> > +         * Prepare the switch to the EL2_SP1 mode from EL3
> > +         */
> > +        msr     elr_el3, x30                    // Return to desired function
> 
> Are you passing an argument in x30?  Or is x30 the link register?

x30 is lr, yes. In entry.S I define an alias, I think I'll do the same
here.

> > +        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
> > +        msr     spsr_el3, x1
> > +        eret
> 
> Maybe add an emacs block here?

Absolutely.

Thanks for the review.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 14:32:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14:32: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 1U3SWF-0005dG-Uu; Thu, 07 Feb 2013 14:32:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3SWE-0005d8-8W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:32:06 +0000
Received: from [85.158.139.83:32799] by server-14.bemta-5.messagelabs.com id
	E5/F9-06967-5EAB3115; Thu, 07 Feb 2013 14:32:05 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360247524!20016662!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2285 invoked from network); 7 Feb 2013 14:32:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 14:32:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1242388"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 14:32:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 7 Feb 2013
	14:32:04 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 14:32:03 +0000
Thread-Topic: [PATCH v7] cover: Coverage support
Thread-Index: Ac4FP+Xn2l9RS4APRLOhlOx/q+nyzQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458374@LONPMAILBOX01.citrite.net>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<511396B2.3030804@eu.citrix.com>
In-Reply-To: <511396B2.3030804@eu.citrix.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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v7] cover: Coverage 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, 2013-02-07 at 11:57 +0000, George Dunlap wrote:
> On 07/02/13 11:27, Frediano Ziglio wrote:
> > Updated set of patches for coverage.
> >
> > Changes:
> > - remove operation to check if coverage enabled
> > - add operation to read and reset coverage at same time
> > - updated utility to refrect changes above
> >
> 
> I've done a once-over and in principle I think this is a good series.  
> Thanks for doing it -- I think Xen has needed this for some time.  Just 
> a couple of high-level comments (and I haven't been following the 
> discussion, so please forgive me if I'm contradicting something someone 
> said somewhere else):
> 
> First, re the name -- is there any reason not to call it "gcov" (or 
> "xgcov" or something like that) in the patch series and the Xen 
> command-line option?  Since we're using the gcov format and the intent 
> (I presume) is to use the gcov tools to do the actual analysis,
> 

Do you mean gcov on first commit line? That's fine.

For the tool I used xencov like xenperf and xentrace. cov instead of
gcov allow to change the compiler in the future (I don't know,
clang/llvm perhaps?).

> Secondly, there doesn't seem to be any documentation.  A definition of 
> the Xen command-line term is an absolute minimum, and a brief markdown 
> how-to explaining how to enable the option and use it would be much 
> appreciated.
> 

You are right. I need some direction however. Which documentation are
you referring at? Wiki, internal one (docs directory in
xen-unstable.hg)?

>   -George

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 14:32:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14:32: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 1U3SWF-0005dG-Uu; Thu, 07 Feb 2013 14:32:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3SWE-0005d8-8W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:32:06 +0000
Received: from [85.158.139.83:32799] by server-14.bemta-5.messagelabs.com id
	E5/F9-06967-5EAB3115; Thu, 07 Feb 2013 14:32:05 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360247524!20016662!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2285 invoked from network); 7 Feb 2013 14:32:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 14:32:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1242388"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 14:32:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 7 Feb 2013
	14:32:04 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 14:32:03 +0000
Thread-Topic: [PATCH v7] cover: Coverage support
Thread-Index: Ac4FP+Xn2l9RS4APRLOhlOx/q+nyzQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458374@LONPMAILBOX01.citrite.net>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<511396B2.3030804@eu.citrix.com>
In-Reply-To: <511396B2.3030804@eu.citrix.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: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v7] cover: Coverage 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, 2013-02-07 at 11:57 +0000, George Dunlap wrote:
> On 07/02/13 11:27, Frediano Ziglio wrote:
> > Updated set of patches for coverage.
> >
> > Changes:
> > - remove operation to check if coverage enabled
> > - add operation to read and reset coverage at same time
> > - updated utility to refrect changes above
> >
> 
> I've done a once-over and in principle I think this is a good series.  
> Thanks for doing it -- I think Xen has needed this for some time.  Just 
> a couple of high-level comments (and I haven't been following the 
> discussion, so please forgive me if I'm contradicting something someone 
> said somewhere else):
> 
> First, re the name -- is there any reason not to call it "gcov" (or 
> "xgcov" or something like that) in the patch series and the Xen 
> command-line option?  Since we're using the gcov format and the intent 
> (I presume) is to use the gcov tools to do the actual analysis,
> 

Do you mean gcov on first commit line? That's fine.

For the tool I used xencov like xenperf and xentrace. cov instead of
gcov allow to change the compiler in the future (I don't know,
clang/llvm perhaps?).

> Secondly, there doesn't seem to be any documentation.  A definition of 
> the Xen command-line term is an absolute minimum, and a brief markdown 
> how-to explaining how to enable the option and use it would be much 
> appreciated.
> 

You are right. I need some direction however. Which documentation are
you referring at? Wiki, internal one (docs directory in
xen-unstable.hg)?

>   -George

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 14:34:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14:34: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 1U3SYa-0005t0-Ni; Thu, 07 Feb 2013 14:34: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 1U3SYZ-0005ss-PR
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:34:31 +0000
Received: from [193.109.254.147:32694] by server-6.bemta-14.messagelabs.com id
	8A/06-12010-77BB3115; Thu, 07 Feb 2013 14:34:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360247649!2054749!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 801 invoked from network); 7 Feb 2013 14:34:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 14:34:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3SY6-000Kij-1m; Thu, 07 Feb 2013 14:34:02 +0000
Date: Thu, 7 Feb 2013 14:34:01 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207143401.GG77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-7-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-7-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 07/45] xen: arm64: basic config and types
	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

At 15:56 +0000 on 23 Jan (1358956573), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Assuming all these orrible implementations are going to be replaced by
proper ARM64 ones, 

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 Thu Feb 07 14:34:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14:34: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 1U3SYa-0005t0-Ni; Thu, 07 Feb 2013 14:34: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 1U3SYZ-0005ss-PR
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:34:31 +0000
Received: from [193.109.254.147:32694] by server-6.bemta-14.messagelabs.com id
	8A/06-12010-77BB3115; Thu, 07 Feb 2013 14:34:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360247649!2054749!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 801 invoked from network); 7 Feb 2013 14:34:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 14:34:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3SY6-000Kij-1m; Thu, 07 Feb 2013 14:34:02 +0000
Date: Thu, 7 Feb 2013 14:34:01 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207143401.GG77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-7-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-7-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 07/45] xen: arm64: basic config and types
	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

At 15:56 +0000 on 23 Jan (1358956573), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Assuming all these orrible implementations are going to be replaced by
proper ARM64 ones, 

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 Thu Feb 07 14:42:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14:42: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 1U3Sfv-0006DW-Lr; Thu, 07 Feb 2013 14:42: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 1U3Sft-0006DR-RL
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:42:06 +0000
Received: from [85.158.138.51:42491] by server-13.bemta-3.messagelabs.com id
	6B/EE-20653-D3DB3115; Thu, 07 Feb 2013 14:42:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360248122!29256159!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9329 invoked from network); 7 Feb 2013 14:42:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 14:42:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3Sfq-000KkE-4v; Thu, 07 Feb 2013 14:42:02 +0000
Date: Thu, 7 Feb 2013 14:42:02 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207144202.GH77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/45] xen: arm64: 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Comparing the existing arm32 locks:

At 15:56 +0000 on 23 Jan (1358956574), Ian Campbell wrote:
> +static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
> +{
> +    ASSERT(_raw_spin_is_locked(lock));
> +
> +    smp_mb();
> +
> +    __asm__ __volatile__(
> +"   str     %1, [%0]\n"
> +    :
> +    : "r" (&lock->lock), "r" (0)
> +    : "cc");
> +
> +    dsb_sev();
> +}
> +
> +static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
> +{
> +    unsigned long tmp;
> +
> +    __asm__ __volatile__(
> +"   ldrex   %0, [%1]\n"
> +"   teq     %0, #0\n"
> +"   strexeq %0, %2, [%1]"
> +    : "=&r" (tmp)
> +    : "r" (&lock->lock), "r" (1)
> +    : "cc");
> +
> +    if (tmp == 0) {
> +        smp_mb();
> +        return 1;
> +    } else {
> +        return 0;
> +    }
> +}

with the new arm64 ones:

> +static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
> +{
> +    ASSERT(_raw_spin_is_locked(lock));
> +
> +    asm volatile(
> +        "       stlr    %w1, [%0]\n"
> +        : : "r" (&lock->lock), "r" (0) : "memory");
> +}
> +
> +static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
> +{
> +    unsigned int tmp;
> +
> +    asm volatile(
> +        "       ldaxr   %w0, [%1]\n"
> +        "       cbnz    %w0, 1f\n"
> +        "       stxr    %w0, %w2, [%1]\n"
> +        "1:\n"
> +        : "=&r" (tmp)
> +        : "r" (&lock->lock), "r" (1)
> +        : "memory");
> +
> +    return !tmp;
> +}

The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
that's useful if the slow path has a WFE in 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 Feb 07 14:42:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14:42: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 1U3Sfv-0006DW-Lr; Thu, 07 Feb 2013 14:42: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 1U3Sft-0006DR-RL
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:42:06 +0000
Received: from [85.158.138.51:42491] by server-13.bemta-3.messagelabs.com id
	6B/EE-20653-D3DB3115; Thu, 07 Feb 2013 14:42:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360248122!29256159!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9329 invoked from network); 7 Feb 2013 14:42:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 14:42:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3Sfq-000KkE-4v; Thu, 07 Feb 2013 14:42:02 +0000
Date: Thu, 7 Feb 2013 14:42:02 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207144202.GH77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/45] xen: arm64: 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Comparing the existing arm32 locks:

At 15:56 +0000 on 23 Jan (1358956574), Ian Campbell wrote:
> +static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
> +{
> +    ASSERT(_raw_spin_is_locked(lock));
> +
> +    smp_mb();
> +
> +    __asm__ __volatile__(
> +"   str     %1, [%0]\n"
> +    :
> +    : "r" (&lock->lock), "r" (0)
> +    : "cc");
> +
> +    dsb_sev();
> +}
> +
> +static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
> +{
> +    unsigned long tmp;
> +
> +    __asm__ __volatile__(
> +"   ldrex   %0, [%1]\n"
> +"   teq     %0, #0\n"
> +"   strexeq %0, %2, [%1]"
> +    : "=&r" (tmp)
> +    : "r" (&lock->lock), "r" (1)
> +    : "cc");
> +
> +    if (tmp == 0) {
> +        smp_mb();
> +        return 1;
> +    } else {
> +        return 0;
> +    }
> +}

with the new arm64 ones:

> +static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
> +{
> +    ASSERT(_raw_spin_is_locked(lock));
> +
> +    asm volatile(
> +        "       stlr    %w1, [%0]\n"
> +        : : "r" (&lock->lock), "r" (0) : "memory");
> +}
> +
> +static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
> +{
> +    unsigned int tmp;
> +
> +    asm volatile(
> +        "       ldaxr   %w0, [%1]\n"
> +        "       cbnz    %w0, 1f\n"
> +        "       stxr    %w0, %w2, [%1]\n"
> +        "1:\n"
> +        : "=&r" (tmp)
> +        : "r" (&lock->lock), "r" (1)
> +        : "memory");
> +
> +    return !tmp;
> +}

The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
that's useful if the slow path has a WFE in 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 Feb 07 14:42:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14: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 1U3SgO-0006Ex-3M; Thu, 07 Feb 2013 14:42: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 1U3SgM-0006Ef-BJ
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:42:34 +0000
Received: from [85.158.143.99:65499] by server-3.bemta-4.messagelabs.com id
	22/38-08920-85DB3115; Thu, 07 Feb 2013 14:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360248152!23076144!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20128 invoked from network); 7 Feb 2013 14:42:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 14:42:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1242880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 14: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.297.1; Thu, 7 Feb 2013
	14:42:32 +0000
Message-ID: <1360248150.32479.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 14:42:30 +0000
In-Reply-To: <20130207143401.GG77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-7-git-send-email-ian.campbell@citrix.com>
	<20130207143401.GG77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 07/45] xen: arm64: basic config and types
 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 Thu, 2013-02-07 at 14:34 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956573), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Assuming all these orrible implementations are going to be replaced by
> proper ARM64 ones, 

Yes, I should have said in the commit message: These are the Linux
asm-generic implementations, when optimised asm-arm64 variants arrive we
will pull those in.

> Acked-by: Tim Deegan <tim@xen.org>

Ta.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 14:42:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14: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 1U3SgO-0006Ex-3M; Thu, 07 Feb 2013 14:42: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 1U3SgM-0006Ef-BJ
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:42:34 +0000
Received: from [85.158.143.99:65499] by server-3.bemta-4.messagelabs.com id
	22/38-08920-85DB3115; Thu, 07 Feb 2013 14:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360248152!23076144!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20128 invoked from network); 7 Feb 2013 14:42:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 14:42:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1242880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 14: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.297.1; Thu, 7 Feb 2013
	14:42:32 +0000
Message-ID: <1360248150.32479.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 14:42:30 +0000
In-Reply-To: <20130207143401.GG77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-7-git-send-email-ian.campbell@citrix.com>
	<20130207143401.GG77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 07/45] xen: arm64: basic config and types
 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 Thu, 2013-02-07 at 14:34 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956573), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Assuming all these orrible implementations are going to be replaced by
> proper ARM64 ones, 

Yes, I should have said in the commit message: These are the Linux
asm-generic implementations, when optimised asm-arm64 variants arrive we
will pull those in.

> Acked-by: Tim Deegan <tim@xen.org>

Ta.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 14:48:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14: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 1U3SlS-0006dG-SY; Thu, 07 Feb 2013 14:47:50 +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 1U3SlQ-0006d8-W6
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:47:49 +0000
Received: from [85.158.139.83:28220] by server-13.bemta-5.messagelabs.com id
	CD/EC-06769-49EB3115; Thu, 07 Feb 2013 14:47:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360248467!30447393!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29967 invoked from network); 7 Feb 2013 14:47:47 -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; 7 Feb 2013 14:47:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3SlO-000KlY-Au; Thu, 07 Feb 2013 14:47:46 +0000
Date: Thu, 7 Feb 2013 14:47:46 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207144746.GI77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/45] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956575), Ian Campbell wrote:
> +#if 0 /* Currently unused in Xen */
> +/*
> + * 64-bit atomic operations.
> + */

Do we imagine that we're going to need them or can we just drop them
entirely?  I'd be happier to pull in an up-to-date set of atomic64 ops
from linux if we need them than to deliberately carry dead code.

Tim.
5A

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 14:48:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 14: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 1U3SlS-0006dG-SY; Thu, 07 Feb 2013 14:47:50 +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 1U3SlQ-0006d8-W6
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 14:47:49 +0000
Received: from [85.158.139.83:28220] by server-13.bemta-5.messagelabs.com id
	CD/EC-06769-49EB3115; Thu, 07 Feb 2013 14:47:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360248467!30447393!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29967 invoked from network); 7 Feb 2013 14:47:47 -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; 7 Feb 2013 14:47:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3SlO-000KlY-Au; Thu, 07 Feb 2013 14:47:46 +0000
Date: Thu, 7 Feb 2013 14:47:46 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207144746.GI77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/45] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956575), Ian Campbell wrote:
> +#if 0 /* Currently unused in Xen */
> +/*
> + * 64-bit atomic operations.
> + */

Do we imagine that we're going to need them or can we just drop them
entirely?  I'd be happier to pull in an up-to-date set of atomic64 ops
from linux if we need them than to deliberately carry dead code.

Tim.
5A

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:00:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:00: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 1U3SxP-0007M0-3V; Thu, 07 Feb 2013 15:00:11 +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 1U3SxN-0007Lt-Hq
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:00:09 +0000
Received: from [85.158.139.83:7150] by server-9.bemta-5.messagelabs.com id
	62/A1-24440-871C3115; Thu, 07 Feb 2013 15:00:08 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360249205!30864167!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18170 invoked from network); 7 Feb 2013 15:00:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:00:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6324517"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 15:00:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 10:00:04 -0500
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 1U3SxH-0006oV-NY;
	Thu, 07 Feb 2013 15:00:03 +0000
Message-ID: <5113BFBA.70200@eu.citrix.com>
Date: Thu, 7 Feb 2013 14:52:42 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<511396B2.3030804@eu.citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458374@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458374@LONPMAILBOX01.citrite.net>
Cc: "konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] cover: Coverage 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-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 07/02/13 14:32, Frediano Ziglio wrote:
> On Thu, 2013-02-07 at 11:57 +0000, George Dunlap wrote:
>> On 07/02/13 11:27, Frediano Ziglio wrote:
>>> Updated set of patches for coverage.
>>>
>>> Changes:
>>> - remove operation to check if coverage enabled
>>> - add operation to read and reset coverage at same time
>>> - updated utility to refrect changes above
>>>
>> I've done a once-over and in principle I think this is a good series.
>> Thanks for doing it -- I think Xen has needed this for some time.  Just
>> a couple of high-level comments (and I haven't been following the
>> discussion, so please forgive me if I'm contradicting something someone
>> said somewhere else):
>>
>> First, re the name -- is there any reason not to call it "gcov" (or
>> "xgcov" or something like that) in the patch series and the Xen
>> command-line option?  Since we're using the gcov format and the intent
>> (I presume) is to use the gcov tools to do the actual analysis,
>>
> Do you mean gcov on first commit line? That's fine.
>
> For the tool I used xencov like xenperf and xentrace. cov instead of
> gcov allow to change the compiler in the future (I don't know,
> clang/llvm perhaps?).

You know, for some reason I thought there was also a Xen command-line 
option as well, but there doesn't seem to be; just the option in 
Config.mk.  Sorry, my mistake.

>
>> Secondly, there doesn't seem to be any documentation.  A definition of
>> the Xen command-line term is an absolute minimum, and a brief markdown
>> how-to explaining how to enable the option and use it would be much
>> appreciated.
>>
> You are right. I need some direction however. Which documentation are
> you referring at? Wiki, internal one (docs directory in
> xen-unstable.hg)?

Well thinking that there was a Xen command-line option, I meant 
docs/misc/xen-command-line.markdown; but you can forget that now. :-)  
Adding a basic HOWTO to docs/misc/ in the markdown format would be 
appreciated as well.  There are some other examples in there to give you 
an idea what we might be after.

Following suit with small tools like xentrace, xenperf, &c, I think that 
as long as "xencov -h" gives you something useful, you don't need a man 
page.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:00:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:00: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 1U3SxP-0007M0-3V; Thu, 07 Feb 2013 15:00:11 +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 1U3SxN-0007Lt-Hq
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:00:09 +0000
Received: from [85.158.139.83:7150] by server-9.bemta-5.messagelabs.com id
	62/A1-24440-871C3115; Thu, 07 Feb 2013 15:00:08 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360249205!30864167!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18170 invoked from network); 7 Feb 2013 15:00:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:00:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6324517"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 15:00:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 10:00:04 -0500
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 1U3SxH-0006oV-NY;
	Thu, 07 Feb 2013 15:00:03 +0000
Message-ID: <5113BFBA.70200@eu.citrix.com>
Date: Thu, 7 Feb 2013 14:52:42 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1360236482-25452-1-git-send-email-frediano.ziglio@citrix.com>
	<511396B2.3030804@eu.citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458374@LONPMAILBOX01.citrite.net>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458374@LONPMAILBOX01.citrite.net>
Cc: "konrad@kernel.org" <konrad@kernel.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v7] cover: Coverage 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-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 07/02/13 14:32, Frediano Ziglio wrote:
> On Thu, 2013-02-07 at 11:57 +0000, George Dunlap wrote:
>> On 07/02/13 11:27, Frediano Ziglio wrote:
>>> Updated set of patches for coverage.
>>>
>>> Changes:
>>> - remove operation to check if coverage enabled
>>> - add operation to read and reset coverage at same time
>>> - updated utility to refrect changes above
>>>
>> I've done a once-over and in principle I think this is a good series.
>> Thanks for doing it -- I think Xen has needed this for some time.  Just
>> a couple of high-level comments (and I haven't been following the
>> discussion, so please forgive me if I'm contradicting something someone
>> said somewhere else):
>>
>> First, re the name -- is there any reason not to call it "gcov" (or
>> "xgcov" or something like that) in the patch series and the Xen
>> command-line option?  Since we're using the gcov format and the intent
>> (I presume) is to use the gcov tools to do the actual analysis,
>>
> Do you mean gcov on first commit line? That's fine.
>
> For the tool I used xencov like xenperf and xentrace. cov instead of
> gcov allow to change the compiler in the future (I don't know,
> clang/llvm perhaps?).

You know, for some reason I thought there was also a Xen command-line 
option as well, but there doesn't seem to be; just the option in 
Config.mk.  Sorry, my mistake.

>
>> Secondly, there doesn't seem to be any documentation.  A definition of
>> the Xen command-line term is an absolute minimum, and a brief markdown
>> how-to explaining how to enable the option and use it would be much
>> appreciated.
>>
> You are right. I need some direction however. Which documentation are
> you referring at? Wiki, internal one (docs directory in
> xen-unstable.hg)?

Well thinking that there was a Xen command-line option, I meant 
docs/misc/xen-command-line.markdown; but you can forget that now. :-)  
Adding a basic HOWTO to docs/misc/ in the markdown format would be 
appreciated as well.  There are some other examples in there to give you 
an idea what we might be after.

Following suit with small tools like xentrace, xenperf, &c, I think that 
as long as "xencov -h" gives you something useful, you don't need a man 
page.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:11:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:11: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 1U3T8N-0007wa-Ef; Thu, 07 Feb 2013 15:11:31 +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 1U3T8M-0007wV-8s
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:11:30 +0000
Received: from [85.158.143.99:64070] by server-1.bemta-4.messagelabs.com id
	E2/94-08839-124C3115; Thu, 07 Feb 2013 15:11:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360249887!30300118!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15173 invoked from network); 7 Feb 2013 15:11:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 15:11:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiy0MFtHG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-075-254.pools.arcor-ip.net [88.65.75.254])
	by smtp.strato.de (jorabe mo38) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j07a5cp17EY7XE ;
	Thu, 7 Feb 2013 16:11:27 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0BEAB1884C; Thu,  7 Feb 2013 16:11:26 +0100 (CET)
Date: Thu, 7 Feb 2013 16:11:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130207151126.GA31180@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <496E7A8DB9DCF257D29E10F2@nimrod.local>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 07, Alex Bligh wrote:

> >You can also level down an entire host using the cpuid_mask_* command
> >line options described in
> >http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
> 
> Thanks - that's really helpful. Looking at the documentation for cpuid=
> I can't see an obvious way of saying 'mask everything except the
> least common denominator of features' using the libxl method, without
> having prior knowledge of what each version of xen supports. I'm not
> even clear how to do this on the xend method (obviously I want to
> pass long bitstrings of zeros, but how many?). Am I missing something?

cpuid= is what the guest sees, so its not so much a feature of Xen
itself but what the host cpu provides. I'm not sure if Xen can emulate
certain important bits. The wikipedia CPUID entry has a list what each
bit means.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:11:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:11: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 1U3T8N-0007wa-Ef; Thu, 07 Feb 2013 15:11:31 +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 1U3T8M-0007wV-8s
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:11:30 +0000
Received: from [85.158.143.99:64070] by server-1.bemta-4.messagelabs.com id
	E2/94-08839-124C3115; Thu, 07 Feb 2013 15:11:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360249887!30300118!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYzNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15173 invoked from network); 7 Feb 2013 15:11:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 15:11:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiy0MFtHG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-075-254.pools.arcor-ip.net [88.65.75.254])
	by smtp.strato.de (jorabe mo38) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j07a5cp17EY7XE ;
	Thu, 7 Feb 2013 16:11:27 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0BEAB1884C; Thu,  7 Feb 2013 16:11:26 +0100 (CET)
Date: Thu, 7 Feb 2013 16:11:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130207151126.GA31180@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <496E7A8DB9DCF257D29E10F2@nimrod.local>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 07, Alex Bligh wrote:

> >You can also level down an entire host using the cpuid_mask_* command
> >line options described in
> >http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
> 
> Thanks - that's really helpful. Looking at the documentation for cpuid=
> I can't see an obvious way of saying 'mask everything except the
> least common denominator of features' using the libxl method, without
> having prior knowledge of what each version of xen supports. I'm not
> even clear how to do this on the xend method (obviously I want to
> pass long bitstrings of zeros, but how many?). Am I missing something?

cpuid= is what the guest sees, so its not so much a feature of Xen
itself but what the host cpu provides. I'm not sure if Xen can emulate
certain important bits. The wikipedia CPUID entry has a list what each
bit means.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:14:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TBE-0008IH-4m; Thu, 07 Feb 2013 15:14: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 1U3TBD-0008IA-9w
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:14:27 +0000
Received: from [85.158.143.99:19629] by server-1.bemta-4.messagelabs.com id
	FB/D8-08839-2D4C3115; Thu, 07 Feb 2013 15:14:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360250065!23082506!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19751 invoked from network); 7 Feb 2013 15:14:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 15:14:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TBB-000KrG-Ae; Thu, 07 Feb 2013 15:14:25 +0000
Date: Thu, 7 Feb 2013 15:14:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207151425.GJ77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-10-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/45] xen: arm: refactor co-pro and sysreg
	reg 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

At 15:56 +0000 on 23 Jan (1358956576), Ian Campbell wrote:
> AArch64 has removed the concept of co-processors replacing them with a
> combination of specific instructions (cache and tlb flushes etc) and
> system registers (which are understood by name in the assembler).
> 
> However most system registers are equivalent to a particular AArch32
> co-pro register and can be used by generic code in the same way. Note
> that the names of the registers differ (often only slightly)
> 
> For consistency it would be better to use only set of names in the
> common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
> arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
> differ #defines will be provided on 32-bit.
> 
> HSR_CPREG and friends are required even on 64-bit in order to decode
> traps from 32 bit guests.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 15:14:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TBE-0008IH-4m; Thu, 07 Feb 2013 15:14: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 1U3TBD-0008IA-9w
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:14:27 +0000
Received: from [85.158.143.99:19629] by server-1.bemta-4.messagelabs.com id
	FB/D8-08839-2D4C3115; Thu, 07 Feb 2013 15:14:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360250065!23082506!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19751 invoked from network); 7 Feb 2013 15:14:26 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 15:14:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TBB-000KrG-Ae; Thu, 07 Feb 2013 15:14:25 +0000
Date: Thu, 7 Feb 2013 15:14:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207151425.GJ77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-10-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/45] xen: arm: refactor co-pro and sysreg
	reg 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

At 15:56 +0000 on 23 Jan (1358956576), Ian Campbell wrote:
> AArch64 has removed the concept of co-processors replacing them with a
> combination of specific instructions (cache and tlb flushes etc) and
> system registers (which are understood by name in the assembler).
> 
> However most system registers are equivalent to a particular AArch32
> co-pro register and can be used by generic code in the same way. Note
> that the names of the registers differ (often only slightly)
> 
> For consistency it would be better to use only set of names in the
> common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
> arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
> differ #defines will be provided on 32-bit.
> 
> HSR_CPREG and friends are required even on 64-bit in order to decode
> traps from 32 bit guests.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 15:25:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TLK-0000JD-Bl; Thu, 07 Feb 2013 15:24: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 1U3TLI-0000J8-BC
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 15:24:52 +0000
Received: from [193.109.254.147:24839] by server-16.bemta-14.messagelabs.com
	id 96/81-25906-347C3115; Thu, 07 Feb 2013 15:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360250690!9329466!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5565 invoked from network); 7 Feb 2013 15:24:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:24:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1245440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:24: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.297.1; Thu, 7 Feb 2013 15:24:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3TLG-00058D-HI;
	Thu, 07 Feb 2013 15:24:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3TLG-0000W8-B6;
	Thu, 07 Feb 2013 15:24:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15442-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Feb 2013 15:24:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15442: 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 15442 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15442/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install     fail pass in 15440
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 15440

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15440
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15440
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15440

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-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop    fail in 15440 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 15440 never pass

version targeted for testing:
 xen                  6c1b12c884b4
baseline version:
 xen                  6c1b12c884b4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 07 15:25:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TLK-0000JD-Bl; Thu, 07 Feb 2013 15:24: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 1U3TLI-0000J8-BC
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 15:24:52 +0000
Received: from [193.109.254.147:24839] by server-16.bemta-14.messagelabs.com
	id 96/81-25906-347C3115; Thu, 07 Feb 2013 15:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360250690!9329466!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5565 invoked from network); 7 Feb 2013 15:24:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:24:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1245440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:24: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.297.1; Thu, 7 Feb 2013 15:24:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3TLG-00058D-HI;
	Thu, 07 Feb 2013 15:24:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3TLG-0000W8-B6;
	Thu, 07 Feb 2013 15:24:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15442-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 7 Feb 2013 15:24:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15442: 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 15442 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15442/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install     fail pass in 15440
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 15440

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15440
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15440
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15440

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-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop    fail in 15440 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 15440 never pass

version targeted for testing:
 xen                  6c1b12c884b4
baseline version:
 xen                  6c1b12c884b4

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 07 15:31:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TRb-0000Z8-D4; Thu, 07 Feb 2013 15:31:23 +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 1U3TRa-0000Z3-KC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:31:22 +0000
Received: from [85.158.143.35:13907] by server-3.bemta-4.messagelabs.com id
	C0/13-08920-9C8C3115; Thu, 07 Feb 2013 15:31:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360251080!14094156!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26587 invoked from network); 7 Feb 2013 15:31:21 -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; 7 Feb 2013 15:31:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TRX-000KuD-BY; Thu, 07 Feb 2013 15:31:19 +0000
Date: Thu, 7 Feb 2013 15:31:19 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207153119.GK77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-11-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-11-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/45] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956577), Ian Campbell wrote:
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/flushtlb.h
> @@ -0,0 +1,34 @@
> +#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
> +#define __ASM_ARM_ARM64_FLUSHTLB_H__
> +
> +/* Flush local TLBs, current VMID only */
> +static inline void flush_tlb_local(void)
> +{
> +    asm volatile(
> +        "dsb sy;"
> +        "tlbi vmalle1;" /* ,is ??? */

Good question.  I think probably not ',is'; at least not until we decide
on, and document, what inner & outer mean on a Xen system.

I see that the 32-bit equivalent does use IS; I think that's proabably
an error too.

Tim.

> +        "dsb sy;"
> +        "isb;"
> +        : : : "memory");
> +}
> +
> +/* Flush local TLBs, all VMIDs, non-hypervisor mode */
> +static inline void flush_tlb_all_local(void)
> +{
> +    asm volatile(
> +        "dsb sy;"
> +        "tlbi alle1;" /* ,is ??? */
> +        "dsb sy;"
> +        "isb;"
> +        : : : "memory");
> +}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:31:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TRb-0000Z8-D4; Thu, 07 Feb 2013 15:31:23 +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 1U3TRa-0000Z3-KC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:31:22 +0000
Received: from [85.158.143.35:13907] by server-3.bemta-4.messagelabs.com id
	C0/13-08920-9C8C3115; Thu, 07 Feb 2013 15:31:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360251080!14094156!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26587 invoked from network); 7 Feb 2013 15:31:21 -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; 7 Feb 2013 15:31:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TRX-000KuD-BY; Thu, 07 Feb 2013 15:31:19 +0000
Date: Thu, 7 Feb 2013 15:31:19 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207153119.GK77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-11-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-11-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/45] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956577), Ian Campbell wrote:
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/flushtlb.h
> @@ -0,0 +1,34 @@
> +#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
> +#define __ASM_ARM_ARM64_FLUSHTLB_H__
> +
> +/* Flush local TLBs, current VMID only */
> +static inline void flush_tlb_local(void)
> +{
> +    asm volatile(
> +        "dsb sy;"
> +        "tlbi vmalle1;" /* ,is ??? */

Good question.  I think probably not ',is'; at least not until we decide
on, and document, what inner & outer mean on a Xen system.

I see that the 32-bit equivalent does use IS; I think that's proabably
an error too.

Tim.

> +        "dsb sy;"
> +        "isb;"
> +        : : : "memory");
> +}
> +
> +/* Flush local TLBs, all VMIDs, non-hypervisor mode */
> +static inline void flush_tlb_all_local(void)
> +{
> +    asm volatile(
> +        "dsb sy;"
> +        "tlbi alle1;" /* ,is ??? */
> +        "dsb sy;"
> +        "isb;"
> +        : : : "memory");
> +}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:35:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:35: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 1U3TVJ-0000s8-2C; Thu, 07 Feb 2013 15:35:13 +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 1U3TVI-0000s3-BE
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:35:12 +0000
Received: from [85.158.143.99:8031] by server-2.bemta-4.messagelabs.com id
	BB/23-01597-FA9C3115; Thu, 07 Feb 2013 15:35:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360251301!24086920!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17895 invoked from network); 7 Feb 2013 15:35:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 15:35:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TV5-000Kut-Rw; Thu, 07 Feb 2013 15:34:59 +0000
Date: Thu, 7 Feb 2013 15:34:59 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207153459.GL77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130207144202.GH77133@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/45] xen: arm64: 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>
Content-Type: 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:42 +0000 on 07 Feb (1360248122), Tim Deegan wrote:
> The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> that's useful if the slow path has a WFE in it?

OK, I see the arm64 versions are using the new load-acquire/store-release
instructions so no DSBs or DMBs should be necessary.  Still puzzled by
the SEV.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:35:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:35: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 1U3TVJ-0000s8-2C; Thu, 07 Feb 2013 15:35:13 +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 1U3TVI-0000s3-BE
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:35:12 +0000
Received: from [85.158.143.99:8031] by server-2.bemta-4.messagelabs.com id
	BB/23-01597-FA9C3115; Thu, 07 Feb 2013 15:35:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360251301!24086920!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17895 invoked from network); 7 Feb 2013 15:35:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 15:35:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TV5-000Kut-Rw; Thu, 07 Feb 2013 15:34:59 +0000
Date: Thu, 7 Feb 2013 15:34:59 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207153459.GL77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130207144202.GH77133@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 08/45] xen: arm64: 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>
Content-Type: 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:42 +0000 on 07 Feb (1360248122), Tim Deegan wrote:
> The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> that's useful if the slow path has a WFE in it?

OK, I see the arm64 versions are using the new load-acquire/store-release
instructions so no DSBs or DMBs should be necessary.  Still puzzled by
the SEV.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:36:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:36: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 1U3TWS-0000vS-HM; Thu, 07 Feb 2013 15:36: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 1U3TWQ-0000v9-GT
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:36:22 +0000
Received: from [85.158.139.211:17095] by server-6.bemta-5.messagelabs.com id
	2E/21-01489-5F9C3115; Thu, 07 Feb 2013 15:36:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360251375!21226934!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14550 invoked from network); 7 Feb 2013 15:36:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 15:36:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TWJ-000KvP-D8; Thu, 07 Feb 2013 15:36:15 +0000
Date: Thu, 7 Feb 2013 15:36:15 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207153615.GM77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-12-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-12-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/45] xen: arm64: PTE 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

At 15:56 +0000 on 23 Jan (1358956578), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 15:36:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:36: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 1U3TWS-0000vS-HM; Thu, 07 Feb 2013 15:36: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 1U3TWQ-0000v9-GT
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:36:22 +0000
Received: from [85.158.139.211:17095] by server-6.bemta-5.messagelabs.com id
	2E/21-01489-5F9C3115; Thu, 07 Feb 2013 15:36:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360251375!21226934!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14550 invoked from network); 7 Feb 2013 15:36:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 15:36:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3TWJ-000KvP-D8; Thu, 07 Feb 2013 15:36:15 +0000
Date: Thu, 7 Feb 2013 15:36:15 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207153615.GM77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-12-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-12-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/45] xen: arm64: PTE 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

At 15:56 +0000 on 23 Jan (1358956578), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 15:43:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:43: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 1U3Td2-0001S0-Cr; Thu, 07 Feb 2013 15:43:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <trolle.selander@gmail.com>) id 1U3Td0-0001Rv-KL
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 15:43:10 +0000
Received: from [85.158.137.99:36620] by server-13.bemta-3.messagelabs.com id
	48/70-20653-D8BC3115; Thu, 07 Feb 2013 15:43:09 +0000
X-Env-Sender: trolle.selander@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360251773!20462402!1
X-Originating-IP: [209.85.217.176]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29927 invoked from network); 7 Feb 2013 15:42:54 -0000
Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com)
	(209.85.217.176)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:42:54 -0000
Received: by mail-lb0-f176.google.com with SMTP id s4so2189919lbc.21
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Feb 2013 07:42:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:content-type;
	bh=Kql18QuoYAV4DWDJGeosqtQPfNO6t+AZV1ziWSkn9ak=;
	b=rx521ue1l3MxTZmvtE2+UlhmdmZOVx5QzVhY40sVL+gK4nFIOHc3DE50a31ooaHwki
	x9M4BbmKJQzcF/kgaR1IVtg30JP8bq6cr4aPrBP0xUN8+TkngTYPQ8KhcSynhe7NPTlV
	XXbJetpsNdkXxbsV3uBGLhF4Num2klMRkTVgUF+NT5SPSSiyEYWjCQuK9ClI+4A8ncmg
	LMYgV5Zn0Rj49XYcMQKBoB6JqTMUCm6KAm7wHVpZMZs7pwzmfqFcu4LcCVl4+cWAamiN
	NmvmTaMufrQTTk5AgJ0Fevl6brHqoB0/vvauyS2SAWfrPQX9dOHsWZDdlllpffAKk5Ln
	ohQw==
MIME-Version: 1.0
X-Received: by 10.152.148.4 with SMTP id to4mr1693294lab.39.1360251773127;
	Thu, 07 Feb 2013 07:42:53 -0800 (PST)
Received: by 10.114.99.98 with HTTP; Thu, 7 Feb 2013 07:42:52 -0800 (PST)
In-Reply-To: <510BAC65.7080505@tiscali.it>
References: <50F036FA.9090500@tiscali.it>
	<alpine.DEB.2.02.1301141244460.4978@kaball.uk.xensource.com>
	<50F41548.1010508@tiscali.it>
	<alpine.DEB.2.02.1301141818360.4978@kaball.uk.xensource.com>
	<510BAC65.7080505@tiscali.it>
Date: Thu, 7 Feb 2013 10:42:52 -0500
Message-ID: <CAMhw156J7m2ZT8b8dyWxViqGeQv7qYxusdjXpoOr-d4ou4KoQQ@mail.gmail.com>
From: Trolle Selander <trolle.selander@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3] tools/libxl: Improve videoram 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: multipart/mixed; boundary="===============8645158753923189689=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8645158753923189689==
Content-Type: multipart/alternative; boundary=e89a8f2345b3be0a6c04d5244b62

--e89a8f2345b3be0a6c04d5244b62
Content-Type: text/plain; charset=ISO-8859-1

Just as a quick note, when I originally added the variable vram option in
"traditional" qemu-xen, it required patches to the vga BIOS as well as to
qemu. I'm not sure that those patches ever made it into upstream vgabios,
though I did post the patches to qemu-devel at one point.

/Trolle


On Fri, Feb 1, 2013 at 6:52 AM, Fabio Fantoni <fantonifabio@tiscali.it>wrote:

> Il 14/01/2013 19:21, Stefano Stabellini ha scritto:
>
>> I did a quick test and it seems that it should be possible to change the
>> amount of videoram for stdvga too using the same command line option,
>> however at the moment it just errors out. Therefore I am OK with this patch
>> only taking care of Cirrus for the moment.
>>
> I found details about stdvga on qemu upstream:
> http://xenbits.xen.org/gitweb/**?p=staging/qemu-upstream-**
> unstable.git;a=blob_plain;f=**docs/specs/standard-vga.txt;**hb=HEAD<http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=blob_plain;f=docs/specs/standard-vga.txt;hb=HEAD>
>
> It seems that stdvga memory by default is 16 mb, while xen reserves only 8
> mb by default and doen't logs any error.
> For cirrus, increasing memory seems to be correct and without error with
> my patch.
> WIth both cirrus and stdvga under qemu upstream with xen the performance
> are really poor even if I increase video memory, respect to qemu-only and
> qemu-kvm (without xen).
> Qxl is definitely not working under xen and conversely is ok on qemu-kvm
> and qemu-only.
>
> It seem that xen need change and/or fix to have full working emulated vga
> on qemu upstream.
> At the moment all emulated vgas have problems with xen that aren't present
> without xen.
>
> The performance differences are noticeable (in some case very big) with
> xen and without xen using resolution > 1024x768.
>
> Probably the first link explain the change/fix necessary in xen about vga
> (probably in hvmloader).
> I tried to do that more times failing but unfortunately I do not have
> sufficient knowledge about this.
> Can someone help me please?
>
> I think this is important, years ago the minimal resolution used on
> desktop was 1024x768, and no problem with actual vga setting but now
> minimal resolution seems increased to up 1366x768 and many people are using
> even higher resolutions.
> http://www.screenresolution.**org/year-2013/<http://www.screenresolution.org/year-2013/>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--e89a8f2345b3be0a6c04d5244b62
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just as a quick note, when I originally added the variable=
 vram option in &quot;traditional&quot; qemu-xen, it required patches to th=
e vga BIOS as well as to qemu. I&#39;m not sure that those patches ever mad=
e it into upstream vgabios, though I did post the patches to qemu-devel at =
one point.<div>
<br></div><div style>/Trolle</div></div><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">On Fri, Feb 1, 2013 at 6:52 AM, Fabio Fantoni <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:fantonifabio@tiscali.it" target=3D"_b=
lank">fantonifabio@tiscali.it</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"im">Il 14/01/2013 19:21, Stefa=
no Stabellini ha scritto:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
I did a quick test and it seems that it should be possible to change the am=
ount of videoram for stdvga too using the same command line option, however=
 at the moment it just errors out. Therefore I am OK with this patch only t=
aking care of Cirrus for the moment. <br>

</blockquote>
I found details about stdvga on qemu upstream:<br>
<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dstaging/qemu-upstream-unstabl=
e.git;a=3Dblob_plain;f=3Ddocs/specs/standard-vga.txt;hb=3DHEAD" target=3D"_=
blank">http://xenbits.xen.org/gitweb/<u></u>?p=3Dstaging/qemu-upstream-<u><=
/u>unstable.git;a=3Dblob_plain;f=3D<u></u>docs/specs/standard-vga.txt;<u></=
u>hb=3DHEAD</a><br>

<br>
It seems that stdvga memory by default is 16 mb, while xen reserves only 8 =
mb by default and doen&#39;t logs any error.<br>
For cirrus, increasing memory seems to be correct and without error with my=
 patch.<br>
WIth both cirrus and stdvga under qemu upstream with xen the performance ar=
e really poor even if I increase video memory, respect to qemu-only and qem=
u-kvm (without xen).<br>
Qxl is definitely not working under xen and conversely is ok on qemu-kvm an=
d qemu-only.<br>
<br>
It seem that xen need change and/or fix to have full working emulated vga o=
n qemu upstream.<br>
At the moment all emulated vgas have problems with xen that aren&#39;t pres=
ent without xen.<br>
<br>
The performance differences are noticeable (in some case very big) with xen=
 and without xen using resolution &gt; 1024x768.<br>
<br>
Probably the first link explain the change/fix necessary in xen about vga (=
probably in hvmloader).<br>
I tried to do that more times failing but unfortunately I do not have suffi=
cient knowledge about this.<br>
Can someone help me please?<br>
<br>
I think this is important, years ago the minimal resolution used on desktop=
 was 1024x768, and no problem with actual vga setting but now minimal resol=
ution seems increased to up 1366x768 and many people are using even higher =
resolutions.<br>

<a href=3D"http://www.screenresolution.org/year-2013/" target=3D"_blank">ht=
tp://www.screenresolution.<u></u>org/year-2013/</a><br>
<br>
<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.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br></div>

--e89a8f2345b3be0a6c04d5244b62--


--===============8645158753923189689==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8645158753923189689==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 15:43:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:43: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 1U3Td2-0001S0-Cr; Thu, 07 Feb 2013 15:43:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <trolle.selander@gmail.com>) id 1U3Td0-0001Rv-KL
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 15:43:10 +0000
Received: from [85.158.137.99:36620] by server-13.bemta-3.messagelabs.com id
	48/70-20653-D8BC3115; Thu, 07 Feb 2013 15:43:09 +0000
X-Env-Sender: trolle.selander@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360251773!20462402!1
X-Originating-IP: [209.85.217.176]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29927 invoked from network); 7 Feb 2013 15:42:54 -0000
Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com)
	(209.85.217.176)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:42:54 -0000
Received: by mail-lb0-f176.google.com with SMTP id s4so2189919lbc.21
	for <xen-devel@lists.xensource.com>;
	Thu, 07 Feb 2013 07:42:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:content-type;
	bh=Kql18QuoYAV4DWDJGeosqtQPfNO6t+AZV1ziWSkn9ak=;
	b=rx521ue1l3MxTZmvtE2+UlhmdmZOVx5QzVhY40sVL+gK4nFIOHc3DE50a31ooaHwki
	x9M4BbmKJQzcF/kgaR1IVtg30JP8bq6cr4aPrBP0xUN8+TkngTYPQ8KhcSynhe7NPTlV
	XXbJetpsNdkXxbsV3uBGLhF4Num2klMRkTVgUF+NT5SPSSiyEYWjCQuK9ClI+4A8ncmg
	LMYgV5Zn0Rj49XYcMQKBoB6JqTMUCm6KAm7wHVpZMZs7pwzmfqFcu4LcCVl4+cWAamiN
	NmvmTaMufrQTTk5AgJ0Fevl6brHqoB0/vvauyS2SAWfrPQX9dOHsWZDdlllpffAKk5Ln
	ohQw==
MIME-Version: 1.0
X-Received: by 10.152.148.4 with SMTP id to4mr1693294lab.39.1360251773127;
	Thu, 07 Feb 2013 07:42:53 -0800 (PST)
Received: by 10.114.99.98 with HTTP; Thu, 7 Feb 2013 07:42:52 -0800 (PST)
In-Reply-To: <510BAC65.7080505@tiscali.it>
References: <50F036FA.9090500@tiscali.it>
	<alpine.DEB.2.02.1301141244460.4978@kaball.uk.xensource.com>
	<50F41548.1010508@tiscali.it>
	<alpine.DEB.2.02.1301141818360.4978@kaball.uk.xensource.com>
	<510BAC65.7080505@tiscali.it>
Date: Thu, 7 Feb 2013 10:42:52 -0500
Message-ID: <CAMhw156J7m2ZT8b8dyWxViqGeQv7qYxusdjXpoOr-d4ou4KoQQ@mail.gmail.com>
From: Trolle Selander <trolle.selander@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v3] tools/libxl: Improve videoram 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: multipart/mixed; boundary="===============8645158753923189689=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8645158753923189689==
Content-Type: multipart/alternative; boundary=e89a8f2345b3be0a6c04d5244b62

--e89a8f2345b3be0a6c04d5244b62
Content-Type: text/plain; charset=ISO-8859-1

Just as a quick note, when I originally added the variable vram option in
"traditional" qemu-xen, it required patches to the vga BIOS as well as to
qemu. I'm not sure that those patches ever made it into upstream vgabios,
though I did post the patches to qemu-devel at one point.

/Trolle


On Fri, Feb 1, 2013 at 6:52 AM, Fabio Fantoni <fantonifabio@tiscali.it>wrote:

> Il 14/01/2013 19:21, Stefano Stabellini ha scritto:
>
>> I did a quick test and it seems that it should be possible to change the
>> amount of videoram for stdvga too using the same command line option,
>> however at the moment it just errors out. Therefore I am OK with this patch
>> only taking care of Cirrus for the moment.
>>
> I found details about stdvga on qemu upstream:
> http://xenbits.xen.org/gitweb/**?p=staging/qemu-upstream-**
> unstable.git;a=blob_plain;f=**docs/specs/standard-vga.txt;**hb=HEAD<http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=blob_plain;f=docs/specs/standard-vga.txt;hb=HEAD>
>
> It seems that stdvga memory by default is 16 mb, while xen reserves only 8
> mb by default and doen't logs any error.
> For cirrus, increasing memory seems to be correct and without error with
> my patch.
> WIth both cirrus and stdvga under qemu upstream with xen the performance
> are really poor even if I increase video memory, respect to qemu-only and
> qemu-kvm (without xen).
> Qxl is definitely not working under xen and conversely is ok on qemu-kvm
> and qemu-only.
>
> It seem that xen need change and/or fix to have full working emulated vga
> on qemu upstream.
> At the moment all emulated vgas have problems with xen that aren't present
> without xen.
>
> The performance differences are noticeable (in some case very big) with
> xen and without xen using resolution > 1024x768.
>
> Probably the first link explain the change/fix necessary in xen about vga
> (probably in hvmloader).
> I tried to do that more times failing but unfortunately I do not have
> sufficient knowledge about this.
> Can someone help me please?
>
> I think this is important, years ago the minimal resolution used on
> desktop was 1024x768, and no problem with actual vga setting but now
> minimal resolution seems increased to up 1366x768 and many people are using
> even higher resolutions.
> http://www.screenresolution.**org/year-2013/<http://www.screenresolution.org/year-2013/>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--e89a8f2345b3be0a6c04d5244b62
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just as a quick note, when I originally added the variable=
 vram option in &quot;traditional&quot; qemu-xen, it required patches to th=
e vga BIOS as well as to qemu. I&#39;m not sure that those patches ever mad=
e it into upstream vgabios, though I did post the patches to qemu-devel at =
one point.<div>
<br></div><div style>/Trolle</div></div><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">On Fri, Feb 1, 2013 at 6:52 AM, Fabio Fantoni <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:fantonifabio@tiscali.it" target=3D"_b=
lank">fantonifabio@tiscali.it</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"im">Il 14/01/2013 19:21, Stefa=
no Stabellini ha scritto:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
I did a quick test and it seems that it should be possible to change the am=
ount of videoram for stdvga too using the same command line option, however=
 at the moment it just errors out. Therefore I am OK with this patch only t=
aking care of Cirrus for the moment. <br>

</blockquote>
I found details about stdvga on qemu upstream:<br>
<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dstaging/qemu-upstream-unstabl=
e.git;a=3Dblob_plain;f=3Ddocs/specs/standard-vga.txt;hb=3DHEAD" target=3D"_=
blank">http://xenbits.xen.org/gitweb/<u></u>?p=3Dstaging/qemu-upstream-<u><=
/u>unstable.git;a=3Dblob_plain;f=3D<u></u>docs/specs/standard-vga.txt;<u></=
u>hb=3DHEAD</a><br>

<br>
It seems that stdvga memory by default is 16 mb, while xen reserves only 8 =
mb by default and doen&#39;t logs any error.<br>
For cirrus, increasing memory seems to be correct and without error with my=
 patch.<br>
WIth both cirrus and stdvga under qemu upstream with xen the performance ar=
e really poor even if I increase video memory, respect to qemu-only and qem=
u-kvm (without xen).<br>
Qxl is definitely not working under xen and conversely is ok on qemu-kvm an=
d qemu-only.<br>
<br>
It seem that xen need change and/or fix to have full working emulated vga o=
n qemu upstream.<br>
At the moment all emulated vgas have problems with xen that aren&#39;t pres=
ent without xen.<br>
<br>
The performance differences are noticeable (in some case very big) with xen=
 and without xen using resolution &gt; 1024x768.<br>
<br>
Probably the first link explain the change/fix necessary in xen about vga (=
probably in hvmloader).<br>
I tried to do that more times failing but unfortunately I do not have suffi=
cient knowledge about this.<br>
Can someone help me please?<br>
<br>
I think this is important, years ago the minimal resolution used on desktop=
 was 1024x768, and no problem with actual vga setting but now minimal resol=
ution seems increased to up 1366x768 and many people are using even higher =
resolutions.<br>

<a href=3D"http://www.screenresolution.org/year-2013/" target=3D"_blank">ht=
tp://www.screenresolution.<u></u>org/year-2013/</a><br>
<br>
<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.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br></div>

--e89a8f2345b3be0a6c04d5244b62--


--===============8645158753923189689==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8645158753923189689==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 15:50:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:50: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 1U3TjR-0001aX-8J; Thu, 07 Feb 2013 15:49:49 +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 1U3TjQ-0001aR-CM
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:49:48 +0000
Received: from [85.158.139.211:5052] by server-13.bemta-5.messagelabs.com id
	9E/0B-06769-B1DC3115; Thu, 07 Feb 2013 15:49:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360252186!19865202!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27672 invoked from network); 7 Feb 2013 15:49:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:49:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1246860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:49: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.297.1; Thu, 7 Feb 2013
	15:49:47 +0000
Message-ID: <1360252182.32479.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 15:49:42 +0000
In-Reply-To: <20130207144746.GI77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
	<20130207144746.GI77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 09/45] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 14:47 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956575), Ian Campbell wrote:
> > +#if 0 /* Currently unused in Xen */
> > +/*
> > + * 64-bit atomic operations.
> > + */
> 
> Do we imagine that we're going to need them or can we just drop them
> entirely?  I'd be happier to pull in an up-to-date set of atomic64 ops
> from linux if we need them than to deliberately carry dead code.

I've generally tried to keep these files as close to Linux as I can to
ease future syncing, but since future syncing in this case is likely to
mean "pull in a whole new implementation from Linux" perhaps I don't
care so much...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:50:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:50: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 1U3TjR-0001aX-8J; Thu, 07 Feb 2013 15:49:49 +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 1U3TjQ-0001aR-CM
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:49:48 +0000
Received: from [85.158.139.211:5052] by server-13.bemta-5.messagelabs.com id
	9E/0B-06769-B1DC3115; Thu, 07 Feb 2013 15:49:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360252186!19865202!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27672 invoked from network); 7 Feb 2013 15:49:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:49:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1246860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:49: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.297.1; Thu, 7 Feb 2013
	15:49:47 +0000
Message-ID: <1360252182.32479.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 15:49:42 +0000
In-Reply-To: <20130207144746.GI77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
	<20130207144746.GI77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 09/45] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 14:47 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956575), Ian Campbell wrote:
> > +#if 0 /* Currently unused in Xen */
> > +/*
> > + * 64-bit atomic operations.
> > + */
> 
> Do we imagine that we're going to need them or can we just drop them
> entirely?  I'd be happier to pull in an up-to-date set of atomic64 ops
> from linux if we need them than to deliberately carry dead code.

I've generally tried to keep these files as close to Linux as I can to
ease future syncing, but since future syncing in this case is likely to
mean "pull in a whole new implementation from Linux" perhaps I don't
care so much...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:51:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TlB-0001kk-Od; Thu, 07 Feb 2013 15: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.Campbell@citrix.com>) id 1U3TlA-0001kc-Bp
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:51:36 +0000
Received: from [85.158.139.83:51382] by server-16.bemta-5.messagelabs.com id
	F4/F4-14948-78DC3115; Thu, 07 Feb 2013 15:51:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360252219!28914939!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26723 invoked from network); 7 Feb 2013 15:50:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:50:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1246886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:50: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.297.1; Thu, 7 Feb 2013
	15:50:19 +0000
Message-ID: <1360252218.32479.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 15:50:18 +0000
In-Reply-To: <20130207144202.GH77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 08/45] xen: arm64: 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>
Content-Type: text/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, 2013-02-07 at 14:42 +0000, Tim Deegan wrote:
> The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> that's useful if the slow path has a WFE in it?

The "strl" in the 64 bit version is a store-release which has well
defined ordering semantics vs the ldar stuff in the other half.

The store in the 32-bit version is just a store so it needs barriers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:51:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3TlB-0001kk-Od; Thu, 07 Feb 2013 15: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.Campbell@citrix.com>) id 1U3TlA-0001kc-Bp
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:51:36 +0000
Received: from [85.158.139.83:51382] by server-16.bemta-5.messagelabs.com id
	F4/F4-14948-78DC3115; Thu, 07 Feb 2013 15:51:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360252219!28914939!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26723 invoked from network); 7 Feb 2013 15:50:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:50:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1246886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:50: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.297.1; Thu, 7 Feb 2013
	15:50:19 +0000
Message-ID: <1360252218.32479.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 15:50:18 +0000
In-Reply-To: <20130207144202.GH77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 08/45] xen: arm64: 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>
Content-Type: text/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, 2013-02-07 at 14:42 +0000, Tim Deegan wrote:
> The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> that's useful if the slow path has a WFE in it?

The "strl" in the 64 bit version is a store-release which has well
defined ordering semantics vs the ldar stuff in the other half.

The store in the 32-bit version is just a store so it needs barriers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:51:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:51: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 1U3TlG-0001nC-4X; Thu, 07 Feb 2013 15:51: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 1U3TlE-0001lR-98
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:51:40 +0000
Received: from [85.158.139.83:40830] by server-7.bemta-5.messagelabs.com id
	FC/AB-11121-B8DC3115; Thu, 07 Feb 2013 15:51:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360252298!27141238!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20602 invoked from network); 7 Feb 2013 15:51:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:51:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1246966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:51: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.297.1; Thu, 7 Feb 2013
	15:51:38 +0000
Message-ID: <1360252296.32479.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 15:51:36 +0000
In-Reply-To: <20130207153459.GL77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
	<20130207153459.GL77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 08/45] xen: arm64: 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>
Content-Type: text/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, 2013-02-07 at 15:34 +0000, Tim Deegan wrote:
> At 14:42 +0000 on 07 Feb (1360248122), Tim Deegan wrote:
> > The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> > 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> > that's useful if the slow path has a WFE in it?
> 
> OK, I see the arm64 versions are using the new load-acquire/store-release
> instructions so no DSBs or DMBs should be necessary.  Still puzzled by
> the SEV.

The ldar/strl generate the sev's as appropriate 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 Feb 07 15:51:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15:51: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 1U3TlG-0001nC-4X; Thu, 07 Feb 2013 15:51: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 1U3TlE-0001lR-98
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:51:40 +0000
Received: from [85.158.139.83:40830] by server-7.bemta-5.messagelabs.com id
	FC/AB-11121-B8DC3115; Thu, 07 Feb 2013 15:51:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360252298!27141238!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20602 invoked from network); 7 Feb 2013 15:51:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 15:51:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1246966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 15:51: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.297.1; Thu, 7 Feb 2013
	15:51:38 +0000
Message-ID: <1360252296.32479.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 15:51:36 +0000
In-Reply-To: <20130207153459.GL77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
	<20130207153459.GL77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 08/45] xen: arm64: 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>
Content-Type: text/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, 2013-02-07 at 15:34 +0000, Tim Deegan wrote:
> At 14:42 +0000 on 07 Feb (1360248122), Tim Deegan wrote:
> > The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> > 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> > that's useful if the slow path has a WFE in it?
> 
> OK, I see the arm64 versions are using the new load-acquire/store-release
> instructions so no DSBs or DMBs should be necessary.  Still puzzled by
> the SEV.

The ldar/strl generate the sev's as appropriate 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 Feb 07 15:59:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3Tsx-0002IX-4w; Thu, 07 Feb 2013 15:59:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3Tsv-0002IS-Ch
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:59:37 +0000
Received: from [85.158.143.99:42478] by server-2.bemta-4.messagelabs.com id
	1D/04-01597-86FC3115; Thu, 07 Feb 2013 15:59:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360252774!27771775!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30610 invoked from network); 7 Feb 2013 15:59:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-216.messagelabs.com with SMTP;
	7 Feb 2013 15:59:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 2AD8BC56196;
	Thu,  7 Feb 2013 15:59:21 +0000 (GMT)
Date: Thu, 07 Feb 2013 15:59:21 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <13FBA4F2DA636D516C1AAB94@nimrod.local>
In-Reply-To: <20130207151126.GA31180@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Olaf,

--On 7 February 2013 16:11:26 +0100 Olaf Hering <olaf@aepfle.de> wrote:

> cpuid= is what the guest sees, so its not so much a feature of Xen
> itself but what the host cpu provides. I'm not sure if Xen can emulate
> certain important bits. The wikipedia CPUID entry has a list what each
> bit means.

I know what how to find out what the bits mean. But in some sense
I don't care.

What I want to do is take a particular set of cpu features (which for the
sake of argument I will do by booting a kvm domain), and say "mask off
any additional cpuid flags beyond these", so if a new feature gets
introduced in the Xen codebase, it won't show in the guest. I think the
only thing I can do at the moment is check the Xen code for every cpu
feature Xen knows about, remove those I still want, and mask off the rest.
What I actually want to do is to say "please don't expose any features
other than these ones, and only expose these if the host supports them",
so that if we change versions of Xen to one supporting another feature,
we won't need to poke around in every domain config.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 15:59:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 15: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 1U3Tsx-0002IX-4w; Thu, 07 Feb 2013 15:59:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3Tsv-0002IS-Ch
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 15:59:37 +0000
Received: from [85.158.143.99:42478] by server-2.bemta-4.messagelabs.com id
	1D/04-01597-86FC3115; Thu, 07 Feb 2013 15:59:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360252774!27771775!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30610 invoked from network); 7 Feb 2013 15:59:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-216.messagelabs.com with SMTP;
	7 Feb 2013 15:59:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 2AD8BC56196;
	Thu,  7 Feb 2013 15:59:21 +0000 (GMT)
Date: Thu, 07 Feb 2013 15:59:21 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <13FBA4F2DA636D516C1AAB94@nimrod.local>
In-Reply-To: <20130207151126.GA31180@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Olaf,

--On 7 February 2013 16:11:26 +0100 Olaf Hering <olaf@aepfle.de> wrote:

> cpuid= is what the guest sees, so its not so much a feature of Xen
> itself but what the host cpu provides. I'm not sure if Xen can emulate
> certain important bits. The wikipedia CPUID entry has a list what each
> bit means.

I know what how to find out what the bits mean. But in some sense
I don't care.

What I want to do is take a particular set of cpu features (which for the
sake of argument I will do by booting a kvm domain), and say "mask off
any additional cpuid flags beyond these", so if a new feature gets
introduced in the Xen codebase, it won't show in the guest. I think the
only thing I can do at the moment is check the Xen code for every cpu
feature Xen knows about, remove those I still want, and mask off the rest.
What I actually want to do is to say "please don't expose any features
other than these ones, and only expose these if the host supports them",
so that if we change versions of Xen to one supporting another feature,
we won't need to poke around in every domain config.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:12:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:12: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 1U3U5X-0003Pi-Dk; Thu, 07 Feb 2013 16:12:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U5W-0003Pd-Jz
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:12:38 +0000
Received: from [85.158.138.51:37983] by server-5.bemta-3.messagelabs.com id
	A1/9A-04457-472D3115; Thu, 07 Feb 2013 16:12:36 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360253553!22580188!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20385 invoked from network); 7 Feb 2013 16:12:35 -0000
Received: from mail-da0-f43.google.com (HELO mail-da0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:35 -0000
Received: by mail-da0-f43.google.com with SMTP id u36so1301961dak.30
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:subject:date:message-id:x-mailer;
	bh=QxN+B+yJaA3ArHU/s6ly4lmR4YMRU0CUEKWCvePk4ak=;
	b=yXipKBubdh8uU5rVG0EOmaDdXrLDPe3G5mXem60DHgXs1igTErhZ7dKD5V0F/6gqmc
	x2BkWRH2j/wrd/MoUnytD0l6k09aUeP0CIWqxilCGKlST2v4MM4bThByCpAAfXhvh8M2
	RUJ5IqfySBhBLZit53SUqriOIwn6+gE8my0+LusCbIj5fTtaoxbmQOeQ/9s6ADvzS+DV
	rax96ovQdsFgcY+WtB9HJCB8Mgrh6naUd5j90wpvbI50DGnvZLtbsGOkBJLtTgBimFI4
	bRcCYVAPJ1qj6WBl/4ykWFgZ7QUE55MFTCK3aS8ZSVYwuAtBzIXFcQA6iC7ASVqVFDwY
	oP5w==
X-Received: by 10.66.52.116 with SMTP id s20mr7066102pao.70.1360253552793;
	Thu, 07 Feb 2013 08:12:32 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.28
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:32 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:05 +0800
Message-Id: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
Subject: [Xen-devel] Patch series for IGD 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>
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 series contains all the fixes required to produce a working IGD
passthrough box. All the changes are previously seen in the dev list but
not yet accepted. Some of them are out-dated and need some reshape.

Detailed description can be found later in each patch.

. [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags
. [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD
. [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific

Thanks,
Timothy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:12:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:12: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 1U3U5X-0003Pi-Dk; Thu, 07 Feb 2013 16:12:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U5W-0003Pd-Jz
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:12:38 +0000
Received: from [85.158.138.51:37983] by server-5.bemta-3.messagelabs.com id
	A1/9A-04457-472D3115; Thu, 07 Feb 2013 16:12:36 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360253553!22580188!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20385 invoked from network); 7 Feb 2013 16:12:35 -0000
Received: from mail-da0-f43.google.com (HELO mail-da0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:35 -0000
Received: by mail-da0-f43.google.com with SMTP id u36so1301961dak.30
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:subject:date:message-id:x-mailer;
	bh=QxN+B+yJaA3ArHU/s6ly4lmR4YMRU0CUEKWCvePk4ak=;
	b=yXipKBubdh8uU5rVG0EOmaDdXrLDPe3G5mXem60DHgXs1igTErhZ7dKD5V0F/6gqmc
	x2BkWRH2j/wrd/MoUnytD0l6k09aUeP0CIWqxilCGKlST2v4MM4bThByCpAAfXhvh8M2
	RUJ5IqfySBhBLZit53SUqriOIwn6+gE8my0+LusCbIj5fTtaoxbmQOeQ/9s6ADvzS+DV
	rax96ovQdsFgcY+WtB9HJCB8Mgrh6naUd5j90wpvbI50DGnvZLtbsGOkBJLtTgBimFI4
	bRcCYVAPJ1qj6WBl/4ykWFgZ7QUE55MFTCK3aS8ZSVYwuAtBzIXFcQA6iC7ASVqVFDwY
	oP5w==
X-Received: by 10.66.52.116 with SMTP id s20mr7066102pao.70.1360253552793;
	Thu, 07 Feb 2013 08:12:32 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.28
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:32 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:05 +0800
Message-Id: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
Subject: [Xen-devel] Patch series for IGD 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>
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 series contains all the fixes required to produce a working IGD
passthrough box. All the changes are previously seen in the dev list but
not yet accepted. Some of them are out-dated and need some reshape.

Detailed description can be found later in each patch.

. [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags
. [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD
. [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific

Thanks,
Timothy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:13:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:13: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 1U3U5g-0003Qz-D1; Thu, 07 Feb 2013 16:12:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U5e-0003Qk-UC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:12:47 +0000
Received: from [85.158.139.211:3273] by server-2.bemta-5.messagelabs.com id
	22/6B-16911-E72D3115; Thu, 07 Feb 2013 16:12:46 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360253562!21523549!1
X-Originating-IP: [209.85.220.54]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31053 invoked from network); 7 Feb 2013 16:12:44 -0000
Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com)
	(209.85.220.54)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:44 -0000
Received: by mail-pa0-f54.google.com with SMTP id fa10so1466294pad.13
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=iq3RI+sDuoJJo9BBZq+Wzqa2CLj+14VUznG3bqNDmvw=;
	b=zYQEZf0enWg0blchwqjyex4c3oXZbUBBGI5WEN31BQTXVRX+G5sx5OSW1CgVPBEKYh
	PkHiny3JzUqgF+fJ/iwnTT4KNdi7mYr9Gxfhl1rIvNPAh8k13Sketjw8LBcbKe9hMu7u
	q2ZM10jZprOeoVrGNv7q2RhxObqLqjIBhNuU/918Zd4+HUNXVSw0Lr+7fAAIJOhAl2p2
	6AOK5vrNOaOGXx0Q+57JMFNdkxKccPU21w1OTMpqZMs1Ffu6LdkD4rlEKTK2U2vRVwTM
	uKVvaIaUdIB98GUBx+J43YClggp82BYx137xBVZsLKEchwcnNC4UTwuagUvpxuiw3min
	YdLQ==
X-Received: by 10.66.77.200 with SMTP id u8mr7191064paw.43.1360253561390;
	Thu, 07 Feb 2013 08:12:41 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.37
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:40 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:07 +0800
Message-Id: <1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Cc: Rui Guo <firemeteor@users.sourceforge.net>
Subject: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
	bridge for IGD 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>
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 i915 driver probes chip version through PCH ISA bridge device / vendor ID.
Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in qemu-xen-trad,
which breaks the assumption of the driver. This change fixes the issue by
correctly exposing the ISA bridge to domU.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
               Rui Guo <firemeteor@users.sourceforge.net>
Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135548433715750
---
 hw/pci.c         |    5 -----
 hw/pci.h         |    5 +++++
 hw/pt-graphics.c |   24 +++++++++++++++++++++---
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index f051de1..d371bd7 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
     }
 }
 
-typedef struct {
-    PCIDevice dev;
-    PCIBus *bus;
-} PCIBridge;
-
 void pci_bridge_write_config(PCIDevice *d,
                              uint32_t address, uint32_t val, int len)
 {
diff --git a/hw/pci.h b/hw/pci.h
index edc58b6..c2acab9 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -222,6 +222,11 @@ struct PCIDevice {
     int irq_state[4];
 };
 
+typedef struct {
+    PCIDevice dev;
+    PCIBus *bus;
+} PCIBridge;
+
 extern char direct_pci_str[];
 extern int direct_pci_msitranslate;
 extern int direct_pci_power_mgmt;
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..5d4cf4a 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,6 +3,7 @@
  */
 
 #include "pass-through.h"
+#include "pci.h"
 #include "pci/header.h"
 #include "pci/pci.h"
 
@@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
 
-    if ( vid == PCI_VENDOR_ID_INTEL )
-        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
-                        pch_map_irq, "intel_bridge_1f");
+    if (vid == PCI_VENDOR_ID_INTEL) {
+        PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
+                sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
+
+        pci_config_set_vendor_id(s->dev.config, vid);
+        pci_config_set_device_id(s->dev.config, did);
+
+        s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
+        s->dev.config[PCI_COMMAND + 1] = 0x00;
+        s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
+        s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
+        s->dev.config[PCI_REVISION] = rid;
+        s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
+        pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
+        s->dev.config[PCI_LATENCY_TIMER] = 0x10;
+        s->dev.config[PCI_HEADER_TYPE] = 0x80;
+        s->dev.config[PCI_SEC_STATUS] = 0xa0;
+
+        s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
+    }
 }
 
 uint32_t igd_read_opregion(struct pt_dev *pci_dev)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:13:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:13: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 1U3U5g-0003Qz-D1; Thu, 07 Feb 2013 16:12:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U5e-0003Qk-UC
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:12:47 +0000
Received: from [85.158.139.211:3273] by server-2.bemta-5.messagelabs.com id
	22/6B-16911-E72D3115; Thu, 07 Feb 2013 16:12:46 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360253562!21523549!1
X-Originating-IP: [209.85.220.54]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31053 invoked from network); 7 Feb 2013 16:12:44 -0000
Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com)
	(209.85.220.54)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:44 -0000
Received: by mail-pa0-f54.google.com with SMTP id fa10so1466294pad.13
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=iq3RI+sDuoJJo9BBZq+Wzqa2CLj+14VUznG3bqNDmvw=;
	b=zYQEZf0enWg0blchwqjyex4c3oXZbUBBGI5WEN31BQTXVRX+G5sx5OSW1CgVPBEKYh
	PkHiny3JzUqgF+fJ/iwnTT4KNdi7mYr9Gxfhl1rIvNPAh8k13Sketjw8LBcbKe9hMu7u
	q2ZM10jZprOeoVrGNv7q2RhxObqLqjIBhNuU/918Zd4+HUNXVSw0Lr+7fAAIJOhAl2p2
	6AOK5vrNOaOGXx0Q+57JMFNdkxKccPU21w1OTMpqZMs1Ffu6LdkD4rlEKTK2U2vRVwTM
	uKVvaIaUdIB98GUBx+J43YClggp82BYx137xBVZsLKEchwcnNC4UTwuagUvpxuiw3min
	YdLQ==
X-Received: by 10.66.77.200 with SMTP id u8mr7191064paw.43.1360253561390;
	Thu, 07 Feb 2013 08:12:41 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.37
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:40 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:07 +0800
Message-Id: <1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Cc: Rui Guo <firemeteor@users.sourceforge.net>
Subject: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
	bridge for IGD 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>
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 i915 driver probes chip version through PCH ISA bridge device / vendor ID.
Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in qemu-xen-trad,
which breaks the assumption of the driver. This change fixes the issue by
correctly exposing the ISA bridge to domU.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
               Rui Guo <firemeteor@users.sourceforge.net>
Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135548433715750
---
 hw/pci.c         |    5 -----
 hw/pci.h         |    5 +++++
 hw/pt-graphics.c |   24 +++++++++++++++++++++---
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index f051de1..d371bd7 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -871,11 +871,6 @@ void pci_unplug_netifs(void)
     }
 }
 
-typedef struct {
-    PCIDevice dev;
-    PCIBus *bus;
-} PCIBridge;
-
 void pci_bridge_write_config(PCIDevice *d,
                              uint32_t address, uint32_t val, int len)
 {
diff --git a/hw/pci.h b/hw/pci.h
index edc58b6..c2acab9 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -222,6 +222,11 @@ struct PCIDevice {
     int irq_state[4];
 };
 
+typedef struct {
+    PCIDevice dev;
+    PCIBus *bus;
+} PCIBridge;
+
 extern char direct_pci_str[];
 extern int direct_pci_msitranslate;
 extern int direct_pci_power_mgmt;
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..5d4cf4a 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,6 +3,7 @@
  */
 
 #include "pass-through.h"
+#include "pci.h"
 #include "pci/header.h"
 #include "pci/pci.h"
 
@@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
 
-    if ( vid == PCI_VENDOR_ID_INTEL )
-        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
-                        pch_map_irq, "intel_bridge_1f");
+    if (vid == PCI_VENDOR_ID_INTEL) {
+        PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
+                sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
+
+        pci_config_set_vendor_id(s->dev.config, vid);
+        pci_config_set_device_id(s->dev.config, did);
+
+        s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
+        s->dev.config[PCI_COMMAND + 1] = 0x00;
+        s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
+        s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
+        s->dev.config[PCI_REVISION] = rid;
+        s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
+        pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
+        s->dev.config[PCI_LATENCY_TIMER] = 0x10;
+        s->dev.config[PCI_HEADER_TYPE] = 0x80;
+        s->dev.config[PCI_SEC_STATUS] = 0xa0;
+
+        s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
+    }
 }
 
 uint32_t igd_read_opregion(struct pt_dev *pci_dev)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:13:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:13: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 1U3U5a-0003QM-Vr; Thu, 07 Feb 2013 16:12:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U5Z-0003Q1-Eq
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:12:41 +0000
Received: from [85.158.139.83:17213] by server-11.bemta-5.messagelabs.com id
	36/2A-19159-872D3115; Thu, 07 Feb 2013 16:12:40 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360253558!23302391!1
X-Originating-IP: [209.85.210.42]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18013 invoked from network); 7 Feb 2013 16:12:39 -0000
Received: from mail-da0-f42.google.com (HELO mail-da0-f42.google.com)
	(209.85.210.42)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:39 -0000
Received: by mail-da0-f42.google.com with SMTP id z17so1292611dal.1
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=/CSvZQ3wT1rDEK2dTt4RwDN0ko9TPYmBl0k1MokYTXE=;
	b=axph/ch4V5aDqWuRJNikJJGxrOyWwmMs88pTw9DFCh5z92YfF36O7A6F76U1Qq1V0B
	8AC4u8XwcJPG3AH683z4rlAm/J/5uKwMJXvRo6JpWRUJl+T0Lve3icaQCa6XyP04F1BR
	ddrzOCwMEXZXaaGyz398PLgwI7I4chYC33e/FFUjd035IdfzCXMmoXINjy/qzziZdRyY
	cAVAPnPjeEUn2dmo/FyU96ho9sQP6mmKsZBBRlgZD7BBt1o9KXWXbB/3EYIlOBqiK/ZM
	dSb0O7fTXk6cFGZzlG6QZ6a6RhFdoMGDJ8NGUAFok3Ql6SB57iYZJDIye5sn/wAQCEOg
	CY3g==
X-Received: by 10.66.83.8 with SMTP id m8mr7217769pay.40.1360253557488;
	Thu, 07 Feb 2013 08:12:37 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.33
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:36 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:06 +0800
Message-Id: <1360253528-5424-2-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Cc: Rui Guo <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear
	all MSI 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>
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

"qemu-xen-trad: fix msi_translate with PV event delivery" added a
pt_msi_disable() call into pt_msgctrl_reg_write, clearing the MSI flags as a
consequence. MSIs get enabled again soon after by calling pt_msi_setup.

However the MSI flags are only setup once in the pt_msgctrl_reg_init function,
so from the QEMU point of view the device has lost some important properties,
like for example PCI_MSI_FLAGS_64BIT.

This patch fixes the bug by clearing only the MSI enabled/mapped/initialized
flags in pt_msi_disable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: G.R. <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135489879503075
---
 hw/pt-msi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 73f737d..b03b989 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -213,7 +213,7 @@ void pt_msi_disable(struct pt_dev *dev)
 
 out:
     /* clear msi info */
-    dev->msi->flags = 0;
+    dev->msi->flags &= ~(MSI_FLAG_UNINIT | PT_MSI_MAPPED | PCI_MSI_FLAGS_ENABLE);
     dev->msi->pirq = -1;
     dev->msi_trans_en = 0;
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:13:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:13: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 1U3U5a-0003QM-Vr; Thu, 07 Feb 2013 16:12:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U5Z-0003Q1-Eq
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:12:41 +0000
Received: from [85.158.139.83:17213] by server-11.bemta-5.messagelabs.com id
	36/2A-19159-872D3115; Thu, 07 Feb 2013 16:12:40 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360253558!23302391!1
X-Originating-IP: [209.85.210.42]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18013 invoked from network); 7 Feb 2013 16:12:39 -0000
Received: from mail-da0-f42.google.com (HELO mail-da0-f42.google.com)
	(209.85.210.42)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:39 -0000
Received: by mail-da0-f42.google.com with SMTP id z17so1292611dal.1
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=/CSvZQ3wT1rDEK2dTt4RwDN0ko9TPYmBl0k1MokYTXE=;
	b=axph/ch4V5aDqWuRJNikJJGxrOyWwmMs88pTw9DFCh5z92YfF36O7A6F76U1Qq1V0B
	8AC4u8XwcJPG3AH683z4rlAm/J/5uKwMJXvRo6JpWRUJl+T0Lve3icaQCa6XyP04F1BR
	ddrzOCwMEXZXaaGyz398PLgwI7I4chYC33e/FFUjd035IdfzCXMmoXINjy/qzziZdRyY
	cAVAPnPjeEUn2dmo/FyU96ho9sQP6mmKsZBBRlgZD7BBt1o9KXWXbB/3EYIlOBqiK/ZM
	dSb0O7fTXk6cFGZzlG6QZ6a6RhFdoMGDJ8NGUAFok3Ql6SB57iYZJDIye5sn/wAQCEOg
	CY3g==
X-Received: by 10.66.83.8 with SMTP id m8mr7217769pay.40.1360253557488;
	Thu, 07 Feb 2013 08:12:37 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.33
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:36 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:06 +0800
Message-Id: <1360253528-5424-2-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Cc: Rui Guo <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear
	all MSI 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>
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

"qemu-xen-trad: fix msi_translate with PV event delivery" added a
pt_msi_disable() call into pt_msgctrl_reg_write, clearing the MSI flags as a
consequence. MSIs get enabled again soon after by calling pt_msi_setup.

However the MSI flags are only setup once in the pt_msgctrl_reg_init function,
so from the QEMU point of view the device has lost some important properties,
like for example PCI_MSI_FLAGS_64BIT.

This patch fixes the bug by clearing only the MSI enabled/mapped/initialized
flags in pt_msi_disable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: G.R. <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135489879503075
---
 hw/pt-msi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 73f737d..b03b989 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -213,7 +213,7 @@ void pt_msi_disable(struct pt_dev *dev)
 
 out:
     /* clear msi info */
-    dev->msi->flags = 0;
+    dev->msi->flags &= ~(MSI_FLAG_UNINIT | PT_MSI_MAPPED | PCI_MSI_FLAGS_ENABLE);
     dev->msi->pirq = -1;
     dev->msi_trans_en = 0;
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:13:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:13: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 1U3U6E-0003Vy-RL; Thu, 07 Feb 2013 16:13:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U6D-0003VZ-99
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:13:21 +0000
Received: from [85.158.143.99:4277] by server-2.bemta-4.messagelabs.com id
	F1/57-01597-0A2D3115; Thu, 07 Feb 2013 16:13:20 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360253567!22575620!1
X-Originating-IP: [209.85.210.52]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27007 invoked from network); 7 Feb 2013 16:12:49 -0000
Received: from mail-da0-f52.google.com (HELO mail-da0-f52.google.com)
	(209.85.210.52)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:49 -0000
Received: by mail-da0-f52.google.com with SMTP id f10so1259955dak.25
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=+45zN9vFnKJwRcw4+Dik532zvPXvFsi0l7FqKEW7t5Q=;
	b=XrYgHBeTdtGy7DUuoq1Z6Ylp9Avmbskmw9GLEyiCCaHvgyDczervjhwWLgCpY5lEzL
	iCTacpbyK0Yn5UbSBlt/QwnnY7WXmyzbQkDA2CMj2zwVyb7wBKFOXRVwKS6sVwWvy0Tn
	SpGSjT1RhxsyOnPR4kQJIOgtBnK+FKM/H2wC/33oEwOPentuVINjzpdFHWyRvQ8mH5Qi
	N/t43RK++U2czGI24O+sn0IJRtGT9slcWQgVWzp1SyEBa9ZZUowGJi9AE1bBGn+T8pqG
	kM4kpKwmjrfXv4HEI3cJCdWnF3hUI6EjXfcaUpx1sJXFOGApPDmi4QpFTvrs/3UQyjaS
	akoQ==
X-Received: by 10.66.84.202 with SMTP id b10mr7051318paz.71.1360253566989;
	Thu, 07 Feb 2013 08:12:46 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.43
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:46 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:08 +0800
Message-Id: <1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Cc: Rui Guo <firemeteor@users.sourceforge.net>
Subject: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
	vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

As part of the change, the init for pt_pci_host() return value
has to be modified. With an init of -1 all the return value
smaller than a double word will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@gmail.com>,
               Rui Guo <firemeteor@users.sourceforge.net>
Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135748187808766
---
 hw/pass-through.c |    2 +-
 hw/pt-graphics.c  |   69 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 64 insertions(+), 7 deletions(-)

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 304c438..2e795e1 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2101,7 +2101,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 5d4cf4a..269aade 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -144,6 +144,53 @@ write_default:
     pci_default_write_config(pci_dev, config_addr, val, len);
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+/*
+ * This function returns 0 is the value hasn't been
+ * updated. That mean the offset doesn't anything to
+ * do with the vendor capability.
+ */
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t *val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (!vendor_cap)
+        return 0;
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+        return 0;
+
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+    {
+        *val = vendor_cap;
+        return 1;
+    }
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+    {
+        *val = 0;
+        return 1;
+    }
+
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+    if (config_addr >= vendor_cap &&
+            config_addr + len <= vendor_cap + cap_size)
+    {
+        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+        return 1;
+    }
+
+    return 0;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge;
@@ -151,12 +198,22 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 
     assert(pci_dev->devfn == 0x00);
     if ( !igd_passthru )
-        goto read_default;
+    {
+        val = pci_default_read_config(pci_dev, config_addr, len);
+        goto read_return;
+    }
 
+    /* Exposing writable register does not lead to security risk since this
+       only apply to read. This may confuse the guest, but it works good so far.
+       Will switch to mask & merge style only if this is proved broken.
+       Note: Always expose aligned address if any byte of the dword is to be
+       exposed. This provides a consistent view, at least for read. */
     switch (config_addr)
     {
         case 0x00:        /* vendor id */
         case 0x02:        /* device id */
+        case 0x04:        /* command */
+        case 0x06:        /* status, needed for the cap list bit*/
         case 0x08:        /* revision id */
         case 0x2c:        /* sybsystem vendor id */
         case 0x2e:        /* sybsystem id */
@@ -169,7 +226,9 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa8:        /* SNB: base of GTT stolen memory */
             break;
         default:
-            goto read_default;
+            if (!(igd_passthru && igd_pci_read_vendor_cap(pci_dev, config_addr, len, &val)))
+                val = pci_default_read_config(pci_dev, config_addr, len);
+            goto read_return;
     }
 
     /* Host read */
@@ -180,15 +239,13 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
     }
 
     val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+
+read_return:
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
     PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
                config_addr, len, val);
 #endif
     return val;
-   
-read_default:
-   
-   return pci_default_read_config(pci_dev, config_addr, len);
 }
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:13:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:13: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 1U3U6E-0003Vy-RL; Thu, 07 Feb 2013 16:13:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3U6D-0003VZ-99
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:13:21 +0000
Received: from [85.158.143.99:4277] by server-2.bemta-4.messagelabs.com id
	F1/57-01597-0A2D3115; Thu, 07 Feb 2013 16:13:20 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360253567!22575620!1
X-Originating-IP: [209.85.210.52]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27007 invoked from network); 7 Feb 2013 16:12:49 -0000
Received: from mail-da0-f52.google.com (HELO mail-da0-f52.google.com)
	(209.85.210.52)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:12:49 -0000
Received: by mail-da0-f52.google.com with SMTP id f10so1259955dak.25
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 08:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references;
	bh=+45zN9vFnKJwRcw4+Dik532zvPXvFsi0l7FqKEW7t5Q=;
	b=XrYgHBeTdtGy7DUuoq1Z6Ylp9Avmbskmw9GLEyiCCaHvgyDczervjhwWLgCpY5lEzL
	iCTacpbyK0Yn5UbSBlt/QwnnY7WXmyzbQkDA2CMj2zwVyb7wBKFOXRVwKS6sVwWvy0Tn
	SpGSjT1RhxsyOnPR4kQJIOgtBnK+FKM/H2wC/33oEwOPentuVINjzpdFHWyRvQ8mH5Qi
	N/t43RK++U2czGI24O+sn0IJRtGT9slcWQgVWzp1SyEBa9ZZUowGJi9AE1bBGn+T8pqG
	kM4kpKwmjrfXv4HEI3cJCdWnF3hUI6EjXfcaUpx1sJXFOGApPDmi4QpFTvrs/3UQyjaS
	akoQ==
X-Received: by 10.66.84.202 with SMTP id b10mr7051318paz.71.1360253566989;
	Thu, 07 Feb 2013 08:12:46 -0800 (PST)
Received: from localhost.localdomain ([101.224.56.63])
	by mx.google.com with ESMTPS id e6sm47041338paw.16.2013.02.07.08.12.43
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 08:12:46 -0800 (PST)
From: Rui Guo <firemeteor@users.sourceforge.net>
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	stefano.stabellini@citrix.com
Date: Fri,  8 Feb 2013 00:12:08 +0800
Message-Id: <1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Cc: Rui Guo <firemeteor@users.sourceforge.net>
Subject: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
	vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

As part of the change, the init for pt_pci_host() return value
has to be modified. With an init of -1 all the return value
smaller than a double word will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@gmail.com>,
               Rui Guo <firemeteor@users.sourceforge.net>
Tested-by: Rui Guo <firemeteor@users.sourceforge.net>
Xen-devel: http://marc.info/?l=xen-devel&m=135748187808766
---
 hw/pass-through.c |    2 +-
 hw/pt-graphics.c  |   69 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 64 insertions(+), 7 deletions(-)

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 304c438..2e795e1 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2101,7 +2101,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 5d4cf4a..269aade 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -144,6 +144,53 @@ write_default:
     pci_default_write_config(pci_dev, config_addr, val, len);
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+/*
+ * This function returns 0 is the value hasn't been
+ * updated. That mean the offset doesn't anything to
+ * do with the vendor capability.
+ */
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t *val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (!vendor_cap)
+        return 0;
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+        return 0;
+
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+    {
+        *val = vendor_cap;
+        return 1;
+    }
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+    {
+        *val = 0;
+        return 1;
+    }
+
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+    if (config_addr >= vendor_cap &&
+            config_addr + len <= vendor_cap + cap_size)
+    {
+        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+        return 1;
+    }
+
+    return 0;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge;
@@ -151,12 +198,22 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 
     assert(pci_dev->devfn == 0x00);
     if ( !igd_passthru )
-        goto read_default;
+    {
+        val = pci_default_read_config(pci_dev, config_addr, len);
+        goto read_return;
+    }
 
+    /* Exposing writable register does not lead to security risk since this
+       only apply to read. This may confuse the guest, but it works good so far.
+       Will switch to mask & merge style only if this is proved broken.
+       Note: Always expose aligned address if any byte of the dword is to be
+       exposed. This provides a consistent view, at least for read. */
     switch (config_addr)
     {
         case 0x00:        /* vendor id */
         case 0x02:        /* device id */
+        case 0x04:        /* command */
+        case 0x06:        /* status, needed for the cap list bit*/
         case 0x08:        /* revision id */
         case 0x2c:        /* sybsystem vendor id */
         case 0x2e:        /* sybsystem id */
@@ -169,7 +226,9 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa8:        /* SNB: base of GTT stolen memory */
             break;
         default:
-            goto read_default;
+            if (!(igd_passthru && igd_pci_read_vendor_cap(pci_dev, config_addr, len, &val)))
+                val = pci_default_read_config(pci_dev, config_addr, len);
+            goto read_return;
     }
 
     /* Host read */
@@ -180,15 +239,13 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
     }
 
     val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+
+read_return:
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
     PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
                config_addr, len, val);
 #endif
     return val;
-   
-read_default:
-   
-   return pci_default_read_config(pci_dev, config_addr, len);
 }
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:14:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:14: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 1U3U7Q-0003if-Bx; Thu, 07 Feb 2013 16:14:36 +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 1U3U7O-0003iL-V7
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:14:35 +0000
Received: from [85.158.143.35:50559] by server-2.bemta-4.messagelabs.com id
	78/F8-01597-AE2D3115; Thu, 07 Feb 2013 16:14:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360253673!14484008!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19642 invoked from network); 7 Feb 2013 16:14:33 -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; 7 Feb 2013 16:14:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3U7M-000L3j-42; Thu, 07 Feb 2013 16:14:32 +0000
Date: Thu, 7 Feb 2013 16:14:32 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207161432.GN77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache 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

At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> This drops the
>     "m" (*_p)
> asm contraint. I can't figure out what this was for.
> 

It's to stop the compiler hoisting writes to the wrong side of the
flush.  It's the lighter-weight equivalent to the "memory" clobber in
the range version.  By moving from inline "dsb;" to dsb() you've
reintroduced the full memory clobber here anyway. :(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:14:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:14: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 1U3U7Q-0003if-Bx; Thu, 07 Feb 2013 16:14:36 +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 1U3U7O-0003iL-V7
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:14:35 +0000
Received: from [85.158.143.35:50559] by server-2.bemta-4.messagelabs.com id
	78/F8-01597-AE2D3115; Thu, 07 Feb 2013 16:14:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1360253673!14484008!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19642 invoked from network); 7 Feb 2013 16:14:33 -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; 7 Feb 2013 16:14:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3U7M-000L3j-42; Thu, 07 Feb 2013 16:14:32 +0000
Date: Thu, 7 Feb 2013 16:14:32 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207161432.GN77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache 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

At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> This drops the
>     "m" (*_p)
> asm contraint. I can't figure out what this was for.
> 

It's to stop the compiler hoisting writes to the wrong side of the
flush.  It's the lighter-weight equivalent to the "memory" clobber in
the range version.  By moving from inline "dsb;" to dsb() you've
reintroduced the full memory clobber here anyway. :(


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:17:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:17: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 1U3U9k-00041K-Tq; Thu, 07 Feb 2013 16:17: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 1U3U9i-000414-Rc
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:16:59 +0000
Received: from [85.158.139.211:32222] by server-12.bemta-5.messagelabs.com id
	39/9C-20195-A73D3115; Thu, 07 Feb 2013 16:16:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360253817!21533051!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28350 invoked from network); 7 Feb 2013 16:16:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1248290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:16: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.297.1; Thu, 7 Feb 2013
	16:16:57 +0000
Message-ID: <1360253815.32479.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Thu, 7 Feb 2013 16:16:55 +0000
In-Reply-To: <13FBA4F2DA636D516C1AAB94@nimrod.local>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 15:59 +0000, Alex Bligh wrote:
> Olaf,
> 
> --On 7 February 2013 16:11:26 +0100 Olaf Hering <olaf@aepfle.de> wrote:
> 
> > cpuid= is what the guest sees, so its not so much a feature of Xen
> > itself but what the host cpu provides. I'm not sure if Xen can emulate
> > certain important bits. The wikipedia CPUID entry has a list what each
> > bit means.
> 
> I know what how to find out what the bits mean. But in some sense
> I don't care.
> 
> What I want to do is take a particular set of cpu features (which for the
> sake of argument I will do by booting a kvm domain), and say "mask off
> any additional cpuid flags beyond these", so if a new feature gets
> introduced in the Xen codebase, it won't show in the guest. I think the
> only thing I can do at the moment is check the Xen code for every cpu
> feature Xen knows about, remove those I still want, and mask off the rest.
> What I actually want to do is to say "please don't expose any features
> other than these ones, and only expose these if the host supports them",
> so that if we change versions of Xen to one supporting another feature,
> we won't need to poke around in every domain config.

I think you can do this using what xl.cfg(5) describes as the "xend"
syntax, by setting all the ones you aren't explicitly exposing to 0.

The "libxl syntax" is currently "=host,flag=value,..." which starts from
the host and modifies the flags. I can't offhand thing of a reason why
we wouldn't also want to support a different keyword ("explicit"?) which
means "starting from an empty slate add these". Patches accepted...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:17:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:17: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 1U3U9k-00041K-Tq; Thu, 07 Feb 2013 16:17: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 1U3U9i-000414-Rc
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:16:59 +0000
Received: from [85.158.139.211:32222] by server-12.bemta-5.messagelabs.com id
	39/9C-20195-A73D3115; Thu, 07 Feb 2013 16:16:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360253817!21533051!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28350 invoked from network); 7 Feb 2013 16:16:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1248290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:16: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.297.1; Thu, 7 Feb 2013
	16:16:57 +0000
Message-ID: <1360253815.32479.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Thu, 7 Feb 2013 16:16:55 +0000
In-Reply-To: <13FBA4F2DA636D516C1AAB94@nimrod.local>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 15:59 +0000, Alex Bligh wrote:
> Olaf,
> 
> --On 7 February 2013 16:11:26 +0100 Olaf Hering <olaf@aepfle.de> wrote:
> 
> > cpuid= is what the guest sees, so its not so much a feature of Xen
> > itself but what the host cpu provides. I'm not sure if Xen can emulate
> > certain important bits. The wikipedia CPUID entry has a list what each
> > bit means.
> 
> I know what how to find out what the bits mean. But in some sense
> I don't care.
> 
> What I want to do is take a particular set of cpu features (which for the
> sake of argument I will do by booting a kvm domain), and say "mask off
> any additional cpuid flags beyond these", so if a new feature gets
> introduced in the Xen codebase, it won't show in the guest. I think the
> only thing I can do at the moment is check the Xen code for every cpu
> feature Xen knows about, remove those I still want, and mask off the rest.
> What I actually want to do is to say "please don't expose any features
> other than these ones, and only expose these if the host supports them",
> so that if we change versions of Xen to one supporting another feature,
> we won't need to poke around in every domain config.

I think you can do this using what xl.cfg(5) describes as the "xend"
syntax, by setting all the ones you aren't explicitly exposing to 0.

The "libxl syntax" is currently "=host,flag=value,..." which starts from
the host and modifies the flags. I can't offhand thing of a reason why
we wouldn't also want to support a different keyword ("explicit"?) which
means "starting from an empty slate add these". Patches accepted...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:19:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UCF-0004Cm-1W; Thu, 07 Feb 2013 16:19:35 +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 1U3UCD-0004Ce-5I
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:19:33 +0000
Received: from [85.158.139.211:35057] by server-13.bemta-5.messagelabs.com id
	D2/53-06769-414D3115; Thu, 07 Feb 2013 16:19:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360253971!21524696!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28931 invoked from network); 7 Feb 2013 16:19:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:19:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 16:19:30 +0000
Message-Id: <5113E22102000078000BCF51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 16:19:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Bligh" <alex@alex.org.uk>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
In-Reply-To: <13FBA4F2DA636D516C1AAB94@nimrod.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 16:59, Alex Bligh <alex@alex.org.uk> wrote:
> What I want to do is take a particular set of cpu features (which for the
> sake of argument I will do by booting a kvm domain), and say "mask off
> any additional cpuid flags beyond these", so if a new feature gets
> introduced in the Xen codebase, it won't show in the guest. I think the
> only thing I can do at the moment is check the Xen code for every cpu
> feature Xen knows about, remove those I still want, and mask off the rest.
> What I actually want to do is to say "please don't expose any features
> other than these ones, and only expose these if the host supports them",
> so that if we change versions of Xen to one supporting another feature,
> we won't need to poke around in every domain config.

You're heading in a slightly wrong direction here: You don't really
care what features Xen know about or supports. What you do care
about is what features your DomU-s get to see. And that's where
the masking comes into play (and why this can be done on a per
guest basis as well as at the host level).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:19:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UCF-0004Cm-1W; Thu, 07 Feb 2013 16:19:35 +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 1U3UCD-0004Ce-5I
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:19:33 +0000
Received: from [85.158.139.211:35057] by server-13.bemta-5.messagelabs.com id
	D2/53-06769-414D3115; Thu, 07 Feb 2013 16:19:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360253971!21524696!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28931 invoked from network); 7 Feb 2013 16:19:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:19:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 16:19:30 +0000
Message-Id: <5113E22102000078000BCF51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 16:19:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Bligh" <alex@alex.org.uk>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
In-Reply-To: <13FBA4F2DA636D516C1AAB94@nimrod.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Ian Campbell <Ian.Campbell@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 16:59, Alex Bligh <alex@alex.org.uk> wrote:
> What I want to do is take a particular set of cpu features (which for the
> sake of argument I will do by booting a kvm domain), and say "mask off
> any additional cpuid flags beyond these", so if a new feature gets
> introduced in the Xen codebase, it won't show in the guest. I think the
> only thing I can do at the moment is check the Xen code for every cpu
> feature Xen knows about, remove those I still want, and mask off the rest.
> What I actually want to do is to say "please don't expose any features
> other than these ones, and only expose these if the host supports them",
> so that if we change versions of Xen to one supporting another feature,
> we won't need to poke around in every domain config.

You're heading in a slightly wrong direction here: You don't really
care what features Xen know about or supports. What you do care
about is what features your DomU-s get to see. And that's where
the masking comes into play (and why this can be done on a per
guest basis as well as at the host level).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:23:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UFS-0004RG-L8; Thu, 07 Feb 2013 16:22:54 +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 1U3UFR-0004R9-FH
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:22:53 +0000
Received: from [85.158.138.51:44341] by server-15.bemta-3.messagelabs.com id
	99/A7-25405-CD4D3115; Thu, 07 Feb 2013 16:22:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360254172!29274416!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7813 invoked from network); 7 Feb 2013 16:22:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:22:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1248534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:22: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.297.1; Thu, 7 Feb 2013
	16:22:51 +0000
Message-ID: <1360254170.32479.88.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 16:22:50 +0000
In-Reply-To: <20130207161432.GN77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 13/45] xen: arm64: dcache 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

On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > This drops the
> >     "m" (*_p)
> > asm contraint. I can't figure out what this was for.
> > 
> 
> It's to stop the compiler hoisting writes to the wrong side of the
> flush.  It's the lighter-weight equivalent to the "memory" clobber in
> the range version.  By moving from inline "dsb;" to dsb() you've
> reintroduced the full memory clobber here anyway. :(

Ah, I forgot about the "memory" on the inline asm of the dsb macro.

How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
for cases such as this?

I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
form is valid. The reason I didn't err on the side of just adding the
"sy" was that often there is something else which differs between the
two in the same asm inline block and so using the macro throughout
seemed cleaner. Perhaps I should rethink this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:23:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UFS-0004RG-L8; Thu, 07 Feb 2013 16:22:54 +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 1U3UFR-0004R9-FH
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:22:53 +0000
Received: from [85.158.138.51:44341] by server-15.bemta-3.messagelabs.com id
	99/A7-25405-CD4D3115; Thu, 07 Feb 2013 16:22:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360254172!29274416!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7813 invoked from network); 7 Feb 2013 16:22:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:22:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1248534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:22: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.297.1; Thu, 7 Feb 2013
	16:22:51 +0000
Message-ID: <1360254170.32479.88.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 16:22:50 +0000
In-Reply-To: <20130207161432.GN77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 13/45] xen: arm64: dcache 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

On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > This drops the
> >     "m" (*_p)
> > asm contraint. I can't figure out what this was for.
> > 
> 
> It's to stop the compiler hoisting writes to the wrong side of the
> flush.  It's the lighter-weight equivalent to the "memory" clobber in
> the range version.  By moving from inline "dsb;" to dsb() you've
> reintroduced the full memory clobber here anyway. :(

Ah, I forgot about the "memory" on the inline asm of the dsb macro.

How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
for cases such as this?

I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
form is valid. The reason I didn't err on the side of just adding the
"sy" was that often there is something else which differs between the
two in the same asm inline block and so using the macro throughout
seemed cleaner. Perhaps I should rethink this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:28:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UKm-0004wN-Vo; Thu, 07 Feb 2013 16:28:24 +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 1U3UKl-0004w9-Kq
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 16:28:23 +0000
Received: from [85.158.137.99:56766] by server-16.bemta-3.messagelabs.com id
	AD/2B-02727-626D3115; Thu, 07 Feb 2013 16:28:22 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360254501!20433471!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3708 invoked from network); 7 Feb 2013 16:28:21 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:28:21 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 040A740053D;
	Thu,  7 Feb 2013 17:28:21 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 2YeMs6-XCBho; Thu,  7 Feb 2013 17:28:20 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 815634000C3;
	Thu,  7 Feb 2013 17:28:19 +0100 (CET)
Message-ID: <5113D620.702@tiscali.it>
Date: Thu, 07 Feb 2013 17:28:16 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
In-Reply-To: <19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
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="===============6956591950340177296=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============6956591950340177296==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020709030006020302010304"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020709030006020302010304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 07/02/2013 13:48, Kristian Hagsted Rasmussen ha scritto:
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
>> Sent: 7. februar 2013 13:28
>> To: xen-devel; Ian Campbell; Stefano Stabellini
>> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
>>
>> I haven't seen mail about eufi support on hvm domUs (ovmf) for a long =
time.
>> I'm interested in trying it with xen-unstable.
>> Someone can tell me if there is something to add to have it working an=
d/or
>> ovmf git need to be updated?
> I have been running Windows 8 and server 2012 HVM on OVMF for some time=
=2E I used the latest OVMF build from the edk2 source with xen-unstable. =
It works fine, except that the vnc connection doesn't update the picture,=
 so I have to open and close the vnc window for updating the picture, unt=
il I have enabled remote desktop in windows. I also tried to pass through=
 some USB ports with success, the passing through my intel hd 4000 gfx, d=
oes not work even in secondary mode.
>
> /Kristian Hagsted Rasmussen

Thanks for reply.
I built successfull ovmf with xen-unstable with this changes:
=2E/configure --enable-ovmf
vi Config.mk
OVMF_UPSTREAM_URL ?=3D git://github.com/tianocore/edk2.git
OVMF_UPSTREAM_REVISION ?=3D master
# Added patch for support gcc4.7 and rispective change in=20
tools/firmware/ovmf-makefile

After that I tested it adding bios=3D"ovmf" on domU's xl cfg.
The domU starts but performance is very poor (similar to qemu without=20
xen or kvm or worse).
Tried with Windows 7 and Fedora 18: they start loading but never reach a =

complete boot (even after about 10 minutes).

Are there any others specific task to do?

Thanks for any reply.

>> Thanks for any reply.
>>



--------------ms020709030006020302010304
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNzE2MjgxNlowIwYJKoZIhvcNAQkEMRYEFNXJkT8DSZ51KYtYjjUUzWvv
AJGGMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAEda93DtiFwpyAY6djs9n3V9r
M7Du/a+9k1nkmLOnOS/mosq/pR/3Jl0FBFjFkV2ItGizMEUbnh+yltZnxwGM2KwWxekF1BUj
akQXjWEav9bOb8oOnD21SA82A+Ag0hyfYJXIN698IQ6GKFE0Ov8GBsranlAfFvI8pU5ujoOA
4UB9lSZfaDc4n9Xpmzps1hdWKUX3iI6Xat12SoReevd/Pnk0asMHpJzvlIFM0oQDUCrx+jkL
YsF6GG6mbcpYx9BEylwuvagwQCm4cxZ8bIMmeVKV7Pi6bKK0RkPtIRDb27p0+wI2dfoqaFHA
JVY84kUx4r1hMguFy297POcmyr19VAAAAAAAAA==
--------------ms020709030006020302010304--


--===============6956591950340177296==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6956591950340177296==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 16:28:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UKm-0004wN-Vo; Thu, 07 Feb 2013 16:28:24 +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 1U3UKl-0004w9-Kq
	for xen-devel@lists.xensource.com; Thu, 07 Feb 2013 16:28:23 +0000
Received: from [85.158.137.99:56766] by server-16.bemta-3.messagelabs.com id
	AD/2B-02727-626D3115; Thu, 07 Feb 2013 16:28:22 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360254501!20433471!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3708 invoked from network); 7 Feb 2013 16:28:21 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:28:21 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 040A740053D;
	Thu,  7 Feb 2013 17:28:21 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 2YeMs6-XCBho; Thu,  7 Feb 2013 17:28:20 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 815634000C3;
	Thu,  7 Feb 2013 17:28:19 +0100 (CET)
Message-ID: <5113D620.702@tiscali.it>
Date: Thu, 07 Feb 2013 17:28:16 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
In-Reply-To: <19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
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="===============6956591950340177296=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============6956591950340177296==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020709030006020302010304"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020709030006020302010304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 07/02/2013 13:48, Kristian Hagsted Rasmussen ha scritto:
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
>> Sent: 7. februar 2013 13:28
>> To: xen-devel; Ian Campbell; Stefano Stabellini
>> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
>>
>> I haven't seen mail about eufi support on hvm domUs (ovmf) for a long =
time.
>> I'm interested in trying it with xen-unstable.
>> Someone can tell me if there is something to add to have it working an=
d/or
>> ovmf git need to be updated?
> I have been running Windows 8 and server 2012 HVM on OVMF for some time=
=2E I used the latest OVMF build from the edk2 source with xen-unstable. =
It works fine, except that the vnc connection doesn't update the picture,=
 so I have to open and close the vnc window for updating the picture, unt=
il I have enabled remote desktop in windows. I also tried to pass through=
 some USB ports with success, the passing through my intel hd 4000 gfx, d=
oes not work even in secondary mode.
>
> /Kristian Hagsted Rasmussen

Thanks for reply.
I built successfull ovmf with xen-unstable with this changes:
=2E/configure --enable-ovmf
vi Config.mk
OVMF_UPSTREAM_URL ?=3D git://github.com/tianocore/edk2.git
OVMF_UPSTREAM_REVISION ?=3D master
# Added patch for support gcc4.7 and rispective change in=20
tools/firmware/ovmf-makefile

After that I tested it adding bios=3D"ovmf" on domU's xl cfg.
The domU starts but performance is very poor (similar to qemu without=20
xen or kvm or worse).
Tried with Windows 7 and Fedora 18: they start loading but never reach a =

complete boot (even after about 10 minutes).

Are there any others specific task to do?

Thanks for any reply.

>> Thanks for any reply.
>>



--------------ms020709030006020302010304
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwNzE2MjgxNlowIwYJKoZIhvcNAQkEMRYEFNXJkT8DSZ51KYtYjjUUzWvv
AJGGMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAEda93DtiFwpyAY6djs9n3V9r
M7Du/a+9k1nkmLOnOS/mosq/pR/3Jl0FBFjFkV2ItGizMEUbnh+yltZnxwGM2KwWxekF1BUj
akQXjWEav9bOb8oOnD21SA82A+Ag0hyfYJXIN698IQ6GKFE0Ov8GBsranlAfFvI8pU5ujoOA
4UB9lSZfaDc4n9Xpmzps1hdWKUX3iI6Xat12SoReevd/Pnk0asMHpJzvlIFM0oQDUCrx+jkL
YsF6GG6mbcpYx9BEylwuvagwQCm4cxZ8bIMmeVKV7Pi6bKK0RkPtIRDb27p0+wI2dfoqaFHA
JVY84kUx4r1hMguFy297POcmyr19VAAAAAAAAA==
--------------ms020709030006020302010304--


--===============6956591950340177296==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6956591950340177296==--


From xen-devel-bounces@lists.xen.org Thu Feb 07 16:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:31: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 1U3UN8-0005CU-Gz; Thu, 07 Feb 2013 16:30:50 +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 1U3UN8-0005CO-34
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:30:50 +0000
Received: from [85.158.138.51:33930] by server-14.bemta-3.messagelabs.com id
	3E/CC-23533-9B6D3115; Thu, 07 Feb 2013 16:30:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360254643!31479704!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26418 invoked from network); 7 Feb 2013 16:30:44 -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; 7 Feb 2013 16:30:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 16:30:43 +0000
Message-Id: <5113E4C302000078000BCF6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 16:30:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rui Guo" <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
In-Reply-To: <1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 07.02.13 at 17:12, Rui Guo <firemeteor@users.sourceforge.net> wrote:
> @@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
>      did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>      rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>  
> -    if ( vid == PCI_VENDOR_ID_INTEL )
> -        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
> -                        pch_map_irq, "intel_bridge_1f");
> +    if (vid == PCI_VENDOR_ID_INTEL) {
> +        PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
> +                sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
> +
> +        pci_config_set_vendor_id(s->dev.config, vid);
> +        pci_config_set_device_id(s->dev.config, did);
> +
> +        s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
> +        s->dev.config[PCI_COMMAND + 1] = 0x00;
> +        s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
> +        s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
> +        s->dev.config[PCI_REVISION] = rid;
> +        s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
> +        pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
> +        s->dev.config[PCI_LATENCY_TIMER] = 0x10;
> +        s->dev.config[PCI_HEADER_TYPE] = 0x80;
> +        s->dev.config[PCI_SEC_STATUS] = 0xa0;
> +
> +        s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
> +    }
>  }
>  
>  uint32_t igd_read_opregion(struct pt_dev *pci_dev)

For one I wonder whether this is really _always_ correct. I.e.
the device at 00:1f.0 always being an ISA bridge. Wouldn't it
be better to mirror whatever the host device says?

And then I don't see why you need to open code all of
pci_bridge_init() instead of just overriding the class value after
you called that function (or, if the order of events for some
reason matters, adding another parameter to the function).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:31: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 1U3UN8-0005CU-Gz; Thu, 07 Feb 2013 16:30:50 +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 1U3UN8-0005CO-34
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:30:50 +0000
Received: from [85.158.138.51:33930] by server-14.bemta-3.messagelabs.com id
	3E/CC-23533-9B6D3115; Thu, 07 Feb 2013 16:30:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360254643!31479704!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26418 invoked from network); 7 Feb 2013 16:30:44 -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; 7 Feb 2013 16:30:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 16:30:43 +0000
Message-Id: <5113E4C302000078000BCF6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 16:30:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rui Guo" <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
In-Reply-To: <1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 07.02.13 at 17:12, Rui Guo <firemeteor@users.sourceforge.net> wrote:
> @@ -40,9 +41,26 @@ void intel_pch_init(PCIBus *bus)
>      did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
>      rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
>  
> -    if ( vid == PCI_VENDOR_ID_INTEL )
> -        pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
> -                        pch_map_irq, "intel_bridge_1f");
> +    if (vid == PCI_VENDOR_ID_INTEL) {
> +        PCIBridge *s = (PCIBridge *)pci_register_device(bus, "intel_bridge_1f",
> +                sizeof(PCIBridge), PCI_DEVFN(0x1f, 0), NULL, pci_bridge_write_config);
> +
> +        pci_config_set_vendor_id(s->dev.config, vid);
> +        pci_config_set_device_id(s->dev.config, did);
> +
> +        s->dev.config[PCI_COMMAND] = 0x06; // command = bus master, pci mem
> +        s->dev.config[PCI_COMMAND + 1] = 0x00;
> +        s->dev.config[PCI_STATUS] = 0xa0; // status = fast back-to-back, 66MHz, no error
> +        s->dev.config[PCI_STATUS + 1] = 0x00; // status = fast devsel
> +        s->dev.config[PCI_REVISION] = rid;
> +        s->dev.config[PCI_CLASS_PROG] = 0x00; // programming i/f
> +        pci_config_set_class(s->dev.config, PCI_CLASS_BRIDGE_ISA);
> +        s->dev.config[PCI_LATENCY_TIMER] = 0x10;
> +        s->dev.config[PCI_HEADER_TYPE] = 0x80;
> +        s->dev.config[PCI_SEC_STATUS] = 0xa0;
> +
> +        s->bus = pci_register_secondary_bus(&s->dev, pch_map_irq);
> +    }
>  }
>  
>  uint32_t igd_read_opregion(struct pt_dev *pci_dev)

For one I wonder whether this is really _always_ correct. I.e.
the device at 00:1f.0 always being an ISA bridge. Wouldn't it
be better to mirror whatever the host device says?

And then I don't see why you need to open code all of
pci_bridge_init() instead of just overriding the class value after
you called that function (or, if the order of events for some
reason matters, adding another parameter to the function).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:31:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:31: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 1U3UNF-0005DG-Tj; Thu, 07 Feb 2013 16:30:57 +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 1U3UNE-0005Cx-B2
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:30:56 +0000
Received: from [85.158.138.51:34376] by server-8.bemta-3.messagelabs.com id
	AD/A1-25687-FB6D3115; Thu, 07 Feb 2013 16:30:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360254640!21078526!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29618 invoked from network); 7 Feb 2013 16:30:41 -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; 7 Feb 2013 16:30:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UMu-000L74-Pq; Thu, 07 Feb 2013 16:30:36 +0000
Date: Thu, 7 Feb 2013 16:30:36 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130207163036.GO77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360254170.32479.88.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache 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

At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > This drops the
> > >     "m" (*_p)
> > > asm contraint. I can't figure out what this was for.
> > > 
> > 
> > It's to stop the compiler hoisting writes to the wrong side of the
> > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > the range version.  By moving from inline "dsb;" to dsb() you've
> > reintroduced the full memory clobber here anyway. :(
> 
> Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> 
> How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> for cases such as this?

Maybe.  The profusion of undersocre-prefixed operations is staring to
confuse me, though.

> I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> form is valid. The reason I didn't err on the side of just adding the
> "sy" was that often there is something else which differs between the
> two in the same asm inline block and so using the macro throughout
> seemed cleaner. Perhaps I should rethink this.

I see.  So maybe we could just switch to using 'dsb sy' in
flush_xen_dcache() and just macro up the one line of inline asm that
expands to STORE_CP32(0, DCCMVAC) ?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:31:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:31: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 1U3UNF-0005DG-Tj; Thu, 07 Feb 2013 16:30:57 +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 1U3UNE-0005Cx-B2
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:30:56 +0000
Received: from [85.158.138.51:34376] by server-8.bemta-3.messagelabs.com id
	AD/A1-25687-FB6D3115; Thu, 07 Feb 2013 16:30:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360254640!21078526!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29618 invoked from network); 7 Feb 2013 16:30:41 -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; 7 Feb 2013 16:30:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UMu-000L74-Pq; Thu, 07 Feb 2013 16:30:36 +0000
Date: Thu, 7 Feb 2013 16:30:36 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130207163036.GO77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360254170.32479.88.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache 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

At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > This drops the
> > >     "m" (*_p)
> > > asm contraint. I can't figure out what this was for.
> > > 
> > 
> > It's to stop the compiler hoisting writes to the wrong side of the
> > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > the range version.  By moving from inline "dsb;" to dsb() you've
> > reintroduced the full memory clobber here anyway. :(
> 
> Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> 
> How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> for cases such as this?

Maybe.  The profusion of undersocre-prefixed operations is staring to
confuse me, though.

> I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> form is valid. The reason I didn't err on the side of just adding the
> "sy" was that often there is something else which differs between the
> two in the same asm inline block and so using the macro throughout
> seemed cleaner. Perhaps I should rethink this.

I see.  So maybe we could just switch to using 'dsb sy' in
flush_xen_dcache() and just macro up the one line of inline asm that
expands to STORE_CP32(0, DCCMVAC) ?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:34:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:34: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 1U3UQN-0005o9-HJ; Thu, 07 Feb 2013 16:34: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 1U3UQL-0005nx-Oa
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:34:09 +0000
Received: from [85.158.139.211:40390] by server-16.bemta-5.messagelabs.com id
	E8/8A-14948-187D3115; Thu, 07 Feb 2013 16:34:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360254813!20443472!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4709 invoked from network); 7 Feb 2013 16:33:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:33:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1249067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:33: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.297.1; Thu, 7 Feb 2013
	16:33:33 +0000
Message-ID: <1360254812.32479.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 16:33:32 +0000
In-Reply-To: <20130207163036.GO77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
	<20130207163036.GO77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 13/45] xen: arm64: dcache 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

On Thu, 2013-02-07 at 16:30 +0000, Tim Deegan wrote:
> At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> > On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > > This drops the
> > > >     "m" (*_p)
> > > > asm contraint. I can't figure out what this was for.
> > > > 
> > > 
> > > It's to stop the compiler hoisting writes to the wrong side of the
> > > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > > the range version.  By moving from inline "dsb;" to dsb() you've
> > > reintroduced the full memory clobber here anyway. :(
> > 
> > Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> > 
> > How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> > for cases such as this?
> 
> Maybe.  The profusion of undersocre-prefixed operations is staring to
> confuse me, though.

Ack.

> > I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> > form is valid. The reason I didn't err on the side of just adding the
> > "sy" was that often there is something else which differs between the
> > two in the same asm inline block and so using the macro throughout
> > seemed cleaner. Perhaps I should rethink this.
> 
> I see.  So maybe we could just switch to using 'dsb sy' in
> flush_xen_dcache() and just macro up the one line of inline asm that
> expands to STORE_CP32(0, DCCMVAC) ?

Actually, yes, I subsequently to make this change invented
READ/WRITE_SYSREG to abstract this stuff away -- I should extend that to
inline ASM 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 Feb 07 16:34:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:34: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 1U3UQN-0005o9-HJ; Thu, 07 Feb 2013 16:34: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 1U3UQL-0005nx-Oa
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:34:09 +0000
Received: from [85.158.139.211:40390] by server-16.bemta-5.messagelabs.com id
	E8/8A-14948-187D3115; Thu, 07 Feb 2013 16:34:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360254813!20443472!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4709 invoked from network); 7 Feb 2013 16:33:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:33:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1249067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:33: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.297.1; Thu, 7 Feb 2013
	16:33:33 +0000
Message-ID: <1360254812.32479.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 16:33:32 +0000
In-Reply-To: <20130207163036.GO77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
	<20130207163036.GO77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 13/45] xen: arm64: dcache 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

On Thu, 2013-02-07 at 16:30 +0000, Tim Deegan wrote:
> At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> > On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > > This drops the
> > > >     "m" (*_p)
> > > > asm contraint. I can't figure out what this was for.
> > > > 
> > > 
> > > It's to stop the compiler hoisting writes to the wrong side of the
> > > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > > the range version.  By moving from inline "dsb;" to dsb() you've
> > > reintroduced the full memory clobber here anyway. :(
> > 
> > Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> > 
> > How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> > for cases such as this?
> 
> Maybe.  The profusion of undersocre-prefixed operations is staring to
> confuse me, though.

Ack.

> > I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> > form is valid. The reason I didn't err on the side of just adding the
> > "sy" was that often there is something else which differs between the
> > two in the same asm inline block and so using the macro throughout
> > seemed cleaner. Perhaps I should rethink this.
> 
> I see.  So maybe we could just switch to using 'dsb sy' in
> flush_xen_dcache() and just macro up the one line of inline asm that
> expands to STORE_CP32(0, DCCMVAC) ?

Actually, yes, I subsequently to make this change invented
READ/WRITE_SYSREG to abstract this stuff away -- I should extend that to
inline ASM 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 Feb 07 16:36:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:36: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 1U3US8-0005xB-2T; Thu, 07 Feb 2013 16:36:00 +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 1U3US6-0005x2-8x
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:35:58 +0000
Received: from [193.109.254.147:12732] by server-15.bemta-14.messagelabs.com
	id D6/E3-24599-DE7D3115; Thu, 07 Feb 2013 16:35:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360254950!9905101!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 499 invoked from network); 7 Feb 2013 16:35:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:35:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UQk-000LAK-MZ; Thu, 07 Feb 2013 16:34:34 +0000
Date: Thu, 7 Feb 2013 16:34:34 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207163434.GP77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-14-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-14-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/45] xen: arm64: TLB flushes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956580), Ian Campbell wrote:
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -20,6 +20,58 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>  
>  #define __flush_xen_dcache_one(va) asm volatile ("dc cvac, %0;" : : "r" (va))
>  
> +/*
> + * Flush all hypervisor mappings from the TLB
> + * This is needed after changing Xen code mappings.
> + *
> + * The caller needs to issue the necessary DSB and D-cache flushes
> + * before calling flush_xen_text_tlb.
> + */
> +static inline void flush_xen_text_tlb(void)
> +{
> +    asm volatile (
> +        "isb;"       /* Ensure synchronization with previous changes to text */
> +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> +        "ic     iallu;"                 /* Flush I-cache */
> +        "dsb    sy;"                    /* Ensure completion of TLB+BP flush */

No BP flush operation on arm64?  If so, I think this comment needs
updating. 

> +        "isb;"
> +        : : : "memory");
> +}
> +
> +/*
> + * Flush all hypervisor mappings from the data TLB. This is not
> + * sufficient when changing code mappings or for self modifying code.
> + */
> +static inline void flush_xen_data_tlb(void)
> +{
> +    asm volatile (
> +        "dsb    sy;"                    /* Ensure visibility of PTE writes */
> +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> +        "dsb    sy;"                    /* Ensure completion of TLB flush */
> +        "isb;"
> +        : : : "memory");
> +}
> +
> +/*
> + * Flush one VA's hypervisor mappings from the data TLB. This is not
> + * sufficient when changing code mappings or for self modifying code.
> + */
> +static inline void flush_xen_data_tlb_va(vaddr_t va)
> +{
> +    asm volatile(
> +        "dsb    sy;"                    /* Ensure preceding are visible */
> +        "tlbi   vae2, %0;"
> +        "dsb    sy;"                    /* Ensure completion of the TLB flush */
> +        "isb;"
> +        : : "r" (va>>PAGE_SHIFT) : "memory");
> +}
> +
> +/* Flush all non-hypervisor mappings from the TLB */
> +static inline void flush_guest_tlb(void)
> +{
> +    asm volatile("tlbi alle1,ns" : : : "memory");
> +}

What does the ',ns' do here?  And is the memory clobber required?  (And
if so, don't we need a DSB or two as well?)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:36:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:36: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 1U3US8-0005xB-2T; Thu, 07 Feb 2013 16:36:00 +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 1U3US6-0005x2-8x
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:35:58 +0000
Received: from [193.109.254.147:12732] by server-15.bemta-14.messagelabs.com
	id D6/E3-24599-DE7D3115; Thu, 07 Feb 2013 16:35:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360254950!9905101!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 499 invoked from network); 7 Feb 2013 16:35:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:35:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UQk-000LAK-MZ; Thu, 07 Feb 2013 16:34:34 +0000
Date: Thu, 7 Feb 2013 16:34:34 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207163434.GP77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-14-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-14-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/45] xen: arm64: TLB flushes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956580), Ian Campbell wrote:
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -20,6 +20,58 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>  
>  #define __flush_xen_dcache_one(va) asm volatile ("dc cvac, %0;" : : "r" (va))
>  
> +/*
> + * Flush all hypervisor mappings from the TLB
> + * This is needed after changing Xen code mappings.
> + *
> + * The caller needs to issue the necessary DSB and D-cache flushes
> + * before calling flush_xen_text_tlb.
> + */
> +static inline void flush_xen_text_tlb(void)
> +{
> +    asm volatile (
> +        "isb;"       /* Ensure synchronization with previous changes to text */
> +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> +        "ic     iallu;"                 /* Flush I-cache */
> +        "dsb    sy;"                    /* Ensure completion of TLB+BP flush */

No BP flush operation on arm64?  If so, I think this comment needs
updating. 

> +        "isb;"
> +        : : : "memory");
> +}
> +
> +/*
> + * Flush all hypervisor mappings from the data TLB. This is not
> + * sufficient when changing code mappings or for self modifying code.
> + */
> +static inline void flush_xen_data_tlb(void)
> +{
> +    asm volatile (
> +        "dsb    sy;"                    /* Ensure visibility of PTE writes */
> +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> +        "dsb    sy;"                    /* Ensure completion of TLB flush */
> +        "isb;"
> +        : : : "memory");
> +}
> +
> +/*
> + * Flush one VA's hypervisor mappings from the data TLB. This is not
> + * sufficient when changing code mappings or for self modifying code.
> + */
> +static inline void flush_xen_data_tlb_va(vaddr_t va)
> +{
> +    asm volatile(
> +        "dsb    sy;"                    /* Ensure preceding are visible */
> +        "tlbi   vae2, %0;"
> +        "dsb    sy;"                    /* Ensure completion of the TLB flush */
> +        "isb;"
> +        : : "r" (va>>PAGE_SHIFT) : "memory");
> +}
> +
> +/* Flush all non-hypervisor mappings from the TLB */
> +static inline void flush_guest_tlb(void)
> +{
> +    asm volatile("tlbi alle1,ns" : : : "memory");
> +}

What does the ',ns' do here?  And is the memory clobber required?  (And
if so, don't we need a DSB or two as well?)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:38:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:38: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 1U3UUq-000683-Lh; Thu, 07 Feb 2013 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 <tim@xen.org>)
	id 1U3UUp-00067w-8G
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:38:47 +0000
Received: from [85.158.138.51:29347] by server-14.bemta-3.messagelabs.com id
	62/6C-23533-698D3115; Thu, 07 Feb 2013 16:38:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360255113!29669088!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29101 invoked from network); 7 Feb 2013 16:38:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:38:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UUb-000LBU-2A; Thu, 07 Feb 2013 16:38:33 +0000
Date: Thu, 7 Feb 2013 16:38:33 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207163833.GQ77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-15-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-15-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 15/45] xen: arm64: address translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956581), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 16:38:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:38: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 1U3UUq-000683-Lh; Thu, 07 Feb 2013 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 <tim@xen.org>)
	id 1U3UUp-00067w-8G
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:38:47 +0000
Received: from [85.158.138.51:29347] by server-14.bemta-3.messagelabs.com id
	62/6C-23533-698D3115; Thu, 07 Feb 2013 16:38:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360255113!29669088!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29101 invoked from network); 7 Feb 2013 16:38:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:38:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UUb-000LBU-2A; Thu, 07 Feb 2013 16:38:33 +0000
Date: Thu, 7 Feb 2013 16:38:33 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207163833.GQ77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-15-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-15-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 15/45] xen: arm64: address translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956581), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 07 16:40:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UWp-0006I7-BT; Thu, 07 Feb 2013 16:40:51 +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 1U3UWn-0006I0-E0
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:40:49 +0000
Received: from [193.109.254.147:39210] by server-8.bemta-14.messagelabs.com id
	77/9C-17325-019D3115; Thu, 07 Feb 2013 16:40:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360255243!4039001!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8921 invoked from network); 7 Feb 2013 16:40:44 -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; 7 Feb 2013 16:40:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 16:40:42 +0000
Message-Id: <5113E71B02000078000BCF86@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 16:40:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rui Guo" <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
In-Reply-To: <1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 17:12, Rui Guo <firemeteor@users.sourceforge.net> wrote:
> +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> +                                        uint32_t *val)
> +{
> +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    uint32_t vendor_cap = 0;
> +    uint32_t cap_type = 0;
> +    uint32_t cap_size = 0;
> +
> +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> +    if (!vendor_cap)
> +        return 0;
> +
> +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> +        return 0;
> +
> +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> +    {
> +        *val = vendor_cap;
> +        return 1;
> +    }
> +
> +    /* Remove the next capability link */
> +    if (config_addr == vendor_cap + 1)
> +    {
> +        *val = 0;
> +        return 1;
> +    }

It doesn't look right to ignore "len" up to here? What if this is a
word read at "vendor_cap"?

Also, why would removing the next capability be correct here,
when you're not removing _all_ other capabilities?

> +
> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> +    if (config_addr >= vendor_cap &&
> +            config_addr + len <= vendor_cap + cap_size)
> +    {
> +        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +        return 1;
> +    }

Similarly such a read wouldn't get handled consistently (with the
above intention) here: You're not masking off the byte at
"vendor_cap + 1".

> +    /* Exposing writable register does not lead to security risk since this
> +       only apply to read. This may confuse the guest, but it works good so far.
> +       Will switch to mask & merge style only if this is proved broken.
> +       Note: Always expose aligned address if any byte of the dword is to be
> +       exposed. This provides a consistent view, at least for read. */

Such a comment is certainly not helping being confident in the
changes you're trying to get merged in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:40:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UWp-0006I7-BT; Thu, 07 Feb 2013 16:40:51 +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 1U3UWn-0006I0-E0
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:40:49 +0000
Received: from [193.109.254.147:39210] by server-8.bemta-14.messagelabs.com id
	77/9C-17325-019D3115; Thu, 07 Feb 2013 16:40:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360255243!4039001!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8921 invoked from network); 7 Feb 2013 16:40:44 -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; 7 Feb 2013 16:40:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 07 Feb 2013 16:40:42 +0000
Message-Id: <5113E71B02000078000BCF86@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 07 Feb 2013 16:40:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Rui Guo" <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
In-Reply-To: <1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 17:12, Rui Guo <firemeteor@users.sourceforge.net> wrote:
> +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> +                                        uint32_t *val)
> +{
> +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    uint32_t vendor_cap = 0;
> +    uint32_t cap_type = 0;
> +    uint32_t cap_size = 0;
> +
> +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> +    if (!vendor_cap)
> +        return 0;
> +
> +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> +        return 0;
> +
> +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> +    {
> +        *val = vendor_cap;
> +        return 1;
> +    }
> +
> +    /* Remove the next capability link */
> +    if (config_addr == vendor_cap + 1)
> +    {
> +        *val = 0;
> +        return 1;
> +    }

It doesn't look right to ignore "len" up to here? What if this is a
word read at "vendor_cap"?

Also, why would removing the next capability be correct here,
when you're not removing _all_ other capabilities?

> +
> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> +    if (config_addr >= vendor_cap &&
> +            config_addr + len <= vendor_cap + cap_size)
> +    {
> +        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +        return 1;
> +    }

Similarly such a read wouldn't get handled consistently (with the
above intention) here: You're not masking off the byte at
"vendor_cap + 1".

> +    /* Exposing writable register does not lead to security risk since this
> +       only apply to read. This may confuse the guest, but it works good so far.
> +       Will switch to mask & merge style only if this is proved broken.
> +       Note: Always expose aligned address if any byte of the dword is to be
> +       exposed. This provides a consistent view, at least for read. */

Such a comment is certainly not helping being confident in the
changes you're trying to get merged in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:44:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UZj-0006hY-Uv; Thu, 07 Feb 2013 16:43: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 1U3UZi-0006hN-HG
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:43:50 +0000
Received: from [85.158.143.35:45704] by server-1.bemta-4.messagelabs.com id
	25/52-08839-5C9D3115; Thu, 07 Feb 2013 16:43:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360255429!12200975!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27228 invoked from network); 7 Feb 2013 16:43:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:43:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UZg-000LCj-Vq; Thu, 07 Feb 2013 16:43:48 +0000
Date: Thu, 7 Feb 2013 16:43:48 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207164348.GR77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-16-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-16-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 16/45] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956582), Ian Campbell wrote:
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/system.h
> @@ -0,0 +1,28 @@
> +/* Portions taken from Linux arch arm64 */
> +#ifndef __ASM_ARM64_SYSTEM_H
> +#define __ASM_ARM64_SYSTEM_H
> +
> +#define sev()           asm volatile("sev" : : : "memory")
> +#define wfe()           asm volatile("wfe" : : : "memory")
> +#define wfi()           asm volatile("wfi" : : : "memory")
> +
> +#define isb()           asm volatile("isb" : : : "memory")
> +#define dsb()           asm volatile("dsb sy" : : : "memory")
> +
> +#define mb()            dsb()
> +#define rmb()           asm volatile("dsb ld" : : : "memory")
> +#define wmb()           asm volatile("dsb st" : : : "memory")
> +
> +#define smp_mb()        asm volatile("dmb ish" : : : "memory")
> +#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> +#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")

Is this effectively declaring that all 'normal' RAM shall be inner
shareable?  I think if that's the case we might want to update all the
rest of the memory management to see things that way too. 

What's the intended difference between rmb() and smp_rmb(), 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 Feb 07 16:44:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UZj-0006hY-Uv; Thu, 07 Feb 2013 16:43: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 1U3UZi-0006hN-HG
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:43:50 +0000
Received: from [85.158.143.35:45704] by server-1.bemta-4.messagelabs.com id
	25/52-08839-5C9D3115; Thu, 07 Feb 2013 16:43:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360255429!12200975!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27228 invoked from network); 7 Feb 2013 16:43:49 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:43:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UZg-000LCj-Vq; Thu, 07 Feb 2013 16:43:48 +0000
Date: Thu, 7 Feb 2013 16:43:48 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207164348.GR77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-16-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-16-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 16/45] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956582), Ian Campbell wrote:
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/system.h
> @@ -0,0 +1,28 @@
> +/* Portions taken from Linux arch arm64 */
> +#ifndef __ASM_ARM64_SYSTEM_H
> +#define __ASM_ARM64_SYSTEM_H
> +
> +#define sev()           asm volatile("sev" : : : "memory")
> +#define wfe()           asm volatile("wfe" : : : "memory")
> +#define wfi()           asm volatile("wfi" : : : "memory")
> +
> +#define isb()           asm volatile("isb" : : : "memory")
> +#define dsb()           asm volatile("dsb sy" : : : "memory")
> +
> +#define mb()            dsb()
> +#define rmb()           asm volatile("dsb ld" : : : "memory")
> +#define wmb()           asm volatile("dsb st" : : : "memory")
> +
> +#define smp_mb()        asm volatile("dmb ish" : : : "memory")
> +#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> +#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")

Is this effectively declaring that all 'normal' RAM shall be inner
shareable?  I think if that's the case we might want to update all the
rest of the memory management to see things that way too. 

What's the intended difference between rmb() and smp_rmb(), 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 Feb 07 16:44:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:44: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 1U3Ua9-0006mw-Co; Thu, 07 Feb 2013 16:44: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 1U3Ua8-0006m0-9F
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:44:16 +0000
Received: from [193.109.254.147:13156] by server-15.bemta-14.messagelabs.com
	id D0/6E-24599-FD9D3115; Thu, 07 Feb 2013 16:44:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360255410!8924295!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6040 invoked from network); 7 Feb 2013 16:43:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:43:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1249441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:43: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.297.1; Thu, 7 Feb 2013
	16:43:27 +0000
Message-ID: <1360255405.32479.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 16:43:25 +0000
In-Reply-To: <20130207163434.GP77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-14-git-send-email-ian.campbell@citrix.com>
	<20130207163434.GP77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 14/45] xen: arm64: TLB flushes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 16:34 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956580), Ian Campbell wrote:
> > --- a/xen/include/asm-arm/arm64/page.h
> > +++ b/xen/include/asm-arm/arm64/page.h
> > @@ -20,6 +20,58 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
> >  
> >  #define __flush_xen_dcache_one(va) asm volatile ("dc cvac, %0;" : : "r" (va))
> >  
> > +/*
> > + * Flush all hypervisor mappings from the TLB
> > + * This is needed after changing Xen code mappings.
> > + *
> > + * The caller needs to issue the necessary DSB and D-cache flushes
> > + * before calling flush_xen_text_tlb.
> > + */
> > +static inline void flush_xen_text_tlb(void)
> > +{
> > +    asm volatile (
> > +        "isb;"       /* Ensure synchronization with previous changes to text */
> > +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> > +        "ic     iallu;"                 /* Flush I-cache */
> > +        "dsb    sy;"                    /* Ensure completion of TLB+BP flush */
> 
> No BP flush operation on arm64?

Correct.

> If so, I think this comment needs updating. 

Yup, I think I got most of them but missed this one.

> 
> > +        "isb;"
> > +        : : : "memory");
> > +}
> > +
> > +/*
> > + * Flush all hypervisor mappings from the data TLB. This is not
> > + * sufficient when changing code mappings or for self modifying code.
> > + */
> > +static inline void flush_xen_data_tlb(void)
> > +{
> > +    asm volatile (
> > +        "dsb    sy;"                    /* Ensure visibility of PTE writes */
> > +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> > +        "dsb    sy;"                    /* Ensure completion of TLB flush */
> > +        "isb;"
> > +        : : : "memory");
> > +}
> > +
> > +/*
> > + * Flush one VA's hypervisor mappings from the data TLB. This is not
> > + * sufficient when changing code mappings or for self modifying code.
> > + */
> > +static inline void flush_xen_data_tlb_va(vaddr_t va)
> > +{
> > +    asm volatile(
> > +        "dsb    sy;"                    /* Ensure preceding are visible */
> > +        "tlbi   vae2, %0;"
> > +        "dsb    sy;"                    /* Ensure completion of the TLB flush */
> > +        "isb;"
> > +        : : "r" (va>>PAGE_SHIFT) : "memory");
> > +}
> > +
> > +/* Flush all non-hypervisor mappings from the TLB */
> > +static inline void flush_guest_tlb(void)
> > +{
> > +    asm volatile("tlbi alle1,ns" : : : "memory");
> > +}
> 
> What does the ',ns' do here?

Er, I can't remember and I can't find it anywhere in the docs. It might
be a typo of "is" which somehow makes it past gas. Or maybe something to
do with non-secure e1?

> And is the memory clobber required?  (And if so, don't we need a DSB or two as well?)

The 32-bit stuff doesn't have one either.

But then it appears that this function is never called anyway...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:44:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:44: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 1U3Ua9-0006mw-Co; Thu, 07 Feb 2013 16:44: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 1U3Ua8-0006m0-9F
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:44:16 +0000
Received: from [193.109.254.147:13156] by server-15.bemta-14.messagelabs.com
	id D0/6E-24599-FD9D3115; Thu, 07 Feb 2013 16:44:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360255410!8924295!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6040 invoked from network); 7 Feb 2013 16:43:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:43:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1249441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 16:43: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.297.1; Thu, 7 Feb 2013
	16:43:27 +0000
Message-ID: <1360255405.32479.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 16:43:25 +0000
In-Reply-To: <20130207163434.GP77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-14-git-send-email-ian.campbell@citrix.com>
	<20130207163434.GP77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 14/45] xen: arm64: TLB flushes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 16:34 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956580), Ian Campbell wrote:
> > --- a/xen/include/asm-arm/arm64/page.h
> > +++ b/xen/include/asm-arm/arm64/page.h
> > @@ -20,6 +20,58 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
> >  
> >  #define __flush_xen_dcache_one(va) asm volatile ("dc cvac, %0;" : : "r" (va))
> >  
> > +/*
> > + * Flush all hypervisor mappings from the TLB
> > + * This is needed after changing Xen code mappings.
> > + *
> > + * The caller needs to issue the necessary DSB and D-cache flushes
> > + * before calling flush_xen_text_tlb.
> > + */
> > +static inline void flush_xen_text_tlb(void)
> > +{
> > +    asm volatile (
> > +        "isb;"       /* Ensure synchronization with previous changes to text */
> > +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> > +        "ic     iallu;"                 /* Flush I-cache */
> > +        "dsb    sy;"                    /* Ensure completion of TLB+BP flush */
> 
> No BP flush operation on arm64?

Correct.

> If so, I think this comment needs updating. 

Yup, I think I got most of them but missed this one.

> 
> > +        "isb;"
> > +        : : : "memory");
> > +}
> > +
> > +/*
> > + * Flush all hypervisor mappings from the data TLB. This is not
> > + * sufficient when changing code mappings or for self modifying code.
> > + */
> > +static inline void flush_xen_data_tlb(void)
> > +{
> > +    asm volatile (
> > +        "dsb    sy;"                    /* Ensure visibility of PTE writes */
> > +        "tlbi   alle2;"                 /* Flush hypervisor TLB */
> > +        "dsb    sy;"                    /* Ensure completion of TLB flush */
> > +        "isb;"
> > +        : : : "memory");
> > +}
> > +
> > +/*
> > + * Flush one VA's hypervisor mappings from the data TLB. This is not
> > + * sufficient when changing code mappings or for self modifying code.
> > + */
> > +static inline void flush_xen_data_tlb_va(vaddr_t va)
> > +{
> > +    asm volatile(
> > +        "dsb    sy;"                    /* Ensure preceding are visible */
> > +        "tlbi   vae2, %0;"
> > +        "dsb    sy;"                    /* Ensure completion of the TLB flush */
> > +        "isb;"
> > +        : : "r" (va>>PAGE_SHIFT) : "memory");
> > +}
> > +
> > +/* Flush all non-hypervisor mappings from the TLB */
> > +static inline void flush_guest_tlb(void)
> > +{
> > +    asm volatile("tlbi alle1,ns" : : : "memory");
> > +}
> 
> What does the ',ns' do here?

Er, I can't remember and I can't find it anywhere in the docs. It might
be a typo of "is" which somehow makes it past gas. Or maybe something to
do with non-secure e1?

> And is the memory clobber required?  (And if so, don't we need a DSB or two as well?)

The 32-bit stuff doesn't have one either.

But then it appears that this function is never called anyway...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:46:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3Ubz-0006z6-Pm; Thu, 07 Feb 2013 16:46:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Uby-0006yb-Gf
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:10 +0000
Received: from [85.158.137.99:49721] by server-1.bemta-3.messagelabs.com id
	B3/0F-08955-15AD3115; Thu, 07 Feb 2013 16:46:09 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360255566!19606636!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17565 invoked from network); 7 Feb 2013 16:46:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6672674"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:06 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-42;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:14 +0000
Message-ID: <1360255096-25924-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/5] gcov: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  159 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c         |    7 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |    9 +++
 5 files changed, 328 insertions(+)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 4de4b58..e9c222c 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,6 +19,9 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
 
@@ -61,6 +64,162 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    int reset = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+        reset = 1;
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if (reset && !ret)
+            ret = reset_counters();
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..7dec8c1 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,12 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+#ifdef TEST_COVERAGE
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+#endif
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..1b29b48
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..425dbbb 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..27c5c37 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,11 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 16:46:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3Uc1-0006zt-F7; Thu, 07 Feb 2013 16:46:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Ubz-0006yh-Cj
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:11 +0000
Received: from [85.158.138.51:19443] by server-9.bemta-3.messagelabs.com id
	5E/09-09484-25AD3115; Thu, 07 Feb 2013 16:46:10 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360255566!22507042!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8080 invoked from network); 7 Feb 2013 16:46:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6344628"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:06 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-2F;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:13 +0000
Message-ID: <1360255096-25924-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/5] gcov: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 169 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..4de4b58
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,72 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 16:46:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3Ubz-0006z6-Pm; Thu, 07 Feb 2013 16:46:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Uby-0006yb-Gf
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:10 +0000
Received: from [85.158.137.99:49721] by server-1.bemta-3.messagelabs.com id
	B3/0F-08955-15AD3115; Thu, 07 Feb 2013 16:46:09 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360255566!19606636!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17565 invoked from network); 7 Feb 2013 16:46:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6672674"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:06 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-42;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:14 +0000
Message-ID: <1360255096-25924-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/5] gcov: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  159 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c         |    7 ++
 xen/include/public/gcov.h   |  115 +++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |    9 +++
 5 files changed, 328 insertions(+)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 4de4b58..e9c222c 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,6 +19,9 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
 
@@ -61,6 +64,162 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    long ret = 0;
+    int reset = 0;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        if ( copy_to_guest(op->u.total_size, &iter.write_offset, 1) )
+            ret = -EFAULT;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+        reset = 1;
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if (reset && !ret)
+            ret = reset_counters();
+        break;
+
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+
+    default:
+        ret = -EINVAL;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..7dec8c1 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,12 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+#ifdef TEST_COVERAGE
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+#endif
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..1b29b48
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..425dbbb 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        XEN_GUEST_HANDLE_64(uint32) total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..27c5c37 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,11 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 16:46:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3Uc1-0006zt-F7; Thu, 07 Feb 2013 16:46:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Ubz-0006yh-Cj
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:11 +0000
Received: from [85.158.138.51:19443] by server-9.bemta-3.messagelabs.com id
	5E/09-09484-25AD3115; Thu, 07 Feb 2013 16:46:10 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360255566!22507042!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8080 invoked from network); 7 Feb 2013 16:46:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6344628"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:06 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-2F;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:13 +0000
Message-ID: <1360255096-25924-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/5] gcov: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 169 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 462e291..af48492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 3024ef1..146d8d4 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..4de4b58
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,72 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 07 16:46:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:46: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 1U3Uby-0006yi-Vy; Thu, 07 Feb 2013 16:46:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Ubx-0006yS-8L
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:09 +0000
Received: from [85.158.137.99:23603] by server-10.bemta-3.messagelabs.com id
	89/ED-10609-05AD3115; Thu, 07 Feb 2013 16:46:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360255566!19606636!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17484 invoked from network); 7 Feb 2013 16:46:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6672671"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:05 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-56;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:16 +0000
Message-ID: <1360255096-25924-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/5] gcov: Add documentation for coverage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

---
 docs/misc/coverage.markdown |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 docs/misc/coverage.markdown

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
new file mode 100644
index 0000000..74af665
--- /dev/null
+++ b/docs/misc/coverage.markdown
@@ -0,0 +1,39 @@
+# Coverage support for Xen
+
+Coverare support allow you to get coverage information from Xen execution.
+You can see how many times a line is executed.
+
+The compiler have specific options that enable the collection of these
+information. Every basic block in the code will be instructed by the compiler
+to compute these statistics. It should not be used in production as it slow
+down your hypervisor.
+
+## Enable coverage
+
+Test coverage support can be turned on compiling Xen with coverage option set
+to y.
+
+Something like:
+    cd xen
+    make coverage=y
+
+(or change your `Config.mk` file).
+
+## Extract coverage data
+
+The way GCC and other tools deal with coverage information is to use some files
+created during build phase (.gcno) and some files produced by executing the
+*program* (.gcda). The program in this case is Xen but Xen cannot write files
+so the way you can use coverage from Xen is extract coverage data from Xen and
+then split these information into files.
+
+To extract data you use a simple utility called `xencov`. Mainly `xencore`
+allow you to do 3 operations:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+Another utility (**TODO**) is used to split extracted data file into files
+needed by userspace tools.
+
-- 
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 Thu Feb 07 16:46:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:46: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 1U3Uby-0006yi-Vy; Thu, 07 Feb 2013 16:46:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Ubx-0006yS-8L
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:09 +0000
Received: from [85.158.137.99:23603] by server-10.bemta-3.messagelabs.com id
	89/ED-10609-05AD3115; Thu, 07 Feb 2013 16:46:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360255566!19606636!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17484 invoked from network); 7 Feb 2013 16:46:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6672671"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:05 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-56;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:16 +0000
Message-ID: <1360255096-25924-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/5] gcov: Add documentation for coverage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

---
 docs/misc/coverage.markdown |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 docs/misc/coverage.markdown

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
new file mode 100644
index 0000000..74af665
--- /dev/null
+++ b/docs/misc/coverage.markdown
@@ -0,0 +1,39 @@
+# Coverage support for Xen
+
+Coverare support allow you to get coverage information from Xen execution.
+You can see how many times a line is executed.
+
+The compiler have specific options that enable the collection of these
+information. Every basic block in the code will be instructed by the compiler
+to compute these statistics. It should not be used in production as it slow
+down your hypervisor.
+
+## Enable coverage
+
+Test coverage support can be turned on compiling Xen with coverage option set
+to y.
+
+Something like:
+    cd xen
+    make coverage=y
+
+(or change your `Config.mk` file).
+
+## Extract coverage data
+
+The way GCC and other tools deal with coverage information is to use some files
+created during build phase (.gcno) and some files produced by executing the
+*program* (.gcda). The program in this case is Xen but Xen cannot write files
+so the way you can use coverage from Xen is extract coverage data from Xen and
+then split these information into files.
+
+To extract data you use a simple utility called `xencov`. Mainly `xencore`
+allow you to do 3 operations:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+Another utility (**TODO**) is used to split extracted data file into files
+needed by userspace tools.
+
-- 
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 Thu Feb 07 16:46:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:46: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 1U3Uc1-00070D-T7; Thu, 07 Feb 2013 16:46:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Uc0-0006z2-4Y
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:12 +0000
Received: from [85.158.137.99:17630] by server-16.bemta-3.messagelabs.com id
	D1/8E-02727-35AD3115; Thu, 07 Feb 2013 16:46:11 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360255566!19606636!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17674 invoked from network); 7 Feb 2013 16:46:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6672676"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:08 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-0S;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:12 +0000
Message-ID: <1360255096-25924-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 07 16:46:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:46: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 1U3Uc1-00070D-T7; Thu, 07 Feb 2013 16:46:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Uc0-0006z2-4Y
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:12 +0000
Received: from [85.158.137.99:17630] by server-16.bemta-3.messagelabs.com id
	D1/8E-02727-35AD3115; Thu, 07 Feb 2013 16:46:11 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360255566!19606636!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17674 invoked from network); 7 Feb 2013 16:46:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6672676"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:08 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-0S;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:12 +0000
Message-ID: <1360255096-25924-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f4d3788..a75066e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1313,6 +1313,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index f7074cf..d856ab1 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -125,4 +125,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 07 16:46:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:46: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 1U3Ubz-0006yw-CN; Thu, 07 Feb 2013 16:46:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Ubx-0006yT-L8
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:10 +0000
Received: from [85.158.138.51:19331] by server-12.bemta-3.messagelabs.com id
	DA/47-05889-05AD3115; Thu, 07 Feb 2013 16:46:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360255566!22507042!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8013 invoked from network); 7 Feb 2013 16:46:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6344624"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:05 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-4Z;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:15 +0000
Message-ID: <1360255096-25924-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/5] gcov: Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  159 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 167 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..8e21cd2
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,159 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(exit_code);
+}
+
+int main(int argc, char **argv)
+{
+    int opt;
+
+    while ((opt = getopt(argc, argv, "h")) != -1) {
+        switch (opt) {
+        case 'h':
+            usage(0);
+            break;
+        default:
+            usage(1);
+        }
+    }
+
+    argv += optind;
+    argc -= optind;
+    if (argc <= 0)
+        usage(1);
+
+    gcov_init();
+
+    if ( strcmp(argv[0], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[0], "read") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 0);
+    else if ( strcmp(argv[0], "read-reset") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 1);
+    else
+        usage(1);
+
+    return 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 Thu Feb 07 16:46:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:46: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 1U3Ubz-0006yw-CN; Thu, 07 Feb 2013 16:46:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3Ubx-0006yT-L8
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:10 +0000
Received: from [85.158.138.51:19331] by server-12.bemta-3.messagelabs.com id
	DA/47-05889-05AD3115; Thu, 07 Feb 2013 16:46:08 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360255566!22507042!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8013 invoked from network); 7 Feb 2013 16:46:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6344624"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:05 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWR-0008W1-4Z;
	Thu, 07 Feb 2013 16:40:27 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:15 +0000
Message-ID: <1360255096-25924-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/5] gcov: Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  159 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 167 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index af48492..9e947ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index 146d8d4..e98c3df 100644
--- a/.hgignore
+++ b/.hgignore
@@ -218,6 +218,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..8e21cd2
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,159 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+    struct xen_sysctl sys;
+
+    memset(&sys, 0, sizeof(sys));
+    sys.cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys.u.coverage_op;
+    cov->cmd = op;
+    cov->u.total_size.p = ptr;
+
+    return xc_sysctl(gcov_xch, &sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t *ui, total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* allocate */
+    p = mmap(0, page_size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "allocating memory");
+
+    /* get total length */
+    ui = (uint32_t *) p;
+    *ui = 0;
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, ui) < 0 )
+        err(1, "getting total length");
+    fprintf(stderr, "returned %u bytes\n", (unsigned) *ui);
+
+    /* safe check */
+    total_len = *ui;
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* reallocate */
+    munmap(p, page_size);
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(exit_code);
+}
+
+int main(int argc, char **argv)
+{
+    int opt;
+
+    while ((opt = getopt(argc, argv, "h")) != -1) {
+        switch (opt) {
+        case 'h':
+            usage(0);
+            break;
+        default:
+            usage(1);
+        }
+    }
+
+    argv += optind;
+    argc -= optind;
+    if (argc <= 0)
+        usage(1);
+
+    gcov_init();
+
+    if ( strcmp(argv[0], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[0], "read") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 0);
+    else if ( strcmp(argv[0], "read-reset") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 1);
+    else
+        usage(1);
+
+    return 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 Thu Feb 07 16:46:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UcB-00074P-CF; Thu, 07 Feb 2013 16:46:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3UcA-00073J-90
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:22 +0000
Received: from [85.158.137.99:24214] by server-16.bemta-3.messagelabs.com id
	D4/CE-02727-D5AD3115; Thu, 07 Feb 2013 16:46:21 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360255567!18131712!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4997 invoked from network); 7 Feb 2013 16:46:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6344632"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:08 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWQ-0008W1-V0;
	Thu, 07 Feb 2013 16:40:26 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:11 +0000
Message-ID: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v8] gcov: Coverage 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

Updated set of patches for coverage.

Changes:
- change copyright lines
- use gcov: instead of cover: in commit comment
- use #ifdef in xen/common/sysctl.c instead of dummy inline function
- added base documentation in docs/misc
- added -h option to xencov


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:46:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16: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 1U3UcB-00074P-CF; Thu, 07 Feb 2013 16:46:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U3UcA-00073J-90
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:46:22 +0000
Received: from [85.158.137.99:24214] by server-16.bemta-3.messagelabs.com id
	D4/CE-02727-D5AD3115; Thu, 07 Feb 2013 16:46:21 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360255567!18131712!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4997 invoked from network); 7 Feb 2013 16:46:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 16:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="6344632"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 16:46:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 11:46:08 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U3UWQ-0008W1-V0;
	Thu, 07 Feb 2013 16:40:26 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 7 Feb 2013 16:38:11 +0000
Message-ID: <1360255096-25924-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v8] gcov: Coverage 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

Updated set of patches for coverage.

Changes:
- change copyright lines
- use gcov: instead of cover: in commit comment
- use #ifdef in xen/common/sysctl.c instead of dummy inline function
- added base documentation in docs/misc
- added -h option to xencov


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:50:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:50: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 1U3Ufy-0007pr-2B; Thu, 07 Feb 2013 16:50:18 +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 1U3Ufw-0007pX-Db
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:50:16 +0000
Received: from [85.158.143.35:2764] by server-2.bemta-4.messagelabs.com id
	66/95-01597-74BD3115; Thu, 07 Feb 2013 16:50:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360255724!14203489!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15830 invoked from network); 7 Feb 2013 16:48:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:48:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UeS-000LET-4c; Thu, 07 Feb 2013 16:48:44 +0000
Date: Thu, 7 Feb 2013 16:48:44 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207164844.GS77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/45] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956583), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
>  xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/system.h       |  114 --------------------------
>  3 files changed, 270 insertions(+), 114 deletions(-)
> 
> --- a/xen/include/asm-arm/arm64/system.h
> +++ b/xen/include/asm-arm/arm64/system.h
> @@ -17,6 +17,161 @@
>  #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
>  #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
>  
> +
> +extern void __bad_xchg(volatile void *, int);
> +
> +static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
> +{
> +        unsigned long ret, tmp;
> +
> +        switch (size) {
> +        case 1:
> +                asm volatile("//        __xchg1\n"
> +                "1:     ldaxrb  %w0, [%3]\n"
> +                "       stlxrb  %w1, %w2, [%3]\n"

Why are these using acquire/release ops (i.e. why not LDXR/STXR)?
The 32-bit equivalent doesn't have any memory barriers. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:50:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:50: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 1U3Ufy-0007pr-2B; Thu, 07 Feb 2013 16:50:18 +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 1U3Ufw-0007pX-Db
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:50:16 +0000
Received: from [85.158.143.35:2764] by server-2.bemta-4.messagelabs.com id
	66/95-01597-74BD3115; Thu, 07 Feb 2013 16:50:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360255724!14203489!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15830 invoked from network); 7 Feb 2013 16:48:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 16:48:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3UeS-000LET-4c; Thu, 07 Feb 2013 16:48:44 +0000
Date: Thu, 7 Feb 2013 16:48:44 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130207164844.GS77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/45] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956583), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
>  xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/system.h       |  114 --------------------------
>  3 files changed, 270 insertions(+), 114 deletions(-)
> 
> --- a/xen/include/asm-arm/arm64/system.h
> +++ b/xen/include/asm-arm/arm64/system.h
> @@ -17,6 +17,161 @@
>  #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
>  #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
>  
> +
> +extern void __bad_xchg(volatile void *, int);
> +
> +static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
> +{
> +        unsigned long ret, tmp;
> +
> +        switch (size) {
> +        case 1:
> +                asm volatile("//        __xchg1\n"
> +                "1:     ldaxrb  %w0, [%3]\n"
> +                "       stlxrb  %w1, %w2, [%3]\n"

Why are these using acquire/release ops (i.e. why not LDXR/STXR)?
The 32-bit equivalent doesn't have any memory barriers. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:59:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:59: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 1U3Uog-0008MT-5g; Thu, 07 Feb 2013 16:59:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3Uoe-0008MO-3y
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:59:16 +0000
Received: from [85.158.143.35:51084] by server-1.bemta-4.messagelabs.com id
	21/84-08839-36DD3115; Thu, 07 Feb 2013 16:59:15 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360256354!13385403!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27941 invoked from network); 7 Feb 2013 16:59:14 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-21.messagelabs.com with SMTP;
	7 Feb 2013 16:59:14 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E8C77C56198;
	Thu,  7 Feb 2013 16:59:01 +0000 (GMT)
Date: Thu, 07 Feb 2013 16:59:00 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <83398C3BBF16693DB6E1E2CA@nimrod.local>
In-Reply-To: <5113E22102000078000BCF51@nat28.tlf.novell.com>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:

> You're heading in a slightly wrong direction here: You don't really
> care what features Xen know about or supports. What you do care
> about is what features your DomU-s get to see. And that's where
> the masking comes into play (and why this can be done on a per
> guest basis as well as at the host level).

I want my domUs to see a no more than a fixed set of CPU flags
(obviously if those CPU flags aren't present, I don't want to
lie that they are). I have no visibility of what hardware my
software may be installed on in the future. EG if Intel introduces
a megawidget CPU flag and Xen adds support for it, I want to be
guaranteed this is masked out as it will break live migrate
between megawidget and non-megawidget compatible machines.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 16:59:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 16:59: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 1U3Uog-0008MT-5g; Thu, 07 Feb 2013 16:59:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3Uoe-0008MO-3y
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 16:59:16 +0000
Received: from [85.158.143.35:51084] by server-1.bemta-4.messagelabs.com id
	21/84-08839-36DD3115; Thu, 07 Feb 2013 16:59:15 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360256354!13385403!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27941 invoked from network); 7 Feb 2013 16:59:14 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-21.messagelabs.com with SMTP;
	7 Feb 2013 16:59:14 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E8C77C56198;
	Thu,  7 Feb 2013 16:59:01 +0000 (GMT)
Date: Thu, 07 Feb 2013 16:59:00 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <83398C3BBF16693DB6E1E2CA@nimrod.local>
In-Reply-To: <5113E22102000078000BCF51@nat28.tlf.novell.com>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:

> You're heading in a slightly wrong direction here: You don't really
> care what features Xen know about or supports. What you do care
> about is what features your DomU-s get to see. And that's where
> the masking comes into play (and why this can be done on a per
> guest basis as well as at the host level).

I want my domUs to see a no more than a fixed set of CPU flags
(obviously if those CPU flags aren't present, I don't want to
lie that they are). I have no visibility of what hardware my
software may be installed on in the future. EG if Intel introduces
a megawidget CPU flag and Xen adds support for it, I want to be
guaranteed this is masked out as it will break live migrate
between megawidget and non-megawidget compatible machines.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:01:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:01: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 1U3Uqs-00005t-Nn; Thu, 07 Feb 2013 17:01:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3Uqs-00005o-3p
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:01:34 +0000
Received: from [85.158.139.83:5004] by server-2.bemta-5.messagelabs.com id
	FD/8F-16911-DEDD3115; Thu, 07 Feb 2013 17:01:33 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360256385!20041874!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24885 invoked from network); 7 Feb 2013 16:59:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-182.messagelabs.com with SMTP;
	7 Feb 2013 16:59:45 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1ACC4C56198;
	Thu,  7 Feb 2013 16:59:43 +0000 (GMT)
Date: Thu, 07 Feb 2013 16:59:41 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <8884518671F56092C81CE269@nimrod.local>
In-Reply-To: <1360253815.32479.85.camel@zakaz.uk.xensource.com>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>	
	<20130207091907.GA5540@aepfle.de>	
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>	
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>	
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<1360253815.32479.85.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

--On 7 February 2013 16:16:55 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> I think you can do this using what xl.cfg(5) describes as the "xend"
> syntax, by setting all the ones you aren't explicitly exposing to 0.

OK thanks.

> The "libxl syntax" is currently "=host,flag=value,..." which starts from
> the host and modifies the flags. I can't offhand thing of a reason why
> we wouldn't also want to support a different keyword ("explicit"?) which
> means "starting from an empty slate add these". Patches accepted...

I may just take you up on that.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:01:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:01: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 1U3Uqs-00005t-Nn; Thu, 07 Feb 2013 17:01:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U3Uqs-00005o-3p
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:01:34 +0000
Received: from [85.158.139.83:5004] by server-2.bemta-5.messagelabs.com id
	FD/8F-16911-DEDD3115; Thu, 07 Feb 2013 17:01:33 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360256385!20041874!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24885 invoked from network); 7 Feb 2013 16:59:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-182.messagelabs.com with SMTP;
	7 Feb 2013 16:59:45 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1ACC4C56198;
	Thu,  7 Feb 2013 16:59:43 +0000 (GMT)
Date: Thu, 07 Feb 2013 16:59:41 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <8884518671F56092C81CE269@nimrod.local>
In-Reply-To: <1360253815.32479.85.camel@zakaz.uk.xensource.com>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>	
	<20130207091907.GA5540@aepfle.de>	
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>	
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>	
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<1360253815.32479.85.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

--On 7 February 2013 16:16:55 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> I think you can do this using what xl.cfg(5) describes as the "xend"
> syntax, by setting all the ones you aren't explicitly exposing to 0.

OK thanks.

> The "libxl syntax" is currently "=host,flag=value,..." which starts from
> the host and modifies the flags. I can't offhand thing of a reason why
> we wouldn't also want to support a different keyword ("explicit"?) which
> means "starting from an empty slate add these". Patches accepted...

I may just take you up on that.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:02:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:02: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 1U3Ur6-00007w-4S; Thu, 07 Feb 2013 17:01: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 1U3Ur4-00007j-DY
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:01:46 +0000
Received: from [85.158.139.211:6707] by server-2.bemta-5.messagelabs.com id
	FE/DF-16911-9FDD3115; Thu, 07 Feb 2013 17:01:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360256504!21240891!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12430 invoked from network); 7 Feb 2013 17:01:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:01:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1250153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 17:01: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.297.1; Thu, 7 Feb 2013
	17:01:44 +0000
Message-ID: <1360256503.32479.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 17:01:43 +0000
In-Reply-To: <20130207164348.GR77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-16-git-send-email-ian.campbell@citrix.com>
	<20130207164348.GR77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 16/45] xen: arm64: barriers and wait for
 interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 16:43 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956582), Ian Campbell wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-arm/arm64/system.h
> > @@ -0,0 +1,28 @@
> > +/* Portions taken from Linux arch arm64 */
> > +#ifndef __ASM_ARM64_SYSTEM_H
> > +#define __ASM_ARM64_SYSTEM_H
> > +
> > +#define sev()           asm volatile("sev" : : : "memory")
> > +#define wfe()           asm volatile("wfe" : : : "memory")
> > +#define wfi()           asm volatile("wfi" : : : "memory")
> > +
> > +#define isb()           asm volatile("isb" : : : "memory")
> > +#define dsb()           asm volatile("dsb sy" : : : "memory")
> > +
> > +#define mb()            dsb()
> > +#define rmb()           asm volatile("dsb ld" : : : "memory")
> > +#define wmb()           asm volatile("dsb st" : : : "memory")
> > +
> > +#define smp_mb()        asm volatile("dmb ish" : : : "memory")
> > +#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> > +#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> 
> Is this effectively declaring that all 'normal' RAM shall be inner
> shareable?  I think if that's the case we might want to update all the
> rest of the memory management to see things that way too.

> What's the intended difference between rmb() and smp_rmb(), anyway? 

It's part of the Linux CONFIG_SMP abstraction, smp_rmb becomes just a
regular barrier on UP but is a proper rmb (e.g. lfence) on SMP, rmp() is
always a proper barrier.

But that's a Linux-ism and I see x86 Xen has diverged from x86 Linux
here and just defines smp_foo as foo (i.e. a stronger barrier than might
strictly be required).

I think I'll do that here as well, until asyou say previously we revisit
this and decide what inner and outer shareable mean for Xen...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:02:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:02: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 1U3Ur6-00007w-4S; Thu, 07 Feb 2013 17:01: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 1U3Ur4-00007j-DY
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:01:46 +0000
Received: from [85.158.139.211:6707] by server-2.bemta-5.messagelabs.com id
	FE/DF-16911-9FDD3115; Thu, 07 Feb 2013 17:01:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360256504!21240891!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12430 invoked from network); 7 Feb 2013 17:01:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:01:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1250153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 17:01: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.297.1; Thu, 7 Feb 2013
	17:01:44 +0000
Message-ID: <1360256503.32479.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 17:01:43 +0000
In-Reply-To: <20130207164348.GR77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-16-git-send-email-ian.campbell@citrix.com>
	<20130207164348.GR77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 16/45] xen: arm64: barriers and wait for
 interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 16:43 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956582), Ian Campbell wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-arm/arm64/system.h
> > @@ -0,0 +1,28 @@
> > +/* Portions taken from Linux arch arm64 */
> > +#ifndef __ASM_ARM64_SYSTEM_H
> > +#define __ASM_ARM64_SYSTEM_H
> > +
> > +#define sev()           asm volatile("sev" : : : "memory")
> > +#define wfe()           asm volatile("wfe" : : : "memory")
> > +#define wfi()           asm volatile("wfi" : : : "memory")
> > +
> > +#define isb()           asm volatile("isb" : : : "memory")
> > +#define dsb()           asm volatile("dsb sy" : : : "memory")
> > +
> > +#define mb()            dsb()
> > +#define rmb()           asm volatile("dsb ld" : : : "memory")
> > +#define wmb()           asm volatile("dsb st" : : : "memory")
> > +
> > +#define smp_mb()        asm volatile("dmb ish" : : : "memory")
> > +#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> > +#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> 
> Is this effectively declaring that all 'normal' RAM shall be inner
> shareable?  I think if that's the case we might want to update all the
> rest of the memory management to see things that way too.

> What's the intended difference between rmb() and smp_rmb(), anyway? 

It's part of the Linux CONFIG_SMP abstraction, smp_rmb becomes just a
regular barrier on UP but is a proper rmb (e.g. lfence) on SMP, rmp() is
always a proper barrier.

But that's a Linux-ism and I see x86 Xen has diverged from x86 Linux
here and just defines smp_foo as foo (i.e. a stronger barrier than might
strictly be required).

I think I'll do that here as well, until asyou say previously we revisit
this and decide what inner and outer shareable mean for Xen...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:06:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17: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 1U3Uvc-0000fY-4i; Thu, 07 Feb 2013 17:06: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 1U3Uva-0000fR-Tb
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:06:27 +0000
Received: from [85.158.143.99:8290] by server-2.bemta-4.messagelabs.com id
	99/78-01597-21FD3115; Thu, 07 Feb 2013 17:06:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360256784!21570319!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1888 invoked from network); 7 Feb 2013 17:06:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:06:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1250377"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 17:06: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.297.1; Thu, 7 Feb 2013
	17:06:23 +0000
Message-ID: <1360256782.32479.101.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 17:06:22 +0000
In-Reply-To: <20130207164844.GS77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
	<20130207164844.GS77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 17/45] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 16:48 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956583), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
> >  xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/system.h       |  114 --------------------------
> >  3 files changed, 270 insertions(+), 114 deletions(-)
> > 
> > --- a/xen/include/asm-arm/arm64/system.h
> > +++ b/xen/include/asm-arm/arm64/system.h
> > @@ -17,6 +17,161 @@
> >  #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> >  #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> >  
> > +
> > +extern void __bad_xchg(volatile void *, int);
> > +
> > +static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
> > +{
> > +        unsigned long ret, tmp;
> > +
> > +        switch (size) {
> > +        case 1:
> > +                asm volatile("//        __xchg1\n"
> > +                "1:     ldaxrb  %w0, [%3]\n"
> > +                "       stlxrb  %w1, %w2, [%3]\n"
> 
> Why are these using acquire/release ops (i.e. why not LDXR/STXR)?

I nicked this from Linux ;-)

> The 32-bit equivalent doesn't have any memory barriers. 

You mean does? There is a smp_mb() before and after in that
implementation.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:06:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17: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 1U3Uvc-0000fY-4i; Thu, 07 Feb 2013 17:06: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 1U3Uva-0000fR-Tb
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:06:27 +0000
Received: from [85.158.143.99:8290] by server-2.bemta-4.messagelabs.com id
	99/78-01597-21FD3115; Thu, 07 Feb 2013 17:06:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360256784!21570319!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1888 invoked from network); 7 Feb 2013 17:06:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:06:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; 
   d="scan'208";a="1250377"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Feb 2013 17:06: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.297.1; Thu, 7 Feb 2013
	17:06:23 +0000
Message-ID: <1360256782.32479.101.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 17:06:22 +0000
In-Reply-To: <20130207164844.GS77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
	<20130207164844.GS77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 17/45] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 16:48 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956583), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
> >  xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/system.h       |  114 --------------------------
> >  3 files changed, 270 insertions(+), 114 deletions(-)
> > 
> > --- a/xen/include/asm-arm/arm64/system.h
> > +++ b/xen/include/asm-arm/arm64/system.h
> > @@ -17,6 +17,161 @@
> >  #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> >  #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> >  
> > +
> > +extern void __bad_xchg(volatile void *, int);
> > +
> > +static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
> > +{
> > +        unsigned long ret, tmp;
> > +
> > +        switch (size) {
> > +        case 1:
> > +                asm volatile("//        __xchg1\n"
> > +                "1:     ldaxrb  %w0, [%3]\n"
> > +                "       stlxrb  %w1, %w2, [%3]\n"
> 
> Why are these using acquire/release ops (i.e. why not LDXR/STXR)?

I nicked this from Linux ;-)

> The 32-bit equivalent doesn't have any memory barriers. 

You mean does? There is a smp_mb() before and after in that
implementation.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:19:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:19: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 1U3V7T-00017Z-G1; Thu, 07 Feb 2013 17:18:43 +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 1U3V7R-00017U-UN
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:18:42 +0000
Received: from [85.158.139.83:38416] by server-2.bemta-5.messagelabs.com id
	E9/A8-16911-FE1E3115; Thu, 07 Feb 2013 17:18:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360257518!28203719!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32144 invoked from network); 7 Feb 2013 17:18:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 17:18:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3V7N-000LK7-Js; Thu, 07 Feb 2013 17:18:37 +0000
Date: Thu, 7 Feb 2013 17:18:37 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130207171837.GT77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
	<20130207164844.GS77133@ocelot.phlegethon.org>
	<1360256782.32479.101.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360256782.32479.101.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 17/45] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:06 +0000 on 07 Feb (1360256782), Ian Campbell wrote:
> On Thu, 2013-02-07 at 16:48 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956583), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
> > >  xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
> > >  xen/include/asm-arm/system.h       |  114 --------------------------
> > >  3 files changed, 270 insertions(+), 114 deletions(-)
> > > 
> > > --- a/xen/include/asm-arm/arm64/system.h
> > > +++ b/xen/include/asm-arm/arm64/system.h
> > > @@ -17,6 +17,161 @@
> > >  #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> > >  #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> > >  
> > > +
> > > +extern void __bad_xchg(volatile void *, int);
> > > +
> > > +static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
> > > +{
> > > +        unsigned long ret, tmp;
> > > +
> > > +        switch (size) {
> > > +        case 1:
> > > +                asm volatile("//        __xchg1\n"
> > > +                "1:     ldaxrb  %w0, [%3]\n"
> > > +                "       stlxrb  %w1, %w2, [%3]\n"
> > 
> > Why are these using acquire/release ops (i.e. why not LDXR/STXR)?
> 
> I nicked this from Linux ;-)
> 
> > The 32-bit equivalent doesn't have any memory barriers. 
> 
> You mean does? There is a smp_mb() before and after in that
> implementation.

Argh, so there is.  I jujst didn't see it for some reason.  So,

Acked-by: Tim Deegan <tim@xen.org>

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:19:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:19: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 1U3V7T-00017Z-G1; Thu, 07 Feb 2013 17:18:43 +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 1U3V7R-00017U-UN
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:18:42 +0000
Received: from [85.158.139.83:38416] by server-2.bemta-5.messagelabs.com id
	E9/A8-16911-FE1E3115; Thu, 07 Feb 2013 17:18:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360257518!28203719!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32144 invoked from network); 7 Feb 2013 17:18:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 17:18:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3V7N-000LK7-Js; Thu, 07 Feb 2013 17:18:37 +0000
Date: Thu, 7 Feb 2013 17:18:37 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130207171837.GT77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-17-git-send-email-ian.campbell@citrix.com>
	<20130207164844.GS77133@ocelot.phlegethon.org>
	<1360256782.32479.101.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360256782.32479.101.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 17/45] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:06 +0000 on 07 Feb (1360256782), Ian Campbell wrote:
> On Thu, 2013-02-07 at 16:48 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956583), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
> > >  xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
> > >  xen/include/asm-arm/system.h       |  114 --------------------------
> > >  3 files changed, 270 insertions(+), 114 deletions(-)
> > > 
> > > --- a/xen/include/asm-arm/arm64/system.h
> > > +++ b/xen/include/asm-arm/arm64/system.h
> > > @@ -17,6 +17,161 @@
> > >  #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> > >  #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> > >  
> > > +
> > > +extern void __bad_xchg(volatile void *, int);
> > > +
> > > +static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
> > > +{
> > > +        unsigned long ret, tmp;
> > > +
> > > +        switch (size) {
> > > +        case 1:
> > > +                asm volatile("//        __xchg1\n"
> > > +                "1:     ldaxrb  %w0, [%3]\n"
> > > +                "       stlxrb  %w1, %w2, [%3]\n"
> > 
> > Why are these using acquire/release ops (i.e. why not LDXR/STXR)?
> 
> I nicked this from Linux ;-)
> 
> > The 32-bit equivalent doesn't have any memory barriers. 
> 
> You mean does? There is a smp_mb() before and after in that
> implementation.

Argh, so there is.  I jujst didn't see it for some reason.  So,

Acked-by: Tim Deegan <tim@xen.org>

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:38:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 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 1U3VQK-0001oz-Bb; Thu, 07 Feb 2013 17:38:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3VQI-0001ou-BD
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:38:10 +0000
Received: from [85.158.138.51:9407] by server-5.bemta-3.messagelabs.com id
	FA/F5-04457-186E3115; Thu, 07 Feb 2013 17:38:09 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360258687!31448789!1
X-Originating-IP: [209.85.219.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4509 invoked from network); 7 Feb 2013 17:38:08 -0000
Received: from mail-oa0-f50.google.com (HELO mail-oa0-f50.google.com)
	(209.85.219.50)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:38:08 -0000
Received: by mail-oa0-f50.google.com with SMTP id l20so3122942oag.9
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 09:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1bw/M0+jQJ1So+o3ZMDDWJzV0MpKKOKwfdawZiFkJjw=;
	b=X8ZOTvEUso5muTLYEzjwDsFNaLF0NEVVehmirrtS1YBaUcD6SsxQ2RQn9Q9K+hRmyr
	9w0QOJ3vaKR6VT0piQjSOI0tRg1kVe8l/kfcC8GoS9Y7HqXYQfxD6T9+Zxw4DSTLe4hz
	XMxBB9DNtYXhowMgCsMJYcztGuBObBZGVXQ1npoXYAYOHYQGi+hgxZU8X6LeST2+nVNe
	V/DzG7O8hbtAHrq2/VisGBCyPHCV0tnRjgCRbNIvOlAyMk4J2d1PLj5NB/nVCZFVcPfy
	R7SrMFK7euM99qlqlLMkRrB6ZXMH0xGozJIfaV1PrWsj0oeSb1CxGkhq4poM5PDF0WUm
	KUCA==
MIME-Version: 1.0
X-Received: by 10.182.146.13 with SMTP id sy13mr1784779obb.45.1360258687051;
	Thu, 07 Feb 2013 09:38:07 -0800 (PST)
Received: by 10.60.33.196 with HTTP; Thu, 7 Feb 2013 09:38:06 -0800 (PST)
In-Reply-To: <5113E71B02000078000BCF86@nat28.tlf.novell.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
	<5113E71B02000078000BCF86@nat28.tlf.novell.com>
Date: Fri, 8 Feb 2013 01:38:06 +0800
X-Google-Sender-Auth: TvEbrTW6xgkYNRnzesLAMzUpf-o
Message-ID: <CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
From: "G.R." <firemeteor@users.sourceforge.net>
To: Jan Beulich <JBeulich@suse.com>, Jean Guyader <Jean.guyader@gmail.com>
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 (config_addr == PCI_INTEL_VENDOR_CAP)
>> +    {
>> +        *val = vendor_cap;
>> +        return 1;
>> +    }
>> +
>> +    /* Remove the next capability link */
>> +    if (config_addr == vendor_cap + 1)
>> +    {
>> +        *val = 0;
>> +        return 1;
>> +    }
>
> It doesn't look right to ignore "len" up to here? What if this is a
> word read at "vendor_cap"?
The function is for intel IGD only and the first two returns are only
sanity checks.
The third is fine also since the PCI register is only one byte in
length and other bytes in that word are reserved.

>
> Also, why would removing the next capability be correct here,
> when you're not removing _all_ other capabilities?

I need help from the original author.
Jean, could you comment on this line in your original patch?

>
>> +
>> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
>> +    if (config_addr >= vendor_cap &&
>> +            config_addr + len <= vendor_cap + cap_size)
>> +    {
>> +        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
>> +        return 1;
>> +    }
>
> Similarly such a read wouldn't get handled consistently (with the
> above intention) here: You're not masking off the byte at
> "vendor_cap + 1".
>
Same as above. Jean, could you comment?

>> +    /* Exposing writable register does not lead to security risk since this
>> +       only apply to read. This may confuse the guest, but it works good so far.
>> +       Will switch to mask & merge style only if this is proved broken.
>> +       Note: Always expose aligned address if any byte of the dword is to be
>> +       exposed. This provides a consistent view, at least for read. */
>
> Such a comment is certainly not helping being confident in the
> changes you're trying to get merged in.

Could you be more specific on your suggestion?
I don't think you are recommending to remove them.
Some clarification: The 'Note' sentence just make it explicit the rule
that existing code follows.
And the first sentence about the writeable register are for the
'command' register, which is a side effect of the same rule due to the
'status' register.

Thanks,
Timothy (Rui)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:38:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 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 1U3VQK-0001oz-Bb; Thu, 07 Feb 2013 17:38:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3VQI-0001ou-BD
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:38:10 +0000
Received: from [85.158.138.51:9407] by server-5.bemta-3.messagelabs.com id
	FA/F5-04457-186E3115; Thu, 07 Feb 2013 17:38:09 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360258687!31448789!1
X-Originating-IP: [209.85.219.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4509 invoked from network); 7 Feb 2013 17:38:08 -0000
Received: from mail-oa0-f50.google.com (HELO mail-oa0-f50.google.com)
	(209.85.219.50)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:38:08 -0000
Received: by mail-oa0-f50.google.com with SMTP id l20so3122942oag.9
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 09:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1bw/M0+jQJ1So+o3ZMDDWJzV0MpKKOKwfdawZiFkJjw=;
	b=X8ZOTvEUso5muTLYEzjwDsFNaLF0NEVVehmirrtS1YBaUcD6SsxQ2RQn9Q9K+hRmyr
	9w0QOJ3vaKR6VT0piQjSOI0tRg1kVe8l/kfcC8GoS9Y7HqXYQfxD6T9+Zxw4DSTLe4hz
	XMxBB9DNtYXhowMgCsMJYcztGuBObBZGVXQ1npoXYAYOHYQGi+hgxZU8X6LeST2+nVNe
	V/DzG7O8hbtAHrq2/VisGBCyPHCV0tnRjgCRbNIvOlAyMk4J2d1PLj5NB/nVCZFVcPfy
	R7SrMFK7euM99qlqlLMkRrB6ZXMH0xGozJIfaV1PrWsj0oeSb1CxGkhq4poM5PDF0WUm
	KUCA==
MIME-Version: 1.0
X-Received: by 10.182.146.13 with SMTP id sy13mr1784779obb.45.1360258687051;
	Thu, 07 Feb 2013 09:38:07 -0800 (PST)
Received: by 10.60.33.196 with HTTP; Thu, 7 Feb 2013 09:38:06 -0800 (PST)
In-Reply-To: <5113E71B02000078000BCF86@nat28.tlf.novell.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
	<5113E71B02000078000BCF86@nat28.tlf.novell.com>
Date: Fri, 8 Feb 2013 01:38:06 +0800
X-Google-Sender-Auth: TvEbrTW6xgkYNRnzesLAMzUpf-o
Message-ID: <CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
From: "G.R." <firemeteor@users.sourceforge.net>
To: Jan Beulich <JBeulich@suse.com>, Jean Guyader <Jean.guyader@gmail.com>
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 (config_addr == PCI_INTEL_VENDOR_CAP)
>> +    {
>> +        *val = vendor_cap;
>> +        return 1;
>> +    }
>> +
>> +    /* Remove the next capability link */
>> +    if (config_addr == vendor_cap + 1)
>> +    {
>> +        *val = 0;
>> +        return 1;
>> +    }
>
> It doesn't look right to ignore "len" up to here? What if this is a
> word read at "vendor_cap"?
The function is for intel IGD only and the first two returns are only
sanity checks.
The third is fine also since the PCI register is only one byte in
length and other bytes in that word are reserved.

>
> Also, why would removing the next capability be correct here,
> when you're not removing _all_ other capabilities?

I need help from the original author.
Jean, could you comment on this line in your original patch?

>
>> +
>> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
>> +    if (config_addr >= vendor_cap &&
>> +            config_addr + len <= vendor_cap + cap_size)
>> +    {
>> +        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
>> +        return 1;
>> +    }
>
> Similarly such a read wouldn't get handled consistently (with the
> above intention) here: You're not masking off the byte at
> "vendor_cap + 1".
>
Same as above. Jean, could you comment?

>> +    /* Exposing writable register does not lead to security risk since this
>> +       only apply to read. This may confuse the guest, but it works good so far.
>> +       Will switch to mask & merge style only if this is proved broken.
>> +       Note: Always expose aligned address if any byte of the dword is to be
>> +       exposed. This provides a consistent view, at least for read. */
>
> Such a comment is certainly not helping being confident in the
> changes you're trying to get merged in.

Could you be more specific on your suggestion?
I don't think you are recommending to remove them.
Some clarification: The 'Note' sentence just make it explicit the rule
that existing code follows.
And the first sentence about the writeable register are for the
'command' register, which is a side effect of the same rule due to the
'status' register.

Thanks,
Timothy (Rui)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:43:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17: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 1U3VVR-0002MM-OA; Thu, 07 Feb 2013 17:43:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3VVQ-0002Kf-0N
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:43:28 +0000
Received: from [85.158.143.35:4890] by server-2.bemta-4.messagelabs.com id
	AD/8B-01597-FB7E3115; Thu, 07 Feb 2013 17:43:27 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360259000!14109513!1
X-Originating-IP: [209.85.219.46]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14011 invoked from network); 7 Feb 2013 17:43:22 -0000
Received: from mail-oa0-f46.google.com (HELO mail-oa0-f46.google.com)
	(209.85.219.46)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:43:22 -0000
Received: by mail-oa0-f46.google.com with SMTP id k1so3093653oag.5
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 09:43:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=+bmVZBVo8P+pIP3jMiZiLgtHc5Ty8mutIQ0bB/cnPgQ=;
	b=Xf14SQLHmt17yI/U9n5x6wE+NcfuIa2CtHEk9CfT1EVuAs4MX+P58jbkkg6Q5xPLpT
	EizkH763BsY6nNIi4Q3gSh1ihofmkXIzDZgxocw5BniUHrHaeVvZWtKZ3E55cqv75UoE
	ctfoHhT1oYkJfNawwZmMpwT+C8RBEM9Vi/ZPYZT5DVKWaWxCq6ABNm/hICyVptqe9aN2
	RfFWvq8DgwXhxr5/rFbplHGwIVHuwqakqQa0ikLep3DC5lrAqmaInkPpVCzd3fe/ftuC
	9tGQBSdzp9thrVng9WWJsnXKZ5xGObiR8/Vz99emZFZLj1w+HRwRuJRB0O4t8pmo/TR8
	eKOg==
MIME-Version: 1.0
X-Received: by 10.60.172.229 with SMTP id bf5mr1766389oec.81.1360259000136;
	Thu, 07 Feb 2013 09:43:20 -0800 (PST)
Received: by 10.60.33.196 with HTTP; Thu, 7 Feb 2013 09:43:20 -0800 (PST)
In-Reply-To: <5113E4C302000078000BCF6B@nat28.tlf.novell.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
Date: Fri, 8 Feb 2013 01:43:20 +0800
X-Google-Sender-Auth: 2AQkPVbL_YvdjzthtOIQWbojrBk
Message-ID: <CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
From: "G.R." <firemeteor@users.sourceforge.net>
To: Jan Beulich <JBeulich@suse.com>, stefano.stabellini@citrix.com
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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

>
> For one I wonder whether this is really _always_ correct. I.e.
> the device at 00:1f.0 always being an ISA bridge. Wouldn't it
> be better to mirror whatever the host device says?
>
>From the Intel driver code, it's looking for an intel ISA bridge.
So your question would be should it be always at 00:1f.0.
So far it seems that it is.

> And then I don't see why you need to open code all of
> pci_bridge_init() instead of just overriding the class value after
> you called that function (or, if the order of events for some
> reason matters, adding another parameter to the function).

Stefano, could you comment? It's your code after all.

Thanks,
Timothy (Rui)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:43:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17: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 1U3VVR-0002MM-OA; Thu, 07 Feb 2013 17:43:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <firemeteor.guo@gmail.com>) id 1U3VVQ-0002Kf-0N
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:43:28 +0000
Received: from [85.158.143.35:4890] by server-2.bemta-4.messagelabs.com id
	AD/8B-01597-FB7E3115; Thu, 07 Feb 2013 17:43:27 +0000
X-Env-Sender: firemeteor.guo@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360259000!14109513!1
X-Originating-IP: [209.85.219.46]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14011 invoked from network); 7 Feb 2013 17:43:22 -0000
Received: from mail-oa0-f46.google.com (HELO mail-oa0-f46.google.com)
	(209.85.219.46)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:43:22 -0000
Received: by mail-oa0-f46.google.com with SMTP id k1so3093653oag.5
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 09:43:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=+bmVZBVo8P+pIP3jMiZiLgtHc5Ty8mutIQ0bB/cnPgQ=;
	b=Xf14SQLHmt17yI/U9n5x6wE+NcfuIa2CtHEk9CfT1EVuAs4MX+P58jbkkg6Q5xPLpT
	EizkH763BsY6nNIi4Q3gSh1ihofmkXIzDZgxocw5BniUHrHaeVvZWtKZ3E55cqv75UoE
	ctfoHhT1oYkJfNawwZmMpwT+C8RBEM9Vi/ZPYZT5DVKWaWxCq6ABNm/hICyVptqe9aN2
	RfFWvq8DgwXhxr5/rFbplHGwIVHuwqakqQa0ikLep3DC5lrAqmaInkPpVCzd3fe/ftuC
	9tGQBSdzp9thrVng9WWJsnXKZ5xGObiR8/Vz99emZFZLj1w+HRwRuJRB0O4t8pmo/TR8
	eKOg==
MIME-Version: 1.0
X-Received: by 10.60.172.229 with SMTP id bf5mr1766389oec.81.1360259000136;
	Thu, 07 Feb 2013 09:43:20 -0800 (PST)
Received: by 10.60.33.196 with HTTP; Thu, 7 Feb 2013 09:43:20 -0800 (PST)
In-Reply-To: <5113E4C302000078000BCF6B@nat28.tlf.novell.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
Date: Fri, 8 Feb 2013 01:43:20 +0800
X-Google-Sender-Auth: 2AQkPVbL_YvdjzthtOIQWbojrBk
Message-ID: <CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
From: "G.R." <firemeteor@users.sourceforge.net>
To: Jan Beulich <JBeulich@suse.com>, stefano.stabellini@citrix.com
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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

>
> For one I wonder whether this is really _always_ correct. I.e.
> the device at 00:1f.0 always being an ISA bridge. Wouldn't it
> be better to mirror whatever the host device says?
>
>From the Intel driver code, it's looking for an intel ISA bridge.
So your question would be should it be always at 00:1f.0.
So far it seems that it is.

> And then I don't see why you need to open code all of
> pci_bridge_init() instead of just overriding the class value after
> you called that function (or, if the order of events for some
> reason matters, adding another parameter to the function).

Stefano, could you comment? It's your code after all.

Thanks,
Timothy (Rui)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:50:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:50: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 1U3VbY-0002eA-In; Thu, 07 Feb 2013 17:49:48 +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 1U3VbW-0002e4-Tz
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:49:47 +0000
Received: from [85.158.138.51:25243] by server-5.bemta-3.messagelabs.com id
	90/F1-04457-539E3115; Thu, 07 Feb 2013 17:49:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360259379!31490879!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18401 invoked from network); 7 Feb 2013 17:49:40 -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;
	7 Feb 2013 17:49:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6684189"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 17:49:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 12:49:38 -0500
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 1U3VbO-00016L-Ad	for xen-devel@lists.xen.org;
	Thu, 07 Feb 2013 17:49:38 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U3VbO-0006Ea-0O	for
	xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:49:38 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7feb83e3f79a3094e3002560c896a9ee97f1e907
Message-ID: <7feb83e3f79a3094e300.1360259377@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 7 Feb 2013 17:49:37 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360259288 0
# Node ID 7feb83e3f79a3094e3002560c896a9ee97f1e907
# Parent  6c1b12c884b4521a940e079c8dfebc5d8e88d2e9
x86/setup: don't relocate the VGA hole.

Copying the contents of the VGA hole is at best pointless and at worst
dangerous.  Booting Xen on Xen, it causes a very long delay as each
byte is referred to qemu.

Since we were already discarding the first 1MB of the relocated area,
just avoid copying it in the first place.

Reported-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 6c1b12c884b4 -r 7feb83e3f79a xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Tue Feb 05 15:47:41 2013 +0000
+++ b/xen/arch/x86/setup.c	Thu Feb 07 17:48:08 2013 +0000
@@ -826,7 +826,6 @@ void __init __start_xen(unsigned long mb
             l3_pgentry_t *pl3e;
             l2_pgentry_t *pl2e;
             int i, j, k;
-            void *dst;
 
             /* Select relocation address. */
             e = end - reloc_size;
@@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
              * data until after we have switched to the relocated pagetables!
              */
             barrier();
-            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START, 1);
-
-            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
-            memset(dst, 0x55, 1U << 20);
+            move_memory(e + (1u << 20), (1u << 20),
+                      ((unsigned long)&_end - XEN_VIRT_START) - (1u << 20), 1);
 
             /* Walk initial pagetables, relocating page directory entries. */
             pl4e = __va(__pa(idle_pg_table));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:50:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:50: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 1U3VbY-0002eA-In; Thu, 07 Feb 2013 17:49:48 +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 1U3VbW-0002e4-Tz
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:49:47 +0000
Received: from [85.158.138.51:25243] by server-5.bemta-3.messagelabs.com id
	90/F1-04457-539E3115; Thu, 07 Feb 2013 17:49:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360259379!31490879!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18401 invoked from network); 7 Feb 2013 17:49:40 -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;
	7 Feb 2013 17:49:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6684189"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 17:49:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 12:49:38 -0500
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 1U3VbO-00016L-Ad	for xen-devel@lists.xen.org;
	Thu, 07 Feb 2013 17:49:38 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U3VbO-0006Ea-0O	for
	xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:49:38 +0000
MIME-Version: 1.0
X-Mercurial-Node: 7feb83e3f79a3094e3002560c896a9ee97f1e907
Message-ID: <7feb83e3f79a3094e300.1360259377@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 7 Feb 2013 17:49:37 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360259288 0
# Node ID 7feb83e3f79a3094e3002560c896a9ee97f1e907
# Parent  6c1b12c884b4521a940e079c8dfebc5d8e88d2e9
x86/setup: don't relocate the VGA hole.

Copying the contents of the VGA hole is at best pointless and at worst
dangerous.  Booting Xen on Xen, it causes a very long delay as each
byte is referred to qemu.

Since we were already discarding the first 1MB of the relocated area,
just avoid copying it in the first place.

Reported-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 6c1b12c884b4 -r 7feb83e3f79a xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Tue Feb 05 15:47:41 2013 +0000
+++ b/xen/arch/x86/setup.c	Thu Feb 07 17:48:08 2013 +0000
@@ -826,7 +826,6 @@ void __init __start_xen(unsigned long mb
             l3_pgentry_t *pl3e;
             l2_pgentry_t *pl2e;
             int i, j, k;
-            void *dst;
 
             /* Select relocation address. */
             e = end - reloc_size;
@@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
              * data until after we have switched to the relocated pagetables!
              */
             barrier();
-            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START, 1);
-
-            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
-            memset(dst, 0x55, 1U << 20);
+            move_memory(e + (1u << 20), (1u << 20),
+                      ((unsigned long)&_end - XEN_VIRT_START) - (1u << 20), 1);
 
             /* Walk initial pagetables, relocating page directory entries. */
             pl4e = __va(__pa(idle_pg_table));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 17:58:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:58: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 1U3VjE-00038D-IE; Thu, 07 Feb 2013 17:57:44 +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 1U3VjD-000388-3D
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:57:43 +0000
Received: from [85.158.139.211:51671] by server-13.bemta-5.messagelabs.com id
	CC/18-06769-61BE3115; Thu, 07 Feb 2013 17:57:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360259860!21547709!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32622 invoked from network); 7 Feb 2013 17:57:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:57:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6356394"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 17:57:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 12:57:39 -0500
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 1U3Vj9-0001DS-HL;
	Thu, 07 Feb 2013 17:57:39 +0000
Message-ID: <5113E959.5070608@eu.citrix.com>
Date: Thu, 7 Feb 2013 17:50:17 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<45d2f5dc459ce84ca7ee.1359716473@Solace>
In-Reply-To: <45d2f5dc459ce84ca7ee.1359716473@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 03 of 11 v3] xen: sched_credit: when picking,
 make sure we get an idle one, if any
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 01/02/13 11:01, Dario Faggioli wrote:
> The pcpu picking algorithm treats two threads of a SMT core the same.
> More specifically, if one is idle and the other one is busy, they both
> will be assigned a weight of 1. Therefore, when picking begins, if the
> first target pcpu is the busy thread (and if there are no other idle
> pcpu than its sibling), that will never change.
>
> This change fixes this by ensuring that, before entering the core of
> the picking algorithm, the target pcpu is an idle one (if there is an
> idle pcpu at all, of course).
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-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 Feb 07 17:58:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 17:58: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 1U3VjE-00038D-IE; Thu, 07 Feb 2013 17:57:44 +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 1U3VjD-000388-3D
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 17:57:43 +0000
Received: from [85.158.139.211:51671] by server-13.bemta-5.messagelabs.com id
	CC/18-06769-61BE3115; Thu, 07 Feb 2013 17:57:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360259860!21547709!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32622 invoked from network); 7 Feb 2013 17:57:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 17:57:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6356394"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 17:57:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 12:57:39 -0500
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 1U3Vj9-0001DS-HL;
	Thu, 07 Feb 2013 17:57:39 +0000
Message-ID: <5113E959.5070608@eu.citrix.com>
Date: Thu, 7 Feb 2013 17:50:17 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace>
	<45d2f5dc459ce84ca7ee.1359716473@Solace>
In-Reply-To: <45d2f5dc459ce84ca7ee.1359716473@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 03 of 11 v3] xen: sched_credit: when picking,
 make sure we get an idle one, if any
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 01/02/13 11:01, Dario Faggioli wrote:
> The pcpu picking algorithm treats two threads of a SMT core the same.
> More specifically, if one is idle and the other one is busy, they both
> will be assigned a weight of 1. Therefore, when picking begins, if the
> first target pcpu is the busy thread (and if there are no other idle
> pcpu than its sibling), that will never change.
>
> This change fixes this by ensuring that, before entering the core of
> the picking algorithm, the target pcpu is an idle one (if there is an
> idle pcpu at all, of course).
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-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 Feb 07 20:23:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 20:23: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 1U3Y0G-0008Hz-R2; Thu, 07 Feb 2013 20:23: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 1U3Y0F-0008Hu-H3
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 20:23:27 +0000
Received: from [85.158.138.51:24638] by server-5.bemta-3.messagelabs.com id
	A9/48-04457-E3D04115; Thu, 07 Feb 2013 20:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360268604!31505002!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26969 invoked from network); 7 Feb 2013 20:23:25 -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;
	7 Feb 2013 20:23:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6709420"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 20:23:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 15:23:23 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3Y0B-0003IW-3s;
	Thu, 07 Feb 2013 20:23:23 +0000
Message-ID: <1360268453.22622.30.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 21:20:53 +0100
In-Reply-To: <7feb83e3f79a3094e300.1360259377@whitby.uk.xensource.com>
References: <7feb83e3f79a3094e300.1360259377@whitby.uk.xensource.com>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
>               * data until after we have switched to the relocated pagetables!
>               */
>              barrier();
> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START, 1);
> -
> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
> -            memset(dst, 0x55, 1U << 20);

Is this poisoning not still desirable?

> +            move_memory(e + (1u << 20), (1u << 20),
> +                      ((unsigned long)&_end - XEN_VIRT_START) - (1u << 20), 1);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 20:23:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 20:23: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 1U3Y0G-0008Hz-R2; Thu, 07 Feb 2013 20:23: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 1U3Y0F-0008Hu-H3
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 20:23:27 +0000
Received: from [85.158.138.51:24638] by server-5.bemta-3.messagelabs.com id
	A9/48-04457-E3D04115; Thu, 07 Feb 2013 20:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360268604!31505002!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26969 invoked from network); 7 Feb 2013 20:23:25 -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;
	7 Feb 2013 20:23:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6709420"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 20:23:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 15:23:23 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3Y0B-0003IW-3s;
	Thu, 07 Feb 2013 20:23:23 +0000
Message-ID: <1360268453.22622.30.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 7 Feb 2013 21:20:53 +0100
In-Reply-To: <7feb83e3f79a3094e300.1360259377@whitby.uk.xensource.com>
References: <7feb83e3f79a3094e300.1360259377@whitby.uk.xensource.com>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
>               * data until after we have switched to the relocated pagetables!
>               */
>              barrier();
> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START, 1);
> -
> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
> -            memset(dst, 0x55, 1U << 20);

Is this poisoning not still desirable?

> +            move_memory(e + (1u << 20), (1u << 20),
> +                      ((unsigned long)&_end - XEN_VIRT_START) - (1u << 20), 1);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 20:39:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 20:39: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 1U3YF0-0000HW-AT; Thu, 07 Feb 2013 20:38:42 +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 1U3YEy-0000HR-Vw
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 20:38:41 +0000
Received: from [85.158.139.211:47090] by server-2.bemta-5.messagelabs.com id
	3F/BF-16911-0D014115; Thu, 07 Feb 2013 20:38:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360269519!21262709!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31070 invoked from network); 7 Feb 2013 20:38:39 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 20:38:39 -0000
Received: by mail-wg0-f50.google.com with SMTP id es5so2405140wgb.29
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 12:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0nOpD7gLe1zLjQB/N2k1SPDLo6rWYaesAig/BS22Kwg=;
	b=CjIe8KMNXFA8PeIyppjDy1S7rvWVMTutPI9HwunGfs/w78DoO+OuXtbWlClsz1IWJx
	QoheCjSdSMvrfpYad7EU1wPeoX/aekdoeQRG6vLjlskekVRYeJTkOdiPBhmA15ecgrtJ
	/v05KdX5iA2H8UZC/fb6ddX2quZk5Lca4WHINzImsadgB4zLQOSFJ6r120jXloPoW8+z
	GwHIZ4abkTDXti6QqER36UHrdRo6xgKhw0vjNlX/QlVk/GjeCuTyuC4d8/6ifvUbYZoP
	pSlCiHIb3WC+eSQfW+GjSY0wF/xwijavprosSuV0N5qtZAam1VMmSPgrax2HT3SeXcey
	Ws2Q==
X-Received: by 10.180.101.98 with SMTP id ff2mr342678wib.0.1360269519493;
	Thu, 07 Feb 2013 12:38:39 -0800 (PST)
Received: from [192.168.1.94] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id gy2sm11711245wib.3.2013.02.07.12.38.34
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 12:38:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 07 Feb 2013 20:38:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD39C148.4B872%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
Thread-Index: Ac4FcxfcHeEZHkalEUa6SbPobnaNuw==
In-Reply-To: <1360268453.22622.30.camel@hastur.hellion.org.uk>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/02/2013 20:20, "Ian Campbell" <ian.campbell@citrix.com> wrote:

>> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
>>               * data until after we have switched to the relocated
>> pagetables!
>>               */
>>              barrier();
>> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START,
>> 1);
>> -
>> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
>> -            memset(dst, 0x55, 1U << 20);
> 
> Is this poisoning not still desirable?

If we don't copy that low 1MB I don't see any reason to poison it at the
destination.

>> +            move_memory(e + (1u << 20), (1u << 20),
>> +                      ((unsigned long)&_end - XEN_VIRT_START) - (1u << 20),
>> 1);

1MB here is actually something of a magic number. We could make use of
_start instead, eg:

off = (ulong)&_start - XEN_VIRT_START;
move_memory(e + off, off, (ulong)&_end - (ulong)&_start, 1);

This would be my preference.

 -- Keir

> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 07 20:39:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 20:39: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 1U3YF0-0000HW-AT; Thu, 07 Feb 2013 20:38:42 +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 1U3YEy-0000HR-Vw
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 20:38:41 +0000
Received: from [85.158.139.211:47090] by server-2.bemta-5.messagelabs.com id
	3F/BF-16911-0D014115; Thu, 07 Feb 2013 20:38:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360269519!21262709!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31070 invoked from network); 7 Feb 2013 20:38:39 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 20:38:39 -0000
Received: by mail-wg0-f50.google.com with SMTP id es5so2405140wgb.29
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 12:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0nOpD7gLe1zLjQB/N2k1SPDLo6rWYaesAig/BS22Kwg=;
	b=CjIe8KMNXFA8PeIyppjDy1S7rvWVMTutPI9HwunGfs/w78DoO+OuXtbWlClsz1IWJx
	QoheCjSdSMvrfpYad7EU1wPeoX/aekdoeQRG6vLjlskekVRYeJTkOdiPBhmA15ecgrtJ
	/v05KdX5iA2H8UZC/fb6ddX2quZk5Lca4WHINzImsadgB4zLQOSFJ6r120jXloPoW8+z
	GwHIZ4abkTDXti6QqER36UHrdRo6xgKhw0vjNlX/QlVk/GjeCuTyuC4d8/6ifvUbYZoP
	pSlCiHIb3WC+eSQfW+GjSY0wF/xwijavprosSuV0N5qtZAam1VMmSPgrax2HT3SeXcey
	Ws2Q==
X-Received: by 10.180.101.98 with SMTP id ff2mr342678wib.0.1360269519493;
	Thu, 07 Feb 2013 12:38:39 -0800 (PST)
Received: from [192.168.1.94] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id gy2sm11711245wib.3.2013.02.07.12.38.34
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 12:38:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 07 Feb 2013 20:38:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD39C148.4B872%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
Thread-Index: Ac4FcxfcHeEZHkalEUa6SbPobnaNuw==
In-Reply-To: <1360268453.22622.30.camel@hastur.hellion.org.uk>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/02/2013 20:20, "Ian Campbell" <ian.campbell@citrix.com> wrote:

>> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
>>               * data until after we have switched to the relocated
>> pagetables!
>>               */
>>              barrier();
>> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START,
>> 1);
>> -
>> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
>> -            memset(dst, 0x55, 1U << 20);
> 
> Is this poisoning not still desirable?

If we don't copy that low 1MB I don't see any reason to poison it at the
destination.

>> +            move_memory(e + (1u << 20), (1u << 20),
>> +                      ((unsigned long)&_end - XEN_VIRT_START) - (1u << 20),
>> 1);

1MB here is actually something of a magic number. We could make use of
_start instead, eg:

off = (ulong)&_start - XEN_VIRT_START;
move_memory(e + off, off, (ulong)&_end - (ulong)&_start, 1);

This would be my preference.

 -- Keir

> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 07 21:17:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21: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 1U3Yq5-0001x3-Ij; Thu, 07 Feb 2013 21:17:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arrfab@centos.org>) id 1U3YRr-0001EX-81
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 20:51:59 +0000
Received: from [85.158.143.35:2165] by server-2.bemta-4.messagelabs.com id
	16/94-01597-EE314115; Thu, 07 Feb 2013 20:51:58 +0000
X-Env-Sender: arrfab@centos.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360270316!15617196!1
X-Originating-IP: [188.40.68.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13109 invoked from network); 7 Feb 2013 20:51:57 -0000
Received: from tungstene.arrfab.net (HELO oxygen.arrfab.net) (188.40.68.214)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 20:51:57 -0000
Received: from w9980138l.cpc998.be (localhost.localdomain [127.0.0.1])
	by oxygen.arrfab.net (8.13.8/8.13.8) with ESMTP id r17Kpq6C027600;
	Thu, 7 Feb 2013 21:51:52 +0100
Message-ID: <511413E8.3090407@centos.org>
Date: Thu, 07 Feb 2013 21:51:52 +0100
From: Fabian Arrotin <arrfab@centos.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: agya naila <agya.naila@gmail.com>
References: <20130206132802.GU8912@reaktio.net>
	<CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
In-Reply-To: <CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
X-Mailman-Approved-At: Thu, 07 Feb 2013 21:17:00 +0000
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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 02/06/2013 02:39 PM, agya naila wrote:
> I configure it by added nmi=ignore to my /boot/grub/grub.cfg
> 

Just to add that I also tried the nmi=ignore parameter for Xen, and it
stills hard reboot/resets automatically during the kernel dom0 boot

Fabian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 21:17:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21: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 1U3Yq5-0001x3-Ij; Thu, 07 Feb 2013 21:17:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arrfab@centos.org>) id 1U3YRr-0001EX-81
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 20:51:59 +0000
Received: from [85.158.143.35:2165] by server-2.bemta-4.messagelabs.com id
	16/94-01597-EE314115; Thu, 07 Feb 2013 20:51:58 +0000
X-Env-Sender: arrfab@centos.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360270316!15617196!1
X-Originating-IP: [188.40.68.214]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13109 invoked from network); 7 Feb 2013 20:51:57 -0000
Received: from tungstene.arrfab.net (HELO oxygen.arrfab.net) (188.40.68.214)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 20:51:57 -0000
Received: from w9980138l.cpc998.be (localhost.localdomain [127.0.0.1])
	by oxygen.arrfab.net (8.13.8/8.13.8) with ESMTP id r17Kpq6C027600;
	Thu, 7 Feb 2013 21:51:52 +0100
Message-ID: <511413E8.3090407@centos.org>
Date: Thu, 07 Feb 2013 21:51:52 +0100
From: Fabian Arrotin <arrfab@centos.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: agya naila <agya.naila@gmail.com>
References: <20130206132802.GU8912@reaktio.net>
	<CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
In-Reply-To: <CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
X-Mailman-Approved-At: Thu, 07 Feb 2013 21:17:00 +0000
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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 02/06/2013 02:39 PM, agya naila wrote:
> I configure it by added nmi=ignore to my /boot/grub/grub.cfg
> 

Just to add that I also tried the nmi=ignore parameter for Xen, and it
stills hard reboot/resets automatically during the kernel dom0 boot

Fabian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 21:32:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21: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 1U3Z50-0002fW-4L; Thu, 07 Feb 2013 21:32: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 1U3Z4y-0002fR-9d
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 21:32:24 +0000
Received: from [85.158.143.99:51135] by server-1.bemta-4.messagelabs.com id
	7E/DA-08839-76D14115; Thu, 07 Feb 2013 21:32:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360272741!30433740!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23218 invoked from network); 7 Feb 2013 21:32:23 -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;
	7 Feb 2013 21:32:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6718209"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 21:32:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 16:32:21 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3Z4u-0004Gr-Nd;
	Thu, 07 Feb 2013 21:32:20 +0000
Message-ID: <1360272591.22622.33.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 7 Feb 2013 22:29:51 +0100
In-Reply-To: <CD39C148.4B872%keir.xen@gmail.com>
References: <CD39C148.4B872%keir.xen@gmail.com>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 20:38 +0000, Keir Fraser wrote:
> On 07/02/2013 20:20, "Ian Campbell" <ian.campbell@citrix.com> wrote:
> 
> >> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
> >>               * data until after we have switched to the relocated
> >> pagetables!
> >>               */
> >>              barrier();
> >> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START,
> >> 1);
> >> -
> >> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
> >> -            memset(dst, 0x55, 1U << 20);
> > 
> > Is this poisoning not still desirable?
> 
> If we don't copy that low 1MB I don't see any reason to poison it at the
> destination.

The poisoning was to protect against stray pointers out of the low 1MB
region? I assumed it was against pointers into 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 Feb 07 21:32:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21: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 1U3Z50-0002fW-4L; Thu, 07 Feb 2013 21:32: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 1U3Z4y-0002fR-9d
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 21:32:24 +0000
Received: from [85.158.143.99:51135] by server-1.bemta-4.messagelabs.com id
	7E/DA-08839-76D14115; Thu, 07 Feb 2013 21:32:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360272741!30433740!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgzNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23218 invoked from network); 7 Feb 2013 21:32:23 -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;
	7 Feb 2013 21:32:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6718209"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 21:32:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 16:32:21 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3Z4u-0004Gr-Nd;
	Thu, 07 Feb 2013 21:32:20 +0000
Message-ID: <1360272591.22622.33.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 7 Feb 2013 22:29:51 +0100
In-Reply-To: <CD39C148.4B872%keir.xen@gmail.com>
References: <CD39C148.4B872%keir.xen@gmail.com>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 20:38 +0000, Keir Fraser wrote:
> On 07/02/2013 20:20, "Ian Campbell" <ian.campbell@citrix.com> wrote:
> 
> >> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
> >>               * data until after we have switched to the relocated
> >> pagetables!
> >>               */
> >>              barrier();
> >> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START,
> >> 1);
> >> -
> >> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
> >> -            memset(dst, 0x55, 1U << 20);
> > 
> > Is this poisoning not still desirable?
> 
> If we don't copy that low 1MB I don't see any reason to poison it at the
> destination.

The poisoning was to protect against stray pointers out of the low 1MB
region? I assumed it was against pointers into 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 Feb 07 21:39:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21:39: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 1U3ZB7-0002oc-Vb; Thu, 07 Feb 2013 21:38:45 +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 1U3ZB7-0002oV-1W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 21:38:45 +0000
Received: from [85.158.139.211:17610] by server-8.bemta-5.messagelabs.com id
	57/F0-19075-4EE14115; Thu, 07 Feb 2013 21:38:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360273123!20474555!1
X-Originating-IP: [74.125.82.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19966 invoked from network); 7 Feb 2013 21:38:43 -0000
Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com)
	(74.125.82.175)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 21:38:43 -0000
Received: by mail-we0-f175.google.com with SMTP id x8so2561874wey.34
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 13:38:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=3vH44uVUrAoqz7OOQIj8XNAWK2p6bn8EZ29pQ4tLNdM=;
	b=Vz/brayJsYoq3MTiwQ4kZjvBiOLQtD3ThpPpehiroVSXEU0XB+RMA12pmgv+mLoLjH
	YDC4lAw3Fglt+teuZs6b69pF3Qi4FWc2DJaK83LoZBCk7lD1rlBkahnN1nequfVamPMv
	rAQNTPWxxi6dZNosmOy6XvSICmIVt3GSPmODJWvGzrG1uMHY1MMr8Dj3ffUxk7MUO2en
	vfTKAYqaFrMqbMIBgdiBSNt0YA/rF5ZGac91ERI5VapeV/vhwrAS5ga+e4D80l3NxF6/
	5BMSWHIGPIeib9KVBVn0QgGGIlThnyXWqCbXYrCMxu5jwXfaA23mDV1+EaZrSmBlP/bh
	3RzA==
X-Received: by 10.180.84.199 with SMTP id b7mr5639160wiz.22.1360273123351;
	Thu, 07 Feb 2013 13:38:43 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id t7sm4339116wiy.2.2013.02.07.13.38.41
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 13:38:42 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 07 Feb 2013 21:38:38 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <CD39CF5E.5A732%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
Thread-Index: Ac4Fe3001asj4U7QzEaAExlPcc+yrg==
In-Reply-To: <1360272591.22622.33.camel@hastur.hellion.org.uk>
Mime-version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/02/2013 21:29, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> On Thu, 2013-02-07 at 20:38 +0000, Keir Fraser wrote:
>> On 07/02/2013 20:20, "Ian Campbell" <ian.campbell@citrix.com> wrote:
>> 
>>>> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
>>>>               * data until after we have switched to the relocated
>>>> pagetables!
>>>>               */
>>>>              barrier();
>>>> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START,
>>>> 1);
>>>> -
>>>> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB.
>>>> */
>>>> -            memset(dst, 0x55, 1U << 20);
>>> 
>>> Is this poisoning not still desirable?
>> 
>> If we don't copy that low 1MB I don't see any reason to poison it at the
>> destination.
> 
> The poisoning was to protect against stray pointers out of the low 1MB
> region? I assumed it was against pointers into it...

I mean any stray pointers into that region are only going to see garbage at
the relocated highmem address anyway, as contents of 0-1MB are no longer
being copied. So deliberate poisoning seems even more paranoid than it
already was (it was already really quite paranoid).

 -- 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 Feb 07 21:39:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21:39: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 1U3ZB7-0002oc-Vb; Thu, 07 Feb 2013 21:38:45 +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 1U3ZB7-0002oV-1W
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 21:38:45 +0000
Received: from [85.158.139.211:17610] by server-8.bemta-5.messagelabs.com id
	57/F0-19075-4EE14115; Thu, 07 Feb 2013 21:38:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360273123!20474555!1
X-Originating-IP: [74.125.82.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19966 invoked from network); 7 Feb 2013 21:38:43 -0000
Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com)
	(74.125.82.175)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 21:38:43 -0000
Received: by mail-we0-f175.google.com with SMTP id x8so2561874wey.34
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 13:38:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=3vH44uVUrAoqz7OOQIj8XNAWK2p6bn8EZ29pQ4tLNdM=;
	b=Vz/brayJsYoq3MTiwQ4kZjvBiOLQtD3ThpPpehiroVSXEU0XB+RMA12pmgv+mLoLjH
	YDC4lAw3Fglt+teuZs6b69pF3Qi4FWc2DJaK83LoZBCk7lD1rlBkahnN1nequfVamPMv
	rAQNTPWxxi6dZNosmOy6XvSICmIVt3GSPmODJWvGzrG1uMHY1MMr8Dj3ffUxk7MUO2en
	vfTKAYqaFrMqbMIBgdiBSNt0YA/rF5ZGac91ERI5VapeV/vhwrAS5ga+e4D80l3NxF6/
	5BMSWHIGPIeib9KVBVn0QgGGIlThnyXWqCbXYrCMxu5jwXfaA23mDV1+EaZrSmBlP/bh
	3RzA==
X-Received: by 10.180.84.199 with SMTP id b7mr5639160wiz.22.1360273123351;
	Thu, 07 Feb 2013 13:38:43 -0800 (PST)
Received: from [192.168.1.3] (host81-157-22-99.range81-157.btcentralplus.com.
	[81.157.22.99])
	by mx.google.com with ESMTPS id t7sm4339116wiy.2.2013.02.07.13.38.41
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 07 Feb 2013 13:38:42 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 07 Feb 2013 21:38:38 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <CD39CF5E.5A732%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
Thread-Index: Ac4Fe3001asj4U7QzEaAExlPcc+yrg==
In-Reply-To: <1360272591.22622.33.camel@hastur.hellion.org.uk>
Mime-version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/02/2013 21:29, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> On Thu, 2013-02-07 at 20:38 +0000, Keir Fraser wrote:
>> On 07/02/2013 20:20, "Ian Campbell" <ian.campbell@citrix.com> wrote:
>> 
>>>> @@ -840,10 +839,8 @@ void __init __start_xen(unsigned long mb
>>>>               * data until after we have switched to the relocated
>>>> pagetables!
>>>>               */
>>>>              barrier();
>>>> -            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START,
>>>> 1);
>>>> -
>>>> -            /* Poison low 1MB to detect stray pointers to physical 0-1MB.
>>>> */
>>>> -            memset(dst, 0x55, 1U << 20);
>>> 
>>> Is this poisoning not still desirable?
>> 
>> If we don't copy that low 1MB I don't see any reason to poison it at the
>> destination.
> 
> The poisoning was to protect against stray pointers out of the low 1MB
> region? I assumed it was against pointers into it...

I mean any stray pointers into that region are only going to see garbage at
the relocated highmem address anyway, as contents of 0-1MB are no longer
being copied. So deliberate poisoning seems even more paranoid than it
already was (it was already really quite paranoid).

 -- 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 Feb 07 21:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21:48: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 1U3ZKF-0003FL-2V; Thu, 07 Feb 2013 21:48: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 1U3ZKD-0003FG-TD
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 21:48:09 +0000
Received: from [85.158.143.35:20400] by server-3.bemta-4.messagelabs.com id
	E3/C6-08920-91124115; Thu, 07 Feb 2013 21:48:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360273686!14229158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7727 invoked from network); 7 Feb 2013 21:48:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 21:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6390440"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 21:48:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 16:48:05 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3ZK9-0004UY-0w;
	Thu, 07 Feb 2013 21:48:05 +0000
Message-ID: <1360273535.22622.35.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Thu, 7 Feb 2013 22:45:35 +0100
In-Reply-To: <CD39CF5E.5A732%keir@xen.org>
References: <CD39CF5E.5A732%keir@xen.org>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 21:38 +0000, Keir Fraser wrote:

> > The poisoning was to protect against stray pointers out of the low 1MB
> > region? I assumed it was against pointers into it...
> 
> I mean any stray pointers into that region are only going to see garbage at
> the relocated highmem address anyway, as contents of 0-1MB are no longer
> being copied. So deliberate poisoning seems even more paranoid than it
> already was (it was already really quite paranoid).

Right, I assumed the idea was that you could recognise the 0x55...55 as
being something more specific than random garbage. It is indeed quite
paranoid ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 21:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 21:48: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 1U3ZKF-0003FL-2V; Thu, 07 Feb 2013 21:48: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 1U3ZKD-0003FG-TD
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 21:48:09 +0000
Received: from [85.158.143.35:20400] by server-3.bemta-4.messagelabs.com id
	E3/C6-08920-91124115; Thu, 07 Feb 2013 21:48:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360273686!14229158!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDIxOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7727 invoked from network); 7 Feb 2013 21:48:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Feb 2013 21:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; 
   d="scan'208";a="6390440"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	07 Feb 2013 21:48:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 7 Feb 2013 16:48:05 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3ZK9-0004UY-0w;
	Thu, 07 Feb 2013 21:48:05 +0000
Message-ID: <1360273535.22622.35.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Thu, 7 Feb 2013 22:45:35 +0100
In-Reply-To: <CD39CF5E.5A732%keir@xen.org>
References: <CD39CF5E.5A732%keir@xen.org>
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 21:38 +0000, Keir Fraser wrote:

> > The poisoning was to protect against stray pointers out of the low 1MB
> > region? I assumed it was against pointers into it...
> 
> I mean any stray pointers into that region are only going to see garbage at
> the relocated highmem address anyway, as contents of 0-1MB are no longer
> being copied. So deliberate poisoning seems even more paranoid than it
> already was (it was already really quite paranoid).

Right, I assumed the idea was that you could recognise the 0x55...55 as
being something more specific than random garbage. It is indeed quite
paranoid ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 07 23:21:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 23:21: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 1U3amK-0006t3-La; Thu, 07 Feb 2013 23:21:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1U3amI-0006rZ-Qj
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 23:21:15 +0000
Received: from [85.158.139.83:7281] by server-10.bemta-5.messagelabs.com id
	E7/A4-04697-AE634115; Thu, 07 Feb 2013 23:21:14 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360279272!28234496!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8249 invoked from network); 7 Feb 2013 23:21:13 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 23:21:13 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NKtZX021408;
	Thu, 7 Feb 2013 23:20:59 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NKpMS026076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 23:20:51 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r17NKpYO029626;
	Thu, 7 Feb 2013 23:20:51 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r17NKpII029622; Thu, 7 Feb 2013 23:20:51 GMT
Date: Thu, 7 Feb 2013 23:20:50 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CD39469B.4B817%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
References: <CD39469B.4B817%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1674372147-1360279251=:6708"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r17NKtZX021408
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-1674372147-1360279251=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 7 Feb 2013, Keir Fraser wrote:

> On 07/02/2013 09:57, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> Actually, I'm of the opposite opinion - it should be in other places
>> too that handles don't get needlessly defined by the public
>> headers. They should get defined only when there actually is a
>> use for them. Everything else can be defined where actually
>> consumed, as in this case: For one, a handle of a compat_*
>> type can't be defined in a public header anyway, as the compat
>> types don't get defined there. And then, as you say, the oddity
>> of this type makes it desirable to scope restrict it as much as
>> possible.
>>
>> Now, for the actual solution, I'd prefer the -Wno-... Option
>
> +1. It's not a compiler warning that I care about.
>
> -- Keir
>
>> suggested above, or as a second best choice generalizing the
>> solution suggested by Michael, applying the attribute in
>> DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
>> attaching it in to the use of the macro just happens to work,
>> but isn't guaranteed to in the future: Switching around the
>> order of the two lines of the expansion
>>
>> #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
>>     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>>     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>>
>> or adding a third (say, volatile) one would re-expose the
>> problem.
>>
>> Jan

I am attaching a patch that turns off this check.

 	Michael Young
--8323329-1674372147-1360279251=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.1.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.1.patch

Z2NjIDQuOCBnaXZlcyB0aGUgZm9sbG93aW5nIGVycm9yIHdoZW4gYnVpbGRp
bmcgeGVuL2NvbW1vbi9jb21wYXQvbWVtb3J5LmMNCg0KbWVtb3J5LmM6IElu
IGZ1bmN0aW9uICdjb21wYXRfbWVtb3J5X29wJzoNCi9idWlsZGRpci9idWls
ZC9CVUlMRC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2
L3hlbi5oOjM1OjMzOiBlcnJvcjogdHlwZWRlZiAnX19ndWVzdF9oYW5kbGVf
Y29uc3RfY29tcGF0X21lbW9yeV9leGNoYW5nZV90JyBsb2NhbGx5IGRlZmlu
ZWQgYnV0IG5vdCB1c2VkIFstV2Vycm9yPXVudXNlZC1sb2NhbC10eXBlZGVm
c10NCiAgICAgdHlwZWRlZiBzdHJ1Y3QgeyB0eXBlICpwOyB9IF9fZ3Vlc3Rf
aGFuZGxlXyAjIyBuYW1lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBeDQovYnVpbGRkaXIvYnVpbGQvQlVJTEQveGVuLTQuMi4xL3hlbi9p
bmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni94ZW4uaDo0Mzo1OiBub3RlOiBpbiBl
eHBhbnNpb24gb2YgbWFjcm8gJ19fX0RFRklORV9YRU5fR1VFU1RfSEFORExF
Jw0KICAgICBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShjb25zdF8jI25h
bWUsIGNvbnN0IHR5cGUpDQogICAgIF4NCi9idWlsZGRpci9idWlsZC9CVUlM
RC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L3hlbi5o
OjQ0OjQxOiBub3RlOiBpbiBleHBhbnNpb24gb2YgbWFjcm8gJ19fREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUnDQogI2RlZmluZSBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShuYW1lKSAgIF9fREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobmFt
ZSwgbmFtZSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXg0KbWVtb3J5LmM6MjYxOjEzOiBub3RlOiBpbiBleHBhbnNpb24g
b2YgbWFjcm8gJ0RFRklORV9YRU5fR1VFU1RfSEFORExFJw0KICAgICAgICAg
ICAgIERFRklORV9YRU5fR1VFU1RfSEFORExFKGNvbXBhdF9tZW1vcnlfZXhj
aGFuZ2VfdCk7DQogICAgICAgICAgICAgXg0KDQpUaGUgZXJyb3IgaXMgaGFy
bWxlc3MgaW4gdGhpcyBjYXNlIHNvIHR1cm4gdGhlIGNoZWNrIG9mZi4NCg0K
U2lnbmVkLW9mZi1ieTogTWljaGFlbCBZb3VuZyA8bS5hLnlvdW5nQGR1cmhh
bS5hYy51az4NCg0KLS0tIHhlbi00LjIuMS9Db25maWcubWsub3JpZwkyMDEz
LTAyLTA3IDIxOjExOjUxLjYwMzk3MDI1NSArMDAwMA0KKysrIHhlbi00LjIu
MS9Db25maWcubWsJMjAxMy0wMi0wNyAyMTo1MTo0NC45OTIwNDg3ODcgKzAw
MDANCkBAIC0xNTYsNyArMTU2LDcgQEANCiANCiBDRkxBR1MgKz0gLXN0ZD1n
bnU5OQ0KIA0KLUNGTEFHUyArPSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
DQorQ0ZMQUdTICs9IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVduby11
bnVzZWQtbG9jYWwtdHlwZWRlZnMNCiANCiAjIENsYW5nIGNvbXBsYWlucyBh
Ym91dCBtYWNyb3MgdGhhdCBleHBhbmQgdG8gJ2lmICggKCBmb28gPT0gYmFy
ICkgKSAuLi4nDQogIyBhbmQgaXMgb3Zlci16ZWFsb3VzIHdpdGggdGhlIHBy
aW50ZiBmb3JtYXQgbGludA0K

--8323329-1674372147-1360279251=:6708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1674372147-1360279251=:6708--


From xen-devel-bounces@lists.xen.org Thu Feb 07 23:21:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 23:21: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 1U3amK-0006t3-La; Thu, 07 Feb 2013 23:21:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1U3amI-0006rZ-Qj
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 23:21:15 +0000
Received: from [85.158.139.83:7281] by server-10.bemta-5.messagelabs.com id
	E7/A4-04697-AE634115; Thu, 07 Feb 2013 23:21:14 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360279272!28234496!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8249 invoked from network); 7 Feb 2013 23:21:13 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Feb 2013 23:21:13 -0000
Received: from smtphost4.dur.ac.uk (smtphost4.dur.ac.uk [129.234.252.4])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NKtZX021408;
	Thu, 7 Feb 2013 23:20:59 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost4.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NKpMS026076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 23:20:51 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r17NKpYO029626;
	Thu, 7 Feb 2013 23:20:51 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r17NKpII029622; Thu, 7 Feb 2013 23:20:51 GMT
Date: Thu, 7 Feb 2013 23:20:50 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CD39469B.4B817%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
References: <CD39469B.4B817%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1674372147-1360279251=:6708"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r17NKtZX021408
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-1674372147-1360279251=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 7 Feb 2013, Keir Fraser wrote:

> On 07/02/2013 09:57, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> Actually, I'm of the opposite opinion - it should be in other places
>> too that handles don't get needlessly defined by the public
>> headers. They should get defined only when there actually is a
>> use for them. Everything else can be defined where actually
>> consumed, as in this case: For one, a handle of a compat_*
>> type can't be defined in a public header anyway, as the compat
>> types don't get defined there. And then, as you say, the oddity
>> of this type makes it desirable to scope restrict it as much as
>> possible.
>>
>> Now, for the actual solution, I'd prefer the -Wno-... Option
>
> +1. It's not a compiler warning that I care about.
>
> -- Keir
>
>> suggested above, or as a second best choice generalizing the
>> solution suggested by Michael, applying the attribute in
>> DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
>> attaching it in to the use of the macro just happens to work,
>> but isn't guaranteed to in the future: Switching around the
>> order of the two lines of the expansion
>>
>> #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
>>     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>>     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>>
>> or adding a third (say, volatile) one would re-expose the
>> problem.
>>
>> Jan

I am attaching a patch that turns off this check.

 	Michael Young
--8323329-1674372147-1360279251=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.1.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.1.patch

Z2NjIDQuOCBnaXZlcyB0aGUgZm9sbG93aW5nIGVycm9yIHdoZW4gYnVpbGRp
bmcgeGVuL2NvbW1vbi9jb21wYXQvbWVtb3J5LmMNCg0KbWVtb3J5LmM6IElu
IGZ1bmN0aW9uICdjb21wYXRfbWVtb3J5X29wJzoNCi9idWlsZGRpci9idWls
ZC9CVUlMRC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2
L3hlbi5oOjM1OjMzOiBlcnJvcjogdHlwZWRlZiAnX19ndWVzdF9oYW5kbGVf
Y29uc3RfY29tcGF0X21lbW9yeV9leGNoYW5nZV90JyBsb2NhbGx5IGRlZmlu
ZWQgYnV0IG5vdCB1c2VkIFstV2Vycm9yPXVudXNlZC1sb2NhbC10eXBlZGVm
c10NCiAgICAgdHlwZWRlZiBzdHJ1Y3QgeyB0eXBlICpwOyB9IF9fZ3Vlc3Rf
aGFuZGxlXyAjIyBuYW1lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBeDQovYnVpbGRkaXIvYnVpbGQvQlVJTEQveGVuLTQuMi4xL3hlbi9p
bmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni94ZW4uaDo0Mzo1OiBub3RlOiBpbiBl
eHBhbnNpb24gb2YgbWFjcm8gJ19fX0RFRklORV9YRU5fR1VFU1RfSEFORExF
Jw0KICAgICBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShjb25zdF8jI25h
bWUsIGNvbnN0IHR5cGUpDQogICAgIF4NCi9idWlsZGRpci9idWlsZC9CVUlM
RC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L3hlbi5o
OjQ0OjQxOiBub3RlOiBpbiBleHBhbnNpb24gb2YgbWFjcm8gJ19fREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUnDQogI2RlZmluZSBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShuYW1lKSAgIF9fREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobmFt
ZSwgbmFtZSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXg0KbWVtb3J5LmM6MjYxOjEzOiBub3RlOiBpbiBleHBhbnNpb24g
b2YgbWFjcm8gJ0RFRklORV9YRU5fR1VFU1RfSEFORExFJw0KICAgICAgICAg
ICAgIERFRklORV9YRU5fR1VFU1RfSEFORExFKGNvbXBhdF9tZW1vcnlfZXhj
aGFuZ2VfdCk7DQogICAgICAgICAgICAgXg0KDQpUaGUgZXJyb3IgaXMgaGFy
bWxlc3MgaW4gdGhpcyBjYXNlIHNvIHR1cm4gdGhlIGNoZWNrIG9mZi4NCg0K
U2lnbmVkLW9mZi1ieTogTWljaGFlbCBZb3VuZyA8bS5hLnlvdW5nQGR1cmhh
bS5hYy51az4NCg0KLS0tIHhlbi00LjIuMS9Db25maWcubWsub3JpZwkyMDEz
LTAyLTA3IDIxOjExOjUxLjYwMzk3MDI1NSArMDAwMA0KKysrIHhlbi00LjIu
MS9Db25maWcubWsJMjAxMy0wMi0wNyAyMTo1MTo0NC45OTIwNDg3ODcgKzAw
MDANCkBAIC0xNTYsNyArMTU2LDcgQEANCiANCiBDRkxBR1MgKz0gLXN0ZD1n
bnU5OQ0KIA0KLUNGTEFHUyArPSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz
DQorQ0ZMQUdTICs9IC1XYWxsIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVduby11
bnVzZWQtbG9jYWwtdHlwZWRlZnMNCiANCiAjIENsYW5nIGNvbXBsYWlucyBh
Ym91dCBtYWNyb3MgdGhhdCBleHBhbmQgdG8gJ2lmICggKCBmb28gPT0gYmFy
ICkgKSAuLi4nDQogIyBhbmQgaXMgb3Zlci16ZWFsb3VzIHdpdGggdGhlIHBy
aW50ZiBmb3JtYXQgbGludA0K

--8323329-1674372147-1360279251=:6708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1674372147-1360279251=:6708--


From xen-devel-bounces@lists.xen.org Thu Feb 07 23:26:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 23: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 1U3aqi-00076z-CU; Thu, 07 Feb 2013 23:25:48 +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 1U3aqh-00076u-GB
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 23:25:47 +0000
Received: from [85.158.137.99:4759] by server-5.bemta-3.messagelabs.com id
	50/5B-04457-8F734115; Thu, 07 Feb 2013 23:25:44 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360279541!12672006!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11598 invoked from network); 7 Feb 2013 23:25:41 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 23:25:41 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NPUsO022170;
	Thu, 7 Feb 2013 23:25:34 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NPR51025906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 23:25:27 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r17NPR0o031190;
	Thu, 7 Feb 2013 23:25:27 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r17NPRW8031186; Thu, 7 Feb 2013 23:25:27 GMT
Date: Thu, 7 Feb 2013 23:25:26 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <511389AC02000078000BCC3A@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1302072321090.6708@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<511389AC02000078000BCC3A@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1416213049-1360279527=:6708"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r17NPUsO022170
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [Patch 2/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-1416213049-1360279527=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 7 Feb 2013, Jan Beulich wrote:

>>>> On 06.02.13 at 21:37, M A Young <m.a.young@durham.ac.uk> wrote:
>> @@ -264,7 +264,7 @@
>>                return -1;
>>        }
>>
>> -       memset(buf,0,sizeof(buf));
>> +       memset(buf,0,sizeof(*buf));
>
> While everything else looks right, this one for sure is wrong - buf
> is an array, and hence sizeof(*buf) would clear just the first array
> element.

Yes, I now agree it is wrong (I found the other example in that file and 
assumed this one was broken as well). I am attaching a patch that fixes 
the other cases.

 	Michael Young
--8323329-1416213049-1360279527=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.2.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.2.patch

Z2NjIDQuOCBpZGVudGlmaWVzIHNldmVyYWwgcGxhY2VzIHdoZXJlIGNvZGUg
b2YgdGhlIGZvcm0NCm1lbXNldCAoeCwgMCwgc2l6ZW9mKHgpKTsNCmlzIHVz
ZWQgaW5jb3JyZWN0bHksIG1lYW5pbmcgdGhhdCBsZXNzIG1lbW9yeSBpcyBz
ZXQgdG8gemVybyB0aGFuIHJlcXVpcmVkLg0KDQpTaWduZWQtb2ZmLWJ5OiBN
aWNoYWVsIFlvdW5nIDxtLmEueW91bmdAZHVyaGFtLmFjLnVrPg0KDQotLS0g
eGVuLTQuMi4xL3Rvb2xzL2xpYnhjL3hjX2RvbV9ib290LmMub3JpZwkyMDEy
LTEyLTE3IDE1OjAwOjQ4LjAwMDAwMDAwMCArMDAwMA0KKysrIHhlbi00LjIu
MS90b29scy9saWJ4Yy94Y19kb21fYm9vdC5jCTIwMTMtMDEtMjggMjI6MjE6
MTMuMjE1NzgyMzI5ICswMDAwDQpAQCAtMjY2LDcgKzI2Niw3IEBADQogICAg
ICAgICByZXR1cm4gcmM7DQogDQogICAgIC8qIGxldCB0aGUgdm0gcnVuICov
DQotICAgIG1lbXNldChjdHh0LCAwLCBzaXplb2YoY3R4dCkpOw0KKyAgICBt
ZW1zZXQoY3R4dCwgMCwgc2l6ZW9mKCpjdHh0KSk7DQogICAgIGlmICggKHJj
ID0gZG9tLT5hcmNoX2hvb2tzLT52Y3B1KGRvbSwgY3R4dCkpICE9IDAgKQ0K
ICAgICAgICAgcmV0dXJuIHJjOw0KICAgICB4Y19kb21fdW5tYXBfYWxsKGRv
bSk7DQotLS0geGVuLTQuMi4xL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy9tZDUu
Yy5vcmlnCTIwMTItMTItMTcgMTU6MDA6MTEuMDAwMDAwMDAwICswMDAwDQor
KysgeGVuLTQuMi4xL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy9tZDUuYwkyMDEz
LTAxLTI4IDIzOjQ5OjUxLjk0MDI4OTEyMyArMDAwMA0KQEAgLTE3NCw3ICsx
NzQsNyBAQA0KICAgICBNRDVUcmFuc2Zvcm0oY3R4LT5idWYsICh1aW50MzJf
dCAqKSBjdHgtPmluKTsNCiAgICAgYnl0ZVJldmVyc2UoKHVuc2lnbmVkIGNo
YXIgKikgY3R4LT5idWYsIDQpOw0KICAgICBtZW1jcHkoZGlnZXN0LCBjdHgt
PmJ1ZiwgMTYpOw0KLSAgICBtZW1zZXQoY3R4LCAwLCBzaXplb2YoY3R4KSk7
ICAgICAvKiBJbiBjYXNlIGl0J3Mgc2Vuc2l0aXZlICovDQorICAgIG1lbXNl
dChjdHgsIDAsIHNpemVvZigqY3R4KSk7ICAgICAvKiBJbiBjYXNlIGl0J3Mg
c2Vuc2l0aXZlICovDQogfQ0KIA0KIC8qIFRoZSBmb3VyIGNvcmUgZnVuY3Rp
b25zIC0gRjEgaXMgb3B0aW1pemVkIHNvbWV3aGF0ICovDQotLS0geGVuLTQu
Mi4xL3Rvb2xzL2xpYnhsL2xpYnhsX3FtcC5jLm9yaWcJMjAxMi0xMi0xNyAx
NTowMTowOS4wMDAwMDAwMDAgKzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMv
bGlieGwvbGlieGxfcW1wLmMJMjAxMy0wMS0yOSAyMToyODoyNy43NjM2NTAw
NzMgKzAwMDANCkBAIC0zNzcsNyArMzc3LDcgQEANCiAgICAgcmV0ID0gbGli
eGxfZmRfc2V0X2Nsb2V4ZWMocW1wLT5jdHgsIHFtcC0+cW1wX2ZkLCAxKTsN
CiAgICAgaWYgKHJldCkgcmV0dXJuIC0xOw0KIA0KLSAgICBtZW1zZXQoJnFt
cC0+YWRkciwgMCwgc2l6ZW9mICgmcW1wLT5hZGRyKSk7DQorICAgIG1lbXNl
dCgmcW1wLT5hZGRyLCAwLCBzaXplb2YgKHFtcC0+YWRkcikpOw0KICAgICBx
bXAtPmFkZHIuc3VuX2ZhbWlseSA9IEFGX1VOSVg7DQogICAgIHN0cm5jcHko
cW1wLT5hZGRyLnN1bl9wYXRoLCBxbXBfc29ja2V0X3BhdGgsDQogICAgICAg
ICAgICAgc2l6ZW9mIChxbXAtPmFkZHIuc3VuX3BhdGgpKTsNCi0tLSB4ZW4t
NC4yLjEvdG9vbHMveGVuc3RhdC9saWJ4ZW5zdGF0L3NyYy94ZW5zdGF0X2xp
bnV4LmMub3JpZwkyMDEyLTEyLTE3IDE1OjAxOjM1LjAwMDAwMDAwMCArMDAw
MA0KKysrIHhlbi00LjIuMS90b29scy94ZW5zdGF0L2xpYnhlbnN0YXQvc3Jj
L3hlbnN0YXRfbGludXguYwkyMDEzLTAxLTI5IDIxOjQzOjQ2LjA0NDE2OTk4
NyArMDAwMA0KQEAgLTExMyw3ICsxMTMsNyBAQA0KIA0KIAkvKiBJbml0aWFs
aXplIGFsbCB2YXJpYWJsZXMgY2FsbGVkIGhhcyBwYXNzZWQgYXMgbm9uLU5V
TEwgdG8gemVyb3MgKi8NCiAJaWYgKGlmYWNlICE9IE5VTEwpDQotCQltZW1z
ZXQoaWZhY2UsIDAsIHNpemVvZihpZmFjZSkpOw0KKwkJbWVtc2V0KGlmYWNl
LCAwLCBzaXplb2YoKmlmYWNlKSk7DQogCWlmIChyeEJ5dGVzICE9IE5VTEwp
DQogCQkqcnhCeXRlcyA9IDA7DQogCWlmIChyeFBhY2tldHMgIT0gTlVMTCkN
Ci0tLSB4ZW4tNC4yLjEvdG9vbHMvZGVidWdnZXIva2RkL2tkZC14ZW4uYy5v
cmlnCTIwMTItMTItMTcgMTU6MDA6MjIuMDAwMDAwMDAwICswMDAwDQorKysg
eGVuLTQuMi4xL3Rvb2xzL2RlYnVnZ2VyL2tkZC9rZGQteGVuLmMJMjAxMy0w
MS0yOSAyMTo0NToxMi42NTIwODcyMzkgKzAwMDANCkBAIC0zMzMsNyArMzMz
LDcgQEANCiAgICAgaWYgKCFjcHUpIA0KICAgICAgICAgcmV0dXJuIC0xOw0K
IA0KLSAgICBtZW1zZXQociwgMCwgc2l6ZW9mKHIpKTsNCisgICAgbWVtc2V0
KHIsIDAsIHNpemVvZigqcikpOw0KICAgICANCiAgICAgaWYgKHc2NCkNCiAg
ICAgICAgIGtkZF9nZXRfcmVnc194ODZfNjQoY3B1LCAmci0+cjY0KTsNCi0t
LSB4ZW4tNC4yLjEvdG9vbHMvcHl0aG9uL3hlbi9sb3dsZXZlbC9uZXRsaW5r
L2xpYm5ldGxpbmsuYy5vcmlnCTIwMTItMTItMTcgMTU6MDE6MjQuMDAwMDAw
MDAwICswMDAwDQorKysgeGVuLTQuMi4xL3Rvb2xzL3B5dGhvbi94ZW4vbG93
bGV2ZWwvbmV0bGluay9saWJuZXRsaW5rLmMJMjAxMy0wMS0yOSAyMTo0Nzo1
OS41MjQwMDEwNTMgKzAwMDANCkBAIC0zNyw3ICszNyw3IEBADQogICAgICAg
IGludCBzbmRidWYgPSAzMjc2ODsNCiAgICAgICAgaW50IHJjdmJ1ZiA9IDMy
NzY4Ow0KIA0KLSAgICAgICBtZW1zZXQocnRoLCAwLCBzaXplb2YocnRoKSk7
DQorICAgICAgIG1lbXNldChydGgsIDAsIHNpemVvZigqcnRoKSk7DQogDQog
ICAgICAgIHJ0aC0+ZmQgPSBzb2NrZXQoQUZfTkVUTElOSywgU09DS19SQVcs
IHByb3RvY29sKTsNCiAgICAgICAgaWYgKHJ0aC0+ZmQgPCAwKSB7DQo=

--8323329-1416213049-1360279527=:6708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1416213049-1360279527=:6708--


From xen-devel-bounces@lists.xen.org Thu Feb 07 23:26:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 07 Feb 2013 23: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 1U3aqi-00076z-CU; Thu, 07 Feb 2013 23:25:48 +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 1U3aqh-00076u-GB
	for xen-devel@lists.xen.org; Thu, 07 Feb 2013 23:25:47 +0000
Received: from [85.158.137.99:4759] by server-5.bemta-3.messagelabs.com id
	50/5B-04457-8F734115; Thu, 07 Feb 2013 23:25:44 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360279541!12672006!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA5NDQ1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11598 invoked from network); 7 Feb 2013 23:25:41 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Feb 2013 23:25:41 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NPUsO022170;
	Thu, 7 Feb 2013 23:25:34 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r17NPR51025906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 7 Feb 2013 23:25:27 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r17NPR0o031190;
	Thu, 7 Feb 2013 23:25:27 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r17NPRW8031186; Thu, 7 Feb 2013 23:25:27 GMT
Date: Thu, 7 Feb 2013 23:25:26 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <511389AC02000078000BCC3A@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1302072321090.6708@procyon.dur.ac.uk>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<511389AC02000078000BCC3A@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1416213049-1360279527=:6708"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r17NPUsO022170
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [Patch 2/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-1416213049-1360279527=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 7 Feb 2013, Jan Beulich wrote:

>>>> On 06.02.13 at 21:37, M A Young <m.a.young@durham.ac.uk> wrote:
>> @@ -264,7 +264,7 @@
>>                return -1;
>>        }
>>
>> -       memset(buf,0,sizeof(buf));
>> +       memset(buf,0,sizeof(*buf));
>
> While everything else looks right, this one for sure is wrong - buf
> is an array, and hence sizeof(*buf) would clear just the first array
> element.

Yes, I now agree it is wrong (I found the other example in that file and 
assumed this one was broken as well). I am attaching a patch that fixes 
the other cases.

 	Michael Young
--8323329-1416213049-1360279527=:6708
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.2.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.2.patch

Z2NjIDQuOCBpZGVudGlmaWVzIHNldmVyYWwgcGxhY2VzIHdoZXJlIGNvZGUg
b2YgdGhlIGZvcm0NCm1lbXNldCAoeCwgMCwgc2l6ZW9mKHgpKTsNCmlzIHVz
ZWQgaW5jb3JyZWN0bHksIG1lYW5pbmcgdGhhdCBsZXNzIG1lbW9yeSBpcyBz
ZXQgdG8gemVybyB0aGFuIHJlcXVpcmVkLg0KDQpTaWduZWQtb2ZmLWJ5OiBN
aWNoYWVsIFlvdW5nIDxtLmEueW91bmdAZHVyaGFtLmFjLnVrPg0KDQotLS0g
eGVuLTQuMi4xL3Rvb2xzL2xpYnhjL3hjX2RvbV9ib290LmMub3JpZwkyMDEy
LTEyLTE3IDE1OjAwOjQ4LjAwMDAwMDAwMCArMDAwMA0KKysrIHhlbi00LjIu
MS90b29scy9saWJ4Yy94Y19kb21fYm9vdC5jCTIwMTMtMDEtMjggMjI6MjE6
MTMuMjE1NzgyMzI5ICswMDAwDQpAQCAtMjY2LDcgKzI2Niw3IEBADQogICAg
ICAgICByZXR1cm4gcmM7DQogDQogICAgIC8qIGxldCB0aGUgdm0gcnVuICov
DQotICAgIG1lbXNldChjdHh0LCAwLCBzaXplb2YoY3R4dCkpOw0KKyAgICBt
ZW1zZXQoY3R4dCwgMCwgc2l6ZW9mKCpjdHh0KSk7DQogICAgIGlmICggKHJj
ID0gZG9tLT5hcmNoX2hvb2tzLT52Y3B1KGRvbSwgY3R4dCkpICE9IDAgKQ0K
ICAgICAgICAgcmV0dXJuIHJjOw0KICAgICB4Y19kb21fdW5tYXBfYWxsKGRv
bSk7DQotLS0geGVuLTQuMi4xL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy9tZDUu
Yy5vcmlnCTIwMTItMTItMTcgMTU6MDA6MTEuMDAwMDAwMDAwICswMDAwDQor
KysgeGVuLTQuMi4xL3Rvb2xzL2Jsa3RhcDIvZHJpdmVycy9tZDUuYwkyMDEz
LTAxLTI4IDIzOjQ5OjUxLjk0MDI4OTEyMyArMDAwMA0KQEAgLTE3NCw3ICsx
NzQsNyBAQA0KICAgICBNRDVUcmFuc2Zvcm0oY3R4LT5idWYsICh1aW50MzJf
dCAqKSBjdHgtPmluKTsNCiAgICAgYnl0ZVJldmVyc2UoKHVuc2lnbmVkIGNo
YXIgKikgY3R4LT5idWYsIDQpOw0KICAgICBtZW1jcHkoZGlnZXN0LCBjdHgt
PmJ1ZiwgMTYpOw0KLSAgICBtZW1zZXQoY3R4LCAwLCBzaXplb2YoY3R4KSk7
ICAgICAvKiBJbiBjYXNlIGl0J3Mgc2Vuc2l0aXZlICovDQorICAgIG1lbXNl
dChjdHgsIDAsIHNpemVvZigqY3R4KSk7ICAgICAvKiBJbiBjYXNlIGl0J3Mg
c2Vuc2l0aXZlICovDQogfQ0KIA0KIC8qIFRoZSBmb3VyIGNvcmUgZnVuY3Rp
b25zIC0gRjEgaXMgb3B0aW1pemVkIHNvbWV3aGF0ICovDQotLS0geGVuLTQu
Mi4xL3Rvb2xzL2xpYnhsL2xpYnhsX3FtcC5jLm9yaWcJMjAxMi0xMi0xNyAx
NTowMTowOS4wMDAwMDAwMDAgKzAwMDANCisrKyB4ZW4tNC4yLjEvdG9vbHMv
bGlieGwvbGlieGxfcW1wLmMJMjAxMy0wMS0yOSAyMToyODoyNy43NjM2NTAw
NzMgKzAwMDANCkBAIC0zNzcsNyArMzc3LDcgQEANCiAgICAgcmV0ID0gbGli
eGxfZmRfc2V0X2Nsb2V4ZWMocW1wLT5jdHgsIHFtcC0+cW1wX2ZkLCAxKTsN
CiAgICAgaWYgKHJldCkgcmV0dXJuIC0xOw0KIA0KLSAgICBtZW1zZXQoJnFt
cC0+YWRkciwgMCwgc2l6ZW9mICgmcW1wLT5hZGRyKSk7DQorICAgIG1lbXNl
dCgmcW1wLT5hZGRyLCAwLCBzaXplb2YgKHFtcC0+YWRkcikpOw0KICAgICBx
bXAtPmFkZHIuc3VuX2ZhbWlseSA9IEFGX1VOSVg7DQogICAgIHN0cm5jcHko
cW1wLT5hZGRyLnN1bl9wYXRoLCBxbXBfc29ja2V0X3BhdGgsDQogICAgICAg
ICAgICAgc2l6ZW9mIChxbXAtPmFkZHIuc3VuX3BhdGgpKTsNCi0tLSB4ZW4t
NC4yLjEvdG9vbHMveGVuc3RhdC9saWJ4ZW5zdGF0L3NyYy94ZW5zdGF0X2xp
bnV4LmMub3JpZwkyMDEyLTEyLTE3IDE1OjAxOjM1LjAwMDAwMDAwMCArMDAw
MA0KKysrIHhlbi00LjIuMS90b29scy94ZW5zdGF0L2xpYnhlbnN0YXQvc3Jj
L3hlbnN0YXRfbGludXguYwkyMDEzLTAxLTI5IDIxOjQzOjQ2LjA0NDE2OTk4
NyArMDAwMA0KQEAgLTExMyw3ICsxMTMsNyBAQA0KIA0KIAkvKiBJbml0aWFs
aXplIGFsbCB2YXJpYWJsZXMgY2FsbGVkIGhhcyBwYXNzZWQgYXMgbm9uLU5V
TEwgdG8gemVyb3MgKi8NCiAJaWYgKGlmYWNlICE9IE5VTEwpDQotCQltZW1z
ZXQoaWZhY2UsIDAsIHNpemVvZihpZmFjZSkpOw0KKwkJbWVtc2V0KGlmYWNl
LCAwLCBzaXplb2YoKmlmYWNlKSk7DQogCWlmIChyeEJ5dGVzICE9IE5VTEwp
DQogCQkqcnhCeXRlcyA9IDA7DQogCWlmIChyeFBhY2tldHMgIT0gTlVMTCkN
Ci0tLSB4ZW4tNC4yLjEvdG9vbHMvZGVidWdnZXIva2RkL2tkZC14ZW4uYy5v
cmlnCTIwMTItMTItMTcgMTU6MDA6MjIuMDAwMDAwMDAwICswMDAwDQorKysg
eGVuLTQuMi4xL3Rvb2xzL2RlYnVnZ2VyL2tkZC9rZGQteGVuLmMJMjAxMy0w
MS0yOSAyMTo0NToxMi42NTIwODcyMzkgKzAwMDANCkBAIC0zMzMsNyArMzMz
LDcgQEANCiAgICAgaWYgKCFjcHUpIA0KICAgICAgICAgcmV0dXJuIC0xOw0K
IA0KLSAgICBtZW1zZXQociwgMCwgc2l6ZW9mKHIpKTsNCisgICAgbWVtc2V0
KHIsIDAsIHNpemVvZigqcikpOw0KICAgICANCiAgICAgaWYgKHc2NCkNCiAg
ICAgICAgIGtkZF9nZXRfcmVnc194ODZfNjQoY3B1LCAmci0+cjY0KTsNCi0t
LSB4ZW4tNC4yLjEvdG9vbHMvcHl0aG9uL3hlbi9sb3dsZXZlbC9uZXRsaW5r
L2xpYm5ldGxpbmsuYy5vcmlnCTIwMTItMTItMTcgMTU6MDE6MjQuMDAwMDAw
MDAwICswMDAwDQorKysgeGVuLTQuMi4xL3Rvb2xzL3B5dGhvbi94ZW4vbG93
bGV2ZWwvbmV0bGluay9saWJuZXRsaW5rLmMJMjAxMy0wMS0yOSAyMTo0Nzo1
OS41MjQwMDEwNTMgKzAwMDANCkBAIC0zNyw3ICszNyw3IEBADQogICAgICAg
IGludCBzbmRidWYgPSAzMjc2ODsNCiAgICAgICAgaW50IHJjdmJ1ZiA9IDMy
NzY4Ow0KIA0KLSAgICAgICBtZW1zZXQocnRoLCAwLCBzaXplb2YocnRoKSk7
DQorICAgICAgIG1lbXNldChydGgsIDAsIHNpemVvZigqcnRoKSk7DQogDQog
ICAgICAgIHJ0aC0+ZmQgPSBzb2NrZXQoQUZfTkVUTElOSywgU09DS19SQVcs
IHByb3RvY29sKTsNCiAgICAgICAgaWYgKHJ0aC0+ZmQgPCAwKSB7DQo=

--8323329-1416213049-1360279527=:6708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1416213049-1360279527=:6708--


From xen-devel-bounces@lists.xen.org Fri Feb 08 00:36:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 00: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 1U3bwl-0001Ei-02; Fri, 08 Feb 2013 00:36: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 1U3bwj-0001Ed-HC
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 00:36:05 +0000
Received: from [85.158.139.211:62051] by server-8.bemta-5.messagelabs.com id
	EC/89-19075-47844115; Fri, 08 Feb 2013 00:36:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360283763!21447276!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22056 invoked from network); 8 Feb 2013 00:36:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 00:36:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; 
   d="scan'208";a="1262086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 00:36: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.297.1; Fri, 8 Feb 2013 00:36:03 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3bwh-0007ol-Ba;
	Fri, 08 Feb 2013 00:36:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3bwh-0002ST-1z;
	Fri, 08 Feb 2013 00:36:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15444-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 00:36:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 15444: 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 15444 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15444/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 15426
 test-amd64-i386-xl-qemut-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 15426

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15426
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 15426

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  130446135528
baseline version:
 xen                  e5ed73d172eb

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.

------------------------------------------------------------
changeset:   23453:130446135528
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:26:37 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23452:47c7b8531923
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:26:29 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26521:2c0fd406f02c
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23451:e5ed73d172eb
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:36:34 2013 +0100
    
    AMD,IOMMU: Make per-device interrupt remapping table default
    
    Using global interrupt remapping table may be insecure, as
    described by XSA-36. This patch makes per-device mode default.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Moved warning in amd_iov_detect() to location covering all cases.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26519:1af531e7bc2f
    xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
    
    
========================================
commit 7a3a2aaa8fd1049fa0f033c5113e165900c84758
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 00:36:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 00: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 1U3bwl-0001Ei-02; Fri, 08 Feb 2013 00:36: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 1U3bwj-0001Ed-HC
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 00:36:05 +0000
Received: from [85.158.139.211:62051] by server-8.bemta-5.messagelabs.com id
	EC/89-19075-47844115; Fri, 08 Feb 2013 00:36:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360283763!21447276!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22056 invoked from network); 8 Feb 2013 00:36:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 00:36:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; 
   d="scan'208";a="1262086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 00:36: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.297.1; Fri, 8 Feb 2013 00:36:03 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3bwh-0007ol-Ba;
	Fri, 08 Feb 2013 00:36:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3bwh-0002ST-1z;
	Fri, 08 Feb 2013 00:36:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15444-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 00:36:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 15444: 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 15444 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15444/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 15426
 test-amd64-i386-xl-qemut-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 15426

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15426
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 15426

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  130446135528
baseline version:
 xen                  e5ed73d172eb

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.

------------------------------------------------------------
changeset:   23453:130446135528
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:26:37 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23452:47c7b8531923
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:26:29 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26521:2c0fd406f02c
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23451:e5ed73d172eb
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:36:34 2013 +0100
    
    AMD,IOMMU: Make per-device interrupt remapping table default
    
    Using global interrupt remapping table may be insecure, as
    described by XSA-36. This patch makes per-device mode default.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Moved warning in amd_iov_detect() to location covering all cases.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26519:1af531e7bc2f
    xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
    
    
========================================
commit 7a3a2aaa8fd1049fa0f033c5113e165900c84758
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 04:31:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 04: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 1U3fcH-00045P-09; Fri, 08 Feb 2013 04:31:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U3fcF-00044h-Hu
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 04:31:11 +0000
Received: from [85.158.143.99:7166] by server-1.bemta-4.messagelabs.com id
	D5/50-08839-E8F74115; Fri, 08 Feb 2013 04:31:10 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360297869!30459718!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5746 invoked from network); 8 Feb 2013 04:31:09 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-13.tower-216.messagelabs.com with SMTP;
	8 Feb 2013 04:31:09 -0000
Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id BFAEE580557;
	Thu,  7 Feb 2013 20:31:11 -0800 (PST)
Date: Thu, 07 Feb 2013 23:31:07 -0500 (EST)
Message-Id: <20130207.233107.1094455509765442729.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 0/4] XSA-39 CVE-2013-021[67]: Linux
 netback DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Date: Thu, 7 Feb 2013 09:41:18 +0000

> The Xen netback implementation contains a couple of flaws which can
> allow a guest to cause a DoS in the backend domain, potentially
> affecting other domains in the system.
> 
> CVE-2013-0216 is a failure to sanity check the ring producer/consumer
> pointers which can allow a guest to cause netback to loop for an
> extended period preventing other work from occurring.
> 
> CVE-2013-0217 is a memory leak on an error path which is guest
> triggerable.
> 
> The following series contains the fixes for these issues, as previously
> included in Xen Security Advisory 39:
> http://lists.xen.org/archives/html/xen-announce/2013-02/msg00001.html
> 
> Changes in v2:
>  - Typo and block comment format fixes 
>  - Added stable Cc

Applied, please don't add stable CC:'s to networking patches, instead
ask me to queue it up to my -stable todo pile instead.

I don't like it when patches instantly be submitted to -stable when
they hit Linus's tree, I'd rather it soak upstream for a week or two
instead.  That's why I do it this way.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 04:31:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 04: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 1U3fcH-00045P-09; Fri, 08 Feb 2013 04:31:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U3fcF-00044h-Hu
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 04:31:11 +0000
Received: from [85.158.143.99:7166] by server-1.bemta-4.messagelabs.com id
	D5/50-08839-E8F74115; Fri, 08 Feb 2013 04:31:10 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360297869!30459718!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5746 invoked from network); 8 Feb 2013 04:31:09 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-13.tower-216.messagelabs.com with SMTP;
	8 Feb 2013 04:31:09 -0000
Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id BFAEE580557;
	Thu,  7 Feb 2013 20:31:11 -0800 (PST)
Date: Thu, 07 Feb 2013 23:31:07 -0500 (EST)
Message-Id: <20130207.233107.1094455509765442729.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 0/4] XSA-39 CVE-2013-021[67]: Linux
 netback DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Date: Thu, 7 Feb 2013 09:41:18 +0000

> The Xen netback implementation contains a couple of flaws which can
> allow a guest to cause a DoS in the backend domain, potentially
> affecting other domains in the system.
> 
> CVE-2013-0216 is a failure to sanity check the ring producer/consumer
> pointers which can allow a guest to cause netback to loop for an
> extended period preventing other work from occurring.
> 
> CVE-2013-0217 is a memory leak on an error path which is guest
> triggerable.
> 
> The following series contains the fixes for these issues, as previously
> included in Xen Security Advisory 39:
> http://lists.xen.org/archives/html/xen-announce/2013-02/msg00001.html
> 
> Changes in v2:
>  - Typo and block comment format fixes 
>  - Added stable Cc

Applied, please don't add stable CC:'s to networking patches, instead
ask me to queue it up to my -stable todo pile instead.

I don't like it when patches instantly be submitted to -stable when
they hit Linus's tree, I'd rather it soak upstream for a week or two
instead.  That's why I do it this way.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 05:13:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 05:13: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 1U3gGk-0005e4-D1; Fri, 08 Feb 2013 05:13: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 1U3gGi-0005dz-Ad
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 05:13:00 +0000
Received: from [85.158.143.99:18372] by server-1.bemta-4.messagelabs.com id
	C6/BD-08839-B5984115; Fri, 08 Feb 2013 05:12:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360300378!27834651!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6163 invoked from network); 8 Feb 2013 05:12:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 05:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; 
   d="scan'208";a="1265679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 05:12: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.297.1; Fri, 8 Feb 2013 05:12:57 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3gGf-0000kb-CU;
	Fri, 08 Feb 2013 05:12:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3gGe-00007K-SH;
	Fri, 08 Feb 2013 05:12:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15445-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 05:12:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15445: 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 15445 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15445/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv            14 guest-localmigrate/x10    fail REGR. vs. 15434
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 15434
 test-amd64-i386-qemut-win    12 guest-localmigrate/x10    fail REGR. vs. 15434
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15434
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 15434
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15434
 test-i386-i386-qemut-win      7 windows-install           fail REGR. vs. 15434
 test-i386-i386-win           11 guest-localmigrate.2      fail REGR. vs. 15434
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15434
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15434
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15434
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15434

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15434

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-xl-qemut-win  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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass

version targeted for testing:
 xen                  c713f1f7d3c1
baseline version:
 xen                  b8a523d9f14c

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.

------------------------------------------------------------
changeset:   25979:c713f1f7d3c1
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:24:08 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25978:b150d8787a05
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:23:56 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26521:2c0fd406f02c
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25977:b8a523d9f14c
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:30:59 2013 +0100
    
    AMD,IOMMU: Make per-device interrupt remapping table default
    
    Using global interrupt remapping table may be insecure, as
    described by XSA-36. This patch makes per-device mode default.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Moved warning in amd_iov_detect() to location covering all cases.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26519:1af531e7bc2f
    xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 05:13:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 05:13: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 1U3gGk-0005e4-D1; Fri, 08 Feb 2013 05:13: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 1U3gGi-0005dz-Ad
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 05:13:00 +0000
Received: from [85.158.143.99:18372] by server-1.bemta-4.messagelabs.com id
	C6/BD-08839-B5984115; Fri, 08 Feb 2013 05:12:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360300378!27834651!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6163 invoked from network); 8 Feb 2013 05:12:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 05:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; 
   d="scan'208";a="1265679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 05:12: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.297.1; Fri, 8 Feb 2013 05:12:57 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3gGf-0000kb-CU;
	Fri, 08 Feb 2013 05:12:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3gGe-00007K-SH;
	Fri, 08 Feb 2013 05:12:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15445-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 05:12:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15445: 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 15445 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15445/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv            14 guest-localmigrate/x10    fail REGR. vs. 15434
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 15434
 test-amd64-i386-qemut-win    12 guest-localmigrate/x10    fail REGR. vs. 15434
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15434
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 15434
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15434
 test-i386-i386-qemut-win      7 windows-install           fail REGR. vs. 15434
 test-i386-i386-win           11 guest-localmigrate.2      fail REGR. vs. 15434
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15434
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15434
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15434
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15434

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15434

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-xl-qemut-win  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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass

version targeted for testing:
 xen                  c713f1f7d3c1
baseline version:
 xen                  b8a523d9f14c

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.

------------------------------------------------------------
changeset:   25979:c713f1f7d3c1
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:24:08 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25978:b150d8787a05
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:23:56 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26521:2c0fd406f02c
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25977:b8a523d9f14c
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 05 15:30:59 2013 +0100
    
    AMD,IOMMU: Make per-device interrupt remapping table default
    
    Using global interrupt remapping table may be insecure, as
    described by XSA-36. This patch makes per-device mode default.
    
    This is XSA-36 / CVE-2013-0153.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    
    Moved warning in amd_iov_detect() to location covering all cases.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26519:1af531e7bc2f
    xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:33:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:33: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 1U3iSZ-0001d3-Bn; Fri, 08 Feb 2013 07:33:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kristian@hagsted.dk>) id 1U3iSX-0001cy-DD
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 07:33:21 +0000
Received: from [193.109.254.147:63122] by server-4.bemta-14.messagelabs.com id
	BE/1D-20719-04AA4115; Fri, 08 Feb 2013 07:33:20 +0000
X-Env-Sender: kristian@hagsted.dk
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360308799!1605058!1
X-Originating-IP: [80.160.77.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMTYwLjc3LjExNCA9PiAxMzk5MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28799 invoked from network); 8 Feb 2013 07:33:19 -0000
Received: from pasmtpa.tele.dk (HELO pasmtpA.tele.dk) (80.160.77.114)
	by server-7.tower-27.messagelabs.com with SMTP;
	8 Feb 2013 07:33:19 -0000
Received: from hagsted.dk (2-108-99-186-static.dk.customer.tdc.net
	[2.108.99.186])
	by pasmtpA.tele.dk (Postfix) with ESMTP id CAAA9800320;
	Fri,  8 Feb 2013 08:33:14 +0100 (CET)
Received: from HAGSTED-BSERVER.hagsted.dk ([fe80::91b7:737e:e057:7c8b]) by
	hagsted-bserver.hagsted.dk ([fe80::91b7:737e:e057:7c8b%10]) with mapi
	id 14.02.0328.009; Fri, 8 Feb 2013 08:33:00 +0100
From: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
Thread-Index: AQHOBS6+hxHSkkT9D0irHGI4vPjQCZhuVtvggAAuRwCAAQ1MgA==
Date: Fri, 8 Feb 2013 07:32:59 +0000
Message-ID: <19EF9FEB5AF86243A3F18E5CE75971640C94B29A@hagsted-bserver.hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
	<5113D620.702@tiscali.it>
In-Reply-To: <5113D620.702@tiscali.it>
Accept-Language: da-DK, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.38.90.11]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
> Sent: 7. februar 2013 17:28
> To: Kristian Hagsted Rasmussen
> Cc: xen-devel; Ian Campbell; Stefano Stabellini
> Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
> 
> Il 07/02/2013 13:48, Kristian Hagsted Rasmussen ha scritto:
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> >> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
> >> Sent: 7. februar 2013 13:28
> >> To: xen-devel; Ian Campbell; Stefano Stabellini
> >> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
> >>
> >> I haven't seen mail about eufi support on hvm domUs (ovmf) for a long
> time.
> >> I'm interested in trying it with xen-unstable.
> >> Someone can tell me if there is something to add to have it working
> and/or
> >> ovmf git need to be updated?
> > I have been running Windows 8 and server 2012 HVM on OVMF for some
> time. I used the latest OVMF build from the edk2 source with xen-unstable.
> It works fine, except that the vnc connection doesn't update the picture, so I
> have to open and close the vnc window for updating the picture, until I have
> enabled remote desktop in windows. I also tried to pass through some USB
> ports with success, the passing through my intel hd 4000 gfx, does not work
> even in secondary mode.
> >
> > /Kristian Hagsted Rasmussen
> 
> Thanks for reply.
> I built successfull ovmf with xen-unstable with this changes:
> ./configure --enable-ovmf
> vi Config.mk
> OVMF_UPSTREAM_URL ?= git://github.com/tianocore/edk2.git
> OVMF_UPSTREAM_REVISION ?= master
> # Added patch for support gcc4.7 and rispective change in
> tools/firmware/ovmf-makefile
> 
> After that I tested it adding bios="ovmf" on domU's xl cfg.
> The domU starts but performance is very poor (similar to qemu without
> xen or kvm or worse).
> Tried with Windows 7 and Fedora 18: they start loading but never reach a
> complete boot (even after about 10 minutes).

When you say that they newer reach a complete boot, have you then tried to close your vnc and reconnect?

> 
> Are there any others specific task to do?
> 
> Thanks for any reply.
> 
> >> Thanks for any reply.
> >>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:33:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:33: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 1U3iSZ-0001d3-Bn; Fri, 08 Feb 2013 07:33:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kristian@hagsted.dk>) id 1U3iSX-0001cy-DD
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 07:33:21 +0000
Received: from [193.109.254.147:63122] by server-4.bemta-14.messagelabs.com id
	BE/1D-20719-04AA4115; Fri, 08 Feb 2013 07:33:20 +0000
X-Env-Sender: kristian@hagsted.dk
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360308799!1605058!1
X-Originating-IP: [80.160.77.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuMTYwLjc3LjExNCA9PiAxMzk5MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28799 invoked from network); 8 Feb 2013 07:33:19 -0000
Received: from pasmtpa.tele.dk (HELO pasmtpA.tele.dk) (80.160.77.114)
	by server-7.tower-27.messagelabs.com with SMTP;
	8 Feb 2013 07:33:19 -0000
Received: from hagsted.dk (2-108-99-186-static.dk.customer.tdc.net
	[2.108.99.186])
	by pasmtpA.tele.dk (Postfix) with ESMTP id CAAA9800320;
	Fri,  8 Feb 2013 08:33:14 +0100 (CET)
Received: from HAGSTED-BSERVER.hagsted.dk ([fe80::91b7:737e:e057:7c8b]) by
	hagsted-bserver.hagsted.dk ([fe80::91b7:737e:e057:7c8b%10]) with mapi
	id 14.02.0328.009; Fri, 8 Feb 2013 08:33:00 +0100
From: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
Thread-Index: AQHOBS6+hxHSkkT9D0irHGI4vPjQCZhuVtvggAAuRwCAAQ1MgA==
Date: Fri, 8 Feb 2013 07:32:59 +0000
Message-ID: <19EF9FEB5AF86243A3F18E5CE75971640C94B29A@hagsted-bserver.hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
	<5113D620.702@tiscali.it>
In-Reply-To: <5113D620.702@tiscali.it>
Accept-Language: da-DK, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.38.90.11]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
> Sent: 7. februar 2013 17:28
> To: Kristian Hagsted Rasmussen
> Cc: xen-devel; Ian Campbell; Stefano Stabellini
> Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
> 
> Il 07/02/2013 13:48, Kristian Hagsted Rasmussen ha scritto:
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> >> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
> >> Sent: 7. februar 2013 13:28
> >> To: xen-devel; Ian Campbell; Stefano Stabellini
> >> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
> >>
> >> I haven't seen mail about eufi support on hvm domUs (ovmf) for a long
> time.
> >> I'm interested in trying it with xen-unstable.
> >> Someone can tell me if there is something to add to have it working
> and/or
> >> ovmf git need to be updated?
> > I have been running Windows 8 and server 2012 HVM on OVMF for some
> time. I used the latest OVMF build from the edk2 source with xen-unstable.
> It works fine, except that the vnc connection doesn't update the picture, so I
> have to open and close the vnc window for updating the picture, until I have
> enabled remote desktop in windows. I also tried to pass through some USB
> ports with success, the passing through my intel hd 4000 gfx, does not work
> even in secondary mode.
> >
> > /Kristian Hagsted Rasmussen
> 
> Thanks for reply.
> I built successfull ovmf with xen-unstable with this changes:
> ./configure --enable-ovmf
> vi Config.mk
> OVMF_UPSTREAM_URL ?= git://github.com/tianocore/edk2.git
> OVMF_UPSTREAM_REVISION ?= master
> # Added patch for support gcc4.7 and rispective change in
> tools/firmware/ovmf-makefile
> 
> After that I tested it adding bios="ovmf" on domU's xl cfg.
> The domU starts but performance is very poor (similar to qemu without
> xen or kvm or worse).
> Tried with Windows 7 and Fedora 18: they start loading but never reach a
> complete boot (even after about 10 minutes).

When you say that they newer reach a complete boot, have you then tried to close your vnc and reconnect?

> 
> Are there any others specific task to do?
> 
> Thanks for any reply.
> 
> >> Thanks for any reply.
> >>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:52:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:52: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 1U3ikh-00023S-7J; Fri, 08 Feb 2013 07:52: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 1U3ikf-00023N-Cx
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:52:05 +0000
Received: from [85.158.143.35:62252] by server-1.bemta-4.messagelabs.com id
	70/6B-08839-4AEA4115; Fri, 08 Feb 2013 07:52:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360309918!14167866!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11719 invoked from network); 8 Feb 2013 07:51:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 07:51:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 07:51:58 +0000
Message-Id: <5114BCAE02000078000BD12D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 07:51:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@citrix.com>, "G.R." <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
In-Reply-To: <CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 07.02.13 at 18:43, "G.R." <firemeteor@users.sourceforge.net> wrote:
>> 
>> For one I wonder whether this is really _always_ correct. I.e.
>> the device at 00:1f.0 always being an ISA bridge. Wouldn't it
>> be better to mirror whatever the host device says?
>>
> From the Intel driver code, it's looking for an intel ISA bridge.

That doesn't mean that it always will be.

> So your question would be should it be always at 00:1f.0.
> So far it seems that it is.

Same thing here. We ought to be careful, or else we risk to
introduce issues that pretty hard to locate, debug, and fix.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:52:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:52: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 1U3ikh-00023S-7J; Fri, 08 Feb 2013 07:52: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 1U3ikf-00023N-Cx
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:52:05 +0000
Received: from [85.158.143.35:62252] by server-1.bemta-4.messagelabs.com id
	70/6B-08839-4AEA4115; Fri, 08 Feb 2013 07:52:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360309918!14167866!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11719 invoked from network); 8 Feb 2013 07:51:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 07:51:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 07:51:58 +0000
Message-Id: <5114BCAE02000078000BD12D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 07:51:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@citrix.com>, "G.R." <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
In-Reply-To: <CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 07.02.13 at 18:43, "G.R." <firemeteor@users.sourceforge.net> wrote:
>> 
>> For one I wonder whether this is really _always_ correct. I.e.
>> the device at 00:1f.0 always being an ISA bridge. Wouldn't it
>> be better to mirror whatever the host device says?
>>
> From the Intel driver code, it's looking for an intel ISA bridge.

That doesn't mean that it always will be.

> So your question would be should it be always at 00:1f.0.
> So far it seems that it is.

Same thing here. We ought to be careful, or else we risk to
introduce issues that pretty hard to locate, debug, and fix.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:55:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:55: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 1U3inK-0002AF-PL; Fri, 08 Feb 2013 07:54:50 +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 1U3inJ-0002A8-SL
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:54:50 +0000
Received: from [85.158.137.99:33514] by server-8.bemta-3.messagelabs.com id
	A4/40-25687-94FA4115; Fri, 08 Feb 2013 07:54:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360310088!15133156!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11293 invoked from network); 8 Feb 2013 07:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 07:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1268470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 07:54:09 +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.297.1; Fri, 8 Feb 2013
	07:54:09 +0000
Message-ID: <1360310048.9063.47.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Fri, 8 Feb 2013 07:54:08 +0000
In-Reply-To: <20130207.233107.1094455509765442729.davem@davemloft.net>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
	<20130207.233107.1094455509765442729.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] XSA-39 CVE-2013-021[67]: Linux
 netback DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 04:31 +0000, David Miller wrote:

> Applied, please don't add stable CC:'s to networking patches, instead
> ask me to queue it up to my -stable todo pile instead.

Thanks & Ack.

> I don't like it when patches instantly be submitted to -stable when
> they hit Linus's tree, I'd rather it soak upstream for a week or two
> instead.  That's why I do it this way.

Very reasonable.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:55:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:55: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 1U3inK-0002AF-PL; Fri, 08 Feb 2013 07:54:50 +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 1U3inJ-0002A8-SL
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:54:50 +0000
Received: from [85.158.137.99:33514] by server-8.bemta-3.messagelabs.com id
	A4/40-25687-94FA4115; Fri, 08 Feb 2013 07:54:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360310088!15133156!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11293 invoked from network); 8 Feb 2013 07:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 07:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1268470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 07:54:09 +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.297.1; Fri, 8 Feb 2013
	07:54:09 +0000
Message-ID: <1360310048.9063.47.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Fri, 8 Feb 2013 07:54:08 +0000
In-Reply-To: <20130207.233107.1094455509765442729.davem@davemloft.net>
References: <1360230078.32479.41.camel@zakaz.uk.xensource.com>
	<20130207.233107.1094455509765442729.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 0/4] XSA-39 CVE-2013-021[67]: Linux
 netback DoS via malicious guest ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 04:31 +0000, David Miller wrote:

> Applied, please don't add stable CC:'s to networking patches, instead
> ask me to queue it up to my -stable todo pile instead.

Thanks & Ack.

> I don't like it when patches instantly be submitted to -stable when
> they hit Linus's tree, I'd rather it soak upstream for a week or two
> instead.  That's why I do it this way.

Very reasonable.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:57:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:57: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 1U3ipc-0002Tn-Gf; Fri, 08 Feb 2013 07:57: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 1U3ipb-0002Tf-Ah
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:57:11 +0000
Received: from [85.158.143.35:46886] by server-3.bemta-4.messagelabs.com id
	BA/35-08920-6DFA4115; Fri, 08 Feb 2013 07:57:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360310194!6021113!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3939 invoked from network); 8 Feb 2013 07:56:34 -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; 8 Feb 2013 07:56:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 07:56:33 +0000
Message-Id: <5114BDC202000078000BD138@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 07:56:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <Jean.guyader@gmail.com>,
	"G.R." <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
	<5113E71B02000078000BCF86@nat28.tlf.novell.com>
	<CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
In-Reply-To: <CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 18:38, "G.R." <firemeteor@users.sourceforge.net> wrote:
>> > +    if (config_addr == PCI_INTEL_VENDOR_CAP)
>>> +    {
>>> +        *val = vendor_cap;
>>> +        return 1;
>>> +    }
>>> +
>>> +    /* Remove the next capability link */
>>> +    if (config_addr == vendor_cap + 1)
>>> +    {
>>> +        *val = 0;
>>> +        return 1;
>>> +    }
>>
>> It doesn't look right to ignore "len" up to here? What if this is a
>> word read at "vendor_cap"?
> The function is for intel IGD only and the first two returns are only
> sanity checks.
> The third is fine also since the PCI register is only one byte in
> length and other bytes in that word are reserved.

Just as for the other patch - this is way too lax an approach.
You mustn't introduce dependencies on current or observed
behavior, as this may break with future chipsets. You need to
follow what actual hardware does (i.e. allow multi-byte aligned
reads to properly return _all_ covered registers' values).

>>> +    /* Exposing writable register does not lead to security risk since this
>>> +       only apply to read. This may confuse the guest, but it works good so 
> far.
>>> +       Will switch to mask & merge style only if this is proved broken.
>>> +       Note: Always expose aligned address if any byte of the dword is to 
> be
>>> +       exposed. This provides a consistent view, at least for read. */
>>
>> Such a comment is certainly not helping being confident in the
>> changes you're trying to get merged in.
> 
> Could you be more specific on your suggestion?
> I don't think you are recommending to remove them.

Certainly not. I'm recommending to fix the code to make the
comment unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 07:57:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 07:57: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 1U3ipc-0002Tn-Gf; Fri, 08 Feb 2013 07:57: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 1U3ipb-0002Tf-Ah
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:57:11 +0000
Received: from [85.158.143.35:46886] by server-3.bemta-4.messagelabs.com id
	BA/35-08920-6DFA4115; Fri, 08 Feb 2013 07:57:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360310194!6021113!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3939 invoked from network); 8 Feb 2013 07:56:34 -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; 8 Feb 2013 07:56:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 07:56:33 +0000
Message-Id: <5114BDC202000078000BD138@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 07:56:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <Jean.guyader@gmail.com>,
	"G.R." <firemeteor@users.sourceforge.net>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
	<5113E71B02000078000BCF86@nat28.tlf.novell.com>
	<CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
In-Reply-To: <CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.02.13 at 18:38, "G.R." <firemeteor@users.sourceforge.net> wrote:
>> > +    if (config_addr == PCI_INTEL_VENDOR_CAP)
>>> +    {
>>> +        *val = vendor_cap;
>>> +        return 1;
>>> +    }
>>> +
>>> +    /* Remove the next capability link */
>>> +    if (config_addr == vendor_cap + 1)
>>> +    {
>>> +        *val = 0;
>>> +        return 1;
>>> +    }
>>
>> It doesn't look right to ignore "len" up to here? What if this is a
>> word read at "vendor_cap"?
> The function is for intel IGD only and the first two returns are only
> sanity checks.
> The third is fine also since the PCI register is only one byte in
> length and other bytes in that word are reserved.

Just as for the other patch - this is way too lax an approach.
You mustn't introduce dependencies on current or observed
behavior, as this may break with future chipsets. You need to
follow what actual hardware does (i.e. allow multi-byte aligned
reads to properly return _all_ covered registers' values).

>>> +    /* Exposing writable register does not lead to security risk since this
>>> +       only apply to read. This may confuse the guest, but it works good so 
> far.
>>> +       Will switch to mask & merge style only if this is proved broken.
>>> +       Note: Always expose aligned address if any byte of the dword is to 
> be
>>> +       exposed. This provides a consistent view, at least for read. */
>>
>> Such a comment is certainly not helping being confident in the
>> changes you're trying to get merged in.
> 
> Could you be more specific on your suggestion?
> I don't think you are recommending to remove them.

Certainly not. I'm recommending to fix the code to make the
comment unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:06:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:06: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 1U3iy3-0003Sb-PI; Fri, 08 Feb 2013 08:05: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 1U3iy2-0003SW-Oz
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:05:54 +0000
Received: from [85.158.137.99:3797] by server-7.bemta-3.messagelabs.com id
	41/9A-10367-2E1B4115; Fri, 08 Feb 2013 08:05:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360310753!15762057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30707 invoked from network); 8 Feb 2013 08:05:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 08:05:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:05:52 +0000
Message-Id: <5114BFEC02000078000BD148@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:05:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Milan opath" <milan.opath@gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
In-Reply-To: <CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 08.02.13 at 08:47, Milan opath <milan.opath@gmail.com> wrote:
> Thank you for your help guys. I tried to apply those patches, but I didn't
> succeed.
> Konrard's acpi-s3 worked (in sence I didn't get error while patching), but
> the patches from Ben not. Arch linux is using pretty much vanilla kernel
> with only 3 patches applied(upstream patch, default console loglevel patch
> and fat issue patch), and it seems I'm missing a whole lot of things there.
> For instance, the 'fix-dmar-zap-reinstate.txt' requires /xen/drivers/
> folder, but in my kernel source it is missing (there is xen, but no
> drivers).

Are you trying to apply hypervisor patches to the kernel? That
surely can't woprk...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:06:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:06: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 1U3iy3-0003Sb-PI; Fri, 08 Feb 2013 08:05: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 1U3iy2-0003SW-Oz
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:05:54 +0000
Received: from [85.158.137.99:3797] by server-7.bemta-3.messagelabs.com id
	41/9A-10367-2E1B4115; Fri, 08 Feb 2013 08:05:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360310753!15762057!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30707 invoked from network); 8 Feb 2013 08:05:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 08:05:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:05:52 +0000
Message-Id: <5114BFEC02000078000BD148@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:05:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Milan opath" <milan.opath@gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
In-Reply-To: <CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 08.02.13 at 08:47, Milan opath <milan.opath@gmail.com> wrote:
> Thank you for your help guys. I tried to apply those patches, but I didn't
> succeed.
> Konrard's acpi-s3 worked (in sence I didn't get error while patching), but
> the patches from Ben not. Arch linux is using pretty much vanilla kernel
> with only 3 patches applied(upstream patch, default console loglevel patch
> and fat issue patch), and it seems I'm missing a whole lot of things there.
> For instance, the 'fix-dmar-zap-reinstate.txt' requires /xen/drivers/
> folder, but in my kernel source it is missing (there is xen, but no
> drivers).

Are you trying to apply hypervisor patches to the kernel? That
surely can't woprk...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:07: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 1U3izI-0003WW-8T; Fri, 08 Feb 2013 08:07:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U3izH-0003WI-12
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:07:11 +0000
Received: from [85.158.137.99:54151] by server-4.bemta-3.messagelabs.com id
	F7/1D-12802-E22B4115; Fri, 08 Feb 2013 08:07:10 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360310829!19679868!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7026 invoked from network); 8 Feb 2013 08:07:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 08:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1268819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 08:07: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.297.1; Fri, 8 Feb 2013 08:07:09 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U3izF-0001iG-5H; Fri, 08 Feb 2013
	08:07:09 +0000
Message-ID: <5114B228.8070009@citrix.com>
Date: Fri, 8 Feb 2013 09:07:04 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Milan opath <milan.opath@gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>	<510F885B.2040603@citrix.com>	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
In-Reply-To: <CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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/02/13 08:47, Milan opath wrote:
> Thank you for your help guys. I tried to apply those patches, but I 
> didn't succeed.
> Konrard's acpi-s3 worked (in sence I didn't get error while patching), 
> but the patches from Ben not. Arch linux is using pretty much vanilla 
> kernel with only 3 patches applied(upstream patch, default console 
> loglevel patch and fat issue patch), and it seems I'm missing a whole 
> lot of things there.
> For instance, the 'fix-dmar-zap-reinstate.txt' requires /xen/drivers/ 
> folder, but in my kernel source it is missing (there is xen, but no 
> drivers).
>
> I'm not familiar with custom kernel building (this was my first time), 
> but I would say I'm missing some xen patches that should be applied 
> priror to those of Ben.
> Could you please give me a hint on how can I proceed or what kernel 
> did you use?
> Thank you very much for your time.
>
>
Milan, these three patches from Ben are against xen, not linux kernel - 
so you have to build patched xen from sources.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:07: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 1U3izI-0003WW-8T; Fri, 08 Feb 2013 08:07:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U3izH-0003WI-12
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:07:11 +0000
Received: from [85.158.137.99:54151] by server-4.bemta-3.messagelabs.com id
	F7/1D-12802-E22B4115; Fri, 08 Feb 2013 08:07:10 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360310829!19679868!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7026 invoked from network); 8 Feb 2013 08:07:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 08:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1268819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 08:07: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.297.1; Fri, 8 Feb 2013 08:07:09 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U3izF-0001iG-5H; Fri, 08 Feb 2013
	08:07:09 +0000
Message-ID: <5114B228.8070009@citrix.com>
Date: Fri, 8 Feb 2013 09:07:04 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Milan opath <milan.opath@gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>	<510F885B.2040603@citrix.com>	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
In-Reply-To: <CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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/02/13 08:47, Milan opath wrote:
> Thank you for your help guys. I tried to apply those patches, but I 
> didn't succeed.
> Konrard's acpi-s3 worked (in sence I didn't get error while patching), 
> but the patches from Ben not. Arch linux is using pretty much vanilla 
> kernel with only 3 patches applied(upstream patch, default console 
> loglevel patch and fat issue patch), and it seems I'm missing a whole 
> lot of things there.
> For instance, the 'fix-dmar-zap-reinstate.txt' requires /xen/drivers/ 
> folder, but in my kernel source it is missing (there is xen, but no 
> drivers).
>
> I'm not familiar with custom kernel building (this was my first time), 
> but I would say I'm missing some xen patches that should be applied 
> priror to those of Ben.
> Could you please give me a hint on how can I proceed or what kernel 
> did you use?
> Thank you very much for your time.
>
>
Milan, these three patches from Ben are against xen, not linux kernel - 
so you have to build patched xen from sources.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:11:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08: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 1U3j3T-0003z3-VU; Fri, 08 Feb 2013 08:11:31 +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 1U3j3S-0003yv-8R
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:11:30 +0000
Received: from [85.158.137.99:14596] by server-3.bemta-3.messagelabs.com id
	AD/E5-31070-133B4115; Fri, 08 Feb 2013 08:11:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360311088!15833804!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30734 invoked from network); 8 Feb 2013 08:11:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 08:11:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:11:27 +0000
Message-Id: <5114C13E02000078000BD15E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:11:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "M A Young" <m.a.young@durham.ac.uk>
References: <CD39469B.4B817%keir.xen@gmail.com>
	<alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 00:20, M A Young <m.a.young@durham.ac.uk> wrote:
> I am attaching a patch that turns off this check.

You were told how to do it and still did it wrong: You can't blindly
pass an option to the compiler that not all supported versions
recognize. Once again, please do it the same way as done for
other warnings (using cc-option-add).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:11:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08: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 1U3j3T-0003z3-VU; Fri, 08 Feb 2013 08:11:31 +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 1U3j3S-0003yv-8R
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:11:30 +0000
Received: from [85.158.137.99:14596] by server-3.bemta-3.messagelabs.com id
	AD/E5-31070-133B4115; Fri, 08 Feb 2013 08:11:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360311088!15833804!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30734 invoked from network); 8 Feb 2013 08:11:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 08:11:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:11:27 +0000
Message-Id: <5114C13E02000078000BD15E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:11:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "M A Young" <m.a.young@durham.ac.uk>
References: <CD39469B.4B817%keir.xen@gmail.com>
	<alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 00:20, M A Young <m.a.young@durham.ac.uk> wrote:
> I am attaching a patch that turns off this check.

You were told how to do it and still did it wrong: You can't blindly
pass an option to the compiler that not all supported versions
recognize. Once again, please do it the same way as done for
other warnings (using cc-option-add).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:14:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:14: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 1U3j5n-0004BV-Q2; Fri, 08 Feb 2013 08:13:55 +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 1U3j5m-0004BN-E9
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:13:54 +0000
Received: from [193.109.254.147:6675] by server-14.bemta-14.messagelabs.com id
	26/B0-02031-1C3B4115; Fri, 08 Feb 2013 08:13:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360311233!2132386!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30258 invoked from network); 8 Feb 2013 08:13:53 -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; 8 Feb 2013 08:13:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:13:52 +0000
Message-Id: <5114C1CE02000078000BD161@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:13:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "M A Young" <m.a.young@durham.ac.uk>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<511389AC02000078000BCC3A@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1302072321090.6708@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302072321090.6708@procyon.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Patch 2/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 00:25, M A Young <m.a.young@durham.ac.uk> wrote:
> On Thu, 7 Feb 2013, Jan Beulich wrote:
> 
>>>>> On 06.02.13 at 21:37, M A Young <m.a.young@durham.ac.uk> wrote:
>>> @@ -264,7 +264,7 @@
>>>                return -1;
>>>        }
>>>
>>> -       memset(buf,0,sizeof(buf));
>>> +       memset(buf,0,sizeof(*buf));
>>
>> While everything else looks right, this one for sure is wrong - buf
>> is an array, and hence sizeof(*buf) would clear just the first array
>> element.
> 
> Yes, I now agree it is wrong (I found the other example in that file and 
> assumed this one was broken as well). I am attaching a patch that fixes 
> the other cases.

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Ian - please also consider applying to the 4.x trees.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:14:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:14: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 1U3j5n-0004BV-Q2; Fri, 08 Feb 2013 08:13:55 +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 1U3j5m-0004BN-E9
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:13:54 +0000
Received: from [193.109.254.147:6675] by server-14.bemta-14.messagelabs.com id
	26/B0-02031-1C3B4115; Fri, 08 Feb 2013 08:13:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360311233!2132386!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30258 invoked from network); 8 Feb 2013 08:13:53 -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; 8 Feb 2013 08:13:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:13:52 +0000
Message-Id: <5114C1CE02000078000BD161@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:13:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "M A Young" <m.a.young@durham.ac.uk>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <alpine.DEB.2.00.1302062013370.12408@procyon.dur.ac.uk>
	<511389AC02000078000BCC3A@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1302072321090.6708@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1302072321090.6708@procyon.dur.ac.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Patch 2/2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 00:25, M A Young <m.a.young@durham.ac.uk> wrote:
> On Thu, 7 Feb 2013, Jan Beulich wrote:
> 
>>>>> On 06.02.13 at 21:37, M A Young <m.a.young@durham.ac.uk> wrote:
>>> @@ -264,7 +264,7 @@
>>>                return -1;
>>>        }
>>>
>>> -       memset(buf,0,sizeof(buf));
>>> +       memset(buf,0,sizeof(*buf));
>>
>> While everything else looks right, this one for sure is wrong - buf
>> is an array, and hence sizeof(*buf) would clear just the first array
>> element.
> 
> Yes, I now agree it is wrong (I found the other example in that file and 
> assumed this one was broken as well). I am attaching a patch that fixes 
> the other cases.

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Ian - please also consider applying to the 4.x trees.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:20:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08: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 1U3jBx-0004ad-Tv; Fri, 08 Feb 2013 08:20:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U3jBw-0004aX-7i
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:20:16 +0000
Received: from [85.158.139.83:51148] by server-3.bemta-5.messagelabs.com id
	47/D2-07037-F35B4115; Fri, 08 Feb 2013 08:20:15 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360311613!27422908!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4MzU1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29461 invoked from network); 8 Feb 2013 08:20:14 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 08:20:14 -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:Subject:References:In-Reply-To:
	Content-Type:Content-Transfer-Encoding;
	b=QiWL4a5kBNyCFlPMVemEBiIkBTWL6T5hqjyv7HtGJ4OjWq/Cd/S0s8su
	JmXteXgoY6VgsTx7apPagAYjCAIN+TvQg7s9E2XvoK0tZ5ZmyCcvDGwNO
	hglWppxxSDqUzBusTPBRlxNd23cAjejltBHPi0HpAHDy97zlr+ycyzTuL
	sqtYa2xFaR8pM9EHYW01why8JyQ83bAeLcicfpvBy96opqSblNgxpKvkv
	yWChz25++0gr26PZ3uGlod08uMD+Y;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1360311614; x=1391847614;
	h=message-id:date:from:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=dEN+vahhUgjWcC9DzEEw/LWAnY2VgBxsWJ9enF5XkDQ=;
	b=qBKU0jExpYOVoGBdoM+1XNQliWD4B/dwVy9e3sicQiNPjrCO/NE8ib3z
	JjvqJv1B3EIeM3jHQvC2pDnMQvnz7q51kW8dodYffQaGNIu6xoXDlu6ZO
	/eLBUcCWNxw2UpxnwjxMZ0rDVuEotuyrxD3Plcsc8WsJru0R1yPiBkI0L
	w1Pa4Bp6+wP/roaBFjM4N0AniNW4XJLxOYILJ5ZPq4LvAu7fHPZciAyxp
	M1lzjrGQ2Sd5vMsVNpAVHCTPTuaNK;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; d="scan'208";a="136198165"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2013 09:20:13 +0100
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; 
   d="scan'208";a="450275"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 08 Feb 2013 09:20:13 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 985B996BB1C;
	Fri,  8 Feb 2013 09:20:13 +0100 (CET)
Message-ID: <5114B53D.1000108@ts.fujitsu.com>
Date: Fri, 08 Feb 2013 09:20:13 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
References: <51025526.3060105@ts.fujitsu.com>
In-Reply-To: <51025526.3060105@ts.fujitsu.com>
Subject: Re: [Xen-devel] backport request for Xen 4.2 and 4.1 of
	cs	26287:127c2c47d440
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Ping?

Am 25.01.2013 10:49, schrieb Juergen Gross:
> Hi,
>
> I request backport of changeset 26287:127c2c47d440 to Xen 4.2 and Xen 4.1.
>
> Without this change we experience Dom0 lockups when cpupool0 has all
> cpus but
> one on a single socket and xen ticketlocks are disabled in Dom0.
>
> Some background information:
>
> Disabling ticketlocks in Dom0 was done to avoid lock starvation on certain
> workloads with one lock in Dom0 taken at a higher frequency as ticketlock
> processing would allow (the poll hypercall was much more expensive than
> waiting
> for the lock via spinning). In our configuration Dom0 is the only domain in
> cpupool0 so using xen ticketlocks shouldn't be an advantage.
>
> The Dom0 lockup happened when one vcpu was holding the xtime_lock while all
> other vcpus tried to grab it and none of the vcpus was running on the
> single
> core on the other socket. At some time all vcpus were spinning and the one
> core was idle without being considered for vcpu migration (this should be
> addressed by the changeset above). As none of the vcpus would give up
> control
> voluntarily the complete time slice is used with one vcpu of Dom0 having no
> physical processor to run on. During that time the next timer interrupt
> will
> be pending leading to another request of the xtime_lock which will
> trigger the
> same loop over and over again.
>
>
> Juergen
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 08 08:20:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08: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 1U3jBx-0004ad-Tv; Fri, 08 Feb 2013 08:20:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U3jBw-0004aX-7i
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:20:16 +0000
Received: from [85.158.139.83:51148] by server-3.bemta-5.messagelabs.com id
	47/D2-07037-F35B4115; Fri, 08 Feb 2013 08:20:15 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360311613!27422908!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4MzU1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29461 invoked from network); 8 Feb 2013 08:20:14 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 08:20:14 -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:Subject:References:In-Reply-To:
	Content-Type:Content-Transfer-Encoding;
	b=QiWL4a5kBNyCFlPMVemEBiIkBTWL6T5hqjyv7HtGJ4OjWq/Cd/S0s8su
	JmXteXgoY6VgsTx7apPagAYjCAIN+TvQg7s9E2XvoK0tZ5ZmyCcvDGwNO
	hglWppxxSDqUzBusTPBRlxNd23cAjejltBHPi0HpAHDy97zlr+ycyzTuL
	sqtYa2xFaR8pM9EHYW01why8JyQ83bAeLcicfpvBy96opqSblNgxpKvkv
	yWChz25++0gr26PZ3uGlod08uMD+Y;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1360311614; x=1391847614;
	h=message-id:date:from:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=dEN+vahhUgjWcC9DzEEw/LWAnY2VgBxsWJ9enF5XkDQ=;
	b=qBKU0jExpYOVoGBdoM+1XNQliWD4B/dwVy9e3sicQiNPjrCO/NE8ib3z
	JjvqJv1B3EIeM3jHQvC2pDnMQvnz7q51kW8dodYffQaGNIu6xoXDlu6ZO
	/eLBUcCWNxw2UpxnwjxMZ0rDVuEotuyrxD3Plcsc8WsJru0R1yPiBkI0L
	w1Pa4Bp6+wP/roaBFjM4N0AniNW4XJLxOYILJ5ZPq4LvAu7fHPZciAyxp
	M1lzjrGQ2Sd5vMsVNpAVHCTPTuaNK;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; d="scan'208";a="136198165"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2013 09:20:13 +0100
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; 
   d="scan'208";a="450275"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 08 Feb 2013 09:20:13 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 985B996BB1C;
	Fri,  8 Feb 2013 09:20:13 +0100 (CET)
Message-ID: <5114B53D.1000108@ts.fujitsu.com>
Date: Fri, 08 Feb 2013 09:20:13 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
References: <51025526.3060105@ts.fujitsu.com>
In-Reply-To: <51025526.3060105@ts.fujitsu.com>
Subject: Re: [Xen-devel] backport request for Xen 4.2 and 4.1 of
	cs	26287:127c2c47d440
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Ping?

Am 25.01.2013 10:49, schrieb Juergen Gross:
> Hi,
>
> I request backport of changeset 26287:127c2c47d440 to Xen 4.2 and Xen 4.1.
>
> Without this change we experience Dom0 lockups when cpupool0 has all
> cpus but
> one on a single socket and xen ticketlocks are disabled in Dom0.
>
> Some background information:
>
> Disabling ticketlocks in Dom0 was done to avoid lock starvation on certain
> workloads with one lock in Dom0 taken at a higher frequency as ticketlock
> processing would allow (the poll hypercall was much more expensive than
> waiting
> for the lock via spinning). In our configuration Dom0 is the only domain in
> cpupool0 so using xen ticketlocks shouldn't be an advantage.
>
> The Dom0 lockup happened when one vcpu was holding the xtime_lock while all
> other vcpus tried to grab it and none of the vcpus was running on the
> single
> core on the other socket. At some time all vcpus were spinning and the one
> core was idle without being considered for vcpu migration (this should be
> addressed by the changeset above). As none of the vcpus would give up
> control
> voluntarily the complete time slice is used with one vcpu of Dom0 having no
> physical processor to run on. During that time the next timer interrupt
> will
> be pending leading to another request of the xtime_lock which will
> trigger the
> same loop over and over again.
>
>
> Juergen
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 08 08:38:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:38: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 1U3jTb-0005QI-MH; Fri, 08 Feb 2013 08:38:31 +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 1U3jTa-0005QD-4a
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:38:30 +0000
Received: from [193.109.254.147:3285] by server-7.bemta-14.messagelabs.com id
	E3/A9-13581-589B4115; Fri, 08 Feb 2013 08:38:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360312696!9221608!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1211 invoked from network); 8 Feb 2013 08:38:16 -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; 8 Feb 2013 08:38:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:38:16 +0000
Message-Id: <5114C78802000078000BD196@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:38:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <51025526.3060105@ts.fujitsu.com> <5114B53D.1000108@ts.fujitsu.com>
In-Reply-To: <5114B53D.1000108@ts.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport request for Xen 4.2 and 4.1 of
 cs	26287:127c2c47d440
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 09:20, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> Ping?

This is still on my todo list, but I wanted it to go through our own
internal testing first. Meanwhile that's done (for 4.2 at least), but
I didn't have time to apply the pending backports yet, and there's
no rush as we still have a couple of weeks until the intended -rc1.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:38:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:38: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 1U3jTb-0005QI-MH; Fri, 08 Feb 2013 08:38:31 +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 1U3jTa-0005QD-4a
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:38:30 +0000
Received: from [193.109.254.147:3285] by server-7.bemta-14.messagelabs.com id
	E3/A9-13581-589B4115; Fri, 08 Feb 2013 08:38:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360312696!9221608!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1211 invoked from network); 8 Feb 2013 08:38:16 -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; 8 Feb 2013 08:38:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 08:38:16 +0000
Message-Id: <5114C78802000078000BD196@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 08:38:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <51025526.3060105@ts.fujitsu.com> <5114B53D.1000108@ts.fujitsu.com>
In-Reply-To: <5114B53D.1000108@ts.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport request for Xen 4.2 and 4.1 of
 cs	26287:127c2c47d440
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 09:20, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> Ping?

This is still on my todo list, but I wanted it to go through our own
internal testing first. Meanwhile that's done (for 4.2 at least), but
I didn't have time to apply the pending backports yet, and there's
no rush as we still have a couple of weeks until the intended -rc1.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 08:46:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:46: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 1U3jaq-0005qy-JF; Fri, 08 Feb 2013 08:46:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U3jap-0005qt-V8
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:46:00 +0000
Received: from [85.158.143.35:17308] by server-3.bemta-4.messagelabs.com id
	00/7B-08920-74BB4115; Fri, 08 Feb 2013 08:45:59 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360313104!14174405!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4MzU1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22180 invoked from network); 8 Feb 2013 08:45:21 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 08:45: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:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=IHwKAOKPXFtSc8fNkvBCkiFiDeW/VtP+unh5e6XoVFghI+jmuLuXCrIv
	i7McvEwq84I1tPfvbtrFVyGoE+xrwOZewK3dHuCFbyhEpjYwRWqWnddPa
	FWRBiDrv2Ukrsgq1NE4TJUZEAMX8SGSudWf5nSldAHd2Zkm+LqAQ80NJE
	zetBCwkfBW3BgMRQjnY4jlIH3wNUpLHE2uPbtJqwSwX2a/91ZTFbeA06d
	FIheDVWV7zYytqq3XR0CbGPX/Yzm+;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1360313121; x=1391849121;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=Zl25BuBmG8+c8AOFdxLqzLd7FjK6TP/5wJhixaqtUQw=;
	b=lbstSR8NP+TTbVIBEeL8CFiBKahiClpnAqBrmRqq4R3/H++wRhkGuBQB
	ZlG10gtxaMt96VkYh83glzOv+WU6/7T6Tl3pv9YZPvWQvkcS08bOtlZHA
	INPIbr24RfjlNY/ijB2jPeui5mf6oTKdJ5gC8vqGvJJDIU2VwM9bvHeUY
	bMcfYEz9pq+bUy+vnzb3GJQRMSOxynaPNr/Kix6+dHLmb8M/5qBlAslJO
	ep76LHy3DLt3VKGCiAvzCnMkYNe7U;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; d="scan'208";a="136202796"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2013 09:45:02 +0100
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; 
   d="scan'208";a="453063"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 08 Feb 2013 09:45:01 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id A861D96A7E2;
	Fri,  8 Feb 2013 09:45:01 +0100 (CET)
Message-ID: <5114BB0D.4050703@ts.fujitsu.com>
Date: Fri, 08 Feb 2013 09:45:01 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51025526.3060105@ts.fujitsu.com> <5114B53D.1000108@ts.fujitsu.com>
	<5114C78802000078000BD196@nat28.tlf.novell.com>
In-Reply-To: <5114C78802000078000BD196@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport request for Xen 4.2 and 4.1 of
	cs	26287:127c2c47d440
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 08.02.2013 09:38, schrieb Jan Beulich:
>>>> On 08.02.13 at 09:20, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>> Ping?
>
> This is still on my todo list, but I wanted it to go through our own
> internal testing first. Meanwhile that's done (for 4.2 at least), but
> I didn't have time to apply the pending backports yet, and there's
> no rush as we still have a couple of weeks until the intended -rc1.

Okay, thanks.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 08 08:46:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:46: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 1U3jaq-0005qy-JF; Fri, 08 Feb 2013 08:46:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1U3jap-0005qt-V8
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 08:46:00 +0000
Received: from [85.158.143.35:17308] by server-3.bemta-4.messagelabs.com id
	00/7B-08920-74BB4115; Fri, 08 Feb 2013 08:45:59 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360313104!14174405!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4MzU1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22180 invoked from network); 8 Feb 2013 08:45:21 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 08:45: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:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=IHwKAOKPXFtSc8fNkvBCkiFiDeW/VtP+unh5e6XoVFghI+jmuLuXCrIv
	i7McvEwq84I1tPfvbtrFVyGoE+xrwOZewK3dHuCFbyhEpjYwRWqWnddPa
	FWRBiDrv2Ukrsgq1NE4TJUZEAMX8SGSudWf5nSldAHd2Zkm+LqAQ80NJE
	zetBCwkfBW3BgMRQjnY4jlIH3wNUpLHE2uPbtJqwSwX2a/91ZTFbeA06d
	FIheDVWV7zYytqq3XR0CbGPX/Yzm+;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1360313121; x=1391849121;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=Zl25BuBmG8+c8AOFdxLqzLd7FjK6TP/5wJhixaqtUQw=;
	b=lbstSR8NP+TTbVIBEeL8CFiBKahiClpnAqBrmRqq4R3/H++wRhkGuBQB
	ZlG10gtxaMt96VkYh83glzOv+WU6/7T6Tl3pv9YZPvWQvkcS08bOtlZHA
	INPIbr24RfjlNY/ijB2jPeui5mf6oTKdJ5gC8vqGvJJDIU2VwM9bvHeUY
	bMcfYEz9pq+bUy+vnzb3GJQRMSOxynaPNr/Kix6+dHLmb8M/5qBlAslJO
	ep76LHy3DLt3VKGCiAvzCnMkYNe7U;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; d="scan'208";a="136202796"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 08 Feb 2013 09:45:02 +0100
X-IronPort-AV: E=Sophos;i="4.84,628,1355094000"; 
   d="scan'208";a="453063"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 08 Feb 2013 09:45:01 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id A861D96A7E2;
	Fri,  8 Feb 2013 09:45:01 +0100 (CET)
Message-ID: <5114BB0D.4050703@ts.fujitsu.com>
Date: Fri, 08 Feb 2013 09:45:01 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51025526.3060105@ts.fujitsu.com> <5114B53D.1000108@ts.fujitsu.com>
	<5114C78802000078000BD196@nat28.tlf.novell.com>
In-Reply-To: <5114C78802000078000BD196@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] backport request for Xen 4.2 and 4.1 of
	cs	26287:127c2c47d440
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 08.02.2013 09:38, schrieb Jan Beulich:
>>>> On 08.02.13 at 09:20, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>> Ping?
>
> This is still on my todo list, but I wanted it to go through our own
> internal testing first. Meanwhile that's done (for 4.2 at least), but
> I didn't have time to apply the pending backports yet, and there's
> no rush as we still have a couple of weeks until the intended -rc1.

Okay, thanks.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG 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 Fri Feb 08 08:53:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:53: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 1U3jhi-0006JH-9B; Fri, 08 Feb 2013 08:53:06 +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 1U3jhh-0006JC-B0
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 08:53:05 +0000
Received: from [193.109.254.147:43828] by server-14.bemta-14.messagelabs.com
	id D4/88-02031-0FCB4115; Fri, 08 Feb 2013 08:53:04 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360313576!4103046!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22131 invoked from network); 8 Feb 2013 08:52:56 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 08:52:56 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id AD21240046B;
	Fri,  8 Feb 2013 09:52:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id zBEJuDHAiJZ3; Fri,  8 Feb 2013 09:52:54 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id B1CCF40045E;
	Fri,  8 Feb 2013 09:52:53 +0100 (CET)
Message-ID: <5114BCE2.70405@tiscali.it>
Date: Fri, 08 Feb 2013 09:52:50 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
	<5113D620.702@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94B29A@hagsted-bserver.hagsted.dk>
In-Reply-To: <19EF9FEB5AF86243A3F18E5CE75971640C94B29A@hagsted-bserver.hagsted.dk>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
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="===============8118805497940573605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8118805497940573605==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090609060607050702060702"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090609060607050702060702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 08/02/2013 08:32, Kristian Hagsted Rasmussen ha scritto:
>
>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
>> Sent: 7. februar 2013 17:28
>> To: Kristian Hagsted Rasmussen
>> Cc: xen-devel; Ian Campbell; Stefano Stabellini
>> Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
>>
>> Il 07/02/2013 13:48, Kristian Hagsted Rasmussen ha scritto:
>>>> -----Original Message-----
>>>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>>>> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
>>>> Sent: 7. februar 2013 13:28
>>>> To: xen-devel; Ian Campbell; Stefano Stabellini
>>>> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
>>>>
>>>> I haven't seen mail about eufi support on hvm domUs (ovmf) for a lon=
g
>> time.
>>>> I'm interested in trying it with xen-unstable.
>>>> Someone can tell me if there is something to add to have it working
>> and/or
>>>> ovmf git need to be updated?
>>> I have been running Windows 8 and server 2012 HVM on OVMF for some
>> time. I used the latest OVMF build from the edk2 source with xen-unsta=
ble.
>> It works fine, except that the vnc connection doesn't update the pictu=
re, so I
>> have to open and close the vnc window for updating the picture, until =
I have
>> enabled remote desktop in windows. I also tried to pass through some U=
SB
>> ports with success, the passing through my intel hd 4000 gfx, does not=
 work
>> even in secondary mode.
>>> /Kristian Hagsted Rasmussen
>> Thanks for reply.
>> I built successfull ovmf with xen-unstable with this changes:
>> ./configure --enable-ovmf
>> vi Config.mk
>> OVMF_UPSTREAM_URL ?=3D git://github.com/tianocore/edk2.git
>> OVMF_UPSTREAM_REVISION ?=3D master
>> # Added patch for support gcc4.7 and rispective change in
>> tools/firmware/ovmf-makefile
>>
>> After that I tested it adding bios=3D"ovmf" on domU's xl cfg.
>> The domU starts but performance is very poor (similar to qemu without
>> xen or kvm or worse).
>> Tried with Windows 7 and Fedora 18: they start loading but never reach=
 a
>> complete boot (even after about 10 minutes).
> When you say that they newer reach a complete boot, have you then tried=
 to close your vnc and reconnect?

I don't used vnc but Spice (basic without qxl), no error or warning in lo=
g.
Tried also with vnc but same problem.
The problem seem general domU performance.
Have you tried ovmf adding its vgabios?
Can you tell me your ovmf revision, build parameter and qemu version?

>> Are there any others specific task to do?
>>
>> Thanks for any reply.
>>
>>>> Thanks for any reply.
>>>>
>



--------------ms090609060607050702060702
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwODA4NTI1MFowIwYJKoZIhvcNAQkEMRYEFO/qsLWd2y86iBMV7RfYw7kH
QNhNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAPk6YWOmiNTFCglT0LzE2kGDQ
m28ckUlKapifpJT7mklGthxwYW814JHPMhfGIj8/rFf3Hm0cNxWlf4CkA1zfOYJGpeVxc9Zr
wM0XthKLKkLCMkODO3KG/YhfjkoDPak3jVlBHtOXFjH8s9AquI8grnexbni/32tNcV28CiY6
NczcElafd0fIdP+vtH3mXYWQHMaT3hvqlxMHW6YLbojaZsZiDN2sqtHGzS2QQ2sV+EvEx5EB
CfiMFgJe7lTtXH7xgue9HNnoTqpBvu+dA7kAVoSmxwXvQW6tpRHOCuXdJamuXXMER830KJkM
3+X3/rut9d6GPT5ZES5hOCcJhmnlMAAAAAAAAA==
--------------ms090609060607050702060702--


--===============8118805497940573605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8118805497940573605==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 08:53:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 08:53: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 1U3jhi-0006JH-9B; Fri, 08 Feb 2013 08:53:06 +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 1U3jhh-0006JC-B0
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 08:53:05 +0000
Received: from [193.109.254.147:43828] by server-14.bemta-14.messagelabs.com
	id D4/88-02031-0FCB4115; Fri, 08 Feb 2013 08:53:04 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360313576!4103046!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22131 invoked from network); 8 Feb 2013 08:52:56 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 08:52:56 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id AD21240046B;
	Fri,  8 Feb 2013 09:52:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id zBEJuDHAiJZ3; Fri,  8 Feb 2013 09:52:54 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id B1CCF40045E;
	Fri,  8 Feb 2013 09:52:53 +0100 (CET)
Message-ID: <5114BCE2.70405@tiscali.it>
Date: Fri, 08 Feb 2013 09:52:50 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Kristian Hagsted Rasmussen <kristian@hagsted.dk>
References: <51139DBE.7070407@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94AE2A@hagsted-bserver.hagsted.dk>
	<5113D620.702@tiscali.it>
	<19EF9FEB5AF86243A3F18E5CE75971640C94B29A@hagsted-bserver.hagsted.dk>
In-Reply-To: <19EF9FEB5AF86243A3F18E5CE75971640C94B29A@hagsted-bserver.hagsted.dk>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
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="===============8118805497940573605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8118805497940573605==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090609060607050702060702"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090609060607050702060702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 08/02/2013 08:32, Kristian Hagsted Rasmussen ha scritto:
>
>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
>> Sent: 7. februar 2013 17:28
>> To: Kristian Hagsted Rasmussen
>> Cc: xen-devel; Ian Campbell; Stefano Stabellini
>> Subject: Re: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
>>
>> Il 07/02/2013 13:48, Kristian Hagsted Rasmussen ha scritto:
>>>> -----Original Message-----
>>>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>>>> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
>>>> Sent: 7. februar 2013 13:28
>>>> To: xen-devel; Ian Campbell; Stefano Stabellini
>>>> Subject: [Xen-devel] Status of UEFI (ovmf) with hvm domUs
>>>>
>>>> I haven't seen mail about eufi support on hvm domUs (ovmf) for a lon=
g
>> time.
>>>> I'm interested in trying it with xen-unstable.
>>>> Someone can tell me if there is something to add to have it working
>> and/or
>>>> ovmf git need to be updated?
>>> I have been running Windows 8 and server 2012 HVM on OVMF for some
>> time. I used the latest OVMF build from the edk2 source with xen-unsta=
ble.
>> It works fine, except that the vnc connection doesn't update the pictu=
re, so I
>> have to open and close the vnc window for updating the picture, until =
I have
>> enabled remote desktop in windows. I also tried to pass through some U=
SB
>> ports with success, the passing through my intel hd 4000 gfx, does not=
 work
>> even in secondary mode.
>>> /Kristian Hagsted Rasmussen
>> Thanks for reply.
>> I built successfull ovmf with xen-unstable with this changes:
>> ./configure --enable-ovmf
>> vi Config.mk
>> OVMF_UPSTREAM_URL ?=3D git://github.com/tianocore/edk2.git
>> OVMF_UPSTREAM_REVISION ?=3D master
>> # Added patch for support gcc4.7 and rispective change in
>> tools/firmware/ovmf-makefile
>>
>> After that I tested it adding bios=3D"ovmf" on domU's xl cfg.
>> The domU starts but performance is very poor (similar to qemu without
>> xen or kvm or worse).
>> Tried with Windows 7 and Fedora 18: they start loading but never reach=
 a
>> complete boot (even after about 10 minutes).
> When you say that they newer reach a complete boot, have you then tried=
 to close your vnc and reconnect?

I don't used vnc but Spice (basic without qxl), no error or warning in lo=
g.
Tried also with vnc but same problem.
The problem seem general domU performance.
Have you tried ovmf adding its vgabios?
Can you tell me your ovmf revision, build parameter and qemu version?

>> Are there any others specific task to do?
>>
>> Thanks for any reply.
>>
>>>> Thanks for any reply.
>>>>
>



--------------ms090609060607050702060702
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwODA4NTI1MFowIwYJKoZIhvcNAQkEMRYEFO/qsLWd2y86iBMV7RfYw7kH
QNhNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAPk6YWOmiNTFCglT0LzE2kGDQ
m28ckUlKapifpJT7mklGthxwYW814JHPMhfGIj8/rFf3Hm0cNxWlf4CkA1zfOYJGpeVxc9Zr
wM0XthKLKkLCMkODO3KG/YhfjkoDPak3jVlBHtOXFjH8s9AquI8grnexbni/32tNcV28CiY6
NczcElafd0fIdP+vtH3mXYWQHMaT3hvqlxMHW6YLbojaZsZiDN2sqtHGzS2QQ2sV+EvEx5EB
CfiMFgJe7lTtXH7xgue9HNnoTqpBvu+dA7kAVoSmxwXvQW6tpRHOCuXdJamuXXMER830KJkM
3+X3/rut9d6GPT5ZES5hOCcJhmnlMAAAAAAAAA==
--------------ms090609060607050702060702--


--===============8118805497940573605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8118805497940573605==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 09:58:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 09: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 1U3kib-00088y-DA; Fri, 08 Feb 2013 09:58:05 +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 1U3kia-00088t-93
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 09:58:04 +0000
Received: from [85.158.139.211:6299] by server-14.bemta-5.messagelabs.com id
	EA/3B-06967-B2CC4115; Fri, 08 Feb 2013 09:58:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360317482!20534643!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21495 invoked from network); 8 Feb 2013 09:58:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 09:58:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 09:58:02 +0000
Message-Id: <5114DA3A02000078000BD1FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 09:58:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDBEB933A.2__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xiantao.zhang@intel.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartDBEB933A.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> A regression was reported on a class of broken firmware that c/s
> 26517:601139e2b0db didn't consider, leading to a boot time crash.

After some more thought on this and the comments we got
regarding disabling the IOMMU in this situation altogether making
things worse instead of better, I came to the conclusion that we
can actually restrict the action in affected cases to just disabling
interrupt remapping. That doesn't make the situation worse than
prior to the XSA-36 fixes (where interrupt remapping didn't really
protect domains from one another), but allows at least DMA
isolation to still be utilized. Patch 3/2 below/attached.

Jan

AMD IOMMU: only disable interrupt remapping when certain IVRS consistency =
checks fail

After some more thought on the XSA-36 and specifically the comments we
got regarding disabling the IOMMU in this situation altogether making
things worse instead of better, I came to the conclusion that we can
actually restrict the action in affected cases to just disabling
interrupt remapping. That doesn't make the situation worse than prior
to the XSA-36 fixes (where interrupt remapping didn't really protect
domains from one another), but allows at least DMA isolation to still
be utilized.

In the course of this, the calls to the interrupt remapping related
IOMMU implementation specific operations needed to be re-qualified
from depending on iommu_enabled to iommu_intremap (as was already the
case for x86's HPET code).

That in turn required to make sure iommu_intremap gets properly
cleared when the respective initialization fails (or isn't being
done at all).

Along with making sure interrupt remapping doesn't get inconsistently
enabled on some IOMMUs and not on others in the VT-d code, this in turn
allowed quite a bit of cleanup on the VT-d side (if desired, that
cleanup could of course be broken out into a separate patch).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc
         BUG();
     }
=20
-    if ( iommu_enabled )
+    if ( iommu_intremap )
         iommu_read_msi_from_ire(entry, msg);
 }
=20
@@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des
 {
     entry->msg =3D *msg;
=20
-    if ( iommu_enabled )
+    if ( iommu_intremap )
     {
         ASSERT(msg !=3D &entry->msg);
         iommu_update_ire_from_msi(entry, msg);
@@ -489,7 +489,7 @@ int msi_free_irq(struct msi_desc *entry)
     }
=20
     /* Free the unused IRTE if intr remap enabled */
-    if ( iommu_enabled )
+    if ( iommu_intremap )
         iommu_update_ire_from_msi(entry, NULL);
=20
     list_del(&entry->list);
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -682,10 +682,10 @@ static u16 __init parse_ivhd_device_spec
                     printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC =
%#x entries\n",
                            special->handle);
                     if ( amd_iommu_perdev_intremap )
-                        return 0;
+                        iommu_intremap =3D 0;
                 }
             }
-            else
+            else if ( iommu_intremap )
             {
                 /* set device id of ioapic */
                 ioapic_sbdf[special->handle].bdf =3D bdf;
@@ -697,7 +697,7 @@ static u16 __init parse_ivhd_device_spec
                      !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
                 {
                     printk(XENLOG_ERR "IVHD Error: Out of memory\n");
-                    return 0;
+                    iommu_intremap =3D 0;
                 }
             }
             break;
@@ -706,7 +706,7 @@ static u16 __init parse_ivhd_device_spec
         {
             printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
                    special->handle);
-            return 0;
+            iommu_intremap =3D 0;
         }
         break;
     case ACPI_IVHD_HPET:
@@ -932,7 +932,7 @@ static int __init parse_ivrs_table(struc
         printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
                IO_APIC_ID(apic));
         if ( amd_iommu_perdev_intremap )
-            error =3D -ENXIO;
+            iommu_intremap =3D 0;
         else
         {
             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =3D xzalloc_array(
@@ -940,7 +940,7 @@ static int __init parse_ivrs_table(struc
             if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
             {
                 printk(XENLOG_ERR "IVHD Error: Out of memory\n");
-                error =3D -ENOMEM;
+                iommu_intremap =3D 0;
             }
         }
     }
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)
     BUG_ON( !iommu_found() );
=20
     if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
-        goto error_out;
+        iommu_intremap =3D 0;
=20
     ivrs_bdf_entries =3D amd_iommu_get_ivrs_dev_entries();
=20
@@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)
         goto error_out;
=20
     /* initialize io-apic interrupt remapping entries */
-    if ( amd_iommu_setup_ioapic_remapping() !=3D 0 )
+    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() !=3D 0 )
         goto error_out;
=20
     /* allocate and initialize a global device table shared by all iommus =
*/
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -470,6 +470,8 @@ int __init iommu_setup(void)
         rc =3D iommu_hardware_setup();
         iommu_enabled =3D (rc =3D=3D 0);
     }
+    if ( !iommu_enabled )
+        iommu_intremap =3D 0;
=20
     if ( (force_iommu && !iommu_enabled) ||
          (force_intremap && !iommu_intremap) )
@@ -487,6 +489,7 @@ int __init iommu_setup(void)
         printk(" - Dom0 mode: %s\n",
                iommu_passthrough ? "Passthrough" :
                iommu_dom0_strict ? "Strict" : "Relaxed");
+    printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" : =
"dis");
=20
     return rc;
 }
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -373,7 +373,7 @@ unsigned int io_apic_read_remap_rte(
     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
+    if ( !ir_ctrl->iremap_num ||
         ( (index =3D apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
         return __io_apic_read(apic, reg);
=20
@@ -396,15 +396,8 @@ void io_apic_write_remap_rte(
     struct IO_APIC_route_remap_entry *remap_rte;
     unsigned int rte_upper =3D (reg & 1) ? 1 : 0;
     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));
-    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
     int saved_mask;
=20
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
-    {
-        __io_apic_write(apic, reg, value);
-        return;
-    }
-
     old_rte =3D __ioapic_read_entry(apic, ioapic_pin, 1);
=20
     remap_rte =3D (struct IO_APIC_route_remap_entry *) &old_rte;
@@ -653,20 +646,11 @@ void msi_msg_read_remap_rte(
 {
     struct pci_dev *pdev =3D msi_desc->dev;
     struct acpi_drhd_unit *drhd =3D NULL;
-    struct iommu *iommu =3D NULL;
-    struct ir_ctrl *ir_ctrl;
=20
     drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
                 : hpet_to_drhd(msi_desc->hpet_id);
-    if ( !drhd )
-        return;
-    iommu =3D drhd->iommu;
-
-    ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
-        return;
-
-    remap_entry_to_msi_msg(iommu, msg);
+    if ( drhd )
+        remap_entry_to_msi_msg(drhd->iommu, msg);
 }
=20
 void msi_msg_write_remap_rte(
@@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(
 {
     struct pci_dev *pdev =3D msi_desc->dev;
     struct acpi_drhd_unit *drhd =3D NULL;
-    struct iommu *iommu =3D NULL;
-    struct ir_ctrl *ir_ctrl;
=20
     drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
                 : hpet_to_drhd(msi_desc->hpet_id);
-    if ( !drhd )
-        return;
-    iommu =3D drhd->iommu;
-
-    ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
-        return;
-
-    msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
+    if ( drhd )
+        msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg);
 }
=20
 int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2065,6 +2065,9 @@ static int init_vtd_hw(void)
                 break;
             }
         }
+        if ( !iommu_intremap )
+            for_each_drhd_unit ( drhd )
+                disable_intremap(drhd->iommu);
     }
=20
     /*
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -129,7 +129,7 @@ struct IO_APIC_route_entry {
 extern struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
=20
 /* Only need to remap ioapic RTE (reg: 10~3Fh) */
-#define ioapic_reg_remapped(reg) (iommu_enabled && ((reg) >=3D 0x10))
+#define ioapic_reg_remapped(reg) (iommu_intremap && ((reg) >=3D 0x10))
=20
 static inline unsigned int __io_apic_read(unsigned int apic, unsigned int =
reg)
 {



--=__PartDBEB933A.2__=
Content-Type: text/plain; name="AMD-IOMMU-disable-intremap-only.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-disable-intremap-only.patch"

AMD IOMMU: only disable interrupt remapping when certain IVRS consistency =
checks fail=0A=0AAfter some more thought on the XSA-36 and specifically =
the comments we=0Agot regarding disabling the IOMMU in this situation =
altogether making=0Athings worse instead of better, I came to the =
conclusion that we can=0Aactually restrict the action in affected cases to =
just disabling=0Ainterrupt remapping. That doesn't make the situation =
worse than prior=0Ato the XSA-36 fixes (where interrupt remapping didn't =
really protect=0Adomains from one another), but allows at least DMA =
isolation to still=0Abe utilized.=0A=0AIn the course of this, the calls to =
the interrupt remapping related=0AIOMMU implementation specific operations =
needed to be re-qualified=0Afrom depending on iommu_enabled to iommu_intrem=
ap (as was already the=0Acase for x86's HPET code).=0A=0AThat in turn =
required to make sure iommu_intremap gets properly=0Acleared when the =
respective initialization fails (or isn't being=0Adone at all).=0A=0AAlong =
with making sure interrupt remapping doesn't get inconsistently=0Aenabled =
on some IOMMUs and not on others in the VT-d code, this in turn=0Aallowed =
quite a bit of cleanup on the VT-d side (if desired, that=0Acleanup could =
of course be broken out into a separate patch).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/=
x86/msi.c=0A@@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc=0A=
         BUG();=0A     }=0A =0A-    if ( iommu_enabled )=0A+    if ( =
iommu_intremap )=0A         iommu_read_msi_from_ire(entry, msg);=0A }=0A =
=0A@@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des=0A {=0A    =
 entry->msg =3D *msg;=0A =0A-    if ( iommu_enabled )=0A+    if ( =
iommu_intremap )=0A     {=0A         ASSERT(msg !=3D &entry->msg);=0A      =
   iommu_update_ire_from_msi(entry, msg);=0A@@ -489,7 +489,7 @@ int =
msi_free_irq(struct msi_desc *entry)=0A     }=0A =0A     /* Free the =
unused IRTE if intr remap enabled */=0A-    if ( iommu_enabled )=0A+    if =
( iommu_intremap )=0A         iommu_update_ire_from_msi(entry, NULL);=0A =
=0A     list_del(&entry->list);=0A--- a/xen/drivers/passthrough/amd/iommu_a=
cpi.c=0A+++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -682,10 =
+682,10 @@ static u16 __init parse_ivhd_device_spec=0A                     =
printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n",=0A      =
                      special->handle);=0A                     if ( =
amd_iommu_perdev_intremap )=0A-                        return 0;=0A+       =
                 iommu_intremap =3D 0;=0A                 }=0A             =
}=0A-            else=0A+            else if ( iommu_intremap )=0A         =
    {=0A                 /* set device id of ioapic */=0A                 =
ioapic_sbdf[special->handle].bdf =3D bdf;=0A@@ -697,7 +697,7 @@ static u16 =
__init parse_ivhd_device_spec=0A                      !ioapic_sbdf[IO_APIC_=
ID(apic)].pin_setup )=0A                 {=0A                     =
printk(XENLOG_ERR "IVHD Error: Out of memory\n");=0A-                    =
return 0;=0A+                    iommu_intremap =3D 0;=0A                 =
}=0A             }=0A             break;=0A@@ -706,7 +706,7 @@ static u16 =
__init parse_ivhd_device_spec=0A         {=0A             printk(XENLOG_ERR=
 "IVHD Error: Invalid IO-APIC %#x\n",=0A                    special->handle=
);=0A-            return 0;=0A+            iommu_intremap =3D 0;=0A        =
 }=0A         break;=0A     case ACPI_IVHD_HPET:=0A@@ -932,7 +932,7 @@ =
static int __init parse_ivrs_table(struc=0A         printk(XENLOG_ERR =
"IVHD Error: no information for IO-APIC %#x\n",=0A                =
IO_APIC_ID(apic));=0A         if ( amd_iommu_perdev_intremap )=0A-         =
   error =3D -ENXIO;=0A+            iommu_intremap =3D 0;=0A         =
else=0A         {=0A             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =
=3D xzalloc_array(=0A@@ -940,7 +940,7 @@ static int __init parse_ivrs_table=
(struc=0A             if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )=0A   =
          {=0A                 printk(XENLOG_ERR "IVHD Error: Out of =
memory\n");=0A-                error =3D -ENOMEM;=0A+                =
iommu_intremap =3D 0;=0A             }=0A         }=0A     }=0A--- =
a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/=
amd/iommu_init.c=0A@@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)=0A=
     BUG_ON( !iommu_found() );=0A =0A     if ( amd_iommu_perdev_intremap =
&& amd_sp5100_erratum28() )=0A-        goto error_out;=0A+        =
iommu_intremap =3D 0;=0A =0A     ivrs_bdf_entries =3D amd_iommu_get_ivrs_de=
v_entries();=0A =0A@@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)=0A=
         goto error_out;=0A =0A     /* initialize io-apic interrupt =
remapping entries */=0A-    if ( amd_iommu_setup_ioapic_remapping() !=3D 0 =
)=0A+    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() !=3D 0 =
)=0A         goto error_out;=0A =0A     /* allocate and initialize a =
global device table shared by all iommus */=0A--- a/xen/drivers/passthrough=
/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -470,6 +470,8 @@ int =
__init iommu_setup(void)=0A         rc =3D iommu_hardware_setup();=0A      =
   iommu_enabled =3D (rc =3D=3D 0);=0A     }=0A+    if ( !iommu_enabled =
)=0A+        iommu_intremap =3D 0;=0A =0A     if ( (force_iommu && =
!iommu_enabled) ||=0A          (force_intremap && !iommu_intremap) )=0A@@ =
-487,6 +489,7 @@ int __init iommu_setup(void)=0A         printk(" - Dom0 =
mode: %s\n",=0A                iommu_passthrough ? "Passthrough" :=0A      =
          iommu_dom0_strict ? "Strict" : "Relaxed");=0A+    printk("Interru=
pt remapping %sabled\n", iommu_intremap ? "en" : "dis");=0A =0A     return =
rc;=0A }=0A--- a/xen/drivers/passthrough/vtd/intremap.c=0A+++ b/xen/drivers=
/passthrough/vtd/intremap.c=0A@@ -373,7 +373,7 @@ unsigned int io_apic_read=
_remap_rte(=0A     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic)=
);=0A     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A-    if =
( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||=0A+    if =
( !ir_ctrl->iremap_num ||=0A         ( (index =3D apic_pin_2_ir_idx[apic][i=
oapic_pin]) < 0 ) )=0A         return __io_apic_read(apic, reg);=0A =0A@@ =
-396,15 +396,8 @@ void io_apic_write_remap_rte(=0A     struct IO_APIC_route=
_remap_entry *remap_rte;=0A     unsigned int rte_upper =3D (reg & 1) ? 1 : =
0;=0A     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));=0A-   =
 struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A     int saved_mask;=
=0A =0A-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A-    {=0A-        =
__io_apic_write(apic, reg, value);=0A-        return;=0A-    }=0A-=0A     =
old_rte =3D __ioapic_read_entry(apic, ioapic_pin, 1);=0A =0A     remap_rte =
=3D (struct IO_APIC_route_remap_entry *) &old_rte;=0A@@ -653,20 +646,11 @@ =
void msi_msg_read_remap_rte(=0A {=0A     struct pci_dev *pdev =3D =
msi_desc->dev;=0A     struct acpi_drhd_unit *drhd =3D NULL;=0A-    struct =
iommu *iommu =3D NULL;=0A-    struct ir_ctrl *ir_ctrl;=0A =0A     drhd =3D =
pdev ? acpi_find_matched_drhd_unit(pdev)=0A                 : hpet_to_drhd(=
msi_desc->hpet_id);=0A-    if ( !drhd )=0A-        return;=0A-    iommu =
=3D drhd->iommu;=0A-=0A-    ir_ctrl =3D iommu_ir_ctrl(iommu);=0A-    if ( =
!ir_ctrl || !ir_ctrl->iremap_maddr )=0A-        return;=0A-=0A-    =
remap_entry_to_msi_msg(iommu, msg);=0A+    if ( drhd )=0A+        =
remap_entry_to_msi_msg(drhd->iommu, msg);=0A }=0A =0A void msi_msg_write_re=
map_rte(=0A@@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(=0A {=0A     =
struct pci_dev *pdev =3D msi_desc->dev;=0A     struct acpi_drhd_unit *drhd =
=3D NULL;=0A-    struct iommu *iommu =3D NULL;=0A-    struct ir_ctrl =
*ir_ctrl;=0A =0A     drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)=0A  =
               : hpet_to_drhd(msi_desc->hpet_id);=0A-    if ( !drhd )=0A-  =
      return;=0A-    iommu =3D drhd->iommu;=0A-=0A-    ir_ctrl =3D =
iommu_ir_ctrl(iommu);=0A-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A- =
       return;=0A-=0A-    msi_msg_to_remap_entry(iommu, pdev, msi_desc, =
msg);=0A+    if ( drhd )=0A+        msi_msg_to_remap_entry(drhd->iommu, =
pdev, msi_desc, msg);=0A }=0A =0A int __init intel_setup_hpet_msi(struct =
msi_desc *msi_desc)=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ =
b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -2065,6 +2065,9 @@ static int =
init_vtd_hw(void)=0A                 break;=0A             }=0A         =
}=0A+        if ( !iommu_intremap )=0A+            for_each_drhd_unit ( =
drhd )=0A+                disable_intremap(drhd->iommu);=0A     }=0A =0A   =
  /*=0A--- a/xen/include/asm-x86/io_apic.h=0A+++ b/xen/include/asm-x86/io_a=
pic.h=0A@@ -129,7 +129,7 @@ struct IO_APIC_route_entry {=0A extern struct =
mpc_config_ioapic mp_ioapics[MAX_IO_APICS];=0A =0A /* Only need to remap =
ioapic RTE (reg: 10~3Fh) */=0A-#define ioapic_reg_remapped(reg) (iommu_enab=
led && ((reg) >=3D 0x10))=0A+#define ioapic_reg_remapped(reg) (iommu_intrem=
ap && ((reg) >=3D 0x10))=0A =0A static inline unsigned int __io_apic_read(u=
nsigned int apic, unsigned int reg)=0A {=0A
--=__PartDBEB933A.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartDBEB933A.2__=--


From xen-devel-bounces@lists.xen.org Fri Feb 08 09:58:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 09: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 1U3kib-00088y-DA; Fri, 08 Feb 2013 09:58:05 +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 1U3kia-00088t-93
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 09:58:04 +0000
Received: from [85.158.139.211:6299] by server-14.bemta-5.messagelabs.com id
	EA/3B-06967-B2CC4115; Fri, 08 Feb 2013 09:58:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360317482!20534643!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21495 invoked from network); 8 Feb 2013 09:58:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 09:58:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 09:58:02 +0000
Message-Id: <5114DA3A02000078000BD1FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 09:58:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDBEB933A.2__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xiantao.zhang@intel.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartDBEB933A.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> A regression was reported on a class of broken firmware that c/s
> 26517:601139e2b0db didn't consider, leading to a boot time crash.

After some more thought on this and the comments we got
regarding disabling the IOMMU in this situation altogether making
things worse instead of better, I came to the conclusion that we
can actually restrict the action in affected cases to just disabling
interrupt remapping. That doesn't make the situation worse than
prior to the XSA-36 fixes (where interrupt remapping didn't really
protect domains from one another), but allows at least DMA
isolation to still be utilized. Patch 3/2 below/attached.

Jan

AMD IOMMU: only disable interrupt remapping when certain IVRS consistency =
checks fail

After some more thought on the XSA-36 and specifically the comments we
got regarding disabling the IOMMU in this situation altogether making
things worse instead of better, I came to the conclusion that we can
actually restrict the action in affected cases to just disabling
interrupt remapping. That doesn't make the situation worse than prior
to the XSA-36 fixes (where interrupt remapping didn't really protect
domains from one another), but allows at least DMA isolation to still
be utilized.

In the course of this, the calls to the interrupt remapping related
IOMMU implementation specific operations needed to be re-qualified
from depending on iommu_enabled to iommu_intremap (as was already the
case for x86's HPET code).

That in turn required to make sure iommu_intremap gets properly
cleared when the respective initialization fails (or isn't being
done at all).

Along with making sure interrupt remapping doesn't get inconsistently
enabled on some IOMMUs and not on others in the VT-d code, this in turn
allowed quite a bit of cleanup on the VT-d side (if desired, that
cleanup could of course be broken out into a separate patch).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc
         BUG();
     }
=20
-    if ( iommu_enabled )
+    if ( iommu_intremap )
         iommu_read_msi_from_ire(entry, msg);
 }
=20
@@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des
 {
     entry->msg =3D *msg;
=20
-    if ( iommu_enabled )
+    if ( iommu_intremap )
     {
         ASSERT(msg !=3D &entry->msg);
         iommu_update_ire_from_msi(entry, msg);
@@ -489,7 +489,7 @@ int msi_free_irq(struct msi_desc *entry)
     }
=20
     /* Free the unused IRTE if intr remap enabled */
-    if ( iommu_enabled )
+    if ( iommu_intremap )
         iommu_update_ire_from_msi(entry, NULL);
=20
     list_del(&entry->list);
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -682,10 +682,10 @@ static u16 __init parse_ivhd_device_spec
                     printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC =
%#x entries\n",
                            special->handle);
                     if ( amd_iommu_perdev_intremap )
-                        return 0;
+                        iommu_intremap =3D 0;
                 }
             }
-            else
+            else if ( iommu_intremap )
             {
                 /* set device id of ioapic */
                 ioapic_sbdf[special->handle].bdf =3D bdf;
@@ -697,7 +697,7 @@ static u16 __init parse_ivhd_device_spec
                      !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
                 {
                     printk(XENLOG_ERR "IVHD Error: Out of memory\n");
-                    return 0;
+                    iommu_intremap =3D 0;
                 }
             }
             break;
@@ -706,7 +706,7 @@ static u16 __init parse_ivhd_device_spec
         {
             printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
                    special->handle);
-            return 0;
+            iommu_intremap =3D 0;
         }
         break;
     case ACPI_IVHD_HPET:
@@ -932,7 +932,7 @@ static int __init parse_ivrs_table(struc
         printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
                IO_APIC_ID(apic));
         if ( amd_iommu_perdev_intremap )
-            error =3D -ENXIO;
+            iommu_intremap =3D 0;
         else
         {
             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =3D xzalloc_array(
@@ -940,7 +940,7 @@ static int __init parse_ivrs_table(struc
             if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
             {
                 printk(XENLOG_ERR "IVHD Error: Out of memory\n");
-                error =3D -ENOMEM;
+                iommu_intremap =3D 0;
             }
         }
     }
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)
     BUG_ON( !iommu_found() );
=20
     if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
-        goto error_out;
+        iommu_intremap =3D 0;
=20
     ivrs_bdf_entries =3D amd_iommu_get_ivrs_dev_entries();
=20
@@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)
         goto error_out;
=20
     /* initialize io-apic interrupt remapping entries */
-    if ( amd_iommu_setup_ioapic_remapping() !=3D 0 )
+    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() !=3D 0 )
         goto error_out;
=20
     /* allocate and initialize a global device table shared by all iommus =
*/
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -470,6 +470,8 @@ int __init iommu_setup(void)
         rc =3D iommu_hardware_setup();
         iommu_enabled =3D (rc =3D=3D 0);
     }
+    if ( !iommu_enabled )
+        iommu_intremap =3D 0;
=20
     if ( (force_iommu && !iommu_enabled) ||
          (force_intremap && !iommu_intremap) )
@@ -487,6 +489,7 @@ int __init iommu_setup(void)
         printk(" - Dom0 mode: %s\n",
                iommu_passthrough ? "Passthrough" :
                iommu_dom0_strict ? "Strict" : "Relaxed");
+    printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" : =
"dis");
=20
     return rc;
 }
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -373,7 +373,7 @@ unsigned int io_apic_read_remap_rte(
     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
+    if ( !ir_ctrl->iremap_num ||
         ( (index =3D apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
         return __io_apic_read(apic, reg);
=20
@@ -396,15 +396,8 @@ void io_apic_write_remap_rte(
     struct IO_APIC_route_remap_entry *remap_rte;
     unsigned int rte_upper =3D (reg & 1) ? 1 : 0;
     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));
-    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
     int saved_mask;
=20
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
-    {
-        __io_apic_write(apic, reg, value);
-        return;
-    }
-
     old_rte =3D __ioapic_read_entry(apic, ioapic_pin, 1);
=20
     remap_rte =3D (struct IO_APIC_route_remap_entry *) &old_rte;
@@ -653,20 +646,11 @@ void msi_msg_read_remap_rte(
 {
     struct pci_dev *pdev =3D msi_desc->dev;
     struct acpi_drhd_unit *drhd =3D NULL;
-    struct iommu *iommu =3D NULL;
-    struct ir_ctrl *ir_ctrl;
=20
     drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
                 : hpet_to_drhd(msi_desc->hpet_id);
-    if ( !drhd )
-        return;
-    iommu =3D drhd->iommu;
-
-    ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
-        return;
-
-    remap_entry_to_msi_msg(iommu, msg);
+    if ( drhd )
+        remap_entry_to_msi_msg(drhd->iommu, msg);
 }
=20
 void msi_msg_write_remap_rte(
@@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(
 {
     struct pci_dev *pdev =3D msi_desc->dev;
     struct acpi_drhd_unit *drhd =3D NULL;
-    struct iommu *iommu =3D NULL;
-    struct ir_ctrl *ir_ctrl;
=20
     drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
                 : hpet_to_drhd(msi_desc->hpet_id);
-    if ( !drhd )
-        return;
-    iommu =3D drhd->iommu;
-
-    ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
-        return;
-
-    msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
+    if ( drhd )
+        msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg);
 }
=20
 int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2065,6 +2065,9 @@ static int init_vtd_hw(void)
                 break;
             }
         }
+        if ( !iommu_intremap )
+            for_each_drhd_unit ( drhd )
+                disable_intremap(drhd->iommu);
     }
=20
     /*
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -129,7 +129,7 @@ struct IO_APIC_route_entry {
 extern struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
=20
 /* Only need to remap ioapic RTE (reg: 10~3Fh) */
-#define ioapic_reg_remapped(reg) (iommu_enabled && ((reg) >=3D 0x10))
+#define ioapic_reg_remapped(reg) (iommu_intremap && ((reg) >=3D 0x10))
=20
 static inline unsigned int __io_apic_read(unsigned int apic, unsigned int =
reg)
 {



--=__PartDBEB933A.2__=
Content-Type: text/plain; name="AMD-IOMMU-disable-intremap-only.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-disable-intremap-only.patch"

AMD IOMMU: only disable interrupt remapping when certain IVRS consistency =
checks fail=0A=0AAfter some more thought on the XSA-36 and specifically =
the comments we=0Agot regarding disabling the IOMMU in this situation =
altogether making=0Athings worse instead of better, I came to the =
conclusion that we can=0Aactually restrict the action in affected cases to =
just disabling=0Ainterrupt remapping. That doesn't make the situation =
worse than prior=0Ato the XSA-36 fixes (where interrupt remapping didn't =
really protect=0Adomains from one another), but allows at least DMA =
isolation to still=0Abe utilized.=0A=0AIn the course of this, the calls to =
the interrupt remapping related=0AIOMMU implementation specific operations =
needed to be re-qualified=0Afrom depending on iommu_enabled to iommu_intrem=
ap (as was already the=0Acase for x86's HPET code).=0A=0AThat in turn =
required to make sure iommu_intremap gets properly=0Acleared when the =
respective initialization fails (or isn't being=0Adone at all).=0A=0AAlong =
with making sure interrupt remapping doesn't get inconsistently=0Aenabled =
on some IOMMUs and not on others in the VT-d code, this in turn=0Aallowed =
quite a bit of cleanup on the VT-d side (if desired, that=0Acleanup could =
of course be broken out into a separate patch).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/=
x86/msi.c=0A@@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc=0A=
         BUG();=0A     }=0A =0A-    if ( iommu_enabled )=0A+    if ( =
iommu_intremap )=0A         iommu_read_msi_from_ire(entry, msg);=0A }=0A =
=0A@@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des=0A {=0A    =
 entry->msg =3D *msg;=0A =0A-    if ( iommu_enabled )=0A+    if ( =
iommu_intremap )=0A     {=0A         ASSERT(msg !=3D &entry->msg);=0A      =
   iommu_update_ire_from_msi(entry, msg);=0A@@ -489,7 +489,7 @@ int =
msi_free_irq(struct msi_desc *entry)=0A     }=0A =0A     /* Free the =
unused IRTE if intr remap enabled */=0A-    if ( iommu_enabled )=0A+    if =
( iommu_intremap )=0A         iommu_update_ire_from_msi(entry, NULL);=0A =
=0A     list_del(&entry->list);=0A--- a/xen/drivers/passthrough/amd/iommu_a=
cpi.c=0A+++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -682,10 =
+682,10 @@ static u16 __init parse_ivhd_device_spec=0A                     =
printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n",=0A      =
                      special->handle);=0A                     if ( =
amd_iommu_perdev_intremap )=0A-                        return 0;=0A+       =
                 iommu_intremap =3D 0;=0A                 }=0A             =
}=0A-            else=0A+            else if ( iommu_intremap )=0A         =
    {=0A                 /* set device id of ioapic */=0A                 =
ioapic_sbdf[special->handle].bdf =3D bdf;=0A@@ -697,7 +697,7 @@ static u16 =
__init parse_ivhd_device_spec=0A                      !ioapic_sbdf[IO_APIC_=
ID(apic)].pin_setup )=0A                 {=0A                     =
printk(XENLOG_ERR "IVHD Error: Out of memory\n");=0A-                    =
return 0;=0A+                    iommu_intremap =3D 0;=0A                 =
}=0A             }=0A             break;=0A@@ -706,7 +706,7 @@ static u16 =
__init parse_ivhd_device_spec=0A         {=0A             printk(XENLOG_ERR=
 "IVHD Error: Invalid IO-APIC %#x\n",=0A                    special->handle=
);=0A-            return 0;=0A+            iommu_intremap =3D 0;=0A        =
 }=0A         break;=0A     case ACPI_IVHD_HPET:=0A@@ -932,7 +932,7 @@ =
static int __init parse_ivrs_table(struc=0A         printk(XENLOG_ERR =
"IVHD Error: no information for IO-APIC %#x\n",=0A                =
IO_APIC_ID(apic));=0A         if ( amd_iommu_perdev_intremap )=0A-         =
   error =3D -ENXIO;=0A+            iommu_intremap =3D 0;=0A         =
else=0A         {=0A             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup =
=3D xzalloc_array(=0A@@ -940,7 +940,7 @@ static int __init parse_ivrs_table=
(struc=0A             if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )=0A   =
          {=0A                 printk(XENLOG_ERR "IVHD Error: Out of =
memory\n");=0A-                error =3D -ENOMEM;=0A+                =
iommu_intremap =3D 0;=0A             }=0A         }=0A     }=0A--- =
a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/=
amd/iommu_init.c=0A@@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)=0A=
     BUG_ON( !iommu_found() );=0A =0A     if ( amd_iommu_perdev_intremap =
&& amd_sp5100_erratum28() )=0A-        goto error_out;=0A+        =
iommu_intremap =3D 0;=0A =0A     ivrs_bdf_entries =3D amd_iommu_get_ivrs_de=
v_entries();=0A =0A@@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)=0A=
         goto error_out;=0A =0A     /* initialize io-apic interrupt =
remapping entries */=0A-    if ( amd_iommu_setup_ioapic_remapping() !=3D 0 =
)=0A+    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() !=3D 0 =
)=0A         goto error_out;=0A =0A     /* allocate and initialize a =
global device table shared by all iommus */=0A--- a/xen/drivers/passthrough=
/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -470,6 +470,8 @@ int =
__init iommu_setup(void)=0A         rc =3D iommu_hardware_setup();=0A      =
   iommu_enabled =3D (rc =3D=3D 0);=0A     }=0A+    if ( !iommu_enabled =
)=0A+        iommu_intremap =3D 0;=0A =0A     if ( (force_iommu && =
!iommu_enabled) ||=0A          (force_intremap && !iommu_intremap) )=0A@@ =
-487,6 +489,7 @@ int __init iommu_setup(void)=0A         printk(" - Dom0 =
mode: %s\n",=0A                iommu_passthrough ? "Passthrough" :=0A      =
          iommu_dom0_strict ? "Strict" : "Relaxed");=0A+    printk("Interru=
pt remapping %sabled\n", iommu_intremap ? "en" : "dis");=0A =0A     return =
rc;=0A }=0A--- a/xen/drivers/passthrough/vtd/intremap.c=0A+++ b/xen/drivers=
/passthrough/vtd/intremap.c=0A@@ -373,7 +373,7 @@ unsigned int io_apic_read=
_remap_rte(=0A     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic)=
);=0A     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A-    if =
( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||=0A+    if =
( !ir_ctrl->iremap_num ||=0A         ( (index =3D apic_pin_2_ir_idx[apic][i=
oapic_pin]) < 0 ) )=0A         return __io_apic_read(apic, reg);=0A =0A@@ =
-396,15 +396,8 @@ void io_apic_write_remap_rte(=0A     struct IO_APIC_route=
_remap_entry *remap_rte;=0A     unsigned int rte_upper =3D (reg & 1) ? 1 : =
0;=0A     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));=0A-   =
 struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A     int saved_mask;=
=0A =0A-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A-    {=0A-        =
__io_apic_write(apic, reg, value);=0A-        return;=0A-    }=0A-=0A     =
old_rte =3D __ioapic_read_entry(apic, ioapic_pin, 1);=0A =0A     remap_rte =
=3D (struct IO_APIC_route_remap_entry *) &old_rte;=0A@@ -653,20 +646,11 @@ =
void msi_msg_read_remap_rte(=0A {=0A     struct pci_dev *pdev =3D =
msi_desc->dev;=0A     struct acpi_drhd_unit *drhd =3D NULL;=0A-    struct =
iommu *iommu =3D NULL;=0A-    struct ir_ctrl *ir_ctrl;=0A =0A     drhd =3D =
pdev ? acpi_find_matched_drhd_unit(pdev)=0A                 : hpet_to_drhd(=
msi_desc->hpet_id);=0A-    if ( !drhd )=0A-        return;=0A-    iommu =
=3D drhd->iommu;=0A-=0A-    ir_ctrl =3D iommu_ir_ctrl(iommu);=0A-    if ( =
!ir_ctrl || !ir_ctrl->iremap_maddr )=0A-        return;=0A-=0A-    =
remap_entry_to_msi_msg(iommu, msg);=0A+    if ( drhd )=0A+        =
remap_entry_to_msi_msg(drhd->iommu, msg);=0A }=0A =0A void msi_msg_write_re=
map_rte(=0A@@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(=0A {=0A     =
struct pci_dev *pdev =3D msi_desc->dev;=0A     struct acpi_drhd_unit *drhd =
=3D NULL;=0A-    struct iommu *iommu =3D NULL;=0A-    struct ir_ctrl =
*ir_ctrl;=0A =0A     drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)=0A  =
               : hpet_to_drhd(msi_desc->hpet_id);=0A-    if ( !drhd )=0A-  =
      return;=0A-    iommu =3D drhd->iommu;=0A-=0A-    ir_ctrl =3D =
iommu_ir_ctrl(iommu);=0A-    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A- =
       return;=0A-=0A-    msi_msg_to_remap_entry(iommu, pdev, msi_desc, =
msg);=0A+    if ( drhd )=0A+        msi_msg_to_remap_entry(drhd->iommu, =
pdev, msi_desc, msg);=0A }=0A =0A int __init intel_setup_hpet_msi(struct =
msi_desc *msi_desc)=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ =
b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -2065,6 +2065,9 @@ static int =
init_vtd_hw(void)=0A                 break;=0A             }=0A         =
}=0A+        if ( !iommu_intremap )=0A+            for_each_drhd_unit ( =
drhd )=0A+                disable_intremap(drhd->iommu);=0A     }=0A =0A   =
  /*=0A--- a/xen/include/asm-x86/io_apic.h=0A+++ b/xen/include/asm-x86/io_a=
pic.h=0A@@ -129,7 +129,7 @@ struct IO_APIC_route_entry {=0A extern struct =
mpc_config_ioapic mp_ioapics[MAX_IO_APICS];=0A =0A /* Only need to remap =
ioapic RTE (reg: 10~3Fh) */=0A-#define ioapic_reg_remapped(reg) (iommu_enab=
led && ((reg) >=3D 0x10))=0A+#define ioapic_reg_remapped(reg) (iommu_intrem=
ap && ((reg) >=3D 0x10))=0A =0A static inline unsigned int __io_apic_read(u=
nsigned int apic, unsigned int reg)=0A {=0A
--=__PartDBEB933A.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartDBEB933A.2__=--


From xen-devel-bounces@lists.xen.org Fri Feb 08 10:12:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 10: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 1U3kvm-0000Q5-0F; Fri, 08 Feb 2013 10:11:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U3kvk-0000OB-91
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 10:11:40 +0000
Received: from [85.158.139.83:59291] by server-14.bemta-5.messagelabs.com id
	8E/F0-06967-B5FC4115; Fri, 08 Feb 2013 10:11:39 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360318298!24086932!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1898 invoked from network); 8 Feb 2013 10:11:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 10:11:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1273426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 10:11: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.297.1; Fri, 8 Feb 2013 10:11:38 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U3kvi-0002LC-9O; Fri, 08 Feb 2013
	10:11:38 +0000
Message-ID: <5114CF55.5000303@citrix.com>
Date: Fri, 8 Feb 2013 11:11:33 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
In-Reply-To: <20130205183236.GB5652@konrad-lan.dumpdata.com>
Cc: Milan opath <milan.opath@gmail.com>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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


> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> you are .. ah yes, you are hitting a bug that should be in the stable
> tree fix.
>
> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
>
>    
Thanks Konrad. I've tried your patches, and whilst I have not seen this 
crash in cpuidle_register anymore, the others are still present (in 
build_schedule_domains for example).

I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen 
commandline stops both the xen scheduler and dom0 kernel crashing and 
all works fine - made dozens of succesfull s3 attempts. Was wondering if 
you guys had any thoughts on this? Is the dom0 kernel even supposed to 
cope during s3 in non dom0 vcpu pin case?








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 10:12:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 10: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 1U3kvm-0000Q5-0F; Fri, 08 Feb 2013 10:11:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U3kvk-0000OB-91
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 10:11:40 +0000
Received: from [85.158.139.83:59291] by server-14.bemta-5.messagelabs.com id
	8E/F0-06967-B5FC4115; Fri, 08 Feb 2013 10:11:39 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360318298!24086932!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1898 invoked from network); 8 Feb 2013 10:11:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 10:11:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1273426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 10:11: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.297.1; Fri, 8 Feb 2013 10:11:38 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U3kvi-0002LC-9O; Fri, 08 Feb 2013
	10:11:38 +0000
Message-ID: <5114CF55.5000303@citrix.com>
Date: Fri, 8 Feb 2013 11:11:33 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
In-Reply-To: <20130205183236.GB5652@konrad-lan.dumpdata.com>
Cc: Milan opath <milan.opath@gmail.com>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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


> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> you are .. ah yes, you are hitting a bug that should be in the stable
> tree fix.
>
> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
>
>    
Thanks Konrad. I've tried your patches, and whilst I have not seen this 
crash in cpuidle_register anymore, the others are still present (in 
build_schedule_domains for example).

I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen 
commandline stops both the xen scheduler and dom0 kernel crashing and 
all works fine - made dozens of succesfull s3 attempts. Was wondering if 
you guys had any thoughts on this? Is the dom0 kernel even supposed to 
cope during s3 in non dom0 vcpu pin case?








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:15:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3luk-0002FZ-4B; Fri, 08 Feb 2013 11:14:42 +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 1U3luj-0002FU-GY
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:14:41 +0000
Received: from [85.158.138.51:33407] by server-6.bemta-3.messagelabs.com id
	35/BA-29959-02ED4115; Fri, 08 Feb 2013 11:14:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360322078!21310372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12475 invoked from network); 8 Feb 2013 11:14:39 -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;
	8 Feb 2013 11:14:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="6447305"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:14:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:14:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3luf-0007gM-8Q;
	Fri, 08 Feb 2013 11:14:37 +0000
Date: Fri, 8 Feb 2013 11:14:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rui Guo <firemeteor@users.sourceforge.net>
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Message-ID: <alpine.DEB.2.02.1302081114180.4275@kaball.uk.xensource.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Patch series for IGD 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, 7 Feb 2013, Rui Guo wrote:
> This series contains all the fixes required to produce a working IGD
> passthrough box. All the changes are previously seen in the dev list but
> not yet accepted. Some of them are out-dated and need some reshape.
> 
> Detailed description can be found later in each patch.
> 
> . [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags
> . [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD
> . [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific

All patches look good

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:15:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3luk-0002FZ-4B; Fri, 08 Feb 2013 11:14:42 +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 1U3luj-0002FU-GY
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:14:41 +0000
Received: from [85.158.138.51:33407] by server-6.bemta-3.messagelabs.com id
	35/BA-29959-02ED4115; Fri, 08 Feb 2013 11:14:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360322078!21310372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12475 invoked from network); 8 Feb 2013 11:14:39 -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;
	8 Feb 2013 11:14:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="6447305"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:14:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:14:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3luf-0007gM-8Q;
	Fri, 08 Feb 2013 11:14:37 +0000
Date: Fri, 8 Feb 2013 11:14:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rui Guo <firemeteor@users.sourceforge.net>
In-Reply-To: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
Message-ID: <alpine.DEB.2.02.1302081114180.4275@kaball.uk.xensource.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Patch series for IGD 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, 7 Feb 2013, Rui Guo wrote:
> This series contains all the fixes required to produce a working IGD
> passthrough box. All the changes are previously seen in the dev list but
> not yet accepted. Some of them are out-dated and need some reshape.
> 
> Detailed description can be found later in each patch.
> 
> . [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags
> . [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD
> . [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific

All patches look good

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:20:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:20: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 1U3m0A-0002O2-Qy; Fri, 08 Feb 2013 11:20:18 +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 1U3m08-0002Nf-4Y; Fri, 08 Feb 2013 11:20:16 +0000
Received: from [85.158.137.99:64162] by server-9.bemta-3.messagelabs.com id
	27/85-09484-F6FD4115; Fri, 08 Feb 2013 11:20:15 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360322411!17144239!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14318 invoked from network); 8 Feb 2013 11:20:13 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:20:13 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so687459wic.17
	for <multiple recipients>; Fri, 08 Feb 2013 03:20:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=VRQcMOK1Afb74oWTx6brw+0Ed6v3Jwrorpa+iSWQAz4=;
	b=uPExF7Re9pn0ZiJCZnFE6X6czW2l815lT8yzUvczV+7CbTWWvhg26W2xIuOCliUgwc
	jLEvpFD7dfGJraRa9KQWE/EydAeflMrYosnbUewZMc5P/biKerAu1egcZbDzpzzBBUcs
	g70gSjqBtYXpmaOWSXz7s3ag3ZLYeKpBwSXPfcRPaduKRCogBvfIlMgZOWRCtqotmYQw
	dfVq95Tg6B6hUX10AGqqrFwGN2FbAH4kCfZQZGnKRXTnnAh+4CDk4g/X6c3t19uDYEAt
	6EEQyPGTwDrSLSuPQ6k3L6M4r3GawZgZXJFNsVjaEkYYGy3sZOyVOON9uD50EDnYb0YX
	/I/Q==
X-Received: by 10.180.84.199 with SMTP id b7mr1738635wiz.22.1360322410057;
	Fri, 08 Feb 2013 03:20:10 -0800 (PST)
Received: from [172.16.26.11] ([151.225.33.147])
	by mx.google.com with ESMTPS id b10sm13661943wix.7.2013.02.08.03.20.07
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 08 Feb 2013 03:20:08 -0800 (PST)
Message-ID: <5114DF66.5090409@xen.org>
Date: Fri, 08 Feb 2013 11:20:06 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-arm@lists.xen.org, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Vote] Formal vote for Mirage to be accepted as Xen.org
 Incubation Project (deadliner Feb 15th)
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,

after the initial positive community review of the 
http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal, it is time 
to have a formal vote.

Who can vote?
- Project leads of Mature Xen.org projects
- Committers of Mature Xen.org projects
- Others can register their vote in support of the project, but the vote 
is not binding.

How to vote?
- Vote via the voting form at 
http://xen.org/polls/mirage_incubation_proposal.html

Deadline?
- Friday Feb 15th, 23:55 GMT
- Or before Feb 15th (i.e. when all eligible community members have cast 
their vote)

What happens next?
If accepted, I will work with the Mirage project lead on a detailed plan 
for the Incubation phase.

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 Fri Feb 08 11:20:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:20: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 1U3m0A-0002O2-Qy; Fri, 08 Feb 2013 11:20:18 +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 1U3m08-0002Nf-4Y; Fri, 08 Feb 2013 11:20:16 +0000
Received: from [85.158.137.99:64162] by server-9.bemta-3.messagelabs.com id
	27/85-09484-F6FD4115; Fri, 08 Feb 2013 11:20:15 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360322411!17144239!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14318 invoked from network); 8 Feb 2013 11:20:13 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:20:13 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so687459wic.17
	for <multiple recipients>; Fri, 08 Feb 2013 03:20:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=VRQcMOK1Afb74oWTx6brw+0Ed6v3Jwrorpa+iSWQAz4=;
	b=uPExF7Re9pn0ZiJCZnFE6X6czW2l815lT8yzUvczV+7CbTWWvhg26W2xIuOCliUgwc
	jLEvpFD7dfGJraRa9KQWE/EydAeflMrYosnbUewZMc5P/biKerAu1egcZbDzpzzBBUcs
	g70gSjqBtYXpmaOWSXz7s3ag3ZLYeKpBwSXPfcRPaduKRCogBvfIlMgZOWRCtqotmYQw
	dfVq95Tg6B6hUX10AGqqrFwGN2FbAH4kCfZQZGnKRXTnnAh+4CDk4g/X6c3t19uDYEAt
	6EEQyPGTwDrSLSuPQ6k3L6M4r3GawZgZXJFNsVjaEkYYGy3sZOyVOON9uD50EDnYb0YX
	/I/Q==
X-Received: by 10.180.84.199 with SMTP id b7mr1738635wiz.22.1360322410057;
	Fri, 08 Feb 2013 03:20:10 -0800 (PST)
Received: from [172.16.26.11] ([151.225.33.147])
	by mx.google.com with ESMTPS id b10sm13661943wix.7.2013.02.08.03.20.07
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 08 Feb 2013 03:20:08 -0800 (PST)
Message-ID: <5114DF66.5090409@xen.org>
Date: Fri, 08 Feb 2013 11:20:06 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-arm@lists.xen.org, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Vote] Formal vote for Mirage to be accepted as Xen.org
 Incubation Project (deadliner Feb 15th)
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,

after the initial positive community review of the 
http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal, it is time 
to have a formal vote.

Who can vote?
- Project leads of Mature Xen.org projects
- Committers of Mature Xen.org projects
- Others can register their vote in support of the project, but the vote 
is not binding.

How to vote?
- Vote via the voting form at 
http://xen.org/polls/mirage_incubation_proposal.html

Deadline?
- Friday Feb 15th, 23:55 GMT
- Or before Feb 15th (i.e. when all eligible community members have cast 
their vote)

What happens next?
If accepted, I will work with the Mirage project lead on a detailed plan 
for the Incubation phase.

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 Fri Feb 08 11:25:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3m5J-0002u4-Sb; Fri, 08 Feb 2013 11:25:37 +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 1U3m5I-0002tv-7g; Fri, 08 Feb 2013 11:25:36 +0000
Received: from [85.158.139.83:12900] by server-2.bemta-5.messagelabs.com id
	3D/B9-16911-FA0E4115; Fri, 08 Feb 2013 11:25:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360322726!24416515!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14629 invoked from network); 8 Feb 2013 11:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1276373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:25: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.297.1; Fri, 8 Feb 2013
	11:25:25 +0000
Message-ID: <1360322724.32479.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, Lars Kurth <lars.kurth@xen.org>
Date: Fri, 8 Feb 2013 11:25:24 +0000
In-Reply-To: <1357558616.7989.41.camel@zakaz.uk.xensource.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org>  wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues. i.e. they
> > >>          are discussed and fixed publicly on xen-devel and the fix is
> > >>          checked in in the usual way. There is no embargo or specific
> > >>          announcement. changelog may or may not refer to the security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer builds, and
> > > wouldn't expect to see them used in production environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.

Looks like we have a consensus on this then.

Lars, could you add some words to the doc?

e.g. under "Scope of this process".

This process primarily covers the Xen Hypervisor Project. Vulnerabilties
reported against other Xen.org projects will be handled on a best effort
basis by the relevant Project Lead together with the security team.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:25:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3m5J-0002u4-Sb; Fri, 08 Feb 2013 11:25:37 +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 1U3m5I-0002tv-7g; Fri, 08 Feb 2013 11:25:36 +0000
Received: from [85.158.139.83:12900] by server-2.bemta-5.messagelabs.com id
	3D/B9-16911-FA0E4115; Fri, 08 Feb 2013 11:25:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360322726!24416515!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14629 invoked from network); 8 Feb 2013 11:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1276373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:25: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.297.1; Fri, 8 Feb 2013
	11:25:25 +0000
Message-ID: <1360322724.32479.159.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, Lars Kurth <lars.kurth@xen.org>
Date: Fri, 8 Feb 2013 11:25:24 +0000
In-Reply-To: <1357558616.7989.41.camel@zakaz.uk.xensource.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org>  wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues. i.e. they
> > >>          are discussed and fixed publicly on xen-devel and the fix is
> > >>          checked in in the usual way. There is no embargo or specific
> > >>          announcement. changelog may or may not refer to the security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer builds, and
> > > wouldn't expect to see them used in production environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.

Looks like we have a consensus on this then.

Lars, could you add some words to the doc?

e.g. under "Scope of this process".

This process primarily covers the Xen Hypervisor Project. Vulnerabilties
reported against other Xen.org projects will be handled on a best effort
basis by the relevant Project Lead together with the security team.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:29:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3m8o-0003BW-Bt; Fri, 08 Feb 2013 11:29: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 1U3m8m-0003BL-MB; Fri, 08 Feb 2013 11:29:12 +0000
Received: from [85.158.143.99:37162] by server-2.bemta-4.messagelabs.com id
	85/17-01597-781E4115; Fri, 08 Feb 2013 11:29:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360322950!18489252!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22282 invoked from network); 8 Feb 2013 11:29:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:29:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1276602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:29: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.297.1; Fri, 8 Feb 2013
	11:29:09 +0000
Message-ID: <1360322948.29432.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, Lars Kurth <lars.kurth@xen.org>
Date: Fri, 8 Feb 2013 11:29:08 +0000
In-Reply-To: <1357558616.7989.41.camel@zakaz.uk.xensource.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org>  wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues. i.e. they
> > >>          are discussed and fixed publicly on xen-devel and the fix is
> > >>          checked in in the usual way. There is no embargo or specific
> > >>          announcement. changelog may or may not refer to the security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer builds, and
> > > wouldn't expect to see them used in production environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.

Looks like we have a consensus on this then.

I'm in two minds about whether this needs to be made explicit in the
vulnerability process.

If it were then e.g. "Scope of this process" could become:

        This process primarily covers the Xen Hypervisor Project and
        covers production configurations only, that is builds without
        debugging features enabled, e.g. debug=y.
        
        Vulnerabilties reported against other Xen.org projects will be
        handled on a best effort basis by the relevant Project Lead
        together with the security team.
        
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:29:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3m8o-0003BW-Bt; Fri, 08 Feb 2013 11:29: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 1U3m8m-0003BL-MB; Fri, 08 Feb 2013 11:29:12 +0000
Received: from [85.158.143.99:37162] by server-2.bemta-4.messagelabs.com id
	85/17-01597-781E4115; Fri, 08 Feb 2013 11:29:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360322950!18489252!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22282 invoked from network); 8 Feb 2013 11:29:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:29:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1276602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:29: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.297.1; Fri, 8 Feb 2013
	11:29:09 +0000
Message-ID: <1360322948.29432.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>, Lars Kurth <lars.kurth@xen.org>
Date: Fri, 8 Feb 2013 11:29:08 +0000
In-Reply-To: <1357558616.7989.41.camel@zakaz.uk.xensource.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org>  wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues. i.e. they
> > >>          are discussed and fixed publicly on xen-devel and the fix is
> > >>          checked in in the usual way. There is no embargo or specific
> > >>          announcement. changelog may or may not refer to the security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer builds, and
> > > wouldn't expect to see them used in production environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.

Looks like we have a consensus on this then.

I'm in two minds about whether this needs to be made explicit in the
vulnerability process.

If it were then e.g. "Scope of this process" could become:

        This process primarily covers the Xen Hypervisor Project and
        covers production configurations only, that is builds without
        debugging features enabled, e.g. debug=y.
        
        Vulnerabilties reported against other Xen.org projects will be
        handled on a best effort basis by the relevant Project Lead
        together with the security team.
        
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:29:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3m9A-0003Dw-GY; Fri, 08 Feb 2013 11:29: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 1U3m98-0003DM-IJ; Fri, 08 Feb 2013 11:29:34 +0000
Received: from [85.158.138.51:39448] by server-15.bemta-3.messagelabs.com id
	B2/34-25405-D91E4115; Fri, 08 Feb 2013 11:29:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360322972!24278457!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23188 invoked from network); 8 Feb 2013 11:29:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:29:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1276636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:29: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.297.1; Fri, 8 Feb 2013
	11:29:32 +0000
Message-ID: <1360322971.29432.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Fri, 8 Feb 2013 11:29:31 +0000
In-Reply-To: <1360322724.32479.159.camel@zakaz.uk.xensource.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
	<1360322724.32479.159.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, Lars Kurth <lars.kurth@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ignore this one, hit send too soon.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:29:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3m9A-0003Dw-GY; Fri, 08 Feb 2013 11:29: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 1U3m98-0003DM-IJ; Fri, 08 Feb 2013 11:29:34 +0000
Received: from [85.158.138.51:39448] by server-15.bemta-3.messagelabs.com id
	B2/34-25405-D91E4115; Fri, 08 Feb 2013 11:29:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360322972!24278457!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23188 invoked from network); 8 Feb 2013 11:29:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:29:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,628,1355097600"; 
   d="scan'208";a="1276636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:29: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.297.1; Fri, 8 Feb 2013
	11:29:32 +0000
Message-ID: <1360322971.29432.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Date: Fri, 8 Feb 2013 11:29:31 +0000
In-Reply-To: <1360322724.32479.159.camel@zakaz.uk.xensource.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
	<1360322724.32479.159.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, Lars Kurth <lars.kurth@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ignore this one, hit send too soon.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:30:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:30: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 1U3mAA-0003V9-3P; Fri, 08 Feb 2013 11:30: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 1U3mA8-0003UP-DP
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:30:36 +0000
Received: from [85.158.139.211:18833] by server-14.bemta-5.messagelabs.com id
	B3/11-06967-BD1E4115; Fri, 08 Feb 2013 11:30:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360323019!20598076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18273 invoked from network); 8 Feb 2013 11:30:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:30:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6781881"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:30:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:30:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3m9q-0007vh-7G;
	Fri, 08 Feb 2013 11:30:18 +0000
Date: Fri, 8 Feb 2013 11:30:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: G.R. <firemeteor@users.sourceforge.net>
In-Reply-To: <CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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, 7 Feb 2013, G.R. wrote:
> >
> > For one I wonder whether this is really _always_ correct. I.e.
> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
> > be better to mirror whatever the host device says?
> >
> >From the Intel driver code, it's looking for an intel ISA bridge.
> So your question would be should it be always at 00:1f.0.
> So far it seems that it is.
> 
> > And then I don't see why you need to open code all of
> > pci_bridge_init() instead of just overriding the class value after
> > you called that function (or, if the order of events for some
> > reason matters, adding another parameter to the function).
> 
> Stefano, could you comment? It's your code after all.

It's not trivial because PCIBus is defined in hw/pci.c, so you can't
dereference members of PCIBus from hw/pt-graphics.c.

However if you come up with a good patch that makes it work, even
better.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:30:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:30: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 1U3mAA-0003V9-3P; Fri, 08 Feb 2013 11:30: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 1U3mA8-0003UP-DP
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:30:36 +0000
Received: from [85.158.139.211:18833] by server-14.bemta-5.messagelabs.com id
	B3/11-06967-BD1E4115; Fri, 08 Feb 2013 11:30:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360323019!20598076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18273 invoked from network); 8 Feb 2013 11:30:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:30:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6781881"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:30:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:30:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3m9q-0007vh-7G;
	Fri, 08 Feb 2013 11:30:18 +0000
Date: Fri, 8 Feb 2013 11:30:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: G.R. <firemeteor@users.sourceforge.net>
In-Reply-To: <CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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, 7 Feb 2013, G.R. wrote:
> >
> > For one I wonder whether this is really _always_ correct. I.e.
> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
> > be better to mirror whatever the host device says?
> >
> >From the Intel driver code, it's looking for an intel ISA bridge.
> So your question would be should it be always at 00:1f.0.
> So far it seems that it is.
> 
> > And then I don't see why you need to open code all of
> > pci_bridge_init() instead of just overriding the class value after
> > you called that function (or, if the order of events for some
> > reason matters, adding another parameter to the function).
> 
> Stefano, could you comment? It's your code after all.

It's not trivial because PCIBus is defined in hw/pci.c, so you can't
dereference members of PCIBus from hw/pt-graphics.c.

However if you come up with a good patch that makes it work, even
better.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:36:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:36: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 1U3mFd-0004Pd-Ug; Fri, 08 Feb 2013 11:36:17 +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 1U3mFc-0004PO-GY
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 11:36:16 +0000
Received: from [85.158.143.99:19082] by server-1.bemta-4.messagelabs.com id
	4A/1A-08839-F23E4115; Fri, 08 Feb 2013 11:36:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360323372!31390168!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13542 invoked from network); 8 Feb 2013 11:36:14 -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;
	8 Feb 2013 11:36:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6449774"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:36:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:36:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3mFX-00081O-H2;
	Fri, 08 Feb 2013 11:36:11 +0000
Date: Fri, 8 Feb 2013 11:36:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fantonifabio@tiscali.it>
In-Reply-To: <510A9566.7030609@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
References: <510A9566.7030609@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl 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

On Thu, 31 Jan 2013, Fabio Fantoni wrote:
> I tested spice vdagent, spice audio and spice usbredirection with qemu
> upstream and xen-unstable manually, is all working.
> I'm start to write some patches to have all spice features on xen 4.3.
> 
> About vdagent probably no problem.
> 
> About spice audio on test I actually set this variable manually:
> 
> export QEMU_AUDIO_DRV=spice
> 
> I need know how to setup this env variable but for a given hvm domU start.
> In other word I need to set this env variable on a per domU basis (if
> spiceaudio if setted in cfg).

Pass it from libxl, after all QEMU is spawned by libxl


> About usb redirection the qemu parameters to add are similar to this:
> 
> 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"]
> 
> Probably is not good point to external generic file (on my test
> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do this?

Add the paramter list to libxl


> About xl cfg parameters can be good add spiceaudio=0|1 and
> spiceusbredirection=0|1 both with default 0?
 
Yes, it looks OK to me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:36:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:36: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 1U3mFd-0004Pd-Ug; Fri, 08 Feb 2013 11:36:17 +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 1U3mFc-0004PO-GY
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 11:36:16 +0000
Received: from [85.158.143.99:19082] by server-1.bemta-4.messagelabs.com id
	4A/1A-08839-F23E4115; Fri, 08 Feb 2013 11:36:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360323372!31390168!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13542 invoked from network); 8 Feb 2013 11:36:14 -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;
	8 Feb 2013 11:36:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6449774"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:36:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:36:11 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3mFX-00081O-H2;
	Fri, 08 Feb 2013 11:36:11 +0000
Date: Fri, 8 Feb 2013 11:36:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fantonifabio@tiscali.it>
In-Reply-To: <510A9566.7030609@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
References: <510A9566.7030609@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl 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

On Thu, 31 Jan 2013, Fabio Fantoni wrote:
> I tested spice vdagent, spice audio and spice usbredirection with qemu
> upstream and xen-unstable manually, is all working.
> I'm start to write some patches to have all spice features on xen 4.3.
> 
> About vdagent probably no problem.
> 
> About spice audio on test I actually set this variable manually:
> 
> export QEMU_AUDIO_DRV=spice
> 
> I need know how to setup this env variable but for a given hvm domU start.
> In other word I need to set this env variable on a per domU basis (if
> spiceaudio if setted in cfg).

Pass it from libxl, after all QEMU is spawned by libxl


> About usb redirection the qemu parameters to add are similar to this:
> 
> 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"]
> 
> Probably is not good point to external generic file (on my test
> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do this?

Add the paramter list to libxl


> About xl cfg parameters can be good add spiceaudio=0|1 and
> spiceusbredirection=0|1 both with default 0?
 
Yes, it looks OK to me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:36:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mFw-0004Sc-Kt; Fri, 08 Feb 2013 11:36: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 1U3mFv-0004SL-Bt
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:36:35 +0000
Received: from [85.158.143.35:61717] by server-2.bemta-4.messagelabs.com id
	7C/82-01597-243E4115; Fri, 08 Feb 2013 11:36:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360323392!5202387!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30637 invoked from network); 8 Feb 2013 11:36:33 -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; 8 Feb 2013 11:36:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 11:36:32 +0000
Message-Id: <5114F15002000078000BD2B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 11:36:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
	<alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "G.R." <firemeteor@users.sourceforge.net>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 08.02.13 at 12:30, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 7 Feb 2013, G.R. wrote:
>> >
>> > For one I wonder whether this is really _always_ correct. I.e.
>> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
>> > be better to mirror whatever the host device says?
>> >
>> >From the Intel driver code, it's looking for an intel ISA bridge.
>> So your question would be should it be always at 00:1f.0.
>> So far it seems that it is.
>> 
>> > And then I don't see why you need to open code all of
>> > pci_bridge_init() instead of just overriding the class value after
>> > you called that function (or, if the order of events for some
>> > reason matters, adding another parameter to the function).
>> 
>> Stefano, could you comment? It's your code after all.
> 
> It's not trivial because PCIBus is defined in hw/pci.c, so you can't
> dereference members of PCIBus from hw/pt-graphics.c.

But the patch makes it so the structure itself becomes public?
What problem do you see?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:36:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mFw-0004Sc-Kt; Fri, 08 Feb 2013 11:36: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 1U3mFv-0004SL-Bt
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:36:35 +0000
Received: from [85.158.143.35:61717] by server-2.bemta-4.messagelabs.com id
	7C/82-01597-243E4115; Fri, 08 Feb 2013 11:36:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360323392!5202387!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30637 invoked from network); 8 Feb 2013 11:36:33 -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; 8 Feb 2013 11:36:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 11:36:32 +0000
Message-Id: <5114F15002000078000BD2B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 11:36:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
	<alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "G.R." <firemeteor@users.sourceforge.net>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 08.02.13 at 12:30, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 7 Feb 2013, G.R. wrote:
>> >
>> > For one I wonder whether this is really _always_ correct. I.e.
>> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
>> > be better to mirror whatever the host device says?
>> >
>> >From the Intel driver code, it's looking for an intel ISA bridge.
>> So your question would be should it be always at 00:1f.0.
>> So far it seems that it is.
>> 
>> > And then I don't see why you need to open code all of
>> > pci_bridge_init() instead of just overriding the class value after
>> > you called that function (or, if the order of events for some
>> > reason matters, adding another parameter to the function).
>> 
>> Stefano, could you comment? It's your code after all.
> 
> It's not trivial because PCIBus is defined in hw/pci.c, so you can't
> dereference members of PCIBus from hw/pt-graphics.c.

But the patch makes it so the structure itself becomes public?
What problem do you see?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:40:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 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 1U3mJZ-0004t0-D4; Fri, 08 Feb 2013 11:40: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 1U3mJY-0004sp-Hf; Fri, 08 Feb 2013 11:40:20 +0000
Received: from [85.158.143.35:40301] by server-3.bemta-4.messagelabs.com id
	A0/1F-08920-324E4115; Fri, 08 Feb 2013 11:40:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360323616!10112188!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28697 invoked from network); 8 Feb 2013 11:40:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 11:40:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 11:40:15 +0000
Message-Id: <5114F22F02000078000BD2C6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 11:40:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Lars Kurth" <lars.kurth@xen.org>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
	<1360322948.29432.0.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360322948.29432.0.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	xen-users <xen-users@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> If it were then e.g. "Scope of this process" could become:
> 
>         This process primarily covers the Xen Hypervisor Project and
>         covers production configurations only, that is builds without
>         debugging features enabled, e.g. debug=y.

To me, with the wording above, the "debug=y" example here is
ambiguous (in that I could read it to mean only "debug=y" is
covered by the process, even if I agree that this makes little
sense).

Jan

>         Vulnerabilties reported against other Xen.org projects will be
>         handled on a best effort basis by the relevant Project Lead
>         together with the security team.
>         
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:40:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 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 1U3mJZ-0004t0-D4; Fri, 08 Feb 2013 11:40: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 1U3mJY-0004sp-Hf; Fri, 08 Feb 2013 11:40:20 +0000
Received: from [85.158.143.35:40301] by server-3.bemta-4.messagelabs.com id
	A0/1F-08920-324E4115; Fri, 08 Feb 2013 11:40:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360323616!10112188!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28697 invoked from network); 8 Feb 2013 11:40:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 11:40:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 11:40:15 +0000
Message-Id: <5114F22F02000078000BD2C6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 11:40:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Lars Kurth" <lars.kurth@xen.org>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
	<1360322948.29432.0.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360322948.29432.0.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	xen-users <xen-users@lists.xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> If it were then e.g. "Scope of this process" could become:
> 
>         This process primarily covers the Xen Hypervisor Project and
>         covers production configurations only, that is builds without
>         debugging features enabled, e.g. debug=y.

To me, with the wording above, the "debug=y" example here is
ambiguous (in that I could read it to mean only "debug=y" is
covered by the process, even if I agree that this makes little
sense).

Jan

>         Vulnerabilties reported against other Xen.org projects will be
>         handled on a best effort basis by the relevant Project Lead
>         together with the security team.
>         
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:42:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mLU-0005PP-Iz; Fri, 08 Feb 2013 11:42:20 +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 1U3mLT-0005Ol-4C
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:42:19 +0000
Received: from [85.158.139.83:5055] by server-9.bemta-5.messagelabs.com id
	11/80-24440-A94E4115; Fri, 08 Feb 2013 11:42:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360323729!24103818!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4436 invoked from network); 8 Feb 2013 11:42:10 -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;
	8 Feb 2013 11:42:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6783827"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:42:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:42:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3mLI-000871-IJ;
	Fri, 08 Feb 2013 11:42:08 +0000
Date: Fri, 8 Feb 2013 11:42:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
In-Reply-To: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302081138310.4275@kaball.uk.xensource.com>
References: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] redirect qemu-dm log to syslog
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 7 Feb 2013, Vasiliy Tolstov wrote:
> I'm search mailing list and can't see any questions and answers...
> Is that possible (and how) to redirect qemu-dm output (stored in
> /var/log/xen/qemu-dm-xxx.log) to syslog and not write to file?

Not easily, unless you find a way to capture QEMU's stdout and stderr
and send it to syslog using an external tool. You can replace the QEMU
binary with a script that spawns QEMU and a syslog logger to do this.

You can also play nasty tricks with preprocessor macros and turn all
QEMU's printf into syslog calls. Of course such a patch wouldn't be
acceptable upstream.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:42:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mLU-0005PP-Iz; Fri, 08 Feb 2013 11:42:20 +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 1U3mLT-0005Ol-4C
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:42:19 +0000
Received: from [85.158.139.83:5055] by server-9.bemta-5.messagelabs.com id
	11/80-24440-A94E4115; Fri, 08 Feb 2013 11:42:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360323729!24103818!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4436 invoked from network); 8 Feb 2013 11:42:10 -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;
	8 Feb 2013 11:42:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6783827"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:42:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:42:08 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3mLI-000871-IJ;
	Fri, 08 Feb 2013 11:42:08 +0000
Date: Fri, 8 Feb 2013 11:42:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
In-Reply-To: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302081138310.4275@kaball.uk.xensource.com>
References: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] redirect qemu-dm log to syslog
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 7 Feb 2013, Vasiliy Tolstov wrote:
> I'm search mailing list and can't see any questions and answers...
> Is that possible (and how) to redirect qemu-dm output (stored in
> /var/log/xen/qemu-dm-xxx.log) to syslog and not write to file?

Not easily, unless you find a way to capture QEMU's stdout and stderr
and send it to syslog using an external tool. You can replace the QEMU
binary with a script that spawns QEMU and a syslog logger to do this.

You can also play nasty tricks with preprocessor macros and turn all
QEMU's printf into syslog calls. Of course such a patch wouldn't be
acceptable upstream.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:47:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mQ3-0005lH-Cn; Fri, 08 Feb 2013 11:47:03 +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 1U3mQ2-0005lA-BG
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:47:02 +0000
Received: from [85.158.143.99:18577] by server-2.bemta-4.messagelabs.com id
	A9/70-01597-5B5E4115; Fri, 08 Feb 2013 11:47:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360324019!25024060!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7940 invoked from network); 8 Feb 2013 11:47:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:47:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6451169"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U3mPq-0008BJ-4E;
	Fri, 08 Feb 2013 11:46:50 +0000
Message-ID: <5114E5A9.4090200@citrix.com>
Date: Fri, 8 Feb 2013 11:46:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
	<alpine.DEB.2.02.1302081138310.4275@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302081138310.4275@kaball.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Vasiliy Tolstov <v.tolstov@selfip.ru>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] redirect qemu-dm log to syslog
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/02/13 11:42, Stefano Stabellini wrote:
> On Thu, 7 Feb 2013, Vasiliy Tolstov wrote:
>> I'm search mailing list and can't see any questions and answers...
>> Is that possible (and how) to redirect qemu-dm output (stored in
>> /var/log/xen/qemu-dm-xxx.log) to syslog and not write to file?
> Not easily, unless you find a way to capture QEMU's stdout and stderr
> and send it to syslog using an external tool. You can replace the QEMU
> binary with a script that spawns QEMU and a syslog logger to do this.
>
> You can also play nasty tricks with preprocessor macros and turn all
> QEMU's printf into syslog calls. Of course such a patch wouldn't be
> acceptable upstream.

This was attempted in XenServer, and is harder than just changing the
printf calls.  In the end we gave up and just wrapped stdout/stderr.

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 11:47:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mQ3-0005lH-Cn; Fri, 08 Feb 2013 11:47:03 +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 1U3mQ2-0005lA-BG
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:47:02 +0000
Received: from [85.158.143.99:18577] by server-2.bemta-4.messagelabs.com id
	A9/70-01597-5B5E4115; Fri, 08 Feb 2013 11:47:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360324019!25024060!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7940 invoked from network); 8 Feb 2013 11:47:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:47:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6451169"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U3mPq-0008BJ-4E;
	Fri, 08 Feb 2013 11:46:50 +0000
Message-ID: <5114E5A9.4090200@citrix.com>
Date: Fri, 8 Feb 2013 11:46:49 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CACaajQs3-tdf32igNOTSdRewd3qbQTAJPUMh87Zwq3zSMkZNGw@mail.gmail.com>
	<alpine.DEB.2.02.1302081138310.4275@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302081138310.4275@kaball.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Vasiliy Tolstov <v.tolstov@selfip.ru>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] redirect qemu-dm log to syslog
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/02/13 11:42, Stefano Stabellini wrote:
> On Thu, 7 Feb 2013, Vasiliy Tolstov wrote:
>> I'm search mailing list and can't see any questions and answers...
>> Is that possible (and how) to redirect qemu-dm output (stored in
>> /var/log/xen/qemu-dm-xxx.log) to syslog and not write to file?
> Not easily, unless you find a way to capture QEMU's stdout and stderr
> and send it to syslog using an external tool. You can replace the QEMU
> binary with a script that spawns QEMU and a syslog logger to do this.
>
> You can also play nasty tricks with preprocessor macros and turn all
> QEMU's printf into syslog calls. Of course such a patch wouldn't be
> acceptable upstream.

This was attempted in XenServer, and is harder than just changing the
printf calls.  In the end we gave up and just wrapped stdout/stderr.

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 11:47:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:47: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 1U3mQO-0005nM-RI; Fri, 08 Feb 2013 11:47: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 1U3mQN-0005n7-ON; Fri, 08 Feb 2013 11:47:23 +0000
Received: from [85.158.143.35:60721] by server-1.bemta-4.messagelabs.com id
	B0/39-08839-BC5E4115; Fri, 08 Feb 2013 11:47:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360324038!11628652!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29367 invoked from network); 8 Feb 2013 11:47:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:47:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="1277344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11: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.297.1; Fri, 8 Feb 2013
	11:47:18 +0000
Message-ID: <1360324037.29432.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 8 Feb 2013 11:47:17 +0000
In-Reply-To: <5114F22F02000078000BD2C6@nat28.tlf.novell.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
	<1360322948.29432.0.camel@zakaz.uk.xensource.com>
	<5114F22F02000078000BD2C6@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	xen-users <xen-users@lists.xen.org>, Lars Kurth <lars.kurth@xen.org>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 11:40 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > If it were then e.g. "Scope of this process" could become:
> > 
> >         This process primarily covers the Xen Hypervisor Project and
> >         covers production configurations only, that is builds without
> >         debugging features enabled, e.g. debug=y.
> 
> To me, with the wording above, the "debug=y" example here is
> ambiguous (in that I could read it to mean only "debug=y" is
> covered by the process, even if I agree that this makes little
> sense).

yes, you are right.

I was trying to avoid having to explicitly list all the options while
also avoiding suggesting that other debug options, like perfc=y or (in
the future) coverage=y, might be supported.

Perhaps
        .... Therefore configurations built with e.g. debug=y are not
        covered by this process.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:47:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11:47: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 1U3mQO-0005nM-RI; Fri, 08 Feb 2013 11:47: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 1U3mQN-0005n7-ON; Fri, 08 Feb 2013 11:47:23 +0000
Received: from [85.158.143.35:60721] by server-1.bemta-4.messagelabs.com id
	B0/39-08839-BC5E4115; Fri, 08 Feb 2013 11:47:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360324038!11628652!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29367 invoked from network); 8 Feb 2013 11:47:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:47:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="1277344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11: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.297.1; Fri, 8 Feb 2013
	11:47:18 +0000
Message-ID: <1360324037.29432.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 8 Feb 2013 11:47:17 +0000
In-Reply-To: <5114F22F02000078000BD2C6@nat28.tlf.novell.com>
References: <CD105D24.56EC3%keir@xen.org> <50EAAFAB.9000904@citrix.com>
	<1357558616.7989.41.camel@zakaz.uk.xensource.com>
	<1360322948.29432.0.camel@zakaz.uk.xensource.com>
	<5114F22F02000078000BD2C6@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	xen-users <xen-users@lists.xen.org>, Lars Kurth <lars.kurth@xen.org>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Security support for debug=y builds (Was Re: Xen
 Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect
 ASSERT (debug build only))
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 11:40 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > If it were then e.g. "Scope of this process" could become:
> > 
> >         This process primarily covers the Xen Hypervisor Project and
> >         covers production configurations only, that is builds without
> >         debugging features enabled, e.g. debug=y.
> 
> To me, with the wording above, the "debug=y" example here is
> ambiguous (in that I could read it to mean only "debug=y" is
> covered by the process, even if I agree that this makes little
> sense).

yes, you are right.

I was trying to avoid having to explicitly list all the options while
also avoiding suggesting that other debug options, like perfc=y or (in
the future) coverage=y, might be supported.

Perhaps
        .... Therefore configurations built with e.g. debug=y are not
        covered by this process.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:49:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mS4-00063j-5l; Fri, 08 Feb 2013 11:49:08 +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 1U3mS2-00063R-GT
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:49:06 +0000
Received: from [85.158.139.83:11757] by server-11.bemta-5.messagelabs.com id
	39/C2-19159-136E4115; Fri, 08 Feb 2013 11:49:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360324143!23418819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17153 invoked from network); 8 Feb 2013 11:49:05 -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;
	8 Feb 2013 11:49:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6784279"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:49:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:49:03 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3mRz-0008E4-37;
	Fri, 08 Feb 2013 11:49:03 +0000
Date: Fri, 8 Feb 2013 11:48:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5114F15002000078000BD2B2@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1302081142350.4275@kaball.uk.xensource.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
	<alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
	<5114F15002000078000BD2B2@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "G.R." <firemeteor@users.sourceforge.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 Fri, 8 Feb 2013, Jan Beulich wrote:
> >>> On 08.02.13 at 12:30, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Thu, 7 Feb 2013, G.R. wrote:
> >> >
> >> > For one I wonder whether this is really _always_ correct. I.e.
> >> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
> >> > be better to mirror whatever the host device says?
> >> >
> >> >From the Intel driver code, it's looking for an intel ISA bridge.
> >> So your question would be should it be always at 00:1f.0.
> >> So far it seems that it is.
> >> 
> >> > And then I don't see why you need to open code all of
> >> > pci_bridge_init() instead of just overriding the class value after
> >> > you called that function (or, if the order of events for some
> >> > reason matters, adding another parameter to the function).
> >> 
> >> Stefano, could you comment? It's your code after all.
> > 
> > It's not trivial because PCIBus is defined in hw/pci.c, so you can't
> > dereference members of PCIBus from hw/pt-graphics.c.
> 
> But the patch makes it so the structure itself becomes public?
> What problem do you see?

QEMU's include chain can be devious at times but I have no objections in
making PCIBus public.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:49:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mS4-00063j-5l; Fri, 08 Feb 2013 11:49:08 +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 1U3mS2-00063R-GT
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 11:49:06 +0000
Received: from [85.158.139.83:11757] by server-11.bemta-5.messagelabs.com id
	39/C2-19159-136E4115; Fri, 08 Feb 2013 11:49:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360324143!23418819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17153 invoked from network); 8 Feb 2013 11:49:05 -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;
	8 Feb 2013 11:49:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6784279"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 11:49:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 06:49:03 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3mRz-0008E4-37;
	Fri, 08 Feb 2013 11:49:03 +0000
Date: Fri, 8 Feb 2013 11:48:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5114F15002000078000BD2B2@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1302081142350.4275@kaball.uk.xensource.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-3-git-send-email-firemeteor@users.sourceforge.net>
	<5113E4C302000078000BCF6B@nat28.tlf.novell.com>
	<CAKhsbWbFz-Qz_rqkty5aq9GRJ0E20FOu4ik4H9+3-q8wDevMpw@mail.gmail.com>
	<alpine.DEB.2.02.1302081124390.4275@kaball.uk.xensource.com>
	<5114F15002000078000BD2B2@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "G.R." <firemeteor@users.sourceforge.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA
 bridge for IGD 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 Fri, 8 Feb 2013, Jan Beulich wrote:
> >>> On 08.02.13 at 12:30, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > On Thu, 7 Feb 2013, G.R. wrote:
> >> >
> >> > For one I wonder whether this is really _always_ correct. I.e.
> >> > the device at 00:1f.0 always being an ISA bridge. Wouldn't it
> >> > be better to mirror whatever the host device says?
> >> >
> >> >From the Intel driver code, it's looking for an intel ISA bridge.
> >> So your question would be should it be always at 00:1f.0.
> >> So far it seems that it is.
> >> 
> >> > And then I don't see why you need to open code all of
> >> > pci_bridge_init() instead of just overriding the class value after
> >> > you called that function (or, if the order of events for some
> >> > reason matters, adding another parameter to the function).
> >> 
> >> Stefano, could you comment? It's your code after all.
> > 
> > It's not trivial because PCIBus is defined in hw/pci.c, so you can't
> > dereference members of PCIBus from hw/pt-graphics.c.
> 
> But the patch makes it so the structure itself becomes public?
> What problem do you see?

QEMU's include chain can be devious at times but I have no objections in
making PCIBus public.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:51:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mTq-0006Ir-O9; Fri, 08 Feb 2013 11:50:58 +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 1U3mTo-0006IP-LU
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 11:50:56 +0000
Received: from [85.158.139.83:61722] by server-13.bemta-5.messagelabs.com id
	98/8B-06769-F96E4115; Fri, 08 Feb 2013 11:50:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360324255!26030996!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19201 invoked from network); 8 Feb 2013 11:50:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:50:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="1277491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:50: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.297.1; Fri, 8 Feb 2013
	11:50:55 +0000
Message-ID: <1360324253.29432.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 8 Feb 2013 11:50:53 +0000
In-Reply-To: <alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Need advice to develop some libxl 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

On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
> > I tested spice vdagent, spice audio and spice usbredirection with qemu
> > upstream and xen-unstable manually, is all working.
> > I'm start to write some patches to have all spice features on xen 4.3.
> > 
> > About vdagent probably no problem.
> > 
> > About spice audio on test I actually set this variable manually:
> > 
> > export QEMU_AUDIO_DRV=spice
> > 
> > I need know how to setup this env variable but for a given hvm domU start.
> > In other word I need to set this env variable on a per domU basis (if
> > spiceaudio if setted in cfg).
> 
> Pass it from libxl, after all QEMU is spawned by libxl

Setting envvars to configure qemu is a pretty crappy interface though,
given that qemu supports both command line and configuration files for
most other stuff. Perhaps this interface should be fixed upstream to use
the standard mechanisms first?

> > About usb redirection the qemu parameters to add are similar to this:
> > 
> > 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"]
> > 
> > Probably is not good point to external generic file (on my test
> > /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do this?

What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to
add USB passthrough as a concept in libxl so as to expose this in a more
"libxl" like manner, instead of just cutting through the qemu options?
(I think George also brought this up a while back).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 11:51:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 11: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 1U3mTq-0006Ir-O9; Fri, 08 Feb 2013 11:50:58 +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 1U3mTo-0006IP-LU
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 11:50:56 +0000
Received: from [85.158.139.83:61722] by server-13.bemta-5.messagelabs.com id
	98/8B-06769-F96E4115; Fri, 08 Feb 2013 11:50:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360324255!26030996!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19201 invoked from network); 8 Feb 2013 11:50:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 11:50:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="1277491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 11:50: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.297.1; Fri, 8 Feb 2013
	11:50:55 +0000
Message-ID: <1360324253.29432.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 8 Feb 2013 11:50:53 +0000
In-Reply-To: <alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] Need advice to develop some libxl 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

On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
> > I tested spice vdagent, spice audio and spice usbredirection with qemu
> > upstream and xen-unstable manually, is all working.
> > I'm start to write some patches to have all spice features on xen 4.3.
> > 
> > About vdagent probably no problem.
> > 
> > About spice audio on test I actually set this variable manually:
> > 
> > export QEMU_AUDIO_DRV=spice
> > 
> > I need know how to setup this env variable but for a given hvm domU start.
> > In other word I need to set this env variable on a per domU basis (if
> > spiceaudio if setted in cfg).
> 
> Pass it from libxl, after all QEMU is spawned by libxl

Setting envvars to configure qemu is a pretty crappy interface though,
given that qemu supports both command line and configuration files for
most other stuff. Perhaps this interface should be fixed upstream to use
the standard mechanisms first?

> > About usb redirection the qemu parameters to add are similar to this:
> > 
> > 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"]
> > 
> > Probably is not good point to external generic file (on my test
> > /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do this?

What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to
add USB passthrough as a concept in libxl so as to expose this in a more
"libxl" like manner, instead of just cutting through the qemu options?
(I think George also brought this up a while back).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 12:06:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 12:06: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 1U3mij-0007Px-6k; Fri, 08 Feb 2013 12:06:21 +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 1U3mih-0007Ps-It
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 12:06:19 +0000
Received: from [85.158.138.51:26421] by server-13.bemta-3.messagelabs.com id
	B5/EE-20653-93AE4115; Fri, 08 Feb 2013 12:06:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360325163!8786933!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28493 invoked from network); 8 Feb 2013 12:06:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 12:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="1278288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 12:06: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.297.1; Fri, 8 Feb 2013 12:06:02 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3miQ-0002v8-IP;
	Fri, 08 Feb 2013 12:06:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3miQ-0007N7-4l;
	Fri, 08 Feb 2013 12:06:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15446-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 12:06:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15446: 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 15446 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15446/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 15442
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15442
 test-amd64-i386-win          12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xend-qemut-winxpsp3  3 host-install(3)  broken REGR. vs. 15442
 test-amd64-i386-qemut-win    12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ffd30e7388ad
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26522:ffd30e7388ad
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Fri Feb 08 12:06:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 12:06: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 1U3mij-0007Px-6k; Fri, 08 Feb 2013 12:06:21 +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 1U3mih-0007Ps-It
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 12:06:19 +0000
Received: from [85.158.138.51:26421] by server-13.bemta-3.messagelabs.com id
	B5/EE-20653-93AE4115; Fri, 08 Feb 2013 12:06:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360325163!8786933!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28493 invoked from network); 8 Feb 2013 12:06:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 12:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="1278288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 12:06: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.297.1; Fri, 8 Feb 2013 12:06:02 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3miQ-0002v8-IP;
	Fri, 08 Feb 2013 12:06:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3miQ-0007N7-4l;
	Fri, 08 Feb 2013 12:06:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15446-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 12:06:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15446: 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 15446 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15446/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 15442
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15442
 test-amd64-i386-win          12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xend-qemut-winxpsp3  3 host-install(3)  broken REGR. vs. 15442
 test-amd64-i386-qemut-win    12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ffd30e7388ad
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26522:ffd30e7388ad
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Fri Feb 08 12:39:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 12: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 1U3nEt-0000EB-6c; Fri, 08 Feb 2013 12:39: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 1U3nEr-0000E6-LS
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 12:39:33 +0000
Received: from [85.158.139.211:25218] by server-12.bemta-5.messagelabs.com id
	8A/DB-20195-402F4115; Fri, 08 Feb 2013 12:39:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360327169!21357852!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27211 invoked from network); 8 Feb 2013 12:39:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 12:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6455199"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 12:39:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 07:39:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3nEd-0000ZM-PV;
	Fri, 08 Feb 2013 12:39:19 +0000
Date: Fri, 8 Feb 2013 12:39:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fabio.fantoni@heliman.it>
In-Reply-To: <5111301B.8080304@heliman.it>
Message-ID: <alpine.DEB.2.02.1302081239010.4275@kaball.uk.xensource.com>
References: <5111301B.8080304@heliman.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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] tools/libxl: Disable useless empty floppy
 drive with 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

On Tue, 5 Feb 2013, Fabio Fantoni wrote:
> tools/libxl: Disable useless empty floppy drive with
>   qemu-xen
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>   tools/libxl/libxl_dm.c |    3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..c265618 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -406,6 +406,9 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>       if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           int ioemu_nics = 0;
> 
> +        /* Disable useless empty floppy drive */
> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
> +
>           if (b_info->u.hvm.serial) {
>               flexarray_vappend(dm_args, "-serial", 
> b_info->u.hvm.serial, NULL);
>           }
> -- 
> 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 Fri Feb 08 12:39:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 12: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 1U3nEt-0000EB-6c; Fri, 08 Feb 2013 12:39: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 1U3nEr-0000E6-LS
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 12:39:33 +0000
Received: from [85.158.139.211:25218] by server-12.bemta-5.messagelabs.com id
	8A/DB-20195-402F4115; Fri, 08 Feb 2013 12:39:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360327169!21357852!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27211 invoked from network); 8 Feb 2013 12:39:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 12:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6455199"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 12:39:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 07:39:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3nEd-0000ZM-PV;
	Fri, 08 Feb 2013 12:39:19 +0000
Date: Fri, 8 Feb 2013 12:39:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fabio.fantoni@heliman.it>
In-Reply-To: <5111301B.8080304@heliman.it>
Message-ID: <alpine.DEB.2.02.1302081239010.4275@kaball.uk.xensource.com>
References: <5111301B.8080304@heliman.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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] tools/libxl: Disable useless empty floppy
 drive with 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

On Tue, 5 Feb 2013, Fabio Fantoni wrote:
> tools/libxl: Disable useless empty floppy drive with
>   qemu-xen
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>   tools/libxl/libxl_dm.c |    3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..c265618 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -406,6 +406,9 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>       if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           int ioemu_nics = 0;
> 
> +        /* Disable useless empty floppy drive */
> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
> +
>           if (b_info->u.hvm.serial) {
>               flexarray_vappend(dm_args, "-serial", 
> b_info->u.hvm.serial, NULL);
>           }
> -- 
> 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 Fri Feb 08 13:37:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 13: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 1U3o8B-0002H4-Rx; Fri, 08 Feb 2013 13:36:43 +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 1U3o89-0002Gz-U5
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 13:36:42 +0000
Received: from [85.158.143.99:4496] by server-3.bemta-4.messagelabs.com id
	34/31-08920-96FF4115; Fri, 08 Feb 2013 13:36:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360330599!23824000!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18219 invoked from network); 8 Feb 2013 13:36:40 -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 DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 13:36:40 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/dwQPR/OM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-089-105.pools.arcor-ip.net [88.65.89.105])
	by smtp.strato.de (jorabe mo35) (RZmta 31.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a029f3p18D7blb ;
	Fri, 8 Feb 2013 14:36:33 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id F225A1884C; Fri,  8 Feb 2013 14:36:30 +0100 (CET)
Date: Fri, 8 Feb 2013 14:36:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130208133630.GA5304@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
	<83398C3BBF16693DB6E1E2CA@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <83398C3BBF16693DB6E1E2CA@nimrod.local>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 07, Alex Bligh wrote:

> 
> 
> --On 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:
> 
> >You're heading in a slightly wrong direction here: You don't really
> >care what features Xen know about or supports. What you do care
> >about is what features your DomU-s get to see. And that's where
> >the masking comes into play (and why this can be done on a per
> >guest basis as well as at the host level).
> 
> I want my domUs to see a no more than a fixed set of CPU flags
> (obviously if those CPU flags aren't present, I don't want to
> lie that they are). I have no visibility of what hardware my
> software may be installed on in the future. EG if Intel introduces
> a megawidget CPU flag and Xen adds support for it, I want to be
> guaranteed this is masked out as it will break live migrate
> between megawidget and non-megawidget compatible machines.

I'm not sure what the question is, in a recent bug I had to disable
popcnt because one of the hosts did not have it. So I came up with this
config entry, which disables popcnt and sse4* bits:

cpuid=[ '1:ecx=xxxxxxxx0xx00xxxxxxxxxxxxxxxxxxx' ]

I think you have to read through the CPUID entry and set a few "required" bits
and a few "common across your hardware zoo" bits to 1 and set everything else
to 0 to handle the upcoming megawidget bit:
http://en.wikipedia.org/wiki/CPUID


If you use xend, you may need this patch to handle cpuid properly:

Only add cpuid and cpuid_check to sexpr once

When converting a XendConfig object to sexpr, cpuid and cpuid_check
were being emitted twice in the resulting sexpr.  The first conversion
writes incorrect sexpr, causing parsing of the sexpr to fail when xend
is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
are read and parsed.

This patch skips the first conversion, and uses only the custom
cpuid{_check} conversion methods called later.  It is not pretty, but
is the least invasive fix in this complex code.

Index: xen-4.2.0-testing/tools/python/xen/xend/XendConfig.py
===================================================================
--- xen-4.2.0-testing.orig/tools/python/xen/xend/XendConfig.py
+++ xen-4.2.0-testing/tools/python/xen/xend/XendConfig.py
@@ -1126,6 +1126,10 @@ class XendConfig(dict):
         else:
             for name, typ in XENAPI_CFG_TYPES.items():
                 if name in self and self[name] not in (None, []):
+                    # Skip cpuid and cpuid_check.  Custom conversion
+                    # methods for these are called below.
+                    if name in ("cpuid", "cpuid_check"):
+                        continue
                     if typ == dict:
                         s = self[name].items()
                     elif typ == list:


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 13:37:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 13: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 1U3o8B-0002H4-Rx; Fri, 08 Feb 2013 13:36:43 +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 1U3o89-0002Gz-U5
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 13:36:42 +0000
Received: from [85.158.143.99:4496] by server-3.bemta-4.messagelabs.com id
	34/31-08920-96FF4115; Fri, 08 Feb 2013 13:36:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360330599!23824000!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1MzI5NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18219 invoked from network); 8 Feb 2013 13:36:40 -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 DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 13:36:40 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/dwQPR/OM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-089-105.pools.arcor-ip.net [88.65.89.105])
	by smtp.strato.de (jorabe mo35) (RZmta 31.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a029f3p18D7blb ;
	Fri, 8 Feb 2013 14:36:33 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id F225A1884C; Fri,  8 Feb 2013 14:36:30 +0100 (CET)
Date: Fri, 8 Feb 2013 14:36:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130208133630.GA5304@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
	<83398C3BBF16693DB6E1E2CA@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <83398C3BBF16693DB6E1E2CA@nimrod.local>
User-Agent: Mutt/1.5.21.rev5636 (2013-01-23)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 07, Alex Bligh wrote:

> 
> 
> --On 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:
> 
> >You're heading in a slightly wrong direction here: You don't really
> >care what features Xen know about or supports. What you do care
> >about is what features your DomU-s get to see. And that's where
> >the masking comes into play (and why this can be done on a per
> >guest basis as well as at the host level).
> 
> I want my domUs to see a no more than a fixed set of CPU flags
> (obviously if those CPU flags aren't present, I don't want to
> lie that they are). I have no visibility of what hardware my
> software may be installed on in the future. EG if Intel introduces
> a megawidget CPU flag and Xen adds support for it, I want to be
> guaranteed this is masked out as it will break live migrate
> between megawidget and non-megawidget compatible machines.

I'm not sure what the question is, in a recent bug I had to disable
popcnt because one of the hosts did not have it. So I came up with this
config entry, which disables popcnt and sse4* bits:

cpuid=[ '1:ecx=xxxxxxxx0xx00xxxxxxxxxxxxxxxxxxx' ]

I think you have to read through the CPUID entry and set a few "required" bits
and a few "common across your hardware zoo" bits to 1 and set everything else
to 0 to handle the upcoming megawidget bit:
http://en.wikipedia.org/wiki/CPUID


If you use xend, you may need this patch to handle cpuid properly:

Only add cpuid and cpuid_check to sexpr once

When converting a XendConfig object to sexpr, cpuid and cpuid_check
were being emitted twice in the resulting sexpr.  The first conversion
writes incorrect sexpr, causing parsing of the sexpr to fail when xend
is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
are read and parsed.

This patch skips the first conversion, and uses only the custom
cpuid{_check} conversion methods called later.  It is not pretty, but
is the least invasive fix in this complex code.

Index: xen-4.2.0-testing/tools/python/xen/xend/XendConfig.py
===================================================================
--- xen-4.2.0-testing.orig/tools/python/xen/xend/XendConfig.py
+++ xen-4.2.0-testing/tools/python/xen/xend/XendConfig.py
@@ -1126,6 +1126,10 @@ class XendConfig(dict):
         else:
             for name, typ in XENAPI_CFG_TYPES.items():
                 if name in self and self[name] not in (None, []):
+                    # Skip cpuid and cpuid_check.  Custom conversion
+                    # methods for these are called below.
+                    if name in ("cpuid", "cpuid_check"):
+                        continue
                     if typ == dict:
                         s = self[name].items()
                     elif typ == list:


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 13:42:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 13:42: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 1U3oDb-0002ge-LK; Fri, 08 Feb 2013 13:42:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U3igL-00022Y-D9
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:47:37 +0000
Received: from [85.158.139.83:44848] by server-11.bemta-5.messagelabs.com id
	31/1B-19159-89DA4115; Fri, 08 Feb 2013 07:47:36 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360309653!20109672!1
X-Originating-IP: [209.85.216.172]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15967 invoked from network); 8 Feb 2013 07:47:34 -0000
Received: from mail-qc0-f172.google.com (HELO mail-qc0-f172.google.com)
	(209.85.216.172)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 07:47:34 -0000
Received: by mail-qc0-f172.google.com with SMTP id b25so1328349qca.31
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 23:47:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=NxUInLxRYiIaZPrZuQOx9aK/IrkIjK86jaxAivAc+dY=;
	b=iqH0/tiDk9GDyzE66iRkNvVkZ+UtNB+H/M5qv7ukbtfILuWIkMQTIaz3XrmXdY/B4f
	bCusA9djvlWJSCE8EHg6KVRgDw6Qn18n9a/v56Aa26IwjtdBsWFp3xQoNe8z11BEpYbt
	iURJWCpQ2MNAqXuS+k5K5uuvS3Xm6iskYIyiJlx87UuXZhNAR7qHpzkd3RKYgtZsEQAf
	89pi/7pD0ABQx/Wb8wa6I7snDvcLaYdobxmS6T0CQt/jBPhRYV+jjf7bgVVDLX9R74Z9
	yrQZ5VdLQNagcfZPzj+bZM1vY8Q3CegizwDnTa+OT96yUtooqZ+9BF1xTMBJ2RZAF91S
	95Gw==
MIME-Version: 1.0
X-Received: by 10.224.52.68 with SMTP id h4mr1727624qag.17.1360309652803; Thu,
	07 Feb 2013 23:47:32 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Thu, 7 Feb 2013 23:47:32 -0800 (PST)
In-Reply-To: <20130205183236.GB5652@konrad-lan.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
Date: Fri, 8 Feb 2013 08:47:32 +0100
Message-ID: <CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 08 Feb 2013 13:42:18 +0000
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============8694149927345817112=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8694149927345817112==
Content-Type: multipart/alternative; boundary=20cf3074afa8a3d1c604d531c58b

--20cf3074afa8a3d1c604d531c58b
Content-Type: text/plain; charset=ISO-8859-1

Thank you for your help guys. I tried to apply those patches, but I didn't
succeed.
Konrard's acpi-s3 worked (in sence I didn't get error while patching), but
the patches from Ben not. Arch linux is using pretty much vanilla kernel
with only 3 patches applied(upstream patch, default console loglevel patch
and fat issue patch), and it seems I'm missing a whole lot of things there.
For instance, the 'fix-dmar-zap-reinstate.txt' requires /xen/drivers/
folder, but in my kernel source it is missing (there is xen, but no
drivers).

I'm not familiar with custom kernel building (this was my first time), but
I would say I'm missing some xen patches that should be applied priror to
those of Ben.
Could you please give me a hint on how can I proceed or what kernel did you
use?
Thank you very much for your time.


2013/2/5 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> On Mon, Feb 04, 2013 at 11:07:23AM +0100, Tomasz Wroblewski wrote:
> >
> > >>fix-suspend-scheduler-v2
> > >>fix-suspend-scheduler-revert-affinity-part
> > >>s3-timerirq
> > >>
> > >>All of these fixes have been proposed to the xen-devel list, but have
> > >>not yet been accepted, for one reason, or another.
> > >And I don't think comments on them have seen follow-ups.
> > >
> > >Jan
> > >
> > I guess it's worth bringing this up again;
> >
> > s3-timerirq: this was empirical hack which for some reason is needed
> > on stable 4.2 we use, but not on latest unstable, didn't really
> > investigate further since it appeared fixed later on anyway..
> >
> > fix-suspend-scheduler/revert-affinity: the big objection here was
> > the part which reverts one of the hunks in Keir's commit. I tried
> > for quite few days to find a working fix which does not do this
> > revert using posted suggestions, but was not succesfull:
> >
> > - there was a crash in xen scheduler, which was fixable using your
> > suggestion of masking softirqs during s3 (ugly)
> > - there was also a crash in xen acpi cpufreq driver, which was
> > similarily fixable using a bandaid s3 condition (ugly)
> > - unfortunately this turned out to not be all, xen did not crash
> > anymore at this point but dom0 kernel did around the time it enables
> > cpus, in multiple places: at this point I didn't have a good
> > explanation for it, my opinion of aggravating hunk was rather low,
> > so I uttered a hearty curse and stuck a revert into private
> > patchqueue.
> >
> > The dom0 kernel crashes were as follows:
> >
> > 1)
> >
> > [   60.657751] Enabling non-boot CPUs ...
> > [   60.657958] installing Xen timer for CPU 1
> > [   60.657987] cpu 1 spinlock event irq 279
> > [   60.658101] Disabled fast string operations
> > [   60.658466] CPU1 is up
> > [   60.658736] installing Xen timer for CPU 2
> > [   60.658784] cpu 2 spinlock event irq 285
> > [   60.659764] Disabled fast string operations
> > [   60.661811] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000018
> > [   60.661817] IP: [<ffffffff8105f700>]
> > build_sched_domains+0x770/0(XEN) *** Serial input -> Xen (type
> > 'CTRL-a' three times to switch input to DOM0)
> >
> >
> >
> >
> > 2)
> > .332997] installing Xen timer for CPU 2emory
> > [   36.333061] cpu 2 spinlock event irq 285
> > [   36.333343] Disabled fast string operations
> > [   36.334939] CPU2 is up
> > [   36.335213] installing Xen timer for CPU 3
> > [   36.335244] cpu 3 spinlock event irq 291
> > [   36.335561] Disabled fast string operations
> > [   36.337461] CPU3 is up
> > [   36.339513] ACPI: Waking up from system sleep state S3
> > [   36.350193] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000004
> > [   36.350211] IP: [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> > [   36.350236] PGD 2f19067 PUD 2ec7067 PMD 0
> > [   36.350252] Oops: 0000 [#1] SMP
> > [   36.350263] CPU 1
> > [   36.350267] Modules linked in: xt_mac ipt_MASQUERADE
> > ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> > xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> > nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> > ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> > snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> > serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> > thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> > snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> > intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> > [   36.350437]
> > [   36.350445] Pid: 2730, comm: bash Tainted: G         C O
> > 3.2.23-orc #19 LENOVO 42404EU/42404EU
> > [   36.350463] RIP: e030:[<ffffffff81055f9a>]  [<ffffffff81055f9a>]
> > find_busiest_group+0x38a/0xbb0
> > [   36.350481] RSP: e02b:ffff880002b71228  EFLAGS: 00010046
> > [   36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX:
> > 0000000000000000
> > [   36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
> > 0000000000000000
> > [   36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09:
> > 0000000000000000
> > [   36.350519] R10: 0000000000000000 R11: 0000000000000001 R12:
> > 0000000000000000
> > [   36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15:
> > ffff880026109f98
> > [   36.350547] FS:  00007fc41e295700(0000) GS:ffff88002dc40000(0000)
> > knlGS:0000000000000000
> > [   36.350558] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [   36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4:
> > 0000000000002660
> > [   36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> > 0000000000000000
> > [   36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> > 0000000000000400
> > [   36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000,
> > task ffff880027a7db40)
> > [   36.350608] Stack:
> > [   36.350613]  00ffffff00000002 0000000300000001 ffff880002b71498
> > ffff880002b71534
> > [   36.350630]  00ffffff00000002 0000000100000001 ffff8800262cf000
> > 0000000000000008
> > [   36.350646]  ffffffff00000000 0000000000000000 0000000000000000
> > ffff88002dc4e2c8
> > [   36.350662] Call Trace:
> > [   36.350677]  [<ffffffff8105b158>] load_balance+0xb8/0x840
> > [   36.350690]  [<ffffffff8101b909>] ? sched_clock+0x9/0x10
> > [   36.350706]  [<ffffffff8108ccad>] ? sched_clock_cpu+0xbd/0x110
> > [   36.350718]  [<ffffffff81052b1c>] ? update_shares+0xcc/0x100
> > [   36.350735]  [<ffffffff8157b9b5>] __schedule+0x875/0x8d0
> > [   36.350749]  [<ffffffff81073ae2>] ? try_to_del_timer_sync+0x92/0x130
> > [   36.350762]  [<ffffffff8157bd3f>] schedule+0x3f/0x60
> > [   36.350773]  [<ffffffff8157c24d>] schedule_timeout+0x16d/0x320
> > [   36.350786]  [<ffffffff810728e0>] ? usleep_range+0x50/0x50
> > [   36.350800]  [<ffffffff8157de2e>] ?
> _raw_spin_unlock_irqrestore+0x1e/0x30
> > [   36.350817]  [<ffffffff8130c340>]
> > acpi_ec_transaction_unlocked+0x134/0x1d8
> > [   36.350830]  [<ffffffff81086b90>] ? add_wait_queue+0x60/0x60
> > [   36.350842]  [<ffffffff8130c6c6>] acpi_ec_transaction+0x196/0x239
> > [   36.350856]  [<ffffffff8157de2e>] ?
> _raw_spin_unlock_irqrestore+0x1e/0x30
> > [   36.350869]  [<ffffffff8130c8a0>] acpi_ec_write+0x40/0x42
> > [   36.350881]  [<ffffffff8130c9a8>] acpi_ec_space_handler+0x9e/0xfc
> > [   36.350894]  [<ffffffff8130c90a>] ? acpi_ec_burst_disable+0x3d/0x3d
> > [   36.350909]  [<ffffffff813159c6>]
> > acpi_ev_address_space_dispatch+0x179/0x1c8
> > [   36.350924]  [<ffffffff8131aafe>] acpi_ex_access_region+0x23e/0x24b
> > [   36.350936]  [<ffffffff8106e82c>] ? __sysctl_head_next+0x11c/0x130
> > [   36.350951]  [<ffffffff8131ae15>] acpi_ex_field_datum_io+0xf9/0x17a
> > [   36.350965]  [<ffffffff8131b148>]
> > acpi_ex_write_with_update_rule+0xb5/0xc1
> > [   36.350989]  [<ffffffff8131acfa>]
> acpi_ex_insert_into_field+0x1ef/0x211
> > [   36.351003]  [<ffffffff8132b5a7>] ?
> > acpi_ut_allocate_object_desc_dbg+0x45/0x7f
> > [   36.351018]  [<ffffffff8131980e>]
> acpi_ex_write_data_to_field+0x194/0x1c2
> > [   36.351031]  [<ffffffff813131e4>] ?
> > acpi_ds_init_object_from_op+0x137/0x231
> > [   36.351044]  [<ffffffff8131d94f>]
> acpi_ex_store_object_to_node+0xa3/0xe2
> > [   36.351056]  [<ffffffff8131da51>] acpi_ex_store+0xc3/0x256
> > [   36.351066]  [<ffffffff8131b62b>] acpi_ex_opcode_1A_1T_1R+0x353/0x4a5
> > [   36.351078]  [<ffffffff8131260c>] acpi_ds_exec_end_op+0xf7/0x3e7
> > [   36.351092]  [<ffffffff81325ae7>] acpi_ps_parse_loop+0x7bd/0x94e
> > [   36.351105]  [<ffffffff81324ed9>] acpi_ps_parse_aml+0x96/0x275
> > [   36.351119]  [<ffffffff81326394>] acpi_ps_execute_method+0x1ce/0x276
> > [   36.351131]  [<ffffffff8132165b>] acpi_ns_evaluate+0xdf/0x1aa
> > [   36.351144]  [<ffffffff81320c9d>] acpi_evaluate_object+0xfb/0x1f4
> > [   36.351156]  [<ffffffff8130f8ee>] acpi_device_sleep_wake+0x95/0xc7
> > [   36.351168]  [<ffffffff8130fa60>]
> > acpi_disable_wakeup_device_power+0x6e/0xc9
> > [   36.351182]  [<ffffffff813085e2>]
> acpi_disable_wakeup_devices+0x7b/0x95
> > [   36.351194]  [<ffffffff81308710>] acpi_pm_finish+0x39/0x55
> > [   36.351208]  [<ffffffff810a6034>]
> suspend_devices_and_enter+0x104/0x310
> > [   36.351222]  [<ffffffff810a63a7>] enter_state+0x167/0x190
> > [   36.351234]  [<ffffffff810a4d27>] state_store+0xb7/0x130
> > [   36.351246]  [<ffffffff812b54df>] kobj_attr_store+0xf/0x30
> > [   36.351260]  [<ffffffff811d382f>] sysfs_write_file+0xef/0x170
> > [   36.351274]  [<ffffffff811668d3>] vfs_write+0xb3/0x180
> > [   36.351286]  [<ffffffff81166bfa>] sys_write+0x4a/0x90
> > [   36.351300]  [<ffffffff81585d02>] system_call_fastpath+0x16/0x1b
> > [   36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8
> > 5d fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b
> > 4d 98 31 d2 <8b> 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0 48
> > 85 c9 48
> > [   36.351435] RIP  [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> > [   36.351450]  RSP <ffff880002b71228>
> > [   36.351456] CR2: 0000000000000004
> > [   36.351465] ---[ end trace 5ad2b14b3a9050ae ]---
> > [   36.352362] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000010
> > [   36.352379] IP: [<ffffffff812ba531>] rb_next+0x1/0x50
> > [   36.352394] PGD 0
> > [   36.352402] Oops: 0000 [#2] SMP
> > [   36.352411] CPU 1
> > [   36.352416] Modules linked in: xt_mac ipt_MASQUERADE
> > ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> > xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> > nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> > ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> > snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> > serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> > thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> > snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> > intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> > [   36.352573]
> > [   36.352580] Pid: 2730, comm: bash Tainted: G      D  C O
> > 3.2.23-orc #19 LENOVO 42404EU/42404EU
> > [   36.352596] RIP: e030:[<ffffffff812ba531>]  [<fffffff
> >
> >
> >
> >
> > 3)
> >
> > [   47.833362] Resuming Xen processor info
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > [   47.886297] Enabling non-boot CPUs ...
> > [   47.890082] installing Xen timer for CPU 1
> > [   47.894257] cpu 1 spinlock event irq 48
> > [   47.899013] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000008
> > [   47.906740] IP: [<ffffffff8149196b>]
> __cpuidle_register_device+0x2b/0x100
> > [   47.913578] PGD 34a4067 PUD 3ac3067 PMD 0
> > [   47.917825] Oops: 0000 [#1] SMP
> > [   47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebtables
> iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdisk(O)
> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> nf_conntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs
> bridge stp llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp
> crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw
> aes_x86_64 xts gf128mul microcode psmouse serio_raw arc4 iwldvm mac80211
> i915 drm_kms_helper drm iwlwifi intel_agp i2c_algo_bit cfg80211 intel_gtt
> video ahci libahci e1000e [last unloaded: tpm_bios]
> > [   47.974636] CPU 0
> > [   47.976456] Pid: 2468, comm: pm-suspend Tainted: G         C O
> 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake
> > [   47.988310] RIP: e030:[<ffffffff8149196b>]  [<ffffffff8149196b>]
> __cpuidle_register_device+0x2b/0x100
> > [   47.997605] RSP: e02b:ffff880025685c98  EFLAGS: 00010286
> > [   48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX:
> 0000000000000000
> > [   48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI:
> ffff88002de40000
> > [   48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09:
> 0000000000000000
> > [   48.024520] R10: 0000000000000030 R11: 0000000000000000 R12:
> ffff88002de40000
> > [   48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15:
> 0000000000000000
> > [   48.038927] FS:  00007fb599d0e700(0000) GS:ffff88002de00000(0000)
> knlGS:0000000000000000
> > [   48.047060] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [   48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4:
> 0000000000002660
> > [   48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> > [   48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> > [   48.074450] Process pm-suspend (pid: 2468, threadinfo
> ffff880025684000, task ffff880003558000)
> > [   48.083102] Stack:
> > [   48.085179]  ffff88002de40000 ffff88002de40000 00000000ffffffde
> ffffffff81a6b480
> > [   48.092622]  ffff880025685cd8 ffffffff81491cc1 0000000000000001
> ffff88002de40000
> > [   48.100064]  ffff880025685cf8 ffffffff813046df 0000000000000001
> 0000000000000001
> > [   48.107517] Call Trace:
> > [   48.110029]  [<ffffffff81491cc1>] cpuidle_register_device+0x31/0x80
> > [   48.116348]  [<ffffffff813046df>] intel_idle_cpu_init+0xbf/0x120
> > [   48.122423]  [<ffffffff813047b0>] cpu_hotplug_notify+0x70/0x80
> > [   48.128310]  [<ffffffff815a619d>] notifier_call_chain+0x4d/0x70
> > [   48.134281]  [<ffffffff8107969e>] __raw_notifier_call_chain+0xe/0x10
> > [   48.140686]  [<ffffffff81053bb0>] __cpu_notify+0x20/0x40
> > [   48.146050]  [<ffffffff81594c7c>] _cpu_up+0xf1/0x138
> > [   48.151070]  [<ffffffff8158ab39>] enable_nonboot_cpus+0x99/0xd0
> > [   48.157090]  [<ffffffff81097b8d>]
> suspend_devices_and_enter+0x25d/0x330
> > [   48.163752]  [<ffffffff81097def>] pm_suspend+0x18f/0x1f0
> > [   48.169117]  [<ffffffff81096dea>] state_store+0x8a/0x100
> > [   48.174483]  [<ffffffff812ac29f>] kobj_attr_store+0xf/0x30
> > [   48.180022]  [<ffffffff811c005f>] sysfs_write_file+0xef/0x170
> > [   48.185943]  [<ffffffff8115c253>] vfs_write+0xb3/0x180
> > [   48.191056]  [<ffffffff8115c592>] sys_write+0x52/0xa0
> > [   48.196160]  [<ffffffff815a614e>] ? do_page_fault+0xe/0x10
> > [   48.201700]  [<ffffffff815aa7d9>] system_call_fastpath+0x16/0x1b
> > [   48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e0
> 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a 00
> 00<48>  8b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 49 c7
> > [   48.226658] RIP  [<ffffffff8149196b>]
> __cpuidle_register_device+0x2b/0x100
>
> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> you are .. ah yes, you are hitting a bug that should be in the stable
> tree fix.
>
> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
>
> > [   48.233582]  RSP<ffff880025685c98>
> > [   48.237131] CR2: 0000000000000008
> >
> > [   48.240521] ---[ end trace 535ebe28cd06b143 ]---
> >
> >
> >
>

--20cf3074afa8a3d1c604d531c58b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Thank you for your help guys. I t=
ried to apply those patches, but I didn&#39;t succeed.<br></div>Konrard&#39=
;s acpi-s3 worked (in sence I didn&#39;t get error while patching), but the=
 patches from Ben not. Arch linux is using pretty much vanilla kernel with =
only 3 patches applied(upstream patch, default console loglevel patch and f=
at issue patch), and it seems I&#39;m missing a whole lot of things there. =
<br>
</div>For instance, the &#39;fix-dmar-zap-reinstate.txt&#39; requires /xen/=
drivers/ folder, but in my kernel source it is missing (there is xen, but n=
o drivers). <br><br></div>I&#39;m not familiar with custom kernel building =
(this was my first time), but I would say I&#39;m missing some xen patches =
that should be applied priror to those of Ben. <br>
</div>Could you please give me a hint on how can I proceed or what kernel d=
id you use? <br></div>Thank you very much for your time.<br></div><div clas=
s=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/2/5 Konrad Rzeszu=
tek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@oracle.com" ta=
rget=3D"_blank">konrad.wilk@oracle.com</a>&gt;</span><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 M=
on, Feb 04, 2013 at 11:07:23AM +0100, Tomasz Wroblewski wrote:<br>
&gt;<br>
&gt; &gt;&gt;fix-suspend-scheduler-v2<br>
&gt; &gt;&gt;fix-suspend-scheduler-revert-affinity-part<br>
&gt; &gt;&gt;s3-timerirq<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;All of these fixes have been proposed to the xen-devel list, b=
ut have<br>
&gt; &gt;&gt;not yet been accepted, for one reason, or another.<br>
&gt; &gt;And I don&#39;t think comments on them have seen follow-ups.<br>
&gt; &gt;<br>
&gt; &gt;Jan<br>
&gt; &gt;<br>
&gt; I guess it&#39;s worth bringing this up again;<br>
&gt;<br>
&gt; s3-timerirq: this was empirical hack which for some reason is needed<b=
r>
&gt; on stable 4.2 we use, but not on latest unstable, didn&#39;t really<br=
>
&gt; investigate further since it appeared fixed later on anyway..<br>
&gt;<br>
&gt; fix-suspend-scheduler/revert-affinity: the big objection here was<br>
&gt; the part which reverts one of the hunks in Keir&#39;s commit. I tried<=
br>
&gt; for quite few days to find a working fix which does not do this<br>
&gt; revert using posted suggestions, but was not succesfull:<br>
&gt;<br>
&gt; - there was a crash in xen scheduler, which was fixable using your<br>
&gt; suggestion of masking softirqs during s3 (ugly)<br>
&gt; - there was also a crash in xen acpi cpufreq driver, which was<br>
&gt; similarily fixable using a bandaid s3 condition (ugly)<br>
&gt; - unfortunately this turned out to not be all, xen did not crash<br>
&gt; anymore at this point but dom0 kernel did around the time it enables<b=
r>
&gt; cpus, in multiple places: at this point I didn&#39;t have a good<br>
&gt; explanation for it, my opinion of aggravating hunk was rather low,<br>
&gt; so I uttered a hearty curse and stuck a revert into private<br>
&gt; patchqueue.<br>
&gt;<br>
&gt; The dom0 kernel crashes were as follows:<br>
&gt;<br>
&gt; 1)<br>
&gt;<br>
&gt; [ =A0 60.657751] Enabling non-boot CPUs ...<br>
&gt; [ =A0 60.657958] installing Xen timer for CPU 1<br>
&gt; [ =A0 60.657987] cpu 1 spinlock event irq 279<br>
&gt; [ =A0 60.658101] Disabled fast string operations<br>
&gt; [ =A0 60.658466] CPU1 is up<br>
&gt; [ =A0 60.658736] installing Xen timer for CPU 2<br>
&gt; [ =A0 60.658784] cpu 2 spinlock event irq 285<br>
&gt; [ =A0 60.659764] Disabled fast string operations<br>
&gt; [ =A0 60.661811] BUG: unable to handle kernel NULL pointer dereference=
<br>
&gt; at 0000000000000018<br>
&gt; [ =A0 60.661817] IP: [&lt;ffffffff8105f700&gt;]<br>
&gt; build_sched_domains+0x770/0(XEN) *** Serial input -&gt; Xen (type<br>
&gt; &#39;CTRL-a&#39; three times to switch input to DOM0)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; 2)<br>
&gt; .332997] installing Xen timer for CPU 2emory<br>
&gt; [ =A0 36.333061] cpu 2 spinlock event irq 285<br>
&gt; [ =A0 36.333343] Disabled fast string operations<br>
&gt; [ =A0 36.334939] CPU2 is up<br>
&gt; [ =A0 36.335213] installing Xen timer for CPU 3<br>
&gt; [ =A0 36.335244] cpu 3 spinlock event irq 291<br>
&gt; [ =A0 36.335561] Disabled fast string operations<br>
&gt; [ =A0 36.337461] CPU3 is up<br>
&gt; [ =A0 36.339513] ACPI: Waking up from system sleep state S3<br>
&gt; [ =A0 36.350193] BUG: unable to handle kernel NULL pointer dereference=
<br>
&gt; at 0000000000000004<br>
&gt; [ =A0 36.350211] IP: [&lt;ffffffff81055f9a&gt;] find_busiest_group+0x3=
8a/0xbb0<br>
&gt; [ =A0 36.350236] PGD 2f19067 PUD 2ec7067 PMD 0<br>
&gt; [ =A0 36.350252] Oops: 0000 [#1] SMP<br>
&gt; [ =A0 36.350263] CPU 1<br>
&gt; [ =A0 36.350267] Modules linked in: xt_mac ipt_MASQUERADE<br>
&gt; ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)<br>
&gt; xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat<br>
&gt; nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4<br>
&gt; ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)<br>
&gt; snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse<br>
&gt; serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)<b=
r>
&gt; thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm<br>
&gt; snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video<br=
>
&gt; intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e<br>
&gt; [ =A0 36.350437]<br>
&gt; [ =A0 36.350445] Pid: 2730, comm: bash Tainted: G =A0 =A0 =A0 =A0 C O<=
br>
&gt; 3.2.23-orc #19 LENOVO 42404EU/42404EU<br>
&gt; [ =A0 36.350463] RIP: e030:[&lt;ffffffff81055f9a&gt;] =A0[&lt;ffffffff=
81055f9a&gt;]<br>
&gt; find_busiest_group+0x38a/0xbb0<br>
&gt; [ =A0 36.350481] RSP: e02b:ffff880002b71228 =A0EFLAGS: 00010046<br>
&gt; [ =A0 36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350519] R10: 0000000000000000 R11: 0000000000000001 R12:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15:<br>
&gt; ffff880026109f98<br>
&gt; [ =A0 36.350547] FS: =A000007fc41e295700(0000) GS:ffff88002dc40000(000=
0)<br>
&gt; knlGS:0000000000000000<br>
&gt; [ =A0 36.350558] CS: =A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b<b=
r>
&gt; [ =A0 36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4:<br>
&gt; 0000000000002660<br>
&gt; [ =A0 36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:<br>
&gt; 0000000000000400<br>
&gt; [ =A0 36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000,=
<br>
&gt; task ffff880027a7db40)<br>
&gt; [ =A0 36.350608] Stack:<br>
&gt; [ =A0 36.350613] =A000ffffff00000002 0000000300000001 ffff880002b71498=
<br>
&gt; ffff880002b71534<br>
&gt; [ =A0 36.350630] =A000ffffff00000002 0000000100000001 ffff8800262cf000=
<br>
&gt; 0000000000000008<br>
&gt; [ =A0 36.350646] =A0ffffffff00000000 0000000000000000 0000000000000000=
<br>
&gt; ffff88002dc4e2c8<br>
&gt; [ =A0 36.350662] Call Trace:<br>
&gt; [ =A0 36.350677] =A0[&lt;ffffffff8105b158&gt;] load_balance+0xb8/0x840=
<br>
&gt; [ =A0 36.350690] =A0[&lt;ffffffff8101b909&gt;] ? sched_clock+0x9/0x10<=
br>
&gt; [ =A0 36.350706] =A0[&lt;ffffffff8108ccad&gt;] ? sched_clock_cpu+0xbd/=
0x110<br>
&gt; [ =A0 36.350718] =A0[&lt;ffffffff81052b1c&gt;] ? update_shares+0xcc/0x=
100<br>
&gt; [ =A0 36.350735] =A0[&lt;ffffffff8157b9b5&gt;] __schedule+0x875/0x8d0<=
br>
&gt; [ =A0 36.350749] =A0[&lt;ffffffff81073ae2&gt;] ? try_to_del_timer_sync=
+0x92/0x130<br>
&gt; [ =A0 36.350762] =A0[&lt;ffffffff8157bd3f&gt;] schedule+0x3f/0x60<br>
&gt; [ =A0 36.350773] =A0[&lt;ffffffff8157c24d&gt;] schedule_timeout+0x16d/=
0x320<br>
&gt; [ =A0 36.350786] =A0[&lt;ffffffff810728e0&gt;] ? usleep_range+0x50/0x5=
0<br>
&gt; [ =A0 36.350800] =A0[&lt;ffffffff8157de2e&gt;] ? _raw_spin_unlock_irqr=
estore+0x1e/0x30<br>
&gt; [ =A0 36.350817] =A0[&lt;ffffffff8130c340&gt;]<br>
&gt; acpi_ec_transaction_unlocked+0x134/0x1d8<br>
&gt; [ =A0 36.350830] =A0[&lt;ffffffff81086b90&gt;] ? add_wait_queue+0x60/0=
x60<br>
&gt; [ =A0 36.350842] =A0[&lt;ffffffff8130c6c6&gt;] acpi_ec_transaction+0x1=
96/0x239<br>
&gt; [ =A0 36.350856] =A0[&lt;ffffffff8157de2e&gt;] ? _raw_spin_unlock_irqr=
estore+0x1e/0x30<br>
&gt; [ =A0 36.350869] =A0[&lt;ffffffff8130c8a0&gt;] acpi_ec_write+0x40/0x42=
<br>
&gt; [ =A0 36.350881] =A0[&lt;ffffffff8130c9a8&gt;] acpi_ec_space_handler+0=
x9e/0xfc<br>
&gt; [ =A0 36.350894] =A0[&lt;ffffffff8130c90a&gt;] ? acpi_ec_burst_disable=
+0x3d/0x3d<br>
&gt; [ =A0 36.350909] =A0[&lt;ffffffff813159c6&gt;]<br>
&gt; acpi_ev_address_space_dispatch+0x179/0x1c8<br>
&gt; [ =A0 36.350924] =A0[&lt;ffffffff8131aafe&gt;] acpi_ex_access_region+0=
x23e/0x24b<br>
&gt; [ =A0 36.350936] =A0[&lt;ffffffff8106e82c&gt;] ? __sysctl_head_next+0x=
11c/0x130<br>
&gt; [ =A0 36.350951] =A0[&lt;ffffffff8131ae15&gt;] acpi_ex_field_datum_io+=
0xf9/0x17a<br>
&gt; [ =A0 36.350965] =A0[&lt;ffffffff8131b148&gt;]<br>
&gt; acpi_ex_write_with_update_rule+0xb5/0xc1<br>
&gt; [ =A0 36.350989] =A0[&lt;ffffffff8131acfa&gt;] acpi_ex_insert_into_fie=
ld+0x1ef/0x211<br>
&gt; [ =A0 36.351003] =A0[&lt;ffffffff8132b5a7&gt;] ?<br>
&gt; acpi_ut_allocate_object_desc_dbg+0x45/0x7f<br>
&gt; [ =A0 36.351018] =A0[&lt;ffffffff8131980e&gt;] acpi_ex_write_data_to_f=
ield+0x194/0x1c2<br>
&gt; [ =A0 36.351031] =A0[&lt;ffffffff813131e4&gt;] ?<br>
&gt; acpi_ds_init_object_from_op+0x137/0x231<br>
&gt; [ =A0 36.351044] =A0[&lt;ffffffff8131d94f&gt;] acpi_ex_store_object_to=
_node+0xa3/0xe2<br>
&gt; [ =A0 36.351056] =A0[&lt;ffffffff8131da51&gt;] acpi_ex_store+0xc3/0x25=
6<br>
&gt; [ =A0 36.351066] =A0[&lt;ffffffff8131b62b&gt;] acpi_ex_opcode_1A_1T_1R=
+0x353/0x4a5<br>
&gt; [ =A0 36.351078] =A0[&lt;ffffffff8131260c&gt;] acpi_ds_exec_end_op+0xf=
7/0x3e7<br>
&gt; [ =A0 36.351092] =A0[&lt;ffffffff81325ae7&gt;] acpi_ps_parse_loop+0x7b=
d/0x94e<br>
&gt; [ =A0 36.351105] =A0[&lt;ffffffff81324ed9&gt;] acpi_ps_parse_aml+0x96/=
0x275<br>
&gt; [ =A0 36.351119] =A0[&lt;ffffffff81326394&gt;] acpi_ps_execute_method+=
0x1ce/0x276<br>
&gt; [ =A0 36.351131] =A0[&lt;ffffffff8132165b&gt;] acpi_ns_evaluate+0xdf/0=
x1aa<br>
&gt; [ =A0 36.351144] =A0[&lt;ffffffff81320c9d&gt;] acpi_evaluate_object+0x=
fb/0x1f4<br>
&gt; [ =A0 36.351156] =A0[&lt;ffffffff8130f8ee&gt;] acpi_device_sleep_wake+=
0x95/0xc7<br>
&gt; [ =A0 36.351168] =A0[&lt;ffffffff8130fa60&gt;]<br>
&gt; acpi_disable_wakeup_device_power+0x6e/0xc9<br>
&gt; [ =A0 36.351182] =A0[&lt;ffffffff813085e2&gt;] acpi_disable_wakeup_dev=
ices+0x7b/0x95<br>
&gt; [ =A0 36.351194] =A0[&lt;ffffffff81308710&gt;] acpi_pm_finish+0x39/0x5=
5<br>
&gt; [ =A0 36.351208] =A0[&lt;ffffffff810a6034&gt;] suspend_devices_and_ent=
er+0x104/0x310<br>
&gt; [ =A0 36.351222] =A0[&lt;ffffffff810a63a7&gt;] enter_state+0x167/0x190=
<br>
&gt; [ =A0 36.351234] =A0[&lt;ffffffff810a4d27&gt;] state_store+0xb7/0x130<=
br>
&gt; [ =A0 36.351246] =A0[&lt;ffffffff812b54df&gt;] kobj_attr_store+0xf/0x3=
0<br>
&gt; [ =A0 36.351260] =A0[&lt;ffffffff811d382f&gt;] sysfs_write_file+0xef/0=
x170<br>
&gt; [ =A0 36.351274] =A0[&lt;ffffffff811668d3&gt;] vfs_write+0xb3/0x180<br=
>
&gt; [ =A0 36.351286] =A0[&lt;ffffffff81166bfa&gt;] sys_write+0x4a/0x90<br>
&gt; [ =A0 36.351300] =A0[&lt;ffffffff81585d02&gt;] system_call_fastpath+0x=
16/0x1b<br>
&gt; [ =A0 36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8=
<br>
&gt; 5d fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b<b=
r>
&gt; 4d 98 31 d2 &lt;8b&gt; 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0=
 48<br>
&gt; 85 c9 48<br>
&gt; [ =A0 36.351435] RIP =A0[&lt;ffffffff81055f9a&gt;] find_busiest_group+=
0x38a/0xbb0<br>
&gt; [ =A0 36.351450] =A0RSP &lt;ffff880002b71228&gt;<br>
&gt; [ =A0 36.351456] CR2: 0000000000000004<br>
&gt; [ =A0 36.351465] ---[ end trace 5ad2b14b3a9050ae ]---<br>
&gt; [ =A0 36.352362] BUG: unable to handle kernel NULL pointer dereference=
<br>
&gt; at 0000000000000010<br>
&gt; [ =A0 36.352379] IP: [&lt;ffffffff812ba531&gt;] rb_next+0x1/0x50<br>
&gt; [ =A0 36.352394] PGD 0<br>
&gt; [ =A0 36.352402] Oops: 0000 [#2] SMP<br>
&gt; [ =A0 36.352411] CPU 1<br>
&gt; [ =A0 36.352416] Modules linked in: xt_mac ipt_MASQUERADE<br>
&gt; ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)<br>
&gt; xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat<br>
&gt; nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4<br>
&gt; ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)<br>
&gt; snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse<br>
&gt; serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)<b=
r>
&gt; thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm<br>
&gt; snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video<br=
>
&gt; intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e<br>
&gt; [ =A0 36.352573]<br>
&gt; [ =A0 36.352580] Pid: 2730, comm: bash Tainted: G =A0 =A0 =A0D =A0C O<=
br>
&gt; 3.2.23-orc #19 LENOVO 42404EU/42404EU<br>
&gt; [ =A0 36.352596] RIP: e030:[&lt;ffffffff812ba531&gt;] =A0[&lt;fffffff<=
br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; 3)<br>
&gt;<br>
&gt; [ =A0 47.833362] Resuming Xen processor info<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; [ =A0 47.886297] Enabling non-boot CPUs ...<br>
&gt; [ =A0 47.890082] installing Xen timer for CPU 1<br>
&gt; [ =A0 47.894257] cpu 1 spinlock event irq 48<br>
&gt; [ =A0 47.899013] BUG: unable to handle kernel NULL pointer dereference=
 at 0000000000000008<br>
&gt; [ =A0 47.906740] IP: [&lt;ffffffff8149196b&gt;] __cpuidle_register_dev=
ice+0x2b/0x100<br>
&gt; [ =A0 47.913578] PGD 34a4067 PUD 3ac3067 PMD 0<br>
&gt; [ =A0 47.917825] Oops: 0000 [#1] SMP<br>
&gt; [ =A0 47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebta=
bles iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdis=
k(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_con=
ntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs bridge stp =
llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp crc32c_intel ghash_=
clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul mi=
crocode psmouse serio_raw arc4 iwldvm mac80211 i915 drm_kms_helper drm iwlw=
ifi intel_agp i2c_algo_bit cfg80211 intel_gtt video ahci libahci e1000e [la=
st unloaded: tpm_bios]<br>

&gt; [ =A0 47.974636] CPU 0<br>
&gt; [ =A0 47.976456] Pid: 2468, comm: pm-suspend Tainted: G =A0 =A0 =A0 =
=A0 C O 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake<b=
r>
&gt; [ =A0 47.988310] RIP: e030:[&lt;ffffffff8149196b&gt;] =A0[&lt;ffffffff=
8149196b&gt;] __cpuidle_register_device+0x2b/0x100<br>
&gt; [ =A0 47.997605] RSP: e02b:ffff880025685c98 =A0EFLAGS: 00010286<br>
&gt; [ =A0 48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX: 0000=
000000000000<br>
&gt; [ =A0 48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI: ffff=
88002de40000<br>
&gt; [ =A0 48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09: 0000=
000000000000<br>
&gt; [ =A0 48.024520] R10: 0000000000000030 R11: 0000000000000000 R12: ffff=
88002de40000<br>
&gt; [ =A0 48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15: 0000=
000000000000<br>
&gt; [ =A0 48.038927] FS: =A000007fb599d0e700(0000) GS:ffff88002de00000(000=
0) knlGS:0000000000000000<br>
&gt; [ =A0 48.047060] CS: =A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b<b=
r>
&gt; [ =A0 48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4: 0000=
000000002660<br>
&gt; [ =A0 48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000=
000000000000<br>
&gt; [ =A0 48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000=
000000000400<br>
&gt; [ =A0 48.074450] Process pm-suspend (pid: 2468, threadinfo ffff8800256=
84000, task ffff880003558000)<br>
&gt; [ =A0 48.083102] Stack:<br>
&gt; [ =A0 48.085179] =A0ffff88002de40000 ffff88002de40000 00000000ffffffde=
 ffffffff81a6b480<br>
&gt; [ =A0 48.092622] =A0ffff880025685cd8 ffffffff81491cc1 0000000000000001=
 ffff88002de40000<br>
&gt; [ =A0 48.100064] =A0ffff880025685cf8 ffffffff813046df 0000000000000001=
 0000000000000001<br>
&gt; [ =A0 48.107517] Call Trace:<br>
&gt; [ =A0 48.110029] =A0[&lt;ffffffff81491cc1&gt;] cpuidle_register_device=
+0x31/0x80<br>
&gt; [ =A0 48.116348] =A0[&lt;ffffffff813046df&gt;] intel_idle_cpu_init+0xb=
f/0x120<br>
&gt; [ =A0 48.122423] =A0[&lt;ffffffff813047b0&gt;] cpu_hotplug_notify+0x70=
/0x80<br>
&gt; [ =A0 48.128310] =A0[&lt;ffffffff815a619d&gt;] notifier_call_chain+0x4=
d/0x70<br>
&gt; [ =A0 48.134281] =A0[&lt;ffffffff8107969e&gt;] __raw_notifier_call_cha=
in+0xe/0x10<br>
&gt; [ =A0 48.140686] =A0[&lt;ffffffff81053bb0&gt;] __cpu_notify+0x20/0x40<=
br>
&gt; [ =A0 48.146050] =A0[&lt;ffffffff81594c7c&gt;] _cpu_up+0xf1/0x138<br>
&gt; [ =A0 48.151070] =A0[&lt;ffffffff8158ab39&gt;] enable_nonboot_cpus+0x9=
9/0xd0<br>
&gt; [ =A0 48.157090] =A0[&lt;ffffffff81097b8d&gt;] suspend_devices_and_ent=
er+0x25d/0x330<br>
&gt; [ =A0 48.163752] =A0[&lt;ffffffff81097def&gt;] pm_suspend+0x18f/0x1f0<=
br>
&gt; [ =A0 48.169117] =A0[&lt;ffffffff81096dea&gt;] state_store+0x8a/0x100<=
br>
&gt; [ =A0 48.174483] =A0[&lt;ffffffff812ac29f&gt;] kobj_attr_store+0xf/0x3=
0<br>
&gt; [ =A0 48.180022] =A0[&lt;ffffffff811c005f&gt;] sysfs_write_file+0xef/0=
x170<br>
&gt; [ =A0 48.185943] =A0[&lt;ffffffff8115c253&gt;] vfs_write+0xb3/0x180<br=
>
&gt; [ =A0 48.191056] =A0[&lt;ffffffff8115c592&gt;] sys_write+0x52/0xa0<br>
&gt; [ =A0 48.196160] =A0[&lt;ffffffff815a614e&gt;] ? do_page_fault+0xe/0x1=
0<br>
&gt; [ =A0 48.201700] =A0[&lt;ffffffff815aa7d9&gt;] system_call_fastpath+0x=
16/0x1b<br>
&gt; [ =A0 48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d=
 e0 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a=
 00 00&lt;48&gt; =A08b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 4=
9 c7<br>

&gt; [ =A0 48.226658] RIP =A0[&lt;ffffffff8149196b&gt;] __cpuidle_register_=
device+0x2b/0x100<br>
<br>
</div></div>Hm, that is suspect. There should not be any cpuidle_register? =
Perhaps<br>
you are .. ah yes, you are hitting a bug that should be in the stable<br>
tree fix.<br>
<br>
Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and<br>
6f8c2e7933679f54b6478945dc72e59ef9a3d5e0<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; [ =A0 48.233582] =A0RSP&lt;ffff880025685c98&gt;<br>
&gt; [ =A0 48.237131] CR2: 0000000000000008<br>
&gt;<br>
&gt; [ =A0 48.240521] ---[ end trace 535ebe28cd06b143 ]---<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--20cf3074afa8a3d1c604d531c58b--


--===============8694149927345817112==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8694149927345817112==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 13:42:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 13:42: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 1U3oDb-0002ge-LK; Fri, 08 Feb 2013 13:42:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U3igL-00022Y-D9
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 07:47:37 +0000
Received: from [85.158.139.83:44848] by server-11.bemta-5.messagelabs.com id
	31/1B-19159-89DA4115; Fri, 08 Feb 2013 07:47:36 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360309653!20109672!1
X-Originating-IP: [209.85.216.172]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15967 invoked from network); 8 Feb 2013 07:47:34 -0000
Received: from mail-qc0-f172.google.com (HELO mail-qc0-f172.google.com)
	(209.85.216.172)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 07:47:34 -0000
Received: by mail-qc0-f172.google.com with SMTP id b25so1328349qca.31
	for <xen-devel@lists.xen.org>; Thu, 07 Feb 2013 23:47:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=NxUInLxRYiIaZPrZuQOx9aK/IrkIjK86jaxAivAc+dY=;
	b=iqH0/tiDk9GDyzE66iRkNvVkZ+UtNB+H/M5qv7ukbtfILuWIkMQTIaz3XrmXdY/B4f
	bCusA9djvlWJSCE8EHg6KVRgDw6Qn18n9a/v56Aa26IwjtdBsWFp3xQoNe8z11BEpYbt
	iURJWCpQ2MNAqXuS+k5K5uuvS3Xm6iskYIyiJlx87UuXZhNAR7qHpzkd3RKYgtZsEQAf
	89pi/7pD0ABQx/Wb8wa6I7snDvcLaYdobxmS6T0CQt/jBPhRYV+jjf7bgVVDLX9R74Z9
	yrQZ5VdLQNagcfZPzj+bZM1vY8Q3CegizwDnTa+OT96yUtooqZ+9BF1xTMBJ2RZAF91S
	95Gw==
MIME-Version: 1.0
X-Received: by 10.224.52.68 with SMTP id h4mr1727624qag.17.1360309652803; Thu,
	07 Feb 2013 23:47:32 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Thu, 7 Feb 2013 23:47:32 -0800 (PST)
In-Reply-To: <20130205183236.GB5652@konrad-lan.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
Date: Fri, 8 Feb 2013 08:47:32 +0100
Message-ID: <CAKbSZ9ZR7zUzMyT0-Ti4ObN-+Ag0F8YdW5NhnAz2=Bq6BRcyxw@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 08 Feb 2013 13:42:18 +0000
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============8694149927345817112=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8694149927345817112==
Content-Type: multipart/alternative; boundary=20cf3074afa8a3d1c604d531c58b

--20cf3074afa8a3d1c604d531c58b
Content-Type: text/plain; charset=ISO-8859-1

Thank you for your help guys. I tried to apply those patches, but I didn't
succeed.
Konrard's acpi-s3 worked (in sence I didn't get error while patching), but
the patches from Ben not. Arch linux is using pretty much vanilla kernel
with only 3 patches applied(upstream patch, default console loglevel patch
and fat issue patch), and it seems I'm missing a whole lot of things there.
For instance, the 'fix-dmar-zap-reinstate.txt' requires /xen/drivers/
folder, but in my kernel source it is missing (there is xen, but no
drivers).

I'm not familiar with custom kernel building (this was my first time), but
I would say I'm missing some xen patches that should be applied priror to
those of Ben.
Could you please give me a hint on how can I proceed or what kernel did you
use?
Thank you very much for your time.


2013/2/5 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> On Mon, Feb 04, 2013 at 11:07:23AM +0100, Tomasz Wroblewski wrote:
> >
> > >>fix-suspend-scheduler-v2
> > >>fix-suspend-scheduler-revert-affinity-part
> > >>s3-timerirq
> > >>
> > >>All of these fixes have been proposed to the xen-devel list, but have
> > >>not yet been accepted, for one reason, or another.
> > >And I don't think comments on them have seen follow-ups.
> > >
> > >Jan
> > >
> > I guess it's worth bringing this up again;
> >
> > s3-timerirq: this was empirical hack which for some reason is needed
> > on stable 4.2 we use, but not on latest unstable, didn't really
> > investigate further since it appeared fixed later on anyway..
> >
> > fix-suspend-scheduler/revert-affinity: the big objection here was
> > the part which reverts one of the hunks in Keir's commit. I tried
> > for quite few days to find a working fix which does not do this
> > revert using posted suggestions, but was not succesfull:
> >
> > - there was a crash in xen scheduler, which was fixable using your
> > suggestion of masking softirqs during s3 (ugly)
> > - there was also a crash in xen acpi cpufreq driver, which was
> > similarily fixable using a bandaid s3 condition (ugly)
> > - unfortunately this turned out to not be all, xen did not crash
> > anymore at this point but dom0 kernel did around the time it enables
> > cpus, in multiple places: at this point I didn't have a good
> > explanation for it, my opinion of aggravating hunk was rather low,
> > so I uttered a hearty curse and stuck a revert into private
> > patchqueue.
> >
> > The dom0 kernel crashes were as follows:
> >
> > 1)
> >
> > [   60.657751] Enabling non-boot CPUs ...
> > [   60.657958] installing Xen timer for CPU 1
> > [   60.657987] cpu 1 spinlock event irq 279
> > [   60.658101] Disabled fast string operations
> > [   60.658466] CPU1 is up
> > [   60.658736] installing Xen timer for CPU 2
> > [   60.658784] cpu 2 spinlock event irq 285
> > [   60.659764] Disabled fast string operations
> > [   60.661811] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000018
> > [   60.661817] IP: [<ffffffff8105f700>]
> > build_sched_domains+0x770/0(XEN) *** Serial input -> Xen (type
> > 'CTRL-a' three times to switch input to DOM0)
> >
> >
> >
> >
> > 2)
> > .332997] installing Xen timer for CPU 2emory
> > [   36.333061] cpu 2 spinlock event irq 285
> > [   36.333343] Disabled fast string operations
> > [   36.334939] CPU2 is up
> > [   36.335213] installing Xen timer for CPU 3
> > [   36.335244] cpu 3 spinlock event irq 291
> > [   36.335561] Disabled fast string operations
> > [   36.337461] CPU3 is up
> > [   36.339513] ACPI: Waking up from system sleep state S3
> > [   36.350193] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000004
> > [   36.350211] IP: [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> > [   36.350236] PGD 2f19067 PUD 2ec7067 PMD 0
> > [   36.350252] Oops: 0000 [#1] SMP
> > [   36.350263] CPU 1
> > [   36.350267] Modules linked in: xt_mac ipt_MASQUERADE
> > ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> > xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> > nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> > ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> > snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> > serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> > thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> > snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> > intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> > [   36.350437]
> > [   36.350445] Pid: 2730, comm: bash Tainted: G         C O
> > 3.2.23-orc #19 LENOVO 42404EU/42404EU
> > [   36.350463] RIP: e030:[<ffffffff81055f9a>]  [<ffffffff81055f9a>]
> > find_busiest_group+0x38a/0xbb0
> > [   36.350481] RSP: e02b:ffff880002b71228  EFLAGS: 00010046
> > [   36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX:
> > 0000000000000000
> > [   36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
> > 0000000000000000
> > [   36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09:
> > 0000000000000000
> > [   36.350519] R10: 0000000000000000 R11: 0000000000000001 R12:
> > 0000000000000000
> > [   36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15:
> > ffff880026109f98
> > [   36.350547] FS:  00007fc41e295700(0000) GS:ffff88002dc40000(0000)
> > knlGS:0000000000000000
> > [   36.350558] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [   36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4:
> > 0000000000002660
> > [   36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> > 0000000000000000
> > [   36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> > 0000000000000400
> > [   36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000,
> > task ffff880027a7db40)
> > [   36.350608] Stack:
> > [   36.350613]  00ffffff00000002 0000000300000001 ffff880002b71498
> > ffff880002b71534
> > [   36.350630]  00ffffff00000002 0000000100000001 ffff8800262cf000
> > 0000000000000008
> > [   36.350646]  ffffffff00000000 0000000000000000 0000000000000000
> > ffff88002dc4e2c8
> > [   36.350662] Call Trace:
> > [   36.350677]  [<ffffffff8105b158>] load_balance+0xb8/0x840
> > [   36.350690]  [<ffffffff8101b909>] ? sched_clock+0x9/0x10
> > [   36.350706]  [<ffffffff8108ccad>] ? sched_clock_cpu+0xbd/0x110
> > [   36.350718]  [<ffffffff81052b1c>] ? update_shares+0xcc/0x100
> > [   36.350735]  [<ffffffff8157b9b5>] __schedule+0x875/0x8d0
> > [   36.350749]  [<ffffffff81073ae2>] ? try_to_del_timer_sync+0x92/0x130
> > [   36.350762]  [<ffffffff8157bd3f>] schedule+0x3f/0x60
> > [   36.350773]  [<ffffffff8157c24d>] schedule_timeout+0x16d/0x320
> > [   36.350786]  [<ffffffff810728e0>] ? usleep_range+0x50/0x50
> > [   36.350800]  [<ffffffff8157de2e>] ?
> _raw_spin_unlock_irqrestore+0x1e/0x30
> > [   36.350817]  [<ffffffff8130c340>]
> > acpi_ec_transaction_unlocked+0x134/0x1d8
> > [   36.350830]  [<ffffffff81086b90>] ? add_wait_queue+0x60/0x60
> > [   36.350842]  [<ffffffff8130c6c6>] acpi_ec_transaction+0x196/0x239
> > [   36.350856]  [<ffffffff8157de2e>] ?
> _raw_spin_unlock_irqrestore+0x1e/0x30
> > [   36.350869]  [<ffffffff8130c8a0>] acpi_ec_write+0x40/0x42
> > [   36.350881]  [<ffffffff8130c9a8>] acpi_ec_space_handler+0x9e/0xfc
> > [   36.350894]  [<ffffffff8130c90a>] ? acpi_ec_burst_disable+0x3d/0x3d
> > [   36.350909]  [<ffffffff813159c6>]
> > acpi_ev_address_space_dispatch+0x179/0x1c8
> > [   36.350924]  [<ffffffff8131aafe>] acpi_ex_access_region+0x23e/0x24b
> > [   36.350936]  [<ffffffff8106e82c>] ? __sysctl_head_next+0x11c/0x130
> > [   36.350951]  [<ffffffff8131ae15>] acpi_ex_field_datum_io+0xf9/0x17a
> > [   36.350965]  [<ffffffff8131b148>]
> > acpi_ex_write_with_update_rule+0xb5/0xc1
> > [   36.350989]  [<ffffffff8131acfa>]
> acpi_ex_insert_into_field+0x1ef/0x211
> > [   36.351003]  [<ffffffff8132b5a7>] ?
> > acpi_ut_allocate_object_desc_dbg+0x45/0x7f
> > [   36.351018]  [<ffffffff8131980e>]
> acpi_ex_write_data_to_field+0x194/0x1c2
> > [   36.351031]  [<ffffffff813131e4>] ?
> > acpi_ds_init_object_from_op+0x137/0x231
> > [   36.351044]  [<ffffffff8131d94f>]
> acpi_ex_store_object_to_node+0xa3/0xe2
> > [   36.351056]  [<ffffffff8131da51>] acpi_ex_store+0xc3/0x256
> > [   36.351066]  [<ffffffff8131b62b>] acpi_ex_opcode_1A_1T_1R+0x353/0x4a5
> > [   36.351078]  [<ffffffff8131260c>] acpi_ds_exec_end_op+0xf7/0x3e7
> > [   36.351092]  [<ffffffff81325ae7>] acpi_ps_parse_loop+0x7bd/0x94e
> > [   36.351105]  [<ffffffff81324ed9>] acpi_ps_parse_aml+0x96/0x275
> > [   36.351119]  [<ffffffff81326394>] acpi_ps_execute_method+0x1ce/0x276
> > [   36.351131]  [<ffffffff8132165b>] acpi_ns_evaluate+0xdf/0x1aa
> > [   36.351144]  [<ffffffff81320c9d>] acpi_evaluate_object+0xfb/0x1f4
> > [   36.351156]  [<ffffffff8130f8ee>] acpi_device_sleep_wake+0x95/0xc7
> > [   36.351168]  [<ffffffff8130fa60>]
> > acpi_disable_wakeup_device_power+0x6e/0xc9
> > [   36.351182]  [<ffffffff813085e2>]
> acpi_disable_wakeup_devices+0x7b/0x95
> > [   36.351194]  [<ffffffff81308710>] acpi_pm_finish+0x39/0x55
> > [   36.351208]  [<ffffffff810a6034>]
> suspend_devices_and_enter+0x104/0x310
> > [   36.351222]  [<ffffffff810a63a7>] enter_state+0x167/0x190
> > [   36.351234]  [<ffffffff810a4d27>] state_store+0xb7/0x130
> > [   36.351246]  [<ffffffff812b54df>] kobj_attr_store+0xf/0x30
> > [   36.351260]  [<ffffffff811d382f>] sysfs_write_file+0xef/0x170
> > [   36.351274]  [<ffffffff811668d3>] vfs_write+0xb3/0x180
> > [   36.351286]  [<ffffffff81166bfa>] sys_write+0x4a/0x90
> > [   36.351300]  [<ffffffff81585d02>] system_call_fastpath+0x16/0x1b
> > [   36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8
> > 5d fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b
> > 4d 98 31 d2 <8b> 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0 48
> > 85 c9 48
> > [   36.351435] RIP  [<ffffffff81055f9a>] find_busiest_group+0x38a/0xbb0
> > [   36.351450]  RSP <ffff880002b71228>
> > [   36.351456] CR2: 0000000000000004
> > [   36.351465] ---[ end trace 5ad2b14b3a9050ae ]---
> > [   36.352362] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000010
> > [   36.352379] IP: [<ffffffff812ba531>] rb_next+0x1/0x50
> > [   36.352394] PGD 0
> > [   36.352402] Oops: 0000 [#2] SMP
> > [   36.352411] CPU 1
> > [   36.352416] Modules linked in: xt_mac ipt_MASQUERADE
> > ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)
> > xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat
> > nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4
> > ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)
> > snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse
> > serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)
> > thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> > snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video
> > intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e
> > [   36.352573]
> > [   36.352580] Pid: 2730, comm: bash Tainted: G      D  C O
> > 3.2.23-orc #19 LENOVO 42404EU/42404EU
> > [   36.352596] RIP: e030:[<ffffffff812ba531>]  [<fffffff
> >
> >
> >
> >
> > 3)
> >
> > [   47.833362] Resuming Xen processor info
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > (XEN) microcode: collect_cpu_info : sig=0x206a6, pf=0x10, rev=0x28
> > [   47.886297] Enabling non-boot CPUs ...
> > [   47.890082] installing Xen timer for CPU 1
> > [   47.894257] cpu 1 spinlock event irq 48
> > [   47.899013] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000008
> > [   47.906740] IP: [<ffffffff8149196b>]
> __cpuidle_register_device+0x2b/0x100
> > [   47.913578] PGD 34a4067 PUD 3ac3067 PMD 0
> > [   47.917825] Oops: 0000 [#1] SMP
> > [   47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebtables
> iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdisk(O)
> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> nf_conntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs
> bridge stp llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp
> crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw
> aes_x86_64 xts gf128mul microcode psmouse serio_raw arc4 iwldvm mac80211
> i915 drm_kms_helper drm iwlwifi intel_agp i2c_algo_bit cfg80211 intel_gtt
> video ahci libahci e1000e [last unloaded: tpm_bios]
> > [   47.974636] CPU 0
> > [   47.976456] Pid: 2468, comm: pm-suspend Tainted: G         C O
> 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake
> > [   47.988310] RIP: e030:[<ffffffff8149196b>]  [<ffffffff8149196b>]
> __cpuidle_register_device+0x2b/0x100
> > [   47.997605] RSP: e02b:ffff880025685c98  EFLAGS: 00010286
> > [   48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX:
> 0000000000000000
> > [   48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI:
> ffff88002de40000
> > [   48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09:
> 0000000000000000
> > [   48.024520] R10: 0000000000000030 R11: 0000000000000000 R12:
> ffff88002de40000
> > [   48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15:
> 0000000000000000
> > [   48.038927] FS:  00007fb599d0e700(0000) GS:ffff88002de00000(0000)
> knlGS:0000000000000000
> > [   48.047060] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [   48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4:
> 0000000000002660
> > [   48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> > [   48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> > [   48.074450] Process pm-suspend (pid: 2468, threadinfo
> ffff880025684000, task ffff880003558000)
> > [   48.083102] Stack:
> > [   48.085179]  ffff88002de40000 ffff88002de40000 00000000ffffffde
> ffffffff81a6b480
> > [   48.092622]  ffff880025685cd8 ffffffff81491cc1 0000000000000001
> ffff88002de40000
> > [   48.100064]  ffff880025685cf8 ffffffff813046df 0000000000000001
> 0000000000000001
> > [   48.107517] Call Trace:
> > [   48.110029]  [<ffffffff81491cc1>] cpuidle_register_device+0x31/0x80
> > [   48.116348]  [<ffffffff813046df>] intel_idle_cpu_init+0xbf/0x120
> > [   48.122423]  [<ffffffff813047b0>] cpu_hotplug_notify+0x70/0x80
> > [   48.128310]  [<ffffffff815a619d>] notifier_call_chain+0x4d/0x70
> > [   48.134281]  [<ffffffff8107969e>] __raw_notifier_call_chain+0xe/0x10
> > [   48.140686]  [<ffffffff81053bb0>] __cpu_notify+0x20/0x40
> > [   48.146050]  [<ffffffff81594c7c>] _cpu_up+0xf1/0x138
> > [   48.151070]  [<ffffffff8158ab39>] enable_nonboot_cpus+0x99/0xd0
> > [   48.157090]  [<ffffffff81097b8d>]
> suspend_devices_and_enter+0x25d/0x330
> > [   48.163752]  [<ffffffff81097def>] pm_suspend+0x18f/0x1f0
> > [   48.169117]  [<ffffffff81096dea>] state_store+0x8a/0x100
> > [   48.174483]  [<ffffffff812ac29f>] kobj_attr_store+0xf/0x30
> > [   48.180022]  [<ffffffff811c005f>] sysfs_write_file+0xef/0x170
> > [   48.185943]  [<ffffffff8115c253>] vfs_write+0xb3/0x180
> > [   48.191056]  [<ffffffff8115c592>] sys_write+0x52/0xa0
> > [   48.196160]  [<ffffffff815a614e>] ? do_page_fault+0xe/0x10
> > [   48.201700]  [<ffffffff815aa7d9>] system_call_fastpath+0x16/0x1b
> > [   48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e0
> 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a 00
> 00<48>  8b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 49 c7
> > [   48.226658] RIP  [<ffffffff8149196b>]
> __cpuidle_register_device+0x2b/0x100
>
> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> you are .. ah yes, you are hitting a bug that should be in the stable
> tree fix.
>
> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
>
> > [   48.233582]  RSP<ffff880025685c98>
> > [   48.237131] CR2: 0000000000000008
> >
> > [   48.240521] ---[ end trace 535ebe28cd06b143 ]---
> >
> >
> >
>

--20cf3074afa8a3d1c604d531c58b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Thank you for your help guys. I t=
ried to apply those patches, but I didn&#39;t succeed.<br></div>Konrard&#39=
;s acpi-s3 worked (in sence I didn&#39;t get error while patching), but the=
 patches from Ben not. Arch linux is using pretty much vanilla kernel with =
only 3 patches applied(upstream patch, default console loglevel patch and f=
at issue patch), and it seems I&#39;m missing a whole lot of things there. =
<br>
</div>For instance, the &#39;fix-dmar-zap-reinstate.txt&#39; requires /xen/=
drivers/ folder, but in my kernel source it is missing (there is xen, but n=
o drivers). <br><br></div>I&#39;m not familiar with custom kernel building =
(this was my first time), but I would say I&#39;m missing some xen patches =
that should be applied priror to those of Ben. <br>
</div>Could you please give me a hint on how can I proceed or what kernel d=
id you use? <br></div>Thank you very much for your time.<br></div><div clas=
s=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/2/5 Konrad Rzeszu=
tek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@oracle.com" ta=
rget=3D"_blank">konrad.wilk@oracle.com</a>&gt;</span><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 M=
on, Feb 04, 2013 at 11:07:23AM +0100, Tomasz Wroblewski wrote:<br>
&gt;<br>
&gt; &gt;&gt;fix-suspend-scheduler-v2<br>
&gt; &gt;&gt;fix-suspend-scheduler-revert-affinity-part<br>
&gt; &gt;&gt;s3-timerirq<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;All of these fixes have been proposed to the xen-devel list, b=
ut have<br>
&gt; &gt;&gt;not yet been accepted, for one reason, or another.<br>
&gt; &gt;And I don&#39;t think comments on them have seen follow-ups.<br>
&gt; &gt;<br>
&gt; &gt;Jan<br>
&gt; &gt;<br>
&gt; I guess it&#39;s worth bringing this up again;<br>
&gt;<br>
&gt; s3-timerirq: this was empirical hack which for some reason is needed<b=
r>
&gt; on stable 4.2 we use, but not on latest unstable, didn&#39;t really<br=
>
&gt; investigate further since it appeared fixed later on anyway..<br>
&gt;<br>
&gt; fix-suspend-scheduler/revert-affinity: the big objection here was<br>
&gt; the part which reverts one of the hunks in Keir&#39;s commit. I tried<=
br>
&gt; for quite few days to find a working fix which does not do this<br>
&gt; revert using posted suggestions, but was not succesfull:<br>
&gt;<br>
&gt; - there was a crash in xen scheduler, which was fixable using your<br>
&gt; suggestion of masking softirqs during s3 (ugly)<br>
&gt; - there was also a crash in xen acpi cpufreq driver, which was<br>
&gt; similarily fixable using a bandaid s3 condition (ugly)<br>
&gt; - unfortunately this turned out to not be all, xen did not crash<br>
&gt; anymore at this point but dom0 kernel did around the time it enables<b=
r>
&gt; cpus, in multiple places: at this point I didn&#39;t have a good<br>
&gt; explanation for it, my opinion of aggravating hunk was rather low,<br>
&gt; so I uttered a hearty curse and stuck a revert into private<br>
&gt; patchqueue.<br>
&gt;<br>
&gt; The dom0 kernel crashes were as follows:<br>
&gt;<br>
&gt; 1)<br>
&gt;<br>
&gt; [ =A0 60.657751] Enabling non-boot CPUs ...<br>
&gt; [ =A0 60.657958] installing Xen timer for CPU 1<br>
&gt; [ =A0 60.657987] cpu 1 spinlock event irq 279<br>
&gt; [ =A0 60.658101] Disabled fast string operations<br>
&gt; [ =A0 60.658466] CPU1 is up<br>
&gt; [ =A0 60.658736] installing Xen timer for CPU 2<br>
&gt; [ =A0 60.658784] cpu 2 spinlock event irq 285<br>
&gt; [ =A0 60.659764] Disabled fast string operations<br>
&gt; [ =A0 60.661811] BUG: unable to handle kernel NULL pointer dereference=
<br>
&gt; at 0000000000000018<br>
&gt; [ =A0 60.661817] IP: [&lt;ffffffff8105f700&gt;]<br>
&gt; build_sched_domains+0x770/0(XEN) *** Serial input -&gt; Xen (type<br>
&gt; &#39;CTRL-a&#39; three times to switch input to DOM0)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; 2)<br>
&gt; .332997] installing Xen timer for CPU 2emory<br>
&gt; [ =A0 36.333061] cpu 2 spinlock event irq 285<br>
&gt; [ =A0 36.333343] Disabled fast string operations<br>
&gt; [ =A0 36.334939] CPU2 is up<br>
&gt; [ =A0 36.335213] installing Xen timer for CPU 3<br>
&gt; [ =A0 36.335244] cpu 3 spinlock event irq 291<br>
&gt; [ =A0 36.335561] Disabled fast string operations<br>
&gt; [ =A0 36.337461] CPU3 is up<br>
&gt; [ =A0 36.339513] ACPI: Waking up from system sleep state S3<br>
&gt; [ =A0 36.350193] BUG: unable to handle kernel NULL pointer dereference=
<br>
&gt; at 0000000000000004<br>
&gt; [ =A0 36.350211] IP: [&lt;ffffffff81055f9a&gt;] find_busiest_group+0x3=
8a/0xbb0<br>
&gt; [ =A0 36.350236] PGD 2f19067 PUD 2ec7067 PMD 0<br>
&gt; [ =A0 36.350252] Oops: 0000 [#1] SMP<br>
&gt; [ =A0 36.350263] CPU 1<br>
&gt; [ =A0 36.350267] Modules linked in: xt_mac ipt_MASQUERADE<br>
&gt; ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)<br>
&gt; xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat<br>
&gt; nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4<br>
&gt; ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)<br>
&gt; snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse<br>
&gt; serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)<b=
r>
&gt; thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm<br>
&gt; snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video<br=
>
&gt; intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e<br>
&gt; [ =A0 36.350437]<br>
&gt; [ =A0 36.350445] Pid: 2730, comm: bash Tainted: G =A0 =A0 =A0 =A0 C O<=
br>
&gt; 3.2.23-orc #19 LENOVO 42404EU/42404EU<br>
&gt; [ =A0 36.350463] RIP: e030:[&lt;ffffffff81055f9a&gt;] =A0[&lt;ffffffff=
81055f9a&gt;]<br>
&gt; find_busiest_group+0x38a/0xbb0<br>
&gt; [ =A0 36.350481] RSP: e02b:ffff880002b71228 =A0EFLAGS: 00010046<br>
&gt; [ =A0 36.350490] RAX: 0000000000000040 RBX: 0000000000000000 RCX:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350500] RDX: 0000000000000000 RSI: 0000000000000040 RDI:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350510] RBP: ffff880002b713b8 R08: ffff880026109f00 R09:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350519] R10: 0000000000000000 R11: 0000000000000001 R12:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350529] R13: ffff880026109f80 R14: ffffffffffffffff R15:<br>
&gt; ffff880026109f98<br>
&gt; [ =A0 36.350547] FS: =A000007fc41e295700(0000) GS:ffff88002dc40000(000=
0)<br>
&gt; knlGS:0000000000000000<br>
&gt; [ =A0 36.350558] CS: =A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b<b=
r>
&gt; [ =A0 36.350566] CR2: 0000000000000004 CR3: 0000000026329000 CR4:<br>
&gt; 0000000000002660<br>
&gt; [ =A0 36.350577] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br>
&gt; 0000000000000000<br>
&gt; [ =A0 36.350587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:<br>
&gt; 0000000000000400<br>
&gt; [ =A0 36.350598] Process bash (pid: 2730, threadinfo ffff880002b70000,=
<br>
&gt; task ffff880027a7db40)<br>
&gt; [ =A0 36.350608] Stack:<br>
&gt; [ =A0 36.350613] =A000ffffff00000002 0000000300000001 ffff880002b71498=
<br>
&gt; ffff880002b71534<br>
&gt; [ =A0 36.350630] =A000ffffff00000002 0000000100000001 ffff8800262cf000=
<br>
&gt; 0000000000000008<br>
&gt; [ =A0 36.350646] =A0ffffffff00000000 0000000000000000 0000000000000000=
<br>
&gt; ffff88002dc4e2c8<br>
&gt; [ =A0 36.350662] Call Trace:<br>
&gt; [ =A0 36.350677] =A0[&lt;ffffffff8105b158&gt;] load_balance+0xb8/0x840=
<br>
&gt; [ =A0 36.350690] =A0[&lt;ffffffff8101b909&gt;] ? sched_clock+0x9/0x10<=
br>
&gt; [ =A0 36.350706] =A0[&lt;ffffffff8108ccad&gt;] ? sched_clock_cpu+0xbd/=
0x110<br>
&gt; [ =A0 36.350718] =A0[&lt;ffffffff81052b1c&gt;] ? update_shares+0xcc/0x=
100<br>
&gt; [ =A0 36.350735] =A0[&lt;ffffffff8157b9b5&gt;] __schedule+0x875/0x8d0<=
br>
&gt; [ =A0 36.350749] =A0[&lt;ffffffff81073ae2&gt;] ? try_to_del_timer_sync=
+0x92/0x130<br>
&gt; [ =A0 36.350762] =A0[&lt;ffffffff8157bd3f&gt;] schedule+0x3f/0x60<br>
&gt; [ =A0 36.350773] =A0[&lt;ffffffff8157c24d&gt;] schedule_timeout+0x16d/=
0x320<br>
&gt; [ =A0 36.350786] =A0[&lt;ffffffff810728e0&gt;] ? usleep_range+0x50/0x5=
0<br>
&gt; [ =A0 36.350800] =A0[&lt;ffffffff8157de2e&gt;] ? _raw_spin_unlock_irqr=
estore+0x1e/0x30<br>
&gt; [ =A0 36.350817] =A0[&lt;ffffffff8130c340&gt;]<br>
&gt; acpi_ec_transaction_unlocked+0x134/0x1d8<br>
&gt; [ =A0 36.350830] =A0[&lt;ffffffff81086b90&gt;] ? add_wait_queue+0x60/0=
x60<br>
&gt; [ =A0 36.350842] =A0[&lt;ffffffff8130c6c6&gt;] acpi_ec_transaction+0x1=
96/0x239<br>
&gt; [ =A0 36.350856] =A0[&lt;ffffffff8157de2e&gt;] ? _raw_spin_unlock_irqr=
estore+0x1e/0x30<br>
&gt; [ =A0 36.350869] =A0[&lt;ffffffff8130c8a0&gt;] acpi_ec_write+0x40/0x42=
<br>
&gt; [ =A0 36.350881] =A0[&lt;ffffffff8130c9a8&gt;] acpi_ec_space_handler+0=
x9e/0xfc<br>
&gt; [ =A0 36.350894] =A0[&lt;ffffffff8130c90a&gt;] ? acpi_ec_burst_disable=
+0x3d/0x3d<br>
&gt; [ =A0 36.350909] =A0[&lt;ffffffff813159c6&gt;]<br>
&gt; acpi_ev_address_space_dispatch+0x179/0x1c8<br>
&gt; [ =A0 36.350924] =A0[&lt;ffffffff8131aafe&gt;] acpi_ex_access_region+0=
x23e/0x24b<br>
&gt; [ =A0 36.350936] =A0[&lt;ffffffff8106e82c&gt;] ? __sysctl_head_next+0x=
11c/0x130<br>
&gt; [ =A0 36.350951] =A0[&lt;ffffffff8131ae15&gt;] acpi_ex_field_datum_io+=
0xf9/0x17a<br>
&gt; [ =A0 36.350965] =A0[&lt;ffffffff8131b148&gt;]<br>
&gt; acpi_ex_write_with_update_rule+0xb5/0xc1<br>
&gt; [ =A0 36.350989] =A0[&lt;ffffffff8131acfa&gt;] acpi_ex_insert_into_fie=
ld+0x1ef/0x211<br>
&gt; [ =A0 36.351003] =A0[&lt;ffffffff8132b5a7&gt;] ?<br>
&gt; acpi_ut_allocate_object_desc_dbg+0x45/0x7f<br>
&gt; [ =A0 36.351018] =A0[&lt;ffffffff8131980e&gt;] acpi_ex_write_data_to_f=
ield+0x194/0x1c2<br>
&gt; [ =A0 36.351031] =A0[&lt;ffffffff813131e4&gt;] ?<br>
&gt; acpi_ds_init_object_from_op+0x137/0x231<br>
&gt; [ =A0 36.351044] =A0[&lt;ffffffff8131d94f&gt;] acpi_ex_store_object_to=
_node+0xa3/0xe2<br>
&gt; [ =A0 36.351056] =A0[&lt;ffffffff8131da51&gt;] acpi_ex_store+0xc3/0x25=
6<br>
&gt; [ =A0 36.351066] =A0[&lt;ffffffff8131b62b&gt;] acpi_ex_opcode_1A_1T_1R=
+0x353/0x4a5<br>
&gt; [ =A0 36.351078] =A0[&lt;ffffffff8131260c&gt;] acpi_ds_exec_end_op+0xf=
7/0x3e7<br>
&gt; [ =A0 36.351092] =A0[&lt;ffffffff81325ae7&gt;] acpi_ps_parse_loop+0x7b=
d/0x94e<br>
&gt; [ =A0 36.351105] =A0[&lt;ffffffff81324ed9&gt;] acpi_ps_parse_aml+0x96/=
0x275<br>
&gt; [ =A0 36.351119] =A0[&lt;ffffffff81326394&gt;] acpi_ps_execute_method+=
0x1ce/0x276<br>
&gt; [ =A0 36.351131] =A0[&lt;ffffffff8132165b&gt;] acpi_ns_evaluate+0xdf/0=
x1aa<br>
&gt; [ =A0 36.351144] =A0[&lt;ffffffff81320c9d&gt;] acpi_evaluate_object+0x=
fb/0x1f4<br>
&gt; [ =A0 36.351156] =A0[&lt;ffffffff8130f8ee&gt;] acpi_device_sleep_wake+=
0x95/0xc7<br>
&gt; [ =A0 36.351168] =A0[&lt;ffffffff8130fa60&gt;]<br>
&gt; acpi_disable_wakeup_device_power+0x6e/0xc9<br>
&gt; [ =A0 36.351182] =A0[&lt;ffffffff813085e2&gt;] acpi_disable_wakeup_dev=
ices+0x7b/0x95<br>
&gt; [ =A0 36.351194] =A0[&lt;ffffffff81308710&gt;] acpi_pm_finish+0x39/0x5=
5<br>
&gt; [ =A0 36.351208] =A0[&lt;ffffffff810a6034&gt;] suspend_devices_and_ent=
er+0x104/0x310<br>
&gt; [ =A0 36.351222] =A0[&lt;ffffffff810a63a7&gt;] enter_state+0x167/0x190=
<br>
&gt; [ =A0 36.351234] =A0[&lt;ffffffff810a4d27&gt;] state_store+0xb7/0x130<=
br>
&gt; [ =A0 36.351246] =A0[&lt;ffffffff812b54df&gt;] kobj_attr_store+0xf/0x3=
0<br>
&gt; [ =A0 36.351260] =A0[&lt;ffffffff811d382f&gt;] sysfs_write_file+0xef/0=
x170<br>
&gt; [ =A0 36.351274] =A0[&lt;ffffffff811668d3&gt;] vfs_write+0xb3/0x180<br=
>
&gt; [ =A0 36.351286] =A0[&lt;ffffffff81166bfa&gt;] sys_write+0x4a/0x90<br>
&gt; [ =A0 36.351300] =A0[&lt;ffffffff81585d02&gt;] system_call_fastpath+0x=
16/0x1b<br>
&gt; [ =A0 36.351308] Code: ff 48 8b bd a0 fe ff ff 44 88 85 78 fe ff ff e8=
<br>
&gt; 5d fb ff ff 44 0f b6 85 78 fe ff ff 0f 1f 44 00 00 49 8b 7d 10 4c 8b<b=
r>
&gt; 4d 98 31 d2 &lt;8b&gt; 4f 04 4c 89 c8 48 c1 e0 0a 48 f7 f1 48 8b 4d a0=
 48<br>
&gt; 85 c9 48<br>
&gt; [ =A0 36.351435] RIP =A0[&lt;ffffffff81055f9a&gt;] find_busiest_group+=
0x38a/0xbb0<br>
&gt; [ =A0 36.351450] =A0RSP &lt;ffff880002b71228&gt;<br>
&gt; [ =A0 36.351456] CR2: 0000000000000004<br>
&gt; [ =A0 36.351465] ---[ end trace 5ad2b14b3a9050ae ]---<br>
&gt; [ =A0 36.352362] BUG: unable to handle kernel NULL pointer dereference=
<br>
&gt; at 0000000000000010<br>
&gt; [ =A0 36.352379] IP: [&lt;ffffffff812ba531&gt;] rb_next+0x1/0x50<br>
&gt; [ =A0 36.352394] PGD 0<br>
&gt; [ =A0 36.352402] Oops: 0000 [#2] SMP<br>
&gt; [ =A0 36.352411] CPU 1<br>
&gt; [ =A0 36.352416] Modules linked in: xt_mac ipt_MASQUERADE<br>
&gt; ebtable_filter ebtables iscsi_scst(O) xt_tcpudp scst_vdisk(O)<br>
&gt; xt_state crc32c xt_multiport libcrc32c iptable_filter iptable_nat<br>
&gt; nf_nat nf_conntrack_ipv4 nf_conntrack scst_cdrom(O) nf_defrag_ipv4<br>
&gt; ip_tables scst(O) x_tables bridge stp llc nls_cp437 isofs zram(C)<br>
&gt; snd_hda_codec_hdmi snd_hda_codec_conexant microcode arc4 psmouse<br>
&gt; serio_raw i915 drm_kms_helper drm iwlwifi(O) mac80211(O) cfg80211(O)<b=
r>
&gt; thinkpad_acpi nvram snd_hda_intel snd_hda_codec snd_hwdep snd_pcm<br>
&gt; snd_timer snd soundcore snd_page_alloc i2c_algo_bit intel_agp video<br=
>
&gt; intel_gtt tpm_tis tpm tpm_bios sdhci_pci sdhci ehci_hcd e1000e<br>
&gt; [ =A0 36.352573]<br>
&gt; [ =A0 36.352580] Pid: 2730, comm: bash Tainted: G =A0 =A0 =A0D =A0C O<=
br>
&gt; 3.2.23-orc #19 LENOVO 42404EU/42404EU<br>
&gt; [ =A0 36.352596] RIP: e030:[&lt;ffffffff812ba531&gt;] =A0[&lt;fffffff<=
br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; 3)<br>
&gt;<br>
&gt; [ =A0 47.833362] Resuming Xen processor info<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x206a6, pf=3D0x10, rev=3D0x=
28<br>
&gt; [ =A0 47.886297] Enabling non-boot CPUs ...<br>
&gt; [ =A0 47.890082] installing Xen timer for CPU 1<br>
&gt; [ =A0 47.894257] cpu 1 spinlock event irq 48<br>
&gt; [ =A0 47.899013] BUG: unable to handle kernel NULL pointer dereference=
 at 0000000000000008<br>
&gt; [ =A0 47.906740] IP: [&lt;ffffffff8149196b&gt;] __cpuidle_register_dev=
ice+0x2b/0x100<br>
&gt; [ =A0 47.913578] PGD 34a4067 PUD 3ac3067 PMD 0<br>
&gt; [ =A0 47.917825] Oops: 0000 [#1] SMP<br>
&gt; [ =A0 47.921108] Modules linked in: ipt_MASQUERADE ebtable_filter ebta=
bles iscsi_scst(O) xt_tcpudp xt_state xt_multiport iptable_filter scst_vdis=
k(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_con=
ntrack scst_cdrom(O) ip_tables scst(O) x_tables nls_cp437 isofs bridge stp =
llc zram(C) zsmalloc(C) hid_generic usbhid hid coretemp crc32c_intel ghash_=
clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul mi=
crocode psmouse serio_raw arc4 iwldvm mac80211 i915 drm_kms_helper drm iwlw=
ifi intel_agp i2c_algo_bit cfg80211 intel_gtt video ahci libahci e1000e [la=
st unloaded: tpm_bios]<br>

&gt; [ =A0 47.974636] CPU 0<br>
&gt; [ =A0 47.976456] Pid: 2468, comm: pm-suspend Tainted: G =A0 =A0 =A0 =
=A0 C O 3.8.0-orc #19 Intel Corporation SandyBridge Platform/Emerald Lake<b=
r>
&gt; [ =A0 47.988310] RIP: e030:[&lt;ffffffff8149196b&gt;] =A0[&lt;ffffffff=
8149196b&gt;] __cpuidle_register_device+0x2b/0x100<br>
&gt; [ =A0 47.997605] RSP: e02b:ffff880025685c98 =A0EFLAGS: 00010286<br>
&gt; [ =A0 48.002970] RAX: 0000000000000000 RBX: ffff88002de40000 RCX: 0000=
000000000000<br>
&gt; [ =A0 48.010154] RDX: ffff880025685fd8 RSI: 0000000000000007 RDI: ffff=
88002de40000<br>
&gt; [ =A0 48.017336] RBP: ffff880025685cb8 R08: 0000000000021120 R09: 0000=
000000000000<br>
&gt; [ =A0 48.024520] R10: 0000000000000030 R11: 0000000000000000 R12: ffff=
88002de40000<br>
&gt; [ =A0 48.031742] R13: 00000000ffffffde R14: 00000000ffffffea R15: 0000=
000000000000<br>
&gt; [ =A0 48.038927] FS: =A000007fb599d0e700(0000) GS:ffff88002de00000(000=
0) knlGS:0000000000000000<br>
&gt; [ =A0 48.047060] CS: =A0e033 DS: 0000 ES: 0000 CR0: 000000008005003b<b=
r>
&gt; [ =A0 48.052859] CR2: 0000000000000008 CR3: 000000000345b000 CR4: 0000=
000000002660<br>
&gt; [ =A0 48.060043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000=
000000000000<br>
&gt; [ =A0 48.067223] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000=
000000000400<br>
&gt; [ =A0 48.074450] Process pm-suspend (pid: 2468, threadinfo ffff8800256=
84000, task ffff880003558000)<br>
&gt; [ =A0 48.083102] Stack:<br>
&gt; [ =A0 48.085179] =A0ffff88002de40000 ffff88002de40000 00000000ffffffde=
 ffffffff81a6b480<br>
&gt; [ =A0 48.092622] =A0ffff880025685cd8 ffffffff81491cc1 0000000000000001=
 ffff88002de40000<br>
&gt; [ =A0 48.100064] =A0ffff880025685cf8 ffffffff813046df 0000000000000001=
 0000000000000001<br>
&gt; [ =A0 48.107517] Call Trace:<br>
&gt; [ =A0 48.110029] =A0[&lt;ffffffff81491cc1&gt;] cpuidle_register_device=
+0x31/0x80<br>
&gt; [ =A0 48.116348] =A0[&lt;ffffffff813046df&gt;] intel_idle_cpu_init+0xb=
f/0x120<br>
&gt; [ =A0 48.122423] =A0[&lt;ffffffff813047b0&gt;] cpu_hotplug_notify+0x70=
/0x80<br>
&gt; [ =A0 48.128310] =A0[&lt;ffffffff815a619d&gt;] notifier_call_chain+0x4=
d/0x70<br>
&gt; [ =A0 48.134281] =A0[&lt;ffffffff8107969e&gt;] __raw_notifier_call_cha=
in+0xe/0x10<br>
&gt; [ =A0 48.140686] =A0[&lt;ffffffff81053bb0&gt;] __cpu_notify+0x20/0x40<=
br>
&gt; [ =A0 48.146050] =A0[&lt;ffffffff81594c7c&gt;] _cpu_up+0xf1/0x138<br>
&gt; [ =A0 48.151070] =A0[&lt;ffffffff8158ab39&gt;] enable_nonboot_cpus+0x9=
9/0xd0<br>
&gt; [ =A0 48.157090] =A0[&lt;ffffffff81097b8d&gt;] suspend_devices_and_ent=
er+0x25d/0x330<br>
&gt; [ =A0 48.163752] =A0[&lt;ffffffff81097def&gt;] pm_suspend+0x18f/0x1f0<=
br>
&gt; [ =A0 48.169117] =A0[&lt;ffffffff81096dea&gt;] state_store+0x8a/0x100<=
br>
&gt; [ =A0 48.174483] =A0[&lt;ffffffff812ac29f&gt;] kobj_attr_store+0xf/0x3=
0<br>
&gt; [ =A0 48.180022] =A0[&lt;ffffffff811c005f&gt;] sysfs_write_file+0xef/0=
x170<br>
&gt; [ =A0 48.185943] =A0[&lt;ffffffff8115c253&gt;] vfs_write+0xb3/0x180<br=
>
&gt; [ =A0 48.191056] =A0[&lt;ffffffff8115c592&gt;] sys_write+0x52/0xa0<br>
&gt; [ =A0 48.196160] =A0[&lt;ffffffff815a614e&gt;] ? do_page_fault+0xe/0x1=
0<br>
&gt; [ =A0 48.201700] =A0[&lt;ffffffff815aa7d9&gt;] system_call_fastpath+0x=
16/0x1b<br>
&gt; [ =A0 48.207758] Code: 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d=
 e0 4c 89 6d f0 48 89 fb 4c 89 75 f8 4c 89 65 e8 41 be ea ff ff ff e8 75 0a=
 00 00&lt;48&gt; =A08b 78 08 49 89 c5 e8 19 80 c1 ff 84 c0 74 53 8b 43 04 4=
9 c7<br>

&gt; [ =A0 48.226658] RIP =A0[&lt;ffffffff8149196b&gt;] __cpuidle_register_=
device+0x2b/0x100<br>
<br>
</div></div>Hm, that is suspect. There should not be any cpuidle_register? =
Perhaps<br>
you are .. ah yes, you are hitting a bug that should be in the stable<br>
tree fix.<br>
<br>
Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and<br>
6f8c2e7933679f54b6478945dc72e59ef9a3d5e0<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; [ =A0 48.233582] =A0RSP&lt;ffff880025685c98&gt;<br>
&gt; [ =A0 48.237131] CR2: 0000000000000008<br>
&gt;<br>
&gt; [ =A0 48.240521] ---[ end trace 535ebe28cd06b143 ]---<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--20cf3074afa8a3d1c604d531c58b--


--===============8694149927345817112==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8694149927345817112==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 13:54:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 13: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 1U3oOu-00039j-40; Fri, 08 Feb 2013 13:54:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3oOs-00039e-Nc
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 13:53:59 +0000
Received: from [85.158.139.211:29056] by server-12.bemta-5.messagelabs.com id
	70/E8-20195-67305115; Fri, 08 Feb 2013 13:53:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360331623!20006392!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31539 invoked from network); 8 Feb 2013 13:53:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 13:53:43 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:54136 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 1U3oUy-0000fn-Il; Fri, 08 Feb 2013 15:00:16 +0100
Date: Fri, 8 Feb 2013 14:53:40 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <675353343.20130208145340@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5114DA3A02000078000BD1FB@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<5114DA3A02000078000BD1FB@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, xiantao.zhang@intel.com,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, February 8, 2013, 10:58:02 AM, you wrote:

>>>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
>> A regression was reported on a class of broken firmware that c/s
>> 26517:601139e2b0db didn't consider, leading to a boot time crash.

> After some more thought on this and the comments we got
> regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we
> can actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than
> prior to the XSA-36 fixes (where interrupt remapping didn't really
> protect domains from one another), but allows at least DMA
> isolation to still be utilized. Patch 3/2 below/attached.

> Jan

That seems the same linux does.
Unfortunately it seems i'am having to use it, just tested the latest bios for my motherboard and that still has no IVHD for the IOAPIC, but also locks up immediately after that message.


> AMD IOMMU: only disable interrupt remapping when certain IVRS consistency checks fail

> After some more thought on the XSA-36 and specifically the comments we
> got regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we can
> actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than prior
> to the XSA-36 fixes (where interrupt remapping didn't really protect
> domains from one another), but allows at least DMA isolation to still
> be utilized.

> In the course of this, the calls to the interrupt remapping related
> IOMMU implementation specific operations needed to be re-qualified
> from depending on iommu_enabled to iommu_intremap (as was already the
> case for x86's HPET code).

> That in turn required to make sure iommu_intremap gets properly
> cleared when the respective initialization fails (or isn't being
> done at all).

> Along with making sure interrupt remapping doesn't get inconsistently
> enabled on some IOMMUs and not on others in the VT-d code, this in turn
> allowed quite a bit of cleanup on the VT-d side (if desired, that
> cleanup could of course be broken out into a separate patch).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc
>          BUG();
>      }
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_read_msi_from_ire(entry, msg);
>  }
>  
> @@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des
>  {
>      entry->msg = *msg;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>      {
>          ASSERT(msg != &entry->msg);
>          iommu_update_ire_from_msi(entry, msg);
> @@ -489,7 +489,7 @@ int msi_free_irq(struct msi_desc *entry)
>      }
>  
>      /* Free the unused IRTE if intr remap enabled */
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_update_ire_from_msi(entry, NULL);
>  
>      list_del(&entry->list);
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -682,10 +682,10 @@ static u16 __init parse_ivhd_device_spec
>                      printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n",
>                             special->handle);
>                      if ( amd_iommu_perdev_intremap )
> -                        return 0;
> +                        iommu_intremap = 0;
>                  }
>              }
> -            else
> +            else if ( iommu_intremap )
>              {
>                  /* set device id of ioapic */
>                  ioapic_sbdf[special->handle].bdf = bdf;
> @@ -697,7 +697,7 @@ static u16 __init parse_ivhd_device_spec
>                       !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>                  {
>                      printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> -                    return 0;
> +                    iommu_intremap = 0;
>                  }
>              }
>              break;
> @@ -706,7 +706,7 @@ static u16 __init parse_ivhd_device_spec
>          {
>              printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
>                     special->handle);
> -            return 0;
> +            iommu_intremap = 0;
>          }
>          break;
>      case ACPI_IVHD_HPET:
> @@ -932,7 +932,7 @@ static int __init parse_ivrs_table(struc
>          printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>                 IO_APIC_ID(apic));
>          if ( amd_iommu_perdev_intremap )
> -            error = -ENXIO;
> +            iommu_intremap = 0;
>          else
>          {
>              ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> @@ -940,7 +940,7 @@ static int __init parse_ivrs_table(struc
>              if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>              {
>                  printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> -                error = -ENOMEM;
> +                iommu_intremap = 0;
>              }
>          }
>      }
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)
>      BUG_ON( !iommu_found() );
>  
>      if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
> -        goto error_out;
> +        iommu_intremap = 0;
>  
>      ivrs_bdf_entries = amd_iommu_get_ivrs_dev_entries();
>  
> @@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)
>          goto error_out;
>  
>      /* initialize io-apic interrupt remapping entries */
> -    if ( amd_iommu_setup_ioapic_remapping() != 0 )
> +    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() != 0 )
>          goto error_out;
>  
>      /* allocate and initialize a global device table shared by all iommus */
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -470,6 +470,8 @@ int __init iommu_setup(void)
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
>      }
> +    if ( !iommu_enabled )
> +        iommu_intremap = 0;
>  
>      if ( (force_iommu && !iommu_enabled) ||
>           (force_intremap && !iommu_intremap) )
> @@ -487,6 +489,7 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" : "dis");
>  
>      return rc;
>  }
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -373,7 +373,7 @@ unsigned int io_apic_read_remap_rte(
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
+    if ( !ir_ctrl->>iremap_num ||
>          ( (index = apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
>          return __io_apic_read(apic, reg);
>  
> @@ -396,15 +396,8 @@ void io_apic_write_remap_rte(
>      struct IO_APIC_route_remap_entry *remap_rte;
>      unsigned int rte_upper = (reg & 1) ? 1 : 0;
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
> -    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>      int saved_mask;
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -    {
> -        __io_apic_write(apic, reg, value);
> -        return;
> -    }
> -
>      old_rte = __ioapic_read_entry(apic, ioapic_pin, 1);
>  
>      remap_rte = (struct IO_APIC_route_remap_entry *) &old_rte;
> @@ -653,20 +646,11 @@ void msi_msg_read_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
-    iommu = drhd->>iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    remap_entry_to_msi_msg(iommu, msg);
> +    if ( drhd )
> +        remap_entry_to_msi_msg(drhd->iommu, msg);
>  }
>  
>  void msi_msg_write_remap_rte(
> @@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
-    iommu = drhd->>iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
> +    if ( drhd )
> +        msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg);
>  }
>  
>  int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2065,6 +2065,9 @@ static int init_vtd_hw(void)
>                  break;
>              }
>          }
> +        if ( !iommu_intremap )
> +            for_each_drhd_unit ( drhd )
> +                disable_intremap(drhd->iommu);
>      }
>  
>      /*
> --- a/xen/include/asm-x86/io_apic.h
> +++ b/xen/include/asm-x86/io_apic.h
> @@ -129,7 +129,7 @@ struct IO_APIC_route_entry {
>  extern struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
>  
>  /* Only need to remap ioapic RTE (reg: 10~3Fh) */
> -#define ioapic_reg_remapped(reg) (iommu_enabled && ((reg) >= 0x10))
> +#define ioapic_reg_remapped(reg) (iommu_intremap && ((reg) >= 0x10))
>  
>  static inline unsigned int __io_apic_read(unsigned int apic, unsigned int reg)
>  {




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 13:54:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 13: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 1U3oOu-00039j-40; Fri, 08 Feb 2013 13:54:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3oOs-00039e-Nc
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 13:53:59 +0000
Received: from [85.158.139.211:29056] by server-12.bemta-5.messagelabs.com id
	70/E8-20195-67305115; Fri, 08 Feb 2013 13:53:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360331623!20006392!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31539 invoked from network); 8 Feb 2013 13:53:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 13:53:43 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:54136 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 1U3oUy-0000fn-Il; Fri, 08 Feb 2013 15:00:16 +0100
Date: Fri, 8 Feb 2013 14:53:40 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <675353343.20130208145340@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5114DA3A02000078000BD1FB@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<5114DA3A02000078000BD1FB@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>, xiantao.zhang@intel.com,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, February 8, 2013, 10:58:02 AM, you wrote:

>>>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
>> A regression was reported on a class of broken firmware that c/s
>> 26517:601139e2b0db didn't consider, leading to a boot time crash.

> After some more thought on this and the comments we got
> regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we
> can actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than
> prior to the XSA-36 fixes (where interrupt remapping didn't really
> protect domains from one another), but allows at least DMA
> isolation to still be utilized. Patch 3/2 below/attached.

> Jan

That seems the same linux does.
Unfortunately it seems i'am having to use it, just tested the latest bios for my motherboard and that still has no IVHD for the IOAPIC, but also locks up immediately after that message.


> AMD IOMMU: only disable interrupt remapping when certain IVRS consistency checks fail

> After some more thought on the XSA-36 and specifically the comments we
> got regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we can
> actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than prior
> to the XSA-36 fixes (where interrupt remapping didn't really protect
> domains from one another), but allows at least DMA isolation to still
> be utilized.

> In the course of this, the calls to the interrupt remapping related
> IOMMU implementation specific operations needed to be re-qualified
> from depending on iommu_enabled to iommu_intremap (as was already the
> case for x86's HPET code).

> That in turn required to make sure iommu_intremap gets properly
> cleared when the respective initialization fails (or isn't being
> done at all).

> Along with making sure interrupt remapping doesn't get inconsistently
> enabled on some IOMMUs and not on others in the VT-d code, this in turn
> allowed quite a bit of cleanup on the VT-d side (if desired, that
> cleanup could of course be broken out into a separate patch).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc
>          BUG();
>      }
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_read_msi_from_ire(entry, msg);
>  }
>  
> @@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des
>  {
>      entry->msg = *msg;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>      {
>          ASSERT(msg != &entry->msg);
>          iommu_update_ire_from_msi(entry, msg);
> @@ -489,7 +489,7 @@ int msi_free_irq(struct msi_desc *entry)
>      }
>  
>      /* Free the unused IRTE if intr remap enabled */
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_update_ire_from_msi(entry, NULL);
>  
>      list_del(&entry->list);
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -682,10 +682,10 @@ static u16 __init parse_ivhd_device_spec
>                      printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n",
>                             special->handle);
>                      if ( amd_iommu_perdev_intremap )
> -                        return 0;
> +                        iommu_intremap = 0;
>                  }
>              }
> -            else
> +            else if ( iommu_intremap )
>              {
>                  /* set device id of ioapic */
>                  ioapic_sbdf[special->handle].bdf = bdf;
> @@ -697,7 +697,7 @@ static u16 __init parse_ivhd_device_spec
>                       !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>                  {
>                      printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> -                    return 0;
> +                    iommu_intremap = 0;
>                  }
>              }
>              break;
> @@ -706,7 +706,7 @@ static u16 __init parse_ivhd_device_spec
>          {
>              printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
>                     special->handle);
> -            return 0;
> +            iommu_intremap = 0;
>          }
>          break;
>      case ACPI_IVHD_HPET:
> @@ -932,7 +932,7 @@ static int __init parse_ivrs_table(struc
>          printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>                 IO_APIC_ID(apic));
>          if ( amd_iommu_perdev_intremap )
> -            error = -ENXIO;
> +            iommu_intremap = 0;
>          else
>          {
>              ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> @@ -940,7 +940,7 @@ static int __init parse_ivrs_table(struc
>              if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>              {
>                  printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> -                error = -ENOMEM;
> +                iommu_intremap = 0;
>              }
>          }
>      }
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)
>      BUG_ON( !iommu_found() );
>  
>      if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
> -        goto error_out;
> +        iommu_intremap = 0;
>  
>      ivrs_bdf_entries = amd_iommu_get_ivrs_dev_entries();
>  
> @@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)
>          goto error_out;
>  
>      /* initialize io-apic interrupt remapping entries */
> -    if ( amd_iommu_setup_ioapic_remapping() != 0 )
> +    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() != 0 )
>          goto error_out;
>  
>      /* allocate and initialize a global device table shared by all iommus */
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -470,6 +470,8 @@ int __init iommu_setup(void)
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
>      }
> +    if ( !iommu_enabled )
> +        iommu_intremap = 0;
>  
>      if ( (force_iommu && !iommu_enabled) ||
>           (force_intremap && !iommu_intremap) )
> @@ -487,6 +489,7 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" : "dis");
>  
>      return rc;
>  }
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -373,7 +373,7 @@ unsigned int io_apic_read_remap_rte(
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
+    if ( !ir_ctrl->>iremap_num ||
>          ( (index = apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
>          return __io_apic_read(apic, reg);
>  
> @@ -396,15 +396,8 @@ void io_apic_write_remap_rte(
>      struct IO_APIC_route_remap_entry *remap_rte;
>      unsigned int rte_upper = (reg & 1) ? 1 : 0;
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
> -    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>      int saved_mask;
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -    {
> -        __io_apic_write(apic, reg, value);
> -        return;
> -    }
> -
>      old_rte = __ioapic_read_entry(apic, ioapic_pin, 1);
>  
>      remap_rte = (struct IO_APIC_route_remap_entry *) &old_rte;
> @@ -653,20 +646,11 @@ void msi_msg_read_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
-    iommu = drhd->>iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    remap_entry_to_msi_msg(iommu, msg);
> +    if ( drhd )
> +        remap_entry_to_msi_msg(drhd->iommu, msg);
>  }
>  
>  void msi_msg_write_remap_rte(
> @@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
-    iommu = drhd->>iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
> +    if ( drhd )
> +        msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg);
>  }
>  
>  int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2065,6 +2065,9 @@ static int init_vtd_hw(void)
>                  break;
>              }
>          }
> +        if ( !iommu_intremap )
> +            for_each_drhd_unit ( drhd )
> +                disable_intremap(drhd->iommu);
>      }
>  
>      /*
> --- a/xen/include/asm-x86/io_apic.h
> +++ b/xen/include/asm-x86/io_apic.h
> @@ -129,7 +129,7 @@ struct IO_APIC_route_entry {
>  extern struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
>  
>  /* Only need to remap ioapic RTE (reg: 10~3Fh) */
> -#define ioapic_reg_remapped(reg) (iommu_enabled && ((reg) >= 0x10))
> +#define ioapic_reg_remapped(reg) (iommu_intremap && ((reg) >= 0x10))
>  
>  static inline unsigned int __io_apic_read(unsigned int apic, unsigned int reg)
>  {




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 14:08:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3ocf-0003b5-HH; Fri, 08 Feb 2013 14:08:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U3occ-0003b0-Ti
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:08:11 +0000
Received: from [85.158.139.211:7076] by server-1.bemta-5.messagelabs.com id
	D5/39-29263-9C605115; Fri, 08 Feb 2013 14:08:09 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360332488!21671971!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 785 invoked from network); 8 Feb 2013 14:08:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 14:08:09 -0000
Received: by mail-wi0-f171.google.com with SMTP id hn17so890111wib.10
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 06:08:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=mD9gUUwkkOsjv7WUJ/mKkXKN/uSatehb2t6N2nZFHzw=;
	b=IuPGK+YN92IcSYke39jNHmyCcWpm2cW8z63jfkL2KB0a3V7CG1UdkEbJ7X/ZFp87/V
	tffhPLH8neHd9zD8h8ER1OTpI2OMG3b3xEJV2dL3xSSokRyrdvZwW5i8DJmtHKfm+dYZ
	LzBixVR2dGhLNRRUQEG2PuBinbj0wXoRaqe4Skg4D+4VppC8BeiWB1wWdXNcCJJTGXS1
	VeVR0limqh+rTTjVB8iqyh9IhZ4isaZweTXGWfgfrDttCW7KoBC9A9YK3MAR73ZBo0VD
	R2JV+VoV9pSx5505p0Bj9jyUZgfrw6jmrQhfdjMgvVxe75YpjPHGrV9BxPLh0ND2Ow/Z
	gcBg==
MIME-Version: 1.0
X-Received: by 10.194.108.229 with SMTP id hn5mr10133864wjb.8.1360332488521;
	Fri, 08 Feb 2013 06:08:08 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Fri, 8 Feb 2013 06:08:08 -0800 (PST)
In-Reply-To: <511413E8.3090407@centos.org>
References: <20130206132802.GU8912@reaktio.net>
	<CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
	<511413E8.3090407@centos.org>
Date: Fri, 8 Feb 2013 15:08:08 +0100
Message-ID: <CAN-nQwjgTee88x+m0yOdLrehox8=H17CfP_bANpSmPwNh83wUw@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: Fabian Arrotin <arrfab@centos.org>
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============2233391311851892454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2233391311851892454==
Content-Type: multipart/alternative; boundary=047d7bf19890c1396004d53716ee

--047d7bf19890c1396004d53716ee
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

Today Xen finally running on IBM blade server machine, try to add nmi=dom0
and find the Base Board Management Controller on bios configuration and
disabled the 'reboot system on nmi' attribute. This step won't eliminate
the nmi problem since I still found NMI error interrupt on my blade server
log but xen would ignored and keep running. If any other found better
solution would be great.

Agya

On Thu, Feb 7, 2013 at 9:51 PM, Fabian Arrotin <arrfab@centos.org> wrote:

> On 02/06/2013 02:39 PM, agya naila wrote:
> > I configure it by added nmi=ignore to my /boot/grub/grub.cfg
> >
>
> Just to add that I also tried the nmi=ignore parameter for Xen, and it
> stills hard reboot/resets automatically during the kernel dom0 boot
>
> Fabian
>

--047d7bf19890c1396004d53716ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello all,<div><br></div><div>Today Xen finally running on IBM blade server=
 machine, try to add nmi=3Ddom0 and find the Base Board Management Controll=
er on bios configuration and disabled the &#39;reboot system on nmi&#39; at=
tribute. This step won&#39;t eliminate the nmi problem since I still found =
NMI error interrupt on my blade server log but xen would ignored and keep r=
unning. If any other found better solution would be great.</div>
<div><br></div><div>Agya<br><br><div class=3D"gmail_quote">On Thu, Feb 7, 2=
013 at 9:51 PM, Fabian Arrotin <span dir=3D"ltr">&lt;<a href=3D"mailto:arrf=
ab@centos.org" target=3D"_blank">arrfab@centos.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D"im">On 02/06/2013 02:39 PM, agya naila wrote:<br>
&gt; I configure it by added nmi=3Dignore to my /boot/grub/grub.cfg<br>
&gt;<br>
<br>
</div>Just to add that I also tried the nmi=3Dignore parameter for Xen, and=
 it<br>
stills hard reboot/resets automatically during the kernel dom0 boot<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Fabian<br>
</font></span></blockquote></div><br></div>

--047d7bf19890c1396004d53716ee--


--===============2233391311851892454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2233391311851892454==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 14:08:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3ocf-0003b5-HH; Fri, 08 Feb 2013 14:08:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U3occ-0003b0-Ti
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:08:11 +0000
Received: from [85.158.139.211:7076] by server-1.bemta-5.messagelabs.com id
	D5/39-29263-9C605115; Fri, 08 Feb 2013 14:08:09 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360332488!21671971!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 785 invoked from network); 8 Feb 2013 14:08:09 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 14:08:09 -0000
Received: by mail-wi0-f171.google.com with SMTP id hn17so890111wib.10
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 06:08:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=mD9gUUwkkOsjv7WUJ/mKkXKN/uSatehb2t6N2nZFHzw=;
	b=IuPGK+YN92IcSYke39jNHmyCcWpm2cW8z63jfkL2KB0a3V7CG1UdkEbJ7X/ZFp87/V
	tffhPLH8neHd9zD8h8ER1OTpI2OMG3b3xEJV2dL3xSSokRyrdvZwW5i8DJmtHKfm+dYZ
	LzBixVR2dGhLNRRUQEG2PuBinbj0wXoRaqe4Skg4D+4VppC8BeiWB1wWdXNcCJJTGXS1
	VeVR0limqh+rTTjVB8iqyh9IhZ4isaZweTXGWfgfrDttCW7KoBC9A9YK3MAR73ZBo0VD
	R2JV+VoV9pSx5505p0Bj9jyUZgfrw6jmrQhfdjMgvVxe75YpjPHGrV9BxPLh0ND2Ow/Z
	gcBg==
MIME-Version: 1.0
X-Received: by 10.194.108.229 with SMTP id hn5mr10133864wjb.8.1360332488521;
	Fri, 08 Feb 2013 06:08:08 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Fri, 8 Feb 2013 06:08:08 -0800 (PST)
In-Reply-To: <511413E8.3090407@centos.org>
References: <20130206132802.GU8912@reaktio.net>
	<CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
	<511413E8.3090407@centos.org>
Date: Fri, 8 Feb 2013 15:08:08 +0100
Message-ID: <CAN-nQwjgTee88x+m0yOdLrehox8=H17CfP_bANpSmPwNh83wUw@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: Fabian Arrotin <arrfab@centos.org>
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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: multipart/mixed; boundary="===============2233391311851892454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2233391311851892454==
Content-Type: multipart/alternative; boundary=047d7bf19890c1396004d53716ee

--047d7bf19890c1396004d53716ee
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

Today Xen finally running on IBM blade server machine, try to add nmi=dom0
and find the Base Board Management Controller on bios configuration and
disabled the 'reboot system on nmi' attribute. This step won't eliminate
the nmi problem since I still found NMI error interrupt on my blade server
log but xen would ignored and keep running. If any other found better
solution would be great.

Agya

On Thu, Feb 7, 2013 at 9:51 PM, Fabian Arrotin <arrfab@centos.org> wrote:

> On 02/06/2013 02:39 PM, agya naila wrote:
> > I configure it by added nmi=ignore to my /boot/grub/grub.cfg
> >
>
> Just to add that I also tried the nmi=ignore parameter for Xen, and it
> stills hard reboot/resets automatically during the kernel dom0 boot
>
> Fabian
>

--047d7bf19890c1396004d53716ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello all,<div><br></div><div>Today Xen finally running on IBM blade server=
 machine, try to add nmi=3Ddom0 and find the Base Board Management Controll=
er on bios configuration and disabled the &#39;reboot system on nmi&#39; at=
tribute. This step won&#39;t eliminate the nmi problem since I still found =
NMI error interrupt on my blade server log but xen would ignored and keep r=
unning. If any other found better solution would be great.</div>
<div><br></div><div>Agya<br><br><div class=3D"gmail_quote">On Thu, Feb 7, 2=
013 at 9:51 PM, Fabian Arrotin <span dir=3D"ltr">&lt;<a href=3D"mailto:arrf=
ab@centos.org" target=3D"_blank">arrfab@centos.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D"im">On 02/06/2013 02:39 PM, agya naila wrote:<br>
&gt; I configure it by added nmi=3Dignore to my /boot/grub/grub.cfg<br>
&gt;<br>
<br>
</div>Just to add that I also tried the nmi=3Dignore parameter for Xen, and=
 it<br>
stills hard reboot/resets automatically during the kernel dom0 boot<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Fabian<br>
</font></span></blockquote></div><br></div>

--047d7bf19890c1396004d53716ee--


--===============2233391311851892454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2233391311851892454==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 14:14:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3oiO-000452-D3; Fri, 08 Feb 2013 14:14:08 +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 1U3oiM-00044u-R3
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:14:07 +0000
Received: from [85.158.139.211:7615] by server-12.bemta-5.messagelabs.com id
	56/36-20195-E2805115; Fri, 08 Feb 2013 14:14:06 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360332835!17727222!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzY0OTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22681 invoked from network); 8 Feb 2013 14:13:56 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 14:13:56 -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 F12C11694;
	Fri,  8 Feb 2013 16:13:54 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B747DF4017; Fri,  8 Feb 2013 16:13:54 +0200 (EET)
Date: Fri, 8 Feb 2013 16:13:54 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130208141354.GY8912@reaktio.net>
References: <20130206132802.GU8912@reaktio.net>
	<CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
	<511413E8.3090407@centos.org>
	<CAN-nQwjgTee88x+m0yOdLrehox8=H17CfP_bANpSmPwNh83wUw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN-nQwjgTee88x+m0yOdLrehox8=H17CfP_bANpSmPwNh83wUw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Fabian Arrotin <arrfab@centos.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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 Fri, Feb 08, 2013 at 03:08:08PM +0100, agya naila wrote:
>    Hello all,
>    Today Xen finally running on IBM blade server machine, try to add nmi=dom0
>    and find the Base Board Management Controller on bios configuration and
>    disabled the 'reboot system on nmi' attribute. This step won't eliminate
>    the nmi problem since I still found NMI error interrupt on my blade server
>    log but xen would ignored and keep running. If any other found better
>    solution would be great.
>

Thanks for the 'workaround' info.

We still should find out what exactly generates/causes that NMI with Xen..

-- Pasi

>    Agya
> 
>    On Thu, Feb 7, 2013 at 9:51 PM, Fabian Arrotin <[1]arrfab@centos.org>
>    wrote:
> 
>      On 02/06/2013 02:39 PM, agya naila wrote:
>      > I configure it by added nmi=ignore to my /boot/grub/grub.cfg
>      >
> 
>      Just to add that I also tried the nmi=ignore parameter for Xen, and it
>      stills hard reboot/resets automatically during the kernel dom0 boot
>      Fabian
> 
> References
> 
>    Visible links
>    1. mailto:arrfab@centos.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 14:14:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3oiO-000452-D3; Fri, 08 Feb 2013 14:14:08 +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 1U3oiM-00044u-R3
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:14:07 +0000
Received: from [85.158.139.211:7615] by server-12.bemta-5.messagelabs.com id
	56/36-20195-E2805115; Fri, 08 Feb 2013 14:14:06 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360332835!17727222!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzY0OTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22681 invoked from network); 8 Feb 2013 14:13:56 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 14:13:56 -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 F12C11694;
	Fri,  8 Feb 2013 16:13:54 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B747DF4017; Fri,  8 Feb 2013 16:13:54 +0200 (EET)
Date: Fri, 8 Feb 2013 16:13:54 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: agya naila <agya.naila@gmail.com>
Message-ID: <20130208141354.GY8912@reaktio.net>
References: <20130206132802.GU8912@reaktio.net>
	<CAN-nQwhs9Vt+ttDeALYZEgFSQ_UH=08y0zfQ9aRBU4RydF+zTQ@mail.gmail.com>
	<511413E8.3090407@centos.org>
	<CAN-nQwjgTee88x+m0yOdLrehox8=H17CfP_bANpSmPwNh83wUw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN-nQwjgTee88x+m0yOdLrehox8=H17CfP_bANpSmPwNh83wUw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Fabian Arrotin <arrfab@centos.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] IBM HS20 Xen 4.1 and 4.2 Critical Interrupt - Front
 panel NMI 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 Fri, Feb 08, 2013 at 03:08:08PM +0100, agya naila wrote:
>    Hello all,
>    Today Xen finally running on IBM blade server machine, try to add nmi=dom0
>    and find the Base Board Management Controller on bios configuration and
>    disabled the 'reboot system on nmi' attribute. This step won't eliminate
>    the nmi problem since I still found NMI error interrupt on my blade server
>    log but xen would ignored and keep running. If any other found better
>    solution would be great.
>

Thanks for the 'workaround' info.

We still should find out what exactly generates/causes that NMI with Xen..

-- Pasi

>    Agya
> 
>    On Thu, Feb 7, 2013 at 9:51 PM, Fabian Arrotin <[1]arrfab@centos.org>
>    wrote:
> 
>      On 02/06/2013 02:39 PM, agya naila wrote:
>      > I configure it by added nmi=ignore to my /boot/grub/grub.cfg
>      >
> 
>      Just to add that I also tried the nmi=ignore parameter for Xen, and it
>      stills hard reboot/resets automatically during the kernel dom0 boot
>      Fabian
> 
> References
> 
>    Visible links
>    1. mailto:arrfab@centos.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 14:30:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3oxh-0004Ws-VD; Fri, 08 Feb 2013 14:29:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U3oxg-0004Wn-Qe
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:29:57 +0000
Received: from [85.158.139.211:41985] by server-3.bemta-5.messagelabs.com id
	78/90-07037-3EB05115; Fri, 08 Feb 2013 14:29:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360333793!20628771!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjQzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11002 invoked from network); 8 Feb 2013 14:29:55 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 14:29:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r18ETob4014445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Feb 2013 14:29:50 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
	r18ETnEI025750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 14:29:49 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
	r18ETm1l011003; Fri, 8 Feb 2013 08:29:49 -0600
MIME-Version: 1.0
Message-ID: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
Date: Fri, 8 Feb 2013 06:29:48 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <JBeulich@suse.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: sherry.hurwitz@amd.com, xiantao.zhang@intel.com,
	suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


----- JBeulich@suse.com wrote:

> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> > A regression was reported on a class of broken firmware that c/s
> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
> 
> After some more thought on this and the comments we got
> regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we
> can actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than
> prior to the XSA-36 fixes (where interrupt remapping didn't really
> protect domains from one another), but allows at least DMA
> isolation to still be utilized. Patch 3/2 below/attached.

But now users who don't examine log messages may not realize 
that interupt remapping is disabled and therefore the system can be
affected by XSA-36.

With current code (boot option to use global remapping table) users
are explicitly agreeing to allow for possibility of cross-domain interrupt
attack.

Also, I think it may not be a bad idea to have AMD folks test you earlier
patch on multi-IOMMU system (and simulate bad IVRS) to see how it behaves there.

Suravee --- this is the patch I am referring to: http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html

-boris

> 
> Jan
> 
> AMD IOMMU: only disable interrupt remapping when certain IVRS
> consistency checks fail
> 
> After some more thought on the XSA-36 and specifically the comments
> we
> got regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we can
> actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than prior
> to the XSA-36 fixes (where interrupt remapping didn't really protect
> domains from one another), but allows at least DMA isolation to still
> be utilized.
> 
> In the course of this, the calls to the interrupt remapping related
> IOMMU implementation specific operations needed to be re-qualified
> from depending on iommu_enabled to iommu_intremap (as was already the
> case for x86's HPET code).
> 
> That in turn required to make sure iommu_intremap gets properly
> cleared when the respective initialization fails (or isn't being
> done at all).
> 
> Along with making sure interrupt remapping doesn't get inconsistently
> enabled on some IOMMUs and not on others in the VT-d code, this in
> turn
> allowed quite a bit of cleanup on the VT-d side (if desired, that
> cleanup could of course be broken out into a separate patch).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc
>          BUG();
>      }
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_read_msi_from_ire(entry, msg);
>  }
>  
> @@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des
>  {
>      entry->msg = *msg;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>      {
>          ASSERT(msg != &entry->msg);
>          iommu_update_ire_from_msi(entry, msg);
> @@ -489,7 +489,7 @@ int msi_free_irq(struct msi_desc *entry)
>      }
>  
>      /* Free the unused IRTE if intr remap enabled */
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_update_ire_from_msi(entry, NULL);
>  
>      list_del(&entry->list);
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -682,10 +682,10 @@ static u16 __init parse_ivhd_device_spec
>                      printk(XENLOG_ERR "IVHD Error: Conflicting
> IO-APIC %#x entries\n",
>                             special->handle);
>                      if ( amd_iommu_perdev_intremap )
> -                        return 0;
> +                        iommu_intremap = 0;
>                  }
>              }
> -            else
> +            else if ( iommu_intremap )
>              {
>                  /* set device id of ioapic */
>                  ioapic_sbdf[special->handle].bdf = bdf;
> @@ -697,7 +697,7 @@ static u16 __init parse_ivhd_device_spec
>                       !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>                  {
>                      printk(XENLOG_ERR "IVHD Error: Out of
> memory\n");
> -                    return 0;
> +                    iommu_intremap = 0;
>                  }
>              }
>              break;
> @@ -706,7 +706,7 @@ static u16 __init parse_ivhd_device_spec
>          {
>              printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
>                     special->handle);
> -            return 0;
> +            iommu_intremap = 0;
>          }
>          break;
>      case ACPI_IVHD_HPET:
> @@ -932,7 +932,7 @@ static int __init parse_ivrs_table(struc
>          printk(XENLOG_ERR "IVHD Error: no information for IO-APIC
> %#x\n",
>                 IO_APIC_ID(apic));
>          if ( amd_iommu_perdev_intremap )
> -            error = -ENXIO;
> +            iommu_intremap = 0;
>          else
>          {
>              ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> @@ -940,7 +940,7 @@ static int __init parse_ivrs_table(struc
>              if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>              {
>                  printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> -                error = -ENOMEM;
> +                iommu_intremap = 0;
>              }
>          }
>      }
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)
>      BUG_ON( !iommu_found() );
>  
>      if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
> -        goto error_out;
> +        iommu_intremap = 0;
>  
>      ivrs_bdf_entries = amd_iommu_get_ivrs_dev_entries();
>  
> @@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)
>          goto error_out;
>  
>      /* initialize io-apic interrupt remapping entries */
> -    if ( amd_iommu_setup_ioapic_remapping() != 0 )
> +    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() != 0 )
>          goto error_out;
>  
>      /* allocate and initialize a global device table shared by all
> iommus */
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -470,6 +470,8 @@ int __init iommu_setup(void)
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
>      }
> +    if ( !iommu_enabled )
> +        iommu_intremap = 0;
>  
>      if ( (force_iommu && !iommu_enabled) ||
>           (force_intremap && !iommu_intremap) )
> @@ -487,6 +489,7 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" :
> "dis");
>  
>      return rc;
>  }
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -373,7 +373,7 @@ unsigned int io_apic_read_remap_rte(
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num
> ||
> +    if ( !ir_ctrl->iremap_num ||
>          ( (index = apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
>          return __io_apic_read(apic, reg);
>  
> @@ -396,15 +396,8 @@ void io_apic_write_remap_rte(
>      struct IO_APIC_route_remap_entry *remap_rte;
>      unsigned int rte_upper = (reg & 1) ? 1 : 0;
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
> -    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>      int saved_mask;
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -    {
> -        __io_apic_write(apic, reg, value);
> -        return;
> -    }
> -
>      old_rte = __ioapic_read_entry(apic, ioapic_pin, 1);
>  
>      remap_rte = (struct IO_APIC_route_remap_entry *) &old_rte;
> @@ -653,20 +646,11 @@ void msi_msg_read_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
> -    iommu = drhd->iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    remap_entry_to_msi_msg(iommu, msg);
> +    if ( drhd )
> +        remap_entry_to_msi_msg(drhd->iommu, msg);
>  }
>  
>  void msi_msg_write_remap_rte(
> @@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
> -    iommu = drhd->iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
> +    if ( drhd )
> +        msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg);
>  }
>  
>  int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2065,6 +2065,9 @@ static int init_vtd_hw(void)
>                  break;
>              }
>          }
> +        if ( !iommu_intremap )
> +            for_each_drhd_unit ( drhd )
> +                disable_intremap(drhd->iommu);
>      }
>  
>      /*
> --- a/xen/include/asm-x86/io_apic.h
> +++ b/xen/include/asm-x86/io_apic.h
> @@ -129,7 +129,7 @@ struct IO_APIC_route_entry {
>  extern struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
>  
>  /* Only need to remap ioapic RTE (reg: 10~3Fh) */
> -#define ioapic_reg_remapped(reg) (iommu_enabled && ((reg) >= 0x10))
> +#define ioapic_reg_remapped(reg) (iommu_intremap && ((reg) >= 0x10))
>  
>  static inline unsigned int __io_apic_read(unsigned int apic, unsigned
> int reg)
>  {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 14:30:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3oxh-0004Ws-VD; Fri, 08 Feb 2013 14:29:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U3oxg-0004Wn-Qe
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:29:57 +0000
Received: from [85.158.139.211:41985] by server-3.bemta-5.messagelabs.com id
	78/90-07037-3EB05115; Fri, 08 Feb 2013 14:29:55 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360333793!20628771!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjQzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11002 invoked from network); 8 Feb 2013 14:29:55 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 14:29:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r18ETob4014445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Feb 2013 14:29:50 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
	r18ETnEI025750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 14:29:49 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
	r18ETm1l011003; Fri, 8 Feb 2013 08:29:49 -0600
MIME-Version: 1.0
Message-ID: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
Date: Fri, 8 Feb 2013 06:29:48 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <JBeulich@suse.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: sherry.hurwitz@amd.com, xiantao.zhang@intel.com,
	suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


----- JBeulich@suse.com wrote:

> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> > A regression was reported on a class of broken firmware that c/s
> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
> 
> After some more thought on this and the comments we got
> regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we
> can actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than
> prior to the XSA-36 fixes (where interrupt remapping didn't really
> protect domains from one another), but allows at least DMA
> isolation to still be utilized. Patch 3/2 below/attached.

But now users who don't examine log messages may not realize 
that interupt remapping is disabled and therefore the system can be
affected by XSA-36.

With current code (boot option to use global remapping table) users
are explicitly agreeing to allow for possibility of cross-domain interrupt
attack.

Also, I think it may not be a bad idea to have AMD folks test you earlier
patch on multi-IOMMU system (and simulate bad IVRS) to see how it behaves there.

Suravee --- this is the patch I am referring to: http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html

-boris

> 
> Jan
> 
> AMD IOMMU: only disable interrupt remapping when certain IVRS
> consistency checks fail
> 
> After some more thought on the XSA-36 and specifically the comments
> we
> got regarding disabling the IOMMU in this situation altogether making
> things worse instead of better, I came to the conclusion that we can
> actually restrict the action in affected cases to just disabling
> interrupt remapping. That doesn't make the situation worse than prior
> to the XSA-36 fixes (where interrupt remapping didn't really protect
> domains from one another), but allows at least DMA isolation to still
> be utilized.
> 
> In the course of this, the calls to the interrupt remapping related
> IOMMU implementation specific operations needed to be re-qualified
> from depending on iommu_enabled to iommu_intremap (as was already the
> case for x86's HPET code).
> 
> That in turn required to make sure iommu_intremap gets properly
> cleared when the respective initialization fails (or isn't being
> done at all).
> 
> Along with making sure interrupt remapping doesn't get inconsistently
> enabled on some IOMMUs and not on others in the VT-d code, this in
> turn
> allowed quite a bit of cleanup on the VT-d side (if desired, that
> cleanup could of course be broken out into a separate patch).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -207,7 +207,7 @@ static void read_msi_msg(struct msi_desc
>          BUG();
>      }
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_read_msi_from_ire(entry, msg);
>  }
>  
> @@ -215,7 +215,7 @@ static void write_msi_msg(struct msi_des
>  {
>      entry->msg = *msg;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>      {
>          ASSERT(msg != &entry->msg);
>          iommu_update_ire_from_msi(entry, msg);
> @@ -489,7 +489,7 @@ int msi_free_irq(struct msi_desc *entry)
>      }
>  
>      /* Free the unused IRTE if intr remap enabled */
> -    if ( iommu_enabled )
> +    if ( iommu_intremap )
>          iommu_update_ire_from_msi(entry, NULL);
>  
>      list_del(&entry->list);
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -682,10 +682,10 @@ static u16 __init parse_ivhd_device_spec
>                      printk(XENLOG_ERR "IVHD Error: Conflicting
> IO-APIC %#x entries\n",
>                             special->handle);
>                      if ( amd_iommu_perdev_intremap )
> -                        return 0;
> +                        iommu_intremap = 0;
>                  }
>              }
> -            else
> +            else if ( iommu_intremap )
>              {
>                  /* set device id of ioapic */
>                  ioapic_sbdf[special->handle].bdf = bdf;
> @@ -697,7 +697,7 @@ static u16 __init parse_ivhd_device_spec
>                       !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>                  {
>                      printk(XENLOG_ERR "IVHD Error: Out of
> memory\n");
> -                    return 0;
> +                    iommu_intremap = 0;
>                  }
>              }
>              break;
> @@ -706,7 +706,7 @@ static u16 __init parse_ivhd_device_spec
>          {
>              printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
>                     special->handle);
> -            return 0;
> +            iommu_intremap = 0;
>          }
>          break;
>      case ACPI_IVHD_HPET:
> @@ -932,7 +932,7 @@ static int __init parse_ivrs_table(struc
>          printk(XENLOG_ERR "IVHD Error: no information for IO-APIC
> %#x\n",
>                 IO_APIC_ID(apic));
>          if ( amd_iommu_perdev_intremap )
> -            error = -ENXIO;
> +            iommu_intremap = 0;
>          else
>          {
>              ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> @@ -940,7 +940,7 @@ static int __init parse_ivrs_table(struc
>              if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>              {
>                  printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> -                error = -ENOMEM;
> +                iommu_intremap = 0;
>              }
>          }
>      }
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1157,7 +1157,7 @@ int __init amd_iommu_init(void)
>      BUG_ON( !iommu_found() );
>  
>      if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
> -        goto error_out;
> +        iommu_intremap = 0;
>  
>      ivrs_bdf_entries = amd_iommu_get_ivrs_dev_entries();
>  
> @@ -1173,7 +1173,7 @@ int __init amd_iommu_init(void)
>          goto error_out;
>  
>      /* initialize io-apic interrupt remapping entries */
> -    if ( amd_iommu_setup_ioapic_remapping() != 0 )
> +    if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() != 0 )
>          goto error_out;
>  
>      /* allocate and initialize a global device table shared by all
> iommus */
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -470,6 +470,8 @@ int __init iommu_setup(void)
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
>      }
> +    if ( !iommu_enabled )
> +        iommu_intremap = 0;
>  
>      if ( (force_iommu && !iommu_enabled) ||
>           (force_intremap && !iommu_intremap) )
> @@ -487,6 +489,7 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" :
> "dis");
>  
>      return rc;
>  }
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -373,7 +373,7 @@ unsigned int io_apic_read_remap_rte(
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num
> ||
> +    if ( !ir_ctrl->iremap_num ||
>          ( (index = apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
>          return __io_apic_read(apic, reg);
>  
> @@ -396,15 +396,8 @@ void io_apic_write_remap_rte(
>      struct IO_APIC_route_remap_entry *remap_rte;
>      unsigned int rte_upper = (reg & 1) ? 1 : 0;
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
> -    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>      int saved_mask;
>  
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -    {
> -        __io_apic_write(apic, reg, value);
> -        return;
> -    }
> -
>      old_rte = __ioapic_read_entry(apic, ioapic_pin, 1);
>  
>      remap_rte = (struct IO_APIC_route_remap_entry *) &old_rte;
> @@ -653,20 +646,11 @@ void msi_msg_read_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
> -    iommu = drhd->iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    remap_entry_to_msi_msg(iommu, msg);
> +    if ( drhd )
> +        remap_entry_to_msi_msg(drhd->iommu, msg);
>  }
>  
>  void msi_msg_write_remap_rte(
> @@ -674,20 +658,11 @@ void msi_msg_write_remap_rte(
>  {
>      struct pci_dev *pdev = msi_desc->dev;
>      struct acpi_drhd_unit *drhd = NULL;
> -    struct iommu *iommu = NULL;
> -    struct ir_ctrl *ir_ctrl;
>  
>      drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
>                  : hpet_to_drhd(msi_desc->hpet_id);
> -    if ( !drhd )
> -        return;
> -    iommu = drhd->iommu;
> -
> -    ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> -        return;
> -
> -    msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
> +    if ( drhd )
> +        msi_msg_to_remap_entry(drhd->iommu, pdev, msi_desc, msg);
>  }
>  
>  int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2065,6 +2065,9 @@ static int init_vtd_hw(void)
>                  break;
>              }
>          }
> +        if ( !iommu_intremap )
> +            for_each_drhd_unit ( drhd )
> +                disable_intremap(drhd->iommu);
>      }
>  
>      /*
> --- a/xen/include/asm-x86/io_apic.h
> +++ b/xen/include/asm-x86/io_apic.h
> @@ -129,7 +129,7 @@ struct IO_APIC_route_entry {
>  extern struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
>  
>  /* Only need to remap ioapic RTE (reg: 10~3Fh) */
> -#define ioapic_reg_remapped(reg) (iommu_enabled && ((reg) >= 0x10))
> +#define ioapic_reg_remapped(reg) (iommu_intremap && ((reg) >= 0x10))
>  
>  static inline unsigned int __io_apic_read(unsigned int apic, unsigned
> int reg)
>  {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 14:54:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3pKd-0005tI-Td; Fri, 08 Feb 2013 14:53:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U3pKc-0005tD-Ah
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:53:38 +0000
Received: from [85.158.137.99:12860] by server-4.bemta-3.messagelabs.com id
	C0/51-12802-07115115; Fri, 08 Feb 2013 14:53:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360335214!15906838!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 8 Feb 2013 14:53:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 14:53:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6806610"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 14:53:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 09:53:33 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U3pKX-0002jn-95;
	Fri, 08 Feb 2013 14:53:33 +0000
Message-ID: <5115116D.4010707@citrix.com>
Date: Fri, 8 Feb 2013 14:53:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
In-Reply-To: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] HAP: Add global enable/disable 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

Ping?

On 28/01/13 11:21, Andrew Cooper wrote:
> Also, correct a copy&paste error in the documentation.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> ---
>
> Changes since v1:
>  * bool_t __initdata
>  * tweak logic to reduce size of patch
>
> diff -r 5af4f2ab06f3 -r b741ace3835a docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -521,6 +521,14 @@ more importance will be printed.
>  The optional `<rate-limited level>` option instructs which severities
>  should be rate limited.
>  
> +### hap
> +> `= <boolean>`
> +
> +> Default: `true`
> +
> +Flag to globally enable or disable support for Hardware Assisted
> +Paging (HAP)
> +
>  ### hap\_1gb
>  > `= <boolean>`
>  
> @@ -534,7 +542,7 @@ Paging (HAP).
>  
>  > Default: `true`
>  
> -Flag to enable 1 GB host page table support for Hardware Assisted
> +Flag to enable 2 MB host page table support for Hardware Assisted
>  Paging (HAP).
>  
>  ### hpetbroadcast
> diff -r 5af4f2ab06f3 -r b741ace3835a xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -78,6 +78,10 @@ struct hvm_function_table hvm_funcs __re
>  unsigned long __attribute__ ((__section__ (".bss.page_aligned")))
>      hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
>  
> +/* Xen command-line option to enable HAP */
> +static bool_t __initdata opt_hap_enabled = 1;
> +boolean_param("hap", opt_hap_enabled);
> +
>  static int cpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -123,7 +127,14 @@ static int __init hvm_enable(void)
>      hvm_enabled = 1;
>  
>      printk("HVM: %s enabled\n", hvm_funcs.name);
> -    if ( hvm_funcs.hap_supported )
> +    if ( ! hvm_funcs.hap_supported )
> +        printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
> +    else if ( ! opt_hap_enabled )
> +    {
> +        hvm_funcs.hap_supported = 0;
> +        printk("HVM: Hardware Assisted Paging (HAP) detected but disabled\n");
> +    }
> +    else
>      {
>          printk("HVM: Hardware Assisted Paging (HAP) detected\n");
>          printk("HVM: HAP page sizes: 4kB");
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 14:54:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 14: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 1U3pKd-0005tI-Td; Fri, 08 Feb 2013 14:53:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U3pKc-0005tD-Ah
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:53:38 +0000
Received: from [85.158.137.99:12860] by server-4.bemta-3.messagelabs.com id
	C0/51-12802-07115115; Fri, 08 Feb 2013 14:53:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360335214!15906838!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28997 invoked from network); 8 Feb 2013 14:53:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 14:53:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; 
   d="scan'208";a="6806610"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 14:53:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 09:53:33 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U3pKX-0002jn-95;
	Fri, 08 Feb 2013 14:53:33 +0000
Message-ID: <5115116D.4010707@citrix.com>
Date: Fri, 8 Feb 2013 14:53:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
In-Reply-To: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] HAP: Add global enable/disable 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

Ping?

On 28/01/13 11:21, Andrew Cooper wrote:
> Also, correct a copy&paste error in the documentation.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> ---
>
> Changes since v1:
>  * bool_t __initdata
>  * tweak logic to reduce size of patch
>
> diff -r 5af4f2ab06f3 -r b741ace3835a docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -521,6 +521,14 @@ more importance will be printed.
>  The optional `<rate-limited level>` option instructs which severities
>  should be rate limited.
>  
> +### hap
> +> `= <boolean>`
> +
> +> Default: `true`
> +
> +Flag to globally enable or disable support for Hardware Assisted
> +Paging (HAP)
> +
>  ### hap\_1gb
>  > `= <boolean>`
>  
> @@ -534,7 +542,7 @@ Paging (HAP).
>  
>  > Default: `true`
>  
> -Flag to enable 1 GB host page table support for Hardware Assisted
> +Flag to enable 2 MB host page table support for Hardware Assisted
>  Paging (HAP).
>  
>  ### hpetbroadcast
> diff -r 5af4f2ab06f3 -r b741ace3835a xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -78,6 +78,10 @@ struct hvm_function_table hvm_funcs __re
>  unsigned long __attribute__ ((__section__ (".bss.page_aligned")))
>      hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
>  
> +/* Xen command-line option to enable HAP */
> +static bool_t __initdata opt_hap_enabled = 1;
> +boolean_param("hap", opt_hap_enabled);
> +
>  static int cpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -123,7 +127,14 @@ static int __init hvm_enable(void)
>      hvm_enabled = 1;
>  
>      printk("HVM: %s enabled\n", hvm_funcs.name);
> -    if ( hvm_funcs.hap_supported )
> +    if ( ! hvm_funcs.hap_supported )
> +        printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
> +    else if ( ! opt_hap_enabled )
> +    {
> +        hvm_funcs.hap_supported = 0;
> +        printk("HVM: Hardware Assisted Paging (HAP) detected but disabled\n");
> +    }
> +    else
>      {
>          printk("HVM: Hardware Assisted Paging (HAP) detected\n");
>          printk("HVM: HAP page sizes: 4kB");
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 15:14:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15:14: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 1U3peE-0006ew-2S; Fri, 08 Feb 2013 15:13: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 1U3peB-0006er-OC
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 15:13:52 +0000
Received: from [85.158.139.211:13296] by server-14.bemta-5.messagelabs.com id
	CB/A8-06967-F2615115; Fri, 08 Feb 2013 15:13:51 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360336428!18946893!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28304 invoked from network); 8 Feb 2013 15:13:50 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 15:13:50 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 258504015E0;
	Fri,  8 Feb 2013 16:13:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id jSinq6FQu6Qe; Fri,  8 Feb 2013 16:13:47 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 0F9C140053D;
	Fri,  8 Feb 2013 16:13:46 +0100 (CET)
Message-ID: <51151627.5040403@tiscali.it>
Date: Fri, 08 Feb 2013 16:13:43 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
	<1360324253.29432.13.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360324253.29432.13.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl patches
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="===============7696774783271571133=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7696774783271571133==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000706030801010206040209"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms000706030801010206040209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 08/02/2013 12:50, Ian Campbell ha scritto:
> On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
>>> I tested spice vdagent, spice audio and spice usbredirection with qem=
u
>>> upstream and xen-unstable manually, is all working.
>>> I'm start to write some patches to have all spice features on xen 4.3=
=2E
>>>
>>> About vdagent probably no problem.
>>>
>>> About spice audio on test I actually set this variable manually:
>>>
>>> export QEMU_AUDIO_DRV=3Dspice
>>>
>>> I need know how to setup this env variable but for a given hvm domU s=
tart.
>>> In other word I need to set this env variable on a per domU basis (if=

>>> spiceaudio if setted in cfg).
>> Pass it from libxl, after all QEMU is spawned by libxl
> Setting envvars to configure qemu is a pretty crappy interface though,
> given that qemu supports both command line and configuration files for
> most other stuff. Perhaps this interface should be fixed upstream to us=
e
> the standard mechanisms first?
>>> About usb redirection the qemu parameters to add are similar to this:=

>>>
>>> device_model_args=3D["-readconfig","/etc/xen/ich9-ehci-uhci.cfg","-ch=
ardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev1","-device","usb-re=
dir,chardev=3Dusbredirchardev1,id=3Dusbredirdev1,bus=3Dehci.0,debug=3D3",=
"-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev2","-device","us=
b-redir,chardev=3Dusbredirchardev2,id=3Dusbredirdev2,bus=3Dehci.0,debug=3D=
3","-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev3","-device",=
"usb-redir,chardev=3Dusbredirchardev3,id=3Dusbredirdev3,bus=3Dehci.0,debu=
g=3D3"]
>>>
>>> Probably is not good point to external generic file (on my test
>>> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do=
 this?
> What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to=

> add USB passthrough as a concept in libxl so as to expose this in a mor=
e
> "libxl" like manner, instead of just cutting through the qemu options?
> (I think George also brought this up a while back).

The content is here:
http://xenbits.xen.org/gitweb/?p=3Dqemu-upstream-unstable.git;a=3Dblob_pl=
ain;f=3Ddocs/ich9-ehci-uhci.cfg;hb=3DHEAD

Spice usbredir redirects USB devices from client (where spice-client is=20
launched) to qemu, not from dom0 to qemu.
How to expose it in a more "libxl" like manner?

>
> Ian.
>


--------------ms000706030801010206040209
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwODE1MTM0M1owIwYJKoZIhvcNAQkEMRYEFAEqlxQGfNvA0eR/j0wp/XSz
KIMUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAV0TGZvebHyafhONbcUrog+EP
CXBwRjqQgXfrocxreuIdL3Jy48oJmRgVQ+nEYe49vvOhWcHYZKZ2AVZCHLBJ4/hq17YjbSqP
EBr7Fji/a1JGe01ktMZ5d8wINgS7pEOs7rd4zDiNyTpceoWf3K+kktFmgvUSlP5BDJEpn9Nv
yQJF+RBQGUckaZNrgLqf9snSEcO/VH7ujPcQ8rpoeYxbGOdecgIST86Bzxni/9Zz8bi7U6/y
QhYJrFGxQ2Ymk3Y++3RkBRZV+TA3Hh2cVa8kaGUwT8nwecJhThyfgtUebXFHk9u+Kd9AegKk
DvUMUPPZN7GlvX/EvMqfC8HJhvNWDgAAAAAAAA==
--------------ms000706030801010206040209--


--===============7696774783271571133==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7696774783271571133==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 15:14:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15:14: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 1U3peE-0006ew-2S; Fri, 08 Feb 2013 15:13: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 1U3peB-0006er-OC
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 15:13:52 +0000
Received: from [85.158.139.211:13296] by server-14.bemta-5.messagelabs.com id
	CB/A8-06967-F2615115; Fri, 08 Feb 2013 15:13:51 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360336428!18946893!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28304 invoked from network); 8 Feb 2013 15:13:50 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 15:13:50 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 258504015E0;
	Fri,  8 Feb 2013 16:13:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id jSinq6FQu6Qe; Fri,  8 Feb 2013 16:13:47 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 0F9C140053D;
	Fri,  8 Feb 2013 16:13:46 +0100 (CET)
Message-ID: <51151627.5040403@tiscali.it>
Date: Fri, 08 Feb 2013 16:13:43 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
	<1360324253.29432.13.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360324253.29432.13.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl patches
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="===============7696774783271571133=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7696774783271571133==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000706030801010206040209"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms000706030801010206040209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 08/02/2013 12:50, Ian Campbell ha scritto:
> On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
>>> I tested spice vdagent, spice audio and spice usbredirection with qem=
u
>>> upstream and xen-unstable manually, is all working.
>>> I'm start to write some patches to have all spice features on xen 4.3=
=2E
>>>
>>> About vdagent probably no problem.
>>>
>>> About spice audio on test I actually set this variable manually:
>>>
>>> export QEMU_AUDIO_DRV=3Dspice
>>>
>>> I need know how to setup this env variable but for a given hvm domU s=
tart.
>>> In other word I need to set this env variable on a per domU basis (if=

>>> spiceaudio if setted in cfg).
>> Pass it from libxl, after all QEMU is spawned by libxl
> Setting envvars to configure qemu is a pretty crappy interface though,
> given that qemu supports both command line and configuration files for
> most other stuff. Perhaps this interface should be fixed upstream to us=
e
> the standard mechanisms first?
>>> About usb redirection the qemu parameters to add are similar to this:=

>>>
>>> device_model_args=3D["-readconfig","/etc/xen/ich9-ehci-uhci.cfg","-ch=
ardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev1","-device","usb-re=
dir,chardev=3Dusbredirchardev1,id=3Dusbredirdev1,bus=3Dehci.0,debug=3D3",=
"-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev2","-device","us=
b-redir,chardev=3Dusbredirchardev2,id=3Dusbredirdev2,bus=3Dehci.0,debug=3D=
3","-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev3","-device",=
"usb-redir,chardev=3Dusbredirchardev3,id=3Dusbredirdev3,bus=3Dehci.0,debu=
g=3D3"]
>>>
>>> Probably is not good point to external generic file (on my test
>>> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do=
 this?
> What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to=

> add USB passthrough as a concept in libxl so as to expose this in a mor=
e
> "libxl" like manner, instead of just cutting through the qemu options?
> (I think George also brought this up a while back).

The content is here:
http://xenbits.xen.org/gitweb/?p=3Dqemu-upstream-unstable.git;a=3Dblob_pl=
ain;f=3Ddocs/ich9-ehci-uhci.cfg;hb=3DHEAD

Spice usbredir redirects USB devices from client (where spice-client is=20
launched) to qemu, not from dom0 to qemu.
How to expose it in a more "libxl" like manner?

>
> Ian.
>


--------------ms000706030801010206040209
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIwODE1MTM0M1owIwYJKoZIhvcNAQkEMRYEFAEqlxQGfNvA0eR/j0wp/XSz
KIMUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAV0TGZvebHyafhONbcUrog+EP
CXBwRjqQgXfrocxreuIdL3Jy48oJmRgVQ+nEYe49vvOhWcHYZKZ2AVZCHLBJ4/hq17YjbSqP
EBr7Fji/a1JGe01ktMZ5d8wINgS7pEOs7rd4zDiNyTpceoWf3K+kktFmgvUSlP5BDJEpn9Nv
yQJF+RBQGUckaZNrgLqf9snSEcO/VH7ujPcQ8rpoeYxbGOdecgIST86Bzxni/9Zz8bi7U6/y
QhYJrFGxQ2Ymk3Y++3RkBRZV+TA3Hh2cVa8kaGUwT8nwecJhThyfgtUebXFHk9u+Kd9AegKk
DvUMUPPZN7GlvX/EvMqfC8HJhvNWDgAAAAAAAA==
--------------ms000706030801010206040209--


--===============7696774783271571133==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7696774783271571133==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 15:15:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3pfZ-0006iY-Ic; Fri, 08 Feb 2013 15:15:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U3pJe-0005pX-Dr
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:52:39 +0000
Received: from [193.109.254.147:65062] by server-15.bemta-14.messagelabs.com
	id B6/B4-24599-53115115; Fri, 08 Feb 2013 14:52:37 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360335112!9035149!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3146 invoked from network); 8 Feb 2013 14:51:53 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 14:51:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID;
	bh=uOtjm8v1NVNkKlqZT3/USz2OciTJq0R6hDrcy/mVqdM=; 
	b=Lu0zNTFg+fvLsCx/y/UTWGxKpr8egMrj4cTbSnCmlr3snKKLetFr2YgRZjlZJ3mSK4QYz9vyy3m2kNHsOJmsHR1PasNe8qBR9GyUc3Nu7tfLlpeAo5Ub+VpZQvYyo6bHd8a4q2bXZhg2H1VSAq0L+9ebAccE/zvjOn4Aa5ajoXw=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U3pIr-0001f5-CB
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:51:49 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id U2rDdh1rI63y for <xen-devel@lists.xen.org>;
	Fri,  8 Feb 2013 15:51:44 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U3pIm-0001eF-0D
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:51:44 +0100
Message-ID: <511510FA.8010109@crysys.hu>
Date: Fri, 08 Feb 2013 15:51:38 +0100
From: =?ISO-8859-1?Q?G=E1bor_P=C9K?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
X-Mailman-Approved-At: Fri, 08 Feb 2013 15:15:16 +0000
Subject: [Xen-devel] NMI SERR interrupts in 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

I have an Intel e1000e NIC which I put into passthrough for an HVM
domain under Xen 4.2. All the corresponding hardware protections are
enabled on my system (DMA + Interrupt remapping), however, once in a
while I get a SERR NMI in dom0 (NMI - PCI sys error (SERR) in xl dmesg).
I am wondering about its exact reason. I am thinking in the following way:

[+] Under Intel VT-x, interrupts are virtualized, thus all the
interrupts coming from my HVM domain should be handled by the
corresponding handler in dom0/(hypervisor?) which decides whether to
neglect that interrupt or inject back into the guest to be handled by
the corresponding vcpu. Thus, every time an interrupt is generated
inside my HVM guest, a VM exit occurs that is handled by the hypervisor
which forwards the "event" to the appropriate handler (in my case it is
the NMI handler in dom0 with ring1 privileges).

[+] At the same time, PCI SERR interrupts refer to hardware errors that
is generated by my passthrough NIC directly, so I expect that these
interrupts are physical (e.g., MSIs) so they should go directly either
to the BSP or one of the APs. However, Interrupt remapping is in place
which should check the origin of such interrupts and should remap the
interrupts by using the BDF id of the device. Thus, the real interrupt
is generated by the Interrupt Remapping hardware unit which is still a
physical one. Am I right?

So I have the feeling that actually it is the normal behaviour of Xen,
but it is a bit weird for me that a PT device, which can also be
controlled by a guest, could invoke an interrupt handler
out-of-the-guest with higher privileges.

Can anyone clarify this issue for me if I have a misunderstanding?

Thank you!
-gabor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:15:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3pfZ-0006iY-Ic; Fri, 08 Feb 2013 15:15:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U3pJe-0005pX-Dr
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 14:52:39 +0000
Received: from [193.109.254.147:65062] by server-15.bemta-14.messagelabs.com
	id B6/B4-24599-53115115; Fri, 08 Feb 2013 14:52:37 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360335112!9035149!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3146 invoked from network); 8 Feb 2013 14:51:53 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 14:51:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID;
	bh=uOtjm8v1NVNkKlqZT3/USz2OciTJq0R6hDrcy/mVqdM=; 
	b=Lu0zNTFg+fvLsCx/y/UTWGxKpr8egMrj4cTbSnCmlr3snKKLetFr2YgRZjlZJ3mSK4QYz9vyy3m2kNHsOJmsHR1PasNe8qBR9GyUc3Nu7tfLlpeAo5Ub+VpZQvYyo6bHd8a4q2bXZhg2H1VSAq0L+9ebAccE/zvjOn4Aa5ajoXw=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U3pIr-0001f5-CB
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:51:49 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id U2rDdh1rI63y for <xen-devel@lists.xen.org>;
	Fri,  8 Feb 2013 15:51:44 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U3pIm-0001eF-0D
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:51:44 +0100
Message-ID: <511510FA.8010109@crysys.hu>
Date: Fri, 08 Feb 2013 15:51:38 +0100
From: =?ISO-8859-1?Q?G=E1bor_P=C9K?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
X-Mailman-Approved-At: Fri, 08 Feb 2013 15:15:16 +0000
Subject: [Xen-devel] NMI SERR interrupts in 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

I have an Intel e1000e NIC which I put into passthrough for an HVM
domain under Xen 4.2. All the corresponding hardware protections are
enabled on my system (DMA + Interrupt remapping), however, once in a
while I get a SERR NMI in dom0 (NMI - PCI sys error (SERR) in xl dmesg).
I am wondering about its exact reason. I am thinking in the following way:

[+] Under Intel VT-x, interrupts are virtualized, thus all the
interrupts coming from my HVM domain should be handled by the
corresponding handler in dom0/(hypervisor?) which decides whether to
neglect that interrupt or inject back into the guest to be handled by
the corresponding vcpu. Thus, every time an interrupt is generated
inside my HVM guest, a VM exit occurs that is handled by the hypervisor
which forwards the "event" to the appropriate handler (in my case it is
the NMI handler in dom0 with ring1 privileges).

[+] At the same time, PCI SERR interrupts refer to hardware errors that
is generated by my passthrough NIC directly, so I expect that these
interrupts are physical (e.g., MSIs) so they should go directly either
to the BSP or one of the APs. However, Interrupt remapping is in place
which should check the origin of such interrupts and should remap the
interrupts by using the BDF id of the device. Thus, the real interrupt
is generated by the Interrupt Remapping hardware unit which is still a
physical one. Am I right?

So I have the feeling that actually it is the normal behaviour of Xen,
but it is a bit weird for me that a PT device, which can also be
controlled by a guest, could invoke an interrupt handler
out-of-the-guest with higher privileges.

Can anyone clarify this issue for me if I have a misunderstanding?

Thank you!
-gabor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:22:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3plo-00079e-EX; Fri, 08 Feb 2013 15:21: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 1U3pln-00079Z-3I
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 15:21:43 +0000
Received: from [85.158.139.211:63938] by server-14.bemta-5.messagelabs.com id
	5C/F9-06967-60815115; Fri, 08 Feb 2013 15:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360336900!21677341!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4276 invoked from network); 8 Feb 2013 15:21:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1286278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 15:21: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.297.1; Fri, 8 Feb 2013
	15:21:29 +0000
Message-ID: <1360336887.29432.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Fri, 8 Feb 2013 15:21:27 +0000
In-Reply-To: <51151627.5040403@tiscali.it>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
	<1360324253.29432.13.camel@zakaz.uk.xensource.com>
	<51151627.5040403@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl 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

On Fri, 2013-02-08 at 15:13 +0000, Fabio Fantoni wrote:
> Il 08/02/2013 12:50, Ian Campbell ha scritto:
> > On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
> >> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
> >>> I tested spice vdagent, spice audio and spice usbredirection with qemu
> >>> upstream and xen-unstable manually, is all working.
> >>> I'm start to write some patches to have all spice features on xen 4.3.
> >>>
> >>> About vdagent probably no problem.
> >>>
> >>> About spice audio on test I actually set this variable manually:
> >>>
> >>> export QEMU_AUDIO_DRV=spice
> >>>
> >>> I need know how to setup this env variable but for a given hvm domU start.
> >>> In other word I need to set this env variable on a per domU basis (if
> >>> spiceaudio if setted in cfg).
> >> Pass it from libxl, after all QEMU is spawned by libxl
> > Setting envvars to configure qemu is a pretty crappy interface though,
> > given that qemu supports both command line and configuration files for
> > most other stuff. Perhaps this interface should be fixed upstream to use
> > the standard mechanisms first?
> >>> About usb redirection the qemu parameters to add are similar to this:
> >>>
> >>> 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"]
> >>>
> >>> Probably is not good point to external generic file (on my test
> >>> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do this?
> > What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to
> > add USB passthrough as a concept in libxl so as to expose this in a more
> > "libxl" like manner, instead of just cutting through the qemu options?
> > (I think George also brought this up a while back).
> 
> The content is here:
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD
> 
> Spice usbredir redirects USB devices from client (where spice-client is 
> launched) to qemu, not from dom0 to qemu.
> How to expose it in a more "libxl" like manner?

Perhaps be defining a libxl_device_usb device type and including a list
of those in the domain config struct, like for other devices? We would
likely want to accommodate both emulated and passthrough devices.

Not sure how to handle USB topology though, if possible we should avoid
exposing this to the user and synthesise something suitable within
libxl.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:22:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3plo-00079e-EX; Fri, 08 Feb 2013 15:21: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 1U3pln-00079Z-3I
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 15:21:43 +0000
Received: from [85.158.139.211:63938] by server-14.bemta-5.messagelabs.com id
	5C/F9-06967-60815115; Fri, 08 Feb 2013 15:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360336900!21677341!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4276 invoked from network); 8 Feb 2013 15:21:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1286278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 15:21: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.297.1; Fri, 8 Feb 2013
	15:21:29 +0000
Message-ID: <1360336887.29432.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Fri, 8 Feb 2013 15:21:27 +0000
In-Reply-To: <51151627.5040403@tiscali.it>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
	<1360324253.29432.13.camel@zakaz.uk.xensource.com>
	<51151627.5040403@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl 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

On Fri, 2013-02-08 at 15:13 +0000, Fabio Fantoni wrote:
> Il 08/02/2013 12:50, Ian Campbell ha scritto:
> > On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
> >> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
> >>> I tested spice vdagent, spice audio and spice usbredirection with qemu
> >>> upstream and xen-unstable manually, is all working.
> >>> I'm start to write some patches to have all spice features on xen 4.3.
> >>>
> >>> About vdagent probably no problem.
> >>>
> >>> About spice audio on test I actually set this variable manually:
> >>>
> >>> export QEMU_AUDIO_DRV=spice
> >>>
> >>> I need know how to setup this env variable but for a given hvm domU start.
> >>> In other word I need to set this env variable on a per domU basis (if
> >>> spiceaudio if setted in cfg).
> >> Pass it from libxl, after all QEMU is spawned by libxl
> > Setting envvars to configure qemu is a pretty crappy interface though,
> > given that qemu supports both command line and configuration files for
> > most other stuff. Perhaps this interface should be fixed upstream to use
> > the standard mechanisms first?
> >>> About usb redirection the qemu parameters to add are similar to this:
> >>>
> >>> 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"]
> >>>
> >>> Probably is not good point to external generic file (on my test
> >>> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do this?
> > What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to
> > add USB passthrough as a concept in libxl so as to expose this in a more
> > "libxl" like manner, instead of just cutting through the qemu options?
> > (I think George also brought this up a while back).
> 
> The content is here:
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD
> 
> Spice usbredir redirects USB devices from client (where spice-client is 
> launched) to qemu, not from dom0 to qemu.
> How to expose it in a more "libxl" like manner?

Perhaps be defining a libxl_device_usb device type and including a list
of those in the domain config struct, like for other devices? We would
likely want to accommodate both emulated and passthrough devices.

Not sure how to handle USB topology though, if possible we should avoid
exposing this to the user and synthesise something suitable within
libxl.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:28:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15:28: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 1U3prm-0007Nd-9T; Fri, 08 Feb 2013 15:27:54 +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 1U3prk-0007NY-J1
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:27:52 +0000
Received: from [85.158.137.99:60724] by server-15.bemta-3.messagelabs.com id
	6E/7C-25405-77915115; Fri, 08 Feb 2013 15:27:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360337270!15212551!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19981 invoked from network); 8 Feb 2013 15:27:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1286522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 15:27: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.297.1; Fri, 8 Feb 2013
	15:27:50 +0000
Message-ID: <1360337269.29432.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 8 Feb 2013 15:27:49 +0000
In-Reply-To: <1360252182.32479.80.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
	<20130207144746.GI77133@ocelot.phlegethon.org>
	<1360252182.32479.80.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 09/45] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 15:49 +0000, Ian Campbell wrote:
> On Thu, 2013-02-07 at 14:47 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956575), Ian Campbell wrote:
> > > +#if 0 /* Currently unused in Xen */
> > > +/*
> > > + * 64-bit atomic operations.
> > > + */
> > 
> > Do we imagine that we're going to need them or can we just drop them
> > entirely?  I'd be happier to pull in an up-to-date set of atomic64 ops
> > from linux if we need them than to deliberately carry dead code.
> 
> I've generally tried to keep these files as close to Linux as I can to
> ease future syncing, but since future syncing in this case is likely to
> mean "pull in a whole new implementation from Linux" perhaps I don't
> care so much...

FYI I've nuked the #if0 covered stuff in my tree.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:28:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15:28: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 1U3prm-0007Nd-9T; Fri, 08 Feb 2013 15:27:54 +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 1U3prk-0007NY-J1
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:27:52 +0000
Received: from [85.158.137.99:60724] by server-15.bemta-3.messagelabs.com id
	6E/7C-25405-77915115; Fri, 08 Feb 2013 15:27:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360337270!15212551!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19981 invoked from network); 8 Feb 2013 15:27:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:27:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1286522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 15:27: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.297.1; Fri, 8 Feb 2013
	15:27:50 +0000
Message-ID: <1360337269.29432.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 8 Feb 2013 15:27:49 +0000
In-Reply-To: <1360252182.32479.80.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-9-git-send-email-ian.campbell@citrix.com>
	<20130207144746.GI77133@ocelot.phlegethon.org>
	<1360252182.32479.80.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 09/45] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 15:49 +0000, Ian Campbell wrote:
> On Thu, 2013-02-07 at 14:47 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956575), Ian Campbell wrote:
> > > +#if 0 /* Currently unused in Xen */
> > > +/*
> > > + * 64-bit atomic operations.
> > > + */
> > 
> > Do we imagine that we're going to need them or can we just drop them
> > entirely?  I'd be happier to pull in an up-to-date set of atomic64 ops
> > from linux if we need them than to deliberately carry dead code.
> 
> I've generally tried to keep these files as close to Linux as I can to
> ease future syncing, but since future syncing in this case is likely to
> mean "pull in a whole new implementation from Linux" perhaps I don't
> care so much...

FYI I've nuked the #if0 covered stuff in my tree.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:33:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3pxH-0007nQ-9p; Fri, 08 Feb 2013 15:33:35 +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 1U3pxF-0007nL-Er
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:33:33 +0000
Received: from [193.109.254.147:41690] by server-10.bemta-14.messagelabs.com
	id 37/57-12679-CCA15115; Fri, 08 Feb 2013 15:33:32 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360337604!9274531!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27982 invoked from network); 8 Feb 2013 15:33:24 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-8.tower-27.messagelabs.com with SMTP;
	8 Feb 2013 15:33:24 -0000
Received: from p5b2e3bbe.dip.t-dialin.net ([91.46.59.190] 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 1U3px5-0005hC-QZ; Fri, 08 Feb 2013 15:33:23 +0000
Message-ID: <51151ABF.1070007@canonical.com>
Date: Fri, 08 Feb 2013 16:33:19 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0007533134303517939=="
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)
--===============0007533134303517939==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigDC212E15171035B117EDAF53"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDC212E15171035B117EDAF53
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

A while ago I had been reporting an issue which causes Xen PVM guests
to hang (apparently related to spinlocks). Since then I was able to
gather a few more facts which I try to provide below. For the real
reasons, I am still puzzled and would be thankful for any hints or
direction.

- Happens with Xen 4.1.2 and Xen 4.2 host-side.
- PVM guest with 8 VCPUs is running 800 threads doing DB updates.
- When hanging at least 2 VCPUs in xen_spin_lock_slow with the lock free.=

  IIRC the weird lock always belongs to one VCPU runqueue.
- Testcase shows the problem for guest kernel versions v3.2..v3.5 (not
  verified farther back). Since v3.6 it cannot be reproduced. Bisect
  ends up with: 611ae8e3f5204f7480b3b405993b3352cfa16662
    "x86/tlb: enable tlb flush range support for x86"
- The other potential fix for this was to prevent xen_spin_lock_slow()
  from unmasking events (enabling interrupts) if those were enabled
  before the spinlock call.

Maybe allowing or not allowing the interrupts in xen_spin_lock_slow
just manages to tip the likelihood of getting nested deeper. The same
way that the changed TLB flush may reduce it by causing lesser IPIs.
=46rom the static information I can extract from a dump it is hard to
tell what exactly is going on. VCPU2 seems to be doing something but
looks to be rather deep in event handling. The irq_count is at 2, but
irq_count seems to be used in a few more places than just xen_hypervisor
callback. Though that at least seems to be the entry on the stack I can
see for VCPU2. The contents of the per-cpu variables for irq_reqs and
irq_stack_ptr at least seem consistent as if a callback came in while
being on the sched_op hypercall. But then the bt command seems to be
operating on a completely different stack.
VCPU2 seems to be active, not polling (event processing could be initiate=
d
from enable_irqs via force callback or before finally exiting the sched_o=
p
hypercall), there seems to be a pending upcall but upcalls are masked.
The next thing I would try is to instrument the sites incrementing and
decrementing irq_count...
---

Below some of the info seen from dom0 debugging keys and looking
at a dump with crash:

Dom0 Info:

Polling vCPUs: {1,5-7}
VCPU0: CPU0 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU1: CPU1 [has=3DF] poll=3D10 upcall_pend =3D 00, upcall_mask =3D 00
VCPU2: CPU6 [has=3DT] poll=3D0  upcall_pend =3D 01, upcall_mask =3D 01
VCPU3: CPU2 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU4: CPU4 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU5: CPU3 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU6: CPU7 [has=3DF] poll=3D40 upcall_pend =3D 01, upcall_mask =3D 01
VCPU7: CPU4 [has=3DF] poll=3D46 upcall_pend =3D 01, upcall_mask =3D 01

10 [0/1]: s=3D6 n=3D1 x=3D0
40 [0/1]: s=3D6 n=3D6 x=3D0
46 [0/1]: s=3D6 n=3D7 x=3D0

Guest Info:

lock_spinners:
[0] (struct xen_spinlock *) 0x
[1] (struct xen_spinlock *) 0xffff8803bffc8ae8 =3D { lock=3D1, spinners=3D=
2 }
[2] (struct xen_spinlock *) 0xffff8803bfc93700 =3D { lock=3D0, spinners=3D=
2 }
[3] (struct xen_spinlock *) 0x
[4] (struct xen_spinlock *) 0x
[5] (struct xen_spinlock *) 0xffff8803bffc8ae8 -> [1]
[6] (struct xen_spinlock *) 0xffff8803bfc93700 -> [2]
[7] (struct xen_spinlock *) 0xffffffff81f15ef0 =3D { lock=3D1, spinners=3D=
1 }

VCPU[2,6] -> lock of runqueue[2] =3D (struct rq *) 0xffff8803bfc93700

irq_count[1] =3D 1
irq_count[2] =3D 2
It is -1 for the rest.

*(struct pt_regs *) irq_regs[2] =3D {
	.ip =3D 0xffffffff810013aa =3D=3D hypercall_page+938 -> sched_op
	.sp =3D 0xffff8803bfc83ce8
}

char *irq_stack_ptr[2] =3D 0xffff8803bfc83fc0

#> bt -T ffff88033d65c4a0
PID: 2050   TASK: ffff88033d65c4a0  CPU: 2   COMMAND: "postgres"
  [ffff88033d72d530] get_page_from_freelist at ffffffff8111e6df
  [ffff88033d72d600] __alloc_pages_nodemask at ffffffff8111ebec
  [ffff88033d72d620] check_preempt_curr at ffffffff81050254
  [ffff88033d72d640] pull_task at ffffffff8105e33e
  [ffff88033d72d670] balance_tasks at ffffffff8105e4b6
  [ffff88033d72d680] radix_tree_lookup_slot at ffffffff8130db5e
  [ffff88033d72d690] find_get_page at ffffffff811161ee
  [ffff88033d72d6b0] find_lock_page at ffffffff81116286
  [ffff88033d72d6e0] shmem_getpage_gfp at ffffffff8112dd10
  [ffff88033d72d748] pte_pfn_to_mfn at ffffffff81005a78
  [ffff88033d72d7a0] get_page_from_freelist at ffffffff8111e6df
  [ffff88033d72d7c0] _raw_spin_lock at ffffffff81655e4e
  [ffff88033d72d7d0] ext4_ext_check_cache at ffffffff81239248
  [ffff88033d72d820] ext4_ext_map_blocks at ffffffff8123e269
  [ffff88033d72d870] _raw_spin_lock at ffffffff81655e4e
  [ffff88033d72d880] enqueue_to_backlog at ffffffff8153e55f
  [ffff88033d72d890] __wake_up_common at ffffffff8104c1c8
  [ffff88033d72d8e0] netif_rx.part.82 at ffffffff8153f2de
  [ffff88033d72d920] netif_rx at ffffffff8153f400
  [ffff88033d72d960] loopback_xmit at ffffffff8146fb1c
  [ffff88033d72d990] dev_hard_start_xmit at ffffffff8153fea6
  [ffff88033d72d9d0] do_softirq at ffffffff81016284
  [ffff88033d72d9f0] local_bh_enable at ffffffff8106d614
  [ffff88033d72da00] dev_queue_xmit at ffffffff81540309
  [ffff88033d72da50] ip_finish_output at ffffffff815769ab
  [ffff88033d72da90] ip_output at ffffffff81577518
  [ffff88033d72dac0] ip_local_out at ffffffff81576c09
  [ffff88033d72dae0] ip_send_skb at ffffffff81577f4b
  [ffff88033d72db00] udp_send_skb at ffffffff8159aaa1
  [ffff88033d72db40] ip_generic_getfrag at ffffffff81575030
  [ffff88033d72db50] udp_sendmsg at ffffffff8159bd38
  [ffff88033d72db90] irq_to_desc at ffffffff810d70b7
  [ffff88033d72dbd0] notify_remote_via_irq at ffffffff813a74c1
  [ffff88033d72dc10] ttwu_queue at ffffffff81052672
  [ffff88033d72dc38] _raw_spin_unlock_irqrestore at ffffffff8165605e
  [ffff88033d72dc90] inet_sendmsg at ffffffff815a6474
  --- bt -t would end here
  [ffff88033d72dcb0] apparmor_socket_sendmsg at ffffffff812d43f7
  [ffff88033d72dcd0] sock_sendmsg at ffffffff815266fe
  [ffff88033d72dd70] md_make_request at ffffffff814e0606
  [ffff88033d72ddd0] kmem_cache_free at ffffffff811605cf
  [ffff88033d72de10] mempool_free_slab at ffffffff81118507
  [ffff88033d72de20] mempool_free at ffffffff811185b7
  [ffff88033d72de50] sys_sendto at ffffffff8152974d
  [ffff88033d72dee0] ext4_sync_file at ffffffff8120f07b
  [ffff88033d72df00] vfs_write at ffffffff811764b0
  [ffff88033d72df50] xen_hypervisor_callback at ffffffff816606db
    RIP: 00007f6852c7b39a  RSP: 00007fff431454e0  RFLAGS: 00000212
    RAX: 00007f6852fb38b8  RBX: 00007f6852fb3720  RCX: 000000000000014a
    RDX: 0000000000000150  RSI: 0000000000000140  RDI: 00007f6852fb3720
    RBP: 0000000000000150   R8: 0000000000000015   R9: 0000000000000000
    R10: 0000000000000000  R11: 00007f6852c9174a  R12: 00007f6852fb3778
    R13: 0000000000000140  R14: 00007f6852fb38b8  R15: 0000000000000001
    ORIG_RAX: ffffffffffffffff  CS: e033  SS: e02b

#> bt -T ffff88033b812dc0
PID: 2069   TASK: ffff88033b812dc0  CPU: 6   COMMAND: "postgres"
  [ffff88033b897530] get_page_from_freelist at ffffffff8111e6df
  [ffff88033b897600] __alloc_pages_nodemask at ffffffff8111ebec
  [ffff88033b897640] radix_tree_lookup at ffffffff8130db6b
  [ffff88033b897650] irq_to_desc at ffffffff810d70b7
  [ffff88033b897660] irq_get_irq_data at ffffffff810d9f4e
  [ffff88033b897670] balance_tasks at ffffffff8105e493
  [ffff88033b897680] radix_tree_lookup_slot at ffffffff8130db5e
  [ffff88033b897690] find_get_page at ffffffff811161ee
  [ffff88033b8976b0] find_lock_page at ffffffff81116286
  [ffff88033b8976e0] shmem_getpage_gfp at ffffffff8112dd10
  [ffff88033b897748] pte_pfn_to_mfn at ffffffff81005a78
  [ffff88033b897770] xen_set_pte_at at ffffffff81008e29
  [ffff88033b897788] __raw_callee_save_xen_make_pte at ffffffff810052cd
  [ffff88033b8977b0] unlock_page at ffffffff8111589a
  [ffff88033b8977d0] __do_fault at ffffffff81138ac9
  [ffff88033b8978a0] pvclock_clocksource_read at ffffffff8103dd15
  [ffff88033b8978f0] xen_clocksource_read at ffffffff8100a850
  [ffff88033b897900] sched_clock at ffffffff8101bd79
  [ffff88033b897910] blk_rq_init at ffffffff812ec262
  [ffff88033b897930] get_request at ffffffff812f004e
  [ffff88033b8979c0] cpumask_next_and at ffffffff81308c66
  [ffff88033b8979e0] find_busiest_group at ffffffff8105a061
  --- bt -t ends here
  [ffff88033b897a30] radix_tree_lookup at ffffffff8130db6b
  [ffff88033b897a40] irq_to_desc at ffffffff810d70b7
  [ffff88033b897a50] irq_get_irq_data at ffffffff810d9f4e
  [ffff88033b897a60] info_for_irq at ffffffff813a636e
  [ffff88033b897a80] xen_poll_irq_timeout at ffffffff813a696e
  [ffff88033b897ac0] xen_poll_irq at ffffffff813a8450
  [ffff88033b897ad0] xen_spin_lock_slow at ffffffff8163ad77
  [ffff88033b897b20] xen_spin_lock at ffffffff810121da
  [ffff88033b897b40] _raw_spin_lock at ffffffff81655e4e
  [ffff88033b897b50] double_rq_lock at ffffffff8105119c
  [ffff88033b897b80] load_balance at ffffffff8105e788
  [ffff88033b897b88] _raw_spin_unlock_irqrestore at ffffffff8165605e
  [ffff88033b897c10] idle_balance at ffffffff8163d57c
  [ffff88033b897c60] __schedule at ffffffff81653ea9
  [ffff88033b897cc0] sleep_on_page at ffffffff81115810
  [ffff88033b897ce0] schedule at ffffffff81653fcf
  [ffff88033b897cf0] io_schedule at ffffffff8165407f
  [ffff88033b897d10] sleep_on_page at ffffffff8111581e
  [ffff88033b897d20] __wait_on_bit at ffffffff8165489f
  [ffff88033b897d70] wait_on_page_bit at ffffffff81115988
  [ffff88033b897da0] wake_bit_function at ffffffff8108a140
  [ffff88033b897dc0] filemap_fdatawait_range at ffffffff81115a9c
  [ffff88033b897e60] do_writepages at ffffffff81120ee1
  [ffff88033b897eb0] filemap_write_and_wait_range at ffffffff81117398
  [ffff88033b897ee0] ext4_sync_file at ffffffff8120ef9f
  [ffff88033b897f00] vfs_write at ffffffff811764b0
  [ffff88033b897f40] do_fsync at ffffffff811a4a36
  [ffff88033b897f70] sys_fdatasync at ffffffff811a4d83
  [ffff88033b897f80] system_call_fastpath at ffffffff8165e442
    RIP: 00007f6852ce8240  RSP: 00007fff43145618  RFLAGS: 00000246
    RAX: 000000000000004b  RBX: ffffffff8165e442  RCX: 00007f6852ce1900
    RDX: 00000000000000c5  RSI: 000000000000000c  RDI: 000000000000000c
    RBP: 00000000000000c5   R8: 000000000073a550   R9: 0000000000000000
    R10: 0000000000000004  R11: 0000000000000246  R12: ffffffff811a4d83
    R13: ffff88033b897f78  R14: 0000000000000001  R15: 0000000000af7488
    ORIG_RAX: 000000000000004b  CS: e033  SS: e02b


--------------enigDC212E15171035B117EDAF53
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRFRrAAAoJEOhnXe7L7s6jbxEP/3p7L9ASFBZDCrxsnG7n67jQ
2MysQ0MWLtbVrngaGSCz5GLK609T1rVnTt4Yn67EGc2R01Rhnohfplelcp3l7jOt
t2LidGO7A0oS2+XPLc+WfWQ5OzEqRoRX51A4UDffA7Ug4GJ/TkjSIHwiJ7xA8rNW
1pNozx5C9WivKouuMleWQYGXAZe1NzloC6EONXva+c9NEtHIJURG5DZI42e+/DTB
TIeeU/SIus9+vzji9Kyvlvs6xry3+t2kUMRKN/u6PKTRgyK5zxaq3xtQQ4vBcrht
XosLKxoSYo2nBo324KO/Rep5hMCgD2QCaHEByEpxfYlKwJUsbCX0FnyKSryv4FK8
xek3ui61hbHSpfEYAtPtOPQ48GqPIlJ+l5frq1Dh6FjCoIFPQgQgujFz0/u14dOz
Gj/AmMZtkecGC0cJMHGEXJCNEL1YEw+n9+cey2ohriNzNnqat3CgUNNuxiqqTNcu
Jv86GvbRqhQDs4lprPcenLtmctEJ/E/dMQ3c1DlSnLhLsxh5bfrpIGfzu7pWs4Ke
HmqKzNpECpMXHJuMVVfYk9o7VKS8YKsUhG0bT81Xa9RWOKGMP/oWz62ErYOC5B8+
U/4vxnxBiE5SZY6KNPVnds2tHCRVSZvjekfpvmvtyVp4uPhAWlZZ6JDEqqlCyMBT
KOcWVqMVUzGN1NtYgKqb
=2vi6
-----END PGP SIGNATURE-----

--------------enigDC212E15171035B117EDAF53--


--===============0007533134303517939==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0007533134303517939==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 15:33:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3pxH-0007nQ-9p; Fri, 08 Feb 2013 15:33:35 +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 1U3pxF-0007nL-Er
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:33:33 +0000
Received: from [193.109.254.147:41690] by server-10.bemta-14.messagelabs.com
	id 37/57-12679-CCA15115; Fri, 08 Feb 2013 15:33:32 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360337604!9274531!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27982 invoked from network); 8 Feb 2013 15:33:24 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-8.tower-27.messagelabs.com with SMTP;
	8 Feb 2013 15:33:24 -0000
Received: from p5b2e3bbe.dip.t-dialin.net ([91.46.59.190] 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 1U3px5-0005hC-QZ; Fri, 08 Feb 2013 15:33:23 +0000
Message-ID: <51151ABF.1070007@canonical.com>
Date: Fri, 08 Feb 2013 16:33:19 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0007533134303517939=="
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)
--===============0007533134303517939==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigDC212E15171035B117EDAF53"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDC212E15171035B117EDAF53
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

A while ago I had been reporting an issue which causes Xen PVM guests
to hang (apparently related to spinlocks). Since then I was able to
gather a few more facts which I try to provide below. For the real
reasons, I am still puzzled and would be thankful for any hints or
direction.

- Happens with Xen 4.1.2 and Xen 4.2 host-side.
- PVM guest with 8 VCPUs is running 800 threads doing DB updates.
- When hanging at least 2 VCPUs in xen_spin_lock_slow with the lock free.=

  IIRC the weird lock always belongs to one VCPU runqueue.
- Testcase shows the problem for guest kernel versions v3.2..v3.5 (not
  verified farther back). Since v3.6 it cannot be reproduced. Bisect
  ends up with: 611ae8e3f5204f7480b3b405993b3352cfa16662
    "x86/tlb: enable tlb flush range support for x86"
- The other potential fix for this was to prevent xen_spin_lock_slow()
  from unmasking events (enabling interrupts) if those were enabled
  before the spinlock call.

Maybe allowing or not allowing the interrupts in xen_spin_lock_slow
just manages to tip the likelihood of getting nested deeper. The same
way that the changed TLB flush may reduce it by causing lesser IPIs.
=46rom the static information I can extract from a dump it is hard to
tell what exactly is going on. VCPU2 seems to be doing something but
looks to be rather deep in event handling. The irq_count is at 2, but
irq_count seems to be used in a few more places than just xen_hypervisor
callback. Though that at least seems to be the entry on the stack I can
see for VCPU2. The contents of the per-cpu variables for irq_reqs and
irq_stack_ptr at least seem consistent as if a callback came in while
being on the sched_op hypercall. But then the bt command seems to be
operating on a completely different stack.
VCPU2 seems to be active, not polling (event processing could be initiate=
d
from enable_irqs via force callback or before finally exiting the sched_o=
p
hypercall), there seems to be a pending upcall but upcalls are masked.
The next thing I would try is to instrument the sites incrementing and
decrementing irq_count...
---

Below some of the info seen from dom0 debugging keys and looking
at a dump with crash:

Dom0 Info:

Polling vCPUs: {1,5-7}
VCPU0: CPU0 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU1: CPU1 [has=3DF] poll=3D10 upcall_pend =3D 00, upcall_mask =3D 00
VCPU2: CPU6 [has=3DT] poll=3D0  upcall_pend =3D 01, upcall_mask =3D 01
VCPU3: CPU2 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU4: CPU4 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU5: CPU3 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00
VCPU6: CPU7 [has=3DF] poll=3D40 upcall_pend =3D 01, upcall_mask =3D 01
VCPU7: CPU4 [has=3DF] poll=3D46 upcall_pend =3D 01, upcall_mask =3D 01

10 [0/1]: s=3D6 n=3D1 x=3D0
40 [0/1]: s=3D6 n=3D6 x=3D0
46 [0/1]: s=3D6 n=3D7 x=3D0

Guest Info:

lock_spinners:
[0] (struct xen_spinlock *) 0x
[1] (struct xen_spinlock *) 0xffff8803bffc8ae8 =3D { lock=3D1, spinners=3D=
2 }
[2] (struct xen_spinlock *) 0xffff8803bfc93700 =3D { lock=3D0, spinners=3D=
2 }
[3] (struct xen_spinlock *) 0x
[4] (struct xen_spinlock *) 0x
[5] (struct xen_spinlock *) 0xffff8803bffc8ae8 -> [1]
[6] (struct xen_spinlock *) 0xffff8803bfc93700 -> [2]
[7] (struct xen_spinlock *) 0xffffffff81f15ef0 =3D { lock=3D1, spinners=3D=
1 }

VCPU[2,6] -> lock of runqueue[2] =3D (struct rq *) 0xffff8803bfc93700

irq_count[1] =3D 1
irq_count[2] =3D 2
It is -1 for the rest.

*(struct pt_regs *) irq_regs[2] =3D {
	.ip =3D 0xffffffff810013aa =3D=3D hypercall_page+938 -> sched_op
	.sp =3D 0xffff8803bfc83ce8
}

char *irq_stack_ptr[2] =3D 0xffff8803bfc83fc0

#> bt -T ffff88033d65c4a0
PID: 2050   TASK: ffff88033d65c4a0  CPU: 2   COMMAND: "postgres"
  [ffff88033d72d530] get_page_from_freelist at ffffffff8111e6df
  [ffff88033d72d600] __alloc_pages_nodemask at ffffffff8111ebec
  [ffff88033d72d620] check_preempt_curr at ffffffff81050254
  [ffff88033d72d640] pull_task at ffffffff8105e33e
  [ffff88033d72d670] balance_tasks at ffffffff8105e4b6
  [ffff88033d72d680] radix_tree_lookup_slot at ffffffff8130db5e
  [ffff88033d72d690] find_get_page at ffffffff811161ee
  [ffff88033d72d6b0] find_lock_page at ffffffff81116286
  [ffff88033d72d6e0] shmem_getpage_gfp at ffffffff8112dd10
  [ffff88033d72d748] pte_pfn_to_mfn at ffffffff81005a78
  [ffff88033d72d7a0] get_page_from_freelist at ffffffff8111e6df
  [ffff88033d72d7c0] _raw_spin_lock at ffffffff81655e4e
  [ffff88033d72d7d0] ext4_ext_check_cache at ffffffff81239248
  [ffff88033d72d820] ext4_ext_map_blocks at ffffffff8123e269
  [ffff88033d72d870] _raw_spin_lock at ffffffff81655e4e
  [ffff88033d72d880] enqueue_to_backlog at ffffffff8153e55f
  [ffff88033d72d890] __wake_up_common at ffffffff8104c1c8
  [ffff88033d72d8e0] netif_rx.part.82 at ffffffff8153f2de
  [ffff88033d72d920] netif_rx at ffffffff8153f400
  [ffff88033d72d960] loopback_xmit at ffffffff8146fb1c
  [ffff88033d72d990] dev_hard_start_xmit at ffffffff8153fea6
  [ffff88033d72d9d0] do_softirq at ffffffff81016284
  [ffff88033d72d9f0] local_bh_enable at ffffffff8106d614
  [ffff88033d72da00] dev_queue_xmit at ffffffff81540309
  [ffff88033d72da50] ip_finish_output at ffffffff815769ab
  [ffff88033d72da90] ip_output at ffffffff81577518
  [ffff88033d72dac0] ip_local_out at ffffffff81576c09
  [ffff88033d72dae0] ip_send_skb at ffffffff81577f4b
  [ffff88033d72db00] udp_send_skb at ffffffff8159aaa1
  [ffff88033d72db40] ip_generic_getfrag at ffffffff81575030
  [ffff88033d72db50] udp_sendmsg at ffffffff8159bd38
  [ffff88033d72db90] irq_to_desc at ffffffff810d70b7
  [ffff88033d72dbd0] notify_remote_via_irq at ffffffff813a74c1
  [ffff88033d72dc10] ttwu_queue at ffffffff81052672
  [ffff88033d72dc38] _raw_spin_unlock_irqrestore at ffffffff8165605e
  [ffff88033d72dc90] inet_sendmsg at ffffffff815a6474
  --- bt -t would end here
  [ffff88033d72dcb0] apparmor_socket_sendmsg at ffffffff812d43f7
  [ffff88033d72dcd0] sock_sendmsg at ffffffff815266fe
  [ffff88033d72dd70] md_make_request at ffffffff814e0606
  [ffff88033d72ddd0] kmem_cache_free at ffffffff811605cf
  [ffff88033d72de10] mempool_free_slab at ffffffff81118507
  [ffff88033d72de20] mempool_free at ffffffff811185b7
  [ffff88033d72de50] sys_sendto at ffffffff8152974d
  [ffff88033d72dee0] ext4_sync_file at ffffffff8120f07b
  [ffff88033d72df00] vfs_write at ffffffff811764b0
  [ffff88033d72df50] xen_hypervisor_callback at ffffffff816606db
    RIP: 00007f6852c7b39a  RSP: 00007fff431454e0  RFLAGS: 00000212
    RAX: 00007f6852fb38b8  RBX: 00007f6852fb3720  RCX: 000000000000014a
    RDX: 0000000000000150  RSI: 0000000000000140  RDI: 00007f6852fb3720
    RBP: 0000000000000150   R8: 0000000000000015   R9: 0000000000000000
    R10: 0000000000000000  R11: 00007f6852c9174a  R12: 00007f6852fb3778
    R13: 0000000000000140  R14: 00007f6852fb38b8  R15: 0000000000000001
    ORIG_RAX: ffffffffffffffff  CS: e033  SS: e02b

#> bt -T ffff88033b812dc0
PID: 2069   TASK: ffff88033b812dc0  CPU: 6   COMMAND: "postgres"
  [ffff88033b897530] get_page_from_freelist at ffffffff8111e6df
  [ffff88033b897600] __alloc_pages_nodemask at ffffffff8111ebec
  [ffff88033b897640] radix_tree_lookup at ffffffff8130db6b
  [ffff88033b897650] irq_to_desc at ffffffff810d70b7
  [ffff88033b897660] irq_get_irq_data at ffffffff810d9f4e
  [ffff88033b897670] balance_tasks at ffffffff8105e493
  [ffff88033b897680] radix_tree_lookup_slot at ffffffff8130db5e
  [ffff88033b897690] find_get_page at ffffffff811161ee
  [ffff88033b8976b0] find_lock_page at ffffffff81116286
  [ffff88033b8976e0] shmem_getpage_gfp at ffffffff8112dd10
  [ffff88033b897748] pte_pfn_to_mfn at ffffffff81005a78
  [ffff88033b897770] xen_set_pte_at at ffffffff81008e29
  [ffff88033b897788] __raw_callee_save_xen_make_pte at ffffffff810052cd
  [ffff88033b8977b0] unlock_page at ffffffff8111589a
  [ffff88033b8977d0] __do_fault at ffffffff81138ac9
  [ffff88033b8978a0] pvclock_clocksource_read at ffffffff8103dd15
  [ffff88033b8978f0] xen_clocksource_read at ffffffff8100a850
  [ffff88033b897900] sched_clock at ffffffff8101bd79
  [ffff88033b897910] blk_rq_init at ffffffff812ec262
  [ffff88033b897930] get_request at ffffffff812f004e
  [ffff88033b8979c0] cpumask_next_and at ffffffff81308c66
  [ffff88033b8979e0] find_busiest_group at ffffffff8105a061
  --- bt -t ends here
  [ffff88033b897a30] radix_tree_lookup at ffffffff8130db6b
  [ffff88033b897a40] irq_to_desc at ffffffff810d70b7
  [ffff88033b897a50] irq_get_irq_data at ffffffff810d9f4e
  [ffff88033b897a60] info_for_irq at ffffffff813a636e
  [ffff88033b897a80] xen_poll_irq_timeout at ffffffff813a696e
  [ffff88033b897ac0] xen_poll_irq at ffffffff813a8450
  [ffff88033b897ad0] xen_spin_lock_slow at ffffffff8163ad77
  [ffff88033b897b20] xen_spin_lock at ffffffff810121da
  [ffff88033b897b40] _raw_spin_lock at ffffffff81655e4e
  [ffff88033b897b50] double_rq_lock at ffffffff8105119c
  [ffff88033b897b80] load_balance at ffffffff8105e788
  [ffff88033b897b88] _raw_spin_unlock_irqrestore at ffffffff8165605e
  [ffff88033b897c10] idle_balance at ffffffff8163d57c
  [ffff88033b897c60] __schedule at ffffffff81653ea9
  [ffff88033b897cc0] sleep_on_page at ffffffff81115810
  [ffff88033b897ce0] schedule at ffffffff81653fcf
  [ffff88033b897cf0] io_schedule at ffffffff8165407f
  [ffff88033b897d10] sleep_on_page at ffffffff8111581e
  [ffff88033b897d20] __wait_on_bit at ffffffff8165489f
  [ffff88033b897d70] wait_on_page_bit at ffffffff81115988
  [ffff88033b897da0] wake_bit_function at ffffffff8108a140
  [ffff88033b897dc0] filemap_fdatawait_range at ffffffff81115a9c
  [ffff88033b897e60] do_writepages at ffffffff81120ee1
  [ffff88033b897eb0] filemap_write_and_wait_range at ffffffff81117398
  [ffff88033b897ee0] ext4_sync_file at ffffffff8120ef9f
  [ffff88033b897f00] vfs_write at ffffffff811764b0
  [ffff88033b897f40] do_fsync at ffffffff811a4a36
  [ffff88033b897f70] sys_fdatasync at ffffffff811a4d83
  [ffff88033b897f80] system_call_fastpath at ffffffff8165e442
    RIP: 00007f6852ce8240  RSP: 00007fff43145618  RFLAGS: 00000246
    RAX: 000000000000004b  RBX: ffffffff8165e442  RCX: 00007f6852ce1900
    RDX: 00000000000000c5  RSI: 000000000000000c  RDI: 000000000000000c
    RBP: 00000000000000c5   R8: 000000000073a550   R9: 0000000000000000
    R10: 0000000000000004  R11: 0000000000000246  R12: ffffffff811a4d83
    R13: ffff88033b897f78  R14: 0000000000000001  R15: 0000000000af7488
    ORIG_RAX: 000000000000004b  CS: e033  SS: e02b


--------------enigDC212E15171035B117EDAF53
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRFRrAAAoJEOhnXe7L7s6jbxEP/3p7L9ASFBZDCrxsnG7n67jQ
2MysQ0MWLtbVrngaGSCz5GLK609T1rVnTt4Yn67EGc2R01Rhnohfplelcp3l7jOt
t2LidGO7A0oS2+XPLc+WfWQ5OzEqRoRX51A4UDffA7Ug4GJ/TkjSIHwiJ7xA8rNW
1pNozx5C9WivKouuMleWQYGXAZe1NzloC6EONXva+c9NEtHIJURG5DZI42e+/DTB
TIeeU/SIus9+vzji9Kyvlvs6xry3+t2kUMRKN/u6PKTRgyK5zxaq3xtQQ4vBcrht
XosLKxoSYo2nBo324KO/Rep5hMCgD2QCaHEByEpxfYlKwJUsbCX0FnyKSryv4FK8
xek3ui61hbHSpfEYAtPtOPQ48GqPIlJ+l5frq1Dh6FjCoIFPQgQgujFz0/u14dOz
Gj/AmMZtkecGC0cJMHGEXJCNEL1YEw+n9+cey2ohriNzNnqat3CgUNNuxiqqTNcu
Jv86GvbRqhQDs4lprPcenLtmctEJ/E/dMQ3c1DlSnLhLsxh5bfrpIGfzu7pWs4Ke
HmqKzNpECpMXHJuMVVfYk9o7VKS8YKsUhG0bT81Xa9RWOKGMP/oWz62ErYOC5B8+
U/4vxnxBiE5SZY6KNPVnds2tHCRVSZvjekfpvmvtyVp4uPhAWlZZ6JDEqqlCyMBT
KOcWVqMVUzGN1NtYgKqb
=2vi6
-----END PGP SIGNATURE-----

--------------enigDC212E15171035B117EDAF53--


--===============0007533134303517939==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0007533134303517939==--


From xen-devel-bounces@lists.xen.org Fri Feb 08 15:41:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3q4V-0007zQ-7z; Fri, 08 Feb 2013 15:41: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 1U3q4S-0007zL-OU
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:41:00 +0000
Received: from [85.158.139.211:60727] by server-13.bemta-5.messagelabs.com id
	94/02-06769-B8C15115; Fri, 08 Feb 2013 15:40:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360338057!21554854!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 713 invoked from network); 8 Feb 2013 15:40:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:40:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6483032"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 15:40:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 10:40:57 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3q4O-0003i1-TC;
	Fri, 08 Feb 2013 15:40:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Feb 2013 15:40:56 +0000
Message-ID: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: arm32: Use system wide TLB flushes,
	not just inner-shareable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 currently setup page table walks etc as outer-shareable. Given we don't
really make the distinction between inner- and outer-shareable yet err on
theside of safety.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/flushtlb.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
index 210abfa..5067e5d 100644
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -19,7 +19,7 @@ static inline void flush_tlb_local(void)
 {
     dsb();
 
-    WRITE_CP32((uint32_t) 0, TLBIALLIS);
+    WRITE_CP32((uint32_t) 0, TLBIALL);
 
     dsb();
     isb();
@@ -30,7 +30,7 @@ static inline void flush_tlb_all_local(void)
 {
     dsb();
 
-    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
+    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
 
     dsb();
     isb();
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:41:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3q4V-0007zQ-7z; Fri, 08 Feb 2013 15:41: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 1U3q4S-0007zL-OU
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:41:00 +0000
Received: from [85.158.139.211:60727] by server-13.bemta-5.messagelabs.com id
	94/02-06769-B8C15115; Fri, 08 Feb 2013 15:40:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360338057!21554854!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 713 invoked from network); 8 Feb 2013 15:40:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:40:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6483032"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 15:40:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 10:40:57 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U3q4O-0003i1-TC;
	Fri, 08 Feb 2013 15:40:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 8 Feb 2013 15:40:56 +0000
Message-ID: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: arm32: Use system wide TLB flushes,
	not just inner-shareable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 currently setup page table walks etc as outer-shareable. Given we don't
really make the distinction between inner- and outer-shareable yet err on
theside of safety.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/flushtlb.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
index 210abfa..5067e5d 100644
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -19,7 +19,7 @@ static inline void flush_tlb_local(void)
 {
     dsb();
 
-    WRITE_CP32((uint32_t) 0, TLBIALLIS);
+    WRITE_CP32((uint32_t) 0, TLBIALL);
 
     dsb();
     isb();
@@ -30,7 +30,7 @@ static inline void flush_tlb_all_local(void)
 {
     dsb();
 
-    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
+    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
 
     dsb();
     isb();
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:41:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3q4g-000802-KW; Fri, 08 Feb 2013 15:41:14 +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 1U3q4e-0007zt-JH
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:41:12 +0000
Received: from [85.158.139.83:59437] by server-6.bemta-5.messagelabs.com id
	DB/64-01489-79C15115; Fri, 08 Feb 2013 15:41:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360338071!31317574!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 624 invoked from network); 8 Feb 2013 15:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1286936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 15:41: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.297.1; Fri, 8 Feb 2013
	15:41:11 +0000
Message-ID: <1360338069.29432.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 8 Feb 2013 15:41:09 +0000
In-Reply-To: <20130207153119.GK77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-11-git-send-email-ian.campbell@citrix.com>
	<20130207153119.GK77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 11/45] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 15:31 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956577), Ian Campbell wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-arm/arm64/flushtlb.h
> > @@ -0,0 +1,34 @@
> > +#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
> > +#define __ASM_ARM_ARM64_FLUSHTLB_H__
> > +
> > +/* Flush local TLBs, current VMID only */
> > +static inline void flush_tlb_local(void)
> > +{
> > +    asm volatile(
> > +        "dsb sy;"
> > +        "tlbi vmalle1;" /* ,is ??? */
> 
> Good question.  I think probably not ',is'; at least not until we decide
> on, and document, what inner & outer mean on a Xen system.

Agreed, dropped the comment.

> I see that the 32-bit equivalent does use IS; I think that's proabably
> an error too.

I have sent out a patch for this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:41:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3q4g-000802-KW; Fri, 08 Feb 2013 15:41:14 +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 1U3q4e-0007zt-JH
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:41:12 +0000
Received: from [85.158.139.83:59437] by server-6.bemta-5.messagelabs.com id
	DB/64-01489-79C15115; Fri, 08 Feb 2013 15:41:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360338071!31317574!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 624 invoked from network); 8 Feb 2013 15:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 15:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1286936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 15:41: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.297.1; Fri, 8 Feb 2013
	15:41:11 +0000
Message-ID: <1360338069.29432.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 8 Feb 2013 15:41:09 +0000
In-Reply-To: <20130207153119.GK77133@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-11-git-send-email-ian.campbell@citrix.com>
	<20130207153119.GK77133@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 11/45] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-07 at 15:31 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956577), Ian Campbell wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-arm/arm64/flushtlb.h
> > @@ -0,0 +1,34 @@
> > +#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
> > +#define __ASM_ARM_ARM64_FLUSHTLB_H__
> > +
> > +/* Flush local TLBs, current VMID only */
> > +static inline void flush_tlb_local(void)
> > +{
> > +    asm volatile(
> > +        "dsb sy;"
> > +        "tlbi vmalle1;" /* ,is ??? */
> 
> Good question.  I think probably not ',is'; at least not until we decide
> on, and document, what inner & outer mean on a Xen system.

Agreed, dropped the comment.

> I see that the 32-bit equivalent does use IS; I think that's proabably
> an error too.

I have sent out a patch for this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:44:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3q7E-0008Bu-72; Fri, 08 Feb 2013 15:43: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 1U3q7D-0008Bl-BB
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:43:51 +0000
Received: from [85.158.143.99:32843] by server-3.bemta-4.messagelabs.com id
	9B/B7-08920-63D15115; Fri, 08 Feb 2013 15:43:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360338230!30468233!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32386 invoked from network); 8 Feb 2013 15:43:50 -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; 8 Feb 2013 15:43:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3q7B-000ObR-Jg; Fri, 08 Feb 2013 15:43:49 +0000
Date: Fri, 8 Feb 2013 15:43:49 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130208154349.GA93591@ocelot.phlegethon.org>
References: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm32: Use system wide TLB flushes,
	not just inner-shareable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:40 +0000 on 08 Feb (1360338056), Ian Campbell wrote:
> We currently setup page table walks etc as outer-shareable. Given we don't
> really make the distinction between inner- and outer-shareable yet err on
> theside of safety.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
> Cc: Tim Deegan <tim@xen.org>
> ---
>  xen/include/asm-arm/flushtlb.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
> index 210abfa..5067e5d 100644
> --- a/xen/include/asm-arm/flushtlb.h
> +++ b/xen/include/asm-arm/flushtlb.h
> @@ -19,7 +19,7 @@ static inline void flush_tlb_local(void)
>  {
>      dsb();
>  
> -    WRITE_CP32((uint32_t) 0, TLBIALLIS);
> +    WRITE_CP32((uint32_t) 0, TLBIALL);
>  
>      dsb();
>      isb();
> @@ -30,7 +30,7 @@ static inline void flush_tlb_all_local(void)
>  {
>      dsb();
>  
> -    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
> +    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
>  
>      dsb();
>      isb();
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 15:44:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 15: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 1U3q7E-0008Bu-72; Fri, 08 Feb 2013 15:43: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 1U3q7D-0008Bl-BB
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 15:43:51 +0000
Received: from [85.158.143.99:32843] by server-3.bemta-4.messagelabs.com id
	9B/B7-08920-63D15115; Fri, 08 Feb 2013 15:43:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360338230!30468233!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32386 invoked from network); 8 Feb 2013 15:43:50 -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; 8 Feb 2013 15:43:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3q7B-000ObR-Jg; Fri, 08 Feb 2013 15:43:49 +0000
Date: Fri, 8 Feb 2013 15:43:49 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130208154349.GA93591@ocelot.phlegethon.org>
References: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: arm32: Use system wide TLB flushes,
	not just inner-shareable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:40 +0000 on 08 Feb (1360338056), Ian Campbell wrote:
> We currently setup page table walks etc as outer-shareable. Given we don't
> really make the distinction between inner- and outer-shareable yet err on
> theside of safety.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
> Cc: Tim Deegan <tim@xen.org>
> ---
>  xen/include/asm-arm/flushtlb.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
> index 210abfa..5067e5d 100644
> --- a/xen/include/asm-arm/flushtlb.h
> +++ b/xen/include/asm-arm/flushtlb.h
> @@ -19,7 +19,7 @@ static inline void flush_tlb_local(void)
>  {
>      dsb();
>  
> -    WRITE_CP32((uint32_t) 0, TLBIALLIS);
> +    WRITE_CP32((uint32_t) 0, TLBIALL);
>  
>      dsb();
>      isb();
> @@ -30,7 +30,7 @@ static inline void flush_tlb_all_local(void)
>  {
>      dsb();
>  
> -    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
> +    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
>  
>      dsb();
>      isb();
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:06:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:06: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 1U3qT0-0001Bt-9u; Fri, 08 Feb 2013 16:06:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3qSz-0001Bn-5J
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:06:21 +0000
Received: from [85.158.143.99:44159] by server-2.bemta-4.messagelabs.com id
	A1/3F-01597-C7225115; Fri, 08 Feb 2013 16:06:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360339578!23254263!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3581 invoked from network); 8 Feb 2013 16:06:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1287837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:06:18 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 8 Feb 2013
	16:06:17 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 8 Feb 2013 16:06:55 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4FKlXG6T1jigJtQli5bZ+1hW1pBQA60lbg
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
In-Reply-To: <1360238260.2536.22.camel@zion.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: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 07 February 2013 11:58
> To: Paul Durrant
> Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> jbeulich@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> 
> On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > [snip]
> > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > sizeof(unsigned long) * 64)
> > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > +sizeof(unsigned long) * 64)
> > > > >
> > > > > We did a bit of header change to make the ARM code always use
> > > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t
> > > > > and
> > > xen_mfn_t typdefs.
> > > > >
> > > > > Any chance you can do that here? That way on ARM - irregardless
> > > > > if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > >
> > > >
> > > > I don't think so. The reason to use unsigned long here is to
> > > > guarantee each selector (in 2-level case there is only L1
> > > > selector) fits into a word.
> > >
> >
> > That's still going to be a problem with Windows drivers. Unfortunately
> MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is
> word size is a pointer. Any chance we can use uintptr_t rather than an
> unsigned long? (At the moment I have to sed all the public headers to
> replace long with LONG_PTR and it's a PITA).
> >
> 
> TBH I don't know much about Windows. But are you suggesting replace all
> the relevant bit in the header or just the specific event channel interface?
> 

I was just pointing out that assumption that unsigned long == native word size does not hold for 64-bit Windows. So, if we're adding something new can we avoid use of unsigned long and use an abstract type defined to be the native word size?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:06:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:06: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 1U3qT0-0001Bt-9u; Fri, 08 Feb 2013 16:06:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3qSz-0001Bn-5J
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:06:21 +0000
Received: from [85.158.143.99:44159] by server-2.bemta-4.messagelabs.com id
	A1/3F-01597-C7225115; Fri, 08 Feb 2013 16:06:20 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360339578!23254263!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3581 invoked from network); 8 Feb 2013 16:06:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1287837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:06:18 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 8 Feb 2013
	16:06:17 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 8 Feb 2013 16:06:55 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4FKlXG6T1jigJtQli5bZ+1hW1pBQA60lbg
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
In-Reply-To: <1360238260.2536.22.camel@zion.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: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 07 February 2013 11:58
> To: Paul Durrant
> Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> jbeulich@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> 
> On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > [snip]
> > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > sizeof(unsigned long) * 64)
> > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > +sizeof(unsigned long) * 64)
> > > > >
> > > > > We did a bit of header change to make the ARM code always use
> > > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t
> > > > > and
> > > xen_mfn_t typdefs.
> > > > >
> > > > > Any chance you can do that here? That way on ARM - irregardless
> > > > > if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > >
> > > >
> > > > I don't think so. The reason to use unsigned long here is to
> > > > guarantee each selector (in 2-level case there is only L1
> > > > selector) fits into a word.
> > >
> >
> > That's still going to be a problem with Windows drivers. Unfortunately
> MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is
> word size is a pointer. Any chance we can use uintptr_t rather than an
> unsigned long? (At the moment I have to sed all the public headers to
> replace long with LONG_PTR and it's a PITA).
> >
> 
> TBH I don't know much about Windows. But are you suggesting replace all
> the relevant bit in the header or just the specific event channel interface?
> 

I was just pointing out that assumption that unsigned long == native word size does not hold for 64-bit Windows. So, if we're adding something new can we avoid use of unsigned long and use an abstract type defined to be the native word size?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:10:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3qWQ-0001Ih-Ur; Fri, 08 Feb 2013 16:09:54 +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 1U3qWO-0001IZ-Ix
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 16:09:52 +0000
Received: from [85.158.139.211:10037] by server-6.bemta-5.messagelabs.com id
	21/85-01489-F4325115; Fri, 08 Feb 2013 16:09:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360339789!18956168!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6154 invoked from network); 8 Feb 2013 16:09:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:09:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6488386"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 16:09:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 11:09:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3qWK-00049x-BP;
	Fri, 08 Feb 2013 16:09:48 +0000
Date: Fri, 8 Feb 2013 16:09:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
In-Reply-To: <CACaajQtxLauXCmYP0yjzO0tCDmufafty=XOYNPWjA1bAXH98Aw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302081559400.4275@kaball.uk.xensource.com>
References: <CACaajQtmHY2EJcODrgFCmJFqOg-sNo8Q4_DotStrLF0RFvVp8g@mail.gmail.com>
	<1358762719.3279.158.camel@zakaz.uk.xensource.com>
	<CACaajQusNCQM1qOs_38oRSba2mr0+emQzEV8Pn332D-MdtW_ZQ@mail.gmail.com>
	<1358849670.3279.315.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301221142370.29727@kaball.uk.xensource.com>
	<CACaajQstT3EbNSk=ssxjyWtT4M0YyF4xhVBYjLjyJ39O62XfCg@mail.gmail.com>
	<CACaajQsgLpWk7y7ym2Lu2fav_bJZVneu7pZt4_AqQwDX1RQMnQ@mail.gmail.com>
	<alpine.DEB.2.02.1301301609280.10432@kaball.uk.xensource.com>
	<CACaajQtxLauXCmYP0yjzO0tCDmufafty=XOYNPWjA1bAXH98Aw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "james.harper@bendigoit.com.au" <james.harper@bendigoit.com.au>,
	"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] can't boot from iso on cifs mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 for the late reply.

O_DIRECT is called BDRV_O_NOCACHE in QEMU, we don't set BDRV_O_NOCACHE
in xenstore.c, so I don't know where the O_DIRECT flag comes from.

What version of Xen and QEMU are you using?
What is the last commit on your QEMU tree?

Posting your QEMU logs after you applied this simple debug patch might
help us understand the problem:

diff --git a/block-raw-posix.c b/block-raw-posix.c
index 795cd5b..ca6bc26 100644
--- a/block-raw-posix.c
+++ b/block-raw-posix.c
@@ -190,6 +190,7 @@ static int raw_open(BlockDriverState *bs, const char *filename, int flags)
         open_flags |= O_DIRECT;
     else if (!(flags & BDRV_O_CACHE_WB))
         open_flags |= O_DSYNC;
+    printf("DEBUG flags=%lx open_flags=%lx\n", flags,open_flags);
 
     s->type = FTYPE_FILE;
 

On Fri, 1 Feb 2013, Vasiliy Tolstov wrote:
> Failed again.
> may be in xenstore.c in this code i need to delete O_DIRECT flag?
> 
> In strace before i get messages about fallback without O_DIRECT
> (provided with patch) i get this:
> 
> write(2, "Using file /var/storage/iso/SW_D"..., 130) = 130
> open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
> O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
> write(2, "qemu: could not open vbd '/local"..., 216) = 216
> 
> My be in this code i append fallback?
> 
>             if (bdrv_open2(bs, params, flags|BDRV_O_CACHE_WB /*
> snapshot and write-back */, format) < 0) {
>                 fprintf(stderr, "qemu: could not open vbd '%s' or hard
> disk image '%s' (drv '%s' format '%s')\n", buf, params, drv ? drv :
> "?", format ? format->format_name : "0");
>             } else {
>                 char* snapshot = get_snapshot_name(atoi(e_danger[i]));
>                 if (snapshot) {
>                     fprintf(stderr, "Using snapshot %s\n", snapshot);
>                     ret = bdrv_snapshot_goto(bs, snapshot);
>                     switch (ret) {
>                     case 0:
>                         /* Success */
>                         break;
>                     case -ENOTSUP:
>                         /* Don't abort here (could be read-only ISO) */
>                         fprintf(stderr, "Snapshots are not supported for "
>                             "this image file format\n");
>                         break;
>                     case -ENOENT:
>                         fprintf(stderr, "No such snapshot, skipping this "
>                             "image file\n");
>                         continue;
>                     default:
>                         fprintf(stderr, "Could not load snapshot, skipping"
>                             " this image file\n");
>                         continue;
>                     }
>                 }
>             }
> 
> 2013/1/30 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > Sorry that was my stupid mistake.
> > This should work:
> >
> > diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > index 33a5531..1786db8 100644
> > --- a/hw/xen_disk.c
> > +++ b/hw/xen_disk.c
> > @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
> >         if (blkdev->bs) {
> >             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> >                             bdrv_find_format(blkdev->fileproto)) != 0) {
> > -               bdrv_delete(blkdev->bs);
> > -               blkdev->bs = NULL;
> > -           }
> > +                /* try without O_DIRECT */
> > +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
> > +                        blkdev->filename);
> > +                qflags &= ~BDRV_O_NOCACHE;
> > +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> > +                            bdrv_find_format(blkdev->fileproto)) != 0) {
> > +                    bdrv_delete(blkdev->bs);
> > +                    blkdev->bs = NULL;
> > +                }
> > +            }
> >         }
> >         if (!blkdev->bs)
> >             return -1;
> >
> > On Wed, 30 Jan 2013, Vasiliy Tolstov wrote:
> >> Strace shows that qemu after O_DIRECT next try with O_DIRECT
> >> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
> >> EINVAL (Invalid argument)
> >> write(2, "xen be: qdisk-832: ", 19)     = 19
> >> write(2, "xen be: qdisk-832: ", 19)     = 19
> >> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
> >> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
> >> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
> >> EINVAL (Invalid argument)
> >>
> >> 2013/1/30 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> >> > Thanks for patch. But it not solve problem:
> >> > Now i have :
> >> > domid: 6
> >> > Using file /dev/disk/vbd/21-828 in read-write mode
> >> > Strip off blktap sub-type prefix to  (drv 'aio')
> >> > Watching /local/domain/0/device-model/6/logdirty/cmd
> >> > Watching /local/domain/0/device-model/6/command
> >> > Watching /local/domain/6/cpu
> >> > char device redirected to /dev/pts/5
> >> > qemu_map_cache_init nr_buckets = 10000 size 4194304
> >> > Could not open /var/run/tap/qemu-read-6
> >> > shared page at pfn feffd
> >> > buffered io page at pfn feffb
> >> > Guest uuid = c98c33c8-1891-41ec-96a0-984f3df80def
> >> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
> >> > trying write-through.
> >> > opening  with O_DIRECT failed, trying write-through.
> >> > 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/6/xen_extended_power_mgmt): read error
> >> > medium change watch on `hdc' (index: 1): aio:
> >> > 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
> >> > vcpu-set: watch node error.
> >> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> >> > xs_read(/local/domain/6/log-throttling): read error
> >> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
> >> > medium change watch on `/local/domain/6/log-throttling' - unknown
> >> > device, ignored
> >> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
> >> > trying write-through.
> >> > opening  with O_DIRECT failed, trying write-through.
> >> > log_throttling disabled
> >> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
> >> > medium change watch on `/local/domain/6/log-throttling' - unknown
> >> > device, ignored
> >> > vga s->lfb_addr = f0000000 s->lfb_end = f1000000
> >> > 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.
> >> >
> >> >
> >> > (XEN) HVM6: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> >> > (XEN) HVM6: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $
> >> > (XEN) HVM6: Bochs BIOS - build: 06/23/99
> >> > (XEN) HVM6: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> >> > (XEN) HVM6: Options: apmbios pcibios eltorito PMM
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> >> > (XEN) HVM6: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10246 MBytes)
> >> > (XEN) HVM6: IDE time out
> >> > (XEN) HVM6: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
> >> > (XEN) HVM6: IDE time out
> >> > (XEN) HVM6:
> >> > (XEN) HVM6:
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: Press F12 for boot menu.
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: Booting from Hard Disk...
> >> > (XEN) HVM6: Boot from Hard Disk failed: not a bootable disk
> >> > (XEN) HVM6:
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: No bootable device.
> >> > (XEN) HVM6: Powering off in 30 seconds.
> >> > (XEN) hvm.c:1080:d6 All CPUs offline -- powering off.
> >> >
> >> > 2013/1/22 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> >> >> On Tue, 22 Jan 2013, Ian Campbell wrote:
> >> >>> Please don't top post.
> >> >>>
> >> >>> On Tue, 2013-01-22 at 05:38 +0000, Vasiliy Tolstov wrote:
> >> >>> > Thanks!
> >> >>> > I found, that now xl tries to open iso with O_DIRECT flag.
> >> >>> > open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
> >> >>> > O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
> >> >>> > write(2, "qemu: could not open vbd '/local"..., 217) = 217
> >> >>
> >> >> xl? I guess you mean QEMU tries to open the ISO with O_DIRECT.
> >> >>
> >> >>
> >> >>> I guess CIFS doesn't support O_DIRECT. It looks like it does have mount
> >> >>> -o directio though, worth a try.
> >> >>>
> >> >>> I'm not sure what options exist to turn this off from the qemu side --
> >> >>> Stefano? I also have a feeling something changed in this regard in 4.2.x
> >> >>
> >> >> Given that you are not passing any device_model_version option to xl, I
> >> >> assume that you are running qemu-xen-traditional (ps should show that a
> >> >> binary called qemu-dm is running).
> >> >>
> >> >> If that is the case, there is currently no way to specify any flags.
> >> >> However the interesting bit is that qemu-xen-traditional opens files
> >> >> corresponding to emulated devices with BDRV_O_CACHE_WB and opens files
> >> >> corresponding to PV interfaces using BDRV_O_NOCACHE (this means
> >> >> O_DIRECT).
> >> >> This means that the failure should be caused by hw/xen_disk.c trying to
> >> >> opening the iso O_DIRECT. Paradoxically the PV inteface for a cdrom
> >> >> drive is usually never used AFAIK.
> >> >>
> >> >> Did the Windows PV drivers start using the PV cdrom interface all of a
> >> >> sudden?
> >> >>
> >> >> In any case I think that the best thing we could do it fall back to
> >> >> write-through (or should it be write-back? It might not be safe..) in
> >> >> case O_DIRECT fails. This is what qemu-xen does in such cases.
> >> >>
> >> >> Try this patch:
> >> >>
> >> >> ---
> >> >>
> >> >> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >> >> index 33a5531..d6d71fe 100644
> >> >> --- a/hw/xen_disk.c
> >> >> +++ b/hw/xen_disk.c
> >> >> @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
> >> >>         if (blkdev->bs) {
> >> >>             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> >> >>                             bdrv_find_format(blkdev->fileproto)) != 0) {
> >> >> -               bdrv_delete(blkdev->bs);
> >> >> -               blkdev->bs = NULL;
> >> >> -           }
> >> >> +                /* try without O_DIRECT */
> >> >> +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
> >> >> +                        blkdev->filename);
> >> >> +                qflags &= BDRV_O_NOCACHE;
> >> >> +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> >> >> +                            bdrv_find_format(blkdev->fileproto)) != 0) {
> >> >> +                    bdrv_delete(blkdev->bs);
> >> >> +                    blkdev->bs = NULL;
> >> >> +                }
> >> >> +            }
> >> >>         }
> >> >>         if (!blkdev->bs)
> >> >>             return -1;
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Vasiliy Tolstov,
> >> > Clodo.ru
> >> > e-mail: v.tolstov@selfip.ru
> >> > jabber: vase@selfip.ru
> >>
> >>
> >>
> >> --
> >> Vasiliy Tolstov,
> >> Clodo.ru
> >> e-mail: v.tolstov@selfip.ru
> >> jabber: vase@selfip.ru
> >>
> 
> 
> 
> --
> 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 Feb 08 16:10:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3qWQ-0001Ih-Ur; Fri, 08 Feb 2013 16:09:54 +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 1U3qWO-0001IZ-Ix
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 16:09:52 +0000
Received: from [85.158.139.211:10037] by server-6.bemta-5.messagelabs.com id
	21/85-01489-F4325115; Fri, 08 Feb 2013 16:09:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360339789!18956168!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6154 invoked from network); 8 Feb 2013 16:09:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:09:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6488386"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 16:09:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 11:09:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3qWK-00049x-BP;
	Fri, 08 Feb 2013 16:09:48 +0000
Date: Fri, 8 Feb 2013 16:09:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
In-Reply-To: <CACaajQtxLauXCmYP0yjzO0tCDmufafty=XOYNPWjA1bAXH98Aw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302081559400.4275@kaball.uk.xensource.com>
References: <CACaajQtmHY2EJcODrgFCmJFqOg-sNo8Q4_DotStrLF0RFvVp8g@mail.gmail.com>
	<1358762719.3279.158.camel@zakaz.uk.xensource.com>
	<CACaajQusNCQM1qOs_38oRSba2mr0+emQzEV8Pn332D-MdtW_ZQ@mail.gmail.com>
	<1358849670.3279.315.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301221142370.29727@kaball.uk.xensource.com>
	<CACaajQstT3EbNSk=ssxjyWtT4M0YyF4xhVBYjLjyJ39O62XfCg@mail.gmail.com>
	<CACaajQsgLpWk7y7ym2Lu2fav_bJZVneu7pZt4_AqQwDX1RQMnQ@mail.gmail.com>
	<alpine.DEB.2.02.1301301609280.10432@kaball.uk.xensource.com>
	<CACaajQtxLauXCmYP0yjzO0tCDmufafty=XOYNPWjA1bAXH98Aw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "james.harper@bendigoit.com.au" <james.harper@bendigoit.com.au>,
	"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] can't boot from iso on cifs mount
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 for the late reply.

O_DIRECT is called BDRV_O_NOCACHE in QEMU, we don't set BDRV_O_NOCACHE
in xenstore.c, so I don't know where the O_DIRECT flag comes from.

What version of Xen and QEMU are you using?
What is the last commit on your QEMU tree?

Posting your QEMU logs after you applied this simple debug patch might
help us understand the problem:

diff --git a/block-raw-posix.c b/block-raw-posix.c
index 795cd5b..ca6bc26 100644
--- a/block-raw-posix.c
+++ b/block-raw-posix.c
@@ -190,6 +190,7 @@ static int raw_open(BlockDriverState *bs, const char *filename, int flags)
         open_flags |= O_DIRECT;
     else if (!(flags & BDRV_O_CACHE_WB))
         open_flags |= O_DSYNC;
+    printf("DEBUG flags=%lx open_flags=%lx\n", flags,open_flags);
 
     s->type = FTYPE_FILE;
 

On Fri, 1 Feb 2013, Vasiliy Tolstov wrote:
> Failed again.
> may be in xenstore.c in this code i need to delete O_DIRECT flag?
> 
> In strace before i get messages about fallback without O_DIRECT
> (provided with patch) i get this:
> 
> write(2, "Using file /var/storage/iso/SW_D"..., 130) = 130
> open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
> O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
> write(2, "qemu: could not open vbd '/local"..., 216) = 216
> 
> My be in this code i append fallback?
> 
>             if (bdrv_open2(bs, params, flags|BDRV_O_CACHE_WB /*
> snapshot and write-back */, format) < 0) {
>                 fprintf(stderr, "qemu: could not open vbd '%s' or hard
> disk image '%s' (drv '%s' format '%s')\n", buf, params, drv ? drv :
> "?", format ? format->format_name : "0");
>             } else {
>                 char* snapshot = get_snapshot_name(atoi(e_danger[i]));
>                 if (snapshot) {
>                     fprintf(stderr, "Using snapshot %s\n", snapshot);
>                     ret = bdrv_snapshot_goto(bs, snapshot);
>                     switch (ret) {
>                     case 0:
>                         /* Success */
>                         break;
>                     case -ENOTSUP:
>                         /* Don't abort here (could be read-only ISO) */
>                         fprintf(stderr, "Snapshots are not supported for "
>                             "this image file format\n");
>                         break;
>                     case -ENOENT:
>                         fprintf(stderr, "No such snapshot, skipping this "
>                             "image file\n");
>                         continue;
>                     default:
>                         fprintf(stderr, "Could not load snapshot, skipping"
>                             " this image file\n");
>                         continue;
>                     }
>                 }
>             }
> 
> 2013/1/30 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> > Sorry that was my stupid mistake.
> > This should work:
> >
> > diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > index 33a5531..1786db8 100644
> > --- a/hw/xen_disk.c
> > +++ b/hw/xen_disk.c
> > @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
> >         if (blkdev->bs) {
> >             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> >                             bdrv_find_format(blkdev->fileproto)) != 0) {
> > -               bdrv_delete(blkdev->bs);
> > -               blkdev->bs = NULL;
> > -           }
> > +                /* try without O_DIRECT */
> > +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
> > +                        blkdev->filename);
> > +                qflags &= ~BDRV_O_NOCACHE;
> > +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> > +                            bdrv_find_format(blkdev->fileproto)) != 0) {
> > +                    bdrv_delete(blkdev->bs);
> > +                    blkdev->bs = NULL;
> > +                }
> > +            }
> >         }
> >         if (!blkdev->bs)
> >             return -1;
> >
> > On Wed, 30 Jan 2013, Vasiliy Tolstov wrote:
> >> Strace shows that qemu after O_DIRECT next try with O_DIRECT
> >> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
> >> EINVAL (Invalid argument)
> >> write(2, "xen be: qdisk-832: ", 19)     = 19
> >> write(2, "xen be: qdisk-832: ", 19)     = 19
> >> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
> >> write(2, "opening /var/storage/iso/winpe_a"..., 85) = 85
> >> open("/var/storage/iso/winpe_amd64.iso", O_RDONLY|O_DIRECT) = -1
> >> EINVAL (Invalid argument)
> >>
> >> 2013/1/30 Vasiliy Tolstov <v.tolstov@selfip.ru>:
> >> > Thanks for patch. But it not solve problem:
> >> > Now i have :
> >> > domid: 6
> >> > Using file /dev/disk/vbd/21-828 in read-write mode
> >> > Strip off blktap sub-type prefix to  (drv 'aio')
> >> > Watching /local/domain/0/device-model/6/logdirty/cmd
> >> > Watching /local/domain/0/device-model/6/command
> >> > Watching /local/domain/6/cpu
> >> > char device redirected to /dev/pts/5
> >> > qemu_map_cache_init nr_buckets = 10000 size 4194304
> >> > Could not open /var/run/tap/qemu-read-6
> >> > shared page at pfn feffd
> >> > buffered io page at pfn feffb
> >> > Guest uuid = c98c33c8-1891-41ec-96a0-984f3df80def
> >> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
> >> > trying write-through.
> >> > opening  with O_DIRECT failed, trying write-through.
> >> > 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/6/xen_extended_power_mgmt): read error
> >> > medium change watch on `hdc' (index: 1): aio:
> >> > 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
> >> > vcpu-set: watch node error.
> >> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> >> > xs_read(/local/domain/6/log-throttling): read error
> >> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
> >> > medium change watch on `/local/domain/6/log-throttling' - unknown
> >> > device, ignored
> >> > xen be: qdisk-5632: xen be: qdisk-5632: opening  with O_DIRECT failed,
> >> > trying write-through.
> >> > opening  with O_DIRECT failed, trying write-through.
> >> > log_throttling disabled
> >> > qemu: ignoring not-understood drive `/local/domain/6/log-throttling'
> >> > medium change watch on `/local/domain/6/log-throttling' - unknown
> >> > device, ignored
> >> > vga s->lfb_addr = f0000000 s->lfb_end = f1000000
> >> > 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.
> >> >
> >> >
> >> > (XEN) HVM6: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> >> > (XEN) HVM6: VBE Bios $Id: vbe.c,v 1.60 2008/03/02 07:47:21 vruppert Exp $
> >> > (XEN) HVM6: Bochs BIOS - build: 06/23/99
> >> > (XEN) HVM6: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> >> > (XEN) HVM6: Options: apmbios pcibios eltorito PMM
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> >> > (XEN) HVM6: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10246 MBytes)
> >> > (XEN) HVM6: IDE time out
> >> > (XEN) HVM6: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
> >> > (XEN) HVM6: IDE time out
> >> > (XEN) HVM6:
> >> > (XEN) HVM6:
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: Press F12 for boot menu.
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: Booting from Hard Disk...
> >> > (XEN) HVM6: Boot from Hard Disk failed: not a bootable disk
> >> > (XEN) HVM6:
> >> > (XEN) HVM6:
> >> > (XEN) HVM6: No bootable device.
> >> > (XEN) HVM6: Powering off in 30 seconds.
> >> > (XEN) hvm.c:1080:d6 All CPUs offline -- powering off.
> >> >
> >> > 2013/1/22 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> >> >> On Tue, 22 Jan 2013, Ian Campbell wrote:
> >> >>> Please don't top post.
> >> >>>
> >> >>> On Tue, 2013-01-22 at 05:38 +0000, Vasiliy Tolstov wrote:
> >> >>> > Thanks!
> >> >>> > I found, that now xl tries to open iso with O_DIRECT flag.
> >> >>> > open("/var/storage/iso/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_Russian_w_SP1_MLF_X17-22616_vase.iso",
> >> >>> > O_RDONLY|O_DIRECT) = -1 EINVAL (Invalid argument)
> >> >>> > write(2, "qemu: could not open vbd '/local"..., 217) = 217
> >> >>
> >> >> xl? I guess you mean QEMU tries to open the ISO with O_DIRECT.
> >> >>
> >> >>
> >> >>> I guess CIFS doesn't support O_DIRECT. It looks like it does have mount
> >> >>> -o directio though, worth a try.
> >> >>>
> >> >>> I'm not sure what options exist to turn this off from the qemu side --
> >> >>> Stefano? I also have a feeling something changed in this regard in 4.2.x
> >> >>
> >> >> Given that you are not passing any device_model_version option to xl, I
> >> >> assume that you are running qemu-xen-traditional (ps should show that a
> >> >> binary called qemu-dm is running).
> >> >>
> >> >> If that is the case, there is currently no way to specify any flags.
> >> >> However the interesting bit is that qemu-xen-traditional opens files
> >> >> corresponding to emulated devices with BDRV_O_CACHE_WB and opens files
> >> >> corresponding to PV interfaces using BDRV_O_NOCACHE (this means
> >> >> O_DIRECT).
> >> >> This means that the failure should be caused by hw/xen_disk.c trying to
> >> >> opening the iso O_DIRECT. Paradoxically the PV inteface for a cdrom
> >> >> drive is usually never used AFAIK.
> >> >>
> >> >> Did the Windows PV drivers start using the PV cdrom interface all of a
> >> >> sudden?
> >> >>
> >> >> In any case I think that the best thing we could do it fall back to
> >> >> write-through (or should it be write-back? It might not be safe..) in
> >> >> case O_DIRECT fails. This is what qemu-xen does in such cases.
> >> >>
> >> >> Try this patch:
> >> >>
> >> >> ---
> >> >>
> >> >> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >> >> index 33a5531..d6d71fe 100644
> >> >> --- a/hw/xen_disk.c
> >> >> +++ b/hw/xen_disk.c
> >> >> @@ -659,9 +659,16 @@ static int blk_init(struct XenDevice *xendev)
> >> >>         if (blkdev->bs) {
> >> >>             if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> >> >>                             bdrv_find_format(blkdev->fileproto)) != 0) {
> >> >> -               bdrv_delete(blkdev->bs);
> >> >> -               blkdev->bs = NULL;
> >> >> -           }
> >> >> +                /* try without O_DIRECT */
> >> >> +                xen_be_printf(&blkdev->xendev, 0, "opening %s with O_DIRECT failed, trying write-through.\n",
> >> >> +                        blkdev->filename);
> >> >> +                qflags &= BDRV_O_NOCACHE;
> >> >> +                if (bdrv_open2(blkdev->bs, blkdev->filename, qflags,
> >> >> +                            bdrv_find_format(blkdev->fileproto)) != 0) {
> >> >> +                    bdrv_delete(blkdev->bs);
> >> >> +                    blkdev->bs = NULL;
> >> >> +                }
> >> >> +            }
> >> >>         }
> >> >>         if (!blkdev->bs)
> >> >>             return -1;
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Vasiliy Tolstov,
> >> > Clodo.ru
> >> > e-mail: v.tolstov@selfip.ru
> >> > jabber: vase@selfip.ru
> >>
> >>
> >>
> >> --
> >> Vasiliy Tolstov,
> >> Clodo.ru
> >> e-mail: v.tolstov@selfip.ru
> >> jabber: vase@selfip.ru
> >>
> 
> 
> 
> --
> 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 Feb 08 16:22:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3qhw-00029M-Ob; Fri, 08 Feb 2013 16:21: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 1U3qhv-00029H-Dk
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 16:21:47 +0000
Received: from [85.158.137.99:24738] by server-3.bemta-3.messagelabs.com id
	7C/92-31070-A1625115; Fri, 08 Feb 2013 16:21:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360340504!18291267!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31847 invoked from network); 8 Feb 2013 16:21:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:21:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6824850"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 16:21:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 11:21:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3qhr-0004Lh-9I;
	Fri, 08 Feb 2013 16:21:43 +0000
Date: Fri, 8 Feb 2013 16:21:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fabio.fantoni@heliman.it>
In-Reply-To: <510903EF.5020004@heliman.it>
Message-ID: <alpine.DEB.2.02.1302081611190.4275@kaball.uk.xensource.com>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<CAFLBxZaV9VbVvMUwp_QWEfvJUA78qtbceKiD-ayES78j5tmivA@mail.gmail.com>
	<510903EF.5020004@heliman.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: George Dunlap <dunlapg@umich.edu>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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 Wed, 30 Jan 2013, Fabio Fantoni wrote:
> I done other test with qemu upstream, on restore of Windows 7 pro 64 bit 
> domU with latest gplpv give these lines on logs:
> 
> xen_ram_alloc: do not alloc 7f800000 bytes of ram at 0 when runstate is 
> INMIGRATE
> xen_ram_alloc: do not alloc 800000 bytes of ram at 7f800000 when 
> runstate is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 80000000 when runstate 
> is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 80010000 when runstate 
> is INMIGRATE
> 
> All seem working except network (seem more gplpv problem already 
> reported on other post), about this ram logs (first is very strange).
> Is it normal or maybe some bugs around?

Those messages are normal: RAM is already allocated at restore time.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:22:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3qhw-00029M-Ob; Fri, 08 Feb 2013 16:21: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 1U3qhv-00029H-Dk
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 16:21:47 +0000
Received: from [85.158.137.99:24738] by server-3.bemta-3.messagelabs.com id
	7C/92-31070-A1625115; Fri, 08 Feb 2013 16:21:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360340504!18291267!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31847 invoked from network); 8 Feb 2013 16:21:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:21:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6824850"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 16:21:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 11:21:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U3qhr-0004Lh-9I;
	Fri, 08 Feb 2013 16:21:43 +0000
Date: Fri, 8 Feb 2013 16:21:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Fabio Fantoni <fabio.fantoni@heliman.it>
In-Reply-To: <510903EF.5020004@heliman.it>
Message-ID: <alpine.DEB.2.02.1302081611190.4275@kaball.uk.xensource.com>
References: <50F91A25.5080408@heliman.it>
	<alpine.DEB.2.02.1301181245360.4978@kaball.uk.xensource.com>
	<50F95FE9.2030104@heliman.it>
	<CAFLBxZaV9VbVvMUwp_QWEfvJUA78qtbceKiD-ayES78j5tmivA@mail.gmail.com>
	<510903EF.5020004@heliman.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: George Dunlap <dunlapg@umich.edu>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Qemu upstream bugs with 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 Wed, 30 Jan 2013, Fabio Fantoni wrote:
> I done other test with qemu upstream, on restore of Windows 7 pro 64 bit 
> domU with latest gplpv give these lines on logs:
> 
> xen_ram_alloc: do not alloc 7f800000 bytes of ram at 0 when runstate is 
> INMIGRATE
> xen_ram_alloc: do not alloc 800000 bytes of ram at 7f800000 when 
> runstate is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 80000000 when runstate 
> is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 80010000 when runstate 
> is INMIGRATE
> 
> All seem working except network (seem more gplpv problem already 
> reported on other post), about this ram logs (first is very strange).
> Is it normal or maybe some bugs around?

Those messages are normal: RAM is already allocated at restore time.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:23:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:23: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 1U3qj9-0002D2-8L; Fri, 08 Feb 2013 16:23: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 1U3qj7-0002Ct-0u
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:23:01 +0000
Received: from [85.158.139.211:16010] by server-15.bemta-5.messagelabs.com id
	85/CA-18914-46625115; Fri, 08 Feb 2013 16:23:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360340576!20646890!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15267 invoked from network); 8 Feb 2013 16:22:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:22:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1288672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:22: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.297.1; Fri, 8 Feb 2013
	16:22:56 +0000
Message-ID: <1360340574.29432.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 8 Feb 2013 16:22:54 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:06 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: 07 February 2013 11:58
> > To: Paul Durrant
> > Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> > jbeulich@suse.com; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> > 
> > On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > [snip]
> > > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > > sizeof(unsigned long) * 64)
> > > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > > +sizeof(unsigned long) * 64)
> > > > > >
> > > > > > We did a bit of header change to make the ARM code always use
> > > > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t
> > > > > > and
> > > > xen_mfn_t typdefs.
> > > > > >
> > > > > > Any chance you can do that here? That way on ARM - irregardless
> > > > > > if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > > >
> > > > >
> > > > > I don't think so. The reason to use unsigned long here is to
> > > > > guarantee each selector (in 2-level case there is only L1
> > > > > selector) fits into a word.
> > > >
> > >
> > > That's still going to be a problem with Windows drivers. Unfortunately
> > MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is
> > word size is a pointer. Any chance we can use uintptr_t rather than an
> > unsigned long? (At the moment I have to sed all the public headers to
> > replace long with LONG_PTR and it's a PITA).
> > >
> > 
> > TBH I don't know much about Windows. But are you suggesting replace all
> > the relevant bit in the header or just the specific event channel interface?
> > 
> 
> I was just pointing out that assumption that unsigned long == native
> word size does not hold for 64-bit Windows. So, if we're adding
> something new can we avoid use of unsigned long and use an abstract
> type defined to be the native word size?

Probably ought to be the existing xen_ulong_t.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:23:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:23: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 1U3qj9-0002D2-8L; Fri, 08 Feb 2013 16:23: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 1U3qj7-0002Ct-0u
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:23:01 +0000
Received: from [85.158.139.211:16010] by server-15.bemta-5.messagelabs.com id
	85/CA-18914-46625115; Fri, 08 Feb 2013 16:23:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360340576!20646890!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15267 invoked from network); 8 Feb 2013 16:22:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:22:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1288672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:22: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.297.1; Fri, 8 Feb 2013
	16:22:56 +0000
Message-ID: <1360340574.29432.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 8 Feb 2013 16:22:54 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:06 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: 07 February 2013 11:58
> > To: Paul Durrant
> > Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> > jbeulich@suse.com; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> > 
> > On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > [snip]
> > > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > > sizeof(unsigned long) * 64)
> > > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > > +sizeof(unsigned long) * 64)
> > > > > >
> > > > > > We did a bit of header change to make the ARM code always use
> > > > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t
> > > > > > and
> > > > xen_mfn_t typdefs.
> > > > > >
> > > > > > Any chance you can do that here? That way on ARM - irregardless
> > > > > > if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > > >
> > > > >
> > > > > I don't think so. The reason to use unsigned long here is to
> > > > > guarantee each selector (in 2-level case there is only L1
> > > > > selector) fits into a word.
> > > >
> > >
> > > That's still going to be a problem with Windows drivers. Unfortunately
> > MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is
> > word size is a pointer. Any chance we can use uintptr_t rather than an
> > unsigned long? (At the moment I have to sed all the public headers to
> > replace long with LONG_PTR and it's a PITA).
> > >
> > 
> > TBH I don't know much about Windows. But are you suggesting replace all
> > the relevant bit in the header or just the specific event channel interface?
> > 
> 
> I was just pointing out that assumption that unsigned long == native
> word size does not hold for 64-bit Windows. So, if we're adding
> something new can we avoid use of unsigned long and use an abstract
> type defined to be the native word size?

Probably ought to be the existing xen_ulong_t.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:36:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:36: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 1U3qvm-0002iV-KG; Fri, 08 Feb 2013 16:36:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3qvl-0002iQ-3V
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:36:05 +0000
Received: from [193.109.254.147:59932] by server-3.bemta-14.messagelabs.com id
	7A/64-22141-47925115; Fri, 08 Feb 2013 16:36:04 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360341362!9282010!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27889 invoked from network); 8 Feb 2013 16:36:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:36:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289119"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:36:01 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 8 Feb 2013
	16:36:00 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 8 Feb 2013 16:36:38 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4GGI2cl/PcHUeERoKfw60L4tD/lgAAZexA
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360340574.29432.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.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
> From: Ian Campbell
> Sent: 08 February 2013 16:23
> To: Paul Durrant
> Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; jbeulich@suse.com; xen-
> devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> 
> On Fri, 2013-02-08 at 16:06 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: 07 February 2013 11:58
> > > To: Paul Durrant
> > > Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> > > jbeulich@suse.com; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> > >
> > > On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > [snip]
> > > > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > > > sizeof(unsigned long) * 64)
> > > > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > > > +sizeof(unsigned long) * 64)
> > > > > > >
> > > > > > > We did a bit of header change to make the ARM code always
> > > > > > > use 'unsinged long long' on 32-bit (so it is a nice 8-bytes)
> > > > > > > and 'unsigned long' on 64-bit. This was all done using the
> > > > > > > xen_pfn_t and
> > > > > xen_mfn_t typdefs.
> > > > > > >
> > > > > > > Any chance you can do that here? That way on ARM -
> > > > > > > irregardless if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > > > >
> > > > > >
> > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > selector) fits into a word.
> > > > >
> > > >
> > > > That's still going to be a problem with Windows drivers.
> > > > Unfortunately
> > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > thing that is word size is a pointer. Any chance we can use
> > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > >
> > >
> > > TBH I don't know much about Windows. But are you suggesting replace
> > > all the relevant bit in the header or just the specific event channel
> interface?
> > >
> >
> > I was just pointing out that assumption that unsigned long == native
> > word size does not hold for 64-bit Windows. So, if we're adding
> > something new can we avoid use of unsigned long and use an abstract
> > type defined to be the native word size?
> 
> Probably ought to be the existing xen_ulong_t.
> 

That works for me :-)

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:36:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:36: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 1U3qvm-0002iV-KG; Fri, 08 Feb 2013 16:36:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3qvl-0002iQ-3V
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:36:05 +0000
Received: from [193.109.254.147:59932] by server-3.bemta-14.messagelabs.com id
	7A/64-22141-47925115; Fri, 08 Feb 2013 16:36:04 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360341362!9282010!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27889 invoked from network); 8 Feb 2013 16:36:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:36:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289119"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:36:01 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 8 Feb 2013
	16:36:00 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 8 Feb 2013 16:36:38 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4GGI2cl/PcHUeERoKfw60L4tD/lgAAZexA
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360340574.29432.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.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
> From: Ian Campbell
> Sent: 08 February 2013 16:23
> To: Paul Durrant
> Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; jbeulich@suse.com; xen-
> devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> 
> On Fri, 2013-02-08 at 16:06 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: 07 February 2013 11:58
> > > To: Paul Durrant
> > > Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> > > jbeulich@suse.com; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> > >
> > > On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > [snip]
> > > > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > > > sizeof(unsigned long) * 64)
> > > > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > > > +sizeof(unsigned long) * 64)
> > > > > > >
> > > > > > > We did a bit of header change to make the ARM code always
> > > > > > > use 'unsinged long long' on 32-bit (so it is a nice 8-bytes)
> > > > > > > and 'unsigned long' on 64-bit. This was all done using the
> > > > > > > xen_pfn_t and
> > > > > xen_mfn_t typdefs.
> > > > > > >
> > > > > > > Any chance you can do that here? That way on ARM -
> > > > > > > irregardless if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > > > >
> > > > > >
> > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > selector) fits into a word.
> > > > >
> > > >
> > > > That's still going to be a problem with Windows drivers.
> > > > Unfortunately
> > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > thing that is word size is a pointer. Any chance we can use
> > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > >
> > >
> > > TBH I don't know much about Windows. But are you suggesting replace
> > > all the relevant bit in the header or just the specific event channel
> interface?
> > >
> >
> > I was just pointing out that assumption that unsigned long == native
> > word size does not hold for 64-bit Windows. So, if we're adding
> > something new can we avoid use of unsigned long and use an abstract
> > type defined to be the native word size?
> 
> Probably ought to be the existing xen_ulong_t.
> 

That works for me :-)

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:38: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 1U3qxi-0002mU-4r; Fri, 08 Feb 2013 16:38:06 +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 1U3qxg-0002mL-D0
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:38:04 +0000
Received: from [85.158.143.99:29198] by server-1.bemta-4.messagelabs.com id
	EB/AD-08839-BE925115; Fri, 08 Feb 2013 16:38:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360341472!27926858!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7342 invoked from network); 8 Feb 2013 16:37:54 -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;
	8 Feb 2013 16:37:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6827490"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 16:37:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 11:37:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U3qxT-0004cP-CS;
	Fri, 08 Feb 2013 16:37:51 +0000
Message-ID: <1360341471.16636.14.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 8 Feb 2013 16:37:51 +0000
In-Reply-To: <1360340574.29432.70.camel@zakaz.uk.xensource.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:22 +0000, Ian Campbell wrote:
> On Fri, 2013-02-08 at 16:06 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: 07 February 2013 11:58
> > > To: Paul Durrant
> > > Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> > > jbeulich@suse.com; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> > > 
> > > On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > [snip]
> > > > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > > > sizeof(unsigned long) * 64)
> > > > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > > > +sizeof(unsigned long) * 64)
> > > > > > >
> > > > > > > We did a bit of header change to make the ARM code always use
> > > > > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t
> > > > > > > and
> > > > > xen_mfn_t typdefs.
> > > > > > >
> > > > > > > Any chance you can do that here? That way on ARM - irregardless
> > > > > > > if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > > > >
> > > > > >
> > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > selector) fits into a word.
> > > > >
> > > >
> > > > That's still going to be a problem with Windows drivers. Unfortunately
> > > MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is
> > > word size is a pointer. Any chance we can use uintptr_t rather than an
> > > unsigned long? (At the moment I have to sed all the public headers to
> > > replace long with LONG_PTR and it's a PITA).
> > > >
> > > 
> > > TBH I don't know much about Windows. But are you suggesting replace all
> > > the relevant bit in the header or just the specific event channel interface?
> > > 
> > 
> > I was just pointing out that assumption that unsigned long == native
> > word size does not hold for 64-bit Windows. So, if we're adding
> > something new can we avoid use of unsigned long and use an abstract
> > type defined to be the native word size?
> 
> Probably ought to be the existing xen_ulong_t.

AFAICT there is no typedef for xen_ulong_t in Linux, we need to add it
manually then.


Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:38: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 1U3qxi-0002mU-4r; Fri, 08 Feb 2013 16:38:06 +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 1U3qxg-0002mL-D0
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:38:04 +0000
Received: from [85.158.143.99:29198] by server-1.bemta-4.messagelabs.com id
	EB/AD-08839-BE925115; Fri, 08 Feb 2013 16:38:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360341472!27926858!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc1MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7342 invoked from network); 8 Feb 2013 16:37:54 -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;
	8 Feb 2013 16:37:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6827490"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 16:37:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 8 Feb 2013 11:37:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U3qxT-0004cP-CS;
	Fri, 08 Feb 2013 16:37:51 +0000
Message-ID: <1360341471.16636.14.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 8 Feb 2013 16:37:51 +0000
In-Reply-To: <1360340574.29432.70.camel@zakaz.uk.xensource.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:22 +0000, Ian Campbell wrote:
> On Fri, 2013-02-08 at 16:06 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: 07 February 2013 11:58
> > > To: Paul Durrant
> > > Cc: Wei Liu; Konrad Rzeszutek Wilk; David Vrabel; Ian Campbell;
> > > jbeulich@suse.com; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> > > 
> > > On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > [snip]
> > > > > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > > > > sizeof(unsigned long) * 64)
> > > > > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > > > > +sizeof(unsigned long) * 64)
> > > > > > >
> > > > > > > We did a bit of header change to make the ARM code always use
> > > > > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t
> > > > > > > and
> > > > > xen_mfn_t typdefs.
> > > > > > >
> > > > > > > Any chance you can do that here? That way on ARM - irregardless
> > > > > > > if it is 32-bit or 64-bit it is always of the 64-bit size?
> > > > > > >
> > > > > >
> > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > selector) fits into a word.
> > > > >
> > > >
> > > > That's still going to be a problem with Windows drivers. Unfortunately
> > > MSVC uses a 64-bit model where longs are still 32-bit. The only thing that is
> > > word size is a pointer. Any chance we can use uintptr_t rather than an
> > > unsigned long? (At the moment I have to sed all the public headers to
> > > replace long with LONG_PTR and it's a PITA).
> > > >
> > > 
> > > TBH I don't know much about Windows. But are you suggesting replace all
> > > the relevant bit in the header or just the specific event channel interface?
> > > 
> > 
> > I was just pointing out that assumption that unsigned long == native
> > word size does not hold for 64-bit Windows. So, if we're adding
> > something new can we avoid use of unsigned long and use an abstract
> > type defined to be the native word size?
> 
> Probably ought to be the existing xen_ulong_t.

AFAICT there is no typedef for xen_ulong_t in Linux, we need to add it
manually then.


Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:41:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:41: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 1U3r0j-0002yv-On; Fri, 08 Feb 2013 16:41: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 1U3r0i-0002yn-06
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:41:12 +0000
Received: from [85.158.143.99:9782] by server-2.bemta-4.messagelabs.com id
	02/27-01597-7AA25115; Fri, 08 Feb 2013 16:41:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360341670!25073637!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24760 invoked from network); 8 Feb 2013 16:41:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:41:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:40: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.297.1; Fri, 8 Feb 2013
	16:40:50 +0000
Message-ID: <1360341648.29432.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 8 Feb 2013 16:40:48 +0000
In-Reply-To: <1360341471.16636.14.camel@zion.uk.xensource.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<1360341471.16636.14.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:37 +0000, Wei Liu wrote:
> AFAICT there is no typedef for xen_ulong_t in Linux, we need to add it
> manually then.

There is from ~3.7 onwards, since we had to add it for ARM (where for
ABI reason xen_ulong_t is 8 bytes, not 4 like unsigned long).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:41:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:41: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 1U3r0j-0002yv-On; Fri, 08 Feb 2013 16:41: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 1U3r0i-0002yn-06
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:41:12 +0000
Received: from [85.158.143.99:9782] by server-2.bemta-4.messagelabs.com id
	02/27-01597-7AA25115; Fri, 08 Feb 2013 16:41:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360341670!25073637!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24760 invoked from network); 8 Feb 2013 16:41:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:41:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:40: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.297.1; Fri, 8 Feb 2013
	16:40:50 +0000
Message-ID: <1360341648.29432.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 8 Feb 2013 16:40:48 +0000
In-Reply-To: <1360341471.16636.14.camel@zion.uk.xensource.com>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<1360341471.16636.14.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:37 +0000, Wei Liu wrote:
> AFAICT there is no typedef for xen_ulong_t in Linux, we need to add it
> manually then.

There is from ~3.7 onwards, since we had to add it for ARM (where for
ABI reason xen_ulong_t is 8 bytes, not 4 like unsigned long).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:45:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:45: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 1U3r4m-0003Ot-Ei; Fri, 08 Feb 2013 16:45: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 1U3r4l-0003Om-1j
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:45:23 +0000
Received: from [85.158.139.83:50329] by server-1.bemta-5.messagelabs.com id
	4B/D8-29263-2AB25115; Fri, 08 Feb 2013 16:45:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360341917!28356647!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32306 invoked from network); 8 Feb 2013 16:45:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:45: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.297.1; Fri, 8 Feb 2013
	16:45:17 +0000
Message-ID: <1360341915.29432.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 8 Feb 2013 16:45:15 +0000
In-Reply-To: <1360254812.32479.90.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
	<20130207163036.GO77133@ocelot.phlegethon.org>
	<1360254812.32479.90.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 13/45] xen: arm64: dcache 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

On Thu, 2013-02-07 at 16:33 +0000, Ian Campbell wrote:
> On Thu, 2013-02-07 at 16:30 +0000, Tim Deegan wrote:
> > At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> > > On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > > > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > > > This drops the
> > > > >     "m" (*_p)
> > > > > asm contraint. I can't figure out what this was for.
> > > > > 
> > > > 
> > > > It's to stop the compiler hoisting writes to the wrong side of the
> > > > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > > > the range version.  By moving from inline "dsb;" to dsb() you've
> > > > reintroduced the full memory clobber here anyway. :(
> > > 
> > > Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> > > 
> > > How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> > > for cases such as this?
> > 
> > Maybe.  The profusion of undersocre-prefixed operations is staring to
> > confuse me, though.
> 
> Ack.
> 
> > > I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> > > form is valid. The reason I didn't err on the side of just adding the
> > > "sy" was that often there is something else which differs between the
> > > two in the same asm inline block and so using the macro throughout
> > > seemed cleaner. Perhaps I should rethink this.
> > 
> > I see.  So maybe we could just switch to using 'dsb sy' in
> > flush_xen_dcache() and just macro up the one line of inline asm that
> > expands to STORE_CP32(0, DCCMVAC) ?
> 
> Actually, yes, I subsequently to make this change invented
> READ/WRITE_SYSREG to abstract this stuff away -- I should extend that to
> inline ASM too.

Actually, sysreg is not a useful concept here because cache flushes
under arm64 are actual instructions (at least mnemonically in the
assembler). So "STORE_CP32(0, DCCMVAC)" on 32-bit becomes "dc cvac, %0;"
on 64-bit.

I came up with the below (which I think is basically what you suggested)

Ian.

8<---------------------------------

>From 7ea401f56956261ac6af22d70f61b2c059280a4e Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 10 Dec 2012 16:08:59 +0000
Subject: [PATCH] xen: arm64: dcache flush

Use "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.

Abstract the actual flush operation into a macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: revert to inline asm
---
 xen/include/asm-arm/arm32/page.h |    3 +++
 xen/include/asm-arm/arm64/page.h |    3 +++
 xen/include/asm-arm/page.h       |    8 ++++----
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 96b5798..45d25ee 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index ce5be63..1d7c70e 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 4e245a9..b89238b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
     void *end;
     dsb();           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
-        WRITE_CP32((uint32_t) p, DCCMVAC);
+        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
     dsb();           /* So we know the flushes happen before continuing */
 }
 
@@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
         flush_xen_dcache_va_range(_p, sizeof(x));                       \
     else                                                                \
         asm volatile (                                                  \
-            "dsb;"   /* Finish all earlier writes */                    \
-            STORE_CP32(0, DCCMVAC)                                      \
-            "dsb;"   /* Finish flush before continuing */               \
+            "dsb sy;"   /* Finish all earlier writes */                 \
+            __flush_xen_dcache_one(0)                                   \
+            "dsb sy;"   /* Finish flush before continuing */            \
             : : "r" (_p), "m" (*_p));                                   \
 } while (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 Feb 08 16:45:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:45: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 1U3r4m-0003Ot-Ei; Fri, 08 Feb 2013 16:45: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 1U3r4l-0003Om-1j
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:45:23 +0000
Received: from [85.158.139.83:50329] by server-1.bemta-5.messagelabs.com id
	4B/D8-29263-2AB25115; Fri, 08 Feb 2013 16:45:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360341917!28356647!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32306 invoked from network); 8 Feb 2013 16:45:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:45: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.297.1; Fri, 8 Feb 2013
	16:45:17 +0000
Message-ID: <1360341915.29432.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 8 Feb 2013 16:45:15 +0000
In-Reply-To: <1360254812.32479.90.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
	<20130207163036.GO77133@ocelot.phlegethon.org>
	<1360254812.32479.90.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 13/45] xen: arm64: dcache 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

On Thu, 2013-02-07 at 16:33 +0000, Ian Campbell wrote:
> On Thu, 2013-02-07 at 16:30 +0000, Tim Deegan wrote:
> > At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> > > On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > > > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > > > This drops the
> > > > >     "m" (*_p)
> > > > > asm contraint. I can't figure out what this was for.
> > > > > 
> > > > 
> > > > It's to stop the compiler hoisting writes to the wrong side of the
> > > > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > > > the range version.  By moving from inline "dsb;" to dsb() you've
> > > > reintroduced the full memory clobber here anyway. :(
> > > 
> > > Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> > > 
> > > How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> > > for cases such as this?
> > 
> > Maybe.  The profusion of undersocre-prefixed operations is staring to
> > confuse me, though.
> 
> Ack.
> 
> > > I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> > > form is valid. The reason I didn't err on the side of just adding the
> > > "sy" was that often there is something else which differs between the
> > > two in the same asm inline block and so using the macro throughout
> > > seemed cleaner. Perhaps I should rethink this.
> > 
> > I see.  So maybe we could just switch to using 'dsb sy' in
> > flush_xen_dcache() and just macro up the one line of inline asm that
> > expands to STORE_CP32(0, DCCMVAC) ?
> 
> Actually, yes, I subsequently to make this change invented
> READ/WRITE_SYSREG to abstract this stuff away -- I should extend that to
> inline ASM too.

Actually, sysreg is not a useful concept here because cache flushes
under arm64 are actual instructions (at least mnemonically in the
assembler). So "STORE_CP32(0, DCCMVAC)" on 32-bit becomes "dc cvac, %0;"
on 64-bit.

I came up with the below (which I think is basically what you suggested)

Ian.

8<---------------------------------

>From 7ea401f56956261ac6af22d70f61b2c059280a4e Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 10 Dec 2012 16:08:59 +0000
Subject: [PATCH] xen: arm64: dcache flush

Use "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.

Abstract the actual flush operation into a macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: revert to inline asm
---
 xen/include/asm-arm/arm32/page.h |    3 +++
 xen/include/asm-arm/arm64/page.h |    3 +++
 xen/include/asm-arm/page.h       |    8 ++++----
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 96b5798..45d25ee 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index ce5be63..1d7c70e 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 4e245a9..b89238b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
     void *end;
     dsb();           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
-        WRITE_CP32((uint32_t) p, DCCMVAC);
+        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
     dsb();           /* So we know the flushes happen before continuing */
 }
 
@@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
         flush_xen_dcache_va_range(_p, sizeof(x));                       \
     else                                                                \
         asm volatile (                                                  \
-            "dsb;"   /* Finish all earlier writes */                    \
-            STORE_CP32(0, DCCMVAC)                                      \
-            "dsb;"   /* Finish flush before continuing */               \
+            "dsb sy;"   /* Finish all earlier writes */                 \
+            __flush_xen_dcache_one(0)                                   \
+            "dsb sy;"   /* Finish flush before continuing */            \
             : : "r" (_p), "m" (*_p));                                   \
 } while (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 Feb 08 16:49:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:49: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 1U3r7z-0003XL-9K; Fri, 08 Feb 2013 16:48: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 1U3r7x-0003XG-TU
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:48:42 +0000
Received: from [85.158.137.99:2405] by server-3.bemta-3.messagelabs.com id
	3F/87-31070-96C25115; Fri, 08 Feb 2013 16:48:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360342120!17428040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31211 invoked from network); 8 Feb 2013 16:48:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:48:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:48:39 +0000
Message-Id: <51153A7902000078000BD48B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:48:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
In-Reply-To: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, xiantao.zhang@intel.com,
	suravee.suthikulpanit@amd.com, sherry.hurwitz@amd.com
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:

> ----- JBeulich@suse.com wrote:
> 
>> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
>> > A regression was reported on a class of broken firmware that c/s
>> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
>> 
>> After some more thought on this and the comments we got
>> regarding disabling the IOMMU in this situation altogether making
>> things worse instead of better, I came to the conclusion that we
>> can actually restrict the action in affected cases to just disabling
>> interrupt remapping. That doesn't make the situation worse than
>> prior to the XSA-36 fixes (where interrupt remapping didn't really
>> protect domains from one another), but allows at least DMA
>> isolation to still be utilized. Patch 3/2 below/attached.
> 
> But now users who don't examine log messages may not realize 
> that interupt remapping is disabled and therefore the system can be
> affected by XSA-36.

Yes. We need to balance these against one another - I see pros
and cons in both (and I don't mind dropping this additional patch
if we collectively come to the conclusion that the way it is now -
with the one earlier fix - is the better state). So I'm really
interested in others' opinions.

> With current code (boot option to use global remapping table) users
> are explicitly agreeing to allow for possibility of cross-domain interrupt
> attack.
> 
> Also, I think it may not be a bad idea to have AMD folks test you earlier
> patch on multi-IOMMU system (and simulate bad IVRS) to see how it behaves 
> there.

That would indeed be very desirable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:49:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:49: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 1U3r7z-0003XL-9K; Fri, 08 Feb 2013 16:48: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 1U3r7x-0003XG-TU
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:48:42 +0000
Received: from [85.158.137.99:2405] by server-3.bemta-3.messagelabs.com id
	3F/87-31070-96C25115; Fri, 08 Feb 2013 16:48:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360342120!17428040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31211 invoked from network); 8 Feb 2013 16:48:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:48:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:48:39 +0000
Message-Id: <51153A7902000078000BD48B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:48:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
In-Reply-To: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, xiantao.zhang@intel.com,
	suravee.suthikulpanit@amd.com, sherry.hurwitz@amd.com
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:

> ----- JBeulich@suse.com wrote:
> 
>> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
>> > A regression was reported on a class of broken firmware that c/s
>> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
>> 
>> After some more thought on this and the comments we got
>> regarding disabling the IOMMU in this situation altogether making
>> things worse instead of better, I came to the conclusion that we
>> can actually restrict the action in affected cases to just disabling
>> interrupt remapping. That doesn't make the situation worse than
>> prior to the XSA-36 fixes (where interrupt remapping didn't really
>> protect domains from one another), but allows at least DMA
>> isolation to still be utilized. Patch 3/2 below/attached.
> 
> But now users who don't examine log messages may not realize 
> that interupt remapping is disabled and therefore the system can be
> affected by XSA-36.

Yes. We need to balance these against one another - I see pros
and cons in both (and I don't mind dropping this additional patch
if we collectively come to the conclusion that the way it is now -
with the one earlier fix - is the better state). So I'm really
interested in others' opinions.

> With current code (boot option to use global remapping table) users
> are explicitly agreeing to allow for possibility of cross-domain interrupt
> attack.
> 
> Also, I think it may not be a bad idea to have AMD folks test you earlier
> patch on multi-IOMMU system (and simulate bad IVRS) to see how it behaves 
> there.

That would indeed be very desirable.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:49:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:49: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 1U3r90-0003aw-OS; Fri, 08 Feb 2013 16:49:46 +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 1U3r8y-0003ai-OE
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:49:44 +0000
Received: from [85.158.138.51:14102] by server-10.bemta-3.messagelabs.com id
	D3/13-10609-3AC25115; Fri, 08 Feb 2013 16:49:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1360342178!31484891!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16625 invoked from network); 8 Feb 2013 16:49:39 -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; 8 Feb 2013 16:49:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3r8q-000Om9-OS; Fri, 08 Feb 2013 16:49:36 +0000
Date: Fri, 8 Feb 2013 16:49:36 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20130208164936.GB93591@ocelot.phlegethon.org>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > selector) fits into a word.
> > > > > >
> > > > >
> > > > > That's still going to be a problem with Windows drivers.
> > > > > Unfortunately
> > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > thing that is word size is a pointer. Any chance we can use
> > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > >
> > > >
> > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > all the relevant bit in the header or just the specific event channel
> > interface?
> > > >
> > >
> > > I was just pointing out that assumption that unsigned long == native
> > > word size does not hold for 64-bit Windows. So, if we're adding
> > > something new can we avoid use of unsigned long and use an abstract
> > > type defined to be the native word size?
> > 
> > Probably ought to be the existing xen_ulong_t.
> 
> That works for me :-)

Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
suggesting we change that?  On the grounds that any platform where it
would make a difference to the ABI has already had to adjust its
headers?  I think I can buy that.

In any case, if we are defining up a new native-word-size type, it
oughtn't to be uintptr_t --- there are systems where pointers are not
word-sized (e.g. x32) and we might want to support one of them at some
point.  Explicitly setting it to uint32_t/uint64_t also avoids any
further problems with compiler-specific variations.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:49:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:49: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 1U3r90-0003aw-OS; Fri, 08 Feb 2013 16:49:46 +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 1U3r8y-0003ai-OE
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:49:44 +0000
Received: from [85.158.138.51:14102] by server-10.bemta-3.messagelabs.com id
	D3/13-10609-3AC25115; Fri, 08 Feb 2013 16:49:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1360342178!31484891!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16625 invoked from network); 8 Feb 2013 16:49:39 -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; 8 Feb 2013 16:49:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3r8q-000Om9-OS; Fri, 08 Feb 2013 16:49:36 +0000
Date: Fri, 8 Feb 2013 16:49:36 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20130208164936.GB93591@ocelot.phlegethon.org>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > selector) fits into a word.
> > > > > >
> > > > >
> > > > > That's still going to be a problem with Windows drivers.
> > > > > Unfortunately
> > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > thing that is word size is a pointer. Any chance we can use
> > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > >
> > > >
> > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > all the relevant bit in the header or just the specific event channel
> > interface?
> > > >
> > >
> > > I was just pointing out that assumption that unsigned long == native
> > > word size does not hold for 64-bit Windows. So, if we're adding
> > > something new can we avoid use of unsigned long and use an abstract
> > > type defined to be the native word size?
> > 
> > Probably ought to be the existing xen_ulong_t.
> 
> That works for me :-)

Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
suggesting we change that?  On the grounds that any platform where it
would make a difference to the ABI has already had to adjust its
headers?  I think I can buy that.

In any case, if we are defining up a new native-word-size type, it
oughtn't to be uintptr_t --- there are systems where pointers are not
word-sized (e.g. x32) and we might want to support one of them at some
point.  Explicitly setting it to uint32_t/uint64_t also avoids any
further problems with compiler-specific variations.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:51:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rA2-0003hH-6z; Fri, 08 Feb 2013 16:50:50 +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 1U3rA1-0003h8-DO
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:50:49 +0000
Received: from [85.158.137.99:41494] by server-9.bemta-3.messagelabs.com id
	C3/97-09484-8EC25115; Fri, 08 Feb 2013 16:50:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360342244!17200953!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13475 invoked from network); 8 Feb 2013 16:50:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:50:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:50:44 +0000
Message-Id: <51153AF402000078000BD48E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:50:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 "Tim Deegan" <tim@xen.org>
References: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
	<5115116D.4010707@citrix.com>
In-Reply-To: <5115116D.4010707@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] HAP: Add global enable/disable 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

>>> On 08.02.13 at 15:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Ping?

As being HAP related I was assuming Tim would be taking care of
this, despite the modified code not being under xen/arch/x86/mm/,
or at least ack it.

Jan

> On 28/01/13 11:21, Andrew Cooper wrote:
>> Also, correct a copy&paste error in the documentation.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> ---
>>
>> Changes since v1:
>>  * bool_t __initdata
>>  * tweak logic to reduce size of patch
>>
>> diff -r 5af4f2ab06f3 -r b741ace3835a docs/misc/xen-command-line.markdown
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -521,6 +521,14 @@ more importance will be printed.
>>  The optional `<rate-limited level>` option instructs which severities
>>  should be rate limited.
>>  
>> +### hap
>> +> `= <boolean>`
>> +
>> +> Default: `true`
>> +
>> +Flag to globally enable or disable support for Hardware Assisted
>> +Paging (HAP)
>> +
>>  ### hap\_1gb
>>  > `= <boolean>`
>>  
>> @@ -534,7 +542,7 @@ Paging (HAP).
>>  
>>  > Default: `true`
>>  
>> -Flag to enable 1 GB host page table support for Hardware Assisted
>> +Flag to enable 2 MB host page table support for Hardware Assisted
>>  Paging (HAP).
>>  
>>  ### hpetbroadcast
>> diff -r 5af4f2ab06f3 -r b741ace3835a xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -78,6 +78,10 @@ struct hvm_function_table hvm_funcs __re
>>  unsigned long __attribute__ ((__section__ (".bss.page_aligned")))
>>      hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
>>  
>> +/* Xen command-line option to enable HAP */
>> +static bool_t __initdata opt_hap_enabled = 1;
>> +boolean_param("hap", opt_hap_enabled);
>> +
>>  static int cpu_callback(
>>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>>  {
>> @@ -123,7 +127,14 @@ static int __init hvm_enable(void)
>>      hvm_enabled = 1;
>>  
>>      printk("HVM: %s enabled\n", hvm_funcs.name);
>> -    if ( hvm_funcs.hap_supported )
>> +    if ( ! hvm_funcs.hap_supported )
>> +        printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
>> +    else if ( ! opt_hap_enabled )
>> +    {
>> +        hvm_funcs.hap_supported = 0;
>> +        printk("HVM: Hardware Assisted Paging (HAP) detected but 
> disabled\n");
>> +    }
>> +    else
>>      {
>>          printk("HVM: Hardware Assisted Paging (HAP) detected\n");
>>          printk("HVM: HAP page sizes: 4kB");
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/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 Feb 08 16:51:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rA2-0003hH-6z; Fri, 08 Feb 2013 16:50:50 +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 1U3rA1-0003h8-DO
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:50:49 +0000
Received: from [85.158.137.99:41494] by server-9.bemta-3.messagelabs.com id
	C3/97-09484-8EC25115; Fri, 08 Feb 2013 16:50:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360342244!17200953!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13475 invoked from network); 8 Feb 2013 16:50:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:50:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:50:44 +0000
Message-Id: <51153AF402000078000BD48E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:50:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
 "Tim Deegan" <tim@xen.org>
References: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
	<5115116D.4010707@citrix.com>
In-Reply-To: <5115116D.4010707@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] HAP: Add global enable/disable 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

>>> On 08.02.13 at 15:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Ping?

As being HAP related I was assuming Tim would be taking care of
this, despite the modified code not being under xen/arch/x86/mm/,
or at least ack it.

Jan

> On 28/01/13 11:21, Andrew Cooper wrote:
>> Also, correct a copy&paste error in the documentation.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> ---
>>
>> Changes since v1:
>>  * bool_t __initdata
>>  * tweak logic to reduce size of patch
>>
>> diff -r 5af4f2ab06f3 -r b741ace3835a docs/misc/xen-command-line.markdown
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -521,6 +521,14 @@ more importance will be printed.
>>  The optional `<rate-limited level>` option instructs which severities
>>  should be rate limited.
>>  
>> +### hap
>> +> `= <boolean>`
>> +
>> +> Default: `true`
>> +
>> +Flag to globally enable or disable support for Hardware Assisted
>> +Paging (HAP)
>> +
>>  ### hap\_1gb
>>  > `= <boolean>`
>>  
>> @@ -534,7 +542,7 @@ Paging (HAP).
>>  
>>  > Default: `true`
>>  
>> -Flag to enable 1 GB host page table support for Hardware Assisted
>> +Flag to enable 2 MB host page table support for Hardware Assisted
>>  Paging (HAP).
>>  
>>  ### hpetbroadcast
>> diff -r 5af4f2ab06f3 -r b741ace3835a xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -78,6 +78,10 @@ struct hvm_function_table hvm_funcs __re
>>  unsigned long __attribute__ ((__section__ (".bss.page_aligned")))
>>      hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
>>  
>> +/* Xen command-line option to enable HAP */
>> +static bool_t __initdata opt_hap_enabled = 1;
>> +boolean_param("hap", opt_hap_enabled);
>> +
>>  static int cpu_callback(
>>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>>  {
>> @@ -123,7 +127,14 @@ static int __init hvm_enable(void)
>>      hvm_enabled = 1;
>>  
>>      printk("HVM: %s enabled\n", hvm_funcs.name);
>> -    if ( hvm_funcs.hap_supported )
>> +    if ( ! hvm_funcs.hap_supported )
>> +        printk("HVM: Hardware Assisted Paging (HAP) not detected\n");
>> +    else if ( ! opt_hap_enabled )
>> +    {
>> +        hvm_funcs.hap_supported = 0;
>> +        printk("HVM: Hardware Assisted Paging (HAP) detected but 
> disabled\n");
>> +    }
>> +    else
>>      {
>>          printk("HVM: Hardware Assisted Paging (HAP) detected\n");
>>          printk("HVM: HAP page sizes: 4kB");
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/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 Feb 08 16:53:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rCS-00048Q-Pw; Fri, 08 Feb 2013 16:53:20 +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 1U3rCR-00048E-9g
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:53:19 +0000
Received: from [85.158.139.83:60867] by server-1.bemta-5.messagelabs.com id
	49/65-29263-E7D25115; Fri, 08 Feb 2013 16:53:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360342397!20201020!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30686 invoked from network); 8 Feb 2013 16:53:17 -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; 8 Feb 2013 16:53:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3rCO-000OnC-D6; Fri, 08 Feb 2013 16:53:16 +0000
Date: Fri, 8 Feb 2013 16:53:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130208165316.GC93591@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
	<20130207163036.GO77133@ocelot.phlegethon.org>
	<1360254812.32479.90.camel@zakaz.uk.xensource.com>
	<1360341915.29432.82.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360341915.29432.82.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache 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

At 16:45 +0000 on 08 Feb (1360341915), Ian Campbell wrote:
> Subject: [PATCH] xen: arm64: dcache flush
> 
> Use "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
> former is valid on 64-bit.
> 
> Abstract the actual flush operation into a macro.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
> v2: revert to inline asm
> ---
>  xen/include/asm-arm/arm32/page.h |    3 +++
>  xen/include/asm-arm/arm64/page.h |    3 +++
>  xen/include/asm-arm/page.h       |    8 ++++----
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
> index 96b5798..45d25ee 100644
> --- a/xen/include/asm-arm/arm32/page.h
> +++ b/xen/include/asm-arm/arm32/page.h
> @@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>          : : "r" (pte.bits), "r" (p) : "memory");
>  }
>  
> +/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
> +#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
> +
>  /*
>   * Flush all hypervisor mappings from the TLB and branch predictor.
>   * This is needed after changing Xen code mappings.
> diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
> index ce5be63..1d7c70e 100644
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>          : : "r" (pte.bits), "r" (p) : "memory");
>  }
>  
> +/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
> +#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
> +
>  /*
>   * Flush all hypervisor mappings from the TLB
>   * This is needed after changing Xen code mappings.
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 4e245a9..b89238b 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>      void *end;
>      dsb();           /* So the CPU issues all writes to the range */
>      for ( end = p + size; p < end; p += cacheline_bytes )
> -        WRITE_CP32((uint32_t) p, DCCMVAC);
> +        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
>      dsb();           /* So we know the flushes happen before continuing */
>  }
>  
> @@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>          flush_xen_dcache_va_range(_p, sizeof(x));                       \
>      else                                                                \
>          asm volatile (                                                  \
> -            "dsb;"   /* Finish all earlier writes */                    \
> -            STORE_CP32(0, DCCMVAC)                                      \
> -            "dsb;"   /* Finish flush before continuing */               \
> +            "dsb sy;"   /* Finish all earlier writes */                 \
> +            __flush_xen_dcache_one(0)                                   \
> +            "dsb sy;"   /* Finish flush before continuing */            \
>              : : "r" (_p), "m" (*_p));                                   \
>  } while (0)
>  
> -- 
> 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 Feb 08 16:53:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rCS-00048Q-Pw; Fri, 08 Feb 2013 16:53:20 +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 1U3rCR-00048E-9g
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:53:19 +0000
Received: from [85.158.139.83:60867] by server-1.bemta-5.messagelabs.com id
	49/65-29263-E7D25115; Fri, 08 Feb 2013 16:53:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360342397!20201020!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30686 invoked from network); 8 Feb 2013 16:53:17 -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; 8 Feb 2013 16:53:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3rCO-000OnC-D6; Fri, 08 Feb 2013 16:53:16 +0000
Date: Fri, 8 Feb 2013 16:53:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130208165316.GC93591@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-13-git-send-email-ian.campbell@citrix.com>
	<20130207161432.GN77133@ocelot.phlegethon.org>
	<1360254170.32479.88.camel@zakaz.uk.xensource.com>
	<20130207163036.GO77133@ocelot.phlegethon.org>
	<1360254812.32479.90.camel@zakaz.uk.xensource.com>
	<1360341915.29432.82.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360341915.29432.82.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache 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

At 16:45 +0000 on 08 Feb (1360341915), Ian Campbell wrote:
> Subject: [PATCH] xen: arm64: dcache flush
> 
> Use "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
> former is valid on 64-bit.
> 
> Abstract the actual flush operation into a macro.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
> v2: revert to inline asm
> ---
>  xen/include/asm-arm/arm32/page.h |    3 +++
>  xen/include/asm-arm/arm64/page.h |    3 +++
>  xen/include/asm-arm/page.h       |    8 ++++----
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
> index 96b5798..45d25ee 100644
> --- a/xen/include/asm-arm/arm32/page.h
> +++ b/xen/include/asm-arm/arm32/page.h
> @@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>          : : "r" (pte.bits), "r" (p) : "memory");
>  }
>  
> +/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
> +#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
> +
>  /*
>   * Flush all hypervisor mappings from the TLB and branch predictor.
>   * This is needed after changing Xen code mappings.
> diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
> index ce5be63..1d7c70e 100644
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>          : : "r" (pte.bits), "r" (p) : "memory");
>  }
>  
> +/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
> +#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
> +
>  /*
>   * Flush all hypervisor mappings from the TLB
>   * This is needed after changing Xen code mappings.
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 4e245a9..b89238b 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>      void *end;
>      dsb();           /* So the CPU issues all writes to the range */
>      for ( end = p + size; p < end; p += cacheline_bytes )
> -        WRITE_CP32((uint32_t) p, DCCMVAC);
> +        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
>      dsb();           /* So we know the flushes happen before continuing */
>  }
>  
> @@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>          flush_xen_dcache_va_range(_p, sizeof(x));                       \
>      else                                                                \
>          asm volatile (                                                  \
> -            "dsb;"   /* Finish all earlier writes */                    \
> -            STORE_CP32(0, DCCMVAC)                                      \
> -            "dsb;"   /* Finish flush before continuing */               \
> +            "dsb sy;"   /* Finish all earlier writes */                 \
> +            __flush_xen_dcache_one(0)                                   \
> +            "dsb sy;"   /* Finish flush before continuing */            \
>              : : "r" (_p), "m" (*_p));                                   \
>  } while (0)
>  
> -- 
> 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 Feb 08 16:56:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:56: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 1U3rEz-0004Ij-Cu; Fri, 08 Feb 2013 16:55:57 +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 1U3rEx-0004Ib-HM
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:55:55 +0000
Received: from [85.158.137.99:38678] by server-16.bemta-3.messagelabs.com id
	55/5D-02727-A1E25115; Fri, 08 Feb 2013 16:55:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360342553!20607031!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32026 invoked from network); 8 Feb 2013 16:55:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:55:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:55:52 +0000
Message-Id: <51153C2902000078000BD4A6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:55:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?R8OhYm9yIFDDiUs=?=" <pek@crysys.hu>
References: <511510FA.8010109@crysys.hu>
In-Reply-To: <511510FA.8010109@crysys.hu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] NMI SERR interrupts in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA4LjAyLjEzIGF0IDE1OjUxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90
ZToKPiBbK10gQXQgdGhlIHNhbWUgdGltZSwgUENJIFNFUlIgaW50ZXJydXB0cyByZWZlciB0byBo
YXJkd2FyZSBlcnJvcnMgdGhhdAo+IGlzIGdlbmVyYXRlZCBieSBteSBwYXNzdGhyb3VnaCBOSUMg
ZGlyZWN0bHksIHNvIEkgZXhwZWN0IHRoYXQgdGhlc2UKPiBpbnRlcnJ1cHRzIGFyZSBwaHlzaWNh
bCAoZS5nLiwgTVNJcykgc28gdGhleSBzaG91bGQgZ28gZGlyZWN0bHkgZWl0aGVyCj4gdG8gdGhl
IEJTUCBvciBvbmUgb2YgdGhlIEFQcy4gSG93ZXZlciwgSW50ZXJydXB0IHJlbWFwcGluZyBpcyBp
biBwbGFjZQo+IHdoaWNoIHNob3VsZCBjaGVjayB0aGUgb3JpZ2luIG9mIHN1Y2ggaW50ZXJydXB0
cyBhbmQgc2hvdWxkIHJlbWFwIHRoZQo+IGludGVycnVwdHMgYnkgdXNpbmcgdGhlIEJERiBpZCBv
ZiB0aGUgZGV2aWNlLiBUaHVzLCB0aGUgcmVhbCBpbnRlcnJ1cHQKPiBpcyBnZW5lcmF0ZWQgYnkg
dGhlIEludGVycnVwdCBSZW1hcHBpbmcgaGFyZHdhcmUgdW5pdCB3aGljaCBpcyBzdGlsbCBhCj4g
cGh5c2ljYWwgb25lLiBBbSBJIHJpZ2h0PwoKTm8sIE5NSXMgZG9uJ3QgZ28gdGhyb3VnaCB0aGUg
cmVtYXBwaW5nIGhhcmR3YXJlLCB0aGV5IGdldApkZWxpdmVyZWQgZGlyZWN0bHkgdG8gdGhlIENQ
VS4gV2hpY2ggbWFrZXMgc2Vuc2UsIGJlY2F1c2UgdGhleQpwb2ludCBvdXQgYSBwcm9ibGVtIGlu
IHRoZSBzeXN0ZW0gYXMgYSB3aG9sZSwgcmVnYXJkbGVzcyBvZgp3aGV0aGVyIGEgZGV2aWNlIGhh
dmluZyBjYXVzZWQgdGhlbSBpcyBhc3NpZ25lZCB0byBhIGd1ZXN0LgoKTm90ZSB0aGF0IGJlY2F1
c2Ugb2YgdGhlIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIGRldmljZXMgcmFpc2luZwpzdWNoIGFu
IE5NSSwgSSB0aGluayBpdCBpcyBhbHNvIG5vdCBwb3NzaWJsZSBmb3IgWGVuIHRvIGFjdHVhbGx5
IGtub3cKd2hpY2ggZGV2aWNlKHMpIGNhdXNlZCB0aGUgTk1JLCBhbmQgaGVuY2UgaXQgaGFzIG5v
IHdheSB0bwphc3NvY2lhdGUgaXQgd2l0aCBhIHBhcnRpY3VsYXIgZ3Vlc3QsIGV2ZW4gaWYgaXQg
d2FudGVkIHRvLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:56:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:56: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 1U3rEz-0004Ij-Cu; Fri, 08 Feb 2013 16:55:57 +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 1U3rEx-0004Ib-HM
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:55:55 +0000
Received: from [85.158.137.99:38678] by server-16.bemta-3.messagelabs.com id
	55/5D-02727-A1E25115; Fri, 08 Feb 2013 16:55:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360342553!20607031!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32026 invoked from network); 8 Feb 2013 16:55:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:55:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:55:52 +0000
Message-Id: <51153C2902000078000BD4A6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:55:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?R8OhYm9yIFDDiUs=?=" <pek@crysys.hu>
References: <511510FA.8010109@crysys.hu>
In-Reply-To: <511510FA.8010109@crysys.hu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] NMI SERR interrupts in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDA4LjAyLjEzIGF0IDE1OjUxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90
ZToKPiBbK10gQXQgdGhlIHNhbWUgdGltZSwgUENJIFNFUlIgaW50ZXJydXB0cyByZWZlciB0byBo
YXJkd2FyZSBlcnJvcnMgdGhhdAo+IGlzIGdlbmVyYXRlZCBieSBteSBwYXNzdGhyb3VnaCBOSUMg
ZGlyZWN0bHksIHNvIEkgZXhwZWN0IHRoYXQgdGhlc2UKPiBpbnRlcnJ1cHRzIGFyZSBwaHlzaWNh
bCAoZS5nLiwgTVNJcykgc28gdGhleSBzaG91bGQgZ28gZGlyZWN0bHkgZWl0aGVyCj4gdG8gdGhl
IEJTUCBvciBvbmUgb2YgdGhlIEFQcy4gSG93ZXZlciwgSW50ZXJydXB0IHJlbWFwcGluZyBpcyBp
biBwbGFjZQo+IHdoaWNoIHNob3VsZCBjaGVjayB0aGUgb3JpZ2luIG9mIHN1Y2ggaW50ZXJydXB0
cyBhbmQgc2hvdWxkIHJlbWFwIHRoZQo+IGludGVycnVwdHMgYnkgdXNpbmcgdGhlIEJERiBpZCBv
ZiB0aGUgZGV2aWNlLiBUaHVzLCB0aGUgcmVhbCBpbnRlcnJ1cHQKPiBpcyBnZW5lcmF0ZWQgYnkg
dGhlIEludGVycnVwdCBSZW1hcHBpbmcgaGFyZHdhcmUgdW5pdCB3aGljaCBpcyBzdGlsbCBhCj4g
cGh5c2ljYWwgb25lLiBBbSBJIHJpZ2h0PwoKTm8sIE5NSXMgZG9uJ3QgZ28gdGhyb3VnaCB0aGUg
cmVtYXBwaW5nIGhhcmR3YXJlLCB0aGV5IGdldApkZWxpdmVyZWQgZGlyZWN0bHkgdG8gdGhlIENQ
VS4gV2hpY2ggbWFrZXMgc2Vuc2UsIGJlY2F1c2UgdGhleQpwb2ludCBvdXQgYSBwcm9ibGVtIGlu
IHRoZSBzeXN0ZW0gYXMgYSB3aG9sZSwgcmVnYXJkbGVzcyBvZgp3aGV0aGVyIGEgZGV2aWNlIGhh
dmluZyBjYXVzZWQgdGhlbSBpcyBhc3NpZ25lZCB0byBhIGd1ZXN0LgoKTm90ZSB0aGF0IGJlY2F1
c2Ugb2YgdGhlIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIGRldmljZXMgcmFpc2luZwpzdWNoIGFu
IE5NSSwgSSB0aGluayBpdCBpcyBhbHNvIG5vdCBwb3NzaWJsZSBmb3IgWGVuIHRvIGFjdHVhbGx5
IGtub3cKd2hpY2ggZGV2aWNlKHMpIGNhdXNlZCB0aGUgTk1JLCBhbmQgaGVuY2UgaXQgaGFzIG5v
IHdheSB0bwphc3NvY2lhdGUgaXQgd2l0aCBhIHBhcnRpY3VsYXIgZ3Vlc3QsIGV2ZW4gaWYgaXQg
d2FudGVkIHRvLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:57:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rGa-0004Tw-St; Fri, 08 Feb 2013 16:57:36 +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 1U3rGZ-0004Tn-WE
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:57:36 +0000
Received: from [85.158.139.211:7680] by server-5.bemta-5.messagelabs.com id
	95/38-11945-F7E25115; Fri, 08 Feb 2013 16:57:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360342654!21661825!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20325 invoked from network); 8 Feb 2013 16:57:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:57:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3rGV-000Oo9-9C; Fri, 08 Feb 2013 16:57:31 +0000
Date: Fri, 8 Feb 2013 16:57:31 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130208165731.GD93591@ocelot.phlegethon.org>
References: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
	<5115116D.4010707@citrix.com>
	<51153AF402000078000BD48E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51153AF402000078000BD48E@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] HAP: Add global enable/disable 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

At 16:50 +0000 on 08 Feb (1360342244), Jan Beulich wrote:
> >>> On 08.02.13 at 15:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > Ping?
> 
> As being HAP related I was assuming Tim would be taking care of
> this, despite the modified code not being under xen/arch/x86/mm/,
> or at least ack it.

Sorry, slipped under my radar. 

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 Feb 08 16:57:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rGa-0004Tw-St; Fri, 08 Feb 2013 16:57:36 +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 1U3rGZ-0004Tn-WE
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:57:36 +0000
Received: from [85.158.139.211:7680] by server-5.bemta-5.messagelabs.com id
	95/38-11945-F7E25115; Fri, 08 Feb 2013 16:57:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360342654!21661825!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20325 invoked from network); 8 Feb 2013 16:57:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:57:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3rGV-000Oo9-9C; Fri, 08 Feb 2013 16:57:31 +0000
Date: Fri, 8 Feb 2013 16:57:31 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130208165731.GD93591@ocelot.phlegethon.org>
References: <b741ace3835ac7408e32.1359372076@andrewcoop.uk.xensource.com>
	<5115116D.4010707@citrix.com>
	<51153AF402000078000BD48E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51153AF402000078000BD48E@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] HAP: Add global enable/disable 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

At 16:50 +0000 on 08 Feb (1360342244), Jan Beulich wrote:
> >>> On 08.02.13 at 15:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > Ping?
> 
> As being HAP related I was assuming Tim would be taking care of
> this, despite the modified code not being under xen/arch/x86/mm/,
> or at least ack it.

Sorry, slipped under my radar. 

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 Feb 08 16:57:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rGk-0004V8-9V; Fri, 08 Feb 2013 16:57: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 1U3rGi-0004Ur-NW
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:57:44 +0000
Received: from [85.158.137.99:6180] by server-10.bemta-3.messagelabs.com id
	AB/10-10609-38E25115; Fri, 08 Feb 2013 16:57:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360342654!15226193!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29540 invoked from network); 8 Feb 2013 16:57:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:57:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:56:33 +0000
Message-Id: <51153C5202000078000BD4A9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:56:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>,
 "Tim Deegan" <tim@xen.org>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
In-Reply-To: <20130208164936.GB93591@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 08.02.13 at 17:49, Tim Deegan <tim@xen.org> wrote:
> Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> suggesting we change that?  On the grounds that any platform where it
> would make a difference to the ABI has already had to adjust its
> headers?  I think I can buy that.

I don't think we should be changing the underlying definition on
x86.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:57:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16: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 1U3rGk-0004V8-9V; Fri, 08 Feb 2013 16:57: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 1U3rGi-0004Ur-NW
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:57:44 +0000
Received: from [85.158.137.99:6180] by server-10.bemta-3.messagelabs.com id
	AB/10-10609-38E25115; Fri, 08 Feb 2013 16:57:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360342654!15226193!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29540 invoked from network); 8 Feb 2013 16:57:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 16:57:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 08 Feb 2013 16:56:33 +0000
Message-Id: <51153C5202000078000BD4A9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 08 Feb 2013 16:56:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>,
 "Tim Deegan" <tim@xen.org>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
In-Reply-To: <20130208164936.GB93591@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 08.02.13 at 17:49, Tim Deegan <tim@xen.org> wrote:
> Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> suggesting we change that?  On the grounds that any platform where it
> would make a difference to the ABI has already had to adjust its
> headers?  I think I can buy that.

I don't think we should be changing the underlying definition on
x86.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:59:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:59: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 1U3rIH-0004iS-QI; Fri, 08 Feb 2013 16:59: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 1U3rIF-0004hx-Rc
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:59:20 +0000
Received: from [85.158.139.211:21536] by server-10.bemta-5.messagelabs.com id
	A8/DE-04697-7EE25115; Fri, 08 Feb 2013 16:59:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360342742!18963590!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11918 invoked from network); 8 Feb 2013 16:59:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:59:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289849"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:59: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.297.1; Fri, 8 Feb 2013
	16:59:02 +0000
Message-ID: <1360342741.29432.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 8 Feb 2013 16:59:01 +0000
In-Reply-To: <20130208164936.GB93591@ocelot.phlegethon.org>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > > selector) fits into a word.
> > > > > > >
> > > > > >
> > > > > > That's still going to be a problem with Windows drivers.
> > > > > > Unfortunately
> > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > thing that is word size is a pointer. Any chance we can use
> > > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > > >
> > > > >
> > > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > > all the relevant bit in the header or just the specific event channel
> > > interface?
> > > > >
> > > >
> > > > I was just pointing out that assumption that unsigned long == native
> > > > word size does not hold for 64-bit Windows. So, if we're adding
> > > > something new can we avoid use of unsigned long and use an abstract
> > > > type defined to be the native word size?
> > > 
> > > Probably ought to be the existing xen_ulong_t.
> > 
> > That works for me :-)
> 
> Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> suggesting we change that?

I don't think that would be a good idea, but using xen_ulong_t does at
least mean he only needs to change one place rather than sed'ing up the
whole lot.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 16:59:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 16:59: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 1U3rIH-0004iS-QI; Fri, 08 Feb 2013 16:59: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 1U3rIF-0004hx-Rc
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 16:59:20 +0000
Received: from [85.158.139.211:21536] by server-10.bemta-5.messagelabs.com id
	A8/DE-04697-7EE25115; Fri, 08 Feb 2013 16:59:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360342742!18963590!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11918 invoked from network); 8 Feb 2013 16:59:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 16:59:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1289849"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 16:59: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.297.1; Fri, 8 Feb 2013
	16:59:02 +0000
Message-ID: <1360342741.29432.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 8 Feb 2013 16:59:01 +0000
In-Reply-To: <20130208164936.GB93591@ocelot.phlegethon.org>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > > selector) fits into a word.
> > > > > > >
> > > > > >
> > > > > > That's still going to be a problem with Windows drivers.
> > > > > > Unfortunately
> > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > thing that is word size is a pointer. Any chance we can use
> > > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > > >
> > > > >
> > > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > > all the relevant bit in the header or just the specific event channel
> > > interface?
> > > > >
> > > >
> > > > I was just pointing out that assumption that unsigned long == native
> > > > word size does not hold for 64-bit Windows. So, if we're adding
> > > > something new can we avoid use of unsigned long and use an abstract
> > > > type defined to be the native word size?
> > > 
> > > Probably ought to be the existing xen_ulong_t.
> > 
> > That works for me :-)
> 
> Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> suggesting we change that?

I don't think that would be a good idea, but using xen_ulong_t does at
least mean he only needs to change one place rather than sed'ing up the
whole lot.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:06:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rPL-00057b-0t; Fri, 08 Feb 2013 17:06: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 1U3rPK-00057W-3I
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:06:38 +0000
Received: from [85.158.143.35:19652] by server-3.bemta-4.messagelabs.com id
	5B/A9-08920-D9035115; Fri, 08 Feb 2013 17:06:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360343191!13127998!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5022 invoked from network); 8 Feb 2013 17:06:31 -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; 8 Feb 2013 17:06:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3rPC-000OqO-6g; Fri, 08 Feb 2013 17:06:30 +0000
Date: Fri, 8 Feb 2013 17:06:30 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130208170630.GE93591@ocelot.phlegethon.org>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
	<1360342741.29432.85.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360342741.29432.85.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

At 16:59 +0000 on 08 Feb (1360342741), Ian Campbell wrote:
> On Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> > At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > > > selector) fits into a word.
> > > > > > > >
> > > > > > >
> > > > > > > That's still going to be a problem with Windows drivers.
> > > > > > > Unfortunately
> > > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > > thing that is word size is a pointer. Any chance we can use
> > > > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > > > >
> > > > > >
> > > > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > > > all the relevant bit in the header or just the specific event channel
> > > > interface?
> > > > > >
> > > > >
> > > > > I was just pointing out that assumption that unsigned long == native
> > > > > word size does not hold for 64-bit Windows. So, if we're adding
> > > > > something new can we avoid use of unsigned long and use an abstract
> > > > > type defined to be the native word size?
> > > > 
> > > > Probably ought to be the existing xen_ulong_t.
> > > 
> > > That works for me :-)
> > 
> > Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> > suggesting we change that?
> 
> I don't think that would be a good idea, but using xen_ulong_t does at
> least mean he only needs to change one place rather than sed'ing up the
> whole lot.

Ah, OK. 

But on arm32 it's explicitly the wrong thing (i.e. bigger than a word).
Is that just going to be part of the cost of using explicit sizes
everywhere on arm?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:06:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rPL-00057b-0t; Fri, 08 Feb 2013 17:06: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 1U3rPK-00057W-3I
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:06:38 +0000
Received: from [85.158.143.35:19652] by server-3.bemta-4.messagelabs.com id
	5B/A9-08920-D9035115; Fri, 08 Feb 2013 17:06:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360343191!13127998!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5022 invoked from network); 8 Feb 2013 17:06:31 -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; 8 Feb 2013 17:06:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U3rPC-000OqO-6g; Fri, 08 Feb 2013 17:06:30 +0000
Date: Fri, 8 Feb 2013 17:06:30 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130208170630.GE93591@ocelot.phlegethon.org>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
	<1360342741.29432.85.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360342741.29432.85.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

At 16:59 +0000 on 08 Feb (1360342741), Ian Campbell wrote:
> On Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> > At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > > > selector) fits into a word.
> > > > > > > >
> > > > > > >
> > > > > > > That's still going to be a problem with Windows drivers.
> > > > > > > Unfortunately
> > > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > > thing that is word size is a pointer. Any chance we can use
> > > > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > > > >
> > > > > >
> > > > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > > > all the relevant bit in the header or just the specific event channel
> > > > interface?
> > > > > >
> > > > >
> > > > > I was just pointing out that assumption that unsigned long == native
> > > > > word size does not hold for 64-bit Windows. So, if we're adding
> > > > > something new can we avoid use of unsigned long and use an abstract
> > > > > type defined to be the native word size?
> > > > 
> > > > Probably ought to be the existing xen_ulong_t.
> > > 
> > > That works for me :-)
> > 
> > Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> > suggesting we change that?
> 
> I don't think that would be a good idea, but using xen_ulong_t does at
> least mean he only needs to change one place rather than sed'ing up the
> whole lot.

Ah, OK. 

But on arm32 it's explicitly the wrong thing (i.e. bigger than a word).
Is that just going to be part of the cost of using explicit sizes
everywhere on arm?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:07:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rPm-000594-Eb; Fri, 08 Feb 2013 17:07:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3rPl-00058w-9D
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:07:05 +0000
Received: from [85.158.143.99:46449] by server-3.bemta-4.messagelabs.com id
	93/1A-08920-8B035115; Fri, 08 Feb 2013 17:07:04 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360343216!18541878!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9696 invoked from network); 8 Feb 2013 17:06:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:06:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290101"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:06:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 8 Feb 2013
	17:06:44 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 8 Feb 2013 17:07:21 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4GHFm9H7SPWW8RTv6vXyx6+tBh2wAAa61A
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457557CD@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
In-Reply-To: <20130208164936.GB93591@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: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 08 February 2013 16:50
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xen.org; Wei Liu; David Vrabel;
> jbeulich@suse.com; Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> 
> At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > I don't think so. The reason to use unsigned long here is
> > > > > > > > to guarantee each selector (in 2-level case there is only
> > > > > > > > L1
> > > > > > > > selector) fits into a word.
> > > > > > >
> > > > > >
> > > > > > That's still going to be a problem with Windows drivers.
> > > > > > Unfortunately
> > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > thing that is word size is a pointer. Any chance we can use
> > > > > uintptr_t rather than an unsigned long? (At the moment I have to
> > > > > sed all the public headers to replace long with LONG_PTR and it's a
> PITA).
> > > > > >
> > > > >
> > > > > TBH I don't know much about Windows. But are you suggesting
> > > > > replace all the relevant bit in the header or just the specific
> > > > > event channel
> > > interface?
> > > > >
> > > >
> > > > I was just pointing out that assumption that unsigned long ==
> > > > native word size does not hold for 64-bit Windows. So, if we're
> > > > adding something new can we avoid use of unsigned long and use an
> > > > abstract type defined to be the native word size?
> > >
> > > Probably ought to be the existing xen_ulong_t.
> >
> > That works for me :-)
> 
> Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> suggesting we change that?  On the grounds that any platform where it
> would make a difference to the ABI has already had to adjust its headers?  I
> think I can buy that.
> 

Yes, the crux of the issue is what *is* an unsigned long? If Xen uses one model and the guest OS uses a different one then use of non-abstract types in the public headers becomes awkward.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:07:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rPm-000594-Eb; Fri, 08 Feb 2013 17:07:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U3rPl-00058w-9D
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:07:05 +0000
Received: from [85.158.143.99:46449] by server-3.bemta-4.messagelabs.com id
	93/1A-08920-8B035115; Fri, 08 Feb 2013 17:07:04 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360343216!18541878!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9696 invoked from network); 8 Feb 2013 17:06:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:06:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290101"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:06:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 8 Feb 2013
	17:06:44 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 8 Feb 2013 17:07:21 +0000
Thread-Topic: [Xen-devel] [PATCH 04/13] xen: sync public headers
Thread-Index: Ac4GHFm9H7SPWW8RTv6vXyx6+tBh2wAAa61A
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457557CD@LONPMAILBOX01.citrite.net>
References: <1359643627-29486-1-git-send-email-wei.liu2@citrix.com>
	<1359643627-29486-5-git-send-email-wei.liu2@citrix.com>
	<20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
In-Reply-To: <20130208164936.GB93591@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: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 08 February 2013 16:50
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xen.org; Wei Liu; David Vrabel;
> jbeulich@suse.com; Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public headers
> 
> At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > I don't think so. The reason to use unsigned long here is
> > > > > > > > to guarantee each selector (in 2-level case there is only
> > > > > > > > L1
> > > > > > > > selector) fits into a word.
> > > > > > >
> > > > > >
> > > > > > That's still going to be a problem with Windows drivers.
> > > > > > Unfortunately
> > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > thing that is word size is a pointer. Any chance we can use
> > > > > uintptr_t rather than an unsigned long? (At the moment I have to
> > > > > sed all the public headers to replace long with LONG_PTR and it's a
> PITA).
> > > > > >
> > > > >
> > > > > TBH I don't know much about Windows. But are you suggesting
> > > > > replace all the relevant bit in the header or just the specific
> > > > > event channel
> > > interface?
> > > > >
> > > >
> > > > I was just pointing out that assumption that unsigned long ==
> > > > native word size does not hold for 64-bit Windows. So, if we're
> > > > adding something new can we avoid use of unsigned long and use an
> > > > abstract type defined to be the native word size?
> > >
> > > Probably ought to be the existing xen_ulong_t.
> >
> > That works for me :-)
> 
> Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> suggesting we change that?  On the grounds that any platform where it
> would make a difference to the ABI has already had to adjust its headers?  I
> think I can buy that.
> 

Yes, the crux of the issue is what *is* an unsigned long? If Xen uses one model and the guest OS uses a different one then use of non-abstract types in the public headers becomes awkward.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:10:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:10: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 1U3rSU-0005Jn-13; Fri, 08 Feb 2013 17:09:54 +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 1U3rSS-0005Je-8q
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:09:52 +0000
Received: from [85.158.139.83:39773] by server-16.bemta-5.messagelabs.com id
	63/E4-14948-F5135115; Fri, 08 Feb 2013 17:09:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360343380!24157217!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21097 invoked from network); 8 Feb 2013 17:09:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:09: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.297.1; Fri, 8 Feb 2013
	17:09:39 +0000
Message-ID: <1360343378.29432.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 8 Feb 2013 17:09:38 +0000
In-Reply-To: <20130208170630.GE93591@ocelot.phlegethon.org>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
	<1360342741.29432.85.camel@zakaz.uk.xensource.com>
	<20130208170630.GE93591@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 17:06 +0000, Tim Deegan wrote:
> At 16:59 +0000 on 08 Feb (1360342741), Ian Campbell wrote:
> > On Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> > > At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > > > > selector) fits into a word.
> > > > > > > > >
> > > > > > > >
> > > > > > > > That's still going to be a problem with Windows drivers.
> > > > > > > > Unfortunately
> > > > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > > > thing that is word size is a pointer. Any chance we can use
> > > > > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > > > > >
> > > > > > >
> > > > > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > > > > all the relevant bit in the header or just the specific event channel
> > > > > interface?
> > > > > > >
> > > > > >
> > > > > > I was just pointing out that assumption that unsigned long == native
> > > > > > word size does not hold for 64-bit Windows. So, if we're adding
> > > > > > something new can we avoid use of unsigned long and use an abstract
> > > > > > type defined to be the native word size?
> > > > > 
> > > > > Probably ought to be the existing xen_ulong_t.
> > > > 
> > > > That works for me :-)
> > > 
> > > Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> > > suggesting we change that?
> > 
> > I don't think that would be a good idea, but using xen_ulong_t does at
> > least mean he only needs to change one place rather than sed'ing up the
> > whole lot.
> 
> Ah, OK. 
> 
> But on arm32 it's explicitly the wrong thing (i.e. bigger than a word).
> Is that just going to be part of the cost of using explicit sizes
> everywhere on arm?

Actually, Stefano and I were discussing this the other day, the use of
unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
should be fixed -- using xen_ulong_t would fix this too...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:10:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:10: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 1U3rSU-0005Jn-13; Fri, 08 Feb 2013 17:09:54 +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 1U3rSS-0005Je-8q
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:09:52 +0000
Received: from [85.158.139.83:39773] by server-16.bemta-5.messagelabs.com id
	63/E4-14948-F5135115; Fri, 08 Feb 2013 17:09:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360343380!24157217!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21097 invoked from network); 8 Feb 2013 17:09:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:09: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.297.1; Fri, 8 Feb 2013
	17:09:39 +0000
Message-ID: <1360343378.29432.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 8 Feb 2013 17:09:38 +0000
In-Reply-To: <20130208170630.GE93591@ocelot.phlegethon.org>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
	<1360342741.29432.85.camel@zakaz.uk.xensource.com>
	<20130208170630.GE93591@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 17:06 +0000, Tim Deegan wrote:
> At 16:59 +0000 on 08 Feb (1360342741), Ian Campbell wrote:
> > On Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> > > At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > > > > selector) fits into a word.
> > > > > > > > >
> > > > > > > >
> > > > > > > > That's still going to be a problem with Windows drivers.
> > > > > > > > Unfortunately
> > > > > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > > > > thing that is word size is a pointer. Any chance we can use
> > > > > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > > > > >
> > > > > > >
> > > > > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > > > > all the relevant bit in the header or just the specific event channel
> > > > > interface?
> > > > > > >
> > > > > >
> > > > > > I was just pointing out that assumption that unsigned long == native
> > > > > > word size does not hold for 64-bit Windows. So, if we're adding
> > > > > > something new can we avoid use of unsigned long and use an abstract
> > > > > > type defined to be the native word size?
> > > > > 
> > > > > Probably ought to be the existing xen_ulong_t.
> > > > 
> > > > That works for me :-)
> > > 
> > > Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
> > > suggesting we change that?
> > 
> > I don't think that would be a good idea, but using xen_ulong_t does at
> > least mean he only needs to change one place rather than sed'ing up the
> > whole lot.
> 
> Ah, OK. 
> 
> But on arm32 it's explicitly the wrong thing (i.e. bigger than a word).
> Is that just going to be part of the cost of using explicit sizes
> everywhere on arm?

Actually, Stefano and I were discussing this the other day, the use of
unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
should be fixed -- using xen_ulong_t would fix this too...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:10:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:10: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 1U3rT2-0005MV-Do; Fri, 08 Feb 2013 17:10:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3rT1-0005MM-Mt
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:10:27 +0000
Received: from [85.158.138.51:60781] by server-2.bemta-3.messagelabs.com id
	54/5C-25961-28135115; Fri, 08 Feb 2013 17:10:26 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360343424!29824657!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30966 invoked from network); 8 Feb 2013 17:10:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 17:10:25 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:57748 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 1U3rZJ-0001lJ-2g; Fri, 08 Feb 2013 18:16:57 +0100
Date: Fri, 8 Feb 2013 18:10:19 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <356983899.20130208181019@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <51153A7902000078000BD48B@nat28.tlf.novell.com>
References: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
	<51153A7902000078000BD48B@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, sherry.hurwitz@amd.com,
	suravee.suthikulpanit@amd.com, xiantao.zhang@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, February 8, 2013, 5:48:41 PM, you wrote:

>>>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:

>> ----- JBeulich@suse.com wrote:
>> 
>>> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> > A regression was reported on a class of broken firmware that c/s
>>> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
>>> 
>>> After some more thought on this and the comments we got
>>> regarding disabling the IOMMU in this situation altogether making
>>> things worse instead of better, I came to the conclusion that we
>>> can actually restrict the action in affected cases to just disabling
>>> interrupt remapping. That doesn't make the situation worse than
>>> prior to the XSA-36 fixes (where interrupt remapping didn't really
>>> protect domains from one another), but allows at least DMA
>>> isolation to still be utilized. Patch 3/2 below/attached.
>> 
>> But now users who don't examine log messages may not realize 
>> that interupt remapping is disabled and therefore the system can be
>> affected by XSA-36.

> Yes. We need to balance these against one another - I see pros
> and cons in both (and I don't mind dropping this additional patch
> if we collectively come to the conclusion that the way it is now -
> with the one earlier fix - is the better state). So I'm really
> interested in others' opinions.

One argument pro could be that linux seems to do the same (only disable interrupt remapping)

>> With current code (boot option to use global remapping table) users
>> are explicitly agreeing to allow for possibility of cross-domain interrupt
>> attack.
>> 
>> Also, I think it may not be a bad idea to have AMD folks test you earlier
>> patch on multi-IOMMU system (and simulate bad IVRS) to see how it behaves 
>> there.

And getting mainbord / bios manufactures actually support stuff .. instead of giving some nice disinformation.
Fresh from MSI techsupport:

Posted:         2013-02-09 00:11:38 (GMT+8),MSI
Content:        CPU virtualization (SVM) should be possible on the 890FXA-GD70. I/O virtualization (IOMMU) is support on the MSI's AMD 900-series. IOMMU will not be possible on MSI's AMD 800 series.

In short .. buy a new mainboard and pray .. pray hard .. that it works out of the box

> That would indeed be very desirable.

> Jan





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:10:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:10: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 1U3rT2-0005MV-Do; Fri, 08 Feb 2013 17:10:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3rT1-0005MM-Mt
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 17:10:27 +0000
Received: from [85.158.138.51:60781] by server-2.bemta-3.messagelabs.com id
	54/5C-25961-28135115; Fri, 08 Feb 2013 17:10:26 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360343424!29824657!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30966 invoked from network); 8 Feb 2013 17:10:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 17:10:25 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:57748 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 1U3rZJ-0001lJ-2g; Fri, 08 Feb 2013 18:16:57 +0100
Date: Fri, 8 Feb 2013 18:10:19 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <356983899.20130208181019@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <51153A7902000078000BD48B@nat28.tlf.novell.com>
References: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
	<51153A7902000078000BD48B@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, sherry.hurwitz@amd.com,
	suravee.suthikulpanit@amd.com, xiantao.zhang@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, February 8, 2013, 5:48:41 PM, you wrote:

>>>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:

>> ----- JBeulich@suse.com wrote:
>> 
>>> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> > A regression was reported on a class of broken firmware that c/s
>>> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
>>> 
>>> After some more thought on this and the comments we got
>>> regarding disabling the IOMMU in this situation altogether making
>>> things worse instead of better, I came to the conclusion that we
>>> can actually restrict the action in affected cases to just disabling
>>> interrupt remapping. That doesn't make the situation worse than
>>> prior to the XSA-36 fixes (where interrupt remapping didn't really
>>> protect domains from one another), but allows at least DMA
>>> isolation to still be utilized. Patch 3/2 below/attached.
>> 
>> But now users who don't examine log messages may not realize 
>> that interupt remapping is disabled and therefore the system can be
>> affected by XSA-36.

> Yes. We need to balance these against one another - I see pros
> and cons in both (and I don't mind dropping this additional patch
> if we collectively come to the conclusion that the way it is now -
> with the one earlier fix - is the better state). So I'm really
> interested in others' opinions.

One argument pro could be that linux seems to do the same (only disable interrupt remapping)

>> With current code (boot option to use global remapping table) users
>> are explicitly agreeing to allow for possibility of cross-domain interrupt
>> attack.
>> 
>> Also, I think it may not be a bad idea to have AMD folks test you earlier
>> patch on multi-IOMMU system (and simulate bad IVRS) to see how it behaves 
>> there.

And getting mainbord / bios manufactures actually support stuff .. instead of giving some nice disinformation.
Fresh from MSI techsupport:

Posted:         2013-02-09 00:11:38 (GMT+8),MSI
Content:        CPU virtualization (SVM) should be possible on the 890FXA-GD70. I/O virtualization (IOMMU) is support on the MSI's AMD 900-series. IOMMU will not be possible on MSI's AMD 800 series.

In short .. buy a new mainboard and pray .. pray hard .. that it works out of the box

> That would indeed be very desirable.

> Jan





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:25:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:25: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 1U3rh4-0006PX-Fc; Fri, 08 Feb 2013 17:24:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh2-0006P8-Lf
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:56 +0000
Received: from [85.158.143.99:53203] by server-3.bemta-4.messagelabs.com id
	7A/D9-08920-7E435115; Fri, 08 Feb 2013 17:24:55 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20636 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:56 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: dd920505264c49fea734fa76d2e07ac6c5e4070e
Message-ID: <dd920505264c49fea734.1360344252@makatos-desktop>
In-Reply-To: <patchbomb.1360344251@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:12 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] blktap3/libxl: add new device kind and
	disk back-end
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 use new identifiers so that blktap2 and blktap3 can co-exist.

diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Feb 08 17:23:23 2013 +0000
@@ -58,6 +58,7 @@ libxl_disk_backend = Enumeration("disk_b
     (1, "PHY"),
     (2, "TAP"),
     (3, "QDISK"),
+    (4, "TAP3"),
     ])
 
 libxl_nic_type = Enumeration("nic_type", [
diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxl_types_internal.idl	Fri Feb 08 17:23:23 2013 +0000
@@ -20,6 +20,7 @@ libxl__device_kind = Enumeration("device
     (6, "VKBD"),
     (7, "CONSOLE"),
     (8, "VTPM"),
+    (9, "VBD3"),
     ])
 
 libxl__console_backend = Enumeration("console_backend", [
diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxlu_disk_l.c
--- a/tools/libxl/libxlu_disk_l.c	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxlu_disk_l.c	Fri Feb 08 17:23:23 2013 +0000
@@ -852,6 +852,7 @@ static void setformat(DiskParseContext *
 static void setbackendtype(DiskParseContext *dpc, const char *str) {
     if (     !strcmp(str,"phy"))   DSET(dpc,backend,BACKEND,str,PHY);
     else if (!strcmp(str,"tap"))   DSET(dpc,backend,BACKEND,str,TAP);
+    else if (!strcmp(str,"tap3"))   DSET(dpc,backend,BACKEND,str,TAP3);
     else if (!strcmp(str,"qdisk")) DSET(dpc,backend,BACKEND,str,QDISK);
     else xlu__disk_err(dpc,str,"unknown value for backendtype");
 }
diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxlu_disk_l.l
--- a/tools/libxl/libxlu_disk_l.l	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxlu_disk_l.l	Fri Feb 08 17:23:23 2013 +0000
@@ -109,6 +109,7 @@ static void setformat(DiskParseContext *
 static void setbackendtype(DiskParseContext *dpc, const char *str) {
     if (     !strcmp(str,"phy"))   DSET(dpc,backend,BACKEND,str,PHY);
     else if (!strcmp(str,"tap"))   DSET(dpc,backend,BACKEND,str,TAP);
+    else if (!strcmp(str,"tap3"))   DSET(dpc,backend,BACKEND,str,TAP3);
     else if (!strcmp(str,"qdisk")) DSET(dpc,backend,BACKEND,str,QDISK);
     else xlu__disk_err(dpc,str,"unknown value for backendtype");
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:25:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:25: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 1U3rh4-0006PX-Fc; Fri, 08 Feb 2013 17:24:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh2-0006P8-Lf
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:56 +0000
Received: from [85.158.143.99:53203] by server-3.bemta-4.messagelabs.com id
	7A/D9-08920-7E435115; Fri, 08 Feb 2013 17:24:55 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20636 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:56 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: dd920505264c49fea734fa76d2e07ac6c5e4070e
Message-ID: <dd920505264c49fea734.1360344252@makatos-desktop>
In-Reply-To: <patchbomb.1360344251@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:12 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] blktap3/libxl: add new device kind and
	disk back-end
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 use new identifiers so that blktap2 and blktap3 can co-exist.

diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Feb 08 17:23:23 2013 +0000
@@ -58,6 +58,7 @@ libxl_disk_backend = Enumeration("disk_b
     (1, "PHY"),
     (2, "TAP"),
     (3, "QDISK"),
+    (4, "TAP3"),
     ])
 
 libxl_nic_type = Enumeration("nic_type", [
diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxl_types_internal.idl	Fri Feb 08 17:23:23 2013 +0000
@@ -20,6 +20,7 @@ libxl__device_kind = Enumeration("device
     (6, "VKBD"),
     (7, "CONSOLE"),
     (8, "VTPM"),
+    (9, "VBD3"),
     ])
 
 libxl__console_backend = Enumeration("console_backend", [
diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxlu_disk_l.c
--- a/tools/libxl/libxlu_disk_l.c	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxlu_disk_l.c	Fri Feb 08 17:23:23 2013 +0000
@@ -852,6 +852,7 @@ static void setformat(DiskParseContext *
 static void setbackendtype(DiskParseContext *dpc, const char *str) {
     if (     !strcmp(str,"phy"))   DSET(dpc,backend,BACKEND,str,PHY);
     else if (!strcmp(str,"tap"))   DSET(dpc,backend,BACKEND,str,TAP);
+    else if (!strcmp(str,"tap3"))   DSET(dpc,backend,BACKEND,str,TAP3);
     else if (!strcmp(str,"qdisk")) DSET(dpc,backend,BACKEND,str,QDISK);
     else xlu__disk_err(dpc,str,"unknown value for backendtype");
 }
diff -r 6c1b12c884b4 -r dd920505264c tools/libxl/libxlu_disk_l.l
--- a/tools/libxl/libxlu_disk_l.l	Tue Feb 05 15:47:41 2013 +0000
+++ b/tools/libxl/libxlu_disk_l.l	Fri Feb 08 17:23:23 2013 +0000
@@ -109,6 +109,7 @@ static void setformat(DiskParseContext *
 static void setbackendtype(DiskParseContext *dpc, const char *str) {
     if (     !strcmp(str,"phy"))   DSET(dpc,backend,BACKEND,str,PHY);
     else if (!strcmp(str,"tap"))   DSET(dpc,backend,BACKEND,str,TAP);
+    else if (!strcmp(str,"tap3"))   DSET(dpc,backend,BACKEND,str,TAP3);
     else if (!strcmp(str,"qdisk")) DSET(dpc,backend,BACKEND,str,QDISK);
     else xlu__disk_err(dpc,str,"unknown value for backendtype");
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:25:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:25: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 1U3rh3-0006PM-2W; Fri, 08 Feb 2013 17:24:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh2-0006P8-9W
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:56 +0000
Received: from [85.158.143.99:53202] by server-3.bemta-4.messagelabs.com id
	2A/D9-08920-7E435115; Fri, 08 Feb 2013 17:24:55 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20628 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:55 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:54 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:11 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] blktap3/libxl: add support for blktap3
	in 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 patch series implements support for blktap3 in libxl.

Supporting blktap3 requires rather few changes:
1. We introduce a new disk back-end type (TAP3) and a new device kind (VBD3) to
   allow blktap3 to co-exist with blktap3. blktap2 remains the default back-end
   for tap devices. Switching in the future to blktap3 as the default handler
   of tap devices should be trivial.
2. libxl doesn't spawn the tapdisk process any more, as is the case for
   blktap2, since the tapback daemon is responsible for that. Thus, libxl only
   needs to write to XenStore the file/partition/whatever backing the virtual
   disk so that the tapback daemon can pass it to tapdisk.
3. Since there is no block device in dom0 any more, pygrub won't be able to
   boot from VHD files. To get around this problem, pygrub can use the NBD
   functionality (existing in blktap2.5): it can explicitly ask tapback to
   create a NDB in order to access the virtual disk. This functionality will be
   implemented in a future patch series. However, this will only work for Linux
   dom0's. As a generic solution that would work on any dom0, we could
   implement a simple protocol for data exchange between pygrub and tapdisk.

Signed-off-by: Thanos Makatos <thanos.makatos@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 Feb 08 17:25:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17:25: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 1U3rh3-0006PM-2W; Fri, 08 Feb 2013 17:24:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh2-0006P8-9W
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:56 +0000
Received: from [85.158.143.99:53202] by server-3.bemta-4.messagelabs.com id
	2A/D9-08920-7E435115; Fri, 08 Feb 2013 17:24:55 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20628 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:55 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:54 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:11 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] blktap3/libxl: add support for blktap3
	in 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 patch series implements support for blktap3 in libxl.

Supporting blktap3 requires rather few changes:
1. We introduce a new disk back-end type (TAP3) and a new device kind (VBD3) to
   allow blktap3 to co-exist with blktap3. blktap2 remains the default back-end
   for tap devices. Switching in the future to blktap3 as the default handler
   of tap devices should be trivial.
2. libxl doesn't spawn the tapdisk process any more, as is the case for
   blktap2, since the tapback daemon is responsible for that. Thus, libxl only
   needs to write to XenStore the file/partition/whatever backing the virtual
   disk so that the tapback daemon can pass it to tapdisk.
3. Since there is no block device in dom0 any more, pygrub won't be able to
   boot from VHD files. To get around this problem, pygrub can use the NBD
   functionality (existing in blktap2.5): it can explicitly ask tapback to
   create a NDB in order to access the virtual disk. This functionality will be
   implemented in a future patch series. However, this will only work for Linux
   dom0's. As a generic solution that would work on any dom0, we could
   implement a simple protocol for data exchange between pygrub and tapdisk.

Signed-off-by: Thanos Makatos <thanos.makatos@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 Feb 08 17:25:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rh4-0006Pg-Qn; Fri, 08 Feb 2013 17:24:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh2-0006P9-Ob
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:56 +0000
Received: from [85.158.143.99:53224] by server-1.bemta-4.messagelabs.com id
	45/6B-08839-8E435115; Fri, 08 Feb 2013 17:24:56 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!3
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20660 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:56 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: dd63f2992e71a1e43abf0ea6047a3b0cdf988d6b
Message-ID: <dd63f2992e71a1e43abf.1360344253@makatos-desktop>
In-Reply-To: <patchbomb.1360344251@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:13 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3 is
	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 implements function libxl__blktap3_enabled, the equivalent of the
existing libxl__blktap_enabled for blktap2. The checks performed are rather
simple and should be extended.

diff -r dd920505264c -r dd63f2992e71 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Feb 08 17:23:23 2013 +0000
+++ b/tools/libxl/Makefile	Fri Feb 08 17:23:25 2013 +0000
@@ -37,8 +37,10 @@ LIBXLU_LIBS =
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
 ifeq ($(LIBXL_BLKTAP),y)
 LIBXL_OBJS-y += libxl_blktap2.o
+LIBXL_OBJS-y += libxl_blktap3.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
+LIBXL_OBJS-y += libxl_noblktap3.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
diff -r dd920505264c -r dd63f2992e71 tools/libxl/libxl_blktap3.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_blktap3.c	Fri Feb 08 17:23:25 2013 +0000
@@ -0,0 +1,60 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * 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
+ * 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.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+
+/* FIXME get the tapback name from blktap3 instead of hard-coding */
+#define TAPBACK_NAME "tapback"
+#define CMD "pidof " TAPBACK_NAME
+
+/*
+ * Simple sanity checks. Most of these checks are not race-free (e.g. checking
+ * wether the tapdisk binary exists), but at least we get some protection
+ * against spectacularly silly mistakes.
+ *
+ * We don't check whether the tapdisk binary exists as this is done by the
+ * tapback daemon.
+ */
+int libxl__blktap3_enabled(libxl__gc *gc)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int err;
+
+    /*
+     * Check whether the tapback daemon is running.
+     */
+    err = system(CMD);
+    if (err == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                "failed to check whether the tapback daemon is running\n");
+        return 0;
+    }
+    err = WEXITSTATUS(err);
+    if (err != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "tapback daemon not running\n");
+        return 0;
+    }
+
+    /*
+     * TODO Check for evtchn, gntdev. How do we do that!?
+     */
+
+    return 1;
+}
diff -r dd920505264c -r dd63f2992e71 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Feb 08 17:23:23 2013 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Feb 08 17:23:25 2013 +0000
@@ -1337,6 +1337,14 @@ struct libxl__cpuid_policy {
 };
 
 /*
+ * blktap3 support
+ */
+/* libxl__blktap_enabled:
+ *    return true if blktap3 support is available.
+ */
+_hidden int libxl__blktap3_enabled(libxl__gc *gc);
+
+/*
  * blktap2 support
  */
 
diff -r dd920505264c -r dd63f2992e71 tools/libxl/libxl_noblktap3.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_noblktap3.c	Fri Feb 08 17:23:25 2013 +0000
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * 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
+ * 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.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+
+int libxl__blktap3_enabled(libxl__gc *gc)
+{
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:25:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rh4-0006Pg-Qn; Fri, 08 Feb 2013 17:24:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh2-0006P9-Ob
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:56 +0000
Received: from [85.158.143.99:53224] by server-1.bemta-4.messagelabs.com id
	45/6B-08839-8E435115; Fri, 08 Feb 2013 17:24:56 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!3
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20660 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:56 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: dd63f2992e71a1e43abf0ea6047a3b0cdf988d6b
Message-ID: <dd63f2992e71a1e43abf.1360344253@makatos-desktop>
In-Reply-To: <patchbomb.1360344251@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:13 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3 is
	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 implements function libxl__blktap3_enabled, the equivalent of the
existing libxl__blktap_enabled for blktap2. The checks performed are rather
simple and should be extended.

diff -r dd920505264c -r dd63f2992e71 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Feb 08 17:23:23 2013 +0000
+++ b/tools/libxl/Makefile	Fri Feb 08 17:23:25 2013 +0000
@@ -37,8 +37,10 @@ LIBXLU_LIBS =
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
 ifeq ($(LIBXL_BLKTAP),y)
 LIBXL_OBJS-y += libxl_blktap2.o
+LIBXL_OBJS-y += libxl_blktap3.o
 else
 LIBXL_OBJS-y += libxl_noblktap2.o
+LIBXL_OBJS-y += libxl_noblktap3.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
diff -r dd920505264c -r dd63f2992e71 tools/libxl/libxl_blktap3.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_blktap3.c	Fri Feb 08 17:23:25 2013 +0000
@@ -0,0 +1,60 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * 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
+ * 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.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+
+/* FIXME get the tapback name from blktap3 instead of hard-coding */
+#define TAPBACK_NAME "tapback"
+#define CMD "pidof " TAPBACK_NAME
+
+/*
+ * Simple sanity checks. Most of these checks are not race-free (e.g. checking
+ * wether the tapdisk binary exists), but at least we get some protection
+ * against spectacularly silly mistakes.
+ *
+ * We don't check whether the tapdisk binary exists as this is done by the
+ * tapback daemon.
+ */
+int libxl__blktap3_enabled(libxl__gc *gc)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int err;
+
+    /*
+     * Check whether the tapback daemon is running.
+     */
+    err = system(CMD);
+    if (err == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                "failed to check whether the tapback daemon is running\n");
+        return 0;
+    }
+    err = WEXITSTATUS(err);
+    if (err != 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "tapback daemon not running\n");
+        return 0;
+    }
+
+    /*
+     * TODO Check for evtchn, gntdev. How do we do that!?
+     */
+
+    return 1;
+}
diff -r dd920505264c -r dd63f2992e71 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Feb 08 17:23:23 2013 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Feb 08 17:23:25 2013 +0000
@@ -1337,6 +1337,14 @@ struct libxl__cpuid_policy {
 };
 
 /*
+ * blktap3 support
+ */
+/* libxl__blktap_enabled:
+ *    return true if blktap3 support is available.
+ */
+_hidden int libxl__blktap3_enabled(libxl__gc *gc);
+
+/*
  * blktap2 support
  */
 
diff -r dd920505264c -r dd63f2992e71 tools/libxl/libxl_noblktap3.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_noblktap3.c	Fri Feb 08 17:23:25 2013 +0000
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2012      Citrix Ltd.
+ *
+ * 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
+ * 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.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+
+int libxl__blktap3_enabled(libxl__gc *gc)
+{
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:25:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rh5-0006Pq-6W; Fri, 08 Feb 2013 17:24:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh3-0006P8-1Y
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:57 +0000
Received: from [85.158.143.99:53231] by server-3.bemta-4.messagelabs.com id
	1C/D9-08920-8E435115; Fri, 08 Feb 2013 17:24:56 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!4
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20670 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:56 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6b54db4abe1276e1003dcff629ca5165f45ab92f
Message-ID: <6b54db4abe1276e1003d.1360344254@makatos-desktop>
In-Reply-To: <patchbomb.1360344251@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:14 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3 device in
	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

Handling of blktap3 devices is similar to blktap2, except that libxl doesn't
spawn the tapdisk and doesn't create the physical device in dom0.

diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Feb 08 17:23:25 2013 +0000
+++ b/tools/libxl/libxl.c	Fri Feb 08 17:23:26 2013 +0000
@@ -1158,6 +1158,8 @@ static void disk_eject_xswatch_callback(
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
         disk->backend = LIBXL_DISK_BACKEND_QDISK;
+    } else if (!strcmp(backend_type, "tap3")) {
+        disk->backend = LIBXL_DISK_BACKEND_TAP3;
     } else {
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
@@ -1998,6 +2000,9 @@ int libxl__device_from_disk(libxl__gc *g
         case LIBXL_DISK_BACKEND_QDISK:
             device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
             break;
+        case LIBXL_DISK_BACKEND_TAP3:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD3;
+            break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
                        disk->backend);
@@ -2113,6 +2118,12 @@ static void device_disk_add(libxl__egc *
 
                 /* now create a phy device to export the device to the guest */
                 goto do_backend_phy;
+            case LIBXL_DISK_BACKEND_TAP3:
+                flexarray_append(back, "params");
+                flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                    libxl__device_disk_string_of_format(disk->format),
+                    disk->pdev_path));
+                break;
             case LIBXL_DISK_BACKEND_QDISK:
                 flexarray_append(back, "params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Feb 08 17:23:25 2013 +0000
+++ b/tools/libxl/libxl_device.c	Fri Feb 08 17:23:26 2013 +0000
@@ -190,6 +190,23 @@ static int disk_try_backend(disk_try_bac
         }
         return backend;
 
+    case LIBXL_DISK_BACKEND_TAP3:
+        /* TODO What's that script thing? */
+        if (a->disk->script) goto bad_script;
+
+        if (!libxl__blktap3_enabled(a->gc)) {
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
+                       " unsuitable because blktap3 not available",
+                       a->disk->vdev);
+            return 0;
+        }
+        /* TODO other formats supported by blktap3? */
+        if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
+              a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
+            goto bad_format;
+        }
+        return backend;
+
     case LIBXL_DISK_BACKEND_QDISK:
         if (a->disk->script) goto bad_script;
         return backend;
@@ -258,6 +275,7 @@ int libxl__device_disk_set_backend(libxl
         ok=
             disk_try_backend(&a, LIBXL_DISK_BACKEND_PHY) ?:
             disk_try_backend(&a, LIBXL_DISK_BACKEND_TAP) ?:
+            disk_try_backend(&a, LIBXL_DISK_BACKEND_TAP3) ?:
             disk_try_backend(&a, LIBXL_DISK_BACKEND_QDISK);
         if (ok)
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, using backend %s",
@@ -290,6 +308,7 @@ char *libxl__device_disk_string_of_backe
     switch (backend) {
         case LIBXL_DISK_BACKEND_QDISK: return "qdisk";
         case LIBXL_DISK_BACKEND_TAP: return "phy";
+        case LIBXL_DISK_BACKEND_TAP3: return "phy";
         case LIBXL_DISK_BACKEND_PHY: return "phy";
         default: return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 17:25:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 17: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 1U3rh5-0006Pq-6W; Fri, 08 Feb 2013 17:24:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U3rh3-0006P8-1Y
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 17:24:57 +0000
Received: from [85.158.143.99:53231] by server-3.bemta-4.messagelabs.com id
	1C/D9-08920-8E435115; Fri, 08 Feb 2013 17:24:56 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360344295!21730749!4
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20670 invoked from network); 8 Feb 2013 17:24:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 17:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1290762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 17:24:56 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1; Fri, 8 Feb 2013
	17:24:55 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6b54db4abe1276e1003dcff629ca5165f45ab92f
Message-ID: <6b54db4abe1276e1003d.1360344254@makatos-desktop>
In-Reply-To: <patchbomb.1360344251@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Fri, 8 Feb 2013 17:24:14 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: xen-devel@lists.xensource.com
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3 device in
	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

Handling of blktap3 devices is similar to blktap2, except that libxl doesn't
spawn the tapdisk and doesn't create the physical device in dom0.

diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Feb 08 17:23:25 2013 +0000
+++ b/tools/libxl/libxl.c	Fri Feb 08 17:23:26 2013 +0000
@@ -1158,6 +1158,8 @@ static void disk_eject_xswatch_callback(
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
         disk->backend = LIBXL_DISK_BACKEND_QDISK;
+    } else if (!strcmp(backend_type, "tap3")) {
+        disk->backend = LIBXL_DISK_BACKEND_TAP3;
     } else {
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
@@ -1998,6 +2000,9 @@ int libxl__device_from_disk(libxl__gc *g
         case LIBXL_DISK_BACKEND_QDISK:
             device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
             break;
+        case LIBXL_DISK_BACKEND_TAP3:
+            device->backend_kind = LIBXL__DEVICE_KIND_VBD3;
+            break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n",
                        disk->backend);
@@ -2113,6 +2118,12 @@ static void device_disk_add(libxl__egc *
 
                 /* now create a phy device to export the device to the guest */
                 goto do_backend_phy;
+            case LIBXL_DISK_BACKEND_TAP3:
+                flexarray_append(back, "params");
+                flexarray_append(back, libxl__sprintf(gc, "%s:%s",
+                    libxl__device_disk_string_of_format(disk->format),
+                    disk->pdev_path));
+                break;
             case LIBXL_DISK_BACKEND_QDISK:
                 flexarray_append(back, "params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Feb 08 17:23:25 2013 +0000
+++ b/tools/libxl/libxl_device.c	Fri Feb 08 17:23:26 2013 +0000
@@ -190,6 +190,23 @@ static int disk_try_backend(disk_try_bac
         }
         return backend;
 
+    case LIBXL_DISK_BACKEND_TAP3:
+        /* TODO What's that script thing? */
+        if (a->disk->script) goto bad_script;
+
+        if (!libxl__blktap3_enabled(a->gc)) {
+            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
+                       " unsuitable because blktap3 not available",
+                       a->disk->vdev);
+            return 0;
+        }
+        /* TODO other formats supported by blktap3? */
+        if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
+              a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
+            goto bad_format;
+        }
+        return backend;
+
     case LIBXL_DISK_BACKEND_QDISK:
         if (a->disk->script) goto bad_script;
         return backend;
@@ -258,6 +275,7 @@ int libxl__device_disk_set_backend(libxl
         ok=
             disk_try_backend(&a, LIBXL_DISK_BACKEND_PHY) ?:
             disk_try_backend(&a, LIBXL_DISK_BACKEND_TAP) ?:
+            disk_try_backend(&a, LIBXL_DISK_BACKEND_TAP3) ?:
             disk_try_backend(&a, LIBXL_DISK_BACKEND_QDISK);
         if (ok)
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, using backend %s",
@@ -290,6 +308,7 @@ char *libxl__device_disk_string_of_backe
     switch (backend) {
         case LIBXL_DISK_BACKEND_QDISK: return "qdisk";
         case LIBXL_DISK_BACKEND_TAP: return "phy";
+        case LIBXL_DISK_BACKEND_TAP3: return "phy";
         case LIBXL_DISK_BACKEND_PHY: return "phy";
         default: return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 18:49:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 18: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 1U3t02-0001aE-Ib; Fri, 08 Feb 2013 18:48:38 +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 1U3t00-0001a9-Qj
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 18:48:37 +0000
Received: from [85.158.137.99:63418] by server-3.bemta-3.messagelabs.com id
	87/81-31070-F7845115; Fri, 08 Feb 2013 18:48:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360349310!20528584!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8629 invoked from network); 8 Feb 2013 18:48:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 18:48:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1292677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 18:48: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.297.1; Fri, 8 Feb 2013 18:48:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3szt-00050z-Dj;
	Fri, 08 Feb 2013 18:48:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3szt-0002em-Cm;
	Fri, 08 Feb 2013 18:48:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15449-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 18:48:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 15449: 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 15449 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15449/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15426
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 15426

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  130446135528
baseline version:
 xen                  e5ed73d172eb

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=130446135528
+ . 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 130446135528
+ branch=xen-4.1-testing
+ revision=130446135528
+ . 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/hg/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 130446135528 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 2 changesets with 2 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 Fri Feb 08 18:49:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 18: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 1U3t02-0001aE-Ib; Fri, 08 Feb 2013 18:48:38 +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 1U3t00-0001a9-Qj
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 18:48:37 +0000
Received: from [85.158.137.99:63418] by server-3.bemta-3.messagelabs.com id
	87/81-31070-F7845115; Fri, 08 Feb 2013 18:48:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360349310!20528584!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8629 invoked from network); 8 Feb 2013 18:48:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 18:48:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1292677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 18:48: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.297.1; Fri, 8 Feb 2013 18:48:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3szt-00050z-Dj;
	Fri, 08 Feb 2013 18:48:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3szt-0002em-Cm;
	Fri, 08 Feb 2013 18:48:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15449-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 8 Feb 2013 18:48:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 15449: 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 15449 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15449/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15426
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 15426

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  130446135528
baseline version:
 xen                  e5ed73d172eb

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=130446135528
+ . 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 130446135528
+ branch=xen-4.1-testing
+ revision=130446135528
+ . 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/hg/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 130446135528 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 2 changesets with 2 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 Fri Feb 08 19:29:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 19:29: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 1U3td7-00031X-5v; Fri, 08 Feb 2013 19:29:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yinghai@kernel.org>) id 1U3td5-00031S-S0
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 19:29:00 +0000
Received: from [85.158.137.99:49925] by server-4.bemta-3.messagelabs.com id
	A3/F5-12802-6F155115; Fri, 08 Feb 2013 19:28:54 +0000
X-Env-Sender: yinghai@kernel.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360351732!19789479!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjQzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11242 invoked from network); 8 Feb 2013 19:28:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 19:28:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r18JSccC031625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Feb 2013 19:28:38 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
	r18JSbLq023690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 19:28:37 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
	r18JSaap006719; Fri, 8 Feb 2013 13:28:36 -0600
Received: from linux-siqj.site (/10.132.127.230)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Feb 2013 11:28:36 -0800
From: Yinghai Lu <yinghai@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>, Bjorn Helgaas <bhelgaas@google.com>, 
	"Rafael J. Wysocki" <rjw@sisk.pl>
Date: Fri,  8 Feb 2013 11:28:12 -0800
Message-Id: <1360351703-20571-16-git-send-email-yinghai@kernel.org>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360351703-20571-1-git-send-email-yinghai@kernel.org>
References: <1360351703-20571-1-git-send-email-yinghai@kernel.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	Yinghai Lu <yinghai@kernel.org>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v2 15/26] xen,
	irq: call irq_realloc_desc_at() at 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>
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 will pre-reserve irq for all gsi at first for x86, so we have to
use realloc with it.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
---
 drivers/xen/events.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..dda38db 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -482,8 +482,12 @@ static int __must_check xen_allocate_irq_gsi(unsigned gsi)
 	/* Legacy IRQ descriptors are already allocated by the arch. */
 	if (gsi < NR_IRQS_LEGACY)
 		irq = gsi;
-	else
-		irq = irq_alloc_desc_at(gsi, -1);
+	else {
+		/* for x86, irq already get reserved for gsi */
+		irq = irq_realloc_desc_at(gsi, -1);
+		if (irq < 0)
+			irq = irq_alloc_desc_at(gsi, -1);
+	}
 
 	xen_irq_init(irq);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 19:29:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 19:29: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 1U3td7-00031X-5v; Fri, 08 Feb 2013 19:29:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yinghai@kernel.org>) id 1U3td5-00031S-S0
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 19:29:00 +0000
Received: from [85.158.137.99:49925] by server-4.bemta-3.messagelabs.com id
	A3/F5-12802-6F155115; Fri, 08 Feb 2013 19:28:54 +0000
X-Env-Sender: yinghai@kernel.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360351732!19789479!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjQzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11242 invoked from network); 8 Feb 2013 19:28:54 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 19:28:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r18JSccC031625
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Feb 2013 19:28:38 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
	r18JSbLq023690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 19:28:37 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
	r18JSaap006719; Fri, 8 Feb 2013 13:28:36 -0600
Received: from linux-siqj.site (/10.132.127.230)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Feb 2013 11:28:36 -0800
From: Yinghai Lu <yinghai@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>, Bjorn Helgaas <bhelgaas@google.com>, 
	"Rafael J. Wysocki" <rjw@sisk.pl>
Date: Fri,  8 Feb 2013 11:28:12 -0800
Message-Id: <1360351703-20571-16-git-send-email-yinghai@kernel.org>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360351703-20571-1-git-send-email-yinghai@kernel.org>
References: <1360351703-20571-1-git-send-email-yinghai@kernel.org>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	Yinghai Lu <yinghai@kernel.org>, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v2 15/26] xen,
	irq: call irq_realloc_desc_at() at 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>
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 will pre-reserve irq for all gsi at first for x86, so we have to
use realloc with it.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
---
 drivers/xen/events.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..dda38db 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -482,8 +482,12 @@ static int __must_check xen_allocate_irq_gsi(unsigned gsi)
 	/* Legacy IRQ descriptors are already allocated by the arch. */
 	if (gsi < NR_IRQS_LEGACY)
 		irq = gsi;
-	else
-		irq = irq_alloc_desc_at(gsi, -1);
+	else {
+		/* for x86, irq already get reserved for gsi */
+		irq = irq_realloc_desc_at(gsi, -1);
+		if (irq < 0)
+			irq = irq_alloc_desc_at(gsi, -1);
+	}
 
 	xen_irq_init(irq);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 19:45:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 19:45: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 1U3tt1-0003QJ-PK; Fri, 08 Feb 2013 19:45:27 +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 1U3tsz-0003Nz-Lt
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 19:45:25 +0000
Received: from [85.158.143.99:8108] by server-2.bemta-4.messagelabs.com id
	30/25-01597-5D555115; Fri, 08 Feb 2013 19:45:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360352722!30495807!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11983 invoked from network); 8 Feb 2013 19:45:24 -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;
	8 Feb 2013 19:45:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6516739"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 19:45:22 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Fri, 8 Feb 2013
	14:45:21 -0500
Message-ID: <511555D0.5010208@citrix.com>
Date: Fri, 8 Feb 2013 19:45:20 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>	<1360085020.7477.167.camel@zion.uk.xensource.com>	<20130206165709.GC24458@konrad-lan.dumpdata.com>	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>	<1360238260.2536.22.camel@zion.uk.xensource.com>	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>	<1360340574.29432.70.camel@zakaz.uk.xensource.com>	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>	<20130208164936.GB93591@ocelot.phlegethon.org>	<1360342741.29432.85.camel@zakaz.uk.xensource.com>	<20130208170630.GE93591@ocelot.phlegethon.org>
	<1360343378.29432.89.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360343378.29432.89.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 08/02/13 17:09, Ian Campbell wrote:
> 
> Actually, Stefano and I were discussing this the other day, the use of
> unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
> should be fixed -- using xen_ulong_t would fix this too...

Keep in mind that it must be possible to do an atomic xchg() on the
vcpu_info's evtchn_pending_sel word.  I don't think 64-bit words will
work with a 32-bit ARM guest.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 19:45:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 19:45: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 1U3tt1-0003QJ-PK; Fri, 08 Feb 2013 19:45:27 +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 1U3tsz-0003Nz-Lt
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 19:45:25 +0000
Received: from [85.158.143.99:8108] by server-2.bemta-4.messagelabs.com id
	30/25-01597-5D555115; Fri, 08 Feb 2013 19:45:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360352722!30495807!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11983 invoked from network); 8 Feb 2013 19:45:24 -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;
	8 Feb 2013 19:45:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="6516739"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	08 Feb 2013 19:45:22 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1; Fri, 8 Feb 2013
	14:45:21 -0500
Message-ID: <511555D0.5010208@citrix.com>
Date: Fri, 8 Feb 2013 19:45:20 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>	<1360085020.7477.167.camel@zion.uk.xensource.com>	<20130206165709.GC24458@konrad-lan.dumpdata.com>	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>	<1360238260.2536.22.camel@zion.uk.xensource.com>	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>	<1360340574.29432.70.camel@zakaz.uk.xensource.com>	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>	<20130208164936.GB93591@ocelot.phlegethon.org>	<1360342741.29432.85.camel@zakaz.uk.xensource.com>	<20130208170630.GE93591@ocelot.phlegethon.org>
	<1360343378.29432.89.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360343378.29432.89.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 08/02/13 17:09, Ian Campbell wrote:
> 
> Actually, Stefano and I were discussing this the other day, the use of
> unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
> should be fixed -- using xen_ulong_t would fix this too...

Keep in mind that it must be possible to do an atomic xchg() on the
vcpu_info's evtchn_pending_sel word.  I don't think 64-bit words will
work with a 32-bit ARM guest.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 19:55:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 19:55: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 1U3u2N-0004Ce-Rs; Fri, 08 Feb 2013 19:55: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 1U3u2M-0004CZ-Pj
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 19:55:07 +0000
Received: from [85.158.138.51:18400] by server-16.bemta-3.messagelabs.com id
	47/4A-02727-91855115; Fri, 08 Feb 2013 19:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360353303!8851729!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15318 invoked from network); 8 Feb 2013 19:55:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 19:55:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1294212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 19:55:03 +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.297.1; Fri, 8 Feb 2013
	19:55:03 +0000
Message-ID: <1360353302.9063.67.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 8 Feb 2013 19:55:02 +0000
In-Reply-To: <511555D0.5010208@citrix.com>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
	<1360342741.29432.85.camel@zakaz.uk.xensource.com>
	<20130208170630.GE93591@ocelot.phlegethon.org>
	<1360343378.29432.89.camel@zakaz.uk.xensource.com>
	<511555D0.5010208@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 19:45 +0000, David Vrabel wrote:
> On 08/02/13 17:09, Ian Campbell wrote:
> > 
> > Actually, Stefano and I were discussing this the other day, the use of
> > unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
> > should be fixed -- using xen_ulong_t would fix this too...
> 
> Keep in mind that it must be possible to do an atomic xchg() on the
> vcpu_info's evtchn_pending_sel word.  I don't think 64-bit words will
> work with a 32-bit ARM guest.

ARM (at least the variants we care about) has load/store exclusive,
including a double word sized option (ldrexd/strexd), so this is fine.

I think the double word variants were introduced along with LPAE, so you
can update a PTE atomically.

I also suspect it would be fine to treat a 64-bit word as two
independent 32-bit halves which must be accessed atomically, at least
for the purposes of updating the pending sel word(assumnig h/v and guest
agree on this), but thankfully due to the above I don't have to think
about it *too* hard to be sure ;-)

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 19:55:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 19:55: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 1U3u2N-0004Ce-Rs; Fri, 08 Feb 2013 19:55: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 1U3u2M-0004CZ-Pj
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 19:55:07 +0000
Received: from [85.158.138.51:18400] by server-16.bemta-3.messagelabs.com id
	47/4A-02727-91855115; Fri, 08 Feb 2013 19:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360353303!8851729!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15318 invoked from network); 8 Feb 2013 19:55:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 19:55:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; 
   d="scan'208";a="1294212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Feb 2013 19:55:03 +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.297.1; Fri, 8 Feb 2013
	19:55:03 +0000
Message-ID: <1360353302.9063.67.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 8 Feb 2013 19:55:02 +0000
In-Reply-To: <511555D0.5010208@citrix.com>
References: <20130205170006.GE2187@konrad-lan.dumpdata.com>
	<1360085020.7477.167.camel@zion.uk.xensource.com>
	<20130206165709.GC24458@konrad-lan.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022013F457554D9@LONPMAILBOX01.citrite.net>
	<1360238260.2536.22.camel@zion.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557B1@LONPMAILBOX01.citrite.net>
	<1360340574.29432.70.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022013F457557C0@LONPMAILBOX01.citrite.net>
	<20130208164936.GB93591@ocelot.phlegethon.org>
	<1360342741.29432.85.camel@zakaz.uk.xensource.com>
	<20130208170630.GE93591@ocelot.phlegethon.org>
	<1360343378.29432.89.camel@zakaz.uk.xensource.com>
	<511555D0.5010208@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 04/13] xen: sync public 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 Fri, 2013-02-08 at 19:45 +0000, David Vrabel wrote:
> On 08/02/13 17:09, Ian Campbell wrote:
> > 
> > Actually, Stefano and I were discussing this the other day, the use of
> > unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
> > should be fixed -- using xen_ulong_t would fix this too...
> 
> Keep in mind that it must be possible to do an atomic xchg() on the
> vcpu_info's evtchn_pending_sel word.  I don't think 64-bit words will
> work with a 32-bit ARM guest.

ARM (at least the variants we care about) has load/store exclusive,
including a double word sized option (ldrexd/strexd), so this is fine.

I think the double word variants were introduced along with LPAE, so you
can update a PTE atomically.

I also suspect it would be fine to treat a 64-bit word as two
independent 32-bit halves which must be accessed atomically, at least
for the purposes of updating the pending sel word(assumnig h/v and guest
agree on this), but thankfully due to the above I don't have to think
about it *too* hard to be sure ;-)

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 20:05:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:05: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 1U3uBk-0004UK-4O; Fri, 08 Feb 2013 20:04:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U3uBi-0004UF-Ny
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:04:46 +0000
Received: from [85.158.143.99:26571] by server-1.bemta-4.messagelabs.com id
	41/36-08839-E5A55115; Fri, 08 Feb 2013 20:04:46 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360353883!23874615!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23276 invoked from network); 8 Feb 2013 20:04:45 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 20:04:45 -0000
Received: by mail-ie0-f173.google.com with SMTP id 9so5519087iec.4
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 12:04:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=+gvBPPNdqsyep7+d4EfCmGQlvWa3d9CEPQXj7SY/6VE=;
	b=myUsPTnq7Fq4tWvsZ/47y+3kYlxPr/teIMFRVwYrpIKes2t20NS/pbsstml7v1jqwP
	vWiAro/k0iNM8bvYmqu/7RiebT6mmALtNX9nhPBnlAe6hVBWFYigr9mgyl9scTKVwD8u
	f2NULQEoE1uhmlk9US10SpxekEnEO3oze41IRmSasw0dbWvDt2YaFq68pRC7sJJcGg5A
	8EKHIOxPrfWnIlVXHM0P9rNdkgz82vztHSUHjP2qmXcgsZiQFY3LbHtCxIixOUuQOQlz
	PvwGED0H73HxPTm901KbZt0ANBqMSqAc0NxIWjPuWPZfsQszqUubIQQncdyqEc6o3wDB
	d5OQ==
MIME-Version: 1.0
X-Received: by 10.50.56.232 with SMTP id d8mr4914699igq.112.1360353883334;
	Fri, 08 Feb 2013 12:04:43 -0800 (PST)
Received: by 10.64.138.37 with HTTP; Fri, 8 Feb 2013 12:04:43 -0800 (PST)
In-Reply-To: <20130208133630.GA5304@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
	<83398C3BBF16693DB6E1E2CA@nimrod.local>
	<20130208133630.GA5304@aepfle.de>
Date: Fri, 8 Feb 2013 15:04:43 -0500
X-Google-Sender-Auth: o7BnCLA_gGCeMJBBxrIe674C9AE
Message-ID: <CACJDEmpQXeCaSgNWhZCdcEZotsUkQHJHUEVm2G=edsgaaL92AA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
	cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 8, 2013 at 8:36 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Feb 07, Alex Bligh wrote:
>
>>
>>
>> --On 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >You're heading in a slightly wrong direction here: You don't really
>> >care what features Xen know about or supports. What you do care
>> >about is what features your DomU-s get to see. And that's where
>> >the masking comes into play (and why this can be done on a per
>> >guest basis as well as at the host level).
>>
>> I want my domUs to see a no more than a fixed set of CPU flags
>> (obviously if those CPU flags aren't present, I don't want to
>> lie that they are). I have no visibility of what hardware my
>> software may be installed on in the future. EG if Intel introduces
>> a megawidget CPU flag and Xen adds support for it, I want to be
>> guaranteed this is masked out as it will break live migrate
>> between megawidget and non-megawidget compatible machines.
>
> I'm not sure what the question is, in a recent bug I had to disable
> popcnt because one of the hosts did not have it. So I came up with this
> config entry, which disables popcnt and sse4* bits:
>
> cpuid=[ '1:ecx=xxxxxxxx0xx00xxxxxxxxxxxxxxxxxxx' ]
>
> I think you have to read through the CPUID entry and set a few "required" bits
> and a few "common across your hardware zoo" bits to 1 and set everything else
> to 0 to handle the upcoming megawidget bit:
> http://en.wikipedia.org/wiki/CPUID
>
>
> If you use xend, you may need this patch to handle cpuid properly:
>
> Only add cpuid and cpuid_check to sexpr once
>
> When converting a XendConfig object to sexpr, cpuid and cpuid_check
> were being emitted twice in the resulting sexpr.  The first conversion
> writes incorrect sexpr, causing parsing of the sexpr to fail when xend
> is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
> are read and parsed.
>
> This patch skips the first conversion, and uses only the custom
> cpuid{_check} conversion methods called later.  It is not pretty, but
> is the least invasive fix in this complex code.


I recall seeing that libvirt had some of this figured out. It would
know which CPUID flags each CPU family had - and you could actually
set ('I am a Westmere CPU') or it would use the lowest common CPU
family support for all the guest.

Granted that means you need to know _which_ of the machines has the
lowest common CPU family first. Or you set the guest to say 'Core' .

Anyhow, perhaps looking at libvirt and implementing something similar
in 'xl' would be beneficial for these issues?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 20:05:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:05: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 1U3uBk-0004UK-4O; Fri, 08 Feb 2013 20:04:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U3uBi-0004UF-Ny
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:04:46 +0000
Received: from [85.158.143.99:26571] by server-1.bemta-4.messagelabs.com id
	41/36-08839-E5A55115; Fri, 08 Feb 2013 20:04:46 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360353883!23874615!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23276 invoked from network); 8 Feb 2013 20:04:45 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 20:04:45 -0000
Received: by mail-ie0-f173.google.com with SMTP id 9so5519087iec.4
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 12:04:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=+gvBPPNdqsyep7+d4EfCmGQlvWa3d9CEPQXj7SY/6VE=;
	b=myUsPTnq7Fq4tWvsZ/47y+3kYlxPr/teIMFRVwYrpIKes2t20NS/pbsstml7v1jqwP
	vWiAro/k0iNM8bvYmqu/7RiebT6mmALtNX9nhPBnlAe6hVBWFYigr9mgyl9scTKVwD8u
	f2NULQEoE1uhmlk9US10SpxekEnEO3oze41IRmSasw0dbWvDt2YaFq68pRC7sJJcGg5A
	8EKHIOxPrfWnIlVXHM0P9rNdkgz82vztHSUHjP2qmXcgsZiQFY3LbHtCxIixOUuQOQlz
	PvwGED0H73HxPTm901KbZt0ANBqMSqAc0NxIWjPuWPZfsQszqUubIQQncdyqEc6o3wDB
	d5OQ==
MIME-Version: 1.0
X-Received: by 10.50.56.232 with SMTP id d8mr4914699igq.112.1360353883334;
	Fri, 08 Feb 2013 12:04:43 -0800 (PST)
Received: by 10.64.138.37 with HTTP; Fri, 8 Feb 2013 12:04:43 -0800 (PST)
In-Reply-To: <20130208133630.GA5304@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
	<83398C3BBF16693DB6E1E2CA@nimrod.local>
	<20130208133630.GA5304@aepfle.de>
Date: Fri, 8 Feb 2013 15:04:43 -0500
X-Google-Sender-Auth: o7BnCLA_gGCeMJBBxrIe674C9AE
Message-ID: <CACJDEmpQXeCaSgNWhZCdcEZotsUkQHJHUEVm2G=edsgaaL92AA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
	cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 8, 2013 at 8:36 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Feb 07, Alex Bligh wrote:
>
>>
>>
>> --On 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >You're heading in a slightly wrong direction here: You don't really
>> >care what features Xen know about or supports. What you do care
>> >about is what features your DomU-s get to see. And that's where
>> >the masking comes into play (and why this can be done on a per
>> >guest basis as well as at the host level).
>>
>> I want my domUs to see a no more than a fixed set of CPU flags
>> (obviously if those CPU flags aren't present, I don't want to
>> lie that they are). I have no visibility of what hardware my
>> software may be installed on in the future. EG if Intel introduces
>> a megawidget CPU flag and Xen adds support for it, I want to be
>> guaranteed this is masked out as it will break live migrate
>> between megawidget and non-megawidget compatible machines.
>
> I'm not sure what the question is, in a recent bug I had to disable
> popcnt because one of the hosts did not have it. So I came up with this
> config entry, which disables popcnt and sse4* bits:
>
> cpuid=[ '1:ecx=xxxxxxxx0xx00xxxxxxxxxxxxxxxxxxx' ]
>
> I think you have to read through the CPUID entry and set a few "required" bits
> and a few "common across your hardware zoo" bits to 1 and set everything else
> to 0 to handle the upcoming megawidget bit:
> http://en.wikipedia.org/wiki/CPUID
>
>
> If you use xend, you may need this patch to handle cpuid properly:
>
> Only add cpuid and cpuid_check to sexpr once
>
> When converting a XendConfig object to sexpr, cpuid and cpuid_check
> were being emitted twice in the resulting sexpr.  The first conversion
> writes incorrect sexpr, causing parsing of the sexpr to fail when xend
> is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
> are read and parsed.
>
> This patch skips the first conversion, and uses only the custom
> cpuid{_check} conversion methods called later.  It is not pretty, but
> is the least invasive fix in this complex code.


I recall seeing that libvirt had some of this figured out. It would
know which CPUID flags each CPU family had - and you could actually
set ('I am a Westmere CPU') or it would use the lowest common CPU
family support for all the guest.

Granted that means you need to know _which_ of the machines has the
lowest common CPU family first. Or you set the guest to say 'Core' .

Anyhow, perhaps looking at libvirt and implementing something similar
in 'xl' would be beneficial for these issues?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 20:15:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:15: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 1U3uLM-0005C9-7z; Fri, 08 Feb 2013 20:14:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Suravee.Suthikulpanit@amd.com>) id 1U3uLK-0005C4-Ie
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:14:42 +0000
Received: from [85.158.138.51:39096] by server-8.bemta-3.messagelabs.com id
	9C/E5-25687-1BC55115; Fri, 08 Feb 2013 20:14:41 +0000
X-Env-Sender: Suravee.Suthikulpanit@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360354478!29456225!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5983 invoked from network); 8 Feb 2013 20:14:40 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Feb 2013 20:14:40 -0000
Received: from mail80-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 20:14:38 +0000
Received: from mail80-tx2 (localhost [127.0.0.1])	by mail80-tx2-R.bigfish.com
	(Postfix) with ESMTP id F0E252A0324;
	Fri,  8 Feb 2013 20:14:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI98dI9371I2a2cM1432I179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ah8275dhz2dh668h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h1155h)
Received: from mail80-tx2 (localhost.localdomain [127.0.0.1]) by mail80-tx2
	(MessageSwitch) id 1360354476474563_4717;
	Fri,  8 Feb 2013 20:14:36 +0000 (UTC)
Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.237])	by
	mail80-tx2.bigfish.com (Postfix) with ESMTP id 66D9E48004A;
	Fri,  8 Feb 2013 20:14:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 20:14:35 +0000
X-WSS-ID: 0MHX48A-02-0NT-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 2F6B8C8003;	Fri,  8 Feb 2013 14:14:33 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Feb 2013 14:14:14 -0600
Received: from [10.236.48.55] (10.236.48.55) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server id 14.2.328.9; Fri, 8 Feb 2013
	14:14:35 -0600
Message-ID: <51155CAB.7010600@amd.com>
Date: Fri, 8 Feb 2013 14:14:35 -0600
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>, <JBeulich@suse.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
In-Reply-To: <5112602602000078000BC725@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: linux@eikelenboom.it, boris.ostrovsky@oracle.com, "Hurwitz,
	Sherry" <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 2/6/2013 6:52 AM, Jan Beulich wrote:
>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm with the patch it does boot, but disables the I/O virtualization.
> Good. While, as said before, I still don't understand why it didn't
> crash earlier without that patch, I'm glad it's fixed. Will post the
> patch for inclusion momentarily.
>
>> Output of xl-dmesg attached, do you still need a xen-sums of the situation
>> without the debug patch (where it does crash) ?
> And you can't expect much else with broken ACPI tables:
>
> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0
>
> This is a HPET entry.
>
> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
>
> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says
>
> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
>
> so the IOMMU table is lacking an entry for the first IO-APIC, and
> without that we can't set up per-device interrupt remapping (in
> which case we choose to disable the IOMMU altogether, albeit it
> had been questioned whether that isn't making a bad situation
> worse in some cases).
>
> If you want the IOMMU back (at the price of re-opening the
> security issue described in XSA-36), you'd have to pass
> "iommu=amd-iommu-perdev-intremap" to the hypervisor.
>
> Jan

Jan,

It seems that all the recent issues with the AMD IOMMU regarding IOAPIC are
mainly caused by mismatch information from IVRS and MADT. Xen sets up "nr_ioapics"
by checking the number of IOAPICs reported in MADT, while the amd/iommu_acpi.c
code uses information from the IVHD entries of the IVRS to initialize IOMMU.

Most of the issues we are seeing are often triggered when platform BIOS decides
to disable one of the two IOAPICs in the RD890s configuration. I am trying to
summarize the cases here:


CASE1: BIOS disable the IOAPIC in the southbridge (SB8X0 chipset)
This is the case we are seeing here with the AMD 890-FX motherboard.
Here, the MADT is reporting 2 IOAPICs as shown by the message:

(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

However, when Xen tries to setup the IOMMU interrupt remapping table using IVHD
entries, there is only one IOAPIC (IOAPIC 1 with apic_id 7).

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
(XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
(XEN) IVHD Error: no information for IO-APIC 0x6
(XEN) AMD-Vi: Error initialization

In this case, if we should be able to look at the IVHD to correlate IOAPIC ID (0 or 1)
from the "handle" field and map it back to the BDF to setup the remapping table.

CASE2: BIOS disable the IOAPIC in the I/O bridge (RD890s chipset)
This happens in the case when we were testing the per-device interrupt remapping
table patch. (I think this is the issue you might be seeing in one of the Xen test system.)
In this case, the MADT reports 1 IOAPIC while the IVRS contains two IVHD entries with both
entries have the "hahandle" set to "0".  Unfortunately, in this case, there is no obvious
workaround, and the current solution is to disable IOMMU.

I am working with some of the BIOS engineers and vendors to try to issue root-cause
and provide BIOS update.

Jan, Sander:
Could you please provide the system information:
1. Motherboard vendor
2. BIOS version

Thank you,

Suravee


>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 20:15:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:15: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 1U3uLM-0005C9-7z; Fri, 08 Feb 2013 20:14:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Suravee.Suthikulpanit@amd.com>) id 1U3uLK-0005C4-Ie
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:14:42 +0000
Received: from [85.158.138.51:39096] by server-8.bemta-3.messagelabs.com id
	9C/E5-25687-1BC55115; Fri, 08 Feb 2013 20:14:41 +0000
X-Env-Sender: Suravee.Suthikulpanit@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360354478!29456225!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5983 invoked from network); 8 Feb 2013 20:14:40 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Feb 2013 20:14:40 -0000
Received: from mail80-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 20:14:38 +0000
Received: from mail80-tx2 (localhost [127.0.0.1])	by mail80-tx2-R.bigfish.com
	(Postfix) with ESMTP id F0E252A0324;
	Fri,  8 Feb 2013 20:14:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI98dI9371I2a2cM1432I179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ah8275dhz2dh668h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h1155h)
Received: from mail80-tx2 (localhost.localdomain [127.0.0.1]) by mail80-tx2
	(MessageSwitch) id 1360354476474563_4717;
	Fri,  8 Feb 2013 20:14:36 +0000 (UTC)
Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.237])	by
	mail80-tx2.bigfish.com (Postfix) with ESMTP id 66D9E48004A;
	Fri,  8 Feb 2013 20:14:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 20:14:35 +0000
X-WSS-ID: 0MHX48A-02-0NT-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 2F6B8C8003;	Fri,  8 Feb 2013 14:14:33 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Feb 2013 14:14:14 -0600
Received: from [10.236.48.55] (10.236.48.55) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server id 14.2.328.9; Fri, 8 Feb 2013
	14:14:35 -0600
Message-ID: <51155CAB.7010600@amd.com>
Date: Fri, 8 Feb 2013 14:14:35 -0600
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>, <JBeulich@suse.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
In-Reply-To: <5112602602000078000BC725@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: linux@eikelenboom.it, boris.ostrovsky@oracle.com, "Hurwitz,
	Sherry" <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 2/6/2013 6:52 AM, Jan Beulich wrote:
>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm with the patch it does boot, but disables the I/O virtualization.
> Good. While, as said before, I still don't understand why it didn't
> crash earlier without that patch, I'm glad it's fixed. Will post the
> patch for inclusion momentarily.
>
>> Output of xl-dmesg attached, do you still need a xen-sums of the situation
>> without the debug patch (where it does crash) ?
> And you can't expect much else with broken ACPI tables:
>
> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0
>
> This is a HPET entry.
>
> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
>
> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says
>
> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
>
> so the IOMMU table is lacking an entry for the first IO-APIC, and
> without that we can't set up per-device interrupt remapping (in
> which case we choose to disable the IOMMU altogether, albeit it
> had been questioned whether that isn't making a bad situation
> worse in some cases).
>
> If you want the IOMMU back (at the price of re-opening the
> security issue described in XSA-36), you'd have to pass
> "iommu=amd-iommu-perdev-intremap" to the hypervisor.
>
> Jan

Jan,

It seems that all the recent issues with the AMD IOMMU regarding IOAPIC are
mainly caused by mismatch information from IVRS and MADT. Xen sets up "nr_ioapics"
by checking the number of IOAPICs reported in MADT, while the amd/iommu_acpi.c
code uses information from the IVHD entries of the IVRS to initialize IOMMU.

Most of the issues we are seeing are often triggered when platform BIOS decides
to disable one of the two IOAPICs in the RD890s configuration. I am trying to
summarize the cases here:


CASE1: BIOS disable the IOAPIC in the southbridge (SB8X0 chipset)
This is the case we are seeing here with the AMD 890-FX motherboard.
Here, the MADT is reporting 2 IOAPICs as shown by the message:

(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

However, when Xen tries to setup the IOMMU interrupt remapping table using IVHD
entries, there is only one IOAPIC (IOAPIC 1 with apic_id 7).

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
(XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
(XEN) IVHD Error: no information for IO-APIC 0x6
(XEN) AMD-Vi: Error initialization

In this case, if we should be able to look at the IVHD to correlate IOAPIC ID (0 or 1)
from the "handle" field and map it back to the BDF to setup the remapping table.

CASE2: BIOS disable the IOAPIC in the I/O bridge (RD890s chipset)
This happens in the case when we were testing the per-device interrupt remapping
table patch. (I think this is the issue you might be seeing in one of the Xen test system.)
In this case, the MADT reports 1 IOAPIC while the IVRS contains two IVHD entries with both
entries have the "hahandle" set to "0".  Unfortunately, in this case, there is no obvious
workaround, and the current solution is to disable IOMMU.

I am working with some of the BIOS engineers and vendors to try to issue root-cause
and provide BIOS update.

Jan, Sander:
Could you please provide the system information:
1. Motherboard vendor
2. BIOS version

Thank you,

Suravee


>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 08 20:35:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:35: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 1U3uf6-0005fG-5N; Fri, 08 Feb 2013 20:35:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3uf4-0005fB-IB
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:35:06 +0000
Received: from [85.158.137.99:15379] by server-13.bemta-3.messagelabs.com id
	37/FE-20653-97165115; Fri, 08 Feb 2013 20:35:05 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360355703!20623171!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4457 invoked from network); 8 Feb 2013 20:35:03 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 20:35:03 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:60322 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 1U3ulM-0003mw-Kq; Fri, 08 Feb 2013 21:41:36 +0100
Date: Fri, 8 Feb 2013 21:34:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <17910596343.20130208213459@eikelenboom.it>
To: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
In-Reply-To: <51155CAB.7010600@amd.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
	<51155CAB.7010600@amd.com>
MIME-Version: 1.0
Cc: boris.ostrovsky@oracle.com, "Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
	JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, February 8, 2013, 9:14:35 PM, you wrote:

> On 2/6/2013 6:52 AM, Jan Beulich wrote:
>>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> Hmm with the patch it does boot, but disables the I/O virtualization.
>> Good. While, as said before, I still don't understand why it didn't
>> crash earlier without that patch, I'm glad it's fixed. Will post the
>> patch for inclusion momentarily.
>>
>>> Output of xl-dmesg attached, do you still need a xen-sums of the situation
>>> without the debug patch (where it does crash) ?
>> And you can't expect much else with broken ACPI tables:
>>
>> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
>> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0
>>
>> This is a HPET entry.
>>
>> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
>> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
>>
>> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says
>>
>> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
>> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
>> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
>> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
>>
>> so the IOMMU table is lacking an entry for the first IO-APIC, and
>> without that we can't set up per-device interrupt remapping (in
>> which case we choose to disable the IOMMU altogether, albeit it
>> had been questioned whether that isn't making a bad situation
>> worse in some cases).
>>
>> If you want the IOMMU back (at the price of re-opening the
>> security issue described in XSA-36), you'd have to pass
>> "iommu=amd-iommu-perdev-intremap" to the hypervisor.
>>
>> Jan

> Jan,

> It seems that all the recent issues with the AMD IOMMU regarding IOAPIC are
> mainly caused by mismatch information from IVRS and MADT. Xen sets up "nr_ioapics"
> by checking the number of IOAPICs reported in MADT, while the amd/iommu_acpi.c
> code uses information from the IVHD entries of the IVRS to initialize IOMMU.

> Most of the issues we are seeing are often triggered when platform BIOS decides
> to disable one of the two IOAPICs in the RD890s configuration. I am trying to
> summarize the cases here:


> CASE1: BIOS disable the IOAPIC in the southbridge (SB8X0 chipset)
> This is the case we are seeing here with the AMD 890-FX motherboard.
> Here, the MADT is reporting 2 IOAPICs as shown by the message:

> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

> However, when Xen tries to setup the IOMMU interrupt remapping table using IVHD
> entries, there is only one IOAPIC (IOAPIC 1 with apic_id 7).

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
> (XEN) IVHD Error: no information for IO-APIC 0x6
> (XEN) AMD-Vi: Error initialization

> In this case, if we should be able to look at the IVHD to correlate IOAPIC ID (0 or 1)
> from the "handle" field and map it back to the BDF to setup the remapping table.

> CASE2: BIOS disable the IOAPIC in the I/O bridge (RD890s chipset)
> This happens in the case when we were testing the per-device interrupt remapping
> table patch. (I think this is the issue you might be seeing in one of the Xen test system.)
> In this case, the MADT reports 1 IOAPIC while the IVRS contains two IVHD entries with both
> entries have the "hahandle" set to "0".  Unfortunately, in this case, there is no obvious
> workaround, and the current solution is to disable IOMMU.

> I am working with some of the BIOS engineers and vendors to try to issue root-cause
> and provide BIOS update.

> Jan, Sander:
> Could you please provide the system information:
> 1. Motherboard vendor
> 2. BIOS version

Suravee,

1. My motherboard is a "890FXA-GD70" from MSI (http://www.msi.com/product/mb/890FXA-GD70.html)
2. As for the bios version:
        - I'm currently running 1.8 beta1, it's a beta bios. It boots and works, but has the problem you described above.

        - I have tried all newer bioses up to the latest bios (1.15), but with these bioses the system halts during boot when the iommu option in the bios is enabled.
          With xen it halts right after the "(XEN) IVHD Error: no information for IO-APIC 0x6", so it could be another problem initializing the iommu i'm afraid.
          It also halts while trying to boot a baremetal linux kernel.
          When the iommu is disabled it boots fine.

I hope a more direct approach of the bios engineers has some result, customer support most of the time have no clue and react like a firewall, bouncing and dropping all the packets :-(

Thanks for trying and picking it up !
--

Sander

> Thank you,

> Suravee


>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 08 20:35:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:35: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 1U3uf6-0005fG-5N; Fri, 08 Feb 2013 20:35:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U3uf4-0005fB-IB
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:35:06 +0000
Received: from [85.158.137.99:15379] by server-13.bemta-3.messagelabs.com id
	37/FE-20653-97165115; Fri, 08 Feb 2013 20:35:05 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360355703!20623171!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4457 invoked from network); 8 Feb 2013 20:35:03 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Feb 2013 20:35:03 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:60322 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 1U3ulM-0003mw-Kq; Fri, 08 Feb 2013 21:41:36 +0100
Date: Fri, 8 Feb 2013 21:34:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <17910596343.20130208213459@eikelenboom.it>
To: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
In-Reply-To: <51155CAB.7010600@amd.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
	<51155CAB.7010600@amd.com>
MIME-Version: 1.0
Cc: boris.ostrovsky@oracle.com, "Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
	JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, February 8, 2013, 9:14:35 PM, you wrote:

> On 2/6/2013 6:52 AM, Jan Beulich wrote:
>>>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> Hmm with the patch it does boot, but disables the I/O virtualization.
>> Good. While, as said before, I still don't understand why it didn't
>> crash earlier without that patch, I'm glad it's fixed. Will post the
>> patch for inclusion momentarily.
>>
>>> Output of xl-dmesg attached, do you still need a xen-sums of the situation
>>> without the debug patch (where it does crash) ?
>> And you can't expect much else with broken ACPI tables:
>>
>> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
>> (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0
>>
>> This is a HPET entry.
>>
>> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
>> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
>>
>> And this is an entry for IO-APIC #2 (ID 7), whereas FADT says
>>
>> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
>> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
>> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
>> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
>>
>> so the IOMMU table is lacking an entry for the first IO-APIC, and
>> without that we can't set up per-device interrupt remapping (in
>> which case we choose to disable the IOMMU altogether, albeit it
>> had been questioned whether that isn't making a bad situation
>> worse in some cases).
>>
>> If you want the IOMMU back (at the price of re-opening the
>> security issue described in XSA-36), you'd have to pass
>> "iommu=amd-iommu-perdev-intremap" to the hypervisor.
>>
>> Jan

> Jan,

> It seems that all the recent issues with the AMD IOMMU regarding IOAPIC are
> mainly caused by mismatch information from IVRS and MADT. Xen sets up "nr_ioapics"
> by checking the number of IOAPICs reported in MADT, while the amd/iommu_acpi.c
> code uses information from the IVHD entries of the IVRS to initialize IOMMU.

> Most of the issues we are seeing are often triggered when platform BIOS decides
> to disable one of the two IOAPICs in the RD890s configuration. I am trying to
> summarize the cases here:


> CASE1: BIOS disable the IOAPIC in the southbridge (SB8X0 chipset)
> This is the case we are seeing here with the AMD 890-FX motherboard.
> Here, the MADT is reporting 2 IOAPICs as shown by the message:

> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

> However, when Xen tries to setup the IOMMU interrupt remapping table using IVHD
> entries, there is only one IOAPIC (IOAPIC 1 with apic_id 7).

> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
> (XEN) IVHD Error: no information for IO-APIC 0x6
> (XEN) AMD-Vi: Error initialization

> In this case, if we should be able to look at the IVHD to correlate IOAPIC ID (0 or 1)
> from the "handle" field and map it back to the BDF to setup the remapping table.

> CASE2: BIOS disable the IOAPIC in the I/O bridge (RD890s chipset)
> This happens in the case when we were testing the per-device interrupt remapping
> table patch. (I think this is the issue you might be seeing in one of the Xen test system.)
> In this case, the MADT reports 1 IOAPIC while the IVRS contains two IVHD entries with both
> entries have the "hahandle" set to "0".  Unfortunately, in this case, there is no obvious
> workaround, and the current solution is to disable IOMMU.

> I am working with some of the BIOS engineers and vendors to try to issue root-cause
> and provide BIOS update.

> Jan, Sander:
> Could you please provide the system information:
> 1. Motherboard vendor
> 2. BIOS version

Suravee,

1. My motherboard is a "890FXA-GD70" from MSI (http://www.msi.com/product/mb/890FXA-GD70.html)
2. As for the bios version:
        - I'm currently running 1.8 beta1, it's a beta bios. It boots and works, but has the problem you described above.

        - I have tried all newer bioses up to the latest bios (1.15), but with these bioses the system halts during boot when the iommu option in the bios is enabled.
          With xen it halts right after the "(XEN) IVHD Error: no information for IO-APIC 0x6", so it could be another problem initializing the iommu i'm afraid.
          It also halts while trying to boot a baremetal linux kernel.
          When the iommu is disabled it boots fine.

I hope a more direct approach of the bios engineers has some result, customer support most of the time have no clue and react like a firewall, bouncing and dropping all the packets :-(

Thanks for trying and picking it up !
--

Sander

> Thank you,

> Suravee


>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 08 20:43:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:43: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 1U3un5-0006Z2-Hg; Fri, 08 Feb 2013 20:43:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <timg@tpi.com>) id 1U3ug0-0005hi-Rb
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 20:36:04 +0000
Received: from [85.158.138.51:28878] by server-5.bemta-3.messagelabs.com id
	E9/47-04457-2B165115; Fri, 08 Feb 2013 20:36:02 +0000
X-Env-Sender: timg@tpi.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360355759!8854626!1
X-Originating-IP: [70.99.223.143]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30459 invoked from network); 8 Feb 2013 20:36:00 -0000
Received: from mail.tpi.com (HELO mail.tpi.com) (70.99.223.143)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 20:36:00 -0000
Received: from salmon.rtg.net (mail.tpi.com [70.99.223.143])
	by mail.tpi.com (Postfix) with ESMTP id 6962D3309B2;
	Fri,  8 Feb 2013 12:34:46 -0800 (PST)
Received: by salmon.rtg.net (Postfix, from userid 1000)
	id 21CD0203BE; Fri,  8 Feb 2013 13:34:46 -0700 (MST)
From: Tim Gardner <tim.gardner@canonical.com>
To: linux-kernel@vger.kernel.org
Date: Fri,  8 Feb 2013 13:34:37 -0700
Message-Id: <1360355677-52442-1-git-send-email-tim.gardner@canonical.com>
X-Mailer: git-send-email 1.7.9.5
X-Mailman-Approved-At: Fri, 08 Feb 2013 20:43:22 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	stable@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tim Gardner <tim.gardner@canonical.com>
Subject: [Xen-devel] [PATCH linux-next] xen/multicall: xen_mc_callback():
	avoid buffer overflow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 buffer overflow was introduced with 91e0c5f3dad47838cb2ecc1865ce789a0b7182b1
(2.6.24).

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: stable@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---

This patch applies cleanly to 3.1.10 and newer. Requires a backport
for 2.6.24-3.2.y

 arch/x86/xen/multicalls.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
index 0d82003..5270407 100644
--- a/arch/x86/xen/multicalls.c
+++ b/arch/x86/xen/multicalls.c
@@ -195,9 +195,10 @@ void xen_mc_callback(void (*fn)(void *), void *data)
 	struct mc_buffer *b = &__get_cpu_var(mc_buffer);
 	struct callback *cb;
 
-	if (b->cbidx == MC_BATCH) {
+	if (b->cbidx >= MC_BATCH) {
 		trace_xen_mc_flush_reason(XEN_MC_FL_CALLBACK);
 		xen_mc_flush();
+		return;
 	}
 
 	trace_xen_mc_callback(fn, data);
-- 
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 Fri Feb 08 20:43:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:43: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 1U3un5-0006Z2-Hg; Fri, 08 Feb 2013 20:43:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <timg@tpi.com>) id 1U3ug0-0005hi-Rb
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 20:36:04 +0000
Received: from [85.158.138.51:28878] by server-5.bemta-3.messagelabs.com id
	E9/47-04457-2B165115; Fri, 08 Feb 2013 20:36:02 +0000
X-Env-Sender: timg@tpi.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360355759!8854626!1
X-Originating-IP: [70.99.223.143]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30459 invoked from network); 8 Feb 2013 20:36:00 -0000
Received: from mail.tpi.com (HELO mail.tpi.com) (70.99.223.143)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Feb 2013 20:36:00 -0000
Received: from salmon.rtg.net (mail.tpi.com [70.99.223.143])
	by mail.tpi.com (Postfix) with ESMTP id 6962D3309B2;
	Fri,  8 Feb 2013 12:34:46 -0800 (PST)
Received: by salmon.rtg.net (Postfix, from userid 1000)
	id 21CD0203BE; Fri,  8 Feb 2013 13:34:46 -0700 (MST)
From: Tim Gardner <tim.gardner@canonical.com>
To: linux-kernel@vger.kernel.org
Date: Fri,  8 Feb 2013 13:34:37 -0700
Message-Id: <1360355677-52442-1-git-send-email-tim.gardner@canonical.com>
X-Mailer: git-send-email 1.7.9.5
X-Mailman-Approved-At: Fri, 08 Feb 2013 20:43:22 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	stable@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tim Gardner <tim.gardner@canonical.com>
Subject: [Xen-devel] [PATCH linux-next] xen/multicall: xen_mc_callback():
	avoid buffer overflow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 buffer overflow was introduced with 91e0c5f3dad47838cb2ecc1865ce789a0b7182b1
(2.6.24).

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: stable@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---

This patch applies cleanly to 3.1.10 and newer. Requires a backport
for 2.6.24-3.2.y

 arch/x86/xen/multicalls.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
index 0d82003..5270407 100644
--- a/arch/x86/xen/multicalls.c
+++ b/arch/x86/xen/multicalls.c
@@ -195,9 +195,10 @@ void xen_mc_callback(void (*fn)(void *), void *data)
 	struct mc_buffer *b = &__get_cpu_var(mc_buffer);
 	struct callback *cb;
 
-	if (b->cbidx == MC_BATCH) {
+	if (b->cbidx >= MC_BATCH) {
 		trace_xen_mc_flush_reason(XEN_MC_FL_CALLBACK);
 		xen_mc_flush();
+		return;
 	}
 
 	trace_xen_mc_callback(fn, data);
-- 
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 Fri Feb 08 20:57:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:57: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 1U3v0I-00075L-BL; Fri, 08 Feb 2013 20:57:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1U3v0G-00075G-HX
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:57:00 +0000
Received: from [85.158.139.83:17309] by server-7.bemta-5.messagelabs.com id
	F7/F5-11121-B9665115; Fri, 08 Feb 2013 20:56:59 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360357017!31538411!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMTk5NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26951 invoked from network); 8 Feb 2013 20:56:58 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 20:56:58 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r18KuhAa002206;
	Fri, 8 Feb 2013 20:56:47 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r18Kuexl010129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 20:56:40 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r18Kuekd031205;
	Fri, 8 Feb 2013 20:56:40 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r18Kudg3031200; Fri, 8 Feb 2013 20:56:40 GMT
Date: Fri, 8 Feb 2013 20:56:39 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5114C13E02000078000BD15E@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1302082053100.8629@procyon.dur.ac.uk>
References: <CD39469B.4B817%keir.xen@gmail.com>
	<alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
	<5114C13E02000078000BD15E@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-468485992-1360357000=:8629"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r18KuhAa002206
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/2 v2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-468485992-1360357000=:8629
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 8 Feb 2013, Jan Beulich wrote:

>>>> On 08.02.13 at 00:20, M A Young <m.a.young@durham.ac.uk> wrote:
>> I am attaching a patch that turns off this check.
>
> You were told how to do it and still did it wrong: You can't blindly
> pass an option to the compiler that not all supported versions
> recognize. Once again, please do it the same way as done for
> other warnings (using cc-option-add).

Here is a revised version that adds the -Wno-unused-local-typedefs option 
in a cc-option-add clause.

 	Michael Young
--8323329-468485992-1360357000=:8629
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.1.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.1.patch

Z2NjIDQuOCBnaXZlcyB0aGUgZm9sbG93aW5nIGVycm9yIHdoZW4gYnVpbGRp
bmcgeGVuL2NvbW1vbi9jb21wYXQvbWVtb3J5LmMNCg0KbWVtb3J5LmM6IElu
IGZ1bmN0aW9uICdjb21wYXRfbWVtb3J5X29wJzoNCi9idWlsZGRpci9idWls
ZC9CVUlMRC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2
L3hlbi5oOjM1OjMzOiBlcnJvcjogdHlwZWRlZiAnX19ndWVzdF9oYW5kbGVf
Y29uc3RfY29tcGF0X21lbW9yeV9leGNoYW5nZV90JyBsb2NhbGx5IGRlZmlu
ZWQgYnV0IG5vdCB1c2VkIFstV2Vycm9yPXVudXNlZC1sb2NhbC10eXBlZGVm
c10NCiAgICAgdHlwZWRlZiBzdHJ1Y3QgeyB0eXBlICpwOyB9IF9fZ3Vlc3Rf
aGFuZGxlXyAjIyBuYW1lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBeDQovYnVpbGRkaXIvYnVpbGQvQlVJTEQveGVuLTQuMi4xL3hlbi9p
bmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni94ZW4uaDo0Mzo1OiBub3RlOiBpbiBl
eHBhbnNpb24gb2YgbWFjcm8gJ19fX0RFRklORV9YRU5fR1VFU1RfSEFORExF
Jw0KICAgICBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShjb25zdF8jI25h
bWUsIGNvbnN0IHR5cGUpDQogICAgIF4NCi9idWlsZGRpci9idWlsZC9CVUlM
RC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L3hlbi5o
OjQ0OjQxOiBub3RlOiBpbiBleHBhbnNpb24gb2YgbWFjcm8gJ19fREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUnDQogI2RlZmluZSBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShuYW1lKSAgIF9fREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobmFt
ZSwgbmFtZSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXg0KbWVtb3J5LmM6MjYxOjEzOiBub3RlOiBpbiBleHBhbnNpb24g
b2YgbWFjcm8gJ0RFRklORV9YRU5fR1VFU1RfSEFORExFJw0KICAgICAgICAg
ICAgIERFRklORV9YRU5fR1VFU1RfSEFORExFKGNvbXBhdF9tZW1vcnlfZXhj
aGFuZ2VfdCk7DQogICAgICAgICAgICAgXg0KDQpUaGUgZXJyb3IgaXMgaGFy
bWxlc3MgaW4gdGhpcyBjYXNlIHNvIHR1cm4gdGhlIGNoZWNrIG9mZi4NCg0K
U2lnbmVkLW9mZi1ieTogTWljaGFlbCBZb3VuZyA8bS5hLnlvdW5nQGR1cmhh
bS5hYy51az4NCg0KLS0tIHhlbi00LjIuMS9Db25maWcubWsub3JpZwkyMDEz
LTAyLTA4IDIwOjA3OjI1LjAwNjcxNjk3NSArMDAwMA0KKysrIHhlbi00LjIu
MS9Db25maWcubWsJMjAxMy0wMi0wOCAyMDoxMzo1Mi4xODQ4NzY1ODIgKzAw
MDANCkBAIC0xNjYsNiArMTY2LDcgQEANCiAkKGNhbGwgY2Mtb3B0aW9uLWFk
ZCxIT1NUQ0ZMQUdTLEhPU1RDQywtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCkNCiAkKGNhbGwgY2Mtb3B0aW9uLWFkZCxDRkxBR1MsQ0MsLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQpDQogJChjYWxsIGNjLW9wdGlvbi1h
ZGQsQ0ZMQUdTLENDLC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUpDQor
JChjYWxsIGNjLW9wdGlvbi1hZGQsQ0ZMQUdTLENDLC1Xbm8tdW51c2VkLWxv
Y2FsLXR5cGVkZWZzKQ0KIA0KIExERkxBR1MgKz0gJChmb3JlYWNoIGksICQo
RVhUUkFfTElCKSwgLUwkKGkpKSANCiBDRkxBR1MgKz0gJChmb3JlYWNoIGks
ICQoRVhUUkFfSU5DTFVERVMpLCAtSSQoaSkpDQo=

--8323329-468485992-1360357000=:8629
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-468485992-1360357000=:8629--


From xen-devel-bounces@lists.xen.org Fri Feb 08 20:57:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 20:57: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 1U3v0I-00075L-BL; Fri, 08 Feb 2013 20:57:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1U3v0G-00075G-HX
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 20:57:00 +0000
Received: from [85.158.139.83:17309] by server-7.bemta-5.messagelabs.com id
	F7/F5-11121-B9665115; Fri, 08 Feb 2013 20:56:59 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360357017!31538411!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMTk5NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26951 invoked from network); 8 Feb 2013 20:56:58 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 20:56:58 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r18KuhAa002206;
	Fri, 8 Feb 2013 20:56:47 GMT
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r18Kuexl010129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 20:56:40 GMT
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id r18Kuekd031205;
	Fri, 8 Feb 2013 20:56:40 GMT
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	r18Kudg3031200; Fri, 8 Feb 2013 20:56:40 GMT
Date: Fri, 8 Feb 2013 20:56:39 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5114C13E02000078000BD15E@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1302082053100.8629@procyon.dur.ac.uk>
References: <CD39469B.4B817%keir.xen@gmail.com>
	<alpine.DEB.2.00.1302072317240.6708@procyon.dur.ac.uk>
	<5114C13E02000078000BD15E@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-468485992-1360357000=:8629"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: r18KuhAa002206
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH 1/2 v2] Compile errors with gcc 4.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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-468485992-1360357000=:8629
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 8 Feb 2013, Jan Beulich wrote:

>>>> On 08.02.13 at 00:20, M A Young <m.a.young@durham.ac.uk> wrote:
>> I am attaching a patch that turns off this check.
>
> You were told how to do it and still did it wrong: You can't blindly
> pass an option to the compiler that not all supported versions
> recognize. Once again, please do it the same way as done for
> other warnings (using cc-option-add).

Here is a revised version that adds the -Wno-unused-local-typedefs option 
in a cc-option-add clause.

 	Michael Young
--8323329-468485992-1360357000=:8629
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc48.build.1.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc48.build.1.patch

Z2NjIDQuOCBnaXZlcyB0aGUgZm9sbG93aW5nIGVycm9yIHdoZW4gYnVpbGRp
bmcgeGVuL2NvbW1vbi9jb21wYXQvbWVtb3J5LmMNCg0KbWVtb3J5LmM6IElu
IGZ1bmN0aW9uICdjb21wYXRfbWVtb3J5X29wJzoNCi9idWlsZGRpci9idWls
ZC9CVUlMRC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2
L3hlbi5oOjM1OjMzOiBlcnJvcjogdHlwZWRlZiAnX19ndWVzdF9oYW5kbGVf
Y29uc3RfY29tcGF0X21lbW9yeV9leGNoYW5nZV90JyBsb2NhbGx5IGRlZmlu
ZWQgYnV0IG5vdCB1c2VkIFstV2Vycm9yPXVudXNlZC1sb2NhbC10eXBlZGVm
c10NCiAgICAgdHlwZWRlZiBzdHJ1Y3QgeyB0eXBlICpwOyB9IF9fZ3Vlc3Rf
aGFuZGxlXyAjIyBuYW1lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBeDQovYnVpbGRkaXIvYnVpbGQvQlVJTEQveGVuLTQuMi4xL3hlbi9p
bmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni94ZW4uaDo0Mzo1OiBub3RlOiBpbiBl
eHBhbnNpb24gb2YgbWFjcm8gJ19fX0RFRklORV9YRU5fR1VFU1RfSEFORExF
Jw0KICAgICBfX19ERUZJTkVfWEVOX0dVRVNUX0hBTkRMRShjb25zdF8jI25h
bWUsIGNvbnN0IHR5cGUpDQogICAgIF4NCi9idWlsZGRpci9idWlsZC9CVUlM
RC94ZW4tNC4yLjEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L3hlbi5o
OjQ0OjQxOiBub3RlOiBpbiBleHBhbnNpb24gb2YgbWFjcm8gJ19fREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUnDQogI2RlZmluZSBERUZJTkVfWEVOX0dVRVNU
X0hBTkRMRShuYW1lKSAgIF9fREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUobmFt
ZSwgbmFtZSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXg0KbWVtb3J5LmM6MjYxOjEzOiBub3RlOiBpbiBleHBhbnNpb24g
b2YgbWFjcm8gJ0RFRklORV9YRU5fR1VFU1RfSEFORExFJw0KICAgICAgICAg
ICAgIERFRklORV9YRU5fR1VFU1RfSEFORExFKGNvbXBhdF9tZW1vcnlfZXhj
aGFuZ2VfdCk7DQogICAgICAgICAgICAgXg0KDQpUaGUgZXJyb3IgaXMgaGFy
bWxlc3MgaW4gdGhpcyBjYXNlIHNvIHR1cm4gdGhlIGNoZWNrIG9mZi4NCg0K
U2lnbmVkLW9mZi1ieTogTWljaGFlbCBZb3VuZyA8bS5hLnlvdW5nQGR1cmhh
bS5hYy51az4NCg0KLS0tIHhlbi00LjIuMS9Db25maWcubWsub3JpZwkyMDEz
LTAyLTA4IDIwOjA3OjI1LjAwNjcxNjk3NSArMDAwMA0KKysrIHhlbi00LjIu
MS9Db25maWcubWsJMjAxMy0wMi0wOCAyMDoxMzo1Mi4xODQ4NzY1ODIgKzAw
MDANCkBAIC0xNjYsNiArMTY2LDcgQEANCiAkKGNhbGwgY2Mtb3B0aW9uLWFk
ZCxIT1NUQ0ZMQUdTLEhPU1RDQywtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRl
bWVudCkNCiAkKGNhbGwgY2Mtb3B0aW9uLWFkZCxDRkxBR1MsQ0MsLVdkZWNs
YXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQpDQogJChjYWxsIGNjLW9wdGlvbi1h
ZGQsQ0ZMQUdTLENDLC1Xbm8tdW51c2VkLWJ1dC1zZXQtdmFyaWFibGUpDQor
JChjYWxsIGNjLW9wdGlvbi1hZGQsQ0ZMQUdTLENDLC1Xbm8tdW51c2VkLWxv
Y2FsLXR5cGVkZWZzKQ0KIA0KIExERkxBR1MgKz0gJChmb3JlYWNoIGksICQo
RVhUUkFfTElCKSwgLUwkKGkpKSANCiBDRkxBR1MgKz0gJChmb3JlYWNoIGks
ICQoRVhUUkFfSU5DTFVERVMpLCAtSSQoaSkpDQo=

--8323329-468485992-1360357000=:8629
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-468485992-1360357000=:8629--


From xen-devel-bounces@lists.xen.org Fri Feb 08 21:14:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 21: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 1U3vGz-0007iG-7J; Fri, 08 Feb 2013 21:14:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>) id 1U3vGx-0007iB-9Q
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 21:14:15 +0000
Received: from [85.158.143.99:58890] by server-3.bemta-4.messagelabs.com id
	CE/0F-08920-6AA65115; Fri, 08 Feb 2013 21:14:14 +0000
X-Env-Sender: dvrabel@cantab.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360358054!30588732!1
X-Originating-IP: [212.23.1.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIzLjEuMyA9PiA1NzcwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26253 invoked from network); 8 Feb 2013 21:14:14 -0000
Received: from smarthost03.mail.zen.net.uk (HELO smarthost03.mail.zen.net.uk)
	(212.23.1.3) by server-13.tower-216.messagelabs.com with SMTP;
	8 Feb 2013 21:14:14 -0000
Received: from [82.70.146.41] (helo=pear)
	by smarthost03.mail.zen.net.uk with esmtps
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>)
	id 1U3vGr-0004oA-GL; Fri, 08 Feb 2013 21:14:09 +0000
Received: from apple.davidvrabel.org.uk ([82.70.146.43])
	by pear with esmtp (Exim 4.72) (envelope-from <dvrabel@cantab.net>)
	id 1U3vGn-0008Ff-PU; Fri, 08 Feb 2013 21:14:07 +0000
Message-ID: <51156A91.5070801@cantab.net>
Date: Fri, 08 Feb 2013 21:13:53 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tim Gardner <tim.gardner@canonical.com>
References: <1360355677-52442-1-git-send-email-tim.gardner@canonical.com>
In-Reply-To: <1360355677-52442-1-git-send-email-tim.gardner@canonical.com>
X-SA-Exim-Connect-IP: 82.70.146.43
X-SA-Exim-Mail-From: dvrabel@cantab.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pear
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL
	autolearn=no version=3.3.1
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000)
X-SA-Exim-Scanned: Yes (on pear)
X-Originating-Smarthost03-IP: [82.70.146.41]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH linux-next] xen/multicall:
 xen_mc_callback(): avoid buffer overflow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/02/2013 20:34, Tim Gardner wrote:
> This buffer overflow was introduced with 91e0c5f3dad47838cb2ecc1865ce789a0b7182b1
> (2.6.24).

There's no buffer overflow here. xen_mc_flush() resets b->cbidx.

David

>  arch/x86/xen/multicalls.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
> index 0d82003..5270407 100644
> --- a/arch/x86/xen/multicalls.c
> +++ b/arch/x86/xen/multicalls.c
> @@ -195,9 +195,10 @@ void xen_mc_callback(void (*fn)(void *), void *data)
>  	struct mc_buffer *b = &__get_cpu_var(mc_buffer);
>  	struct callback *cb;
>  
> -	if (b->cbidx == MC_BATCH) {
> +	if (b->cbidx >= MC_BATCH) {
>  		trace_xen_mc_flush_reason(XEN_MC_FL_CALLBACK);
>  		xen_mc_flush();
> +		return;
>  	}
>  
>  	trace_xen_mc_callback(fn, data);
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 21:14:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 21: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 1U3vGz-0007iG-7J; Fri, 08 Feb 2013 21:14:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>) id 1U3vGx-0007iB-9Q
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 21:14:15 +0000
Received: from [85.158.143.99:58890] by server-3.bemta-4.messagelabs.com id
	CE/0F-08920-6AA65115; Fri, 08 Feb 2013 21:14:14 +0000
X-Env-Sender: dvrabel@cantab.net
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360358054!30588732!1
X-Originating-IP: [212.23.1.3]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIzLjEuMyA9PiA1NzcwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26253 invoked from network); 8 Feb 2013 21:14:14 -0000
Received: from smarthost03.mail.zen.net.uk (HELO smarthost03.mail.zen.net.uk)
	(212.23.1.3) by server-13.tower-216.messagelabs.com with SMTP;
	8 Feb 2013 21:14:14 -0000
Received: from [82.70.146.41] (helo=pear)
	by smarthost03.mail.zen.net.uk with esmtps
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>)
	id 1U3vGr-0004oA-GL; Fri, 08 Feb 2013 21:14:09 +0000
Received: from apple.davidvrabel.org.uk ([82.70.146.43])
	by pear with esmtp (Exim 4.72) (envelope-from <dvrabel@cantab.net>)
	id 1U3vGn-0008Ff-PU; Fri, 08 Feb 2013 21:14:07 +0000
Message-ID: <51156A91.5070801@cantab.net>
Date: Fri, 08 Feb 2013 21:13:53 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tim Gardner <tim.gardner@canonical.com>
References: <1360355677-52442-1-git-send-email-tim.gardner@canonical.com>
In-Reply-To: <1360355677-52442-1-git-send-email-tim.gardner@canonical.com>
X-SA-Exim-Connect-IP: 82.70.146.43
X-SA-Exim-Mail-From: dvrabel@cantab.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pear
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL
	autolearn=no version=3.3.1
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000)
X-SA-Exim-Scanned: Yes (on pear)
X-Originating-Smarthost03-IP: [82.70.146.41]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH linux-next] xen/multicall:
 xen_mc_callback(): avoid buffer overflow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/02/2013 20:34, Tim Gardner wrote:
> This buffer overflow was introduced with 91e0c5f3dad47838cb2ecc1865ce789a0b7182b1
> (2.6.24).

There's no buffer overflow here. xen_mc_flush() resets b->cbidx.

David

>  arch/x86/xen/multicalls.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
> index 0d82003..5270407 100644
> --- a/arch/x86/xen/multicalls.c
> +++ b/arch/x86/xen/multicalls.c
> @@ -195,9 +195,10 @@ void xen_mc_callback(void (*fn)(void *), void *data)
>  	struct mc_buffer *b = &__get_cpu_var(mc_buffer);
>  	struct callback *cb;
>  
> -	if (b->cbidx == MC_BATCH) {
> +	if (b->cbidx >= MC_BATCH) {
>  		trace_xen_mc_flush_reason(XEN_MC_FL_CALLBACK);
>  		xen_mc_flush();
> +		return;
>  	}
>  
>  	trace_xen_mc_callback(fn, data);
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 21:23:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 21: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 1U3vPV-0008PN-8G; Fri, 08 Feb 2013 21:23:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U3vPT-0008PI-Fd
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 21:23:03 +0000
Received: from [85.158.143.99:49759] by server-3.bemta-4.messagelabs.com id
	97/B1-08920-6BC65115; Fri, 08 Feb 2013 21:23:02 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360358578!22770461!1
X-Originating-IP: [209.85.223.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5064 invoked from network); 8 Feb 2013 21:23:00 -0000
Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com)
	(209.85.223.180)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 21:23:00 -0000
Received: by mail-ie0-f180.google.com with SMTP id bn7so5682889ieb.11
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 13:22:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=uq+kgNiEs+JruWxs3xny7mghVbbN3R4/DfSxUfSKrQo=;
	b=VNqEEnlagbIGcP+w/4nMeNppMH1hoQJkljvz+JQMj9MoRX+OuCaDi7haIT2ZEvDKAd
	eSzAdN+XhML9GljqpD+acFpv0twVRlClHUqx5fS2oMSmFR9Pt2aDxayMLpq2J0gV8PL3
	vR82x7GkAJL8Z+/bmeTw/Wqs7aCKVgynqzskuQKNnxTsK1csGOTKpjnE7kTMsLbAn4Vy
	0NFGMgkHZB3dr6+esRP85cej7iw4IQpkw+UisXKYvRj01+fwYxRqQkdOaCLKrZTGzgS7
	tZ3ERmGBGoLm2pPRzSAZ0eN3lY9w7GCSBjiD3OclYhiYpQBVib1B1OZyRsqKNg0iQMBX
	jI2Q==
MIME-Version: 1.0
X-Received: by 10.50.56.232 with SMTP id d8mr5386851igq.112.1360358578273;
	Fri, 08 Feb 2013 13:22:58 -0800 (PST)
Received: by 10.64.138.37 with HTTP; Fri, 8 Feb 2013 13:22:58 -0800 (PST)
In-Reply-To: <5114CF55.5000303@citrix.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
Date: Fri, 8 Feb 2013 16:22:58 -0500
X-Google-Sender-Auth: PbwAvGdU3dfoypTKUmOKk8wVe_0
Message-ID: <CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Cc: Milan opath <milan.opath@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
<tomasz.wroblewski@citrix.com> wrote:
>
>> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
>> you are .. ah yes, you are hitting a bug that should be in the stable
>> tree fix.
>>
>> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
>> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
>>
>>
>
> Thanks Konrad. I've tried your patches, and whilst I have not seen this
> crash in cpuidle_register anymore, the others are still present (in
> build_schedule_domains for example).
>

That looks familiar too. I think it got fixed in the upstream kernel
and it was a generic bug - but I can't recall which commit it was.

> I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
> commandline stops both the xen scheduler and dom0 kernel crashing and all
> works fine - made dozens of succesfull s3 attempts. Was wondering if you
> guys had any thoughts on this? Is the dom0 kernel even supposed to cope
> during s3 in non dom0 vcpu pin case?
>
No that is something new. Is this only an issue on Intel boxes but not AMD?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 21:23:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 21: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 1U3vPV-0008PN-8G; Fri, 08 Feb 2013 21:23:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1U3vPT-0008PI-Fd
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 21:23:03 +0000
Received: from [85.158.143.99:49759] by server-3.bemta-4.messagelabs.com id
	97/B1-08920-6BC65115; Fri, 08 Feb 2013 21:23:02 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360358578!22770461!1
X-Originating-IP: [209.85.223.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5064 invoked from network); 8 Feb 2013 21:23:00 -0000
Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com)
	(209.85.223.180)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Feb 2013 21:23:00 -0000
Received: by mail-ie0-f180.google.com with SMTP id bn7so5682889ieb.11
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 13:22:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=uq+kgNiEs+JruWxs3xny7mghVbbN3R4/DfSxUfSKrQo=;
	b=VNqEEnlagbIGcP+w/4nMeNppMH1hoQJkljvz+JQMj9MoRX+OuCaDi7haIT2ZEvDKAd
	eSzAdN+XhML9GljqpD+acFpv0twVRlClHUqx5fS2oMSmFR9Pt2aDxayMLpq2J0gV8PL3
	vR82x7GkAJL8Z+/bmeTw/Wqs7aCKVgynqzskuQKNnxTsK1csGOTKpjnE7kTMsLbAn4Vy
	0NFGMgkHZB3dr6+esRP85cej7iw4IQpkw+UisXKYvRj01+fwYxRqQkdOaCLKrZTGzgS7
	tZ3ERmGBGoLm2pPRzSAZ0eN3lY9w7GCSBjiD3OclYhiYpQBVib1B1OZyRsqKNg0iQMBX
	jI2Q==
MIME-Version: 1.0
X-Received: by 10.50.56.232 with SMTP id d8mr5386851igq.112.1360358578273;
	Fri, 08 Feb 2013 13:22:58 -0800 (PST)
Received: by 10.64.138.37 with HTTP; Fri, 8 Feb 2013 13:22:58 -0800 (PST)
In-Reply-To: <5114CF55.5000303@citrix.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
Date: Fri, 8 Feb 2013 16:22:58 -0500
X-Google-Sender-Auth: PbwAvGdU3dfoypTKUmOKk8wVe_0
Message-ID: <CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Cc: Milan opath <milan.opath@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
<tomasz.wroblewski@citrix.com> wrote:
>
>> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
>> you are .. ah yes, you are hitting a bug that should be in the stable
>> tree fix.
>>
>> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
>> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
>>
>>
>
> Thanks Konrad. I've tried your patches, and whilst I have not seen this
> crash in cpuidle_register anymore, the others are still present (in
> build_schedule_domains for example).
>

That looks familiar too. I think it got fixed in the upstream kernel
and it was a generic bug - but I can't recall which commit it was.

> I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
> commandline stops both the xen scheduler and dom0 kernel crashing and all
> works fine - made dozens of succesfull s3 attempts. Was wondering if you
> guys had any thoughts on this? Is the dom0 kernel even supposed to cope
> during s3 in non dom0 vcpu pin case?
>
No that is something new. Is this only an issue on Intel boxes but not AMD?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 22:19:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 22: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 1U3wHu-0001yz-C8; Fri, 08 Feb 2013 22:19:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Suravee.Suthikulpanit@amd.com>) id 1U3wHs-0001yu-DH
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 22:19:16 +0000
Received: from [85.158.138.51:61514] by server-7.bemta-3.messagelabs.com id
	46/97-10367-3E975115; Fri, 08 Feb 2013 22:19:15 +0000
X-Env-Sender: Suravee.Suthikulpanit@amd.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360361953!22774500!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24309 invoked from network); 8 Feb 2013 22:19:14 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Feb 2013 22:19:14 -0000
Received: from mail77-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 22:19:13 +0000
Received: from mail77-va3 (localhost [127.0.0.1])	by mail77-va3-R.bigfish.com
	(Postfix) with ESMTP id 6A1A43E0183;
	Fri,  8 Feb 2013 22:19:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VPS1(zzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275bh8275eha1495iz2dh668h839hd24he5bhf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1155h)
Received: from mail77-va3 (localhost.localdomain [127.0.0.1]) by mail77-va3
	(MessageSwitch) id 1360361904146384_8195;
	Fri,  8 Feb 2013 22:18:24 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.250])	by
	mail77-va3.bigfish.com (Postfix) with ESMTP id 2000A48004E;
	Fri,  8 Feb 2013 22:18:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 22:18:23 +0000
X-WSS-ID: 0MHX9YL-02-5M5-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 299C1C8003;	Fri,  8 Feb 2013 16:18:20 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Feb 2013 16:18:02 -0600
Received: from sos-dev02.amd.com (163.181.55.254) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server id 14.2.328.9; Fri, 8 Feb 2013
	16:18:22 -0600
From: <suravee.suthikulpanit@amd.com>
To: <xen-devel@lists.xen.org>, <JBeulich@suse.com>
Date: Fri, 8 Feb 2013 16:18:09 -0600
Message-ID: <1360361889-3503-1-git-send-email-suravee.suthikulpanit@amd.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: [Xen-devel] [PATCH] Add Xenoprofile support for AMD Family16h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add Xenoprofile support for AMD Family16h. The corresponded OProfile
patch has already been submitted to OProfile mailing list.
(http://marc.info/?l=oprofile-list&m=136036136017302&w=2 ).

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 xen/arch/x86/hvm/svm/vpmu.c     |    2 ++
 xen/arch/x86/oprofile/nmi_int.c |    4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 96eee8c..bf186fe 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -314,6 +314,7 @@ static int amd_vpmu_initialise(struct vcpu *v)
 	 case 0x10:
 	 case 0x12:
 	 case 0x14:
+	 case 0x16:
 	 default:
 	     num_counters = F10H_NUM_COUNTERS;
 	     counters = AMD_F10H_COUNTERS;
@@ -375,6 +376,7 @@ int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
     case 0x12:
     case 0x14:
     case 0x15:
+    case 0x16:
         ret = amd_vpmu_initialise(v);
         if ( !ret )
             vpmu->arch_vpmu_ops = &amd_vpmu_ops;
diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index 0710db2..0bd9355 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -415,6 +415,10 @@ static int __init nmi_init(void)
                                 model = &op_amd_fam15h_spec;
                                 cpu_type = "x86-64/family15h";
                                 break;
+                        case 0x16:
+                                model = &op_athlon_spec;
+                                cpu_type = "x86-64/family16h";
+                                break;
 			}
 			break;
 
-- 
1.7.10.4



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 22:19:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 22: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 1U3wHu-0001yz-C8; Fri, 08 Feb 2013 22:19:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Suravee.Suthikulpanit@amd.com>) id 1U3wHs-0001yu-DH
	for xen-devel@lists.xen.org; Fri, 08 Feb 2013 22:19:16 +0000
Received: from [85.158.138.51:61514] by server-7.bemta-3.messagelabs.com id
	46/97-10367-3E975115; Fri, 08 Feb 2013 22:19:15 +0000
X-Env-Sender: Suravee.Suthikulpanit@amd.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360361953!22774500!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24309 invoked from network); 8 Feb 2013 22:19:14 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-12.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Feb 2013 22:19:14 -0000
Received: from mail77-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 22:19:13 +0000
Received: from mail77-va3 (localhost [127.0.0.1])	by mail77-va3-R.bigfish.com
	(Postfix) with ESMTP id 6A1A43E0183;
	Fri,  8 Feb 2013 22:19:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VPS1(zzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275bh8275eha1495iz2dh668h839hd24he5bhf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1155h)
Received: from mail77-va3 (localhost.localdomain [127.0.0.1]) by mail77-va3
	(MessageSwitch) id 1360361904146384_8195;
	Fri,  8 Feb 2013 22:18:24 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.250])	by
	mail77-va3.bigfish.com (Postfix) with ESMTP id 2000A48004E;
	Fri,  8 Feb 2013 22:18:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server id
	14.1.225.23; Fri, 8 Feb 2013 22:18:23 +0000
X-WSS-ID: 0MHX9YL-02-5M5-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 299C1C8003;	Fri,  8 Feb 2013 16:18:20 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 8 Feb 2013 16:18:02 -0600
Received: from sos-dev02.amd.com (163.181.55.254) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server id 14.2.328.9; Fri, 8 Feb 2013
	16:18:22 -0600
From: <suravee.suthikulpanit@amd.com>
To: <xen-devel@lists.xen.org>, <JBeulich@suse.com>
Date: Fri, 8 Feb 2013 16:18:09 -0600
Message-ID: <1360361889-3503-1-git-send-email-suravee.suthikulpanit@amd.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: [Xen-devel] [PATCH] Add Xenoprofile support for AMD Family16h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add Xenoprofile support for AMD Family16h. The corresponded OProfile
patch has already been submitted to OProfile mailing list.
(http://marc.info/?l=oprofile-list&m=136036136017302&w=2 ).

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 xen/arch/x86/hvm/svm/vpmu.c     |    2 ++
 xen/arch/x86/oprofile/nmi_int.c |    4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 96eee8c..bf186fe 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -314,6 +314,7 @@ static int amd_vpmu_initialise(struct vcpu *v)
 	 case 0x10:
 	 case 0x12:
 	 case 0x14:
+	 case 0x16:
 	 default:
 	     num_counters = F10H_NUM_COUNTERS;
 	     counters = AMD_F10H_COUNTERS;
@@ -375,6 +376,7 @@ int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
     case 0x12:
     case 0x14:
     case 0x15:
+    case 0x16:
         ret = amd_vpmu_initialise(v);
         if ( !ret )
             vpmu->arch_vpmu_ops = &amd_vpmu_ops;
diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index 0710db2..0bd9355 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -415,6 +415,10 @@ static int __init nmi_init(void)
                                 model = &op_amd_fam15h_spec;
                                 cpu_type = "x86-64/family15h";
                                 break;
+                        case 0x16:
+                                model = &op_athlon_spec;
+                                cpu_type = "x86-64/family16h";
+                                break;
 			}
 			break;
 
-- 
1.7.10.4



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 08 23:51:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 23:51: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 1U3xiW-0004l6-Ol; Fri, 08 Feb 2013 23:50:52 +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 1U3xiV-0004l1-BV
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 23:50:51 +0000
Received: from [85.158.143.99:28389] by server-1.bemta-4.messagelabs.com id
	57/34-08839-A5F85115; Fri, 08 Feb 2013 23:50:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360367448!25108736!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjQzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16509 invoked from network); 8 Feb 2013 23:50:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 23:50:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r18NojkS004492
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Feb 2013 23:50:46 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
	r18Nojip024173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 23:50:45 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
	r18NoiNu031210; Fri, 8 Feb 2013 17:50:44 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Feb 2013 15:50:44 -0800
Date: Fri, 8 Feb 2013 15:50:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Message-ID: <20130208155043.04f99410@mantra.us.oracle.com>
In-Reply-To: <20130207105425.GA1597@elgon.mountain>
References: <20130207105425.GA1597@elgon.mountain>
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]
Cc: kbuild@01.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/pvh linux: Use ballooning to allocate grant
	table 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

On Thu, 7 Feb 2013 13:54:25 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> Hello Mukesh Rathor,
> 
> The patch 40f633eb0def: "xen/pvh linux: Use ballooning to allocate
> grant table pages" from Jan 31, 2013, leads to the following Sparse
> warning: "drivers/xen/grant-table.c:1095:28: error: bad constant
> 	expression"
> 
> drivers/xen/grant-table.c
>   1092  static int xlated_setup_gnttab_pages(int numpages, void
> **addr) 1093  {
>   1094          int i, rc;
>   1095          unsigned long pfns[numpages];
>   1096          struct page *pages[numpages];
>                                    ^^^^^^^^
> Because the kernel uses an 8k stack if this is over 500 it will cause
> a kernel crash.  It will crash before we reach 500 actually.  It looks
> like typical values for this are around 4 so we're probably safe, but
> it's still a bit nasty.
> 
>   1097  
>   1098          rc = alloc_xenballooned_pages(numpages, pages, 0);
>   1099          if (rc != 0) {
>   1100                  pr_warn("%s Could not balloon alloc %d pfns
> rc:%d\n", __func__,
> 
> regards,
> dan carpenter

Hi Dan,

Yeah, I know. Currently, there is a hard max on num of grant pages to
32, but on average are lot less. So I think it should be OK. Konrad, do
you still want me to change it to kmalloc?

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 Feb 08 23:51:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 08 Feb 2013 23:51: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 1U3xiW-0004l6-Ol; Fri, 08 Feb 2013 23:50:52 +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 1U3xiV-0004l1-BV
	for xen-devel@lists.xensource.com; Fri, 08 Feb 2013 23:50:51 +0000
Received: from [85.158.143.99:28389] by server-1.bemta-4.messagelabs.com id
	57/34-08839-A5F85115; Fri, 08 Feb 2013 23:50:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360367448!25108736!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjQzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16509 invoked from network); 8 Feb 2013 23:50:49 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Feb 2013 23:50:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r18NojkS004492
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 8 Feb 2013 23:50:46 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
	r18Nojip024173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 8 Feb 2013 23:50:45 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
	r18NoiNu031210; Fri, 8 Feb 2013 17:50:44 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Feb 2013 15:50:44 -0800
Date: Fri, 8 Feb 2013 15:50:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Message-ID: <20130208155043.04f99410@mantra.us.oracle.com>
In-Reply-To: <20130207105425.GA1597@elgon.mountain>
References: <20130207105425.GA1597@elgon.mountain>
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]
Cc: kbuild@01.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/pvh linux: Use ballooning to allocate grant
	table 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

On Thu, 7 Feb 2013 13:54:25 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> Hello Mukesh Rathor,
> 
> The patch 40f633eb0def: "xen/pvh linux: Use ballooning to allocate
> grant table pages" from Jan 31, 2013, leads to the following Sparse
> warning: "drivers/xen/grant-table.c:1095:28: error: bad constant
> 	expression"
> 
> drivers/xen/grant-table.c
>   1092  static int xlated_setup_gnttab_pages(int numpages, void
> **addr) 1093  {
>   1094          int i, rc;
>   1095          unsigned long pfns[numpages];
>   1096          struct page *pages[numpages];
>                                    ^^^^^^^^
> Because the kernel uses an 8k stack if this is over 500 it will cause
> a kernel crash.  It will crash before we reach 500 actually.  It looks
> like typical values for this are around 4 so we're probably safe, but
> it's still a bit nasty.
> 
>   1097  
>   1098          rc = alloc_xenballooned_pages(numpages, pages, 0);
>   1099          if (rc != 0) {
>   1100                  pr_warn("%s Could not balloon alloc %d pfns
> rc:%d\n", __func__,
> 
> regards,
> dan carpenter

Hi Dan,

Yeah, I know. Currently, there is a hard max on num of grant pages to
32, but on average are lot less. So I think it should be OK. Konrad, do
you still want me to change it to kmalloc?

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 Feb 09 00:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 00: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 1U3xzo-0005yi-Ck; Sat, 09 Feb 2013 00:08: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 1U3xzm-0005yd-EW
	for xen-devel@lists.xensource.com; Sat, 09 Feb 2013 00:08:42 +0000
Received: from [85.158.139.83:44185] by server-15.bemta-5.messagelabs.com id
	7A/FD-18914-98395115; Sat, 09 Feb 2013 00:08:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360368520!20604794!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29649 invoked from network); 9 Feb 2013 00:08:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 00:08:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; 
   d="scan'208";a="1299811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2013 00:08: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.297.1; Sat, 9 Feb 2013 00:08:40 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3xzj-0006hb-Px;
	Sat, 09 Feb 2013 00:08:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3xzj-0006Vw-Mt;
	Sat, 09 Feb 2013 00:08:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15450-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Feb 2013 00:08:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15450: regressions - 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 15450 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15450/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv            14 guest-localmigrate/x10    fail REGR. vs. 15434
 test-amd64-i386-qemut-win 12 guest-localmigrate/x10 fail REGR. vs. 15466-bisect
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15434
 test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15434
 test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 15434
 test-i386-i386-qemut-win      7 windows-install           fail REGR. vs. 15434
 test-i386-i386-win           11 guest-localmigrate.2      fail REGR. vs. 15434
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15434
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15434
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15434

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          13 guest-localmigrate.2        fail pass in 15445
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15445 pass in 15465-bisect
 test-amd64-i386-win           7 windows-install    fail in 15445 pass in 15450
 test-amd64-amd64-win          7 windows-install    fail in 15445 pass in 15450
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15445 pass in 15450

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15434

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-xl-qemut-win  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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c713f1f7d3c1
baseline version:
 xen                  b8a523d9f14c

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
+ revision=c713f1f7d3c1
+ . 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.2-testing c713f1f7d3c1
+ branch=xen-4.2-testing
+ revision=c713f1f7d3c1
+ . 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.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-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.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r c713f1f7d3c1 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 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 Sat Feb 09 00:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 00: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 1U3xzo-0005yi-Ck; Sat, 09 Feb 2013 00:08: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 1U3xzm-0005yd-EW
	for xen-devel@lists.xensource.com; Sat, 09 Feb 2013 00:08:42 +0000
Received: from [85.158.139.83:44185] by server-15.bemta-5.messagelabs.com id
	7A/FD-18914-98395115; Sat, 09 Feb 2013 00:08:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360368520!20604794!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29649 invoked from network); 9 Feb 2013 00:08:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 00:08:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; 
   d="scan'208";a="1299811"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2013 00:08: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.297.1; Sat, 9 Feb 2013 00:08:40 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U3xzj-0006hb-Px;
	Sat, 09 Feb 2013 00:08:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U3xzj-0006Vw-Mt;
	Sat, 09 Feb 2013 00:08:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15450-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Feb 2013 00:08:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 15450: regressions - 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 15450 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15450/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv            14 guest-localmigrate/x10    fail REGR. vs. 15434
 test-amd64-i386-qemut-win 12 guest-localmigrate/x10 fail REGR. vs. 15466-bisect
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15434
 test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15434
 test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 15434
 test-i386-i386-qemut-win      7 windows-install           fail REGR. vs. 15434
 test-i386-i386-win           11 guest-localmigrate.2      fail REGR. vs. 15434
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15434
 test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15434
 test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15434

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          13 guest-localmigrate.2        fail pass in 15445
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15445 pass in 15465-bisect
 test-amd64-i386-win           7 windows-install    fail in 15445 pass in 15450
 test-amd64-amd64-win          7 windows-install    fail in 15445 pass in 15450
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15445 pass in 15450

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15434

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-xl-qemut-win  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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c713f1f7d3c1
baseline version:
 xen                  b8a523d9f14c

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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                                            fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
+ revision=c713f1f7d3c1
+ . 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.2-testing c713f1f7d3c1
+ branch=xen-4.2-testing
+ revision=c713f1f7d3c1
+ . 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.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-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.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r c713f1f7d3c1 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 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 Sat Feb 09 03:30:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 03: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 1U4188-00085a-C4; Sat, 09 Feb 2013 03:29:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U4186-00085V-RI
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 03:29:31 +0000
Received: from [85.158.138.51:53728] by server-1.bemta-3.messagelabs.com id
	B4/48-08955-092C5115; Sat, 09 Feb 2013 03:29:20 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360380559!21412191!1
X-Originating-IP: [209.85.212.177]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15474 invoked from network); 9 Feb 2013 03:29:19 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 03:29:19 -0000
Received: by mail-wi0-f177.google.com with SMTP id hm14so1528734wib.16
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 19:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=7XOF0NxgIrqLvK8XZCYNlqgapn2+VmvjbiCKXXKTpD8=;
	b=h1aYGlLBfJ91QGLTKKAUFMwC1tgnhMFZ1aFyTGvnC0ajLiJl7e95MgUXSQdqYslQcx
	03Mt9qxUcwBuG9fOqvsuEl/BKvvrZCJ6sLWNnWeP+rfMRx9RhwZwa2i0WUTsX0ol3UbG
	wCtkuGPqQYeY6jWJz2MJG0uiY+MO2T00+n69XNiqlItPfhqpnCu5jDfvG9OGRhy/fz8/
	HdQCpm5VqIZUUmcPePCnLIZ2GUOPYO4KStSnCsih2PGTg93SN7maag+9K8xFjgiM47Z6
	lZqOGcTbtzhLdBJ8VBfojYgSMfeps7++JxxUp5Z+ZTkHjUWSwhpG3GPU0WANNfk2ZcwP
	wiVw==
MIME-Version: 1.0
X-Received: by 10.180.81.164 with SMTP id b4mr5885722wiy.34.1360380559074;
	Fri, 08 Feb 2013 19:29:19 -0800 (PST)
Received: by 10.194.240.168 with HTTP; Fri, 8 Feb 2013 19:29:18 -0800 (PST)
Date: Fri, 8 Feb 2013 22:29:18 -0500
Message-ID: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] bug fix in configure 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="===============5847188852465741537=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5847188852465741537==
Content-Type: multipart/alternative; boundary=14dae9cc9fbefba59004d5424727

--14dae9cc9fbefba59004d5424727
Content-Type: text/plain; charset=ISO-8859-1

The end of if is at the wrong place.

Signed-off-by: Shakeel Butt <shakeel.butt@gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
# HG changeset patch
# Parent 6c1b12c884b4521a940e079c8dfebc5d8e88d2e9

diff -r 6c1b12c884b4 configure
--- a/configure
+++ b/configure
@@ -2000,6 +2000,8 @@ stubdom=n

 fi

+fi
+
 if test -e "stubdom/configure"; then :

 if test "x$stubdom" = "xy" || test "x$stubdom" = "x" ; then
@@ -2011,9 +2013,6 @@ fi



-fi
-
-

 # Check whether --enable-docs was given.
 if test "${enable_docs+set}" = set; then :

--14dae9cc9fbefba59004d5424727
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>The end of if is at the wrong place.</div><div =
style><br></div><div style><span style=3D"font-family:arial,sans-serif;font=
-size:12.800000190734863px">Signed-off-by: Shakeel Butt &lt;<a href=3D"mail=
to:shakeel.butt@gmail.com">shakeel.butt@gmail.com</a>&gt;</span><br>
</div><div style><span style=3D"font-family:arial,sans-serif;font-size:12.8=
00000190734863px">Cc:=A0</span><span style=3D"font-family:arial,sans-serif;=
font-size:12.800000190734863px">Ian Campbell &lt;</span><a href=3D"mailto:i=
an.campbell@citrix.com">ian.campbell@citrix.com</a><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.800000190734863px">&gt;</span></div>
<div style>---</div><div># HG changeset patch</div><div># Parent 6c1b12c884=
b4521a940e079c8dfebc5d8e88d2e9</div><div><br></div><div>diff -r 6c1b12c884b=
4 configure</div><div>--- a/configure</div><div>+++ b/configure</div><div>
@@ -2000,6 +2000,8 @@ stubdom=3Dn</div><div>=A0</div><div>=A0fi</div><div>=
=A0</div><div>+fi</div><div>+</div><div>=A0if test -e &quot;stubdom/configu=
re&quot;; then :</div><div>=A0</div><div>=A0if test &quot;x$stubdom&quot; =
=3D &quot;xy&quot; || test &quot;x$stubdom&quot; =3D &quot;x&quot; ; then</=
div>
<div>@@ -2011,9 +2013,6 @@ fi</div><div>=A0</div><div>=A0</div><div>=A0</di=
v><div>-fi</div><div>-</div><div>-</div><div>=A0</div><div>=A0# Check wheth=
er --enable-docs was given.</div><div>=A0if test &quot;${enable_docs+set}&q=
uot; =3D set; then :</div>
<div><br></div></div>

--14dae9cc9fbefba59004d5424727--


--===============5847188852465741537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5847188852465741537==--


From xen-devel-bounces@lists.xen.org Sat Feb 09 03:30:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 03: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 1U4188-00085a-C4; Sat, 09 Feb 2013 03:29:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U4186-00085V-RI
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 03:29:31 +0000
Received: from [85.158.138.51:53728] by server-1.bemta-3.messagelabs.com id
	B4/48-08955-092C5115; Sat, 09 Feb 2013 03:29:20 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360380559!21412191!1
X-Originating-IP: [209.85.212.177]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15474 invoked from network); 9 Feb 2013 03:29:19 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 03:29:19 -0000
Received: by mail-wi0-f177.google.com with SMTP id hm14so1528734wib.16
	for <xen-devel@lists.xen.org>; Fri, 08 Feb 2013 19:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=7XOF0NxgIrqLvK8XZCYNlqgapn2+VmvjbiCKXXKTpD8=;
	b=h1aYGlLBfJ91QGLTKKAUFMwC1tgnhMFZ1aFyTGvnC0ajLiJl7e95MgUXSQdqYslQcx
	03Mt9qxUcwBuG9fOqvsuEl/BKvvrZCJ6sLWNnWeP+rfMRx9RhwZwa2i0WUTsX0ol3UbG
	wCtkuGPqQYeY6jWJz2MJG0uiY+MO2T00+n69XNiqlItPfhqpnCu5jDfvG9OGRhy/fz8/
	HdQCpm5VqIZUUmcPePCnLIZ2GUOPYO4KStSnCsih2PGTg93SN7maag+9K8xFjgiM47Z6
	lZqOGcTbtzhLdBJ8VBfojYgSMfeps7++JxxUp5Z+ZTkHjUWSwhpG3GPU0WANNfk2ZcwP
	wiVw==
MIME-Version: 1.0
X-Received: by 10.180.81.164 with SMTP id b4mr5885722wiy.34.1360380559074;
	Fri, 08 Feb 2013 19:29:19 -0800 (PST)
Received: by 10.194.240.168 with HTTP; Fri, 8 Feb 2013 19:29:18 -0800 (PST)
Date: Fri, 8 Feb 2013 22:29:18 -0500
Message-ID: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] bug fix in configure 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="===============5847188852465741537=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5847188852465741537==
Content-Type: multipart/alternative; boundary=14dae9cc9fbefba59004d5424727

--14dae9cc9fbefba59004d5424727
Content-Type: text/plain; charset=ISO-8859-1

The end of if is at the wrong place.

Signed-off-by: Shakeel Butt <shakeel.butt@gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
# HG changeset patch
# Parent 6c1b12c884b4521a940e079c8dfebc5d8e88d2e9

diff -r 6c1b12c884b4 configure
--- a/configure
+++ b/configure
@@ -2000,6 +2000,8 @@ stubdom=n

 fi

+fi
+
 if test -e "stubdom/configure"; then :

 if test "x$stubdom" = "xy" || test "x$stubdom" = "x" ; then
@@ -2011,9 +2013,6 @@ fi



-fi
-
-

 # Check whether --enable-docs was given.
 if test "${enable_docs+set}" = set; then :

--14dae9cc9fbefba59004d5424727
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>The end of if is at the wrong place.</div><div =
style><br></div><div style><span style=3D"font-family:arial,sans-serif;font=
-size:12.800000190734863px">Signed-off-by: Shakeel Butt &lt;<a href=3D"mail=
to:shakeel.butt@gmail.com">shakeel.butt@gmail.com</a>&gt;</span><br>
</div><div style><span style=3D"font-family:arial,sans-serif;font-size:12.8=
00000190734863px">Cc:=A0</span><span style=3D"font-family:arial,sans-serif;=
font-size:12.800000190734863px">Ian Campbell &lt;</span><a href=3D"mailto:i=
an.campbell@citrix.com">ian.campbell@citrix.com</a><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.800000190734863px">&gt;</span></div>
<div style>---</div><div># HG changeset patch</div><div># Parent 6c1b12c884=
b4521a940e079c8dfebc5d8e88d2e9</div><div><br></div><div>diff -r 6c1b12c884b=
4 configure</div><div>--- a/configure</div><div>+++ b/configure</div><div>
@@ -2000,6 +2000,8 @@ stubdom=3Dn</div><div>=A0</div><div>=A0fi</div><div>=
=A0</div><div>+fi</div><div>+</div><div>=A0if test -e &quot;stubdom/configu=
re&quot;; then :</div><div>=A0</div><div>=A0if test &quot;x$stubdom&quot; =
=3D &quot;xy&quot; || test &quot;x$stubdom&quot; =3D &quot;x&quot; ; then</=
div>
<div>@@ -2011,9 +2013,6 @@ fi</div><div>=A0</div><div>=A0</div><div>=A0</di=
v><div>-fi</div><div>-</div><div>-</div><div>=A0</div><div>=A0# Check wheth=
er --enable-docs was given.</div><div>=A0if test &quot;${enable_docs+set}&q=
uot; =3D set; then :</div>
<div><br></div></div>

--14dae9cc9fbefba59004d5424727--


--===============5847188852465741537==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5847188852465741537==--


From xen-devel-bounces@lists.xen.org Sat Feb 09 05:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 05:03: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 1U42aX-0002q9-TB; Sat, 09 Feb 2013 05:02:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1U42aW-0002q4-0I
	for xen-devel@lists.xensource.com; Sat, 09 Feb 2013 05:02:56 +0000
Received: from [85.158.143.99:54253] by server-2.bemta-4.messagelabs.com id
	43/1C-01597-F78D5115; Sat, 09 Feb 2013 05:02:55 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360386173!24541338!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE0OTI5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11077 invoked from network); 9 Feb 2013 05:02:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2013 05:02:54 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1952oWv016591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 9 Feb 2013 05:02:51 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
	r1952oC1002576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 9 Feb 2013 05:02:50 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
	r1952nvR011721; Fri, 8 Feb 2013 23:02:50 -0600
Received: from mwanda (/41.212.103.53) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Feb 2013 21:02:48 -0800
Date: Sat, 9 Feb 2013 08:02:48 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130209050248.GB4989@mwanda>
References: <20130207105425.GA1597@elgon.mountain>
	<20130208155043.04f99410@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130208155043.04f99410@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kbuild@01.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/pvh linux: Use ballooning to allocate grant
	table 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

On Fri, Feb 08, 2013 at 03:50:43PM -0800, Mukesh Rathor wrote:
> On Thu, 7 Feb 2013 13:54:25 +0300
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 
> > Hello Mukesh Rathor,
> > 
> > The patch 40f633eb0def: "xen/pvh linux: Use ballooning to allocate
> > grant table pages" from Jan 31, 2013, leads to the following Sparse
> > warning: "drivers/xen/grant-table.c:1095:28: error: bad constant
> > 	expression"
> > 
> > drivers/xen/grant-table.c
> >   1092  static int xlated_setup_gnttab_pages(int numpages, void
> > **addr) 1093  {
> >   1094          int i, rc;
> >   1095          unsigned long pfns[numpages];
> >   1096          struct page *pages[numpages];
> >                                    ^^^^^^^^
> > Because the kernel uses an 8k stack if this is over 500 it will cause
> > a kernel crash.  It will crash before we reach 500 actually.  It looks
> > like typical values for this are around 4 so we're probably safe, but
> > it's still a bit nasty.
> > 
> >   1097  
> >   1098          rc = alloc_xenballooned_pages(numpages, pages, 0);
> >   1099          if (rc != 0) {
> >   1100                  pr_warn("%s Could not balloon alloc %d pfns
> > rc:%d\n", __func__,
> > 
> > regards,
> > dan carpenter
> 
> Hi Dan,
> 
> Yeah, I know. Currently, there is a hard max on num of grant pages to
> 32, but on average are lot less. So I think it should be OK. Konrad, do
> you still want me to change it to kmalloc?

If there is a hard limit then it should be ok.

The place where dynamically allocated arrays are forbiden is inside
loops.  On some arches the stack memory isn't freed until the end of
the function.

regards,
dan carpenter

> 
> 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 Feb 09 05:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 05:03: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 1U42aX-0002q9-TB; Sat, 09 Feb 2013 05:02:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1U42aW-0002q4-0I
	for xen-devel@lists.xensource.com; Sat, 09 Feb 2013 05:02:56 +0000
Received: from [85.158.143.99:54253] by server-2.bemta-4.messagelabs.com id
	43/1C-01597-F78D5115; Sat, 09 Feb 2013 05:02:55 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360386173!24541338!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE0OTI5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11077 invoked from network); 9 Feb 2013 05:02:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Feb 2013 05:02:54 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1952oWv016591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 9 Feb 2013 05:02:51 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
	r1952oC1002576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 9 Feb 2013 05:02:50 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
	r1952nvR011721; Fri, 8 Feb 2013 23:02:50 -0600
Received: from mwanda (/41.212.103.53) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 08 Feb 2013 21:02:48 -0800
Date: Sat, 9 Feb 2013 08:02:48 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130209050248.GB4989@mwanda>
References: <20130207105425.GA1597@elgon.mountain>
	<20130208155043.04f99410@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130208155043.04f99410@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kbuild@01.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xen/pvh linux: Use ballooning to allocate grant
	table 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

On Fri, Feb 08, 2013 at 03:50:43PM -0800, Mukesh Rathor wrote:
> On Thu, 7 Feb 2013 13:54:25 +0300
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 
> > Hello Mukesh Rathor,
> > 
> > The patch 40f633eb0def: "xen/pvh linux: Use ballooning to allocate
> > grant table pages" from Jan 31, 2013, leads to the following Sparse
> > warning: "drivers/xen/grant-table.c:1095:28: error: bad constant
> > 	expression"
> > 
> > drivers/xen/grant-table.c
> >   1092  static int xlated_setup_gnttab_pages(int numpages, void
> > **addr) 1093  {
> >   1094          int i, rc;
> >   1095          unsigned long pfns[numpages];
> >   1096          struct page *pages[numpages];
> >                                    ^^^^^^^^
> > Because the kernel uses an 8k stack if this is over 500 it will cause
> > a kernel crash.  It will crash before we reach 500 actually.  It looks
> > like typical values for this are around 4 so we're probably safe, but
> > it's still a bit nasty.
> > 
> >   1097  
> >   1098          rc = alloc_xenballooned_pages(numpages, pages, 0);
> >   1099          if (rc != 0) {
> >   1100                  pr_warn("%s Could not balloon alloc %d pfns
> > rc:%d\n", __func__,
> > 
> > regards,
> > dan carpenter
> 
> Hi Dan,
> 
> Yeah, I know. Currently, there is a hard max on num of grant pages to
> 32, but on average are lot less. So I think it should be OK. Konrad, do
> you still want me to change it to kmalloc?

If there is a hard limit then it should be ok.

The place where dynamically allocated arrays are forbiden is inside
loops.  On some arches the stack memory isn't freed until the end of
the function.

regards,
dan carpenter

> 
> 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 Feb 09 07:01:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 07: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 1U44Qe-00060Q-GL; Sat, 09 Feb 2013 07:00: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 1U44Qd-00060L-4d
	for xen-devel@lists.xensource.com; Sat, 09 Feb 2013 07:00:51 +0000
Received: from [85.158.138.51:50840] by server-9.bemta-3.messagelabs.com id
	03/F6-09484-224F5115; Sat, 09 Feb 2013 07:00:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360393249!28295471!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNTk3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30613 invoked from network); 9 Feb 2013 07:00:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 07:00:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,634,1355097600"; 
   d="scan'208";a="1302269"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2013 07:00: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.297.1; Sat, 9 Feb 2013 07:00:48 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U44Qa-0000MU-Iy;
	Sat, 09 Feb 2013 07:00:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U44Qa-00011U-IX;
	Sat, 09 Feb 2013 07:00:48 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15452-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Feb 2013 07:00:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15452: 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 15452 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15452/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 15442
 test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15442
 test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail REGR. vs. 15442
 test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install    fail REGR. vs. 15442
 test-amd64-i386-qemut-win    11 guest-localmigrate.2      fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Sat Feb 09 07:01:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 07: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 1U44Qe-00060Q-GL; Sat, 09 Feb 2013 07:00: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 1U44Qd-00060L-4d
	for xen-devel@lists.xensource.com; Sat, 09 Feb 2013 07:00:51 +0000
Received: from [85.158.138.51:50840] by server-9.bemta-3.messagelabs.com id
	03/F6-09484-224F5115; Sat, 09 Feb 2013 07:00:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360393249!28295471!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNTk3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30613 invoked from network); 9 Feb 2013 07:00:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 07:00:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,634,1355097600"; 
   d="scan'208";a="1302269"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Feb 2013 07:00: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.297.1; Sat, 9 Feb 2013 07:00:48 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U44Qa-0000MU-Iy;
	Sat, 09 Feb 2013 07:00:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U44Qa-00011U-IX;
	Sat, 09 Feb 2013 07:00:48 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15452-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 9 Feb 2013 07:00:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15452: 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 15452 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15452/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 15442
 test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15442
 test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail REGR. vs. 15442
 test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install    fail REGR. vs. 15442
 test-amd64-i386-qemut-win    11 guest-localmigrate.2      fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Sat Feb 09 12:39:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 12:39: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 1U49hX-0008ON-Hx; Sat, 09 Feb 2013 12:38:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U49hV-0008OF-JR; Sat, 09 Feb 2013 12:38:37 +0000
Received: from [85.158.139.211:61922] by server-7.bemta-5.messagelabs.com id
	B0/12-11121-C4346115; Sat, 09 Feb 2013 12:38:36 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360413514!21770854!1
X-Originating-IP: [209.85.216.48]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 9 Feb 2013 12:38:35 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 12:38:35 -0000
Received: by mail-qa0-f48.google.com with SMTP id j8so655588qah.7
	for <multiple recipients>; Sat, 09 Feb 2013 04:38:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=OEiCj3TyRc5wMW9y95MZySVOfgeNrWxmTKlb/cU/ob0=;
	b=X3k8j1DxouxrttHAZ8JuzpLekv5TVoAk4+Wwjdsi36HGtYhApTl4ym82DFRAbA6XBq
	7EsjJqM7o47mIwH86glflI8SwXgPbwMkPTtwZCgddiiw+OabPxK4iyHdHkUjkmLd4LkW
	j85PqWpRvE6gDM09rQESrmjlxGkqF3Bc+J4kLLJdG/KD+16vNg6CytbuO4+XXlgrtOzo
	GZax/1N8hCh9RLdb86rMWvF5MV0XtiId4dky7iTeycTzoDEx/wzYOtv4baSt0NSPhHJk
	74HN9+Zb2MlTTvyX3kxCUvMMNlj5VFm8qaIU1JjKnuOYWVUHdqieoO9FopCP/6U8PGY6
	nRRA==
MIME-Version: 1.0
X-Received: by 10.224.111.83 with SMTP id r19mr3246873qap.39.1360413514498;
	Sat, 09 Feb 2013 04:38:34 -0800 (PST)
Received: by 10.49.110.70 with HTTP; Sat, 9 Feb 2013 04:38:34 -0800 (PST)
Date: Sat, 9 Feb 2013 13:38:34 +0100
Message-ID: <CAMCOOJsH8vX-=fXM0xm0rqei_QVgo3X-Vcu70XjtTQkXe+5-7A@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: port-xen@netbsd.org, xen-users <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.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: multipart/mixed; boundary="===============3546161593467617247=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3546161593467617247==
Content-Type: multipart/alternative; boundary=20cf306f77a847833704d549f4a8

--20cf306f77a847833704d549f4a8
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I try to build Xen 4.2.1 on NetBSD 6.0.1 with vTPM. I would say that
dependencies are missing but I don't know it.

I have done the following:

I installed the building dependencies from pkgsrc

Run configure as follows:

./configure PYTHON=/usr/pkg/bin/python2.7
APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib
--prefix=/usr/xen42 --enable-vtpm

Builded Xen itself successfully.

Run gmake for the tools target as follows:

gmake LD_LIBRARY_PATH=/usr/pkg/lib tools

This fails with the following error:

gmake[5]: Entering directory `/root/xen-4.2.1/tools/vtpm_manager/manager'
gcc  -Werror -g3 -D_GNU_SOURCE
-DLOGGING_MODULES="(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_VTPM))"
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/crypto
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/util
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/tcs
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/manager
-pthread  -c -o vtpmd.o vtpmd.c  -I/usr/pkg/include
cc1: warnings being treated as errors
vtpmd.c: In function 'signal_handler':
vtpmd.c:96:3: error: passing argument 2 of '__libc_thr_equal' makes
pointer from integer without a cast
/usr/include/pthread.h:368:5: note: expected 'pthread_t' but argument
is of type '__pid_t'
vtpmd.c: In function 'main':
vtpmd.c:343:28: error: assignment makes integer from pointer without a cast
gmake[5]: *** [vtpmd.o] Error 1
gmake[5]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager/manager'
gmake[4]: *** [subdir-install-manager] Error 2
gmake[4]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'
gmake[3]: *** [subdirs-install] Error 2
gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'
gmake[2]: *** [subdir-install-vtpm_manager] Error 2
gmake[2]: Leaving directory `/root/xen-4.2.1/tools'
gmake[1]: *** [subdirs-install] Error 2
gmake[1]: Leaving directory `/root/xen-4.2.1/tools'
gmake: *** [install-tools] Error 2

So I know that already one dependency is missing I think it's libgmp
but I found no way to build it on NetBSD.

Is vTPM buildable on NetBSD and what does this error/warning which was
treated as error mean?

Best Regards

--20cf306f77a847833704d549f4a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>Hello all,<br><br>I try to build Xen 4=
.2.1 on NetBSD 6.0.1 with vTPM. I would say that dependencies are missing b=
ut I don&#39;t know it.<br><br></div><div>I have done the following:<br><br=
>
</div><div>I installed the building dependencies from pkgsrc<br><br></div><=
div>Run configure as follows: <br><pre>./configure PYTHON=3D/usr/pkg/bin/py=
thon2.7 APPEND_INCLUDES=3D/usr/pkg/include APPEND_LIB=3D/usr/pkg/lib --pref=
ix=3D/usr/xen42 --enable-vtpm<br>
<br></pre><pre>Builded Xen itself successfully.<br><br></pre><pre>Run gmake=
 for the tools target as follows: <br><br>gmake LD_LIBRARY_PATH=3D/usr/pkg/=
lib tools<br><br></pre><pre>This fails with the following error:<br><br></p=
re>
<pre>gmake[5]: Entering directory `/root/xen-4.2.1/tools/vtpm_manager/manag=
er&#39;<br>gcc  -Werror -g3 -D_GNU_SOURCE -DLOGGING_MODULES=3D&quot;(BITMAS=
K(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_VTPM))&quot; -I/roo=
t/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/crypto -=
I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/uti=
l -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/=
tcs -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manage=
r/manager -pthread  -c -o vtpmd.o vtpmd.c  -I/usr/pkg/include<br>
cc1: warnings being treated as errors<br>vtpmd.c: In function &#39;signal_h=
andler&#39;:<br>vtpmd.c:96:3: error: passing argument 2 of &#39;__libc_thr_=
equal&#39; makes pointer from integer without a cast<br>/usr/include/pthrea=
d.h:368:5: note: expected &#39;pthread_t&#39; but argument is of type &#39;=
__pid_t&#39;<br>
vtpmd.c: In function &#39;main&#39;:<br>vtpmd.c:343:28: error: assignment m=
akes integer from pointer without a cast<br>gmake[5]: *** [vtpmd.o] Error 1=
<br>gmake[5]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager/manager=
&#39;<br>
gmake[4]: *** [subdir-install-manager] Error 2<br>gmake[4]: Leaving directo=
ry `/root/xen-4.2.1/tools/vtpm_manager&#39;<br>gmake[3]: *** [subdirs-insta=
ll] Error 2<br>gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_mana=
ger&#39;<br>
gmake[2]: *** [subdir-install-vtpm_manager] Error 2<br>gmake[2]: Leaving di=
rectory `/root/xen-4.2.1/tools&#39;<br>gmake[1]: *** [subdirs-install] Erro=
r 2<br>gmake[1]: Leaving directory `/root/xen-4.2.1/tools&#39;<br>gmake: **=
* [install-tools] Error 2<br>
<br></pre><pre>So I know that already one dependency is missing I think it&=
#39;s libgmp but I found no way to build it on NetBSD.<br><br></pre><pre>Is=
 vTPM buildable on NetBSD and what does this error/warning which was treate=
d as error mean?<br>
<br></pre><pre>Best Regards<br></pre></div></div>

--20cf306f77a847833704d549f4a8--


--===============3546161593467617247==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3546161593467617247==--


From xen-devel-bounces@lists.xen.org Sat Feb 09 12:39:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 12:39: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 1U49hX-0008ON-Hx; Sat, 09 Feb 2013 12:38:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mailinglists.tech@gmail.com>)
	id 1U49hV-0008OF-JR; Sat, 09 Feb 2013 12:38:37 +0000
Received: from [85.158.139.211:61922] by server-7.bemta-5.messagelabs.com id
	B0/12-11121-C4346115; Sat, 09 Feb 2013 12:38:36 +0000
X-Env-Sender: mailinglists.tech@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360413514!21770854!1
X-Originating-IP: [209.85.216.48]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3567 invoked from network); 9 Feb 2013 12:38:35 -0000
Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com)
	(209.85.216.48)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 12:38:35 -0000
Received: by mail-qa0-f48.google.com with SMTP id j8so655588qah.7
	for <multiple recipients>; Sat, 09 Feb 2013 04:38:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=OEiCj3TyRc5wMW9y95MZySVOfgeNrWxmTKlb/cU/ob0=;
	b=X3k8j1DxouxrttHAZ8JuzpLekv5TVoAk4+Wwjdsi36HGtYhApTl4ym82DFRAbA6XBq
	7EsjJqM7o47mIwH86glflI8SwXgPbwMkPTtwZCgddiiw+OabPxK4iyHdHkUjkmLd4LkW
	j85PqWpRvE6gDM09rQESrmjlxGkqF3Bc+J4kLLJdG/KD+16vNg6CytbuO4+XXlgrtOzo
	GZax/1N8hCh9RLdb86rMWvF5MV0XtiId4dky7iTeycTzoDEx/wzYOtv4baSt0NSPhHJk
	74HN9+Zb2MlTTvyX3kxCUvMMNlj5VFm8qaIU1JjKnuOYWVUHdqieoO9FopCP/6U8PGY6
	nRRA==
MIME-Version: 1.0
X-Received: by 10.224.111.83 with SMTP id r19mr3246873qap.39.1360413514498;
	Sat, 09 Feb 2013 04:38:34 -0800 (PST)
Received: by 10.49.110.70 with HTTP; Sat, 9 Feb 2013 04:38:34 -0800 (PST)
Date: Sat, 9 Feb 2013 13:38:34 +0100
Message-ID: <CAMCOOJsH8vX-=fXM0xm0rqei_QVgo3X-Vcu70XjtTQkXe+5-7A@mail.gmail.com>
From: tech mailinglists <mailinglists.tech@gmail.com>
To: port-xen@netbsd.org, xen-users <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.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: multipart/mixed; boundary="===============3546161593467617247=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3546161593467617247==
Content-Type: multipart/alternative; boundary=20cf306f77a847833704d549f4a8

--20cf306f77a847833704d549f4a8
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I try to build Xen 4.2.1 on NetBSD 6.0.1 with vTPM. I would say that
dependencies are missing but I don't know it.

I have done the following:

I installed the building dependencies from pkgsrc

Run configure as follows:

./configure PYTHON=/usr/pkg/bin/python2.7
APPEND_INCLUDES=/usr/pkg/include APPEND_LIB=/usr/pkg/lib
--prefix=/usr/xen42 --enable-vtpm

Builded Xen itself successfully.

Run gmake for the tools target as follows:

gmake LD_LIBRARY_PATH=/usr/pkg/lib tools

This fails with the following error:

gmake[5]: Entering directory `/root/xen-4.2.1/tools/vtpm_manager/manager'
gcc  -Werror -g3 -D_GNU_SOURCE
-DLOGGING_MODULES="(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_VTPM))"
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/crypto
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/util
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/tcs
-I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/manager
-pthread  -c -o vtpmd.o vtpmd.c  -I/usr/pkg/include
cc1: warnings being treated as errors
vtpmd.c: In function 'signal_handler':
vtpmd.c:96:3: error: passing argument 2 of '__libc_thr_equal' makes
pointer from integer without a cast
/usr/include/pthread.h:368:5: note: expected 'pthread_t' but argument
is of type '__pid_t'
vtpmd.c: In function 'main':
vtpmd.c:343:28: error: assignment makes integer from pointer without a cast
gmake[5]: *** [vtpmd.o] Error 1
gmake[5]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager/manager'
gmake[4]: *** [subdir-install-manager] Error 2
gmake[4]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'
gmake[3]: *** [subdirs-install] Error 2
gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'
gmake[2]: *** [subdir-install-vtpm_manager] Error 2
gmake[2]: Leaving directory `/root/xen-4.2.1/tools'
gmake[1]: *** [subdirs-install] Error 2
gmake[1]: Leaving directory `/root/xen-4.2.1/tools'
gmake: *** [install-tools] Error 2

So I know that already one dependency is missing I think it's libgmp
but I found no way to build it on NetBSD.

Is vTPM buildable on NetBSD and what does this error/warning which was
treated as error mean?

Best Regards

--20cf306f77a847833704d549f4a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>Hello all,<br><br>I try to build Xen 4=
.2.1 on NetBSD 6.0.1 with vTPM. I would say that dependencies are missing b=
ut I don&#39;t know it.<br><br></div><div>I have done the following:<br><br=
>
</div><div>I installed the building dependencies from pkgsrc<br><br></div><=
div>Run configure as follows: <br><pre>./configure PYTHON=3D/usr/pkg/bin/py=
thon2.7 APPEND_INCLUDES=3D/usr/pkg/include APPEND_LIB=3D/usr/pkg/lib --pref=
ix=3D/usr/xen42 --enable-vtpm<br>
<br></pre><pre>Builded Xen itself successfully.<br><br></pre><pre>Run gmake=
 for the tools target as follows: <br><br>gmake LD_LIBRARY_PATH=3D/usr/pkg/=
lib tools<br><br></pre><pre>This fails with the following error:<br><br></p=
re>
<pre>gmake[5]: Entering directory `/root/xen-4.2.1/tools/vtpm_manager/manag=
er&#39;<br>gcc  -Werror -g3 -D_GNU_SOURCE -DLOGGING_MODULES=3D&quot;(BITMAS=
K(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_VTPM))&quot; -I/roo=
t/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/crypto -=
I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/uti=
l -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manager/=
tcs -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtpm_manage=
r/manager -pthread  -c -o vtpmd.o vtpmd.c  -I/usr/pkg/include<br>
cc1: warnings being treated as errors<br>vtpmd.c: In function &#39;signal_h=
andler&#39;:<br>vtpmd.c:96:3: error: passing argument 2 of &#39;__libc_thr_=
equal&#39; makes pointer from integer without a cast<br>/usr/include/pthrea=
d.h:368:5: note: expected &#39;pthread_t&#39; but argument is of type &#39;=
__pid_t&#39;<br>
vtpmd.c: In function &#39;main&#39;:<br>vtpmd.c:343:28: error: assignment m=
akes integer from pointer without a cast<br>gmake[5]: *** [vtpmd.o] Error 1=
<br>gmake[5]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager/manager=
&#39;<br>
gmake[4]: *** [subdir-install-manager] Error 2<br>gmake[4]: Leaving directo=
ry `/root/xen-4.2.1/tools/vtpm_manager&#39;<br>gmake[3]: *** [subdirs-insta=
ll] Error 2<br>gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_mana=
ger&#39;<br>
gmake[2]: *** [subdir-install-vtpm_manager] Error 2<br>gmake[2]: Leaving di=
rectory `/root/xen-4.2.1/tools&#39;<br>gmake[1]: *** [subdirs-install] Erro=
r 2<br>gmake[1]: Leaving directory `/root/xen-4.2.1/tools&#39;<br>gmake: **=
* [install-tools] Error 2<br>
<br></pre><pre>So I know that already one dependency is missing I think it&=
#39;s libgmp but I found no way to build it on NetBSD.<br><br></pre><pre>Is=
 vTPM buildable on NetBSD and what does this error/warning which was treate=
d as error mean?<br>
<br></pre><pre>Best Regards<br></pre></div></div>

--20cf306f77a847833704d549f4a8--


--===============3546161593467617247==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3546161593467617247==--


From xen-devel-bounces@lists.xen.org Sat Feb 09 17:45:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 17: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 1U4ETS-0007iX-R5; Sat, 09 Feb 2013 17:44:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen.list@daevel.fr>) id 1U4ETR-0007iS-TZ
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 17:44:26 +0000
Received: from [85.158.143.35:28870] by server-3.bemta-4.messagelabs.com id
	B6/38-08920-8FA86115; Sat, 09 Feb 2013 17:44:24 +0000
X-Env-Sender: xen.list@daevel.fr
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360431863!11390798!1
X-Originating-IP: [178.32.94.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2412 invoked from network); 9 Feb 2013 17:44:23 -0000
Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222)
	by server-11.tower-21.messagelabs.com with SMTP;
	9 Feb 2013 17:44:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daevel.fr;
	s=default; 
	h=Content-Transfer-Encoding:Mime-Version:Content-Type:Date:To:From:Subject:Message-ID;
	bh=SJUbvFCW4dHEAO1fuVt8+NCNNe2t5jHr3nsySPypDZ0=; 
	b=qXy9LBzifYrRP+9W9OKsCn6IOTa74CY+eKBHKiv/ikNdy6NSN8ucYgXTmCO822i0hBxpapFKnhSKC+wN8trDYNhFGi0EGC5uOROPhc6Z4Q7qzt1aqpUREutMFvMjajW/;
Received: from luuna.daevel.fr ([82.67.37.138] helo=[192.168.1.50])
	by licorne.daevel.fr with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1U4ETO-0001ja-Om
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 18:44:22 +0100
Message-ID: <1360431862.27289.8.camel@boolette.noo>
From: Olivier Bonvalet <xen.list@daevel.fr>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Sat, 09 Feb 2013 18:44:22 +0100
X-Mailer: Evolution 3.6.3-1 
Mime-Version: 1.0
Subject: [Xen-devel] [blkfront] max_segments & max_segment_size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 have (very) poor write performance with Xen PV, used over RBD, and I
suppose it's because of very short values for max_segments and
max_segment_size.
(I have 250MB/s write speed in Dom0 vs 40MB/s write speed in DomU)

>From what I read, there is already a patch to fix that, called "multi
page ring support for block devices" : 
   http://lists.xen.org/archives/html/xen-devel/2012-03/msg00388.html

But it doesn't seem to have been accepted.

So, does it exist an other solution to fix that kind of problem ?

Thanks,
Olivier


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 09 17:45:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 09 Feb 2013 17: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 1U4ETS-0007iX-R5; Sat, 09 Feb 2013 17:44:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen.list@daevel.fr>) id 1U4ETR-0007iS-TZ
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 17:44:26 +0000
Received: from [85.158.143.35:28870] by server-3.bemta-4.messagelabs.com id
	B6/38-08920-8FA86115; Sat, 09 Feb 2013 17:44:24 +0000
X-Env-Sender: xen.list@daevel.fr
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360431863!11390798!1
X-Originating-IP: [178.32.94.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2412 invoked from network); 9 Feb 2013 17:44:23 -0000
Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222)
	by server-11.tower-21.messagelabs.com with SMTP;
	9 Feb 2013 17:44:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daevel.fr;
	s=default; 
	h=Content-Transfer-Encoding:Mime-Version:Content-Type:Date:To:From:Subject:Message-ID;
	bh=SJUbvFCW4dHEAO1fuVt8+NCNNe2t5jHr3nsySPypDZ0=; 
	b=qXy9LBzifYrRP+9W9OKsCn6IOTa74CY+eKBHKiv/ikNdy6NSN8ucYgXTmCO822i0hBxpapFKnhSKC+wN8trDYNhFGi0EGC5uOROPhc6Z4Q7qzt1aqpUREutMFvMjajW/;
Received: from luuna.daevel.fr ([82.67.37.138] helo=[192.168.1.50])
	by licorne.daevel.fr with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1U4ETO-0001ja-Om
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 18:44:22 +0100
Message-ID: <1360431862.27289.8.camel@boolette.noo>
From: Olivier Bonvalet <xen.list@daevel.fr>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Sat, 09 Feb 2013 18:44:22 +0100
X-Mailer: Evolution 3.6.3-1 
Mime-Version: 1.0
Subject: [Xen-devel] [blkfront] max_segments & max_segment_size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 have (very) poor write performance with Xen PV, used over RBD, and I
suppose it's because of very short values for max_segments and
max_segment_size.
(I have 250MB/s write speed in Dom0 vs 40MB/s write speed in DomU)

>From what I read, there is already a patch to fix that, called "multi
page ring support for block devices" : 
   http://lists.xen.org/archives/html/xen-devel/2012-03/msg00388.html

But it doesn't seem to have been accepted.

So, does it exist an other solution to fix that kind of problem ?

Thanks,
Olivier


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 05:31:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 05: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 1U4PV9-0001LJ-15; Sun, 10 Feb 2013 05:30:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4PV6-0001LE-KD
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 05:30:52 +0000
Received: from [193.109.254.147:34417] by server-9.bemta-14.messagelabs.com id
	95/2D-30867-B8037115; Sun, 10 Feb 2013 05:30:51 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360474248!1778802!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19651 invoked from network); 10 Feb 2013 05:30:49 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-7.tower-27.messagelabs.com with SMTP;
	10 Feb 2013 05:30:49 -0000
Received: from [10.0.1.5] (c-98-221-118-138.hsd1.nj.comcast.net
	[98.221.118.138])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1A5UlSW031265;
	Sun, 10 Feb 2013 00:30:48 -0500
Mime-Version: 1.0 (Apple Message framework v1085)
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
Date: Sun, 10 Feb 2013 00:30:47 -0500
Message-Id: <50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
To: Wei Liu <liuw@liuw.name>
X-Mailer: Apple Mail (2.1085)
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Feb 1, 2013, at 8:01 PM, Wei Liu wrote:
> Just happened to fix a bug related to OOM not getting handled correctly.
> 
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html

Rebuilt with the above patch, and have now hit this:

BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
PGD 82c63067 PUD 82640067 PMD 0 
Oops: 0002 [#1] SMP 
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
CPU 0 
Pid: 1545, comm: netback/0 Not tainted 3.7.6-1-x86_64 #1 Supermicro X8DT6/X8DT6
RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
RSP: e02b:ffff880083693b58  EFLAGS: 00010006
RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 0000000000dabda3
RDX: 0000000000000001 RSI: 0000000000000210 RDI: 00000000000008b8
RBP: ffff880083693b78 R08: 000000000000005f R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000001
R13: 0000000000000200 R14: 0000000000000400 R15: 0000000000dabda3
FS:  00007f19e7f69700(0000) GS:ffff880100600000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000008b8 CR3: 0000000082413000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/0 (pid: 1545, threadinfo ffff880083692000, task ffff880083d2e740)
Stack:
 0000000000000210 00000000000008b8 ffff88005f807700 ffff88005f8077d8
 ffff880083693b98 ffffffff817605da 0000000000000000 00000000000008b8
 ffff880083693bd8 ffffffff8154446f ffff88005f807000 0000000000000000
Call Trace:
 [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
 [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
 [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
 [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
 [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
 [<ffffffff816357b9>] ? enqueue_to_backlog+0xb9/0x190
 [<ffffffff8100140a>] ? xen_hypercall_event_channel_op+0xa/0x20
 [<ffffffff81639284>] ? netif_rx+0x44/0xe0
 [<ffffffff81015410>] ? do_softirq+0x50/0xa0
 [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
 [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
 [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
 [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
 [<ffffffff81071a06>] kthread+0xc6/0xd0
 [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
 [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
 [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
 [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15 
RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
 RSP <ffff880083693b58>
CR2: 00000000000008b8
---[ end trace db6edd7c15bd6503 ]---

Plenty of RAM free (over 900M).  Same symptoms: now xenwatch is in D state and hotplug stuff is timing out.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 05:31:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 05: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 1U4PV9-0001LJ-15; Sun, 10 Feb 2013 05:30:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4PV6-0001LE-KD
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 05:30:52 +0000
Received: from [193.109.254.147:34417] by server-9.bemta-14.messagelabs.com id
	95/2D-30867-B8037115; Sun, 10 Feb 2013 05:30:51 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360474248!1778802!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19651 invoked from network); 10 Feb 2013 05:30:49 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-7.tower-27.messagelabs.com with SMTP;
	10 Feb 2013 05:30:49 -0000
Received: from [10.0.1.5] (c-98-221-118-138.hsd1.nj.comcast.net
	[98.221.118.138])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1A5UlSW031265;
	Sun, 10 Feb 2013 00:30:48 -0500
Mime-Version: 1.0 (Apple Message framework v1085)
From: "Christopher S. Aker" <caker@theshore.net>
In-Reply-To: <CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
Date: Sun, 10 Feb 2013 00:30:47 -0500
Message-Id: <50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
To: Wei Liu <liuw@liuw.name>
X-Mailer: Apple Mail (2.1085)
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Feb 1, 2013, at 8:01 PM, Wei Liu wrote:
> Just happened to fix a bug related to OOM not getting handled correctly.
> 
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg02549.html

Rebuilt with the above patch, and have now hit this:

BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
PGD 82c63067 PUD 82640067 PMD 0 
Oops: 0002 [#1] SMP 
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
CPU 0 
Pid: 1545, comm: netback/0 Not tainted 3.7.6-1-x86_64 #1 Supermicro X8DT6/X8DT6
RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
RSP: e02b:ffff880083693b58  EFLAGS: 00010006
RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 0000000000dabda3
RDX: 0000000000000001 RSI: 0000000000000210 RDI: 00000000000008b8
RBP: ffff880083693b78 R08: 000000000000005f R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000001
R13: 0000000000000200 R14: 0000000000000400 R15: 0000000000dabda3
FS:  00007f19e7f69700(0000) GS:ffff880100600000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000008b8 CR3: 0000000082413000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/0 (pid: 1545, threadinfo ffff880083692000, task ffff880083d2e740)
Stack:
 0000000000000210 00000000000008b8 ffff88005f807700 ffff88005f8077d8
 ffff880083693b98 ffffffff817605da 0000000000000000 00000000000008b8
 ffff880083693bd8 ffffffff8154446f ffff88005f807000 0000000000000000
Call Trace:
 [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
 [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
 [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
 [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
 [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
 [<ffffffff816357b9>] ? enqueue_to_backlog+0xb9/0x190
 [<ffffffff8100140a>] ? xen_hypercall_event_channel_op+0xa/0x20
 [<ffffffff81639284>] ? netif_rx+0x44/0xe0
 [<ffffffff81015410>] ? do_softirq+0x50/0xa0
 [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
 [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
 [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
 [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
 [<ffffffff81071a06>] kthread+0xc6/0xd0
 [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
 [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
 [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
 [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15 
RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
 RSP <ffff880083693b58>
CR2: 00000000000008b8
---[ end trace db6edd7c15bd6503 ]---

Plenty of RAM free (over 900M).  Same symptoms: now xenwatch is in D state and hotplug stuff is timing out.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 05:59:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 05: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 1U4PwH-00023k-KX; Sun, 10 Feb 2013 05:58:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lenb417@gmail.com>) id 1U4PwF-00023f-ME
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 05:58:55 +0000
Received: from [193.109.254.147:41865] by server-14.bemta-14.messagelabs.com
	id 40/B4-02031-E1737115; Sun, 10 Feb 2013 05:58:54 +0000
X-Env-Sender: lenb417@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360475933!9723467!1
X-Originating-IP: [209.85.128.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27906 invoked from network); 10 Feb 2013 05:58:54 -0000
Received: from mail-ve0-f176.google.com (HELO mail-ve0-f176.google.com)
	(209.85.128.176)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2013 05:58:54 -0000
Received: by mail-ve0-f176.google.com with SMTP id cz10so4293479veb.7
	for <xen-devel@lists.xensource.com>;
	Sat, 09 Feb 2013 21:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references:in-reply-to:references:reply-to:organization;
	bh=S5yz3SpA3SiWzOJl5tYzR2ExyKIhMkzawbaeZ6FUPvQ=;
	b=ZIcSIeFuynWZXA6h7dwXdpC8WxhIdxkAnMUAWaP2+VAMYgqFVOHzryQSWSuChyA5+8
	WVKC9Pf3cFLi8ST+uevXUPtczWgBlmfgpUPJSqI7CgCl0VEIkhk8qaLfCSQVQtMiIXOt
	3S+o2CLdpMwkgo4l5ewZciah4rZMkzXynw8ytpa7nNEMsCXomufx+FyO+jyyQCGkZTUk
	jHiZ0WNPLWV5qsshmfVFMqIuUYMsEt1TnBKkBZ6F4S1F6mk/eRNaajO3xGwF9pxoVkug
	/zLKGVO73WgySXZXZT5ZzVxa/5wUvYAyZQbSQQydS7tvOVF854S6GIjMCycp6wP8B4GG
	CElA==
X-Received: by 10.52.95.243 with SMTP id dn19mr11773609vdb.110.1360475932861; 
	Sat, 09 Feb 2013 21:58:52 -0800 (PST)
Received: from x980.localdomain6 (pool-108-7-58-246.bstnma.fios.verizon.net.
	[108.7.58.246])
	by mx.google.com with ESMTPS id p7sm42173052vdt.2.2013.02.09.21.58.51
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Sat, 09 Feb 2013 21:58:52 -0800 (PST)
From: Len Brown <lenb@kernel.org>
To: linux-pm@vger.kernel.org
Date: Sun, 10 Feb 2013 00:58:23 -0500
Message-Id: <fd112767551c1dc5f15e1db92830d51af186edcf.1360475150.git.len.brown@intel.com>
X-Mailer: git-send-email 1.8.1.3.535.ga923c31
In-Reply-To: <1360475903-30007-1-git-send-email-lenb@kernel.org>
References: <1360475903-30007-1-git-send-email-lenb@kernel.org>
In-Reply-To: <2b219d07e0f287c2c713f5465fc8646158fa986e.1360475150.git.len.brown@intel.com>
References: <2b219d07e0f287c2c713f5465fc8646158fa986e.1360475150.git.len.brown@intel.com>
Organization: Intel Open Source Technology Center
Cc: Len Brown <len.brown@intel.com>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH 16/16] xen idle: make xen-specific macro
	xen-specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Len Brown <lenb@kernel.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>
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: Len Brown <len.brown@intel.com>

This macro is only invoked by Xen,
so make its definition specific to Xen.

> set_pm_idle_to_default()
< xen_set_default_idle()

Signed-off-by: Len Brown <len.brown@intel.com>
Cc: xen-devel@lists.xensource.com
---
 arch/x86/include/asm/processor.h | 6 +++++-
 arch/x86/kernel/process.c        | 4 +++-
 arch/x86/xen/setup.c             | 2 +-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 888184b..c2f7f47 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -998,7 +998,11 @@ extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
 
 void default_idle(void);
-bool set_pm_idle_to_default(void);
+#ifdef	CONFIG_XEN
+bool xen_set_default_idle(void);
+#else
+#define xen_set_default_idle 0
+#endif
 
 void stop_this_cpu(void *dummy);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index ceb05db..b86de21 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -390,7 +390,8 @@ void default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif
 
-bool set_pm_idle_to_default(void)
+#ifdef CONFIG_XEN
+bool xen_set_default_idle(void)
 {
 	bool ret = !!x86_idle;
 
@@ -398,6 +399,7 @@ bool set_pm_idle_to_default(void)
 
 	return ret;
 }
+#endif
 void stop_this_cpu(void *dummy)
 {
 	local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..2b73b5c 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -561,7 +561,7 @@ void __init xen_arch_setup(void)
 #endif
 	disable_cpuidle();
 	disable_cpufreq();
-	WARN_ON(set_pm_idle_to_default());
+	WARN_ON(xen_set_default_idle());
 	fiddle_vdso();
 #ifdef CONFIG_NUMA
 	numa_off = 1;
-- 
1.8.1.3.535.ga923c31


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 05:59:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 05: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 1U4PwH-00023k-KX; Sun, 10 Feb 2013 05:58:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lenb417@gmail.com>) id 1U4PwF-00023f-ME
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 05:58:55 +0000
Received: from [193.109.254.147:41865] by server-14.bemta-14.messagelabs.com
	id 40/B4-02031-E1737115; Sun, 10 Feb 2013 05:58:54 +0000
X-Env-Sender: lenb417@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360475933!9723467!1
X-Originating-IP: [209.85.128.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27906 invoked from network); 10 Feb 2013 05:58:54 -0000
Received: from mail-ve0-f176.google.com (HELO mail-ve0-f176.google.com)
	(209.85.128.176)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2013 05:58:54 -0000
Received: by mail-ve0-f176.google.com with SMTP id cz10so4293479veb.7
	for <xen-devel@lists.xensource.com>;
	Sat, 09 Feb 2013 21:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer
	:in-reply-to:references:in-reply-to:references:reply-to:organization;
	bh=S5yz3SpA3SiWzOJl5tYzR2ExyKIhMkzawbaeZ6FUPvQ=;
	b=ZIcSIeFuynWZXA6h7dwXdpC8WxhIdxkAnMUAWaP2+VAMYgqFVOHzryQSWSuChyA5+8
	WVKC9Pf3cFLi8ST+uevXUPtczWgBlmfgpUPJSqI7CgCl0VEIkhk8qaLfCSQVQtMiIXOt
	3S+o2CLdpMwkgo4l5ewZciah4rZMkzXynw8ytpa7nNEMsCXomufx+FyO+jyyQCGkZTUk
	jHiZ0WNPLWV5qsshmfVFMqIuUYMsEt1TnBKkBZ6F4S1F6mk/eRNaajO3xGwF9pxoVkug
	/zLKGVO73WgySXZXZT5ZzVxa/5wUvYAyZQbSQQydS7tvOVF854S6GIjMCycp6wP8B4GG
	CElA==
X-Received: by 10.52.95.243 with SMTP id dn19mr11773609vdb.110.1360475932861; 
	Sat, 09 Feb 2013 21:58:52 -0800 (PST)
Received: from x980.localdomain6 (pool-108-7-58-246.bstnma.fios.verizon.net.
	[108.7.58.246])
	by mx.google.com with ESMTPS id p7sm42173052vdt.2.2013.02.09.21.58.51
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Sat, 09 Feb 2013 21:58:52 -0800 (PST)
From: Len Brown <lenb@kernel.org>
To: linux-pm@vger.kernel.org
Date: Sun, 10 Feb 2013 00:58:23 -0500
Message-Id: <fd112767551c1dc5f15e1db92830d51af186edcf.1360475150.git.len.brown@intel.com>
X-Mailer: git-send-email 1.8.1.3.535.ga923c31
In-Reply-To: <1360475903-30007-1-git-send-email-lenb@kernel.org>
References: <1360475903-30007-1-git-send-email-lenb@kernel.org>
In-Reply-To: <2b219d07e0f287c2c713f5465fc8646158fa986e.1360475150.git.len.brown@intel.com>
References: <2b219d07e0f287c2c713f5465fc8646158fa986e.1360475150.git.len.brown@intel.com>
Organization: Intel Open Source Technology Center
Cc: Len Brown <len.brown@intel.com>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH 16/16] xen idle: make xen-specific macro
	xen-specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Len Brown <lenb@kernel.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>
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: Len Brown <len.brown@intel.com>

This macro is only invoked by Xen,
so make its definition specific to Xen.

> set_pm_idle_to_default()
< xen_set_default_idle()

Signed-off-by: Len Brown <len.brown@intel.com>
Cc: xen-devel@lists.xensource.com
---
 arch/x86/include/asm/processor.h | 6 +++++-
 arch/x86/kernel/process.c        | 4 +++-
 arch/x86/xen/setup.c             | 2 +-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 888184b..c2f7f47 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -998,7 +998,11 @@ extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
 
 void default_idle(void);
-bool set_pm_idle_to_default(void);
+#ifdef	CONFIG_XEN
+bool xen_set_default_idle(void);
+#else
+#define xen_set_default_idle 0
+#endif
 
 void stop_this_cpu(void *dummy);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index ceb05db..b86de21 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -390,7 +390,8 @@ void default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif
 
-bool set_pm_idle_to_default(void)
+#ifdef CONFIG_XEN
+bool xen_set_default_idle(void)
 {
 	bool ret = !!x86_idle;
 
@@ -398,6 +399,7 @@ bool set_pm_idle_to_default(void)
 
 	return ret;
 }
+#endif
 void stop_this_cpu(void *dummy)
 {
 	local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..2b73b5c 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -561,7 +561,7 @@ void __init xen_arch_setup(void)
 #endif
 	disable_cpuidle();
 	disable_cpufreq();
-	WARN_ON(set_pm_idle_to_default());
+	WARN_ON(xen_set_default_idle());
 	fiddle_vdso();
 #ifdef CONFIG_NUMA
 	numa_off = 1;
-- 
1.8.1.3.535.ga923c31


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 06:03:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 06:03: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 1U4Q0T-0002Lk-AW; Sun, 10 Feb 2013 06:03: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 1U4Q0R-0002Ld-9U
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 06:03:15 +0000
Received: from [85.158.143.99:34948] by server-2.bemta-4.messagelabs.com id
	9C/FB-01597-22837115; Sun, 10 Feb 2013 06:03:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360476193!28063362!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32707 invoked from network); 10 Feb 2013 06:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2013 06:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,636,1355097600"; 
   d="scan'208";a="1308723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2013 06:03: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.297.1; Sun, 10 Feb 2013 06:03:13 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U4Q0P-0007KW-4J;
	Sun, 10 Feb 2013 06:03:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U4Q0P-0002al-1k;
	Sun, 10 Feb 2013 06:03:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15659-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Feb 2013 06:03:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15659: 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 15659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15659/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-win          12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-qemut-win    12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15452
 test-amd64-i386-qemut-win-vcpus1 11 guest-localmigrate.2    fail pass in 15452
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore          fail pass in 15452
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15452 pass in 15659
 test-amd64-i386-win        11 guest-localmigrate.2 fail in 15452 pass in 15659
 test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail in 15452 pass in 15659
 test-amd64-i386-xl-qemut-win-vcpus1 7 windows-install fail in 15452 pass in 15659
 test-amd64-i386-qemut-win  11 guest-localmigrate.2 fail in 15452 pass in 15659

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             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-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 15452 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 15452 never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Sun Feb 10 06:03:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 06:03: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 1U4Q0T-0002Lk-AW; Sun, 10 Feb 2013 06:03: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 1U4Q0R-0002Ld-9U
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 06:03:15 +0000
Received: from [85.158.143.99:34948] by server-2.bemta-4.messagelabs.com id
	9C/FB-01597-22837115; Sun, 10 Feb 2013 06:03:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360476193!28063362!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32707 invoked from network); 10 Feb 2013 06:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2013 06:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,636,1355097600"; 
   d="scan'208";a="1308723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2013 06:03: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.297.1; Sun, 10 Feb 2013 06:03:13 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U4Q0P-0007KW-4J;
	Sun, 10 Feb 2013 06:03:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U4Q0P-0002al-1k;
	Sun, 10 Feb 2013 06:03:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-15659-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Feb 2013 06:03:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15659: 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 15659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15659/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-win          12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-qemut-win    12 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15452
 test-amd64-i386-qemut-win-vcpus1 11 guest-localmigrate.2    fail pass in 15452
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore          fail pass in 15452
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15452 pass in 15659
 test-amd64-i386-win        11 guest-localmigrate.2 fail in 15452 pass in 15659
 test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail in 15452 pass in 15659
 test-amd64-i386-xl-qemut-win-vcpus1 7 windows-install fail in 15452 pass in 15659
 test-amd64-i386-qemut-win  11 guest-localmigrate.2 fail in 15452 pass in 15659

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             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-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 15452 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 15452 never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Sun Feb 10 22:04:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 22: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 1U4ezZ-0005rJ-Tg; Sun, 10 Feb 2013 22:03:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4ezY-0005rE-TJ
	for xen-devel@lists.xen.org; Sun, 10 Feb 2013 22:03:21 +0000
Received: from [85.158.139.211:18045] by server-7.bemta-5.messagelabs.com id
	09/2E-11121-82918115; Sun, 10 Feb 2013 22:03:20 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360533798!20794409!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21299 invoked from network); 10 Feb 2013 22:03:18 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-16.tower-206.messagelabs.com with SMTP;
	10 Feb 2013 22:03:18 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1AM3HkC013648
	for <xen-devel@lists.xen.org>; Sun, 10 Feb 2013 17:03:17 -0500
Message-ID: <51181924.4050500@theshore.net>
Date: Sun, 10 Feb 2013 17:03:16 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
In-Reply-To: <50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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

And another this afternoon on a different machine:

BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
CPU 5
Pid: 1550, comm: netback/5 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
X8DT6/X8DT6
RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
xen_spin_lock_flags+0x3a/0x80
RSP: e02b:ffff8800836e7b58  EFLAGS: 00010006
RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 000000000045de5d
RDX: 0000000000000001 RSI: 0000000000000211 RDI: 00000000000008b8
RBP: ffff8800836e7b78 R08: 0000000000000068 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000200 R14: 0000000000000400 R15: 000000000045de5d
FS:  00007f474a465700(0000) GS:ffff880100740000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/5 (pid: 1550, threadinfo ffff8800836e6000, task 
ffff880084510000)
Stack:
  0000000000000211 00000000000008b8 ffff8800771e5700 ffff8800771e57d8
  ffff8800836e7b98 ffffffff817605da 0000000000000000 00000000000008b8
  ffff8800836e7bd8 ffffffff8154446f ffff8800771e5000 0000000000000000
Call Trace:
  [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
  [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
  [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
  [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
  [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
  [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
  [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
  [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
  [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
  [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
  [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
  [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
  [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
  [<ffffffff81071a06>] kthread+0xc6/0xd0
  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
  [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 
02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 
84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
  RSP <ffff8800836e7b58>
CR2: 00000000000008b8
---[ end trace 62de4ce454b1699e ]---


Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 
02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 
84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
All code
========
    0:   24 08                   and    $0x8,%al
    2:   4c 89 6c 24 10          mov    %r13,0x10(%rsp)
    7:   4c 89 74 24 18          mov    %r14,0x18(%rsp)
    c:   49 89 f5                mov    %rsi,%r13
    f:   48 89 fb                mov    %rdi,%rbx
   12:   41 81 e5 00 02 00 00    and    $0x200,%r13d
   19:   41 bc 01 00 00 00       mov    $0x1,%r12d
   1f:   41 be 00 04 00 00       mov    $0x400,%r14d
   25:   44 89 f0                mov    %r14d,%eax
   28:   44 89 e2                mov    %r12d,%edx
   2b:*  86 13                   xchg   %dl,(%rbx)     <-- trapping 
instruction
   2d:   84 d2                   test   %dl,%dl
   2f:   74 0b                   je     0x3c
   31:   f3 90                   pause
   33:   80 3b 00                cmpb   $0x0,(%rbx)
   36:   74 f3                   je     0x2b
   38:   ff c8                   dec    %eax
   3a:   75 f5                   jne    0x31
   3c:   84 d2                   test   %dl,%dl
   3e:   75 15                   jne    0x55

Code starting with the faulting instruction
===========================================
    0:   86 13                   xchg   %dl,(%rbx)
    2:   84 d2                   test   %dl,%dl
    4:   74 0b                   je     0x11
    6:   f3 90                   pause
    8:   80 3b 00                cmpb   $0x0,(%rbx)
    b:   74 f3                   je     0x0
    d:   ff c8                   dec    %eax
    f:   75 f5                   jne    0x6
   11:   84 d2                   test   %dl,%dl
   13:   75 15                   jne    0x2a



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_flags(struct arch_spinlock *lock, unsigned 
long flags)
{
         __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
}



(gdb) disassemble xen_spin_lock_flags
Dump of assembler code for function xen_spin_lock_flags:
0xffffffff81011da0 <xen_spin_lock_flags+0>:     push   %rbp
0xffffffff81011da1 <xen_spin_lock_flags+1>:     mov    %rsp,%rbp
0xffffffff81011da4 <xen_spin_lock_flags+4>:     sub    $0x20,%rsp
0xffffffff81011da8 <xen_spin_lock_flags+8>:     mov    %rbx,(%rsp)
0xffffffff81011dac <xen_spin_lock_flags+12>:    mov    %r12,0x8(%rsp)
0xffffffff81011db1 <xen_spin_lock_flags+17>:    mov    %r13,0x10(%rsp)
0xffffffff81011db6 <xen_spin_lock_flags+22>:    mov 
%r14,ffff81011dda0x18(%rsp)
0xffffffff81011dbb <xen_spin_lock_flags+27>:    mov    %rsi,%r13
0xffffffff81011dbe <xen_spin_lock_flags+30>:    mov    %rdi,%rbx
0xffffffff81011dc1 <xen_spin_lock_flags+33>:    and    $0x200,%r13d
0xffffffff81011dc8 <xen_spin_lock_flags+40>:    mov    $0x1,%r12d
0xffffffff81011dce <xen_spin_lock_flags+46>:    mov    $0x400,%r14d
0xffffffff81011dd4 <xen_spin_lock_flags+52>:    mov    %r14d,%eax
0xffffffff81011dd7 <xen_spin_lock_flags+55>:    mov    %r12d,%edx
0xffffffff81011dda <xen_spin_lock_flags+58>:    xchg   %dl,(%rbx) <--
0xffffffff81011ddc <xen_spin_lock_flags+60>:    test   %dl,%dl
0xffffffff81011dde <xen_spin_lock_flags+62>:    je 
0xffffffff81011deb <xen_spin_lock_flags+75>
0xffffffff81011de0 <xen_spin_lock_flags+64>:    pause
0xffffffff81011de2 <xen_spin_lock_flags+66>:    cmpb   $0x0,(%rbx)
0xffffffff81011de5 <xen_spin_lock_flags+69>:    je 
0xffffffff81011dda <xen_spin_lock_flags+58>
0xffffffff81011de7 <xen_spin_lock_flags+71>:    dec    %eax
0xffffffff81011de9 <xen_spin_lock_flags+73>:    jne 
0xffffffff81011de0 <xen_spin_lock_flags+64>
0xffffffff81011deb <xen_spin_lock_flags+75>:    test   %dl,%dl
0xffffffff81011ded <xen_spin_lock_flags+77>:    jne 
0xffffffff81011e04 <xen_spin_lock_flags+100>
0xffffffff81011def <xen_spin_lock_flags+79>:    mov    (%rsp),%rbx
0xffffffff81011df3 <xen_spin_lock_flags+83>:    mov    0x8(%rsp),%r12
0xffffffff81011df8 <xen_spin_lock_flags+88>:    mov    0x10(%rsp),%r13
0xffffffff81011dfd <xen_spin_lock_flags+93>:    mov    0x18(%rsp),%r14
0xffffffff81011e02 <xen_spin_lock_flags+98>:    leaveq
0xffffffff81011e03 <xen_spin_lock_flags+99>:    retq
0xffffffff81011e04 <xen_spin_lock_flags+100>:   xor    %esi,%esi
0xffffffff81011e06 <xen_spin_lock_flags+102>:   mov    %rbx,%rdi
0xffffffff81011e09 <xen_spin_lock_flags+105>:   test   %r13,%r13
0xffffffff81011e0c <xen_spin_lock_flags+108>:   setne  %sil
0xffffffff81011e10 <xen_spin_lock_flags+112>:   callq 
0xffffffff81011ca0 <xen_spin_lock_slow>
0xffffffff81011e15 <xen_spin_lock_flags+117>:   test   %eax,%eax
0xffffffff81011e17 <xen_spin_lock_flags+119>:   jne 
0xffffffff81011def <xen_spin_lock_flags+79>
0xffffffff81011e19 <xen_spin_lock_flags+121>:   jmp 
0xffffffff81011dd4 <xen_spin_lock_flags+52>
End of assembler dump.


We're not so good at this, but it looks like xl->lock deref is what we 
hit?  The lock was gone?

-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 22:04:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 22: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 1U4ezZ-0005rJ-Tg; Sun, 10 Feb 2013 22:03:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4ezY-0005rE-TJ
	for xen-devel@lists.xen.org; Sun, 10 Feb 2013 22:03:21 +0000
Received: from [85.158.139.211:18045] by server-7.bemta-5.messagelabs.com id
	09/2E-11121-82918115; Sun, 10 Feb 2013 22:03:20 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360533798!20794409!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21299 invoked from network); 10 Feb 2013 22:03:18 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-16.tower-206.messagelabs.com with SMTP;
	10 Feb 2013 22:03:18 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1AM3HkC013648
	for <xen-devel@lists.xen.org>; Sun, 10 Feb 2013 17:03:17 -0500
Message-ID: <51181924.4050500@theshore.net>
Date: Sun, 10 Feb 2013 17:03:16 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
In-Reply-To: <50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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

And another this afternoon on a different machine:

BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
CPU 5
Pid: 1550, comm: netback/5 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
X8DT6/X8DT6
RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
xen_spin_lock_flags+0x3a/0x80
RSP: e02b:ffff8800836e7b58  EFLAGS: 00010006
RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 000000000045de5d
RDX: 0000000000000001 RSI: 0000000000000211 RDI: 00000000000008b8
RBP: ffff8800836e7b78 R08: 0000000000000068 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000200 R14: 0000000000000400 R15: 000000000045de5d
FS:  00007f474a465700(0000) GS:ffff880100740000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netback/5 (pid: 1550, threadinfo ffff8800836e6000, task 
ffff880084510000)
Stack:
  0000000000000211 00000000000008b8 ffff8800771e5700 ffff8800771e57d8
  ffff8800836e7b98 ffffffff817605da 0000000000000000 00000000000008b8
  ffff8800836e7bd8 ffffffff8154446f ffff8800771e5000 0000000000000000
Call Trace:
  [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
  [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
  [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
  [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
  [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
  [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
  [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
  [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
  [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
  [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
  [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
  [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
  [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
  [<ffffffff81071a06>] kthread+0xc6/0xd0
  [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
  [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 
02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 
84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
  RSP <ffff8800836e7b58>
CR2: 00000000000008b8
---[ end trace 62de4ce454b1699e ]---


Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 
02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 
84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
All code
========
    0:   24 08                   and    $0x8,%al
    2:   4c 89 6c 24 10          mov    %r13,0x10(%rsp)
    7:   4c 89 74 24 18          mov    %r14,0x18(%rsp)
    c:   49 89 f5                mov    %rsi,%r13
    f:   48 89 fb                mov    %rdi,%rbx
   12:   41 81 e5 00 02 00 00    and    $0x200,%r13d
   19:   41 bc 01 00 00 00       mov    $0x1,%r12d
   1f:   41 be 00 04 00 00       mov    $0x400,%r14d
   25:   44 89 f0                mov    %r14d,%eax
   28:   44 89 e2                mov    %r12d,%edx
   2b:*  86 13                   xchg   %dl,(%rbx)     <-- trapping 
instruction
   2d:   84 d2                   test   %dl,%dl
   2f:   74 0b                   je     0x3c
   31:   f3 90                   pause
   33:   80 3b 00                cmpb   $0x0,(%rbx)
   36:   74 f3                   je     0x2b
   38:   ff c8                   dec    %eax
   3a:   75 f5                   jne    0x31
   3c:   84 d2                   test   %dl,%dl
   3e:   75 15                   jne    0x55

Code starting with the faulting instruction
===========================================
    0:   86 13                   xchg   %dl,(%rbx)
    2:   84 d2                   test   %dl,%dl
    4:   74 0b                   je     0x11
    6:   f3 90                   pause
    8:   80 3b 00                cmpb   $0x0,(%rbx)
    b:   74 f3                   je     0x0
    d:   ff c8                   dec    %eax
    f:   75 f5                   jne    0x6
   11:   84 d2                   test   %dl,%dl
   13:   75 15                   jne    0x2a



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_flags(struct arch_spinlock *lock, unsigned 
long flags)
{
         __xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
}



(gdb) disassemble xen_spin_lock_flags
Dump of assembler code for function xen_spin_lock_flags:
0xffffffff81011da0 <xen_spin_lock_flags+0>:     push   %rbp
0xffffffff81011da1 <xen_spin_lock_flags+1>:     mov    %rsp,%rbp
0xffffffff81011da4 <xen_spin_lock_flags+4>:     sub    $0x20,%rsp
0xffffffff81011da8 <xen_spin_lock_flags+8>:     mov    %rbx,(%rsp)
0xffffffff81011dac <xen_spin_lock_flags+12>:    mov    %r12,0x8(%rsp)
0xffffffff81011db1 <xen_spin_lock_flags+17>:    mov    %r13,0x10(%rsp)
0xffffffff81011db6 <xen_spin_lock_flags+22>:    mov 
%r14,ffff81011dda0x18(%rsp)
0xffffffff81011dbb <xen_spin_lock_flags+27>:    mov    %rsi,%r13
0xffffffff81011dbe <xen_spin_lock_flags+30>:    mov    %rdi,%rbx
0xffffffff81011dc1 <xen_spin_lock_flags+33>:    and    $0x200,%r13d
0xffffffff81011dc8 <xen_spin_lock_flags+40>:    mov    $0x1,%r12d
0xffffffff81011dce <xen_spin_lock_flags+46>:    mov    $0x400,%r14d
0xffffffff81011dd4 <xen_spin_lock_flags+52>:    mov    %r14d,%eax
0xffffffff81011dd7 <xen_spin_lock_flags+55>:    mov    %r12d,%edx
0xffffffff81011dda <xen_spin_lock_flags+58>:    xchg   %dl,(%rbx) <--
0xffffffff81011ddc <xen_spin_lock_flags+60>:    test   %dl,%dl
0xffffffff81011dde <xen_spin_lock_flags+62>:    je 
0xffffffff81011deb <xen_spin_lock_flags+75>
0xffffffff81011de0 <xen_spin_lock_flags+64>:    pause
0xffffffff81011de2 <xen_spin_lock_flags+66>:    cmpb   $0x0,(%rbx)
0xffffffff81011de5 <xen_spin_lock_flags+69>:    je 
0xffffffff81011dda <xen_spin_lock_flags+58>
0xffffffff81011de7 <xen_spin_lock_flags+71>:    dec    %eax
0xffffffff81011de9 <xen_spin_lock_flags+73>:    jne 
0xffffffff81011de0 <xen_spin_lock_flags+64>
0xffffffff81011deb <xen_spin_lock_flags+75>:    test   %dl,%dl
0xffffffff81011ded <xen_spin_lock_flags+77>:    jne 
0xffffffff81011e04 <xen_spin_lock_flags+100>
0xffffffff81011def <xen_spin_lock_flags+79>:    mov    (%rsp),%rbx
0xffffffff81011df3 <xen_spin_lock_flags+83>:    mov    0x8(%rsp),%r12
0xffffffff81011df8 <xen_spin_lock_flags+88>:    mov    0x10(%rsp),%r13
0xffffffff81011dfd <xen_spin_lock_flags+93>:    mov    0x18(%rsp),%r14
0xffffffff81011e02 <xen_spin_lock_flags+98>:    leaveq
0xffffffff81011e03 <xen_spin_lock_flags+99>:    retq
0xffffffff81011e04 <xen_spin_lock_flags+100>:   xor    %esi,%esi
0xffffffff81011e06 <xen_spin_lock_flags+102>:   mov    %rbx,%rdi
0xffffffff81011e09 <xen_spin_lock_flags+105>:   test   %r13,%r13
0xffffffff81011e0c <xen_spin_lock_flags+108>:   setne  %sil
0xffffffff81011e10 <xen_spin_lock_flags+112>:   callq 
0xffffffff81011ca0 <xen_spin_lock_slow>
0xffffffff81011e15 <xen_spin_lock_flags+117>:   test   %eax,%eax
0xffffffff81011e17 <xen_spin_lock_flags+119>:   jne 
0xffffffff81011def <xen_spin_lock_flags+79>
0xffffffff81011e19 <xen_spin_lock_flags+121>:   jmp 
0xffffffff81011dd4 <xen_spin_lock_flags+52>
End of assembler dump.


We're not so good at this, but it looks like xl->lock deref is what we 
hit?  The lock was gone?

-Chris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 10 23:31:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 23:31: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 1U4gMd-0006ie-4D; Sun, 10 Feb 2013 23:31: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 1U4gMa-0006iW-VF
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 23:31:13 +0000
Received: from [85.158.139.211:6240] by server-6.bemta-5.messagelabs.com id
	D6/05-01489-0CD28115; Sun, 10 Feb 2013 23:31:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360539070!21884203!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 10 Feb 2013 23:31:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2013 23:31:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,639,1355097600"; 
   d="scan'208";a="1313767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2013 23:31: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.297.1; Sun, 10 Feb 2013 23:31:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U4gMX-0004Eu-DK;
	Sun, 10 Feb 2013 23:31:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U4gMX-00019Q-C7;
	Sun, 10 Feb 2013 23:31:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15817-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Feb 2013 23:31:09 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15817: 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 15817 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15817/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-qemut-win 12 guest-localmigrate/x10 fail in 15659 REGR. vs. 15442

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10     fail pass in 15659
 test-amd64-i386-xend-qemut-winxpsp3  9 guest-localmigrate   fail pass in 15659
 test-amd64-i386-qemut-win     7 windows-install             fail pass in 15659
 test-amd64-i386-qemut-win-vcpus1  7 windows-install         fail pass in 15659
 test-amd64-i386-pv       14 guest-localmigrate/x10 fail in 15659 pass in 15817
 test-amd64-i386-win      12 guest-localmigrate/x10 fail in 15659 pass in 15817
 test-amd64-i386-qemut-win-vcpus1 11 guest-localmigrate.2 fail in 15659 pass in 15452
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore fail in 15659 pass in 15817
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 15659 pass in 15817
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15452 pass in 15817
 test-amd64-i386-win        11 guest-localmigrate.2 fail in 15452 pass in 15817
 test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail in 15452 pass in 15659
 test-amd64-i386-xl-qemut-win-vcpus1 7 windows-install fail in 15452 pass in 15817
 test-amd64-i386-qemut-win  11 guest-localmigrate.2 fail in 15452 pass in 15659

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 15659 never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 15659 never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 15452 never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Sun Feb 10 23:31:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 10 Feb 2013 23:31: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 1U4gMd-0006ie-4D; Sun, 10 Feb 2013 23:31: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 1U4gMa-0006iW-VF
	for xen-devel@lists.xensource.com; Sun, 10 Feb 2013 23:31:13 +0000
Received: from [85.158.139.211:6240] by server-6.bemta-5.messagelabs.com id
	D6/05-01489-0CD28115; Sun, 10 Feb 2013 23:31:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360539070!21884203!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 10 Feb 2013 23:31:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Feb 2013 23:31:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,639,1355097600"; 
   d="scan'208";a="1313767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Feb 2013 23:31: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.297.1; Sun, 10 Feb 2013 23:31:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U4gMX-0004Eu-DK;
	Sun, 10 Feb 2013 23:31:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U4gMX-00019Q-C7;
	Sun, 10 Feb 2013 23:31:09 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-15817-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 10 Feb 2013 23:31:09 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 15817: 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 15817 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/15817/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442
 test-amd64-i386-qemut-win 12 guest-localmigrate/x10 fail in 15659 REGR. vs. 15442

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10     fail pass in 15659
 test-amd64-i386-xend-qemut-winxpsp3  9 guest-localmigrate   fail pass in 15659
 test-amd64-i386-qemut-win     7 windows-install             fail pass in 15659
 test-amd64-i386-qemut-win-vcpus1  7 windows-install         fail pass in 15659
 test-amd64-i386-pv       14 guest-localmigrate/x10 fail in 15659 pass in 15817
 test-amd64-i386-win      12 guest-localmigrate/x10 fail in 15659 pass in 15817
 test-amd64-i386-qemut-win-vcpus1 11 guest-localmigrate.2 fail in 15659 pass in 15452
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore fail in 15659 pass in 15817
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 15659 pass in 15817
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15452 pass in 15817
 test-amd64-i386-win        11 guest-localmigrate.2 fail in 15452 pass in 15817
 test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail in 15452 pass in 15659
 test-amd64-i386-xl-qemut-win-vcpus1 7 windows-install fail in 15452 pass in 15817
 test-amd64-i386-qemut-win  11 guest-localmigrate.2 fail in 15452 pass in 15659

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 15659 never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 15659 never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 15452 never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 11 00:04:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 00: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 1U4gs5-0007lG-HJ; Mon, 11 Feb 2013 00:03:45 +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 1U4gs3-0007l9-Th
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 00:03:44 +0000
Received: from [85.158.138.51:14151] by server-13.bemta-3.messagelabs.com id
	3E/64-20653-F5538115; Mon, 11 Feb 2013 00:03:43 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360541019!18624500!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22448 invoked from network); 11 Feb 2013 00:03:42 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Feb 2013 00:03:42 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U4grw-0000Hp-RQ
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:03:37 +1100
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 id
	14.01.0438.000; Mon, 11 Feb 2013 11:03:37 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgA==
Date: Mon, 11 Feb 2013 00:03:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:388:e000:712:b80e:ea50:dc96:baea]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19628.002
x-tm-as-result: No--31.870900-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 user has pointed out a problem with GPLPV under Xen 4.2 when using PoD. I'm using the difference between XENMEM_maximum_reservation and XENMEM_current_reservation to tell me how much I should balloon down to account for PoD, but when the user has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:

13005008825593: XenPCI     XENMEM_maximum_reservation = 262400
13005008825593: XenPCI     XENMEM_current_reservation = 262136
13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen

What is the correct way to tell how much PoD memory there is under 4.2? Am I doing it wrong?

I balloon down as early as possible (before xenbus starts) to avoid windows going over its limit so I'm hoping I can determine the size of PoD memory just via hypercalls.

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 00:04:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 00: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 1U4gs5-0007lG-HJ; Mon, 11 Feb 2013 00:03:45 +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 1U4gs3-0007l9-Th
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 00:03:44 +0000
Received: from [85.158.138.51:14151] by server-13.bemta-3.messagelabs.com id
	3E/64-20653-F5538115; Mon, 11 Feb 2013 00:03:43 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360541019!18624500!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22448 invoked from network); 11 Feb 2013 00:03:42 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Feb 2013 00:03:42 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U4grw-0000Hp-RQ
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:03:37 +1100
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 id
	14.01.0438.000; Mon, 11 Feb 2013 11:03:37 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgA==
Date: Mon, 11 Feb 2013 00:03:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:388:e000:712:b80e:ea50:dc96:baea]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19628.002
x-tm-as-result: No--31.870900-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 user has pointed out a problem with GPLPV under Xen 4.2 when using PoD. I'm using the difference between XENMEM_maximum_reservation and XENMEM_current_reservation to tell me how much I should balloon down to account for PoD, but when the user has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:

13005008825593: XenPCI     XENMEM_maximum_reservation = 262400
13005008825593: XenPCI     XENMEM_current_reservation = 262136
13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen

What is the correct way to tell how much PoD memory there is under 4.2? Am I doing it wrong?

I balloon down as early as possible (before xenbus starts) to avoid windows going over its limit so I'm hoping I can determine the size of PoD memory just via hypercalls.

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 06:32:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 06:32: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 1U4mvm-0006G1-9x; Mon, 11 Feb 2013 06:31:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U4E8O-0007Jg-N5
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 17:22:40 +0000
Received: from [85.158.143.35:63804] by server-3.bemta-4.messagelabs.com id
	DD/44-08920-FD586115; Sat, 09 Feb 2013 17:22:39 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360430495!10237277!1
X-Originating-IP: [209.85.216.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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30337 invoked from network); 9 Feb 2013 17:21:36 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 17:21:36 -0000
Received: by mail-qa0-f45.google.com with SMTP id g10so716643qah.11
	for <xen-devel@lists.xen.org>; Sat, 09 Feb 2013 09:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=WmePxiEYV3GAyRWrL+xO2BSBTt8UdppjldMaaixy4OE=;
	b=0nljERkkpDdRyqDS/IbJDmxpap0ckc11e6J+iFh0V3Ypde+QTfXr/ksFBzFFnQsW3q
	9FKfxHLz0w2SXpbiBHVs+o0kCunnBfo9L2en2+uKBdGhqUV3oNFyzmZch5iabgitm04g
	p9JTo1Ugo8hShX3CUvq7IVToyVHDn6ENleNnOAIyLCsO0LrQ/hSYjYkLMf/aB2+VeqfF
	L16zlJHlTdE4jdQMU82XJBY53IyS6NP4NUpGUd/quKqedWGLKqjuzBJUXYiHwibHegPE
	6kZkVGrgxwGKJFmtNqZO6jZ10qH/xoRVMMr+peJjR3hkXB3l3/EYRVBh0FjIMR/bmA+E
	wUCw==
MIME-Version: 1.0
X-Received: by 10.229.175.68 with SMTP id w4mr800441qcz.71.1360430494897; Sat,
	09 Feb 2013 09:21:34 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Sat, 9 Feb 2013 09:21:34 -0800 (PST)
In-Reply-To: <CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
Date: Sat, 9 Feb 2013 18:21:34 +0100
Message-ID: <CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
X-Mailman-Approved-At: Mon, 11 Feb 2013 06:31:56 +0000
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============7385874469941965729=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7385874469941965729==
Content-Type: multipart/alternative; boundary=0016369f9dc463d6ba04d54de86a

--0016369f9dc463d6ba04d54de86a
Content-Type: text/plain; charset=ISO-8859-1

I apologize for the patching confusion. I applied Konrad's acpi-s3 patch to
linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
dom0_vcpus_pin to xen kernel line in bootloader but still I cannot modprobe
acpi_cpufreq and S3 sleep resume still not working.

How can I debug it?
Thanks.


2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> <tomasz.wroblewski@citrix.com> wrote:
> >
> >> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> >> you are .. ah yes, you are hitting a bug that should be in the stable
> >> tree fix.
> >>
> >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> >>
> >>
> >
> > Thanks Konrad. I've tried your patches, and whilst I have not seen this
> > crash in cpuidle_register anymore, the others are still present (in
> > build_schedule_domains for example).
> >
>
> That looks familiar too. I think it got fixed in the upstream kernel
> and it was a generic bug - but I can't recall which commit it was.
>
> > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
> > commandline stops both the xen scheduler and dom0 kernel crashing and all
> > works fine - made dozens of succesfull s3 attempts. Was wondering if you
> > guys had any thoughts on this? Is the dom0 kernel even supposed to cope
> > during s3 in non dom0 vcpu pin case?
> >
> No that is something new. Is this only an issue on Intel boxes but not AMD?
>

--0016369f9dc463d6ba04d54de86a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I apologize for the patching confusion. I applie=
d Konrad&#39;s acpi-s3 patch to linux 3.7.5-1 and Ben&#39;s Xen patches to =
Xen 4.2.1-3 stable. I&#39;ve also put dom0_vcpus_pin to xen kernel line in =
bootloader but still I cannot modprobe acpi_cpufreq and S3 sleep resume sti=
ll not working. <br>
</div><br>How can I debug it?<br></div><div>Thanks.<br></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/2/8 Konrad Rzesz=
utek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=
=3D"_blank">konrad@kernel.org</a>&gt;</span><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 Fri, Feb 8, 2013 at 5:1=
1 AM, Tomasz Wroblewski<br>
&lt;<a href=3D"mailto:tomasz.wroblewski@citrix.com">tomasz.wroblewski@citri=
x.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Hm, that is suspect. There should not be any cpuidle_register? Per=
haps<br>
&gt;&gt; you are .. ah yes, you are hitting a bug that should be in the sta=
ble<br>
&gt;&gt; tree fix.<br>
&gt;&gt;<br>
&gt;&gt; Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece an=
d<br>
&gt;&gt; 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt; Thanks Konrad. I&#39;ve tried your patches, and whilst I have not seen=
 this<br>
&gt; crash in cpuidle_register anymore, the others are still present (in<br=
>
&gt; build_schedule_domains for example).<br>
&gt;<br>
<br>
</div>That looks familiar too. I think it got fixed in the upstream kernel<=
br>
and it was a generic bug - but I can&#39;t recall which commit it was.<br>
<div class=3D"im"><br>
&gt; I&#39;ve stumbled on a bit of interesting info - using dom0_vcpus_pin =
on xen<br>
&gt; commandline stops both the xen scheduler and dom0 kernel crashing and =
all<br>
&gt; works fine - made dozens of succesfull s3 attempts. Was wondering if y=
ou<br>
&gt; guys had any thoughts on this? Is the dom0 kernel even supposed to cop=
e<br>
&gt; during s3 in non dom0 vcpu pin case?<br>
&gt;<br>
</div>No that is something new. Is this only an issue on Intel boxes but no=
t AMD?<br>
</blockquote></div><br></div>

--0016369f9dc463d6ba04d54de86a--


--===============7385874469941965729==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7385874469941965729==--


From xen-devel-bounces@lists.xen.org Mon Feb 11 06:32:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 06:32: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 1U4mvm-0006G1-9x; Mon, 11 Feb 2013 06:31:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U4E8O-0007Jg-N5
	for xen-devel@lists.xen.org; Sat, 09 Feb 2013 17:22:40 +0000
Received: from [85.158.143.35:63804] by server-3.bemta-4.messagelabs.com id
	DD/44-08920-FD586115; Sat, 09 Feb 2013 17:22:39 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360430495!10237277!1
X-Originating-IP: [209.85.216.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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30337 invoked from network); 9 Feb 2013 17:21:36 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Feb 2013 17:21:36 -0000
Received: by mail-qa0-f45.google.com with SMTP id g10so716643qah.11
	for <xen-devel@lists.xen.org>; Sat, 09 Feb 2013 09:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=WmePxiEYV3GAyRWrL+xO2BSBTt8UdppjldMaaixy4OE=;
	b=0nljERkkpDdRyqDS/IbJDmxpap0ckc11e6J+iFh0V3Ypde+QTfXr/ksFBzFFnQsW3q
	9FKfxHLz0w2SXpbiBHVs+o0kCunnBfo9L2en2+uKBdGhqUV3oNFyzmZch5iabgitm04g
	p9JTo1Ugo8hShX3CUvq7IVToyVHDn6ENleNnOAIyLCsO0LrQ/hSYjYkLMf/aB2+VeqfF
	L16zlJHlTdE4jdQMU82XJBY53IyS6NP4NUpGUd/quKqedWGLKqjuzBJUXYiHwibHegPE
	6kZkVGrgxwGKJFmtNqZO6jZ10qH/xoRVMMr+peJjR3hkXB3l3/EYRVBh0FjIMR/bmA+E
	wUCw==
MIME-Version: 1.0
X-Received: by 10.229.175.68 with SMTP id w4mr800441qcz.71.1360430494897; Sat,
	09 Feb 2013 09:21:34 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Sat, 9 Feb 2013 09:21:34 -0800 (PST)
In-Reply-To: <CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
Date: Sat, 9 Feb 2013 18:21:34 +0100
Message-ID: <CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
X-Mailman-Approved-At: Mon, 11 Feb 2013 06:31:56 +0000
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============7385874469941965729=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7385874469941965729==
Content-Type: multipart/alternative; boundary=0016369f9dc463d6ba04d54de86a

--0016369f9dc463d6ba04d54de86a
Content-Type: text/plain; charset=ISO-8859-1

I apologize for the patching confusion. I applied Konrad's acpi-s3 patch to
linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
dom0_vcpus_pin to xen kernel line in bootloader but still I cannot modprobe
acpi_cpufreq and S3 sleep resume still not working.

How can I debug it?
Thanks.


2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> <tomasz.wroblewski@citrix.com> wrote:
> >
> >> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> >> you are .. ah yes, you are hitting a bug that should be in the stable
> >> tree fix.
> >>
> >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> >>
> >>
> >
> > Thanks Konrad. I've tried your patches, and whilst I have not seen this
> > crash in cpuidle_register anymore, the others are still present (in
> > build_schedule_domains for example).
> >
>
> That looks familiar too. I think it got fixed in the upstream kernel
> and it was a generic bug - but I can't recall which commit it was.
>
> > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
> > commandline stops both the xen scheduler and dom0 kernel crashing and all
> > works fine - made dozens of succesfull s3 attempts. Was wondering if you
> > guys had any thoughts on this? Is the dom0 kernel even supposed to cope
> > during s3 in non dom0 vcpu pin case?
> >
> No that is something new. Is this only an issue on Intel boxes but not AMD?
>

--0016369f9dc463d6ba04d54de86a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I apologize for the patching confusion. I applie=
d Konrad&#39;s acpi-s3 patch to linux 3.7.5-1 and Ben&#39;s Xen patches to =
Xen 4.2.1-3 stable. I&#39;ve also put dom0_vcpus_pin to xen kernel line in =
bootloader but still I cannot modprobe acpi_cpufreq and S3 sleep resume sti=
ll not working. <br>
</div><br>How can I debug it?<br></div><div>Thanks.<br></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/2/8 Konrad Rzesz=
utek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=
=3D"_blank">konrad@kernel.org</a>&gt;</span><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 Fri, Feb 8, 2013 at 5:1=
1 AM, Tomasz Wroblewski<br>
&lt;<a href=3D"mailto:tomasz.wroblewski@citrix.com">tomasz.wroblewski@citri=
x.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Hm, that is suspect. There should not be any cpuidle_register? Per=
haps<br>
&gt;&gt; you are .. ah yes, you are hitting a bug that should be in the sta=
ble<br>
&gt;&gt; tree fix.<br>
&gt;&gt;<br>
&gt;&gt; Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece an=
d<br>
&gt;&gt; 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt; Thanks Konrad. I&#39;ve tried your patches, and whilst I have not seen=
 this<br>
&gt; crash in cpuidle_register anymore, the others are still present (in<br=
>
&gt; build_schedule_domains for example).<br>
&gt;<br>
<br>
</div>That looks familiar too. I think it got fixed in the upstream kernel<=
br>
and it was a generic bug - but I can&#39;t recall which commit it was.<br>
<div class=3D"im"><br>
&gt; I&#39;ve stumbled on a bit of interesting info - using dom0_vcpus_pin =
on xen<br>
&gt; commandline stops both the xen scheduler and dom0 kernel crashing and =
all<br>
&gt; works fine - made dozens of succesfull s3 attempts. Was wondering if y=
ou<br>
&gt; guys had any thoughts on this? Is the dom0 kernel even supposed to cop=
e<br>
&gt; during s3 in non dom0 vcpu pin case?<br>
&gt;<br>
</div>No that is something new. Is this only an issue on Intel boxes but no=
t AMD?<br>
</blockquote></div><br></div>

--0016369f9dc463d6ba04d54de86a--


--===============7385874469941965729==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7385874469941965729==--


From xen-devel-bounces@lists.xen.org Mon Feb 11 08:43:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 08: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 1U4oyY-0007XM-RY; Mon, 11 Feb 2013 08:42:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U4oyW-0007XH-QZ
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 08:42:57 +0000
Received: from [85.158.139.83:15266] by server-2.bemta-5.messagelabs.com id
	37/72-16911-01FA8115; Mon, 11 Feb 2013 08:42:56 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360572173!31708962!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzA3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20753 invoked from network); 11 Feb 2013 08:42:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 08:42:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1318719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 08: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.297.1; Mon, 11 Feb 2013 08:42:53 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U4oyS-00073f-U6; Mon, 11 Feb 2013
	08:42:53 +0000
Message-ID: <5118AF07.90704@citrix.com>
Date: Mon, 11 Feb 2013 09:42:47 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>	<510F885B.2040603@citrix.com>	<20130205183236.GB5652@konrad-lan.dumpdata.com>	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
In-Reply-To: <CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
Cc: Milan opath <milan.opath@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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 Konrad. I've tried your patches, and whilst I have not seen this
>> crash in cpuidle_register anymore, the others are still present (in
>> build_schedule_domains for example).
>>
>>      
> That looks familiar too. I think it got fixed in the upstream kernel
> and it was a generic bug - but I can't recall which commit it was.
>
>    
Aha, all right.
>> I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
>> commandline stops both the xen scheduler and dom0 kernel crashing and all
>> works fine - made dozens of succesfull s3 attempts. Was wondering if you
>> guys had any thoughts on this? Is the dom0 kernel even supposed to cope
>> during s3 in non dom0 vcpu pin case?
>>
>>      
> No that is something new. Is this only an issue on Intel boxes but not AMD?
>    
I think it was primarily reproducible on sandybridge intels whilst being 
hard/impossible to repro on Ivy Bridge - and sorry - don't have an AMD 
box to make a test. It might just go away with newer kernel though, I 
think we're in the process of updating to 3.8 (previous tests were on 
3.2) so will be worth trying on that.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 08:43:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 08: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 1U4oyY-0007XM-RY; Mon, 11 Feb 2013 08:42:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tomasz.wroblewski@citrix.com>) id 1U4oyW-0007XH-QZ
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 08:42:57 +0000
Received: from [85.158.139.83:15266] by server-2.bemta-5.messagelabs.com id
	37/72-16911-01FA8115; Mon, 11 Feb 2013 08:42:56 +0000
X-Env-Sender: tomasz.wroblewski@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360572173!31708962!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzA3\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20753 invoked from network); 11 Feb 2013 08:42:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 08:42:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1318719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 08: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.297.1; Mon, 11 Feb 2013 08:42:53 +0000
Received: from zonk.cam.xci-test.com ([10.80.248.174] helo=[10.40.10.21])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<tomasz.wroblewski@citrix.com>)	id 1U4oyS-00073f-U6; Mon, 11 Feb 2013
	08:42:53 +0000
Message-ID: <5118AF07.90704@citrix.com>
Date: Mon, 11 Feb 2013 09:42:47 +0100
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120507 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>	<510F885B.2040603@citrix.com>	<20130205183236.GB5652@konrad-lan.dumpdata.com>	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
In-Reply-To: <CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
Cc: Milan opath <milan.opath@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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-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 Konrad. I've tried your patches, and whilst I have not seen this
>> crash in cpuidle_register anymore, the others are still present (in
>> build_schedule_domains for example).
>>
>>      
> That looks familiar too. I think it got fixed in the upstream kernel
> and it was a generic bug - but I can't recall which commit it was.
>
>    
Aha, all right.
>> I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
>> commandline stops both the xen scheduler and dom0 kernel crashing and all
>> works fine - made dozens of succesfull s3 attempts. Was wondering if you
>> guys had any thoughts on this? Is the dom0 kernel even supposed to cope
>> during s3 in non dom0 vcpu pin case?
>>
>>      
> No that is something new. Is this only an issue on Intel boxes but not AMD?
>    
I think it was primarily reproducible on sandybridge intels whilst being 
hard/impossible to repro on Ivy Bridge - and sorry - don't have an AMD 
box to make a test. It might just go away with newer kernel though, I 
think we're in the process of updating to 3.8 (previous tests were on 
3.2) so will be worth trying on that.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 10:50:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 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 1U4qx8-0008FO-Tc; Mon, 11 Feb 2013 10:49:38 +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 1U4qx7-0008FJ-QJ
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 10:49:38 +0000
Received: from [85.158.139.83:35643] by server-16.bemta-5.messagelabs.com id
	1A/06-14948-0CCC8115; Mon, 11 Feb 2013 10:49:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360579776!27569782!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4702 invoked from network); 11 Feb 2013 10:49:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 10:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1323806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 10:49: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.297.1;
	Mon, 11 Feb 2013 10:49:36 +0000
Message-ID: <1360579774.29432.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 10:49:34 +0000
In-Reply-To: <511264B402000078000BC754@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 Wed, 2013-02-06 at 13:12 +0000, Jan Beulich wrote:
> Apart from dealing duplicate conflicting entries, we also have to
> handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
> so has resulted in c/s 26517:601139e2b0db to crash such systems during
> boot (whereas with the change here the IOMMU gets disabled just as is
> being done in the other cases, i.e. unless global tables are being
> used).
> 
> Debugging this issue has also pointed out that the debug log output is
> pretty ugly to look at - consolidate the output, and add one extra
> item for the IVHD special entries, so that future issues are easier
> to analyze.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

Not really my area but the change looks reasonably straight forward and
fixes a real error observed in the field,
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -354,9 +354,8 @@ static int __init parse_ivmd_block(const
>      base = start_addr & PAGE_MASK;
>      limit = (start_addr + mem_length - 1) & PAGE_MASK;
>  
> -    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
> -    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
> -    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
> +    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
> +                    ivmd_block->header.type, start_addr, mem_length);
>  
>      if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
>          iw = ir = IOMMU_CONTROL_ENABLED;
> @@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias %#x\n",
> +                    first_bdf, last_bdf, alias_id);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>          add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_setting,
> @@ -654,6 +653,9 @@ static u16 __init parse_ivhd_device_spec
>          return 0;
>      }
>  
> +    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle %#x\n",
> +                    seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
> +                    special->variety, special->handle);
>      add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
>  
>      switch ( special->variety )
> @@ -758,10 +760,9 @@ static int __init parse_ivhd_block(const
>      {
>          ivhd_device = (const void *)((const u8 *)ivhd_block + block_length);
>  
> -        AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
> -        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
> -        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
> -        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);
> +        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags %#x\n",
> +                        ivhd_device->header.type, ivhd_device->header.id,
> +                        ivhd_device->header.data_setting);
>  
>          switch ( ivhd_device->header.type )
>          {
> @@ -890,6 +891,7 @@ static int __init parse_ivrs_table(struc
>  {
>      const struct acpi_ivrs_header *ivrs_block;
>      unsigned long length;
> +    unsigned int apic;
>      int error = 0;
>  
>      BUG_ON(!table);
> @@ -903,11 +905,9 @@ static int __init parse_ivrs_table(struc
>      {
>          ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>  
> -        AMD_IOMMU_DEBUG("IVRS Block:\n");
> -        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
> -        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
> -        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
> -        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
> +        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id %#x\n",
> +                        ivrs_block->type, ivrs_block->flags,
> +                        ivrs_block->length, ivrs_block->device_id);
>  
>          if ( table->length < (length + ivrs_block->length) )
>          {
> @@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc
>          length += ivrs_block->length;
>      }
>  
> +    /* Each IO-APIC must have been mentioned in the table. */
> +    for ( apic = 0; !error && apic < nr_ioapics; ++apic )
> +    {
> +        if ( !nr_ioapic_entries[apic] ||
> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            continue;
> +
> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
> +               IO_APIC_ID(apic));
> +        if ( amd_iommu_perdev_intremap )
> +            error = -ENXIO;
> +        else
> +        {
> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            {
> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> +                error = -ENOMEM;
> +            }
> +        }
> +    }
> +
>      return error;
>  }
>  
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 10:50:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 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 1U4qx8-0008FO-Tc; Mon, 11 Feb 2013 10:49:38 +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 1U4qx7-0008FJ-QJ
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 10:49:38 +0000
Received: from [85.158.139.83:35643] by server-16.bemta-5.messagelabs.com id
	1A/06-14948-0CCC8115; Mon, 11 Feb 2013 10:49:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360579776!27569782!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4702 invoked from network); 11 Feb 2013 10:49:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 10:49:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1323806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 10:49: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.297.1;
	Mon, 11 Feb 2013 10:49:36 +0000
Message-ID: <1360579774.29432.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 10:49:34 +0000
In-Reply-To: <511264B402000078000BC754@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 Wed, 2013-02-06 at 13:12 +0000, Jan Beulich wrote:
> Apart from dealing duplicate conflicting entries, we also have to
> handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
> so has resulted in c/s 26517:601139e2b0db to crash such systems during
> boot (whereas with the change here the IOMMU gets disabled just as is
> being done in the other cases, i.e. unless global tables are being
> used).
> 
> Debugging this issue has also pointed out that the debug log output is
> pretty ugly to look at - consolidate the output, and add one extra
> item for the IVHD special entries, so that future issues are easier
> to analyze.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

Not really my area but the change looks reasonably straight forward and
fixes a real error observed in the field,
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -354,9 +354,8 @@ static int __init parse_ivmd_block(const
>      base = start_addr & PAGE_MASK;
>      limit = (start_addr + mem_length - 1) & PAGE_MASK;
>  
> -    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
> -    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
> -    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
> +    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
> +                    ivmd_block->header.type, start_addr, mem_length);
>  
>      if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
>          iw = ir = IOMMU_CONTROL_ENABLED;
> @@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias %#x\n",
> +                    first_bdf, last_bdf, alias_id);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>          add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_setting,
> @@ -654,6 +653,9 @@ static u16 __init parse_ivhd_device_spec
>          return 0;
>      }
>  
> +    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle %#x\n",
> +                    seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
> +                    special->variety, special->handle);
>      add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
>  
>      switch ( special->variety )
> @@ -758,10 +760,9 @@ static int __init parse_ivhd_block(const
>      {
>          ivhd_device = (const void *)((const u8 *)ivhd_block + block_length);
>  
> -        AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
> -        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
> -        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
> -        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);
> +        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags %#x\n",
> +                        ivhd_device->header.type, ivhd_device->header.id,
> +                        ivhd_device->header.data_setting);
>  
>          switch ( ivhd_device->header.type )
>          {
> @@ -890,6 +891,7 @@ static int __init parse_ivrs_table(struc
>  {
>      const struct acpi_ivrs_header *ivrs_block;
>      unsigned long length;
> +    unsigned int apic;
>      int error = 0;
>  
>      BUG_ON(!table);
> @@ -903,11 +905,9 @@ static int __init parse_ivrs_table(struc
>      {
>          ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>  
> -        AMD_IOMMU_DEBUG("IVRS Block:\n");
> -        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
> -        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
> -        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
> -        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
> +        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id %#x\n",
> +                        ivrs_block->type, ivrs_block->flags,
> +                        ivrs_block->length, ivrs_block->device_id);
>  
>          if ( table->length < (length + ivrs_block->length) )
>          {
> @@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc
>          length += ivrs_block->length;
>      }
>  
> +    /* Each IO-APIC must have been mentioned in the table. */
> +    for ( apic = 0; !error && apic < nr_ioapics; ++apic )
> +    {
> +        if ( !nr_ioapic_entries[apic] ||
> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            continue;
> +
> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
> +               IO_APIC_ID(apic));
> +        if ( amd_iommu_perdev_intremap )
> +            error = -ENXIO;
> +        else
> +        {
> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
> +            {
> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
> +                error = -ENOMEM;
> +            }
> +        }
> +    }
> +
>      return error;
>  }
>  
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 10:54:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10: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 1U4r16-0008Ni-In; Mon, 11 Feb 2013 10:53: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 1U4r15-0008NZ-2N
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 10:53:43 +0000
Received: from [85.158.137.99:18997] by server-9.bemta-3.messagelabs.com id
	03/43-09484-6BDC8115; Mon, 11 Feb 2013 10:53:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360580019!15483967!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8008 invoked from network); 11 Feb 2013 10:53:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 10:53:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1323941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 10:53: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.297.1;
	Mon, 11 Feb 2013 10:53:39 +0000
Message-ID: <1360580018.29432.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 10:53:38 +0000
In-Reply-To: <511264DA02000078000BC758@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264DA02000078000BC758@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] AMD IOMMU: handle MSI for phantom
 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 Wed, 2013-02-06 at 13:12 +0000, Jan Beulich wrote:
> @@ -379,12 +382,30 @@ void amd_iommu_msi_msg_update_ire(
>      }
>  
>      if ( msi_desc->remap_index >= 0 )
> -        update_intremap_entry_from_msi_msg(iommu, bdf, msi_desc, NULL);
> +    {
> +        do {
> +            update_intremap_entry_from_msi_msg(iommu, bdf,
> +                                               &msi_desc->remap_index, NULL);
> +            if ( !pdev || !pdev->phantom_stride )
> +                break;
> +            bdf += pdev->phantom_stride;
> +        } while ( PCI_SLOT(bdf) == PCI_SLOT(pdev->devfn) );
> +
> +        msi_desc->remap_index = -1;

The reason for this reset is a bit subtle, but I think I get it, might
be worth a comment though.

Otherwise: Acked-by: Ian Campbell <ian.campbell@citrix.com>
(although with similar caveats to 1/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 Feb 11 10:54:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10: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 1U4r16-0008Ni-In; Mon, 11 Feb 2013 10:53: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 1U4r15-0008NZ-2N
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 10:53:43 +0000
Received: from [85.158.137.99:18997] by server-9.bemta-3.messagelabs.com id
	03/43-09484-6BDC8115; Mon, 11 Feb 2013 10:53:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360580019!15483967!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8008 invoked from network); 11 Feb 2013 10:53:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 10:53:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1323941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 10:53: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.297.1;
	Mon, 11 Feb 2013 10:53:39 +0000
Message-ID: <1360580018.29432.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 10:53:38 +0000
In-Reply-To: <511264DA02000078000BC758@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264DA02000078000BC758@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] AMD IOMMU: handle MSI for phantom
 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 Wed, 2013-02-06 at 13:12 +0000, Jan Beulich wrote:
> @@ -379,12 +382,30 @@ void amd_iommu_msi_msg_update_ire(
>      }
>  
>      if ( msi_desc->remap_index >= 0 )
> -        update_intremap_entry_from_msi_msg(iommu, bdf, msi_desc, NULL);
> +    {
> +        do {
> +            update_intremap_entry_from_msi_msg(iommu, bdf,
> +                                               &msi_desc->remap_index, NULL);
> +            if ( !pdev || !pdev->phantom_stride )
> +                break;
> +            bdf += pdev->phantom_stride;
> +        } while ( PCI_SLOT(bdf) == PCI_SLOT(pdev->devfn) );
> +
> +        msi_desc->remap_index = -1;

The reason for this reset is a bit subtle, but I think I get it, might
be worth a comment though.

Otherwise: Acked-by: Ian Campbell <ian.campbell@citrix.com>
(although with similar caveats to 1/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 Feb 11 10:57:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10: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 1U4r4i-0008Vo-7a; Mon, 11 Feb 2013 10:57:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U4qns-0008Cp-EN
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 10:40:05 +0000
Received: from [85.158.143.35:24166] by server-1.bemta-4.messagelabs.com id
	61/BA-08839-38AC8115; Mon, 11 Feb 2013 10:40:03 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360579201!4203477!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5997 invoked from network); 11 Feb 2013 10:40:02 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Feb 2013 10:40:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=DJJr3FMgBuY13Iv/EL5v9wG+E1p92AEKeVei0zBidTI=; 
	b=KNy/ySWnqbiEwKLb3HBxAuqEL/75G6p73CHpWo56iNNJJpjBqjNdHcYmhIl14KIHeB1/5XZ2wLSE20gkHphQL4wOj8nfTVTHlPhUqvrEaYM0qRxzHAeTNB2coLk+sMeMeount1k40iEmK9f7Ng3opJyk48MWsPftZcOqoLLjCCI=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>)
	id 1U4qnk-0003Yp-Fd; Mon, 11 Feb 2013 11:39:56 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id RhRh+dE-9sZz; Mon, 11 Feb 2013 11:39:51 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>)
	id 1U4qne-0003YV-VO; Mon, 11 Feb 2013 11:39:51 +0100
Message-ID: <5118CA6C.8060809@crysys.hu>
Date: Mon, 11 Feb 2013 11:39:40 +0100
From: =?UTF-8?B?R8OhYm9yIFDDiUs=?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511510FA.8010109@crysys.hu>
	<51153C2902000078000BD4A6@nat28.tlf.novell.com>
In-Reply-To: <51153C2902000078000BD4A6@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
X-Mailman-Approved-At: Mon, 11 Feb 2013 10:57:26 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] NMI SERR interrupts in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAxMy4wMi4wOC4gMTc6NTUsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDA4LjAyLjEz
IGF0IDE1OjUxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90ZToKPj4gWytdIEF0IHRo
ZSBzYW1lIHRpbWUsIFBDSSBTRVJSIGludGVycnVwdHMgcmVmZXIgdG8gaGFyZHdhcmUgZXJyb3Jz
IHRoYXQKPj4gaXMgZ2VuZXJhdGVkIGJ5IG15IHBhc3N0aHJvdWdoIE5JQyBkaXJlY3RseSwgc28g
SSBleHBlY3QgdGhhdCB0aGVzZQo+PiBpbnRlcnJ1cHRzIGFyZSBwaHlzaWNhbCAoZS5nLiwgTVNJ
cykgc28gdGhleSBzaG91bGQgZ28gZGlyZWN0bHkgZWl0aGVyCj4+IHRvIHRoZSBCU1Agb3Igb25l
IG9mIHRoZSBBUHMuIEhvd2V2ZXIsIEludGVycnVwdCByZW1hcHBpbmcgaXMgaW4gcGxhY2UKPj4g
d2hpY2ggc2hvdWxkIGNoZWNrIHRoZSBvcmlnaW4gb2Ygc3VjaCBpbnRlcnJ1cHRzIGFuZCBzaG91
bGQgcmVtYXAgdGhlCj4+IGludGVycnVwdHMgYnkgdXNpbmcgdGhlIEJERiBpZCBvZiB0aGUgZGV2
aWNlLiBUaHVzLCB0aGUgcmVhbCBpbnRlcnJ1cHQKPj4gaXMgZ2VuZXJhdGVkIGJ5IHRoZSBJbnRl
cnJ1cHQgUmVtYXBwaW5nIGhhcmR3YXJlIHVuaXQgd2hpY2ggaXMgc3RpbGwgYQo+PiBwaHlzaWNh
bCBvbmUuIEFtIEkgcmlnaHQ/Cj4gCj4gTm8sIE5NSXMgZG9uJ3QgZ28gdGhyb3VnaCB0aGUgcmVt
YXBwaW5nIGhhcmR3YXJlLCB0aGV5IGdldAo+IGRlbGl2ZXJlZCBkaXJlY3RseSB0byB0aGUgQ1BV
LiBXaGljaCBtYWtlcyBzZW5zZSwgYmVjYXVzZSB0aGV5Cj4gcG9pbnQgb3V0IGEgcHJvYmxlbSBp
biB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIHJlZ2FyZGxlc3Mgb2YKPiB3aGV0aGVyIGEgZGV2aWNl
IGhhdmluZyBjYXVzZWQgdGhlbSBpcyBhc3NpZ25lZCB0byBhIGd1ZXN0CgpJIGZhY2VkIHRoaXMg
Tk1JIGlzc3VlIHdoaWxlIGxvb2tpbmcgYXQgdGhlIHNlY3VyaXR5IG9mIFhlbiwgaG93ZXZlciwg
aXQKcmFpc2VzIHNlY3VyaXR5IGNvbmNlcm5zIGluIG15IG1pbmQuIElmIGFuIE5NSSBkb2VzIG5v
dCBnbyB0aHJvdWdoIHRoZQpJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuZ2luZSAod2hpY2ggbWFrZXMg
c2Vuc2UgZHVlIHRvIGl0cyBub24tbWFza2FibGUKbmF0dXJlKSwgdGhlbiBhICJtYWxpY2lvdXMi
IE5NSSBjb3VsZCBnaXZlIHJpc2UgdG8gZWl0aGVyIGEgRG9TIGF0dGFjawpvciBjb2RlIGV4ZWN1
dGlvbiBwcm9ibGVtcyB3aXRoIHJpbmcxIHByaXZpbGVnZXMuIEluIHRoZSBmb3JtZXIgY2FzZSB0
aGUKcmVhc29uIGNvdWxkIGJlIHRoZSB1bmNsZWFyZWQgRU9JIHJlZ2lzdGVyIGZvciB0aGUgc3Bl
Y2lmaWMgQ1BVIGFmdGVyCk5NSSBnZW5lcmF0aW9uLCB3aGlsZSBpbiB0aGUgbGF0dGVyIGNhc2Ug
dGhlIGNvZGUgaW5qZWN0aW9uIG1pZ2h0IGJlCmRpZmZpY3VsdCwgYnV0IHRoZSBjb25jZXJuIGlz
IHN0aWxsIHZhbGlkIEkgdGhpbmsuCgpGdXJ0aGVybW9yZSwgYW4gYXR0YWNrZXIgY2FuIGdlbmVy
YXRlIHN1Y2ggTk1JcyB2aWEgTVNJcyBmcm9tIHVudHJ1c3RlZApIVk0gZG9tYWlucyBieSBtZWFu
cyBvZiBhIFBUIGRldmljZSBpbiB4QVBJQyBtb2RlIGVhc2lseS4geDJBUElDIG1vZGUKKGluIHRv
Z2V0aGVyIHdpdGggSW50ZXJydXB0IFJlbWFwcGluZykgY291bGQgZ2l2ZSBtaXRpZ2F0aW9uIGFn
YWluc3QKc3VjaCBtYWxpY2lvdXMgRE1BIHdyaXRlcyBieSBhY2Nlc3NpbmcgTEFQSUMgcmVnaXN0
ZXJzIHZpYSBNU1JzIGFuZAplbmZvcmNpbmcgdGhlIFJlbWFwcGFibGUgTVNJIGZvcm1hdC4gSG93
ZXZlciwgaWYgYW4gYXR0YWNrZXIgY2FuIGNyZWF0ZQpOTUkgY29uZGl0aW9ucyBpbiB4MmFwaWMg
bW9kZSBhcyB3ZWxsLCB0aGVuIHRoZSBSZW1hcHBhYmxlIEZvcm1hdCBkb2VzCm5vdCBtYWtlIHNl
bnNlIGF0IGFsbCAoYXMgdGhlIE5NSSBpcyBub3QgaGFuZGxlZCBieSB0aGUgcmVtYXBwaW5nCmVu
Z2luZSkuIFNvIHdoYXQgSSBmZWVsIHRoYXQgdGhlcmUgaXMgbm8gcmVhbCBoYXJkd2FyZS9zb2Z0
d2FyZSBzb2x1dGlvbgpmb3IgdGhpcyBpc3N1ZS4uLgo+IAo+IE5vdGUgdGhhdCBiZWNhdXNlIG9m
IHRoZSBwb3NzaWJpbGl0eSBvZiBtdWx0aXBsZSBkZXZpY2VzIHJhaXNpbmcKPiBzdWNoIGFuIE5N
SSwgSSB0aGluayBpdCBpcyBhbHNvIG5vdCBwb3NzaWJsZSBmb3IgWGVuIHRvIGFjdHVhbGx5IGtu
b3cKPiB3aGljaCBkZXZpY2UocykgY2F1c2VkIHRoZSBOTUksIGFuZCBoZW5jZSBpdCBoYXMgbm8g
d2F5IHRvCj4gYXNzb2NpYXRlIGl0IHdpdGggYSBwYXJ0aWN1bGFyIGd1ZXN0LCBldmVuIGlmIGl0
IHdhbnRlZCB0by4KCkNhbiB0aGlzIGV4cGxhaW4gd2h5IG15IE5NSSBkb2VzIG5vdCBhcHBlYXIg
aW4gdGhlIC9wcm9jL2ludGVycnVwdHMgaW4KZG9tMCB3aGlsZSB0aGUgaGFuZGxlciBpcyBleGVj
dXRlZCB3aXRoIHJpbmcxIHByaXZpbGVnZXM/CgpUaGFuayB5b3UhCi1nYWJvcgoKPiAKPiBKYW4K
PiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 11 10:57:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10: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 1U4r4i-0008Vo-7a; Mon, 11 Feb 2013 10:57:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U4qns-0008Cp-EN
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 10:40:05 +0000
Received: from [85.158.143.35:24166] by server-1.bemta-4.messagelabs.com id
	61/BA-08839-38AC8115; Mon, 11 Feb 2013 10:40:03 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360579201!4203477!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5997 invoked from network); 11 Feb 2013 10:40:02 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Feb 2013 10:40:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=DJJr3FMgBuY13Iv/EL5v9wG+E1p92AEKeVei0zBidTI=; 
	b=KNy/ySWnqbiEwKLb3HBxAuqEL/75G6p73CHpWo56iNNJJpjBqjNdHcYmhIl14KIHeB1/5XZ2wLSE20gkHphQL4wOj8nfTVTHlPhUqvrEaYM0qRxzHAeTNB2coLk+sMeMeount1k40iEmK9f7Ng3opJyk48MWsPftZcOqoLLjCCI=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>)
	id 1U4qnk-0003Yp-Fd; Mon, 11 Feb 2013 11:39:56 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id RhRh+dE-9sZz; Mon, 11 Feb 2013 11:39:51 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>)
	id 1U4qne-0003YV-VO; Mon, 11 Feb 2013 11:39:51 +0100
Message-ID: <5118CA6C.8060809@crysys.hu>
Date: Mon, 11 Feb 2013 11:39:40 +0100
From: =?UTF-8?B?R8OhYm9yIFDDiUs=?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511510FA.8010109@crysys.hu>
	<51153C2902000078000BD4A6@nat28.tlf.novell.com>
In-Reply-To: <51153C2902000078000BD4A6@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
X-Mailman-Approved-At: Mon, 11 Feb 2013 10:57:26 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] NMI SERR interrupts in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAxMy4wMi4wOC4gMTc6NTUsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDA4LjAyLjEz
IGF0IDE1OjUxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90ZToKPj4gWytdIEF0IHRo
ZSBzYW1lIHRpbWUsIFBDSSBTRVJSIGludGVycnVwdHMgcmVmZXIgdG8gaGFyZHdhcmUgZXJyb3Jz
IHRoYXQKPj4gaXMgZ2VuZXJhdGVkIGJ5IG15IHBhc3N0aHJvdWdoIE5JQyBkaXJlY3RseSwgc28g
SSBleHBlY3QgdGhhdCB0aGVzZQo+PiBpbnRlcnJ1cHRzIGFyZSBwaHlzaWNhbCAoZS5nLiwgTVNJ
cykgc28gdGhleSBzaG91bGQgZ28gZGlyZWN0bHkgZWl0aGVyCj4+IHRvIHRoZSBCU1Agb3Igb25l
IG9mIHRoZSBBUHMuIEhvd2V2ZXIsIEludGVycnVwdCByZW1hcHBpbmcgaXMgaW4gcGxhY2UKPj4g
d2hpY2ggc2hvdWxkIGNoZWNrIHRoZSBvcmlnaW4gb2Ygc3VjaCBpbnRlcnJ1cHRzIGFuZCBzaG91
bGQgcmVtYXAgdGhlCj4+IGludGVycnVwdHMgYnkgdXNpbmcgdGhlIEJERiBpZCBvZiB0aGUgZGV2
aWNlLiBUaHVzLCB0aGUgcmVhbCBpbnRlcnJ1cHQKPj4gaXMgZ2VuZXJhdGVkIGJ5IHRoZSBJbnRl
cnJ1cHQgUmVtYXBwaW5nIGhhcmR3YXJlIHVuaXQgd2hpY2ggaXMgc3RpbGwgYQo+PiBwaHlzaWNh
bCBvbmUuIEFtIEkgcmlnaHQ/Cj4gCj4gTm8sIE5NSXMgZG9uJ3QgZ28gdGhyb3VnaCB0aGUgcmVt
YXBwaW5nIGhhcmR3YXJlLCB0aGV5IGdldAo+IGRlbGl2ZXJlZCBkaXJlY3RseSB0byB0aGUgQ1BV
LiBXaGljaCBtYWtlcyBzZW5zZSwgYmVjYXVzZSB0aGV5Cj4gcG9pbnQgb3V0IGEgcHJvYmxlbSBp
biB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIHJlZ2FyZGxlc3Mgb2YKPiB3aGV0aGVyIGEgZGV2aWNl
IGhhdmluZyBjYXVzZWQgdGhlbSBpcyBhc3NpZ25lZCB0byBhIGd1ZXN0CgpJIGZhY2VkIHRoaXMg
Tk1JIGlzc3VlIHdoaWxlIGxvb2tpbmcgYXQgdGhlIHNlY3VyaXR5IG9mIFhlbiwgaG93ZXZlciwg
aXQKcmFpc2VzIHNlY3VyaXR5IGNvbmNlcm5zIGluIG15IG1pbmQuIElmIGFuIE5NSSBkb2VzIG5v
dCBnbyB0aHJvdWdoIHRoZQpJbnRlcnJ1cHQgUmVtYXBwaW5nIGVuZ2luZSAod2hpY2ggbWFrZXMg
c2Vuc2UgZHVlIHRvIGl0cyBub24tbWFza2FibGUKbmF0dXJlKSwgdGhlbiBhICJtYWxpY2lvdXMi
IE5NSSBjb3VsZCBnaXZlIHJpc2UgdG8gZWl0aGVyIGEgRG9TIGF0dGFjawpvciBjb2RlIGV4ZWN1
dGlvbiBwcm9ibGVtcyB3aXRoIHJpbmcxIHByaXZpbGVnZXMuIEluIHRoZSBmb3JtZXIgY2FzZSB0
aGUKcmVhc29uIGNvdWxkIGJlIHRoZSB1bmNsZWFyZWQgRU9JIHJlZ2lzdGVyIGZvciB0aGUgc3Bl
Y2lmaWMgQ1BVIGFmdGVyCk5NSSBnZW5lcmF0aW9uLCB3aGlsZSBpbiB0aGUgbGF0dGVyIGNhc2Ug
dGhlIGNvZGUgaW5qZWN0aW9uIG1pZ2h0IGJlCmRpZmZpY3VsdCwgYnV0IHRoZSBjb25jZXJuIGlz
IHN0aWxsIHZhbGlkIEkgdGhpbmsuCgpGdXJ0aGVybW9yZSwgYW4gYXR0YWNrZXIgY2FuIGdlbmVy
YXRlIHN1Y2ggTk1JcyB2aWEgTVNJcyBmcm9tIHVudHJ1c3RlZApIVk0gZG9tYWlucyBieSBtZWFu
cyBvZiBhIFBUIGRldmljZSBpbiB4QVBJQyBtb2RlIGVhc2lseS4geDJBUElDIG1vZGUKKGluIHRv
Z2V0aGVyIHdpdGggSW50ZXJydXB0IFJlbWFwcGluZykgY291bGQgZ2l2ZSBtaXRpZ2F0aW9uIGFn
YWluc3QKc3VjaCBtYWxpY2lvdXMgRE1BIHdyaXRlcyBieSBhY2Nlc3NpbmcgTEFQSUMgcmVnaXN0
ZXJzIHZpYSBNU1JzIGFuZAplbmZvcmNpbmcgdGhlIFJlbWFwcGFibGUgTVNJIGZvcm1hdC4gSG93
ZXZlciwgaWYgYW4gYXR0YWNrZXIgY2FuIGNyZWF0ZQpOTUkgY29uZGl0aW9ucyBpbiB4MmFwaWMg
bW9kZSBhcyB3ZWxsLCB0aGVuIHRoZSBSZW1hcHBhYmxlIEZvcm1hdCBkb2VzCm5vdCBtYWtlIHNl
bnNlIGF0IGFsbCAoYXMgdGhlIE5NSSBpcyBub3QgaGFuZGxlZCBieSB0aGUgcmVtYXBwaW5nCmVu
Z2luZSkuIFNvIHdoYXQgSSBmZWVsIHRoYXQgdGhlcmUgaXMgbm8gcmVhbCBoYXJkd2FyZS9zb2Z0
d2FyZSBzb2x1dGlvbgpmb3IgdGhpcyBpc3N1ZS4uLgo+IAo+IE5vdGUgdGhhdCBiZWNhdXNlIG9m
IHRoZSBwb3NzaWJpbGl0eSBvZiBtdWx0aXBsZSBkZXZpY2VzIHJhaXNpbmcKPiBzdWNoIGFuIE5N
SSwgSSB0aGluayBpdCBpcyBhbHNvIG5vdCBwb3NzaWJsZSBmb3IgWGVuIHRvIGFjdHVhbGx5IGtu
b3cKPiB3aGljaCBkZXZpY2UocykgY2F1c2VkIHRoZSBOTUksIGFuZCBoZW5jZSBpdCBoYXMgbm8g
d2F5IHRvCj4gYXNzb2NpYXRlIGl0IHdpdGggYSBwYXJ0aWN1bGFyIGd1ZXN0LCBldmVuIGlmIGl0
IHdhbnRlZCB0by4KCkNhbiB0aGlzIGV4cGxhaW4gd2h5IG15IE5NSSBkb2VzIG5vdCBhcHBlYXIg
aW4gdGhlIC9wcm9jL2ludGVycnVwdHMgaW4KZG9tMCB3aGlsZSB0aGUgaGFuZGxlciBpcyBleGVj
dXRlZCB3aXRoIHJpbmcxIHByaXZpbGVnZXM/CgpUaGFuayB5b3UhCi1nYWJvcgoKPiAKPiBKYW4K
PiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 11 10:58:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10:58: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 1U4r5V-00007G-LY; Mon, 11 Feb 2013 10:58:17 +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 1U4r5U-000079-AC
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 10:58:16 +0000
Received: from [193.109.254.147:30152] by server-16.bemta-14.messagelabs.com
	id 38/A4-25906-7CEC8115; Mon, 11 Feb 2013 10:58:15 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360580294!2406958!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27562 invoked from network); 11 Feb 2013 10:58:14 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-11.tower-27.messagelabs.com with SMTP;
	11 Feb 2013 10:58:14 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 7A758646CB2;
	Mon, 11 Feb 2013 11:58:13 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 11 Feb 2013 11:57:21 +0100
Message-Id: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="stdvga"|"cirrus"

- Default option is cirrus.
- Prints error and exit if unknown value is passed.
- stdvga parameter is now deprecated.
- Updated xl.cfg man.

Required patch: Improve videoram setting v5
Is prerequisite for patch: Add qxl support v9

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 docs/man/xl.cfg.pod.5    |    8 +++++++-
 tools/libxl/xl_cmdimpl.c |   14 +++++++++++++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9c5cdcd..9862842 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -979,7 +979,7 @@ The default amount of video ram for stdvga is 8MB which is sufficient
 for e.g. 1600x1200 at 32bpp and videoram option is currently working
 only when using the qemu-xen-traditional device-model.
 
-When using the emulated Cirrus graphics card (B<stdvga=0>)
+When using the emulated Cirrus graphics card (B<vga="cirrus">)
 the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
@@ -991,6 +991,12 @@ emulated graphics device. The default is false which means to emulate
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
 stdvga supports more video ram and bigger resolutions than Cirrus.
+This option is deprecated, use vga="stdvga" instead.
+
+=item B<vga="STRING">
+
+Selects the emulated video card (stdvga|cirrus).
+The default is cirrus.
 
 =item B<vnc=BOOLEAN>
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080bbd8..f9101ba 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1469,7 +1469,19 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+        if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
+            if (!strcmp(buf, "stdvga")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_STD;
+            } else if (!strcmp(buf, "cirrus")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            } else {
+                fprintf(stderr,
+                "Unknown vga \"%s\" specified\n", buf);
+                exit(1);
+            }
+        } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
             b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
                                          LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
 
-- 
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 Mon Feb 11 10:58:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10:58: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 1U4r5V-00007G-LY; Mon, 11 Feb 2013 10:58:17 +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 1U4r5U-000079-AC
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 10:58:16 +0000
Received: from [193.109.254.147:30152] by server-16.bemta-14.messagelabs.com
	id 38/A4-25906-7CEC8115; Mon, 11 Feb 2013 10:58:15 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360580294!2406958!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27562 invoked from network); 11 Feb 2013 10:58:14 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-11.tower-27.messagelabs.com with SMTP;
	11 Feb 2013 10:58:14 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 7A758646CB2;
	Mon, 11 Feb 2013 11:58:13 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 11 Feb 2013 11:57:21 +0100
Message-Id: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="stdvga"|"cirrus"

- Default option is cirrus.
- Prints error and exit if unknown value is passed.
- stdvga parameter is now deprecated.
- Updated xl.cfg man.

Required patch: Improve videoram setting v5
Is prerequisite for patch: Add qxl support v9

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 docs/man/xl.cfg.pod.5    |    8 +++++++-
 tools/libxl/xl_cmdimpl.c |   14 +++++++++++++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9c5cdcd..9862842 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -979,7 +979,7 @@ The default amount of video ram for stdvga is 8MB which is sufficient
 for e.g. 1600x1200 at 32bpp and videoram option is currently working
 only when using the qemu-xen-traditional device-model.
 
-When using the emulated Cirrus graphics card (B<stdvga=0>)
+When using the emulated Cirrus graphics card (B<vga="cirrus">)
 the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
@@ -991,6 +991,12 @@ emulated graphics device. The default is false which means to emulate
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
 stdvga supports more video ram and bigger resolutions than Cirrus.
+This option is deprecated, use vga="stdvga" instead.
+
+=item B<vga="STRING">
+
+Selects the emulated video card (stdvga|cirrus).
+The default is cirrus.
 
 =item B<vnc=BOOLEAN>
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080bbd8..f9101ba 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1469,7 +1469,19 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
+        if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
+            if (!strcmp(buf, "stdvga")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_STD;
+            } else if (!strcmp(buf, "cirrus")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            } else {
+                fprintf(stderr,
+                "Unknown vga \"%s\" specified\n", buf);
+                exit(1);
+            }
+        } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
             b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
                                          LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
 
-- 
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 Mon Feb 11 10:59:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10:59: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 1U4r64-0000Ax-2h; Mon, 11 Feb 2013 10:58:52 +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 1U4r63-0000Ah-47
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 10:58:51 +0000
Received: from [85.158.138.51:64548] by server-4.bemta-3.messagelabs.com id
	76/58-12802-AEEC8115; Mon, 11 Feb 2013 10:58:50 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360580328!31896771!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 11 Feb 2013 10:58:49 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-9.tower-174.messagelabs.com with SMTP;
	11 Feb 2013 10:58:49 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 40EE1646CC9;
	Mon, 11 Feb 2013 11:58:48 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 11 Feb 2013 11:58:38 +0100
Message-Id: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface support
	for upstream 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="qxl"

Changes from v8:
- vga=qxl instead of qxl=1 to use it.
- Show an error and exit if vga="qxl" without qemu upstream.
- Other small improvements.

Required patches:
- Improve videoram setting v5
- Added vga parameter for hvm domUs

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
---
 docs/man/xl.cfg.pod.5       |   10 +++++++++-
 tools/libxl/libxl_create.c  |   17 +++++++++++++++++
 tools/libxl/libxl_dm.c      |   13 +++++++++++++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    3 +++
 5 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9862842..a3b3645 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
+For B<qxl> vga, the default is both default and minimal 128MB.
+If B<videoram> is set less than 128MB, an error will be triggered.
+
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -995,9 +998,14 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus).
+Selects the emulated video card (stdvga|cirrus|qxl).
 The default is cirrus.
 
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.
+
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index cf545ef..67b5e6e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -197,6 +197,23 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
+
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->device_model_version ==
+               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                    b_info->video_memkb = (128 * 1024);
+                }else if (b_info->video_memkb < (128 * 1024)) {
+                    LOG(ERROR,
+                    "128 Mib videoram is the minimum for qxl default");
+                    return ERROR_INVAL;
+                }
+            } else {
+                LOG(ERROR,"qemu upstream required for qxl vga");
+                return ERROR_INVAL;
+            }
+        }
+
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
         else if (b_info->video_memkb < 8192){
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2c99bd..59fc86a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -440,6 +442,17 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                 NULL);
             }
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            /*QXL have 2 ram regions, ram and vram*/
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), "-global",
+                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), NULL);
+            }
+            break;
         }
 
         if (b_info->u.hvm.boot) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index acc4bc9..3f90f12 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f9101ba..b20c185 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1476,6 +1476,9 @@ skip_vfb:
             } else if (!strcmp(buf, "cirrus")) {
                 b_info->u.hvm.vga.kind
                 = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }else if (!strcmp(buf, "qxl")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
                 fprintf(stderr,
                 "Unknown vga \"%s\" specified\n", buf);
-- 
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 Mon Feb 11 10:59:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 10:59: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 1U4r64-0000Ax-2h; Mon, 11 Feb 2013 10:58:52 +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 1U4r63-0000Ah-47
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 10:58:51 +0000
Received: from [85.158.138.51:64548] by server-4.bemta-3.messagelabs.com id
	76/58-12802-AEEC8115; Mon, 11 Feb 2013 10:58:50 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360580328!31896771!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDIyNTM=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 11 Feb 2013 10:58:49 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-9.tower-174.messagelabs.com with SMTP;
	11 Feb 2013 10:58:49 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 40EE1646CC9;
	Mon, 11 Feb 2013 11:58:48 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 11 Feb 2013 11:58:38 +0100
Message-Id: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface support
	for upstream 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="qxl"

Changes from v8:
- vga=qxl instead of qxl=1 to use it.
- Show an error and exit if vga="qxl" without qemu upstream.
- Other small improvements.

Required patches:
- Improve videoram setting v5
- Added vga parameter for hvm domUs

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
---
 docs/man/xl.cfg.pod.5       |   10 +++++++++-
 tools/libxl/libxl_create.c  |   17 +++++++++++++++++
 tools/libxl/libxl_dm.c      |   13 +++++++++++++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    3 +++
 5 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9862842..a3b3645 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
+For B<qxl> vga, the default is both default and minimal 128MB.
+If B<videoram> is set less than 128MB, an error will be triggered.
+
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -995,9 +998,14 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus).
+Selects the emulated video card (stdvga|cirrus|qxl).
 The default is cirrus.
 
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.
+
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index cf545ef..67b5e6e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -197,6 +197,23 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
+
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->device_model_version ==
+               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                    b_info->video_memkb = (128 * 1024);
+                }else if (b_info->video_memkb < (128 * 1024)) {
+                    LOG(ERROR,
+                    "128 Mib videoram is the minimum for qxl default");
+                    return ERROR_INVAL;
+                }
+            } else {
+                LOG(ERROR,"qemu upstream required for qxl vga");
+                return ERROR_INVAL;
+            }
+        }
+
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
         else if (b_info->video_memkb < 8192){
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2c99bd..59fc86a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -440,6 +442,17 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                 NULL);
             }
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            /*QXL have 2 ram regions, ram and vram*/
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), "-global",
+                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), NULL);
+            }
+            break;
         }
 
         if (b_info->u.hvm.boot) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index acc4bc9..3f90f12 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f9101ba..b20c185 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1476,6 +1476,9 @@ skip_vfb:
             } else if (!strcmp(buf, "cirrus")) {
                 b_info->u.hvm.vga.kind
                 = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }else if (!strcmp(buf, "qxl")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
                 fprintf(stderr,
                 "Unknown vga \"%s\" specified\n", buf);
-- 
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 Mon Feb 11 11:15:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:15: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 1U4rLb-0000eb-RS; Mon, 11 Feb 2013 11:14:55 +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 1U4rLZ-0000eW-Fd
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:14:53 +0000
Received: from [85.158.139.211:33726] by server-13.bemta-5.messagelabs.com id
	7B/72-06769-CA2D8115; Mon, 11 Feb 2013 11:14:52 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360581290!18012068!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2901 invoked from network); 11 Feb 2013 11:14:51 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:14:51 -0000
Received: by mail-wg0-f48.google.com with SMTP id 16so4592165wgi.27
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 03:13:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=QV5vWIFPEgRdceWm8uvl0s6lPk2x7Wzwxx0vW5CfHpw=;
	b=GV7vtD+N1cbBQKYfioh1kexT04LEljHLjXSeAzkszyRAf+o8rjExRowU677F9fjM2J
	Oq3XYXf4U/1BoIQtIDqT2wjkGtDAM9PiESi5LgFBFj1VhDk8s9149zUNFp5yFYRpjXVh
	LQXxAHWmA00F0p+2ylPbVTQtpgPwKdGOtsWszgCsRU+SW8wYAUZb2RHrnbzeB4QmfeKa
	AmPXldgYqloNjBpnvIyHBKrSVi8kPEJgOdGSCjC0pkBOD0lSVSHk5vwrbpRSVZlcnKD7
	p8Mn2hg9NstcxbJdelSYsL2+vqJ801BRHHWVWfTr3ahxEj2JLRJQwuzH8P1ogsAAQFT9
	6HvQ==
MIME-Version: 1.0
X-Received: by 10.194.122.199 with SMTP id lu7mr22998833wjb.42.1360581212375; 
	Mon, 11 Feb 2013 03:13:32 -0800 (PST)
Received: by 10.194.136.98 with HTTP; Mon, 11 Feb 2013 03:13:32 -0800 (PST)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
Date: Mon, 11 Feb 2013 11:13:32 +0000
X-Google-Sender-Auth: ALn8v0hcQX5PsJfWdCbBZliom5I
Message-ID: <CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0370826621984662906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0370826621984662906==
Content-Type: multipart/alternative; boundary=089e012292e4da097404d570fff2

--089e012292e4da097404d570fff2
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 11, 2013 at 12:03 AM, James Harper <
james.harper@bendigoit.com.au> wrote:

> A user has pointed out a problem with GPLPV under Xen 4.2 when using PoD.
> I'm using the difference between XENMEM_maximum_reservation and
> XENMEM_current_reservation to tell me how much I should balloon down to
> account for PoD, but when the user has ballooned down to 1G (from 4Gb or
> 8GB), GPLPV logs the following:
>
> 13005008825593: XenPCI     XENMEM_maximum_reservation = 262400
> 13005008825593: XenPCI     XENMEM_current_reservation = 262136
> 13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
>
> What is the correct way to tell how much PoD memory there is under 4.2? Am
> I doing it wrong?
>
> I balloon down as early as possible (before xenbus starts) to avoid
> windows going over its limit so I'm hoping I can determine the size of PoD
> memory just via hypercalls.
>

You shouldn't have to know anything specifically about PoD -- you should
just look at the balloon target for the guest written in xenstore.  The
idea was as much as possible for the toolstack and Xen to work together to
make it transparent to the balloon driver, in part because we expected to
be running legacy drivers.  The Citrix PV drivers don't do anything special
wrt PoD memory.  (Paul, please correct me if I'm wrong.)

WRT timing and xenbus, a couple of things:
* Windows does a scrub of all memory at start-of-day.  Especially on
multiple-vcpu systems, we were unable to start the balloon process early
enough to win the race against the scrubber, so we had to have ways of
"reclaiming" zeroed pages for the PoD pool.  What this means is that it's
not a matter of Windows *touching* memory, but of windows *dirtying* memory
that will lead to a problem.
* So there is a minimum amount of memory Windows needs to be able to make
it to the stage where the balloon driver can run.  When XenServer first
implemented DMC, the team did extensive testing to determine minimum values
above which Windows never crashed or hung, and (as I understand it) baked
those into the xapi toolstack as a "seatbelt" to prevent users from setting
the value too low.

Not sure if that helps in your particular case -- I think 1G was within the
limit, but I could be wrong.  Dave, any comments?

 -George

--089e012292e4da097404d570fff2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Feb 11, 2013 at 12:03 AM, James Harper <span dir=
=3D"ltr">&lt;<a href=3D"mailto:james.harper@bendigoit.com.au" target=3D"_bl=
ank">james.harper@bendigoit.com.au</a>&gt;</span> wrote:<br><div class=3D"g=
mail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A user has pointe=
d out a problem with GPLPV under Xen 4.2 when using PoD. I&#39;m using the =
difference between XENMEM_maximum_reservation and XENMEM_current_reservatio=
n to tell me how much I should balloon down to account for PoD, but when th=
e user has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following=
:<br>

<br>
13005008825593: XenPCI =A0 =A0 XENMEM_maximum_reservation =3D 262400<br>
13005008825593: XenPCI =A0 =A0 XENMEM_current_reservation =3D 262136<br>
13005008825609: XenPCI =A0 =A0 Trying to give 1056 KB (1 MB) to Xen<br>
<br>
What is the correct way to tell how much PoD memory there is under 4.2? Am =
I doing it wrong?<br>
<br>
I balloon down as early as possible (before xenbus starts) to avoid windows=
 going over its limit so I&#39;m hoping I can determine the size of PoD mem=
ory just via hypercalls.<br></blockquote><div><br></div>You shouldn&#39;t h=
ave to know anything specifically about PoD -- you should just look at the =
balloon target for the guest written in xenstore.=A0 The idea was as much a=
s possible for the toolstack and Xen to work together to make it transparen=
t to the balloon driver, in part because we expected to be running legacy d=
rivers.=A0 The Citrix PV drivers don&#39;t do anything special wrt PoD memo=
ry.=A0 (Paul, please correct me if I&#39;m wrong.)<br>
<br></div><div class=3D"gmail_quote">WRT timing and xenbus, a couple of thi=
ngs:<br></div><div class=3D"gmail_quote">* Windows does a scrub of all memo=
ry at start-of-day.=A0 Especially on multiple-vcpu systems, we were unable =
to start the balloon process early enough to win the race against the scrub=
ber, so we had to have ways of &quot;reclaiming&quot; zeroed pages for the =
PoD pool.=A0 What this means is that it&#39;s not a matter of Windows *touc=
hing* memory, but of windows *dirtying* memory that will lead to a problem.=
<br>
</div><div class=3D"gmail_quote">* So there is a minimum amount of memory W=
indows needs to be able to make it to the stage where the balloon driver ca=
n run.=A0 When XenServer first implemented DMC, the team did extensive test=
ing to determine minimum values above which Windows never crashed or hung, =
and (as I understand it) baked those into the xapi toolstack as a &quot;sea=
tbelt&quot; to prevent users from setting the value too low.<br>
<br></div><div class=3D"gmail_quote">Not sure if that helps in your particu=
lar case -- I think 1G was within the limit, but I could be wrong.=A0 Dave,=
 any comments?<br><br></div><div class=3D"gmail_quote">=A0-George<br></div>=
<div class=3D"gmail_quote">
<br></div><div class=3D"gmail_quote"><br></div></div></div>

--089e012292e4da097404d570fff2--


--===============0370826621984662906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0370826621984662906==--


From xen-devel-bounces@lists.xen.org Mon Feb 11 11:15:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:15: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 1U4rLb-0000eb-RS; Mon, 11 Feb 2013 11:14:55 +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 1U4rLZ-0000eW-Fd
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:14:53 +0000
Received: from [85.158.139.211:33726] by server-13.bemta-5.messagelabs.com id
	7B/72-06769-CA2D8115; Mon, 11 Feb 2013 11:14:52 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360581290!18012068!1
X-Originating-IP: [74.125.82.48]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2901 invoked from network); 11 Feb 2013 11:14:51 -0000
Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com)
	(74.125.82.48)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:14:51 -0000
Received: by mail-wg0-f48.google.com with SMTP id 16so4592165wgi.27
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 03:13:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=QV5vWIFPEgRdceWm8uvl0s6lPk2x7Wzwxx0vW5CfHpw=;
	b=GV7vtD+N1cbBQKYfioh1kexT04LEljHLjXSeAzkszyRAf+o8rjExRowU677F9fjM2J
	Oq3XYXf4U/1BoIQtIDqT2wjkGtDAM9PiESi5LgFBFj1VhDk8s9149zUNFp5yFYRpjXVh
	LQXxAHWmA00F0p+2ylPbVTQtpgPwKdGOtsWszgCsRU+SW8wYAUZb2RHrnbzeB4QmfeKa
	AmPXldgYqloNjBpnvIyHBKrSVi8kPEJgOdGSCjC0pkBOD0lSVSHk5vwrbpRSVZlcnKD7
	p8Mn2hg9NstcxbJdelSYsL2+vqJ801BRHHWVWfTr3ahxEj2JLRJQwuzH8P1ogsAAQFT9
	6HvQ==
MIME-Version: 1.0
X-Received: by 10.194.122.199 with SMTP id lu7mr22998833wjb.42.1360581212375; 
	Mon, 11 Feb 2013 03:13:32 -0800 (PST)
Received: by 10.194.136.98 with HTTP; Mon, 11 Feb 2013 03:13:32 -0800 (PST)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
Date: Mon, 11 Feb 2013 11:13:32 +0000
X-Google-Sender-Auth: ALn8v0hcQX5PsJfWdCbBZliom5I
Message-ID: <CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0370826621984662906=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0370826621984662906==
Content-Type: multipart/alternative; boundary=089e012292e4da097404d570fff2

--089e012292e4da097404d570fff2
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 11, 2013 at 12:03 AM, James Harper <
james.harper@bendigoit.com.au> wrote:

> A user has pointed out a problem with GPLPV under Xen 4.2 when using PoD.
> I'm using the difference between XENMEM_maximum_reservation and
> XENMEM_current_reservation to tell me how much I should balloon down to
> account for PoD, but when the user has ballooned down to 1G (from 4Gb or
> 8GB), GPLPV logs the following:
>
> 13005008825593: XenPCI     XENMEM_maximum_reservation = 262400
> 13005008825593: XenPCI     XENMEM_current_reservation = 262136
> 13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
>
> What is the correct way to tell how much PoD memory there is under 4.2? Am
> I doing it wrong?
>
> I balloon down as early as possible (before xenbus starts) to avoid
> windows going over its limit so I'm hoping I can determine the size of PoD
> memory just via hypercalls.
>

You shouldn't have to know anything specifically about PoD -- you should
just look at the balloon target for the guest written in xenstore.  The
idea was as much as possible for the toolstack and Xen to work together to
make it transparent to the balloon driver, in part because we expected to
be running legacy drivers.  The Citrix PV drivers don't do anything special
wrt PoD memory.  (Paul, please correct me if I'm wrong.)

WRT timing and xenbus, a couple of things:
* Windows does a scrub of all memory at start-of-day.  Especially on
multiple-vcpu systems, we were unable to start the balloon process early
enough to win the race against the scrubber, so we had to have ways of
"reclaiming" zeroed pages for the PoD pool.  What this means is that it's
not a matter of Windows *touching* memory, but of windows *dirtying* memory
that will lead to a problem.
* So there is a minimum amount of memory Windows needs to be able to make
it to the stage where the balloon driver can run.  When XenServer first
implemented DMC, the team did extensive testing to determine minimum values
above which Windows never crashed or hung, and (as I understand it) baked
those into the xapi toolstack as a "seatbelt" to prevent users from setting
the value too low.

Not sure if that helps in your particular case -- I think 1G was within the
limit, but I could be wrong.  Dave, any comments?

 -George

--089e012292e4da097404d570fff2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Feb 11, 2013 at 12:03 AM, James Harper <span dir=
=3D"ltr">&lt;<a href=3D"mailto:james.harper@bendigoit.com.au" target=3D"_bl=
ank">james.harper@bendigoit.com.au</a>&gt;</span> wrote:<br><div class=3D"g=
mail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A user has pointe=
d out a problem with GPLPV under Xen 4.2 when using PoD. I&#39;m using the =
difference between XENMEM_maximum_reservation and XENMEM_current_reservatio=
n to tell me how much I should balloon down to account for PoD, but when th=
e user has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following=
:<br>

<br>
13005008825593: XenPCI =A0 =A0 XENMEM_maximum_reservation =3D 262400<br>
13005008825593: XenPCI =A0 =A0 XENMEM_current_reservation =3D 262136<br>
13005008825609: XenPCI =A0 =A0 Trying to give 1056 KB (1 MB) to Xen<br>
<br>
What is the correct way to tell how much PoD memory there is under 4.2? Am =
I doing it wrong?<br>
<br>
I balloon down as early as possible (before xenbus starts) to avoid windows=
 going over its limit so I&#39;m hoping I can determine the size of PoD mem=
ory just via hypercalls.<br></blockquote><div><br></div>You shouldn&#39;t h=
ave to know anything specifically about PoD -- you should just look at the =
balloon target for the guest written in xenstore.=A0 The idea was as much a=
s possible for the toolstack and Xen to work together to make it transparen=
t to the balloon driver, in part because we expected to be running legacy d=
rivers.=A0 The Citrix PV drivers don&#39;t do anything special wrt PoD memo=
ry.=A0 (Paul, please correct me if I&#39;m wrong.)<br>
<br></div><div class=3D"gmail_quote">WRT timing and xenbus, a couple of thi=
ngs:<br></div><div class=3D"gmail_quote">* Windows does a scrub of all memo=
ry at start-of-day.=A0 Especially on multiple-vcpu systems, we were unable =
to start the balloon process early enough to win the race against the scrub=
ber, so we had to have ways of &quot;reclaiming&quot; zeroed pages for the =
PoD pool.=A0 What this means is that it&#39;s not a matter of Windows *touc=
hing* memory, but of windows *dirtying* memory that will lead to a problem.=
<br>
</div><div class=3D"gmail_quote">* So there is a minimum amount of memory W=
indows needs to be able to make it to the stage where the balloon driver ca=
n run.=A0 When XenServer first implemented DMC, the team did extensive test=
ing to determine minimum values above which Windows never crashed or hung, =
and (as I understand it) baked those into the xapi toolstack as a &quot;sea=
tbelt&quot; to prevent users from setting the value too low.<br>
<br></div><div class=3D"gmail_quote">Not sure if that helps in your particu=
lar case -- I think 1G was within the limit, but I could be wrong.=A0 Dave,=
 any comments?<br><br></div><div class=3D"gmail_quote">=A0-George<br></div>=
<div class=3D"gmail_quote">
<br></div><div class=3D"gmail_quote"><br></div></div></div>

--089e012292e4da097404d570fff2--


--===============0370826621984662906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0370826621984662906==--


From xen-devel-bounces@lists.xen.org Mon Feb 11 11:20:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:20: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 1U4rQm-0000vP-9w; Mon, 11 Feb 2013 11: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.Campbell@citrix.com>) id 1U4rQk-0000vC-Lo
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:20:14 +0000
Received: from [85.158.143.35:36227] by server-2.bemta-4.messagelabs.com id
	81/CE-01597-EE3D8115; Mon, 11 Feb 2013 11:20:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360581167!14675834!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32358 invoked from network); 11 Feb 2013 11:12:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:12:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1324623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11: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.297.1;
	Mon, 11 Feb 2013 11:12:47 +0000
Message-ID: <1360581166.29432.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:12:46 +0000
In-Reply-To: <osstest-15452-mainreport@xen.org>
References: <osstest-15452-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Dave
	Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15452: 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 Sat, 2013-02-09 at 07:00 +0000, xen.org wrote:
> flight 15452 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15452/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 15442
>  test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
>  test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
>  test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 15442
>  test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15442
>  test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail REGR. vs. 15442
>  test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install    fail REGR. vs. 15442
>  test-amd64-i386-qemut-win    11 guest-localmigrate.2      fail REGR. vs. 15442
>  test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Of the windows install failures the xl one failed with:
        libxl: error: libxl.c:2101:device_disk_add: failed to get blktap devpath for 0x82ba7b0
        
        libxl: error: libxl_create.c:901:domcreate_launch_dm: unable to add disk devices
        libxl: error: libxl_dm.c:1229:libxl__destroy_device_model: could not find device-model's pid for dom 2
        libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model failed for 2
        Parsing config from /etc/xen/win.guest.osstest.cfg
        
The xend ones failed in every case with:
        [2013-02-09 00:11:38 2336] DEBUG (XendDomainInfo:2499)
        XendDomainInfo.constructDomain
        [2013-02-09 00:11:38 2336] ERROR (XendDomainInfo:488) VM start failed
        Traceback (most recent call last):
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 473, in start
            XendTask.log_progress(0, 30, self._constructDomain)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
            retval = func(*args, **kwds)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2576, in _constructDomain
            self._recreateDom()
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 1730, in _recreateDom
            complete(self.dompath, lambda t: self._recreateDomFunc(t))
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/xenstore/xstransact.py", line 364, in complete
            if t.commit():
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/xenstore/xstransact.py", line 41, in commit
            rc = xshandle().transaction_end(self.transaction, False)
        Error: (2, 'No such file or directory')
        
oxenstored was in use in every case, which does tend to focus the
attention on:

26521:2c0fd406f02c tools/ocaml: oxenstored: Be more paranoid about ring reading
26522:ffd30e7388ad oxenstored: Enforce a maximum message size of 4096 bytes

The other two changes in the range under test are 
        x86: debugging code for testing 16Tb support on smaller memory systems
        xen: enable stubdom on a per arch basis
which seem far less plausible.

The bisector doesn't appear to be having a go at this issue though.

At least one of the xend migration failures also ends with a similar
xshandle().transaction_end stack trace. I don't see anything similar in
any of the xl variants, but that may be down to poor logging plus the
fact that xl cases are the minority and one of them has no logs. This
mostly affects Windows VMs but not exclusively.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:20:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:20: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 1U4rQm-0000vP-9w; Mon, 11 Feb 2013 11: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.Campbell@citrix.com>) id 1U4rQk-0000vC-Lo
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:20:14 +0000
Received: from [85.158.143.35:36227] by server-2.bemta-4.messagelabs.com id
	81/CE-01597-EE3D8115; Mon, 11 Feb 2013 11:20:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360581167!14675834!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32358 invoked from network); 11 Feb 2013 11:12:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:12:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1324623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11: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.297.1;
	Mon, 11 Feb 2013 11:12:47 +0000
Message-ID: <1360581166.29432.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:12:46 +0000
In-Reply-To: <osstest-15452-mainreport@xen.org>
References: <osstest-15452-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Dave
	Scott <Dave.Scott@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 15452: 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 Sat, 2013-02-09 at 07:00 +0000, xen.org wrote:
> flight 15452 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15452/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 15442
>  test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
>  test-amd64-amd64-pv          14 guest-localmigrate/x10    fail REGR. vs. 15442
>  test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 15442
>  test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15442
>  test-amd64-i386-xend-qemut-winxpsp3 11 guest-localmigrate.2 fail REGR. vs. 15442
>  test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install    fail REGR. vs. 15442
>  test-amd64-i386-qemut-win    11 guest-localmigrate.2      fail REGR. vs. 15442
>  test-amd64-amd64-qemut-win    7 windows-install           fail REGR. vs. 15442
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15442
>  test-amd64-amd64-win          7 windows-install           fail REGR. vs. 15442

Of the windows install failures the xl one failed with:
        libxl: error: libxl.c:2101:device_disk_add: failed to get blktap devpath for 0x82ba7b0
        
        libxl: error: libxl_create.c:901:domcreate_launch_dm: unable to add disk devices
        libxl: error: libxl_dm.c:1229:libxl__destroy_device_model: could not find device-model's pid for dom 2
        libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model failed for 2
        Parsing config from /etc/xen/win.guest.osstest.cfg
        
The xend ones failed in every case with:
        [2013-02-09 00:11:38 2336] DEBUG (XendDomainInfo:2499)
        XendDomainInfo.constructDomain
        [2013-02-09 00:11:38 2336] ERROR (XendDomainInfo:488) VM start failed
        Traceback (most recent call last):
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 473, in start
            XendTask.log_progress(0, 30, self._constructDomain)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendTask.py", line 209, in log_progress
            retval = func(*args, **kwds)
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 2576, in _constructDomain
            self._recreateDom()
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py", line 1730, in _recreateDom
            complete(self.dompath, lambda t: self._recreateDomFunc(t))
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/xenstore/xstransact.py", line 364, in complete
            if t.commit():
          File "/usr/local/lib/python2.6/dist-packages/xen/xend/xenstore/xstransact.py", line 41, in commit
            rc = xshandle().transaction_end(self.transaction, False)
        Error: (2, 'No such file or directory')
        
oxenstored was in use in every case, which does tend to focus the
attention on:

26521:2c0fd406f02c tools/ocaml: oxenstored: Be more paranoid about ring reading
26522:ffd30e7388ad oxenstored: Enforce a maximum message size of 4096 bytes

The other two changes in the range under test are 
        x86: debugging code for testing 16Tb support on smaller memory systems
        xen: enable stubdom on a per arch basis
which seem far less plausible.

The bisector doesn't appear to be having a go at this issue though.

At least one of the xend migration failures also ends with a similar
xshandle().transaction_end stack trace. I don't see anything similar in
any of the xl variants, but that may be down to poor logging plus the
fact that xl cases are the minority and one of them has no logs. This
mostly affects Windows VMs but not exclusively.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:31:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rav-0001Sy-1Y; Mon, 11 Feb 2013 11:30:45 +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 1U4rat-0001Sp-UZ
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:30:44 +0000
Received: from [85.158.138.51:45493] by server-4.bemta-3.messagelabs.com id
	8C/8D-12802-366D8115; Mon, 11 Feb 2013 11:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360582241!31870298!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29447 invoked from network); 11 Feb 2013 11:30:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:30:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1325580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:30: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.297.1;
	Mon, 11 Feb 2013 11:30:41 +0000
Message-ID: <1360582239.29432.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:30:39 +0000
In-Reply-To: <1360581166.29432.114.camel@zakaz.uk.xensource.com>
References: <osstest-15452-mainreport@xen.org>
	<1360581166.29432.114.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Dave
	Scott <Dave.Scott@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring. (Was: Re: [xen-unstable test] 15452: 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 Mon, 2013-02-11 at 11:12 +0000, Ian Campbell wrote:
> 
> 26521:2c0fd406f02c tools/ocaml: oxenstored: Be more paranoid about
> ring reading 

I think this change has broken the case where the ring is full.
Specifically we've gone from

       cons = intf->req_cons;
       prod = intf->req_prod;
       ...
       if (prod == cons)
           return 0;

to:

       cons = intf->req_cons;
       prod = intf->req_prod;
       cons = MASK_XENSTORE_IDX(cons);
       prod = MASK_XENSTORE_IDX(prod);
       ...
       if (prod == cons)
           return 0;

IOW if prod == cons + PAGE_SIZE we now make proc == cons before checking
if they are the same...

8<---------------------------------

>From dd72c63ee56e700b00c0ceffa5d8c150e50fa36f Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 11 Feb 2013 11:27:47 +0000
Subject: [PATCH] tools/ocaml: oxenstored: correctly handle a full ring.

Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
caused us to ignore rather than process a completely full ring. Check if
producer and consumer are equal before masking to avoid this, since prod ==
cons + PAGE_SIZE after masking becomes prod == cons.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
index 4888ac5..fdd9983 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
 	cons = *(volatile uint32*)&intf->req_cons;
 	prod = *(volatile uint32*)&intf->req_prod;
 	xen_mb();
-	cons = MASK_XENSTORE_IDX(cons);
-	prod = MASK_XENSTORE_IDX(prod);
 	if (prod == cons)
 		return 0;
+	cons = MASK_XENSTORE_IDX(cons);
+	prod = MASK_XENSTORE_IDX(prod);
 	if (prod > cons)
 		to_read = prod - cons;
 	else
-- 
1.7.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 Feb 11 11:31:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rav-0001Sy-1Y; Mon, 11 Feb 2013 11:30:45 +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 1U4rat-0001Sp-UZ
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:30:44 +0000
Received: from [85.158.138.51:45493] by server-4.bemta-3.messagelabs.com id
	8C/8D-12802-366D8115; Mon, 11 Feb 2013 11:30:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360582241!31870298!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29447 invoked from network); 11 Feb 2013 11:30:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:30:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1325580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:30: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.297.1;
	Mon, 11 Feb 2013 11:30:41 +0000
Message-ID: <1360582239.29432.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:30:39 +0000
In-Reply-To: <1360581166.29432.114.camel@zakaz.uk.xensource.com>
References: <osstest-15452-mainreport@xen.org>
	<1360581166.29432.114.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Dave
	Scott <Dave.Scott@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring. (Was: Re: [xen-unstable test] 15452: 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 Mon, 2013-02-11 at 11:12 +0000, Ian Campbell wrote:
> 
> 26521:2c0fd406f02c tools/ocaml: oxenstored: Be more paranoid about
> ring reading 

I think this change has broken the case where the ring is full.
Specifically we've gone from

       cons = intf->req_cons;
       prod = intf->req_prod;
       ...
       if (prod == cons)
           return 0;

to:

       cons = intf->req_cons;
       prod = intf->req_prod;
       cons = MASK_XENSTORE_IDX(cons);
       prod = MASK_XENSTORE_IDX(prod);
       ...
       if (prod == cons)
           return 0;

IOW if prod == cons + PAGE_SIZE we now make proc == cons before checking
if they are the same...

8<---------------------------------

>From dd72c63ee56e700b00c0ceffa5d8c150e50fa36f Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 11 Feb 2013 11:27:47 +0000
Subject: [PATCH] tools/ocaml: oxenstored: correctly handle a full ring.

Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
caused us to ignore rather than process a completely full ring. Check if
producer and consumer are equal before masking to avoid this, since prod ==
cons + PAGE_SIZE after masking becomes prod == cons.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
index 4888ac5..fdd9983 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
 	cons = *(volatile uint32*)&intf->req_cons;
 	prod = *(volatile uint32*)&intf->req_prod;
 	xen_mb();
-	cons = MASK_XENSTORE_IDX(cons);
-	prod = MASK_XENSTORE_IDX(prod);
 	if (prod == cons)
 		return 0;
+	cons = MASK_XENSTORE_IDX(cons);
+	prod = MASK_XENSTORE_IDX(prod);
 	if (prod > cons)
 		to_read = prod - cons;
 	else
-- 
1.7.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 Feb 11 11:39:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rjV-0001l7-45; Mon, 11 Feb 2013 11:39:37 +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 1U4rjU-0001l2-2p
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:39:36 +0000
Received: from [85.158.143.35:4565] by server-2.bemta-4.messagelabs.com id
	1A/10-01597-778D8115; Mon, 11 Feb 2013 11:39:35 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360582771!13402356!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29368 invoked from network); 11 Feb 2013 11:39:34 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Feb 2013 11:39:34 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U4rjI-0003ul-A5; Mon, 11 Feb 2013 22:39:24 +1100
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 id
	14.01.0438.000; Mon, 11 Feb 2013 22:39:23 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgAAAdQUAABfjY9A=
Date: Mon, 11 Feb 2013 11:39:21 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
In-Reply-To: <CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19628.006
x-tm-as-result: No--47.997400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 11, 2013 at 12:03 AM, James Harper
> <james.harper@bendigoit.com.au> wrote:
> 
> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
> using PoD. I'm using the difference between
> XENMEM_maximum_reservation and XENMEM_current_reservation to tell
> me how much I should balloon down to account for PoD, but when the user
> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
> 
> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
> 262400
> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
> 
> 	What is the correct way to tell how much PoD memory there is under
> 4.2? Am I doing it wrong?
> 
> 	I balloon down as early as possible (before xenbus starts) to avoid
> windows going over its limit so I'm hoping I can determine the size of PoD
> memory just via hypercalls.
> 
> 
> 
> You shouldn't have to know anything specifically about PoD -- you should just
> look at the balloon target for the guest written in xenstore.  The idea was as
> much as possible for the toolstack and Xen to work together to make it
> transparent to the balloon driver, in part because we expected to be running
> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
> memory.  (Paul, please correct me if I'm wrong.)

So I should just balloon down to the current_reservation figure right?

> WRT timing and xenbus, a couple of things:
> 
> * Windows does a scrub of all memory at start-of-day.  Especially on multiple-
> vcpu systems, we were unable to start the balloon process early enough to
> win the race against the scrubber, so we had to have ways of "reclaiming"
> zeroed pages for the PoD pool.  What this means is that it's not a matter of
> Windows *touching* memory, but of windows *dirtying* memory that will
> lead to a problem.
> 
> * So there is a minimum amount of memory Windows needs to be able to
> make it to the stage where the balloon driver can run.  When XenServer first
> implemented DMC, the team did extensive testing to determine minimum
> values above which Windows never crashed or hung, and (as I understand it)
> baked those into the xapi toolstack as a "seatbelt" to prevent users from
> setting the value too low.
> 
> Not sure if that helps in your particular case -- I think 1G was within the limit,
> but I could be wrong.  Dave, any comments?
> 

I think I could go from 4GB down to 128MB reliably without crashing, although the resulting OS wasn't particularly usable :)

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:39:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rjV-0001l7-45; Mon, 11 Feb 2013 11:39:37 +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 1U4rjU-0001l2-2p
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:39:36 +0000
Received: from [85.158.143.35:4565] by server-2.bemta-4.messagelabs.com id
	1A/10-01597-778D8115; Mon, 11 Feb 2013 11:39:35 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360582771!13402356!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29368 invoked from network); 11 Feb 2013 11:39:34 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Feb 2013 11:39:34 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U4rjI-0003ul-A5; Mon, 11 Feb 2013 22:39:24 +1100
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 id
	14.01.0438.000; Mon, 11 Feb 2013 22:39:23 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgAAAdQUAABfjY9A=
Date: Mon, 11 Feb 2013 11:39:21 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
In-Reply-To: <CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19628.006
x-tm-as-result: No--47.997400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 11, 2013 at 12:03 AM, James Harper
> <james.harper@bendigoit.com.au> wrote:
> 
> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
> using PoD. I'm using the difference between
> XENMEM_maximum_reservation and XENMEM_current_reservation to tell
> me how much I should balloon down to account for PoD, but when the user
> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
> 
> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
> 262400
> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
> 
> 	What is the correct way to tell how much PoD memory there is under
> 4.2? Am I doing it wrong?
> 
> 	I balloon down as early as possible (before xenbus starts) to avoid
> windows going over its limit so I'm hoping I can determine the size of PoD
> memory just via hypercalls.
> 
> 
> 
> You shouldn't have to know anything specifically about PoD -- you should just
> look at the balloon target for the guest written in xenstore.  The idea was as
> much as possible for the toolstack and Xen to work together to make it
> transparent to the balloon driver, in part because we expected to be running
> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
> memory.  (Paul, please correct me if I'm wrong.)

So I should just balloon down to the current_reservation figure right?

> WRT timing and xenbus, a couple of things:
> 
> * Windows does a scrub of all memory at start-of-day.  Especially on multiple-
> vcpu systems, we were unable to start the balloon process early enough to
> win the race against the scrubber, so we had to have ways of "reclaiming"
> zeroed pages for the PoD pool.  What this means is that it's not a matter of
> Windows *touching* memory, but of windows *dirtying* memory that will
> lead to a problem.
> 
> * So there is a minimum amount of memory Windows needs to be able to
> make it to the stage where the balloon driver can run.  When XenServer first
> implemented DMC, the team did extensive testing to determine minimum
> values above which Windows never crashed or hung, and (as I understand it)
> baked those into the xapi toolstack as a "seatbelt" to prevent users from
> setting the value too low.
> 
> Not sure if that helps in your particular case -- I think 1G was within the limit,
> but I could be wrong.  Dave, any comments?
> 

I think I could go from 4GB down to 128MB reliably without crashing, although the resulting OS wasn't particularly usable :)

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:45:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rpB-0001vg-UA; Mon, 11 Feb 2013 11:45:29 +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 1U4rpA-0001vW-01
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:45:28 +0000
Received: from [85.158.143.35:19246] by server-1.bemta-4.messagelabs.com id
	9D/93-08839-7D9D8115; Mon, 11 Feb 2013 11:45:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360583104!4212984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27589 invoked from network); 11 Feb 2013 11:45:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:45:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="6988184"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 11:45:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 06:45:03 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U4rol-0004I5-4J;
	Mon, 11 Feb 2013 11:45:03 +0000
Message-ID: <1360583103.16636.29.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Mon, 11 Feb 2013 11:45:03 +0000
In-Reply-To: <51181924.4050500@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Sun, 2013-02-10 at 22:03 +0000, Christopher S. Aker wrote:
> And another this afternoon on a different machine:
> 
> BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8

OK, so the guest is faulting at different offset now. It is very likely
that there is OOM / race condition in other places. And judging from
your two emails, I presume this bug can be reproduce steadily.

> IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
> CPU 5
> Pid: 1550, comm: netback/5 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
> X8DT6/X8DT6
> RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> RSP: e02b:ffff8800836e7b58  EFLAGS: 00010006
> RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 000000000045de5d
> RDX: 0000000000000001 RSI: 0000000000000211 RDI: 00000000000008b8
> RBP: ffff8800836e7b78 R08: 0000000000000068 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
> R13: 0000000000000200 R14: 0000000000000400 R15: 000000000045de5d
> FS:  00007f474a465700(0000) GS:ffff880100740000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/5 (pid: 1550, threadinfo ffff8800836e6000, task 
> ffff880084510000)
> Stack:
>   0000000000000211 00000000000008b8 ffff8800771e5700 ffff8800771e57d8
>   ffff8800836e7b98 ffffffff817605da 0000000000000000 00000000000008b8
>   ffff8800836e7bd8 ffffffff8154446f ffff8800771e5000 0000000000000000
> Call Trace:
>   [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
>   [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
>   [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
>   [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
>   [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
>   [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
>   [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
>   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
>   [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
>   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
>   [<ffffffff81071a06>] kthread+0xc6/0xd0
>   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
>   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
>   [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
[snip]
> 
> We're not so good at this, but it looks like xl->lock deref is what we 
> hit?  The lock was gone?
> 

A quick check on the xen_spinlock struct, its offset should not be
0x8b8. Reading the backtrace suggests that it is the netbk struct is
gone.

Do you manipulate the number of vcpus Dom0 has after it's up?


Wei.

> -Chris
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 11 11:45:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rpB-0001vg-UA; Mon, 11 Feb 2013 11:45:29 +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 1U4rpA-0001vW-01
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:45:28 +0000
Received: from [85.158.143.35:19246] by server-1.bemta-4.messagelabs.com id
	9D/93-08839-7D9D8115; Mon, 11 Feb 2013 11:45:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360583104!4212984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27589 invoked from network); 11 Feb 2013 11:45:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:45:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="6988184"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 11:45:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 06:45:03 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U4rol-0004I5-4J;
	Mon, 11 Feb 2013 11:45:03 +0000
Message-ID: <1360583103.16636.29.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Mon, 11 Feb 2013 11:45:03 +0000
In-Reply-To: <51181924.4050500@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Sun, 2013-02-10 at 22:03 +0000, Christopher S. Aker wrote:
> And another this afternoon on a different machine:
> 
> BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8

OK, so the guest is faulting at different offset now. It is very likely
that there is OOM / race condition in other places. And judging from
your two emails, I presume this bug can be reproduce steadily.

> IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
> CPU 5
> Pid: 1550, comm: netback/5 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
> X8DT6/X8DT6
> RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> RSP: e02b:ffff8800836e7b58  EFLAGS: 00010006
> RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 000000000045de5d
> RDX: 0000000000000001 RSI: 0000000000000211 RDI: 00000000000008b8
> RBP: ffff8800836e7b78 R08: 0000000000000068 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
> R13: 0000000000000200 R14: 0000000000000400 R15: 000000000045de5d
> FS:  00007f474a465700(0000) GS:ffff880100740000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process netback/5 (pid: 1550, threadinfo ffff8800836e6000, task 
> ffff880084510000)
> Stack:
>   0000000000000211 00000000000008b8 ffff8800771e5700 ffff8800771e57d8
>   ffff8800836e7b98 ffffffff817605da 0000000000000000 00000000000008b8
>   ffff8800836e7bd8 ffffffff8154446f ffff8800771e5000 0000000000000000
> Call Trace:
>   [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
>   [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
>   [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
>   [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
>   [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
>   [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
>   [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
>   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
>   [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
>   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
>   [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
>   [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
>   [<ffffffff81071a06>] kthread+0xc6/0xd0
>   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
>   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
>   [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
[snip]
> 
> We're not so good at this, but it looks like xl->lock deref is what we 
> hit?  The lock was gone?
> 

A quick check on the xen_spinlock struct, its offset should not be
0x8b8. Reading the backtrace suggests that it is the netbk struct is
gone.

Do you manipulate the number of vcpus Dom0 has after it's up?


Wei.

> -Chris
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 11 11:45:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rpC-0001vx-FG; Mon, 11 Feb 2013 11:45: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 1U4rpB-0001vb-HH
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:45:29 +0000
Received: from [85.158.139.83:50448] by server-4.bemta-5.messagelabs.com id
	AD/9E-29496-8D9D8115; Mon, 11 Feb 2013 11:45:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360583123!29354550!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 11 Feb 2013 11:45:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:45:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:45: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.297.1;
	Mon, 11 Feb 2013 11:45:23 +0000
Message-ID: <1360583122.29432.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Mon, 11 Feb 2013 11:45:22 +0000
In-Reply-To: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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 Sat, 2013-02-09 at 03:29 +0000, Shakeel Butt wrote:
> The end of if is at the wrong place.

Please can you describe what goes wrong with it where it is?

> diff -r 6c1b12c884b4 configure

I'm afraid this is a generate file, you need to instead edit
configure.ac and/or m4/*.m4 (probably subsystem.m4) and
rerun ./autogen.sh.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:45:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4rpC-0001vx-FG; Mon, 11 Feb 2013 11:45: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 1U4rpB-0001vb-HH
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:45:29 +0000
Received: from [85.158.139.83:50448] by server-4.bemta-5.messagelabs.com id
	AD/9E-29496-8D9D8115; Mon, 11 Feb 2013 11:45:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360583123!29354550!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10704 invoked from network); 11 Feb 2013 11:45:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:45:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326158"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:45: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.297.1;
	Mon, 11 Feb 2013 11:45:23 +0000
Message-ID: <1360583122.29432.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Mon, 11 Feb 2013 11:45:22 +0000
In-Reply-To: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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 Sat, 2013-02-09 at 03:29 +0000, Shakeel Butt wrote:
> The end of if is at the wrong place.

Please can you describe what goes wrong with it where it is?

> diff -r 6c1b12c884b4 configure

I'm afraid this is a generate file, you need to instead edit
configure.ac and/or m4/*.m4 (probably subsystem.m4) and
rerun ./autogen.sh.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:46:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:46: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 1U4rqH-000250-Um; Mon, 11 Feb 2013 11:46: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 1U4rqG-00024l-Pz
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:46:36 +0000
Received: from [85.158.143.99:14072] by server-1.bemta-4.messagelabs.com id
	E7/15-08839-A1AD8115; Mon, 11 Feb 2013 11:46:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360583183!24122346!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23038 invoked from network); 11 Feb 2013 11:46:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:46:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11: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.297.1;
	Mon, 11 Feb 2013 11:46:23 +0000
Message-ID: <1360583182.29432.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 11:46:22 +0000
In-Reply-To: <51153A7902000078000BD48B@nat28.tlf.novell.com>
References: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
	<51153A7902000078000BD48B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"sherry.hurwitz@amd.com" <sherry.hurwitz@amd.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 16:48 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> 
> > ----- JBeulich@suse.com wrote:
> > 
> >> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> > A regression was reported on a class of broken firmware that c/s
> >> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
> >> 
> >> After some more thought on this and the comments we got
> >> regarding disabling the IOMMU in this situation altogether making
> >> things worse instead of better, I came to the conclusion that we
> >> can actually restrict the action in affected cases to just disabling
> >> interrupt remapping. That doesn't make the situation worse than
> >> prior to the XSA-36 fixes (where interrupt remapping didn't really
> >> protect domains from one another), but allows at least DMA
> >> isolation to still be utilized. Patch 3/2 below/attached.
> > 
> > But now users who don't examine log messages may not realize 
> > that interupt remapping is disabled and therefore the system can be
> > affected by XSA-36.
> 
> Yes. We need to balance these against one another - I see pros
> and cons in both (and I don't mind dropping this additional patch
> if we collectively come to the conclusion that the way it is now -
> with the one earlier fix - is the better state). So I'm really
> interested in others' opinions.

Given the infrastructure currently available for dealing with these
things in a more fine-grained/less heavy-handed manner (i.e. not much)
and in the context of security advisories (where obviousness of the
patch is a very useful property and where we are effectively
highlighting the issue to the world) I think it is reasonable to be
fairly aggressive in our handling of systems which don't provide the
necessary security properties.

Most of these sorts of issues naturally only arise as part of a security
vulnerability but if someone wanted to implement more fine grained
control after the fact that would also seem reasonable.

If we had pre-existing better infrastructure for determining controlling
things at runtime, including informing the user and allowing for
overrides, which could be tweaked with one or two lines in a security
fix then it would seem reasonable to use them up front.

Somebody would need to figure out what that actually means and implement
it as part of the normal development process, since we obviously don't
want to do it next time we are under the cosh of an impending security
advisory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:46:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:46: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 1U4rqH-000250-Um; Mon, 11 Feb 2013 11:46: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 1U4rqG-00024l-Pz
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:46:36 +0000
Received: from [85.158.143.99:14072] by server-1.bemta-4.messagelabs.com id
	E7/15-08839-A1AD8115; Mon, 11 Feb 2013 11:46:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360583183!24122346!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23038 invoked from network); 11 Feb 2013 11:46:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:46:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11: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.297.1;
	Mon, 11 Feb 2013 11:46:23 +0000
Message-ID: <1360583182.29432.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 11:46:22 +0000
In-Reply-To: <51153A7902000078000BD48B@nat28.tlf.novell.com>
References: <4d5451fc-d8f6-4d85-bb10-e39fb8931b13@default>
	<51153A7902000078000BD48B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"sherry.hurwitz@amd.com" <sherry.hurwitz@amd.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 16:48 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> 
> > ----- JBeulich@suse.com wrote:
> > 
> >> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> > A regression was reported on a class of broken firmware that c/s
> >> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
> >> 
> >> After some more thought on this and the comments we got
> >> regarding disabling the IOMMU in this situation altogether making
> >> things worse instead of better, I came to the conclusion that we
> >> can actually restrict the action in affected cases to just disabling
> >> interrupt remapping. That doesn't make the situation worse than
> >> prior to the XSA-36 fixes (where interrupt remapping didn't really
> >> protect domains from one another), but allows at least DMA
> >> isolation to still be utilized. Patch 3/2 below/attached.
> > 
> > But now users who don't examine log messages may not realize 
> > that interupt remapping is disabled and therefore the system can be
> > affected by XSA-36.
> 
> Yes. We need to balance these against one another - I see pros
> and cons in both (and I don't mind dropping this additional patch
> if we collectively come to the conclusion that the way it is now -
> with the one earlier fix - is the better state). So I'm really
> interested in others' opinions.

Given the infrastructure currently available for dealing with these
things in a more fine-grained/less heavy-handed manner (i.e. not much)
and in the context of security advisories (where obviousness of the
patch is a very useful property and where we are effectively
highlighting the issue to the world) I think it is reasonable to be
fairly aggressive in our handling of systems which don't provide the
necessary security properties.

Most of these sorts of issues naturally only arise as part of a security
vulnerability but if someone wanted to implement more fine grained
control after the fact that would also seem reasonable.

If we had pre-existing better infrastructure for determining controlling
things at runtime, including informing the user and allowing for
overrides, which could be tweaked with one or two lines in a security
fix then it would seem reasonable to use them up front.

Somebody would need to figure out what that actually means and implement
it as part of the normal development process, since we obviously don't
want to do it next time we are under the cosh of an impending security
advisory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:47:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:47: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 1U4rrC-0002Bt-Dt; Mon, 11 Feb 2013 11:47: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 1U4rrA-0002BW-7B
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:47:32 +0000
Received: from [85.158.138.51:52530] by server-8.bemta-3.messagelabs.com id
	A8/74-25687-35AD8115; Mon, 11 Feb 2013 11:47:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360583166!21502474!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31857 invoked from network); 11 Feb 2013 11:47:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:47:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:46: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.297.1; Mon, 11 Feb 2013 11:46:06 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U4rpl-000824-CG;
	Mon, 11 Feb 2013 11:46:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U4rpl-0005yA-BX;
	Mon, 11 Feb 2013 11:46:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:46:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test guest-localmigrate/x10

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad


  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.guest-localmigrate--x10.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 15817 fail [host=leaf-beetle] / 16006 ok.
Failure / basis pass flights: 15817 / 16006
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#2a1354d655d816feaad7dbdb8364f40a208439c1-2a1354d655d816feaad7dbdb8364f40a208439c1 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 http://xenbits.xen.org/hg/staging/xen-unstable.hg#ffd30e7388ad-fd997a96d448
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 114 nodes in revision graph
Searching for test results:
 15452 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15643 pass irrelevant
 15647 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15651 pass irrelevant
 15656 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15662 pass irrelevant
 15659 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15817 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15815 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15820 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 15997 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16000 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16003 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16006 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16009 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
Searching for interesting versions
 Result found: flight 15820 (pass), for basis pass
 Result found: flight 15997 (fail), for basis failure
 Repro found: flight 16000 (pass), for basis pass
 Repro found: flight 16003 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
No revisions left to test, checking graph state.
 Result found: flight 15820 (pass), for last pass
 Result found: flight 15997 (fail), for first failure
 Repro found: flight 16000 (pass), for last pass
 Repro found: flight 16003 (fail), for first failure
 Repro found: flight 16006 (pass), for last pass
 Repro found: flight 16009 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.guest-localmigrate--x10.{dot,ps,png,html}.
----------------------------------------
16009: tolerable ALL FAIL

flight 16009 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16009/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10  fail baseline untested


jobs:
 test-amd64-i386-xl-credit2                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:47:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:47: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 1U4rrC-0002Bt-Dt; Mon, 11 Feb 2013 11:47: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 1U4rrA-0002BW-7B
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:47:32 +0000
Received: from [85.158.138.51:52530] by server-8.bemta-3.messagelabs.com id
	A8/74-25687-35AD8115; Mon, 11 Feb 2013 11:47:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360583166!21502474!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31857 invoked from network); 11 Feb 2013 11:47:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:47:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:46: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.297.1; Mon, 11 Feb 2013 11:46:06 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U4rpl-000824-CG;
	Mon, 11 Feb 2013 11:46:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U4rpl-0005yA-BX;
	Mon, 11 Feb 2013 11:46:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:46:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test guest-localmigrate/x10

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad


  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.guest-localmigrate--x10.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 15817 fail [host=leaf-beetle] / 16006 ok.
Failure / basis pass flights: 15817 / 16006
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#2a1354d655d816feaad7dbdb8364f40a208439c1-2a1354d655d816feaad7dbdb8364f40a208439c1 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 http://xenbits.xen.org/hg/staging/xen-unstable.hg#ffd30e7388ad-fd997a96d448
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 114 nodes in revision graph
Searching for test results:
 15452 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15643 pass irrelevant
 15647 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15651 pass irrelevant
 15656 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15662 pass irrelevant
 15659 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15817 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15815 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15820 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 15997 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16000 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16003 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16006 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16009 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
Searching for interesting versions
 Result found: flight 15820 (pass), for basis pass
 Result found: flight 15997 (fail), for basis failure
 Repro found: flight 16000 (pass), for basis pass
 Repro found: flight 16003 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
No revisions left to test, checking graph state.
 Result found: flight 15820 (pass), for last pass
 Result found: flight 15997 (fail), for first failure
 Repro found: flight 16000 (pass), for last pass
 Repro found: flight 16003 (fail), for first failure
 Repro found: flight 16006 (pass), for last pass
 Repro found: flight 16009 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.guest-localmigrate--x10.{dot,ps,png,html}.
----------------------------------------
16009: tolerable ALL FAIL

flight 16009 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16009/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10  fail baseline untested


jobs:
 test-amd64-i386-xl-credit2                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:48:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:48: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 1U4rrR-0002ES-R3; Mon, 11 Feb 2013 11:47:49 +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 1U4rrQ-0002E6-Nf
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:47:48 +0000
Received: from [85.158.139.83:31558] by server-15.bemta-5.messagelabs.com id
	38/F2-18914-46AD8115; Mon, 11 Feb 2013 11:47:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360583265!30893908!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17820 invoked from network); 11 Feb 2013 11:47:47 -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;
	11 Feb 2013 11:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="6639198"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 11:47:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 06:47:31 -0500
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 1U4rr8-0004K2-LI;
	Mon, 11 Feb 2013 11:47:30 +0000
Message-ID: <5118D893.7020102@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:40:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/02/13 11:39, James Harper wrote:
>> On Mon, Feb 11, 2013 at 12:03 AM, James Harper
>> <james.harper@bendigoit.com.au> wrote:
>>
>> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
>> using PoD. I'm using the difference between
>> XENMEM_maximum_reservation and XENMEM_current_reservation to tell
>> me how much I should balloon down to account for PoD, but when the user
>> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
>>
>> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
>> 262400
>> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
>> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
>>
>> 	What is the correct way to tell how much PoD memory there is under
>> 4.2? Am I doing it wrong?
>>
>> 	I balloon down as early as possible (before xenbus starts) to avoid
>> windows going over its limit so I'm hoping I can determine the size of PoD
>> memory just via hypercalls.
>>
>>
>>
>> You shouldn't have to know anything specifically about PoD -- you should just
>> look at the balloon target for the guest written in xenstore.  The idea was as
>> much as possible for the toolstack and Xen to work together to make it
>> transparent to the balloon driver, in part because we expected to be running
>> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
>> memory.  (Paul, please correct me if I'm wrong.)
> So I should just balloon down to the current_reservation figure right?

...I don't think so -- it looks like you're getting that from a 
hypercall, not from xenstore.  You want the normal balloon target value 
from xenstore.  (But I might be confused -- I'm not super familiar with 
the technical details of the ballooning codepath, just the overall 
principles.)

>> WRT timing and xenbus, a couple of things:
>>
>> * Windows does a scrub of all memory at start-of-day.  Especially on multiple-
>> vcpu systems, we were unable to start the balloon process early enough to
>> win the race against the scrubber, so we had to have ways of "reclaiming"
>> zeroed pages for the PoD pool.  What this means is that it's not a matter of
>> Windows *touching* memory, but of windows *dirtying* memory that will
>> lead to a problem.
>>
>> * So there is a minimum amount of memory Windows needs to be able to
>> make it to the stage where the balloon driver can run.  When XenServer first
>> implemented DMC, the team did extensive testing to determine minimum
>> values above which Windows never crashed or hung, and (as I understand it)
>> baked those into the xapi toolstack as a "seatbelt" to prevent users from
>> setting the value too low.
>>
>> Not sure if that helps in your particular case -- I think 1G was within the limit,
>> but I could be wrong.  Dave, any comments?
>>
> I think I could go from 4GB down to 128MB reliably without crashing, although the resulting OS wasn't particularly usable :)

I think what we found was that Windows required a certain amount of 
memory to *boot*.  If you gave it less than that, then either one of two 
things would happen:
* The processes dirtying RAM beat the balloon driver, and the guest 
crashed with a PoD-cache-empty error
* The balloon driver beat the processes dirtying ram, and the guest 
hung; presumably some service somewhere waiting for some memory to "free 
up".

In theory after boot you could reduce the memory below that threshold.  
But then what would you do if you needed to reboot the guest?  You'd 
have to go grab the memory from somewhere else, which is the situation 
we were trying to avoid with having PoD in the first place.  So the guy 
architecting DMC just made it a hard floor (again, as I understand 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 Feb 11 11:48:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11:48: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 1U4rrR-0002ES-R3; Mon, 11 Feb 2013 11:47:49 +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 1U4rrQ-0002E6-Nf
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 11:47:48 +0000
Received: from [85.158.139.83:31558] by server-15.bemta-5.messagelabs.com id
	38/F2-18914-46AD8115; Mon, 11 Feb 2013 11:47:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360583265!30893908!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17820 invoked from network); 11 Feb 2013 11:47:47 -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;
	11 Feb 2013 11:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="6639198"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 11:47:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 06:47:31 -0500
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 1U4rr8-0004K2-LI;
	Mon, 11 Feb 2013 11:47:30 +0000
Message-ID: <5118D893.7020102@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:40:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/02/13 11:39, James Harper wrote:
>> On Mon, Feb 11, 2013 at 12:03 AM, James Harper
>> <james.harper@bendigoit.com.au> wrote:
>>
>> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
>> using PoD. I'm using the difference between
>> XENMEM_maximum_reservation and XENMEM_current_reservation to tell
>> me how much I should balloon down to account for PoD, but when the user
>> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
>>
>> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
>> 262400
>> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
>> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
>>
>> 	What is the correct way to tell how much PoD memory there is under
>> 4.2? Am I doing it wrong?
>>
>> 	I balloon down as early as possible (before xenbus starts) to avoid
>> windows going over its limit so I'm hoping I can determine the size of PoD
>> memory just via hypercalls.
>>
>>
>>
>> You shouldn't have to know anything specifically about PoD -- you should just
>> look at the balloon target for the guest written in xenstore.  The idea was as
>> much as possible for the toolstack and Xen to work together to make it
>> transparent to the balloon driver, in part because we expected to be running
>> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
>> memory.  (Paul, please correct me if I'm wrong.)
> So I should just balloon down to the current_reservation figure right?

...I don't think so -- it looks like you're getting that from a 
hypercall, not from xenstore.  You want the normal balloon target value 
from xenstore.  (But I might be confused -- I'm not super familiar with 
the technical details of the ballooning codepath, just the overall 
principles.)

>> WRT timing and xenbus, a couple of things:
>>
>> * Windows does a scrub of all memory at start-of-day.  Especially on multiple-
>> vcpu systems, we were unable to start the balloon process early enough to
>> win the race against the scrubber, so we had to have ways of "reclaiming"
>> zeroed pages for the PoD pool.  What this means is that it's not a matter of
>> Windows *touching* memory, but of windows *dirtying* memory that will
>> lead to a problem.
>>
>> * So there is a minimum amount of memory Windows needs to be able to
>> make it to the stage where the balloon driver can run.  When XenServer first
>> implemented DMC, the team did extensive testing to determine minimum
>> values above which Windows never crashed or hung, and (as I understand it)
>> baked those into the xapi toolstack as a "seatbelt" to prevent users from
>> setting the value too low.
>>
>> Not sure if that helps in your particular case -- I think 1G was within the limit,
>> but I could be wrong.  Dave, any comments?
>>
> I think I could go from 4GB down to 128MB reliably without crashing, although the resulting OS wasn't particularly usable :)

I think what we found was that Windows required a certain amount of 
memory to *boot*.  If you gave it less than that, then either one of two 
things would happen:
* The processes dirtying RAM beat the balloon driver, and the guest 
crashed with a PoD-cache-empty error
* The balloon driver beat the processes dirtying ram, and the guest 
hung; presumably some service somewhere waiting for some memory to "free 
up".

In theory after boot you could reduce the memory below that threshold.  
But then what would you do if you needed to reboot the guest?  You'd 
have to go grab the memory from somewhere else, which is the situation 
we were trying to avoid with having PoD in the first place.  So the guy 
architecting DMC just made it a hard floor (again, as I understand 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 Feb 11 11:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4ryi-0002gr-OF; Mon, 11 Feb 2013 11:55: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 1U4ryh-0002gk-9l
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:55:19 +0000
Received: from [193.109.254.147:38087] by server-5.bemta-14.messagelabs.com id
	3C/A6-21539-62CD8115; Mon, 11 Feb 2013 11:55:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360583716!8515918!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2188 invoked from network); 11 Feb 2013 11:55:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:55:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:55: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.297.1;
	Mon, 11 Feb 2013 11:55:17 +0000
Message-ID: <1360583715.29432.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:55:15 +0000
In-Reply-To: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
References: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-11 at 11:46 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-xl-credit2
> test guest-localmigrate/x10
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
>   Bug introduced:  fd997a96d448
>   Bug not present: ffd30e7388ad
> 
> 
>   changeset:   26523:fd997a96d448
>   tag:         tip
>   user:        Jan Beulich <jbeulich@suse.com>
>   date:        Fri Feb 08 11:06:04 2013 +0100
>       
>       x86: debugging code for testing 16Tb support on smaller memory systems
>       
>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>       Acked-by: Keir Fraser <keir@xen.org>

This seems less likely than the oxenstored issue I mentioned in the
"[xen-unstable test] 15452: regressions - FAIL" thread.

The xenstored things seems likely to be a bit intermittent, which
perhaps has confused the bisector.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 11:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 11: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 1U4ryi-0002gr-OF; Mon, 11 Feb 2013 11:55: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 1U4ryh-0002gk-9l
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 11:55:19 +0000
Received: from [193.109.254.147:38087] by server-5.bemta-14.messagelabs.com id
	3C/A6-21539-62CD8115; Mon, 11 Feb 2013 11:55:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360583716!8515918!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2188 invoked from network); 11 Feb 2013 11:55:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 11:55:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,641,1355097600"; 
   d="scan'208";a="1326490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 11:55: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.297.1;
	Mon, 11 Feb 2013 11:55:17 +0000
Message-ID: <1360583715.29432.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 11:55:15 +0000
In-Reply-To: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
References: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-11 at 11:46 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-xl-credit2
> test guest-localmigrate/x10
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
>   Bug introduced:  fd997a96d448
>   Bug not present: ffd30e7388ad
> 
> 
>   changeset:   26523:fd997a96d448
>   tag:         tip
>   user:        Jan Beulich <jbeulich@suse.com>
>   date:        Fri Feb 08 11:06:04 2013 +0100
>       
>       x86: debugging code for testing 16Tb support on smaller memory systems
>       
>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>       Acked-by: Keir Fraser <keir@xen.org>

This seems less likely than the oxenstored issue I mentioned in the
"[xen-unstable test] 15452: regressions - FAIL" thread.

The xenstored things seems likely to be a bit intermittent, which
perhaps has confused the bisector.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 13:12:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tB6-0003LK-Ku; Mon, 11 Feb 2013 13:12: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 1U4tB5-0003LF-2H
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:11 +0000
Received: from [85.158.143.99:20438] by server-2.bemta-4.messagelabs.com id
	E5/E2-01597-A2EE8115; Mon, 11 Feb 2013 13:12:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360588328!25357437!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8957 invoked from network); 11 Feb 2013 13:12:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:12:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1329495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 13:12: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.297.1;
	Mon, 11 Feb 2013 13:12:07 +0000
Message-ID: <1360588326.20449.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 13:12:06 +0000
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 13:04 +0000, Jan Beulich wrote:
> A regression was reported on a class of broken firmware that c/s
> 26517:601139e2b0db didn't consider, leading to a boot time crash.

Should we release an update to XSA-36 when these have gone in?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 13:12:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tB6-0003LK-Ku; Mon, 11 Feb 2013 13:12: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 1U4tB5-0003LF-2H
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:11 +0000
Received: from [85.158.143.99:20438] by server-2.bemta-4.messagelabs.com id
	E5/E2-01597-A2EE8115; Mon, 11 Feb 2013 13:12:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360588328!25357437!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8957 invoked from network); 11 Feb 2013 13:12:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:12:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1329495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 13:12: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.297.1;
	Mon, 11 Feb 2013 13:12:07 +0000
Message-ID: <1360588326.20449.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 11 Feb 2013 13:12:06 +0000
In-Reply-To: <511262E302000078000BC738@nat28.tlf.novell.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-06 at 13:04 +0000, Jan Beulich wrote:
> A regression was reported on a class of broken firmware that c/s
> 26517:601139e2b0db didn't consider, leading to a boot time crash.

Should we release an update to XSA-36 when these have gone in?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 13:13:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13:13: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 1U4tBY-0003MQ-2A; Mon, 11 Feb 2013 13:12: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 1U4tBW-0003MF-Jd
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:38 +0000
Received: from [85.158.139.211:59603] by server-6.bemta-5.messagelabs.com id
	50/05-01489-54EE8115; Mon, 11 Feb 2013 13:12:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360588357!20884893!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3658 invoked from network); 11 Feb 2013 13:12:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:12:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1329516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 13:12: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.297.1;
	Mon, 11 Feb 2013 13:12:36 +0000
Message-ID: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:35 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 4.0-testing 00/10] XSA-{25, 27, 33,
 36}: Backports for 4.0 (for Debian update)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 need of these for a Debian squeeze update (the others are all in
the tree already) so I thought I would share. These are based on the 4.1
backports already in tree. If any one wants to check my working (or just
compare notes with their own backports) I'd appreciate it.

The only one which I'm a bit uncertain about is XSA-36, not because the
backport was hard but because I'm not sure what if anything my be needed
as an antecedent to those patches. I already included a backport of "AMD
IOMMU: Fix an interrupt remapping issue" (unstable 23200:995a0c01a076).

I'm also intending to wait for the "AMD IOMMU: XSA-36 follow ups"
patches to go into mainline before actually sending these anywhere.

NB I also included "libxc: Do not use dom0 physmem as parameter to lzma
decoder" as a precursor to "libxc: builder: limit maximum size of
kernel/ramdisk." since it simplified the backport but also had a vague
whiff of being useful too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 13:13:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13:13: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 1U4tBY-0003MQ-2A; Mon, 11 Feb 2013 13:12: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 1U4tBW-0003MF-Jd
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:38 +0000
Received: from [85.158.139.211:59603] by server-6.bemta-5.messagelabs.com id
	50/05-01489-54EE8115; Mon, 11 Feb 2013 13:12:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360588357!20884893!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3658 invoked from network); 11 Feb 2013 13:12:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:12:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1329516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 13:12: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.297.1;
	Mon, 11 Feb 2013 13:12:36 +0000
Message-ID: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:35 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 4.0-testing 00/10] XSA-{25, 27, 33,
 36}: Backports for 4.0 (for Debian update)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 need of these for a Debian squeeze update (the others are all in
the tree already) so I thought I would share. These are based on the 4.1
backports already in tree. If any one wants to check my working (or just
compare notes with their own backports) I'd appreciate it.

The only one which I'm a bit uncertain about is XSA-36, not because the
backport was hard but because I'm not sure what if anything my be needed
as an antecedent to those patches. I already included a backport of "AMD
IOMMU: Fix an interrupt remapping issue" (unstable 23200:995a0c01a076).

I'm also intending to wait for the "AMD IOMMU: XSA-36 follow ups"
patches to go into mainline before actually sending these anywhere.

NB I also included "libxc: Do not use dom0 physmem as parameter to lzma
decoder" as a precursor to "libxc: builder: limit maximum size of
kernel/ramdisk." since it simplified the backport but also had a vague
whiff of being useful too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBu-0003QN-Pl; Mon, 11 Feb 2013 13:13: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 1U4tBr-0003OY-1Z
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:59 +0000
Received: from [85.158.139.83:29524] by server-3.bemta-5.messagelabs.com id
	32/D8-07037-A5EE8115; Mon, 11 Feb 2013 13:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27111 invoked from network); 11 Feb 2013 13:12: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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996116"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBm-0005mc-3J;
	Mon, 11 Feb 2013 13:12:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:53 +0000
Message-ID: <1360588373-779-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 10/10] AMD,
	IOMMU: Make per-device interrupt remapping table 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

From: Boris Ostrovsky <boris.ostrovsky@amd.com>

Using global interrupt remapping table may be insecure, as
described by XSA-36. This patch makes per-device mode default.

This is XSA-36 / CVE-2013-0153.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

Moved warning in amd_iov_detect() to location covering all cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26519:1af531e7bc2f
xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
---
 xen/drivers/passthrough/amd/iommu_acpi.c    |    5 +++--
 xen/drivers/passthrough/amd/pci_amd_iommu.c |    2 ++
 xen/drivers/passthrough/iommu.c             |    4 +++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c
index 0d6d2a6..bf4a691 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,7 +20,6 @@
 
 #include <xen/config.h>
 #include <xen/errno.h>
-#include <asm/apicdef.h>
 #include <asm/io_apic.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
@@ -690,7 +689,7 @@ static u16 __init parse_ivhd_device_special(
             /* set device id of ioapic */
             ioapic_bdf[ivhd_device->special.handle].bdf = bdf;
 
-            ioapic_bdf[ivhd_device->special.handle].pin_setup = xzalloc_array(
+            ioapic_bdf[ivhd_device->special.handle].pin_setup = xmalloc_array(
                 unsigned long, BITS_TO_LONGS(nr_ioapic_registers[apic]));
             if ( nr_ioapic_registers[apic] &&
                  !ioapic_bdf[IO_APIC_ID(apic)].pin_setup )
@@ -698,6 +697,8 @@ static u16 __init parse_ivhd_device_special(
                 printk(XENLOG_ERR "IVHD Error: Out of memory\n");
                 return 0;
             }
+	    memset(ioapic_bdf[ivhd_device->special.handle].pin_setup, 0,
+		   sizeof(unsigned long) * BITS_TO_LONGS(nr_ioapic_registers[apic]));
         }
         return dev_length;
     }
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index fb29e20..597a06a 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -173,6 +173,8 @@ int amd_iov_detect(void)
         printk("Error initialization\n");
         return -ENODEV;
     }
+    if ( !amd_iommu_perdev_intremap )
+        printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is not recommended (see XSA-36)!\n");
     return 0;
 }
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 0dad6ef..5b3c66b 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -48,7 +48,7 @@ bool_t __read_mostly iommu_snoop = 1;
 bool_t __read_mostly iommu_qinval = 1;
 bool_t __read_mostly iommu_intremap = 1;
 bool_t __read_mostly amd_iommu_debug;
-bool_t __read_mostly amd_iommu_perdev_intremap;
+bool_t __read_mostly amd_iommu_perdev_intremap = 1;
 
 static void __init parse_iommu_param(char *s)
 {
@@ -78,6 +78,8 @@ static void __init parse_iommu_param(char *s)
             amd_iommu_debug = 1;
         else if ( !strcmp(s, "amd-iommu-perdev-intremap") )
             amd_iommu_perdev_intremap = 1;
+        else if ( !strcmp(s, "amd-iommu-global-intremap") )
+            amd_iommu_perdev_intremap = 0;
         else if ( !strcmp(s, "dom0-passthrough") )
             iommu_passthrough = 1;
         else if ( !strcmp(s, "dom0-strict") )
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBu-0003QN-Pl; Mon, 11 Feb 2013 13:13: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 1U4tBr-0003OY-1Z
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:59 +0000
Received: from [85.158.139.83:29524] by server-3.bemta-5.messagelabs.com id
	32/D8-07037-A5EE8115; Mon, 11 Feb 2013 13:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27111 invoked from network); 11 Feb 2013 13:12: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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996116"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBm-0005mc-3J;
	Mon, 11 Feb 2013 13:12:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:53 +0000
Message-ID: <1360588373-779-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 10/10] AMD,
	IOMMU: Make per-device interrupt remapping table 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

From: Boris Ostrovsky <boris.ostrovsky@amd.com>

Using global interrupt remapping table may be insecure, as
described by XSA-36. This patch makes per-device mode default.

This is XSA-36 / CVE-2013-0153.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

Moved warning in amd_iov_detect() to location covering all cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26519:1af531e7bc2f
xen-unstable date: Tue Feb  5 14:22:11 UTC 2013
---
 xen/drivers/passthrough/amd/iommu_acpi.c    |    5 +++--
 xen/drivers/passthrough/amd/pci_amd_iommu.c |    2 ++
 xen/drivers/passthrough/iommu.c             |    4 +++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c
index 0d6d2a6..bf4a691 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,7 +20,6 @@
 
 #include <xen/config.h>
 #include <xen/errno.h>
-#include <asm/apicdef.h>
 #include <asm/io_apic.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
@@ -690,7 +689,7 @@ static u16 __init parse_ivhd_device_special(
             /* set device id of ioapic */
             ioapic_bdf[ivhd_device->special.handle].bdf = bdf;
 
-            ioapic_bdf[ivhd_device->special.handle].pin_setup = xzalloc_array(
+            ioapic_bdf[ivhd_device->special.handle].pin_setup = xmalloc_array(
                 unsigned long, BITS_TO_LONGS(nr_ioapic_registers[apic]));
             if ( nr_ioapic_registers[apic] &&
                  !ioapic_bdf[IO_APIC_ID(apic)].pin_setup )
@@ -698,6 +697,8 @@ static u16 __init parse_ivhd_device_special(
                 printk(XENLOG_ERR "IVHD Error: Out of memory\n");
                 return 0;
             }
+	    memset(ioapic_bdf[ivhd_device->special.handle].pin_setup, 0,
+		   sizeof(unsigned long) * BITS_TO_LONGS(nr_ioapic_registers[apic]));
         }
         return dev_length;
     }
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index fb29e20..597a06a 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -173,6 +173,8 @@ int amd_iov_detect(void)
         printk("Error initialization\n");
         return -ENODEV;
     }
+    if ( !amd_iommu_perdev_intremap )
+        printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is not recommended (see XSA-36)!\n");
     return 0;
 }
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 0dad6ef..5b3c66b 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -48,7 +48,7 @@ bool_t __read_mostly iommu_snoop = 1;
 bool_t __read_mostly iommu_qinval = 1;
 bool_t __read_mostly iommu_intremap = 1;
 bool_t __read_mostly amd_iommu_debug;
-bool_t __read_mostly amd_iommu_perdev_intremap;
+bool_t __read_mostly amd_iommu_perdev_intremap = 1;
 
 static void __init parse_iommu_param(char *s)
 {
@@ -78,6 +78,8 @@ static void __init parse_iommu_param(char *s)
             amd_iommu_debug = 1;
         else if ( !strcmp(s, "amd-iommu-perdev-intremap") )
             amd_iommu_perdev_intremap = 1;
+        else if ( !strcmp(s, "amd-iommu-global-intremap") )
+            amd_iommu_perdev_intremap = 0;
         else if ( !strcmp(s, "dom0-passthrough") )
             iommu_passthrough = 1;
         else if ( !strcmp(s, "dom0-strict") )
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBz-0003Su-6c; Mon, 11 Feb 2013 13:13: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 1U4tBx-0003RL-O2
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:13:05 +0000
Received: from [85.158.137.99:10089] by server-9.bemta-3.messagelabs.com id
	C5/DC-09484-06EE8115; Mon, 11 Feb 2013 13:13:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360588380!15511804!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6223 invoked from network); 11 Feb 2013 13:13:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645862"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:59 -0500
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 1U4tBl-0005mc-Ph;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:44 +0000
Message-ID: <1360588373-779-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4.0-testing 01/10] libxc: Do not use dom0
	physmem as parameter to lzma decoder
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <Ian.Jackson@eu.citrix.com>

It's not clear why a userspace lzma decode would want to use that
particular value, what bearing it has on anything or why it would
assume it could use 1/3 of the total RAM in the system (potentially
quite a large amount of RAM) as opposed to any other limit number.

Instead, hardcode 32Mby.

This reverts 22830:c80960244942, removes the xc_get_physmem/physmem
function entirely, and replaces the expression at the call site with a
fixed constant.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/xc_dom_bzimageloader.c |   23 +----------------------
 1 files changed, 1 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index 398dbff..aa5abc7 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -149,27 +149,6 @@ static int xc_try_bzip2_decode(
 
 #include <lzma.h>
 
-static uint64_t physmem(void)
-{
-    uint64_t ret = 0;
-    const long pagesize = sysconf(_SC_PAGESIZE);
-    const long pages = sysconf(_SC_PHYS_PAGES);
-
-    if ( (pagesize != -1) || (pages != -1) )
-    {
-        /*
-         * According to docs, pagesize * pages can overflow.
-         * Simple case is 32-bit box with 4 GiB or more RAM,
-         * which may report exactly 4 GiB of RAM, and "long"
-         * being 32-bit will overflow. Casting to uint64_t
-         * hopefully avoids overflows in the near future.
-         */
-        ret = (uint64_t)(pagesize) * (uint64_t)(pages);
-    }
-
-    return ret;
-}
-
 static int xc_try_lzma_decode(
     struct xc_dom_image *dom, void **blob, size_t *size)
 {
@@ -182,7 +161,7 @@ static int xc_try_lzma_decode(
     int outsize;
     const char *msg;
 
-    ret = lzma_alone_decoder(&stream, physmem() / 3);
+    ret = lzma_alone_decoder(&stream, 32*1024*1024);
     if ( ret != LZMA_OK )
     {
         xc_dom_printf("LZMA: Failed to init stream decoder\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 Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBs-0003PM-M8; Mon, 11 Feb 2013 13:13: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 1U4tBq-0003OO-GR
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:58 +0000
Received: from [85.158.139.83:29468] by server-12.bemta-5.messagelabs.com id
	C9/B0-20195-95EE8115; Mon, 11 Feb 2013 13:12:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27071 invoked from network); 11 Feb 2013 13:12: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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996115"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBm-0005mc-1Y;
	Mon, 11 Feb 2013 13:12:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:52 +0000
Message-ID: <1360588373-779-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 09/10] AMD,
	IOMMU: Disable IOMMU if SATA Combined mode is on
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Boris Ostrovsky <boris.ostrovsky@amd.com>

AMD's SP5100 chipset can be placed into SATA Combined mode
that may cause prevent dom0 from booting when IOMMU is
enabled and per-device interrupt remapping table is used.
While SP5100 erratum 28 requires BIOSes to disable this mode,
some may still use it.

This patch checks whether this mode is on and, if per-device
table is in use, disables IOMMU.

This is XSA-36 / CVE-2013-0153.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

Flipped operands of && in amd_iommu_init() to make the message issued
by amd_sp5100_erratum28() match reality (when amd_iommu_perdev_intremap
is zero, there's really no point in calling the function).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26518:e379a23b0465
xen-unstable date: Tue Feb  5 14:21:25 UTC 2013
---
 xen/drivers/passthrough/amd/iommu_init.c |   33 ++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_init.c b/xen/drivers/passthrough/amd/iommu_init.c
index c0ceb2e..170f61f 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -823,12 +823,45 @@ static int __init amd_iommu_setup_device_table(void)
     return 0;
 }
 
+/* Check whether SP5100 SATA Combined mode is on */
+static bool_t __init amd_sp5100_erratum28(void)
+{
+    u32 bus, id;
+    u16 vendor_id, dev_id;
+    u8 byte;
+
+    for (bus = 0; bus < 256; bus++)
+    {
+        id = pci_conf_read32(bus, 0x14, 0, PCI_VENDOR_ID);
+
+        vendor_id = id & 0xffff;
+        dev_id = (id >> 16) & 0xffff;
+
+        /* SP5100 SMBus module sets Combined mode on */
+        if (vendor_id != 0x1002 || dev_id != 0x4385)
+            continue;
+
+        byte = pci_conf_read8(bus, 0x14, 0, 0xad);
+        if ( (byte >> 3) & 1 )
+        {
+            printk(XENLOG_WARNING "AMD-Vi: SP5100 erratum 28 detected, disabling IOMMU.\n"
+                   "If possible, disable SATA Combined mode in BIOS or contact your vendor for BIOS update.\n");
+            return 1;
+        }
+    }
+
+    return 0;
+}
+
 int __init amd_iommu_init(void)
 {
     struct amd_iommu *iommu;
 
     BUG_ON( !iommu_found() );
 
+    if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
+        goto error_out;
+
     irq_to_iommu = xmalloc_array(struct amd_iommu *, nr_irqs);
     if ( irq_to_iommu == NULL )
         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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBr-0003Oy-8I; Mon, 11 Feb 2013 13:12: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 1U4tBp-0003OA-Us
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:58 +0000
Received: from [85.158.139.83:29412] by server-16.bemta-5.messagelabs.com id
	74/18-14948-95EE8115; Mon, 11 Feb 2013 13:12:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27040 invoked from network); 11 Feb 2013 13:12:56 -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;
	11 Feb 2013 13:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996114"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Tm;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:49 +0000
Message-ID: <1360588373-779-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 4.0-testing 06/10] AMD IOMMU: Fix an interrupt
	remapping 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

From: Wei Wang <wei.wang2@amd.com>

Some device could generate bogus interrupts if an IO-APIC RTE and an
iommu interrupt remapping entry are not consistent during 2 adjacent
64bits IO-APIC RTE updates. For example, if the 2nd operation updates
destination bits in RTE for SATA device and unmask it, in some case,
SATA device will assert ioapic pin to generate interrupt immediately
using new destination but iommu could still translate it into the old
destination, then dom0 would be confused. To fix that, we sync up
interrupt remapping entry with IO-APIC IRE on every 32 bits operation
and forward IOAPIC RTE updates after interrupt.

Signed-off-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset:   23200:995a0c01a076
xen-unstable date:        Tue Apr 12 13:26:19 2011 +0100
---
 xen/drivers/passthrough/amd/iommu_intr.c |  104 +++++++++++++++++------------
 1 files changed, 61 insertions(+), 43 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index 8c284d3..ceb6f47 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -116,8 +116,7 @@ void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
 static void update_intremap_entry_from_ioapic(
     int bdf,
     struct amd_iommu *iommu,
-    struct IO_APIC_route_entry *ioapic_rte,
-    unsigned int rte_upper, unsigned int value)
+    struct IO_APIC_route_entry *ioapic_rte)
 {
     unsigned long flags;
     u32* entry;
@@ -129,28 +128,26 @@ static void update_intremap_entry_from_ioapic(
 
     req_id = get_intremap_requestor_id(bdf);
     lock = get_intremap_lock(req_id);
-    /* only remap interrupt vector when lower 32 bits in ioapic ire changed */
-    if ( likely(!rte_upper) )
-    {
-        delivery_mode = rte->delivery_mode;
-        vector = rte->vector;
-        dest_mode = rte->dest_mode;
-        dest = rte->dest.logical.logical_dest;
 
-        spin_lock_irqsave(lock, flags);
-        offset = get_intremap_offset(vector, delivery_mode);
-        entry = (u32*)get_intremap_entry(req_id, offset);
+    delivery_mode = rte->delivery_mode;
+    vector = rte->vector;
+    dest_mode = rte->dest_mode;
+    dest = rte->dest.logical.logical_dest;
 
-        update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
-        spin_unlock_irqrestore(lock, flags);
+    spin_lock_irqsave(lock, flags);
 
-        if ( iommu->enabled )
-        {
-            spin_lock_irqsave(&iommu->lock, flags);
-            invalidate_interrupt_table(iommu, req_id);
-            flush_command_buffer(iommu);
-            spin_unlock_irqrestore(&iommu->lock, flags);
-        }
+    offset = get_intremap_offset(vector, delivery_mode);
+    entry = (u32*)get_intremap_entry(req_id, offset);
+    update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
+
+    spin_unlock_irqrestore(lock, flags);
+
+    if ( iommu->enabled )
+    {
+        spin_lock_irqsave(&iommu->lock, flags);
+        invalidate_interrupt_table(iommu, req_id);
+        flush_command_buffer(iommu);
+        spin_unlock_irqrestore(&iommu->lock, flags);
     }
 }
 
@@ -198,7 +195,8 @@ int __init amd_iommu_setup_ioapic_remapping(void)
             spin_lock_irqsave(lock, flags);
             offset = get_intremap_offset(vector, delivery_mode);
             entry = (u32*)get_intremap_entry(req_id, offset);
-            update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
+            update_intremap_entry(entry, vector,
+                                  delivery_mode, dest_mode, dest);
             spin_unlock_irqrestore(lock, flags);
 
             if ( iommu->enabled )
@@ -216,16 +214,17 @@ int __init amd_iommu_setup_ioapic_remapping(void)
 void amd_iommu_ioapic_update_ire(
     unsigned int apic, unsigned int reg, unsigned int value)
 {
-    struct IO_APIC_route_entry ioapic_rte = { 0 };
-    unsigned int rte_upper = (reg & 1) ? 1 : 0;
+    struct IO_APIC_route_entry old_rte = { 0 };
+    struct IO_APIC_route_entry new_rte = { 0 };
+    unsigned int rte_lo = (reg & 1) ? reg - 1 : reg;
     int saved_mask, bdf;
     struct amd_iommu *iommu;
 
-    *IO_APIC_BASE(apic) = reg;
-    *(IO_APIC_BASE(apic)+4) = value;
-
     if ( !iommu_intremap )
+    {
+        __io_apic_write(apic, reg, value);
         return;
+    }
 
     /* get device id of ioapic devices */
     bdf = ioapic_bdf[IO_APIC_ID(apic)];
@@ -234,30 +233,49 @@ void amd_iommu_ioapic_update_ire(
     {
         AMD_IOMMU_DEBUG(
             "Fail to find iommu for ioapic device id = 0x%x\n", bdf);
+        __io_apic_write(apic, reg, value);
         return;
     }
-    if ( rte_upper )
-        return;
 
-    /* read both lower and upper 32-bits of rte entry */
-    *IO_APIC_BASE(apic) = reg;
-    *(((u32 *)&ioapic_rte) + 0) = *(IO_APIC_BASE(apic)+4);
-    *IO_APIC_BASE(apic) = reg + 1;
-    *(((u32 *)&ioapic_rte) + 1) = *(IO_APIC_BASE(apic)+4);
+    /* save io-apic rte lower 32 bits */
+    *((u32 *)&old_rte) =  __io_apic_read(apic, rte_lo);
+    saved_mask = old_rte.mask;
+
+    if ( reg == rte_lo )
+    {
+        *((u32 *)&new_rte) = value;
+        /* read upper 32 bits from io-apic rte */
+        *(((u32 *)&new_rte) + 1) = __io_apic_read(apic, reg + 1);
+    }
+    else
+    {
+        *((u32 *)&new_rte) = *((u32 *)&old_rte);
+        *(((u32 *)&new_rte) + 1) = value;
+    }
 
     /* mask the interrupt while we change the intremap table */
-    saved_mask = ioapic_rte.mask;
-    ioapic_rte.mask = 1;
-    *IO_APIC_BASE(apic) = reg;
-    *(IO_APIC_BASE(apic)+4) = *(((int *)&ioapic_rte)+0);
-    ioapic_rte.mask = saved_mask;
+    if ( !saved_mask )
+    {
+        old_rte.mask = 1;
+        __io_apic_write(apic, rte_lo, *((u32 *)&old_rte));
+    }
 
-    update_intremap_entry_from_ioapic(
-        bdf, iommu, &ioapic_rte, rte_upper, value);
+    /* Update interrupt remapping entry */
+    update_intremap_entry_from_ioapic(bdf, iommu, &new_rte);
+
+    /* Forward write access to IO-APIC RTE */
+    __io_apic_write(apic, reg, value);
+
+    /* For lower bits access, return directly to avoid double writes */
+    if ( reg == rte_lo )
+        return;
 
     /* unmask the interrupt after we have updated the intremap table */
-    *IO_APIC_BASE(apic) = reg;
-    *(IO_APIC_BASE(apic)+4) = *(((u32 *)&ioapic_rte)+0);
+    if ( !saved_mask )
+    {
+        old_rte.mask = saved_mask;
+        __io_apic_write(apic, rte_lo, *((u32 *)&old_rte));
+    }
 }
 
 static void update_intremap_entry_from_msi_msg(
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBq-0003OU-FB; Mon, 11 Feb 2013 13:12: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 1U4tBp-0003O8-92
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:57 +0000
Received: from [85.158.143.99:27674] by server-3.bemta-4.messagelabs.com id
	56/FF-08920-85EE8115; Mon, 11 Feb 2013 13:12:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22385 invoked from network); 11 Feb 2013 13:12:56 -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;
	11 Feb 2013 13:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645852"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Sb;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:47 +0000
Message-ID: <1360588373-779-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 4.0-testing 04/10] x86/mm: Fix loop increment in
	paging_log_dirty_range()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

In 23417:53ef1f35a0f8 (the fix for XSA-27 / CVE-2012-5511), the
loop variable gets incremented twice, so the loop only clears every
second page of the bitmap.  This might cause the tools to think that
pages are dirty when they are not.

Reported-by: Steven Noonan <snoonan@amazon.com>
Reported-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/mm/paging.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index bba747e..0caebe0 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -491,7 +491,8 @@ int paging_log_dirty_range(struct domain *d,
 
         size = ((nr + BITS_PER_LONG - 1) / BITS_PER_LONG) * sizeof (long);
         rv = 0;
-        for ( off = 0; !rv && off < size; off += sizeof zeroes )
+        off = 0;
+        while ( !rv && off < size )
         {
             int todo = min(size - off, (int) PAGE_SIZE);
             if ( copy_to_guest_offset(dirty_bitmap, off, zeroes, todo) )
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBr-0003Oy-8I; Mon, 11 Feb 2013 13:12: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 1U4tBp-0003OA-Us
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:58 +0000
Received: from [85.158.139.83:29412] by server-16.bemta-5.messagelabs.com id
	74/18-14948-95EE8115; Mon, 11 Feb 2013 13:12:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27040 invoked from network); 11 Feb 2013 13:12:56 -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;
	11 Feb 2013 13:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996114"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Tm;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:49 +0000
Message-ID: <1360588373-779-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 4.0-testing 06/10] AMD IOMMU: Fix an interrupt
	remapping 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

From: Wei Wang <wei.wang2@amd.com>

Some device could generate bogus interrupts if an IO-APIC RTE and an
iommu interrupt remapping entry are not consistent during 2 adjacent
64bits IO-APIC RTE updates. For example, if the 2nd operation updates
destination bits in RTE for SATA device and unmask it, in some case,
SATA device will assert ioapic pin to generate interrupt immediately
using new destination but iommu could still translate it into the old
destination, then dom0 would be confused. To fix that, we sync up
interrupt remapping entry with IO-APIC IRE on every 32 bits operation
and forward IOAPIC RTE updates after interrupt.

Signed-off-by: Wei Wang <wei.wang2@amd.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
xen-unstable changeset:   23200:995a0c01a076
xen-unstable date:        Tue Apr 12 13:26:19 2011 +0100
---
 xen/drivers/passthrough/amd/iommu_intr.c |  104 +++++++++++++++++------------
 1 files changed, 61 insertions(+), 43 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index 8c284d3..ceb6f47 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -116,8 +116,7 @@ void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
 static void update_intremap_entry_from_ioapic(
     int bdf,
     struct amd_iommu *iommu,
-    struct IO_APIC_route_entry *ioapic_rte,
-    unsigned int rte_upper, unsigned int value)
+    struct IO_APIC_route_entry *ioapic_rte)
 {
     unsigned long flags;
     u32* entry;
@@ -129,28 +128,26 @@ static void update_intremap_entry_from_ioapic(
 
     req_id = get_intremap_requestor_id(bdf);
     lock = get_intremap_lock(req_id);
-    /* only remap interrupt vector when lower 32 bits in ioapic ire changed */
-    if ( likely(!rte_upper) )
-    {
-        delivery_mode = rte->delivery_mode;
-        vector = rte->vector;
-        dest_mode = rte->dest_mode;
-        dest = rte->dest.logical.logical_dest;
 
-        spin_lock_irqsave(lock, flags);
-        offset = get_intremap_offset(vector, delivery_mode);
-        entry = (u32*)get_intremap_entry(req_id, offset);
+    delivery_mode = rte->delivery_mode;
+    vector = rte->vector;
+    dest_mode = rte->dest_mode;
+    dest = rte->dest.logical.logical_dest;
 
-        update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
-        spin_unlock_irqrestore(lock, flags);
+    spin_lock_irqsave(lock, flags);
 
-        if ( iommu->enabled )
-        {
-            spin_lock_irqsave(&iommu->lock, flags);
-            invalidate_interrupt_table(iommu, req_id);
-            flush_command_buffer(iommu);
-            spin_unlock_irqrestore(&iommu->lock, flags);
-        }
+    offset = get_intremap_offset(vector, delivery_mode);
+    entry = (u32*)get_intremap_entry(req_id, offset);
+    update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
+
+    spin_unlock_irqrestore(lock, flags);
+
+    if ( iommu->enabled )
+    {
+        spin_lock_irqsave(&iommu->lock, flags);
+        invalidate_interrupt_table(iommu, req_id);
+        flush_command_buffer(iommu);
+        spin_unlock_irqrestore(&iommu->lock, flags);
     }
 }
 
@@ -198,7 +195,8 @@ int __init amd_iommu_setup_ioapic_remapping(void)
             spin_lock_irqsave(lock, flags);
             offset = get_intremap_offset(vector, delivery_mode);
             entry = (u32*)get_intremap_entry(req_id, offset);
-            update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
+            update_intremap_entry(entry, vector,
+                                  delivery_mode, dest_mode, dest);
             spin_unlock_irqrestore(lock, flags);
 
             if ( iommu->enabled )
@@ -216,16 +214,17 @@ int __init amd_iommu_setup_ioapic_remapping(void)
 void amd_iommu_ioapic_update_ire(
     unsigned int apic, unsigned int reg, unsigned int value)
 {
-    struct IO_APIC_route_entry ioapic_rte = { 0 };
-    unsigned int rte_upper = (reg & 1) ? 1 : 0;
+    struct IO_APIC_route_entry old_rte = { 0 };
+    struct IO_APIC_route_entry new_rte = { 0 };
+    unsigned int rte_lo = (reg & 1) ? reg - 1 : reg;
     int saved_mask, bdf;
     struct amd_iommu *iommu;
 
-    *IO_APIC_BASE(apic) = reg;
-    *(IO_APIC_BASE(apic)+4) = value;
-
     if ( !iommu_intremap )
+    {
+        __io_apic_write(apic, reg, value);
         return;
+    }
 
     /* get device id of ioapic devices */
     bdf = ioapic_bdf[IO_APIC_ID(apic)];
@@ -234,30 +233,49 @@ void amd_iommu_ioapic_update_ire(
     {
         AMD_IOMMU_DEBUG(
             "Fail to find iommu for ioapic device id = 0x%x\n", bdf);
+        __io_apic_write(apic, reg, value);
         return;
     }
-    if ( rte_upper )
-        return;
 
-    /* read both lower and upper 32-bits of rte entry */
-    *IO_APIC_BASE(apic) = reg;
-    *(((u32 *)&ioapic_rte) + 0) = *(IO_APIC_BASE(apic)+4);
-    *IO_APIC_BASE(apic) = reg + 1;
-    *(((u32 *)&ioapic_rte) + 1) = *(IO_APIC_BASE(apic)+4);
+    /* save io-apic rte lower 32 bits */
+    *((u32 *)&old_rte) =  __io_apic_read(apic, rte_lo);
+    saved_mask = old_rte.mask;
+
+    if ( reg == rte_lo )
+    {
+        *((u32 *)&new_rte) = value;
+        /* read upper 32 bits from io-apic rte */
+        *(((u32 *)&new_rte) + 1) = __io_apic_read(apic, reg + 1);
+    }
+    else
+    {
+        *((u32 *)&new_rte) = *((u32 *)&old_rte);
+        *(((u32 *)&new_rte) + 1) = value;
+    }
 
     /* mask the interrupt while we change the intremap table */
-    saved_mask = ioapic_rte.mask;
-    ioapic_rte.mask = 1;
-    *IO_APIC_BASE(apic) = reg;
-    *(IO_APIC_BASE(apic)+4) = *(((int *)&ioapic_rte)+0);
-    ioapic_rte.mask = saved_mask;
+    if ( !saved_mask )
+    {
+        old_rte.mask = 1;
+        __io_apic_write(apic, rte_lo, *((u32 *)&old_rte));
+    }
 
-    update_intremap_entry_from_ioapic(
-        bdf, iommu, &ioapic_rte, rte_upper, value);
+    /* Update interrupt remapping entry */
+    update_intremap_entry_from_ioapic(bdf, iommu, &new_rte);
+
+    /* Forward write access to IO-APIC RTE */
+    __io_apic_write(apic, reg, value);
+
+    /* For lower bits access, return directly to avoid double writes */
+    if ( reg == rte_lo )
+        return;
 
     /* unmask the interrupt after we have updated the intremap table */
-    *IO_APIC_BASE(apic) = reg;
-    *(IO_APIC_BASE(apic)+4) = *(((u32 *)&ioapic_rte)+0);
+    if ( !saved_mask )
+    {
+        old_rte.mask = saved_mask;
+        __io_apic_write(apic, rte_lo, *((u32 *)&old_rte));
+    }
 }
 
 static void update_intremap_entry_from_msi_msg(
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBs-0003PM-M8; Mon, 11 Feb 2013 13:13: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 1U4tBq-0003OO-GR
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:58 +0000
Received: from [85.158.139.83:29468] by server-12.bemta-5.messagelabs.com id
	C9/B0-20195-95EE8115; Mon, 11 Feb 2013 13:12:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27071 invoked from network); 11 Feb 2013 13:12: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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996115"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBm-0005mc-1Y;
	Mon, 11 Feb 2013 13:12:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:52 +0000
Message-ID: <1360588373-779-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 09/10] AMD,
	IOMMU: Disable IOMMU if SATA Combined mode is on
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Boris Ostrovsky <boris.ostrovsky@amd.com>

AMD's SP5100 chipset can be placed into SATA Combined mode
that may cause prevent dom0 from booting when IOMMU is
enabled and per-device interrupt remapping table is used.
While SP5100 erratum 28 requires BIOSes to disable this mode,
some may still use it.

This patch checks whether this mode is on and, if per-device
table is in use, disables IOMMU.

This is XSA-36 / CVE-2013-0153.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

Flipped operands of && in amd_iommu_init() to make the message issued
by amd_sp5100_erratum28() match reality (when amd_iommu_perdev_intremap
is zero, there's really no point in calling the function).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26518:e379a23b0465
xen-unstable date: Tue Feb  5 14:21:25 UTC 2013
---
 xen/drivers/passthrough/amd/iommu_init.c |   33 ++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_init.c b/xen/drivers/passthrough/amd/iommu_init.c
index c0ceb2e..170f61f 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -823,12 +823,45 @@ static int __init amd_iommu_setup_device_table(void)
     return 0;
 }
 
+/* Check whether SP5100 SATA Combined mode is on */
+static bool_t __init amd_sp5100_erratum28(void)
+{
+    u32 bus, id;
+    u16 vendor_id, dev_id;
+    u8 byte;
+
+    for (bus = 0; bus < 256; bus++)
+    {
+        id = pci_conf_read32(bus, 0x14, 0, PCI_VENDOR_ID);
+
+        vendor_id = id & 0xffff;
+        dev_id = (id >> 16) & 0xffff;
+
+        /* SP5100 SMBus module sets Combined mode on */
+        if (vendor_id != 0x1002 || dev_id != 0x4385)
+            continue;
+
+        byte = pci_conf_read8(bus, 0x14, 0, 0xad);
+        if ( (byte >> 3) & 1 )
+        {
+            printk(XENLOG_WARNING "AMD-Vi: SP5100 erratum 28 detected, disabling IOMMU.\n"
+                   "If possible, disable SATA Combined mode in BIOS or contact your vendor for BIOS update.\n");
+            return 1;
+        }
+    }
+
+    return 0;
+}
+
 int __init amd_iommu_init(void)
 {
     struct amd_iommu *iommu;
 
     BUG_ON( !iommu_found() );
 
+    if ( amd_iommu_perdev_intremap && amd_sp5100_erratum28() )
+        goto error_out;
+
     irq_to_iommu = xmalloc_array(struct amd_iommu *, nr_irqs);
     if ( irq_to_iommu == NULL )
         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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBq-0003OU-FB; Mon, 11 Feb 2013 13:12: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 1U4tBp-0003O8-92
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:57 +0000
Received: from [85.158.143.99:27674] by server-3.bemta-4.messagelabs.com id
	56/FF-08920-85EE8115; Mon, 11 Feb 2013 13:12:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22385 invoked from network); 11 Feb 2013 13:12:56 -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;
	11 Feb 2013 13:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645852"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Sb;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:47 +0000
Message-ID: <1360588373-779-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH 4.0-testing 04/10] x86/mm: Fix loop increment in
	paging_log_dirty_range()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

In 23417:53ef1f35a0f8 (the fix for XSA-27 / CVE-2012-5511), the
loop variable gets incremented twice, so the loop only clears every
second page of the bitmap.  This might cause the tools to think that
pages are dirty when they are not.

Reported-by: Steven Noonan <snoonan@amazon.com>
Reported-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/mm/paging.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index bba747e..0caebe0 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -491,7 +491,8 @@ int paging_log_dirty_range(struct domain *d,
 
         size = ((nr + BITS_PER_LONG - 1) / BITS_PER_LONG) * sizeof (long);
         rv = 0;
-        for ( off = 0; !rv && off < size; off += sizeof zeroes )
+        off = 0;
+        while ( !rv && off < size )
         {
             int todo = min(size - off, (int) PAGE_SIZE);
             if ( copy_to_guest_offset(dirty_bitmap, off, zeroes, todo) )
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBz-0003Su-6c; Mon, 11 Feb 2013 13:13: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 1U4tBx-0003RL-O2
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:13:05 +0000
Received: from [85.158.137.99:10089] by server-9.bemta-3.messagelabs.com id
	C5/DC-09484-06EE8115; Mon, 11 Feb 2013 13:13:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360588380!15511804!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6223 invoked from network); 11 Feb 2013 13:13:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645862"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:59 -0500
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 1U4tBl-0005mc-Ph;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:44 +0000
Message-ID: <1360588373-779-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4.0-testing 01/10] libxc: Do not use dom0
	physmem as parameter to lzma decoder
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <Ian.Jackson@eu.citrix.com>

It's not clear why a userspace lzma decode would want to use that
particular value, what bearing it has on anything or why it would
assume it could use 1/3 of the total RAM in the system (potentially
quite a large amount of RAM) as opposed to any other limit number.

Instead, hardcode 32Mby.

This reverts 22830:c80960244942, removes the xc_get_physmem/physmem
function entirely, and replaces the expression at the call site with a
fixed constant.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxc/xc_dom_bzimageloader.c |   23 +----------------------
 1 files changed, 1 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index 398dbff..aa5abc7 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -149,27 +149,6 @@ static int xc_try_bzip2_decode(
 
 #include <lzma.h>
 
-static uint64_t physmem(void)
-{
-    uint64_t ret = 0;
-    const long pagesize = sysconf(_SC_PAGESIZE);
-    const long pages = sysconf(_SC_PHYS_PAGES);
-
-    if ( (pagesize != -1) || (pages != -1) )
-    {
-        /*
-         * According to docs, pagesize * pages can overflow.
-         * Simple case is 32-bit box with 4 GiB or more RAM,
-         * which may report exactly 4 GiB of RAM, and "long"
-         * being 32-bit will overflow. Casting to uint64_t
-         * hopefully avoids overflows in the near future.
-         */
-        ret = (uint64_t)(pagesize) * (uint64_t)(pages);
-    }
-
-    return ret;
-}
-
 static int xc_try_lzma_decode(
     struct xc_dom_image *dom, void **blob, size_t *size)
 {
@@ -182,7 +161,7 @@ static int xc_try_lzma_decode(
     int outsize;
     const char *msg;
 
-    ret = lzma_alone_decoder(&stream, physmem() / 3);
+    ret = lzma_alone_decoder(&stream, 32*1024*1024);
     if ( ret != LZMA_OK )
     {
         xc_dom_printf("LZMA: Failed to init stream decoder\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 Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBv-0003Qq-D7; Mon, 11 Feb 2013 13:13: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 1U4tBs-0003P6-1G
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:13:00 +0000
Received: from [85.158.139.83:49656] by server-7.bemta-5.messagelabs.com id
	B0/4A-11121-B5EE8115; Mon, 11 Feb 2013 13:12:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27145 invoked from network); 11 Feb 2013 13:12:58 -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;
	11 Feb 2013 13:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996117"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-W5;
	Mon, 11 Feb 2013 13:12:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:51 +0000
Message-ID: <1360588373-779-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 08/10] AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <jbeulich@suse.com>

When changing the affinity of an IRQ associated with a passed
through PCI device, clear previous mapping.

This is XSA-36 / CVE-2013-0153.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

In addition, because some BIOSes may incorrectly program IVRS
entries for IOAPIC try to check for entry's consistency. Specifically,
if conflicting entries are found disable IOMMU if per-device
remapping table is used. If entries refer to bogus IOAPIC IDs
disable IOMMU unconditionally

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
xen-unstable changeset: 26517:601139e2b0db
xen-unstable date: Tue Feb  5 14:20:47 UTC 2013
---
 xen/drivers/passthrough/amd/iommu_acpi.c      |   59 +++++++++++++++++++++++--
 xen/drivers/passthrough/amd/iommu_intr.c      |   40 ++++++++++++++---
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |    5 ++
 3 files changed, 94 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c
index 7905e12..0d6d2a6 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,6 +20,8 @@
 
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <asm/apicdef.h>
+#include <asm/io_apic.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include <asm/hvm/svm/amd-iommu-acpi.h>
@@ -28,7 +30,6 @@ extern unsigned long amd_iommu_page_entries;
 extern unsigned short ivrs_bdf_entries;
 extern struct ivrs_mappings *ivrs_mappings;
 extern unsigned short last_bdf;
-extern int ioapic_bdf[MAX_IO_APICS];
 extern void *shared_intremap_table;
 
 static void add_ivrs_mapping_entry(
@@ -635,6 +636,7 @@ static u16 __init parse_ivhd_device_special(
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
+    int apic;
 
     dev_length = sizeof(struct acpi_ivhd_device_special);
     if ( header_length < (block_length + dev_length) )
@@ -651,9 +653,58 @@ static u16 __init parse_ivhd_device_special(
     }
 
     add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
-    /* set device id of ioapic */
-    ioapic_bdf[ivhd_device->special.handle] = bdf;
-    return dev_length;
+
+    if ( ivhd_device->special.variety != 1 /* ACPI_IVHD_IOAPIC */ )
+    {
+        if ( ivhd_device->special.variety != 2 /* ACPI_IVHD_HPET */ )
+            printk(XENLOG_ERR "Unrecognized IVHD special variety %#x\n",
+                   ivhd_device->special.variety);
+        return dev_length;
+    }
+
+    /*
+     * Some BIOSes have IOAPIC broken entries so we check for IVRS
+     * consistency here --- whether entry's IOAPIC ID is valid and
+     * whether there are conflicting/duplicated entries.
+     */
+    for ( apic = 0; apic < nr_ioapics; apic++ )
+    {
+        if ( IO_APIC_ID(apic) != ivhd_device->special.handle )
+            continue;
+
+        if ( ioapic_bdf[ivhd_device->special.handle].pin_setup )
+        {
+            if ( ioapic_bdf[ivhd_device->special.handle].bdf == bdf )
+                AMD_IOMMU_DEBUG("IVHD Warning: Duplicate IO-APIC %#x entries\n",
+                                ivhd_device->special.handle);
+            else
+            {
+                printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n",
+                       ivhd_device->special.handle);
+                if ( amd_iommu_perdev_intremap )
+                    return 0;
+            }
+        }
+        else
+        {
+            /* set device id of ioapic */
+            ioapic_bdf[ivhd_device->special.handle].bdf = bdf;
+
+            ioapic_bdf[ivhd_device->special.handle].pin_setup = xzalloc_array(
+                unsigned long, BITS_TO_LONGS(nr_ioapic_registers[apic]));
+            if ( nr_ioapic_registers[apic] &&
+                 !ioapic_bdf[IO_APIC_ID(apic)].pin_setup )
+            {
+                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
+                return 0;
+            }
+        }
+        return dev_length;
+    }
+
+    printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
+           ivhd_device->special.handle);
+    return 0;
 }
 
 static int __init parse_ivhd_block(struct acpi_ivhd_block_header *ivhd_block)
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index ceb6f47..f8b1bb0 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -26,7 +26,7 @@
 #define INTREMAP_LENGTH 0xB
 #define INTREMAP_ENTRIES (1 << INTREMAP_LENGTH)
 
-int ioapic_bdf[MAX_IO_APICS];
+struct ioapic_bdf ioapic_bdf[MAX_IO_APICS];
 extern struct ivrs_mappings *ivrs_mappings;
 extern unsigned short ivrs_bdf_entries;
 void *shared_intremap_table;
@@ -116,12 +116,12 @@ void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
 static void update_intremap_entry_from_ioapic(
     int bdf,
     struct amd_iommu *iommu,
-    struct IO_APIC_route_entry *ioapic_rte)
+    const struct IO_APIC_route_entry *rte,
+    const struct IO_APIC_route_entry *old_rte)
 {
     unsigned long flags;
     u32* entry;
     u8 delivery_mode, dest, vector, dest_mode;
-    struct IO_APIC_route_entry *rte = ioapic_rte;
     int req_id;
     spinlock_t *lock;
     int offset;
@@ -137,6 +137,14 @@ static void update_intremap_entry_from_ioapic(
     spin_lock_irqsave(lock, flags);
 
     offset = get_intremap_offset(vector, delivery_mode);
+    if ( old_rte )
+    {
+        int old_offset = get_intremap_offset(old_rte->vector,
+                                             old_rte->delivery_mode);
+
+        if ( offset != old_offset )
+            free_intremap_entry(bdf, old_offset);
+    }
     entry = (u32*)get_intremap_entry(req_id, offset);
     update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
 
@@ -175,7 +183,7 @@ int __init amd_iommu_setup_ioapic_remapping(void)
                 continue;
 
             /* get device id of ioapic devices */
-            bdf = ioapic_bdf[IO_APIC_ID(apic)];
+            bdf = ioapic_bdf[IO_APIC_ID(apic)].bdf;
             iommu = find_iommu_for_device(bdf);
             if ( !iommu )
             {
@@ -206,6 +214,7 @@ int __init amd_iommu_setup_ioapic_remapping(void)
                 flush_command_buffer(iommu);
                 spin_unlock_irqrestore(&iommu->lock, flags);
             }
+            set_bit(pin, ioapic_bdf[IO_APIC_ID(apic)].pin_setup);
         }
     }
     return 0;
@@ -217,6 +226,7 @@ void amd_iommu_ioapic_update_ire(
     struct IO_APIC_route_entry old_rte = { 0 };
     struct IO_APIC_route_entry new_rte = { 0 };
     unsigned int rte_lo = (reg & 1) ? reg - 1 : reg;
+    unsigned int pin = (reg - 0x10) / 2;
     int saved_mask, bdf;
     struct amd_iommu *iommu;
 
@@ -227,7 +237,7 @@ void amd_iommu_ioapic_update_ire(
     }
 
     /* get device id of ioapic devices */
-    bdf = ioapic_bdf[IO_APIC_ID(apic)];
+    bdf = ioapic_bdf[IO_APIC_ID(apic)].bdf;
     iommu = find_iommu_for_device(bdf);
     if ( !iommu )
     {
@@ -253,6 +263,14 @@ void amd_iommu_ioapic_update_ire(
         *(((u32 *)&new_rte) + 1) = value;
     }
 
+    if ( new_rte.mask &&
+         !test_bit(pin, ioapic_bdf[IO_APIC_ID(apic)].pin_setup) )
+    {
+        ASSERT(saved_mask);
+        __io_apic_write(apic, reg, value);
+        return;
+    }
+
     /* mask the interrupt while we change the intremap table */
     if ( !saved_mask )
     {
@@ -261,7 +279,11 @@ void amd_iommu_ioapic_update_ire(
     }
 
     /* Update interrupt remapping entry */
-    update_intremap_entry_from_ioapic(bdf, iommu, &new_rte);
+    update_intremap_entry_from_ioapic(
+        bdf, iommu, &new_rte,
+        test_and_set_bit(pin,
+                         ioapic_bdf[IO_APIC_ID(apic)].pin_setup) ? &old_rte
+                                                                 : NULL);
 
     /* Forward write access to IO-APIC RTE */
     __io_apic_write(apic, reg, value);
@@ -373,6 +395,12 @@ void amd_iommu_msi_msg_update_ire(
         return;
     }
 
+    if ( msi_desc->remap_index >= 0 )
+        update_intremap_entry_from_msi_msg(iommu, pdev, msi_desc, NULL);
+
+    if ( !msg )
+        return;
+
     update_intremap_entry_from_msi_msg(iommu, pdev, msi_desc, msg);
 }
 
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 5539636..bbe763d 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -89,6 +89,11 @@ void amd_iommu_read_msi_from_ire(
 unsigned int amd_iommu_read_ioapic_from_ire(
     unsigned int apic, unsigned int reg);
 
+extern struct ioapic_bdf {
+    u16 bdf;
+    unsigned long *pin_setup;
+} ioapic_bdf[];
+
 /* power management support */
 void amd_iommu_resume(void);
 void amd_iommu_suspend(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 Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBt-0003Pj-4T; Mon, 11 Feb 2013 13:13: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 1U4tBq-0003O8-HB
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:58 +0000
Received: from [85.158.143.99:30694] by server-3.bemta-4.messagelabs.com id
	9B/00-08920-A5EE8115; Mon, 11 Feb 2013 13:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22460 invoked from network); 11 Feb 2013 13:12:57 -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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645854"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Qy;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:46 +0000
Message-ID: <1360588373-779-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 03/10] hvm: Limit the size of large
	HVM op batches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

Doing large p2m updates for HVMOP_track_dirty_vram without preemption
ties up the physical processor. Integrating preemption into the p2m
updates is hard so simply limit to 1GB which is sufficient for a 15000
* 15000 * 32bpp framebuffer.

For HVMOP_modified_memory and HVMOP_set_mem_type preemptible add the
necessary machinery to handle preemption.

This is CVE-2012-5511 / XSA-27.

Signed-off-by: Tim Deegan <tim@xen.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>

x86/paging: Don't allocate user-controlled amounts of stack memory.

This is XSA-27 / CVE-2012-5511.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
v2: Provide definition of GB to fix x86-32 compile.

Signed-off-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 xen/arch/x86/hvm/hvm.c       |   37 +++++++++++++++++++++++++++++++++----
 xen/arch/x86/mm/paging.c     |   17 +++++++++++------
 xen/include/asm-x86/config.h |    4 +++-
 3 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 640969b..1ab0ec6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2943,6 +2943,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail2;
 
+        if ( a.nr > GB(1) >> PAGE_SHIFT )
+            goto param_fail2;
+
         rc = xsm_hvm_param(d, op);
         if ( rc )
             goto param_fail2;
@@ -2969,7 +2972,6 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
     {
         struct xen_hvm_modified_memory a;
         struct domain *d;
-        unsigned long pfn;
 
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
@@ -2996,8 +2998,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !paging_mode_log_dirty(d) )
             goto param_fail3;
 
-        for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
+        while ( a.nr > 0 )
         {
+            unsigned long pfn = a.first_pfn;
             p2m_type_t t;
             mfn_t mfn = gfn_to_mfn(d, pfn, &t);
             if ( p2m_is_paging(t) )
@@ -3018,6 +3021,19 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                 /* don't take a long time and don't die either */
                 sh_remove_shadows(d->vcpu[0], mfn, 1, 0);
             }
+
+            a.first_pfn++;
+            a.nr--;
+
+            /* Check for continuation if it's not the last interation */
+            if ( a.nr > 0 && hypercall_preempt_check() )
+            {
+                if ( copy_to_guest(arg, &a, 1) )
+                    rc = -EFAULT;
+                else
+                    rc = -EAGAIN;
+                break;
+            }
         }
 
     param_fail3:
@@ -3029,7 +3045,6 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
     {
         struct xen_hvm_set_mem_type a;
         struct domain *d;
-        unsigned long pfn;
         
         /* Interface types to internal p2m types */
         p2m_type_t memtype[] = {
@@ -3062,8 +3077,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
             goto param_fail4;
 
-        for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
+        while ( a.nr > 0 )
         {
+            unsigned long pfn = a.first_pfn;
             p2m_type_t t;
             p2m_type_t nt;
             mfn_t mfn;
@@ -3099,6 +3115,19 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                     goto param_fail4;
                 }
             }
+
+            a.first_pfn++;
+            a.nr--;
+
+            /* Check for continuation if it's not the last interation */
+            if ( a.nr > 0 && hypercall_preempt_check() )
+            {
+                if ( copy_to_guest(arg, &a, 1) )
+                    rc = -EFAULT;
+                else
+                    rc = -EAGAIN;
+                goto param_fail4;
+            }
         }
 
         rc = 0;
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index b11577a..bba747e 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -486,13 +486,18 @@ int paging_log_dirty_range(struct domain *d,
 
     if ( !d->arch.paging.log_dirty.fault_count &&
          !d->arch.paging.log_dirty.dirty_count ) {
-        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
-        unsigned long zeroes[size];
-        memset(zeroes, 0x00, size * BYTES_PER_LONG);
+        static uint8_t zeroes[PAGE_SIZE];
+        int off, size;
+
+        size = ((nr + BITS_PER_LONG - 1) / BITS_PER_LONG) * sizeof (long);
         rv = 0;
-        if ( copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,
-                                  size * BYTES_PER_LONG) != 0 )
-            rv = -EFAULT;
+        for ( off = 0; !rv && off < size; off += sizeof zeroes )
+        {
+            int todo = min(size - off, (int) PAGE_SIZE);
+            if ( copy_to_guest_offset(dirty_bitmap, off, zeroes, todo) )
+                rv = -EFAULT;
+            off += todo;
+        }
         goto out;
     }
     d->arch.paging.log_dirty.fault_count = 0;
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index c9e6057..462df51 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -108,6 +108,9 @@ extern unsigned int trampoline_xen_phys_start;
 extern unsigned char trampoline_cpu_started;
 extern char wakeup_start[];
 extern unsigned int video_mode, video_flags;
+
+#define GB(_gb) (_gb ## UL << 30)
+
 #endif
 
 #define asmlinkage
@@ -123,7 +126,6 @@ extern unsigned int video_mode, video_flags;
 #define PML4_ADDR(_slot)                             \
     ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \
      (_slot ## UL << PML4_ENTRY_BITS))
-#define GB(_gb) (_gb ## UL << 30)
 #else
 #define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)
 #define PML4_ADDR(_slot)                             \
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBq-0003Om-R0; Mon, 11 Feb 2013 13:12: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 1U4tBp-0003O8-OD
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:57 +0000
Received: from [85.158.143.99:27724] by server-3.bemta-4.messagelabs.com id
	1B/FF-08920-95EE8115; Mon, 11 Feb 2013 13:12:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22435 invoked from network); 11 Feb 2013 13:12:56 -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;
	11 Feb 2013 13:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645853"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Vc;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:50 +0000
Message-ID: <1360588373-779-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>
Subject: [Xen-devel] [PATCH 4.0-testing 07/10] ACPI: acpi_table_parse()
	should return handler's error 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

From: Boris Ostrovsky <boris.ostrovsky@amd.com>

Currently, the error code returned by acpi_table_parse()'s handler
is ignored. This patch will propagate handler's return value to
acpi_table_parse()'s caller.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26516:32d4516a97f0
xen-unstable date: Tue Feb  5 14:18:18 UTC 2013
---
 xen/drivers/acpi/tables.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index a25d9b2..151bda6 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -237,7 +237,7 @@ acpi_table_parse_madt(enum acpi_madt_type id,
  * @handler: handler to run
  *
  * Scan the ACPI System Descriptor Table (STD) for a table matching @id,
- * run @handler on it.  Return 0 if table found, return on if not.
+ * run @handler on it.
  */
 int acpi_table_parse(char *id, acpi_table_handler handler)
 {
@@ -252,8 +252,7 @@ int acpi_table_parse(char *id, acpi_table_handler handler)
 		acpi_get_table(id, 0, &table);
 
 	if (table) {
-		handler(table);
-		return 0;
+		return handler(table);
 	} else
 		return 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 Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBv-0003Qq-D7; Mon, 11 Feb 2013 13:13: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 1U4tBs-0003P6-1G
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:13:00 +0000
Received: from [85.158.139.83:49656] by server-7.bemta-5.messagelabs.com id
	B0/4A-11121-B5EE8115; Mon, 11 Feb 2013 13:12:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360588375!24440787!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTc4NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27145 invoked from network); 11 Feb 2013 13:12:58 -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;
	11 Feb 2013 13:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6996117"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-W5;
	Mon, 11 Feb 2013 13:12:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:51 +0000
Message-ID: <1360588373-779-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 08/10] AMD,
	IOMMU: Clean up old entries in remapping tables when creating new
	one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <jbeulich@suse.com>

When changing the affinity of an IRQ associated with a passed
through PCI device, clear previous mapping.

This is XSA-36 / CVE-2013-0153.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

In addition, because some BIOSes may incorrectly program IVRS
entries for IOAPIC try to check for entry's consistency. Specifically,
if conflicting entries are found disable IOMMU if per-device
remapping table is used. If entries refer to bogus IOAPIC IDs
disable IOMMU unconditionally

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
xen-unstable changeset: 26517:601139e2b0db
xen-unstable date: Tue Feb  5 14:20:47 UTC 2013
---
 xen/drivers/passthrough/amd/iommu_acpi.c      |   59 +++++++++++++++++++++++--
 xen/drivers/passthrough/amd/iommu_intr.c      |   40 ++++++++++++++---
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |    5 ++
 3 files changed, 94 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c
index 7905e12..0d6d2a6 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -20,6 +20,8 @@
 
 #include <xen/config.h>
 #include <xen/errno.h>
+#include <asm/apicdef.h>
+#include <asm/io_apic.h>
 #include <asm/amd-iommu.h>
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include <asm/hvm/svm/amd-iommu-acpi.h>
@@ -28,7 +30,6 @@ extern unsigned long amd_iommu_page_entries;
 extern unsigned short ivrs_bdf_entries;
 extern struct ivrs_mappings *ivrs_mappings;
 extern unsigned short last_bdf;
-extern int ioapic_bdf[MAX_IO_APICS];
 extern void *shared_intremap_table;
 
 static void add_ivrs_mapping_entry(
@@ -635,6 +636,7 @@ static u16 __init parse_ivhd_device_special(
     u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
     u16 dev_length, bdf;
+    int apic;
 
     dev_length = sizeof(struct acpi_ivhd_device_special);
     if ( header_length < (block_length + dev_length) )
@@ -651,9 +653,58 @@ static u16 __init parse_ivhd_device_special(
     }
 
     add_ivrs_mapping_entry(bdf, bdf, ivhd_device->header.flags, iommu);
-    /* set device id of ioapic */
-    ioapic_bdf[ivhd_device->special.handle] = bdf;
-    return dev_length;
+
+    if ( ivhd_device->special.variety != 1 /* ACPI_IVHD_IOAPIC */ )
+    {
+        if ( ivhd_device->special.variety != 2 /* ACPI_IVHD_HPET */ )
+            printk(XENLOG_ERR "Unrecognized IVHD special variety %#x\n",
+                   ivhd_device->special.variety);
+        return dev_length;
+    }
+
+    /*
+     * Some BIOSes have IOAPIC broken entries so we check for IVRS
+     * consistency here --- whether entry's IOAPIC ID is valid and
+     * whether there are conflicting/duplicated entries.
+     */
+    for ( apic = 0; apic < nr_ioapics; apic++ )
+    {
+        if ( IO_APIC_ID(apic) != ivhd_device->special.handle )
+            continue;
+
+        if ( ioapic_bdf[ivhd_device->special.handle].pin_setup )
+        {
+            if ( ioapic_bdf[ivhd_device->special.handle].bdf == bdf )
+                AMD_IOMMU_DEBUG("IVHD Warning: Duplicate IO-APIC %#x entries\n",
+                                ivhd_device->special.handle);
+            else
+            {
+                printk(XENLOG_ERR "IVHD Error: Conflicting IO-APIC %#x entries\n",
+                       ivhd_device->special.handle);
+                if ( amd_iommu_perdev_intremap )
+                    return 0;
+            }
+        }
+        else
+        {
+            /* set device id of ioapic */
+            ioapic_bdf[ivhd_device->special.handle].bdf = bdf;
+
+            ioapic_bdf[ivhd_device->special.handle].pin_setup = xzalloc_array(
+                unsigned long, BITS_TO_LONGS(nr_ioapic_registers[apic]));
+            if ( nr_ioapic_registers[apic] &&
+                 !ioapic_bdf[IO_APIC_ID(apic)].pin_setup )
+            {
+                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
+                return 0;
+            }
+        }
+        return dev_length;
+    }
+
+    printk(XENLOG_ERR "IVHD Error: Invalid IO-APIC %#x\n",
+           ivhd_device->special.handle);
+    return 0;
 }
 
 static int __init parse_ivhd_block(struct acpi_ivhd_block_header *ivhd_block)
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index ceb6f47..f8b1bb0 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -26,7 +26,7 @@
 #define INTREMAP_LENGTH 0xB
 #define INTREMAP_ENTRIES (1 << INTREMAP_LENGTH)
 
-int ioapic_bdf[MAX_IO_APICS];
+struct ioapic_bdf ioapic_bdf[MAX_IO_APICS];
 extern struct ivrs_mappings *ivrs_mappings;
 extern unsigned short ivrs_bdf_entries;
 void *shared_intremap_table;
@@ -116,12 +116,12 @@ void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
 static void update_intremap_entry_from_ioapic(
     int bdf,
     struct amd_iommu *iommu,
-    struct IO_APIC_route_entry *ioapic_rte)
+    const struct IO_APIC_route_entry *rte,
+    const struct IO_APIC_route_entry *old_rte)
 {
     unsigned long flags;
     u32* entry;
     u8 delivery_mode, dest, vector, dest_mode;
-    struct IO_APIC_route_entry *rte = ioapic_rte;
     int req_id;
     spinlock_t *lock;
     int offset;
@@ -137,6 +137,14 @@ static void update_intremap_entry_from_ioapic(
     spin_lock_irqsave(lock, flags);
 
     offset = get_intremap_offset(vector, delivery_mode);
+    if ( old_rte )
+    {
+        int old_offset = get_intremap_offset(old_rte->vector,
+                                             old_rte->delivery_mode);
+
+        if ( offset != old_offset )
+            free_intremap_entry(bdf, old_offset);
+    }
     entry = (u32*)get_intremap_entry(req_id, offset);
     update_intremap_entry(entry, vector, delivery_mode, dest_mode, dest);
 
@@ -175,7 +183,7 @@ int __init amd_iommu_setup_ioapic_remapping(void)
                 continue;
 
             /* get device id of ioapic devices */
-            bdf = ioapic_bdf[IO_APIC_ID(apic)];
+            bdf = ioapic_bdf[IO_APIC_ID(apic)].bdf;
             iommu = find_iommu_for_device(bdf);
             if ( !iommu )
             {
@@ -206,6 +214,7 @@ int __init amd_iommu_setup_ioapic_remapping(void)
                 flush_command_buffer(iommu);
                 spin_unlock_irqrestore(&iommu->lock, flags);
             }
+            set_bit(pin, ioapic_bdf[IO_APIC_ID(apic)].pin_setup);
         }
     }
     return 0;
@@ -217,6 +226,7 @@ void amd_iommu_ioapic_update_ire(
     struct IO_APIC_route_entry old_rte = { 0 };
     struct IO_APIC_route_entry new_rte = { 0 };
     unsigned int rte_lo = (reg & 1) ? reg - 1 : reg;
+    unsigned int pin = (reg - 0x10) / 2;
     int saved_mask, bdf;
     struct amd_iommu *iommu;
 
@@ -227,7 +237,7 @@ void amd_iommu_ioapic_update_ire(
     }
 
     /* get device id of ioapic devices */
-    bdf = ioapic_bdf[IO_APIC_ID(apic)];
+    bdf = ioapic_bdf[IO_APIC_ID(apic)].bdf;
     iommu = find_iommu_for_device(bdf);
     if ( !iommu )
     {
@@ -253,6 +263,14 @@ void amd_iommu_ioapic_update_ire(
         *(((u32 *)&new_rte) + 1) = value;
     }
 
+    if ( new_rte.mask &&
+         !test_bit(pin, ioapic_bdf[IO_APIC_ID(apic)].pin_setup) )
+    {
+        ASSERT(saved_mask);
+        __io_apic_write(apic, reg, value);
+        return;
+    }
+
     /* mask the interrupt while we change the intremap table */
     if ( !saved_mask )
     {
@@ -261,7 +279,11 @@ void amd_iommu_ioapic_update_ire(
     }
 
     /* Update interrupt remapping entry */
-    update_intremap_entry_from_ioapic(bdf, iommu, &new_rte);
+    update_intremap_entry_from_ioapic(
+        bdf, iommu, &new_rte,
+        test_and_set_bit(pin,
+                         ioapic_bdf[IO_APIC_ID(apic)].pin_setup) ? &old_rte
+                                                                 : NULL);
 
     /* Forward write access to IO-APIC RTE */
     __io_apic_write(apic, reg, value);
@@ -373,6 +395,12 @@ void amd_iommu_msi_msg_update_ire(
         return;
     }
 
+    if ( msi_desc->remap_index >= 0 )
+        update_intremap_entry_from_msi_msg(iommu, pdev, msi_desc, NULL);
+
+    if ( !msg )
+        return;
+
     update_intremap_entry_from_msi_msg(iommu, pdev, msi_desc, msg);
 }
 
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 5539636..bbe763d 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -89,6 +89,11 @@ void amd_iommu_read_msi_from_ire(
 unsigned int amd_iommu_read_ioapic_from_ire(
     unsigned int apic, unsigned int reg);
 
+extern struct ioapic_bdf {
+    u16 bdf;
+    unsigned long *pin_setup;
+} ioapic_bdf[];
+
 /* power management support */
 void amd_iommu_resume(void);
 void amd_iommu_suspend(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 Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBu-0003Q9-BO; Mon, 11 Feb 2013 13:13: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 1U4tBr-0003O8-0F
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:59 +0000
Received: from [85.158.143.99:30720] by server-3.bemta-4.messagelabs.com id
	EC/00-08920-A5EE8115; Mon, 11 Feb 2013 13:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22512 invoked from network); 11 Feb 2013 13:12:57 -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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645855"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-TK;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:48 +0000
Message-ID: <1360588373-779-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 05/10] VT-d: fix interrupt remapping
	source validation for devices behind legacy bridges
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <jbeulich@suse.com>

Using SVT_VERIFY_BUS here doesn't make sense; native Linux also
uses SVT_VERIFY_SID_SQ here instead.

This is XSA-33 / CVE-2012-5634.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26340:19fd1237ff0d
xen-unstable date: Wed Jan  9 16:13:26 UTC 2013
---
 xen/drivers/passthrough/vtd/intremap.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrough/vtd/intremap.c
index 006fdd9..663c1d0 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -502,7 +502,7 @@ static void set_msi_source_id(struct pci_dev *pdev, struct iremap_entry *ire)
                 set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16,
                             (bus << 8) | pdev->bus);
             else if ( pdev_type(bus, devfn) == DEV_TYPE_LEGACY_PCI_BRIDGE )
-                set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16,
+                set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_ALL_16,
                             PCI_BDF2(bus, devfn));
         }
         break;
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBt-0003Pj-4T; Mon, 11 Feb 2013 13:13: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 1U4tBq-0003O8-HB
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:58 +0000
Received: from [85.158.143.99:30694] by server-3.bemta-4.messagelabs.com id
	9B/00-08920-A5EE8115; Mon, 11 Feb 2013 13:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22460 invoked from network); 11 Feb 2013 13:12:57 -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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645854"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Qy;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:46 +0000
Message-ID: <1360588373-779-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 03/10] hvm: Limit the size of large
	HVM op batches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

Doing large p2m updates for HVMOP_track_dirty_vram without preemption
ties up the physical processor. Integrating preemption into the p2m
updates is hard so simply limit to 1GB which is sufficient for a 15000
* 15000 * 32bpp framebuffer.

For HVMOP_modified_memory and HVMOP_set_mem_type preemptible add the
necessary machinery to handle preemption.

This is CVE-2012-5511 / XSA-27.

Signed-off-by: Tim Deegan <tim@xen.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>

x86/paging: Don't allocate user-controlled amounts of stack memory.

This is XSA-27 / CVE-2012-5511.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
v2: Provide definition of GB to fix x86-32 compile.

Signed-off-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 xen/arch/x86/hvm/hvm.c       |   37 +++++++++++++++++++++++++++++++++----
 xen/arch/x86/mm/paging.c     |   17 +++++++++++------
 xen/include/asm-x86/config.h |    4 +++-
 3 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 640969b..1ab0ec6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2943,6 +2943,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !is_hvm_domain(d) )
             goto param_fail2;
 
+        if ( a.nr > GB(1) >> PAGE_SHIFT )
+            goto param_fail2;
+
         rc = xsm_hvm_param(d, op);
         if ( rc )
             goto param_fail2;
@@ -2969,7 +2972,6 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
     {
         struct xen_hvm_modified_memory a;
         struct domain *d;
-        unsigned long pfn;
 
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
@@ -2996,8 +2998,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( !paging_mode_log_dirty(d) )
             goto param_fail3;
 
-        for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
+        while ( a.nr > 0 )
         {
+            unsigned long pfn = a.first_pfn;
             p2m_type_t t;
             mfn_t mfn = gfn_to_mfn(d, pfn, &t);
             if ( p2m_is_paging(t) )
@@ -3018,6 +3021,19 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                 /* don't take a long time and don't die either */
                 sh_remove_shadows(d->vcpu[0], mfn, 1, 0);
             }
+
+            a.first_pfn++;
+            a.nr--;
+
+            /* Check for continuation if it's not the last interation */
+            if ( a.nr > 0 && hypercall_preempt_check() )
+            {
+                if ( copy_to_guest(arg, &a, 1) )
+                    rc = -EFAULT;
+                else
+                    rc = -EAGAIN;
+                break;
+            }
         }
 
     param_fail3:
@@ -3029,7 +3045,6 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
     {
         struct xen_hvm_set_mem_type a;
         struct domain *d;
-        unsigned long pfn;
         
         /* Interface types to internal p2m types */
         p2m_type_t memtype[] = {
@@ -3062,8 +3077,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
             goto param_fail4;
 
-        for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
+        while ( a.nr > 0 )
         {
+            unsigned long pfn = a.first_pfn;
             p2m_type_t t;
             p2m_type_t nt;
             mfn_t mfn;
@@ -3099,6 +3115,19 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
                     goto param_fail4;
                 }
             }
+
+            a.first_pfn++;
+            a.nr--;
+
+            /* Check for continuation if it's not the last interation */
+            if ( a.nr > 0 && hypercall_preempt_check() )
+            {
+                if ( copy_to_guest(arg, &a, 1) )
+                    rc = -EFAULT;
+                else
+                    rc = -EAGAIN;
+                goto param_fail4;
+            }
         }
 
         rc = 0;
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index b11577a..bba747e 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -486,13 +486,18 @@ int paging_log_dirty_range(struct domain *d,
 
     if ( !d->arch.paging.log_dirty.fault_count &&
          !d->arch.paging.log_dirty.dirty_count ) {
-        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
-        unsigned long zeroes[size];
-        memset(zeroes, 0x00, size * BYTES_PER_LONG);
+        static uint8_t zeroes[PAGE_SIZE];
+        int off, size;
+
+        size = ((nr + BITS_PER_LONG - 1) / BITS_PER_LONG) * sizeof (long);
         rv = 0;
-        if ( copy_to_guest_offset(dirty_bitmap, 0, (uint8_t *) zeroes,
-                                  size * BYTES_PER_LONG) != 0 )
-            rv = -EFAULT;
+        for ( off = 0; !rv && off < size; off += sizeof zeroes )
+        {
+            int todo = min(size - off, (int) PAGE_SIZE);
+            if ( copy_to_guest_offset(dirty_bitmap, off, zeroes, todo) )
+                rv = -EFAULT;
+            off += todo;
+        }
         goto out;
     }
     d->arch.paging.log_dirty.fault_count = 0;
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index c9e6057..462df51 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -108,6 +108,9 @@ extern unsigned int trampoline_xen_phys_start;
 extern unsigned char trampoline_cpu_started;
 extern char wakeup_start[];
 extern unsigned int video_mode, video_flags;
+
+#define GB(_gb) (_gb ## UL << 30)
+
 #endif
 
 #define asmlinkage
@@ -123,7 +126,6 @@ extern unsigned int video_mode, video_flags;
 #define PML4_ADDR(_slot)                             \
     ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \
      (_slot ## UL << PML4_ENTRY_BITS))
-#define GB(_gb) (_gb ## UL << 30)
 #else
 #define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)
 #define PML4_ADDR(_slot)                             \
-- 
1.7.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 Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBq-0003Om-R0; Mon, 11 Feb 2013 13:12: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 1U4tBp-0003O8-OD
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:57 +0000
Received: from [85.158.143.99:27724] by server-3.bemta-4.messagelabs.com id
	1B/FF-08920-95EE8115; Mon, 11 Feb 2013 13:12:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22435 invoked from network); 11 Feb 2013 13:12:56 -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;
	11 Feb 2013 13:12:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645853"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-Vc;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:50 +0000
Message-ID: <1360588373-779-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>
Subject: [Xen-devel] [PATCH 4.0-testing 07/10] ACPI: acpi_table_parse()
	should return handler's error 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

From: Boris Ostrovsky <boris.ostrovsky@amd.com>

Currently, the error code returned by acpi_table_parse()'s handler
is ignored. This patch will propagate handler's return value to
acpi_table_parse()'s caller.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26516:32d4516a97f0
xen-unstable date: Tue Feb  5 14:18:18 UTC 2013
---
 xen/drivers/acpi/tables.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index a25d9b2..151bda6 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -237,7 +237,7 @@ acpi_table_parse_madt(enum acpi_madt_type id,
  * @handler: handler to run
  *
  * Scan the ACPI System Descriptor Table (STD) for a table matching @id,
- * run @handler on it.  Return 0 if table found, return on if not.
+ * run @handler on it.
  */
 int acpi_table_parse(char *id, acpi_table_handler handler)
 {
@@ -252,8 +252,7 @@ int acpi_table_parse(char *id, acpi_table_handler handler)
 		acpi_get_table(id, 0, &table);
 
 	if (table) {
-		handler(table);
-		return 0;
+		return handler(table);
 	} else
 		return 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 Mon Feb 11 13:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13: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 1U4tBu-0003Q9-BO; Mon, 11 Feb 2013 13:13: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 1U4tBr-0003O8-0F
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:12:59 +0000
Received: from [85.158.143.99:30720] by server-3.bemta-4.messagelabs.com id
	EC/00-08920-A5EE8115; Mon, 11 Feb 2013 13:12:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360588374!24776602!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22512 invoked from network); 11 Feb 2013 13:12:57 -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;
	11 Feb 2013 13:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645855"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-TK;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:48 +0000
Message-ID: <1360588373-779-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 4.0-testing 05/10] VT-d: fix interrupt remapping
	source validation for devices behind legacy bridges
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <jbeulich@suse.com>

Using SVT_VERIFY_BUS here doesn't make sense; native Linux also
uses SVT_VERIFY_SID_SQ here instead.

This is XSA-33 / CVE-2012-5634.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 26340:19fd1237ff0d
xen-unstable date: Wed Jan  9 16:13:26 UTC 2013
---
 xen/drivers/passthrough/vtd/intremap.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrough/vtd/intremap.c
index 006fdd9..663c1d0 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -502,7 +502,7 @@ static void set_msi_source_id(struct pci_dev *pdev, struct iremap_entry *ire)
                 set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16,
                             (bus << 8) | pdev->bus);
             else if ( pdev_type(bus, devfn) == DEV_TYPE_LEGACY_PCI_BRIDGE )
-                set_ire_sid(ire, SVT_VERIFY_BUS, SQ_ALL_16,
+                set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_ALL_16,
                             PCI_BDF2(bus, devfn));
         }
         break;
-- 
1.7.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 Feb 11 13:13:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13:13: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 1U4tBy-0003SW-QC; Mon, 11 Feb 2013 13:13:06 +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 1U4tBw-0003RL-Vy
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:13:05 +0000
Received: from [85.158.137.99:48254] by server-9.bemta-3.messagelabs.com id
	47/AC-09484-B5EE8115; Mon, 11 Feb 2013 13:12:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360588376!17494154!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4311 invoked from network); 11 Feb 2013 13:12:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645856"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-QF;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:45 +0000
Message-ID: <1360588373-779-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4.0-testing 02/10] libxc: builder: limit maximum
	size of kernel/ramdisk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <Ian.Jackson@eu.citrix.com>

Allowing user supplied kernels of arbitrary sizes, especially during
decompression, can swallow up dom0 memory leading to either virtual
address space exhaustion in the builder process or allocation
failures/OOM killing of both toolstack and unrelated processes.

We disable these checks when building in a stub domain for pvgrub
since this uses the guest's own memory and is isolated.

Decompression of gzip compressed kernels and ramdisks has been safe
since 14954:58205257517d (Xen 3.1.0 onwards).

This is XSA-25 / CVE-2012-4544.

Also make explicit checks for buffer overflows in various
decompression routines. These were already ruled out due to other
properties of the code but check them as a belt-and-braces measure.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
---
 stubdom/grub/kexec.c                    |    4 ++
 tools/libxc/xc_dom.h                    |   23 +++++++++-
 tools/libxc/xc_dom_bzimageloader.c      |   44 ++++++++++++++++--
 tools/libxc/xc_dom_core.c               |   78 +++++++++++++++++++++++++++++--
 tools/pygrub/src/pygrub                 |   55 +++++++++++++++++----
 tools/python/xen/xm/messages/xen-xm.pot |    3 +-
 6 files changed, 186 insertions(+), 21 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 821c71d..f3f1b7b 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -137,6 +137,10 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     dom = xc_dom_allocate(cmdline, features);
     dom->allocate = kexec_allocate;
 
+    /* We are using guest owned memory, therefore no limits. */
+    xc_dom_kernel_max_size(dom, 0);
+    xc_dom_ramdisk_max_size(dom, 0);
+
     dom->kernel_blob = kernel;
     dom->kernel_size = kernel_size;
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 58d3f49..71ffa1e 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -36,6 +36,9 @@ struct xc_dom_image {
     void *ramdisk_blob;
     size_t ramdisk_size;
 
+    size_t max_kernel_size;
+    size_t max_ramdisk_size;
+
     /* arguments and parameters */
     char *cmdline;
     uint32_t f_requested[XENFEAT_NR_SUBMAPS];
@@ -158,6 +161,23 @@ void xc_dom_release_phys(struct xc_dom_image *dom);
 void xc_dom_release(struct xc_dom_image *dom);
 int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb);
 
+/* Set this larger if you have enormous ramdisks/kernels. Note that
+ * you should trust all kernels not to be maliciously large (e.g. to
+ * exhaust all dom0 memory) if you do this (see CVE-2012-4544 /
+ * XSA-25). You can also set the default independently for
+ * ramdisks/kernels in xc_dom_allocate() or call
+ * xc_dom_{kernel,ramdisk}_max_size.
+ */
+#ifndef XC_DOM_DECOMPRESS_MAX
+#define XC_DOM_DECOMPRESS_MAX (1024*1024*1024) /* 1GB */
+#endif
+
+int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
+int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
+
+int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz);
+int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
+
 size_t xc_dom_check_gzip(void *blob, size_t ziplen);
 int xc_dom_do_gunzip(void *src, size_t srclen, void *dst, size_t dstlen);
 int xc_dom_try_gunzip(struct xc_dom_image *dom, void **blob, size_t * size);
@@ -202,7 +222,8 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
-                            const char *filename, size_t * size);
+                            const char *filename, size_t * size,
+                            const size_t max_size);
 char *xc_dom_strdup(struct xc_dom_image *dom, const char *str);
 
 /* --- alloc memory pool ------------------------------------------- */
diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index aa5abc7..3aaf827 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -33,13 +33,19 @@ static int xc_try_bzip2_decode(
     char *out_buf;
     char *tmp_buf;
     int retval = -1;
-    int outsize;
+    unsigned int outsize;
     uint64_t total;
 
     stream.bzalloc = NULL;
     stream.bzfree = NULL;
     stream.opaque = NULL;
 
+    if ( dom->kernel_size == 0)
+    {
+        xc_dom_printf("BZIP2: Input is 0 size");
+        return -1;
+    }
+
     ret = BZ2_bzDecompressInit(&stream, 0, 0);
     if ( ret != BZ_OK )
     {
@@ -52,6 +58,17 @@ static int xc_try_bzip2_decode(
      * the input buffer to start, and we'll realloc as needed.
      */
     outsize = dom->kernel_size;
+
+    /*
+     * stream.avail_in and outsize are unsigned int, while kernel_size
+     * is a size_t. Check we aren't overflowing.
+     */
+    if ( outsize != dom->kernel_size )
+    {
+        xc_dom_printf("BZIP2: Input too large");
+        goto bzip2_cleanup;
+    }
+
     out_buf = malloc(outsize);
     if ( out_buf == NULL )
     {
@@ -84,13 +101,20 @@ static int xc_try_bzip2_decode(
         if ( stream.avail_out == 0 )
         {
             /* Protect against output buffer overflow */
-            if ( outsize > INT_MAX / 2 )
+            if ( outsize > UINT_MAX / 2 )
             {
                 xc_dom_printf("BZIP2: output buffer overflow\n");
                 free(out_buf);
                 goto bzip2_cleanup;
             }
 
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                xc_dom_printf("BZIP2: output too large");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+
             tmp_buf = realloc(out_buf, outsize * 2);
             if ( tmp_buf == NULL )
             {
@@ -158,10 +182,15 @@ static int xc_try_lzma_decode(
     unsigned char *out_buf;
     unsigned char *tmp_buf;
     int retval = -1;
-    int outsize;
+    size_t outsize;
     const char *msg;
 
     ret = lzma_alone_decoder(&stream, 32*1024*1024);
+    if ( dom->kernel_size == 0)
+    {
+        xc_dom_printf("LZMA: Input is 0 size");
+        return -1;
+    }
     if ( ret != LZMA_OK )
     {
         xc_dom_printf("LZMA: Failed to init stream decoder\n");
@@ -237,13 +266,20 @@ static int xc_try_lzma_decode(
         if ( stream.avail_out == 0 )
         {
             /* Protect against output buffer overflow */
-            if ( outsize > INT_MAX / 2 )
+            if ( outsize > SIZE_MAX / 2 )
             {
                 xc_dom_printf("LZMA: output buffer overflow\n");
                 free(out_buf);
                 goto lzma_cleanup;
             }
 
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                xc_dom_printf("LZMA: output too large");
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+
             tmp_buf = realloc(out_buf, outsize * 2);
             if ( tmp_buf == NULL )
             {
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index df8e83b..6770302 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -139,7 +139,8 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
-                            const char *filename, size_t * size)
+                            const char *filename, size_t * size,
+                            const size_t max_size)
 {
     struct xc_dom_mem *block = NULL;
     int fd = -1;
@@ -151,6 +152,13 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
     lseek(fd, 0, SEEK_SET);
     *size = lseek(fd, 0, SEEK_END);
 
+    if ( max_size && *size > max_size )
+    {
+        xc_dom_panic(XC_OUT_OF_MEMORY,
+                     "tried to map file which is too large");
+        goto err;
+    }
+
     block = malloc(sizeof(*block));
     if ( block == NULL )
         goto err;
@@ -202,6 +210,40 @@ char *xc_dom_strdup(struct xc_dom_image *dom, const char *str)
 }
 
 /* ------------------------------------------------------------------------ */
+/* decompression buffer sizing                                              */
+int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz)
+{
+    /* No limit */
+    if ( !dom->max_kernel_size )
+        return 0;
+
+    if ( sz > dom->max_kernel_size )
+    {
+        xc_dom_panic(XC_INVALID_KERNEL,
+                     "kernel image too large");
+        return 1;
+    }
+
+    return 0;
+}
+
+int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz)
+{
+    /* No limit */
+    if ( !dom->max_ramdisk_size )
+        return 0;
+
+    if ( sz > dom->max_ramdisk_size )
+    {
+        xc_dom_panic(XC_INVALID_KERNEL,
+                     "ramdisk image too large");
+        return 1;
+    }
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
 /* read files, copy memory blocks, with transparent gunzip                  */
 
 size_t xc_dom_check_gzip(void *blob, size_t ziplen)
@@ -215,7 +257,7 @@ size_t xc_dom_check_gzip(void *blob, size_t ziplen)
 
     gzlen = blob + ziplen - 4;
     unziplen = gzlen[3] << 24 | gzlen[2] << 16 | gzlen[1] << 8 | gzlen[0];
-    if ( (unziplen < 0) || (unziplen > (1024*1024*1024)) ) /* 1GB limit */
+    if ( (unziplen < 0) || (unziplen > XC_DOM_DECOMPRESS_MAX) )
     {
         xc_dom_printf
             ("%s: size (zip %zd, unzip %zd) looks insane, skip gunzip\n",
@@ -266,6 +308,9 @@ int xc_dom_try_gunzip(struct xc_dom_image *dom, void **blob, size_t * size)
     if ( unziplen == 0 )
         return 0;
 
+    if ( xc_dom_kernel_check_size(dom, unziplen) )
+        return 0;
+
     unzip = xc_dom_malloc(dom, unziplen);
     if ( unzip == NULL )
         return -1;
@@ -562,6 +607,10 @@ struct xc_dom_image *xc_dom_allocate(const char *cmdline, const char *features)
         goto err;
 
     memset(dom, 0, sizeof(*dom));
+
+    dom->max_kernel_size = XC_DOM_DECOMPRESS_MAX;
+    dom->max_ramdisk_size = XC_DOM_DECOMPRESS_MAX;
+
     if ( cmdline )
         dom->cmdline = xc_dom_strdup(dom, cmdline);
     if ( features )
@@ -582,10 +631,25 @@ struct xc_dom_image *xc_dom_allocate(const char *cmdline, const char *features)
     return NULL;
 }
 
+int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz)
+{
+    xc_dom_printf("%s: kernel_max_size=%zx", __FUNCTION__, sz);
+    dom->max_kernel_size = sz;
+    return 0;
+}
+
+int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz)
+{
+    xc_dom_printf("%s: ramdisk_max_size=%zx", __FUNCTION__, sz);
+    dom->max_ramdisk_size = sz;
+    return 0;
+}
+
 int xc_dom_kernel_file(struct xc_dom_image *dom, const char *filename)
 {
     xc_dom_printf("%s: filename=\"%s\"\n", __FUNCTION__, filename);
-    dom->kernel_blob = xc_dom_malloc_filemap(dom, filename, &dom->kernel_size);
+    dom->kernel_blob = xc_dom_malloc_filemap(dom, filename, &dom->kernel_size,
+                                             dom->max_kernel_size);
     if ( dom->kernel_blob == NULL )
         return -1;
     return xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size);
@@ -595,7 +659,9 @@ int xc_dom_ramdisk_file(struct xc_dom_image *dom, const char *filename)
 {
     xc_dom_printf("%s: filename=\"%s\"\n", __FUNCTION__, filename);
     dom->ramdisk_blob =
-        xc_dom_malloc_filemap(dom, filename, &dom->ramdisk_size);
+        xc_dom_malloc_filemap(dom, filename, &dom->ramdisk_size,
+                              dom->max_ramdisk_size);
+
     if ( dom->ramdisk_blob == NULL )
         return -1;
 //    return xc_dom_try_gunzip(dom, &dom->ramdisk_blob, &dom->ramdisk_size);
@@ -755,7 +821,11 @@ int xc_dom_build_image(struct xc_dom_image *dom)
         void *ramdiskmap;
 
         unziplen = xc_dom_check_gzip(dom->ramdisk_blob, dom->ramdisk_size);
+        if ( xc_dom_ramdisk_check_size(dom, unziplen) != 0 )
+            unziplen = 0;
+
         ramdisklen = unziplen ? unziplen : dom->ramdisk_size;
+
         if ( xc_dom_alloc_segment(dom, &dom->ramdisk_seg, "ramdisk", 0,
                                   ramdisklen) != 0 )
             goto err;
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index e52df7b..93b0cac 100644
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -28,6 +28,7 @@ import grub.LiloConf
 import grub.ExtLinuxConf
 
 PYGRUB_VER = 0.6
+FS_READ_MAX = 1024 * 1024
 
 def enable_cursor(ison):
     if ison:
@@ -407,7 +408,8 @@ class Grub:
         if self.__dict__.get('cf', None) is None:
             raise RuntimeError, "couldn't find bootloader config file in the image provided."
         f = fs.open_file(self.cf.filename)
-        buf = f.read()
+        # limit read size to avoid pathological cases
+        buf = f.read(FS_READ_MAX)
         del f
         self.cf.parse(buf)
 
@@ -633,6 +635,37 @@ if __name__ == "__main__":
     def usage():
         print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] <image>" %(sys.argv[0],)
 
+    def copy_from_image(fs, file_to_read, file_type, output_directory,
+                        not_really):
+        if not_really:
+            if fs.file_exists(file_to_read):
+                return "<%s:%s>" % (file_type, file_to_read)
+            else:
+                sys.exit("The requested %s file does not exist" % file_type)
+        try:
+            datafile = fs.open_file(file_to_read)
+        except Exception, e:
+            print >>sys.stderr, e
+            sys.exit("Error opening %s in guest" % file_to_read)
+        (tfd, ret) = tempfile.mkstemp(prefix="boot_"+file_type+".",
+                                      dir=output_directory)
+        dataoff = 0
+        while True:
+            data = datafile.read(FS_READ_MAX, dataoff)
+            if len(data) == 0:
+                os.close(tfd)
+                del datafile
+                return ret
+            try:
+                os.write(tfd, data)
+            except Exception, e:
+                print >>sys.stderr, e
+                os.close(tfd)
+                os.unlink(ret)
+                del datafile
+                sys.exit("Error writing temporary copy of "+file_type)
+            dataoff += len(data)
+
     try:
         opts, args = getopt.gnu_getopt(sys.argv[1:], 'qih::',
                                    ["quiet", "interactive", "help", "output=",
@@ -712,18 +745,18 @@ if __name__ == "__main__":
     if not chosencfg["kernel"]:
         chosencfg = run_grub(file, entry, fs, incfg["args"])
 
-    data = fs.open_file(chosencfg["kernel"]).read()
-    (tfd, bootcfg["kernel"]) = tempfile.mkstemp(prefix="boot_kernel.",
-        dir="/var/run/xend/boot")
-    os.write(tfd, data)
-    os.close(tfd)
+    bootcfg["kernel"] = copy_from_image(fs, chosencfg["kernel"], "kernel",
+                                        output_directory, not_really)
 
     if chosencfg["ramdisk"]:
-        data = fs.open_file(chosencfg["ramdisk"],).read()
-        (tfd, bootcfg["ramdisk"]) = tempfile.mkstemp(prefix="boot_ramdisk.",
-            dir="/var/run/xend/boot")
-        os.write(tfd, data)
-        os.close(tfd)
+        try:
+            bootcfg["ramdisk"] = copy_from_image(fs, chosencfg["ramdisk"],
+                                                 "ramdisk", output_directory,
+                                                 not_really)
+        except:
+            if not not_really:
+                os.unlink(bootcfg["kernel"])
+            raise
     else:
         initrd = None
 
diff --git a/tools/python/xen/xm/messages/xen-xm.pot b/tools/python/xen/xm/messages/xen-xm.pot
index a600a69..3d381f1 100644
--- a/tools/python/xen/xm/messages/xen-xm.pot
+++ b/tools/python/xen/xm/messages/xen-xm.pot
@@ -8,10 +8,11 @@ msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-03-31 17:40+0100\n"
+"POT-Creation-Date: 2013-02-07 10:25+0000\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
+"Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=CHARSET\n"
 "Content-Transfer-Encoding: 8bit\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 Mon Feb 11 13:13:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 13:13: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 1U4tBy-0003SW-QC; Mon, 11 Feb 2013 13:13:06 +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 1U4tBw-0003RL-Vy
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:13:05 +0000
Received: from [85.158.137.99:48254] by server-9.bemta-3.messagelabs.com id
	47/AC-09484-B5EE8115; Mon, 11 Feb 2013 13:12:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360588376!17494154!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4311 invoked from network); 11 Feb 2013 13:12:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:12:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6645856"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 13:12:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 08:12:54 -0500
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 1U4tBl-0005mc-QF;
	Mon, 11 Feb 2013 13:12:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 11 Feb 2013 13:12:45 +0000
Message-ID: <1360588373-779-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4.0-testing 02/10] libxc: builder: limit maximum
	size of kernel/ramdisk.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 <Ian.Jackson@eu.citrix.com>

Allowing user supplied kernels of arbitrary sizes, especially during
decompression, can swallow up dom0 memory leading to either virtual
address space exhaustion in the builder process or allocation
failures/OOM killing of both toolstack and unrelated processes.

We disable these checks when building in a stub domain for pvgrub
since this uses the guest's own memory and is isolated.

Decompression of gzip compressed kernels and ramdisks has been safe
since 14954:58205257517d (Xen 3.1.0 onwards).

This is XSA-25 / CVE-2012-4544.

Also make explicit checks for buffer overflows in various
decompression routines. These were already ruled out due to other
properties of the code but check them as a belt-and-braces measure.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
---
 stubdom/grub/kexec.c                    |    4 ++
 tools/libxc/xc_dom.h                    |   23 +++++++++-
 tools/libxc/xc_dom_bzimageloader.c      |   44 ++++++++++++++++--
 tools/libxc/xc_dom_core.c               |   78 +++++++++++++++++++++++++++++--
 tools/pygrub/src/pygrub                 |   55 +++++++++++++++++----
 tools/python/xen/xm/messages/xen-xm.pot |    3 +-
 6 files changed, 186 insertions(+), 21 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 821c71d..f3f1b7b 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -137,6 +137,10 @@ void kexec(void *kernel, long kernel_size, void *module, long module_size, char
     dom = xc_dom_allocate(cmdline, features);
     dom->allocate = kexec_allocate;
 
+    /* We are using guest owned memory, therefore no limits. */
+    xc_dom_kernel_max_size(dom, 0);
+    xc_dom_ramdisk_max_size(dom, 0);
+
     dom->kernel_blob = kernel;
     dom->kernel_size = kernel_size;
 
diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index 58d3f49..71ffa1e 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -36,6 +36,9 @@ struct xc_dom_image {
     void *ramdisk_blob;
     size_t ramdisk_size;
 
+    size_t max_kernel_size;
+    size_t max_ramdisk_size;
+
     /* arguments and parameters */
     char *cmdline;
     uint32_t f_requested[XENFEAT_NR_SUBMAPS];
@@ -158,6 +161,23 @@ void xc_dom_release_phys(struct xc_dom_image *dom);
 void xc_dom_release(struct xc_dom_image *dom);
 int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb);
 
+/* Set this larger if you have enormous ramdisks/kernels. Note that
+ * you should trust all kernels not to be maliciously large (e.g. to
+ * exhaust all dom0 memory) if you do this (see CVE-2012-4544 /
+ * XSA-25). You can also set the default independently for
+ * ramdisks/kernels in xc_dom_allocate() or call
+ * xc_dom_{kernel,ramdisk}_max_size.
+ */
+#ifndef XC_DOM_DECOMPRESS_MAX
+#define XC_DOM_DECOMPRESS_MAX (1024*1024*1024) /* 1GB */
+#endif
+
+int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
+int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
+
+int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz);
+int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz);
+
 size_t xc_dom_check_gzip(void *blob, size_t ziplen);
 int xc_dom_do_gunzip(void *src, size_t srclen, void *dst, size_t dstlen);
 int xc_dom_try_gunzip(struct xc_dom_image *dom, void **blob, size_t * size);
@@ -202,7 +222,8 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom);
 void *xc_dom_malloc(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size);
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
-                            const char *filename, size_t * size);
+                            const char *filename, size_t * size,
+                            const size_t max_size);
 char *xc_dom_strdup(struct xc_dom_image *dom, const char *str);
 
 /* --- alloc memory pool ------------------------------------------- */
diff --git a/tools/libxc/xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c
index aa5abc7..3aaf827 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -33,13 +33,19 @@ static int xc_try_bzip2_decode(
     char *out_buf;
     char *tmp_buf;
     int retval = -1;
-    int outsize;
+    unsigned int outsize;
     uint64_t total;
 
     stream.bzalloc = NULL;
     stream.bzfree = NULL;
     stream.opaque = NULL;
 
+    if ( dom->kernel_size == 0)
+    {
+        xc_dom_printf("BZIP2: Input is 0 size");
+        return -1;
+    }
+
     ret = BZ2_bzDecompressInit(&stream, 0, 0);
     if ( ret != BZ_OK )
     {
@@ -52,6 +58,17 @@ static int xc_try_bzip2_decode(
      * the input buffer to start, and we'll realloc as needed.
      */
     outsize = dom->kernel_size;
+
+    /*
+     * stream.avail_in and outsize are unsigned int, while kernel_size
+     * is a size_t. Check we aren't overflowing.
+     */
+    if ( outsize != dom->kernel_size )
+    {
+        xc_dom_printf("BZIP2: Input too large");
+        goto bzip2_cleanup;
+    }
+
     out_buf = malloc(outsize);
     if ( out_buf == NULL )
     {
@@ -84,13 +101,20 @@ static int xc_try_bzip2_decode(
         if ( stream.avail_out == 0 )
         {
             /* Protect against output buffer overflow */
-            if ( outsize > INT_MAX / 2 )
+            if ( outsize > UINT_MAX / 2 )
             {
                 xc_dom_printf("BZIP2: output buffer overflow\n");
                 free(out_buf);
                 goto bzip2_cleanup;
             }
 
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                xc_dom_printf("BZIP2: output too large");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+
             tmp_buf = realloc(out_buf, outsize * 2);
             if ( tmp_buf == NULL )
             {
@@ -158,10 +182,15 @@ static int xc_try_lzma_decode(
     unsigned char *out_buf;
     unsigned char *tmp_buf;
     int retval = -1;
-    int outsize;
+    size_t outsize;
     const char *msg;
 
     ret = lzma_alone_decoder(&stream, 32*1024*1024);
+    if ( dom->kernel_size == 0)
+    {
+        xc_dom_printf("LZMA: Input is 0 size");
+        return -1;
+    }
     if ( ret != LZMA_OK )
     {
         xc_dom_printf("LZMA: Failed to init stream decoder\n");
@@ -237,13 +266,20 @@ static int xc_try_lzma_decode(
         if ( stream.avail_out == 0 )
         {
             /* Protect against output buffer overflow */
-            if ( outsize > INT_MAX / 2 )
+            if ( outsize > SIZE_MAX / 2 )
             {
                 xc_dom_printf("LZMA: output buffer overflow\n");
                 free(out_buf);
                 goto lzma_cleanup;
             }
 
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                xc_dom_printf("LZMA: output too large");
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+
             tmp_buf = realloc(out_buf, outsize * 2);
             if ( tmp_buf == NULL )
             {
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index df8e83b..6770302 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -139,7 +139,8 @@ void *xc_dom_malloc_page_aligned(struct xc_dom_image *dom, size_t size)
 }
 
 void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
-                            const char *filename, size_t * size)
+                            const char *filename, size_t * size,
+                            const size_t max_size)
 {
     struct xc_dom_mem *block = NULL;
     int fd = -1;
@@ -151,6 +152,13 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
     lseek(fd, 0, SEEK_SET);
     *size = lseek(fd, 0, SEEK_END);
 
+    if ( max_size && *size > max_size )
+    {
+        xc_dom_panic(XC_OUT_OF_MEMORY,
+                     "tried to map file which is too large");
+        goto err;
+    }
+
     block = malloc(sizeof(*block));
     if ( block == NULL )
         goto err;
@@ -202,6 +210,40 @@ char *xc_dom_strdup(struct xc_dom_image *dom, const char *str)
 }
 
 /* ------------------------------------------------------------------------ */
+/* decompression buffer sizing                                              */
+int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz)
+{
+    /* No limit */
+    if ( !dom->max_kernel_size )
+        return 0;
+
+    if ( sz > dom->max_kernel_size )
+    {
+        xc_dom_panic(XC_INVALID_KERNEL,
+                     "kernel image too large");
+        return 1;
+    }
+
+    return 0;
+}
+
+int xc_dom_ramdisk_check_size(struct xc_dom_image *dom, size_t sz)
+{
+    /* No limit */
+    if ( !dom->max_ramdisk_size )
+        return 0;
+
+    if ( sz > dom->max_ramdisk_size )
+    {
+        xc_dom_panic(XC_INVALID_KERNEL,
+                     "ramdisk image too large");
+        return 1;
+    }
+
+    return 0;
+}
+
+/* ------------------------------------------------------------------------ */
 /* read files, copy memory blocks, with transparent gunzip                  */
 
 size_t xc_dom_check_gzip(void *blob, size_t ziplen)
@@ -215,7 +257,7 @@ size_t xc_dom_check_gzip(void *blob, size_t ziplen)
 
     gzlen = blob + ziplen - 4;
     unziplen = gzlen[3] << 24 | gzlen[2] << 16 | gzlen[1] << 8 | gzlen[0];
-    if ( (unziplen < 0) || (unziplen > (1024*1024*1024)) ) /* 1GB limit */
+    if ( (unziplen < 0) || (unziplen > XC_DOM_DECOMPRESS_MAX) )
     {
         xc_dom_printf
             ("%s: size (zip %zd, unzip %zd) looks insane, skip gunzip\n",
@@ -266,6 +308,9 @@ int xc_dom_try_gunzip(struct xc_dom_image *dom, void **blob, size_t * size)
     if ( unziplen == 0 )
         return 0;
 
+    if ( xc_dom_kernel_check_size(dom, unziplen) )
+        return 0;
+
     unzip = xc_dom_malloc(dom, unziplen);
     if ( unzip == NULL )
         return -1;
@@ -562,6 +607,10 @@ struct xc_dom_image *xc_dom_allocate(const char *cmdline, const char *features)
         goto err;
 
     memset(dom, 0, sizeof(*dom));
+
+    dom->max_kernel_size = XC_DOM_DECOMPRESS_MAX;
+    dom->max_ramdisk_size = XC_DOM_DECOMPRESS_MAX;
+
     if ( cmdline )
         dom->cmdline = xc_dom_strdup(dom, cmdline);
     if ( features )
@@ -582,10 +631,25 @@ struct xc_dom_image *xc_dom_allocate(const char *cmdline, const char *features)
     return NULL;
 }
 
+int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz)
+{
+    xc_dom_printf("%s: kernel_max_size=%zx", __FUNCTION__, sz);
+    dom->max_kernel_size = sz;
+    return 0;
+}
+
+int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz)
+{
+    xc_dom_printf("%s: ramdisk_max_size=%zx", __FUNCTION__, sz);
+    dom->max_ramdisk_size = sz;
+    return 0;
+}
+
 int xc_dom_kernel_file(struct xc_dom_image *dom, const char *filename)
 {
     xc_dom_printf("%s: filename=\"%s\"\n", __FUNCTION__, filename);
-    dom->kernel_blob = xc_dom_malloc_filemap(dom, filename, &dom->kernel_size);
+    dom->kernel_blob = xc_dom_malloc_filemap(dom, filename, &dom->kernel_size,
+                                             dom->max_kernel_size);
     if ( dom->kernel_blob == NULL )
         return -1;
     return xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size);
@@ -595,7 +659,9 @@ int xc_dom_ramdisk_file(struct xc_dom_image *dom, const char *filename)
 {
     xc_dom_printf("%s: filename=\"%s\"\n", __FUNCTION__, filename);
     dom->ramdisk_blob =
-        xc_dom_malloc_filemap(dom, filename, &dom->ramdisk_size);
+        xc_dom_malloc_filemap(dom, filename, &dom->ramdisk_size,
+                              dom->max_ramdisk_size);
+
     if ( dom->ramdisk_blob == NULL )
         return -1;
 //    return xc_dom_try_gunzip(dom, &dom->ramdisk_blob, &dom->ramdisk_size);
@@ -755,7 +821,11 @@ int xc_dom_build_image(struct xc_dom_image *dom)
         void *ramdiskmap;
 
         unziplen = xc_dom_check_gzip(dom->ramdisk_blob, dom->ramdisk_size);
+        if ( xc_dom_ramdisk_check_size(dom, unziplen) != 0 )
+            unziplen = 0;
+
         ramdisklen = unziplen ? unziplen : dom->ramdisk_size;
+
         if ( xc_dom_alloc_segment(dom, &dom->ramdisk_seg, "ramdisk", 0,
                                   ramdisklen) != 0 )
             goto err;
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index e52df7b..93b0cac 100644
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -28,6 +28,7 @@ import grub.LiloConf
 import grub.ExtLinuxConf
 
 PYGRUB_VER = 0.6
+FS_READ_MAX = 1024 * 1024
 
 def enable_cursor(ison):
     if ison:
@@ -407,7 +408,8 @@ class Grub:
         if self.__dict__.get('cf', None) is None:
             raise RuntimeError, "couldn't find bootloader config file in the image provided."
         f = fs.open_file(self.cf.filename)
-        buf = f.read()
+        # limit read size to avoid pathological cases
+        buf = f.read(FS_READ_MAX)
         del f
         self.cf.parse(buf)
 
@@ -633,6 +635,37 @@ if __name__ == "__main__":
     def usage():
         print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] <image>" %(sys.argv[0],)
 
+    def copy_from_image(fs, file_to_read, file_type, output_directory,
+                        not_really):
+        if not_really:
+            if fs.file_exists(file_to_read):
+                return "<%s:%s>" % (file_type, file_to_read)
+            else:
+                sys.exit("The requested %s file does not exist" % file_type)
+        try:
+            datafile = fs.open_file(file_to_read)
+        except Exception, e:
+            print >>sys.stderr, e
+            sys.exit("Error opening %s in guest" % file_to_read)
+        (tfd, ret) = tempfile.mkstemp(prefix="boot_"+file_type+".",
+                                      dir=output_directory)
+        dataoff = 0
+        while True:
+            data = datafile.read(FS_READ_MAX, dataoff)
+            if len(data) == 0:
+                os.close(tfd)
+                del datafile
+                return ret
+            try:
+                os.write(tfd, data)
+            except Exception, e:
+                print >>sys.stderr, e
+                os.close(tfd)
+                os.unlink(ret)
+                del datafile
+                sys.exit("Error writing temporary copy of "+file_type)
+            dataoff += len(data)
+
     try:
         opts, args = getopt.gnu_getopt(sys.argv[1:], 'qih::',
                                    ["quiet", "interactive", "help", "output=",
@@ -712,18 +745,18 @@ if __name__ == "__main__":
     if not chosencfg["kernel"]:
         chosencfg = run_grub(file, entry, fs, incfg["args"])
 
-    data = fs.open_file(chosencfg["kernel"]).read()
-    (tfd, bootcfg["kernel"]) = tempfile.mkstemp(prefix="boot_kernel.",
-        dir="/var/run/xend/boot")
-    os.write(tfd, data)
-    os.close(tfd)
+    bootcfg["kernel"] = copy_from_image(fs, chosencfg["kernel"], "kernel",
+                                        output_directory, not_really)
 
     if chosencfg["ramdisk"]:
-        data = fs.open_file(chosencfg["ramdisk"],).read()
-        (tfd, bootcfg["ramdisk"]) = tempfile.mkstemp(prefix="boot_ramdisk.",
-            dir="/var/run/xend/boot")
-        os.write(tfd, data)
-        os.close(tfd)
+        try:
+            bootcfg["ramdisk"] = copy_from_image(fs, chosencfg["ramdisk"],
+                                                 "ramdisk", output_directory,
+                                                 not_really)
+        except:
+            if not not_really:
+                os.unlink(bootcfg["kernel"])
+            raise
     else:
         initrd = None
 
diff --git a/tools/python/xen/xm/messages/xen-xm.pot b/tools/python/xen/xm/messages/xen-xm.pot
index a600a69..3d381f1 100644
--- a/tools/python/xen/xm/messages/xen-xm.pot
+++ b/tools/python/xen/xm/messages/xen-xm.pot
@@ -8,10 +8,11 @@ msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-03-31 17:40+0100\n"
+"POT-Creation-Date: 2013-02-07 10:25+0000\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
+"Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=CHARSET\n"
 "Content-Transfer-Encoding: 8bit\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 Mon Feb 11 13:23:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 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 1U4tLR-000562-Ge; Mon, 11 Feb 2013 13:22:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U4tLQ-00055x-Bc
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:22:52 +0000
Received: from [193.109.254.147:20115] by server-4.bemta-14.messagelabs.com id
	7E/84-20719-BA0F8115; Mon, 11 Feb 2013 13:22:51 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360588968!9928088!1
X-Originating-IP: [209.85.214.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2325 invoked from network); 11 Feb 2013 13:22:49 -0000
Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com)
	(209.85.214.169)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:22:49 -0000
Received: by mail-ob0-f169.google.com with SMTP id ta14so6115027obb.14
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 05:22:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=7Qx/0kHT3nAy7je5cDaY9yvhErFqItErDyQkQ5TyAJ4=;
	b=Y9u/lMzTDEAKCzhtdwsMpzq9JggNO+VtELi4Kevk6EV7ToXjjGZG/A/4F2WSrsHbta
	dVei3b0o3Wgh6F3BUINRS4VxueL8mmKLHUPWxKUx7eFYWiVxqk93/5SH8P922dld1qIG
	lFu5S6TEab+l4lNsAAChWrC/iZ/O5PbH2CpcGPBVp1xk6AiCwntW5kvKgr4+1sFoITrG
	i4tQA9123CwIhvrbv9NJzvs7maVq4SoHr6IHMW6DEPnrZrRg+EZWaBEhidm1nimcd/xN
	a8skJqu+g9L74EQI6+O/+D41NCzvepnmVnQsKN+WquJ04nbIK5xPTWh9lqN9lI4N4gxc
	m0BQ==
MIME-Version: 1.0
X-Received: by 10.60.20.35 with SMTP id k3mr10487526oee.119.1360588968356;
	Mon, 11 Feb 2013 05:22:48 -0800 (PST)
Received: by 10.60.146.228 with HTTP; Mon, 11 Feb 2013 05:22:48 -0800 (PST)
In-Reply-To: <1360583122.29432.135.camel@zakaz.uk.xensource.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
Date: Mon, 11 Feb 2013 08:22:48 -0500
Message-ID: <CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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

> Please can you describe what goes wrong with it where it is?
Executing "./configure --enable-stubdom" doesn't call
stubdom/configure and I think the following patch will fix it
correctly.


Signed-off-by: Shakeel Butt <shakeel.butt@gmail.com>
---

diff -r 6c1b12c884b4 m4/subsystem.m4
--- a/m4/subsystem.m4
+++ b/m4/subsystem.m4
@@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
 ],[
 AX_DISABLE_SUBSYSTEM([$1])
 ])
+])
 AX_SUBSYSTEM_CONFIGURE([$1])
 AC_SUBST($1)
 ])
-])

 AC_DEFUN([AX_SUBSYSTEM_FINISH], [
 AC_SUBST(SUBSYSTEMS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 13:23:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 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 1U4tLR-000562-Ge; Mon, 11 Feb 2013 13:22:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U4tLQ-00055x-Bc
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 13:22:52 +0000
Received: from [193.109.254.147:20115] by server-4.bemta-14.messagelabs.com id
	7E/84-20719-BA0F8115; Mon, 11 Feb 2013 13:22:51 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360588968!9928088!1
X-Originating-IP: [209.85.214.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2325 invoked from network); 11 Feb 2013 13:22:49 -0000
Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com)
	(209.85.214.169)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 13:22:49 -0000
Received: by mail-ob0-f169.google.com with SMTP id ta14so6115027obb.14
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 05:22:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=7Qx/0kHT3nAy7je5cDaY9yvhErFqItErDyQkQ5TyAJ4=;
	b=Y9u/lMzTDEAKCzhtdwsMpzq9JggNO+VtELi4Kevk6EV7ToXjjGZG/A/4F2WSrsHbta
	dVei3b0o3Wgh6F3BUINRS4VxueL8mmKLHUPWxKUx7eFYWiVxqk93/5SH8P922dld1qIG
	lFu5S6TEab+l4lNsAAChWrC/iZ/O5PbH2CpcGPBVp1xk6AiCwntW5kvKgr4+1sFoITrG
	i4tQA9123CwIhvrbv9NJzvs7maVq4SoHr6IHMW6DEPnrZrRg+EZWaBEhidm1nimcd/xN
	a8skJqu+g9L74EQI6+O/+D41NCzvepnmVnQsKN+WquJ04nbIK5xPTWh9lqN9lI4N4gxc
	m0BQ==
MIME-Version: 1.0
X-Received: by 10.60.20.35 with SMTP id k3mr10487526oee.119.1360588968356;
	Mon, 11 Feb 2013 05:22:48 -0800 (PST)
Received: by 10.60.146.228 with HTTP; Mon, 11 Feb 2013 05:22:48 -0800 (PST)
In-Reply-To: <1360583122.29432.135.camel@zakaz.uk.xensource.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
Date: Mon, 11 Feb 2013 08:22:48 -0500
Message-ID: <CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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

> Please can you describe what goes wrong with it where it is?
Executing "./configure --enable-stubdom" doesn't call
stubdom/configure and I think the following patch will fix it
correctly.


Signed-off-by: Shakeel Butt <shakeel.butt@gmail.com>
---

diff -r 6c1b12c884b4 m4/subsystem.m4
--- a/m4/subsystem.m4
+++ b/m4/subsystem.m4
@@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
 ],[
 AX_DISABLE_SUBSYSTEM([$1])
 ])
+])
 AX_SUBSYSTEM_CONFIGURE([$1])
 AC_SUBST($1)
 ])
-])

 AC_DEFUN([AX_SUBSYSTEM_FINISH], [
 AC_SUBST(SUBSYSTEMS)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 14:11:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 14:11: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 1U4u5s-0005Zu-EH; Mon, 11 Feb 2013 14:10:52 +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 1U4u5q-0005Zp-LS
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 14:10:50 +0000
Received: from [85.158.143.35:61941] by server-2.bemta-4.messagelabs.com id
	FE/B1-01597-9EBF8115; Mon, 11 Feb 2013 14:10:49 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360591692!5010842!1
X-Originating-IP: [62.94.10.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7861 invoked from network); 11 Feb 2013 14:08:13 -0000
Received: from mp1-smtp-2.eutelia.it (HELO smtp.eutelia.it) (62.94.10.162)
	by server-2.tower-21.messagelabs.com with SMTP;
	11 Feb 2013 14:08:13 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id ED996CAB96;
	Mon, 11 Feb 2013 15:08:11 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 11 Feb 2013 15:07:32 +0100
Message-Id: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

- If videoram setting is less than 8 mb shows error and exit.
- Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
- Updated xl.cfg man.
- Default and minimal videoram changed to 16 mb if stdvga is set and upstream
  qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
  (qemu 1.3 doesn't complain about it, probably buggy).

Changes from v5:
- Default and minimal videoram changed to 16 mb if stdvga is set and upstream
  qemu is being used.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 docs/man/xl.cfg.pod.5      |   14 +++++---------
 tools/libxl/libxl_create.c |   18 +++++++++++++++++-
 tools/libxl/libxl_dm.c     |    6 ++++++
 3 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index caba162..9c5cdcd 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
 
 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B<stdvga>
-option (see below).
+available.
 The default amount of video ram for stdvga is 8MB which is sufficient
-for e.g. 1600x1200 at 32bpp.
+for e.g. 1600x1200 at 32bpp and videoram option is currently working
+only when using the qemu-xen-traditional device-model.
 
 When using the emulated Cirrus graphics card (B<stdvga=0>)
 the amount of video ram is fixed at 4MB which is sufficient
-for 1024x768 at 32 bpp.
-
-videoram option is currently only available when using the
-qemu-xen-traditional device-model. Upstream qemu-xen device-model
-currently does not support changing the amount of video memory for the
-emulated graphics device.
+for 1024x768 at 32 bpp and videoram option is currently working
+only when using the upstream qemu-xen device-model.
 
 =item B<stdvga=BOOLEAN>
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a8dfe61..fa81f88 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -197,8 +197,24 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
-        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
+            b_info->device_model_version ==
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+                    b_info->video_memkb = 16 * 1024;
+                else if (b_info->video_memkb < (16 * 1024) ){
+                    LOG(ERROR,
+                    "videoram must be at least 16 mb with stdvga");
+                    return ERROR_INVAL;
+                }
+        } else if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+        else if (b_info->video_memkb < (8 * 1024) ){
+            LOG(ERROR,"videoram must be at least 8 mb");
+            return ERROR_INVAL;
+        }
+
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51f9914..465b1fd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -430,6 +430,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "vga.vram_size_mb=%d",
+                libxl__sizekb_to_mb(b_info->video_memkb)),
+                NULL);
+            }
             break;
         }
 
-- 
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 Mon Feb 11 14:11:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 14:11: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 1U4u5s-0005Zu-EH; Mon, 11 Feb 2013 14:10:52 +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 1U4u5q-0005Zp-LS
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 14:10:50 +0000
Received: from [85.158.143.35:61941] by server-2.bemta-4.messagelabs.com id
	FE/B1-01597-9EBF8115; Mon, 11 Feb 2013 14:10:49 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360591692!5010842!1
X-Originating-IP: [62.94.10.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7861 invoked from network); 11 Feb 2013 14:08:13 -0000
Received: from mp1-smtp-2.eutelia.it (HELO smtp.eutelia.it) (62.94.10.162)
	by server-2.tower-21.messagelabs.com with SMTP;
	11 Feb 2013 14:08:13 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id ED996CAB96;
	Mon, 11 Feb 2013 15:08:11 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 11 Feb 2013 15:07:32 +0100
Message-Id: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

- If videoram setting is less than 8 mb shows error and exit.
- Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
- Updated xl.cfg man.
- Default and minimal videoram changed to 16 mb if stdvga is set and upstream
  qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
  (qemu 1.3 doesn't complain about it, probably buggy).

Changes from v5:
- Default and minimal videoram changed to 16 mb if stdvga is set and upstream
  qemu is being used.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 docs/man/xl.cfg.pod.5      |   14 +++++---------
 tools/libxl/libxl_create.c |   18 +++++++++++++++++-
 tools/libxl/libxl_dm.c     |    6 ++++++
 3 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index caba162..9c5cdcd 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
 
 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B<stdvga>
-option (see below).
+available.
 The default amount of video ram for stdvga is 8MB which is sufficient
-for e.g. 1600x1200 at 32bpp.
+for e.g. 1600x1200 at 32bpp and videoram option is currently working
+only when using the qemu-xen-traditional device-model.
 
 When using the emulated Cirrus graphics card (B<stdvga=0>)
 the amount of video ram is fixed at 4MB which is sufficient
-for 1024x768 at 32 bpp.
-
-videoram option is currently only available when using the
-qemu-xen-traditional device-model. Upstream qemu-xen device-model
-currently does not support changing the amount of video memory for the
-emulated graphics device.
+for 1024x768 at 32 bpp and videoram option is currently working
+only when using the upstream qemu-xen device-model.
 
 =item B<stdvga=BOOLEAN>
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a8dfe61..fa81f88 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -197,8 +197,24 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
-        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
+            b_info->device_model_version ==
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
+                    b_info->video_memkb = 16 * 1024;
+                else if (b_info->video_memkb < (16 * 1024) ){
+                    LOG(ERROR,
+                    "videoram must be at least 16 mb with stdvga");
+                    return ERROR_INVAL;
+                }
+        } else if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+        else if (b_info->video_memkb < (8 * 1024) ){
+            LOG(ERROR,"videoram must be at least 8 mb");
+            return ERROR_INVAL;
+        }
+
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 51f9914..465b1fd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -430,6 +430,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "vga.vram_size_mb=%d",
+                libxl__sizekb_to_mb(b_info->video_memkb)),
+                NULL);
+            }
             break;
         }
 
-- 
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 Mon Feb 11 14:54:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 14:54: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 1U4ulT-0005sw-Hh; Mon, 11 Feb 2013 14:53:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabiano.francesconi@gmail.com>) id 1U4ulR-0005sr-8I
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 14:53:49 +0000
Received: from [85.158.143.35:45355] by server-3.bemta-4.messagelabs.com id
	B6/31-08920-CF509115; Mon, 11 Feb 2013 14:53:48 +0000
X-Env-Sender: fabiano.francesconi@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1360594425!4618629!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17042 invoked from network); 11 Feb 2013 14:53:47 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 14:53:47 -0000
Received: by mail-ee0-f45.google.com with SMTP id b57so3322178eek.32
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 06:53:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:date:from:to:message-id:subject:x-mailer:mime-version
	:content-type:content-transfer-encoding:content-disposition;
	bh=qMkcq/F8yLIuacQfa67+idMsCWHNqzEUSfWzntjTzYs=;
	b=Sij872iyPc8AL5CE4HnOpByHuVr+WRrWVVC2FmvSNsd5LHy13GIKxc5HJSsm8yECCj
	XNqTFqmLamJl0r6bpgZKoejINe0+O5tW4HJo+goztCsrV4rJKT0HFuhaukAc3lIsqOOD
	sfJ0SKNKsbJavhbz+yYCBISe+NNiycG4m46WzWGFB1fq7hjqx5GWZM1f1RvvvYOCTHAT
	36C1iVVJjk9/sEWipIifWGYfD17m4SaRT775kJssUtVxuzg9pfT6/iSRw50pClAqL6r3
	dwkxgyHK7vnxNFE35meVHG8G8YSVV5CmWL/k0ZLxXJzfark97x6jQXPKd6Ug55YJmr7n
	l6aQ==
X-Received: by 10.14.215.131 with SMTP id e3mr51372624eep.32.1360594402482;
	Mon, 11 Feb 2013 06:53:22 -0800 (PST)
Received: from [192.168.0.145]
	(host111-111-dynamic.14-87-r.retail.telecomitalia.it.
	[87.14.111.111])
	by mx.google.com with ESMTPS id q5sm62908263eep.11.2013.02.11.06.53.21
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 11 Feb 2013 06:53:22 -0800 (PST)
Date: Mon, 11 Feb 2013 15:53:20 +0100
From: Fabiano Francesconi <fabiano.francesconi@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <9E695C71278D43F7A53208C5BF34FBA3@gmail.com>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] Xen 4.2.0: unable to add disk 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

Hello everybody, 
I think I've screwed up today. I was trying to fix a malfunctioning domU and I ended up issuing xenstore-rm {/local,/vm}.

I feel like an idiot that did something really wrong. Since that, all the my virtual machines cannot start anymore.

What I get is:

xevelon ~ # xl cr -c /xen/configs/aquaria 
Parsing config from /xen/configs/aquaria
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51714
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51715
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51728
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51714
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51715
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51728
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 12


And if I take a look at xenstored:

xevelon ~ # xenstore-ls -fp
/tool = "" (n0)
/tool/xenstored = "" (n0)
/libxl = "" (n0)
/vm = "" (n0)
/local = "" (n0)
/local/domain = "" (n0)
/local/domain/0 = "" (n0)
/local/domain/0/name = "Domain-0" (n0)
/local/domain/0/libxl = "" (n0)
/local/domain/0/libxl/disable_udev = "1" (n0)

Obviously something is wrong here. I've no data about the dom0, no information about the backend. Is there a way to reload all the stuff I've removed?

Thank you very much  

-- 
Fabiano Francesconi [GPG key: 0x81E53461]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 14:54:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 14:54: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 1U4ulT-0005sw-Hh; Mon, 11 Feb 2013 14:53:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabiano.francesconi@gmail.com>) id 1U4ulR-0005sr-8I
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 14:53:49 +0000
Received: from [85.158.143.35:45355] by server-3.bemta-4.messagelabs.com id
	B6/31-08920-CF509115; Mon, 11 Feb 2013 14:53:48 +0000
X-Env-Sender: fabiano.francesconi@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1360594425!4618629!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17042 invoked from network); 11 Feb 2013 14:53:47 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 14:53:47 -0000
Received: by mail-ee0-f45.google.com with SMTP id b57so3322178eek.32
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 06:53:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:date:from:to:message-id:subject:x-mailer:mime-version
	:content-type:content-transfer-encoding:content-disposition;
	bh=qMkcq/F8yLIuacQfa67+idMsCWHNqzEUSfWzntjTzYs=;
	b=Sij872iyPc8AL5CE4HnOpByHuVr+WRrWVVC2FmvSNsd5LHy13GIKxc5HJSsm8yECCj
	XNqTFqmLamJl0r6bpgZKoejINe0+O5tW4HJo+goztCsrV4rJKT0HFuhaukAc3lIsqOOD
	sfJ0SKNKsbJavhbz+yYCBISe+NNiycG4m46WzWGFB1fq7hjqx5GWZM1f1RvvvYOCTHAT
	36C1iVVJjk9/sEWipIifWGYfD17m4SaRT775kJssUtVxuzg9pfT6/iSRw50pClAqL6r3
	dwkxgyHK7vnxNFE35meVHG8G8YSVV5CmWL/k0ZLxXJzfark97x6jQXPKd6Ug55YJmr7n
	l6aQ==
X-Received: by 10.14.215.131 with SMTP id e3mr51372624eep.32.1360594402482;
	Mon, 11 Feb 2013 06:53:22 -0800 (PST)
Received: from [192.168.0.145]
	(host111-111-dynamic.14-87-r.retail.telecomitalia.it.
	[87.14.111.111])
	by mx.google.com with ESMTPS id q5sm62908263eep.11.2013.02.11.06.53.21
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 11 Feb 2013 06:53:22 -0800 (PST)
Date: Mon, 11 Feb 2013 15:53:20 +0100
From: Fabiano Francesconi <fabiano.francesconi@gmail.com>
To: xen-devel@lists.xen.org
Message-ID: <9E695C71278D43F7A53208C5BF34FBA3@gmail.com>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] Xen 4.2.0: unable to add disk 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

Hello everybody, 
I think I've screwed up today. I was trying to fix a malfunctioning domU and I ended up issuing xenstore-rm {/local,/vm}.

I feel like an idiot that did something really wrong. Since that, all the my virtual machines cannot start anymore.

What I get is:

xevelon ~ # xl cr -c /xen/configs/aquaria 
Parsing config from /xen/configs/aquaria
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51714
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51715
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51728
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51714
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51715
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/12/51728
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 12


And if I take a look at xenstored:

xevelon ~ # xenstore-ls -fp
/tool = "" (n0)
/tool/xenstored = "" (n0)
/libxl = "" (n0)
/vm = "" (n0)
/local = "" (n0)
/local/domain = "" (n0)
/local/domain/0 = "" (n0)
/local/domain/0/name = "Domain-0" (n0)
/local/domain/0/libxl = "" (n0)
/local/domain/0/libxl/disable_udev = "1" (n0)

Obviously something is wrong here. I've no data about the dom0, no information about the backend. Is there a way to reload all the stuff I've removed?

Thank you very much  

-- 
Fabiano Francesconi [GPG key: 0x81E53461]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 15:28:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 15:28: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 1U4vIh-0007N5-SV; Mon, 11 Feb 2013 15:28:11 +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 1U4vIg-0007Mq-MC
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 15:28:10 +0000
Received: from [85.158.139.211:2065] by server-2.bemta-5.messagelabs.com id
	98/05-16911-90E09115; Mon, 11 Feb 2013 15:28:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360596484!21871115!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21812 invoked from network); 11 Feb 2013 15:28:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Feb 2013 15:28:05 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r7WwX+cIQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-013.pools.arcor-ip.net [84.57.92.13])
	by smtp.strato.de (jorabe mo13) (RZmta 31.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y035b2p1BEgnBQ
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 16:28:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6DFB91863D
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 16:28:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e80418f1f58bf36fe953af587cc0e6dbd52dffa7
Message-Id: <e80418f1f58bf36fe953.1360596482@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Mon, 11 Feb 2013 16:28:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] unmodified_drivers: __devinit was removed in
	linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360595055 -3600
# Node ID e80418f1f58bf36fe953af587cc0e6dbd52dffa7
# Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
unmodified_drivers: __devinit was removed in linux-3.8

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2fdca30363f0 -r e80418f1f58b unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
@@ -24,6 +24,11 @@
 
 #include <linux/pci.h>
 
+#ifndef __devinit
+#define __devinit
+#define __devinitdata
+#endif
+
 unsigned long alloc_xen_mmio(unsigned long len);
 void platform_pci_resume(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 15:28:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 15:28: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 1U4vIh-0007N5-SV; Mon, 11 Feb 2013 15:28:11 +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 1U4vIg-0007Mq-MC
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 15:28:10 +0000
Received: from [85.158.139.211:2065] by server-2.bemta-5.messagelabs.com id
	98/05-16911-90E09115; Mon, 11 Feb 2013 15:28:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360596484!21871115!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21812 invoked from network); 11 Feb 2013 15:28:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Feb 2013 15:28:05 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r7WwX+cIQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-013.pools.arcor-ip.net [84.57.92.13])
	by smtp.strato.de (jorabe mo13) (RZmta 31.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y035b2p1BEgnBQ
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 16:28:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6DFB91863D
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 16:28:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e80418f1f58bf36fe953af587cc0e6dbd52dffa7
Message-Id: <e80418f1f58bf36fe953.1360596482@probook.site>
User-Agent: Mercurial-patchbomb/2.4.2
Date: Mon, 11 Feb 2013 16:28:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] unmodified_drivers: __devinit was removed in
	linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360595055 -3600
# Node ID e80418f1f58bf36fe953af587cc0e6dbd52dffa7
# Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
unmodified_drivers: __devinit was removed in linux-3.8

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2fdca30363f0 -r e80418f1f58b unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
@@ -24,6 +24,11 @@
 
 #include <linux/pci.h>
 
+#ifndef __devinit
+#define __devinit
+#define __devinitdata
+#endif
+
 unsigned long alloc_xen_mmio(unsigned long len);
 void platform_pci_resume(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:12:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 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 1U4vzd-0000BK-9H; Mon, 11 Feb 2013 16:12:33 +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 1U4vzb-0000BE-Qk
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:12:32 +0000
Received: from [85.158.138.51:3477] by server-8.bemta-3.messagelabs.com id
	54/21-25687-A6819115; Mon, 11 Feb 2013 16:12:26 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360599141!21680914!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27441 invoked from network); 11 Feb 2013 16:12:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 16:12:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1337408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 16:12:21 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Mon, 11 Feb 2013 16:12:20 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Mon, 11 Feb 2013 17:10:58 +0100
Message-ID: <1360599058-1567-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: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen-blkfront: drop the use of
	llist_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

UmVwbGFjZSBsbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlIHdpdGggYSB3aGlsZSBsb29wIGFuZAps
bGlzdF9kZWxfZmlyc3QuCgpsbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlIGNhbiB0cmlnZ2VyIGEg
YnVnIGluIEdDQyA0LjEsIHNvIGl0J3MgYmVzdAp0byByZW1vdmUgaXQgYW5kIHVzZSBhIHdoaWxl
IGxvb3AgYW5kIGxsaXN0X2RlbF9maXJzdCAod2hpY2ggaXMKYWxyZWFkeSBpbiBsbGlzdC5oKS4K
ClNpbmNlIHhlbi1ibGtmcm9udCBpcyB0aGUgb25seSB1c2VyIG9mIHRoZSBsbGlzdF9mb3JfZWFj
aF9lbnRyeV9zYWZlCm1hY3JvIHJlbW92ZSBpdCBmcm9tIGxsaXN0LmguCgpTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmVwb3J0ZWQtYnk6IEtv
bnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCkNjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9y
YWNsZS5jb20+Ci0tLQogZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYyB8ICAgIDUgKystLS0K
IGluY2x1ZGUvbGludXgvbGxpc3QuaCAgICAgICAgfCAgIDI1IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KIDIgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAyOCBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9j
ay94ZW4tYmxrZnJvbnQuYwppbmRleCAxMTA0M2MxLi5jMzI1MDYyIDEwMDY0NAotLS0gYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250
LmMKQEAgLTc5MCw3ICs3OTAsNiBAQCBzdGF0aWMgdm9pZCBibGtpZl9yZXN0YXJ0X3F1ZXVlKHN0
cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKIAogc3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3Qg
YmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiB7Ci0Jc3RydWN0IGxsaXN0X25vZGUg
KmFsbF9nbnRzOwogCXN0cnVjdCBncmFudCAqcGVyc2lzdGVudF9nbnQ7CiAJc3RydWN0IGxsaXN0
X25vZGUgKm47CiAKQEAgLTgwNCw4ICs4MDMsOCBAQCBzdGF0aWMgdm9pZCBibGtpZl9mcmVlKHN0
cnVjdCBibGtmcm9udF9pbmZvICppbmZvLCBpbnQgc3VzcGVuZCkKIAogCS8qIFJlbW92ZSBhbGwg
cGVyc2lzdGVudCBncmFudHMgKi8KIAlpZiAoaW5mby0+cGVyc2lzdGVudF9nbnRzX2MpIHsKLQkJ
YWxsX2dudHMgPSBsbGlzdF9kZWxfYWxsKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwotCQlsbGlz
dF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBlcnNpc3RlbnRfZ250LCBuLCBhbGxfZ250cywgbm9kZSkg
eworCQl3aGlsZSAoKG4gPSBsbGlzdF9kZWxfZmlyc3QoJmluZm8tPnBlcnNpc3RlbnRfZ250cykp
ICE9IE5VTEwpIHsKKwkJCXBlcnNpc3RlbnRfZ250ID0gbGxpc3RfZW50cnkobiwgc3RydWN0IGdy
YW50LCBub2RlKTsKIAkJCWdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3MocGVyc2lzdGVudF9nbnQt
PmdyZWYsIDAsIDBVTCk7CiAJCQlfX2ZyZWVfcGFnZShwZm5fdG9fcGFnZShwZXJzaXN0ZW50X2du
dC0+cGZuKSk7CiAJCQlrZnJlZShwZXJzaXN0ZW50X2dudCk7CmRpZmYgLS1naXQgYS9pbmNsdWRl
L2xpbnV4L2xsaXN0LmggYi9pbmNsdWRlL2xpbnV4L2xsaXN0LmgKaW5kZXggZDBhYjk4Zi4uYTUx
OTlmNiAxMDA2NDQKLS0tIGEvaW5jbHVkZS9saW51eC9sbGlzdC5oCisrKyBiL2luY2x1ZGUvbGlu
dXgvbGxpc3QuaApAQCAtMTI1LDMxICsxMjUsNiBAQCBzdGF0aWMgaW5saW5lIHZvaWQgaW5pdF9s
bGlzdF9oZWFkKHN0cnVjdCBsbGlzdF9oZWFkICpsaXN0KQogCSAgICAgKHBvcykgPSBsbGlzdF9l
bnRyeSgocG9zKS0+bWVtYmVyLm5leHQsIHR5cGVvZigqKHBvcykpLCBtZW1iZXIpKQogCiAvKioK
LSAqIGxsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUgLSBpdGVyYXRlIHNhZmVseSBhZ2FpbnN0IHJl
bW92ZSBvdmVyIHNvbWUgZW50cmllcwotICogb2YgbG9jay1sZXNzIGxpc3Qgb2YgZ2l2ZW4gdHlw
ZS4KLSAqIEBwb3M6CXRoZSB0eXBlICogdG8gdXNlIGFzIGEgbG9vcCBjdXJzb3IuCi0gKiBAbjoJ
CWFub3RoZXIgdHlwZSAqIHRvIHVzZSBhcyBhIHRlbXBvcmFyeSBzdG9yYWdlLgotICogQG5vZGU6
CXRoZSBmaXN0IGVudHJ5IG9mIGRlbGV0ZWQgbGlzdCBlbnRyaWVzLgotICogQG1lbWJlcjoJdGhl
IG5hbWUgb2YgdGhlIGxsaXN0X25vZGUgd2l0aCB0aGUgc3RydWN0LgotICoKLSAqIEluIGdlbmVy
YWwsIHNvbWUgZW50cmllcyBvZiB0aGUgbG9jay1sZXNzIGxpc3QgY2FuIGJlIHRyYXZlcnNlZAot
ICogc2FmZWx5IG9ubHkgYWZ0ZXIgYmVpbmcgcmVtb3ZlZCBmcm9tIGxpc3QsIHNvIHN0YXJ0IHdp
dGggYW4gZW50cnkKLSAqIGluc3RlYWQgb2YgbGlzdCBoZWFkLiBUaGlzIHZhcmlhbnQgYWxsb3dz
IHJlbW92YWwgb2YgZW50cmllcwotICogYXMgd2UgaXRlcmF0ZS4KLSAqCi0gKiBJZiBiZWluZyB1
c2VkIG9uIGVudHJpZXMgZGVsZXRlZCBmcm9tIGxvY2stbGVzcyBsaXN0IGRpcmVjdGx5LCB0aGUK
LSAqIHRyYXZlcnNlIG9yZGVyIGlzIGZyb20gdGhlIG5ld2VzdCB0byB0aGUgb2xkZXN0IGFkZGVk
IGVudHJ5LiAgSWYKLSAqIHlvdSB3YW50IHRvIHRyYXZlcnNlIGZyb20gdGhlIG9sZGVzdCB0byB0
aGUgbmV3ZXN0LCB5b3UgbXVzdAotICogcmV2ZXJzZSB0aGUgb3JkZXIgYnkgeW91cnNlbGYgYmVm
b3JlIHRyYXZlcnNpbmcuCi0gKi8KLSNkZWZpbmUgbGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShw
b3MsIG4sIG5vZGUsIG1lbWJlcikJCVwKLQlmb3IgKChwb3MpID0gbGxpc3RfZW50cnkoKG5vZGUp
LCB0eXBlb2YoKihwb3MpKSwgbWVtYmVyKSwJXAotCSAgICAgKG4pID0gKHBvcyktPm1lbWJlci5u
ZXh0OwkJCQkJXAotCSAgICAgJihwb3MpLT5tZW1iZXIgIT0gTlVMTDsJCQkJCVwKLQkgICAgIChw
b3MpID0gbGxpc3RfZW50cnkobiwgdHlwZW9mKCoocG9zKSksIG1lbWJlciksCQlcCi0JICAgICAo
bikgPSAoJihwb3MpLT5tZW1iZXIgIT0gTlVMTCkgPyAocG9zKS0+bWVtYmVyLm5leHQgOiBOVUxM
KQotCi0vKioKICAqIGxsaXN0X2VtcHR5IC0gdGVzdHMgd2hldGhlciBhIGxvY2stbGVzcyBsaXN0
IGlzIGVtcHR5CiAgKiBAaGVhZDoJdGhlIGxpc3QgdG8gdGVzdAogICoKLS0gCjEuNy43LjUgKEFw
cGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:12:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 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 1U4vzd-0000BK-9H; Mon, 11 Feb 2013 16:12:33 +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 1U4vzb-0000BE-Qk
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:12:32 +0000
Received: from [85.158.138.51:3477] by server-8.bemta-3.messagelabs.com id
	54/21-25687-A6819115; Mon, 11 Feb 2013 16:12:26 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360599141!21680914!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27441 invoked from network); 11 Feb 2013 16:12:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 16:12:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1337408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 16:12:21 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Mon, 11 Feb 2013 16:12:20 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Mon, 11 Feb 2013 17:10:58 +0100
Message-ID: <1360599058-1567-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: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen-blkfront: drop the use of
	llist_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

UmVwbGFjZSBsbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlIHdpdGggYSB3aGlsZSBsb29wIGFuZAps
bGlzdF9kZWxfZmlyc3QuCgpsbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlIGNhbiB0cmlnZ2VyIGEg
YnVnIGluIEdDQyA0LjEsIHNvIGl0J3MgYmVzdAp0byByZW1vdmUgaXQgYW5kIHVzZSBhIHdoaWxl
IGxvb3AgYW5kIGxsaXN0X2RlbF9maXJzdCAod2hpY2ggaXMKYWxyZWFkeSBpbiBsbGlzdC5oKS4K
ClNpbmNlIHhlbi1ibGtmcm9udCBpcyB0aGUgb25seSB1c2VyIG9mIHRoZSBsbGlzdF9mb3JfZWFj
aF9lbnRyeV9zYWZlCm1hY3JvIHJlbW92ZSBpdCBmcm9tIGxsaXN0LmguCgpTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KUmVwb3J0ZWQtYnk6IEtv
bnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCkNjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9y
YWNsZS5jb20+Ci0tLQogZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYyB8ICAgIDUgKystLS0K
IGluY2x1ZGUvbGludXgvbGxpc3QuaCAgICAgICAgfCAgIDI1IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KIDIgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAyOCBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9j
ay94ZW4tYmxrZnJvbnQuYwppbmRleCAxMTA0M2MxLi5jMzI1MDYyIDEwMDY0NAotLS0gYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250
LmMKQEAgLTc5MCw3ICs3OTAsNiBAQCBzdGF0aWMgdm9pZCBibGtpZl9yZXN0YXJ0X3F1ZXVlKHN0
cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKIAogc3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3Qg
YmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiB7Ci0Jc3RydWN0IGxsaXN0X25vZGUg
KmFsbF9nbnRzOwogCXN0cnVjdCBncmFudCAqcGVyc2lzdGVudF9nbnQ7CiAJc3RydWN0IGxsaXN0
X25vZGUgKm47CiAKQEAgLTgwNCw4ICs4MDMsOCBAQCBzdGF0aWMgdm9pZCBibGtpZl9mcmVlKHN0
cnVjdCBibGtmcm9udF9pbmZvICppbmZvLCBpbnQgc3VzcGVuZCkKIAogCS8qIFJlbW92ZSBhbGwg
cGVyc2lzdGVudCBncmFudHMgKi8KIAlpZiAoaW5mby0+cGVyc2lzdGVudF9nbnRzX2MpIHsKLQkJ
YWxsX2dudHMgPSBsbGlzdF9kZWxfYWxsKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwotCQlsbGlz
dF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBlcnNpc3RlbnRfZ250LCBuLCBhbGxfZ250cywgbm9kZSkg
eworCQl3aGlsZSAoKG4gPSBsbGlzdF9kZWxfZmlyc3QoJmluZm8tPnBlcnNpc3RlbnRfZ250cykp
ICE9IE5VTEwpIHsKKwkJCXBlcnNpc3RlbnRfZ250ID0gbGxpc3RfZW50cnkobiwgc3RydWN0IGdy
YW50LCBub2RlKTsKIAkJCWdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3MocGVyc2lzdGVudF9nbnQt
PmdyZWYsIDAsIDBVTCk7CiAJCQlfX2ZyZWVfcGFnZShwZm5fdG9fcGFnZShwZXJzaXN0ZW50X2du
dC0+cGZuKSk7CiAJCQlrZnJlZShwZXJzaXN0ZW50X2dudCk7CmRpZmYgLS1naXQgYS9pbmNsdWRl
L2xpbnV4L2xsaXN0LmggYi9pbmNsdWRlL2xpbnV4L2xsaXN0LmgKaW5kZXggZDBhYjk4Zi4uYTUx
OTlmNiAxMDA2NDQKLS0tIGEvaW5jbHVkZS9saW51eC9sbGlzdC5oCisrKyBiL2luY2x1ZGUvbGlu
dXgvbGxpc3QuaApAQCAtMTI1LDMxICsxMjUsNiBAQCBzdGF0aWMgaW5saW5lIHZvaWQgaW5pdF9s
bGlzdF9oZWFkKHN0cnVjdCBsbGlzdF9oZWFkICpsaXN0KQogCSAgICAgKHBvcykgPSBsbGlzdF9l
bnRyeSgocG9zKS0+bWVtYmVyLm5leHQsIHR5cGVvZigqKHBvcykpLCBtZW1iZXIpKQogCiAvKioK
LSAqIGxsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUgLSBpdGVyYXRlIHNhZmVseSBhZ2FpbnN0IHJl
bW92ZSBvdmVyIHNvbWUgZW50cmllcwotICogb2YgbG9jay1sZXNzIGxpc3Qgb2YgZ2l2ZW4gdHlw
ZS4KLSAqIEBwb3M6CXRoZSB0eXBlICogdG8gdXNlIGFzIGEgbG9vcCBjdXJzb3IuCi0gKiBAbjoJ
CWFub3RoZXIgdHlwZSAqIHRvIHVzZSBhcyBhIHRlbXBvcmFyeSBzdG9yYWdlLgotICogQG5vZGU6
CXRoZSBmaXN0IGVudHJ5IG9mIGRlbGV0ZWQgbGlzdCBlbnRyaWVzLgotICogQG1lbWJlcjoJdGhl
IG5hbWUgb2YgdGhlIGxsaXN0X25vZGUgd2l0aCB0aGUgc3RydWN0LgotICoKLSAqIEluIGdlbmVy
YWwsIHNvbWUgZW50cmllcyBvZiB0aGUgbG9jay1sZXNzIGxpc3QgY2FuIGJlIHRyYXZlcnNlZAot
ICogc2FmZWx5IG9ubHkgYWZ0ZXIgYmVpbmcgcmVtb3ZlZCBmcm9tIGxpc3QsIHNvIHN0YXJ0IHdp
dGggYW4gZW50cnkKLSAqIGluc3RlYWQgb2YgbGlzdCBoZWFkLiBUaGlzIHZhcmlhbnQgYWxsb3dz
IHJlbW92YWwgb2YgZW50cmllcwotICogYXMgd2UgaXRlcmF0ZS4KLSAqCi0gKiBJZiBiZWluZyB1
c2VkIG9uIGVudHJpZXMgZGVsZXRlZCBmcm9tIGxvY2stbGVzcyBsaXN0IGRpcmVjdGx5LCB0aGUK
LSAqIHRyYXZlcnNlIG9yZGVyIGlzIGZyb20gdGhlIG5ld2VzdCB0byB0aGUgb2xkZXN0IGFkZGVk
IGVudHJ5LiAgSWYKLSAqIHlvdSB3YW50IHRvIHRyYXZlcnNlIGZyb20gdGhlIG9sZGVzdCB0byB0
aGUgbmV3ZXN0LCB5b3UgbXVzdAotICogcmV2ZXJzZSB0aGUgb3JkZXIgYnkgeW91cnNlbGYgYmVm
b3JlIHRyYXZlcnNpbmcuCi0gKi8KLSNkZWZpbmUgbGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShw
b3MsIG4sIG5vZGUsIG1lbWJlcikJCVwKLQlmb3IgKChwb3MpID0gbGxpc3RfZW50cnkoKG5vZGUp
LCB0eXBlb2YoKihwb3MpKSwgbWVtYmVyKSwJXAotCSAgICAgKG4pID0gKHBvcyktPm1lbWJlci5u
ZXh0OwkJCQkJXAotCSAgICAgJihwb3MpLT5tZW1iZXIgIT0gTlVMTDsJCQkJCVwKLQkgICAgIChw
b3MpID0gbGxpc3RfZW50cnkobiwgdHlwZW9mKCoocG9zKSksIG1lbWJlciksCQlcCi0JICAgICAo
bikgPSAoJihwb3MpLT5tZW1iZXIgIT0gTlVMTCkgPyAocG9zKS0+bWVtYmVyLm5leHQgOiBOVUxM
KQotCi0vKioKICAqIGxsaXN0X2VtcHR5IC0gdGVzdHMgd2hldGhlciBhIGxvY2stbGVzcyBsaXN0
IGlzIGVtcHR5CiAgKiBAaGVhZDoJdGhlIGxpc3QgdG8gdGVzdAogICoKLS0gCjEuNy43LjUgKEFw
cGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:18:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16: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 1U4w5D-0000M9-39; Mon, 11 Feb 2013 16:18:19 +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 1U4w5C-0000M3-Fl
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:18:18 +0000
Received: from [85.158.138.51:2586] by server-7.bemta-3.messagelabs.com id
	50/68-10367-9C919115; Mon, 11 Feb 2013 16:18:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360599489!30141596!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29174 invoked from network); 11 Feb 2013 16:18:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Feb 2013 16:18:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287qEf4=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-013.pools.arcor-ip.net [84.57.92.13])
	by smtp.strato.de (jored mo23) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I02b36p1BFtch8 ;
	Mon, 11 Feb 2013 17:18:00 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 6431E1884C; Mon, 11 Feb 2013 17:18:00 +0100 (CET)
Date: Mon, 11 Feb 2013 17:18:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20130211161800.GA15788@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
	<83398C3BBF16693DB6E1E2CA@nimrod.local>
	<20130208133630.GA5304@aepfle.de>
	<CACJDEmpQXeCaSgNWhZCdcEZotsUkQHJHUEVm2G=edsgaaL92AA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACJDEmpQXeCaSgNWhZCdcEZotsUkQHJHUEVm2G=edsgaaL92AA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 08, Konrad Rzeszutek Wilk wrote:

> I recall seeing that libvirt had some of this figured out. It would
> know which CPUID flags each CPU family had - and you could actually
> set ('I am a Westmere CPU') or it would use the lowest common CPU
> family support for all the guest.
> 
> Granted that means you need to know _which_ of the machines has the
> lowest common CPU family first. Or you set the guest to say 'Core' .
> 
> Anyhow, perhaps looking at libvirt and implementing something similar
> in 'xl' would be beneficial for these issues?

I havent looked at the code, but I can imagine it does that via qemu.
But it would be nice thing to have proper cpuid= handling were libvirt
can force a certain cpu type.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:18:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16: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 1U4w5D-0000M9-39; Mon, 11 Feb 2013 16:18:19 +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 1U4w5C-0000M3-Fl
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:18:18 +0000
Received: from [85.158.138.51:2586] by server-7.bemta-3.messagelabs.com id
	50/68-10367-9C919115; Mon, 11 Feb 2013 16:18:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360599489!30141596!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTAzMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29174 invoked from network); 11 Feb 2013 16:18:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Feb 2013 16:18:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287qEf4=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-013.pools.arcor-ip.net [84.57.92.13])
	by smtp.strato.de (jored mo23) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I02b36p1BFtch8 ;
	Mon, 11 Feb 2013 17:18:00 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 6431E1884C; Mon, 11 Feb 2013 17:18:00 +0100 (CET)
Date: Mon, 11 Feb 2013 17:18:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20130211161800.GA15788@aepfle.de>
References: <8B93B6FC00D1EC219B83AEDB@nimrod.local>
	<20130207091907.GA5540@aepfle.de>
	<1360230421.32479.46.camel@zakaz.uk.xensource.com>
	<496E7A8DB9DCF257D29E10F2@nimrod.local>
	<20130207151126.GA31180@aepfle.de>
	<13FBA4F2DA636D516C1AAB94@nimrod.local>
	<5113E22102000078000BCF51@nat28.tlf.novell.com>
	<83398C3BBF16693DB6E1E2CA@nimrod.local>
	<20130208133630.GA5304@aepfle.de>
	<CACJDEmpQXeCaSgNWhZCdcEZotsUkQHJHUEVm2G=edsgaaL92AA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACJDEmpQXeCaSgNWhZCdcEZotsUkQHJHUEVm2G=edsgaaL92AA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Question re live migrate on Xen 4.2 re different
 cpu capabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 08, Konrad Rzeszutek Wilk wrote:

> I recall seeing that libvirt had some of this figured out. It would
> know which CPUID flags each CPU family had - and you could actually
> set ('I am a Westmere CPU') or it would use the lowest common CPU
> family support for all the guest.
> 
> Granted that means you need to know _which_ of the machines has the
> lowest common CPU family first. Or you set the guest to say 'Core' .
> 
> Anyhow, perhaps looking at libvirt and implementing something similar
> in 'xl' would be beneficial for these issues?

I havent looked at the code, but I can imagine it does that via qemu.
But it would be nice thing to have proper cpuid= handling were libvirt
can force a certain cpu type.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:19:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16: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 1U4w5w-0000Pj-NP; Mon, 11 Feb 2013 16:19:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4w5u-0000PM-9s
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:19:02 +0000
Received: from [193.109.254.147:16742] by server-13.bemta-14.messagelabs.com
	id 5F/C6-30639-5F919115; Mon, 11 Feb 2013 16:19:01 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360599472!3202953!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4907 invoked from network); 11 Feb 2013 16:17:53 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-6.tower-27.messagelabs.com with SMTP;
	11 Feb 2013 16:17:53 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1BGHmQY000636;
	Mon, 11 Feb 2013 11:17:48 -0500
Message-ID: <511919AB.3070001@theshore.net>
Date: Mon, 11 Feb 2013 11:17:47 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
In-Reply-To: <1360583103.16636.29.camel@zion.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/11/13 6:45 AM, Wei Liu wrote:
> OK, so the guest is faulting at different offset now. It is very likely
> that there is OOM / race condition in other places. And judging from
> your two emails, I presume this bug can be reproduce steadily.

It is frequent enough to be a problem, yes.  We're constantly deploying 
new servers and upgrading the stack on existing ones, so testing changes 
won't be a problem.

> A quick check on the xen_spinlock struct, its offset should not be
> 0x8b8. Reading the backtrace suggests that it is the netbk struct is
> gone.

Great, we've narrowed it down some.

> Do you manipulate the number of vcpus Dom0 has after it's up?

No, we do not.

Thanks,
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:19:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16: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 1U4w5w-0000Pj-NP; Mon, 11 Feb 2013 16:19:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4w5u-0000PM-9s
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:19:02 +0000
Received: from [193.109.254.147:16742] by server-13.bemta-14.messagelabs.com
	id 5F/C6-30639-5F919115; Mon, 11 Feb 2013 16:19:01 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360599472!3202953!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4907 invoked from network); 11 Feb 2013 16:17:53 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-6.tower-27.messagelabs.com with SMTP;
	11 Feb 2013 16:17:53 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1BGHmQY000636;
	Mon, 11 Feb 2013 11:17:48 -0500
Message-ID: <511919AB.3070001@theshore.net>
Date: Mon, 11 Feb 2013 11:17:47 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
In-Reply-To: <1360583103.16636.29.camel@zion.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/11/13 6:45 AM, Wei Liu wrote:
> OK, so the guest is faulting at different offset now. It is very likely
> that there is OOM / race condition in other places. And judging from
> your two emails, I presume this bug can be reproduce steadily.

It is frequent enough to be a problem, yes.  We're constantly deploying 
new servers and upgrading the stack on existing ones, so testing changes 
won't be a problem.

> A quick check on the xen_spinlock struct, its offset should not be
> 0x8b8. Reading the backtrace suggests that it is the netbk struct is
> gone.

Great, we've narrowed it down some.

> Do you manipulate the number of vcpus Dom0 has after it's up?

No, we do not.

Thanks,
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:41:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16:41: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 1U4wQv-00010Y-9n; Mon, 11 Feb 2013 16:40: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 1U4uyE-0006Mm-D3; Mon, 11 Feb 2013 15:07:02 +0000
Received: from [85.158.143.35:30304] by server-2.bemta-4.messagelabs.com id
	42/C0-01597-51909115; Mon, 11 Feb 2013 15:07:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1360595211!12444533!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30900 invoked from network); 11 Feb 2013 15:06:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 15:06:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1334394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 15:06: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.297.1;
	Mon, 11 Feb 2013 15:06:51 +0000
Message-ID: <1360595210.20449.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabiano Francesconi <fabiano.francesconi@gmail.com>
Date: Mon, 11 Feb 2013 15:06:50 +0000
In-Reply-To: <9E695C71278D43F7A53208C5BF34FBA3@gmail.com>
References: <9E695C71278D43F7A53208C5BF34FBA3@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 11 Feb 2013 16:40:43 +0000
Cc: xen-users@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.0: unable to add disk 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

This seems like a -users question to me, please try and pick the
appropriate list for your questions. I've moved this there.

On Mon, 2013-02-11 at 14:53 +0000, Fabiano Francesconi wrote:
> Is there a way to reload all the stuff I've removed?

Rebooting is the most obvious way to reset to a known good state
quickly.

You could also try restarting the "xencommons" service.

However the only thing which should be in xenstore at start of day is
the domain 0 name, the rest should be created on the fly as needed, and
what you have now looks a lot like a fresh system to me, so I'm not
quite sure what is causing your issue.

I'm not 100% sure but perhaps this has also broken the backend driver's
watches on the xenstore. But I thought they were path based, rather than
based on the specific node, and so shouldn't be affected but perhaps I
am mistaken. Anyway, you could try rmmod and modprobe all of the Xen
related modules in your kernel (assuming they are mostly modular).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:41:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16:41: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 1U4wQv-00010Y-9n; Mon, 11 Feb 2013 16:40: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 1U4uyE-0006Mm-D3; Mon, 11 Feb 2013 15:07:02 +0000
Received: from [85.158.143.35:30304] by server-2.bemta-4.messagelabs.com id
	42/C0-01597-51909115; Mon, 11 Feb 2013 15:07:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1360595211!12444533!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30900 invoked from network); 11 Feb 2013 15:06:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 15:06:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1334394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 15:06: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.297.1;
	Mon, 11 Feb 2013 15:06:51 +0000
Message-ID: <1360595210.20449.52.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabiano Francesconi <fabiano.francesconi@gmail.com>
Date: Mon, 11 Feb 2013 15:06:50 +0000
In-Reply-To: <9E695C71278D43F7A53208C5BF34FBA3@gmail.com>
References: <9E695C71278D43F7A53208C5BF34FBA3@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 11 Feb 2013 16:40:43 +0000
Cc: xen-users@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.0: unable to add disk 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

This seems like a -users question to me, please try and pick the
appropriate list for your questions. I've moved this there.

On Mon, 2013-02-11 at 14:53 +0000, Fabiano Francesconi wrote:
> Is there a way to reload all the stuff I've removed?

Rebooting is the most obvious way to reset to a known good state
quickly.

You could also try restarting the "xencommons" service.

However the only thing which should be in xenstore at start of day is
the domain 0 name, the rest should be created on the fly as needed, and
what you have now looks a lot like a fresh system to me, so I'm not
quite sure what is causing your issue.

I'm not 100% sure but perhaps this has also broken the backend driver's
watches on the xenstore. But I thought they were path based, rather than
based on the specific node, and so shouldn't be affected but perhaps I
am mistaken. Anyway, you could try rmmod and modprobe all of the Xen
related modules in your kernel (assuming they are mostly modular).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:57:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16: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 1U4wh5-0001EY-9I; Mon, 11 Feb 2013 16:57:27 +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 1U4wh3-0001ET-Gt
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:57:25 +0000
Received: from [85.158.139.211:9411] by server-9.bemta-5.messagelabs.com id
	F7/75-24440-4F229115; Mon, 11 Feb 2013 16:57:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360601840!21625031!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5233 invoked from network); 11 Feb 2013 16:57:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 16:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6681983"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 16:57:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 11:57:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U4wgx-0000s7-5u;
	Mon, 11 Feb 2013 16:57:19 +0000
Message-ID: <1360601839.16636.40.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Mon, 11 Feb 2013 16:57:19 +0000
In-Reply-To: <511919AB.3070001@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<511919AB.3070001@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-11 at 16:17 +0000, Christopher S. Aker wrote:
> On 2/11/13 6:45 AM, Wei Liu wrote:
> > OK, so the guest is faulting at different offset now. It is very likely
> > that there is OOM / race condition in other places. And judging from
> > your two emails, I presume this bug can be reproduce steadily.
> 
> It is frequent enough to be a problem, yes.  We're constantly deploying 
> new servers and upgrading the stack on existing ones, so testing changes 
> won't be a problem.
> 
> > A quick check on the xen_spinlock struct, its offset should not be
> > 0x8b8. Reading the backtrace suggests that it is the netbk struct is
> > gone.
> 
> Great, we've narrowed it down some.
> 
> > Do you manipulate the number of vcpus Dom0 has after it's up?
> 
> No, we do not.
> 

Ha, strange. But a second thought come to me that even if you manipulate
number of cpus of Dom0, it should not cause problem like this.

Could you post your kernel config file.


Wei.

> Thanks,
> -Chris
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 16:57:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 16: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 1U4wh5-0001EY-9I; Mon, 11 Feb 2013 16:57:27 +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 1U4wh3-0001ET-Gt
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 16:57:25 +0000
Received: from [85.158.139.211:9411] by server-9.bemta-5.messagelabs.com id
	F7/75-24440-4F229115; Mon, 11 Feb 2013 16:57:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360601840!21625031!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI4Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5233 invoked from network); 11 Feb 2013 16:57:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 16:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="6681983"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	11 Feb 2013 16:57:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 11 Feb 2013 11:57:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U4wgx-0000s7-5u;
	Mon, 11 Feb 2013 16:57:19 +0000
Message-ID: <1360601839.16636.40.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Mon, 11 Feb 2013 16:57:19 +0000
In-Reply-To: <511919AB.3070001@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<511919AB.3070001@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-11 at 16:17 +0000, Christopher S. Aker wrote:
> On 2/11/13 6:45 AM, Wei Liu wrote:
> > OK, so the guest is faulting at different offset now. It is very likely
> > that there is OOM / race condition in other places. And judging from
> > your two emails, I presume this bug can be reproduce steadily.
> 
> It is frequent enough to be a problem, yes.  We're constantly deploying 
> new servers and upgrading the stack on existing ones, so testing changes 
> won't be a problem.
> 
> > A quick check on the xen_spinlock struct, its offset should not be
> > 0x8b8. Reading the backtrace suggests that it is the netbk struct is
> > gone.
> 
> Great, we've narrowed it down some.
> 
> > Do you manipulate the number of vcpus Dom0 has after it's up?
> 
> No, we do not.
> 

Ha, strange. But a second thought come to me that even if you manipulate
number of cpus of Dom0, it should not cause problem like this.

Could you post your kernel config file.


Wei.

> Thanks,
> -Chris
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 17:29:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:29: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 1U4xBl-0001ZN-9r; Mon, 11 Feb 2013 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 1U4xBk-0001ZF-0s
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 17:29:08 +0000
Received: from [85.158.139.83:25878] by server-16.bemta-5.messagelabs.com id
	B7/07-14948-36A29115; Mon, 11 Feb 2013 17:29:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360603746!31373091!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9068 invoked from network); 11 Feb 2013 17:29:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:29:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1341564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 17:29: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.297.1;
	Mon, 11 Feb 2013 17:29:05 +0000
Message-ID: <1360603744.20449.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Mon, 11 Feb 2013 17:29:04 +0000
In-Reply-To: <51151ABF.1070007@canonical.com>
References: <51151ABF.1070007@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
> A while ago I had been reporting an issue which causes Xen PVM guests
> to hang (apparently related to spinlocks). Since then I was able to
> gather a few more facts which I try to provide below. For the real
> reasons, I am still puzzled and would be thankful for any hints or
> direction.
> 
> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.

This is on a host with >= 8 PCPUs, correct?

> - When hanging at least 2 VCPUs in xen_spin_lock_slow with the lock free.
>   IIRC the weird lock always belongs to one VCPU runqueue.
> - Testcase shows the problem for guest kernel versions v3.2..v3.5 (not
>   verified farther back). Since v3.6 it cannot be reproduced. Bisect
>   ends up with: 611ae8e3f5204f7480b3b405993b3352cfa16662
>     "x86/tlb: enable tlb flush range support for x86"

That seems like a very odd candidate for impacting on this issue.

> - The other potential fix for this was to prevent xen_spin_lock_slow()
>   from unmasking events (enabling interrupts) if those were enabled
>   before the spinlock call.
> 
> Maybe allowing or not allowing the interrupts in xen_spin_lock_slow
> just manages to tip the likelihood of getting nested deeper.

Either that or the bug is in the nesting aspect of xen_spin_lock_slow(),
which seems to be a rather complex dance judging from the comments in
that function (and one I confess I don't really follow).

>  The same
> way that the changed TLB flush may reduce it by causing lesser IPIs.

Ah, that might explain why that patch is relevant, yes.

> From the static information I can extract from a dump it is hard to
> tell what exactly is going on. VCPU2 seems to be doing something but
> looks to be rather deep in event handling. The irq_count is at 2, but
> irq_count seems to be used in a few more places than just xen_hypervisor
> callback. Though that at least seems to be the entry on the stack I can
> see for VCPU2. The contents of the per-cpu variables for irq_reqs and
> irq_stack_ptr at least seem consistent as if a callback came in while
> being on the sched_op hypercall. But then the bt command seems to be
> operating on a completely different stack.
> VCPU2 seems to be active, not polling (event processing could be initiated
> from enable_irqs via force callback or before finally exiting the sched_op
> hypercall), there seems to be a pending upcall but upcalls are masked.
> The next thing I would try is to instrument the sites incrementing and
> decrementing irq_count...
> ---
> 
> Below some of the info seen from dom0 debugging keys and looking
> at a dump with crash:
> 
> Dom0 Info:
> 
> Polling vCPUs: {1,5-7}
> VCPU0: CPU0 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU1: CPU1 [has=F] poll=10 upcall_pend = 00, upcall_mask = 00
> VCPU2: CPU6 [has=T] poll=0  upcall_pend = 01, upcall_mask = 01
> VCPU3: CPU2 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU4: CPU4 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU5: CPU3 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU6: CPU7 [has=F] poll=40 upcall_pend = 01, upcall_mask = 01
> VCPU7: CPU4 [has=F] poll=46 upcall_pend = 01, upcall_mask = 01
> 
> 10 [0/1]: s=6 n=1 x=0
> 40 [0/1]: s=6 n=6 x=0
> 46 [0/1]: s=6 n=7 x=0
> 
> Guest Info:
> 
> lock_spinners:
> [0] (struct xen_spinlock *) 0x
> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 = { lock=1, spinners=2 }
> [2] (struct xen_spinlock *) 0xffff8803bfc93700 = { lock=0, spinners=2 }

If I understand correctly this means that 2 threads (VCPU2 & 6, I
suppose) are spinning on this lock, but no one is holding it?

An interesting hack^Wexperiment might be to make xen_poll_irq use a
timeout and see if that unwedges things -- this would help confirm that
the issue is on nested wakeup.

I suppose xen_spin_unlock could also be instrumented to indicate who it
last kicked and for which lock and that might show us something?

Can someone explain why the non-locked update of lock_spinners in
spinning_lock() is safe against xen_spin_unlock reading the field from
another VCPU? I suspect it isn't, so what happens if the other VCPU
kicks the lock which is just about to become prev? maybe this is handled
in xen_spin_lock_slow somehow?

In a similar vein do we not need a barrier in unspinning_lock to ensure
that the remote cpu sees prev getting restored?

> [3] (struct xen_spinlock *) 0x
> [4] (struct xen_spinlock *) 0x
> [5] (struct xen_spinlock *) 0xffff8803bffc8ae8 -> [1]
> [6] (struct xen_spinlock *) 0xffff8803bfc93700 -> [2]
> [7] (struct xen_spinlock *) 0xffffffff81f15ef0 = { lock=1, spinners=1 }
> 
> VCPU[2,6] -> lock of runqueue[2] = (struct rq *) 0xffff8803bfc93700
> 
> irq_count[1] = 1
> irq_count[2] = 2
> It is -1 for the rest.
> 
> *(struct pt_regs *) irq_regs[2] = {
> 	.ip = 0xffffffff810013aa == hypercall_page+938 -> sched_op
> 	.sp = 0xffff8803bfc83ce8
> }
> 
> char *irq_stack_ptr[2] = 0xffff8803bfc83fc0
> 
> #> bt -T ffff88033d65c4a0
> PID: 2050   TASK: ffff88033d65c4a0  CPU: 2   COMMAND: "postgres"
>   [ffff88033d72d530] get_page_from_freelist at ffffffff8111e6df
>   [ffff88033d72d600] __alloc_pages_nodemask at ffffffff8111ebec
>   [ffff88033d72d620] check_preempt_curr at ffffffff81050254
>   [ffff88033d72d640] pull_task at ffffffff8105e33e
>   [ffff88033d72d670] balance_tasks at ffffffff8105e4b6
>   [ffff88033d72d680] radix_tree_lookup_slot at ffffffff8130db5e
>   [ffff88033d72d690] find_get_page at ffffffff811161ee
>   [ffff88033d72d6b0] find_lock_page at ffffffff81116286
>   [ffff88033d72d6e0] shmem_getpage_gfp at ffffffff8112dd10
>   [ffff88033d72d748] pte_pfn_to_mfn at ffffffff81005a78
>   [ffff88033d72d7a0] get_page_from_freelist at ffffffff8111e6df
>   [ffff88033d72d7c0] _raw_spin_lock at ffffffff81655e4e
>   [ffff88033d72d7d0] ext4_ext_check_cache at ffffffff81239248
>   [ffff88033d72d820] ext4_ext_map_blocks at ffffffff8123e269
>   [ffff88033d72d870] _raw_spin_lock at ffffffff81655e4e
>   [ffff88033d72d880] enqueue_to_backlog at ffffffff8153e55f
>   [ffff88033d72d890] __wake_up_common at ffffffff8104c1c8
>   [ffff88033d72d8e0] netif_rx.part.82 at ffffffff8153f2de
>   [ffff88033d72d920] netif_rx at ffffffff8153f400
>   [ffff88033d72d960] loopback_xmit at ffffffff8146fb1c
>   [ffff88033d72d990] dev_hard_start_xmit at ffffffff8153fea6
>   [ffff88033d72d9d0] do_softirq at ffffffff81016284
>   [ffff88033d72d9f0] local_bh_enable at ffffffff8106d614
>   [ffff88033d72da00] dev_queue_xmit at ffffffff81540309
>   [ffff88033d72da50] ip_finish_output at ffffffff815769ab
>   [ffff88033d72da90] ip_output at ffffffff81577518
>   [ffff88033d72dac0] ip_local_out at ffffffff81576c09
>   [ffff88033d72dae0] ip_send_skb at ffffffff81577f4b
>   [ffff88033d72db00] udp_send_skb at ffffffff8159aaa1
>   [ffff88033d72db40] ip_generic_getfrag at ffffffff81575030
>   [ffff88033d72db50] udp_sendmsg at ffffffff8159bd38
>   [ffff88033d72db90] irq_to_desc at ffffffff810d70b7
>   [ffff88033d72dbd0] notify_remote_via_irq at ffffffff813a74c1
>   [ffff88033d72dc10] ttwu_queue at ffffffff81052672
>   [ffff88033d72dc38] _raw_spin_unlock_irqrestore at ffffffff8165605e
>   [ffff88033d72dc90] inet_sendmsg at ffffffff815a6474
>   --- bt -t would end here
>   [ffff88033d72dcb0] apparmor_socket_sendmsg at ffffffff812d43f7
>   [ffff88033d72dcd0] sock_sendmsg at ffffffff815266fe
>   [ffff88033d72dd70] md_make_request at ffffffff814e0606
>   [ffff88033d72ddd0] kmem_cache_free at ffffffff811605cf
>   [ffff88033d72de10] mempool_free_slab at ffffffff81118507
>   [ffff88033d72de20] mempool_free at ffffffff811185b7
>   [ffff88033d72de50] sys_sendto at ffffffff8152974d
>   [ffff88033d72dee0] ext4_sync_file at ffffffff8120f07b
>   [ffff88033d72df00] vfs_write at ffffffff811764b0
>   [ffff88033d72df50] xen_hypervisor_callback at ffffffff816606db
>     RIP: 00007f6852c7b39a  RSP: 00007fff431454e0  RFLAGS: 00000212
>     RAX: 00007f6852fb38b8  RBX: 00007f6852fb3720  RCX: 000000000000014a
>     RDX: 0000000000000150  RSI: 0000000000000140  RDI: 00007f6852fb3720
>     RBP: 0000000000000150   R8: 0000000000000015   R9: 0000000000000000
>     R10: 0000000000000000  R11: 00007f6852c9174a  R12: 00007f6852fb3778
>     R13: 0000000000000140  R14: 00007f6852fb38b8  R15: 0000000000000001
>     ORIG_RAX: ffffffffffffffff  CS: e033  SS: e02b
> 
> #> bt -T ffff88033b812dc0
> PID: 2069   TASK: ffff88033b812dc0  CPU: 6   COMMAND: "postgres"
>   [ffff88033b897530] get_page_from_freelist at ffffffff8111e6df
>   [ffff88033b897600] __alloc_pages_nodemask at ffffffff8111ebec
>   [ffff88033b897640] radix_tree_lookup at ffffffff8130db6b
>   [ffff88033b897650] irq_to_desc at ffffffff810d70b7
>   [ffff88033b897660] irq_get_irq_data at ffffffff810d9f4e
>   [ffff88033b897670] balance_tasks at ffffffff8105e493
>   [ffff88033b897680] radix_tree_lookup_slot at ffffffff8130db5e
>   [ffff88033b897690] find_get_page at ffffffff811161ee
>   [ffff88033b8976b0] find_lock_page at ffffffff81116286
>   [ffff88033b8976e0] shmem_getpage_gfp at ffffffff8112dd10
>   [ffff88033b897748] pte_pfn_to_mfn at ffffffff81005a78
>   [ffff88033b897770] xen_set_pte_at at ffffffff81008e29
>   [ffff88033b897788] __raw_callee_save_xen_make_pte at ffffffff810052cd
>   [ffff88033b8977b0] unlock_page at ffffffff8111589a
>   [ffff88033b8977d0] __do_fault at ffffffff81138ac9
>   [ffff88033b8978a0] pvclock_clocksource_read at ffffffff8103dd15
>   [ffff88033b8978f0] xen_clocksource_read at ffffffff8100a850
>   [ffff88033b897900] sched_clock at ffffffff8101bd79
>   [ffff88033b897910] blk_rq_init at ffffffff812ec262
>   [ffff88033b897930] get_request at ffffffff812f004e
>   [ffff88033b8979c0] cpumask_next_and at ffffffff81308c66
>   [ffff88033b8979e0] find_busiest_group at ffffffff8105a061
>   --- bt -t ends here
>   [ffff88033b897a30] radix_tree_lookup at ffffffff8130db6b
>   [ffff88033b897a40] irq_to_desc at ffffffff810d70b7
>   [ffff88033b897a50] irq_get_irq_data at ffffffff810d9f4e
>   [ffff88033b897a60] info_for_irq at ffffffff813a636e
>   [ffff88033b897a80] xen_poll_irq_timeout at ffffffff813a696e
>   [ffff88033b897ac0] xen_poll_irq at ffffffff813a8450
>   [ffff88033b897ad0] xen_spin_lock_slow at ffffffff8163ad77
>   [ffff88033b897b20] xen_spin_lock at ffffffff810121da
>   [ffff88033b897b40] _raw_spin_lock at ffffffff81655e4e
>   [ffff88033b897b50] double_rq_lock at ffffffff8105119c
>   [ffff88033b897b80] load_balance at ffffffff8105e788
>   [ffff88033b897b88] _raw_spin_unlock_irqrestore at ffffffff8165605e
>   [ffff88033b897c10] idle_balance at ffffffff8163d57c
>   [ffff88033b897c60] __schedule at ffffffff81653ea9
>   [ffff88033b897cc0] sleep_on_page at ffffffff81115810
>   [ffff88033b897ce0] schedule at ffffffff81653fcf
>   [ffff88033b897cf0] io_schedule at ffffffff8165407f
>   [ffff88033b897d10] sleep_on_page at ffffffff8111581e
>   [ffff88033b897d20] __wait_on_bit at ffffffff8165489f
>   [ffff88033b897d70] wait_on_page_bit at ffffffff81115988
>   [ffff88033b897da0] wake_bit_function at ffffffff8108a140
>   [ffff88033b897dc0] filemap_fdatawait_range at ffffffff81115a9c
>   [ffff88033b897e60] do_writepages at ffffffff81120ee1
>   [ffff88033b897eb0] filemap_write_and_wait_range at ffffffff81117398
>   [ffff88033b897ee0] ext4_sync_file at ffffffff8120ef9f
>   [ffff88033b897f00] vfs_write at ffffffff811764b0
>   [ffff88033b897f40] do_fsync at ffffffff811a4a36
>   [ffff88033b897f70] sys_fdatasync at ffffffff811a4d83
>   [ffff88033b897f80] system_call_fastpath at ffffffff8165e442
>     RIP: 00007f6852ce8240  RSP: 00007fff43145618  RFLAGS: 00000246
>     RAX: 000000000000004b  RBX: ffffffff8165e442  RCX: 00007f6852ce1900
>     RDX: 00000000000000c5  RSI: 000000000000000c  RDI: 000000000000000c
>     RBP: 00000000000000c5   R8: 000000000073a550   R9: 0000000000000000
>     R10: 0000000000000004  R11: 0000000000000246  R12: ffffffff811a4d83
>     R13: ffff88033b897f78  R14: 0000000000000001  R15: 0000000000af7488
>     ORIG_RAX: 000000000000004b  CS: e033  SS: e02b
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 17:29:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:29: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 1U4xBl-0001ZN-9r; Mon, 11 Feb 2013 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 1U4xBk-0001ZF-0s
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 17:29:08 +0000
Received: from [85.158.139.83:25878] by server-16.bemta-5.messagelabs.com id
	B7/07-14948-36A29115; Mon, 11 Feb 2013 17:29:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360603746!31373091!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9068 invoked from network); 11 Feb 2013 17:29:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:29:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1341564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 17:29: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.297.1;
	Mon, 11 Feb 2013 17:29:05 +0000
Message-ID: <1360603744.20449.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Mon, 11 Feb 2013 17:29:04 +0000
In-Reply-To: <51151ABF.1070007@canonical.com>
References: <51151ABF.1070007@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
> A while ago I had been reporting an issue which causes Xen PVM guests
> to hang (apparently related to spinlocks). Since then I was able to
> gather a few more facts which I try to provide below. For the real
> reasons, I am still puzzled and would be thankful for any hints or
> direction.
> 
> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.

This is on a host with >= 8 PCPUs, correct?

> - When hanging at least 2 VCPUs in xen_spin_lock_slow with the lock free.
>   IIRC the weird lock always belongs to one VCPU runqueue.
> - Testcase shows the problem for guest kernel versions v3.2..v3.5 (not
>   verified farther back). Since v3.6 it cannot be reproduced. Bisect
>   ends up with: 611ae8e3f5204f7480b3b405993b3352cfa16662
>     "x86/tlb: enable tlb flush range support for x86"

That seems like a very odd candidate for impacting on this issue.

> - The other potential fix for this was to prevent xen_spin_lock_slow()
>   from unmasking events (enabling interrupts) if those were enabled
>   before the spinlock call.
> 
> Maybe allowing or not allowing the interrupts in xen_spin_lock_slow
> just manages to tip the likelihood of getting nested deeper.

Either that or the bug is in the nesting aspect of xen_spin_lock_slow(),
which seems to be a rather complex dance judging from the comments in
that function (and one I confess I don't really follow).

>  The same
> way that the changed TLB flush may reduce it by causing lesser IPIs.

Ah, that might explain why that patch is relevant, yes.

> From the static information I can extract from a dump it is hard to
> tell what exactly is going on. VCPU2 seems to be doing something but
> looks to be rather deep in event handling. The irq_count is at 2, but
> irq_count seems to be used in a few more places than just xen_hypervisor
> callback. Though that at least seems to be the entry on the stack I can
> see for VCPU2. The contents of the per-cpu variables for irq_reqs and
> irq_stack_ptr at least seem consistent as if a callback came in while
> being on the sched_op hypercall. But then the bt command seems to be
> operating on a completely different stack.
> VCPU2 seems to be active, not polling (event processing could be initiated
> from enable_irqs via force callback or before finally exiting the sched_op
> hypercall), there seems to be a pending upcall but upcalls are masked.
> The next thing I would try is to instrument the sites incrementing and
> decrementing irq_count...
> ---
> 
> Below some of the info seen from dom0 debugging keys and looking
> at a dump with crash:
> 
> Dom0 Info:
> 
> Polling vCPUs: {1,5-7}
> VCPU0: CPU0 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU1: CPU1 [has=F] poll=10 upcall_pend = 00, upcall_mask = 00
> VCPU2: CPU6 [has=T] poll=0  upcall_pend = 01, upcall_mask = 01
> VCPU3: CPU2 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU4: CPU4 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU5: CPU3 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> VCPU6: CPU7 [has=F] poll=40 upcall_pend = 01, upcall_mask = 01
> VCPU7: CPU4 [has=F] poll=46 upcall_pend = 01, upcall_mask = 01
> 
> 10 [0/1]: s=6 n=1 x=0
> 40 [0/1]: s=6 n=6 x=0
> 46 [0/1]: s=6 n=7 x=0
> 
> Guest Info:
> 
> lock_spinners:
> [0] (struct xen_spinlock *) 0x
> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 = { lock=1, spinners=2 }
> [2] (struct xen_spinlock *) 0xffff8803bfc93700 = { lock=0, spinners=2 }

If I understand correctly this means that 2 threads (VCPU2 & 6, I
suppose) are spinning on this lock, but no one is holding it?

An interesting hack^Wexperiment might be to make xen_poll_irq use a
timeout and see if that unwedges things -- this would help confirm that
the issue is on nested wakeup.

I suppose xen_spin_unlock could also be instrumented to indicate who it
last kicked and for which lock and that might show us something?

Can someone explain why the non-locked update of lock_spinners in
spinning_lock() is safe against xen_spin_unlock reading the field from
another VCPU? I suspect it isn't, so what happens if the other VCPU
kicks the lock which is just about to become prev? maybe this is handled
in xen_spin_lock_slow somehow?

In a similar vein do we not need a barrier in unspinning_lock to ensure
that the remote cpu sees prev getting restored?

> [3] (struct xen_spinlock *) 0x
> [4] (struct xen_spinlock *) 0x
> [5] (struct xen_spinlock *) 0xffff8803bffc8ae8 -> [1]
> [6] (struct xen_spinlock *) 0xffff8803bfc93700 -> [2]
> [7] (struct xen_spinlock *) 0xffffffff81f15ef0 = { lock=1, spinners=1 }
> 
> VCPU[2,6] -> lock of runqueue[2] = (struct rq *) 0xffff8803bfc93700
> 
> irq_count[1] = 1
> irq_count[2] = 2
> It is -1 for the rest.
> 
> *(struct pt_regs *) irq_regs[2] = {
> 	.ip = 0xffffffff810013aa == hypercall_page+938 -> sched_op
> 	.sp = 0xffff8803bfc83ce8
> }
> 
> char *irq_stack_ptr[2] = 0xffff8803bfc83fc0
> 
> #> bt -T ffff88033d65c4a0
> PID: 2050   TASK: ffff88033d65c4a0  CPU: 2   COMMAND: "postgres"
>   [ffff88033d72d530] get_page_from_freelist at ffffffff8111e6df
>   [ffff88033d72d600] __alloc_pages_nodemask at ffffffff8111ebec
>   [ffff88033d72d620] check_preempt_curr at ffffffff81050254
>   [ffff88033d72d640] pull_task at ffffffff8105e33e
>   [ffff88033d72d670] balance_tasks at ffffffff8105e4b6
>   [ffff88033d72d680] radix_tree_lookup_slot at ffffffff8130db5e
>   [ffff88033d72d690] find_get_page at ffffffff811161ee
>   [ffff88033d72d6b0] find_lock_page at ffffffff81116286
>   [ffff88033d72d6e0] shmem_getpage_gfp at ffffffff8112dd10
>   [ffff88033d72d748] pte_pfn_to_mfn at ffffffff81005a78
>   [ffff88033d72d7a0] get_page_from_freelist at ffffffff8111e6df
>   [ffff88033d72d7c0] _raw_spin_lock at ffffffff81655e4e
>   [ffff88033d72d7d0] ext4_ext_check_cache at ffffffff81239248
>   [ffff88033d72d820] ext4_ext_map_blocks at ffffffff8123e269
>   [ffff88033d72d870] _raw_spin_lock at ffffffff81655e4e
>   [ffff88033d72d880] enqueue_to_backlog at ffffffff8153e55f
>   [ffff88033d72d890] __wake_up_common at ffffffff8104c1c8
>   [ffff88033d72d8e0] netif_rx.part.82 at ffffffff8153f2de
>   [ffff88033d72d920] netif_rx at ffffffff8153f400
>   [ffff88033d72d960] loopback_xmit at ffffffff8146fb1c
>   [ffff88033d72d990] dev_hard_start_xmit at ffffffff8153fea6
>   [ffff88033d72d9d0] do_softirq at ffffffff81016284
>   [ffff88033d72d9f0] local_bh_enable at ffffffff8106d614
>   [ffff88033d72da00] dev_queue_xmit at ffffffff81540309
>   [ffff88033d72da50] ip_finish_output at ffffffff815769ab
>   [ffff88033d72da90] ip_output at ffffffff81577518
>   [ffff88033d72dac0] ip_local_out at ffffffff81576c09
>   [ffff88033d72dae0] ip_send_skb at ffffffff81577f4b
>   [ffff88033d72db00] udp_send_skb at ffffffff8159aaa1
>   [ffff88033d72db40] ip_generic_getfrag at ffffffff81575030
>   [ffff88033d72db50] udp_sendmsg at ffffffff8159bd38
>   [ffff88033d72db90] irq_to_desc at ffffffff810d70b7
>   [ffff88033d72dbd0] notify_remote_via_irq at ffffffff813a74c1
>   [ffff88033d72dc10] ttwu_queue at ffffffff81052672
>   [ffff88033d72dc38] _raw_spin_unlock_irqrestore at ffffffff8165605e
>   [ffff88033d72dc90] inet_sendmsg at ffffffff815a6474
>   --- bt -t would end here
>   [ffff88033d72dcb0] apparmor_socket_sendmsg at ffffffff812d43f7
>   [ffff88033d72dcd0] sock_sendmsg at ffffffff815266fe
>   [ffff88033d72dd70] md_make_request at ffffffff814e0606
>   [ffff88033d72ddd0] kmem_cache_free at ffffffff811605cf
>   [ffff88033d72de10] mempool_free_slab at ffffffff81118507
>   [ffff88033d72de20] mempool_free at ffffffff811185b7
>   [ffff88033d72de50] sys_sendto at ffffffff8152974d
>   [ffff88033d72dee0] ext4_sync_file at ffffffff8120f07b
>   [ffff88033d72df00] vfs_write at ffffffff811764b0
>   [ffff88033d72df50] xen_hypervisor_callback at ffffffff816606db
>     RIP: 00007f6852c7b39a  RSP: 00007fff431454e0  RFLAGS: 00000212
>     RAX: 00007f6852fb38b8  RBX: 00007f6852fb3720  RCX: 000000000000014a
>     RDX: 0000000000000150  RSI: 0000000000000140  RDI: 00007f6852fb3720
>     RBP: 0000000000000150   R8: 0000000000000015   R9: 0000000000000000
>     R10: 0000000000000000  R11: 00007f6852c9174a  R12: 00007f6852fb3778
>     R13: 0000000000000140  R14: 00007f6852fb38b8  R15: 0000000000000001
>     ORIG_RAX: ffffffffffffffff  CS: e033  SS: e02b
> 
> #> bt -T ffff88033b812dc0
> PID: 2069   TASK: ffff88033b812dc0  CPU: 6   COMMAND: "postgres"
>   [ffff88033b897530] get_page_from_freelist at ffffffff8111e6df
>   [ffff88033b897600] __alloc_pages_nodemask at ffffffff8111ebec
>   [ffff88033b897640] radix_tree_lookup at ffffffff8130db6b
>   [ffff88033b897650] irq_to_desc at ffffffff810d70b7
>   [ffff88033b897660] irq_get_irq_data at ffffffff810d9f4e
>   [ffff88033b897670] balance_tasks at ffffffff8105e493
>   [ffff88033b897680] radix_tree_lookup_slot at ffffffff8130db5e
>   [ffff88033b897690] find_get_page at ffffffff811161ee
>   [ffff88033b8976b0] find_lock_page at ffffffff81116286
>   [ffff88033b8976e0] shmem_getpage_gfp at ffffffff8112dd10
>   [ffff88033b897748] pte_pfn_to_mfn at ffffffff81005a78
>   [ffff88033b897770] xen_set_pte_at at ffffffff81008e29
>   [ffff88033b897788] __raw_callee_save_xen_make_pte at ffffffff810052cd
>   [ffff88033b8977b0] unlock_page at ffffffff8111589a
>   [ffff88033b8977d0] __do_fault at ffffffff81138ac9
>   [ffff88033b8978a0] pvclock_clocksource_read at ffffffff8103dd15
>   [ffff88033b8978f0] xen_clocksource_read at ffffffff8100a850
>   [ffff88033b897900] sched_clock at ffffffff8101bd79
>   [ffff88033b897910] blk_rq_init at ffffffff812ec262
>   [ffff88033b897930] get_request at ffffffff812f004e
>   [ffff88033b8979c0] cpumask_next_and at ffffffff81308c66
>   [ffff88033b8979e0] find_busiest_group at ffffffff8105a061
>   --- bt -t ends here
>   [ffff88033b897a30] radix_tree_lookup at ffffffff8130db6b
>   [ffff88033b897a40] irq_to_desc at ffffffff810d70b7
>   [ffff88033b897a50] irq_get_irq_data at ffffffff810d9f4e
>   [ffff88033b897a60] info_for_irq at ffffffff813a636e
>   [ffff88033b897a80] xen_poll_irq_timeout at ffffffff813a696e
>   [ffff88033b897ac0] xen_poll_irq at ffffffff813a8450
>   [ffff88033b897ad0] xen_spin_lock_slow at ffffffff8163ad77
>   [ffff88033b897b20] xen_spin_lock at ffffffff810121da
>   [ffff88033b897b40] _raw_spin_lock at ffffffff81655e4e
>   [ffff88033b897b50] double_rq_lock at ffffffff8105119c
>   [ffff88033b897b80] load_balance at ffffffff8105e788
>   [ffff88033b897b88] _raw_spin_unlock_irqrestore at ffffffff8165605e
>   [ffff88033b897c10] idle_balance at ffffffff8163d57c
>   [ffff88033b897c60] __schedule at ffffffff81653ea9
>   [ffff88033b897cc0] sleep_on_page at ffffffff81115810
>   [ffff88033b897ce0] schedule at ffffffff81653fcf
>   [ffff88033b897cf0] io_schedule at ffffffff8165407f
>   [ffff88033b897d10] sleep_on_page at ffffffff8111581e
>   [ffff88033b897d20] __wait_on_bit at ffffffff8165489f
>   [ffff88033b897d70] wait_on_page_bit at ffffffff81115988
>   [ffff88033b897da0] wake_bit_function at ffffffff8108a140
>   [ffff88033b897dc0] filemap_fdatawait_range at ffffffff81115a9c
>   [ffff88033b897e60] do_writepages at ffffffff81120ee1
>   [ffff88033b897eb0] filemap_write_and_wait_range at ffffffff81117398
>   [ffff88033b897ee0] ext4_sync_file at ffffffff8120ef9f
>   [ffff88033b897f00] vfs_write at ffffffff811764b0
>   [ffff88033b897f40] do_fsync at ffffffff811a4a36
>   [ffff88033b897f70] sys_fdatasync at ffffffff811a4d83
>   [ffff88033b897f80] system_call_fastpath at ffffffff8165e442
>     RIP: 00007f6852ce8240  RSP: 00007fff43145618  RFLAGS: 00000246
>     RAX: 000000000000004b  RBX: ffffffff8165e442  RCX: 00007f6852ce1900
>     RDX: 00000000000000c5  RSI: 000000000000000c  RDI: 000000000000000c
>     RBP: 00000000000000c5   R8: 000000000073a550   R9: 0000000000000000
>     R10: 0000000000000004  R11: 0000000000000246  R12: ffffffff811a4d83
>     R13: ffff88033b897f78  R14: 0000000000000001  R15: 0000000000af7488
>     ORIG_RAX: 000000000000004b  CS: e033  SS: e02b
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 17:32:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:32: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 1U4xEW-0001ee-Sp; Mon, 11 Feb 2013 17:32:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U4xEV-0001eX-GI
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 17:31:59 +0000
Received: from [85.158.139.83:54167] by server-4.bemta-5.messagelabs.com id
	66/7B-29496-E0B29115; Mon, 11 Feb 2013 17:31:58 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360603886!24802871!1
X-Originating-IP: [209.85.128.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDM1MjIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6682 invoked from network); 11 Feb 2013 17:31:28 -0000
Received: from mail-ve0-f178.google.com (HELO mail-ve0-f178.google.com)
	(209.85.128.178)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:31:28 -0000
Received: by mail-ve0-f178.google.com with SMTP id db10so5298636veb.23
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 09:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:from:date:message-id:subject:to
	:content-type; bh=JjhJj80+nCsmR3SczjZNu1iKv4f1SlqZdIYM47CCRPg=;
	b=d8tnOVyvMo7UIXOqxXA2SdB0RpoAmdNqCyXQqi56zfmsgxM6EfWoI4Ul7RjGXKstme
	sF31sGrQz7nxFeP72VamYA4d2kGxCfaGvjvxdsdS8h2vRxqX9drNJ3Lkjo9A2Itr200i
	1RxNOkCpk1/pEMP59U53oPMLEjDMzw1O2ZKwkVw4V5GpU3d/o8gOdj+CwtLzO0s5flS5
	sHbbiHpRVHA8tcYVwjJt0BLnOJM8+WHRXDcfaXoI04rknHBsf/LqvvqNHwo3tXzu6bs5
	1HQ5bMrX8KDcDDBn0U8sGWYidJiahx4To/Yy37ugcPid03R9UhC8HDrZ3YuuY6DQ/MjX
	2diw==
X-Received: by 10.52.96.163 with SMTP id dt3mr17147078vdb.11.1360603886180;
	Mon, 11 Feb 2013 09:31:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Mon, 11 Feb 2013 09:31:06 -0800 (PST)
From: povder <povder@gmail.com>
Date: Mon, 11 Feb 2013 18:31:06 +0100
Message-ID: <CACvNfPy2qSSkUqF+C2NY87RmbRXjHaE_K+ZQH4dZEN_X0iYcZg@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

Hi all

I already posted about this problem on xen-users some time ago
(http://markmail.org/message/sbgtyjqh6bzmqx4s) but I couldn't
resolve my problem using help from people on xen-users, so I'm posting here .

I have a problem with enabling IOMMU on Xen 4.2.1. When I enable it in BIOS
and in grub.conf using iommu=1 kernel option, my machine cannot boot.
I get a following error on serial console:

(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at pci_amd_iommu.c:35
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Is it a bug in Xen or maybe bug in BIOS?

I run CentOS 6.3 and use dom0 kernel 3.7.1 and Xen from
http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository,
but I also tried with other 3.x and 2.6.32 kernels and different Xen
builds with no luck.

GRUB entry:
 title CentOS Xen kernel IOMMU serial console (3.7.1-3.el6xen.x86_64)
        root (hd0,0)
        kernel /xen.gz dom0_mem=1G,max:1G dom0_max_vcpus=1
dom0_vcpus_pin iommu=verbose loglvl=all guest_loglvl=all iommu=1
com1=38400,8n1 console=com1
        module /vmlinuz-3.7.1-3.el6xen.x86_64 ro
root=/dev/mapper/vg_titan_raid5-lv_titan_root
rd_LVM_LV=vg_titan_raid5/lv_titan_root rd_NO_LUKS LANG=en_US.UTF-8
rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto
rd_LVM_LV=vg_titan_raid5/lv_titan_swap  KEYBOARDTYPE=pc KEYTABLE=us
rd_NO_DM console=hvc0 earlyprintk=xen nomodeset
        module /initramfs-3.7.1-3.el6xen.x86_64.img

Hardware info:
 Motherboard: ASUS M4A89TD PRO USB3 (AMD 890FX chipset, reported to
work with IOMMU on Xen wiki)
 CPU: AMD Phenom II X6 1045T

Software info:
 OS: CentOS 6.3 64bit
 Xen: 4.2.1
 BIOS version: 3029 (up to date, also tried with older versions)

Detailed information:
 Full serial output: http://pastebin.com/raw.php?i=K1DuhDcj
 xl info (when booting with iommu=0): http://pastebin.com/raw.php?i=jU7bEFrN
 lspci -vvv: http://pastebin.com/raw.php?i=3wpKPQT9
 dmidecode: http://pastebin.com/raw.php?i=7wEcTXzr
 kernel config: http://pastebin.com/raw.php?i=zYgGZ84f

Please help
povder

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 17:32:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:32: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 1U4xEW-0001ee-Sp; Mon, 11 Feb 2013 17:32:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U4xEV-0001eX-GI
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 17:31:59 +0000
Received: from [85.158.139.83:54167] by server-4.bemta-5.messagelabs.com id
	66/7B-29496-E0B29115; Mon, 11 Feb 2013 17:31:58 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360603886!24802871!1
X-Originating-IP: [209.85.128.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDM1MjIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6682 invoked from network); 11 Feb 2013 17:31:28 -0000
Received: from mail-ve0-f178.google.com (HELO mail-ve0-f178.google.com)
	(209.85.128.178)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:31:28 -0000
Received: by mail-ve0-f178.google.com with SMTP id db10so5298636veb.23
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 09:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:from:date:message-id:subject:to
	:content-type; bh=JjhJj80+nCsmR3SczjZNu1iKv4f1SlqZdIYM47CCRPg=;
	b=d8tnOVyvMo7UIXOqxXA2SdB0RpoAmdNqCyXQqi56zfmsgxM6EfWoI4Ul7RjGXKstme
	sF31sGrQz7nxFeP72VamYA4d2kGxCfaGvjvxdsdS8h2vRxqX9drNJ3Lkjo9A2Itr200i
	1RxNOkCpk1/pEMP59U53oPMLEjDMzw1O2ZKwkVw4V5GpU3d/o8gOdj+CwtLzO0s5flS5
	sHbbiHpRVHA8tcYVwjJt0BLnOJM8+WHRXDcfaXoI04rknHBsf/LqvvqNHwo3tXzu6bs5
	1HQ5bMrX8KDcDDBn0U8sGWYidJiahx4To/Yy37ugcPid03R9UhC8HDrZ3YuuY6DQ/MjX
	2diw==
X-Received: by 10.52.96.163 with SMTP id dt3mr17147078vdb.11.1360603886180;
	Mon, 11 Feb 2013 09:31:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Mon, 11 Feb 2013 09:31:06 -0800 (PST)
From: povder <povder@gmail.com>
Date: Mon, 11 Feb 2013 18:31:06 +0100
Message-ID: <CACvNfPy2qSSkUqF+C2NY87RmbRXjHaE_K+ZQH4dZEN_X0iYcZg@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

Hi all

I already posted about this problem on xen-users some time ago
(http://markmail.org/message/sbgtyjqh6bzmqx4s) but I couldn't
resolve my problem using help from people on xen-users, so I'm posting here .

I have a problem with enabling IOMMU on Xen 4.2.1. When I enable it in BIOS
and in grub.conf using iommu=1 kernel option, my machine cannot boot.
I get a following error on serial console:

(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at pci_amd_iommu.c:35
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Is it a bug in Xen or maybe bug in BIOS?

I run CentOS 6.3 and use dom0 kernel 3.7.1 and Xen from
http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository,
but I also tried with other 3.x and 2.6.32 kernels and different Xen
builds with no luck.

GRUB entry:
 title CentOS Xen kernel IOMMU serial console (3.7.1-3.el6xen.x86_64)
        root (hd0,0)
        kernel /xen.gz dom0_mem=1G,max:1G dom0_max_vcpus=1
dom0_vcpus_pin iommu=verbose loglvl=all guest_loglvl=all iommu=1
com1=38400,8n1 console=com1
        module /vmlinuz-3.7.1-3.el6xen.x86_64 ro
root=/dev/mapper/vg_titan_raid5-lv_titan_root
rd_LVM_LV=vg_titan_raid5/lv_titan_root rd_NO_LUKS LANG=en_US.UTF-8
rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto
rd_LVM_LV=vg_titan_raid5/lv_titan_swap  KEYBOARDTYPE=pc KEYTABLE=us
rd_NO_DM console=hvc0 earlyprintk=xen nomodeset
        module /initramfs-3.7.1-3.el6xen.x86_64.img

Hardware info:
 Motherboard: ASUS M4A89TD PRO USB3 (AMD 890FX chipset, reported to
work with IOMMU on Xen wiki)
 CPU: AMD Phenom II X6 1045T

Software info:
 OS: CentOS 6.3 64bit
 Xen: 4.2.1
 BIOS version: 3029 (up to date, also tried with older versions)

Detailed information:
 Full serial output: http://pastebin.com/raw.php?i=K1DuhDcj
 xl info (when booting with iommu=0): http://pastebin.com/raw.php?i=jU7bEFrN
 lspci -vvv: http://pastebin.com/raw.php?i=3wpKPQT9
 dmidecode: http://pastebin.com/raw.php?i=7wEcTXzr
 kernel config: http://pastebin.com/raw.php?i=zYgGZ84f

Please help
povder

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 17:35:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:35: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 1U4xHO-0001mU-Fn; Mon, 11 Feb 2013 17:34: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 1U4xHM-0001mJ-Gx
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 17:34:56 +0000
Received: from [85.158.138.51:53459] by server-15.bemta-3.messagelabs.com id
	1F/73-25405-FBB29115; Mon, 11 Feb 2013 17:34:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360604094!23073980!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2370 invoked from network); 11 Feb 2013 17:34:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1341722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 17:34: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.297.1; Mon, 11 Feb 2013 17:34:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U4xHK-0001LY-D2; Mon, 11 Feb 2013 17:34:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U4xHK-0003Un-46;
	Mon, 11 Feb 2013 17:34:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20761.11198.2141.731409@mariner.uk.xensource.com>
Date: Mon, 11 Feb 2013 17:34:54 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360583715.29432.141.camel@zakaz.uk.xensource.com>
References: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
	<1360583715.29432.141.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>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-unstable bisection] complete test-amd64-i386-xl-credit2"):
> This seems less likely than the oxenstored issue I mentioned in the
> "[xen-unstable test] 15452: regressions - FAIL" thread.

Yes.  It looks like I have messed up my osstest branches and
accidentally caused a version which uses oxenstored to be pushed
bypassing the push gate.  I'm undoing 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 Feb 11 17:35:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:35: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 1U4xHO-0001mU-Fn; Mon, 11 Feb 2013 17:34: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 1U4xHM-0001mJ-Gx
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 17:34:56 +0000
Received: from [85.158.138.51:53459] by server-15.bemta-3.messagelabs.com id
	1F/73-25405-FBB29115; Mon, 11 Feb 2013 17:34:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360604094!23073980!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2370 invoked from network); 11 Feb 2013 17:34:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1341722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 17:34: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.297.1; Mon, 11 Feb 2013 17:34:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U4xHK-0001LY-D2; Mon, 11 Feb 2013 17:34:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U4xHK-0003Un-46;
	Mon, 11 Feb 2013 17:34:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20761.11198.2141.731409@mariner.uk.xensource.com>
Date: Mon, 11 Feb 2013 17:34:54 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360583715.29432.141.camel@zakaz.uk.xensource.com>
References: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
	<1360583715.29432.141.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>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-unstable bisection] complete test-amd64-i386-xl-credit2"):
> This seems less likely than the oxenstored issue I mentioned in the
> "[xen-unstable test] 15452: regressions - FAIL" thread.

Yes.  It looks like I have messed up my osstest branches and
accidentally caused a version which uses oxenstored to be pushed
bypassing the push gate.  I'm undoing 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 Feb 11 17:41:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:41: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 1U4xNV-000239-HM; Mon, 11 Feb 2013 17:41:17 +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 1U4xNT-000234-Rl
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 17:41:16 +0000
Received: from [85.158.137.99:7511] by server-3.bemta-3.messagelabs.com id
	D8/4D-31070-63D29115; Mon, 11 Feb 2013 17:41:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360604468!15556194!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9617 invoked from network); 11 Feb 2013 17:41:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1342173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 17:41: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.297.1;
	Mon, 11 Feb 2013 17:41:07 +0000
Message-ID: <1360604466.20449.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 17:41:06 +0000
In-Reply-To: <20761.11198.2141.731409@mariner.uk.xensource.com>
References: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
	<1360583715.29432.141.camel@zakaz.uk.xensource.com>
	<20761.11198.2141.731409@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-11 at 17:34 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-credit2"):
> > This seems less likely than the oxenstored issue I mentioned in the
> > "[xen-unstable test] 15452: regressions - FAIL" thread.
> 
> Yes.  It looks like I have messed up my osstest branches and
> accidentally caused a version which uses oxenstored to be pushed
> bypassing the push gate.  I'm undoing this...

OK, but I think it is has also found an actual new bug in oxenstored
since I am fingering the XSA-38 changes in that thread...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 17:41:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 17:41: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 1U4xNV-000239-HM; Mon, 11 Feb 2013 17:41:17 +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 1U4xNT-000234-Rl
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 17:41:16 +0000
Received: from [85.158.137.99:7511] by server-3.bemta-3.messagelabs.com id
	D8/4D-31070-63D29115; Mon, 11 Feb 2013 17:41:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360604468!15556194!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9617 invoked from network); 11 Feb 2013 17:41:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 17:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; 
   d="scan'208";a="1342173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 17:41: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.297.1;
	Mon, 11 Feb 2013 17:41:07 +0000
Message-ID: <1360604466.20449.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 17:41:06 +0000
In-Reply-To: <20761.11198.2141.731409@mariner.uk.xensource.com>
References: <E1U4rpl-0005yA-BX@woking.cam.xci-test.com>
	<1360583715.29432.141.camel@zakaz.uk.xensource.com>
	<20761.11198.2141.731409@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-11 at 17:34 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-credit2"):
> > This seems less likely than the oxenstored issue I mentioned in the
> > "[xen-unstable test] 15452: regressions - FAIL" thread.
> 
> Yes.  It looks like I have messed up my osstest branches and
> accidentally caused a version which uses oxenstored to be pushed
> bypassing the push gate.  I'm undoing this...

OK, but I think it is has also found an actual new bug in oxenstored
since I am fingering the XSA-38 changes in that thread...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 18:45:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 18:45: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 1U4yMV-0002Vq-UW; Mon, 11 Feb 2013 18:44:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4yMU-0002Vl-F7
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 18:44:18 +0000
Received: from [85.158.139.83:64102] by server-1.bemta-5.messagelabs.com id
	C9/EF-29263-10C39115; Mon, 11 Feb 2013 18:44:17 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360608256!24493177!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7935 invoked from network); 11 Feb 2013 18:44:16 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-16.tower-182.messagelabs.com with SMTP;
	11 Feb 2013 18:44:16 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1BIiEhd008083;
	Mon, 11 Feb 2013 13:44:15 -0500
Message-ID: <51193BFE.2070808@theshore.net>
Date: Mon, 11 Feb 2013 13:44:14 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<511919AB.3070001@theshore.net>
	<1360601839.16636.40.camel@zion.uk.xensource.com>
In-Reply-To: <1360601839.16636.40.camel@zion.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/11/13 11:57 AM, Wei Liu wrote:
> Could you post your kernel config file.

Config, syms and binaries are here:

http://www.theshore.net/~caker/xen/BUGS/netback/

Thank you for looking into this.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 18:45:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 18:45: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 1U4yMV-0002Vq-UW; Mon, 11 Feb 2013 18:44:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U4yMU-0002Vl-F7
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 18:44:18 +0000
Received: from [85.158.139.83:64102] by server-1.bemta-5.messagelabs.com id
	C9/EF-29263-10C39115; Mon, 11 Feb 2013 18:44:17 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360608256!24493177!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7935 invoked from network); 11 Feb 2013 18:44:16 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-16.tower-182.messagelabs.com with SMTP;
	11 Feb 2013 18:44:16 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1BIiEhd008083;
	Mon, 11 Feb 2013 13:44:15 -0500
Message-ID: <51193BFE.2070808@theshore.net>
Date: Mon, 11 Feb 2013 13:44:14 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<511919AB.3070001@theshore.net>
	<1360601839.16636.40.camel@zion.uk.xensource.com>
In-Reply-To: <1360601839.16636.40.camel@zion.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/11/13 11:57 AM, Wei Liu wrote:
> Could you post your kernel config file.

Config, syms and binaries are here:

http://www.theshore.net/~caker/xen/BUGS/netback/

Thank you for looking into this.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 19:57:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 19:57: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 1U4zUh-0002xS-VT; Mon, 11 Feb 2013 19:56:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U4zUg-0002xN-Co
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 19:56:50 +0000
Received: from [85.158.139.211:42821] by server-11.bemta-5.messagelabs.com id
	91/45-19159-10D49115; Mon, 11 Feb 2013 19:56:49 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360612609!20991695!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19519 invoked from network); 11 Feb 2013 19:56:49 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 19:56:49 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so3740689wib.3
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 11:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Fa3RZXaa2ahkUNLEfEIEJ8+KX5r172mTl12mcUwlbPo=;
	b=lyWmakjmBThEgABPbAIjATMYgPATPmqPpzPNcSYY3pRNuuHqRAJUmgM3qy4iyAWmhc
	TrIReYIQ0XU9Xo/IXyuxmPV/XtTZMv41UqPrFkL67hvU2hGQfXfd50DU4XZgna149JLN
	ABCyZM8MJAZLct42WUG4JgQHkfwnLzbo8yWDDwbhfUDch1vVDNVyQxjMdW6BOpUFHgvK
	fr8o5pfNNr+NWcgA3yp5md90x2AtJk6kpHcggZgjNCmtCuZlNE95J+gWL5XaabO1WV1j
	Xjse0IXnnbfwsekLzXau+HNyoyGW8HNU7tnuuEsMntxogo+FSHTi2JPOazLA9QWgdzua
	VDpw==
MIME-Version: 1.0
X-Received: by 10.194.94.37 with SMTP id cz5mr26326339wjb.49.1360612608957;
	Mon, 11 Feb 2013 11:56:48 -0800 (PST)
Received: by 10.194.240.168 with HTTP; Mon, 11 Feb 2013 11:56:48 -0800 (PST)
In-Reply-To: <CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
Date: Mon, 11 Feb 2013 14:56:48 -0500
Message-ID: <CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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

>
> diff -r 6c1b12c884b4 m4/subsystem.m4
> --- a/m4/subsystem.m4
> +++ b/m4/subsystem.m4
> @@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
>  ],[
>  AX_DISABLE_SUBSYSTEM([$1])
>  ])
> +])
>  AX_SUBSYSTEM_CONFIGURE([$1])
>  AC_SUBST($1)
>  ])
> -])

BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
configure of stubdom be called?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 19:57:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 19:57: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 1U4zUh-0002xS-VT; Mon, 11 Feb 2013 19:56:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U4zUg-0002xN-Co
	for xen-devel@lists.xen.org; Mon, 11 Feb 2013 19:56:50 +0000
Received: from [85.158.139.211:42821] by server-11.bemta-5.messagelabs.com id
	91/45-19159-10D49115; Mon, 11 Feb 2013 19:56:49 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360612609!20991695!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19519 invoked from network); 11 Feb 2013 19:56:49 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 19:56:49 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so3740689wib.3
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 11:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Fa3RZXaa2ahkUNLEfEIEJ8+KX5r172mTl12mcUwlbPo=;
	b=lyWmakjmBThEgABPbAIjATMYgPATPmqPpzPNcSYY3pRNuuHqRAJUmgM3qy4iyAWmhc
	TrIReYIQ0XU9Xo/IXyuxmPV/XtTZMv41UqPrFkL67hvU2hGQfXfd50DU4XZgna149JLN
	ABCyZM8MJAZLct42WUG4JgQHkfwnLzbo8yWDDwbhfUDch1vVDNVyQxjMdW6BOpUFHgvK
	fr8o5pfNNr+NWcgA3yp5md90x2AtJk6kpHcggZgjNCmtCuZlNE95J+gWL5XaabO1WV1j
	Xjse0IXnnbfwsekLzXau+HNyoyGW8HNU7tnuuEsMntxogo+FSHTi2JPOazLA9QWgdzua
	VDpw==
MIME-Version: 1.0
X-Received: by 10.194.94.37 with SMTP id cz5mr26326339wjb.49.1360612608957;
	Mon, 11 Feb 2013 11:56:48 -0800 (PST)
Received: by 10.194.240.168 with HTTP; Mon, 11 Feb 2013 11:56:48 -0800 (PST)
In-Reply-To: <CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
Date: Mon, 11 Feb 2013 14:56:48 -0500
Message-ID: <CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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

>
> diff -r 6c1b12c884b4 m4/subsystem.m4
> --- a/m4/subsystem.m4
> +++ b/m4/subsystem.m4
> @@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
>  ],[
>  AX_DISABLE_SUBSYSTEM([$1])
>  ])
> +])
>  AX_SUBSYSTEM_CONFIGURE([$1])
>  AC_SUBST($1)
>  ])
> -])

BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
configure of stubdom be called?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 23:13:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 23:13: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 1U52Y4-0004ZL-F3; Mon, 11 Feb 2013 23:12: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 1U52Y2-0004ZG-Jv
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 23:12:30 +0000
Received: from [85.158.138.51:45483] by server-15.bemta-3.messagelabs.com id
	BC/95-25405-DDA79115; Mon, 11 Feb 2013 23:12:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360624348!21589092!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxODA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17950 invoked from network); 11 Feb 2013 23:12:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 23:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,646,1355097600"; 
   d="scan'208";a="1350448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 23:12: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.297.1; Mon, 11 Feb 2013 23:12:27 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U52Xz-00032k-Cv;
	Mon, 11 Feb 2013 23:12:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U52Xz-0008Uq-CO;
	Mon, 11 Feb 2013 23:12:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 23:12:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-multivcpu
test guest-localmigrate/x10

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad


  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.guest-localmigrate--x10.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 15817 fail [host=leaf-beetle] / 16066 ok.
Failure / basis pass flights: 15817 / 16066
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#2a1354d655d816feaad7dbdb8364f40a208439c1-2a1354d655d816feaad7dbdb8364f40a208439c1 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 http://xenbits.xen.org/hg/staging/xen-unstable.hg#ffd30e7388ad-fd997a96d448
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 114 nodes in revision graph
Searching for test results:
 15452 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15659 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15817 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16044 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16048 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16012 pass irrelevant
 16017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16053 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16020 pass irrelevant
 16069 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16022 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16025 pass irrelevant
 16032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16057 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16066 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
Searching for interesting versions
 Result found: flight 16044 (pass), for basis pass
 Result found: flight 16048 (fail), for basis failure
 Repro found: flight 16053 (pass), for basis pass
 Repro found: flight 16057 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
No revisions left to test, checking graph state.
 Result found: flight 16044 (pass), for last pass
 Result found: flight 16048 (fail), for first failure
 Repro found: flight 16053 (pass), for last pass
 Repro found: flight 16057 (fail), for first failure
 Repro found: flight 16066 (pass), for last pass
 Repro found: flight 16069 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.guest-localmigrate--x10.{dot,ps,png,html}.
----------------------------------------
16069: tolerable ALL FAIL

flight 16069 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16069/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10  fail baseline untested


jobs:
 test-amd64-i386-xl-multivcpu                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 23:13:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 23:13: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 1U52Y4-0004ZL-F3; Mon, 11 Feb 2013 23:12: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 1U52Y2-0004ZG-Jv
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 23:12:30 +0000
Received: from [85.158.138.51:45483] by server-15.bemta-3.messagelabs.com id
	BC/95-25405-DDA79115; Mon, 11 Feb 2013 23:12:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360624348!21589092!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxODA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17950 invoked from network); 11 Feb 2013 23:12:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 23:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,646,1355097600"; 
   d="scan'208";a="1350448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 23:12: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.297.1; Mon, 11 Feb 2013 23:12:27 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U52Xz-00032k-Cv;
	Mon, 11 Feb 2013 23:12:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U52Xz-0008Uq-CO;
	Mon, 11 Feb 2013 23:12:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 23:12:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-multivcpu
test guest-localmigrate/x10

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad


  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.guest-localmigrate--x10.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 15817 fail [host=leaf-beetle] / 16066 ok.
Failure / basis pass flights: 15817 / 16066
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#2a1354d655d816feaad7dbdb8364f40a208439c1-2a1354d655d816feaad7dbdb8364f40a208439c1 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 http://xenbits.xen.org/hg/staging/xen-unstable.hg#ffd30e7388ad-fd997a96d448
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 114 nodes in revision graph
Searching for test results:
 15452 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15659 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 15817 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16044 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16048 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16012 pass irrelevant
 16017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16053 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
 16020 pass irrelevant
 16069 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16022 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16025 pass irrelevant
 16032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16057 fail a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fd997a96d448
 16066 pass a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
Searching for interesting versions
 Result found: flight 16044 (pass), for basis pass
 Result found: flight 16048 (fail), for basis failure
 Repro found: flight 16053 (pass), for basis pass
 Repro found: flight 16057 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 2a1354d655d816feaad7dbdb8364f40a208439c1 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 ffd30e7388ad
No revisions left to test, checking graph state.
 Result found: flight 16044 (pass), for last pass
 Result found: flight 16048 (fail), for first failure
 Repro found: flight 16053 (pass), for last pass
 Repro found: flight 16057 (fail), for first failure
 Repro found: flight 16066 (pass), for last pass
 Repro found: flight 16069 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  fd997a96d448
  Bug not present: ffd30e7388ad

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26523:fd997a96d448
  tag:         tip
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Feb 08 11:06:04 2013 +0100
      
      x86: debugging code for testing 16Tb support on smaller memory systems
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.guest-localmigrate--x10.{dot,ps,png,html}.
----------------------------------------
16069: tolerable ALL FAIL

flight 16069 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16069/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10  fail baseline untested


jobs:
 test-amd64-i386-xl-multivcpu                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 11 23:45:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 23: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 1U533i-0004mN-8w; Mon, 11 Feb 2013 23:45: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 1U533g-0004mI-KT
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 23:45:13 +0000
Received: from [85.158.139.83:17550] by server-15.bemta-5.messagelabs.com id
	DE/34-18914-78289115; Mon, 11 Feb 2013 23:45:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360626310!20931677!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27956 invoked from network); 11 Feb 2013 23:45:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 23:45:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,646,1355097600"; 
   d="scan'208";a="1350863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 23:45: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.297.1; Mon, 11 Feb 2013 23:45:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U533d-0003D0-CT;
	Mon, 11 Feb 2013 23:45:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U533d-0004sv-3O;
	Mon, 11 Feb 2013 23:45:09 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16014-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 23:45:09 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16014: 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 16014 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16014/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16014
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 16014
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 16014
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16014
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16014
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16014
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16014

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 11 23:45:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 11 Feb 2013 23: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 1U533i-0004mN-8w; Mon, 11 Feb 2013 23:45: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 1U533g-0004mI-KT
	for xen-devel@lists.xensource.com; Mon, 11 Feb 2013 23:45:13 +0000
Received: from [85.158.139.83:17550] by server-15.bemta-5.messagelabs.com id
	DE/34-18914-78289115; Mon, 11 Feb 2013 23:45:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360626310!20931677!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxNzE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27956 invoked from network); 11 Feb 2013 23:45:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Feb 2013 23:45:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,646,1355097600"; 
   d="scan'208";a="1350863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Feb 2013 23:45: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.297.1; Mon, 11 Feb 2013 23:45:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U533d-0003D0-CT;
	Mon, 11 Feb 2013 23:45:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U533d-0004sv-3O;
	Mon, 11 Feb 2013 23:45:09 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16014-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 11 Feb 2013 23:45:09 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16014: 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 16014 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16014/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16014
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 16014
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 16014
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16014
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16014
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16014
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16014

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 12 02:19:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 02: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 1U55S6-0001pD-Sn; Tue, 12 Feb 2013 02:18:34 +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 1U55S4-0001p8-Mz
	for Xen-devel@lists.xensource.com; Tue, 12 Feb 2013 02:18:32 +0000
Received: from [193.109.254.147:17901] by server-6.bemta-14.messagelabs.com id
	36/B0-12010-776A9115; Tue, 12 Feb 2013 02:18:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360635508!3246479!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE0ODEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19778 invoked from network); 12 Feb 2013 02:18:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 02:18:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1C2IR2t019809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 02:18:28 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
	r1C2IQ82021250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 02:18:26 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
	r1C2IQUW017500; Mon, 11 Feb 2013 20:18:26 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Feb 2013 18:18:25 -0800
Date: Mon, 11 Feb 2013 18:18:24 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130211181824.169b9d05@mantra.us.oracle.com>
In-Reply-To: <20130124173118.GN20551@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 14/16]: PVH xen: add
 xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013 17:31:18 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:11 -0800 on 11 Jan (1357927863), Mukesh Rathor wrote:
> 
> > +    /* qemu, running on PVH dom0, mapping hvm domain's io pages
> > during domain 
> > +     * creation, doesn't have mfns in the HAP table */
> > +    if ( !mfn_valid(mfn) && p2m_is_mmio(p2mt) ) {
> 
> This test should be for == p2m_mmio_direct; we don't want to try
> mapping p2m_mmio_dm areas.

Yup. Done.

> > +        if (!is_hvm_domain(fdom)) {
> > +            printk("mmio type for non-hvm domain. fd:%d fgmfn:%lx
> > gpfn:%lx\n",
> > +                   foreign_domid, fgmfn, gpfn);
> > +            return -EINVAL;
> > +        }
> > +        mfn = fgmfn;     /* map 1 to 1 */
> 
> Surely not -- you want to map the _actual_ MMIO range, right, not just
> whatever GFN-address the foreigh domain mapped it at?

Actually, fgmfn here is the machine address of the mmio page. 
Removed the "map 1 to 1" comment.

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 Feb 12 02:19:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 02: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 1U55S6-0001pD-Sn; Tue, 12 Feb 2013 02:18:34 +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 1U55S4-0001p8-Mz
	for Xen-devel@lists.xensource.com; Tue, 12 Feb 2013 02:18:32 +0000
Received: from [193.109.254.147:17901] by server-6.bemta-14.messagelabs.com id
	36/B0-12010-776A9115; Tue, 12 Feb 2013 02:18:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360635508!3246479!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE0ODEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19778 invoked from network); 12 Feb 2013 02:18:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 02:18:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1C2IR2t019809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 02:18:28 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
	r1C2IQ82021250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 02:18:26 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
	r1C2IQUW017500; Mon, 11 Feb 2013 20:18:26 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 11 Feb 2013 18:18:25 -0800
Date: Mon, 11 Feb 2013 18:18:24 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130211181824.169b9d05@mantra.us.oracle.com>
In-Reply-To: <20130124173118.GN20551@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 14/16]: PVH xen: add
 xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013 17:31:18 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:11 -0800 on 11 Jan (1357927863), Mukesh Rathor wrote:
> 
> > +    /* qemu, running on PVH dom0, mapping hvm domain's io pages
> > during domain 
> > +     * creation, doesn't have mfns in the HAP table */
> > +    if ( !mfn_valid(mfn) && p2m_is_mmio(p2mt) ) {
> 
> This test should be for == p2m_mmio_direct; we don't want to try
> mapping p2m_mmio_dm areas.

Yup. Done.

> > +        if (!is_hvm_domain(fdom)) {
> > +            printk("mmio type for non-hvm domain. fd:%d fgmfn:%lx
> > gpfn:%lx\n",
> > +                   foreign_domid, fgmfn, gpfn);
> > +            return -EINVAL;
> > +        }
> > +        mfn = fgmfn;     /* map 1 to 1 */
> 
> Surely not -- you want to map the _actual_ MMIO range, right, not just
> whatever GFN-address the foreigh domain mapped it at?

Actually, fgmfn here is the machine address of the mmio page. 
Removed the "map 1 to 1" comment.

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 Feb 12 03:21:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 03:21: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 1U56QX-0002Bn-Ee; Tue, 12 Feb 2013 03:21:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U56QW-0002Bi-7b
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 03:21:00 +0000
Received: from [85.158.143.35:28507] by server-2.bemta-4.messagelabs.com id
	75/1D-01597-B15B9115; Tue, 12 Feb 2013 03:20:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360639256!11643137!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjU1MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3786 invoked from network); 12 Feb 2013 03:20:57 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 03:20:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1C3KraH021783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 03:20:53 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
	r1C3KqrP019303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 03:20:52 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
	r1C3Kpr8016900; Mon, 11 Feb 2013 21:20:51 -0600
MIME-Version: 1.0
Message-ID: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
Date: Mon, 11 Feb 2013 19:20:51 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <povder@gmail.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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


----- povder@gmail.com wrote:

> 
> GRUB entry:
>  title CentOS Xen kernel IOMMU serial console (3.7.1-3.el6xen.x86_64)
>         root (hd0,0)
>         kernel /xen.gz dom0_mem=1G,max:1G dom0_max_vcpus=1
> dom0_vcpus_pin iommu=verbose loglvl=all guest_loglvl=all iommu=1
> com1=38400,8n1 console=com1

Try adding "iommu=debug" option --- it will print more information including 
dump of the ACPI table that describes IOMMU.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 03:21:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 03:21: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 1U56QX-0002Bn-Ee; Tue, 12 Feb 2013 03:21:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U56QW-0002Bi-7b
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 03:21:00 +0000
Received: from [85.158.143.35:28507] by server-2.bemta-4.messagelabs.com id
	75/1D-01597-B15B9115; Tue, 12 Feb 2013 03:20:59 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360639256!11643137!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjU1MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3786 invoked from network); 12 Feb 2013 03:20:57 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 03:20:57 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1C3KraH021783
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 03:20:53 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
	r1C3KqrP019303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 03:20:52 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
	r1C3Kpr8016900; Mon, 11 Feb 2013 21:20:51 -0600
MIME-Version: 1.0
Message-ID: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
Date: Mon, 11 Feb 2013 19:20:51 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <povder@gmail.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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


----- povder@gmail.com wrote:

> 
> GRUB entry:
>  title CentOS Xen kernel IOMMU serial console (3.7.1-3.el6xen.x86_64)
>         root (hd0,0)
>         kernel /xen.gz dom0_mem=1G,max:1G dom0_max_vcpus=1
> dom0_vcpus_pin iommu=verbose loglvl=all guest_loglvl=all iommu=1
> com1=38400,8n1 console=com1

Try adding "iommu=debug" option --- it will print more information including 
dump of the ACPI table that describes IOMMU.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 06:27:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 06:27: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 1U59KW-0003Na-Jo; Tue, 12 Feb 2013 06:27:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U59KW-0003NV-2g
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 06:27:00 +0000
Received: from [85.158.139.83:32437] by server-9.bemta-5.messagelabs.com id
	05/FD-24440-3B0E9115; Tue, 12 Feb 2013 06:26:59 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360650417!23861737!1
X-Originating-IP: [209.85.128.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17117 invoked from network); 12 Feb 2013 06:26:58 -0000
Received: from mail-ve0-f182.google.com (HELO mail-ve0-f182.google.com)
	(209.85.128.182)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 06:26:58 -0000
Received: by mail-ve0-f182.google.com with SMTP id ox1so5955000veb.13
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 22:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=7+OR08nyNmuTxW8eKOaA7hUhB5injeeKYGro15Eg4SU=;
	b=bVrEjCHwDk39F129qehg/bwEgHUc7gSBJYx6nZOEtWAwJUobCKXZ5Ccl4vuSEN6NYR
	2YZjpHVaGcgngTHPz2kwzUVopUqbCCzvYirE+iHrawQTRlovGlGhgCGD5G6eJ8v99PRH
	NkFmlyUW3J611p9xEqT3asAaOx66w65M8umUqvR6Mfpcxy1fda4QNZia51NsiazbRyjb
	KVdZmbeKsWbIWjETLOYaYsX+PweOlafYG8FprCL71Uf80vWvm3X51THJ2CST5lKw9Nbo
	QBeQGEME+YdDf3aN/U7dl+2/1Pcu9VtH/STyvhJM1nb6QrFJlTN22/5PhD7pER/MVeK0
	hdxw==
X-Received: by 10.58.50.7 with SMTP id y7mr22438229ven.24.1360650416887; Mon,
	11 Feb 2013 22:26:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Mon, 11 Feb 2013 22:26:36 -0800 (PST)
In-Reply-To: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 07:26:36 +0100
Message-ID: <CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>
> Try adding "iommu=debug" option --- it will print more information including
> dump of the ACPI table that describes IOMMU.
>

Thanks for a quick reply.
Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 06:27:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 06:27: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 1U59KW-0003Na-Jo; Tue, 12 Feb 2013 06:27:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U59KW-0003NV-2g
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 06:27:00 +0000
Received: from [85.158.139.83:32437] by server-9.bemta-5.messagelabs.com id
	05/FD-24440-3B0E9115; Tue, 12 Feb 2013 06:26:59 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360650417!23861737!1
X-Originating-IP: [209.85.128.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17117 invoked from network); 12 Feb 2013 06:26:58 -0000
Received: from mail-ve0-f182.google.com (HELO mail-ve0-f182.google.com)
	(209.85.128.182)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 06:26:58 -0000
Received: by mail-ve0-f182.google.com with SMTP id ox1so5955000veb.13
	for <xen-devel@lists.xen.org>; Mon, 11 Feb 2013 22:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=7+OR08nyNmuTxW8eKOaA7hUhB5injeeKYGro15Eg4SU=;
	b=bVrEjCHwDk39F129qehg/bwEgHUc7gSBJYx6nZOEtWAwJUobCKXZ5Ccl4vuSEN6NYR
	2YZjpHVaGcgngTHPz2kwzUVopUqbCCzvYirE+iHrawQTRlovGlGhgCGD5G6eJ8v99PRH
	NkFmlyUW3J611p9xEqT3asAaOx66w65M8umUqvR6Mfpcxy1fda4QNZia51NsiazbRyjb
	KVdZmbeKsWbIWjETLOYaYsX+PweOlafYG8FprCL71Uf80vWvm3X51THJ2CST5lKw9Nbo
	QBeQGEME+YdDf3aN/U7dl+2/1Pcu9VtH/STyvhJM1nb6QrFJlTN22/5PhD7pER/MVeK0
	hdxw==
X-Received: by 10.58.50.7 with SMTP id y7mr22438229ven.24.1360650416887; Mon,
	11 Feb 2013 22:26:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Mon, 11 Feb 2013 22:26:36 -0800 (PST)
In-Reply-To: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 07:26:36 +0100
Message-ID: <CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>
> Try adding "iommu=debug" option --- it will print more information including
> dump of the ACPI table that describes IOMMU.
>

Thanks for a quick reply.
Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 06:27:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 06: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 1U59Kb-0003Nm-3E; Tue, 12 Feb 2013 06:27: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 1U59KZ-0003Nh-FC
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 06:27:03 +0000
Received: from [85.158.139.83:25285] by server-10.bemta-5.messagelabs.com id
	16/01-04697-6B0E9115; Tue, 12 Feb 2013 06:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360650421!31434394!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxODA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32187 invoked from network); 12 Feb 2013 06:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 06:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,647,1355097600"; 
   d="scan'208";a="1357286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 06: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.297.1; Tue, 12 Feb 2013 06:27:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U59KW-0005HJ-Nr;
	Tue, 12 Feb 2013 06:27:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U59KW-0006Gx-NA;
	Tue, 12 Feb 2013 06:27:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16074-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 06:27:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16074: 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 16074 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16074/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16074
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 16074
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 16074
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16074
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16074
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16074
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16074

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 12 06:27:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 06: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 1U59Kb-0003Nm-3E; Tue, 12 Feb 2013 06:27: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 1U59KZ-0003Nh-FC
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 06:27:03 +0000
Received: from [85.158.139.83:25285] by server-10.bemta-5.messagelabs.com id
	16/01-04697-6B0E9115; Tue, 12 Feb 2013 06:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360650421!31434394!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxODA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32187 invoked from network); 12 Feb 2013 06:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 06:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,647,1355097600"; 
   d="scan'208";a="1357286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 06: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.297.1; Tue, 12 Feb 2013 06:27:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U59KW-0005HJ-Nr;
	Tue, 12 Feb 2013 06:27:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U59KW-0006Gx-NA;
	Tue, 12 Feb 2013 06:27:00 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16074-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 06:27:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16074: 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 16074 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16074/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16074
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 16074
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 16074
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16074
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16074
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16074
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16074

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 12 08:08:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5AuZ-0004g2-MJ; Tue, 12 Feb 2013 08:08:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U5AuX-0004fx-QZ
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:08:18 +0000
Received: from [85.158.143.35:57173] by server-1.bemta-4.messagelabs.com id
	C2/61-08839-178F9115; Tue, 12 Feb 2013 08:08:17 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360656385!16010433!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15207 invoked from network); 12 Feb 2013 08:06:26 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 08:06:26 -0000
Received: by mail-wi0-f181.google.com with SMTP id hm6so4035034wib.2
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 00:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=n98d1KOe8w4UQDrTDP8VyxNyvV4MZMhSudN7kLLSe7w=;
	b=q68p0jGh99TzqgGVGU3VcfYT+0DYDrUlxMerhiYdABIc6vq2NUJvmsZDmve/+6U6O9
	sOis+J0gz3Y1BfriQSK9gUvJ7uWwhXfCWi29S78Bzwc0vOnoALCCUK27Zl5kWhgJBDwn
	VamLzHl4MWNEQlzOckwD4gSMKh6BmvEAGaYTkDM2wyKDkW54QaC7QZ7n4AhQJ0fysJcV
	RkMy1hV/tMa1DHRxHyFq4m527sotoOr0mPDsV4wehzZNkMQjRaD8DPUTjLnm5CFAjiCt
	XQ341zUMwtSIipanCSuyaRI7x/JvAdkbXvwckTIr5jz1yBq/AHja5XjjyLeQxZmYF6l4
	ve4w==
MIME-Version: 1.0
X-Received: by 10.194.108.229 with SMTP id hn5mr29090240wjb.8.1360656385072;
	Tue, 12 Feb 2013 00:06:25 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Tue, 12 Feb 2013 00:06:24 -0800 (PST)
Date: Tue, 12 Feb 2013 09:06:24 +0100
Message-ID: <CAN-nQwin8zEofxb0j09fb93uxsurOHvBpDNaC=QCpoehVwzcEQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Remus on Ubuntu 12.04 with XEN 4.1 AMD 64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2192269135253824332=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2192269135253824332==
Content-Type: multipart/alternative; boundary=047d7bf198907e5fe604d582801b

--047d7bf198907e5fe604d582801b
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I am new in XEN and quite confusing with this remus installation. Could
anyone point me out how to do it.
I have Ubuntu 12.04 with kernel 3.2.0-29-generic 64 bit bot for Dom0 dan
DomU with Para Virtualization. I have installed Xen4.1 AMD 64 bit by
following this https://help.ubuntu.com/community/XenProposed. I have
succesfully done the migration from one machine into another. How ever I
want to run this remus to support my server. I have read
http://remusha.wikidot.com/ to configuring and install remus.

Could any body point me out what I should do? am I have to re-installed my
machine with supported kernel firstly (kernel 2.6.x) or something.

Thank you very much.

Regards,

Agya

--047d7bf198907e5fe604d582801b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p style=3D"font-family:verdana,arial,helvetica,sans-serif;font-size:13px">=
Dear all,</p><p style=3D"font-family:verdana,arial,helvetica,sans-serif;fon=
t-size:13px">I am new in XEN and quite confusing with this remus installati=
on. Could anyone point me out how to do it.<br>
I have Ubuntu 12.04 with kernel 3.2.0-29-generic 64 bit bot for Dom0 dan Do=
mU with Para Virtualization. I have installed Xen4.1 AMD 64 bit by followin=
g this=A0<a href=3D"https://help.ubuntu.com/community/XenProposed" style=3D=
"color:rgb(0,0,170)">https://help.ubuntu.com/community/XenProposed</a>. I h=
ave succesfully done the migration from one machine into another. How ever =
I want to run this remus to support my server. I have read=A0<a href=3D"htt=
p://remusha.wikidot.com/" style=3D"color:rgb(0,0,170)">http://remusha.wikid=
ot.com/</a>=A0to configuring and install remus.</p>
<p style=3D"font-family:verdana,arial,helvetica,sans-serif;font-size:13px">=
Could any body point me out what I should do? am I have to re-installed my =
machine with supported kernel firstly (kernel 2.6.x) or something.</p><p st=
yle=3D"font-family:verdana,arial,helvetica,sans-serif;font-size:13px">
Thank you very much.</p><p style=3D"font-family:verdana,arial,helvetica,san=
s-serif;font-size:13px">Regards,</p><p style=3D"font-family:verdana,arial,h=
elvetica,sans-serif;font-size:13px">Agya</p>

--047d7bf198907e5fe604d582801b--


--===============2192269135253824332==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2192269135253824332==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 08:08:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5AuZ-0004g2-MJ; Tue, 12 Feb 2013 08:08:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>) id 1U5AuX-0004fx-QZ
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:08:18 +0000
Received: from [85.158.143.35:57173] by server-1.bemta-4.messagelabs.com id
	C2/61-08839-178F9115; Tue, 12 Feb 2013 08:08:17 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360656385!16010433!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15207 invoked from network); 12 Feb 2013 08:06:26 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 08:06:26 -0000
Received: by mail-wi0-f181.google.com with SMTP id hm6so4035034wib.2
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 00:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=n98d1KOe8w4UQDrTDP8VyxNyvV4MZMhSudN7kLLSe7w=;
	b=q68p0jGh99TzqgGVGU3VcfYT+0DYDrUlxMerhiYdABIc6vq2NUJvmsZDmve/+6U6O9
	sOis+J0gz3Y1BfriQSK9gUvJ7uWwhXfCWi29S78Bzwc0vOnoALCCUK27Zl5kWhgJBDwn
	VamLzHl4MWNEQlzOckwD4gSMKh6BmvEAGaYTkDM2wyKDkW54QaC7QZ7n4AhQJ0fysJcV
	RkMy1hV/tMa1DHRxHyFq4m527sotoOr0mPDsV4wehzZNkMQjRaD8DPUTjLnm5CFAjiCt
	XQ341zUMwtSIipanCSuyaRI7x/JvAdkbXvwckTIr5jz1yBq/AHja5XjjyLeQxZmYF6l4
	ve4w==
MIME-Version: 1.0
X-Received: by 10.194.108.229 with SMTP id hn5mr29090240wjb.8.1360656385072;
	Tue, 12 Feb 2013 00:06:25 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Tue, 12 Feb 2013 00:06:24 -0800 (PST)
Date: Tue, 12 Feb 2013 09:06:24 +0100
Message-ID: <CAN-nQwin8zEofxb0j09fb93uxsurOHvBpDNaC=QCpoehVwzcEQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Remus on Ubuntu 12.04 with XEN 4.1 AMD 64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2192269135253824332=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2192269135253824332==
Content-Type: multipart/alternative; boundary=047d7bf198907e5fe604d582801b

--047d7bf198907e5fe604d582801b
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I am new in XEN and quite confusing with this remus installation. Could
anyone point me out how to do it.
I have Ubuntu 12.04 with kernel 3.2.0-29-generic 64 bit bot for Dom0 dan
DomU with Para Virtualization. I have installed Xen4.1 AMD 64 bit by
following this https://help.ubuntu.com/community/XenProposed. I have
succesfully done the migration from one machine into another. How ever I
want to run this remus to support my server. I have read
http://remusha.wikidot.com/ to configuring and install remus.

Could any body point me out what I should do? am I have to re-installed my
machine with supported kernel firstly (kernel 2.6.x) or something.

Thank you very much.

Regards,

Agya

--047d7bf198907e5fe604d582801b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p style=3D"font-family:verdana,arial,helvetica,sans-serif;font-size:13px">=
Dear all,</p><p style=3D"font-family:verdana,arial,helvetica,sans-serif;fon=
t-size:13px">I am new in XEN and quite confusing with this remus installati=
on. Could anyone point me out how to do it.<br>
I have Ubuntu 12.04 with kernel 3.2.0-29-generic 64 bit bot for Dom0 dan Do=
mU with Para Virtualization. I have installed Xen4.1 AMD 64 bit by followin=
g this=A0<a href=3D"https://help.ubuntu.com/community/XenProposed" style=3D=
"color:rgb(0,0,170)">https://help.ubuntu.com/community/XenProposed</a>. I h=
ave succesfully done the migration from one machine into another. How ever =
I want to run this remus to support my server. I have read=A0<a href=3D"htt=
p://remusha.wikidot.com/" style=3D"color:rgb(0,0,170)">http://remusha.wikid=
ot.com/</a>=A0to configuring and install remus.</p>
<p style=3D"font-family:verdana,arial,helvetica,sans-serif;font-size:13px">=
Could any body point me out what I should do? am I have to re-installed my =
machine with supported kernel firstly (kernel 2.6.x) or something.</p><p st=
yle=3D"font-family:verdana,arial,helvetica,sans-serif;font-size:13px">
Thank you very much.</p><p style=3D"font-family:verdana,arial,helvetica,san=
s-serif;font-size:13px">Regards,</p><p style=3D"font-family:verdana,arial,h=
elvetica,sans-serif;font-size:13px">Agya</p>

--047d7bf198907e5fe604d582801b--


--===============2192269135253824332==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2192269135253824332==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 08:29:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5BEX-0004tu-9y; Tue, 12 Feb 2013 08:28: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 1U5BEV-0004tp-Nk
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:28:55 +0000
Received: from [85.158.143.99:60585] by server-2.bemta-4.messagelabs.com id
	CB/4D-01597-74DF9115; Tue, 12 Feb 2013 08:28:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360657734!30882006!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxODA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4221 invoked from network); 12 Feb 2013 08:28:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 08:28:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,647,1355097600"; 
   d="scan'208";a="1360493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 08:28:55 +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.297.1;
	Tue, 12 Feb 2013 08:28:54 +0000
Message-ID: <1360657733.18663.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Tue, 12 Feb 2013 08:28:53 +0000
In-Reply-To: <CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
	<CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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 Mon, 2013-02-11 at 19:56 +0000, Shakeel Butt wrote:
> >
> > diff -r 6c1b12c884b4 m4/subsystem.m4
> > --- a/m4/subsystem.m4
> > +++ b/m4/subsystem.m4
> > @@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
> >  ],[
> >  AX_DISABLE_SUBSYSTEM([$1])
> >  ])
> > +])
> >  AX_SUBSYSTEM_CONFIGURE([$1])
> >  AC_SUBST($1)
> >  ])
> > -])
> 
> BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
> configure of stubdom be called?

My intention was that --(enable|disable)-stubdom would always override
arch_enable_stubdom, so yes it should be called.

About the only person this would matter to is the person doing the port
of mini-os to ARM...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 08:29:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5BEX-0004tu-9y; Tue, 12 Feb 2013 08:28: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 1U5BEV-0004tp-Nk
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:28:55 +0000
Received: from [85.158.143.99:60585] by server-2.bemta-4.messagelabs.com id
	CB/4D-01597-74DF9115; Tue, 12 Feb 2013 08:28:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360657734!30882006!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxODA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4221 invoked from network); 12 Feb 2013 08:28:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 08:28:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,647,1355097600"; 
   d="scan'208";a="1360493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 08:28:55 +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.297.1;
	Tue, 12 Feb 2013 08:28:54 +0000
Message-ID: <1360657733.18663.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Tue, 12 Feb 2013 08:28:53 +0000
In-Reply-To: <CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
	<CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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 Mon, 2013-02-11 at 19:56 +0000, Shakeel Butt wrote:
> >
> > diff -r 6c1b12c884b4 m4/subsystem.m4
> > --- a/m4/subsystem.m4
> > +++ b/m4/subsystem.m4
> > @@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
> >  ],[
> >  AX_DISABLE_SUBSYSTEM([$1])
> >  ])
> > +])
> >  AX_SUBSYSTEM_CONFIGURE([$1])
> >  AC_SUBST($1)
> >  ])
> > -])
> 
> BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
> configure of stubdom be called?

My intention was that --(enable|disable)-stubdom would always override
arch_enable_stubdom, so yes it should be called.

About the only person this would matter to is the person doing the port
of mini-os to ARM...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 08:52:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5BaI-0005Jl-7L; Tue, 12 Feb 2013 08:51: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 1U5BaG-0005Jb-OD
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:51:24 +0000
Received: from [85.158.143.99:59100] by server-3.bemta-4.messagelabs.com id
	8C/F3-08920-C820A115; Tue, 12 Feb 2013 08:51:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360659083!18936326!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25059 invoked from network); 12 Feb 2013 08:51:23 -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 Feb 2013 08:51:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 08:51:24 +0000
Message-Id: <511A105E02000078000BD9FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 08:50:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Suravee Suthikulanit" <suravee.suthikulpanit@amd.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
	<51155CAB.7010600@amd.com>
In-Reply-To: <51155CAB.7010600@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux@eikelenboom.it, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 21:14, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote:
> CASE1: BIOS disable the IOAPIC in the southbridge (SB8X0 chipset)
> This is the case we are seeing here with the AMD 890-FX motherboard.
> Here, the MADT is reporting 2 IOAPICs as shown by the message:
> 
> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
> 
> However, when Xen tries to setup the IOMMU interrupt remapping table using 
> IVHD
> entries, there is only one IOAPIC (IOAPIC 1 with apic_id 7).
> 
> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
> (XEN) IVHD Error: no information for IO-APIC 0x6
> (XEN) AMD-Vi: Error initialization

But you realize that it's the _first_ IO-APIC that has no
representation in IVRS? And it can only reasonably be the 2nd
that the BIOS might choose to disable (or else legacy interrupts,
including the timer, wouldn't work).

> In this case, if we should be able to look at the IVHD to correlate IOAPIC 
> ID (0 or 1)
> from the "handle" field and map it back to the BDF to setup the remapping 
> table.

I don't currently see how you would figure out the BDF for the
IO-APIC. Care to explain?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 08:52:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5BaI-0005Jl-7L; Tue, 12 Feb 2013 08:51: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 1U5BaG-0005Jb-OD
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:51:24 +0000
Received: from [85.158.143.99:59100] by server-3.bemta-4.messagelabs.com id
	8C/F3-08920-C820A115; Tue, 12 Feb 2013 08:51:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360659083!18936326!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25059 invoked from network); 12 Feb 2013 08:51:23 -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 Feb 2013 08:51:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 08:51:24 +0000
Message-Id: <511A105E02000078000BD9FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 08:50:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Suravee Suthikulanit" <suravee.suthikulpanit@amd.com>
References: <165496354.20130205221901@eikelenboom.it>
	<51123D3102000078000BC61B@nat28.tlf.novell.com>
	<364251457.20130206122422@eikelenboom.it>
	<5112602602000078000BC725@nat28.tlf.novell.com>
	<51155CAB.7010600@amd.com>
In-Reply-To: <51155CAB.7010600@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux@eikelenboom.it, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD,
 IOMMU: Clean up old entries in remapping tables when creating new
 one
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.02.13 at 21:14, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote:
> CASE1: BIOS disable the IOAPIC in the southbridge (SB8X0 chipset)
> This is the case we are seeing here with the AMD 890-FX motherboard.
> Here, the MADT is reporting 2 IOAPICs as shown by the message:
> 
> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
> 
> However, when Xen tries to setup the IOMMU interrupt remapping table using 
> IVHD
> entries, there is only one IOAPIC (IOAPIC 1 with apic_id 7).
> 
> (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
> (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7
> (XEN) IVHD Error: no information for IO-APIC 0x6
> (XEN) AMD-Vi: Error initialization

But you realize that it's the _first_ IO-APIC that has no
representation in IVRS? And it can only reasonably be the 2nd
that the BIOS might choose to disable (or else legacy interrupts,
including the timer, wouldn't work).

> In this case, if we should be able to look at the IVHD to correlate IOAPIC 
> ID (0 or 1)
> from the "handle" field and map it back to the BDF to setup the remapping 
> table.

I don't currently see how you would figure out the BDF for the
IO-APIC. Care to explain?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 08:55:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5Be4-0005Sw-TT; Tue, 12 Feb 2013 08:55: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 1U5Be2-0005Sr-SH
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:55:19 +0000
Received: from [85.158.143.99:3276] by server-2.bemta-4.messagelabs.com id
	ED/1D-01597-5730A115; Tue, 12 Feb 2013 08:55:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360658873!24896278!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14257 invoked from network); 12 Feb 2013 08:47:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 08:47:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 08:47:54 +0000
Message-Id: <511A0F4C02000078000BD9ED@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 08:45:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<1360588326.20449.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360588326.20449.33.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-06 at 13:04 +0000, Jan Beulich wrote:
>> A regression was reported on a class of broken firmware that c/s
>> 26517:601139e2b0db didn't consider, leading to a boot time crash.
> 
> Should we release an update to XSA-36 when these have gone in?

I think so, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 08:55:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 08: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 1U5Be4-0005Sw-TT; Tue, 12 Feb 2013 08:55: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 1U5Be2-0005Sr-SH
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 08:55:19 +0000
Received: from [85.158.143.99:3276] by server-2.bemta-4.messagelabs.com id
	ED/1D-01597-5730A115; Tue, 12 Feb 2013 08:55:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360658873!24896278!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14257 invoked from network); 12 Feb 2013 08:47:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 08:47:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 08:47:54 +0000
Message-Id: <511A0F4C02000078000BD9ED@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 08:45:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<1360588326.20449.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360588326.20449.33.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-06 at 13:04 +0000, Jan Beulich wrote:
>> A regression was reported on a class of broken firmware that c/s
>> 26517:601139e2b0db didn't consider, leading to a boot time crash.
> 
> Should we release an update to XSA-36 when these have gone in?

I think so, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:08:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:08: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 1U5BqN-0005mU-CQ; Tue, 12 Feb 2013 09:08:03 +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 1U5BqL-0005mP-V7
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:08:02 +0000
Received: from [85.158.139.211:37966] by server-2.bemta-5.messagelabs.com id
	C4/CE-16911-0760A115; Tue, 12 Feb 2013 09:08:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360660076!18152577!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15499 invoked from network); 12 Feb 2013 09:07:56 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 09:07:56 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:07:55 +0100
Message-Id: <511A147802000078000BDA2B@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:07:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?R8OhYm9yIFDDiUs=?=" <pek@crysys.hu>
References: <511510FA.8010109@crysys.hu>
	<51153C2902000078000BD4A6@nat28.tlf.novell.com>
	<5118CA6C.8060809@crysys.hu>
In-Reply-To: <5118CA6C.8060809@crysys.hu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] NMI SERR interrupts in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDExLjAyLjEzIGF0IDExOjM5LCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90
ZToKPiBPbiAyMDEzLjAyLjA4LiAxNzo1NSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+IE9uIDA4
LjAyLjEzIGF0IDE1OjUxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90ZToKPj4+IFsr
XSBBdCB0aGUgc2FtZSB0aW1lLCBQQ0kgU0VSUiBpbnRlcnJ1cHRzIHJlZmVyIHRvIGhhcmR3YXJl
IGVycm9ycyB0aGF0Cj4+PiBpcyBnZW5lcmF0ZWQgYnkgbXkgcGFzc3Rocm91Z2ggTklDIGRpcmVj
dGx5LCBzbyBJIGV4cGVjdCB0aGF0IHRoZXNlCj4+PiBpbnRlcnJ1cHRzIGFyZSBwaHlzaWNhbCAo
ZS5nLiwgTVNJcykgc28gdGhleSBzaG91bGQgZ28gZGlyZWN0bHkgZWl0aGVyCj4+PiB0byB0aGUg
QlNQIG9yIG9uZSBvZiB0aGUgQVBzLiBIb3dldmVyLCBJbnRlcnJ1cHQgcmVtYXBwaW5nIGlzIGlu
IHBsYWNlCj4+PiB3aGljaCBzaG91bGQgY2hlY2sgdGhlIG9yaWdpbiBvZiBzdWNoIGludGVycnVw
dHMgYW5kIHNob3VsZCByZW1hcCB0aGUKPj4+IGludGVycnVwdHMgYnkgdXNpbmcgdGhlIEJERiBp
ZCBvZiB0aGUgZGV2aWNlLiBUaHVzLCB0aGUgcmVhbCBpbnRlcnJ1cHQKPj4+IGlzIGdlbmVyYXRl
ZCBieSB0aGUgSW50ZXJydXB0IFJlbWFwcGluZyBoYXJkd2FyZSB1bml0IHdoaWNoIGlzIHN0aWxs
IGEKPj4+IHBoeXNpY2FsIG9uZS4gQW0gSSByaWdodD8KPj4gCj4+IE5vLCBOTUlzIGRvbid0IGdv
IHRocm91Z2ggdGhlIHJlbWFwcGluZyBoYXJkd2FyZSwgdGhleSBnZXQKPj4gZGVsaXZlcmVkIGRp
cmVjdGx5IHRvIHRoZSBDUFUuIFdoaWNoIG1ha2VzIHNlbnNlLCBiZWNhdXNlIHRoZXkKPj4gcG9p
bnQgb3V0IGEgcHJvYmxlbSBpbiB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIHJlZ2FyZGxlc3Mgb2YK
Pj4gd2hldGhlciBhIGRldmljZSBoYXZpbmcgY2F1c2VkIHRoZW0gaXMgYXNzaWduZWQgdG8gYSBn
dWVzdAo+IAo+IEkgZmFjZWQgdGhpcyBOTUkgaXNzdWUgd2hpbGUgbG9va2luZyBhdCB0aGUgc2Vj
dXJpdHkgb2YgWGVuLCBob3dldmVyLCBpdAo+IHJhaXNlcyBzZWN1cml0eSBjb25jZXJucyBpbiBt
eSBtaW5kLiBJZiBhbiBOTUkgZG9lcyBub3QgZ28gdGhyb3VnaCB0aGUKPiBJbnRlcnJ1cHQgUmVt
YXBwaW5nIGVuZ2luZSAod2hpY2ggbWFrZXMgc2Vuc2UgZHVlIHRvIGl0cyBub24tbWFza2FibGUK
PiBuYXR1cmUpLCB0aGVuIGEgIm1hbGljaW91cyIgTk1JIGNvdWxkIGdpdmUgcmlzZSB0byBlaXRo
ZXIgYSBEb1MgYXR0YWNrCj4gb3IgY29kZSBleGVjdXRpb24gcHJvYmxlbXMgd2l0aCByaW5nMSBw
cml2aWxlZ2VzLiBJbiB0aGUgZm9ybWVyIGNhc2UgdGhlCj4gcmVhc29uIGNvdWxkIGJlIHRoZSB1
bmNsZWFyZWQgRU9JIHJlZ2lzdGVyIGZvciB0aGUgc3BlY2lmaWMgQ1BVIGFmdGVyCj4gTk1JIGdl
bmVyYXRpb24sIHdoaWxlIGluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgY29kZSBpbmplY3Rpb24gbWln
aHQgYmUKPiBkaWZmaWN1bHQsIGJ1dCB0aGUgY29uY2VybiBpcyBzdGlsbCB2YWxpZCBJIHRoaW5r
LgoKSSdtIGFmcmFpZCB5b3UncmUgbWl4aW5nIHVwIHRoaW5ncyBoZXJlLiBBbiBOTUkgZG9lc24n
dCByZXF1aXJlIGFuCkVPSSAoYXMgaXQncyBub3QgYSB2ZWN0b3JlZCBpbnRlcnJ1cHQsIGFuZCBh
cyBzdWNoIGRvZXNuJ3QgZ28KdGhyb3VnaCB0aGUgbm9ybWFsIExBUElDIHByb2Nlc3NpbmcgYXQg
YWxsOyBDUFVzIGhhdmUgYSBkZWRpY2F0ZWQKW3ZpcnR1YWxdIGlucHV0IGZvciB0aGlzKS4KCj4g
RnVydGhlcm1vcmUsIGFuIGF0dGFja2VyIGNhbiBnZW5lcmF0ZSBzdWNoIE5NSXMgdmlhIE1TSXMg
ZnJvbSB1bnRydXN0ZWQKPiBIVk0gZG9tYWlucyBieSBtZWFucyBvZiBhIFBUIGRldmljZSBpbiB4
QVBJQyBtb2RlIGVhc2lseS4KCkhvdyB0aGF0PwoKPiB4MkFQSUMgbW9kZQo+IChpbiB0b2dldGhl
ciB3aXRoIEludGVycnVwdCBSZW1hcHBpbmcpIGNvdWxkIGdpdmUgbWl0aWdhdGlvbiBhZ2FpbnN0
Cj4gc3VjaCBtYWxpY2lvdXMgRE1BIHdyaXRlcyBieSBhY2Nlc3NpbmcgTEFQSUMgcmVnaXN0ZXJz
IHZpYSBNU1JzIGFuZAo+IGVuZm9yY2luZyB0aGUgUmVtYXBwYWJsZSBNU0kgZm9ybWF0LiBIb3dl
dmVyLCBpZiBhbiBhdHRhY2tlciBjYW4gY3JlYXRlCj4gTk1JIGNvbmRpdGlvbnMgaW4geDJhcGlj
IG1vZGUgYXMgd2VsbCwgdGhlbiB0aGUgUmVtYXBwYWJsZSBGb3JtYXQgZG9lcwo+IG5vdCBtYWtl
IHNlbnNlIGF0IGFsbCAoYXMgdGhlIE5NSSBpcyBub3QgaGFuZGxlZCBieSB0aGUgcmVtYXBwaW5n
Cj4gZW5naW5lKS4gU28gd2hhdCBJIGZlZWwgdGhhdCB0aGVyZSBpcyBubyByZWFsIGhhcmR3YXJl
L3NvZnR3YXJlIHNvbHV0aW9uCj4gZm9yIHRoaXMgaXNzdWUuLi4KClRoZXJlIHNob3VsZG4ndCBi
ZSB3YXlzIGZvciBzb2Z0d2FyZSB0byBjYXVzZSBOTUlzLCBvdGhlciB0aGFuCmJ5IG1hbmlwdWxh
dGluZyB0aGUgTEFQSUMgZGlyZWN0bHkgKHdoaWNoIG9ubHkgdGhlIGh5cGVydmlzb3IgY2FuKQpv
ciB3cml0aW5nIG1hbGZvcm1lZCBNU0kgbWVzc2FnZXMgKGFuZCB1bnByaXZpbGVnZWQgZ3Vlc3Rz
IGRvbid0CnRoZW1zZWx2ZXMgY29udHJvbCB3aGF0IGFkZHJlc3MvZGF0YSBwYWlyIGdldHMgcHJv
Z3JhbW1lZCBpbnRvCnRoZSByZXNwZWN0aXZlIGRldmljZSBmaWVsZHMpLgoKU0VSUiwgYWZhaWss
IHNob3VsZCBiZSByYWlzZWQgYnkgdGhlIGRldmljZSBpdHNlbGYgb25seSBmb3IgY2VydGFpbgpl
cnJvciBjb25kaXRpb25zLCBhbmQgaWYgc3VjaCBlcnJvciBjb25kaXRpb25zIGNhbiBiZSBlbmZv
cmNlZCBvbgpzb21lIHNwZWNpZmljIGRldmljZSBieSBpdHMgZHJpdmVyLCB0aGVuIHBhc3Npbmcg
dGhyb3VnaCBzdWNoIGEKZGV2aWNlIGlzIGluaGVyZW50bHkgaW5zZWN1cmUgKHdpdGggbm90aGlu
ZyB0aGUgaHlwZXJ2aXNvciBjYW4gZG8KYWJvdXQgaXQpLgoKPj4gTm90ZSB0aGF0IGJlY2F1c2Ug
b2YgdGhlIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIGRldmljZXMgcmFpc2luZwo+PiBzdWNoIGFu
IE5NSSwgSSB0aGluayBpdCBpcyBhbHNvIG5vdCBwb3NzaWJsZSBmb3IgWGVuIHRvIGFjdHVhbGx5
IGtub3cKPj4gd2hpY2ggZGV2aWNlKHMpIGNhdXNlZCB0aGUgTk1JLCBhbmQgaGVuY2UgaXQgaGFz
IG5vIHdheSB0bwo+PiBhc3NvY2lhdGUgaXQgd2l0aCBhIHBhcnRpY3VsYXIgZ3Vlc3QsIGV2ZW4g
aWYgaXQgd2FudGVkIHRvLgo+IAo+IENhbiB0aGlzIGV4cGxhaW4gd2h5IG15IE5NSSBkb2VzIG5v
dCBhcHBlYXIgaW4gdGhlIC9wcm9jL2ludGVycnVwdHMgaW4KPiBkb20wIHdoaWxlIHRoZSBoYW5k
bGVyIGlzIGV4ZWN1dGVkIHdpdGggcmluZzEgcHJpdmlsZWdlcz8KCkF0IGxlYXN0IG9uZSBOTUkg
aW5zdGFuY2Ugc2hvdWxkIHNob3cgdXAgaW4gdGhlIHN0YXRpc3RpY3MuCgpKYW4KCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:08:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:08: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 1U5BqN-0005mU-CQ; Tue, 12 Feb 2013 09:08:03 +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 1U5BqL-0005mP-V7
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:08:02 +0000
Received: from [85.158.139.211:37966] by server-2.bemta-5.messagelabs.com id
	C4/CE-16911-0760A115; Tue, 12 Feb 2013 09:08:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360660076!18152577!1
X-Originating-IP: [195.135.221.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15499 invoked from network); 12 Feb 2013 09:07:56 -0000
Received: from smtp.nue.novell.com (HELO smtp.nue.novell.com) (195.135.221.5)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 09:07:56 -0000
Received: from EMEA5-MTA by smtp.nue.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:07:55 +0100
Message-Id: <511A147802000078000BDA2B@smtp.nue.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:07:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?R8OhYm9yIFDDiUs=?=" <pek@crysys.hu>
References: <511510FA.8010109@crysys.hu>
	<51153C2902000078000BD4A6@nat28.tlf.novell.com>
	<5118CA6C.8060809@crysys.hu>
In-Reply-To: <5118CA6C.8060809@crysys.hu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] NMI SERR interrupts in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDExLjAyLjEzIGF0IDExOjM5LCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90
ZToKPiBPbiAyMDEzLjAyLjA4LiAxNzo1NSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+IE9uIDA4
LjAyLjEzIGF0IDE1OjUxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90ZToKPj4+IFsr
XSBBdCB0aGUgc2FtZSB0aW1lLCBQQ0kgU0VSUiBpbnRlcnJ1cHRzIHJlZmVyIHRvIGhhcmR3YXJl
IGVycm9ycyB0aGF0Cj4+PiBpcyBnZW5lcmF0ZWQgYnkgbXkgcGFzc3Rocm91Z2ggTklDIGRpcmVj
dGx5LCBzbyBJIGV4cGVjdCB0aGF0IHRoZXNlCj4+PiBpbnRlcnJ1cHRzIGFyZSBwaHlzaWNhbCAo
ZS5nLiwgTVNJcykgc28gdGhleSBzaG91bGQgZ28gZGlyZWN0bHkgZWl0aGVyCj4+PiB0byB0aGUg
QlNQIG9yIG9uZSBvZiB0aGUgQVBzLiBIb3dldmVyLCBJbnRlcnJ1cHQgcmVtYXBwaW5nIGlzIGlu
IHBsYWNlCj4+PiB3aGljaCBzaG91bGQgY2hlY2sgdGhlIG9yaWdpbiBvZiBzdWNoIGludGVycnVw
dHMgYW5kIHNob3VsZCByZW1hcCB0aGUKPj4+IGludGVycnVwdHMgYnkgdXNpbmcgdGhlIEJERiBp
ZCBvZiB0aGUgZGV2aWNlLiBUaHVzLCB0aGUgcmVhbCBpbnRlcnJ1cHQKPj4+IGlzIGdlbmVyYXRl
ZCBieSB0aGUgSW50ZXJydXB0IFJlbWFwcGluZyBoYXJkd2FyZSB1bml0IHdoaWNoIGlzIHN0aWxs
IGEKPj4+IHBoeXNpY2FsIG9uZS4gQW0gSSByaWdodD8KPj4gCj4+IE5vLCBOTUlzIGRvbid0IGdv
IHRocm91Z2ggdGhlIHJlbWFwcGluZyBoYXJkd2FyZSwgdGhleSBnZXQKPj4gZGVsaXZlcmVkIGRp
cmVjdGx5IHRvIHRoZSBDUFUuIFdoaWNoIG1ha2VzIHNlbnNlLCBiZWNhdXNlIHRoZXkKPj4gcG9p
bnQgb3V0IGEgcHJvYmxlbSBpbiB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIHJlZ2FyZGxlc3Mgb2YK
Pj4gd2hldGhlciBhIGRldmljZSBoYXZpbmcgY2F1c2VkIHRoZW0gaXMgYXNzaWduZWQgdG8gYSBn
dWVzdAo+IAo+IEkgZmFjZWQgdGhpcyBOTUkgaXNzdWUgd2hpbGUgbG9va2luZyBhdCB0aGUgc2Vj
dXJpdHkgb2YgWGVuLCBob3dldmVyLCBpdAo+IHJhaXNlcyBzZWN1cml0eSBjb25jZXJucyBpbiBt
eSBtaW5kLiBJZiBhbiBOTUkgZG9lcyBub3QgZ28gdGhyb3VnaCB0aGUKPiBJbnRlcnJ1cHQgUmVt
YXBwaW5nIGVuZ2luZSAod2hpY2ggbWFrZXMgc2Vuc2UgZHVlIHRvIGl0cyBub24tbWFza2FibGUK
PiBuYXR1cmUpLCB0aGVuIGEgIm1hbGljaW91cyIgTk1JIGNvdWxkIGdpdmUgcmlzZSB0byBlaXRo
ZXIgYSBEb1MgYXR0YWNrCj4gb3IgY29kZSBleGVjdXRpb24gcHJvYmxlbXMgd2l0aCByaW5nMSBw
cml2aWxlZ2VzLiBJbiB0aGUgZm9ybWVyIGNhc2UgdGhlCj4gcmVhc29uIGNvdWxkIGJlIHRoZSB1
bmNsZWFyZWQgRU9JIHJlZ2lzdGVyIGZvciB0aGUgc3BlY2lmaWMgQ1BVIGFmdGVyCj4gTk1JIGdl
bmVyYXRpb24sIHdoaWxlIGluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgY29kZSBpbmplY3Rpb24gbWln
aHQgYmUKPiBkaWZmaWN1bHQsIGJ1dCB0aGUgY29uY2VybiBpcyBzdGlsbCB2YWxpZCBJIHRoaW5r
LgoKSSdtIGFmcmFpZCB5b3UncmUgbWl4aW5nIHVwIHRoaW5ncyBoZXJlLiBBbiBOTUkgZG9lc24n
dCByZXF1aXJlIGFuCkVPSSAoYXMgaXQncyBub3QgYSB2ZWN0b3JlZCBpbnRlcnJ1cHQsIGFuZCBh
cyBzdWNoIGRvZXNuJ3QgZ28KdGhyb3VnaCB0aGUgbm9ybWFsIExBUElDIHByb2Nlc3NpbmcgYXQg
YWxsOyBDUFVzIGhhdmUgYSBkZWRpY2F0ZWQKW3ZpcnR1YWxdIGlucHV0IGZvciB0aGlzKS4KCj4g
RnVydGhlcm1vcmUsIGFuIGF0dGFja2VyIGNhbiBnZW5lcmF0ZSBzdWNoIE5NSXMgdmlhIE1TSXMg
ZnJvbSB1bnRydXN0ZWQKPiBIVk0gZG9tYWlucyBieSBtZWFucyBvZiBhIFBUIGRldmljZSBpbiB4
QVBJQyBtb2RlIGVhc2lseS4KCkhvdyB0aGF0PwoKPiB4MkFQSUMgbW9kZQo+IChpbiB0b2dldGhl
ciB3aXRoIEludGVycnVwdCBSZW1hcHBpbmcpIGNvdWxkIGdpdmUgbWl0aWdhdGlvbiBhZ2FpbnN0
Cj4gc3VjaCBtYWxpY2lvdXMgRE1BIHdyaXRlcyBieSBhY2Nlc3NpbmcgTEFQSUMgcmVnaXN0ZXJz
IHZpYSBNU1JzIGFuZAo+IGVuZm9yY2luZyB0aGUgUmVtYXBwYWJsZSBNU0kgZm9ybWF0LiBIb3dl
dmVyLCBpZiBhbiBhdHRhY2tlciBjYW4gY3JlYXRlCj4gTk1JIGNvbmRpdGlvbnMgaW4geDJhcGlj
IG1vZGUgYXMgd2VsbCwgdGhlbiB0aGUgUmVtYXBwYWJsZSBGb3JtYXQgZG9lcwo+IG5vdCBtYWtl
IHNlbnNlIGF0IGFsbCAoYXMgdGhlIE5NSSBpcyBub3QgaGFuZGxlZCBieSB0aGUgcmVtYXBwaW5n
Cj4gZW5naW5lKS4gU28gd2hhdCBJIGZlZWwgdGhhdCB0aGVyZSBpcyBubyByZWFsIGhhcmR3YXJl
L3NvZnR3YXJlIHNvbHV0aW9uCj4gZm9yIHRoaXMgaXNzdWUuLi4KClRoZXJlIHNob3VsZG4ndCBi
ZSB3YXlzIGZvciBzb2Z0d2FyZSB0byBjYXVzZSBOTUlzLCBvdGhlciB0aGFuCmJ5IG1hbmlwdWxh
dGluZyB0aGUgTEFQSUMgZGlyZWN0bHkgKHdoaWNoIG9ubHkgdGhlIGh5cGVydmlzb3IgY2FuKQpv
ciB3cml0aW5nIG1hbGZvcm1lZCBNU0kgbWVzc2FnZXMgKGFuZCB1bnByaXZpbGVnZWQgZ3Vlc3Rz
IGRvbid0CnRoZW1zZWx2ZXMgY29udHJvbCB3aGF0IGFkZHJlc3MvZGF0YSBwYWlyIGdldHMgcHJv
Z3JhbW1lZCBpbnRvCnRoZSByZXNwZWN0aXZlIGRldmljZSBmaWVsZHMpLgoKU0VSUiwgYWZhaWss
IHNob3VsZCBiZSByYWlzZWQgYnkgdGhlIGRldmljZSBpdHNlbGYgb25seSBmb3IgY2VydGFpbgpl
cnJvciBjb25kaXRpb25zLCBhbmQgaWYgc3VjaCBlcnJvciBjb25kaXRpb25zIGNhbiBiZSBlbmZv
cmNlZCBvbgpzb21lIHNwZWNpZmljIGRldmljZSBieSBpdHMgZHJpdmVyLCB0aGVuIHBhc3Npbmcg
dGhyb3VnaCBzdWNoIGEKZGV2aWNlIGlzIGluaGVyZW50bHkgaW5zZWN1cmUgKHdpdGggbm90aGlu
ZyB0aGUgaHlwZXJ2aXNvciBjYW4gZG8KYWJvdXQgaXQpLgoKPj4gTm90ZSB0aGF0IGJlY2F1c2Ug
b2YgdGhlIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIGRldmljZXMgcmFpc2luZwo+PiBzdWNoIGFu
IE5NSSwgSSB0aGluayBpdCBpcyBhbHNvIG5vdCBwb3NzaWJsZSBmb3IgWGVuIHRvIGFjdHVhbGx5
IGtub3cKPj4gd2hpY2ggZGV2aWNlKHMpIGNhdXNlZCB0aGUgTk1JLCBhbmQgaGVuY2UgaXQgaGFz
IG5vIHdheSB0bwo+PiBhc3NvY2lhdGUgaXQgd2l0aCBhIHBhcnRpY3VsYXIgZ3Vlc3QsIGV2ZW4g
aWYgaXQgd2FudGVkIHRvLgo+IAo+IENhbiB0aGlzIGV4cGxhaW4gd2h5IG15IE5NSSBkb2VzIG5v
dCBhcHBlYXIgaW4gdGhlIC9wcm9jL2ludGVycnVwdHMgaW4KPiBkb20wIHdoaWxlIHRoZSBoYW5k
bGVyIGlzIGV4ZWN1dGVkIHdpdGggcmluZzEgcHJpdmlsZWdlcz8KCkF0IGxlYXN0IG9uZSBOTUkg
aW5zdGFuY2Ugc2hvdWxkIHNob3cgdXAgaW4gdGhlIHN0YXRpc3RpY3MuCgpKYW4KCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:31:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09: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 1U5CCT-0006E3-6L; Tue, 12 Feb 2013 09:30:53 +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 1U5CCR-0006Dy-DM
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:30:51 +0000
Received: from [85.158.137.99:25554] by server-12.bemta-3.messagelabs.com id
	32/35-05889-ACB0A115; Tue, 12 Feb 2013 09:30:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360661448!16349815!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23652 invoked from network); 12 Feb 2013 09:30:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 09:30:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 09:30:50 +0000
Message-Id: <511A19D202000078000BDA3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 09:30:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-15450-mainreport@xen.org>
In-Reply-To: <osstest-15450-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 15450: regressions - 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 09.02.13 at 01:08, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 15450 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15450/ 
> 
> Regressions :-(

So why did this do a push?

Jan

> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-pv            14 guest-localmigrate/x10    fail REGR. vs. 15434
>  test-amd64-i386-qemut-win 12 guest-localmigrate/x10 fail REGR. vs. 15466-bisect
>  test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15434
>  test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15434
>  test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 15434
>  test-i386-i386-qemut-win      7 windows-install           fail REGR. vs. 15434
>  test-i386-i386-win           11 guest-localmigrate.2      fail REGR. vs. 15434
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15434
>  test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15434
>  test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15434
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-pv          13 guest-localmigrate.2        fail pass in 15445
>  test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15445 pass in 
> 15465-bisect
>  test-amd64-i386-win           7 windows-install    fail in 15445 pass in 15450
>  test-amd64-amd64-win          7 windows-install    fail in 15445 pass in 15450
>  test-amd64-amd64-qemut-win    7 windows-install    fail in 15445 pass in 15450
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15434
> 
> Tests which did not succeed, but are not blocking:
>  build-armhf                   4 xen-build                    fail   never 
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
>  test-i386-i386-xl-qemut-win  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-win      13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
>  test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
>  test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
>  test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
>  test-i386-i386-xl-qemut-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
>  test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
> 
> version targeted for testing:
>  xen                  c713f1f7d3c1
> baseline version:
>  xen                  b8a523d9f14c
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Boris Ostrovsky <boris.ostrovsky@amd.com>
>   David Scott <dave.scott@eu.citrix.com>
>   Ian Campbell <Ian.Campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Matthew Daley <mattjd@gmail.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-armhf                                                  fail    
>  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                                 pass    
>  test-amd64-i386-qemut-rhel6hvm-amd                           pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemut-win7-amd64                         fail    
>  test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  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                                            fail    
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-qemut-win-vcpus1                             fail    
>  test-amd64-i386-xl-qemut-win-vcpus1                          fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
>  test-amd64-i386-qemut-win                                    fail    
>  test-i386-i386-qemut-win                                     fail    
>  test-amd64-amd64-xl-qemut-win                                fail    
>  test-i386-i386-xl-qemut-win                                  fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-qemut-winxpsp3                          fail    
>  test-amd64-amd64-xl-qemut-winxpsp3                           fail    
>  test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
> + revision=c713f1f7d3c1
> + . 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.2-testing 
> c713f1f7d3c1
> + branch=xen-4.2-testing
> + revision=c713f1f7d3c1
> + . 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.2-testing
> + '[' xxen = xlinux ']'
> + linuxbranch=linux
> + : master
> + : tested/2.6.39.x
> + . ap-common
> ++ : xen@xenbits.xensource.com 
> ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg 
> ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-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.2-testing
> ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 
> ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
> ++ : daily-cron.xen-4.2-testing
> + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
> + 
> TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
> 
> + info_linux_tree xen-4.2-testing
> + case $1 in
> + return 1
> + case "$branch" in
> + cd /export/home/osstest/repos/xen-4.2-testing.hg
> + hg push -r c713f1f7d3c1 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
> pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
> searching for changes
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: added 2 changesets with 2 changes to 2 files
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 12 09:31:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09: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 1U5CCT-0006E3-6L; Tue, 12 Feb 2013 09:30:53 +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 1U5CCR-0006Dy-DM
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:30:51 +0000
Received: from [85.158.137.99:25554] by server-12.bemta-3.messagelabs.com id
	32/35-05889-ACB0A115; Tue, 12 Feb 2013 09:30:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360661448!16349815!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23652 invoked from network); 12 Feb 2013 09:30:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 09:30:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 09:30:50 +0000
Message-Id: <511A19D202000078000BDA3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 09:30:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-15450-mainreport@xen.org>
In-Reply-To: <osstest-15450-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 15450: regressions - 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 09.02.13 at 01:08, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 15450 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/15450/ 
> 
> Regressions :-(

So why did this do a push?

Jan

> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-pv            14 guest-localmigrate/x10    fail REGR. vs. 15434
>  test-amd64-i386-qemut-win 12 guest-localmigrate/x10 fail REGR. vs. 15466-bisect
>  test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10   fail REGR. vs. 15434
>  test-amd64-i386-win          11 guest-localmigrate.2      fail REGR. vs. 15434
>  test-amd64-amd64-win         12 guest-localmigrate/x10    fail REGR. vs. 15434
>  test-i386-i386-qemut-win      7 windows-install           fail REGR. vs. 15434
>  test-i386-i386-win           11 guest-localmigrate.2      fail REGR. vs. 15434
>  test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 15434
>  test-amd64-i386-xend-qemut-winxpsp3  7 windows-install    fail REGR. vs. 15434
>  test-amd64-i386-qemut-win-vcpus1  7 windows-install       fail REGR. vs. 15434
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-pv          13 guest-localmigrate.2        fail pass in 15445
>  test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail in 15445 pass in 
> 15465-bisect
>  test-amd64-i386-win           7 windows-install    fail in 15445 pass in 15450
>  test-amd64-amd64-win          7 windows-install    fail in 15445 pass in 15450
>  test-amd64-amd64-qemut-win    7 windows-install    fail in 15445 pass in 15450
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15434
> 
> Tests which did not succeed, but are not blocking:
>  build-armhf                   4 xen-build                    fail   never 
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
>  test-i386-i386-xl-qemut-win  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-win      13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
>  test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
>  test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
>  test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
>  test-i386-i386-xl-qemut-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-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
>  test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
> 
> version targeted for testing:
>  xen                  c713f1f7d3c1
> baseline version:
>  xen                  b8a523d9f14c
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Boris Ostrovsky <boris.ostrovsky@amd.com>
>   David Scott <dave.scott@eu.citrix.com>
>   Ian Campbell <Ian.Campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Matthew Daley <mattjd@gmail.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-armhf                                                  fail    
>  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                                 pass    
>  test-amd64-i386-qemut-rhel6hvm-amd                           pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemut-win7-amd64                         fail    
>  test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  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                                            fail    
>  test-amd64-amd64-xl-sedf                                     pass    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-qemut-win-vcpus1                             fail    
>  test-amd64-i386-xl-qemut-win-vcpus1                          fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
>  test-amd64-i386-qemut-win                                    fail    
>  test-i386-i386-qemut-win                                     fail    
>  test-amd64-amd64-xl-qemut-win                                fail    
>  test-i386-i386-xl-qemut-win                                  fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-i386-i386-xl-win                                        fail    
>  test-amd64-i386-xend-qemut-winxpsp3                          fail    
>  test-amd64-amd64-xl-qemut-winxpsp3                           fail    
>  test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
> + revision=c713f1f7d3c1
> + . 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.2-testing 
> c713f1f7d3c1
> + branch=xen-4.2-testing
> + revision=c713f1f7d3c1
> + . 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.2-testing
> + '[' xxen = xlinux ']'
> + linuxbranch=linux
> + : master
> + : tested/2.6.39.x
> + . ap-common
> ++ : xen@xenbits.xensource.com 
> ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg 
> ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-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.2-testing
> ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 
> ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
> ++ : daily-cron.xen-4.2-testing
> + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
> + 
> TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
> 
> + info_linux_tree xen-4.2-testing
> + case $1 in
> + return 1
> + case "$branch" in
> + cd /export/home/osstest/repos/xen-4.2-testing.hg
> + hg push -r c713f1f7d3c1 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
> pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
> searching for changes
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: added 2 changesets with 2 changes to 2 files
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 12 09:44:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09: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 1U5CPf-0006UZ-JD; Tue, 12 Feb 2013 09:44: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 1U5CPe-0006UU-5A
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:44:30 +0000
Received: from [85.158.143.35:41565] by server-3.bemta-4.messagelabs.com id
	7B/86-08920-DFE0A115; Tue, 12 Feb 2013 09:44:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360662255!14808234!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9148 invoked from network); 12 Feb 2013 09:44:17 -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; 12 Feb 2013 09:44:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 09:44:15 +0000
Message-Id: <511A1CF902000078000BDA47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 09:44:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4.0-testing 00/10] XSA-{25, 27, 33,
 36}: Backports for 4.0 (for Debian update)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The only one which I'm a bit uncertain about is XSA-36, not because the
> backport was hard but because I'm not sure what if anything my be needed
> as an antecedent to those patches. I already included a backport of "AMD
> IOMMU: Fix an interrupt remapping issue" (unstable 23200:995a0c01a076).

Since I also had to bring the XSA-36 fixes over to 4.0.x the other
day, here's what I included as prereqs:

23752:ef9ed3d2aa87
23753:2e0cf9428554
23754:fa4e2ca9ecff
23765:68b903bb1b01
23786:3a05da2dc7c0
23812:32814ad7458d
23899:a99d75671a91 (non-essential, but allowing eases other things)
24155:0d50e704834f
24156:f29b5bd6e25f

There may be others (like 23200 that you mentioned) which we
already had in our tree, and hence I didn't directly notice as prereq.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:44:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09: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 1U5CPf-0006UZ-JD; Tue, 12 Feb 2013 09:44: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 1U5CPe-0006UU-5A
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:44:30 +0000
Received: from [85.158.143.35:41565] by server-3.bemta-4.messagelabs.com id
	7B/86-08920-DFE0A115; Tue, 12 Feb 2013 09:44:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360662255!14808234!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9148 invoked from network); 12 Feb 2013 09:44:17 -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; 12 Feb 2013 09:44:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 09:44:15 +0000
Message-Id: <511A1CF902000078000BDA47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 09:44:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360588355.20449.34.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4.0-testing 00/10] XSA-{25, 27, 33,
 36}: Backports for 4.0 (for Debian update)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> The only one which I'm a bit uncertain about is XSA-36, not because the
> backport was hard but because I'm not sure what if anything my be needed
> as an antecedent to those patches. I already included a backport of "AMD
> IOMMU: Fix an interrupt remapping issue" (unstable 23200:995a0c01a076).

Since I also had to bring the XSA-36 fixes over to 4.0.x the other
day, here's what I included as prereqs:

23752:ef9ed3d2aa87
23753:2e0cf9428554
23754:fa4e2ca9ecff
23765:68b903bb1b01
23786:3a05da2dc7c0
23812:32814ad7458d
23899:a99d75671a91 (non-essential, but allowing eases other things)
24155:0d50e704834f
24156:f29b5bd6e25f

There may be others (like 23200 that you mentioned) which we
already had in our tree, and hence I didn't directly notice as prereq.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:54:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:54: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 1U5CYm-0006gT-Pi; Tue, 12 Feb 2013 09:53: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 1U5CYl-0006gO-U8
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:53:56 +0000
Received: from [85.158.139.211:41095] by server-9.bemta-5.messagelabs.com id
	55/EB-24440-3311A115; Tue, 12 Feb 2013 09:53:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360662834!22070886!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14401 invoked from network); 12 Feb 2013 09:53:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 09:53:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 09:53:54 +0000
Message-Id: <511A1F3D02000078000BDA51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 09:53:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "James Harper" <james.harper@bendigoit.com.au>,
	"George Dunlap" <george.dunlap@eu.citrix.com>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
In-Reply-To: <5118D893.7020102@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:40, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 11/02/13 11:39, James Harper wrote:
>>> On Mon, Feb 11, 2013 at 12:03 AM, James Harper
>>> <james.harper@bendigoit.com.au> wrote:
>>>
>>> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
>>> using PoD. I'm using the difference between
>>> XENMEM_maximum_reservation and XENMEM_current_reservation to tell
>>> me how much I should balloon down to account for PoD, but when the user
>>> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
>>>
>>> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
>>> 262400
>>> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
>>> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
>>>
>>> 	What is the correct way to tell how much PoD memory there is under
>>> 4.2? Am I doing it wrong?
>>>
>>> 	I balloon down as early as possible (before xenbus starts) to avoid
>>> windows going over its limit so I'm hoping I can determine the size of PoD
>>> memory just via hypercalls.
>>>
>>>
>>>
>>> You shouldn't have to know anything specifically about PoD -- you should just
>>> look at the balloon target for the guest written in xenstore.  The idea was 
> as
>>> much as possible for the toolstack and Xen to work together to make it
>>> transparent to the balloon driver, in part because we expected to be running
>>> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
>>> memory.  (Paul, please correct me if I'm wrong.)
>> So I should just balloon down to the current_reservation figure right?
> 
> ...I don't think so -- it looks like you're getting that from a 
> hypercall, not from xenstore.  You want the normal balloon target value 
> from xenstore.  (But I might be confused -- I'm not super familiar with 
> the technical details of the ballooning codepath, just the overall 
> principles.)

As James said, this ought to run without xenbus having initialized
(so it can be done as early as possible). Hence the need for doing
this via hypercalls. The "classic" Xen balloon driver does so too, btw.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:54:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:54: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 1U5CYm-0006gT-Pi; Tue, 12 Feb 2013 09:53: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 1U5CYl-0006gO-U8
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:53:56 +0000
Received: from [85.158.139.211:41095] by server-9.bemta-5.messagelabs.com id
	55/EB-24440-3311A115; Tue, 12 Feb 2013 09:53:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360662834!22070886!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14401 invoked from network); 12 Feb 2013 09:53:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 09:53:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 09:53:54 +0000
Message-Id: <511A1F3D02000078000BDA51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 09:53:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "James Harper" <james.harper@bendigoit.com.au>,
	"George Dunlap" <george.dunlap@eu.citrix.com>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
In-Reply-To: <5118D893.7020102@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:40, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 11/02/13 11:39, James Harper wrote:
>>> On Mon, Feb 11, 2013 at 12:03 AM, James Harper
>>> <james.harper@bendigoit.com.au> wrote:
>>>
>>> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
>>> using PoD. I'm using the difference between
>>> XENMEM_maximum_reservation and XENMEM_current_reservation to tell
>>> me how much I should balloon down to account for PoD, but when the user
>>> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
>>>
>>> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
>>> 262400
>>> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
>>> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
>>>
>>> 	What is the correct way to tell how much PoD memory there is under
>>> 4.2? Am I doing it wrong?
>>>
>>> 	I balloon down as early as possible (before xenbus starts) to avoid
>>> windows going over its limit so I'm hoping I can determine the size of PoD
>>> memory just via hypercalls.
>>>
>>>
>>>
>>> You shouldn't have to know anything specifically about PoD -- you should just
>>> look at the balloon target for the guest written in xenstore.  The idea was 
> as
>>> much as possible for the toolstack and Xen to work together to make it
>>> transparent to the balloon driver, in part because we expected to be running
>>> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
>>> memory.  (Paul, please correct me if I'm wrong.)
>> So I should just balloon down to the current_reservation figure right?
> 
> ...I don't think so -- it looks like you're getting that from a 
> hypercall, not from xenstore.  You want the normal balloon target value 
> from xenstore.  (But I might be confused -- I'm not super familiar with 
> the technical details of the ballooning codepath, just the overall 
> principles.)

As James said, this ought to run without xenbus having initialized
(so it can be done as early as possible). Hence the need for doing
this via hypercalls. The "classic" Xen balloon driver does so too, btw.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:58:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:58: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 1U5CdD-0006oV-Gh; Tue, 12 Feb 2013 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 <james.harper@bendigoit.com.au>) id 1U5CdC-0006oQ-QV
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:58:31 +0000
Received: from [85.158.143.35:40916] by server-2.bemta-4.messagelabs.com id
	DB/92-01597-5421A115; Tue, 12 Feb 2013 09:58:29 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360662970!12055737!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14800 invoked from network); 12 Feb 2013 09:56:13 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 09:56:13 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5Caf-0007zh-NY; Tue, 12 Feb 2013 20:55:53 +1100
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 id
	14.01.0438.000; Tue, 12 Feb 2013 20:55:53 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Jan Beulich <JBeulich@suse.com>, George Dunlap
	<george.dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgAAAdQUAABfjY9D//0hNgIABdKaA//9HWRA=
Date: Tue, 12 Feb 2013 09:55:52 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35668A23@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
	<511A1F3D02000078000BDA51@nat28.tlf.novell.com>
In-Reply-To: <511A1F3D02000078000BDA51@nat28.tlf.novell.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19632.001
x-tm-as-result: No--39.214300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 I should just balloon down to the current_reservation figure right?
> >
> > ...I don't think so -- it looks like you're getting that from a
> > hypercall, not from xenstore.  You want the normal balloon target value
> > from xenstore.  (But I might be confused -- I'm not super familiar with
> > the technical details of the ballooning codepath, just the overall
> > principles.)
> 
> As James said, this ought to run without xenbus having initialized
> (so it can be done as early as possible). Hence the need for doing
> this via hypercalls. The "classic" Xen balloon driver does so too, btw.
> 

So is my mistake simply that I'm assuming that 'maximum reservation' == 'total memory?

It occurs to me that I don't actually know how to get the total amount of memory from a windows driver... guess I'd better look it up!

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:58:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:58: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 1U5CdD-0006oV-Gh; Tue, 12 Feb 2013 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 <james.harper@bendigoit.com.au>) id 1U5CdC-0006oQ-QV
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:58:31 +0000
Received: from [85.158.143.35:40916] by server-2.bemta-4.messagelabs.com id
	DB/92-01597-5421A115; Tue, 12 Feb 2013 09:58:29 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360662970!12055737!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14800 invoked from network); 12 Feb 2013 09:56:13 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 09:56:13 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5Caf-0007zh-NY; Tue, 12 Feb 2013 20:55:53 +1100
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 id
	14.01.0438.000; Tue, 12 Feb 2013 20:55:53 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Jan Beulich <JBeulich@suse.com>, George Dunlap
	<george.dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgAAAdQUAABfjY9D//0hNgIABdKaA//9HWRA=
Date: Tue, 12 Feb 2013 09:55:52 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35668A23@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
	<511A1F3D02000078000BDA51@nat28.tlf.novell.com>
In-Reply-To: <511A1F3D02000078000BDA51@nat28.tlf.novell.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19632.001
x-tm-as-result: No--39.214300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 I should just balloon down to the current_reservation figure right?
> >
> > ...I don't think so -- it looks like you're getting that from a
> > hypercall, not from xenstore.  You want the normal balloon target value
> > from xenstore.  (But I might be confused -- I'm not super familiar with
> > the technical details of the ballooning codepath, just the overall
> > principles.)
> 
> As James said, this ought to run without xenbus having initialized
> (so it can be done as early as possible). Hence the need for doing
> this via hypercalls. The "classic" Xen balloon driver does so too, btw.
> 

So is my mistake simply that I'm assuming that 'maximum reservation' == 'total memory?

It occurs to me that I don't actually know how to get the total amount of memory from a windows driver... guess I'd better look it up!

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:59:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:59: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 1U5Cde-0006q7-Tr; Tue, 12 Feb 2013 09:58: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 1U5Cdc-0006pw-U3
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:58:57 +0000
Received: from [85.158.143.99:10597] by server-2.bemta-4.messagelabs.com id
	D5/43-01597-0621A115; Tue, 12 Feb 2013 09:58:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360663135!27927909!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31520 invoked from network); 12 Feb 2013 09:58:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 09:58:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1363978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 09:58: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.297.1;
	Tue, 12 Feb 2013 09:58:55 +0000
Message-ID: <1360663133.20449.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 12 Feb 2013 09:58:53 +0000
In-Reply-To: <1360583103.16636.29.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-11 at 11:45 +0000, Wei Liu wrote:
> On Sun, 2013-02-10 at 22:03 +0000, Christopher S. Aker wrote:
> > And another this afternoon on a different machine:
> > 
> > BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
> 
> OK, so the guest is faulting at different offset now. It is very likely
> that there is OOM / race condition in other places. And judging from
> your two emails, I presume this bug can be reproduce steadily.
> 
> > IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> > PGD 0
> > Oops: 0002 [#1] SMP
> > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> > ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
> > CPU 5
> > Pid: 1550, comm: netback/5 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
> > X8DT6/X8DT6
> > RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> > xen_spin_lock_flags+0x3a/0x80
> > RSP: e02b:ffff8800836e7b58  EFLAGS: 00010006
> > RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 000000000045de5d
> > RDX: 0000000000000001 RSI: 0000000000000211 RDI: 00000000000008b8
> > RBP: ffff8800836e7b78 R08: 0000000000000068 R09: 0000000000000000
> > R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
> > R13: 0000000000000200 R14: 0000000000000400 R15: 000000000045de5d
> > FS:  00007f474a465700(0000) GS:ffff880100740000(0000) knlGS:0000000000000000
> > CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process netback/5 (pid: 1550, threadinfo ffff8800836e6000, task 
> > ffff880084510000)
> > Stack:
> >   0000000000000211 00000000000008b8 ffff8800771e5700 ffff8800771e57d8
> >   ffff8800836e7b98 ffffffff817605da 0000000000000000 00000000000008b8
> >   ffff8800836e7bd8 ffffffff8154446f ffff8800771e5000 0000000000000000
> > Call Trace:
> >   [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
> >   [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
> >   [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
> >   [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
> >   [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
> >   [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
> >   [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
> >   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> >   [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
> >   [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
> >   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> >   [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
> >   [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
> >   [<ffffffff81071a06>] kthread+0xc6/0xd0
> >   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
> >   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
> >   [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
> >   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
> [snip]
> > 
> > We're not so good at this, but it looks like xl->lock deref is what we 
> > hit?  The lock was gone?
> > 
> 
> A quick check on the xen_spinlock struct, its offset should not be
> 0x8b8.

This originally came from "&netbk->net_schedule_list_lock" in
xen_netbk_schedule_xenvif so I guess most of the 0x8b8 came from the
offset of net_schedule_list_lock.


>  Reading the backtrace suggests that it is the netbk struct is
> gone.

Yes. It would be interesting to add
	if (!netbk)
		netdev_err(vif->dev, "vif has no associated netbk!");
and also to add prints to xen_netbk_add_xenvif() and
xen_netbk_remove_xenvif() to track to setup and teardown of the
vif<->netbk relationships (these are infrequent, only when a vif is
opened/closed, so it might be that dumping a stack trace is
plausible/useful especially on the teardown).

It would also be useful to confirm that the netbk selected in
xen_netbk_add_xenvif is non-NULL and that its index relates sanely to
xen_netbk_group_nr.

There should be no way for a vif to get on the schedule list without
being associated with a non-NULL netbk. Here the call chain is through
xen_netbk_tx_build_gops -> netbk_tx_err -> xen_netbk_check_rx_xenvif.
However the netback variable in xen_netbk_tx_build_gops has been used
several times before we even get near any call to netbk_tx_err. I
suppose adding a check
	if (vif->netbk != netbk)
		netdev_err(vif->dev, "has netbk %p should be %p!");
right after the !vif check at the top of the loop would also be
interesting.

Have you applied the XSA-39 fixes to this kernel? Every invocation of
netbk_tx_err *should* have an associated error print, I think, at least
after that change, if you are before it would be worth just checking.
Either way you'll need to turn on debugging (or s/pr_dbg/pr_err/ in
netback.c). Knowing which call to tx_err occurred might yield a clue.

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 09:59:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 09:59: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 1U5Cde-0006q7-Tr; Tue, 12 Feb 2013 09:58: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 1U5Cdc-0006pw-U3
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 09:58:57 +0000
Received: from [85.158.143.99:10597] by server-2.bemta-4.messagelabs.com id
	D5/43-01597-0621A115; Tue, 12 Feb 2013 09:58:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360663135!27927909!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31520 invoked from network); 12 Feb 2013 09:58:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 09:58:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1363978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 09:58: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.297.1;
	Tue, 12 Feb 2013 09:58:55 +0000
Message-ID: <1360663133.20449.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 12 Feb 2013 09:58:53 +0000
In-Reply-To: <1360583103.16636.29.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-11 at 11:45 +0000, Wei Liu wrote:
> On Sun, 2013-02-10 at 22:03 +0000, Christopher S. Aker wrote:
> > And another this afternoon on a different machine:
> > 
> > BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
> 
> OK, so the guest is faulting at different offset now. It is very likely
> that there is OOM / race condition in other places. And judging from
> your two emails, I presume this bug can be reproduce steadily.
> 
> > IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> > PGD 0
> > Oops: 0002 [#1] SMP
> > Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> > ip_set_hash_net ip_set ebtable_nat xen_gntdev bonding ebtable_filter e1000e
> > CPU 5
> > Pid: 1550, comm: netback/5 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
> > X8DT6/X8DT6
> > RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> > xen_spin_lock_flags+0x3a/0x80
> > RSP: e02b:ffff8800836e7b58  EFLAGS: 00010006
> > RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 000000000045de5d
> > RDX: 0000000000000001 RSI: 0000000000000211 RDI: 00000000000008b8
> > RBP: ffff8800836e7b78 R08: 0000000000000068 R09: 0000000000000000
> > R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
> > R13: 0000000000000200 R14: 0000000000000400 R15: 000000000045de5d
> > FS:  00007f474a465700(0000) GS:ffff880100740000(0000) knlGS:0000000000000000
> > CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process netback/5 (pid: 1550, threadinfo ffff8800836e6000, task 
> > ffff880084510000)
> > Stack:
> >   0000000000000211 00000000000008b8 ffff8800771e5700 ffff8800771e57d8
> >   ffff8800836e7b98 ffffffff817605da 0000000000000000 00000000000008b8
> >   ffff8800836e7bd8 ffffffff8154446f ffff8800771e5000 0000000000000000
> > Call Trace:
> >   [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
> >   [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
> >   [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
> >   [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
> >   [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
> >   [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
> >   [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
> >   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> >   [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
> >   [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
> >   [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> >   [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
> >   [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
> >   [<ffffffff81071a06>] kthread+0xc6/0xd0
> >   [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
> >   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
> >   [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
> >   [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
> [snip]
> > 
> > We're not so good at this, but it looks like xl->lock deref is what we 
> > hit?  The lock was gone?
> > 
> 
> A quick check on the xen_spinlock struct, its offset should not be
> 0x8b8.

This originally came from "&netbk->net_schedule_list_lock" in
xen_netbk_schedule_xenvif so I guess most of the 0x8b8 came from the
offset of net_schedule_list_lock.


>  Reading the backtrace suggests that it is the netbk struct is
> gone.

Yes. It would be interesting to add
	if (!netbk)
		netdev_err(vif->dev, "vif has no associated netbk!");
and also to add prints to xen_netbk_add_xenvif() and
xen_netbk_remove_xenvif() to track to setup and teardown of the
vif<->netbk relationships (these are infrequent, only when a vif is
opened/closed, so it might be that dumping a stack trace is
plausible/useful especially on the teardown).

It would also be useful to confirm that the netbk selected in
xen_netbk_add_xenvif is non-NULL and that its index relates sanely to
xen_netbk_group_nr.

There should be no way for a vif to get on the schedule list without
being associated with a non-NULL netbk. Here the call chain is through
xen_netbk_tx_build_gops -> netbk_tx_err -> xen_netbk_check_rx_xenvif.
However the netback variable in xen_netbk_tx_build_gops has been used
several times before we even get near any call to netbk_tx_err. I
suppose adding a check
	if (vif->netbk != netbk)
		netdev_err(vif->dev, "has netbk %p should be %p!");
right after the !vif check at the top of the loop would also be
interesting.

Have you applied the XSA-39 fixes to this kernel? Every invocation of
netbk_tx_err *should* have an associated error print, I think, at least
after that change, if you are before it would be worth just checking.
Either way you'll need to turn on debugging (or s/pr_dbg/pr_err/ in
netback.c). Knowing which call to tx_err occurred might yield a clue.

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:01:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:01: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 1U5CfV-000746-Eb; Tue, 12 Feb 2013 10:00:53 +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 1U5CfT-00073y-92
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:00:51 +0000
Received: from [85.158.138.51:5415] by server-12.bemta-3.messagelabs.com id
	37/C9-05889-2D21A115; Tue, 12 Feb 2013 10:00:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360663247!32023844!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11412 invoked from network); 12 Feb 2013 10:00:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:00:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:00:49 +0000
Message-Id: <511A20DA02000078000BDA69@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:00:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
In-Reply-To: <e80418f1f58bf36fe953.1360596482@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: __devinit was removed
 in linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:28, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1360595055 -3600
> # Node ID e80418f1f58bf36fe953af587cc0e6dbd52dffa7
> # Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
> unmodified_drivers: __devinit was removed in linux-3.8

I recognize the need for dealing with this, but ...

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 2fdca30363f0 -r e80418f1f58b 
> unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h

... this is the wrong file. See compat-include/xen/platform-compat.h
(including how it already deals with non-present __init).

Jan

> @@ -24,6 +24,11 @@
>  
>  #include <linux/pci.h>
>  
> +#ifndef __devinit
> +#define __devinit
> +#define __devinitdata
> +#endif
> +
>  unsigned long alloc_xen_mmio(unsigned long len);
>  void platform_pci_resume(void);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 12 10:01:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:01: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 1U5CfV-000746-Eb; Tue, 12 Feb 2013 10:00:53 +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 1U5CfT-00073y-92
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:00:51 +0000
Received: from [85.158.138.51:5415] by server-12.bemta-3.messagelabs.com id
	37/C9-05889-2D21A115; Tue, 12 Feb 2013 10:00:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360663247!32023844!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11412 invoked from network); 12 Feb 2013 10:00:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:00:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:00:49 +0000
Message-Id: <511A20DA02000078000BDA69@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:00:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
In-Reply-To: <e80418f1f58bf36fe953.1360596482@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: __devinit was removed
 in linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:28, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1360595055 -3600
> # Node ID e80418f1f58bf36fe953af587cc0e6dbd52dffa7
> # Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
> unmodified_drivers: __devinit was removed in linux-3.8

I recognize the need for dealing with this, but ...

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 2fdca30363f0 -r e80418f1f58b 
> unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h

... this is the wrong file. See compat-include/xen/platform-compat.h
(including how it already deals with non-present __init).

Jan

> @@ -24,6 +24,11 @@
>  
>  #include <linux/pci.h>
>  
> +#ifndef __devinit
> +#define __devinit
> +#define __devinitdata
> +#endif
> +
>  unsigned long alloc_xen_mmio(unsigned long len);
>  void platform_pci_resume(void);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 12 10:07:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10: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 1U5ClO-0007PH-SZ; Tue, 12 Feb 2013 10:06:58 +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 1U5ClN-0007P9-Rm
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:06:57 +0000
Received: from [85.158.137.99:37296] by server-9.bemta-3.messagelabs.com id
	A8/65-09484-1441A115; Tue, 12 Feb 2013 10:06:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360663615!18730970!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30710 invoked from network); 12 Feb 2013 10:06:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:06:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:06:57 +0000
Message-Id: <511A224A02000078000BDA7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:06:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
In-Reply-To: <CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 07:26, povder <povder@gmail.com> wrote:
> 2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>>
>> Try adding "iommu=debug" option --- it will print more information including
>> dump of the ACPI table that describes IOMMU.
>>
> 
> Thanks for a quick reply.
> Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c 

There's no boot failure in that log, so please clarify what this was
generated from.

Also, sadly, the debug output isn't really helpful, which is why
the patch that supposedly fixes your boot problem also adjusts
what gets printed here (for the unlikely case that your problem
persists with that patch:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:07:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10: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 1U5ClO-0007PH-SZ; Tue, 12 Feb 2013 10:06:58 +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 1U5ClN-0007P9-Rm
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:06:57 +0000
Received: from [85.158.137.99:37296] by server-9.bemta-3.messagelabs.com id
	A8/65-09484-1441A115; Tue, 12 Feb 2013 10:06:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360663615!18730970!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30710 invoked from network); 12 Feb 2013 10:06:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:06:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:06:57 +0000
Message-Id: <511A224A02000078000BDA7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:06:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
In-Reply-To: <CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 07:26, povder <povder@gmail.com> wrote:
> 2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>>
>> Try adding "iommu=debug" option --- it will print more information including
>> dump of the ACPI table that describes IOMMU.
>>
> 
> Thanks for a quick reply.
> Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c 

There's no boot failure in that log, so please clarify what this was
generated from.

Also, sadly, the debug output isn't really helpful, which is why
the patch that supposedly fixes your boot problem also adjusts
what gets printed here (for the unlikely case that your problem
persists with that patch:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:10:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10: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 1U5CoN-0007d5-Fj; Tue, 12 Feb 2013 10:10:03 +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 1U5CoM-0007cw-7Y
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:10:02 +0000
Received: from [193.109.254.147:56358] by server-13.bemta-14.messagelabs.com
	id 64/05-30639-9F41A115; Tue, 12 Feb 2013 10:10:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1360663800!7616429!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17022 invoked from network); 12 Feb 2013 10:10:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 10:10:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGii0PF2o=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-084-014.pools.arcor-ip.net [88.65.84.14])
	by smtp.strato.de (joses mo36) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x04285p1C9R3Di
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 11:09:59 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E40A21863D
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 11:09:58 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 37bca0abac676afdece18363ba3170027378659c
Message-Id: <37bca0abac676afdece1.1360663796@probook.site>
In-Reply-To: <e80418f1f58bf36fe953.1360596482@probook.site>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Tue, 12 Feb 2013 11:09:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] unmodified_drivers: __devinit was removed in
	linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360663714 -3600
# Node ID 37bca0abac676afdece18363ba3170027378659c
# Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
unmodified_drivers: __devinit was removed in linux-3.8

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2fdca30363f0 -r 37bca0abac67 unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
--- a/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
+++ b/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
@@ -171,4 +171,9 @@ typedef irqreturn_t (*irq_handler_t)(int
 #define synch_test_bit			sync_test_bit
 #endif
 
+#ifndef __devinit
+#define __devinit
+#define __devinitdata
 #endif
+
+#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:10:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10: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 1U5CoN-0007d5-Fj; Tue, 12 Feb 2013 10:10:03 +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 1U5CoM-0007cw-7Y
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:10:02 +0000
Received: from [193.109.254.147:56358] by server-13.bemta-14.messagelabs.com
	id 64/05-30639-9F41A115; Tue, 12 Feb 2013 10:10:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1360663800!7616429!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17022 invoked from network); 12 Feb 2013 10:10:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 10:10:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGii0PF2o=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-084-014.pools.arcor-ip.net [88.65.84.14])
	by smtp.strato.de (joses mo36) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x04285p1C9R3Di
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 11:09:59 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E40A21863D
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 11:09:58 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 37bca0abac676afdece18363ba3170027378659c
Message-Id: <37bca0abac676afdece1.1360663796@probook.site>
In-Reply-To: <e80418f1f58bf36fe953.1360596482@probook.site>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Tue, 12 Feb 2013 11:09:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] unmodified_drivers: __devinit was removed in
	linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360663714 -3600
# Node ID 37bca0abac676afdece18363ba3170027378659c
# Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
unmodified_drivers: __devinit was removed in linux-3.8

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2fdca30363f0 -r 37bca0abac67 unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
--- a/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
+++ b/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
@@ -171,4 +171,9 @@ typedef irqreturn_t (*irq_handler_t)(int
 #define synch_test_bit			sync_test_bit
 #endif
 
+#ifndef __devinit
+#define __devinit
+#define __devinitdata
 #endif
+
+#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:11:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:11: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 1U5CpB-0007hj-Uq; Tue, 12 Feb 2013 10:10:53 +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 1U5CpA-0007hU-MF
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:10:52 +0000
Received: from [85.158.137.99:63683] by server-11.bemta-3.messagelabs.com id
	D1/1A-10249-B251A115; Tue, 12 Feb 2013 10:10:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360663827!17633597!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15503 invoked from network); 12 Feb 2013 10:10:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:10:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGii0PF2o=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-084-014.pools.arcor-ip.net [88.65.84.14])
	by smtp.strato.de (josoe mo50) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z024bap1C93Oyv ;
	Tue, 12 Feb 2013 11:10:20 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 390431884C; Tue, 12 Feb 2013 11:10:19 +0100 (CET)
Date: Tue, 12 Feb 2013 11:10:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130212101019.GA26182@aepfle.de>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
	<511A20DA02000078000BDA69@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511A20DA02000078000BDA69@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: __devinit was removed
 in linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 12, Jan Beulich wrote:

> >>> On 11.02.13 at 16:28, Olaf Hering <olaf@aepfle.de> wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1360595055 -3600
> > # Node ID e80418f1f58bf36fe953af587cc0e6dbd52dffa7
> > # Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
> > unmodified_drivers: __devinit was removed in linux-3.8
> 
> I recognize the need for dealing with this, but ...
> 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > diff -r 2fdca30363f0 -r e80418f1f58b 
> > unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> > --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> > +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> 
> ... this is the wrong file. See compat-include/xen/platform-compat.h
> (including how it already deals with non-present __init).

Thanks, I sent v2 of this patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:11:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:11: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 1U5CpB-0007hj-Uq; Tue, 12 Feb 2013 10:10:53 +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 1U5CpA-0007hU-MF
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:10:52 +0000
Received: from [85.158.137.99:63683] by server-11.bemta-3.messagelabs.com id
	D1/1A-10249-B251A115; Tue, 12 Feb 2013 10:10:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360663827!17633597!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjQ0Nzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15503 invoked from network); 12 Feb 2013 10:10:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:10:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGii0PF2o=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-084-014.pools.arcor-ip.net [88.65.84.14])
	by smtp.strato.de (josoe mo50) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z024bap1C93Oyv ;
	Tue, 12 Feb 2013 11:10:20 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 390431884C; Tue, 12 Feb 2013 11:10:19 +0100 (CET)
Date: Tue, 12 Feb 2013 11:10:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130212101019.GA26182@aepfle.de>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
	<511A20DA02000078000BDA69@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511A20DA02000078000BDA69@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] unmodified_drivers: __devinit was removed
 in linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 12, Jan Beulich wrote:

> >>> On 11.02.13 at 16:28, Olaf Hering <olaf@aepfle.de> wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1360595055 -3600
> > # Node ID e80418f1f58bf36fe953af587cc0e6dbd52dffa7
> > # Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
> > unmodified_drivers: __devinit was removed in linux-3.8
> 
> I recognize the need for dealing with this, but ...
> 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > diff -r 2fdca30363f0 -r e80418f1f58b 
> > unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> > --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> > +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.h
> 
> ... this is the wrong file. See compat-include/xen/platform-compat.h
> (including how it already deals with non-present __init).

Thanks, I sent v2 of this patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:12:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:12: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 1U5CqJ-0007rG-Et; Tue, 12 Feb 2013 10:12:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U5CqH-0007qy-Gi
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:12:01 +0000
Received: from [85.158.139.211:27413] by server-7.bemta-5.messagelabs.com id
	50/BD-11121-0751A115; Tue, 12 Feb 2013 10:12:00 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360663834!21816922!1
X-Originating-IP: [209.85.214.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5565 invoked from network); 12 Feb 2013 10:10:36 -0000
Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com)
	(209.85.214.169)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:10:36 -0000
Received: by mail-ob0-f169.google.com with SMTP id ta14so127086obb.14
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 02:10:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=EjsqnwAHqwffwIGXIZYaS/oWEYL7crucqjBBFQbavt4=;
	b=Eao7RxEFql7arHBolT+YCNOrz8j2AN2vmOsKuX3vFkMhLp7XDmcKdSqTO1TbY0FbTc
	8Z3baAYb8MGx8h6RZKV6G73vjBX4NrQXgcpx8qj8umKQX5TbWBZYdgC/O48H2sUL6uZm
	6P/MM4SFpeFPgJRfT/Otw/LttTN42DkeLgOt4spL1xatJ2hOVYMDSkhIu9hkzCdYX08f
	i+fLXhsBoAa4HPX9sQS5+POBuGR3ZMha29fQEWzOjiGWUHbFsmapv3ZC0SSiYqmqVnDs
	PbtRPJ22TawqlHNTwtfjm1Y0nmQdhWg4KUOW/t0npwMDthitFYbKULWEukl6qx/r9VMI
	iq6A==
MIME-Version: 1.0
X-Received: by 10.60.20.35 with SMTP id k3mr12929961oee.119.1360663834041;
	Tue, 12 Feb 2013 02:10:34 -0800 (PST)
Received: by 10.60.146.228 with HTTP; Tue, 12 Feb 2013 02:10:33 -0800 (PST)
In-Reply-To: <1360657733.18663.1.camel@dagon.hellion.org.uk>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
	<CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
	<1360657733.18663.1.camel@dagon.hellion.org.uk>
Date: Tue, 12 Feb 2013 05:10:33 -0500
Message-ID: <CAGj-7pU8mTrA0CzFFAqr5TsptijrkWz3u2FS-tz56wq_aamzaA@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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

>> BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
>> configure of stubdom be called?
>
> My intention was that --(enable|disable)-stubdom would always override
> arch_enable_stubdom, so yes it should be called.
>
Thanks, then can you please review the changes I submitted against
m4/subsystem.m4 because otherwise even if with "--enable-stubdom", the
stubdom/configure is not being called.

Shakeel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:12:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:12: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 1U5CqJ-0007rG-Et; Tue, 12 Feb 2013 10:12:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shakeel.butt@gmail.com>) id 1U5CqH-0007qy-Gi
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:12:01 +0000
Received: from [85.158.139.211:27413] by server-7.bemta-5.messagelabs.com id
	50/BD-11121-0751A115; Tue, 12 Feb 2013 10:12:00 +0000
X-Env-Sender: shakeel.butt@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360663834!21816922!1
X-Originating-IP: [209.85.214.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5565 invoked from network); 12 Feb 2013 10:10:36 -0000
Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com)
	(209.85.214.169)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:10:36 -0000
Received: by mail-ob0-f169.google.com with SMTP id ta14so127086obb.14
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 02:10:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=EjsqnwAHqwffwIGXIZYaS/oWEYL7crucqjBBFQbavt4=;
	b=Eao7RxEFql7arHBolT+YCNOrz8j2AN2vmOsKuX3vFkMhLp7XDmcKdSqTO1TbY0FbTc
	8Z3baAYb8MGx8h6RZKV6G73vjBX4NrQXgcpx8qj8umKQX5TbWBZYdgC/O48H2sUL6uZm
	6P/MM4SFpeFPgJRfT/Otw/LttTN42DkeLgOt4spL1xatJ2hOVYMDSkhIu9hkzCdYX08f
	i+fLXhsBoAa4HPX9sQS5+POBuGR3ZMha29fQEWzOjiGWUHbFsmapv3ZC0SSiYqmqVnDs
	PbtRPJ22TawqlHNTwtfjm1Y0nmQdhWg4KUOW/t0npwMDthitFYbKULWEukl6qx/r9VMI
	iq6A==
MIME-Version: 1.0
X-Received: by 10.60.20.35 with SMTP id k3mr12929961oee.119.1360663834041;
	Tue, 12 Feb 2013 02:10:34 -0800 (PST)
Received: by 10.60.146.228 with HTTP; Tue, 12 Feb 2013 02:10:33 -0800 (PST)
In-Reply-To: <1360657733.18663.1.camel@dagon.hellion.org.uk>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
	<CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
	<1360657733.18663.1.camel@dagon.hellion.org.uk>
Date: Tue, 12 Feb 2013 05:10:33 -0500
Message-ID: <CAGj-7pU8mTrA0CzFFAqr5TsptijrkWz3u2FS-tz56wq_aamzaA@mail.gmail.com>
From: Shakeel Butt <shakeel.butt@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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

>> BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
>> configure of stubdom be called?
>
> My intention was that --(enable|disable)-stubdom would always override
> arch_enable_stubdom, so yes it should be called.
>
Thanks, then can you please review the changes I submitted against
m4/subsystem.m4 because otherwise even if with "--enable-stubdom", the
stubdom/configure is not being called.

Shakeel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:14:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:14: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 1U5CsS-00085r-5M; Tue, 12 Feb 2013 10:14:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipecaml@gmail.com>) id 1U57Dp-0002i7-LS
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 04:11:57 +0000
Received: from [85.158.143.99:59076] by server-3.bemta-4.messagelabs.com id
	A3/EC-08920-C01C9115; Tue, 12 Feb 2013 04:11:56 +0000
X-Env-Sender: tipecaml@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360642314!24227604!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4174 invoked from network); 12 Feb 2013 04:11:55 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 04:11:55 -0000
Received: by mail-wg0-f50.google.com with SMTP id es5so5331293wgb.5
	for <xen-devel@lists.xensource.com>;
	Mon, 11 Feb 2013 20:11:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=Mmulp5WQAhoxSTmeR89TWb8mVWFUTZAbR3MrPkR+SYo=;
	b=ec1uaP3vl/C/TKV+Tf7LWQoVA6stzQmBaIHLlPq0y9BBYzNNrNa7MaKCrNP61vqCCL
	ljve5QBtNfVOcl/cKEdMZU1Bl7ty5AHItz/VW+4QKiosVBZwizBIHItDwa7wY/4I12Wl
	dTG3RP3CoGu2atkaE/QwW92UeNrRbyc8RSnAIfvAKVT4zi0rS/qwwxpCGiw7zhj/u8Bb
	bcrlfhJLkIvrcPc/frMIsHfH1aSLjLURGM3Hvpl5oIhimczLchLMGWITciNspqCNN0R7
	mjET5pqeTP96gg5inOd67TzSJ5FkcWoz5IM1wNUXEHRecc4G2E27RPG4AHcIE2R7vfqt
	UtzQ==
X-Received: by 10.180.84.199 with SMTP id b7mr400832wiz.22.1360642314629;
	Mon, 11 Feb 2013 20:11:54 -0800 (PST)
Received: from localhost.localdomain (tal33-3-82-233-82-24.fbx.proxad.net.
	[82.233.82.24])
	by mx.google.com with ESMTPS id ex1sm37168008wib.7.2013.02.11.20.11.52
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 11 Feb 2013 20:11:53 -0800 (PST)
From: Cyril Roelandt <tipecaml@gmail.com>
To: linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Date: Tue, 12 Feb 2013 05:01:53 +0100
Message-Id: <1360641713-24895-6-git-send-email-tipecaml@gmail.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360641713-24895-1-git-send-email-tipecaml@gmail.com>
References: <1360641713-24895-1-git-send-email-tipecaml@gmail.com>
X-Mailman-Approved-At: Tue, 12 Feb 2013 10:14:14 +0000
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Cyril Roelandt <tipecaml@gmail.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 5/5] xen: remove redundant NULL check before
	unregister_and_remove_pcpu().
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.

Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
---
 drivers/xen/pcpu.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 067fcfa..5a27a45 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -278,8 +278,7 @@ static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu)
 	 * Only those at cpu present map has its sys interface.
 	 */
 	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
-		if (pcpu)
-			unregister_and_remove_pcpu(pcpu);
+		unregister_and_remove_pcpu(pcpu);
 		return 0;
 	}
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:14:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:14: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 1U5CsS-00085r-5M; Tue, 12 Feb 2013 10:14:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipecaml@gmail.com>) id 1U57Dp-0002i7-LS
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 04:11:57 +0000
Received: from [85.158.143.99:59076] by server-3.bemta-4.messagelabs.com id
	A3/EC-08920-C01C9115; Tue, 12 Feb 2013 04:11:56 +0000
X-Env-Sender: tipecaml@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360642314!24227604!1
X-Originating-IP: [74.125.82.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4174 invoked from network); 12 Feb 2013 04:11:55 -0000
Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com)
	(74.125.82.50)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 04:11:55 -0000
Received: by mail-wg0-f50.google.com with SMTP id es5so5331293wgb.5
	for <xen-devel@lists.xensource.com>;
	Mon, 11 Feb 2013 20:11:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:from:to:cc:subject:date:message-id:x-mailer:in-reply-to
	:references; bh=Mmulp5WQAhoxSTmeR89TWb8mVWFUTZAbR3MrPkR+SYo=;
	b=ec1uaP3vl/C/TKV+Tf7LWQoVA6stzQmBaIHLlPq0y9BBYzNNrNa7MaKCrNP61vqCCL
	ljve5QBtNfVOcl/cKEdMZU1Bl7ty5AHItz/VW+4QKiosVBZwizBIHItDwa7wY/4I12Wl
	dTG3RP3CoGu2atkaE/QwW92UeNrRbyc8RSnAIfvAKVT4zi0rS/qwwxpCGiw7zhj/u8Bb
	bcrlfhJLkIvrcPc/frMIsHfH1aSLjLURGM3Hvpl5oIhimczLchLMGWITciNspqCNN0R7
	mjET5pqeTP96gg5inOd67TzSJ5FkcWoz5IM1wNUXEHRecc4G2E27RPG4AHcIE2R7vfqt
	UtzQ==
X-Received: by 10.180.84.199 with SMTP id b7mr400832wiz.22.1360642314629;
	Mon, 11 Feb 2013 20:11:54 -0800 (PST)
Received: from localhost.localdomain (tal33-3-82-233-82-24.fbx.proxad.net.
	[82.233.82.24])
	by mx.google.com with ESMTPS id ex1sm37168008wib.7.2013.02.11.20.11.52
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 11 Feb 2013 20:11:53 -0800 (PST)
From: Cyril Roelandt <tipecaml@gmail.com>
To: linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Date: Tue, 12 Feb 2013 05:01:53 +0100
Message-Id: <1360641713-24895-6-git-send-email-tipecaml@gmail.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360641713-24895-1-git-send-email-tipecaml@gmail.com>
References: <1360641713-24895-1-git-send-email-tipecaml@gmail.com>
X-Mailman-Approved-At: Tue, 12 Feb 2013 10:14:14 +0000
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Cyril Roelandt <tipecaml@gmail.com>, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 5/5] xen: remove redundant NULL check before
	unregister_and_remove_pcpu().
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.

Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
---
 drivers/xen/pcpu.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 067fcfa..5a27a45 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -278,8 +278,7 @@ static int sync_pcpu(uint32_t cpu, uint32_t *max_cpu)
 	 * Only those at cpu present map has its sys interface.
 	 */
 	if (info->flags & XEN_PCPU_FLAGS_INVALID) {
-		if (pcpu)
-			unregister_and_remove_pcpu(pcpu);
+		unregister_and_remove_pcpu(pcpu);
 		return 0;
 	}
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:18:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:18: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 1U5Cw4-0008Jw-Rn; Tue, 12 Feb 2013 10:18: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 1U5Cw3-0008Jp-Ba
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:17:59 +0000
Received: from [85.158.143.35:36412] by server-2.bemta-4.messagelabs.com id
	90/25-01597-6D61A115; Tue, 12 Feb 2013 10:17:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360664262!14813823!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15152 invoked from network); 12 Feb 2013 10:17:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:17:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1365027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:17: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.297.1;
	Tue, 12 Feb 2013 10:17:42 +0000
Message-ID: <1360664260.20449.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Tue, 12 Feb 2013 10:17:40 +0000
In-Reply-To: <CAGj-7pU8mTrA0CzFFAqr5TsptijrkWz3u2FS-tz56wq_aamzaA@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
	<CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
	<1360657733.18663.1.camel@dagon.hellion.org.uk>
	<CAGj-7pU8mTrA0CzFFAqr5TsptijrkWz3u2FS-tz56wq_aamzaA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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, 2013-02-12 at 10:10 +0000, Shakeel Butt wrote:
> >> BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
> >> configure of stubdom be called?
> >
> > My intention was that --(enable|disable)-stubdom would always override
> > arch_enable_stubdom, so yes it should be called.
> >
> Thanks, then can you please review the changes I submitted against
> m4/subsystem.m4 because otherwise even if with "--enable-stubdom", the
> stubdom/configure is not being called.

Yes, it's in my queue to look at.

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 Feb 12 10:18:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:18: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 1U5Cw4-0008Jw-Rn; Tue, 12 Feb 2013 10:18: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 1U5Cw3-0008Jp-Ba
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:17:59 +0000
Received: from [85.158.143.35:36412] by server-2.bemta-4.messagelabs.com id
	90/25-01597-6D61A115; Tue, 12 Feb 2013 10:17:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360664262!14813823!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15152 invoked from network); 12 Feb 2013 10:17:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:17:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1365027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:17: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.297.1;
	Tue, 12 Feb 2013 10:17:42 +0000
Message-ID: <1360664260.20449.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Tue, 12 Feb 2013 10:17:40 +0000
In-Reply-To: <CAGj-7pU8mTrA0CzFFAqr5TsptijrkWz3u2FS-tz56wq_aamzaA@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
	<CAGj-7pXHzH9vX0LgNizjOypLpjOaP0TbGygN1u3EVWP2TXN06g@mail.gmail.com>
	<1360657733.18663.1.camel@dagon.hellion.org.uk>
	<CAGj-7pU8mTrA0CzFFAqr5TsptijrkWz3u2FS-tz56wq_aamzaA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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, 2013-02-12 at 10:10 +0000, Shakeel Butt wrote:
> >> BTW if 'arch_enable_stubdom=n' and '--enable-stubdom' should the
> >> configure of stubdom be called?
> >
> > My intention was that --(enable|disable)-stubdom would always override
> > arch_enable_stubdom, so yes it should be called.
> >
> Thanks, then can you please review the changes I submitted against
> m4/subsystem.m4 because otherwise even if with "--enable-stubdom", the
> stubdom/configure is not being called.

Yes, it's in my queue to look at.

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 Feb 12 10:32:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:32: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 1U5D9x-0000eQ-UV; Tue, 12 Feb 2013 10:32:21 +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 1U5D9w-0000eL-0s
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:32:20 +0000
Received: from [85.158.139.83:30711] by server-11.bemta-5.messagelabs.com id
	DF/A2-19159-33A1A115; Tue, 12 Feb 2013 10:32:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360665109!23901678!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12614 invoked from network); 12 Feb 2013 10:31:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:31:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:32:01 +0000
Message-Id: <511A282202000078000BDA9F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:31:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
	<37bca0abac676afdece1.1360663796@probook.site>
In-Reply-To: <37bca0abac676afdece1.1360663796@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] unmodified_drivers: __devinit was
 removed in linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:09, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1360663714 -3600
> # Node ID 37bca0abac676afdece18363ba3170027378659c
> # Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
> unmodified_drivers: __devinit was removed in linux-3.8
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Committed, but it would have been nice if you had followed the
advice I gave and thus saved me from having to edit the patch
before checking in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:32:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:32: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 1U5D9x-0000eQ-UV; Tue, 12 Feb 2013 10:32:21 +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 1U5D9w-0000eL-0s
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:32:20 +0000
Received: from [85.158.139.83:30711] by server-11.bemta-5.messagelabs.com id
	DF/A2-19159-33A1A115; Tue, 12 Feb 2013 10:32:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360665109!23901678!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12614 invoked from network); 12 Feb 2013 10:31:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:31:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:32:01 +0000
Message-Id: <511A282202000078000BDA9F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:31:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <e80418f1f58bf36fe953.1360596482@probook.site>
	<37bca0abac676afdece1.1360663796@probook.site>
In-Reply-To: <37bca0abac676afdece1.1360663796@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] unmodified_drivers: __devinit was
 removed in linux-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:09, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1360663714 -3600
> # Node ID 37bca0abac676afdece18363ba3170027378659c
> # Parent  2fdca30363f08026971c094e8a1a84e19ca3e55b
> unmodified_drivers: __devinit was removed in linux-3.8
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Committed, but it would have been nice if you had followed the
advice I gave and thus saved me from having to edit the patch
before checking in.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:33:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:33: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 1U5DAn-0000iJ-CT; Tue, 12 Feb 2013 10:33:13 +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 1U5DAm-0000i9-Ge
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:33:12 +0000
Received: from [85.158.139.83:21264] by server-2.bemta-5.messagelabs.com id
	EE/22-16911-76A1A115; Tue, 12 Feb 2013 10:33:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360665169!23901930!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19104 invoked from network); 12 Feb 2013 10:32:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:32:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:33:01 +0000
Message-Id: <511A285802000078000BDAA2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:32:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <CAFLBxZbVizXazpqgqvYNicD9nU1wv-=kMhN0X1pQXkkpqMsPUA@mail.gmail.com>
In-Reply-To: <CAFLBxZbVizXazpqgqvYNicD9nU1wv-=kMhN0X1pQXkkpqMsPUA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano@stabellini.net>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.3 Planning: Taking stock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.01.13 at 17:32, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> * Scalability: 16TiB of RAM

Done.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:33:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:33: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 1U5DAn-0000iJ-CT; Tue, 12 Feb 2013 10:33:13 +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 1U5DAm-0000i9-Ge
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:33:12 +0000
Received: from [85.158.139.83:21264] by server-2.bemta-5.messagelabs.com id
	EE/22-16911-76A1A115; Tue, 12 Feb 2013 10:33:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360665169!23901930!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19104 invoked from network); 12 Feb 2013 10:32:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 10:32:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 10:33:01 +0000
Message-Id: <511A285802000078000BDAA2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 10:32:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <CAFLBxZbVizXazpqgqvYNicD9nU1wv-=kMhN0X1pQXkkpqMsPUA@mail.gmail.com>
In-Reply-To: <CAFLBxZbVizXazpqgqvYNicD9nU1wv-=kMhN0X1pQXkkpqMsPUA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano@stabellini.net>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.3 Planning: Taking stock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.01.13 at 17:32, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> * Scalability: 16TiB of RAM

Done.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:36:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:36: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 1U5DE0-0000yG-1A; Tue, 12 Feb 2013 10:36: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 1U5DDy-0000y4-9t
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 10:36:30 +0000
Received: from [85.158.137.99:52991] by server-10.bemta-3.messagelabs.com id
	71/12-10609-D2B1A115; Tue, 12 Feb 2013 10:36:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360665388!21043046!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32150 invoked from network); 12 Feb 2013 10:36:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:36:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1365876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:36: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.297.1;
	Tue, 12 Feb 2013 10:36:12 +0000
Message-ID: <1360665371.20449.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 10:36:11 +0000
In-Reply-To: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-11 at 23:12 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-xl-multivcpu
> test guest-localmigrate/x10
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
>   Bug introduced:  fd997a96d448
>   Bug not present: ffd30e7388ad
> 
> 
>   changeset:   26523:fd997a96d448
>   tag:         tip
>   user:        Jan Beulich <jbeulich@suse.com>
>   date:        Fri Feb 08 11:06:04 2013 +0100
>       
>       x86: debugging code for testing 16Tb support on smaller memory systems
>       
>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>       Acked-by: Keir Fraser <keir@xen.org>

This is now the second bisection to finger this changeset
("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
yesterday was the other).

Perhaps it is worth investigating after 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 Feb 12 10:36:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:36: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 1U5DE0-0000yG-1A; Tue, 12 Feb 2013 10:36: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 1U5DDy-0000y4-9t
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 10:36:30 +0000
Received: from [85.158.137.99:52991] by server-10.bemta-3.messagelabs.com id
	71/12-10609-D2B1A115; Tue, 12 Feb 2013 10:36:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360665388!21043046!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32150 invoked from network); 12 Feb 2013 10:36:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:36:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1365876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:36: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.297.1;
	Tue, 12 Feb 2013 10:36:12 +0000
Message-ID: <1360665371.20449.150.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 10:36:11 +0000
In-Reply-To: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-11 at 23:12 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-xl-multivcpu
> test guest-localmigrate/x10
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
>   Bug introduced:  fd997a96d448
>   Bug not present: ffd30e7388ad
> 
> 
>   changeset:   26523:fd997a96d448
>   tag:         tip
>   user:        Jan Beulich <jbeulich@suse.com>
>   date:        Fri Feb 08 11:06:04 2013 +0100
>       
>       x86: debugging code for testing 16Tb support on smaller memory systems
>       
>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>       Acked-by: Keir Fraser <keir@xen.org>

This is now the second bisection to finger this changeset
("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
yesterday was the other).

Perhaps it is worth investigating after 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 Feb 12 10:40:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:40: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 1U5DH9-0001C4-O5; Tue, 12 Feb 2013 10:39:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U5DH7-0001Bs-M8
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:39:45 +0000
Received: from [85.158.137.99:30844] by server-12.bemta-3.messagelabs.com id
	2F/7D-05889-0FB1A115; Tue, 12 Feb 2013 10:39:44 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360665577!21081670!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4159 invoked from network); 12 Feb 2013 10:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1366021"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:39:38 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 12 Feb 2013
	10:39:37 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, James Harper
	<james.harper@bendigoit.com.au>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 12 Feb 2013 10:39:35 +0000
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4JBuabWi+7mj8+QTmwKNbZN7N9GwABfDEg
Message-ID: <291EDFCB1E9E224A99088639C4762022013F4575599C@LONPMAILBOX01.citrite.net>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
	<511A1F3D02000078000BDA51@nat28.tlf.novell.com>
In-Reply-To: <511A1F3D02000078000BDA51@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: Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 12 February 2013 09:54
> To: James Harper; George Dunlap
> Cc: Paul Durrant; Dave Scott; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
> 
> >>> On 11.02.13 at 12:40, George Dunlap <george.dunlap@eu.citrix.com>
> wrote:
> > On 11/02/13 11:39, James Harper wrote:
> >>> On Mon, Feb 11, 2013 at 12:03 AM, James Harper
> >>> <james.harper@bendigoit.com.au> wrote:
> >>>
> >>> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
> >>> using PoD. I'm using the difference between
> >>> XENMEM_maximum_reservation and XENMEM_current_reservation to
> tell
> >>> me how much I should balloon down to account for PoD, but when the
> user
> >>> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
> >>>
> >>> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
> >>> 262400
> >>> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
> >>> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
> >>>
> >>> 	What is the correct way to tell how much PoD memory there is under
> >>> 4.2? Am I doing it wrong?
> >>>
> >>> 	I balloon down as early as possible (before xenbus starts) to avoid
> >>> windows going over its limit so I'm hoping I can determine the size of
> PoD
> >>> memory just via hypercalls.
> >>>
> >>>
> >>>
> >>> You shouldn't have to know anything specifically about PoD -- you should
> just
> >>> look at the balloon target for the guest written in xenstore.  The idea
> was
> > as
> >>> much as possible for the toolstack and Xen to work together to make it
> >>> transparent to the balloon driver, in part because we expected to be
> running
> >>> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
> >>> memory.  (Paul, please correct me if I'm wrong.)
> >> So I should just balloon down to the current_reservation figure right?
> >
> > ...I don't think so -- it looks like you're getting that from a
> > hypercall, not from xenstore.  You want the normal balloon target value
> > from xenstore.  (But I might be confused -- I'm not super familiar with
> > the technical details of the ballooning codepath, just the overall
> > principles.)
> 
> As James said, this ought to run without xenbus having initialized
> (so it can be done as early as possible). Hence the need for doing
> this via hypercalls. The "classic" Xen balloon driver does so too, btw.
> 

We just use xenbus in the Citrix PV drivers and rely on the zero page sweep code in Xen to prevent a memory scrub from crashing the domain.

One problem with Windows can be SKU memory limits i.e. the OS cannot actually allocate from all the memory that is given to the domain so the target cannot necessarily be met.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:40:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:40: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 1U5DH9-0001C4-O5; Tue, 12 Feb 2013 10:39:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U5DH7-0001Bs-M8
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:39:45 +0000
Received: from [85.158.137.99:30844] by server-12.bemta-3.messagelabs.com id
	2F/7D-05889-0FB1A115; Tue, 12 Feb 2013 10:39:44 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360665577!21081670!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4159 invoked from network); 12 Feb 2013 10:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1366021"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:39:38 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 12 Feb 2013
	10:39:37 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, James Harper
	<james.harper@bendigoit.com.au>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 12 Feb 2013 10:39:35 +0000
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4JBuabWi+7mj8+QTmwKNbZN7N9GwABfDEg
Message-ID: <291EDFCB1E9E224A99088639C4762022013F4575599C@LONPMAILBOX01.citrite.net>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
	<511A1F3D02000078000BDA51@nat28.tlf.novell.com>
In-Reply-To: <511A1F3D02000078000BDA51@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: Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: 12 February 2013 09:54
> To: James Harper; George Dunlap
> Cc: Paul Durrant; Dave Scott; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
> 
> >>> On 11.02.13 at 12:40, George Dunlap <george.dunlap@eu.citrix.com>
> wrote:
> > On 11/02/13 11:39, James Harper wrote:
> >>> On Mon, Feb 11, 2013 at 12:03 AM, James Harper
> >>> <james.harper@bendigoit.com.au> wrote:
> >>>
> >>> 	A user has pointed out a problem with GPLPV under Xen 4.2 when
> >>> using PoD. I'm using the difference between
> >>> XENMEM_maximum_reservation and XENMEM_current_reservation to
> tell
> >>> me how much I should balloon down to account for PoD, but when the
> user
> >>> has ballooned down to 1G (from 4Gb or 8GB), GPLPV logs the following:
> >>>
> >>> 	13005008825593: XenPCI     XENMEM_maximum_reservation =
> >>> 262400
> >>> 	13005008825593: XenPCI     XENMEM_current_reservation = 262136
> >>> 	13005008825609: XenPCI     Trying to give 1056 KB (1 MB) to Xen
> >>>
> >>> 	What is the correct way to tell how much PoD memory there is under
> >>> 4.2? Am I doing it wrong?
> >>>
> >>> 	I balloon down as early as possible (before xenbus starts) to avoid
> >>> windows going over its limit so I'm hoping I can determine the size of
> PoD
> >>> memory just via hypercalls.
> >>>
> >>>
> >>>
> >>> You shouldn't have to know anything specifically about PoD -- you should
> just
> >>> look at the balloon target for the guest written in xenstore.  The idea
> was
> > as
> >>> much as possible for the toolstack and Xen to work together to make it
> >>> transparent to the balloon driver, in part because we expected to be
> running
> >>> legacy drivers.  The Citrix PV drivers don't do anything special wrt PoD
> >>> memory.  (Paul, please correct me if I'm wrong.)
> >> So I should just balloon down to the current_reservation figure right?
> >
> > ...I don't think so -- it looks like you're getting that from a
> > hypercall, not from xenstore.  You want the normal balloon target value
> > from xenstore.  (But I might be confused -- I'm not super familiar with
> > the technical details of the ballooning codepath, just the overall
> > principles.)
> 
> As James said, this ought to run without xenbus having initialized
> (so it can be done as early as possible). Hence the need for doing
> this via hypercalls. The "classic" Xen balloon driver does so too, btw.
> 

We just use xenbus in the Citrix PV drivers and rely on the zero page sweep code in Xen to prevent a memory scrub from crashing the domain.

One problem with Windows can be SKU memory limits i.e. the OS cannot actually allocate from all the memory that is given to the domain so the target cannot necessarily be met.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:45:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:45: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 1U5DMG-0001Nv-Jp; Tue, 12 Feb 2013 10:45:04 +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 1U5DMF-0001No-Dp
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:45:03 +0000
Received: from [85.158.139.83:8447] by server-13.bemta-5.messagelabs.com id
	58/31-06769-E2D1A115; Tue, 12 Feb 2013 10:45:02 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360665898!29516472!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6795 invoked from network); 12 Feb 2013 10:45:01 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 10:45:01 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5DLy-0008CX-59; Tue, 12 Feb 2013 21:44:46 +1100
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 id
	14.01.0438.000; Tue, 12 Feb 2013 21:44:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgAAAdQUAABfjY9D//0hNgIABdKaAgAAMyoD//0dUwA==
Date: Tue, 12 Feb 2013 10:44:45 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3566C4B5@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
	<511A1F3D02000078000BDA51@nat28.tlf.novell.com>
	<291EDFCB1E9E224A99088639C4762022013F4575599C@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F4575599C@LONPMAILBOX01.citrite.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19632.002
x-tm-as-result: No--41.505300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 James said, this ought to run without xenbus having initialized
> > (so it can be done as early as possible). Hence the need for doing
> > this via hypercalls. The "classic" Xen balloon driver does so too, btw.
> >
> 
> We just use xenbus in the Citrix PV drivers and rely on the zero page sweep
> code in Xen to prevent a memory scrub from crashing the domain.
> 

I was using the difference between current_reservation and maximum_reservation but maximum_reservation doesn't appear to return the value in 4.2 that it did in 4.1 (based on one user report). current_reservation still appears to though so as long as I figure out how much physical memory is in the system (harder than it seems but a requirement even if you are using xenbus) I should be back in business.

> One problem with Windows can be SKU memory limits i.e. the OS cannot
> actually allocate from all the memory that is given to the domain so the target
> cannot necessarily be met.
> 

Like giving memory=2GB, maxmem=6GB to an XP32 system and wondering why things don't work? I guess that's a case of don't do that :)

Windows has too many secrets.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:45:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:45: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 1U5DMG-0001Nv-Jp; Tue, 12 Feb 2013 10:45:04 +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 1U5DMF-0001No-Dp
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:45:03 +0000
Received: from [85.158.139.83:8447] by server-13.bemta-5.messagelabs.com id
	58/31-06769-E2D1A115; Tue, 12 Feb 2013 10:45:02 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360665898!29516472!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6795 invoked from network); 12 Feb 2013 10:45:01 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 10:45:01 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5DLy-0008CX-59; Tue, 12 Feb 2013 21:44:46 +1100
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 id
	14.01.0438.000; Tue, 12 Feb 2013 21:44:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Thread-Topic: [Xen-devel] PoD, 4.2, and current/maximum reservation
Thread-Index: Ac4H6swD3JGQERAlREGi/33A8IBUgAAAdQUAABfjY9D//0hNgIABdKaAgAAMyoD//0dUwA==
Date: Tue, 12 Feb 2013 10:44:45 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3566C4B5@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B356654A4@BITCOM1.int.sbss.com.au>
	<CAFLBxZa+gB6PJ0f59ifNCgJdSXKYdhwrXAipu8s1on--MrLm0w@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B356666F4@BITCOM1.int.sbss.com.au>
	<5118D893.7020102@eu.citrix.com>
	<511A1F3D02000078000BDA51@nat28.tlf.novell.com>
	<291EDFCB1E9E224A99088639C4762022013F4575599C@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F4575599C@LONPMAILBOX01.citrite.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19632.002
x-tm-as-result: No--41.505300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Dave Scott <Dave.Scott@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] PoD, 4.2, and current/maximum reservation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 James said, this ought to run without xenbus having initialized
> > (so it can be done as early as possible). Hence the need for doing
> > this via hypercalls. The "classic" Xen balloon driver does so too, btw.
> >
> 
> We just use xenbus in the Citrix PV drivers and rely on the zero page sweep
> code in Xen to prevent a memory scrub from crashing the domain.
> 

I was using the difference between current_reservation and maximum_reservation but maximum_reservation doesn't appear to return the value in 4.2 that it did in 4.1 (based on one user report). current_reservation still appears to though so as long as I figure out how much physical memory is in the system (harder than it seems but a requirement even if you are using xenbus) I should be back in business.

> One problem with Windows can be SKU memory limits i.e. the OS cannot
> actually allocate from all the memory that is given to the domain so the target
> cannot necessarily be met.
> 

Like giving memory=2GB, maxmem=6GB to an XP32 system and wondering why things don't work? I guess that's a case of don't do that :)

Windows has too many secrets.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:48: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 1U5DPP-0001W5-8v; Tue, 12 Feb 2013 10:48: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 1U5DPN-0001Vy-S5
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 10:48:18 +0000
Received: from [85.158.139.83:58804] by server-6.bemta-5.messagelabs.com id
	7A/13-01489-1FD1A115; Tue, 12 Feb 2013 10:48:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360666095!23904567!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26868 invoked from network); 12 Feb 2013 10:48:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:48:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1366359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:47: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.297.1; Tue, 12 Feb 2013 10:47:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5DOM-0006i9-V3; Tue, 12 Feb 2013 10:47:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5DOM-00047Q-1O;
	Tue, 12 Feb 2013 10:47:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.7601.238158.739689@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 10:47:13 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360665371.20449.150.camel@zakaz.uk.xensource.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
	<1360665371.20449.150.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>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-unstable bisection] complete test-amd64-i386-xl-multivcpu"):
> On Mon, 2013-02-11 at 23:12 +0000, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-xl-multivcpu
> > test guest-localmigrate/x10
...
> This is now the second bisection to finger this changeset
> ("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
> yesterday was the other).
> 
> Perhaps it is worth investigating after all?

Looking at the tested revision graph:

http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.guest-localmigrate--x10.html

I can see three passes of ffd30e and nine fails of fd997a.  So I do
think there is something wrong with this changeset.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10:48: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 1U5DPP-0001W5-8v; Tue, 12 Feb 2013 10:48: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 1U5DPN-0001Vy-S5
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 10:48:18 +0000
Received: from [85.158.139.83:58804] by server-6.bemta-5.messagelabs.com id
	7A/13-01489-1FD1A115; Tue, 12 Feb 2013 10:48:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360666095!23904567!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26868 invoked from network); 12 Feb 2013 10:48:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:48:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; 
   d="scan'208";a="1366359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 10:47: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.297.1; Tue, 12 Feb 2013 10:47:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5DOM-0006i9-V3; Tue, 12 Feb 2013 10:47:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5DOM-00047Q-1O;
	Tue, 12 Feb 2013 10:47:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.7601.238158.739689@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 10:47:13 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360665371.20449.150.camel@zakaz.uk.xensource.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
	<1360665371.20449.150.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>, "Keir
	\(Xen.org\)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-unstable bisection] complete test-amd64-i386-xl-multivcpu"):
> On Mon, 2013-02-11 at 23:12 +0000, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-xl-multivcpu
> > test guest-localmigrate/x10
...
> This is now the second bisection to finger this changeset
> ("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
> yesterday was the other).
> 
> Perhaps it is worth investigating after all?

Looking at the tested revision graph:

http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.guest-localmigrate--x10.html

I can see three passes of ffd30e and nine fails of fd997a.  So I do
think there is something wrong with this changeset.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:56:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10: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 1U5DWl-0001uf-4M; Tue, 12 Feb 2013 10:55:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5DWj-0001uR-Ii
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:55:53 +0000
Received: from [85.158.139.211:56903] by server-7.bemta-5.messagelabs.com id
	76/F0-11121-8BF1A115; Tue, 12 Feb 2013 10:55:52 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360666550!19340105!1
X-Originating-IP: [209.85.220.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24854 invoked from network); 12 Feb 2013 10:55:51 -0000
Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com)
	(209.85.220.182)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:55:51 -0000
Received: by mail-vc0-f182.google.com with SMTP id fl17so4481255vcb.13
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 02:55:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=Cq9bS7Vvxh4x3HdvE4KvF9VuQgPn7ObhzGkLg3El+SI=;
	b=HHzJHmRPTQ9KRv5xjs8iME2twb2FbofBqI0IvlFL3SxZsuslIQR976W7F96XNeRh8J
	wYdEiZ50ZZLpu7siLqLVDAKGnH5dqECvwvhkSL9SAHlayUgEBA7Id5IuJAzu4tdn8n7l
	ieXLv3PQ4CS8WJIeMnvINoiPJEPhtmU4/8UKYKDQzDuGZw4lL5DjyzwPqJoLw/PeP4Y4
	Ize1P3cAJTOE0i9drxHiVIEnp5vdnp41u6Af3mTa6GQjLfV9L4fyv4/dsULymfTtHE6B
	VMLIQj75DMtrHaa9Uc+USDyg6zUDDbX/rskg3FnAZX2W5aezvlBvz+daCBRAxEhblNYC
	VWMA==
X-Received: by 10.58.46.203 with SMTP id x11mr22866429vem.8.1360666550323;
	Tue, 12 Feb 2013 02:55:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Tue, 12 Feb 2013 02:55:30 -0800 (PST)
In-Reply-To: <511A224A02000078000BDA7B@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 11:55:30 +0100
Message-ID: <CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
>> On 12.02.13 at 07:26, povder <povder@gmail.com> wrote:
>> Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c
>
> There's no boot failure in that log, so please clarify what this was
> generated from.
>

I don't know if I understood you well but for me this log contains a
boot failure.
Maybe I misunderstand the term "boot failure" but for me (non-native
english speaker)
when a machine cannot start I understand it as a "boot failure".
This log is a full serial output of start process of my machine
which ends up with a failure so in my opinion it contains a boot
failure - correct me
if I'm wrong.

> Also, sadly, the debug output isn't really helpful, which is why
> the patch that supposedly fixes your boot problem also adjusts
> what gets printed here (for the unlikely case that your problem
> persists with that patch:
> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html).
>

So to ensure myself: I should apply a path from
http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html
and that should resolve my problem? Or maybe is there is a planned release
of next Xen version that will already contain this patch? If a release
is planned
to be in near future I would prefer to wait for it rather than apply the patch
myself and compile Xen from sources.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 10:56:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 10: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 1U5DWl-0001uf-4M; Tue, 12 Feb 2013 10:55:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5DWj-0001uR-Ii
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 10:55:53 +0000
Received: from [85.158.139.211:56903] by server-7.bemta-5.messagelabs.com id
	76/F0-11121-8BF1A115; Tue, 12 Feb 2013 10:55:52 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360666550!19340105!1
X-Originating-IP: [209.85.220.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24854 invoked from network); 12 Feb 2013 10:55:51 -0000
Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com)
	(209.85.220.182)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 10:55:51 -0000
Received: by mail-vc0-f182.google.com with SMTP id fl17so4481255vcb.13
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 02:55:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=Cq9bS7Vvxh4x3HdvE4KvF9VuQgPn7ObhzGkLg3El+SI=;
	b=HHzJHmRPTQ9KRv5xjs8iME2twb2FbofBqI0IvlFL3SxZsuslIQR976W7F96XNeRh8J
	wYdEiZ50ZZLpu7siLqLVDAKGnH5dqECvwvhkSL9SAHlayUgEBA7Id5IuJAzu4tdn8n7l
	ieXLv3PQ4CS8WJIeMnvINoiPJEPhtmU4/8UKYKDQzDuGZw4lL5DjyzwPqJoLw/PeP4Y4
	Ize1P3cAJTOE0i9drxHiVIEnp5vdnp41u6Af3mTa6GQjLfV9L4fyv4/dsULymfTtHE6B
	VMLIQj75DMtrHaa9Uc+USDyg6zUDDbX/rskg3FnAZX2W5aezvlBvz+daCBRAxEhblNYC
	VWMA==
X-Received: by 10.58.46.203 with SMTP id x11mr22866429vem.8.1360666550323;
	Tue, 12 Feb 2013 02:55:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Tue, 12 Feb 2013 02:55:30 -0800 (PST)
In-Reply-To: <511A224A02000078000BDA7B@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 11:55:30 +0100
Message-ID: <CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
>> On 12.02.13 at 07:26, povder <povder@gmail.com> wrote:
>> Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c
>
> There's no boot failure in that log, so please clarify what this was
> generated from.
>

I don't know if I understood you well but for me this log contains a
boot failure.
Maybe I misunderstand the term "boot failure" but for me (non-native
english speaker)
when a machine cannot start I understand it as a "boot failure".
This log is a full serial output of start process of my machine
which ends up with a failure so in my opinion it contains a boot
failure - correct me
if I'm wrong.

> Also, sadly, the debug output isn't really helpful, which is why
> the patch that supposedly fixes your boot problem also adjusts
> what gets printed here (for the unlikely case that your problem
> persists with that patch:
> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html).
>

So to ensure myself: I should apply a path from
http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html
and that should resolve my problem? Or maybe is there is a planned release
of next Xen version that will already contain this patch? If a release
is planned
to be in near future I would prefer to wait for it rather than apply the patch
myself and compile Xen from sources.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:05:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:05: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 1U5DfP-0002F4-5e; Tue, 12 Feb 2013 11:04:51 +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 1U5DfN-0002Ex-QH
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:04:49 +0000
Received: from [85.158.143.35:4024] by server-3.bemta-4.messagelabs.com id
	15/45-08920-1D12A115; Tue, 12 Feb 2013 11:04:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360667033!14819942!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20043 invoked from network); 12 Feb 2013 11:03: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; 12 Feb 2013 11:03:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:05:20 +0000
Message-Id: <511A2FA402000078000BDAF7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:03:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
In-Reply-To: <CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 11:55, povder <povder@gmail.com> wrote:
> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>> On 12.02.13 at 07:26, povder <povder@gmail.com> wrote:
>>> Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c 
>>
>> There's no boot failure in that log, so please clarify what this was
>> generated from.
>>
> 
> I don't know if I understood you well but for me this log contains a
> boot failure.
> Maybe I misunderstand the term "boot failure" but for me (non-native
> english speaker)
> when a machine cannot start I understand it as a "boot failure".
> This log is a full serial output of start process of my machine
> which ends up with a failure so in my opinion it contains a boot
> failure - correct me
> if I'm wrong.

Oh, I'm sorry, I didn't look through all the way to the end of the
log, as I expected the crash to happen before Dom0 even starts.

>> Also, sadly, the debug output isn't really helpful, which is why
>> the patch that supposedly fixes your boot problem also adjusts
>> what gets printed here (for the unlikely case that your problem
>> persists with that patch:
>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html).
>>
> 
> So to ensure myself: I should apply a path from
> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html 
> and that should resolve my problem? Or maybe is there is a planned release
> of next Xen version that will already contain this patch? If a release
> is planned
> to be in near future I would prefer to wait for it rather than apply the 
> patch
> myself and compile Xen from sources.

With the above, the patch is unlikely to address your problem,
but will likely provide better debugging output. So please
nevertheless try building with that patch included, assuming
the problem first started after you built Xen from a recent
4.2-testing tree (as opposed to this being plain 4.2.1, in which
case the problem is obviously unrelated to the recent changes
I'm thinking of).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:05:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:05: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 1U5DfP-0002F4-5e; Tue, 12 Feb 2013 11:04:51 +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 1U5DfN-0002Ex-QH
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:04:49 +0000
Received: from [85.158.143.35:4024] by server-3.bemta-4.messagelabs.com id
	15/45-08920-1D12A115; Tue, 12 Feb 2013 11:04:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360667033!14819942!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20043 invoked from network); 12 Feb 2013 11:03: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; 12 Feb 2013 11:03:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:05:20 +0000
Message-Id: <511A2FA402000078000BDAF7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:03:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
In-Reply-To: <CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 11:55, povder <povder@gmail.com> wrote:
> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>> On 12.02.13 at 07:26, povder <povder@gmail.com> wrote:
>>> Here is the output with iommu=debug: http://pastebin.com/raw.php?i=1wwLw82c 
>>
>> There's no boot failure in that log, so please clarify what this was
>> generated from.
>>
> 
> I don't know if I understood you well but for me this log contains a
> boot failure.
> Maybe I misunderstand the term "boot failure" but for me (non-native
> english speaker)
> when a machine cannot start I understand it as a "boot failure".
> This log is a full serial output of start process of my machine
> which ends up with a failure so in my opinion it contains a boot
> failure - correct me
> if I'm wrong.

Oh, I'm sorry, I didn't look through all the way to the end of the
log, as I expected the crash to happen before Dom0 even starts.

>> Also, sadly, the debug output isn't really helpful, which is why
>> the patch that supposedly fixes your boot problem also adjusts
>> what gets printed here (for the unlikely case that your problem
>> persists with that patch:
>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html).
>>
> 
> So to ensure myself: I should apply a path from
> http://lists.xen.org/archives/html/xen-devel/2013-02/msg00408.html 
> and that should resolve my problem? Or maybe is there is a planned release
> of next Xen version that will already contain this patch? If a release
> is planned
> to be in near future I would prefer to wait for it rather than apply the 
> patch
> myself and compile Xen from sources.

With the above, the patch is unlikely to address your problem,
but will likely provide better debugging output. So please
nevertheless try building with that patch included, assuming
the problem first started after you built Xen from a recent
4.2-testing tree (as opposed to this being plain 4.2.1, in which
case the problem is obviously unrelated to the recent changes
I'm thinking of).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:07:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:07: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 1U5DhK-0002LG-Mp; Tue, 12 Feb 2013 11:06:50 +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 1U5DhJ-0002LA-Sk
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 11:06:50 +0000
Received: from [85.158.139.211:46410] by server-2.bemta-5.messagelabs.com id
	0F/03-16911-9422A115; Tue, 12 Feb 2013 11:06:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360667208!21734344!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24876 invoked from network); 12 Feb 2013 11:06:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:06:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:08:16 +0000
Message-Id: <511A305502000078000BDAFA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:06:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"xen.org" <ian.jackson@eu.citrix.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
	<1360665371.20449.150.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360665371.20449.150.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:36, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-11 at 23:12 +0000, xen.org wrote:
>> branch xen-unstable
>> xen branch xen-unstable
>> job test-amd64-i386-xl-multivcpu
>> test guest-localmigrate/x10
>> 
>> Tree: linux git://xenbits.xen.org/linux-pvops.git
>> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
>> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>> 
>> *** Found and reproduced problem changeset ***
>> 
>>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>>   Bug introduced:  fd997a96d448
>>   Bug not present: ffd30e7388ad
>> 
>> 
>>   changeset:   26523:fd997a96d448
>>   tag:         tip
>>   user:        Jan Beulich <jbeulich@suse.com>
>>   date:        Fri Feb 08 11:06:04 2013 +0100
>>       
>>       x86: debugging code for testing 16Tb support on smaller memory systems
>>       
>>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>       Acked-by: Keir Fraser <keir@xen.org>
> 
> This is now the second bisection to finger this changeset
> ("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
> yesterday was the other).
> 
> Perhaps it is worth investigating after all?

Yes, quite obviously it is (looking at the serial log).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:07:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:07: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 1U5DhK-0002LG-Mp; Tue, 12 Feb 2013 11:06:50 +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 1U5DhJ-0002LA-Sk
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 11:06:50 +0000
Received: from [85.158.139.211:46410] by server-2.bemta-5.messagelabs.com id
	0F/03-16911-9422A115; Tue, 12 Feb 2013 11:06:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360667208!21734344!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24876 invoked from network); 12 Feb 2013 11:06:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:06:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:08:16 +0000
Message-Id: <511A305502000078000BDAFA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:06:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"xen.org" <ian.jackson@eu.citrix.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
	<1360665371.20449.150.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360665371.20449.150.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:36, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-11 at 23:12 +0000, xen.org wrote:
>> branch xen-unstable
>> xen branch xen-unstable
>> job test-amd64-i386-xl-multivcpu
>> test guest-localmigrate/x10
>> 
>> Tree: linux git://xenbits.xen.org/linux-pvops.git
>> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
>> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>> 
>> *** Found and reproduced problem changeset ***
>> 
>>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>>   Bug introduced:  fd997a96d448
>>   Bug not present: ffd30e7388ad
>> 
>> 
>>   changeset:   26523:fd997a96d448
>>   tag:         tip
>>   user:        Jan Beulich <jbeulich@suse.com>
>>   date:        Fri Feb 08 11:06:04 2013 +0100
>>       
>>       x86: debugging code for testing 16Tb support on smaller memory systems
>>       
>>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>       Acked-by: Keir Fraser <keir@xen.org>
> 
> This is now the second bisection to finger this changeset
> ("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
> yesterday was the other).
> 
> Perhaps it is worth investigating after all?

Yes, quite obviously it is (looking at the serial log).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:14:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11: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 1U5DoK-0002Zx-Kn; Tue, 12 Feb 2013 11:14:04 +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 1U5DoJ-0002Zs-P0
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 11:14:03 +0000
Received: from [85.158.137.99:28324] by server-3.bemta-3.messagelabs.com id
	BA/E2-31070-AF32A115; Tue, 12 Feb 2013 11:14:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360667642!20232686!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7056 invoked from network); 12 Feb 2013 11:14:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:14:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:15:29 +0000
Message-Id: <511A320602000078000BDB17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:13:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"xen.org" <ian.jackson@eu.citrix.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
	<1360665371.20449.150.camel@zakaz.uk.xensource.com>
	<511A305502000078000BDAFA@nat28.tlf.novell.com>
In-Reply-To: <511A305502000078000BDAFA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 12.02.13 at 11:36, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Mon, 2013-02-11 at 23:12 +0000, xen.org wrote:
>>> branch xen-unstable
>>> xen branch xen-unstable
>>> job test-amd64-i386-xl-multivcpu
>>> test guest-localmigrate/x10
>>> 
>>> Tree: linux git://xenbits.xen.org/linux-pvops.git
>>> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
>>> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>>> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>>> 
>>> *** Found and reproduced problem changeset ***
>>> 
>>>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>>>   Bug introduced:  fd997a96d448
>>>   Bug not present: ffd30e7388ad
>>> 
>>> 
>>>   changeset:   26523:fd997a96d448
>>>   tag:         tip
>>>   user:        Jan Beulich <jbeulich@suse.com>
>>>   date:        Fri Feb 08 11:06:04 2013 +0100
>>>       
>>>       x86: debugging code for testing 16Tb support on smaller memory systems
>>>       
>>>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>       Acked-by: Keir Fraser <keir@xen.org>
>> 
>> This is now the second bisection to finger this changeset
>> ("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
>> yesterday was the other).
>> 
>> Perhaps it is worth investigating after all?
> 
> Yes, quite obviously it is (looking at the serial log).

And this looks to be a domain page mapping leak, one of which I
already spotted on Friday (but didn't get around to send a patch
for, not the least because I wasn't in the office yesterday).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:14:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11: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 1U5DoK-0002Zx-Kn; Tue, 12 Feb 2013 11:14:04 +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 1U5DoJ-0002Zs-P0
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 11:14:03 +0000
Received: from [85.158.137.99:28324] by server-3.bemta-3.messagelabs.com id
	BA/E2-31070-AF32A115; Tue, 12 Feb 2013 11:14:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360667642!20232686!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7056 invoked from network); 12 Feb 2013 11:14:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:14:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:15:29 +0000
Message-Id: <511A320602000078000BDB17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:13:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"xen.org" <ian.jackson@eu.citrix.com>
References: <E1U52Xz-0008Uq-CO@woking.cam.xci-test.com>
	<1360665371.20449.150.camel@zakaz.uk.xensource.com>
	<511A305502000078000BDAFA@nat28.tlf.novell.com>
In-Reply-To: <511A305502000078000BDAFA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 12.02.13 at 11:36, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Mon, 2013-02-11 at 23:12 +0000, xen.org wrote:
>>> branch xen-unstable
>>> xen branch xen-unstable
>>> job test-amd64-i386-xl-multivcpu
>>> test guest-localmigrate/x10
>>> 
>>> Tree: linux git://xenbits.xen.org/linux-pvops.git
>>> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
>>> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>>> Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>>> 
>>> *** Found and reproduced problem changeset ***
>>> 
>>>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>>>   Bug introduced:  fd997a96d448
>>>   Bug not present: ffd30e7388ad
>>> 
>>> 
>>>   changeset:   26523:fd997a96d448
>>>   tag:         tip
>>>   user:        Jan Beulich <jbeulich@suse.com>
>>>   date:        Fri Feb 08 11:06:04 2013 +0100
>>>       
>>>       x86: debugging code for testing 16Tb support on smaller memory systems
>>>       
>>>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>       Acked-by: Keir Fraser <keir@xen.org>
>> 
>> This is now the second bisection to finger this changeset
>> ("[xen-unstable bisection] complete test-amd64-i386-xl-credit2"
>> yesterday was the other).
>> 
>> Perhaps it is worth investigating after all?
> 
> Yes, quite obviously it is (looking at the serial log).

And this looks to be a domain page mapping leak, one of which I
already spotted on Friday (but didn't get around to send a patch
for, not the least because I wasn't in the office yesterday).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:18:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:18: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 1U5Dsa-0002hn-Bg; Tue, 12 Feb 2013 11:18:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5DsY-0002hi-PI
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:18:26 +0000
Received: from [193.109.254.147:44856] by server-7.bemta-14.messagelabs.com id
	D8/EE-13581-2052A115; Tue, 12 Feb 2013 11:18:26 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360667726!4502506!1
X-Originating-IP: [209.85.128.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNTcxMjUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4854 invoked from network); 12 Feb 2013 11:15:28 -0000
Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com)
	(209.85.128.179)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 11:15:28 -0000
Received: by mail-ve0-f179.google.com with SMTP id da11so5956752veb.38
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 03:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=xFctFXM21REAIIcmKWFSFuTMcFCpr+MRvYYp9KU4XS4=;
	b=wTAFLBGui1DxWoN/JOr66jJADlznW/2r/Uhn8ebawe/ffLcd9arrBqV/3Zr0SmrQdf
	zmi1BhRMRmKHX7mvNYiRuegUe8uLeSrXkZfel2ozAEPYLjMre4wm3DPJN1zdIBBkCdau
	PaXnD2nKJNOkiWK08xzxb13cEl7zo5HKyVlCiCN2n3mRLwRIxQyyp8L6agH8rTB87u7H
	KbHV5FpLmr+FTxt4DsK27mfOirKDui4RR+jInY8ZHUNqr1QoTkwt7LqpT88wZcK/SbZk
	THmrJYD+uWS8RQP5S0TY8hhDEO22DbnV/nKHZI2FF3Fs5vgHp9HsX8Vtx5zIoz36Ungb
	Sk9Q==
X-Received: by 10.220.154.66 with SMTP id n2mr23849473vcw.40.1360667725628;
	Tue, 12 Feb 2013 03:15:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Tue, 12 Feb 2013 03:15:05 -0800 (PST)
In-Reply-To: <511A2FA402000078000BDAF7@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 12:15:05 +0100
Message-ID: <CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
> With the above, the patch is unlikely to address your problem,
> but will likely provide better debugging output. So please
> nevertheless try building with that patch included, assuming
> the problem first started after you built Xen from a recent
> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
> case the problem is obviously unrelated to the recent changes
> I'm thinking of).
>

I haven't built Xen myself, I use binaries from
http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
that builds in this repository are from plain 4.2.1.
xl info (when I boot with iommu disabled) shows:
xen_major              : 4
xen_minor              : 2
xen_extra              : .1

I just started using Xen when 4.2.1 already was released so this
problem appeared to me from the beginning. I can try with 4.2-testing
though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:18:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:18: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 1U5Dsa-0002hn-Bg; Tue, 12 Feb 2013 11:18:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5DsY-0002hi-PI
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:18:26 +0000
Received: from [193.109.254.147:44856] by server-7.bemta-14.messagelabs.com id
	D8/EE-13581-2052A115; Tue, 12 Feb 2013 11:18:26 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360667726!4502506!1
X-Originating-IP: [209.85.128.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNTcxMjUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4854 invoked from network); 12 Feb 2013 11:15:28 -0000
Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com)
	(209.85.128.179)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 11:15:28 -0000
Received: by mail-ve0-f179.google.com with SMTP id da11so5956752veb.38
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 03:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=xFctFXM21REAIIcmKWFSFuTMcFCpr+MRvYYp9KU4XS4=;
	b=wTAFLBGui1DxWoN/JOr66jJADlznW/2r/Uhn8ebawe/ffLcd9arrBqV/3Zr0SmrQdf
	zmi1BhRMRmKHX7mvNYiRuegUe8uLeSrXkZfel2ozAEPYLjMre4wm3DPJN1zdIBBkCdau
	PaXnD2nKJNOkiWK08xzxb13cEl7zo5HKyVlCiCN2n3mRLwRIxQyyp8L6agH8rTB87u7H
	KbHV5FpLmr+FTxt4DsK27mfOirKDui4RR+jInY8ZHUNqr1QoTkwt7LqpT88wZcK/SbZk
	THmrJYD+uWS8RQP5S0TY8hhDEO22DbnV/nKHZI2FF3Fs5vgHp9HsX8Vtx5zIoz36Ungb
	Sk9Q==
X-Received: by 10.220.154.66 with SMTP id n2mr23849473vcw.40.1360667725628;
	Tue, 12 Feb 2013 03:15:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.239.35 with HTTP; Tue, 12 Feb 2013 03:15:05 -0800 (PST)
In-Reply-To: <511A2FA402000078000BDAF7@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 12:15:05 +0100
Message-ID: <CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
> With the above, the patch is unlikely to address your problem,
> but will likely provide better debugging output. So please
> nevertheless try building with that patch included, assuming
> the problem first started after you built Xen from a recent
> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
> case the problem is obviously unrelated to the recent changes
> I'm thinking of).
>

I haven't built Xen myself, I use binaries from
http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
that builds in this repository are from plain 4.2.1.
xl info (when I boot with iommu disabled) shows:
xen_major              : 4
xen_minor              : 2
xen_extra              : .1

I just started using Xen when 4.2.1 already was released so this
problem appeared to me from the beginning. I can try with 4.2-testing
though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:21:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:21: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 1U5DvA-0002qX-VV; Tue, 12 Feb 2013 11:21:08 +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 1U5Dv9-0002qO-9q
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:21:07 +0000
Received: from [85.158.137.99:6103] by server-2.bemta-3.messagelabs.com id
	4D/3B-25961-2A52A115; Tue, 12 Feb 2013 11:21:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360668065!20962679!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12913 invoked from network); 12 Feb 2013 11:21:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:21:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:22:33 +0000
Message-Id: <511A33AE02000078000BDB28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:21:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part88B8CE8E.0__="
Subject: [Xen-devel] [PATCH] x86: fix map_domain_page() leak from
 vcpu_destroy_pagetables()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part88B8CE8E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Introduced by c/s 26450:4816763549e0 and exposed with
26523:fd997a96d448.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1997,6 +1997,7 @@ static void vcpu_destroy_pagetables(stru
         }
=20
         l4e_write(l4tab, l4e_empty());
+        unmap_domain_page(l4tab);
=20
         v->arch.cr3 =3D 0;
         return;




--=__Part88B8CE8E.0__=
Content-Type: text/plain; name="x86-map-domain-page-leak.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-domain-page-leak.patch"

x86: fix map_domain_page() leak from vcpu_destroy_pagetables()=0A=0AIntrodu=
ced by c/s 26450:4816763549e0 and exposed with=0A26523:fd997a96d448.=0A=0AS=
igned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domai=
n.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -1997,6 +1997,7 @@ static void =
vcpu_destroy_pagetables(stru=0A         }=0A =0A         l4e_write(l4tab, =
l4e_empty());=0A+        unmap_domain_page(l4tab);=0A =0A         =
v->arch.cr3 =3D 0;=0A         return;=0A
--=__Part88B8CE8E.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

--=__Part88B8CE8E.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 12 11:21:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:21: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 1U5DvA-0002qX-VV; Tue, 12 Feb 2013 11:21:08 +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 1U5Dv9-0002qO-9q
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:21:07 +0000
Received: from [85.158.137.99:6103] by server-2.bemta-3.messagelabs.com id
	4D/3B-25961-2A52A115; Tue, 12 Feb 2013 11:21:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360668065!20962679!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12913 invoked from network); 12 Feb 2013 11:21:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:21:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:22:33 +0000
Message-Id: <511A33AE02000078000BDB28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:21:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part88B8CE8E.0__="
Subject: [Xen-devel] [PATCH] x86: fix map_domain_page() leak from
 vcpu_destroy_pagetables()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part88B8CE8E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Introduced by c/s 26450:4816763549e0 and exposed with
26523:fd997a96d448.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1997,6 +1997,7 @@ static void vcpu_destroy_pagetables(stru
         }
=20
         l4e_write(l4tab, l4e_empty());
+        unmap_domain_page(l4tab);
=20
         v->arch.cr3 =3D 0;
         return;




--=__Part88B8CE8E.0__=
Content-Type: text/plain; name="x86-map-domain-page-leak.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-domain-page-leak.patch"

x86: fix map_domain_page() leak from vcpu_destroy_pagetables()=0A=0AIntrodu=
ced by c/s 26450:4816763549e0 and exposed with=0A26523:fd997a96d448.=0A=0AS=
igned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domai=
n.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -1997,6 +1997,7 @@ static void =
vcpu_destroy_pagetables(stru=0A         }=0A =0A         l4e_write(l4tab, =
l4e_empty());=0A+        unmap_domain_page(l4tab);=0A =0A         =
v->arch.cr3 =3D 0;=0A         return;=0A
--=__Part88B8CE8E.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

--=__Part88B8CE8E.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 12 11:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:22: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 1U5DwI-0002wF-Ml; Tue, 12 Feb 2013 11:22:18 +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 1U5DwH-0002w0-Iz
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:22:17 +0000
Received: from [85.158.137.99:46754] by server-12.bemta-3.messagelabs.com id
	71/D8-05889-8E52A115; Tue, 12 Feb 2013 11:22:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360668135!13249297!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6250 invoked from network); 12 Feb 2013 11:22:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:22:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:23:43 +0000
Message-Id: <511A33F302000078000BDB2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:22:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
In-Reply-To: <CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 12:15, povder <povder@gmail.com> wrote:
> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>> With the above, the patch is unlikely to address your problem,
>> but will likely provide better debugging output. So please
>> nevertheless try building with that patch included, assuming
>> the problem first started after you built Xen from a recent
>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
>> case the problem is obviously unrelated to the recent changes
>> I'm thinking of).
>>
> 
> I haven't built Xen myself, I use binaries from
> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
> that builds in this repository are from plain 4.2.1.
> xl info (when I boot with iommu disabled) shows:
> xen_major              : 4
> xen_minor              : 2
> xen_extra              : .1
> 
> I just started using Xen when 4.2.1 already was released so this
> problem appeared to me from the beginning. I can try with 4.2-testing
> though.

No, there's no point I'm afraid. We really need to analyze the
debugging output to first understand what's missing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:22: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 1U5DwI-0002wF-Ml; Tue, 12 Feb 2013 11:22:18 +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 1U5DwH-0002w0-Iz
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:22:17 +0000
Received: from [85.158.137.99:46754] by server-12.bemta-3.messagelabs.com id
	71/D8-05889-8E52A115; Tue, 12 Feb 2013 11:22:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1360668135!13249297!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6250 invoked from network); 12 Feb 2013 11:22:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:22:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:23:43 +0000
Message-Id: <511A33F302000078000BDB2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:22:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
In-Reply-To: <CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 12:15, povder <povder@gmail.com> wrote:
> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>> With the above, the patch is unlikely to address your problem,
>> but will likely provide better debugging output. So please
>> nevertheless try building with that patch included, assuming
>> the problem first started after you built Xen from a recent
>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
>> case the problem is obviously unrelated to the recent changes
>> I'm thinking of).
>>
> 
> I haven't built Xen myself, I use binaries from
> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
> that builds in this repository are from plain 4.2.1.
> xl info (when I boot with iommu disabled) shows:
> xen_major              : 4
> xen_minor              : 2
> xen_extra              : .1
> 
> I just started using Xen when 4.2.1 already was released so this
> problem appeared to me from the beginning. I can try with 4.2-testing
> though.

No, there's no point I'm afraid. We really need to analyze the
debugging output to first understand what's missing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:30:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11: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 1U5E3n-0003B5-L5; Tue, 12 Feb 2013 11:30:03 +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 1U5E3l-0003B0-Jw
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:30:02 +0000
Received: from [85.158.137.99:50749] by server-14.bemta-3.messagelabs.com id
	2C/39-23533-8B72A115; Tue, 12 Feb 2013 11:30:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360668599!21090773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22874 invoked from network); 12 Feb 2013 11:30:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:30:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:31:27 +0000
Message-Id: <511A35C402000078000BDB47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:29:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
In-Reply-To: <511A33F302000078000BDB2B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 12:22, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 12.02.13 at 12:15, povder <povder@gmail.com> wrote:
>> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>> With the above, the patch is unlikely to address your problem,
>>> but will likely provide better debugging output. So please
>>> nevertheless try building with that patch included, assuming
>>> the problem first started after you built Xen from a recent
>>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
>>> case the problem is obviously unrelated to the recent changes
>>> I'm thinking of).
>>>
>> 
>> I haven't built Xen myself, I use binaries from
>> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
>> that builds in this repository are from plain 4.2.1.
>> xl info (when I boot with iommu disabled) shows:
>> xen_major              : 4
>> xen_minor              : 2
>> xen_extra              : .1
>> 
>> I just started using Xen when 4.2.1 already was released so this
>> problem appeared to me from the beginning. I can try with 4.2-testing
>> though.
> 
> No, there's no point I'm afraid. We really need to analyze the
> debugging output to first understand what's missing.

All there is for bus 7 is

(XEN) AMD-Vi: IVHD Device Entry:
(XEN) AMD-Vi:  Type 0x2
(XEN) AMD-Vi:  Dev_Id 0x700
(XEN) AMD-Vi:  Flags 0x0

i.e. a single device at 07:00.0, yet from the register dump at the
crash it's fairly clear that we're talking about 07:00.1 here. I'm
afraid only a firmware update can help you here (or passing
"iommu=off" to Xen); in particular I can't see how we could work
around that problem in software.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:30:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11: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 1U5E3n-0003B5-L5; Tue, 12 Feb 2013 11:30:03 +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 1U5E3l-0003B0-Jw
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:30:02 +0000
Received: from [85.158.137.99:50749] by server-14.bemta-3.messagelabs.com id
	2C/39-23533-8B72A115; Tue, 12 Feb 2013 11:30:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360668599!21090773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwODY=\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22874 invoked from network); 12 Feb 2013 11:30:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:30:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:31:27 +0000
Message-Id: <511A35C402000078000BDB47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:29:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
In-Reply-To: <511A33F302000078000BDB2B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 12:22, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 12.02.13 at 12:15, povder <povder@gmail.com> wrote:
>> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>> With the above, the patch is unlikely to address your problem,
>>> but will likely provide better debugging output. So please
>>> nevertheless try building with that patch included, assuming
>>> the problem first started after you built Xen from a recent
>>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
>>> case the problem is obviously unrelated to the recent changes
>>> I'm thinking of).
>>>
>> 
>> I haven't built Xen myself, I use binaries from
>> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
>> that builds in this repository are from plain 4.2.1.
>> xl info (when I boot with iommu disabled) shows:
>> xen_major              : 4
>> xen_minor              : 2
>> xen_extra              : .1
>> 
>> I just started using Xen when 4.2.1 already was released so this
>> problem appeared to me from the beginning. I can try with 4.2-testing
>> though.
> 
> No, there's no point I'm afraid. We really need to analyze the
> debugging output to first understand what's missing.

All there is for bus 7 is

(XEN) AMD-Vi: IVHD Device Entry:
(XEN) AMD-Vi:  Type 0x2
(XEN) AMD-Vi:  Dev_Id 0x700
(XEN) AMD-Vi:  Flags 0x0

i.e. a single device at 07:00.0, yet from the register dump at the
crash it's fairly clear that we're talking about 07:00.1 here. I'm
afraid only a firmware update can help you here (or passing
"iommu=off" to Xen); in particular I can't see how we could work
around that problem in software.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:59:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:59: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 1U5EW6-0003ZE-JF; Tue, 12 Feb 2013 11:59:18 +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 1U5EW5-0003Z9-91
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:59:17 +0000
Received: from [85.158.138.51:21503] by server-8.bemta-3.messagelabs.com id
	AA/3D-25687-49E2A115; Tue, 12 Feb 2013 11:59:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360670354!23188586!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21200 invoked from network); 12 Feb 2013 11:59:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:59:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:59:13 +0000
Message-Id: <511A3C9C02000078000BDB53@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:59:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<1360579774.29432.102.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360579774.29432.102.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	xen-devel <xen-devel@lists.xen.org>, suravee.suthikulpanit@amd.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 11.02.13 at 11:49, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-06 at 13:12 +0000, Jan Beulich wrote:
>> Apart from dealing duplicate conflicting entries, we also have to
>> handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
>> so has resulted in c/s 26517:601139e2b0db to crash such systems during
>> boot (whereas with the change here the IOMMU gets disabled just as is
>> being done in the other cases, i.e. unless global tables are being
>> used).
>> 
>> Debugging this issue has also pointed out that the debug log output is
>> pretty ugly to look at - consolidate the output, and add one extra
>> item for the IVHD special entries, so that future issues are easier
>> to analyze.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
> 
> Not really my area but the change looks reasonably straight forward and
> fixes a real error observed in the field,
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

While I'd like to see this one go in rather sooner than later, I'm
willing to wait for the community call tomorrow to see whether
we can get an AMD side ack for this and the other patch. But
we surely shouldn't defer getting this in for much longer.

Jan

>> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
>> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>> @@ -354,9 +354,8 @@ static int __init parse_ivmd_block(const
>>      base = start_addr & PAGE_MASK;
>>      limit = (start_addr + mem_length - 1) & PAGE_MASK;
>>  
>> -    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
>> -    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
>> -    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
>> +    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
>> +                    ivmd_block->header.type, start_addr, mem_length);
>>  
>>      if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
>>          iw = ir = IOMMU_CONTROL_ENABLED;
>> @@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia
>>          return 0;
>>      }
>>  
>> -    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
>> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
>> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias %#x\n",
>> +                    first_bdf, last_bdf, alias_id);
>>  
>>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>>          add_ivrs_mapping_entry(bdf, alias_id, 
> range->alias.header.data_setting,
>> @@ -654,6 +653,9 @@ static u16 __init parse_ivhd_device_spec
>>          return 0;
>>      }
>>  
>> +    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle 
> %#x\n",
>> +                    seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
>> +                    special->variety, special->handle);
>>      add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
>>  
>>      switch ( special->variety )
>> @@ -758,10 +760,9 @@ static int __init parse_ivhd_block(const
>>      {
>>          ivhd_device = (const void *)((const u8 *)ivhd_block + 
> block_length);
>>  
>> -        AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
>> -        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
>> -        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
>> -        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);
>> +        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags %#x\n",
>> +                        ivhd_device->header.type, ivhd_device->header.id,
>> +                        ivhd_device->header.data_setting);
>>  
>>          switch ( ivhd_device->header.type )
>>          {
>> @@ -890,6 +891,7 @@ static int __init parse_ivrs_table(struc
>>  {
>>      const struct acpi_ivrs_header *ivrs_block;
>>      unsigned long length;
>> +    unsigned int apic;
>>      int error = 0;
>>  
>>      BUG_ON(!table);
>> @@ -903,11 +905,9 @@ static int __init parse_ivrs_table(struc
>>      {
>>          ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>>  
>> -        AMD_IOMMU_DEBUG("IVRS Block:\n");
>> -        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
>> -        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
>> -        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
>> -        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
>> +        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id %#x\n",
>> +                        ivrs_block->type, ivrs_block->flags,
>> +                        ivrs_block->length, ivrs_block->device_id);
>>  
>>          if ( table->length < (length + ivrs_block->length) )
>>          {
>> @@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc
>>          length += ivrs_block->length;
>>      }
>>  
>> +    /* Each IO-APIC must have been mentioned in the table. */
>> +    for ( apic = 0; !error && apic < nr_ioapics; ++apic )
>> +    {
>> +        if ( !nr_ioapic_entries[apic] ||
>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            continue;
>> +
>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>> +               IO_APIC_ID(apic));
>> +        if ( amd_iommu_perdev_intremap )
>> +            error = -ENXIO;
>> +        else
>> +        {
>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            {
>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>> +                error = -ENOMEM;
>> +            }
>> +        }
>> +    }
>> +
>>      return error;
>>  }
>>  
>> 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 11:59:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 11:59: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 1U5EW6-0003ZE-JF; Tue, 12 Feb 2013 11:59:18 +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 1U5EW5-0003Z9-91
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 11:59:17 +0000
Received: from [85.158.138.51:21503] by server-8.bemta-3.messagelabs.com id
	AA/3D-25687-49E2A115; Tue, 12 Feb 2013 11:59:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360670354!23188586!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21200 invoked from network); 12 Feb 2013 11:59:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 11:59:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 11:59:13 +0000
Message-Id: <511A3C9C02000078000BDB53@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 11:59:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <511262E302000078000BC738@nat28.tlf.novell.com>
	<511264B402000078000BC754@nat28.tlf.novell.com>
	<1360579774.29432.102.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360579774.29432.102.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	xen-devel <xen-devel@lists.xen.org>, suravee.suthikulpanit@amd.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/2] AMD IOMMU: also spot missing IO-APIC
 entries in IVRS 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 11.02.13 at 11:49, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-06 at 13:12 +0000, Jan Beulich wrote:
>> Apart from dealing duplicate conflicting entries, we also have to
>> handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
>> so has resulted in c/s 26517:601139e2b0db to crash such systems during
>> boot (whereas with the change here the IOMMU gets disabled just as is
>> being done in the other cases, i.e. unless global tables are being
>> used).
>> 
>> Debugging this issue has also pointed out that the debug log output is
>> pretty ugly to look at - consolidate the output, and add one extra
>> item for the IVHD special entries, so that future issues are easier
>> to analyze.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
> 
> Not really my area but the change looks reasonably straight forward and
> fixes a real error observed in the field,
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

While I'd like to see this one go in rather sooner than later, I'm
willing to wait for the community call tomorrow to see whether
we can get an AMD side ack for this and the other patch. But
we surely shouldn't defer getting this in for much longer.

Jan

>> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
>> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>> @@ -354,9 +354,8 @@ static int __init parse_ivmd_block(const
>>      base = start_addr & PAGE_MASK;
>>      limit = (start_addr + mem_length - 1) & PAGE_MASK;
>>  
>> -    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
>> -    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
>> -    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
>> +    AMD_IOMMU_DEBUG("IVMD Block: type %#x phys %#lx len %#lx\n",
>> +                    ivmd_block->header.type, start_addr, mem_length);
>>  
>>      if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
>>          iw = ir = IOMMU_CONTROL_ENABLED;
>> @@ -551,8 +550,8 @@ static u16 __init parse_ivhd_device_alia
>>          return 0;
>>      }
>>  
>> -    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
>> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
>> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x alias %#x\n",
>> +                    first_bdf, last_bdf, alias_id);
>>  
>>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>>          add_ivrs_mapping_entry(bdf, alias_id, 
> range->alias.header.data_setting,
>> @@ -654,6 +653,9 @@ static u16 __init parse_ivhd_device_spec
>>          return 0;
>>      }
>>  
>> +    AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle 
> %#x\n",
>> +                    seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
>> +                    special->variety, special->handle);
>>      add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
>>  
>>      switch ( special->variety )
>> @@ -758,10 +760,9 @@ static int __init parse_ivhd_block(const
>>      {
>>          ivhd_device = (const void *)((const u8 *)ivhd_block + 
> block_length);
>>  
>> -        AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
>> -        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
>> -        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
>> -        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);
>> +        AMD_IOMMU_DEBUG("IVHD Device Entry: type %#x id %#x flags %#x\n",
>> +                        ivhd_device->header.type, ivhd_device->header.id,
>> +                        ivhd_device->header.data_setting);
>>  
>>          switch ( ivhd_device->header.type )
>>          {
>> @@ -890,6 +891,7 @@ static int __init parse_ivrs_table(struc
>>  {
>>      const struct acpi_ivrs_header *ivrs_block;
>>      unsigned long length;
>> +    unsigned int apic;
>>      int error = 0;
>>  
>>      BUG_ON(!table);
>> @@ -903,11 +905,9 @@ static int __init parse_ivrs_table(struc
>>      {
>>          ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>>  
>> -        AMD_IOMMU_DEBUG("IVRS Block:\n");
>> -        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
>> -        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
>> -        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
>> -        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
>> +        AMD_IOMMU_DEBUG("IVRS Block: type %#x flags %#x len %#x id %#x\n",
>> +                        ivrs_block->type, ivrs_block->flags,
>> +                        ivrs_block->length, ivrs_block->device_id);
>>  
>>          if ( table->length < (length + ivrs_block->length) )
>>          {
>> @@ -922,6 +922,29 @@ static int __init parse_ivrs_table(struc
>>          length += ivrs_block->length;
>>      }
>>  
>> +    /* Each IO-APIC must have been mentioned in the table. */
>> +    for ( apic = 0; !error && apic < nr_ioapics; ++apic )
>> +    {
>> +        if ( !nr_ioapic_entries[apic] ||
>> +             ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            continue;
>> +
>> +        printk(XENLOG_ERR "IVHD Error: no information for IO-APIC %#x\n",
>> +               IO_APIC_ID(apic));
>> +        if ( amd_iommu_perdev_intremap )
>> +            error = -ENXIO;
>> +        else
>> +        {
>> +            ioapic_sbdf[IO_APIC_ID(apic)].pin_setup = xzalloc_array(
>> +                unsigned long, BITS_TO_LONGS(nr_ioapic_entries[apic]));
>> +            if ( !ioapic_sbdf[IO_APIC_ID(apic)].pin_setup )
>> +            {
>> +                printk(XENLOG_ERR "IVHD Error: Out of memory\n");
>> +                error = -ENOMEM;
>> +            }
>> +        }
>> +    }
>> +
>>      return error;
>>  }
>>  
>> 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 12:26:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 12:26: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 1U5Ew4-00043l-Os; Tue, 12 Feb 2013 12:26:08 +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 1U5Ew3-00043d-KX
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 12:26:07 +0000
Received: from [85.158.139.83:62923] by server-6.bemta-5.messagelabs.com id
	55/4B-01489-ED43A115; Tue, 12 Feb 2013 12:26:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360671964!26739693!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21910 invoked from network); 12 Feb 2013 12:26:04 -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; 12 Feb 2013 12:26:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 12:26:03 +0000
Message-Id: <511A42E902000078000BDB5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 12:26:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kouya Shimura" <kouya@jp.fujitsu.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
In-Reply-To: <5110A2DD.1080603@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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 05.02.13 at 07:12, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>--- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
>+++ b/xen/arch/x86/hvm/pmtimer.c	Tue Feb 05 10:26:13 2013 +0900
>@@ -84,28 +84,31 @@ void hvm_acpi_sleep_button(struct domain
> }
> 
> /* Set the correct value in the timer, accounting for time elapsed
>- * since the last time we did that. */
>-static void pmt_update_time(PMTState *s)
>+ * since the last time we did that.
>+ * return true if the counter's MSB has changed. */
>+static bool_t pmt_count_up_and_test_msb(PMTState *s, uint64_t gtime)
> {
>-    uint64_t curr_gtime, tmp;
>     uint32_t tmr_val = s->pm.tmr_val, msb = tmr_val & TMR_VAL_MSB;
>-    
>-    ASSERT(spin_is_locked(&s->lock));
>+    uint64_t tmp = ((gtime - s->last_gtime) * s->scale) + s->not_accounted;
> 
>-    /* Update the timer */
>-    curr_gtime = hvm_get_guest_time(s->vcpu);
>-    tmp = ((curr_gtime - s->last_gtime) * s->scale) + s->not_accounted;
>     s->not_accounted = (uint32_t)tmp;
>     tmr_val += tmp >> 32;
>     tmr_val &= TMR_VAL_MASK;
>-    s->last_gtime = curr_gtime;
>+    s->last_gtime = gtime;
> 
>     /* Update timer value atomically wrt lock-free reads in handle_pmt_io(). */
>     *(volatile uint32_t *)&s->pm.tmr_val = tmr_val;
> 
>-    /* If the counter's MSB has changed, set the status bit */
>-    if ( (tmr_val & TMR_VAL_MSB) != msb )
>+    return  ((tmr_val & TMR_VAL_MSB) != msb);

Single space only please.

>+}
>+
>+static void pmt_update_time(PMTState *s)
>+{
>+    ASSERT(spin_is_locked(&s->lock));
>+
>+    if ( pmt_count_up_and_test_msb(s, hvm_get_guest_time(s->vcpu)) )
>     {
>+        /* MSB has changed, set the status bit */
>         s->pm.pm1a_sts |= TMR_STS;
>         pmt_update_sci(s);
>     }
>@@ -244,21 +247,34 @@ static int handle_pmt_io(
> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
> {
>     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>+    uint64_t guest_time;
>     int rc;
> 
>     spin_lock(&s->lock);
> 
>-    /* Update the counter to the guest's current time.  We always save
>-     * with the domain paused, so the saved time should be after the
>-     * last_gtime, but just in case, make sure we only go forwards */
>-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>-    if ( x < 1UL<<31 )
>-        s->pm.tmr_val += x;
>-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>-        s->pm.pm1a_sts |= TMR_STS;
>-    /* No point in setting the SCI here because we'll already have saved the 
>-     * IRQ and *PIC state; we'll fix it up when we restore the domain */
>+    guest_time = s->vcpu->arch.hvm_vcpu.guest_time;
>+    /* Update the counter to the guest's current time only if the
>+     * timer mode is delay_for_missed_ticks */
>+    if ( guest_time != 0 )

How is guest_time being (non-)zero an indication of mode being
delay_for_missed_ticks? I think you should check for the mode
explicitly, as the value here being zero can just be an effect of
a large enough negative v->arch.hvm_vcpu.stime_offset.

And besides that you don't explain why the update being done
here is unnecessary in other modes - all you explain is that the
way it's being done in those modes is wrong.

>+    {
>+        /* We always save with the domain paused, so the saved time
>+         * should be after the last_gtime, but just in case, make sure
>+         * we only go forwards */
>+        if ( (s64)guest_time - (s64)s->last_gtime < 0)
>+        {
>+            dprintk(XENLOG_WARNING,
>+                    "Last update of PMT is ahead of guest's time by %ld\n",

While probably fine this way for -unstable, please nevertheless
use the correct PRId64 here (both to be formally correct and to
ease eventual backporting).

Jan

>+                    s->last_gtime - guest_time);
>+        }
>+        else
>+        {
>+            if ( pmt_count_up_and_test_msb(s, guest_time) )
>+                s->pm.pm1a_sts |= TMR_STS;
>+            /* No point in setting the SCI here because we'll already
>+             * have saved the IRQ and *PIC state;
>+             * we'll fix it up when we restore the domain */
>+        }
>+    }
> 
>     rc = hvm_save_entry(PMTIMER, 0, h, &s->pm);
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 12:26:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 12:26: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 1U5Ew4-00043l-Os; Tue, 12 Feb 2013 12:26:08 +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 1U5Ew3-00043d-KX
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 12:26:07 +0000
Received: from [85.158.139.83:62923] by server-6.bemta-5.messagelabs.com id
	55/4B-01489-ED43A115; Tue, 12 Feb 2013 12:26:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360671964!26739693!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21910 invoked from network); 12 Feb 2013 12:26:04 -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; 12 Feb 2013 12:26:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 12:26:03 +0000
Message-Id: <511A42E902000078000BDB5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 12:26:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kouya Shimura" <kouya@jp.fujitsu.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
In-Reply-To: <5110A2DD.1080603@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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 05.02.13 at 07:12, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>--- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
>+++ b/xen/arch/x86/hvm/pmtimer.c	Tue Feb 05 10:26:13 2013 +0900
>@@ -84,28 +84,31 @@ void hvm_acpi_sleep_button(struct domain
> }
> 
> /* Set the correct value in the timer, accounting for time elapsed
>- * since the last time we did that. */
>-static void pmt_update_time(PMTState *s)
>+ * since the last time we did that.
>+ * return true if the counter's MSB has changed. */
>+static bool_t pmt_count_up_and_test_msb(PMTState *s, uint64_t gtime)
> {
>-    uint64_t curr_gtime, tmp;
>     uint32_t tmr_val = s->pm.tmr_val, msb = tmr_val & TMR_VAL_MSB;
>-    
>-    ASSERT(spin_is_locked(&s->lock));
>+    uint64_t tmp = ((gtime - s->last_gtime) * s->scale) + s->not_accounted;
> 
>-    /* Update the timer */
>-    curr_gtime = hvm_get_guest_time(s->vcpu);
>-    tmp = ((curr_gtime - s->last_gtime) * s->scale) + s->not_accounted;
>     s->not_accounted = (uint32_t)tmp;
>     tmr_val += tmp >> 32;
>     tmr_val &= TMR_VAL_MASK;
>-    s->last_gtime = curr_gtime;
>+    s->last_gtime = gtime;
> 
>     /* Update timer value atomically wrt lock-free reads in handle_pmt_io(). */
>     *(volatile uint32_t *)&s->pm.tmr_val = tmr_val;
> 
>-    /* If the counter's MSB has changed, set the status bit */
>-    if ( (tmr_val & TMR_VAL_MSB) != msb )
>+    return  ((tmr_val & TMR_VAL_MSB) != msb);

Single space only please.

>+}
>+
>+static void pmt_update_time(PMTState *s)
>+{
>+    ASSERT(spin_is_locked(&s->lock));
>+
>+    if ( pmt_count_up_and_test_msb(s, hvm_get_guest_time(s->vcpu)) )
>     {
>+        /* MSB has changed, set the status bit */
>         s->pm.pm1a_sts |= TMR_STS;
>         pmt_update_sci(s);
>     }
>@@ -244,21 +247,34 @@ static int handle_pmt_io(
> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
> {
>     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>+    uint64_t guest_time;
>     int rc;
> 
>     spin_lock(&s->lock);
> 
>-    /* Update the counter to the guest's current time.  We always save
>-     * with the domain paused, so the saved time should be after the
>-     * last_gtime, but just in case, make sure we only go forwards */
>-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>-    if ( x < 1UL<<31 )
>-        s->pm.tmr_val += x;
>-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>-        s->pm.pm1a_sts |= TMR_STS;
>-    /* No point in setting the SCI here because we'll already have saved the 
>-     * IRQ and *PIC state; we'll fix it up when we restore the domain */
>+    guest_time = s->vcpu->arch.hvm_vcpu.guest_time;
>+    /* Update the counter to the guest's current time only if the
>+     * timer mode is delay_for_missed_ticks */
>+    if ( guest_time != 0 )

How is guest_time being (non-)zero an indication of mode being
delay_for_missed_ticks? I think you should check for the mode
explicitly, as the value here being zero can just be an effect of
a large enough negative v->arch.hvm_vcpu.stime_offset.

And besides that you don't explain why the update being done
here is unnecessary in other modes - all you explain is that the
way it's being done in those modes is wrong.

>+    {
>+        /* We always save with the domain paused, so the saved time
>+         * should be after the last_gtime, but just in case, make sure
>+         * we only go forwards */
>+        if ( (s64)guest_time - (s64)s->last_gtime < 0)
>+        {
>+            dprintk(XENLOG_WARNING,
>+                    "Last update of PMT is ahead of guest's time by %ld\n",

While probably fine this way for -unstable, please nevertheless
use the correct PRId64 here (both to be formally correct and to
ease eventual backporting).

Jan

>+                    s->last_gtime - guest_time);
>+        }
>+        else
>+        {
>+            if ( pmt_count_up_and_test_msb(s, guest_time) )
>+                s->pm.pm1a_sts |= TMR_STS;
>+            /* No point in setting the SCI here because we'll already
>+             * have saved the IRQ and *PIC state;
>+             * we'll fix it up when we restore the domain */
>+        }
>+    }
> 
>     rc = hvm_save_entry(PMTIMER, 0, h, &s->pm);
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 13:21:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 13:21: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 1U5Fn9-0004T7-JD; Tue, 12 Feb 2013 13:20:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1U5Fn8-0004Sy-QM
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 13:20:59 +0000
Received: from [85.158.137.99:12887] by server-10.bemta-3.messagelabs.com id
	82/D8-10609-5B14A115; Tue, 12 Feb 2013 13:20:53 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360675251!21112463!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19464 invoked from network); 12 Feb 2013 13:20:52 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 13:20:52 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 17177FE346
	for <xen-devel@lists.xensource.com>;
	Tue, 12 Feb 2013 13:22:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=postfix; bh=mQ3td7FqD0pqVmNviTcHcL
	YruiY=; b=wWZv8hco4DUiEzcKhA3ElMyVFnqMCwlnlav8IzbBX2uBIF7FMiALYX
	/+IRoJjHyVXjB6ryxnoE/RWDfvO05QvAJpyJjgM0J1m3nb1yNGMBNVCaPCU7jqGS
	tVVvLF0f26UoZmILabH+TRPKMuXCxBGTDnOdjRKYu/0EuaDbP/UZs=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=postfix; b=XUF3PFWk7k7B9Ufs
	DvIGLmgJ26QE+uKkMsYwGLRGLQIBpNsJNOhelCEtB7QRItJqmgj2YIdThkca8Xez
	dsD+F46MRClso+sqt5nPwRnjrrEoOcpEtb/5NO9+X6vKLHB2GQEi0+AVgtC7fkHb
	UAxlmnW182jRt/shqIoej53zfzg=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id B801DFE25D
	for <xen-devel@lists.xensource.com>;
	Tue, 12 Feb 2013 13:22:05 +0000 (UTC)
Message-ID: <511A41AE.6090102@goirand.fr>
Date: Tue, 12 Feb 2013 21:20:46 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.1
Subject: [Xen-devel] domU loosing ipv6 connectivity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

We have multiple cases where our domU looses IPv6 connectivity for a
while, then it pings again our IPv6 gateway. I've been searching on
google for similar cases, but I found none, though this issue, it seems
we have it on a lot of servers.

Note that I'm using sock (up to date) Debian Squeeze kernel and
hypervisor, with Xen 4.0 and kernel 3.6.32. Both domU which should be
communicating together (one being connected to HE tunnels to provide the
IPv6) are on the same physical server.

Cheers,

Thomas Goirand (zigo)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 13:21:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 13:21: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 1U5Fn9-0004T7-JD; Tue, 12 Feb 2013 13:20:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1U5Fn8-0004Sy-QM
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 13:20:59 +0000
Received: from [85.158.137.99:12887] by server-10.bemta-3.messagelabs.com id
	82/D8-10609-5B14A115; Tue, 12 Feb 2013 13:20:53 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360675251!21112463!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19464 invoked from network); 12 Feb 2013 13:20:52 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 13:20:52 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 17177FE346
	for <xen-devel@lists.xensource.com>;
	Tue, 12 Feb 2013 13:22:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=postfix; bh=mQ3td7FqD0pqVmNviTcHcL
	YruiY=; b=wWZv8hco4DUiEzcKhA3ElMyVFnqMCwlnlav8IzbBX2uBIF7FMiALYX
	/+IRoJjHyVXjB6ryxnoE/RWDfvO05QvAJpyJjgM0J1m3nb1yNGMBNVCaPCU7jqGS
	tVVvLF0f26UoZmILabH+TRPKMuXCxBGTDnOdjRKYu/0EuaDbP/UZs=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=postfix; b=XUF3PFWk7k7B9Ufs
	DvIGLmgJ26QE+uKkMsYwGLRGLQIBpNsJNOhelCEtB7QRItJqmgj2YIdThkca8Xez
	dsD+F46MRClso+sqt5nPwRnjrrEoOcpEtb/5NO9+X6vKLHB2GQEi0+AVgtC7fkHb
	UAxlmnW182jRt/shqIoej53zfzg=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id B801DFE25D
	for <xen-devel@lists.xensource.com>;
	Tue, 12 Feb 2013 13:22:05 +0000 (UTC)
Message-ID: <511A41AE.6090102@goirand.fr>
Date: Tue, 12 Feb 2013 21:20:46 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: xen devel <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.1
Subject: [Xen-devel] domU loosing ipv6 connectivity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

We have multiple cases where our domU looses IPv6 connectivity for a
while, then it pings again our IPv6 gateway. I've been searching on
google for similar cases, but I found none, though this issue, it seems
we have it on a lot of servers.

Note that I'm using sock (up to date) Debian Squeeze kernel and
hypervisor, with Xen 4.0 and kernel 3.6.32. Both domU which should be
communicating together (one being connected to HE tunnels to provide the
IPv6) are on the same physical server.

Cheers,

Thomas Goirand (zigo)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 13:32:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 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 1U5Fy2-0004el-So; Tue, 12 Feb 2013 13:32: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 1U5Fy1-0004eg-0k
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 13:32:13 +0000
Received: from [85.158.137.99:30931] by server-5.bemta-3.messagelabs.com id
	7A/0E-04457-7544A115; Tue, 12 Feb 2013 13:32:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360675926!15689767!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3194 invoked from network); 12 Feb 2013 13:32:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 13:32:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1373661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 13:32: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.297.1; Tue, 12 Feb 2013 13:32:06 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5Fxt-0007g9-US;
	Tue, 12 Feb 2013 13:32:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5Fxt-0004Ww-Sd;
	Tue, 12 Feb 2013 13:32:05 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16102-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 13:32:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16102: 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 16102 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16102/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16102
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 16102
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 16102
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16102
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16102
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16102
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16102

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install    fail blocked in 16012-bisect
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 15817 like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 12 13:32:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 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 1U5Fy2-0004el-So; Tue, 12 Feb 2013 13:32: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 1U5Fy1-0004eg-0k
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 13:32:13 +0000
Received: from [85.158.137.99:30931] by server-5.bemta-3.messagelabs.com id
	7A/0E-04457-7544A115; Tue, 12 Feb 2013 13:32:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360675926!15689767!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3194 invoked from network); 12 Feb 2013 13:32:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 13:32:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1373661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 13:32: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.297.1; Tue, 12 Feb 2013 13:32:06 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5Fxt-0007g9-US;
	Tue, 12 Feb 2013 13:32:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5Fxt-0004Ww-Sd;
	Tue, 12 Feb 2013 13:32:05 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16102-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 13:32:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16102: 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 16102 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16102/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16102
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 16102
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 16102
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16102
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16102
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16102
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16102

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install    fail blocked in 16012-bisect
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 15817 like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 12 13:39:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 13:39: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 1U5G52-0004nv-On; Tue, 12 Feb 2013 13:39:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1U5G51-0004nq-25
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 13:39:27 +0000
Received: from [85.158.139.211:33666] by server-15.bemta-5.messagelabs.com id
	E9/A9-18914-E064A115; Tue, 12 Feb 2013 13:39:26 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360676365!22116963!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31776 invoked from network); 12 Feb 2013 13:39:25 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-14.tower-206.messagelabs.com with SMTP;
	12 Feb 2013 13:39:25 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id CA403E24E5;
	Tue, 12 Feb 2013 14:37:02 +0100 (CET)
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 ezjzC7eQciX3; Tue, 12 Feb 2013 14:37:02 +0100 (CET)
Received: from [10.0.0.1] (p54BDDE0B.dip.t-dialin.net [84.189.222.11])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 12 Feb 2013 14:37:02 +0100 (CET)
Message-ID: <511A45D0.4030806@hfp.de>
Date: Tue, 12 Feb 2013 14:38:24 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: James Harper <james.harper@bendigoit.com.au>
Subject: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

What is the state of GPLPV and Windows 8? I am currently running tests 
with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look 
good. There seems to be a problem with shutdown/reboot where Windows 
hangs somewhat and displays a warning about improper shutdown on next 
reboot.

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 Feb 12 13:39:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 13:39: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 1U5G52-0004nv-On; Tue, 12 Feb 2013 13:39:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1U5G51-0004nq-25
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 13:39:27 +0000
Received: from [85.158.139.211:33666] by server-15.bemta-5.messagelabs.com id
	E9/A9-18914-E064A115; Tue, 12 Feb 2013 13:39:26 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360676365!22116963!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31776 invoked from network); 12 Feb 2013 13:39:25 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-14.tower-206.messagelabs.com with SMTP;
	12 Feb 2013 13:39:25 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id CA403E24E5;
	Tue, 12 Feb 2013 14:37:02 +0100 (CET)
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 ezjzC7eQciX3; Tue, 12 Feb 2013 14:37:02 +0100 (CET)
Received: from [10.0.0.1] (p54BDDE0B.dip.t-dialin.net [84.189.222.11])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 12 Feb 2013 14:37:02 +0100 (CET)
Message-ID: <511A45D0.4030806@hfp.de>
Date: Tue, 12 Feb 2013 14:38:24 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: James Harper <james.harper@bendigoit.com.au>
Subject: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

What is the state of GPLPV and Windows 8? I am currently running tests 
with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look 
good. There seems to be a problem with shutdown/reboot where Windows 
hangs somewhat and displays a warning about improper shutdown on next 
reboot.

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 Feb 12 13:42:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 13:42: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 1U5G7t-0004vX-Be; Tue, 12 Feb 2013 13:42:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1U5G7r-0004vO-8E
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 13:42:23 +0000
Received: from [85.158.139.211:35827] by server-10.bemta-5.messagelabs.com id
	2B/55-04697-EB64A115; Tue, 12 Feb 2013 13:42:22 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360676537!19373790!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14047 invoked from network); 12 Feb 2013 13:42:18 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-206.messagelabs.com with SMTP;
	12 Feb 2013 13:42:18 -0000
Received: from p5b2e333a.dip.t-dialin.net ([91.46.51.58] 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 1U5G7l-0004dd-7n; Tue, 12 Feb 2013 13:42:17 +0000
Message-ID: <511A46AC.5020202@canonical.com>
Date: Tue, 12 Feb 2013 14:42:04 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360603744.20449.74.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4157919901350199352=="
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)
--===============4157919901350199352==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig57AF0FB6ACE3157B505EB2A6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig57AF0FB6ACE3157B505EB2A6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11.02.2013 18:29, Ian Campbell wrote:
> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
>> A while ago I had been reporting an issue which causes Xen PVM guests
>> to hang (apparently related to spinlocks). Since then I was able to
>> gather a few more facts which I try to provide below. For the real
>> reasons, I am still puzzled and would be thankful for any hints or
>> direction.
>>
>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
>=20
> This is on a host with >=3D 8 PCPUs, correct?

Maybe >=3D4 but I cannot remember for sure anymore.
>=20
>> - When hanging at least 2 VCPUs in xen_spin_lock_slow with the lock fr=
ee.
>>   IIRC the weird lock always belongs to one VCPU runqueue.
>> - Testcase shows the problem for guest kernel versions v3.2..v3.5 (not=

>>   verified farther back). Since v3.6 it cannot be reproduced. Bisect
>>   ends up with: 611ae8e3f5204f7480b3b405993b3352cfa16662
>>     "x86/tlb: enable tlb flush range support for x86"
>=20
> That seems like a very odd candidate for impacting on this issue.
>=20
>> - The other potential fix for this was to prevent xen_spin_lock_slow()=

>>   from unmasking events (enabling interrupts) if those were enabled
>>   before the spinlock call.
>>
>> Maybe allowing or not allowing the interrupts in xen_spin_lock_slow
>> just manages to tip the likelihood of getting nested deeper.
>=20
> Either that or the bug is in the nesting aspect of xen_spin_lock_slow()=
,
> which seems to be a rather complex dance judging from the comments in
> that function (and one I confess I don't really follow).
>=20

I am suspecting something like this. Or maybe generally a nesting issue r=
evealed
by enabling interrupts here.

>>  The same
>> way that the changed TLB flush may reduce it by causing lesser IPIs.
>=20
> Ah, that might explain why that patch is relevant, yes.
>=20
>> From the static information I can extract from a dump it is hard to
>> tell what exactly is going on. VCPU2 seems to be doing something but
>> looks to be rather deep in event handling. The irq_count is at 2, but
>> irq_count seems to be used in a few more places than just xen_hypervis=
or
>> callback. Though that at least seems to be the entry on the stack I ca=
n
>> see for VCPU2. The contents of the per-cpu variables for irq_reqs and
>> irq_stack_ptr at least seem consistent as if a callback came in while
>> being on the sched_op hypercall. But then the bt command seems to be
>> operating on a completely different stack.
>> VCPU2 seems to be active, not polling (event processing could be initi=
ated
>> from enable_irqs via force callback or before finally exiting the sche=
d_op
>> hypercall), there seems to be a pending upcall but upcalls are masked.=

>> The next thing I would try is to instrument the sites incrementing and=

>> decrementing irq_count...
>> ---
>>
>> Below some of the info seen from dom0 debugging keys and looking
>> at a dump with crash:
>>
>> Dom0 Info:
>>
>> Polling vCPUs: {1,5-7}
>> VCPU0: CPU0 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU1: CPU1 [has=3DF] poll=3D10 upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU2: CPU6 [has=3DT] poll=3D0  upcall_pend =3D 01, upcall_mask =3D 01=

>> VCPU3: CPU2 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU4: CPU4 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU5: CPU3 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU6: CPU7 [has=3DF] poll=3D40 upcall_pend =3D 01, upcall_mask =3D 01=

>> VCPU7: CPU4 [has=3DF] poll=3D46 upcall_pend =3D 01, upcall_mask =3D 01=

>>
>> 10 [0/1]: s=3D6 n=3D1 x=3D0
>> 40 [0/1]: s=3D6 n=3D6 x=3D0
>> 46 [0/1]: s=3D6 n=3D7 x=3D0
>>
>> Guest Info:
>>
>> lock_spinners:
>> [0] (struct xen_spinlock *) 0x
>> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 =3D { lock=3D1, spinner=
s=3D2 }
>> [2] (struct xen_spinlock *) 0xffff8803bfc93700 =3D { lock=3D0, spinner=
s=3D2 }
>=20
> If I understand correctly this means that 2 threads (VCPU2 & 6, I
> suppose) are spinning on this lock, but no one is holding it?

To my reading both went into xen_spinlock_slow(). VCPU2 may be either in =
the
raw_local_irq_enable() before doing poll_irq or maybe in handling some ev=
ent
after receiving the wakeup irq but before returning from the hv call. So =
the
VCPU that had the lock has returned it and likely the wakeup has been sen=
t.

>=20
> An interesting hack^Wexperiment might be to make xen_poll_irq use a
> timeout and see if that unwedges things -- this would help confirm that=

> the issue is on nested wakeup.

I could do that. This would at least re-activate the other waiters. In th=
e case
shown VCPU6 and if something in the path of execution on VCPU2 deadlocks =
there
this would move things ahead.

>=20
> I suppose xen_spin_unlock could also be instrumented to indicate who it=

> last kicked and for which lock and that might show us something?

IIRC I had done this but it did not really show much. What I have done in=
 the
meantime was to instrument the IRQ service functions in
arch/x86/kernel/entry_64.S to give me a history of callbacks. This shows =
(in
another experiment where it is 1,2,5,6 in the same lock and 2,5,6 still p=
olling)
that the last events on the vcpu not polling are:

xen_do_hypervisor_callback+127
call_softirq+29
call_softirq+125
call_softirq+29
call_softirq+125
call_softirq+29
call_softirq+125
xen_do_hypervisor_callback+28
call_softirq+29
xen_do_hypervisor_callback+28

The lower offsets are when irq_count gets incremented and the higher offs=
ets are
when irq_count gets decremented before ending the callback. This shows th=
at at
least in this case there was an upcall, a softirq and another upcall bein=
g
triggered without finishing the previous one. There was another experimen=
t where
I saw softirq, upcall, upcall. But at least it seems that there is always=
 a
three level stack.
I believe that softirq, upcall would be ok as softirq processing enables
interrupts but is it expected to have an upcall interrupted by another on=
e?

>=20
> Can someone explain why the non-locked update of lock_spinners in
> spinning_lock() is safe against xen_spin_unlock reading the field from
> another VCPU? I suspect it isn't, so what happens if the other VCPU
> kicks the lock which is just about to become prev? maybe this is handle=
d
> in xen_spin_lock_slow somehow?

Isn't that safe because lock_spinners is percpu?

>=20
> In a similar vein do we not need a barrier in unspinning_lock to ensure=

> that the remote cpu sees prev getting restored?
>=20
>> [3] (struct xen_spinlock *) 0x
>> [4] (struct xen_spinlock *) 0x
>> [5] (struct xen_spinlock *) 0xffff8803bffc8ae8 -> [1]
>> [6] (struct xen_spinlock *) 0xffff8803bfc93700 -> [2]
>> [7] (struct xen_spinlock *) 0xffffffff81f15ef0 =3D { lock=3D1, spinner=
s=3D1 }
>>
>> VCPU[2,6] -> lock of runqueue[2] =3D (struct rq *) 0xffff8803bfc93700
>>
>> irq_count[1] =3D 1
>> irq_count[2] =3D 2
>> It is -1 for the rest.
>>
>> *(struct pt_regs *) irq_regs[2] =3D {
>> 	.ip =3D 0xffffffff810013aa =3D=3D hypercall_page+938 -> sched_op
>> 	.sp =3D 0xffff8803bfc83ce8
>> }
>>
>> char *irq_stack_ptr[2] =3D 0xffff8803bfc83fc0
>>
>> #> bt -T ffff88033d65c4a0
>> PID: 2050   TASK: ffff88033d65c4a0  CPU: 2   COMMAND: "postgres"
>>   [ffff88033d72d530] get_page_from_freelist at ffffffff8111e6df
>>   [ffff88033d72d600] __alloc_pages_nodemask at ffffffff8111ebec
>>   [ffff88033d72d620] check_preempt_curr at ffffffff81050254
>>   [ffff88033d72d640] pull_task at ffffffff8105e33e
>>   [ffff88033d72d670] balance_tasks at ffffffff8105e4b6
>>   [ffff88033d72d680] radix_tree_lookup_slot at ffffffff8130db5e
>>   [ffff88033d72d690] find_get_page at ffffffff811161ee
>>   [ffff88033d72d6b0] find_lock_page at ffffffff81116286
>>   [ffff88033d72d6e0] shmem_getpage_gfp at ffffffff8112dd10
>>   [ffff88033d72d748] pte_pfn_to_mfn at ffffffff81005a78
>>   [ffff88033d72d7a0] get_page_from_freelist at ffffffff8111e6df
>>   [ffff88033d72d7c0] _raw_spin_lock at ffffffff81655e4e
>>   [ffff88033d72d7d0] ext4_ext_check_cache at ffffffff81239248
>>   [ffff88033d72d820] ext4_ext_map_blocks at ffffffff8123e269
>>   [ffff88033d72d870] _raw_spin_lock at ffffffff81655e4e
>>   [ffff88033d72d880] enqueue_to_backlog at ffffffff8153e55f
>>   [ffff88033d72d890] __wake_up_common at ffffffff8104c1c8
>>   [ffff88033d72d8e0] netif_rx.part.82 at ffffffff8153f2de
>>   [ffff88033d72d920] netif_rx at ffffffff8153f400
>>   [ffff88033d72d960] loopback_xmit at ffffffff8146fb1c
>>   [ffff88033d72d990] dev_hard_start_xmit at ffffffff8153fea6
>>   [ffff88033d72d9d0] do_softirq at ffffffff81016284
>>   [ffff88033d72d9f0] local_bh_enable at ffffffff8106d614
>>   [ffff88033d72da00] dev_queue_xmit at ffffffff81540309
>>   [ffff88033d72da50] ip_finish_output at ffffffff815769ab
>>   [ffff88033d72da90] ip_output at ffffffff81577518
>>   [ffff88033d72dac0] ip_local_out at ffffffff81576c09
>>   [ffff88033d72dae0] ip_send_skb at ffffffff81577f4b
>>   [ffff88033d72db00] udp_send_skb at ffffffff8159aaa1
>>   [ffff88033d72db40] ip_generic_getfrag at ffffffff81575030
>>   [ffff88033d72db50] udp_sendmsg at ffffffff8159bd38
>>   [ffff88033d72db90] irq_to_desc at ffffffff810d70b7
>>   [ffff88033d72dbd0] notify_remote_via_irq at ffffffff813a74c1
>>   [ffff88033d72dc10] ttwu_queue at ffffffff81052672
>>   [ffff88033d72dc38] _raw_spin_unlock_irqrestore at ffffffff8165605e
>>   [ffff88033d72dc90] inet_sendmsg at ffffffff815a6474
>>   --- bt -t would end here
>>   [ffff88033d72dcb0] apparmor_socket_sendmsg at ffffffff812d43f7
>>   [ffff88033d72dcd0] sock_sendmsg at ffffffff815266fe
>>   [ffff88033d72dd70] md_make_request at ffffffff814e0606
>>   [ffff88033d72ddd0] kmem_cache_free at ffffffff811605cf
>>   [ffff88033d72de10] mempool_free_slab at ffffffff81118507
>>   [ffff88033d72de20] mempool_free at ffffffff811185b7
>>   [ffff88033d72de50] sys_sendto at ffffffff8152974d
>>   [ffff88033d72dee0] ext4_sync_file at ffffffff8120f07b
>>   [ffff88033d72df00] vfs_write at ffffffff811764b0
>>   [ffff88033d72df50] xen_hypervisor_callback at ffffffff816606db
>>     RIP: 00007f6852c7b39a  RSP: 00007fff431454e0  RFLAGS: 00000212
>>     RAX: 00007f6852fb38b8  RBX: 00007f6852fb3720  RCX: 000000000000014=
a
>>     RDX: 0000000000000150  RSI: 0000000000000140  RDI: 00007f6852fb372=
0
>>     RBP: 0000000000000150   R8: 0000000000000015   R9: 000000000000000=
0
>>     R10: 0000000000000000  R11: 00007f6852c9174a  R12: 00007f6852fb377=
8
>>     R13: 0000000000000140  R14: 00007f6852fb38b8  R15: 000000000000000=
1
>>     ORIG_RAX: ffffffffffffffff  CS: e033  SS: e02b
>>
>> #> bt -T ffff88033b812dc0
>> PID: 2069   TASK: ffff88033b812dc0  CPU: 6   COMMAND: "postgres"
>>   [ffff88033b897530] get_page_from_freelist at ffffffff8111e6df
>>   [ffff88033b897600] __alloc_pages_nodemask at ffffffff8111ebec
>>   [ffff88033b897640] radix_tree_lookup at ffffffff8130db6b
>>   [ffff88033b897650] irq_to_desc at ffffffff810d70b7
>>   [ffff88033b897660] irq_get_irq_data at ffffffff810d9f4e
>>   [ffff88033b897670] balance_tasks at ffffffff8105e493
>>   [ffff88033b897680] radix_tree_lookup_slot at ffffffff8130db5e
>>   [ffff88033b897690] find_get_page at ffffffff811161ee
>>   [ffff88033b8976b0] find_lock_page at ffffffff81116286
>>   [ffff88033b8976e0] shmem_getpage_gfp at ffffffff8112dd10
>>   [ffff88033b897748] pte_pfn_to_mfn at ffffffff81005a78
>>   [ffff88033b897770] xen_set_pte_at at ffffffff81008e29
>>   [ffff88033b897788] __raw_callee_save_xen_make_pte at ffffffff810052c=
d
>>   [ffff88033b8977b0] unlock_page at ffffffff8111589a
>>   [ffff88033b8977d0] __do_fault at ffffffff81138ac9
>>   [ffff88033b8978a0] pvclock_clocksource_read at ffffffff8103dd15
>>   [ffff88033b8978f0] xen_clocksource_read at ffffffff8100a850
>>   [ffff88033b897900] sched_clock at ffffffff8101bd79
>>   [ffff88033b897910] blk_rq_init at ffffffff812ec262
>>   [ffff88033b897930] get_request at ffffffff812f004e
>>   [ffff88033b8979c0] cpumask_next_and at ffffffff81308c66
>>   [ffff88033b8979e0] find_busiest_group at ffffffff8105a061
>>   --- bt -t ends here
>>   [ffff88033b897a30] radix_tree_lookup at ffffffff8130db6b
>>   [ffff88033b897a40] irq_to_desc at ffffffff810d70b7
>>   [ffff88033b897a50] irq_get_irq_data at ffffffff810d9f4e
>>   [ffff88033b897a60] info_for_irq at ffffffff813a636e
>>   [ffff88033b897a80] xen_poll_irq_timeout at ffffffff813a696e
>>   [ffff88033b897ac0] xen_poll_irq at ffffffff813a8450
>>   [ffff88033b897ad0] xen_spin_lock_slow at ffffffff8163ad77
>>   [ffff88033b897b20] xen_spin_lock at ffffffff810121da
>>   [ffff88033b897b40] _raw_spin_lock at ffffffff81655e4e
>>   [ffff88033b897b50] double_rq_lock at ffffffff8105119c
>>   [ffff88033b897b80] load_balance at ffffffff8105e788
>>   [ffff88033b897b88] _raw_spin_unlock_irqrestore at ffffffff8165605e
>>   [ffff88033b897c10] idle_balance at ffffffff8163d57c
>>   [ffff88033b897c60] __schedule at ffffffff81653ea9
>>   [ffff88033b897cc0] sleep_on_page at ffffffff81115810
>>   [ffff88033b897ce0] schedule at ffffffff81653fcf
>>   [ffff88033b897cf0] io_schedule at ffffffff8165407f
>>   [ffff88033b897d10] sleep_on_page at ffffffff8111581e
>>   [ffff88033b897d20] __wait_on_bit at ffffffff8165489f
>>   [ffff88033b897d70] wait_on_page_bit at ffffffff81115988
>>   [ffff88033b897da0] wake_bit_function at ffffffff8108a140
>>   [ffff88033b897dc0] filemap_fdatawait_range at ffffffff81115a9c
>>   [ffff88033b897e60] do_writepages at ffffffff81120ee1
>>   [ffff88033b897eb0] filemap_write_and_wait_range at ffffffff81117398
>>   [ffff88033b897ee0] ext4_sync_file at ffffffff8120ef9f
>>   [ffff88033b897f00] vfs_write at ffffffff811764b0
>>   [ffff88033b897f40] do_fsync at ffffffff811a4a36
>>   [ffff88033b897f70] sys_fdatasync at ffffffff811a4d83
>>   [ffff88033b897f80] system_call_fastpath at ffffffff8165e442
>>     RIP: 00007f6852ce8240  RSP: 00007fff43145618  RFLAGS: 00000246
>>     RAX: 000000000000004b  RBX: ffffffff8165e442  RCX: 00007f6852ce190=
0
>>     RDX: 00000000000000c5  RSI: 000000000000000c  RDI: 000000000000000=
c
>>     RBP: 00000000000000c5   R8: 000000000073a550   R9: 000000000000000=
0
>>     R10: 0000000000000004  R11: 0000000000000246  R12: ffffffff811a4d8=
3
>>     R13: ffff88033b897f78  R14: 0000000000000001  R15: 0000000000af748=
8
>>     ORIG_RAX: 000000000000004b  CS: e033  SS: e02b
>>




--------------enig57AF0FB6ACE3157B505EB2A6
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGka3AAoJEOhnXe7L7s6jXNwP/RLIeHMvUzmgKWHOd3yNS45/
C4KxvLaygs+pHoQsQWOKFBnHvNiT08QsIC9pWqYWz3XCMBAcZrYb/KCcN//2laIg
51hxXdPzTHAvHEOv6Jphx1th0lhthGTZXAQcAalLM8h3WaNWmOxjJvfSqDIlEoVo
Y+i+Ml8JHA5DvVGarMxgHpXj3viqO7OZHQygT/zrRbLqZ5dohru1MamdLD4KMJHA
hBvAax7fgE057KAPTBO2TN8ecYVUt1yj6YxlK6MIEL9uCMmRONSxBzpgs2DaWut8
ATA6b4nr/qOsPjFpe4XfWKIpPRT707j7EttfofVjByW9XIRVovYu9I1LBskFPuL4
z2J8I2YOrDXgGSqJFPTPMrFKspKwj403hW3ReKx5LlAC7ARHnIvOkEcBDMcUQgM9
SZmIuGqSBpDrTe2UdmH4PKQPiAPCrp72pJjym6sIy/4ok3o/dfZDepW6CMqST18K
mTbkCbuljzsWsS6jb97ao2j6+uRT4w/ZHndpiv/PVyg0y3AweK7YbmgJlnhGlblc
yERiO3qJ2H7JgexZdaG1913xTplJWruGHw1QSBW/QIbmFSZR0HGWVJZVVRWXGgLL
K/wibX+sC271//wMpqqFuVnp4GGyWYfisci5Q91UQE/YbHMw0Pg6pmhFKwmVdPLU
zSdUfSfd5ZNU9BIDu4er
=/1yu
-----END PGP SIGNATURE-----

--------------enig57AF0FB6ACE3157B505EB2A6--


--===============4157919901350199352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4157919901350199352==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 13:42:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 13:42: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 1U5G7t-0004vX-Be; Tue, 12 Feb 2013 13:42:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1U5G7r-0004vO-8E
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 13:42:23 +0000
Received: from [85.158.139.211:35827] by server-10.bemta-5.messagelabs.com id
	2B/55-04697-EB64A115; Tue, 12 Feb 2013 13:42:22 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360676537!19373790!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14047 invoked from network); 12 Feb 2013 13:42:18 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-206.messagelabs.com with SMTP;
	12 Feb 2013 13:42:18 -0000
Received: from p5b2e333a.dip.t-dialin.net ([91.46.51.58] 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 1U5G7l-0004dd-7n; Tue, 12 Feb 2013 13:42:17 +0000
Message-ID: <511A46AC.5020202@canonical.com>
Date: Tue, 12 Feb 2013 14:42:04 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360603744.20449.74.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4157919901350199352=="
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)
--===============4157919901350199352==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig57AF0FB6ACE3157B505EB2A6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig57AF0FB6ACE3157B505EB2A6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11.02.2013 18:29, Ian Campbell wrote:
> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
>> A while ago I had been reporting an issue which causes Xen PVM guests
>> to hang (apparently related to spinlocks). Since then I was able to
>> gather a few more facts which I try to provide below. For the real
>> reasons, I am still puzzled and would be thankful for any hints or
>> direction.
>>
>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
>=20
> This is on a host with >=3D 8 PCPUs, correct?

Maybe >=3D4 but I cannot remember for sure anymore.
>=20
>> - When hanging at least 2 VCPUs in xen_spin_lock_slow with the lock fr=
ee.
>>   IIRC the weird lock always belongs to one VCPU runqueue.
>> - Testcase shows the problem for guest kernel versions v3.2..v3.5 (not=

>>   verified farther back). Since v3.6 it cannot be reproduced. Bisect
>>   ends up with: 611ae8e3f5204f7480b3b405993b3352cfa16662
>>     "x86/tlb: enable tlb flush range support for x86"
>=20
> That seems like a very odd candidate for impacting on this issue.
>=20
>> - The other potential fix for this was to prevent xen_spin_lock_slow()=

>>   from unmasking events (enabling interrupts) if those were enabled
>>   before the spinlock call.
>>
>> Maybe allowing or not allowing the interrupts in xen_spin_lock_slow
>> just manages to tip the likelihood of getting nested deeper.
>=20
> Either that or the bug is in the nesting aspect of xen_spin_lock_slow()=
,
> which seems to be a rather complex dance judging from the comments in
> that function (and one I confess I don't really follow).
>=20

I am suspecting something like this. Or maybe generally a nesting issue r=
evealed
by enabling interrupts here.

>>  The same
>> way that the changed TLB flush may reduce it by causing lesser IPIs.
>=20
> Ah, that might explain why that patch is relevant, yes.
>=20
>> From the static information I can extract from a dump it is hard to
>> tell what exactly is going on. VCPU2 seems to be doing something but
>> looks to be rather deep in event handling. The irq_count is at 2, but
>> irq_count seems to be used in a few more places than just xen_hypervis=
or
>> callback. Though that at least seems to be the entry on the stack I ca=
n
>> see for VCPU2. The contents of the per-cpu variables for irq_reqs and
>> irq_stack_ptr at least seem consistent as if a callback came in while
>> being on the sched_op hypercall. But then the bt command seems to be
>> operating on a completely different stack.
>> VCPU2 seems to be active, not polling (event processing could be initi=
ated
>> from enable_irqs via force callback or before finally exiting the sche=
d_op
>> hypercall), there seems to be a pending upcall but upcalls are masked.=

>> The next thing I would try is to instrument the sites incrementing and=

>> decrementing irq_count...
>> ---
>>
>> Below some of the info seen from dom0 debugging keys and looking
>> at a dump with crash:
>>
>> Dom0 Info:
>>
>> Polling vCPUs: {1,5-7}
>> VCPU0: CPU0 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU1: CPU1 [has=3DF] poll=3D10 upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU2: CPU6 [has=3DT] poll=3D0  upcall_pend =3D 01, upcall_mask =3D 01=

>> VCPU3: CPU2 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU4: CPU4 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU5: CPU3 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D 00=

>> VCPU6: CPU7 [has=3DF] poll=3D40 upcall_pend =3D 01, upcall_mask =3D 01=

>> VCPU7: CPU4 [has=3DF] poll=3D46 upcall_pend =3D 01, upcall_mask =3D 01=

>>
>> 10 [0/1]: s=3D6 n=3D1 x=3D0
>> 40 [0/1]: s=3D6 n=3D6 x=3D0
>> 46 [0/1]: s=3D6 n=3D7 x=3D0
>>
>> Guest Info:
>>
>> lock_spinners:
>> [0] (struct xen_spinlock *) 0x
>> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 =3D { lock=3D1, spinner=
s=3D2 }
>> [2] (struct xen_spinlock *) 0xffff8803bfc93700 =3D { lock=3D0, spinner=
s=3D2 }
>=20
> If I understand correctly this means that 2 threads (VCPU2 & 6, I
> suppose) are spinning on this lock, but no one is holding it?

To my reading both went into xen_spinlock_slow(). VCPU2 may be either in =
the
raw_local_irq_enable() before doing poll_irq or maybe in handling some ev=
ent
after receiving the wakeup irq but before returning from the hv call. So =
the
VCPU that had the lock has returned it and likely the wakeup has been sen=
t.

>=20
> An interesting hack^Wexperiment might be to make xen_poll_irq use a
> timeout and see if that unwedges things -- this would help confirm that=

> the issue is on nested wakeup.

I could do that. This would at least re-activate the other waiters. In th=
e case
shown VCPU6 and if something in the path of execution on VCPU2 deadlocks =
there
this would move things ahead.

>=20
> I suppose xen_spin_unlock could also be instrumented to indicate who it=

> last kicked and for which lock and that might show us something?

IIRC I had done this but it did not really show much. What I have done in=
 the
meantime was to instrument the IRQ service functions in
arch/x86/kernel/entry_64.S to give me a history of callbacks. This shows =
(in
another experiment where it is 1,2,5,6 in the same lock and 2,5,6 still p=
olling)
that the last events on the vcpu not polling are:

xen_do_hypervisor_callback+127
call_softirq+29
call_softirq+125
call_softirq+29
call_softirq+125
call_softirq+29
call_softirq+125
xen_do_hypervisor_callback+28
call_softirq+29
xen_do_hypervisor_callback+28

The lower offsets are when irq_count gets incremented and the higher offs=
ets are
when irq_count gets decremented before ending the callback. This shows th=
at at
least in this case there was an upcall, a softirq and another upcall bein=
g
triggered without finishing the previous one. There was another experimen=
t where
I saw softirq, upcall, upcall. But at least it seems that there is always=
 a
three level stack.
I believe that softirq, upcall would be ok as softirq processing enables
interrupts but is it expected to have an upcall interrupted by another on=
e?

>=20
> Can someone explain why the non-locked update of lock_spinners in
> spinning_lock() is safe against xen_spin_unlock reading the field from
> another VCPU? I suspect it isn't, so what happens if the other VCPU
> kicks the lock which is just about to become prev? maybe this is handle=
d
> in xen_spin_lock_slow somehow?

Isn't that safe because lock_spinners is percpu?

>=20
> In a similar vein do we not need a barrier in unspinning_lock to ensure=

> that the remote cpu sees prev getting restored?
>=20
>> [3] (struct xen_spinlock *) 0x
>> [4] (struct xen_spinlock *) 0x
>> [5] (struct xen_spinlock *) 0xffff8803bffc8ae8 -> [1]
>> [6] (struct xen_spinlock *) 0xffff8803bfc93700 -> [2]
>> [7] (struct xen_spinlock *) 0xffffffff81f15ef0 =3D { lock=3D1, spinner=
s=3D1 }
>>
>> VCPU[2,6] -> lock of runqueue[2] =3D (struct rq *) 0xffff8803bfc93700
>>
>> irq_count[1] =3D 1
>> irq_count[2] =3D 2
>> It is -1 for the rest.
>>
>> *(struct pt_regs *) irq_regs[2] =3D {
>> 	.ip =3D 0xffffffff810013aa =3D=3D hypercall_page+938 -> sched_op
>> 	.sp =3D 0xffff8803bfc83ce8
>> }
>>
>> char *irq_stack_ptr[2] =3D 0xffff8803bfc83fc0
>>
>> #> bt -T ffff88033d65c4a0
>> PID: 2050   TASK: ffff88033d65c4a0  CPU: 2   COMMAND: "postgres"
>>   [ffff88033d72d530] get_page_from_freelist at ffffffff8111e6df
>>   [ffff88033d72d600] __alloc_pages_nodemask at ffffffff8111ebec
>>   [ffff88033d72d620] check_preempt_curr at ffffffff81050254
>>   [ffff88033d72d640] pull_task at ffffffff8105e33e
>>   [ffff88033d72d670] balance_tasks at ffffffff8105e4b6
>>   [ffff88033d72d680] radix_tree_lookup_slot at ffffffff8130db5e
>>   [ffff88033d72d690] find_get_page at ffffffff811161ee
>>   [ffff88033d72d6b0] find_lock_page at ffffffff81116286
>>   [ffff88033d72d6e0] shmem_getpage_gfp at ffffffff8112dd10
>>   [ffff88033d72d748] pte_pfn_to_mfn at ffffffff81005a78
>>   [ffff88033d72d7a0] get_page_from_freelist at ffffffff8111e6df
>>   [ffff88033d72d7c0] _raw_spin_lock at ffffffff81655e4e
>>   [ffff88033d72d7d0] ext4_ext_check_cache at ffffffff81239248
>>   [ffff88033d72d820] ext4_ext_map_blocks at ffffffff8123e269
>>   [ffff88033d72d870] _raw_spin_lock at ffffffff81655e4e
>>   [ffff88033d72d880] enqueue_to_backlog at ffffffff8153e55f
>>   [ffff88033d72d890] __wake_up_common at ffffffff8104c1c8
>>   [ffff88033d72d8e0] netif_rx.part.82 at ffffffff8153f2de
>>   [ffff88033d72d920] netif_rx at ffffffff8153f400
>>   [ffff88033d72d960] loopback_xmit at ffffffff8146fb1c
>>   [ffff88033d72d990] dev_hard_start_xmit at ffffffff8153fea6
>>   [ffff88033d72d9d0] do_softirq at ffffffff81016284
>>   [ffff88033d72d9f0] local_bh_enable at ffffffff8106d614
>>   [ffff88033d72da00] dev_queue_xmit at ffffffff81540309
>>   [ffff88033d72da50] ip_finish_output at ffffffff815769ab
>>   [ffff88033d72da90] ip_output at ffffffff81577518
>>   [ffff88033d72dac0] ip_local_out at ffffffff81576c09
>>   [ffff88033d72dae0] ip_send_skb at ffffffff81577f4b
>>   [ffff88033d72db00] udp_send_skb at ffffffff8159aaa1
>>   [ffff88033d72db40] ip_generic_getfrag at ffffffff81575030
>>   [ffff88033d72db50] udp_sendmsg at ffffffff8159bd38
>>   [ffff88033d72db90] irq_to_desc at ffffffff810d70b7
>>   [ffff88033d72dbd0] notify_remote_via_irq at ffffffff813a74c1
>>   [ffff88033d72dc10] ttwu_queue at ffffffff81052672
>>   [ffff88033d72dc38] _raw_spin_unlock_irqrestore at ffffffff8165605e
>>   [ffff88033d72dc90] inet_sendmsg at ffffffff815a6474
>>   --- bt -t would end here
>>   [ffff88033d72dcb0] apparmor_socket_sendmsg at ffffffff812d43f7
>>   [ffff88033d72dcd0] sock_sendmsg at ffffffff815266fe
>>   [ffff88033d72dd70] md_make_request at ffffffff814e0606
>>   [ffff88033d72ddd0] kmem_cache_free at ffffffff811605cf
>>   [ffff88033d72de10] mempool_free_slab at ffffffff81118507
>>   [ffff88033d72de20] mempool_free at ffffffff811185b7
>>   [ffff88033d72de50] sys_sendto at ffffffff8152974d
>>   [ffff88033d72dee0] ext4_sync_file at ffffffff8120f07b
>>   [ffff88033d72df00] vfs_write at ffffffff811764b0
>>   [ffff88033d72df50] xen_hypervisor_callback at ffffffff816606db
>>     RIP: 00007f6852c7b39a  RSP: 00007fff431454e0  RFLAGS: 00000212
>>     RAX: 00007f6852fb38b8  RBX: 00007f6852fb3720  RCX: 000000000000014=
a
>>     RDX: 0000000000000150  RSI: 0000000000000140  RDI: 00007f6852fb372=
0
>>     RBP: 0000000000000150   R8: 0000000000000015   R9: 000000000000000=
0
>>     R10: 0000000000000000  R11: 00007f6852c9174a  R12: 00007f6852fb377=
8
>>     R13: 0000000000000140  R14: 00007f6852fb38b8  R15: 000000000000000=
1
>>     ORIG_RAX: ffffffffffffffff  CS: e033  SS: e02b
>>
>> #> bt -T ffff88033b812dc0
>> PID: 2069   TASK: ffff88033b812dc0  CPU: 6   COMMAND: "postgres"
>>   [ffff88033b897530] get_page_from_freelist at ffffffff8111e6df
>>   [ffff88033b897600] __alloc_pages_nodemask at ffffffff8111ebec
>>   [ffff88033b897640] radix_tree_lookup at ffffffff8130db6b
>>   [ffff88033b897650] irq_to_desc at ffffffff810d70b7
>>   [ffff88033b897660] irq_get_irq_data at ffffffff810d9f4e
>>   [ffff88033b897670] balance_tasks at ffffffff8105e493
>>   [ffff88033b897680] radix_tree_lookup_slot at ffffffff8130db5e
>>   [ffff88033b897690] find_get_page at ffffffff811161ee
>>   [ffff88033b8976b0] find_lock_page at ffffffff81116286
>>   [ffff88033b8976e0] shmem_getpage_gfp at ffffffff8112dd10
>>   [ffff88033b897748] pte_pfn_to_mfn at ffffffff81005a78
>>   [ffff88033b897770] xen_set_pte_at at ffffffff81008e29
>>   [ffff88033b897788] __raw_callee_save_xen_make_pte at ffffffff810052c=
d
>>   [ffff88033b8977b0] unlock_page at ffffffff8111589a
>>   [ffff88033b8977d0] __do_fault at ffffffff81138ac9
>>   [ffff88033b8978a0] pvclock_clocksource_read at ffffffff8103dd15
>>   [ffff88033b8978f0] xen_clocksource_read at ffffffff8100a850
>>   [ffff88033b897900] sched_clock at ffffffff8101bd79
>>   [ffff88033b897910] blk_rq_init at ffffffff812ec262
>>   [ffff88033b897930] get_request at ffffffff812f004e
>>   [ffff88033b8979c0] cpumask_next_and at ffffffff81308c66
>>   [ffff88033b8979e0] find_busiest_group at ffffffff8105a061
>>   --- bt -t ends here
>>   [ffff88033b897a30] radix_tree_lookup at ffffffff8130db6b
>>   [ffff88033b897a40] irq_to_desc at ffffffff810d70b7
>>   [ffff88033b897a50] irq_get_irq_data at ffffffff810d9f4e
>>   [ffff88033b897a60] info_for_irq at ffffffff813a636e
>>   [ffff88033b897a80] xen_poll_irq_timeout at ffffffff813a696e
>>   [ffff88033b897ac0] xen_poll_irq at ffffffff813a8450
>>   [ffff88033b897ad0] xen_spin_lock_slow at ffffffff8163ad77
>>   [ffff88033b897b20] xen_spin_lock at ffffffff810121da
>>   [ffff88033b897b40] _raw_spin_lock at ffffffff81655e4e
>>   [ffff88033b897b50] double_rq_lock at ffffffff8105119c
>>   [ffff88033b897b80] load_balance at ffffffff8105e788
>>   [ffff88033b897b88] _raw_spin_unlock_irqrestore at ffffffff8165605e
>>   [ffff88033b897c10] idle_balance at ffffffff8163d57c
>>   [ffff88033b897c60] __schedule at ffffffff81653ea9
>>   [ffff88033b897cc0] sleep_on_page at ffffffff81115810
>>   [ffff88033b897ce0] schedule at ffffffff81653fcf
>>   [ffff88033b897cf0] io_schedule at ffffffff8165407f
>>   [ffff88033b897d10] sleep_on_page at ffffffff8111581e
>>   [ffff88033b897d20] __wait_on_bit at ffffffff8165489f
>>   [ffff88033b897d70] wait_on_page_bit at ffffffff81115988
>>   [ffff88033b897da0] wake_bit_function at ffffffff8108a140
>>   [ffff88033b897dc0] filemap_fdatawait_range at ffffffff81115a9c
>>   [ffff88033b897e60] do_writepages at ffffffff81120ee1
>>   [ffff88033b897eb0] filemap_write_and_wait_range at ffffffff81117398
>>   [ffff88033b897ee0] ext4_sync_file at ffffffff8120ef9f
>>   [ffff88033b897f00] vfs_write at ffffffff811764b0
>>   [ffff88033b897f40] do_fsync at ffffffff811a4a36
>>   [ffff88033b897f70] sys_fdatasync at ffffffff811a4d83
>>   [ffff88033b897f80] system_call_fastpath at ffffffff8165e442
>>     RIP: 00007f6852ce8240  RSP: 00007fff43145618  RFLAGS: 00000246
>>     RAX: 000000000000004b  RBX: ffffffff8165e442  RCX: 00007f6852ce190=
0
>>     RDX: 00000000000000c5  RSI: 000000000000000c  RDI: 000000000000000=
c
>>     RBP: 00000000000000c5   R8: 000000000073a550   R9: 000000000000000=
0
>>     R10: 0000000000000004  R11: 0000000000000246  R12: ffffffff811a4d8=
3
>>     R13: ffff88033b897f78  R14: 0000000000000001  R15: 0000000000af748=
8
>>     ORIG_RAX: 000000000000004b  CS: e033  SS: e02b
>>




--------------enig57AF0FB6ACE3157B505EB2A6
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGka3AAoJEOhnXe7L7s6jXNwP/RLIeHMvUzmgKWHOd3yNS45/
C4KxvLaygs+pHoQsQWOKFBnHvNiT08QsIC9pWqYWz3XCMBAcZrYb/KCcN//2laIg
51hxXdPzTHAvHEOv6Jphx1th0lhthGTZXAQcAalLM8h3WaNWmOxjJvfSqDIlEoVo
Y+i+Ml8JHA5DvVGarMxgHpXj3viqO7OZHQygT/zrRbLqZ5dohru1MamdLD4KMJHA
hBvAax7fgE057KAPTBO2TN8ecYVUt1yj6YxlK6MIEL9uCMmRONSxBzpgs2DaWut8
ATA6b4nr/qOsPjFpe4XfWKIpPRT707j7EttfofVjByW9XIRVovYu9I1LBskFPuL4
z2J8I2YOrDXgGSqJFPTPMrFKspKwj403hW3ReKx5LlAC7ARHnIvOkEcBDMcUQgM9
SZmIuGqSBpDrTe2UdmH4PKQPiAPCrp72pJjym6sIy/4ok3o/dfZDepW6CMqST18K
mTbkCbuljzsWsS6jb97ao2j6+uRT4w/ZHndpiv/PVyg0y3AweK7YbmgJlnhGlblc
yERiO3qJ2H7JgexZdaG1913xTplJWruGHw1QSBW/QIbmFSZR0HGWVJZVVRWXGgLL
K/wibX+sC271//wMpqqFuVnp4GGyWYfisci5Q91UQE/YbHMw0Pg6pmhFKwmVdPLU
zSdUfSfd5ZNU9BIDu4er
=/1yu
-----END PGP SIGNATURE-----

--------------enig57AF0FB6ACE3157B505EB2A6--


--===============4157919901350199352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4157919901350199352==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 14:08:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 14: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 1U5GWY-0005GQ-No; Tue, 12 Feb 2013 14:07:54 +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 1U5GWX-0005GL-4W
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 14:07:53 +0000
Received: from [85.158.137.99:59888] by server-8.bemta-3.messagelabs.com id
	47/88-25687-8BC4A115; Tue, 12 Feb 2013 14:07:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360678071!20996894!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29135 invoked from network); 12 Feb 2013 14:07:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 14:07:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1375170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 14:07: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.297.1;
	Tue, 12 Feb 2013 14:07:51 +0000
Message-ID: <1360678069.20449.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Tue, 12 Feb 2013 14:07:49 +0000
In-Reply-To: <511A46AC.5020202@canonical.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
> On 11.02.2013 18:29, Ian Campbell wrote:
> > On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
> >> A while ago I had been reporting an issue which causes Xen PVM guests
> >> to hang (apparently related to spinlocks). Since then I was able to
> >> gather a few more facts which I try to provide below. For the real
> >> reasons, I am still puzzled and would be thankful for any hints or
> >> direction.
> >>
> >> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
> >> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
> > 
> > This is on a host with >= 8 PCPUs, correct?
> 
> Maybe >=4 but I cannot remember for sure anymore.

OK, so the important point I was getting at was whether the guest was
overcommitting the host or not, it seems like it is (2xVCPUs for each
PCPU)


> >> From the static information I can extract from a dump it is hard to
> >> tell what exactly is going on. VCPU2 seems to be doing something but
> >> looks to be rather deep in event handling. The irq_count is at 2, but
> >> irq_count seems to be used in a few more places than just xen_hypervisor
> >> callback. Though that at least seems to be the entry on the stack I can
> >> see for VCPU2. The contents of the per-cpu variables for irq_reqs and
> >> irq_stack_ptr at least seem consistent as if a callback came in while
> >> being on the sched_op hypercall. But then the bt command seems to be
> >> operating on a completely different stack.
> >> VCPU2 seems to be active, not polling (event processing could be initiated
> >> from enable_irqs via force callback or before finally exiting the sched_op
> >> hypercall), there seems to be a pending upcall but upcalls are masked.
> >> The next thing I would try is to instrument the sites incrementing and
> >> decrementing irq_count...
> >> ---
> >>
> >> Below some of the info seen from dom0 debugging keys and looking
> >> at a dump with crash:
> >>
> >> Dom0 Info:
> >>
> >> Polling vCPUs: {1,5-7}
> >> VCPU0: CPU0 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU1: CPU1 [has=F] poll=10 upcall_pend = 00, upcall_mask = 00
> >> VCPU2: CPU6 [has=T] poll=0  upcall_pend = 01, upcall_mask = 01
> >> VCPU3: CPU2 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU4: CPU4 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU5: CPU3 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU6: CPU7 [has=F] poll=40 upcall_pend = 01, upcall_mask = 01
> >> VCPU7: CPU4 [has=F] poll=46 upcall_pend = 01, upcall_mask = 01
> >>
> >> 10 [0/1]: s=6 n=1 x=0
> >> 40 [0/1]: s=6 n=6 x=0
> >> 46 [0/1]: s=6 n=7 x=0
> >>
> >> Guest Info:
> >>
> >> lock_spinners:
> >> [0] (struct xen_spinlock *) 0x
> >> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 = { lock=1, spinners=2 }
> >> [2] (struct xen_spinlock *) 0xffff8803bfc93700 = { lock=0, spinners=2 }
> > 
> > If I understand correctly this means that 2 threads (VCPU2 & 6, I
> > suppose) are spinning on this lock, but no one is holding it?
> 
> To my reading both went into xen_spinlock_slow(). VCPU2 may be either in the
> raw_local_irq_enable() before doing poll_irq or maybe in handling some event
> after receiving the wakeup irq but before returning from the hv call. So the
> VCPU that had the lock has returned it and likely the wakeup has been sent.

Makes sense, so we are in the window between one holder unlocking and
the next unlocking, which explains why noone is currently holding it
(which I previously thought odd).

> > An interesting hack^Wexperiment might be to make xen_poll_irq use a
> > timeout and see if that unwedges things -- this would help confirm that
> > the issue is on nested wakeup.
> 
> I could do that. This would at least re-activate the other waiters. In the case
> shown VCPU6 and if something in the path of execution on VCPU2 deadlocks there
> this would move things ahead.

Yes, it would be interesting e.g. if only either 6 or 2 made progress
and the other remained wedged for all time.

> > I suppose xen_spin_unlock could also be instrumented to indicate who it
> > last kicked and for which lock and that might show us something?
> 
> IIRC I had done this but it did not really show much. What I have done in the
> meantime was to instrument the IRQ service functions in
> arch/x86/kernel/entry_64.S to give me a history of callbacks. This shows (in
> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 still polling)
> that the last events on the vcpu not polling are:
> 
> xen_do_hypervisor_callback+127
> call_softirq+29
> call_softirq+125
> call_softirq+29
> call_softirq+125
> call_softirq+29
> call_softirq+125
> xen_do_hypervisor_callback+28
> call_softirq+29
> xen_do_hypervisor_callback+28
> 
> The lower offsets are when irq_count gets incremented and the higher offsets are
> when irq_count gets decremented before ending the callback. This shows that at
> least in this case there was an upcall, a softirq and another upcall being
> triggered without finishing the previous one. There was another experiment where
> I saw softirq, upcall, upcall. But at least it seems that there is always a
> three level stack.
> I believe that softirq, upcall would be ok as softirq processing enables
> interrupts but is it expected to have an upcall interrupted by another one?

I'm not sure. evtchn's don't have a priority mechanism so I expect not
in general but individual interrupt handlers could well reenable
interrupts, I think (it might be one of the flags you pass when calling
request_irq?).

> > Can someone explain why the non-locked update of lock_spinners in
> > spinning_lock() is safe against xen_spin_unlock reading the field from
> > another VCPU? I suspect it isn't, so what happens if the other VCPU
> > kicks the lock which is just about to become prev? maybe this is handled
> > in xen_spin_lock_slow somehow?
> 
> Isn't that safe because lock_spinners is percpu?

xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, which
is what I think might be unsafe.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 14:08:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 14: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 1U5GWY-0005GQ-No; Tue, 12 Feb 2013 14:07:54 +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 1U5GWX-0005GL-4W
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 14:07:53 +0000
Received: from [85.158.137.99:59888] by server-8.bemta-3.messagelabs.com id
	47/88-25687-8BC4A115; Tue, 12 Feb 2013 14:07:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360678071!20996894!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29135 invoked from network); 12 Feb 2013 14:07:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 14:07:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1375170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 14:07: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.297.1;
	Tue, 12 Feb 2013 14:07:51 +0000
Message-ID: <1360678069.20449.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Tue, 12 Feb 2013 14:07:49 +0000
In-Reply-To: <511A46AC.5020202@canonical.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
> On 11.02.2013 18:29, Ian Campbell wrote:
> > On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
> >> A while ago I had been reporting an issue which causes Xen PVM guests
> >> to hang (apparently related to spinlocks). Since then I was able to
> >> gather a few more facts which I try to provide below. For the real
> >> reasons, I am still puzzled and would be thankful for any hints or
> >> direction.
> >>
> >> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
> >> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
> > 
> > This is on a host with >= 8 PCPUs, correct?
> 
> Maybe >=4 but I cannot remember for sure anymore.

OK, so the important point I was getting at was whether the guest was
overcommitting the host or not, it seems like it is (2xVCPUs for each
PCPU)


> >> From the static information I can extract from a dump it is hard to
> >> tell what exactly is going on. VCPU2 seems to be doing something but
> >> looks to be rather deep in event handling. The irq_count is at 2, but
> >> irq_count seems to be used in a few more places than just xen_hypervisor
> >> callback. Though that at least seems to be the entry on the stack I can
> >> see for VCPU2. The contents of the per-cpu variables for irq_reqs and
> >> irq_stack_ptr at least seem consistent as if a callback came in while
> >> being on the sched_op hypercall. But then the bt command seems to be
> >> operating on a completely different stack.
> >> VCPU2 seems to be active, not polling (event processing could be initiated
> >> from enable_irqs via force callback or before finally exiting the sched_op
> >> hypercall), there seems to be a pending upcall but upcalls are masked.
> >> The next thing I would try is to instrument the sites incrementing and
> >> decrementing irq_count...
> >> ---
> >>
> >> Below some of the info seen from dom0 debugging keys and looking
> >> at a dump with crash:
> >>
> >> Dom0 Info:
> >>
> >> Polling vCPUs: {1,5-7}
> >> VCPU0: CPU0 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU1: CPU1 [has=F] poll=10 upcall_pend = 00, upcall_mask = 00
> >> VCPU2: CPU6 [has=T] poll=0  upcall_pend = 01, upcall_mask = 01
> >> VCPU3: CPU2 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU4: CPU4 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU5: CPU3 [has=F] poll=0  upcall_pend = 00, upcall_mask = 00
> >> VCPU6: CPU7 [has=F] poll=40 upcall_pend = 01, upcall_mask = 01
> >> VCPU7: CPU4 [has=F] poll=46 upcall_pend = 01, upcall_mask = 01
> >>
> >> 10 [0/1]: s=6 n=1 x=0
> >> 40 [0/1]: s=6 n=6 x=0
> >> 46 [0/1]: s=6 n=7 x=0
> >>
> >> Guest Info:
> >>
> >> lock_spinners:
> >> [0] (struct xen_spinlock *) 0x
> >> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 = { lock=1, spinners=2 }
> >> [2] (struct xen_spinlock *) 0xffff8803bfc93700 = { lock=0, spinners=2 }
> > 
> > If I understand correctly this means that 2 threads (VCPU2 & 6, I
> > suppose) are spinning on this lock, but no one is holding it?
> 
> To my reading both went into xen_spinlock_slow(). VCPU2 may be either in the
> raw_local_irq_enable() before doing poll_irq or maybe in handling some event
> after receiving the wakeup irq but before returning from the hv call. So the
> VCPU that had the lock has returned it and likely the wakeup has been sent.

Makes sense, so we are in the window between one holder unlocking and
the next unlocking, which explains why noone is currently holding it
(which I previously thought odd).

> > An interesting hack^Wexperiment might be to make xen_poll_irq use a
> > timeout and see if that unwedges things -- this would help confirm that
> > the issue is on nested wakeup.
> 
> I could do that. This would at least re-activate the other waiters. In the case
> shown VCPU6 and if something in the path of execution on VCPU2 deadlocks there
> this would move things ahead.

Yes, it would be interesting e.g. if only either 6 or 2 made progress
and the other remained wedged for all time.

> > I suppose xen_spin_unlock could also be instrumented to indicate who it
> > last kicked and for which lock and that might show us something?
> 
> IIRC I had done this but it did not really show much. What I have done in the
> meantime was to instrument the IRQ service functions in
> arch/x86/kernel/entry_64.S to give me a history of callbacks. This shows (in
> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 still polling)
> that the last events on the vcpu not polling are:
> 
> xen_do_hypervisor_callback+127
> call_softirq+29
> call_softirq+125
> call_softirq+29
> call_softirq+125
> call_softirq+29
> call_softirq+125
> xen_do_hypervisor_callback+28
> call_softirq+29
> xen_do_hypervisor_callback+28
> 
> The lower offsets are when irq_count gets incremented and the higher offsets are
> when irq_count gets decremented before ending the callback. This shows that at
> least in this case there was an upcall, a softirq and another upcall being
> triggered without finishing the previous one. There was another experiment where
> I saw softirq, upcall, upcall. But at least it seems that there is always a
> three level stack.
> I believe that softirq, upcall would be ok as softirq processing enables
> interrupts but is it expected to have an upcall interrupted by another one?

I'm not sure. evtchn's don't have a priority mechanism so I expect not
in general but individual interrupt handlers could well reenable
interrupts, I think (it might be one of the flags you pass when calling
request_irq?).

> > Can someone explain why the non-locked update of lock_spinners in
> > spinning_lock() is safe against xen_spin_unlock reading the field from
> > another VCPU? I suspect it isn't, so what happens if the other VCPU
> > kicks the lock which is just about to become prev? maybe this is handled
> > in xen_spin_lock_slow somehow?
> 
> Isn't that safe because lock_spinners is percpu?

xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, which
is what I think might be unsafe.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 14:37:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 14: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 1U5GzA-0005VL-BL; Tue, 12 Feb 2013 14:37:28 +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 1U5Gz8-0005VG-DJ
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 14:37:26 +0000
Received: from [85.158.139.83:2614] by server-9.bemta-5.messagelabs.com id
	B3/5B-24440-5A35A115; Tue, 12 Feb 2013 14:37:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360679844!27537490!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 939 invoked from network); 12 Feb 2013 14:37:24 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 14:37:24 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 63AA14002E6;
	Tue, 12 Feb 2013 15:37:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iTBszLv9gzga; Tue, 12 Feb 2013 15:37:24 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 7F654400168;
	Tue, 12 Feb 2013 15:37:22 +0100 (CET)
Message-ID: <511A539D.7050503@tiscali.it>
Date: Tue, 12 Feb 2013 15:37:17 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
	<1360324253.29432.13.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360324253.29432.13.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl patches
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="===============8307524780274724379=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8307524780274724379==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090902000302000002010401"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090902000302000002010401
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 08/02/2013 12:50, Ian Campbell ha scritto:
> On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
>>> I tested spice vdagent, spice audio and spice usbredirection with qem=
u
>>> upstream and xen-unstable manually, is all working.
>>> I'm start to write some patches to have all spice features on xen 4.3=
=2E
>>>
>>> About vdagent probably no problem.
>>>
>>> About spice audio on test I actually set this variable manually:
>>>
>>> export QEMU_AUDIO_DRV=3Dspice
>>>
>>> I need know how to setup this env variable but for a given hvm domU s=
tart.
>>> In other word I need to set this env variable on a per domU basis (if=

>>> spiceaudio if setted in cfg).
>> Pass it from libxl, after all QEMU is spawned by libxl
> Setting envvars to configure qemu is a pretty crappy interface though,
> given that qemu supports both command line and configuration files for
> most other stuff. Perhaps this interface should be fixed upstream to us=
e
> the standard mechanisms first?
On qemu-devel they are saying that setting the environment variable for=20
the audio driver is not necessary because the spice audio driver is used =

by default if spice is turned on.
I also see that audio is already implemented on libxl, it is a basic=20
implementation without sanity check but working.
Tried soundhw=3D"hda" and is working, also with spice.

>
>>> About usb redirection the qemu parameters to add are similar to this:=

>>>
>>> device_model_args=3D["-readconfig","/etc/xen/ich9-ehci-uhci.cfg","-ch=
ardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev1","-device","usb-re=
dir,chardev=3Dusbredirchardev1,id=3Dusbredirdev1,bus=3Dehci.0,debug=3D3",=
"-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev2","-device","us=
b-redir,chardev=3Dusbredirchardev2,id=3Dusbredirdev2,bus=3Dehci.0,debug=3D=
3","-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev3","-device",=
"usb-redir,chardev=3Dusbredirchardev3,id=3Dusbredirdev3,bus=3Dehci.0,debu=
g=3D3"]
>>>
>>> Probably is not good point to external generic file (on my test
>>> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do=
 this?
> What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to=

> add USB passthrough as a concept in libxl so as to expose this in a mor=
e
> "libxl" like manner, instead of just cutting through the qemu options?
> (I think George also brought this up a while back).
>
> Ian.
>


--------------ms090902000302000002010401
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxMjE0MzcxN1owIwYJKoZIhvcNAQkEMRYEFDX86LnehcGlGvecMqGXyOwm
XTjBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAF7RwI9jpL941ys5BBmdgB7WS
sl0T2HPh+c3SW6QM10PEQ9AOasGx2QOPFlGLlYGvRCPzWfYZWlQQcTQ+5bzczZejWrr5cO7f
NmNyXBr/W0v9gIL9v5rnb3rvKDyCyYRK9ZAfZs4rhsD1mY4OsVMzZ0vEl4c+g/p57brf8A6j
pLFiXrLi9gZrtvCyn2m2gSRnfX0ZNzCuEdS61XY8eMJ875VRRKJ3+QoMCCfzpJgz2BcYWzTC
imB7POAWJ6sMJmLw6KbiEjO2X6aUZUP8oepJoPG5XujQXcWuWqbDqAKs3rEfWInmLvs6ldyX
QpCwSKebKNDHu2Ck0BDY1FdtIs8DQgAAAAAAAA==
--------------ms090902000302000002010401--


--===============8307524780274724379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8307524780274724379==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 14:37:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 14: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 1U5GzA-0005VL-BL; Tue, 12 Feb 2013 14:37:28 +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 1U5Gz8-0005VG-DJ
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 14:37:26 +0000
Received: from [85.158.139.83:2614] by server-9.bemta-5.messagelabs.com id
	B3/5B-24440-5A35A115; Tue, 12 Feb 2013 14:37:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360679844!27537490!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 939 invoked from network); 12 Feb 2013 14:37:24 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 14:37:24 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 63AA14002E6;
	Tue, 12 Feb 2013 15:37:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iTBszLv9gzga; Tue, 12 Feb 2013 15:37:24 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 7F654400168;
	Tue, 12 Feb 2013 15:37:22 +0100 (CET)
Message-ID: <511A539D.7050503@tiscali.it>
Date: Tue, 12 Feb 2013 15:37:17 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510A9566.7030609@tiscali.it>
	<alpine.DEB.2.02.1302081134360.4275@kaball.uk.xensource.com>
	<1360324253.29432.13.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360324253.29432.13.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Need advice to develop some libxl patches
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="===============8307524780274724379=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8307524780274724379==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090902000302000002010401"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090902000302000002010401
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 08/02/2013 12:50, Ian Campbell ha scritto:
> On Fri, 2013-02-08 at 11:36 +0000, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2013, Fabio Fantoni wrote:
>>> I tested spice vdagent, spice audio and spice usbredirection with qem=
u
>>> upstream and xen-unstable manually, is all working.
>>> I'm start to write some patches to have all spice features on xen 4.3=
=2E
>>>
>>> About vdagent probably no problem.
>>>
>>> About spice audio on test I actually set this variable manually:
>>>
>>> export QEMU_AUDIO_DRV=3Dspice
>>>
>>> I need know how to setup this env variable but for a given hvm domU s=
tart.
>>> In other word I need to set this env variable on a per domU basis (if=

>>> spiceaudio if setted in cfg).
>> Pass it from libxl, after all QEMU is spawned by libxl
> Setting envvars to configure qemu is a pretty crappy interface though,
> given that qemu supports both command line and configuration files for
> most other stuff. Perhaps this interface should be fixed upstream to us=
e
> the standard mechanisms first?
On qemu-devel they are saying that setting the environment variable for=20
the audio driver is not necessary because the spice audio driver is used =

by default if spice is turned on.
I also see that audio is already implemented on libxl, it is a basic=20
implementation without sanity check but working.
Tried soundhw=3D"hda" and is working, also with spice.

>
>>> About usb redirection the qemu parameters to add are similar to this:=

>>>
>>> device_model_args=3D["-readconfig","/etc/xen/ich9-ehci-uhci.cfg","-ch=
ardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev1","-device","usb-re=
dir,chardev=3Dusbredirchardev1,id=3Dusbredirdev1,bus=3Dehci.0,debug=3D3",=
"-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev2","-device","us=
b-redir,chardev=3Dusbredirchardev2,id=3Dusbredirdev2,bus=3Dehci.0,debug=3D=
3","-chardev","spicevmc,name=3Dusbredir,id=3Dusbredirchardev3","-device",=
"usb-redir,chardev=3Dusbredirchardev3,id=3Dusbredirdev3,bus=3Dehci.0,debu=
g=3D3"]
>>>
>>> Probably is not good point to external generic file (on my test
>>> /etc/xen/ich9-ehci-uhci.cfg), someone can tell me the best way for do=
 this?
> What does /etc/xen/ich9-ehci-uhci.cfg contain? Perhaps we might want to=

> add USB passthrough as a concept in libxl so as to expose this in a mor=
e
> "libxl" like manner, instead of just cutting through the qemu options?
> (I think George also brought this up a while back).
>
> Ian.
>


--------------ms090902000302000002010401
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxMjE0MzcxN1owIwYJKoZIhvcNAQkEMRYEFDX86LnehcGlGvecMqGXyOwm
XTjBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAF7RwI9jpL941ys5BBmdgB7WS
sl0T2HPh+c3SW6QM10PEQ9AOasGx2QOPFlGLlYGvRCPzWfYZWlQQcTQ+5bzczZejWrr5cO7f
NmNyXBr/W0v9gIL9v5rnb3rvKDyCyYRK9ZAfZs4rhsD1mY4OsVMzZ0vEl4c+g/p57brf8A6j
pLFiXrLi9gZrtvCyn2m2gSRnfX0ZNzCuEdS61XY8eMJ875VRRKJ3+QoMCCfzpJgz2BcYWzTC
imB7POAWJ6sMJmLw6KbiEjO2X6aUZUP8oepJoPG5XujQXcWuWqbDqAKs3rEfWInmLvs6ldyX
QpCwSKebKNDHu2Ck0BDY1FdtIs8DQgAAAAAAAA==
--------------ms090902000302000002010401--


--===============8307524780274724379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8307524780274724379==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 14:50:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 14:50: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 1U5HBi-0005hU-Ns; Tue, 12 Feb 2013 14:50:26 +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 1U5HBg-0005hO-SU
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 14:50:25 +0000
Received: from [85.158.138.51:57432] by server-13.bemta-3.messagelabs.com id
	6B/91-20653-FA65A115; Tue, 12 Feb 2013 14:50:23 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360680619!30300070!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13413 invoked from network); 12 Feb 2013 14:50:19 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-174.messagelabs.com with SMTP;
	12 Feb 2013 14:50:19 -0000
Received: from p5b2e333a.dip.t-dialin.net ([91.46.51.58] 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 1U5HBX-0006c1-S3; Tue, 12 Feb 2013 14:50:16 +0000
Message-ID: <511A56A5.1040305@canonical.com>
Date: Tue, 12 Feb 2013 15:50:13 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
	<1360678069.20449.169.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360678069.20449.169.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9144088592457002976=="
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)
--===============9144088592457002976==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigB330817712CDC1EA33DC055E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB330817712CDC1EA33DC055E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12.02.2013 15:07, Ian Campbell wrote:
> On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
>> On 11.02.2013 18:29, Ian Campbell wrote:
>>> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
>>>> A while ago I had been reporting an issue which causes Xen PVM guest=
s
>>>> to hang (apparently related to spinlocks). Since then I was able to
>>>> gather a few more facts which I try to provide below. For the real
>>>> reasons, I am still puzzled and would be thankful for any hints or
>>>> direction.
>>>>
>>>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
>>>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
>>>
>>> This is on a host with >=3D 8 PCPUs, correct?
>>
>> Maybe >=3D4 but I cannot remember for sure anymore.
>=20
> OK, so the important point I was getting at was whether the guest was
> overcommitting the host or not, it seems like it is (2xVCPUs for each
> PCPU)

Err not so much. I run on an 8-core host. ;)

>=20
>=20
>>>> From the static information I can extract from a dump it is hard to
>>>> tell what exactly is going on. VCPU2 seems to be doing something but=

>>>> looks to be rather deep in event handling. The irq_count is at 2, bu=
t
>>>> irq_count seems to be used in a few more places than just xen_hyperv=
isor
>>>> callback. Though that at least seems to be the entry on the stack I =
can
>>>> see for VCPU2. The contents of the per-cpu variables for irq_reqs an=
d
>>>> irq_stack_ptr at least seem consistent as if a callback came in whil=
e
>>>> being on the sched_op hypercall. But then the bt command seems to be=

>>>> operating on a completely different stack.
>>>> VCPU2 seems to be active, not polling (event processing could be ini=
tiated
>>>> from enable_irqs via force callback or before finally exiting the sc=
hed_op
>>>> hypercall), there seems to be a pending upcall but upcalls are maske=
d.
>>>> The next thing I would try is to instrument the sites incrementing a=
nd
>>>> decrementing irq_count...
>>>> ---
>>>>
>>>> Below some of the info seen from dom0 debugging keys and looking
>>>> at a dump with crash:
>>>>
>>>> Dom0 Info:
>>>>
>>>> Polling vCPUs: {1,5-7}
>>>> VCPU0: CPU0 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU1: CPU1 [has=3DF] poll=3D10 upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU2: CPU6 [has=3DT] poll=3D0  upcall_pend =3D 01, upcall_mask =3D =
01
>>>> VCPU3: CPU2 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU4: CPU4 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU5: CPU3 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU6: CPU7 [has=3DF] poll=3D40 upcall_pend =3D 01, upcall_mask =3D =
01
>>>> VCPU7: CPU4 [has=3DF] poll=3D46 upcall_pend =3D 01, upcall_mask =3D =
01
>>>>
>>>> 10 [0/1]: s=3D6 n=3D1 x=3D0
>>>> 40 [0/1]: s=3D6 n=3D6 x=3D0
>>>> 46 [0/1]: s=3D6 n=3D7 x=3D0
>>>>
>>>> Guest Info:
>>>>
>>>> lock_spinners:
>>>> [0] (struct xen_spinlock *) 0x
>>>> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 =3D { lock=3D1, spinn=
ers=3D2 }
>>>> [2] (struct xen_spinlock *) 0xffff8803bfc93700 =3D { lock=3D0, spinn=
ers=3D2 }
>>>
>>> If I understand correctly this means that 2 threads (VCPU2 & 6, I
>>> suppose) are spinning on this lock, but no one is holding it?
>>
>> To my reading both went into xen_spinlock_slow(). VCPU2 may be either =
in the
>> raw_local_irq_enable() before doing poll_irq or maybe in handling some=
 event
>> after receiving the wakeup irq but before returning from the hv call. =
So the
>> VCPU that had the lock has returned it and likely the wakeup has been =
sent.
>=20
> Makes sense, so we are in the window between one holder unlocking and
> the next unlocking, which explains why noone is currently holding it
> (which I previously thought odd).
>=20
>>> An interesting hack^Wexperiment might be to make xen_poll_irq use a
>>> timeout and see if that unwedges things -- this would help confirm th=
at
>>> the issue is on nested wakeup.
>>
>> I could do that. This would at least re-activate the other waiters. In=
 the case
>> shown VCPU6 and if something in the path of execution on VCPU2 deadloc=
ks there
>> this would move things ahead.
>=20
> Yes, it would be interesting e.g. if only either 6 or 2 made progress
> and the other remained wedged for all time.

On my list next...

>=20
>>> I suppose xen_spin_unlock could also be instrumented to indicate who =
it
>>> last kicked and for which lock and that might show us something?
>>
>> IIRC I had done this but it did not really show much. What I have done=
 in the
>> meantime was to instrument the IRQ service functions in
>> arch/x86/kernel/entry_64.S to give me a history of callbacks. This sho=
ws (in
>> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 stil=
l polling)
>> that the last events on the vcpu not polling are:
>>
>> xen_do_hypervisor_callback+127
>> call_softirq+29
>> call_softirq+125
>> call_softirq+29
>> call_softirq+125
>> call_softirq+29
>> call_softirq+125
>> xen_do_hypervisor_callback+28
>> call_softirq+29
>> xen_do_hypervisor_callback+28
>>
>> The lower offsets are when irq_count gets incremented and the higher o=
ffsets are
>> when irq_count gets decremented before ending the callback. This shows=
 that at
>> least in this case there was an upcall, a softirq and another upcall b=
eing
>> triggered without finishing the previous one. There was another experi=
ment where
>> I saw softirq, upcall, upcall. But at least it seems that there is alw=
ays a
>> three level stack.
>> I believe that softirq, upcall would be ok as softirq processing enabl=
es
>> interrupts but is it expected to have an upcall interrupted by another=
 one?
>=20
> I'm not sure. evtchn's don't have a priority mechanism so I expect not
> in general but individual interrupt handlers could well reenable
> interrupts, I think (it might be one of the flags you pass when calling=

> request_irq?).

Just a gut feeling but it feels wrong to enable interrupts in any interru=
pt
handler. I thought for anything that needs interrupts enabled and/or take=
s
longer it should pushed off to a workqueue...

>=20
>>> Can someone explain why the non-locked update of lock_spinners in
>>> spinning_lock() is safe against xen_spin_unlock reading the field fro=
m
>>> another VCPU? I suspect it isn't, so what happens if the other VCPU
>>> kicks the lock which is just about to become prev? maybe this is hand=
led
>>> in xen_spin_lock_slow somehow?
>>
>> Isn't that safe because lock_spinners is percpu?
>=20
> xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, which=

> is what I think might be unsafe.

Ah right, that. Hm, the way those two play together always was a bit brai=
n
hurting. Though somehow it feels like if the top level poll_irq would ret=
urn and
count things as spurious wakeup. I think in that case I would expect the
lock_spinner entry of one vcpu to be not matching the freed lock...
Not a really scientific argument.
>=20
> Ian.
>=20



--------------enigB330817712CDC1EA33DC055E
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGlalAAoJEOhnXe7L7s6j+1oP/08jOOODxE7u2zRq1cdxkYRJ
TXGrorgkovk7xRoRCrAyjNukRDep+hA4POyDmTiwYJkSwwTvwGTYVAprRopZS8l/
q2nt63LxJ1dLS51xSCejxwzd7bZcJWALmPWa69kJh+A9HSebTADjLtiESi5N6wM9
DJYMVlHqV++Gb3DaWsTf7KYfYqUi5H0Kqy9kXS47fKAc/u/IQGYsMILfOpnxNDLN
NqDqJAzIxtdEXlmXMCzgLLZW1O5XbYdgPp+QKUzT4UBssDgNfztUoWRDizjWHT/R
Vkyo+DnYxA+2qX3LDwF1dRy6vh6d6wY1cnPPhGI6RmqAsL00CHbk/aDhqs42yzoS
Ox30SJ38KVc65gGFPRFasgkuyOC+6QJYDm/7h9cHTOWSx4G2TtMYc5qoZrRN+Vcc
VirMbb28kP9N3FHgUYnsfcEPKAn4fN1SBQuy1oPUxlDa+u3otibSFf93Gvz2s8ld
uvmH/LK4+lfpAwCleZZxhwZKzJ9kvC5ejQ50Hq+0X6bJ7jWPYRVOB1/48U4NS8sg
rU6dfM1gU6UIj3qKu/cYHsJoZSNB5cjvHBPehz3hdTuLf7hanSocXcgRfAnKYePh
Y+FcCUDsQTKgMRCu7S2WJEgJjBPI0pD0J7jgVncK5MnOPHXwW1kzgr+UdDZsMov9
6h6Ih1ePWrbcRLTQ2/E1
=RPP+
-----END PGP SIGNATURE-----

--------------enigB330817712CDC1EA33DC055E--


--===============9144088592457002976==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9144088592457002976==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 14:50:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 14:50: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 1U5HBi-0005hU-Ns; Tue, 12 Feb 2013 14:50:26 +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 1U5HBg-0005hO-SU
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 14:50:25 +0000
Received: from [85.158.138.51:57432] by server-13.bemta-3.messagelabs.com id
	6B/91-20653-FA65A115; Tue, 12 Feb 2013 14:50:23 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360680619!30300070!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13413 invoked from network); 12 Feb 2013 14:50:19 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-174.messagelabs.com with SMTP;
	12 Feb 2013 14:50:19 -0000
Received: from p5b2e333a.dip.t-dialin.net ([91.46.51.58] 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 1U5HBX-0006c1-S3; Tue, 12 Feb 2013 14:50:16 +0000
Message-ID: <511A56A5.1040305@canonical.com>
Date: Tue, 12 Feb 2013 15:50:13 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
	<1360678069.20449.169.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360678069.20449.169.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9144088592457002976=="
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)
--===============9144088592457002976==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigB330817712CDC1EA33DC055E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB330817712CDC1EA33DC055E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12.02.2013 15:07, Ian Campbell wrote:
> On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
>> On 11.02.2013 18:29, Ian Campbell wrote:
>>> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
>>>> A while ago I had been reporting an issue which causes Xen PVM guest=
s
>>>> to hang (apparently related to spinlocks). Since then I was able to
>>>> gather a few more facts which I try to provide below. For the real
>>>> reasons, I am still puzzled and would be thankful for any hints or
>>>> direction.
>>>>
>>>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
>>>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
>>>
>>> This is on a host with >=3D 8 PCPUs, correct?
>>
>> Maybe >=3D4 but I cannot remember for sure anymore.
>=20
> OK, so the important point I was getting at was whether the guest was
> overcommitting the host or not, it seems like it is (2xVCPUs for each
> PCPU)

Err not so much. I run on an 8-core host. ;)

>=20
>=20
>>>> From the static information I can extract from a dump it is hard to
>>>> tell what exactly is going on. VCPU2 seems to be doing something but=

>>>> looks to be rather deep in event handling. The irq_count is at 2, bu=
t
>>>> irq_count seems to be used in a few more places than just xen_hyperv=
isor
>>>> callback. Though that at least seems to be the entry on the stack I =
can
>>>> see for VCPU2. The contents of the per-cpu variables for irq_reqs an=
d
>>>> irq_stack_ptr at least seem consistent as if a callback came in whil=
e
>>>> being on the sched_op hypercall. But then the bt command seems to be=

>>>> operating on a completely different stack.
>>>> VCPU2 seems to be active, not polling (event processing could be ini=
tiated
>>>> from enable_irqs via force callback or before finally exiting the sc=
hed_op
>>>> hypercall), there seems to be a pending upcall but upcalls are maske=
d.
>>>> The next thing I would try is to instrument the sites incrementing a=
nd
>>>> decrementing irq_count...
>>>> ---
>>>>
>>>> Below some of the info seen from dom0 debugging keys and looking
>>>> at a dump with crash:
>>>>
>>>> Dom0 Info:
>>>>
>>>> Polling vCPUs: {1,5-7}
>>>> VCPU0: CPU0 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU1: CPU1 [has=3DF] poll=3D10 upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU2: CPU6 [has=3DT] poll=3D0  upcall_pend =3D 01, upcall_mask =3D =
01
>>>> VCPU3: CPU2 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU4: CPU4 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU5: CPU3 [has=3DF] poll=3D0  upcall_pend =3D 00, upcall_mask =3D =
00
>>>> VCPU6: CPU7 [has=3DF] poll=3D40 upcall_pend =3D 01, upcall_mask =3D =
01
>>>> VCPU7: CPU4 [has=3DF] poll=3D46 upcall_pend =3D 01, upcall_mask =3D =
01
>>>>
>>>> 10 [0/1]: s=3D6 n=3D1 x=3D0
>>>> 40 [0/1]: s=3D6 n=3D6 x=3D0
>>>> 46 [0/1]: s=3D6 n=3D7 x=3D0
>>>>
>>>> Guest Info:
>>>>
>>>> lock_spinners:
>>>> [0] (struct xen_spinlock *) 0x
>>>> [1] (struct xen_spinlock *) 0xffff8803bffc8ae8 =3D { lock=3D1, spinn=
ers=3D2 }
>>>> [2] (struct xen_spinlock *) 0xffff8803bfc93700 =3D { lock=3D0, spinn=
ers=3D2 }
>>>
>>> If I understand correctly this means that 2 threads (VCPU2 & 6, I
>>> suppose) are spinning on this lock, but no one is holding it?
>>
>> To my reading both went into xen_spinlock_slow(). VCPU2 may be either =
in the
>> raw_local_irq_enable() before doing poll_irq or maybe in handling some=
 event
>> after receiving the wakeup irq but before returning from the hv call. =
So the
>> VCPU that had the lock has returned it and likely the wakeup has been =
sent.
>=20
> Makes sense, so we are in the window between one holder unlocking and
> the next unlocking, which explains why noone is currently holding it
> (which I previously thought odd).
>=20
>>> An interesting hack^Wexperiment might be to make xen_poll_irq use a
>>> timeout and see if that unwedges things -- this would help confirm th=
at
>>> the issue is on nested wakeup.
>>
>> I could do that. This would at least re-activate the other waiters. In=
 the case
>> shown VCPU6 and if something in the path of execution on VCPU2 deadloc=
ks there
>> this would move things ahead.
>=20
> Yes, it would be interesting e.g. if only either 6 or 2 made progress
> and the other remained wedged for all time.

On my list next...

>=20
>>> I suppose xen_spin_unlock could also be instrumented to indicate who =
it
>>> last kicked and for which lock and that might show us something?
>>
>> IIRC I had done this but it did not really show much. What I have done=
 in the
>> meantime was to instrument the IRQ service functions in
>> arch/x86/kernel/entry_64.S to give me a history of callbacks. This sho=
ws (in
>> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 stil=
l polling)
>> that the last events on the vcpu not polling are:
>>
>> xen_do_hypervisor_callback+127
>> call_softirq+29
>> call_softirq+125
>> call_softirq+29
>> call_softirq+125
>> call_softirq+29
>> call_softirq+125
>> xen_do_hypervisor_callback+28
>> call_softirq+29
>> xen_do_hypervisor_callback+28
>>
>> The lower offsets are when irq_count gets incremented and the higher o=
ffsets are
>> when irq_count gets decremented before ending the callback. This shows=
 that at
>> least in this case there was an upcall, a softirq and another upcall b=
eing
>> triggered without finishing the previous one. There was another experi=
ment where
>> I saw softirq, upcall, upcall. But at least it seems that there is alw=
ays a
>> three level stack.
>> I believe that softirq, upcall would be ok as softirq processing enabl=
es
>> interrupts but is it expected to have an upcall interrupted by another=
 one?
>=20
> I'm not sure. evtchn's don't have a priority mechanism so I expect not
> in general but individual interrupt handlers could well reenable
> interrupts, I think (it might be one of the flags you pass when calling=

> request_irq?).

Just a gut feeling but it feels wrong to enable interrupts in any interru=
pt
handler. I thought for anything that needs interrupts enabled and/or take=
s
longer it should pushed off to a workqueue...

>=20
>>> Can someone explain why the non-locked update of lock_spinners in
>>> spinning_lock() is safe against xen_spin_unlock reading the field fro=
m
>>> another VCPU? I suspect it isn't, so what happens if the other VCPU
>>> kicks the lock which is just about to become prev? maybe this is hand=
led
>>> in xen_spin_lock_slow somehow?
>>
>> Isn't that safe because lock_spinners is percpu?
>=20
> xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, which=

> is what I think might be unsafe.

Ah right, that. Hm, the way those two play together always was a bit brai=
n
hurting. Though somehow it feels like if the top level poll_irq would ret=
urn and
count things as spurious wakeup. I think in that case I would expect the
lock_spinner entry of one vcpu to be not matching the freed lock...
Not a really scientific argument.
>=20
> Ian.
>=20



--------------enigB330817712CDC1EA33DC055E
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGlalAAoJEOhnXe7L7s6j+1oP/08jOOODxE7u2zRq1cdxkYRJ
TXGrorgkovk7xRoRCrAyjNukRDep+hA4POyDmTiwYJkSwwTvwGTYVAprRopZS8l/
q2nt63LxJ1dLS51xSCejxwzd7bZcJWALmPWa69kJh+A9HSebTADjLtiESi5N6wM9
DJYMVlHqV++Gb3DaWsTf7KYfYqUi5H0Kqy9kXS47fKAc/u/IQGYsMILfOpnxNDLN
NqDqJAzIxtdEXlmXMCzgLLZW1O5XbYdgPp+QKUzT4UBssDgNfztUoWRDizjWHT/R
Vkyo+DnYxA+2qX3LDwF1dRy6vh6d6wY1cnPPhGI6RmqAsL00CHbk/aDhqs42yzoS
Ox30SJ38KVc65gGFPRFasgkuyOC+6QJYDm/7h9cHTOWSx4G2TtMYc5qoZrRN+Vcc
VirMbb28kP9N3FHgUYnsfcEPKAn4fN1SBQuy1oPUxlDa+u3otibSFf93Gvz2s8ld
uvmH/LK4+lfpAwCleZZxhwZKzJ9kvC5ejQ50Hq+0X6bJ7jWPYRVOB1/48U4NS8sg
rU6dfM1gU6UIj3qKu/cYHsJoZSNB5cjvHBPehz3hdTuLf7hanSocXcgRfAnKYePh
Y+FcCUDsQTKgMRCu7S2WJEgJjBPI0pD0J7jgVncK5MnOPHXwW1kzgr+UdDZsMov9
6h6Ih1ePWrbcRLTQ2/E1
=RPP+
-----END PGP SIGNATURE-----

--------------enigB330817712CDC1EA33DC055E--


--===============9144088592457002976==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9144088592457002976==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 15:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:00: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 1U5HKe-0005tc-0p; Tue, 12 Feb 2013 14:59:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5HKd-0005tX-1I
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 14:59:39 +0000
Received: from [85.158.138.51:2975] by server-14.bemta-3.messagelabs.com id
	1E/21-23533-AD85A115; Tue, 12 Feb 2013 14:59:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360681176!23224626!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30519 invoked from network); 12 Feb 2013 14:59:37 -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;
	12 Feb 2013 14:59:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="6817696"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	12 Feb 2013 14:59:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 12 Feb 2013 09:59:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5HKY-0004OE-T1;
	Tue, 12 Feb 2013 14:59:34 +0000
Message-ID: <1360681174.16636.71.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Tue, 12 Feb 2013 14:59:34 +0000
In-Reply-To: <51193BFE.2070808@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<511919AB.3070001@theshore.net>
	<1360601839.16636.40.camel@zion.uk.xensource.com>
	<51193BFE.2070808@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-11 at 18:44 +0000, Christopher S. Aker wrote:
> On 2/11/13 11:57 AM, Wei Liu wrote:
> > Could you post your kernel config file.
> 
> Config, syms and binaries are here:
> 
> http://www.theshore.net/~caker/xen/BUGS/netback/
> 
> Thank you for looking into this.
> 

Judging from the statements I assume this is mostly a kernel issue. It
would be better if you provide uncompressed vmlinux and symbols.

Also please add some debug printk as Ian suggested. We cannot duplicate
your setup entirely so it might be very hard to reproduce this problem.


Wei.

> -Chris
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:00: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 1U5HKe-0005tc-0p; Tue, 12 Feb 2013 14:59:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5HKd-0005tX-1I
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 14:59:39 +0000
Received: from [85.158.138.51:2975] by server-14.bemta-3.messagelabs.com id
	1E/21-23533-AD85A115; Tue, 12 Feb 2013 14:59:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360681176!23224626!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30519 invoked from network); 12 Feb 2013 14:59:37 -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;
	12 Feb 2013 14:59:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="6817696"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	12 Feb 2013 14:59:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 12 Feb 2013 09:59:35 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5HKY-0004OE-T1;
	Tue, 12 Feb 2013 14:59:34 +0000
Message-ID: <1360681174.16636.71.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Tue, 12 Feb 2013 14:59:34 +0000
In-Reply-To: <51193BFE.2070808@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<511919AB.3070001@theshore.net>
	<1360601839.16636.40.camel@zion.uk.xensource.com>
	<51193BFE.2070808@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Mon, 2013-02-11 at 18:44 +0000, Christopher S. Aker wrote:
> On 2/11/13 11:57 AM, Wei Liu wrote:
> > Could you post your kernel config file.
> 
> Config, syms and binaries are here:
> 
> http://www.theshore.net/~caker/xen/BUGS/netback/
> 
> Thank you for looking into this.
> 

Judging from the statements I assume this is mostly a kernel issue. It
would be better if you provide uncompressed vmlinux and symbols.

Also please add some debug printk as Ian suggested. We cannot duplicate
your setup entirely so it might be very hard to reproduce this problem.


Wei.

> -Chris
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:01:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:01: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 1U5HMD-00060g-Gf; Tue, 12 Feb 2013 15:01:17 +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 1U5HMB-00060Z-Iz
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 15:01:15 +0000
Received: from [85.158.143.35:41032] by server-2.bemta-4.messagelabs.com id
	F4/CE-01597-A395A115; Tue, 12 Feb 2013 15:01:14 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360681272!14857421!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22253 invoked from network); 12 Feb 2013 15:01:13 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Feb 2013 15:01:13 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 4E540E24E5;
	Tue, 12 Feb 2013 15:59:49 +0100 (CET)
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 RIfrj0Md5Psh; Tue, 12 Feb 2013 15:59:49 +0100 (CET)
Received: from [10.0.0.1] (p54BDDE0B.dip.t-dialin.net [84.189.222.11])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 12 Feb 2013 15:59:49 +0100 (CET)
Message-ID: <511A5937.3020101@hfp.de>
Date: Tue, 12 Feb 2013 16:01:11 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <511A45D0.4030806@hfp.de>
In-Reply-To: <511A45D0.4030806@hfp.de>
Cc: James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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


Maybe the WinDbg log may be helpful. Sees to have some connection to 
hibernation?


1: kd> !analyze -v
*******************************************************************************
*                                                                             
*
*                        Bugcheck 
Analysis                                    *
*                                                                             
*
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff803c5e81400, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: ffffffffffffffff, Parameter 1 of the exception

Debugging Details:
------------------


READ_ADDRESS:  ffffffffffffffff

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx 
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!memcpy+240
fffff803`c5e81400 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h]

EXCEPTION_PARAMETER2:  ffffffffffffffff

BUGCHECK_STR:  0x1E_c0000005_R

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  f

TAG_NOT_DEFINED_c000000f:  FFFFF88003622FB0

EXCEPTION_RECORD:  fffffa8003398e10 -- (.exr 0xfffffa8003398e10)
ExceptionAddress: fffffa8003398e18
    ExceptionCode: 000e0002
   ExceptionFlags: 00000001
NumberParameters: 93528968
    Parameter[0]: fffffa8005932388
    Parameter[1]: 0000000000000000
    Parameter[2]: 0000000000000100
    Parameter[3]: 0000000200000001
    Parameter[4]: 0000000000000001
    Parameter[5]: fffffa8003398e70
    Parameter[6]: 0000000fa1662b9d
    Parameter[7]: 0000000fa1662b9d
    Parameter[8]: fffffa8003398f00
    Parameter[9]: fffffa8003398f80
    Parameter[10]: 0000000000000000
    Parameter[11]: 0000000000000000
    Parameter[12]: 0000000000000000
    Parameter[13]: 0000000000000000
    Parameter[14]: 0000000000000000

LAST_CONTROL_TRANSFER:  from fffff803c5f7ddf2 to fffff803c5e86340

STACK_TEXT:
fffff880`0361a308 fffff803`c5f7ddf2 : 00000000`0000001e 
ffffffff`c0000005 fffff803`c5e81400 00000000`00000000 : nt!KeBugCheckEx
fffff880`0361a310 fffff803`c5ee68ad : fffff803`c658ac0e 
00000000`00000000 fffff880`0361a480 00000000`00000000 : 
nt!KiFatalExceptionHandler+0x22
fffff880`0361a350 fffff803`c5ee8633 : 00000000`00000000 
fffff880`03616000 00000000`00003990 fffff880`0361c000 : 
nt!RtlpExecuteHandlerForException+0xd
fffff880`0361a380 fffff803`c5f04abe : fffff880`0361b288 
fffff880`0361afc0 fffff880`0361b288 00000000`00000000 : 
nt!RtlDispatchException+0x44b
fffff880`0361aa90 fffff803`c5e85742 : fffffa80`03398e10 
fffffa80`04bd2101 fffffa80`04bd2190 00000000`00000103 : 
nt!KiDispatchException+0x455
fffff880`0361b150 fffff803`c5e83c4a : fffffa80`00000006 
56530701`00000000 00000000`00000003 00000000`00000000 : 
nt!KiExceptionDispatch+0xc2
fffff880`0361b330 fffff803`c5e81400 : fffff803`c6170a31 
00000000`00000003 00000000`00010000 fffff880`000001b9 : 
nt!KiGeneralProtectionFault+0x10a
fffff880`0361b4c8 fffff803`c6170a31 : 00000000`00000003 
00000000`00010000 fffff880`000001b9 fffff803`c617084f : nt!memcpy+0x240
fffff880`0361b4d0 fffff803`c61709a7 : fffffa80`05e00080 
fffff880`009c3101 fffffa80`047665a0 fffff880`0361b590 : 
nt!PopAddPagesToCompressedPageSet+0x5d
fffff880`0361b540 fffff803`c6173b8b : fffff880`0361b779 
fffff803`c5ebd2d6 fffffa80`05430680 fffffa80`047665a0 : 
nt!PopCompressHiberBlocks+0x87
fffff880`0361b6f0 fffff803`c658ac0e : fffffa80`03477340 
00000000`00000bb2 fffff880`009c3180 00000000`00000000 : 
nt!PopSaveHiberContext+0x7c
fffff880`0361b980 fffff803`c616b0a4 : fffffa80`04276510 
00000000`00000000 00000000`00000000 00000003`00000000 : 
hal!HaliAcpiSleep+0x54f
fffff880`0361ba10 fffff803`c616b26b : fffff803`c6093410 
fffff880`0361bbf0 fffff880`06a61b90 00000000`00f7fc98 : 
nt!PopHandleNextState+0x125
fffff880`0361ba60 fffff803`c5e7b6a8 : fffff880`009c5f00 
fffff880`009c3180 fffffa80`0410b118 fffff880`0361bca0 : 
nt!PopInvokeStateHandlerTargetProcessor+0x3c
fffff880`0361baf0 fffff803`c5ead1b0 : fffffa80`055f6980 
00000000`ffffffff fffffa80`055f6c58 00000000`00000000 : 
nt!KiExecuteAllDpcs+0x198
fffff880`0361bc30 fffff803`c5eb167a : fffff880`009c3180 
fffff880`009c3180 00000000`00000000 fffff880`009cedc0 : 
nt!KiRetireDpcList+0xd0
fffff880`0361bda0 00000000`00000000 : fffff880`0361c000 
fffff880`03616000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWUP_IP:
nt!KiFatalExceptionHandler+22
fffff803`c5f7ddf2 cc              int     3

SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt!KiFatalExceptionHandler+22
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
IMAGE_NAME:  ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP:  50ab0e64
BUCKET_ID_FUNC_OFFSET:  22
FAILURE_BUCKET_ID:  0x1E_c0000005_R_nt!KiFatalExceptionHandler
BUCKET_ID:  0x1E_c0000005_R_nt!KiFatalExceptionHandler
Followup: MachineOwner
---------



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:01:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:01: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 1U5HMD-00060g-Gf; Tue, 12 Feb 2013 15:01:17 +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 1U5HMB-00060Z-Iz
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 15:01:15 +0000
Received: from [85.158.143.35:41032] by server-2.bemta-4.messagelabs.com id
	F4/CE-01597-A395A115; Tue, 12 Feb 2013 15:01:14 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360681272!14857421!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22253 invoked from network); 12 Feb 2013 15:01:13 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Feb 2013 15:01:13 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 4E540E24E5;
	Tue, 12 Feb 2013 15:59:49 +0100 (CET)
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 RIfrj0Md5Psh; Tue, 12 Feb 2013 15:59:49 +0100 (CET)
Received: from [10.0.0.1] (p54BDDE0B.dip.t-dialin.net [84.189.222.11])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 12 Feb 2013 15:59:49 +0100 (CET)
Message-ID: <511A5937.3020101@hfp.de>
Date: Tue, 12 Feb 2013 16:01:11 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <511A45D0.4030806@hfp.de>
In-Reply-To: <511A45D0.4030806@hfp.de>
Cc: James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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


Maybe the WinDbg log may be helpful. Sees to have some connection to 
hibernation?


1: kd> !analyze -v
*******************************************************************************
*                                                                             
*
*                        Bugcheck 
Analysis                                    *
*                                                                             
*
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff803c5e81400, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: ffffffffffffffff, Parameter 1 of the exception

Debugging Details:
------------------


READ_ADDRESS:  ffffffffffffffff

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx 
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!memcpy+240
fffff803`c5e81400 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h]

EXCEPTION_PARAMETER2:  ffffffffffffffff

BUGCHECK_STR:  0x1E_c0000005_R

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  f

TAG_NOT_DEFINED_c000000f:  FFFFF88003622FB0

EXCEPTION_RECORD:  fffffa8003398e10 -- (.exr 0xfffffa8003398e10)
ExceptionAddress: fffffa8003398e18
    ExceptionCode: 000e0002
   ExceptionFlags: 00000001
NumberParameters: 93528968
    Parameter[0]: fffffa8005932388
    Parameter[1]: 0000000000000000
    Parameter[2]: 0000000000000100
    Parameter[3]: 0000000200000001
    Parameter[4]: 0000000000000001
    Parameter[5]: fffffa8003398e70
    Parameter[6]: 0000000fa1662b9d
    Parameter[7]: 0000000fa1662b9d
    Parameter[8]: fffffa8003398f00
    Parameter[9]: fffffa8003398f80
    Parameter[10]: 0000000000000000
    Parameter[11]: 0000000000000000
    Parameter[12]: 0000000000000000
    Parameter[13]: 0000000000000000
    Parameter[14]: 0000000000000000

LAST_CONTROL_TRANSFER:  from fffff803c5f7ddf2 to fffff803c5e86340

STACK_TEXT:
fffff880`0361a308 fffff803`c5f7ddf2 : 00000000`0000001e 
ffffffff`c0000005 fffff803`c5e81400 00000000`00000000 : nt!KeBugCheckEx
fffff880`0361a310 fffff803`c5ee68ad : fffff803`c658ac0e 
00000000`00000000 fffff880`0361a480 00000000`00000000 : 
nt!KiFatalExceptionHandler+0x22
fffff880`0361a350 fffff803`c5ee8633 : 00000000`00000000 
fffff880`03616000 00000000`00003990 fffff880`0361c000 : 
nt!RtlpExecuteHandlerForException+0xd
fffff880`0361a380 fffff803`c5f04abe : fffff880`0361b288 
fffff880`0361afc0 fffff880`0361b288 00000000`00000000 : 
nt!RtlDispatchException+0x44b
fffff880`0361aa90 fffff803`c5e85742 : fffffa80`03398e10 
fffffa80`04bd2101 fffffa80`04bd2190 00000000`00000103 : 
nt!KiDispatchException+0x455
fffff880`0361b150 fffff803`c5e83c4a : fffffa80`00000006 
56530701`00000000 00000000`00000003 00000000`00000000 : 
nt!KiExceptionDispatch+0xc2
fffff880`0361b330 fffff803`c5e81400 : fffff803`c6170a31 
00000000`00000003 00000000`00010000 fffff880`000001b9 : 
nt!KiGeneralProtectionFault+0x10a
fffff880`0361b4c8 fffff803`c6170a31 : 00000000`00000003 
00000000`00010000 fffff880`000001b9 fffff803`c617084f : nt!memcpy+0x240
fffff880`0361b4d0 fffff803`c61709a7 : fffffa80`05e00080 
fffff880`009c3101 fffffa80`047665a0 fffff880`0361b590 : 
nt!PopAddPagesToCompressedPageSet+0x5d
fffff880`0361b540 fffff803`c6173b8b : fffff880`0361b779 
fffff803`c5ebd2d6 fffffa80`05430680 fffffa80`047665a0 : 
nt!PopCompressHiberBlocks+0x87
fffff880`0361b6f0 fffff803`c658ac0e : fffffa80`03477340 
00000000`00000bb2 fffff880`009c3180 00000000`00000000 : 
nt!PopSaveHiberContext+0x7c
fffff880`0361b980 fffff803`c616b0a4 : fffffa80`04276510 
00000000`00000000 00000000`00000000 00000003`00000000 : 
hal!HaliAcpiSleep+0x54f
fffff880`0361ba10 fffff803`c616b26b : fffff803`c6093410 
fffff880`0361bbf0 fffff880`06a61b90 00000000`00f7fc98 : 
nt!PopHandleNextState+0x125
fffff880`0361ba60 fffff803`c5e7b6a8 : fffff880`009c5f00 
fffff880`009c3180 fffffa80`0410b118 fffff880`0361bca0 : 
nt!PopInvokeStateHandlerTargetProcessor+0x3c
fffff880`0361baf0 fffff803`c5ead1b0 : fffffa80`055f6980 
00000000`ffffffff fffffa80`055f6c58 00000000`00000000 : 
nt!KiExecuteAllDpcs+0x198
fffff880`0361bc30 fffff803`c5eb167a : fffff880`009c3180 
fffff880`009c3180 00000000`00000000 fffff880`009cedc0 : 
nt!KiRetireDpcList+0xd0
fffff880`0361bda0 00000000`00000000 : fffff880`0361c000 
fffff880`03616000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWUP_IP:
nt!KiFatalExceptionHandler+22
fffff803`c5f7ddf2 cc              int     3

SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt!KiFatalExceptionHandler+22
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
IMAGE_NAME:  ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP:  50ab0e64
BUCKET_ID_FUNC_OFFSET:  22
FAILURE_BUCKET_ID:  0x1E_c0000005_R_nt!KiFatalExceptionHandler
BUCKET_ID:  0x1E_c0000005_R_nt!KiFatalExceptionHandler
Followup: MachineOwner
---------



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:07:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:07: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 1U5HSA-0006E8-Aq; Tue, 12 Feb 2013 15: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 1U5HS9-0006E1-3u
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:07:25 +0000
Received: from [85.158.143.99:32801] by server-1.bemta-4.messagelabs.com id
	4B/6E-08839-CAA5A115; Tue, 12 Feb 2013 15:07:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360681643!24326319!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6400 invoked from network); 12 Feb 2013 15:07:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:07:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1377997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:07: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.297.1;
	Tue, 12 Feb 2013 15:07:23 +0000
Message-ID: <1360681641.20449.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Tue, 12 Feb 2013 15:07:21 +0000
In-Reply-To: <511A56A5.1040305@canonical.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
	<1360678069.20449.169.camel@zakaz.uk.xensource.com>
	<511A56A5.1040305@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 14:50 +0000, Stefan Bader wrote:
> On 12.02.2013 15:07, Ian Campbell wrote:
> > On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
> >> On 11.02.2013 18:29, Ian Campbell wrote:
> >>> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
> >>>> A while ago I had been reporting an issue which causes Xen PVM guests
> >>>> to hang (apparently related to spinlocks). Since then I was able to
> >>>> gather a few more facts which I try to provide below. For the real
> >>>> reasons, I am still puzzled and would be thankful for any hints or
> >>>> direction.
> >>>>
> >>>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
> >>>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
> >>>
> >>> This is on a host with >= 8 PCPUs, correct?
> >>
> >> Maybe >=4 but I cannot remember for sure anymore.
> > 
> > OK, so the important point I was getting at was whether the guest was
> > overcommitting the host or not, it seems like it is (2xVCPUs for each
> > PCPU)
> 
> Err not so much. I run on an 8-core host. ;)

Um, which is what I asked. What is >= 4 then?


> > 
> >>> I suppose xen_spin_unlock could also be instrumented to indicate who it
> >>> last kicked and for which lock and that might show us something?
> >>
> >> IIRC I had done this but it did not really show much. What I have done in the
> >> meantime was to instrument the IRQ service functions in
> >> arch/x86/kernel/entry_64.S to give me a history of callbacks. This shows (in
> >> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 still polling)
> >> that the last events on the vcpu not polling are:
> >>
> >> xen_do_hypervisor_callback+127
> >> call_softirq+29
> >> call_softirq+125
> >> call_softirq+29
> >> call_softirq+125
> >> call_softirq+29
> >> call_softirq+125
> >> xen_do_hypervisor_callback+28
> >> call_softirq+29
> >> xen_do_hypervisor_callback+28
> >>
> >> The lower offsets are when irq_count gets incremented and the higher offsets are
> >> when irq_count gets decremented before ending the callback. This shows that at
> >> least in this case there was an upcall, a softirq and another upcall being
> >> triggered without finishing the previous one. There was another experiment where
> >> I saw softirq, upcall, upcall. But at least it seems that there is always a
> >> three level stack.
> >> I believe that softirq, upcall would be ok as softirq processing enables
> >> interrupts but is it expected to have an upcall interrupted by another one?
> > 
> > I'm not sure. evtchn's don't have a priority mechanism so I expect not
> > in general but individual interrupt handlers could well reenable
> > interrupts, I think (it might be one of the flags you pass when calling
> > request_irq?).
> 
> Just a gut feeling but it feels wrong to enable interrupts in any interrupt
> handler. I thought for anything that needs interrupts enabled and/or takes
> longer it should pushed off to a workqueue...

Either that or some sort of interrupt prioritisation mechanism in the
hardware so only higher priority interrupts than the current one will
occur.

> 
> > 
> >>> Can someone explain why the non-locked update of lock_spinners in
> >>> spinning_lock() is safe against xen_spin_unlock reading the field from
> >>> another VCPU? I suspect it isn't, so what happens if the other VCPU
> >>> kicks the lock which is just about to become prev? maybe this is handled
> >>> in xen_spin_lock_slow somehow?
> >>
> >> Isn't that safe because lock_spinners is percpu?
> > 
> > xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, which
> > is what I think might be unsafe.
> 
> Ah right, that. Hm, the way those two play together always was a bit brain
> hurting.

Yes...

>  Though somehow it feels like if the top level poll_irq would return and
> count things as spurious wakeup. I think in that case I would expect the
> lock_spinner entry of one vcpu to be not matching the freed lock...
> Not a really scientific argument.

Adding a BUG_ON(__this_cpu_write(lock_spinners) != xl) in
unspinning_lock might be interesting?

I wonder if this is something where the ftrace and related kernel
infrastructure might be useful?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:07:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:07: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 1U5HSA-0006E8-Aq; Tue, 12 Feb 2013 15: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 1U5HS9-0006E1-3u
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:07:25 +0000
Received: from [85.158.143.99:32801] by server-1.bemta-4.messagelabs.com id
	4B/6E-08839-CAA5A115; Tue, 12 Feb 2013 15:07:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360681643!24326319!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6400 invoked from network); 12 Feb 2013 15:07:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:07:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1377997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:07: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.297.1;
	Tue, 12 Feb 2013 15:07:23 +0000
Message-ID: <1360681641.20449.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Tue, 12 Feb 2013 15:07:21 +0000
In-Reply-To: <511A56A5.1040305@canonical.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
	<1360678069.20449.169.camel@zakaz.uk.xensource.com>
	<511A56A5.1040305@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 14:50 +0000, Stefan Bader wrote:
> On 12.02.2013 15:07, Ian Campbell wrote:
> > On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
> >> On 11.02.2013 18:29, Ian Campbell wrote:
> >>> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
> >>>> A while ago I had been reporting an issue which causes Xen PVM guests
> >>>> to hang (apparently related to spinlocks). Since then I was able to
> >>>> gather a few more facts which I try to provide below. For the real
> >>>> reasons, I am still puzzled and would be thankful for any hints or
> >>>> direction.
> >>>>
> >>>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
> >>>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
> >>>
> >>> This is on a host with >= 8 PCPUs, correct?
> >>
> >> Maybe >=4 but I cannot remember for sure anymore.
> > 
> > OK, so the important point I was getting at was whether the guest was
> > overcommitting the host or not, it seems like it is (2xVCPUs for each
> > PCPU)
> 
> Err not so much. I run on an 8-core host. ;)

Um, which is what I asked. What is >= 4 then?


> > 
> >>> I suppose xen_spin_unlock could also be instrumented to indicate who it
> >>> last kicked and for which lock and that might show us something?
> >>
> >> IIRC I had done this but it did not really show much. What I have done in the
> >> meantime was to instrument the IRQ service functions in
> >> arch/x86/kernel/entry_64.S to give me a history of callbacks. This shows (in
> >> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 still polling)
> >> that the last events on the vcpu not polling are:
> >>
> >> xen_do_hypervisor_callback+127
> >> call_softirq+29
> >> call_softirq+125
> >> call_softirq+29
> >> call_softirq+125
> >> call_softirq+29
> >> call_softirq+125
> >> xen_do_hypervisor_callback+28
> >> call_softirq+29
> >> xen_do_hypervisor_callback+28
> >>
> >> The lower offsets are when irq_count gets incremented and the higher offsets are
> >> when irq_count gets decremented before ending the callback. This shows that at
> >> least in this case there was an upcall, a softirq and another upcall being
> >> triggered without finishing the previous one. There was another experiment where
> >> I saw softirq, upcall, upcall. But at least it seems that there is always a
> >> three level stack.
> >> I believe that softirq, upcall would be ok as softirq processing enables
> >> interrupts but is it expected to have an upcall interrupted by another one?
> > 
> > I'm not sure. evtchn's don't have a priority mechanism so I expect not
> > in general but individual interrupt handlers could well reenable
> > interrupts, I think (it might be one of the flags you pass when calling
> > request_irq?).
> 
> Just a gut feeling but it feels wrong to enable interrupts in any interrupt
> handler. I thought for anything that needs interrupts enabled and/or takes
> longer it should pushed off to a workqueue...

Either that or some sort of interrupt prioritisation mechanism in the
hardware so only higher priority interrupts than the current one will
occur.

> 
> > 
> >>> Can someone explain why the non-locked update of lock_spinners in
> >>> spinning_lock() is safe against xen_spin_unlock reading the field from
> >>> another VCPU? I suspect it isn't, so what happens if the other VCPU
> >>> kicks the lock which is just about to become prev? maybe this is handled
> >>> in xen_spin_lock_slow somehow?
> >>
> >> Isn't that safe because lock_spinners is percpu?
> > 
> > xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, which
> > is what I think might be unsafe.
> 
> Ah right, that. Hm, the way those two play together always was a bit brain
> hurting.

Yes...

>  Though somehow it feels like if the top level poll_irq would return and
> count things as spurious wakeup. I think in that case I would expect the
> lock_spinner entry of one vcpu to be not matching the freed lock...
> Not a really scientific argument.

Adding a BUG_ON(__this_cpu_write(lock_spinners) != xl) in
unspinning_lock might be interesting?

I wonder if this is something where the ftrace and related kernel
infrastructure might be useful?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:26:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5HkF-0006Uo-8e; Tue, 12 Feb 2013 15:26:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U5HkE-0006Uj-1J
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:26:06 +0000
Received: from [85.158.138.51:35909] by server-10.bemta-3.messagelabs.com id
	30/B6-10609-80F5A115; Tue, 12 Feb 2013 15:26:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360682757!23819792!1
X-Originating-IP: [141.146.126.70]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	UNPARSEABLE_RELAY,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 12 Feb 2013 15:25:58 -0000
Received: from aserp1050.oracle.com (HELO aserp1050.oracle.com)
	(141.146.126.70)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 15:25:58 -0000
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69])
	by aserp1050.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFPtHb017600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 15:25:56 GMT
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFKr2L002387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 15:20:54 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
	r1CFKqma023078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 15:20:52 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
	r1CFKoW3024161; Tue, 12 Feb 2013 09:20:52 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-157.usdhcp.oraclecorp.com
	(/10.152.55.156) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 07:20:50 -0800
Message-ID: <511A5DC3.4010106@oracle.com>
Date: Tue, 12 Feb 2013 10:20:35 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
In-Reply-To: <511A35C402000078000BDB47@nat28.tlf.novell.com>
X-Source-IP: aserp1040.oracle.com [141.146.126.69]
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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-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/12/2013 06:29 AM, Jan Beulich wrote:
>>>> On 12.02.13 at 12:22, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 12.02.13 at 12:15, povder <povder@gmail.com> wrote:
>>> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>>> With the above, the patch is unlikely to address your problem,
>>>> but will likely provide better debugging output. So please
>>>> nevertheless try building with that patch included, assuming
>>>> the problem first started after you built Xen from a recent
>>>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
>>>> case the problem is obviously unrelated to the recent changes
>>>> I'm thinking of).
>>>>
>>> I haven't built Xen myself, I use binaries from
>>> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
>>> that builds in this repository are from plain 4.2.1.
>>> xl info (when I boot with iommu disabled) shows:
>>> xen_major              : 4
>>> xen_minor              : 2
>>> xen_extra              : .1
>>>
>>> I just started using Xen when 4.2.1 already was released so this
>>> problem appeared to me from the beginning. I can try with 4.2-testing
>>> though.
>> No, there's no point I'm afraid. We really need to analyze the
>> debugging output to first understand what's missing.
> All there is for bus 7 is
>
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x700
> (XEN) AMD-Vi:  Flags 0x0
>
> i.e. a single device at 07:00.0, yet from the register dump at the
> crash it's fairly clear that we're talking about 07:00.1 here. I'm
> afraid only a firmware update can help you here (or passing
> "iommu=off" to Xen); in particular I can't see how we could work
> around that problem in software.

I don't see any devices on bus 7 in lspci output 
(http://pastebin.com/raw.php?i=3wpKPQT9 from original report).

However the log shows

pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
..
(XEN) PCI add device 0000:07:00.0



-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:26:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5HkF-0006Uo-8e; Tue, 12 Feb 2013 15:26:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U5HkE-0006Uj-1J
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:26:06 +0000
Received: from [85.158.138.51:35909] by server-10.bemta-3.messagelabs.com id
	30/B6-10609-80F5A115; Tue, 12 Feb 2013 15:26:00 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360682757!23819792!1
X-Originating-IP: [141.146.126.70]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	UNPARSEABLE_RELAY,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 12 Feb 2013 15:25:58 -0000
Received: from aserp1050.oracle.com (HELO aserp1050.oracle.com)
	(141.146.126.70)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 15:25:58 -0000
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69])
	by aserp1050.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFPtHb017600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 15:25:56 GMT
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFKr2L002387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 15:20:54 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
	r1CFKqma023078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 15:20:52 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
	r1CFKoW3024161; Tue, 12 Feb 2013 09:20:52 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-157.usdhcp.oraclecorp.com
	(/10.152.55.156) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 07:20:50 -0800
Message-ID: <511A5DC3.4010106@oracle.com>
Date: Tue, 12 Feb 2013 10:20:35 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
In-Reply-To: <511A35C402000078000BDB47@nat28.tlf.novell.com>
X-Source-IP: aserp1040.oracle.com [141.146.126.69]
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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-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/12/2013 06:29 AM, Jan Beulich wrote:
>>>> On 12.02.13 at 12:22, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 12.02.13 at 12:15, povder <povder@gmail.com> wrote:
>>> 2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>>> With the above, the patch is unlikely to address your problem,
>>>> but will likely provide better debugging output. So please
>>>> nevertheless try building with that patch included, assuming
>>>> the problem first started after you built Xen from a recent
>>>> 4.2-testing tree (as opposed to this being plain 4.2.1, in which
>>>> case the problem is obviously unrelated to the recent changes
>>>> I'm thinking of).
>>>>
>>> I haven't built Xen myself, I use binaries from
>>> http://au1.mirror.crc.id.au/repo/el6/x86_64/ repository and I guess
>>> that builds in this repository are from plain 4.2.1.
>>> xl info (when I boot with iommu disabled) shows:
>>> xen_major              : 4
>>> xen_minor              : 2
>>> xen_extra              : .1
>>>
>>> I just started using Xen when 4.2.1 already was released so this
>>> problem appeared to me from the beginning. I can try with 4.2-testing
>>> though.
>> No, there's no point I'm afraid. We really need to analyze the
>> debugging output to first understand what's missing.
> All there is for bus 7 is
>
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x700
> (XEN) AMD-Vi:  Flags 0x0
>
> i.e. a single device at 07:00.0, yet from the register dump at the
> crash it's fairly clear that we're talking about 07:00.1 here. I'm
> afraid only a firmware update can help you here (or passing
> "iommu=off" to Xen); in particular I can't see how we could work
> around that problem in software.

I don't see any devices on bus 7 in lspci output 
(http://pastebin.com/raw.php?i=3wpKPQT9 from original report).

However the log shows

pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
..
(XEN) PCI add device 0000:07:00.0



-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:32: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 1U5Hq1-0006g3-3j; Tue, 12 Feb 2013 15:32:05 +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 1U5Hpz-0006fw-S1
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:32:03 +0000
Received: from [85.158.138.51:56144] by server-14.bemta-3.messagelabs.com id
	89/F9-23533-2706A115; Tue, 12 Feb 2013 15:32:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360683122!21848114!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2862 invoked from network); 12 Feb 2013 15:32:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:32:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:32: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.297.1; Tue, 12 Feb 2013 15:32:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hpx-0008Pc-Pc; Tue, 12 Feb 2013 15:32:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hpx-0004Nw-LJ;
	Tue, 12 Feb 2013 15:32:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24689.570182.129974@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:32:01 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-3-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
	enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> This value from libxl__json_node_type is never used.

We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
needs to remain frozen.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:32: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 1U5Hq1-0006g3-3j; Tue, 12 Feb 2013 15:32:05 +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 1U5Hpz-0006fw-S1
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:32:03 +0000
Received: from [85.158.138.51:56144] by server-14.bemta-3.messagelabs.com id
	89/F9-23533-2706A115; Tue, 12 Feb 2013 15:32:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360683122!21848114!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2862 invoked from network); 12 Feb 2013 15:32:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:32:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:32: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.297.1; Tue, 12 Feb 2013 15:32:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hpx-0008Pc-Pc; Tue, 12 Feb 2013 15:32:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hpx-0004Nw-LJ;
	Tue, 12 Feb 2013 15:32:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24689.570182.129974@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:32:01 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-3-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
	enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> This value from libxl__json_node_type is never used.

We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
needs to remain frozen.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:34:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:34: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 1U5HsH-0006le-LC; Tue, 12 Feb 2013 15:34: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 1U5HsF-0006lX-Ti
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:34:24 +0000
Received: from [85.158.139.211:5544] by server-5.bemta-5.messagelabs.com id
	13/26-11945-EF06A115; Tue, 12 Feb 2013 15:34:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360683255!19444174!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8223 invoked from network); 12 Feb 2013 15:34:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:34: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.297.1; Tue, 12 Feb 2013 15:34:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hs6-0008QI-RM; Tue, 12 Feb 2013 15:34:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hs6-0004OL-Nb;
	Tue, 12 Feb 2013 15:34:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24822.614162.510363@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:34:14 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] QEMU: Enabling live-migrate on HVM on qemu-xen
	device	model in 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

Alex Bligh writes ("[Xen-devel] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2"):
> This patch series consists of 2	parts:
> * 11 patches to	libxl
> 
> These patches enable live-migrate on HVM using the upstream qemu-xen
> device model under Xen 4.2. Currently this is unimplemented. In	the
> main they are backports	    of patches in xen-unstable, thought the
> QEMU side in particular	    needed some fiddling.

I think we should consider this when all of the required patches are
either backports from unstable, or for exceptional cases where there
is some reason why a particular patch can't or shouldn't go via
unstable.

I'll make substantive comment on the individual patches.

(Your text formatting is a bit odd.)

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 Feb 12 15:34:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:34: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 1U5HsH-0006le-LC; Tue, 12 Feb 2013 15:34: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 1U5HsF-0006lX-Ti
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:34:24 +0000
Received: from [85.158.139.211:5544] by server-5.bemta-5.messagelabs.com id
	13/26-11945-EF06A115; Tue, 12 Feb 2013 15:34:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360683255!19444174!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8223 invoked from network); 12 Feb 2013 15:34:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:34: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.297.1; Tue, 12 Feb 2013 15:34:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hs6-0008QI-RM; Tue, 12 Feb 2013 15:34:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hs6-0004OL-Nb;
	Tue, 12 Feb 2013 15:34:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24822.614162.510363@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:34:14 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] QEMU: Enabling live-migrate on HVM on qemu-xen
	device	model in 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

Alex Bligh writes ("[Xen-devel] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2"):
> This patch series consists of 2	parts:
> * 11 patches to	libxl
> 
> These patches enable live-migrate on HVM using the upstream qemu-xen
> device model under Xen 4.2. Currently this is unimplemented. In	the
> main they are backports	    of patches in xen-unstable, thought the
> QEMU side in particular	    needed some fiddling.

I think we should consider this when all of the required patches are
either backports from unstable, or for exceptional cases where there
is some reason why a particular patch can't or shouldn't go via
unstable.

I'll make substantive comment on the individual patches.

(Your text formatting is a bit odd.)

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 Feb 12 15:36:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:36: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 1U5HuB-0006uO-BP; Tue, 12 Feb 2013 15:36: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 1U5HuA-0006uJ-At
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:36:22 +0000
Received: from [85.158.143.99:15499] by server-1.bemta-4.messagelabs.com id
	B5/3D-08839-5716A115; Tue, 12 Feb 2013 15:36:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360683379!19014625!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13922 invoked from network); 12 Feb 2013 15:36:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:36: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.297.1; Tue, 12 Feb 2013 15:36:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hu6-0008Qw-Ru; Tue, 12 Feb 2013 15:36:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hu6-0004Oq-Nd;
	Tue, 12 Feb 2013 15:36:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24946.487122.307260@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:36:18 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-12-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-12-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] libxl: libxl__qmp_save: Add filename
	as	JSON parameter to xen-save-devices-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

Alex Bligh writes ("[Xen-devel] [PATCH 11/11] libxl: libxl__qmp_save: Add filename as JSON parameter to xen-save-devices-state"):
> +    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
>      return qmp_run_command(gc, domid, "xen-save-devices-state", args,
>                             NULL, NULL);

This looks plausible.

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 Feb 12 15:36:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:36: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 1U5HuB-0006uO-BP; Tue, 12 Feb 2013 15:36: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 1U5HuA-0006uJ-At
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:36:22 +0000
Received: from [85.158.143.99:15499] by server-1.bemta-4.messagelabs.com id
	B5/3D-08839-5716A115; Tue, 12 Feb 2013 15:36:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360683379!19014625!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13922 invoked from network); 12 Feb 2013 15:36:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:36: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.297.1; Tue, 12 Feb 2013 15:36:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hu6-0008Qw-Ru; Tue, 12 Feb 2013 15:36:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hu6-0004Oq-Nd;
	Tue, 12 Feb 2013 15:36:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24946.487122.307260@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:36:18 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-12-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-12-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] libxl: libxl__qmp_save: Add filename
	as	JSON parameter to xen-save-devices-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

Alex Bligh writes ("[Xen-devel] [PATCH 11/11] libxl: libxl__qmp_save: Add filename as JSON parameter to xen-save-devices-state"):
> +    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
>      return qmp_run_command(gc, domid, "xen-save-devices-state", args,
>                             NULL, NULL);

This looks plausible.

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 Feb 12 15:37:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:37: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 1U5Hv5-0006zM-QJ; Tue, 12 Feb 2013 15:37: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 1U5Hv4-0006z7-2k
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:37:18 +0000
Received: from [85.158.139.83:4726] by server-13.bemta-5.messagelabs.com id
	DF/B8-06769-DA16A115; Tue, 12 Feb 2013 15:37:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360683430!24963399!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11192 invoked from network); 12 Feb 2013 15:37:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:37:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15: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.297.1; Tue, 12 Feb 2013 15:37:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Huu-0008RD-Mq; Tue, 12 Feb 2013 15:37:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Huu-0004Ow-J8;
	Tue, 12 Feb 2013 15:37:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24996.486162.373451@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:37:08 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-10-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-10-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/11] libxl_dom: Call the right switch
	logdirty	for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 09/11] libxl_dom: Call the right switch logdirty for the right DM."):
> This patch dispatch the switch logdirty call depending on which device model
> version is running.
> 
> The call to qemu-xen right now is synchronous, not like the one to
> qemu-xen-traditional.
> 
> Backport of xen-unstable patch:

This backport will be fine when we have the whole series to put in.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:37:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:37: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 1U5Hv5-0006zM-QJ; Tue, 12 Feb 2013 15:37: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 1U5Hv4-0006z7-2k
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:37:18 +0000
Received: from [85.158.139.83:4726] by server-13.bemta-5.messagelabs.com id
	DF/B8-06769-DA16A115; Tue, 12 Feb 2013 15:37:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360683430!24963399!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11192 invoked from network); 12 Feb 2013 15:37:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:37:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15: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.297.1; Tue, 12 Feb 2013 15:37:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Huu-0008RD-Mq; Tue, 12 Feb 2013 15:37:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Huu-0004Ow-J8;
	Tue, 12 Feb 2013 15:37:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.24996.486162.373451@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:37:08 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-10-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-10-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 09/11] libxl_dom: Call the right switch
	logdirty	for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 09/11] libxl_dom: Call the right switch logdirty for the right DM."):
> This patch dispatch the switch logdirty call depending on which device model
> version is running.
> 
> The call to qemu-xen right now is synchronous, not like the one to
> qemu-xen-traditional.
> 
> Backport of xen-unstable patch:

This backport will be fine when we have the whole series to put in.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:38:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5Hvn-00074S-80; Tue, 12 Feb 2013 15:38: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 1U5Hvl-000747-C0
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:38:01 +0000
Received: from [85.158.143.99:38017] by server-3.bemta-4.messagelabs.com id
	6A/76-08920-8D16A115; Tue, 12 Feb 2013 15:38:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360683480!24456604!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23441 invoked from network); 12 Feb 2013 15:38:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15: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.297.1; Tue, 12 Feb 2013 15:38:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hvj-0008RU-Ur; Tue, 12 Feb 2013 15:37:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hvj-0004P5-QO;
	Tue, 12 Feb 2013 15:37:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25047.686468.319085@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:37:59 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-11-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 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

Alex Bligh writes ("[Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> Backport of xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693136 -3600
> : Node ID 0995890022391682a2499a202c3c8608e1d3780a
> : Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369

This backport is fine but needs to come at the end of the series, I
think ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:38:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5Hvn-00074S-80; Tue, 12 Feb 2013 15:38: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 1U5Hvl-000747-C0
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:38:01 +0000
Received: from [85.158.143.99:38017] by server-3.bemta-4.messagelabs.com id
	6A/76-08920-8D16A115; Tue, 12 Feb 2013 15:38:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360683480!24456604!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23441 invoked from network); 12 Feb 2013 15:38:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15: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.297.1; Tue, 12 Feb 2013 15:38:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hvj-0008RU-Ur; Tue, 12 Feb 2013 15:37:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hvj-0004P5-QO;
	Tue, 12 Feb 2013 15:37:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25047.686468.319085@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:37:59 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-11-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 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

Alex Bligh writes ("[Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> Backport of xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693136 -3600
> : Node ID 0995890022391682a2499a202c3c8608e1d3780a
> : Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369

This backport is fine but needs to come at the end of the series, I
think ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:39:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5Hwi-0007CI-NM; Tue, 12 Feb 2013 15:39:00 +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 1U5Hwh-0007C2-IP
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:38:59 +0000
Received: from [85.158.139.83:26997] by server-5.bemta-5.messagelabs.com id
	F6/3E-11945-2126A115; Tue, 12 Feb 2013 15:38:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360683536!31535618!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjcyODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23590 invoked from network); 12 Feb 2013 15:38:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 15:38:58 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFckub031155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 15:38:47 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
	r1CFciqq028200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 15:38:45 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
	r1CFciqK006974; Tue, 12 Feb 2013 09:38:44 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 07:38:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B4C81BF781; Tue, 12 Feb 2013 10:38:42 -0500 (EST)
Date: Tue, 12 Feb 2013 10:38:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Scott <Dave.Scott@eu.citrix.com>
Message-ID: <20130212153842.GF3016@phenom.dumpdata.com>
References: <mailman.18000.1354568068.1399.xen-devel@lists.xen.org>
	<49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca>
	<20121218221749.GA6332@phenom.dumpdata.com>
	<50D1B8D0.4020500@eu.citrix.com>
	<20130102215901.GA16093@phenom.dumpdata.com>
	<50F44E60.4090904@eu.citrix.com>
	<20130122215748.GA14146@phenom.dumpdata.com>
	<81A73678E76EA642801C8F2E4823AD21014183065D37@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21014183065D37@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 23, 2013 at 06:36:06PM +0000, Dave Scott wrote:
> Hi,
> 
> > On Mon, Jan 14, 2013 at 06:28:48PM +0000, George Dunlap wrote:
> > > I'm not fluent in OCaml either, I'm mainly going from memory based on
> > > the discussions I had with the author when it was being designed, as
> > > well as discussions with the xapi team when dealing with bugs at later
> > > points.
> 
> Konrad Rzeszutek Wilk replied:
> 
> > I was looking at xen-api/ocaml/xenops/squeeze.ml and just reading the
> > comments and feebly trying to understand how the OCaml code is.
> > Best I could understand it does various measurements, makes the
> > appropiate hypercalls and waits for everything to stabilize before allowing
> > the guest to start.
> > 
> > N.B: With tmem, the 'stabilization' might never happen.
> 
> In case it's useful I re-uploaded the squeezed design doc to the xen wiki:
> 
> http://wiki.xen.org/wiki/File:Squeezed.pdf
> 
> I think it got lost during the conversion from the old wiki to the new wiki.
> 
> Hopefully the doc gives a better "big picture" view than the code itself :-)
> 
> The quick summary is that squeezed tries to "balance" memory between the VMs on the host by manipulating their balloon targets. When a VM is to be started, xapi will ask it to "reserve" memory, squeezed will lower the balloon targets (and set maxmem as an absolute limit on allocation), wait for something to happen, possibly conclude some guests are being "uncooperative" and ask the "cooperative" ones to balloon down some more etc. It works but the problems I would highlight are:
> 

How do you know whether the cooperative guests _can_ balloon further down? As in, what if they are OK doing it but end
up OOM-ing? That can happen right now with Linux if you set the memory target too low.

> 0. since a VM which refuses to balloon down causes other VMs to be ballooned harder, we needed a good way to signal misbehavior to the user
> 
> 1. freeing memory by ballooning can be quite slow (especially on windows)
> 
> 2. to actually free 'x' MiB we have to know what number to set the memory/target to. Experimentally it seems that, when an HVM guest has finished ballooning, the domain's total_pages will equal the memory/target + a constant offset. Squeezed performs an initial calibration but it is potentially quite fragile.
> 
> 3. we want to keep as much memory in-use as possible (ie allocated to guests) but allocating domain structures often failed due to lack of (low? contiguous?) memory. To work around this we balloon first and domain create second, but this required us to track memory 'reservations' independently of the domains so that we wouldn't leak over a crash. This is a bit complicated but ok because all memory allocations are handled by squeezed.
> 
> 4. squeezed's memory management will clearly not work very well if some degree of page sharing is in-use :-)

Right, and 'tmem' is in the same "boat" so to say.
> 
> 5. (more of a bug) the code for "balancing" would occasionally oscillate, moving pages between VMs every few seconds. This caused quite a lot of log spam.

Thank you for writing it up. I think  I got a better understanding of it.
> 
> HTH,
> 
> Dave
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 12 15:39:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5Hwi-0007CI-NM; Tue, 12 Feb 2013 15:39:00 +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 1U5Hwh-0007C2-IP
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:38:59 +0000
Received: from [85.158.139.83:26997] by server-5.bemta-5.messagelabs.com id
	F6/3E-11945-2126A115; Tue, 12 Feb 2013 15:38:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360683536!31535618!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjcyODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23590 invoked from network); 12 Feb 2013 15:38:58 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 15:38:58 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFckub031155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 15:38:47 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
	r1CFciqq028200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 15:38:45 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
	r1CFciqK006974; Tue, 12 Feb 2013 09:38:44 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 07:38:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B4C81BF781; Tue, 12 Feb 2013 10:38:42 -0500 (EST)
Date: Tue, 12 Feb 2013 10:38:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Scott <Dave.Scott@eu.citrix.com>
Message-ID: <20130212153842.GF3016@phenom.dumpdata.com>
References: <mailman.18000.1354568068.1399.xen-devel@lists.xen.org>
	<49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca>
	<20121218221749.GA6332@phenom.dumpdata.com>
	<50D1B8D0.4020500@eu.citrix.com>
	<20130102215901.GA16093@phenom.dumpdata.com>
	<50F44E60.4090904@eu.citrix.com>
	<20130122215748.GA14146@phenom.dumpdata.com>
	<81A73678E76EA642801C8F2E4823AD21014183065D37@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21014183065D37@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 23, 2013 at 06:36:06PM +0000, Dave Scott wrote:
> Hi,
> 
> > On Mon, Jan 14, 2013 at 06:28:48PM +0000, George Dunlap wrote:
> > > I'm not fluent in OCaml either, I'm mainly going from memory based on
> > > the discussions I had with the author when it was being designed, as
> > > well as discussions with the xapi team when dealing with bugs at later
> > > points.
> 
> Konrad Rzeszutek Wilk replied:
> 
> > I was looking at xen-api/ocaml/xenops/squeeze.ml and just reading the
> > comments and feebly trying to understand how the OCaml code is.
> > Best I could understand it does various measurements, makes the
> > appropiate hypercalls and waits for everything to stabilize before allowing
> > the guest to start.
> > 
> > N.B: With tmem, the 'stabilization' might never happen.
> 
> In case it's useful I re-uploaded the squeezed design doc to the xen wiki:
> 
> http://wiki.xen.org/wiki/File:Squeezed.pdf
> 
> I think it got lost during the conversion from the old wiki to the new wiki.
> 
> Hopefully the doc gives a better "big picture" view than the code itself :-)
> 
> The quick summary is that squeezed tries to "balance" memory between the VMs on the host by manipulating their balloon targets. When a VM is to be started, xapi will ask it to "reserve" memory, squeezed will lower the balloon targets (and set maxmem as an absolute limit on allocation), wait for something to happen, possibly conclude some guests are being "uncooperative" and ask the "cooperative" ones to balloon down some more etc. It works but the problems I would highlight are:
> 

How do you know whether the cooperative guests _can_ balloon further down? As in, what if they are OK doing it but end
up OOM-ing? That can happen right now with Linux if you set the memory target too low.

> 0. since a VM which refuses to balloon down causes other VMs to be ballooned harder, we needed a good way to signal misbehavior to the user
> 
> 1. freeing memory by ballooning can be quite slow (especially on windows)
> 
> 2. to actually free 'x' MiB we have to know what number to set the memory/target to. Experimentally it seems that, when an HVM guest has finished ballooning, the domain's total_pages will equal the memory/target + a constant offset. Squeezed performs an initial calibration but it is potentially quite fragile.
> 
> 3. we want to keep as much memory in-use as possible (ie allocated to guests) but allocating domain structures often failed due to lack of (low? contiguous?) memory. To work around this we balloon first and domain create second, but this required us to track memory 'reservations' independently of the domains so that we wouldn't leak over a crash. This is a bit complicated but ok because all memory allocations are handled by squeezed.
> 
> 4. squeezed's memory management will clearly not work very well if some degree of page sharing is in-use :-)

Right, and 'tmem' is in the same "boat" so to say.
> 
> 5. (more of a bug) the code for "balancing" would occasionally oscillate, moving pages between VMs every few seconds. This caused quite a lot of log spam.

Thank you for writing it up. I think  I got a better understanding of it.
> 
> HTH,
> 
> Dave
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 12 15:39:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5HxD-0007Gw-5c; Tue, 12 Feb 2013 15:39: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 1U5HxB-0007Gd-H5
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:39:29 +0000
Received: from [85.158.143.35:37606] by server-1.bemta-4.messagelabs.com id
	E8/A1-08839-0326A115; Tue, 12 Feb 2013 15:39:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360683446!11737336!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22997 invoked from network); 12 Feb 2013 15:37:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:37:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:37: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.297.1;
	Tue, 12 Feb 2013 15:37:25 +0000
Message-ID: <1360683444.20449.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 15:37:24 +0000
In-Reply-To: <20762.24689.570182.129974@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
 enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 15:32 +0000, Ian Jackson wrote:
> Alex Bligh writes ("[Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> > This value from libxl__json_node_type is never used.
> 
> We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> needs to remain frozen.

This is a purely internal type, so no ABI implications.

Also the libxl ABI is not frozen, only the API. We can always change the
SONAME.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:39:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5HxD-0007Gw-5c; Tue, 12 Feb 2013 15:39: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 1U5HxB-0007Gd-H5
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:39:29 +0000
Received: from [85.158.143.35:37606] by server-1.bemta-4.messagelabs.com id
	E8/A1-08839-0326A115; Tue, 12 Feb 2013 15:39:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360683446!11737336!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22997 invoked from network); 12 Feb 2013 15:37:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:37:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:37: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.297.1;
	Tue, 12 Feb 2013 15:37:25 +0000
Message-ID: <1360683444.20449.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 15:37:24 +0000
In-Reply-To: <20762.24689.570182.129974@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
 enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 15:32 +0000, Ian Jackson wrote:
> Alex Bligh writes ("[Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> > This value from libxl__json_node_type is never used.
> 
> We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> needs to remain frozen.

This is a purely internal type, so no ABI implications.

Also the libxl ABI is not frozen, only the API. We can always change the
SONAME.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:39:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:39: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 1U5HxV-0007Kv-Jp; Tue, 12 Feb 2013 15: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 1U5HxT-0007KF-Ku
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:39:47 +0000
Received: from [85.158.139.83:38645] by server-8.bemta-5.messagelabs.com id
	8C/21-19075-2426A115; Tue, 12 Feb 2013 15:39:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360683584!24963882!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 12 Feb 2013 15:39:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:39:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15: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.297.1; Tue, 12 Feb 2013 15:39:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5HxP-0008SF-VL; Tue, 12 Feb 2013 15:39:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5HxP-0004PS-QK;
	Tue, 12 Feb 2013 15:39:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25149.674143.835903@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:39:41 +0000
To: Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20762.24689.570182.129974@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
	enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 02/11] libxl_json: Remove JSON_ERROR from enum."):
> Alex Bligh writes ("[Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> > This value from libxl__json_node_type is never used.
> 
> We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> needs to remain frozen.

Sorry, forget about that comment.  I didn't spot that this change is
in libxl_internal.h.  It's fine.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:39:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:39: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 1U5HxV-0007Kv-Jp; Tue, 12 Feb 2013 15: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 1U5HxT-0007KF-Ku
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:39:47 +0000
Received: from [85.158.139.83:38645] by server-8.bemta-5.messagelabs.com id
	8C/21-19075-2426A115; Tue, 12 Feb 2013 15:39:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360683584!24963882!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 12 Feb 2013 15:39:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:39:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15: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.297.1; Tue, 12 Feb 2013 15:39:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5HxP-0008SF-VL; Tue, 12 Feb 2013 15:39:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5HxP-0004PS-QK;
	Tue, 12 Feb 2013 15:39:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25149.674143.835903@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:39:41 +0000
To: Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20762.24689.570182.129974@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
	enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 02/11] libxl_json: Remove JSON_ERROR from enum."):
> Alex Bligh writes ("[Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> > This value from libxl__json_node_type is never used.
> 
> We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> needs to remain frozen.

Sorry, forget about that comment.  I didn't spot that this change is
in libxl_internal.h.  It's fine.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:40:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:40: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 1U5Hxf-0007NX-0i; Tue, 12 Feb 2013 15:39: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 1U5Hxd-0007Mr-Ge
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:39:57 +0000
Received: from [85.158.138.51:22238] by server-15.bemta-3.messagelabs.com id
	F6/AE-25405-C426A115; Tue, 12 Feb 2013 15:39:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360683596!32092948!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18294 invoked from network); 12 Feb 2013 15:39:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:39: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.297.1; Tue, 12 Feb 2013 15:39:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hxb-0008SK-OT; Tue, 12 Feb 2013 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 1U5Hxb-0004PY-Jl;
	Tue, 12 Feb 2013 15:39:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25163.506196.797595@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:39:55 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-4-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-4-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/11] libxl_json: Replace JSON_TRUE/FALSE
	by	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 03/11] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL."):
> Those two JSON_TRUE and JSON_FALSE were types of node. But it's better
> to have a unique JSON_BOOL type.
> 
> Backported from xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693131 -3600
> : Node ID 3f71aab0e2774ded0c5a03436c364fb031ba9aa0
> : Parent  4a6d5d8cba4fc44f9bbda201188885868604b8e8

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:40:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:40: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 1U5Hxf-0007NX-0i; Tue, 12 Feb 2013 15:39: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 1U5Hxd-0007Mr-Ge
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:39:57 +0000
Received: from [85.158.138.51:22238] by server-15.bemta-3.messagelabs.com id
	F6/AE-25405-C426A115; Tue, 12 Feb 2013 15:39:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360683596!32092948!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18294 invoked from network); 12 Feb 2013 15:39:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:39: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.297.1; Tue, 12 Feb 2013 15:39:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hxb-0008SK-OT; Tue, 12 Feb 2013 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 1U5Hxb-0004PY-Jl;
	Tue, 12 Feb 2013 15:39:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25163.506196.797595@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:39:55 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-4-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-4-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 03/11] libxl_json: Replace JSON_TRUE/FALSE
	by	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 03/11] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL."):
> Those two JSON_TRUE and JSON_FALSE were types of node. But it's better
> to have a unique JSON_BOOL type.
> 
> Backported from xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693131 -3600
> : Node ID 3f71aab0e2774ded0c5a03436c364fb031ba9aa0
> : Parent  4a6d5d8cba4fc44f9bbda201188885868604b8e8

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:40:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5HyU-0007ar-Hh; Tue, 12 Feb 2013 15:40:50 +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 1U5HyT-0007aL-1n
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:40:49 +0000
Received: from [85.158.137.99:49845] by server-4.bemta-3.messagelabs.com id
	23/CD-12802-0826A115; Tue, 12 Feb 2013 15:40:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360683639!20276122!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19650 invoked from network); 12 Feb 2013 15:40:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:40: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.297.1; Tue, 12 Feb 2013 15:40:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5HyJ-0008Sj-KC; Tue, 12 Feb 2013 15:40:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5HyJ-0004Pj-G7;
	Tue, 12 Feb 2013 15:40:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25203.22484.536197@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:40:35 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-7-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-7-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/11] libxl_qmp: Use qmp_parameters_*
	functions	for param list of a QMP 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

Alex Bligh writes ("[Xen-devel] [PATCH 06/11] libxl_qmp: Use qmp_parameters_* functions for param list of a QMP command."):
> Backported from xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693133 -3600
> : Node ID be5d014f91dfbd67afacc3385c265243794a246f
> : Parent  6f7847729f0f42614de516d15257ede7243f995f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:40:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5HyU-0007ar-Hh; Tue, 12 Feb 2013 15:40:50 +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 1U5HyT-0007aL-1n
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:40:49 +0000
Received: from [85.158.137.99:49845] by server-4.bemta-3.messagelabs.com id
	23/CD-12802-0826A115; Tue, 12 Feb 2013 15:40:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360683639!20276122!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19650 invoked from network); 12 Feb 2013 15:40:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:40: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.297.1; Tue, 12 Feb 2013 15:40:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5HyJ-0008Sj-KC; Tue, 12 Feb 2013 15:40:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5HyJ-0004Pj-G7;
	Tue, 12 Feb 2013 15:40:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25203.22484.536197@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:40:35 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-7-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-7-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/11] libxl_qmp: Use qmp_parameters_*
	functions	for param list of a QMP 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

Alex Bligh writes ("[Xen-devel] [PATCH 06/11] libxl_qmp: Use qmp_parameters_* functions for param list of a QMP command."):
> Backported from xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693133 -3600
> : Node ID be5d014f91dfbd67afacc3385c265243794a246f
> : Parent  6f7847729f0f42614de516d15257ede7243f995f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:41:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:41: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 1U5Hyr-0007hq-53; Tue, 12 Feb 2013 15:41: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 1U5Hyq-0007hO-E3
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:41:12 +0000
Received: from [85.158.139.211:11421] by server-16.bemta-5.messagelabs.com id
	3C/50-14948-7926A115; Tue, 12 Feb 2013 15:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360683670!18231351!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20213 invoked from network); 12 Feb 2013 15:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:41: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.297.1; Tue, 12 Feb 2013 15:41:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hyo-0008Su-LE; Tue, 12 Feb 2013 15:41:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hyo-0004Q5-H4;
	Tue, 12 Feb 2013 15:41:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25238.410553.666172@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:41:10 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-8-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-8-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/11] libxl_qmp: Simplify run of single
	QMP	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 07/11] libxl_qmp: Simplify run of single QMP commands."):
> This new function connects to QEMU, sends the command and disconnects.
> 
> Backport of xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693134 -3600
> : Node ID f3890916496445c97d6778d6c986b0270ff707f2
> : Parent  be5d014f91dfbd67afacc3385c265243794a246f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:41:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:41: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 1U5Hyr-0007hq-53; Tue, 12 Feb 2013 15:41: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 1U5Hyq-0007hO-E3
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:41:12 +0000
Received: from [85.158.139.211:11421] by server-16.bemta-5.messagelabs.com id
	3C/50-14948-7926A115; Tue, 12 Feb 2013 15:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360683670!18231351!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20213 invoked from network); 12 Feb 2013 15:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:41: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.297.1; Tue, 12 Feb 2013 15:41:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Hyo-0008Su-LE; Tue, 12 Feb 2013 15:41:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Hyo-0004Q5-H4;
	Tue, 12 Feb 2013 15:41:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25238.410553.666172@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:41:10 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-8-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-8-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 07/11] libxl_qmp: Simplify run of single
	QMP	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 07/11] libxl_qmp: Simplify run of single QMP commands."):
> This new function connects to QEMU, sends the command and disconnects.
> 
> Backport of xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693134 -3600
> : Node ID f3890916496445c97d6778d6c986b0270ff707f2
> : Parent  be5d014f91dfbd67afacc3385c265243794a246f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:42:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:42: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 1U5I0C-000831-1T; Tue, 12 Feb 2013 15:42: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 1U5I0A-00082W-Nc
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:42:34 +0000
Received: from [85.158.139.83:8249] by server-2.bemta-5.messagelabs.com id
	2F/2E-16911-9E26A115; Tue, 12 Feb 2013 15:42:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360683753!31113974!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20944 invoked from network); 12 Feb 2013 15:42:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:42: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.297.1; Tue, 12 Feb 2013 15:42:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I08-0008TM-QU; Tue, 12 Feb 2013 15:42:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I08-0004QJ-ML;
	Tue, 12 Feb 2013 15:42:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25320.467534.174911@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:42:32 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360683444.20449.192.camel@zakaz.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
	<1360683444.20449.192.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>,
	Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
 enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/11] libxl_json: Remove JSON_ERROR from enum."):
> On Tue, 2013-02-12 at 15:32 +0000, Ian Jackson wrote:
> > We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> > needs to remain frozen.
> 
> This is a purely internal type, so no ABI implications.
> 
> Also the libxl ABI is not frozen, only the API. We can always change the
> SONAME.

The ABI certainly needs to be frozen within a stable release.  I don't
know if we document this anywhere but it seems like a fairly basic
obvious requirement.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:42:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:42: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 1U5I0C-000831-1T; Tue, 12 Feb 2013 15:42: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 1U5I0A-00082W-Nc
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:42:34 +0000
Received: from [85.158.139.83:8249] by server-2.bemta-5.messagelabs.com id
	2F/2E-16911-9E26A115; Tue, 12 Feb 2013 15:42:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360683753!31113974!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20944 invoked from network); 12 Feb 2013 15:42:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:42: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.297.1; Tue, 12 Feb 2013 15:42:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I08-0008TM-QU; Tue, 12 Feb 2013 15:42:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I08-0004QJ-ML;
	Tue, 12 Feb 2013 15:42:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25320.467534.174911@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:42:32 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360683444.20449.192.camel@zakaz.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
	<1360683444.20449.192.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>,
	Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
 enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/11] libxl_json: Remove JSON_ERROR from enum."):
> On Tue, 2013-02-12 at 15:32 +0000, Ian Jackson wrote:
> > We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> > needs to remain frozen.
> 
> This is a purely internal type, so no ABI implications.
> 
> Also the libxl ABI is not frozen, only the API. We can always change the
> SONAME.

The ABI certainly needs to be frozen within a stable release.  I don't
know if we document this anywhere but it seems like a fairly basic
obvious requirement.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:42:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I09-00082L-Kw; Tue, 12 Feb 2013 15:42: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 1U5I08-000823-L0
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:42:32 +0000
Received: from [85.158.143.35:48992] by server-2.bemta-4.messagelabs.com id
	80/5D-01597-8E26A115; Tue, 12 Feb 2013 15:42:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360683521!13592457!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15673 invoked from network); 12 Feb 2013 15:38:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:38:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:38: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.297.1; Tue, 12 Feb 2013 15:38:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5HwO-0008Rq-Pd; Tue, 12 Feb 2013 15:38:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5HwO-0004PJ-MH;
	Tue, 12 Feb 2013 15:38:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25088.595158.14337@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:38:40 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-5-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-5-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/11] libxl_json:
	Introduce	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 04/11] libxl_json: Introduce libxl__json_object_to_yajl_gen."):
> This function converts a libxl__json_object to yajl by calling every
> yajl_gen_* function on a preallocated yajl_gen hand.

This backport is also fine.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:42:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I09-00082L-Kw; Tue, 12 Feb 2013 15:42: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 1U5I08-000823-L0
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:42:32 +0000
Received: from [85.158.143.35:48992] by server-2.bemta-4.messagelabs.com id
	80/5D-01597-8E26A115; Tue, 12 Feb 2013 15:42:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360683521!13592457!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15673 invoked from network); 12 Feb 2013 15:38:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:38:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379761"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:38: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.297.1; Tue, 12 Feb 2013 15:38:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5HwO-0008Rq-Pd; Tue, 12 Feb 2013 15:38:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5HwO-0004PJ-MH;
	Tue, 12 Feb 2013 15:38:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25088.595158.14337@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:38:40 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-5-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-5-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 04/11] libxl_json:
	Introduce	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 04/11] libxl_json: Introduce libxl__json_object_to_yajl_gen."):
> This function converts a libxl__json_object to yajl by calling every
> yajl_gen_* function on a preallocated yajl_gen hand.

This backport is also fine.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:43:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:43: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 1U5I0h-0008A4-GT; Tue, 12 Feb 2013 15:43: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 1U5I0f-00089b-Lm
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:43:05 +0000
Received: from [85.158.139.83:46339] by server-8.bemta-5.messagelabs.com id
	EB/A6-19075-8036A115; Tue, 12 Feb 2013 15:43:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360683784!26565955!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26891 invoked from network); 12 Feb 2013 15:43:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:43: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.297.1; Tue, 12 Feb 2013 15:43:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I0d-0008TX-NJ; Tue, 12 Feb 2013 15:43:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I0d-0004QR-Io;
	Tue, 12 Feb 2013 15:43:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25351.462212.620736@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:43:03 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-9-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-9-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl_qmp:
	Introduce	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 08/11] libxl_qmp: Introduce libxl__qmp_set_global_dirty_log."):
> This function will enable or disable the global dirty log on QEMU,
> used during a migration.
> 
> Backport of xen-unstable patch:
> : HG changeset patch

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:43:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:43: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 1U5I0h-0008A4-GT; Tue, 12 Feb 2013 15:43: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 1U5I0f-00089b-Lm
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:43:05 +0000
Received: from [85.158.139.83:46339] by server-8.bemta-5.messagelabs.com id
	EB/A6-19075-8036A115; Tue, 12 Feb 2013 15:43:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360683784!26565955!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26891 invoked from network); 12 Feb 2013 15:43:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1379998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:43: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.297.1; Tue, 12 Feb 2013 15:43:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I0d-0008TX-NJ; Tue, 12 Feb 2013 15:43:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I0d-0004QR-Io;
	Tue, 12 Feb 2013 15:43:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25351.462212.620736@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:43:03 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-9-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-9-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/11] libxl_qmp:
	Introduce	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[Xen-devel] [PATCH 08/11] libxl_qmp: Introduce libxl__qmp_set_global_dirty_log."):
> This function will enable or disable the global dirty log on QEMU,
> used during a migration.
> 
> Backport of xen-unstable patch:
> : HG changeset patch

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:44:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I1p-0008R6-06; Tue, 12 Feb 2013 15:44: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 1U5I1n-0008Qp-R6
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:44:16 +0000
Received: from [193.109.254.147:57195] by server-12.bemta-14.messagelabs.com
	id A5/C5-32582-F436A115; Tue, 12 Feb 2013 15:44:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360683815!2058005!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22812 invoked from network); 12 Feb 2013 15:43:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:43:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:43: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.297.1; Tue, 12 Feb 2013 15:43:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I15-0008Th-94; Tue, 12 Feb 2013 15:43:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I15-0004Qa-4W;
	Tue, 12 Feb 2013 15:43:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25379.38871.994188@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:43:31 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-6-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-6-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] libxl_qmp: Introduces helpers to
	create	an argument 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

Alex Bligh writes ("[Xen-devel] [PATCH 05/11] libxl_qmp: Introduces helpers to create an argument list."):
> Those functions will be used to create a "list" of parameters that
> contain more than just strings. This list is converted by qmp_send to
> a string to be sent to QEMU.
> 
> Those functions will be used in the next two patches, so right now
> there are not compiled.
> 
> Backported from xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693132 -3600
> : Node ID 6f7847729f0f42614de516d15257ede7243f995f
> : Parent  74dee58cfc0d2d6594f388db3b4d2ce91d1bb204

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:44:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I1p-0008R6-06; Tue, 12 Feb 2013 15:44: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 1U5I1n-0008Qp-R6
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:44:16 +0000
Received: from [193.109.254.147:57195] by server-12.bemta-14.messagelabs.com
	id A5/C5-32582-F436A115; Tue, 12 Feb 2013 15:44:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360683815!2058005!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22812 invoked from network); 12 Feb 2013 15:43:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:43:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:43: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.297.1; Tue, 12 Feb 2013 15:43:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I15-0008Th-94; Tue, 12 Feb 2013 15:43:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I15-0004Qa-4W;
	Tue, 12 Feb 2013 15:43:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25379.38871.994188@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:43:31 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-6-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-6-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] libxl_qmp: Introduces helpers to
	create	an argument 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

Alex Bligh writes ("[Xen-devel] [PATCH 05/11] libxl_qmp: Introduces helpers to create an argument list."):
> Those functions will be used to create a "list" of parameters that
> contain more than just strings. This list is converted by qmp_send to
> a string to be sent to QEMU.
> 
> Those functions will be used in the next two patches, so right now
> there are not compiled.
> 
> Backported from xen-unstable patch:
> : HG changeset patch
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693132 -3600
> : Node ID 6f7847729f0f42614de516d15257ede7243f995f
> : Parent  74dee58cfc0d2d6594f388db3b4d2ce91d1bb204

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:44:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 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 1U5I1t-0008SJ-EL; Tue, 12 Feb 2013 15:44: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 1U5I1s-0008Ro-0G
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:44:20 +0000
Received: from [193.109.254.147:30852] by server-10.bemta-14.messagelabs.com
	id 59/BD-12679-3536A115; Tue, 12 Feb 2013 15:44:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360683815!2058005!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23211 invoked from network); 12 Feb 2013 15:43:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:43: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.297.1; Tue, 12 Feb 2013 15:43:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I1K-0008Tp-PM; Tue, 12 Feb 2013 15:43:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I1K-0004Qj-LN;
	Tue, 12 Feb 2013 15:43:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25394.566522.95800@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:43:46 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-2-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-2-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] libxl_json: Export json_object
	related	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

Alex Bligh writes ("[Xen-devel] [PATCH 01/11] libxl_json: Export json_object related function."):
> Export libxl__json_object_alloc and libxl__json_object_append_to to
> use them in a later patch.
> 
> Backported from xen-unstable patch:
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693129 -3600
> : Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
> : Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:44:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 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 1U5I1t-0008SJ-EL; Tue, 12 Feb 2013 15:44: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 1U5I1s-0008Ro-0G
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:44:20 +0000
Received: from [193.109.254.147:30852] by server-10.bemta-14.messagelabs.com
	id 59/BD-12679-3536A115; Tue, 12 Feb 2013 15:44:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360683815!2058005!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23211 invoked from network); 12 Feb 2013 15:43:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:43: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.297.1; Tue, 12 Feb 2013 15:43:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I1K-0008Tp-PM; Tue, 12 Feb 2013 15:43:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I1K-0004Qj-LN;
	Tue, 12 Feb 2013 15:43:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25394.566522.95800@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:43:46 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358618288-17109-2-git-send-email-alex@alex.org.uk>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-2-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] libxl_json: Export json_object
	related	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

Alex Bligh writes ("[Xen-devel] [PATCH 01/11] libxl_json: Export json_object related function."):
> Export libxl__json_object_alloc and libxl__json_object_append_to to
> use them in a later patch.
> 
> Backported from xen-unstable patch:
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693129 -3600
> : Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
> : Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(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 Feb 12 15:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:45: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 1U5I2Y-0000As-Tq; Tue, 12 Feb 2013 15:45: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 1U5I2X-0000AK-7k
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:45:01 +0000
Received: from [85.158.138.51:27007] by server-7.bemta-3.messagelabs.com id
	97/33-10367-6736A115; Tue, 12 Feb 2013 15:44:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360683893!9316691!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24335 invoked from network); 12 Feb 2013 15:44:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:44: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.297.1; Tue, 12 Feb 2013 15:44:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I2O-0008U9-Rf; Tue, 12 Feb 2013 15:44:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I2O-0004Qs-NS;
	Tue, 12 Feb 2013 15:44:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25460.618127.856037@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:44:52 +0000
To: Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20762.25047.686468.319085@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 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

Ian Jackson writes ("Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> Alex Bligh writes ("[Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> > Backport of xen-unstable patch:
> > : HG changeset patch
> > : User Anthony PERARD <anthony.perard@citrix.com>
> > : Date 1349693136 -3600
> > : Node ID 0995890022391682a2499a202c3c8608e1d3780a
> > : Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369
> 
> This backport is fine but needs to come at the end of the series, I
> think ?

I've had another thought: what if this series is applied, including
this final patch, but the result is used with an older qemu which
hasn't had the relevant features added ?

AFAICT the result would probably be a failure to execute the logdirty
switch.  Is that error sufficiently clean ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:45: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 1U5I2Y-0000As-Tq; Tue, 12 Feb 2013 15:45: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 1U5I2X-0000AK-7k
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:45:01 +0000
Received: from [85.158.138.51:27007] by server-7.bemta-3.messagelabs.com id
	97/33-10367-6736A115; Tue, 12 Feb 2013 15:44:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360683893!9316691!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24335 invoked from network); 12 Feb 2013 15:44:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:44: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.297.1; Tue, 12 Feb 2013 15:44:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I2O-0008U9-Rf; Tue, 12 Feb 2013 15:44:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I2O-0004Qs-NS;
	Tue, 12 Feb 2013 15:44:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25460.618127.856037@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:44:52 +0000
To: Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20762.25047.686468.319085@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 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

Ian Jackson writes ("Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> Alex Bligh writes ("[Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> > Backport of xen-unstable patch:
> > : HG changeset patch
> > : User Anthony PERARD <anthony.perard@citrix.com>
> > : Date 1349693136 -3600
> > : Node ID 0995890022391682a2499a202c3c8608e1d3780a
> > : Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369
> 
> This backport is fine but needs to come at the end of the series, I
> think ?

I've had another thought: what if this series is applied, including
this final patch, but the result is used with an older qemu which
hasn't had the relevant features added ?

AFAICT the result would probably be a failure to execute the logdirty
switch.  Is that error sufficiently clean ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:47:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I4v-0000ZB-GY; Tue, 12 Feb 2013 15: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.Jackson@eu.citrix.com>) id 1U5I4u-0000Yw-BX
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 15:47:28 +0000
Received: from [85.158.143.35:10350] by server-3.bemta-4.messagelabs.com id
	6E/73-08920-F046A115; Tue, 12 Feb 2013 15:47:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360684040!11647454!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2631 invoked from network); 12 Feb 2013 15:47:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:47:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:47: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.297.1; Tue, 12 Feb 2013 15:47:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I4l-0008Uv-T5; Tue, 12 Feb 2013 15:47:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I4j-0004R3-OE;
	Tue, 12 Feb 2013 15:47:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25605.626511.737910@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:47:17 +0000
To: Ross Philipson <Ross.Philipson@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1C9E@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31F6B645F@FTLPMAILBOX02.citrite.net>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BE8@FTLPMAILBOX02.citrite.net>
	<516D2318-7330-49AD-9BC0-222274803CC7@gmail.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BF3@FTLPMAILBOX02.citrite.net>
	<20130109145555.GA19595@phenom.dumpdata.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1C9E@FTLPMAILBOX02.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Konrad Rzeszutek Will <ketuzsezr@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v4 00/04] 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

Ross Philipson writes ("Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough"):
> I am not sure if that is related to my patches. I had brought up the point
> that the new xc_hvm_build() routine was never called from xl. I think the
> consensus was that I should remedy that in the process of adding the support
> for fw pass-through.

I think in general it is best to introduce new features in the whole
stack in the same series.

That way we don't introduce code at lower layers only to discover
later that the higher layer wants something different.

> I planned to do xl after the first patch set went in - are there any vetoes
> to that plan? Also since I will be adding parameters I suspect I need to
> update the docs on the xl configuration files. Any pointers on how to do that
> would be helpful. I see the man page source in docs/man/xl.cfg.pod.5; is
> the wiki information generated off of this?

How are you testing this series yourself if you don't have a suitable
series for libxl/xl as well ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:47:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I4v-0000ZB-GY; Tue, 12 Feb 2013 15: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.Jackson@eu.citrix.com>) id 1U5I4u-0000Yw-BX
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 15:47:28 +0000
Received: from [85.158.143.35:10350] by server-3.bemta-4.messagelabs.com id
	6E/73-08920-F046A115; Tue, 12 Feb 2013 15:47:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360684040!11647454!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2631 invoked from network); 12 Feb 2013 15:47:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:47:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:47: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.297.1; Tue, 12 Feb 2013 15:47:20 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I4l-0008Uv-T5; Tue, 12 Feb 2013 15:47:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I4j-0004R3-OE;
	Tue, 12 Feb 2013 15:47:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25605.626511.737910@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:47:17 +0000
To: Ross Philipson <Ross.Philipson@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A31FBE1C9E@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31F6B645F@FTLPMAILBOX02.citrite.net>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BE8@FTLPMAILBOX02.citrite.net>
	<516D2318-7330-49AD-9BC0-222274803CC7@gmail.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BF3@FTLPMAILBOX02.citrite.net>
	<20130109145555.GA19595@phenom.dumpdata.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1C9E@FTLPMAILBOX02.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Konrad Rzeszutek Will <ketuzsezr@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v4 00/04] 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

Ross Philipson writes ("Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough"):
> I am not sure if that is related to my patches. I had brought up the point
> that the new xc_hvm_build() routine was never called from xl. I think the
> consensus was that I should remedy that in the process of adding the support
> for fw pass-through.

I think in general it is best to introduce new features in the whole
stack in the same series.

That way we don't introduce code at lower layers only to discover
later that the higher layer wants something different.

> I planned to do xl after the first patch set went in - are there any vetoes
> to that plan? Also since I will be adding parameters I suspect I need to
> update the docs on the xl configuration files. Any pointers on how to do that
> would be helpful. I see the man page source in docs/man/xl.cfg.pod.5; is
> the wiki information generated off of this?

How are you testing this series yourself if you don't have a suitable
series for libxl/xl as well ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:51:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I8f-0000oB-7R; Tue, 12 Feb 2013 15:51:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5I8d-0000o4-7D
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:51:19 +0000
Received: from [193.109.254.147:29348] by server-15.bemta-14.messagelabs.com
	id 72/B6-24599-6F46A115; Tue, 12 Feb 2013 15:51:18 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360684274!2059095!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27351 invoked from network); 12 Feb 2013 15:51:16 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:51:16 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so288032iea.36
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 07:51:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=ZAcgEQv76jcbfhQAJUSFhPWllIs806xTdyz4o7LFlI0=;
	b=UsD7xanCkQgAdar1AN5lvOdi7c9y9zxEPfKIntwyJFK7Jqe1UaPfSMLbsbXppXCjmt
	bQfjfTHpqE4pclOzqhWFXdw0E4XWQH4+IOUwyEqA036usn/zl9gNCQJpjHHDwnhlQbMe
	ay13HWqZqu0ZjhW5NNpftjhxQG23hpd2Sjq5XB75UfZ8gPcjIUmOtZnya6QZUnVwZ4h+
	kuagb7KEPla3iBq70evDjWWLDNUg34xeDGy6efFFs7TtwHCbEf/TFSoYxwlr4oX0X1bh
	x2P6cqm1o6PYupauObJ8Ssx1j89Ex4FLOiczqDr4FGjbwmITrLta9P7ip3uUG8dd94cJ
	Kj9Q==
X-Received: by 10.50.196.132 with SMTP id im4mr4159444igc.58.1360684274622;
	Tue, 12 Feb 2013 07:51:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 07:50:54 -0800 (PST)
In-Reply-To: <511A5DC3.4010106@oracle.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 16:50:54 +0100
Message-ID: <CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>
> I don't see any devices on bus 7 in lspci output
> (http://pastebin.com/raw.php?i=3wpKPQT9 from original report).
>
> However the log shows
>
> pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it
> with 'pcie_aspm=force'
> ..
> (XEN) PCI add device 0000:07:00.0
>

There is device 00:07.0 in lspci output from original report:
00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to
PCI bridge (PCI express gpp port G) (prog-if 00 [Normal decode])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:51:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5I8f-0000oB-7R; Tue, 12 Feb 2013 15:51:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5I8d-0000o4-7D
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:51:19 +0000
Received: from [193.109.254.147:29348] by server-15.bemta-14.messagelabs.com
	id 72/B6-24599-6F46A115; Tue, 12 Feb 2013 15:51:18 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360684274!2059095!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27351 invoked from network); 12 Feb 2013 15:51:16 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:51:16 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so288032iea.36
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 07:51:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=ZAcgEQv76jcbfhQAJUSFhPWllIs806xTdyz4o7LFlI0=;
	b=UsD7xanCkQgAdar1AN5lvOdi7c9y9zxEPfKIntwyJFK7Jqe1UaPfSMLbsbXppXCjmt
	bQfjfTHpqE4pclOzqhWFXdw0E4XWQH4+IOUwyEqA036usn/zl9gNCQJpjHHDwnhlQbMe
	ay13HWqZqu0ZjhW5NNpftjhxQG23hpd2Sjq5XB75UfZ8gPcjIUmOtZnya6QZUnVwZ4h+
	kuagb7KEPla3iBq70evDjWWLDNUg34xeDGy6efFFs7TtwHCbEf/TFSoYxwlr4oX0X1bh
	x2P6cqm1o6PYupauObJ8Ssx1j89Ex4FLOiczqDr4FGjbwmITrLta9P7ip3uUG8dd94cJ
	Kj9Q==
X-Received: by 10.50.196.132 with SMTP id im4mr4159444igc.58.1360684274622;
	Tue, 12 Feb 2013 07:51:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 07:50:54 -0800 (PST)
In-Reply-To: <511A5DC3.4010106@oracle.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 16:50:54 +0100
Message-ID: <CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>
> I don't see any devices on bus 7 in lspci output
> (http://pastebin.com/raw.php?i=3wpKPQT9 from original report).
>
> However the log shows
>
> pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it
> with 'pcie_aspm=force'
> ..
> (XEN) PCI add device 0000:07:00.0
>

There is device 00:07.0 in lspci output from original report:
00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to
PCI bridge (PCI express gpp port G) (prog-if 00 [Normal decode])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:51:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:51: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 1U5I8x-0000qc-OT; Tue, 12 Feb 2013 15:51: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 1U5I8w-0000qH-Hh; Tue, 12 Feb 2013 15:51:38 +0000
Received: from [85.158.139.83:4121] by server-8.bemta-5.messagelabs.com id
	52/55-19075-9056A115; Tue, 12 Feb 2013 15:51:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360684296!31115743!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6379 invoked from network); 12 Feb 2013 15:51:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:51: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.297.1; Tue, 12 Feb 2013 15:51:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I8u-0008W7-HV; Tue, 12 Feb 2013 15:51:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I8u-0004Rl-DU;
	Tue, 12 Feb 2013 15:51:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25864.314580.353107@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:51:36 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1TmAB7-134992@chiark.greenend.org.uk>
References: <E71FC5D6F96C3C4B93FC8FF942D924C682F44808@SBJEXCH1B.websense.com>
	<20121022135023.GU8912@reaktio.net>
	<E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3@SBJEXCH1B.websense.com>
	<m2n.s.1TmAB7-134992@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Fan,
	Huaxiang" <hufan@websense.com>
Subject: Re: [Xen-devel] e820_host 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: 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] e820_host problems"):
> On Wed, Oct 24, 2012 at 06:02:11AM +0000, Fan, Huaxiang wrote:
> > Hi Pasi,
> > 
> > Thanks for your reply. I've tried the latest table kernel 3.6.3. The situation is better, but still not perfect.  
> > When I assign 6144M to domu wcg ,the output of 'xl list' only indicates 5110M allocated for domu wcg.
> > When I logon domu wcg, the totol memory is *limited within 3G*. I suspect the e820-map was wrong.
> 
> It looks like there is a bug in the libxl when assembling the e820 map.

This would be in e820_sanitize in libxl_x86.c I guess ?
Konrad, are you looking into a fix ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:51:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15:51: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 1U5I8x-0000qc-OT; Tue, 12 Feb 2013 15:51: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 1U5I8w-0000qH-Hh; Tue, 12 Feb 2013 15:51:38 +0000
Received: from [85.158.139.83:4121] by server-8.bemta-5.messagelabs.com id
	52/55-19075-9056A115; Tue, 12 Feb 2013 15:51:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360684296!31115743!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6379 invoked from network); 12 Feb 2013 15:51:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 15:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1380433"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 15:51: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.297.1; Tue, 12 Feb 2013 15:51:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5I8u-0008W7-HV; Tue, 12 Feb 2013 15:51:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5I8u-0004Rl-DU;
	Tue, 12 Feb 2013 15:51:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.25864.314580.353107@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 15:51:36 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1TmAB7-134992@chiark.greenend.org.uk>
References: <E71FC5D6F96C3C4B93FC8FF942D924C682F44808@SBJEXCH1B.websense.com>
	<20121022135023.GU8912@reaktio.net>
	<E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3@SBJEXCH1B.websense.com>
	<m2n.s.1TmAB7-134992@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Fan,
	Huaxiang" <hufan@websense.com>
Subject: Re: [Xen-devel] e820_host 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: 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] e820_host problems"):
> On Wed, Oct 24, 2012 at 06:02:11AM +0000, Fan, Huaxiang wrote:
> > Hi Pasi,
> > 
> > Thanks for your reply. I've tried the latest table kernel 3.6.3. The situation is better, but still not perfect.  
> > When I assign 6144M to domu wcg ,the output of 'xl list' only indicates 5110M allocated for domu wcg.
> > When I logon domu wcg, the totol memory is *limited within 3G*. I suspect the e820-map was wrong.
> 
> It looks like there is a bug in the libxl when assembling the e820 map.

This would be in e820_sanitize in libxl_x86.c I guess ?
Konrad, are you looking into a fix ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:54:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 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 1U5IB9-0001BK-VQ; Tue, 12 Feb 2013 15:53:55 +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 1U5IB7-0001Ay-Tq
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:53:54 +0000
Received: from [85.158.143.35:35213] by server-1.bemta-4.messagelabs.com id
	BC/05-08839-1956A115; Tue, 12 Feb 2013 15:53:53 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360684393!13566981!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25469 invoked from network); 12 Feb 2013 15:53:14 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-21.messagelabs.com with SMTP;
	12 Feb 2013 15:53:14 -0000
Received: from p5b2e333a.dip.t-dialin.net ([91.46.51.58] 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 1U5IAO-0008Vg-21; Tue, 12 Feb 2013 15:53:08 +0000
Message-ID: <511A6562.4070303@canonical.com>
Date: Tue, 12 Feb 2013 16:53:06 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
	<1360678069.20449.169.camel@zakaz.uk.xensource.com>
	<511A56A5.1040305@canonical.com>
	<1360681641.20449.178.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360681641.20449.178.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0573501494782216971=="
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)
--===============0573501494782216971==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig84979C251F77BDAB5045B7EA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig84979C251F77BDAB5045B7EA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 12.02.2013 16:07, Ian Campbell wrote:
> On Tue, 2013-02-12 at 14:50 +0000, Stefan Bader wrote:
>> On 12.02.2013 15:07, Ian Campbell wrote:
>>> On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
>>>> On 11.02.2013 18:29, Ian Campbell wrote:
>>>>> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
>>>>>> A while ago I had been reporting an issue which causes Xen PVM gue=
sts
>>>>>> to hang (apparently related to spinlocks). Since then I was able t=
o
>>>>>> gather a few more facts which I try to provide below. For the real=

>>>>>> reasons, I am still puzzled and would be thankful for any hints or=

>>>>>> direction.
>>>>>>
>>>>>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
>>>>>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
>>>>>
>>>>> This is on a host with >=3D 8 PCPUs, correct?
>>>>
>>>> Maybe >=3D4 but I cannot remember for sure anymore.
>>>
>>> OK, so the important point I was getting at was whether the guest was=

>>> overcommitting the host or not, it seems like it is (2xVCPUs for each=

>>> PCPU)
>>
>> Err not so much. I run on an 8-core host. ;)
>=20
> Um, which is what I asked. What is >=3D 4 then?

Uhm, me not being able to discern between P and V at some point. So what =
I was
thinking, was that I believe I had this when running with 4 VCPUs or 8 VC=
PUs on
the same 8 PCPU host...

>=20
>=20
>>>
>>>>> I suppose xen_spin_unlock could also be instrumented to indicate wh=
o it
>>>>> last kicked and for which lock and that might show us something?
>>>>
>>>> IIRC I had done this but it did not really show much. What I have do=
ne in the
>>>> meantime was to instrument the IRQ service functions in
>>>> arch/x86/kernel/entry_64.S to give me a history of callbacks. This s=
hows (in
>>>> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 st=
ill polling)
>>>> that the last events on the vcpu not polling are:
>>>>
>>>> xen_do_hypervisor_callback+127
>>>> call_softirq+29
>>>> call_softirq+125
>>>> call_softirq+29
>>>> call_softirq+125
>>>> call_softirq+29
>>>> call_softirq+125
>>>> xen_do_hypervisor_callback+28
>>>> call_softirq+29
>>>> xen_do_hypervisor_callback+28
>>>>
>>>> The lower offsets are when irq_count gets incremented and the higher=
 offsets are
>>>> when irq_count gets decremented before ending the callback. This sho=
ws that at
>>>> least in this case there was an upcall, a softirq and another upcall=
 being
>>>> triggered without finishing the previous one. There was another expe=
riment where
>>>> I saw softirq, upcall, upcall. But at least it seems that there is a=
lways a
>>>> three level stack.
>>>> I believe that softirq, upcall would be ok as softirq processing ena=
bles
>>>> interrupts but is it expected to have an upcall interrupted by anoth=
er one?
>>>
>>> I'm not sure. evtchn's don't have a priority mechanism so I expect no=
t
>>> in general but individual interrupt handlers could well reenable
>>> interrupts, I think (it might be one of the flags you pass when calli=
ng
>>> request_irq?).
>>
>> Just a gut feeling but it feels wrong to enable interrupts in any inte=
rrupt
>> handler. I thought for anything that needs interrupts enabled and/or t=
akes
>> longer it should pushed off to a workqueue...
>=20
> Either that or some sort of interrupt prioritisation mechanism in the
> hardware so only higher priority interrupts than the current one will
> occur.
>=20
>>
>>>
>>>>> Can someone explain why the non-locked update of lock_spinners in
>>>>> spinning_lock() is safe against xen_spin_unlock reading the field f=
rom
>>>>> another VCPU? I suspect it isn't, so what happens if the other VCPU=

>>>>> kicks the lock which is just about to become prev? maybe this is ha=
ndled
>>>>> in xen_spin_lock_slow somehow?
>>>>
>>>> Isn't that safe because lock_spinners is percpu?
>>>
>>> xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, whi=
ch
>>> is what I think might be unsafe.
>>
>> Ah right, that. Hm, the way those two play together always was a bit b=
rain
>> hurting.
>=20
> Yes...
>=20
>>  Though somehow it feels like if the top level poll_irq would return a=
nd
>> count things as spurious wakeup. I think in that case I would expect t=
he
>> lock_spinner entry of one vcpu to be not matching the freed lock...
>> Not a really scientific argument.
>=20
> Adding a BUG_ON(__this_cpu_write(lock_spinners) !=3D xl) in
> unspinning_lock might be interesting?

Hm, beside of writing prev into there which always should not be xl, I th=
ink
since write access only happens in spin_lock_slow that should stack ok. T=
he two
cases that would go wrong are sending a wakeup event when the lock was ju=
st
replaced on the other vcpu or not sending one when it should be.
IIRC I had one attempt print when xen_spin_unlock_slow went through all v=
cpus
without finding one to signal. That seemed to happen rather often but the=
n would
resolve as xen_spin_lock_slow for the other lock would set the event pend=
ing for
the prev lock if there was one (after being sucessful with the top level =
lock).

I think there is room for improvement by finding a way not always to sear=
ch from
vcpu 0 in spin_unlock_slow and maybe in spin_lock_slow to check whether
returning from poll without the current lock being free may be because of=
 prev
being free now. When there are more than one spinner may be able to proce=
ed...

>=20
> I wonder if this is something where the ftrace and related kernel
> infrastructure might be useful?

MAybe. Not sure there are hooks for what we are looking for and whether t=
he
system if not hanging too badly. My usual approach of looking at the dump=
 would
require to manually find the buffer and parse the records...




--------------enig84979C251F77BDAB5045B7EA
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGmViAAoJEOhnXe7L7s6jVN8P/1AhkAiOIodQfLqufAkxSQqV
zX/2g+3H+YAnJJGqkqMdgo7IbLLdiWuc++swNeTjjyBFiHseTss02ubY2e8nvbnx
bIo9LpA/VzYYZ46eOp1uiXJ4sNZ/Zw0/Vb8vS+Ngcvt9QllTFyJP+SMSJkB12T+Y
vn6O9xe1VwvlBkI8kk5Y9I6OMlmi3C/QlvMrwtlSPvdJ24hFC8TOyRpzVFY+zDjN
OYRWPjrzkqzXCBal85Rgl60sthpMwe7i+C2Nzl0icjp9/kjC4Oc0zYX/E3k7X2ra
WXxjutJuzkij6mW8oZ2LrMzQjBhGrGdrYYvlcQwrAb8lngAqEPeqGLa5p9Li9eQj
3A5WCVs8ewdbGsu9NV3GKsCEI5Y8/lZ5dESfFEPjxc5F8g9IcHrTKYG9x28pIoif
hKQNT56Rxx8RvxcEZMGHSel7f+wYbExh2eqXuQkO4NzaeJ3j/q9XXKGNoeecTsEc
16RoFTpRZ3dlJuAtGWMCMhFhp0gEkjOnmuWIliV3WcJc4FyXD79VDj8cqighutrp
LNI8ypcZdmW0AhSio21n+pZDiZyyZG2XEMvflPYuyB7u7dkh32eKo+E1d+FerO3E
Nlg5J6c/vxtaQjWk5NyL2wWJ5FzpHeQ05qYeZBnV+Q0lL18YzHQ/gIhbISrmwf3m
klZI0vf2CI6K60g0GYai
=/jEs
-----END PGP SIGNATURE-----

--------------enig84979C251F77BDAB5045B7EA--


--===============0573501494782216971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0573501494782216971==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 15:54:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 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 1U5IB9-0001BK-VQ; Tue, 12 Feb 2013 15:53:55 +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 1U5IB7-0001Ay-Tq
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:53:54 +0000
Received: from [85.158.143.35:35213] by server-1.bemta-4.messagelabs.com id
	BC/05-08839-1956A115; Tue, 12 Feb 2013 15:53:53 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360684393!13566981!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25469 invoked from network); 12 Feb 2013 15:53:14 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-21.messagelabs.com with SMTP;
	12 Feb 2013 15:53:14 -0000
Received: from p5b2e333a.dip.t-dialin.net ([91.46.51.58] 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 1U5IAO-0008Vg-21; Tue, 12 Feb 2013 15:53:08 +0000
Message-ID: <511A6562.4070303@canonical.com>
Date: Tue, 12 Feb 2013 16:53:06 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511A46AC.5020202@canonical.com>
	<1360678069.20449.169.camel@zakaz.uk.xensource.com>
	<511A56A5.1040305@canonical.com>
	<1360681641.20449.178.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360681641.20449.178.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0573501494782216971=="
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)
--===============0573501494782216971==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig84979C251F77BDAB5045B7EA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig84979C251F77BDAB5045B7EA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 12.02.2013 16:07, Ian Campbell wrote:
> On Tue, 2013-02-12 at 14:50 +0000, Stefan Bader wrote:
>> On 12.02.2013 15:07, Ian Campbell wrote:
>>> On Tue, 2013-02-12 at 13:42 +0000, Stefan Bader wrote:
>>>> On 11.02.2013 18:29, Ian Campbell wrote:
>>>>> On Fri, 2013-02-08 at 15:33 +0000, Stefan Bader wrote:
>>>>>> A while ago I had been reporting an issue which causes Xen PVM gue=
sts
>>>>>> to hang (apparently related to spinlocks). Since then I was able t=
o
>>>>>> gather a few more facts which I try to provide below. For the real=

>>>>>> reasons, I am still puzzled and would be thankful for any hints or=

>>>>>> direction.
>>>>>>
>>>>>> - Happens with Xen 4.1.2 and Xen 4.2 host-side.
>>>>>> - PVM guest with 8 VCPUs is running 800 threads doing DB updates.
>>>>>
>>>>> This is on a host with >=3D 8 PCPUs, correct?
>>>>
>>>> Maybe >=3D4 but I cannot remember for sure anymore.
>>>
>>> OK, so the important point I was getting at was whether the guest was=

>>> overcommitting the host or not, it seems like it is (2xVCPUs for each=

>>> PCPU)
>>
>> Err not so much. I run on an 8-core host. ;)
>=20
> Um, which is what I asked. What is >=3D 4 then?

Uhm, me not being able to discern between P and V at some point. So what =
I was
thinking, was that I believe I had this when running with 4 VCPUs or 8 VC=
PUs on
the same 8 PCPU host...

>=20
>=20
>>>
>>>>> I suppose xen_spin_unlock could also be instrumented to indicate wh=
o it
>>>>> last kicked and for which lock and that might show us something?
>>>>
>>>> IIRC I had done this but it did not really show much. What I have do=
ne in the
>>>> meantime was to instrument the IRQ service functions in
>>>> arch/x86/kernel/entry_64.S to give me a history of callbacks. This s=
hows (in
>>>> another experiment where it is 1,2,5,6 in the same lock and 2,5,6 st=
ill polling)
>>>> that the last events on the vcpu not polling are:
>>>>
>>>> xen_do_hypervisor_callback+127
>>>> call_softirq+29
>>>> call_softirq+125
>>>> call_softirq+29
>>>> call_softirq+125
>>>> call_softirq+29
>>>> call_softirq+125
>>>> xen_do_hypervisor_callback+28
>>>> call_softirq+29
>>>> xen_do_hypervisor_callback+28
>>>>
>>>> The lower offsets are when irq_count gets incremented and the higher=
 offsets are
>>>> when irq_count gets decremented before ending the callback. This sho=
ws that at
>>>> least in this case there was an upcall, a softirq and another upcall=
 being
>>>> triggered without finishing the previous one. There was another expe=
riment where
>>>> I saw softirq, upcall, upcall. But at least it seems that there is a=
lways a
>>>> three level stack.
>>>> I believe that softirq, upcall would be ok as softirq processing ena=
bles
>>>> interrupts but is it expected to have an upcall interrupted by anoth=
er one?
>>>
>>> I'm not sure. evtchn's don't have a priority mechanism so I expect no=
t
>>> in general but individual interrupt handlers could well reenable
>>> interrupts, I think (it might be one of the flags you pass when calli=
ng
>>> request_irq?).
>>
>> Just a gut feeling but it feels wrong to enable interrupts in any inte=
rrupt
>> handler. I thought for anything that needs interrupts enabled and/or t=
akes
>> longer it should pushed off to a workqueue...
>=20
> Either that or some sort of interrupt prioritisation mechanism in the
> hardware so only higher priority interrupts than the current one will
> occur.
>=20
>>
>>>
>>>>> Can someone explain why the non-locked update of lock_spinners in
>>>>> spinning_lock() is safe against xen_spin_unlock reading the field f=
rom
>>>>> another VCPU? I suspect it isn't, so what happens if the other VCPU=

>>>>> kicks the lock which is just about to become prev? maybe this is ha=
ndled
>>>>> in xen_spin_lock_slow somehow?
>>>>
>>>> Isn't that safe because lock_spinners is percpu?
>>>
>>> xen_spin_unlock_slow() accesses the lock_spinners of remote CPUs, whi=
ch
>>> is what I think might be unsafe.
>>
>> Ah right, that. Hm, the way those two play together always was a bit b=
rain
>> hurting.
>=20
> Yes...
>=20
>>  Though somehow it feels like if the top level poll_irq would return a=
nd
>> count things as spurious wakeup. I think in that case I would expect t=
he
>> lock_spinner entry of one vcpu to be not matching the freed lock...
>> Not a really scientific argument.
>=20
> Adding a BUG_ON(__this_cpu_write(lock_spinners) !=3D xl) in
> unspinning_lock might be interesting?

Hm, beside of writing prev into there which always should not be xl, I th=
ink
since write access only happens in spin_lock_slow that should stack ok. T=
he two
cases that would go wrong are sending a wakeup event when the lock was ju=
st
replaced on the other vcpu or not sending one when it should be.
IIRC I had one attempt print when xen_spin_unlock_slow went through all v=
cpus
without finding one to signal. That seemed to happen rather often but the=
n would
resolve as xen_spin_lock_slow for the other lock would set the event pend=
ing for
the prev lock if there was one (after being sucessful with the top level =
lock).

I think there is room for improvement by finding a way not always to sear=
ch from
vcpu 0 in spin_unlock_slow and maybe in spin_lock_slow to check whether
returning from poll without the current lock being free may be because of=
 prev
being free now. When there are more than one spinner may be able to proce=
ed...

>=20
> I wonder if this is something where the ftrace and related kernel
> infrastructure might be useful?

MAybe. Not sure there are hooks for what we are looking for and whether t=
he
system if not hanging too badly. My usual approach of looking at the dump=
 would
require to manually find the buffer and parse the records...




--------------enig84979C251F77BDAB5045B7EA
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRGmViAAoJEOhnXe7L7s6jVN8P/1AhkAiOIodQfLqufAkxSQqV
zX/2g+3H+YAnJJGqkqMdgo7IbLLdiWuc++swNeTjjyBFiHseTss02ubY2e8nvbnx
bIo9LpA/VzYYZ46eOp1uiXJ4sNZ/Zw0/Vb8vS+Ngcvt9QllTFyJP+SMSJkB12T+Y
vn6O9xe1VwvlBkI8kk5Y9I6OMlmi3C/QlvMrwtlSPvdJ24hFC8TOyRpzVFY+zDjN
OYRWPjrzkqzXCBal85Rgl60sthpMwe7i+C2Nzl0icjp9/kjC4Oc0zYX/E3k7X2ra
WXxjutJuzkij6mW8oZ2LrMzQjBhGrGdrYYvlcQwrAb8lngAqEPeqGLa5p9Li9eQj
3A5WCVs8ewdbGsu9NV3GKsCEI5Y8/lZ5dESfFEPjxc5F8g9IcHrTKYG9x28pIoif
hKQNT56Rxx8RvxcEZMGHSel7f+wYbExh2eqXuQkO4NzaeJ3j/q9XXKGNoeecTsEc
16RoFTpRZ3dlJuAtGWMCMhFhp0gEkjOnmuWIliV3WcJc4FyXD79VDj8cqighutrp
LNI8ypcZdmW0AhSio21n+pZDiZyyZG2XEMvflPYuyB7u7dkh32eKo+E1d+FerO3E
Nlg5J6c/vxtaQjWk5NyL2wWJ5FzpHeQ05qYeZBnV+Q0lL18YzHQ/gIhbISrmwf3m
klZI0vf2CI6K60g0GYai
=/jEs
-----END PGP SIGNATURE-----

--------------enig84979C251F77BDAB5045B7EA--


--===============0573501494782216971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0573501494782216971==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 15:54:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5IBg-0001GO-E7; Tue, 12 Feb 2013 15:54:28 +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 1U5IBf-0001G3-BV
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:54:27 +0000
Received: from [85.158.137.99:55566] by server-8.bemta-3.messagelabs.com id
	5B/A8-25687-2B56A115; Tue, 12 Feb 2013 15:54:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360684464!21107212!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE2NTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13569 invoked from network); 12 Feb 2013 15:54:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 15:54:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFsCBk016065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 15:54:13 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
	r1CFsC5D022221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 15:54:12 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1CFsCn1020658; Tue, 12 Feb 2013 09:54:12 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 07:54:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4CF4B1BF781; Tue, 12 Feb 2013 10:54:10 -0500 (EST)
Date: Tue, 12 Feb 2013 10:54:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130212155410.GG3016@phenom.dumpdata.com>
References: <mailman.18000.1354568068.1399.xen-devel@lists.xen.org>
	<49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca>
	<20121218221749.GA6332@phenom.dumpdata.com>
	<AF146C82-5904-480C-80D0-7906AFD2B614@gridcentric.ca>
	<20130111160314.GD15353@phenom.dumpdata.com>
	<F2749668-D894-4DBA-BC48-D5CE8180C27F@gridcentric.ca>
	<20130111190814.GD29020@phenom.dumpdata.com>
	<20130117151631.GF19975@ocelot.phlegethon.org>
	<20130118214542.GB3047@phenom.dumpdata.com>
	<20130121102923.GA72616@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130121102923.GA72616@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 21, 2013 at 10:29:23AM +0000, Tim Deegan wrote:
> At 16:45 -0500 on 18 Jan (1358527542), Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 17, 2013 at 03:16:31PM +0000, Tim Deegan wrote:
> > > At 14:08 -0500 on 11 Jan (1357913294), Konrad Rzeszutek Wilk wrote:
> > > > But the solution to the hypercall failing are multiple - one is to 
> > > > try to "squeeze" all the guests to make space
> > > 
> > > AFAICT if the toolstack can squeeze guests up to make room then the
> > > reservation hypercall isn't necessary -- just use the squeezing
> > > mechanism to make sure that running VMs don't use up the memory you want
> > > for building new ones.
> > 
> > We might want to not do that until we have run out of options (this would
> > be a toolstack option to select the right choice). The other option is
> > to just launch the guest on another node.
> 
> Sure, I see that; but what I meant was: the reservation hypercall only
> makes any kind of sense if the toolstack can't squeeze the existing guests. 

OK. I am going to take the liberty here to assume that squeeze is setting
d->max_pages and kicking the guest to balloon down to some number.

> 
> If it can squeeze VMs, as part of that it must have some mechanism to
> stop them from immediately re-allocating all the memory as it frees it.
> So in the case where enough memory is already free, you just use that
> mechanism to protect it while you build the new VM.

Sure.
> 
> Or (since I get the impression that losing this allocation race is a
> rare event) you can take the optimistic route: after you've checked that
> enough memory is free, just start building the VM.  If you run out of
> memory part-way through, you can squeeze the other VMs back out so you can
> finish the job.

All of this revolves around 'squeezing' the existing guests from the
tool-stack side. And as such the options you enumerated are the right
way of fixing it. And also the ways Xapi are pretty good.

However that is not the problem we are trying to address. We do _not_ want
to squeeze the guest at all. We want to leave it up to the guest to
go and down as it sees fit. We just need to set the ceiling (at start
time, and this is d->max_pages), and let the guest increment/decrement
d->tot_pages as it sees fit. And while that is going on, still be able
to create new guests in parallel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 15:54:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 15: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 1U5IBg-0001GO-E7; Tue, 12 Feb 2013 15:54:28 +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 1U5IBf-0001G3-BV
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 15:54:27 +0000
Received: from [85.158.137.99:55566] by server-8.bemta-3.messagelabs.com id
	5B/A8-25687-2B56A115; Tue, 12 Feb 2013 15:54:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360684464!21107212!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE2NTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13569 invoked from network); 12 Feb 2013 15:54:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 15:54:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CFsCBk016065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 15:54:13 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
	r1CFsC5D022221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 15:54:12 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1CFsCn1020658; Tue, 12 Feb 2013 09:54:12 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 07:54:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4CF4B1BF781; Tue, 12 Feb 2013 10:54:10 -0500 (EST)
Date: Tue, 12 Feb 2013 10:54:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130212155410.GG3016@phenom.dumpdata.com>
References: <mailman.18000.1354568068.1399.xen-devel@lists.xen.org>
	<49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca>
	<20121218221749.GA6332@phenom.dumpdata.com>
	<AF146C82-5904-480C-80D0-7906AFD2B614@gridcentric.ca>
	<20130111160314.GD15353@phenom.dumpdata.com>
	<F2749668-D894-4DBA-BC48-D5CE8180C27F@gridcentric.ca>
	<20130111190814.GD29020@phenom.dumpdata.com>
	<20130117151631.GF19975@ocelot.phlegethon.org>
	<20130118214542.GB3047@phenom.dumpdata.com>
	<20130121102923.GA72616@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130121102923.GA72616@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 21, 2013 at 10:29:23AM +0000, Tim Deegan wrote:
> At 16:45 -0500 on 18 Jan (1358527542), Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 17, 2013 at 03:16:31PM +0000, Tim Deegan wrote:
> > > At 14:08 -0500 on 11 Jan (1357913294), Konrad Rzeszutek Wilk wrote:
> > > > But the solution to the hypercall failing are multiple - one is to 
> > > > try to "squeeze" all the guests to make space
> > > 
> > > AFAICT if the toolstack can squeeze guests up to make room then the
> > > reservation hypercall isn't necessary -- just use the squeezing
> > > mechanism to make sure that running VMs don't use up the memory you want
> > > for building new ones.
> > 
> > We might want to not do that until we have run out of options (this would
> > be a toolstack option to select the right choice). The other option is
> > to just launch the guest on another node.
> 
> Sure, I see that; but what I meant was: the reservation hypercall only
> makes any kind of sense if the toolstack can't squeeze the existing guests. 

OK. I am going to take the liberty here to assume that squeeze is setting
d->max_pages and kicking the guest to balloon down to some number.

> 
> If it can squeeze VMs, as part of that it must have some mechanism to
> stop them from immediately re-allocating all the memory as it frees it.
> So in the case where enough memory is already free, you just use that
> mechanism to protect it while you build the new VM.

Sure.
> 
> Or (since I get the impression that losing this allocation race is a
> rare event) you can take the optimistic route: after you've checked that
> enough memory is free, just start building the VM.  If you run out of
> memory part-way through, you can squeeze the other VMs back out so you can
> finish the job.

All of this revolves around 'squeezing' the existing guests from the
tool-stack side. And as such the options you enumerated are the right
way of fixing it. And also the ways Xapi are pretty good.

However that is not the problem we are trying to address. We do _not_ want
to squeeze the guest at all. We want to leave it up to the guest to
go and down as it sees fit. We just need to set the ceiling (at start
time, and this is d->max_pages), and let the guest increment/decrement
d->tot_pages as it sees fit. And while that is going on, still be able
to create new guests in parallel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 16:08:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16:08: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 1U5IPY-0002FD-0B; Tue, 12 Feb 2013 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 <JBeulich@suse.com>) id 1U5IPW-0002F8-9u
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:08:46 +0000
Received: from [85.158.143.35:57345] by server-2.bemta-4.messagelabs.com id
	58/FF-01597-D096A115; Tue, 12 Feb 2013 16:08:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360685094!10264382!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1630 invoked from network); 12 Feb 2013 16:04:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 16:04:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 16:04:53 +0000
Message-Id: <511A763302000078000BDC82@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 16:04:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
In-Reply-To: <CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 16:50, povder <povder@gmail.com> wrote:
> 2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>>
>> I don't see any devices on bus 7 in lspci output
>> (http://pastebin.com/raw.php?i=3wpKPQT9 from original report).
>>
>> However the log shows
>>
>> pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it
>> with 'pcie_aspm=force'
>> ..
>> (XEN) PCI add device 0000:07:00.0
>>
> 
> There is device 00:07.0 in lspci output from original report:
> 00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to
> PCI bridge (PCI express gpp port G) (prog-if 00 [Normal decode])

But we're seeing a device reported as 07:00.0; we don't care
about the one at 00:07.0.

You ought to explain where this device comes from, or why your
lspci output doesn't show it. Perhaps handing us a native kernel
boot log (at maximum log level) might already help...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 16:08:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16:08: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 1U5IPY-0002FD-0B; Tue, 12 Feb 2013 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 <JBeulich@suse.com>) id 1U5IPW-0002F8-9u
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:08:46 +0000
Received: from [85.158.143.35:57345] by server-2.bemta-4.messagelabs.com id
	58/FF-01597-D096A115; Tue, 12 Feb 2013 16:08:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360685094!10264382!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1630 invoked from network); 12 Feb 2013 16:04:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 16:04:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 16:04:53 +0000
Message-Id: <511A763302000078000BDC82@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 16:04:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
In-Reply-To: <CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 16:50, povder <povder@gmail.com> wrote:
> 2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>>
>> I don't see any devices on bus 7 in lspci output
>> (http://pastebin.com/raw.php?i=3wpKPQT9 from original report).
>>
>> However the log shows
>>
>> pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it
>> with 'pcie_aspm=force'
>> ..
>> (XEN) PCI add device 0000:07:00.0
>>
> 
> There is device 00:07.0 in lspci output from original report:
> 00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to
> PCI bridge (PCI express gpp port G) (prog-if 00 [Normal decode])

But we're seeing a device reported as 07:00.0; we don't care
about the one at 00:07.0.

You ought to explain where this device comes from, or why your
lspci output doesn't show it. Perhaps handing us a native kernel
boot log (at maximum log level) might already help...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 16:19:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16: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 1U5IZd-0002SG-61; Tue, 12 Feb 2013 16:19: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 1U5IZb-0002SB-A1
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:19:11 +0000
Received: from [85.158.138.51:7313] by server-8.bemta-3.messagelabs.com id
	B4/6A-25687-D7B6A115; Tue, 12 Feb 2013 16:19:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360685946!9322370!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjcyODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17565 invoked from network); 12 Feb 2013 16:19:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 16:19:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CGIqPX020808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 16:18:53 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
	r1CGIpZd008764
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 16:18:52 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
	r1CGIofV008954; Tue, 12 Feb 2013 10:18:51 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 08:18:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 456EB1BF781; Tue, 12 Feb 2013 11:18:49 -0500 (EST)
Date: Tue, 12 Feb 2013 11:18:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130212161849.GH3016@phenom.dumpdata.com>
References: <fedf0cad-8f7e-4ca3-a9fd-5b27bdce82b7@default>
	<1357635807.12649.94.camel@dagon.hellion.org.uk>
	<8c937ac1-3b79-4ca4-9637-f563f7d8eca8@default>
	<1357728078.7989.219.camel@zakaz.uk.xensource.com>
	<5692967d-11f4-4c44-be68-76a99f4ee482@default>
	<50F42827.60507@eu.citrix.com>
	<9be877bb-d38b-40c7-bae7-b66497f11abf@default>
	<50F45FBA.3000508@eu.citrix.com>
	<e9e4d7fd-ab7f-42bf-bbfa-a54330488e85@default>
	<1358943520.17440.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358943520.17440.38.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 23, 2013 at 12:18:40PM +0000, Ian Campbell wrote:
> On Mon, 2013-01-14 at 23:14 +0000, Dan Magenheimer wrote:
> > For the public record, I _partially_ believe #3.  I would restate it
> > as: You (and others with the same point-of-view) have a very fixed
> > idea of how memory-management should work in the Xen stack.  This
> > idea is not really implemented, AFAICT you haven't thought through
> > the policy issues, and you haven't yet realized the challenges
> > I believe it will present in the context of Oracle's dynamic model
> > (since AFAIK you have not understood tmem and selfballooning though
> > it is all open source upstream in Xen and Linux).
> 
> Putting aside any bias or fixed mindedness the maintainers are not
> especially happy with the proposed fix, even within the constraints of
> the dynamic model. (It omits to cover various use cases and I think
> strikes many as something of a sticking plaster).

Could you excuse my ignorance of idioms and explain what 'sticking plaster'
is in this context? Is it akin to 'duct-tape'?

> 
> Given that I've been trying to suggest an alternative solution which
> works within the constraints of you model and happens to have the nice
> property of not requiring hypervisor changes. I genuinely think there is
> a workable solution to your problem in there, although you are correct
> that it mostly just an idea right now.

This is mid.gmane.org/mid.gmane.org/20130121102923.GA72616@ocelot.phlegethon.org
right? Dan had some questions about it and some clarifications about
the premises of it. And in:
http://mid.gmane.org/1357743524.7989.266.camel@zakaz.uk.xensource.com

you mentioned that you will take a look back at it. Perhaps I am missing an
email?
> 
> That said the best suggestion for a solution I've seen so far was Tim's
> suggestion that tmem be more tightly integrated with memory allocation
> as another step towards the "memory scheduler" idea. So I wouldn't

Is this the mid.gmane.org/20130121102923.GA72616@ocelot.phlegethon.org ?

> bother pursuing the maxmem approach further unless the tmem-integration
> idea doesn't pan out for some reason.

Maxmem is which one? Is that the one that Xapi is using wherein the 
d->max_pages is set via the XEN_DOMCTL_max_mem hypercall?

> 
> 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 Feb 12 16:19:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16: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 1U5IZd-0002SG-61; Tue, 12 Feb 2013 16:19: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 1U5IZb-0002SB-A1
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:19:11 +0000
Received: from [85.158.138.51:7313] by server-8.bemta-3.messagelabs.com id
	B4/6A-25687-D7B6A115; Tue, 12 Feb 2013 16:19:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360685946!9322370!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjcyODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17565 invoked from network); 12 Feb 2013 16:19:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 16:19:08 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CGIqPX020808
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 16:18:53 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
	r1CGIpZd008764
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 16:18:52 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
	r1CGIofV008954; Tue, 12 Feb 2013 10:18:51 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 08:18:50 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 456EB1BF781; Tue, 12 Feb 2013 11:18:49 -0500 (EST)
Date: Tue, 12 Feb 2013 11:18:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130212161849.GH3016@phenom.dumpdata.com>
References: <fedf0cad-8f7e-4ca3-a9fd-5b27bdce82b7@default>
	<1357635807.12649.94.camel@dagon.hellion.org.uk>
	<8c937ac1-3b79-4ca4-9637-f563f7d8eca8@default>
	<1357728078.7989.219.camel@zakaz.uk.xensource.com>
	<5692967d-11f4-4c44-be68-76a99f4ee482@default>
	<50F42827.60507@eu.citrix.com>
	<9be877bb-d38b-40c7-bae7-b66497f11abf@default>
	<50F45FBA.3000508@eu.citrix.com>
	<e9e4d7fd-ab7f-42bf-bbfa-a54330488e85@default>
	<1358943520.17440.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358943520.17440.38.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Jan 23, 2013 at 12:18:40PM +0000, Ian Campbell wrote:
> On Mon, 2013-01-14 at 23:14 +0000, Dan Magenheimer wrote:
> > For the public record, I _partially_ believe #3.  I would restate it
> > as: You (and others with the same point-of-view) have a very fixed
> > idea of how memory-management should work in the Xen stack.  This
> > idea is not really implemented, AFAICT you haven't thought through
> > the policy issues, and you haven't yet realized the challenges
> > I believe it will present in the context of Oracle's dynamic model
> > (since AFAIK you have not understood tmem and selfballooning though
> > it is all open source upstream in Xen and Linux).
> 
> Putting aside any bias or fixed mindedness the maintainers are not
> especially happy with the proposed fix, even within the constraints of
> the dynamic model. (It omits to cover various use cases and I think
> strikes many as something of a sticking plaster).

Could you excuse my ignorance of idioms and explain what 'sticking plaster'
is in this context? Is it akin to 'duct-tape'?

> 
> Given that I've been trying to suggest an alternative solution which
> works within the constraints of you model and happens to have the nice
> property of not requiring hypervisor changes. I genuinely think there is
> a workable solution to your problem in there, although you are correct
> that it mostly just an idea right now.

This is mid.gmane.org/mid.gmane.org/20130121102923.GA72616@ocelot.phlegethon.org
right? Dan had some questions about it and some clarifications about
the premises of it. And in:
http://mid.gmane.org/1357743524.7989.266.camel@zakaz.uk.xensource.com

you mentioned that you will take a look back at it. Perhaps I am missing an
email?
> 
> That said the best suggestion for a solution I've seen so far was Tim's
> suggestion that tmem be more tightly integrated with memory allocation
> as another step towards the "memory scheduler" idea. So I wouldn't

Is this the mid.gmane.org/20130121102923.GA72616@ocelot.phlegethon.org ?

> bother pursuing the maxmem approach further unless the tmem-integration
> idea doesn't pan out for some reason.

Maxmem is which one? Is that the one that Xapi is using wherein the 
d->max_pages is set via the XEN_DOMCTL_max_mem hypercall?

> 
> 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 Feb 12 16:23:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16: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 1U5IdK-0002b7-TB; Tue, 12 Feb 2013 16:23: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 1U5IdI-0002b2-OM
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:23:00 +0000
Received: from [85.158.137.99:10833] by server-10.bemta-3.messagelabs.com id
	52/49-10609-36C6A115; Tue, 12 Feb 2013 16:22:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360686179!16432965!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2396 invoked from network); 12 Feb 2013 16:22:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 16:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1381491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 16:22: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.297.1; Tue, 12 Feb 2013 16:22:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5IdG-0000Ew-OP; Tue, 12 Feb 2013 16:22:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5IdG-0004Th-K4;
	Tue, 12 Feb 2013 16:22:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.27746.326464.442488@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 16:22:58 +0000
To: Xiantao Zhang <xiantao.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: keir@xen.org, jun.nakajima@intel.com, eddie.dong@intel.com, tim@xen.org,
	xen-devel@lists.xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT &
	VPID	support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xiantao Zhang writes ("[Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID support to L1 VMM"):
> From: Zhang Xiantao <xiantao.zhang@intel.com>
> 
> With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 guest's memory virtualization.
> In this way, L2 guest's performance can be improved sharply.
> According to our testing, some benchmarks can show > 5x performance gain.

I'm no expert on the areas of code you're touching, so perhaps you've
already done this, but:

I think there may need to be some high-level knob to turn this feature
on and off (probably, for individual guests).  This is because this
feature exposes a richer attack surface for guests (AFAICT).  I know
there's already a feature check for nested HVM, but I wonder if that's
enough.

I'd like to hear other people's opinions on this point.

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 Feb 12 16:23:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16: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 1U5IdK-0002b7-TB; Tue, 12 Feb 2013 16:23: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 1U5IdI-0002b2-OM
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:23:00 +0000
Received: from [85.158.137.99:10833] by server-10.bemta-3.messagelabs.com id
	52/49-10609-36C6A115; Tue, 12 Feb 2013 16:22:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360686179!16432965!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2396 invoked from network); 12 Feb 2013 16:22:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 16:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1381491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 16:22: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.297.1; Tue, 12 Feb 2013 16:22:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5IdG-0000Ew-OP; Tue, 12 Feb 2013 16:22:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5IdG-0004Th-K4;
	Tue, 12 Feb 2013 16:22:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.27746.326464.442488@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 16:22:58 +0000
To: Xiantao Zhang <xiantao.zhang@intel.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: keir@xen.org, jun.nakajima@intel.com, eddie.dong@intel.com, tim@xen.org,
	xen-devel@lists.xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT &
	VPID	support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xiantao Zhang writes ("[Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID support to L1 VMM"):
> From: Zhang Xiantao <xiantao.zhang@intel.com>
> 
> With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 guest's memory virtualization.
> In this way, L2 guest's performance can be improved sharply.
> According to our testing, some benchmarks can show > 5x performance gain.

I'm no expert on the areas of code you're touching, so perhaps you've
already done this, but:

I think there may need to be some high-level knob to turn this feature
on and off (probably, for individual guests).  This is because this
feature exposes a richer attack surface for guests (AFAICT).  I know
there's already a feature check for nested HVM, but I wonder if that's
enough.

I'd like to hear other people's opinions on this point.

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 Feb 12 16:53:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16:53: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 1U5J6U-0002wN-At; Tue, 12 Feb 2013 16:53:10 +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 1U5J6T-0002w9-4z
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:53:09 +0000
Received: from [193.109.254.147:26565] by server-9.bemta-14.messagelabs.com id
	B0/7F-30867-4737A115; Tue, 12 Feb 2013 16:53:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360687987!2288786!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24744 invoked from network); 12 Feb 2013 16:53:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 16:53:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 16:53:02 +0000
Message-Id: <511A817B02000078000BDCAC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 16:52:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Eddie Dong" <eddie.dong@intel.com>,
	"Jun Nakajima" <jun.nakajima@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jiongxi Li <jiongxi.li@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.01.13 at 04:23, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> This patchset fixes some APICV issues, including a potential issue while 
> doing live migration and enabling APICV while guest is in X2APIC mode.
> 
> PATCH 1/2: Xen: Fix live migration while enabling APICV.
> 
> PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling APICV.

Jun, Eddie - we're still waiting for an ack of at least one of you
on these two...

Thanks, Jan

> Changes v4 to v5
> Correct coding style. Add debug log in msr enable/disable intercept function 
> for out of range case.
> 
> Changes v3 to v4
> According to Jan's comment, add define for numbers used in 
> GUEST_INTR_STATUS, change function name.
> Use 'set_bit/clear_bit' instead of '__set_bit/__clear_bit'
> 
> Changes v2 to v3
> When enabling APICV for x2apic mode, ppr, tmict tmcct MSR read still need to 
> be intercepted.
> 
> Changes v1 to v2
> According to Keir's comment, don't change the save/restore order for 
> compatibility.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 16:53:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 16:53: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 1U5J6U-0002wN-At; Tue, 12 Feb 2013 16:53:10 +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 1U5J6T-0002w9-4z
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 16:53:09 +0000
Received: from [193.109.254.147:26565] by server-9.bemta-14.messagelabs.com id
	B0/7F-30867-4737A115; Tue, 12 Feb 2013 16:53:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360687987!2288786!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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24744 invoked from network); 12 Feb 2013 16:53:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Feb 2013 16:53:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 12 Feb 2013 16:53:02 +0000
Message-Id: <511A817B02000078000BDCAC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 12 Feb 2013 16:52:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Eddie Dong" <eddie.dong@intel.com>,
	"Jun Nakajima" <jun.nakajima@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jiongxi Li <jiongxi.li@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.01.13 at 04:23, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> This patchset fixes some APICV issues, including a potential issue while 
> doing live migration and enabling APICV while guest is in X2APIC mode.
> 
> PATCH 1/2: Xen: Fix live migration while enabling APICV.
> 
> PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling APICV.

Jun, Eddie - we're still waiting for an ack of at least one of you
on these two...

Thanks, Jan

> Changes v4 to v5
> Correct coding style. Add debug log in msr enable/disable intercept function 
> for out of range case.
> 
> Changes v3 to v4
> According to Jan's comment, add define for numbers used in 
> GUEST_INTR_STATUS, change function name.
> Use 'set_bit/clear_bit' instead of '__set_bit/__clear_bit'
> 
> Changes v2 to v3
> When enabling APICV for x2apic mode, ppr, tmict tmcct MSR read still need to 
> be intercepted.
> 
> Changes v1 to v2
> According to Keir's comment, don't change the save/restore order for 
> compatibility.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 17:36:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:36: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 1U5Jlm-0003sc-Re; Tue, 12 Feb 2013 17:35:50 +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 1U5Jlk-0003sV-MB
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 17:35:48 +0000
Received: from [85.158.137.99:26969] by server-11.bemta-3.messagelabs.com id
	8C/1B-10249-37D7A115; Tue, 12 Feb 2013 17:35:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360690546!12725996!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 12 Feb 2013 17:35:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:35:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1383767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 17:35: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.297.1; Tue, 12 Feb 2013 17:35:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Jlh-0000cT-NA; Tue, 12 Feb 2013 17:35:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Jlh-0004X8-Im;
	Tue, 12 Feb 2013 17:35:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.32113.322517.985897@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 17:35:45 +0000
To: =?utf-8?Q?=E9=A9=AC=E7=A3=8A?= <aware.why@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CA+ePHTBy8dAy18s-cJLWTTvHpZ3tmR4=kE_YF_RUQccENS3wkQ@mail.gmail.com>
References: <CA+ePHTAUcGdK5SHPq9av=-Yfa2zyLLKzcJXQ8BYBxOgVOcGtQQ@mail.gmail.com>
	<CD0F0954.56DFB%keir@xen.org>
	<CA+ePHTBy8dAy18s-cJLWTTvHpZ3tmR4=kE_YF_RUQccENS3wkQ@mail.gmail.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] seperate xen checkpoint file as three
 parts(for 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

6ams56OKIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0hdIHNlcGVyYXRlIHhlbiBjaGVj
a3BvaW50IGZpbGUgYXMgdGhyZWUgcGFydHMoZm9yIHhlbi00LjEuMikiKToKPiBUaGlzIGZlYXR1
cmUgY291bGQgYmUgY29uZmlndXJlZCB0byBiZSBvcHRpb25hbCBpbiBtYWtlIGZpbGUgY29uZmln
dXJhdGlvbgo+IGFjY29yZGluZyB0byBpbmRpdmlkdWFsIHByZWZlcmVuY2UuCgp4bCByZXN0b3Jl
IGFscmVhZHkgdGFrZXMgYSBjb21tYW5kIGxpbmUgcGFyYW1ldGVyIHRvIHNwZWNpZnkgYQpyZXBs
YWNlbWVudCBjb25maWcgZmlsZS4gIFdoeSBpcyB0aGF0IG5vdCBzdWZmaWNpZW50ID8KCj4gZm9y
IGV4YW1wbGUsIGlmIGkgd2FudCB0byByZXN0b3JlIGEgdm0gd2l0aCBkaWZmZXJlbnQgY29uZmln
dXJhdGlvbiBmcm9tIG1hYwo+IGFkZHJlc3MgdG8gdm0taWQsIHlvdSBuZWVkIHRvIG92ZXJyaWRl
IHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzdGF0ZSBmaWxlIGFuZAo+IG1heWJlIGFsc28gdGhlIHRo
aXJkIHBhcnQgaXMgbmVlZGVkIHRvIGJlIG1vZGlmaWVkIHN1Y2ggYXMgdGhlIGJ5dGVzIHJhbmdl
ICBmb3IKPiBtYWMgYWRkcmVzcyBpbiAgcWVtdSBzdGF0ZSBzZWN0aW9uLgoKWW91IGNhbid0IGV4
cGVjdCBhIGd1ZXN0IHRvIGNvcGUgd2l0aCBpdHMgbmV0d29yayBpbnRlcmZhY2UgY2hhbmdpbmcK
bWFjIGFkZHJlc3MgdW5kZXIgaXRzIGZlZXQuICBTbyB0aGlzIGlzbid0IGEgZ29vZCBleGFtcGxl
LgoKSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 12 17:36:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:36: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 1U5Jlm-0003sc-Re; Tue, 12 Feb 2013 17:35:50 +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 1U5Jlk-0003sV-MB
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 17:35:48 +0000
Received: from [85.158.137.99:26969] by server-11.bemta-3.messagelabs.com id
	8C/1B-10249-37D7A115; Tue, 12 Feb 2013 17:35:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360690546!12725996!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 12 Feb 2013 17:35:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:35:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1383767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 17:35: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.297.1; Tue, 12 Feb 2013 17:35:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5Jlh-0000cT-NA; Tue, 12 Feb 2013 17:35:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5Jlh-0004X8-Im;
	Tue, 12 Feb 2013 17:35:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.32113.322517.985897@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 17:35:45 +0000
To: =?utf-8?Q?=E9=A9=AC=E7=A3=8A?= <aware.why@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CA+ePHTBy8dAy18s-cJLWTTvHpZ3tmR4=kE_YF_RUQccENS3wkQ@mail.gmail.com>
References: <CA+ePHTAUcGdK5SHPq9av=-Yfa2zyLLKzcJXQ8BYBxOgVOcGtQQ@mail.gmail.com>
	<CD0F0954.56DFB%keir@xen.org>
	<CA+ePHTBy8dAy18s-cJLWTTvHpZ3tmR4=kE_YF_RUQccENS3wkQ@mail.gmail.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] seperate xen checkpoint file as three
 parts(for 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

6ams56OKIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0hdIHNlcGVyYXRlIHhlbiBjaGVj
a3BvaW50IGZpbGUgYXMgdGhyZWUgcGFydHMoZm9yIHhlbi00LjEuMikiKToKPiBUaGlzIGZlYXR1
cmUgY291bGQgYmUgY29uZmlndXJlZCB0byBiZSBvcHRpb25hbCBpbiBtYWtlIGZpbGUgY29uZmln
dXJhdGlvbgo+IGFjY29yZGluZyB0byBpbmRpdmlkdWFsIHByZWZlcmVuY2UuCgp4bCByZXN0b3Jl
IGFscmVhZHkgdGFrZXMgYSBjb21tYW5kIGxpbmUgcGFyYW1ldGVyIHRvIHNwZWNpZnkgYQpyZXBs
YWNlbWVudCBjb25maWcgZmlsZS4gIFdoeSBpcyB0aGF0IG5vdCBzdWZmaWNpZW50ID8KCj4gZm9y
IGV4YW1wbGUsIGlmIGkgd2FudCB0byByZXN0b3JlIGEgdm0gd2l0aCBkaWZmZXJlbnQgY29uZmln
dXJhdGlvbiBmcm9tIG1hYwo+IGFkZHJlc3MgdG8gdm0taWQsIHlvdSBuZWVkIHRvIG92ZXJyaWRl
IHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzdGF0ZSBmaWxlIGFuZAo+IG1heWJlIGFsc28gdGhlIHRo
aXJkIHBhcnQgaXMgbmVlZGVkIHRvIGJlIG1vZGlmaWVkIHN1Y2ggYXMgdGhlIGJ5dGVzIHJhbmdl
ICBmb3IKPiBtYWMgYWRkcmVzcyBpbiAgcWVtdSBzdGF0ZSBzZWN0aW9uLgoKWW91IGNhbid0IGV4
cGVjdCBhIGd1ZXN0IHRvIGNvcGUgd2l0aCBpdHMgbmV0d29yayBpbnRlcmZhY2UgY2hhbmdpbmcK
bWFjIGFkZHJlc3MgdW5kZXIgaXRzIGZlZXQuICBTbyB0aGlzIGlzbid0IGEgZ29vZCBleGFtcGxl
LgoKSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlz
dHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 12 17:45:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17: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 1U5JuQ-00045F-Ss; Tue, 12 Feb 2013 17:44:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5JuP-00045A-Rk
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 17:44:46 +0000
Received: from [85.158.143.35:36338] by server-3.bemta-4.messagelabs.com id
	7D/43-08920-D8F7A115; Tue, 12 Feb 2013 17:44:45 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1360691081!4782465!1
X-Originating-IP: [209.85.223.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24849 invoked from network); 12 Feb 2013 17:44:43 -0000
Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com)
	(209.85.223.182)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:44:43 -0000
Received: by mail-ie0-f182.google.com with SMTP id k14so462023iea.41
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 09:44:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=RD4LH2MK92ZWeSahrH0aZ16jqQ8+/CNEZkUtWIAvjLo=;
	b=wRZkFMd1IFQHZLliz+o7RKPqiSJ7xC06RgJSyAhW6Pv1PgjU4RoF7AQMYgKXeNwR/N
	cYo8g6UdbX1CmN46TVOS9tIw6/xxCRu9bwgaFbtpivpuscVSTYgzoh7ovQ5W5gv5pUY5
	+q+DZGNKaz6Gid/jbtw7x/u/qbkSYO5m8a+b5xIjPTzvhanNXgW5Xa3B7MeVHSIrzCxX
	SpBtphxLmcrpSqtBy3GD7S8wgPWSA7v9BZdjUDpGpK+hWEpa+FsR29ZtxGWQZdLKfk79
	h1FrfgpC8Uavh2MsQ03aa0s+XdnEsi23ubEdO9X30ITheyh77AFEBlgNJzK2tw8aTkmI
	CaMA==
X-Received: by 10.50.183.167 with SMTP id en7mr4951337igc.58.1360691062258;
	Tue, 12 Feb 2013 09:44:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 09:44:02 -0800 (PST)
In-Reply-To: <511A763302000078000BDC82@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 18:44:02 +0100
Message-ID: <CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>>> On 12.02.13 at 16:50, povder <povder@gmail.com> wrote:
>> 2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>>>
>>> I don't see any devices on bus 7 in lspci output
>>> (http://pastebin.com/raw.php?i=3wpKPQT9 from original report).
>>>
>>> However the log shows
>>>
>>> pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it
>>> with 'pcie_aspm=force'
>>> ..
>>> (XEN) PCI add device 0000:07:00.0
>>>
>>
>> There is device 00:07.0 in lspci output from original report:
>> 00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to
>> PCI bridge (PCI express gpp port G) (prog-if 00 [Normal decode])
>
> But we're seeing a device reported as 07:00.0; we don't care
> about the one at 00:07.0.
>
> You ought to explain where this device comes from, or why your
> lspci output doesn't show it. Perhaps handing us a native kernel
> boot log (at maximum log level) might already help...
>
> Jan
>

Sorry, I've mistaken 00:07.0 with 07:00.0. I'll post some more info soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 17:45:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17: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 1U5JuQ-00045F-Ss; Tue, 12 Feb 2013 17:44:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5JuP-00045A-Rk
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 17:44:46 +0000
Received: from [85.158.143.35:36338] by server-3.bemta-4.messagelabs.com id
	7D/43-08920-D8F7A115; Tue, 12 Feb 2013 17:44:45 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1360691081!4782465!1
X-Originating-IP: [209.85.223.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24849 invoked from network); 12 Feb 2013 17:44:43 -0000
Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com)
	(209.85.223.182)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:44:43 -0000
Received: by mail-ie0-f182.google.com with SMTP id k14so462023iea.41
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 09:44:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=RD4LH2MK92ZWeSahrH0aZ16jqQ8+/CNEZkUtWIAvjLo=;
	b=wRZkFMd1IFQHZLliz+o7RKPqiSJ7xC06RgJSyAhW6Pv1PgjU4RoF7AQMYgKXeNwR/N
	cYo8g6UdbX1CmN46TVOS9tIw6/xxCRu9bwgaFbtpivpuscVSTYgzoh7ovQ5W5gv5pUY5
	+q+DZGNKaz6Gid/jbtw7x/u/qbkSYO5m8a+b5xIjPTzvhanNXgW5Xa3B7MeVHSIrzCxX
	SpBtphxLmcrpSqtBy3GD7S8wgPWSA7v9BZdjUDpGpK+hWEpa+FsR29ZtxGWQZdLKfk79
	h1FrfgpC8Uavh2MsQ03aa0s+XdnEsi23ubEdO9X30ITheyh77AFEBlgNJzK2tw8aTkmI
	CaMA==
X-Received: by 10.50.183.167 with SMTP id en7mr4951337igc.58.1360691062258;
	Tue, 12 Feb 2013 09:44:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 09:44:02 -0800 (PST)
In-Reply-To: <511A763302000078000BDC82@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 18:44:02 +0100
Message-ID: <CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
>>>> On 12.02.13 at 16:50, povder <povder@gmail.com> wrote:
>> 2013/2/12 Boris Ostrovsky <boris.ostrovsky@oracle.com>:
>>>
>>> I don't see any devices on bus 7 in lspci output
>>> (http://pastebin.com/raw.php?i=3wpKPQT9 from original report).
>>>
>>> However the log shows
>>>
>>> pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it
>>> with 'pcie_aspm=force'
>>> ..
>>> (XEN) PCI add device 0000:07:00.0
>>>
>>
>> There is device 00:07.0 in lspci output from original report:
>> 00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to
>> PCI bridge (PCI express gpp port G) (prog-if 00 [Normal decode])
>
> But we're seeing a device reported as 07:00.0; we don't care
> about the one at 00:07.0.
>
> You ought to explain where this device comes from, or why your
> lspci output doesn't show it. Perhaps handing us a native kernel
> boot log (at maximum log level) might already help...
>
> Jan
>

Sorry, I've mistaken 00:07.0 with 07:00.0. I'll post some more info soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 17:55:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:55: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 1U5K4g-0004G2-1k; Tue, 12 Feb 2013 17:55:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jun.nakajima@intel.com>) id 1U5K4e-0004Fx-W1
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 17:55:21 +0000
Received: from [85.158.143.99:35178] by server-1.bemta-4.messagelabs.com id
	C6/3F-08839-8028A115; Tue, 12 Feb 2013 17:55:20 +0000
X-Env-Sender: jun.nakajima@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360691716!24999327!1
X-Originating-IP: [209.85.215.47]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22907 invoked from network); 12 Feb 2013 17:55:16 -0000
Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com)
	(209.85.215.47)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:55:16 -0000
Received: by mail-la0-f47.google.com with SMTP id fj20so352480lab.34
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 09:54:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=8rh6LRGxNi6aAVZCycwxJ3I5+dzpTGXf/hT+Vdz5kqE=;
	b=NEq5zaohJnymLRrNXrRzk2/75nR2whJksRHZ7IdCkLisXXRZJryFKPkxCnaLuhG28q
	sdxqcMH7xbbPAxDlgFK67mBTFWimLNmbbW3ciIcZkcQ8+mNN/5CxNc+GhyHjcpo0qKQ0
	1mzTtfZLyajVcLKkPbalUghOt7ShEWh3cw5R2VlGZcMFT5Am5x/EHRn50wUkyGSVE8oZ
	VABbJfQGLrktEPzWbo4JGXZqEfutLU4ByGqceu+jhhwq6JUTpda4SY09IrYpM+TQZWMz
	L5YenBN/5scQBdTgJEE0yCcz4OJ8Jab75BHLVUJcOLKavqzsaczzW+me3QR6VoObkjJF
	fcnA==
MIME-Version: 1.0
X-Received: by 10.152.130.131 with SMTP id oe3mr9305237lab.1.1360691656707;
	Tue, 12 Feb 2013 09:54:16 -0800 (PST)
Received: by 10.114.18.231 with HTTP; Tue, 12 Feb 2013 09:54:16 -0800 (PST)
In-Reply-To: <20762.27746.326464.442488@mariner.uk.xensource.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
	<20762.27746.326464.442488@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 09:54:16 -0800
Message-ID: <CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQkIqBNkf4gw2FEubzcYSXi0Lj07UMs6o8FBXPtaXbRgtbl8uIijSeSU5C1SfGEwlHslv1pN
Cc: keir@xen.org, eddie.dong@intel.com, tim@xen.org, xen-devel@lists.xen.org,
	JBeulich@suse.com, Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID
 support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5868557228751169791=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5868557228751169791==
Content-Type: multipart/alternative; boundary=f46d04095bf7d8cffe04d58ab6ab

--f46d04095bf7d8cffe04d58ab6ab
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 12, 2013 at 8:22 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Xiantao Zhang writes ("[Xen-devel] [PATCH v4 00/10] Nested VMX: Add
> virtual EPT & VPID support to L1 VMM"):
> > From: Zhang Xiantao <xiantao.zhang@intel.com>
> >
> > With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2
> guest's memory virtualization.
> > In this way, L2 guest's performance can be improved sharply.
> > According to our testing, some benchmarks can show > 5x performance gain.
>
> I'm no expert on the areas of code you're touching, so perhaps you've
> already done this, but:
>
> I think there may need to be some high-level knob to turn this feature
> on and off (probably, for individual guests).  This is because this
> feature exposes a richer attack surface for guests (AFAICT).  I know
> there's already a feature check for nested HVM, but I wonder if that's
> enough.
>

I agree that the feature does or can expose a richer attack surface for
guests today. We need to set "nestedhvm" in the config ('false' by default)
for each guest, to turn on the feature, as far as I know. I don't think we
need a global switch like a boot parameter for Xen at this point.

-- 
Jun
Intel Open Source Technology Center

--f46d04095bf7d8cffe04d58ab6ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 12, 2013 at 8:22 AM, Ian Jackson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:Ian.Jackson@eu.citrix.com" target=3D"_blank">Ian.Jackson@eu.citr=
ix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
Xiantao Zhang writes (&quot;[Xen-devel] [PATCH v4 00/10] Nested VMX: Add vi=
rtual EPT &amp; VPID support to L1 VMM&quot;):<br>
&gt; From: Zhang Xiantao &lt;<a href=3D"mailto:xiantao.zhang@intel.com">xia=
ntao.zhang@intel.com</a>&gt;<br>
&gt;<br>
&gt; With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 gu=
est&#39;s memory virtualization.<br>
&gt; In this way, L2 guest&#39;s performance can be improved sharply.<br>
&gt; According to our testing, some benchmarks can show &gt; 5x performance=
 gain.<br>
<br>
I&#39;m no expert on the areas of code you&#39;re touching, so perhaps you&=
#39;ve<br>
already done this, but:<br>
<br>
I think there may need to be some high-level knob to turn this feature<br>
on and off (probably, for individual guests). =A0This is because this<br>
feature exposes a richer attack surface for guests (AFAICT). =A0I know<br>
there&#39;s already a feature check for nested HVM, but I wonder if that&#3=
9;s<br>
enough.<br></blockquote><div><br></div><div>I agree that the feature does o=
r can expose a richer attack surface for guests today. We need to set &quot=
;nestedhvm&quot; in the config (&#39;false&#39; by default) for each guest,=
 to turn on the feature, as far as I know. I don&#39;t think we need a glob=
al switch like a boot parameter for Xen at this point.=A0</div>
<div><br></div></div>-- <br><div><div>Jun</div><div><div>Intel Open Source =
Technology Center</div></div></div>

--f46d04095bf7d8cffe04d58ab6ab--


--===============5868557228751169791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5868557228751169791==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 17:55:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:55: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 1U5K4g-0004G2-1k; Tue, 12 Feb 2013 17:55:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jun.nakajima@intel.com>) id 1U5K4e-0004Fx-W1
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 17:55:21 +0000
Received: from [85.158.143.99:35178] by server-1.bemta-4.messagelabs.com id
	C6/3F-08839-8028A115; Tue, 12 Feb 2013 17:55:20 +0000
X-Env-Sender: jun.nakajima@intel.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360691716!24999327!1
X-Originating-IP: [209.85.215.47]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22907 invoked from network); 12 Feb 2013 17:55:16 -0000
Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com)
	(209.85.215.47)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:55:16 -0000
Received: by mail-la0-f47.google.com with SMTP id fj20so352480lab.34
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 09:54:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=8rh6LRGxNi6aAVZCycwxJ3I5+dzpTGXf/hT+Vdz5kqE=;
	b=NEq5zaohJnymLRrNXrRzk2/75nR2whJksRHZ7IdCkLisXXRZJryFKPkxCnaLuhG28q
	sdxqcMH7xbbPAxDlgFK67mBTFWimLNmbbW3ciIcZkcQ8+mNN/5CxNc+GhyHjcpo0qKQ0
	1mzTtfZLyajVcLKkPbalUghOt7ShEWh3cw5R2VlGZcMFT5Am5x/EHRn50wUkyGSVE8oZ
	VABbJfQGLrktEPzWbo4JGXZqEfutLU4ByGqceu+jhhwq6JUTpda4SY09IrYpM+TQZWMz
	L5YenBN/5scQBdTgJEE0yCcz4OJ8Jab75BHLVUJcOLKavqzsaczzW+me3QR6VoObkjJF
	fcnA==
MIME-Version: 1.0
X-Received: by 10.152.130.131 with SMTP id oe3mr9305237lab.1.1360691656707;
	Tue, 12 Feb 2013 09:54:16 -0800 (PST)
Received: by 10.114.18.231 with HTTP; Tue, 12 Feb 2013 09:54:16 -0800 (PST)
In-Reply-To: <20762.27746.326464.442488@mariner.uk.xensource.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
	<20762.27746.326464.442488@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 09:54:16 -0800
Message-ID: <CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQkIqBNkf4gw2FEubzcYSXi0Lj07UMs6o8FBXPtaXbRgtbl8uIijSeSU5C1SfGEwlHslv1pN
Cc: keir@xen.org, eddie.dong@intel.com, tim@xen.org, xen-devel@lists.xen.org,
	JBeulich@suse.com, Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID
 support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5868557228751169791=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5868557228751169791==
Content-Type: multipart/alternative; boundary=f46d04095bf7d8cffe04d58ab6ab

--f46d04095bf7d8cffe04d58ab6ab
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 12, 2013 at 8:22 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Xiantao Zhang writes ("[Xen-devel] [PATCH v4 00/10] Nested VMX: Add
> virtual EPT & VPID support to L1 VMM"):
> > From: Zhang Xiantao <xiantao.zhang@intel.com>
> >
> > With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2
> guest's memory virtualization.
> > In this way, L2 guest's performance can be improved sharply.
> > According to our testing, some benchmarks can show > 5x performance gain.
>
> I'm no expert on the areas of code you're touching, so perhaps you've
> already done this, but:
>
> I think there may need to be some high-level knob to turn this feature
> on and off (probably, for individual guests).  This is because this
> feature exposes a richer attack surface for guests (AFAICT).  I know
> there's already a feature check for nested HVM, but I wonder if that's
> enough.
>

I agree that the feature does or can expose a richer attack surface for
guests today. We need to set "nestedhvm" in the config ('false' by default)
for each guest, to turn on the feature, as far as I know. I don't think we
need a global switch like a boot parameter for Xen at this point.

-- 
Jun
Intel Open Source Technology Center

--f46d04095bf7d8cffe04d58ab6ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 12, 2013 at 8:22 AM, Ian Jackson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:Ian.Jackson@eu.citrix.com" target=3D"_blank">Ian.Jackson@eu.citr=
ix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
Xiantao Zhang writes (&quot;[Xen-devel] [PATCH v4 00/10] Nested VMX: Add vi=
rtual EPT &amp; VPID support to L1 VMM&quot;):<br>
&gt; From: Zhang Xiantao &lt;<a href=3D"mailto:xiantao.zhang@intel.com">xia=
ntao.zhang@intel.com</a>&gt;<br>
&gt;<br>
&gt; With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 gu=
est&#39;s memory virtualization.<br>
&gt; In this way, L2 guest&#39;s performance can be improved sharply.<br>
&gt; According to our testing, some benchmarks can show &gt; 5x performance=
 gain.<br>
<br>
I&#39;m no expert on the areas of code you&#39;re touching, so perhaps you&=
#39;ve<br>
already done this, but:<br>
<br>
I think there may need to be some high-level knob to turn this feature<br>
on and off (probably, for individual guests). =A0This is because this<br>
feature exposes a richer attack surface for guests (AFAICT). =A0I know<br>
there&#39;s already a feature check for nested HVM, but I wonder if that&#3=
9;s<br>
enough.<br></blockquote><div><br></div><div>I agree that the feature does o=
r can expose a richer attack surface for guests today. We need to set &quot=
;nestedhvm&quot; in the config (&#39;false&#39; by default) for each guest,=
 to turn on the feature, as far as I know. I don&#39;t think we need a glob=
al switch like a boot parameter for Xen at this point.=A0</div>
<div><br></div></div>-- <br><div><div>Jun</div><div><div>Intel Open Source =
Technology Center</div></div></div>

--f46d04095bf7d8cffe04d58ab6ab--


--===============5868557228751169791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5868557228751169791==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 17:56:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:56: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 1U5K5v-0004JD-HZ; Tue, 12 Feb 2013 17:56: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 1U5K5u-0004J3-38
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 17:56:38 +0000
Received: from [85.158.139.83:9754] by server-5.bemta-5.messagelabs.com id
	BC/FC-11945-5528A115; Tue, 12 Feb 2013 17:56:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360691796!21077635!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18876 invoked from network); 12 Feb 2013 17:56:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:56:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1384622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 17: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.297.1; Tue, 12 Feb 2013 17:56:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5K5r-0000it-RC; Tue, 12 Feb 2013 17:56:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5K5r-0004YQ-NG;
	Tue, 12 Feb 2013 17:56:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.33363.606499.35682@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 17:56:35 +0000
To: "Nakajima, Jun" <jun.nakajima@intel.com>
In-Reply-To: <CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
	<20762.27746.326464.442488@mariner.uk.xensource.com>
	<CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID
 support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nakajima, Jun writes ("Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID support to L1 VMM"):
> I agree that the feature does or can expose a richer attack surface
> for guests today. We need to set "nestedhvm" in the config ('false'
> by default) for each guest, to turn on the feature, as far as I
> know. I don't think we need a global switch like a boot parameter
> for Xen at this point.

Yes, but my point was whether the "nestedhvm" switch is sufficient.
As I understand it nestedhvm with virtual EPT provides a richer attack
surface than without.  So the question is whether we should provide a
switch to disable virtual EPT while leaving nestedhvm 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 Feb 12 17:56:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:56: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 1U5K5v-0004JD-HZ; Tue, 12 Feb 2013 17:56: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 1U5K5u-0004J3-38
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 17:56:38 +0000
Received: from [85.158.139.83:9754] by server-5.bemta-5.messagelabs.com id
	BC/FC-11945-5528A115; Tue, 12 Feb 2013 17:56:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360691796!21077635!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18876 invoked from network); 12 Feb 2013 17:56:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:56:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1384622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 17: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.297.1; Tue, 12 Feb 2013 17:56:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5K5r-0000it-RC; Tue, 12 Feb 2013 17:56:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5K5r-0004YQ-NG;
	Tue, 12 Feb 2013 17:56:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.33363.606499.35682@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 17:56:35 +0000
To: "Nakajima, Jun" <jun.nakajima@intel.com>
In-Reply-To: <CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
	<20762.27746.326464.442488@mariner.uk.xensource.com>
	<CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID
 support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Nakajima, Jun writes ("Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID support to L1 VMM"):
> I agree that the feature does or can expose a richer attack surface
> for guests today. We need to set "nestedhvm" in the config ('false'
> by default) for each guest, to turn on the feature, as far as I
> know. I don't think we need a global switch like a boot parameter
> for Xen at this point.

Yes, but my point was whether the "nestedhvm" switch is sufficient.
As I understand it nestedhvm with virtual EPT provides a richer attack
surface than without.  So the question is whether we should provide a
switch to disable virtual EPT while leaving nestedhvm 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 Feb 12 17:58:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:58: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 1U5K7D-0004PS-5M; Tue, 12 Feb 2013 17:57: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 1U5K7C-0004PI-EO
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 17:57:58 +0000
Received: from [85.158.143.99:46260] by server-1.bemta-4.messagelabs.com id
	D3/31-08839-5A28A115; Tue, 12 Feb 2013 17:57:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360691877!24771094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 12 Feb 2013 17:57:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:57:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1384670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 17:57: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.297.1; Tue, 12 Feb 2013 17:57:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5K7A-0000jM-U0; Tue, 12 Feb 2013 17:57:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5K7A-0004Ye-QP;
	Tue, 12 Feb 2013 17:57:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.33440.178465.605902@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 17:57:52 +0000
To: Thanos Makatos <thanos.makatos@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <dd63f2992e71a1e43abf.1360344253@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
	<dd63f2992e71a1e43abf.1360344253@makatos-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, andrei.lifchits@citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3
	is	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanos Makatos writes ("[Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3 is available"):
> This patch implements function libxl__blktap3_enabled, the equivalent of the
> existing libxl__blktap_enabled for blktap2. The checks performed are rather
> simple and should be extended.
...
> +/* FIXME get the tapback name from blktap3 instead of hard-coding */
> +#define TAPBACK_NAME "tapback"
> +#define CMD "pidof " TAPBACK_NAME

I'm afraid I'm fundamentally unhappy with this approach to detecting
the availability of blktap3.  Searching the process table for process
with particular names is not a good idea.

Can't you try to connect to its control socket ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 17:58:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 17:58: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 1U5K7D-0004PS-5M; Tue, 12 Feb 2013 17:57: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 1U5K7C-0004PI-EO
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 17:57:58 +0000
Received: from [85.158.143.99:46260] by server-1.bemta-4.messagelabs.com id
	D3/31-08839-5A28A115; Tue, 12 Feb 2013 17:57:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360691877!24771094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 12 Feb 2013 17:57:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 17:57:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1384670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 17:57: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.297.1; Tue, 12 Feb 2013 17:57:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5K7A-0000jM-U0; Tue, 12 Feb 2013 17:57:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5K7A-0004Ye-QP;
	Tue, 12 Feb 2013 17:57:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.33440.178465.605902@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 17:57:52 +0000
To: Thanos Makatos <thanos.makatos@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <dd63f2992e71a1e43abf.1360344253@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
	<dd63f2992e71a1e43abf.1360344253@makatos-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, andrei.lifchits@citrix.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3
	is	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanos Makatos writes ("[Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3 is available"):
> This patch implements function libxl__blktap3_enabled, the equivalent of the
> existing libxl__blktap_enabled for blktap2. The checks performed are rather
> simple and should be extended.
...
> +/* FIXME get the tapback name from blktap3 instead of hard-coding */
> +#define TAPBACK_NAME "tapback"
> +#define CMD "pidof " TAPBACK_NAME

I'm afraid I'm fundamentally unhappy with this approach to detecting
the availability of blktap3.  Searching the process table for process
with particular names is not a good idea.

Can't you try to connect to its control socket ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 18:02:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18:02: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 1U5KB1-0004jL-VZ; Tue, 12 Feb 2013 18:01: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 1U5KAz-0004jD-Tw
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 18:01:54 +0000
Received: from [85.158.139.211:32775] by server-13.bemta-5.messagelabs.com id
	2F/2A-06769-1938A115; Tue, 12 Feb 2013 18:01:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360692112!21810884!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17253 invoked from network); 12 Feb 2013 18:01:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1384736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 18:01: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.297.1; Tue, 12 Feb 2013 18:01:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5KAy-0000kS-7h; Tue, 12 Feb 2013 18:01:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5KAy-0004Z0-36;
	Tue, 12 Feb 2013 18:01:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.33679.974580.589786@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 18:01:51 +0000
To: Thanos Makatos <thanos.makatos@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6b54db4abe1276e1003d.1360344254@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
	<6b54db4abe1276e1003d.1360344254@makatos-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, andrei.lifchits@citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3
	device in	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

Thanos Makatos writes ("[Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3 device in libxl"):
> Handling of blktap3 devices is similar to blktap2, except that libxl doesn't
> spawn the tapdisk and doesn't create the physical device in dom0.
...
> +            case LIBXL_DISK_BACKEND_TAP3:
> +                flexarray_append(back, "params");
> +                flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> +                    libxl__device_disk_string_of_format(disk->format),
> +                    disk->pdev_path));
> +                break;
>              case LIBXL_DISK_BACKEND_QDISK:
>                  flexarray_append(back, "params");
>                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",

This seems to duplicate much of the entry for
LIBXL_DISK_BACKEND_QDISK.  I think this could be profitably
reorganised to avoid clone-and-hack.

> diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Fri Feb 08 17:23:25 2013 +0000
> +++ b/tools/libxl/libxl_device.c	Fri Feb 08 17:23:26 2013 +0000
> @@ -190,6 +190,23 @@ static int disk_try_backend(disk_try_bac
>          }
>          return backend;
>  
> +    case LIBXL_DISK_BACKEND_TAP3:
> +        /* TODO What's that script thing? */
> +        if (a->disk->script) goto bad_script;

Is this series supposed to be an RFC ?  It still has the odd TODO and
FIXME in it.

A disk script is an external script which arranges to provision a
block device for use by guests (and dom0).  It's an alternative to
TAP3 so I think you can just delete the comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 18:02:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18:02: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 1U5KB1-0004jL-VZ; Tue, 12 Feb 2013 18:01: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 1U5KAz-0004jD-Tw
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 18:01:54 +0000
Received: from [85.158.139.211:32775] by server-13.bemta-5.messagelabs.com id
	2F/2A-06769-1938A115; Tue, 12 Feb 2013 18:01:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360692112!21810884!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17253 invoked from network); 12 Feb 2013 18:01:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1384736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 18:01: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.297.1; Tue, 12 Feb 2013 18:01:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5KAy-0000kS-7h; Tue, 12 Feb 2013 18:01:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5KAy-0004Z0-36;
	Tue, 12 Feb 2013 18:01:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.33679.974580.589786@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 18:01:51 +0000
To: Thanos Makatos <thanos.makatos@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6b54db4abe1276e1003d.1360344254@makatos-desktop>
References: <patchbomb.1360344251@makatos-desktop>
	<6b54db4abe1276e1003d.1360344254@makatos-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, andrei.lifchits@citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3
	device in	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

Thanos Makatos writes ("[Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3 device in libxl"):
> Handling of blktap3 devices is similar to blktap2, except that libxl doesn't
> spawn the tapdisk and doesn't create the physical device in dom0.
...
> +            case LIBXL_DISK_BACKEND_TAP3:
> +                flexarray_append(back, "params");
> +                flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> +                    libxl__device_disk_string_of_format(disk->format),
> +                    disk->pdev_path));
> +                break;
>              case LIBXL_DISK_BACKEND_QDISK:
>                  flexarray_append(back, "params");
>                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",

This seems to duplicate much of the entry for
LIBXL_DISK_BACKEND_QDISK.  I think this could be profitably
reorganised to avoid clone-and-hack.

> diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Fri Feb 08 17:23:25 2013 +0000
> +++ b/tools/libxl/libxl_device.c	Fri Feb 08 17:23:26 2013 +0000
> @@ -190,6 +190,23 @@ static int disk_try_backend(disk_try_bac
>          }
>          return backend;
>  
> +    case LIBXL_DISK_BACKEND_TAP3:
> +        /* TODO What's that script thing? */
> +        if (a->disk->script) goto bad_script;

Is this series supposed to be an RFC ?  It still has the odd TODO and
FIXME in it.

A disk script is an external script which arranges to provision a
block device for use by guests (and dom0).  It's an alternative to
TAP3 so I think you can just delete the comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 18:20:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18:20: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 1U5KSp-0004x8-M4; Tue, 12 Feb 2013 18:20:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jun.nakajima@intel.com>) id 1U5KSn-0004x3-Qr
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 18:20:18 +0000
Received: from [85.158.139.211:54343] by server-10.bemta-5.messagelabs.com id
	9D/52-04697-1E78A115; Tue, 12 Feb 2013 18:20:17 +0000
X-Env-Sender: jun.nakajima@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360693215!22162534!1
X-Originating-IP: [209.85.215.46]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16633 invoked from network); 12 Feb 2013 18:20:16 -0000
Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com)
	(209.85.215.46)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:20:16 -0000
Received: by mail-la0-f46.google.com with SMTP id fq12so378780lab.19
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 10:20:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=LspPtLiTZFZfk8o/Px57MqvcQbRP1YRSQmeGTvjSEJI=;
	b=cPgWFBzCQW19Ms3ZCdIg1gcTLts0Hb0qHOIMI531rp/Z/s2sRZzvam5HyFZesBIpqw
	+hKjDXqMF7G1DDcbp+77tfU4YKI1mv7mIANcxGLXTUSV++sCjcI6wZlmMg3j6xLujuVz
	HeJr3ZPOZqqino02TNm5C+46J+uaPzvqXy2RtI1t61WRr1TfNyI9tS/hDOw7F9IkXq4o
	NtxQ9B39bYLUrRnAtt2BWk2KroSqKiVIVaVt1jDBOH9FSaEB54wyqq1Qnh/lK6ULT/hI
	ylaZu+4qZJrge2olEMxWoyovVFql5ADxH0Vrv8sPCiw9AElgaOzru2vJMOZBjfRvU2f/
	eEZw==
MIME-Version: 1.0
X-Received: by 10.152.109.146 with SMTP id hs18mr17557138lab.8.1360693215307; 
	Tue, 12 Feb 2013 10:20:15 -0800 (PST)
Received: by 10.114.18.231 with HTTP; Tue, 12 Feb 2013 10:20:15 -0800 (PST)
In-Reply-To: <20762.33363.606499.35682@mariner.uk.xensource.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
	<20762.27746.326464.442488@mariner.uk.xensource.com>
	<CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
	<20762.33363.606499.35682@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 10:20:15 -0800
Message-ID: <CAL54oT2XJwKzUvnjiS-J5ufjppmNhbNO8b7Was8TiPh98pvYuA@mail.gmail.com>
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQkM43PjtPq4MD4ciw4ii2hu02Nj9ItY+axmv+o4rwKH1r8L4+StLluwJNGnGoj7JPwvilXP
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID
 support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8488845445191103219=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8488845445191103219==
Content-Type: multipart/alternative; boundary=bcaec54ee776bf28d704d58b134e

--bcaec54ee776bf28d704d58b134e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 12, 2013 at 9:56 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Nakajima, Jun writes ("Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add
> virtual EPT & VPID support to L1 VMM"):
> > I agree that the feature does or can expose a richer attack surface
> > for guests today. We need to set "nestedhvm" in the config ('false'
> > by default) for each guest, to turn on the feature, as far as I
> > know. I don't think we need a global switch like a boot parameter
> > for Xen at this point.
>
> Yes, but my point was whether the "nestedhvm" switch is sufficient.
> As I understand it nestedhvm with virtual EPT provides a richer attack
> surface than without.  So the question is whether we should provide a
> switch to disable virtual EPT while leaving nestedhvm enabled.
>
>
Given the simple implementation in Xen that utilizes the real H/W feature,
I think nestedhvm with virtual EPT should be able to provide more secure
implementations with less testing/QA.

It's possible that we may see more security issues as a side-effect
of virtual EPT support in the short term because people may use
the nestedhvm feature more. In other words, the option nestedhvm may not be
practical without virtual EPT from performance point of view.

-- 
Jun
Intel Open Source Technology Center

--bcaec54ee776bf28d704d58b134e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tue, Feb 12, 2013 at 9:56 AM, Ian Jackson <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:Ian.Jackson@eu.citrix.com" target=3D"_blank">Ian.Jackson@eu.c=
itrix.com</a>&gt;</span> wrote:<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">
Nakajima, Jun writes (&quot;Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Ad=
d virtual EPT &amp; VPID support to L1 VMM&quot;):<br>
<div class=3D"im">&gt; I agree that the feature does or can expose a richer=
 attack surface<br>
&gt; for guests today. We need to set &quot;nestedhvm&quot; in the config (=
&#39;false&#39;<br>
&gt; by default) for each guest, to turn on the feature, as far as I<br>
&gt; know. I don&#39;t think we need a global switch like a boot parameter<=
br>
&gt; for Xen at this point.<br>
<br>
</div>Yes, but my point was whether the &quot;nestedhvm&quot; switch is suf=
ficient.<br>
As I understand it nestedhvm with virtual EPT provides a richer attack<br>
surface than without. =A0So the question is whether we should provide a<br>
switch to disable virtual EPT while leaving nestedhvm enabled.<br><span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></blockquote></div><div><br></div>Given the simple implementa=
tion in Xen that utilizes the real H/W feature, I think=A0nestedhvm with vi=
rtual EPT should be able to provide more secure implementations with less t=
esting/QA.=A0<div>
<div><br></div><div>It&#39;s possible that we may see more security issues =
as a side-effect of=A0virtual EPT support in the short term because people =
may use the=A0nestedhvm feature more. In other words, the option nestedhvm =
may not be practical without=A0virtual EPT from performance point of view.<=
div>
<br></div><div>--=A0<br><div><div><div><div><div><div><div><div>Jun</div><d=
iv><div>Intel Open Source Technology Center</div></div></div>
</div></div></div></div></div></div></div></div></div>

--bcaec54ee776bf28d704d58b134e--


--===============8488845445191103219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8488845445191103219==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 18:20:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18:20: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 1U5KSp-0004x8-M4; Tue, 12 Feb 2013 18:20:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jun.nakajima@intel.com>) id 1U5KSn-0004x3-Qr
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 18:20:18 +0000
Received: from [85.158.139.211:54343] by server-10.bemta-5.messagelabs.com id
	9D/52-04697-1E78A115; Tue, 12 Feb 2013 18:20:17 +0000
X-Env-Sender: jun.nakajima@intel.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360693215!22162534!1
X-Originating-IP: [209.85.215.46]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16633 invoked from network); 12 Feb 2013 18:20:16 -0000
Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com)
	(209.85.215.46)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:20:16 -0000
Received: by mail-la0-f46.google.com with SMTP id fq12so378780lab.19
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 10:20:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=LspPtLiTZFZfk8o/Px57MqvcQbRP1YRSQmeGTvjSEJI=;
	b=cPgWFBzCQW19Ms3ZCdIg1gcTLts0Hb0qHOIMI531rp/Z/s2sRZzvam5HyFZesBIpqw
	+hKjDXqMF7G1DDcbp+77tfU4YKI1mv7mIANcxGLXTUSV++sCjcI6wZlmMg3j6xLujuVz
	HeJr3ZPOZqqino02TNm5C+46J+uaPzvqXy2RtI1t61WRr1TfNyI9tS/hDOw7F9IkXq4o
	NtxQ9B39bYLUrRnAtt2BWk2KroSqKiVIVaVt1jDBOH9FSaEB54wyqq1Qnh/lK6ULT/hI
	ylaZu+4qZJrge2olEMxWoyovVFql5ADxH0Vrv8sPCiw9AElgaOzru2vJMOZBjfRvU2f/
	eEZw==
MIME-Version: 1.0
X-Received: by 10.152.109.146 with SMTP id hs18mr17557138lab.8.1360693215307; 
	Tue, 12 Feb 2013 10:20:15 -0800 (PST)
Received: by 10.114.18.231 with HTTP; Tue, 12 Feb 2013 10:20:15 -0800 (PST)
In-Reply-To: <20762.33363.606499.35682@mariner.uk.xensource.com>
References: <1356359194-5321-1-git-send-email-xiantao.zhang@intel.com>
	<20762.27746.326464.442488@mariner.uk.xensource.com>
	<CAL54oT0uC6Cf6PaQmUA7vVgNNRuFYp+9qYv98MW+D+LZnXsCMQ@mail.gmail.com>
	<20762.33363.606499.35682@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 10:20:15 -0800
Message-ID: <CAL54oT2XJwKzUvnjiS-J5ufjppmNhbNO8b7Was8TiPh98pvYuA@mail.gmail.com>
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Gm-Message-State: ALoCoQkM43PjtPq4MD4ciw4ii2hu02Nj9ItY+axmv+o4rwKH1r8L4+StLluwJNGnGoj7JPwvilXP
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"eddie.dong@intel.com" <eddie.dong@intel.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add virtual EPT & VPID
 support to L1 VMM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8488845445191103219=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8488845445191103219==
Content-Type: multipart/alternative; boundary=bcaec54ee776bf28d704d58b134e

--bcaec54ee776bf28d704d58b134e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 12, 2013 at 9:56 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Nakajima, Jun writes ("Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Add
> virtual EPT & VPID support to L1 VMM"):
> > I agree that the feature does or can expose a richer attack surface
> > for guests today. We need to set "nestedhvm" in the config ('false'
> > by default) for each guest, to turn on the feature, as far as I
> > know. I don't think we need a global switch like a boot parameter
> > for Xen at this point.
>
> Yes, but my point was whether the "nestedhvm" switch is sufficient.
> As I understand it nestedhvm with virtual EPT provides a richer attack
> surface than without.  So the question is whether we should provide a
> switch to disable virtual EPT while leaving nestedhvm enabled.
>
>
Given the simple implementation in Xen that utilizes the real H/W feature,
I think nestedhvm with virtual EPT should be able to provide more secure
implementations with less testing/QA.

It's possible that we may see more security issues as a side-effect
of virtual EPT support in the short term because people may use
the nestedhvm feature more. In other words, the option nestedhvm may not be
practical without virtual EPT from performance point of view.

-- 
Jun
Intel Open Source Technology Center

--bcaec54ee776bf28d704d58b134e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Tue, Feb 12, 2013 at 9:56 AM, Ian Jackson <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:Ian.Jackson@eu.citrix.com" target=3D"_blank">Ian.Jackson@eu.c=
itrix.com</a>&gt;</span> wrote:<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">
Nakajima, Jun writes (&quot;Re: [Xen-devel] [PATCH v4 00/10] Nested VMX: Ad=
d virtual EPT &amp; VPID support to L1 VMM&quot;):<br>
<div class=3D"im">&gt; I agree that the feature does or can expose a richer=
 attack surface<br>
&gt; for guests today. We need to set &quot;nestedhvm&quot; in the config (=
&#39;false&#39;<br>
&gt; by default) for each guest, to turn on the feature, as far as I<br>
&gt; know. I don&#39;t think we need a global switch like a boot parameter<=
br>
&gt; for Xen at this point.<br>
<br>
</div>Yes, but my point was whether the &quot;nestedhvm&quot; switch is suf=
ficient.<br>
As I understand it nestedhvm with virtual EPT provides a richer attack<br>
surface than without. =A0So the question is whether we should provide a<br>
switch to disable virtual EPT while leaving nestedhvm enabled.<br><span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></blockquote></div><div><br></div>Given the simple implementa=
tion in Xen that utilizes the real H/W feature, I think=A0nestedhvm with vi=
rtual EPT should be able to provide more secure implementations with less t=
esting/QA.=A0<div>
<div><br></div><div>It&#39;s possible that we may see more security issues =
as a side-effect of=A0virtual EPT support in the short term because people =
may use the=A0nestedhvm feature more. In other words, the option nestedhvm =
may not be practical without=A0virtual EPT from performance point of view.<=
div>
<br></div><div>--=A0<br><div><div><div><div><div><div><div><div>Jun</div><d=
iv><div>Intel Open Source Technology Center</div></div></div>
</div></div></div></div></div></div></div></div></div>

--bcaec54ee776bf28d704d58b134e--


--===============8488845445191103219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8488845445191103219==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 18:24:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18: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 1U5KWO-00057B-G9; Tue, 12 Feb 2013 18:24:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5KWM-000571-Sa
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 18:23:59 +0000
Received: from [85.158.143.35:15985] by server-2.bemta-4.messagelabs.com id
	90/AB-01597-EB88A115; Tue, 12 Feb 2013 18:23:58 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360693435!11665412!1
X-Originating-IP: [209.85.223.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22007 invoked from network); 12 Feb 2013 18:23:57 -0000
Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com)
	(209.85.223.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:23:57 -0000
Received: by mail-ie0-f180.google.com with SMTP id bn7so522061ieb.25
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 10:23:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=+sFlkrC6fV7KH+WZjQha/y0jn/rlcpAYjisgnpGtwMo=;
	b=FOVjUOT6VeyXi4YEvnUzYKEJ4xdy604s2HY0YjM2AQiU1ztguJnt4LEMz2/1SkqZRB
	GJQpfLQ0WILz2w626GKkEkCY2Q5fsZ1SYjR4Vkc2rJbSrC7VHfLhnKGaQLK5S53vMAwO
	DhXuKziizcT9WwOiXf5rj7xJ7Hs28Fj/eLLZXOHl2ZqLJNK8ibCRfsXLGp8Zo01jWqd6
	o0ZjGn7gAe4jzTONJVDwmQzVy8rq+EzAQLQfUtLR/GVMAqHEmV/x0KrBV4Pdv1biWshC
	sg3G8iECv2GTzUfKy4SwT82t0fEdIPuLL4fi8AS5QkAKCvHXAybvQ4rYp42JHTWvSC5d
	Y31A==
X-Received: by 10.50.37.162 with SMTP id z2mr5278175igj.13.1360693435153; Tue,
	12 Feb 2013 10:23:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 10:23:35 -0800 (PST)
In-Reply-To: <CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 19:23:35 +0100
Message-ID: <CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
> You ought to explain where this device comes from, or why your
> lspci output doesn't show it. Perhaps handing us a native kernel
> boot log (at maximum log level) might already help...
>

The original lspci -vvv output I posted was from the time I had
Firewire disabled in BIOS, I guess I've reset settings since then
because I was trying on different BIOS versions. With Firewire enabled
at 06:00.0 is Firewire controller instead of SATA controller, at
07:00.0 is SATA controller and at 07:00.1 is IDE interface.

So I guess boot always fail on the 07:00.1 (or 06:00.1) IDE interface:
JMicron Technology Corp. JMB361 AHCI/IDE (rev 02) (prog-if 85 [Master
SecO PriO]).

If I disable Firewire boot fails with:
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:06:00.0
(XEN) Xen BUG at pci_amd_iommu.c:35
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c48014afd2>] find_iommu_for_device+0x32/0x40
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 0000000000000601   rbx: 0000000000000601   rcx: ffff83042c980010

If I enable Firewire boot fails with:
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:07:00.0
(XEN) Xen BUG at pci_amd_iommu.c:35
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c48014afd2>] find_iommu_for_device+0x32/0x40
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 0000000000000701   rbx: 0000000000000701   rcx: ffff83042c980010

full lspci -vvv with firewire enabled (with IDE interface as 07:00.1):
http://pastebin.com/raw.php?i=V7YqxNYD
boot log with firewire enabled (posted earlier):
http://pastebin.com/raw.php?i=1wwLw82c

full lspci -vvv with firewire disabled (posted earlier, with IDE
interface as 06:00.1): http://pastebin.com/raw.php?i=3wpKPQT9
boot log with firewire disabled: http://pastebin.com/raw.php?i=LhaN4XeK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 18:24:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18: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 1U5KWO-00057B-G9; Tue, 12 Feb 2013 18:24:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5KWM-000571-Sa
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 18:23:59 +0000
Received: from [85.158.143.35:15985] by server-2.bemta-4.messagelabs.com id
	90/AB-01597-EB88A115; Tue, 12 Feb 2013 18:23:58 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360693435!11665412!1
X-Originating-IP: [209.85.223.180]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22007 invoked from network); 12 Feb 2013 18:23:57 -0000
Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com)
	(209.85.223.180)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:23:57 -0000
Received: by mail-ie0-f180.google.com with SMTP id bn7so522061ieb.25
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 10:23:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=+sFlkrC6fV7KH+WZjQha/y0jn/rlcpAYjisgnpGtwMo=;
	b=FOVjUOT6VeyXi4YEvnUzYKEJ4xdy604s2HY0YjM2AQiU1ztguJnt4LEMz2/1SkqZRB
	GJQpfLQ0WILz2w626GKkEkCY2Q5fsZ1SYjR4Vkc2rJbSrC7VHfLhnKGaQLK5S53vMAwO
	DhXuKziizcT9WwOiXf5rj7xJ7Hs28Fj/eLLZXOHl2ZqLJNK8ibCRfsXLGp8Zo01jWqd6
	o0ZjGn7gAe4jzTONJVDwmQzVy8rq+EzAQLQfUtLR/GVMAqHEmV/x0KrBV4Pdv1biWshC
	sg3G8iECv2GTzUfKy4SwT82t0fEdIPuLL4fi8AS5QkAKCvHXAybvQ4rYp42JHTWvSC5d
	Y31A==
X-Received: by 10.50.37.162 with SMTP id z2mr5278175igj.13.1360693435153; Tue,
	12 Feb 2013 10:23:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 10:23:35 -0800 (PST)
In-Reply-To: <CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 19:23:35 +0100
Message-ID: <CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/12 Jan Beulich <JBeulich@suse.com>:
> You ought to explain where this device comes from, or why your
> lspci output doesn't show it. Perhaps handing us a native kernel
> boot log (at maximum log level) might already help...
>

The original lspci -vvv output I posted was from the time I had
Firewire disabled in BIOS, I guess I've reset settings since then
because I was trying on different BIOS versions. With Firewire enabled
at 06:00.0 is Firewire controller instead of SATA controller, at
07:00.0 is SATA controller and at 07:00.1 is IDE interface.

So I guess boot always fail on the 07:00.1 (or 06:00.1) IDE interface:
JMicron Technology Corp. JMB361 AHCI/IDE (rev 02) (prog-if 85 [Master
SecO PriO]).

If I disable Firewire boot fails with:
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:06:00.0
(XEN) Xen BUG at pci_amd_iommu.c:35
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c48014afd2>] find_iommu_for_device+0x32/0x40
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 0000000000000601   rbx: 0000000000000601   rcx: ffff83042c980010

If I enable Firewire boot fails with:
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:07:00.0
(XEN) Xen BUG at pci_amd_iommu.c:35
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c48014afd2>] find_iommu_for_device+0x32/0x40
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 0000000000000701   rbx: 0000000000000701   rcx: ffff83042c980010

full lspci -vvv with firewire enabled (with IDE interface as 07:00.1):
http://pastebin.com/raw.php?i=V7YqxNYD
boot log with firewire enabled (posted earlier):
http://pastebin.com/raw.php?i=1wwLw82c

full lspci -vvv with firewire disabled (posted earlier, with IDE
interface as 06:00.1): http://pastebin.com/raw.php?i=3wpKPQT9
boot log with firewire disabled: http://pastebin.com/raw.php?i=LhaN4XeK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 18:43:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18:43: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 1U5KoV-0005M8-8B; Tue, 12 Feb 2013 18:42:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5KoT-0005M3-Vy
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 18:42:42 +0000
Received: from [85.158.139.211:21431] by server-10.bemta-5.messagelabs.com id
	C4/DB-04697-12D8A115; Tue, 12 Feb 2013 18:42:41 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360694559!20732192!1
X-Originating-IP: [209.85.210.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26176 invoked from network); 12 Feb 2013 18:42:40 -0000
Received: from unknown (HELO mail-ia0-f177.google.com) (209.85.210.177)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:42:40 -0000
Received: by mail-ia0-f177.google.com with SMTP id k38so362964iah.22
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 10:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=2t+jOr3coucyrX0R4wSJdtIpMz+o6nuOvlgwZF98xi4=;
	b=xXr2H1kJCFjev86pBWNux28M8h0wZcvndsOzB0E8/tmWn0Bckn5/GXxDhGDNVJ9LWP
	sTYtenAxuzZTpxn1h9oHqChTj+2SzwKSLhM9HF7plFFyTDV5tBFUtGvtUzbPiNoaQ+Lb
	nqiaLraEGg1nWnoUXfJv4jfc2cS+lN6mzkr8UM2bwmgqed4jjxEwTlEdnqMA0t/gdUn3
	AbSHhFf7EVgdA9YA+tr1uthzeni279yQCtg89FUZK4XMcCP4AY2HVE3x+ZXlzDGtQRh5
	JcjxBFthWNXbYRsKtBM4og71z+e5Y+a85eKNlqAhr9a7dcD+tJwl8NhUAkYRL3nPXEWS
	CgxQ==
X-Received: by 10.50.1.240 with SMTP id 16mr5332416igp.76.1360694440967; Tue,
	12 Feb 2013 10:40:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 10:40:20 -0800 (PST)
In-Reply-To: <CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 19:40:20 +0100
Message-ID: <CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

I disabled id BIOS IDE interface that was causing problems and system
boots fine. Thanks for your help!

I just wonder if it's a bug in BIOS or in Xen. If it's ASUS bug I
would like to report bug to them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 18:43:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 18:43: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 1U5KoV-0005M8-8B; Tue, 12 Feb 2013 18:42:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5KoT-0005M3-Vy
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 18:42:42 +0000
Received: from [85.158.139.211:21431] by server-10.bemta-5.messagelabs.com id
	C4/DB-04697-12D8A115; Tue, 12 Feb 2013 18:42:41 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360694559!20732192!1
X-Originating-IP: [209.85.210.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26176 invoked from network); 12 Feb 2013 18:42:40 -0000
Received: from unknown (HELO mail-ia0-f177.google.com) (209.85.210.177)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 18:42:40 -0000
Received: by mail-ia0-f177.google.com with SMTP id k38so362964iah.22
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 10:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=2t+jOr3coucyrX0R4wSJdtIpMz+o6nuOvlgwZF98xi4=;
	b=xXr2H1kJCFjev86pBWNux28M8h0wZcvndsOzB0E8/tmWn0Bckn5/GXxDhGDNVJ9LWP
	sTYtenAxuzZTpxn1h9oHqChTj+2SzwKSLhM9HF7plFFyTDV5tBFUtGvtUzbPiNoaQ+Lb
	nqiaLraEGg1nWnoUXfJv4jfc2cS+lN6mzkr8UM2bwmgqed4jjxEwTlEdnqMA0t/gdUn3
	AbSHhFf7EVgdA9YA+tr1uthzeni279yQCtg89FUZK4XMcCP4AY2HVE3x+ZXlzDGtQRh5
	JcjxBFthWNXbYRsKtBM4og71z+e5Y+a85eKNlqAhr9a7dcD+tJwl8NhUAkYRL3nPXEWS
	CgxQ==
X-Received: by 10.50.1.240 with SMTP id 16mr5332416igp.76.1360694440967; Tue,
	12 Feb 2013 10:40:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Tue, 12 Feb 2013 10:40:20 -0800 (PST)
In-Reply-To: <CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
From: povder <povder@gmail.com>
Date: Tue, 12 Feb 2013 19:40:20 +0100
Message-ID: <CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

I disabled id BIOS IDE interface that was causing problems and system
boots fine. Thanks for your help!

I just wonder if it's a bug in BIOS or in Xen. If it's ASUS bug I
would like to report bug to them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 19:09:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 19: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 1U5LEN-0005cX-N0; Tue, 12 Feb 2013 19:09: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 1U5LEL-0005cS-OR
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 19:09:26 +0000
Received: from [85.158.137.99:4276] by server-12.bemta-3.messagelabs.com id
	9A/EE-05889-0639A115; Tue, 12 Feb 2013 19:09:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360696158!16454917!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16856 invoked from network); 12 Feb 2013 19:09:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 19:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1386890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 19:09: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.297.1; Tue, 12 Feb 2013 19:09:18 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5LEE-000156-7e;
	Tue, 12 Feb 2013 19:09:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5LEE-0001SN-2o;
	Tue, 12 Feb 2013 19:09:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16140-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 19:09:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16140: trouble:
	fail/pass/preparing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 16140 xen-4.2-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16140/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-pcipt-intel  2 hosts-allocate        running [st=running!]
 test-amd64-i386-qemuu-rhel6hvm-amd  2 hosts-allocate     running [st=running!]
 test-amd64-i386-rhel6hvm-amd  2 hosts-allocate           running [st=running!]
 test-amd64-amd64-pv           2 hosts-allocate           running [st=running!]
 test-amd64-i386-qemut-rhel6hvm-amd  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xl-credit2    2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-multivcpu  2 hosts-allocate           running [st=running!]
 test-i386-i386-pv             2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl           2 hosts-allocate           running [st=running!]
 test-amd64-i386-pv            2 hosts-allocate           running [st=running!]
 test-i386-i386-xl             2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl            2 hosts-allocate           running [st=running!]
 test-amd64-i386-qemuu-rhel6hvm-intel  2 hosts-allocate   running [st=running!]
 test-amd64-i386-qemut-rhel6hvm-intel  2 hosts-allocate   running [st=running!]
 test-amd64-amd64-xl-sedf      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-pair         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-win7-amd64  2 hosts-allocate   running [st=running!]
 test-amd64-i386-pair          2 hosts-allocate           running [st=running!]
 test-i386-i386-pair           2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemut-win   2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win7-amd64  2 hosts-allocate         running [st=running!]
 test-amd64-i386-xl-win7-amd64  2 hosts-allocate          running [st=running!]
 test-amd64-i386-qemut-win     2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win       2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemut-win7-amd64  2 hosts-allocate   running [st=running!]
 test-amd64-amd64-xl-qemut-winxpsp3  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 2 hosts-allocate running [st=running!]
 test-i386-i386-xl-winxpsp3    2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemuu-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-qemut-win  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-qemut-win7-amd64  2 hosts-allocate    running [st=running!]
 test-amd64-i386-xl-qemut-win-vcpus1  2 hosts-allocate    running [st=running!]
 test-i386-i386-xl-qemut-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-i386-xl-win-vcpus1  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-winxpsp3-vcpus1  2 hosts-allocate     running [st=running!]
 test-amd64-i386-rhel6hvm-intel  2 hosts-allocate         running [st=running!]
 test-amd64-i386-xend-winxpsp3  2 hosts-allocate          running [st=running!]
 test-i386-i386-xl-win         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-winxpsp3  2 hosts-allocate           running [st=running!]
 test-amd64-i386-win           2 hosts-allocate           running [st=running!]
 test-amd64-amd64-win          2 hosts-allocate           running [st=running!]
 test-i386-i386-qemut-win      2 hosts-allocate           running [st=running!]
 test-i386-i386-win            2 hosts-allocate           running [st=running!]
 test-amd64-i386-win-vcpus1    2 hosts-allocate           running [st=running!]
 test-amd64-i386-xend-qemut-winxpsp3  2 hosts-allocate    running [st=running!]
 test-amd64-i386-qemut-win-vcpus1  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3  2 hosts-allocate     running [st=running!]
 test-amd64-amd64-qemut-win    2 hosts-allocate           running [st=running!]

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass

version targeted for testing:
 xen                  94cfa1b6e178
baseline version:
 xen                  c713f1f7d3c1

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Scott <dave.scott@eu.citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  George Dunlap <george.dunlap@citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Phil Evans <Phil.Evans@m247.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          preparing
 test-amd64-i386-xl                                           preparing
 test-i386-i386-xl                                            preparing
 test-amd64-i386-rhel6hvm-amd                                 preparing
 test-amd64-i386-qemut-rhel6hvm-amd                           preparing
 test-amd64-i386-qemuu-rhel6hvm-amd                           preparing
 test-amd64-amd64-xl-qemut-win7-amd64                         preparing
 test-amd64-i386-xl-qemut-win7-amd64                          preparing
 test-amd64-amd64-xl-qemuu-win7-amd64                         preparing
 test-amd64-amd64-xl-win7-amd64                               preparing
 test-amd64-i386-xl-win7-amd64                                preparing
 test-amd64-i386-xl-credit2                                   preparing
 test-amd64-amd64-xl-pcipt-intel                              preparing
 test-amd64-i386-rhel6hvm-intel                               preparing
 test-amd64-i386-qemut-rhel6hvm-intel                         preparing
 test-amd64-i386-qemuu-rhel6hvm-intel                         preparing
 test-amd64-i386-xl-multivcpu                                 preparing
 test-amd64-amd64-pair                                        preparing
 test-amd64-i386-pair                                         preparing
 test-i386-i386-pair                                          preparing
 test-amd64-amd64-xl-sedf-pin                                 preparing
 test-amd64-amd64-pv                                          preparing
 test-amd64-i386-pv                                           preparing
 test-i386-i386-pv                                            preparing
 test-amd64-amd64-xl-sedf                                     preparing
 test-amd64-i386-win-vcpus1                                   preparing
 test-amd64-i386-qemut-win-vcpus1                             preparing
 test-amd64-i386-xl-qemut-win-vcpus1                          preparing
 test-amd64-i386-xl-win-vcpus1                                preparing
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     preparing
 test-amd64-i386-xl-winxpsp3-vcpus1                           preparing
 test-amd64-amd64-win                                         preparing
 test-amd64-i386-win                                          preparing
 test-i386-i386-win                                           preparing
 test-amd64-amd64-qemut-win                                   preparing
 test-amd64-i386-qemut-win                                    preparing
 test-i386-i386-qemut-win                                     preparing
 test-amd64-amd64-xl-qemut-win                                preparing
 test-i386-i386-xl-qemut-win                                  preparing
 test-amd64-amd64-xl-win                                      preparing
 test-i386-i386-xl-win                                        preparing
 test-amd64-i386-xend-qemut-winxpsp3                          preparing
 test-amd64-amd64-xl-qemut-winxpsp3                           preparing
 test-i386-i386-xl-qemut-winxpsp3                             preparing
 test-amd64-amd64-xl-qemuu-winxpsp3                           preparing
 test-i386-i386-xl-qemuu-winxpsp3                             preparing
 test-amd64-i386-xend-winxpsp3                                preparing
 test-amd64-amd64-xl-winxpsp3                                 preparing
 test-i386-i386-xl-winxpsp3                                   preparing


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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.

------------------------------------------------------------
changeset:   25987:94cfa1b6e178
tag:         tip
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Tue Feb 12 13:44:02 2013 +0100
    
    VMX: disable SMEP feature when guest is in non-paging mode
    
    SMEP is disabled if CPU is in non-paging mode in hardware.
    However Xen always uses paging mode to emulate guest non-paging
    mode with HAP. To emulate this behavior, SMEP needs to be manually
    disabled when guest switches to non-paging mode.
    
    We met an issue that, SMP Linux guest with recent kernel (enable
    SMEP support, for example, 3.5.3) would crash with triple fault if
    setting unrestricted_guest=0 in grub. This is because Xen uses an
    identity mapping page table to emulate the non-paging mode, where
    the page table is set with USER flag. If SMEP is still enabled in
    this case, guest will meet unhandlable page fault and then crash.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
    xen-unstable changeset: 26502:d1bf3b21f783
    xen-unstable date: Wed Jan 30 17:17:30 UTC 2013
    
    
changeset:   25986:51f6ae41fd7e
user:        Keir Fraser <keir@xen.org>
date:        Tue Feb 12 13:43:16 2013 +0100
    
    vmx: Simplify cr0 update handling by deferring cr4 changes to the cr4 handler.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 26501:8201b6ec3564
    xen-unstable date: Wed Jan 30 17:15:39 UTC 2013
    
    
changeset:   25985:f3a2642c52e4
user:        Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
date:        Tue Feb 12 13:41:37 2013 +0100
    
    fix acpi_dmar_zap/reinstate() (fixes S3 regression)
    
    Fix S3 regression introduced by cs 23013:65d26504e843 (ACPI: large
    cleanup). The dmar virtual pointer returned from acpi_get_table cannot
    be safely stored away and used later, as the underlying
    acpi_os_map_memory / __acpi_map_table functions overwrite the mapping
    causing it to point to different tables than dmar (last fetched table is
    used). This subsequently causes acpi_dmar_reinstate() and
    acpi_dmar_zap() to write data to wrong table, causing its corruption and
    problems with consecutive s3 resumes.
    
    Added a new function to fetch ACPI table physical address, and
    establishing separate static mapping for dmar_table pointer instead of
    using acpi_get_table().
    
    Signed-off-by: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
    
    Added call to acpi_tb_verify_table(). Fixed page count passed to
    map_pages_to_xen(). Cosmetic changes.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26443:9efe4c0bf9c8
    xen-unstable date: Wed Jan 23 09:31:04 UTC 2013
    
    
changeset:   25984:60e9576338b6
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Feb 12 13:40:36 2013 +0100
    
    x86: restore (optional) forwarding of PCI SERR induced NMI to Dom0
    
    c/s 22949:54fe1011f86b removed the forwarding of NMIs to Dom0 when they
    were caused by PCI SERR. NMI buttons as well as BMCs (like HP's iLO)
    may however want such events to be seen in Dom0 (e.g. to trigger a
    dump).
    
    Therefore restore most of the functionality which named c/s removed
    (adjusted for subsequent changes, and adjusting the public interface to
    use the modern term, retaining the old one for backwards
    compatibility).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 26440:5af4f2ab06f3
    xen-unstable date: Tue Jan 22 08:33:10 UTC 2013
    
    
changeset:   25983:c82378694acf
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 12 13:39:30 2013 +0100
    
    x86/hvm: fix RTC setting.
    
    When the guest writes one field of the RTC time, we must bring all the
    other fields up to date for the current second before calculating the
    new RTC time.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Tested-by: Phil Evans <Phil.Evans@m247.com>
    xen-unstable changeset: 26428:9e8c39bdc1fe
    xen-unstable date: Fri Jan 18 11:31:57 UTC 2013
    
    
changeset:   25982:154e4909ff55
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 12 13:38:22 2013 +0100
    
    x86/AMD: Enable WC+ memory type on family 10 processors
    
    In some cases BIOS may not enable WC+ memory type on family 10 processors,
    instead converting what would be WC+ memory to CD type. On guests using
    nested pages this could result in performance degradation. This patch
    enables WC+.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    xen-unstable changeset: 26427:8f6dd5dc5d6c
    xen-unstable date: Fri Jan 18 11:20:58 UTC 2013
    
    
changeset:   25981:5b3c15526555
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Feb 12 13:37:15 2013 +0100
    
    x86: consistently mask floating point exceptions
    
    c/s 23142:f5e8d152a565 resulted in v->arch.fpu_ctxt to point into the
    save area allocated for xsave/xrstor (when they're available). The way
    vcpu_restore_fpu_lazy() works (using fpu_init() for an uninitialized
    vCPU only when there's no xsave support) causes this to load whatever
    arch_set_info_guest() put there, irrespective of whether the i387 state
    was specified to be valid in the respective input structure.
    
    Consequently, with a cleared (al zeroes) incoming FPU context, and with
    xsave available, one gets all exceptions unmasked (as opposed to to the
    legacy case, where FINIT and LDMXCSR get used, masking all exceptions).
    This causes e.g. para-virtualized NetWare to crash.
    
    The behavior of arch_set_info_guest() is thus being made more hardware-
    like for the FPU portion of it: Considering it to be similar to INIT,
    it will leave untouched all floating point state now. An alternative
    would be to make the behavior RESET-like, forcing all state to known
    values, albeit - taking into account legacy behavior - not to precisely
    the values RESET would enforce (which masks only SSE exceptions, but
    not x87 ones); that would come closest to mimicing FINIT behavior in
    the xsave case. Another option would be to continue copying whatever
    was provided, but override (at least) FCW and MXCSR if VGCF_I387_VALID
    isn't set.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 26395:b4cbb83f9a1f
    xen-unstable date: Wed Jan 16 12:56:55 UTC 2013
    
    
changeset:   25980:0bc9a0996a6b
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Tue Feb 12 13:36:07 2013 +0100
    
    xen: sched_credit: improve picking up the idle CPU for a VCPU
    
    In _csched_cpu_pick() we try to select the best possible CPU for
    running a VCPU, considering the characteristics of the underlying
    hardware (i.e., how many threads, core, sockets, and how busy they
    are). What we want is "the idle execution vehicle with the most
    idling neighbours in its grouping".
    
    In order to achieve it, we select a CPU from the VCPU's affinity,
    giving preference to its current processor if possible, as the basis
    for the comparison with all the other CPUs. Problem is, to discount
    the VCPU itself when computing this "idleness" (in an attempt to be
    fair wrt its current processor), we arbitrarily and unconditionally
    consider that selected CPU as idle, even when it is not the case,
    for instance:
     1. If the CPU is not the one where the VCPU is running (perhaps due
        to the affinity being changed);
     2. The CPU is where the VCPU is running, but it has other VCPUs in
        its runq, so it won't go idle even if the VCPU in question goes.
    
    This is exemplified in the trace below:
    
    ]  3.466115364 x|------|------| d10v1   22005(2:2:5) 3 [ a 1 8 ]
       ... ... ...
       3.466122856 x|------|------| d10v1 runstate_change d10v1
       running->offline
       3.466123046 x|------|------| d?v? runstate_change d32767v0
       runnable->running
       ... ... ...
    ]  3.466126887 x|------|------| d32767v0   28004(2:8:4) 3 [ a 1 8 ]
    
    22005(...) line (the first line) means _csched_cpu_pick() was called
    on VCPU 1 of domain 10, while it is running on CPU 0, and it choose
    CPU 8, which is busy ('|'), even if there are plenty of idle
    CPUs. That is because, as a consequence of changing the VCPU affinity,
    CPU 8 was chosen as the basis for the comparison, and therefore
    considered idle (its bit gets unconditionally set in the bitmask
    representing the idle CPUs). 28004(...) line means the VCPU is woken
    up and queued on CPU 8's runq, where it waits for a context switch or
    a migration, in order to be able to execute.
    
    This change fixes things by only considering the "guessed" CPU idle if
    the VCPU in question is both running there and is its only runnable
    VCPU.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
    Acked-by: George Dunlap <george.dunlap@citrix.com>
    xen-unstable changeset: 26287:127c2c47d440
    xen-unstable date: Tue Dec 18 18:10:18 UTC 2012
    
    
changeset:   25979:c713f1f7d3c1
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:24:08 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 19:09:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 19: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 1U5LEN-0005cX-N0; Tue, 12 Feb 2013 19:09: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 1U5LEL-0005cS-OR
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 19:09:26 +0000
Received: from [85.158.137.99:4276] by server-12.bemta-3.messagelabs.com id
	9A/EE-05889-0639A115; Tue, 12 Feb 2013 19:09:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360696158!16454917!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16856 invoked from network); 12 Feb 2013 19:09:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 19:09:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1386890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 19:09: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.297.1; Tue, 12 Feb 2013 19:09:18 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5LEE-000156-7e;
	Tue, 12 Feb 2013 19:09:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5LEE-0001SN-2o;
	Tue, 12 Feb 2013 19:09:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16140-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 19:09:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16140: trouble:
	fail/pass/preparing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 16140 xen-4.2-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16140/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-pcipt-intel  2 hosts-allocate        running [st=running!]
 test-amd64-i386-qemuu-rhel6hvm-amd  2 hosts-allocate     running [st=running!]
 test-amd64-i386-rhel6hvm-amd  2 hosts-allocate           running [st=running!]
 test-amd64-amd64-pv           2 hosts-allocate           running [st=running!]
 test-amd64-i386-qemut-rhel6hvm-amd  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xl-credit2    2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-multivcpu  2 hosts-allocate           running [st=running!]
 test-i386-i386-pv             2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl           2 hosts-allocate           running [st=running!]
 test-amd64-i386-pv            2 hosts-allocate           running [st=running!]
 test-i386-i386-xl             2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl            2 hosts-allocate           running [st=running!]
 test-amd64-i386-qemuu-rhel6hvm-intel  2 hosts-allocate   running [st=running!]
 test-amd64-i386-qemut-rhel6hvm-intel  2 hosts-allocate   running [st=running!]
 test-amd64-amd64-xl-sedf      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-pair         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-win7-amd64  2 hosts-allocate   running [st=running!]
 test-amd64-i386-pair          2 hosts-allocate           running [st=running!]
 test-i386-i386-pair           2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemut-win   2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win7-amd64  2 hosts-allocate         running [st=running!]
 test-amd64-i386-xl-win7-amd64  2 hosts-allocate          running [st=running!]
 test-amd64-i386-qemut-win     2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win       2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemut-win7-amd64  2 hosts-allocate   running [st=running!]
 test-amd64-amd64-xl-qemut-winxpsp3  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 2 hosts-allocate running [st=running!]
 test-i386-i386-xl-winxpsp3    2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemuu-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-qemut-win  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-qemut-win7-amd64  2 hosts-allocate    running [st=running!]
 test-amd64-i386-xl-qemut-win-vcpus1  2 hosts-allocate    running [st=running!]
 test-i386-i386-xl-qemut-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-i386-xl-win-vcpus1  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-winxpsp3-vcpus1  2 hosts-allocate     running [st=running!]
 test-amd64-i386-rhel6hvm-intel  2 hosts-allocate         running [st=running!]
 test-amd64-i386-xend-winxpsp3  2 hosts-allocate          running [st=running!]
 test-i386-i386-xl-win         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-winxpsp3  2 hosts-allocate           running [st=running!]
 test-amd64-i386-win           2 hosts-allocate           running [st=running!]
 test-amd64-amd64-win          2 hosts-allocate           running [st=running!]
 test-i386-i386-qemut-win      2 hosts-allocate           running [st=running!]
 test-i386-i386-win            2 hosts-allocate           running [st=running!]
 test-amd64-i386-win-vcpus1    2 hosts-allocate           running [st=running!]
 test-amd64-i386-xend-qemut-winxpsp3  2 hosts-allocate    running [st=running!]
 test-amd64-i386-qemut-win-vcpus1  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3  2 hosts-allocate     running [st=running!]
 test-amd64-amd64-qemut-win    2 hosts-allocate           running [st=running!]

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass

version targeted for testing:
 xen                  94cfa1b6e178
baseline version:
 xen                  c713f1f7d3c1

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Scott <dave.scott@eu.citrix.com>
  Dongxiao Xu <dongxiao.xu@intel.com>
  George Dunlap <george.dunlap@citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Phil Evans <Phil.Evans@m247.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
  Xiantao Zhang <xiantao.zhang@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          preparing
 test-amd64-i386-xl                                           preparing
 test-i386-i386-xl                                            preparing
 test-amd64-i386-rhel6hvm-amd                                 preparing
 test-amd64-i386-qemut-rhel6hvm-amd                           preparing
 test-amd64-i386-qemuu-rhel6hvm-amd                           preparing
 test-amd64-amd64-xl-qemut-win7-amd64                         preparing
 test-amd64-i386-xl-qemut-win7-amd64                          preparing
 test-amd64-amd64-xl-qemuu-win7-amd64                         preparing
 test-amd64-amd64-xl-win7-amd64                               preparing
 test-amd64-i386-xl-win7-amd64                                preparing
 test-amd64-i386-xl-credit2                                   preparing
 test-amd64-amd64-xl-pcipt-intel                              preparing
 test-amd64-i386-rhel6hvm-intel                               preparing
 test-amd64-i386-qemut-rhel6hvm-intel                         preparing
 test-amd64-i386-qemuu-rhel6hvm-intel                         preparing
 test-amd64-i386-xl-multivcpu                                 preparing
 test-amd64-amd64-pair                                        preparing
 test-amd64-i386-pair                                         preparing
 test-i386-i386-pair                                          preparing
 test-amd64-amd64-xl-sedf-pin                                 preparing
 test-amd64-amd64-pv                                          preparing
 test-amd64-i386-pv                                           preparing
 test-i386-i386-pv                                            preparing
 test-amd64-amd64-xl-sedf                                     preparing
 test-amd64-i386-win-vcpus1                                   preparing
 test-amd64-i386-qemut-win-vcpus1                             preparing
 test-amd64-i386-xl-qemut-win-vcpus1                          preparing
 test-amd64-i386-xl-win-vcpus1                                preparing
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     preparing
 test-amd64-i386-xl-winxpsp3-vcpus1                           preparing
 test-amd64-amd64-win                                         preparing
 test-amd64-i386-win                                          preparing
 test-i386-i386-win                                           preparing
 test-amd64-amd64-qemut-win                                   preparing
 test-amd64-i386-qemut-win                                    preparing
 test-i386-i386-qemut-win                                     preparing
 test-amd64-amd64-xl-qemut-win                                preparing
 test-i386-i386-xl-qemut-win                                  preparing
 test-amd64-amd64-xl-win                                      preparing
 test-i386-i386-xl-win                                        preparing
 test-amd64-i386-xend-qemut-winxpsp3                          preparing
 test-amd64-amd64-xl-qemut-winxpsp3                           preparing
 test-i386-i386-xl-qemut-winxpsp3                             preparing
 test-amd64-amd64-xl-qemuu-winxpsp3                           preparing
 test-i386-i386-xl-qemuu-winxpsp3                             preparing
 test-amd64-i386-xend-winxpsp3                                preparing
 test-amd64-amd64-xl-winxpsp3                                 preparing
 test-i386-i386-xl-winxpsp3                                   preparing


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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.

------------------------------------------------------------
changeset:   25987:94cfa1b6e178
tag:         tip
user:        Dongxiao Xu <dongxiao.xu@intel.com>
date:        Tue Feb 12 13:44:02 2013 +0100
    
    VMX: disable SMEP feature when guest is in non-paging mode
    
    SMEP is disabled if CPU is in non-paging mode in hardware.
    However Xen always uses paging mode to emulate guest non-paging
    mode with HAP. To emulate this behavior, SMEP needs to be manually
    disabled when guest switches to non-paging mode.
    
    We met an issue that, SMP Linux guest with recent kernel (enable
    SMEP support, for example, 3.5.3) would crash with triple fault if
    setting unrestricted_guest=0 in grub. This is because Xen uses an
    identity mapping page table to emulate the non-paging mode, where
    the page table is set with USER flag. If SMEP is still enabled in
    this case, guest will meet unhandlable page fault and then crash.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
    xen-unstable changeset: 26502:d1bf3b21f783
    xen-unstable date: Wed Jan 30 17:17:30 UTC 2013
    
    
changeset:   25986:51f6ae41fd7e
user:        Keir Fraser <keir@xen.org>
date:        Tue Feb 12 13:43:16 2013 +0100
    
    vmx: Simplify cr0 update handling by deferring cr4 changes to the cr4 handler.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 26501:8201b6ec3564
    xen-unstable date: Wed Jan 30 17:15:39 UTC 2013
    
    
changeset:   25985:f3a2642c52e4
user:        Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
date:        Tue Feb 12 13:41:37 2013 +0100
    
    fix acpi_dmar_zap/reinstate() (fixes S3 regression)
    
    Fix S3 regression introduced by cs 23013:65d26504e843 (ACPI: large
    cleanup). The dmar virtual pointer returned from acpi_get_table cannot
    be safely stored away and used later, as the underlying
    acpi_os_map_memory / __acpi_map_table functions overwrite the mapping
    causing it to point to different tables than dmar (last fetched table is
    used). This subsequently causes acpi_dmar_reinstate() and
    acpi_dmar_zap() to write data to wrong table, causing its corruption and
    problems with consecutive s3 resumes.
    
    Added a new function to fetch ACPI table physical address, and
    establishing separate static mapping for dmar_table pointer instead of
    using acpi_get_table().
    
    Signed-off-by: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
    
    Added call to acpi_tb_verify_table(). Fixed page count passed to
    map_pages_to_xen(). Cosmetic changes.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 26443:9efe4c0bf9c8
    xen-unstable date: Wed Jan 23 09:31:04 UTC 2013
    
    
changeset:   25984:60e9576338b6
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Feb 12 13:40:36 2013 +0100
    
    x86: restore (optional) forwarding of PCI SERR induced NMI to Dom0
    
    c/s 22949:54fe1011f86b removed the forwarding of NMIs to Dom0 when they
    were caused by PCI SERR. NMI buttons as well as BMCs (like HP's iLO)
    may however want such events to be seen in Dom0 (e.g. to trigger a
    dump).
    
    Therefore restore most of the functionality which named c/s removed
    (adjusted for subsequent changes, and adjusting the public interface to
    use the modern term, retaining the old one for backwards
    compatibility).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 26440:5af4f2ab06f3
    xen-unstable date: Tue Jan 22 08:33:10 UTC 2013
    
    
changeset:   25983:c82378694acf
user:        Tim Deegan <tim@xen.org>
date:        Tue Feb 12 13:39:30 2013 +0100
    
    x86/hvm: fix RTC setting.
    
    When the guest writes one field of the RTC time, we must bring all the
    other fields up to date for the current second before calculating the
    new RTC time.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Tested-by: Phil Evans <Phil.Evans@m247.com>
    xen-unstable changeset: 26428:9e8c39bdc1fe
    xen-unstable date: Fri Jan 18 11:31:57 UTC 2013
    
    
changeset:   25982:154e4909ff55
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Feb 12 13:38:22 2013 +0100
    
    x86/AMD: Enable WC+ memory type on family 10 processors
    
    In some cases BIOS may not enable WC+ memory type on family 10 processors,
    instead converting what would be WC+ memory to CD type. On guests using
    nested pages this could result in performance degradation. This patch
    enables WC+.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    xen-unstable changeset: 26427:8f6dd5dc5d6c
    xen-unstable date: Fri Jan 18 11:20:58 UTC 2013
    
    
changeset:   25981:5b3c15526555
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Feb 12 13:37:15 2013 +0100
    
    x86: consistently mask floating point exceptions
    
    c/s 23142:f5e8d152a565 resulted in v->arch.fpu_ctxt to point into the
    save area allocated for xsave/xrstor (when they're available). The way
    vcpu_restore_fpu_lazy() works (using fpu_init() for an uninitialized
    vCPU only when there's no xsave support) causes this to load whatever
    arch_set_info_guest() put there, irrespective of whether the i387 state
    was specified to be valid in the respective input structure.
    
    Consequently, with a cleared (al zeroes) incoming FPU context, and with
    xsave available, one gets all exceptions unmasked (as opposed to to the
    legacy case, where FINIT and LDMXCSR get used, masking all exceptions).
    This causes e.g. para-virtualized NetWare to crash.
    
    The behavior of arch_set_info_guest() is thus being made more hardware-
    like for the FPU portion of it: Considering it to be similar to INIT,
    it will leave untouched all floating point state now. An alternative
    would be to make the behavior RESET-like, forcing all state to known
    values, albeit - taking into account legacy behavior - not to precisely
    the values RESET would enforce (which masks only SSE exceptions, but
    not x87 ones); that would come closest to mimicing FINIT behavior in
    the xsave case. Another option would be to continue copying whatever
    was provided, but override (at least) FCW and MXCSR if VGCF_I387_VALID
    isn't set.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 26395:b4cbb83f9a1f
    xen-unstable date: Wed Jan 16 12:56:55 UTC 2013
    
    
changeset:   25980:0bc9a0996a6b
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Tue Feb 12 13:36:07 2013 +0100
    
    xen: sched_credit: improve picking up the idle CPU for a VCPU
    
    In _csched_cpu_pick() we try to select the best possible CPU for
    running a VCPU, considering the characteristics of the underlying
    hardware (i.e., how many threads, core, sockets, and how busy they
    are). What we want is "the idle execution vehicle with the most
    idling neighbours in its grouping".
    
    In order to achieve it, we select a CPU from the VCPU's affinity,
    giving preference to its current processor if possible, as the basis
    for the comparison with all the other CPUs. Problem is, to discount
    the VCPU itself when computing this "idleness" (in an attempt to be
    fair wrt its current processor), we arbitrarily and unconditionally
    consider that selected CPU as idle, even when it is not the case,
    for instance:
     1. If the CPU is not the one where the VCPU is running (perhaps due
        to the affinity being changed);
     2. The CPU is where the VCPU is running, but it has other VCPUs in
        its runq, so it won't go idle even if the VCPU in question goes.
    
    This is exemplified in the trace below:
    
    ]  3.466115364 x|------|------| d10v1   22005(2:2:5) 3 [ a 1 8 ]
       ... ... ...
       3.466122856 x|------|------| d10v1 runstate_change d10v1
       running->offline
       3.466123046 x|------|------| d?v? runstate_change d32767v0
       runnable->running
       ... ... ...
    ]  3.466126887 x|------|------| d32767v0   28004(2:8:4) 3 [ a 1 8 ]
    
    22005(...) line (the first line) means _csched_cpu_pick() was called
    on VCPU 1 of domain 10, while it is running on CPU 0, and it choose
    CPU 8, which is busy ('|'), even if there are plenty of idle
    CPUs. That is because, as a consequence of changing the VCPU affinity,
    CPU 8 was chosen as the basis for the comparison, and therefore
    considered idle (its bit gets unconditionally set in the bitmask
    representing the idle CPUs). 28004(...) line means the VCPU is woken
    up and queued on CPU 8's runq, where it waits for a context switch or
    a migration, in order to be able to execute.
    
    This change fixes things by only considering the "guessed" CPU idle if
    the VCPU in question is both running there and is its only runnable
    VCPU.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
    Acked-by: George Dunlap <george.dunlap@citrix.com>
    xen-unstable changeset: 26287:127c2c47d440
    xen-unstable date: Tue Dec 18 18:10:18 UTC 2012
    
    
changeset:   25979:c713f1f7d3c1
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:24:08 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xen.org
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 19:15:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 19: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 1U5LKC-0005no-Ms; Tue, 12 Feb 2013 19:15:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <mad@wol.de>)
	id 1U5LKB-0005nj-03
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 19:15:27 +0000
Received: from [85.158.143.99:21333] by server-1.bemta-4.messagelabs.com id
	0F/E4-08839-EC49A115; Tue, 12 Feb 2013 19:15:26 +0000
X-Env-Sender: mad@wol.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360696525!22239638!1
X-Originating-IP: [193.158.62.4]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4245 invoked from network); 12 Feb 2013 19:15:25 -0000
Received: from cmx.wol.de (HELO cmx.wol.de) (193.158.62.4)
	by server-8.tower-216.messagelabs.com with SMTP;
	12 Feb 2013 19:15:25 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by cmx.wol.de (Postfix) with ESMTP id CCA0F5C141;
	Tue, 12 Feb 2013 20:15:24 +0100 (CET)
Received: from cmx.wol.de ([127.0.0.1])
	by localhost (cmx.wol.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id nLCIgkYSpviP; Tue, 12 Feb 2013 20:15:22 +0100 (CET)
Received: from [10.4.8.43] (p57901CBE.dip.t-dialin.net [87.144.28.190])
	by cmx.wol.de (Postfix) with ESMTP id 3F8325C119;
	Tue, 12 Feb 2013 20:15:22 +0100 (CET)
Message-ID: <511A94CA.7050207@wol.de>
Date: Tue, 12 Feb 2013 20:15:22 +0100
From: Marc Dahlhaus <mad@wol.de>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Andreas Kinzler <ml-xen-devel@hfp.de>
References: <511A45D0.4030806@hfp.de> <511A5937.3020101@hfp.de>
In-Reply-To: <511A5937.3020101@hfp.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4800934718471692925=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4800934718471692925==
Content-Type: multipart/alternative;
 boundary="------------040805030507000108090904"

This is a multi-part message in MIME format.
--------------040805030507000108090904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Give this a try:

 1. Open Control Panel.
 2. Click Hardware and Sound.
 3. Click Power Options.
 4. Click the*Require a password on wakeup* option located on the left-pane.
 5. Click Change settings that are currently unavailable
 6. Under the *Windows Shutdown Settings* located at the end of the
    window,  uncheck the*Enable Hybrid Boot (recommended)* and click 
    the Save Changes button.

If it works, the hybrid boot of win8 isn't supported in the drivers...

Marc

Am 12.02.2013 16:01, schrieb Andreas Kinzler:
>
> Maybe the WinDbg log may be helpful. Sees to have some connection to 
> hibernation?
>
>
--8<--

--------------040805030507000108090904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Give this a try:<br>
      <ol>
        <li>Open Control Panel.</li>
        <li>Click Hardware and Sound.</li>
        <li>Click Power Options.</li>
        <li>Click the<strong> Require a password on wakeup</strong>
          option located on the left-pane.</li>
        <li>Click Change settings that are currently unavailable</li>
        <li>Under the <strong>Windows Shutdown Settings</strong>
          located at the end of the window,&nbsp; uncheck the<strong> Enable
            Hybrid Boot (recommended)</strong> and click&nbsp; the Save
          Changes button.</li>
      </ol>
      If it works, the hybrid boot of win8 isn't supported in the
      drivers...<br>
      <br>
      Marc<br>
      <br>
      Am 12.02.2013 16:01, schrieb Andreas Kinzler:<br>
    </div>
    <blockquote cite="mid:511A5937.3020101@hfp.de" type="cite">
      <br>
      Maybe the WinDbg log may be helpful. Sees to have some connection
      to hibernation?
      <br>
      <br>
      <br>
    </blockquote>
    --8&lt;--
  </body>
</html>

--------------040805030507000108090904--


--===============4800934718471692925==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4800934718471692925==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 19:15:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 19: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 1U5LKC-0005no-Ms; Tue, 12 Feb 2013 19:15:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <mad@wol.de>)
	id 1U5LKB-0005nj-03
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 19:15:27 +0000
Received: from [85.158.143.99:21333] by server-1.bemta-4.messagelabs.com id
	0F/E4-08839-EC49A115; Tue, 12 Feb 2013 19:15:26 +0000
X-Env-Sender: mad@wol.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360696525!22239638!1
X-Originating-IP: [193.158.62.4]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4245 invoked from network); 12 Feb 2013 19:15:25 -0000
Received: from cmx.wol.de (HELO cmx.wol.de) (193.158.62.4)
	by server-8.tower-216.messagelabs.com with SMTP;
	12 Feb 2013 19:15:25 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by cmx.wol.de (Postfix) with ESMTP id CCA0F5C141;
	Tue, 12 Feb 2013 20:15:24 +0100 (CET)
Received: from cmx.wol.de ([127.0.0.1])
	by localhost (cmx.wol.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id nLCIgkYSpviP; Tue, 12 Feb 2013 20:15:22 +0100 (CET)
Received: from [10.4.8.43] (p57901CBE.dip.t-dialin.net [87.144.28.190])
	by cmx.wol.de (Postfix) with ESMTP id 3F8325C119;
	Tue, 12 Feb 2013 20:15:22 +0100 (CET)
Message-ID: <511A94CA.7050207@wol.de>
Date: Tue, 12 Feb 2013 20:15:22 +0100
From: Marc Dahlhaus <mad@wol.de>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Andreas Kinzler <ml-xen-devel@hfp.de>
References: <511A45D0.4030806@hfp.de> <511A5937.3020101@hfp.de>
In-Reply-To: <511A5937.3020101@hfp.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4800934718471692925=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4800934718471692925==
Content-Type: multipart/alternative;
 boundary="------------040805030507000108090904"

This is a multi-part message in MIME format.
--------------040805030507000108090904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Give this a try:

 1. Open Control Panel.
 2. Click Hardware and Sound.
 3. Click Power Options.
 4. Click the*Require a password on wakeup* option located on the left-pane.
 5. Click Change settings that are currently unavailable
 6. Under the *Windows Shutdown Settings* located at the end of the
    window,  uncheck the*Enable Hybrid Boot (recommended)* and click 
    the Save Changes button.

If it works, the hybrid boot of win8 isn't supported in the drivers...

Marc

Am 12.02.2013 16:01, schrieb Andreas Kinzler:
>
> Maybe the WinDbg log may be helpful. Sees to have some connection to 
> hibernation?
>
>
--8<--

--------------040805030507000108090904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Give this a try:<br>
      <ol>
        <li>Open Control Panel.</li>
        <li>Click Hardware and Sound.</li>
        <li>Click Power Options.</li>
        <li>Click the<strong> Require a password on wakeup</strong>
          option located on the left-pane.</li>
        <li>Click Change settings that are currently unavailable</li>
        <li>Under the <strong>Windows Shutdown Settings</strong>
          located at the end of the window,&nbsp; uncheck the<strong> Enable
            Hybrid Boot (recommended)</strong> and click&nbsp; the Save
          Changes button.</li>
      </ol>
      If it works, the hybrid boot of win8 isn't supported in the
      drivers...<br>
      <br>
      Marc<br>
      <br>
      Am 12.02.2013 16:01, schrieb Andreas Kinzler:<br>
    </div>
    <blockquote cite="mid:511A5937.3020101@hfp.de" type="cite">
      <br>
      Maybe the WinDbg log may be helpful. Sees to have some connection
      to hibernation?
      <br>
      <br>
      <br>
    </blockquote>
    --8&lt;--
  </body>
</html>

--------------040805030507000108090904--


--===============4800934718471692925==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4800934718471692925==--


From xen-devel-bounces@lists.xen.org Tue Feb 12 19:17:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 19: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 1U5LLX-0005s3-6C; Tue, 12 Feb 2013 19:16: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 1U5LLV-0005rr-9G
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 19:16:49 +0000
Received: from [85.158.139.211:39098] by server-5.bemta-5.messagelabs.com id
	2C/42-11945-0259A115; Tue, 12 Feb 2013 19:16:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360696606!22077036!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5520 invoked from network); 12 Feb 2013 19:16:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 19:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1387069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 19: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.297.1; Tue, 12 Feb 2013 19:15:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5LKP-00017M-3o; Tue, 12 Feb 2013 19:15:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5LKP-0004fo-0N;
	Tue, 12 Feb 2013 19:15:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.38108.802123.636018@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 19:15:40 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <511A19D202000078000BDA3D@nat28.tlf.novell.com>
References: <osstest-15450-mainreport@xen.org>
	<511A19D202000078000BDA3D@nat28.tlf.novell.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-testing test] 15450: regressions - 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

Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 15450: regressions - FAIL - PUSHED"):
> >>> On 09.02.13 at 01:08, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 15450 xen-4.2-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15450/ 
> > 
> > Regressions :-(
> 
> So why did this do a push?

I have investigated this and it was due to my recent efforts to try to
make the push gate look at bisection reports too.  I had earlier
introduced a bug in sg-report-flight, which produces the report and
looks for regressions.  When it looks at a flight other than the one
we are mainly looking at, it is still prepared to write "tolerable" to
the output file which controls the push.  This wasn't a problem when
the other flights were other full flight tests of the same version,
but when it looks at a bisection flight it sees only one column of the
test matrix.

Sorry.  I've fixed this bug now.

We need to decide what to do with xen-4.2-testing.hg non-staging.  I
would be tempted to rewind it, if that isn't a horrible thing to do.
It's not as bad with hg as it is with git: aiui if you pull from a
rewound repo, nothing bad happens.

I think this can be done with hg strip.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 19:17:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 19: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 1U5LLX-0005s3-6C; Tue, 12 Feb 2013 19:16: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 1U5LLV-0005rr-9G
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 19:16:49 +0000
Received: from [85.158.139.211:39098] by server-5.bemta-5.messagelabs.com id
	2C/42-11945-0259A115; Tue, 12 Feb 2013 19:16:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360696606!22077036!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIxOTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5520 invoked from network); 12 Feb 2013 19:16:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 19:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; 
   d="scan'208";a="1387069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 19: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.297.1; Tue, 12 Feb 2013 19:15:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5LKP-00017M-3o; Tue, 12 Feb 2013 19:15:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5LKP-0004fo-0N;
	Tue, 12 Feb 2013 19:15:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20762.38108.802123.636018@mariner.uk.xensource.com>
Date: Tue, 12 Feb 2013 19:15:40 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <511A19D202000078000BDA3D@nat28.tlf.novell.com>
References: <osstest-15450-mainreport@xen.org>
	<511A19D202000078000BDA3D@nat28.tlf.novell.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-testing test] 15450: regressions - 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

Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 15450: regressions - FAIL - PUSHED"):
> >>> On 09.02.13 at 01:08, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 15450 xen-4.2-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/15450/ 
> > 
> > Regressions :-(
> 
> So why did this do a push?

I have investigated this and it was due to my recent efforts to try to
make the push gate look at bisection reports too.  I had earlier
introduced a bug in sg-report-flight, which produces the report and
looks for regressions.  When it looks at a flight other than the one
we are mainly looking at, it is still prepared to write "tolerable" to
the output file which controls the push.  This wasn't a problem when
the other flights were other full flight tests of the same version,
but when it looks at a bisection flight it sees only one column of the
test matrix.

Sorry.  I've fixed this bug now.

We need to decide what to do with xen-4.2-testing.hg non-staging.  I
would be tempted to rewind it, if that isn't a horrible thing to do.
It's not as bad with hg as it is with git: aiui if you pull from a
rewound repo, nothing bad happens.

I think this can be done with hg strip.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 20:03:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 20: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 1U5M3Z-0006P6-6X; Tue, 12 Feb 2013 20:02:21 +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 1U5M3X-0006P1-OU
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 20:02:20 +0000
Received: from [85.158.139.211:54882] by server-10.bemta-5.messagelabs.com id
	CA/A1-04697-ACF9A115; Tue, 12 Feb 2013 20:02:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360699336!20545674!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE2NTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26827 invoked from network); 12 Feb 2013 20:02:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 20:02:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CK28sR013061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 20:02:09 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
	r1CK26hZ013167
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 20:02:06 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1CK25ER007833; Tue, 12 Feb 2013 14:02:05 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 12:02:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 09C4C1BF781; Tue, 12 Feb 2013 15:02:04 -0500 (EST)
Date: Tue, 12 Feb 2013 15:02:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Milan opath <milan.opath@gmail.com>
Message-ID: <20130212200203.GR3016@phenom.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wrote:
> I apologize for the patching confusion. I applied Konrad's acpi-s3 patch to
> linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
> dom0_vcpus_pin to xen kernel line in bootloader but still I cannot modprobe
> acpi_cpufreq and S3 sleep resume still not working.

The module is xen-acpi-processor and you should see whether it works by
running 'xenpm get-cpufreq-para'. If you get values then it worked.

> 
> How can I debug it?
> Thanks.
> 
> 
> 2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>
> 
> > On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> > <tomasz.wroblewski@citrix.com> wrote:
> > >
> > >> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> > >> you are .. ah yes, you are hitting a bug that should be in the stable
> > >> tree fix.
> > >>
> > >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> > >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> > >>
> > >>
> > >
> > > Thanks Konrad. I've tried your patches, and whilst I have not seen this
> > > crash in cpuidle_register anymore, the others are still present (in
> > > build_schedule_domains for example).
> > >
> >
> > That looks familiar too. I think it got fixed in the upstream kernel
> > and it was a generic bug - but I can't recall which commit it was.
> >
> > > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
> > > commandline stops both the xen scheduler and dom0 kernel crashing and all
> > > works fine - made dozens of succesfull s3 attempts. Was wondering if you
> > > guys had any thoughts on this? Is the dom0 kernel even supposed to cope
> > > during s3 in non dom0 vcpu pin case?
> > >
> > No that is something new. Is this only an issue on Intel boxes but not AMD?
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 20:03:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 20: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 1U5M3Z-0006P6-6X; Tue, 12 Feb 2013 20:02:21 +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 1U5M3X-0006P1-OU
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 20:02:20 +0000
Received: from [85.158.139.211:54882] by server-10.bemta-5.messagelabs.com id
	CA/A1-04697-ACF9A115; Tue, 12 Feb 2013 20:02:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360699336!20545674!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE2NTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26827 invoked from network); 12 Feb 2013 20:02:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 20:02:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CK28sR013061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 20:02:09 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
	r1CK26hZ013167
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 20:02:06 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1CK25ER007833; Tue, 12 Feb 2013 14:02:05 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 12 Feb 2013 12:02:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 09C4C1BF781; Tue, 12 Feb 2013 15:02:04 -0500 (EST)
Date: Tue, 12 Feb 2013 15:02:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Milan opath <milan.opath@gmail.com>
Message-ID: <20130212200203.GR3016@phenom.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wrote:
> I apologize for the patching confusion. I applied Konrad's acpi-s3 patch to
> linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
> dom0_vcpus_pin to xen kernel line in bootloader but still I cannot modprobe
> acpi_cpufreq and S3 sleep resume still not working.

The module is xen-acpi-processor and you should see whether it works by
running 'xenpm get-cpufreq-para'. If you get values then it worked.

> 
> How can I debug it?
> Thanks.
> 
> 
> 2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>
> 
> > On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> > <tomasz.wroblewski@citrix.com> wrote:
> > >
> > >> Hm, that is suspect. There should not be any cpuidle_register? Perhaps
> > >> you are .. ah yes, you are hitting a bug that should be in the stable
> > >> tree fix.
> > >>
> > >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> > >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> > >>
> > >>
> > >
> > > Thanks Konrad. I've tried your patches, and whilst I have not seen this
> > > crash in cpuidle_register anymore, the others are still present (in
> > > build_schedule_domains for example).
> > >
> >
> > That looks familiar too. I think it got fixed in the upstream kernel
> > and it was a generic bug - but I can't recall which commit it was.
> >
> > > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on xen
> > > commandline stops both the xen scheduler and dom0 kernel crashing and all
> > > works fine - made dozens of succesfull s3 attempts. Was wondering if you
> > > guys had any thoughts on this? Is the dom0 kernel even supposed to cope
> > > during s3 in non dom0 vcpu pin case?
> > >
> > No that is something new. Is this only an issue on Intel boxes but not AMD?
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 21:31:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 21: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 1U5NRC-0006s7-9Y; Tue, 12 Feb 2013 21:30:50 +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 1U5NRB-0006s2-34
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 21:30:49 +0000
Received: from [85.158.143.99:6163] by server-3.bemta-4.messagelabs.com id
	28/76-08920-784BA115; Tue, 12 Feb 2013 21:30:47 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360704644!25018912!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgxNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 12 Feb 2013 21:30:46 -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;
	12 Feb 2013 21:30:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,652,1355097600"; 
   d="scan'208";a="7247171"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 21:30:31 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 12 Feb 2013
	16:30:32 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 16:30:35 -0500
Thread-Topic: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough
Thread-Index: Ac4JOD7elvZP+BnVSs6FTKjPm/9ISgAL8Rfg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320CC2881@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31F6B645F@FTLPMAILBOX02.citrite.net>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BE8@FTLPMAILBOX02.citrite.net>
	<516D2318-7330-49AD-9BC0-222274803CC7@gmail.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BF3@FTLPMAILBOX02.citrite.net>
	<20130109145555.GA19595@phenom.dumpdata.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1C9E@FTLPMAILBOX02.citrite.net>
	<20762.25605.626511.737910@mariner.uk.xensource.com>
In-Reply-To: <20762.25605.626511.737910@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
Cc: Konrad Rzeszutek Will <ketuzsezr@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v4 00/04] 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 Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Tuesday, February 12, 2013 10:47 AM
> To: Ross Philipson
> Cc: Konrad Rzeszutek Wilk; Konrad Rzeszutek Will; xen-
> devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough
> 
> Ross Philipson writes ("Re: [Xen-devel] [PATCH v4 00/04] HVM firmware
> passthrough"):
> > I am not sure if that is related to my patches. I had brought up the
> point
> > that the new xc_hvm_build() routine was never called from xl. I think
> the
> > consensus was that I should remedy that in the process of adding the
> support
> > for fw pass-through.
> 
> I think in general it is best to introduce new features in the whole
> stack in the same series.
> 
> That way we don't introduce code at lower layers only to discover
> later that the higher layer wants something different.

In the future I will do this.

> 
> > I planned to do xl after the first patch set went in - are there any
> vetoes
> > to that plan? Also since I will be adding parameters I suspect I need
> to
> > update the docs on the xl configuration files. Any pointers on how to
> do that
> > would be helpful. I see the man page source in docs/man/xl.cfg.pod.5;
> is
> > the wiki information generated off of this?
> 
> How are you testing this series yourself if you don't have a suitable
> series for libxl/xl as well ?

I just had some hard coded test code that more or less behaved as the
code I am submitting for libxl behaves.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 21:31:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 21: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 1U5NRC-0006s7-9Y; Tue, 12 Feb 2013 21:30:50 +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 1U5NRB-0006s2-34
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 21:30:49 +0000
Received: from [85.158.143.99:6163] by server-3.bemta-4.messagelabs.com id
	28/76-08920-784BA115; Tue, 12 Feb 2013 21:30:47 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360704644!25018912!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTgxNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 12 Feb 2013 21:30:46 -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;
	12 Feb 2013 21:30:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,652,1355097600"; 
   d="scan'208";a="7247171"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Feb 2013 21:30:31 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 12 Feb 2013
	16:30:32 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 12 Feb 2013 16:30:35 -0500
Thread-Topic: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough
Thread-Index: Ac4JOD7elvZP+BnVSs6FTKjPm/9ISgAL8Rfg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320CC2881@FTLPMAILBOX02.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720A31F6B645F@FTLPMAILBOX02.citrite.net>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BE8@FTLPMAILBOX02.citrite.net>
	<516D2318-7330-49AD-9BC0-222274803CC7@gmail.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1BF3@FTLPMAILBOX02.citrite.net>
	<20130109145555.GA19595@phenom.dumpdata.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31FBE1C9E@FTLPMAILBOX02.citrite.net>
	<20762.25605.626511.737910@mariner.uk.xensource.com>
In-Reply-To: <20762.25605.626511.737910@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
Cc: Konrad Rzeszutek Will <ketuzsezr@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v4 00/04] 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 Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Tuesday, February 12, 2013 10:47 AM
> To: Ross Philipson
> Cc: Konrad Rzeszutek Wilk; Konrad Rzeszutek Will; xen-
> devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough
> 
> Ross Philipson writes ("Re: [Xen-devel] [PATCH v4 00/04] HVM firmware
> passthrough"):
> > I am not sure if that is related to my patches. I had brought up the
> point
> > that the new xc_hvm_build() routine was never called from xl. I think
> the
> > consensus was that I should remedy that in the process of adding the
> support
> > for fw pass-through.
> 
> I think in general it is best to introduce new features in the whole
> stack in the same series.
> 
> That way we don't introduce code at lower layers only to discover
> later that the higher layer wants something different.

In the future I will do this.

> 
> > I planned to do xl after the first patch set went in - are there any
> vetoes
> > to that plan? Also since I will be adding parameters I suspect I need
> to
> > update the docs on the xl configuration files. Any pointers on how to
> do that
> > would be helpful. I see the man page source in docs/man/xl.cfg.pod.5;
> is
> > the wiki information generated off of this?
> 
> How are you testing this series yourself if you don't have a suitable
> series for libxl/xl as well ?

I just had some hard coded test code that more or less behaved as the
code I am submitting for libxl behaves.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 21:57:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 21: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 1U5Nqr-000771-Po; Tue, 12 Feb 2013 21:57:21 +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 1U5Nqp-00076w-Tl
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 21:57:20 +0000
Received: from [85.158.143.35:42482] by server-2.bemta-4.messagelabs.com id
	40/8B-01597-FBABA115; Tue, 12 Feb 2013 21:57:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360706234!13600448!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE2NTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30552 invoked from network); 12 Feb 2013 21:57:15 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 21:57:15 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CLuwtU002129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 21:56: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
	r1CLuw7M020309
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 21:56:58 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
	r1CLuwIC032128; Tue, 12 Feb 2013 15:56:58 -0600
Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Tue, 12 Feb 2013 13:56:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 56B771BF781;
	Tue, 12 Feb 2013 16:56:55 -0500 (EST)
USER-AGENT: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
Message-ID: <20130212215655.GA18127@phenom.dumpdata.com>
Date: Tue, 12 Feb 2013 13:56:55 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Milan opath <milan.opath@gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
In-Reply-To: <CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Tue, Feb 12, 2013 at 10:40:32PM +0100, Milan opath wrote:
> xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
> ok. Unfortunately resume from S3 still doesn't work.

So then the process of elimination starts. Try doing it without having Xorg or any
KMS drivers running (so text-console). Then also try without serial output.
And also as somebody suggested with dom0_pin_vcpus arguments.

> 
> 
> 
> 
> 
> 
> 2013/2/12 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > On Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wrote:
> > > I apologize for the patching confusion. I applied Konrad's acpi-s3 patch
> > to
> > > linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
> > > dom0_vcpus_pin to xen kernel line in bootloader but still I cannot
> > modprobe
> > > acpi_cpufreq and S3 sleep resume still not working.
> >
> > The module is xen-acpi-processor and you should see whether it works by
> > running 'xenpm get-cpufreq-para'. If you get values then it worked.
> >
> > >
> > > How can I debug it?
> > > Thanks.
> > >
> > >
> > > 2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>
> > >
> > > > On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> > > > <tomasz.wroblewski@citrix.com> wrote:
> > > > >
> > > > >> Hm, that is suspect. There should not be any cpuidle_register?
> > Perhaps
> > > > >> you are .. ah yes, you are hitting a bug that should be in the
> > stable
> > > > >> tree fix.
> > > > >>
> > > > >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> > > > >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> > > > >>
> > > > >>
> > > > >
> > > > > Thanks Konrad. I've tried your patches, and whilst I have not seen
> > this
> > > > > crash in cpuidle_register anymore, the others are still present (in
> > > > > build_schedule_domains for example).
> > > > >
> > > >
> > > > That looks familiar too. I think it got fixed in the upstream kernel
> > > > and it was a generic bug - but I can't recall which commit it was.
> > > >
> > > > > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on
> > xen
> > > > > commandline stops both the xen scheduler and dom0 kernel crashing
> > and all
> > > > > works fine - made dozens of succesfull s3 attempts. Was wondering if
> > you
> > > > > guys had any thoughts on this? Is the dom0 kernel even supposed to
> > cope
> > > > > during s3 in non dom0 vcpu pin case?
> > > > >
> > > > No that is something new. Is this only an issue on Intel boxes but not
> > AMD?
> > > >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 21:57:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 21: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 1U5Nqr-000771-Po; Tue, 12 Feb 2013 21:57:21 +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 1U5Nqp-00076w-Tl
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 21:57:20 +0000
Received: from [85.158.143.35:42482] by server-2.bemta-4.messagelabs.com id
	40/8B-01597-FBABA115; Tue, 12 Feb 2013 21:57:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360706234!13600448!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjE2NTcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30552 invoked from network); 12 Feb 2013 21:57:15 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Feb 2013 21:57:15 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1CLuwtU002129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 12 Feb 2013 21:56: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
	r1CLuw7M020309
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 12 Feb 2013 21:56:58 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
	r1CLuwIC032128; Tue, 12 Feb 2013 15:56:58 -0600
Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Tue, 12 Feb 2013 13:56:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 56B771BF781;
	Tue, 12 Feb 2013 16:56:55 -0500 (EST)
USER-AGENT: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
Message-ID: <20130212215655.GA18127@phenom.dumpdata.com>
Date: Tue, 12 Feb 2013 13:56:55 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Milan opath <milan.opath@gmail.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
In-Reply-To: <CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Tue, Feb 12, 2013 at 10:40:32PM +0100, Milan opath wrote:
> xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
> ok. Unfortunately resume from S3 still doesn't work.

So then the process of elimination starts. Try doing it without having Xorg or any
KMS drivers running (so text-console). Then also try without serial output.
And also as somebody suggested with dom0_pin_vcpus arguments.

> 
> 
> 
> 
> 
> 
> 2013/2/12 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > On Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wrote:
> > > I apologize for the patching confusion. I applied Konrad's acpi-s3 patch
> > to
> > > linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
> > > dom0_vcpus_pin to xen kernel line in bootloader but still I cannot
> > modprobe
> > > acpi_cpufreq and S3 sleep resume still not working.
> >
> > The module is xen-acpi-processor and you should see whether it works by
> > running 'xenpm get-cpufreq-para'. If you get values then it worked.
> >
> > >
> > > How can I debug it?
> > > Thanks.
> > >
> > >
> > > 2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>
> > >
> > > > On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> > > > <tomasz.wroblewski@citrix.com> wrote:
> > > > >
> > > > >> Hm, that is suspect. There should not be any cpuidle_register?
> > Perhaps
> > > > >> you are .. ah yes, you are hitting a bug that should be in the
> > stable
> > > > >> tree fix.
> > > > >>
> > > > >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> > > > >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> > > > >>
> > > > >>
> > > > >
> > > > > Thanks Konrad. I've tried your patches, and whilst I have not seen
> > this
> > > > > crash in cpuidle_register anymore, the others are still present (in
> > > > > build_schedule_domains for example).
> > > > >
> > > >
> > > > That looks familiar too. I think it got fixed in the upstream kernel
> > > > and it was a generic bug - but I can't recall which commit it was.
> > > >
> > > > > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on
> > xen
> > > > > commandline stops both the xen scheduler and dom0 kernel crashing
> > and all
> > > > > works fine - made dozens of succesfull s3 attempts. Was wondering if
> > you
> > > > > guys had any thoughts on this? Is the dom0 kernel even supposed to
> > cope
> > > > > during s3 in non dom0 vcpu pin case?
> > > > >
> > > > No that is something new. Is this only an issue on Intel boxes but not
> > AMD?
> > > >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 22:19:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 22: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 1U5OC3-0007M0-Px; Tue, 12 Feb 2013 22:19:15 +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 1U5OC2-0007Lv-VU
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 22:19:15 +0000
Received: from [85.158.143.35:63126] by server-2.bemta-4.messagelabs.com id
	E3/15-01597-2EFBA115; Tue, 12 Feb 2013 22:19:14 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360707548!13629256!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31988 invoked from network); 12 Feb 2013 22:19:10 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 22:19:10 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5OBs-0006AW-3C; Wed, 13 Feb 2013 09:19:04 +1100
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 id
	14.01.0438.000; Wed, 13 Feb 2013 09:19:04 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Andreas Kinzler <ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQ
Date: Tue, 12 Feb 2013 22:19:04 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
In-Reply-To: <511A45D0.4030806@hfp.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.58]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19634.002
x-tm-as-result: No--28.648700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> What is the state of GPLPV and Windows 8? I am currently running tests
> with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look
> good. There seems to be a problem with shutdown/reboot where Windows
> hangs somewhat and displays a warning about improper shutdown on next
> reboot.
> 

I have only tested with Windows 2012 but it shouldn't be any different to 8. My testing was pretty much limited to 'does it boot' testing, but I don't recall having any problems with shutdown or anything.

Are you interested in trying the very latest version? I've been doing a fairly major update in the way the child devices talk to the bus driver and it is now at a point where everything should be working but I haven't done a lot of testing yet.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 22:19:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 22: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 1U5OC3-0007M0-Px; Tue, 12 Feb 2013 22:19:15 +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 1U5OC2-0007Lv-VU
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 22:19:15 +0000
Received: from [85.158.143.35:63126] by server-2.bemta-4.messagelabs.com id
	E3/15-01597-2EFBA115; Tue, 12 Feb 2013 22:19:14 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360707548!13629256!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31988 invoked from network); 12 Feb 2013 22:19:10 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 22:19:10 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5OBs-0006AW-3C; Wed, 13 Feb 2013 09:19:04 +1100
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 id
	14.01.0438.000; Wed, 13 Feb 2013 09:19:04 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Andreas Kinzler <ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQ
Date: Tue, 12 Feb 2013 22:19:04 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
In-Reply-To: <511A45D0.4030806@hfp.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.58]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19634.002
x-tm-as-result: No--28.648700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> What is the state of GPLPV and Windows 8? I am currently running tests
> with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look
> good. There seems to be a problem with shutdown/reboot where Windows
> hangs somewhat and displays a warning about improper shutdown on next
> reboot.
> 

I have only tested with Windows 2012 but it shouldn't be any different to 8. My testing was pretty much limited to 'does it boot' testing, but I don't recall having any problems with shutdown or anything.

Are you interested in trying the very latest version? I've been doing a fairly major update in the way the child devices talk to the bus driver and it is now at a point where everything should be working but I haven't done a lot of testing yet.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 22:20:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 22:20: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 1U5OCo-0007OA-4C; Tue, 12 Feb 2013 22:20:02 +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 1U5OCl-0007Nv-Dm
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 22:19:59 +0000
Received: from [85.158.139.211:28447] by server-16.bemta-5.messagelabs.com id
	7F/BE-14948-E00CA115; Tue, 12 Feb 2013 22:19:58 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360707594!21122610!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21763 invoked from network); 12 Feb 2013 22:19:57 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 22:19:57 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5OCd-0002fv-Mk; Wed, 13 Feb 2013 09:19:51 +1100
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 id
	14.01.0438.000; Wed, 13 Feb 2013 09:19:51 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Andreas Kinzler <ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh1mOOAgAEy4ZA=
Date: Tue, 12 Feb 2013 22:19:47 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3566D4F5@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de> <511A5937.3020101@hfp.de>
In-Reply-To: <511A5937.3020101@hfp.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.58]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19634.002
x-tm-as-result: No--25.457800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Maybe the WinDbg log may be helpful. Sees to have some connection to
> hibernation?
> 

Were you actually hibernating at the time?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 12 22:20:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 12 Feb 2013 22:20: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 1U5OCo-0007OA-4C; Tue, 12 Feb 2013 22:20:02 +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 1U5OCl-0007Nv-Dm
	for xen-devel@lists.xensource.com; Tue, 12 Feb 2013 22:19:59 +0000
Received: from [85.158.139.211:28447] by server-16.bemta-5.messagelabs.com id
	7F/BE-14948-E00CA115; Tue, 12 Feb 2013 22:19:58 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360707594!21122610!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21763 invoked from network); 12 Feb 2013 22:19:57 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Feb 2013 22:19:57 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5OCd-0002fv-Mk; Wed, 13 Feb 2013 09:19:51 +1100
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 id
	14.01.0438.000; Wed, 13 Feb 2013 09:19:51 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Andreas Kinzler <ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh1mOOAgAEy4ZA=
Date: Tue, 12 Feb 2013 22:19:47 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3566D4F5@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de> <511A5937.3020101@hfp.de>
In-Reply-To: <511A5937.3020101@hfp.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.58]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19634.002
x-tm-as-result: No--25.457800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> Maybe the WinDbg log may be helpful. Sees to have some connection to
> hibernation?
> 

Were you actually hibernating at the time?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 01:34:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 01:34: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 1U5REW-0004Er-Re; Wed, 13 Feb 2013 01:34: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@oracle.com>) id 1U5REU-0004Em-Ls
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 01:33:58 +0000
Received: from [85.158.143.35:29303] by server-3.bemta-4.messagelabs.com id
	23/FB-08920-58DEA115; Wed, 13 Feb 2013 01:33:57 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360719235!4755834!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjg5NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8562 invoked from network); 13 Feb 2013 01:33:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 01:33:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1D1Xq5n032227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 01:33:53 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
	r1D1Xq7u006958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 01:33:52 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
	r1D1XqZb017924; Tue, 12 Feb 2013 19:33:52 -0600
MIME-Version: 1.0
Message-ID: <04647143-a56e-44ef-b3a5-2bf98d704802@default>
Date: Tue, 12 Feb 2013 17:33:51 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <povder@gmail.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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


----- povder@gmail.com wrote:

> I disabled id BIOS IDE interface that was causing problems and system
> boots fine. Thanks for your help!
> 
> I just wonder if it's a bug in BIOS or in Xen. If it's ASUS bug I
> would like to report bug to them.


This looks like BIOS bug -- there is no entry for the IDE interface in IVRS
table (which is used by IOMMU driver to discover devices). 

I am wondering whether such cases (undeclared devices in IVRS) should cause a
panic or disabling of IOMMU. This may be a more generic case of Jan's earlier 
patch for dealing with missing IOAPIC. Not sure whether it would be possible 
to "unwind" IOMMU at this point though.

(For the record, I asked povder to run with xen-unstable that I provided 
to him because for some reason I thought this might be combined mode problem.
Obviously this had nothing to do with combined mode)

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 01:34:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 01:34: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 1U5REW-0004Er-Re; Wed, 13 Feb 2013 01:34: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@oracle.com>) id 1U5REU-0004Em-Ls
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 01:33:58 +0000
Received: from [85.158.143.35:29303] by server-3.bemta-4.messagelabs.com id
	23/FB-08920-58DEA115; Wed, 13 Feb 2013 01:33:57 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360719235!4755834!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjg5NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8562 invoked from network); 13 Feb 2013 01:33:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 01:33:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1D1Xq5n032227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 01:33:53 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
	r1D1Xq7u006958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 01:33:52 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
	r1D1XqZb017924; Tue, 12 Feb 2013 19:33:52 -0600
MIME-Version: 1.0
Message-ID: <04647143-a56e-44ef-b3a5-2bf98d704802@default>
Date: Tue, 12 Feb 2013 17:33:51 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <povder@gmail.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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


----- povder@gmail.com wrote:

> I disabled id BIOS IDE interface that was causing problems and system
> boots fine. Thanks for your help!
> 
> I just wonder if it's a bug in BIOS or in Xen. If it's ASUS bug I
> would like to report bug to them.


This looks like BIOS bug -- there is no entry for the IDE interface in IVRS
table (which is used by IOMMU driver to discover devices). 

I am wondering whether such cases (undeclared devices in IVRS) should cause a
panic or disabling of IOMMU. This may be a more generic case of Jan's earlier 
patch for dealing with missing IOAPIC. Not sure whether it would be possible 
to "unwind" IOMMU at this point though.

(For the record, I asked povder to run with xen-unstable that I provided 
to him because for some reason I thought this might be combined mode problem.
Obviously this had nothing to do with combined mode)

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 02:53:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 02:53: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 1U5SSx-0004zP-5h; Wed, 13 Feb 2013 02:52:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U5SSw-0004zK-90
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 02:52:58 +0000
Received: from [85.158.139.211:6043] by server-2.bemta-5.messagelabs.com id
	B0/4A-16911-9000B115; Wed, 13 Feb 2013 02:52:57 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360723975!21198924!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23813 invoked from network); 13 Feb 2013 02:52:56 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-2.tower-206.messagelabs.com with SMTP;
	13 Feb 2013 02:52:56 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1D2prK5002862;
	Tue, 12 Feb 2013 21:51:54 -0500
Message-ID: <511AFFC9.3050404@theshore.net>
Date: Tue, 12 Feb 2013 21:51:53 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360663133.20449.123.camel@zakaz.uk.xensource.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/12/13 4:58 AM, Ian Campbell wrote:
> Have you applied the XSA-39 fixes to this kernel?

Yes!  When I rebuilt with Wei's suggested patch for my original 
netback/xenwatch problem I also brought us up to date with XSA patches.

We just hit the same (new) problem on another machine, and looking at 
the BUG with more kernel output context gives a giant clue:

Feb 12 20:30:54: IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready
Feb 12 20:30:54: device vif21.0 entered promiscuous mode
Feb 12 20:30:56: xen-blkback:ring-ref 8, event-channel 31, protocol 2 
(x86_32-abi)
Feb 12 20:30:56: xen-blkback:ring-ref 9, event-channel 32, protocol 2 
(x86_32-abi)
Feb 12 20:30:56: IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready
Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
Feb 12 20:30:58: br0: port 5(vif21.0) entered forwarding state
Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
<--------------
Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference 
at 00000000000008b8
Feb 12 20:34:12: IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
Feb 12 20:34:12: PGD 0
Feb 12 20:34:12: Oops: 0002 [#1] SMP
Feb 12 20:34:12: Modules linked in: ebt_comment ebt_arp ebt_set 
ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev 
bonding ebtable_filter e1000e
Feb 12 20:34:12: CPU 3
Feb 12 20:34:12: Pid: 1548, comm: netback/3 Not tainted 3.7.6-1-x86_64 
#1 Supermicro X8DT6/X8DT6
Feb 12 20:34:12: RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
xen_spin_lock_flags+0x3a/0x80
Feb 12 20:34:12: RSP: e02b:ffff880083681b58  EFLAGS: 00010006
Feb 12 20:34:12: RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 
0000000000000663
Feb 12 20:34:12: RDX: 0000000000000001 RSI: 0000000000000210 RDI: 
00000000000008b8
Feb 12 20:34:12: RBP: ffff880083681b78 R08: 000000000000000d R09: 
0000000000000000
Feb 12 20:34:12: R10: 0000000000000001 R11: 0000000000000001 R12: 
0000000000000001
Feb 12 20:34:12: R13: 0000000000000200 R14: 0000000000000400 R15: 
0000000000000663
Feb 12 20:34:12: FS:  00007f2bc1fb2700(0000) GS:ffff8801006c0000(0000) 
knlGS:0000000000000000
Feb 12 20:34:12: CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
Feb 12 20:34:12: CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 
0000000000002660
Feb 12 20:34:12: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
Feb 12 20:34:12: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
Feb 12 20:34:12: Process netback/3 (pid: 1548, threadinfo 
ffff880083680000, task ffff8800837ec9c0)
Feb 12 20:34:12: Stack:
Feb 12 20:34:12: 0000000000000210 00000000000008b8 ffff880003baa700 
ffff880003baa7d8
Feb 12 20:34:12: ffff880083681b98 ffffffff817605da 0000000000000000 
00000000000008b8
Feb 12 20:34:12: ffff880083681bd8 ffffffff8154446f ffff880003baa000 
0000000000000000
Feb 12 20:34:12: Call Trace:
Feb 12 20:34:12: [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
Feb 12 20:34:12: [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
Feb 12 20:34:12: [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
Feb 12 20:34:12: [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
Feb 12 20:34:12: [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
Feb 12 20:34:12: [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
Feb 12 20:34:12: [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
Feb 12 20:34:12: [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
Feb 12 20:34:12: [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
Feb 12 20:34:12: [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
Feb 12 20:34:12: [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
Feb 12 20:34:12: [<ffffffff81071a06>] kthread+0xc6/0xd0
Feb 12 20:34:12: [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
Feb 12 20:34:12: [<ffffffff81071940>] ? 
kthread_freezable_should_stop+0x70/0x70
Feb 12 20:34:12: [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
Feb 12 20:34:12: [<ffffffff81071940>] ? 
kthread_freezable_should_stop+0x70/0x70
Feb 12 20:34:12: Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 
89 fb 41 81 e5 00 02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 
44 89 e2 <86> 13 84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
Feb 12 20:34:12: RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
Feb 12 20:34:12: RSP <ffff880083681b58>
Feb 12 20:34:12: CR2: 00000000000008b8
Feb 12 20:34:12: ---[ end trace ae243211c8c8cba5 ]---

https://lkml.org/lkml/2013/2/12/575 - "xen/netback: shut down the ring 
if it contains garbage"

-Chris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 02:53:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 02:53: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 1U5SSx-0004zP-5h; Wed, 13 Feb 2013 02:52:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U5SSw-0004zK-90
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 02:52:58 +0000
Received: from [85.158.139.211:6043] by server-2.bemta-5.messagelabs.com id
	B0/4A-16911-9000B115; Wed, 13 Feb 2013 02:52:57 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360723975!21198924!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23813 invoked from network); 13 Feb 2013 02:52:56 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-2.tower-206.messagelabs.com with SMTP;
	13 Feb 2013 02:52:56 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1D2prK5002862;
	Tue, 12 Feb 2013 21:51:54 -0500
Message-ID: <511AFFC9.3050404@theshore.net>
Date: Tue, 12 Feb 2013 21:51:53 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360663133.20449.123.camel@zakaz.uk.xensource.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/12/13 4:58 AM, Ian Campbell wrote:
> Have you applied the XSA-39 fixes to this kernel?

Yes!  When I rebuilt with Wei's suggested patch for my original 
netback/xenwatch problem I also brought us up to date with XSA patches.

We just hit the same (new) problem on another machine, and looking at 
the BUG with more kernel output context gives a giant clue:

Feb 12 20:30:54: IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready
Feb 12 20:30:54: device vif21.0 entered promiscuous mode
Feb 12 20:30:56: xen-blkback:ring-ref 8, event-channel 31, protocol 2 
(x86_32-abi)
Feb 12 20:30:56: xen-blkback:ring-ref 9, event-channel 32, protocol 2 
(x86_32-abi)
Feb 12 20:30:56: IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready
Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
Feb 12 20:30:58: br0: port 5(vif21.0) entered forwarding state
Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
<--------------
Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference 
at 00000000000008b8
Feb 12 20:34:12: IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
Feb 12 20:34:12: PGD 0
Feb 12 20:34:12: Oops: 0002 [#1] SMP
Feb 12 20:34:12: Modules linked in: ebt_comment ebt_arp ebt_set 
ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev 
bonding ebtable_filter e1000e
Feb 12 20:34:12: CPU 3
Feb 12 20:34:12: Pid: 1548, comm: netback/3 Not tainted 3.7.6-1-x86_64 
#1 Supermicro X8DT6/X8DT6
Feb 12 20:34:12: RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
xen_spin_lock_flags+0x3a/0x80
Feb 12 20:34:12: RSP: e02b:ffff880083681b58  EFLAGS: 00010006
Feb 12 20:34:12: RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 
0000000000000663
Feb 12 20:34:12: RDX: 0000000000000001 RSI: 0000000000000210 RDI: 
00000000000008b8
Feb 12 20:34:12: RBP: ffff880083681b78 R08: 000000000000000d R09: 
0000000000000000
Feb 12 20:34:12: R10: 0000000000000001 R11: 0000000000000001 R12: 
0000000000000001
Feb 12 20:34:12: R13: 0000000000000200 R14: 0000000000000400 R15: 
0000000000000663
Feb 12 20:34:12: FS:  00007f2bc1fb2700(0000) GS:ffff8801006c0000(0000) 
knlGS:0000000000000000
Feb 12 20:34:12: CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
Feb 12 20:34:12: CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 
0000000000002660
Feb 12 20:34:12: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
Feb 12 20:34:12: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
Feb 12 20:34:12: Process netback/3 (pid: 1548, threadinfo 
ffff880083680000, task ffff8800837ec9c0)
Feb 12 20:34:12: Stack:
Feb 12 20:34:12: 0000000000000210 00000000000008b8 ffff880003baa700 
ffff880003baa7d8
Feb 12 20:34:12: ffff880083681b98 ffffffff817605da 0000000000000000 
00000000000008b8
Feb 12 20:34:12: ffff880083681bd8 ffffffff8154446f ffff880003baa000 
0000000000000000
Feb 12 20:34:12: Call Trace:
Feb 12 20:34:12: [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
Feb 12 20:34:12: [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
Feb 12 20:34:12: [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
Feb 12 20:34:12: [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
Feb 12 20:34:12: [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
Feb 12 20:34:12: [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
Feb 12 20:34:12: [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
Feb 12 20:34:12: [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
Feb 12 20:34:12: [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
Feb 12 20:34:12: [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
Feb 12 20:34:12: [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
Feb 12 20:34:12: [<ffffffff81071a06>] kthread+0xc6/0xd0
Feb 12 20:34:12: [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
Feb 12 20:34:12: [<ffffffff81071940>] ? 
kthread_freezable_should_stop+0x70/0x70
Feb 12 20:34:12: [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
Feb 12 20:34:12: [<ffffffff81071940>] ? 
kthread_freezable_should_stop+0x70/0x70
Feb 12 20:34:12: Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 
89 fb 41 81 e5 00 02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 
44 89 e2 <86> 13 84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
Feb 12 20:34:12: RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
Feb 12 20:34:12: RSP <ffff880083681b58>
Feb 12 20:34:12: CR2: 00000000000008b8
Feb 12 20:34:12: ---[ end trace ae243211c8c8cba5 ]---

https://lkml.org/lkml/2013/2/12/575 - "xen/netback: shut down the ring 
if it contains garbage"

-Chris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 06:13:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 06: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 1U5Va1-0006Ij-44; Wed, 13 Feb 2013 06:12: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 1U5VZz-0006Ie-BD
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 06:12:27 +0000
Received: from [85.158.139.211:27009] by server-6.bemta-5.messagelabs.com id
	9B/C9-01489-ACE2B115; Wed, 13 Feb 2013 06:12:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360735945!20786283!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMTE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3422 invoked from network); 13 Feb 2013 06:12:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 06:12:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1401178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 06:12: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.297.1; Wed, 13 Feb 2013 06:12:25 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5VZw-0004Xw-SB;
	Wed, 13 Feb 2013 06:12:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5VZw-000578-Nz;
	Wed, 13 Feb 2013 06:12:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16159-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 06:12:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16159: 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 16159 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16159/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15449
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15449

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  cb92e40d8681
baseline version:
 xen                  130446135528

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=cb92e40d8681
+ . 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 cb92e40d8681
+ branch=xen-4.1-testing
+ revision=cb92e40d8681
+ . 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/hg/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 cb92e40d8681 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 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 Wed Feb 13 06:13:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 06: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 1U5Va1-0006Ij-44; Wed, 13 Feb 2013 06:12: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 1U5VZz-0006Ie-BD
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 06:12:27 +0000
Received: from [85.158.139.211:27009] by server-6.bemta-5.messagelabs.com id
	9B/C9-01489-ACE2B115; Wed, 13 Feb 2013 06:12:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360735945!20786283!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMTE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3422 invoked from network); 13 Feb 2013 06:12:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 06:12:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1401178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 06:12: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.297.1; Wed, 13 Feb 2013 06:12:25 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5VZw-0004Xw-SB;
	Wed, 13 Feb 2013 06:12:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5VZw-000578-Nz;
	Wed, 13 Feb 2013 06:12:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16159-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 06:12:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16159: 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 16159 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16159/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 15449
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15449

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  cb92e40d8681
baseline version:
 xen                  130446135528

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <Ian.Campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=cb92e40d8681
+ . 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 cb92e40d8681
+ branch=xen-4.1-testing
+ revision=cb92e40d8681
+ . 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/hg/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 cb92e40d8681 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 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 Wed Feb 13 06:26:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 06:26: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 1U5VnG-0006Ua-H2; Wed, 13 Feb 2013 06:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U5Nai-00072l-Va
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 21:40:41 +0000
Received: from [85.158.143.35:32492] by server-3.bemta-4.messagelabs.com id
	FF/4B-08920-7D6BA115; Tue, 12 Feb 2013 21:40:39 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360705236!10293697!1
X-Originating-IP: [209.85.216.170]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2478 invoked from network); 12 Feb 2013 21:40:37 -0000
Received: from mail-qc0-f170.google.com (HELO mail-qc0-f170.google.com)
	(209.85.216.170)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 21:40:37 -0000
Received: by mail-qc0-f170.google.com with SMTP id d42so209602qca.1
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 13:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=wBzcU68sFWQk54JCumoeNZ6VgjMb3VdOpLwrQ2L3A7E=;
	b=nalhFOHTzSnxVoXZiVQvYGWPqsL4v6qj08hLJ3d2oVYzuZnfrJi2EHHqBMl1sboNSu
	vAfNx7xPC5MEUaVker912uTALIEO5J2sEZCzTVXEiDlXGhseewbGB+zdJzV8+bOzIpSN
	qhtAPoRo5XRNUBFJxT/tlFpnKmkr0nLIabi9G0XDdGO47WIThszWSf4IttuLF+u3TZPN
	yerYyDVWPEPp5JClU8ZWRZcWllNghl+6zrFJCG1KpsMtqXEsFMy1qqhgQCoUn3w6wFoG
	+eeiothzKLfYrCkRtNn7ZH5MhUlVVqu0lWfS4m7XdR+kNpkdEkVq8f2mHrWHzfhwjrDL
	gt7Q==
MIME-Version: 1.0
X-Received: by 10.229.111.150 with SMTP id s22mr1748359qcp.137.1360705232588; 
	Tue, 12 Feb 2013 13:40:32 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Tue, 12 Feb 2013 13:40:32 -0800 (PST)
In-Reply-To: <20130212200203.GR3016@phenom.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
Date: Tue, 12 Feb 2013 22:40:32 +0100
Message-ID: <CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Wed, 13 Feb 2013 06:26:08 +0000
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============1654250809352848147=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1654250809352848147==
Content-Type: multipart/alternative; boundary=00235447139c084edc04d58de0f0

--00235447139c084edc04d58de0f0
Content-Type: text/plain; charset=ISO-8859-1

xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
ok. Unfortunately resume from S3 still doesn't work.






2013/2/12 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> On Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wrote:
> > I apologize for the patching confusion. I applied Konrad's acpi-s3 patch
> to
> > linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
> > dom0_vcpus_pin to xen kernel line in bootloader but still I cannot
> modprobe
> > acpi_cpufreq and S3 sleep resume still not working.
>
> The module is xen-acpi-processor and you should see whether it works by
> running 'xenpm get-cpufreq-para'. If you get values then it worked.
>
> >
> > How can I debug it?
> > Thanks.
> >
> >
> > 2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>
> >
> > > On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> > > <tomasz.wroblewski@citrix.com> wrote:
> > > >
> > > >> Hm, that is suspect. There should not be any cpuidle_register?
> Perhaps
> > > >> you are .. ah yes, you are hitting a bug that should be in the
> stable
> > > >> tree fix.
> > > >>
> > > >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> > > >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> > > >>
> > > >>
> > > >
> > > > Thanks Konrad. I've tried your patches, and whilst I have not seen
> this
> > > > crash in cpuidle_register anymore, the others are still present (in
> > > > build_schedule_domains for example).
> > > >
> > >
> > > That looks familiar too. I think it got fixed in the upstream kernel
> > > and it was a generic bug - but I can't recall which commit it was.
> > >
> > > > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on
> xen
> > > > commandline stops both the xen scheduler and dom0 kernel crashing
> and all
> > > > works fine - made dozens of succesfull s3 attempts. Was wondering if
> you
> > > > guys had any thoughts on this? Is the dom0 kernel even supposed to
> cope
> > > > during s3 in non dom0 vcpu pin case?
> > > >
> > > No that is something new. Is this only an issue on Intel boxes but not
> AMD?
> > >
>

--00235447139c084edc04d58de0f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>xen-acpi-processor module is loaded and xenpm ge=
t-cpufreq-para seems to be ok. Unfortunately resume from S3 still doesn&#39=
;t work.<br><br></div><br></div><br><div><br></div></div><div class=3D"gmai=
l_extra">
<br><br><div class=3D"gmail_quote">2013/2/12 Konrad Rzeszutek Wilk <span di=
r=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@oracle.com" target=3D"_blank">k=
onrad.wilk@oracle.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wro=
te:<br>
&gt; I apologize for the patching confusion. I applied Konrad&#39;s acpi-s3=
 patch to<br>
&gt; linux 3.7.5-1 and Ben&#39;s Xen patches to Xen 4.2.1-3 stable. I&#39;v=
e also put<br>
&gt; dom0_vcpus_pin to xen kernel line in bootloader but still I cannot mod=
probe<br>
&gt; acpi_cpufreq and S3 sleep resume still not working.<br>
<br>
</div>The module is xen-acpi-processor and you should see whether it works =
by<br>
running &#39;xenpm get-cpufreq-para&#39;. If you get values then it worked.=
<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt; How can I debug it?<br>
&gt; Thanks.<br>
&gt;<br>
&gt;<br>
&gt; 2013/2/8 Konrad Rzeszutek Wilk &lt;<a href=3D"mailto:konrad@kernel.org=
">konrad@kernel.org</a>&gt;<br>
&gt;<br>
&gt; &gt; On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski<br>
&gt; &gt; &lt;<a href=3D"mailto:tomasz.wroblewski@citrix.com">tomasz.wroble=
wski@citrix.com</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; Hm, that is suspect. There should not be any cpuidle_reg=
ister? Perhaps<br>
&gt; &gt; &gt;&gt; you are .. ah yes, you are hitting a bug that should be =
in the stable<br>
&gt; &gt; &gt;&gt; tree fix.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Here is the git commit b88a634a903d9670aa5f2f785aa890628=
ce0dece and<br>
&gt; &gt; &gt;&gt; 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks Konrad. I&#39;ve tried your patches, and whilst I hav=
e not seen this<br>
&gt; &gt; &gt; crash in cpuidle_register anymore, the others are still pres=
ent (in<br>
&gt; &gt; &gt; build_schedule_domains for example).<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; That looks familiar too. I think it got fixed in the upstream ker=
nel<br>
&gt; &gt; and it was a generic bug - but I can&#39;t recall which commit it=
 was.<br>
&gt; &gt;<br>
&gt; &gt; &gt; I&#39;ve stumbled on a bit of interesting info - using dom0_=
vcpus_pin on xen<br>
&gt; &gt; &gt; commandline stops both the xen scheduler and dom0 kernel cra=
shing and all<br>
&gt; &gt; &gt; works fine - made dozens of succesfull s3 attempts. Was wond=
ering if you<br>
&gt; &gt; &gt; guys had any thoughts on this? Is the dom0 kernel even suppo=
sed to cope<br>
&gt; &gt; &gt; during s3 in non dom0 vcpu pin case?<br>
&gt; &gt; &gt;<br>
&gt; &gt; No that is something new. Is this only an issue on Intel boxes bu=
t not AMD?<br>
&gt; &gt;<br>
</div></div></blockquote></div><br></div>

--00235447139c084edc04d58de0f0--


--===============1654250809352848147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1654250809352848147==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 06:26:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 06:26: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 1U5VnG-0006Ua-H2; Wed, 13 Feb 2013 06:26:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U5Nai-00072l-Va
	for xen-devel@lists.xen.org; Tue, 12 Feb 2013 21:40:41 +0000
Received: from [85.158.143.35:32492] by server-3.bemta-4.messagelabs.com id
	FF/4B-08920-7D6BA115; Tue, 12 Feb 2013 21:40:39 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360705236!10293697!1
X-Originating-IP: [209.85.216.170]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2478 invoked from network); 12 Feb 2013 21:40:37 -0000
Received: from mail-qc0-f170.google.com (HELO mail-qc0-f170.google.com)
	(209.85.216.170)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Feb 2013 21:40:37 -0000
Received: by mail-qc0-f170.google.com with SMTP id d42so209602qca.1
	for <xen-devel@lists.xen.org>; Tue, 12 Feb 2013 13:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=wBzcU68sFWQk54JCumoeNZ6VgjMb3VdOpLwrQ2L3A7E=;
	b=nalhFOHTzSnxVoXZiVQvYGWPqsL4v6qj08hLJ3d2oVYzuZnfrJi2EHHqBMl1sboNSu
	vAfNx7xPC5MEUaVker912uTALIEO5J2sEZCzTVXEiDlXGhseewbGB+zdJzV8+bOzIpSN
	qhtAPoRo5XRNUBFJxT/tlFpnKmkr0nLIabi9G0XDdGO47WIThszWSf4IttuLF+u3TZPN
	yerYyDVWPEPp5JClU8ZWRZcWllNghl+6zrFJCG1KpsMtqXEsFMy1qqhgQCoUn3w6wFoG
	+eeiothzKLfYrCkRtNn7ZH5MhUlVVqu0lWfS4m7XdR+kNpkdEkVq8f2mHrWHzfhwjrDL
	gt7Q==
MIME-Version: 1.0
X-Received: by 10.229.111.150 with SMTP id s22mr1748359qcp.137.1360705232588; 
	Tue, 12 Feb 2013 13:40:32 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Tue, 12 Feb 2013 13:40:32 -0800 (PST)
In-Reply-To: <20130212200203.GR3016@phenom.dumpdata.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
Date: Tue, 12 Feb 2013 22:40:32 +0100
Message-ID: <CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Wed, 13 Feb 2013 06:26:08 +0000
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============1654250809352848147=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1654250809352848147==
Content-Type: multipart/alternative; boundary=00235447139c084edc04d58de0f0

--00235447139c084edc04d58de0f0
Content-Type: text/plain; charset=ISO-8859-1

xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
ok. Unfortunately resume from S3 still doesn't work.






2013/2/12 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> On Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wrote:
> > I apologize for the patching confusion. I applied Konrad's acpi-s3 patch
> to
> > linux 3.7.5-1 and Ben's Xen patches to Xen 4.2.1-3 stable. I've also put
> > dom0_vcpus_pin to xen kernel line in bootloader but still I cannot
> modprobe
> > acpi_cpufreq and S3 sleep resume still not working.
>
> The module is xen-acpi-processor and you should see whether it works by
> running 'xenpm get-cpufreq-para'. If you get values then it worked.
>
> >
> > How can I debug it?
> > Thanks.
> >
> >
> > 2013/2/8 Konrad Rzeszutek Wilk <konrad@kernel.org>
> >
> > > On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski
> > > <tomasz.wroblewski@citrix.com> wrote:
> > > >
> > > >> Hm, that is suspect. There should not be any cpuidle_register?
> Perhaps
> > > >> you are .. ah yes, you are hitting a bug that should be in the
> stable
> > > >> tree fix.
> > > >>
> > > >> Here is the git commit b88a634a903d9670aa5f2f785aa890628ce0dece and
> > > >> 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0
> > > >>
> > > >>
> > > >
> > > > Thanks Konrad. I've tried your patches, and whilst I have not seen
> this
> > > > crash in cpuidle_register anymore, the others are still present (in
> > > > build_schedule_domains for example).
> > > >
> > >
> > > That looks familiar too. I think it got fixed in the upstream kernel
> > > and it was a generic bug - but I can't recall which commit it was.
> > >
> > > > I've stumbled on a bit of interesting info - using dom0_vcpus_pin on
> xen
> > > > commandline stops both the xen scheduler and dom0 kernel crashing
> and all
> > > > works fine - made dozens of succesfull s3 attempts. Was wondering if
> you
> > > > guys had any thoughts on this? Is the dom0 kernel even supposed to
> cope
> > > > during s3 in non dom0 vcpu pin case?
> > > >
> > > No that is something new. Is this only an issue on Intel boxes but not
> AMD?
> > >
>

--00235447139c084edc04d58de0f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>xen-acpi-processor module is loaded and xenpm ge=
t-cpufreq-para seems to be ok. Unfortunately resume from S3 still doesn&#39=
;t work.<br><br></div><br></div><br><div><br></div></div><div class=3D"gmai=
l_extra">
<br><br><div class=3D"gmail_quote">2013/2/12 Konrad Rzeszutek Wilk <span di=
r=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@oracle.com" target=3D"_blank">k=
onrad.wilk@oracle.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Sat, Feb 09, 2013 at 06:21:34PM +0100, Milan opath wro=
te:<br>
&gt; I apologize for the patching confusion. I applied Konrad&#39;s acpi-s3=
 patch to<br>
&gt; linux 3.7.5-1 and Ben&#39;s Xen patches to Xen 4.2.1-3 stable. I&#39;v=
e also put<br>
&gt; dom0_vcpus_pin to xen kernel line in bootloader but still I cannot mod=
probe<br>
&gt; acpi_cpufreq and S3 sleep resume still not working.<br>
<br>
</div>The module is xen-acpi-processor and you should see whether it works =
by<br>
running &#39;xenpm get-cpufreq-para&#39;. If you get values then it worked.=
<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt; How can I debug it?<br>
&gt; Thanks.<br>
&gt;<br>
&gt;<br>
&gt; 2013/2/8 Konrad Rzeszutek Wilk &lt;<a href=3D"mailto:konrad@kernel.org=
">konrad@kernel.org</a>&gt;<br>
&gt;<br>
&gt; &gt; On Fri, Feb 8, 2013 at 5:11 AM, Tomasz Wroblewski<br>
&gt; &gt; &lt;<a href=3D"mailto:tomasz.wroblewski@citrix.com">tomasz.wroble=
wski@citrix.com</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; Hm, that is suspect. There should not be any cpuidle_reg=
ister? Perhaps<br>
&gt; &gt; &gt;&gt; you are .. ah yes, you are hitting a bug that should be =
in the stable<br>
&gt; &gt; &gt;&gt; tree fix.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; Here is the git commit b88a634a903d9670aa5f2f785aa890628=
ce0dece and<br>
&gt; &gt; &gt;&gt; 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks Konrad. I&#39;ve tried your patches, and whilst I hav=
e not seen this<br>
&gt; &gt; &gt; crash in cpuidle_register anymore, the others are still pres=
ent (in<br>
&gt; &gt; &gt; build_schedule_domains for example).<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; That looks familiar too. I think it got fixed in the upstream ker=
nel<br>
&gt; &gt; and it was a generic bug - but I can&#39;t recall which commit it=
 was.<br>
&gt; &gt;<br>
&gt; &gt; &gt; I&#39;ve stumbled on a bit of interesting info - using dom0_=
vcpus_pin on xen<br>
&gt; &gt; &gt; commandline stops both the xen scheduler and dom0 kernel cra=
shing and all<br>
&gt; &gt; &gt; works fine - made dozens of succesfull s3 attempts. Was wond=
ering if you<br>
&gt; &gt; &gt; guys had any thoughts on this? Is the dom0 kernel even suppo=
sed to cope<br>
&gt; &gt; &gt; during s3 in non dom0 vcpu pin case?<br>
&gt; &gt; &gt;<br>
&gt; &gt; No that is something new. Is this only an issue on Intel boxes bu=
t not AMD?<br>
&gt; &gt;<br>
</div></div></blockquote></div><br></div>

--00235447139c084edc04d58de0f0--


--===============1654250809352848147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1654250809352848147==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 07:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 07:32: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 1U5Wov-00078j-Ej; Wed, 13 Feb 2013 07:31: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 1U5Wot-00078e-Cy
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 07:31:55 +0000
Received: from [85.158.143.99:47644] by server-2.bemta-4.messagelabs.com id
	EB/B4-01597-A614B115; Wed, 13 Feb 2013 07:31:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360740713!17522309!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4226 invoked from network); 13 Feb 2013 07:31:53 -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 Feb 2013 07:31:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 07:31:52 +0000
Message-Id: <511B4F7602000078000BDE2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 07:31:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-15450-mainreport@xen.org>
	<511A19D202000078000BDA3D@nat28.tlf.novell.com>
	<20762.38108.802123.636018@mariner.uk.xensource.com>
In-Reply-To: <20762.38108.802123.636018@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 15450: regressions - 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 12.02.13 at 20:15, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> We need to decide what to do with xen-4.2-testing.hg non-staging.  I
> would be tempted to rewind it, if that isn't a horrible thing to do.
> It's not as bad with hg as it is with git: aiui if you pull from a
> rewound repo, nothing bad happens.
> 
> I think this can be done with hg strip.

Question is - do we need to do anything here at all? With IanC
apparently already having found the reason for the regression,
can't we just get that committed to -unstable, and once pushed
there put it here (and on 4.1-testing) too?

I would be more concerned about the tree's state when close
to a release, but we still have about two weeks until we ought
to cut -rc1 there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 07:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 07:32: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 1U5Wov-00078j-Ej; Wed, 13 Feb 2013 07:31: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 1U5Wot-00078e-Cy
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 07:31:55 +0000
Received: from [85.158.143.99:47644] by server-2.bemta-4.messagelabs.com id
	EB/B4-01597-A614B115; Wed, 13 Feb 2013 07:31:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360740713!17522309!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4226 invoked from network); 13 Feb 2013 07:31:53 -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 Feb 2013 07:31:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 07:31:52 +0000
Message-Id: <511B4F7602000078000BDE2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 07:31:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-15450-mainreport@xen.org>
	<511A19D202000078000BDA3D@nat28.tlf.novell.com>
	<20762.38108.802123.636018@mariner.uk.xensource.com>
In-Reply-To: <20762.38108.802123.636018@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 15450: regressions - 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 12.02.13 at 20:15, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> We need to decide what to do with xen-4.2-testing.hg non-staging.  I
> would be tempted to rewind it, if that isn't a horrible thing to do.
> It's not as bad with hg as it is with git: aiui if you pull from a
> rewound repo, nothing bad happens.
> 
> I think this can be done with hg strip.

Question is - do we need to do anything here at all? With IanC
apparently already having found the reason for the regression,
can't we just get that committed to -unstable, and once pushed
there put it here (and on 4.1-testing) too?

I would be more concerned about the tree's state when close
to a release, but we still have about two weeks until we ought
to cut -rc1 there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:05:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08: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 1U5XLJ-0007qZ-LW; Wed, 13 Feb 2013 08:05: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 1U5XLH-0007qU-QN
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:05:23 +0000
Received: from [85.158.138.51:7899] by server-14.bemta-3.messagelabs.com id
	F7/78-23533-E394B115; Wed, 13 Feb 2013 08:05:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360742717!21001844!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11911 invoked from network); 13 Feb 2013 08:05:17 -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; 13 Feb 2013 08:05:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:05:16 +0000
Message-Id: <511B574902000078000BDE41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:05:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
In-Reply-To: <CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 19:40, povder <povder@gmail.com> wrote:
> I disabled id BIOS IDE interface that was causing problems and system
> boots fine. Thanks for your help!
> 
> I just wonder if it's a bug in BIOS or in Xen. If it's ASUS bug I
> would like to report bug to them.

Quite obviously it's a BIOS bug, failing to cover all devices in the
IVRS table. Whether we can do any better than crashing in that
case is a different question - I wonder how native Linux with
IOMMU enabled does in that situation...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:05:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08: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 1U5XLJ-0007qZ-LW; Wed, 13 Feb 2013 08:05: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 1U5XLH-0007qU-QN
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:05:23 +0000
Received: from [85.158.138.51:7899] by server-14.bemta-3.messagelabs.com id
	F7/78-23533-E394B115; Wed, 13 Feb 2013 08:05:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360742717!21001844!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11911 invoked from network); 13 Feb 2013 08:05:17 -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; 13 Feb 2013 08:05:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:05:16 +0000
Message-Id: <511B574902000078000BDE41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:05:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
In-Reply-To: <CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 12.02.13 at 19:40, povder <povder@gmail.com> wrote:
> I disabled id BIOS IDE interface that was causing problems and system
> boots fine. Thanks for your help!
> 
> I just wonder if it's a bug in BIOS or in Xen. If it's ASUS bug I
> would like to report bug to them.

Quite obviously it's a BIOS bug, failing to cover all devices in the
IVRS table. Whether we can do any better than crashing in that
case is a different question - I wonder how native Linux with
IOMMU enabled does in that situation...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:25:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:25: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 1U5Xdq-000847-Ju; Wed, 13 Feb 2013 08:24:34 +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 1U5Xdp-000842-1b
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 08:24:33 +0000
Received: from [85.158.139.211:3177] by server-7.bemta-5.messagelabs.com id
	BE/2E-11121-EBD4B115; Wed, 13 Feb 2013 08:24:30 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360743866!22260368!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMTE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16058 invoked from network); 13 Feb 2013 08:24:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 08:24:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1404251"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 08:24:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 13 Feb 2013
	08:24:12 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 13 Feb 2013 08:24:11 +0000
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GA=
Message-ID: <291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
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] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 8 doesn't actually shut down when you tell it to... It terminates all sessions apart from 0 (where services live) and then hibernates, so 'shutdown' is actually a lot more complex and error prone than it was before.

  Paul 

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of James Harper
> Sent: 12 February 2013 22:19
> To: Andreas Kinzler; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] State of GPLPV and Windows 8
> 
> >
> > What is the state of GPLPV and Windows 8? I am currently running tests
> > with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look
> > good. There seems to be a problem with shutdown/reboot where
> Windows
> > hangs somewhat and displays a warning about improper shutdown on next
> > reboot.
> >
> 
> I have only tested with Windows 2012 but it shouldn't be any different to 8.
> My testing was pretty much limited to 'does it boot' testing, but I don't recall
> having any problems with shutdown or anything.
> 
> Are you interested in trying the very latest version? I've been doing a fairly
> major update in the way the child devices talk to the bus driver and it is now
> at a point where everything should be working but I haven't done a lot of
> testing yet.
> 
> 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 Wed Feb 13 08:25:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:25: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 1U5Xdq-000847-Ju; Wed, 13 Feb 2013 08:24:34 +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 1U5Xdp-000842-1b
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 08:24:33 +0000
Received: from [85.158.139.211:3177] by server-7.bemta-5.messagelabs.com id
	BE/2E-11121-EBD4B115; Wed, 13 Feb 2013 08:24:30 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360743866!22260368!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMTE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16058 invoked from network); 13 Feb 2013 08:24:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 08:24:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1404251"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 08:24:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 13 Feb 2013
	08:24:12 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 13 Feb 2013 08:24:11 +0000
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GA=
Message-ID: <291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
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] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 8 doesn't actually shut down when you tell it to... It terminates all sessions apart from 0 (where services live) and then hibernates, so 'shutdown' is actually a lot more complex and error prone than it was before.

  Paul 

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of James Harper
> Sent: 12 February 2013 22:19
> To: Andreas Kinzler; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] State of GPLPV and Windows 8
> 
> >
> > What is the state of GPLPV and Windows 8? I am currently running tests
> > with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look
> > good. There seems to be a problem with shutdown/reboot where
> Windows
> > hangs somewhat and displays a warning about improper shutdown on next
> > reboot.
> >
> 
> I have only tested with Windows 2012 but it shouldn't be any different to 8.
> My testing was pretty much limited to 'does it boot' testing, but I don't recall
> having any problems with shutdown or anything.
> 
> Are you interested in trying the very latest version? I've been doing a fairly
> major update in the way the child devices talk to the bus driver and it is now
> at a point where everything should be working but I haven't done a lot of
> testing yet.
> 
> 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 Wed Feb 13 08:25:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:25: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 1U5Xdx-00084Q-2S; Wed, 13 Feb 2013 08:24:41 +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 1U5Xdv-00084K-Sz
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:24:40 +0000
Received: from [85.158.137.99:34649] by server-6.bemta-3.messagelabs.com id
	A1/C4-29959-2CD4B115; Wed, 13 Feb 2013 08:24:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360743873!17797629!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29297 invoked from network); 13 Feb 2013 08:24:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 08:24:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:24:33 +0000
Message-Id: <511B5BCE02000078000BDE57@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:24:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <04647143-a56e-44ef-b3a5-2bf98d704802@default>
In-Reply-To: <04647143-a56e-44ef-b3a5-2bf98d704802@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: povder@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 02:33, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> I am wondering whether such cases (undeclared devices in IVRS) should cause 
> a panic or disabling of IOMMU. This may be a more generic case of Jan's earlier 
> patch for dealing with missing IOAPIC. Not sure whether it would be possible 
> to "unwind" IOMMU at this point though.

I doubt it - this would likely cause further problems down the road.

Instead, with us doing a bus scan anyway (as of 4.1), we could
detect the problem much earlier (and only bug on devices that we
don't find but Dom0 does - in particular, I'm wondering how SR-IOV
VFs would get dealt with here).

Furthermore I wonder whether in the single IOMMU case we
couldn't deal with this on the same basis as is being done (sort of
unintendedly) for the IO-APIC case: The single IOMMU in the
system _must_ be the one responsible for any device not reported
by the firmware. That would deal with povder's case, and
experience tells us that more complex (read: expensive) systems
tend to have less ACPI table flaws (i.e. wouldn't suffer from not
being covered by such a workaround).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:25:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:25: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 1U5Xdx-00084Q-2S; Wed, 13 Feb 2013 08:24:41 +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 1U5Xdv-00084K-Sz
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:24:40 +0000
Received: from [85.158.137.99:34649] by server-6.bemta-3.messagelabs.com id
	A1/C4-29959-2CD4B115; Wed, 13 Feb 2013 08:24:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360743873!17797629!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29297 invoked from network); 13 Feb 2013 08:24:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 08:24:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:24:33 +0000
Message-Id: <511B5BCE02000078000BDE57@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:24:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <04647143-a56e-44ef-b3a5-2bf98d704802@default>
In-Reply-To: <04647143-a56e-44ef-b3a5-2bf98d704802@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: povder@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 02:33, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> I am wondering whether such cases (undeclared devices in IVRS) should cause 
> a panic or disabling of IOMMU. This may be a more generic case of Jan's earlier 
> patch for dealing with missing IOAPIC. Not sure whether it would be possible 
> to "unwind" IOMMU at this point though.

I doubt it - this would likely cause further problems down the road.

Instead, with us doing a bus scan anyway (as of 4.1), we could
detect the problem much earlier (and only bug on devices that we
don't find but Dom0 does - in particular, I'm wondering how SR-IOV
VFs would get dealt with here).

Furthermore I wonder whether in the single IOMMU case we
couldn't deal with this on the same basis as is being done (sort of
unintendedly) for the IO-APIC case: The single IOMMU in the
system _must_ be the one responsible for any device not reported
by the firmware. That would deal with povder's case, and
experience tells us that more complex (read: expensive) systems
tend to have less ACPI table flaws (i.e. wouldn't suffer from not
being covered by such a workaround).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:27:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:27: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 1U5Xgq-0008Gu-Pe; Wed, 13 Feb 2013 08:27:40 +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 1U5Xgo-0008Gj-Mf
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:27:38 +0000
Received: from [85.158.137.99:11665] by server-1.bemta-3.messagelabs.com id
	9E/84-08955-97E4B115; Wed, 13 Feb 2013 08:27:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360744056!12807814!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23101 invoked from network); 13 Feb 2013 08:27:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 08:27:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:27:36 +0000
Message-Id: <511B5C8402000078000BDE5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:27:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Milan opath" <milan.opath@gmail.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
	<20130212215655.GA18127@phenom.dumpdata.com>
In-Reply-To: <20130212215655.GA18127@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 12.02.13 at 22:56, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Tue, Feb 12, 2013 at 10:40:32PM +0100, Milan opath wrote:
>> xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
>> ok. Unfortunately resume from S3 still doesn't work.
> 
> So then the process of elimination starts. Try doing it without having Xorg 
> or any
> KMS drivers running (so text-console). Then also try without serial output.
> And also as somebody suggested with dom0_pin_vcpus arguments.

Without, you mean? Iirc Ben's findings suggested that there are
problems when this option is used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:27:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:27: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 1U5Xgq-0008Gu-Pe; Wed, 13 Feb 2013 08:27:40 +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 1U5Xgo-0008Gj-Mf
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:27:38 +0000
Received: from [85.158.137.99:11665] by server-1.bemta-3.messagelabs.com id
	9E/84-08955-97E4B115; Wed, 13 Feb 2013 08:27:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360744056!12807814!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23101 invoked from network); 13 Feb 2013 08:27:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 08:27:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:27:36 +0000
Message-Id: <511B5C8402000078000BDE5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:27:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Milan opath" <milan.opath@gmail.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
	<20130212215655.GA18127@phenom.dumpdata.com>
In-Reply-To: <20130212215655.GA18127@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 12.02.13 at 22:56, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Tue, Feb 12, 2013 at 10:40:32PM +0100, Milan opath wrote:
>> xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
>> ok. Unfortunately resume from S3 still doesn't work.
> 
> So then the process of elimination starts. Try doing it without having Xorg 
> or any
> KMS drivers running (so text-console). Then also try without serial output.
> And also as somebody suggested with dom0_pin_vcpus arguments.

Without, you mean? Iirc Ben's findings suggested that there are
problems when this option is used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:29:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:29: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 1U5Xhv-0008QE-4e; Wed, 13 Feb 2013 08:28:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5Xht-0008Pk-2q
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:28:45 +0000
Received: from [85.158.139.211:3301] by server-7.bemta-5.messagelabs.com id
	32/E3-11121-CBE4B115; Wed, 13 Feb 2013 08:28:44 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360744122!22236150!1
X-Originating-IP: [209.85.210.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32460 invoked from network); 13 Feb 2013 08:28:43 -0000
Received: from mail-ia0-f179.google.com (HELO mail-ia0-f179.google.com)
	(209.85.210.179)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 08:28:43 -0000
Received: by mail-ia0-f179.google.com with SMTP id x24so970425iak.24
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 00:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=JyekCePjrvuR+VPxpIxrl4pcag2SzNZBKgURkUJHWZY=;
	b=ivswSt9ABtkEAnHCxj0rwrNOJtvl4JG/nIpkD3iG5elH/44daRRfl14Zc6sot+u83y
	LjHnC6Sao3/avMGXwXEOmdyPuLeL2OSCJK+AcUHBT/0rFbhx7TliBWfkLBQloNdbBQ0b
	yAoiOB7jjhYV3yCj4HqR4M3uUQ2+OJxXmzXQXDq49XNXEf4p1Ha2lFmmVyT0DBES5ipN
	RyR+sWggNCov6jdGlggY1efji77bnVSaSDszU+k3qx1cks9ipjIgn3shSESl+H2WawXr
	xlIenTggdDEs6VElvCELC3UVHjlYWj2+pjVkFJW6+2Q1xJVGHxqW98GRPyGRxBPelW42
	bxtw==
X-Received: by 10.50.214.67 with SMTP id ny3mr9414367igc.13.1360744121974;
	Wed, 13 Feb 2013 00:28:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Wed, 13 Feb 2013 00:28:21 -0800 (PST)
In-Reply-To: <511B574902000078000BDE41@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Wed, 13 Feb 2013 09:28:21 +0100
Message-ID: <CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/13 Jan Beulich <JBeulich@suse.com>:
> I wonder how native Linux with
> IOMMU enabled does in that situation...
>

I can try it today if you want. What kernel option should i use to
enable iommu? "iommu=force"?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:29:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:29: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 1U5Xhv-0008QE-4e; Wed, 13 Feb 2013 08:28:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5Xht-0008Pk-2q
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:28:45 +0000
Received: from [85.158.139.211:3301] by server-7.bemta-5.messagelabs.com id
	32/E3-11121-CBE4B115; Wed, 13 Feb 2013 08:28:44 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360744122!22236150!1
X-Originating-IP: [209.85.210.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32460 invoked from network); 13 Feb 2013 08:28:43 -0000
Received: from mail-ia0-f179.google.com (HELO mail-ia0-f179.google.com)
	(209.85.210.179)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 08:28:43 -0000
Received: by mail-ia0-f179.google.com with SMTP id x24so970425iak.24
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 00:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=JyekCePjrvuR+VPxpIxrl4pcag2SzNZBKgURkUJHWZY=;
	b=ivswSt9ABtkEAnHCxj0rwrNOJtvl4JG/nIpkD3iG5elH/44daRRfl14Zc6sot+u83y
	LjHnC6Sao3/avMGXwXEOmdyPuLeL2OSCJK+AcUHBT/0rFbhx7TliBWfkLBQloNdbBQ0b
	yAoiOB7jjhYV3yCj4HqR4M3uUQ2+OJxXmzXQXDq49XNXEf4p1Ha2lFmmVyT0DBES5ipN
	RyR+sWggNCov6jdGlggY1efji77bnVSaSDszU+k3qx1cks9ipjIgn3shSESl+H2WawXr
	xlIenTggdDEs6VElvCELC3UVHjlYWj2+pjVkFJW6+2Q1xJVGHxqW98GRPyGRxBPelW42
	bxtw==
X-Received: by 10.50.214.67 with SMTP id ny3mr9414367igc.13.1360744121974;
	Wed, 13 Feb 2013 00:28:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.82.72 with HTTP; Wed, 13 Feb 2013 00:28:21 -0800 (PST)
In-Reply-To: <511B574902000078000BDE41@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Wed, 13 Feb 2013 09:28:21 +0100
Message-ID: <CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

2013/2/13 Jan Beulich <JBeulich@suse.com>:
> I wonder how native Linux with
> IOMMU enabled does in that situation...
>

I can try it today if you want. What kernel option should i use to
enable iommu? "iommu=force"?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:37:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:37: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 1U5XqU-0000fN-0V; Wed, 13 Feb 2013 08:37:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5XqS-0000fC-78
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:37:36 +0000
Received: from [85.158.143.99:41167] by server-1.bemta-4.messagelabs.com id
	88/7B-08839-FC05B115; Wed, 13 Feb 2013 08:37:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360744654!17530659!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27064 invoked from network); 13 Feb 2013 08:37:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 08:37:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 16301C56195;
	Wed, 13 Feb 2013 08:37:22 +0000 (GMT)
Date: Wed, 13 Feb 2013 08:37:21 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <D66675BF9FE63A7F8D0FE7D3@nimrod.local>
In-Reply-To: <20762.25460.618127.856037@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
	<20762.25460.618127.856037@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

Firstly, thanks for the review. I think the issue of JSON_ERROR's removal
you thought was OK in the end because it was from the _internal file

--On 12 February 2013 15:44:52 +0000 Ian Jackson 
<Ian.Jackson@eu.citrix.com> wrote:

> Alex Bligh writes ("[Xen-devel] [PATCH 10/11] libxl: Allow migration with 
qemu-xen."):
> > Backport of xen-unstable patch:
> > : HG changeset patch
> > : User Anthony PERARD <anthony.perard@citrix.com>
> > : Date 1349693136 -3600
> > : Node ID 0995890022391682a2499a202c3c8608e1d3780a
> > : Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369
>
> This backport is fine but needs to come at the end of the series, I
> think ?

I can reorder patch 11 so it precedes patch 10 if you want. It's only
there as I found the bug in patch 11 later. Tell me if you want me to
do this.

If I'm right re JSON_ERROR, the only substantive issue is the following:

> I've had another thought: what if this series is applied, including
> this final patch, but the result is used with an older qemu which
> hasn't had the relevant features added ?

Does that ever happen? By which I mean does that ever happen in a manner
that is permitted?

I thought if you were using Xen 4.2 you pretty much had to be using either
a qemu upstream compiled specifically for Xen and thus distributed with
it, so you'd expect to upgrade it, or you'd be using one of the newer
upstream releases which has all this stuff in anyway. Was there some
window where true upstream qemu (as opposed to the one carried by Xen) had
a release version which carried Xen 4.2 support and qemu DM, but not
live migrate?

> AFAICT the result would probably be a failure to execute the logdirty
> switch.  Is that error sufficiently clean ?

This might depend on our policy of using mixed versions of qemu and
xen. If a policy of "either use the version of qemu included in Xen
or use a version greater than N.N.N" is ok, then I think the answer is
yes.

If not, then I'm not sure. Does Xen currently check the version of
qemu somehow?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:37:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:37: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 1U5XqU-0000fN-0V; Wed, 13 Feb 2013 08:37:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5XqS-0000fC-78
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:37:36 +0000
Received: from [85.158.143.99:41167] by server-1.bemta-4.messagelabs.com id
	88/7B-08839-FC05B115; Wed, 13 Feb 2013 08:37:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360744654!17530659!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27064 invoked from network); 13 Feb 2013 08:37:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 08:37:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 16301C56195;
	Wed, 13 Feb 2013 08:37:22 +0000 (GMT)
Date: Wed, 13 Feb 2013 08:37:21 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <D66675BF9FE63A7F8D0FE7D3@nimrod.local>
In-Reply-To: <20762.25460.618127.856037@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
	<20762.25460.618127.856037@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

Firstly, thanks for the review. I think the issue of JSON_ERROR's removal
you thought was OK in the end because it was from the _internal file

--On 12 February 2013 15:44:52 +0000 Ian Jackson 
<Ian.Jackson@eu.citrix.com> wrote:

> Alex Bligh writes ("[Xen-devel] [PATCH 10/11] libxl: Allow migration with 
qemu-xen."):
> > Backport of xen-unstable patch:
> > : HG changeset patch
> > : User Anthony PERARD <anthony.perard@citrix.com>
> > : Date 1349693136 -3600
> > : Node ID 0995890022391682a2499a202c3c8608e1d3780a
> > : Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369
>
> This backport is fine but needs to come at the end of the series, I
> think ?

I can reorder patch 11 so it precedes patch 10 if you want. It's only
there as I found the bug in patch 11 later. Tell me if you want me to
do this.

If I'm right re JSON_ERROR, the only substantive issue is the following:

> I've had another thought: what if this series is applied, including
> this final patch, but the result is used with an older qemu which
> hasn't had the relevant features added ?

Does that ever happen? By which I mean does that ever happen in a manner
that is permitted?

I thought if you were using Xen 4.2 you pretty much had to be using either
a qemu upstream compiled specifically for Xen and thus distributed with
it, so you'd expect to upgrade it, or you'd be using one of the newer
upstream releases which has all this stuff in anyway. Was there some
window where true upstream qemu (as opposed to the one carried by Xen) had
a release version which carried Xen 4.2 support and qemu DM, but not
live migrate?

> AFAICT the result would probably be a failure to execute the logdirty
> switch.  Is that error sufficiently clean ?

This might depend on our policy of using mixed versions of qemu and
xen. If a policy of "either use the version of qemu included in Xen
or use a version greater than N.N.N" is ok, then I think the answer is
yes.

If not, then I'm not sure. Does Xen currently check the version of
qemu somehow?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:38:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:38: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 1U5Xqe-0000gF-EH; Wed, 13 Feb 2013 08:37:48 +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 1U5Xqd-0000g7-JG
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:37:47 +0000
Received: from [193.109.254.147:20532] by server-2.bemta-14.messagelabs.com id
	45/51-16277-AD05B115; Wed, 13 Feb 2013 08:37:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360744660!2352085!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27986 invoked from network); 13 Feb 2013 08:37:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 08:37:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:37:40 +0000
Message-Id: <511B5EE102000078000BDE8A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:37:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
In-Reply-To: <CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 09:28, povder <povder@gmail.com> wrote:
> 2013/2/13 Jan Beulich <JBeulich@suse.com>:
>> I wonder how native Linux with
>> IOMMU enabled does in that situation...
>>
> 
> I can try it today if you want. What kernel option should i use to
> enable iommu? "iommu=force"?

Looks like other than Intel's, AMD's IOMMU gets turned on by
default independent of any configuration settings. So providing
a native kernel boot log (at maximum log level) ought to suffice
(assuming of course you don't have any command line options
in place to _disable_ the IOMMU).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 08:38:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 08:38: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 1U5Xqe-0000gF-EH; Wed, 13 Feb 2013 08:37:48 +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 1U5Xqd-0000g7-JG
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 08:37:47 +0000
Received: from [193.109.254.147:20532] by server-2.bemta-14.messagelabs.com id
	45/51-16277-AD05B115; Wed, 13 Feb 2013 08:37:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360744660!2352085!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27986 invoked from network); 13 Feb 2013 08:37:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 08:37:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 08:37:40 +0000
Message-Id: <511B5EE102000078000BDE8A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 08:37:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
In-Reply-To: <CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 09:28, povder <povder@gmail.com> wrote:
> 2013/2/13 Jan Beulich <JBeulich@suse.com>:
>> I wonder how native Linux with
>> IOMMU enabled does in that situation...
>>
> 
> I can try it today if you want. What kernel option should i use to
> enable iommu? "iommu=force"?

Looks like other than Intel's, AMD's IOMMU gets turned on by
default independent of any configuration settings. So providing
a native kernel boot log (at maximum log level) ought to suffice
(assuming of course you don't have any command line options
in place to _disable_ the IOMMU).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 09:14:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 09:14: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 1U5YPq-0001Hl-L7; Wed, 13 Feb 2013 09:14: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 1U5YPo-0001Hg-Vl
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 09:14:09 +0000
Received: from [85.158.139.83:42578] by server-8.bemta-5.messagelabs.com id
	8B/C0-19075-0695B115; Wed, 13 Feb 2013 09:14:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360746835!31216443!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23889 invoked from network); 13 Feb 2013 09:13:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 09:13:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1405899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 09:13: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.297.1;
	Wed, 13 Feb 2013 09:13:55 +0000
Message-ID: <1360746833.20449.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 09:13:53 +0000
In-Reply-To: <20762.25320.467534.174911@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
	<1360683444.20449.192.camel@zakaz.uk.xensource.com>
	<20762.25320.467534.174911@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
 enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 15:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> > On Tue, 2013-02-12 at 15:32 +0000, Ian Jackson wrote:
> > > We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> > > needs to remain frozen.
> > 
> > This is a purely internal type, so no ABI implications.
> > 
> > Also the libxl ABI is not frozen, only the API. We can always change the
> > SONAME.
> 
> The ABI certainly needs to be frozen within a stable release.  I don't
> know if we document this anywhere but it seems like a fairly basic
> obvious requirement.

Ah, yes, true.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 09:14:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 09:14: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 1U5YPq-0001Hl-L7; Wed, 13 Feb 2013 09:14: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 1U5YPo-0001Hg-Vl
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 09:14:09 +0000
Received: from [85.158.139.83:42578] by server-8.bemta-5.messagelabs.com id
	8B/C0-19075-0695B115; Wed, 13 Feb 2013 09:14:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360746835!31216443!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23889 invoked from network); 13 Feb 2013 09:13:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 09:13:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1405899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 09:13: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.297.1;
	Wed, 13 Feb 2013 09:13:55 +0000
Message-ID: <1360746833.20449.203.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 09:13:53 +0000
In-Reply-To: <20762.25320.467534.174911@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-3-git-send-email-alex@alex.org.uk>
	<20762.24689.570182.129974@mariner.uk.xensource.com>
	<1360683444.20449.192.camel@zakaz.uk.xensource.com>
	<20762.25320.467534.174911@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from
 enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-12 at 15:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum."):
> > On Tue, 2013-02-12 at 15:32 +0000, Ian Jackson wrote:
> > > We shouldn't be introducing anything like this into Xen 4.2.  Its ABI
> > > needs to remain frozen.
> > 
> > This is a purely internal type, so no ABI implications.
> > 
> > Also the libxl ABI is not frozen, only the API. We can always change the
> > SONAME.
> 
> The ABI certainly needs to be frozen within a stable release.  I don't
> know if we document this anywhere but it seems like a fairly basic
> obvious requirement.

Ah, yes, true.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 09:43:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 09:43: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 1U5YrM-0001eC-DP; Wed, 13 Feb 2013 09:42: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 1U5YrL-0001e7-0u
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 09:42:35 +0000
Received: from [85.158.137.99:61252] by server-6.bemta-3.messagelabs.com id
	79/F5-29959-A006B115; Wed, 13 Feb 2013 09:42:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360748553!16538004!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8766 invoked from network); 13 Feb 2013 09:42:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 09:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1407331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 09:42: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.297.1;
	Wed, 13 Feb 2013 09:42:33 +0000
Message-ID: <1360748552.20449.211.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 13 Feb 2013 09:42:32 +0000
In-Reply-To: <511B4F7602000078000BDE2B@nat28.tlf.novell.com>
References: <osstest-15450-mainreport@xen.org>
	<511A19D202000078000BDA3D@nat28.tlf.novell.com>
	<20762.38108.802123.636018@mariner.uk.xensource.com>
	<511B4F7602000078000BDE2B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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-testing test] 15450: regressions - 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 Wed, 2013-02-13 at 07:31 +0000, Jan Beulich wrote:
> >>> On 12.02.13 at 20:15, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > We need to decide what to do with xen-4.2-testing.hg non-staging.  I
> > would be tempted to rewind it, if that isn't a horrible thing to do.
> > It's not as bad with hg as it is with git: aiui if you pull from a
> > rewound repo, nothing bad happens.
> > 
> > I think this can be done with hg strip.
> 
> Question is - do we need to do anything here at all? With IanC
> apparently already having found the reason for the regression,
> can't we just get that committed to -unstable, and once pushed
> there put it here (and on 4.1-testing) too?

I'd certainly be inclined to commit the fixes and only if they are not
sufficient think about messing with the trees.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 09:43:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 09:43: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 1U5YrM-0001eC-DP; Wed, 13 Feb 2013 09:42: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 1U5YrL-0001e7-0u
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 09:42:35 +0000
Received: from [85.158.137.99:61252] by server-6.bemta-3.messagelabs.com id
	79/F5-29959-A006B115; Wed, 13 Feb 2013 09:42:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360748553!16538004!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8766 invoked from network); 13 Feb 2013 09:42:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 09:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1407331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 09:42: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.297.1;
	Wed, 13 Feb 2013 09:42:33 +0000
Message-ID: <1360748552.20449.211.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 13 Feb 2013 09:42:32 +0000
In-Reply-To: <511B4F7602000078000BDE2B@nat28.tlf.novell.com>
References: <osstest-15450-mainreport@xen.org>
	<511A19D202000078000BDA3D@nat28.tlf.novell.com>
	<20762.38108.802123.636018@mariner.uk.xensource.com>
	<511B4F7602000078000BDE2B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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-testing test] 15450: regressions - 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 Wed, 2013-02-13 at 07:31 +0000, Jan Beulich wrote:
> >>> On 12.02.13 at 20:15, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > We need to decide what to do with xen-4.2-testing.hg non-staging.  I
> > would be tempted to rewind it, if that isn't a horrible thing to do.
> > It's not as bad with hg as it is with git: aiui if you pull from a
> > rewound repo, nothing bad happens.
> > 
> > I think this can be done with hg strip.
> 
> Question is - do we need to do anything here at all? With IanC
> apparently already having found the reason for the regression,
> can't we just get that committed to -unstable, and once pushed
> there put it here (and on 4.1-testing) too?

I'd certainly be inclined to commit the fixes and only if they are not
sufficient think about messing with the trees.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 09:43:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 09: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 1U5YsA-0001gb-RG; Wed, 13 Feb 2013 09:43: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 1U5YsA-0001gV-0N
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 09:43:26 +0000
Received: from [85.158.143.99:17713] by server-1.bemta-4.messagelabs.com id
	81/17-08839-D306B115; Wed, 13 Feb 2013 09:43:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360748603!17684972!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14795 invoked from network); 13 Feb 2013 09:43:24 -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;
	13 Feb 2013 09:43:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="6942417"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 09:43:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 04:43:22 -0500
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 1U5Ys6-0004Rf-EB;
	Wed, 13 Feb 2013 09:43:22 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 13 Feb 2013 09:43:22 +0000
Message-ID: <1360748602-9357-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
	full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
caused us to ignore rather than process a completely full ring. Check if
producer and consumer are equal before masking to avoid this, since prod ==
cons + PAGE_SIZE after masking becomes prod == cons.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
index 4888ac5..fdd9983 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
 	cons = *(volatile uint32*)&intf->req_cons;
 	prod = *(volatile uint32*)&intf->req_prod;
 	xen_mb();
-	cons = MASK_XENSTORE_IDX(cons);
-	prod = MASK_XENSTORE_IDX(prod);
 	if (prod == cons)
 		return 0;
+	cons = MASK_XENSTORE_IDX(cons);
+	prod = MASK_XENSTORE_IDX(prod);
 	if (prod > cons)
 		to_read = prod - cons;
 	else
-- 
1.7.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 Feb 13 09:43:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 09: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 1U5YsA-0001gb-RG; Wed, 13 Feb 2013 09:43: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 1U5YsA-0001gV-0N
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 09:43:26 +0000
Received: from [85.158.143.99:17713] by server-1.bemta-4.messagelabs.com id
	81/17-08839-D306B115; Wed, 13 Feb 2013 09:43:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360748603!17684972!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14795 invoked from network); 13 Feb 2013 09:43:24 -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;
	13 Feb 2013 09:43:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="6942417"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 09:43:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 04:43:22 -0500
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 1U5Ys6-0004Rf-EB;
	Wed, 13 Feb 2013 09:43:22 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 13 Feb 2013 09:43:22 +0000
Message-ID: <1360748602-9357-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
	full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
caused us to ignore rather than process a completely full ring. Check if
producer and consumer are equal before masking to avoid this, since prod ==
cons + PAGE_SIZE after masking becomes prod == cons.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
index 4888ac5..fdd9983 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
 	cons = *(volatile uint32*)&intf->req_cons;
 	prod = *(volatile uint32*)&intf->req_prod;
 	xen_mb();
-	cons = MASK_XENSTORE_IDX(cons);
-	prod = MASK_XENSTORE_IDX(prod);
 	if (prod == cons)
 		return 0;
+	cons = MASK_XENSTORE_IDX(cons);
+	prod = MASK_XENSTORE_IDX(prod);
 	if (prod > cons)
 		to_read = prod - cons;
 	else
-- 
1.7.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 Feb 13 10:18:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 10: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 1U5ZPz-00029h-Pg; Wed, 13 Feb 2013 10: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 1U5ZPy-00029c-2q
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 10:18:22 +0000
Received: from [85.158.139.83:58148] by server-12.bemta-5.messagelabs.com id
	40/52-20195-D686B115; Wed, 13 Feb 2013 10:18:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360750700!31229182!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5432 invoked from network); 13 Feb 2013 10:18:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 10:18:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1409007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 10:17: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.297.1; Wed, 13 Feb 2013 10:17:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5ZOx-0005nJ-Qu;
	Wed, 13 Feb 2013 10:17:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5ZOx-0002D7-KW;
	Wed, 13 Feb 2013 10:17:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16160-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 10:17:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16160: 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 16160 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16160/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv           14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl           14 guest-localmigrate/x10    fail REGR. vs. 15442

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a37aa55c3cbc
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26526:a37aa55c3cbc
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Tue Feb 12 11:29:51 2013 +0100
    
    unmodified_drivers: __devinit was removed in linux-3.8
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    
    Merge with __init handling.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26525:9af6e566befe
user:        Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
date:        Tue Feb 12 11:18:54 2013 +0100
    
    x86: Add Xenoprofile support for AMD Family16h
    
    Add Xenoprofile support for AMD Family16h. The corresponded OProfile
    patch has already been submitted to OProfile mailing list.
    (http://marc.info/?l=oprofile-list&m=136036136017302&w=2 ).
    
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26524:171018fef8f8
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Feb 12 11:12:22 2013 +0100
    
    x86/HAP: Add global enable/disable command line option
    
    Also, correct a copy&paste error in the documentation.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26523:fd997a96d448
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 13 10:18:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 10: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 1U5ZPz-00029h-Pg; Wed, 13 Feb 2013 10: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 1U5ZPy-00029c-2q
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 10:18:22 +0000
Received: from [85.158.139.83:58148] by server-12.bemta-5.messagelabs.com id
	40/52-20195-D686B115; Wed, 13 Feb 2013 10:18:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360750700!31229182!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5432 invoked from network); 13 Feb 2013 10:18:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 10:18:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1409007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 10:17: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.297.1; Wed, 13 Feb 2013 10:17:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5ZOx-0005nJ-Qu;
	Wed, 13 Feb 2013 10:17:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5ZOx-0002D7-KW;
	Wed, 13 Feb 2013 10:17:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16160-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 10:17:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16160: 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 16160 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16160/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv           14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 15442
 test-amd64-i386-xl           14 guest-localmigrate/x10    fail REGR. vs. 15442

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a37aa55c3cbc
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26526:a37aa55c3cbc
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Tue Feb 12 11:29:51 2013 +0100
    
    unmodified_drivers: __devinit was removed in linux-3.8
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    
    Merge with __init handling.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26525:9af6e566befe
user:        Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
date:        Tue Feb 12 11:18:54 2013 +0100
    
    x86: Add Xenoprofile support for AMD Family16h
    
    Add Xenoprofile support for AMD Family16h. The corresponded OProfile
    patch has already been submitted to OProfile mailing list.
    (http://marc.info/?l=oprofile-list&m=136036136017302&w=2 ).
    
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26524:171018fef8f8
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Tue Feb 12 11:12:22 2013 +0100
    
    x86/HAP: Add global enable/disable command line option
    
    Also, correct a copy&paste error in the documentation.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   26523:fd997a96d448
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@eu.citrix.com>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Matthew Daley <mattjd@gmail.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Feb 13 10:47:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 10:47: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 1U5Zs0-0002Re-71; Wed, 13 Feb 2013 10:47:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U5Zry-0002RZ-B1
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 10:47:18 +0000
Received: from [85.158.139.83:16081] by server-10.bemta-5.messagelabs.com id
	E4/A2-04697-53F6B115; Wed, 13 Feb 2013 10:47:17 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360752329!31657432!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25734 invoked from network); 13 Feb 2013 10:45:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 10:45:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1410125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 10:44:29 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 13 Feb 2013
	10:44:29 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 10:44:28 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether
	blktap3 is	available
Thread-Index: Ac4JSn0vx8l5krOBSa6e0O/iYv15jQAjIp7Q
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153A75F9536@LONPMAILBOX01.citrite.net>
References: <patchbomb.1360344251@makatos-desktop>
	<dd63f2992e71a1e43abf.1360344253@makatos-desktop>
	<20762.33440.178465.605902@mariner.uk.xensource.com>
In-Reply-To: <20762.33440.178465.605902@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
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andrei Lifchits <Andrei.Lifchits@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3
 is	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +/* FIXME get the tapback name from blktap3 instead of hard-coding */
> > +#define TAPBACK_NAME "tapback"
> > +#define CMD "pidof " TAPBACK_NAME
> 
> I'm afraid I'm fundamentally unhappy with this approach to detecting
> the availability of blktap3.  Searching the process table for process
> with particular names is not a good idea.
> 
> Can't you try to connect to its control socket ?

Sure.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 10:47:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 10:47: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 1U5Zs0-0002Re-71; Wed, 13 Feb 2013 10:47:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U5Zry-0002RZ-B1
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 10:47:18 +0000
Received: from [85.158.139.83:16081] by server-10.bemta-5.messagelabs.com id
	E4/A2-04697-53F6B115; Wed, 13 Feb 2013 10:47:17 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360752329!31657432!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25734 invoked from network); 13 Feb 2013 10:45:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 10:45:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1410125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 10:44:29 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 13 Feb 2013
	10:44:29 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 10:44:28 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether
	blktap3 is	available
Thread-Index: Ac4JSn0vx8l5krOBSa6e0O/iYv15jQAjIp7Q
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153A75F9536@LONPMAILBOX01.citrite.net>
References: <patchbomb.1360344251@makatos-desktop>
	<dd63f2992e71a1e43abf.1360344253@makatos-desktop>
	<20762.33440.178465.605902@mariner.uk.xensource.com>
In-Reply-To: <20762.33440.178465.605902@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
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andrei Lifchits <Andrei.Lifchits@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] blktap3/libxl: Check whether blktap3
 is	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +/* FIXME get the tapback name from blktap3 instead of hard-coding */
> > +#define TAPBACK_NAME "tapback"
> > +#define CMD "pidof " TAPBACK_NAME
> 
> I'm afraid I'm fundamentally unhappy with this approach to detecting
> the availability of blktap3.  Searching the process table for process
> with particular names is not a good idea.
> 
> Can't you try to connect to its control socket ?

Sure.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 11:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 11: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 1U5aK7-00030b-Bj; Wed, 13 Feb 2013 11:16:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U5aK5-00030S-Pb
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 11:16:22 +0000
Received: from [85.158.143.99:8341] by server-1.bemta-4.messagelabs.com id
	C3/68-08839-4067B115; Wed, 13 Feb 2013 11:16:20 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360754179!22081061!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4581 invoked from network); 13 Feb 2013 11:16:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 11:16:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1411513"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 11:16:20 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 13 Feb 2013
	11:16:19 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 11:16:18 +0000
Thread-Topic: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3
	device in	libxl
Thread-Index: Ac4JSwlwyfcb/pZiQCOoQ7VMQ9WaLAAjBXZw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153A75F9543@LONPMAILBOX01.citrite.net>
References: <patchbomb.1360344251@makatos-desktop>
	<6b54db4abe1276e1003d.1360344254@makatos-desktop>
	<20762.33679.974580.589786@mariner.uk.xensource.com>
In-Reply-To: <20762.33679.974580.589786@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
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andrei Lifchits <Andrei.Lifchits@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3
 device in	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

> ...
> > +            case LIBXL_DISK_BACKEND_TAP3:
> > +                flexarray_append(back, "params");
> > +                flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> > +                    libxl__device_disk_string_of_format(disk-
> >format),
> > +                    disk->pdev_path));
> > +                break;
> >              case LIBXL_DISK_BACKEND_QDISK:
> >                  flexarray_append(back, "params");
> >                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> 
> This seems to duplicate much of the entry for LIBXL_DISK_BACKEND_QDISK.
> I think this could be profitably reorganised to avoid clone-and-hack.

You're right, though I think I missed something: tapback spawns tapdisk when the front-end starts running the Xenbus protocol, so if it takes too long for tapback to spawn the tapdisk (e.g. the host is over-loaded) the domain creation will time out. To address this, libxl could tell tapback it's going to need a tapdisk on a particular file/disk/whatever (it will also have to explicitly tell tapback that it doesn't need the tapdisk anymore). Does this sound plausible?

> 
> > diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl_device.c
> > --- a/tools/libxl/libxl_device.c	Fri Feb 08 17:23:25 2013 +0000
> > +++ b/tools/libxl/libxl_device.c	Fri Feb 08 17:23:26 2013 +0000
> > @@ -190,6 +190,23 @@ static int disk_try_backend(disk_try_bac
> >          }
> >          return backend;
> >
> > +    case LIBXL_DISK_BACKEND_TAP3:
> > +        /* TODO What's that script thing? */
> > +        if (a->disk->script) goto bad_script;
> 
> Is this series supposed to be an RFC ?  It still has the odd TODO and
> FIXME in it.

No it's not an RFC. Some TODOs are there as guides for possible improvements/optimisations.

> 
> A disk script is an external script which arranges to provision a block
> device for use by guests (and dom0).  It's an alternative to
> TAP3 so I think you can just delete the comment.

I'll update the comment.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 11:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 11: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 1U5aK7-00030b-Bj; Wed, 13 Feb 2013 11:16:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U5aK5-00030S-Pb
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 11:16:22 +0000
Received: from [85.158.143.99:8341] by server-1.bemta-4.messagelabs.com id
	C3/68-08839-4067B115; Wed, 13 Feb 2013 11:16:20 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360754179!22081061!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4581 invoked from network); 13 Feb 2013 11:16:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 11:16:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,655,1355097600"; 
   d="scan'208";a="1411513"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 11:16:20 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 13 Feb 2013
	11:16:19 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 11:16:18 +0000
Thread-Topic: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3
	device in	libxl
Thread-Index: Ac4JSwlwyfcb/pZiQCOoQ7VMQ9WaLAAjBXZw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153A75F9543@LONPMAILBOX01.citrite.net>
References: <patchbomb.1360344251@makatos-desktop>
	<6b54db4abe1276e1003d.1360344254@makatos-desktop>
	<20762.33679.974580.589786@mariner.uk.xensource.com>
In-Reply-To: <20762.33679.974580.589786@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
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Andrei Lifchits <Andrei.Lifchits@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] blktap3/libxl: Handles blktap3
 device in	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

> ...
> > +            case LIBXL_DISK_BACKEND_TAP3:
> > +                flexarray_append(back, "params");
> > +                flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> > +                    libxl__device_disk_string_of_format(disk-
> >format),
> > +                    disk->pdev_path));
> > +                break;
> >              case LIBXL_DISK_BACKEND_QDISK:
> >                  flexarray_append(back, "params");
> >                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> 
> This seems to duplicate much of the entry for LIBXL_DISK_BACKEND_QDISK.
> I think this could be profitably reorganised to avoid clone-and-hack.

You're right, though I think I missed something: tapback spawns tapdisk when the front-end starts running the Xenbus protocol, so if it takes too long for tapback to spawn the tapdisk (e.g. the host is over-loaded) the domain creation will time out. To address this, libxl could tell tapback it's going to need a tapdisk on a particular file/disk/whatever (it will also have to explicitly tell tapback that it doesn't need the tapdisk anymore). Does this sound plausible?

> 
> > diff -r dd63f2992e71 -r 6b54db4abe12 tools/libxl/libxl_device.c
> > --- a/tools/libxl/libxl_device.c	Fri Feb 08 17:23:25 2013 +0000
> > +++ b/tools/libxl/libxl_device.c	Fri Feb 08 17:23:26 2013 +0000
> > @@ -190,6 +190,23 @@ static int disk_try_backend(disk_try_bac
> >          }
> >          return backend;
> >
> > +    case LIBXL_DISK_BACKEND_TAP3:
> > +        /* TODO What's that script thing? */
> > +        if (a->disk->script) goto bad_script;
> 
> Is this series supposed to be an RFC ?  It still has the odd TODO and
> FIXME in it.

No it's not an RFC. Some TODOs are there as guides for possible improvements/optimisations.

> 
> A disk script is an external script which arranges to provision a block
> device for use by guests (and dom0).  It's an alternative to
> TAP3 so I think you can just delete the comment.

I'll update the comment.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 11:32:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 11:32: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 1U5aZ1-0003JV-61; Wed, 13 Feb 2013 11:31:47 +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 1U5aYz-0003JO-0E
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 11:31:45 +0000
Received: from [193.109.254.147:31958] by server-16.bemta-14.messagelabs.com
	id 80/05-25906-F997B115; Wed, 13 Feb 2013 11:31:43 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360755077!2153931!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6770 invoked from network); 13 Feb 2013 11:31:17 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 11:31:17 -0000
Received: from p5b2e33be.dip.t-dialin.net ([91.46.51.190] 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 1U5aYW-0005PF-Eg; Wed, 13 Feb 2013 11:31:16 +0000
Message-ID: <511B7983.7000907@canonical.com>
Date: Wed, 13 Feb 2013 12:31:15 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360603744.20449.74.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9037532320681636710=="
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)
--===============9037532320681636710==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigC95BF4D59164A7C52A3588D0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC95BF4D59164A7C52A3588D0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11.02.2013 18:29, Ian Campbell wrote:

> An interesting hack^Wexperiment might be to make xen_poll_irq use a
> timeout and see if that unwedges things -- this would help confirm that=

> the issue is on nested wakeup.
>=20

So I did go forward and replaced xen_poll_irq by xen_poll_irq_timeout and=
 it did
get rid of the hang. Though I think there is a big taint there. There was=

only one other user of poll_irq_timeout in the kernel code. And that uses=

"jiffies + <timeout>*HZ". But when I look at the Xen side in do_poll, tha=
t looks
like it is using timeout in a absolute "ns since boot" (of hv/dom0) way. =
Not
sure how that ever can work. The ns since boot in the guest clearly is al=
ways
behind the host (and jiffies isn't ns either).
Effectively I likely got rid of any wait time in the hypervisor and back =
to
mostly spinning. Which matches the experience that the test run never get=
s stuck
waiting for a timeout. That maybe proves the stacking is an issue but als=
o is
likely a bit too aggressive in not having any... :/

I will try to think of some better way. Not sure the thinking is realisti=
c but
maybe that could happen:

xen_spin_lock_slow(a)
  ...
  enables irq and upcalls are pending
    upcall processing wants lock b
    xen_spin_lock_slow(b)
                    --- just before replacing lock_spinners ---
                                                   xen_spin_unlock_slow(a=
)
                                                   finds other vcpu, trig=
gers
                                                     IRQ
    lock b is top spinner
    going into poll_irq
    poll_irq returns
    lock a gets restored
    so maybe no spinners on b
    dropping out to xen_spin_lock
                                                  unlock of b not finding=
 any
                                                  spinners
    lock b acquired

That way the irq for lock a maybe get lost...


--------------enigC95BF4D59164A7C52A3588D0
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 undefined - http://www.enigmail.net/

iQIbBAEBCgAGBQJRG3mDAAoJEOhnXe7L7s6jxTUP9jdsIAZn6RKxBHaW3Y0DHGvz
2x4ZJ1jGktG7RzbqUcYoaU0PqOXgW/bpbdYAwx/Yz17/Y3CI0cR47DbhjJLsGCJt
kfb417yW35wN2AJs2pVeGOTETkBHE3vOLNipv8/fevYCg/8MaokIowDKuHbETY4c
aQOVqTLJ31zlCP04CxKfTmv5kw79hw3zF+VlEpFyHBivBU7sCfg1d9SlOrcyJseQ
HQXtss6McUOcFpNcOo1uoV6q+ODsIAhvicEp1WPgHzkctYhRG4m5nYgRaaemly9e
AaP0ONNIwdXcmPIZUSK2Q1qj1FvaAH9HRFvo07sYy4N2+uWHQOZWTXo5MWFUNdzh
Q9Vdpstx8SfsRXuByLdxML3QEjaVhbQ7uZt0J/4pp8z79d5jQT4hMgGS/+ENVsd1
vaBBvYBOX1/zbEIYNu2HkjNQpntvGKC6UPMkBNXZBc97eZIM/3RkKqatJknvbjDA
nsES9ks4szwqtnl2IacHV2EzGIbWmfdABaJzfJ9NTph2LHBVOa6HWXhKjfVbY5Kk
4lBrpV+jq+ExG1Qb/QWSuiHuLhPelMscKv29eyaPuTwEmV62AYQTHhRJIQMIwIFr
kKmZ+kPWv65PvfnYA+NkAfC9MmgzzT6+7EBeEK5hLNiqTS6MRrLn+4yfNY9tTpZZ
Ir7jIgVBD5D5g0DMieY=
=wnhp
-----END PGP SIGNATURE-----

--------------enigC95BF4D59164A7C52A3588D0--


--===============9037532320681636710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9037532320681636710==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 11:32:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 11:32: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 1U5aZ1-0003JV-61; Wed, 13 Feb 2013 11:31:47 +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 1U5aYz-0003JO-0E
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 11:31:45 +0000
Received: from [193.109.254.147:31958] by server-16.bemta-14.messagelabs.com
	id 80/05-25906-F997B115; Wed, 13 Feb 2013 11:31:43 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360755077!2153931!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6770 invoked from network); 13 Feb 2013 11:31:17 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 11:31:17 -0000
Received: from p5b2e33be.dip.t-dialin.net ([91.46.51.190] 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 1U5aYW-0005PF-Eg; Wed, 13 Feb 2013 11:31:16 +0000
Message-ID: <511B7983.7000907@canonical.com>
Date: Wed, 13 Feb 2013 12:31:15 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360603744.20449.74.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9037532320681636710=="
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)
--===============9037532320681636710==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigC95BF4D59164A7C52A3588D0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC95BF4D59164A7C52A3588D0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11.02.2013 18:29, Ian Campbell wrote:

> An interesting hack^Wexperiment might be to make xen_poll_irq use a
> timeout and see if that unwedges things -- this would help confirm that=

> the issue is on nested wakeup.
>=20

So I did go forward and replaced xen_poll_irq by xen_poll_irq_timeout and=
 it did
get rid of the hang. Though I think there is a big taint there. There was=

only one other user of poll_irq_timeout in the kernel code. And that uses=

"jiffies + <timeout>*HZ". But when I look at the Xen side in do_poll, tha=
t looks
like it is using timeout in a absolute "ns since boot" (of hv/dom0) way. =
Not
sure how that ever can work. The ns since boot in the guest clearly is al=
ways
behind the host (and jiffies isn't ns either).
Effectively I likely got rid of any wait time in the hypervisor and back =
to
mostly spinning. Which matches the experience that the test run never get=
s stuck
waiting for a timeout. That maybe proves the stacking is an issue but als=
o is
likely a bit too aggressive in not having any... :/

I will try to think of some better way. Not sure the thinking is realisti=
c but
maybe that could happen:

xen_spin_lock_slow(a)
  ...
  enables irq and upcalls are pending
    upcall processing wants lock b
    xen_spin_lock_slow(b)
                    --- just before replacing lock_spinners ---
                                                   xen_spin_unlock_slow(a=
)
                                                   finds other vcpu, trig=
gers
                                                     IRQ
    lock b is top spinner
    going into poll_irq
    poll_irq returns
    lock a gets restored
    so maybe no spinners on b
    dropping out to xen_spin_lock
                                                  unlock of b not finding=
 any
                                                  spinners
    lock b acquired

That way the irq for lock a maybe get lost...


--------------enigC95BF4D59164A7C52A3588D0
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 undefined - http://www.enigmail.net/

iQIbBAEBCgAGBQJRG3mDAAoJEOhnXe7L7s6jxTUP9jdsIAZn6RKxBHaW3Y0DHGvz
2x4ZJ1jGktG7RzbqUcYoaU0PqOXgW/bpbdYAwx/Yz17/Y3CI0cR47DbhjJLsGCJt
kfb417yW35wN2AJs2pVeGOTETkBHE3vOLNipv8/fevYCg/8MaokIowDKuHbETY4c
aQOVqTLJ31zlCP04CxKfTmv5kw79hw3zF+VlEpFyHBivBU7sCfg1d9SlOrcyJseQ
HQXtss6McUOcFpNcOo1uoV6q+ODsIAhvicEp1WPgHzkctYhRG4m5nYgRaaemly9e
AaP0ONNIwdXcmPIZUSK2Q1qj1FvaAH9HRFvo07sYy4N2+uWHQOZWTXo5MWFUNdzh
Q9Vdpstx8SfsRXuByLdxML3QEjaVhbQ7uZt0J/4pp8z79d5jQT4hMgGS/+ENVsd1
vaBBvYBOX1/zbEIYNu2HkjNQpntvGKC6UPMkBNXZBc97eZIM/3RkKqatJknvbjDA
nsES9ks4szwqtnl2IacHV2EzGIbWmfdABaJzfJ9NTph2LHBVOa6HWXhKjfVbY5Kk
4lBrpV+jq+ExG1Qb/QWSuiHuLhPelMscKv29eyaPuTwEmV62AYQTHhRJIQMIwIFr
kKmZ+kPWv65PvfnYA+NkAfC9MmgzzT6+7EBeEK5hLNiqTS6MRrLn+4yfNY9tTpZZ
Ir7jIgVBD5D5g0DMieY=
=wnhp
-----END PGP SIGNATURE-----

--------------enigC95BF4D59164A7C52A3588D0--


--===============9037532320681636710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9037532320681636710==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 11:49:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 11: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 1U5apQ-0003Y5-7N; Wed, 13 Feb 2013 11:48:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1U5apP-0003Y0-3o
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 11:48:43 +0000
Received: from [85.158.138.51:40648] by server-15.bemta-3.messagelabs.com id
	CF/DC-25405-A9D7B115; Wed, 13 Feb 2013 11:48:42 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360756113!19442826!1
X-Originating-IP: [209.85.220.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20544 invoked from network); 13 Feb 2013 11:48:34 -0000
Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com)
	(209.85.220.178)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 11:48:34 -0000
Received: by mail-vc0-f178.google.com with SMTP id m8so693856vcd.23
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 03:48:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:references:from:mime-version:in-reply-to:date:message-id
	:subject:to:cc:content-type;
	bh=pG6l6TCG2hyySLUuDVxsXekdhs8W1szQ5ADqWIQ4+ng=;
	b=U+5L8lNxjvYcabwB0S/uugGsQ1RB9adHq/Hq0LteXkO0Ai11Xjd6NO4Zs3oMPa6LI8
	9gnmXXXjWdJ4TjfbRdYpt2nPDGRvPFmgiKXoE3VyZ9sZ1/dAkjgpcrH9XgzSoVARh8/W
	F8nwsEK8DeVc5TcDproYdjcjioA36bN6LYGoSnINnUx11PX13+cHRnjpIedpz1cxRP1a
	xbsoA55f7zbTeQhCs7nF3o8GBLMhQMyt5sW/czm/P683pDICqpL84lhbk6bTFOlDe6Op
	MpSmZkaxK56MuNPL34fR0vYnjXoFVTY1ZRLRpdMDCjq4k3OO2m3kwNgI6l3ij+NC9XV7
	RhUQ==
X-Received: by 10.59.7.170 with SMTP id dd10mr28591971ved.2.1360756113369;
	Wed, 13 Feb 2013 03:48:33 -0800 (PST)
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
	<20130212215655.GA18127@phenom.dumpdata.com>
	<511B5C8402000078000BDE5A@nat28.tlf.novell.com>
From: Ben Guthro <ben.guthro@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <511B5C8402000078000BDE5A@nat28.tlf.novell.com>
Date: Wed, 13 Feb 2013 06:48:32 -0500
Message-ID: <7839105284694601472@unknownmsgid>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Milan opath <milan.opath@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Feb 13, 2013, at 3:27 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 12.02.13 at 22:56, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> On Tue, Feb 12, 2013 at 10:40:32PM +0100, Milan opath wrote:
>>> xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
>>> ok. Unfortunately resume from S3 still doesn't work.
>>
>> So then the process of elimination starts. Try doing it without having Xorg
>> or any
>> KMS drivers running (so text-console). Then also try without serial output.
>> And also as somebody suggested with dom0_pin_vcpus arguments.
>
> Without, you mean? Iirc Ben's findings suggested that there are
> problems when this option is used.
>
> Jan
>

Yes, this was the reason for some of the scheduler changes introduced
by system_state in the original patches I attached.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 11:49:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 11: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 1U5apQ-0003Y5-7N; Wed, 13 Feb 2013 11:48:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1U5apP-0003Y0-3o
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 11:48:43 +0000
Received: from [85.158.138.51:40648] by server-15.bemta-3.messagelabs.com id
	CF/DC-25405-A9D7B115; Wed, 13 Feb 2013 11:48:42 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360756113!19442826!1
X-Originating-IP: [209.85.220.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20544 invoked from network); 13 Feb 2013 11:48:34 -0000
Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com)
	(209.85.220.178)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 11:48:34 -0000
Received: by mail-vc0-f178.google.com with SMTP id m8so693856vcd.23
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 03:48:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:references:from:mime-version:in-reply-to:date:message-id
	:subject:to:cc:content-type;
	bh=pG6l6TCG2hyySLUuDVxsXekdhs8W1szQ5ADqWIQ4+ng=;
	b=U+5L8lNxjvYcabwB0S/uugGsQ1RB9adHq/Hq0LteXkO0Ai11Xjd6NO4Zs3oMPa6LI8
	9gnmXXXjWdJ4TjfbRdYpt2nPDGRvPFmgiKXoE3VyZ9sZ1/dAkjgpcrH9XgzSoVARh8/W
	F8nwsEK8DeVc5TcDproYdjcjioA36bN6LYGoSnINnUx11PX13+cHRnjpIedpz1cxRP1a
	xbsoA55f7zbTeQhCs7nF3o8GBLMhQMyt5sW/czm/P683pDICqpL84lhbk6bTFOlDe6Op
	MpSmZkaxK56MuNPL34fR0vYnjXoFVTY1ZRLRpdMDCjq4k3OO2m3kwNgI6l3ij+NC9XV7
	RhUQ==
X-Received: by 10.59.7.170 with SMTP id dd10mr28591971ved.2.1360756113369;
	Wed, 13 Feb 2013 03:48:33 -0800 (PST)
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
	<20130212215655.GA18127@phenom.dumpdata.com>
	<511B5C8402000078000BDE5A@nat28.tlf.novell.com>
From: Ben Guthro <ben.guthro@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <511B5C8402000078000BDE5A@nat28.tlf.novell.com>
Date: Wed, 13 Feb 2013 06:48:32 -0500
Message-ID: <7839105284694601472@unknownmsgid>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Milan opath <milan.opath@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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 Feb 13, 2013, at 3:27 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 12.02.13 at 22:56, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> On Tue, Feb 12, 2013 at 10:40:32PM +0100, Milan opath wrote:
>>> xen-acpi-processor module is loaded and xenpm get-cpufreq-para seems to be
>>> ok. Unfortunately resume from S3 still doesn't work.
>>
>> So then the process of elimination starts. Try doing it without having Xorg
>> or any
>> KMS drivers running (so text-console). Then also try without serial output.
>> And also as somebody suggested with dom0_pin_vcpus arguments.
>
> Without, you mean? Iirc Ben's findings suggested that there are
> problems when this option is used.
>
> Jan
>

Yes, this was the reason for some of the scheduler changes introduced
by system_state in the original patches I attached.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 12:17:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 12: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 1U5bGt-00048L-TA; Wed, 13 Feb 2013 12:17:07 +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 1U5bGs-00048D-NV
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 12:17:06 +0000
Received: from [193.109.254.147:21948] by server-8.bemta-14.messagelabs.com id
	1D/05-17325-1448B115; Wed, 13 Feb 2013 12:17:05 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360757813!8366934!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30138 invoked from network); 13 Feb 2013 12:16:54 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 12:16:54 -0000
Received: from p5b2e33be.dip.t-dialin.net ([91.46.51.190] 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 1U5bGe-0006nn-QK; Wed, 13 Feb 2013 12:16:52 +0000
Message-ID: <511B8433.7070006@canonical.com>
Date: Wed, 13 Feb 2013 13:16:51 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511B7983.7000907@canonical.com>
In-Reply-To: <511B7983.7000907@canonical.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4618302985902255805=="
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)
--===============4618302985902255805==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigB9D27EE82D4922A87EF8074A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9D27EE82D4922A87EF8074A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 13.02.2013 12:31, Stefan Bader wrote:

> I will try to think of some better way. Not sure the thinking is realis=
tic but
> maybe that could happen:
>=20
> xen_spin_lock_slow(a)
>   ...
>   enables irq and upcalls are pending
>     upcall processing wants lock b
>     xen_spin_lock_slow(b)
>                     --- just before replacing lock_spinners ---
>                                                    xen_spin_unlock_slow=
(a)
>                                                    finds other vcpu, tr=
iggers
>                                                      IRQ
>     lock b is top spinner
>     going into poll_irq
>     poll_irq returns
>     lock a gets restored
>     so maybe no spinners on b
>     dropping out to xen_spin_lock
>                                                   unlock of b not findi=
ng any
>                                                   spinners
>     lock b acquired
>=20
> That way the irq for lock a maybe get lost...

Darn, maybe not since the pending status is not cleared when leaving
xen_spin_lock_slow. So I assume the interrupted lock does at least one cy=
cle out
of slow and back...



--------------enigB9D27EE82D4922A87EF8074A
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRG4QzAAoJEOhnXe7L7s6jFEQP+wVJZ7p82/Km3V8LAj+IYYR+
m03HBcD3nj/sBX8j3Qd+CtQqFwQwxSS7PqtnMlleYIi6uqBdVvilzh6pJ+I7Wk3V
6LEVg8im+yQduBLhtSTEUATo34IYM8ep4g7qs7rgV4AHJqz4Zpq8RVCBWNltPtP8
yL0fZR0rvqvoReKg82M4CHb9Ph/ZXC4kUDvY9KhtMcEoMFSQaPhdKA2pNQI/OoHi
5cEs52zxaxXw2Ig/MrU3EIzdr5rKLBdeFwmikWnte0j7+11yb4zg8uIidZv0I6zp
8tVKdt5VH5Z595RkK7gCr+zCPx1WbmzAP4vKfR6F4gq/XSSNon63bmZdzAsIviEj
cz5z2hp6eH/36eD2CyorEbyzES70K0vIjJViE/ka6oAmoGrccz9H41a5XRpt/Vwx
z9NuS1E/LtcCAMrxcXyfq6Gdt+BW9HlnXvSxQzc2omCGwOszKDCXjnoLtRm5kIDp
SAU/94x1OBkZ+2bDVf/sBS3jWDagA87iIOa0+c7iu9QmyTPKD3F4gcYGxmUd8gEd
q5oclIYlEuJqo30Z1Nc0v45/1POrI4p8TQNZ8i2oOzqLZrj3ivggsRNEuV3YvelW
ZMgwiLH1Fy/ut+AxuWs4fMRXuYg34a+yrW2fCMky2tzUjFV3E6a2h07SpmeQKhAA
eF4HvVYQh361ziMueAgu
=Vj3/
-----END PGP SIGNATURE-----

--------------enigB9D27EE82D4922A87EF8074A--


--===============4618302985902255805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4618302985902255805==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 12:17:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 12: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 1U5bGt-00048L-TA; Wed, 13 Feb 2013 12:17:07 +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 1U5bGs-00048D-NV
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 12:17:06 +0000
Received: from [193.109.254.147:21948] by server-8.bemta-14.messagelabs.com id
	1D/05-17325-1448B115; Wed, 13 Feb 2013 12:17:05 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360757813!8366934!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30138 invoked from network); 13 Feb 2013 12:16:54 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 12:16:54 -0000
Received: from p5b2e33be.dip.t-dialin.net ([91.46.51.190] 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 1U5bGe-0006nn-QK; Wed, 13 Feb 2013 12:16:52 +0000
Message-ID: <511B8433.7070006@canonical.com>
Date: Wed, 13 Feb 2013 13:16:51 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <51151ABF.1070007@canonical.com>
	<1360603744.20449.74.camel@zakaz.uk.xensource.com>
	<511B7983.7000907@canonical.com>
In-Reply-To: <511B7983.7000907@canonical.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4618302985902255805=="
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)
--===============4618302985902255805==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigB9D27EE82D4922A87EF8074A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9D27EE82D4922A87EF8074A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 13.02.2013 12:31, Stefan Bader wrote:

> I will try to think of some better way. Not sure the thinking is realis=
tic but
> maybe that could happen:
>=20
> xen_spin_lock_slow(a)
>   ...
>   enables irq and upcalls are pending
>     upcall processing wants lock b
>     xen_spin_lock_slow(b)
>                     --- just before replacing lock_spinners ---
>                                                    xen_spin_unlock_slow=
(a)
>                                                    finds other vcpu, tr=
iggers
>                                                      IRQ
>     lock b is top spinner
>     going into poll_irq
>     poll_irq returns
>     lock a gets restored
>     so maybe no spinners on b
>     dropping out to xen_spin_lock
>                                                   unlock of b not findi=
ng any
>                                                   spinners
>     lock b acquired
>=20
> That way the irq for lock a maybe get lost...

Darn, maybe not since the pending status is not cleared when leaving
xen_spin_lock_slow. So I assume the interrupted lock does at least one cy=
cle out
of slow and back...



--------------enigB9D27EE82D4922A87EF8074A
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRG4QzAAoJEOhnXe7L7s6jFEQP+wVJZ7p82/Km3V8LAj+IYYR+
m03HBcD3nj/sBX8j3Qd+CtQqFwQwxSS7PqtnMlleYIi6uqBdVvilzh6pJ+I7Wk3V
6LEVg8im+yQduBLhtSTEUATo34IYM8ep4g7qs7rgV4AHJqz4Zpq8RVCBWNltPtP8
yL0fZR0rvqvoReKg82M4CHb9Ph/ZXC4kUDvY9KhtMcEoMFSQaPhdKA2pNQI/OoHi
5cEs52zxaxXw2Ig/MrU3EIzdr5rKLBdeFwmikWnte0j7+11yb4zg8uIidZv0I6zp
8tVKdt5VH5Z595RkK7gCr+zCPx1WbmzAP4vKfR6F4gq/XSSNon63bmZdzAsIviEj
cz5z2hp6eH/36eD2CyorEbyzES70K0vIjJViE/ka6oAmoGrccz9H41a5XRpt/Vwx
z9NuS1E/LtcCAMrxcXyfq6Gdt+BW9HlnXvSxQzc2omCGwOszKDCXjnoLtRm5kIDp
SAU/94x1OBkZ+2bDVf/sBS3jWDagA87iIOa0+c7iu9QmyTPKD3F4gcYGxmUd8gEd
q5oclIYlEuJqo30Z1Nc0v45/1POrI4p8TQNZ8i2oOzqLZrj3ivggsRNEuV3YvelW
ZMgwiLH1Fy/ut+AxuWs4fMRXuYg34a+yrW2fCMky2tzUjFV3E6a2h07SpmeQKhAA
eF4HvVYQh361ziMueAgu
=Vj3/
-----END PGP SIGNATURE-----

--------------enigB9D27EE82D4922A87EF8074A--


--===============4618302985902255805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4618302985902255805==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 12:25:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 12:25: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 1U5bOy-0004JZ-Tw; Wed, 13 Feb 2013 12:25: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 1U5bOx-0004JU-TX
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 12:25:28 +0000
Received: from [85.158.139.83:42428] by server-9.bemta-5.messagelabs.com id
	DB/41-24440-7368B115; Wed, 13 Feb 2013 12:25:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360758325!27685756!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 13 Feb 2013 12:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 12:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; 
   d="scan'208";a="1414055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 12:25: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.297.1; Wed, 13 Feb 2013 12:25:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5bOv-0006Uk-9V; Wed, 13 Feb 2013 12:25:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5bOv-0005Pn-5d;
	Wed, 13 Feb 2013 12:25:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20763.34351.854483.320275@mariner.uk.xensource.com>
Date: Wed, 13 Feb 2013 12:25:19 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <D66675BF9FE63A7F8D0FE7D3@nimrod.local>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
	<20762.25460.618127.856037@mariner.uk.xensource.com>
	<D66675BF9FE63A7F8D0FE7D3@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 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

Alex Bligh writes ("Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> Firstly, thanks for the review. I think the issue of JSON_ERROR's removal
> you thought was OK in the end because it was from the _internal file

Yes.

> > This backport is fine but needs to come at the end of the series, I
> > think ?
> 
> I can reorder patch 11 so it precedes patch 10 if you want. It's only
> there as I found the bug in patch 11 later. Tell me if you want me to
> do this.

That would be best, I think.

> If I'm right re JSON_ERROR, the only substantive issue is the following:
> 
> > I've had another thought: what if this series is applied, including
> > this final patch, but the result is used with an older qemu which
> > hasn't had the relevant features added ?
> 
> Does that ever happen? By which I mean does that ever happen in a manner
> that is permitted?

Certainly there are deployment strategies - often ones used by distros
- which might have that result.

> I thought if you were using Xen 4.2 you pretty much had to be using either
> a qemu upstream compiled specifically for Xen and thus distributed with
> it, so you'd expect to upgrade it, or you'd be using one of the newer
> upstream releases which has all this stuff in anyway. Was there some
> window where true upstream qemu (as opposed to the one carried by Xen) had
> a release version which carried Xen 4.2 support and qemu DM, but not
> live migrate?

I think we can't assume that people won't have taken snapshots
particularly of our stable branch.

> > AFAICT the result would probably be a failure to execute the logdirty
> > switch.  Is that error sufficiently clean ?
> 
> This might depend on our policy of using mixed versions of qemu and
> xen. If a policy of "either use the version of qemu included in Xen
> or use a version greater than N.N.N" is ok, then I think the answer is
> yes.

My concern is only whether turning an existing specifically-diagnosed
failure into a more general one is acceptable, under these
circumstances.  TBH I'm inclined to think it is in this case but I
wanted to give you and others a chance to comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 12:25:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 12:25: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 1U5bOy-0004JZ-Tw; Wed, 13 Feb 2013 12:25: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 1U5bOx-0004JU-TX
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 12:25:28 +0000
Received: from [85.158.139.83:42428] by server-9.bemta-5.messagelabs.com id
	DB/41-24440-7368B115; Wed, 13 Feb 2013 12:25:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360758325!27685756!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28946 invoked from network); 13 Feb 2013 12:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 12:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; 
   d="scan'208";a="1414055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 12:25: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.297.1; Wed, 13 Feb 2013 12:25:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5bOv-0006Uk-9V; Wed, 13 Feb 2013 12:25:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5bOv-0005Pn-5d;
	Wed, 13 Feb 2013 12:25:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20763.34351.854483.320275@mariner.uk.xensource.com>
Date: Wed, 13 Feb 2013 12:25:19 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <D66675BF9FE63A7F8D0FE7D3@nimrod.local>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
	<20762.25460.618127.856037@mariner.uk.xensource.com>
	<D66675BF9FE63A7F8D0FE7D3@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with 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

Alex Bligh writes ("Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen."):
> Firstly, thanks for the review. I think the issue of JSON_ERROR's removal
> you thought was OK in the end because it was from the _internal file

Yes.

> > This backport is fine but needs to come at the end of the series, I
> > think ?
> 
> I can reorder patch 11 so it precedes patch 10 if you want. It's only
> there as I found the bug in patch 11 later. Tell me if you want me to
> do this.

That would be best, I think.

> If I'm right re JSON_ERROR, the only substantive issue is the following:
> 
> > I've had another thought: what if this series is applied, including
> > this final patch, but the result is used with an older qemu which
> > hasn't had the relevant features added ?
> 
> Does that ever happen? By which I mean does that ever happen in a manner
> that is permitted?

Certainly there are deployment strategies - often ones used by distros
- which might have that result.

> I thought if you were using Xen 4.2 you pretty much had to be using either
> a qemu upstream compiled specifically for Xen and thus distributed with
> it, so you'd expect to upgrade it, or you'd be using one of the newer
> upstream releases which has all this stuff in anyway. Was there some
> window where true upstream qemu (as opposed to the one carried by Xen) had
> a release version which carried Xen 4.2 support and qemu DM, but not
> live migrate?

I think we can't assume that people won't have taken snapshots
particularly of our stable branch.

> > AFAICT the result would probably be a failure to execute the logdirty
> > switch.  Is that error sufficiently clean ?
> 
> This might depend on our policy of using mixed versions of qemu and
> xen. If a policy of "either use the version of qemu included in Xen
> or use a version greater than N.N.N" is ok, then I think the answer is
> yes.

My concern is only whether turning an existing specifically-diagnosed
failure into a more general one is acceptable, under these
circumstances.  TBH I'm inclined to think it is in this case but I
wanted to give you and others a chance to comment.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 12:47:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 12:47: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 1U5bkD-0004Zl-37; Wed, 13 Feb 2013 12:47:25 +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 1U5bkB-0004Zg-E8
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 12:47:23 +0000
Received: from [85.158.143.99:49251] by server-2.bemta-4.messagelabs.com id
	04/3E-01597-A5B8B115; Wed, 13 Feb 2013 12:47:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360759638!16146304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11939 invoked from network); 13 Feb 2013 12:47:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 12:47:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; 
   d="scan'208";a="7321309"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 12:47:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 07:47:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5bk5-0007R0-14;
	Wed, 13 Feb 2013 12:47:17 +0000
Message-ID: <1360759637.16636.85.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Wed, 13 Feb 2013 12:47:17 +0000
In-Reply-To: <511AFFC9.3050404@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
> On 2/12/13 4:58 AM, Ian Campbell wrote:
> > Have you applied the XSA-39 fixes to this kernel?
> 
> Yes!  When I rebuilt with Wei's suggested patch for my original 
> netback/xenwatch problem I also brought us up to date with XSA patches.
> 
> We just hit the same (new) problem on another machine, and looking at 
> the BUG with more kernel output context gives a giant clue:
> 
> Feb 12 20:30:54: IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready
> Feb 12 20:30:54: device vif21.0 entered promiscuous mode
> Feb 12 20:30:56: xen-blkback:ring-ref 8, event-channel 31, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: xen-blkback:ring-ref 9, event-channel 32, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:58: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
> Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
> <--------------
> Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference 
> at 00000000000008b8

Good to have more context.

So the vif in question is disabled and unlinked from netbk but it gets
rescheduled?

Could you try something in xen_netbk_schedule_xenvif

if (vif->netbk == NULL)
	netdev_err(vif->dev, "OOPS\n");

You should be able to get the device name. If it is the same name as the
disabled device, we might get a bug somewhere alone the scheduling path.


Wei.


> Feb 12 20:34:12: IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: PGD 0
> Feb 12 20:34:12: Oops: 0002 [#1] SMP
> Feb 12 20:34:12: Modules linked in: ebt_comment ebt_arp ebt_set 
> ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev 
> bonding ebtable_filter e1000e
> Feb 12 20:34:12: CPU 3
> Feb 12 20:34:12: Pid: 1548, comm: netback/3 Not tainted 3.7.6-1-x86_64 
> #1 Supermicro X8DT6/X8DT6
> Feb 12 20:34:12: RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: RSP: e02b:ffff880083681b58  EFLAGS: 00010006
> Feb 12 20:34:12: RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 
> 0000000000000663
> Feb 12 20:34:12: RDX: 0000000000000001 RSI: 0000000000000210 RDI: 
> 00000000000008b8
> Feb 12 20:34:12: RBP: ffff880083681b78 R08: 000000000000000d R09: 
> 0000000000000000
> Feb 12 20:34:12: R10: 0000000000000001 R11: 0000000000000001 R12: 
> 0000000000000001
> Feb 12 20:34:12: R13: 0000000000000200 R14: 0000000000000400 R15: 
> 0000000000000663
> Feb 12 20:34:12: FS:  00007f2bc1fb2700(0000) GS:ffff8801006c0000(0000) 
> knlGS:0000000000000000
> Feb 12 20:34:12: CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> Feb 12 20:34:12: CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 
> 0000000000002660
> Feb 12 20:34:12: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
> 0000000000000000
> Feb 12 20:34:12: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
> 0000000000000400
> Feb 12 20:34:12: Process netback/3 (pid: 1548, threadinfo 
> ffff880083680000, task ffff8800837ec9c0)
> Feb 12 20:34:12: Stack:
> Feb 12 20:34:12: 0000000000000210 00000000000008b8 ffff880003baa700 
> ffff880003baa7d8
> Feb 12 20:34:12: ffff880083681b98 ffffffff817605da 0000000000000000 
> 00000000000008b8
> Feb 12 20:34:12: ffff880083681bd8 ffffffff8154446f ffff880003baa000 
> 0000000000000000
> Feb 12 20:34:12: Call Trace:
> Feb 12 20:34:12: [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
> Feb 12 20:34:12: [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
> Feb 12 20:34:12: [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
> Feb 12 20:34:12: [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
> Feb 12 20:34:12: [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
> Feb 12 20:34:12: [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
> Feb 12 20:34:12: [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
> Feb 12 20:34:12: [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
> Feb 12 20:34:12: [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
> Feb 12 20:34:12: [<ffffffff81071a06>] kthread+0xc6/0xd0
> Feb 12 20:34:12: [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
> Feb 12 20:34:12: [<ffffffff81071940>] ? 
> kthread_freezable_should_stop+0x70/0x70
> Feb 12 20:34:12: [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
> Feb 12 20:34:12: [<ffffffff81071940>] ? 
> kthread_freezable_should_stop+0x70/0x70
> Feb 12 20:34:12: Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 
> 89 fb 41 81 e5 00 02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 
> 44 89 e2 <86> 13 84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
> Feb 12 20:34:12: RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: RSP <ffff880083681b58>
> Feb 12 20:34:12: CR2: 00000000000008b8
> Feb 12 20:34:12: ---[ end trace ae243211c8c8cba5 ]---
> 
> https://lkml.org/lkml/2013/2/12/575 - "xen/netback: shut down the ring 
> if it contains garbage"
> 
> -Chris
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 12:47:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 12:47: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 1U5bkD-0004Zl-37; Wed, 13 Feb 2013 12:47:25 +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 1U5bkB-0004Zg-E8
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 12:47:23 +0000
Received: from [85.158.143.99:49251] by server-2.bemta-4.messagelabs.com id
	04/3E-01597-A5B8B115; Wed, 13 Feb 2013 12:47:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360759638!16146304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11939 invoked from network); 13 Feb 2013 12:47:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 12:47:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; 
   d="scan'208";a="7321309"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 12:47:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 07:47:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5bk5-0007R0-14;
	Wed, 13 Feb 2013 12:47:17 +0000
Message-ID: <1360759637.16636.85.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Wed, 13 Feb 2013 12:47:17 +0000
In-Reply-To: <511AFFC9.3050404@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
> On 2/12/13 4:58 AM, Ian Campbell wrote:
> > Have you applied the XSA-39 fixes to this kernel?
> 
> Yes!  When I rebuilt with Wei's suggested patch for my original 
> netback/xenwatch problem I also brought us up to date with XSA patches.
> 
> We just hit the same (new) problem on another machine, and looking at 
> the BUG with more kernel output context gives a giant clue:
> 
> Feb 12 20:30:54: IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready
> Feb 12 20:30:54: device vif21.0 entered promiscuous mode
> Feb 12 20:30:56: xen-blkback:ring-ref 8, event-channel 31, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: xen-blkback:ring-ref 9, event-channel 32, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:58: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
> Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
> <--------------
> Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference 
> at 00000000000008b8

Good to have more context.

So the vif in question is disabled and unlinked from netbk but it gets
rescheduled?

Could you try something in xen_netbk_schedule_xenvif

if (vif->netbk == NULL)
	netdev_err(vif->dev, "OOPS\n");

You should be able to get the device name. If it is the same name as the
disabled device, we might get a bug somewhere alone the scheduling path.


Wei.


> Feb 12 20:34:12: IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: PGD 0
> Feb 12 20:34:12: Oops: 0002 [#1] SMP
> Feb 12 20:34:12: Modules linked in: ebt_comment ebt_arp ebt_set 
> ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev 
> bonding ebtable_filter e1000e
> Feb 12 20:34:12: CPU 3
> Feb 12 20:34:12: Pid: 1548, comm: netback/3 Not tainted 3.7.6-1-x86_64 
> #1 Supermicro X8DT6/X8DT6
> Feb 12 20:34:12: RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: RSP: e02b:ffff880083681b58  EFLAGS: 00010006
> Feb 12 20:34:12: RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 
> 0000000000000663
> Feb 12 20:34:12: RDX: 0000000000000001 RSI: 0000000000000210 RDI: 
> 00000000000008b8
> Feb 12 20:34:12: RBP: ffff880083681b78 R08: 000000000000000d R09: 
> 0000000000000000
> Feb 12 20:34:12: R10: 0000000000000001 R11: 0000000000000001 R12: 
> 0000000000000001
> Feb 12 20:34:12: R13: 0000000000000200 R14: 0000000000000400 R15: 
> 0000000000000663
> Feb 12 20:34:12: FS:  00007f2bc1fb2700(0000) GS:ffff8801006c0000(0000) 
> knlGS:0000000000000000
> Feb 12 20:34:12: CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> Feb 12 20:34:12: CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 
> 0000000000002660
> Feb 12 20:34:12: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
> 0000000000000000
> Feb 12 20:34:12: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
> 0000000000000400
> Feb 12 20:34:12: Process netback/3 (pid: 1548, threadinfo 
> ffff880083680000, task ffff8800837ec9c0)
> Feb 12 20:34:12: Stack:
> Feb 12 20:34:12: 0000000000000210 00000000000008b8 ffff880003baa700 
> ffff880003baa7d8
> Feb 12 20:34:12: ffff880083681b98 ffffffff817605da 0000000000000000 
> 00000000000008b8
> Feb 12 20:34:12: ffff880083681bd8 ffffffff8154446f ffff880003baa000 
> 0000000000000000
> Feb 12 20:34:12: Call Trace:
> Feb 12 20:34:12: [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
> Feb 12 20:34:12: [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
> Feb 12 20:34:12: [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
> Feb 12 20:34:12: [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
> Feb 12 20:34:12: [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
> Feb 12 20:34:12: [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
> Feb 12 20:34:12: [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
> Feb 12 20:34:12: [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
> Feb 12 20:34:12: [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
> Feb 12 20:34:12: [<ffffffff81071a06>] kthread+0xc6/0xd0
> Feb 12 20:34:12: [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
> Feb 12 20:34:12: [<ffffffff81071940>] ? 
> kthread_freezable_should_stop+0x70/0x70
> Feb 12 20:34:12: [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
> Feb 12 20:34:12: [<ffffffff81071940>] ? 
> kthread_freezable_should_stop+0x70/0x70
> Feb 12 20:34:12: Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 
> 89 fb 41 81 e5 00 02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 
> 44 89 e2 <86> 13 84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
> Feb 12 20:34:12: RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: RSP <ffff880083681b58>
> Feb 12 20:34:12: CR2: 00000000000008b8
> Feb 12 20:34:12: ---[ end trace ae243211c8c8cba5 ]---
> 
> https://lkml.org/lkml/2013/2/12/575 - "xen/netback: shut down the ring 
> if it contains garbage"
> 
> -Chris
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 13:50:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 13:50: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 1U5cin-00055R-W2; Wed, 13 Feb 2013 13:50:01 +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 1U5cil-00055M-Pu
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 13:49:59 +0000
Received: from [85.158.143.35:40941] by server-3.bemta-4.messagelabs.com id
	DC/6B-08920-60A9B115; Wed, 13 Feb 2013 13:49:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360763250!12397880!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19519 invoked from network); 13 Feb 2013 13:47:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 13:47:32 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalMmrc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jorabe mo19) (RZmta 31.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C036cep1DDlLfZ ;
	Wed, 13 Feb 2013 14:47:30 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 437851884C; Wed, 13 Feb 2013 14:47:30 +0100 (CET)
Date: Wed, 13 Feb 2013 14:47:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130213134730.GA19050@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359972720.5281.20.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1359745022 -3600
> > # Node ID d76b38b799293ff17fed8eaaac8fbbebced1b72f
> > # Parent  6d1d516ecaade56f796e3216e9931fdcc12282cd
> > tools/xc: restore logging in xc_save
> > 
> > Prior to xen-4.1 the helper xc_save would print some progress during
> > migration. With the new xc_interface_open API no more messages were
> > printed because no logger was configured.
> > 
> > Restore previous behaviour by providing a logger. The progress in
> > xc_domain_save will be disabled because its output lacks a linefeed
> > which makes xend.log look ugly.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > diff -r 6d1d516ecaad -r d76b38b79929 tools/xcutils/xc_save.c
> > --- a/tools/xcutils/xc_save.c
> > +++ b/tools/xcutils/xc_save.c
> > @@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
> >  int
> >  main(int argc, char **argv)
> >  {
> > -    unsigned int maxit, max_f;
> > +    unsigned int maxit, max_f, lflags;
> >      int io_fd, ret, port;
> >      struct save_callbacks callbacks;
> > +    xentoollog_level lvl;
> > +    xentoollog_logger *l;
> >  
> >      if (argc != 6)
> >          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> >  
> > -    si.xch = xc_interface_open(0,0,0);
> > -    if (!si.xch)
> > -        errx(1, "failed to open control interface");
> > -
> >      io_fd = atoi(argv[1]);
> >      si.domid = atoi(argv[2]);
> >      maxit = atoi(argv[3]);
> > @@ -185,6 +183,13 @@ main(int argc, char **argv)
> >  
> >      si.suspend_evtchn = -1;
> >  
> > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> 
> Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> flag which makes it output something more suitable for logging,
> e.g. ...10%...20%...30%... 
> (or perhaps automatic based on isatty(outputfd)?)

It could be as simple as this tested patch, if its a logfile always
write a new line.

What do you think about this approach?

Olaf

tools/xc: handle tty output differently in stdiostream_progress

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d9b27c9c40a2 -r 5d7a62db6b3b tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -86,7 +86,7 @@ static void stdiostream_progress(struct 
                                  const char *doing_what, int percent,
                                  unsigned long done, unsigned long total) {
     xentoollog_logger_stdiostream *lg = (void*)logger_in;
-    int newpel, extra_erase;
+    int newpel, extra_erase, istty;
     xentoollog_level this_level;
 
     if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
@@ -105,7 +105,9 @@ static void stdiostream_progress(struct 
     if (this_level < lg->min_level)
         return;
 
-    if (lg->progress_erase_len)
+    istty = isatty(fileno(lg->f)) > 0;
+
+    if (istty && lg->progress_erase_len)
         putc('\r', lg->f);
 
     lg->progress_last_percent = percent;
@@ -113,10 +115,10 @@ static void stdiostream_progress(struct 
     newpel = fprintf(lg->f, "%s%s" "%s: %lu/%lu  %3d%%%s",
                      context?context:"", context?": ":"",
                      doing_what, done, total, percent,
-		     done == total ? "\n" : "");
+		     (done == total) || !istty ? "\n" : "");
 
     extra_erase = lg->progress_erase_len - newpel;
-    if (extra_erase > 0)
+    if (istty && extra_erase > 0)
         fprintf(lg->f, "%*s\r", extra_erase, "");
 
     lg->progress_erase_len = newpel;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 13:50:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 13:50: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 1U5cin-00055R-W2; Wed, 13 Feb 2013 13:50:01 +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 1U5cil-00055M-Pu
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 13:49:59 +0000
Received: from [85.158.143.35:40941] by server-3.bemta-4.messagelabs.com id
	DC/6B-08920-60A9B115; Wed, 13 Feb 2013 13:49:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360763250!12397880!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19519 invoked from network); 13 Feb 2013 13:47:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 13:47:32 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalMmrc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jorabe mo19) (RZmta 31.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C036cep1DDlLfZ ;
	Wed, 13 Feb 2013 14:47:30 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 437851884C; Wed, 13 Feb 2013 14:47:30 +0100 (CET)
Date: Wed, 13 Feb 2013 14:47:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130213134730.GA19050@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359972720.5281.20.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Mon, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 18:58 +0000, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1359745022 -3600
> > # Node ID d76b38b799293ff17fed8eaaac8fbbebced1b72f
> > # Parent  6d1d516ecaade56f796e3216e9931fdcc12282cd
> > tools/xc: restore logging in xc_save
> > 
> > Prior to xen-4.1 the helper xc_save would print some progress during
> > migration. With the new xc_interface_open API no more messages were
> > printed because no logger was configured.
> > 
> > Restore previous behaviour by providing a logger. The progress in
> > xc_domain_save will be disabled because its output lacks a linefeed
> > which makes xend.log look ugly.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > diff -r 6d1d516ecaad -r d76b38b79929 tools/xcutils/xc_save.c
> > --- a/tools/xcutils/xc_save.c
> > +++ b/tools/xcutils/xc_save.c
> > @@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
> >  int
> >  main(int argc, char **argv)
> >  {
> > -    unsigned int maxit, max_f;
> > +    unsigned int maxit, max_f, lflags;
> >      int io_fd, ret, port;
> >      struct save_callbacks callbacks;
> > +    xentoollog_level lvl;
> > +    xentoollog_logger *l;
> >  
> >      if (argc != 6)
> >          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> >  
> > -    si.xch = xc_interface_open(0,0,0);
> > -    if (!si.xch)
> > -        errx(1, "failed to open control interface");
> > -
> >      io_fd = atoi(argv[1]);
> >      si.domid = atoi(argv[2]);
> >      maxit = atoi(argv[3]);
> > @@ -185,6 +183,13 @@ main(int argc, char **argv)
> >  
> >      si.suspend_evtchn = -1;
> >  
> > +    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
> > +    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
> 
> Would it be useful (as an extension) to implement an XTL_STDIOSTREAM
> flag which makes it output something more suitable for logging,
> e.g. ...10%...20%...30%... 
> (or perhaps automatic based on isatty(outputfd)?)

It could be as simple as this tested patch, if its a logfile always
write a new line.

What do you think about this approach?

Olaf

tools/xc: handle tty output differently in stdiostream_progress

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d9b27c9c40a2 -r 5d7a62db6b3b tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -86,7 +86,7 @@ static void stdiostream_progress(struct 
                                  const char *doing_what, int percent,
                                  unsigned long done, unsigned long total) {
     xentoollog_logger_stdiostream *lg = (void*)logger_in;
-    int newpel, extra_erase;
+    int newpel, extra_erase, istty;
     xentoollog_level this_level;
 
     if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
@@ -105,7 +105,9 @@ static void stdiostream_progress(struct 
     if (this_level < lg->min_level)
         return;
 
-    if (lg->progress_erase_len)
+    istty = isatty(fileno(lg->f)) > 0;
+
+    if (istty && lg->progress_erase_len)
         putc('\r', lg->f);
 
     lg->progress_last_percent = percent;
@@ -113,10 +115,10 @@ static void stdiostream_progress(struct 
     newpel = fprintf(lg->f, "%s%s" "%s: %lu/%lu  %3d%%%s",
                      context?context:"", context?": ":"",
                      doing_what, done, total, percent,
-		     done == total ? "\n" : "");
+		     (done == total) || !istty ? "\n" : "");
 
     extra_erase = lg->progress_erase_len - newpel;
-    if (extra_erase > 0)
+    if (istty && extra_erase > 0)
         fprintf(lg->f, "%*s\r", extra_erase, "");
 
     lg->progress_erase_len = newpel;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 14:09:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 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 1U5d0w-0005Nq-PB; Wed, 13 Feb 2013 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 <ml-xen-devel@hfp.de>) id 1U5d0v-0005Nl-3j
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 14:08:45 +0000
Received: from [85.158.143.99:22436] by server-2.bemta-4.messagelabs.com id
	62/9A-01597-C6E9B115; Wed, 13 Feb 2013 14:08:44 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360764523!26461003!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28227 invoked from network); 13 Feb 2013 14:08:44 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 14:08:44 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 0FC38E255D;
	Wed, 13 Feb 2013 15:07:19 +0100 (CET)
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 WxR63oNTJcp1; Wed, 13 Feb 2013 15:07:18 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7823.dip.t-dialin.net [93.203.120.35])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Wed, 13 Feb 2013 15:07:18 +0100 (CET)
Message-ID: <511B9E6A.3010308@hfp.de>
Date: Wed, 13 Feb 2013 15:08:42 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511A45D0.4030806@hfp.de> <511A5937.3020101@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4F5@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3566D4F5@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 think Paul is right when he says

>Windows 8 doesn't actually shut down when you tell it to... It terminates all sessions
>apart from 0 (where services live) and then hibernates, so 'shutdown' is actually a lot
>more complex and error prone than it was before.

I clicked "shutdown" - Windows hibernates.



> James Harper <mailto:james.harper@bendigoit.com.au>
> Tuesday, 12. February 2013 23:19
>
> Were you actually hibernating at the time?
>
> James
> Andreas Kinzler <mailto:ml-xen-devel@hfp.de>
> Tuesday, 12. February 2013 16:01
>
> Maybe the WinDbg log may be helpful. Sees to have some connection to 
> hibernation?
>
>
> 1: kd> !analyze -v
> ******************************************************************************* 
>
> *                                                                             
> *
> *                        Bugcheck 
> Analysis                                    *
> *                                                                             
> *
> ******************************************************************************* 
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 14:09:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 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 1U5d0w-0005Nq-PB; Wed, 13 Feb 2013 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 <ml-xen-devel@hfp.de>) id 1U5d0v-0005Nl-3j
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 14:08:45 +0000
Received: from [85.158.143.99:22436] by server-2.bemta-4.messagelabs.com id
	62/9A-01597-C6E9B115; Wed, 13 Feb 2013 14:08:44 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360764523!26461003!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28227 invoked from network); 13 Feb 2013 14:08:44 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 14:08:44 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 0FC38E255D;
	Wed, 13 Feb 2013 15:07:19 +0100 (CET)
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 WxR63oNTJcp1; Wed, 13 Feb 2013 15:07:18 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7823.dip.t-dialin.net [93.203.120.35])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Wed, 13 Feb 2013 15:07:18 +0100 (CET)
Message-ID: <511B9E6A.3010308@hfp.de>
Date: Wed, 13 Feb 2013 15:08:42 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511A45D0.4030806@hfp.de> <511A5937.3020101@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4F5@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3566D4F5@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 think Paul is right when he says

>Windows 8 doesn't actually shut down when you tell it to... It terminates all sessions
>apart from 0 (where services live) and then hibernates, so 'shutdown' is actually a lot
>more complex and error prone than it was before.

I clicked "shutdown" - Windows hibernates.



> James Harper <mailto:james.harper@bendigoit.com.au>
> Tuesday, 12. February 2013 23:19
>
> Were you actually hibernating at the time?
>
> James
> Andreas Kinzler <mailto:ml-xen-devel@hfp.de>
> Tuesday, 12. February 2013 16:01
>
> Maybe the WinDbg log may be helpful. Sees to have some connection to 
> hibernation?
>
>
> 1: kd> !analyze -v
> ******************************************************************************* 
>
> *                                                                             
> *
> *                        Bugcheck 
> Analysis                                    *
> *                                                                             
> *
> ******************************************************************************* 
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 14:20:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 14: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 1U5dBU-0005eV-Jt; Wed, 13 Feb 2013 14:19:40 +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 1U5dBT-0005eN-Fc
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 14:19:39 +0000
Received: from [85.158.139.83:60657] by server-4.bemta-5.messagelabs.com id
	83/45-29496-AF0AB115; Wed, 13 Feb 2013 14:19:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360765149!25123113!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11732 invoked from network); 13 Feb 2013 14:19:09 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 14:19:09 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id C840B40046B;
	Wed, 13 Feb 2013 15:19:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GNvEMmgk9vpC; Wed, 13 Feb 2013 15:19:08 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id CA6854001C6;
	Wed, 13 Feb 2013 15:19:07 +0100 (CET)
Message-ID: <511BA0D7.8070809@tiscali.it>
Date: Wed, 13 Feb 2013 15:19:03 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	James Harper <james.harper@bendigoit.com.au>
Subject: [Xen-devel] GPLPV questions
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="===============7167974798724640501=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7167974798724640501==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020409010508090902060200"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020409010508090902060200
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I have tried to build gplpv from source with makedist.bat but it gave me =

some errors about files not found.
I saw that latest commits were big. Is there something incomplete and=20
must I wait other commits before build it?

I would like to see if new build fix network not working after restore=20
on windows domUs using upstream qemu.
Dom0 is wheezy with xen-unstable from source.
Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found=20
error on xen for now, probably is problem of gplpv with qemu upstream.
Linux hvm domUs seem not have that problem, tested with quantal (ubuntu=20
12.10) and network works also after restore.
If you need more details and tests tell me and I'll post it.

Another problem present on both traditional/upstream qemu  with=20
older/new xen and  older/new gplpv is domU's time not correctly updated=20
after restore (it remains the time at the save operation), this is a big =

problem with windows domUs (DC and client) in a windows domain where the =

time source is DC by default.

Thanks for any reply.


--------------ms020409010508090902060200
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxMzE0MTkwM1owIwYJKoZIhvcNAQkEMRYEFPZcHSkWsLgfOdnDA0J6WV7+
bzqxMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAX05jAZPgrEGfi/e0NRXv6rLr
2xTUkXIOgT+/vZtG0dNxA0/g44J18oRZl8gu/lOmj/yXiftloHJNINrKI0LZlXFn1qO2tdHK
a2WnyZnBYQGM9MTZ1dCmY4PhfHj10LM/uRzIZCiB3VsLYjZNA2zuZPXfCV5+s71iKrEgN9oC
qIaZ1yh3P2fznfm/9XxkXl0tbX2fnXN7fk1l0zEtNAVrbTEQXGZqoEdTNjVixbaYPLoRsqGv
LOhKjL9x3++hklVBQcmmAFjkd0tYTdgGW6N/1V8/S8XSx7adXAVAPXavjvrYVwgfxe7zAo5S
XqcFk8wjDnyDzn6VaFE74nMZz3iXeQAAAAAAAA==
--------------ms020409010508090902060200--


--===============7167974798724640501==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7167974798724640501==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 14:20:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 14: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 1U5dBU-0005eV-Jt; Wed, 13 Feb 2013 14:19:40 +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 1U5dBT-0005eN-Fc
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 14:19:39 +0000
Received: from [85.158.139.83:60657] by server-4.bemta-5.messagelabs.com id
	83/45-29496-AF0AB115; Wed, 13 Feb 2013 14:19:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360765149!25123113!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11732 invoked from network); 13 Feb 2013 14:19:09 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 14:19:09 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id C840B40046B;
	Wed, 13 Feb 2013 15:19:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GNvEMmgk9vpC; Wed, 13 Feb 2013 15:19:08 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id CA6854001C6;
	Wed, 13 Feb 2013 15:19:07 +0100 (CET)
Message-ID: <511BA0D7.8070809@tiscali.it>
Date: Wed, 13 Feb 2013 15:19:03 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	James Harper <james.harper@bendigoit.com.au>
Subject: [Xen-devel] GPLPV questions
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="===============7167974798724640501=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7167974798724640501==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020409010508090902060200"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020409010508090902060200
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I have tried to build gplpv from source with makedist.bat but it gave me =

some errors about files not found.
I saw that latest commits were big. Is there something incomplete and=20
must I wait other commits before build it?

I would like to see if new build fix network not working after restore=20
on windows domUs using upstream qemu.
Dom0 is wheezy with xen-unstable from source.
Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found=20
error on xen for now, probably is problem of gplpv with qemu upstream.
Linux hvm domUs seem not have that problem, tested with quantal (ubuntu=20
12.10) and network works also after restore.
If you need more details and tests tell me and I'll post it.

Another problem present on both traditional/upstream qemu  with=20
older/new xen and  older/new gplpv is domU's time not correctly updated=20
after restore (it remains the time at the save operation), this is a big =

problem with windows domUs (DC and client) in a windows domain where the =

time source is DC by default.

Thanks for any reply.


--------------ms020409010508090902060200
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxMzE0MTkwM1owIwYJKoZIhvcNAQkEMRYEFPZcHSkWsLgfOdnDA0J6WV7+
bzqxMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAX05jAZPgrEGfi/e0NRXv6rLr
2xTUkXIOgT+/vZtG0dNxA0/g44J18oRZl8gu/lOmj/yXiftloHJNINrKI0LZlXFn1qO2tdHK
a2WnyZnBYQGM9MTZ1dCmY4PhfHj10LM/uRzIZCiB3VsLYjZNA2zuZPXfCV5+s71iKrEgN9oC
qIaZ1yh3P2fznfm/9XxkXl0tbX2fnXN7fk1l0zEtNAVrbTEQXGZqoEdTNjVixbaYPLoRsqGv
LOhKjL9x3++hklVBQcmmAFjkd0tYTdgGW6N/1V8/S8XSx7adXAVAPXavjvrYVwgfxe7zAo5S
XqcFk8wjDnyDzn6VaFE74nMZz3iXeQAAAAAAAA==
--------------ms020409010508090902060200--


--===============7167974798724640501==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7167974798724640501==--


From xen-devel-bounces@lists.xen.org Wed Feb 13 14:23:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 14: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 1U5dEW-0005rs-E2; Wed, 13 Feb 2013 14:22:48 +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 1U5dEU-0005rZ-N6
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 14:22:46 +0000
Received: from [85.158.137.99:9973] by server-1.bemta-3.messagelabs.com id
	F1/04-08955-5B1AB115; Wed, 13 Feb 2013 14:22:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360765365!17868801!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11090 invoked from network); 13 Feb 2013 14:22:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 14:22:45 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalMmrc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jorabe mo8) (RZmta 31.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f032acp1DDHRdt ;
	Wed, 13 Feb 2013 15:22:44 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 44CA31884C; Wed, 13 Feb 2013 15:22:44 +0100 (CET)
Date: Wed, 13 Feb 2013 15:22:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130213142244.GB22106@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130213134730.GA19050@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213134730.GA19050@aepfle.de>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Wed, Feb 13, Olaf Hering wrote:

> What do you think about this approach?

I think its not perfect. If XTL_STDIOSTREAM_SHOW_PID or
XTL_STDIOSTREAM_SHOW_DATE is requested, then both will not be printed. I
will let stdiostream_vmessage print the message if the output is not a
tty.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 14:23:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 14: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 1U5dEW-0005rs-E2; Wed, 13 Feb 2013 14:22:48 +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 1U5dEU-0005rZ-N6
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 14:22:46 +0000
Received: from [85.158.137.99:9973] by server-1.bemta-3.messagelabs.com id
	F1/04-08955-5B1AB115; Wed, 13 Feb 2013 14:22:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360765365!17868801!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11090 invoked from network); 13 Feb 2013 14:22:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 14:22:45 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalMmrc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jorabe mo8) (RZmta 31.16 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f032acp1DDHRdt ;
	Wed, 13 Feb 2013 15:22:44 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 44CA31884C; Wed, 13 Feb 2013 15:22:44 +0100 (CET)
Date: Wed, 13 Feb 2013 15:22:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130213142244.GB22106@aepfle.de>
References: <d76b38b799293ff17fed.1359745100@probook.site>
	<1359972720.5281.20.camel@zakaz.uk.xensource.com>
	<20130213134730.GA19050@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213134730.GA19050@aepfle.de>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/xc: restore logging in xc_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

On Wed, Feb 13, Olaf Hering wrote:

> What do you think about this approach?

I think its not perfect. If XTL_STDIOSTREAM_SHOW_PID or
XTL_STDIOSTREAM_SHOW_DATE is requested, then both will not be printed. I
will let stdiostream_vmessage print the message if the output is not a
tty.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 14:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 14: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 1U5djk-0006N2-79; Wed, 13 Feb 2013 14:55:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1U5dji-0006Mx-Gd
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 14:55:02 +0000
Received: from [85.158.137.99:28859] by server-7.bemta-3.messagelabs.com id
	BB/1A-10367-549AB115; Wed, 13 Feb 2013 14:55:01 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360767293!12882383!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22270 invoked from network); 13 Feb 2013 14:55:00 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-3.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 14:55:00 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 60ACEE2573;
	Wed, 13 Feb 2013 15:53:15 +0100 (CET)
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 RW7Q5pG5tzDa; Wed, 13 Feb 2013 15:53:15 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7823.dip.t-dialin.net [93.203.120.35])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Wed, 13 Feb 2013 15:53:15 +0100 (CET)
Message-ID: <511BA92E.1040002@hfp.de>
Date: Wed, 13 Feb 2013 15:54:38 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

In the meantime I disabled hibernation (powercfg.exe -h off) and it 
seems to work now. Which revision from your repo do you wish to be 
tested? I am interested in testing, but my time is somewhat limited - I 
cannot make any promise.

As I said in my original post, rev956 works quite well with its core 
operations: net IO and disk IO.

Regards Andreas
> James Harper <mailto:james.harper@bendigoit.com.au>
> Tuesday, 12. February 2013 23:19
>
> I have only tested with Windows 2012 but it shouldn't be any different 
> to 8. My testing was pretty much limited to 'does it boot' testing, 
> but I don't recall having any problems with shutdown or anything.
>
> Are you interested in trying the very latest version? I've been doing 
> a fairly major update in the way the child devices talk to the bus 
> driver and it is now at a point where everything should be working but 
> I haven't done a lot of testing yet.
>
> James
> Andreas Kinzler <mailto:ml-xen-devel@hfp.de>
> Tuesday, 12. February 2013 14:38
> What is the state of GPLPV and Windows 8? I am currently running tests 
> with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look 
> good. There seems to be a problem with shutdown/reboot where Windows 
> hangs somewhat and displays a warning about improper shutdown on next 
> reboot.
>
> Regards Andreas
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 13 14:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 14: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 1U5djk-0006N2-79; Wed, 13 Feb 2013 14:55:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1U5dji-0006Mx-Gd
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 14:55:02 +0000
Received: from [85.158.137.99:28859] by server-7.bemta-3.messagelabs.com id
	BB/1A-10367-549AB115; Wed, 13 Feb 2013 14:55:01 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360767293!12882383!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22270 invoked from network); 13 Feb 2013 14:55:00 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-3.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 14:55:00 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 60ACEE2573;
	Wed, 13 Feb 2013 15:53:15 +0100 (CET)
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 RW7Q5pG5tzDa; Wed, 13 Feb 2013 15:53:15 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7823.dip.t-dialin.net [93.203.120.35])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Wed, 13 Feb 2013 15:53:15 +0100 (CET)
Message-ID: <511BA92E.1040002@hfp.de>
Date: Wed, 13 Feb 2013 15:54:38 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Postbox 3.0.7 (Windows/20130120)
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

In the meantime I disabled hibernation (powercfg.exe -h off) and it 
seems to work now. Which revision from your repo do you wish to be 
tested? I am interested in testing, but my time is somewhat limited - I 
cannot make any promise.

As I said in my original post, rev956 works quite well with its core 
operations: net IO and disk IO.

Regards Andreas
> James Harper <mailto:james.harper@bendigoit.com.au>
> Tuesday, 12. February 2013 23:19
>
> I have only tested with Windows 2012 but it shouldn't be any different 
> to 8. My testing was pretty much limited to 'does it boot' testing, 
> but I don't recall having any problems with shutdown or anything.
>
> Are you interested in trying the very latest version? I've been doing 
> a fairly major update in the way the child devices talk to the bus 
> driver and it is now at a point where everything should be working but 
> I haven't done a lot of testing yet.
>
> James
> Andreas Kinzler <mailto:ml-xen-devel@hfp.de>
> Tuesday, 12. February 2013 14:38
> What is the state of GPLPV and Windows 8? I am currently running tests 
> with Windows 8 and GPLPV rev956 and operations (disk IO, net IO) look 
> good. There seems to be a problem with shutdown/reboot where Windows 
> hangs somewhat and displays a warning about improper shutdown on next 
> reboot.
>
> Regards Andreas
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 13 15:19:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:19: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 1U5e78-0006ke-JX; Wed, 13 Feb 2013 15:19:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5e76-0006kX-UA
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:19:13 +0000
Received: from [85.158.138.51:10216] by server-11.bemta-3.messagelabs.com id
	F8/EE-10249-FEEAB115; Wed, 13 Feb 2013 15:19:11 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360768751!19482252!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32587 invoked from network); 13 Feb 2013 15:19:11 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	13 Feb 2013 15:19:11 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 07CEAC56195;
	Wed, 13 Feb 2013 15:18:59 +0000 (GMT)
Date: Wed, 13 Feb 2013 15:18:59 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <BD58EB8228181B9B1EA93797@Ximines.local>
In-Reply-To: <20763.34351.854483.320275@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
	<20762.25460.618127.856037@mariner.uk.xensource.com>
	<D66675BF9FE63A7F8D0FE7D3@nimrod.local>
	<20763.34351.854483.320275@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

>> I can reorder patch 11 so it precedes patch 10 if you want. It's only
>> there as I found the bug in patch 11 later. Tell me if you want me to
>> do this.
>
> That would be best, I think.

OK will do.

> My concern is only whether turning an existing specifically-diagnosed
> failure into a more general one is acceptable, under these
> circumstances.  TBH I'm inclined to think it is in this case but I
> wanted to give you and others a chance to comment.

Agree.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:19:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:19: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 1U5e78-0006ke-JX; Wed, 13 Feb 2013 15:19:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5e76-0006kX-UA
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:19:13 +0000
Received: from [85.158.138.51:10216] by server-11.bemta-3.messagelabs.com id
	F8/EE-10249-FEEAB115; Wed, 13 Feb 2013 15:19:11 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360768751!19482252!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32587 invoked from network); 13 Feb 2013 15:19:11 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	13 Feb 2013 15:19:11 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 07CEAC56195;
	Wed, 13 Feb 2013 15:18:59 +0000 (GMT)
Date: Wed, 13 Feb 2013 15:18:59 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <BD58EB8228181B9B1EA93797@Ximines.local>
In-Reply-To: <20763.34351.854483.320275@mariner.uk.xensource.com>
References: <1358618288-17109-1-git-send-email-alex@alex.org.uk>
	<1358618288-17109-11-git-send-email-alex@alex.org.uk>
	<20762.25047.686468.319085@mariner.uk.xensource.com>
	<20762.25460.618127.856037@mariner.uk.xensource.com>
	<D66675BF9FE63A7F8D0FE7D3@nimrod.local>
	<20763.34351.854483.320275@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

>> I can reorder patch 11 so it precedes patch 10 if you want. It's only
>> there as I found the bug in patch 11 later. Tell me if you want me to
>> do this.
>
> That would be best, I think.

OK will do.

> My concern is only whether turning an existing specifically-diagnosed
> failure into a more general one is acceptable, under these
> circumstances.  TBH I'm inclined to think it is in this case but I
> wanted to give you and others a chance to comment.

Agree.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:53: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 1U5edy-00079f-Hh; Wed, 13 Feb 2013 15:53: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 1U5edx-00078u-B5
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:09 +0000
Received: from [85.158.143.35:24974] by server-3.bemta-4.messagelabs.com id
	4B/D8-08920-5E6BB115; Wed, 13 Feb 2013 15:53:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360770784!15665751!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo9) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m027edp1DFYbbi
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id F1B1A189BA
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3bcbdd2cc6079a93ed7f4c335b86bfa34c3ae4e1
Message-Id: <3bcbdd2cc6079a93ed7f.1360770785@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 7] libxl: pass debug flag down to
	libxl_domain_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360770325 -3600
# Node ID 3bcbdd2cc6079a93ed7f4c335b86bfa34c3ae4e1
# Parent  de60f1266f051fd54155ca1b149dd8c9bf64f2dc
libxl: pass debug flag down to libxl_domain_suspend

libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
and xl migrate handles the -d switch as well. Pass this flag down to
libxl_domain_suspend, so that finally xc_domain_save can dump huge
amount of debug data to stdout.
Update xl.1 and help text output.

v4:
 - change -d to --debug

v3:
 - require 3 -d options to really enable it

v2:
 - fix xl.1 option, really use -d instead of -e

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r de60f1266f05 -r 3bcbdd2cc607 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -387,6 +387,10 @@ domain. See the corresponding option of 
 
 Send <config> instead of config file from creation.
 
+=item B<--debug>
+
+Print huge (!) amount of debug during the migration process.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r de60f1266f05 -r 3bcbdd2cc607 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3331,7 +3331,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune, int debug,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3340,7 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len;
+    int config_len, flags = LIBXL_SUSPEND_LIVE;
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3358,7 +3358,9 @@ static void migrate_domain(uint32_t domi
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
+    if (debug)
+        flags |= LIBXL_SUSPEND_DEBUG;
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3751,8 +3753,13 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    static struct option opts[] = {
+        {"debug", 0, 0, 0x100},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:e", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3766,7 +3773,7 @@ int main_migrate(int argc, char **argv)
         daemonize = 0;
         monitor = 0;
         break;
-    case 'd':
+    case 0x100:
         debug = 1;
         break;
     }
@@ -3784,7 +3791,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, config_filename);
+    migrate_domain(domid, rune, debug, config_filename);
     return 0;
 }
 
diff -r de60f1266f05 -r 3bcbdd2cc607 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
       "                to sh. If empty, run <host> instead of ssh <host> xl\n"
       "                migrate-receive [-d -e]\n"
       "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain."
+      "                of the domain.\n"
+      "--debug         Print huge (!) amount of debug during the migration process."
     },
     { "dump-core",
       &main_dump_core, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:53: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 1U5edy-00079f-Hh; Wed, 13 Feb 2013 15:53: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 1U5edx-00078u-B5
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:09 +0000
Received: from [85.158.143.35:24974] by server-3.bemta-4.messagelabs.com id
	4B/D8-08920-5E6BB115; Wed, 13 Feb 2013 15:53:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360770784!15665751!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo9) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m027edp1DFYbbi
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id F1B1A189BA
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3bcbdd2cc6079a93ed7f4c335b86bfa34c3ae4e1
Message-Id: <3bcbdd2cc6079a93ed7f.1360770785@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 7] libxl: pass debug flag down to
	libxl_domain_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360770325 -3600
# Node ID 3bcbdd2cc6079a93ed7f4c335b86bfa34c3ae4e1
# Parent  de60f1266f051fd54155ca1b149dd8c9bf64f2dc
libxl: pass debug flag down to libxl_domain_suspend

libxl_domain_suspend is already prepared to handle LIBXL_SUSPEND_DEBUG,
and xl migrate handles the -d switch as well. Pass this flag down to
libxl_domain_suspend, so that finally xc_domain_save can dump huge
amount of debug data to stdout.
Update xl.1 and help text output.

v4:
 - change -d to --debug

v3:
 - require 3 -d options to really enable it

v2:
 - fix xl.1 option, really use -d instead of -e

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r de60f1266f05 -r 3bcbdd2cc607 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -387,6 +387,10 @@ domain. See the corresponding option of 
 
 Send <config> instead of config file from creation.
 
+=item B<--debug>
+
+Print huge (!) amount of debug during the migration process.
+
 =back
 
 =item B<remus> [I<OPTIONS>] I<domain-id> I<host>
diff -r de60f1266f05 -r 3bcbdd2cc607 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3331,7 +3331,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(uint32_t domid, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune, int debug,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3340,7 +3340,7 @@ static void migrate_domain(uint32_t domi
     char *away_domname;
     char rc_buf;
     uint8_t *config_data;
-    int config_len;
+    int config_len, flags = LIBXL_SUSPEND_LIVE;
 
     save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
@@ -3358,7 +3358,9 @@ static void migrate_domain(uint32_t domi
 
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
-    rc = libxl_domain_suspend(ctx, domid, send_fd, LIBXL_SUSPEND_LIVE, NULL);
+    if (debug)
+        flags |= LIBXL_SUSPEND_DEBUG;
+    rc = libxl_domain_suspend(ctx, domid, send_fd, flags, NULL);
     if (rc) {
         fprintf(stderr, "migration sender: libxl_domain_suspend failed"
                 " (rc=%d)\n", rc);
@@ -3751,8 +3753,13 @@ int main_migrate(int argc, char **argv)
     char *rune = NULL;
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
-
-    SWITCH_FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    static struct option opts[] = {
+        {"debug", 0, 0, 0x100},
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    SWITCH_FOREACH_OPT(opt, "FC:s:e", opts, "migrate", 2) {
     case 'C':
         config_filename = optarg;
         break;
@@ -3766,7 +3773,7 @@ int main_migrate(int argc, char **argv)
         daemonize = 0;
         monitor = 0;
         break;
-    case 'd':
+    case 0x100:
         debug = 1;
         break;
     }
@@ -3784,7 +3791,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(domid, rune, config_filename);
+    migrate_domain(domid, rune, debug, config_filename);
     return 0;
 }
 
diff -r de60f1266f05 -r 3bcbdd2cc607 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -153,7 +153,8 @@ struct cmd_spec cmd_table[] = {
       "                to sh. If empty, run <host> instead of ssh <host> xl\n"
       "                migrate-receive [-d -e]\n"
       "-e              Do not wait in the background (on <host>) for the death\n"
-      "                of the domain."
+      "                of the domain.\n"
+      "--debug         Print huge (!) amount of debug during the migration process."
     },
     { "dump-core",
       &main_dump_core, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:53: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 1U5edy-00079S-3W; Wed, 13 Feb 2013 15:53: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 1U5edw-00078u-Qj
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:09 +0000
Received: from [85.158.143.35:21099] by server-3.bemta-4.messagelabs.com id
	D6/D8-08920-4E6BB115; Wed, 13 Feb 2013 15:53:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360770783!15665749!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16053 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (joses mo16) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L03db1p1DFjfQN
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2E62D189BA
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1518e1b1341a56e8ea52c7fbaa56a7c062e559a5
Message-Id: <1518e1b1341a56e8ea52.1360770780@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output differently
 in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360769525 -3600
# Node ID 1518e1b1341a56e8ea52c7fbaa56a7c062e559a5
# Parent  d13841ebeb080e3dea9b865d79e194e81d6aa2db
tools/xc: handle tty output differently in stdiostream_progress

If the output goes to a tty, rewind the cursor and print everything in a
single line as it was done up to now. If the output goes to a file or
pipe print a newline after each progress output. This will fix logging
of progress messages from xc_save to xend.log.

To support XTL_STDIOSTREAM_SHOW_PID or XTL_STDIOSTREAM_SHOW_DATE print
the output via vmessage if the output is not a tty.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d13841ebeb08 -r 1518e1b1341a tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -81,6 +81,17 @@ static void stdiostream_vmessage(xentool
     fflush(lg->f);
 }
 
+static void stdiostream_message(struct xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                const char *context,
+                                const char *format, ...)
+{
+    va_list al;
+    va_start(al,format);
+    stdiostream_vmessage(logger_in, level, -1, context, format, al);
+    va_end(al);
+}
+
 static void stdiostream_progress(struct xentoollog_logger *logger_in,
                                  const char *context,
                                  const char *doing_what, int percent,
@@ -105,11 +116,18 @@ static void stdiostream_progress(struct 
     if (this_level < lg->min_level)
         return;
 
+    lg->progress_last_percent = percent;
+
+    if (isatty(fileno(lg->f)) <= 0) {
+        stdiostream_message(logger_in, this_level, context,
+                            "%s: %lu/%lu  %3d%%",
+                            doing_what, done, total, percent);
+        return;
+    }
+
     if (lg->progress_erase_len)
         putc('\r', lg->f);
 
-    lg->progress_last_percent = percent;
-
     newpel = fprintf(lg->f, "%s%s" "%s: %lu/%lu  %3d%%%s",
                      context?context:"", context?": ":"",
                      doing_what, done, total, percent,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:53: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 1U5edy-00079S-3W; Wed, 13 Feb 2013 15:53: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 1U5edw-00078u-Qj
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:09 +0000
Received: from [85.158.143.35:21099] by server-3.bemta-4.messagelabs.com id
	D6/D8-08920-4E6BB115; Wed, 13 Feb 2013 15:53:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360770783!15665749!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16053 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (joses mo16) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L03db1p1DFjfQN
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2E62D189BA
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1518e1b1341a56e8ea52c7fbaa56a7c062e559a5
Message-Id: <1518e1b1341a56e8ea52.1360770780@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output differently
 in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360769525 -3600
# Node ID 1518e1b1341a56e8ea52c7fbaa56a7c062e559a5
# Parent  d13841ebeb080e3dea9b865d79e194e81d6aa2db
tools/xc: handle tty output differently in stdiostream_progress

If the output goes to a tty, rewind the cursor and print everything in a
single line as it was done up to now. If the output goes to a file or
pipe print a newline after each progress output. This will fix logging
of progress messages from xc_save to xend.log.

To support XTL_STDIOSTREAM_SHOW_PID or XTL_STDIOSTREAM_SHOW_DATE print
the output via vmessage if the output is not a tty.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d13841ebeb08 -r 1518e1b1341a tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -81,6 +81,17 @@ static void stdiostream_vmessage(xentool
     fflush(lg->f);
 }
 
+static void stdiostream_message(struct xentoollog_logger *logger_in,
+                                xentoollog_level level,
+                                const char *context,
+                                const char *format, ...)
+{
+    va_list al;
+    va_start(al,format);
+    stdiostream_vmessage(logger_in, level, -1, context, format, al);
+    va_end(al);
+}
+
 static void stdiostream_progress(struct xentoollog_logger *logger_in,
                                  const char *context,
                                  const char *doing_what, int percent,
@@ -105,11 +116,18 @@ static void stdiostream_progress(struct 
     if (this_level < lg->min_level)
         return;
 
+    lg->progress_last_percent = percent;
+
+    if (isatty(fileno(lg->f)) <= 0) {
+        stdiostream_message(logger_in, this_level, context,
+                            "%s: %lu/%lu  %3d%%",
+                            doing_what, done, total, percent);
+        return;
+    }
+
     if (lg->progress_erase_len)
         putc('\r', lg->f);
 
-    lg->progress_last_percent = percent;
-
     newpel = fprintf(lg->f, "%s%s" "%s: %lu/%lu  %3d%%%s",
                      context?context:"", context?": ":"",
                      doing_what, done, total, percent,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edw-000790-M5; Wed, 13 Feb 2013 15:53: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 1U5edu-00078T-Qf
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:06 +0000
Received: from [85.158.143.99:24713] by server-2.bemta-4.messagelabs.com id
	E4/3A-01597-1E6BB115; Wed, 13 Feb 2013 15:53:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360770784!20352168!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8582 invoked from network); 13 Feb 2013 15:53:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:05 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (joses mo15) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U03d5cp1DEsYj0
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D83231884C
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: de60f1266f051fd54155ca1b149dd8c9bf64f2dc
Message-Id: <de60f1266f051fd54155.1360770784@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 7] xl: correct help text of xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360770321 -3600
# Node ID de60f1266f051fd54155ca1b149dd8c9bf64f2dc
# Parent  101ba725b5a58323c34a1944d7d24f600aaf48d5
xl: correct help text of xl migrate

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 101ba725b5a5 -r de60f1266f05 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -145,7 +145,7 @@ struct cmd_spec cmd_table[] = {
     },
     { "migrate",
       &main_migrate, 0, 1,
-      "Save a domain state to restore later",
+      "Migrate a domain to another host",
       "[options] <Domain> <host>",
       "-h              Print this help.\n"
       "-C <config>     Send <config> instead of config file from creation.\n"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edw-000790-M5; Wed, 13 Feb 2013 15:53: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 1U5edu-00078T-Qf
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:06 +0000
Received: from [85.158.143.99:24713] by server-2.bemta-4.messagelabs.com id
	E4/3A-01597-1E6BB115; Wed, 13 Feb 2013 15:53:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360770784!20352168!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8582 invoked from network); 13 Feb 2013 15:53:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:05 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (joses mo15) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U03d5cp1DEsYj0
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D83231884C
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: de60f1266f051fd54155ca1b149dd8c9bf64f2dc
Message-Id: <de60f1266f051fd54155.1360770784@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 7] xl: correct help text of xl migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360770321 -3600
# Node ID de60f1266f051fd54155ca1b149dd8c9bf64f2dc
# Parent  101ba725b5a58323c34a1944d7d24f600aaf48d5
xl: correct help text of xl migrate

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 101ba725b5a5 -r de60f1266f05 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -145,7 +145,7 @@ struct cmd_spec cmd_table[] = {
     },
     { "migrate",
       &main_migrate, 0, 1,
-      "Save a domain state to restore later",
+      "Migrate a domain to another host",
       "[options] <Domain> <host>",
       "-h              Print this help.\n"
       "-C <config>     Send <config> instead of config file from creation.\n"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edu-00078U-Ef; Wed, 13 Feb 2013 15:53:06 +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 1U5edt-00078I-4n
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:05 +0000
Received: from [193.109.254.147:40198] by server-10.bemta-14.messagelabs.com
	id 98/50-12679-0E6BB115; Wed, 13 Feb 2013 15:53:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360770783!2709621!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22922 invoked from network); 13 Feb 2013 15:53:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:03 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (josoe mo50) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z024bap1DF1M0C
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E43E31863F
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:02 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:52:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 7] various changes for xm migrate logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xc: fix logic error in stdiostream_progress
tools/xc: handle tty output differently in stdiostream_progress
tools/xc: turn XCFLAGS_* into shifts
tools/xc: restore logging in xc_save
tools/xc: log pid in xc_save/xc_restore output
xl: correct help text of xl migrate
libxl: pass debug flag down to libxl_domain_suspend

 docs/man/xl.pod.1               |    4 ++++
 tools/libxc/xc_domain_restore.c |    6 ++++--
 tools/libxc/xc_domain_save.c    |    4 +++-
 tools/libxc/xenguest.h          |   11 ++++++-----
 tools/libxc/xtl_logger_stdio.c  |   24 +++++++++++++++++++++---
 tools/libxl/xl_cmdimpl.c        |   21 ++++++++++++++-------
 tools/libxl/xl_cmdtable.c       |    5 +++--
 tools/xcutils/xc_restore.c      |    9 +++++++--
 tools/xcutils/xc_save.c         |   15 ++++++++++-----
 9 files changed, 72 insertions(+), 27 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edu-00078U-Ef; Wed, 13 Feb 2013 15:53:06 +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 1U5edt-00078I-4n
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:05 +0000
Received: from [193.109.254.147:40198] by server-10.bemta-14.messagelabs.com
	id 98/50-12679-0E6BB115; Wed, 13 Feb 2013 15:53:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360770783!2709621!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22922 invoked from network); 13 Feb 2013 15:53:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:03 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (josoe mo50) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z024bap1DF1M0C
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E43E31863F
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:02 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:52:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 7] various changes for xm migrate logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xc: fix logic error in stdiostream_progress
tools/xc: handle tty output differently in stdiostream_progress
tools/xc: turn XCFLAGS_* into shifts
tools/xc: restore logging in xc_save
tools/xc: log pid in xc_save/xc_restore output
xl: correct help text of xl migrate
libxl: pass debug flag down to libxl_domain_suspend

 docs/man/xl.pod.1               |    4 ++++
 tools/libxc/xc_domain_restore.c |    6 ++++--
 tools/libxc/xc_domain_save.c    |    4 +++-
 tools/libxc/xenguest.h          |   11 ++++++-----
 tools/libxc/xtl_logger_stdio.c  |   24 +++++++++++++++++++++---
 tools/libxl/xl_cmdimpl.c        |   21 ++++++++++++++-------
 tools/libxl/xl_cmdtable.c       |    5 +++--
 tools/xcutils/xc_restore.c      |    9 +++++++--
 tools/xcutils/xc_save.c         |   15 ++++++++++-----
 9 files changed, 72 insertions(+), 27 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edu-00078b-SC; Wed, 13 Feb 2013 15:53: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 1U5edt-00078J-DO
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:05 +0000
Received: from [85.158.139.83:64228] by server-16.bemta-5.messagelabs.com id
	3F/72-14948-0E6BB115; Wed, 13 Feb 2013 15:53:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360770783!24820704!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5993 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo49) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y03113p1DFJ3jg
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0CF221884C
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d13841ebeb080e3dea9b865d79e194e81d6aa2db
Message-Id: <d13841ebeb080e3dea9b.1360770779@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:52:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 7] tools/xc: fix logic error in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360769518 -3600
# Node ID d13841ebeb080e3dea9b865d79e194e81d6aa2db
# Parent  63594ce1708ffb1269cd124c3a864485eeba1736
tools/xc: fix logic error in stdiostream_progress

Setting XTL_STDIOSTREAM_HIDE_PROGRESS should disable progress reporting.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 63594ce1708f -r d13841ebeb08 tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -89,7 +89,7 @@ static void stdiostream_progress(struct 
     int newpel, extra_erase;
     xentoollog_level this_level;
 
-    if (!(lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS))
+    if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
         return;
 
     if (percent < lg->progress_last_percent) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edu-00078b-SC; Wed, 13 Feb 2013 15:53: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 1U5edt-00078J-DO
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:05 +0000
Received: from [85.158.139.83:64228] by server-16.bemta-5.messagelabs.com id
	3F/72-14948-0E6BB115; Wed, 13 Feb 2013 15:53:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360770783!24820704!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5993 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo49) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y03113p1DFJ3jg
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0CF221884C
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d13841ebeb080e3dea9b865d79e194e81d6aa2db
Message-Id: <d13841ebeb080e3dea9b.1360770779@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:52:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 7] tools/xc: fix logic error in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360769518 -3600
# Node ID d13841ebeb080e3dea9b865d79e194e81d6aa2db
# Parent  63594ce1708ffb1269cd124c3a864485eeba1736
tools/xc: fix logic error in stdiostream_progress

Setting XTL_STDIOSTREAM_HIDE_PROGRESS should disable progress reporting.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 63594ce1708f -r d13841ebeb08 tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -89,7 +89,7 @@ static void stdiostream_progress(struct 
     int newpel, extra_erase;
     xentoollog_level this_level;
 
-    if (!(lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS))
+    if (lg->flags & XTL_STDIOSTREAM_HIDE_PROGRESS)
         return;
 
     if (percent < lg->progress_last_percent) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edw-00078q-9E; Wed, 13 Feb 2013 15:53: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 1U5edu-00078S-Jg
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:06 +0000
Received: from [85.158.138.51:37899] by server-10.bemta-3.messagelabs.com id
	DD/85-10609-1E6BB115; Wed, 13 Feb 2013 15:53:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360770784!25673353!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10238 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo49) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y03113p1DFJ3jo
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9AA3D189BC
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 101ba725b5a58323c34a1944d7d24f600aaf48d5
Message-Id: <101ba725b5a58323c34a.1360770783@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 7] tools/xc: log pid in xc_save/xc_restore
	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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360770273 -3600
# Node ID 101ba725b5a58323c34a1944d7d24f600aaf48d5
# Parent  0e6a41e1ee36237ba130959dc3d2a3bd44104eb0
tools/xc: log pid in xc_save/xc_restore output

If several migrations log their output to xend.log its not clear which
line belongs to a which guest. Print entry/exit of xc_save and
xc_restore and also request to print pid with each log call.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1456,6 +1456,8 @@ int xc_domain_restore(xc_interface *xch,
     struct restore_ctx *ctx = &_ctx;
     struct domain_info_context *dinfo = &ctx->dinfo;
 
+    DPRINTF("%s: starting restore of new domid %u", __func__, dom);
+
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
@@ -1485,7 +1487,7 @@ int xc_domain_restore(xc_interface *xch,
         PERROR("read: p2m_size");
         goto out;
     }
-    DPRINTF("xc_domain_restore start: p2m_size = %lx\n", dinfo->p2m_size);
+    DPRINTF("%s: p2m_size = %lx\n", __func__, dinfo->p2m_size);
 
     if ( !get_platform_info(xch, dom,
                             &ctx->max_mfn, &ctx->hvirt_start, &ctx->pt_levels, &dinfo->guest_width) )
@@ -2300,7 +2302,7 @@ int xc_domain_restore(xc_interface *xch,
 
     fcntl(io_fd, F_SETFL, orig_io_fd_flags);
 
-    DPRINTF("Restore exit with rc=%d\n", rc);
+    DPRINTF("Restore exit of domid %u with rc=%d\n", dom, rc);
 
     return rc;
 }
diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -888,6 +888,8 @@ int xc_domain_save(xc_interface *xch, in
 
     int completed = 0;
 
+    DPRINTF("%s: starting save of domid %u", __func__, dom);
+
     if ( hvm && !callbacks->switch_qemu_logdirty )
     {
         ERROR("No switch_qemu_logdirty callback provided.");
@@ -2121,7 +2123,7 @@ int xc_domain_save(xc_interface *xch, in
     free(pfn_err);
     free(to_fix);
 
-    DPRINTF("Save exit rc=%d\n",rc);
+    DPRINTF("Save exit of domid %u with rc=%d\n", dom, rc);
 
     return !!rc;
 }
diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -19,17 +19,22 @@ int
 main(int argc, char **argv)
 {
     unsigned int domid, store_evtchn, console_evtchn;
-    unsigned int hvm, pae, apic;
+    unsigned int hvm, pae, apic, lflags;
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
     unsigned long store_mfn, console_mfn;
+    xentoollog_level lvl;
+    xentoollog_logger *l;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
              "console_evtchn hvm pae apic [superpages]", argv[0]);
 
-    xch = xc_interface_open(0,0,0);
+    lvl = XTL_DETAIL;
+    lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
+    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
+    xch = xc_interface_open(l, 0, 0);
     if ( !xch )
         errx(1, "failed to open control interface");
 
diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -184,7 +184,7 @@ main(int argc, char **argv)
     si.suspend_evtchn = -1;
 
     lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
-    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
+    lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
     l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
     si.xch = xc_interface_open(l, 0, 0);
     if (!si.xch)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5edw-00078q-9E; Wed, 13 Feb 2013 15:53: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 1U5edu-00078S-Jg
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:06 +0000
Received: from [85.158.138.51:37899] by server-10.bemta-3.messagelabs.com id
	DD/85-10609-1E6BB115; Wed, 13 Feb 2013 15:53:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1360770784!25673353!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10238 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo49) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y03113p1DFJ3jo
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9AA3D189BC
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 101ba725b5a58323c34a1944d7d24f600aaf48d5
Message-Id: <101ba725b5a58323c34a.1360770783@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 7] tools/xc: log pid in xc_save/xc_restore
	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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360770273 -3600
# Node ID 101ba725b5a58323c34a1944d7d24f600aaf48d5
# Parent  0e6a41e1ee36237ba130959dc3d2a3bd44104eb0
tools/xc: log pid in xc_save/xc_restore output

If several migrations log their output to xend.log its not clear which
line belongs to a which guest. Print entry/exit of xc_save and
xc_restore and also request to print pid with each log call.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1456,6 +1456,8 @@ int xc_domain_restore(xc_interface *xch,
     struct restore_ctx *ctx = &_ctx;
     struct domain_info_context *dinfo = &ctx->dinfo;
 
+    DPRINTF("%s: starting restore of new domid %u", __func__, dom);
+
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
@@ -1485,7 +1487,7 @@ int xc_domain_restore(xc_interface *xch,
         PERROR("read: p2m_size");
         goto out;
     }
-    DPRINTF("xc_domain_restore start: p2m_size = %lx\n", dinfo->p2m_size);
+    DPRINTF("%s: p2m_size = %lx\n", __func__, dinfo->p2m_size);
 
     if ( !get_platform_info(xch, dom,
                             &ctx->max_mfn, &ctx->hvirt_start, &ctx->pt_levels, &dinfo->guest_width) )
@@ -2300,7 +2302,7 @@ int xc_domain_restore(xc_interface *xch,
 
     fcntl(io_fd, F_SETFL, orig_io_fd_flags);
 
-    DPRINTF("Restore exit with rc=%d\n", rc);
+    DPRINTF("Restore exit of domid %u with rc=%d\n", dom, rc);
 
     return rc;
 }
diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -888,6 +888,8 @@ int xc_domain_save(xc_interface *xch, in
 
     int completed = 0;
 
+    DPRINTF("%s: starting save of domid %u", __func__, dom);
+
     if ( hvm && !callbacks->switch_qemu_logdirty )
     {
         ERROR("No switch_qemu_logdirty callback provided.");
@@ -2121,7 +2123,7 @@ int xc_domain_save(xc_interface *xch, in
     free(pfn_err);
     free(to_fix);
 
-    DPRINTF("Save exit rc=%d\n",rc);
+    DPRINTF("Save exit of domid %u with rc=%d\n", dom, rc);
 
     return !!rc;
 }
diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -19,17 +19,22 @@ int
 main(int argc, char **argv)
 {
     unsigned int domid, store_evtchn, console_evtchn;
-    unsigned int hvm, pae, apic;
+    unsigned int hvm, pae, apic, lflags;
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
     unsigned long store_mfn, console_mfn;
+    xentoollog_level lvl;
+    xentoollog_logger *l;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
              "console_evtchn hvm pae apic [superpages]", argv[0]);
 
-    xch = xc_interface_open(0,0,0);
+    lvl = XTL_DETAIL;
+    lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
+    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
+    xch = xc_interface_open(l, 0, 0);
     if ( !xch )
         errx(1, "failed to open control interface");
 
diff -r 0e6a41e1ee36 -r 101ba725b5a5 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -184,7 +184,7 @@ main(int argc, char **argv)
     si.suspend_evtchn = -1;
 
     lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
-    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
+    lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
     l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
     si.xch = xc_interface_open(l, 0, 0);
     if (!si.xch)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:53: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 1U5eeJ-0007Ff-5i; Wed, 13 Feb 2013 15:53:31 +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 1U5eeH-0007Dt-Pf
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:29 +0000
Received: from [85.158.143.35:25668] by server-3.bemta-4.messagelabs.com id
	17/49-08920-9F6BB115; Wed, 13 Feb 2013 15:53:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360770784!13148685!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo27) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k02bb9p1DFAwrK
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 54D64189BB
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8958163de4026b150a2fbb8fd7fa496941e22d0d
Message-Id: <8958163de4026b150a2f.1360770781@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 7] tools/xc: turn XCFLAGS_* into shifts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360769530 -3600
# Node ID 8958163de4026b150a2fbb8fd7fa496941e22d0d
# Parent  1518e1b1341a56e8ea52c7fbaa56a7c062e559a5
tools/xc: turn XCFLAGS_* into shifts

to make it clear that these are bits and to make it easier to use in
xend code.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1518e1b1341a -r 8958163de402 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -23,11 +23,12 @@
 #ifndef XENGUEST_H
 #define XENGUEST_H
 
-#define XCFLAGS_LIVE      1
-#define XCFLAGS_DEBUG     2
-#define XCFLAGS_HVM       4
-#define XCFLAGS_STDVGA    8
-#define XCFLAGS_CHECKPOINT_COMPRESS    16
+#define XCFLAGS_LIVE      (1 << 0)
+#define XCFLAGS_DEBUG     (1 << 1)
+#define XCFLAGS_HVM       (1 << 2)
+#define XCFLAGS_STDVGA    (1 << 3)
+#define XCFLAGS_CHECKPOINT_COMPRESS    (1 << 4)
+
 #define X86_64_B_SIZE   64 
 #define X86_32_B_SIZE   32
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:53:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:53: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 1U5eeJ-0007Ff-5i; Wed, 13 Feb 2013 15:53:31 +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 1U5eeH-0007Dt-Pf
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:53:29 +0000
Received: from [85.158.143.35:25668] by server-3.bemta-4.messagelabs.com id
	17/49-08920-9F6BB115; Wed, 13 Feb 2013 15:53:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360770784!13148685!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 13 Feb 2013 15:53:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:04 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo27) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k02bb9p1DFAwrK
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 54D64189BB
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8958163de4026b150a2fbb8fd7fa496941e22d0d
Message-Id: <8958163de4026b150a2f.1360770781@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 7] tools/xc: turn XCFLAGS_* into shifts
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360769530 -3600
# Node ID 8958163de4026b150a2fbb8fd7fa496941e22d0d
# Parent  1518e1b1341a56e8ea52c7fbaa56a7c062e559a5
tools/xc: turn XCFLAGS_* into shifts

to make it clear that these are bits and to make it easier to use in
xend code.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1518e1b1341a -r 8958163de402 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -23,11 +23,12 @@
 #ifndef XENGUEST_H
 #define XENGUEST_H
 
-#define XCFLAGS_LIVE      1
-#define XCFLAGS_DEBUG     2
-#define XCFLAGS_HVM       4
-#define XCFLAGS_STDVGA    8
-#define XCFLAGS_CHECKPOINT_COMPRESS    16
+#define XCFLAGS_LIVE      (1 << 0)
+#define XCFLAGS_DEBUG     (1 << 1)
+#define XCFLAGS_HVM       (1 << 2)
+#define XCFLAGS_STDVGA    (1 << 3)
+#define XCFLAGS_CHECKPOINT_COMPRESS    (1 << 4)
+
 #define X86_64_B_SIZE   64 
 #define X86_32_B_SIZE   32
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:54:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5ef1-0007Up-Ky; Wed, 13 Feb 2013 15:54:15 +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 1U5ef0-0007UL-Kj
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:54:14 +0000
Received: from [193.109.254.147:47886] by server-16.bemta-14.messagelabs.com
	id 99/82-25906-527BB115; Wed, 13 Feb 2013 15:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360770784!11047042!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18601 invoked from network); 13 Feb 2013 15:53:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:05 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo46) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D030acp1DFUE60
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 82E281863F
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0e6a41e1ee36237ba130959dc3d2a3bd44104eb0
Message-Id: <0e6a41e1ee36237ba130.1360770782@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 7] tools/xc: restore logging in xc_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360769534 -3600
# Node ID 0e6a41e1ee36237ba130959dc3d2a3bd44104eb0
# Parent  8958163de4026b150a2fbb8fd7fa496941e22d0d
tools/xc: restore logging in xc_save

Prior to xen-4.1 the helper xc_save would print some progress during
migration. With the new xc_interface_open API no more messages were
printed because no logger was configured.

Restore previous behaviour by providing a logger. The progress in
xc_domain_save will be disabled because it generates alot of output and
fills up xend.log quickly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8958163de402 -r 0e6a41e1ee36 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
 int
 main(int argc, char **argv)
 {
-    unsigned int maxit, max_f;
+    unsigned int maxit, max_f, lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    xentoollog_level lvl;
+    xentoollog_logger *l;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
 
-    si.xch = xc_interface_open(0,0,0);
-    if (!si.xch)
-        errx(1, "failed to open control interface");
-
     io_fd = atoi(argv[1]);
     si.domid = atoi(argv[2]);
     maxit = atoi(argv[3]);
@@ -185,6 +183,13 @@ main(int argc, char **argv)
 
     si.suspend_evtchn = -1;
 
+    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
+    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
+    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
+    si.xch = xc_interface_open(l, 0, 0);
+    if (!si.xch)
+        errx(1, "failed to open control interface");
+
     si.xce = xc_evtchn_open(NULL, 0);
     if (si.xce == NULL)
         warnx("failed to open event channel handle");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:54:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15: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 1U5ef1-0007Up-Ky; Wed, 13 Feb 2013 15:54:15 +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 1U5ef0-0007UL-Kj
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:54:14 +0000
Received: from [193.109.254.147:47886] by server-16.bemta-14.messagelabs.com
	id 99/82-25906-527BB115; Wed, 13 Feb 2013 15:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360770784!11047042!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjYzNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18601 invoked from network); 13 Feb 2013 15:53:05 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 15:53:05 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (jored mo46) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D030acp1DFUE60
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:04 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 82E281863F
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 16:53:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0e6a41e1ee36237ba130959dc3d2a3bd44104eb0
Message-Id: <0e6a41e1ee36237ba130.1360770782@probook.site>
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 13 Feb 2013 16:53:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 7] tools/xc: restore logging in xc_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360769534 -3600
# Node ID 0e6a41e1ee36237ba130959dc3d2a3bd44104eb0
# Parent  8958163de4026b150a2fbb8fd7fa496941e22d0d
tools/xc: restore logging in xc_save

Prior to xen-4.1 the helper xc_save would print some progress during
migration. With the new xc_interface_open API no more messages were
printed because no logger was configured.

Restore previous behaviour by providing a logger. The progress in
xc_domain_save will be disabled because it generates alot of output and
fills up xend.log quickly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 8958163de402 -r 0e6a41e1ee36 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -166,17 +166,15 @@ static int switch_qemu_logdirty(int domi
 int
 main(int argc, char **argv)
 {
-    unsigned int maxit, max_f;
+    unsigned int maxit, max_f, lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    xentoollog_level lvl;
+    xentoollog_logger *l;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
 
-    si.xch = xc_interface_open(0,0,0);
-    if (!si.xch)
-        errx(1, "failed to open control interface");
-
     io_fd = atoi(argv[1]);
     si.domid = atoi(argv[2]);
     maxit = atoi(argv[3]);
@@ -185,6 +183,13 @@ main(int argc, char **argv)
 
     si.suspend_evtchn = -1;
 
+    lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
+    lflags = XTL_STDIOSTREAM_HIDE_PROGRESS;
+    l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
+    si.xch = xc_interface_open(l, 0, 0);
+    if (!si.xch)
+        errx(1, "failed to open control interface");
+
     si.xce = xc_evtchn_open(NULL, 0);
     if (si.xce == NULL)
         warnx("failed to open event channel handle");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:56:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:56: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 1U5egk-0007yG-73; Wed, 13 Feb 2013 15:56:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5egi-0007xe-EN
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:56:00 +0000
Received: from [193.109.254.147:6675] by server-13.bemta-14.messagelabs.com id
	A0/E1-30639-F87BB115; Wed, 13 Feb 2013 15:55:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360770946!8619279!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9361 invoked from network); 13 Feb 2013 15:55:46 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 15:55:46 -0000
X-TM-IMSS-Message-ID: <577eb75a0000d1c2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	577eb75a0000d1c2 ; Wed, 13 Feb 2013 10:54:14 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DFtPDY014981; 
	Wed, 13 Feb 2013 10:55:25 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: keir@xen.org
Date: Wed, 13 Feb 2013 10:54:48 -0500
Message-Id: <1360770888-11644-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/flask: fix crash on debugkey "i"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 IRQs beyond nr_static_irqs do not all have an associated PCI device,
so only query the device SID if pci is not NULL.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 85d009c..29a78dd 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -110,7 +110,7 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
         }
         return security_irq_sid(irq, sid);
     }
-    if ( desc->msi_desc ) {
+    if ( desc->msi_desc && desc->msi_desc->dev ) {
         struct pci_dev *dev = desc->msi_desc->dev;
         u32 sbdf = (dev->seg << 16) | (dev->bus << 8) | dev->devfn;
         if (ad) {
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 15:56:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 15:56: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 1U5egk-0007yG-73; Wed, 13 Feb 2013 15:56:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5egi-0007xe-EN
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 15:56:00 +0000
Received: from [193.109.254.147:6675] by server-13.bemta-14.messagelabs.com id
	A0/E1-30639-F87BB115; Wed, 13 Feb 2013 15:55:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360770946!8619279!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9361 invoked from network); 13 Feb 2013 15:55:46 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 15:55:46 -0000
X-TM-IMSS-Message-ID: <577eb75a0000d1c2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	577eb75a0000d1c2 ; Wed, 13 Feb 2013 10:54:14 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DFtPDY014981; 
	Wed, 13 Feb 2013 10:55:25 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: keir@xen.org
Date: Wed, 13 Feb 2013 10:54:48 -0500
Message-Id: <1360770888-11644-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/flask: fix crash on debugkey "i"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 IRQs beyond nr_static_irqs do not all have an associated PCI device,
so only query the device SID if pci is not NULL.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 85d009c..29a78dd 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -110,7 +110,7 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
         }
         return security_irq_sid(irq, sid);
     }
-    if ( desc->msi_desc ) {
+    if ( desc->msi_desc && desc->msi_desc->dev ) {
         struct pci_dev *dev = desc->msi_desc->dev;
         u32 sbdf = (dev->seg << 16) | (dev->bus << 8) | dev->devfn;
         if (ad) {
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:01: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 1U5emH-0000Nu-Uw; Wed, 13 Feb 2013 16:01:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emF-0000NS-Os
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:44 +0000
Received: from [193.109.254.147:2797] by server-7.bemta-14.messagelabs.com id
	0A/40-13581-6E8BB115; Wed, 13 Feb 2013 16:01:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360771300!2411673!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30924 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-15.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <57846c850000d391@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	57846c850000d391 ; Wed, 13 Feb 2013 11:00:28 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCc015710; 
	Wed, 13 Feb 2013 11:01:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:33 -0500
Message-Id: <1360771294-11763-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/3] flask/policy: rework policy build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 adds the ability to define security classes and access vectors in
FLASK policy not defined by the hypervisor, for the use of stub domains
or applications without their own security policies.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/Makefile                | 203 +++++++++--------------------
 tools/flask/policy/policy/access_vectors   |  24 ++++
 tools/flask/policy/policy/global_booleans  |   5 -
 tools/flask/policy/policy/global_tunables  |   5 +-
 tools/flask/policy/policy/initial_sids     |   4 +-
 tools/flask/policy/policy/security_classes |   8 ++
 6 files changed, 96 insertions(+), 153 deletions(-)
 create mode 100644 tools/flask/policy/policy/access_vectors
 delete mode 100644 tools/flask/policy/policy/global_booleans
 create mode 100644 tools/flask/policy/policy/security_classes

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index 3f5aa38..e666f3e 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -1,117 +1,86 @@
-#
-# Makefile for the security policy.
-#
-# Targets:
-# 
-# install       - compile and install the policy configuration.
-# load          - compile, install, and load the policy configuration.
-# reload        - compile, install, and load/reload the policy configuration.
-# policy        - compile the policy configuration locally for testing/development.
-#
-# The default target is 'policy'.
-#
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
 
 ########################################
 #
 # Configurable portions of the Makefile
 #
+########################################
 
-# Policy version
-# By default, checkpolicy will create the highest
-# version policy it supports.  Setting this will
-# override the version.
-OUTPUT_POLICY = 24
-
-# Policy Type
-# xen
-# xen-mls
-TYPE = xen 
-
-# Policy Name
-# If set, this will be used as the policy
-# name.  Otherwise xenpolicy will be
-# used for the name.
-# NAME = xenpolicy
-
-# Number of MLS Sensitivities
-# The sensitivities will be s0 to s(MLS_SENS-1).
-# Dominance will be in increasing numerical order
-# with s0 being lowest.
-# MLS_SENS = 16
+CONFIG_MLS ?= n
 
-# Number of MLS Categories
+# Number of available MLS sensitivities and categories.
+# The sensitivities will be s0 to s(MLS_SENS-1).  Dominance will be in
+# increasing numerical order with s0 being lowest.
+MLS_SENS ?= 16
 # The categories will be c0 to c(MLS_CATS-1).
-# MLS_CATS = 256
+MLS_CATS ?= 256
 
-# Uncomment this to disable command echoing
-# QUIET:=@
+# executable paths
+CHECKPOLICY ?= checkpolicy
+M4 ?= m4
 
 ########################################
 #
-# NO OPTIONS BELOW HERE
+# End of configuration options
 #
+########################################
 
-# executable paths
-PREFIX := /usr
-BINDIR := $(PREFIX)/bin
-SBINDIR := $(PREFIX)/sbin
-CHECKPOLICY := $(BINDIR)/checkpolicy
-LOADPOLICY := $(SBINDIR)/flask-loadpolicy
+# Policy version
+# By default, checkpolicy creates the highest version policy it supports. Force
+# the use of version 24 which is the highest that Xen supports, and the first to
+# include the Xen policy type (needed for static device policy).
+OUTPUT_POLICY = 24
+
+POLICY_FILENAME = xenpolicy.$(OUTPUT_POLICY)
+POLICY_LOADPATH = $(DESTDIR)/boot
 
 # policy source layout
 POLDIR := policy
 MODDIR := $(POLDIR)/modules
+
+# Classes and access vectors defined in the hypervisor. Changes to these require
+# a recompile of both the hypervisor and security policy.
 FLASKDIR := ../../../xen/xsm/flask/policy
 SECCLASS := $(FLASKDIR)/security_classes
-ISIDS := $(FLASKDIR)/initial_sids
+ISID_DECLS := $(FLASKDIR)/initial_sids
 AVS := $(FLASKDIR)/access_vectors
 
+# Additional classes and access vectors defined by local policy
+SECCLASS += $(POLDIR)/security_classes
+AVS += $(POLDIR)/access_vectors
+
+# Other policy components
+M4SUPPORT := $(wildcard $(POLDIR)/support/*.spt)
+MLSSUPPORT := $(POLDIR)/mls
+USERS := $(POLDIR)/users
+CONSTRAINTS := $(POLDIR)/constraints
+ISID_DEFS := $(POLDIR)/initial_sids
+
 # config file paths
 GLOBALTUN := $(POLDIR)/global_tunables
-GLOBALBOOL := $(POLDIR)/global_booleans
 MOD_CONF := $(POLDIR)/modules.conf
-TUNABLES := $(POLDIR)/tunables.conf
-BOOLEANS := $(POLDIR)/booleans.conf
-
-# install paths
-
-DESTDIR = /boot
-INSTALLDIR = $(DESTDIR)
-LOADPATH = $(INSTALLDIR)/$(POLVER)
 
-# default MLS sensitivity and category settings.
-MLS_SENS ?= 16
-MLS_CATS ?= 256
+# checkpolicy can use the #line directives provided by -s for error reporting:
+M4PARAM := -D self_contained_policy -s
+CHECKPOLICY_PARAM := -t Xen -c $(OUTPUT_POLICY)
 
 # enable MLS if requested.
-ifneq ($(findstring -mls,$(TYPE)),)
+ifneq ($(CONFIG_MLS),n)
 	M4PARAM += -D enable_mls
-	CHECKPOLICY += -M
-endif
-
-ifeq ($(NAME),)
-	NAME := xenpolicy
-endif
-
-PV := $(shell $(CHECKPOLICY) -V |cut -f 1 -d ' ')
-
-ifneq ($(OUTPUT_POLICY),)
-	CHECKPOLICY += -c $(OUTPUT_POLICY)
-	POLVER = $(NAME).$(OUTPUT_POLICY)
-else
-	POLVER +=$(NAME).$(PV)
+	CHECKPOLICY_PARAM += -M
 endif
 
 # Always define these because they are referenced even in non-MLS policy
 M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS)
 
-M4SUPPORT = $(wildcard $(POLDIR)/support/*.spt)
 
+# Find modules
 ALL_LAYERS := $(filter-out $(MODDIR)/CVS,$(shell find $(wildcard $(MODDIR)/*) -maxdepth 0 -type d))
 
 # sort here since it removes duplicates, which can happen
 # when a generated file is already generated
-DETECTED_MODS := $(sort $(foreach dir,$(ALL_LAYERS),$(wildcard $(dir)/*.te))) 
+DETECTED_MODS := $(sort $(foreach dir,$(ALL_LAYERS),$(wildcard $(dir)/*.te)))
 
 # modules.conf setting for policy configuration
 MODENABLED := on
@@ -122,81 +91,27 @@ ENABLED_MODS := $(foreach mod,$(shell awk '/^[[:blank:]]*[[:alpha:]]/{ if ($$3 =
 ALL_MODULES := $(filter $(ENABLED_MODS),$(DETECTED_MODS))
 
 ALL_INTERFACES := $(ALL_MODULES:.te=.if)
-ALL_TE_FILES := $(ALL_MODULES)
-
-PRE_TE_FILES := $(SECCLASS) $(ISIDS) $(AVS) $(M4SUPPORT) $(POLDIR)/mls 
-POST_TE_FILES := $(POLDIR)/users $(POLDIR)/constraints $(POLDIR)/initial_sids
 
-POLICY_SECTIONS := $(PRE_TE_FILES) $(ALL_INTERFACES) $(GLOBALBOOL) $(GLOBALTUN) $(ALL_TE_FILES) $(POST_TE_FILES)
-
-########################################
-#
-# default action: build policy locally
-#
-default: policy
+# The order of these files is important
+POLICY_SECTIONS := $(SECCLASS) $(ISID_DECLS) $(AVS)
+POLICY_SECTIONS += $(M4SUPPORT) $(MLSSUPPORT)
+POLICY_SECTIONS += $(ALL_INTERFACES)
+POLICY_SECTIONS += $(GLOBALTUN)
+POLICY_SECTIONS += $(ALL_MODULES)
+POLICY_SECTIONS += $(USERS) $(CONSTRAINTS) $(ISID_DEFS)
 
-policy: $(POLVER)
+all: $(POLICY_FILENAME)
 
-install: $(LOADPATH)
+install: $(POLICY_FILENAME)
+	$(INSTALL_DATA) $^ $(POLICY_LOADPATH)
 
-load: .load_stamp
+$(POLICY_FILENAME): policy.conf
+	$(CHECKPOLICY) $(CHECKPOLICY_PARAM) $^ -o $@
 
-########################################
-#
-# Build a binary policy locally
-#
-$(POLVER): policy.conf
-	@echo "Compiling $(NAME) $(POLVER)"
-	$(QUIET) $(CHECKPOLICY) $^ -o $@
-# Uncomment line below to enable policies for devices
-#	$(QUIET) $(CHECKPOLICY) -t Xen $^ -o $@
-
-########################################
-#
-# Install a binary policy
-#
-$(LOADPATH): policy.conf
-	@echo "Compiling and installing $(NAME) $(LOADPATH)"
-	$(QUIET) $(CHECKPOLICY) $^ -o $@
-# Uncomment line below to enable policies for devices
-#	$(QUIET) $(CHECKPOLICY) -t Xen $^ -o $@
-
-########################################
-#
-# Load the binary policy
-#
-.load_stamp: reload
-reload: $(LOADPATH)
-	@echo "Loading $(NAME) $(LOADPATH)"
-	$(QUIET) $(LOADPOLICY) $(LOADPATH)
-	@touch .load_stamp
-
-########################################
-#
-# Construct a monolithic policy.conf
-#
 policy.conf: $(POLICY_SECTIONS)
-	@echo "Creating $(NAME) policy.conf"
-# checkpolicy can use the #line directives provided by -s for error reporting:
-	$(QUIET) m4 -D self_contained_policy $(M4PARAM) -s $^ > $@
+	$(M4) $(M4PARAM) $^ > $@
 
-########################################
-#
-# Remove the dontaudit rules from the policy.conf
-#
-enableaudit: policy.conf
-	@test -d tmp || mkdir -p tmp
-	@echo "Removing dontaudit rules from policy.conf"
-	$(QUIET) grep -v dontaudit policy.conf > tmp/policy.audit
-	$(QUIET) mv tmp/policy.audit policy.conf
-
-########################################
-#
-# Clean the built policies. 
-#
 clean:
-	rm -fR tmp
-	rm -f policy.conf
-	rm -f $(POLVER)
+	$(RM) tmp policy.conf $(POLICY_FILENAME)
 
-.PHONY: default policy install load reload enableaudit clean
+.PHONY: all install clean
diff --git a/tools/flask/policy/policy/access_vectors b/tools/flask/policy/policy/access_vectors
new file mode 100644
index 0000000..4fd61f1
--- /dev/null
+++ b/tools/flask/policy/policy/access_vectors
@@ -0,0 +1,24 @@
+# Locally defined access vectors
+#
+# Define access vectors for the security classes defined in security_classes
+#
+
+# Note: this is an example; the xenstore daemon provided with Xen does
+# not yet include XSM support, and the exact permissions may be defined
+# differently if such support is added.
+class xenstore {
+	# read from keys owned by the target domain (if permissions allow)
+	read
+	# write to keys owned by the target domain (if permissions allow)
+	write
+	# change permissions of a key owned by the target domain
+	chmod
+	# change the owner of a key which was owned by the target domain
+	chown_from
+	# change the owner of a key to the target domain
+	chown_to
+	# access a key owned by the target domain without permission
+	override
+	# introduce a domain
+	introduce
+}
diff --git a/tools/flask/policy/policy/global_booleans b/tools/flask/policy/policy/global_booleans
deleted file mode 100644
index 4c13cfb..0000000
--- a/tools/flask/policy/policy/global_booleans
+++ /dev/null
@@ -1,5 +0,0 @@
-#
-# This file is for the declaration of global booleans.
-# To change the default value at build time, the booleans.conf
-# file should be used.
-#
diff --git a/tools/flask/policy/policy/global_tunables b/tools/flask/policy/policy/global_tunables
index 801b27e..c5da7ae 100644
--- a/tools/flask/policy/policy/global_tunables
+++ b/tools/flask/policy/policy/global_tunables
@@ -1,6 +1,5 @@
 #
-# This file is for the declaration of global tunables.
-# To change the default value at build time, the booleans.conf
-# file should be used.
+# This file is for the declaration of global policy tunables, booleans,
+# and other components not defined within a specific policy module.
 #
 
diff --git a/tools/flask/policy/policy/initial_sids b/tools/flask/policy/policy/initial_sids
index b70a54e..5de0bbf 100644
--- a/tools/flask/policy/policy/initial_sids
+++ b/tools/flask/policy/policy/initial_sids
@@ -1,4 +1,6 @@
-# Labels for initial SIDs
+# Labels for initial SIDs. These initial SIDs are used by the hypervisor for
+# objects created before the policy is loaded or for objects that do not have a
+# label defined in some other manner.
 
 sid xen gen_context(system_u:system_r:xen_t,s0)
 sid dom0 gen_context(system_u:system_r:dom0_t,s0)
diff --git a/tools/flask/policy/policy/security_classes b/tools/flask/policy/policy/security_classes
new file mode 100644
index 0000000..56595e8
--- /dev/null
+++ b/tools/flask/policy/policy/security_classes
@@ -0,0 +1,8 @@
+# Locally defined security classes
+#
+# These classes are not used by the hypervisor, but may be used by domains or
+# daemons that need to make access control decisions using the hypervisor's
+# security policy.
+#
+# Access vectors for these classes must be defined in the access_vectors file.
+class xenstore
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:01: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 1U5emH-0000Nu-Uw; Wed, 13 Feb 2013 16:01:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emF-0000NS-Os
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:44 +0000
Received: from [193.109.254.147:2797] by server-7.bemta-14.messagelabs.com id
	0A/40-13581-6E8BB115; Wed, 13 Feb 2013 16:01:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360771300!2411673!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30924 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-15.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <57846c850000d391@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	57846c850000d391 ; Wed, 13 Feb 2013 11:00:28 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCc015710; 
	Wed, 13 Feb 2013 11:01:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:33 -0500
Message-Id: <1360771294-11763-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/3] flask/policy: rework policy build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 adds the ability to define security classes and access vectors in
FLASK policy not defined by the hypervisor, for the use of stub domains
or applications without their own security policies.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/Makefile                | 203 +++++++++--------------------
 tools/flask/policy/policy/access_vectors   |  24 ++++
 tools/flask/policy/policy/global_booleans  |   5 -
 tools/flask/policy/policy/global_tunables  |   5 +-
 tools/flask/policy/policy/initial_sids     |   4 +-
 tools/flask/policy/policy/security_classes |   8 ++
 6 files changed, 96 insertions(+), 153 deletions(-)
 create mode 100644 tools/flask/policy/policy/access_vectors
 delete mode 100644 tools/flask/policy/policy/global_booleans
 create mode 100644 tools/flask/policy/policy/security_classes

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index 3f5aa38..e666f3e 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -1,117 +1,86 @@
-#
-# Makefile for the security policy.
-#
-# Targets:
-# 
-# install       - compile and install the policy configuration.
-# load          - compile, install, and load the policy configuration.
-# reload        - compile, install, and load/reload the policy configuration.
-# policy        - compile the policy configuration locally for testing/development.
-#
-# The default target is 'policy'.
-#
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
 
 ########################################
 #
 # Configurable portions of the Makefile
 #
+########################################
 
-# Policy version
-# By default, checkpolicy will create the highest
-# version policy it supports.  Setting this will
-# override the version.
-OUTPUT_POLICY = 24
-
-# Policy Type
-# xen
-# xen-mls
-TYPE = xen 
-
-# Policy Name
-# If set, this will be used as the policy
-# name.  Otherwise xenpolicy will be
-# used for the name.
-# NAME = xenpolicy
-
-# Number of MLS Sensitivities
-# The sensitivities will be s0 to s(MLS_SENS-1).
-# Dominance will be in increasing numerical order
-# with s0 being lowest.
-# MLS_SENS = 16
+CONFIG_MLS ?= n
 
-# Number of MLS Categories
+# Number of available MLS sensitivities and categories.
+# The sensitivities will be s0 to s(MLS_SENS-1).  Dominance will be in
+# increasing numerical order with s0 being lowest.
+MLS_SENS ?= 16
 # The categories will be c0 to c(MLS_CATS-1).
-# MLS_CATS = 256
+MLS_CATS ?= 256
 
-# Uncomment this to disable command echoing
-# QUIET:=@
+# executable paths
+CHECKPOLICY ?= checkpolicy
+M4 ?= m4
 
 ########################################
 #
-# NO OPTIONS BELOW HERE
+# End of configuration options
 #
+########################################
 
-# executable paths
-PREFIX := /usr
-BINDIR := $(PREFIX)/bin
-SBINDIR := $(PREFIX)/sbin
-CHECKPOLICY := $(BINDIR)/checkpolicy
-LOADPOLICY := $(SBINDIR)/flask-loadpolicy
+# Policy version
+# By default, checkpolicy creates the highest version policy it supports. Force
+# the use of version 24 which is the highest that Xen supports, and the first to
+# include the Xen policy type (needed for static device policy).
+OUTPUT_POLICY = 24
+
+POLICY_FILENAME = xenpolicy.$(OUTPUT_POLICY)
+POLICY_LOADPATH = $(DESTDIR)/boot
 
 # policy source layout
 POLDIR := policy
 MODDIR := $(POLDIR)/modules
+
+# Classes and access vectors defined in the hypervisor. Changes to these require
+# a recompile of both the hypervisor and security policy.
 FLASKDIR := ../../../xen/xsm/flask/policy
 SECCLASS := $(FLASKDIR)/security_classes
-ISIDS := $(FLASKDIR)/initial_sids
+ISID_DECLS := $(FLASKDIR)/initial_sids
 AVS := $(FLASKDIR)/access_vectors
 
+# Additional classes and access vectors defined by local policy
+SECCLASS += $(POLDIR)/security_classes
+AVS += $(POLDIR)/access_vectors
+
+# Other policy components
+M4SUPPORT := $(wildcard $(POLDIR)/support/*.spt)
+MLSSUPPORT := $(POLDIR)/mls
+USERS := $(POLDIR)/users
+CONSTRAINTS := $(POLDIR)/constraints
+ISID_DEFS := $(POLDIR)/initial_sids
+
 # config file paths
 GLOBALTUN := $(POLDIR)/global_tunables
-GLOBALBOOL := $(POLDIR)/global_booleans
 MOD_CONF := $(POLDIR)/modules.conf
-TUNABLES := $(POLDIR)/tunables.conf
-BOOLEANS := $(POLDIR)/booleans.conf
-
-# install paths
-
-DESTDIR = /boot
-INSTALLDIR = $(DESTDIR)
-LOADPATH = $(INSTALLDIR)/$(POLVER)
 
-# default MLS sensitivity and category settings.
-MLS_SENS ?= 16
-MLS_CATS ?= 256
+# checkpolicy can use the #line directives provided by -s for error reporting:
+M4PARAM := -D self_contained_policy -s
+CHECKPOLICY_PARAM := -t Xen -c $(OUTPUT_POLICY)
 
 # enable MLS if requested.
-ifneq ($(findstring -mls,$(TYPE)),)
+ifneq ($(CONFIG_MLS),n)
 	M4PARAM += -D enable_mls
-	CHECKPOLICY += -M
-endif
-
-ifeq ($(NAME),)
-	NAME := xenpolicy
-endif
-
-PV := $(shell $(CHECKPOLICY) -V |cut -f 1 -d ' ')
-
-ifneq ($(OUTPUT_POLICY),)
-	CHECKPOLICY += -c $(OUTPUT_POLICY)
-	POLVER = $(NAME).$(OUTPUT_POLICY)
-else
-	POLVER +=$(NAME).$(PV)
+	CHECKPOLICY_PARAM += -M
 endif
 
 # Always define these because they are referenced even in non-MLS policy
 M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS)
 
-M4SUPPORT = $(wildcard $(POLDIR)/support/*.spt)
 
+# Find modules
 ALL_LAYERS := $(filter-out $(MODDIR)/CVS,$(shell find $(wildcard $(MODDIR)/*) -maxdepth 0 -type d))
 
 # sort here since it removes duplicates, which can happen
 # when a generated file is already generated
-DETECTED_MODS := $(sort $(foreach dir,$(ALL_LAYERS),$(wildcard $(dir)/*.te))) 
+DETECTED_MODS := $(sort $(foreach dir,$(ALL_LAYERS),$(wildcard $(dir)/*.te)))
 
 # modules.conf setting for policy configuration
 MODENABLED := on
@@ -122,81 +91,27 @@ ENABLED_MODS := $(foreach mod,$(shell awk '/^[[:blank:]]*[[:alpha:]]/{ if ($$3 =
 ALL_MODULES := $(filter $(ENABLED_MODS),$(DETECTED_MODS))
 
 ALL_INTERFACES := $(ALL_MODULES:.te=.if)
-ALL_TE_FILES := $(ALL_MODULES)
-
-PRE_TE_FILES := $(SECCLASS) $(ISIDS) $(AVS) $(M4SUPPORT) $(POLDIR)/mls 
-POST_TE_FILES := $(POLDIR)/users $(POLDIR)/constraints $(POLDIR)/initial_sids
 
-POLICY_SECTIONS := $(PRE_TE_FILES) $(ALL_INTERFACES) $(GLOBALBOOL) $(GLOBALTUN) $(ALL_TE_FILES) $(POST_TE_FILES)
-
-########################################
-#
-# default action: build policy locally
-#
-default: policy
+# The order of these files is important
+POLICY_SECTIONS := $(SECCLASS) $(ISID_DECLS) $(AVS)
+POLICY_SECTIONS += $(M4SUPPORT) $(MLSSUPPORT)
+POLICY_SECTIONS += $(ALL_INTERFACES)
+POLICY_SECTIONS += $(GLOBALTUN)
+POLICY_SECTIONS += $(ALL_MODULES)
+POLICY_SECTIONS += $(USERS) $(CONSTRAINTS) $(ISID_DEFS)
 
-policy: $(POLVER)
+all: $(POLICY_FILENAME)
 
-install: $(LOADPATH)
+install: $(POLICY_FILENAME)
+	$(INSTALL_DATA) $^ $(POLICY_LOADPATH)
 
-load: .load_stamp
+$(POLICY_FILENAME): policy.conf
+	$(CHECKPOLICY) $(CHECKPOLICY_PARAM) $^ -o $@
 
-########################################
-#
-# Build a binary policy locally
-#
-$(POLVER): policy.conf
-	@echo "Compiling $(NAME) $(POLVER)"
-	$(QUIET) $(CHECKPOLICY) $^ -o $@
-# Uncomment line below to enable policies for devices
-#	$(QUIET) $(CHECKPOLICY) -t Xen $^ -o $@
-
-########################################
-#
-# Install a binary policy
-#
-$(LOADPATH): policy.conf
-	@echo "Compiling and installing $(NAME) $(LOADPATH)"
-	$(QUIET) $(CHECKPOLICY) $^ -o $@
-# Uncomment line below to enable policies for devices
-#	$(QUIET) $(CHECKPOLICY) -t Xen $^ -o $@
-
-########################################
-#
-# Load the binary policy
-#
-.load_stamp: reload
-reload: $(LOADPATH)
-	@echo "Loading $(NAME) $(LOADPATH)"
-	$(QUIET) $(LOADPOLICY) $(LOADPATH)
-	@touch .load_stamp
-
-########################################
-#
-# Construct a monolithic policy.conf
-#
 policy.conf: $(POLICY_SECTIONS)
-	@echo "Creating $(NAME) policy.conf"
-# checkpolicy can use the #line directives provided by -s for error reporting:
-	$(QUIET) m4 -D self_contained_policy $(M4PARAM) -s $^ > $@
+	$(M4) $(M4PARAM) $^ > $@
 
-########################################
-#
-# Remove the dontaudit rules from the policy.conf
-#
-enableaudit: policy.conf
-	@test -d tmp || mkdir -p tmp
-	@echo "Removing dontaudit rules from policy.conf"
-	$(QUIET) grep -v dontaudit policy.conf > tmp/policy.audit
-	$(QUIET) mv tmp/policy.audit policy.conf
-
-########################################
-#
-# Clean the built policies. 
-#
 clean:
-	rm -fR tmp
-	rm -f policy.conf
-	rm -f $(POLVER)
+	$(RM) tmp policy.conf $(POLICY_FILENAME)
 
-.PHONY: default policy install load reload enableaudit clean
+.PHONY: all install clean
diff --git a/tools/flask/policy/policy/access_vectors b/tools/flask/policy/policy/access_vectors
new file mode 100644
index 0000000..4fd61f1
--- /dev/null
+++ b/tools/flask/policy/policy/access_vectors
@@ -0,0 +1,24 @@
+# Locally defined access vectors
+#
+# Define access vectors for the security classes defined in security_classes
+#
+
+# Note: this is an example; the xenstore daemon provided with Xen does
+# not yet include XSM support, and the exact permissions may be defined
+# differently if such support is added.
+class xenstore {
+	# read from keys owned by the target domain (if permissions allow)
+	read
+	# write to keys owned by the target domain (if permissions allow)
+	write
+	# change permissions of a key owned by the target domain
+	chmod
+	# change the owner of a key which was owned by the target domain
+	chown_from
+	# change the owner of a key to the target domain
+	chown_to
+	# access a key owned by the target domain without permission
+	override
+	# introduce a domain
+	introduce
+}
diff --git a/tools/flask/policy/policy/global_booleans b/tools/flask/policy/policy/global_booleans
deleted file mode 100644
index 4c13cfb..0000000
--- a/tools/flask/policy/policy/global_booleans
+++ /dev/null
@@ -1,5 +0,0 @@
-#
-# This file is for the declaration of global booleans.
-# To change the default value at build time, the booleans.conf
-# file should be used.
-#
diff --git a/tools/flask/policy/policy/global_tunables b/tools/flask/policy/policy/global_tunables
index 801b27e..c5da7ae 100644
--- a/tools/flask/policy/policy/global_tunables
+++ b/tools/flask/policy/policy/global_tunables
@@ -1,6 +1,5 @@
 #
-# This file is for the declaration of global tunables.
-# To change the default value at build time, the booleans.conf
-# file should be used.
+# This file is for the declaration of global policy tunables, booleans,
+# and other components not defined within a specific policy module.
 #
 
diff --git a/tools/flask/policy/policy/initial_sids b/tools/flask/policy/policy/initial_sids
index b70a54e..5de0bbf 100644
--- a/tools/flask/policy/policy/initial_sids
+++ b/tools/flask/policy/policy/initial_sids
@@ -1,4 +1,6 @@
-# Labels for initial SIDs
+# Labels for initial SIDs. These initial SIDs are used by the hypervisor for
+# objects created before the policy is loaded or for objects that do not have a
+# label defined in some other manner.
 
 sid xen gen_context(system_u:system_r:xen_t,s0)
 sid dom0 gen_context(system_u:system_r:dom0_t,s0)
diff --git a/tools/flask/policy/policy/security_classes b/tools/flask/policy/policy/security_classes
new file mode 100644
index 0000000..56595e8
--- /dev/null
+++ b/tools/flask/policy/policy/security_classes
@@ -0,0 +1,8 @@
+# Locally defined security classes
+#
+# These classes are not used by the hypervisor, but may be used by domains or
+# daemons that need to make access control decisions using the hypervisor's
+# security policy.
+#
+# Access vectors for these classes must be defined in the access_vectors file.
+class xenstore
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16: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 1U5emH-0000Nc-22; Wed, 13 Feb 2013 16:01:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emF-0000NN-0d
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:43 +0000
Received: from [193.109.254.147:54630] by server-10.bemta-14.messagelabs.com
	id CC/4B-12679-6E8BB115; Wed, 13 Feb 2013 16:01:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360771301!3468666!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11606 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <33bc3c650000cd79@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	33bc3c650000cd79 ; Wed, 13 Feb 2013 11:02:14 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCa015710
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 11:01:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:31 -0500
Message-Id: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
Subject: [Xen-devel] [PATCH 0/3] FLASK policy build rework
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

These patches update the example FLASK policy shipped with Xen and
enable its build if the required tools are present. The third patch
requires rerunning autoconf to update tools/configure.

[PATCH 1/3] flask/policy: sort dom0 accesses
[PATCH 2/3] flask/policy: rework policy build system
[PATCH 3/3] tools/flask: add FLASK policy to build

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16: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 1U5emH-0000Nc-22; Wed, 13 Feb 2013 16:01:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emF-0000NN-0d
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:43 +0000
Received: from [193.109.254.147:54630] by server-10.bemta-14.messagelabs.com
	id CC/4B-12679-6E8BB115; Wed, 13 Feb 2013 16:01:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360771301!3468666!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11606 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <33bc3c650000cd79@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	33bc3c650000cd79 ; Wed, 13 Feb 2013 11:02:14 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCa015710
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 11:01:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:31 -0500
Message-Id: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
Subject: [Xen-devel] [PATCH 0/3] FLASK policy build rework
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

These patches update the example FLASK policy shipped with Xen and
enable its build if the required tools are present. The third patch
requires rerunning autoconf to update tools/configure.

[PATCH 1/3] flask/policy: sort dom0 accesses
[PATCH 2/3] flask/policy: rework policy build system
[PATCH 3/3] tools/flask: add FLASK policy to build

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16: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 1U5emH-0000Nl-F5; Wed, 13 Feb 2013 16:01:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emF-0000NT-RJ
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:44 +0000
Received: from [193.109.254.147:54690] by server-13.bemta-14.messagelabs.com
	id 73/0A-30639-7E8BB115; Wed, 13 Feb 2013 16:01:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360771301!8697416!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27506 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <33bc3f040000cd7c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	33bc3f040000cd7c ; Wed, 13 Feb 2013 11:02:14 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCd015710; 
	Wed, 13 Feb 2013 11:01:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:34 -0500
Message-Id: <1360771294-11763-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/3] tools/flask: add FLASK policy to 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>
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 patch enables the compilation of the FLASK policy as part of the
tools build if the needed prerequisites are present.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---

Note: ./autogen.sh nees to be rerun after applying this patch

 config/Tools.mk.in   |  1 +
 m4/checkpolicy.m4    | 12 ++++++++++++
 tools/configure.ac   | 10 ++++++++++
 tools/flask/Makefile |  4 ++--
 4 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 m4/checkpolicy.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 3967e7d..c69c7d2 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -46,6 +46,7 @@ GIT_HTTP            := @githttp@
 XENSTAT_XENTOP      := @monitors@
 LIBXENAPI_BINDINGS  := @xenapi@
 OCAML_TOOLS         := @ocamltools@
+FLASK_POLICY        := @xsmpolicy@
 CONFIG_MINITERM     := @miniterm@
 CONFIG_LOMOUNT      := @lomount@
 CONFIG_OVMF         := @ovmf@
diff --git a/m4/checkpolicy.m4 b/m4/checkpolicy.m4
new file mode 100644
index 0000000..f727a7d
--- /dev/null
+++ b/m4/checkpolicy.m4
@@ -0,0 +1,12 @@
+AC_DEFUN([AC_PROG_CHECKPOLICY],
+[dnl
+  # check for a checkpolicy binary with support for -t xen
+  AC_CHECK_TOOL([CHECKPOLICY],[checkpolicy],[no])
+
+  if test "$CHECKPOLICY" != "no"; then
+     CHECKPOLICYHELP=`$CHECKPOLICY -h | grep xen`
+     if test "$CHECKPOLICYHELP" = ""; then
+        CHECKPOLICY=no
+     fi
+  fi
+])
diff --git a/tools/configure.ac b/tools/configure.ac
index de5d085..0d38408 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -28,6 +28,7 @@ m4_include([../m4/path_or_fail.m4])
 m4_include([../m4/python_version.m4])
 m4_include([../m4/python_devel.m4])
 m4_include([../m4/ocaml.m4])
+m4_include([../m4/checkpolicy.m4])
 m4_include([../m4/set_cflags_ldflags.m4])
 m4_include([../m4/uuid.m4])
 m4_include([../m4/pkg.m4])
@@ -42,6 +43,7 @@ AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
 AX_ARG_DEFAULT_ENABLE([monitors], [Disable xenstat and xentop monitoring tools])
 AX_ARG_DEFAULT_DISABLE([xenapi], [Enable Xen API Bindings])
 AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
+AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
@@ -93,6 +95,14 @@ AS_IF([test "x$ocamltools" = "xy"], [
         ocamltools="n"
     ])
 ])
+AS_IF([test "x$xsmpolicy" = "xy"], [
+    AC_PROG_CHECKPOLICY
+    AS_IF([test "x$CHECKPOLICY" = "xno"], [
+        AS_IF([test "x$enable_xsmpolicy" = "xyes"], [
+            AC_MSG_ERROR([XSM policy compilation enabled, but unable to find checkpolicy])])
+        xsmpolicy="n"
+    ])
+])
 AX_PATH_PROG_OR_FAIL([BASH], [bash])
 AS_IF([echo "$PYTHON" | grep -q "^/"], [
     PYTHONPATH=$PYTHON
diff --git a/tools/flask/Makefile b/tools/flask/Makefile
index add9035..bc77a06 100644
--- a/tools/flask/Makefile
+++ b/tools/flask/Makefile
@@ -1,8 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS :=
-SUBDIRS += utils
+SUBDIRS-y := utils
+SUBDIRS-$(FLASK_POLICY) += policy
 
 .PHONY: all clean install
 all clean install: %: subdirs-%
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16: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 1U5emH-0000Nl-F5; Wed, 13 Feb 2013 16:01:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emF-0000NT-RJ
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:44 +0000
Received: from [193.109.254.147:54690] by server-13.bemta-14.messagelabs.com
	id 73/0A-30639-7E8BB115; Wed, 13 Feb 2013 16:01:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360771301!8697416!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27506 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <33bc3f040000cd7c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	33bc3f040000cd7c ; Wed, 13 Feb 2013 11:02:14 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCd015710; 
	Wed, 13 Feb 2013 11:01:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:34 -0500
Message-Id: <1360771294-11763-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/3] tools/flask: add FLASK policy to 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>
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 patch enables the compilation of the FLASK policy as part of the
tools build if the needed prerequisites are present.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---

Note: ./autogen.sh nees to be rerun after applying this patch

 config/Tools.mk.in   |  1 +
 m4/checkpolicy.m4    | 12 ++++++++++++
 tools/configure.ac   | 10 ++++++++++
 tools/flask/Makefile |  4 ++--
 4 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 m4/checkpolicy.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 3967e7d..c69c7d2 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -46,6 +46,7 @@ GIT_HTTP            := @githttp@
 XENSTAT_XENTOP      := @monitors@
 LIBXENAPI_BINDINGS  := @xenapi@
 OCAML_TOOLS         := @ocamltools@
+FLASK_POLICY        := @xsmpolicy@
 CONFIG_MINITERM     := @miniterm@
 CONFIG_LOMOUNT      := @lomount@
 CONFIG_OVMF         := @ovmf@
diff --git a/m4/checkpolicy.m4 b/m4/checkpolicy.m4
new file mode 100644
index 0000000..f727a7d
--- /dev/null
+++ b/m4/checkpolicy.m4
@@ -0,0 +1,12 @@
+AC_DEFUN([AC_PROG_CHECKPOLICY],
+[dnl
+  # check for a checkpolicy binary with support for -t xen
+  AC_CHECK_TOOL([CHECKPOLICY],[checkpolicy],[no])
+
+  if test "$CHECKPOLICY" != "no"; then
+     CHECKPOLICYHELP=`$CHECKPOLICY -h | grep xen`
+     if test "$CHECKPOLICYHELP" = ""; then
+        CHECKPOLICY=no
+     fi
+  fi
+])
diff --git a/tools/configure.ac b/tools/configure.ac
index de5d085..0d38408 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -28,6 +28,7 @@ m4_include([../m4/path_or_fail.m4])
 m4_include([../m4/python_version.m4])
 m4_include([../m4/python_devel.m4])
 m4_include([../m4/ocaml.m4])
+m4_include([../m4/checkpolicy.m4])
 m4_include([../m4/set_cflags_ldflags.m4])
 m4_include([../m4/uuid.m4])
 m4_include([../m4/pkg.m4])
@@ -42,6 +43,7 @@ AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
 AX_ARG_DEFAULT_ENABLE([monitors], [Disable xenstat and xentop monitoring tools])
 AX_ARG_DEFAULT_DISABLE([xenapi], [Enable Xen API Bindings])
 AX_ARG_DEFAULT_ENABLE([ocamltools], [Disable Ocaml tools])
+AX_ARG_DEFAULT_ENABLE([xsmpolicy], [Disable XSM policy compilation])
 AX_ARG_DEFAULT_DISABLE([miniterm], [Enable miniterm])
 AX_ARG_DEFAULT_DISABLE([lomount], [Enable lomount])
 AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
@@ -93,6 +95,14 @@ AS_IF([test "x$ocamltools" = "xy"], [
         ocamltools="n"
     ])
 ])
+AS_IF([test "x$xsmpolicy" = "xy"], [
+    AC_PROG_CHECKPOLICY
+    AS_IF([test "x$CHECKPOLICY" = "xno"], [
+        AS_IF([test "x$enable_xsmpolicy" = "xyes"], [
+            AC_MSG_ERROR([XSM policy compilation enabled, but unable to find checkpolicy])])
+        xsmpolicy="n"
+    ])
+])
 AX_PATH_PROG_OR_FAIL([BASH], [bash])
 AS_IF([echo "$PYTHON" | grep -q "^/"], [
     PYTHONPATH=$PYTHON
diff --git a/tools/flask/Makefile b/tools/flask/Makefile
index add9035..bc77a06 100644
--- a/tools/flask/Makefile
+++ b/tools/flask/Makefile
@@ -1,8 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS :=
-SUBDIRS += utils
+SUBDIRS-y := utils
+SUBDIRS-$(FLASK_POLICY) += policy
 
 .PHONY: all clean install
 all clean install: %: subdirs-%
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:01: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 1U5emN-0000Ot-IY; Wed, 13 Feb 2013 16:01:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emM-0000Of-95
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:50 +0000
Received: from [193.109.254.147:55198] by server-8.bemta-14.messagelabs.com id
	9D/4D-17325-DE8BB115; Wed, 13 Feb 2013 16:01:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360771300!11047759!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11256 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <57846bab0000d38f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	57846bab0000d38f ; Wed, 13 Feb 2013 11:00:28 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCb015710; 
	Wed, 13 Feb 2013 11:01:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:32 -0500
Message-Id: <1360771294-11763-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/3] flask/policy: sort dom0 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>
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 the example policy shipped with Xen, it makes sense to allow dom0
access to all system calls so that policy does not need to be updated
for each new hypervisor or toolstack feature used.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te | 60 ++++++++++++++++++++++------
 1 file changed, 48 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 955fd8b..454e27e 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -51,20 +51,58 @@ type device_t, resource_type;
 
 ################################################################################
 #
-# Rules required to boot the hypervisor and dom0
+# Allow dom0 access to all sysctls, devices, and the security server.
+#
+# While this could be written more briefly using wildcards, the permissions are
+# listed out to make removing specific permissions simpler.
 #
 ################################################################################
-allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
-	physinfo heap quirk readconsole writeconsole settime getcpuinfo
-	microcode cpupool_op pm_op tmem_control getscheduler setscheduler };
-allow dom0_t xen_t:mmu { memorymap };
-allow dom0_t security_t:security { check_context compute_av compute_create
-	compute_member load_policy compute_relabel compute_user setenforce
-	setbool setsecparam add_ocontext del_ocontext };
-
-allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
+allow dom0_t xen_t:xen {
+	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
+	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
+	writeapic privprofile nonprivprofile kexec firmware sleep frequency
+	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
+	tmem_control getscheduler setscheduler
+};
+allow dom0_t xen_t:mmu memorymap;
+
+# Allow dom0 to use these domctls on itself. For domctls acting on other
+# domains, see the definitions of create_domain and manage_domain.
+allow dom0_t dom0_t:domain {
+	setvcpucontext max_vcpus setvcpuaffinity getvcpuaffinity getscheduler
+	getdomaininfo getvcpuinfo getvcpucontext setdomainmaxmem setdomainhandle
+	setdebugging hypercall settime setaddrsize getaddrsize trigger
+	getextvcpucontext setextvcpucontext getvcpuextstate setvcpuextstate
+	getpodtarget setpodtarget set_misc_info set_virq_handler
+};
+allow dom0_t dom0_t:domain2 {
+	set_cpuid gettsc settsc setscheduler
+};
 allow dom0_t dom0_t:resource { add remove };
 
+# These permissions allow using the FLASK security server to compute access
+# checks locally, which could be used by a domain or service (such as xenstore)
+# that does not have its own security server to make access decisions based on
+# Xen's security policy.
+allow dom0_t security_t:security {
+	compute_av compute_create compute_member compute_relabel compute_user
+};
+
+# Allow string/SID conversions (for "xl list -Z" and similar)
+allow dom0_t security_t:security check_context;
+
+# Allow flask-label-pci to add and change labels
+allow dom0_t security_t:security { add_ocontext del_ocontext };
+
+# Allow performance parameters of the security server to be tweaked
+allow dom0_t security_t:security setsecparam;
+
+# Allow changing the security policy
+allow dom0_t security_t:security { load_policy setenforce setbool };
+
+# Audit policy change events even when they are allowed
+auditallow dom0_t security_t:security { load_policy setenforce setbool };
+
 admin_device(dom0_t, device_t)
 admin_device(dom0_t, irq_t)
 admin_device(dom0_t, ioport_t)
@@ -72,8 +110,6 @@ admin_device(dom0_t, iomem_t)
 
 domain_comms(dom0_t, dom0_t)
 
-auditallow dom0_t security_t:security { load_policy setenforce setbool };
-
 # Allow all domains to use (unprivileged parts of) the tmem hypercall
 allow domain_type xen_t:xen tmem_op;
 
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:01:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:01: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 1U5emN-0000Ot-IY; Wed, 13 Feb 2013 16:01:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1U5emM-0000Of-95
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:01:50 +0000
Received: from [193.109.254.147:55198] by server-8.bemta-14.messagelabs.com id
	9D/4D-17325-DE8BB115; Wed, 13 Feb 2013 16:01:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360771300!11047759!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11256 invoked from network); 13 Feb 2013 16:01:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 16:01:41 -0000
X-TM-IMSS-Message-ID: <57846bab0000d38f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov
	([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	57846bab0000d38f ; Wed, 13 Feb 2013 11:00:28 -0500
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [192.168.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DG1cCb015710; 
	Wed, 13 Feb 2013 11:01:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 13 Feb 2013 11:01:32 -0500
Message-Id: <1360771294-11763-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.8.1.2
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/3] flask/policy: sort dom0 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>
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 the example policy shipped with Xen, it makes sense to allow dom0
access to all system calls so that policy does not need to be updated
for each new hypervisor or toolstack feature used.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te | 60 ++++++++++++++++++++++------
 1 file changed, 48 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 955fd8b..454e27e 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -51,20 +51,58 @@ type device_t, resource_type;
 
 ################################################################################
 #
-# Rules required to boot the hypervisor and dom0
+# Allow dom0 access to all sysctls, devices, and the security server.
+#
+# While this could be written more briefly using wildcards, the permissions are
+# listed out to make removing specific permissions simpler.
 #
 ################################################################################
-allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
-	physinfo heap quirk readconsole writeconsole settime getcpuinfo
-	microcode cpupool_op pm_op tmem_control getscheduler setscheduler };
-allow dom0_t xen_t:mmu { memorymap };
-allow dom0_t security_t:security { check_context compute_av compute_create
-	compute_member load_policy compute_relabel compute_user setenforce
-	setbool setsecparam add_ocontext del_ocontext };
-
-allow dom0_t dom0_t:domain { getdomaininfo getvcpuinfo getvcpuaffinity };
+allow dom0_t xen_t:xen {
+	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
+	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
+	writeapic privprofile nonprivprofile kexec firmware sleep frequency
+	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
+	tmem_control getscheduler setscheduler
+};
+allow dom0_t xen_t:mmu memorymap;
+
+# Allow dom0 to use these domctls on itself. For domctls acting on other
+# domains, see the definitions of create_domain and manage_domain.
+allow dom0_t dom0_t:domain {
+	setvcpucontext max_vcpus setvcpuaffinity getvcpuaffinity getscheduler
+	getdomaininfo getvcpuinfo getvcpucontext setdomainmaxmem setdomainhandle
+	setdebugging hypercall settime setaddrsize getaddrsize trigger
+	getextvcpucontext setextvcpucontext getvcpuextstate setvcpuextstate
+	getpodtarget setpodtarget set_misc_info set_virq_handler
+};
+allow dom0_t dom0_t:domain2 {
+	set_cpuid gettsc settsc setscheduler
+};
 allow dom0_t dom0_t:resource { add remove };
 
+# These permissions allow using the FLASK security server to compute access
+# checks locally, which could be used by a domain or service (such as xenstore)
+# that does not have its own security server to make access decisions based on
+# Xen's security policy.
+allow dom0_t security_t:security {
+	compute_av compute_create compute_member compute_relabel compute_user
+};
+
+# Allow string/SID conversions (for "xl list -Z" and similar)
+allow dom0_t security_t:security check_context;
+
+# Allow flask-label-pci to add and change labels
+allow dom0_t security_t:security { add_ocontext del_ocontext };
+
+# Allow performance parameters of the security server to be tweaked
+allow dom0_t security_t:security setsecparam;
+
+# Allow changing the security policy
+allow dom0_t security_t:security { load_policy setenforce setbool };
+
+# Audit policy change events even when they are allowed
+auditallow dom0_t security_t:security { load_policy setenforce setbool };
+
 admin_device(dom0_t, device_t)
 admin_device(dom0_t, irq_t)
 admin_device(dom0_t, ioport_t)
@@ -72,8 +110,6 @@ admin_device(dom0_t, iomem_t)
 
 domain_comms(dom0_t, dom0_t)
 
-auditallow dom0_t security_t:security { load_policy setenforce setbool };
-
 # Allow all domains to use (unprivileged parts of) the tmem hypercall
 allow domain_type xen_t:xen tmem_op;
 
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:14:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:14: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 1U5eyk-000153-3N; Wed, 13 Feb 2013 16:14:38 +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 1U5eyi-00014y-Bi
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:14:36 +0000
Received: from [85.158.143.35:36549] by server-1.bemta-4.messagelabs.com id
	67/1A-08839-BEBBB115; Wed, 13 Feb 2013 16:14:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360771524!10187440!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8321 invoked from network); 13 Feb 2013 16:05:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 16:05:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 16:05:19 +0000
Message-Id: <511BC80702000078000BDFA8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 16:06:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>,<keir@xen.org>
References: <1360770888-11644-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1360770888-11644-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/flask: fix crash on debugkey "i"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:54, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> The IRQs beyond nr_static_irqs do not all have an associated PCI device,
> so only query the device SID if pci is not NULL.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  xen/xsm/flask/hooks.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 85d009c..29a78dd 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -110,7 +110,7 @@ static int get_irq_sid(int irq, u32 *sid, struct 
> avc_audit_data *ad)
>          }
>          return security_irq_sid(irq, sid);
>      }
> -    if ( desc->msi_desc ) {
> +    if ( desc->msi_desc && desc->msi_desc->dev ) {
>          struct pci_dev *dev = desc->msi_desc->dev;
>          u32 sbdf = (dev->seg << 16) | (dev->bus << 8) | dev->devfn;
>          if (ad) {
> -- 
> 1.8.1.2
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 13 16:14:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:14: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 1U5eyk-000153-3N; Wed, 13 Feb 2013 16:14:38 +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 1U5eyi-00014y-Bi
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:14:36 +0000
Received: from [85.158.143.35:36549] by server-1.bemta-4.messagelabs.com id
	67/1A-08839-BEBBB115; Wed, 13 Feb 2013 16:14:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360771524!10187440!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8321 invoked from network); 13 Feb 2013 16:05:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 16:05:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 16:05:19 +0000
Message-Id: <511BC80702000078000BDFA8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 16:06:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>,<keir@xen.org>
References: <1360770888-11644-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1360770888-11644-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/flask: fix crash on debugkey "i"
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:54, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> The IRQs beyond nr_static_irqs do not all have an associated PCI device,
> so only query the device SID if pci is not NULL.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  xen/xsm/flask/hooks.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 85d009c..29a78dd 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -110,7 +110,7 @@ static int get_irq_sid(int irq, u32 *sid, struct 
> avc_audit_data *ad)
>          }
>          return security_irq_sid(irq, sid);
>      }
> -    if ( desc->msi_desc ) {
> +    if ( desc->msi_desc && desc->msi_desc->dev ) {
>          struct pci_dev *dev = desc->msi_desc->dev;
>          u32 sbdf = (dev->seg << 16) | (dev->bus << 8) | dev->devfn;
>          if (ad) {
> -- 
> 1.8.1.2
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 13 16:39:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:39: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 1U5fMX-0001Wk-HM; Wed, 13 Feb 2013 16:39:13 +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 1U5fMV-0001Wf-Sn
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:39:12 +0000
Received: from [85.158.137.99:42401] by server-12.bemta-3.messagelabs.com id
	CB/EC-05889-EA1CB115; Wed, 13 Feb 2013 16:39:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360773550!21207914!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30794 invoked from network); 13 Feb 2013 16:39:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 16:39:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 16:39:09 +0000
Message-Id: <511BCFF502000078000BDFCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 16:40:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
In-Reply-To: <511AFFC9.3050404@theshore.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13.02.13 at 03:51, "Christopher S. Aker" <caker@theshore.net> wrote:
> Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
> Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
> <--------------
> Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
>...
> Feb 12 20:34:12: Call Trace:
> Feb 12 20:34:12: [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
> Feb 12 20:34:12: [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
> Feb 12 20:34:12: [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
> Feb 12 20:34:12: [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
> Feb 12 20:34:12: [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
> Feb 12 20:34:12: [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
> Feb 12 20:34:12: [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
> Feb 12 20:34:12: [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
> Feb 12 20:34:12: [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
> Feb 12 20:34:12: [<ffffffff81071a06>] kthread+0xc6/0xd0
> Feb 12 20:34:12: [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
> Feb 12 20:34:12: [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
> Feb 12 20:34:12: [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
> Feb 12 20:34:12: [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70

I think the root cause is the same as for the problem reported on
the !classic" kernels - we should not blindly shut down everything
on a fatal error. Instead I think we ought to set a flag on the
xenvif and disassociate the two in a more controlled manner. On
the pv-ops tree, that would likely be just at the bottom of the
main loop in xen_netbk_kthread(), with the caveat that there
needs to be a way to identify the busted xenvif(s).

On the classic tree, this apparently could be done directly in
net_tx_action() (and hence can be done in netbk_fatal_tx_err()
in place of the call to xenvif_carrier_off()), but the scheduled
piece of code would then need to sync with both tasklets. Of
course there's nothing preventing the pv-ops solution to be
similar to this (allowing easier adding back of tasklet support,
which - as I already told you elsewhere - appears to address
throughput and/or CPU utilization problems people reported to
us with the kthreads approach).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:39:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16:39: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 1U5fMX-0001Wk-HM; Wed, 13 Feb 2013 16:39:13 +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 1U5fMV-0001Wf-Sn
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 16:39:12 +0000
Received: from [85.158.137.99:42401] by server-12.bemta-3.messagelabs.com id
	CB/EC-05889-EA1CB115; Wed, 13 Feb 2013 16:39:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360773550!21207914!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30794 invoked from network); 13 Feb 2013 16:39:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 16:39:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 13 Feb 2013 16:39:09 +0000
Message-Id: <511BCFF502000078000BDFCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 13 Feb 2013 16:40:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
In-Reply-To: <511AFFC9.3050404@theshore.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13.02.13 at 03:51, "Christopher S. Aker" <caker@theshore.net> wrote:
> Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
> Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
> <--------------
> Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference at 00000000000008b8
>...
> Feb 12 20:34:12: Call Trace:
> Feb 12 20:34:12: [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
> Feb 12 20:34:12: [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
> Feb 12 20:34:12: [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
> Feb 12 20:34:12: [<ffffffff815445eb>] netbk_tx_err+0x5b/0x70
> Feb 12 20:34:12: [<ffffffff8154518c>] xen_netbk_tx_build_gops+0xb8c/0xbc0
> Feb 12 20:34:12: [<ffffffff81012880>] ? __switch_to+0x160/0x4f0
> Feb 12 20:34:12: [<ffffffff810891b8>] ? idle_balance+0xf8/0x150
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff8175f7b4>] ? __schedule+0x394/0x750
> Feb 12 20:34:12: [<ffffffff815452af>] xen_netbk_kthread+0xef/0x9d0
> Feb 12 20:34:12: [<ffffffff81080150>] ? finish_task_switch+0x60/0xd0
> Feb 12 20:34:12: [<ffffffff810720c0>] ? wake_up_bit+0x40/0x40
> Feb 12 20:34:12: [<ffffffff815451c0>] ? xen_netbk_tx_build_gops+0xbc0/0xbc0
> Feb 12 20:34:12: [<ffffffff81071a06>] kthread+0xc6/0xd0
> Feb 12 20:34:12: [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20
> Feb 12 20:34:12: [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70
> Feb 12 20:34:12: [<ffffffff8176847c>] ret_from_fork+0x7c/0xb0
> Feb 12 20:34:12: [<ffffffff81071940>] ? kthread_freezable_should_stop+0x70/0x70

I think the root cause is the same as for the problem reported on
the !classic" kernels - we should not blindly shut down everything
on a fatal error. Instead I think we ought to set a flag on the
xenvif and disassociate the two in a more controlled manner. On
the pv-ops tree, that would likely be just at the bottom of the
main loop in xen_netbk_kthread(), with the caveat that there
needs to be a way to identify the busted xenvif(s).

On the classic tree, this apparently could be done directly in
net_tx_action() (and hence can be done in netbk_fatal_tx_err()
in place of the call to xenvif_carrier_off()), but the scheduled
piece of code would then need to sync with both tasklets. Of
course there's nothing preventing the pv-ops solution to be
similar to this (allowing easier adding back of tasklet support,
which - as I already told you elsewhere - appears to address
throughput and/or CPU utilization problems people reported to
us with the kthreads approach).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 16:51:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16: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 1U5fYJ-0001la-HM; Wed, 13 Feb 2013 16:51:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U5fYH-0001lH-VA; Wed, 13 Feb 2013 16:51:22 +0000
Received: from [85.158.143.35:32056] by server-3.bemta-4.messagelabs.com id
	66/97-08920-984CB115; Wed, 13 Feb 2013 16:51:21 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360774248!10193618!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14092 invoked from network); 13 Feb 2013 16:50:50 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2013 16:50:50 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U5fXd-0000EK-Hh; Wed, 13 Feb 2013 16:50:41 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U5fXd-0004ML-2n; Wed, 13 Feb 2013 16:50:41 +0000
Date: Wed, 13 Feb 2013 16:50:41 +0000
Message-Id: <E1U5fXd-0004ML-2n@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 42 (CVE-2013-0228) - Linux kernel
 hits general protection if %ds is corrupt for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2013-0228 / XSA-42
                            version 2

 Linux kernel hits general protection if %ds is corrupt for 32-bit PVOPS.


UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

Linux kernel when returning from an iret assumes that %ds segment is safe
and uses it to reference various per-cpu related fields. Unfortunately
the user can modify the LDT and provide a NULL one. Whenever an iret is called
we end up in xen_iret and try to use the %ds segment and cause an
general protection fault.

IMPACT
======

Malicious or buggy unprivileged user space can cause the guest kernel to
crash, or permit a privilege escalation within the guest, or operate
erroneously.

VULNERABLE SYSTEMS
==================

All 32bit PVOPS versions of Linux are affected, since the introduction
of Xen PVOPS support in 2.6.23.  Classic-Xen kernels are not vulnerable.

MITIGATION
==========

This can be mitigated by not running 32bit PVOPS Linux guests.

32bit classic-Xen guests, all 64bit PV guests and all HVM guests are
unaffected.


RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.


$ sha256sum xsa42*.patch
a931fdc161653fb1a3a6d8c1cf6d2c9954c5aec134b610be6e9699552a659eb8  xsa42-pvops-0001-x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRG8PxAAoJEIP+FMlX6CvZC3gH/0v/9nr3jXbsMHZlkBRtCx9n
np1ed8btQGpmmk/WqbyLj/KcTNlXLIa1zwhTSPUgXlVIoDPuzstfGXm96gBNfYhS
hl56QYTruhHPAvvrAwE8SNIlMUH+n7Wq1BThkXFU1yBnjXxzTi4SdmUwy4gAA/SE
Xp35RAcIV6IwLRMMY12aat7XKnVx4S5n+gCC5eu0WZ+n73Ecrlqmsq+2X2ZHo3wP
nu9UN+PChmBJHfcA8OhelY/X4X4DV1HNPuFkj9ypyPrvXIrl6M0D5TfGoyRNXMHq
izAn51ro8gTGND6xY+s3auelquKiJkyl/5AXnfd0y9bSewGJS6oxoRzFdctJqxM=
=mgHb
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream;
 name="xsa42-pvops-0001-x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32.patch"
Content-Disposition: attachment;
 filename="xsa42-pvops-0001-x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32.patch"
Content-Transfer-Encoding: base64

RnJvbSA5OGUwODljNWYyM2IzNmRiNDE1ZDBhNGMzODU0ZTk2OWM3YTRlY2Zh
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKYW4gQmV1bGljaCA8
SkJldWxpY2hAc3VzZS5jb20+CkRhdGU6IFRodSwgMjQgSmFuIDIwMTMgMTM6
MTE6MTAgKzAwMDAKU3ViamVjdDogW1BBVENIXSB4ODYveGVuOiBkb24ndCBh
c3N1bWUgJWRzIGlzIHVzYWJsZSBpbiB4ZW5faXJldCBmb3IgMzItYml0CiBQ
Vk9QUy4KClRoaXMgZml4ZXMgQ1ZFLTIwMTMtMDIyOCAvIFhTQS00MgoKRHJl
dyBKb25lcyB3aGlsZSB3b3JraW5nIG9uIENWRS0yMDEzLTAxOTAgZm91bmQg
dGhhdCB0aGF0IHVucHJpdmlsZWdlZCBndWVzdCB1c2VyCmluIDMyYml0IFBW
IGd1ZXN0IGNhbiB1c2UgdG8gY3Jhc2ggdGhlID4gZ3Vlc3Qgd2l0aCB0aGUg
cGFuaWMgbGlrZSB0aGlzOgoKLS0tLS0tLS0tLS0tLQpnZW5lcmFsIHByb3Rl
Y3Rpb24gZmF1bHQ6IDAwMDAgWyMxXSBTTVAKbGFzdCBzeXNmcyBmaWxlOiAv
c3lzL2RldmljZXMvdmJkLTUxNzEyL2Jsb2NrL3h2ZGEvZGV2Ck1vZHVsZXMg
bGlua2VkIGluOiBzdW5ycGMgaXB0X1JFSkVDVCBuZl9jb25udHJhY2tfaXB2
NCBuZl9kZWZyYWdfaXB2NAppcHRhYmxlX2ZpbHRlciBpcF90YWJsZXMgaXA2
dF9SRUpFQ1QgbmZfY29ubnRyYWNrX2lwdjYgbmZfZGVmcmFnX2lwdjYKeHRf
c3RhdGUgbmZfY29ubnRyYWNrIGlwNnRhYmxlX2ZpbHRlciBpcDZfdGFibGVz
IGlwdjYgeGVuX25ldGZyb250IGV4dDQKbWJjYWNoZSBqYmQyIHhlbl9ibGtm
cm9udCBkbV9taXJyb3IgZG1fcmVnaW9uX2hhc2ggZG1fbG9nIGRtX21vZCBb
bGFzdAp1bmxvYWRlZDogc2NzaV93YWl0X3NjYW5dCgpQaWQ6IDEyNTAsIGNv
bW06IHIgTm90IHRhaW50ZWQgMi42LjMyLTM1Ni5lbDYuaTY4NiAjMQpFSVA6
IDAwNjE6WzxjMDQwNzQ2Mj5dIEVGTEFHUzogMDAwMTAwODYgQ1BVOiAwCkVJ
UCBpcyBhdCB4ZW5faXJldCsweDEyLzB4MmIKRUFYOiBlYjhkMDAwMCBFQlg6
IDAwMDAwMDAxIEVDWDogMDgwNDk4NjAgRURYOiAwMDAwMDAxMApFU0k6IDAw
MDAwMDAwIEVESTogMDAzZDBmMDAgRUJQOiBiNzdmODM4OCBFU1A6IGViOGQx
ZmUwCiBEUzogMDAwMCBFUzogMDA3YiBGUzogMDAwMCBHUzogMDBlMCBTUzog
MDA2OQpQcm9jZXNzIHIgKHBpZDogMTI1MCwgdGk9ZWI4ZDAwMDAgdGFzaz1j
Mjk1MzU1MCB0YXNrLnRpPWViOGQwMDAwKQpTdGFjazoKIDAwMDAwMDAwIDAw
MjdmNDE2IDAwMDAwMDczIDAwMDAwMjA2IGI3N2Y4MzY0IDAwMDAwMDdiIDAw
MDAwMDAwIDAwMDAwMDAwCkNhbGwgVHJhY2U6CkNvZGU6IGMzIDhiIDQ0IDI0
IDE4IDgxIDRjIDI0IDM4IDAwIDAyIDAwIDAwIDhkIDY0IDI0IDMwIGU5IDAz
IDAwIDAwIDAwCjhkIDc2IDAwIGY3IDQ0IDI0IDA4IDAwIDAwIDAyIDgwIDc1
IDMzIDUwIGI4IDAwIGUwIGZmIGZmIDIxIGUwIDw4Yj4gNDAKMTAgOGIgMDQg
ODUgYTAgZjYgYWIgYzAgOGIgODAgMGMgYjAgYjMgYzAgZjYgNDQgMjQgMGQg
MDIKRUlQOiBbPGMwNDA3NDYyPl0geGVuX2lyZXQrMHgxMi8weDJiIFNTOkVT
UCAwMDY5OmViOGQxZmUwCmdlbmVyYWwgcHJvdGVjdGlvbiBmYXVsdDogMDAw
MCBbIzJdCi0tLVsgZW5kIHRyYWNlIGFiMGQyOWE0OTJkY2QzMzAgXS0tLQpL
ZXJuZWwgcGFuaWMgLSBub3Qgc3luY2luZzogRmF0YWwgZXhjZXB0aW9uClBp
ZDogMTI1MCwgY29tbTogciBUYWludGVkOiBHICAgICAgRCAgICAtLS0tLS0t
LS0tLS0tLS0KMi42LjMyLTM1Ni5lbDYuaTY4NiAjMQpDYWxsIFRyYWNlOgog
WzxjMDg0NzZkZj5dID8gcGFuaWMrMHg2ZS8weDEyMgogWzxjMDg0YjYzYz5d
ID8gb29wc19lbmQrMHhiYy8weGQwCiBbPGMwODRiMjYwPl0gPyBkb19nZW5l
cmFsX3Byb3RlY3Rpb24rMHgwLzB4MjEwCiBbPGMwODRhOWI3Pl0gPyBlcnJv
cl9jb2RlKzB4NzMvCi0tLS0tLS0tLS0tLS0KClBldHIgc2F5czogIgogSSd2
ZSBhbmFseXNlZCB0aGUgYnVnIGFuZCBJIHRoaW5rIHRoYXQgeGVuX2lyZXQo
KSBjYW5ub3QgY29wZSB3aXRoCiBtYW5nbGVkIERTLCBpbiB0aGlzIGNhc2Ug
emVyb2VkIG91dCAobnVsbCBzZWxlY3Rvci9kZXNjcmlwdG9yKSBieSBlaXRo
ZXIKIHhlbl9mYWlsc2FmZV9jYWxsYmFjaygpIG9yIFJFU1RPUkVfUkVHUyBi
ZWNhdXNlIHRoZSBjb3JyZXNwb25kaW5nIExEVAogZW50cnkgd2FzIGludmFs
aWRhdGVkIGJ5IHRoZSByZXByb2R1Y2VyLiAiCgpKYW4gdG9vayBhIGxvb2sg
YXQgdGhlIHByZWxpbWluYXJ5IHBhdGNoIGFuZCBjYW1lIHVwIGEgZml4IHRo
YXQgc29sdmVzCnRoaXMgcHJvYmxlbToKCiJUaGlzIGNvZGUgZ2V0cyBjYWxs
ZWQgYWZ0ZXIgYWxsIHJlZ2lzdGVycyBvdGhlciB0aGFuIHRob3NlIGhhbmRs
ZWQgYnkKSVJFVCBnb3QgYWxyZWFkeSByZXN0b3JlZCwgaGVuY2UgYSBudWxs
IHNlbGVjdG9yIGluICVkcyBvciBhIG5vbi1udWxsCm9uZSB0aGF0IGdvdCBs
b2FkZWQgZnJvbSBhIGNvZGUgb3IgcmVhZC1vbmx5IGRhdGEgZGVzY3JpcHRv
ciB3b3VsZApjYXVzZSBhIGtlcm5lbCBtb2RlIGZhdWx0ICh3aXRoIHRoZSBw
b3RlbnRpYWwgb2YgY3Jhc2hpbmcgdGhlIGtlcm5lbAphcyBhIHdob2xlLCBp
ZiBwYW5pY19vbl9vb3BzIGlzIHNldCkuIgoKVGhlIHdheSB0byBmaXggdGhp
cyBpcyB0byByZWFsaXplIHRoYXQgdGhlIHdlIGNhbiBvbmx5IHJlbGF5IG9u
IHRoZQpyZWdpc3RlcnMgdGhhdCBJUkVUIHJlc3RvcmVzLiBUaGUgdHdvIHRo
YXQgYXJlIGd1YXJhbnRlZWQgYXJlIHRoZQolY3MgYW5kICVzcyBhcyB0aGV5
IGFyZSBhbHdheXMgZml4ZWQgR0RUIHNlbGVjdG9ycy4gQWxzbyB0aGV5IGFy
ZQppbmFjY2Vzc2libGUgZnJvbSB1c2VyIG1vZGUgLSBzbyB0aGV5IGNhbm5v
dCBiZSBhbHRlcmVkLiBUaGlzIGlzCnRoZSBhcHByb2FjaCB0YWtlbiBpbiB0
aGlzIHBhdGNoLgoKQW5vdGhlciBhbHRlcm5hdGl2ZSBvcHRpb24gc3VnZ2Vz
dGVkIGJ5IEphbiB3b3VsZCBiZSB0byByZWxheSBvbgp0aGUgc3VidGxlIHJl
YWxpemF0aW9uIHRoYXQgdXNpbmcgdGhlICVlYnAgb3IgJWVzcCByZWxhdGl2
ZSByZWZlcmVuY2VzIHVzZXMKdGhlICVzcyBzZWdtZW50LiAgSW4gd2hpY2gg
Y2FzZSB3ZSBjb3VsZCBzd2l0Y2ggZnJvbSB1c2luZyAlZWF4IHRvICVlYnAg
YW5kCndvdWxkIG5vdCBuZWVkIHRoZSAlc3Mgb3Zlci1yaWRlcy4gVGhhdCB3
b3VsZCBhbHNvIHJlcXVpcmUgb25lIGV4dHJhCmluc3RydWN0aW9uIHRvIGNv
bXBlbnNhdGUgZm9yIHRoZSBvbmUgcGxhY2Ugd2hlcmUgdGhlIHJlZ2lzdGVy
IGlzIHVzZWQKYXMgc2NhbGVkIGluZGV4LiBIb3dldmVyIEFuZHJldyBwb2lu
dGVkIG91dCB0aGF0IGlzIHRvbyBzdWJ0bGUgYW5kIGlmCmZ1cnRoZXIgd29y
ayB3YXMgdG8gYmUgZG9uZSBpbiB0aGlzIGNvZGUtcGF0aCBpdCBjb3VsZCBl
c2NhcGUgZm9sa3MgYXR0ZW50aW9uCmFuZCBsZWFkIHRvIGFjY2lkZW50cy4K
ClJldmlld2VkLWJ5OiBQZXRyIE1hdG91c2VrIDxwbWF0b3VzZUByZWRoYXQu
Y29tPgpSZXBvcnRlZC1ieTogUGV0ciBNYXRvdXNlayA8cG1hdG91c2VAcmVk
aGF0LmNvbT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5j
b29wZXIzQGNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNo
IDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0KIGFy
Y2gveDg2L3hlbi94ZW4tYXNtXzMyLlMgfCAxNCArKysrKysrLS0tLS0tLQog
MSBmaWxlIGNoYW5nZWQsIDcgaW5zZXJ0aW9ucygrKSwgNyBkZWxldGlvbnMo
LSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4veGVuLWFzbV8zMi5TIGIv
YXJjaC94ODYveGVuL3hlbi1hc21fMzIuUwppbmRleCBmOTY0M2ZjLi4zM2Nh
NmU0IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4veGVuLWFzbV8zMi5TCisr
KyBiL2FyY2gveDg2L3hlbi94ZW4tYXNtXzMyLlMKQEAgLTg5LDExICs4OSwx
MSBAQCBFTlRSWSh4ZW5faXJldCkKIAkgKi8KICNpZmRlZiBDT05GSUdfU01Q
CiAJR0VUX1RIUkVBRF9JTkZPKCVlYXgpCi0JbW92bCBUSV9jcHUoJWVheCks
ICVlYXgKLQltb3ZsIF9fcGVyX2NwdV9vZmZzZXQoLCVlYXgsNCksICVlYXgK
LQltb3YgeGVuX3ZjcHUoJWVheCksICVlYXgKKwltb3ZsICVzczpUSV9jcHUo
JWVheCksICVlYXgKKwltb3ZsICVzczpfX3Blcl9jcHVfb2Zmc2V0KCwlZWF4
LDQpLCAlZWF4CisJbW92ICVzczp4ZW5fdmNwdSglZWF4KSwgJWVheAogI2Vs
c2UKLQltb3ZsIHhlbl92Y3B1LCAlZWF4CisJbW92bCAlc3M6eGVuX3ZjcHUs
ICVlYXgKICNlbmRpZgogCiAJLyogY2hlY2sgSUYgc3RhdGUgd2UncmUgcmVz
dG9yaW5nICovCkBAIC0xMDYsMTEgKzEwNiwxMSBAQCBFTlRSWSh4ZW5faXJl
dCkKIAkgKiByZXN1bWluZyB0aGUgY29kZSwgc28gd2UgZG9uJ3QgaGF2ZSB0
byBiZSB3b3JyaWVkIGFib3V0CiAJICogYmVpbmcgcHJlZW1wdGVkIHRvIGFu
b3RoZXIgQ1BVLgogCSAqLwotCXNldHogWEVOX3ZjcHVfaW5mb19tYXNrKCVl
YXgpCisJc2V0eiAlc3M6WEVOX3ZjcHVfaW5mb19tYXNrKCVlYXgpCiB4ZW5f
aXJldF9zdGFydF9jcml0OgogCiAJLyogY2hlY2sgZm9yIHVubWFza2VkIGFu
ZCBwZW5kaW5nICovCi0JY21wdyAkMHgwMDAxLCBYRU5fdmNwdV9pbmZvX3Bl
bmRpbmcoJWVheCkKKwljbXB3ICQweDAwMDEsICVzczpYRU5fdmNwdV9pbmZv
X3BlbmRpbmcoJWVheCkKIAogCS8qCiAJICogSWYgdGhlcmUncyBzb21ldGhp
bmcgcGVuZGluZywgbWFzayBldmVudHMgYWdhaW4gc28gd2UgY2FuCkBAIC0x
MTgsNyArMTE4LDcgQEAgeGVuX2lyZXRfc3RhcnRfY3JpdDoKIAkgKiB0b3Vj
aCBYRU5fdmNwdV9pbmZvX21hc2suCiAJICovCiAJam5lIDFmCi0JbW92YiAk
MSwgWEVOX3ZjcHVfaW5mb19tYXNrKCVlYXgpCisJbW92YiAkMSwgJXNzOlhF
Tl92Y3B1X2luZm9fbWFzayglZWF4KQogCiAxOglwb3BsICVlYXgKIAotLSAK
MS44LjAuMgoK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Wed Feb 13 16:51:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 16: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 1U5fYJ-0001la-HM; Wed, 13 Feb 2013 16:51:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U5fYH-0001lH-VA; Wed, 13 Feb 2013 16:51:22 +0000
Received: from [85.158.143.35:32056] by server-3.bemta-4.messagelabs.com id
	66/97-08920-984CB115; Wed, 13 Feb 2013 16:51:21 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360774248!10193618!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14092 invoked from network); 13 Feb 2013 16:50:50 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2013 16:50:50 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U5fXd-0000EK-Hh; Wed, 13 Feb 2013 16:50:41 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U5fXd-0004ML-2n; Wed, 13 Feb 2013 16:50:41 +0000
Date: Wed, 13 Feb 2013 16:50:41 +0000
Message-Id: <E1U5fXd-0004ML-2n@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 42 (CVE-2013-0228) - Linux kernel
 hits general protection if %ds is corrupt for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2013-0228 / XSA-42
                            version 2

 Linux kernel hits general protection if %ds is corrupt for 32-bit PVOPS.


UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

Linux kernel when returning from an iret assumes that %ds segment is safe
and uses it to reference various per-cpu related fields. Unfortunately
the user can modify the LDT and provide a NULL one. Whenever an iret is called
we end up in xen_iret and try to use the %ds segment and cause an
general protection fault.

IMPACT
======

Malicious or buggy unprivileged user space can cause the guest kernel to
crash, or permit a privilege escalation within the guest, or operate
erroneously.

VULNERABLE SYSTEMS
==================

All 32bit PVOPS versions of Linux are affected, since the introduction
of Xen PVOPS support in 2.6.23.  Classic-Xen kernels are not vulnerable.

MITIGATION
==========

This can be mitigated by not running 32bit PVOPS Linux guests.

32bit classic-Xen guests, all 64bit PV guests and all HVM guests are
unaffected.


RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.


$ sha256sum xsa42*.patch
a931fdc161653fb1a3a6d8c1cf6d2c9954c5aec134b610be6e9699552a659eb8  xsa42-pvops-0001-x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRG8PxAAoJEIP+FMlX6CvZC3gH/0v/9nr3jXbsMHZlkBRtCx9n
np1ed8btQGpmmk/WqbyLj/KcTNlXLIa1zwhTSPUgXlVIoDPuzstfGXm96gBNfYhS
hl56QYTruhHPAvvrAwE8SNIlMUH+n7Wq1BThkXFU1yBnjXxzTi4SdmUwy4gAA/SE
Xp35RAcIV6IwLRMMY12aat7XKnVx4S5n+gCC5eu0WZ+n73Ecrlqmsq+2X2ZHo3wP
nu9UN+PChmBJHfcA8OhelY/X4X4DV1HNPuFkj9ypyPrvXIrl6M0D5TfGoyRNXMHq
izAn51ro8gTGND6xY+s3auelquKiJkyl/5AXnfd0y9bSewGJS6oxoRzFdctJqxM=
=mgHb
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream;
 name="xsa42-pvops-0001-x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32.patch"
Content-Disposition: attachment;
 filename="xsa42-pvops-0001-x86-xen-don-t-assume-ds-is-usable-in-xen_iret-for-32.patch"
Content-Transfer-Encoding: base64

RnJvbSA5OGUwODljNWYyM2IzNmRiNDE1ZDBhNGMzODU0ZTk2OWM3YTRlY2Zh
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKYW4gQmV1bGljaCA8
SkJldWxpY2hAc3VzZS5jb20+CkRhdGU6IFRodSwgMjQgSmFuIDIwMTMgMTM6
MTE6MTAgKzAwMDAKU3ViamVjdDogW1BBVENIXSB4ODYveGVuOiBkb24ndCBh
c3N1bWUgJWRzIGlzIHVzYWJsZSBpbiB4ZW5faXJldCBmb3IgMzItYml0CiBQ
Vk9QUy4KClRoaXMgZml4ZXMgQ1ZFLTIwMTMtMDIyOCAvIFhTQS00MgoKRHJl
dyBKb25lcyB3aGlsZSB3b3JraW5nIG9uIENWRS0yMDEzLTAxOTAgZm91bmQg
dGhhdCB0aGF0IHVucHJpdmlsZWdlZCBndWVzdCB1c2VyCmluIDMyYml0IFBW
IGd1ZXN0IGNhbiB1c2UgdG8gY3Jhc2ggdGhlID4gZ3Vlc3Qgd2l0aCB0aGUg
cGFuaWMgbGlrZSB0aGlzOgoKLS0tLS0tLS0tLS0tLQpnZW5lcmFsIHByb3Rl
Y3Rpb24gZmF1bHQ6IDAwMDAgWyMxXSBTTVAKbGFzdCBzeXNmcyBmaWxlOiAv
c3lzL2RldmljZXMvdmJkLTUxNzEyL2Jsb2NrL3h2ZGEvZGV2Ck1vZHVsZXMg
bGlua2VkIGluOiBzdW5ycGMgaXB0X1JFSkVDVCBuZl9jb25udHJhY2tfaXB2
NCBuZl9kZWZyYWdfaXB2NAppcHRhYmxlX2ZpbHRlciBpcF90YWJsZXMgaXA2
dF9SRUpFQ1QgbmZfY29ubnRyYWNrX2lwdjYgbmZfZGVmcmFnX2lwdjYKeHRf
c3RhdGUgbmZfY29ubnRyYWNrIGlwNnRhYmxlX2ZpbHRlciBpcDZfdGFibGVz
IGlwdjYgeGVuX25ldGZyb250IGV4dDQKbWJjYWNoZSBqYmQyIHhlbl9ibGtm
cm9udCBkbV9taXJyb3IgZG1fcmVnaW9uX2hhc2ggZG1fbG9nIGRtX21vZCBb
bGFzdAp1bmxvYWRlZDogc2NzaV93YWl0X3NjYW5dCgpQaWQ6IDEyNTAsIGNv
bW06IHIgTm90IHRhaW50ZWQgMi42LjMyLTM1Ni5lbDYuaTY4NiAjMQpFSVA6
IDAwNjE6WzxjMDQwNzQ2Mj5dIEVGTEFHUzogMDAwMTAwODYgQ1BVOiAwCkVJ
UCBpcyBhdCB4ZW5faXJldCsweDEyLzB4MmIKRUFYOiBlYjhkMDAwMCBFQlg6
IDAwMDAwMDAxIEVDWDogMDgwNDk4NjAgRURYOiAwMDAwMDAxMApFU0k6IDAw
MDAwMDAwIEVESTogMDAzZDBmMDAgRUJQOiBiNzdmODM4OCBFU1A6IGViOGQx
ZmUwCiBEUzogMDAwMCBFUzogMDA3YiBGUzogMDAwMCBHUzogMDBlMCBTUzog
MDA2OQpQcm9jZXNzIHIgKHBpZDogMTI1MCwgdGk9ZWI4ZDAwMDAgdGFzaz1j
Mjk1MzU1MCB0YXNrLnRpPWViOGQwMDAwKQpTdGFjazoKIDAwMDAwMDAwIDAw
MjdmNDE2IDAwMDAwMDczIDAwMDAwMjA2IGI3N2Y4MzY0IDAwMDAwMDdiIDAw
MDAwMDAwIDAwMDAwMDAwCkNhbGwgVHJhY2U6CkNvZGU6IGMzIDhiIDQ0IDI0
IDE4IDgxIDRjIDI0IDM4IDAwIDAyIDAwIDAwIDhkIDY0IDI0IDMwIGU5IDAz
IDAwIDAwIDAwCjhkIDc2IDAwIGY3IDQ0IDI0IDA4IDAwIDAwIDAyIDgwIDc1
IDMzIDUwIGI4IDAwIGUwIGZmIGZmIDIxIGUwIDw4Yj4gNDAKMTAgOGIgMDQg
ODUgYTAgZjYgYWIgYzAgOGIgODAgMGMgYjAgYjMgYzAgZjYgNDQgMjQgMGQg
MDIKRUlQOiBbPGMwNDA3NDYyPl0geGVuX2lyZXQrMHgxMi8weDJiIFNTOkVT
UCAwMDY5OmViOGQxZmUwCmdlbmVyYWwgcHJvdGVjdGlvbiBmYXVsdDogMDAw
MCBbIzJdCi0tLVsgZW5kIHRyYWNlIGFiMGQyOWE0OTJkY2QzMzAgXS0tLQpL
ZXJuZWwgcGFuaWMgLSBub3Qgc3luY2luZzogRmF0YWwgZXhjZXB0aW9uClBp
ZDogMTI1MCwgY29tbTogciBUYWludGVkOiBHICAgICAgRCAgICAtLS0tLS0t
LS0tLS0tLS0KMi42LjMyLTM1Ni5lbDYuaTY4NiAjMQpDYWxsIFRyYWNlOgog
WzxjMDg0NzZkZj5dID8gcGFuaWMrMHg2ZS8weDEyMgogWzxjMDg0YjYzYz5d
ID8gb29wc19lbmQrMHhiYy8weGQwCiBbPGMwODRiMjYwPl0gPyBkb19nZW5l
cmFsX3Byb3RlY3Rpb24rMHgwLzB4MjEwCiBbPGMwODRhOWI3Pl0gPyBlcnJv
cl9jb2RlKzB4NzMvCi0tLS0tLS0tLS0tLS0KClBldHIgc2F5czogIgogSSd2
ZSBhbmFseXNlZCB0aGUgYnVnIGFuZCBJIHRoaW5rIHRoYXQgeGVuX2lyZXQo
KSBjYW5ub3QgY29wZSB3aXRoCiBtYW5nbGVkIERTLCBpbiB0aGlzIGNhc2Ug
emVyb2VkIG91dCAobnVsbCBzZWxlY3Rvci9kZXNjcmlwdG9yKSBieSBlaXRo
ZXIKIHhlbl9mYWlsc2FmZV9jYWxsYmFjaygpIG9yIFJFU1RPUkVfUkVHUyBi
ZWNhdXNlIHRoZSBjb3JyZXNwb25kaW5nIExEVAogZW50cnkgd2FzIGludmFs
aWRhdGVkIGJ5IHRoZSByZXByb2R1Y2VyLiAiCgpKYW4gdG9vayBhIGxvb2sg
YXQgdGhlIHByZWxpbWluYXJ5IHBhdGNoIGFuZCBjYW1lIHVwIGEgZml4IHRo
YXQgc29sdmVzCnRoaXMgcHJvYmxlbToKCiJUaGlzIGNvZGUgZ2V0cyBjYWxs
ZWQgYWZ0ZXIgYWxsIHJlZ2lzdGVycyBvdGhlciB0aGFuIHRob3NlIGhhbmRs
ZWQgYnkKSVJFVCBnb3QgYWxyZWFkeSByZXN0b3JlZCwgaGVuY2UgYSBudWxs
IHNlbGVjdG9yIGluICVkcyBvciBhIG5vbi1udWxsCm9uZSB0aGF0IGdvdCBs
b2FkZWQgZnJvbSBhIGNvZGUgb3IgcmVhZC1vbmx5IGRhdGEgZGVzY3JpcHRv
ciB3b3VsZApjYXVzZSBhIGtlcm5lbCBtb2RlIGZhdWx0ICh3aXRoIHRoZSBw
b3RlbnRpYWwgb2YgY3Jhc2hpbmcgdGhlIGtlcm5lbAphcyBhIHdob2xlLCBp
ZiBwYW5pY19vbl9vb3BzIGlzIHNldCkuIgoKVGhlIHdheSB0byBmaXggdGhp
cyBpcyB0byByZWFsaXplIHRoYXQgdGhlIHdlIGNhbiBvbmx5IHJlbGF5IG9u
IHRoZQpyZWdpc3RlcnMgdGhhdCBJUkVUIHJlc3RvcmVzLiBUaGUgdHdvIHRo
YXQgYXJlIGd1YXJhbnRlZWQgYXJlIHRoZQolY3MgYW5kICVzcyBhcyB0aGV5
IGFyZSBhbHdheXMgZml4ZWQgR0RUIHNlbGVjdG9ycy4gQWxzbyB0aGV5IGFy
ZQppbmFjY2Vzc2libGUgZnJvbSB1c2VyIG1vZGUgLSBzbyB0aGV5IGNhbm5v
dCBiZSBhbHRlcmVkLiBUaGlzIGlzCnRoZSBhcHByb2FjaCB0YWtlbiBpbiB0
aGlzIHBhdGNoLgoKQW5vdGhlciBhbHRlcm5hdGl2ZSBvcHRpb24gc3VnZ2Vz
dGVkIGJ5IEphbiB3b3VsZCBiZSB0byByZWxheSBvbgp0aGUgc3VidGxlIHJl
YWxpemF0aW9uIHRoYXQgdXNpbmcgdGhlICVlYnAgb3IgJWVzcCByZWxhdGl2
ZSByZWZlcmVuY2VzIHVzZXMKdGhlICVzcyBzZWdtZW50LiAgSW4gd2hpY2gg
Y2FzZSB3ZSBjb3VsZCBzd2l0Y2ggZnJvbSB1c2luZyAlZWF4IHRvICVlYnAg
YW5kCndvdWxkIG5vdCBuZWVkIHRoZSAlc3Mgb3Zlci1yaWRlcy4gVGhhdCB3
b3VsZCBhbHNvIHJlcXVpcmUgb25lIGV4dHJhCmluc3RydWN0aW9uIHRvIGNv
bXBlbnNhdGUgZm9yIHRoZSBvbmUgcGxhY2Ugd2hlcmUgdGhlIHJlZ2lzdGVy
IGlzIHVzZWQKYXMgc2NhbGVkIGluZGV4LiBIb3dldmVyIEFuZHJldyBwb2lu
dGVkIG91dCB0aGF0IGlzIHRvbyBzdWJ0bGUgYW5kIGlmCmZ1cnRoZXIgd29y
ayB3YXMgdG8gYmUgZG9uZSBpbiB0aGlzIGNvZGUtcGF0aCBpdCBjb3VsZCBl
c2NhcGUgZm9sa3MgYXR0ZW50aW9uCmFuZCBsZWFkIHRvIGFjY2lkZW50cy4K
ClJldmlld2VkLWJ5OiBQZXRyIE1hdG91c2VrIDxwbWF0b3VzZUByZWRoYXQu
Y29tPgpSZXBvcnRlZC1ieTogUGV0ciBNYXRvdXNlayA8cG1hdG91c2VAcmVk
aGF0LmNvbT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5j
b29wZXIzQGNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNo
IDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0KIGFy
Y2gveDg2L3hlbi94ZW4tYXNtXzMyLlMgfCAxNCArKysrKysrLS0tLS0tLQog
MSBmaWxlIGNoYW5nZWQsIDcgaW5zZXJ0aW9ucygrKSwgNyBkZWxldGlvbnMo
LSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4veGVuLWFzbV8zMi5TIGIv
YXJjaC94ODYveGVuL3hlbi1hc21fMzIuUwppbmRleCBmOTY0M2ZjLi4zM2Nh
NmU0IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4veGVuLWFzbV8zMi5TCisr
KyBiL2FyY2gveDg2L3hlbi94ZW4tYXNtXzMyLlMKQEAgLTg5LDExICs4OSwx
MSBAQCBFTlRSWSh4ZW5faXJldCkKIAkgKi8KICNpZmRlZiBDT05GSUdfU01Q
CiAJR0VUX1RIUkVBRF9JTkZPKCVlYXgpCi0JbW92bCBUSV9jcHUoJWVheCks
ICVlYXgKLQltb3ZsIF9fcGVyX2NwdV9vZmZzZXQoLCVlYXgsNCksICVlYXgK
LQltb3YgeGVuX3ZjcHUoJWVheCksICVlYXgKKwltb3ZsICVzczpUSV9jcHUo
JWVheCksICVlYXgKKwltb3ZsICVzczpfX3Blcl9jcHVfb2Zmc2V0KCwlZWF4
LDQpLCAlZWF4CisJbW92ICVzczp4ZW5fdmNwdSglZWF4KSwgJWVheAogI2Vs
c2UKLQltb3ZsIHhlbl92Y3B1LCAlZWF4CisJbW92bCAlc3M6eGVuX3ZjcHUs
ICVlYXgKICNlbmRpZgogCiAJLyogY2hlY2sgSUYgc3RhdGUgd2UncmUgcmVz
dG9yaW5nICovCkBAIC0xMDYsMTEgKzEwNiwxMSBAQCBFTlRSWSh4ZW5faXJl
dCkKIAkgKiByZXN1bWluZyB0aGUgY29kZSwgc28gd2UgZG9uJ3QgaGF2ZSB0
byBiZSB3b3JyaWVkIGFib3V0CiAJICogYmVpbmcgcHJlZW1wdGVkIHRvIGFu
b3RoZXIgQ1BVLgogCSAqLwotCXNldHogWEVOX3ZjcHVfaW5mb19tYXNrKCVl
YXgpCisJc2V0eiAlc3M6WEVOX3ZjcHVfaW5mb19tYXNrKCVlYXgpCiB4ZW5f
aXJldF9zdGFydF9jcml0OgogCiAJLyogY2hlY2sgZm9yIHVubWFza2VkIGFu
ZCBwZW5kaW5nICovCi0JY21wdyAkMHgwMDAxLCBYRU5fdmNwdV9pbmZvX3Bl
bmRpbmcoJWVheCkKKwljbXB3ICQweDAwMDEsICVzczpYRU5fdmNwdV9pbmZv
X3BlbmRpbmcoJWVheCkKIAogCS8qCiAJICogSWYgdGhlcmUncyBzb21ldGhp
bmcgcGVuZGluZywgbWFzayBldmVudHMgYWdhaW4gc28gd2UgY2FuCkBAIC0x
MTgsNyArMTE4LDcgQEAgeGVuX2lyZXRfc3RhcnRfY3JpdDoKIAkgKiB0b3Vj
aCBYRU5fdmNwdV9pbmZvX21hc2suCiAJICovCiAJam5lIDFmCi0JbW92YiAk
MSwgWEVOX3ZjcHVfaW5mb19tYXNrKCVlYXgpCisJbW92YiAkMSwgJXNzOlhF
Tl92Y3B1X2luZm9fbWFzayglZWF4KQogCiAxOglwb3BsICVlYXgKIAotLSAK
MS44LjAuMgoK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Wed Feb 13 17:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17: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 1U5fpG-0002sL-2y; Wed, 13 Feb 2013 17:08: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 1U5fpD-0002s9-PC
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 17:08:51 +0000
Received: from [85.158.137.99:16530] by server-2.bemta-3.messagelabs.com id
	DE/FD-25961-D98CB115; Wed, 13 Feb 2013 17:08:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360775324!20474976!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 13 Feb 2013 17:08:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 17:08:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="1427240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 17:08: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.297.1; Wed, 13 Feb 2013 17:08:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5fp3-000075-EZ; Wed, 13 Feb 2013 17:08:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5fp3-0005jy-AQ;
	Wed, 13 Feb 2013 17:08:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20763.51353.91324.851766@mariner.uk.xensource.com>
Date: Wed, 13 Feb 2013 17:08:41 +0000
To: <xen-devel@lists.xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 previously agreed, we will be moving the main Xen trees to git.
The existing .hg trees will continue to exist, but as hg mirrors of
the git history.  Committers will push to the git repo.

The new git tree will be this one:
  http://xenbits.xen.org/gitweb/?p=xen.git
  git://xenbits.xen.org/xen.git
For committers it will be accessible via
  xenbits.xen.org:/home/xen/git/xen.git

It has a branch corresponding to each xen*.hg tree:
  master                xen-unstable.hg
  stable-4.0            xen-4.0-testing.hg
  stable-4.1            xen-4.1-testing.hg
  stable-4.2            xen-4.2-testing.hg
  staging               staging/xen-unstable.hg
  staging-4.0           staging/xen-4.0-testing.hg
  staging-4.1           staging/xen-4.1-testing.hg
  staging-4.2           staging/xen-4.2-testing.hg

We have some background infrastructure work which needs to be complete
before we make this switch, but we are currently expecting/hoping this
to be ready next week.  We tentatively intend to make the switch on
Thursday the 13th of February, assuming none of the committers object.

Committers please note that if you have commits (patch queues) in hg
at this point, they will need to be transferred into git somehow to be
committed and pushed.  After the switch it will not be possible to
accept changes from hg, because we won't have bidirectional mirroring.

If at the point we make the change there are changes in staging that
have not propagated to the corresponding stable or master tree, this
situation will be preserved.  However, revision history will be broken
(by the difference in revision ids), which will slightly weaken the
autotester's push gate.  I therefore recommend that we avoid making
this change if we have a big or scary backlog in any staging tree.

People posting and approving patches, including maintainers, are not
directly affected.

The process will be as follows:
  1. Autotester push gate shut down
  2. Announcement and coordination with committers
  3. hg trees made read-only (other than by forthcoming git->hg mirror)
  4. hg->git mirroring process stopped
  5. git tree made writeable by committers.
  6. git->hg mirror outputs checked for sanity
  7. git->hg mirror enabled, pointing at old hg trees
  8. Autotester push gate told to use git and restarted

If any committer needs help getting git to work please feel free to
ask.  git has many advantages but its user interface has received very
mixed reviews.  We appreciate that you might need handholding.  So if
you get confused, or into trouble, do consult.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17: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 1U5fpG-0002sL-2y; Wed, 13 Feb 2013 17:08: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 1U5fpD-0002s9-PC
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 17:08:51 +0000
Received: from [85.158.137.99:16530] by server-2.bemta-3.messagelabs.com id
	DE/FD-25961-D98CB115; Wed, 13 Feb 2013 17:08:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360775324!20474976!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 13 Feb 2013 17:08:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 17:08:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="1427240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 17:08: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.297.1; Wed, 13 Feb 2013 17:08:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U5fp3-000075-EZ; Wed, 13 Feb 2013 17:08:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U5fp3-0005jy-AQ;
	Wed, 13 Feb 2013 17:08:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20763.51353.91324.851766@mariner.uk.xensource.com>
Date: Wed, 13 Feb 2013 17:08:41 +0000
To: <xen-devel@lists.xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 previously agreed, we will be moving the main Xen trees to git.
The existing .hg trees will continue to exist, but as hg mirrors of
the git history.  Committers will push to the git repo.

The new git tree will be this one:
  http://xenbits.xen.org/gitweb/?p=xen.git
  git://xenbits.xen.org/xen.git
For committers it will be accessible via
  xenbits.xen.org:/home/xen/git/xen.git

It has a branch corresponding to each xen*.hg tree:
  master                xen-unstable.hg
  stable-4.0            xen-4.0-testing.hg
  stable-4.1            xen-4.1-testing.hg
  stable-4.2            xen-4.2-testing.hg
  staging               staging/xen-unstable.hg
  staging-4.0           staging/xen-4.0-testing.hg
  staging-4.1           staging/xen-4.1-testing.hg
  staging-4.2           staging/xen-4.2-testing.hg

We have some background infrastructure work which needs to be complete
before we make this switch, but we are currently expecting/hoping this
to be ready next week.  We tentatively intend to make the switch on
Thursday the 13th of February, assuming none of the committers object.

Committers please note that if you have commits (patch queues) in hg
at this point, they will need to be transferred into git somehow to be
committed and pushed.  After the switch it will not be possible to
accept changes from hg, because we won't have bidirectional mirroring.

If at the point we make the change there are changes in staging that
have not propagated to the corresponding stable or master tree, this
situation will be preserved.  However, revision history will be broken
(by the difference in revision ids), which will slightly weaken the
autotester's push gate.  I therefore recommend that we avoid making
this change if we have a big or scary backlog in any staging tree.

People posting and approving patches, including maintainers, are not
directly affected.

The process will be as follows:
  1. Autotester push gate shut down
  2. Announcement and coordination with committers
  3. hg trees made read-only (other than by forthcoming git->hg mirror)
  4. hg->git mirroring process stopped
  5. git tree made writeable by committers.
  6. git->hg mirror outputs checked for sanity
  7. git->hg mirror enabled, pointing at old hg trees
  8. Autotester push gate told to use git and restarted

If any committer needs help getting git to work please feel free to
ask.  git has many advantages but its user interface has received very
mixed reviews.  We appreciate that you might need handholding.  So if
you get confused, or into trouble, do consult.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:13:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17: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 1U5ftZ-0003J2-Nm; Wed, 13 Feb 2013 17:13: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 1U5ftY-0003Iu-1b
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 17:13:20 +0000
Received: from [85.158.139.83:11443] by server-10.bemta-5.messagelabs.com id
	4D/BA-04697-FA9CB115; Wed, 13 Feb 2013 17:13:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360775597!29034975!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4194 invoked from network); 13 Feb 2013 17:13:18 -0000
Received: from unknown (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 17:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="1427371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 17:12: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.297.1; Wed, 13 Feb 2013 17:12:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5fsT-00008Q-Vt;
	Wed, 13 Feb 2013 17:12:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5fsT-0007OQ-FA;
	Wed, 13 Feb 2013 17:12:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16161-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 17:12:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16161: 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 16161 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16161/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  63594ce1708f
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=63594ce1708f
+ . 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 63594ce1708f
+ branch=xen-unstable
+ revision=63594ce1708f
+ . 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/hg/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 63594ce1708f 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 7 changesets with 14 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:13:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17: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 1U5ftZ-0003J2-Nm; Wed, 13 Feb 2013 17:13: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 1U5ftY-0003Iu-1b
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 17:13:20 +0000
Received: from [85.158.139.83:11443] by server-10.bemta-5.messagelabs.com id
	4D/BA-04697-FA9CB115; Wed, 13 Feb 2013 17:13:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360775597!29034975!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4194 invoked from network); 13 Feb 2013 17:13:18 -0000
Received: from unknown (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 17:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="1427371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 17:12: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.297.1; Wed, 13 Feb 2013 17:12:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5fsT-00008Q-Vt;
	Wed, 13 Feb 2013 17:12:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5fsT-0007OQ-FA;
	Wed, 13 Feb 2013 17:12:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16161-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 17:12:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16161: 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 16161 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16161/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  63594ce1708f
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  David Scott <dave.scott@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matthew Daley <mattjd@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=63594ce1708f
+ . 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 63594ce1708f
+ branch=xen-unstable
+ revision=63594ce1708f
+ . 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/hg/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 63594ce1708f 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 7 changesets with 14 changes to 13 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:34:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17:34: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 1U5gDX-0003dx-Rs; Wed, 13 Feb 2013 17:33:59 +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 1U5gDW-0003dn-O0
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 17:33:59 +0000
Received: from [193.109.254.147:3945] by server-1.bemta-14.messagelabs.com id
	E5/8F-29874-68ECB115; Wed, 13 Feb 2013 17:33:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360776810!8593148!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24033 invoked from network); 13 Feb 2013 17:33:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 17:33:33 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DHXE5J026680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 17:33:15 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
	r1DHXDLO016733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 17:33:14 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1DHXDRQ025334; Wed, 13 Feb 2013 11:33:13 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 09:33:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 28CE11BF781; Wed, 13 Feb 2013 12:33:12 -0500 (EST)
Date: Wed, 13 Feb 2013 12:33:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130213173312.GA20866@phenom.dumpdata.com>
References: <1360599058-1567-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360599058-1567-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: drop the use of
	llist_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="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, Feb 11, 2013 at 05:10:58PM +0100, Roger Pau Monne wrote:
> Replace llist_for_each_entry_safe with a while loop and
> llist_del_first.
> =

> llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
> to remove it and use a while loop and llist_del_first (which is
> already in llist.h).

I spruced this up a bit:

commit f73be4e09510cda1457ab96abf356e664ba96d4a
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Mon Feb 11 17:10:58 2013 +0100

    xen-blkfront: drop the use of llist_for_each_entry_safe
    =

    Replace llist_for_each_entry_safe with a while loop and
    llist_del_first.
    =

    llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
    to remove it and use a while loop and llist_del_first (which is
    already in llist.h).
    =

    Specifically this bug can be triggered by hot-unplugging a disk, either
    by doing xm block-detach or by save/restore cycle.
    =

    BUG: unable to handle kernel paging request at fffffffffffffff0
    IP: [<ffffffffa0047223>] blkif_free+0x63/0x130 [xen_blkfront]
    The crash call trace is:
    	...
    bad_area_nosemaphore+0x13/0x20
    do_page_fault+0x25e/0x4b0
    page_fault+0x25/0x30
    ? blkif_free+0x63/0x130 [xen_blkfront]
    blkfront_resume+0x46/0xa0 [xen_blkfront]
    xenbus_dev_resume+0x6c/0x140
    pm_op+0x192/0x1b0
    device_resume+0x82/0x1e0
    dpm_resume+0xc9/0x1a0
    dpm_resume_end+0x15/0x30
    do_suspend+0x117/0x1e0
    =

    When drilling down to the assembler code, on newer GCC it does
    .L29:
            cmpq    $-16, %r12      #, persistent_gnt check
            je      .L30    	#, out of the loop
    .L25:
    	... code in the loop
            testq   %r13, %r13      # n
            je      .L29    	#, back to the top of the loop
            cmpq    $-16, %r12      #, persistent_gnt check
            movq    16(%r12), %r13  # <variable>.node.next, n
            jne     .L25    	#,	back to the top of the loop
    .L30:
    =

    While on GCC 4.1, it is:
    L78:
    	... code in the loop
    	testq   %r13, %r13      # n
            je      .L78    #,	back to the top of the loop
            movq    16(%rbx), %r13  # <variable>.node.next, n
            jmp     .L78    #,	back to the top of the loop
    =

    Which basically means that the exit loop condition instead of
    being:
    =

    	&(pos)->member !=3D NULL;
    =

    is:
    	;
    =

    which makes the loop unbound.
    =

    Since xen-blkfront is the only user of the llist_for_each_entry_safe
    macro remove it from llist.h.
    =

    Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
    Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: xen-devel@lists.xen.org
    [v1: Spruced the description]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 11043c1..c325062 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -790,7 +790,6 @@ static void blkif_restart_queue(struct work_struct *wor=
k)
 =

 static void blkif_free(struct blkfront_info *info, int suspend)
 {
-	struct llist_node *all_gnts;
 	struct grant *persistent_gnt;
 	struct llist_node *n;
 =

@@ -804,8 +803,8 @@ static void blkif_free(struct blkfront_info *info, int =
suspend)
 =

 	/* Remove all persistent grants */
 	if (info->persistent_gnts_c) {
-		all_gnts =3D llist_del_all(&info->persistent_gnts);
-		llist_for_each_entry_safe(persistent_gnt, n, all_gnts, node) {
+		while ((n =3D llist_del_first(&info->persistent_gnts)) !=3D NULL) {
+			persistent_gnt =3D llist_entry(n, struct grant, node);
 			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
 			__free_page(pfn_to_page(persistent_gnt->pfn));
 			kfree(persistent_gnt);
diff --git a/include/linux/llist.h b/include/linux/llist.h
index d0ab98f..a5199f6 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -125,31 +125,6 @@ static inline void init_llist_head(struct llist_head *=
list)
 	     (pos) =3D llist_entry((pos)->member.next, typeof(*(pos)), member))
 =

 /**
- * llist_for_each_entry_safe - iterate safely against remove over some ent=
ries
- * of lock-less list of given type.
- * @pos:	the type * to use as a loop cursor.
- * @n:		another type * to use as a temporary storage.
- * @node:	the fist entry of deleted list entries.
- * @member:	the name of the llist_node with the struct.
- *
- * In general, some entries of the lock-less list can be traversed
- * safely only after being removed from list, so start with an entry
- * instead of list head. This variant allows removal of entries
- * as we iterate.
- *
- * If being used on entries deleted from lock-less list directly, the
- * traverse order is from the newest to the oldest added entry.  If
- * you want to traverse from the oldest to the newest, you must
- * reverse the order by yourself before traversing.
- */
-#define llist_for_each_entry_safe(pos, n, node, member)		\
-	for ((pos) =3D llist_entry((node), typeof(*(pos)), member),	\
-	     (n) =3D (pos)->member.next;					\
-	     &(pos)->member !=3D NULL;					\
-	     (pos) =3D llist_entry(n, typeof(*(pos)), member),		\
-	     (n) =3D (&(pos)->member !=3D NULL) ? (pos)->member.next : NULL)
-
-/**
  * llist_empty - tests whether a lock-less list is empty
  * @head:	the list to test
  *

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:34:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17:34: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 1U5gDX-0003dx-Rs; Wed, 13 Feb 2013 17:33:59 +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 1U5gDW-0003dn-O0
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 17:33:59 +0000
Received: from [193.109.254.147:3945] by server-1.bemta-14.messagelabs.com id
	E5/8F-29874-68ECB115; Wed, 13 Feb 2013 17:33:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360776810!8593148!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24033 invoked from network); 13 Feb 2013 17:33:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 17:33:33 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DHXE5J026680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 17:33:15 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
	r1DHXDLO016733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 17:33:14 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1DHXDRQ025334; Wed, 13 Feb 2013 11:33:13 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 09:33:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 28CE11BF781; Wed, 13 Feb 2013 12:33:12 -0500 (EST)
Date: Wed, 13 Feb 2013 12:33:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130213173312.GA20866@phenom.dumpdata.com>
References: <1360599058-1567-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360599058-1567-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: drop the use of
	llist_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="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, Feb 11, 2013 at 05:10:58PM +0100, Roger Pau Monne wrote:
> Replace llist_for_each_entry_safe with a while loop and
> llist_del_first.
> =

> llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
> to remove it and use a while loop and llist_del_first (which is
> already in llist.h).

I spruced this up a bit:

commit f73be4e09510cda1457ab96abf356e664ba96d4a
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Mon Feb 11 17:10:58 2013 +0100

    xen-blkfront: drop the use of llist_for_each_entry_safe
    =

    Replace llist_for_each_entry_safe with a while loop and
    llist_del_first.
    =

    llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
    to remove it and use a while loop and llist_del_first (which is
    already in llist.h).
    =

    Specifically this bug can be triggered by hot-unplugging a disk, either
    by doing xm block-detach or by save/restore cycle.
    =

    BUG: unable to handle kernel paging request at fffffffffffffff0
    IP: [<ffffffffa0047223>] blkif_free+0x63/0x130 [xen_blkfront]
    The crash call trace is:
    	...
    bad_area_nosemaphore+0x13/0x20
    do_page_fault+0x25e/0x4b0
    page_fault+0x25/0x30
    ? blkif_free+0x63/0x130 [xen_blkfront]
    blkfront_resume+0x46/0xa0 [xen_blkfront]
    xenbus_dev_resume+0x6c/0x140
    pm_op+0x192/0x1b0
    device_resume+0x82/0x1e0
    dpm_resume+0xc9/0x1a0
    dpm_resume_end+0x15/0x30
    do_suspend+0x117/0x1e0
    =

    When drilling down to the assembler code, on newer GCC it does
    .L29:
            cmpq    $-16, %r12      #, persistent_gnt check
            je      .L30    	#, out of the loop
    .L25:
    	... code in the loop
            testq   %r13, %r13      # n
            je      .L29    	#, back to the top of the loop
            cmpq    $-16, %r12      #, persistent_gnt check
            movq    16(%r12), %r13  # <variable>.node.next, n
            jne     .L25    	#,	back to the top of the loop
    .L30:
    =

    While on GCC 4.1, it is:
    L78:
    	... code in the loop
    	testq   %r13, %r13      # n
            je      .L78    #,	back to the top of the loop
            movq    16(%rbx), %r13  # <variable>.node.next, n
            jmp     .L78    #,	back to the top of the loop
    =

    Which basically means that the exit loop condition instead of
    being:
    =

    	&(pos)->member !=3D NULL;
    =

    is:
    	;
    =

    which makes the loop unbound.
    =

    Since xen-blkfront is the only user of the llist_for_each_entry_safe
    macro remove it from llist.h.
    =

    Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
    Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: xen-devel@lists.xen.org
    [v1: Spruced the description]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 11043c1..c325062 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -790,7 +790,6 @@ static void blkif_restart_queue(struct work_struct *wor=
k)
 =

 static void blkif_free(struct blkfront_info *info, int suspend)
 {
-	struct llist_node *all_gnts;
 	struct grant *persistent_gnt;
 	struct llist_node *n;
 =

@@ -804,8 +803,8 @@ static void blkif_free(struct blkfront_info *info, int =
suspend)
 =

 	/* Remove all persistent grants */
 	if (info->persistent_gnts_c) {
-		all_gnts =3D llist_del_all(&info->persistent_gnts);
-		llist_for_each_entry_safe(persistent_gnt, n, all_gnts, node) {
+		while ((n =3D llist_del_first(&info->persistent_gnts)) !=3D NULL) {
+			persistent_gnt =3D llist_entry(n, struct grant, node);
 			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
 			__free_page(pfn_to_page(persistent_gnt->pfn));
 			kfree(persistent_gnt);
diff --git a/include/linux/llist.h b/include/linux/llist.h
index d0ab98f..a5199f6 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -125,31 +125,6 @@ static inline void init_llist_head(struct llist_head *=
list)
 	     (pos) =3D llist_entry((pos)->member.next, typeof(*(pos)), member))
 =

 /**
- * llist_for_each_entry_safe - iterate safely against remove over some ent=
ries
- * of lock-less list of given type.
- * @pos:	the type * to use as a loop cursor.
- * @n:		another type * to use as a temporary storage.
- * @node:	the fist entry of deleted list entries.
- * @member:	the name of the llist_node with the struct.
- *
- * In general, some entries of the lock-less list can be traversed
- * safely only after being removed from list, so start with an entry
- * instead of list head. This variant allows removal of entries
- * as we iterate.
- *
- * If being used on entries deleted from lock-less list directly, the
- * traverse order is from the newest to the oldest added entry.  If
- * you want to traverse from the oldest to the newest, you must
- * reverse the order by yourself before traversing.
- */
-#define llist_for_each_entry_safe(pos, n, node, member)		\
-	for ((pos) =3D llist_entry((node), typeof(*(pos)), member),	\
-	     (n) =3D (pos)->member.next;					\
-	     &(pos)->member !=3D NULL;					\
-	     (pos) =3D llist_entry(n, typeof(*(pos)), member),		\
-	     (n) =3D (&(pos)->member !=3D NULL) ? (pos)->member.next : NULL)
-
-/**
  * llist_empty - tests whether a lock-less list is empty
  * @head:	the list to test
  *

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:42:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17:42: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 1U5gLl-0003rc-S0; Wed, 13 Feb 2013 17:42:29 +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 1U5gLk-0003rW-Ix
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 17:42:28 +0000
Received: from [85.158.143.99:58615] by server-1.bemta-4.messagelabs.com id
	B1/F6-08839-380DB115; Wed, 13 Feb 2013 17:42:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360777345!21009730!1
X-Originating-IP: [74.125.82.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4432 invoked from network); 13 Feb 2013 17:42:25 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 17:42:25 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so1226586wey.40
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 09:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=RDPg7UATPe6bQEDUlAK8RgMrDRiZGyEUY9YN8l8MttI=;
	b=e6Ee924MAPoRaA8D8GW9Ysn1fUdaYNxncr/ZvsHpVXAbt26DM8eIqFxliuC1Tb9Hs6
	NJYrDzkE+oGcA0TDq+iSmFjuEU0qS2NFUD/t/X/3HP1gg0AnwQkjh9leTFV298XxrZQj
	oHs/OZrnqWsq8FolzOaTPjwRuGMMOUxKHceWy3BoOKrclYvjs3pc2W05NPOkcixARjA/
	WK7/8n2eC7V5z+tEXTJ5L1PokmVf3bdDdtBLir+n36BwmBgEVvAhkra9dndn0Iu7tg8M
	LQ7hd9/VrRj7vvmKyGTr5OkExHd9kbnfxXHj6fJRwjXAAym17hD9pYU+YwQh2VHk4twR
	Zt4Q==
X-Received: by 10.180.105.195 with SMTP id go3mr11655399wib.13.1360777345429; 
	Wed, 13 Feb 2013 09:42:25 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id bs6sm81923wib.4.2013.02.13.09.42.22
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 13 Feb 2013 09:42:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 13 Feb 2013 17:42:19 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CD4180FB.5ACFE%keir@xen.org>
Thread-Topic: Moving xen*.hg to git
Thread-Index: Ac4KEXhW3LVzXAsLg0y4+4Gq1EThFw==
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> As previously agreed, we will be moving the main Xen trees to git.
> The existing .hg trees will continue to exist, but as hg mirrors of
> the git history.  Committers will push to the git repo.
> 
> The new git tree will be this one:
>   http://xenbits.xen.org/gitweb/?p=xen.git
>   git://xenbits.xen.org/xen.git
> For committers it will be accessible via
>   xenbits.xen.org:/home/xen/git/xen.git
> 
> It has a branch corresponding to each xen*.hg tree:
>   master                xen-unstable.hg
>   stable-4.0            xen-4.0-testing.hg
>   stable-4.1            xen-4.1-testing.hg
>   stable-4.2            xen-4.2-testing.hg
>   staging               staging/xen-unstable.hg
>   staging-4.0           staging/xen-4.0-testing.hg
>   staging-4.1           staging/xen-4.1-testing.hg
>   staging-4.2           staging/xen-4.2-testing.hg
> 
> We have some background infrastructure work which needs to be complete
> before we make this switch, but we are currently expecting/hoping this
> to be ready next week.  We tentatively intend to make the switch on
> Thursday the 13th of February, assuming none of the committers object.

Do you mean 14th Feb (tomorrow)?

 -- Keir

> Committers please note that if you have commits (patch queues) in hg
> at this point, they will need to be transferred into git somehow to be
> committed and pushed.  After the switch it will not be possible to
> accept changes from hg, because we won't have bidirectional mirroring.
> 
> If at the point we make the change there are changes in staging that
> have not propagated to the corresponding stable or master tree, this
> situation will be preserved.  However, revision history will be broken
> (by the difference in revision ids), which will slightly weaken the
> autotester's push gate.  I therefore recommend that we avoid making
> this change if we have a big or scary backlog in any staging tree.
> 
> People posting and approving patches, including maintainers, are not
> directly affected.
> 
> The process will be as follows:
>   1. Autotester push gate shut down
>   2. Announcement and coordination with committers
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped
>   5. git tree made writeable by committers.
>   6. git->hg mirror outputs checked for sanity
>   7. git->hg mirror enabled, pointing at old hg trees
>   8. Autotester push gate told to use git and restarted
> 
> If any committer needs help getting git to work please feel free to
> ask.  git has many advantages but its user interface has received very
> mixed reviews.  We appreciate that you might need handholding.  So if
> you get confused, or into trouble, do consult.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 17:42:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 17:42: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 1U5gLl-0003rc-S0; Wed, 13 Feb 2013 17:42:29 +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 1U5gLk-0003rW-Ix
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 17:42:28 +0000
Received: from [85.158.143.99:58615] by server-1.bemta-4.messagelabs.com id
	B1/F6-08839-380DB115; Wed, 13 Feb 2013 17:42:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360777345!21009730!1
X-Originating-IP: [74.125.82.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4432 invoked from network); 13 Feb 2013 17:42:25 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 17:42:25 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so1226586wey.40
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 09:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=RDPg7UATPe6bQEDUlAK8RgMrDRiZGyEUY9YN8l8MttI=;
	b=e6Ee924MAPoRaA8D8GW9Ysn1fUdaYNxncr/ZvsHpVXAbt26DM8eIqFxliuC1Tb9Hs6
	NJYrDzkE+oGcA0TDq+iSmFjuEU0qS2NFUD/t/X/3HP1gg0AnwQkjh9leTFV298XxrZQj
	oHs/OZrnqWsq8FolzOaTPjwRuGMMOUxKHceWy3BoOKrclYvjs3pc2W05NPOkcixARjA/
	WK7/8n2eC7V5z+tEXTJ5L1PokmVf3bdDdtBLir+n36BwmBgEVvAhkra9dndn0Iu7tg8M
	LQ7hd9/VrRj7vvmKyGTr5OkExHd9kbnfxXHj6fJRwjXAAym17hD9pYU+YwQh2VHk4twR
	Zt4Q==
X-Received: by 10.180.105.195 with SMTP id go3mr11655399wib.13.1360777345429; 
	Wed, 13 Feb 2013 09:42:25 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id bs6sm81923wib.4.2013.02.13.09.42.22
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 13 Feb 2013 09:42:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 13 Feb 2013 17:42:19 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CD4180FB.5ACFE%keir@xen.org>
Thread-Topic: Moving xen*.hg to git
Thread-Index: Ac4KEXhW3LVzXAsLg0y4+4Gq1EThFw==
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> As previously agreed, we will be moving the main Xen trees to git.
> The existing .hg trees will continue to exist, but as hg mirrors of
> the git history.  Committers will push to the git repo.
> 
> The new git tree will be this one:
>   http://xenbits.xen.org/gitweb/?p=xen.git
>   git://xenbits.xen.org/xen.git
> For committers it will be accessible via
>   xenbits.xen.org:/home/xen/git/xen.git
> 
> It has a branch corresponding to each xen*.hg tree:
>   master                xen-unstable.hg
>   stable-4.0            xen-4.0-testing.hg
>   stable-4.1            xen-4.1-testing.hg
>   stable-4.2            xen-4.2-testing.hg
>   staging               staging/xen-unstable.hg
>   staging-4.0           staging/xen-4.0-testing.hg
>   staging-4.1           staging/xen-4.1-testing.hg
>   staging-4.2           staging/xen-4.2-testing.hg
> 
> We have some background infrastructure work which needs to be complete
> before we make this switch, but we are currently expecting/hoping this
> to be ready next week.  We tentatively intend to make the switch on
> Thursday the 13th of February, assuming none of the committers object.

Do you mean 14th Feb (tomorrow)?

 -- Keir

> Committers please note that if you have commits (patch queues) in hg
> at this point, they will need to be transferred into git somehow to be
> committed and pushed.  After the switch it will not be possible to
> accept changes from hg, because we won't have bidirectional mirroring.
> 
> If at the point we make the change there are changes in staging that
> have not propagated to the corresponding stable or master tree, this
> situation will be preserved.  However, revision history will be broken
> (by the difference in revision ids), which will slightly weaken the
> autotester's push gate.  I therefore recommend that we avoid making
> this change if we have a big or scary backlog in any staging tree.
> 
> People posting and approving patches, including maintainers, are not
> directly affected.
> 
> The process will be as follows:
>   1. Autotester push gate shut down
>   2. Announcement and coordination with committers
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped
>   5. git tree made writeable by committers.
>   6. git->hg mirror outputs checked for sanity
>   7. git->hg mirror enabled, pointing at old hg trees
>   8. Autotester push gate told to use git and restarted
> 
> If any committer needs help getting git to work please feel free to
> ask.  git has many advantages but its user interface has received very
> mixed reviews.  We appreciate that you might need handholding.  So if
> you get confused, or into trouble, do consult.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:13:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5gou-0004Ia-Hx; Wed, 13 Feb 2013 18:12: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 1U5gos-0004IV-Mt
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 18:12:34 +0000
Received: from [85.158.143.35:63143] by server-3.bemta-4.messagelabs.com id
	FE/24-08920-297DB115; Wed, 13 Feb 2013 18:12:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360779135!14444247!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9530 invoked from network); 13 Feb 2013 18:12:21 -0000
Received: from unknown (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 18:12:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DIB5bc005078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 18:11:06 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
	r1DIB4DY003906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 18:11:05 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
	r1DIB4GZ013597; Wed, 13 Feb 2013 12:11:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 10:11:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 330461BF781; Wed, 13 Feb 2013 13:11:03 -0500 (EST)
Date: Wed, 13 Feb 2013 13:11:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: olaf@aepfle.de, xen-devel@lists.xensource.com
Message-ID: <20130213181103.GC20042@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] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM:
 use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM
 guests (v3.8-rcX) on Xen 4.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

Hey Olaf,

The commit 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f
(xen PVonHVM: use E820_Reserved area for shared_info) causes
a regression when doing 'xm restore' (or migrate) of a 32-bit
PVHVM guest with Xen 4.1. This is xen-4.1-testing with v3.8-rc7
and me just doing 'xm save <name> <file>' followed by
'xm restore <file> && xm console <name>' and I don't see anything
on the serial console. The 'xentop' shows the guest consuming 100%
cycles spinning around in pvlock_read.

By just reverting this patch (well, also a7be94ac8d69c037d08f0fd94b45a593f1d45176)
the problem disappears.

Any thoughts of what might be wrong?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:13:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5gou-0004Ia-Hx; Wed, 13 Feb 2013 18:12: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 1U5gos-0004IV-Mt
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 18:12:34 +0000
Received: from [85.158.143.35:63143] by server-3.bemta-4.messagelabs.com id
	FE/24-08920-297DB115; Wed, 13 Feb 2013 18:12:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360779135!14444247!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9530 invoked from network); 13 Feb 2013 18:12:21 -0000
Received: from unknown (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 18:12:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DIB5bc005078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 18:11:06 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
	r1DIB4DY003906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 18:11:05 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
	r1DIB4GZ013597; Wed, 13 Feb 2013 12:11:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 10:11:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 330461BF781; Wed, 13 Feb 2013 13:11:03 -0500 (EST)
Date: Wed, 13 Feb 2013 13:11:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: olaf@aepfle.de, xen-devel@lists.xensource.com
Message-ID: <20130213181103.GC20042@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] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen PVonHVM:
 use E820_Reserved area for shared_info) causes regression with 32-bit PVHVM
 guests (v3.8-rcX) on Xen 4.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

Hey Olaf,

The commit 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f
(xen PVonHVM: use E820_Reserved area for shared_info) causes
a regression when doing 'xm restore' (or migrate) of a 32-bit
PVHVM guest with Xen 4.1. This is xen-4.1-testing with v3.8-rc7
and me just doing 'xm save <name> <file>' followed by
'xm restore <file> && xm console <name>' and I don't see anything
on the serial console. The 'xentop' shows the guest consuming 100%
cycles spinning around in pvlock_read.

By just reverting this patch (well, also a7be94ac8d69c037d08f0fd94b45a593f1d45176)
the problem disappears.

Any thoughts of what might be wrong?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:22:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5gxt-0004Ue-KV; Wed, 13 Feb 2013 18:21:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5gxr-0004UZ-UZ
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:21:52 +0000
Received: from [85.158.143.99:59890] by server-1.bemta-4.messagelabs.com id
	E7/53-08839-FB9DB115; Wed, 13 Feb 2013 18:21:51 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360779709!27075182!1
X-Originating-IP: [209.85.220.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17331 invoked from network); 13 Feb 2013 18:21:50 -0000
Received: from mail-vc0-f179.google.com (HELO mail-vc0-f179.google.com)
	(209.85.220.179)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 18:21:50 -0000
Received: by mail-vc0-f179.google.com with SMTP id gb23so927941vcb.38
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 10:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=OckZdkE+R7qL6LhLmh9KNr6w/6nJFjftvAi7h4Y7CzY=;
	b=i2k1/fKQU1r+49eIlbsxL2JbaUMjaWpaUuokU0IK5or6rb6EjUhcGWce0lKDIsThd7
	FEtwHsT0j91Ui8UDt9TG5KiMN6x4apXxx5/GoUp0Co/atrsrl4tVkqL0LBee92xN8fBl
	RMc5mOcmowYoUUKO4MHvGturWehs9LzQtuYrWan/MEukCo6JVbNXvVrQGZEBlNW7ddri
	zoxa4jxIQZ/k3W8ThwaCfIt5bcxPK9gnycdTzqw+XVWKMrj+v4foeyu7lWEJJCLi830e
	dtxbSJDUvPWjmy2F/FcLKmrUerHTYI51ZOb++1LQbAS0Zkf7iib5E5pCrk62x3JrzpVM
	XzMw==
X-Received: by 10.52.19.200 with SMTP id h8mr25738131vde.60.1360779682479;
	Wed, 13 Feb 2013 10:21:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.203.106 with HTTP; Wed, 13 Feb 2013 10:21:02 -0800 (PST)
In-Reply-To: <511B5EE102000078000BDE8A@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Wed, 13 Feb 2013 19:21:02 +0100
Message-ID: <CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>> 2013/2/13 Jan Beulich <JBeulich@suse.com>:
>>> I wonder how native Linux with
>>> IOMMU enabled does in that situation...
>>>

Here is full boot log of latest centos stable kernel:
http://pastebin.com/raw.php?i=RnrMFXqf
I had to set amd_iommu=on and amd_iommu_dump (to dump ACPI table) -
undocumented kernel options.

Interesting part in my opinion:
calling  pci_iommu_init+0x0/0x21 @ 1
AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: 3e info 1300
AMD-Vi:        mmio-addr: 00000000f6000000
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:00.2
AMD-Vi:   DEV_SELECT			 devid: 00:04.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 06:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:06.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 05:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:07.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 04:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:0b.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 03:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 03:00.1
AMD-Vi:   DEV_SELECT			 devid: 00:0d.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 02:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:11.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:12.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:12.2
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:13.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:13.2
AMD-Vi:   DEV_SELECT			 devid: 00:14.0 flags: d7
AMD-Vi:   DEV_SELECT			 devid: 00:14.1 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:14.2 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:14.3 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:14.4 flags: 00
AMD-Vi:   DEV_ALIAS_RANGE		 devid: 01:00.0 flags: 00 devid_to: 00:14.4
AMD-Vi:   DEV_RANGE_END		 devid: 01:1f.7
AMD-Vi:   DEV_SELECT			 devid: 00:14.5 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:16.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:16.2
  alloc irq_desc for 55 on node 0
  alloc kstat_irqs on node 0
IOAPIC[1]: Set routing entry (7-31 -> 0x79 -> IRQ 55 Mode:1 Active:1)
pci 0000:00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55
  alloc irq_desc for 56 on node 0
  alloc kstat_irqs on node 0
pci 0000:00:00.2: irq 56 for MSI/MSI-X
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Initialized for Passthrough Mode
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
initcall pci_iommu_init+0x0/0x21 returned 0 after 569797 usecs

I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.

lspci output: http://pastebin.com/raw.php?i=3wpKPQT9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:22:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5gxt-0004Ue-KV; Wed, 13 Feb 2013 18:21:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <povder@gmail.com>) id 1U5gxr-0004UZ-UZ
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:21:52 +0000
Received: from [85.158.143.99:59890] by server-1.bemta-4.messagelabs.com id
	E7/53-08839-FB9DB115; Wed, 13 Feb 2013 18:21:51 +0000
X-Env-Sender: povder@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360779709!27075182!1
X-Originating-IP: [209.85.220.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17331 invoked from network); 13 Feb 2013 18:21:50 -0000
Received: from mail-vc0-f179.google.com (HELO mail-vc0-f179.google.com)
	(209.85.220.179)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 18:21:50 -0000
Received: by mail-vc0-f179.google.com with SMTP id gb23so927941vcb.38
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 10:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=OckZdkE+R7qL6LhLmh9KNr6w/6nJFjftvAi7h4Y7CzY=;
	b=i2k1/fKQU1r+49eIlbsxL2JbaUMjaWpaUuokU0IK5or6rb6EjUhcGWce0lKDIsThd7
	FEtwHsT0j91Ui8UDt9TG5KiMN6x4apXxx5/GoUp0Co/atrsrl4tVkqL0LBee92xN8fBl
	RMc5mOcmowYoUUKO4MHvGturWehs9LzQtuYrWan/MEukCo6JVbNXvVrQGZEBlNW7ddri
	zoxa4jxIQZ/k3W8ThwaCfIt5bcxPK9gnycdTzqw+XVWKMrj+v4foeyu7lWEJJCLi830e
	dtxbSJDUvPWjmy2F/FcLKmrUerHTYI51ZOb++1LQbAS0Zkf7iib5E5pCrk62x3JrzpVM
	XzMw==
X-Received: by 10.52.19.200 with SMTP id h8mr25738131vde.60.1360779682479;
	Wed, 13 Feb 2013 10:21:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.203.106 with HTTP; Wed, 13 Feb 2013 10:21:02 -0800 (PST)
In-Reply-To: <511B5EE102000078000BDE8A@nat28.tlf.novell.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
From: povder <povder@gmail.com>
Date: Wed, 13 Feb 2013 19:21:02 +0100
Message-ID: <CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>> 2013/2/13 Jan Beulich <JBeulich@suse.com>:
>>> I wonder how native Linux with
>>> IOMMU enabled does in that situation...
>>>

Here is full boot log of latest centos stable kernel:
http://pastebin.com/raw.php?i=RnrMFXqf
I had to set amd_iommu=on and amd_iommu_dump (to dump ACPI table) -
undocumented kernel options.

Interesting part in my opinion:
calling  pci_iommu_init+0x0/0x21 @ 1
AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: 3e info 1300
AMD-Vi:        mmio-addr: 00000000f6000000
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:00.2
AMD-Vi:   DEV_SELECT			 devid: 00:04.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 06:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:06.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 05:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:07.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 04:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:0b.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 03:00.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 03:00.1
AMD-Vi:   DEV_SELECT			 devid: 00:0d.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 02:00.0 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:11.0 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:12.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:12.2
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:13.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:13.2
AMD-Vi:   DEV_SELECT			 devid: 00:14.0 flags: d7
AMD-Vi:   DEV_SELECT			 devid: 00:14.1 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:14.2 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:14.3 flags: 00
AMD-Vi:   DEV_SELECT			 devid: 00:14.4 flags: 00
AMD-Vi:   DEV_ALIAS_RANGE		 devid: 01:00.0 flags: 00 devid_to: 00:14.4
AMD-Vi:   DEV_RANGE_END		 devid: 01:1f.7
AMD-Vi:   DEV_SELECT			 devid: 00:14.5 flags: 00
AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:16.0 flags: 00
AMD-Vi:   DEV_RANGE_END		 devid: 00:16.2
  alloc irq_desc for 55 on node 0
  alloc kstat_irqs on node 0
IOAPIC[1]: Set routing entry (7-31 -> 0x79 -> IRQ 55 Mode:1 Active:1)
pci 0000:00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55
  alloc irq_desc for 56 on node 0
  alloc kstat_irqs on node 0
pci 0000:00:00.2: irq 56 for MSI/MSI-X
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Initialized for Passthrough Mode
AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
initcall pci_iommu_init+0x0/0x21 returned 0 after 569797 usecs

I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.

lspci output: http://pastebin.com/raw.php?i=3wpKPQT9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:24:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:24: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 1U5h0U-0004d2-IF; Wed, 13 Feb 2013 18:24:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5h0T-0004ct-8z
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:24:33 +0000
Received: from [85.158.137.99:64418] by server-15.bemta-3.messagelabs.com id
	93/22-25405-06ADB115; Wed, 13 Feb 2013 18:24:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360779869!15919081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14447 invoked from network); 13 Feb 2013 18:24:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 18:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7011379"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 18:24:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 13:24:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5h0O-0004tS-GF;
	Wed, 13 Feb 2013 18:24:28 +0000
Message-ID: <1360779868.16636.92.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Wed, 13 Feb 2013 18:24:28 +0000
In-Reply-To: <511AFFC9.3050404@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
> On 2/12/13 4:58 AM, Ian Campbell wrote:
> > Have you applied the XSA-39 fixes to this kernel?
> 
> Yes!  When I rebuilt with Wei's suggested patch for my original 
> netback/xenwatch problem I also brought us up to date with XSA patches.
> 
> We just hit the same (new) problem on another machine, and looking at 
> the BUG with more kernel output context gives a giant clue:
> 
> Feb 12 20:30:54: IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready
> Feb 12 20:30:54: device vif21.0 entered promiscuous mode
> Feb 12 20:30:56: xen-blkback:ring-ref 8, event-channel 31, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: xen-blkback:ring-ref 9, event-channel 32, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:58: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
> Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
> <--------------
> Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference 
> at 00000000000008b8
> Feb 12 20:34:12: IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: PGD 0
> Feb 12 20:34:12: Oops: 0002 [#1] SMP
> Feb 12 20:34:12: Modules linked in: ebt_comment ebt_arp ebt_set 
> ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev 
> bonding ebtable_filter e1000e
> Feb 12 20:34:12: CPU 3
> Feb 12 20:34:12: Pid: 1548, comm: netback/3 Not tainted 3.7.6-1-x86_64 
> #1 Supermicro X8DT6/X8DT6
> Feb 12 20:34:12: RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: RSP: e02b:ffff880083681b58  EFLAGS: 00010006
> Feb 12 20:34:12: RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 
> 0000000000000663
> Feb 12 20:34:12: RDX: 0000000000000001 RSI: 0000000000000210 RDI: 
> 00000000000008b8
> Feb 12 20:34:12: RBP: ffff880083681b78 R08: 000000000000000d R09: 
> 0000000000000000
> Feb 12 20:34:12: R10: 0000000000000001 R11: 0000000000000001 R12: 
> 0000000000000001
> Feb 12 20:34:12: R13: 0000000000000200 R14: 0000000000000400 R15: 
> 0000000000000663
> Feb 12 20:34:12: FS:  00007f2bc1fb2700(0000) GS:ffff8801006c0000(0000) 
> knlGS:0000000000000000
> Feb 12 20:34:12: CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> Feb 12 20:34:12: CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 
> 0000000000002660
> Feb 12 20:34:12: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
> 0000000000000000
> Feb 12 20:34:12: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
> 0000000000000400
> Feb 12 20:34:12: Process netback/3 (pid: 1548, threadinfo 
> ffff880083680000, task ffff8800837ec9c0)
> Feb 12 20:34:12: Stack:
> Feb 12 20:34:12: 0000000000000210 00000000000008b8 ffff880003baa700 
> ffff880003baa7d8
> Feb 12 20:34:12: ffff880083681b98 ffffffff817605da 0000000000000000 
> 00000000000008b8
> Feb 12 20:34:12: ffff880083681bd8 ffffffff8154446f ffff880003baa000 
> 0000000000000000

Fancy trying this *UNTESTED* patch a bit? I look through the code and
there seems to be an error.

Jan's advice is worth consideration, but I think we should fix this XSA
bug first.


Wei.

-----8<----
commit 6a06b51edd7124193322fd62244171eb099aff52
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Wed Feb 13 18:17:01 2013 +0000

    netback: fix netbk_count_requests
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 103294d..61aaeb0 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -927,7 +927,11 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (txp->size > first->size) {
 			netdev_err(vif->dev, "Frag is bigger than frame.\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			/* frag could be zero at this point if it
+			 * fails during first iteration, so we need to
+			 * set it to negative number if there is
+			 * error */
+			return frags ? -frags : -1;
 		}
 
 		first->size -= txp->size;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:24:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:24: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 1U5h0U-0004d2-IF; Wed, 13 Feb 2013 18:24:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5h0T-0004ct-8z
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:24:33 +0000
Received: from [85.158.137.99:64418] by server-15.bemta-3.messagelabs.com id
	93/22-25405-06ADB115; Wed, 13 Feb 2013 18:24:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360779869!15919081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14447 invoked from network); 13 Feb 2013 18:24:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 18:24:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7011379"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 18:24:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 13:24:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5h0O-0004tS-GF;
	Wed, 13 Feb 2013 18:24:28 +0000
Message-ID: <1360779868.16636.92.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Wed, 13 Feb 2013 18:24:28 +0000
In-Reply-To: <511AFFC9.3050404@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
> On 2/12/13 4:58 AM, Ian Campbell wrote:
> > Have you applied the XSA-39 fixes to this kernel?
> 
> Yes!  When I rebuilt with Wei's suggested patch for my original 
> netback/xenwatch problem I also brought us up to date with XSA patches.
> 
> We just hit the same (new) problem on another machine, and looking at 
> the BUG with more kernel output context gives a giant clue:
> 
> Feb 12 20:30:54: IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready
> Feb 12 20:30:54: device vif21.0 entered promiscuous mode
> Feb 12 20:30:56: xen-blkback:ring-ref 8, event-channel 31, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: xen-blkback:ring-ref 9, event-channel 32, protocol 2 
> (x86_32-abi)
> Feb 12 20:30:56: IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:56: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:30:58: br0: port 5(vif21.0) entered forwarding state
> Feb 12 20:34:12: vif vif-21-0 vif21.0: Frag is bigger than frame.
> Feb 12 20:34:12: vif vif-21-0 vif21.0: fatal error; disabling device 
> <--------------
> Feb 12 20:34:12: BUG: unable to handle kernel NULL pointer dereference 
> at 00000000000008b8
> Feb 12 20:34:12: IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: PGD 0
> Feb 12 20:34:12: Oops: 0002 [#1] SMP
> Feb 12 20:34:12: Modules linked in: ebt_comment ebt_arp ebt_set 
> ebt_limit ebt_ip6 ebt_ip ip_set_hash_net ip_set ebtable_nat xen_gntdev 
> bonding ebtable_filter e1000e
> Feb 12 20:34:12: CPU 3
> Feb 12 20:34:12: Pid: 1548, comm: netback/3 Not tainted 3.7.6-1-x86_64 
> #1 Supermicro X8DT6/X8DT6
> Feb 12 20:34:12: RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> Feb 12 20:34:12: RSP: e02b:ffff880083681b58  EFLAGS: 00010006
> Feb 12 20:34:12: RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 
> 0000000000000663
> Feb 12 20:34:12: RDX: 0000000000000001 RSI: 0000000000000210 RDI: 
> 00000000000008b8
> Feb 12 20:34:12: RBP: ffff880083681b78 R08: 000000000000000d R09: 
> 0000000000000000
> Feb 12 20:34:12: R10: 0000000000000001 R11: 0000000000000001 R12: 
> 0000000000000001
> Feb 12 20:34:12: R13: 0000000000000200 R14: 0000000000000400 R15: 
> 0000000000000663
> Feb 12 20:34:12: FS:  00007f2bc1fb2700(0000) GS:ffff8801006c0000(0000) 
> knlGS:0000000000000000
> Feb 12 20:34:12: CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> Feb 12 20:34:12: CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 
> 0000000000002660
> Feb 12 20:34:12: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
> 0000000000000000
> Feb 12 20:34:12: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
> 0000000000000400
> Feb 12 20:34:12: Process netback/3 (pid: 1548, threadinfo 
> ffff880083680000, task ffff8800837ec9c0)
> Feb 12 20:34:12: Stack:
> Feb 12 20:34:12: 0000000000000210 00000000000008b8 ffff880003baa700 
> ffff880003baa7d8
> Feb 12 20:34:12: ffff880083681b98 ffffffff817605da 0000000000000000 
> 00000000000008b8
> Feb 12 20:34:12: ffff880083681bd8 ffffffff8154446f ffff880003baa000 
> 0000000000000000

Fancy trying this *UNTESTED* patch a bit? I look through the code and
there seems to be an error.

Jan's advice is worth consideration, but I think we should fix this XSA
bug first.


Wei.

-----8<----
commit 6a06b51edd7124193322fd62244171eb099aff52
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Wed Feb 13 18:17:01 2013 +0000

    netback: fix netbk_count_requests
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 103294d..61aaeb0 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -927,7 +927,11 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (txp->size > first->size) {
 			netdev_err(vif->dev, "Frag is bigger than frame.\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			/* frag could be zero at this point if it
+			 * fails during first iteration, so we need to
+			 * set it to negative number if there is
+			 * error */
+			return frags ? -frags : -1;
 		}
 
 		first->size -= txp->size;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8J-0004r6-MY; Wed, 13 Feb 2013 18:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qF-Rk
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:38742] by server-1.bemta-4.messagelabs.com id
	C3/B9-08839-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!5
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12081 invoked from network); 13 Feb 2013 18:32:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id D9B99C561A4;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:17 +0000
Message-Id: <1360780340-19117-9-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 08/11] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function will enable or disable the global dirty log on QEMU,
used during a migration.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693135 -3600
: Node ID d4aec9eff7e6d15c2805957af620c82555553b3e
: Parent  f3890916496445c97d6778d6c986b0270ff707f2

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_qmp.c      |   12 ++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b00ff61..f658562 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1400,6 +1400,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* 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 b09bf13..ac10f20 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -658,7 +658,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,7 +668,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                           NULL, NULL);
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8J-0004r6-MY; Wed, 13 Feb 2013 18:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qF-Rk
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:38742] by server-1.bemta-4.messagelabs.com id
	C3/B9-08839-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!5
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12081 invoked from network); 13 Feb 2013 18:32:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id D9B99C561A4;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:17 +0000
Message-Id: <1360780340-19117-9-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 08/11] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function will enable or disable the global dirty log on QEMU,
used during a migration.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693135 -3600
: Node ID d4aec9eff7e6d15c2805957af620c82555553b3e
: Parent  f3890916496445c97d6778d6c986b0270ff707f2

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_qmp.c      |   12 ++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b00ff61..f658562 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1400,6 +1400,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* 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 b09bf13..ac10f20 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -658,7 +658,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,7 +668,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                           NULL, NULL);
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8J-0004qz-9y; Wed, 13 Feb 2013 18:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qH-MO
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:30353] by server-3.bemta-4.messagelabs.com id
	5C/10-08920-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12046 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 49932C561A0;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:14 +0000
Message-Id: <1360780340-19117-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 05/11] libxl_qmp: Introduces helpers to create
	an argument 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>
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

Those functions will be used to create a "list" of parameters that
contain more than just strings. This list is converted by qmp_send to
a string to be sent to QEMU.

Those functions will be used in the next two patches, so right now
there are not compiled.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 6f7847729f0f42614de516d15257ede7243f995f
: Parent  74dee58cfc0d2d6594f388db3b4d2ce91d1bb204

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9e86c35..827f1b7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -624,6 +624,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(gc, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(gc, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(gc, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_STRING);
+    obj->u.string = libxl__strdup(gc, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_BOOL);
+    obj->u.b = b;
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8J-0004qz-9y; Wed, 13 Feb 2013 18:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qH-MO
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:30353] by server-3.bemta-4.messagelabs.com id
	5C/10-08920-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12046 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 49932C561A0;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:14 +0000
Message-Id: <1360780340-19117-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 05/11] libxl_qmp: Introduces helpers to create
	an argument 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>
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

Those functions will be used to create a "list" of parameters that
contain more than just strings. This list is converted by qmp_send to
a string to be sent to QEMU.

Those functions will be used in the next two patches, so right now
there are not compiled.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 6f7847729f0f42614de516d15257ede7243f995f
: Parent  74dee58cfc0d2d6594f388db3b4d2ce91d1bb204

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9e86c35..827f1b7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -624,6 +624,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(gc, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(gc, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(gc, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_STRING);
+    obj->u.string = libxl__strdup(gc, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_BOOL);
+    obj->u.b = b;
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8P-0004uS-4R; Wed, 13 Feb 2013 18:32:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8N-0004t8-Go
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:43 +0000
Received: from [85.158.137.99:51233] by server-15.bemta-3.messagelabs.com id
	56/29-25405-54CDB115; Wed, 13 Feb 2013 18:32:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360780356!17907583!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1387 invoked from network); 13 Feb 2013 18:32:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:32:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 76425C561A8;
	Wed, 13 Feb 2013 18:32:36 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:20 +0000
Message-Id: <1360780340-19117-12-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 11/11] libxl: Allow migration with 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>
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

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 0995890022391682a2499a202c3c8608e1d3780a
: Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl.c |   17 -----------------
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4b4c5b0..9b14364 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -768,23 +768,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
         goto out_err;
     }
 
-    if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
-        switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            /* No problem */
-            break;
-        case -1:
-            rc = ERROR_FAIL;
-            goto out_err;
-        default: abort();
-        }
-    }
-
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8P-0004uS-4R; Wed, 13 Feb 2013 18:32:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8N-0004t8-Go
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:43 +0000
Received: from [85.158.137.99:51233] by server-15.bemta-3.messagelabs.com id
	56/29-25405-54CDB115; Wed, 13 Feb 2013 18:32:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360780356!17907583!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1387 invoked from network); 13 Feb 2013 18:32:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:32:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 76425C561A8;
	Wed, 13 Feb 2013 18:32:36 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:20 +0000
Message-Id: <1360780340-19117-12-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 11/11] libxl: Allow migration with 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>
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

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 0995890022391682a2499a202c3c8608e1d3780a
: Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl.c |   17 -----------------
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4b4c5b0..9b14364 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -768,23 +768,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
         goto out_err;
     }
 
-    if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
-        switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            /* No problem */
-            break;
-        case -1:
-            rc = ERROR_FAIL;
-            goto out_err;
-        default: abort();
-        }
-    }
-
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:32: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 1U5h8I-0004qk-HH; Wed, 13 Feb 2013 18:32:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qF-AF
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:38709] by server-1.bemta-4.messagelabs.com id
	41/B9-08839-34CDB115; Wed, 13 Feb 2013 18:32:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360780354!17636438!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6317 invoked from network); 13 Feb 2013 18:32:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 870D2C56197;
	Wed, 13 Feb 2013 18:32:34 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:10 +0000
Message-Id: <1360780340-19117-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 01/11] libxl_json: Export json_object related
	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>
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

Export libxl__json_object_alloc and libxl__json_object_append_to to
use them in a later patch.

Backported from xen-unstable patch:
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693129 -3600
: Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
: Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   14 ++++++++++++--
 tools/libxl/libxl_json.c     |   32 ++++++++++++++++----------------
 2 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a135cd7..2959527 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1512,6 +1512,15 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
         return -1;
 }
 
+/*
+ * NOGC can be used with those json_object functions, but the
+ * libxl__json_object* will need to be freed with libxl__json_object_free.
+ */
+_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt,
+                                                     libxl__json_node_type type);
+_hidden int libxl__json_object_append_to(libxl__gc *gc_opt,
+                                         libxl__json_object *obj,
+                                         libxl__json_object *dst);
 _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                   int i);
 _hidden
@@ -1520,9 +1529,10 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
-_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
+_hidden void libxl__json_object_free(libxl__gc *gc_opt,
+                                     libxl__json_object *obj);
 
-_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
+_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s);
 
   /* Based on /local/domain/$domid/dm-version xenstore key
    * default is qemu xen traditional */
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index caa8312..0b0cf2f 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
  * libxl__json_object helper functions
  */
 
-static libxl__json_object *json_object_alloc(libxl__gc *gc,
+libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                              libxl__json_node_type type)
 {
     libxl__json_object *obj;
@@ -236,7 +236,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     return obj;
 }
 
-static int json_object_append_to(libxl__gc *gc,
+int libxl__json_object_append_to(libxl__gc *gc,
                                  libxl__json_object *obj,
                                  libxl__json_object *dst)
 {
@@ -393,10 +393,10 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
         return 0;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -411,11 +411,11 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = json_object_alloc(ctx->gc,
+    if ((obj = libxl__json_object_alloc(ctx->gc,
                                  boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
         return 0;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -448,7 +448,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
+        if ((obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
             return 0;
         obj->u.d = d;
     } else {
@@ -458,7 +458,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
+        if ((obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
             return 0;
         obj->u.i = i;
     }
@@ -466,7 +466,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
 
 error:
     /* If the conversion fail, we just store the original string. */
-    if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
         return 0;
 
     t = malloc(len + 1);
@@ -481,7 +481,7 @@ error:
     obj->u.string = t;
 
 out:
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -508,13 +508,13 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
         free(t);
         return 0;
     }
     obj->u.string = t;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -573,11 +573,11 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
         return 0;
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
@@ -615,11 +615,11 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
         return 0;
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:32: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 1U5h8I-0004qk-HH; Wed, 13 Feb 2013 18:32:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qF-AF
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:38709] by server-1.bemta-4.messagelabs.com id
	41/B9-08839-34CDB115; Wed, 13 Feb 2013 18:32:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360780354!17636438!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6317 invoked from network); 13 Feb 2013 18:32:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 870D2C56197;
	Wed, 13 Feb 2013 18:32:34 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:10 +0000
Message-Id: <1360780340-19117-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 01/11] libxl_json: Export json_object related
	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>
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

Export libxl__json_object_alloc and libxl__json_object_append_to to
use them in a later patch.

Backported from xen-unstable patch:
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693129 -3600
: Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
: Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   14 ++++++++++++--
 tools/libxl/libxl_json.c     |   32 ++++++++++++++++----------------
 2 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a135cd7..2959527 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1512,6 +1512,15 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
         return -1;
 }
 
+/*
+ * NOGC can be used with those json_object functions, but the
+ * libxl__json_object* will need to be freed with libxl__json_object_free.
+ */
+_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt,
+                                                     libxl__json_node_type type);
+_hidden int libxl__json_object_append_to(libxl__gc *gc_opt,
+                                         libxl__json_object *obj,
+                                         libxl__json_object *dst);
 _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                   int i);
 _hidden
@@ -1520,9 +1529,10 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
-_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
+_hidden void libxl__json_object_free(libxl__gc *gc_opt,
+                                     libxl__json_object *obj);
 
-_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
+_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s);
 
   /* Based on /local/domain/$domid/dm-version xenstore key
    * default is qemu xen traditional */
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index caa8312..0b0cf2f 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
  * libxl__json_object helper functions
  */
 
-static libxl__json_object *json_object_alloc(libxl__gc *gc,
+libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                              libxl__json_node_type type)
 {
     libxl__json_object *obj;
@@ -236,7 +236,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     return obj;
 }
 
-static int json_object_append_to(libxl__gc *gc,
+int libxl__json_object_append_to(libxl__gc *gc,
                                  libxl__json_object *obj,
                                  libxl__json_object *dst)
 {
@@ -393,10 +393,10 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
         return 0;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -411,11 +411,11 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = json_object_alloc(ctx->gc,
+    if ((obj = libxl__json_object_alloc(ctx->gc,
                                  boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
         return 0;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -448,7 +448,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
+        if ((obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
             return 0;
         obj->u.d = d;
     } else {
@@ -458,7 +458,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
+        if ((obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
             return 0;
         obj->u.i = i;
     }
@@ -466,7 +466,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
 
 error:
     /* If the conversion fail, we just store the original string. */
-    if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
         return 0;
 
     t = malloc(len + 1);
@@ -481,7 +481,7 @@ error:
     obj->u.string = t;
 
 out:
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -508,13 +508,13 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
         free(t);
         return 0;
     }
     obj->u.string = t;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -573,11 +573,11 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
         return 0;
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
@@ -615,11 +615,11 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
         return 0;
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 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 1U5h8I-0004qr-TB; Wed, 13 Feb 2013 18:32:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qG-MN
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:38712] by server-2.bemta-4.messagelabs.com id
	83/CB-01597-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12044 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1B1F9C5619C;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:13 +0000
Message-Id: <1360780340-19117-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 04/11] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function converts a libxl__json_object to yajl by calling every
yajl_gen_* function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing
yajl_gen tree.

This function is used in a later patch.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 74dee58cfc0d2d6594f388db3b4d2ce91d1bb204
: Parent  3f71aab0e2774ded0c5a03436c364fb031ba9aa0

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    3 ++
 tools/libxl/libxl_json.c     |   61 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7dbd8af..b00ff61 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1539,6 +1539,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 _hidden void libxl__json_object_free(libxl__gc *gc_opt,
                                      libxl__json_object *obj);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 98db465..72b52e8 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -381,6 +381,67 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int idx = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_BOOL:
+        return yajl_gen_bool(hand, obj->u.b);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ANY:
+        /* JSON_ANY is not a valid value for obj->type. */
+        ;
+    }
+    abort();
+}
+
 
 /*
  * JSON callbacks
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 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 1U5h8I-0004qr-TB; Wed, 13 Feb 2013 18:32:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8G-0004qG-MN
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:36 +0000
Received: from [85.158.143.99:38712] by server-2.bemta-4.messagelabs.com id
	83/CB-01597-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12044 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1B1F9C5619C;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:13 +0000
Message-Id: <1360780340-19117-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 04/11] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function converts a libxl__json_object to yajl by calling every
yajl_gen_* function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing
yajl_gen tree.

This function is used in a later patch.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 74dee58cfc0d2d6594f388db3b4d2ce91d1bb204
: Parent  3f71aab0e2774ded0c5a03436c364fb031ba9aa0

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    3 ++
 tools/libxl/libxl_json.c     |   61 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7dbd8af..b00ff61 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1539,6 +1539,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 _hidden void libxl__json_object_free(libxl__gc *gc_opt,
                                      libxl__json_object *obj);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 98db465..72b52e8 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -381,6 +381,67 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int idx = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_BOOL:
+        return yajl_gen_bool(hand, obj->u.b);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ANY:
+        /* JSON_ANY is not a valid value for obj->type. */
+        ;
+    }
+    abort();
+}
+
 
 /*
  * JSON callbacks
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8M-0004sS-3L; Wed, 13 Feb 2013 18:32:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8K-0004rH-Nb
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:40 +0000
Received: from [85.158.137.99:6780] by server-14.bemta-3.messagelabs.com id
	F9/82-23533-34CDB115; Wed, 13 Feb 2013 18:32:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360780354!17907580!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1299 invoked from network); 13 Feb 2013 18:32:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:32:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 58B6EC56195;
	Wed, 13 Feb 2013 18:32:24 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:09 +0000
Message-Id: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [v3] QEMU: Enabling live-migrate on HVM on qemu-xen
	device model in 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>
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 patch series consists of 2	parts:
* 11 patches to	libxl
* 5 patches to QEMU

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

The difference between this patch series and the previous series
is patches 10 and 11 have been swapped around.

I would	suggest	these patches should be included in 4.2.2.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8M-0004sS-3L; Wed, 13 Feb 2013 18:32:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8K-0004rH-Nb
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:40 +0000
Received: from [85.158.137.99:6780] by server-14.bemta-3.messagelabs.com id
	F9/82-23533-34CDB115; Wed, 13 Feb 2013 18:32:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360780354!17907580!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1299 invoked from network); 13 Feb 2013 18:32:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:32:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 58B6EC56195;
	Wed, 13 Feb 2013 18:32:24 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:09 +0000
Message-Id: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [v3] QEMU: Enabling live-migrate on HVM on qemu-xen
	device model in 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>
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 patch series consists of 2	parts:
* 11 patches to	libxl
* 5 patches to QEMU

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

The difference between this patch series and the previous series
is patches 10 and 11 have been swapped around.

I would	suggest	these patches should be included in 4.2.2.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8K-0004rN-H6; Wed, 13 Feb 2013 18:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8H-0004qH-4k
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:37 +0000
Received: from [85.158.143.99:38736] by server-3.bemta-4.messagelabs.com id
	2D/10-08920-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!3
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12054 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 7AF40C561A2;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:15 +0000
Message-Id: <1360780340-19117-7-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 06/11] libxl_qmp: Use qmp_parameters_* functions
	for param list of a QMP 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>
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

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693133 -3600
: Node ID be5d014f91dfbd67afacc3385c265243794a246f
: Parent  6f7847729f0f42614de516d15257ede7243f995f

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   89 ++++++++++++++++-------------------------------
 1 files changed, 30 insertions(+), 59 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 827f1b7..605e8f3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -503,7 +503,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -527,7 +527,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -561,7 +561,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -589,7 +589,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -624,7 +624,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  */
@@ -659,6 +658,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,11 +669,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -801,8 +801,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -815,31 +814,22 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -847,24 +837,18 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -882,56 +866,43 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     if (!args) {
         rc = ERROR_NOMEM;
-        goto out2;
+        goto out;
     }
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
 
-out2:
-    flexarray_free(parameters);
 out:
     libxl__qmp_close(qmp);
     return rc;
+
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:32:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8K-0004rN-H6; Wed, 13 Feb 2013 18:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8H-0004qH-4k
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:37 +0000
Received: from [85.158.143.99:38736] by server-3.bemta-4.messagelabs.com id
	2D/10-08920-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!3
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12054 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 7AF40C561A2;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:15 +0000
Message-Id: <1360780340-19117-7-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 06/11] libxl_qmp: Use qmp_parameters_* functions
	for param list of a QMP 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>
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

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693133 -3600
: Node ID be5d014f91dfbd67afacc3385c265243794a246f
: Parent  6f7847729f0f42614de516d15257ede7243f995f

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   89 ++++++++++++++++-------------------------------
 1 files changed, 30 insertions(+), 59 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 827f1b7..605e8f3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -503,7 +503,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -527,7 +527,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -561,7 +561,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -589,7 +589,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -624,7 +624,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  */
@@ -659,6 +658,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,11 +669,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -801,8 +801,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -815,31 +814,22 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -847,24 +837,18 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -882,56 +866,43 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     if (!args) {
         rc = ERROR_NOMEM;
-        goto out2;
+        goto out;
     }
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
 
-out2:
-    flexarray_free(parameters);
 out:
     libxl__qmp_close(qmp);
     return rc;
+
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:33: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 1U5h8L-0004ri-0L; Wed, 13 Feb 2013 18:32:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8H-0004qG-JI
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:37 +0000
Received: from [85.158.143.99:30395] by server-2.bemta-4.messagelabs.com id
	95/CB-01597-54CDB115; Wed, 13 Feb 2013 18:32:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!6
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12108 invoked from network); 13 Feb 2013 18:32:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 17C3EC561A5;
	Wed, 13 Feb 2013 18:32:36 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:18 +0000
Message-Id: <1360780340-19117-10-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 09/11] libxl_dom: Call the right switch logdirty
	for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen right now is synchronous, not like the one to
qemu-xen-traditional.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 08fac5c2bf3dcbc493ce45091383f6ce1938f369
: Parent  d4aec9eff7e6d15c2805957af620c82555553b3e

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_dom.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:33: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 1U5h8L-0004ri-0L; Wed, 13 Feb 2013 18:32:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8H-0004qG-JI
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:37 +0000
Received: from [85.158.143.99:30395] by server-2.bemta-4.messagelabs.com id
	95/CB-01597-54CDB115; Wed, 13 Feb 2013 18:32:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!6
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12108 invoked from network); 13 Feb 2013 18:32:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 17C3EC561A5;
	Wed, 13 Feb 2013 18:32:36 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:18 +0000
Message-Id: <1360780340-19117-10-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 09/11] libxl_dom: Call the right switch logdirty
	for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen right now is synchronous, not like the one to
qemu-xen-traditional.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 08fac5c2bf3dcbc493ce45091383f6ce1938f369
: Parent  d4aec9eff7e6d15c2805957af620c82555553b3e

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_dom.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8M-0004sp-GS; Wed, 13 Feb 2013 18:32:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8L-0004rp-P8
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:41 +0000
Received: from [85.158.138.51:9176] by server-11.bemta-3.messagelabs.com id
	2C/42-10249-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360780355!27507644!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15224 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-174.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id B01F9C5619A;
	Wed, 13 Feb 2013 18:32:34 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:11 +0000
Message-Id: <1360780340-19117-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 value from libxl__json_node_type is never used.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693130 -3600
: Node ID 4a6d5d8cba4fc44f9bbda201188885868604b8e8
: Parent  c9b80c7f8db1a5d26906a2298c481bf7e87fda94

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2959527..5b285d4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1428,7 +1428,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
-    JSON_ERROR,
     JSON_NULL,
     JSON_TRUE,
     JSON_FALSE,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h8M-0004sp-GS; Wed, 13 Feb 2013 18:32:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8L-0004rp-P8
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:41 +0000
Received: from [85.158.138.51:9176] by server-11.bemta-3.messagelabs.com id
	2C/42-10249-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-174.messagelabs.com!1360780355!27507644!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15224 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-174.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id B01F9C5619A;
	Wed, 13 Feb 2013 18:32:34 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:11 +0000
Message-Id: <1360780340-19117-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 02/11] libxl_json: Remove JSON_ERROR from enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 value from libxl__json_node_type is never used.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693130 -3600
: Node ID 4a6d5d8cba4fc44f9bbda201188885868604b8e8
: Parent  c9b80c7f8db1a5d26906a2298c481bf7e87fda94

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2959527..5b285d4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1428,7 +1428,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
-    JSON_ERROR,
     JSON_NULL,
     JSON_TRUE,
     JSON_FALSE,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:33: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 1U5h8L-0004sF-Lb; Wed, 13 Feb 2013 18:32:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8K-0004qv-Cp
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:40 +0000
Received: from [193.109.254.147:57434] by server-16.bemta-14.messagelabs.com
	id 4F/52-25906-64CDB115; Wed, 13 Feb 2013 18:32:38 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360780355!3520908!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5225 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id DE714C5619B;
	Wed, 13 Feb 2013 18:32:34 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:12 +0000
Message-Id: <1360780340-19117-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 03/11] libxl_json: Replace JSON_TRUE/FALSE by
	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Those two JSON_TRUE and JSON_FALSE were types of node. But it's better
to have a unique JSON_BOOL type.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693131 -3600
: Node ID 3f71aab0e2774ded0c5a03436c364fb031ba9aa0
: Parent  4a6d5d8cba4fc44f9bbda201188885868604b8e8

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   15 +++++++++++++--
 tools/libxl/libxl_json.c     |    3 +--
 tools/libxl/libxl_qmp.c      |    3 ++-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5b285d4..7dbd8af 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1429,8 +1429,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
     JSON_NULL,
-    JSON_TRUE,
-    JSON_FALSE,
+    JSON_BOOL,
     JSON_INTEGER,
     JSON_DOUBLE,
     /* number is store in string, it's too big to be a long long or a double */
@@ -1444,6 +1443,7 @@ typedef enum {
 typedef struct libxl__json_object {
     libxl__json_node_type type;
     union {
+        bool b;
         long long i;
         double d;
         char *string;
@@ -1462,6 +1462,10 @@ typedef struct {
 
 typedef struct libxl__yajl_ctx libxl__yajl_ctx;
 
+static inline bool libxl__json_object_is_bool(const libxl__json_object *o)
+{
+    return o != NULL && o->type == JSON_BOOL;
+}
 static inline bool libxl__json_object_is_string(const libxl__json_object *o)
 {
     return o != NULL && o->type == JSON_STRING;
@@ -1479,6 +1483,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o)
     return o != NULL && o->type == JSON_ARRAY;
 }
 
+static inline bool libxl__json_object_get_bool(const libxl__json_object *o)
+{
+    if (libxl__json_object_is_bool(o))
+        return o->u.b;
+    else
+        return false;
+}
 static inline
 const char *libxl__json_object_get_string(const libxl__json_object *o)
 {
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0b0cf2f..98db465 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -411,8 +411,7 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = libxl__json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL)) == NULL)
         return 0;
 
     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e33b130..9e86c35 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
         goto out;
     }
 
-    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+    obj = libxl__json_map_get("enabled", o, JSON_BOOL);
+    if (!obj || !libxl__json_object_get_bool(obj)) {
         rc = 0;
         goto out;
     }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:33: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 1U5h8L-0004sF-Lb; Wed, 13 Feb 2013 18:32:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8K-0004qv-Cp
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:40 +0000
Received: from [193.109.254.147:57434] by server-16.bemta-14.messagelabs.com
	id 4F/52-25906-64CDB115; Wed, 13 Feb 2013 18:32:38 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360780355!3520908!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5225 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-27.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id DE714C5619B;
	Wed, 13 Feb 2013 18:32:34 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:12 +0000
Message-Id: <1360780340-19117-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 03/11] libxl_json: Replace JSON_TRUE/FALSE by
	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Those two JSON_TRUE and JSON_FALSE were types of node. But it's better
to have a unique JSON_BOOL type.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693131 -3600
: Node ID 3f71aab0e2774ded0c5a03436c364fb031ba9aa0
: Parent  4a6d5d8cba4fc44f9bbda201188885868604b8e8

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   15 +++++++++++++--
 tools/libxl/libxl_json.c     |    3 +--
 tools/libxl/libxl_qmp.c      |    3 ++-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5b285d4..7dbd8af 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1429,8 +1429,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
     JSON_NULL,
-    JSON_TRUE,
-    JSON_FALSE,
+    JSON_BOOL,
     JSON_INTEGER,
     JSON_DOUBLE,
     /* number is store in string, it's too big to be a long long or a double */
@@ -1444,6 +1443,7 @@ typedef enum {
 typedef struct libxl__json_object {
     libxl__json_node_type type;
     union {
+        bool b;
         long long i;
         double d;
         char *string;
@@ -1462,6 +1462,10 @@ typedef struct {
 
 typedef struct libxl__yajl_ctx libxl__yajl_ctx;
 
+static inline bool libxl__json_object_is_bool(const libxl__json_object *o)
+{
+    return o != NULL && o->type == JSON_BOOL;
+}
 static inline bool libxl__json_object_is_string(const libxl__json_object *o)
 {
     return o != NULL && o->type == JSON_STRING;
@@ -1479,6 +1483,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o)
     return o != NULL && o->type == JSON_ARRAY;
 }
 
+static inline bool libxl__json_object_get_bool(const libxl__json_object *o)
+{
+    if (libxl__json_object_is_bool(o))
+        return o->u.b;
+    else
+        return false;
+}
 static inline
 const char *libxl__json_object_get_string(const libxl__json_object *o)
 {
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0b0cf2f..98db465 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -411,8 +411,7 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = libxl__json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL)) == NULL)
         return 0;
 
     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e33b130..9e86c35 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
         goto out;
     }
 
-    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+    obj = libxl__json_map_get("enabled", o, JSON_BOOL);
+    if (!obj || !libxl__json_object_get_bool(obj)) {
         rc = 0;
         goto out;
     }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:33: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 1U5h8K-0004rD-3C; Wed, 13 Feb 2013 18:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8H-0004qG-4i
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:37 +0000
Received: from [85.158.143.99:38732] by server-2.bemta-4.messagelabs.com id
	44/CB-01597-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!4
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12066 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id ABAFCC561A3;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:16 +0000
Message-Id: <1360780340-19117-8-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 07/11] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 new function connects to QEMU, sends the command and disconnects.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693134 -3600
: Node ID f3890916496445c97d6778d6c986b0270ff707f2
: Parent  be5d014f91dfbd67afacc3385c265243794a246f

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   77 +++++++++++++---------------------------------
 1 files changed, 22 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 605e8f3..b09bf13 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -798,6 +798,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -836,21 +853,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "id", id);
-
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
 }
 
 int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
@@ -865,27 +871,10 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
-
-out:
-    libxl__qmp_close(qmp);
-    return rc;
 
+    return qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                           NULL, NULL);
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
@@ -908,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:33: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 1U5h8K-0004rD-3C; Wed, 13 Feb 2013 18:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h8H-0004qG-4i
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:32:37 +0000
Received: from [85.158.143.99:38732] by server-2.bemta-4.messagelabs.com id
	44/CB-01597-44CDB115; Wed, 13 Feb 2013 18:32:36 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1360780355!26501089!4
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12066 invoked from network); 13 Feb 2013 18:32:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Feb 2013 18:32:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id ABAFCC561A3;
	Wed, 13 Feb 2013 18:32:35 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:16 +0000
Message-Id: <1360780340-19117-8-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 07/11] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 new function connects to QEMU, sends the command and disconnects.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693134 -3600
: Node ID f3890916496445c97d6778d6c986b0270ff707f2
: Parent  be5d014f91dfbd67afacc3385c265243794a246f

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   77 +++++++++++++---------------------------------
 1 files changed, 22 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 605e8f3..b09bf13 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -798,6 +798,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -836,21 +853,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "id", id);
-
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
 }
 
 int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
@@ -865,27 +871,10 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
-
-out:
-    libxl__qmp_close(qmp);
-    return rc;
 
+    return qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                           NULL, NULL);
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
@@ -908,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9T-0005a7-29; Wed, 13 Feb 2013 18:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005YY-DC
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.137.99:2145] by server-10.bemta-3.messagelabs.com id
	CD/D5-10609-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360780427!19008601!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27145 invoked from network); 13 Feb 2013 18:33:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-15.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:33:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id EB638C561AB;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:45 +0000
Message-Id: <1360780425-19607-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 5/5] xen: Set the vram dirty when an error occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 xen-all.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 121289d..dbd759c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
@@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
         while (map != 0) {
             j = ffsl(map) - 1;
             map &= ~(1ul << j);
-            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
+            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
+            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
+            cpu_physical_memory_set_dirty(todirty);
         };
     }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9S-0005Zl-Kv; Wed, 13 Feb 2013 18:33:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005YM-3C
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.143.35:45819] by server-1.bemta-4.messagelabs.com id
	A2/8A-08839-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360780427!12435985!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27775 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-21.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 560ABC5619B;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:42 +0000
Message-Id: <1360780425-19607-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 2/5] xen: Introduce xen_modified_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>
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 function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 hw/xen.h   |    1 +
 xen-all.c  |   21 +++++++++++++++++++++
 xen-stub.c |    4 ++++
 3 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index 2162111..359a275 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -45,6 +45,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/xen-all.c b/xen-all.c
index 6b4e511..121289d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1135,3 +1135,24 @@ void destroy_hvm_domain(bool reboot)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(cpu_physical_memory_get_dirty_tracking())) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 25317ec..7b54477 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -48,3 +48,7 @@ int xen_init(void)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9T-0005a7-29; Wed, 13 Feb 2013 18:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005YY-DC
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.137.99:2145] by server-10.bemta-3.messagelabs.com id
	CD/D5-10609-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360780427!19008601!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27145 invoked from network); 13 Feb 2013 18:33:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-15.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:33:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id EB638C561AB;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:45 +0000
Message-Id: <1360780425-19607-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 5/5] xen: Set the vram dirty when an error occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 xen-all.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 121289d..dbd759c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
@@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
         while (map != 0) {
             j = ffsl(map) - 1;
             map &= ~(1ul << j);
-            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
+            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
+            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
+            cpu_physical_memory_set_dirty(todirty);
         };
     }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9S-0005Zl-Kv; Wed, 13 Feb 2013 18:33:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005YM-3C
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.143.35:45819] by server-1.bemta-4.messagelabs.com id
	A2/8A-08839-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360780427!12435985!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27775 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-21.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 560ABC5619B;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:42 +0000
Message-Id: <1360780425-19607-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 2/5] xen: Introduce xen_modified_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>
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 function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 hw/xen.h   |    1 +
 xen-all.c  |   21 +++++++++++++++++++++
 xen-stub.c |    4 ++++
 3 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index 2162111..359a275 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -45,6 +45,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/xen-all.c b/xen-all.c
index 6b4e511..121289d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1135,3 +1135,24 @@ void destroy_hvm_domain(bool reboot)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(cpu_physical_memory_get_dirty_tracking())) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 25317ec..7b54477 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -48,3 +48,7 @@ int xen_init(void)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9T-0005ag-FB; Wed, 13 Feb 2013 18:33:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005YM-IE
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.143.35:45821] by server-1.bemta-4.messagelabs.com id
	B2/8A-08839-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360780427!11716847!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21531 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-21.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id BA6EAC561AA;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:44 +0000
Message-Id: <1360780425-19607-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 4/5] exec, memory: Call to xen_modified_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>
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 patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c   |    4 ++++
 memory.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 511777b..401f9bc 100644
--- a/exec.c
+++ b/exec.c
@@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
            0xff, size >> TARGET_PAGE_BITS);
 
+    if (xen_enabled())
+        xen_modified_memory(new_block->offset, size);
+
     if (kvm_enabled())
         kvm_setup_guest_memory(new_block->host, size);
 
@@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 7c20a07..6e0c596 100644
--- a/memory.c
+++ b/memory.c
@@ -16,6 +16,7 @@
 #include "ioport.h"
 #include "bitops.h"
 #include "kvm.h"
+#include "hw/xen.h"
 #include <assert.h>
 
 unsigned memory_region_transaction_depth = 0;
@@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
 {
     assert(mr->terminates);
+    if (xen_enabled())
+        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
+                            TARGET_PAGE_SIZE);
     return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9T-0005ag-FB; Wed, 13 Feb 2013 18:33:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005YM-IE
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.143.35:45821] by server-1.bemta-4.messagelabs.com id
	B2/8A-08839-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360780427!11716847!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21531 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-21.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id BA6EAC561AA;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:44 +0000
Message-Id: <1360780425-19607-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 4/5] exec, memory: Call to xen_modified_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>
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 patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c   |    4 ++++
 memory.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 511777b..401f9bc 100644
--- a/exec.c
+++ b/exec.c
@@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
            0xff, size >> TARGET_PAGE_BITS);
 
+    if (xen_enabled())
+        xen_modified_memory(new_block->offset, size);
+
     if (kvm_enabled())
         kvm_setup_guest_memory(new_block->host, size);
 
@@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 7c20a07..6e0c596 100644
--- a/memory.c
+++ b/memory.c
@@ -16,6 +16,7 @@
 #include "ioport.h"
 #include "bitops.h"
 #include "kvm.h"
+#include "hw/xen.h"
 #include <assert.h>
 
 unsigned memory_region_transaction_depth = 0;
@@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
 {
     assert(mr->terminates);
+    if (xen_enabled())
+        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
+                            TARGET_PAGE_SIZE);
     return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9T-0005b3-TH; Wed, 13 Feb 2013 18:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005Yc-FK
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.137.99:13572] by server-5.bemta-3.messagelabs.com id
	05/B1-04457-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360780427!19008601!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27136 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-15.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 8B71BC5619C;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:43 +0000
Message-Id: <1360780425-19607-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 3/5] exec: Introduce helper to set dirty 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>
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 new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |   45 +++++++++++++++++----------------------------
 1 files changed, 17 insertions(+), 28 deletions(-)

diff --git a/exec.c b/exec.c
index 6c206ff..511777b 100644
--- a/exec.c
+++ b/exec.c
@@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -4081,6 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
+	    invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -4211,13 +4218,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -4561,13 +4562,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4639,13 +4634,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:33:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18: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 1U5h9T-0005b3-TH; Wed, 13 Feb 2013 18:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9R-0005Yc-FK
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:33:49 +0000
Received: from [85.158.137.99:13572] by server-5.bemta-3.messagelabs.com id
	05/B1-04457-C8CDB115; Wed, 13 Feb 2013 18:33:48 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360780427!19008601!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27136 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-15.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 8B71BC5619C;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:43 +0000
Message-Id: <1360780425-19607-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 3/5] exec: Introduce helper to set dirty 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>
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 new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |   45 +++++++++++++++++----------------------------
 1 files changed, 17 insertions(+), 28 deletions(-)

diff --git a/exec.c b/exec.c
index 6c206ff..511777b 100644
--- a/exec.c
+++ b/exec.c
@@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -4081,6 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
+	    invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -4211,13 +4218,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -4561,13 +4562,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4639,13 +4634,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:34:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:34: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 1U5h9e-0005kg-Az; Wed, 13 Feb 2013 18:34:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9d-0005ja-OH
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:34:01 +0000
Received: from [85.158.139.211:51161] by server-16.bemta-5.messagelabs.com id
	CC/FD-14948-89CDB115; Wed, 13 Feb 2013 18:34:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360780356!19640592!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5585 invoked from network); 13 Feb 2013 18:32:37 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-206.messagelabs.com with SMTP;
	13 Feb 2013 18:32:37 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4781AC561A6;
	Wed, 13 Feb 2013 18:32:36 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:19 +0000
Message-Id: <1360780340-19117-11-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 10/11] libxl: libxl__qmp_save: Add filename as
	JSON parameter to xen-save-devices-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>
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: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ac10f20..b4cc247 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -871,6 +871,7 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__json_object *args = NULL;
 
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     return qmp_run_command(gc, domid, "xen-save-devices-state", args,
                            NULL, NULL);
 }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:34:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:34: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 1U5h9e-0005kg-Az; Wed, 13 Feb 2013 18:34:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5h9d-0005ja-OH
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:34:01 +0000
Received: from [85.158.139.211:51161] by server-16.bemta-5.messagelabs.com id
	CC/FD-14948-89CDB115; Wed, 13 Feb 2013 18:34:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360780356!19640592!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5585 invoked from network); 13 Feb 2013 18:32:37 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-206.messagelabs.com with SMTP;
	13 Feb 2013 18:32:37 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4781AC561A6;
	Wed, 13 Feb 2013 18:32:36 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:32:19 +0000
Message-Id: <1360780340-19117-11-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 10/11] libxl: libxl__qmp_save: Add filename as
	JSON parameter to xen-save-devices-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>
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: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ac10f20..b4cc247 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -871,6 +871,7 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__json_object *args = NULL;
 
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     return qmp_run_command(gc, domid, "xen-save-devices-state", args,
                            NULL, NULL);
 }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:34:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:34: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 1U5hAO-000685-Pe; Wed, 13 Feb 2013 18:34:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5hAN-00067a-NS
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:34:47 +0000
Received: from [85.158.139.83:2379] by server-9.bemta-5.messagelabs.com id
	93/2D-24440-6CCDB115; Wed, 13 Feb 2013 18:34:46 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360780486!29769551!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5882 invoked from network); 13 Feb 2013 18:34:46 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	13 Feb 2013 18:34:46 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 23502C5619A;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:41 +0000
Message-Id: <1360780425-19607-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 1/5] QMP,
	Introduce xen-set-global-dirty-log 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>
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 command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |    6 ++++++
 xen-stub.c       |    5 +++++
 4 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index a669e98..bb0d7c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -905,3 +905,16 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.3
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index bf1df49..0de68df 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -472,6 +472,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/xen-all.c b/xen-all.c
index 3256509..6b4e511 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -12,6 +12,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -524,6 +525,11 @@ static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
     .log_stop = xen_log_stop,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    cpu_physical_memory_set_dirty_tracking(!!enable);
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..25317ec 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:34:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:34: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 1U5hAO-000685-Pe; Wed, 13 Feb 2013 18:34:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5hAN-00067a-NS
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:34:47 +0000
Received: from [85.158.139.83:2379] by server-9.bemta-5.messagelabs.com id
	93/2D-24440-6CCDB115; Wed, 13 Feb 2013 18:34:46 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360780486!29769551!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5882 invoked from network); 13 Feb 2013 18:34:46 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	13 Feb 2013 18:34:46 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 23502C5619A;
	Wed, 13 Feb 2013 18:33:47 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:41 +0000
Message-Id: <1360780425-19607-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
References: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCH 1/5] QMP,
	Introduce xen-set-global-dirty-log 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>
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 command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |    6 ++++++
 xen-stub.c       |    5 +++++
 4 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index a669e98..bb0d7c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -905,3 +905,16 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.3
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index bf1df49..0de68df 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -472,6 +472,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/xen-all.c b/xen-all.c
index 3256509..6b4e511 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -12,6 +12,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -524,6 +525,11 @@ static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
     .log_stop = xen_log_stop,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    cpu_physical_memory_set_dirty_tracking(!!enable);
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..25317ec 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:35:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:35: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 1U5hAt-0006Nm-74; Wed, 13 Feb 2013 18:35:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5hAr-0006Mf-7L
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:35:17 +0000
Received: from [85.158.143.35:47324] by server-3.bemta-4.messagelabs.com id
	AC/81-08920-4ECDB115; Wed, 13 Feb 2013 18:35:16 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360780427!10205754!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23637 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-21.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E849CC56197;
	Wed, 13 Feb 2013 18:33:46 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:40 +0000
Message-Id: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] QEMU: Enabling live-migrate on HVM on qemu-xen device
	model in 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>
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 patch series consists of 2 parts:
* 11 patches to libxl
* 5 patches to QEMU

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

The difference between this patch series and the previous series
is patches 10 and 11 have been swapped around.

I would suggest these patches should be included in 4.2.2.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:35:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:35: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 1U5hAt-0006Nm-74; Wed, 13 Feb 2013 18:35:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U5hAr-0006Mf-7L
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:35:17 +0000
Received: from [85.158.143.35:47324] by server-3.bemta-4.messagelabs.com id
	AC/81-08920-4ECDB115; Wed, 13 Feb 2013 18:35:16 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360780427!10205754!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23637 invoked from network); 13 Feb 2013 18:33:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-21.messagelabs.com with SMTP;
	13 Feb 2013 18:33:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E849CC56197;
	Wed, 13 Feb 2013 18:33:46 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 13 Feb 2013 18:33:40 +0000
Message-Id: <1360780425-19607-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] QEMU: Enabling live-migrate on HVM on qemu-xen device
	model in 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>
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 patch series consists of 2 parts:
* 11 patches to libxl
* 5 patches to QEMU

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

The difference between this patch series and the previous series
is patches 10 and 11 have been swapped around.

I would suggest these patches should be included in 4.2.2.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:38:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:38: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 1U5hDP-0007G2-1K; Wed, 13 Feb 2013 18:37:55 +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 1U5hDN-0007FL-Ag
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:37:53 +0000
Received: from [85.158.139.83:20415] by server-13.bemta-5.messagelabs.com id
	5C/F4-06769-08DDB115; Wed, 13 Feb 2013 18:37:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360780670!24842166!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18061 invoked from network); 13 Feb 2013 18:37:51 -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;
	13 Feb 2013 18:37:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7380127"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 18:37:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 13:37:49 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5hDJ-00054Y-LN;
	Wed, 13 Feb 2013 18:37:49 +0000
Message-ID: <1360780669.16636.94.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Wed, 13 Feb 2013 18:37:49 +0000
In-Reply-To: <1360779868.16636.92.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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

A slightly upgraded version of the *UNTESTED* patch.


Wei.

----8<----
commit df4c929d034cec7043fbd96ba89833eb639c336e
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Wed Feb 13 18:17:01 2013 +0000

    netback: fix netbk_count_requests
    
    There are two paths in the original code, a) test against work_to_do, b) test
    against first->size, could return 0 even when error happens.
    
    Simply return -1 in error paths should work. Modify all error paths to return
    -1 to be consistent.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 103294d..0e0162e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (frags >= work_to_do) {
 			netdev_err(vif->dev, "Need more frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
 			netdev_err(vif->dev, "Too many frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
@@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (txp->size > first->size) {
 			netdev_err(vif->dev, "Frag is bigger than frame.\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 
 		first->size -= txp->size;
@@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
 			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
 	return frags;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:38:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:38: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 1U5hDP-0007G2-1K; Wed, 13 Feb 2013 18:37:55 +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 1U5hDN-0007FL-Ag
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 18:37:53 +0000
Received: from [85.158.139.83:20415] by server-13.bemta-5.messagelabs.com id
	5C/F4-06769-08DDB115; Wed, 13 Feb 2013 18:37:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360780670!24842166!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18061 invoked from network); 13 Feb 2013 18:37:51 -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;
	13 Feb 2013 18:37:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7380127"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 18:37:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 13:37:49 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5hDJ-00054Y-LN;
	Wed, 13 Feb 2013 18:37:49 +0000
Message-ID: <1360780669.16636.94.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Wed, 13 Feb 2013 18:37:49 +0000
In-Reply-To: <1360779868.16636.92.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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

A slightly upgraded version of the *UNTESTED* patch.


Wei.

----8<----
commit df4c929d034cec7043fbd96ba89833eb639c336e
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Wed Feb 13 18:17:01 2013 +0000

    netback: fix netbk_count_requests
    
    There are two paths in the original code, a) test against work_to_do, b) test
    against first->size, could return 0 even when error happens.
    
    Simply return -1 in error paths should work. Modify all error paths to return
    -1 to be consistent.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 103294d..0e0162e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (frags >= work_to_do) {
 			netdev_err(vif->dev, "Need more frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
 			netdev_err(vif->dev, "Too many frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
@@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (txp->size > first->size) {
 			netdev_err(vif->dev, "Frag is bigger than frame.\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 
 		first->size -= txp->size;
@@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
 			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -1;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
 	return frags;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:58:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:58: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 1U5hXN-0007np-9t; Wed, 13 Feb 2013 18:58: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 1U5hXL-0007nk-Sc
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 18:58:31 +0000
Received: from [85.158.137.99:14971] by server-10.bemta-3.messagelabs.com id
	3F/0A-10609-652EB115; Wed, 13 Feb 2013 18:58:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360781910!18167980!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23714 invoked from network); 13 Feb 2013 18:58:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 18:58:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (josoe mo6) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z01a37p1DHlvT9 ;
	Wed, 13 Feb 2013 19:58:27 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0E9421884C; Wed, 13 Feb 2013 19:58:26 +0100 (CET)
Date: Wed, 13 Feb 2013 19:58:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130213185826.GA25891@aepfle.de>
References: <20130213181103.GC20042@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213181103.GC20042@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, Konrad Rzeszutek Wilk wrote:

> Any thoughts of what might be wrong?

Do you have a xenctx output when it hangs?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 18:58:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 18:58: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 1U5hXN-0007np-9t; Wed, 13 Feb 2013 18:58: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 1U5hXL-0007nk-Sc
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 18:58:31 +0000
Received: from [85.158.137.99:14971] by server-10.bemta-3.messagelabs.com id
	3F/0A-10609-652EB115; Wed, 13 Feb 2013 18:58:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360781910!18167980!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1Mzg0MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23714 invoked from network); 13 Feb 2013 18:58:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 18:58:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (josoe mo6) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z01a37p1DHlvT9 ;
	Wed, 13 Feb 2013 19:58:27 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 0E9421884C; Wed, 13 Feb 2013 19:58:26 +0100 (CET)
Date: Wed, 13 Feb 2013 19:58:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130213185826.GA25891@aepfle.de>
References: <20130213181103.GC20042@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213181103.GC20042@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, Konrad Rzeszutek Wilk wrote:

> Any thoughts of what might be wrong?

Do you have a xenctx output when it hangs?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 19:21:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 19: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 1U5hsq-0008EI-8r; Wed, 13 Feb 2013 19:20:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1U5hso-0008ED-No
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 19:20:42 +0000
Received: from [85.158.137.99:41098] by server-15.bemta-3.messagelabs.com id
	4E/DF-25405-587EB115; Wed, 13 Feb 2013 19:20:37 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360783235!17911904!1
X-Originating-IP: [74.125.82.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18694 invoked from network); 13 Feb 2013 19:20:35 -0000
Received: from mail-we0-f178.google.com (HELO mail-we0-f178.google.com)
	(74.125.82.178)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 19:20:35 -0000
Received: by mail-we0-f178.google.com with SMTP id x48so1269110wey.23
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 11:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding;
	bh=jdhyKiKJGT9SDZGcxaNqGf1pGRNcEfiIayaJ7Npa9TM=;
	b=HdbUKd+HpOchLkSHpggXN3dJaJCbm3hfhCC1Us7auU9jCF4WgNweqAOmaYrLG7qWGf
	8SSnV24PLLB3+SD2yuEDl894IW9PTvBIIxRCCTZteML77oV+uHybe5bGy/XZFMxnorZH
	sBAYDEfZyd32AkFB9/d+yZHGbo03pPVVm8B0CMFzXdltumdkTgcRnyDRaHQf7PAlGcTY
	YB2kf03O09KhLZlQgFqADZE3/q+iruL0oMA+Je7DUqrtGLYBj9ZO1PAdObvhVwE7D5MY
	SAtgyeLcg/brKsthl61ponfRDerE/hMpnhT1lFVSxFMd1JfydAOsERxAPhAVYRhpn4/8
	fCZQ==
X-Received: by 10.180.92.39 with SMTP id cj7mr12240465wib.19.1360783234862;
	Wed, 13 Feb 2013 11:20:34 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id ex1sm47985462wib.7.2013.02.13.11.20.32
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 13 Feb 2013 11:20:34 -0800 (PST)
Message-ID: <511BE780.9000707@cantab.net>
Date: Wed, 13 Feb 2013 19:20:32 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	<51181924.4050500@theshore.net>	<1360583103.16636.29.camel@zion.uk.xensource.com>	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	<511AFFC9.3050404@theshore.net>	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
In-Reply-To: <1360780669.16636.94.camel@zion.uk.xensource.com>
X-Enigmail-Version: 1.0.1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13/02/13 18:37, Wei Liu wrote:
> A slightly upgraded version of the *UNTESTED* patch.
> 
> 
> Wei.
> 
> ----8<----
> commit df4c929d034cec7043fbd96ba89833eb639c336e
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Wed Feb 13 18:17:01 2013 +0000
> 
>     netback: fix netbk_count_requests
>     
>     There are two paths in the original code, a) test against work_to_do, b) test
>     against first->size, could return 0 even when error happens.
>     
>     Simply return -1 in error paths should work. Modify all error paths to return
>     -1 to be consistent.

You also need to remove the netbk_tx_err() after checking the result of
netbk_count_requests().  Otherwise you will have a double xenvif_put(),
which will screw up ref counting.

I would also suggest returning -EINVAL from netbk_count_requests().

It not clear to me how this will fix the original oops though.

David

>     
>     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 103294d..0e0162e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (frags >= work_to_do) {
>  			netdev_err(vif->dev, "Need more frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
>  			netdev_err(vif->dev, "Too many frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (txp->size > first->size) {
>  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		first->size -= txp->size;
> @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
>  				 txp->offset, txp->size);
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  	} while ((txp++)->flags & XEN_NETTXF_more_data);
>  	return frags;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 13 19:21:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 19: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 1U5hsq-0008EI-8r; Wed, 13 Feb 2013 19:20:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1U5hso-0008ED-No
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 19:20:42 +0000
Received: from [85.158.137.99:41098] by server-15.bemta-3.messagelabs.com id
	4E/DF-25405-587EB115; Wed, 13 Feb 2013 19:20:37 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360783235!17911904!1
X-Originating-IP: [74.125.82.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18694 invoked from network); 13 Feb 2013 19:20:35 -0000
Received: from mail-we0-f178.google.com (HELO mail-we0-f178.google.com)
	(74.125.82.178)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 19:20:35 -0000
Received: by mail-we0-f178.google.com with SMTP id x48so1269110wey.23
	for <xen-devel@lists.xen.org>; Wed, 13 Feb 2013 11:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding;
	bh=jdhyKiKJGT9SDZGcxaNqGf1pGRNcEfiIayaJ7Npa9TM=;
	b=HdbUKd+HpOchLkSHpggXN3dJaJCbm3hfhCC1Us7auU9jCF4WgNweqAOmaYrLG7qWGf
	8SSnV24PLLB3+SD2yuEDl894IW9PTvBIIxRCCTZteML77oV+uHybe5bGy/XZFMxnorZH
	sBAYDEfZyd32AkFB9/d+yZHGbo03pPVVm8B0CMFzXdltumdkTgcRnyDRaHQf7PAlGcTY
	YB2kf03O09KhLZlQgFqADZE3/q+iruL0oMA+Je7DUqrtGLYBj9ZO1PAdObvhVwE7D5MY
	SAtgyeLcg/brKsthl61ponfRDerE/hMpnhT1lFVSxFMd1JfydAOsERxAPhAVYRhpn4/8
	fCZQ==
X-Received: by 10.180.92.39 with SMTP id cj7mr12240465wib.19.1360783234862;
	Wed, 13 Feb 2013 11:20:34 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id ex1sm47985462wib.7.2013.02.13.11.20.32
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 13 Feb 2013 11:20:34 -0800 (PST)
Message-ID: <511BE780.9000707@cantab.net>
Date: Wed, 13 Feb 2013 19:20:32 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	<51181924.4050500@theshore.net>	<1360583103.16636.29.camel@zion.uk.xensource.com>	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	<511AFFC9.3050404@theshore.net>	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
In-Reply-To: <1360780669.16636.94.camel@zion.uk.xensource.com>
X-Enigmail-Version: 1.0.1
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13/02/13 18:37, Wei Liu wrote:
> A slightly upgraded version of the *UNTESTED* patch.
> 
> 
> Wei.
> 
> ----8<----
> commit df4c929d034cec7043fbd96ba89833eb639c336e
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Wed Feb 13 18:17:01 2013 +0000
> 
>     netback: fix netbk_count_requests
>     
>     There are two paths in the original code, a) test against work_to_do, b) test
>     against first->size, could return 0 even when error happens.
>     
>     Simply return -1 in error paths should work. Modify all error paths to return
>     -1 to be consistent.

You also need to remove the netbk_tx_err() after checking the result of
netbk_count_requests().  Otherwise you will have a double xenvif_put(),
which will screw up ref counting.

I would also suggest returning -EINVAL from netbk_count_requests().

It not clear to me how this will fix the original oops though.

David

>     
>     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 103294d..0e0162e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (frags >= work_to_do) {
>  			netdev_err(vif->dev, "Need more frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
>  			netdev_err(vif->dev, "Too many frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (txp->size > first->size) {
>  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		first->size -= txp->size;
> @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
>  				 txp->offset, txp->size);
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  	} while ((txp++)->flags & XEN_NETTXF_more_data);
>  	return frags;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 13 19:40:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 19: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 1U5iBL-0008Vu-8a; Wed, 13 Feb 2013 19:39:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5iBJ-0008Vp-Ir
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 19:39:49 +0000
Received: from [85.158.138.51:7999] by server-6.bemta-3.messagelabs.com id
	AD/54-29959-40CEB115; Wed, 13 Feb 2013 19:39:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360784385!27515756!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1085 invoked from network); 13 Feb 2013 19:39:47 -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;
	13 Feb 2013 19:39:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7390499"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 19:39:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 14:39:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5iAu-0006RZ-T0;
	Wed, 13 Feb 2013 19:39:24 +0000
Message-ID: <1360784364.16636.105.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Wed, 13 Feb 2013 19:39:24 +0000
In-Reply-To: <511BE780.9000707@cantab.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, 2013-02-13 at 19:20 +0000, David Vrabel wrote:
> On 13/02/13 18:37, Wei Liu wrote:
> > A slightly upgraded version of the *UNTESTED* patch.
> > 
> > 
> > Wei.
> > 
> > ----8<----
> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> > Author: Wei Liu <wei.liu2@citrix.com>
> > Date:   Wed Feb 13 18:17:01 2013 +0000
> > 
> >     netback: fix netbk_count_requests
> >     
> >     There are two paths in the original code, a) test against work_to_do, b) test
> >     against first->size, could return 0 even when error happens.
> >     
> >     Simply return -1 in error paths should work. Modify all error paths to return
> >     -1 to be consistent.
> 
> You also need to remove the netbk_tx_err() after checking the result of
> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
> which will screw up ref counting.
> 

Yes I saw that as well. I was suspecting it was done on purpose. I
didn't write this patch anyway. I thought that Ian at least smoke-tested
it with creation / teardown vif so I just left it like that.

> I would also suggest returning -EINVAL from netbk_count_requests().
> It not clear to me how this will fix the original oops though.
> 

My analysis:

netbk_count_requests returns 0 when an error occurs in the first
iteration (frag = 0, -frag = 0), the caller gets 0 and doesn't notice
this vif has been disconnected. The subsequent call comparison
txreq.size < ETH_HLEN is true for some reason - frontend messes up the
txreq (this could also be the same reason that netbk_count_requests
fails in first iteration), and a subsequent call to netbk_tx_err
triggers the bug.


Wei.

> David
> 
> >     
> >     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 103294d..0e0162e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (frags >= work_to_do) {
> >  			netdev_err(vif->dev, "Need more frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
> >  			netdev_err(vif->dev, "Too many frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> > @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (txp->size > first->size) {
> >  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		first->size -= txp->size;
> > @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
> >  				 txp->offset, txp->size);
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> >  	return frags;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Feb 13 19:40:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 19: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 1U5iBL-0008Vu-8a; Wed, 13 Feb 2013 19:39:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5iBJ-0008Vp-Ir
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 19:39:49 +0000
Received: from [85.158.138.51:7999] by server-6.bemta-3.messagelabs.com id
	AD/54-29959-40CEB115; Wed, 13 Feb 2013 19:39:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360784385!27515756!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1085 invoked from network); 13 Feb 2013 19:39:47 -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;
	13 Feb 2013 19:39:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7390499"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 19:39:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 14:39:24 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5iAu-0006RZ-T0;
	Wed, 13 Feb 2013 19:39:24 +0000
Message-ID: <1360784364.16636.105.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Wed, 13 Feb 2013 19:39:24 +0000
In-Reply-To: <511BE780.9000707@cantab.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, 2013-02-13 at 19:20 +0000, David Vrabel wrote:
> On 13/02/13 18:37, Wei Liu wrote:
> > A slightly upgraded version of the *UNTESTED* patch.
> > 
> > 
> > Wei.
> > 
> > ----8<----
> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> > Author: Wei Liu <wei.liu2@citrix.com>
> > Date:   Wed Feb 13 18:17:01 2013 +0000
> > 
> >     netback: fix netbk_count_requests
> >     
> >     There are two paths in the original code, a) test against work_to_do, b) test
> >     against first->size, could return 0 even when error happens.
> >     
> >     Simply return -1 in error paths should work. Modify all error paths to return
> >     -1 to be consistent.
> 
> You also need to remove the netbk_tx_err() after checking the result of
> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
> which will screw up ref counting.
> 

Yes I saw that as well. I was suspecting it was done on purpose. I
didn't write this patch anyway. I thought that Ian at least smoke-tested
it with creation / teardown vif so I just left it like that.

> I would also suggest returning -EINVAL from netbk_count_requests().
> It not clear to me how this will fix the original oops though.
> 

My analysis:

netbk_count_requests returns 0 when an error occurs in the first
iteration (frag = 0, -frag = 0), the caller gets 0 and doesn't notice
this vif has been disconnected. The subsequent call comparison
txreq.size < ETH_HLEN is true for some reason - frontend messes up the
txreq (this could also be the same reason that netbk_count_requests
fails in first iteration), and a subsequent call to netbk_tx_err
triggers the bug.


Wei.

> David
> 
> >     
> >     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 103294d..0e0162e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (frags >= work_to_do) {
> >  			netdev_err(vif->dev, "Need more frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
> >  			netdev_err(vif->dev, "Too many frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> > @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (txp->size > first->size) {
> >  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		first->size -= txp->size;
> > @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
> >  				 txp->offset, txp->size);
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> >  	return frags;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Feb 13 19:44:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 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 1U5iFI-0000Fe-5L; Wed, 13 Feb 2013 19:43: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 1U5iFG-0000FY-NX
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 19:43:54 +0000
Received: from [85.158.139.83:41901] by server-7.bemta-5.messagelabs.com id
	3B/6F-11121-9FCEB115; Wed, 13 Feb 2013 19:43:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360784631!26981481!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1623 invoked from network); 13 Feb 2013 19:43:53 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 19:43:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DJhmIO015255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 19:43:49 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
	r1DJhl0h001801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 19:43:48 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
	r1DJhltW028466; Wed, 13 Feb 2013 13:43:47 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 11:43:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 769D01BF781; Wed, 13 Feb 2013 14:43:46 -0500 (EST)
Date: Wed, 13 Feb 2013 14:43:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130213194346.GA23146@phenom.dumpdata.com>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130213185826.GA25891@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213185826.GA25891@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, 2013 at 07:58:26PM +0100, Olaf Hering wrote:
> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:
> 
> > Any thoughts of what might be wrong?
> 
> Do you have a xenctx output when it hangs?

> /usr/lib64/xen/bin/xenctx -s System.map -a 5 0
cs:eip: 0060:c10730f5 native_safe_halt+0x5 
flags: 00000246 i z p
ss:esp: 0068:c171df8c
eax: 00000000   ebx: c176df70   ecx: 00000000   edx: 00000000
esi: 00000000   edi: 00000000   ebp: c171df8c
 ds:     007b    es:     007b    fs:     00d8    gs:     0000

cr0: 8005003b
cr2: 00000000
cr3: 00000000
cr4: b747f000

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: 00000000
dr7: 00000000
Code (instr addr c10730f5)
55 89 e5 fb 5d c3 8d 76 00 8d bc 27 00 00 00 00 55 89 e5 fb f4 <5d> c3 89 f6 8d bc 27 00 00 00 00 


Stack:
 c171dfa4 c1050101 00000096 c176df70 00000000 c1720800 c171dfb0 c104fab8
 c17bb3c0 c171dfb8 c157e3df c171dfd8 c1775b1d 000000f7 ffffffff ffffffff
 c1775663 c17bb3c0 7a54b000 c171dff8 c17752e6 05a94000 00000000 7ffdf000
 00000000 00200800 00033000 01d0d003 00000000

Call Trace:
  [<c10730f5>] native_safe_halt+0x5  <--
  [<c1050101>] default_idle+0x41 
  [<c104fab8>] cpu_idle+0x68 
  [<c157e3df>] rest_init+0x6f 
  [<c1775b1d>] start_kernel+0x32b 
  [<c1775663>] unknown_bootoption 
  [<c17752e6>] i386_start_kernel+0xa9 

> /usr/lib64/xen/bin/xenctx -s System.map -a 5 1
cs:eip: 0060:c1073dc8 pvclock_clocksource_read+0x18 
flags: 00000086 s nz p
ss:esp: 0068:f0c8de44
eax: 63dcc977   ebx: 00000001   ecx: 2f908000   edx: 00000077
esi: f0c6f030   edi: 00000742   ebp: f0c8de60
 ds:     007b    es:     007b    fs:     00d8    gs:     0000

cr0: 8005003b
cr2: 00000000
cr3: 00000000
cr4: b766ae24

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: 00000000
dr7: 00000000
Code (instr addr c1073dc8)
57 56 53 83 ec 10 8b 38 89 04 24 66 90 8d 76 00 0f ae e8 0f 31 <8b> 0c 24 89 44 24 08 8b 04 24 89 


Stack:
 f10fc120 2af6a2d6 000002a5 00000001 00000001 f0c6f030 00000002 f0c8de6c
 c103f2c5 00000001 f0c8de74 c104e218 f0c8deb8 c10b4f22 00000015 76f0981d
 0000000d fffffff2 ffffffff f11035d0 f11035d0 f11035c0 00000015 2d1b4a9b
 00000015 00000001 00000001 f0c6f030 00000002 f0c8df00 c10b5131 f10fe9a0

Call Trace:
  [<c1073dc8>] pvclock_clocksource_read+0x18  <--
  [<c103f2c5>] xen_clocksource_read+0x25 
  [<c104e218>] sched_clock+0x8 
  [<c10b4f22>] sched_clock_local+0xb2 
  [<c10b5131>] sched_clock_cpu+0x131 
  [<c103f2c5>] xen_clocksource_read+0x25 
  [<c103f488>] xen_clocksource_get_cycles+0x8 
  [<c10cb433>] ktime_get+0x43 
  [<c10b5901>] irqtime_account_irq+0x41 
  [<c108a77e>] irq_exit+0xe 
  [<c13316e0>] xen_evtchn_do_upcall+0x20 
  [<c1595ff9>] xen_hvm_callback_vector+0x2d 
  [<c10730f5>] native_safe_halt+0x5 
  [<c1050101>] default_idle+0x41 
  [<c104fab8>] cpu_idle+0x68 
  [<c1588bd7>] start_secondary+0x19f 


And then if I time it just right I can see on the VCPU1 sometimes:

> /usr/lib64/xen/bin/xenctx -s System.map -a 5 1
cs:eip: 0060:c10b4ef5 sched_clock_local+0x85 
flags: 00000002 nz
ss:esp: 0068:f0c8de7c
eax: 2d1b4a9b   ebx: 2d1b4a9b   ecx: 00000015   edx: 00000015
esi: 2d1b4a9b   edi: 00000015   ebp: f0c8deb8
 ds:     007b    es:     007b    fs:     00d8    gs:     0000

cr0: 8005003b
cr2: 00000000
cr3: 00000000
cr4: b766ae24

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: 00000000
dr7: 00000000
Code (instr addr c10b4ef5)
0c 24 89 5c 24 04 8b 74 24 20 8b 7c 24 24 8b 1c 24 8b 4c 24 04 <89> 74 24 28 89 f0 8b 74 24 18 89 


Stack:
 2d1b4a9b 00000015 feb559f0 00000026 ffffffd9 ffffffff f11035d0 f11035c0
 2d1b4a9b 00000015 ffffffff ffffffff 00000001 f0c6f030 00000002 f0c8df00
 c10b5131 f10fe9a0 f0c8ded0 c103f2c5 c176ce80 f0c8ded8 c103f488 f0c8df00
 c10cb433 f11035c0 f11035c0 00000046 f10fc100 f10fc104 00000001 f0c6f030

Call Trace:
  [<c10b4ef5>] sched_clock_local+0x85  <--
  [<c10b5131>] sched_clock_cpu+0x131 
  [<c103f2c5>] xen_clocksource_read+0x25 
  [<c103f488>] xen_clocksource_get_cycles+0x8 
  [<c10cb433>] ktime_get+0x43 
  [<c10b5901>] irqtime_account_irq+0x41 
  [<c108a77e>] irq_exit+0xe 
  [<c13316e0>] xen_evtchn_do_upcall+0x20 
  [<c1595ff9>] xen_hvm_callback_vector+0x2d 
  [<c10730f5>] native_safe_halt+0x5 
  [<c1050101>] default_idle+0x41 
  [<c104fab8>] cpu_idle+0x68 
  [<c1588bd7>] start_secondary+0x19f 

So the VCPU1 is looping around trying to read the pvclock. Presumarily
the info is full of zeros.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 19:44:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 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 1U5iFI-0000Fe-5L; Wed, 13 Feb 2013 19:43: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 1U5iFG-0000FY-NX
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 19:43:54 +0000
Received: from [85.158.139.83:41901] by server-7.bemta-5.messagelabs.com id
	3B/6F-11121-9FCEB115; Wed, 13 Feb 2013 19:43:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360784631!26981481!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1623 invoked from network); 13 Feb 2013 19:43:53 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 19:43:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DJhmIO015255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 19:43:49 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
	r1DJhl0h001801
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 19:43:48 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
	r1DJhltW028466; Wed, 13 Feb 2013 13:43:47 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 11:43:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 769D01BF781; Wed, 13 Feb 2013 14:43:46 -0500 (EST)
Date: Wed, 13 Feb 2013 14:43:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130213194346.GA23146@phenom.dumpdata.com>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130213185826.GA25891@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213185826.GA25891@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, 2013 at 07:58:26PM +0100, Olaf Hering wrote:
> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:
> 
> > Any thoughts of what might be wrong?
> 
> Do you have a xenctx output when it hangs?

> /usr/lib64/xen/bin/xenctx -s System.map -a 5 0
cs:eip: 0060:c10730f5 native_safe_halt+0x5 
flags: 00000246 i z p
ss:esp: 0068:c171df8c
eax: 00000000   ebx: c176df70   ecx: 00000000   edx: 00000000
esi: 00000000   edi: 00000000   ebp: c171df8c
 ds:     007b    es:     007b    fs:     00d8    gs:     0000

cr0: 8005003b
cr2: 00000000
cr3: 00000000
cr4: b747f000

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: 00000000
dr7: 00000000
Code (instr addr c10730f5)
55 89 e5 fb 5d c3 8d 76 00 8d bc 27 00 00 00 00 55 89 e5 fb f4 <5d> c3 89 f6 8d bc 27 00 00 00 00 


Stack:
 c171dfa4 c1050101 00000096 c176df70 00000000 c1720800 c171dfb0 c104fab8
 c17bb3c0 c171dfb8 c157e3df c171dfd8 c1775b1d 000000f7 ffffffff ffffffff
 c1775663 c17bb3c0 7a54b000 c171dff8 c17752e6 05a94000 00000000 7ffdf000
 00000000 00200800 00033000 01d0d003 00000000

Call Trace:
  [<c10730f5>] native_safe_halt+0x5  <--
  [<c1050101>] default_idle+0x41 
  [<c104fab8>] cpu_idle+0x68 
  [<c157e3df>] rest_init+0x6f 
  [<c1775b1d>] start_kernel+0x32b 
  [<c1775663>] unknown_bootoption 
  [<c17752e6>] i386_start_kernel+0xa9 

> /usr/lib64/xen/bin/xenctx -s System.map -a 5 1
cs:eip: 0060:c1073dc8 pvclock_clocksource_read+0x18 
flags: 00000086 s nz p
ss:esp: 0068:f0c8de44
eax: 63dcc977   ebx: 00000001   ecx: 2f908000   edx: 00000077
esi: f0c6f030   edi: 00000742   ebp: f0c8de60
 ds:     007b    es:     007b    fs:     00d8    gs:     0000

cr0: 8005003b
cr2: 00000000
cr3: 00000000
cr4: b766ae24

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: 00000000
dr7: 00000000
Code (instr addr c1073dc8)
57 56 53 83 ec 10 8b 38 89 04 24 66 90 8d 76 00 0f ae e8 0f 31 <8b> 0c 24 89 44 24 08 8b 04 24 89 


Stack:
 f10fc120 2af6a2d6 000002a5 00000001 00000001 f0c6f030 00000002 f0c8de6c
 c103f2c5 00000001 f0c8de74 c104e218 f0c8deb8 c10b4f22 00000015 76f0981d
 0000000d fffffff2 ffffffff f11035d0 f11035d0 f11035c0 00000015 2d1b4a9b
 00000015 00000001 00000001 f0c6f030 00000002 f0c8df00 c10b5131 f10fe9a0

Call Trace:
  [<c1073dc8>] pvclock_clocksource_read+0x18  <--
  [<c103f2c5>] xen_clocksource_read+0x25 
  [<c104e218>] sched_clock+0x8 
  [<c10b4f22>] sched_clock_local+0xb2 
  [<c10b5131>] sched_clock_cpu+0x131 
  [<c103f2c5>] xen_clocksource_read+0x25 
  [<c103f488>] xen_clocksource_get_cycles+0x8 
  [<c10cb433>] ktime_get+0x43 
  [<c10b5901>] irqtime_account_irq+0x41 
  [<c108a77e>] irq_exit+0xe 
  [<c13316e0>] xen_evtchn_do_upcall+0x20 
  [<c1595ff9>] xen_hvm_callback_vector+0x2d 
  [<c10730f5>] native_safe_halt+0x5 
  [<c1050101>] default_idle+0x41 
  [<c104fab8>] cpu_idle+0x68 
  [<c1588bd7>] start_secondary+0x19f 


And then if I time it just right I can see on the VCPU1 sometimes:

> /usr/lib64/xen/bin/xenctx -s System.map -a 5 1
cs:eip: 0060:c10b4ef5 sched_clock_local+0x85 
flags: 00000002 nz
ss:esp: 0068:f0c8de7c
eax: 2d1b4a9b   ebx: 2d1b4a9b   ecx: 00000015   edx: 00000015
esi: 2d1b4a9b   edi: 00000015   ebp: f0c8deb8
 ds:     007b    es:     007b    fs:     00d8    gs:     0000

cr0: 8005003b
cr2: 00000000
cr3: 00000000
cr4: b766ae24

dr0: 00000000
dr1: 00000000
dr2: 00000000
dr3: 00000000
dr6: 00000000
dr7: 00000000
Code (instr addr c10b4ef5)
0c 24 89 5c 24 04 8b 74 24 20 8b 7c 24 24 8b 1c 24 8b 4c 24 04 <89> 74 24 28 89 f0 8b 74 24 18 89 


Stack:
 2d1b4a9b 00000015 feb559f0 00000026 ffffffd9 ffffffff f11035d0 f11035c0
 2d1b4a9b 00000015 ffffffff ffffffff 00000001 f0c6f030 00000002 f0c8df00
 c10b5131 f10fe9a0 f0c8ded0 c103f2c5 c176ce80 f0c8ded8 c103f488 f0c8df00
 c10cb433 f11035c0 f11035c0 00000046 f10fc100 f10fc104 00000001 f0c6f030

Call Trace:
  [<c10b4ef5>] sched_clock_local+0x85  <--
  [<c10b5131>] sched_clock_cpu+0x131 
  [<c103f2c5>] xen_clocksource_read+0x25 
  [<c103f488>] xen_clocksource_get_cycles+0x8 
  [<c10cb433>] ktime_get+0x43 
  [<c10b5901>] irqtime_account_irq+0x41 
  [<c108a77e>] irq_exit+0xe 
  [<c13316e0>] xen_evtchn_do_upcall+0x20 
  [<c1595ff9>] xen_hvm_callback_vector+0x2d 
  [<c10730f5>] native_safe_halt+0x5 
  [<c1050101>] default_idle+0x41 
  [<c104fab8>] cpu_idle+0x68 
  [<c1588bd7>] start_secondary+0x19f 

So the VCPU1 is looping around trying to read the pvclock. Presumarily
the info is full of zeros.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:13:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20:13: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 1U5ihK-0000dA-Lo; Wed, 13 Feb 2013 20:12:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U5ihI-0000d5-SM
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:12:53 +0000
Received: from [85.158.137.99:65462] by server-4.bemta-3.messagelabs.com id
	BA/4F-12802-FB3FB115; Wed, 13 Feb 2013 20:12:47 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360786365!17916375!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11264 invoked from network); 13 Feb 2013 20:12:46 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-14.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 20:12:46 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1DKCiZA021026;
	Wed, 13 Feb 2013 15:12:44 -0500
Message-ID: <511BF3BC.2020800@theshore.net>
Date: Wed, 13 Feb 2013 15:12:44 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360759637.16636.85.camel@zion.uk.xensource.com>
In-Reply-To: <1360759637.16636.85.camel@zion.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/13/13 7:47 AM, Wei Liu wrote:
> On Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
>> On 2/12/13 4:58 AM, Ian Campbell wrote:
>>> Have you applied the XSA-39 fixes to this kernel?
>>
>> Yes!  When I rebuilt with Wei's suggested patch for my original
>> netback/xenwatch problem I also brought us up to date with XSA patches.
> Good to have more context.

We have found a way to reproduce a very similar BUG by keeping a guest's 
network IO busy and then from the host "ifconfig down" the vif.  It 
results in the following dump.  This only works if the guest is doing 
network I/O.

We can reproduce regardless if dom0 is patched with XSA-39, and is 
trigger-able at least as far back as 3.2.6 dom0.

Procedure:

Launch a guest and configure iperf [in TCP mode] between it and another 
box on the network then bring down its vif on the host.

root@dom0:~# ifconfig vif14.0 down <-- insta-boom
br0: port 3(vif14.0) entered disabled state
unable to handle kernel NULL pointer dereference at 00000000000008b8
IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set xt_physdev iptable_filter ip_tables ebtable_nat 
xen_gntdev bonding ebtable_filter igb
CPU 1
Pid: 0, comm: swapper/1 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F
RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
xen_spin_lock_flags+0x3a/0x80
RSP: e02b:ffff880141843d60  EFLAGS: 00010006
RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 0000000000012739
RDX: 0000000000000001 RSI: 0000000000000222 RDI: 00000000000008b8
RBP: ffff880141843d80 R08: 0000000000000144 R09: 0000000000000003
R10: 0000000000000003 R11: dead000000200200 R12: 0000000000000001
R13: 0000000000000200 R14: 0000000000000400 R15: ffff8800216ba700
FS:  00007f03fa88a700(0000) GS:ffff880141840000(0000) 
knlGS:0000000000000000
CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/1 (pid: 0, threadinfo ffff880101138000, task 
ffff8801011049c0)
Stack:
  0000000000000222 00000000000008b8 ffff8800216ba700 ffff8800216ba7d8
  ffff880141843da0 ffffffff817605da 0000000000000000 00000000000008b8
  ffff880141843de0 ffffffff8154446f ffff88014184e5b8 ffff88014184e578
Call Trace:
  <IRQ>
  [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
  [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
  [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
  [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
  [<ffffffff81544589>] tx_credit_callback+0x49/0x50
  [<ffffffff8105ee04>] call_timer_fn+0x44/0x120
  [<ffffffff8105f411>] run_timer_softirq+0x241/0x2b0
  [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
  [<ffffffff8105731f>] __do_softirq+0xcf/0x250
  [<ffffffff810c1253>] ? handle_percpu_irq+0x43/0x60
  [<ffffffff8176971c>] call_softirq+0x1c/0x30
  [<ffffffff81015425>] do_softirq+0x65/0xa0
  [<ffffffff8105710d>] irq_exit+0xbd/0xe0
  [<ffffffff8141a73f>] xen_evtchn_do_upcall+0x2f/0x40
  [<ffffffff8176977e>] xen_do_hypervisor_callback+0x1e/0x30
  <EOI>
  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
  [<ffffffff81009ae0>] ? xen_safe_halt+0x10/0x20
  [<ffffffff8101c168>] ? default_idle+0x58/0x1b0
  [<ffffffff8101b8a8>] ? cpu_idle+0x88/0xd0
  [<ffffffff817541de>] ? cpu_bringup_and_idle+0xe/0x10
Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 
02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 
84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
  RSP <ffff880141843d60>
CR2: 00000000000008b8
---[ end trace 337eb85a44e2f0ef ]---
Kernel panic - not syncing: Fatal exception in interrupt
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:13:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20:13: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 1U5ihK-0000dA-Lo; Wed, 13 Feb 2013 20:12:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U5ihI-0000d5-SM
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:12:53 +0000
Received: from [85.158.137.99:65462] by server-4.bemta-3.messagelabs.com id
	BA/4F-12802-FB3FB115; Wed, 13 Feb 2013 20:12:47 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360786365!17916375!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11264 invoked from network); 13 Feb 2013 20:12:46 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-14.tower-217.messagelabs.com with SMTP;
	13 Feb 2013 20:12:46 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1DKCiZA021026;
	Wed, 13 Feb 2013 15:12:44 -0500
Message-ID: <511BF3BC.2020800@theshore.net>
Date: Wed, 13 Feb 2013 15:12:44 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360759637.16636.85.camel@zion.uk.xensource.com>
In-Reply-To: <1360759637.16636.85.camel@zion.uk.xensource.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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-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 2/13/13 7:47 AM, Wei Liu wrote:
> On Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
>> On 2/12/13 4:58 AM, Ian Campbell wrote:
>>> Have you applied the XSA-39 fixes to this kernel?
>>
>> Yes!  When I rebuilt with Wei's suggested patch for my original
>> netback/xenwatch problem I also brought us up to date with XSA patches.
> Good to have more context.

We have found a way to reproduce a very similar BUG by keeping a guest's 
network IO busy and then from the host "ifconfig down" the vif.  It 
results in the following dump.  This only works if the guest is doing 
network I/O.

We can reproduce regardless if dom0 is patched with XSA-39, and is 
trigger-able at least as far back as 3.2.6 dom0.

Procedure:

Launch a guest and configure iperf [in TCP mode] between it and another 
box on the network then bring down its vif on the host.

root@dom0:~# ifconfig vif14.0 down <-- insta-boom
br0: port 3(vif14.0) entered disabled state
unable to handle kernel NULL pointer dereference at 00000000000008b8
IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
ip_set_hash_net ip_set xt_physdev iptable_filter ip_tables ebtable_nat 
xen_gntdev bonding ebtable_filter igb
CPU 1
Pid: 0, comm: swapper/1 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F
RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
xen_spin_lock_flags+0x3a/0x80
RSP: e02b:ffff880141843d60  EFLAGS: 00010006
RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 0000000000012739
RDX: 0000000000000001 RSI: 0000000000000222 RDI: 00000000000008b8
RBP: ffff880141843d80 R08: 0000000000000144 R09: 0000000000000003
R10: 0000000000000003 R11: dead000000200200 R12: 0000000000000001
R13: 0000000000000200 R14: 0000000000000400 R15: ffff8800216ba700
FS:  00007f03fa88a700(0000) GS:ffff880141840000(0000) 
knlGS:0000000000000000
CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/1 (pid: 0, threadinfo ffff880101138000, task 
ffff8801011049c0)
Stack:
  0000000000000222 00000000000008b8 ffff8800216ba700 ffff8800216ba7d8
  ffff880141843da0 ffffffff817605da 0000000000000000 00000000000008b8
  ffff880141843de0 ffffffff8154446f ffff88014184e5b8 ffff88014184e578
Call Trace:
  <IRQ>
  [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
  [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
  [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
  [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
  [<ffffffff81544589>] tx_credit_callback+0x49/0x50
  [<ffffffff8105ee04>] call_timer_fn+0x44/0x120
  [<ffffffff8105f411>] run_timer_softirq+0x241/0x2b0
  [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
  [<ffffffff8105731f>] __do_softirq+0xcf/0x250
  [<ffffffff810c1253>] ? handle_percpu_irq+0x43/0x60
  [<ffffffff8176971c>] call_softirq+0x1c/0x30
  [<ffffffff81015425>] do_softirq+0x65/0xa0
  [<ffffffff8105710d>] irq_exit+0xbd/0xe0
  [<ffffffff8141a73f>] xen_evtchn_do_upcall+0x2f/0x40
  [<ffffffff8176977e>] xen_do_hypervisor_callback+0x1e/0x30
  <EOI>
  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
  [<ffffffff81009ae0>] ? xen_safe_halt+0x10/0x20
  [<ffffffff8101c168>] ? default_idle+0x58/0x1b0
  [<ffffffff8101b8a8>] ? cpu_idle+0x88/0xd0
  [<ffffffff817541de>] ? cpu_bringup_and_idle+0xe/0x10
Code: 24 08 4c 89 6c 24 10 4c 89 74 24 18 49 89 f5 48 89 fb 41 81 e5 00 
02 00 00 41 bc 01 00 00 00 41 be 00 04 00 00 44 89 f0 44 89 e2 <86> 13 
84 d2 74 0b f3 90 80 3b 00 74 f3 ff c8 75 f5 84 d2 75 15
RIP  [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
  RSP <ffff880141843d60>
CR2: 00000000000008b8
---[ end trace 337eb85a44e2f0ef ]---
Kernel panic - not syncing: Fatal exception in interrupt
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:17:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20:17: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 1U5iln-0000mD-HK; Wed, 13 Feb 2013 20:17:31 +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 1U5ilm-0000m5-C9
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:17:30 +0000
Received: from [85.158.139.211:62510] by server-10.bemta-5.messagelabs.com id
	BC/61-04697-8D4FB115; Wed, 13 Feb 2013 20:17:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360786646!22373081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17535 invoked from network); 13 Feb 2013 20:17:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 20:17:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7029747"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 20:17:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 15:17:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5ilh-0006za-6Z;
	Wed, 13 Feb 2013 20:17:25 +0000
Date: Wed, 13 Feb 2013 20:17:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20130213201725.GA1453@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511BE780.9000707@cantab.net>
Thread-Topic: [Xen-devel] netback Oops then xenwatch stuck in D state
Accept-Language: en-US
Content-Language: en-US
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
> On 13/02/13 18:37, Wei Liu wrote:
> > A slightly upgraded version of the *UNTESTED* patch.
> > 
> > 
> > Wei.
> > 
> > ----8<----
> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> > Author: Wei Liu <wei.liu2@citrix.com>
> > Date:   Wed Feb 13 18:17:01 2013 +0000
> > 
> >     netback: fix netbk_count_requests
> >     
> >     There are two paths in the original code, a) test against work_to_do, b) test
> >     against first->size, could return 0 even when error happens.
> >     
> >     Simply return -1 in error paths should work. Modify all error paths to return
> >     -1 to be consistent.
> 
> You also need to remove the netbk_tx_err() after checking the result of
> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
> which will screw up ref counting.

I just realized that we were talking about different code path when I
walked home.

The path you mentioned is correct. As excution flow should never reach
there if there is error in netbk_count_requests.

The path I'm not sure is that in the netbk_fatal_tx_err, it calls
xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
which is likely to mess up the refcount.


Wei.

> 
> I would also suggest returning -EINVAL from netbk_count_requests().
> 
> It not clear to me how this will fix the original oops though.
> 
> David
> 
> >     
> >     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 103294d..0e0162e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (frags >= work_to_do) {
> >  			netdev_err(vif->dev, "Need more frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
> >  			netdev_err(vif->dev, "Too many frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> > @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (txp->size > first->size) {
> >  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		first->size -= txp->size;
> > @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
> >  				 txp->offset, txp->size);
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> >  	return frags;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Feb 13 20:17:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20:17: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 1U5iln-0000mD-HK; Wed, 13 Feb 2013 20:17:31 +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 1U5ilm-0000m5-C9
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:17:30 +0000
Received: from [85.158.139.211:62510] by server-10.bemta-5.messagelabs.com id
	BC/61-04697-8D4FB115; Wed, 13 Feb 2013 20:17:28 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360786646!22373081!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17535 invoked from network); 13 Feb 2013 20:17:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 20:17:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7029747"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 20:17:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 15:17:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5ilh-0006za-6Z;
	Wed, 13 Feb 2013 20:17:25 +0000
Date: Wed, 13 Feb 2013 20:17:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20130213201725.GA1453@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511BE780.9000707@cantab.net>
Thread-Topic: [Xen-devel] netback Oops then xenwatch stuck in D state
Accept-Language: en-US
Content-Language: en-US
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
> On 13/02/13 18:37, Wei Liu wrote:
> > A slightly upgraded version of the *UNTESTED* patch.
> > 
> > 
> > Wei.
> > 
> > ----8<----
> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> > Author: Wei Liu <wei.liu2@citrix.com>
> > Date:   Wed Feb 13 18:17:01 2013 +0000
> > 
> >     netback: fix netbk_count_requests
> >     
> >     There are two paths in the original code, a) test against work_to_do, b) test
> >     against first->size, could return 0 even when error happens.
> >     
> >     Simply return -1 in error paths should work. Modify all error paths to return
> >     -1 to be consistent.
> 
> You also need to remove the netbk_tx_err() after checking the result of
> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
> which will screw up ref counting.

I just realized that we were talking about different code path when I
walked home.

The path you mentioned is correct. As excution flow should never reach
there if there is error in netbk_count_requests.

The path I'm not sure is that in the netbk_fatal_tx_err, it calls
xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
which is likely to mess up the refcount.


Wei.

> 
> I would also suggest returning -EINVAL from netbk_count_requests().
> 
> It not clear to me how this will fix the original oops though.
> 
> David
> 
> >     
> >     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 103294d..0e0162e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (frags >= work_to_do) {
> >  			netdev_err(vif->dev, "Need more frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
> >  			netdev_err(vif->dev, "Too many frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> > @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (txp->size > first->size) {
> >  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		first->size -= txp->size;
> > @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
> >  				 txp->offset, txp->size);
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> >  	return frags;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Feb 13 20:20:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20:20: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 1U5io3-0000tF-42; Wed, 13 Feb 2013 20:19:51 +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 1U5io1-0000t7-AP
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:19:49 +0000
Received: from [85.158.143.99:40209] by server-1.bemta-4.messagelabs.com id
	FC/AE-08839-465FB115; Wed, 13 Feb 2013 20:19:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360786786!27084540!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18237 invoked from network); 13 Feb 2013 20:19:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 20:19:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DKJhJY023978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 20:19:44 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
	r1DKJhoA007973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 20:19:43 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
	r1DKJhYo021935; Wed, 13 Feb 2013 14:19:43 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 12:19:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 066C31BF781; Wed, 13 Feb 2013 15:19:42 -0500 (EST)
Date: Wed, 13 Feb 2013 15:19:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130213201941.GA21909@phenom.dumpdata.com>
References: <1360599058-1567-1-git-send-email-roger.pau@citrix.com>
	<20130213173312.GA20866@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213173312.GA20866@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: drop the use of
	llist_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 Wed, Feb 13, 2013 at 12:33:12PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 11, 2013 at 05:10:58PM +0100, Roger Pau Monne wrote:
> > Replace llist_for_each_entry_safe with a while loop and
> > llist_del_first.
> > 
> > llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
> > to remove it and use a while loop and llist_del_first (which is
> > already in llist.h).
> 
> I spruced this up a bit:

And then I re-tested it once more and it did _not_ fix the problem. But this
did fix it:

>From 5f9c7b8388af474f3692cd78fade6d047981dcde Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 13 Feb 2013 13:01:55 -0500
Subject: [PATCH] xen-blkfront: drop the use of llist_for_each_entry_safe

Replace llist_for_each_entry_safe with a while loop.

llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
to remove it and use a while loop and do the deletion manually.

Specifically this bug can be triggered by hot-unplugging a disk, either
by doing xm block-detach or by save/restore cycle.

BUG: unable to handle kernel paging request at fffffffffffffff0
IP: [<ffffffffa0047223>] blkif_free+0x63/0x130 [xen_blkfront]
The crash call trace is:
	...
bad_area_nosemaphore+0x13/0x20
do_page_fault+0x25e/0x4b0
page_fault+0x25/0x30
? blkif_free+0x63/0x130 [xen_blkfront]
blkfront_resume+0x46/0xa0 [xen_blkfront]
xenbus_dev_resume+0x6c/0x140
pm_op+0x192/0x1b0
device_resume+0x82/0x1e0
dpm_resume+0xc9/0x1a0
dpm_resume_end+0x15/0x30
do_suspend+0x117/0x1e0

When drilling down to the assembler code, on newer GCC it does
.L29:
        cmpq    $-16, %r12      #, persistent_gnt check
        je      .L30    	#, out of the loop
.L25:
	... code in the loop
        testq   %r13, %r13      # n
        je      .L29    	#, back to the top of the loop
        cmpq    $-16, %r12      #, persistent_gnt check
        movq    16(%r12), %r13  # <variable>.node.next, n
        jne     .L25    	#,	back to the top of the loop
.L30:

While on GCC 4.1, it is:
L78:
	... code in the loop
	testq   %r13, %r13      # n
        je      .L78    #,	back to the top of the loop
        movq    16(%rbx), %r13  # <variable>.node.next, n
        jmp     .L78    #,	back to the top of the loop

Which basically means that the exit loop condition instead of
being:

	&(pos)->member != NULL;

is:
	;

which makes the loop unbound.

Since xen-blkfront is the only user of the llist_for_each_entry_safe
macro remove it from llist.h.

Orabug: 16263164
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c | 13 ++++++++++---
 include/linux/llist.h        | 25 -------------------------
 2 files changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 11043c1..c3dae2e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -791,7 +791,7 @@ static void blkif_restart_queue(struct work_struct *work)
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
 	struct llist_node *all_gnts;
-	struct grant *persistent_gnt;
+	struct grant *persistent_gnt, *tmp;
 	struct llist_node *n;
 
 	/* Prevent new requests being issued until we fix things up. */
@@ -805,10 +805,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* Remove all persistent grants */
 	if (info->persistent_gnts_c) {
 		all_gnts = llist_del_all(&info->persistent_gnts);
-		llist_for_each_entry_safe(persistent_gnt, n, all_gnts, node) {
+		persistent_gnt = llist_entry(all_gnts, typeof(*(persistent_gnt)), node);
+		while (persistent_gnt) {
 			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
 			__free_page(pfn_to_page(persistent_gnt->pfn));
-			kfree(persistent_gnt);
+			tmp = persistent_gnt;
+			n = persistent_gnt->node.next;
+			if (n)
+				persistent_gnt = llist_entry(n, typeof(*(persistent_gnt)), node);
+			else
+				persistent_gnt = NULL;
+			kfree(tmp);
 		}
 		info->persistent_gnts_c = 0;
 	}
diff --git a/include/linux/llist.h b/include/linux/llist.h
index d0ab98f..a5199f6 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -125,31 +125,6 @@ static inline void init_llist_head(struct llist_head *list)
 	     (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
- * llist_for_each_entry_safe - iterate safely against remove over some entries
- * of lock-less list of given type.
- * @pos:	the type * to use as a loop cursor.
- * @n:		another type * to use as a temporary storage.
- * @node:	the fist entry of deleted list entries.
- * @member:	the name of the llist_node with the struct.
- *
- * In general, some entries of the lock-less list can be traversed
- * safely only after being removed from list, so start with an entry
- * instead of list head. This variant allows removal of entries
- * as we iterate.
- *
- * If being used on entries deleted from lock-less list directly, the
- * traverse order is from the newest to the oldest added entry.  If
- * you want to traverse from the oldest to the newest, you must
- * reverse the order by yourself before traversing.
- */
-#define llist_for_each_entry_safe(pos, n, node, member)		\
-	for ((pos) = llist_entry((node), typeof(*(pos)), member),	\
-	     (n) = (pos)->member.next;					\
-	     &(pos)->member != NULL;					\
-	     (pos) = llist_entry(n, typeof(*(pos)), member),		\
-	     (n) = (&(pos)->member != NULL) ? (pos)->member.next : NULL)
-
-/**
  * llist_empty - tests whether a lock-less list is empty
  * @head:	the list to test
  *
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:20:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20:20: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 1U5io3-0000tF-42; Wed, 13 Feb 2013 20:19:51 +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 1U5io1-0000t7-AP
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:19:49 +0000
Received: from [85.158.143.99:40209] by server-1.bemta-4.messagelabs.com id
	FC/AE-08839-465FB115; Wed, 13 Feb 2013 20:19:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360786786!27084540!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18237 invoked from network); 13 Feb 2013 20:19:48 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 20:19:48 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DKJhJY023978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 20:19:44 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
	r1DKJhoA007973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 20:19:43 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
	r1DKJhYo021935; Wed, 13 Feb 2013 14:19:43 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 12:19:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 066C31BF781; Wed, 13 Feb 2013 15:19:42 -0500 (EST)
Date: Wed, 13 Feb 2013 15:19:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130213201941.GA21909@phenom.dumpdata.com>
References: <1360599058-1567-1-git-send-email-roger.pau@citrix.com>
	<20130213173312.GA20866@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213173312.GA20866@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: drop the use of
	llist_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 Wed, Feb 13, 2013 at 12:33:12PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 11, 2013 at 05:10:58PM +0100, Roger Pau Monne wrote:
> > Replace llist_for_each_entry_safe with a while loop and
> > llist_del_first.
> > 
> > llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
> > to remove it and use a while loop and llist_del_first (which is
> > already in llist.h).
> 
> I spruced this up a bit:

And then I re-tested it once more and it did _not_ fix the problem. But this
did fix it:

>From 5f9c7b8388af474f3692cd78fade6d047981dcde Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 13 Feb 2013 13:01:55 -0500
Subject: [PATCH] xen-blkfront: drop the use of llist_for_each_entry_safe

Replace llist_for_each_entry_safe with a while loop.

llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
to remove it and use a while loop and do the deletion manually.

Specifically this bug can be triggered by hot-unplugging a disk, either
by doing xm block-detach or by save/restore cycle.

BUG: unable to handle kernel paging request at fffffffffffffff0
IP: [<ffffffffa0047223>] blkif_free+0x63/0x130 [xen_blkfront]
The crash call trace is:
	...
bad_area_nosemaphore+0x13/0x20
do_page_fault+0x25e/0x4b0
page_fault+0x25/0x30
? blkif_free+0x63/0x130 [xen_blkfront]
blkfront_resume+0x46/0xa0 [xen_blkfront]
xenbus_dev_resume+0x6c/0x140
pm_op+0x192/0x1b0
device_resume+0x82/0x1e0
dpm_resume+0xc9/0x1a0
dpm_resume_end+0x15/0x30
do_suspend+0x117/0x1e0

When drilling down to the assembler code, on newer GCC it does
.L29:
        cmpq    $-16, %r12      #, persistent_gnt check
        je      .L30    	#, out of the loop
.L25:
	... code in the loop
        testq   %r13, %r13      # n
        je      .L29    	#, back to the top of the loop
        cmpq    $-16, %r12      #, persistent_gnt check
        movq    16(%r12), %r13  # <variable>.node.next, n
        jne     .L25    	#,	back to the top of the loop
.L30:

While on GCC 4.1, it is:
L78:
	... code in the loop
	testq   %r13, %r13      # n
        je      .L78    #,	back to the top of the loop
        movq    16(%rbx), %r13  # <variable>.node.next, n
        jmp     .L78    #,	back to the top of the loop

Which basically means that the exit loop condition instead of
being:

	&(pos)->member != NULL;

is:
	;

which makes the loop unbound.

Since xen-blkfront is the only user of the llist_for_each_entry_safe
macro remove it from llist.h.

Orabug: 16263164
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkfront.c | 13 ++++++++++---
 include/linux/llist.h        | 25 -------------------------
 2 files changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 11043c1..c3dae2e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -791,7 +791,7 @@ static void blkif_restart_queue(struct work_struct *work)
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
 	struct llist_node *all_gnts;
-	struct grant *persistent_gnt;
+	struct grant *persistent_gnt, *tmp;
 	struct llist_node *n;
 
 	/* Prevent new requests being issued until we fix things up. */
@@ -805,10 +805,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* Remove all persistent grants */
 	if (info->persistent_gnts_c) {
 		all_gnts = llist_del_all(&info->persistent_gnts);
-		llist_for_each_entry_safe(persistent_gnt, n, all_gnts, node) {
+		persistent_gnt = llist_entry(all_gnts, typeof(*(persistent_gnt)), node);
+		while (persistent_gnt) {
 			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
 			__free_page(pfn_to_page(persistent_gnt->pfn));
-			kfree(persistent_gnt);
+			tmp = persistent_gnt;
+			n = persistent_gnt->node.next;
+			if (n)
+				persistent_gnt = llist_entry(n, typeof(*(persistent_gnt)), node);
+			else
+				persistent_gnt = NULL;
+			kfree(tmp);
 		}
 		info->persistent_gnts_c = 0;
 	}
diff --git a/include/linux/llist.h b/include/linux/llist.h
index d0ab98f..a5199f6 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -125,31 +125,6 @@ static inline void init_llist_head(struct llist_head *list)
 	     (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
- * llist_for_each_entry_safe - iterate safely against remove over some entries
- * of lock-less list of given type.
- * @pos:	the type * to use as a loop cursor.
- * @n:		another type * to use as a temporary storage.
- * @node:	the fist entry of deleted list entries.
- * @member:	the name of the llist_node with the struct.
- *
- * In general, some entries of the lock-less list can be traversed
- * safely only after being removed from list, so start with an entry
- * instead of list head. This variant allows removal of entries
- * as we iterate.
- *
- * If being used on entries deleted from lock-less list directly, the
- * traverse order is from the newest to the oldest added entry.  If
- * you want to traverse from the oldest to the newest, you must
- * reverse the order by yourself before traversing.
- */
-#define llist_for_each_entry_safe(pos, n, node, member)		\
-	for ((pos) = llist_entry((node), typeof(*(pos)), member),	\
-	     (n) = (pos)->member.next;					\
-	     &(pos)->member != NULL;					\
-	     (pos) = llist_entry(n, typeof(*(pos)), member),		\
-	     (n) = (&(pos)->member != NULL) ? (pos)->member.next : NULL)
-
-/**
  * llist_empty - tests whether a lock-less list is empty
  * @head:	the list to test
  *
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:30:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20: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 1U5ixZ-00018J-8E; Wed, 13 Feb 2013 20:29:41 +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 1U5ixX-00018E-H3
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:29:39 +0000
Received: from [193.109.254.147:26361] by server-6.bemta-14.messagelabs.com id
	D7/10-12010-2B7FB115; Wed, 13 Feb 2013 20:29:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360787375!3491098!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12203 invoked from network); 13 Feb 2013 20:29:37 -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;
	13 Feb 2013 20:29:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7031374"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 20:29:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 15:29:30 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5ixO-0007AW-OB;
	Wed, 13 Feb 2013 20:29:30 +0000
Date: Wed, 13 Feb 2013 20:29:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Message-ID: <20130213202930.GB1453@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360759637.16636.85.camel@zion.uk.xensource.com>
	<511BF3BC.2020800@theshore.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511BF3BC.2020800@theshore.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, Feb 13, 2013 at 08:12:44PM +0000, Christopher S. Aker wrote:
> On 2/13/13 7:47 AM, Wei Liu wrote:
> > On Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
> >> On 2/12/13 4:58 AM, Ian Campbell wrote:
> >>> Have you applied the XSA-39 fixes to this kernel?
> >>
> >> Yes!  When I rebuilt with Wei's suggested patch for my original
> >> netback/xenwatch problem I also brought us up to date with XSA patches.
> > Good to have more context.
> 
> We have found a way to reproduce a very similar BUG by keeping a guest's 
> network IO busy and then from the host "ifconfig down" the vif.  It 
> results in the following dump.  This only works if the guest is doing 
> network I/O.
> 
> We can reproduce regardless if dom0 is patched with XSA-39, and is 
> trigger-able at least as far back as 3.2.6 dom0.
> 
> Procedure:
> 
> Launch a guest and configure iperf [in TCP mode] between it and another 
> box on the network then bring down its vif on the host.
> 
> root@dom0:~# ifconfig vif14.0 down <-- insta-boom
> br0: port 3(vif14.0) entered disabled state
> unable to handle kernel NULL pointer dereference at 00000000000008b8
> IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> ip_set_hash_net ip_set xt_physdev iptable_filter ip_tables ebtable_nat 
> xen_gntdev bonding ebtable_filter igb
> CPU 1
> Pid: 0, comm: swapper/1 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
> X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F
> RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> RSP: e02b:ffff880141843d60  EFLAGS: 00010006
> RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 0000000000012739
> RDX: 0000000000000001 RSI: 0000000000000222 RDI: 00000000000008b8
> RBP: ffff880141843d80 R08: 0000000000000144 R09: 0000000000000003
> R10: 0000000000000003 R11: dead000000200200 R12: 0000000000000001
> R13: 0000000000000200 R14: 0000000000000400 R15: ffff8800216ba700
> FS:  00007f03fa88a700(0000) GS:ffff880141840000(0000) 
> knlGS:0000000000000000
> CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/1 (pid: 0, threadinfo ffff880101138000, task 
> ffff8801011049c0)
> Stack:
>   0000000000000222 00000000000008b8 ffff8800216ba700 ffff8800216ba7d8
>   ffff880141843da0 ffffffff817605da 0000000000000000 00000000000008b8
>   ffff880141843de0 ffffffff8154446f ffff88014184e5b8 ffff88014184e578
> Call Trace:
>   <IRQ>
>   [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
>   [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
>   [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
>   [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
>   [<ffffffff81544589>] tx_credit_callback+0x49/0x50
>   [<ffffffff8105ee04>] call_timer_fn+0x44/0x120
>   [<ffffffff8105f411>] run_timer_softirq+0x241/0x2b0
>   [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
>   [<ffffffff8105731f>] __do_softirq+0xcf/0x250
>   [<ffffffff810c1253>] ? handle_percpu_irq+0x43/0x60
>   [<ffffffff8176971c>] call_softirq+0x1c/0x30
>   [<ffffffff81015425>] do_softirq+0x65/0xa0
>   [<ffffffff8105710d>] irq_exit+0xbd/0xe0
>   [<ffffffff8141a73f>] xen_evtchn_do_upcall+0x2f/0x40
>   [<ffffffff8176977e>] xen_do_hypervisor_callback+0x1e/0x30

Notice the tracelog is different here, this looks like a vallina bug to
me. It is the timer callback that triggers the oops. This one should be
simple to fix - we should also shut down the timer when shutting down
vif.

Will get to this tomorrow. Need to have rest now. :-)


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:30:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20: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 1U5ixZ-00018J-8E; Wed, 13 Feb 2013 20:29:41 +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 1U5ixX-00018E-H3
	for xen-devel@lists.xen.org; Wed, 13 Feb 2013 20:29:39 +0000
Received: from [193.109.254.147:26361] by server-6.bemta-14.messagelabs.com id
	D7/10-12010-2B7FB115; Wed, 13 Feb 2013 20:29:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1360787375!3491098!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12203 invoked from network); 13 Feb 2013 20:29:37 -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;
	13 Feb 2013 20:29:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7031374"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 20:29:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 13 Feb 2013 15:29:30 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5ixO-0007AW-OB;
	Wed, 13 Feb 2013 20:29:30 +0000
Date: Wed, 13 Feb 2013 20:29:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Message-ID: <20130213202930.GB1453@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360759637.16636.85.camel@zion.uk.xensource.com>
	<511BF3BC.2020800@theshore.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511BF3BC.2020800@theshore.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Wed, Feb 13, 2013 at 08:12:44PM +0000, Christopher S. Aker wrote:
> On 2/13/13 7:47 AM, Wei Liu wrote:
> > On Wed, 2013-02-13 at 02:51 +0000, Christopher S. Aker wrote:
> >> On 2/12/13 4:58 AM, Ian Campbell wrote:
> >>> Have you applied the XSA-39 fixes to this kernel?
> >>
> >> Yes!  When I rebuilt with Wei's suggested patch for my original
> >> netback/xenwatch problem I also brought us up to date with XSA patches.
> > Good to have more context.
> 
> We have found a way to reproduce a very similar BUG by keeping a guest's 
> network IO busy and then from the host "ifconfig down" the vif.  It 
> results in the following dump.  This only works if the guest is doing 
> network I/O.
> 
> We can reproduce regardless if dom0 is patched with XSA-39, and is 
> trigger-able at least as far back as 3.2.6 dom0.
> 
> Procedure:
> 
> Launch a guest and configure iperf [in TCP mode] between it and another 
> box on the network then bring down its vif on the host.
> 
> root@dom0:~# ifconfig vif14.0 down <-- insta-boom
> br0: port 3(vif14.0) entered disabled state
> unable to handle kernel NULL pointer dereference at 00000000000008b8
> IP: [<ffffffff81011dda>] xen_spin_lock_flags+0x3a/0x80
> PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: ebt_comment ebt_arp ebt_set ebt_limit ebt_ip6 ebt_ip 
> ip_set_hash_net ip_set xt_physdev iptable_filter ip_tables ebtable_nat 
> xen_gntdev bonding ebtable_filter igb
> CPU 1
> Pid: 0, comm: swapper/1 Not tainted 3.7.6-1-x86_64 #1 Supermicro 
> X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F
> RIP: e030:[<ffffffff81011dda>]  [<ffffffff81011dda>] 
> xen_spin_lock_flags+0x3a/0x80
> RSP: e02b:ffff880141843d60  EFLAGS: 00010006
> RAX: 0000000000000400 RBX: 00000000000008b8 RCX: 0000000000012739
> RDX: 0000000000000001 RSI: 0000000000000222 RDI: 00000000000008b8
> RBP: ffff880141843d80 R08: 0000000000000144 R09: 0000000000000003
> R10: 0000000000000003 R11: dead000000200200 R12: 0000000000000001
> R13: 0000000000000200 R14: 0000000000000400 R15: ffff8800216ba700
> FS:  00007f03fa88a700(0000) GS:ffff880141840000(0000) 
> knlGS:0000000000000000
> CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: 00000000000008b8 CR3: 0000000001c0b000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/1 (pid: 0, threadinfo ffff880101138000, task 
> ffff8801011049c0)
> Stack:
>   0000000000000222 00000000000008b8 ffff8800216ba700 ffff8800216ba7d8
>   ffff880141843da0 ffffffff817605da 0000000000000000 00000000000008b8
>   ffff880141843de0 ffffffff8154446f ffff88014184e5b8 ffff88014184e578
> Call Trace:
>   <IRQ>
>   [<ffffffff817605da>] _raw_spin_lock_irqsave+0x2a/0x40
>   [<ffffffff8154446f>] xen_netbk_schedule_xenvif+0x8f/0x100
>   [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
>   [<ffffffff81544505>] xen_netbk_check_rx_xenvif+0x25/0x60
>   [<ffffffff81544589>] tx_credit_callback+0x49/0x50
>   [<ffffffff8105ee04>] call_timer_fn+0x44/0x120
>   [<ffffffff8105f411>] run_timer_softirq+0x241/0x2b0
>   [<ffffffff81544540>] ? xen_netbk_check_rx_xenvif+0x60/0x60
>   [<ffffffff8105731f>] __do_softirq+0xcf/0x250
>   [<ffffffff810c1253>] ? handle_percpu_irq+0x43/0x60
>   [<ffffffff8176971c>] call_softirq+0x1c/0x30
>   [<ffffffff81015425>] do_softirq+0x65/0xa0
>   [<ffffffff8105710d>] irq_exit+0xbd/0xe0
>   [<ffffffff8141a73f>] xen_evtchn_do_upcall+0x2f/0x40
>   [<ffffffff8176977e>] xen_do_hypervisor_callback+0x1e/0x30

Notice the tracelog is different here, this looks like a vallina bug to
me. It is the timer callback that triggers the oops. This one should be
simple to fix - we should also shut down the timer when shutting down
vif.

Will get to this tomorrow. Need to have rest now. :-)


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 20:33:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20: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 1U5j1A-0001Hs-Ua; Wed, 13 Feb 2013 20:33: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 1U5j19-0001Hj-VO
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 20:33:24 +0000
Received: from [85.158.143.99:7433] by server-3.bemta-4.messagelabs.com id
	E0/E9-08920-398FB115; Wed, 13 Feb 2013 20:33:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360787601!22098193!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13104 invoked from network); 13 Feb 2013 20:33:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 20:33:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DKWgRO006383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 20:32: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
	r1DKWfef010771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 20:32:41 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
	r1DKWe0F024633; Wed, 13 Feb 2013 14:32:40 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 12:32:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 542EC1BF781; Wed, 13 Feb 2013 15:32:39 -0500 (EST)
Date: Wed, 13 Feb 2013 15:32:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Fabio Fantoni <fantonifabio@tiscali.it>
Message-ID: <20130213203239.GC24566@phenom.dumpdata.com>
References: <511BA0D7.8070809@tiscali.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511BA0D7.8070809@tiscali.it>
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.xensource.com>,
	James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] GPLPV 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 Wed, Feb 13, 2013 at 03:19:03PM +0100, Fabio Fantoni wrote:
> I have tried to build gplpv from source with makedist.bat but it
> gave me some errors about files not found.
> I saw that latest commits were big. Is there something incomplete
> and must I wait other commits before build it?

It would probably help if you pasted what those errors were.
> 
> I would like to see if new build fix network not working after
> restore on windows domUs using upstream qemu.
> Dom0 is wheezy with xen-unstable from source.
> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
> error on xen for now, probably is problem of gplpv with qemu
> upstream.
> Linux hvm domUs seem not have that problem, tested with quantal
> (ubuntu 12.10) and network works also after restore.
> If you need more details and tests tell me and I'll post it.
> 
> Another problem present on both traditional/upstream qemu  with
> older/new xen and  older/new gplpv is domU's time not correctly
> updated after restore (it remains the time at the save operation),
> this is a big problem with windows domUs (DC and client) in a
> windows domain where the time source is DC by default.
> 
> Thanks for any reply.
> 



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 13 20:33:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 20: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 1U5j1A-0001Hs-Ua; Wed, 13 Feb 2013 20:33: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 1U5j19-0001Hj-VO
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 20:33:24 +0000
Received: from [85.158.143.99:7433] by server-3.bemta-4.messagelabs.com id
	E0/E9-08920-398FB115; Wed, 13 Feb 2013 20:33:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360787601!22098193!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzA2NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13104 invoked from network); 13 Feb 2013 20:33:22 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 20:33:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DKWgRO006383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 20:32: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
	r1DKWfef010771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 20:32:41 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
	r1DKWe0F024633; Wed, 13 Feb 2013 14:32:40 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 12:32:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 542EC1BF781; Wed, 13 Feb 2013 15:32:39 -0500 (EST)
Date: Wed, 13 Feb 2013 15:32:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Fabio Fantoni <fantonifabio@tiscali.it>
Message-ID: <20130213203239.GC24566@phenom.dumpdata.com>
References: <511BA0D7.8070809@tiscali.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511BA0D7.8070809@tiscali.it>
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.xensource.com>,
	James Harper <james.harper@bendigoit.com.au>
Subject: Re: [Xen-devel] GPLPV 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 Wed, Feb 13, 2013 at 03:19:03PM +0100, Fabio Fantoni wrote:
> I have tried to build gplpv from source with makedist.bat but it
> gave me some errors about files not found.
> I saw that latest commits were big. Is there something incomplete
> and must I wait other commits before build it?

It would probably help if you pasted what those errors were.
> 
> I would like to see if new build fix network not working after
> restore on windows domUs using upstream qemu.
> Dom0 is wheezy with xen-unstable from source.
> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
> error on xen for now, probably is problem of gplpv with qemu
> upstream.
> Linux hvm domUs seem not have that problem, tested with quantal
> (ubuntu 12.10) and network works also after restore.
> If you need more details and tests tell me and I'll post it.
> 
> Another problem present on both traditional/upstream qemu  with
> older/new xen and  older/new gplpv is domU's time not correctly
> updated after restore (it remains the time at the save operation),
> this is a big problem with windows domUs (DC and client) in a
> windows domain where the time source is DC by default.
> 
> Thanks for any reply.
> 



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 13 21:20:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:20: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 1U5jkH-0001iI-46; Wed, 13 Feb 2013 21:20:01 +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 1U5jkF-0001iD-Bd
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:19:59 +0000
Received: from [85.158.143.99:42011] by server-2.bemta-4.messagelabs.com id
	D9/A8-01597-E730C115; Wed, 13 Feb 2013 21:19:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360790397!27392708!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9432 invoked from network); 13 Feb 2013 21:19:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 21:19:57 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (josoe mo43) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Q023cbp1DKexi0 ;
	Wed, 13 Feb 2013 22:19:55 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id C05551884C; Wed, 13 Feb 2013 22:19:54 +0100 (CET)
Date: Wed, 13 Feb 2013 22:19:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130213211954.GA30363@aepfle.de>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130213185826.GA25891@aepfle.de>
	<20130213194346.GA23146@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213194346.GA23146@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, Konrad Rzeszutek Wilk wrote:

> So the VCPU1 is looping around trying to read the pvclock. Presumarily
> the info is full of zeros.

I will have a look tomorrow. Is the page perhaps not mapped and qemu is
spinning in dom0?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:20:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:20: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 1U5jkH-0001iI-46; Wed, 13 Feb 2013 21:20:01 +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 1U5jkF-0001iD-Bd
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:19:59 +0000
Received: from [85.158.143.99:42011] by server-2.bemta-4.messagelabs.com id
	D9/A8-01597-E730C115; Wed, 13 Feb 2013 21:19:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360790397!27392708!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTM2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9432 invoked from network); 13 Feb 2013 21:19:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Feb 2013 21:19:57 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0PEbcd
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-126.pools.arcor-ip.net [88.65.85.126])
	by smtp.strato.de (josoe mo43) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Q023cbp1DKexi0 ;
	Wed, 13 Feb 2013 22:19:55 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id C05551884C; Wed, 13 Feb 2013 22:19:54 +0100 (CET)
Date: Wed, 13 Feb 2013 22:19:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130213211954.GA30363@aepfle.de>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130213185826.GA25891@aepfle.de>
	<20130213194346.GA23146@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213194346.GA23146@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, Konrad Rzeszutek Wilk wrote:

> So the VCPU1 is looping around trying to read the pvclock. Presumarily
> the info is full of zeros.

I will have a look tomorrow. Is the page perhaps not mapped and qemu is
spinning in dom0?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:33:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:33: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 1U5jx2-0001wK-Fl; Wed, 13 Feb 2013 21:33: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 1U5jx1-0001wF-Dg
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:33:11 +0000
Received: from [85.158.138.51:35424] by server-3.bemta-3.messagelabs.com id
	0C/4F-31070-2960C115; Wed, 13 Feb 2013 21:33:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360791185!19435817!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10103 invoked from network); 13 Feb 2013 21:33:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:33:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="1435138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 21:33: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.297.1; Wed, 13 Feb 2013 21:33:04 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5jwu-0001WD-If;
	Wed, 13 Feb 2013 21:33:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5jwu-0000vX-3w;
	Wed, 13 Feb 2013 21:33:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16164-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 21:33:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16164: 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 16164 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16164/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 15418
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore     fail REGR. vs. 15418
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 15418

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 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-amd64-amd64-win         16 leak-check/check             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-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 linux                a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 11 08:27:49 2013 -0800

    Linux 3.0.63

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:33:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:33: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 1U5jx2-0001wK-Fl; Wed, 13 Feb 2013 21:33: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 1U5jx1-0001wF-Dg
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:33:11 +0000
Received: from [85.158.138.51:35424] by server-3.bemta-3.messagelabs.com id
	0C/4F-31070-2960C115; Wed, 13 Feb 2013 21:33:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360791185!19435817!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyMjcw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10103 invoked from network); 13 Feb 2013 21:33:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:33:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="1435138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Feb 2013 21:33: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.297.1; Wed, 13 Feb 2013 21:33:04 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5jwu-0001WD-If;
	Wed, 13 Feb 2013 21:33:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5jwu-0000vX-3w;
	Wed, 13 Feb 2013 21:33:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16164-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 13 Feb 2013 21:33:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16164: 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 16164 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16164/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 15418
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore     fail REGR. vs. 15418
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 15418

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 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-amd64-amd64-win         16 leak-check/check             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-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 linux                a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 11 08:27:49 2013 -0800

    Linux 3.0.63

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:44:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:44: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 1U5k7e-00029a-Ry; Wed, 13 Feb 2013 21:44:10 +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 1U5k7d-00029V-Au
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:44:09 +0000
Received: from [85.158.143.35:5430] by server-1.bemta-4.messagelabs.com id
	FC/C2-08839-8290C115; Wed, 13 Feb 2013 21:44:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360791846!11732488!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzIwMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7264 invoked from network); 13 Feb 2013 21:44:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 21:44:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DLi3i4019992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 21:44:03 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
	r1DLi2Xw005211
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 21:44:02 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
	r1DLi12e011636; Wed, 13 Feb 2013 15:44:02 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 13:44:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 947F11BF781; Wed, 13 Feb 2013 16:44:00 -0500 (EST)
Date: Wed, 13 Feb 2013 16:44:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130213214400.GA17041@phenom.dumpdata.com>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130213185826.GA25891@aepfle.de>
	<20130213194346.GA23146@phenom.dumpdata.com>
	<20130213211954.GA30363@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213211954.GA30363@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, 2013 at 10:19:54PM +0100, Olaf Hering wrote:
> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:
> 
> > So the VCPU1 is looping around trying to read the pvclock. Presumarily
> > the info is full of zeros.
> 
> I will have a look tomorrow. Is the page perhaps not mapped and qemu is
> spinning in dom0?

QEMU looks to be idle.
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:44:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:44: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 1U5k7e-00029a-Ry; Wed, 13 Feb 2013 21:44:10 +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 1U5k7d-00029V-Au
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:44:09 +0000
Received: from [85.158.143.35:5430] by server-1.bemta-4.messagelabs.com id
	FC/C2-08839-8290C115; Wed, 13 Feb 2013 21:44:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360791846!11732488!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzIwMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7264 invoked from network); 13 Feb 2013 21:44:07 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Feb 2013 21:44:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1DLi3i4019992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 13 Feb 2013 21:44:03 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
	r1DLi2Xw005211
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 13 Feb 2013 21:44:02 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
	r1DLi12e011636; Wed, 13 Feb 2013 15:44:02 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 13:44:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 947F11BF781; Wed, 13 Feb 2013 16:44:00 -0500 (EST)
Date: Wed, 13 Feb 2013 16:44:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130213214400.GA17041@phenom.dumpdata.com>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130213185826.GA25891@aepfle.de>
	<20130213194346.GA23146@phenom.dumpdata.com>
	<20130213211954.GA30363@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213211954.GA30363@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, 2013 at 10:19:54PM +0100, Olaf Hering wrote:
> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:
> 
> > So the VCPU1 is looping around trying to read the pvclock. Presumarily
> > the info is full of zeros.
> 
> I will have a look tomorrow. Is the page perhaps not mapped and qemu is
> spinning in dom0?

QEMU looks to be idle.
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kER-0002KU-UU; Wed, 13 Feb 2013 21:51:11 +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 1U5kEP-0002K0-KZ
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:10 +0000
Received: from [85.158.139.211:15752] by server-12.bemta-5.messagelabs.com id
	23/E8-20195-CCA0C115; Wed, 13 Feb 2013 21:51:08 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360792265!21344102!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31584 invoked from network); 13 Feb 2013 21:51:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7411753"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:06 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: a5dd2f1fe65e99571c781a4cfd4f930d1dadacbc
Message-ID: <a5dd2f1fe65e99571c78.1360792344@colonel-moodus.bos.xci-test.com>
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:24 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] [v3] HVM firmware passthrough libxl
	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

Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

diff -r 3d809b510886 -r a5dd2f1fe65e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 13 16:20:24 2013 -0500
+++ b/tools/libxl/libxl_dom.c	Wed Feb 13 16:20:32 2013 -0500
@@ -31,8 +31,7 @@ libxl_domain_type libxl__domain_type(lib
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (ret != 1 || info.domain != domid) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                   "unable to get domain type for domid=%"PRIu32, domid);
+        LOG(ERROR, "unable to get domain type for domid=%"PRIu32, domid);
         return LIBXL_DOMAIN_TYPE_INVALID;
     }
     if (info.flags & XEN_DOMINF_hvm_guest)
@@ -313,20 +312,19 @@ int libxl__build_post(libxl__gc *gc, uin
 
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
-    ents[1] = libxl__sprintf(gc, "%"PRId64, info->max_memkb);
+    ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
     ents[2] = "memory/target";
-    ents[3] = libxl__sprintf(gc, "%"PRId64,
-                             info->target_memkb - info->video_memkb);
+    ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);
     ents[4] = "memory/videoram";
-    ents[5] = libxl__sprintf(gc, "%"PRId64, info->video_memkb);
+    ents[5] = GCSPRINTF("%"PRId64, info->video_memkb);
     ents[6] = "domid";
-    ents[7] = libxl__sprintf(gc, "%d", domid);
+    ents[7] = GCSPRINTF("%d", domid);
     ents[8] = "store/port";
-    ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
+    ents[9] = GCSPRINTF("%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
-    ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[11] = GCSPRINTF("%lu", state->store_mfn);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[12+(i*2)]   = GCSPRINTF("cpu/%d/availability", i);
         ents[12+(i*2)+1] = libxl_bitmap_test(&info->avail_vcpus, i)
                             ? "online" : "offline";
     }
@@ -335,7 +333,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
         hvm_ents[0] = "hvmloader/generation-id-address";
-        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+        hvm_ents[1] = GCSPRINTF("0x%lx", state->vm_generationid_addr);
     }
 
     dom_path = libxl__xs_get_dompath(gc, domid);
@@ -343,7 +341,7 @@ int libxl__build_post(libxl__gc *gc, uin
         return ERROR_FAIL;
     }
 
-    vm_path = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path), NULL);
+    vm_path = xs_read(ctx->xsh, XBT_NULL, GCSPRINTF("%s/vm", dom_path), NULL);
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
@@ -374,7 +372,7 @@ int libxl__build_pv(libxl__gc *gc, uint3
 
     dom = xc_dom_allocate(ctx->xch, state->pv_cmdline, info->u.pv.features);
     if (!dom) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_allocate failed");
+        LOGE(ERROR, "xc_dom_allocate failed");
         return ERROR_FAIL;
     }
 
@@ -384,13 +382,13 @@ int libxl__build_pv(libxl__gc *gc, uint3
                                 state->pv_kernel.data,
                                 state->pv_kernel.size);
         if ( ret != 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_kernel_mem failed");
+            LOGE(ERROR, "xc_dom_kernel_mem failed");
             goto out;
         }
     } else {
         ret = xc_dom_kernel_file(dom, state->pv_kernel.path);
         if ( ret != 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_kernel_file failed");
+            LOGE(ERROR, "xc_dom_kernel_file failed");
             goto out;
         }
     }
@@ -398,12 +396,12 @@ int libxl__build_pv(libxl__gc *gc, uint3
     if ( state->pv_ramdisk.path && strlen(state->pv_ramdisk.path) ) {
         if (state->pv_ramdisk.mapped) {
             if ( (ret = xc_dom_ramdisk_mem(dom, state->pv_ramdisk.data, state->pv_ramdisk.size)) != 0 ) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_ramdisk_mem failed");
+                LOGE(ERROR, "xc_dom_ramdisk_mem failed");
                 goto out;
             }
         } else {
             if ( (ret = xc_dom_ramdisk_file(dom, state->pv_ramdisk.path)) != 0 ) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_ramdisk_file failed");
+                LOGE(ERROR, "xc_dom_ramdisk_file failed");
                 goto out;
             }
         }
@@ -416,31 +414,31 @@ int libxl__build_pv(libxl__gc *gc, uint3
     dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
+        LOGE(ERROR, "xc_dom_boot_xen_init failed");
         goto out;
     }
     if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_parse_image failed");
+        LOGE(ERROR, "xc_dom_parse_image failed");
         goto out;
     }
     if ( (ret = xc_dom_mem_init(dom, info->target_memkb / 1024)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_mem_init failed");
+        LOGE(ERROR, "xc_dom_mem_init failed");
         goto out;
     }
     if ( (ret = xc_dom_boot_mem_init(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_mem_init failed");
+        LOGE(ERROR, "xc_dom_boot_mem_init failed");
         goto out;
     }
     if ( (ret = xc_dom_build_image(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_build_image failed");
+        LOGE(ERROR, "xc_dom_build_image failed");
         goto out;
     }
     if ( (ret = xc_dom_boot_image(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
+        LOGE(ERROR, "xc_dom_boot_image failed");
         goto out;
     }
     if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        LOGE(ERROR, "xc_dom_gnttab_init failed");
         goto out;
     }
 
@@ -679,8 +677,7 @@ int libxl__qemu_traditional_cmd(libxl__g
                                 const char *cmd)
 {
     char *path = NULL;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
+    path = GCSPRINTF("/local/domain/0/device-model/%d/command", domid);
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
@@ -697,8 +694,7 @@ struct libxl__physmap_info {
 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",
+    return GCSPRINTF("/local/domain/0/device-model/%d/physmap/%"PRIx64"/%s",
             domid, phys_offset, node);
 }
 
@@ -708,7 +704,6 @@ int libxl__toolstack_restore(uint32_t do
     libxl__save_helper_state *shs = user;
     libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
     STATE_AO_GC(dcs->ao);
-    libxl_ctx *ctx = CTX;
     int i, ret;
     const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
@@ -718,7 +713,7 @@ int libxl__toolstack_restore(uint32_t do
     LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
 
     if (size < sizeof(version) + sizeof(count)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        LOG(ERROR, "wrong size");
         return -1;
     }
 
@@ -726,7 +721,7 @@ int libxl__toolstack_restore(uint32_t do
     ptr += sizeof(version);
 
     if (version != TOOLSTACK_SAVE_VERSION) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong version");
+        LOG(ERROR, "wrong version");
         return -1;
     }
 
@@ -735,7 +730,7 @@ int libxl__toolstack_restore(uint32_t do
 
     if (size < sizeof(version) + sizeof(count) +
             count * (sizeof(struct libxl__physmap_info))) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        LOG(ERROR, "wrong size");
         return -1;
     }
 
@@ -984,15 +979,13 @@ static void switch_logdirty_done(libxl__
 int libxl__domain_suspend_device_model(libxl__gc *gc,
                                        libxl__domain_suspend_state *dss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
     uint32_t const domid = dss->domid;
     const char *const filename = dss->dm_savefile;
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
+        LOG(DEBUG, "Saving device model state to %s", filename);
         libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
@@ -1168,8 +1161,7 @@ int libxl__domain_suspend_common_callbac
 static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
-    return libxl__sprintf(gc,
-            "/local/domain/0/device-model/%d/physmap/%s/%s",
+    return GCSPRINTF("/local/domain/0/device-model/%d/physmap/%s/%s",
             domid, phys_offset, node);
 }
 
@@ -1186,7 +1178,7 @@ int libxl__toolstack_save(uint32_t domid
     char **entries = NULL;
     struct libxl__physmap_info *pi;
 
-    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+    entries = libxl__xs_directory(gc, 0, GCSPRINTF(
                 "/local/domain/0/device-model/%d/physmap", domid), &num);
     count = num;
 
@@ -1327,7 +1319,7 @@ void libxl__domain_suspend(libxl__egc *e
         char *path;
         char *addr;
 
-        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+        path = GCSPRINTF("%s/hvmloader/generation-id-address",
                               libxl__xs_get_dompath(gc, domid));
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
@@ -1541,10 +1533,7 @@ static void domain_suspend_done(libxl__e
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
-    char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
-    if (!s)
-        LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "cannot allocate for uuid");
-    return s;
+    return GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
 }
 
 static const char *userdata_path(libxl__gc *gc, uint32_t domid,
@@ -1552,34 +1541,27 @@ static const char *userdata_path(libxl__
                                       const char *wh)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    char *path, *uuid_string;
+    char *uuid_string;
     libxl_dominfo info;
     int rc;
 
     rc = libxl_domain_info(ctx, &info, domid);
     if (rc) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to find domain info"
-                     " for domain %"PRIu32, domid);
+        LOGE(ERROR, "unable to find domain info for domain %"PRIu32, domid);
         return NULL;
     }
-    uuid_string = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+    uuid_string = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
 
-    path = libxl__sprintf(gc, "/var/lib/xen/"
-                         "userdata-%s.%u.%s.%s",
-                         wh, domid, uuid_string, userdata_userid);
-    if (!path)
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to allocate for"
-                     " userdata path");
-    return path;
+    return GCSPRINTF("/var/lib/xen/userdata-%s.%u.%s.%s",
+                     wh, domid, uuid_string, userdata_userid);
 }
 
 static int userdata_delete(libxl__gc *gc, const char *path)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     int r;
     r = unlink(path);
     if (r) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "remove failed for %s", path);
+        LOGE(ERROR, "remove failed for %s", path);
         return errno;
     }
     return 0;
@@ -1587,7 +1569,6 @@ static int userdata_delete(libxl__gc *gc
 
 void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *pattern;
     glob_t gl;
     int r, i;
@@ -1603,7 +1584,7 @@ void libxl__userdata_destroyall(libxl__g
     if (r == GLOB_NOMATCH)
         goto out;
     if (r)
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "glob failed for %s", pattern);
+        LOGE(ERROR, "glob failed for %s", pattern);
 
     for (i=0; i<gl.gl_pathc; i++) {
         userdata_delete(gc, gl.gl_pathv[i]);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kER-0002KU-UU; Wed, 13 Feb 2013 21:51:11 +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 1U5kEP-0002K0-KZ
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:10 +0000
Received: from [85.158.139.211:15752] by server-12.bemta-5.messagelabs.com id
	23/E8-20195-CCA0C115; Wed, 13 Feb 2013 21:51:08 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360792265!21344102!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31584 invoked from network); 13 Feb 2013 21:51:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7411753"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:06 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: a5dd2f1fe65e99571c781a4cfd4f930d1dadacbc
Message-ID: <a5dd2f1fe65e99571c78.1360792344@colonel-moodus.bos.xci-test.com>
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:24 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] [v3] HVM firmware passthrough libxl
	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

Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

diff -r 3d809b510886 -r a5dd2f1fe65e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 13 16:20:24 2013 -0500
+++ b/tools/libxl/libxl_dom.c	Wed Feb 13 16:20:32 2013 -0500
@@ -31,8 +31,7 @@ libxl_domain_type libxl__domain_type(lib
 
     ret = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (ret != 1 || info.domain != domid) {
-        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
-                   "unable to get domain type for domid=%"PRIu32, domid);
+        LOG(ERROR, "unable to get domain type for domid=%"PRIu32, domid);
         return LIBXL_DOMAIN_TYPE_INVALID;
     }
     if (info.flags & XEN_DOMINF_hvm_guest)
@@ -313,20 +312,19 @@ int libxl__build_post(libxl__gc *gc, uin
 
     ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
-    ents[1] = libxl__sprintf(gc, "%"PRId64, info->max_memkb);
+    ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
     ents[2] = "memory/target";
-    ents[3] = libxl__sprintf(gc, "%"PRId64,
-                             info->target_memkb - info->video_memkb);
+    ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);
     ents[4] = "memory/videoram";
-    ents[5] = libxl__sprintf(gc, "%"PRId64, info->video_memkb);
+    ents[5] = GCSPRINTF("%"PRId64, info->video_memkb);
     ents[6] = "domid";
-    ents[7] = libxl__sprintf(gc, "%d", domid);
+    ents[7] = GCSPRINTF("%d", domid);
     ents[8] = "store/port";
-    ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
+    ents[9] = GCSPRINTF("%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
-    ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[11] = GCSPRINTF("%lu", state->store_mfn);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[12+(i*2)]   = GCSPRINTF("cpu/%d/availability", i);
         ents[12+(i*2)+1] = libxl_bitmap_test(&info->avail_vcpus, i)
                             ? "online" : "offline";
     }
@@ -335,7 +333,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         hvm_ents = libxl__calloc(gc, 3, sizeof(char *));
         hvm_ents[0] = "hvmloader/generation-id-address";
-        hvm_ents[1] = libxl__sprintf(gc, "0x%lx", state->vm_generationid_addr);
+        hvm_ents[1] = GCSPRINTF("0x%lx", state->vm_generationid_addr);
     }
 
     dom_path = libxl__xs_get_dompath(gc, domid);
@@ -343,7 +341,7 @@ int libxl__build_post(libxl__gc *gc, uin
         return ERROR_FAIL;
     }
 
-    vm_path = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path), NULL);
+    vm_path = xs_read(ctx->xsh, XBT_NULL, GCSPRINTF("%s/vm", dom_path), NULL);
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
 
@@ -374,7 +372,7 @@ int libxl__build_pv(libxl__gc *gc, uint3
 
     dom = xc_dom_allocate(ctx->xch, state->pv_cmdline, info->u.pv.features);
     if (!dom) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_allocate failed");
+        LOGE(ERROR, "xc_dom_allocate failed");
         return ERROR_FAIL;
     }
 
@@ -384,13 +382,13 @@ int libxl__build_pv(libxl__gc *gc, uint3
                                 state->pv_kernel.data,
                                 state->pv_kernel.size);
         if ( ret != 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_kernel_mem failed");
+            LOGE(ERROR, "xc_dom_kernel_mem failed");
             goto out;
         }
     } else {
         ret = xc_dom_kernel_file(dom, state->pv_kernel.path);
         if ( ret != 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_kernel_file failed");
+            LOGE(ERROR, "xc_dom_kernel_file failed");
             goto out;
         }
     }
@@ -398,12 +396,12 @@ int libxl__build_pv(libxl__gc *gc, uint3
     if ( state->pv_ramdisk.path && strlen(state->pv_ramdisk.path) ) {
         if (state->pv_ramdisk.mapped) {
             if ( (ret = xc_dom_ramdisk_mem(dom, state->pv_ramdisk.data, state->pv_ramdisk.size)) != 0 ) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_ramdisk_mem failed");
+                LOGE(ERROR, "xc_dom_ramdisk_mem failed");
                 goto out;
             }
         } else {
             if ( (ret = xc_dom_ramdisk_file(dom, state->pv_ramdisk.path)) != 0 ) {
-                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_ramdisk_file failed");
+                LOGE(ERROR, "xc_dom_ramdisk_file failed");
                 goto out;
             }
         }
@@ -416,31 +414,31 @@ int libxl__build_pv(libxl__gc *gc, uint3
     dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
+        LOGE(ERROR, "xc_dom_boot_xen_init failed");
         goto out;
     }
     if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_parse_image failed");
+        LOGE(ERROR, "xc_dom_parse_image failed");
         goto out;
     }
     if ( (ret = xc_dom_mem_init(dom, info->target_memkb / 1024)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_mem_init failed");
+        LOGE(ERROR, "xc_dom_mem_init failed");
         goto out;
     }
     if ( (ret = xc_dom_boot_mem_init(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_mem_init failed");
+        LOGE(ERROR, "xc_dom_boot_mem_init failed");
         goto out;
     }
     if ( (ret = xc_dom_build_image(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_build_image failed");
+        LOGE(ERROR, "xc_dom_build_image failed");
         goto out;
     }
     if ( (ret = xc_dom_boot_image(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
+        LOGE(ERROR, "xc_dom_boot_image failed");
         goto out;
     }
     if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        LOGE(ERROR, "xc_dom_gnttab_init failed");
         goto out;
     }
 
@@ -679,8 +677,7 @@ int libxl__qemu_traditional_cmd(libxl__g
                                 const char *cmd)
 {
     char *path = NULL;
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
+    path = GCSPRINTF("/local/domain/0/device-model/%d/command", domid);
     return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
 }
 
@@ -697,8 +694,7 @@ struct libxl__physmap_info {
 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",
+    return GCSPRINTF("/local/domain/0/device-model/%d/physmap/%"PRIx64"/%s",
             domid, phys_offset, node);
 }
 
@@ -708,7 +704,6 @@ int libxl__toolstack_restore(uint32_t do
     libxl__save_helper_state *shs = user;
     libxl__domain_create_state *dcs = CONTAINER_OF(shs, *dcs, shs);
     STATE_AO_GC(dcs->ao);
-    libxl_ctx *ctx = CTX;
     int i, ret;
     const uint8_t *ptr = buf;
     uint32_t count = 0, version = 0;
@@ -718,7 +713,7 @@ int libxl__toolstack_restore(uint32_t do
     LOG(DEBUG,"domain=%"PRIu32" toolstack data size=%"PRIu32, domid, size);
 
     if (size < sizeof(version) + sizeof(count)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        LOG(ERROR, "wrong size");
         return -1;
     }
 
@@ -726,7 +721,7 @@ int libxl__toolstack_restore(uint32_t do
     ptr += sizeof(version);
 
     if (version != TOOLSTACK_SAVE_VERSION) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong version");
+        LOG(ERROR, "wrong version");
         return -1;
     }
 
@@ -735,7 +730,7 @@ int libxl__toolstack_restore(uint32_t do
 
     if (size < sizeof(version) + sizeof(count) +
             count * (sizeof(struct libxl__physmap_info))) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "wrong size");
+        LOG(ERROR, "wrong size");
         return -1;
     }
 
@@ -984,15 +979,13 @@ static void switch_logdirty_done(libxl__
 int libxl__domain_suspend_device_model(libxl__gc *gc,
                                        libxl__domain_suspend_state *dss)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret = 0;
     uint32_t const domid = dss->domid;
     const char *const filename = dss->dm_savefile;
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
+        LOG(DEBUG, "Saving device model state to %s", filename);
         libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
@@ -1168,8 +1161,7 @@ int libxl__domain_suspend_common_callbac
 static inline char *physmap_path(libxl__gc *gc, uint32_t domid,
         char *phys_offset, char *node)
 {
-    return libxl__sprintf(gc,
-            "/local/domain/0/device-model/%d/physmap/%s/%s",
+    return GCSPRINTF("/local/domain/0/device-model/%d/physmap/%s/%s",
             domid, phys_offset, node);
 }
 
@@ -1186,7 +1178,7 @@ int libxl__toolstack_save(uint32_t domid
     char **entries = NULL;
     struct libxl__physmap_info *pi;
 
-    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+    entries = libxl__xs_directory(gc, 0, GCSPRINTF(
                 "/local/domain/0/device-model/%d/physmap", domid), &num);
     count = num;
 
@@ -1327,7 +1319,7 @@ void libxl__domain_suspend(libxl__egc *e
         char *path;
         char *addr;
 
-        path = libxl__sprintf(gc, "%s/hvmloader/generation-id-address",
+        path = GCSPRINTF("%s/hvmloader/generation-id-address",
                               libxl__xs_get_dompath(gc, domid));
         addr = libxl__xs_read(gc, XBT_NULL, path);
 
@@ -1541,10 +1533,7 @@ static void domain_suspend_done(libxl__e
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
 {
-    char *s = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
-    if (!s)
-        LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "cannot allocate for uuid");
-    return s;
+    return GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
 }
 
 static const char *userdata_path(libxl__gc *gc, uint32_t domid,
@@ -1552,34 +1541,27 @@ static const char *userdata_path(libxl__
                                       const char *wh)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    char *path, *uuid_string;
+    char *uuid_string;
     libxl_dominfo info;
     int rc;
 
     rc = libxl_domain_info(ctx, &info, domid);
     if (rc) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to find domain info"
-                     " for domain %"PRIu32, domid);
+        LOGE(ERROR, "unable to find domain info for domain %"PRIu32, domid);
         return NULL;
     }
-    uuid_string = libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
+    uuid_string = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
 
-    path = libxl__sprintf(gc, "/var/lib/xen/"
-                         "userdata-%s.%u.%s.%s",
-                         wh, domid, uuid_string, userdata_userid);
-    if (!path)
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unable to allocate for"
-                     " userdata path");
-    return path;
+    return GCSPRINTF("/var/lib/xen/userdata-%s.%u.%s.%s",
+                     wh, domid, uuid_string, userdata_userid);
 }
 
 static int userdata_delete(libxl__gc *gc, const char *path)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     int r;
     r = unlink(path);
     if (r) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "remove failed for %s", path);
+        LOGE(ERROR, "remove failed for %s", path);
         return errno;
     }
     return 0;
@@ -1587,7 +1569,6 @@ static int userdata_delete(libxl__gc *gc
 
 void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *pattern;
     glob_t gl;
     int r, i;
@@ -1603,7 +1584,7 @@ void libxl__userdata_destroyall(libxl__g
     if (r == GLOB_NOMATCH)
         goto out;
     if (r)
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "glob failed for %s", pattern);
+        LOGE(ERROR, "glob failed for %s", pattern);
 
     for (i=0; i<gl.gl_pathc; i++) {
         userdata_delete(gc, gl.gl_pathv[i]);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kEQ-0002KG-4S; Wed, 13 Feb 2013 21:51:10 +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 1U5kEO-0002Jn-Hx
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:08 +0000
Received: from [85.158.139.211:51209] by server-11.bemta-5.messagelabs.com id
	2C/66-19159-CCA0C115; Wed, 13 Feb 2013 21:51:08 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360792265!21344102!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31575 invoked from network); 13 Feb 2013 21:51:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7411752"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:05 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: c5a851de03f122576a64a536134ee2bac699f28a
Message-ID: <c5a851de03f122576a64.1360792342@colonel-moodus.bos.xci-test.com>
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:22 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] [v3] HVM firmware passthrough libxl
	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

Switch libxl to use the new xc_hvm_build() libxc API.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

diff -r 63594ce1708f -r c5a851de03f1 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 13 09:31:48 2013 +0100
+++ b/tools/libxl/libxl_dom.c	Wed Feb 13 14:51:51 2013 -0500
@@ -542,17 +542,24 @@ int libxl__build_hvm(libxl__gc *gc, uint
               libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    struct xc_hvm_build_args args = {};
     int ret, rc = ERROR_FAIL;
     const char *firmware = libxl__domain_firmware(gc, info);
 
     if (!firmware)
         goto out;
-    ret = xc_hvm_build_target_mem(
-        ctx->xch,
-        domid,
-        (info->max_memkb - info->video_memkb) / 1024,
-        (info->target_memkb - info->video_memkb) / 1024,
-        firmware);
+
+    memset(&args, 0, sizeof(struct xc_hvm_build_args));
+    /* The params from the configuration file are in Mb, which are then
+     * multiplied by 1 Kb. This was then divided off when calling
+     * the old xc_hvm_build_target_mem() which then turned them to bytes.
+     * Do all this in one step here...
+     */
+    args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
+    args.mem_target = (uint64_t)(info->target_memkb - info->video_memkb) << 10;
+    args.image_file_name = firmware;
+
+    ret = xc_hvm_build(ctx->xch, domid, &args);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building failed");
         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 Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kEQ-0002KG-4S; Wed, 13 Feb 2013 21:51:10 +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 1U5kEO-0002Jn-Hx
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:08 +0000
Received: from [85.158.139.211:51209] by server-11.bemta-5.messagelabs.com id
	2C/66-19159-CCA0C115; Wed, 13 Feb 2013 21:51:08 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360792265!21344102!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg0MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31575 invoked from network); 13 Feb 2013 21:51:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7411752"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:05 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: c5a851de03f122576a64a536134ee2bac699f28a
Message-ID: <c5a851de03f122576a64.1360792342@colonel-moodus.bos.xci-test.com>
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:22 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] [v3] HVM firmware passthrough libxl
	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

Switch libxl to use the new xc_hvm_build() libxc API.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

diff -r 63594ce1708f -r c5a851de03f1 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 13 09:31:48 2013 +0100
+++ b/tools/libxl/libxl_dom.c	Wed Feb 13 14:51:51 2013 -0500
@@ -542,17 +542,24 @@ int libxl__build_hvm(libxl__gc *gc, uint
               libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    struct xc_hvm_build_args args = {};
     int ret, rc = ERROR_FAIL;
     const char *firmware = libxl__domain_firmware(gc, info);
 
     if (!firmware)
         goto out;
-    ret = xc_hvm_build_target_mem(
-        ctx->xch,
-        domid,
-        (info->max_memkb - info->video_memkb) / 1024,
-        (info->target_memkb - info->video_memkb) / 1024,
-        firmware);
+
+    memset(&args, 0, sizeof(struct xc_hvm_build_args));
+    /* The params from the configuration file are in Mb, which are then
+     * multiplied by 1 Kb. This was then divided off when calling
+     * the old xc_hvm_build_target_mem() which then turned them to bytes.
+     * Do all this in one step here...
+     */
+    args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
+    args.mem_target = (uint64_t)(info->target_memkb - info->video_memkb) << 10;
+    args.image_file_name = firmware;
+
+    ret = xc_hvm_build(ctx->xch, domid, &args);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building failed");
         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 Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kEP-0002K5-O3; Wed, 13 Feb 2013 21:51:09 +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 1U5kEN-0002Jn-R1
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:07 +0000
Received: from [85.158.139.211:16418] by server-11.bemta-5.messagelabs.com id
	74/66-19159-BCA0C115; Wed, 13 Feb 2013 21:51:07 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360792265!20732677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11753 invoked from network); 13 Feb 2013 21:51:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7044552"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:04 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:04 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:21 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough libxl
	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

This patch series is a follow-up to the earlier HVM firmware passthrough
patch set. It introduces support in libxl for specifying and loading the
ACPI and SMBIOS firmware blobs that are passed to libxc.

There are 3 patches in the series:
01 - Switch xl to use the new xc_hvm_build() libxc API.
02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
     Doc changes to the man page for xl.cfg describing the new params.
03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

This version cleans up some of the logging and error handling in the
new firmware passthrough code.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

(Based on xen-4.3 staging/unstable cs 26527)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kEP-0002K5-O3; Wed, 13 Feb 2013 21:51:09 +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 1U5kEN-0002Jn-R1
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:07 +0000
Received: from [85.158.139.211:16418] by server-11.bemta-5.messagelabs.com id
	74/66-19159-BCA0C115; Wed, 13 Feb 2013 21:51:07 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360792265!20732677!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11753 invoked from network); 13 Feb 2013 21:51:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7044552"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:04 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:04 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:21 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough libxl
	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

This patch series is a follow-up to the earlier HVM firmware passthrough
patch set. It introduces support in libxl for specifying and loading the
ACPI and SMBIOS firmware blobs that are passed to libxc.

There are 3 patches in the series:
01 - Switch xl to use the new xc_hvm_build() libxc API.
02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
     Doc changes to the man page for xl.cfg describing the new params.
03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c

This version cleans up some of the logging and error handling in the
new firmware passthrough code.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

(Based on xen-4.3 staging/unstable cs 26527)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kEQ-0002KN-Gz; Wed, 13 Feb 2013 21:51:10 +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 1U5kEP-0002Js-43
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:09 +0000
Received: from [85.158.139.211:15728] by server-14.bemta-5.messagelabs.com id
	6B/AE-06967-CCA0C115; Wed, 13 Feb 2013 21:51:08 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360792265!20732677!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 13 Feb 2013 21:51:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7044553"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:06 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3d809b51088617ef4787e10182a357cfbe8cff32
Message-ID: <3d809b51088617ef4787.1360792343@colonel-moodus.bos.xci-test.com>
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:23 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] [v3] HVM firmware passthrough libxl
	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

This patch introduces support for two new parameters in libxl:

smbios_firmware=<path_to_smbios_structures_file>
acpi_firmware=<path_to_acpi_tables_file>

The changes are primarily in the domain building code where the firmware files
are read and passed to libxc for loading into the new guest. After the domain
building call to libxc, the addresses for the loaded blobs are returned and
written to xenstore.

LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users to
determine if the feature is present.

This patch also updates the xl.cfg man page with descriptions of the two new
parameters for firmware passthrough.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

diff -r c5a851de03f1 -r 3d809b510886 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Wed Feb 13 14:51:51 2013 -0500
+++ b/docs/man/xl.cfg.pod.5	Wed Feb 13 16:20:24 2013 -0500
@@ -829,6 +829,25 @@ libxl: 'host,tm=0,sse3=0'
 More info about the CPUID instruction can be found in the processor manuals, and
 in Wikipedia: L<http://en.wikipedia.org/wiki/CPUID>
 
+=item B<acpi_firmware="STRING">
+
+Specify a path to a file that contains extra ACPI firmware tables to pass in to
+a guest. The file can contain several tables in their binary AML form
+concatenated together. Each table self describes its length so no additional
+information is needed. These tables will be added to the ACPI table set in the
+guest. Note that existing tables cannot be overridden by this feature. For
+example this cannot be used to override tables like DSDT, FADT, etc.
+
+=item B<smbios_firmware="STRING">
+
+Specify a path to a file that contains extra SMBIOS firmware structures to pass
+in to a guest. The file can contain a set DMTF predefined structures which will
+override the internal defaults. Not all predefined structures can be overridden,
+only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also contain any
+number of vendor defined SMBIOS structures (type 128 - 255). Since SMBIOS
+structures do not present their overall size, each entry in the file must be
+preceded by a 32b integer indicating the size of the next structure.
+
 =back 
 
 =head3 Guest Virtual Time Controls
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/libxl.h	Wed Feb 13 16:20:24 2013 -0500
@@ -68,6 +68,13 @@
  */
 
 /*
+ * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the feature for
+ * passing in SMBIOS and ACPI firmware to HVM guests is present
+ * in the library.
+ */
+#define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/libxl_dom.c	Wed Feb 13 16:20:24 2013 -0500
@@ -21,6 +21,7 @@
 
 #include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/hvm_xs_strings.h>
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
@@ -510,11 +511,61 @@ static int hvm_build_set_params(xc_inter
     return 0;
 }
 
-static const char *libxl__domain_firmware(libxl__gc *gc,
-                                          libxl_domain_build_info *info)
+static int hvm_build_set_xs_values(libxl__gc *gc,
+                                   uint32_t domid,
+                                   struct xc_hvm_build_args *args)
+{
+    char *path = NULL;
+    int ret = 0;
+
+    if (args->smbios_module.guest_addr_out) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_ADDRESS, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
+                              args->smbios_module.guest_addr_out);
+        if (ret)
+            goto err;
+
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_LENGTH, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
+                              args->smbios_module.length);
+        if (ret)
+            goto err;
+    }
+
+    if (args->acpi_module.guest_addr_out) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
+                              args->acpi_module.guest_addr_out);
+        if (ret)
+            goto err;
+
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
+                              args->acpi_module.length);
+        if (ret)
+            goto err;
+    }
+
+    return 0;
+
+err:
+    LOG(ERROR, "failed to write firmware xenstore value, err: %d", ret);
+    return ret;
+}
+
+static int libxl__domain_firmware(libxl__gc *gc,
+                                  libxl_domain_build_info *info,
+                                  struct xc_hvm_build_args *args)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *firmware;
+    int e, rc = ERROR_FAIL;
+    int datalen = 0;
+    void *data;
 
     if (info->u.hvm.firmware)
         firmware = info->u.hvm.firmware;
@@ -528,13 +579,52 @@ static const char *libxl__domain_firmwar
             firmware = "hvmloader";
             break;
         default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
-                       info->device_model_version);
-            return NULL;
+            LOG(ERROR, "invalid device model version %d",
+                info->device_model_version);
+            return ERROR_FAIL;
             break;
         }
     }
-    return libxl__abs_path(gc, firmware, libxl__xenfirmwaredir_path());
+    args->image_file_name = libxl__abs_path(gc, firmware,
+                                            libxl__xenfirmwaredir_path());
+
+    if (info->u.hvm.smbios_firmware) {
+        data = NULL;
+        e = libxl_read_file_contents(ctx, info->u.hvm.smbios_firmware,
+                                     &data, &datalen);
+        if (e) {
+            LOGEV(ERROR, e, "failed to read SMBIOS firmware file %s",
+                info->u.hvm.smbios_firmware);
+            goto out;
+        }
+        libxl__ptr_add(gc, data);
+        if (datalen) {
+            /* Only accept non-empty files */
+            args->smbios_module.data = data;
+            args->smbios_module.length = (uint32_t)datalen;
+        }
+    }
+
+    if (info->u.hvm.acpi_firmware) {
+        data = NULL;
+        e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
+                                     &data, &datalen);
+        if (e) {
+            LOGEV(ERROR, e, "failed to read ACPI firmware file %s",
+                info->u.hvm.acpi_firmware);
+            goto out;
+        }
+        libxl__ptr_add(gc, data);
+        if (datalen) {
+            /* Only accept non-empty files */
+            args->acpi_module.data = data;
+            args->acpi_module.length = (uint32_t)datalen;
+        }
+    }
+
+    return 0;
+out:
+    return rc;
 }
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
@@ -544,10 +634,6 @@ int libxl__build_hvm(libxl__gc *gc, uint
     libxl_ctx *ctx = libxl__gc_owner(gc);
     struct xc_hvm_build_args args = {};
     int ret, rc = ERROR_FAIL;
-    const char *firmware = libxl__domain_firmware(gc, info);
-
-    if (!firmware)
-        goto out;
 
     memset(&args, 0, sizeof(struct xc_hvm_build_args));
     /* The params from the configuration file are in Mb, which are then
@@ -557,22 +643,34 @@ int libxl__build_hvm(libxl__gc *gc, uint
      */
     args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
     args.mem_target = (uint64_t)(info->target_memkb - info->video_memkb) << 10;
-    args.image_file_name = firmware;
+
+    if (libxl__domain_firmware(gc, info, &args)) {
+        LOG(ERROR, "initializing domain firmware failed");
+        goto out;
+    }
 
     ret = xc_hvm_build(ctx->xch, domid, &args);
     if (ret) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building failed");
+        LOGEV(ERROR, ret, "hvm building failed");
         goto out;
     }
+
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
                                state->console_domid);
     if (ret) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
+        LOGEV(ERROR, ret, "hvm build set params failed");
         goto out;
     }
-    rc = 0;
+
+    ret = hvm_build_set_xs_values(gc, domid, &args);
+    if (ret) {
+        LOG(ERROR, "hvm build set xenstore values failed (ret=%d)", ret);
+        goto out;
+    }
+
+    return 0;
 out:
     return rc;
 }
@@ -634,7 +732,7 @@ int libxl__toolstack_restore(uint32_t do
 
     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");
@@ -848,7 +946,7 @@ static void switch_logdirty_xswatch(libx
         rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
         if (rc) goto out;
 
-        rc = libxl__xs_transaction_commit(gc, &t); 
+        rc = libxl__xs_transaction_commit(gc, &t);
         if (!rc) break;
         if (rc<0) goto out;
     }
@@ -1320,7 +1418,7 @@ void libxl__xc_domain_save_done(libxl__e
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
-        
+
         libxl__domain_save_device_model(egc, dss, domain_suspend_done);
         return;
     }
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/libxl_types.idl	Wed Feb 13 16:20:24 2013 -0500
@@ -308,6 +308,8 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
+                                       ("smbios_firmware",  string),
+                                       ("acpi_firmware",    string),
                                        ("nographic",        libxl_defbool),
                                        ("vga",              libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info),
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 13 16:20:24 2013 -0500
@@ -882,6 +882,11 @@ static void parse_config_data(const char
         }
 
         xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
+
+        xlu_cfg_replace_string(config, "smbios_firmware",
+                               &b_info->u.hvm.smbios_firmware, 0);
+        xlu_cfg_replace_string(config, "acpi_firmware",
+                               &b_info->u.hvm.acpi_firmware, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 21:51:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 21:51: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 1U5kEQ-0002KN-Gz; Wed, 13 Feb 2013 21:51:10 +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 1U5kEP-0002Js-43
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 21:51:09 +0000
Received: from [85.158.139.211:15728] by server-14.bemta-5.messagelabs.com id
	6B/AE-06967-CCA0C115; Wed, 13 Feb 2013 21:51:08 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360792265!20732677!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 13 Feb 2013 21:51:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Feb 2013 21:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; 
   d="scan'208";a="7044553"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	13 Feb 2013 21:51:06 +0000
Received: from colonel-moodus.bos.xci-test.com (10.204.207.129) by
	FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id
	14.2.318.1; Wed, 13 Feb 2013 16:51:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3d809b51088617ef4787e10182a357cfbe8cff32
Message-ID: <3d809b51088617ef4787.1360792343@colonel-moodus.bos.xci-test.com>
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 13 Feb 2013 16:52:23 -0500
From: Ross Philipson <ross.philipson@citrix.com>
To: <xen-devel@lists.xensource.com>
X-Originating-IP: [10.204.207.129]
Cc: ross.philipson@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] [v3] HVM firmware passthrough libxl
	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

This patch introduces support for two new parameters in libxl:

smbios_firmware=<path_to_smbios_structures_file>
acpi_firmware=<path_to_acpi_tables_file>

The changes are primarily in the domain building code where the firmware files
are read and passed to libxc for loading into the new guest. After the domain
building call to libxc, the addresses for the loaded blobs are returned and
written to xenstore.

LIBXL_HAVE_FIRMWARE_PASSTHROUGH is defined in libxl.h to allow users to
determine if the feature is present.

This patch also updates the xl.cfg man page with descriptions of the two new
parameters for firmware passthrough.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

diff -r c5a851de03f1 -r 3d809b510886 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Wed Feb 13 14:51:51 2013 -0500
+++ b/docs/man/xl.cfg.pod.5	Wed Feb 13 16:20:24 2013 -0500
@@ -829,6 +829,25 @@ libxl: 'host,tm=0,sse3=0'
 More info about the CPUID instruction can be found in the processor manuals, and
 in Wikipedia: L<http://en.wikipedia.org/wiki/CPUID>
 
+=item B<acpi_firmware="STRING">
+
+Specify a path to a file that contains extra ACPI firmware tables to pass in to
+a guest. The file can contain several tables in their binary AML form
+concatenated together. Each table self describes its length so no additional
+information is needed. These tables will be added to the ACPI table set in the
+guest. Note that existing tables cannot be overridden by this feature. For
+example this cannot be used to override tables like DSDT, FADT, etc.
+
+=item B<smbios_firmware="STRING">
+
+Specify a path to a file that contains extra SMBIOS firmware structures to pass
+in to a guest. The file can contain a set DMTF predefined structures which will
+override the internal defaults. Not all predefined structures can be overridden,
+only the following types: 0, 1, 2, 3, 11, 22, 39. The file can also contain any
+number of vendor defined SMBIOS structures (type 128 - 255). Since SMBIOS
+structures do not present their overall size, each entry in the file must be
+preceded by a 32b integer indicating the size of the next structure.
+
 =back 
 
 =head3 Guest Virtual Time Controls
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/libxl.h	Wed Feb 13 16:20:24 2013 -0500
@@ -68,6 +68,13 @@
  */
 
 /*
+ * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the feature for
+ * passing in SMBIOS and ACPI firmware to HVM guests is present
+ * in the library.
+ */
+#define LIBXL_HAVE_FIRMWARE_PASSTHROUGH 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/libxl_dom.c	Wed Feb 13 16:20:24 2013 -0500
@@ -21,6 +21,7 @@
 
 #include <xc_dom.h>
 #include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/hvm_xs_strings.h>
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
@@ -510,11 +511,61 @@ static int hvm_build_set_params(xc_inter
     return 0;
 }
 
-static const char *libxl__domain_firmware(libxl__gc *gc,
-                                          libxl_domain_build_info *info)
+static int hvm_build_set_xs_values(libxl__gc *gc,
+                                   uint32_t domid,
+                                   struct xc_hvm_build_args *args)
+{
+    char *path = NULL;
+    int ret = 0;
+
+    if (args->smbios_module.guest_addr_out) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_ADDRESS, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
+                              args->smbios_module.guest_addr_out);
+        if (ret)
+            goto err;
+
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_SMBIOS_PT_LENGTH, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
+                              args->smbios_module.length);
+        if (ret)
+            goto err;
+    }
+
+    if (args->acpi_module.guest_addr_out) {
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%"PRIx64,
+                              args->acpi_module.guest_addr_out);
+        if (ret)
+            goto err;
+
+        path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
+
+        ret = libxl__xs_write(gc, XBT_NULL, path, "0x%x",
+                              args->acpi_module.length);
+        if (ret)
+            goto err;
+    }
+
+    return 0;
+
+err:
+    LOG(ERROR, "failed to write firmware xenstore value, err: %d", ret);
+    return ret;
+}
+
+static int libxl__domain_firmware(libxl__gc *gc,
+                                  libxl_domain_build_info *info,
+                                  struct xc_hvm_build_args *args)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *firmware;
+    int e, rc = ERROR_FAIL;
+    int datalen = 0;
+    void *data;
 
     if (info->u.hvm.firmware)
         firmware = info->u.hvm.firmware;
@@ -528,13 +579,52 @@ static const char *libxl__domain_firmwar
             firmware = "hvmloader";
             break;
         default:
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
-                       info->device_model_version);
-            return NULL;
+            LOG(ERROR, "invalid device model version %d",
+                info->device_model_version);
+            return ERROR_FAIL;
             break;
         }
     }
-    return libxl__abs_path(gc, firmware, libxl__xenfirmwaredir_path());
+    args->image_file_name = libxl__abs_path(gc, firmware,
+                                            libxl__xenfirmwaredir_path());
+
+    if (info->u.hvm.smbios_firmware) {
+        data = NULL;
+        e = libxl_read_file_contents(ctx, info->u.hvm.smbios_firmware,
+                                     &data, &datalen);
+        if (e) {
+            LOGEV(ERROR, e, "failed to read SMBIOS firmware file %s",
+                info->u.hvm.smbios_firmware);
+            goto out;
+        }
+        libxl__ptr_add(gc, data);
+        if (datalen) {
+            /* Only accept non-empty files */
+            args->smbios_module.data = data;
+            args->smbios_module.length = (uint32_t)datalen;
+        }
+    }
+
+    if (info->u.hvm.acpi_firmware) {
+        data = NULL;
+        e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
+                                     &data, &datalen);
+        if (e) {
+            LOGEV(ERROR, e, "failed to read ACPI firmware file %s",
+                info->u.hvm.acpi_firmware);
+            goto out;
+        }
+        libxl__ptr_add(gc, data);
+        if (datalen) {
+            /* Only accept non-empty files */
+            args->acpi_module.data = data;
+            args->acpi_module.length = (uint32_t)datalen;
+        }
+    }
+
+    return 0;
+out:
+    return rc;
 }
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
@@ -544,10 +634,6 @@ int libxl__build_hvm(libxl__gc *gc, uint
     libxl_ctx *ctx = libxl__gc_owner(gc);
     struct xc_hvm_build_args args = {};
     int ret, rc = ERROR_FAIL;
-    const char *firmware = libxl__domain_firmware(gc, info);
-
-    if (!firmware)
-        goto out;
 
     memset(&args, 0, sizeof(struct xc_hvm_build_args));
     /* The params from the configuration file are in Mb, which are then
@@ -557,22 +643,34 @@ int libxl__build_hvm(libxl__gc *gc, uint
      */
     args.mem_size = (uint64_t)(info->max_memkb - info->video_memkb) << 10;
     args.mem_target = (uint64_t)(info->target_memkb - info->video_memkb) << 10;
-    args.image_file_name = firmware;
+
+    if (libxl__domain_firmware(gc, info, &args)) {
+        LOG(ERROR, "initializing domain firmware failed");
+        goto out;
+    }
 
     ret = xc_hvm_build(ctx->xch, domid, &args);
     if (ret) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm building failed");
+        LOGEV(ERROR, ret, "hvm building failed");
         goto out;
     }
+
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
                                &state->store_mfn, state->console_port,
                                &state->console_mfn, state->store_domid,
                                state->console_domid);
     if (ret) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
+        LOGEV(ERROR, ret, "hvm build set params failed");
         goto out;
     }
-    rc = 0;
+
+    ret = hvm_build_set_xs_values(gc, domid, &args);
+    if (ret) {
+        LOG(ERROR, "hvm build set xenstore values failed (ret=%d)", ret);
+        goto out;
+    }
+
+    return 0;
 out:
     return rc;
 }
@@ -634,7 +732,7 @@ int libxl__toolstack_restore(uint32_t do
 
     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");
@@ -848,7 +946,7 @@ static void switch_logdirty_xswatch(libx
         rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
         if (rc) goto out;
 
-        rc = libxl__xs_transaction_commit(gc, &t); 
+        rc = libxl__xs_transaction_commit(gc, &t);
         if (!rc) break;
         if (rc<0) goto out;
     }
@@ -1320,7 +1418,7 @@ void libxl__xc_domain_save_done(libxl__e
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
         rc = libxl__domain_suspend_device_model(gc, dss);
         if (rc) goto out;
-        
+
         libxl__domain_save_device_model(egc, dss, domain_suspend_done);
         return;
     }
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/libxl_types.idl	Wed Feb 13 16:20:24 2013 -0500
@@ -308,6 +308,8 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
+                                       ("smbios_firmware",  string),
+                                       ("acpi_firmware",    string),
                                        ("nographic",        libxl_defbool),
                                        ("vga",              libxl_vga_interface_info),
                                        ("vnc",              libxl_vnc_info),
diff -r c5a851de03f1 -r 3d809b510886 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Feb 13 14:51:51 2013 -0500
+++ b/tools/libxl/xl_cmdimpl.c	Wed Feb 13 16:20:24 2013 -0500
@@ -882,6 +882,11 @@ static void parse_config_data(const char
         }
 
         xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
+
+        xlu_cfg_replace_string(config, "smbios_firmware",
+                               &b_info->u.hvm.smbios_firmware, 0);
+        xlu_cfg_replace_string(config, "acpi_firmware",
+                               &b_info->u.hvm.acpi_firmware, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 22:27:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 22: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 1U5knH-00036u-Ao; Wed, 13 Feb 2013 22:27:11 +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 1U5knG-00036p-4L
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 22:27:10 +0000
Received: from [85.158.143.35:51472] by server-3.bemta-4.messagelabs.com id
	1A/F6-08920-D331C115; Wed, 13 Feb 2013 22:27:09 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360794424!13211514!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9749 invoked from network); 13 Feb 2013 22:27:07 -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;
	13 Feb 2013 22:27:07 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5kn2-0008Sz-Ga; Thu, 14 Feb 2013 09:26:56 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 09:26:56 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, xen-devel
	<xen-devel@lists.xensource.com>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTA
Date: Wed, 13 Feb 2013 22:26:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
In-Reply-To: <511BA0D7.8070809@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.59]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.002
x-tm-as-result: No--28.042200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] GPLPV 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

> 
> I have tried to build gplpv from source with makedist.bat but it gave me
> some errors about files not found.
> I saw that latest commits were big. Is there something incomplete and
> must I wait other commits before build it?

It's possible I missed a commit but I can't see any missing files.

Can you post the output of makedist?

But yes the latest commits involve a pretty major change and I haven't tested save/restore yet so that is probably more broken than before.

> I would like to see if new build fix network not working after restore
> on windows domUs using upstream qemu.
> Dom0 is wheezy with xen-unstable from source.
> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
> error on xen for now, probably is problem of gplpv with qemu upstream.
> Linux hvm domUs seem not have that problem, tested with quantal (ubuntu
> 12.10) and network works also after restore.
> If you need more details and tests tell me and I'll post it.
> 
> Another problem present on both traditional/upstream qemu  with
> older/new xen and  older/new gplpv is domU's time not correctly updated
> after restore (it remains the time at the save operation), this is a big
> problem with windows domUs (DC and client) in a windows domain where
> the time source is DC by default.

I noticed that recently. I can't think how it could be a GPLPV bug though.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 22:27:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 22: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 1U5knH-00036u-Ao; Wed, 13 Feb 2013 22:27:11 +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 1U5knG-00036p-4L
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 22:27:10 +0000
Received: from [85.158.143.35:51472] by server-3.bemta-4.messagelabs.com id
	1A/F6-08920-D331C115; Wed, 13 Feb 2013 22:27:09 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360794424!13211514!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9749 invoked from network); 13 Feb 2013 22:27:07 -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;
	13 Feb 2013 22:27:07 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5kn2-0008Sz-Ga; Thu, 14 Feb 2013 09:26:56 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 09:26:56 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, xen-devel
	<xen-devel@lists.xensource.com>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTA
Date: Wed, 13 Feb 2013 22:26:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
In-Reply-To: <511BA0D7.8070809@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.59]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.002
x-tm-as-result: No--28.042200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] GPLPV 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

> 
> I have tried to build gplpv from source with makedist.bat but it gave me
> some errors about files not found.
> I saw that latest commits were big. Is there something incomplete and
> must I wait other commits before build it?

It's possible I missed a commit but I can't see any missing files.

Can you post the output of makedist?

But yes the latest commits involve a pretty major change and I haven't tested save/restore yet so that is probably more broken than before.

> I would like to see if new build fix network not working after restore
> on windows domUs using upstream qemu.
> Dom0 is wheezy with xen-unstable from source.
> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
> error on xen for now, probably is problem of gplpv with qemu upstream.
> Linux hvm domUs seem not have that problem, tested with quantal (ubuntu
> 12.10) and network works also after restore.
> If you need more details and tests tell me and I'll post it.
> 
> Another problem present on both traditional/upstream qemu  with
> older/new xen and  older/new gplpv is domU's time not correctly updated
> after restore (it remains the time at the save operation), this is a big
> problem with windows domUs (DC and client) in a windows domain where
> the time source is DC by default.

I noticed that recently. I can't think how it could be a GPLPV bug though.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 22:52:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 22: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 1U5lBi-0003OC-Ka; Wed, 13 Feb 2013 22:52:26 +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 1U5lBg-0003O7-O5
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 22:52:24 +0000
Received: from [85.158.139.83:46078] by server-9.bemta-5.messagelabs.com id
	EE/F0-24440-7291C115; Wed, 13 Feb 2013 22:52:23 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360795940!23547832!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11577 invoked from network); 13 Feb 2013 22:52:23 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2013 22:52:23 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5lBX-00007a-FG; Thu, 14 Feb 2013 09:52:15 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 09:52:15 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgABebgCAAT2SIA==
Date: Wed, 13 Feb 2013 22:52:14 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35671E77@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<511BA92E.1040002@hfp.de>
In-Reply-To: <511BA92E.1040002@hfp.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.59]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.002
x-tm-as-result: No--25.471700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 meantime I disabled hibernation (powercfg.exe -h off) and it
> seems to work now. Which revision from your repo do you wish to be
> tested? I am interested in testing, but my time is somewhat limited - I
> cannot make any promise.
> 
> As I said in my original post, rev956 works quite well with its core
> operations: net IO and disk IO.
> 

I've just fixed a hibernate problem under 4.2 and have just installed windows 8 to test the hibernate issues (previously I'd been testing Windows 2012 which doesn't have this feature I assume).

Once I've got those sorted I'll upload what I've got.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 22:52:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 22: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 1U5lBi-0003OC-Ka; Wed, 13 Feb 2013 22:52:26 +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 1U5lBg-0003O7-O5
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 22:52:24 +0000
Received: from [85.158.139.83:46078] by server-9.bemta-5.messagelabs.com id
	EE/F0-24440-7291C115; Wed, 13 Feb 2013 22:52:23 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360795940!23547832!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11577 invoked from network); 13 Feb 2013 22:52:23 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2013 22:52:23 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5lBX-00007a-FG; Thu, 14 Feb 2013 09:52:15 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 09:52:15 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgABebgCAAT2SIA==
Date: Wed, 13 Feb 2013 22:52:14 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35671E77@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<511BA92E.1040002@hfp.de>
In-Reply-To: <511BA92E.1040002@hfp.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.59]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.002
x-tm-as-result: No--25.471700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 meantime I disabled hibernation (powercfg.exe -h off) and it
> seems to work now. Which revision from your repo do you wish to be
> tested? I am interested in testing, but my time is somewhat limited - I
> cannot make any promise.
> 
> As I said in my original post, rev956 works quite well with its core
> operations: net IO and disk IO.
> 

I've just fixed a hibernate problem under 4.2 and have just installed windows 8 to test the hibernate issues (previously I'd been testing Windows 2012 which doesn't have this feature I assume).

Once I've got those sorted I'll upload what I've got.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 22:53:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 22: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 1U5lCk-0003RE-33; Wed, 13 Feb 2013 22:53:30 +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 1U5lCj-0003R7-2p
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 22:53:29 +0000
Received: from [85.158.143.35:23524] by server-1.bemta-4.messagelabs.com id
	A2/AC-08839-8691C115; Wed, 13 Feb 2013 22:53:28 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360796004!12456948!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28208 invoked from network); 13 Feb 2013 22:53:27 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-12.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2013 22:53:27 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5lCW-0006NN-J7; Thu, 14 Feb 2013 09:53:16 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 09:53:17 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, xen-devel
	<xen-devel@lists.xensource.com>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4ZbDQ
Date: Wed, 13 Feb 2013 22:53:16 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35671E9C@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
In-Reply-To: <511BA0D7.8070809@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.59]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.002
x-tm-as-result: No--22.837800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] GPLPV 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

> 
> I have tried to build gplpv from source with makedist.bat but it gave me
> some errors about files not found.
> I saw that latest commits were big. Is there something incomplete and
> must I wait other commits before build it?
> 

It's not missing xenusb is it? I've removed that from the build script for now as I haven't updated it but it's probably still in the installer.wxs.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 13 22:53:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 13 Feb 2013 22: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 1U5lCk-0003RE-33; Wed, 13 Feb 2013 22:53:30 +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 1U5lCj-0003R7-2p
	for xen-devel@lists.xensource.com; Wed, 13 Feb 2013 22:53:29 +0000
Received: from [85.158.143.35:23524] by server-1.bemta-4.messagelabs.com id
	A2/AC-08839-8691C115; Wed, 13 Feb 2013 22:53:28 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360796004!12456948!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28208 invoked from network); 13 Feb 2013 22:53:27 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-12.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Feb 2013 22:53:27 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5lCW-0006NN-J7; Thu, 14 Feb 2013 09:53:16 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 09:53:17 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, xen-devel
	<xen-devel@lists.xensource.com>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4ZbDQ
Date: Wed, 13 Feb 2013 22:53:16 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35671E9C@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
In-Reply-To: <511BA0D7.8070809@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.59]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.002
x-tm-as-result: No--22.837800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] GPLPV 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

> 
> I have tried to build gplpv from source with makedist.bat but it gave me
> some errors about files not found.
> I saw that latest commits were big. Is there something incomplete and
> must I wait other commits before build it?
> 

It's not missing xenusb is it? I've removed that from the build script for now as I haven't updated it but it's probably still in the installer.wxs.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 02:35:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 02: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 1U5oeh-0000zc-M0; Thu, 14 Feb 2013 02:34:35 +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 1U5oeg-0000zX-GO
	for Xen-devel@lists.xensource.com; Thu, 14 Feb 2013 02:34:34 +0000
Received: from [85.158.139.211:49761] by server-15.bemta-5.messagelabs.com id
	6F/D1-18914-83D4C115; Thu, 14 Feb 2013 02:34:32 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360809270!22409670!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIwNjY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 352 invoked from network); 14 Feb 2013 02:34:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 02:34:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1E2YSUE022009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 02:34: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
	r1E2YRap010918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 02:34:28 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1E2YR71019977; Wed, 13 Feb 2013 20:34:27 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 18:34:26 -0800
Date: Wed, 13 Feb 2013 18:34:25 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130213183425.0d17c236@mantra.us.oracle.com>
In-Reply-To: <20130211181824.169b9d05@mantra.us.oracle.com>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@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]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 14/16]: PVH xen: add
 xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 11 Feb 2013 18:18:24 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 24 Jan 2013 17:31:18 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:11 -0800 on 11 Jan (1357927863), Mukesh Rathor wrote:
> > 
> > > +    /* qemu, running on PVH dom0, mapping hvm domain's io pages
> > > during domain 
> > > +     * creation, doesn't have mfns in the HAP table */
> > > +    if ( !mfn_valid(mfn) && p2m_is_mmio(p2mt) ) {
> > 
> > This test should be for == p2m_mmio_direct; we don't want to try
> > mapping p2m_mmio_dm areas.
> 
> Yup. Done.

No, qemu is changing the mem type for these pages, so I need to dig
into understanding what it's trying to do there. But the above, I don't
think is correct. Xen returns p2m type of dm, but I don't think I'm
looking at right mfn's here for this qemu special case. Basically, it's
during hvm guest creation on PVH dom0 that qemu accesses some addresses
that are not mapped.

Anyways, I hope to figure whats going on in qemu soon.

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 Feb 14 02:35:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 02: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 1U5oeh-0000zc-M0; Thu, 14 Feb 2013 02:34:35 +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 1U5oeg-0000zX-GO
	for Xen-devel@lists.xensource.com; Thu, 14 Feb 2013 02:34:34 +0000
Received: from [85.158.139.211:49761] by server-15.bemta-5.messagelabs.com id
	6F/D1-18914-83D4C115; Thu, 14 Feb 2013 02:34:32 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360809270!22409670!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIwNjY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 352 invoked from network); 14 Feb 2013 02:34:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 02:34:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1E2YSUE022009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 02:34: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
	r1E2YRap010918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 02:34:28 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1E2YR71019977; Wed, 13 Feb 2013 20:34:27 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 13 Feb 2013 18:34:26 -0800
Date: Wed, 13 Feb 2013 18:34:25 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130213183425.0d17c236@mantra.us.oracle.com>
In-Reply-To: <20130211181824.169b9d05@mantra.us.oracle.com>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@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]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 14/16]: PVH xen: add
 xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 11 Feb 2013 18:18:24 -0800
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 24 Jan 2013 17:31:18 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:11 -0800 on 11 Jan (1357927863), Mukesh Rathor wrote:
> > 
> > > +    /* qemu, running on PVH dom0, mapping hvm domain's io pages
> > > during domain 
> > > +     * creation, doesn't have mfns in the HAP table */
> > > +    if ( !mfn_valid(mfn) && p2m_is_mmio(p2mt) ) {
> > 
> > This test should be for == p2m_mmio_direct; we don't want to try
> > mapping p2m_mmio_dm areas.
> 
> Yup. Done.

No, qemu is changing the mem type for these pages, so I need to dig
into understanding what it's trying to do there. But the above, I don't
think is correct. Xen returns p2m type of dm, but I don't think I'm
looking at right mfn's here for this qemu special case. Basically, it's
during hvm guest creation on PVH dom0 that qemu accesses some addresses
that are not mapped.

Anyways, I hope to figure whats going on in qemu soon.

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 Feb 14 03:19:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 03: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 1U5pM1-0001eM-0p; Thu, 14 Feb 2013 03:19: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 1U5pLz-0001eH-13
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 03:19:19 +0000
Received: from [85.158.139.211:4447] by server-10.bemta-5.messagelabs.com id
	DC/5D-04697-6B75C115; Thu, 14 Feb 2013 03:19:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360811957!21316235!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNDkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7025 invoked from network); 14 Feb 2013 03:19:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 03:19:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,660,1355097600"; 
   d="scan'208";a="1442486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 03:19: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.297.1; Thu, 14 Feb 2013 03:19:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5pLo-0003FO-WC;
	Thu, 14 Feb 2013 03:19:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5pLo-0000x8-P1;
	Thu, 14 Feb 2013 03:19:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16170-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 14 Feb 2013 03:19:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16170: 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 16170 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16170/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 16161

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16161

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-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c43be17eec06
baseline version:
 xen                  63594ce1708f

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26530:c43be17eec06
tag:         tip
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 13 17:04:33 2013 +0000
    
    xen/flask: fix crash on debugkey "i"
    
    The IRQs beyond nr_static_irqs do not all have an associated PCI
    device, so only query the device SID if pci is not NULL.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26529:97b7e546e2e4
user:        Keir Fraser <keir@xen.org>
date:        Wed Feb 13 17:03:31 2013 +0000
    
    gcc4.8 build fix: Add -Wno-unused-local-typedefs to CFLAGS.
    
    Based on a patch by M A Young <m.a.young@durham.ac.uk>
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26528:742dde457258
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Wed Feb 13 17:00:15 2013 +0000
    
    tools: Fix memset(&p,0,sizeof(p)) idiom in several places.
    
    gcc 4.8 identifies several places where code of the form memset(x, 0,
    sizeof(x)); is used incorrectly, meaning that less memory is set to
    zero than required.
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26527:63594ce1708f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Feb 13 09:31:48 2013 +0100
    
    x86: fix map_domain_page() leak from vcpu_destroy_pagetables()
    
    Introduced by c/s 26450:4816763549e0 and exposed with
    26523:fd997a96d448.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Thu Feb 14 03:19:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 03: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 1U5pM1-0001eM-0p; Thu, 14 Feb 2013 03:19: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 1U5pLz-0001eH-13
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 03:19:19 +0000
Received: from [85.158.139.211:4447] by server-10.bemta-5.messagelabs.com id
	DC/5D-04697-6B75C115; Thu, 14 Feb 2013 03:19:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360811957!21316235!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNDkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7025 invoked from network); 14 Feb 2013 03:19:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 03:19:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,660,1355097600"; 
   d="scan'208";a="1442486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 03:19: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.297.1; Thu, 14 Feb 2013 03:19:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U5pLo-0003FO-WC;
	Thu, 14 Feb 2013 03:19:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U5pLo-0000x8-P1;
	Thu, 14 Feb 2013 03:19:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16170-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 14 Feb 2013 03:19:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16170: 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 16170 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16170/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 16161

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16161

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-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c43be17eec06
baseline version:
 xen                  63594ce1708f

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   26530:c43be17eec06
tag:         tip
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Wed Feb 13 17:04:33 2013 +0000
    
    xen/flask: fix crash on debugkey "i"
    
    The IRQs beyond nr_static_irqs do not all have an associated PCI
    device, so only query the device SID if pci is not NULL.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26529:97b7e546e2e4
user:        Keir Fraser <keir@xen.org>
date:        Wed Feb 13 17:03:31 2013 +0000
    
    gcc4.8 build fix: Add -Wno-unused-local-typedefs to CFLAGS.
    
    Based on a patch by M A Young <m.a.young@durham.ac.uk>
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26528:742dde457258
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Wed Feb 13 17:00:15 2013 +0000
    
    tools: Fix memset(&p,0,sizeof(p)) idiom in several places.
    
    gcc 4.8 identifies several places where code of the form memset(x, 0,
    sizeof(x)); is used incorrectly, meaning that less memory is set to
    zero than required.
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   26527:63594ce1708f
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Feb 13 09:31:48 2013 +0100
    
    x86: fix map_domain_page() leak from vcpu_destroy_pagetables()
    
    Introduced by c/s 26450:4816763549e0 and exposed with
    26523:fd997a96d448.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-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 Thu Feb 14 06:10:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 06:10: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 1U5s1J-0002oO-Sk; Thu, 14 Feb 2013 06:10:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1U5s1I-0002oJ-S1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 06:10:09 +0000
Received: from [193.109.254.147:56258] by server-14.bemta-14.messagelabs.com
	id 11/BF-02031-0CF7C115; Thu, 14 Feb 2013 06:10:08 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360822204!8668489!1
X-Originating-IP: [192.51.44.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM2ID0+IDIzNTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23796 invoked from network); 14 Feb 2013 06:10:06 -0000
Received: from fgwmail6.fujitsu.co.jp (HELO fgwmail6.fujitsu.co.jp)
	(192.51.44.36)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 06:10:06 -0000
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71])
	by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 7D1A53EE0B5
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:02 +0900 (JST)
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6638E45DE58
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:02 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 43EE345DE54
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:02 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2DF211DB8043
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:01 +0900 (JST)
Received: from g01jpexchkw10.g01.fujitsu.local
	(g01jpexchkw10.g01.fujitsu.local [10.0.194.49])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7CC591DB8051
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:00 +0900 (JST)
Received: from [10.33.110.237] (10.33.110.237) by
	g01jpexchkw10.g01.fujitsu.local (10.0.194.49) with Microsoft SMTP
	Server (TLS) id 14.2.309.2; Thu, 14 Feb 2013 15:10:00 +0900
Message-ID: <511C7FB7.90907@jp.fujitsu.com>
Date: Thu, 14 Feb 2013 15:09:59 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
	<511A42E902000078000BDB5E@nat28.tlf.novell.com>
In-Reply-To: <511A42E902000078000BDB5E@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------010909040807060703020204"
X-Originating-IP: [10.33.110.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010909040807060703020204
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

Thanks for reviewing the code.

On 02/12/2013 09:26 PM, Jan Beulich wrote:
>>>> On 05.02.13 at 07:12, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>> --- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
>> +++ b/xen/arch/x86/hvm/pmtimer.c	Tue Feb 05 10:26:13 2013 +0900
>> @@ -244,21 +247,34 @@ static int handle_pmt_io(
>> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
>> {
>>      PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>> -    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>> +    uint64_t guest_time;
>>      int rc;
>>
>>      spin_lock(&s->lock);
>>
>> -    /* Update the counter to the guest's current time.  We always save
>> -     * with the domain paused, so the saved time should be after the
>> -     * last_gtime, but just in case, make sure we only go forwards */
>> -    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>> -    if ( x < 1UL<<31 )
>> -        s->pm.tmr_val += x;
>> -    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>> -        s->pm.pm1a_sts |= TMR_STS;
>> -    /* No point in setting the SCI here because we'll already have saved the
>> -     * IRQ and *PIC state; we'll fix it up when we restore the domain */
>> +    guest_time = s->vcpu->arch.hvm_vcpu.guest_time;
>> +    /* Update the counter to the guest's current time only if the
>> +     * timer mode is delay_for_missed_ticks */
>> +    if ( guest_time != 0 )
>
> How is guest_time being (non-)zero an indication of mode being
> delay_for_missed_ticks? I think you should check for the mode
> explicitly, as the value here being zero can just be an effect of
> a large enough negative v->arch.hvm_vcpu.stime_offset.
>
> And besides that you don't explain why the update being done
> here is unnecessary in other modes - all you explain is that the
> way it's being done in those modes is wrong.

After due consideration, the update of PM-timer is necessary
for other modes. I misunderstood it's just an adjustment for
the delay_for_missed_ticks mode.
The cause of this bug is to refer the vcpu->arch.hvm_vcpu.guest_time.

Attached is the revised patch.

Aside from this patch, I've found another problem about
delay_for_missed_ticks.  PM-timer might be broken after
pmt_timer_callback is invoked.
I'll think it over.

Thanks,
Kouya


--------------010909040807060703020204
Content-Type: text/x-patch; name="fix_corrupt_saved_pmtimer_v2.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="fix_corrupt_saved_pmtimer_v2.patch"

# HG changeset patch
# User Kouya Shimura <kouya@jp.fujitsu.com>
# Date 1360820290 -32400
# Node ID 9744ac3f23dd198e997bf032385a573408420762
# Parent  5af4f2ab06f33ce441fa550333a9049c09a9ef28
x86/hvm: fix corrupt ACPI PM-Timer during live migration

ACPI PM-Timer value is broken on saving a VM.
Since c/s 16274:44dde35cb2a6, vcpu->arch.hvm_vcpu.guest_time is not
the correct guest's time any more.
Instead, hvm_get_guest_time() should be used in pmtimer_save to calculate
the timer.

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

diff -r 5af4f2ab06f3 -r 9744ac3f23dd xen/arch/x86/hvm/pmtimer.c
--- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
+++ b/xen/arch/x86/hvm/pmtimer.c	Thu Feb 14 14:38:10 2013 +0900
@@ -85,7 +85,7 @@ void hvm_acpi_sleep_button(struct domain
 
 /* Set the correct value in the timer, accounting for time elapsed
  * since the last time we did that. */
-static void pmt_update_time(PMTState *s)
+static void pmt_update_time(PMTState *s, bool_t update_sci)
 {
     uint64_t curr_gtime, tmp;
     uint32_t tmr_val = s->pm.tmr_val, msb = tmr_val & TMR_VAL_MSB;
@@ -107,7 +107,8 @@ static void pmt_update_time(PMTState *s)
     if ( (tmr_val & TMR_VAL_MSB) != msb )
     {
         s->pm.pm1a_sts |= TMR_STS;
-        pmt_update_sci(s);
+        if ( update_sci )
+            pmt_update_sci(s);
     }
 }
 
@@ -123,7 +124,7 @@ static void pmt_timer_callback(void *opa
     spin_lock(&s->lock);
 
     /* Recalculate the timer and make sure we get an SCI if we need one */
-    pmt_update_time(s);
+    pmt_update_time(s, 1);
 
     /* How close are we to the next MSB flip? */
     pmt_cycles_until_flip = TMR_VAL_MSB - (s->pm.tmr_val & (TMR_VAL_MSB - 1));
@@ -221,7 +222,7 @@ static int handle_pmt_io(
         if ( spin_trylock(&s->lock) )
         {
             /* We hold the lock: update timer value and return it. */
-            pmt_update_time(s);
+            pmt_update_time(s, 1);
             *val = s->pm.tmr_val;
             spin_unlock(&s->lock);
         }
@@ -244,21 +245,13 @@ static int handle_pmt_io(
 static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
 {
     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
     int rc;
 
     spin_lock(&s->lock);
 
-    /* Update the counter to the guest's current time.  We always save
-     * with the domain paused, so the saved time should be after the
-     * last_gtime, but just in case, make sure we only go forwards */
-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
-    if ( x < 1UL<<31 )
-        s->pm.tmr_val += x;
-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
-        s->pm.pm1a_sts |= TMR_STS;
     /* No point in setting the SCI here because we'll already have saved the 
      * IRQ and *PIC state; we'll fix it up when we restore the domain */
+    pmt_update_time(s, 0);
 
     rc = hvm_save_entry(PMTIMER, 0, h, &s->pm);
 

--------------010909040807060703020204
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010909040807060703020204--


From xen-devel-bounces@lists.xen.org Thu Feb 14 06:10:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 06:10: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 1U5s1J-0002oO-Sk; Thu, 14 Feb 2013 06:10:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1U5s1I-0002oJ-S1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 06:10:09 +0000
Received: from [193.109.254.147:56258] by server-14.bemta-14.messagelabs.com
	id 11/BF-02031-0CF7C115; Thu, 14 Feb 2013 06:10:08 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360822204!8668489!1
X-Originating-IP: [192.51.44.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM2ID0+IDIzNTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23796 invoked from network); 14 Feb 2013 06:10:06 -0000
Received: from fgwmail6.fujitsu.co.jp (HELO fgwmail6.fujitsu.co.jp)
	(192.51.44.36)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 06:10:06 -0000
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71])
	by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 7D1A53EE0B5
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:02 +0900 (JST)
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6638E45DE58
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:02 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 43EE345DE54
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:02 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2DF211DB8043
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:01 +0900 (JST)
Received: from g01jpexchkw10.g01.fujitsu.local
	(g01jpexchkw10.g01.fujitsu.local [10.0.194.49])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7CC591DB8051
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 15:10:00 +0900 (JST)
Received: from [10.33.110.237] (10.33.110.237) by
	g01jpexchkw10.g01.fujitsu.local (10.0.194.49) with Microsoft SMTP
	Server (TLS) id 14.2.309.2; Thu, 14 Feb 2013 15:10:00 +0900
Message-ID: <511C7FB7.90907@jp.fujitsu.com>
Date: Thu, 14 Feb 2013 15:09:59 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
	<511A42E902000078000BDB5E@nat28.tlf.novell.com>
In-Reply-To: <511A42E902000078000BDB5E@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------010909040807060703020204"
X-Originating-IP: [10.33.110.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010909040807060703020204
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

Thanks for reviewing the code.

On 02/12/2013 09:26 PM, Jan Beulich wrote:
>>>> On 05.02.13 at 07:12, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>> --- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
>> +++ b/xen/arch/x86/hvm/pmtimer.c	Tue Feb 05 10:26:13 2013 +0900
>> @@ -244,21 +247,34 @@ static int handle_pmt_io(
>> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
>> {
>>      PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>> -    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>> +    uint64_t guest_time;
>>      int rc;
>>
>>      spin_lock(&s->lock);
>>
>> -    /* Update the counter to the guest's current time.  We always save
>> -     * with the domain paused, so the saved time should be after the
>> -     * last_gtime, but just in case, make sure we only go forwards */
>> -    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>> -    if ( x < 1UL<<31 )
>> -        s->pm.tmr_val += x;
>> -    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>> -        s->pm.pm1a_sts |= TMR_STS;
>> -    /* No point in setting the SCI here because we'll already have saved the
>> -     * IRQ and *PIC state; we'll fix it up when we restore the domain */
>> +    guest_time = s->vcpu->arch.hvm_vcpu.guest_time;
>> +    /* Update the counter to the guest's current time only if the
>> +     * timer mode is delay_for_missed_ticks */
>> +    if ( guest_time != 0 )
>
> How is guest_time being (non-)zero an indication of mode being
> delay_for_missed_ticks? I think you should check for the mode
> explicitly, as the value here being zero can just be an effect of
> a large enough negative v->arch.hvm_vcpu.stime_offset.
>
> And besides that you don't explain why the update being done
> here is unnecessary in other modes - all you explain is that the
> way it's being done in those modes is wrong.

After due consideration, the update of PM-timer is necessary
for other modes. I misunderstood it's just an adjustment for
the delay_for_missed_ticks mode.
The cause of this bug is to refer the vcpu->arch.hvm_vcpu.guest_time.

Attached is the revised patch.

Aside from this patch, I've found another problem about
delay_for_missed_ticks.  PM-timer might be broken after
pmt_timer_callback is invoked.
I'll think it over.

Thanks,
Kouya


--------------010909040807060703020204
Content-Type: text/x-patch; name="fix_corrupt_saved_pmtimer_v2.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="fix_corrupt_saved_pmtimer_v2.patch"

# HG changeset patch
# User Kouya Shimura <kouya@jp.fujitsu.com>
# Date 1360820290 -32400
# Node ID 9744ac3f23dd198e997bf032385a573408420762
# Parent  5af4f2ab06f33ce441fa550333a9049c09a9ef28
x86/hvm: fix corrupt ACPI PM-Timer during live migration

ACPI PM-Timer value is broken on saving a VM.
Since c/s 16274:44dde35cb2a6, vcpu->arch.hvm_vcpu.guest_time is not
the correct guest's time any more.
Instead, hvm_get_guest_time() should be used in pmtimer_save to calculate
the timer.

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

diff -r 5af4f2ab06f3 -r 9744ac3f23dd xen/arch/x86/hvm/pmtimer.c
--- a/xen/arch/x86/hvm/pmtimer.c	Tue Jan 22 09:33:10 2013 +0100
+++ b/xen/arch/x86/hvm/pmtimer.c	Thu Feb 14 14:38:10 2013 +0900
@@ -85,7 +85,7 @@ void hvm_acpi_sleep_button(struct domain
 
 /* Set the correct value in the timer, accounting for time elapsed
  * since the last time we did that. */
-static void pmt_update_time(PMTState *s)
+static void pmt_update_time(PMTState *s, bool_t update_sci)
 {
     uint64_t curr_gtime, tmp;
     uint32_t tmr_val = s->pm.tmr_val, msb = tmr_val & TMR_VAL_MSB;
@@ -107,7 +107,8 @@ static void pmt_update_time(PMTState *s)
     if ( (tmr_val & TMR_VAL_MSB) != msb )
     {
         s->pm.pm1a_sts |= TMR_STS;
-        pmt_update_sci(s);
+        if ( update_sci )
+            pmt_update_sci(s);
     }
 }
 
@@ -123,7 +124,7 @@ static void pmt_timer_callback(void *opa
     spin_lock(&s->lock);
 
     /* Recalculate the timer and make sure we get an SCI if we need one */
-    pmt_update_time(s);
+    pmt_update_time(s, 1);
 
     /* How close are we to the next MSB flip? */
     pmt_cycles_until_flip = TMR_VAL_MSB - (s->pm.tmr_val & (TMR_VAL_MSB - 1));
@@ -221,7 +222,7 @@ static int handle_pmt_io(
         if ( spin_trylock(&s->lock) )
         {
             /* We hold the lock: update timer value and return it. */
-            pmt_update_time(s);
+            pmt_update_time(s, 1);
             *val = s->pm.tmr_val;
             spin_unlock(&s->lock);
         }
@@ -244,21 +245,13 @@ static int handle_pmt_io(
 static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
 {
     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
     int rc;
 
     spin_lock(&s->lock);
 
-    /* Update the counter to the guest's current time.  We always save
-     * with the domain paused, so the saved time should be after the
-     * last_gtime, but just in case, make sure we only go forwards */
-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
-    if ( x < 1UL<<31 )
-        s->pm.tmr_val += x;
-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
-        s->pm.pm1a_sts |= TMR_STS;
     /* No point in setting the SCI here because we'll already have saved the 
      * IRQ and *PIC state; we'll fix it up when we restore the domain */
+    pmt_update_time(s, 0);
 
     rc = hvm_save_entry(PMTIMER, 0, h, &s->pm);
 

--------------010909040807060703020204
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010909040807060703020204--


From xen-devel-bounces@lists.xen.org Thu Feb 14 09:12:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 09: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 1U5uqa-0004OI-9n; Thu, 14 Feb 2013 09:11:16 +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 1U5uqY-0004OD-TH
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 09:11:15 +0000
Received: from [85.158.139.83:54885] by server-14.bemta-5.messagelabs.com id
	C6/B2-06967-13AAC115; Thu, 14 Feb 2013 09:11:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360833054!20961783!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16895 invoked from network); 14 Feb 2013 09:10:55 -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; 14 Feb 2013 09:10:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 09:10:54 +0000
Message-Id: <511CB86702000078000BE1C5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 09:11:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <dvrabel@cantab.net>,
 "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
In-Reply-To: <20130213201725.GA1453@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13.02.13 at 21:17, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
>> On 13/02/13 18:37, Wei Liu wrote:
>> > A slightly upgraded version of the *UNTESTED* patch.
>> > 
>> > 
>> > Wei.
>> > 
>> > ----8<----
>> > commit df4c929d034cec7043fbd96ba89833eb639c336e
>> > Author: Wei Liu <wei.liu2@citrix.com>
>> > Date:   Wed Feb 13 18:17:01 2013 +0000
>> > 
>> >     netback: fix netbk_count_requests
>> >     
>> >     There are two paths in the original code, a) test against work_to_do, 
> b) test
>> >     against first->size, could return 0 even when error happens.
>> >     
>> >     Simply return -1 in error paths should work. Modify all error paths to 
> return
>> >     -1 to be consistent.
>> 
>> You also need to remove the netbk_tx_err() after checking the result of
>> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
>> which will screw up ref counting.
> 
> I just realized that we were talking about different code path when I
> walked home.
> 
> The path you mentioned is correct. As excution flow should never reach
> there if there is error in netbk_count_requests.
> 
> The path I'm not sure is that in the netbk_fatal_tx_err, it calls
> xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
> which is likely to mess up the refcount.

I first thought so too when looking at this again yesterday, but
then convinced myself that this double put _here_ is correct. And
Ian's patch specifically removed to call to netbk_tx_err() after the
caller netbk_count_requests() recognized the error, knowing that
the latter function now itself issues a call to netbk_fatal_tx_err()
(whether that wouldn't better have replaced the caller's call to
netbk_tx_err() is a different question).

What I do support is that fact that the third error path in
netbk_count_requests() has the potential of returning zero
instead of a negative value. As the caller doesn't really do
anything with the specific negative value (it only did so before
Ian's patch), returning -1 or -EINVAL on all four error paths
would seem the right change to me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 09:12:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 09: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 1U5uqa-0004OI-9n; Thu, 14 Feb 2013 09:11:16 +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 1U5uqY-0004OD-TH
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 09:11:15 +0000
Received: from [85.158.139.83:54885] by server-14.bemta-5.messagelabs.com id
	C6/B2-06967-13AAC115; Thu, 14 Feb 2013 09:11:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360833054!20961783!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16895 invoked from network); 14 Feb 2013 09:10:55 -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; 14 Feb 2013 09:10:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 09:10:54 +0000
Message-Id: <511CB86702000078000BE1C5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 09:11:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <dvrabel@cantab.net>,
 "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
In-Reply-To: <20130213201725.GA1453@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13.02.13 at 21:17, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
>> On 13/02/13 18:37, Wei Liu wrote:
>> > A slightly upgraded version of the *UNTESTED* patch.
>> > 
>> > 
>> > Wei.
>> > 
>> > ----8<----
>> > commit df4c929d034cec7043fbd96ba89833eb639c336e
>> > Author: Wei Liu <wei.liu2@citrix.com>
>> > Date:   Wed Feb 13 18:17:01 2013 +0000
>> > 
>> >     netback: fix netbk_count_requests
>> >     
>> >     There are two paths in the original code, a) test against work_to_do, 
> b) test
>> >     against first->size, could return 0 even when error happens.
>> >     
>> >     Simply return -1 in error paths should work. Modify all error paths to 
> return
>> >     -1 to be consistent.
>> 
>> You also need to remove the netbk_tx_err() after checking the result of
>> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
>> which will screw up ref counting.
> 
> I just realized that we were talking about different code path when I
> walked home.
> 
> The path you mentioned is correct. As excution flow should never reach
> there if there is error in netbk_count_requests.
> 
> The path I'm not sure is that in the netbk_fatal_tx_err, it calls
> xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
> which is likely to mess up the refcount.

I first thought so too when looking at this again yesterday, but
then convinced myself that this double put _here_ is correct. And
Ian's patch specifically removed to call to netbk_tx_err() after the
caller netbk_count_requests() recognized the error, knowing that
the latter function now itself issues a call to netbk_fatal_tx_err()
(whether that wouldn't better have replaced the caller's call to
netbk_tx_err() is a different question).

What I do support is that fact that the third error path in
netbk_count_requests() has the potential of returning zero
instead of a negative value. As the caller doesn't really do
anything with the specific negative value (it only did so before
Ian's patch), returning -1 or -EINVAL on all four error paths
would seem the right change to me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 09:13:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 09:13: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 1U5usb-0004SX-Rc; Thu, 14 Feb 2013 09:13:21 +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 1U5usa-0004SP-Gi
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 09:13:20 +0000
Received: from [85.158.139.83:8794] by server-12.bemta-5.messagelabs.com id
	AB/17-20195-FAAAC115; Thu, 14 Feb 2013 09:13:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360833198!23598383!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24204 invoked from network); 14 Feb 2013 09:13:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 09:13:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 09:13:18 +0000
Message-Id: <511CB8F902000078000BE1CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 09:14:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <wei.liu2@citrix.com>,"Christopher S. Aker" <caker@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
In-Reply-To: <1360780669.16636.94.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13.02.13 at 19:37, Wei Liu <wei.liu2@citrix.com> wrote:
> A slightly upgraded version of the *UNTESTED* patch.

Ack (albeit I'd slightly prefer -EINVAL or, for eventual debugging
purposes, four distinct -Exxx values to be returned).

Jan

> ----8<----
> commit df4c929d034cec7043fbd96ba89833eb639c336e
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Wed Feb 13 18:17:01 2013 +0000
> 
>     netback: fix netbk_count_requests
>     
>     There are two paths in the original code, a) test against work_to_do, b) 
> test
>     against first->size, could return 0 even when error happens.
>     
>     Simply return -1 in error paths should work. Modify all error paths to 
> return
>     -1 to be consistent.
>     
>     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index 103294d..0e0162e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (frags >= work_to_do) {
>  			netdev_err(vif->dev, "Need more frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
>  			netdev_err(vif->dev, "Too many frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (txp->size > first->size) {
>  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		first->size -= txp->size;
> @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
>  				 txp->offset, txp->size);
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  	} while ((txp++)->flags & XEN_NETTXF_more_data);
>  	return frags;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 14 09:13:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 09:13: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 1U5usb-0004SX-Rc; Thu, 14 Feb 2013 09:13:21 +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 1U5usa-0004SP-Gi
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 09:13:20 +0000
Received: from [85.158.139.83:8794] by server-12.bemta-5.messagelabs.com id
	AB/17-20195-FAAAC115; Thu, 14 Feb 2013 09:13:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360833198!23598383!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24204 invoked from network); 14 Feb 2013 09:13:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 09:13:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 09:13:18 +0000
Message-Id: <511CB8F902000078000BE1CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 09:14:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <wei.liu2@citrix.com>,"Christopher S. Aker" <caker@theshore.net>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
In-Reply-To: <1360780669.16636.94.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 13.02.13 at 19:37, Wei Liu <wei.liu2@citrix.com> wrote:
> A slightly upgraded version of the *UNTESTED* patch.

Ack (albeit I'd slightly prefer -EINVAL or, for eventual debugging
purposes, four distinct -Exxx values to be returned).

Jan

> ----8<----
> commit df4c929d034cec7043fbd96ba89833eb639c336e
> Author: Wei Liu <wei.liu2@citrix.com>
> Date:   Wed Feb 13 18:17:01 2013 +0000
> 
>     netback: fix netbk_count_requests
>     
>     There are two paths in the original code, a) test against work_to_do, b) 
> test
>     against first->size, could return 0 even when error happens.
>     
>     Simply return -1 in error paths should work. Modify all error paths to 
> return
>     -1 to be consistent.
>     
>     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index 103294d..0e0162e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (frags >= work_to_do) {
>  			netdev_err(vif->dev, "Need more frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
>  			netdev_err(vif->dev, "Too many frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (txp->size > first->size) {
>  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  
>  		first->size -= txp->size;
> @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
>  				 txp->offset, txp->size);
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -1;
>  		}
>  	} while ((txp++)->flags & XEN_NETTXF_more_data);
>  	return frags;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Feb 14 09:25:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 09:25: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 1U5v3b-0004iJ-8I; Thu, 14 Feb 2013 09:24: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 1U5v3Z-0004iE-1m
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 09:24:41 +0000
Received: from [85.158.137.99:65347] by server-9.bemta-3.messagelabs.com id
	8A/B6-09484-85DAC115; Thu, 14 Feb 2013 09:24:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360833878!20555341!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18260 invoked from network); 14 Feb 2013 09:24:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 09:24:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 09:24:37 +0000
Message-Id: <511CBB9E02000078000BE1DE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 09:25:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511CB8F902000078000BE1CC@nat28.tlf.novell.com>
In-Reply-To: <511CB8F902000078000BE1CC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1626569E.1__="
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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>
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.

--=__Part1626569E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 14.02.13 at 10:14, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 13.02.13 at 19:37, Wei Liu <wei.liu2@citrix.com> wrote:
>> A slightly upgraded version of the *UNTESTED* patch.
>=20
> Ack (albeit I'd slightly prefer -EINVAL or, for eventual debugging
> purposes, four distinct -Exxx values to be returned).

Like this (for the 2.6.18-xen tree).

Jan

netback: fix netbk_count_requests()
   =20
There are two paths in the original code, a) test against work_to_do, b) =
test
against first->size, could return 0 even when error happens.
   =20
Simply return -1 in error paths should work. Modify all error paths to =
return
-1 to be consistent.
   =20
Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Use distinct -E... values instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -1042,14 +1042,14 @@ static int netbk_count_requests(netif_t=20
 			printk(KERN_ERR "%s: Need more frags\n",
 			       netif->dev->name);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -ENODATA;
 		}
=20
 		if (unlikely(frags >=3D MAX_SKB_FRAGS)) {
 			printk(KERN_ERR "%s: Too many frags\n",
 			       netif->dev->name);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -E2BIG;
 		}
=20
 		memcpy(txp, RING_GET_REQUEST(&netif->tx, cons + frags),
@@ -1058,7 +1058,7 @@ static int netbk_count_requests(netif_t=20
 			printk(KERN_ERR "%s: Frag is bigger than frame.\n",=

 			       netif->dev->name);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -EIO;
 		}
=20
 		first->size -=3D txp->size;
@@ -1068,7 +1068,7 @@ static int netbk_count_requests(netif_t=20
 			printk(KERN_ERR "%s: txp->offset: %x, size: %u\n",
 			       netif->dev->name, txp->offset, txp->size);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -EINVAL;
 		}
 	} while ((txp++)->flags & NETTXF_more_data);
=20




--=__Part1626569E.1__=
Content-Type: text/plain; name="xen-netback-count-requests-result.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-netback-count-requests-result.patch"

netback: fix netbk_count_requests()=0A    =0AThere are two paths in the =
original code, a) test against work_to_do, b) test=0Aagainst first->size, =
could return 0 even when error happens.=0A    =0ASimply return -1 in error =
paths should work. Modify all error paths to return=0A-1 to be consistent.=
=0A    =0ASigned-off-by: Wei Liu <wei.liu2@citrix.com>=0A=0AUse distinct =
-E... values instead.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/drivers/xen/netback/netback.c=0A+++ b/drivers/xen/netback/netba=
ck.c=0A@@ -1042,14 +1042,14 @@ static int netbk_count_requests(netif_t =0A =
			printk(KERN_ERR "%s: Need more frags\n",=0A 		=
	       netif->dev->name);=0A 			netbk_fatal_tx_err(=
netif);=0A-			return -frags;=0A+			=
return -ENODATA;=0A 		}=0A =0A 		if (unlikely(frags =
>=3D MAX_SKB_FRAGS)) {=0A 			printk(KERN_ERR "%s: Too =
many frags\n",=0A 			       netif->dev->name);=0A 		=
	netbk_fatal_tx_err(netif);=0A-			return -frags;=0A+	=
		return -E2BIG;=0A 		}=0A =0A 		=
memcpy(txp, RING_GET_REQUEST(&netif->tx, cons + frags),=0A@@ -1058,7 =
+1058,7 @@ static int netbk_count_requests(netif_t =0A 			=
printk(KERN_ERR "%s: Frag is bigger than frame.\n",=0A 			   =
    netif->dev->name);=0A 			netbk_fatal_tx_err(netif);=
=0A-			return -frags;=0A+			return =
-EIO;=0A 		}=0A =0A 		first->size -=3D txp->size;=
=0A@@ -1068,7 +1068,7 @@ static int netbk_count_requests(netif_t =0A 		=
	printk(KERN_ERR "%s: txp->offset: %x, size: %u\n",=0A 			=
       netif->dev->name, txp->offset, txp->size);=0A 			=
netbk_fatal_tx_err(netif);=0A-			return -frags;=0A+		=
	return -EINVAL;=0A 		}=0A 	} while ((txp++)->flags & =
NETTXF_more_data);=0A =0A
--=__Part1626569E.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

--=__Part1626569E.1__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 09:25:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 09:25: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 1U5v3b-0004iJ-8I; Thu, 14 Feb 2013 09:24: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 1U5v3Z-0004iE-1m
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 09:24:41 +0000
Received: from [85.158.137.99:65347] by server-9.bemta-3.messagelabs.com id
	8A/B6-09484-85DAC115; Thu, 14 Feb 2013 09:24:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360833878!20555341!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18260 invoked from network); 14 Feb 2013 09:24:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 09:24:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 09:24:37 +0000
Message-Id: <511CBB9E02000078000BE1DE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 09:25:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511CB8F902000078000BE1CC@nat28.tlf.novell.com>
In-Reply-To: <511CB8F902000078000BE1CC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1626569E.1__="
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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>
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.

--=__Part1626569E.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 14.02.13 at 10:14, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 13.02.13 at 19:37, Wei Liu <wei.liu2@citrix.com> wrote:
>> A slightly upgraded version of the *UNTESTED* patch.
>=20
> Ack (albeit I'd slightly prefer -EINVAL or, for eventual debugging
> purposes, four distinct -Exxx values to be returned).

Like this (for the 2.6.18-xen tree).

Jan

netback: fix netbk_count_requests()
   =20
There are two paths in the original code, a) test against work_to_do, b) =
test
against first->size, could return 0 even when error happens.
   =20
Simply return -1 in error paths should work. Modify all error paths to =
return
-1 to be consistent.
   =20
Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Use distinct -E... values instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -1042,14 +1042,14 @@ static int netbk_count_requests(netif_t=20
 			printk(KERN_ERR "%s: Need more frags\n",
 			       netif->dev->name);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -ENODATA;
 		}
=20
 		if (unlikely(frags >=3D MAX_SKB_FRAGS)) {
 			printk(KERN_ERR "%s: Too many frags\n",
 			       netif->dev->name);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -E2BIG;
 		}
=20
 		memcpy(txp, RING_GET_REQUEST(&netif->tx, cons + frags),
@@ -1058,7 +1058,7 @@ static int netbk_count_requests(netif_t=20
 			printk(KERN_ERR "%s: Frag is bigger than frame.\n",=

 			       netif->dev->name);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -EIO;
 		}
=20
 		first->size -=3D txp->size;
@@ -1068,7 +1068,7 @@ static int netbk_count_requests(netif_t=20
 			printk(KERN_ERR "%s: txp->offset: %x, size: %u\n",
 			       netif->dev->name, txp->offset, txp->size);
 			netbk_fatal_tx_err(netif);
-			return -frags;
+			return -EINVAL;
 		}
 	} while ((txp++)->flags & NETTXF_more_data);
=20




--=__Part1626569E.1__=
Content-Type: text/plain; name="xen-netback-count-requests-result.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-netback-count-requests-result.patch"

netback: fix netbk_count_requests()=0A    =0AThere are two paths in the =
original code, a) test against work_to_do, b) test=0Aagainst first->size, =
could return 0 even when error happens.=0A    =0ASimply return -1 in error =
paths should work. Modify all error paths to return=0A-1 to be consistent.=
=0A    =0ASigned-off-by: Wei Liu <wei.liu2@citrix.com>=0A=0AUse distinct =
-E... values instead.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/drivers/xen/netback/netback.c=0A+++ b/drivers/xen/netback/netba=
ck.c=0A@@ -1042,14 +1042,14 @@ static int netbk_count_requests(netif_t =0A =
			printk(KERN_ERR "%s: Need more frags\n",=0A 		=
	       netif->dev->name);=0A 			netbk_fatal_tx_err(=
netif);=0A-			return -frags;=0A+			=
return -ENODATA;=0A 		}=0A =0A 		if (unlikely(frags =
>=3D MAX_SKB_FRAGS)) {=0A 			printk(KERN_ERR "%s: Too =
many frags\n",=0A 			       netif->dev->name);=0A 		=
	netbk_fatal_tx_err(netif);=0A-			return -frags;=0A+	=
		return -E2BIG;=0A 		}=0A =0A 		=
memcpy(txp, RING_GET_REQUEST(&netif->tx, cons + frags),=0A@@ -1058,7 =
+1058,7 @@ static int netbk_count_requests(netif_t =0A 			=
printk(KERN_ERR "%s: Frag is bigger than frame.\n",=0A 			   =
    netif->dev->name);=0A 			netbk_fatal_tx_err(netif);=
=0A-			return -frags;=0A+			return =
-EIO;=0A 		}=0A =0A 		first->size -=3D txp->size;=
=0A@@ -1068,7 +1068,7 @@ static int netbk_count_requests(netif_t =0A 		=
	printk(KERN_ERR "%s: txp->offset: %x, size: %u\n",=0A 			=
       netif->dev->name, txp->offset, txp->size);=0A 			=
netbk_fatal_tx_err(netif);=0A-			return -frags;=0A+		=
	return -EINVAL;=0A 		}=0A 	} while ((txp++)->flags & =
NETTXF_more_data);=0A =0A
--=__Part1626569E.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

--=__Part1626569E.1__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 10:02:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10:02: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 1U5ve2-000541-Gw; Thu, 14 Feb 2013 10:02: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 1U5ve0-00053w-UK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:02:21 +0000
Received: from [85.158.138.51:11853] by server-9.bemta-3.messagelabs.com id
	73/91-09484-3C5BC115; Thu, 14 Feb 2013 10:00:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360836034!19439609!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12230 invoked from network); 14 Feb 2013 10:00:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1451378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:00: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.297.1;
	Thu, 14 Feb 2013 10:00:34 +0000
Message-ID: <1360836032.20449.307.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 10:00:32 +0000
In-Reply-To: <5113776602000078000BCB8F@nat28.tlf.novell.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 Thu, 2013-02-07 at 08:44 +0000, Jan Beulich wrote:
> >>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> > This adds two new physdev operations for Dom0 to invoke when resource
> > allocation for devices is known to be complete, so that the hypervisor
> > can arrange for the respective MMIO ranges to be marked read-only
> > before an eventual guest getting such a device assigned even gets
> > started, such that it won't be able to set up writable mappings for
> > these MMIO ranges before Xen has a chance to protect them.

This sounds reasonable, is the "when resource allocation ... complete"
difficult to assess or likely to be fragile going forward?

> I should probably mention the alternatives:
> 
> 1) Brute force scan of the (PV) guest's L1 page tables, locating
> eventual mappings of the questionable MMIO pages, and
> converting those mappings to R/O ones.

When would this occur? Just on setup (might be ok) or on any MMU update
(clearly not) or some middle ground (like only DOMID_IO mappings
perhaps)?

> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
> guest_io_write(), taking note of which BAR(s) are relevant at the
> point where the device gets first detected/reported), perhaps
> along with snoops of the PCI_COMMAND_MEMORY bit.

Do these modifications come straight from the guest, or do they come
from dom0 via pciback and/or dom0's own PCI subsystem setup? If these
are coming via pciback then it seems reasonable to me to use physdev
operations, which takes us back to the patch you've implemented I think.

Trapping and emulating them sounds like something to avoid even if these
are not especially hot paths.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:02:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10:02: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 1U5ve2-000541-Gw; Thu, 14 Feb 2013 10:02: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 1U5ve0-00053w-UK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:02:21 +0000
Received: from [85.158.138.51:11853] by server-9.bemta-3.messagelabs.com id
	73/91-09484-3C5BC115; Thu, 14 Feb 2013 10:00:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360836034!19439609!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12230 invoked from network); 14 Feb 2013 10:00:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1451378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:00: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.297.1;
	Thu, 14 Feb 2013 10:00:34 +0000
Message-ID: <1360836032.20449.307.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 10:00:32 +0000
In-Reply-To: <5113776602000078000BCB8F@nat28.tlf.novell.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 Thu, 2013-02-07 at 08:44 +0000, Jan Beulich wrote:
> >>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
> > This adds two new physdev operations for Dom0 to invoke when resource
> > allocation for devices is known to be complete, so that the hypervisor
> > can arrange for the respective MMIO ranges to be marked read-only
> > before an eventual guest getting such a device assigned even gets
> > started, such that it won't be able to set up writable mappings for
> > these MMIO ranges before Xen has a chance to protect them.

This sounds reasonable, is the "when resource allocation ... complete"
difficult to assess or likely to be fragile going forward?

> I should probably mention the alternatives:
> 
> 1) Brute force scan of the (PV) guest's L1 page tables, locating
> eventual mappings of the questionable MMIO pages, and
> converting those mappings to R/O ones.

When would this occur? Just on setup (might be ok) or on any MMU update
(clearly not) or some middle ground (like only DOMID_IO mappings
perhaps)?

> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
> guest_io_write(), taking note of which BAR(s) are relevant at the
> point where the device gets first detected/reported), perhaps
> along with snoops of the PCI_COMMAND_MEMORY bit.

Do these modifications come straight from the guest, or do they come
from dom0 via pciback and/or dom0's own PCI subsystem setup? If these
are coming via pciback then it seems reasonable to me to use physdev
operations, which takes us back to the patch you've implemented I think.

Trapping and emulating them sounds like something to avoid even if these
are not especially hot paths.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:17:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10: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 1U5vqt-0005SL-M4; Thu, 14 Feb 2013 10:15:39 +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 1U5vqs-0005SG-2T
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:15:38 +0000
Received: from [85.158.139.83:4342] by server-4.bemta-5.messagelabs.com id
	20/F0-29496-949BC115; Thu, 14 Feb 2013 10:15:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360836936!27058796!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24664 invoked from network); 14 Feb 2013 10:15:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:15:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1452298"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:15:37 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 14 Feb 2013 10:15:36 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 14 Feb 2013 11:12:09 +0100
Message-ID: <1360836729-17874-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: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen-blkback: use balloon pages for persistent
	grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

V2l0aCBjdXJyZW50IHBlcnNpc3RlbnQgZ3JhbnRzIGltcGxlbWVudGF0aW9uIHdlIGFyZSBub3Qg
ZnJlZWluZyB0aGUKcGVyc2lzdGVudCBncmFudHMgYWZ0ZXIgd2UgZGlzY29ubmVjdCB0aGUgZGV2
aWNlLiBTaW5jZSBncmFudCBtYXAKb3BlcmF0aW9ucyBjaGFuZ2UgdGhlIG1mbiBvZiB0aGUgYWxs
b2NhdGVkIHBhZ2UsIGFuZCB3ZSBjYW4gbm8gbG9uZ2VyCnBhc3MgaXQgdG8gX19mcmVlX3BhZ2Ug
d2l0aG91dCBzZXR0aW5nIHRoZSBtZm4gdG8gYSBzYW5lIHZhbHVlLCB1c2UKYmFsbG9vbiBncmFu
dCBwYWdlcyBpbnN0ZWFkLCBhcyB0aGUgZ250ZGV2IGRldmljZSBkb2VzLgoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiB4ZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFj
bGUuY29tPgotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgICAgNiAr
KysrLS0KIDEgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoK
ZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIGIvZHJpdmVy
cy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKaW5kZXggYzQ2ODI0Zi4uZTZjMmY2YSAxMDA2
NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKKysrIGIvZHJpdmVy
cy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKQEAgLTQ2LDYgKzQ2LDcgQEAKICNpbmNsdWRl
IDx4ZW4veGVuLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CiAjaW5jbHVkZSA8
YXNtL3hlbi9oeXBlcmNhbGwuaD4KKyNpbmNsdWRlIDx4ZW4vYmFsbG9vbi5oPgogI2luY2x1ZGUg
ImNvbW1vbi5oIgogCiAvKgpAQCAtMjM5LDYgKzI0MCw3IEBAIHN0YXRpYyB2b2lkIGZyZWVfcGVy
c2lzdGVudF9nbnRzKHN0cnVjdCByYl9yb290ICpyb290LCB1bnNpZ25lZCBpbnQgbnVtKQogCQkJ
cmV0ID0gZ250dGFiX3VubWFwX3JlZnModW5tYXAsIE5VTEwsIHBhZ2VzLAogCQkJCXNlZ3NfdG9f
dW5tYXApOwogCQkJQlVHX09OKHJldCk7CisJCQlmcmVlX3hlbmJhbGxvb25lZF9wYWdlcyhzZWdz
X3RvX3VubWFwLCBwYWdlcyk7CiAJCQlzZWdzX3RvX3VubWFwID0gMDsKIAkJfQogCkBAIC01Mjcs
OCArNTI5LDggQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0
ICpyZXEsCiAJCQkJR0ZQX0tFUk5FTCk7CiAJCQlpZiAoIXBlcnNpc3RlbnRfZ250KQogCQkJCXJl
dHVybiAtRU5PTUVNOwotCQkJcGVyc2lzdGVudF9nbnQtPnBhZ2UgPSBhbGxvY19wYWdlKEdGUF9L
RVJORUwpOwotCQkJaWYgKCFwZXJzaXN0ZW50X2dudC0+cGFnZSkgeworCQkJaWYgKGFsbG9jX3hl
bmJhbGxvb25lZF9wYWdlcygxLCAmcGVyc2lzdGVudF9nbnQtPnBhZ2UsCisJCQkgICAgZmFsc2Up
KSB7CiAJCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOwogCQkJCXJldHVybiAtRU5PTUVNOwogCQkJ
fQotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:17:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10: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 1U5vqt-0005SL-M4; Thu, 14 Feb 2013 10:15:39 +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 1U5vqs-0005SG-2T
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:15:38 +0000
Received: from [85.158.139.83:4342] by server-4.bemta-5.messagelabs.com id
	20/F0-29496-949BC115; Thu, 14 Feb 2013 10:15:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360836936!27058796!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24664 invoked from network); 14 Feb 2013 10:15:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:15:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1452298"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:15:37 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 14 Feb 2013 10:15:36 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Thu, 14 Feb 2013 11:12:09 +0100
Message-ID: <1360836729-17874-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: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen-blkback: use balloon pages for persistent
	grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

V2l0aCBjdXJyZW50IHBlcnNpc3RlbnQgZ3JhbnRzIGltcGxlbWVudGF0aW9uIHdlIGFyZSBub3Qg
ZnJlZWluZyB0aGUKcGVyc2lzdGVudCBncmFudHMgYWZ0ZXIgd2UgZGlzY29ubmVjdCB0aGUgZGV2
aWNlLiBTaW5jZSBncmFudCBtYXAKb3BlcmF0aW9ucyBjaGFuZ2UgdGhlIG1mbiBvZiB0aGUgYWxs
b2NhdGVkIHBhZ2UsIGFuZCB3ZSBjYW4gbm8gbG9uZ2VyCnBhc3MgaXQgdG8gX19mcmVlX3BhZ2Ug
d2l0aG91dCBzZXR0aW5nIHRoZSBtZm4gdG8gYSBzYW5lIHZhbHVlLCB1c2UKYmFsbG9vbiBncmFu
dCBwYWdlcyBpbnN0ZWFkLCBhcyB0aGUgZ250ZGV2IGRldmljZSBkb2VzLgoKU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiB4ZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFj
bGUuY29tPgotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgICAgNiAr
KysrLS0KIDEgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoK
ZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIGIvZHJpdmVy
cy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKaW5kZXggYzQ2ODI0Zi4uZTZjMmY2YSAxMDA2
NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKKysrIGIvZHJpdmVy
cy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKQEAgLTQ2LDYgKzQ2LDcgQEAKICNpbmNsdWRl
IDx4ZW4veGVuLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcnZpc29yLmg+CiAjaW5jbHVkZSA8
YXNtL3hlbi9oeXBlcmNhbGwuaD4KKyNpbmNsdWRlIDx4ZW4vYmFsbG9vbi5oPgogI2luY2x1ZGUg
ImNvbW1vbi5oIgogCiAvKgpAQCAtMjM5LDYgKzI0MCw3IEBAIHN0YXRpYyB2b2lkIGZyZWVfcGVy
c2lzdGVudF9nbnRzKHN0cnVjdCByYl9yb290ICpyb290LCB1bnNpZ25lZCBpbnQgbnVtKQogCQkJ
cmV0ID0gZ250dGFiX3VubWFwX3JlZnModW5tYXAsIE5VTEwsIHBhZ2VzLAogCQkJCXNlZ3NfdG9f
dW5tYXApOwogCQkJQlVHX09OKHJldCk7CisJCQlmcmVlX3hlbmJhbGxvb25lZF9wYWdlcyhzZWdz
X3RvX3VubWFwLCBwYWdlcyk7CiAJCQlzZWdzX3RvX3VubWFwID0gMDsKIAkJfQogCkBAIC01Mjcs
OCArNTI5LDggQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0
ICpyZXEsCiAJCQkJR0ZQX0tFUk5FTCk7CiAJCQlpZiAoIXBlcnNpc3RlbnRfZ250KQogCQkJCXJl
dHVybiAtRU5PTUVNOwotCQkJcGVyc2lzdGVudF9nbnQtPnBhZ2UgPSBhbGxvY19wYWdlKEdGUF9L
RVJORUwpOwotCQkJaWYgKCFwZXJzaXN0ZW50X2dudC0+cGFnZSkgeworCQkJaWYgKGFsbG9jX3hl
bmJhbGxvb25lZF9wYWdlcygxLCAmcGVyc2lzdGVudF9nbnQtPnBhZ2UsCisJCQkgICAgZmFsc2Up
KSB7CiAJCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOwogCQkJCXJldHVybiAtRU5PTUVNOwogCQkJ
fQotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:23:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5vxW-0005dQ-IH; Thu, 14 Feb 2013 10:22:30 +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 1U5vxV-0005dJ-8b
	for Xen-devel@lists.xensource.com; Thu, 14 Feb 2013 10:22:29 +0000
Received: from [193.109.254.147:45060] by server-3.bemta-14.messagelabs.com id
	2A/22-22141-4EABC115; Thu, 14 Feb 2013 10:22:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1360837347!7879668!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24062 invoked from network); 14 Feb 2013 10:22:27 -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; 14 Feb 2013 10:22:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5vxR-000Lqd-D6; Thu, 14 Feb 2013 10:22:25 +0000
Date: Thu, 14 Feb 2013 10:22:25 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130214102225.GA83752@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@mantra.us.oracle.com>
	<20130213183425.0d17c236@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213183425.0d17c236@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] [RFC PATCH 14/16]: PVH xen: add
	xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:34 -0800 on 13 Feb (1360780465), Mukesh Rathor wrote:
> On Mon, 11 Feb 2013 18:18:24 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > On Thu, 24 Jan 2013 17:31:18 +0000
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 18:11 -0800 on 11 Jan (1357927863), Mukesh Rathor wrote:
> > > 
> > > > +    /* qemu, running on PVH dom0, mapping hvm domain's io pages
> > > > during domain 
> > > > +     * creation, doesn't have mfns in the HAP table */
> > > > +    if ( !mfn_valid(mfn) && p2m_is_mmio(p2mt) ) {
> > > 
> > > This test should be for == p2m_mmio_direct; we don't want to try
> > > mapping p2m_mmio_dm areas.
> > 
> > Yup. Done.
> 
> No, qemu is changing the mem type for these pages, so I need to dig
> into understanding what it's trying to do there. But the above, I don't
> think is correct. Xen returns p2m type of dm, but I don't think I'm
> looking at right mfn's here for this qemu special case. Basically, it's
> during hvm guest creation on PVH dom0 that qemu accesses some addresses
> that are not mapped.

It may be that the memory is genuinely not there - since qemu doesn't
build the guest itself it doesn't necessarily know exactly where the
builder put all the memory.

If that's the case, then just failing the mapping is the right
response. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:23:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5vxW-0005dQ-IH; Thu, 14 Feb 2013 10:22:30 +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 1U5vxV-0005dJ-8b
	for Xen-devel@lists.xensource.com; Thu, 14 Feb 2013 10:22:29 +0000
Received: from [193.109.254.147:45060] by server-3.bemta-14.messagelabs.com id
	2A/22-22141-4EABC115; Thu, 14 Feb 2013 10:22:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1360837347!7879668!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24062 invoked from network); 14 Feb 2013 10:22:27 -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; 14 Feb 2013 10:22:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5vxR-000Lqd-D6; Thu, 14 Feb 2013 10:22:25 +0000
Date: Thu, 14 Feb 2013 10:22:25 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130214102225.GA83752@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@mantra.us.oracle.com>
	<20130213183425.0d17c236@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213183425.0d17c236@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] [RFC PATCH 14/16]: PVH xen: add
	xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:34 -0800 on 13 Feb (1360780465), Mukesh Rathor wrote:
> On Mon, 11 Feb 2013 18:18:24 -0800
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > On Thu, 24 Jan 2013 17:31:18 +0000
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 18:11 -0800 on 11 Jan (1357927863), Mukesh Rathor wrote:
> > > 
> > > > +    /* qemu, running on PVH dom0, mapping hvm domain's io pages
> > > > during domain 
> > > > +     * creation, doesn't have mfns in the HAP table */
> > > > +    if ( !mfn_valid(mfn) && p2m_is_mmio(p2mt) ) {
> > > 
> > > This test should be for == p2m_mmio_direct; we don't want to try
> > > mapping p2m_mmio_dm areas.
> > 
> > Yup. Done.
> 
> No, qemu is changing the mem type for these pages, so I need to dig
> into understanding what it's trying to do there. But the above, I don't
> think is correct. Xen returns p2m type of dm, but I don't think I'm
> looking at right mfn's here for this qemu special case. Basically, it's
> during hvm guest creation on PVH dom0 that qemu accesses some addresses
> that are not mapped.

It may be that the memory is genuinely not there - since qemu doesn't
build the guest itself it doesn't necessarily know exactly where the
builder put all the memory.

If that's the case, then just failing the mapping is the right
response. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:39:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10: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 1U5wE0-0005ve-6J; Thu, 14 Feb 2013 10:39: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 1U5wDy-0005vZ-WB
	for Xen-devel@lists.xensource.com; Thu, 14 Feb 2013 10:39:31 +0000
Received: from [85.158.143.99:49404] by server-1.bemta-4.messagelabs.com id
	B9/3B-08839-2EEBC115; Thu, 14 Feb 2013 10:39:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360838368!22247272!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28902 invoked from network); 14 Feb 2013 10:39:28 -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; 14 Feb 2013 10:39:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5wDv-000Lua-N5; Thu, 14 Feb 2013 10:39:27 +0000
Date: Thu, 14 Feb 2013 10:39:27 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130214103927.GE83752@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130211181824.169b9d05@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] [RFC PATCH 14/16]: PVH xen: add
	xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:18 -0800 on 11 Feb (1360606704), Mukesh Rathor wrote:
> > > +        if (!is_hvm_domain(fdom)) {
> > > +            printk("mmio type for non-hvm domain. fd:%d fgmfn:%lx
> > > gpfn:%lx\n",
> > > +                   foreign_domid, fgmfn, gpfn);
> > > +            return -EINVAL;
> > > +        }
> > > +        mfn = fgmfn;     /* map 1 to 1 */
> > 
> > Surely not -- you want to map the _actual_ MMIO range, right, not just
> > whatever GFN-address the foreigh domain mapped it at?
> 
> Actually, fgmfn here is the machine address of the mmio page. 

I hope not!  You've just passed it to a p2m lookup a little earlier, so
it had better be a gfn.  (And in either case it could do with a more
explicit name: maybe fmfn if it's an mfn or fgfn if it's a gfn?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:39:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10: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 1U5wE0-0005ve-6J; Thu, 14 Feb 2013 10:39: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 1U5wDy-0005vZ-WB
	for Xen-devel@lists.xensource.com; Thu, 14 Feb 2013 10:39:31 +0000
Received: from [85.158.143.99:49404] by server-1.bemta-4.messagelabs.com id
	B9/3B-08839-2EEBC115; Thu, 14 Feb 2013 10:39:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360838368!22247272!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28902 invoked from network); 14 Feb 2013 10:39:28 -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; 14 Feb 2013 10:39:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5wDv-000Lua-N5; Thu, 14 Feb 2013 10:39:27 +0000
Date: Thu, 14 Feb 2013 10:39:27 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130214103927.GE83752@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130211181824.169b9d05@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] [RFC PATCH 14/16]: PVH xen: add
	xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:18 -0800 on 11 Feb (1360606704), Mukesh Rathor wrote:
> > > +        if (!is_hvm_domain(fdom)) {
> > > +            printk("mmio type for non-hvm domain. fd:%d fgmfn:%lx
> > > gpfn:%lx\n",
> > > +                   foreign_domid, fgmfn, gpfn);
> > > +            return -EINVAL;
> > > +        }
> > > +        mfn = fgmfn;     /* map 1 to 1 */
> > 
> > Surely not -- you want to map the _actual_ MMIO range, right, not just
> > whatever GFN-address the foreigh domain mapped it at?
> 
> Actually, fgmfn here is the machine address of the mmio page. 

I hope not!  You've just passed it to a p2m lookup a little earlier, so
it had better be a gfn.  (And in either case it could do with a more
explicit name: maybe fmfn if it's an mfn or fgfn if it's a gfn?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:48:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10:48: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 1U5wMa-00068K-Ct; Thu, 14 Feb 2013 10:48:24 +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 1U5wMZ-00068F-Dx
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:48:23 +0000
Received: from [85.158.139.83:7680] by server-2.bemta-5.messagelabs.com id
	B6/75-16911-6F0CC115; Thu, 14 Feb 2013 10:48:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360838901!23619537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7523 invoked from network); 14 Feb 2013 10:48:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 10:48:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 10:48:21 +0000
Message-Id: <511CCF4002000078000BE233@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 10:49:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
	<1360836032.20449.307.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360836032.20449.307.camel@zakaz.uk.xensource.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/MSI: add mechanism to protect MSI-X
 table from PV guest 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 14.02.13 at 11:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-07 at 08:44 +0000, Jan Beulich wrote:
>> >>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>> > This adds two new physdev operations for Dom0 to invoke when resource
>> > allocation for devices is known to be complete, so that the hypervisor
>> > can arrange for the respective MMIO ranges to be marked read-only
>> > before an eventual guest getting such a device assigned even gets
>> > started, such that it won't be able to set up writable mappings for
>> > these MMIO ranges before Xen has a chance to protect them.
> 
> This sounds reasonable, is the "when resource allocation ... complete"
> difficult to assess or likely to be fragile going forward?

I went through that logic on the Linux side a couple of times, but
couldn't really convince myself of when resource re-allocation might
happen, or would be guaranteed not to happen. I may have to try
to ping the PCI subsytem maintainer(s) to (hopefully) get a firm
statement...

>> I should probably mention the alternatives:
>> 
>> 1) Brute force scan of the (PV) guest's L1 page tables, locating
>> eventual mappings of the questionable MMIO pages, and
>> converting those mappings to R/O ones.
> 
> When would this occur? Just on setup (might be ok) or on any MMU update
> (clearly not) or some middle ground (like only DOMID_IO mappings
> perhaps)?

Since we carry out the page table modifications for the guest
anyway, the only point this is needed is when the first MSI-X
interrupt gets set up. But the guest can do this setup at any rate,
and hence it might get us (maliciously) very busy in this scan, and
handling preemption here might be tricky.

>> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
>> guest_io_write(), taking note of which BAR(s) are relevant at the
>> point where the device gets first detected/reported), perhaps
>> along with snoops of the PCI_COMMAND_MEMORY bit.

Actually, the I/O port based CFG accesses would even be the more
strait forward part. The trickier thing would be the MMCFG based
alternative.

> Do these modifications come straight from the guest, or do they come
> from dom0 via pciback and/or dom0's own PCI subsystem setup? If these
> are coming via pciback then it seems reasonable to me to use physdev
> operations, which takes us back to the patch you've implemented I think.

All CFG accesses go through pciback. The resource assignment (and
hence BAR modifications) are done exclusively by Dom0 (anything
else would be a security hole).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:48:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10:48: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 1U5wMa-00068K-Ct; Thu, 14 Feb 2013 10:48:24 +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 1U5wMZ-00068F-Dx
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:48:23 +0000
Received: from [85.158.139.83:7680] by server-2.bemta-5.messagelabs.com id
	B6/75-16911-6F0CC115; Thu, 14 Feb 2013 10:48:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360838901!23619537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7523 invoked from network); 14 Feb 2013 10:48:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 10:48:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 10:48:21 +0000
Message-Id: <511CCF4002000078000BE233@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 10:49:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
	<1360836032.20449.307.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360836032.20449.307.camel@zakaz.uk.xensource.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/MSI: add mechanism to protect MSI-X
 table from PV guest 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 14.02.13 at 11:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-07 at 08:44 +0000, Jan Beulich wrote:
>> >>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>> > This adds two new physdev operations for Dom0 to invoke when resource
>> > allocation for devices is known to be complete, so that the hypervisor
>> > can arrange for the respective MMIO ranges to be marked read-only
>> > before an eventual guest getting such a device assigned even gets
>> > started, such that it won't be able to set up writable mappings for
>> > these MMIO ranges before Xen has a chance to protect them.
> 
> This sounds reasonable, is the "when resource allocation ... complete"
> difficult to assess or likely to be fragile going forward?

I went through that logic on the Linux side a couple of times, but
couldn't really convince myself of when resource re-allocation might
happen, or would be guaranteed not to happen. I may have to try
to ping the PCI subsytem maintainer(s) to (hopefully) get a firm
statement...

>> I should probably mention the alternatives:
>> 
>> 1) Brute force scan of the (PV) guest's L1 page tables, locating
>> eventual mappings of the questionable MMIO pages, and
>> converting those mappings to R/O ones.
> 
> When would this occur? Just on setup (might be ok) or on any MMU update
> (clearly not) or some middle ground (like only DOMID_IO mappings
> perhaps)?

Since we carry out the page table modifications for the guest
anyway, the only point this is needed is when the first MSI-X
interrupt gets set up. But the guest can do this setup at any rate,
and hence it might get us (maliciously) very busy in this scan, and
handling preemption here might be tricky.

>> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
>> guest_io_write(), taking note of which BAR(s) are relevant at the
>> point where the device gets first detected/reported), perhaps
>> along with snoops of the PCI_COMMAND_MEMORY bit.

Actually, the I/O port based CFG accesses would even be the more
strait forward part. The trickier thing would be the MMCFG based
alternative.

> Do these modifications come straight from the guest, or do they come
> from dom0 via pciback and/or dom0's own PCI subsystem setup? If these
> are coming via pciback then it seems reasonable to me to use physdev
> operations, which takes us back to the patch you've implemented I think.

All CFG accesses go through pciback. The resource assignment (and
hence BAR modifications) are done exclusively by Dom0 (anything
else would be a security hole).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10: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 1U5wUH-0006JI-Ba; Thu, 14 Feb 2013 10:56:21 +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 1U5wUG-0006JD-1j
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:56:20 +0000
Received: from [85.158.139.211:10393] by server-2.bemta-5.messagelabs.com id
	AF/94-16911-3D2CC115; Thu, 14 Feb 2013 10:56:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360839378!22057594!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13903 invoked from network); 14 Feb 2013 10:56:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:56:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1454760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:56:18 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 14 Feb 2013 10:56:18 +0000
Message-ID: <511CC2E5.4090400@citrix.com>
Date: Thu, 14 Feb 2013 11:56:37 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTQvMDIvMTMgMTE6MTIsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBXaXRoIGN1cnJlbnQg
cGVyc2lzdGVudCBncmFudHMgaW1wbGVtZW50YXRpb24gd2UgYXJlIG5vdCBmcmVlaW5nIHRoZQo+
IHBlcnNpc3RlbnQgZ3JhbnRzIGFmdGVyIHdlIGRpc2Nvbm5lY3QgdGhlIGRldmljZS4gU2luY2Ug
Z3JhbnQgbWFwCj4gb3BlcmF0aW9ucyBjaGFuZ2UgdGhlIG1mbiBvZiB0aGUgYWxsb2NhdGVkIHBh
Z2UsIGFuZCB3ZSBjYW4gbm8gbG9uZ2VyCj4gcGFzcyBpdCB0byBfX2ZyZWVfcGFnZSB3aXRob3V0
IHNldHRpbmcgdGhlIG1mbiB0byBhIHNhbmUgdmFsdWUsIHVzZQo+IGJhbGxvb24gZ3JhbnQgcGFn
ZXMgaW5zdGVhZCwgYXMgdGhlIGdudGRldiBkZXZpY2UgZG9lcy4KPiAKPiBTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBDYzogeGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKPiBDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0Bv
cmFjbGUuY29tPgoKSSB0aGluayB0aGlzIHBhdGNoIGlzIG1pc3NpbmcgdGhlIGZvbGxvd2luZyBj
aGFuZ2UgaW4gS2NvbmZpZywgYnV0IApnbnRkZXYgZG9lc24ndCBkZXBlbmQgb24gdGhlIGJhbGxv
b24gZHJpdmVyLCB3aGljaCBpdCBhbHNvIHVzZXMsIHNvIEknbSAKbm90IHN1cmUuCgotLS0KZGlm
ZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2svS2NvbmZpZyBiL2RyaXZlcnMvYmxvY2svS2NvbmZpZwpp
bmRleCBmNTI5NDA3Li43NGUyNDE1IDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL0tjb25maWcK
KysrIGIvZHJpdmVycy9ibG9jay9LY29uZmlnCkBAIC00ODgsNyArNDg4LDcgQEAgY29uZmlnIFhF
Tl9CTEtERVZfRlJPTlRFTkQKIAogY29uZmlnIFhFTl9CTEtERVZfQkFDS0VORAogCXRyaXN0YXRl
ICJYZW4gYmxvY2stZGV2aWNlIGJhY2tlbmQgZHJpdmVyIgotCWRlcGVuZHMgb24gWEVOX0JBQ0tF
TkQKKwlkZXBlbmRzIG9uIFhFTl9CQUNLRU5EICYmIFhFTl9CQUxMT09OCiAJaGVscAogCSAgVGhl
IGJsb2NrLWRldmljZSBiYWNrZW5kIGRyaXZlciBhbGxvd3MgdGhlIGtlcm5lbCB0byBleHBvcnQg
aXRzCiAJICBibG9jayBkZXZpY2VzIHRvIG90aGVyIGd1ZXN0cyB2aWEgYSBoaWdoLXBlcmZvcm1h
bmNlIHNoYXJlZC1tZW1vcnkKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10: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 1U5wUH-0006JI-Ba; Thu, 14 Feb 2013 10:56:21 +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 1U5wUG-0006JD-1j
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:56:20 +0000
Received: from [85.158.139.211:10393] by server-2.bemta-5.messagelabs.com id
	AF/94-16911-3D2CC115; Thu, 14 Feb 2013 10:56:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360839378!22057594!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13903 invoked from network); 14 Feb 2013 10:56:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:56:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1454760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:56:18 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 14 Feb 2013 10:56:18 +0000
Message-ID: <511CC2E5.4090400@citrix.com>
Date: Thu, 14 Feb 2013 11:56:37 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTQvMDIvMTMgMTE6MTIsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPiBXaXRoIGN1cnJlbnQg
cGVyc2lzdGVudCBncmFudHMgaW1wbGVtZW50YXRpb24gd2UgYXJlIG5vdCBmcmVlaW5nIHRoZQo+
IHBlcnNpc3RlbnQgZ3JhbnRzIGFmdGVyIHdlIGRpc2Nvbm5lY3QgdGhlIGRldmljZS4gU2luY2Ug
Z3JhbnQgbWFwCj4gb3BlcmF0aW9ucyBjaGFuZ2UgdGhlIG1mbiBvZiB0aGUgYWxsb2NhdGVkIHBh
Z2UsIGFuZCB3ZSBjYW4gbm8gbG9uZ2VyCj4gcGFzcyBpdCB0byBfX2ZyZWVfcGFnZSB3aXRob3V0
IHNldHRpbmcgdGhlIG1mbiB0byBhIHNhbmUgdmFsdWUsIHVzZQo+IGJhbGxvb24gZ3JhbnQgcGFn
ZXMgaW5zdGVhZCwgYXMgdGhlIGdudGRldiBkZXZpY2UgZG9lcy4KPiAKPiBTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiBDYzogeGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKPiBDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0Bv
cmFjbGUuY29tPgoKSSB0aGluayB0aGlzIHBhdGNoIGlzIG1pc3NpbmcgdGhlIGZvbGxvd2luZyBj
aGFuZ2UgaW4gS2NvbmZpZywgYnV0IApnbnRkZXYgZG9lc24ndCBkZXBlbmQgb24gdGhlIGJhbGxv
b24gZHJpdmVyLCB3aGljaCBpdCBhbHNvIHVzZXMsIHNvIEknbSAKbm90IHN1cmUuCgotLS0KZGlm
ZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2svS2NvbmZpZyBiL2RyaXZlcnMvYmxvY2svS2NvbmZpZwpp
bmRleCBmNTI5NDA3Li43NGUyNDE1IDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL0tjb25maWcK
KysrIGIvZHJpdmVycy9ibG9jay9LY29uZmlnCkBAIC00ODgsNyArNDg4LDcgQEAgY29uZmlnIFhF
Tl9CTEtERVZfRlJPTlRFTkQKIAogY29uZmlnIFhFTl9CTEtERVZfQkFDS0VORAogCXRyaXN0YXRl
ICJYZW4gYmxvY2stZGV2aWNlIGJhY2tlbmQgZHJpdmVyIgotCWRlcGVuZHMgb24gWEVOX0JBQ0tF
TkQKKwlkZXBlbmRzIG9uIFhFTl9CQUNLRU5EICYmIFhFTl9CQUxMT09OCiAJaGVscAogCSAgVGhl
IGJsb2NrLWRldmljZSBiYWNrZW5kIGRyaXZlciBhbGxvd3MgdGhlIGtlcm5lbCB0byBleHBvcnQg
aXRzCiAJICBibG9jayBkZXZpY2VzIHRvIG90aGVyIGd1ZXN0cyB2aWEgYSBoaWdoLXBlcmZvcm1h
bmNlIHNoYXJlZC1tZW1vcnkKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 14 10:58:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10:58: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 1U5wVw-0006OE-Rw; Thu, 14 Feb 2013 10:58:04 +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 1U5wVu-0006O7-O1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:58:02 +0000
Received: from [193.109.254.147:30096] by server-7.bemta-14.messagelabs.com id
	49/AB-13581-933CC115; Thu, 14 Feb 2013 10:58:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360839456!11127183!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22442 invoked from network); 14 Feb 2013 10:57:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:57:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1454796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:57: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.297.1;
	Thu, 14 Feb 2013 10:57:22 +0000
Message-ID: <1360839441.20449.333.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 10:57:21 +0000
In-Reply-To: <511CB8F902000078000BE1CC@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511CB8F902000078000BE1CC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 09:14 +0000, Jan Beulich wrote:
> >>> On 13.02.13 at 19:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > A slightly upgraded version of the *UNTESTED* patch.
> 
> Ack (albeit I'd slightly prefer -EINVAL or, for eventual debugging
> purposes, four distinct -Exxx values to be returned).

Yes, please, 4 values would be good.

I'm a little bit curious what the guest, which is generating these
invalid packets. I guess previously they were being silently dropped?

> 
> Jan
> 
> > ----8<----
> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> > Author: Wei Liu <wei.liu2@citrix.com>
> > Date:   Wed Feb 13 18:17:01 2013 +0000
> > 
> >     netback: fix netbk_count_requests
> >     
> >     There are two paths in the original code, a) test against work_to_do, b) 
> > test
> >     against first->size, could return 0 even when error happens.
> >     
> >     Simply return -1 in error paths should work. Modify all error paths to 
> > return
> >     -1 to be consistent.
> >     
> >     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > diff --git a/drivers/net/xen-netback/netback.c 
> > b/drivers/net/xen-netback/netback.c
> > index 103294d..0e0162e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (frags >= work_to_do) {
> >  			netdev_err(vif->dev, "Need more frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
> >  			netdev_err(vif->dev, "Too many frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> > @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (txp->size > first->size) {
> >  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		first->size -= txp->size;
> > @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
> >  				 txp->offset, txp->size);
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> >  	return frags;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/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 Feb 14 10:58:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 10:58: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 1U5wVw-0006OE-Rw; Thu, 14 Feb 2013 10:58:04 +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 1U5wVu-0006O7-O1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 10:58:02 +0000
Received: from [193.109.254.147:30096] by server-7.bemta-14.messagelabs.com id
	49/AB-13581-933CC115; Thu, 14 Feb 2013 10:58:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360839456!11127183!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22442 invoked from network); 14 Feb 2013 10:57:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 10:57:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="1454796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 10:57: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.297.1;
	Thu, 14 Feb 2013 10:57:22 +0000
Message-ID: <1360839441.20449.333.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 10:57:21 +0000
In-Reply-To: <511CB8F902000078000BE1CC@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511CB8F902000078000BE1CC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 09:14 +0000, Jan Beulich wrote:
> >>> On 13.02.13 at 19:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > A slightly upgraded version of the *UNTESTED* patch.
> 
> Ack (albeit I'd slightly prefer -EINVAL or, for eventual debugging
> purposes, four distinct -Exxx values to be returned).

Yes, please, 4 values would be good.

I'm a little bit curious what the guest, which is generating these
invalid packets. I guess previously they were being silently dropped?

> 
> Jan
> 
> > ----8<----
> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> > Author: Wei Liu <wei.liu2@citrix.com>
> > Date:   Wed Feb 13 18:17:01 2013 +0000
> > 
> >     netback: fix netbk_count_requests
> >     
> >     There are two paths in the original code, a) test against work_to_do, b) 
> > test
> >     against first->size, could return 0 even when error happens.
> >     
> >     Simply return -1 in error paths should work. Modify all error paths to 
> > return
> >     -1 to be consistent.
> >     
> >     Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > diff --git a/drivers/net/xen-netback/netback.c 
> > b/drivers/net/xen-netback/netback.c
> > index 103294d..0e0162e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -913,13 +913,13 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (frags >= work_to_do) {
> >  			netdev_err(vif->dev, "Need more frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
> >  			netdev_err(vif->dev, "Too many frags\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> > @@ -927,7 +927,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  		if (txp->size > first->size) {
> >  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  
> >  		first->size -= txp->size;
> > @@ -937,7 +937,7 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
> >  				 txp->offset, txp->size);
> >  			netbk_fatal_tx_err(vif);
> > -			return -frags;
> > +			return -1;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> >  	return frags;
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org 
> > http://lists.xen.org/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 Feb 14 11:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:02: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 1U5waL-0006c7-Iz; Thu, 14 Feb 2013 11:02:37 +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 1U5waK-0006bz-7Z
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:02:36 +0000
Received: from [85.158.139.83:2988] by server-3.bemta-5.messagelabs.com id
	3B/C4-07037-B44CC115; Thu, 14 Feb 2013 11:02:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360839754!32286547!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21420 invoked from network); 14 Feb 2013 11:02:34 -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; 14 Feb 2013 11:02:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:02:34 +0000
Message-Id: <511CD29502000078000BE24F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:03:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
In-Reply-To: <CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>> > 2013/2/13 Jan Beulich <JBeulich@suse.com>:
>>>> I wonder how native Linux with
>>>> IOMMU enabled does in that situation...
>>>>
> 
> Here is full boot log of latest centos stable kernel:
> http://pastebin.com/raw.php?i=RnrMFXqf 
> I had to set amd_iommu=on and amd_iommu_dump (to dump ACPI table) -
> undocumented kernel options.
> 
> Interesting part in my opinion:
> calling  pci_iommu_init+0x0/0x21 @ 1
> AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: 3e info 1300
> AMD-Vi:        mmio-addr: 00000000f6000000
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:00.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:00.2
> AMD-Vi:   DEV_SELECT			 devid: 00:04.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 06:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:06.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 05:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:07.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 04:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:0b.0 flags: 00
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 03:00.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 03:00.1
> AMD-Vi:   DEV_SELECT			 devid: 00:0d.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 02:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:11.0 flags: 00
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:12.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:12.2
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:13.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:13.2
> AMD-Vi:   DEV_SELECT			 devid: 00:14.0 flags: d7
> AMD-Vi:   DEV_SELECT			 devid: 00:14.1 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:14.2 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:14.3 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:14.4 flags: 00
> AMD-Vi:   DEV_ALIAS_RANGE		 devid: 01:00.0 flags: 00 devid_to: 00:14.4
> AMD-Vi:   DEV_RANGE_END		 devid: 01:1f.7
> AMD-Vi:   DEV_SELECT			 devid: 00:14.5 flags: 00
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:16.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:16.2
>   alloc irq_desc for 55 on node 0
>   alloc kstat_irqs on node 0
> IOAPIC[1]: Set routing entry (7-31 -> 0x79 -> IRQ 55 Mode:1 Active:1)
> pci 0000:00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55
>   alloc irq_desc for 56 on node 0
>   alloc kstat_irqs on node 0
> pci 0000:00:00.2: irq 56 for MSI/MSI-X
> AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
> AMD-Vi: Initialized for Passthrough Mode
> AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
> initcall pci_iommu_init+0x0/0x21 returned 0 after 569797 usecs
> 
> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.

So the problem appears to be that this device has BDF higher than
any known one. Could you therefore try whether the patch below
allows the system to come up?

Jan

--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for_device(
 {
     struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
 
-    BUG_ON ( bdf >= ivrs_bdf_entries );
-    return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;
+    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
+                                                   : NULL;
 }
 
 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:02: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 1U5waL-0006c7-Iz; Thu, 14 Feb 2013 11:02:37 +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 1U5waK-0006bz-7Z
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:02:36 +0000
Received: from [85.158.139.83:2988] by server-3.bemta-5.messagelabs.com id
	3B/C4-07037-B44CC115; Thu, 14 Feb 2013 11:02:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360839754!32286547!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21420 invoked from network); 14 Feb 2013 11:02:34 -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; 14 Feb 2013 11:02:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:02:34 +0000
Message-Id: <511CD29502000078000BE24F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:03:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
In-Reply-To: <CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>> > 2013/2/13 Jan Beulich <JBeulich@suse.com>:
>>>> I wonder how native Linux with
>>>> IOMMU enabled does in that situation...
>>>>
> 
> Here is full boot log of latest centos stable kernel:
> http://pastebin.com/raw.php?i=RnrMFXqf 
> I had to set amd_iommu=on and amd_iommu_dump (to dump ACPI table) -
> undocumented kernel options.
> 
> Interesting part in my opinion:
> calling  pci_iommu_init+0x0/0x21 @ 1
> AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: 3e info 1300
> AMD-Vi:        mmio-addr: 00000000f6000000
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:00.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:00.2
> AMD-Vi:   DEV_SELECT			 devid: 00:04.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 06:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:06.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 05:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:07.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 04:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:0b.0 flags: 00
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 03:00.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 03:00.1
> AMD-Vi:   DEV_SELECT			 devid: 00:0d.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 02:00.0 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:11.0 flags: 00
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:12.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:12.2
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:13.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:13.2
> AMD-Vi:   DEV_SELECT			 devid: 00:14.0 flags: d7
> AMD-Vi:   DEV_SELECT			 devid: 00:14.1 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:14.2 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:14.3 flags: 00
> AMD-Vi:   DEV_SELECT			 devid: 00:14.4 flags: 00
> AMD-Vi:   DEV_ALIAS_RANGE		 devid: 01:00.0 flags: 00 devid_to: 00:14.4
> AMD-Vi:   DEV_RANGE_END		 devid: 01:1f.7
> AMD-Vi:   DEV_SELECT			 devid: 00:14.5 flags: 00
> AMD-Vi:   DEV_SELECT_RANGE_START	 devid: 00:16.0 flags: 00
> AMD-Vi:   DEV_RANGE_END		 devid: 00:16.2
>   alloc irq_desc for 55 on node 0
>   alloc kstat_irqs on node 0
> IOAPIC[1]: Set routing entry (7-31 -> 0x79 -> IRQ 55 Mode:1 Active:1)
> pci 0000:00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55
>   alloc irq_desc for 56 on node 0
>   alloc kstat_irqs on node 0
> pci 0000:00:00.2: irq 56 for MSI/MSI-X
> AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
> AMD-Vi: Initialized for Passthrough Mode
> AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
> initcall pci_iommu_init+0x0/0x21 returned 0 after 569797 usecs
> 
> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.

So the problem appears to be that this device has BDF higher than
any known one. Could you therefore try whether the patch below
allows the system to come up?

Jan

--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for_device(
 {
     struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
 
-    BUG_ON ( bdf >= ivrs_bdf_entries );
-    return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;
+    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
+                                                   : NULL;
 }
 
 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:05:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5wcu-0006jz-5C; Thu, 14 Feb 2013 11:05:16 +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 1U5wct-0006jr-4c
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:05:15 +0000
Received: from [85.158.138.51:54385] by server-8.bemta-3.messagelabs.com id
	45/B2-25687-5E4CC115; Thu, 14 Feb 2013 11:05:09 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360839908!18637819!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20044 invoked from network); 14 Feb 2013 11:05:08 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-174.messagelabs.com with SMTP;
	14 Feb 2013 11:05:08 -0000
Received: from p5b2e3d19.dip.t-dialin.net ([91.46.61.25] 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 1U5wcl-0005SL-Ks; Thu, 14 Feb 2013 11:05:07 +0000
Message-ID: <511CC4D8.3060203@canonical.com>
Date: Thu, 14 Feb 2013 12:04:56 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <51151ABF.1070007@canonical.com>
In-Reply-To: <51151ABF.1070007@canonical.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="===============4915402263337268652=="
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)
--===============4915402263337268652==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigD23FB554A653276F059D5719"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD23FB554A653276F059D5719
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think I finally can proof why allowing interrupts for the duration of p=
oll_irq
in xen_spin_lock_slow is bad! \o/

So with another run/dump:

VCPUs 1,2,5 and 6 are spinning on the runq lock of VCPU 1. The number of
spinners is 4 (ok) and the lock released.
According to dom0 debug info VCPUs 2,5 and 6 are polling, VCPU 1 is not
but seems running (has=3DT). The event channel for spinlock1 is pending.

Checking the interrupt stack of VCPU 1 in the guest dump shows:

hypercall_page+938
xen_poll_irq+16
xen_spin_lock_slow+151
xen_spin_lock_flags+99
_raw_spin_lock_irqsave+46
update_shares+156
rebalance_domains+72
run_rebalance_domains+72
__do_softirq+168
call_softirq+99
do_softirq+101
irq_exit+142
xen_evtchn_do_upcall+53
xen_do_hypervisor_callback+101

So right before finishing a previous callback, irq_exit triggers softirq
processing (interrupts enabled) and while updating the shares this tries =
to grab
the runq lock which we see in lock_spinners.

Since irq_count is 2 there is one more interruption executing right now (=
though
irq_regs wont show this). So I just proceeded upwards in the interrupt st=
ack and
found:
try_to_wake_up+57
default_wake_function+18
autoremove_wake_function+22
wake_bit_function+59
__wake_up_common+88
__wake_up+72
__wake_up_bit+49
end_page_writeback+64
put_io_page+36
ext4_end_bio+338
bio_endio+29
req_bio_endio.isra.45+163
blk_update_request+245
blk_update_bidi_request+49
__blk_end_bidi_request+32
__blk_end_request_all+31
blkif_interrupt+460
handle_irq_event_percpu+85
handle_irq_event+78
handle_edge_irq+132
__xen_evtchn_do_upcall+409
xen_evtchn_do_upcall+47
xen_do_hypervisor_callback+101

There was a bit more on the stack but try_to_wake_up seemed a believable =
current
path. Even more so after looking into the function:

#ifdef CONFIG_SMP
        /*
         * If the owning (remote) cpu is still in the middle of schedule(=
) with
         * this task as prev, wait until its done referencing the task.
         */
        while (p->on_cpu) {
#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
                /*
                 * In case the architecture enables interrupts in
                 * context_switch(), we cannot busy wait, since that
                 * would lead to deadlocks when an interrupt hits and
                 * tries to wake up @prev. So bail and do a complete
                 * remote wakeup.
                 */
                if (ttwu_activate_remote(p, wake_flags))
                        goto stat;
#else
                cpu_relax();
#endif

And prying out the task in question from the stack, it was one currently
being accounted for VCPU 6 and on_cpu. VCPU 6 is one of the other waiters=
 for
the runq lock of VCPU 1. Which would get picked up as soon as this callba=
ck is
done. Unfortunately we "stay awhile... stay forever!".

Ok, as an experiment I defined  __ARCH_WANT_INTERRUPTS_ON_CTXSW for x86 a=
nd
running that kernel in the PVM guest no more locks up.
Problem there is that this define is gone since v3.7 (f3e9478674). And th=
e
same testcase is not able to cause the issue since v3.6 (611ae8e3f5). The=

change of TLB flushes unlikely is directly related (rather changing the n=
umber
of IPIs and by that the likelihood to observe this).

So for v3.6+ kernels, the question is whether it can be ruled out that du=
ring
softirq handling rebalance_domains->update_blocked_averages (was update_s=
hares)
is called which then can get into spin_lock_slow and enable interrupts.
I have not seen it or am aware of reports about it but its likely one of =
those
rare occurrences.

As for a solution, the simplest one would be never to re-enable interrupt=
s
before poll_irq... Anything else feels atm right complicated (like trying=
 to
make the scheduler use disable interrupts and spin_lock variants instead =
of
spin_lock_irq ones... weird hidden implications in common code "just" for=
 PVM).

-Stefan

Note: comparing the number of db records created on a 15min run of the te=
stcase
seems to yield similar results for interrupts enabled (with that arch def=
ine in
v3.2) or disabled. Though I do not have a huge number base and that PVM i=
s the
only one running on the host.




--------------enigD23FB554A653276F059D5719
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHMThAAoJEOhnXe7L7s6jiUoP/2QUWD3TdNlR53z4Mo4ZObEM
rvyMLW291XaSYVVx94d2tW5yKNdpbKFM9kOV0rTfOJ2o/j7/w3O4uZoOncDX5q+l
I88wG0fVV43qfwzCtl5UKh7Pgqk97AOO1k7qcZA7o6RntW1fJSOL7TDrUq3SV4Ec
uuTMKJXhtJ9WGw+FSeHWCYdElT6QZb54BxRvNUzDuAtJ0jqvy8Lh6gIR1lmwaSGN
hpbCirFJkKxFLnJukEWPaCHrrzTvlHCjRSefdPXxZuivZCBDMRSLc2ROYLTAVZxA
UNqJYX83/Aj4kDbGR/54PcWkc1KyPRzDB2kySfLorfJhkK48usjGsKK07eRSZXdk
M+P5X/M6CtVnwgZ2kY5XFap7ihVOnN8ibbOYSshE/r407L6p9OYipAF6puBZ/tmx
bi/r+61LH54+R1YdPOy4xisPM9XajIu85uyrc75aUY4bYzsvbMHLl5RuwYfN7omu
RHwhszPbNdThmHcp/p3SzeG5z2P14rVtunNRJRe28JXnRiksNeNEf5KuvS9offKb
bqLjy5dHNaIS2k/uEO634M1EUGnHeLYhg8EShu0XDHhnk76ASbHS6UHiRi8yPwVp
ybSOqwjmh/A8uS0HqMI+MF8/MgSZl+CkiFWDZ7NUW+wLOUuihjErkM3YBeYmPnD8
XNOyEWnICM4FbtWPRaR6
=mT37
-----END PGP SIGNATURE-----

--------------enigD23FB554A653276F059D5719--


--===============4915402263337268652==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4915402263337268652==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 11:05:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5wcu-0006jz-5C; Thu, 14 Feb 2013 11:05:16 +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 1U5wct-0006jr-4c
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:05:15 +0000
Received: from [85.158.138.51:54385] by server-8.bemta-3.messagelabs.com id
	45/B2-25687-5E4CC115; Thu, 14 Feb 2013 11:05:09 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360839908!18637819!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20044 invoked from network); 14 Feb 2013 11:05:08 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-174.messagelabs.com with SMTP;
	14 Feb 2013 11:05:08 -0000
Received: from p5b2e3d19.dip.t-dialin.net ([91.46.61.25] 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 1U5wcl-0005SL-Ks; Thu, 14 Feb 2013 11:05:07 +0000
Message-ID: <511CC4D8.3060203@canonical.com>
Date: Thu, 14 Feb 2013 12:04:56 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <51151ABF.1070007@canonical.com>
In-Reply-To: <51151ABF.1070007@canonical.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="===============4915402263337268652=="
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)
--===============4915402263337268652==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigD23FB554A653276F059D5719"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD23FB554A653276F059D5719
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think I finally can proof why allowing interrupts for the duration of p=
oll_irq
in xen_spin_lock_slow is bad! \o/

So with another run/dump:

VCPUs 1,2,5 and 6 are spinning on the runq lock of VCPU 1. The number of
spinners is 4 (ok) and the lock released.
According to dom0 debug info VCPUs 2,5 and 6 are polling, VCPU 1 is not
but seems running (has=3DT). The event channel for spinlock1 is pending.

Checking the interrupt stack of VCPU 1 in the guest dump shows:

hypercall_page+938
xen_poll_irq+16
xen_spin_lock_slow+151
xen_spin_lock_flags+99
_raw_spin_lock_irqsave+46
update_shares+156
rebalance_domains+72
run_rebalance_domains+72
__do_softirq+168
call_softirq+99
do_softirq+101
irq_exit+142
xen_evtchn_do_upcall+53
xen_do_hypervisor_callback+101

So right before finishing a previous callback, irq_exit triggers softirq
processing (interrupts enabled) and while updating the shares this tries =
to grab
the runq lock which we see in lock_spinners.

Since irq_count is 2 there is one more interruption executing right now (=
though
irq_regs wont show this). So I just proceeded upwards in the interrupt st=
ack and
found:
try_to_wake_up+57
default_wake_function+18
autoremove_wake_function+22
wake_bit_function+59
__wake_up_common+88
__wake_up+72
__wake_up_bit+49
end_page_writeback+64
put_io_page+36
ext4_end_bio+338
bio_endio+29
req_bio_endio.isra.45+163
blk_update_request+245
blk_update_bidi_request+49
__blk_end_bidi_request+32
__blk_end_request_all+31
blkif_interrupt+460
handle_irq_event_percpu+85
handle_irq_event+78
handle_edge_irq+132
__xen_evtchn_do_upcall+409
xen_evtchn_do_upcall+47
xen_do_hypervisor_callback+101

There was a bit more on the stack but try_to_wake_up seemed a believable =
current
path. Even more so after looking into the function:

#ifdef CONFIG_SMP
        /*
         * If the owning (remote) cpu is still in the middle of schedule(=
) with
         * this task as prev, wait until its done referencing the task.
         */
        while (p->on_cpu) {
#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
                /*
                 * In case the architecture enables interrupts in
                 * context_switch(), we cannot busy wait, since that
                 * would lead to deadlocks when an interrupt hits and
                 * tries to wake up @prev. So bail and do a complete
                 * remote wakeup.
                 */
                if (ttwu_activate_remote(p, wake_flags))
                        goto stat;
#else
                cpu_relax();
#endif

And prying out the task in question from the stack, it was one currently
being accounted for VCPU 6 and on_cpu. VCPU 6 is one of the other waiters=
 for
the runq lock of VCPU 1. Which would get picked up as soon as this callba=
ck is
done. Unfortunately we "stay awhile... stay forever!".

Ok, as an experiment I defined  __ARCH_WANT_INTERRUPTS_ON_CTXSW for x86 a=
nd
running that kernel in the PVM guest no more locks up.
Problem there is that this define is gone since v3.7 (f3e9478674). And th=
e
same testcase is not able to cause the issue since v3.6 (611ae8e3f5). The=

change of TLB flushes unlikely is directly related (rather changing the n=
umber
of IPIs and by that the likelihood to observe this).

So for v3.6+ kernels, the question is whether it can be ruled out that du=
ring
softirq handling rebalance_domains->update_blocked_averages (was update_s=
hares)
is called which then can get into spin_lock_slow and enable interrupts.
I have not seen it or am aware of reports about it but its likely one of =
those
rare occurrences.

As for a solution, the simplest one would be never to re-enable interrupt=
s
before poll_irq... Anything else feels atm right complicated (like trying=
 to
make the scheduler use disable interrupts and spin_lock variants instead =
of
spin_lock_irq ones... weird hidden implications in common code "just" for=
 PVM).

-Stefan

Note: comparing the number of db records created on a 15min run of the te=
stcase
seems to yield similar results for interrupts enabled (with that arch def=
ine in
v3.2) or disabled. Though I do not have a huge number base and that PVM i=
s the
only one running on the host.




--------------enigD23FB554A653276F059D5719
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHMThAAoJEOhnXe7L7s6jiUoP/2QUWD3TdNlR53z4Mo4ZObEM
rvyMLW291XaSYVVx94d2tW5yKNdpbKFM9kOV0rTfOJ2o/j7/w3O4uZoOncDX5q+l
I88wG0fVV43qfwzCtl5UKh7Pgqk97AOO1k7qcZA7o6RntW1fJSOL7TDrUq3SV4Ec
uuTMKJXhtJ9WGw+FSeHWCYdElT6QZb54BxRvNUzDuAtJ0jqvy8Lh6gIR1lmwaSGN
hpbCirFJkKxFLnJukEWPaCHrrzTvlHCjRSefdPXxZuivZCBDMRSLc2ROYLTAVZxA
UNqJYX83/Aj4kDbGR/54PcWkc1KyPRzDB2kySfLorfJhkK48usjGsKK07eRSZXdk
M+P5X/M6CtVnwgZ2kY5XFap7ihVOnN8ibbOYSshE/r407L6p9OYipAF6puBZ/tmx
bi/r+61LH54+R1YdPOy4xisPM9XajIu85uyrc75aUY4bYzsvbMHLl5RuwYfN7omu
RHwhszPbNdThmHcp/p3SzeG5z2P14rVtunNRJRe28JXnRiksNeNEf5KuvS9offKb
bqLjy5dHNaIS2k/uEO634M1EUGnHeLYhg8EShu0XDHhnk76ASbHS6UHiRi8yPwVp
ybSOqwjmh/A8uS0HqMI+MF8/MgSZl+CkiFWDZ7NUW+wLOUuihjErkM3YBeYmPnD8
XNOyEWnICM4FbtWPRaR6
=mT37
-----END PGP SIGNATURE-----

--------------enigD23FB554A653276F059D5719--


--===============4915402263337268652==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4915402263337268652==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 11:11:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5wig-0006wz-5P; Thu, 14 Feb 2013 11:11:14 +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 1U5wie-0006wu-Ux
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:11:13 +0000
Received: from [85.158.139.211:45806] by server-1.bemta-5.messagelabs.com id
	06/5E-29263-056CC115; Thu, 14 Feb 2013 11:11:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360840270!20810606!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24147 invoked from network); 14 Feb 2013 11:11:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:11:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="7482567"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:11:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:11:09 -0500
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 1U5wib-00040z-35	for xen-devel@lists.xen.org;
	Thu, 14 Feb 2013 11:11:09 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U5wia-0004NA-QM	for
	xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:11:08 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6ad763d9f964859d045380baef43edf18399bdb0
Message-ID: <6ad763d9f964859d0453.1360840268@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 11:11:08 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360840027 0
# Node ID 6ad763d9f964859d045380baef43edf18399bdb0
# Parent  788f4551580d476e13ea907e373e58806a32179e
x86/setup: don't relocate the VGA hole.

Copying the contents of the VGA hole is at best pointless and at worst
dangerous.  Booting Xen on Xen, it causes a very long delay as each
byte is referred to qemu.

Since we were already discarding the first 1MB of the relocated area,
just avoid copying it in the first place.

Reported-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 788f4551580d -r 6ad763d9f964 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Thu Feb 14 09:42:57 2013 +0100
+++ b/xen/arch/x86/setup.c	Thu Feb 14 11:07:07 2013 +0000
@@ -838,8 +838,8 @@ void __init __start_xen(unsigned long mb
             l4_pgentry_t *pl4e;
             l3_pgentry_t *pl3e;
             l2_pgentry_t *pl2e;
+            uint64_t load_start;
             int i, j, k;
-            void *dst;
 
             /* Select relocation address. */
             e = end - reloc_size;
@@ -852,11 +852,9 @@ void __init __start_xen(unsigned long mb
              * with a barrier(). After this we must *not* modify static/global
              * data until after we have switched to the relocated pagetables!
              */
+            load_start = (unsigned long)_start - XEN_VIRT_START;
             barrier();
-            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START, 1);
-
-            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
-            memset(dst, 0x55, 1U << 20);
+            move_memory(e + load_start, load_start, _end - _start, 1);
 
             /* Walk initial pagetables, relocating page directory entries. */
             pl4e = __va(__pa(idle_pg_table));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:11:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5wig-0006wz-5P; Thu, 14 Feb 2013 11:11:14 +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 1U5wie-0006wu-Ux
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:11:13 +0000
Received: from [85.158.139.211:45806] by server-1.bemta-5.messagelabs.com id
	06/5E-29263-056CC115; Thu, 14 Feb 2013 11:11:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360840270!20810606!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24147 invoked from network); 14 Feb 2013 11:11:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:11:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,664,1355097600"; 
   d="scan'208";a="7482567"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:11:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:11:09 -0500
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 1U5wib-00040z-35	for xen-devel@lists.xen.org;
	Thu, 14 Feb 2013 11:11:09 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U5wia-0004NA-QM	for
	xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:11:08 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6ad763d9f964859d045380baef43edf18399bdb0
Message-ID: <6ad763d9f964859d0453.1360840268@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 11:11:08 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] x86/setup: don't relocate the VGA hole
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1360840027 0
# Node ID 6ad763d9f964859d045380baef43edf18399bdb0
# Parent  788f4551580d476e13ea907e373e58806a32179e
x86/setup: don't relocate the VGA hole.

Copying the contents of the VGA hole is at best pointless and at worst
dangerous.  Booting Xen on Xen, it causes a very long delay as each
byte is referred to qemu.

Since we were already discarding the first 1MB of the relocated area,
just avoid copying it in the first place.

Reported-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 788f4551580d -r 6ad763d9f964 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c	Thu Feb 14 09:42:57 2013 +0100
+++ b/xen/arch/x86/setup.c	Thu Feb 14 11:07:07 2013 +0000
@@ -838,8 +838,8 @@ void __init __start_xen(unsigned long mb
             l4_pgentry_t *pl4e;
             l3_pgentry_t *pl3e;
             l2_pgentry_t *pl2e;
+            uint64_t load_start;
             int i, j, k;
-            void *dst;
 
             /* Select relocation address. */
             e = end - reloc_size;
@@ -852,11 +852,9 @@ void __init __start_xen(unsigned long mb
              * with a barrier(). After this we must *not* modify static/global
              * data until after we have switched to the relocated pagetables!
              */
+            load_start = (unsigned long)_start - XEN_VIRT_START;
             barrier();
-            dst = move_memory(e, 0, (unsigned long)&_end - XEN_VIRT_START, 1);
-
-            /* Poison low 1MB to detect stray pointers to physical 0-1MB. */
-            memset(dst, 0x55, 1U << 20);
+            move_memory(e + load_start, load_start, _end - _start, 1);
 
             /* Walk initial pagetables, relocating page directory entries. */
             pl4e = __va(__pa(idle_pg_table));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:15:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:15: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 1U5wm0-00076p-Ud; Thu, 14 Feb 2013 11:14: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 1U5wlz-00076k-Dd
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:14:39 +0000
Received: from [85.158.137.99:10501] by server-14.bemta-3.messagelabs.com id
	AF/9A-23533-E17CC115; Thu, 14 Feb 2013 11:14:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360840433!20581904!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28682 invoked from network); 14 Feb 2013 11:13:56 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:13:56 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 335F840046B;
	Thu, 14 Feb 2013 12:13:53 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id BvCDKTNXrM4X; Thu, 14 Feb 2013 12:13:52 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 12E0F40039F;
	Thu, 14 Feb 2013 12:13:51 +0100 (CET)
Message-ID: <511CC6EB.8050809@tiscali.it>
Date: Thu, 14 Feb 2013 12:13:47 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============4104613020789504851=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4104613020789504851==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030202010900050707080005"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030202010900050707080005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/02/2013 23:26, James Harper ha scritto:
>> I have tried to build gplpv from source with makedist.bat but it gave =
me
>> some errors about files not found.
>> I saw that latest commits were big. Is there something incomplete and
>> must I wait other commits before build it?
> It's possible I missed a commit but I can't see any missing files.
>
> Can you post the output of makedist?
>
> But yes the latest commits involve a pretty major change and I haven't =
tested save/restore yet so that is probably more broken than before.

I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at rev=20
1020.
I launched makedist.bat but it gives same errors on each arch build, see =

below the output:

=2E..
1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
1>Linking Executable -=20
waitnopendinginstallevents\waitnopendinginstallevents\obj
fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Thu Feb 14 11:53:50 2013
BUILD: Done

     75 files compiled
     2 libraries built
     8 executables built
Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

installer.wxs
Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system=20
cannot find
the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system=20
cannot find
the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system=20
cannot find
the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system=20
cannot find
  the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system=20
cannot find
  the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system=20
cannot find
  the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system=20
cannot find
  the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system=20
cannot find
  the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system=20
cannot find
  the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system=20
cannot find
  the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system=20
cannot find
  the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
SignTool Error: File not found: /t

>
>> I would like to see if new build fix network not working after restore=

>> on windows domUs using upstream qemu.
>> Dom0 is wheezy with xen-unstable from source.
>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
>> error on xen for now, probably is problem of gplpv with qemu upstream.=

>> Linux hvm domUs seem not have that problem, tested with quantal (ubunt=
u
>> 12.10) and network works also after restore.
>> If you need more details and tests tell me and I'll post it.
>>
>> Another problem present on both traditional/upstream qemu  with
>> older/new xen and  older/new gplpv is domU's time not correctly update=
d
>> after restore (it remains the time at the save operation), this is a b=
ig
>> problem with windows domUs (DC and client) in a windows domain where
>> the time source is DC by default.
> I noticed that recently. I can't think how it could be a GPLPV bug thou=
gh.

What can we try to narrow down the problem?

>
> James
>


--------------ms030202010900050707080005
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxNDExMTM0N1owIwYJKoZIhvcNAQkEMRYEFF3CLJq+l5fvp0F+4HXZXenP
GyteMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAsqwsYY0Qba/EIqbyHZc1zNE4
2Ef22L89/eQ+ujMDp6YppedPihsmWWg7T2hYiW9pA5BdMSofwzav7gJG6x+4izQc8zSBAFwn
hKQ96ilp1SD7eFxVczkJ5kdfIXy5YJfUsPuVQov9vibhFgJ0zEcnqCwB5eWt1VRIFsKkUB3o
PV3qyYIf8SaCZrDopZ184qwpN4IMt0qG+2MQMkYmWKCNig3+7A1VSGLHF2kKELFd+9n7huSO
HYXqdxqP+o8fgosA/u6twmjb0/cHXyN87fL0EZgQVbYOoq1DKSwtqajOYQXGA2pKilNi5gEA
U7VuggGDT5pxCFIovfKPnihzJoI8nQAAAAAAAA==
--------------ms030202010900050707080005--


--===============4104613020789504851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4104613020789504851==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 11:15:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:15: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 1U5wm0-00076p-Ud; Thu, 14 Feb 2013 11:14: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 1U5wlz-00076k-Dd
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:14:39 +0000
Received: from [85.158.137.99:10501] by server-14.bemta-3.messagelabs.com id
	AF/9A-23533-E17CC115; Thu, 14 Feb 2013 11:14:38 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360840433!20581904!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28682 invoked from network); 14 Feb 2013 11:13:56 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:13:56 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 335F840046B;
	Thu, 14 Feb 2013 12:13:53 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id BvCDKTNXrM4X; Thu, 14 Feb 2013 12:13:52 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 12E0F40039F;
	Thu, 14 Feb 2013 12:13:51 +0100 (CET)
Message-ID: <511CC6EB.8050809@tiscali.it>
Date: Thu, 14 Feb 2013 12:13:47 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============4104613020789504851=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4104613020789504851==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030202010900050707080005"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030202010900050707080005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/02/2013 23:26, James Harper ha scritto:
>> I have tried to build gplpv from source with makedist.bat but it gave =
me
>> some errors about files not found.
>> I saw that latest commits were big. Is there something incomplete and
>> must I wait other commits before build it?
> It's possible I missed a commit but I can't see any missing files.
>
> Can you post the output of makedist?
>
> But yes the latest commits involve a pretty major change and I haven't =
tested save/restore yet so that is probably more broken than before.

I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at rev=20
1020.
I launched makedist.bat but it gives same errors on each arch build, see =

below the output:

=2E..
1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
1>Linking Executable -=20
waitnopendinginstallevents\waitnopendinginstallevents\obj
fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Thu Feb 14 11:53:50 2013
BUILD: Done

     75 files compiled
     2 libraries built
     8 executables built
Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

installer.wxs
Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system=20
cannot find
the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system=20
cannot find
the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system=20
cannot find
the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system=20
cannot find
  the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system=20
cannot find
  the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system=20
cannot find
  the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system=20
cannot find
  the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system=20
cannot find
  the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system=20
cannot find
  the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system=20
cannot find
  the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system=20
cannot find
  the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
SignTool Error: File not found: /t

>
>> I would like to see if new build fix network not working after restore=

>> on windows domUs using upstream qemu.
>> Dom0 is wheezy with xen-unstable from source.
>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
>> error on xen for now, probably is problem of gplpv with qemu upstream.=

>> Linux hvm domUs seem not have that problem, tested with quantal (ubunt=
u
>> 12.10) and network works also after restore.
>> If you need more details and tests tell me and I'll post it.
>>
>> Another problem present on both traditional/upstream qemu  with
>> older/new xen and  older/new gplpv is domU's time not correctly update=
d
>> after restore (it remains the time at the save operation), this is a b=
ig
>> problem with windows domUs (DC and client) in a windows domain where
>> the time source is DC by default.
> I noticed that recently. I can't think how it could be a GPLPV bug thou=
gh.

What can we try to narrow down the problem?

>
> James
>


--------------ms030202010900050707080005
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxNDExMTM0N1owIwYJKoZIhvcNAQkEMRYEFF3CLJq+l5fvp0F+4HXZXenP
GyteMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAsqwsYY0Qba/EIqbyHZc1zNE4
2Ef22L89/eQ+ujMDp6YppedPihsmWWg7T2hYiW9pA5BdMSofwzav7gJG6x+4izQc8zSBAFwn
hKQ96ilp1SD7eFxVczkJ5kdfIXy5YJfUsPuVQov9vibhFgJ0zEcnqCwB5eWt1VRIFsKkUB3o
PV3qyYIf8SaCZrDopZ184qwpN4IMt0qG+2MQMkYmWKCNig3+7A1VSGLHF2kKELFd+9n7huSO
HYXqdxqP+o8fgosA/u6twmjb0/cHXyN87fL0EZgQVbYOoq1DKSwtqajOYQXGA2pKilNi5gEA
U7VuggGDT5pxCFIovfKPnihzJoI8nQAAAAAAAA==
--------------ms030202010900050707080005--


--===============4104613020789504851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4104613020789504851==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 11:17:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:17: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 1U5woB-0007Dm-I1; Thu, 14 Feb 2013 11:16:55 +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 1U5woA-0007Dc-Bj
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:16:54 +0000
Received: from [85.158.143.99:28881] by server-1.bemta-4.messagelabs.com id
	BD/37-08839-5A7CC115; Thu, 14 Feb 2013 11:16:53 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360840608!24134014!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25791 invoked from network); 14 Feb 2013 11:16:52 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 11:16:52 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5wo2-00034G-Hc; Thu, 14 Feb 2013 22:16:46 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 22:16:40 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTAgAAecoCAALiu8A==
Date: Thu, 14 Feb 2013 11:16:39 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
In-Reply-To: <511CC6EB.8050809@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.006
x-tm-as-result: No--51.020100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV 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

> 
> Il 13/02/2013 23:26, James Harper ha scritto:
> >> I have tried to build gplpv from source with makedist.bat but it gave me
> >> some errors about files not found.
> >> I saw that latest commits were big. Is there something incomplete and
> >> must I wait other commits before build it?
> > It's possible I missed a commit but I can't see any missing files.
> >
> > Can you post the output of makedist?
> >
> > But yes the latest commits involve a pretty major change and I haven't
> tested save/restore yet so that is probably more broken than before.
> 
> I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at rev
> 1020.
> I launched makedist.bat but it gives same errors on each arch build, see
> below the output:
> 

Ok so it can't find the cat files... I'll need the whole output of makedist.bat (or at least from the start of the wlh amd64 build) to find out - there must have been a previous error causing a failure to generate the cat files.

James


> ...
> 1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
> 1>Linking Executable -
> waitnopendinginstallevents\waitnopendinginstallevents\obj
> fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
> BUILD: Finish time: Thu Feb 14 11:53:50 2013
> BUILD: Done
> 
>      75 files compiled
>      2 libraries built
>      8 executables built
> Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> installer.wxs
> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system
> cannot find
> the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
> C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system
> cannot find
> the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
> C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system
> cannot find
> the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
> C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system
> cannot find
>   the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
> C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system
> cannot find
>   the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
> C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system
> cannot find
>   the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
> C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system
> cannot find
>   the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
> C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system
> cannot find
>   the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
> C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system
> cannot find
>   the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
> C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system
> cannot find
>   the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
> C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system
> cannot find
>   the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
> SignTool Error: File not found: /t
> 
> >
> >> I would like to see if new build fix network not working after restore
> >> on windows domUs using upstream qemu.
> >> Dom0 is wheezy with xen-unstable from source.
> >> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
> >> error on xen for now, probably is problem of gplpv with qemu upstream.
> >> Linux hvm domUs seem not have that problem, tested with quantal
> (ubuntu
> >> 12.10) and network works also after restore.
> >> If you need more details and tests tell me and I'll post it.
> >>
> >> Another problem present on both traditional/upstream qemu  with
> >> older/new xen and  older/new gplpv is domU's time not correctly
> updated
> >> after restore (it remains the time at the save operation), this is a big
> >> problem with windows domUs (DC and client) in a windows domain
> where
> >> the time source is DC by default.
> > I noticed that recently. I can't think how it could be a GPLPV bug though.
> 
> What can we try to narrow down the problem?
> 
> >
> > James
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:17:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:17: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 1U5woB-0007Dm-I1; Thu, 14 Feb 2013 11:16:55 +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 1U5woA-0007Dc-Bj
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:16:54 +0000
Received: from [85.158.143.99:28881] by server-1.bemta-4.messagelabs.com id
	BD/37-08839-5A7CC115; Thu, 14 Feb 2013 11:16:53 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360840608!24134014!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25791 invoked from network); 14 Feb 2013 11:16:52 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 11:16:52 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U5wo2-00034G-Hc; Thu, 14 Feb 2013 22:16:46 +1100
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 id
	14.01.0438.000; Thu, 14 Feb 2013 22:16:40 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTAgAAecoCAALiu8A==
Date: Thu, 14 Feb 2013 11:16:39 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
In-Reply-To: <511CC6EB.8050809@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19636.006
x-tm-as-result: No--51.020100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV 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

> 
> Il 13/02/2013 23:26, James Harper ha scritto:
> >> I have tried to build gplpv from source with makedist.bat but it gave me
> >> some errors about files not found.
> >> I saw that latest commits were big. Is there something incomplete and
> >> must I wait other commits before build it?
> > It's possible I missed a commit but I can't see any missing files.
> >
> > Can you post the output of makedist?
> >
> > But yes the latest commits involve a pretty major change and I haven't
> tested save/restore yet so that is probably more broken than before.
> 
> I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at rev
> 1020.
> I launched makedist.bat but it gives same errors on each arch build, see
> below the output:
> 

Ok so it can't find the cat files... I'll need the whole output of makedist.bat (or at least from the start of the wlh amd64 build) to find out - there must have been a previous error causing a failure to generate the cat files.

James


> ...
> 1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
> 1>Linking Executable -
> waitnopendinginstallevents\waitnopendinginstallevents\obj
> fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
> BUILD: Finish time: Thu Feb 14 11:53:50 2013
> BUILD: Done
> 
>      75 files compiled
>      2 libraries built
>      8 executables built
> Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> installer.wxs
> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
> C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system
> cannot find
> the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
> C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system
> cannot find
> the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
> C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system
> cannot find
> the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
> C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system
> cannot find
>   the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
> C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system
> cannot find
>   the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
> C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system
> cannot find
>   the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
> C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system
> cannot find
>   the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
> C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system
> cannot find
>   the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
> C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system
> cannot find
>   the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
> C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system
> cannot find
>   the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
> C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system
> cannot find
>   the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
> SignTool Error: File not found: /t
> 
> >
> >> I would like to see if new build fix network not working after restore
> >> on windows domUs using upstream qemu.
> >> Dom0 is wheezy with xen-unstable from source.
> >> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
> >> error on xen for now, probably is problem of gplpv with qemu upstream.
> >> Linux hvm domUs seem not have that problem, tested with quantal
> (ubuntu
> >> 12.10) and network works also after restore.
> >> If you need more details and tests tell me and I'll post it.
> >>
> >> Another problem present on both traditional/upstream qemu  with
> >> older/new xen and  older/new gplpv is domU's time not correctly
> updated
> >> after restore (it remains the time at the save operation), this is a big
> >> problem with windows domUs (DC and client) in a windows domain
> where
> >> the time source is DC by default.
> > I noticed that recently. I can't think how it could be a GPLPV bug though.
> 
> What can we try to narrow down the problem?
> 
> >
> > James
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:20:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:20: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 1U5wrK-0007Mh-64; Thu, 14 Feb 2013 11:20:10 +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 1U5wrI-0007MU-5J
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:20:08 +0000
Received: from [85.158.139.83:28867] by server-12.bemta-5.messagelabs.com id
	38/89-20195-768CC115; Thu, 14 Feb 2013 11:20:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360840806!32290412!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24367 invoked from network); 14 Feb 2013 11:20:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:20:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5wrF-000M1Q-EB; Thu, 14 Feb 2013 11:20:05 +0000
Date: Thu, 14 Feb 2013 11:20:05 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214112005.GG83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
	<20130207153459.GL77133@ocelot.phlegethon.org>
	<1360252296.32479.82.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360252296.32479.82.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/45] xen: arm64: 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>
Content-Type: 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:51 +0000 on 07 Feb (1360252296), Ian Campbell wrote:
> On Thu, 2013-02-07 at 15:34 +0000, Tim Deegan wrote:
> > At 14:42 +0000 on 07 Feb (1360248122), Tim Deegan wrote:
> > > The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> > > 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> > > that's useful if the slow path has a WFE in it?
> > 
> > OK, I see the arm64 versions are using the new load-acquire/store-release
> > instructions so no DSBs or DMBs should be necessary.  Still puzzled by
> > the SEV.
> 
> The ldar/strl generate the sev's as appropriate too.

OK.

We talked aout working the WFE into the loop for spinlocks, which would
be non-trivial since today that loop happens in common code.  I'm OK
with taking this much in to unblock other dev work, as long as a WFE is
going to happen eventually.

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 Thu Feb 14 11:20:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:20: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 1U5wrK-0007Mh-64; Thu, 14 Feb 2013 11:20:10 +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 1U5wrI-0007MU-5J
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:20:08 +0000
Received: from [85.158.139.83:28867] by server-12.bemta-5.messagelabs.com id
	38/89-20195-768CC115; Thu, 14 Feb 2013 11:20:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360840806!32290412!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24367 invoked from network); 14 Feb 2013 11:20:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:20:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5wrF-000M1Q-EB; Thu, 14 Feb 2013 11:20:05 +0000
Date: Thu, 14 Feb 2013 11:20:05 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214112005.GG83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-8-git-send-email-ian.campbell@citrix.com>
	<20130207144202.GH77133@ocelot.phlegethon.org>
	<20130207153459.GL77133@ocelot.phlegethon.org>
	<1360252296.32479.82.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360252296.32479.82.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 08/45] xen: arm64: 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>
Content-Type: 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:51 +0000 on 07 Feb (1360252296), Ian Campbell wrote:
> On Thu, 2013-02-07 at 15:34 +0000, Tim Deegan wrote:
> > At 14:42 +0000 on 07 Feb (1360248122), Tim Deegan wrote:
> > > The 32-bit ones have a scattering of DSBs and SEVs that aren't there in
> > > 64-bit.  The DSBs at least seem useful.  Not sure about SEV - presumably
> > > that's useful if the slow path has a WFE in it?
> > 
> > OK, I see the arm64 versions are using the new load-acquire/store-release
> > instructions so no DSBs or DMBs should be necessary.  Still puzzled by
> > the SEV.
> 
> The ldar/strl generate the sev's as appropriate too.

OK.

We talked aout working the WFE into the loop for spinlocks, which would
be non-trivial since today that loop happens in common code.  I'm OK
with taking this much in to unblock other dev work, as long as a WFE is
going to happen eventually.

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 Thu Feb 14 11:20:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:20: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 1U5wrU-0007NW-TV; Thu, 14 Feb 2013 11:20:20 +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 1U5wrT-0007NL-Se
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:20:20 +0000
Received: from [85.158.138.51:35044] by server-16.bemta-3.messagelabs.com id
	DE/CB-02727-E68CC115; Thu, 14 Feb 2013 11:20:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360840696!19454722!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16008 invoked from network); 14 Feb 2013 11:18:17 -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; 14 Feb 2013 11:18:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5woF-000M0i-M6; Thu, 14 Feb 2013 11:16:59 +0000
Date: Thu, 14 Feb 2013 11:16:59 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214111659.GF83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
	<20130207131247.GE77133@ocelot.phlegethon.org>
	<1360243206.32479.75.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360243206.32479.75.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/45] xen: arm64: initial build + config
	changes, start of day 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

At 13:20 +0000 on 07 Feb (1360243206), Ian Campbell wrote:
> On Thu, 2013-02-07 at 13:12 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956572), Ian Campbell wrote:
> > > diff --git a/config/arm64.mk b/config/arm64.mk
> > > new file mode 100644
> > > index 0000000..b2457eb
> > > --- /dev/null
> > > +++ b/config/arm64.mk
> > > @@ -0,0 +1,12 @@
> > > +CONFIG_ARM := y
> > > +CONFIG_ARM_64 := y
> > > +CONFIG_ARM_$(XEN_OS) := y
> > > +
> > > +CFLAGS += #-marm -march= -mcpu= etc
> > > +
> > > +HAS_PL011 := y
> > > +
> > > +# Use only if calling $(LD) directly.
> > > +LDFLAGS_DIRECT += -maarch64elf
> > > +
> > > +CONFIG_LOAD_ADDRESS ?= 0x80000000
> > > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> > > index f83bfee..2250366 100644
> > > --- a/xen/arch/arm/Rules.mk
> > > +++ b/xen/arch/arm/Rules.mk
> > > @@ -25,6 +25,12 @@ arm32 := y
> > >  arm64 := n
> > >  endif
> > >  
> > > +ifeq ($(TARGET_SUBARCH),arm64)
> > > +CFLAGS += -mcpu=generic
> > 
> > Should this go in config/arm64.mk?  I realise the equivalent flags for
> > arm32 are in this file, just wondering if we ought to tidy them all into
> > config/.
> 
> The x86 ones are in xen/arch/x86/Rules.mk too, I'm not averse to fixing
> that though (perhaps as a subsequent cleanup though?)

OK; no need to disturb this patch for it. 

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 Feb 14 11:20:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:20: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 1U5wrU-0007NW-TV; Thu, 14 Feb 2013 11:20:20 +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 1U5wrT-0007NL-Se
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:20:20 +0000
Received: from [85.158.138.51:35044] by server-16.bemta-3.messagelabs.com id
	DE/CB-02727-E68CC115; Thu, 14 Feb 2013 11:20:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360840696!19454722!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16008 invoked from network); 14 Feb 2013 11:18:17 -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; 14 Feb 2013 11:18:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5woF-000M0i-M6; Thu, 14 Feb 2013 11:16:59 +0000
Date: Thu, 14 Feb 2013 11:16:59 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214111659.GF83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-6-git-send-email-ian.campbell@citrix.com>
	<20130207131247.GE77133@ocelot.phlegethon.org>
	<1360243206.32479.75.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360243206.32479.75.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/45] xen: arm64: initial build + config
	changes, start of day 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

At 13:20 +0000 on 07 Feb (1360243206), Ian Campbell wrote:
> On Thu, 2013-02-07 at 13:12 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956572), Ian Campbell wrote:
> > > diff --git a/config/arm64.mk b/config/arm64.mk
> > > new file mode 100644
> > > index 0000000..b2457eb
> > > --- /dev/null
> > > +++ b/config/arm64.mk
> > > @@ -0,0 +1,12 @@
> > > +CONFIG_ARM := y
> > > +CONFIG_ARM_64 := y
> > > +CONFIG_ARM_$(XEN_OS) := y
> > > +
> > > +CFLAGS += #-marm -march= -mcpu= etc
> > > +
> > > +HAS_PL011 := y
> > > +
> > > +# Use only if calling $(LD) directly.
> > > +LDFLAGS_DIRECT += -maarch64elf
> > > +
> > > +CONFIG_LOAD_ADDRESS ?= 0x80000000
> > > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> > > index f83bfee..2250366 100644
> > > --- a/xen/arch/arm/Rules.mk
> > > +++ b/xen/arch/arm/Rules.mk
> > > @@ -25,6 +25,12 @@ arm32 := y
> > >  arm64 := n
> > >  endif
> > >  
> > > +ifeq ($(TARGET_SUBARCH),arm64)
> > > +CFLAGS += -mcpu=generic
> > 
> > Should this go in config/arm64.mk?  I realise the equivalent flags for
> > arm32 are in this file, just wondering if we ought to tidy them all into
> > config/.
> 
> The x86 ones are in xen/arch/x86/Rules.mk too, I'm not averse to fixing
> that though (perhaps as a subsequent cleanup though?)

OK; no need to disturb this patch for it. 

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 Feb 14 11:27:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:27: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 1U5wxo-0007jd-0Z; Thu, 14 Feb 2013 11:26: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 1U5wxm-0007jY-71
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:26:50 +0000
Received: from [85.158.139.83:35438] by server-15.bemta-5.messagelabs.com id
	C7/32-18914-9F9CC115; Thu, 14 Feb 2013 11:26:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360841187!27071800!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18917 invoked from network); 14 Feb 2013 11:26:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:26:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5wxO-000M2c-MQ; Thu, 14 Feb 2013 11:26:26 +0000
Date: Thu, 14 Feb 2013 11:26:26 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214112626.GH83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-18-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-18-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/45] xen: arm64: interrupt/abort
	mask/unmask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956584), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 11:27:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:27: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 1U5wxo-0007jd-0Z; Thu, 14 Feb 2013 11:26: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 1U5wxm-0007jY-71
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:26:50 +0000
Received: from [85.158.139.83:35438] by server-15.bemta-5.messagelabs.com id
	C7/32-18914-9F9CC115; Thu, 14 Feb 2013 11:26:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360841187!27071800!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18917 invoked from network); 14 Feb 2013 11:26:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:26:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5wxO-000M2c-MQ; Thu, 14 Feb 2013 11:26:26 +0000
Date: Thu, 14 Feb 2013 11:26:26 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214112626.GH83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-18-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-18-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/45] xen: arm64: interrupt/abort
	mask/unmask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956584), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 11:27:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:27: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 1U5wy2-0007kg-GF; Thu, 14 Feb 2013 11:27:06 +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 1U5wy1-0007kR-Ha
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:27:05 +0000
Received: from [85.158.139.83:27061] by server-6.bemta-5.messagelabs.com id
	BC/43-01489-80ACC115; Thu, 14 Feb 2013 11:27:04 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360841138!29863776!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22994 invoked from network); 14 Feb 2013 11:25:39 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:25:39 -0000
Received: by mail-wg0-f44.google.com with SMTP id dr12so1748213wgb.11
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 03:25:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding;
	bh=bq5K4f/ZrTFCpY5w9QnZJBYqf+JU6c5cPSwycRmJf1o=;
	b=QchWEzEY3iQBso6V4ae8FZuwp73VLIrWnGEYB4kieHtnxfv/ubyqFrtagOCtiyUEEh
	wIG6KHnj2r5dfQdqMQyZA0z3afxbAMHW+WA7CbJXp9SsoVA76DdZ/9q9a2GhAJDktJBU
	dCohIplOaGtDmSk9gfLwUH89wrh7XXnf7PwtTEla+azaKCXcsXkRGDSWIRRRCWLZhHbj
	cmzIyaP6gkdXaZcleWwc3W7dycNVD0RcO0XAB+RKo8fCCjqC/uQ9Rw4Wp9UDAa2St3Xr
	/dVRkqiw+TYNRgxEVQEbSWQ1j4oxzULfRXtX6lFYAmNwR5RIbyQZBoHHsG+cq1Wv3jUK
	EFqA==
X-Received: by 10.180.79.37 with SMTP id g5mr8176343wix.24.1360841113208;
	Thu, 14 Feb 2013 03:25:13 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id bg5sm10123136wib.8.2013.02.14.03.25.10
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 03:25:12 -0800 (PST)
Message-ID: <511CC995.6050709@cantab.net>
Date: Thu, 14 Feb 2013 11:25:09 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <510C3AA3.2090508@theshore.net>	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	<51181924.4050500@theshore.net>	<1360583103.16636.29.camel@zion.uk.xensource.com>	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	<511AFFC9.3050404@theshore.net>	<1360779868.16636.92.camel@zion.uk.xensource.com>	<1360780669.16636.94.camel@zion.uk.xensource.com>	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
In-Reply-To: <511CB86702000078000BE1C5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.0.1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14/02/13 09:11, Jan Beulich wrote:
>
> I first thought so too when looking at this again yesterday, but
> then convinced myself that this double put _here_ is correct. And
> Ian's patch specifically removed to call to netbk_tx_err() after the
> caller netbk_count_requests() recognized the error, knowing that
> the latter function now itself issues a call to netbk_fatal_tx_err()
> (whether that wouldn't better have replaced the caller's call to
> netbk_tx_err() is a different question).

Yes, I agree.  I had too many different versions of netback open and got
confused.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:27:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:27: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 1U5wy2-0007kg-GF; Thu, 14 Feb 2013 11:27:06 +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 1U5wy1-0007kR-Ha
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:27:05 +0000
Received: from [85.158.139.83:27061] by server-6.bemta-5.messagelabs.com id
	BC/43-01489-80ACC115; Thu, 14 Feb 2013 11:27:04 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360841138!29863776!1
X-Originating-IP: [74.125.82.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22994 invoked from network); 14 Feb 2013 11:25:39 -0000
Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com)
	(74.125.82.44)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:25:39 -0000
Received: by mail-wg0-f44.google.com with SMTP id dr12so1748213wgb.11
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 03:25:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:user-agent:mime-version:to
	:cc:subject:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding;
	bh=bq5K4f/ZrTFCpY5w9QnZJBYqf+JU6c5cPSwycRmJf1o=;
	b=QchWEzEY3iQBso6V4ae8FZuwp73VLIrWnGEYB4kieHtnxfv/ubyqFrtagOCtiyUEEh
	wIG6KHnj2r5dfQdqMQyZA0z3afxbAMHW+WA7CbJXp9SsoVA76DdZ/9q9a2GhAJDktJBU
	dCohIplOaGtDmSk9gfLwUH89wrh7XXnf7PwtTEla+azaKCXcsXkRGDSWIRRRCWLZhHbj
	cmzIyaP6gkdXaZcleWwc3W7dycNVD0RcO0XAB+RKo8fCCjqC/uQ9Rw4Wp9UDAa2St3Xr
	/dVRkqiw+TYNRgxEVQEbSWQ1j4oxzULfRXtX6lFYAmNwR5RIbyQZBoHHsG+cq1Wv3jUK
	EFqA==
X-Received: by 10.180.79.37 with SMTP id g5mr8176343wix.24.1360841113208;
	Thu, 14 Feb 2013 03:25:13 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id bg5sm10123136wib.8.2013.02.14.03.25.10
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 03:25:12 -0800 (PST)
Message-ID: <511CC995.6050709@cantab.net>
Date: Thu, 14 Feb 2013 11:25:09 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <510C3AA3.2090508@theshore.net>	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	<51181924.4050500@theshore.net>	<1360583103.16636.29.camel@zion.uk.xensource.com>	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	<511AFFC9.3050404@theshore.net>	<1360779868.16636.92.camel@zion.uk.xensource.com>	<1360780669.16636.94.camel@zion.uk.xensource.com>	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
In-Reply-To: <511CB86702000078000BE1C5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.0.1
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14/02/13 09:11, Jan Beulich wrote:
>
> I first thought so too when looking at this again yesterday, but
> then convinced myself that this double put _here_ is correct. And
> Ian's patch specifically removed to call to netbk_tx_err() after the
> caller netbk_count_requests() recognized the error, knowing that
> the latter function now itself issues a call to netbk_fatal_tx_err()
> (whether that wouldn't better have replaced the caller's call to
> netbk_tx_err() is a different question).

Yes, I agree.  I had too many different versions of netback open and got
confused.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:29:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:29: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 1U5wzv-0007vp-AA; Thu, 14 Feb 2013 11:29:03 +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 1U5wzt-0007vV-D9
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:29:01 +0000
Received: from [85.158.139.211:27860] by server-15.bemta-5.messagelabs.com id
	35/18-18914-C7ACC115; Thu, 14 Feb 2013 11:29:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360841336!22453092!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8140 invoked from network); 14 Feb 2013 11:28:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:28:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:28:56 +0000
Message-Id: <511CD8C202000078000BE280@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:29:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>, "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
In-Reply-To: <CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
> 
> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9 

This is really odd: The "iommu=debug" output you made available
shows that while there are further devices that have no associated
IOMMU, the bus scan done in the hypervisor didn't even find a
device at 06:00.1. Which I see possible only in two ways: Either
the device becomes visible on the bus only when the driver for
06:00.0 loads (and is otherwise detectable only by other means,
e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
properly set. That latter aspect could be checked by looking at
the raw (hex) config space dump of 06:00.0.

Boris, one other thought I had in this context: Is it really possible
for functions on the same (non-bridge) device to be serviced
by different IOMMUs? If not, find_iommu_for_device() could simply
look for function 0 if nothing is known about the passed in function.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:29:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:29: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 1U5wzv-0007vp-AA; Thu, 14 Feb 2013 11:29:03 +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 1U5wzt-0007vV-D9
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:29:01 +0000
Received: from [85.158.139.211:27860] by server-15.bemta-5.messagelabs.com id
	35/18-18914-C7ACC115; Thu, 14 Feb 2013 11:29:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360841336!22453092!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8140 invoked from network); 14 Feb 2013 11:28:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:28:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:28:56 +0000
Message-Id: <511CD8C202000078000BE280@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:29:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "povder" <povder@gmail.com>, "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPxtjVz0+2QELnpbBUdtvYUXJVeDUMRMe9XjzHanDOxH3Q@mail.gmail.com>
	<511A224A02000078000BDA7B@nat28.tlf.novell.com>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
In-Reply-To: <CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
> 
> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9 

This is really odd: The "iommu=debug" output you made available
shows that while there are further devices that have no associated
IOMMU, the bus scan done in the hypervisor didn't even find a
device at 06:00.1. Which I see possible only in two ways: Either
the device becomes visible on the bus only when the driver for
06:00.0 loads (and is otherwise detectable only by other means,
e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
properly set. That latter aspect could be checked by looking at
the raw (hex) config space dump of 06:00.0.

Boris, one other thought I had in this context: Is it really possible
for functions on the same (non-bridge) device to be serviced
by different IOMMUs? If not, find_iommu_for_device() could simply
look for function 0 if nothing is known about the passed in function.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:30:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x0z-00082w-Rn; Thu, 14 Feb 2013 11:30: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 1U5x0y-00082Z-Ig
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:30:08 +0000
Received: from [85.158.137.99:60311] by server-10.bemta-3.messagelabs.com id
	7A/6F-10609-FBACC115; Thu, 14 Feb 2013 11:30:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360841405!21400748!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13233 invoked from network); 14 Feb 2013 11:30:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:30:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7113782"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:30:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:30:04 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5wzd-0004IS-MB;
	Thu, 14 Feb 2013 11:28:45 +0000
Date: Thu, 14 Feb 2013 11:28:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359049058.32057.37.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141126090.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1301161853130.4978@kaball.uk.xensource.com>
	<1358362736-2870-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1359049058.32057.37.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/4] xen: move XEN_SYSCTL_physinfo,
 XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common 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 Thu, 24 Jan 2013, Ian Campbell wrote:
> On Wed, 2013-01-16 at 18:58 +0000, Stefano Stabellini wrote:
> > @ -93,9 +93,9 @@ int __init init_xen_time(void)
> >      if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
> >          panic("CPU does not support the Generic Timer v1 interface.\n");
> > 
> > -    cntfrq = READ_CP32(CNTFRQ);
> > +    cpu_khz = READ_CP32(CNTFRQ) / 1000;
> 
> Does the loss of precision here matter in practice? Would we be better
> off sticking with cntfrq and doing the divide in arch_do_physinfo?

We need to export cpu_khz anyway because it is exported in
xen/include/xen/time.h.
We can only decide to keep an additional internal cntfrq variable.
However I don't think that we need to worry about it practice.
After all khz have been enough on x86 for all these years..


> > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> > index 4ed5df6..96b36c2 100644
> > --- a/xen/include/asm-arm/mm.h
> > +++ b/xen/include/asm-arm/mm.h
> > @@ -136,6 +136,9 @@ extern unsigned long frametable_base_mfn;
> > 
> >  extern unsigned long max_page;
> >  extern unsigned long total_pages;
> > +/* XXX: implement NUMA support */
> > +#define node_spanned_pages(nid)        (total_pages)
> > +#define __node_distance(a, b) (20)
> 
> Please put these in asm-arm/numa.h

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:30:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x0z-00082w-Rn; Thu, 14 Feb 2013 11:30: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 1U5x0y-00082Z-Ig
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:30:08 +0000
Received: from [85.158.137.99:60311] by server-10.bemta-3.messagelabs.com id
	7A/6F-10609-FBACC115; Thu, 14 Feb 2013 11:30:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360841405!21400748!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13233 invoked from network); 14 Feb 2013 11:30:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:30:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7113782"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:30:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:30:04 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5wzd-0004IS-MB;
	Thu, 14 Feb 2013 11:28:45 +0000
Date: Thu, 14 Feb 2013 11:28:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359049058.32057.37.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141126090.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1301161853130.4978@kaball.uk.xensource.com>
	<1358362736-2870-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1359049058.32057.37.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/4] xen: move XEN_SYSCTL_physinfo,
 XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common 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 Thu, 24 Jan 2013, Ian Campbell wrote:
> On Wed, 2013-01-16 at 18:58 +0000, Stefano Stabellini wrote:
> > @ -93,9 +93,9 @@ int __init init_xen_time(void)
> >      if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
> >          panic("CPU does not support the Generic Timer v1 interface.\n");
> > 
> > -    cntfrq = READ_CP32(CNTFRQ);
> > +    cpu_khz = READ_CP32(CNTFRQ) / 1000;
> 
> Does the loss of precision here matter in practice? Would we be better
> off sticking with cntfrq and doing the divide in arch_do_physinfo?

We need to export cpu_khz anyway because it is exported in
xen/include/xen/time.h.
We can only decide to keep an additional internal cntfrq variable.
However I don't think that we need to worry about it practice.
After all khz have been enough on x86 for all these years..


> > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> > index 4ed5df6..96b36c2 100644
> > --- a/xen/include/asm-arm/mm.h
> > +++ b/xen/include/asm-arm/mm.h
> > @@ -136,6 +136,9 @@ extern unsigned long frametable_base_mfn;
> > 
> >  extern unsigned long max_page;
> >  extern unsigned long total_pages;
> > +/* XXX: implement NUMA support */
> > +#define node_spanned_pages(nid)        (total_pages)
> > +#define __node_distance(a, b) (20)
> 
> Please put these in asm-arm/numa.h

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:30:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x1d-00087O-D2; Thu, 14 Feb 2013 11:30:49 +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 1U5x1b-000875-UV
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:30:48 +0000
Received: from [193.109.254.147:44296] by server-10.bemta-14.messagelabs.com
	id 71/41-12679-7EACC115; Thu, 14 Feb 2013 11:30:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360841413!8676112!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4469 invoked from network); 14 Feb 2013 11:30:14 -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;
	14 Feb 2013 11:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7113794"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:30:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:30:12 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5wrr-0004Au-UL;
	Thu, 14 Feb 2013 11:20:43 +0000
Message-ID: <1360840843.16636.109.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 11:20:43 +0000
In-Reply-To: <511CB86702000078000BE1C5@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 09:11 +0000, Jan Beulich wrote:
> >>> On 13.02.13 at 21:17, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
> >> On 13/02/13 18:37, Wei Liu wrote:
> >> > A slightly upgraded version of the *UNTESTED* patch.
> >> > 
> >> > 
> >> > Wei.
> >> > 
> >> > ----8<----
> >> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> >> > Author: Wei Liu <wei.liu2@citrix.com>
> >> > Date:   Wed Feb 13 18:17:01 2013 +0000
> >> > 
> >> >     netback: fix netbk_count_requests
> >> >     
> >> >     There are two paths in the original code, a) test against work_to_do, 
> > b) test
> >> >     against first->size, could return 0 even when error happens.
> >> >     
> >> >     Simply return -1 in error paths should work. Modify all error paths to 
> > return
> >> >     -1 to be consistent.
> >> 
> >> You also need to remove the netbk_tx_err() after checking the result of
> >> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
> >> which will screw up ref counting.
> > 
> > I just realized that we were talking about different code path when I
> > walked home.
> > 
> > The path you mentioned is correct. As excution flow should never reach
> > there if there is error in netbk_count_requests.
> > 
> > The path I'm not sure is that in the netbk_fatal_tx_err, it calls
> > xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
> > which is likely to mess up the refcount.
> 
> I first thought so too when looking at this again yesterday, but
> then convinced myself that this double put _here_ is correct. And
> Ian's patch specifically removed to call to netbk_tx_err() after the
> caller netbk_count_requests() recognized the error, knowing that
> the latter function now itself issues a call to netbk_fatal_tx_err()
> (whether that wouldn't better have replaced the caller's call to
> netbk_tx_err() is a different question).
> 

I'm not convinced. netbk_tx_err only has one xenvif_put, however
netbk_fatal_tx_err has two puts.

If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
will hit this bug soon when shutting down DomU.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:30:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x1d-00087O-D2; Thu, 14 Feb 2013 11:30:49 +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 1U5x1b-000875-UV
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:30:48 +0000
Received: from [193.109.254.147:44296] by server-10.bemta-14.messagelabs.com
	id 71/41-12679-7EACC115; Thu, 14 Feb 2013 11:30:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360841413!8676112!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4469 invoked from network); 14 Feb 2013 11:30:14 -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;
	14 Feb 2013 11:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7113794"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:30:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:30:12 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5wrr-0004Au-UL;
	Thu, 14 Feb 2013 11:20:43 +0000
Message-ID: <1360840843.16636.109.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 11:20:43 +0000
In-Reply-To: <511CB86702000078000BE1C5@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 09:11 +0000, Jan Beulich wrote:
> >>> On 13.02.13 at 21:17, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
> >> On 13/02/13 18:37, Wei Liu wrote:
> >> > A slightly upgraded version of the *UNTESTED* patch.
> >> > 
> >> > 
> >> > Wei.
> >> > 
> >> > ----8<----
> >> > commit df4c929d034cec7043fbd96ba89833eb639c336e
> >> > Author: Wei Liu <wei.liu2@citrix.com>
> >> > Date:   Wed Feb 13 18:17:01 2013 +0000
> >> > 
> >> >     netback: fix netbk_count_requests
> >> >     
> >> >     There are two paths in the original code, a) test against work_to_do, 
> > b) test
> >> >     against first->size, could return 0 even when error happens.
> >> >     
> >> >     Simply return -1 in error paths should work. Modify all error paths to 
> > return
> >> >     -1 to be consistent.
> >> 
> >> You also need to remove the netbk_tx_err() after checking the result of
> >> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
> >> which will screw up ref counting.
> > 
> > I just realized that we were talking about different code path when I
> > walked home.
> > 
> > The path you mentioned is correct. As excution flow should never reach
> > there if there is error in netbk_count_requests.
> > 
> > The path I'm not sure is that in the netbk_fatal_tx_err, it calls
> > xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
> > which is likely to mess up the refcount.
> 
> I first thought so too when looking at this again yesterday, but
> then convinced myself that this double put _here_ is correct. And
> Ian's patch specifically removed to call to netbk_tx_err() after the
> caller netbk_count_requests() recognized the error, knowing that
> the latter function now itself issues a call to netbk_fatal_tx_err()
> (whether that wouldn't better have replaced the caller's call to
> netbk_tx_err() is a different question).
> 

I'm not convinced. netbk_tx_err only has one xenvif_put, however
netbk_fatal_tx_err has two puts.

If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
will hit this bug soon when shutting down DomU.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:32:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x3S-0008LA-UH; Thu, 14 Feb 2013 11:32:42 +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 1U5x3R-0008Kx-1H
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:32:41 +0000
Received: from [193.109.254.147:7436] by server-16.bemta-14.messagelabs.com id
	E0/2C-25906-85BCC115; Thu, 14 Feb 2013 11:32:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360841559!10302226!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21080 invoked from network); 14 Feb 2013 11:32:39 -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; 14 Feb 2013 11:32:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5x3O-000M3n-5v; Thu, 14 Feb 2013 11:32:38 +0000
Date: Thu, 14 Feb 2013 11:32:38 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214113238.GI83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-19-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-19-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/45] xen: arm64: div64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956585), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 11:32:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x3S-0008LA-UH; Thu, 14 Feb 2013 11:32:42 +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 1U5x3R-0008Kx-1H
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:32:41 +0000
Received: from [193.109.254.147:7436] by server-16.bemta-14.messagelabs.com id
	E0/2C-25906-85BCC115; Thu, 14 Feb 2013 11:32:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360841559!10302226!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21080 invoked from network); 14 Feb 2013 11:32:39 -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; 14 Feb 2013 11:32:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5x3O-000M3n-5v; Thu, 14 Feb 2013 11:32:38 +0000
Date: Thu, 14 Feb 2013 11:32:38 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214113238.GI83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-19-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-19-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/45] xen: arm64: div64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956585), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 11:34:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:34: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 1U5x5B-00006D-FA; Thu, 14 Feb 2013 11:34:29 +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 1U5x59-00005z-Bg
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:34:28 +0000
Received: from [193.109.254.147:17266] by server-12.bemta-14.messagelabs.com
	id A7/C3-32582-2CBCC115; Thu, 14 Feb 2013 11:34:26 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360841529!9275007!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=1.1 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	WEIRD_QUOTING,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13988 invoked from network); 14 Feb 2013 11:32:10 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 11:32:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id E03F740046B;
	Thu, 14 Feb 2013 12:32:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id g49FLElSYeS3; Thu, 14 Feb 2013 12:32:06 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id B8409400168;
	Thu, 14 Feb 2013 12:32:03 +0100 (CET)
Message-ID: <511CCB2F.20608@tiscali.it>
Date: Thu, 14 Feb 2013 12:31:59 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============5091798994668425114=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============5091798994668425114==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070601000809040705060906"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070601000809040705060906
Content-Type: multipart/mixed;
 boundary="------------050404090607090400010101"

This is a multi-part message in MIME format.
--------------050404090607090400010101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 14/02/2013 12:16, James Harper ha scritto:
>> Il 13/02/2013 23:26, James Harper ha scritto:
>>>> I have tried to build gplpv from source with makedist.bat but it gav=
e me
>>>> some errors about files not found.
>>>> I saw that latest commits were big. Is there something incomplete an=
d
>>>> must I wait other commits before build it?
>>> It's possible I missed a commit but I can't see any missing files.
>>>
>>> Can you post the output of makedist?
>>>
>>> But yes the latest commits involve a pretty major change and I haven'=
t
>> tested save/restore yet so that is probably more broken than before.
>>
>> I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at re=
v
>> 1020.
>> I launched makedist.bat but it gives same errors on each arch build, s=
ee
>> below the output:
>>
> Ok so it can't find the cat files... I'll need the whole output of make=
dist.bat (or at least from the start of the wlh amd64 build) to find out =
- there must have been a previous error causing a failure to generate the=
 cat files.
>
> James
>

I added as attachment the build log for this, can be sufficent? If you=20
need other test/data tell me and I'll post them.

>> ...
>> 1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
>> 1>Linking Executable -
>> waitnopendinginstallevents\waitnopendinginstallevents\obj
>> fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
>> BUILD: Finish time: Thu Feb 14 11:53:50 2013
>> BUILD: Done
>>
>>       75 files compiled
>>       2 libraries built
>>       8 executables built
>> Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> installer.wxs
>> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system
>> cannot find
>> the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system
>> cannot find
>> the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>> C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system
>> cannot find
>> the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
>> C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
>> C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system
>> cannot find
>>    the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
>> C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
>> C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>> SignTool Error: File not found: /t
>>
>>>> I would like to see if new build fix network not working after resto=
re
>>>> on windows domUs using upstream qemu.
>>>> Dom0 is wheezy with xen-unstable from source.
>>>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
>>>> error on xen for now, probably is problem of gplpv with qemu upstrea=
m.
>>>> Linux hvm domUs seem not have that problem, tested with quantal
>> (ubuntu
>>>> 12.10) and network works also after restore.
>>>> If you need more details and tests tell me and I'll post it.
>>>>
>>>> Another problem present on both traditional/upstream qemu  with
>>>> older/new xen and  older/new gplpv is domU's time not correctly
>> updated
>>>> after restore (it remains the time at the save operation), this is a=
 big
>>>> problem with windows domUs (DC and client) in a windows domain
>> where
>>>> the time source is DC by default.
>>> I noticed that recently. I can't think how it could be a GPLPV bug th=
ough.
>> What can we try to narrow down the problem?
>>
>>> James
>>>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2899 / Database dei virus: 2639/6101 -  Data di rilasc=
io: 13/02/2013
>
>
>


--------------050404090607090400010101
Content-Type: text/plain; charset=windows-1252;
 name="buildfre_wlh_amd64.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="buildfre_wlh_amd64.log"

BUILD: Examining c:\hg\win-pvdrivers directory tree for files to compile.=

oacr invalidate root:amd64fre /autocleanqueue
1>Building generated files in c:\hg\win-pvdrivers\xenpci *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenpci
2>Building generated files in c:\hg\win-pvdrivers\xenvbd_scsiport *******=
******
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_scsiport
1> copy xenpci.inx c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenp=
ci.inf
1> 1 file copiati.
1> stampinf -f c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.i=
nf -a AMD64 -d * -k 1.9 -v 0.11.0.5
2> copy xenvbd.inx c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\a=
md64\xenvbd.inf
1>Stamping c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.inf [=
Version] section with DriverVer=3D02/14/2013,0.11.0.5
1>Building generated files in c:\hg\win-pvdrivers\xenvbd_storport *******=
******
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_storport
2> 1 file copiati.
2> stampinf -f c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64=
\xenvbd.inf -a AMD64 -d * -v 0.11.0.5
2>Stamping c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xen=
vbd.inf [Version] section with DriverVer=3D02/14/2013,0.11.0.5
2>Building generated files in c:\hg\win-pvdrivers\xennet *************
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xennet
1> copy xenvbd.inx c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\a=
md64\xenvbd.inf
2> copy xennet.inx c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xenn=
et.inf
1> 1 file copiati.
1> stampinf -f c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64=
\xenvbd.inf -a AMD64 -d * -v 0.11.0.5
2> 1 file copiati.
2> stampinf -f c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.i=
nf -a AMD64 -d * -v 0.11.0.5
1>Stamping c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xen=
vbd.inf [Version] section with DriverVer=3D02/14/2013,0.11.0.5
2>Stamping c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.inf [=
Version] section with DriverVer=3D02/14/2013,0.11.0.5
1>Compiling (NoSync) c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_win=
dows_kernel *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i /nologo /f c:\winddk\7600.16385.=
0\bin\makefile.def BUILD_PASS=3DPASS1 NOLINK=3D1 MAKEDIR_RELATIVE_TO_BASE=
DIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_w=
indows_kernel
2>Compiling (NoSync) c:\hg\win-pvdrivers\xenpci *************
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS1 NOLINK=3D1 MA=
KEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenpci
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel: TARGET=
PATH is ../../bin/
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\libl=
fds.6\src\single_dir_for_windows_kernel\objfre_wlh_amd64\amd64\cl.rsp
2> ml64 /c /Cx /nologo /Iamd64\ /I. /I..\common\include /I..\common\inclu=
de\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrivers\xenpci\objfre_wlh_amd6=
4\amd64 /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\api=
 /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\W=
inDDK\7600.16385.0\inc\wdf\kmdf\1.9 /IC:\WinDDK\7600.16385.0\inc\crt  /Zi=
 /D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_=
INST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600=
 /DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1 /DDB=
G=3D0  /DDEVL=3D1 /D__BUILDMACHINE__=3DWinDDK  /Foc:\hg\win-pvdrivers\xen=
pci\objfre_wlh_amd64\amd64\hypercall.obj amd64\hypercall.asm
2> Assembling: amd64\hypercall.asm
2> ml64 /c /Cx /nologo /Iamd64\ /I. /I..\common\include /I..\common\inclu=
de\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrivers\xenpci\objfre_wlh_amd6=
4\amd64 /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\api=
 /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\W=
inDDK\7600.16385.0\inc\wdf\kmdf\1.9 /IC:\WinDDK\7600.16385.0\inc\crt  /Zi=
 /D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_=
INST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600=
 /DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1 /DDB=
G=3D0  /DDEVL=3D1 /D__BUILDMACHINE__=3DWinDDK  /Foc:\hg\win-pvdrivers\xen=
pci\objfre_wlh_amd64\amd64\dbgprint_hook.obj amd64\dbgprint_hook.asm
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
2> Assembling: amd64\dbgprint_hook.asm
1>cl /Fo"c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\=
objfre_wlh_amd64\amd64/"
1> /FC
1> /MT
1> /U_MT
1> /Iamd64\
1> /I.
1> /I..
1> /I../../inc/
1> /Ic:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objf=
re_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /DNTDDI_VERSION=3D0x06000100
1> /c
1> /Zc:wchar_t-
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenp=
ci\objfre_wlh_amd64\amd64\cl.rsp
1> /Zl
1> /Zp8
1> /Gy
1> -cbstring
1> /WX
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Z7
1> /Oxs
1> /GL
1> /Z7
1> /DWIN_KERNEL_BUILD
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\abstraction_aligned_free.c .\abstraction_aligned_malloc.c .\abstract=
ion_cas.c .\abstraction_dcas.c .\abstraction_increment.c .\freelist_delet=
e.c .\freelist_get_and_set.c .\freelist_new.c .\freelist_pop_push.c .\fre=
elist_query.c .\queue_delete.c .\queue_new.c .\queue_query.c .\queue_queu=
e.c .\ringbuffer_delete.c .\ringbuffer_get_and_put.c .\ringbuffer_new.c .=
\ringbuffer_query.c .\slist_delete.c .\slist_get_and_set.c .\slist_link.c=
 .\slist_new.c .\stack_delete.c .\stack_new.c .\stack_push_pop.c .\stack_=
query.c=20
1>abstraction_aligned_free.c
1>abstraction_aligned_malloc.c
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1.9
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
2> /DNDEBUG
2> /D_DLL=3D1
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION=3D1
2> /DKMDF_MINOR_VERSION=3D9
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xenpci.c .\xenpci_fdo.c .\xenpci_pdo.c .\xenpci_export.c .\evtchn.c =
=2E\gnttbl.c .\xenbus.c .\memory.c .\xenpci_device_interface.c .\xenbus_d=
evice_interface.c .\xenpci_highsync.c .\xenpci_patch_kernel.c .\xenpci_db=
gprint.c=20
2>xenpci.c
1>abstraction_cas.c
1>abstraction_dcas.c
2>xenpci_fdo.c
1>abstraction_increment.c
1>freelist_delete.c
1>freelist_get_and_set.c
2>xenpci_pdo.c
1>freelist_new.c
1>freelist_pop_push.c
2>xenpci_export.c
1>freelist_query.c
1>queue_delete.c
1>queue_new.c
2>evtchn.c
1>queue_query.c
1>queue_queue.c
1>ringbuffer_delete.c
2>gnttbl.c
1>ringbuffer_get_and_put.c
1>ringbuffer_new.c
1>ringbuffer_query.c
2>xenbus.c
1>slist_delete.c
1>slist_get_and_set.c
2>memory.c
1>Compiling...
1>slist_link.c
1>slist_new.c
2>xenpci_device_interface.c
1>stack_delete.c
1>stack_new.c
2>xenbus_device_interface.c
1>stack_push_pop.c
1>stack_query.c
2>xenpci_highsync.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /lib /out:../../bin/\am=
d64\liblfds.lib /IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221=
,4108,4088,4218,4218,4235  /WX /nodefaultlib /machine:amd64 /ltcg @c:\hg\=
win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_wlh_amd6=
4\amd64\lib.rsp
1>Microsoft (R) Library Manager Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_aligned_free.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_aligned_malloc.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_cas.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_dcas.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_increment.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_get_and_set.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_pop_push.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_query.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_query.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_queue.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_get_and_put.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_query.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_get_and_set.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_link.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_push_pop.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_query.obj=20
2>xenpci_patch_kernel.c
2>xenpci_dbgprint.c
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /lib /out:c:\hg\win-pvd=
rivers\xenpci\objfre_wlh_amd64\amd64\xenpci.lib @c:\hg\win-pvdrivers\xenp=
ci\objfre_wlh_amd64\amd64\lib.rsp
2>Microsoft (R) Library Manager Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/WX=20
2>/nodefaultlib=20
2>/machine:amd64=20
2>/ltcg=20
2>/def:xenpci.def=20
2>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\hypercall.obj c:\hg\w=
in-pvdrivers\xenpci\objfre_wlh_amd64\amd64\dbgprint_hook.obj c:\hg\win-pv=
drivers\xenpci\objfre_wlh_amd64\amd64\xenpci.obj c:\hg\win-pvdrivers\xenp=
ci\objfre_wlh_amd64\amd64\xenpci_fdo.obj c:\hg\win-pvdrivers\xenpci\objfr=
e_wlh_amd64\amd64\xenpci_pdo.obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_am=
d64\amd64\xenpci_export.obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\a=
md64\evtchn.obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\gnttbl.=
obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus.obj c:\hg\wi=
n-pvdrivers\xenpci\objfre_wlh_amd64\amd64\memory.obj c:\hg\win-pvdrivers\=
xenpci\objfre_wlh_amd64\amd64\xenpci_device_interface.obj c:\hg\win-pvdri=
vers\xenpci\objfre_wlh_amd64\amd64\xenbus_device_interface.obj c:\hg\win-=
pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_highsync.obj c:\hg\win-pvd=
rivers\xenpci\objfre_wlh_amd64\amd64\xenpci_patch_kernel.obj c:\hg\win-pv=
drivers\xenpci\objfre_wlh_amd64\amd64\xenpci_dbgprint.obj=20
2> Creating library c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xen=
pci.lib and object c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenp=
ci.exp
1>Linking for c:\hg\win-pvdrivers\xenpci *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDLL=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenpci
2>Compiling and Linking c:\hg\win-pvdrivers\xenvbd_scsiport *************=

2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_scsiport
2> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenvbd.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.res /=
D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_IN=
ST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /=
DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEV=
L=3D1 /D__BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_=
NUMBER=3D5 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..\common\=
include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrive=
rs\xenvbd_scsiport\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\ap=
i /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\=
WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\crt .\xenvbd.rc
1> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenpci.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.res /D_WIN64 /=
D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_INST=3D0 /D=
WIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /DWINVER=3D=
0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEVL=3D1 /D__=
BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_NUMBER=3D5=
 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..\common\include /I=
=2E.\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrivers\xenpc=
i\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\760=
0.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385=
=2E0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1.9 /IC:\WinDDK\7600.1=
6385.0\inc\crt .\xenpci.rc
2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenv=
bd_scsiport\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenpci\objfre_wlh_amd64\amd64\xenpci.sys /machine:amd64 @c:\hg\win-pvdr=
ivers\xenpci\objfre_wlh_amd64\amd64\lnk.rsp
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/subsystem:native,6.00=20
1>/base:0x10000=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.sys=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.exp=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.res=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\hypercall.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\dbgprint_hook.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.obj=20
2> /DNDEBUG
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_fdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_pdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_export.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\evtchn.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\gnttbl.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\memory.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_highsync.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_patch_kernel.o=
bj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_dbgprint.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2> /D_DLL=3D1
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wdmsec.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\Rtlver.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\..\..\wlh\amd64\aux_klib.lib=20
1>..\liblfds.6\bin\AMD64\liblfds.lib=20
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xenvbd.c=20
1>xenpci.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>xenvbd.c
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/subsystem:native,6.00=20
1>/base:0x10000=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.sys=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.exp=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.res=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\hypercall.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\dbgprint_hook.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_fdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_pdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_export.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\evtchn.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\gnttbl.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\memory.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_highsync.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_patch_kernel.o=
bj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_dbgprint.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wdmsec.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\Rtlver.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\..\..\wlh\amd64\aux_klib.lib=20
1>..\liblfds.6\bin\AMD64\liblfds.lib=20
1>Generating code
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.sys /machine:amd64 @c:\hg=
\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\lnk.rsp
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\scsiport.lib=20
2>xenvbd.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\scsiport.lib=20
2>Generating code
2>Finished generating code
1>Finished generating code
2>Compiling and Linking c:\hg\win-pvdrivers\xenvbd_storport *************=

2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_storport
2> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenvbd.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.res /=
D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_IN=
ST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /=
DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEV=
L=3D1 /D__BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_=
NUMBER=3D5 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..\common\=
include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrive=
rs\xenvbd_storport\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\ap=
i /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\=
WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\crt .\xenvbd.rc
2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenv=
bd_storport\objfre_wlh_amd64\amd64\cl.rsp
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
2> /DNDEBUG
2> /D_DLL=3D1
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xenvbd.c=20
2>xenvbd.c
1>Compiling and Linking c:\hg\win-pvdrivers\xenvbd_filter *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_filter
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.sys /machine:amd64 @c:\hg=
\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\lnk.rsp
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\storport.lib=20
2>xenvbd.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\storport.lib=20
1> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenvbdfilter.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Micros=
oft.Windows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL""=
"Microsoft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D"""""" =
 /r /fo c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_f=
ilter.res /D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D=
1  /DNT_INST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D=
0x0600 /DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D=
1  /DDEVL=3D1 /D__BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  =
-DBUILD_NUMBER=3D5 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..=
\common\include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win=
-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\=
inc\api /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk=
 /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1=
=2E9 /IC:\WinDDK\7600.16385.0\inc\crt .\xenvbd_filter.rc
2>Generating code
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenv=
bd_filter\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1.9
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /DNDEBUG
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> -cbstring
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\
1> /DKMDF_MAJOR_VERSION=3D1
1> /DKMDF_MINOR_VERSION=3D9
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\xenvbd_filter.c=20
1>xenvbd_filter.c
2>Finished generating code
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfilter.sys /machine:amd64 @c=
:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/base:0x10000=20
1>/subsystem:native,6.00=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfil=
ter.sys=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
res=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
1>xenvbd_filter.obj : MSIL .netmodule or module compiled with /GL found; =
restarting link with /LTCG; add /LTCG to the link command line to improve=
 linker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/base:0x10000=20
1>/subsystem:native,6.00=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfil=
ter.sys=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
res=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
1>Generating code
1>Finished generating code
2>Compiling and Linking c:\hg\win-pvdrivers\xennet *************
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xennet
2> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xennet.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.res /D_WIN64 /=
D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_INST=3D0 /D=
WIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /DWINVER=3D=
0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEVL=3D1 /D__=
BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_NUMBER=3D5=
 -DWIN_KERNEL_BUILD -D_GPLPV_NDIS6 /DNTDDI_VERSION=3D0x06000100   /I..\co=
mmon\include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pv=
drivers\xennet\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\api /I=
C:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinD=
DK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\crt .\xennet.rc
1>Compiling and Linking c:\hg\win-pvdrivers\copyconfig *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\copyconfig
2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenn=
et\objfre_wlh_amd64\amd64\cl.rsp
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
2> /DNDEBUG
2> /D_DLL=3D1
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> -D_GPLPV_NDIS6
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xennet.c .\xennet_tx.c .\xennet_rx.c .\xennet_oid.c .\xennet_common.=
c=20
2>xennet.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\copy=
config\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /D_MT=3D1
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /DPSAPI_VERSION=3D1
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\copyconfig.c=20
1>copyconfig.c
2>xennet_tx.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\copyconfig\objfre_wlh_amd64\amd64\copyconfig.exe /machine:amd64 @c:\hg\=
win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\copyconfig.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>copyconfig.obj : MSIL .netmodule or module compiled with /GL found; res=
tarting link with /LTCG; add /LTCG to the link command line to improve li=
nker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\copyconfig.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>Generating code
1>Finished generating code
2>xennet_rx.c
1>Compiling and Linking c:\hg\win-pvdrivers\shutdownmon *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\shutdownmon
2>xennet_oid.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\shut=
downmon\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /D_MT=3D1
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /DPSAPI_VERSION=3D1
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\shutdownmon.c=20
1>shutdownmon.c
2>xennet_common.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.exe /machine:amd64 @c:\h=
g\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.obj =

1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\setupapi.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\powrprof.lib=20
1>shutdownmon.obj : MSIL .netmodule or module compiled with /GL found; re=
starting link with /LTCG; add /LTCG to the link command line to improve l=
inker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.obj =

1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\setupapi.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\powrprof.lib=20
1>Generating code
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xennet\objfre_wlh_amd64\amd64\xennet.sys /machine:amd64 @c:\hg\win-pvdr=
ivers\xennet\objfre_wlh_amd64\amd64\lnk.rsp
1>Finished generating code
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.sys=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.res=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_tx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_rx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_oid.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_common.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ndis.lib=20
2>..\xenpci\objfre_wlh_amd64\amd64\xenpci.lib=20
2>..\liblfds.6\bin\AMD64\liblfds.lib=20
2>xennet.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.sys=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.res=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_tx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_rx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_oid.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_common.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ndis.lib=20
2>..\xenpci\objfre_wlh_amd64\amd64\xenpci.lib=20
2>..\liblfds.6\bin\AMD64\liblfds.lib=20
2>Generating code
2>Finished generating code
1>Compiling and Linking c:\hg\win-pvdrivers\waitnopendinginstallevents **=
***********
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\waitnopendinginstallevents
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\wait=
nopendinginstallevents\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\=
amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd6=
4
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /D_MT=3D1
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /DPSAPI_VERSION=3D1
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd=
64\
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\waitnopendinginstallevents.c=20
1>waitnopendinginstallevents.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\waitnopendinginstallevents\objfre_wlh_amd64\amd64\waitnopendinginstalle=
vents.exe /machine:amd64 @c:\hg\win-pvdrivers\waitnopendinginstallevents\=
objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd64\w=
aitnopendinginstallevents.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\cfgmgr32.lib=20
1>waitnopendinginstallevents.obj : MSIL .netmodule or module compiled wit=
h /GL found; restarting link with /LTCG; add /LTCG to the link command li=
ne to improve linker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd64\w=
aitnopendinginstallevents.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\cfgmgr32.lib=20
1>Generating code
1>Finished generating code

--------------050404090607090400010101--

--------------ms070601000809040705060906
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxNDExMzE1OVowIwYJKoZIhvcNAQkEMRYEFNnoi88TlxFm9sdqDdZrxYTh
Yy9wMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEATg5jUf/tMg/leEc0YRMmt4/K
zm08IVswP806+wfQAJ5l9vy/G27hwCqRV5gAHpjqzX3BxILoeHTEHpmhhR5iNVAwY2Hsl8qH
NrsI6290fnu6TsAySYthEXydTzARlgBFp8R3+mUnuxX+l9nAHaFSYmqtiF9+Lfd0xRE/LDko
Uk9dgBAu0z9U2b+p+OU90W8H7fEhchVE1ULW3Mfi7fcdzKbJYGBfSVZtO5DXC0EmgslGfK4g
R/NzS7EDoLL8DMpjnw//lo3V9F7exKy5gmX/qto0hDLZBystcpO4cbPzAWWl+B+vKgI5lipa
m4rfQpIBR/0dZx5kMk5eZOynq+OZKQAAAAAAAA==
--------------ms070601000809040705060906--


--===============5091798994668425114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5091798994668425114==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 11:34:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:34: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 1U5x5B-00006D-FA; Thu, 14 Feb 2013 11:34:29 +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 1U5x59-00005z-Bg
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:34:28 +0000
Received: from [193.109.254.147:17266] by server-12.bemta-14.messagelabs.com
	id A7/C3-32582-2CBCC115; Thu, 14 Feb 2013 11:34:26 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360841529!9275007!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=1.1 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	WEIRD_QUOTING,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13988 invoked from network); 14 Feb 2013 11:32:10 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 11:32:10 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id E03F740046B;
	Thu, 14 Feb 2013 12:32:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id g49FLElSYeS3; Thu, 14 Feb 2013 12:32:06 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id B8409400168;
	Thu, 14 Feb 2013 12:32:03 +0100 (CET)
Message-ID: <511CCB2F.20608@tiscali.it>
Date: Thu, 14 Feb 2013 12:31:59 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============5091798994668425114=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============5091798994668425114==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070601000809040705060906"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070601000809040705060906
Content-Type: multipart/mixed;
 boundary="------------050404090607090400010101"

This is a multi-part message in MIME format.
--------------050404090607090400010101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 14/02/2013 12:16, James Harper ha scritto:
>> Il 13/02/2013 23:26, James Harper ha scritto:
>>>> I have tried to build gplpv from source with makedist.bat but it gav=
e me
>>>> some errors about files not found.
>>>> I saw that latest commits were big. Is there something incomplete an=
d
>>>> must I wait other commits before build it?
>>> It's possible I missed a commit but I can't see any missing files.
>>>
>>> Can you post the output of makedist?
>>>
>>> But yes the latest commits involve a pretty major change and I haven'=
t
>> tested save/restore yet so that is probably more broken than before.
>>
>> I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at re=
v
>> 1020.
>> I launched makedist.bat but it gives same errors on each arch build, s=
ee
>> below the output:
>>
> Ok so it can't find the cat files... I'll need the whole output of make=
dist.bat (or at least from the start of the wlh amd64 build) to find out =
- there must have been a previous error causing a failure to generate the=
 cat files.
>
> James
>

I added as attachment the build log for this, can be sufficent? If you=20
need other test/data tell me and I'll post them.

>> ...
>> 1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
>> 1>Linking Executable -
>> waitnopendinginstallevents\waitnopendinginstallevents\obj
>> fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
>> BUILD: Finish time: Thu Feb 14 11:53:50 2013
>> BUILD: Done
>>
>>       75 files compiled
>>       2 libraries built
>>       8 executables built
>> Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> installer.wxs
>> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system
>> cannot find
>> the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system
>> cannot find
>> the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>> C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system
>> cannot find
>> the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
>> C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
>> C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system
>> cannot find
>>    the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
>> C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
>> C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
>> C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system
>> cannot find
>>    the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>> SignTool Error: File not found: /t
>>
>>>> I would like to see if new build fix network not working after resto=
re
>>>> on windows domUs using upstream qemu.
>>>> Dom0 is wheezy with xen-unstable from source.
>>>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
>>>> error on xen for now, probably is problem of gplpv with qemu upstrea=
m.
>>>> Linux hvm domUs seem not have that problem, tested with quantal
>> (ubuntu
>>>> 12.10) and network works also after restore.
>>>> If you need more details and tests tell me and I'll post it.
>>>>
>>>> Another problem present on both traditional/upstream qemu  with
>>>> older/new xen and  older/new gplpv is domU's time not correctly
>> updated
>>>> after restore (it remains the time at the save operation), this is a=
 big
>>>> problem with windows domUs (DC and client) in a windows domain
>> where
>>>> the time source is DC by default.
>>> I noticed that recently. I can't think how it could be a GPLPV bug th=
ough.
>> What can we try to narrow down the problem?
>>
>>> James
>>>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2899 / Database dei virus: 2639/6101 -  Data di rilasc=
io: 13/02/2013
>
>
>


--------------050404090607090400010101
Content-Type: text/plain; charset=windows-1252;
 name="buildfre_wlh_amd64.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="buildfre_wlh_amd64.log"

BUILD: Examining c:\hg\win-pvdrivers directory tree for files to compile.=

oacr invalidate root:amd64fre /autocleanqueue
1>Building generated files in c:\hg\win-pvdrivers\xenpci *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenpci
2>Building generated files in c:\hg\win-pvdrivers\xenvbd_scsiport *******=
******
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_scsiport
1> copy xenpci.inx c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenp=
ci.inf
1> 1 file copiati.
1> stampinf -f c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.i=
nf -a AMD64 -d * -k 1.9 -v 0.11.0.5
2> copy xenvbd.inx c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\a=
md64\xenvbd.inf
1>Stamping c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.inf [=
Version] section with DriverVer=3D02/14/2013,0.11.0.5
1>Building generated files in c:\hg\win-pvdrivers\xenvbd_storport *******=
******
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_storport
2> 1 file copiati.
2> stampinf -f c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64=
\xenvbd.inf -a AMD64 -d * -v 0.11.0.5
2>Stamping c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xen=
vbd.inf [Version] section with DriverVer=3D02/14/2013,0.11.0.5
2>Building generated files in c:\hg\win-pvdrivers\xennet *************
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS0 NOLINK=3D1 PA=
SS0ONLY=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xennet
1> copy xenvbd.inx c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\a=
md64\xenvbd.inf
2> copy xennet.inx c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xenn=
et.inf
1> 1 file copiati.
1> stampinf -f c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64=
\xenvbd.inf -a AMD64 -d * -v 0.11.0.5
2> 1 file copiati.
2> stampinf -f c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.i=
nf -a AMD64 -d * -v 0.11.0.5
1>Stamping c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xen=
vbd.inf [Version] section with DriverVer=3D02/14/2013,0.11.0.5
2>Stamping c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.inf [=
Version] section with DriverVer=3D02/14/2013,0.11.0.5
1>Compiling (NoSync) c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_win=
dows_kernel *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i /nologo /f c:\winddk\7600.16385.=
0\bin\makefile.def BUILD_PASS=3DPASS1 NOLINK=3D1 MAKEDIR_RELATIVE_TO_BASE=
DIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_w=
indows_kernel
2>Compiling (NoSync) c:\hg\win-pvdrivers\xenpci *************
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS1 NOLINK=3D1 MA=
KEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenpci
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel: TARGET=
PATH is ../../bin/
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\libl=
fds.6\src\single_dir_for_windows_kernel\objfre_wlh_amd64\amd64\cl.rsp
2> ml64 /c /Cx /nologo /Iamd64\ /I. /I..\common\include /I..\common\inclu=
de\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrivers\xenpci\objfre_wlh_amd6=
4\amd64 /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\api=
 /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\W=
inDDK\7600.16385.0\inc\wdf\kmdf\1.9 /IC:\WinDDK\7600.16385.0\inc\crt  /Zi=
 /D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_=
INST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600=
 /DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1 /DDB=
G=3D0  /DDEVL=3D1 /D__BUILDMACHINE__=3DWinDDK  /Foc:\hg\win-pvdrivers\xen=
pci\objfre_wlh_amd64\amd64\hypercall.obj amd64\hypercall.asm
2> Assembling: amd64\hypercall.asm
2> ml64 /c /Cx /nologo /Iamd64\ /I. /I..\common\include /I..\common\inclu=
de\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrivers\xenpci\objfre_wlh_amd6=
4\amd64 /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\api=
 /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\W=
inDDK\7600.16385.0\inc\wdf\kmdf\1.9 /IC:\WinDDK\7600.16385.0\inc\crt  /Zi=
 /D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_=
INST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600=
 /DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1 /DDB=
G=3D0  /DDEVL=3D1 /D__BUILDMACHINE__=3DWinDDK  /Foc:\hg\win-pvdrivers\xen=
pci\objfre_wlh_amd64\amd64\dbgprint_hook.obj amd64\dbgprint_hook.asm
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
2> Assembling: amd64\dbgprint_hook.asm
1>cl /Fo"c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\=
objfre_wlh_amd64\amd64/"
1> /FC
1> /MT
1> /U_MT
1> /Iamd64\
1> /I.
1> /I..
1> /I../../inc/
1> /Ic:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objf=
re_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /DNTDDI_VERSION=3D0x06000100
1> /c
1> /Zc:wchar_t-
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenp=
ci\objfre_wlh_amd64\amd64\cl.rsp
1> /Zl
1> /Zp8
1> /Gy
1> -cbstring
1> /WX
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Z7
1> /Oxs
1> /GL
1> /Z7
1> /DWIN_KERNEL_BUILD
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\abstraction_aligned_free.c .\abstraction_aligned_malloc.c .\abstract=
ion_cas.c .\abstraction_dcas.c .\abstraction_increment.c .\freelist_delet=
e.c .\freelist_get_and_set.c .\freelist_new.c .\freelist_pop_push.c .\fre=
elist_query.c .\queue_delete.c .\queue_new.c .\queue_query.c .\queue_queu=
e.c .\ringbuffer_delete.c .\ringbuffer_get_and_put.c .\ringbuffer_new.c .=
\ringbuffer_query.c .\slist_delete.c .\slist_get_and_set.c .\slist_link.c=
 .\slist_new.c .\stack_delete.c .\stack_new.c .\stack_push_pop.c .\stack_=
query.c=20
1>abstraction_aligned_free.c
1>abstraction_aligned_malloc.c
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1.9
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
2> /DNDEBUG
2> /D_DLL=3D1
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION=3D1
2> /DKMDF_MINOR_VERSION=3D9
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xenpci.c .\xenpci_fdo.c .\xenpci_pdo.c .\xenpci_export.c .\evtchn.c =
=2E\gnttbl.c .\xenbus.c .\memory.c .\xenpci_device_interface.c .\xenbus_d=
evice_interface.c .\xenpci_highsync.c .\xenpci_patch_kernel.c .\xenpci_db=
gprint.c=20
2>xenpci.c
1>abstraction_cas.c
1>abstraction_dcas.c
2>xenpci_fdo.c
1>abstraction_increment.c
1>freelist_delete.c
1>freelist_get_and_set.c
2>xenpci_pdo.c
1>freelist_new.c
1>freelist_pop_push.c
2>xenpci_export.c
1>freelist_query.c
1>queue_delete.c
1>queue_new.c
2>evtchn.c
1>queue_query.c
1>queue_queue.c
1>ringbuffer_delete.c
2>gnttbl.c
1>ringbuffer_get_and_put.c
1>ringbuffer_new.c
1>ringbuffer_query.c
2>xenbus.c
1>slist_delete.c
1>slist_get_and_set.c
2>memory.c
1>Compiling...
1>slist_link.c
1>slist_new.c
2>xenpci_device_interface.c
1>stack_delete.c
1>stack_new.c
2>xenbus_device_interface.c
1>stack_push_pop.c
1>stack_query.c
2>xenpci_highsync.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /lib /out:../../bin/\am=
d64\liblfds.lib /IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221=
,4108,4088,4218,4218,4235  /WX /nodefaultlib /machine:amd64 /ltcg @c:\hg\=
win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_wlh_amd6=
4\amd64\lib.rsp
1>Microsoft (R) Library Manager Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_aligned_free.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_aligned_malloc.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_cas.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_dcas.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\abstraction_increment.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_get_and_set.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_pop_push.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\freelist_query.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_query.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\queue_queue.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_get_and_put.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\ringbuffer_query.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_get_and_set.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_link.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\slist_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_delete.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_new.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_push_pop.obj=20
1>c:\hg\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel\objfre_=
wlh_amd64\amd64\stack_query.obj=20
2>xenpci_patch_kernel.c
2>xenpci_dbgprint.c
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /lib /out:c:\hg\win-pvd=
rivers\xenpci\objfre_wlh_amd64\amd64\xenpci.lib @c:\hg\win-pvdrivers\xenp=
ci\objfre_wlh_amd64\amd64\lib.rsp
2>Microsoft (R) Library Manager Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/WX=20
2>/nodefaultlib=20
2>/machine:amd64=20
2>/ltcg=20
2>/def:xenpci.def=20
2>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\hypercall.obj c:\hg\w=
in-pvdrivers\xenpci\objfre_wlh_amd64\amd64\dbgprint_hook.obj c:\hg\win-pv=
drivers\xenpci\objfre_wlh_amd64\amd64\xenpci.obj c:\hg\win-pvdrivers\xenp=
ci\objfre_wlh_amd64\amd64\xenpci_fdo.obj c:\hg\win-pvdrivers\xenpci\objfr=
e_wlh_amd64\amd64\xenpci_pdo.obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_am=
d64\amd64\xenpci_export.obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\a=
md64\evtchn.obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\gnttbl.=
obj c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus.obj c:\hg\wi=
n-pvdrivers\xenpci\objfre_wlh_amd64\amd64\memory.obj c:\hg\win-pvdrivers\=
xenpci\objfre_wlh_amd64\amd64\xenpci_device_interface.obj c:\hg\win-pvdri=
vers\xenpci\objfre_wlh_amd64\amd64\xenbus_device_interface.obj c:\hg\win-=
pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_highsync.obj c:\hg\win-pvd=
rivers\xenpci\objfre_wlh_amd64\amd64\xenpci_patch_kernel.obj c:\hg\win-pv=
drivers\xenpci\objfre_wlh_amd64\amd64\xenpci_dbgprint.obj=20
2> Creating library c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xen=
pci.lib and object c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenp=
ci.exp
1>Linking for c:\hg\win-pvdrivers\xenpci *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDLL=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenpci
2>Compiling and Linking c:\hg\win-pvdrivers\xenvbd_scsiport *************=

2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_scsiport
2> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenvbd.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.res /=
D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_IN=
ST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /=
DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEV=
L=3D1 /D__BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_=
NUMBER=3D5 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..\common\=
include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrive=
rs\xenvbd_scsiport\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\ap=
i /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\=
WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\crt .\xenvbd.rc
1> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenpci.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.res /D_WIN64 /=
D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_INST=3D0 /D=
WIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /DWINVER=3D=
0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEVL=3D1 /D__=
BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_NUMBER=3D5=
 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..\common\include /I=
=2E.\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrivers\xenpc=
i\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\760=
0.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385=
=2E0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1.9 /IC:\WinDDK\7600.1=
6385.0\inc\crt .\xenpci.rc
2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenv=
bd_scsiport\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenpci\objfre_wlh_amd64\amd64\xenpci.sys /machine:amd64 @c:\hg\win-pvdr=
ivers\xenpci\objfre_wlh_amd64\amd64\lnk.rsp
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/subsystem:native,6.00=20
1>/base:0x10000=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.sys=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.exp=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.res=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\hypercall.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\dbgprint_hook.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.obj=20
2> /DNDEBUG
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_fdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_pdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_export.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\evtchn.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\gnttbl.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\memory.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_highsync.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_patch_kernel.o=
bj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_dbgprint.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2> /D_DLL=3D1
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wdmsec.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\Rtlver.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\..\..\wlh\amd64\aux_klib.lib=20
1>..\liblfds.6\bin\AMD64\liblfds.lib=20
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xenvbd.c=20
1>xenpci.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>xenvbd.c
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/subsystem:native,6.00=20
1>/base:0x10000=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.sys=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.exp=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.res=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\hypercall.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\dbgprint_hook.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_fdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_pdo.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_export.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\evtchn.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\gnttbl.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\memory.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenbus_device_interfa=
ce.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_highsync.obj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_patch_kernel.o=
bj=20
1>c:\hg\win-pvdrivers\xenpci\objfre_wlh_amd64\amd64\xenpci_dbgprint.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wdmsec.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\Rtlver.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\..\..\wlh\amd64\aux_klib.lib=20
1>..\liblfds.6\bin\AMD64\liblfds.lib=20
1>Generating code
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.sys /machine:amd64 @c:\hg=
\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\lnk.rsp
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\scsiport.lib=20
2>xenvbd.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\scsiport.lib=20
2>Generating code
2>Finished generating code
1>Finished generating code
2>Compiling and Linking c:\hg\win-pvdrivers\xenvbd_storport *************=

2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_storport
2> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenvbd.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.res /=
D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_IN=
ST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /=
DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEV=
L=3D1 /D__BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_=
NUMBER=3D5 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..\common\=
include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pvdrive=
rs\xenvbd_storport\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\ap=
i /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\=
WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\crt .\xenvbd.rc
2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenv=
bd_storport\objfre_wlh_amd64\amd64\cl.rsp
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
2> /DNDEBUG
2> /D_DLL=3D1
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xenvbd.c=20
2>xenvbd.c
1>Compiling and Linking c:\hg\win-pvdrivers\xenvbd_filter *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\xenvbd_filter
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.sys /machine:amd64 @c:\hg=
\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\lnk.rsp
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\storport.lib=20
2>xenvbd.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.=
sys=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.res=20
2>c:\hg\win-pvdrivers\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\storport.lib=20
1> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xenvbdfilter.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Micros=
oft.Windows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL""=
"Microsoft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D"""""" =
 /r /fo c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_f=
ilter.res /D_WIN64 /D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D=
1  /DNT_INST=3D0 /DWIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D=
0x0600 /DWINVER=3D0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D=
1  /DDEVL=3D1 /D__BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  =
-DBUILD_NUMBER=3D5 -DWIN_KERNEL_BUILD /DNTDDI_VERSION=3D0x06000100   /I..=
\common\include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win=
-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\=
inc\api /IC:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk=
 /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1=
=2E9 /IC:\WinDDK\7600.16385.0\inc\crt .\xenvbd_filter.rc
2>Generating code
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenv=
bd_filter\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\ddk
1> /IC:\WinDDK\7600.16385.0\inc\wdf\kmdf\1.9
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /DNDEBUG
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> -cbstring
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\
1> /DKMDF_MAJOR_VERSION=3D1
1> /DKMDF_MINOR_VERSION=3D9
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\xenvbd_filter.c=20
1>xenvbd_filter.c
2>Finished generating code
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfilter.sys /machine:amd64 @c=
:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/base:0x10000=20
1>/subsystem:native,6.00=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfil=
ter.sys=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
res=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
1>xenvbd_filter.obj : MSIL .netmodule or module compiled with /GL found; =
restarting link with /LTCG; add /LTCG to the link command line to improve=
 linker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/pdbcompress=20
1>/STACK:0x40000,0x1000=20
1>/driver=20
1>/base:0x10000=20
1>/subsystem:native,6.00=20
1>/entry:FxDriverEntry=20
1>/out:c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfil=
ter.sys=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
res=20
1>c:\hg\win-pvdrivers\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbd_filter.=
obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfLdr.lib=20
1>C:\WinDDK\7600.16385.0\lib\wdf\kmdf\amd64\1.9\WdfDriverEntry.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>..\xenpci\objfre_wlh_amd64\AMD64\xenpci.lib=20
1>Generating code
1>Finished generating code
2>Compiling and Linking c:\hg\win-pvdrivers\xennet *************
2>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
2>BUILDMSG: Processing c:\hg\win-pvdrivers\xennet
2> rc.exe -l 409 -DSXS_PROCESSOR_ARCHITECTURE=3D"""AMD64"""  -DSXS_TARGET=
=3D"""xennet.sys"""   -DSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3D"""Microsoft.Wi=
ndows.SystemCompatible"""  -DLSYSTEM_COMPATIBLE_ASSEMBLY_NAME=3DL"""Micro=
soft.Windows.SystemCompatible"""   -DSXS_ASSEMBLY_VERSION=3D""""""  /r /f=
o c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.res /D_WIN64 /=
D_AMD64_ /DAMD64   /DCONDITION_HANDLING=3D1 /DNT_UP=3D1  /DNT_INST=3D0 /D=
WIN32=3D100 /D_NT1X_=3D100 /DWINNT=3D1 /D_WIN32_WINNT=3D0x0600 /DWINVER=3D=
0x0600 /D_WIN32_IE=3D0x0700    /DWIN32_LEAN_AND_MEAN=3D1  /DDEVL=3D1 /D__=
BUILDMACHINE__=3DWinDDK  /DNDEBUG /D_DLL=3D1 /DNDEBUG  -DBUILD_NUMBER=3D5=
 -DWIN_KERNEL_BUILD -D_GPLPV_NDIS6 /DNTDDI_VERSION=3D0x06000100   /I..\co=
mmon\include /I..\common\include\public /I..\liblfds.6\inc /Ic:\hg\win-pv=
drivers\xennet\objfre_wlh_amd64\amd64 /IC:\WinDDK\7600.16385.0\inc\api /I=
C:\WinDDK\7600.16385.0\inc\api /IC:\WinDDK\7600.16385.0\inc\ddk /IC:\WinD=
DK\7600.16385.0\inc\ddk /IC:\WinDDK\7600.16385.0\inc\crt .\xennet.rc
1>Compiling and Linking c:\hg\win-pvdrivers\copyconfig *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\copyconfig
2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6908.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\xenn=
et\objfre_wlh_amd64\amd64\cl.rsp
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Fo"c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64/"
2> /FC
2> /Iamd64\
2> /I.
2> /I..\common\include
2> /I..\common\include\public
2> /I..\liblfds.6\inc
2> /Ic:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\api
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\ddk
2> /IC:\WinDDK\7600.16385.0\inc\crt
2> /D_WIN64
2> /D_AMD64_
2> /DAMD64
2> /DCONDITION_HANDLING=3D1
2> /DNT_UP=3D1
2> /DNT_INST=3D0
2> /DWIN32=3D100
2> /D_NT1X_=3D100
2> /DWINNT=3D1
2> /D_WIN32_WINNT=3D0x0600
2> /DWINVER=3D0x0600
2> /D_WIN32_IE=3D0x0700
2> /DWIN32_LEAN_AND_MEAN=3D1
2> /DDEVL=3D1
2> /D__BUILDMACHINE__=3DWinDDK
2> /DNDEBUG
2> /D_DLL=3D1
2> /DNDEBUG
2> -DBUILD_NUMBER=3D5
2> -DWIN_KERNEL_BUILD
2> -D_GPLPV_NDIS6
2> /DNTDDI_VERSION=3D0x06000100
2> /c
2> /Zc:wchar_t-
2> /Zl
2> /Zp8
2> /Gy
2> -cbstring
2> /W4
2> /WX
2> /EHs-c-
2> /GR-
2> /GF
2> /GS
2> /Zi
2> /Oxs
2> /GL
2> /Zi
2> /Fdc:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\
2> /DKMDF_MAJOR_VERSION_STRING=3D01
2> /DKMDF_MINOR_VERSION_STRING=3D009
2> /typedil-
2> /wd4603
2> /wd4627
2> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
2> .\xennet.c .\xennet_tx.c .\xennet_rx.c .\xennet_oid.c .\xennet_common.=
c=20
2>xennet.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\copy=
config\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /D_MT=3D1
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /DPSAPI_VERSION=3D1
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\copyconfig.c=20
1>copyconfig.c
2>xennet_tx.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\copyconfig\objfre_wlh_amd64\amd64\copyconfig.exe /machine:amd64 @c:\hg\=
win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\copyconfig.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>copyconfig.obj : MSIL .netmodule or module compiled with /GL found; res=
tarting link with /LTCG; add /LTCG to the link command line to improve li=
nker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\copyconfig\objfre_wlh_amd64\amd64\copyconfig.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>Generating code
1>Finished generating code
2>xennet_rx.c
1>Compiling and Linking c:\hg\win-pvdrivers\shutdownmon *************
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\shutdownmon
2>xennet_oid.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\shut=
downmon\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /D_MT=3D1
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /DPSAPI_VERSION=3D1
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\shutdownmon.c=20
1>shutdownmon.c
2>xennet_common.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.exe /machine:amd64 @c:\h=
g\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.obj =

1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\setupapi.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\powrprof.lib=20
1>shutdownmon.obj : MSIL .netmodule or module compiled with /GL found; re=
starting link with /LTCG; add /LTCG to the link command line to improve l=
inker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.obj =

1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\setupapi.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\powrprof.lib=20
1>Generating code
2> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\xennet\objfre_wlh_amd64\amd64\xennet.sys /machine:amd64 @c:\hg\win-pvdr=
ivers\xennet\objfre_wlh_amd64\amd64\lnk.rsp
1>Finished generating code
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.sys=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.res=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_tx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_rx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_oid.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_common.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ndis.lib=20
2>..\xenpci\objfre_wlh_amd64\amd64\xenpci.lib=20
2>..\liblfds.6\bin\AMD64\liblfds.lib=20
2>xennet.obj : MSIL .netmodule or module compiled with /GL found; restart=
ing link with /LTCG; add /LTCG to the link command line to improve linker=
 performance
2>Microsoft (R) Incremental Linker Version 9.00.30729.207
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>/MERGE:_PAGE=3DPAGE=20
2>/MERGE:_TEXT=3D.text=20
2>/SECTION:INIT,d=20
2>/OPT:REF=20
2>/OPT:ICF=20
2>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
2>/INCREMENTAL:NO=20
2>/release=20
2>/NODEFAULTLIB=20
2>/WX=20
2>/debug=20
2>/debugtype:cv,fixup,pdata=20
2>/version:6.1=20
2>/osversion:6.1=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
2>/functionpadmin:6=20
2>/pdbcompress=20
2>/STACK:0x40000,0x1000=20
2>/driver=20
2>/base:0x10000=20
2>/subsystem:native,6.00=20
2>/entry:GsDriverEntry=20
2>/out:c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.sys=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.res=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_tx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_rx.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_oid.obj=20
2>c:\hg\win-pvdrivers\xennet\objfre_wlh_amd64\amd64\xennet_common.obj=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\BufferOverflowK.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntoskrnl.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hal.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\wmilib.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ntstrsafe.lib=20
2>C:\WinDDK\7600.16385.0\lib\wlh\amd64\ndis.lib=20
2>..\xenpci\objfre_wlh_amd64\amd64\xenpci.lib=20
2>..\liblfds.6\bin\AMD64\liblfds.lib=20
2>Generating code
2>Finished generating code
1>Compiling and Linking c:\hg\win-pvdrivers\waitnopendinginstallevents **=
***********
1>'nmake.exe /nologo BUILDMSG=3DStop. -i BUILD_PASS=3DPASS2 LINKONLY=3D1 =
NOPASS0=3D1 MAKEDIR_RELATIVE_TO_BASEDIR=3D'
1>BUILDMSG: Processing c:\hg\win-pvdrivers\waitnopendinginstallevents
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrcl @c:\hg\win-pvdrivers\wait=
nopendinginstallevents\objfre_wlh_amd64\amd64\cl.rsp
1>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.207 for x64=

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>cl /Fo"c:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\=
amd64/"
1> /FC
1> /Iamd64\
1> /I.
1> /I..\common\include
1> /I..\common\include\public
1> /I..\liblfds.6\inc
1> /Ic:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd6=
4
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\api
1> /IC:\WinDDK\7600.16385.0\inc\crt
1> /D_WIN64
1> /D_AMD64_
1> /DAMD64
1> /DCONDITION_HANDLING=3D1
1> /DNT_UP=3D1
1> /DNT_INST=3D0
1> /DWIN32=3D100
1> /D_NT1X_=3D100
1> /DWINNT=3D1
1> /D_WIN32_WINNT=3D0x0600
1> /DWINVER=3D0x0600
1> /D_WIN32_IE=3D0x0700
1> /DWIN32_LEAN_AND_MEAN=3D1
1> /DDEVL=3D1
1> /D__BUILDMACHINE__=3DWinDDK
1> /DNDEBUG
1> /D_DLL=3D1
1> /D_MT=3D1
1> -DBUILD_NUMBER=3D5
1> -DWIN_KERNEL_BUILD
1> /DNTDDI_VERSION=3D0x06000100
1> /DPSAPI_VERSION=3D1
1> /c
1> /Zc:wchar_t-
1> /Zl
1> /Zp8
1> /Gy
1> /W4
1> /WX
1> /EHs-c-
1> /GR-
1> /GF
1> /GS
1> /Zi
1> /Oxs
1> /GL
1> /Zi
1> /Fdc:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd=
64\
1> /DKMDF_MAJOR_VERSION_STRING=3D01
1> /DKMDF_MINOR_VERSION_STRING=3D009
1> /typedil-
1> /wd4603
1> /wd4627
1> /FIC:\WinDDK\7600.16385.0\inc\api\warning.h
1> .\waitnopendinginstallevents.c=20
1>waitnopendinginstallevents.c
1> C:\WinDDK\7600.16385.0\Bin\amd64\oacr\oacrlink /out:c:\hg\win-pvdriver=
s\waitnopendinginstallevents\objfre_wlh_amd64\amd64\waitnopendinginstalle=
vents.exe /machine:amd64 @c:\hg\win-pvdrivers\waitnopendinginstallevents\=
objfre_wlh_amd64\amd64\lnk.rsp
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd64\w=
aitnopendinginstallevents.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\cfgmgr32.lib=20
1>waitnopendinginstallevents.obj : MSIL .netmodule or module compiled wit=
h /GL found; restarting link with /LTCG; add /LTCG to the link command li=
ne to improve linker performance
1>Microsoft (R) Incremental Linker Version 9.00.30729.207
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>/MERGE:_PAGE=3DPAGE=20
1>/MERGE:_TEXT=3D.text=20
1>/SECTION:INIT,d=20
1>/OPT:REF=20
1>/OPT:ICF=20
1>/IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,421=
8,4218,4235=20
1>/INCREMENTAL:NO=20
1>/release=20
1>/NODEFAULTLIB=20
1>/WX=20
1>/debug=20
1>/debugtype:cv,fixup,pdata=20
1>/version:6.1=20
1>/osversion:6.1=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\hotpatch.obj=20
1>/functionpadmin:6=20
1>/merge:.rdata=3D.text=20
1>/pdbcompress=20
1>/STACK:0x80000,0x2000=20
1>/tsaware=20
1>/dynamicbase=20
1>/subsystem:console,6.00=20
1>/base:0x400000=20
1>/entry:mainCRTStartup=20
1>c:\hg\win-pvdrivers\waitnopendinginstallevents\objfre_wlh_amd64\amd64\w=
aitnopendinginstallevents.obj=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\advapi32.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\kernel32.lib=20
1>C:\WinDDK\7600.16385.0\lib\crt\amd64\msvcrt.lib=20
1>C:\WinDDK\7600.16385.0\lib\wlh\amd64\cfgmgr32.lib=20
1>Generating code
1>Finished generating code

--------------050404090607090400010101--

--------------ms070601000809040705060906
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIxNDExMzE1OVowIwYJKoZIhvcNAQkEMRYEFNnoi88TlxFm9sdqDdZrxYTh
Yy9wMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEATg5jUf/tMg/leEc0YRMmt4/K
zm08IVswP806+wfQAJ5l9vy/G27hwCqRV5gAHpjqzX3BxILoeHTEHpmhhR5iNVAwY2Hsl8qH
NrsI6290fnu6TsAySYthEXydTzARlgBFp8R3+mUnuxX+l9nAHaFSYmqtiF9+Lfd0xRE/LDko
Uk9dgBAu0z9U2b+p+OU90W8H7fEhchVE1ULW3Mfi7fcdzKbJYGBfSVZtO5DXC0EmgslGfK4g
R/NzS7EDoLL8DMpjnw//lo3V9F7exKy5gmX/qto0hDLZBystcpO4cbPzAWWl+B+vKgI5lipa
m4rfQpIBR/0dZx5kMk5eZOynq+OZKQAAAAAAAA==
--------------ms070601000809040705060906--


--===============5091798994668425114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5091798994668425114==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 11:34:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x5N-00007y-71; Thu, 14 Feb 2013 11:34:41 +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 1U5x5L-00007f-AX
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:34:39 +0000
Received: from [85.158.138.51:54418] by server-13.bemta-3.messagelabs.com id
	20/68-20653-ECBCC115; Thu, 14 Feb 2013 11:34:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360841665!21198640!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20922 invoked from network); 14 Feb 2013 11:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1456462"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:34: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.297.1;
	Thu, 14 Feb 2013 11:34:25 +0000
Message-ID: <1360841663.20449.345.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 14 Feb 2013 11:34:23 +0000
In-Reply-To: <1360840843.16636.109.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:

> I'm not convinced. netbk_tx_err only has one xenvif_put, however
> netbk_fatal_tx_err has two puts.

One balances the get in poll_net_schedule_list (i.e. at the top of the
loop in xen_netbk_tx_build_gops.

The other one I guess you mean the one in xenvif_carrier_off? This
balances the refcount taken in xenvif_connect, when the carrier is
brought up.

In my testing I found that both were required or else things deadlock in
xenvif_disconnect with the refcnt stuck at 1.

The eventual put in xenvif_disconnect is balanced by the initial count
of 1 in xenvif_alloc()

Ian.

> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> will hit this bug soon when shutting down DomU.
> 
> 
> Wei.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:34:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x5N-00007y-71; Thu, 14 Feb 2013 11:34:41 +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 1U5x5L-00007f-AX
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:34:39 +0000
Received: from [85.158.138.51:54418] by server-13.bemta-3.messagelabs.com id
	20/68-20653-ECBCC115; Thu, 14 Feb 2013 11:34:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360841665!21198640!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20922 invoked from network); 14 Feb 2013 11:34:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:34:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1456462"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:34: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.297.1;
	Thu, 14 Feb 2013 11:34:25 +0000
Message-ID: <1360841663.20449.345.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 14 Feb 2013 11:34:23 +0000
In-Reply-To: <1360840843.16636.109.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:

> I'm not convinced. netbk_tx_err only has one xenvif_put, however
> netbk_fatal_tx_err has two puts.

One balances the get in poll_net_schedule_list (i.e. at the top of the
loop in xen_netbk_tx_build_gops.

The other one I guess you mean the one in xenvif_carrier_off? This
balances the refcount taken in xenvif_connect, when the carrier is
brought up.

In my testing I found that both were required or else things deadlock in
xenvif_disconnect with the refcnt stuck at 1.

The eventual put in xenvif_disconnect is balanced by the initial count
of 1 in xenvif_alloc()

Ian.

> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> will hit this bug soon when shutting down DomU.
> 
> 
> Wei.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:37:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x7X-0000O6-Pu; Thu, 14 Feb 2013 11:36:55 +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 1U5x7X-0000Nz-5f
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:36:55 +0000
Received: from [85.158.143.35:51615] by server-2.bemta-4.messagelabs.com id
	5A/0B-01597-65CCC115; Thu, 14 Feb 2013 11:36:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360841788!10117256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11510 invoked from network); 14 Feb 2013 11:36:29 -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;
	14 Feb 2013 11:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7484383"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:36:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:36:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5x75-0004Sa-E4;
	Thu, 14 Feb 2013 11:36:27 +0000
Date: Thu, 14 Feb 2013 11:36:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359032784.32057.20.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141134170.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1301151901330.4978@kaball.uk.xensource.com>
	<1359032784.32057.20.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 0/10] xen: ARM HDLCD video 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, 24 Jan 2013, Ian Campbell wrote:
> On Tue, 2013-01-15 at 19:04 +0000, Stefano Stabellini wrote:
> >       xen/arm: add missing FIRST, SECOND and THIRD MASK and SIZE definitions
> >       xen/arm: introduce flush_xen_data_tlb_range_va
> >       xen/arm: flush the entire dest_va 2MB mapping
> >       xen/arm: introduce early_ioremap
> >       xen: infrastructure to have cross-platform video drivers
> 
> Acked + Applied up to here.
> 
> >       xen: introduce a generic framebuffer driver
> 
> Need an ack from Keir on this one.
> 
> >       xen/arm: move setup_mm right after setup_pagetables
> 
> I think this one will not apply after "arm: avoid allocating the heaps
> over modules or xen itself.". Also there are now some more printk/panic
> which need to become early I think.
 
I guess you want me to rebase and repost again?


> >       xen/device_tree: introduce find_compatible_node
> >       xen/arm: introduce vexpress_syscfg
> 
> If you confirm its safe I'll applies these without the missing
> predessors. Or if these need to wait you can take this as an
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I would rather keep the patch series united

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:37:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x7X-0000O6-Pu; Thu, 14 Feb 2013 11:36:55 +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 1U5x7X-0000Nz-5f
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:36:55 +0000
Received: from [85.158.143.35:51615] by server-2.bemta-4.messagelabs.com id
	5A/0B-01597-65CCC115; Thu, 14 Feb 2013 11:36:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360841788!10117256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11510 invoked from network); 14 Feb 2013 11:36:29 -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;
	14 Feb 2013 11:36:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7484383"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:36:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:36:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5x75-0004Sa-E4;
	Thu, 14 Feb 2013 11:36:27 +0000
Date: Thu, 14 Feb 2013 11:36:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359032784.32057.20.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141134170.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1301151901330.4978@kaball.uk.xensource.com>
	<1359032784.32057.20.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 0/10] xen: ARM HDLCD video 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, 24 Jan 2013, Ian Campbell wrote:
> On Tue, 2013-01-15 at 19:04 +0000, Stefano Stabellini wrote:
> >       xen/arm: add missing FIRST, SECOND and THIRD MASK and SIZE definitions
> >       xen/arm: introduce flush_xen_data_tlb_range_va
> >       xen/arm: flush the entire dest_va 2MB mapping
> >       xen/arm: introduce early_ioremap
> >       xen: infrastructure to have cross-platform video drivers
> 
> Acked + Applied up to here.
> 
> >       xen: introduce a generic framebuffer driver
> 
> Need an ack from Keir on this one.
> 
> >       xen/arm: move setup_mm right after setup_pagetables
> 
> I think this one will not apply after "arm: avoid allocating the heaps
> over modules or xen itself.". Also there are now some more printk/panic
> which need to become early I think.
 
I guess you want me to rebase and repost again?


> >       xen/device_tree: introduce find_compatible_node
> >       xen/arm: introduce vexpress_syscfg
> 
> If you confirm its safe I'll applies these without the missing
> predessors. Or if these need to wait you can take this as an
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I would rather keep the patch series united

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:37:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x7y-0000RL-AE; Thu, 14 Feb 2013 11:37:22 +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 1U5x7w-0000R3-Sl
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:37:21 +0000
Received: from [85.158.139.211:62947] by server-10.bemta-5.messagelabs.com id
	C8/5B-04697-07CCC115; Thu, 14 Feb 2013 11:37:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360841837!22342654!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16496 invoked from network); 14 Feb 2013 11:37:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:37:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5x7s-000M5v-O6; Thu, 14 Feb 2013 11:37:16 +0000
Date: Thu, 14 Feb 2013 11:37:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214113716.GJ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/45] xen: arm64: start of day changes to
	setup.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 15:56 +0000 on 23 Jan (1358956586), Ian Campbell wrote:
> @@ -320,8 +339,8 @@ void __init setup_cache(void)
>      uint32_t ccsid;
>  
>      /* Read the cache size ID register for the level-0 data cache */
> -    WRITE_CP32(0, CSSELR);
> -    ccsid = READ_CP32(CCSIDR);
> +    WRITE_SYSREG32(0, CSSELR_EL1);
> +    ccsid = READ_SYSREG32(CSSELR_EL1);

CSSIDR_EL1 ?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:37:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x7y-0000RL-AE; Thu, 14 Feb 2013 11:37:22 +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 1U5x7w-0000R3-Sl
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:37:21 +0000
Received: from [85.158.139.211:62947] by server-10.bemta-5.messagelabs.com id
	C8/5B-04697-07CCC115; Thu, 14 Feb 2013 11:37:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360841837!22342654!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16496 invoked from network); 14 Feb 2013 11:37:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:37:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5x7s-000M5v-O6; Thu, 14 Feb 2013 11:37:16 +0000
Date: Thu, 14 Feb 2013 11:37:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214113716.GJ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/45] xen: arm64: start of day changes to
	setup.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 15:56 +0000 on 23 Jan (1358956586), Ian Campbell wrote:
> @@ -320,8 +339,8 @@ void __init setup_cache(void)
>      uint32_t ccsid;
>  
>      /* Read the cache size ID register for the level-0 data cache */
> -    WRITE_CP32(0, CSSELR);
> -    ccsid = READ_CP32(CCSIDR);
> +    WRITE_SYSREG32(0, CSSELR_EL1);
> +    ccsid = READ_SYSREG32(CSSELR_EL1);

CSSIDR_EL1 ?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:38:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x8t-0000a5-QY; Thu, 14 Feb 2013 11:38:19 +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 1U5x8r-0000Zj-Bg
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:38:17 +0000
Received: from [85.158.139.211:50877] by server-5.bemta-5.messagelabs.com id
	A7/15-11945-8ACCC115; Thu, 14 Feb 2013 11:38:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360841894!22463323!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5197 invoked from network); 14 Feb 2013 11:38:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7114228"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:38:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:38:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5x8n-0004Ud-CS;
	Thu, 14 Feb 2013 11:38:13 +0000
Message-ID: <1360841893.16636.113.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 11:38:13 +0000
In-Reply-To: <1360841663.20449.345.camel@zakaz.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<1360841663.20449.345.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:34 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:
> 
> > I'm not convinced. netbk_tx_err only has one xenvif_put, however
> > netbk_fatal_tx_err has two puts.
> 
> One balances the get in poll_net_schedule_list (i.e. at the top of the
> loop in xen_netbk_tx_build_gops.
> 
> The other one I guess you mean the one in xenvif_carrier_off? This
> balances the refcount taken in xenvif_connect, when the carrier is
> brought up.
> 
> In my testing I found that both were required or else things deadlock in
> xenvif_disconnect with the refcnt stuck at 1.
> 
> The eventual put in xenvif_disconnect is balanced by the initial count
> of 1 in xenvif_alloc()

Oh, I get what you mean now. Because the vif is down so
xenvif_carrier_off is not invoked in disconnect path.

But I think a better place to balance refcount taken in xenvif_connect
is xenvif_disconnect, so I would rather move that xenvif_put in
fatal_tx_err to xenvif_disconnect.


Wei.

> Ian.
> 
> > If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> > will hit this bug soon when shutting down DomU.
> > 
> > 
> > Wei.
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:38:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5x8t-0000a5-QY; Thu, 14 Feb 2013 11:38:19 +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 1U5x8r-0000Zj-Bg
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:38:17 +0000
Received: from [85.158.139.211:50877] by server-5.bemta-5.messagelabs.com id
	A7/15-11945-8ACCC115; Thu, 14 Feb 2013 11:38:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360841894!22463323!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5197 invoked from network); 14 Feb 2013 11:38:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7114228"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:38:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:38:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5x8n-0004Ud-CS;
	Thu, 14 Feb 2013 11:38:13 +0000
Message-ID: <1360841893.16636.113.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 11:38:13 +0000
In-Reply-To: <1360841663.20449.345.camel@zakaz.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<1360841663.20449.345.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:34 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:
> 
> > I'm not convinced. netbk_tx_err only has one xenvif_put, however
> > netbk_fatal_tx_err has two puts.
> 
> One balances the get in poll_net_schedule_list (i.e. at the top of the
> loop in xen_netbk_tx_build_gops.
> 
> The other one I guess you mean the one in xenvif_carrier_off? This
> balances the refcount taken in xenvif_connect, when the carrier is
> brought up.
> 
> In my testing I found that both were required or else things deadlock in
> xenvif_disconnect with the refcnt stuck at 1.
> 
> The eventual put in xenvif_disconnect is balanced by the initial count
> of 1 in xenvif_alloc()

Oh, I get what you mean now. Because the vif is down so
xenvif_carrier_off is not invoked in disconnect path.

But I think a better place to balance refcount taken in xenvif_connect
is xenvif_disconnect, so I would rather move that xenvif_put in
fatal_tx_err to xenvif_disconnect.


Wei.

> Ian.
> 
> > If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> > will hit this bug soon when shutting down DomU.
> > 
> > 
> > Wei.
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:39:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:39: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 1U5x9u-0000iw-QP; Thu, 14 Feb 2013 11:39:22 +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 1U5x9s-0000iL-SR
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:39:21 +0000
Received: from [85.158.139.83:42979] by server-3.bemta-5.messagelabs.com id
	0D/6B-07037-8ECCC115; Thu, 14 Feb 2013 11:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360841959!20991775!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20966 invoked from network); 14 Feb 2013 11:39:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:39:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1456643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:39: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.297.1;
	Thu, 14 Feb 2013 11:39:19 +0000
Message-ID: <1360841957.20449.346.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 14 Feb 2013 11:39:17 +0000
In-Reply-To: <alpine.DEB.2.02.1302141134170.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1301151901330.4978@kaball.uk.xensource.com>
	<1359032784.32057.20.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302141134170.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v6 0/10] xen: ARM HDLCD video 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, 2013-02-14 at 11:36 +0000, Stefano Stabellini wrote:
> On Thu, 24 Jan 2013, Ian Campbell wrote:
> > On Tue, 2013-01-15 at 19:04 +0000, Stefano Stabellini wrote:
> > >       xen/arm: add missing FIRST, SECOND and THIRD MASK and SIZE definitions
> > >       xen/arm: introduce flush_xen_data_tlb_range_va
> > >       xen/arm: flush the entire dest_va 2MB mapping
> > >       xen/arm: introduce early_ioremap
> > >       xen: infrastructure to have cross-platform video drivers
> > 
> > Acked + Applied up to here.
> > 
> > >       xen: introduce a generic framebuffer driver
> > 
> > Need an ack from Keir on this one.
> > 
> > >       xen/arm: move setup_mm right after setup_pagetables
> > 
> > I think this one will not apply after "arm: avoid allocating the heaps
> > over modules or xen itself.". Also there are now some more printk/panic
> > which need to become early I think.
>  
> I guess you want me to rebase and repost again?

Please.

Need also an ACK from Keir on the above (unless I've missed it?).

> > >       xen/device_tree: introduce find_compatible_node
> > >       xen/arm: introduce vexpress_syscfg
> > 
> > If you confirm its safe I'll applies these without the missing
> > predessors. Or if these need to wait you can take this as an
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I would rather keep the patch series united

ACK.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:39:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:39: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 1U5x9u-0000iw-QP; Thu, 14 Feb 2013 11:39:22 +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 1U5x9s-0000iL-SR
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:39:21 +0000
Received: from [85.158.139.83:42979] by server-3.bemta-5.messagelabs.com id
	0D/6B-07037-8ECCC115; Thu, 14 Feb 2013 11:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360841959!20991775!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20966 invoked from network); 14 Feb 2013 11:39:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:39:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1456643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:39: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.297.1;
	Thu, 14 Feb 2013 11:39:19 +0000
Message-ID: <1360841957.20449.346.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 14 Feb 2013 11:39:17 +0000
In-Reply-To: <alpine.DEB.2.02.1302141134170.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1301151901330.4978@kaball.uk.xensource.com>
	<1359032784.32057.20.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302141134170.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v6 0/10] xen: ARM HDLCD video 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, 2013-02-14 at 11:36 +0000, Stefano Stabellini wrote:
> On Thu, 24 Jan 2013, Ian Campbell wrote:
> > On Tue, 2013-01-15 at 19:04 +0000, Stefano Stabellini wrote:
> > >       xen/arm: add missing FIRST, SECOND and THIRD MASK and SIZE definitions
> > >       xen/arm: introduce flush_xen_data_tlb_range_va
> > >       xen/arm: flush the entire dest_va 2MB mapping
> > >       xen/arm: introduce early_ioremap
> > >       xen: infrastructure to have cross-platform video drivers
> > 
> > Acked + Applied up to here.
> > 
> > >       xen: introduce a generic framebuffer driver
> > 
> > Need an ack from Keir on this one.
> > 
> > >       xen/arm: move setup_mm right after setup_pagetables
> > 
> > I think this one will not apply after "arm: avoid allocating the heaps
> > over modules or xen itself.". Also there are now some more printk/panic
> > which need to become early I think.
>  
> I guess you want me to rebase and repost again?

Please.

Need also an ACK from Keir on the above (unless I've missed it?).

> > >       xen/device_tree: introduce find_compatible_node
> > >       xen/arm: introduce vexpress_syscfg
> > 
> > If you confirm its safe I'll applies these without the missing
> > predessors. Or if these need to wait you can take this as an
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I would rather keep the patch series united

ACK.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:39:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:39: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 1U5x9t-0000ia-Bv; Thu, 14 Feb 2013 11:39:21 +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 1U5x9s-0000iI-I5
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:39:20 +0000
Received: from [85.158.139.83:42952] by server-3.bemta-5.messagelabs.com id
	AB/6B-07037-7ECCC115; Thu, 14 Feb 2013 11:39:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360841953!24944105!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15875 invoked from network); 14 Feb 2013 11:39:14 -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;
	14 Feb 2013 11:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7484552"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:39:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:39:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5x9k-0004VS-MH;
	Thu, 14 Feb 2013 11:39:12 +0000
Date: Thu, 14 Feb 2013 11:39:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359624482.12252.265.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141136570.8231@kaball.uk.xensource.com>
References: <1359391811.12252.25.camel@zakaz.uk.xensource.com>
	<1359549146.12252.224.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301301638470.10432@kaball.uk.xensource.com>
	<1359624482.12252.265.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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] Correct DTB compatibility for xen /hypervisor node?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 31 Jan 2013, Ian Campbell wrote:
> On Wed, 2013-01-30 at 16:42 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Jan 2013, Ian Campbell wrote:
> > > On Mon, 2013-01-28 at 16:50 +0000, Ian Campbell wrote:
> > > > Looks like we have both 4.2 and 4.3 in use. Which should it be?
> > > > 
> > > > $ rgrep xen-4 arch/arm Documentation/
> > > > arch/arm/boot/dts/xenvm-4.2.dts:		compatible = "xen,xen-4.2", "xen,xen";
> > > > Documentation/devicetree/bindings/arm/xen.txt:	compatible = "xen,xen-4.3", "xen,xen";
> > > > 
> > > > FWIW I've always used 4.2 in my own DTB files.
> > > > 
> > > > Strictly speaking the API is the Xen 3.x API, but that doesn't seem
> > > > terribly relevant.
> > > > 
> > > > I suppose arch_get_xen_caps ought to return something consistent?
> > > 
> > > On a related note should /hypervisor contain #interrupt-cells = <3> ?
> > > We use "interrupts = <1 15 0xf08>" so it is somewhat implicit, butsince
> > > the parent doesn't have anything explicit this it will default to
> > > $somethingelse (0)? 
> > 
> > I think that it is implicit that the interrupts attributes follow the
> > rules specified by the interrupt controller node.
> 
> OK.
> 
> > > Should Documentation/devicetree/bindings/arm/xen.txt also reference
> > > gic.txt for the meaning of the fields, or are we free to define our own
> > > meaning?
> > 
> > No, we are not. Referencing gic.txt is a good idea.
> 
> Yes, especially since we assume that interrupt-controller == gic.
> 
> > > We need to get a canonical copy of this binding doc into the hypervisor
> > > tree too.
> > 
> > Right.
> 
> Are you going to send a patch to both Linux and Xen?

I'll add this to my todo list

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:39:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:39: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 1U5x9t-0000ia-Bv; Thu, 14 Feb 2013 11:39:21 +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 1U5x9s-0000iI-I5
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:39:20 +0000
Received: from [85.158.139.83:42952] by server-3.bemta-5.messagelabs.com id
	AB/6B-07037-7ECCC115; Thu, 14 Feb 2013 11:39:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360841953!24944105!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15875 invoked from network); 14 Feb 2013 11:39:14 -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;
	14 Feb 2013 11:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7484552"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:39:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:39:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5x9k-0004VS-MH;
	Thu, 14 Feb 2013 11:39:12 +0000
Date: Thu, 14 Feb 2013 11:39:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1359624482.12252.265.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141136570.8231@kaball.uk.xensource.com>
References: <1359391811.12252.25.camel@zakaz.uk.xensource.com>
	<1359549146.12252.224.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1301301638470.10432@kaball.uk.xensource.com>
	<1359624482.12252.265.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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] Correct DTB compatibility for xen /hypervisor node?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 31 Jan 2013, Ian Campbell wrote:
> On Wed, 2013-01-30 at 16:42 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Jan 2013, Ian Campbell wrote:
> > > On Mon, 2013-01-28 at 16:50 +0000, Ian Campbell wrote:
> > > > Looks like we have both 4.2 and 4.3 in use. Which should it be?
> > > > 
> > > > $ rgrep xen-4 arch/arm Documentation/
> > > > arch/arm/boot/dts/xenvm-4.2.dts:		compatible = "xen,xen-4.2", "xen,xen";
> > > > Documentation/devicetree/bindings/arm/xen.txt:	compatible = "xen,xen-4.3", "xen,xen";
> > > > 
> > > > FWIW I've always used 4.2 in my own DTB files.
> > > > 
> > > > Strictly speaking the API is the Xen 3.x API, but that doesn't seem
> > > > terribly relevant.
> > > > 
> > > > I suppose arch_get_xen_caps ought to return something consistent?
> > > 
> > > On a related note should /hypervisor contain #interrupt-cells = <3> ?
> > > We use "interrupts = <1 15 0xf08>" so it is somewhat implicit, butsince
> > > the parent doesn't have anything explicit this it will default to
> > > $somethingelse (0)? 
> > 
> > I think that it is implicit that the interrupts attributes follow the
> > rules specified by the interrupt controller node.
> 
> OK.
> 
> > > Should Documentation/devicetree/bindings/arm/xen.txt also reference
> > > gic.txt for the meaning of the fields, or are we free to define our own
> > > meaning?
> > 
> > No, we are not. Referencing gic.txt is a good idea.
> 
> Yes, especially since we assume that interrupt-controller == gic.
> 
> > > We need to get a canonical copy of this binding doc into the hypervisor
> > > tree too.
> > 
> > Right.
> 
> Are you going to send a patch to both Linux and Xen?

I'll add this to my todo list

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:42:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:42: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 1U5xD4-00018s-GY; Thu, 14 Feb 2013 11:42:38 +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 1U5xD2-00018f-41
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:42:36 +0000
Received: from [85.158.137.99:55198] by server-14.bemta-3.messagelabs.com id
	01/A2-23533-BADCC115; Thu, 14 Feb 2013 11:42:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360842153!16738749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3650 invoked from network); 14 Feb 2013 11:42:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:42:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:42:32 +0000
Message-Id: <511CDBF302000078000BE2D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:43:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <51151ABF.1070007@canonical.com> <511CC4D8.3060203@canonical.com>
In-Reply-To: <511CC4D8.3060203@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 12:04, Stefan Bader <stefan.bader@canonical.com> wrote:
> There was a bit more on the stack but try_to_wake_up seemed a believable 
> current
> path. Even more so after looking into the function:
> 
> #ifdef CONFIG_SMP
>         /*
>          * If the owning (remote) cpu is still in the middle of schedule() with
>          * this task as prev, wait until its done referencing the task.
>          */
>         while (p->on_cpu) {
> #ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
>                 /*
>                  * In case the architecture enables interrupts in
>                  * context_switch(), we cannot busy wait, since that
>                  * would lead to deadlocks when an interrupt hits and
>                  * tries to wake up @prev. So bail and do a complete
>                  * remote wakeup.
>                  */
>                 if (ttwu_activate_remote(p, wake_flags))
>                         goto stat;
> #else
>                 cpu_relax();
> #endif
> 
> And prying out the task in question from the stack, it was one currently
> being accounted for VCPU 6 and on_cpu. VCPU 6 is one of the other waiters 
> for
> the runq lock of VCPU 1. Which would get picked up as soon as this callback 
> is
> done. Unfortunately we "stay awhile... stay forever!".

When analyzing a similar problem with our old PV ticket lock
implementation (and the interrupt re-enabling there when possible
before going into polling mode), it was precisely this open coded
lock construct that caused problems for us. Back then I didn't,
however, realize that this would even affect the simplistic byte
locks used by the pv-ops Xen code (or else I would have pointed
this out).

Being relatively certain that with our new implementation we don't
have any such problems, I can only recommend against dropping
the re-enabling of interrupts - this needlessly introduces high
interrupt latencies in a broader range of cases. Instead, the
interactions ought to be fixed properly. And it's time for using
ticket locks in the Xen code too...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:42:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:42: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 1U5xD4-00018s-GY; Thu, 14 Feb 2013 11:42:38 +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 1U5xD2-00018f-41
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:42:36 +0000
Received: from [85.158.137.99:55198] by server-14.bemta-3.messagelabs.com id
	01/A2-23533-BADCC115; Thu, 14 Feb 2013 11:42:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360842153!16738749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3650 invoked from network); 14 Feb 2013 11:42:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:42:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:42:32 +0000
Message-Id: <511CDBF302000078000BE2D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:43:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <51151ABF.1070007@canonical.com> <511CC4D8.3060203@canonical.com>
In-Reply-To: <511CC4D8.3060203@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 12:04, Stefan Bader <stefan.bader@canonical.com> wrote:
> There was a bit more on the stack but try_to_wake_up seemed a believable 
> current
> path. Even more so after looking into the function:
> 
> #ifdef CONFIG_SMP
>         /*
>          * If the owning (remote) cpu is still in the middle of schedule() with
>          * this task as prev, wait until its done referencing the task.
>          */
>         while (p->on_cpu) {
> #ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
>                 /*
>                  * In case the architecture enables interrupts in
>                  * context_switch(), we cannot busy wait, since that
>                  * would lead to deadlocks when an interrupt hits and
>                  * tries to wake up @prev. So bail and do a complete
>                  * remote wakeup.
>                  */
>                 if (ttwu_activate_remote(p, wake_flags))
>                         goto stat;
> #else
>                 cpu_relax();
> #endif
> 
> And prying out the task in question from the stack, it was one currently
> being accounted for VCPU 6 and on_cpu. VCPU 6 is one of the other waiters 
> for
> the runq lock of VCPU 1. Which would get picked up as soon as this callback 
> is
> done. Unfortunately we "stay awhile... stay forever!".

When analyzing a similar problem with our old PV ticket lock
implementation (and the interrupt re-enabling there when possible
before going into polling mode), it was precisely this open coded
lock construct that caused problems for us. Back then I didn't,
however, realize that this would even affect the simplistic byte
locks used by the pv-ops Xen code (or else I would have pointed
this out).

Being relatively certain that with our new implementation we don't
have any such problems, I can only recommend against dropping
the re-enabling of interrupts - this needlessly introduces high
interrupt latencies in a broader range of cases. Instead, the
interactions ought to be fixed properly. And it's time for using
ticket locks in the Xen code too...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:44:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:44: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 1U5xEW-0001Jd-2A; Thu, 14 Feb 2013 11:44: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 1U5xEV-0001JP-1h
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:44:07 +0000
Received: from [85.158.143.35:28128] by server-2.bemta-4.messagelabs.com id
	27/B5-01597-60ECC115; Thu, 14 Feb 2013 11:44:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360842245!3926968!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26359 invoked from network); 14 Feb 2013 11:44:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1456978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:44: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.297.1;
	Thu, 14 Feb 2013 11:44:05 +0000
Message-ID: <1360842243.20449.347.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 14 Feb 2013 11:44:03 +0000
In-Reply-To: <1359049232.32057.39.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1301161853130.4978@kaball.uk.xensource.com>
	<1358362736-2870-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1359049232.32057.39.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v2 3/4] libxc: fixes for the ARM 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEzLTAxLTI0IGF0IDE3OjQwICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gV2VkLCAyMDEzLTAxLTE2IGF0IDE4OjU4ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gPiBNYWtlIHhjX2RvbV9mZWF0dXJlX3RyYW5zbGF0ZWQgYW4gYXJjaC1kZXBlbmRlbnQg
ZnVuY3Rpb24uCj4gPiAKPiA+IGFsbG9jX21hZ2ljX3BhZ2VzOiBzYXZlIGNvbnNvbGUgYW5kIHhl
bnN0b3JlIHBmbidzIGluIHhjX2RvbV9pbWFnZS4KPiA+IGFsbG9jX21hZ2ljX3BhZ2VzOiBzZXQg
SFZNX1BBUkFNX0NPTlNPTEVfRVZUQ0hOIGFuZAo+ID4gSFZNX1BBUkFNX1NUT1JFX0VWVENITiBo
dm1fcGFyYW1zIHVzaW5nIHRoZSBldmVudCBjaGFubmVscyBhbGxvY2F0ZWQgYnkKPiA+IHRoZSB0
b29sc3RhY2suCj4gPiAKPiA+IENhbGwgeGNfZG9tX2dudHRhYl9odm1fc2VlZCBpbnN0ZWFkIG9m
IHhjX2RvbV9nbnR0YWJfc2VlZCBpbgo+ID4geGNfZG9tX2dudHRhYl9pbml0IGZvciBhdXRvdHJh
bnNsYXRlZCBndWVzdHMuCj4gPiAKPiA+IAo+ID4gQ2hhbmdlcyBvbiB2MjoKPiA+IC0gYWRkIHhj
X2RvbV9nbnR0YWJfaW5pdCBjaGFuZ2VzLgo+ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgo+IAo+IEFja2Vk
LWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgoKVGhpcyBjaGFuZ2Ug
YnJva2UgdGhlIHg4Nl82NCBidWlsZCAoYXQgbGVhc3QsIHByZXN1bWFsYnkgMzIgdG9vKQogICAg
ICAgIAogICAgICAgIGdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50ICAgLURfX1hFTl9UT09MU19fIC1NTUQgLU1GIC54
Y19jb3JlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1v
bi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbG9jYWwvc2NyYXRj
aC9pYW5jL2RldmVsL2FybS94ZW4tdW5zdGFibGUvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtcHRocmVhZCAgLWMgLW8geGNfY29yZS5vIHhjX2NvcmUuYyAKICAgICAgICBjYzE6IHdh
cm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCiAgICAgICAgSW4gZmlsZSBpbmNsdWRlZCBm
cm9tIHhjX2NvcmUuaDoxNTQsCiAgICAgICAgICAgICAgICAgICAgICAgICBmcm9tIHhjX2NvcmUu
Yzo2NjoKICAgICAgICB4Y19jb3JlX3g4Ni5oOiBJbiBmdW5jdGlvbiDigJh4Y19kb21fZmVhdHVy
ZV90cmFuc2xhdGVk4oCZOgogICAgICAgIHhjX2NvcmVfeDg2Lmg6Mzk6IGVycm9yOiBpbXBsaWNp
dCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiDigJhlbGZfeGVuX2ZlYXR1cmVfZ2V04oCZCiAgICAg
ICAgeGNfY29yZV94ODYuaDozOTogZXJyb3I6IGRlcmVmZXJlbmNpbmcgcG9pbnRlciB0byBpbmNv
bXBsZXRlIHR5cGUKICAgICAgICBJbiBmaWxlIGluY2x1ZGVkIGZyb20geGNfZG9tLmg6MTgsCiAg
ICAgICAgICAgICAgICAgICAgICAgICBmcm9tIHhjX2NvcmUuYzo2NzoKICAgICAgICAvbG9jYWwv
c2NyYXRjaC9pYW5jL2RldmVsL2FybS94ZW4tdW5zdGFibGUvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZS94ZW4vbGliZWxmL2xpYmVsZi5oOiBBdCB0b3AgbGV2ZWw6CiAgICAgICAgL2xv
Y2FsL3NjcmF0Y2gvaWFuYy9kZXZlbC9hcm0veGVuLXVuc3RhYmxlL3Rvb2xzL2xpYnhjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUveGVuL2xpYmVsZi9saWJlbGYuaDoyNjY6IGVycm9yOiBzdGF0aWMgZGVj
bGFyYXRpb24gb2Yg4oCYZWxmX3hlbl9mZWF0dXJlX2dldOKAmSBmb2xsb3dzIG5vbi1zdGF0aWMg
ZGVjbGFyYXRpb24KICAgICAgICB4Y19jb3JlX3g4Ni5oOjM5OiBub3RlOiBwcmV2aW91cyBpbXBs
aWNpdCBkZWNsYXJhdGlvbiBvZiDigJhlbGZfeGVuX2ZlYXR1cmVfZ2V04oCZIHdhcyBoZXJlCiAg
ICAgICAgCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:44:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:44: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 1U5xEW-0001Jd-2A; Thu, 14 Feb 2013 11:44: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 1U5xEV-0001JP-1h
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:44:07 +0000
Received: from [85.158.143.35:28128] by server-2.bemta-4.messagelabs.com id
	27/B5-01597-60ECC115; Thu, 14 Feb 2013 11:44:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360842245!3926968!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26359 invoked from network); 14 Feb 2013 11:44:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:44:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1456978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:44: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.297.1;
	Thu, 14 Feb 2013 11:44:05 +0000
Message-ID: <1360842243.20449.347.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 14 Feb 2013 11:44:03 +0000
In-Reply-To: <1359049232.32057.39.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1301161853130.4978@kaball.uk.xensource.com>
	<1358362736-2870-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1359049232.32057.39.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v2 3/4] libxc: fixes for the ARM 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEzLTAxLTI0IGF0IDE3OjQwICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gV2VkLCAyMDEzLTAxLTE2IGF0IDE4OjU4ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gPiBNYWtlIHhjX2RvbV9mZWF0dXJlX3RyYW5zbGF0ZWQgYW4gYXJjaC1kZXBlbmRlbnQg
ZnVuY3Rpb24uCj4gPiAKPiA+IGFsbG9jX21hZ2ljX3BhZ2VzOiBzYXZlIGNvbnNvbGUgYW5kIHhl
bnN0b3JlIHBmbidzIGluIHhjX2RvbV9pbWFnZS4KPiA+IGFsbG9jX21hZ2ljX3BhZ2VzOiBzZXQg
SFZNX1BBUkFNX0NPTlNPTEVfRVZUQ0hOIGFuZAo+ID4gSFZNX1BBUkFNX1NUT1JFX0VWVENITiBo
dm1fcGFyYW1zIHVzaW5nIHRoZSBldmVudCBjaGFubmVscyBhbGxvY2F0ZWQgYnkKPiA+IHRoZSB0
b29sc3RhY2suCj4gPiAKPiA+IENhbGwgeGNfZG9tX2dudHRhYl9odm1fc2VlZCBpbnN0ZWFkIG9m
IHhjX2RvbV9nbnR0YWJfc2VlZCBpbgo+ID4geGNfZG9tX2dudHRhYl9pbml0IGZvciBhdXRvdHJh
bnNsYXRlZCBndWVzdHMuCj4gPiAKPiA+IAo+ID4gQ2hhbmdlcyBvbiB2MjoKPiA+IC0gYWRkIHhj
X2RvbV9nbnR0YWJfaW5pdCBjaGFuZ2VzLgo+ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBTdGVmYW5v
IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPgo+IAo+IEFja2Vk
LWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgoKVGhpcyBjaGFuZ2Ug
YnJva2UgdGhlIHg4Nl82NCBidWlsZCAoYXQgbGVhc3QsIHByZXN1bWFsYnkgMzIgdG9vKQogICAg
ICAgIAogICAgICAgIGdjYyAgLU8xIC1mbm8tb21pdC1mcmFtZS1wb2ludGVyIC1tNjQgLWcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgLXN0ZD1nbnU5OSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVzIC1X
ZGVjbGFyYXRpb24tYWZ0ZXItc3RhdGVtZW50ICAgLURfX1hFTl9UT09MU19fIC1NTUQgLU1GIC54
Y19jb3JlLm8uZCAgLURfTEFSR0VGSUxFX1NPVVJDRSAtRF9MQVJHRUZJTEU2NF9TT1VSQ0UgLWZu
by1vcHRpbWl6ZS1zaWJsaW5nLWNhbGxzIC1EX0dOVV9TT1VSQ0UgIC1JLi4vLi4veGVuL2NvbW1v
bi9saWJlbGYgLVdlcnJvciAtV21pc3NpbmctcHJvdG90eXBlcyAtSS4gLUkvbG9jYWwvc2NyYXRj
aC9pYW5jL2RldmVsL2FybS94ZW4tdW5zdGFibGUvdG9vbHMvbGlieGMvLi4vLi4vdG9vbHMvaW5j
bHVkZSAtcHRocmVhZCAgLWMgLW8geGNfY29yZS5vIHhjX2NvcmUuYyAKICAgICAgICBjYzE6IHdh
cm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCiAgICAgICAgSW4gZmlsZSBpbmNsdWRlZCBm
cm9tIHhjX2NvcmUuaDoxNTQsCiAgICAgICAgICAgICAgICAgICAgICAgICBmcm9tIHhjX2NvcmUu
Yzo2NjoKICAgICAgICB4Y19jb3JlX3g4Ni5oOiBJbiBmdW5jdGlvbiDigJh4Y19kb21fZmVhdHVy
ZV90cmFuc2xhdGVk4oCZOgogICAgICAgIHhjX2NvcmVfeDg2Lmg6Mzk6IGVycm9yOiBpbXBsaWNp
dCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiDigJhlbGZfeGVuX2ZlYXR1cmVfZ2V04oCZCiAgICAg
ICAgeGNfY29yZV94ODYuaDozOTogZXJyb3I6IGRlcmVmZXJlbmNpbmcgcG9pbnRlciB0byBpbmNv
bXBsZXRlIHR5cGUKICAgICAgICBJbiBmaWxlIGluY2x1ZGVkIGZyb20geGNfZG9tLmg6MTgsCiAg
ICAgICAgICAgICAgICAgICAgICAgICBmcm9tIHhjX2NvcmUuYzo2NzoKICAgICAgICAvbG9jYWwv
c2NyYXRjaC9pYW5jL2RldmVsL2FybS94ZW4tdW5zdGFibGUvdG9vbHMvbGlieGMvLi4vLi4vdG9v
bHMvaW5jbHVkZS94ZW4vbGliZWxmL2xpYmVsZi5oOiBBdCB0b3AgbGV2ZWw6CiAgICAgICAgL2xv
Y2FsL3NjcmF0Y2gvaWFuYy9kZXZlbC9hcm0veGVuLXVuc3RhYmxlL3Rvb2xzL2xpYnhjLy4uLy4u
L3Rvb2xzL2luY2x1ZGUveGVuL2xpYmVsZi9saWJlbGYuaDoyNjY6IGVycm9yOiBzdGF0aWMgZGVj
bGFyYXRpb24gb2Yg4oCYZWxmX3hlbl9mZWF0dXJlX2dldOKAmSBmb2xsb3dzIG5vbi1zdGF0aWMg
ZGVjbGFyYXRpb24KICAgICAgICB4Y19jb3JlX3g4Ni5oOjM5OiBub3RlOiBwcmV2aW91cyBpbXBs
aWNpdCBkZWNsYXJhdGlvbiBvZiDigJhlbGZfeGVuX2ZlYXR1cmVfZ2V04oCZIHdhcyBoZXJlCiAg
ICAgICAgCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:46:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5xGz-0001VU-Qi; Thu, 14 Feb 2013 11:46:41 +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 1U5xGx-0001VL-KF
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:46:39 +0000
Received: from [85.158.138.51:51803] by server-13.bemta-3.messagelabs.com id
	C5/F1-20653-E9ECC115; Thu, 14 Feb 2013 11:46:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360842384!21200383!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13271 invoked from network); 14 Feb 2013 11:46:25 -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;
	14 Feb 2013 11:46:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7114781"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:46:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:46:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5xGb-0004bm-Rz;
	Thu, 14 Feb 2013 11:46:17 +0000
Date: Thu, 14 Feb 2013 11:46:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130124133611.GB20551@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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/2] xen/arm: support the ARM generic
 virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013, Tim Deegan wrote:
> At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > +{
> > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> 
> This is masking the vtimer interrupt in a way that's visible to the
> currently running guest.  Is that going to confuse the guest?
>
> When we talked about this before I had imagined that the masking would
> happen in the GIC, where the guest doesn't see it. 

I know it is not ideal but it is safe, it is not creating any problems to
Linux and it is even the same thing that KVM does).
More importantly I just couldn't get the GIC strategy to work correctly
(actually it work decently well on the physical Versatile Express but it
hangs the emulator, this tells me that it is not the way it was intended
to be used by the ARM people).


> > +    vgic_vcpu_inject_irq(current, irq, 1);
> > +}
> > +
> >  /* Set up the timer interrupt on this CPU */
> >  void __cpuinit init_timer_interrupt(void)
> >  {
> > @@ -172,6 +183,7 @@ void __cpuinit init_timer_interrupt(void)
> >  
> >      /* XXX Need to find this IRQ number from devicetree? */
> >      request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
> > +    request_irq(27, vtimer_interrupt, 0, "virtimer", NULL);
> >      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
> >  }
> >  
> > +static void virt_timer_expired(void *data)
> > +{
> > +    struct vtimer *t = data;
> > +    vcpu_wake(t->v);
> 
> Shouldn't this also inject the irq?  Otherwise when an unscheduled
> guest's timer goes off, we take two interrupts - one for the hyp timer
> to call this function and then another immediately after
> virt_timer_restore() which causes us to inject the vtimer irq. 
> If we injected the irq here (and arranged to mask the vtimer irq) we'd
> avoid a second interrupt.

This might be a good idea, I'll give it a try.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:46:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5xGz-0001VU-Qi; Thu, 14 Feb 2013 11:46:41 +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 1U5xGx-0001VL-KF
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:46:39 +0000
Received: from [85.158.138.51:51803] by server-13.bemta-3.messagelabs.com id
	C5/F1-20653-E9ECC115; Thu, 14 Feb 2013 11:46:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360842384!21200383!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13271 invoked from network); 14 Feb 2013 11:46:25 -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;
	14 Feb 2013 11:46:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7114781"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 11:46:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 06:46:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5xGb-0004bm-Rz;
	Thu, 14 Feb 2013 11:46:17 +0000
Date: Thu, 14 Feb 2013 11:46:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130124133611.GB20551@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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/2] xen/arm: support the ARM generic
 virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Jan 2013, Tim Deegan wrote:
> At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > +{
> > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> 
> This is masking the vtimer interrupt in a way that's visible to the
> currently running guest.  Is that going to confuse the guest?
>
> When we talked about this before I had imagined that the masking would
> happen in the GIC, where the guest doesn't see it. 

I know it is not ideal but it is safe, it is not creating any problems to
Linux and it is even the same thing that KVM does).
More importantly I just couldn't get the GIC strategy to work correctly
(actually it work decently well on the physical Versatile Express but it
hangs the emulator, this tells me that it is not the way it was intended
to be used by the ARM people).


> > +    vgic_vcpu_inject_irq(current, irq, 1);
> > +}
> > +
> >  /* Set up the timer interrupt on this CPU */
> >  void __cpuinit init_timer_interrupt(void)
> >  {
> > @@ -172,6 +183,7 @@ void __cpuinit init_timer_interrupt(void)
> >  
> >      /* XXX Need to find this IRQ number from devicetree? */
> >      request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
> > +    request_irq(27, vtimer_interrupt, 0, "virtimer", NULL);
> >      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
> >  }
> >  
> > +static void virt_timer_expired(void *data)
> > +{
> > +    struct vtimer *t = data;
> > +    vcpu_wake(t->v);
> 
> Shouldn't this also inject the irq?  Otherwise when an unscheduled
> guest's timer goes off, we take two interrupts - one for the hyp timer
> to call this function and then another immediately after
> virt_timer_restore() which causes us to inject the vtimer irq. 
> If we injected the irq here (and arranged to mask the vtimer irq) we'd
> avoid a second interrupt.

This might be a good idea, I'll give it a try.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:47:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:47: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 1U5xHw-0001bL-AA; Thu, 14 Feb 2013 11:47:40 +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 1U5xHu-0001b0-Qt
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:47:39 +0000
Received: from [85.158.137.99:50853] by server-15.bemta-3.messagelabs.com id
	FB/31-25405-9DECC115; Thu, 14 Feb 2013 11:47:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360842456!21325956!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16412 invoked from network); 14 Feb 2013 11:47:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:47:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:47:36 +0000
Message-Id: <511CDD2202000078000BE2F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:48:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
In-Reply-To: <1360840843.16636.109.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 09:11 +0000, Jan Beulich wrote:
>> >>> On 13.02.13 at 21:17, Wei Liu <wei.liu2@citrix.com> wrote:
>> > On Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
>> >> On 13/02/13 18:37, Wei Liu wrote:
>> >> > A slightly upgraded version of the *UNTESTED* patch.
>> >> > 
>> >> > 
>> >> > Wei.
>> >> > 
>> >> > ----8<----
>> >> > commit df4c929d034cec7043fbd96ba89833eb639c336e
>> >> > Author: Wei Liu <wei.liu2@citrix.com>
>> >> > Date:   Wed Feb 13 18:17:01 2013 +0000
>> >> > 
>> >> >     netback: fix netbk_count_requests
>> >> >     
>> >> >     There are two paths in the original code, a) test against work_to_do, 
>> > b) test
>> >> >     against first->size, could return 0 even when error happens.
>> >> >     
>> >> >     Simply return -1 in error paths should work. Modify all error paths to 
> 
>> > return
>> >> >     -1 to be consistent.
>> >> 
>> >> You also need to remove the netbk_tx_err() after checking the result of
>> >> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
>> >> which will screw up ref counting.
>> > 
>> > I just realized that we were talking about different code path when I
>> > walked home.
>> > 
>> > The path you mentioned is correct. As excution flow should never reach
>> > there if there is error in netbk_count_requests.
>> > 
>> > The path I'm not sure is that in the netbk_fatal_tx_err, it calls
>> > xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
>> > which is likely to mess up the refcount.
>> 
>> I first thought so too when looking at this again yesterday, but
>> then convinced myself that this double put _here_ is correct. And
>> Ian's patch specifically removed to call to netbk_tx_err() after the
>> caller netbk_count_requests() recognized the error, knowing that
>> the latter function now itself issues a call to netbk_fatal_tx_err()
>> (whether that wouldn't better have replaced the caller's call to
>> netbk_tx_err() is a different question).
> 
> I'm not convinced. netbk_tx_err only has one xenvif_put, however
> netbk_fatal_tx_err has two puts.

Sure - one for the current transfer, and one for the carrier being
on. That second one would otherwise be put when the interface
gets brought down "normally".

> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> will hit this bug soon when shutting down DomU.

I don't think this patch will fix his problems, which - as described
yesterday - I'm relatively certain result from the harsh action
netbk_fatal_tx_err() 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 Feb 14 11:47:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:47: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 1U5xHw-0001bL-AA; Thu, 14 Feb 2013 11:47:40 +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 1U5xHu-0001b0-Qt
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:47:39 +0000
Received: from [85.158.137.99:50853] by server-15.bemta-3.messagelabs.com id
	FB/31-25405-9DECC115; Thu, 14 Feb 2013 11:47:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1360842456!21325956!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16412 invoked from network); 14 Feb 2013 11:47:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:47:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:47:36 +0000
Message-Id: <511CDD2202000078000BE2F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:48:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
In-Reply-To: <1360840843.16636.109.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 09:11 +0000, Jan Beulich wrote:
>> >>> On 13.02.13 at 21:17, Wei Liu <wei.liu2@citrix.com> wrote:
>> > On Wed, Feb 13, 2013 at 07:20:32PM +0000, David Vrabel wrote:
>> >> On 13/02/13 18:37, Wei Liu wrote:
>> >> > A slightly upgraded version of the *UNTESTED* patch.
>> >> > 
>> >> > 
>> >> > Wei.
>> >> > 
>> >> > ----8<----
>> >> > commit df4c929d034cec7043fbd96ba89833eb639c336e
>> >> > Author: Wei Liu <wei.liu2@citrix.com>
>> >> > Date:   Wed Feb 13 18:17:01 2013 +0000
>> >> > 
>> >> >     netback: fix netbk_count_requests
>> >> >     
>> >> >     There are two paths in the original code, a) test against work_to_do, 
>> > b) test
>> >> >     against first->size, could return 0 even when error happens.
>> >> >     
>> >> >     Simply return -1 in error paths should work. Modify all error paths to 
> 
>> > return
>> >> >     -1 to be consistent.
>> >> 
>> >> You also need to remove the netbk_tx_err() after checking the result of
>> >> netbk_count_requests().  Otherwise you will have a double xenvif_put(),
>> >> which will screw up ref counting.
>> > 
>> > I just realized that we were talking about different code path when I
>> > walked home.
>> > 
>> > The path you mentioned is correct. As excution flow should never reach
>> > there if there is error in netbk_count_requests.
>> > 
>> > The path I'm not sure is that in the netbk_fatal_tx_err, it calls
>> > xenvif_carrier_off which calls xenvif_put, and then it calls xenvif_put,
>> > which is likely to mess up the refcount.
>> 
>> I first thought so too when looking at this again yesterday, but
>> then convinced myself that this double put _here_ is correct. And
>> Ian's patch specifically removed to call to netbk_tx_err() after the
>> caller netbk_count_requests() recognized the error, knowing that
>> the latter function now itself issues a call to netbk_fatal_tx_err()
>> (whether that wouldn't better have replaced the caller's call to
>> netbk_tx_err() is a different question).
> 
> I'm not convinced. netbk_tx_err only has one xenvif_put, however
> netbk_fatal_tx_err has two puts.

Sure - one for the current transfer, and one for the carrier being
on. That second one would otherwise be put when the interface
gets brought down "normally".

> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> will hit this bug soon when shutting down DomU.

I don't think this patch will fix his problems, which - as described
yesterday - I'm relatively certain result from the harsh action
netbk_fatal_tx_err() 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 Feb 14 11:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:48: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 1U5xIe-0001fz-RK; Thu, 14 Feb 2013 11:48:24 +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 1U5xId-0001fm-AR
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:48:23 +0000
Received: from [85.158.143.99:23886] by server-2.bemta-4.messagelabs.com id
	95/DB-01597-60FCC115; Thu, 14 Feb 2013 11:48:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360842500!27531108!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10278 invoked from network); 14 Feb 2013 11:48:20 -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; 14 Feb 2013 11:48:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xIY-000M8K-UV; Thu, 14 Feb 2013 11:48:18 +0000
Date: Thu, 14 Feb 2013 11:48:18 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214114818.GK83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 21/45] xen: arm64: changes to
	setup_pagetables and mm.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 15:56 +0000 on 23 Jan (1358956587), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

> index eb5213e..e870ef6 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -40,13 +40,17 @@
>  struct domain *dom_xen, *dom_io, *dom_cow;
>  
>  /* Static start-of-day pagetables that we use before the allocators
> are up */
> +/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */

Is 0th ARM's numbering scheme or ours?  I don't object to it, but if
we're diverging from their numbering we should say so somewhere
(e.g. in the comment in asm-arm/page.h:75)

>  lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> +#ifdef CONFIG_ARM_64
> +lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> +#endif
>  lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
>  lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
>  static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
>  
>  /* Non-boot CPUs use this to find the correct pagetables. */
> -uint64_t boot_httbr;
> +uint64_t boot_ttbr;
>  
>  static paddr_t phys_offset;
>  
> @@ -69,24 +73,24 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
>      if ( first_table_offset(addr) >= LPAE_ENTRIES )
>          return;
>  
> -    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
> -           first_table_offset(addr),
> +    printk("1ST[0x%lx] = 0x%"PRIpaddr"\n",
> +           (unsigned long)first_table_offset(addr),

Eep!  Please either cast to paddr_t or stop using PRIpaddr (likewise
below).  I suppose it might be useful to have the nth_*_offset() macros
explicitly cast to some suitable small integer type, instead.

>             first[first_table_offset(addr)].bits);
>      if ( !first[first_table_offset(addr)].walk.valid ||
>           !first[first_table_offset(addr)].walk.table )
>          goto done;
>  
>      second = map_domain_page(first[first_table_offset(addr)].walk.base);
> -    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
> -           second_table_offset(addr),
> +    printk("2ND[0x%lx] = 0x%"PRIpaddr"\n",
> +           (unsigned long)second_table_offset(addr),
>             second[second_table_offset(addr)].bits);
>      if ( !second[second_table_offset(addr)].walk.valid ||
>           !second[second_table_offset(addr)].walk.table )
>          goto done;
>  
>      third = map_domain_page(second[second_table_offset(addr)].walk.base);
> -    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
> -           third_table_offset(addr),
> +    printk("3RD[0x%lx] = 0x%"PRIpaddr"\n",
> +           (unsigned long)third_table_offset(addr),
>             third[third_table_offset(addr)].bits);
>  
>  done:
> @@ -95,14 +99,14 @@ done:
>  
>  }
>  
> -void dump_hyp_walk(uint32_t addr)
> +void dump_hyp_walk(vaddr_t addr)
>  {
> -    uint64_t httbr = READ_CP64(HTTBR);
> +    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
>  
> -    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
> -           addr, httbr);
> +    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR0_EL2 0x%016"PRIx64"\n",
> +           addr, ttbr);

Are we going with ARM64 names for HTTBR &c even on 32-bit?  Maybe 'TTBR'
would do in this case.

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 Feb 14 11:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:48: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 1U5xIe-0001fz-RK; Thu, 14 Feb 2013 11:48:24 +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 1U5xId-0001fm-AR
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:48:23 +0000
Received: from [85.158.143.99:23886] by server-2.bemta-4.messagelabs.com id
	95/DB-01597-60FCC115; Thu, 14 Feb 2013 11:48:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360842500!27531108!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10278 invoked from network); 14 Feb 2013 11:48:20 -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; 14 Feb 2013 11:48:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xIY-000M8K-UV; Thu, 14 Feb 2013 11:48:18 +0000
Date: Thu, 14 Feb 2013 11:48:18 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214114818.GK83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 21/45] xen: arm64: changes to
	setup_pagetables and mm.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 15:56 +0000 on 23 Jan (1358956587), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

> index eb5213e..e870ef6 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -40,13 +40,17 @@
>  struct domain *dom_xen, *dom_io, *dom_cow;
>  
>  /* Static start-of-day pagetables that we use before the allocators
> are up */
> +/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */

Is 0th ARM's numbering scheme or ours?  I don't object to it, but if
we're diverging from their numbering we should say so somewhere
(e.g. in the comment in asm-arm/page.h:75)

>  lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> +#ifdef CONFIG_ARM_64
> +lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> +#endif
>  lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
>  lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
>  static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
>  
>  /* Non-boot CPUs use this to find the correct pagetables. */
> -uint64_t boot_httbr;
> +uint64_t boot_ttbr;
>  
>  static paddr_t phys_offset;
>  
> @@ -69,24 +73,24 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
>      if ( first_table_offset(addr) >= LPAE_ENTRIES )
>          return;
>  
> -    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
> -           first_table_offset(addr),
> +    printk("1ST[0x%lx] = 0x%"PRIpaddr"\n",
> +           (unsigned long)first_table_offset(addr),

Eep!  Please either cast to paddr_t or stop using PRIpaddr (likewise
below).  I suppose it might be useful to have the nth_*_offset() macros
explicitly cast to some suitable small integer type, instead.

>             first[first_table_offset(addr)].bits);
>      if ( !first[first_table_offset(addr)].walk.valid ||
>           !first[first_table_offset(addr)].walk.table )
>          goto done;
>  
>      second = map_domain_page(first[first_table_offset(addr)].walk.base);
> -    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
> -           second_table_offset(addr),
> +    printk("2ND[0x%lx] = 0x%"PRIpaddr"\n",
> +           (unsigned long)second_table_offset(addr),
>             second[second_table_offset(addr)].bits);
>      if ( !second[second_table_offset(addr)].walk.valid ||
>           !second[second_table_offset(addr)].walk.table )
>          goto done;
>  
>      third = map_domain_page(second[second_table_offset(addr)].walk.base);
> -    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
> -           third_table_offset(addr),
> +    printk("3RD[0x%lx] = 0x%"PRIpaddr"\n",
> +           (unsigned long)third_table_offset(addr),
>             third[third_table_offset(addr)].bits);
>  
>  done:
> @@ -95,14 +99,14 @@ done:
>  
>  }
>  
> -void dump_hyp_walk(uint32_t addr)
> +void dump_hyp_walk(vaddr_t addr)
>  {
> -    uint64_t httbr = READ_CP64(HTTBR);
> +    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
>  
> -    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
> -           addr, httbr);
> +    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR0_EL2 0x%016"PRIx64"\n",
> +           addr, ttbr);

Are we going with ARM64 names for HTTBR &c even on 32-bit?  Maybe 'TTBR'
would do in this case.

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 Feb 14 11:50:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:50: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 1U5xKg-0001sr-FL; Thu, 14 Feb 2013 11:50:30 +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 1U5xKe-0001sb-Tt
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:50:29 +0000
Received: from [193.109.254.147:6011] by server-11.bemta-14.messagelabs.com id
	56/13-30685-48FCC115; Thu, 14 Feb 2013 11:50:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360842575!8704789!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32642 invoked from network); 14 Feb 2013 11:49:37 -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; 14 Feb 2013 11:49:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xJn-000M8l-Iw; Thu, 14 Feb 2013 11:49:35 +0000
Date: Thu, 14 Feb 2013 11:49:35 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214114935.GL83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-22-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-22-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 22/45] xen: arm: extend HSR struct
	definitions to 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956588), Ian Campbell wrote:
> The main change is that the 4-bit register specifiers are extended
> to 5 bits by taking in an adjacent SBZP bit.
> 
> Also 64-bit has two other properties indicting whether or not the
> target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
> instruction has acquire/release semantics.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 11:50:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:50: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 1U5xKg-0001sr-FL; Thu, 14 Feb 2013 11:50:30 +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 1U5xKe-0001sb-Tt
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:50:29 +0000
Received: from [193.109.254.147:6011] by server-11.bemta-14.messagelabs.com id
	56/13-30685-48FCC115; Thu, 14 Feb 2013 11:50:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360842575!8704789!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32642 invoked from network); 14 Feb 2013 11:49:37 -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; 14 Feb 2013 11:49:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xJn-000M8l-Iw; Thu, 14 Feb 2013 11:49:35 +0000
Date: Thu, 14 Feb 2013 11:49:35 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214114935.GL83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-22-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-22-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 22/45] xen: arm: extend HSR struct
	definitions to 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956588), Ian Campbell wrote:
> The main change is that the 4-bit register specifiers are extended
> to 5 bits by taking in an adjacent SBZP bit.
> 
> Also 64-bit has two other properties indicting whether or not the
> target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
> instruction has acquire/release semantics.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 11:51:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5xL9-0001wV-Un; Thu, 14 Feb 2013 11:50:59 +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 1U5xL9-0001vj-4B
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:50:59 +0000
Received: from [193.109.254.147:59213] by server-8.bemta-14.messagelabs.com id
	A1/EC-17325-2AFCC115; Thu, 14 Feb 2013 11:50:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360842553!8788388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2834 invoked from network); 14 Feb 2013 11:49:13 -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; 14 Feb 2013 11:49:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:49:12 +0000
Message-Id: <511CDD8202000078000BE2F6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:50:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<1360841663.20449.345.camel@zakaz.uk.xensource.com>
	<1360841893.16636.113.camel@zion.uk.xensource.com>
In-Reply-To: <1360841893.16636.113.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 12:38, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 11:34 +0000, Ian Campbell wrote:
>> On Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:
>> 
>> > I'm not convinced. netbk_tx_err only has one xenvif_put, however
>> > netbk_fatal_tx_err has two puts.
>> 
>> One balances the get in poll_net_schedule_list (i.e. at the top of the
>> loop in xen_netbk_tx_build_gops.
>> 
>> The other one I guess you mean the one in xenvif_carrier_off? This
>> balances the refcount taken in xenvif_connect, when the carrier is
>> brought up.
>> 
>> In my testing I found that both were required or else things deadlock in
>> xenvif_disconnect with the refcnt stuck at 1.
>> 
>> The eventual put in xenvif_disconnect is balanced by the initial count
>> of 1 in xenvif_alloc()
> 
> Oh, I get what you mean now. Because the vif is down so
> xenvif_carrier_off is not invoked in disconnect path.
> 
> But I think a better place to balance refcount taken in xenvif_connect
> is xenvif_disconnect, so I would rather move that xenvif_put in
> fatal_tx_err to xenvif_disconnect.

I relatively certain this would make things worse, not better.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:51:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11: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 1U5xL9-0001wV-Un; Thu, 14 Feb 2013 11:50:59 +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 1U5xL9-0001vj-4B
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:50:59 +0000
Received: from [193.109.254.147:59213] by server-8.bemta-14.messagelabs.com id
	A1/EC-17325-2AFCC115; Thu, 14 Feb 2013 11:50:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360842553!8788388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2834 invoked from network); 14 Feb 2013 11:49:13 -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; 14 Feb 2013 11:49:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 11:49:12 +0000
Message-Id: <511CDD8202000078000BE2F6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 11:50:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<1360841663.20449.345.camel@zakaz.uk.xensource.com>
	<1360841893.16636.113.camel@zion.uk.xensource.com>
In-Reply-To: <1360841893.16636.113.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 12:38, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 11:34 +0000, Ian Campbell wrote:
>> On Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:
>> 
>> > I'm not convinced. netbk_tx_err only has one xenvif_put, however
>> > netbk_fatal_tx_err has two puts.
>> 
>> One balances the get in poll_net_schedule_list (i.e. at the top of the
>> loop in xen_netbk_tx_build_gops.
>> 
>> The other one I guess you mean the one in xenvif_carrier_off? This
>> balances the refcount taken in xenvif_connect, when the carrier is
>> brought up.
>> 
>> In my testing I found that both were required or else things deadlock in
>> xenvif_disconnect with the refcnt stuck at 1.
>> 
>> The eventual put in xenvif_disconnect is balanced by the initial count
>> of 1 in xenvif_alloc()
> 
> Oh, I get what you mean now. Because the vif is down so
> xenvif_carrier_off is not invoked in disconnect path.
> 
> But I think a better place to balance refcount taken in xenvif_connect
> is xenvif_disconnect, so I would rather move that xenvif_put in
> fatal_tx_err to xenvif_disconnect.

I relatively certain this would make things worse, not better.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:51:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:51: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 1U5xLU-00020c-Cl; Thu, 14 Feb 2013 11:51:20 +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 1U5xLS-000209-88
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:51:18 +0000
Received: from [85.158.139.83:31801] by server-8.bemta-5.messagelabs.com id
	3F/D1-19075-5BFCC115; Thu, 14 Feb 2013 11:51:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360842676!21360834!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8554 invoked from network); 14 Feb 2013 11:51:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1457265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:51: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.297.1;
	Thu, 14 Feb 2013 11:51:16 +0000
Message-ID: <1360842674.20449.349.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 11:51:14 +0000
In-Reply-To: <20130214113716.GJ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
	<20130214113716.GJ83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 20/45] xen: arm64: start of day changes to
 setup.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 Thu, 2013-02-14 at 11:37 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956586), Ian Campbell wrote:
> > @@ -320,8 +339,8 @@ void __init setup_cache(void)
> >      uint32_t ccsid;
> >  
> >      /* Read the cache size ID register for the level-0 data cache */
> > -    WRITE_CP32(0, CSSELR);
> > -    ccsid = READ_CP32(CCSIDR);
> > +    WRITE_SYSREG32(0, CSSELR_EL1);
> > +    ccsid = READ_SYSREG32(CSSELR_EL1);
> 
> CSSIDR_EL1 ?

CCSIDR_EL1, but yes, good catch.

8<-----------------------------------

>From 4685f77a8c5fa3916a4272437429e9c5349e3ad6 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 13 Dec 2012 15:24:11 +0000
Subject: [PATCH] xen: arm64: start of day changes to setup.c

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: s/CSSELR_EL1/CCSIDR_EL1
---
 xen/arch/arm/setup.c         |   54 ++++++++++++++++++++++++++++--------------
 xen/include/asm-arm/cpregs.h |   25 +++++++++++++++++++
 2 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4e50b2b..c1f06c9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,16 +56,34 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
-    printk("Processor Features: %08x %08x\n",
-           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
-    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
-    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
-    printk("Memory Model Features: %08x %08x %08x %08x\n",
-           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
-           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
-    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
-           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+#if defined(CONFIG_ARM_64)
+    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
+    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
+    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
+    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
+    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+#endif
+    /*
+     * On AArch64 these refer to the capabilities when running in
+     * AArch32 mode.
+     */
+    printk("32-bit Processor Features: %08x %08x\n",
+           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
+    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
+    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
+    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
+           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
+    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
+           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
+           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
+
 }
 
 void __init discard_initial_modules(void)
@@ -250,7 +268,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    printk("Xen heap: %lu pages  Dom heap: %lu pages\n",
+           xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -320,8 +339,8 @@ void __init setup_cache(void)
     uint32_t ccsid;
 
     /* Read the cache size ID register for the level-0 data cache */
-    WRITE_CP32(0, CSSELR);
-    ccsid = READ_CP32(CCSIDR);
+    WRITE_SYSREG32(0, CSSELR_EL1);
+    ccsid = READ_SYSREG32(CCSIDR_EL1);
 
     /* Low 3 bits are log2(cacheline size in words) - 2. */
     cacheline_bytes = 1U << (4 + (ccsid & 0x7));
@@ -368,16 +387,15 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
-    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
-           READ_CP32(HVBAR), hyp_traps_vector);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    isb();
 
     /* Setup Stage 2 address translation */
     /* SH0=00, ORGN0=IRGN0=01
      * SL0=01 (Level-1)
      * T0SZ=(1)1000 = -8 (40 bit physical addresses)
      */
-    WRITE_CP32(0x80002558, VTCR); isb();
+    WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
     processor_id();
 
@@ -455,7 +473,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* Switch on to the dynamically allocated stack for the idle vcpu
      * since the static one we're running on is about to be freed. */
-    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(), 
+    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
            sizeof(struct cpu_info));
     switch_stack_and_jump(idle_vcpu[0]->arch.cpu_info, init_done);
 }
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7eaa50f..559be75 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -222,6 +222,31 @@
 
 /* CP15 CR15: Implementation Defined Registers */
 
+/* Aliases of AArch64 names for use in common code when building for AArch32 */
+#ifdef CONFIG_ARM_32
+/* Alphabetically... */
+#define CCSIDR_EL1              CCSIDR
+#define CLIDR_EL1               CLIDR
+#define CSSELR_EL1              CSSELR
+#define ID_AFR0_EL1             ID_AFR0
+#define ID_DFR0_EL1             ID_DFR0
+#define ID_ISAR0_EL1            ID_ISAR0
+#define ID_ISAR1_EL1            ID_ISAR1
+#define ID_ISAR2_EL1            ID_ISAR2
+#define ID_ISAR3_EL1            ID_ISAR3
+#define ID_ISAR4_EL1            ID_ISAR4
+#define ID_ISAR5_EL1            ID_ISAR5
+#define ID_MMFR0_EL1            ID_MMFR0
+#define ID_MMFR1_EL1            ID_MMFR1
+#define ID_MMFR2_EL1            ID_MMFR2
+#define ID_MMFR3_EL1            ID_MMFR3
+#define ID_PFR0_EL1             ID_PFR0
+#define ID_PFR1_EL1             ID_PFR1
+#define VBAR_EL2                HVBAR
+#define VTCR_EL2                VTCR
+
+#endif
+
 #endif
 /*
  * Local variables:
-- 
1.7.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 Feb 14 11:51:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:51: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 1U5xLU-00020c-Cl; Thu, 14 Feb 2013 11:51:20 +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 1U5xLS-000209-88
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:51:18 +0000
Received: from [85.158.139.83:31801] by server-8.bemta-5.messagelabs.com id
	3F/D1-19075-5BFCC115; Thu, 14 Feb 2013 11:51:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360842676!21360834!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8554 invoked from network); 14 Feb 2013 11:51:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1457265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 11:51: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.297.1;
	Thu, 14 Feb 2013 11:51:16 +0000
Message-ID: <1360842674.20449.349.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 11:51:14 +0000
In-Reply-To: <20130214113716.GJ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
	<20130214113716.GJ83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 20/45] xen: arm64: start of day changes to
 setup.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 Thu, 2013-02-14 at 11:37 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956586), Ian Campbell wrote:
> > @@ -320,8 +339,8 @@ void __init setup_cache(void)
> >      uint32_t ccsid;
> >  
> >      /* Read the cache size ID register for the level-0 data cache */
> > -    WRITE_CP32(0, CSSELR);
> > -    ccsid = READ_CP32(CCSIDR);
> > +    WRITE_SYSREG32(0, CSSELR_EL1);
> > +    ccsid = READ_SYSREG32(CSSELR_EL1);
> 
> CSSIDR_EL1 ?

CCSIDR_EL1, but yes, good catch.

8<-----------------------------------

>From 4685f77a8c5fa3916a4272437429e9c5349e3ad6 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 13 Dec 2012 15:24:11 +0000
Subject: [PATCH] xen: arm64: start of day changes to setup.c

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: s/CSSELR_EL1/CCSIDR_EL1
---
 xen/arch/arm/setup.c         |   54 ++++++++++++++++++++++++++++--------------
 xen/include/asm-arm/cpregs.h |   25 +++++++++++++++++++
 2 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4e50b2b..c1f06c9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,16 +56,34 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
-    printk("Processor Features: %08x %08x\n",
-           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
-    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
-    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
-    printk("Memory Model Features: %08x %08x %08x %08x\n",
-           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
-           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
-    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
-           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+#if defined(CONFIG_ARM_64)
+    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
+    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
+    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
+    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
+    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+#endif
+    /*
+     * On AArch64 these refer to the capabilities when running in
+     * AArch32 mode.
+     */
+    printk("32-bit Processor Features: %08x %08x\n",
+           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
+    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
+    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
+    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
+           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
+    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
+           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
+           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
+
 }
 
 void __init discard_initial_modules(void)
@@ -250,7 +268,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    printk("Xen heap: %lu pages  Dom heap: %lu pages\n",
+           xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -320,8 +339,8 @@ void __init setup_cache(void)
     uint32_t ccsid;
 
     /* Read the cache size ID register for the level-0 data cache */
-    WRITE_CP32(0, CSSELR);
-    ccsid = READ_CP32(CCSIDR);
+    WRITE_SYSREG32(0, CSSELR_EL1);
+    ccsid = READ_SYSREG32(CCSIDR_EL1);
 
     /* Low 3 bits are log2(cacheline size in words) - 2. */
     cacheline_bytes = 1U << (4 + (ccsid & 0x7));
@@ -368,16 +387,15 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
-    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
-           READ_CP32(HVBAR), hyp_traps_vector);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    isb();
 
     /* Setup Stage 2 address translation */
     /* SH0=00, ORGN0=IRGN0=01
      * SL0=01 (Level-1)
      * T0SZ=(1)1000 = -8 (40 bit physical addresses)
      */
-    WRITE_CP32(0x80002558, VTCR); isb();
+    WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
     processor_id();
 
@@ -455,7 +473,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* Switch on to the dynamically allocated stack for the idle vcpu
      * since the static one we're running on is about to be freed. */
-    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(), 
+    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
            sizeof(struct cpu_info));
     switch_stack_and_jump(idle_vcpu[0]->arch.cpu_info, init_done);
 }
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7eaa50f..559be75 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -222,6 +222,31 @@
 
 /* CP15 CR15: Implementation Defined Registers */
 
+/* Aliases of AArch64 names for use in common code when building for AArch32 */
+#ifdef CONFIG_ARM_32
+/* Alphabetically... */
+#define CCSIDR_EL1              CCSIDR
+#define CLIDR_EL1               CLIDR
+#define CSSELR_EL1              CSSELR
+#define ID_AFR0_EL1             ID_AFR0
+#define ID_DFR0_EL1             ID_DFR0
+#define ID_ISAR0_EL1            ID_ISAR0
+#define ID_ISAR1_EL1            ID_ISAR1
+#define ID_ISAR2_EL1            ID_ISAR2
+#define ID_ISAR3_EL1            ID_ISAR3
+#define ID_ISAR4_EL1            ID_ISAR4
+#define ID_ISAR5_EL1            ID_ISAR5
+#define ID_MMFR0_EL1            ID_MMFR0
+#define ID_MMFR1_EL1            ID_MMFR1
+#define ID_MMFR2_EL1            ID_MMFR2
+#define ID_MMFR3_EL1            ID_MMFR3
+#define ID_PFR0_EL1             ID_PFR0
+#define ID_PFR1_EL1             ID_PFR1
+#define VBAR_EL2                HVBAR
+#define VTCR_EL2                VTCR
+
+#endif
+
 #endif
 /*
  * Local variables:
-- 
1.7.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 Feb 14 11:56:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:56: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 1U5xQI-0002Tw-EL; Thu, 14 Feb 2013 11:56:18 +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 1U5xQH-0002Tr-Sz
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:56:18 +0000
Received: from [85.158.139.211:27697] by server-16.bemta-5.messagelabs.com id
	1F/8B-14948-1E0DC115; Thu, 14 Feb 2013 11:56:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360842976!22478536!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11012 invoked from network); 14 Feb 2013 11:56:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:56:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xQF-000MAb-DL; Thu, 14 Feb 2013 11:56:15 +0000
Date: Thu, 14 Feb 2013 11:56:15 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130214115615.GM83752@ocelot.phlegethon.org>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/arm: support the ARM generic
	virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:46 +0000 on 14 Feb (1360842373), Stefano Stabellini wrote:
> On Thu, 24 Jan 2013, Tim Deegan wrote:
> > At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > > +{
> > > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> > 
> > This is masking the vtimer interrupt in a way that's visible to the
> > currently running guest.  Is that going to confuse the guest?
> >
> > When we talked about this before I had imagined that the masking would
> > happen in the GIC, where the guest doesn't see it. 
> 
> I know it is not ideal but it is safe, it is not creating any problems to
> Linux and it is even the same thing that KVM does).

Grrr.  So it's safe unless you run something other than linux, or KVM
devs change their minds...

Do we have an interface document to describe the PV machine that we
provide to a guest?  If so, this divergence from the spec should be
described there.  If not, we really should. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:56:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:56: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 1U5xQI-0002Tw-EL; Thu, 14 Feb 2013 11:56:18 +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 1U5xQH-0002Tr-Sz
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:56:18 +0000
Received: from [85.158.139.211:27697] by server-16.bemta-5.messagelabs.com id
	1F/8B-14948-1E0DC115; Thu, 14 Feb 2013 11:56:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360842976!22478536!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11012 invoked from network); 14 Feb 2013 11:56:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 11:56:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xQF-000MAb-DL; Thu, 14 Feb 2013 11:56:15 +0000
Date: Thu, 14 Feb 2013 11:56:15 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130214115615.GM83752@ocelot.phlegethon.org>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/arm: support the ARM generic
	virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:46 +0000 on 14 Feb (1360842373), Stefano Stabellini wrote:
> On Thu, 24 Jan 2013, Tim Deegan wrote:
> > At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > > +{
> > > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> > 
> > This is masking the vtimer interrupt in a way that's visible to the
> > currently running guest.  Is that going to confuse the guest?
> >
> > When we talked about this before I had imagined that the masking would
> > happen in the GIC, where the guest doesn't see it. 
> 
> I know it is not ideal but it is safe, it is not creating any problems to
> Linux and it is even the same thing that KVM does).

Grrr.  So it's safe unless you run something other than linux, or KVM
devs change their minds...

Do we have an interface document to describe the PV machine that we
provide to a guest?  If so, this divergence from the spec should be
described there.  If not, we really should. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 11:58:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:58: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 1U5xRw-0002a3-W9; Thu, 14 Feb 2013 11:58:01 +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 1U5xRw-0002Zy-0k
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:58:00 +0000
Received: from [85.158.143.99:23429] by server-3.bemta-4.messagelabs.com id
	2E/30-08920-741DC115; Thu, 14 Feb 2013 11:57:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360843078!22231364!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18274 invoked from network); 14 Feb 2013 11:57:58 -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; 14 Feb 2013 11:57:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xRu-000MAu-Cn; Thu, 14 Feb 2013 11:57:58 +0000
Date: Thu, 14 Feb 2013 11:57:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214115758.GN83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
	<20130214113716.GJ83752@ocelot.phlegethon.org>
	<1360842674.20449.349.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360842674.20449.349.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/45] xen: arm64: start of day changes to
	setup.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 11:51 +0000 on 14 Feb (1360842674), Ian Campbell wrote:
> On Thu, 2013-02-14 at 11:37 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956586), Ian Campbell wrote:
> > > @@ -320,8 +339,8 @@ void __init setup_cache(void)
> > >      uint32_t ccsid;
> > >  
> > >      /* Read the cache size ID register for the level-0 data cache */
> > > -    WRITE_CP32(0, CSSELR);
> > > -    ccsid = READ_CP32(CCSIDR);
> > > +    WRITE_SYSREG32(0, CSSELR_EL1);
> > > +    ccsid = READ_SYSREG32(CSSELR_EL1);
> > 
> > CSSIDR_EL1 ?
> 
> CCSIDR_EL1, but yes, good catch.
> 
> 8<-----------------------------------
> 
> From 4685f77a8c5fa3916a4272437429e9c5349e3ad6 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 13 Dec 2012 15:24:11 +0000
> Subject: [PATCH] xen: arm64: start of day changes to setup.c
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: s/CSSELR_EL1/CCSIDR_EL1
> ---

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 Thu Feb 14 11:58:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 11:58: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 1U5xRw-0002a3-W9; Thu, 14 Feb 2013 11:58:01 +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 1U5xRw-0002Zy-0k
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 11:58:00 +0000
Received: from [85.158.143.99:23429] by server-3.bemta-4.messagelabs.com id
	2E/30-08920-741DC115; Thu, 14 Feb 2013 11:57:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360843078!22231364!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18274 invoked from network); 14 Feb 2013 11:57:58 -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; 14 Feb 2013 11:57:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xRu-000MAu-Cn; Thu, 14 Feb 2013 11:57:58 +0000
Date: Thu, 14 Feb 2013 11:57:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214115758.GN83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-20-git-send-email-ian.campbell@citrix.com>
	<20130214113716.GJ83752@ocelot.phlegethon.org>
	<1360842674.20449.349.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360842674.20449.349.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 20/45] xen: arm64: start of day changes to
	setup.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 11:51 +0000 on 14 Feb (1360842674), Ian Campbell wrote:
> On Thu, 2013-02-14 at 11:37 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956586), Ian Campbell wrote:
> > > @@ -320,8 +339,8 @@ void __init setup_cache(void)
> > >      uint32_t ccsid;
> > >  
> > >      /* Read the cache size ID register for the level-0 data cache */
> > > -    WRITE_CP32(0, CSSELR);
> > > -    ccsid = READ_CP32(CCSIDR);
> > > +    WRITE_SYSREG32(0, CSSELR_EL1);
> > > +    ccsid = READ_SYSREG32(CSSELR_EL1);
> > 
> > CSSIDR_EL1 ?
> 
> CCSIDR_EL1, but yes, good catch.
> 
> 8<-----------------------------------
> 
> From 4685f77a8c5fa3916a4272437429e9c5349e3ad6 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 13 Dec 2012 15:24:11 +0000
> Subject: [PATCH] xen: arm64: start of day changes to setup.c
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: s/CSSELR_EL1/CCSIDR_EL1
> ---

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 Thu Feb 14 12:02:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:02: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 1U5xVz-0002x2-KJ; Thu, 14 Feb 2013 12:02:11 +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 1U5xVx-0002wp-RE
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:02:10 +0000
Received: from [85.158.139.211:25219] by server-12.bemta-5.messagelabs.com id
	A7/94-20195-142DC115; Thu, 14 Feb 2013 12:02:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360843326!19740607!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5123 invoked from network); 14 Feb 2013 12:02:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7116175"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:02:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:02:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5xQn-0004mP-9I;
	Thu, 14 Feb 2013 11:56:49 +0000
Message-ID: <1360843009.16636.115.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 11:56:49 +0000
In-Reply-To: <511CDD8202000078000BE2F6@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<1360841663.20449.345.camel@zakaz.uk.xensource.com>
	<1360841893.16636.113.camel@zion.uk.xensource.com>
	<511CDD8202000078000BE2F6@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:50 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 12:38, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, 2013-02-14 at 11:34 +0000, Ian Campbell wrote:
> >> On Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:
> >> 
> >> > I'm not convinced. netbk_tx_err only has one xenvif_put, however
> >> > netbk_fatal_tx_err has two puts.
> >> 
> >> One balances the get in poll_net_schedule_list (i.e. at the top of the
> >> loop in xen_netbk_tx_build_gops.
> >> 
> >> The other one I guess you mean the one in xenvif_carrier_off? This
> >> balances the refcount taken in xenvif_connect, when the carrier is
> >> brought up.
> >> 
> >> In my testing I found that both were required or else things deadlock in
> >> xenvif_disconnect with the refcnt stuck at 1.
> >> 
> >> The eventual put in xenvif_disconnect is balanced by the initial count
> >> of 1 in xenvif_alloc()
> > 
> > Oh, I get what you mean now. Because the vif is down so
> > xenvif_carrier_off is not invoked in disconnect path.
> > 
> > But I think a better place to balance refcount taken in xenvif_connect
> > is xenvif_disconnect, so I would rather move that xenvif_put in
> > fatal_tx_err to xenvif_disconnect.
> 
> I relatively certain this would make things worse, not better.
> 

Oops, my mistake. Let it stay like this is just fine.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:02:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:02: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 1U5xVz-0002x2-KJ; Thu, 14 Feb 2013 12:02:11 +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 1U5xVx-0002wp-RE
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:02:10 +0000
Received: from [85.158.139.211:25219] by server-12.bemta-5.messagelabs.com id
	A7/94-20195-142DC115; Thu, 14 Feb 2013 12:02:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360843326!19740607!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5123 invoked from network); 14 Feb 2013 12:02:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7116175"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:02:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:02:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5xQn-0004mP-9I;
	Thu, 14 Feb 2013 11:56:49 +0000
Message-ID: <1360843009.16636.115.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 11:56:49 +0000
In-Reply-To: <511CDD8202000078000BE2F6@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<1360841663.20449.345.camel@zakaz.uk.xensource.com>
	<1360841893.16636.113.camel@zion.uk.xensource.com>
	<511CDD8202000078000BE2F6@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:50 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 12:38, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, 2013-02-14 at 11:34 +0000, Ian Campbell wrote:
> >> On Thu, 2013-02-14 at 11:20 +0000, Wei Liu wrote:
> >> 
> >> > I'm not convinced. netbk_tx_err only has one xenvif_put, however
> >> > netbk_fatal_tx_err has two puts.
> >> 
> >> One balances the get in poll_net_schedule_list (i.e. at the top of the
> >> loop in xen_netbk_tx_build_gops.
> >> 
> >> The other one I guess you mean the one in xenvif_carrier_off? This
> >> balances the refcount taken in xenvif_connect, when the carrier is
> >> brought up.
> >> 
> >> In my testing I found that both were required or else things deadlock in
> >> xenvif_disconnect with the refcnt stuck at 1.
> >> 
> >> The eventual put in xenvif_disconnect is balanced by the initial count
> >> of 1 in xenvif_alloc()
> > 
> > Oh, I get what you mean now. Because the vif is down so
> > xenvif_carrier_off is not invoked in disconnect path.
> > 
> > But I think a better place to balance refcount taken in xenvif_connect
> > is xenvif_disconnect, so I would rather move that xenvif_put in
> > fatal_tx_err to xenvif_disconnect.
> 
> I relatively certain this would make things worse, not better.
> 

Oops, my mistake. Let it stay like this is just fine.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:02:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5xW2-0002xM-2A; Thu, 14 Feb 2013 12:02: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 1U5xVz-0002x0-MZ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:02:11 +0000
Received: from [85.158.143.35:63509] by server-2.bemta-4.messagelabs.com id
	35/20-01597-342DC115; Thu, 14 Feb 2013 12:02:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360843328!12353083!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26948 invoked from network); 14 Feb 2013 12:02:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1457723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 12:02: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.297.1;
	Thu, 14 Feb 2013 12:02:08 +0000
Message-ID: <1360843326.20449.356.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 12:02:06 +0000
In-Reply-To: <20130214114818.GK83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
	<20130214114818.GK83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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/45] xen: arm64: changes to
 setup_pagetables and mm.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 Thu, 2013-02-14 at 11:48 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956587), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > index eb5213e..e870ef6 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -40,13 +40,17 @@
> >  struct domain *dom_xen, *dom_io, *dom_cow;
> >  
> >  /* Static start-of-day pagetables that we use before the allocators
> > are up */
> > +/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
> 
> Is 0th ARM's numbering scheme or ours?  I don't object to it, but if
> we're diverging from their numbering we should say so somewhere
> (e.g. in the comment in asm-arm/page.h:75)

They talk about level 0..3 in their books. (In theory their scheme
allows for five levels, not sure what happens then ;-))

> >  lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> > +#ifdef CONFIG_ARM_64
> > +lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> > +#endif
> >  lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
> >  lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> >  static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> >  
> >  /* Non-boot CPUs use this to find the correct pagetables. */
> > -uint64_t boot_httbr;
> > +uint64_t boot_ttbr;
> >  
> >  static paddr_t phys_offset;
> >  
> > @@ -69,24 +73,24 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
> >      if ( first_table_offset(addr) >= LPAE_ENTRIES )
> >          return;
> >  
> > -    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
> > -           first_table_offset(addr),
> > +    printk("1ST[0x%lx] = 0x%"PRIpaddr"\n",
> > +           (unsigned long)first_table_offset(addr),
> 
> Eep!  Please either cast to paddr_t or stop using PRIpaddr (likewise
> below).  I suppose it might be useful to have the nth_*_offset() macros
> explicitly cast to some suitable small integer type, instead.

The cast is associated with the %lx, not the %PRIpaddr. I think PRIpaddr
is right where it is used.

Casting in the _offset() might be better -- unsigned long is good?

> >             first[first_table_offset(addr)].bits);
> >      if ( !first[first_table_offset(addr)].walk.valid ||
> >           !first[first_table_offset(addr)].walk.table )
> >          goto done;
> >  
> >      second = map_domain_page(first[first_table_offset(addr)].walk.base);
> > -    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
> > -           second_table_offset(addr),
> > +    printk("2ND[0x%lx] = 0x%"PRIpaddr"\n",
> > +           (unsigned long)second_table_offset(addr),
> >             second[second_table_offset(addr)].bits);
> >      if ( !second[second_table_offset(addr)].walk.valid ||
> >           !second[second_table_offset(addr)].walk.table )
> >          goto done;
> >  
> >      third = map_domain_page(second[second_table_offset(addr)].walk.base);
> > -    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
> > -           third_table_offset(addr),
> > +    printk("3RD[0x%lx] = 0x%"PRIpaddr"\n",
> > +           (unsigned long)third_table_offset(addr),
> >             third[third_table_offset(addr)].bits);
> >  
> >  done:
> > @@ -95,14 +99,14 @@ done:
> >  
> >  }
> >  
> > -void dump_hyp_walk(uint32_t addr)
> > +void dump_hyp_walk(vaddr_t addr)
> >  {
> > -    uint64_t httbr = READ_CP64(HTTBR);
> > +    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
> >  
> > -    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
> > -           addr, httbr);
> > +    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR0_EL2 0x%016"PRIx64"\n",
> > +           addr, ttbr);
> 
> Are we going with ARM64 names for HTTBR &c even on 32-bit?  Maybe 'TTBR'
> would do in this case.

For talking about actual registers I want to use ARM64 names in any
where that isn't 100% 32-bit code. Partly because it makes the accessor
macros easier (because the 64-bit gas speaks the names natively, without
cpp magic) and also just because I think consistence is worthwhile,
nothing would be worse than mixing and matching in common code!

For variable names the arm64 names are a bit ugly though (e.g.
ttbr0_el2), I think ttbr is a good compromise if the context is such
that its not confusing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:02:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5xW2-0002xM-2A; Thu, 14 Feb 2013 12:02: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 1U5xVz-0002x0-MZ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:02:11 +0000
Received: from [85.158.143.35:63509] by server-2.bemta-4.messagelabs.com id
	35/20-01597-342DC115; Thu, 14 Feb 2013 12:02:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360843328!12353083!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26948 invoked from network); 14 Feb 2013 12:02:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1457723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 12:02: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.297.1;
	Thu, 14 Feb 2013 12:02:08 +0000
Message-ID: <1360843326.20449.356.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 12:02:06 +0000
In-Reply-To: <20130214114818.GK83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
	<20130214114818.GK83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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/45] xen: arm64: changes to
 setup_pagetables and mm.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 Thu, 2013-02-14 at 11:48 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956587), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > index eb5213e..e870ef6 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -40,13 +40,17 @@
> >  struct domain *dom_xen, *dom_io, *dom_cow;
> >  
> >  /* Static start-of-day pagetables that we use before the allocators
> > are up */
> > +/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
> 
> Is 0th ARM's numbering scheme or ours?  I don't object to it, but if
> we're diverging from their numbering we should say so somewhere
> (e.g. in the comment in asm-arm/page.h:75)

They talk about level 0..3 in their books. (In theory their scheme
allows for five levels, not sure what happens then ;-))

> >  lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> > +#ifdef CONFIG_ARM_64
> > +lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> > +#endif
> >  lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
> >  lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> >  static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
> >  
> >  /* Non-boot CPUs use this to find the correct pagetables. */
> > -uint64_t boot_httbr;
> > +uint64_t boot_ttbr;
> >  
> >  static paddr_t phys_offset;
> >  
> > @@ -69,24 +73,24 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
> >      if ( first_table_offset(addr) >= LPAE_ENTRIES )
> >          return;
> >  
> > -    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
> > -           first_table_offset(addr),
> > +    printk("1ST[0x%lx] = 0x%"PRIpaddr"\n",
> > +           (unsigned long)first_table_offset(addr),
> 
> Eep!  Please either cast to paddr_t or stop using PRIpaddr (likewise
> below).  I suppose it might be useful to have the nth_*_offset() macros
> explicitly cast to some suitable small integer type, instead.

The cast is associated with the %lx, not the %PRIpaddr. I think PRIpaddr
is right where it is used.

Casting in the _offset() might be better -- unsigned long is good?

> >             first[first_table_offset(addr)].bits);
> >      if ( !first[first_table_offset(addr)].walk.valid ||
> >           !first[first_table_offset(addr)].walk.table )
> >          goto done;
> >  
> >      second = map_domain_page(first[first_table_offset(addr)].walk.base);
> > -    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
> > -           second_table_offset(addr),
> > +    printk("2ND[0x%lx] = 0x%"PRIpaddr"\n",
> > +           (unsigned long)second_table_offset(addr),
> >             second[second_table_offset(addr)].bits);
> >      if ( !second[second_table_offset(addr)].walk.valid ||
> >           !second[second_table_offset(addr)].walk.table )
> >          goto done;
> >  
> >      third = map_domain_page(second[second_table_offset(addr)].walk.base);
> > -    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
> > -           third_table_offset(addr),
> > +    printk("3RD[0x%lx] = 0x%"PRIpaddr"\n",
> > +           (unsigned long)third_table_offset(addr),
> >             third[third_table_offset(addr)].bits);
> >  
> >  done:
> > @@ -95,14 +99,14 @@ done:
> >  
> >  }
> >  
> > -void dump_hyp_walk(uint32_t addr)
> > +void dump_hyp_walk(vaddr_t addr)
> >  {
> > -    uint64_t httbr = READ_CP64(HTTBR);
> > +    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
> >  
> > -    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
> > -           addr, httbr);
> > +    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR0_EL2 0x%016"PRIx64"\n",
> > +           addr, ttbr);
> 
> Are we going with ARM64 names for HTTBR &c even on 32-bit?  Maybe 'TTBR'
> would do in this case.

For talking about actual registers I want to use ARM64 names in any
where that isn't 100% 32-bit code. Partly because it makes the accessor
macros easier (because the 64-bit gas speaks the names natively, without
cpp magic) and also just because I think consistence is worthwhile,
nothing would be worse than mixing and matching in common code!

For variable names the arm64 names are a bit ugly though (e.g.
ttbr0_el2), I think ttbr is a good compromise if the context is such
that its not confusing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:02:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5xWD-000300-HS; Thu, 14 Feb 2013 12:02:25 +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 1U5xWB-0002zZ-R0
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 12:02:24 +0000
Received: from [85.158.137.99:28924] by server-12.bemta-3.messagelabs.com id
	D7/3F-05889-A42DC115; Thu, 14 Feb 2013 12:02:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360843336!16743246!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27998 invoked from network); 14 Feb 2013 12:02:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:02:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7486480"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:02:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:02:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5xW3-0004wB-JO;
	Thu, 14 Feb 2013 12:02:15 +0000
Date: Thu, 14 Feb 2013 12:02:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130214115615.GM83752@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302141202040.8231@kaball.uk.xensource.com>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
	<20130214115615.GM83752@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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/2] xen/arm: support the ARM generic
 virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Tim Deegan wrote:
> At 11:46 +0000 on 14 Feb (1360842373), Stefano Stabellini wrote:
> > On Thu, 24 Jan 2013, Tim Deegan wrote:
> > > At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > > > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > > > +{
> > > > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > > > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> > > 
> > > This is masking the vtimer interrupt in a way that's visible to the
> > > currently running guest.  Is that going to confuse the guest?
> > >
> > > When we talked about this before I had imagined that the masking would
> > > happen in the GIC, where the guest doesn't see it. 
> > 
> > I know it is not ideal but it is safe, it is not creating any problems to
> > Linux and it is even the same thing that KVM does).
> 
> Grrr.  So it's safe unless you run something other than linux, or KVM
> devs change their minds...
> 
> Do we have an interface document to describe the PV machine that we
> provide to a guest?  If so, this divergence from the spec should be
> described there.  If not, we really should. :)

That's a good idea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:02:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5xWD-000300-HS; Thu, 14 Feb 2013 12:02:25 +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 1U5xWB-0002zZ-R0
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 12:02:24 +0000
Received: from [85.158.137.99:28924] by server-12.bemta-3.messagelabs.com id
	D7/3F-05889-A42DC115; Thu, 14 Feb 2013 12:02:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360843336!16743246!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27998 invoked from network); 14 Feb 2013 12:02:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:02:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7486480"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:02:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:02:15 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U5xW3-0004wB-JO;
	Thu, 14 Feb 2013 12:02:15 +0000
Date: Thu, 14 Feb 2013 12:02:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130214115615.GM83752@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302141202040.8231@kaball.uk.xensource.com>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
	<20130214115615.GM83752@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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/2] xen/arm: support the ARM generic
 virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Tim Deegan wrote:
> At 11:46 +0000 on 14 Feb (1360842373), Stefano Stabellini wrote:
> > On Thu, 24 Jan 2013, Tim Deegan wrote:
> > > At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > > > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > > > +{
> > > > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > > > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> > > 
> > > This is masking the vtimer interrupt in a way that's visible to the
> > > currently running guest.  Is that going to confuse the guest?
> > >
> > > When we talked about this before I had imagined that the masking would
> > > happen in the GIC, where the guest doesn't see it. 
> > 
> > I know it is not ideal but it is safe, it is not creating any problems to
> > Linux and it is even the same thing that KVM does).
> 
> Grrr.  So it's safe unless you run something other than linux, or KVM
> devs change their minds...
> 
> Do we have an interface document to describe the PV machine that we
> provide to a guest?  If so, this divergence from the spec should be
> described there.  If not, we really should. :)

That's a good idea

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:05:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:05: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 1U5xZE-0003Q3-Cp; Thu, 14 Feb 2013 12:05:32 +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 1U5xZC-0003Pt-HB
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 12:05:30 +0000
Received: from [85.158.139.211:36240] by server-6.bemta-5.messagelabs.com id
	FE/DC-01489-903DC115; Thu, 14 Feb 2013 12:05:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360843528!19740986!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20513 invoked from network); 14 Feb 2013 12:05:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:05:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1457973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 12:05: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.297.1;
	Thu, 14 Feb 2013 12:05:28 +0000
Message-ID: <1360843527.20449.357.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:05:27 +0000
In-Reply-To: <alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 1/2] xen/arm: support the ARM generic
 virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 11:46 +0000, Stefano Stabellini wrote:
> On Thu, 24 Jan 2013, Tim Deegan wrote:
> > At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > > +{
> > > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> > 
> > This is masking the vtimer interrupt in a way that's visible to the
> > currently running guest.  Is that going to confuse the guest?
> >
> > When we talked about this before I had imagined that the masking would
> > happen in the GIC, where the guest doesn't see it. 
> 
> I know it is not ideal but it is safe, it is not creating any problems to
> Linux and it is even the same thing that KVM does).
> More importantly I just couldn't get the GIC strategy to work correctly
> (actually it work decently well on the physical Versatile Express but it
> hangs the emulator, this tells me that it is not the way it was intended
> to be used by the ARM people).

I think we should ask ARM about this, it could just be a model bug. I'm
sure that they would be interested in cases where the virtualness leaks
out of the hardware like this.

Ian.

> 
> 
> > > +    vgic_vcpu_inject_irq(current, irq, 1);
> > > +}
> > > +
> > >  /* Set up the timer interrupt on this CPU */
> > >  void __cpuinit init_timer_interrupt(void)
> > >  {
> > > @@ -172,6 +183,7 @@ void __cpuinit init_timer_interrupt(void)
> > >  
> > >      /* XXX Need to find this IRQ number from devicetree? */
> > >      request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
> > > +    request_irq(27, vtimer_interrupt, 0, "virtimer", NULL);
> > >      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
> > >  }
> > >  
> > > +static void virt_timer_expired(void *data)
> > > +{
> > > +    struct vtimer *t = data;
> > > +    vcpu_wake(t->v);
> > 
> > Shouldn't this also inject the irq?  Otherwise when an unscheduled
> > guest's timer goes off, we take two interrupts - one for the hyp timer
> > to call this function and then another immediately after
> > virt_timer_restore() which causes us to inject the vtimer irq. 
> > If we injected the irq here (and arranged to mask the vtimer irq) we'd
> > avoid a second interrupt.
> 
> This might be a good idea, I'll give it a try.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:05:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:05: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 1U5xZE-0003Q3-Cp; Thu, 14 Feb 2013 12:05:32 +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 1U5xZC-0003Pt-HB
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 12:05:30 +0000
Received: from [85.158.139.211:36240] by server-6.bemta-5.messagelabs.com id
	FE/DC-01489-903DC115; Thu, 14 Feb 2013 12:05:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360843528!19740986!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20513 invoked from network); 14 Feb 2013 12:05:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:05:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1457973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 12:05: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.297.1;
	Thu, 14 Feb 2013 12:05:28 +0000
Message-ID: <1360843527.20449.357.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:05:27 +0000
In-Reply-To: <alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
References: <1357748278-22593-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20130124133611.GB20551@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302141139220.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 1/2] xen/arm: support the ARM generic
 virtual timer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 11:46 +0000, Stefano Stabellini wrote:
> On Thu, 24 Jan 2013, Tim Deegan wrote:
> > At 16:17 +0000 on 09 Jan (1357748277), Stefano Stabellini wrote:
> > > +static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
> > > +{
> > > +    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
> > > +    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
> > 
> > This is masking the vtimer interrupt in a way that's visible to the
> > currently running guest.  Is that going to confuse the guest?
> >
> > When we talked about this before I had imagined that the masking would
> > happen in the GIC, where the guest doesn't see it. 
> 
> I know it is not ideal but it is safe, it is not creating any problems to
> Linux and it is even the same thing that KVM does).
> More importantly I just couldn't get the GIC strategy to work correctly
> (actually it work decently well on the physical Versatile Express but it
> hangs the emulator, this tells me that it is not the way it was intended
> to be used by the ARM people).

I think we should ask ARM about this, it could just be a model bug. I'm
sure that they would be interested in cases where the virtualness leaks
out of the hardware like this.

Ian.

> 
> 
> > > +    vgic_vcpu_inject_irq(current, irq, 1);
> > > +}
> > > +
> > >  /* Set up the timer interrupt on this CPU */
> > >  void __cpuinit init_timer_interrupt(void)
> > >  {
> > > @@ -172,6 +183,7 @@ void __cpuinit init_timer_interrupt(void)
> > >  
> > >      /* XXX Need to find this IRQ number from devicetree? */
> > >      request_irq(26, timer_interrupt, 0, "hyptimer", NULL);
> > > +    request_irq(27, vtimer_interrupt, 0, "virtimer", NULL);
> > >      request_irq(30, timer_interrupt, 0, "phytimer", NULL);
> > >  }
> > >  
> > > +static void virt_timer_expired(void *data)
> > > +{
> > > +    struct vtimer *t = data;
> > > +    vcpu_wake(t->v);
> > 
> > Shouldn't this also inject the irq?  Otherwise when an unscheduled
> > guest's timer goes off, we take two interrupts - one for the hyp timer
> > to call this function and then another immediately after
> > virt_timer_restore() which causes us to inject the vtimer irq. 
> > If we injected the irq here (and arranged to mask the vtimer irq) we'd
> > avoid a second interrupt.
> 
> This might be a good idea, I'll give it a try.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:10:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:10: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 1U5xdS-0003fp-32; Thu, 14 Feb 2013 12:09:54 +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 1U5xdR-0003fi-CM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:09:53 +0000
Received: from [85.158.143.35:2453] by server-3.bemta-4.messagelabs.com id
	98/13-08920-014DC115; Thu, 14 Feb 2013 12:09:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360843772!13112038!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15115 invoked from network); 14 Feb 2013 12:09:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 12:09:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xd5-000MDf-ON; Thu, 14 Feb 2013 12:09:31 +0000
Date: Thu, 14 Feb 2013 12:09:31 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214120931.GO83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
	<20130214114818.GK83752@ocelot.phlegethon.org>
	<1360843326.20449.356.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360843326.20449.356.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 21/45] xen: arm64: changes to
	setup_pagetables and mm.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 12:02 +0000 on 14 Feb (1360843326), Ian Campbell wrote:
> On Thu, 2013-02-14 at 11:48 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956587), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > > index eb5213e..e870ef6 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -40,13 +40,17 @@
> > >  struct domain *dom_xen, *dom_io, *dom_cow;
> > >  
> > >  /* Static start-of-day pagetables that we use before the allocators
> > > are up */
> > > +/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
> > 
> > Is 0th ARM's numbering scheme or ours?  I don't object to it, but if
> > we're diverging from their numbering we should say so somewhere
> > (e.g. in the comment in asm-arm/page.h:75)
> 
> They talk about level 0..3 in their books. (In theory their scheme
> allows for five levels, not sure what happens then ;-))

Grand so. :)

> > > -    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
> > > -           first_table_offset(addr),
> > > +    printk("1ST[0x%lx] = 0x%"PRIpaddr"\n",
> > > +           (unsigned long)first_table_offset(addr),
> > 
> > Eep!  Please either cast to paddr_t or stop using PRIpaddr (likewise
> > below).  I suppose it might be useful to have the nth_*_offset() macros
> > explicitly cast to some suitable small integer type, instead.
> 
> The cast is associated with the %lx, not the %PRIpaddr. I think PRIpaddr
> is right where it is used.

Argh, so it is.  My apologies. 

> Casting in the _offset() might be better -- unsigned long is good?

Sure.  Or vaddr_t.

> > Are we going with ARM64 names for HTTBR &c even on 32-bit?  Maybe 'TTBR'
> > would do in this case.
> 
> For talking about actual registers I want to use ARM64 names in any
> where that isn't 100% 32-bit code. Partly because it makes the accessor
> macros easier (because the 64-bit gas speaks the names natively, without
> cpp magic) and also just because I think consistence is worthwhile,
> nothing would be worse than mixing and matching in common code!

OK.

> For variable names the arm64 names are a bit ugly though (e.g.
> ttbr0_el2), I think ttbr is a good compromise if the context is such
> that its not confusing.

Also good.  My comment was really about the printk, which I think can
happily use 'TTBR' here since it's obvious in this case which one we mean.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:10:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:10: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 1U5xdS-0003fp-32; Thu, 14 Feb 2013 12:09:54 +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 1U5xdR-0003fi-CM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:09:53 +0000
Received: from [85.158.143.35:2453] by server-3.bemta-4.messagelabs.com id
	98/13-08920-014DC115; Thu, 14 Feb 2013 12:09:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360843772!13112038!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15115 invoked from network); 14 Feb 2013 12:09:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 12:09:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xd5-000MDf-ON; Thu, 14 Feb 2013 12:09:31 +0000
Date: Thu, 14 Feb 2013 12:09:31 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214120931.GO83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-21-git-send-email-ian.campbell@citrix.com>
	<20130214114818.GK83752@ocelot.phlegethon.org>
	<1360843326.20449.356.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360843326.20449.356.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 21/45] xen: arm64: changes to
	setup_pagetables and mm.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 12:02 +0000 on 14 Feb (1360843326), Ian Campbell wrote:
> On Thu, 2013-02-14 at 11:48 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956587), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > > index eb5213e..e870ef6 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -40,13 +40,17 @@
> > >  struct domain *dom_xen, *dom_io, *dom_cow;
> > >  
> > >  /* Static start-of-day pagetables that we use before the allocators
> > > are up */
> > > +/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
> > 
> > Is 0th ARM's numbering scheme or ours?  I don't object to it, but if
> > we're diverging from their numbering we should say so somewhere
> > (e.g. in the comment in asm-arm/page.h:75)
> 
> They talk about level 0..3 in their books. (In theory their scheme
> allows for five levels, not sure what happens then ;-))

Grand so. :)

> > > -    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
> > > -           first_table_offset(addr),
> > > +    printk("1ST[0x%lx] = 0x%"PRIpaddr"\n",
> > > +           (unsigned long)first_table_offset(addr),
> > 
> > Eep!  Please either cast to paddr_t or stop using PRIpaddr (likewise
> > below).  I suppose it might be useful to have the nth_*_offset() macros
> > explicitly cast to some suitable small integer type, instead.
> 
> The cast is associated with the %lx, not the %PRIpaddr. I think PRIpaddr
> is right where it is used.

Argh, so it is.  My apologies. 

> Casting in the _offset() might be better -- unsigned long is good?

Sure.  Or vaddr_t.

> > Are we going with ARM64 names for HTTBR &c even on 32-bit?  Maybe 'TTBR'
> > would do in this case.
> 
> For talking about actual registers I want to use ARM64 names in any
> where that isn't 100% 32-bit code. Partly because it makes the accessor
> macros easier (because the 64-bit gas speaks the names natively, without
> cpp magic) and also just because I think consistence is worthwhile,
> nothing would be worse than mixing and matching in common code!

OK.

> For variable names the arm64 names are a bit ugly though (e.g.
> ttbr0_el2), I think ttbr is a good compromise if the context is such
> that its not confusing.

Also good.  My comment was really about the printk, which I think can
happily use 'TTBR' here since it's obvious in this case which one we mean.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:13:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:13: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 1U5xgk-0003pi-N7; Thu, 14 Feb 2013 12:13:18 +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 1U5xgj-0003pY-5K
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:13:17 +0000
Received: from [85.158.139.83:51918] by server-12.bemta-5.messagelabs.com id
	F4/62-20195-CD4DC115; Thu, 14 Feb 2013 12:13:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360843994!29873796!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28328 invoked from network); 14 Feb 2013 12:13:15 -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;
	14 Feb 2013 12:13:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7488066"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:13:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:13:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5xgf-00057l-D5;
	Thu, 14 Feb 2013 12:13:13 +0000
Message-ID: <1360843993.16636.118.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 12:13:13 +0000
In-Reply-To: <511CDD2202000078000BE2F3@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:

> 
> I don't think this patch will fix his problems, which - as described
> yesterday - I'm relatively certain result from the harsh action
> netbk_fatal_tx_err() does.
> 

Yes, having this one only is not enough. It will need to either disable
the vif timer or check vif->netbk != NULL inside timer callback.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:13:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:13: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 1U5xgk-0003pi-N7; Thu, 14 Feb 2013 12:13:18 +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 1U5xgj-0003pY-5K
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:13:17 +0000
Received: from [85.158.139.83:51918] by server-12.bemta-5.messagelabs.com id
	F4/62-20195-CD4DC115; Thu, 14 Feb 2013 12:13:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360843994!29873796!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28328 invoked from network); 14 Feb 2013 12:13:15 -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;
	14 Feb 2013 12:13:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7488066"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:13:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:13:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5xgf-00057l-D5;
	Thu, 14 Feb 2013 12:13:13 +0000
Message-ID: <1360843993.16636.118.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 12:13:13 +0000
In-Reply-To: <511CDD2202000078000BE2F3@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:

> 
> I don't think this patch will fix his problems, which - as described
> yesterday - I'm relatively certain result from the harsh action
> netbk_fatal_tx_err() does.
> 

Yes, having this one only is not enough. It will need to either disable
the vif timer or check vif->netbk != NULL inside timer callback.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:13:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:13: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 1U5xhA-0003rf-51; Thu, 14 Feb 2013 12:13: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 1U5xh8-0003rV-4w
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:13:42 +0000
Received: from [85.158.143.99:60093] by server-1.bemta-4.messagelabs.com id
	C4/A7-08839-5F4DC115; Thu, 14 Feb 2013 12:13:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360844020!22193634!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13952 invoked from network); 14 Feb 2013 12:13:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 12:13:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xh6-000MEq-1r; Thu, 14 Feb 2013 12:13:40 +0000
Date: Thu, 14 Feb 2013 12:13:39 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214121339.GP83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-23-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-23-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 23/45] xen: arm: use vaddr_t more widely.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956589), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 12:13:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:13: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 1U5xhA-0003rf-51; Thu, 14 Feb 2013 12:13: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 1U5xh8-0003rV-4w
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:13:42 +0000
Received: from [85.158.143.99:60093] by server-1.bemta-4.messagelabs.com id
	C4/A7-08839-5F4DC115; Thu, 14 Feb 2013 12:13:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360844020!22193634!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13952 invoked from network); 14 Feb 2013 12:13:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 12:13:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5xh6-000MEq-1r; Thu, 14 Feb 2013 12:13:40 +0000
Date: Thu, 14 Feb 2013 12:13:39 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214121339.GP83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-23-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-23-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 23/45] xen: arm: use vaddr_t more widely.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956589), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 12:21:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:21: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 1U5xoA-0004EO-Ht; Thu, 14 Feb 2013 12:20: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 1U5xo8-0004EJ-RK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:20:57 +0000
Received: from [85.158.143.35:19069] by server-2.bemta-4.messagelabs.com id
	E3/7B-01597-8A6DC115; Thu, 14 Feb 2013 12:20:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360844445!13094078!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17932 invoked from network); 14 Feb 2013 12:20:47 -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;
	14 Feb 2013 12:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7118280"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:20:45 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:20:44 -0500
Message-ID: <511CD69B.6050900@citrix.com>
Date: Thu, 14 Feb 2013 12:20:43 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <510C3AA3.2090508@theshore.net>	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	<51181924.4050500@theshore.net>	<1360583103.16636.29.camel@zion.uk.xensource.com>	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	<511AFFC9.3050404@theshore.net>	<1360779868.16636.92.camel@zion.uk.xensource.com>	<1360780669.16636.94.camel@zion.uk.xensource.com>	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>	<511CB86702000078000BE1C5@nat28.tlf.novell.com>	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
In-Reply-To: <511CDD2202000078000BE2F3@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14/02/13 11:48, Jan Beulich wrote:
>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> 
>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>> will hit this bug soon when shutting down DomU.
> 
> I don't think this patch will fix his problems, which - as described
> yesterday - I'm relatively certain result from the harsh action
> netbk_fatal_tx_err() does.

I can't see anything broken in netbk_fatal_tx_err().

However, a call to netbk_fatal_tx_err() may result in the vif's ref
count going to 1 which means a simutaneous attempt to shutdown the vif
will free the net device.

Netback thread              Xenwatch thread

netbk_fatal_tx_err()        netback_remove()
                              xenvif_disconnect()
                                ...
                                free_netdev()
netbk_tx_err() Oops!

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:21:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:21: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 1U5xoA-0004EO-Ht; Thu, 14 Feb 2013 12:20: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 1U5xo8-0004EJ-RK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:20:57 +0000
Received: from [85.158.143.35:19069] by server-2.bemta-4.messagelabs.com id
	E3/7B-01597-8A6DC115; Thu, 14 Feb 2013 12:20:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360844445!13094078!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17932 invoked from network); 14 Feb 2013 12:20:47 -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;
	14 Feb 2013 12:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7118280"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:20:45 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:20:44 -0500
Message-ID: <511CD69B.6050900@citrix.com>
Date: Thu, 14 Feb 2013 12:20:43 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <510C3AA3.2090508@theshore.net>	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	<51181924.4050500@theshore.net>	<1360583103.16636.29.camel@zion.uk.xensource.com>	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	<511AFFC9.3050404@theshore.net>	<1360779868.16636.92.camel@zion.uk.xensource.com>	<1360780669.16636.94.camel@zion.uk.xensource.com>	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>	<511CB86702000078000BE1C5@nat28.tlf.novell.com>	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
In-Reply-To: <511CDD2202000078000BE2F3@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14/02/13 11:48, Jan Beulich wrote:
>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> 
>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>> will hit this bug soon when shutting down DomU.
> 
> I don't think this patch will fix his problems, which - as described
> yesterday - I'm relatively certain result from the harsh action
> netbk_fatal_tx_err() does.

I can't see anything broken in netbk_fatal_tx_err().

However, a call to netbk_fatal_tx_err() may result in the vif's ref
count going to 1 which means a simutaneous attempt to shutdown the vif
will free the net device.

Netback thread              Xenwatch thread

netbk_fatal_tx_err()        netback_remove()
                              xenvif_disconnect()
                                ...
                                free_netdev()
netbk_tx_err() Oops!

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:29:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:29: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 1U5xwc-0004Sy-Iv; Thu, 14 Feb 2013 12:29:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5xwa-0004St-R3
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:29:41 +0000
Received: from [85.158.138.51:10016] by server-3.bemta-3.messagelabs.com id
	41/04-31070-FA8DC115; Thu, 14 Feb 2013 12:29:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360844972!19465759!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6097 invoked from network); 14 Feb 2013 12:29: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;
	14 Feb 2013 12:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7118854"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:29:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:29:11 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5xw6-0005OI-SN;
	Thu, 14 Feb 2013 12:29:10 +0000
Message-ID: <1360844950.16636.123.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 12:29:10 +0000
In-Reply-To: <511CD69B.6050900@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
> On 14/02/13 11:48, Jan Beulich wrote:
> >>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> > 
> >> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> >> will hit this bug soon when shutting down DomU.
> > 
> > I don't think this patch will fix his problems, which - as described
> > yesterday - I'm relatively certain result from the harsh action
> > netbk_fatal_tx_err() does.
> 
> I can't see anything broken in netbk_fatal_tx_err().
> 
> However, a call to netbk_fatal_tx_err() may result in the vif's ref
> count going to 1 which means a simutaneous attempt to shutdown the vif
> will free the net device.

> Netback thread              Xenwatch thread
> 
> netbk_fatal_tx_err()        netback_remove()
>                               xenvif_disconnect()
>                                 ...
>                                 free_netdev()
> netbk_tx_err() Oops!
> 

This is not a problem. Reading comments and code of the commit,
netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
is not handled though) which should make sure it will never get
scheduled again, so in practice it will never hit netbk_tx_err.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:29:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:29: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 1U5xwc-0004Sy-Iv; Thu, 14 Feb 2013 12:29:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5xwa-0004St-R3
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:29:41 +0000
Received: from [85.158.138.51:10016] by server-3.bemta-3.messagelabs.com id
	41/04-31070-FA8DC115; Thu, 14 Feb 2013 12:29:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360844972!19465759!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6097 invoked from network); 14 Feb 2013 12:29: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;
	14 Feb 2013 12:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7118854"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:29:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:29:11 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5xw6-0005OI-SN;
	Thu, 14 Feb 2013 12:29:10 +0000
Message-ID: <1360844950.16636.123.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 12:29:10 +0000
In-Reply-To: <511CD69B.6050900@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
> On 14/02/13 11:48, Jan Beulich wrote:
> >>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> > 
> >> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> >> will hit this bug soon when shutting down DomU.
> > 
> > I don't think this patch will fix his problems, which - as described
> > yesterday - I'm relatively certain result from the harsh action
> > netbk_fatal_tx_err() does.
> 
> I can't see anything broken in netbk_fatal_tx_err().
> 
> However, a call to netbk_fatal_tx_err() may result in the vif's ref
> count going to 1 which means a simutaneous attempt to shutdown the vif
> will free the net device.

> Netback thread              Xenwatch thread
> 
> netbk_fatal_tx_err()        netback_remove()
>                               xenvif_disconnect()
>                                 ...
>                                 free_netdev()
> netbk_tx_err() Oops!
> 

This is not a problem. Reading comments and code of the commit,
netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
is not handled though) which should make sure it will never get
scheduled again, so in practice it will never hit netbk_tx_err.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:33:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:33: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 1U5xzh-0004d1-6I; Thu, 14 Feb 2013 12:32:53 +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 1U5xzf-0004cr-U8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:32:52 +0000
Received: from [85.158.139.211:23620] by server-4.bemta-5.messagelabs.com id
	05/58-29496-379DC115; Thu, 14 Feb 2013 12:32:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360845166!19746812!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9191 invoked from network); 14 Feb 2013 12:32:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 12:32:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 12:32:45 +0000
Message-Id: <511CE7B902000078000BE35B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 12:33:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
In-Reply-To: <1360843993.16636.118.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
>> I don't think this patch will fix his problems, which - as described
>> yesterday - I'm relatively certain result from the harsh action
>> netbk_fatal_tx_err() does.
> 
> Yes, having this one only is not enough. It will need to either disable
> the vif timer or check vif->netbk != NULL inside timer callback.

I continue to be unclear what timer you refer to.

If we keep the carrier-off in fatal_tx_err, then _all_
asynchronously callable interfaces need to check whether the
vif -> netbk association went away. But, especially in the
context of using tasklets instead of kthreads, I meanwhile
think that simply setting a flag (along with turning off the IRQ)
would be better (and keep the turning off of the carrier the way
it had been done before. The flag would basically need checking
anywhere we look at the shared ring (which ought to be very
few places), and perhaps should also cause xenvif_schedulable()
to return false.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:33:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:33: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 1U5xzh-0004d1-6I; Thu, 14 Feb 2013 12:32:53 +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 1U5xzf-0004cr-U8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:32:52 +0000
Received: from [85.158.139.211:23620] by server-4.bemta-5.messagelabs.com id
	05/58-29496-379DC115; Thu, 14 Feb 2013 12:32:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360845166!19746812!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9191 invoked from network); 14 Feb 2013 12:32:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 12:32:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 12:32:45 +0000
Message-Id: <511CE7B902000078000BE35B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 12:33:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
In-Reply-To: <1360843993.16636.118.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
>> I don't think this patch will fix his problems, which - as described
>> yesterday - I'm relatively certain result from the harsh action
>> netbk_fatal_tx_err() does.
> 
> Yes, having this one only is not enough. It will need to either disable
> the vif timer or check vif->netbk != NULL inside timer callback.

I continue to be unclear what timer you refer to.

If we keep the carrier-off in fatal_tx_err, then _all_
asynchronously callable interfaces need to check whether the
vif -> netbk association went away. But, especially in the
context of using tasklets instead of kthreads, I meanwhile
think that simply setting a flag (along with turning off the IRQ)
would be better (and keep the turning off of the carrier the way
it had been done before. The flag would basically need checking
anywhere we look at the shared ring (which ought to be very
few places), and perhaps should also cause xenvif_schedulable()
to return false.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:37:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:37: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 1U5y47-0004oY-TF; Thu, 14 Feb 2013 12:37:27 +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 1U5y46-0004oR-KW
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:37:26 +0000
Received: from [85.158.143.35:30385] by server-2.bemta-4.messagelabs.com id
	81/B3-01597-58ADC115; Thu, 14 Feb 2013 12:37:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360845426!3936197!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9644 invoked from network); 14 Feb 2013 12:37:07 -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;
	14 Feb 2013 12:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119507"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:37:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:37:05 -0500
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 1U5y3l-0005Wc-1Y; Thu, 14 Feb 2013 12:37:05 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U5y3k-0004Qx-PJ;
	Thu, 14 Feb 2013 12:37:04 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
Message-ID: <4b01cc2c2c1f4836e7fb.1360845424@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 12:37:04 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: comment the use of second_linear_offset()
	in mm.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 Tim Deegan <tim@xen.org>
# Date 1360845361 0
# Node ID 4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
# Parent  6ad763d9f964859d045380baef43edf18399bdb0
arm: comment the use of second_linear_offset() in mm.c

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 6ad763d9f964 -r 4b01cc2c2c1f xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 14 11:07:07 2013 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 14 12:36:01 2013 +0000
@@ -41,6 +41,9 @@ struct domain *dom_xen, *dom_io, *dom_co
 
 /* Static start-of-day pagetables that we use before the allocators are up */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+/* N.B. The second-level table is 4 contiguous pages long, and covers
+ * all addresses from 0 to 0xffffffff.  Offsets into it are calculated
+ * with second_linear_offset(), not second_table_offset(). */
 lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
 lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:37:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:37: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 1U5y47-0004oY-TF; Thu, 14 Feb 2013 12:37:27 +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 1U5y46-0004oR-KW
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:37:26 +0000
Received: from [85.158.143.35:30385] by server-2.bemta-4.messagelabs.com id
	81/B3-01597-58ADC115; Thu, 14 Feb 2013 12:37:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360845426!3936197!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9644 invoked from network); 14 Feb 2013 12:37:07 -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;
	14 Feb 2013 12:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119507"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:37:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:37:05 -0500
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 1U5y3l-0005Wc-1Y; Thu, 14 Feb 2013 12:37:05 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U5y3k-0004Qx-PJ;
	Thu, 14 Feb 2013 12:37:04 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
Message-ID: <4b01cc2c2c1f4836e7fb.1360845424@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 12:37:04 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] arm: comment the use of second_linear_offset()
	in mm.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 Tim Deegan <tim@xen.org>
# Date 1360845361 0
# Node ID 4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
# Parent  6ad763d9f964859d045380baef43edf18399bdb0
arm: comment the use of second_linear_offset() in mm.c

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 6ad763d9f964 -r 4b01cc2c2c1f xen/arch/arm/mm.c
--- a/xen/arch/arm/mm.c	Thu Feb 14 11:07:07 2013 +0000
+++ b/xen/arch/arm/mm.c	Thu Feb 14 12:36:01 2013 +0000
@@ -41,6 +41,9 @@ struct domain *dom_xen, *dom_io, *dom_co
 
 /* Static start-of-day pagetables that we use before the allocators are up */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+/* N.B. The second-level table is 4 contiguous pages long, and covers
+ * all addresses from 0 to 0xffffffff.  Offsets into it are calculated
+ * with second_linear_offset(), not second_table_offset(). */
 lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
 lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:38:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y4i-0004qv-AW; Thu, 14 Feb 2013 12:38:04 +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 1U5y4f-0004qf-QP
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:38:02 +0000
Received: from [85.158.138.51:22085] by server-5.bemta-3.messagelabs.com id
	E1/C5-04457-9AADC115; Thu, 14 Feb 2013 12:38:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360845477!21210354!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10946 invoked from network); 14 Feb 2013 12:37:58 -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; 14 Feb 2013 12:37:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5y4a-000MI1-6j; Thu, 14 Feb 2013 12:37:56 +0000
Date: Thu, 14 Feb 2013 12:37:56 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214123756.GQ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-24-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-24-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 24/45] xen: arm: add register_t type,
	native register size for the 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

At 15:56 +0000 on 23 Jan (1358956590), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

This is mostly a matter of coding taste, so I'd like Stefano's ack/nack
here as well.

Tim.

> ---
> I can't decide between this, unsigned long or just using vaddr_t
> here.
> ---
>  xen/arch/arm/domain_build.c |    2 +-
>  xen/arch/arm/smpboot.c      |    2 +-
>  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
>  xen/arch/arm/vgic.c         |   18 ++++++++--------
>  xen/arch/arm/vpl011.c       |    6 ++--
>  xen/arch/arm/vtimer.c       |    6 ++--
>  xen/include/asm-arm/regs.h  |    2 +-
>  xen/include/asm-arm/types.h |    4 +++
>  8 files changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..30d014a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
>  
>  static void dtb_load(struct kernel_info *kinfo)
>  {
> -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
>  
>      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
>      xfree(kinfo->fdt);
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 8956ead..5234d14 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -143,7 +143,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
>      set_processor_id(cpuid);
>  
>      /* Setup Hyp vector base */
> -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
>  
>      mmu_init_secondary_cpu();
>      enable_vfp();
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 0a1c483..b9282b0 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -73,7 +73,7 @@ static void print_xen_info(void)
>             debug, print_tainted(taint_str));
>  }
>  
> -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
>  {
>      BUG_ON( !guest_mode(regs) );
>  
> @@ -86,20 +86,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
>  
>      switch ( reg ) {
>      case 0 ... 7: /* Unbanked registers */
> -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
>          return &regs->r0 + reg;
>      case 8 ... 12: /* Register banked in FIQ mode */
> -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
>          if ( fiq_mode(regs) )
>              return &regs->r8_fiq + reg - 8;
>          else
>              return &regs->r8 + reg - 8;
>      case 13 ... 14: /* Banked SP + LR registers */
> -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
>          switch ( regs->cpsr & PSR_MODE_MASK )
>          {
>          case PSR_MODE_USR:
> @@ -320,11 +320,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
>      printk("GUEST STACK GOES HERE\n");
>  }
>  
> -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
>  
>  static void show_trace(struct cpu_user_regs *regs)
>  {
> -    uint32_t *frame, next, addr, low, high;
> +    register_t *frame, next, addr, low, high;
>  
>      printk("Xen call trace:\n   ");
>  
> @@ -332,7 +332,7 @@ static void show_trace(struct cpu_user_regs *regs)
>      print_symbol(" %s\n   ", regs->pc);
>  
>      /* Bounds for range of valid frame pointer. */
> -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
>      high = (low & ~(STACK_SIZE - 1)) +
>          (STACK_SIZE - sizeof(struct cpu_info));
>  
> @@ -361,7 +361,7 @@ static void show_trace(struct cpu_user_regs *regs)
>              break;
>          {
>              /* Ordinary stack frame. */
> -            frame = (uint32_t *)next;
> +            frame = (register_t *)next;
>              next  = frame[-1];
>              addr  = frame[0];
>          }
> @@ -369,7 +369,7 @@ static void show_trace(struct cpu_user_regs *regs)
>          printk("[<%p>]", _p(addr));
>          print_symbol(" %s\n   ", addr);
>  
> -        low = (uint32_t)&frame[1];
> +        low = (register_t)&frame[1];
>      }
>  
>      printk("\n");
> @@ -377,7 +377,7 @@ static void show_trace(struct cpu_user_regs *regs)
>  
>  void show_stack(struct cpu_user_regs *regs)
>  {
> -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
>      int i;
>  
>      if ( guest_mode(regs) )
> @@ -491,20 +491,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
>  
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  {
> -    uint32_t reg, *r;
> +    register_t *r;
> +    uint32_t reg;
>      uint32_t domid = current->domain->domain_id;
>      switch ( code ) {
>      case 0xe0 ... 0xef:
>          reg = code - 0xe0;
>          r = select_user_reg(regs, reg);
> -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
>                 domid, reg, *r, regs->pc);
>          break;
>      case 0xfd:
> -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
>          break;
>      case 0xfe:
> -        printk("%c", (char)(regs->r0 & 0xff));
> +        r = select_user_reg(regs, 0);
> +        printk("%c", (char)(*r & 0xff));
>          break;
>      case 0xff:
>          printk("DOM%d: DEBUG\n", domid);
> @@ -566,7 +568,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>                         union hsr hsr)
>  {
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
>  
>      if ( !cp32.ccvalid ) {
>          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> @@ -612,7 +614,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
>                 cp32.read ? "mrc" : "mcr",
>                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
>          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> @@ -642,7 +644,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
>                 cp64.read ? "mrrc" : "mcrr",
>                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
>          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 39b9775..57147d5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  
>      case GICD_ISPENDR ... GICD_ISPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
>          return 0;
>  
>      case GICD_ICPENDR ... GICD_ICPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
>          return 0;
>  
> @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  
>      case GICD_SGIR:
>          if ( dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
>                 *r, gicd_reg - GICD_ICFGR);
>          return 0;
>  
>      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
>          return 0;
>  
>      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
>          return 0;
>  
> @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>          goto write_ignore;
>  
>      default:
> -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          return 0;
>      }
>  
>  bad_width:
> -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
>             dabt.size, dabt.reg, *r, offset);
>      domain_crash_synchronous();
>      return 0;
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 7dcee90..db5094e 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
>  
>      switch ( offset )
> @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
>  
>      switch ( offset )
> @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>          /* Silently ignore */
>          return 1;
>      default:
> -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          domain_crash_synchronous();
>      }
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 3616879..288c27e 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -93,7 +93,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
>      s_time_t now;
>  
>      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> @@ -145,8 +145,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp64 cp64 = hsr.cp64;
> -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
>      uint64_t ticks;
>      s_time_t now;
>  
> diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> index 7486944..a723f92 100644
> --- a/xen/include/asm-arm/regs.h
> +++ b/xen/include/asm-arm/regs.h
> @@ -34,7 +34,7 @@
>   * Returns a pointer to the given register value in regs, taking the
>   * processor mode (CPSR) into account.
>   */
> -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
>  
>  #endif /* __ARM_REGS_H__ */
>  /*
> diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> index d3e16d8..9ca32f1 100644
> --- a/xen/include/asm-arm/types.h
> +++ b/xen/include/asm-arm/types.h
> @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0ULL)
>  #define PRIpaddr "016llx"
> +typedef u32 register_t;
> +#define PRIregister "x"
>  #elif defined (CONFIG_ARM_64)
>  typedef signed long s64;
>  typedef unsigned long u64;
> @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0UL)
>  #define PRIpaddr "016lx"
> +typedef u64 register_t;
> +#define PRIregister "lx"
>  #endif
>  
>  typedef unsigned long size_t;
> -- 
> 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 Thu Feb 14 12:38:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y4i-0004qv-AW; Thu, 14 Feb 2013 12:38:04 +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 1U5y4f-0004qf-QP
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:38:02 +0000
Received: from [85.158.138.51:22085] by server-5.bemta-3.messagelabs.com id
	E1/C5-04457-9AADC115; Thu, 14 Feb 2013 12:38:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360845477!21210354!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10946 invoked from network); 14 Feb 2013 12:37:58 -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; 14 Feb 2013 12:37:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5y4a-000MI1-6j; Thu, 14 Feb 2013 12:37:56 +0000
Date: Thu, 14 Feb 2013 12:37:56 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214123756.GQ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-24-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-24-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 24/45] xen: arm: add register_t type,
	native register size for the 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

At 15:56 +0000 on 23 Jan (1358956590), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

This is mostly a matter of coding taste, so I'd like Stefano's ack/nack
here as well.

Tim.

> ---
> I can't decide between this, unsigned long or just using vaddr_t
> here.
> ---
>  xen/arch/arm/domain_build.c |    2 +-
>  xen/arch/arm/smpboot.c      |    2 +-
>  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
>  xen/arch/arm/vgic.c         |   18 ++++++++--------
>  xen/arch/arm/vpl011.c       |    6 ++--
>  xen/arch/arm/vtimer.c       |    6 ++--
>  xen/include/asm-arm/regs.h  |    2 +-
>  xen/include/asm-arm/types.h |    4 +++
>  8 files changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..30d014a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
>  
>  static void dtb_load(struct kernel_info *kinfo)
>  {
> -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
>  
>      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
>      xfree(kinfo->fdt);
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 8956ead..5234d14 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -143,7 +143,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
>      set_processor_id(cpuid);
>  
>      /* Setup Hyp vector base */
> -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
>  
>      mmu_init_secondary_cpu();
>      enable_vfp();
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 0a1c483..b9282b0 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -73,7 +73,7 @@ static void print_xen_info(void)
>             debug, print_tainted(taint_str));
>  }
>  
> -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
>  {
>      BUG_ON( !guest_mode(regs) );
>  
> @@ -86,20 +86,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
>  
>      switch ( reg ) {
>      case 0 ... 7: /* Unbanked registers */
> -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
>          return &regs->r0 + reg;
>      case 8 ... 12: /* Register banked in FIQ mode */
> -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
>          if ( fiq_mode(regs) )
>              return &regs->r8_fiq + reg - 8;
>          else
>              return &regs->r8 + reg - 8;
>      case 13 ... 14: /* Banked SP + LR registers */
> -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
>          switch ( regs->cpsr & PSR_MODE_MASK )
>          {
>          case PSR_MODE_USR:
> @@ -320,11 +320,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
>      printk("GUEST STACK GOES HERE\n");
>  }
>  
> -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
>  
>  static void show_trace(struct cpu_user_regs *regs)
>  {
> -    uint32_t *frame, next, addr, low, high;
> +    register_t *frame, next, addr, low, high;
>  
>      printk("Xen call trace:\n   ");
>  
> @@ -332,7 +332,7 @@ static void show_trace(struct cpu_user_regs *regs)
>      print_symbol(" %s\n   ", regs->pc);
>  
>      /* Bounds for range of valid frame pointer. */
> -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
>      high = (low & ~(STACK_SIZE - 1)) +
>          (STACK_SIZE - sizeof(struct cpu_info));
>  
> @@ -361,7 +361,7 @@ static void show_trace(struct cpu_user_regs *regs)
>              break;
>          {
>              /* Ordinary stack frame. */
> -            frame = (uint32_t *)next;
> +            frame = (register_t *)next;
>              next  = frame[-1];
>              addr  = frame[0];
>          }
> @@ -369,7 +369,7 @@ static void show_trace(struct cpu_user_regs *regs)
>          printk("[<%p>]", _p(addr));
>          print_symbol(" %s\n   ", addr);
>  
> -        low = (uint32_t)&frame[1];
> +        low = (register_t)&frame[1];
>      }
>  
>      printk("\n");
> @@ -377,7 +377,7 @@ static void show_trace(struct cpu_user_regs *regs)
>  
>  void show_stack(struct cpu_user_regs *regs)
>  {
> -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
>      int i;
>  
>      if ( guest_mode(regs) )
> @@ -491,20 +491,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
>  
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  {
> -    uint32_t reg, *r;
> +    register_t *r;
> +    uint32_t reg;
>      uint32_t domid = current->domain->domain_id;
>      switch ( code ) {
>      case 0xe0 ... 0xef:
>          reg = code - 0xe0;
>          r = select_user_reg(regs, reg);
> -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
>                 domid, reg, *r, regs->pc);
>          break;
>      case 0xfd:
> -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
>          break;
>      case 0xfe:
> -        printk("%c", (char)(regs->r0 & 0xff));
> +        r = select_user_reg(regs, 0);
> +        printk("%c", (char)(*r & 0xff));
>          break;
>      case 0xff:
>          printk("DOM%d: DEBUG\n", domid);
> @@ -566,7 +568,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>                         union hsr hsr)
>  {
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
>  
>      if ( !cp32.ccvalid ) {
>          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> @@ -612,7 +614,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
>                 cp32.read ? "mrc" : "mcr",
>                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
>          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> @@ -642,7 +644,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
>                 cp64.read ? "mrrc" : "mcrr",
>                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
>          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 39b9775..57147d5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  
>      case GICD_ISPENDR ... GICD_ISPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
>          return 0;
>  
>      case GICD_ICPENDR ... GICD_ICPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
>          return 0;
>  
> @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  
>      case GICD_SGIR:
>          if ( dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
>                 *r, gicd_reg - GICD_ICFGR);
>          return 0;
>  
>      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
>          return 0;
>  
>      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
>          return 0;
>  
> @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>          goto write_ignore;
>  
>      default:
> -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          return 0;
>      }
>  
>  bad_width:
> -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
>             dabt.size, dabt.reg, *r, offset);
>      domain_crash_synchronous();
>      return 0;
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 7dcee90..db5094e 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
>  
>      switch ( offset )
> @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
>  
>      switch ( offset )
> @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>          /* Silently ignore */
>          return 1;
>      default:
> -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          domain_crash_synchronous();
>      }
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 3616879..288c27e 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -93,7 +93,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
>      s_time_t now;
>  
>      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> @@ -145,8 +145,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp64 cp64 = hsr.cp64;
> -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
>      uint64_t ticks;
>      s_time_t now;
>  
> diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> index 7486944..a723f92 100644
> --- a/xen/include/asm-arm/regs.h
> +++ b/xen/include/asm-arm/regs.h
> @@ -34,7 +34,7 @@
>   * Returns a pointer to the given register value in regs, taking the
>   * processor mode (CPSR) into account.
>   */
> -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
>  
>  #endif /* __ARM_REGS_H__ */
>  /*
> diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> index d3e16d8..9ca32f1 100644
> --- a/xen/include/asm-arm/types.h
> +++ b/xen/include/asm-arm/types.h
> @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0ULL)
>  #define PRIpaddr "016llx"
> +typedef u32 register_t;
> +#define PRIregister "x"
>  #elif defined (CONFIG_ARM_64)
>  typedef signed long s64;
>  typedef unsigned long u64;
> @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0UL)
>  #define PRIpaddr "016lx"
> +typedef u64 register_t;
> +#define PRIregister "lx"
>  #endif
>  
>  typedef unsigned long size_t;
> -- 
> 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 Thu Feb 14 12:38:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:38: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 1U5y5A-0004ul-Sx; Thu, 14 Feb 2013 12:38: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 1U5y59-0004uS-QQ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:38:32 +0000
Received: from [193.109.254.147:63822] by server-3.bemta-14.messagelabs.com id
	08/36-22141-7CADC115; Thu, 14 Feb 2013 12:38:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360845503!8795399!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 14 Feb 2013 12:38:23 -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; 14 Feb 2013 12:38:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 12:38:23 +0000
Message-Id: <511CE90802000078000BE36B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 12:39:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
In-Reply-To: <511CD69B.6050900@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 13:20, David Vrabel <david.vrabel@citrix.com> wrote:
> On 14/02/13 11:48, Jan Beulich wrote:
>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
>> 
>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>>> will hit this bug soon when shutting down DomU.
>> 
>> I don't think this patch will fix his problems, which - as described
>> yesterday - I'm relatively certain result from the harsh action
>> netbk_fatal_tx_err() does.
> 
> I can't see anything broken in netbk_fatal_tx_err().

The main problem I'm seeing is the unexpected removal of the
vif->netbk association. There are some checks for this, but not
everywhere.

> However, a call to netbk_fatal_tx_err() may result in the vif's ref
> count going to 1 which means a simutaneous attempt to shutdown the vif
> will free the net device.
> 
> Netback thread              Xenwatch thread
> 
> netbk_fatal_tx_err()        netback_remove()
>                               xenvif_disconnect()
>                                 ...
>                                 free_netdev()
> netbk_tx_err() Oops!

Right. One more argument for not doing it there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:38:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:38: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 1U5y5A-0004ul-Sx; Thu, 14 Feb 2013 12:38: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 1U5y59-0004uS-QQ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:38:32 +0000
Received: from [193.109.254.147:63822] by server-3.bemta-14.messagelabs.com id
	08/36-22141-7CADC115; Thu, 14 Feb 2013 12:38:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360845503!8795399!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 14 Feb 2013 12:38:23 -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; 14 Feb 2013 12:38:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 12:38:23 +0000
Message-Id: <511CE90802000078000BE36B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 12:39:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
In-Reply-To: <511CD69B.6050900@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 13:20, David Vrabel <david.vrabel@citrix.com> wrote:
> On 14/02/13 11:48, Jan Beulich wrote:
>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
>> 
>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>>> will hit this bug soon when shutting down DomU.
>> 
>> I don't think this patch will fix his problems, which - as described
>> yesterday - I'm relatively certain result from the harsh action
>> netbk_fatal_tx_err() does.
> 
> I can't see anything broken in netbk_fatal_tx_err().

The main problem I'm seeing is the unexpected removal of the
vif->netbk association. There are some checks for this, but not
everywhere.

> However, a call to netbk_fatal_tx_err() may result in the vif's ref
> count going to 1 which means a simutaneous attempt to shutdown the vif
> will free the net device.
> 
> Netback thread              Xenwatch thread
> 
> netbk_fatal_tx_err()        netback_remove()
>                               xenvif_disconnect()
>                                 ...
>                                 free_netdev()
> netbk_tx_err() Oops!

Right. One more argument for not doing it there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:39:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:39: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 1U5y5m-00051V-AT; Thu, 14 Feb 2013 12:39: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 1U5y5l-00051J-8K
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:09 +0000
Received: from [85.158.139.83:3015] by server-6.bemta-5.messagelabs.com id
	F1/5B-01489-CEADC115; Thu, 14 Feb 2013 12:39:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360845536!29879267!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4590 invoked from network); 14 Feb 2013 12:38:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1459176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 12:38: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.297.1;
	Thu, 14 Feb 2013 12:38:56 +0000
Message-ID: <1360845534.20449.360.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 14 Feb 2013 12:38:54 +0000
In-Reply-To: <1360844950.16636.123.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
	<1360844950.16636.123.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:29 +0000, Wei Liu wrote:
> On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
> > On 14/02/13 11:48, Jan Beulich wrote:
> > >>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> > > 
> > >> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> > >> will hit this bug soon when shutting down DomU.
> > > 
> > > I don't think this patch will fix his problems, which - as described
> > > yesterday - I'm relatively certain result from the harsh action
> > > netbk_fatal_tx_err() does.
> > 
> > I can't see anything broken in netbk_fatal_tx_err().
> > 
> > However, a call to netbk_fatal_tx_err() may result in the vif's ref
> > count going to 1 which means a simutaneous attempt to shutdown the vif
> > will free the net device.
> 
> > Netback thread              Xenwatch thread
> > 
> > netbk_fatal_tx_err()        netback_remove()
> >                               xenvif_disconnect()
> >                                 ...
> >                                 free_netdev()
> > netbk_tx_err() Oops!
> > 
> 
> This is not a problem. Reading comments and code of the commit,
> netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> is not handled though) which should make sure it will never get
> scheduled again, so in practice it will never hit netbk_tx_err.

That was certainly the intention!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:39:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:39: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 1U5y5m-00051V-AT; Thu, 14 Feb 2013 12:39: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 1U5y5l-00051J-8K
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:09 +0000
Received: from [85.158.139.83:3015] by server-6.bemta-5.messagelabs.com id
	F1/5B-01489-CEADC115; Thu, 14 Feb 2013 12:39:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360845536!29879267!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4590 invoked from network); 14 Feb 2013 12:38:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1459176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 12:38: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.297.1;
	Thu, 14 Feb 2013 12:38:56 +0000
Message-ID: <1360845534.20449.360.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 14 Feb 2013 12:38:54 +0000
In-Reply-To: <1360844950.16636.123.camel@zion.uk.xensource.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
	<1360844950.16636.123.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:29 +0000, Wei Liu wrote:
> On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
> > On 14/02/13 11:48, Jan Beulich wrote:
> > >>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> > > 
> > >> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> > >> will hit this bug soon when shutting down DomU.
> > > 
> > > I don't think this patch will fix his problems, which - as described
> > > yesterday - I'm relatively certain result from the harsh action
> > > netbk_fatal_tx_err() does.
> > 
> > I can't see anything broken in netbk_fatal_tx_err().
> > 
> > However, a call to netbk_fatal_tx_err() may result in the vif's ref
> > count going to 1 which means a simutaneous attempt to shutdown the vif
> > will free the net device.
> 
> > Netback thread              Xenwatch thread
> > 
> > netbk_fatal_tx_err()        netback_remove()
> >                               xenvif_disconnect()
> >                                 ...
> >                                 free_netdev()
> > netbk_tx_err() Oops!
> > 
> 
> This is not a problem. Reading comments and code of the commit,
> netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> is not handled though) which should make sure it will never get
> scheduled again, so in practice it will never hit netbk_tx_err.

That was certainly the intention!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:39:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:39: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 1U5y6L-00057b-Ov; Thu, 14 Feb 2013 12:39:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6K-00057E-3p
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:44 +0000
Received: from [85.158.137.99:60528] by server-15.bemta-3.messagelabs.com id
	4F/54-25405-F0BDC115; Thu, 14 Feb 2013 12:39:43 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360845581!18020974!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16491 invoked from network); 14 Feb 2013 12:39:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490405"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-5W;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:16 +0000
Message-ID: <1360845437-11497-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/5] gcov: Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  152 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index 96a7a5d..71786ca 100644
--- a/.gitignore
+++ b/.gitignore
@@ -229,6 +229,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index a4466d2..6b432f7 100644
--- a/.hgignore
+++ b/.hgignore
@@ -224,6 +224,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..6645a30
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,152 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, struct xen_sysctl *sys, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+
+    memset(sys, 0, sizeof(*sys));
+    sys->cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys->u.coverage_op;
+    cov->cmd = op;
+    cov->u.raw_info.p = ptr;
+
+    return xc_sysctl(gcov_xch, sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    struct xen_sysctl sys;
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* get total length */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, &sys, NULL) < 0 )
+        err(1, "getting total length");
+    total_len = sys.u.coverage_op.u.total_size;
+    fprintf(stderr, "returned %u bytes\n", (unsigned) total_len);
+
+    /* safe check */
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* allocate */
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, &sys, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    struct xen_sysctl sys;
+
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, &sys, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(exit_code);
+}
+
+int main(int argc, char **argv)
+{
+    int opt;
+
+    while ((opt = getopt(argc, argv, "h")) != -1) {
+        switch (opt) {
+        case 'h':
+            usage(0);
+            break;
+        default:
+            usage(1);
+        }
+    }
+
+    argv += optind;
+    argc -= optind;
+    if (argc <= 0)
+        usage(1);
+
+    gcov_init();
+
+    if ( strcmp(argv[0], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[0], "read") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 0);
+    else if ( strcmp(argv[0], "read-reset") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 1);
+    else
+        usage(1);
+
+    return 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 Thu Feb 14 12:39:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:39: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 1U5y6L-00057b-Ov; Thu, 14 Feb 2013 12:39:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6K-00057E-3p
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:44 +0000
Received: from [85.158.137.99:60528] by server-15.bemta-3.messagelabs.com id
	4F/54-25405-F0BDC115; Thu, 14 Feb 2013 12:39:43 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360845581!18020974!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16491 invoked from network); 14 Feb 2013 12:39:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490405"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-5W;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:16 +0000
Message-ID: <1360845437-11497-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/5] gcov: Add small utility to deal with test
	coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  152 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index 96a7a5d..71786ca 100644
--- a/.gitignore
+++ b/.gitignore
@@ -229,6 +229,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index a4466d2..6b432f7 100644
--- a/.hgignore
+++ b/.hgignore
@@ -224,6 +224,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..6645a30
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,152 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, struct xen_sysctl *sys, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+
+    memset(sys, 0, sizeof(*sys));
+    sys->cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys->u.coverage_op;
+    cov->cmd = op;
+    cov->u.raw_info.p = ptr;
+
+    return xc_sysctl(gcov_xch, sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    struct xen_sysctl sys;
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* get total length */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, &sys, NULL) < 0 )
+        err(1, "getting total length");
+    total_len = sys.u.coverage_op.u.total_size;
+    fprintf(stderr, "returned %u bytes\n", (unsigned) total_len);
+
+    /* safe check */
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* allocate */
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, &sys, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    struct xen_sysctl sys;
+
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, &sys, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(exit_code);
+}
+
+int main(int argc, char **argv)
+{
+    int opt;
+
+    while ((opt = getopt(argc, argv, "h")) != -1) {
+        switch (opt) {
+        case 'h':
+            usage(0);
+            break;
+        default:
+            usage(1);
+        }
+    }
+
+    argv += optind;
+    argc -= optind;
+    if (argc <= 0)
+        usage(1);
+
+    gcov_init();
+
+    if ( strcmp(argv[0], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[0], "read") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 0);
+    else if ( strcmp(argv[0], "read-reset") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 1);
+    else
+        usage(1);
+
+    return 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 Thu Feb 14 12:40:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y6W-0005AQ-JO; Thu, 14 Feb 2013 12:39:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6V-00059k-Dl
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:55 +0000
Received: from [85.158.137.99:61264] by server-11.bemta-3.messagelabs.com id
	BB/7E-10249-A1BDC115; Thu, 14 Feb 2013 12:39:54 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360845591!20610798!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13877 invoked from network); 14 Feb 2013 12:39:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:39:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119690"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-1S;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:13 +0000
Message-ID: <1360845437-11497-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2b9dbe3..2979bcc 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1361,6 +1361,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 31e1117..74b34eb 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -127,4 +127,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 14 12:40:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y6W-0005AQ-JO; Thu, 14 Feb 2013 12:39:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6V-00059k-Dl
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:55 +0000
Received: from [85.158.137.99:61264] by server-11.bemta-3.messagelabs.com id
	BB/7E-10249-A1BDC115; Thu, 14 Feb 2013 12:39:54 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360845591!20610798!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13877 invoked from network); 14 Feb 2013 12:39:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:39:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119690"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-1S;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:13 +0000
Message-ID: <1360845437-11497-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..4b98dd8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -445,6 +445,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2b9dbe3..2979bcc 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1361,6 +1361,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 31e1117..74b34eb 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -127,4 +127,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 14 12:40:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y6W-0005AE-5r; Thu, 14 Feb 2013 12:39:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6U-00059K-Mo
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:54 +0000
Received: from [85.158.137.99:61228] by server-9.bemta-3.messagelabs.com id
	B7/6B-09484-91BDC115; Thu, 14 Feb 2013 12:39:53 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360845591!20610798!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13836 invoked from network); 14 Feb 2013 12:39:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:39:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119689"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6C-0005Z3-W1;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:12 +0000
Message-ID: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v9] gcov: Coverage 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

Updated set of patches for coverage.

Changes:
- return total size inline instead of using a pointer to it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:40:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y6W-0005AE-5r; Thu, 14 Feb 2013 12:39:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6U-00059K-Mo
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:39:54 +0000
Received: from [85.158.137.99:61228] by server-9.bemta-3.messagelabs.com id
	B7/6B-09484-91BDC115; Thu, 14 Feb 2013 12:39:53 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360845591!20610798!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13836 invoked from network); 14 Feb 2013 12:39:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 12:39:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119689"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6C-0005Z3-W1;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:12 +0000
Message-ID: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v9] gcov: Coverage 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

Updated set of patches for coverage.

Changes:
- return total size inline instead of using a pointer to it


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:40:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y6l-0005F2-1F; Thu, 14 Feb 2013 12:40:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5y6j-0005EM-LH
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:09 +0000
Received: from [85.158.138.51:37489] by server-5.bemta-3.messagelabs.com id
	35/59-04457-82BDC115; Thu, 14 Feb 2013 12:40:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360845606!23510931!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10583 invoked from network); 14 Feb 2013 12:40:07 -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;
	14 Feb 2013 12:40:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119760"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:40:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:40:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5y6f-0005a9-DD;
	Thu, 14 Feb 2013 12:40:05 +0000
Message-ID: <1360845605.16636.128.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 12:40:05 +0000
In-Reply-To: <511CE7B902000078000BE35B@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:33 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
> >> I don't think this patch will fix his problems, which - as described
> >> yesterday - I'm relatively certain result from the harsh action
> >> netbk_fatal_tx_err() does.
> > 
> > Yes, having this one only is not enough. It will need to either disable
> > the vif timer or check vif->netbk != NULL inside timer callback.
> 
> I continue to be unclear what timer you refer to.
> 

Oh, it is the tx credit timer callback, which will try to schedule vif
regardless of whether it is linked to netbk or not. See
tx_credit_callback.

It is also the root cause of Christopher's latest oops report last
night, when he `ifconfig vifX.X down` in Dom0.

> If we keep the carrier-off in fatal_tx_err, then _all_
> asynchronously callable interfaces need to check whether the
> vif -> netbk association went away. But, especially in the
> context of using tasklets instead of kthreads, I meanwhile
> think that simply setting a flag (along with turning off the IRQ)
> would be better (and keep the turning off of the carrier the way
> it had been done before. The flag would basically need checking
> anywhere we look at the shared ring (which ought to be very
> few places), and perhaps should also cause xenvif_schedulable()
> to return false.
> 

Is this equivalent to checking vif->netbk? Well, at least in practice.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:40:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y6l-0005F2-1F; Thu, 14 Feb 2013 12:40:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U5y6j-0005EM-LH
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:09 +0000
Received: from [85.158.138.51:37489] by server-5.bemta-3.messagelabs.com id
	35/59-04457-82BDC115; Thu, 14 Feb 2013 12:40:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360845606!23510931!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10583 invoked from network); 14 Feb 2013 12:40:07 -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;
	14 Feb 2013 12:40:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7119760"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:40:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:40:05 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5y6f-0005a9-DD;
	Thu, 14 Feb 2013 12:40:05 +0000
Message-ID: <1360845605.16636.128.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 12:40:05 +0000
In-Reply-To: <511CE7B902000078000BE35B@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:33 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
> >> I don't think this patch will fix his problems, which - as described
> >> yesterday - I'm relatively certain result from the harsh action
> >> netbk_fatal_tx_err() does.
> > 
> > Yes, having this one only is not enough. It will need to either disable
> > the vif timer or check vif->netbk != NULL inside timer callback.
> 
> I continue to be unclear what timer you refer to.
> 

Oh, it is the tx credit timer callback, which will try to schedule vif
regardless of whether it is linked to netbk or not. See
tx_credit_callback.

It is also the root cause of Christopher's latest oops report last
night, when he `ifconfig vifX.X down` in Dom0.

> If we keep the carrier-off in fatal_tx_err, then _all_
> asynchronously callable interfaces need to check whether the
> vif -> netbk association went away. But, especially in the
> context of using tasklets instead of kthreads, I meanwhile
> think that simply setting a flag (along with turning off the IRQ)
> would be better (and keep the turning off of the carrier the way
> it had been done before. The flag would basically need checking
> anywhere we look at the shared ring (which ought to be very
> few places), and perhaps should also cause xenvif_schedulable()
> to return false.
> 

Is this equivalent to checking vif->netbk? Well, at least in practice.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:40:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:40: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 1U5y6o-0005Gj-LB; Thu, 14 Feb 2013 12:40:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6n-0005Ft-1o
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:13 +0000
Received: from [85.158.143.35:27298] by server-3.bemta-4.messagelabs.com id
	FC/4E-08920-C2BDC115; Thu, 14 Feb 2013 12:40:12 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360845578!5204029!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19092 invoked from network); 14 Feb 2013 12:39:41 -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;
	14 Feb 2013 12:39:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490403"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-39;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:14 +0000
Message-ID: <1360845437-11497-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/5] gcov: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 169 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 125a582..96a7a5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 74fd424..a4466d2 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..4de4b58
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,72 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 14 12:40:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:40: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 1U5y6o-0005Gj-LB; Thu, 14 Feb 2013 12:40:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y6n-0005Ft-1o
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:13 +0000
Received: from [85.158.143.35:27298] by server-3.bemta-4.messagelabs.com id
	FC/4E-08920-C2BDC115; Thu, 14 Feb 2013 12:40:12 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360845578!5204029!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19092 invoked from network); 14 Feb 2013 12:39:41 -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;
	14 Feb 2013 12:39:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490403"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-39;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:14 +0000
Message-ID: <1360845437-11497-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/5] gcov: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I excluded %.init.o files as they are used before Xen start and should
not have section like .text or .data.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 169 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 125a582..96a7a5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 74fd424..a4466d2 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 64541c8..8e60f5e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..4de4b58
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,72 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 14 12:40:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:40: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 1U5y7G-0005So-4M; Thu, 14 Feb 2013 12:40:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y7E-0005Rt-SS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:41 +0000
Received: from [85.158.143.35:32762] by server-2.bemta-4.messagelabs.com id
	4C/E6-01597-84BDC115; Thu, 14 Feb 2013 12:40:40 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360845578!5204029!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19002 invoked from network); 14 Feb 2013 12:39:39 -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;
	14 Feb 2013 12:39:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490402"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-61;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:17 +0000
Message-ID: <1360845437-11497-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/5] gcov: Add documentation for coverage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

---
 docs/misc/coverage.markdown |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 docs/misc/coverage.markdown

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
new file mode 100644
index 0000000..74af665
--- /dev/null
+++ b/docs/misc/coverage.markdown
@@ -0,0 +1,39 @@
+# Coverage support for Xen
+
+Coverare support allow you to get coverage information from Xen execution.
+You can see how many times a line is executed.
+
+The compiler have specific options that enable the collection of these
+information. Every basic block in the code will be instructed by the compiler
+to compute these statistics. It should not be used in production as it slow
+down your hypervisor.
+
+## Enable coverage
+
+Test coverage support can be turned on compiling Xen with coverage option set
+to y.
+
+Something like:
+    cd xen
+    make coverage=y
+
+(or change your `Config.mk` file).
+
+## Extract coverage data
+
+The way GCC and other tools deal with coverage information is to use some files
+created during build phase (.gcno) and some files produced by executing the
+*program* (.gcda). The program in this case is Xen but Xen cannot write files
+so the way you can use coverage from Xen is extract coverage data from Xen and
+then split these information into files.
+
+To extract data you use a simple utility called `xencov`. Mainly `xencore`
+allow you to do 3 operations:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+Another utility (**TODO**) is used to split extracted data file into files
+needed by userspace tools.
+
-- 
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 Thu Feb 14 12:40:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:40: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 1U5y7G-0005So-4M; Thu, 14 Feb 2013 12:40:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y7E-0005Rt-SS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:41 +0000
Received: from [85.158.143.35:32762] by server-2.bemta-4.messagelabs.com id
	4C/E6-01597-84BDC115; Thu, 14 Feb 2013 12:40:40 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360845578!5204029!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19002 invoked from network); 14 Feb 2013 12:39:39 -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;
	14 Feb 2013 12:39:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490402"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-61;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:17 +0000
Message-ID: <1360845437-11497-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/5] gcov: Add documentation for coverage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

---
 docs/misc/coverage.markdown |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 docs/misc/coverage.markdown

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
new file mode 100644
index 0000000..74af665
--- /dev/null
+++ b/docs/misc/coverage.markdown
@@ -0,0 +1,39 @@
+# Coverage support for Xen
+
+Coverare support allow you to get coverage information from Xen execution.
+You can see how many times a line is executed.
+
+The compiler have specific options that enable the collection of these
+information. Every basic block in the code will be instructed by the compiler
+to compute these statistics. It should not be used in production as it slow
+down your hypervisor.
+
+## Enable coverage
+
+Test coverage support can be turned on compiling Xen with coverage option set
+to y.
+
+Something like:
+    cd xen
+    make coverage=y
+
+(or change your `Config.mk` file).
+
+## Extract coverage data
+
+The way GCC and other tools deal with coverage information is to use some files
+created during build phase (.gcno) and some files produced by executing the
+*program* (.gcda). The program in this case is Xen but Xen cannot write files
+so the way you can use coverage from Xen is extract coverage data from Xen and
+then split these information into files.
+
+To extract data you use a simple utility called `xencov`. Mainly `xencore`
+allow you to do 3 operations:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+Another utility (**TODO**) is used to split extracted data file into files
+needed by userspace tools.
+
-- 
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 Thu Feb 14 12:40:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y7K-0005Vd-Hq; Thu, 14 Feb 2013 12:40:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y7J-0005U8-5p
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:45 +0000
Received: from [85.158.143.35:43134] by server-3.bemta-4.messagelabs.com id
	0C/5F-08920-C4BDC115; Thu, 14 Feb 2013 12:40:44 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360845578!5204029!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19256 invoked from network); 14 Feb 2013 12:39:42 -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;
	14 Feb 2013 12:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490404"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-4x;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:15 +0000
Message-ID: <1360845437-11497-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/5] gcov: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  153 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c         |    7 ++
 xen/include/public/gcov.h   |  115 ++++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |    9 +++
 5 files changed, 322 insertions(+)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 4de4b58..01d5b10 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,6 +19,9 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
 
@@ -61,6 +64,156 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    int ret = -EINVAL;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        op->u.total_size = iter.write_offset;
+        ret = 0;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if ( ret || op->cmd != XEN_SYSCTL_COVERAGE_read_and_reset )
+            break;
+
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..7dec8c1 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,12 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+#ifdef TEST_COVERAGE
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+#endif
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..1b29b48
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..84baae4 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        uint32_t total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..27c5c37 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,11 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 14 12:40:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12: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 1U5y7K-0005Vd-Hq; Thu, 14 Feb 2013 12:40:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5y7J-0005U8-5p
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:40:45 +0000
Received: from [85.158.143.35:43134] by server-3.bemta-4.messagelabs.com id
	0C/5F-08920-C4BDC115; Thu, 14 Feb 2013 12:40:44 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360845578!5204029!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19256 invoked from network); 14 Feb 2013 12:39:42 -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;
	14 Feb 2013 12:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7490404"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:39:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:39:37 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U5y6D-0005Z3-4x;
	Thu, 14 Feb 2013 12:39:37 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Keir (Xen.org)"
	<keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich
	<JBeulich@suse.com>, George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 14 Feb 2013 12:37:15 +0000
Message-ID: <1360845437-11497-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
References: <1360845437-11497-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/5] gcov: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  153 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c         |    7 ++
 xen/include/public/gcov.h   |  115 ++++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |    9 +++
 5 files changed, 322 insertions(+)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 4de4b58..01d5b10 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,6 +19,9 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
 
@@ -61,6 +64,156 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    int ret = -EINVAL;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        op->u.total_size = iter.write_offset;
+        ret = 0;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if ( ret || op->cmd != XEN_SYSCTL_COVERAGE_read_and_reset )
+            break;
+
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..7dec8c1 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -249,6 +250,12 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+#ifdef TEST_COVERAGE
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+#endif
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..1b29b48
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..84baae4 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        uint32_t total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..27c5c37 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,11 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 14 12:45:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:45: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 1U5yBL-0006Pn-FQ; Thu, 14 Feb 2013 12:44:55 +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 1U5yBK-0006Pd-CN
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:44:54 +0000
Received: from [193.109.254.147:35689] by server-12.bemta-14.messagelabs.com
	id D2/73-32582-54CDC115; Thu, 14 Feb 2013 12:44:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360845860!2811633!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12475 invoked from network); 14 Feb 2013 12:44:21 -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; 14 Feb 2013 12:44:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 12:44:20 +0000
Message-Id: <511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 12:45:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
In-Reply-To: <511CE7B902000078000BE35B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
>> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
>>> I don't think this patch will fix his problems, which - as described
>>> yesterday - I'm relatively certain result from the harsh action
>>> netbk_fatal_tx_err() does.
>> 
>> Yes, having this one only is not enough. It will need to either disable
>> the vif timer or check vif->netbk != NULL inside timer callback.
> 
> I continue to be unclear what timer you refer to.
> 
> If we keep the carrier-off in fatal_tx_err, then _all_
> asynchronously callable interfaces need to check whether the
> vif -> netbk association went away. But, especially in the
> context of using tasklets instead of kthreads, I meanwhile
> think that simply setting a flag (along with turning off the IRQ)
> would be better (and keep the turning off of the carrier the way
> it had been done before. The flag would basically need checking
> anywhere we look at the shared ring (which ought to be very
> few places), and perhaps should also cause xenvif_schedulable()
> to return false.

Or a "light" version of xenvif_down(), i.e. simply

	disable_irq(vif->irq);
	xen_netbk_deschedule_xenvif(vif);

If I'm not mistaken, doing this instead of xenvif_carrier_off()
could be all that's needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:45:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:45: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 1U5yBL-0006Pn-FQ; Thu, 14 Feb 2013 12:44:55 +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 1U5yBK-0006Pd-CN
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:44:54 +0000
Received: from [193.109.254.147:35689] by server-12.bemta-14.messagelabs.com
	id D2/73-32582-54CDC115; Thu, 14 Feb 2013 12:44:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360845860!2811633!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12475 invoked from network); 14 Feb 2013 12:44:21 -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; 14 Feb 2013 12:44:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 12:44:20 +0000
Message-Id: <511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 12:45:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
In-Reply-To: <511CE7B902000078000BE35B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14.02.13 at 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
>> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
>>> I don't think this patch will fix his problems, which - as described
>>> yesterday - I'm relatively certain result from the harsh action
>>> netbk_fatal_tx_err() does.
>> 
>> Yes, having this one only is not enough. It will need to either disable
>> the vif timer or check vif->netbk != NULL inside timer callback.
> 
> I continue to be unclear what timer you refer to.
> 
> If we keep the carrier-off in fatal_tx_err, then _all_
> asynchronously callable interfaces need to check whether the
> vif -> netbk association went away. But, especially in the
> context of using tasklets instead of kthreads, I meanwhile
> think that simply setting a flag (along with turning off the IRQ)
> would be better (and keep the turning off of the carrier the way
> it had been done before. The flag would basically need checking
> anywhere we look at the shared ring (which ought to be very
> few places), and perhaps should also cause xenvif_schedulable()
> to return false.

Or a "light" version of xenvif_down(), i.e. simply

	disable_irq(vif->irq);
	xen_netbk_deschedule_xenvif(vif);

If I'm not mistaken, doing this instead of xenvif_carrier_off()
could be all that's needed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:47:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:47: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 1U5yDw-0006aT-2F; Thu, 14 Feb 2013 12:47:36 +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 1U5yDu-0006aN-7m
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:47:34 +0000
Received: from [85.158.143.35:20310] by server-2.bemta-4.messagelabs.com id
	5A/60-01597-5ECDC115; Thu, 14 Feb 2013 12:47:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360846051!11643570!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 14 Feb 2013 12:47:32 -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;
	14 Feb 2013 12:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7120213"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:47:31 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:47:30 -0500
Message-ID: <511CDCE1.8040409@citrix.com>
Date: Thu, 14 Feb 2013 12:47:29 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>	
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	
	<51181924.4050500@theshore.net>	
	<1360583103.16636.29.camel@zion.uk.xensource.com>	
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	
	<511AFFC9.3050404@theshore.net>	
	<1360779868.16636.92.camel@zion.uk.xensource.com>	
	<1360780669.16636.94.camel@zion.uk.xensource.com>	
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>	
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>	
	<1360840843.16636.109.camel@zion.uk.xensource.com>	
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>	
	<511CD69B.6050900@citrix.com>
	<1360844950.16636.123.camel@zion.uk.xensource.com>
In-Reply-To: <1360844950.16636.123.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14/02/13 12:29, Wei Liu wrote:
> On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
>> On 14/02/13 11:48, Jan Beulich wrote:
>>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>>>> will hit this bug soon when shutting down DomU.
>>>
>>> I don't think this patch will fix his problems, which - as described
>>> yesterday - I'm relatively certain result from the harsh action
>>> netbk_fatal_tx_err() does.
>>
>> I can't see anything broken in netbk_fatal_tx_err().
>>
>> However, a call to netbk_fatal_tx_err() may result in the vif's ref
>> count going to 1 which means a simutaneous attempt to shutdown the vif
>> will free the net device.
> 
>> Netback thread              Xenwatch thread
>>
>> netbk_fatal_tx_err()        netback_remove()
>>                               xenvif_disconnect()
>>                                 ...
>>                                 free_netdev()
>> netbk_tx_err() Oops!
>>
> 
> This is not a problem. Reading comments and code of the commit,
> netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> is not handled though) which should make sure it will never get
> scheduled again, so in practice it will never hit netbk_tx_err.

Without the fix to the error paths of netbk_count_requests(), then if it
returned 0 netbk_tx_err() may be called.  e.g., if txreq.size < ETH_HLEN.

netbk_fatal_tx_err() should call del_timer_sync() on the credit timer
(vif->credit_timeout) as well, otherwise it may fire and attempt to
reschedule the vif, which will then oops as vif->netbk == NULL.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:47:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:47: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 1U5yDw-0006aT-2F; Thu, 14 Feb 2013 12:47:36 +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 1U5yDu-0006aN-7m
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:47:34 +0000
Received: from [85.158.143.35:20310] by server-2.bemta-4.messagelabs.com id
	5A/60-01597-5ECDC115; Thu, 14 Feb 2013 12:47:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360846051!11643570!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 14 Feb 2013 12:47:32 -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;
	14 Feb 2013 12:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7120213"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:47:31 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:47:30 -0500
Message-ID: <511CDCE1.8040409@citrix.com>
Date: Thu, 14 Feb 2013 12:47:29 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>	
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>	
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>	
	<51181924.4050500@theshore.net>	
	<1360583103.16636.29.camel@zion.uk.xensource.com>	
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>	
	<511AFFC9.3050404@theshore.net>	
	<1360779868.16636.92.camel@zion.uk.xensource.com>	
	<1360780669.16636.94.camel@zion.uk.xensource.com>	
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>	
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>	
	<1360840843.16636.109.camel@zion.uk.xensource.com>	
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>	
	<511CD69B.6050900@citrix.com>
	<1360844950.16636.123.camel@zion.uk.xensource.com>
In-Reply-To: <1360844950.16636.123.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 14/02/13 12:29, Wei Liu wrote:
> On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
>> On 14/02/13 11:48, Jan Beulich wrote:
>>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>>>> will hit this bug soon when shutting down DomU.
>>>
>>> I don't think this patch will fix his problems, which - as described
>>> yesterday - I'm relatively certain result from the harsh action
>>> netbk_fatal_tx_err() does.
>>
>> I can't see anything broken in netbk_fatal_tx_err().
>>
>> However, a call to netbk_fatal_tx_err() may result in the vif's ref
>> count going to 1 which means a simutaneous attempt to shutdown the vif
>> will free the net device.
> 
>> Netback thread              Xenwatch thread
>>
>> netbk_fatal_tx_err()        netback_remove()
>>                               xenvif_disconnect()
>>                                 ...
>>                                 free_netdev()
>> netbk_tx_err() Oops!
>>
> 
> This is not a problem. Reading comments and code of the commit,
> netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> is not handled though) which should make sure it will never get
> scheduled again, so in practice it will never hit netbk_tx_err.

Without the fix to the error paths of netbk_count_requests(), then if it
returned 0 netbk_tx_err() may be called.  e.g., if txreq.size < ETH_HLEN.

netbk_fatal_tx_err() should call del_timer_sync() on the credit timer
(vif->credit_timeout) as well, otherwise it may fire and attempt to
reschedule the vif, which will then oops as vif->netbk == NULL.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:52:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:52: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 1U5yIM-0006mb-QE; Thu, 14 Feb 2013 12:52:10 +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 1U5yIL-0006mV-Eh
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:52:09 +0000
Received: from [85.158.138.51:19241] by server-10.bemta-3.messagelabs.com id
	0C/50-10609-8FDDC115; Thu, 14 Feb 2013 12:52:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1360846326!27466540!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18253 invoked from network); 14 Feb 2013 12:52:08 -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;
	14 Feb 2013 12:52:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7120573"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:52:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:52:05 -0500
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 1U5yIH-0005kK-Fl	for xen-devel@lists.xen.org;
	Thu, 14 Feb 2013 12:52:05 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U5yIH-0000aI-7K	for
	xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:52:05 +0000
MIME-Version: 1.0
X-Mercurial-Node: 500907997cb7b9c6973147d56cfd8a1a4c136c7e
Message-ID: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 12:52:04 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] x86: explicit suffix in inline assembler (for
	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 1360846113 0
# Node ID 500907997cb7b9c6973147d56cfd8a1a4c136c7e
# Parent  4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
x86: explicit suffix in inline assembler (for clang).

This fixes the clang build, and has no effect on gcc's output.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4b01cc2c2c1f -r 500907997cb7 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Feb 14 12:36:01 2013 +0000
+++ b/xen/arch/x86/time.c	Thu Feb 14 12:48:33 2013 +0000
@@ -127,7 +127,7 @@ static inline u64 scale_delta(u64 delta,
         delta <<= scale->shift;
 
     asm (
-        "mul %2 ; shrd $32,%1,%0"
+        "mulq %2 ; shrd $32,%1,%0"
         : "=a" (product), "=d" (delta)
         : "rm" (delta), "0" ((u64)scale->mul_frac) );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:52:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:52: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 1U5yIM-0006mb-QE; Thu, 14 Feb 2013 12:52:10 +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 1U5yIL-0006mV-Eh
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:52:09 +0000
Received: from [85.158.138.51:19241] by server-10.bemta-3.messagelabs.com id
	0C/50-10609-8FDDC115; Thu, 14 Feb 2013 12:52:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1360846326!27466540!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18253 invoked from network); 14 Feb 2013 12:52:08 -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;
	14 Feb 2013 12:52:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7120573"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:52:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:52:05 -0500
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 1U5yIH-0005kK-Fl	for xen-devel@lists.xen.org;
	Thu, 14 Feb 2013 12:52:05 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U5yIH-0000aI-7K	for
	xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:52:05 +0000
MIME-Version: 1.0
X-Mercurial-Node: 500907997cb7b9c6973147d56cfd8a1a4c136c7e
Message-ID: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 12:52:04 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] x86: explicit suffix in inline assembler (for
	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 1360846113 0
# Node ID 500907997cb7b9c6973147d56cfd8a1a4c136c7e
# Parent  4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
x86: explicit suffix in inline assembler (for clang).

This fixes the clang build, and has no effect on gcc's output.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4b01cc2c2c1f -r 500907997cb7 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Thu Feb 14 12:36:01 2013 +0000
+++ b/xen/arch/x86/time.c	Thu Feb 14 12:48:33 2013 +0000
@@ -127,7 +127,7 @@ static inline u64 scale_delta(u64 delta,
         delta <<= scale->shift;
 
     asm (
-        "mul %2 ; shrd $32,%1,%0"
+        "mulq %2 ; shrd $32,%1,%0"
         : "=a" (product), "=d" (delta)
         : "rm" (delta), "0" ((u64)scale->mul_frac) );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:55:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:55: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 1U5yLY-0006wq-Ek; Thu, 14 Feb 2013 12:55:28 +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 1U5yLX-0006wj-8Y
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:55:27 +0000
Received: from [85.158.139.83:51015] by server-9.bemta-5.messagelabs.com id
	D4/C4-24440-EBEDC115; Thu, 14 Feb 2013 12:55:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360846524!27090935!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29637 invoked from network); 14 Feb 2013 12:55:25 -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;
	14 Feb 2013 12:55:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7120752"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:55:23 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5yLT-0005mo-Ii;
	Thu, 14 Feb 2013 12:55:23 +0000
Message-ID: <1360846523.16636.131.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 12:55:23 +0000
In-Reply-To: <511CDCE1.8040409@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
	<1360844950.16636.123.camel@zion.uk.xensource.com>
	<511CDCE1.8040409@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:47 +0000, David Vrabel wrote:
> On 14/02/13 12:29, Wei Liu wrote:
> > On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
> >> On 14/02/13 11:48, Jan Beulich wrote:
> >>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> >>>
> >>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> >>>> will hit this bug soon when shutting down DomU.
> >>>
> >>> I don't think this patch will fix his problems, which - as described
> >>> yesterday - I'm relatively certain result from the harsh action
> >>> netbk_fatal_tx_err() does.
> >>
> >> I can't see anything broken in netbk_fatal_tx_err().
> >>
> >> However, a call to netbk_fatal_tx_err() may result in the vif's ref
> >> count going to 1 which means a simutaneous attempt to shutdown the vif
> >> will free the net device.
> > 
> >> Netback thread              Xenwatch thread
> >>
> >> netbk_fatal_tx_err()        netback_remove()
> >>                               xenvif_disconnect()
> >>                                 ...
> >>                                 free_netdev()
> >> netbk_tx_err() Oops!
> >>
> > 
> > This is not a problem. Reading comments and code of the commit,
> > netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> > is not handled though) which should make sure it will never get
> > scheduled again, so in practice it will never hit netbk_tx_err.
> 
> Without the fix to the error paths of netbk_count_requests(), then if it
> returned 0 netbk_tx_err() may be called.  e.g., if txreq.size < ETH_HLEN.
> 

Yes returning 0 in error case is wrong. I thought we talked about this
problem on the basis that we fix this one, and the latter timer bug.

> netbk_fatal_tx_err() should call del_timer_sync() on the credit timer
> (vif->credit_timeout) as well, otherwise it may fire and attempt to
> reschedule the vif, which will then oops as vif->netbk == NULL.
> 

Yeah, I have patches to fix these bugs, will post them today. :-)


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 12:55:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 12:55: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 1U5yLY-0006wq-Ek; Thu, 14 Feb 2013 12:55:28 +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 1U5yLX-0006wj-8Y
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 12:55:27 +0000
Received: from [85.158.139.83:51015] by server-9.bemta-5.messagelabs.com id
	D4/C4-24440-EBEDC115; Thu, 14 Feb 2013 12:55:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360846524!27090935!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29637 invoked from network); 14 Feb 2013 12:55:25 -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;
	14 Feb 2013 12:55:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7120752"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 12:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 07:55:23 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5yLT-0005mo-Ii;
	Thu, 14 Feb 2013 12:55:23 +0000
Message-ID: <1360846523.16636.131.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 12:55:23 +0000
In-Reply-To: <511CDCE1.8040409@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<511CD69B.6050900@citrix.com>
	<1360844950.16636.123.camel@zion.uk.xensource.com>
	<511CDCE1.8040409@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 12:47 +0000, David Vrabel wrote:
> On 14/02/13 12:29, Wei Liu wrote:
> > On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
> >> On 14/02/13 11:48, Jan Beulich wrote:
> >>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@citrix.com> wrote:
> >>>
> >>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
> >>>> will hit this bug soon when shutting down DomU.
> >>>
> >>> I don't think this patch will fix his problems, which - as described
> >>> yesterday - I'm relatively certain result from the harsh action
> >>> netbk_fatal_tx_err() does.
> >>
> >> I can't see anything broken in netbk_fatal_tx_err().
> >>
> >> However, a call to netbk_fatal_tx_err() may result in the vif's ref
> >> count going to 1 which means a simutaneous attempt to shutdown the vif
> >> will free the net device.
> > 
> >> Netback thread              Xenwatch thread
> >>
> >> netbk_fatal_tx_err()        netback_remove()
> >>                               xenvif_disconnect()
> >>                                 ...
> >>                                 free_netdev()
> >> netbk_tx_err() Oops!
> >>
> > 
> > This is not a problem. Reading comments and code of the commit,
> > netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> > is not handled though) which should make sure it will never get
> > scheduled again, so in practice it will never hit netbk_tx_err.
> 
> Without the fix to the error paths of netbk_count_requests(), then if it
> returned 0 netbk_tx_err() may be called.  e.g., if txreq.size < ETH_HLEN.
> 

Yes returning 0 in error case is wrong. I thought we talked about this
problem on the basis that we fix this one, and the latter timer bug.

> netbk_fatal_tx_err() should call del_timer_sync() on the credit timer
> (vif->credit_timeout) as well, otherwise it may fire and attempt to
> reschedule the vif, which will then oops as vif->netbk == NULL.
> 

Yeah, I have patches to fix these bugs, will post them today. :-)


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:02:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:02: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 1U5yRl-0007C2-A8; Thu, 14 Feb 2013 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 <Andrew.Cooper3@citrix.com>) id 1U5yRj-0007Bx-Oj
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:01:51 +0000
Received: from [85.158.137.99:36084] by server-4.bemta-3.messagelabs.com id
	36/87-17521-A30EC115; Thu, 14 Feb 2013 13:01:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360846843!18286561!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4543 invoked from network); 14 Feb 2013 13:00:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7491986"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:00:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:00:43 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U5yQc-0005rj-Tb;
	Thu, 14 Feb 2013 13:00:42 +0000
MIME-Version: 1.0
X-Mercurial-Node: dc98663be34ec7399d7373cff8e2933b6a6518ce
Message-ID: <dc98663be34ec7399d73.1360846842@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 14 Feb 2013 13:00:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH v3] hvm: Allow triple fault to imply crash
	rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While the triple fault action on native hardware will result in a system
reset, any modern operating system can and will make use of less violent
reboot methods.  As a result, the most likely cause of a triple fault is a
fatal software bug.

This patch allows the toolstack to indicate that a triple fault should mean a
crash rather than a reboot.  The default of reboot still remains the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v2:
 * Allow any SHUTDOWN_* values to be set
Changes since v1:
 * "reboot" -> "reset"
 * v->domain -> d

diff -r 63594ce1708f -r dc98663be34e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -540,6 +540,7 @@ int hvm_domain_initialise(struct domain 
     hvm_init_guest_time(d);
 
     d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot;
 
     hvm_init_cacheattr_region_list(d);
 
@@ -1244,9 +1245,13 @@ void hvm_hlt(unsigned long rflags)
 void hvm_triple_fault(void)
 {
     struct vcpu *v = current;
+    struct domain *d = v->domain;
+    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON];
+
     gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
-             "invoking HVM system reset.\n", v->vcpu_id);
-    domain_shutdown(v->domain, SHUTDOWN_reboot);
+             "invoking HVM shutdown action %"PRIu8".\n",
+             v->vcpu_id, reason);
+    domain_shutdown(d, reason);
 }
 
 void hvm_inject_trap(struct hvm_trap *trap)
@@ -3929,6 +3934,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_TRIPLE_FAULT_REASON:
+                if ( a.value > SHUTDOWN_MAX )
+                    rc = -EINVAL;
+                break;
             }
 
             if ( rc == 0 ) 
diff -r 63594ce1708f -r dc98663be34e xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,9 @@
 #define HVM_PARAM_ACCESS_RING_PFN   28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
-#define HVM_NR_PARAMS          31
+/* SHUTDOWN_* action in case of a triple fault */
+#define HVM_PARAM_TRIPLE_FAULT_REASON 31
+
+#define HVM_NR_PARAMS          32
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
diff -r 63594ce1708f -r dc98663be34e xen/include/public/sched.h
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -158,6 +158,7 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
+#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.             */
 /* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:02:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:02: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 1U5yRl-0007C2-A8; Thu, 14 Feb 2013 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 <Andrew.Cooper3@citrix.com>) id 1U5yRj-0007Bx-Oj
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:01:51 +0000
Received: from [85.158.137.99:36084] by server-4.bemta-3.messagelabs.com id
	36/87-17521-A30EC115; Thu, 14 Feb 2013 13:01:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360846843!18286561!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4543 invoked from network); 14 Feb 2013 13:00:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7491986"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:00:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:00:43 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U5yQc-0005rj-Tb;
	Thu, 14 Feb 2013 13:00:42 +0000
MIME-Version: 1.0
X-Mercurial-Node: dc98663be34ec7399d7373cff8e2933b6a6518ce
Message-ID: <dc98663be34ec7399d73.1360846842@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 14 Feb 2013 13:00:42 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH v3] hvm: Allow triple fault to imply crash
	rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While the triple fault action on native hardware will result in a system
reset, any modern operating system can and will make use of less violent
reboot methods.  As a result, the most likely cause of a triple fault is a
fatal software bug.

This patch allows the toolstack to indicate that a triple fault should mean a
crash rather than a reboot.  The default of reboot still remains the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v2:
 * Allow any SHUTDOWN_* values to be set
Changes since v1:
 * "reboot" -> "reset"
 * v->domain -> d

diff -r 63594ce1708f -r dc98663be34e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -540,6 +540,7 @@ int hvm_domain_initialise(struct domain 
     hvm_init_guest_time(d);
 
     d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot;
 
     hvm_init_cacheattr_region_list(d);
 
@@ -1244,9 +1245,13 @@ void hvm_hlt(unsigned long rflags)
 void hvm_triple_fault(void)
 {
     struct vcpu *v = current;
+    struct domain *d = v->domain;
+    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON];
+
     gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
-             "invoking HVM system reset.\n", v->vcpu_id);
-    domain_shutdown(v->domain, SHUTDOWN_reboot);
+             "invoking HVM shutdown action %"PRIu8".\n",
+             v->vcpu_id, reason);
+    domain_shutdown(d, reason);
 }
 
 void hvm_inject_trap(struct hvm_trap *trap)
@@ -3929,6 +3934,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_TRIPLE_FAULT_REASON:
+                if ( a.value > SHUTDOWN_MAX )
+                    rc = -EINVAL;
+                break;
             }
 
             if ( rc == 0 ) 
diff -r 63594ce1708f -r dc98663be34e xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -142,6 +142,9 @@
 #define HVM_PARAM_ACCESS_RING_PFN   28
 #define HVM_PARAM_SHARING_RING_PFN  29
 
-#define HVM_NR_PARAMS          31
+/* SHUTDOWN_* action in case of a triple fault */
+#define HVM_PARAM_TRIPLE_FAULT_REASON 31
+
+#define HVM_NR_PARAMS          32
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
diff -r 63594ce1708f -r dc98663be34e xen/include/public/sched.h
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -158,6 +158,7 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
+#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.             */
 /* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:08:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:08: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 1U5yXU-0007Pl-3w; Thu, 14 Feb 2013 13:07:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5yXS-0007Pg-7B
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:07:46 +0000
Received: from [85.158.137.99:13244] by server-3.bemta-3.messagelabs.com id
	65/73-31070-1A1EC115; Thu, 14 Feb 2013 13:07:45 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360847202!13036068!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8644 invoked from network); 14 Feb 2013 13:06:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1460458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:06:35 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 14 Feb 2013
	13:06:34 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 13:06:34 +0000
Thread-Topic: [PATCH] doc: Improve xc_domain_restore inline documentation
Thread-Index: Ac4KtB19PAxRXY6YQ4y1VhBTnC0wwQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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

Was not clear that xc_domain_restore did not resume the machine.
---
 tools/libxc/xenguest.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 1597e5c..f9cd2ec 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -102,6 +102,8 @@ struct restore_callbacks {
 /**
  * This function will restore a saved domain.
  *
+ * Domain is restored in a suspended state ready to be unpaused.
+ *
  * @parm xch a handle to an open hypervisor interface
  * @parm fd the file descriptor to restore a domain from
  * @parm dom the id of the domain
-- 
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 Thu Feb 14 13:08:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:08: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 1U5yXU-0007Pl-3w; Thu, 14 Feb 2013 13:07:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5yXS-0007Pg-7B
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:07:46 +0000
Received: from [85.158.137.99:13244] by server-3.bemta-3.messagelabs.com id
	65/73-31070-1A1EC115; Thu, 14 Feb 2013 13:07:45 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360847202!13036068!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8644 invoked from network); 14 Feb 2013 13:06:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1460458"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:06:35 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 14 Feb 2013
	13:06:34 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 13:06:34 +0000
Thread-Topic: [PATCH] doc: Improve xc_domain_restore inline documentation
Thread-Index: Ac4KtB19PAxRXY6YQ4y1VhBTnC0wwQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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

Was not clear that xc_domain_restore did not resume the machine.
---
 tools/libxc/xenguest.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 1597e5c..f9cd2ec 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -102,6 +102,8 @@ struct restore_callbacks {
 /**
  * This function will restore a saved domain.
  *
+ * Domain is restored in a suspended state ready to be unpaused.
+ *
  * @parm xch a handle to an open hypervisor interface
  * @parm fd the file descriptor to restore a domain from
  * @parm dom the id of the domain
-- 
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 Thu Feb 14 13:11:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:11: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 1U5yaR-0007Xv-N4; Thu, 14 Feb 2013 13:10:51 +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 1U5yaQ-0007Xl-ET
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:10:50 +0000
Received: from [85.158.139.211:53654] by server-6.bemta-5.messagelabs.com id
	FC/C4-01489-952EC115; Thu, 14 Feb 2013 13:10:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360847444!21018835!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32225 invoked from network); 14 Feb 2013 13:10:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:10:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5yaH-000MMb-6P; Thu, 14 Feb 2013 13:10:41 +0000
Date: Thu, 14 Feb 2013 13:10:41 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214131041.GR83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs
	from internal guest 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

So this ends up with two different layouts for core regs, one public and
one private, both of which have the padding/unions to allow 64-bit and
32-bit to coexist.  Can we really not re-use them?

At 15:56 +0000 on 23 Jan (1358956591), Ian Campbell wrote:
> +#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +# ifdef __aarch64__
> +/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> +#   define __DECL_REG(n64, n32) union {          \
> +        uint64_t n64;                            \
> +        uint32_t n32;                            \
> +    }
> +# else
> +/*
> + * Include a 64-bit padding field so that the layout is the same
> + * between 32- and 64-bit hypervisors.
> + */
> +#   define __DECL_REG(n64, n32) union {          \
> +        uint64_t __pad_##n64;                    \
> +        uint32_t n32;                            \
> +    }
> +# endif

On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
allow that on arm64 as well, so I'm not sureethe __pad prefix is useful.

Cheers,

Tim.

> +#else
> +/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
> +#define __DECL_REG(n64, n32) uint64_t n64
> +#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:11:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:11: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 1U5yaR-0007Xv-N4; Thu, 14 Feb 2013 13:10:51 +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 1U5yaQ-0007Xl-ET
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:10:50 +0000
Received: from [85.158.139.211:53654] by server-6.bemta-5.messagelabs.com id
	FC/C4-01489-952EC115; Thu, 14 Feb 2013 13:10:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360847444!21018835!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32225 invoked from network); 14 Feb 2013 13:10:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:10:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5yaH-000MMb-6P; Thu, 14 Feb 2013 13:10:41 +0000
Date: Thu, 14 Feb 2013 13:10:41 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214131041.GR83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs
	from internal guest 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

So this ends up with two different layouts for core regs, one public and
one private, both of which have the padding/unions to allow 64-bit and
32-bit to coexist.  Can we really not re-use them?

At 15:56 +0000 on 23 Jan (1358956591), Ian Campbell wrote:
> +#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +# ifdef __aarch64__
> +/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> +#   define __DECL_REG(n64, n32) union {          \
> +        uint64_t n64;                            \
> +        uint32_t n32;                            \
> +    }
> +# else
> +/*
> + * Include a 64-bit padding field so that the layout is the same
> + * between 32- and 64-bit hypervisors.
> + */
> +#   define __DECL_REG(n64, n32) union {          \
> +        uint64_t __pad_##n64;                    \
> +        uint32_t n32;                            \
> +    }
> +# endif

On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
allow that on arm64 as well, so I'm not sureethe __pad prefix is useful.

Cheers,

Tim.

> +#else
> +/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
> +#define __DECL_REG(n64, n32) uint64_t n64
> +#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:11:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yae-0007a2-9o; Thu, 14 Feb 2013 13:11:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5yab-0007ZB-Bb
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:11:02 +0000
Received: from [85.158.139.211:11345] by server-13.bemta-5.messagelabs.com id
	BB/09-06769-462EC115; Thu, 14 Feb 2013 13:11:00 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360847459!22198850!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9123 invoked from network); 14 Feb 2013 13:11:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:11:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1460568"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:10:00 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 14 Feb 2013
	13:09:59 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Keir (Xen.org)" <keir@xen.org>
Date: Thu, 14 Feb 2013 13:09:59 +0000
Thread-Topic: [PATCH] trivial: Optimize printnum
Thread-Index: Ac4KtJdne+qSldmUTOyIiZADxAcX1g==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458381@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Reuse the string of hexadecimal numbers to simplify printnum implementation
---
 tools/firmware/hvmloader/util.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d5cd277..741b9c2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -315,23 +315,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
         : "0" (idx) );
 }
 
+static const char hex_digits[] = "0123456789abcdef";
+
 /* Write a two-character hex representation of 'byte' to digits[].
    Pre-condition: sizeof(digits) >= 2 */
 void
 byte_to_hex(char *digits, uint8_t byte)
 {
-    uint8_t nybbel = byte >> 4;
-
-    if ( nybbel > 9 )
-        digits[0] = 'a' + nybbel-10;
-    else
-        digits[0] = '0' + nybbel;
-
-    nybbel = byte & 0x0f;
-    if ( nybbel > 9 )
-        digits[1] = 'a' + nybbel-10;
-    else
-        digits[1] = '0' + nybbel;
+    digits[0] = hex_digits[byte >> 4];
+    digits[1] = hex_digits[byte & 0x0f];
 }
 
 /* Convert an array of 16 unsigned bytes to a DCE/OSF formatted UUID
@@ -518,13 +510,13 @@ void pci_write(uint32_t devfn, uint32_t reg, uint32_t len, uint32_t val)
     }
 }
 
-static char *printnum(char *p, unsigned long num, int base)
+static char *printnum(char *p, unsigned long num, unsigned base)
 {
     unsigned long n;
 
     if ( (n = num/base) > 0 )
         p = printnum(p, n, base);
-    *p++ = "0123456789abcdef"[(int)(num % base)];
+    *p++ = hex_digits[num % base];
     *p = '\0';
     return p;
 }
-- 
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 Thu Feb 14 13:11:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yae-0007a2-9o; Thu, 14 Feb 2013 13:11:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5yab-0007ZB-Bb
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:11:02 +0000
Received: from [85.158.139.211:11345] by server-13.bemta-5.messagelabs.com id
	BB/09-06769-462EC115; Thu, 14 Feb 2013 13:11:00 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360847459!22198850!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9123 invoked from network); 14 Feb 2013 13:11:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:11:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1460568"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:10:00 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 14 Feb 2013
	13:09:59 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Keir (Xen.org)" <keir@xen.org>
Date: Thu, 14 Feb 2013 13:09:59 +0000
Thread-Topic: [PATCH] trivial: Optimize printnum
Thread-Index: Ac4KtJdne+qSldmUTOyIiZADxAcX1g==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458381@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Reuse the string of hexadecimal numbers to simplify printnum implementation
---
 tools/firmware/hvmloader/util.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d5cd277..741b9c2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -315,23 +315,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
         : "0" (idx) );
 }
 
+static const char hex_digits[] = "0123456789abcdef";
+
 /* Write a two-character hex representation of 'byte' to digits[].
    Pre-condition: sizeof(digits) >= 2 */
 void
 byte_to_hex(char *digits, uint8_t byte)
 {
-    uint8_t nybbel = byte >> 4;
-
-    if ( nybbel > 9 )
-        digits[0] = 'a' + nybbel-10;
-    else
-        digits[0] = '0' + nybbel;
-
-    nybbel = byte & 0x0f;
-    if ( nybbel > 9 )
-        digits[1] = 'a' + nybbel-10;
-    else
-        digits[1] = '0' + nybbel;
+    digits[0] = hex_digits[byte >> 4];
+    digits[1] = hex_digits[byte & 0x0f];
 }
 
 /* Convert an array of 16 unsigned bytes to a DCE/OSF formatted UUID
@@ -518,13 +510,13 @@ void pci_write(uint32_t devfn, uint32_t reg, uint32_t len, uint32_t val)
     }
 }
 
-static char *printnum(char *p, unsigned long num, int base)
+static char *printnum(char *p, unsigned long num, unsigned base)
 {
     unsigned long n;
 
     if ( (n = num/base) > 0 )
         p = printnum(p, n, base);
-    *p++ = "0123456789abcdef"[(int)(num % base)];
+    *p++ = hex_digits[num % base];
     *p = '\0';
     return p;
 }
-- 
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 Thu Feb 14 13:14:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5ydd-0007sQ-Um; Thu, 14 Feb 2013 13:14:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <suresh.lalith@gmail.com>) id 1U5wfn-0006se-H2
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:08:15 +0000
Received: from [193.109.254.147:48971] by server-5.bemta-14.messagelabs.com id
	F5/32-21539-E95CC115; Thu, 14 Feb 2013 11:08:14 +0000
X-Env-Sender: suresh.lalith@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360840090!8701924!1
X-Originating-IP: [209.85.215.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31254 invoked from network); 14 Feb 2013 11:08:11 -0000
Received: from mail-ea0-f179.google.com (HELO mail-ea0-f179.google.com)
	(209.85.215.179)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:08:11 -0000
Received: by mail-ea0-f179.google.com with SMTP id d12so894669eaa.10
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Feb 2013 03:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:content-type:mime-version:content-transfer-encoding
	:subject:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=S1cGJvpsA4IM4u0ISPdqj0TXc4LKpRlhcLrzFFtI/m0=;
	b=HoUxWv6Aq/A9S0WaktQubRDk7ktynUGp8+mci2qnLjk9sQQaTgCYt9CuG2bxQSEMK/
	3nNB5bKCAJ4nsX+IqdVG9eMli6lh1z0fUj1DKpyqQ+2oys24IvdbS/MId4dZi5P0N3yq
	T5K9SYVRa9L+eddB2Z9D4QjdwkLujC+g+ukfz8Vr85XzsePCkfdhE74pdY5LFbZIDwGn
	DtAeBbBUlBzYSYPJB18gaCd6TJDZn/eUbc9mDBN5U0aAn2I+aUdM4/7xxsb6FRbdcRyK
	ipwUHx7Nd+aEn6Y6/Jlpu45Finvo5k/od9LdUTbxNinizA9gISQcV6eOp/MySY5Mb+GX
	6U/g==
X-Received: by 10.14.202.71 with SMTP id c47mr28291694eeo.39.1360840090237;
	Thu, 14 Feb 2013 03:08:10 -0800 (PST)
Received: from [127.0.1.1] ([130.149.235.15])
	by mx.google.com with ESMTPS id l8sm43906956een.10.2013.02.14.03.08.09
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 03:08:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5ba8cd0c47cb4fe961a1e8a6975e5d0bfeff233e
Message-Id: <5ba8cd0c47cb4fe961a1.1360840081@irule>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 14 Feb 2013 12:08:01 +0100
From: Lalith Suresh <suresh.lalith@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 14 Feb 2013 13:14:08 +0000
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] xm: fix description of xm vcpu-set 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

Minor language correction in the description of the xm vcpu-set command.

Signed-off-by: Lalith Suresh <suresh.lalith@gmail.com>

diff -r 63594ce1708f -r 5ba8cd0c47cb tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py	Wed Feb 13 09:31:48 2013 +0100
+++ b/tools/python/xen/xm/main.py	Thu Feb 14 11:57:20 2013 +0100
@@ -164,7 +164,7 @@ SUBCOMMAND_HELP = {
     'vcpu-pin'    : ('<Domain> <VCPU|all> <CPUs|all>',
                      'Set which CPUs a VCPU can use.'),
     'vcpu-set'    : ('<Domain> <vCPUs>',
-                     'Set the number of active VCPUs for allowed for the'
+                     'Set the number of active VCPUs allowed for the'
                      ' domain.'),
     #usb
     'usb-add'     : ('<domain> <[host:bus.addr] [host:vendor_id:product_id]>','Add the usb device to FV VM.'),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:14:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5ydd-0007sQ-Um; Thu, 14 Feb 2013 13:14:09 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <suresh.lalith@gmail.com>) id 1U5wfn-0006se-H2
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 11:08:15 +0000
Received: from [193.109.254.147:48971] by server-5.bemta-14.messagelabs.com id
	F5/32-21539-E95CC115; Thu, 14 Feb 2013 11:08:14 +0000
X-Env-Sender: suresh.lalith@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360840090!8701924!1
X-Originating-IP: [209.85.215.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31254 invoked from network); 14 Feb 2013 11:08:11 -0000
Received: from mail-ea0-f179.google.com (HELO mail-ea0-f179.google.com)
	(209.85.215.179)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 11:08:11 -0000
Received: by mail-ea0-f179.google.com with SMTP id d12so894669eaa.10
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Feb 2013 03:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:content-type:mime-version:content-transfer-encoding
	:subject:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=S1cGJvpsA4IM4u0ISPdqj0TXc4LKpRlhcLrzFFtI/m0=;
	b=HoUxWv6Aq/A9S0WaktQubRDk7ktynUGp8+mci2qnLjk9sQQaTgCYt9CuG2bxQSEMK/
	3nNB5bKCAJ4nsX+IqdVG9eMli6lh1z0fUj1DKpyqQ+2oys24IvdbS/MId4dZi5P0N3yq
	T5K9SYVRa9L+eddB2Z9D4QjdwkLujC+g+ukfz8Vr85XzsePCkfdhE74pdY5LFbZIDwGn
	DtAeBbBUlBzYSYPJB18gaCd6TJDZn/eUbc9mDBN5U0aAn2I+aUdM4/7xxsb6FRbdcRyK
	ipwUHx7Nd+aEn6Y6/Jlpu45Finvo5k/od9LdUTbxNinizA9gISQcV6eOp/MySY5Mb+GX
	6U/g==
X-Received: by 10.14.202.71 with SMTP id c47mr28291694eeo.39.1360840090237;
	Thu, 14 Feb 2013 03:08:10 -0800 (PST)
Received: from [127.0.1.1] ([130.149.235.15])
	by mx.google.com with ESMTPS id l8sm43906956een.10.2013.02.14.03.08.09
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 03:08:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5ba8cd0c47cb4fe961a1e8a6975e5d0bfeff233e
Message-Id: <5ba8cd0c47cb4fe961a1.1360840081@irule>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 14 Feb 2013 12:08:01 +0100
From: Lalith Suresh <suresh.lalith@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Thu, 14 Feb 2013 13:14:08 +0000
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] xm: fix description of xm vcpu-set 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

Minor language correction in the description of the xm vcpu-set command.

Signed-off-by: Lalith Suresh <suresh.lalith@gmail.com>

diff -r 63594ce1708f -r 5ba8cd0c47cb tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py	Wed Feb 13 09:31:48 2013 +0100
+++ b/tools/python/xen/xm/main.py	Thu Feb 14 11:57:20 2013 +0100
@@ -164,7 +164,7 @@ SUBCOMMAND_HELP = {
     'vcpu-pin'    : ('<Domain> <VCPU|all> <CPUs|all>',
                      'Set which CPUs a VCPU can use.'),
     'vcpu-set'    : ('<Domain> <vCPUs>',
-                     'Set the number of active VCPUs for allowed for the'
+                     'Set the number of active VCPUs allowed for the'
                      ' domain.'),
     #usb
     'usb-add'     : ('<domain> <[host:bus.addr] [host:vendor_id:product_id]>','Add the usb device to FV VM.'),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:17:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5ygx-000830-Ju; Thu, 14 Feb 2013 13:17:35 +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 1U5ygw-00082v-0f
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:17:34 +0000
Received: from [85.158.139.211:25342] by server-2.bemta-5.messagelabs.com id
	ED/2E-16911-DE3EC115; Thu, 14 Feb 2013 13:17:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360847852!19754681!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23884 invoked from network); 14 Feb 2013 13:17:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:17:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 13:17:40 +0000
Message-Id: <511CF23502000078000BE414@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 13:18:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
In-Reply-To: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86: explicit suffix in inline assembler
 (for 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 14.02.13 at 13:52, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1360846113 0
> # Node ID 500907997cb7b9c6973147d56cfd8a1a4c136c7e
> # Parent  4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
> x86: explicit suffix in inline assembler (for clang).
> 
> This fixes the clang build, and has no effect on gcc's output.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 4b01cc2c2c1f -r 500907997cb7 xen/arch/x86/time.c
> --- a/xen/arch/x86/time.c	Thu Feb 14 12:36:01 2013 +0000
> +++ b/xen/arch/x86/time.c	Thu Feb 14 12:48:33 2013 +0000
> @@ -127,7 +127,7 @@ static inline u64 scale_delta(u64 delta,
>          delta <<= scale->shift;
>  
>      asm (
> -        "mul %2 ; shrd $32,%1,%0"
> +        "mulq %2 ; shrd $32,%1,%0"
>          : "=a" (product), "=d" (delta)
>          : "rm" (delta), "0" ((u64)scale->mul_frac) );
>  

I'll commit this as being benign, but what the heck? "mul" needs
a suffix but "shrd" doesn't?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:17:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5ygx-000830-Ju; Thu, 14 Feb 2013 13:17:35 +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 1U5ygw-00082v-0f
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:17:34 +0000
Received: from [85.158.139.211:25342] by server-2.bemta-5.messagelabs.com id
	ED/2E-16911-DE3EC115; Thu, 14 Feb 2013 13:17:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360847852!19754681!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23884 invoked from network); 14 Feb 2013 13:17:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:17:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 13:17:40 +0000
Message-Id: <511CF23502000078000BE414@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 13:18:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
In-Reply-To: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86: explicit suffix in inline assembler
 (for 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 14.02.13 at 13:52, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1360846113 0
> # Node ID 500907997cb7b9c6973147d56cfd8a1a4c136c7e
> # Parent  4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
> x86: explicit suffix in inline assembler (for clang).
> 
> This fixes the clang build, and has no effect on gcc's output.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 4b01cc2c2c1f -r 500907997cb7 xen/arch/x86/time.c
> --- a/xen/arch/x86/time.c	Thu Feb 14 12:36:01 2013 +0000
> +++ b/xen/arch/x86/time.c	Thu Feb 14 12:48:33 2013 +0000
> @@ -127,7 +127,7 @@ static inline u64 scale_delta(u64 delta,
>          delta <<= scale->shift;
>  
>      asm (
> -        "mul %2 ; shrd $32,%1,%0"
> +        "mulq %2 ; shrd $32,%1,%0"
>          : "=a" (product), "=d" (delta)
>          : "rm" (delta), "0" ((u64)scale->mul_frac) );
>  

I'll commit this as being benign, but what the heck? "mul" needs
a suffix but "shrd" doesn't?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:19:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yis-00089K-4p; Thu, 14 Feb 2013 13:19:34 +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 1U5yiq-00089B-MF
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:32 +0000
Received: from [85.158.138.51:18075] by server-16.bemta-3.messagelabs.com id
	D1/6D-02727-364EC115; Thu, 14 Feb 2013 13:19:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360847969!23518326!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7625 invoked from network); 14 Feb 2013 13:19:31 -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;
	14 Feb 2013 13:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7124137"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:19:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:19:28 -0500
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 1U5yig-00069z-NZ;
	Thu, 14 Feb 2013 13:19:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 13:18:57 +0000
Message-ID: <1360847938-11185-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen-netback: correctly return errors from
	netbk_count_requests()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

netbk_count_requests() could detect an error, call
netbk_fatal_tx_error() but return 0.  The vif may then be used
afterwards (e.g., in a call to netbk_tx_error().

Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
if the vif is also removed).

Netback thread              Xenwatch thread
-------------------------------------------
netbk_fatal_tx_err()        netback_remove()
                              xenvif_disconnect()
                                ...
                                free_netdev()
netbk_tx_err() Oops!

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2b9520c..cd49ba9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -911,13 +911,13 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (frags >= work_to_do) {
 			netdev_err(vif->dev, "Need more frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -ENODATA;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
 			netdev_err(vif->dev, "Too many frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -E2BIG;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
@@ -925,7 +925,7 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (txp->size > first->size) {
 			netdev_err(vif->dev, "Frag is bigger than frame.\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -EIO;
 		}
 
 		first->size -= txp->size;
@@ -935,7 +935,7 @@ static int netbk_count_requests(struct xenvif *vif,
 			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -EINVAL;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
 	return frags;
-- 
1.7.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 Feb 14 13:19:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yis-00089K-4p; Thu, 14 Feb 2013 13:19:34 +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 1U5yiq-00089B-MF
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:32 +0000
Received: from [85.158.138.51:18075] by server-16.bemta-3.messagelabs.com id
	D1/6D-02727-364EC115; Thu, 14 Feb 2013 13:19:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360847969!23518326!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7625 invoked from network); 14 Feb 2013 13:19:31 -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;
	14 Feb 2013 13:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7124137"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:19:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:19:28 -0500
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 1U5yig-00069z-NZ;
	Thu, 14 Feb 2013 13:19:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 13:18:57 +0000
Message-ID: <1360847938-11185-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen-netback: correctly return errors from
	netbk_count_requests()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

netbk_count_requests() could detect an error, call
netbk_fatal_tx_error() but return 0.  The vif may then be used
afterwards (e.g., in a call to netbk_tx_error().

Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
if the vif is also removed).

Netback thread              Xenwatch thread
-------------------------------------------
netbk_fatal_tx_err()        netback_remove()
                              xenvif_disconnect()
                                ...
                                free_netdev()
netbk_tx_err() Oops!

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/netback.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2b9520c..cd49ba9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -911,13 +911,13 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (frags >= work_to_do) {
 			netdev_err(vif->dev, "Need more frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -ENODATA;
 		}
 
 		if (unlikely(frags >= MAX_SKB_FRAGS)) {
 			netdev_err(vif->dev, "Too many frags\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -E2BIG;
 		}
 
 		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
@@ -925,7 +925,7 @@ static int netbk_count_requests(struct xenvif *vif,
 		if (txp->size > first->size) {
 			netdev_err(vif->dev, "Frag is bigger than frame.\n");
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -EIO;
 		}
 
 		first->size -= txp->size;
@@ -935,7 +935,7 @@ static int netbk_count_requests(struct xenvif *vif,
 			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 				 txp->offset, txp->size);
 			netbk_fatal_tx_err(vif);
-			return -frags;
+			return -EINVAL;
 		}
 	} while ((txp++)->flags & XEN_NETTXF_more_data);
 	return frags;
-- 
1.7.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 Feb 14 13:19:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yit-00089Y-Hf; Thu, 14 Feb 2013 13:19: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 1U5yis-00089I-8C
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:34 +0000
Received: from [85.158.143.35:38178] by server-1.bemta-4.messagelabs.com id
	B0/E1-08839-564EC115; Thu, 14 Feb 2013 13:19:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360847963!13102427!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12695 invoked from network); 14 Feb 2013 13:19:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7494939"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:19:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:19:22 -0500
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 1U5yig-00069z-LF;
	Thu, 14 Feb 2013 13:19:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 13:18:56 +0000
Message-ID: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: [Xen-devel] xen-netback: fix oopes during shutdown and error
	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

These two netback patches fix oopes that may occur during shutdown or
if a specific fatal error occurs.

They are stable candidants.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:19:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yit-00089Y-Hf; Thu, 14 Feb 2013 13:19: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 1U5yis-00089I-8C
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:34 +0000
Received: from [85.158.143.35:38178] by server-1.bemta-4.messagelabs.com id
	B0/E1-08839-564EC115; Thu, 14 Feb 2013 13:19:33 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360847963!13102427!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12695 invoked from network); 14 Feb 2013 13:19:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7494939"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:19:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:19:22 -0500
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 1U5yig-00069z-LF;
	Thu, 14 Feb 2013 13:19:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 13:18:56 +0000
Message-ID: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: [Xen-devel] xen-netback: fix oopes during shutdown and error
	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

These two netback patches fix oopes that may occur during shutdown or
if a specific fatal error occurs.

They are stable candidants.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:19:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yiw-0008AF-CW; Thu, 14 Feb 2013 13:19:38 +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 1U5yiu-00089m-SI
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:37 +0000
Received: from [85.158.139.211:41929] by server-13.bemta-5.messagelabs.com id
	21/3D-06769-864EC115; Thu, 14 Feb 2013 13:19:36 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360847969!22494420!1
X-Originating-IP: [209.85.216.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14986 invoked from network); 14 Feb 2013 13:19:35 -0000
Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com)
	(209.85.216.179)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:19:35 -0000
Received: by mail-qc0-f179.google.com with SMTP id b40so852076qcq.24
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type;
	bh=Ffm7YtEUWFujYjMPKs6RcJrV8K/ZmTo8U8X7fKITWKM=;
	b=Q2l1h/nT2qIKigQQbQy5jzQVUHyQCjL+fSxSjR/nV3xuR30H+WGcMwmIAJlRqUTPxS
	jauHE8evh4E+yDwJXtJ+fyuro+B2MCZyoFwBBeF6s2DK/vnVDMFEaqJTzlWz3wMJCl4X
	WJf9pN1qpOkjmh2hGmHMihsEHrm2Xb/RDFG+w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type
	:x-gm-message-state;
	bh=Ffm7YtEUWFujYjMPKs6RcJrV8K/ZmTo8U8X7fKITWKM=;
	b=Fe38fAx13cLlhm3BDCd64fwPJPTUSEJegwqYn3W/tFOWYd2zpJRnJhytXgypUYvNjw
	WZ8t1thJg4bSHvzq8EKNnxDS6/oYic0XWGarV69LoQCUghPUVhR0IxCFtXBbMTGQDRR+
	OqFFteNzXPkNN7RkTRakLTuyGvrWSffD8l1yy09AGnmiLoyxwMItZstRLPbMMAKYpgVD
	uw8CvhNx+zzDPkw8DYFreXMfKUpyDuVu+g4sdhwsrohPPeGbg5DUAibtD3I1pFtbYe03
	EjoBC1SyMXjtTBDC51v0f+VUPh1GVyvhPEqeuVVZt4CxVWO3uEubVmWS2BUVEpLLkqPF
	2sJQ==
X-Received: by 10.49.127.240 with SMTP id nj16mr11624444qeb.13.1360847951686; 
	Thu, 14 Feb 2013 05:19:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 14 Feb 2013 05:18:54 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 17:18:54 +0400
X-Google-Sender-Auth: x9tRLN7xlIAkr1jKtlmDebt0SOA
Message-ID: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQm49mZi/3RaqXzXyf8EYr6ak/AUWUOCbBw7fs45LJi863FwQ6ElKVVUJ4NaybDcIqc63k+f
Subject: [Xen-devel] using @releaseDomain to subscribe for domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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!. How can i use @releaseDomain from dom0 to subscribe for domain
destruction?
I'm try to add watch for @releaseDomain path with token equal of
needed domain id. But when another domain dies, i get domain that i
provide via token to xs_watch.
Is that possible to get id of domain what released from xenstore?

-- 
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 Thu Feb 14 13:19:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yiw-0008AF-CW; Thu, 14 Feb 2013 13:19:38 +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 1U5yiu-00089m-SI
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:37 +0000
Received: from [85.158.139.211:41929] by server-13.bemta-5.messagelabs.com id
	21/3D-06769-864EC115; Thu, 14 Feb 2013 13:19:36 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360847969!22494420!1
X-Originating-IP: [209.85.216.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14986 invoked from network); 14 Feb 2013 13:19:35 -0000
Received: from mail-qc0-f179.google.com (HELO mail-qc0-f179.google.com)
	(209.85.216.179)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:19:35 -0000
Received: by mail-qc0-f179.google.com with SMTP id b40so852076qcq.24
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type;
	bh=Ffm7YtEUWFujYjMPKs6RcJrV8K/ZmTo8U8X7fKITWKM=;
	b=Q2l1h/nT2qIKigQQbQy5jzQVUHyQCjL+fSxSjR/nV3xuR30H+WGcMwmIAJlRqUTPxS
	jauHE8evh4E+yDwJXtJ+fyuro+B2MCZyoFwBBeF6s2DK/vnVDMFEaqJTzlWz3wMJCl4X
	WJf9pN1qpOkjmh2hGmHMihsEHrm2Xb/RDFG+w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:sender:x-originating-ip:from:date
	:x-google-sender-auth:message-id:subject:to:content-type
	:x-gm-message-state;
	bh=Ffm7YtEUWFujYjMPKs6RcJrV8K/ZmTo8U8X7fKITWKM=;
	b=Fe38fAx13cLlhm3BDCd64fwPJPTUSEJegwqYn3W/tFOWYd2zpJRnJhytXgypUYvNjw
	WZ8t1thJg4bSHvzq8EKNnxDS6/oYic0XWGarV69LoQCUghPUVhR0IxCFtXBbMTGQDRR+
	OqFFteNzXPkNN7RkTRakLTuyGvrWSffD8l1yy09AGnmiLoyxwMItZstRLPbMMAKYpgVD
	uw8CvhNx+zzDPkw8DYFreXMfKUpyDuVu+g4sdhwsrohPPeGbg5DUAibtD3I1pFtbYe03
	EjoBC1SyMXjtTBDC51v0f+VUPh1GVyvhPEqeuVVZt4CxVWO3uEubVmWS2BUVEpLLkqPF
	2sJQ==
X-Received: by 10.49.127.240 with SMTP id nj16mr11624444qeb.13.1360847951686; 
	Thu, 14 Feb 2013 05:19:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 14 Feb 2013 05:18:54 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 17:18:54 +0400
X-Google-Sender-Auth: x9tRLN7xlIAkr1jKtlmDebt0SOA
Message-ID: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQm49mZi/3RaqXzXyf8EYr6ak/AUWUOCbBw7fs45LJi863FwQ6ElKVVUJ4NaybDcIqc63k+f
Subject: [Xen-devel] using @releaseDomain to subscribe for domain destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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!. How can i use @releaseDomain from dom0 to subscribe for domain
destruction?
I'm try to add watch for @releaseDomain path with token equal of
needed domain id. But when another domain dies, i get domain that i
provide via token to xs_watch.
Is that possible to get id of domain what released from xenstore?

-- 
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 Thu Feb 14 13:19:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yiu-00089s-VH; Thu, 14 Feb 2013 13:19:36 +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 1U5yit-00089I-U1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:36 +0000
Received: from [85.158.143.35:38239] by server-1.bemta-4.messagelabs.com id
	34/E1-08839-664EC115; Thu, 14 Feb 2013 13:19:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360847963!13102427!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12714 invoked from network); 14 Feb 2013 13:19:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:19:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7494940"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:19:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:19:23 -0500
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 1U5yig-00069z-PU;
	Thu, 14 Feb 2013 13:19:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 13:18:58 +0000
Message-ID: <1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer when
	taking the vif 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="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>

If the credit timer is left armed after calling
xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
the vif which will then oops as vif->netbk == NULL.

This may happen both in the fatal error path and during normal
disconnection from the front end.

The sequencing during shutdown is critical to ensure that: a)
vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
is not freed.

1. Mark as unschedulable (netif_carrier_off()).
2. Synchronously cancel the timer.
3. Remove the vif from the schedule list.
4. Remove it from it netback thread group.
5. Wait for vif->refcnt to become 0.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/interface.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b8c5193..221f426 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
 static void xenvif_down(struct xenvif *vif)
 {
 	disable_irq(vif->irq);
+	del_timer_sync(&vif->credit_timeout);
 	xen_netbk_deschedule_xenvif(vif);
 	xen_netbk_remove_xenvif(vif);
 }
@@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
 
-	del_timer_sync(&vif->credit_timeout);
-
 	if (vif->irq)
 		unbind_from_irqhandler(vif->irq, vif);
 
-- 
1.7.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 Feb 14 13:19:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5yiu-00089s-VH; Thu, 14 Feb 2013 13:19:36 +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 1U5yit-00089I-U1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:19:36 +0000
Received: from [85.158.143.35:38239] by server-1.bemta-4.messagelabs.com id
	34/E1-08839-664EC115; Thu, 14 Feb 2013 13:19:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360847963!13102427!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12714 invoked from network); 14 Feb 2013 13:19:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:19:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7494940"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:19:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:19:23 -0500
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 1U5yig-00069z-PU;
	Thu, 14 Feb 2013 13:19:22 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 13:18:58 +0000
Message-ID: <1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer when
	taking the vif 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="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>

If the credit timer is left armed after calling
xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
the vif which will then oops as vif->netbk == NULL.

This may happen both in the fatal error path and during normal
disconnection from the front end.

The sequencing during shutdown is critical to ensure that: a)
vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
is not freed.

1. Mark as unschedulable (netif_carrier_off()).
2. Synchronously cancel the timer.
3. Remove the vif from the schedule list.
4. Remove it from it netback thread group.
5. Wait for vif->refcnt to become 0.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/net/xen-netback/interface.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b8c5193..221f426 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
 static void xenvif_down(struct xenvif *vif)
 {
 	disable_irq(vif->irq);
+	del_timer_sync(&vif->credit_timeout);
 	xen_netbk_deschedule_xenvif(vif);
 	xen_netbk_remove_xenvif(vif);
 }
@@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
 
-	del_timer_sync(&vif->credit_timeout);
-
 	if (vif->irq)
 		unbind_from_irqhandler(vif->irq, vif);
 
-- 
1.7.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 Feb 14 13:23:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5ymh-0000Gl-3G; Thu, 14 Feb 2013 13:23:31 +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 1U5ymf-0000GV-J1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:23:29 +0000
Received: from [85.158.137.99:52596] by server-9.bemta-3.messagelabs.com id
	5E/6C-09484-055EC115; Thu, 14 Feb 2013 13:23:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360848203!21424942!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzM4MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27202 invoked from network); 14 Feb 2013 13:23:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:23:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EDNKob021818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 13:23:21 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
	r1EDNJaV013471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 13:23:20 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
	r1EDNJTG012181; Thu, 14 Feb 2013 07:23:19 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 05:23:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 859DF1C387B; Thu, 14 Feb 2013 08:23:18 -0500 (EST)
Date: Thu, 14 Feb 2013 08:23:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130214132318.GC2506@phenom.dumpdata.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 14, 2013 at 11:12:09AM +0100, Roger Pau Monne wrote:
> With current persistent grants implementation we are not freeing the
> persistent grants after we disconnect the device. Since grant map

Can you explain this in more details please? Isn't gnttab_set_unmap_op
in free_persistent_gnts doing the right job of putting in the right
mfn in? And then we could free the page?


> operations change the mfn of the allocated page, and we can no longer
> pass it to __free_page without setting the mfn to a sane value, use
> balloon grant pages instead, as the gntdev device does.


Wow. I did not realize that we leaving such a huge memory leak behind!
But I guess that was never an issue as we would recycle those persistent
grants to other domains.
> =

> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkback/blkback.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> =

> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkb=
ack/blkback.c
> index c46824f..e6c2f6a 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -46,6 +46,7 @@
>  #include <xen/xen.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> +#include <xen/balloon.h>
>  #include "common.h"
>  =

>  /*
> @@ -239,6 +240,7 @@ static void free_persistent_gnts(struct rb_root *root=
, unsigned int num)
>  			ret =3D gnttab_unmap_refs(unmap, NULL, pages,
>  				segs_to_unmap);
>  			BUG_ON(ret);
> +			free_xenballooned_pages(segs_to_unmap, pages);
>  			segs_to_unmap =3D 0;
>  		}
>  =

> @@ -527,8 +529,8 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				GFP_KERNEL);
>  			if (!persistent_gnt)
>  				return -ENOMEM;
> -			persistent_gnt->page =3D alloc_page(GFP_KERNEL);
> -			if (!persistent_gnt->page) {
> +			if (alloc_xenballooned_pages(1, &persistent_gnt->page,
> +			    false)) {
>  				kfree(persistent_gnt);
>  				return -ENOMEM;
>  			}
> -- =

> 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 Thu Feb 14 13:23:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5ymh-0000Gl-3G; Thu, 14 Feb 2013 13:23:31 +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 1U5ymf-0000GV-J1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:23:29 +0000
Received: from [85.158.137.99:52596] by server-9.bemta-3.messagelabs.com id
	5E/6C-09484-055EC115; Thu, 14 Feb 2013 13:23:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360848203!21424942!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzM4MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27202 invoked from network); 14 Feb 2013 13:23:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:23:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EDNKob021818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 13:23:21 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
	r1EDNJaV013471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 13:23:20 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
	r1EDNJTG012181; Thu, 14 Feb 2013 07:23:19 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 05:23:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 859DF1C387B; Thu, 14 Feb 2013 08:23:18 -0500 (EST)
Date: Thu, 14 Feb 2013 08:23:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130214132318.GC2506@phenom.dumpdata.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 14, 2013 at 11:12:09AM +0100, Roger Pau Monne wrote:
> With current persistent grants implementation we are not freeing the
> persistent grants after we disconnect the device. Since grant map

Can you explain this in more details please? Isn't gnttab_set_unmap_op
in free_persistent_gnts doing the right job of putting in the right
mfn in? And then we could free the page?


> operations change the mfn of the allocated page, and we can no longer
> pass it to __free_page without setting the mfn to a sane value, use
> balloon grant pages instead, as the gntdev device does.


Wow. I did not realize that we leaving such a huge memory leak behind!
But I guess that was never an issue as we would recycle those persistent
grants to other domains.
> =

> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/block/xen-blkback/blkback.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> =

> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkb=
ack/blkback.c
> index c46824f..e6c2f6a 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -46,6 +46,7 @@
>  #include <xen/xen.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> +#include <xen/balloon.h>
>  #include "common.h"
>  =

>  /*
> @@ -239,6 +240,7 @@ static void free_persistent_gnts(struct rb_root *root=
, unsigned int num)
>  			ret =3D gnttab_unmap_refs(unmap, NULL, pages,
>  				segs_to_unmap);
>  			BUG_ON(ret);
> +			free_xenballooned_pages(segs_to_unmap, pages);
>  			segs_to_unmap =3D 0;
>  		}
>  =

> @@ -527,8 +529,8 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				GFP_KERNEL);
>  			if (!persistent_gnt)
>  				return -ENOMEM;
> -			persistent_gnt->page =3D alloc_page(GFP_KERNEL);
> -			if (!persistent_gnt->page) {
> +			if (alloc_xenballooned_pages(1, &persistent_gnt->page,
> +			    false)) {
>  				kfree(persistent_gnt);
>  				return -ENOMEM;
>  			}
> -- =

> 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 Thu Feb 14 13:33:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:33: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 1U5yvo-0000XX-9S; Thu, 14 Feb 2013 13:32:56 +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 1U5yvm-0000XS-Pp
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:32:55 +0000
Received: from [85.158.138.51:17856] by server-13.bemta-3.messagelabs.com id
	0F/EC-20653-187EC115; Thu, 14 Feb 2013 13:32:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360848755!27529043!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzM4MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30507 invoked from network); 14 Feb 2013 13:32:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 13:32:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EDWPeU032495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 13:32:26 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
	r1EDWNTJ016403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 13:32:23 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
	r1EDWMno018675; Thu, 14 Feb 2013 07:32:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 05:32:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBB4E1C387B; Thu, 14 Feb 2013 08:32:20 -0500 (EST)
Date: Thu, 14 Feb 2013 08:32:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130214133220.GE2506@phenom.dumpdata.com>
References: <49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca>
	<20121218221749.GA6332@phenom.dumpdata.com>
	<AF146C82-5904-480C-80D0-7906AFD2B614@gridcentric.ca>
	<20130111160314.GD15353@phenom.dumpdata.com>
	<F2749668-D894-4DBA-BC48-D5CE8180C27F@gridcentric.ca>
	<20130111190814.GD29020@phenom.dumpdata.com>
	<20130117151631.GF19975@ocelot.phlegethon.org>
	<20130118214542.GB3047@phenom.dumpdata.com>
	<20130121102923.GA72616@ocelot.phlegethon.org>
	<20130212155410.GG3016@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130212155410.GG3016@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 12, 2013 at 10:54:10AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 21, 2013 at 10:29:23AM +0000, Tim Deegan wrote:
> > At 16:45 -0500 on 18 Jan (1358527542), Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 17, 2013 at 03:16:31PM +0000, Tim Deegan wrote:
> > > > At 14:08 -0500 on 11 Jan (1357913294), Konrad Rzeszutek Wilk wrote:
> > > > > But the solution to the hypercall failing are multiple - one is to 
> > > > > try to "squeeze" all the guests to make space
> > > > 
> > > > AFAICT if the toolstack can squeeze guests up to make room then the
> > > > reservation hypercall isn't necessary -- just use the squeezing
> > > > mechanism to make sure that running VMs don't use up the memory you want
> > > > for building new ones.
> > > 
> > > We might want to not do that until we have run out of options (this would
> > > be a toolstack option to select the right choice). The other option is
> > > to just launch the guest on another node.
> > 
> > Sure, I see that; but what I meant was: the reservation hypercall only
> > makes any kind of sense if the toolstack can't squeeze the existing guests. 
> 
> OK. I am going to take the liberty here to assume that squeeze is setting
> d->max_pages and kicking the guest to balloon down to some number.
> 
> > 
> > If it can squeeze VMs, as part of that it must have some mechanism to
> > stop them from immediately re-allocating all the memory as it frees it.
> > So in the case where enough memory is already free, you just use that
> > mechanism to protect it while you build the new VM.
> 
> Sure.
> > 
> > Or (since I get the impression that losing this allocation race is a
> > rare event) you can take the optimistic route: after you've checked that
> > enough memory is free, just start building the VM.  If you run out of
> > memory part-way through, you can squeeze the other VMs back out so you can
> > finish the job.
> 
> All of this revolves around 'squeezing' the existing guests from the
> tool-stack side. And as such the options you enumerated are the right
> way of fixing it. And also the ways Xapi are pretty good.
> 
> However that is not the problem we are trying to address. We do _not_ want
> to squeeze the guest at all. We want to leave it up to the guest to
> go and down as it sees fit. We just need to set the ceiling (at start
> time, and this is d->max_pages), and let the guest increment/decrement
> d->tot_pages as it sees fit. And while that is going on, still be able
> to create new guests in parallel.

When I was mulling this over today it dawned on me that I think you
(and Ian) are saying something along these lines: that the claim
hypercall is a piece of this - the fallback mechanism of properly ballooning
("squeezing") should also be implemented - so that this is a full fledged
solution.

In other words - the hypervisor patch _and_ a toolstack logic ought to
be done/consider.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:33:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:33: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 1U5yvo-0000XX-9S; Thu, 14 Feb 2013 13:32:56 +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 1U5yvm-0000XS-Pp
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:32:55 +0000
Received: from [85.158.138.51:17856] by server-13.bemta-3.messagelabs.com id
	0F/EC-20653-187EC115; Thu, 14 Feb 2013 13:32:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360848755!27529043!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzM4MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30507 invoked from network); 14 Feb 2013 13:32:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 13:32:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EDWPeU032495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 13:32:26 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
	r1EDWNTJ016403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 13:32:23 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
	r1EDWMno018675; Thu, 14 Feb 2013 07:32:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 05:32:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBB4E1C387B; Thu, 14 Feb 2013 08:32:20 -0500 (EST)
Date: Thu, 14 Feb 2013 08:32:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130214133220.GE2506@phenom.dumpdata.com>
References: <49049C00-89CA-4B43-9660-83B9ADC061E0@gridcentric.ca>
	<20121218221749.GA6332@phenom.dumpdata.com>
	<AF146C82-5904-480C-80D0-7906AFD2B614@gridcentric.ca>
	<20130111160314.GD15353@phenom.dumpdata.com>
	<F2749668-D894-4DBA-BC48-D5CE8180C27F@gridcentric.ca>
	<20130111190814.GD29020@phenom.dumpdata.com>
	<20130117151631.GF19975@ocelot.phlegethon.org>
	<20130118214542.GB3047@phenom.dumpdata.com>
	<20130121102923.GA72616@ocelot.phlegethon.org>
	<20130212155410.GG3016@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130212155410.GG3016@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of
 problem and alternate solutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 12, 2013 at 10:54:10AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 21, 2013 at 10:29:23AM +0000, Tim Deegan wrote:
> > At 16:45 -0500 on 18 Jan (1358527542), Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 17, 2013 at 03:16:31PM +0000, Tim Deegan wrote:
> > > > At 14:08 -0500 on 11 Jan (1357913294), Konrad Rzeszutek Wilk wrote:
> > > > > But the solution to the hypercall failing are multiple - one is to 
> > > > > try to "squeeze" all the guests to make space
> > > > 
> > > > AFAICT if the toolstack can squeeze guests up to make room then the
> > > > reservation hypercall isn't necessary -- just use the squeezing
> > > > mechanism to make sure that running VMs don't use up the memory you want
> > > > for building new ones.
> > > 
> > > We might want to not do that until we have run out of options (this would
> > > be a toolstack option to select the right choice). The other option is
> > > to just launch the guest on another node.
> > 
> > Sure, I see that; but what I meant was: the reservation hypercall only
> > makes any kind of sense if the toolstack can't squeeze the existing guests. 
> 
> OK. I am going to take the liberty here to assume that squeeze is setting
> d->max_pages and kicking the guest to balloon down to some number.
> 
> > 
> > If it can squeeze VMs, as part of that it must have some mechanism to
> > stop them from immediately re-allocating all the memory as it frees it.
> > So in the case where enough memory is already free, you just use that
> > mechanism to protect it while you build the new VM.
> 
> Sure.
> > 
> > Or (since I get the impression that losing this allocation race is a
> > rare event) you can take the optimistic route: after you've checked that
> > enough memory is free, just start building the VM.  If you run out of
> > memory part-way through, you can squeeze the other VMs back out so you can
> > finish the job.
> 
> All of this revolves around 'squeezing' the existing guests from the
> tool-stack side. And as such the options you enumerated are the right
> way of fixing it. And also the ways Xapi are pretty good.
> 
> However that is not the problem we are trying to address. We do _not_ want
> to squeeze the guest at all. We want to leave it up to the guest to
> go and down as it sees fit. We just need to set the ceiling (at start
> time, and this is d->max_pages), and let the guest increment/decrement
> d->tot_pages as it sees fit. And while that is going on, still be able
> to create new guests in parallel.

When I was mulling this over today it dawned on me that I think you
(and Ian) are saying something along these lines: that the claim
hypercall is a piece of this - the fallback mechanism of properly ballooning
("squeezing") should also be implemented - so that this is a full fledged
solution.

In other words - the hypervisor patch _and_ a toolstack logic ought to
be done/consider.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:36:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:36: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 1U5yz4-0000hj-1C; Thu, 14 Feb 2013 13:36:18 +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 1U5yz2-0000gt-VF
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:36:17 +0000
Received: from [193.109.254.147:20887] by server-4.bemta-14.messagelabs.com id
	52/EF-20719-058EC115; Thu, 14 Feb 2013 13:36:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360848975!10319015!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24994 invoked from network); 14 Feb 2013 13:36:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:36:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1461585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:36: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.297.1;
	Thu, 14 Feb 2013 13:36:15 +0000
Message-ID: <1360848973.20449.369.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 13:36:13 +0000
In-Reply-To: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
 destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 13:18 +0000, Vasiliy Tolstov wrote:
> Hello!. How can i use @releaseDomain from dom0 to subscribe for domain
> destruction?
> I'm try to add watch for @releaseDomain path with token equal of
> needed domain id. But when another domain dies, i get domain that i
> provide via token to xs_watch.

The token is an opaque cookie which xenstore simply echoes back at you
so you can identify which of your watches is firing if you have more
than one. It doesn't have any meaning other than that.

> Is that possible to get id of domain what released from xenstore?

Not directly, @releaseDomain just tells you that *a* domain died, you
need to check if it was the one which interested you.

libxl has some infrastructure for maintaining this state and firing
events on specific domain death. depending on your use case this may or
may not be overkill for your application.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:36:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:36: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 1U5yz4-0000hj-1C; Thu, 14 Feb 2013 13:36:18 +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 1U5yz2-0000gt-VF
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:36:17 +0000
Received: from [193.109.254.147:20887] by server-4.bemta-14.messagelabs.com id
	52/EF-20719-058EC115; Thu, 14 Feb 2013 13:36:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360848975!10319015!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24994 invoked from network); 14 Feb 2013 13:36:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:36:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1461585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:36: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.297.1;
	Thu, 14 Feb 2013 13:36:15 +0000
Message-ID: <1360848973.20449.369.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 13:36:13 +0000
In-Reply-To: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
 destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 13:18 +0000, Vasiliy Tolstov wrote:
> Hello!. How can i use @releaseDomain from dom0 to subscribe for domain
> destruction?
> I'm try to add watch for @releaseDomain path with token equal of
> needed domain id. But when another domain dies, i get domain that i
> provide via token to xs_watch.

The token is an opaque cookie which xenstore simply echoes back at you
so you can identify which of your watches is firing if you have more
than one. It doesn't have any meaning other than that.

> Is that possible to get id of domain what released from xenstore?

Not directly, @releaseDomain just tells you that *a* domain died, you
need to check if it was the one which interested you.

libxl has some infrastructure for maintaining this state and firing
events on specific domain death. depending on your use case this may or
may not be overkill for your application.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:38:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5z1A-0000pM-Ib; Thu, 14 Feb 2013 13:38: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 1U5z18-0000pE-He
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:38:26 +0000
Received: from [85.158.143.99:58739] by server-1.bemta-4.messagelabs.com id
	4F/9B-08839-1D8EC115; Thu, 14 Feb 2013 13:38:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360849104!20001412!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29320 invoked from network); 14 Feb 2013 13:38:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1461647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:38: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.297.1;
	Thu, 14 Feb 2013 13:38:24 +0000
Message-ID: <1360849103.20449.371.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 13:38:23 +0000
In-Reply-To: <20130214131041.GR83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 25/45] xen: arm: separate guest user regs
 from internal guest 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 Thu, 2013-02-14 at 13:10 +0000, Tim Deegan wrote:
> So this ends up with two different layouts for core regs, one public and
> one private, both of which have the padding/unions to allow 64-bit and
> 32-bit to coexist.  Can we really not re-use them?

The 32-bit internal version doesn't have padding because that makes
entry.S hellish, and wastes a bunch of hypervisor memory.

> 
> At 15:56 +0000 on 23 Jan (1358956591), Ian Campbell wrote:
> > +#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> > +# ifdef __aarch64__
> > +/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> > +#   define __DECL_REG(n64, n32) union {          \
> > +        uint64_t n64;                            \
> > +        uint32_t n32;                            \
> > +    }
> > +# else
> > +/*
> > + * Include a 64-bit padding field so that the layout is the same
> > + * between 32- and 64-bit hypervisors.
> > + */
> > +#   define __DECL_REG(n64, n32) union {          \
> > +        uint64_t __pad_##n64;                    \
> > +        uint32_t n32;                            \
> > +    }
> > +# endif
> 
> On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
> allow that on arm64 as well, so I'm not sureethe __pad prefix is useful.

Yes, we absolutely should support this, I'd forgotten about it when I
wrote this...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:38:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5z1A-0000pM-Ib; Thu, 14 Feb 2013 13:38: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 1U5z18-0000pE-He
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:38:26 +0000
Received: from [85.158.143.99:58739] by server-1.bemta-4.messagelabs.com id
	4F/9B-08839-1D8EC115; Thu, 14 Feb 2013 13:38:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360849104!20001412!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29320 invoked from network); 14 Feb 2013 13:38:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1461647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:38: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.297.1;
	Thu, 14 Feb 2013 13:38:24 +0000
Message-ID: <1360849103.20449.371.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 13:38:23 +0000
In-Reply-To: <20130214131041.GR83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 25/45] xen: arm: separate guest user regs
 from internal guest 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 Thu, 2013-02-14 at 13:10 +0000, Tim Deegan wrote:
> So this ends up with two different layouts for core regs, one public and
> one private, both of which have the padding/unions to allow 64-bit and
> 32-bit to coexist.  Can we really not re-use them?

The 32-bit internal version doesn't have padding because that makes
entry.S hellish, and wastes a bunch of hypervisor memory.

> 
> At 15:56 +0000 on 23 Jan (1358956591), Ian Campbell wrote:
> > +#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> > +# ifdef __aarch64__
> > +/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> > +#   define __DECL_REG(n64, n32) union {          \
> > +        uint64_t n64;                            \
> > +        uint32_t n32;                            \
> > +    }
> > +# else
> > +/*
> > + * Include a 64-bit padding field so that the layout is the same
> > + * between 32- and 64-bit hypervisors.
> > + */
> > +#   define __DECL_REG(n64, n32) union {          \
> > +        uint64_t __pad_##n64;                    \
> > +        uint32_t n32;                            \
> > +    }
> > +# endif
> 
> On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
> allow that on arm64 as well, so I'm not sureethe __pad prefix is useful.

Yes, we absolutely should support this, I'd forgotten about it when I
wrote this...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:41:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5z3o-000108-94; Thu, 14 Feb 2013 13:41:12 +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 1U5z3m-000101-S7
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:41:10 +0000
Received: from [85.158.138.51:34555] by server-9.bemta-3.messagelabs.com id
	2A/A0-09484-179EC115; Thu, 14 Feb 2013 13:41:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360849263!27534405!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9568 invoked from network); 14 Feb 2013 13:41:04 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:41:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5z3f-000MSQ-8B; Thu, 14 Feb 2013 13:41:03 +0000
Date: Thu, 14 Feb 2013 13:41:03 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130214134103.GS83752@ocelot.phlegethon.org>
References: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
	<511CF23502000078000BE414@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511CF23502000078000BE414@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86: explicit suffix in inline assembler
	(for 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

At 13:18 +0000 on 14 Feb (1360847909), Jan Beulich wrote:
> >>> On 14.02.13 at 13:52, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1360846113 0
> > # Node ID 500907997cb7b9c6973147d56cfd8a1a4c136c7e
> > # Parent  4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
> > x86: explicit suffix in inline assembler (for clang).
> > 
> > This fixes the clang build, and has no effect on gcc's output.
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r 4b01cc2c2c1f -r 500907997cb7 xen/arch/x86/time.c
> > --- a/xen/arch/x86/time.c	Thu Feb 14 12:36:01 2013 +0000
> > +++ b/xen/arch/x86/time.c	Thu Feb 14 12:48:33 2013 +0000
> > @@ -127,7 +127,7 @@ static inline u64 scale_delta(u64 delta,
> >          delta <<= scale->shift;
> >  
> >      asm (
> > -        "mul %2 ; shrd $32,%1,%0"
> > +        "mulq %2 ; shrd $32,%1,%0"
> >          : "=a" (product), "=d" (delta)
> >          : "rm" (delta), "0" ((u64)scale->mul_frac) );
> >  
> 
> I'll commit this as being benign, but what the heck? "mul" needs
> a suffix but "shrd" doesn't?

Quite.  I presume it's because mul's first operand is implicit (and for
some reason clang doesn't see the second operand being a u64 as enough
to require the 64-bit version).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:41:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5z3o-000108-94; Thu, 14 Feb 2013 13:41:12 +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 1U5z3m-000101-S7
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:41:10 +0000
Received: from [85.158.138.51:34555] by server-9.bemta-3.messagelabs.com id
	2A/A0-09484-179EC115; Thu, 14 Feb 2013 13:41:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360849263!27534405!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9568 invoked from network); 14 Feb 2013 13:41:04 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:41:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5z3f-000MSQ-8B; Thu, 14 Feb 2013 13:41:03 +0000
Date: Thu, 14 Feb 2013 13:41:03 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130214134103.GS83752@ocelot.phlegethon.org>
References: <500907997cb7b9c69731.1360846324@whitby.uk.xensource.com>
	<511CF23502000078000BE414@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511CF23502000078000BE414@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86: explicit suffix in inline assembler
	(for 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

At 13:18 +0000 on 14 Feb (1360847909), Jan Beulich wrote:
> >>> On 14.02.13 at 13:52, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1360846113 0
> > # Node ID 500907997cb7b9c6973147d56cfd8a1a4c136c7e
> > # Parent  4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
> > x86: explicit suffix in inline assembler (for clang).
> > 
> > This fixes the clang build, and has no effect on gcc's output.
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r 4b01cc2c2c1f -r 500907997cb7 xen/arch/x86/time.c
> > --- a/xen/arch/x86/time.c	Thu Feb 14 12:36:01 2013 +0000
> > +++ b/xen/arch/x86/time.c	Thu Feb 14 12:48:33 2013 +0000
> > @@ -127,7 +127,7 @@ static inline u64 scale_delta(u64 delta,
> >          delta <<= scale->shift;
> >  
> >      asm (
> > -        "mul %2 ; shrd $32,%1,%0"
> > +        "mulq %2 ; shrd $32,%1,%0"
> >          : "=a" (product), "=d" (delta)
> >          : "rm" (delta), "0" ((u64)scale->mul_frac) );
> >  
> 
> I'll commit this as being benign, but what the heck? "mul" needs
> a suffix but "shrd" doesn't?

Quite.  I presume it's because mul's first operand is implicit (and for
some reason clang doesn't see the second operand being a u64 as enough
to require the 64-bit version).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:43:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:43: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 1U5z5h-00017i-QI; Thu, 14 Feb 2013 13:43: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 1U5z5g-00017V-1a
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:43:08 +0000
Received: from [85.158.143.99:28145] by server-3.bemta-4.messagelabs.com id
	ED/E5-08920-BE9EC115; Thu, 14 Feb 2013 13:43:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360849386!20002316!1
X-Originating-IP: [74.125.82.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20623 invoked from network); 14 Feb 2013 13:43:06 -0000
Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com)
	(74.125.82.174)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:43:06 -0000
Received: by mail-we0-f174.google.com with SMTP id r6so1951999wey.5
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:43:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=goR4fykeYiOOA4vcpmzW7TTibhmXXyBo6kmZ/iVs6ZY=;
	b=zacSmGnyGd9hcBWHMOUXJ5sfMO5eeUraaYDHk9gYk6dmtB8NexUKXd/bYShHoERg2I
	kGoR4/x7c8k9Zl7GVzBo87zYUIrEK1bRi9cIsKhmogZaDu6x0i6Q7yAG5iOh7gRD094K
	VmXix9WBU09CNcBhCRl/7zN4O6Hl81RrXOyzpFgk5KrDZed9Oyb9cGTkUbb/mpZIPn0w
	kGVEG1YiLOUYi+B3HDZB746rur5XUrkMOuvMH19iki4yfv2cXVllAGRxlER/Ze97OWve
	9SonIYXY8odV7PRjY8iBDIS6/Wp1S0wufPNOjbpfcwgDTq7vu2ZRqs6PsvzTVvCAXBJd
	Wvmw==
X-Received: by 10.194.235.6 with SMTP id ui6mr45708989wjc.12.1360849386175;
	Thu, 14 Feb 2013 05:43:06 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id o13sm43226936wie.10.2013.02.14.05.43.02
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 05:43:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 13:42:58 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CD429A62.5AE4C%keir@xen.org>
Thread-Topic: [PATCH v3] hvm: Allow triple fault to imply crash rather than
	reboot
Thread-Index: Ac4KuTLt+5XBLUeVaEu2NaxAUgNFmQ==
In-Reply-To: <dc98663be34ec7399d73.1360846842@andrewcoop.uk.xensource.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v3] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/2013 13:00, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods.  As a result, the most likely cause of a triple fault is a
> fatal software bug.
> 
> This patch allows the toolstack to indicate that a triple fault should mean a
> crash rather than a reboot.  The default of reboot still remains the same.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> --
> Changes since v2:
>  * Allow any SHUTDOWN_* values to be set
> Changes since v1:
>  * "reboot" -> "reset"
>  * v->domain -> d
> 
> diff -r 63594ce1708f -r dc98663be34e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -540,6 +540,7 @@ int hvm_domain_initialise(struct domain
>      hvm_init_guest_time(d);
>  
>      d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
> +    d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] =
> SHUTDOWN_reboot;
>  
>      hvm_init_cacheattr_region_list(d);
>  
> @@ -1244,9 +1245,13 @@ void hvm_hlt(unsigned long rflags)
>  void hvm_triple_fault(void)
>  {
>      struct vcpu *v = current;
> +    struct domain *d = v->domain;
> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON];
> +
>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
> -             "invoking HVM system reset.\n", v->vcpu_id);
> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
> +             "invoking HVM shutdown action %"PRIu8".\n",
> +             v->vcpu_id, reason);
> +    domain_shutdown(d, reason);
>  }
>  
>  void hvm_inject_trap(struct hvm_trap *trap)
> @@ -3929,6 +3934,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
>              case HVM_PARAM_BUFIOREQ_EVTCHN:
>                  rc = -EINVAL;
>                  break;
> +            case HVM_PARAM_TRIPLE_FAULT_REASON:
> +                if ( a.value > SHUTDOWN_MAX )
> +                    rc = -EINVAL;
> +                break;
>              }
>  
>              if ( rc == 0 )
> diff -r 63594ce1708f -r dc98663be34e xen/include/public/hvm/params.h
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -142,6 +142,9 @@
>  #define HVM_PARAM_ACCESS_RING_PFN   28
>  #define HVM_PARAM_SHARING_RING_PFN  29
>  
> -#define HVM_NR_PARAMS          31
> +/* SHUTDOWN_* action in case of a triple fault */
> +#define HVM_PARAM_TRIPLE_FAULT_REASON 31
> +
> +#define HVM_NR_PARAMS          32
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> diff -r 63594ce1708f -r dc98663be34e xen/include/public/sched.h
> --- a/xen/include/public/sched.h
> +++ b/xen/include/public/sched.h
> @@ -158,6 +158,7 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t
>  #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.
> */
>  #define SHUTDOWN_crash      3  /* Tell controller we've crashed.
> */
>  #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.
> */
> +#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.
> */
>  /* ` } */
>  
>  #endif /* __XEN_PUBLIC_SCHED_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:43:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:43: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 1U5z5h-00017i-QI; Thu, 14 Feb 2013 13:43: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 1U5z5g-00017V-1a
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:43:08 +0000
Received: from [85.158.143.99:28145] by server-3.bemta-4.messagelabs.com id
	ED/E5-08920-BE9EC115; Thu, 14 Feb 2013 13:43:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360849386!20002316!1
X-Originating-IP: [74.125.82.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20623 invoked from network); 14 Feb 2013 13:43:06 -0000
Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com)
	(74.125.82.174)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:43:06 -0000
Received: by mail-we0-f174.google.com with SMTP id r6so1951999wey.5
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:43:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=goR4fykeYiOOA4vcpmzW7TTibhmXXyBo6kmZ/iVs6ZY=;
	b=zacSmGnyGd9hcBWHMOUXJ5sfMO5eeUraaYDHk9gYk6dmtB8NexUKXd/bYShHoERg2I
	kGoR4/x7c8k9Zl7GVzBo87zYUIrEK1bRi9cIsKhmogZaDu6x0i6Q7yAG5iOh7gRD094K
	VmXix9WBU09CNcBhCRl/7zN4O6Hl81RrXOyzpFgk5KrDZed9Oyb9cGTkUbb/mpZIPn0w
	kGVEG1YiLOUYi+B3HDZB746rur5XUrkMOuvMH19iki4yfv2cXVllAGRxlER/Ze97OWve
	9SonIYXY8odV7PRjY8iBDIS6/Wp1S0wufPNOjbpfcwgDTq7vu2ZRqs6PsvzTVvCAXBJd
	Wvmw==
X-Received: by 10.194.235.6 with SMTP id ui6mr45708989wjc.12.1360849386175;
	Thu, 14 Feb 2013 05:43:06 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id o13sm43226936wie.10.2013.02.14.05.43.02
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 05:43:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 13:42:58 +0000
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CD429A62.5AE4C%keir@xen.org>
Thread-Topic: [PATCH v3] hvm: Allow triple fault to imply crash rather than
	reboot
Thread-Index: Ac4KuTLt+5XBLUeVaEu2NaxAUgNFmQ==
In-Reply-To: <dc98663be34ec7399d73.1360846842@andrewcoop.uk.xensource.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v3] hvm: Allow triple fault to imply crash
 rather than reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/2013 13:00, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods.  As a result, the most likely cause of a triple fault is a
> fatal software bug.
> 
> This patch allows the toolstack to indicate that a triple fault should mean a
> crash rather than a reboot.  The default of reboot still remains the same.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> --
> Changes since v2:
>  * Allow any SHUTDOWN_* values to be set
> Changes since v1:
>  * "reboot" -> "reset"
>  * v->domain -> d
> 
> diff -r 63594ce1708f -r dc98663be34e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -540,6 +540,7 @@ int hvm_domain_initialise(struct domain
>      hvm_init_guest_time(d);
>  
>      d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
> +    d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] =
> SHUTDOWN_reboot;
>  
>      hvm_init_cacheattr_region_list(d);
>  
> @@ -1244,9 +1245,13 @@ void hvm_hlt(unsigned long rflags)
>  void hvm_triple_fault(void)
>  {
>      struct vcpu *v = current;
> +    struct domain *d = v->domain;
> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON];
> +
>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
> -             "invoking HVM system reset.\n", v->vcpu_id);
> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
> +             "invoking HVM shutdown action %"PRIu8".\n",
> +             v->vcpu_id, reason);
> +    domain_shutdown(d, reason);
>  }
>  
>  void hvm_inject_trap(struct hvm_trap *trap)
> @@ -3929,6 +3934,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
>              case HVM_PARAM_BUFIOREQ_EVTCHN:
>                  rc = -EINVAL;
>                  break;
> +            case HVM_PARAM_TRIPLE_FAULT_REASON:
> +                if ( a.value > SHUTDOWN_MAX )
> +                    rc = -EINVAL;
> +                break;
>              }
>  
>              if ( rc == 0 )
> diff -r 63594ce1708f -r dc98663be34e xen/include/public/hvm/params.h
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -142,6 +142,9 @@
>  #define HVM_PARAM_ACCESS_RING_PFN   28
>  #define HVM_PARAM_SHARING_RING_PFN  29
>  
> -#define HVM_NR_PARAMS          31
> +/* SHUTDOWN_* action in case of a triple fault */
> +#define HVM_PARAM_TRIPLE_FAULT_REASON 31
> +
> +#define HVM_NR_PARAMS          32
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> diff -r 63594ce1708f -r dc98663be34e xen/include/public/sched.h
> --- a/xen/include/public/sched.h
> +++ b/xen/include/public/sched.h
> @@ -158,6 +158,7 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t
>  #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.
> */
>  #define SHUTDOWN_crash      3  /* Tell controller we've crashed.
> */
>  #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.
> */
> +#define SHUTDOWN_MAX        4  /* Maximum valid shutdown reason.
> */
>  /* ` } */
>  
>  #endif /* __XEN_PUBLIC_SCHED_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:45:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:45: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 1U5z8C-0001I8-CB; Thu, 14 Feb 2013 13:45:44 +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 1U5z8A-0001Hw-QN
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:45:43 +0000
Received: from [85.158.137.99:37576] by server-3.bemta-3.messagelabs.com id
	BF/41-31070-08AEC115; Thu, 14 Feb 2013 13:45:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360849444!18253116!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21571 invoked from network); 14 Feb 2013 13:44:04 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:44:04 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi8so2747871wib.7
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=yZWW5Kgalz4YHXa6hw2O6MauFBloyrkiQoMsEqUPsv0=;
	b=h5z/QA6fGIxSqC6T4/4bvvOyh0n6VsLXtmzgaDR5jloWZa+G/pF10f7ch4z9NOVMXi
	gfUGOgDNvoCctb/Cw2/Li2zohpQfhrcyoiqUylR1bX/nbQo1xh75fdNRjB+u7HNE6Xfh
	ACfHj+17UZSffwXKxnIXC2r2y17Vgm3gg41ulrRYI5oWszLPPgkfB29IfKV5ytb4QAeN
	zkUAq+VKOAqkURtMAy/u9ln4MWIuMQU3QhP7IR/wkeqXiYaRcHm9NoLFqhDkIYkkAoUW
	OCjwtGKtpfIeM/4ff4gg1xXVZGd2TQIZaDONPVdGuD2YfBEf7API0Q1+erfGa6OsFz4K
	ZFCw==
X-Received: by 10.194.156.196 with SMTP id wg4mr45590869wjb.22.1360849444012; 
	Thu, 14 Feb 2013 05:44:04 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id b10sm48344271wix.7.2013.02.14.05.44.01
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 05:44:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 13:43:54 +0000
From: Keir Fraser <keir@xen.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CD429A9A.5AE4E%keir@xen.org>
Thread-Topic: [PATCH] trivial: Optimize printnum
Thread-Index: Ac4KtJdne+qSldmUTOyIiZADxAcX1gABLznR
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458381@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Needs a signed-off-by line, but you can also add my:
Acked-by: Keir Fraser <keir@xen.org>

When you resubmit. I don't know why my reply is mangled as below.

 -- Keir


On 14/02/2013 13:09, "Frediano Ziglio" <frediano.ziglio@citrix.com> wrote:

> 
Reuse the string of hexadecimal numbers to simplify printnum
> implementation
---
 tools/firmware/hvmloader/util.c |   20
> ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff
> --git a/tools/firmware/hvmloader/util.c
> b/tools/firmware/hvmloader/util.c
index d5cd277..741b9c2 100644
---
> a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@
> -315,23 +315,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t
> *ecx, uint32_t *edx)
         : "0" (idx) );
 }
 
+static const char
> hex_digits[] = "0123456789abcdef";
+
 /* Write a two-character hex
> representation of 'byte' to digits[].
    Pre-condition: sizeof(digits) >= 2
> */
 void
 byte_to_hex(char *digits, uint8_t byte)
 {
-    uint8_t nybbel =
> byte >> 4;
-
-    if ( nybbel > 9 )
-        digits[0] = 'a' + nybbel-10;
-
> else
-        digits[0] = '0' + nybbel;
-
-    nybbel = byte & 0x0f;
-    if (
> nybbel > 9 )
-        digits[1] = 'a' + nybbel-10;
-    else
-
> digits[1] = '0' + nybbel;
+    digits[0] = hex_digits[byte >> 4];
+
> digits[1] = hex_digits[byte & 0x0f];
 }
 
 /* Convert an array of 16 unsigned
> bytes to a DCE/OSF formatted UUID
@@ -518,13 +510,13 @@ void
> pci_write(uint32_t devfn, uint32_t reg, uint32_t len, uint32_t val)
     }
 }

> 
-static char *printnum(char *p, unsigned long num, int base)
+static char
> *printnum(char *p, unsigned long num, unsigned base)
 {
     unsigned long n;

> 
     if ( (n = num/base) > 0 )
         p = printnum(p, n, base);
-    *p++ =
> "0123456789abcdef"[(int)(num % base)];
+    *p++ = hex_digits[num % base];

> *p = '\0';
     return p;
 }
-- 
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 Thu Feb 14 13:45:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:45: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 1U5z8C-0001I8-CB; Thu, 14 Feb 2013 13:45:44 +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 1U5z8A-0001Hw-QN
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:45:43 +0000
Received: from [85.158.137.99:37576] by server-3.bemta-3.messagelabs.com id
	BF/41-31070-08AEC115; Thu, 14 Feb 2013 13:45:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360849444!18253116!1
X-Originating-IP: [209.85.212.180]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21571 invoked from network); 14 Feb 2013 13:44:04 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:44:04 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi8so2747871wib.7
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=yZWW5Kgalz4YHXa6hw2O6MauFBloyrkiQoMsEqUPsv0=;
	b=h5z/QA6fGIxSqC6T4/4bvvOyh0n6VsLXtmzgaDR5jloWZa+G/pF10f7ch4z9NOVMXi
	gfUGOgDNvoCctb/Cw2/Li2zohpQfhrcyoiqUylR1bX/nbQo1xh75fdNRjB+u7HNE6Xfh
	ACfHj+17UZSffwXKxnIXC2r2y17Vgm3gg41ulrRYI5oWszLPPgkfB29IfKV5ytb4QAeN
	zkUAq+VKOAqkURtMAy/u9ln4MWIuMQU3QhP7IR/wkeqXiYaRcHm9NoLFqhDkIYkkAoUW
	OCjwtGKtpfIeM/4ff4gg1xXVZGd2TQIZaDONPVdGuD2YfBEf7API0Q1+erfGa6OsFz4K
	ZFCw==
X-Received: by 10.194.156.196 with SMTP id wg4mr45590869wjb.22.1360849444012; 
	Thu, 14 Feb 2013 05:44:04 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id b10sm48344271wix.7.2013.02.14.05.44.01
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 05:44:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 13:43:54 +0000
From: Keir Fraser <keir@xen.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CD429A9A.5AE4E%keir@xen.org>
Thread-Topic: [PATCH] trivial: Optimize printnum
Thread-Index: Ac4KtJdne+qSldmUTOyIiZADxAcX1gABLznR
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458381@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Needs a signed-off-by line, but you can also add my:
Acked-by: Keir Fraser <keir@xen.org>

When you resubmit. I don't know why my reply is mangled as below.

 -- Keir


On 14/02/2013 13:09, "Frediano Ziglio" <frediano.ziglio@citrix.com> wrote:

> 
Reuse the string of hexadecimal numbers to simplify printnum
> implementation
---
 tools/firmware/hvmloader/util.c |   20
> ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff
> --git a/tools/firmware/hvmloader/util.c
> b/tools/firmware/hvmloader/util.c
index d5cd277..741b9c2 100644
---
> a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@
> -315,23 +315,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t
> *ecx, uint32_t *edx)
         : "0" (idx) );
 }
 
+static const char
> hex_digits[] = "0123456789abcdef";
+
 /* Write a two-character hex
> representation of 'byte' to digits[].
    Pre-condition: sizeof(digits) >= 2
> */
 void
 byte_to_hex(char *digits, uint8_t byte)
 {
-    uint8_t nybbel =
> byte >> 4;
-
-    if ( nybbel > 9 )
-        digits[0] = 'a' + nybbel-10;
-
> else
-        digits[0] = '0' + nybbel;
-
-    nybbel = byte & 0x0f;
-    if (
> nybbel > 9 )
-        digits[1] = 'a' + nybbel-10;
-    else
-
> digits[1] = '0' + nybbel;
+    digits[0] = hex_digits[byte >> 4];
+
> digits[1] = hex_digits[byte & 0x0f];
 }
 
 /* Convert an array of 16 unsigned
> bytes to a DCE/OSF formatted UUID
@@ -518,13 +510,13 @@ void
> pci_write(uint32_t devfn, uint32_t reg, uint32_t len, uint32_t val)
     }
 }

> 
-static char *printnum(char *p, unsigned long num, int base)
+static char
> *printnum(char *p, unsigned long num, unsigned base)
 {
     unsigned long n;

> 
     if ( (n = num/base) > 0 )
         p = printnum(p, n, base);
-    *p++ =
> "0123456789abcdef"[(int)(num % base)];
+    *p++ = hex_digits[num % base];

> *p = '\0';
     return p;
 }
-- 
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 Thu Feb 14 13:50:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:50: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 1U5zCV-0001US-3R; Thu, 14 Feb 2013 13:50: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 1U5zCT-0001UM-FV
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:50:09 +0000
Received: from [193.109.254.147:28524] by server-12.bemta-14.messagelabs.com
	id 2D/2A-32582-09BEC115; Thu, 14 Feb 2013 13:50:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360849807!8805048!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5963 invoked from network); 14 Feb 2013 13:50:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:50:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zCQ-000MUK-GA; Thu, 14 Feb 2013 13:50:06 +0000
Date: Thu, 14 Feb 2013 13:50:06 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214135006.GT83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360849103.20449.371.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs
	from internal guest 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

At 13:38 +0000 on 14 Feb (1360849103), Ian Campbell wrote:
> On Thu, 2013-02-14 at 13:10 +0000, Tim Deegan wrote:
> > So this ends up with two different layouts for core regs, one public and
> > one private, both of which have the padding/unions to allow 64-bit and
> > 32-bit to coexist.  Can we really not re-use them?
> 
> The 32-bit internal version doesn't have padding because that makes
> entry.S hellish, and wastes a bunch of hypervisor memory.

Understood - but could the 64-bit on-stack format and the public
interface share some code?  Maybe that's just as ugly as having two
very-similar register structs.  And I guess we'd like to be able to
tinker with the stack format without worrying about the ABI.  So I
withdraw the question. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:50:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:50: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 1U5zCV-0001US-3R; Thu, 14 Feb 2013 13:50: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 1U5zCT-0001UM-FV
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:50:09 +0000
Received: from [193.109.254.147:28524] by server-12.bemta-14.messagelabs.com
	id 2D/2A-32582-09BEC115; Thu, 14 Feb 2013 13:50:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360849807!8805048!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5963 invoked from network); 14 Feb 2013 13:50:07 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 13:50:07 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zCQ-000MUK-GA; Thu, 14 Feb 2013 13:50:06 +0000
Date: Thu, 14 Feb 2013 13:50:06 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214135006.GT83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360849103.20449.371.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs
	from internal guest 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

At 13:38 +0000 on 14 Feb (1360849103), Ian Campbell wrote:
> On Thu, 2013-02-14 at 13:10 +0000, Tim Deegan wrote:
> > So this ends up with two different layouts for core regs, one public and
> > one private, both of which have the padding/unions to allow 64-bit and
> > 32-bit to coexist.  Can we really not re-use them?
> 
> The 32-bit internal version doesn't have padding because that makes
> entry.S hellish, and wastes a bunch of hypervisor memory.

Understood - but could the 64-bit on-stack format and the public
interface share some code?  Maybe that's just as ugly as having two
very-similar register structs.  And I guess we'd like to be able to
tinker with the stack format without worrying about the ABI.  So I
withdraw the question. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:53:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:53: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 1U5zFd-0001gj-Rx; Thu, 14 Feb 2013 13:53:25 +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 1U5zFc-0001gY-CD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:53:24 +0000
Received: from [85.158.139.83:26709] by server-10.bemta-5.messagelabs.com id
	D8/77-04697-35CEC115; Thu, 14 Feb 2013 13:53:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360850000!27102377!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7390 invoked from network); 14 Feb 2013 13:53:22 -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;
	14 Feb 2013 13:53:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7127709"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:53:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:53:20 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5zFX-0006ei-U9;
	Thu, 14 Feb 2013 13:53:19 +0000
Message-ID: <1360849999.16636.135.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 13:53:19 +0000
In-Reply-To: <1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If the credit timer is left armed after calling
> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> the vif which will then oops as vif->netbk == NULL.
> 
> This may happen both in the fatal error path and during normal
> disconnection from the front end.
> 
> The sequencing during shutdown is critical to ensure that: a)
> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> is not freed.
> 
> 1. Mark as unschedulable (netif_carrier_off()).
> 2. Synchronously cancel the timer.
> 3. Remove the vif from the schedule list.
> 4. Remove it from it netback thread group.
> 5. Wait for vif->refcnt to become 0.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

You would need to reinitialize the timer in xenvif_up, given that user
might `ifconfig vifX.X down; ifconfig vifX.X up`.

Another less desired but simpler fix would be leave the timer alone but
check for vif->netbk != NULL in the timer callback.


Wei.

> ---
>  drivers/net/xen-netback/interface.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b8c5193..221f426 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
>  static void xenvif_down(struct xenvif *vif)
>  {
>  	disable_irq(vif->irq);
> +	del_timer_sync(&vif->credit_timeout);
>  	xen_netbk_deschedule_xenvif(vif);
>  	xen_netbk_remove_xenvif(vif);
>  }
> @@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
>  	atomic_dec(&vif->refcnt);
>  	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
>  
> -	del_timer_sync(&vif->credit_timeout);
> -
>  	if (vif->irq)
>  		unbind_from_irqhandler(vif->irq, vif);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:53:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:53: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 1U5zFd-0001gj-Rx; Thu, 14 Feb 2013 13:53:25 +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 1U5zFc-0001gY-CD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:53:24 +0000
Received: from [85.158.139.83:26709] by server-10.bemta-5.messagelabs.com id
	D8/77-04697-35CEC115; Thu, 14 Feb 2013 13:53:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360850000!27102377!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7390 invoked from network); 14 Feb 2013 13:53:22 -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;
	14 Feb 2013 13:53:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7127709"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:53:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:53:20 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5zFX-0006ei-U9;
	Thu, 14 Feb 2013 13:53:19 +0000
Message-ID: <1360849999.16636.135.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 13:53:19 +0000
In-Reply-To: <1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If the credit timer is left armed after calling
> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> the vif which will then oops as vif->netbk == NULL.
> 
> This may happen both in the fatal error path and during normal
> disconnection from the front end.
> 
> The sequencing during shutdown is critical to ensure that: a)
> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> is not freed.
> 
> 1. Mark as unschedulable (netif_carrier_off()).
> 2. Synchronously cancel the timer.
> 3. Remove the vif from the schedule list.
> 4. Remove it from it netback thread group.
> 5. Wait for vif->refcnt to become 0.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

You would need to reinitialize the timer in xenvif_up, given that user
might `ifconfig vifX.X down; ifconfig vifX.X up`.

Another less desired but simpler fix would be leave the timer alone but
check for vif->netbk != NULL in the timer callback.


Wei.

> ---
>  drivers/net/xen-netback/interface.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b8c5193..221f426 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
>  static void xenvif_down(struct xenvif *vif)
>  {
>  	disable_irq(vif->irq);
> +	del_timer_sync(&vif->credit_timeout);
>  	xen_netbk_deschedule_xenvif(vif);
>  	xen_netbk_remove_xenvif(vif);
>  }
> @@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
>  	atomic_dec(&vif->refcnt);
>  	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
>  
> -	del_timer_sync(&vif->credit_timeout);
> -
>  	if (vif->irq)
>  		unbind_from_irqhandler(vif->irq, vif);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:54:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zGl-0001m2-Bl; Thu, 14 Feb 2013 13:54:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5zGj-0001lq-BK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:54:33 +0000
Received: from [85.158.139.83:61350] by server-3.bemta-5.messagelabs.com id
	5C/B1-07037-89CEC115; Thu, 14 Feb 2013 13:54:32 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360850071!31442694!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2059 invoked from network); 14 Feb 2013 13:54:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1462327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:54:31 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 14 Feb 2013
	13:54:31 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 13:54:31 +0000
Thread-Topic: [PATCH] trivial: Optimize printnum
Thread-Index: Ac4KutCpaRySNLyjSyGTmhqWVq0j7Q==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458383@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Reuse the string of hexadecimal numbers to simplify printnum implementation

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
---
 tools/firmware/hvmloader/util.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d5cd277..741b9c2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -315,23 +315,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
         : "0" (idx) );
 }
 
+static const char hex_digits[] = "0123456789abcdef";
+
 /* Write a two-character hex representation of 'byte' to digits[].
    Pre-condition: sizeof(digits) >= 2 */
 void
 byte_to_hex(char *digits, uint8_t byte)
 {
-    uint8_t nybbel = byte >> 4;
-
-    if ( nybbel > 9 )
-        digits[0] = 'a' + nybbel-10;
-    else
-        digits[0] = '0' + nybbel;
-
-    nybbel = byte & 0x0f;
-    if ( nybbel > 9 )
-        digits[1] = 'a' + nybbel-10;
-    else
-        digits[1] = '0' + nybbel;
+    digits[0] = hex_digits[byte >> 4];
+    digits[1] = hex_digits[byte & 0x0f];
 }
 
 /* Convert an array of 16 unsigned bytes to a DCE/OSF formatted UUID
@@ -518,13 +510,13 @@ void pci_write(uint32_t devfn, uint32_t reg, uint32_t len, uint32_t val)
     }
 }
 
-static char *printnum(char *p, unsigned long num, int base)
+static char *printnum(char *p, unsigned long num, unsigned base)
 {
     unsigned long n;
 
     if ( (n = num/base) > 0 )
         p = printnum(p, n, base);
-    *p++ = "0123456789abcdef"[(int)(num % base)];
+    *p++ = hex_digits[num % base];
     *p = '\0';
     return p;
 }
-- 
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 Thu Feb 14 13:54:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zGl-0001m2-Bl; Thu, 14 Feb 2013 13:54:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5zGj-0001lq-BK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:54:33 +0000
Received: from [85.158.139.83:61350] by server-3.bemta-5.messagelabs.com id
	5C/B1-07037-89CEC115; Thu, 14 Feb 2013 13:54:32 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360850071!31442694!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2059 invoked from network); 14 Feb 2013 13:54:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1462327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13:54:31 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 14 Feb 2013
	13:54:31 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 13:54:31 +0000
Thread-Topic: [PATCH] trivial: Optimize printnum
Thread-Index: Ac4KutCpaRySNLyjSyGTmhqWVq0j7Q==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458383@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Reuse the string of hexadecimal numbers to simplify printnum implementation

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
---
 tools/firmware/hvmloader/util.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d5cd277..741b9c2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -315,23 +315,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
         : "0" (idx) );
 }
 
+static const char hex_digits[] = "0123456789abcdef";
+
 /* Write a two-character hex representation of 'byte' to digits[].
    Pre-condition: sizeof(digits) >= 2 */
 void
 byte_to_hex(char *digits, uint8_t byte)
 {
-    uint8_t nybbel = byte >> 4;
-
-    if ( nybbel > 9 )
-        digits[0] = 'a' + nybbel-10;
-    else
-        digits[0] = '0' + nybbel;
-
-    nybbel = byte & 0x0f;
-    if ( nybbel > 9 )
-        digits[1] = 'a' + nybbel-10;
-    else
-        digits[1] = '0' + nybbel;
+    digits[0] = hex_digits[byte >> 4];
+    digits[1] = hex_digits[byte & 0x0f];
 }
 
 /* Convert an array of 16 unsigned bytes to a DCE/OSF formatted UUID
@@ -518,13 +510,13 @@ void pci_write(uint32_t devfn, uint32_t reg, uint32_t len, uint32_t val)
     }
 }
 
-static char *printnum(char *p, unsigned long num, int base)
+static char *printnum(char *p, unsigned long num, unsigned base)
 {
     unsigned long n;
 
     if ( (n = num/base) > 0 )
         p = printnum(p, n, base);
-    *p++ = "0123456789abcdef"[(int)(num % base)];
+    *p++ = hex_digits[num % base];
     *p = '\0';
     return p;
 }
-- 
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 Thu Feb 14 13:56:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zIb-0001vX-SN; Thu, 14 Feb 2013 13:56:29 +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 1U5zIb-0001vS-Bn
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:56:29 +0000
Received: from [193.109.254.147:57391] by server-15.bemta-14.messagelabs.com
	id 8D/A6-24599-C0DEC115; Thu, 14 Feb 2013 13:56:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360850186!8805918!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25929 invoked from network); 14 Feb 2013 13:56:27 -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;
	14 Feb 2013 13:56:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7499018"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:56:26 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:56:25 -0500
Message-ID: <511CED08.9080902@citrix.com>
Date: Thu, 14 Feb 2013 13:56:24 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>	
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
In-Reply-To: <1360849999.16636.135.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/13 13:53, Wei Liu wrote:
> On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> If the credit timer is left armed after calling
>> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
>> the vif which will then oops as vif->netbk == NULL.
>>
>> This may happen both in the fatal error path and during normal
>> disconnection from the front end.
>>
>> The sequencing during shutdown is critical to ensure that: a)
>> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
>> is not freed.
>>
>> 1. Mark as unschedulable (netif_carrier_off()).
>> 2. Synchronously cancel the timer.
>> 3. Remove the vif from the schedule list.
>> 4. Remove it from it netback thread group.
>> 5. Wait for vif->refcnt to become 0.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> You would need to reinitialize the timer in xenvif_up, given that user
> might `ifconfig vifX.X down; ifconfig vifX.X up`.

No.  Deleted timers do not need to be reinitialized.  The timer will be
armed as usual with mod_timer() when credit is next exhausted.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:56:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zIb-0001vX-SN; Thu, 14 Feb 2013 13:56:29 +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 1U5zIb-0001vS-Bn
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:56:29 +0000
Received: from [193.109.254.147:57391] by server-15.bemta-14.messagelabs.com
	id 8D/A6-24599-C0DEC115; Thu, 14 Feb 2013 13:56:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360850186!8805918!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25929 invoked from network); 14 Feb 2013 13:56:27 -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;
	14 Feb 2013 13:56:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7499018"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 13:56:26 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 08:56:25 -0500
Message-ID: <511CED08.9080902@citrix.com>
Date: Thu, 14 Feb 2013 13:56:24 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>	
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
In-Reply-To: <1360849999.16636.135.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/13 13:53, Wei Liu wrote:
> On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> If the credit timer is left armed after calling
>> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
>> the vif which will then oops as vif->netbk == NULL.
>>
>> This may happen both in the fatal error path and during normal
>> disconnection from the front end.
>>
>> The sequencing during shutdown is critical to ensure that: a)
>> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
>> is not freed.
>>
>> 1. Mark as unschedulable (netif_carrier_off()).
>> 2. Synchronously cancel the timer.
>> 3. Remove the vif from the schedule list.
>> 4. Remove it from it netback thread group.
>> 5. Wait for vif->refcnt to become 0.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> You would need to reinitialize the timer in xenvif_up, given that user
> might `ifconfig vifX.X down; ifconfig vifX.X up`.

No.  Deleted timers do not need to be reinitialized.  The timer will be
armed as usual with mod_timer() when credit is next exhausted.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:56:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zIq-0001x4-8z; Thu, 14 Feb 2013 13:56:44 +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 1U5zIp-0001wp-Dc
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:56:43 +0000
Received: from [193.109.254.147:23579] by server-8.bemta-14.messagelabs.com id
	FA/88-17325-A1DEC115; Thu, 14 Feb 2013 13:56:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360850201!8721357!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28523 invoked from network); 14 Feb 2013 13:56:41 -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; 14 Feb 2013 13:56:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zIm-000MVJ-0S; Thu, 14 Feb 2013 13:56:40 +0000
Date: Thu, 14 Feb 2013 13:56:39 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214135639.GU83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-26-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-26-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 26/45] xen: arm64: add guest type to domain
	field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956592), Ian Campbell wrote:
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -35,8 +35,26 @@ struct hvm_domain
>      uint64_t              params[HVM_NR_PARAMS];
>  }  __cacheline_aligned;
>  
> +#ifdef CONFIG_ARM_64
> +enum domain_type {
> +    DOMAIN_PV32,
> +#ifdef CONFIG_ARM_64

Nested ifdef CONFIG_ARM_64 here. 

Tim.

> +    DOMAIN_PV64,
> +#endif
> +};
> +#define is_pv32_domain(d) ((d)->arch.type == DOMAIN_PV32)
> +#define is_pv64_domain(d) ((d)->arch.type == DOMAIN_PV64)
> +#else
> +#define is_pv32_domain(d) (1)
> +#define is_pv64_domain(d) (0)
> +#endif
> +
>  struct arch_domain
>  {
> +#ifdef CONFIG_ARM_64
> +    enum domain_type type;
> +#endif
> +
>      struct p2m_domain p2m;
>      struct hvm_domain hvm_domain;
>  
> -- 
> 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 Thu Feb 14 13:56:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zIq-0001x4-8z; Thu, 14 Feb 2013 13:56:44 +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 1U5zIp-0001wp-Dc
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:56:43 +0000
Received: from [193.109.254.147:23579] by server-8.bemta-14.messagelabs.com id
	FA/88-17325-A1DEC115; Thu, 14 Feb 2013 13:56:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360850201!8721357!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28523 invoked from network); 14 Feb 2013 13:56:41 -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; 14 Feb 2013 13:56:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zIm-000MVJ-0S; Thu, 14 Feb 2013 13:56:40 +0000
Date: Thu, 14 Feb 2013 13:56:39 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214135639.GU83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-26-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-26-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 26/45] xen: arm64: add guest type to domain
	field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956592), Ian Campbell wrote:
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -35,8 +35,26 @@ struct hvm_domain
>      uint64_t              params[HVM_NR_PARAMS];
>  }  __cacheline_aligned;
>  
> +#ifdef CONFIG_ARM_64
> +enum domain_type {
> +    DOMAIN_PV32,
> +#ifdef CONFIG_ARM_64

Nested ifdef CONFIG_ARM_64 here. 

Tim.

> +    DOMAIN_PV64,
> +#endif
> +};
> +#define is_pv32_domain(d) ((d)->arch.type == DOMAIN_PV32)
> +#define is_pv64_domain(d) ((d)->arch.type == DOMAIN_PV64)
> +#else
> +#define is_pv32_domain(d) (1)
> +#define is_pv64_domain(d) (0)
> +#endif
> +
>  struct arch_domain
>  {
> +#ifdef CONFIG_ARM_64
> +    enum domain_type type;
> +#endif
> +
>      struct p2m_domain p2m;
>      struct hvm_domain hvm_domain;
>  
> -- 
> 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 Thu Feb 14 13:57:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zJM-00022P-Nh; Thu, 14 Feb 2013 13:57:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1U5zJK-000220-Pd
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:57:15 +0000
Received: from [85.158.138.51:45058] by server-9.bemta-3.messagelabs.com id
	69/C3-09484-53DEC115; Thu, 14 Feb 2013 13:57:09 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360850148!27533473!1
X-Originating-IP: [209.85.216.174]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16654 invoked from network); 14 Feb 2013 13:55:50 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:55:50 -0000
Received: by mail-qc0-f174.google.com with SMTP id z24so886031qcq.33
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=tTscQzTA0dlh3T1Og/xlrC1ynMl9W7ZzT5To9hU3J/s=;
	b=aAzQJvz26wdLiSpS78mFK04E+TOY5mBRDloEwzxzXlGcs+xD5eAERLsQuD/Cs7xNIJ
	ymxseGPjHbHc9YgKdT5anJiozsDlWsZVZhXAS0LN5Dgu0MDBKioJpcyBbZLDFP2QlYI1
	05kkaDi6lZgCszYr7/nep1+AY8FoPr/7Uq58k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=tTscQzTA0dlh3T1Og/xlrC1ynMl9W7ZzT5To9hU3J/s=;
	b=UlsL0AcniLPszsKeZmmzIhPGjT63krGGfo8odbGDlFSMkFpKEwQ39uSZ8S0hG+hahz
	nM1h2XHvbQyIm0U3ErcUU6iAzB29IqDn+BBMh02AvnkxL6ZbS6IaMsV11veU7LiE3340
	SMYfbqMazxyhnkuN84n1rGtOaG23uTmXC6ItXC0TkJ31eOZL0JyYoCRFWmu9w70PNbsT
	iJ4mmHRfbUoI4vTAEaULIqpqa0SVaGuWTadvcejy+EVuwQqmnVGiOIhhtREoDipqX5g7
	eFQqI8rM6kMtwgoqiR7kJMAsOLaTaMjLu1SZJ0SsxSTtBexjdNxfhd68ChDBdc1PdDWS
	tA9g==
X-Received: by 10.224.100.130 with SMTP id y2mr620642qan.40.1360850147924;
	Thu, 14 Feb 2013 05:55:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 14 Feb 2013 05:55:32 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1360848973.20449.369.camel@zakaz.uk.xensource.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 17:55:32 +0400
X-Google-Sender-Auth: H6XTDVGag3870erWtk1InZ_TIX8
Message-ID: <CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQnT1Xy3becvMPso+QgNMl9Hjaei6jBJReJ2/FAcssx85bE+WHn4u3P/blQSnaYT+AUak1io
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
	destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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! But why release domain not returns domid ?=)
As i understand if i want to know what domains dies i need after fired
watch enumerate all domains and check its status. May be in case of
special watches watch returns not provided token or something more
useful?
in any case thanks for answers.

2013/2/14 Ian Campbell <Ian.Campbell@citrix.com>:
> On Thu, 2013-02-14 at 13:18 +0000, Vasiliy Tolstov wrote:
>> Hello!. How can i use @releaseDomain from dom0 to subscribe for domain
>> destruction?
>> I'm try to add watch for @releaseDomain path with token equal of
>> needed domain id. But when another domain dies, i get domain that i
>> provide via token to xs_watch.
>
> The token is an opaque cookie which xenstore simply echoes back at you
> so you can identify which of your watches is firing if you have more
> than one. It doesn't have any meaning other than that.
>
>> Is that possible to get id of domain what released from xenstore?
>
> Not directly, @releaseDomain just tells you that *a* domain died, you
> need to check if it was the one which interested you.
>
> libxl has some infrastructure for maintaining this state and firing
> events on specific domain death. depending on your use case this may or
> may not be overkill for your application.
>
> Ian.
>
>
>



--
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 Thu Feb 14 13:57:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13: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 1U5zJM-00022P-Nh; Thu, 14 Feb 2013 13:57:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1U5zJK-000220-Pd
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:57:15 +0000
Received: from [85.158.138.51:45058] by server-9.bemta-3.messagelabs.com id
	69/C3-09484-53DEC115; Thu, 14 Feb 2013 13:57:09 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360850148!27533473!1
X-Originating-IP: [209.85.216.174]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16654 invoked from network); 14 Feb 2013 13:55:50 -0000
Received: from mail-qc0-f174.google.com (HELO mail-qc0-f174.google.com)
	(209.85.216.174)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:55:50 -0000
Received: by mail-qc0-f174.google.com with SMTP id z24so886031qcq.33
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=tTscQzTA0dlh3T1Og/xlrC1ynMl9W7ZzT5To9hU3J/s=;
	b=aAzQJvz26wdLiSpS78mFK04E+TOY5mBRDloEwzxzXlGcs+xD5eAERLsQuD/Cs7xNIJ
	ymxseGPjHbHc9YgKdT5anJiozsDlWsZVZhXAS0LN5Dgu0MDBKioJpcyBbZLDFP2QlYI1
	05kkaDi6lZgCszYr7/nep1+AY8FoPr/7Uq58k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=tTscQzTA0dlh3T1Og/xlrC1ynMl9W7ZzT5To9hU3J/s=;
	b=UlsL0AcniLPszsKeZmmzIhPGjT63krGGfo8odbGDlFSMkFpKEwQ39uSZ8S0hG+hahz
	nM1h2XHvbQyIm0U3ErcUU6iAzB29IqDn+BBMh02AvnkxL6ZbS6IaMsV11veU7LiE3340
	SMYfbqMazxyhnkuN84n1rGtOaG23uTmXC6ItXC0TkJ31eOZL0JyYoCRFWmu9w70PNbsT
	iJ4mmHRfbUoI4vTAEaULIqpqa0SVaGuWTadvcejy+EVuwQqmnVGiOIhhtREoDipqX5g7
	eFQqI8rM6kMtwgoqiR7kJMAsOLaTaMjLu1SZJ0SsxSTtBexjdNxfhd68ChDBdc1PdDWS
	tA9g==
X-Received: by 10.224.100.130 with SMTP id y2mr620642qan.40.1360850147924;
	Thu, 14 Feb 2013 05:55:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.92.13 with HTTP; Thu, 14 Feb 2013 05:55:32 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1360848973.20449.369.camel@zakaz.uk.xensource.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 17:55:32 +0400
X-Google-Sender-Auth: H6XTDVGag3870erWtk1InZ_TIX8
Message-ID: <CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQnT1Xy3becvMPso+QgNMl9Hjaei6jBJReJ2/FAcssx85bE+WHn4u3P/blQSnaYT+AUak1io
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
	destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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! But why release domain not returns domid ?=)
As i understand if i want to know what domains dies i need after fired
watch enumerate all domains and check its status. May be in case of
special watches watch returns not provided token or something more
useful?
in any case thanks for answers.

2013/2/14 Ian Campbell <Ian.Campbell@citrix.com>:
> On Thu, 2013-02-14 at 13:18 +0000, Vasiliy Tolstov wrote:
>> Hello!. How can i use @releaseDomain from dom0 to subscribe for domain
>> destruction?
>> I'm try to add watch for @releaseDomain path with token equal of
>> needed domain id. But when another domain dies, i get domain that i
>> provide via token to xs_watch.
>
> The token is an opaque cookie which xenstore simply echoes back at you
> so you can identify which of your watches is firing if you have more
> than one. It doesn't have any meaning other than that.
>
>> Is that possible to get id of domain what released from xenstore?
>
> Not directly, @releaseDomain just tells you that *a* domain died, you
> need to check if it was the one which interested you.
>
> libxl has some infrastructure for maintaining this state and firing
> events on specific domain death. depending on your use case this may or
> may not be overkill for your application.
>
> Ian.
>
>
>



--
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 Thu Feb 14 13:57:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:57: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 1U5zJQ-000238-3o; Thu, 14 Feb 2013 13:57: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 1U5zJP-00022r-4u
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:57:19 +0000
Received: from [85.158.138.51:49347] by server-14.bemta-3.messagelabs.com id
	D2/8D-23533-E3DEC115; Thu, 14 Feb 2013 13:57:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360850232!18672797!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26065 invoked from network); 14 Feb 2013 13:57:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1462447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13: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.297.1;
	Thu, 14 Feb 2013 13:57:12 +0000
Message-ID: <1360850230.20449.381.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 13:57:10 +0000
In-Reply-To: <20130214135006.GT83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
	<20130214135006.GT83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 25/45] xen: arm: separate guest user regs
 from internal guest 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 Thu, 2013-02-14 at 13:50 +0000, Tim Deegan wrote:
> At 13:38 +0000 on 14 Feb (1360849103), Ian Campbell wrote:
> > On Thu, 2013-02-14 at 13:10 +0000, Tim Deegan wrote:
> > > So this ends up with two different layouts for core regs, one public and
> > > one private, both of which have the padding/unions to allow 64-bit and
> > > 32-bit to coexist.  Can we really not re-use them?
> > 
> > The 32-bit internal version doesn't have padding because that makes
> > entry.S hellish, and wastes a bunch of hypervisor memory.
> 
> Understood - but could the 64-bit on-stack format and the public
> interface share some code?  Maybe that's just as ugly as having two
> very-similar register structs.

I did wonder that.

>   And I guess we'd like to be able to
> tinker with the stack format without worrying about the ABI.

But this.

>   So I
> withdraw the question. :)

:-)

> 
> Tim.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 13:57:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 13:57: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 1U5zJQ-000238-3o; Thu, 14 Feb 2013 13:57: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 1U5zJP-00022r-4u
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:57:19 +0000
Received: from [85.158.138.51:49347] by server-14.bemta-3.messagelabs.com id
	D2/8D-23533-E3DEC115; Thu, 14 Feb 2013 13:57:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360850232!18672797!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26065 invoked from network); 14 Feb 2013 13:57:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1462447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 13: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.297.1;
	Thu, 14 Feb 2013 13:57:12 +0000
Message-ID: <1360850230.20449.381.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 13:57:10 +0000
In-Reply-To: <20130214135006.GT83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
	<20130214135006.GT83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 25/45] xen: arm: separate guest user regs
 from internal guest 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 Thu, 2013-02-14 at 13:50 +0000, Tim Deegan wrote:
> At 13:38 +0000 on 14 Feb (1360849103), Ian Campbell wrote:
> > On Thu, 2013-02-14 at 13:10 +0000, Tim Deegan wrote:
> > > So this ends up with two different layouts for core regs, one public and
> > > one private, both of which have the padding/unions to allow 64-bit and
> > > 32-bit to coexist.  Can we really not re-use them?
> > 
> > The 32-bit internal version doesn't have padding because that makes
> > entry.S hellish, and wastes a bunch of hypervisor memory.
> 
> Understood - but could the 64-bit on-stack format and the public
> interface share some code?  Maybe that's just as ugly as having two
> very-similar register structs.

I did wonder that.

>   And I guess we'd like to be able to
> tinker with the stack format without worrying about the ABI.

But this.

>   So I
> withdraw the question. :)

:-)

> 
> Tim.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:04:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zQa-0002jM-2m; Thu, 14 Feb 2013 14:04:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5zQZ-0002jF-8I
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:04:43 +0000
Received: from [85.158.139.83:36291] by server-10.bemta-5.messagelabs.com id
	3F/26-04697-AFEEC115; Thu, 14 Feb 2013 14:04:42 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360850681!27104885!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6221 invoked from network); 14 Feb 2013 14:04:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:04:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1462755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:04:42 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 14 Feb 2013
	14:04:41 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 14:04:41 +0000
Thread-Topic: [PATCH] doc: Improve xc_domain_restore inline documentation
Thread-Index: Ac4KvDwawJ1l3OxjR2+PD3RkbejoJw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458384@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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


Was not clear that xc_domain_restore did not resume the machine.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 tools/libxc/xenguest.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 1597e5c..f9cd2ec 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -102,6 +102,8 @@ struct restore_callbacks {
 /**
  * This function will restore a saved domain.
  *
+ * Domain is restored in a suspended state ready to be unpaused.
+ *
  * @parm xch a handle to an open hypervisor interface
  * @parm fd the file descriptor to restore a domain from
  * @parm dom the id of the domain
-- 
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 Thu Feb 14 14:04:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zQa-0002jM-2m; Thu, 14 Feb 2013 14:04:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5zQZ-0002jF-8I
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:04:43 +0000
Received: from [85.158.139.83:36291] by server-10.bemta-5.messagelabs.com id
	3F/26-04697-AFEEC115; Thu, 14 Feb 2013 14:04:42 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360850681!27104885!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6221 invoked from network); 14 Feb 2013 14:04:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:04:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1462755"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:04:42 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 14 Feb 2013
	14:04:41 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 14:04:41 +0000
Thread-Topic: [PATCH] doc: Improve xc_domain_restore inline documentation
Thread-Index: Ac4KvDwawJ1l3OxjR2+PD3RkbejoJw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458384@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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


Was not clear that xc_domain_restore did not resume the machine.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 tools/libxc/xenguest.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 1597e5c..f9cd2ec 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -102,6 +102,8 @@ struct restore_callbacks {
 /**
  * This function will restore a saved domain.
  *
+ * Domain is restored in a suspended state ready to be unpaused.
+ *
  * @parm xch a handle to an open hypervisor interface
  * @parm fd the file descriptor to restore a domain from
  * @parm dom the id of the domain
-- 
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 Thu Feb 14 14:07:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:07: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 1U5zSf-0002p1-K7; Thu, 14 Feb 2013 14:06:53 +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 1U5zSd-0002ow-RT
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:06:51 +0000
Received: from [85.158.138.51:22587] by server-10.bemta-3.messagelabs.com id
	CE/10-10609-B7FEC115; Thu, 14 Feb 2013 14:06:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360850810!27641080!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22183 invoked from network); 14 Feb 2013 14:06:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:06:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zSb-000MXT-QV; Thu, 14 Feb 2013 14:06:49 +0000
Date: Thu, 14 Feb 2013 14:06:49 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214140649.GV83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-27-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-27-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 27/45] xen: arm: move arm32 specific trap
	handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956593), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Not sure that these couldn't be reused in 64bit, but still:

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 Thu Feb 14 14:07:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:07: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 1U5zSf-0002p1-K7; Thu, 14 Feb 2013 14:06:53 +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 1U5zSd-0002ow-RT
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:06:51 +0000
Received: from [85.158.138.51:22587] by server-10.bemta-3.messagelabs.com id
	CE/10-10609-B7FEC115; Thu, 14 Feb 2013 14:06:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360850810!27641080!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22183 invoked from network); 14 Feb 2013 14:06:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:06:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zSb-000MXT-QV; Thu, 14 Feb 2013 14:06:49 +0000
Date: Thu, 14 Feb 2013 14:06:49 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214140649.GV83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-27-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-27-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 27/45] xen: arm: move arm32 specific trap
	handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956593), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Not sure that these couldn't be reused in 64bit, but still:

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 Thu Feb 14 14:09:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zUo-0002yd-9p; Thu, 14 Feb 2013 14:09:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U5zUm-0002yX-Rv
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:09:05 +0000
Received: from [85.158.138.51:44107] by server-7.bemta-3.messagelabs.com id
	6D/B8-10367-BFFEC115; Thu, 14 Feb 2013 14:08:59 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360850938!19548547!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11719 invoked from network); 14 Feb 2013 14:08:58 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 14:08:58 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U5zUd-0007ww-Uv; Thu, 14 Feb 2013 14:08:55 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U5zUX-0001O3-Dn; Thu, 14 Feb 2013 14:08:55 +0000
Message-ID: <1360850923.20449.390.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 14 Feb 2013 14:08:43 +0000
In-Reply-To: <1360849951.10581.239.camel@shinybook.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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, 2013-02-14 at 13:52 +0000, David Woodhouse wrote:
> On Thu, 2013-02-14 at 13:05 +0000, David Woodhouse wrote:
> > 
> > I'll probably have a look at OVMF under Xen now, and making sure that my
> > CSM code works there. Then you shouldn't need to offer people the choice
> > between OVMF and SeaBIOS because you'll have one image that handles
> > everything (which is what people get on real hardware, and expect).
> 
> That part, at least, was surprisingly easy. The same OVMF images (with
> SeaBIOS-as-CSM) that I've been testing under Qemu work fine under Xen
> too. The OVMF build system is hosed for GCC 4.7 and your own Makefile
> also has 'GCC44' in the path when copying out the build result. when it
> could have been 'GCC4?' and at least been a little more robust.

The chap who did our OVMF stuff has moved on to pastures new but ISTR
him saying something about a build bug with GCC!=44, which had been
fixed in upstream OVMF but not yet sync'd into the Xen tree.

> But that's just fluff. Basically, it works.

Awesome! (I've CCd xen-devel just for their info, it's moderated for
non-subscribers but valid posters get whitelisted)

> I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> PCIR structure unaligned. That was it.

I would have put a substantial sum of money on the VGA ROM we ship not
being used in the SeaBIOS configuration, since SB pulls the ROM from the
emulated cards ROM BAR. The Cirrus ROM we ship should be used with
ROMBIOS only. I wonder what's going on there (another one for my list)

Or did you mean the VGA ROM we ship in the qemu-xen branch that we
include? (rather than tools/firmware/vgabios/)

> Again, this is without actually trying to boot any OS :)

Lets not get carried away :-P

Ian.
-- 
Ian Campbell
Current Noise: Pink Floyd - Time

* weasel wonders how stupid one has to be to spam alt.anonymous.messages
 weasel: about half as stupid as one has to be to harvest it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:09:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zUo-0002yd-9p; Thu, 14 Feb 2013 14:09:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U5zUm-0002yX-Rv
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:09:05 +0000
Received: from [85.158.138.51:44107] by server-7.bemta-3.messagelabs.com id
	6D/B8-10367-BFFEC115; Thu, 14 Feb 2013 14:08:59 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360850938!19548547!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11719 invoked from network); 14 Feb 2013 14:08:58 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 14:08:58 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U5zUd-0007ww-Uv; Thu, 14 Feb 2013 14:08:55 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U5zUX-0001O3-Dn; Thu, 14 Feb 2013 14:08:55 +0000
Message-ID: <1360850923.20449.390.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 14 Feb 2013 14:08:43 +0000
In-Reply-To: <1360849951.10581.239.camel@shinybook.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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, 2013-02-14 at 13:52 +0000, David Woodhouse wrote:
> On Thu, 2013-02-14 at 13:05 +0000, David Woodhouse wrote:
> > 
> > I'll probably have a look at OVMF under Xen now, and making sure that my
> > CSM code works there. Then you shouldn't need to offer people the choice
> > between OVMF and SeaBIOS because you'll have one image that handles
> > everything (which is what people get on real hardware, and expect).
> 
> That part, at least, was surprisingly easy. The same OVMF images (with
> SeaBIOS-as-CSM) that I've been testing under Qemu work fine under Xen
> too. The OVMF build system is hosed for GCC 4.7 and your own Makefile
> also has 'GCC44' in the path when copying out the build result. when it
> could have been 'GCC4?' and at least been a little more robust.

The chap who did our OVMF stuff has moved on to pastures new but ISTR
him saying something about a build bug with GCC!=44, which had been
fixed in upstream OVMF but not yet sync'd into the Xen tree.

> But that's just fluff. Basically, it works.

Awesome! (I've CCd xen-devel just for their info, it's moderated for
non-subscribers but valid posters get whitelisted)

> I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> PCIR structure unaligned. That was it.

I would have put a substantial sum of money on the VGA ROM we ship not
being used in the SeaBIOS configuration, since SB pulls the ROM from the
emulated cards ROM BAR. The Cirrus ROM we ship should be used with
ROMBIOS only. I wonder what's going on there (another one for my list)

Or did you mean the VGA ROM we ship in the qemu-xen branch that we
include? (rather than tools/firmware/vgabios/)

> Again, this is without actually trying to boot any OS :)

Lets not get carried away :-P

Ian.
-- 
Ian Campbell
Current Noise: Pink Floyd - Time

* weasel wonders how stupid one has to be to spam alt.anonymous.messages
 weasel: about half as stupid as one has to be to harvest it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:10:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:10: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 1U5zW7-00035o-Pu; Thu, 14 Feb 2013 14:10:27 +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 1U5zW6-00035g-Tf
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:10:27 +0000
Received: from [193.109.254.147:41574] by server-11.bemta-14.messagelabs.com
	id 68/B1-30685-250FC115; Thu, 14 Feb 2013 14:10:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360851018!2509189!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21073 invoked from network); 14 Feb 2013 14:10:20 -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;
	14 Feb 2013 14:10:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7130247"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:10:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:10:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5zVx-0006vZ-BX;
	Thu, 14 Feb 2013 14:10:17 +0000
Message-ID: <1360851017.16636.141.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 14:10:17 +0000
In-Reply-To: <511CED08.9080902@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
	<511CED08.9080902@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 13:56 +0000, David Vrabel wrote:
> On 14/02/13 13:53, Wei Liu wrote:
> > On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> If the credit timer is left armed after calling
> >> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> >> the vif which will then oops as vif->netbk == NULL.
> >>
> >> This may happen both in the fatal error path and during normal
> >> disconnection from the front end.
> >>
> >> The sequencing during shutdown is critical to ensure that: a)
> >> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> >> is not freed.
> >>
> >> 1. Mark as unschedulable (netif_carrier_off()).
> >> 2. Synchronously cancel the timer.
> >> 3. Remove the vif from the schedule list.
> >> 4. Remove it from it netback thread group.
> >> 5. Wait for vif->refcnt to become 0.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > 
> > You would need to reinitialize the timer in xenvif_up, given that user
> > might `ifconfig vifX.X down; ifconfig vifX.X up`.
> 
> No.  Deleted timers do not need to be reinitialized.  The timer will be

What I really meant was to "rearm"...

> armed as usual with mod_timer() when credit is next exhausted.
> 

Ah, ok.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:10:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:10: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 1U5zW7-00035o-Pu; Thu, 14 Feb 2013 14:10:27 +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 1U5zW6-00035g-Tf
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:10:27 +0000
Received: from [193.109.254.147:41574] by server-11.bemta-14.messagelabs.com
	id 68/B1-30685-250FC115; Thu, 14 Feb 2013 14:10:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1360851018!2509189!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21073 invoked from network); 14 Feb 2013 14:10:20 -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;
	14 Feb 2013 14:10:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7130247"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:10:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:10:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5zVx-0006vZ-BX;
	Thu, 14 Feb 2013 14:10:17 +0000
Message-ID: <1360851017.16636.141.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 14:10:17 +0000
In-Reply-To: <511CED08.9080902@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
	<511CED08.9080902@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 13:56 +0000, David Vrabel wrote:
> On 14/02/13 13:53, Wei Liu wrote:
> > On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> If the credit timer is left armed after calling
> >> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> >> the vif which will then oops as vif->netbk == NULL.
> >>
> >> This may happen both in the fatal error path and during normal
> >> disconnection from the front end.
> >>
> >> The sequencing during shutdown is critical to ensure that: a)
> >> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> >> is not freed.
> >>
> >> 1. Mark as unschedulable (netif_carrier_off()).
> >> 2. Synchronously cancel the timer.
> >> 3. Remove the vif from the schedule list.
> >> 4. Remove it from it netback thread group.
> >> 5. Wait for vif->refcnt to become 0.
> >>
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > 
> > You would need to reinitialize the timer in xenvif_up, given that user
> > might `ifconfig vifX.X down; ifconfig vifX.X up`.
> 
> No.  Deleted timers do not need to be reinitialized.  The timer will be

What I really meant was to "rearm"...

> armed as usual with mod_timer() when credit is next exhausted.
> 

Ah, ok.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:11:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zXH-0003Ex-9e; Thu, 14 Feb 2013 14:11: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 1U5zXG-0003En-9I
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:11:38 +0000
Received: from [85.158.143.99:2104] by server-2.bemta-4.messagelabs.com id
	41/16-01597-990FC115; Thu, 14 Feb 2013 14:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360851083!22256759!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20079 invoked from network); 14 Feb 2013 14:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:11: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.297.1;
	Thu, 14 Feb 2013 14:11:23 +0000
Message-ID: <1360851081.20449.393.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:11:21 +0000
In-Reply-To: <20130214140649.GV83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-27-git-send-email-ian.campbell@citrix.com>
	<20130214140649.GV83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 27/45] xen: arm: move arm32 specific trap
 handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:06 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956593), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Not sure that these couldn't be reused in 64bit, but still:

arm32 has separate entry points for dabt etc whereas arm64 simply has
"trap to EL2 from <lower|same> level" and you distinguish using the HSR.
So arm32 has some extra entry points.

> Acked-by: Tim Deegan <tim@xen.org>

Ta,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:11:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zXH-0003Ex-9e; Thu, 14 Feb 2013 14:11: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 1U5zXG-0003En-9I
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:11:38 +0000
Received: from [85.158.143.99:2104] by server-2.bemta-4.messagelabs.com id
	41/16-01597-990FC115; Thu, 14 Feb 2013 14:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360851083!22256759!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20079 invoked from network); 14 Feb 2013 14:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:11: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.297.1;
	Thu, 14 Feb 2013 14:11:23 +0000
Message-ID: <1360851081.20449.393.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:11:21 +0000
In-Reply-To: <20130214140649.GV83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-27-git-send-email-ian.campbell@citrix.com>
	<20130214140649.GV83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 27/45] xen: arm: move arm32 specific trap
 handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:06 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956593), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Not sure that these couldn't be reused in 64bit, but still:

arm32 has separate entry points for dabt etc whereas arm64 simply has
"trap to EL2 from <lower|same> level" and you distinguish using the HSR.
So arm32 has some extra entry points.

> Acked-by: Tim Deegan <tim@xen.org>

Ta,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:13:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zZM-0003Pf-Rh; Thu, 14 Feb 2013 14:13: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 1U5zZK-0003PT-RB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:13:46 +0000
Received: from [85.158.138.51:45113] by server-11.bemta-3.messagelabs.com id
	75/BF-10249-511FC115; Thu, 14 Feb 2013 14:13:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360851219!27537081!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12852 invoked from network); 14 Feb 2013 14:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:13: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.297.1;
	Thu, 14 Feb 2013 14:13:38 +0000
Message-ID: <1360851217.20449.395.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 14:13:37 +0000
In-Reply-To: <CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
	<CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
 destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 don't top post

On Thu, 2013-02-14 at 13:55 +0000, Vasiliy Tolstov wrote:
> Thanks! But why release domain not returns domid ?=)

The hypervisor only has a single bit (an event channel) to signal the
event to the tools, so there is no space for the domid.

Sure, you could probably invent up some shared memory data structure or
something, but why bother.

> As i understand if i want to know what domains dies i need after fired
> watch enumerate all domains and check its status.

Well, if you only care about one domain you just need to check that one
domain.

Otherwise you should look at the libxl functionality I mentioned before.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:13:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zZM-0003Pf-Rh; Thu, 14 Feb 2013 14:13: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 1U5zZK-0003PT-RB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:13:46 +0000
Received: from [85.158.138.51:45113] by server-11.bemta-3.messagelabs.com id
	75/BF-10249-511FC115; Thu, 14 Feb 2013 14:13:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360851219!27537081!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12852 invoked from network); 14 Feb 2013 14:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:13: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.297.1;
	Thu, 14 Feb 2013 14:13:38 +0000
Message-ID: <1360851217.20449.395.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 14 Feb 2013 14:13:37 +0000
In-Reply-To: <CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
	<CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
 destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 don't top post

On Thu, 2013-02-14 at 13:55 +0000, Vasiliy Tolstov wrote:
> Thanks! But why release domain not returns domid ?=)

The hypervisor only has a single bit (an event channel) to signal the
event to the tools, so there is no space for the domid.

Sure, you could probably invent up some shared memory data structure or
something, but why bother.

> As i understand if i want to know what domains dies i need after fired
> watch enumerate all domains and check its status.

Well, if you only care about one domain you just need to check that one
domain.

Otherwise you should look at the libxl functionality I mentioned before.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:14:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:14: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 1U5za0-0003TI-8t; Thu, 14 Feb 2013 14:14:28 +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 1U5zZy-0003Sz-In
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:14:26 +0000
Received: from [85.158.139.211:15504] by server-5.bemta-5.messagelabs.com id
	D0/88-11945-141FC115; Thu, 14 Feb 2013 14:14:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360851264!21454285!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28021 invoked from network); 14 Feb 2013 14:14:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:14:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 14:14:38 +0000
Message-Id: <511CFF8A02000078000BE4B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 14:15:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
In-Reply-To: <1360849999.16636.135.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	"Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 14:53, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>> 
>> If the credit timer is left armed after calling
>> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
>> the vif which will then oops as vif->netbk == NULL.
>> 
>> This may happen both in the fatal error path and during normal
>> disconnection from the front end.
>> 
>> The sequencing during shutdown is critical to ensure that: a)
>> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
>> is not freed.
>> 
>> 1. Mark as unschedulable (netif_carrier_off()).
>> 2. Synchronously cancel the timer.
>> 3. Remove the vif from the schedule list.
>> 4. Remove it from it netback thread group.
>> 5. Wait for vif->refcnt to become 0.
>> 
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> You would need to reinitialize the timer in xenvif_up, given that user
> might `ifconfig vifX.X down; ifconfig vifX.X up`.

Which gets us to another aspect of the original fix that I don't
think was considered: Is there anything preventing the interface
to be brought back up after fatal_tx_err() shut it down?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:14:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:14: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 1U5za0-0003TI-8t; Thu, 14 Feb 2013 14:14:28 +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 1U5zZy-0003Sz-In
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:14:26 +0000
Received: from [85.158.139.211:15504] by server-5.bemta-5.messagelabs.com id
	D0/88-11945-141FC115; Thu, 14 Feb 2013 14:14:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360851264!21454285!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28021 invoked from network); 14 Feb 2013 14:14:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:14:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 14:14:38 +0000
Message-Id: <511CFF8A02000078000BE4B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 14:15:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
In-Reply-To: <1360849999.16636.135.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	"Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 14:53, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>> 
>> If the credit timer is left armed after calling
>> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
>> the vif which will then oops as vif->netbk == NULL.
>> 
>> This may happen both in the fatal error path and during normal
>> disconnection from the front end.
>> 
>> The sequencing during shutdown is critical to ensure that: a)
>> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
>> is not freed.
>> 
>> 1. Mark as unschedulable (netif_carrier_off()).
>> 2. Synchronously cancel the timer.
>> 3. Remove the vif from the schedule list.
>> 4. Remove it from it netback thread group.
>> 5. Wait for vif->refcnt to become 0.
>> 
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> You would need to reinitialize the timer in xenvif_up, given that user
> might `ifconfig vifX.X down; ifconfig vifX.X up`.

Which gets us to another aspect of the original fix that I don't
think was considered: Is there anything preventing the interface
to be brought back up after fatal_tx_err() shut it down?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:15:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:15: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 1U5zb2-0003bP-Nl; Thu, 14 Feb 2013 14:15: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 1U5zb1-0003b4-9Q
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:15:31 +0000
Received: from [85.158.138.51:37673] by server-13.bemta-3.messagelabs.com id
	EB/B0-20653-081FC115; Thu, 14 Feb 2013 14:15:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360851327!19635852!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4800 invoked from network); 14 Feb 2013 14:15:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:15: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.297.1;
	Thu, 14 Feb 2013 14:15:27 +0000
Message-ID: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:15:24 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 00/04] xen: public interface (and foreign check)
 changes for arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change here is to switch evtchns to xen_ulong_t on arm, this
enables us to have the same interface on arm32 and arm64. I will post a
Linux side series shortly. This is an ABI change for ARM but not x86.

The remainder of the series fixes the tools/include/xen-foreign checks
to cover more stuff on ARM.

As part of this I have moved start_info out of the generic public
headers and into x86-specific public headers -- ARM does not use this
struct in its ABI and the majority of start_info is PV MMU stuff.
Removing it from ARM means I don't have to worry about the unsigned
longs in there.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:15:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:15: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 1U5zb2-0003bP-Nl; Thu, 14 Feb 2013 14:15: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 1U5zb1-0003b4-9Q
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:15:31 +0000
Received: from [85.158.138.51:37673] by server-13.bemta-3.messagelabs.com id
	EB/B0-20653-081FC115; Thu, 14 Feb 2013 14:15:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360851327!19635852!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4800 invoked from network); 14 Feb 2013 14:15:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:15: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.297.1;
	Thu, 14 Feb 2013 14:15:27 +0000
Message-ID: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:15:24 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 00/04] xen: public interface (and foreign check)
 changes for arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change here is to switch evtchns to xen_ulong_t on arm, this
enables us to have the same interface on arm32 and arm64. I will post a
Linux side series shortly. This is an ABI change for ARM but not x86.

The remainder of the series fixes the tools/include/xen-foreign checks
to cover more stuff on ARM.

As part of this I have moved start_info out of the generic public
headers and into x86-specific public headers -- ARM does not use this
struct in its ABI and the majority of start_info is PV MMU stuff.
Removing it from ARM means I don't have to worry about the unsigned
longs in there.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:16:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zbp-0003i4-6E; Thu, 14 Feb 2013 14:16:21 +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 1U5zbn-0003hd-9c
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:16:19 +0000
Received: from [85.158.137.99:3345] by server-2.bemta-3.messagelabs.com id
	BD/AE-25961-2B1FC115; Thu, 14 Feb 2013 14:16:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360851376!16678975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3936 invoked from network); 14 Feb 2013 14:16:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:16:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7502363"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-S4;
	Thu, 14 Feb 2013 14:16:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:11 +0000
Message-ID: <1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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 define __arm__ARM32 as required.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/include/xen-foreign/Makefile       |    4 ++--
 tools/include/xen-foreign/mkheader.py    |    6 +++++-
 tools/include/xen-foreign/reference.size |    2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..5bc2d46 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..c8af7a1 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,15 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["x86_32"] = """
+#define __arm__ARM32 1
+""";
+
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..9f1bfac 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,5 +1,5 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32  x86_32  x86_64
 
 start_info                |       -    1112    1168
 trap_info                 |       -       8      16
-- 
1.7.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 Feb 14 14:16:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zbp-0003i4-6E; Thu, 14 Feb 2013 14:16:21 +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 1U5zbn-0003hd-9c
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:16:19 +0000
Received: from [85.158.137.99:3345] by server-2.bemta-3.messagelabs.com id
	BD/AE-25961-2B1FC115; Thu, 14 Feb 2013 14:16:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360851376!16678975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3936 invoked from network); 14 Feb 2013 14:16:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:16:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7502363"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-S4;
	Thu, 14 Feb 2013 14:16:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:11 +0000
Message-ID: <1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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 define __arm__ARM32 as required.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
 tools/include/xen-foreign/Makefile       |    4 ++--
 tools/include/xen-foreign/mkheader.py    |    6 +++++-
 tools/include/xen-foreign/reference.size |    2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..5bc2d46 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..c8af7a1 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,15 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["x86_32"] = """
+#define __arm__ARM32 1
+""";
+
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..9f1bfac 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,5 +1,5 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32  x86_32  x86_64
 
 start_info                |       -    1112    1168
 trap_info                 |       -       8      16
-- 
1.7.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 Feb 14 14:16:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:16: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 1U5zbp-0003iG-JJ; Thu, 14 Feb 2013 14:16:21 +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 1U5zbo-0003hq-Hv
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:16:20 +0000
Received: from [85.158.137.99:51824] by server-4.bemta-3.messagelabs.com id
	6A/CE-17521-3B1FC115; Thu, 14 Feb 2013 14:16:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360851376!16678975!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4042 invoked from network); 14 Feb 2013 14:16:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7502364"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-Sf;
	Thu, 14 Feb 2013 14:16:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:12 +0000
Message-ID: <1360851374-28326-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/4] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/include/xen-foreign/mkheader.py |    4 +++-
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index c8af7a1..685ab8e 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,17 +21,18 @@ inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
 header["x86_32"] = """
 #define __arm__ARM32 1
 """;
 
-
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -46,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 14 14:16:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:16: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 1U5zbp-0003iG-JJ; Thu, 14 Feb 2013 14:16:21 +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 1U5zbo-0003hq-Hv
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:16:20 +0000
Received: from [85.158.137.99:51824] by server-4.bemta-3.messagelabs.com id
	6A/CE-17521-3B1FC115; Thu, 14 Feb 2013 14:16:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360851376!16678975!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4042 invoked from network); 14 Feb 2013 14:16:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7502364"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-Sf;
	Thu, 14 Feb 2013 14:16:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:12 +0000
Message-ID: <1360851374-28326-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/4] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/include/xen-foreign/mkheader.py |    4 +++-
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index c8af7a1..685ab8e 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,17 +21,18 @@ inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
 header["x86_32"] = """
 #define __arm__ARM32 1
 """;
 
-
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -46,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 14 14:16:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zbt-0003jV-4p; Thu, 14 Feb 2013 14:16: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 1U5zbr-0003it-Q3
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:16:23 +0000
Received: from [85.158.143.99:6084] by server-1.bemta-4.messagelabs.com id
	05/F4-08839-7B1FC115; Thu, 14 Feb 2013 14:16:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360851381!22257909!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17038 invoked from network); 14 Feb 2013 14:16:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:16: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.297.1;
	Thu, 14 Feb 2013 14:16:21 +0000
Message-ID: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:20 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 00/NN] linux: public interface changes for arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change here is to switch evtchns to xen_ulong_t on arm, this
enables us to have the same interface on arm32 and arm64. This is an ABI
change for ARM but not x86. This is a counterpart to the Xen patch just
posted.

In that series I also made start_info x86 specific. ARM does not use
this struct in its ABI but for convenience in non-arch specific code I
have included an internal (non ABI) version on ARM too. Long term
perhaps we should consider improving the abstraction used in the common
code to avoid this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:16:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zbt-0003jV-4p; Thu, 14 Feb 2013 14:16: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 1U5zbr-0003it-Q3
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:16:23 +0000
Received: from [85.158.143.99:6084] by server-1.bemta-4.messagelabs.com id
	05/F4-08839-7B1FC115; Thu, 14 Feb 2013 14:16:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360851381!22257909!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17038 invoked from network); 14 Feb 2013 14:16:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:16: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.297.1;
	Thu, 14 Feb 2013 14:16:21 +0000
Message-ID: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:20 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 00/NN] linux: public interface changes for arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change here is to switch evtchns to xen_ulong_t on arm, this
enables us to have the same interface on arm32 and arm64. This is an ABI
change for ARM but not x86. This is a counterpart to the Xen patch just
posted.

In that series I also made start_info x86 specific. ARM does not use
this struct in its ABI but for convenience in non-arch specific code I
have included an internal (non ABI) version on ARM too. Long term
perhaps we should consider improving the abstraction used in the common
code to avoid this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:18:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zdV-00047i-2k; Thu, 14 Feb 2013 14:18:05 +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 1U5zdT-00047M-GU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:18:03 +0000
Received: from [193.109.254.147:32162] by server-9.bemta-14.messagelabs.com id
	CE/72-30867-A12FC115; Thu, 14 Feb 2013 14:18:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360851435!9296805!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5764 invoked from network); 14 Feb 2013 14:17:22 -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;
	14 Feb 2013 14:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131309"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-UM;
	Thu, 14 Feb 2013 14:16:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:13 +0000
Message-ID: <1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Most of this struct is PV MMU specific and it is not used on ARM at all.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xenctrl.h             |    5 +--
 xen/include/public/arch-x86/xen.h |   73 +++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h          |   73 -------------------------------------
 xen/include/xlat.lst              |    2 +-
 4 files changed, 76 insertions(+), 77 deletions(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 32122fd..9e4a741 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -395,15 +395,14 @@ typedef union
     shared_info_t s;
 } shared_info_any_t;
 
+#if defined(__i386__) || defined(__x86_64__)
 typedef union
 {
-#if defined(__i386__) || defined(__x86_64__)
     start_info_x86_64_t x64;
     start_info_x86_32_t x32;
-#endif
     start_info_t s;
 } start_info_any_t;
-
+#endif
 
 int xc_domain_create(xc_interface *xch,
                      uint32_t ssidref,
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 13c21dc..00f0306 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -147,6 +147,79 @@ DEFINE_XEN_GUEST_HANDLE(trap_info_t);
 
 typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
 
+#define MAX_GUEST_CMDLINE 1024
+struct start_info {
+    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
+    char magic[32];             /* "xen-<version>-<platform>".            */
+    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+    unsigned long shared_info;  /* MACHINE address of shared info struct. */
+    uint32_t flags;             /* SIF_xxx flags.                         */
+    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+    uint32_t store_evtchn;      /* Event channel for store communication. */
+    union {
+        struct {
+            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+            uint32_t  evtchn;   /* Event channel for console page.        */
+        } domU;
+        struct {
+            uint32_t info_off;  /* Offset of console_info struct.         */
+            uint32_t info_size; /* Size of console_info struct from start.*/
+        } dom0;
+    } console;
+    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
+    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
+    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
+    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
+    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
+                                /* (PFN of pre-loaded module if           */
+                                /*  SIF_MOD_START_PFN set in flags).      */
+    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
+    int8_t cmd_line[MAX_GUEST_CMDLINE];
+    /* The pfn range here covers both page table and p->m table frames.   */
+    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
+    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
+};
+typedef struct start_info start_info_t;
+
+/* New console union for dom0 introduced in 0x00030203. */
+#if __XEN_INTERFACE_VERSION__ < 0x00030203
+#define console_mfn    console.domU.mfn
+#define console_evtchn console.domU.evtchn
+#endif
+
+/* These flags are passed in the 'flags' field of start_info_t. */
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
+#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
+
+/*
+ * A multiboot module is a package containing modules very similar to a
+ * multiboot module array. The only differences are:
+ * - the array of module descriptors is by convention simply at the beginning
+ *   of the multiboot module,
+ * - addresses in the module descriptors are based on the beginning of the
+ *   multiboot module,
+ * - the number of modules is determined by a termination descriptor that has
+ *   mod_start == 0.
+ *
+ * This permits to both build it statically and reference it in a configuration
+ * file, and let the PV guest easily rebase the addresses to virtual addresses
+ * and at the same time count the number of modules.
+ */
+struct xen_multiboot_mod_list
+{
+    /* Address of first byte of the module */
+    uint32_t mod_start;
+    /* Address of last byte of the module (inclusive) */
+    uint32_t mod_end;
+    /* Address of zero-terminated command line */
+    uint32_t cmdline;
+    /* Unused, must be zero */
+    uint32_t pad;
+};
+
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled 
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 99c8212..846f446 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
  *     extended by an extra 4MB to ensure this.
  */
 
-#define MAX_GUEST_CMDLINE 1024
-struct start_info {
-    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
-    char magic[32];             /* "xen-<version>-<platform>".            */
-    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
-    unsigned long shared_info;  /* MACHINE address of shared info struct. */
-    uint32_t flags;             /* SIF_xxx flags.                         */
-    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
-    uint32_t store_evtchn;      /* Event channel for store communication. */
-    union {
-        struct {
-            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
-            uint32_t  evtchn;   /* Event channel for console page.        */
-        } domU;
-        struct {
-            uint32_t info_off;  /* Offset of console_info struct.         */
-            uint32_t info_size; /* Size of console_info struct from start.*/
-        } dom0;
-    } console;
-    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
-    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
-    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
-    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
-    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
-                                /* (PFN of pre-loaded module if           */
-                                /*  SIF_MOD_START_PFN set in flags).      */
-    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
-    int8_t cmd_line[MAX_GUEST_CMDLINE];
-    /* The pfn range here covers both page table and p->m table frames.   */
-    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
-    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
-};
-typedef struct start_info start_info_t;
-
-/* New console union for dom0 introduced in 0x00030203. */
-#if __XEN_INTERFACE_VERSION__ < 0x00030203
-#define console_mfn    console.domU.mfn
-#define console_evtchn console.domU.evtchn
-#endif
-
-/* These flags are passed in the 'flags' field of start_info_t. */
-#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
-#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
-#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
-#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
-#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
-
-/*
- * A multiboot module is a package containing modules very similar to a
- * multiboot module array. The only differences are:
- * - the array of module descriptors is by convention simply at the beginning
- *   of the multiboot module,
- * - addresses in the module descriptors are based on the beginning of the
- *   multiboot module,
- * - the number of modules is determined by a termination descriptor that has
- *   mod_start == 0.
- *
- * This permits to both build it statically and reference it in a configuration
- * file, and let the PV guest easily rebase the addresses to virtual addresses
- * and at the same time count the number of modules.
- */
-struct xen_multiboot_mod_list
-{
-    /* Address of first byte of the module */
-    uint32_t mod_start;
-    /* Address of last byte of the module (inclusive) */
-    uint32_t mod_end;
-    /* Address of zero-terminated command line */
-    uint32_t cmdline;
-    /* Unused, must be zero */
-    uint32_t pad;
-};
-
 typedef struct dom0_vga_console_info {
     uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d4f1e3..5b0ff35 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -5,10 +5,10 @@
 ?	xenctl_cpumap			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
-!	start_info			xen.h
 ?	vcpu_info			xen.h
 ?	vcpu_time_info			xen.h
 !	cpu_user_regs			arch-x86/xen-@arch@.h
+!	start_info			arch-x86/xen.h
 !	trap_info			arch-x86/xen.h
 ?	cpu_offline_action		arch-x86/xen-mca.h
 ?	mc				arch-x86/xen-mca.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 Thu Feb 14 14:18:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zdV-00047i-2k; Thu, 14 Feb 2013 14:18:05 +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 1U5zdT-00047M-GU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:18:03 +0000
Received: from [193.109.254.147:32162] by server-9.bemta-14.messagelabs.com id
	CE/72-30867-A12FC115; Thu, 14 Feb 2013 14:18:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360851435!9296805!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5764 invoked from network); 14 Feb 2013 14:17:22 -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;
	14 Feb 2013 14:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131309"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-UM;
	Thu, 14 Feb 2013 14:16:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:13 +0000
Message-ID: <1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Most of this struct is PV MMU specific and it is not used on ARM at all.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xenctrl.h             |    5 +--
 xen/include/public/arch-x86/xen.h |   73 +++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h          |   73 -------------------------------------
 xen/include/xlat.lst              |    2 +-
 4 files changed, 76 insertions(+), 77 deletions(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 32122fd..9e4a741 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -395,15 +395,14 @@ typedef union
     shared_info_t s;
 } shared_info_any_t;
 
+#if defined(__i386__) || defined(__x86_64__)
 typedef union
 {
-#if defined(__i386__) || defined(__x86_64__)
     start_info_x86_64_t x64;
     start_info_x86_32_t x32;
-#endif
     start_info_t s;
 } start_info_any_t;
-
+#endif
 
 int xc_domain_create(xc_interface *xch,
                      uint32_t ssidref,
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 13c21dc..00f0306 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -147,6 +147,79 @@ DEFINE_XEN_GUEST_HANDLE(trap_info_t);
 
 typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
 
+#define MAX_GUEST_CMDLINE 1024
+struct start_info {
+    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
+    char magic[32];             /* "xen-<version>-<platform>".            */
+    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+    unsigned long shared_info;  /* MACHINE address of shared info struct. */
+    uint32_t flags;             /* SIF_xxx flags.                         */
+    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+    uint32_t store_evtchn;      /* Event channel for store communication. */
+    union {
+        struct {
+            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+            uint32_t  evtchn;   /* Event channel for console page.        */
+        } domU;
+        struct {
+            uint32_t info_off;  /* Offset of console_info struct.         */
+            uint32_t info_size; /* Size of console_info struct from start.*/
+        } dom0;
+    } console;
+    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
+    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
+    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
+    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
+    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
+                                /* (PFN of pre-loaded module if           */
+                                /*  SIF_MOD_START_PFN set in flags).      */
+    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
+    int8_t cmd_line[MAX_GUEST_CMDLINE];
+    /* The pfn range here covers both page table and p->m table frames.   */
+    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
+    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
+};
+typedef struct start_info start_info_t;
+
+/* New console union for dom0 introduced in 0x00030203. */
+#if __XEN_INTERFACE_VERSION__ < 0x00030203
+#define console_mfn    console.domU.mfn
+#define console_evtchn console.domU.evtchn
+#endif
+
+/* These flags are passed in the 'flags' field of start_info_t. */
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
+#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
+
+/*
+ * A multiboot module is a package containing modules very similar to a
+ * multiboot module array. The only differences are:
+ * - the array of module descriptors is by convention simply at the beginning
+ *   of the multiboot module,
+ * - addresses in the module descriptors are based on the beginning of the
+ *   multiboot module,
+ * - the number of modules is determined by a termination descriptor that has
+ *   mod_start == 0.
+ *
+ * This permits to both build it statically and reference it in a configuration
+ * file, and let the PV guest easily rebase the addresses to virtual addresses
+ * and at the same time count the number of modules.
+ */
+struct xen_multiboot_mod_list
+{
+    /* Address of first byte of the module */
+    uint32_t mod_start;
+    /* Address of last byte of the module (inclusive) */
+    uint32_t mod_end;
+    /* Address of zero-terminated command line */
+    uint32_t cmdline;
+    /* Unused, must be zero */
+    uint32_t pad;
+};
+
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled 
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 99c8212..846f446 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
  *     extended by an extra 4MB to ensure this.
  */
 
-#define MAX_GUEST_CMDLINE 1024
-struct start_info {
-    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
-    char magic[32];             /* "xen-<version>-<platform>".            */
-    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
-    unsigned long shared_info;  /* MACHINE address of shared info struct. */
-    uint32_t flags;             /* SIF_xxx flags.                         */
-    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
-    uint32_t store_evtchn;      /* Event channel for store communication. */
-    union {
-        struct {
-            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
-            uint32_t  evtchn;   /* Event channel for console page.        */
-        } domU;
-        struct {
-            uint32_t info_off;  /* Offset of console_info struct.         */
-            uint32_t info_size; /* Size of console_info struct from start.*/
-        } dom0;
-    } console;
-    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
-    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
-    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
-    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
-    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
-                                /* (PFN of pre-loaded module if           */
-                                /*  SIF_MOD_START_PFN set in flags).      */
-    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
-    int8_t cmd_line[MAX_GUEST_CMDLINE];
-    /* The pfn range here covers both page table and p->m table frames.   */
-    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
-    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
-};
-typedef struct start_info start_info_t;
-
-/* New console union for dom0 introduced in 0x00030203. */
-#if __XEN_INTERFACE_VERSION__ < 0x00030203
-#define console_mfn    console.domU.mfn
-#define console_evtchn console.domU.evtchn
-#endif
-
-/* These flags are passed in the 'flags' field of start_info_t. */
-#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
-#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
-#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
-#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
-#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
-
-/*
- * A multiboot module is a package containing modules very similar to a
- * multiboot module array. The only differences are:
- * - the array of module descriptors is by convention simply at the beginning
- *   of the multiboot module,
- * - addresses in the module descriptors are based on the beginning of the
- *   multiboot module,
- * - the number of modules is determined by a termination descriptor that has
- *   mod_start == 0.
- *
- * This permits to both build it statically and reference it in a configuration
- * file, and let the PV guest easily rebase the addresses to virtual addresses
- * and at the same time count the number of modules.
- */
-struct xen_multiboot_mod_list
-{
-    /* Address of first byte of the module */
-    uint32_t mod_start;
-    /* Address of last byte of the module (inclusive) */
-    uint32_t mod_end;
-    /* Address of zero-terminated command line */
-    uint32_t cmdline;
-    /* Unused, must be zero */
-    uint32_t pad;
-};
-
 typedef struct dom0_vga_console_info {
     uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d4f1e3..5b0ff35 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -5,10 +5,10 @@
 ?	xenctl_cpumap			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
-!	start_info			xen.h
 ?	vcpu_info			xen.h
 ?	vcpu_time_info			xen.h
 !	cpu_user_regs			arch-x86/xen-@arch@.h
+!	start_info			arch-x86/xen.h
 !	trap_info			arch-x86/xen.h
 ?	cpu_offline_action		arch-x86/xen-mca.h
 ?	mc				arch-x86/xen-mca.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 Thu Feb 14 14:18:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zdU-00047b-MB; Thu, 14 Feb 2013 14:18:04 +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 1U5zdS-00047E-Fx
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:18:02 +0000
Received: from [193.109.254.147:21192] by server-1.bemta-14.messagelabs.com id
	0B/8F-29874-912FC115; Thu, 14 Feb 2013 14:18:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360851435!9296805!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5521 invoked from network); 14 Feb 2013 14:17:17 -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;
	14 Feb 2013 14:17:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131308"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-V4;
	Thu, 14 Feb 2013 14:16:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:14 +0000
Message-ID: <1360851374-28326-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen: arm: include public/xen.h in foreign
	interface checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

mkheader.py doesn't cope with
	structr foo { };
so add a newline.

Define unsigned long and long to a non-existent type on ARM so as to catch
their use.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-foreign/Makefile       |    2 +-
 tools/include/xen-foreign/mkheader.py    |    4 ++--
 tools/include/xen-foreign/reference.size |   10 +++++-----
 xen/include/public/arch-arm.h            |    8 +++++---
 4 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 5bc2d46..53cc6b4 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 685ab8e..1a0d76f 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -18,8 +18,8 @@ footer = {};
 
 #arm
 inttypes["arm32"] = {
-    "unsigned long" : "uint32_t",
-    "long"          : "uint32_t",
+    "unsigned long" : "__danger_unsigned_long_on_arm32",
+    "long"          : "__danger_long_on_arm32",
     "xen_pfn_t"     : "uint64_t",
     "xen_ulong_t"   : "uint64_t",
 };
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 9f1bfac..0e5529d 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -5,9 +5,9 @@ start_info                |       -    1112    1168
 trap_info                 |       -       8      16
 cpu_user_regs             |     160      68     200
 vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+arch_vcpu_info            |       0      24      16
+vcpu_time_info            |      32      32      32
+vcpu_info                 |      48      64      64
+arch_shared_info          |       0     268     280
+shared_info               |    1088    2584    3368
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index d8788f2..8dd9062 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -159,14 +159,16 @@ struct vcpu_guest_context {
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
-struct arch_vcpu_info { };
+struct arch_vcpu_info {
+};
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
-struct arch_shared_info { };
+struct arch_shared_info {
+};
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif /* ifndef __ASSEMBLY __ */
+#endif
 
 /* PSR bits (CPSR, SPSR)*/
 
-- 
1.7.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 Feb 14 14:18:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zdU-00047b-MB; Thu, 14 Feb 2013 14:18:04 +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 1U5zdS-00047E-Fx
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:18:02 +0000
Received: from [193.109.254.147:21192] by server-1.bemta-14.messagelabs.com id
	0B/8F-29874-912FC115; Thu, 14 Feb 2013 14:18:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360851435!9296805!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5521 invoked from network); 14 Feb 2013 14:17:17 -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;
	14 Feb 2013 14:17:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131308"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:16:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:16:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zbi-00070U-V4;
	Thu, 14 Feb 2013 14:16:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:16:14 +0000
Message-ID: <1360851374-28326-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen: arm: include public/xen.h in foreign
	interface checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

mkheader.py doesn't cope with
	structr foo { };
so add a newline.

Define unsigned long and long to a non-existent type on ARM so as to catch
their use.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-foreign/Makefile       |    2 +-
 tools/include/xen-foreign/mkheader.py    |    4 ++--
 tools/include/xen-foreign/reference.size |   10 +++++-----
 xen/include/public/arch-arm.h            |    8 +++++---
 4 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 5bc2d46..53cc6b4 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 685ab8e..1a0d76f 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -18,8 +18,8 @@ footer = {};
 
 #arm
 inttypes["arm32"] = {
-    "unsigned long" : "uint32_t",
-    "long"          : "uint32_t",
+    "unsigned long" : "__danger_unsigned_long_on_arm32",
+    "long"          : "__danger_long_on_arm32",
     "xen_pfn_t"     : "uint64_t",
     "xen_ulong_t"   : "uint64_t",
 };
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 9f1bfac..0e5529d 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -5,9 +5,9 @@ start_info                |       -    1112    1168
 trap_info                 |       -       8      16
 cpu_user_regs             |     160      68     200
 vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+arch_vcpu_info            |       0      24      16
+vcpu_time_info            |      32      32      32
+vcpu_info                 |      48      64      64
+arch_shared_info          |       0     268     280
+shared_info               |    1088    2584    3368
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index d8788f2..8dd9062 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -159,14 +159,16 @@ struct vcpu_guest_context {
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
-struct arch_vcpu_info { };
+struct arch_vcpu_info {
+};
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
-struct arch_shared_info { };
+struct arch_shared_info {
+};
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif /* ifndef __ASSEMBLY __ */
+#endif
 
 /* PSR bits (CPSR, SPSR)*/
 
-- 
1.7.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 Feb 14 14:20:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zfJ-0004T3-5E; Thu, 14 Feb 2013 14:19: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 1U5zfH-0004SX-MS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:19:56 +0000
Received: from [85.158.139.83:4376] by server-12.bemta-5.messagelabs.com id
	1A/4E-20195-B82FC115; Thu, 14 Feb 2013 14:19:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360851591!23662299!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17823 invoked from network); 14 Feb 2013 14:19:54 -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;
	14 Feb 2013 14:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131815"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:19:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:19:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zfC-00073T-SC;
	Thu, 14 Feb 2013 14:19:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:19:50 +0000
Message-ID: <1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARM has no start info. Although it does not existing in the hypervisor ABI we
synthesize one for the benefit of the common code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h |   24 +++++++++++++++++++++++
 arch/x86/include/asm/xen/interface.h |   35 ++++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h          |   33 --------------------------------
 3 files changed, 59 insertions(+), 33 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1151188..1db40d5 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
+/*
+ * On ARM this is not part of the hypervisor ABI but we provide it
+ * internally for the benefit of common code.
+ */
+struct start_info {
+        uint32_t flags;             /* SIF_xxx flags.                         */
+        uint32_t store_evtchn;      /* Event channel for store communication. */
+        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+        union {
+                struct {
+                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+                        uint32_t  evtchn;   /* Event channel for console page.        */
+                } domU;
+                struct {
+                        uint32_t info_off;  /* Offset of console_info struct.         */
+                        uint32_t info_size; /* Size of console_info struct from start.*/
+                } dom0;
+        } console;
+	/* UNUSED ON ARM */
+        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+};
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index fd9cb76..ca9a203 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -131,6 +131,41 @@ struct arch_shared_info {
 #include <asm/pvclock-abi.h>
 
 #ifndef __ASSEMBLY__
+
+
+#define MAX_GUEST_CMDLINE 1024
+struct start_info {
+    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
+    char magic[32];             /* "xen-<version>-<platform>".            */
+    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+    unsigned long shared_info;  /* MACHINE address of shared info struct. */
+    uint32_t flags;             /* SIF_xxx flags.                         */
+    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+    uint32_t store_evtchn;      /* Event channel for store communication. */
+    union {
+        struct {
+            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+            uint32_t  evtchn;   /* Event channel for console page.        */
+        } domU;
+        struct {
+            uint32_t info_off;  /* Offset of console_info struct.         */
+            uint32_t info_size; /* Size of console_info struct from start.*/
+        } dom0;
+    } console;
+    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
+    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
+    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
+    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
+    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
+    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
+    int8_t cmd_line[MAX_GUEST_CMDLINE];
+};
+
+/* These flags are passed in the 'flags' field of start_info_t. */
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
+
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 53ec416..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -422,34 +422,6 @@ struct shared_info {
  *     extended by an extra 4MB to ensure this.
  */
 
-#define MAX_GUEST_CMDLINE 1024
-struct start_info {
-	/* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
-	char magic[32];             /* "xen-<version>-<platform>".            */
-	unsigned long nr_pages;     /* Total pages allocated to this domain.  */
-	unsigned long shared_info;  /* MACHINE address of shared info struct. */
-	uint32_t flags;             /* SIF_xxx flags.                         */
-	xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
-	uint32_t store_evtchn;      /* Event channel for store communication. */
-	union {
-		struct {
-			xen_pfn_t mfn;      /* MACHINE page number of console page.   */
-			uint32_t  evtchn;   /* Event channel for console page.        */
-		} domU;
-		struct {
-			uint32_t info_off;  /* Offset of console_info struct.         */
-			uint32_t info_size; /* Size of console_info struct from start.*/
-		} dom0;
-	} console;
-	/* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
-	unsigned long pt_base;      /* VIRTUAL address of page directory.     */
-	unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
-	unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
-	unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
-	unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
-	int8_t cmd_line[MAX_GUEST_CMDLINE];
-};
-
 struct dom0_vga_console_info {
 	uint8_t video_type;
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
@@ -490,11 +462,6 @@ struct dom0_vga_console_info {
 	} u;
 };
 
-/* These flags are passed in the 'flags' field of start_info_t. */
-#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
-#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
-#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
-
 typedef uint64_t cpumap_t;
 
 typedef uint8_t xen_domain_handle_t[16];
-- 
1.7.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 Feb 14 14:20:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zfJ-0004T3-5E; Thu, 14 Feb 2013 14:19: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 1U5zfH-0004SX-MS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:19:56 +0000
Received: from [85.158.139.83:4376] by server-12.bemta-5.messagelabs.com id
	1A/4E-20195-B82FC115; Thu, 14 Feb 2013 14:19:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360851591!23662299!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17823 invoked from network); 14 Feb 2013 14:19:54 -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;
	14 Feb 2013 14:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131815"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:19:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:19:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zfC-00073T-SC;
	Thu, 14 Feb 2013 14:19:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:19:50 +0000
Message-ID: <1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARM has no start info. Although it does not existing in the hypervisor ABI we
synthesize one for the benefit of the common code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h |   24 +++++++++++++++++++++++
 arch/x86/include/asm/xen/interface.h |   35 ++++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h          |   33 --------------------------------
 3 files changed, 59 insertions(+), 33 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1151188..1db40d5 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
+/*
+ * On ARM this is not part of the hypervisor ABI but we provide it
+ * internally for the benefit of common code.
+ */
+struct start_info {
+        uint32_t flags;             /* SIF_xxx flags.                         */
+        uint32_t store_evtchn;      /* Event channel for store communication. */
+        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+        union {
+                struct {
+                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+                        uint32_t  evtchn;   /* Event channel for console page.        */
+                } domU;
+                struct {
+                        uint32_t info_off;  /* Offset of console_info struct.         */
+                        uint32_t info_size; /* Size of console_info struct from start.*/
+                } dom0;
+        } console;
+	/* UNUSED ON ARM */
+        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+};
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
 
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index fd9cb76..ca9a203 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -131,6 +131,41 @@ struct arch_shared_info {
 #include <asm/pvclock-abi.h>
 
 #ifndef __ASSEMBLY__
+
+
+#define MAX_GUEST_CMDLINE 1024
+struct start_info {
+    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
+    char magic[32];             /* "xen-<version>-<platform>".            */
+    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+    unsigned long shared_info;  /* MACHINE address of shared info struct. */
+    uint32_t flags;             /* SIF_xxx flags.                         */
+    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+    uint32_t store_evtchn;      /* Event channel for store communication. */
+    union {
+        struct {
+            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+            uint32_t  evtchn;   /* Event channel for console page.        */
+        } domU;
+        struct {
+            uint32_t info_off;  /* Offset of console_info struct.         */
+            uint32_t info_size; /* Size of console_info struct from start.*/
+        } dom0;
+    } console;
+    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
+    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
+    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
+    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
+    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
+    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
+    int8_t cmd_line[MAX_GUEST_CMDLINE];
+};
+
+/* These flags are passed in the 'flags' field of start_info_t. */
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
+
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 53ec416..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -422,34 +422,6 @@ struct shared_info {
  *     extended by an extra 4MB to ensure this.
  */
 
-#define MAX_GUEST_CMDLINE 1024
-struct start_info {
-	/* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
-	char magic[32];             /* "xen-<version>-<platform>".            */
-	unsigned long nr_pages;     /* Total pages allocated to this domain.  */
-	unsigned long shared_info;  /* MACHINE address of shared info struct. */
-	uint32_t flags;             /* SIF_xxx flags.                         */
-	xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
-	uint32_t store_evtchn;      /* Event channel for store communication. */
-	union {
-		struct {
-			xen_pfn_t mfn;      /* MACHINE page number of console page.   */
-			uint32_t  evtchn;   /* Event channel for console page.        */
-		} domU;
-		struct {
-			uint32_t info_off;  /* Offset of console_info struct.         */
-			uint32_t info_size; /* Size of console_info struct from start.*/
-		} dom0;
-	} console;
-	/* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
-	unsigned long pt_base;      /* VIRTUAL address of page directory.     */
-	unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
-	unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
-	unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
-	unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
-	int8_t cmd_line[MAX_GUEST_CMDLINE];
-};
-
 struct dom0_vga_console_info {
 	uint8_t video_type;
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
@@ -490,11 +462,6 @@ struct dom0_vga_console_info {
 	} u;
 };
 
-/* These flags are passed in the 'flags' field of start_info_t. */
-#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
-#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
-#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
-
 typedef uint64_t cpumap_t;
 
 typedef uint8_t xen_domain_handle_t[16];
-- 
1.7.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 Feb 14 14:20:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zfI-0004Sn-Kw; Thu, 14 Feb 2013 14:19: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 1U5zfH-0004SQ-0X
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:19:55 +0000
Received: from [85.158.139.83:6184] by server-5.bemta-5.messagelabs.com id
	9F/73-11945-A82FC115; Thu, 14 Feb 2013 14:19:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360851591!23662299!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17496 invoked from network); 14 Feb 2013 14:19:53 -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;
	14 Feb 2013 14:19:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131814"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:19:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:19:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zfC-00073T-RY;
	Thu, 14 Feb 2013 14:19:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:19:49 +0000
Message-ID: <1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/events.h |   22 +++++++++++
 arch/x86/include/asm/xen/events.h |    2 +
 drivers/xen/events.c              |   75 ++++++++++++++++++++----------------
 include/xen/interface/xen.h       |    8 ++--
 4 files changed, 70 insertions(+), 37 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..92dbb89 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xen_read_evtchn_pending_sel(struct vcpu_info *vcpu_info)
+{
+	xen_ulong_t val;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ read_evtchn_pending_sel\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+			: "=&r" (val), "=&r" (tmp)
+			: "r" (0), "r" (&vcpu_info->evtchn_pending_sel)
+			: "memory", "cc");
+	return val;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..55edd58 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,6 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+#define xen_read_evtchn_pending_sel(v) xchg(&(v)->evtchn_pending_sel, 0)
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..e90a440 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +383,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +397,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +411,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +419,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1197,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1213,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,25 +1222,27 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
@@ -1247,16 +1257,16 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1304,9 +1314,8 @@ static void __xen_evtchn_do_upcall(void)
 
 #ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
 		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
 #endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		pending_words = xen_read_evtchn_pending_sel(vcpu_info);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1355,7 +1364,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = __ffs(bits);
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1373,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1386,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1496,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1545,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 886a5d8..53ec416 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 14 14:20:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zfI-0004Sn-Kw; Thu, 14 Feb 2013 14:19: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 1U5zfH-0004SQ-0X
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:19:55 +0000
Received: from [85.158.139.83:6184] by server-5.bemta-5.messagelabs.com id
	9F/73-11945-A82FC115; Thu, 14 Feb 2013 14:19:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360851591!23662299!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17496 invoked from network); 14 Feb 2013 14:19:53 -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;
	14 Feb 2013 14:19:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7131814"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:19:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:19:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U5zfC-00073T-RY;
	Thu, 14 Feb 2013 14:19:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:19:49 +0000
Message-ID: <1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/events.h |   22 +++++++++++
 arch/x86/include/asm/xen/events.h |    2 +
 drivers/xen/events.c              |   75 ++++++++++++++++++++----------------
 include/xen/interface/xen.h       |    8 ++--
 4 files changed, 70 insertions(+), 37 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..92dbb89 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xen_read_evtchn_pending_sel(struct vcpu_info *vcpu_info)
+{
+	xen_ulong_t val;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ read_evtchn_pending_sel\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+			: "=&r" (val), "=&r" (tmp)
+			: "r" (0), "r" (&vcpu_info->evtchn_pending_sel)
+			: "memory", "cc");
+	return val;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..55edd58 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,6 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+#define xen_read_evtchn_pending_sel(v) xchg(&(v)->evtchn_pending_sel, 0)
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..e90a440 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +383,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +397,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +411,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +419,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1197,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1213,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,25 +1222,27 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
@@ -1247,16 +1257,16 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1304,9 +1314,8 @@ static void __xen_evtchn_do_upcall(void)
 
 #ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
 		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
 #endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		pending_words = xen_read_evtchn_pending_sel(vcpu_info);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1355,7 +1364,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = __ffs(bits);
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1373,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1386,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1496,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1545,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 886a5d8..53ec416 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 14 14:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:20: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 1U5zfR-0004Vm-I8; Thu, 14 Feb 2013 14:20:05 +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 1U5zfP-0004Uj-V8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:20:04 +0000
Received: from [85.158.139.211:8178] by server-4.bemta-5.messagelabs.com id
	88/20-29496-392FC115; Thu, 14 Feb 2013 14:20:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360851602!22467177!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11662 invoked from network); 14 Feb 2013 14:20:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:20:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:20: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.297.1;
	Thu, 14 Feb 2013 14:20:02 +0000
Message-ID: <1360851600.20449.400.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:20:00 +0000
In-Reply-To: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/NN] linux: public interface changes for
 arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ahem, NN == 02. Sorry.

On Thu, 2013-02-14 at 14:16 +0000, Ian Campbell wrote:
> The main change here is to switch evtchns to xen_ulong_t on arm, this
> enables us to have the same interface on arm32 and arm64. This is an ABI
> change for ARM but not x86. This is a counterpart to the Xen patch just
> posted.
> 
> In that series I also made start_info x86 specific. ARM does not use
> this struct in its ABI but for convenience in non-arch specific code I
> have included an internal (non ABI) version on ARM too. Long term
> perhaps we should consider improving the abstraction used in the common
> code to avoid this.
> 
> 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 Feb 14 14:20:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:20: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 1U5zfR-0004Vm-I8; Thu, 14 Feb 2013 14:20:05 +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 1U5zfP-0004Uj-V8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:20:04 +0000
Received: from [85.158.139.211:8178] by server-4.bemta-5.messagelabs.com id
	88/20-29496-392FC115; Thu, 14 Feb 2013 14:20:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360851602!22467177!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11662 invoked from network); 14 Feb 2013 14:20:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:20:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1463631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:20: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.297.1;
	Thu, 14 Feb 2013 14:20:02 +0000
Message-ID: <1360851600.20449.400.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 14:20:00 +0000
In-Reply-To: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/NN] linux: public interface changes for
 arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ahem, NN == 02. Sorry.

On Thu, 2013-02-14 at 14:16 +0000, Ian Campbell wrote:
> The main change here is to switch evtchns to xen_ulong_t on arm, this
> enables us to have the same interface on arm32 and arm64. This is an ABI
> change for ARM but not x86. This is a counterpart to the Xen patch just
> posted.
> 
> In that series I also made start_info x86 specific. ARM does not use
> this struct in its ABI but for convenience in non-arch specific code I
> have included an internal (non ABI) version on ARM too. Long term
> perhaps we should consider improving the abstraction used in the common
> code to avoid this.
> 
> 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 Feb 14 14:21:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:21: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 1U5zgu-0004rU-37; Thu, 14 Feb 2013 14:21:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1U5zgs-0004rA-Qj
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:21:34 +0000
Received: from [85.158.143.99:46075] by server-1.bemta-4.messagelabs.com id
	5E/9B-08839-EE2FC115; Thu, 14 Feb 2013 14:21:34 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360851642!16108109!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14621 invoked from network); 14 Feb 2013 14:20:43 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:20:43 -0000
Received: (qmail 25624 invoked from network); 14 Feb 2013 16:19:40 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 16:19:39 +0200
Message-ID: <511CF283.3080608@gmail.com>
Date: Thu, 14 Feb 2013 16:19:47 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
	<CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
	<1360851217.20449.395.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360851217.20449.395.camel@zakaz.uk.xensource.com>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.6.156201, Dats:
	245768, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_LEGIT_VALID_REPLY; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_S_SQARE_BRACKETS;
	NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], URI DNSBL:
	[Disabled], SQMD: [Enabled, Hits: none, MD5:
	814d1852ceae04e16865bd39c860f86a.fuzzy.fzrbl.org], RTDA: [Enabled,
	Hit: No, Details: v1.4.7; Id: 2m1g3ta.17jcctoa8.8r85], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45440
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
	destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

>> As i understand if i want to know what domains dies i need after fired
>> watch enumerate all domains and check its status.
>
> Well, if you only care about one domain you just need to check that one
> domain.
>
> Otherwise you should look at the libxl functionality I mentioned before.

There's also tools/xenpaging/xenpaging.c that can be used as an example.

Cheers,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:21:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:21: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 1U5zgu-0004rU-37; Thu, 14 Feb 2013 14:21:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1U5zgs-0004rA-Qj
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:21:34 +0000
Received: from [85.158.143.99:46075] by server-1.bemta-4.messagelabs.com id
	5E/9B-08839-EE2FC115; Thu, 14 Feb 2013 14:21:34 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360851642!16108109!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14621 invoked from network); 14 Feb 2013 14:20:43 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:20:43 -0000
Received: (qmail 25624 invoked from network); 14 Feb 2013 16:19:40 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 16:19:39 +0200
Message-ID: <511CF283.3080608@gmail.com>
Date: Thu, 14 Feb 2013 16:19:47 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
	<CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
	<1360851217.20449.395.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360851217.20449.395.camel@zakaz.uk.xensource.com>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.6.156201, Dats:
	245768, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_LEGIT_VALID_REPLY; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_S_SQARE_BRACKETS;
	NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], URI DNSBL:
	[Disabled], SQMD: [Enabled, Hits: none, MD5:
	814d1852ceae04e16865bd39c860f86a.fuzzy.fzrbl.org], RTDA: [Enabled,
	Hit: No, Details: v1.4.7; Id: 2m1g3ta.17jcctoa8.8r85], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45440
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
	destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

>> As i understand if i want to know what domains dies i need after fired
>> watch enumerate all domains and check its status.
>
> Well, if you only care about one domain you just need to check that one
> domain.
>
> Otherwise you should look at the libxl functionality I mentioned before.

There's also tools/xenpaging/xenpaging.c that can be used as an example.

Cheers,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:21:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:21: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 1U5zgy-0004sT-Gf; Thu, 14 Feb 2013 14:21:40 +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 1U5zgw-0004s6-JZ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:21:38 +0000
Received: from [85.158.137.99:6696] by server-2.bemta-3.messagelabs.com id
	CA/28-25961-1F2FC115; Thu, 14 Feb 2013 14:21:37 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360851696!19143469!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28538 invoked from network); 14 Feb 2013 14:21:36 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-217.messagelabs.com with SMTP;
	14 Feb 2013 14:21:36 -0000
Received: from p5b2e3d19.dip.t-dialin.net ([91.46.61.25] 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 1U5zgX-0002to-9x; Thu, 14 Feb 2013 14:21:13 +0000
Message-ID: <511CF2D7.6090004@canonical.com>
Date: Thu, 14 Feb 2013 15:21:11 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51151ABF.1070007@canonical.com> <511CC4D8.3060203@canonical.com>
	<511CDBF302000078000BE2D7@nat28.tlf.novell.com>
In-Reply-To: <511CDBF302000078000BE2D7@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="===============7694255929101596411=="
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)
--===============7694255929101596411==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig915666D3C4E4B680CA8FFC0C"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig915666D3C4E4B680CA8FFC0C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14.02.2013 12:43, Jan Beulich wrote:
>>>> On 14.02.13 at 12:04, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> There was a bit more on the stack but try_to_wake_up seemed a believab=
le=20
>> current
>> path. Even more so after looking into the function:
>>
>> #ifdef CONFIG_SMP
>>         /*
>>          * If the owning (remote) cpu is still in the middle of schedu=
le() with
>>          * this task as prev, wait until its done referencing the task=
=2E
>>          */
>>         while (p->on_cpu) {
>> #ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
>>                 /*
>>                  * In case the architecture enables interrupts in
>>                  * context_switch(), we cannot busy wait, since that
>>                  * would lead to deadlocks when an interrupt hits and
>>                  * tries to wake up @prev. So bail and do a complete
>>                  * remote wakeup.
>>                  */
>>                 if (ttwu_activate_remote(p, wake_flags))
>>                         goto stat;
>> #else
>>                 cpu_relax();
>> #endif
>>
>> And prying out the task in question from the stack, it was one current=
ly
>> being accounted for VCPU 6 and on_cpu. VCPU 6 is one of the other wait=
ers=20
>> for
>> the runq lock of VCPU 1. Which would get picked up as soon as this cal=
lback=20
>> is
>> done. Unfortunately we "stay awhile... stay forever!".
>=20
> When analyzing a similar problem with our old PV ticket lock
> implementation (and the interrupt re-enabling there when possible
> before going into polling mode), it was precisely this open coded
> lock construct that caused problems for us. Back then I didn't,
> however, realize that this would even affect the simplistic byte
> locks used by the pv-ops Xen code (or else I would have pointed
> this out).
>=20
> Being relatively certain that with our new implementation we don't
> have any such problems, I can only recommend against dropping
> the re-enabling of interrupts - this needlessly introduces high
> interrupt latencies in a broader range of cases. Instead, the
> interactions ought to be fixed properly. And it's time for using
> ticket locks in the Xen code too...
>=20
Not sure what *your new* implementation is. ;) I am more concerned about =
the
currently released/stable kernels which potentially have this problem. I =
agree
that a proper solution is preferable. Ticket locks likely have a much low=
er
chance of hitting this as part of the current problem is that lower numbe=
r VCPUs
are preferred in unlock_slow.
In the end, though, we would need something that could go upstream (and f=
rom
there back into stable). So it should not be too complicated. Then a prop=
er
solution can be applied.
Having more understanding now, I had a different idea. Not sure this is
foolproof and surely is causing some more active spinning. But it looks l=
ike I
also can keep the system from locking up (v3.2 kernel and the testcase) i=
f I
change xen_spin_unlock_slow to send the wakeup IPI to _all_ spinners inst=
ead of
only the first one found.

-Stefan


--------------enig915666D3C4E4B680CA8FFC0C
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHPLXAAoJEOhnXe7L7s6jtTcP/3xGjsOfdIWtrctq4+F361+U
5wIC4In0i6CTxmP5qAKaLsNJjj02h9HZkZ2qYg763Svs1KYqX2pZlZowk6E+sS3X
jR11JU56MMtR4Wyf8VTtCZcEBGvbPzC4ygtbveTLOQ+w2QlrQLTWqmYiqE9AiG+N
gP+0XG4ICoP0B6kP/UnqDDXqJH0eBhao44WRfN0IHODTJgXxRLox1crvwB9rc7dM
wUTco9BMy4xapAdxiNQRJsK7oHk+i+yZzKAEWg9nNFIyOzA7icaW5kws+E3Sp8Da
xgg0DjN7kBYMUg1O3jp5mkfb8MAC5QOz02zI0tp6xX8DA7NsWht5zvgQG2L6NhDj
9oAVSFnY//TeZMBozPpjaJ88vL0RIXebbn7oEkUA96C9GH/hCw4cPJaYzIpHhCs4
VWadGN2Y22x6bFqjYcS1VRHPcvokdeblw3odmBW0CxYZ4AXtWBbzH7+8KPXd1BAb
c65Npgt0iLVfCKcxeUs4NfnVSn9ijvSyvPwbRgf2a3A4pEeNNQu3cn62d3f1gxg1
RRkh+HysySM0xT3ZB8LIWrnrKkwveTOeto9g08FSd1P2fiUQ4SXtjbU9UZcgj5+v
tmeuQ/B9Ci+7U3oEgwG2wRY+X1FlD6ngcvQxEmr3WSOsf8/+IS5rrfzDrYRAwik+
FvAcu0ybws2vxMyYYsVv
=WCR+
-----END PGP SIGNATURE-----

--------------enig915666D3C4E4B680CA8FFC0C--


--===============7694255929101596411==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7694255929101596411==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 14:21:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:21: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 1U5zgy-0004sT-Gf; Thu, 14 Feb 2013 14:21:40 +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 1U5zgw-0004s6-JZ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:21:38 +0000
Received: from [85.158.137.99:6696] by server-2.bemta-3.messagelabs.com id
	CA/28-25961-1F2FC115; Thu, 14 Feb 2013 14:21:37 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360851696!19143469!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28538 invoked from network); 14 Feb 2013 14:21:36 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-217.messagelabs.com with SMTP;
	14 Feb 2013 14:21:36 -0000
Received: from p5b2e3d19.dip.t-dialin.net ([91.46.61.25] 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 1U5zgX-0002to-9x; Thu, 14 Feb 2013 14:21:13 +0000
Message-ID: <511CF2D7.6090004@canonical.com>
Date: Thu, 14 Feb 2013 15:21:11 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51151ABF.1070007@canonical.com> <511CC4D8.3060203@canonical.com>
	<511CDBF302000078000BE2D7@nat28.tlf.novell.com>
In-Reply-To: <511CDBF302000078000BE2D7@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.6
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="===============7694255929101596411=="
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)
--===============7694255929101596411==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig915666D3C4E4B680CA8FFC0C"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig915666D3C4E4B680CA8FFC0C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14.02.2013 12:43, Jan Beulich wrote:
>>>> On 14.02.13 at 12:04, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> There was a bit more on the stack but try_to_wake_up seemed a believab=
le=20
>> current
>> path. Even more so after looking into the function:
>>
>> #ifdef CONFIG_SMP
>>         /*
>>          * If the owning (remote) cpu is still in the middle of schedu=
le() with
>>          * this task as prev, wait until its done referencing the task=
=2E
>>          */
>>         while (p->on_cpu) {
>> #ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
>>                 /*
>>                  * In case the architecture enables interrupts in
>>                  * context_switch(), we cannot busy wait, since that
>>                  * would lead to deadlocks when an interrupt hits and
>>                  * tries to wake up @prev. So bail and do a complete
>>                  * remote wakeup.
>>                  */
>>                 if (ttwu_activate_remote(p, wake_flags))
>>                         goto stat;
>> #else
>>                 cpu_relax();
>> #endif
>>
>> And prying out the task in question from the stack, it was one current=
ly
>> being accounted for VCPU 6 and on_cpu. VCPU 6 is one of the other wait=
ers=20
>> for
>> the runq lock of VCPU 1. Which would get picked up as soon as this cal=
lback=20
>> is
>> done. Unfortunately we "stay awhile... stay forever!".
>=20
> When analyzing a similar problem with our old PV ticket lock
> implementation (and the interrupt re-enabling there when possible
> before going into polling mode), it was precisely this open coded
> lock construct that caused problems for us. Back then I didn't,
> however, realize that this would even affect the simplistic byte
> locks used by the pv-ops Xen code (or else I would have pointed
> this out).
>=20
> Being relatively certain that with our new implementation we don't
> have any such problems, I can only recommend against dropping
> the re-enabling of interrupts - this needlessly introduces high
> interrupt latencies in a broader range of cases. Instead, the
> interactions ought to be fixed properly. And it's time for using
> ticket locks in the Xen code too...
>=20
Not sure what *your new* implementation is. ;) I am more concerned about =
the
currently released/stable kernels which potentially have this problem. I =
agree
that a proper solution is preferable. Ticket locks likely have a much low=
er
chance of hitting this as part of the current problem is that lower numbe=
r VCPUs
are preferred in unlock_slow.
In the end, though, we would need something that could go upstream (and f=
rom
there back into stable). So it should not be too complicated. Then a prop=
er
solution can be applied.
Having more understanding now, I had a different idea. Not sure this is
foolproof and surely is causing some more active spinning. But it looks l=
ike I
also can keep the system from locking up (v3.2 kernel and the testcase) i=
f I
change xen_spin_unlock_slow to send the wakeup IPI to _all_ spinners inst=
ead of
only the first one found.

-Stefan


--------------enig915666D3C4E4B680CA8FFC0C
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHPLXAAoJEOhnXe7L7s6jtTcP/3xGjsOfdIWtrctq4+F361+U
5wIC4In0i6CTxmP5qAKaLsNJjj02h9HZkZ2qYg763Svs1KYqX2pZlZowk6E+sS3X
jR11JU56MMtR4Wyf8VTtCZcEBGvbPzC4ygtbveTLOQ+w2QlrQLTWqmYiqE9AiG+N
gP+0XG4ICoP0B6kP/UnqDDXqJH0eBhao44WRfN0IHODTJgXxRLox1crvwB9rc7dM
wUTco9BMy4xapAdxiNQRJsK7oHk+i+yZzKAEWg9nNFIyOzA7icaW5kws+E3Sp8Da
xgg0DjN7kBYMUg1O3jp5mkfb8MAC5QOz02zI0tp6xX8DA7NsWht5zvgQG2L6NhDj
9oAVSFnY//TeZMBozPpjaJ88vL0RIXebbn7oEkUA96C9GH/hCw4cPJaYzIpHhCs4
VWadGN2Y22x6bFqjYcS1VRHPcvokdeblw3odmBW0CxYZ4AXtWBbzH7+8KPXd1BAb
c65Npgt0iLVfCKcxeUs4NfnVSn9ijvSyvPwbRgf2a3A4pEeNNQu3cn62d3f1gxg1
RRkh+HysySM0xT3ZB8LIWrnrKkwveTOeto9g08FSd1P2fiUQ4SXtjbU9UZcgj5+v
tmeuQ/B9Ci+7U3oEgwG2wRY+X1FlD6ngcvQxEmr3WSOsf8/+IS5rrfzDrYRAwik+
FvAcu0ybws2vxMyYYsVv
=WCR+
-----END PGP SIGNATURE-----

--------------enig915666D3C4E4B680CA8FFC0C--


--===============7694255929101596411==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7694255929101596411==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 14:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:22: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 1U5zhe-00053e-Vk; Thu, 14 Feb 2013 14:22:22 +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 1U5zhe-00053K-9X
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:22:22 +0000
Received: from [85.158.139.83:44954] by server-11.bemta-5.messagelabs.com id
	ED/99-19159-D13FC115; Thu, 14 Feb 2013 14:22:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360851739!21025763!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17615 invoked from network); 14 Feb 2013 14:22:20 -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;
	14 Feb 2013 14:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7132074"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:21:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:21:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5zh1-00075E-Aa;
	Thu, 14 Feb 2013 14:21:43 +0000
Message-ID: <1360851703.16636.146.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 14:21:43 +0000
In-Reply-To: <511CFF8A02000078000BE4B2@nat28.tlf.novell.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
	<511CFF8A02000078000BE4B2@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 14:15 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 14:53, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >> 
> >> If the credit timer is left armed after calling
> >> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> >> the vif which will then oops as vif->netbk == NULL.
> >> 
> >> This may happen both in the fatal error path and during normal
> >> disconnection from the front end.
> >> 
> >> The sequencing during shutdown is critical to ensure that: a)
> >> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> >> is not freed.
> >> 
> >> 1. Mark as unschedulable (netif_carrier_off()).
> >> 2. Synchronously cancel the timer.
> >> 3. Remove the vif from the schedule list.
> >> 4. Remove it from it netback thread group.
> >> 5. Wait for vif->refcnt to become 0.
> >> 
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > 
> > You would need to reinitialize the timer in xenvif_up, given that user
> > might `ifconfig vifX.X down; ifconfig vifX.X up`.
> 
> Which gets us to another aspect of the original fix that I don't
> think was considered: Is there anything preventing the interface
> to be brought back up after fatal_tx_err() shut it down?
> 

I don't think so. Code could / should not prevent host admin from doing
anything he wants - even it is re-enabling a malicious vif. ;-)


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:22: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 1U5zhe-00053e-Vk; Thu, 14 Feb 2013 14:22:22 +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 1U5zhe-00053K-9X
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:22:22 +0000
Received: from [85.158.139.83:44954] by server-11.bemta-5.messagelabs.com id
	ED/99-19159-D13FC115; Thu, 14 Feb 2013 14:22:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360851739!21025763!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17615 invoked from network); 14 Feb 2013 14:22:20 -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;
	14 Feb 2013 14:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7132074"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 14:21:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 09:21:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U5zh1-00075E-Aa;
	Thu, 14 Feb 2013 14:21:43 +0000
Message-ID: <1360851703.16636.146.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 14:21:43 +0000
In-Reply-To: <511CFF8A02000078000BE4B2@nat28.tlf.novell.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360849999.16636.135.camel@zion.uk.xensource.com>
	<511CFF8A02000078000BE4B2@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	KonradRzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 14:15 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 14:53, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >> 
> >> If the credit timer is left armed after calling
> >> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> >> the vif which will then oops as vif->netbk == NULL.
> >> 
> >> This may happen both in the fatal error path and during normal
> >> disconnection from the front end.
> >> 
> >> The sequencing during shutdown is critical to ensure that: a)
> >> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> >> is not freed.
> >> 
> >> 1. Mark as unschedulable (netif_carrier_off()).
> >> 2. Synchronously cancel the timer.
> >> 3. Remove the vif from the schedule list.
> >> 4. Remove it from it netback thread group.
> >> 5. Wait for vif->refcnt to become 0.
> >> 
> >> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > 
> > You would need to reinitialize the timer in xenvif_up, given that user
> > might `ifconfig vifX.X down; ifconfig vifX.X up`.
> 
> Which gets us to another aspect of the original fix that I don't
> think was considered: Is there anything preventing the interface
> to be brought back up after fatal_tx_err() shut it down?
> 

I don't think so. Code could / should not prevent host admin from doing
anything he wants - even it is re-enabling a malicious vif. ;-)


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:24:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zjX-0005PP-3h; Thu, 14 Feb 2013 14:24:19 +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 1U5zjW-0005P6-LB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:24:18 +0000
Received: from [85.158.137.99:55030] by server-2.bemta-3.messagelabs.com id
	F7/1D-25961-193FC115; Thu, 14 Feb 2013 14:24:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360851856!18261568!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8993 invoked from network); 14 Feb 2013 14:24:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:24:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zjU-000Mcc-6a; Thu, 14 Feb 2013 14:24:16 +0000
Date: Thu, 14 Feb 2013 14:24:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214142416.GW83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 28/45] xen: arm: arm64 trap 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

At 15:56 +0000 on 23 Jan (1358956594), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index 815f305..be41f43 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,5 +1,7 @@
>  subdir-y += lib
>  
> +obj-y += entry.o
>  obj-y += mode_switch.o
>  
> +obj-y += traps.o
>  obj-y += domain.o

Maybe in alphabetical order?

> +/* base-2 logarithm */
> +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))

This is now replicated in three places.  Maybe it should live in, say,
xen/bitops.h?

> +hyp_sync:
> +        entry   hyp=1
> +        msr     daifclr, #2
> +        adr     lr, return_to_hypervisor
> +        mov     x0, sp
> +        b       do_trap_hypervisor

This pattern (call fnX with arg0 == sp and lr == fnY) is repeated
quite a few times.  Could we have another tidying macro for it?

> +ENTRY(return_to_new_vcpu)
> +ENTRY(return_to_guest)
> +ENTRY(return_to_hypervisor)
> +        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
> +
> +        pop     x0, x1
> +        pop     x2, x3
> +        pop     x4, x5
> +        pop     x6, x7
> +        pop     x8, x9
> +
> +        /* XXX handle return to guest tasks, soft irqs etc */
> +        
> +        msr     elr_el2, x21                    // set up the return data
> +        msr     spsr_el2, x22

Done here becasue it's roughly half-way between the load and the
overwrite below?  Should we be using x28/x29 for this to give ourselves
even more pipeline space?

> +        pop     x10, x11
> +        pop     x12, x13
> +        pop     x14, x15
> +        pop     x16, x17
> +        pop     x18, x19
> +        pop     x20, x21
> +        pop     x22, x23
> +        pop     x24, x25
> +        pop     x26, x27
> +        pop     x28, x29
> +
> +        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
> +        eret
> +

> --- a/xen/arch/arm/io.h
> +++ b/xen/arch/arm/io.h
> @@ -26,7 +26,7 @@
>  typedef struct
>  {
>      struct hsr_dabt dabt;
> -    uint32_t gva;
> +    vaddr_t gva;
>      paddr_t gpa;
>  } mmio_info_t;
>  

This seems like it belongs in the earlier vaddr patch.

> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -238,7 +238,7 @@ union hsr {
>  #endif
>  
>  #ifndef __ASSEMBLY__
> -extern uint32_t hyp_traps_vector[8];
> +extern uint32_t hyp_traps_vector;

hyp_traps_vector[], and avoid adding '&' to the users?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:24:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zjX-0005PP-3h; Thu, 14 Feb 2013 14:24:19 +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 1U5zjW-0005P6-LB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:24:18 +0000
Received: from [85.158.137.99:55030] by server-2.bemta-3.messagelabs.com id
	F7/1D-25961-193FC115; Thu, 14 Feb 2013 14:24:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360851856!18261568!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8993 invoked from network); 14 Feb 2013 14:24:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:24:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zjU-000Mcc-6a; Thu, 14 Feb 2013 14:24:16 +0000
Date: Thu, 14 Feb 2013 14:24:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214142416.GW83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 28/45] xen: arm: arm64 trap 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

At 15:56 +0000 on 23 Jan (1358956594), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index 815f305..be41f43 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,5 +1,7 @@
>  subdir-y += lib
>  
> +obj-y += entry.o
>  obj-y += mode_switch.o
>  
> +obj-y += traps.o
>  obj-y += domain.o

Maybe in alphabetical order?

> +/* base-2 logarithm */
> +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))

This is now replicated in three places.  Maybe it should live in, say,
xen/bitops.h?

> +hyp_sync:
> +        entry   hyp=1
> +        msr     daifclr, #2
> +        adr     lr, return_to_hypervisor
> +        mov     x0, sp
> +        b       do_trap_hypervisor

This pattern (call fnX with arg0 == sp and lr == fnY) is repeated
quite a few times.  Could we have another tidying macro for it?

> +ENTRY(return_to_new_vcpu)
> +ENTRY(return_to_guest)
> +ENTRY(return_to_hypervisor)
> +        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
> +
> +        pop     x0, x1
> +        pop     x2, x3
> +        pop     x4, x5
> +        pop     x6, x7
> +        pop     x8, x9
> +
> +        /* XXX handle return to guest tasks, soft irqs etc */
> +        
> +        msr     elr_el2, x21                    // set up the return data
> +        msr     spsr_el2, x22

Done here becasue it's roughly half-way between the load and the
overwrite below?  Should we be using x28/x29 for this to give ourselves
even more pipeline space?

> +        pop     x10, x11
> +        pop     x12, x13
> +        pop     x14, x15
> +        pop     x16, x17
> +        pop     x18, x19
> +        pop     x20, x21
> +        pop     x22, x23
> +        pop     x24, x25
> +        pop     x26, x27
> +        pop     x28, x29
> +
> +        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
> +        eret
> +

> --- a/xen/arch/arm/io.h
> +++ b/xen/arch/arm/io.h
> @@ -26,7 +26,7 @@
>  typedef struct
>  {
>      struct hsr_dabt dabt;
> -    uint32_t gva;
> +    vaddr_t gva;
>      paddr_t gpa;
>  } mmio_info_t;
>  

This seems like it belongs in the earlier vaddr patch.

> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -238,7 +238,7 @@ union hsr {
>  #endif
>  
>  #ifndef __ASSEMBLY__
> -extern uint32_t hyp_traps_vector[8];
> +extern uint32_t hyp_traps_vector;

hyp_traps_vector[], and avoid adding '&' to the users?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:24:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zjV-0005Om-GS; Thu, 14 Feb 2013 14:24:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U5zjT-0005Oa-Ho
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:24:15 +0000
Received: from [193.109.254.147:49014] by server-13.bemta-14.messagelabs.com
	id D8/BE-30639-E83FC115; Thu, 14 Feb 2013 14:24:14 +0000
X-Env-Sender: BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360851852!10326326!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTc5MDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8759 invoked from network); 14 Feb 2013 14:24:13 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 14:24:13 -0000
Received: from shinybook.infradead.org ([2001:8b0:10b:1:e6ce:8fff:fe1f:f2c0])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U5zjE-0005aT-Pq; Thu, 14 Feb 2013 14:24:01 +0000
Message-ID: <1360851838.10581.248.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Thu, 14 Feb 2013 14:23:58 +0000
In-Reply-To: <1360850923.20449.390.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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: multipart/mixed; boundary="===============1148441477731349734=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1148441477731349734==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-ywGaGufIupe5Fq6lpQMw"


--=-ywGaGufIupe5Fq6lpQMw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 14:08 +0000, Ian Campbell wrote:
> The chap who did our OVMF stuff has moved on to pastures new but ISTR
> him saying something about a build bug with GCC!=3D44, which had been
> fixed in upstream OVMF but not yet sync'd into the Xen tree.

Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
although I suspect it might be incomplete and I'm about to blow away my
local build tree and configure from scratch to retest.

But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
line which does
        cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

> Awesome! (I've CCd xen-devel just for their info, it's moderated for
> non-subscribers but valid posters get whitelisted)

In that case I think the only context I need to add, for those who want
to play along at home, is the location of my trees for OVMF and SeaBIOS.
The OVMF one is above, and the SeaBIOS one is next to it:
git:// or http://git.infradead.org/users/dwmw2/seabios.git

There's a README.CSM file in the SeaBIOS tree which describes how to
build OVMF with CSM support. The main reason I'm pointing you at my
trees rather than upstream is the patch within each one that adds the
UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
parts of the UMB memory region should be made read-only. For Qemu with
KVM that's a moot point because it doesn't get made read-only anyway, so
you could just use upstream now. If you don't implement the PAM
protection of those regions, I suspect the same might be true for you.
Suck it and see, perhaps.

> > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > PCIR structure unaligned. That was it.

> ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> include? (rather than tools/firmware/vgabios/)

Yes, the one in /usr/share/qemu-xen. You want the patch from
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

--=20
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




--=-ywGaGufIupe5Fq6lpQMw
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE0MTQyMzU4WjAjBgkqhkiG9w0BCQQx
FgQUl58ZCtPW9uWA7JzWaNHsKbtLGxYwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQAEM1nhyG82QsEw61vWaXWA920e
aZoeGs5xgj4CyxpvaQ2JhkI5Bx7d0xqcv1tLAlklCiMhXlzwaOIXKQI7snZhZuh4Lz6Xqnq+m/RR
0c3STSRW+jXl4EUPr56sw4roPHUDSIcxFBUiXbFMF2Cyxfug8uJyi1mfJrfpIdW7MneNdd/eIzz5
yVZQ4TWW78GpobJxkjfT7SWbVe4zvfzw+1aPT2iWR6IcRKEQxoCPl/B4w0nLf7Mf2H3rW/ZYyAbB
bHRbUdd62mIiE+V3ghEEGaAt31JyH1MEREr3f5g0ChIj7luHOb7vSqWIuxc+J5/eSVljCk5DA5L7
CuuDh+ewO1m5AAAAAAAA


--=-ywGaGufIupe5Fq6lpQMw--



--===============1148441477731349734==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1148441477731349734==--



From xen-devel-bounces@lists.xen.org Thu Feb 14 14:24:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U5zjV-0005Om-GS; Thu, 14 Feb 2013 14:24:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U5zjT-0005Oa-Ho
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:24:15 +0000
Received: from [193.109.254.147:49014] by server-13.bemta-14.messagelabs.com
	id D8/BE-30639-E83FC115; Thu, 14 Feb 2013 14:24:14 +0000
X-Env-Sender: BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360851852!10326326!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTc5MDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8759 invoked from network); 14 Feb 2013 14:24:13 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 14:24:13 -0000
Received: from shinybook.infradead.org ([2001:8b0:10b:1:e6ce:8fff:fe1f:f2c0])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U5zjE-0005aT-Pq; Thu, 14 Feb 2013 14:24:01 +0000
Message-ID: <1360851838.10581.248.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Thu, 14 Feb 2013 14:23:58 +0000
In-Reply-To: <1360850923.20449.390.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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: multipart/mixed; boundary="===============1148441477731349734=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1148441477731349734==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-ywGaGufIupe5Fq6lpQMw"


--=-ywGaGufIupe5Fq6lpQMw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 14:08 +0000, Ian Campbell wrote:
> The chap who did our OVMF stuff has moved on to pastures new but ISTR
> him saying something about a build bug with GCC!=3D44, which had been
> fixed in upstream OVMF but not yet sync'd into the Xen tree.

Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
although I suspect it might be incomplete and I'm about to blow away my
local build tree and configure from scratch to retest.

But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
line which does
        cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

> Awesome! (I've CCd xen-devel just for their info, it's moderated for
> non-subscribers but valid posters get whitelisted)

In that case I think the only context I need to add, for those who want
to play along at home, is the location of my trees for OVMF and SeaBIOS.
The OVMF one is above, and the SeaBIOS one is next to it:
git:// or http://git.infradead.org/users/dwmw2/seabios.git

There's a README.CSM file in the SeaBIOS tree which describes how to
build OVMF with CSM support. The main reason I'm pointing you at my
trees rather than upstream is the patch within each one that adds the
UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
parts of the UMB memory region should be made read-only. For Qemu with
KVM that's a moot point because it doesn't get made read-only anyway, so
you could just use upstream now. If you don't implement the PAM
protection of those regions, I suspect the same might be true for you.
Suck it and see, perhaps.

> > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > PCIR structure unaligned. That was it.

> ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> include? (rather than tools/firmware/vgabios/)

Yes, the one in /usr/share/qemu-xen. You want the patch from
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

--=20
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




--=-ywGaGufIupe5Fq6lpQMw
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE0MTQyMzU4WjAjBgkqhkiG9w0BCQQx
FgQUl58ZCtPW9uWA7JzWaNHsKbtLGxYwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQAEM1nhyG82QsEw61vWaXWA920e
aZoeGs5xgj4CyxpvaQ2JhkI5Bx7d0xqcv1tLAlklCiMhXlzwaOIXKQI7snZhZuh4Lz6Xqnq+m/RR
0c3STSRW+jXl4EUPr56sw4roPHUDSIcxFBUiXbFMF2Cyxfug8uJyi1mfJrfpIdW7MneNdd/eIzz5
yVZQ4TWW78GpobJxkjfT7SWbVe4zvfzw+1aPT2iWR6IcRKEQxoCPl/B4w0nLf7Mf2H3rW/ZYyAbB
bHRbUdd62mIiE+V3ghEEGaAt31JyH1MEREr3f5g0ChIj7luHOb7vSqWIuxc+J5/eSVljCk5DA5L7
CuuDh+ewO1m5AAAAAAAA


--=-ywGaGufIupe5Fq6lpQMw--



--===============1148441477731349734==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1148441477731349734==--



From xen-devel-bounces@lists.xen.org Thu Feb 14 14:30:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:30: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 1U5zpc-0005u5-Uq; Thu, 14 Feb 2013 14:30:36 +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 1U5zpb-0005u0-Ms
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:30:35 +0000
Received: from [85.158.139.211:12512] by server-11.bemta-5.messagelabs.com id
	2C/9F-19159-A05FC115; Thu, 14 Feb 2013 14:30:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360852215!21416493!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21531 invoked from network); 14 Feb 2013 14:30:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:30:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zpF-000Mdp-ST; Thu, 14 Feb 2013 14:30:13 +0000
Date: Thu, 14 Feb 2013 14:30:13 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214143013.GX83752@ocelot.phlegethon.org>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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:16 +0000 on 14 Feb (1360851371), Ian Campbell wrote:
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -17,11 +17,15 @@ header = {};
>  footer = {};
>  
>  #arm
> -inttypes["arm"] = {
> +inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
>  };
> +header["x86_32"] = """

["arm32"] ?

Tim.

> +#define __arm__ARM32 1
> +""";
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:30:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:30: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 1U5zpc-0005u5-Uq; Thu, 14 Feb 2013 14:30:36 +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 1U5zpb-0005u0-Ms
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:30:35 +0000
Received: from [85.158.139.211:12512] by server-11.bemta-5.messagelabs.com id
	2C/9F-19159-A05FC115; Thu, 14 Feb 2013 14:30:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-206.messagelabs.com!1360852215!21416493!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21531 invoked from network); 14 Feb 2013 14:30:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:30:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zpF-000Mdp-ST; Thu, 14 Feb 2013 14:30:13 +0000
Date: Thu, 14 Feb 2013 14:30:13 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214143013.GX83752@ocelot.phlegethon.org>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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:16 +0000 on 14 Feb (1360851371), Ian Campbell wrote:
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -17,11 +17,15 @@ header = {};
>  footer = {};
>  
>  #arm
> -inttypes["arm"] = {
> +inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
>  };
> +header["x86_32"] = """

["arm32"] ?

Tim.

> +#define __arm__ARM32 1
> +""";
> +

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:33:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:33: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 1U5zru-00064u-GC; Thu, 14 Feb 2013 14:32:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5zrs-00064n-OR
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:32:56 +0000
Received: from [193.109.254.147:7315] by server-14.bemta-14.messagelabs.com id
	6D/57-02031-895FC115; Thu, 14 Feb 2013 14:32:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360852375!8702237!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2186 invoked from network); 14 Feb 2013 14:32:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:32:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464257"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:32:56 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 14 Feb 2013
	14:32:55 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>
Date: Thu, 14 Feb 2013 14:32:54 +0000
Thread-Topic: [PATCH] trivial: Do not ignore dsdl.asl file
Thread-Index: Ac4KwC0q1ADjRyvdQp+D/y/9SCv9+A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458385@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] trivial: Do not ignore dsdl.asl 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

dsdl.asl file is not autogenerated while all other dsdl_*.asl files are.
.hgignore is correct.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 125a582..e29e360 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,7 +173,7 @@ tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
 tools/firmware/hvmloader/acpi/mk_dsdt
 tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt*.asl
+tools/firmware/hvmloader/acpi/dsdt_*.asl
 tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
-- 
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 Thu Feb 14 14:33:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:33: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 1U5zru-00064u-GC; Thu, 14 Feb 2013 14:32:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U5zrs-00064n-OR
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:32:56 +0000
Received: from [193.109.254.147:7315] by server-14.bemta-14.messagelabs.com id
	6D/57-02031-895FC115; Thu, 14 Feb 2013 14:32:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360852375!8702237!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2186 invoked from network); 14 Feb 2013 14:32:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:32:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464257"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:32:56 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 14 Feb 2013
	14:32:55 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>
Date: Thu, 14 Feb 2013 14:32:54 +0000
Thread-Topic: [PATCH] trivial: Do not ignore dsdl.asl file
Thread-Index: Ac4KwC0q1ADjRyvdQp+D/y/9SCv9+A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458385@LONPMAILBOX01.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
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] trivial: Do not ignore dsdl.asl 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

dsdl.asl file is not autogenerated while all other dsdl_*.asl files are.
.hgignore is correct.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 125a582..e29e360 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,7 +173,7 @@ tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
 tools/firmware/hvmloader/acpi/mk_dsdt
 tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt*.asl
+tools/firmware/hvmloader/acpi/dsdt_*.asl
 tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
-- 
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 Thu Feb 14 14:36:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:36: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 1U5zv4-0006FB-3j; Thu, 14 Feb 2013 14:36:14 +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 1U5zv2-0006F6-Sp
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:36:12 +0000
Received: from [193.109.254.147:62503] by server-8.bemta-14.messagelabs.com id
	DB/EB-17325-C56FC115; Thu, 14 Feb 2013 14:36:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360852563!2827898!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24015 invoked from network); 14 Feb 2013 14:36:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:36:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zus-000Mes-Jp; Thu, 14 Feb 2013 14:36:02 +0000
Date: Thu, 14 Feb 2013 14:36:02 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214143602.GY83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-29-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-29-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 29/45] xen: arm: pcpu context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956595), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 14:36:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:36: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 1U5zv4-0006FB-3j; Thu, 14 Feb 2013 14:36:14 +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 1U5zv2-0006F6-Sp
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:36:12 +0000
Received: from [193.109.254.147:62503] by server-8.bemta-14.messagelabs.com id
	DB/EB-17325-C56FC115; Thu, 14 Feb 2013 14:36:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360852563!2827898!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24015 invoked from network); 14 Feb 2013 14:36:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:36:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zus-000Mes-Jp; Thu, 14 Feb 2013 14:36:02 +0000
Date: Thu, 14 Feb 2013 14:36:02 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214143602.GY83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-29-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-29-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 29/45] xen: arm: pcpu context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956595), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 14:36:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:36: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 1U5zvQ-0006HQ-Gw; Thu, 14 Feb 2013 14:36:36 +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 1U5zvP-0006HC-Sy
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:36:36 +0000
Received: from [85.158.139.83:42930] by server-5.bemta-5.messagelabs.com id
	6C/83-11945-376FC115; Thu, 14 Feb 2013 14:36:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360852588!27112719!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12356 invoked from network); 14 Feb 2013 14:36:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:36:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zvI-000Mf9-J1; Thu, 14 Feb 2013 14:36:28 +0000
Date: Thu, 14 Feb 2013 14:36:28 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214143628.GZ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-30-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-30-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 30/45] xen: arm64: percpu variable 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 15:56 +0000 on 23 Jan (1358956596), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 14:36:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:36: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 1U5zvQ-0006HQ-Gw; Thu, 14 Feb 2013 14:36:36 +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 1U5zvP-0006HC-Sy
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:36:36 +0000
Received: from [85.158.139.83:42930] by server-5.bemta-5.messagelabs.com id
	6C/83-11945-376FC115; Thu, 14 Feb 2013 14:36:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360852588!27112719!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12356 invoked from network); 14 Feb 2013 14:36:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:36:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U5zvI-000Mf9-J1; Thu, 14 Feb 2013 14:36:28 +0000
Date: Thu, 14 Feb 2013 14:36:28 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214143628.GZ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-30-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-30-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 30/45] xen: arm64: percpu variable 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 15:56 +0000 on 23 Jan (1358956596), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 14:39:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:39: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 1U5zyX-0006Vx-55; Thu, 14 Feb 2013 14:39: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 1U5zyV-0006Vh-WB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:39:48 +0000
Received: from [85.158.138.51:14266] by server-1.bemta-3.messagelabs.com id
	6A/3E-08955-337FC115; Thu, 14 Feb 2013 14:39:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360852786!19490985!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10066 invoked from network); 14 Feb 2013 14:39:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:39: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.297.1;
	Thu, 14 Feb 2013 14:39:46 +0000
Message-ID: <1360852785.20449.408.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:39:45 +0000
In-Reply-To: <20130214142416.GW83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
	<20130214142416.GW83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 28/45] xen: arm: arm64 trap 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 Thu, 2013-02-14 at 14:24 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956594), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> 
> > diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> > index 815f305..be41f43 100644
> > --- a/xen/arch/arm/arm64/Makefile
> > +++ b/xen/arch/arm/arm64/Makefile
> > @@ -1,5 +1,7 @@
> >  subdir-y += lib
> >  
> > +obj-y += entry.o
> >  obj-y += mode_switch.o
> >  
> > +obj-y += traps.o
> >  obj-y += domain.o
> 
> Maybe in alphabetical order?

I suppose so ;-)
> 
> > +/* base-2 logarithm */
> > +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> > +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> > +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> > +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> > +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
> 
> This is now replicated in three places.  Maybe it should live in, say,
> xen/bitops.h?

ACK.

> 
> > +hyp_sync:
> > +        entry   hyp=1
> > +        msr     daifclr, #2
> > +        adr     lr, return_to_hypervisor
> > +        mov     x0, sp
> > +        b       do_trap_hypervisor
> 
> This pattern (call fnX with arg0 == sp and lr == fnY) is repeated
> quite a few times.  Could we have another tidying macro for it?

I'm half considering doing away with the preload lr+b and just using bl
instead and putting the tail stuff in a macro like the entry stuff.

But if we do stick with this way then sure.

> 
> > +ENTRY(return_to_new_vcpu)
> > +ENTRY(return_to_guest)
> > +ENTRY(return_to_hypervisor)
> > +        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
> > +
> > +        pop     x0, x1
> > +        pop     x2, x3
> > +        pop     x4, x5
> > +        pop     x6, x7
> > +        pop     x8, x9
> > +
> > +        /* XXX handle return to guest tasks, soft irqs etc */
> > +        
> > +        msr     elr_el2, x21                    // set up the return data
> > +        msr     spsr_el2, x22
> 
> Done here becasue it's roughly half-way between the load and the
> overwrite below?  Should we be using x28/x29 for this to give ourselves
> even more pipeline space?

I can't for the life of me recall why I did this here instead of
somewhere else... Lets pretend I was thinking about pipelines, sure -;)

> 
> > +        pop     x10, x11
> > +        pop     x12, x13
> > +        pop     x14, x15
> > +        pop     x16, x17
> > +        pop     x18, x19
> > +        pop     x20, x21
> > +        pop     x22, x23
> > +        pop     x24, x25
> > +        pop     x26, x27
> > +        pop     x28, x29
> > +
> > +        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
> > +        eret
> > +
> 
> > --- a/xen/arch/arm/io.h
> > +++ b/xen/arch/arm/io.h
> > @@ -26,7 +26,7 @@
> >  typedef struct
> >  {
> >      struct hsr_dabt dabt;
> > -    uint32_t gva;
> > +    vaddr_t gva;
> >      paddr_t gpa;
> >  } mmio_info_t;
> >  
> 
> This seems like it belongs in the earlier vaddr patch.

ACK.

> 
> > --- a/xen/include/asm-arm/processor.h
> > +++ b/xen/include/asm-arm/processor.h
> > @@ -238,7 +238,7 @@ union hsr {
> >  #endif
> >  
> >  #ifndef __ASSEMBLY__
> > -extern uint32_t hyp_traps_vector[8];
> > +extern uint32_t hyp_traps_vector;
> 
> hyp_traps_vector[], and avoid adding '&' to the users?

Could do, there's actually 8 words at each entry point, so the type is a
bit of a complete fiction anyway

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:39:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:39: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 1U5zyX-0006Vx-55; Thu, 14 Feb 2013 14:39: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 1U5zyV-0006Vh-WB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:39:48 +0000
Received: from [85.158.138.51:14266] by server-1.bemta-3.messagelabs.com id
	6A/3E-08955-337FC115; Thu, 14 Feb 2013 14:39:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360852786!19490985!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10066 invoked from network); 14 Feb 2013 14:39:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:39: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.297.1;
	Thu, 14 Feb 2013 14:39:46 +0000
Message-ID: <1360852785.20449.408.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:39:45 +0000
In-Reply-To: <20130214142416.GW83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
	<20130214142416.GW83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 28/45] xen: arm: arm64 trap 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 Thu, 2013-02-14 at 14:24 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956594), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> 
> > diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> > index 815f305..be41f43 100644
> > --- a/xen/arch/arm/arm64/Makefile
> > +++ b/xen/arch/arm/arm64/Makefile
> > @@ -1,5 +1,7 @@
> >  subdir-y += lib
> >  
> > +obj-y += entry.o
> >  obj-y += mode_switch.o
> >  
> > +obj-y += traps.o
> >  obj-y += domain.o
> 
> Maybe in alphabetical order?

I suppose so ;-)
> 
> > +/* base-2 logarithm */
> > +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> > +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> > +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> > +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> > +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
> 
> This is now replicated in three places.  Maybe it should live in, say,
> xen/bitops.h?

ACK.

> 
> > +hyp_sync:
> > +        entry   hyp=1
> > +        msr     daifclr, #2
> > +        adr     lr, return_to_hypervisor
> > +        mov     x0, sp
> > +        b       do_trap_hypervisor
> 
> This pattern (call fnX with arg0 == sp and lr == fnY) is repeated
> quite a few times.  Could we have another tidying macro for it?

I'm half considering doing away with the preload lr+b and just using bl
instead and putting the tail stuff in a macro like the entry stuff.

But if we do stick with this way then sure.

> 
> > +ENTRY(return_to_new_vcpu)
> > +ENTRY(return_to_guest)
> > +ENTRY(return_to_hypervisor)
> > +        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
> > +
> > +        pop     x0, x1
> > +        pop     x2, x3
> > +        pop     x4, x5
> > +        pop     x6, x7
> > +        pop     x8, x9
> > +
> > +        /* XXX handle return to guest tasks, soft irqs etc */
> > +        
> > +        msr     elr_el2, x21                    // set up the return data
> > +        msr     spsr_el2, x22
> 
> Done here becasue it's roughly half-way between the load and the
> overwrite below?  Should we be using x28/x29 for this to give ourselves
> even more pipeline space?

I can't for the life of me recall why I did this here instead of
somewhere else... Lets pretend I was thinking about pipelines, sure -;)

> 
> > +        pop     x10, x11
> > +        pop     x12, x13
> > +        pop     x14, x15
> > +        pop     x16, x17
> > +        pop     x18, x19
> > +        pop     x20, x21
> > +        pop     x22, x23
> > +        pop     x24, x25
> > +        pop     x26, x27
> > +        pop     x28, x29
> > +
> > +        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
> > +        eret
> > +
> 
> > --- a/xen/arch/arm/io.h
> > +++ b/xen/arch/arm/io.h
> > @@ -26,7 +26,7 @@
> >  typedef struct
> >  {
> >      struct hsr_dabt dabt;
> > -    uint32_t gva;
> > +    vaddr_t gva;
> >      paddr_t gpa;
> >  } mmio_info_t;
> >  
> 
> This seems like it belongs in the earlier vaddr patch.

ACK.

> 
> > --- a/xen/include/asm-arm/processor.h
> > +++ b/xen/include/asm-arm/processor.h
> > @@ -238,7 +238,7 @@ union hsr {
> >  #endif
> >  
> >  #ifndef __ASSEMBLY__
> > -extern uint32_t hyp_traps_vector[8];
> > +extern uint32_t hyp_traps_vector;
> 
> hyp_traps_vector[], and avoid adding '&' to the users?

Could do, there's actually 8 words at each entry point, so the type is a
bit of a complete fiction anyway

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:40:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zzN-0006aY-Jl; Thu, 14 Feb 2013 14:40:41 +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 1U5zzL-0006aN-Pk
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:40:40 +0000
Received: from [85.158.138.51:26704] by server-8.bemta-3.messagelabs.com id
	30/6E-25687-267FC115; Thu, 14 Feb 2013 14:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360852834!19640538!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31978 invoked from network); 14 Feb 2013 14:40:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:40:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:40: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.297.1;
	Thu, 14 Feb 2013 14:40:33 +0000
Message-ID: <1360852832.20449.409.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 14 Feb 2013 14:40:32 +0000
In-Reply-To: <1360849103.20449.371.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 25/45] xen: arm: separate guest user regs
 from internal guest 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 Thu, 2013-02-14 at 13:38 +0000, Ian Campbell wrote:
> 
> > On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
> > allow that on arm64 as well, so I'm not sureethe __pad prefix is
> useful.
> 
> Yes, we absolutely should support this, I'd forgotten about it when I
> wrote this...

8<-------

>From ab5d3b2e1af41580b047b9d85610bd2e4c4b5d0b Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 15 Jan 2013 15:51:47 +0000
Subject: [PATCH] xen: arm: separate guest user regs from internal guest state.

struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).

This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.

So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.

In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.

This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Allow 32-bit to see 64-bit register names too, this is needed so that
    32-bit toolstacks can access/control 64-bit guests.
---
 .gitignore                               |    3 +-
 tools/include/xen-foreign/Makefile       |    7 ++-
 tools/include/xen-foreign/mkheader.py    |   31 ++++++++-
 tools/include/xen-foreign/reference.size |   21 +++---
 tools/include/xen-foreign/structs.py     |    1 +
 tools/libxc/xc_dom_arm.c                 |   10 ++--
 xen/arch/arm/arm32/Makefile              |    2 +
 xen/arch/arm/arm32/domain.c              |   51 +++++++++++++
 xen/arch/arm/arm64/Makefile              |    2 +
 xen/arch/arm/arm64/domain.c              |   66 +++++++++++++++++
 xen/arch/arm/domain.c                    |    4 +-
 xen/arch/arm/domctl.c                    |    4 +-
 xen/include/asm-arm/arm32/processor.h    |   52 +++++++++++++
 xen/include/asm-arm/arm64/processor.h    |   81 +++++++++++++++++++++
 xen/include/asm-arm/current.h            |    1 +
 xen/include/asm-arm/processor.h          |    5 ++
 xen/include/public/arch-arm.h            |  115 ++++++++++++++++++------------
 17 files changed, 388 insertions(+), 68 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain.c
 create mode 100644 xen/arch/arm/arm64/domain.c

diff --git a/.gitignore b/.gitignore
index 125a582..2242344 100644
--- a/.gitignore
+++ b/.gitignore
@@ -363,7 +363,8 @@ tools/include/xen-foreign/checker.c
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
-tools/include/xen-foreign/arm.h
+tools/include/xen-foreign/arm32.h
+tools/include/xen-foreign/arm64.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..8e0be83 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 arm64 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,10 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
+arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..4ee9fb5 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,37 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["arm32"] = """
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t __pad_ ## n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
+""";
+footer["arm32"] = """
+#undef __DECL_REG
+"""
+
+inttypes["arm64"] = {
+    "unsigned long" : "uint64_t",
+    "long"          : "uint64_t",
+    "xen_pfn_t"     : "uint64_t",
+};
+header["arm64"] = """
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
+""";
+footer["arm64"] = """
+#undef __DECL_REG
+"""
 
 # x86_32
 inttypes["x86_32"] = {
@@ -53,6 +79,9 @@ header["x86_64"] = """
 #endif
 #define __x86_64___X86_64 1
 """;
+footer["x86_64"] = """
+#undef __DECL_REG
+"""
 
 ###########################################################################
 # main
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..de36455 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,14 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32   arm64  x86_32  x86_64
 
-start_info                |       -    1112    1168
-trap_info                 |       -       8      16
-cpu_user_regs             |     160      68     200
-vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+start_info                |       -       -    1112    1168
+trap_info                 |       -       -       8      16
+cpu_user_regs             |       -       -      68     200
+vcpu_guest_core_regs      |     304     304       -       -
+vcpu_guest_context        |     336     336    2800    5168
+arch_vcpu_info            |       -       -      24      16
+vcpu_time_info            |       -       -      32      32
+vcpu_info                 |       -       -      64      64
+arch_shared_info          |       -       -     268     280
+shared_info               |       -       -    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 51a77c0..e3e8771 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -6,6 +6,7 @@ unions  = [ "vcpu_cr_regs",
 structs = [ "start_info",
             "trap_info",
             "cpu_user_regs",
+            "vcpu_guest_core_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 0cec774..e46cec9 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -107,17 +107,17 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     /* clear everything */
     memset(ctxt, 0, sizeof(*ctxt));
 
-    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.pc32 = dom->parms.virt_entry;
 
     /* Linux boot protocol. See linux.Documentation/arm/Booting. */
-    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r0_usr = 0; /* SBZ */
     /* Machine ID: We use DTB therefore no machine id */
-    ctxt->user_regs.r1 = 0xffffffff;
+    ctxt->user_regs.r1_usr = 0xffffffff;
     /* ATAGS/DTB: We currently require that the guest kernel to be
      * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look
      * like a valid pointer to a set of ATAGS or a DTB.
      */
-    ctxt->user_regs.r2 = 0xffffffff;
+    ctxt->user_regs.r2_usr = 0xffffffff;
 
     ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
 
@@ -130,7 +130,7 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     ctxt->flags = VGCF_online;
 
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
-           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
     return 0;
 }
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 20931fa..29898ae 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -3,3 +3,5 @@ subdir-y += lib
 obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm32/domain.c b/xen/arch/arm/arm32/domain.c
new file mode 100644
index 0000000..f75a2c6
--- /dev/null
+++ b/xen/arch/arm/arm32/domain.c
@@ -0,0 +1,51 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(r0,r0_usr);   C(r1,r1_usr);   C(r2,r2_usr);   C(r3,r3_usr);   \
+    C(r4,r4_usr);   C(r5,r5_usr);   C(r6,r6_usr);   C(r7,r7_usr);   \
+    C(r8,r8_usr);   C(r9,r9_usr);   C(r10,r10_usr); C(r11,r11_usr); \
+    C(r12,r12_usr); \
+    C(sp_usr,sp_usr); \
+    C(lr,lr_usr); \
+    C(spsr_irq,spsr_irq); C(lr_irq,lr_irq); C(sp_irq,sp_irq); \
+    C(spsr_svc,spsr_svc); C(lr_svc,lr_svc); C(sp_svc,sp_svc); \
+    C(spsr_abt,spsr_abt); C(lr_abt,lr_abt); C(sp_abt,sp_abt); \
+    C(spsr_und,spsr_und); C(lr_und,lr_und); C(sp_und,sp_und); \
+    C(spsr_fiq,spsr_fiq); C(sp_fiq,sp_fiq); C(sp_fiq,sp_fiq); \
+    C(r8_fiq,r8_fiq); C(r9_fiq,r9_fiq); \
+    C(r10_fiq,r10_fiq); C(r11_fiq,r11_fiq); C(r12_fiq,r12_fiq); \
+    C(pc,pc32); \
+    C(cpsr,cpsr)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c447eaa..815f305 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,3 +1,5 @@
 subdir-y += lib
 
 obj-y += mode_switch.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm64/domain.c b/xen/arch/arm/arm64/domain.c
new file mode 100644
index 0000000..05df29e
--- /dev/null
+++ b/xen/arch/arm/arm64/domain.c
@@ -0,0 +1,66 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(x0,x0);   C(x1,x1);   C(x2,x2);   C(x3,x3);   \
+    C(x4,x4);   C(x5,x5);   C(x6,x6);   C(x7,x7);   \
+    C(x8,x8);   C(x9,x9);   C(x10,x10); C(x11,x11); \
+    C(x12,x12); C(x13,x13); C(x14,x14); C(x15,x15); \
+    C(x16,x16); C(x17,x17); C(x18,x18); C(x19,x19); \
+    C(x20,x20); C(x21,x21); C(x22,x22); C(x23,x23); \
+    C(x24,x24); C(x25,x25); C(x26,x26); C(x27,x27); \
+    C(x28,x28); C(fp,x29);  C(lr,x30);  C(pc,pc64); \
+    C(cpsr, cpsr); C(spsr_el1, spsr_el1)
+
+#define ALLREGS32 C(spsr_fiq, spsr_fiq); C(spsr_irq,spsr_irq); \
+                  C(spsr_und,spsr_und); C(spsr_abt,spsr_abt)
+
+#define ALLREGS64 C(sp_el0,sp_el0); C(sp_el1,sp_el1); C(elr_el1,elr_el1)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e7d3ec6..3651fb2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,7 +486,7 @@ int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
     if ( !is_guest_psr(regs->cpsr) )
         return -EINVAL;
@@ -502,7 +502,7 @@ int arch_set_info_guest(
     if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
         return -EINVAL;
 
-    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+    vcpu_regs_user_to_hyp(v, regs);
 
     v->arch.sctlr = ctxt->sctlr;
     v->arch.ttbr0 = ctxt->ttbr0;
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index c7ffd8a..15f8537 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -20,9 +20,9 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
-    *regs = v->arch.cpu_info->guest_cpu_user_regs;
+    vcpu_regs_hyp_to_user(v, regs);
 
     ctxt->sctlr = v->arch.sctlr;
     ctxt->ttbr0 = v->arch.ttbr0;
diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
index 843fbd2..a782d96 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,58 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#ifndef __ASSEMBLY__
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+        uint32_t r11;
+        uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+        uint32_t lr_usr;
+    };
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_irq, lr_irq;
+    uint32_t sp_svc, lr_svc;
+    uint32_t sp_abt, lr_abt;
+    uint32_t sp_und, lr_und;
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+    uint32_t sp_fiq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
+};
+#endif
+
 /* Layout as used in assembly, with src/dest registers mixed in */
 #define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
 #define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
index fdb0dab..b4602fa 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,87 @@
 
 #ifndef __ASSEMBLY__
 
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+
+#define __DECL_REG(n64, n32) union {            \
+    uint64_t n64;                               \
+    uint32_t n32;                               \
+}
+
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0/*_usr*/);
+    __DECL_REG(x1,           r1/*_usr*/);
+    __DECL_REG(x2,           r2/*_usr*/);
+    __DECL_REG(x3,           r3/*_usr*/);
+    __DECL_REG(x4,           r4/*_usr*/);
+    __DECL_REG(x5,           r5/*_usr*/);
+    __DECL_REG(x6,           r6/*_usr*/);
+    __DECL_REG(x7,           r7/*_usr*/);
+    __DECL_REG(x8,           r8/*_usr*/);
+    __DECL_REG(x9,           r9/*_usr*/);
+    __DECL_REG(x10,          r10/*_usr*/);
+    __DECL_REG(x11 ,         r11/*_usr*/);
+    __DECL_REG(x12,          r12/*_usr*/);
+
+    __DECL_REG(x13,          /* r13_usr */ sp_usr);
+    __DECL_REG(x14,          /* r14_usr */ lr_usr);
+
+    __DECL_REG(x15,          /* r13_hyp */ __unused_sp_hyp);
+
+    __DECL_REG(x16,          /* r14_irq */ lr_irq);
+    __DECL_REG(x17,          /* r13_irq */ sp_irq);
+
+    __DECL_REG(x18,          /* r14_svc */ lr_svc);
+    __DECL_REG(x19,          /* r13_svc */ sp_svc);
+
+    __DECL_REG(x20,          /* r14_abt */ lr_abt);
+    __DECL_REG(x21,          /* r13_abt */ sp_abt);
+
+    __DECL_REG(x22,          /* r14_und */ lr_und);
+    __DECL_REG(x23,          /* r13_und */ sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+    __DECL_REG(/* x29 */ fp, /* r13_fiq */ sp_fiq);
+    __DECL_REG(/* x30 */ lr, /* r14_fiq */ lr_fiq);
+
+    register_t sp; /* Valid for hypervisor frames */
+
+    /* Return address and mode */
+    __DECL_REG(pc,           pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
+
+    uint64_t pad0;
+
+    /* Outer guest frame only from here on... */
+
+    union {
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
+    };
+
+    uint32_t pad1; /* Align */
+
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
+
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
+
+    uint64_t pad2; /* Doubleword-align the user half of the frame */
+};
+
+#undef __DECL_REG
+
+/* Access to system registers */
+
 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
     asm volatile("mrs  %0, "#name : "=r" (_r));         \
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index d20d7a8..c9c8ac7 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -6,6 +6,7 @@
 #include <public/xen.h>
 
 #include <asm/percpu.h>
+#include <asm/processor.h>
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 8183d36..230c901 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,11 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs);
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_H */
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1397e40..6b4e24f 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -86,55 +86,80 @@
 #endif
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-struct cpu_user_regs
-{
-    uint32_t r0;
-    uint32_t r1;
-    uint32_t r2;
-    uint32_t r3;
-    uint32_t r4;
-    uint32_t r5;
-    uint32_t r6;
-    uint32_t r7;
-    uint32_t r8;
-    uint32_t r9;
-    uint32_t r10;
-    union {
-        uint32_t r11;
-        uint32_t fp;
-    };
-    uint32_t r12;
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+# define __DECL_REG(n64, n32) union {          \
+        uint64_t n64;                          \
+        uint32_t n32;                          \
+    }
+#else
+/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
+#define __DECL_REG(n64, n32) uint64_t n64
+#endif
 
-    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+struct vcpu_guest_core_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0_usr);
+    __DECL_REG(x1,           r1_usr);
+    __DECL_REG(x2,           r2_usr);
+    __DECL_REG(x3,           r3_usr);
+    __DECL_REG(x4,           r4_usr);
+    __DECL_REG(x5,           r5_usr);
+    __DECL_REG(x6,           r6_usr);
+    __DECL_REG(x7,           r7_usr);
+    __DECL_REG(x8,           r8_usr);
+    __DECL_REG(x9,           r9_usr);
+    __DECL_REG(x10,          r10_usr);
+    __DECL_REG(x11,          r11_usr);
+    __DECL_REG(x12,          r12_usr);
+
+    __DECL_REG(x13,          sp_usr);
+    __DECL_REG(x14,          lr_usr);
+
+    __DECL_REG(x15,          __unused_sp_hyp);
+
+    __DECL_REG(x16,          lr_irq);
+    __DECL_REG(x17,          sp_irq);
+
+    __DECL_REG(x18,          lr_svc);
+    __DECL_REG(x19,          sp_svc);
+
+    __DECL_REG(x20,          lr_abt);
+    __DECL_REG(x21,          sp_abt);
+
+    __DECL_REG(x22,          lr_und);
+    __DECL_REG(x23,          sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+
+    __DECL_REG(x29,          sp_fiq);
+    __DECL_REG(x30,          lr_fiq);
+
+    /* Return address and mode */
+    __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
 
-    /* r14 - LR: is the same physical register as LR_usr */
     union {
-        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
-        uint32_t lr_usr;
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
     };
 
-    uint32_t pc; /* Return IP */
-    uint32_t cpsr; /* Return mode */
-    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
-
-    /* Outer guest frame only from here on... */
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
 
-    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
-
-    uint32_t sp_irq, lr_irq;
-    uint32_t sp_svc, lr_svc;
-    uint32_t sp_abt, lr_abt;
-    uint32_t sp_und, lr_und;
-
-    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
-    uint32_t sp_fiq, lr_fiq;
-
-    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
-
-    uint32_t pad1; /* Doubleword-align the user half of the frame */
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
 };
-typedef struct cpu_user_regs cpu_user_regs_t;
-DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+typedef struct vcpu_guest_core_regs vcpu_guest_core_regs_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
+
+#undef __DECL_REG
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
@@ -151,10 +176,10 @@ struct vcpu_guest_context {
 #define VGCF_online                    (1<<_VGCF_online)
     uint32_t flags;                         /* VGCF_* */
 
-    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    struct vcpu_guest_core_regs user_regs;  /* Core CPU registers */
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
1.7.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 Feb 14 14:40:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U5zzN-0006aY-Jl; Thu, 14 Feb 2013 14:40:41 +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 1U5zzL-0006aN-Pk
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:40:40 +0000
Received: from [85.158.138.51:26704] by server-8.bemta-3.messagelabs.com id
	30/6E-25687-267FC115; Thu, 14 Feb 2013 14:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360852834!19640538!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31978 invoked from network); 14 Feb 2013 14:40:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:40:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:40: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.297.1;
	Thu, 14 Feb 2013 14:40:33 +0000
Message-ID: <1360852832.20449.409.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 14 Feb 2013 14:40:32 +0000
In-Reply-To: <1360849103.20449.371.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 25/45] xen: arm: separate guest user regs
 from internal guest 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 Thu, 2013-02-14 at 13:38 +0000, Ian Campbell wrote:
> 
> > On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
> > allow that on arm64 as well, so I'm not sureethe __pad prefix is
> useful.
> 
> Yes, we absolutely should support this, I'd forgotten about it when I
> wrote this...

8<-------

>From ab5d3b2e1af41580b047b9d85610bd2e4c4b5d0b Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 15 Jan 2013 15:51:47 +0000
Subject: [PATCH] xen: arm: separate guest user regs from internal guest state.

struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).

This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.

So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.

In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.

This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Allow 32-bit to see 64-bit register names too, this is needed so that
    32-bit toolstacks can access/control 64-bit guests.
---
 .gitignore                               |    3 +-
 tools/include/xen-foreign/Makefile       |    7 ++-
 tools/include/xen-foreign/mkheader.py    |   31 ++++++++-
 tools/include/xen-foreign/reference.size |   21 +++---
 tools/include/xen-foreign/structs.py     |    1 +
 tools/libxc/xc_dom_arm.c                 |   10 ++--
 xen/arch/arm/arm32/Makefile              |    2 +
 xen/arch/arm/arm32/domain.c              |   51 +++++++++++++
 xen/arch/arm/arm64/Makefile              |    2 +
 xen/arch/arm/arm64/domain.c              |   66 +++++++++++++++++
 xen/arch/arm/domain.c                    |    4 +-
 xen/arch/arm/domctl.c                    |    4 +-
 xen/include/asm-arm/arm32/processor.h    |   52 +++++++++++++
 xen/include/asm-arm/arm64/processor.h    |   81 +++++++++++++++++++++
 xen/include/asm-arm/current.h            |    1 +
 xen/include/asm-arm/processor.h          |    5 ++
 xen/include/public/arch-arm.h            |  115 ++++++++++++++++++------------
 17 files changed, 388 insertions(+), 68 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain.c
 create mode 100644 xen/arch/arm/arm64/domain.c

diff --git a/.gitignore b/.gitignore
index 125a582..2242344 100644
--- a/.gitignore
+++ b/.gitignore
@@ -363,7 +363,8 @@ tools/include/xen-foreign/checker.c
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
-tools/include/xen-foreign/arm.h
+tools/include/xen-foreign/arm32.h
+tools/include/xen-foreign/arm64.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..8e0be83 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 arm64 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,10 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
+arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..4ee9fb5 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,37 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["arm32"] = """
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t __pad_ ## n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
+""";
+footer["arm32"] = """
+#undef __DECL_REG
+"""
+
+inttypes["arm64"] = {
+    "unsigned long" : "uint64_t",
+    "long"          : "uint64_t",
+    "xen_pfn_t"     : "uint64_t",
+};
+header["arm64"] = """
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
+""";
+footer["arm64"] = """
+#undef __DECL_REG
+"""
 
 # x86_32
 inttypes["x86_32"] = {
@@ -53,6 +79,9 @@ header["x86_64"] = """
 #endif
 #define __x86_64___X86_64 1
 """;
+footer["x86_64"] = """
+#undef __DECL_REG
+"""
 
 ###########################################################################
 # main
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..de36455 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,14 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32   arm64  x86_32  x86_64
 
-start_info                |       -    1112    1168
-trap_info                 |       -       8      16
-cpu_user_regs             |     160      68     200
-vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+start_info                |       -       -    1112    1168
+trap_info                 |       -       -       8      16
+cpu_user_regs             |       -       -      68     200
+vcpu_guest_core_regs      |     304     304       -       -
+vcpu_guest_context        |     336     336    2800    5168
+arch_vcpu_info            |       -       -      24      16
+vcpu_time_info            |       -       -      32      32
+vcpu_info                 |       -       -      64      64
+arch_shared_info          |       -       -     268     280
+shared_info               |       -       -    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 51a77c0..e3e8771 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -6,6 +6,7 @@ unions  = [ "vcpu_cr_regs",
 structs = [ "start_info",
             "trap_info",
             "cpu_user_regs",
+            "vcpu_guest_core_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 0cec774..e46cec9 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -107,17 +107,17 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     /* clear everything */
     memset(ctxt, 0, sizeof(*ctxt));
 
-    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.pc32 = dom->parms.virt_entry;
 
     /* Linux boot protocol. See linux.Documentation/arm/Booting. */
-    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r0_usr = 0; /* SBZ */
     /* Machine ID: We use DTB therefore no machine id */
-    ctxt->user_regs.r1 = 0xffffffff;
+    ctxt->user_regs.r1_usr = 0xffffffff;
     /* ATAGS/DTB: We currently require that the guest kernel to be
      * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look
      * like a valid pointer to a set of ATAGS or a DTB.
      */
-    ctxt->user_regs.r2 = 0xffffffff;
+    ctxt->user_regs.r2_usr = 0xffffffff;
 
     ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
 
@@ -130,7 +130,7 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     ctxt->flags = VGCF_online;
 
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
-           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
     return 0;
 }
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 20931fa..29898ae 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -3,3 +3,5 @@ subdir-y += lib
 obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm32/domain.c b/xen/arch/arm/arm32/domain.c
new file mode 100644
index 0000000..f75a2c6
--- /dev/null
+++ b/xen/arch/arm/arm32/domain.c
@@ -0,0 +1,51 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(r0,r0_usr);   C(r1,r1_usr);   C(r2,r2_usr);   C(r3,r3_usr);   \
+    C(r4,r4_usr);   C(r5,r5_usr);   C(r6,r6_usr);   C(r7,r7_usr);   \
+    C(r8,r8_usr);   C(r9,r9_usr);   C(r10,r10_usr); C(r11,r11_usr); \
+    C(r12,r12_usr); \
+    C(sp_usr,sp_usr); \
+    C(lr,lr_usr); \
+    C(spsr_irq,spsr_irq); C(lr_irq,lr_irq); C(sp_irq,sp_irq); \
+    C(spsr_svc,spsr_svc); C(lr_svc,lr_svc); C(sp_svc,sp_svc); \
+    C(spsr_abt,spsr_abt); C(lr_abt,lr_abt); C(sp_abt,sp_abt); \
+    C(spsr_und,spsr_und); C(lr_und,lr_und); C(sp_und,sp_und); \
+    C(spsr_fiq,spsr_fiq); C(sp_fiq,sp_fiq); C(sp_fiq,sp_fiq); \
+    C(r8_fiq,r8_fiq); C(r9_fiq,r9_fiq); \
+    C(r10_fiq,r10_fiq); C(r11_fiq,r11_fiq); C(r12_fiq,r12_fiq); \
+    C(pc,pc32); \
+    C(cpsr,cpsr)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c447eaa..815f305 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,3 +1,5 @@
 subdir-y += lib
 
 obj-y += mode_switch.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm64/domain.c b/xen/arch/arm/arm64/domain.c
new file mode 100644
index 0000000..05df29e
--- /dev/null
+++ b/xen/arch/arm/arm64/domain.c
@@ -0,0 +1,66 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(x0,x0);   C(x1,x1);   C(x2,x2);   C(x3,x3);   \
+    C(x4,x4);   C(x5,x5);   C(x6,x6);   C(x7,x7);   \
+    C(x8,x8);   C(x9,x9);   C(x10,x10); C(x11,x11); \
+    C(x12,x12); C(x13,x13); C(x14,x14); C(x15,x15); \
+    C(x16,x16); C(x17,x17); C(x18,x18); C(x19,x19); \
+    C(x20,x20); C(x21,x21); C(x22,x22); C(x23,x23); \
+    C(x24,x24); C(x25,x25); C(x26,x26); C(x27,x27); \
+    C(x28,x28); C(fp,x29);  C(lr,x30);  C(pc,pc64); \
+    C(cpsr, cpsr); C(spsr_el1, spsr_el1)
+
+#define ALLREGS32 C(spsr_fiq, spsr_fiq); C(spsr_irq,spsr_irq); \
+                  C(spsr_und,spsr_und); C(spsr_abt,spsr_abt)
+
+#define ALLREGS64 C(sp_el0,sp_el0); C(sp_el1,sp_el1); C(elr_el1,elr_el1)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e7d3ec6..3651fb2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,7 +486,7 @@ int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
     if ( !is_guest_psr(regs->cpsr) )
         return -EINVAL;
@@ -502,7 +502,7 @@ int arch_set_info_guest(
     if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
         return -EINVAL;
 
-    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+    vcpu_regs_user_to_hyp(v, regs);
 
     v->arch.sctlr = ctxt->sctlr;
     v->arch.ttbr0 = ctxt->ttbr0;
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index c7ffd8a..15f8537 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -20,9 +20,9 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
-    *regs = v->arch.cpu_info->guest_cpu_user_regs;
+    vcpu_regs_hyp_to_user(v, regs);
 
     ctxt->sctlr = v->arch.sctlr;
     ctxt->ttbr0 = v->arch.ttbr0;
diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
index 843fbd2..a782d96 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,58 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#ifndef __ASSEMBLY__
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+        uint32_t r11;
+        uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+        uint32_t lr_usr;
+    };
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_irq, lr_irq;
+    uint32_t sp_svc, lr_svc;
+    uint32_t sp_abt, lr_abt;
+    uint32_t sp_und, lr_und;
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+    uint32_t sp_fiq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
+};
+#endif
+
 /* Layout as used in assembly, with src/dest registers mixed in */
 #define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
 #define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
index fdb0dab..b4602fa 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,87 @@
 
 #ifndef __ASSEMBLY__
 
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+
+#define __DECL_REG(n64, n32) union {            \
+    uint64_t n64;                               \
+    uint32_t n32;                               \
+}
+
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0/*_usr*/);
+    __DECL_REG(x1,           r1/*_usr*/);
+    __DECL_REG(x2,           r2/*_usr*/);
+    __DECL_REG(x3,           r3/*_usr*/);
+    __DECL_REG(x4,           r4/*_usr*/);
+    __DECL_REG(x5,           r5/*_usr*/);
+    __DECL_REG(x6,           r6/*_usr*/);
+    __DECL_REG(x7,           r7/*_usr*/);
+    __DECL_REG(x8,           r8/*_usr*/);
+    __DECL_REG(x9,           r9/*_usr*/);
+    __DECL_REG(x10,          r10/*_usr*/);
+    __DECL_REG(x11 ,         r11/*_usr*/);
+    __DECL_REG(x12,          r12/*_usr*/);
+
+    __DECL_REG(x13,          /* r13_usr */ sp_usr);
+    __DECL_REG(x14,          /* r14_usr */ lr_usr);
+
+    __DECL_REG(x15,          /* r13_hyp */ __unused_sp_hyp);
+
+    __DECL_REG(x16,          /* r14_irq */ lr_irq);
+    __DECL_REG(x17,          /* r13_irq */ sp_irq);
+
+    __DECL_REG(x18,          /* r14_svc */ lr_svc);
+    __DECL_REG(x19,          /* r13_svc */ sp_svc);
+
+    __DECL_REG(x20,          /* r14_abt */ lr_abt);
+    __DECL_REG(x21,          /* r13_abt */ sp_abt);
+
+    __DECL_REG(x22,          /* r14_und */ lr_und);
+    __DECL_REG(x23,          /* r13_und */ sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+    __DECL_REG(/* x29 */ fp, /* r13_fiq */ sp_fiq);
+    __DECL_REG(/* x30 */ lr, /* r14_fiq */ lr_fiq);
+
+    register_t sp; /* Valid for hypervisor frames */
+
+    /* Return address and mode */
+    __DECL_REG(pc,           pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
+
+    uint64_t pad0;
+
+    /* Outer guest frame only from here on... */
+
+    union {
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
+    };
+
+    uint32_t pad1; /* Align */
+
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
+
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
+
+    uint64_t pad2; /* Doubleword-align the user half of the frame */
+};
+
+#undef __DECL_REG
+
+/* Access to system registers */
+
 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
     asm volatile("mrs  %0, "#name : "=r" (_r));         \
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index d20d7a8..c9c8ac7 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -6,6 +6,7 @@
 #include <public/xen.h>
 
 #include <asm/percpu.h>
+#include <asm/processor.h>
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 8183d36..230c901 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,11 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs);
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_H */
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 1397e40..6b4e24f 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -86,55 +86,80 @@
 #endif
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-struct cpu_user_regs
-{
-    uint32_t r0;
-    uint32_t r1;
-    uint32_t r2;
-    uint32_t r3;
-    uint32_t r4;
-    uint32_t r5;
-    uint32_t r6;
-    uint32_t r7;
-    uint32_t r8;
-    uint32_t r9;
-    uint32_t r10;
-    union {
-        uint32_t r11;
-        uint32_t fp;
-    };
-    uint32_t r12;
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+# define __DECL_REG(n64, n32) union {          \
+        uint64_t n64;                          \
+        uint32_t n32;                          \
+    }
+#else
+/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
+#define __DECL_REG(n64, n32) uint64_t n64
+#endif
 
-    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+struct vcpu_guest_core_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0_usr);
+    __DECL_REG(x1,           r1_usr);
+    __DECL_REG(x2,           r2_usr);
+    __DECL_REG(x3,           r3_usr);
+    __DECL_REG(x4,           r4_usr);
+    __DECL_REG(x5,           r5_usr);
+    __DECL_REG(x6,           r6_usr);
+    __DECL_REG(x7,           r7_usr);
+    __DECL_REG(x8,           r8_usr);
+    __DECL_REG(x9,           r9_usr);
+    __DECL_REG(x10,          r10_usr);
+    __DECL_REG(x11,          r11_usr);
+    __DECL_REG(x12,          r12_usr);
+
+    __DECL_REG(x13,          sp_usr);
+    __DECL_REG(x14,          lr_usr);
+
+    __DECL_REG(x15,          __unused_sp_hyp);
+
+    __DECL_REG(x16,          lr_irq);
+    __DECL_REG(x17,          sp_irq);
+
+    __DECL_REG(x18,          lr_svc);
+    __DECL_REG(x19,          sp_svc);
+
+    __DECL_REG(x20,          lr_abt);
+    __DECL_REG(x21,          sp_abt);
+
+    __DECL_REG(x22,          lr_und);
+    __DECL_REG(x23,          sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+
+    __DECL_REG(x29,          sp_fiq);
+    __DECL_REG(x30,          lr_fiq);
+
+    /* Return address and mode */
+    __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
 
-    /* r14 - LR: is the same physical register as LR_usr */
     union {
-        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
-        uint32_t lr_usr;
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
     };
 
-    uint32_t pc; /* Return IP */
-    uint32_t cpsr; /* Return mode */
-    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
-
-    /* Outer guest frame only from here on... */
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
 
-    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
-
-    uint32_t sp_irq, lr_irq;
-    uint32_t sp_svc, lr_svc;
-    uint32_t sp_abt, lr_abt;
-    uint32_t sp_und, lr_und;
-
-    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
-    uint32_t sp_fiq, lr_fiq;
-
-    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
-
-    uint32_t pad1; /* Doubleword-align the user half of the frame */
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
 };
-typedef struct cpu_user_regs cpu_user_regs_t;
-DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+typedef struct vcpu_guest_core_regs vcpu_guest_core_regs_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
+
+#undef __DECL_REG
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
@@ -151,10 +176,10 @@ struct vcpu_guest_context {
 #define VGCF_online                    (1<<_VGCF_online)
     uint32_t flags;                         /* VGCF_* */
 
-    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    struct vcpu_guest_core_regs user_regs;  /* Core CPU registers */
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
1.7.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 Feb 14 14:44:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U602S-0006qr-EY; Thu, 14 Feb 2013 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 <JBeulich@suse.com>) id 1U602R-0006qj-3B
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:43:51 +0000
Received: from [193.109.254.147:53567] by server-3.bemta-14.messagelabs.com id
	8E/C5-22141-628FC115; Thu, 14 Feb 2013 14:43:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360852950!8731453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22744 invoked from network); 14 Feb 2013 14:42:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:42:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 14:42:49 +0000
Message-Id: <511D062202000078000BE541@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 14:43:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
> Most of this struct is PV MMU specific and it is not used on ARM at all.

I'm not convinced this is the right move.

> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
>   *     extended by an extra 4MB to ensure this.
>   */
>  
> -#define MAX_GUEST_CMDLINE 1024
> -struct start_info {
> -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> -    char magic[32];             /* "xen-<version>-<platform>".            */
> -    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> -    unsigned long shared_info;  /* MACHINE address of shared info struct. */
> -    uint32_t flags;             /* SIF_xxx flags.                         */
> -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> -    uint32_t store_evtchn;      /* Event channel for store communication. */
> -    union {
> -        struct {
> -            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> -            uint32_t  evtchn;   /* Event channel for console page.        */
> -        } domU;
> -        struct {
> -            uint32_t info_off;  /* Offset of console_info struct.         */
> -            uint32_t info_size; /* Size of console_info struct from start.*/
> -        } dom0;
> -    } console;

What is PV MMU related up to here?

> -    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
> -    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
> -    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
> -    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
> -    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
> -                                /* (PFN of pre-loaded module if           */
> -                                /*  SIF_MOD_START_PFN set in flags).      */
> -    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> -    int8_t cmd_line[MAX_GUEST_CMDLINE];

The last three fields above don't appear to be either.

> -    /* The pfn range here covers both page table and p->m table frames.   */
> -    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
> -    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
> -};
> -typedef struct start_info start_info_t;
> -
> -/* New console union for dom0 introduced in 0x00030203. */
> -#if __XEN_INTERFACE_VERSION__ < 0x00030203
> -#define console_mfn    console.domU.mfn
> -#define console_evtchn console.domU.evtchn
> -#endif
> -
> -/* These flags are passed in the 'flags' field of start_info_t. */
> -#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> -#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> -#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
> -#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
> -#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */

Nor are these flags.

> -
> -/*
> - * A multiboot module is a package containing modules very similar to a
> - * multiboot module array. The only differences are:
> - * - the array of module descriptors is by convention simply at the beginning
> - *   of the multiboot module,
> - * - addresses in the module descriptors are based on the beginning of the
> - *   multiboot module,
> - * - the number of modules is determined by a termination descriptor that has
> - *   mod_start == 0.
> - *
> - * This permits to both build it statically and reference it in a configuration
> - * file, and let the PV guest easily rebase the addresses to virtual addresses
> - * and at the same time count the number of modules.
> - */
> -struct xen_multiboot_mod_list
> -{
> -    /* Address of first byte of the module */
> -    uint32_t mod_start;
> -    /* Address of last byte of the module (inclusive) */
> -    uint32_t mod_end;
> -    /* Address of zero-terminated command line */
> -    uint32_t cmdline;
> -    /* Unused, must be zero */
> -    uint32_t pad;
> -};

And this one isn't either, albeit I'm not sure about its actual use.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:44:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U602S-0006qr-EY; Thu, 14 Feb 2013 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 <JBeulich@suse.com>) id 1U602R-0006qj-3B
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:43:51 +0000
Received: from [193.109.254.147:53567] by server-3.bemta-14.messagelabs.com id
	8E/C5-22141-628FC115; Thu, 14 Feb 2013 14:43:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360852950!8731453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22744 invoked from network); 14 Feb 2013 14:42:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:42:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 14:42:49 +0000
Message-Id: <511D062202000078000BE541@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 14:43:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
> Most of this struct is PV MMU specific and it is not used on ARM at all.

I'm not convinced this is the right move.

> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
>   *     extended by an extra 4MB to ensure this.
>   */
>  
> -#define MAX_GUEST_CMDLINE 1024
> -struct start_info {
> -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> -    char magic[32];             /* "xen-<version>-<platform>".            */
> -    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> -    unsigned long shared_info;  /* MACHINE address of shared info struct. */
> -    uint32_t flags;             /* SIF_xxx flags.                         */
> -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> -    uint32_t store_evtchn;      /* Event channel for store communication. */
> -    union {
> -        struct {
> -            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> -            uint32_t  evtchn;   /* Event channel for console page.        */
> -        } domU;
> -        struct {
> -            uint32_t info_off;  /* Offset of console_info struct.         */
> -            uint32_t info_size; /* Size of console_info struct from start.*/
> -        } dom0;
> -    } console;

What is PV MMU related up to here?

> -    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
> -    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
> -    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
> -    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
> -    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
> -                                /* (PFN of pre-loaded module if           */
> -                                /*  SIF_MOD_START_PFN set in flags).      */
> -    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> -    int8_t cmd_line[MAX_GUEST_CMDLINE];

The last three fields above don't appear to be either.

> -    /* The pfn range here covers both page table and p->m table frames.   */
> -    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
> -    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
> -};
> -typedef struct start_info start_info_t;
> -
> -/* New console union for dom0 introduced in 0x00030203. */
> -#if __XEN_INTERFACE_VERSION__ < 0x00030203
> -#define console_mfn    console.domU.mfn
> -#define console_evtchn console.domU.evtchn
> -#endif
> -
> -/* These flags are passed in the 'flags' field of start_info_t. */
> -#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> -#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> -#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
> -#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
> -#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */

Nor are these flags.

> -
> -/*
> - * A multiboot module is a package containing modules very similar to a
> - * multiboot module array. The only differences are:
> - * - the array of module descriptors is by convention simply at the beginning
> - *   of the multiboot module,
> - * - addresses in the module descriptors are based on the beginning of the
> - *   multiboot module,
> - * - the number of modules is determined by a termination descriptor that has
> - *   mod_start == 0.
> - *
> - * This permits to both build it statically and reference it in a configuration
> - * file, and let the PV guest easily rebase the addresses to virtual addresses
> - * and at the same time count the number of modules.
> - */
> -struct xen_multiboot_mod_list
> -{
> -    /* Address of first byte of the module */
> -    uint32_t mod_start;
> -    /* Address of last byte of the module (inclusive) */
> -    uint32_t mod_end;
> -    /* Address of zero-terminated command line */
> -    uint32_t cmdline;
> -    /* Unused, must be zero */
> -    uint32_t pad;
> -};

And this one isn't either, albeit I'm not sure about its actual use.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:44:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:44: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 1U602w-0006uE-SI; Thu, 14 Feb 2013 14:44:22 +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 1U602v-0006u0-8D
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:44:21 +0000
Received: from [193.109.254.147:45790] by server-7.bemta-14.messagelabs.com id
	3F/4E-13581-448FC115; Thu, 14 Feb 2013 14:44:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360853056!2306146!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5995 invoked from network); 14 Feb 2013 14:44:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:44:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U601s-000Mh9-Il; Thu, 14 Feb 2013 14:43:16 +0000
Date: Thu, 14 Feb 2013 14:43:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214144316.GA83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 31/45] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956597), Ian Campbell wrote:
> One side effect of this is that we now save the full 64-bit
> TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
> support LPAE guests (although this patch doesn't implement anything
> other than the context switch).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
>  xen/arch/arm/traps.c         |   14 +++---
>  xen/include/asm-arm/cpregs.h |   21 +++++++-
>  xen/include/asm-arm/domain.h |   29 ++++++++---
>  4 files changed, 115 insertions(+), 62 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 077521e..0323552 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -41,55 +41,67 @@ void idle_loop(void)
>  static void ctxt_switch_from(struct vcpu *p)
>  {
>      /* CP 15 */
> -    p->arch.csselr = READ_CP32(CSSELR);
> +    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
>  
>      /* Control Registers */
> -    p->arch.actlr = READ_CP32(ACTLR);
> -    p->arch.sctlr = READ_CP32(SCTLR);
> -    p->arch.cpacr = READ_CP32(CPACR);
> +    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
> +    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> +    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
>  
> -    p->arch.contextidr = READ_CP32(CONTEXTIDR);
> -    p->arch.tpidrurw = READ_CP32(TPIDRURW);
> -    p->arch.tpidruro = READ_CP32(TPIDRURO);
> -    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
> +    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
> +    p->arch.tpidrurw = READ_SYSREG(TPIDR_EL0); /* XXX names */

XXX names indeed. :)  Otherwise:

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 Thu Feb 14 14:44:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:44: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 1U602w-0006uE-SI; Thu, 14 Feb 2013 14:44:22 +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 1U602v-0006u0-8D
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:44:21 +0000
Received: from [193.109.254.147:45790] by server-7.bemta-14.messagelabs.com id
	3F/4E-13581-448FC115; Thu, 14 Feb 2013 14:44:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360853056!2306146!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5995 invoked from network); 14 Feb 2013 14:44:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:44:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U601s-000Mh9-Il; Thu, 14 Feb 2013 14:43:16 +0000
Date: Thu, 14 Feb 2013 14:43:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214144316.GA83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 31/45] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956597), Ian Campbell wrote:
> One side effect of this is that we now save the full 64-bit
> TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
> support LPAE guests (although this patch doesn't implement anything
> other than the context switch).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
>  xen/arch/arm/traps.c         |   14 +++---
>  xen/include/asm-arm/cpregs.h |   21 +++++++-
>  xen/include/asm-arm/domain.h |   29 ++++++++---
>  4 files changed, 115 insertions(+), 62 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 077521e..0323552 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -41,55 +41,67 @@ void idle_loop(void)
>  static void ctxt_switch_from(struct vcpu *p)
>  {
>      /* CP 15 */
> -    p->arch.csselr = READ_CP32(CSSELR);
> +    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
>  
>      /* Control Registers */
> -    p->arch.actlr = READ_CP32(ACTLR);
> -    p->arch.sctlr = READ_CP32(SCTLR);
> -    p->arch.cpacr = READ_CP32(CPACR);
> +    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
> +    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> +    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
>  
> -    p->arch.contextidr = READ_CP32(CONTEXTIDR);
> -    p->arch.tpidrurw = READ_CP32(TPIDRURW);
> -    p->arch.tpidruro = READ_CP32(TPIDRURO);
> -    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
> +    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
> +    p->arch.tpidrurw = READ_SYSREG(TPIDR_EL0); /* XXX names */

XXX names indeed. :)  Otherwise:

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 Thu Feb 14 14:44:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U603P-0006yL-9S; Thu, 14 Feb 2013 14:44:51 +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 1U603N-0006y3-Vq
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:44:50 +0000
Received: from [193.109.254.147:7172] by server-3.bemta-14.messagelabs.com id
	A3/27-22141-168FC115; Thu, 14 Feb 2013 14:44:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360853056!8704120!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17246 invoked from network); 14 Feb 2013 14:44:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:43: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.297.1;
	Thu, 14 Feb 2013 14:43:16 +0000
Message-ID: <1360852995.20449.411.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:43:15 +0000
In-Reply-To: <20130214143013.GX83752@ocelot.phlegethon.org>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
	<20130214143013.GX83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
 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>
Content-Type: text/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, 2013-02-14 at 14:30 +0000, Tim Deegan wrote:
> At 14:16 +0000 on 14 Feb (1360851371), Ian Campbell wrote:
> > --- a/tools/include/xen-foreign/mkheader.py
> > +++ b/tools/include/xen-foreign/mkheader.py
> > @@ -17,11 +17,15 @@ header = {};
> >  footer = {};
> >  
> >  #arm
> > -inttypes["arm"] = {
> > +inttypes["arm32"] = {
> >      "unsigned long" : "uint32_t",
> >      "long"          : "uint32_t",
> >      "xen_pfn_t"     : "uint64_t",
> >  };
> > +header["x86_32"] = """
> 
> ["arm32"] ?

Oh bum, yes. That's what I get for rebasing at the last minute ;-)

> 
> Tim.
> 
> > +#define __arm__ARM32 1
> > +""";
> > +



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:44:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U603P-0006yL-9S; Thu, 14 Feb 2013 14:44:51 +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 1U603N-0006y3-Vq
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:44:50 +0000
Received: from [193.109.254.147:7172] by server-3.bemta-14.messagelabs.com id
	A3/27-22141-168FC115; Thu, 14 Feb 2013 14:44:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360853056!8704120!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17246 invoked from network); 14 Feb 2013 14:44:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:43: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.297.1;
	Thu, 14 Feb 2013 14:43:16 +0000
Message-ID: <1360852995.20449.411.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:43:15 +0000
In-Reply-To: <20130214143013.GX83752@ocelot.phlegethon.org>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
	<20130214143013.GX83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
 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>
Content-Type: text/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, 2013-02-14 at 14:30 +0000, Tim Deegan wrote:
> At 14:16 +0000 on 14 Feb (1360851371), Ian Campbell wrote:
> > --- a/tools/include/xen-foreign/mkheader.py
> > +++ b/tools/include/xen-foreign/mkheader.py
> > @@ -17,11 +17,15 @@ header = {};
> >  footer = {};
> >  
> >  #arm
> > -inttypes["arm"] = {
> > +inttypes["arm32"] = {
> >      "unsigned long" : "uint32_t",
> >      "long"          : "uint32_t",
> >      "xen_pfn_t"     : "uint64_t",
> >  };
> > +header["x86_32"] = """
> 
> ["arm32"] ?

Oh bum, yes. That's what I get for rebasing at the last minute ;-)

> 
> Tim.
> 
> > +#define __arm__ARM32 1
> > +""";
> > +



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:47:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:47: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 1U605O-0007Ey-Qp; Thu, 14 Feb 2013 14:46: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 1U605N-0007Ep-PQ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:46:53 +0000
Received: from [85.158.143.99:7854] by server-2.bemta-4.messagelabs.com id
	B8/A7-01597-DD8FC115; Thu, 14 Feb 2013 14:46:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360853212!17917743!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27026 invoked from network); 14 Feb 2013 14:46:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:46: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.297.1;
	Thu, 14 Feb 2013 14:46:52 +0000
Message-ID: <1360853210.20449.414.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 14:46:50 +0000
In-Reply-To: <511D062202000078000BE541@nat28.tlf.novell.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:43 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Most of this struct is PV MMU specific and it is not used on ARM at all.
> 
> I'm not convinced this is the right move.
> 
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
> >   *     extended by an extra 4MB to ensure this.
> >   */
> >  
> > -#define MAX_GUEST_CMDLINE 1024
> > -struct start_info {
> > -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> > -    char magic[32];             /* "xen-<version>-<platform>".            */
> > -    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> > -    unsigned long shared_info;  /* MACHINE address of shared info struct. */
> > -    uint32_t flags;             /* SIF_xxx flags.                         */
> > -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> > -    uint32_t store_evtchn;      /* Event channel for store communication. */
> > -    union {
> > -        struct {
> > -            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> > -            uint32_t  evtchn;   /* Event channel for console page.        */
> > -        } domU;
> > -        struct {
> > -            uint32_t info_off;  /* Offset of console_info struct.         */
> > -            uint32_t info_size; /* Size of console_info struct from start.*/
> > -        } dom0;
> > -    } console;
> 
> What is PV MMU related up to here?

Hrm, perhaps categorising this as PV MMU was a mistake on my part.

These are all unused on ARM in terms of the hypervisor ABI since it uses
HVM like mechanisms for those which are appropriate and doesn't use a
bunch of the others at all.

> > -struct xen_multiboot_mod_list
> > -{
> > -    /* Address of first byte of the module */
> > -    uint32_t mod_start;
> > -    /* Address of last byte of the module (inclusive) */
> > -    uint32_t mod_end;
> > -    /* Address of zero-terminated command line */
> > -    uint32_t cmdline;
> > -    /* Unused, must be zero */
> > -    uint32_t pad;
> > -};
> 
> And this one isn't either, albeit I'm not sure about its actual use.

It's unused AFAICT.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:47:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:47: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 1U605O-0007Ey-Qp; Thu, 14 Feb 2013 14:46: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 1U605N-0007Ep-PQ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:46:53 +0000
Received: from [85.158.143.99:7854] by server-2.bemta-4.messagelabs.com id
	B8/A7-01597-DD8FC115; Thu, 14 Feb 2013 14:46:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360853212!17917743!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27026 invoked from network); 14 Feb 2013 14:46:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1464905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:46: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.297.1;
	Thu, 14 Feb 2013 14:46:52 +0000
Message-ID: <1360853210.20449.414.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 14:46:50 +0000
In-Reply-To: <511D062202000078000BE541@nat28.tlf.novell.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:43 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Most of this struct is PV MMU specific and it is not used on ARM at all.
> 
> I'm not convinced this is the right move.
> 
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
> >   *     extended by an extra 4MB to ensure this.
> >   */
> >  
> > -#define MAX_GUEST_CMDLINE 1024
> > -struct start_info {
> > -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> > -    char magic[32];             /* "xen-<version>-<platform>".            */
> > -    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> > -    unsigned long shared_info;  /* MACHINE address of shared info struct. */
> > -    uint32_t flags;             /* SIF_xxx flags.                         */
> > -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> > -    uint32_t store_evtchn;      /* Event channel for store communication. */
> > -    union {
> > -        struct {
> > -            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> > -            uint32_t  evtchn;   /* Event channel for console page.        */
> > -        } domU;
> > -        struct {
> > -            uint32_t info_off;  /* Offset of console_info struct.         */
> > -            uint32_t info_size; /* Size of console_info struct from start.*/
> > -        } dom0;
> > -    } console;
> 
> What is PV MMU related up to here?

Hrm, perhaps categorising this as PV MMU was a mistake on my part.

These are all unused on ARM in terms of the hypervisor ABI since it uses
HVM like mechanisms for those which are appropriate and doesn't use a
bunch of the others at all.

> > -struct xen_multiboot_mod_list
> > -{
> > -    /* Address of first byte of the module */
> > -    uint32_t mod_start;
> > -    /* Address of last byte of the module (inclusive) */
> > -    uint32_t mod_end;
> > -    /* Address of zero-terminated command line */
> > -    uint32_t cmdline;
> > -    /* Unused, must be zero */
> > -    uint32_t pad;
> > -};
> 
> And this one isn't either, albeit I'm not sure about its actual use.

It's unused AFAICT.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:48:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:48: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 1U606W-0007NE-9i; Thu, 14 Feb 2013 14:48: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 1U606T-0007Mt-Pw
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:48:02 +0000
Received: from [85.158.139.83:34076] by server-16.bemta-5.messagelabs.com id
	BA/85-14948-029FC115; Thu, 14 Feb 2013 14:48:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360853280!28099537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 14 Feb 2013 14:48:00 -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; 14 Feb 2013 14:48:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 14:48:20 +0000
Message-Id: <511D076902000078000BE556@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 14:48:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <51151ABF.1070007@canonical.com> <511CC4D8.3060203@canonical.com>
	<511CDBF302000078000BE2D7@nat28.tlf.novell.com>
	<511CF2D7.6090004@canonical.com>
In-Reply-To: <511CF2D7.6090004@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> Having more understanding now, I had a different idea. Not sure this is
> foolproof and surely is causing some more active spinning. But it looks like I
> also can keep the system from locking up (v3.2 kernel and the testcase) if I
> change xen_spin_unlock_slow to send the wakeup IPI to _all_ spinners instead 
> of only the first one found.

That, afaict, is an absolute requirement with the open coded
lock that you pointed at, as otherwise the code makes a
pseudo ticket assumption in believing to know who's going to
be the next owner of the lock.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:48:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:48: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 1U606W-0007NE-9i; Thu, 14 Feb 2013 14:48: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 1U606T-0007Mt-Pw
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:48:02 +0000
Received: from [85.158.139.83:34076] by server-16.bemta-5.messagelabs.com id
	BA/85-14948-029FC115; Thu, 14 Feb 2013 14:48:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1360853280!28099537!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3201 invoked from network); 14 Feb 2013 14:48:00 -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; 14 Feb 2013 14:48:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 14:48:20 +0000
Message-Id: <511D076902000078000BE556@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 14:48:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <51151ABF.1070007@canonical.com> <511CC4D8.3060203@canonical.com>
	<511CDBF302000078000BE2D7@nat28.tlf.novell.com>
	<511CF2D7.6090004@canonical.com>
In-Reply-To: <511CF2D7.6090004@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Strange PVM spinlock case revisited (nailed 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> Having more understanding now, I had a different idea. Not sure this is
> foolproof and surely is causing some more active spinning. But it looks like I
> also can keep the system from locking up (v3.2 kernel and the testcase) if I
> change xen_spin_unlock_slow to send the wakeup IPI to _all_ spinners instead 
> of only the first one found.

That, afaict, is an absolute requirement with the open coded
lock that you pointed at, as otherwise the code makes a
pseudo ticket assumption in believing to know who's going to
be the next owner of the lock.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:48:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:48: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 1U6073-0007Ro-O9; Thu, 14 Feb 2013 14:48:37 +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 1U6071-0007RP-Kb
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:48:35 +0000
Received: from [193.109.254.147:19545] by server-3.bemta-14.messagelabs.com id
	68/AC-22141-249FC115; Thu, 14 Feb 2013 14:48:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360853313!8511344!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13938 invoked from network); 14 Feb 2013 14:48:34 -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; 14 Feb 2013 14:48:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U606z-000Mir-Mz; Thu, 14 Feb 2013 14:48:33 +0000
Date: Thu, 14 Feb 2013 14:48:33 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214144833.GB83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
	<1360852832.20449.409.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360852832.20449.409.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs
	from internal guest 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

At 14:40 +0000 on 14 Feb (1360852832), Ian Campbell wrote:
> Subject: [PATCH] xen: arm: separate guest user regs from internal guest state.
> 
> struct cpu_user_regs is currently used as both internal state
> (specifically at the base of the stack) and a guest/toolstack
> visible API (via struct vcpu_guest_context used by
> XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).
> 
> This causes problems when we want to make the API 64-bit clean since
> we don't really want to change the size of the on-stack struct.
> 
> So split into vcpu_guest_core_regs which is the API facing struct
> and keep cpu_user_regs purely internal, translate between the two.
> 
> In the user API arrange for both 64- and 32-bit registers to be
> included in a layout which does not differ depending on toolstack
> architecture. Also switch to using the more formal banked register
> names (e.g. with the _usr suffix) for clarity.
> 
> This is an ABI change. Note that the kernel doesn't currently use
> this data structure so it affects the tools interface only.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Allow 32-bit to see 64-bit register names too, this is needed so that
>     32-bit toolstacks can access/control 64-bit guests.

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 Thu Feb 14 14:48:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:48: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 1U6073-0007Ro-O9; Thu, 14 Feb 2013 14:48:37 +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 1U6071-0007RP-Kb
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:48:35 +0000
Received: from [193.109.254.147:19545] by server-3.bemta-14.messagelabs.com id
	68/AC-22141-249FC115; Thu, 14 Feb 2013 14:48:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360853313!8511344!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13938 invoked from network); 14 Feb 2013 14:48:34 -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; 14 Feb 2013 14:48:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U606z-000Mir-Mz; Thu, 14 Feb 2013 14:48:33 +0000
Date: Thu, 14 Feb 2013 14:48:33 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214144833.GB83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-25-git-send-email-ian.campbell@citrix.com>
	<20130214131041.GR83752@ocelot.phlegethon.org>
	<1360849103.20449.371.camel@zakaz.uk.xensource.com>
	<1360852832.20449.409.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360852832.20449.409.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs
	from internal guest 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

At 14:40 +0000 on 14 Feb (1360852832), Ian Campbell wrote:
> Subject: [PATCH] xen: arm: separate guest user regs from internal guest state.
> 
> struct cpu_user_regs is currently used as both internal state
> (specifically at the base of the stack) and a guest/toolstack
> visible API (via struct vcpu_guest_context used by
> XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).
> 
> This causes problems when we want to make the API 64-bit clean since
> we don't really want to change the size of the on-stack struct.
> 
> So split into vcpu_guest_core_regs which is the API facing struct
> and keep cpu_user_regs purely internal, translate between the two.
> 
> In the user API arrange for both 64- and 32-bit registers to be
> included in a layout which does not differ depending on toolstack
> architecture. Also switch to using the more formal banked register
> names (e.g. with the _usr suffix) for clarity.
> 
> This is an ABI change. Note that the kernel doesn't currently use
> this data structure so it affects the tools interface only.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Allow 32-bit to see 64-bit register names too, this is needed so that
>     32-bit toolstacks can access/control 64-bit guests.

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 Thu Feb 14 14:50:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U608p-0007fl-8f; Thu, 14 Feb 2013 14:50:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U608o-0007fc-Na
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:50:26 +0000
Received: from [85.158.143.35:18464] by server-3.bemta-4.messagelabs.com id
	96/4A-08920-2B9FC115; Thu, 14 Feb 2013 14:50:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360853421!10117665!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 14 Feb 2013 14:50:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1465049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:50: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.297.1;
	Thu, 14 Feb 2013 14:50:21 +0000
Message-ID: <1360853419.20449.417.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:50:19 +0000
In-Reply-To: <20130214144316.GA83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
	<20130214144316.GA83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 31/45] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:43 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956597), Ian Campbell wrote:
> > One side effect of this is that we now save the full 64-bit
> > TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
> > support LPAE guests (although this patch doesn't implement anything
> > other than the context switch).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
> >  xen/arch/arm/traps.c         |   14 +++---
> >  xen/include/asm-arm/cpregs.h |   21 +++++++-
> >  xen/include/asm-arm/domain.h |   29 ++++++++---
> >  4 files changed, 115 insertions(+), 62 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 077521e..0323552 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -41,55 +41,67 @@ void idle_loop(void)
> >  static void ctxt_switch_from(struct vcpu *p)
> >  {
> >      /* CP 15 */
> > -    p->arch.csselr = READ_CP32(CSSELR);
> > +    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
> >  
> >      /* Control Registers */
> > -    p->arch.actlr = READ_CP32(ACTLR);
> > -    p->arch.sctlr = READ_CP32(SCTLR);
> > -    p->arch.cpacr = READ_CP32(CPACR);
> > +    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
> > +    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> > +    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
> >  
> > -    p->arch.contextidr = READ_CP32(CONTEXTIDR);
> > -    p->arch.tpidrurw = READ_CP32(TPIDRURW);
> > -    p->arch.tpidruro = READ_CP32(TPIDRURO);
> > -    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
> > +    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
> > +    p->arch.tpidrurw = READ_SYSREG(TPIDR_EL0); /* XXX names */
> 
> XXX names indeed. :)

Do you think:
        s/tpidrurw/tpidr_el0/
        s/tpidrprw/tpidr_el1/
        s/tpidruro/tpidrro_el0/
        
would be an improvement? They are all pretty aweful but the consistent
answer would be to use the aarch64 names.

>   Otherwise:
> 
> Acked-by: Tim Deegan <tim@xen.org>

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 Feb 14 14:50:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14: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 1U608p-0007fl-8f; Thu, 14 Feb 2013 14:50:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U608o-0007fc-Na
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:50:26 +0000
Received: from [85.158.143.35:18464] by server-3.bemta-4.messagelabs.com id
	96/4A-08920-2B9FC115; Thu, 14 Feb 2013 14:50:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360853421!10117665!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 14 Feb 2013 14:50:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 14:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1465049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 14:50: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.297.1;
	Thu, 14 Feb 2013 14:50:21 +0000
Message-ID: <1360853419.20449.417.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 14:50:19 +0000
In-Reply-To: <20130214144316.GA83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
	<20130214144316.GA83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 31/45] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:43 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956597), Ian Campbell wrote:
> > One side effect of this is that we now save the full 64-bit
> > TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
> > support LPAE guests (although this patch doesn't implement anything
> > other than the context switch).
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
> >  xen/arch/arm/traps.c         |   14 +++---
> >  xen/include/asm-arm/cpregs.h |   21 +++++++-
> >  xen/include/asm-arm/domain.h |   29 ++++++++---
> >  4 files changed, 115 insertions(+), 62 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 077521e..0323552 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -41,55 +41,67 @@ void idle_loop(void)
> >  static void ctxt_switch_from(struct vcpu *p)
> >  {
> >      /* CP 15 */
> > -    p->arch.csselr = READ_CP32(CSSELR);
> > +    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
> >  
> >      /* Control Registers */
> > -    p->arch.actlr = READ_CP32(ACTLR);
> > -    p->arch.sctlr = READ_CP32(SCTLR);
> > -    p->arch.cpacr = READ_CP32(CPACR);
> > +    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
> > +    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> > +    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
> >  
> > -    p->arch.contextidr = READ_CP32(CONTEXTIDR);
> > -    p->arch.tpidrurw = READ_CP32(TPIDRURW);
> > -    p->arch.tpidruro = READ_CP32(TPIDRURO);
> > -    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
> > +    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
> > +    p->arch.tpidrurw = READ_SYSREG(TPIDR_EL0); /* XXX names */
> 
> XXX names indeed. :)

Do you think:
        s/tpidrurw/tpidr_el0/
        s/tpidrprw/tpidr_el1/
        s/tpidruro/tpidrro_el0/
        
would be an improvement? They are all pretty aweful but the consistent
answer would be to use the aarch64 names.

>   Otherwise:
> 
> Acked-by: Tim Deegan <tim@xen.org>

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 Feb 14 14:55:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:55: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 1U60Ds-00083W-0a; Thu, 14 Feb 2013 14:55:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U60Dq-00083P-99
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:55:38 +0000
Received: from [85.158.137.99:59952] by server-8.bemta-3.messagelabs.com id
	39/F7-25687-9EAFC115; Thu, 14 Feb 2013 14:55:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360853734!20627543!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIyNTA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30908 invoked from network); 14 Feb 2013 14:55:36 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:55:36 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EEtXJW023481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 14:55:34 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
	r1EEtX1G024927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 14:55:33 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
	r1EEtWYn026583; Thu, 14 Feb 2013 08:55:32 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.54.14) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 06:55:32 -0800
Message-ID: <511CFAD4.9040905@oracle.com>
Date: Thu, 14 Feb 2013 09:55:16 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
	<511CD8C202000078000BE280@nat28.tlf.novell.com>
In-Reply-To: <511CD8C202000078000BE280@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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-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/14/2013 06:29 AM, Jan Beulich wrote:
>>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
>>
>> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9
> This is really odd: The "iommu=debug" output you made available
> shows that while there are further devices that have no associated
> IOMMU, the bus scan done in the hypervisor didn't even find a
> device at 06:00.1. Which I see possible only in two ways: Either
> the device becomes visible on the bus only when the driver for
> 06:00.0 loads (and is otherwise detectable only by other means,
> e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
> properly set. That latter aspect could be checked by looking at
> the raw (hex) config space dump of 06:00.0.

If I read this correctly, Linux enables multi-functionness (?):

http://lxr.linux.no/#linux+v3.7.7/drivers/pci/quirks.c#L1494

So you are probably right. BIOS does not enumerate 06:00.1 in IVRS because
it doesn't see it enabled yet.

>
> Boris, one other thought I had in this context: Is it really possible
> for functions on the same (non-bridge) device to be serviced
> by different IOMMUs?

I can't see how this may be possible: IOMMU is PCIe root complex and any
downstream device can only send transactions through its root. (I hope I am
using right terminology).

> If not, find_iommu_for_device() could simply
> look for function 0 if nothing is known about the passed in function.

Yes, this could work. But with a warning in the log.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:55:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:55: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 1U60Ds-00083W-0a; Thu, 14 Feb 2013 14:55:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U60Dq-00083P-99
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:55:38 +0000
Received: from [85.158.137.99:59952] by server-8.bemta-3.messagelabs.com id
	39/F7-25687-9EAFC115; Thu, 14 Feb 2013 14:55:37 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1360853734!20627543!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIyNTA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30908 invoked from network); 14 Feb 2013 14:55:36 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:55:36 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EEtXJW023481
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 14:55:34 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
	r1EEtX1G024927
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 14:55:33 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
	r1EEtWYn026583; Thu, 14 Feb 2013 08:55:32 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.54.14) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 06:55:32 -0800
Message-ID: <511CFAD4.9040905@oracle.com>
Date: Thu, 14 Feb 2013 09:55:16 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
	<511CD8C202000078000BE280@nat28.tlf.novell.com>
In-Reply-To: <511CD8C202000078000BE280@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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-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/14/2013 06:29 AM, Jan Beulich wrote:
>>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
>>
>> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9
> This is really odd: The "iommu=debug" output you made available
> shows that while there are further devices that have no associated
> IOMMU, the bus scan done in the hypervisor didn't even find a
> device at 06:00.1. Which I see possible only in two ways: Either
> the device becomes visible on the bus only when the driver for
> 06:00.0 loads (and is otherwise detectable only by other means,
> e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
> properly set. That latter aspect could be checked by looking at
> the raw (hex) config space dump of 06:00.0.

If I read this correctly, Linux enables multi-functionness (?):

http://lxr.linux.no/#linux+v3.7.7/drivers/pci/quirks.c#L1494

So you are probably right. BIOS does not enumerate 06:00.1 in IVRS because
it doesn't see it enabled yet.

>
> Boris, one other thought I had in this context: Is it really possible
> for functions on the same (non-bridge) device to be serviced
> by different IOMMUs?

I can't see how this may be possible: IOMMU is PCIe root complex and any
downstream device can only send transactions through its root. (I hope I am
using right terminology).

> If not, find_iommu_for_device() could simply
> look for function 0 if nothing is known about the passed in function.

Yes, this could work. But with a warning in the log.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:59:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:59: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 1U60HQ-0008Cv-Su; Thu, 14 Feb 2013 14:59:20 +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 1U60HP-0008Cq-Ef
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:59:19 +0000
Received: from [85.158.137.99:49082] by server-12.bemta-3.messagelabs.com id
	18/FB-05889-6CBFC115; Thu, 14 Feb 2013 14:59:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360853957!13056809!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27674 invoked from network); 14 Feb 2013 14:59:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:59:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60HN-000MlV-7Y; Thu, 14 Feb 2013 14:59:17 +0000
Date: Thu, 14 Feb 2013 14:59:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214145917.GC83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 32/45] xen: arm: show_registers() support
	for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956598), Ian Campbell wrote:
> -static void _show_registers(struct cpu_user_regs *regs,
> -                            struct reg_ctxt *ctxt,
> -                            int guest_mode)
> +
> +static void _show_registers_32(struct cpu_user_regs *regs,

Can we drop the _extraneous _underscore while we're here?

>      {
> -        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
> +        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
> +        printk("  TCR_EL1: %08"PRIx32"\n",ctxt->tcr);

Missing space  ------------------------------^

> +#ifdef CONFIG_ARM_32
>      printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
>      printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
>      printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
>      printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
>      printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
>      printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
> +    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
>      printk("\n");
>  
>      printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
>      printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
>      printk("\n");
> +#else
> +    reg = READ_SYSREG64(TTBR0_EL2); printk("TTBR0_EL2: %"PRIx64"\n", reg);

Any reason this (&c) isn't printk("...", READ_SYSREG64(...)) like the
arm32 ones?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 14:59:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 14:59: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 1U60HQ-0008Cv-Su; Thu, 14 Feb 2013 14:59:20 +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 1U60HP-0008Cq-Ef
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 14:59:19 +0000
Received: from [85.158.137.99:49082] by server-12.bemta-3.messagelabs.com id
	18/FB-05889-6CBFC115; Thu, 14 Feb 2013 14:59:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360853957!13056809!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27674 invoked from network); 14 Feb 2013 14:59:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 14:59:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60HN-000MlV-7Y; Thu, 14 Feb 2013 14:59:17 +0000
Date: Thu, 14 Feb 2013 14:59:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214145917.GC83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 32/45] xen: arm: show_registers() support
	for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956598), Ian Campbell wrote:
> -static void _show_registers(struct cpu_user_regs *regs,
> -                            struct reg_ctxt *ctxt,
> -                            int guest_mode)
> +
> +static void _show_registers_32(struct cpu_user_regs *regs,

Can we drop the _extraneous _underscore while we're here?

>      {
> -        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
> +        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
> +        printk("  TCR_EL1: %08"PRIx32"\n",ctxt->tcr);

Missing space  ------------------------------^

> +#ifdef CONFIG_ARM_32
>      printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
>      printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
>      printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
>      printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
>      printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
>      printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
> +    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
>      printk("\n");
>  
>      printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
>      printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
>      printk("\n");
> +#else
> +    reg = READ_SYSREG64(TTBR0_EL2); printk("TTBR0_EL2: %"PRIx64"\n", reg);

Any reason this (&c) isn't printk("...", READ_SYSREG64(...)) like the
arm32 ones?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:00:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:00: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 1U60Ie-0008Jz-DA; Thu, 14 Feb 2013 15:00:36 +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 1U60Id-0008Jl-5M
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:00:35 +0000
Received: from [85.158.139.211:47498] by server-1.bemta-5.messagelabs.com id
	AD/97-29263-21CFC115; Thu, 14 Feb 2013 15:00:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360854032!19727632!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19660 invoked from network); 14 Feb 2013 15:00:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:00:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60Ia-000MmR-1u; Thu, 14 Feb 2013 15:00:32 +0000
Date: Thu, 14 Feb 2013 15:00:32 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214150031.GD83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
	<20130214144316.GA83752@ocelot.phlegethon.org>
	<1360853419.20449.417.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360853419.20449.417.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 31/45] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:50 +0000 on 14 Feb (1360853419), Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:43 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956597), Ian Campbell wrote:
> > > One side effect of this is that we now save the full 64-bit
> > > TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
> > > support LPAE guests (although this patch doesn't implement anything
> > > other than the context switch).
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
> > >  xen/arch/arm/traps.c         |   14 +++---
> > >  xen/include/asm-arm/cpregs.h |   21 +++++++-
> > >  xen/include/asm-arm/domain.h |   29 ++++++++---
> > >  4 files changed, 115 insertions(+), 62 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > index 077521e..0323552 100644
> > > --- a/xen/arch/arm/domain.c
> > > +++ b/xen/arch/arm/domain.c
> > > @@ -41,55 +41,67 @@ void idle_loop(void)
> > >  static void ctxt_switch_from(struct vcpu *p)
> > >  {
> > >      /* CP 15 */
> > > -    p->arch.csselr = READ_CP32(CSSELR);
> > > +    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
> > >  
> > >      /* Control Registers */
> > > -    p->arch.actlr = READ_CP32(ACTLR);
> > > -    p->arch.sctlr = READ_CP32(SCTLR);
> > > -    p->arch.cpacr = READ_CP32(CPACR);
> > > +    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
> > > +    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> > > +    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
> > >  
> > > -    p->arch.contextidr = READ_CP32(CONTEXTIDR);
> > > -    p->arch.tpidrurw = READ_CP32(TPIDRURW);
> > > -    p->arch.tpidruro = READ_CP32(TPIDRURO);
> > > -    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
> > > +    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
> > > +    p->arch.tpidrurw = READ_SYSREG(TPIDR_EL0); /* XXX names */
> > 
> > XXX names indeed. :)
> 
> Do you think:
>         s/tpidrurw/tpidr_el0/
>         s/tpidrprw/tpidr_el1/
>         s/tpidruro/tpidrro_el0/
>         
> would be an improvement? They are all pretty aweful but the consistent
> answer would be to use the aarch64 names.

Yes, I think so - it matches how these registers are handled everywhere
else.  With just that change you can keep my ack on the patch.

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 Feb 14 15:00:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:00: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 1U60Ie-0008Jz-DA; Thu, 14 Feb 2013 15:00:36 +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 1U60Id-0008Jl-5M
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:00:35 +0000
Received: from [85.158.139.211:47498] by server-1.bemta-5.messagelabs.com id
	AD/97-29263-21CFC115; Thu, 14 Feb 2013 15:00:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360854032!19727632!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19660 invoked from network); 14 Feb 2013 15:00:32 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:00:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60Ia-000MmR-1u; Thu, 14 Feb 2013 15:00:32 +0000
Date: Thu, 14 Feb 2013 15:00:32 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130214150031.GD83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-31-git-send-email-ian.campbell@citrix.com>
	<20130214144316.GA83752@ocelot.phlegethon.org>
	<1360853419.20449.417.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360853419.20449.417.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 31/45] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:50 +0000 on 14 Feb (1360853419), Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:43 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956597), Ian Campbell wrote:
> > > One side effect of this is that we now save the full 64-bit
> > > TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
> > > support LPAE guests (although this patch doesn't implement anything
> > > other than the context switch).
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
> > >  xen/arch/arm/traps.c         |   14 +++---
> > >  xen/include/asm-arm/cpregs.h |   21 +++++++-
> > >  xen/include/asm-arm/domain.h |   29 ++++++++---
> > >  4 files changed, 115 insertions(+), 62 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > index 077521e..0323552 100644
> > > --- a/xen/arch/arm/domain.c
> > > +++ b/xen/arch/arm/domain.c
> > > @@ -41,55 +41,67 @@ void idle_loop(void)
> > >  static void ctxt_switch_from(struct vcpu *p)
> > >  {
> > >      /* CP 15 */
> > > -    p->arch.csselr = READ_CP32(CSSELR);
> > > +    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
> > >  
> > >      /* Control Registers */
> > > -    p->arch.actlr = READ_CP32(ACTLR);
> > > -    p->arch.sctlr = READ_CP32(SCTLR);
> > > -    p->arch.cpacr = READ_CP32(CPACR);
> > > +    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
> > > +    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
> > > +    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
> > >  
> > > -    p->arch.contextidr = READ_CP32(CONTEXTIDR);
> > > -    p->arch.tpidrurw = READ_CP32(TPIDRURW);
> > > -    p->arch.tpidruro = READ_CP32(TPIDRURO);
> > > -    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
> > > +    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
> > > +    p->arch.tpidrurw = READ_SYSREG(TPIDR_EL0); /* XXX names */
> > 
> > XXX names indeed. :)
> 
> Do you think:
>         s/tpidrurw/tpidr_el0/
>         s/tpidrprw/tpidr_el1/
>         s/tpidruro/tpidrro_el0/
>         
> would be an improvement? They are all pretty aweful but the consistent
> answer would be to use the aarch64 names.

Yes, I think so - it matches how these registers are handled everywhere
else.  With just that change you can keep my ack on the patch.

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 Feb 14 15:02:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60KP-0008Ug-UA; Thu, 14 Feb 2013 15:02:25 +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 1U60KP-0008UT-2n
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:02:25 +0000
Received: from [85.158.139.211:36336] by server-12.bemta-5.messagelabs.com id
	D1/80-20195-08CFC115; Thu, 14 Feb 2013 15:02:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360854143!22505465!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13857 invoked from network); 14 Feb 2013 15:02:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:02:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1465633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:02:23 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 14 Feb 2013 15:02:23 +0000
Message-ID: <511CFC93.9070205@citrix.com>
Date: Thu, 14 Feb 2013 16:02:43 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
	<20130214132318.GC2506@phenom.dumpdata.com>
In-Reply-To: <20130214132318.GC2506@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 14/02/13 14:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 14, 2013 at 11:12:09AM +0100, Roger Pau Monne wrote:
>> With current persistent grants implementation we are not freeing the
>> persistent grants after we disconnect the device. Since grant map
> =

> Can you explain this in more details please? Isn't gnttab_set_unmap_op
> in free_persistent_gnts doing the right job of putting in the right
> mfn in? And then we could free the page?

No, after gnttab_unmap_refs the page still points to the grant frame
mfn. All the users of grant frames either have an internal buffer of
pages that are reused (like blkback), or use balloon pages (like gntdev).

I could probably modify gnttab_map to store the mfn and set it back at
gnttab_unmap, but that will surely require more work than this simple fix.

> =

> =

>> operations change the mfn of the allocated page, and we can no longer
>> pass it to __free_page without setting the mfn to a sane value, use
>> balloon grant pages instead, as the gntdev device does.
> =

> =

> Wow. I did not realize that we leaving such a huge memory leak behind!
> But I guess that was never an issue as we would recycle those persistent
> grants to other domains.

No, we didn't recycle them AFAIK, we allocated them using alloc_page,
passed them to gnttab_map, used them, and when closing the backend we
only unmapped them, but they where never freed.

>>
>> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
>> Cc: xen-devel@lists.xen.org
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  drivers/block/xen-blkback/blkback.c |    6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blk=
back/blkback.c
>> index c46824f..e6c2f6a 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -46,6 +46,7 @@
>>  #include <xen/xen.h>
>>  #include <asm/xen/hypervisor.h>
>>  #include <asm/xen/hypercall.h>
>> +#include <xen/balloon.h>
>>  #include "common.h"
>>  =

>>  /*
>> @@ -239,6 +240,7 @@ static void free_persistent_gnts(struct rb_root *roo=
t, unsigned int num)
>>  			ret =3D gnttab_unmap_refs(unmap, NULL, pages,
>>  				segs_to_unmap);
>>  			BUG_ON(ret);
>> +			free_xenballooned_pages(segs_to_unmap, pages);
>>  			segs_to_unmap =3D 0;
>>  		}
>>  =

>> @@ -527,8 +529,8 @@ static int xen_blkbk_map(struct blkif_request *req,
>>  				GFP_KERNEL);
>>  			if (!persistent_gnt)
>>  				return -ENOMEM;
>> -			persistent_gnt->page =3D alloc_page(GFP_KERNEL);
>> -			if (!persistent_gnt->page) {
>> +			if (alloc_xenballooned_pages(1, &persistent_gnt->page,
>> +			    false)) {
>>  				kfree(persistent_gnt);
>>  				return -ENOMEM;
>>  			}
>> -- =

>> 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 Thu Feb 14 15:02:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60KP-0008Ug-UA; Thu, 14 Feb 2013 15:02:25 +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 1U60KP-0008UT-2n
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:02:25 +0000
Received: from [85.158.139.211:36336] by server-12.bemta-5.messagelabs.com id
	D1/80-20195-08CFC115; Thu, 14 Feb 2013 15:02:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360854143!22505465!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13857 invoked from network); 14 Feb 2013 15:02:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:02:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1465633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:02:23 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 14 Feb 2013 15:02:23 +0000
Message-ID: <511CFC93.9070205@citrix.com>
Date: Thu, 14 Feb 2013 16:02:43 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
	<20130214132318.GC2506@phenom.dumpdata.com>
In-Reply-To: <20130214132318.GC2506@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 14/02/13 14:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 14, 2013 at 11:12:09AM +0100, Roger Pau Monne wrote:
>> With current persistent grants implementation we are not freeing the
>> persistent grants after we disconnect the device. Since grant map
> =

> Can you explain this in more details please? Isn't gnttab_set_unmap_op
> in free_persistent_gnts doing the right job of putting in the right
> mfn in? And then we could free the page?

No, after gnttab_unmap_refs the page still points to the grant frame
mfn. All the users of grant frames either have an internal buffer of
pages that are reused (like blkback), or use balloon pages (like gntdev).

I could probably modify gnttab_map to store the mfn and set it back at
gnttab_unmap, but that will surely require more work than this simple fix.

> =

> =

>> operations change the mfn of the allocated page, and we can no longer
>> pass it to __free_page without setting the mfn to a sane value, use
>> balloon grant pages instead, as the gntdev device does.
> =

> =

> Wow. I did not realize that we leaving such a huge memory leak behind!
> But I guess that was never an issue as we would recycle those persistent
> grants to other domains.

No, we didn't recycle them AFAIK, we allocated them using alloc_page,
passed them to gnttab_map, used them, and when closing the backend we
only unmapped them, but they where never freed.

>>
>> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
>> Cc: xen-devel@lists.xen.org
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  drivers/block/xen-blkback/blkback.c |    6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blk=
back/blkback.c
>> index c46824f..e6c2f6a 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -46,6 +46,7 @@
>>  #include <xen/xen.h>
>>  #include <asm/xen/hypervisor.h>
>>  #include <asm/xen/hypercall.h>
>> +#include <xen/balloon.h>
>>  #include "common.h"
>>  =

>>  /*
>> @@ -239,6 +240,7 @@ static void free_persistent_gnts(struct rb_root *roo=
t, unsigned int num)
>>  			ret =3D gnttab_unmap_refs(unmap, NULL, pages,
>>  				segs_to_unmap);
>>  			BUG_ON(ret);
>> +			free_xenballooned_pages(segs_to_unmap, pages);
>>  			segs_to_unmap =3D 0;
>>  		}
>>  =

>> @@ -527,8 +529,8 @@ static int xen_blkbk_map(struct blkif_request *req,
>>  				GFP_KERNEL);
>>  			if (!persistent_gnt)
>>  				return -ENOMEM;
>> -			persistent_gnt->page =3D alloc_page(GFP_KERNEL);
>> -			if (!persistent_gnt->page) {
>> +			if (alloc_xenballooned_pages(1, &persistent_gnt->page,
>> +			    false)) {
>>  				kfree(persistent_gnt);
>>  				return -ENOMEM;
>>  			}
>> -- =

>> 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 Thu Feb 14 15:03:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:03: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 1U60L9-00007X-Cq; Thu, 14 Feb 2013 15:03: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 1U60L7-00007H-HW
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:03:09 +0000
Received: from [85.158.143.35:17834] by server-3.bemta-4.messagelabs.com id
	1C/AD-08920-CACFC115; Thu, 14 Feb 2013 15:03:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360854188!11654408!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 14 Feb 2013 15:03:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1465674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:03: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.297.1;
	Thu, 14 Feb 2013 15:03:08 +0000
Message-ID: <1360854186.20449.424.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:03:06 +0000
In-Reply-To: <1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: text/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, 2013-02-14 at 14:16 +0000, Ian Campbell wrote:
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..c8af7a1 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -17,11 +17,15 @@ header = {};
>  footer = {};
>  
>  #arm
> -inttypes["arm"] = {
> +inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
>  };
> +header["x86_32"] = """
> +#define __arm__ARM32 1

As well as s/x86_32/arm32/ this should actually be "__arm___ARM32" too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:03:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:03: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 1U60L9-00007X-Cq; Thu, 14 Feb 2013 15:03: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 1U60L7-00007H-HW
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:03:09 +0000
Received: from [85.158.143.35:17834] by server-3.bemta-4.messagelabs.com id
	1C/AD-08920-CACFC115; Thu, 14 Feb 2013 15:03:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360854188!11654408!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 14 Feb 2013 15:03:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1465674"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:03: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.297.1;
	Thu, 14 Feb 2013 15:03:08 +0000
Message-ID: <1360854186.20449.424.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:03:06 +0000
In-Reply-To: <1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: text/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, 2013-02-14 at 14:16 +0000, Ian Campbell wrote:
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..c8af7a1 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -17,11 +17,15 @@ header = {};
>  footer = {};
>  
>  #arm
> -inttypes["arm"] = {
> +inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
>  };
> +header["x86_32"] = """
> +#define __arm__ARM32 1

As well as s/x86_32/arm32/ this should actually be "__arm___ARM32" too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:09:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:09: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 1U60R5-0000Vu-8a; Thu, 14 Feb 2013 15:09:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sander.bogaert@elis.ugent.be>) id 1U60R2-0000Vo-U5
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:09:17 +0000
Received: from [85.158.139.83:57343] by server-2.bemta-5.messagelabs.com id
	48/67-16911-C1EFC115; Thu, 14 Feb 2013 15:09:16 +0000
X-Env-Sender: sander.bogaert@elis.ugent.be
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360854555!27887877!1
X-Originating-IP: [157.193.49.127]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU3LjE5My40OS4xMjcgPT4gMTY0NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19638 invoked from network); 14 Feb 2013 15:09:15 -0000
Received: from smtp3.ugent.be (HELO smtp3.ugent.be) (157.193.49.127)
	by server-12.tower-182.messagelabs.com with SMTP;
	14 Feb 2013 15:09:15 -0000
Received: from localhost (mcheck2.ugent.be [157.193.49.249])
	by smtp3.ugent.be (Postfix) with ESMTP id A9FB4C2D6
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:11 +0100 (CET)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.ugent.be ([157.193.49.127])
	by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new,
	port 10024) with ESMTP id Gj639IzwLg3V for <xen-devel@lists.xen.org>;
	Thu, 14 Feb 2013 16:09:11 +0100 (CET)
Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48])
	by smtp3.ugent.be (Postfix) with ESMTP id 3BA09C2B8
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:11 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mail.elis.ugent.be (Postfix) with ESMTP id 1D26CAA30043
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at elis.ugent.be
Received: from mail.elis.ugent.be ([127.0.0.1])
	by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vuiH+rTTiTSh for <xen-devel@lists.xen.org>;
	Thu, 14 Feb 2013 16:09:05 +0100 (CET)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com
	[209.85.214.182])
	by mail.elis.ugent.be (Postfix) with ESMTP id ABB7B918C60
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:04 +0100 (CET)
Received: by mail-ob0-f182.google.com with SMTP id va7so2532222obc.13
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 07:09:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.13.73 with SMTP id f9mr19296000oec.131.1360854542919;
	Thu, 14 Feb 2013 07:09:02 -0800 (PST)
Received: by 10.60.77.39 with HTTP; Thu, 14 Feb 2013 07:09:02 -0800 (PST)
Date: Thu, 14 Feb 2013 16:09:02 +0100
Message-ID: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
From: Sander Bogaert <sander.bogaert@elis.ugent.be>
To: xen-devel@lists.xen.org
X-Miltered: at jchkm1 with ID 511CFE17.002 by Joe's j-chkmail
	(http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 511CFE17.002 from
	mail.elis.UGent.be/mail.elis.UGent.be/157.193.206.48/mail.elis.ugent.be/<sander.bogaert@elis.ugent.be>
X-j-chkmail-Score: MSGID : 511CFE17.002 on smtp3.ugent.be : j-chkmail score :
	. : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Subject: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2668291069281158395=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2668291069281158395==
Content-Type: multipart/alternative; boundary=e89a8fb202769f27be04d5b0a3a3

--e89a8fb202769f27be04d5b0a3a3
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm trying to get Xen working on the Arndale Board using these
instructions:
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale

When trying to build the Linux kernel from Linaro,
http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
(
configured as specified on the Xen wiki page ) I run into the following
error while compiling:

*drivers/xen/xenbus/xenbus_client.c: In function
'xenbus_map_ring_valloc_hvm':*
*drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of
function 'page_to_section' [-Werror=implicit-function-declaration]*
*cc1: some warnings being treated as errors*
*make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*

I was wondering if anyone else ran into this and if so how best to solve it.
Booting Xen on the board hangs on "Turning on paging", is this related to
not having a dom0?
*...*
*Startinrrrrrrrrrrrrrrrr- UART enabled -*
*- CPU 00000000 booting -*
*- Started in Hyp mode -*
*- Zero BSS -*
*- Setting up control registers -*
*- Turning on paging -*
*
*
Thanks,
Sander

--e89a8fb202769f27be04d5b0a3a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>I&#39;m trying to get Xen wor=
king on the Arndale Board using these instructions:=A0<a href=3D"http://wik=
i.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale">http://wik=
i.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale</a></div>
<div style><br></div><div style>When trying to build the Linux kernel from =
Linaro,=A0<a href=3D"http://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linu=
x_stable.git;a=3Dshortlog;h=3Drefs/heads/lue_arndale_3.7">http://git.linaro=
.org/gitweb?p=3Dpeople/ronynandy/linux_stable.git;a=3Dshortlog;h=3Drefs/hea=
ds/lue_arndale_3.7</a>=A0( configured as specified on the Xen wiki page ) I=
 run into the following error while compiling:</div>
<div style><br></div><div style><div><i>drivers/xen/xenbus/xenbus_client.c:=
 In function &#39;xenbus_map_ring_valloc_hvm&#39;:</i></div><div><i>drivers=
/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of function =
&#39;page_to_section&#39; [-Werror=3Dimplicit-function-declaration]</i></di=
v>
<div><i>cc1: some warnings being treated as errors</i></div><div><i>make[3]=
: *** [drivers/xen/xenbus/xenbus_client.o] Error 1</i></div><div><br></div>=
<div style>I was wondering if anyone else ran into this and if so how best =
to solve it.</div>
<div style>Booting Xen on the board hangs on &quot;Turning on paging&quot;,=
 is this related to not having a dom0?<br></div><div style><i>...</i></div>=
<div style><div><i>Startinrrrrrrrrrrrrrrrr- UART enabled -</i></div><div>
<i>- CPU 00000000 booting -</i></div><div><i>- Started in Hyp mode -</i></d=
iv><div><i>- Zero BSS -</i></div><div><i>- Setting up control registers -</=
i></div><div><i>- Turning on paging -</i></div><div><i><br></i></div><div s=
tyle>
Thanks,</div><div style>Sander</div></div></div></div>

--e89a8fb202769f27be04d5b0a3a3--


--===============2668291069281158395==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2668291069281158395==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 15:09:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:09: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 1U60R5-0000Vu-8a; Thu, 14 Feb 2013 15:09:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sander.bogaert@elis.ugent.be>) id 1U60R2-0000Vo-U5
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:09:17 +0000
Received: from [85.158.139.83:57343] by server-2.bemta-5.messagelabs.com id
	48/67-16911-C1EFC115; Thu, 14 Feb 2013 15:09:16 +0000
X-Env-Sender: sander.bogaert@elis.ugent.be
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360854555!27887877!1
X-Originating-IP: [157.193.49.127]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU3LjE5My40OS4xMjcgPT4gMTY0NDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19638 invoked from network); 14 Feb 2013 15:09:15 -0000
Received: from smtp3.ugent.be (HELO smtp3.ugent.be) (157.193.49.127)
	by server-12.tower-182.messagelabs.com with SMTP;
	14 Feb 2013 15:09:15 -0000
Received: from localhost (mcheck2.ugent.be [157.193.49.249])
	by smtp3.ugent.be (Postfix) with ESMTP id A9FB4C2D6
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:11 +0100 (CET)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.ugent.be ([157.193.49.127])
	by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new,
	port 10024) with ESMTP id Gj639IzwLg3V for <xen-devel@lists.xen.org>;
	Thu, 14 Feb 2013 16:09:11 +0100 (CET)
Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48])
	by smtp3.ugent.be (Postfix) with ESMTP id 3BA09C2B8
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:11 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mail.elis.ugent.be (Postfix) with ESMTP id 1D26CAA30043
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at elis.ugent.be
Received: from mail.elis.ugent.be ([127.0.0.1])
	by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vuiH+rTTiTSh for <xen-devel@lists.xen.org>;
	Thu, 14 Feb 2013 16:09:05 +0100 (CET)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com
	[209.85.214.182])
	by mail.elis.ugent.be (Postfix) with ESMTP id ABB7B918C60
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 16:09:04 +0100 (CET)
Received: by mail-ob0-f182.google.com with SMTP id va7so2532222obc.13
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 07:09:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.13.73 with SMTP id f9mr19296000oec.131.1360854542919;
	Thu, 14 Feb 2013 07:09:02 -0800 (PST)
Received: by 10.60.77.39 with HTTP; Thu, 14 Feb 2013 07:09:02 -0800 (PST)
Date: Thu, 14 Feb 2013 16:09:02 +0100
Message-ID: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
From: Sander Bogaert <sander.bogaert@elis.ugent.be>
To: xen-devel@lists.xen.org
X-Miltered: at jchkm1 with ID 511CFE17.002 by Joe's j-chkmail
	(http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 511CFE17.002 from
	mail.elis.UGent.be/mail.elis.UGent.be/157.193.206.48/mail.elis.ugent.be/<sander.bogaert@elis.ugent.be>
X-j-chkmail-Score: MSGID : 511CFE17.002 on smtp3.ugent.be : j-chkmail score :
	. : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Subject: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2668291069281158395=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2668291069281158395==
Content-Type: multipart/alternative; boundary=e89a8fb202769f27be04d5b0a3a3

--e89a8fb202769f27be04d5b0a3a3
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm trying to get Xen working on the Arndale Board using these
instructions:
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale

When trying to build the Linux kernel from Linaro,
http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
(
configured as specified on the Xen wiki page ) I run into the following
error while compiling:

*drivers/xen/xenbus/xenbus_client.c: In function
'xenbus_map_ring_valloc_hvm':*
*drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of
function 'page_to_section' [-Werror=implicit-function-declaration]*
*cc1: some warnings being treated as errors*
*make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*

I was wondering if anyone else ran into this and if so how best to solve it.
Booting Xen on the board hangs on "Turning on paging", is this related to
not having a dom0?
*...*
*Startinrrrrrrrrrrrrrrrr- UART enabled -*
*- CPU 00000000 booting -*
*- Started in Hyp mode -*
*- Zero BSS -*
*- Setting up control registers -*
*- Turning on paging -*
*
*
Thanks,
Sander

--e89a8fb202769f27be04d5b0a3a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>I&#39;m trying to get Xen wor=
king on the Arndale Board using these instructions:=A0<a href=3D"http://wik=
i.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale">http://wik=
i.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale</a></div>
<div style><br></div><div style>When trying to build the Linux kernel from =
Linaro,=A0<a href=3D"http://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linu=
x_stable.git;a=3Dshortlog;h=3Drefs/heads/lue_arndale_3.7">http://git.linaro=
.org/gitweb?p=3Dpeople/ronynandy/linux_stable.git;a=3Dshortlog;h=3Drefs/hea=
ds/lue_arndale_3.7</a>=A0( configured as specified on the Xen wiki page ) I=
 run into the following error while compiling:</div>
<div style><br></div><div style><div><i>drivers/xen/xenbus/xenbus_client.c:=
 In function &#39;xenbus_map_ring_valloc_hvm&#39;:</i></div><div><i>drivers=
/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of function =
&#39;page_to_section&#39; [-Werror=3Dimplicit-function-declaration]</i></di=
v>
<div><i>cc1: some warnings being treated as errors</i></div><div><i>make[3]=
: *** [drivers/xen/xenbus/xenbus_client.o] Error 1</i></div><div><br></div>=
<div style>I was wondering if anyone else ran into this and if so how best =
to solve it.</div>
<div style>Booting Xen on the board hangs on &quot;Turning on paging&quot;,=
 is this related to not having a dom0?<br></div><div style><i>...</i></div>=
<div style><div><i>Startinrrrrrrrrrrrrrrrr- UART enabled -</i></div><div>
<i>- CPU 00000000 booting -</i></div><div><i>- Started in Hyp mode -</i></d=
iv><div><i>- Zero BSS -</i></div><div><i>- Setting up control registers -</=
i></div><div><i>- Turning on paging -</i></div><div><i><br></i></div><div s=
tyle>
Thanks,</div><div style>Sander</div></div></div></div>

--e89a8fb202769f27be04d5b0a3a3--


--===============2668291069281158395==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2668291069281158395==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 15:09:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:09: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 1U60RW-0000Xb-MU; Thu, 14 Feb 2013 15:09:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>) id 1U60RV-0000XM-1w
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:09:45 +0000
Received: from [85.158.143.35:52891] by server-1.bemta-4.messagelabs.com id
	4E/72-08839-83EFC115; Thu, 14 Feb 2013 15:09:44 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360854579!10120787!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11885 invoked from network); 14 Feb 2013 15:09:39 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 15:09:39 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U60RN-00014p-Ll; Thu, 14 Feb 2013 16:09:37 +0100
Message-ID: <511CFE2F.2050002@hosteurope.de>
Date: Thu, 14 Feb 2013 16:09:35 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1360173877-12696-3-git-send-email-roger.pau@citrix.com>
X-Enigmail-Version: 1.5
Cc: George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4113862882787836984=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4113862882787836984==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2NPRXEGEQBXUDSORNFGHH"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2NPRXEGEQBXUDSORNFGHH
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Roger,


after applying patch v2 1/4 and 2/4 (are there missing some?)
to git checkout c23ea051ccee613e668b2a87817d49a28215ac8b of
git://xenbits.xen.org/xen.git xen

I get the following error(s) during compiling with 'make tools':

In file included from libxl.h:355,
                 from xl_cmdtable.c:17:
_libxl_types.h:437: error: duplicate member =E2=80=98gatewaydev=E2=80=99
make[3]: *** [xl_cmdtable.o] Error 1


On 06.02.2013 19:04, Roger Pau Monne wrote:
> This adds a new global option in the xl configuration file called
> "vif.default.gatewaydev", that is used to specify the default
> gatewaydev to use when none is passed in the vif specification.
>=20

Thanks and best regards,
Ulf


------enig2NPRXEGEQBXUDSORNFGHH
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEc/i8ACgkQhHSVerqjg05W3ACfQqX3FEJKF4qO2L0EHTG/cfeM
muYAnixnBvDbbIhzC9ztHKxfA3i1s/Y8
=b3qt
-----END PGP SIGNATURE-----

------enig2NPRXEGEQBXUDSORNFGHH--


--===============4113862882787836984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4113862882787836984==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 15:09:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:09: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 1U60RW-0000Xb-MU; Thu, 14 Feb 2013 15:09:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>) id 1U60RV-0000XM-1w
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:09:45 +0000
Received: from [85.158.143.35:52891] by server-1.bemta-4.messagelabs.com id
	4E/72-08839-83EFC115; Thu, 14 Feb 2013 15:09:44 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360854579!10120787!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11885 invoked from network); 14 Feb 2013 15:09:39 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 15:09:39 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U60RN-00014p-Ll; Thu, 14 Feb 2013 16:09:37 +0100
Message-ID: <511CFE2F.2050002@hosteurope.de>
Date: Thu, 14 Feb 2013 16:09:35 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Roger Pau Monne <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1360173877-12696-3-git-send-email-roger.pau@citrix.com>
X-Enigmail-Version: 1.5
Cc: George Dunlap <george.dunlap@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4113862882787836984=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4113862882787836984==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2NPRXEGEQBXUDSORNFGHH"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2NPRXEGEQBXUDSORNFGHH
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Roger,


after applying patch v2 1/4 and 2/4 (are there missing some?)
to git checkout c23ea051ccee613e668b2a87817d49a28215ac8b of
git://xenbits.xen.org/xen.git xen

I get the following error(s) during compiling with 'make tools':

In file included from libxl.h:355,
                 from xl_cmdtable.c:17:
_libxl_types.h:437: error: duplicate member =E2=80=98gatewaydev=E2=80=99
make[3]: *** [xl_cmdtable.o] Error 1


On 06.02.2013 19:04, Roger Pau Monne wrote:
> This adds a new global option in the xl configuration file called
> "vif.default.gatewaydev", that is used to specify the default
> gatewaydev to use when none is passed in the vif specification.
>=20

Thanks and best regards,
Ulf


------enig2NPRXEGEQBXUDSORNFGHH
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEc/i8ACgkQhHSVerqjg05W3ACfQqX3FEJKF4qO2L0EHTG/cfeM
muYAnixnBvDbbIhzC9ztHKxfA3i1s/Y8
=b3qt
-----END PGP SIGNATURE-----

------enig2NPRXEGEQBXUDSORNFGHH--


--===============4113862882787836984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4113862882787836984==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 15:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:10: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 1U60Rq-0000Zx-3o; Thu, 14 Feb 2013 15:10: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 1U60Ro-0000Zc-Be
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:10:04 +0000
Received: from [85.158.139.211:49857] by server-3.bemta-5.messagelabs.com id
	E8/26-07037-B4EFC115; Thu, 14 Feb 2013 15:10:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360854603!19777326!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30910 invoked from network); 14 Feb 2013 15:10:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:10:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1466070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:10: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.297.1;
	Thu, 14 Feb 2013 15:10:02 +0000
Message-ID: <1360854601.20449.425.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 15:10:01 +0000
In-Reply-To: <20130214145917.GC83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
	<20130214145917.GC83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 32/45] xen: arm: show_registers() support
 for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:59 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956598), Ian Campbell wrote:
> > -static void _show_registers(struct cpu_user_regs *regs,
> > -                            struct reg_ctxt *ctxt,
> > -                            int guest_mode)
> > +
> > +static void _show_registers_32(struct cpu_user_regs *regs,
> 
> Can we drop the _extraneous _underscore while we're here?

yes.
> 
> >      {
> > -        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
> > +        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
> > +        printk("  TCR_EL1: %08"PRIx32"\n",ctxt->tcr);
> 
> Missing space  ------------------------------^

ack.

> 
> > +#ifdef CONFIG_ARM_32
> >      printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
> >      printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
> >      printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
> >      printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
> >      printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
> >      printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
> > +    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
> >      printk("\n");
> >  
> >      printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
> >      printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
> >      printk("\n");
> > +#else
> > +    reg = READ_SYSREG64(TTBR0_EL2); printk("TTBR0_EL2: %"PRIx64"\n", reg);
> 
> Any reason this (&c) isn't printk("...", READ_SYSREG64(...)) like the
> arm32 ones?

hangover from a previous MACRO(REGISTER, variable) implementation. Will
fix.

> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:10: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 1U60Rq-0000Zx-3o; Thu, 14 Feb 2013 15:10: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 1U60Ro-0000Zc-Be
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:10:04 +0000
Received: from [85.158.139.211:49857] by server-3.bemta-5.messagelabs.com id
	E8/26-07037-B4EFC115; Thu, 14 Feb 2013 15:10:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360854603!19777326!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30910 invoked from network); 14 Feb 2013 15:10:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:10:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1466070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:10: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.297.1;
	Thu, 14 Feb 2013 15:10:02 +0000
Message-ID: <1360854601.20449.425.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 15:10:01 +0000
In-Reply-To: <20130214145917.GC83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
	<20130214145917.GC83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 32/45] xen: arm: show_registers() support
 for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 14:59 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956598), Ian Campbell wrote:
> > -static void _show_registers(struct cpu_user_regs *regs,
> > -                            struct reg_ctxt *ctxt,
> > -                            int guest_mode)
> > +
> > +static void _show_registers_32(struct cpu_user_regs *regs,
> 
> Can we drop the _extraneous _underscore while we're here?

yes.
> 
> >      {
> > -        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
> > +        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
> > +        printk("  TCR_EL1: %08"PRIx32"\n",ctxt->tcr);
> 
> Missing space  ------------------------------^

ack.

> 
> > +#ifdef CONFIG_ARM_32
> >      printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
> >      printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
> >      printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
> >      printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
> >      printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
> >      printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
> > +    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
> >      printk("\n");
> >  
> >      printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
> >      printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
> >      printk("\n");
> > +#else
> > +    reg = READ_SYSREG64(TTBR0_EL2); printk("TTBR0_EL2: %"PRIx64"\n", reg);
> 
> Any reason this (&c) isn't printk("...", READ_SYSREG64(...)) like the
> arm32 ones?

hangover from a previous MACRO(REGISTER, variable) implementation. Will
fix.

> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:15:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60Wt-00013d-28; Thu, 14 Feb 2013 15:15:19 +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 1U60Wr-00013R-NE
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 15:15:17 +0000
Received: from [85.158.143.99:3288] by server-2.bemta-4.messagelabs.com id
	BB/70-01597-38FFC115; Thu, 14 Feb 2013 15:15:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360854913!27574036!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDA0Njk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDA0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19368 invoked from network); 14 Feb 2013 15:15:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 15:15:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pFTU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-027.pools.arcor-ip.net [84.57.80.27])
	by smtp.strato.de (joses mo18) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 503fcep1EESIQ0 ;
	Thu, 14 Feb 2013 16:15:10 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id CB0701884C; Thu, 14 Feb 2013 16:15:09 +0100 (CET)
Date: Thu, 14 Feb 2013 16:15:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130214151509.GA31892@aepfle.de>
References: <20130213181103.GC20042@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213181103.GC20042@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, Konrad Rzeszutek Wilk wrote:

> Any thoughts of what might be wrong?

After a quick browsing of the involved code I dont see anything obvious.
Since kexec for PVonHVM does not work anyway even with this patch,
please revert 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f and
a7be94ac8d69c037d08f0fd94b45a593f1d45176 to avoid the regression.

Please also send the .config for the guest, and say if dom0 is 32bit as
well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:15:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60Wt-00013d-28; Thu, 14 Feb 2013 15:15:19 +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 1U60Wr-00013R-NE
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 15:15:17 +0000
Received: from [85.158.143.99:3288] by server-2.bemta-4.messagelabs.com id
	BB/70-01597-38FFC115; Thu, 14 Feb 2013 15:15:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360854913!27574036!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDA0Njk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDA0Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19368 invoked from network); 14 Feb 2013 15:15:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 15:15:14 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pFTU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-027.pools.arcor-ip.net [84.57.80.27])
	by smtp.strato.de (joses mo18) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 503fcep1EESIQ0 ;
	Thu, 14 Feb 2013 16:15:10 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id CB0701884C; Thu, 14 Feb 2013 16:15:09 +0100 (CET)
Date: Thu, 14 Feb 2013 16:15:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130214151509.GA31892@aepfle.de>
References: <20130213181103.GC20042@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130213181103.GC20042@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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 Wed, Feb 13, Konrad Rzeszutek Wilk wrote:

> Any thoughts of what might be wrong?

After a quick browsing of the involved code I dont see anything obvious.
Since kexec for PVonHVM does not work anyway even with this patch,
please revert 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f and
a7be94ac8d69c037d08f0fd94b45a593f1d45176 to avoid the regression.

Please also send the .config for the guest, and say if dom0 is 32bit as
well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:18:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:18: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 1U60a0-0001Fo-Lw; Thu, 14 Feb 2013 15:18: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 1U60Zz-0001Fh-TL
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:18:32 +0000
Received: from [85.158.143.35:32674] by server-3.bemta-4.messagelabs.com id
	A1/36-08920-7400D115; Thu, 14 Feb 2013 15:18:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1360855109!4609424!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31745 invoked from network); 14 Feb 2013 15:18:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:18:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60Zw-000Mpq-LW; Thu, 14 Feb 2013 15:18:28 +0000
Date: Thu, 14 Feb 2013 15:18:28 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214151828.GE83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-33-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-33-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 33/45] xen: arm: make dom0 builder work on
	64-bit 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

At 15:56 +0000 on 23 Jan (1358956599), Ian Campbell wrote:
> @@ -299,6 +299,12 @@ int construct_dom0(struct domain *d)
>      if ( rc < 0 )
>          return rc;
>  
> +#ifdef CONFIG_ARM_64
> +    printk(" Xen kernel: 64-bit, AArch64, AArch32\n");
> +#else
> +    printk(" Xen kernel: 32-bit, AArch32\n");
> +#endif

A debugging printk left over?  It seems misleading, since dom0 is
AArch32 in any case, and it's got a leading space.

Otherwise, 

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 Thu Feb 14 15:18:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:18: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 1U60a0-0001Fo-Lw; Thu, 14 Feb 2013 15:18: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 1U60Zz-0001Fh-TL
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:18:32 +0000
Received: from [85.158.143.35:32674] by server-3.bemta-4.messagelabs.com id
	A1/36-08920-7400D115; Thu, 14 Feb 2013 15:18:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1360855109!4609424!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31745 invoked from network); 14 Feb 2013 15:18:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:18:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60Zw-000Mpq-LW; Thu, 14 Feb 2013 15:18:28 +0000
Date: Thu, 14 Feb 2013 15:18:28 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214151828.GE83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-33-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-33-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 33/45] xen: arm: make dom0 builder work on
	64-bit 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

At 15:56 +0000 on 23 Jan (1358956599), Ian Campbell wrote:
> @@ -299,6 +299,12 @@ int construct_dom0(struct domain *d)
>      if ( rc < 0 )
>          return rc;
>  
> +#ifdef CONFIG_ARM_64
> +    printk(" Xen kernel: 64-bit, AArch64, AArch32\n");
> +#else
> +    printk(" Xen kernel: 32-bit, AArch32\n");
> +#endif

A debugging printk left over?  It seems misleading, since dom0 is
AArch32 in any case, and it's got a leading space.

Otherwise, 

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 Thu Feb 14 15:19:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60b6-0001KM-4N; Thu, 14 Feb 2013 15:19:40 +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 1U60b4-0001KA-80
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:19:38 +0000
Received: from [85.158.139.83:7878] by server-8.bemta-5.messagelabs.com id
	FF/CA-19075-9800D115; Thu, 14 Feb 2013 15:19:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360855176!23675508!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27940 invoked from network); 14 Feb 2013 15:19:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:19:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 15:20:14 +0000
Message-Id: <511D0ED202000078000BE5BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 15:20:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
	<1360853210.20449.414.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360853210.20449.414.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 15:46, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-14 at 14:43 +0000, Jan Beulich wrote:
>> >>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > Most of this struct is PV MMU specific and it is not used on ARM at all.
>> 
>> I'm not convinced this is the right move.
>> 
>> > --- a/xen/include/public/xen.h
>> > +++ b/xen/include/public/xen.h
>> > @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
>> >   *     extended by an extra 4MB to ensure this.
>> >   */
>> >  
>> > -#define MAX_GUEST_CMDLINE 1024
>> > -struct start_info {
>> > -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    
> */
>> > -    char magic[32];             /* "xen-<version>-<platform>".            */
>> > -    unsigned long nr_pages;     /* Total pages allocated to this domain.  
> */
>> > -    unsigned long shared_info;  /* MACHINE address of shared info struct. 
> */
>> > -    uint32_t flags;             /* SIF_xxx flags.                         
> */
>> > -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    
> */
>> > -    uint32_t store_evtchn;      /* Event channel for store communication. 
> */
>> > -    union {
>> > -        struct {
>> > -            xen_pfn_t mfn;      /* MACHINE page number of console page.   
> */
>> > -            uint32_t  evtchn;   /* Event channel for console page.        
> */
>> > -        } domU;
>> > -        struct {
>> > -            uint32_t info_off;  /* Offset of console_info struct.         
> */
>> > -            uint32_t info_size; /* Size of console_info struct from 
> start.*/
>> > -        } dom0;
>> > -    } console;
>> 
>> What is PV MMU related up to here?
> 
> Hrm, perhaps categorising this as PV MMU was a mistake on my part.
> 
> These are all unused on ARM in terms of the hypervisor ABI since it uses
> HVM like mechanisms for those which are appropriate and doesn't use a
> bunch of the others at all.

But nothing here makes this structure x86 specific, so I'd really like
to keep it that way. If ARM doesn't use the structure at all, then
I don't see the point in removing it from the common headers. If
part of it (the flags come to mind) are being used by ARM, let's
find a reasonable abstraction so that ARM doesn't need to carry
useless baggage (e.g. a XEN_ARCH_HVM_ONLY #define).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:19:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60b6-0001KM-4N; Thu, 14 Feb 2013 15:19:40 +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 1U60b4-0001KA-80
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:19:38 +0000
Received: from [85.158.139.83:7878] by server-8.bemta-5.messagelabs.com id
	FF/CA-19075-9800D115; Thu, 14 Feb 2013 15:19:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360855176!23675508!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27940 invoked from network); 14 Feb 2013 15:19:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:19:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 15:20:14 +0000
Message-Id: <511D0ED202000078000BE5BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 15:20:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
	<1360853210.20449.414.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360853210.20449.414.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 15:46, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-14 at 14:43 +0000, Jan Beulich wrote:
>> >>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > Most of this struct is PV MMU specific and it is not used on ARM at all.
>> 
>> I'm not convinced this is the right move.
>> 
>> > --- a/xen/include/public/xen.h
>> > +++ b/xen/include/public/xen.h
>> > @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
>> >   *     extended by an extra 4MB to ensure this.
>> >   */
>> >  
>> > -#define MAX_GUEST_CMDLINE 1024
>> > -struct start_info {
>> > -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    
> */
>> > -    char magic[32];             /* "xen-<version>-<platform>".            */
>> > -    unsigned long nr_pages;     /* Total pages allocated to this domain.  
> */
>> > -    unsigned long shared_info;  /* MACHINE address of shared info struct. 
> */
>> > -    uint32_t flags;             /* SIF_xxx flags.                         
> */
>> > -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    
> */
>> > -    uint32_t store_evtchn;      /* Event channel for store communication. 
> */
>> > -    union {
>> > -        struct {
>> > -            xen_pfn_t mfn;      /* MACHINE page number of console page.   
> */
>> > -            uint32_t  evtchn;   /* Event channel for console page.        
> */
>> > -        } domU;
>> > -        struct {
>> > -            uint32_t info_off;  /* Offset of console_info struct.         
> */
>> > -            uint32_t info_size; /* Size of console_info struct from 
> start.*/
>> > -        } dom0;
>> > -    } console;
>> 
>> What is PV MMU related up to here?
> 
> Hrm, perhaps categorising this as PV MMU was a mistake on my part.
> 
> These are all unused on ARM in terms of the hypervisor ABI since it uses
> HVM like mechanisms for those which are appropriate and doesn't use a
> bunch of the others at all.

But nothing here makes this structure x86 specific, so I'd really like
to keep it that way. If ARM doesn't use the structure at all, then
I don't see the point in removing it from the common headers. If
part of it (the flags come to mind) are being used by ARM, let's
find a reasonable abstraction so that ARM doesn't need to carry
useless baggage (e.g. a XEN_ARCH_HVM_ONLY #define).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:20:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60c5-0001QG-Ja; Thu, 14 Feb 2013 15:20:41 +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 1U60c3-0001Pz-MM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:20:39 +0000
Received: from [85.158.137.99:11253] by server-8.bemta-3.messagelabs.com id
	A4/04-25687-6C00D115; Thu, 14 Feb 2013 15:20:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360855237!16786197!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31554 invoked from network); 14 Feb 2013 15:20:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:20:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60c1-000Mqa-E7; Thu, 14 Feb 2013 15:20:37 +0000
Date: Thu, 14 Feb 2013 15:20:37 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152037.GF83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-34-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-34-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 34/45] xen: arm: gic: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956600), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:20:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60c5-0001QG-Ja; Thu, 14 Feb 2013 15:20:41 +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 1U60c3-0001Pz-MM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:20:39 +0000
Received: from [85.158.137.99:11253] by server-8.bemta-3.messagelabs.com id
	A4/04-25687-6C00D115; Thu, 14 Feb 2013 15:20:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-217.messagelabs.com!1360855237!16786197!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31554 invoked from network); 14 Feb 2013 15:20:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:20:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60c1-000Mqa-E7; Thu, 14 Feb 2013 15:20:37 +0000
Date: Thu, 14 Feb 2013 15:20:37 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152037.GF83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-34-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-34-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 34/45] xen: arm: gic: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956600), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:20:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60cA-0001Qn-0Z; Thu, 14 Feb 2013 15:20: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 1U60c9-0001Qe-G6
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:20:45 +0000
Received: from [85.158.143.35:39840] by server-1.bemta-4.messagelabs.com id
	7F/62-08839-CC00D115; Thu, 14 Feb 2013 15:20:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360855035!12377313!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2841 invoked from network); 14 Feb 2013 15:17:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:17:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1466378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:17:14 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 14 Feb 2013 15:17:13 +0000
Message-ID: <511D000C.9030908@citrix.com>
Date: Thu, 14 Feb 2013 16:17:32 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de>
In-Reply-To: <511CFE2F.2050002@hosteurope.de>
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTQvMDIvMTMgMTY6MDksIFVsZiBLcmV1dHpiZXJnIHdyb3RlOgo+IFJvZ2VyLAo+IAo+IAo+
IGFmdGVyIGFwcGx5aW5nIHBhdGNoIHYyIDEvNCBhbmQgMi80IChhcmUgdGhlcmUgbWlzc2luZyBz
b21lPykKCldlbGwsIHlvdSBtaWdodCB3YW50IHRvIHRyeSAzLzQgYW5kIDQvNCBhbHNvLCBidXQg
dGhleSBhcmUgbm90IG1hbmRhdG9yeS4KCj4gdG8gZ2l0IGNoZWNrb3V0IGMyM2VhMDUxY2NlZTYx
M2U2NjhiMmE4NzgxN2Q0OWEyODIxNWFjOGIgb2YKPiBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcveGVu
LmdpdCB4ZW4KPiAKPiBJIGdldCB0aGUgZm9sbG93aW5nIGVycm9yKHMpIGR1cmluZyBjb21waWxp
bmcgd2l0aCAnbWFrZSB0b29scyc6Cj4gCj4gSW4gZmlsZSBpbmNsdWRlZCBmcm9tIGxpYnhsLmg6
MzU1LAo+ICAgICAgICAgICAgICAgICAgZnJvbSB4bF9jbWR0YWJsZS5jOjE3Ogo+IF9saWJ4bF90
eXBlcy5oOjQzNzogZXJyb3I6IGR1cGxpY2F0ZSBtZW1iZXIg4oCYZ2F0ZXdheWRlduKAmQo+IG1h
a2VbM106ICoqKiBbeGxfY21kdGFibGUub10gRXJyb3IgMQoKQ291bGQgeW91IHRha2UgYSBsb29r
IGF0IHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbD8KCllvdSBzaG91bGQgaGF2ZSBzb21ldGhp
bmcgbGlrZSB0aGUgZm9sbG93aW5nIGNodW5rOgoKbGlieGxfZGV2aWNlX25pYyA9IFN0cnVjdCgi
ZGV2aWNlX25pYyIsIFsKICAgICgiYmFja2VuZF9kb21pZCIsIGxpYnhsX2RvbWlkKSwKICAgICgi
ZGV2aWQiLCBsaWJ4bF9kZXZpZCksCiAgICAoIm10dSIsIGludGVnZXIpLAogICAgKCJtb2RlbCIs
IHN0cmluZyksCiAgICAoIm1hYyIsIGxpYnhsX21hYyksCiAgICAoImlwIiwgc3RyaW5nKSwKICAg
ICgiYnJpZGdlIiwgc3RyaW5nKSwKICAgICgiaWZuYW1lIiwgc3RyaW5nKSwKICAgICgic2NyaXB0
Iiwgc3RyaW5nKSwKICAgICgibmljdHlwZSIsIGxpYnhsX25pY190eXBlKSwKICAgICgicmF0ZV9i
eXRlc19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAogICAgKCJyYXRlX2ludGVydmFsX3VzZWNzIiwg
dWludDMyKSwKICAgICgiZ2F0ZXdheWRldiIsIHN0cmluZyksCiAgICBdKQoKKFdpdGggb25seSBv
bmUgImdhdGV3YXlkZXYiKS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:20:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60cA-0001Qn-0Z; Thu, 14 Feb 2013 15:20: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 1U60c9-0001Qe-G6
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:20:45 +0000
Received: from [85.158.143.35:39840] by server-1.bemta-4.messagelabs.com id
	7F/62-08839-CC00D115; Thu, 14 Feb 2013 15:20:44 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360855035!12377313!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2841 invoked from network); 14 Feb 2013 15:17:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:17:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1466378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:17:14 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 14 Feb 2013 15:17:13 +0000
Message-ID: <511D000C.9030908@citrix.com>
Date: Thu, 14 Feb 2013 16:17:32 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de>
In-Reply-To: <511CFE2F.2050002@hosteurope.de>
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTQvMDIvMTMgMTY6MDksIFVsZiBLcmV1dHpiZXJnIHdyb3RlOgo+IFJvZ2VyLAo+IAo+IAo+
IGFmdGVyIGFwcGx5aW5nIHBhdGNoIHYyIDEvNCBhbmQgMi80IChhcmUgdGhlcmUgbWlzc2luZyBz
b21lPykKCldlbGwsIHlvdSBtaWdodCB3YW50IHRvIHRyeSAzLzQgYW5kIDQvNCBhbHNvLCBidXQg
dGhleSBhcmUgbm90IG1hbmRhdG9yeS4KCj4gdG8gZ2l0IGNoZWNrb3V0IGMyM2VhMDUxY2NlZTYx
M2U2NjhiMmE4NzgxN2Q0OWEyODIxNWFjOGIgb2YKPiBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcveGVu
LmdpdCB4ZW4KPiAKPiBJIGdldCB0aGUgZm9sbG93aW5nIGVycm9yKHMpIGR1cmluZyBjb21waWxp
bmcgd2l0aCAnbWFrZSB0b29scyc6Cj4gCj4gSW4gZmlsZSBpbmNsdWRlZCBmcm9tIGxpYnhsLmg6
MzU1LAo+ICAgICAgICAgICAgICAgICAgZnJvbSB4bF9jbWR0YWJsZS5jOjE3Ogo+IF9saWJ4bF90
eXBlcy5oOjQzNzogZXJyb3I6IGR1cGxpY2F0ZSBtZW1iZXIg4oCYZ2F0ZXdheWRlduKAmQo+IG1h
a2VbM106ICoqKiBbeGxfY21kdGFibGUub10gRXJyb3IgMQoKQ291bGQgeW91IHRha2UgYSBsb29r
IGF0IHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbD8KCllvdSBzaG91bGQgaGF2ZSBzb21ldGhp
bmcgbGlrZSB0aGUgZm9sbG93aW5nIGNodW5rOgoKbGlieGxfZGV2aWNlX25pYyA9IFN0cnVjdCgi
ZGV2aWNlX25pYyIsIFsKICAgICgiYmFja2VuZF9kb21pZCIsIGxpYnhsX2RvbWlkKSwKICAgICgi
ZGV2aWQiLCBsaWJ4bF9kZXZpZCksCiAgICAoIm10dSIsIGludGVnZXIpLAogICAgKCJtb2RlbCIs
IHN0cmluZyksCiAgICAoIm1hYyIsIGxpYnhsX21hYyksCiAgICAoImlwIiwgc3RyaW5nKSwKICAg
ICgiYnJpZGdlIiwgc3RyaW5nKSwKICAgICgiaWZuYW1lIiwgc3RyaW5nKSwKICAgICgic2NyaXB0
Iiwgc3RyaW5nKSwKICAgICgibmljdHlwZSIsIGxpYnhsX25pY190eXBlKSwKICAgICgicmF0ZV9i
eXRlc19wZXJfaW50ZXJ2YWwiLCB1aW50NjQpLAogICAgKCJyYXRlX2ludGVydmFsX3VzZWNzIiwg
dWludDMyKSwKICAgICgiZ2F0ZXdheWRldiIsIHN0cmluZyksCiAgICBdKQoKKFdpdGggb25seSBv
bmUgImdhdGV3YXlkZXYiKS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:22:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60df-0001kX-H8; Thu, 14 Feb 2013 15:22: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 1U60de-0001kM-Hy
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:22:18 +0000
Received: from [85.158.143.99:5313] by server-1.bemta-4.messagelabs.com id
	62/D4-08839-9210D115; Thu, 14 Feb 2013 15:22:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360855337!22270106!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16488 invoked from network); 14 Feb 2013 15:22:17 -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; 14 Feb 2013 15:22:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60dc-000MrR-Nv; Thu, 14 Feb 2013 15:22:16 +0000
Date: Thu, 14 Feb 2013 15:22:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152216.GG83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-35-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-35-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 35/45] xen: arm: time: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956601), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:22:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60df-0001kX-H8; Thu, 14 Feb 2013 15:22: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 1U60de-0001kM-Hy
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:22:18 +0000
Received: from [85.158.143.99:5313] by server-1.bemta-4.messagelabs.com id
	62/D4-08839-9210D115; Thu, 14 Feb 2013 15:22:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360855337!22270106!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16488 invoked from network); 14 Feb 2013 15:22:17 -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; 14 Feb 2013 15:22:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60dc-000MrR-Nv; Thu, 14 Feb 2013 15:22:16 +0000
Date: Thu, 14 Feb 2013 15:22:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152216.GG83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-35-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-35-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 35/45] xen: arm: time: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956601), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:22:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60dv-0001mj-UF; Thu, 14 Feb 2013 15:22:35 +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 1U60du-0001mN-Fa
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:22:34 +0000
Received: from [85.158.139.211:38650] by server-14.bemta-5.messagelabs.com id
	F1/5A-06967-9310D115; Thu, 14 Feb 2013 15:22:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360855352!22111098!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20124 invoked from network); 14 Feb 2013 15:22:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:22:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60ds-000Mri-G0; Thu, 14 Feb 2013 15:22:32 +0000
Date: Thu, 14 Feb 2013 15:22:32 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152232.GH83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-36-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-36-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 36/45] xen: arm: p2m: use 64-bit compatible
	registers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956602), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:22:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60dv-0001mj-UF; Thu, 14 Feb 2013 15:22:35 +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 1U60du-0001mN-Fa
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:22:34 +0000
Received: from [85.158.139.211:38650] by server-14.bemta-5.messagelabs.com id
	F1/5A-06967-9310D115; Thu, 14 Feb 2013 15:22:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360855352!22111098!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20124 invoked from network); 14 Feb 2013 15:22:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:22:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60ds-000Mri-G0; Thu, 14 Feb 2013 15:22:32 +0000
Date: Thu, 14 Feb 2013 15:22:32 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152232.GH83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-36-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-36-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 36/45] xen: arm: p2m: use 64-bit compatible
	registers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956602), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:25:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60gB-00025D-Gf; Thu, 14 Feb 2013 15:24: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 1U60gA-00024a-BC
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:24:54 +0000
Received: from [85.158.139.211:27205] by server-3.bemta-5.messagelabs.com id
	89/F2-07037-3C10D115; Thu, 14 Feb 2013 15:24:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360855490!22388652!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24750 invoked from network); 14 Feb 2013 15:24:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:24:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60g6-000MsK-Gf; Thu, 14 Feb 2013 15:24:50 +0000
Date: Thu, 14 Feb 2013 15:24:50 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152450.GI83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-37-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-37-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 37/45] xen: arm: Use 64-bit compatible
	registers in vtimer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956603), Ian Campbell wrote:
> Also, don't crash the host if we fail to emulate a vtimer access,
> just kill the guest.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:25:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60gB-00025D-Gf; Thu, 14 Feb 2013 15:24: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 1U60gA-00024a-BC
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:24:54 +0000
Received: from [85.158.139.211:27205] by server-3.bemta-5.messagelabs.com id
	89/F2-07037-3C10D115; Thu, 14 Feb 2013 15:24:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360855490!22388652!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24750 invoked from network); 14 Feb 2013 15:24:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:24:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60g6-000MsK-Gf; Thu, 14 Feb 2013 15:24:50 +0000
Date: Thu, 14 Feb 2013 15:24:50 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152450.GI83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-37-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-37-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 37/45] xen: arm: Use 64-bit compatible
	registers in vtimer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956603), Ian Campbell wrote:
> Also, don't crash the host if we fail to emulate a vtimer access,
> just kill the guest.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:27:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:27: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 1U60io-0002KU-53; Thu, 14 Feb 2013 15:27:38 +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 1U60im-0002KI-Ny
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:27:36 +0000
Received: from [85.158.139.211:27808] by server-5.bemta-5.messagelabs.com id
	66/75-11945-7620D115; Thu, 14 Feb 2013 15:27:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360855612!22389042!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5743 invoked from network); 14 Feb 2013 15:26:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:26:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60i4-000Msu-CO; Thu, 14 Feb 2013 15:26:52 +0000
Date: Thu, 14 Feb 2013 15:26:52 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152652.GJ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-38-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-38-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 38/45] xen: arm: select_user_reg support for
	64-bit 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

At 15:56 +0000 on 23 Jan (1358956604), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:27:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:27: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 1U60io-0002KU-53; Thu, 14 Feb 2013 15:27:38 +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 1U60im-0002KI-Ny
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:27:36 +0000
Received: from [85.158.139.211:27808] by server-5.bemta-5.messagelabs.com id
	66/75-11945-7620D115; Thu, 14 Feb 2013 15:27:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360855612!22389042!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5743 invoked from network); 14 Feb 2013 15:26:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:26:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60i4-000Msu-CO; Thu, 14 Feb 2013 15:26:52 +0000
Date: Thu, 14 Feb 2013 15:26:52 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152652.GJ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-38-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-38-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 38/45] xen: arm: select_user_reg support for
	64-bit 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

At 15:56 +0000 on 23 Jan (1358956604), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:29:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:29: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 1U60kL-0002Qm-Lw; Thu, 14 Feb 2013 15:29:13 +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 1U60kK-0002Qd-FU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:29:12 +0000
Received: from [85.158.143.99:23782] by server-3.bemta-4.messagelabs.com id
	80/54-08920-7C20D115; Thu, 14 Feb 2013 15:29:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360855750!27576669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26285 invoked from network); 14 Feb 2013 15:29:11 -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; 14 Feb 2013 15:29:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60kF-000MtM-IG; Thu, 14 Feb 2013 15:29:07 +0000
Date: Thu, 14 Feb 2013 15:29:07 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152907.GK83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-39-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-39-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 39/45] xen: arm: handle 32-bit guest CP
	register traps on 64-bit 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

At 15:56 +0000 on 23 Jan (1358956605), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:29:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:29: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 1U60kL-0002Qm-Lw; Thu, 14 Feb 2013 15:29:13 +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 1U60kK-0002Qd-FU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:29:12 +0000
Received: from [85.158.143.99:23782] by server-3.bemta-4.messagelabs.com id
	80/54-08920-7C20D115; Thu, 14 Feb 2013 15:29:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360855750!27576669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26285 invoked from network); 14 Feb 2013 15:29:11 -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; 14 Feb 2013 15:29:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60kF-000MtM-IG; Thu, 14 Feb 2013 15:29:07 +0000
Date: Thu, 14 Feb 2013 15:29:07 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152907.GK83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-39-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-39-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 39/45] xen: arm: handle 32-bit guest CP
	register traps on 64-bit 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

At 15:56 +0000 on 23 Jan (1358956605), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:29:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:29: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 1U60kY-0002SK-2R; Thu, 14 Feb 2013 15:29:26 +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 1U60kV-0002Ry-Nk
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:29:24 +0000
Received: from [85.158.138.51:29203] by server-8.bemta-3.messagelabs.com id
	6D/E1-25687-4C20D115; Thu, 14 Feb 2013 15:29:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360855702!27552301!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26954 invoked from network); 14 Feb 2013 15:28:23 -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; 14 Feb 2013 15:28:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 15:29:18 +0000
Message-Id: <511D10E102000078000BE5E2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 15:29:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
	<511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
In-Reply-To: <511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE7D7A6C1.2__="
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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>
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.

--=__PartE7D7A6C1.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 14.02.13 at 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 14.02.13 at 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
>>> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
>>>> I don't think this patch will fix his problems, which - as described
>>>> yesterday - I'm relatively certain result from the harsh action
>>>> netbk_fatal_tx_err() does.
>>>=20
>>> Yes, having this one only is not enough. It will need to either =
disable
>>> the vif timer or check vif->netbk !=3D NULL inside timer callback.
>>=20
>> I continue to be unclear what timer you refer to.
>>=20
>> If we keep the carrier-off in fatal_tx_err, then _all_
>> asynchronously callable interfaces need to check whether the
>> vif -> netbk association went away. But, especially in the
>> context of using tasklets instead of kthreads, I meanwhile
>> think that simply setting a flag (along with turning off the IRQ)
>> would be better (and keep the turning off of the carrier the way
>> it had been done before. The flag would basically need checking
>> anywhere we look at the shared ring (which ought to be very
>> few places), and perhaps should also cause xenvif_schedulable()
>> to return false.
>=20
> Or a "light" version of xenvif_down(), i.e. simply
>=20
> 	disable_irq(vif->irq);
> 	xen_netbk_deschedule_xenvif(vif);
>=20
> If I'm not mistaken, doing this instead of xenvif_carrier_off()
> could be all that's needed.

Like the below/attached (compile tested only so far).

Jan

netback: fix shutting down the ring if it contains garbage

Using rtnl_lock() in tasklet context is not permitted.

This undoes the part of 1219:5108c6901b30 that split off
xenvif_carrier_off() from netif_disconnect().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/netback/common.h
+++ b/drivers/xen/netback/common.h
@@ -78,6 +78,8 @@ typedef struct netif_st {
 	u8 can_queue:1;	/* can queue packets for receiver? */
 	u8 copying_receiver:1;	/* copy packets to receiver?       */
=20
+	u8 busted:1;
+
 	/* Allow netif_be_start_xmit() to peek ahead in the rx request =
ring. */
 	RING_IDX rx_req_cons_peek;
=20
@@ -195,7 +197,8 @@ int netif_map(netif_t *netif, unsigned l
 void netif_xenbus_init(void);
=20
 #define netif_schedulable(netif)				\
-	(netif_running((netif)->dev) && netback_carrier_ok(netif))
+	(likely(!(netif)->busted) &&				\
+	 netif_running((netif)->dev) &&	netback_carrier_ok(netif))
=20
 void netif_schedule_work(netif_t *netif);
 void netif_deschedule_work(netif_t *netif);
@@ -204,9 +207,6 @@ int netif_be_start_xmit(struct sk_buff *
 struct net_device_stats *netif_be_get_stats(struct net_device *dev);
 irqreturn_t netif_be_int(int irq, void *dev_id, struct pt_regs *regs);
=20
-/* Prevent the device from generating any further traffic. */
-void xenvif_carrier_off(netif_t *netif);
-
 static inline int netbk_can_queue(struct net_device *dev)
 {
 	netif_t *netif =3D netdev_priv(dev);
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -56,6 +56,7 @@ module_param_named(queue_length, netbk_q
=20
 static void __netif_up(netif_t *netif)
 {
+	netif->busted =3D 0;
 	enable_irq(netif->irq);
 	netif_schedule_work(netif);
 }
@@ -347,23 +348,19 @@ err_rx:
 	return err;
 }
=20
-void xenvif_carrier_off(netif_t *netif)
-{
-	rtnl_lock();
-	netback_carrier_off(netif);
-	netif_carrier_off(netif->dev); /* discard queued packets */
-	if (netif_running(netif->dev))
-		__netif_down(netif);
-	rtnl_unlock();
-	netif_put(netif);
-}
-
 void netif_disconnect(struct backend_info *be)
 {
 	netif_t *netif =3D be->netif;
=20
-	if (netback_carrier_ok(netif))
-		xenvif_carrier_off(netif);
+	if (netback_carrier_ok(netif)) {
+		rtnl_lock();
+		netback_carrier_off(netif);
+		netif_carrier_off(netif->dev); /* discard queued packets =
*/
+		if (netif_running(netif->dev))
+			__netif_down(netif);
+		rtnl_unlock();
+		netif_put(netif);
+	}
=20
 	atomic_dec(&netif->refcnt);
 	wait_event(netif->waiting_to_free, atomic_read(&netif->refcnt) =
=3D=3D 0);
--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -845,7 +845,7 @@ void netif_schedule_work(netif_t *netif)
 	RING_FINAL_CHECK_FOR_REQUESTS(&netif->tx, more_to_do);
 #endif
=20
-	if (more_to_do) {
+	if (more_to_do && likely(!netif->busted)) {
 		add_to_net_schedule_list_tail(netif);
 		maybe_schedule_tx_action();
 	}
@@ -1024,7 +1024,9 @@ static void netbk_fatal_tx_err(netif_t *
 {
 	printk(KERN_ERR "%s: fatal error; disabling device\n",
 	       netif->dev->name);
-	xenvif_carrier_off(netif);
+	netif->busted =3D 1;
+	disable_irq(netif->irq);
+	netif_deschedule_work(netif);
 	netif_put(netif);
 }
=20
@@ -1292,6 +1294,11 @@ static void net_tx_action(unsigned long=20
 		if (!netif)
 			continue;
=20
+		if (unlikely(netif->busted)) {
+			netif_put(netif);
+			continue;
+		}
+
 		if (netif->tx.sring->req_prod - netif->tx.req_cons >
 		    NET_TX_RING_SIZE) {
 			printk(KERN_ERR "%s: Impossible number of =
requests. "



--=__PartE7D7A6C1.2__=
Content-Type: text/plain; name="xen-netback-garbage-ring-fix.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-netback-garbage-ring-fix.patch"

netback: fix shutting down the ring if it contains garbage=0A=0AUsing =
rtnl_lock() in tasklet context is not permitted.=0A=0AThis undoes the part =
of 1219:5108c6901b30 that split off=0Axenvif_carrier_off() from netif_disco=
nnect().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/netback/common.h=0A+++ b/drivers/xen/netback/common.h=0A@@ =
-78,6 +78,8 @@ typedef struct netif_st {=0A 	u8 can_queue:1;	/* can =
queue packets for receiver? */=0A 	u8 copying_receiver:1;	/* copy =
packets to receiver?       */=0A =0A+	u8 busted:1;=0A+=0A 	/* Allow =
netif_be_start_xmit() to peek ahead in the rx request ring. */=0A 	=
RING_IDX rx_req_cons_peek;=0A =0A@@ -195,7 +197,8 @@ int netif_map(netif_t =
*netif, unsigned l=0A void netif_xenbus_init(void);=0A =0A #define =
netif_schedulable(netif)				\=0A-	(netif_runn=
ing((netif)->dev) && netback_carrier_ok(netif))=0A+	(likely(!(netif)->b=
usted) &&				\=0A+	 netif_running((netif)->dev=
) &&	netback_carrier_ok(netif))=0A =0A void netif_schedule_work(netif_t =
*netif);=0A void netif_deschedule_work(netif_t *netif);=0A@@ -204,9 +207,6 =
@@ int netif_be_start_xmit(struct sk_buff *=0A struct net_device_stats =
*netif_be_get_stats(struct net_device *dev);=0A irqreturn_t netif_be_int(in=
t irq, void *dev_id, struct pt_regs *regs);=0A =0A-/* Prevent the device =
from generating any further traffic. */=0A-void xenvif_carrier_off(netif_t =
*netif);=0A-=0A static inline int netbk_can_queue(struct net_device =
*dev)=0A {=0A 	netif_t *netif =3D netdev_priv(dev);=0A--- a/drivers/xen/ne=
tback/interface.c=0A+++ b/drivers/xen/netback/interface.c=0A@@ -56,6 +56,7 =
@@ module_param_named(queue_length, netbk_q=0A =0A static void __netif_up(n=
etif_t *netif)=0A {=0A+	netif->busted =3D 0;=0A 	enable_irq(netif->i=
rq);=0A 	netif_schedule_work(netif);=0A }=0A@@ -347,23 +348,19 @@ =
err_rx:=0A 	return err;=0A }=0A =0A-void xenvif_carrier_off(netif_t =
*netif)=0A-{=0A-	rtnl_lock();=0A-	netback_carrier_off(netif);=
=0A-	netif_carrier_off(netif->dev); /* discard queued packets */=0A-	if =
(netif_running(netif->dev))=0A-		__netif_down(netif);=0A-	=
rtnl_unlock();=0A-	netif_put(netif);=0A-}=0A-=0A void netif_disconnect=
(struct backend_info *be)=0A {=0A 	netif_t *netif =3D be->netif;=0A =
=0A-	if (netback_carrier_ok(netif))=0A-		xenvif_carrier_off(=
netif);=0A+	if (netback_carrier_ok(netif)) {=0A+		rtnl_lock()=
;=0A+		netback_carrier_off(netif);=0A+		netif_carrier_off(n=
etif->dev); /* discard queued packets */=0A+		if (netif_running(n=
etif->dev))=0A+			__netif_down(netif);=0A+		=
rtnl_unlock();=0A+		netif_put(netif);=0A+	}=0A =0A 	=
atomic_dec(&netif->refcnt);=0A 	wait_event(netif->waiting_to_free, =
atomic_read(&netif->refcnt) =3D=3D 0);=0A--- a/drivers/xen/netback/netback.=
c=0A+++ b/drivers/xen/netback/netback.c=0A@@ -845,7 +845,7 @@ void =
netif_schedule_work(netif_t *netif)=0A 	RING_FINAL_CHECK_FOR_REQUESTS(&neti=
f->tx, more_to_do);=0A #endif=0A =0A-	if (more_to_do) {=0A+	if =
(more_to_do && likely(!netif->busted)) {=0A 		add_to_net_schedule=
_list_tail(netif);=0A 		maybe_schedule_tx_action();=0A 	}=0A@@ =
-1024,7 +1024,9 @@ static void netbk_fatal_tx_err(netif_t *=0A {=0A 	=
printk(KERN_ERR "%s: fatal error; disabling device\n",=0A 	       =
netif->dev->name);=0A-	xenvif_carrier_off(netif);=0A+	netif->busted =3D =
1;=0A+	disable_irq(netif->irq);=0A+	netif_deschedule_work(netif);=0A 	=
netif_put(netif);=0A }=0A =0A@@ -1292,6 +1294,11 @@ static void net_tx_acti=
on(unsigned long =0A 		if (!netif)=0A 			=
continue;=0A =0A+		if (unlikely(netif->busted)) {=0A+		=
	netif_put(netif);=0A+			continue;=0A+		=
}=0A+=0A 		if (netif->tx.sring->req_prod - netif->tx.req_cons =
>=0A 		    NET_TX_RING_SIZE) {=0A 			printk(KERN=
_ERR "%s: Impossible number of requests. "=0A
--=__PartE7D7A6C1.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartE7D7A6C1.2__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 15:29:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:29: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 1U60kY-0002SK-2R; Thu, 14 Feb 2013 15:29:26 +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 1U60kV-0002Ry-Nk
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:29:24 +0000
Received: from [85.158.138.51:29203] by server-8.bemta-3.messagelabs.com id
	6D/E1-25687-4C20D115; Thu, 14 Feb 2013 15:29:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1360855702!27552301!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26954 invoked from network); 14 Feb 2013 15:28:23 -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; 14 Feb 2013 15:28:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 15:29:18 +0000
Message-Id: <511D10E102000078000BE5E2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 15:29:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
	<511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
In-Reply-To: <511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE7D7A6C1.2__="
Cc: David Vrabel <dvrabel@cantab.net>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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>
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.

--=__PartE7D7A6C1.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 14.02.13 at 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 14.02.13 at 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
>>> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
>>>> I don't think this patch will fix his problems, which - as described
>>>> yesterday - I'm relatively certain result from the harsh action
>>>> netbk_fatal_tx_err() does.
>>>=20
>>> Yes, having this one only is not enough. It will need to either =
disable
>>> the vif timer or check vif->netbk !=3D NULL inside timer callback.
>>=20
>> I continue to be unclear what timer you refer to.
>>=20
>> If we keep the carrier-off in fatal_tx_err, then _all_
>> asynchronously callable interfaces need to check whether the
>> vif -> netbk association went away. But, especially in the
>> context of using tasklets instead of kthreads, I meanwhile
>> think that simply setting a flag (along with turning off the IRQ)
>> would be better (and keep the turning off of the carrier the way
>> it had been done before. The flag would basically need checking
>> anywhere we look at the shared ring (which ought to be very
>> few places), and perhaps should also cause xenvif_schedulable()
>> to return false.
>=20
> Or a "light" version of xenvif_down(), i.e. simply
>=20
> 	disable_irq(vif->irq);
> 	xen_netbk_deschedule_xenvif(vif);
>=20
> If I'm not mistaken, doing this instead of xenvif_carrier_off()
> could be all that's needed.

Like the below/attached (compile tested only so far).

Jan

netback: fix shutting down the ring if it contains garbage

Using rtnl_lock() in tasklet context is not permitted.

This undoes the part of 1219:5108c6901b30 that split off
xenvif_carrier_off() from netif_disconnect().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/netback/common.h
+++ b/drivers/xen/netback/common.h
@@ -78,6 +78,8 @@ typedef struct netif_st {
 	u8 can_queue:1;	/* can queue packets for receiver? */
 	u8 copying_receiver:1;	/* copy packets to receiver?       */
=20
+	u8 busted:1;
+
 	/* Allow netif_be_start_xmit() to peek ahead in the rx request =
ring. */
 	RING_IDX rx_req_cons_peek;
=20
@@ -195,7 +197,8 @@ int netif_map(netif_t *netif, unsigned l
 void netif_xenbus_init(void);
=20
 #define netif_schedulable(netif)				\
-	(netif_running((netif)->dev) && netback_carrier_ok(netif))
+	(likely(!(netif)->busted) &&				\
+	 netif_running((netif)->dev) &&	netback_carrier_ok(netif))
=20
 void netif_schedule_work(netif_t *netif);
 void netif_deschedule_work(netif_t *netif);
@@ -204,9 +207,6 @@ int netif_be_start_xmit(struct sk_buff *
 struct net_device_stats *netif_be_get_stats(struct net_device *dev);
 irqreturn_t netif_be_int(int irq, void *dev_id, struct pt_regs *regs);
=20
-/* Prevent the device from generating any further traffic. */
-void xenvif_carrier_off(netif_t *netif);
-
 static inline int netbk_can_queue(struct net_device *dev)
 {
 	netif_t *netif =3D netdev_priv(dev);
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -56,6 +56,7 @@ module_param_named(queue_length, netbk_q
=20
 static void __netif_up(netif_t *netif)
 {
+	netif->busted =3D 0;
 	enable_irq(netif->irq);
 	netif_schedule_work(netif);
 }
@@ -347,23 +348,19 @@ err_rx:
 	return err;
 }
=20
-void xenvif_carrier_off(netif_t *netif)
-{
-	rtnl_lock();
-	netback_carrier_off(netif);
-	netif_carrier_off(netif->dev); /* discard queued packets */
-	if (netif_running(netif->dev))
-		__netif_down(netif);
-	rtnl_unlock();
-	netif_put(netif);
-}
-
 void netif_disconnect(struct backend_info *be)
 {
 	netif_t *netif =3D be->netif;
=20
-	if (netback_carrier_ok(netif))
-		xenvif_carrier_off(netif);
+	if (netback_carrier_ok(netif)) {
+		rtnl_lock();
+		netback_carrier_off(netif);
+		netif_carrier_off(netif->dev); /* discard queued packets =
*/
+		if (netif_running(netif->dev))
+			__netif_down(netif);
+		rtnl_unlock();
+		netif_put(netif);
+	}
=20
 	atomic_dec(&netif->refcnt);
 	wait_event(netif->waiting_to_free, atomic_read(&netif->refcnt) =
=3D=3D 0);
--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -845,7 +845,7 @@ void netif_schedule_work(netif_t *netif)
 	RING_FINAL_CHECK_FOR_REQUESTS(&netif->tx, more_to_do);
 #endif
=20
-	if (more_to_do) {
+	if (more_to_do && likely(!netif->busted)) {
 		add_to_net_schedule_list_tail(netif);
 		maybe_schedule_tx_action();
 	}
@@ -1024,7 +1024,9 @@ static void netbk_fatal_tx_err(netif_t *
 {
 	printk(KERN_ERR "%s: fatal error; disabling device\n",
 	       netif->dev->name);
-	xenvif_carrier_off(netif);
+	netif->busted =3D 1;
+	disable_irq(netif->irq);
+	netif_deschedule_work(netif);
 	netif_put(netif);
 }
=20
@@ -1292,6 +1294,11 @@ static void net_tx_action(unsigned long=20
 		if (!netif)
 			continue;
=20
+		if (unlikely(netif->busted)) {
+			netif_put(netif);
+			continue;
+		}
+
 		if (netif->tx.sring->req_prod - netif->tx.req_cons >
 		    NET_TX_RING_SIZE) {
 			printk(KERN_ERR "%s: Impossible number of =
requests. "



--=__PartE7D7A6C1.2__=
Content-Type: text/plain; name="xen-netback-garbage-ring-fix.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-netback-garbage-ring-fix.patch"

netback: fix shutting down the ring if it contains garbage=0A=0AUsing =
rtnl_lock() in tasklet context is not permitted.=0A=0AThis undoes the part =
of 1219:5108c6901b30 that split off=0Axenvif_carrier_off() from netif_disco=
nnect().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/netback/common.h=0A+++ b/drivers/xen/netback/common.h=0A@@ =
-78,6 +78,8 @@ typedef struct netif_st {=0A 	u8 can_queue:1;	/* can =
queue packets for receiver? */=0A 	u8 copying_receiver:1;	/* copy =
packets to receiver?       */=0A =0A+	u8 busted:1;=0A+=0A 	/* Allow =
netif_be_start_xmit() to peek ahead in the rx request ring. */=0A 	=
RING_IDX rx_req_cons_peek;=0A =0A@@ -195,7 +197,8 @@ int netif_map(netif_t =
*netif, unsigned l=0A void netif_xenbus_init(void);=0A =0A #define =
netif_schedulable(netif)				\=0A-	(netif_runn=
ing((netif)->dev) && netback_carrier_ok(netif))=0A+	(likely(!(netif)->b=
usted) &&				\=0A+	 netif_running((netif)->dev=
) &&	netback_carrier_ok(netif))=0A =0A void netif_schedule_work(netif_t =
*netif);=0A void netif_deschedule_work(netif_t *netif);=0A@@ -204,9 +207,6 =
@@ int netif_be_start_xmit(struct sk_buff *=0A struct net_device_stats =
*netif_be_get_stats(struct net_device *dev);=0A irqreturn_t netif_be_int(in=
t irq, void *dev_id, struct pt_regs *regs);=0A =0A-/* Prevent the device =
from generating any further traffic. */=0A-void xenvif_carrier_off(netif_t =
*netif);=0A-=0A static inline int netbk_can_queue(struct net_device =
*dev)=0A {=0A 	netif_t *netif =3D netdev_priv(dev);=0A--- a/drivers/xen/ne=
tback/interface.c=0A+++ b/drivers/xen/netback/interface.c=0A@@ -56,6 +56,7 =
@@ module_param_named(queue_length, netbk_q=0A =0A static void __netif_up(n=
etif_t *netif)=0A {=0A+	netif->busted =3D 0;=0A 	enable_irq(netif->i=
rq);=0A 	netif_schedule_work(netif);=0A }=0A@@ -347,23 +348,19 @@ =
err_rx:=0A 	return err;=0A }=0A =0A-void xenvif_carrier_off(netif_t =
*netif)=0A-{=0A-	rtnl_lock();=0A-	netback_carrier_off(netif);=
=0A-	netif_carrier_off(netif->dev); /* discard queued packets */=0A-	if =
(netif_running(netif->dev))=0A-		__netif_down(netif);=0A-	=
rtnl_unlock();=0A-	netif_put(netif);=0A-}=0A-=0A void netif_disconnect=
(struct backend_info *be)=0A {=0A 	netif_t *netif =3D be->netif;=0A =
=0A-	if (netback_carrier_ok(netif))=0A-		xenvif_carrier_off(=
netif);=0A+	if (netback_carrier_ok(netif)) {=0A+		rtnl_lock()=
;=0A+		netback_carrier_off(netif);=0A+		netif_carrier_off(n=
etif->dev); /* discard queued packets */=0A+		if (netif_running(n=
etif->dev))=0A+			__netif_down(netif);=0A+		=
rtnl_unlock();=0A+		netif_put(netif);=0A+	}=0A =0A 	=
atomic_dec(&netif->refcnt);=0A 	wait_event(netif->waiting_to_free, =
atomic_read(&netif->refcnt) =3D=3D 0);=0A--- a/drivers/xen/netback/netback.=
c=0A+++ b/drivers/xen/netback/netback.c=0A@@ -845,7 +845,7 @@ void =
netif_schedule_work(netif_t *netif)=0A 	RING_FINAL_CHECK_FOR_REQUESTS(&neti=
f->tx, more_to_do);=0A #endif=0A =0A-	if (more_to_do) {=0A+	if =
(more_to_do && likely(!netif->busted)) {=0A 		add_to_net_schedule=
_list_tail(netif);=0A 		maybe_schedule_tx_action();=0A 	}=0A@@ =
-1024,7 +1024,9 @@ static void netbk_fatal_tx_err(netif_t *=0A {=0A 	=
printk(KERN_ERR "%s: fatal error; disabling device\n",=0A 	       =
netif->dev->name);=0A-	xenvif_carrier_off(netif);=0A+	netif->busted =3D =
1;=0A+	disable_irq(netif->irq);=0A+	netif_deschedule_work(netif);=0A 	=
netif_put(netif);=0A }=0A =0A@@ -1292,6 +1294,11 @@ static void net_tx_acti=
on(unsigned long =0A 		if (!netif)=0A 			=
continue;=0A =0A+		if (unlikely(netif->busted)) {=0A+		=
	netif_put(netif);=0A+			continue;=0A+		=
}=0A+=0A 		if (netif->tx.sring->req_prod - netif->tx.req_cons =
>=0A 		    NET_TX_RING_SIZE) {=0A 			printk(KERN=
_ERR "%s: Impossible number of requests. "=0A
--=__PartE7D7A6C1.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartE7D7A6C1.2__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 15:29:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60kc-0002TL-KW; Thu, 14 Feb 2013 15:29:30 +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 1U60kb-0002Sz-7G
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:29:29 +0000
Received: from [85.158.143.99:25199] by server-1.bemta-4.messagelabs.com id
	D2/CE-08839-8D20D115; Thu, 14 Feb 2013 15:29:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360855767!21157908!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30550 invoked from network); 14 Feb 2013 15:29:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:29:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60kZ-000Mtd-IL; Thu, 14 Feb 2013 15:29:27 +0000
Date: Thu, 14 Feb 2013 15:29:27 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152927.GL83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-40-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-40-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 40/45] xen: arm: guest stage 1 walks on
	64-bit 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

At 15:56 +0000 on 23 Jan (1358956606), Ian Campbell wrote:
> Still only supports non-LPAE 32-bit guests.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:29:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60kc-0002TL-KW; Thu, 14 Feb 2013 15:29:30 +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 1U60kb-0002Sz-7G
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:29:29 +0000
Received: from [85.158.143.99:25199] by server-1.bemta-4.messagelabs.com id
	D2/CE-08839-8D20D115; Thu, 14 Feb 2013 15:29:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360855767!21157908!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30550 invoked from network); 14 Feb 2013 15:29:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:29:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60kZ-000Mtd-IL; Thu, 14 Feb 2013 15:29:27 +0000
Date: Thu, 14 Feb 2013 15:29:27 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214152927.GL83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-40-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-40-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 40/45] xen: arm: guest stage 1 walks on
	64-bit 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

At 15:56 +0000 on 23 Jan (1358956606), Ian Campbell wrote:
> Still only supports non-LPAE 32-bit guests.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:34:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60pX-00033Y-CS; Thu, 14 Feb 2013 15:34:35 +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 1U60pV-00033T-I2
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:34:33 +0000
Received: from [85.158.143.35:15714] by server-2.bemta-4.messagelabs.com id
	BA/EA-01597-8040D115; Thu, 14 Feb 2013 15:34:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360856065!5211638!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18840 invoked from network); 14 Feb 2013 15:34:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:34:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60pN-000Muz-3D; Thu, 14 Feb 2013 15:34:25 +0000
Date: Thu, 14 Feb 2013 15:34:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>, g@phlegethon.org
Message-ID: <20130214153425.GM83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-41-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-41-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 41/45] xen: arm: implement do_multicall_call
	for both 32 and 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956607), Ian Campbell wrote:
> Obviously nothing is actually making multicalls even on 32-bit so
> this isn't tested.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:34:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60pX-00033Y-CS; Thu, 14 Feb 2013 15:34:35 +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 1U60pV-00033T-I2
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:34:33 +0000
Received: from [85.158.143.35:15714] by server-2.bemta-4.messagelabs.com id
	BA/EA-01597-8040D115; Thu, 14 Feb 2013 15:34:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1360856065!5211638!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18840 invoked from network); 14 Feb 2013 15:34:28 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:34:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60pN-000Muz-3D; Thu, 14 Feb 2013 15:34:25 +0000
Date: Thu, 14 Feb 2013 15:34:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>, g@phlegethon.org
Message-ID: <20130214153425.GM83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-41-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-41-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 41/45] xen: arm: implement do_multicall_call
	for both 32 and 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956607), Ian Campbell wrote:
> Obviously nothing is actually making multicalls even on 32-bit so
> this isn't tested.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:35:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:35: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 1U60q2-00035p-Q2; Thu, 14 Feb 2013 15:35:06 +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 1U60q1-00035g-6C
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:35:05 +0000
Received: from [85.158.143.99:57645] by server-3.bemta-4.messagelabs.com id
	84/FC-08920-8240D115; Thu, 14 Feb 2013 15:35:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360856103!20523603!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10948 invoked from network); 14 Feb 2013 15:35:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:35:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60pz-000Mvk-ES; Thu, 14 Feb 2013 15:35:03 +0000
Date: Thu, 14 Feb 2013 15:35:03 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153503.GN83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-42-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-42-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 42/45] xen: arm: Enable VFP is a nop on
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956608), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:35:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:35: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 1U60q2-00035p-Q2; Thu, 14 Feb 2013 15:35:06 +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 1U60q1-00035g-6C
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:35:05 +0000
Received: from [85.158.143.99:57645] by server-3.bemta-4.messagelabs.com id
	84/FC-08920-8240D115; Thu, 14 Feb 2013 15:35:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360856103!20523603!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10948 invoked from network); 14 Feb 2013 15:35:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:35:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60pz-000Mvk-ES; Thu, 14 Feb 2013 15:35:03 +0000
Date: Thu, 14 Feb 2013 15:35:03 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153503.GN83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-42-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-42-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 42/45] xen: arm: Enable VFP is a nop on
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956608), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:36:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60rV-0003ET-9n; Thu, 14 Feb 2013 15:36:37 +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 1U60rU-0003EE-1i
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:36:36 +0000
Received: from [85.158.137.99:45312] by server-16.bemta-3.messagelabs.com id
	05/5E-02727-0840D115; Thu, 14 Feb 2013 15:36:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360856145!13064053!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1862 invoked from network); 14 Feb 2013 15:35:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:35:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60qe-000Mw2-0n; Thu, 14 Feb 2013 15:35:44 +0000
Date: Thu, 14 Feb 2013 15:35:43 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153543.GO83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-43-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-43-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 43/45] xen: arm: Use generic mem{cpy, move,
	set, zero} on 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956609), Ian Campbell wrote:
> No optimised versions are available in Linux yet (meaning I couldn't
> copy them).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:36:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60rV-0003ET-9n; Thu, 14 Feb 2013 15:36:37 +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 1U60rU-0003EE-1i
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:36:36 +0000
Received: from [85.158.137.99:45312] by server-16.bemta-3.messagelabs.com id
	05/5E-02727-0840D115; Thu, 14 Feb 2013 15:36:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360856145!13064053!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1862 invoked from network); 14 Feb 2013 15:35:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:35:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60qe-000Mw2-0n; Thu, 14 Feb 2013 15:35:44 +0000
Date: Thu, 14 Feb 2013 15:35:43 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153543.GO83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-43-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-43-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 43/45] xen: arm: Use generic mem{cpy, move,
	set, zero} on 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956609), Ian Campbell wrote:
> No optimised versions are available in Linux yet (meaning I couldn't
> copy them).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:36:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:36: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 1U60rh-0003G6-N3; Thu, 14 Feb 2013 15:36: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 1U60rf-0003Fm-QU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:36:47 +0000
Received: from [85.158.138.51:29445] by server-14.bemta-3.messagelabs.com id
	7E/F6-23533-A840D115; Thu, 14 Feb 2013 15:36:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360856200!19565711!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13261 invoked from network); 14 Feb 2013 15:36:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:36:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60rY-000MwL-7X; Thu, 14 Feb 2013 15:36:40 +0000
Date: Thu, 14 Feb 2013 15:36:40 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153640.GP83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-44-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-44-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 44/45] xen: arm: Explicitly setup VPIDR &
	VMPIDR at start of day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956610), Ian Campbell wrote:
> These are supposed to reset to the value of the underlying hardware
> but appears not to be on at least some v8 models. There's no harm in
> setting them explicitly.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:36:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:36: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 1U60rh-0003G6-N3; Thu, 14 Feb 2013 15:36: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 1U60rf-0003Fm-QU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:36:47 +0000
Received: from [85.158.138.51:29445] by server-14.bemta-3.messagelabs.com id
	7E/F6-23533-A840D115; Thu, 14 Feb 2013 15:36:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360856200!19565711!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13261 invoked from network); 14 Feb 2013 15:36:40 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 15:36:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60rY-000MwL-7X; Thu, 14 Feb 2013 15:36:40 +0000
Date: Thu, 14 Feb 2013 15:36:40 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153640.GP83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-44-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-44-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 44/45] xen: arm: Explicitly setup VPIDR &
	VMPIDR at start of day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:56 +0000 on 23 Jan (1358956610), Ian Campbell wrote:
> These are supposed to reset to the value of the underlying hardware
> but appears not to be on at least some v8 models. There's no harm in
> setting them explicitly.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 14 15:37:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:37: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 1U60rw-0003J5-4i; Thu, 14 Feb 2013 15:37:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U60ru-0003IX-MM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:37:02 +0000
Received: from [85.158.143.99:12640] by server-3.bemta-4.messagelabs.com id
	54/90-08920-E940D115; Thu, 14 Feb 2013 15:37:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360856213!20524050!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21531 invoked from network); 14 Feb 2013 15:36:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:36:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1467406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:36: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.297.1;
	Thu, 14 Feb 2013 15:36:52 +0000
Message-ID: <1360856211.20449.430.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 15:36:51 +0000
In-Reply-To: <20130214151828.GE83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-33-git-send-email-ian.campbell@citrix.com>
	<20130214151828.GE83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 33/45] xen: arm: make dom0 builder work on
 64-bit 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 Thu, 2013-02-14 at 15:18 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956599), Ian Campbell wrote:
> > @@ -299,6 +299,12 @@ int construct_dom0(struct domain *d)
> >      if ( rc < 0 )
> >          return rc;
> >  
> > +#ifdef CONFIG_ARM_64
> > +    printk(" Xen kernel: 64-bit, AArch64, AArch32\n");
> > +#else
> > +    printk(" Xen kernel: 32-bit, AArch32\n");
> > +#endif
> 
> A debugging printk left over?  It seems misleading, since dom0 is
> AArch32 in any case, and it's got a leading space.

It's the equivalent to this print on x86:
    printk(" Xen  kernel: 64-bit, lsb, compat32\n");

I think this is 64-bit followed by the capabilities? I could happily
drop,

It's indented because it ought to be followed by the equivalent to 
    printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 "\n",
           elf_64bit(&elf) ? "64-bit" : "32-bit",
           parms.pae       ? ", PAE"  : "",
           elf_msb(&elf)   ? "msb"    : "lsb",
           elf.pstart, elf.pend);
but it isn't.

On ARM this message is probably worthless in its current form, I'll
remove it.

> 
> Otherwise, 
> 
> 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 Thu Feb 14 15:37:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:37: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 1U60rw-0003J5-4i; Thu, 14 Feb 2013 15:37:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U60ru-0003IX-MM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:37:02 +0000
Received: from [85.158.143.99:12640] by server-3.bemta-4.messagelabs.com id
	54/90-08920-E940D115; Thu, 14 Feb 2013 15:37:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1360856213!20524050!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21531 invoked from network); 14 Feb 2013 15:36:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:36:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1467406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:36: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.297.1;
	Thu, 14 Feb 2013 15:36:52 +0000
Message-ID: <1360856211.20449.430.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 14 Feb 2013 15:36:51 +0000
In-Reply-To: <20130214151828.GE83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-33-git-send-email-ian.campbell@citrix.com>
	<20130214151828.GE83752@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 33/45] xen: arm: make dom0 builder work on
 64-bit 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 Thu, 2013-02-14 at 15:18 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956599), Ian Campbell wrote:
> > @@ -299,6 +299,12 @@ int construct_dom0(struct domain *d)
> >      if ( rc < 0 )
> >          return rc;
> >  
> > +#ifdef CONFIG_ARM_64
> > +    printk(" Xen kernel: 64-bit, AArch64, AArch32\n");
> > +#else
> > +    printk(" Xen kernel: 32-bit, AArch32\n");
> > +#endif
> 
> A debugging printk left over?  It seems misleading, since dom0 is
> AArch32 in any case, and it's got a leading space.

It's the equivalent to this print on x86:
    printk(" Xen  kernel: 64-bit, lsb, compat32\n");

I think this is 64-bit followed by the capabilities? I could happily
drop,

It's indented because it ought to be followed by the equivalent to 
    printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 "\n",
           elf_64bit(&elf) ? "64-bit" : "32-bit",
           parms.pae       ? ", PAE"  : "",
           elf_msb(&elf)   ? "msb"    : "lsb",
           elf.pstart, elf.pend);
but it isn't.

On ARM this message is probably worthless in its current form, I'll
remove it.

> 
> Otherwise, 
> 
> 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 Thu Feb 14 15:37:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:37: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 1U60sK-0003OA-Iw; Thu, 14 Feb 2013 15:37:28 +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 1U60sJ-0003Nd-IK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:37:27 +0000
Received: from [193.109.254.147:9650] by server-10.bemta-14.messagelabs.com id
	2B/DD-12679-6B40D115; Thu, 14 Feb 2013 15:37:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360856245!10336801!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5994 invoked from network); 14 Feb 2013 15:37:26 -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; 14 Feb 2013 15:37:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60sH-000MxI-GJ; Thu, 14 Feb 2013 15:37:25 +0000
Date: Thu, 14 Feb 2013 15:37:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153725.GQ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-45-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-45-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 45/45] xen: arm: skanky "appended kernel"
	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

At 15:56 +0000 on 23 Jan (1358956611), Ian Campbell wrote:
> I'm using this with the ARMv8 Foundation model:
> 
> ./Foundation_v8pkg/Foundation_v8 \
> 	--image xen-unstable/xen/xen-arm64 \
> 	--data guest.img@0x80400000
> 
> where guest.img is a zImage.
> 
> (disabled by default edit config.h to enable)
> 
> Mostly throwing this out there in case others find it useful.

Righto - so no need to ack this one. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:37:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15:37: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 1U60sK-0003OA-Iw; Thu, 14 Feb 2013 15:37:28 +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 1U60sJ-0003Nd-IK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:37:27 +0000
Received: from [193.109.254.147:9650] by server-10.bemta-14.messagelabs.com id
	2B/DD-12679-6B40D115; Thu, 14 Feb 2013 15:37:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360856245!10336801!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5994 invoked from network); 14 Feb 2013 15:37:26 -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; 14 Feb 2013 15:37:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U60sH-000MxI-GJ; Thu, 14 Feb 2013 15:37:25 +0000
Date: Thu, 14 Feb 2013 15:37:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130214153725.GQ83752@ocelot.phlegethon.org>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-45-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1358956611-8432-45-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 45/45] xen: arm: skanky "appended kernel"
	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

At 15:56 +0000 on 23 Jan (1358956611), Ian Campbell wrote:
> I'm using this with the ARMv8 Foundation model:
> 
> ./Foundation_v8pkg/Foundation_v8 \
> 	--image xen-unstable/xen/xen-arm64 \
> 	--data guest.img@0x80400000
> 
> where guest.img is a zImage.
> 
> (disabled by default edit config.h to enable)
> 
> Mostly throwing this out there in case others find it useful.

Righto - so no need to ack this one. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:39:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60tm-0003f4-3L; Thu, 14 Feb 2013 15:38:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U60tk-0003eh-1J
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:38:56 +0000
Received: from [85.158.137.99:14848] by server-8.bemta-3.messagelabs.com id
	77/61-25687-F050D115; Thu, 14 Feb 2013 15:38:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360856332!21455003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21100 invoked from network); 14 Feb 2013 15:38:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7516743"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:38:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:38:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U60tf-0008PO-9Z;
	Thu, 14 Feb 2013 15:38:51 +0000
Message-ID: <1360856331.16636.156.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 15:38:51 +0000
In-Reply-To: <511D10E102000078000BE5E2@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
	<511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
	<511D10E102000078000BE5E2@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 15:29 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 14.02.13 at 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
> >>> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
> >>>> I don't think this patch will fix his problems, which - as described
> >>>> yesterday - I'm relatively certain result from the harsh action
> >>>> netbk_fatal_tx_err() does.
> >>> 
> >>> Yes, having this one only is not enough. It will need to either disable
> >>> the vif timer or check vif->netbk != NULL inside timer callback.
> >> 
> >> I continue to be unclear what timer you refer to.
> >> 
> >> If we keep the carrier-off in fatal_tx_err, then _all_
> >> asynchronously callable interfaces need to check whether the
> >> vif -> netbk association went away. But, especially in the
> >> context of using tasklets instead of kthreads, I meanwhile
> >> think that simply setting a flag (along with turning off the IRQ)
> >> would be better (and keep the turning off of the carrier the way
> >> it had been done before. The flag would basically need checking
> >> anywhere we look at the shared ring (which ought to be very
> >> few places), and perhaps should also cause xenvif_schedulable()
> >> to return false.
> > 
> > Or a "light" version of xenvif_down(), i.e. simply
> > 
> > 	disable_irq(vif->irq);
> > 	xen_netbk_deschedule_xenvif(vif);
> > 
> > If I'm not mistaken, doing this instead of xenvif_carrier_off()
> > could be all that's needed.
> 

Just a side note, I probably would go along with this busted flag in the
future. If we are to move to 1:1 model, there will be no vif <-> netbk
connection anymore, so the testing against vif->netbk won't exist
anymore.

If this approach serves both tasklet and thread model well, this is the
way to go.


Wei.

> Like the below/attached (compile tested only so far).
> 
> Jan
> 
> netback: fix shutting down the ring if it contains garbage
> 
> Using rtnl_lock() in tasklet context is not permitted.
> 
> This undoes the part of 1219:5108c6901b30 that split off
> xenvif_carrier_off() from netif_disconnect().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/drivers/xen/netback/common.h
> +++ b/drivers/xen/netback/common.h
> @@ -78,6 +78,8 @@ typedef struct netif_st {
>  	u8 can_queue:1;	/* can queue packets for receiver? */
>  	u8 copying_receiver:1;	/* copy packets to receiver?       */
>  
> +	u8 busted:1;
> +
>  	/* Allow netif_be_start_xmit() to peek ahead in the rx request ring. */
>  	RING_IDX rx_req_cons_peek;
>  
> @@ -195,7 +197,8 @@ int netif_map(netif_t *netif, unsigned l
>  void netif_xenbus_init(void);
>  
>  #define netif_schedulable(netif)				\
> -	(netif_running((netif)->dev) && netback_carrier_ok(netif))
> +	(likely(!(netif)->busted) &&				\
> +	 netif_running((netif)->dev) &&	netback_carrier_ok(netif))
>  
>  void netif_schedule_work(netif_t *netif);
>  void netif_deschedule_work(netif_t *netif);
> @@ -204,9 +207,6 @@ int netif_be_start_xmit(struct sk_buff *
>  struct net_device_stats *netif_be_get_stats(struct net_device *dev);
>  irqreturn_t netif_be_int(int irq, void *dev_id, struct pt_regs *regs);
>  
> -/* Prevent the device from generating any further traffic. */
> -void xenvif_carrier_off(netif_t *netif);
> -
>  static inline int netbk_can_queue(struct net_device *dev)
>  {
>  	netif_t *netif = netdev_priv(dev);
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -56,6 +56,7 @@ module_param_named(queue_length, netbk_q
>  
>  static void __netif_up(netif_t *netif)
>  {
> +	netif->busted = 0;
>  	enable_irq(netif->irq);
>  	netif_schedule_work(netif);
>  }
> @@ -347,23 +348,19 @@ err_rx:
>  	return err;
>  }
>  
> -void xenvif_carrier_off(netif_t *netif)
> -{
> -	rtnl_lock();
> -	netback_carrier_off(netif);
> -	netif_carrier_off(netif->dev); /* discard queued packets */
> -	if (netif_running(netif->dev))
> -		__netif_down(netif);
> -	rtnl_unlock();
> -	netif_put(netif);
> -}
> -
>  void netif_disconnect(struct backend_info *be)
>  {
>  	netif_t *netif = be->netif;
>  
> -	if (netback_carrier_ok(netif))
> -		xenvif_carrier_off(netif);
> +	if (netback_carrier_ok(netif)) {
> +		rtnl_lock();
> +		netback_carrier_off(netif);
> +		netif_carrier_off(netif->dev); /* discard queued packets */
> +		if (netif_running(netif->dev))
> +			__netif_down(netif);
> +		rtnl_unlock();
> +		netif_put(netif);
> +	}
>  
>  	atomic_dec(&netif->refcnt);
>  	wait_event(netif->waiting_to_free, atomic_read(&netif->refcnt) == 0);
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -845,7 +845,7 @@ void netif_schedule_work(netif_t *netif)
>  	RING_FINAL_CHECK_FOR_REQUESTS(&netif->tx, more_to_do);
>  #endif
>  
> -	if (more_to_do) {
> +	if (more_to_do && likely(!netif->busted)) {
>  		add_to_net_schedule_list_tail(netif);
>  		maybe_schedule_tx_action();
>  	}
> @@ -1024,7 +1024,9 @@ static void netbk_fatal_tx_err(netif_t *
>  {
>  	printk(KERN_ERR "%s: fatal error; disabling device\n",
>  	       netif->dev->name);
> -	xenvif_carrier_off(netif);
> +	netif->busted = 1;
> +	disable_irq(netif->irq);
> +	netif_deschedule_work(netif);
>  	netif_put(netif);
>  }
>  
> @@ -1292,6 +1294,11 @@ static void net_tx_action(unsigned long 
>  		if (!netif)
>  			continue;
>  
> +		if (unlikely(netif->busted)) {
> +			netif_put(netif);
> +			continue;
> +		}
> +
>  		if (netif->tx.sring->req_prod - netif->tx.req_cons >
>  		    NET_TX_RING_SIZE) {
>  			printk(KERN_ERR "%s: Impossible number of requests. "
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:39:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U60tm-0003f4-3L; Thu, 14 Feb 2013 15:38:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U60tk-0003eh-1J
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:38:56 +0000
Received: from [85.158.137.99:14848] by server-8.bemta-3.messagelabs.com id
	77/61-25687-F050D115; Thu, 14 Feb 2013 15:38:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360856332!21455003!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21100 invoked from network); 14 Feb 2013 15:38:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7516743"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:38:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:38:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U60tf-0008PO-9Z;
	Thu, 14 Feb 2013 15:38:51 +0000
Message-ID: <1360856331.16636.156.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 14 Feb 2013 15:38:51 +0000
In-Reply-To: <511D10E102000078000BE5E2@nat28.tlf.novell.com>
References: <510C3AA3.2090508@theshore.net>
	<CAOsiSVVyNU8GiJZ1km805nL3+UrrE-4J1Wo_UKjMvOiyzpr-xw@mail.gmail.com>
	<50E3A390-C52B-476A-8B20-BADBA42F3775@theshore.net>
	<51181924.4050500@theshore.net>
	<1360583103.16636.29.camel@zion.uk.xensource.com>
	<1360663133.20449.123.camel@zakaz.uk.xensource.com>
	<511AFFC9.3050404@theshore.net>
	<1360779868.16636.92.camel@zion.uk.xensource.com>
	<1360780669.16636.94.camel@zion.uk.xensource.com>
	<511BE780.9000707@cantab.net>
	<20130213201725.GA1453@zion.uk.xensource.com>
	<511CB86702000078000BE1C5@nat28.tlf.novell.com>
	<1360840843.16636.109.camel@zion.uk.xensource.com>
	<511CDD2202000078000BE2F3@nat28.tlf.novell.com>
	<1360843993.16636.118.camel@zion.uk.xensource.com>
	<511CE7B902000078000BE35B@nat28.tlf.novell.com>
	<511CEA6E02000078000BE3AD@nat28.tlf.novell.com>
	<511D10E102000078000BE5E2@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: David Vrabel <dvrabel@cantab.net>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] netback Oops then xenwatch stuck in D 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 Thu, 2013-02-14 at 15:29 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 14.02.13 at 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@citrix.com> wrote:
> >>> On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
> >>>> I don't think this patch will fix his problems, which - as described
> >>>> yesterday - I'm relatively certain result from the harsh action
> >>>> netbk_fatal_tx_err() does.
> >>> 
> >>> Yes, having this one only is not enough. It will need to either disable
> >>> the vif timer or check vif->netbk != NULL inside timer callback.
> >> 
> >> I continue to be unclear what timer you refer to.
> >> 
> >> If we keep the carrier-off in fatal_tx_err, then _all_
> >> asynchronously callable interfaces need to check whether the
> >> vif -> netbk association went away. But, especially in the
> >> context of using tasklets instead of kthreads, I meanwhile
> >> think that simply setting a flag (along with turning off the IRQ)
> >> would be better (and keep the turning off of the carrier the way
> >> it had been done before. The flag would basically need checking
> >> anywhere we look at the shared ring (which ought to be very
> >> few places), and perhaps should also cause xenvif_schedulable()
> >> to return false.
> > 
> > Or a "light" version of xenvif_down(), i.e. simply
> > 
> > 	disable_irq(vif->irq);
> > 	xen_netbk_deschedule_xenvif(vif);
> > 
> > If I'm not mistaken, doing this instead of xenvif_carrier_off()
> > could be all that's needed.
> 

Just a side note, I probably would go along with this busted flag in the
future. If we are to move to 1:1 model, there will be no vif <-> netbk
connection anymore, so the testing against vif->netbk won't exist
anymore.

If this approach serves both tasklet and thread model well, this is the
way to go.


Wei.

> Like the below/attached (compile tested only so far).
> 
> Jan
> 
> netback: fix shutting down the ring if it contains garbage
> 
> Using rtnl_lock() in tasklet context is not permitted.
> 
> This undoes the part of 1219:5108c6901b30 that split off
> xenvif_carrier_off() from netif_disconnect().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/drivers/xen/netback/common.h
> +++ b/drivers/xen/netback/common.h
> @@ -78,6 +78,8 @@ typedef struct netif_st {
>  	u8 can_queue:1;	/* can queue packets for receiver? */
>  	u8 copying_receiver:1;	/* copy packets to receiver?       */
>  
> +	u8 busted:1;
> +
>  	/* Allow netif_be_start_xmit() to peek ahead in the rx request ring. */
>  	RING_IDX rx_req_cons_peek;
>  
> @@ -195,7 +197,8 @@ int netif_map(netif_t *netif, unsigned l
>  void netif_xenbus_init(void);
>  
>  #define netif_schedulable(netif)				\
> -	(netif_running((netif)->dev) && netback_carrier_ok(netif))
> +	(likely(!(netif)->busted) &&				\
> +	 netif_running((netif)->dev) &&	netback_carrier_ok(netif))
>  
>  void netif_schedule_work(netif_t *netif);
>  void netif_deschedule_work(netif_t *netif);
> @@ -204,9 +207,6 @@ int netif_be_start_xmit(struct sk_buff *
>  struct net_device_stats *netif_be_get_stats(struct net_device *dev);
>  irqreturn_t netif_be_int(int irq, void *dev_id, struct pt_regs *regs);
>  
> -/* Prevent the device from generating any further traffic. */
> -void xenvif_carrier_off(netif_t *netif);
> -
>  static inline int netbk_can_queue(struct net_device *dev)
>  {
>  	netif_t *netif = netdev_priv(dev);
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -56,6 +56,7 @@ module_param_named(queue_length, netbk_q
>  
>  static void __netif_up(netif_t *netif)
>  {
> +	netif->busted = 0;
>  	enable_irq(netif->irq);
>  	netif_schedule_work(netif);
>  }
> @@ -347,23 +348,19 @@ err_rx:
>  	return err;
>  }
>  
> -void xenvif_carrier_off(netif_t *netif)
> -{
> -	rtnl_lock();
> -	netback_carrier_off(netif);
> -	netif_carrier_off(netif->dev); /* discard queued packets */
> -	if (netif_running(netif->dev))
> -		__netif_down(netif);
> -	rtnl_unlock();
> -	netif_put(netif);
> -}
> -
>  void netif_disconnect(struct backend_info *be)
>  {
>  	netif_t *netif = be->netif;
>  
> -	if (netback_carrier_ok(netif))
> -		xenvif_carrier_off(netif);
> +	if (netback_carrier_ok(netif)) {
> +		rtnl_lock();
> +		netback_carrier_off(netif);
> +		netif_carrier_off(netif->dev); /* discard queued packets */
> +		if (netif_running(netif->dev))
> +			__netif_down(netif);
> +		rtnl_unlock();
> +		netif_put(netif);
> +	}
>  
>  	atomic_dec(&netif->refcnt);
>  	wait_event(netif->waiting_to_free, atomic_read(&netif->refcnt) == 0);
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -845,7 +845,7 @@ void netif_schedule_work(netif_t *netif)
>  	RING_FINAL_CHECK_FOR_REQUESTS(&netif->tx, more_to_do);
>  #endif
>  
> -	if (more_to_do) {
> +	if (more_to_do && likely(!netif->busted)) {
>  		add_to_net_schedule_list_tail(netif);
>  		maybe_schedule_tx_action();
>  	}
> @@ -1024,7 +1024,9 @@ static void netbk_fatal_tx_err(netif_t *
>  {
>  	printk(KERN_ERR "%s: fatal error; disabling device\n",
>  	       netif->dev->name);
> -	xenvif_carrier_off(netif);
> +	netif->busted = 1;
> +	disable_irq(netif->irq);
> +	netif_deschedule_work(netif);
>  	netif_put(netif);
>  }
>  
> @@ -1292,6 +1294,11 @@ static void net_tx_action(unsigned long 
>  		if (!netif)
>  			continue;
>  
> +		if (unlikely(netif->busted)) {
> +			netif_put(netif);
> +			continue;
> +		}
> +
>  		if (netif->tx.sring->req_prod - netif->tx.req_cons >
>  		    NET_TX_RING_SIZE) {
>  			printk(KERN_ERR "%s: Impossible number of requests. "
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:52:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U6168-0004Kn-Ft; Thu, 14 Feb 2013 15:51: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 1U6167-0004Ki-3t
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:51:43 +0000
Received: from [85.158.139.83:15160] by server-9.bemta-5.messagelabs.com id
	D1/0F-24440-E080D115; Thu, 14 Feb 2013 15:51:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360857101!31887187!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26714 invoked from network); 14 Feb 2013 15:51:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1467986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:51: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.297.1;
	Thu, 14 Feb 2013 15:51:39 +0000
Message-ID: <1360857098.20449.431.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 14 Feb 2013 15:51:38 +0000
In-Reply-To: <1360854601.20449.425.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
	<20130214145917.GC83752@ocelot.phlegethon.org>
	<1360854601.20449.425.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 32/45] xen: arm: show_registers() support
 for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 15:10 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:59 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956598), Ian Campbell wrote:
> > > -static void _show_registers(struct cpu_user_regs *regs,
> > > -                            struct reg_ctxt *ctxt,
> > > -                            int guest_mode)
> > > +
> > > +static void _show_registers_32(struct cpu_user_regs *regs,
> > 
> > Can we drop the _extraneous _underscore while we're here?
> 
> yes.

I did this, although note that the call chain is
	show_registers -> _show_registers -> show_registers_(32|64)
or
	vcpu_show_registers -> _show_registers -> ...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:52:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U6168-0004Kn-Ft; Thu, 14 Feb 2013 15:51: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 1U6167-0004Ki-3t
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:51:43 +0000
Received: from [85.158.139.83:15160] by server-9.bemta-5.messagelabs.com id
	D1/0F-24440-E080D115; Thu, 14 Feb 2013 15:51:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1360857101!31887187!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26714 invoked from network); 14 Feb 2013 15:51:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1467986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:51: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.297.1;
	Thu, 14 Feb 2013 15:51:39 +0000
Message-ID: <1360857098.20449.431.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 14 Feb 2013 15:51:38 +0000
In-Reply-To: <1360854601.20449.425.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-32-git-send-email-ian.campbell@citrix.com>
	<20130214145917.GC83752@ocelot.phlegethon.org>
	<1360854601.20449.425.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 32/45] xen: arm: show_registers() support
 for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 15:10 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:59 +0000, Tim Deegan wrote:
> > At 15:56 +0000 on 23 Jan (1358956598), Ian Campbell wrote:
> > > -static void _show_registers(struct cpu_user_regs *regs,
> > > -                            struct reg_ctxt *ctxt,
> > > -                            int guest_mode)
> > > +
> > > +static void _show_registers_32(struct cpu_user_regs *regs,
> > 
> > Can we drop the _extraneous _underscore while we're here?
> 
> yes.

I did this, although note that the call chain is
	show_registers -> _show_registers -> show_registers_(32|64)
or
	vcpu_show_registers -> _show_registers -> ...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:59:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U61DX-0004Ve-KC; Thu, 14 Feb 2013 15:59:23 +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 1U61DW-0004VZ-7L
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:59:22 +0000
Received: from [85.158.139.211:59037] by server-15.bemta-5.messagelabs.com id
	C8/27-18914-9D90D115; Thu, 14 Feb 2013 15:59:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360857559!21474402!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14075 invoked from network); 14 Feb 2013 15:59:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:59:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1468382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:59: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.297.1;
	Thu, 14 Feb 2013 15:59:18 +0000
Message-ID: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:17 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 00/04] xen: public interface (and foreign
 check) changes for arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 in v2 are to the first patch which I botched a fair bit in the
first cut.

The main change here is to switch evtchns to xen_ulong_t on arm, this
enables us to have the same interface on arm32 and arm64. I will post a
Linux side series shortly. This is an ABI change for ARM but not x86.

The remainder of the series fixes the tools/include/xen-foreign checks
to cover more stuff on ARM.

As part of this I have moved start_info out of the generic public
headers and into x86-specific public headers -- ARM does not use this
struct in its ABI and the majority of start_info is PV MMU stuff.
Removing it from ARM means I don't have to worry about the unsigned
longs in there.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 15:59:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 15: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 1U61DX-0004Ve-KC; Thu, 14 Feb 2013 15:59:23 +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 1U61DW-0004VZ-7L
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 15:59:22 +0000
Received: from [85.158.139.211:59037] by server-15.bemta-5.messagelabs.com id
	C8/27-18914-9D90D115; Thu, 14 Feb 2013 15:59:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360857559!21474402!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14075 invoked from network); 14 Feb 2013 15:59:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:59:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1468382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 15:59: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.297.1;
	Thu, 14 Feb 2013 15:59:18 +0000
Message-ID: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:17 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2 00/04] xen: public interface (and foreign
 check) changes for arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 in v2 are to the first patch which I botched a fair bit in the
first cut.

The main change here is to switch evtchns to xen_ulong_t on arm, this
enables us to have the same interface on arm32 and arm64. I will post a
Linux side series shortly. This is an ABI change for ARM but not x86.

The remainder of the series fixes the tools/include/xen-foreign checks
to cover more stuff on ARM.

As part of this I have moved start_info out of the generic public
headers and into x86-specific public headers -- ARM does not use this
struct in its ABI and the majority of start_info is PV MMU stuff.
Removing it from ARM means I don't have to worry about the unsigned
longs in there.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:00:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U61EF-0004pK-32; Thu, 14 Feb 2013 16:00:07 +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 1U61ED-0004lH-Cf
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:00:05 +0000
Received: from [85.158.139.83:62783] by server-12.bemta-5.messagelabs.com id
	7B/67-20195-40A0D115; Thu, 14 Feb 2013 16:00:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360857601!21044569!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30029 invoked from network); 14 Feb 2013 16:00:03 -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;
	14 Feb 2013 16:00:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149707"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-Bk;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:49 +0000
Message-ID: <1360857591-24979-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/4] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/include/xen-foreign/mkheader.py |    4 +++-
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index eee28f3..e3e61f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,17 +21,18 @@ inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 """;
 
-
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -46,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 14 16:00:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U61EF-0004pK-32; Thu, 14 Feb 2013 16:00:07 +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 1U61ED-0004lH-Cf
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:00:05 +0000
Received: from [85.158.139.83:62783] by server-12.bemta-5.messagelabs.com id
	7B/67-20195-40A0D115; Thu, 14 Feb 2013 16:00:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360857601!21044569!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30029 invoked from network); 14 Feb 2013 16:00:03 -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;
	14 Feb 2013 16:00:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149707"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-Bk;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:49 +0000
Message-ID: <1360857591-24979-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/4] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/include/xen-foreign/mkheader.py |    4 +++-
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index eee28f3..e3e61f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,17 +21,18 @@ inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 """;
 
-
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -46,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 14 16:00:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61EF-0004pS-K8; Thu, 14 Feb 2013 16:00:07 +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 1U61EE-0004lH-60
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:00:06 +0000
Received: from [85.158.139.83:43274] by server-12.bemta-5.messagelabs.com id
	3D/77-20195-50A0D115; Thu, 14 Feb 2013 16:00:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360857601!21044569!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30178 invoked from network); 14 Feb 2013 16:00:04 -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;
	14 Feb 2013 16:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149711"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-Dh;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:50 +0000
Message-ID: <1360857591-24979-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Most of this struct is PV MMU specific and it is not used on ARM at all.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xenctrl.h             |    5 +--
 xen/include/public/arch-x86/xen.h |   73 +++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h          |   73 -------------------------------------
 xen/include/xlat.lst              |    2 +-
 4 files changed, 76 insertions(+), 77 deletions(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 32122fd..9e4a741 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -395,15 +395,14 @@ typedef union
     shared_info_t s;
 } shared_info_any_t;
 
+#if defined(__i386__) || defined(__x86_64__)
 typedef union
 {
-#if defined(__i386__) || defined(__x86_64__)
     start_info_x86_64_t x64;
     start_info_x86_32_t x32;
-#endif
     start_info_t s;
 } start_info_any_t;
-
+#endif
 
 int xc_domain_create(xc_interface *xch,
                      uint32_t ssidref,
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 13c21dc..00f0306 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -147,6 +147,79 @@ DEFINE_XEN_GUEST_HANDLE(trap_info_t);
 
 typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
 
+#define MAX_GUEST_CMDLINE 1024
+struct start_info {
+    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
+    char magic[32];             /* "xen-<version>-<platform>".            */
+    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+    unsigned long shared_info;  /* MACHINE address of shared info struct. */
+    uint32_t flags;             /* SIF_xxx flags.                         */
+    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+    uint32_t store_evtchn;      /* Event channel for store communication. */
+    union {
+        struct {
+            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+            uint32_t  evtchn;   /* Event channel for console page.        */
+        } domU;
+        struct {
+            uint32_t info_off;  /* Offset of console_info struct.         */
+            uint32_t info_size; /* Size of console_info struct from start.*/
+        } dom0;
+    } console;
+    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
+    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
+    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
+    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
+    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
+                                /* (PFN of pre-loaded module if           */
+                                /*  SIF_MOD_START_PFN set in flags).      */
+    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
+    int8_t cmd_line[MAX_GUEST_CMDLINE];
+    /* The pfn range here covers both page table and p->m table frames.   */
+    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
+    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
+};
+typedef struct start_info start_info_t;
+
+/* New console union for dom0 introduced in 0x00030203. */
+#if __XEN_INTERFACE_VERSION__ < 0x00030203
+#define console_mfn    console.domU.mfn
+#define console_evtchn console.domU.evtchn
+#endif
+
+/* These flags are passed in the 'flags' field of start_info_t. */
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
+#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
+
+/*
+ * A multiboot module is a package containing modules very similar to a
+ * multiboot module array. The only differences are:
+ * - the array of module descriptors is by convention simply at the beginning
+ *   of the multiboot module,
+ * - addresses in the module descriptors are based on the beginning of the
+ *   multiboot module,
+ * - the number of modules is determined by a termination descriptor that has
+ *   mod_start == 0.
+ *
+ * This permits to both build it statically and reference it in a configuration
+ * file, and let the PV guest easily rebase the addresses to virtual addresses
+ * and at the same time count the number of modules.
+ */
+struct xen_multiboot_mod_list
+{
+    /* Address of first byte of the module */
+    uint32_t mod_start;
+    /* Address of last byte of the module (inclusive) */
+    uint32_t mod_end;
+    /* Address of zero-terminated command line */
+    uint32_t cmdline;
+    /* Unused, must be zero */
+    uint32_t pad;
+};
+
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled 
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 99c8212..846f446 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
  *     extended by an extra 4MB to ensure this.
  */
 
-#define MAX_GUEST_CMDLINE 1024
-struct start_info {
-    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
-    char magic[32];             /* "xen-<version>-<platform>".            */
-    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
-    unsigned long shared_info;  /* MACHINE address of shared info struct. */
-    uint32_t flags;             /* SIF_xxx flags.                         */
-    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
-    uint32_t store_evtchn;      /* Event channel for store communication. */
-    union {
-        struct {
-            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
-            uint32_t  evtchn;   /* Event channel for console page.        */
-        } domU;
-        struct {
-            uint32_t info_off;  /* Offset of console_info struct.         */
-            uint32_t info_size; /* Size of console_info struct from start.*/
-        } dom0;
-    } console;
-    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
-    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
-    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
-    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
-    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
-                                /* (PFN of pre-loaded module if           */
-                                /*  SIF_MOD_START_PFN set in flags).      */
-    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
-    int8_t cmd_line[MAX_GUEST_CMDLINE];
-    /* The pfn range here covers both page table and p->m table frames.   */
-    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
-    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
-};
-typedef struct start_info start_info_t;
-
-/* New console union for dom0 introduced in 0x00030203. */
-#if __XEN_INTERFACE_VERSION__ < 0x00030203
-#define console_mfn    console.domU.mfn
-#define console_evtchn console.domU.evtchn
-#endif
-
-/* These flags are passed in the 'flags' field of start_info_t. */
-#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
-#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
-#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
-#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
-#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
-
-/*
- * A multiboot module is a package containing modules very similar to a
- * multiboot module array. The only differences are:
- * - the array of module descriptors is by convention simply at the beginning
- *   of the multiboot module,
- * - addresses in the module descriptors are based on the beginning of the
- *   multiboot module,
- * - the number of modules is determined by a termination descriptor that has
- *   mod_start == 0.
- *
- * This permits to both build it statically and reference it in a configuration
- * file, and let the PV guest easily rebase the addresses to virtual addresses
- * and at the same time count the number of modules.
- */
-struct xen_multiboot_mod_list
-{
-    /* Address of first byte of the module */
-    uint32_t mod_start;
-    /* Address of last byte of the module (inclusive) */
-    uint32_t mod_end;
-    /* Address of zero-terminated command line */
-    uint32_t cmdline;
-    /* Unused, must be zero */
-    uint32_t pad;
-};
-
 typedef struct dom0_vga_console_info {
     uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d4f1e3..5b0ff35 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -5,10 +5,10 @@
 ?	xenctl_cpumap			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
-!	start_info			xen.h
 ?	vcpu_info			xen.h
 ?	vcpu_time_info			xen.h
 !	cpu_user_regs			arch-x86/xen-@arch@.h
+!	start_info			arch-x86/xen.h
 !	trap_info			arch-x86/xen.h
 ?	cpu_offline_action		arch-x86/xen-mca.h
 ?	mc				arch-x86/xen-mca.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 Thu Feb 14 16:00:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61EF-0004pS-K8; Thu, 14 Feb 2013 16:00:07 +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 1U61EE-0004lH-60
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:00:06 +0000
Received: from [85.158.139.83:43274] by server-12.bemta-5.messagelabs.com id
	3D/77-20195-50A0D115; Thu, 14 Feb 2013 16:00:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360857601!21044569!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30178 invoked from network); 14 Feb 2013 16:00:04 -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;
	14 Feb 2013 16:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149711"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-Dh;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:50 +0000
Message-ID: <1360857591-24979-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Most of this struct is PV MMU specific and it is not used on ARM at all.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xenctrl.h             |    5 +--
 xen/include/public/arch-x86/xen.h |   73 +++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h          |   73 -------------------------------------
 xen/include/xlat.lst              |    2 +-
 4 files changed, 76 insertions(+), 77 deletions(-)

diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 32122fd..9e4a741 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -395,15 +395,14 @@ typedef union
     shared_info_t s;
 } shared_info_any_t;
 
+#if defined(__i386__) || defined(__x86_64__)
 typedef union
 {
-#if defined(__i386__) || defined(__x86_64__)
     start_info_x86_64_t x64;
     start_info_x86_32_t x32;
-#endif
     start_info_t s;
 } start_info_any_t;
-
+#endif
 
 int xc_domain_create(xc_interface *xch,
                      uint32_t ssidref,
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 13c21dc..00f0306 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -147,6 +147,79 @@ DEFINE_XEN_GUEST_HANDLE(trap_info_t);
 
 typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
 
+#define MAX_GUEST_CMDLINE 1024
+struct start_info {
+    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
+    char magic[32];             /* "xen-<version>-<platform>".            */
+    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
+    unsigned long shared_info;  /* MACHINE address of shared info struct. */
+    uint32_t flags;             /* SIF_xxx flags.                         */
+    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
+    uint32_t store_evtchn;      /* Event channel for store communication. */
+    union {
+        struct {
+            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
+            uint32_t  evtchn;   /* Event channel for console page.        */
+        } domU;
+        struct {
+            uint32_t info_off;  /* Offset of console_info struct.         */
+            uint32_t info_size; /* Size of console_info struct from start.*/
+        } dom0;
+    } console;
+    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
+    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
+    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
+    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
+    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
+                                /* (PFN of pre-loaded module if           */
+                                /*  SIF_MOD_START_PFN set in flags).      */
+    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
+    int8_t cmd_line[MAX_GUEST_CMDLINE];
+    /* The pfn range here covers both page table and p->m table frames.   */
+    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
+    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
+};
+typedef struct start_info start_info_t;
+
+/* New console union for dom0 introduced in 0x00030203. */
+#if __XEN_INTERFACE_VERSION__ < 0x00030203
+#define console_mfn    console.domU.mfn
+#define console_evtchn console.domU.evtchn
+#endif
+
+/* These flags are passed in the 'flags' field of start_info_t. */
+#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
+#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
+#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
+
+/*
+ * A multiboot module is a package containing modules very similar to a
+ * multiboot module array. The only differences are:
+ * - the array of module descriptors is by convention simply at the beginning
+ *   of the multiboot module,
+ * - addresses in the module descriptors are based on the beginning of the
+ *   multiboot module,
+ * - the number of modules is determined by a termination descriptor that has
+ *   mod_start == 0.
+ *
+ * This permits to both build it statically and reference it in a configuration
+ * file, and let the PV guest easily rebase the addresses to virtual addresses
+ * and at the same time count the number of modules.
+ */
+struct xen_multiboot_mod_list
+{
+    /* Address of first byte of the module */
+    uint32_t mod_start;
+    /* Address of last byte of the module (inclusive) */
+    uint32_t mod_end;
+    /* Address of zero-terminated command line */
+    uint32_t cmdline;
+    /* Unused, must be zero */
+    uint32_t pad;
+};
+
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled 
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 99c8212..846f446 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
  *     extended by an extra 4MB to ensure this.
  */
 
-#define MAX_GUEST_CMDLINE 1024
-struct start_info {
-    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
-    char magic[32];             /* "xen-<version>-<platform>".            */
-    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
-    unsigned long shared_info;  /* MACHINE address of shared info struct. */
-    uint32_t flags;             /* SIF_xxx flags.                         */
-    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
-    uint32_t store_evtchn;      /* Event channel for store communication. */
-    union {
-        struct {
-            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
-            uint32_t  evtchn;   /* Event channel for console page.        */
-        } domU;
-        struct {
-            uint32_t info_off;  /* Offset of console_info struct.         */
-            uint32_t info_size; /* Size of console_info struct from start.*/
-        } dom0;
-    } console;
-    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
-    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
-    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
-    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
-    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
-                                /* (PFN of pre-loaded module if           */
-                                /*  SIF_MOD_START_PFN set in flags).      */
-    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
-    int8_t cmd_line[MAX_GUEST_CMDLINE];
-    /* The pfn range here covers both page table and p->m table frames.   */
-    unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
-    unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
-};
-typedef struct start_info start_info_t;
-
-/* New console union for dom0 introduced in 0x00030203. */
-#if __XEN_INTERFACE_VERSION__ < 0x00030203
-#define console_mfn    console.domU.mfn
-#define console_evtchn console.domU.evtchn
-#endif
-
-/* These flags are passed in the 'flags' field of start_info_t. */
-#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
-#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
-#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
-#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
-#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
-
-/*
- * A multiboot module is a package containing modules very similar to a
- * multiboot module array. The only differences are:
- * - the array of module descriptors is by convention simply at the beginning
- *   of the multiboot module,
- * - addresses in the module descriptors are based on the beginning of the
- *   multiboot module,
- * - the number of modules is determined by a termination descriptor that has
- *   mod_start == 0.
- *
- * This permits to both build it statically and reference it in a configuration
- * file, and let the PV guest easily rebase the addresses to virtual addresses
- * and at the same time count the number of modules.
- */
-struct xen_multiboot_mod_list
-{
-    /* Address of first byte of the module */
-    uint32_t mod_start;
-    /* Address of last byte of the module (inclusive) */
-    uint32_t mod_end;
-    /* Address of zero-terminated command line */
-    uint32_t cmdline;
-    /* Unused, must be zero */
-    uint32_t pad;
-};
-
 typedef struct dom0_vga_console_info {
     uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d4f1e3..5b0ff35 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -5,10 +5,10 @@
 ?	xenctl_cpumap			xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
-!	start_info			xen.h
 ?	vcpu_info			xen.h
 ?	vcpu_time_info			xen.h
 !	cpu_user_regs			arch-x86/xen-@arch@.h
+!	start_info			arch-x86/xen.h
 !	trap_info			arch-x86/xen.h
 ?	cpu_offline_action		arch-x86/xen-mca.h
 ?	mc				arch-x86/xen-mca.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 Thu Feb 14 16:01:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:01: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 1U61FH-00055t-8a; Thu, 14 Feb 2013 16:01: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 1U61FF-00055U-Gk
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:01:09 +0000
Received: from [85.158.137.99:8286] by server-6.bemta-3.messagelabs.com id
	0C/FC-29959-44A0D115; Thu, 14 Feb 2013 16:01:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360857593!16075040!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32602 invoked from network); 14 Feb 2013 15:59:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:59:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149706"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-9t;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:48 +0000
Message-ID: <1360857591-24979-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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 define __arm__ARM32 as required.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
v2: s/x86_32/arm32/ in the right place
    s/__arm__ARM32/__arm___ARM32/
    Update gitignore
---
 .gitignore                               |    2 +-
 tools/include/xen-foreign/Makefile       |    4 ++--
 tools/include/xen-foreign/mkheader.py    |    6 +++++-
 tools/include/xen-foreign/reference.size |    2 +-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index 125a582..73c5b77 100644
--- a/.gitignore
+++ b/.gitignore
@@ -363,7 +363,7 @@ tools/include/xen-foreign/checker.c
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
-tools/include/xen-foreign/arm.h
+tools/include/xen-foreign/arm32.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..5bc2d46 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..eee28f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,15 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["arm32"] = """
+#define __arm___ARM32 1
+""";
+
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..9f1bfac 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,5 +1,5 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32  x86_32  x86_64
 
 start_info                |       -    1112    1168
 trap_info                 |       -       8      16
-- 
1.7.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 Feb 14 16:01:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:01: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 1U61FH-00055t-8a; Thu, 14 Feb 2013 16:01: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 1U61FF-00055U-Gk
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:01:09 +0000
Received: from [85.158.137.99:8286] by server-6.bemta-3.messagelabs.com id
	0C/FC-29959-44A0D115; Thu, 14 Feb 2013 16:01:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360857593!16075040!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32602 invoked from network); 14 Feb 2013 15:59:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 15:59:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149706"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-9t;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:48 +0000
Message-ID: <1360857591-24979-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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 define __arm__ARM32 as required.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
---
v2: s/x86_32/arm32/ in the right place
    s/__arm__ARM32/__arm___ARM32/
    Update gitignore
---
 .gitignore                               |    2 +-
 tools/include/xen-foreign/Makefile       |    4 ++--
 tools/include/xen-foreign/mkheader.py    |    6 +++++-
 tools/include/xen-foreign/reference.size |    2 +-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index 125a582..73c5b77 100644
--- a/.gitignore
+++ b/.gitignore
@@ -363,7 +363,7 @@ tools/include/xen-foreign/checker.c
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
-tools/include/xen-foreign/arm.h
+tools/include/xen-foreign/arm32.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..5bc2d46 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..eee28f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,15 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["arm32"] = """
+#define __arm___ARM32 1
+""";
+
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..9f1bfac 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,5 +1,5 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32  x86_32  x86_64
 
 start_info                |       -    1112    1168
 trap_info                 |       -       8      16
-- 
1.7.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 Feb 14 16:03:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61H9-0005PM-Pp; Thu, 14 Feb 2013 16:03: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 1U61H8-0005P2-BG
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:03:06 +0000
Received: from [85.158.137.99:35653] by server-8.bemta-3.messagelabs.com id
	F6/16-25687-9BA0D115; Thu, 14 Feb 2013 16:03:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360857593!16075040!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 778 invoked from network); 14 Feb 2013 16:00:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:00:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149709"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-Ei;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:51 +0000
Message-ID: <1360857591-24979-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen: arm: include public/xen.h in foreign
	interface checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

mkheader.py doesn't cope with
	structr foo { };
so add a newline.

Define unsigned long and long to a non-existent type on ARM so as to catch
their use.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-foreign/Makefile       |    2 +-
 tools/include/xen-foreign/mkheader.py    |    4 ++--
 tools/include/xen-foreign/reference.size |   10 +++++-----
 xen/include/public/arch-arm.h            |    8 +++++---
 4 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 5bc2d46..53cc6b4 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index e3e61f3..b7c34b1 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -18,8 +18,8 @@ footer = {};
 
 #arm
 inttypes["arm32"] = {
-    "unsigned long" : "uint32_t",
-    "long"          : "uint32_t",
+    "unsigned long" : "__danger_unsigned_long_on_arm32",
+    "long"          : "__danger_long_on_arm32",
     "xen_pfn_t"     : "uint64_t",
     "xen_ulong_t"   : "uint64_t",
 };
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 9f1bfac..0e5529d 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -5,9 +5,9 @@ start_info                |       -    1112    1168
 trap_info                 |       -       8      16
 cpu_user_regs             |     160      68     200
 vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+arch_vcpu_info            |       0      24      16
+vcpu_time_info            |      32      32      32
+vcpu_info                 |      48      64      64
+arch_shared_info          |       0     268     280
+shared_info               |    1088    2584    3368
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index d8788f2..8dd9062 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -159,14 +159,16 @@ struct vcpu_guest_context {
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
-struct arch_vcpu_info { };
+struct arch_vcpu_info {
+};
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
-struct arch_shared_info { };
+struct arch_shared_info {
+};
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif /* ifndef __ASSEMBLY __ */
+#endif
 
 /* PSR bits (CPSR, SPSR)*/
 
-- 
1.7.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 Feb 14 16:03:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61H9-0005PM-Pp; Thu, 14 Feb 2013 16:03: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 1U61H8-0005P2-BG
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:03:06 +0000
Received: from [85.158.137.99:35653] by server-8.bemta-3.messagelabs.com id
	F6/16-25687-9BA0D115; Thu, 14 Feb 2013 16:03:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360857593!16075040!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 778 invoked from network); 14 Feb 2013 16:00:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:00:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7149709"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 15:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 10:59:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61Dz-0000M1-Ei;
	Thu, 14 Feb 2013 15:59:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 15:59:51 +0000
Message-ID: <1360857591-24979-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen: arm: include public/xen.h in foreign
	interface checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

mkheader.py doesn't cope with
	structr foo { };
so add a newline.

Define unsigned long and long to a non-existent type on ARM so as to catch
their use.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-foreign/Makefile       |    2 +-
 tools/include/xen-foreign/mkheader.py    |    4 ++--
 tools/include/xen-foreign/reference.size |   10 +++++-----
 xen/include/public/arch-arm.h            |    8 +++++---
 4 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 5bc2d46..53cc6b4 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index e3e61f3..b7c34b1 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -18,8 +18,8 @@ footer = {};
 
 #arm
 inttypes["arm32"] = {
-    "unsigned long" : "uint32_t",
-    "long"          : "uint32_t",
+    "unsigned long" : "__danger_unsigned_long_on_arm32",
+    "long"          : "__danger_long_on_arm32",
     "xen_pfn_t"     : "uint64_t",
     "xen_ulong_t"   : "uint64_t",
 };
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 9f1bfac..0e5529d 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -5,9 +5,9 @@ start_info                |       -    1112    1168
 trap_info                 |       -       8      16
 cpu_user_regs             |     160      68     200
 vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+arch_vcpu_info            |       0      24      16
+vcpu_time_info            |      32      32      32
+vcpu_info                 |      48      64      64
+arch_shared_info          |       0     268     280
+shared_info               |    1088    2584    3368
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index d8788f2..8dd9062 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -159,14 +159,16 @@ struct vcpu_guest_context {
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
-struct arch_vcpu_info { };
+struct arch_vcpu_info {
+};
 typedef struct arch_vcpu_info arch_vcpu_info_t;
 
-struct arch_shared_info { };
+struct arch_shared_info {
+};
 typedef struct arch_shared_info arch_shared_info_t;
 typedef uint64_t xen_callback_t;
 
-#endif /* ifndef __ASSEMBLY __ */
+#endif
 
 /* PSR bits (CPSR, SPSR)*/
 
-- 
1.7.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 Feb 14 16:17:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61UJ-0005vf-C7; Thu, 14 Feb 2013 16:16: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 1U61UI-0005va-7C
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:16:42 +0000
Received: from [85.158.143.99:53412] by server-3.bemta-4.messagelabs.com id
	24/37-08920-9ED0D115; Thu, 14 Feb 2013 16:16:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360858595!20032668!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8558 invoked from network); 14 Feb 2013 16:16:36 -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;
	14 Feb 2013 16:16:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7153715"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:16:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:16:34 -0500
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 1U61UA-0000bf-6V	for xen-devel@lists.xen.org;
	Thu, 14 Feb 2013 16:16:34 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U61U9-0000vQ-Uc	for
	xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:16:33 +0000
MIME-Version: 1.0
X-Mercurial-Node: 68308aac7872c07631cb8424367907a11811ec3d
Message-ID: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 16:16:33 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 1360858577 0
# Node ID 68308aac7872c07631cb8424367907a11811ec3d
# Parent  5a84cc531072378e6e5ff89b4c0e9a35000dc56f
xen/xenoprof: avoid division by 0.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5a84cc531072 -r 68308aac7872 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
+++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
@@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
 #endif
 
     /* reduce max_samples if necessary to limit pages allocated */
-    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
+    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
     max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
     if ( (unsigned)max_samples > max_max_samples )
         max_samples = max_max_samples;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:17:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61UJ-0005vf-C7; Thu, 14 Feb 2013 16:16: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 1U61UI-0005va-7C
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:16:42 +0000
Received: from [85.158.143.99:53412] by server-3.bemta-4.messagelabs.com id
	24/37-08920-9ED0D115; Thu, 14 Feb 2013 16:16:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1360858595!20032668!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8558 invoked from network); 14 Feb 2013 16:16:36 -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;
	14 Feb 2013 16:16:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7153715"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:16:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:16:34 -0500
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 1U61UA-0000bf-6V	for xen-devel@lists.xen.org;
	Thu, 14 Feb 2013 16:16:34 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1U61U9-0000vQ-Uc	for
	xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:16:33 +0000
MIME-Version: 1.0
X-Mercurial-Node: 68308aac7872c07631cb8424367907a11811ec3d
Message-ID: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 14 Feb 2013 16:16:33 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 1360858577 0
# Node ID 68308aac7872c07631cb8424367907a11811ec3d
# Parent  5a84cc531072378e6e5ff89b4c0e9a35000dc56f
xen/xenoprof: avoid division by 0.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5a84cc531072 -r 68308aac7872 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
+++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
@@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
 #endif
 
     /* reduce max_samples if necessary to limit pages allocated */
-    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
+    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
     max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
     if ( (unsigned)max_samples > max_max_samples )
         max_samples = max_max_samples;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:35:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61mA-0006Hx-6W; Thu, 14 Feb 2013 16:35:10 +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 1U61m9-0006Hs-FP
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:35:09 +0000
Received: from [193.109.254.147:17218] by server-7.bemta-14.messagelabs.com id
	58/AD-13581-C321D115; Thu, 14 Feb 2013 16:35:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360859620!2322042!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28251 invoked from network); 14 Feb 2013 16:33:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 16:33:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 16:33:39 +0000
Message-Id: <511D202E02000078000BE68A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 16:34:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
In-Reply-To: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
> --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
> @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
>  #endif
>  
>      /* reduce max_samples if necessary to limit pages allocated */
> -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
> +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
>      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
>      if ( (unsigned)max_samples > max_max_samples )
>          max_samples = max_max_samples;

I think the function would better return an error in that case. After
all there's little point in setting up anything when we for sure don't
know how many vCPU-s a domain is going to have.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:35:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61mA-0006Hx-6W; Thu, 14 Feb 2013 16:35:10 +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 1U61m9-0006Hs-FP
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:35:09 +0000
Received: from [193.109.254.147:17218] by server-7.bemta-14.messagelabs.com id
	58/AD-13581-C321D115; Thu, 14 Feb 2013 16:35:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360859620!2322042!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28251 invoked from network); 14 Feb 2013 16:33:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 16:33:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 16:33:39 +0000
Message-Id: <511D202E02000078000BE68A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 16:34:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
In-Reply-To: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
> --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
> @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
>  #endif
>  
>      /* reduce max_samples if necessary to limit pages allocated */
> -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
> +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
>      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
>      if ( (unsigned)max_samples > max_max_samples )
>          max_samples = max_max_samples;

I think the function would better return an error in that case. After
all there's little point in setting up anything when we for sure don't
know how many vCPU-s a domain is going to have.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:38:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U61of-0006SG-OT; Thu, 14 Feb 2013 16:37:45 +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 1U61od-0006S4-NJ
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:37:43 +0000
Received: from [85.158.139.211:55074] by server-11.bemta-5.messagelabs.com id
	1F/84-19159-6D21D115; Thu, 14 Feb 2013 16:37:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360859860!19792028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22833 invoked from network); 14 Feb 2013 16:37:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527739"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-Pk;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:10 +0000
Message-ID: <1360859833-16498-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4/7] xen/arm: drain all the outstanding
	interrupts before returning from gic_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/gic.c |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ff186d2..1c8219d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -592,16 +592,22 @@ out:
 /* Accept an interrupt from the GIC and dispatch its handler */
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
-    uint32_t intack = GICC[GICC_IAR];
-    unsigned int irq = intack & GICC_IA_IRQ;
+    uint32_t intack;
+    unsigned int irq;
 
-    local_irq_enable();
 
-    if ( irq == 1023 )
-        /* Spurious interrupt */
-        return;
+    do  {
+        intack = GICC[GICC_IAR];
+        irq = intack & GICC_IA_IRQ;
+        local_irq_enable();
+
+        if (likely(irq < 1021))
+            do_IRQ(regs, irq, is_fiq);
+        else
+            break;
 
-    do_IRQ(regs, irq, is_fiq);
+        local_irq_disable();
+    } while (1);
 }
 
 int gicv_setup(struct domain *d)
-- 
1.7.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 Feb 14 16:38:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U61of-0006SG-OT; Thu, 14 Feb 2013 16:37:45 +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 1U61od-0006S4-NJ
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:37:43 +0000
Received: from [85.158.139.211:55074] by server-11.bemta-5.messagelabs.com id
	1F/84-19159-6D21D115; Thu, 14 Feb 2013 16:37:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360859860!19792028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22833 invoked from network); 14 Feb 2013 16:37:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527739"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-Pk;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:10 +0000
Message-ID: <1360859833-16498-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4/7] xen/arm: drain all the outstanding
	interrupts before returning from gic_interrupt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/gic.c |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ff186d2..1c8219d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -592,16 +592,22 @@ out:
 /* Accept an interrupt from the GIC and dispatch its handler */
 void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 {
-    uint32_t intack = GICC[GICC_IAR];
-    unsigned int irq = intack & GICC_IA_IRQ;
+    uint32_t intack;
+    unsigned int irq;
 
-    local_irq_enable();
 
-    if ( irq == 1023 )
-        /* Spurious interrupt */
-        return;
+    do  {
+        intack = GICC[GICC_IAR];
+        irq = intack & GICC_IA_IRQ;
+        local_irq_enable();
+
+        if (likely(irq < 1021))
+            do_IRQ(regs, irq, is_fiq);
+        else
+            break;
 
-    do_IRQ(regs, irq, is_fiq);
+        local_irq_disable();
+    } while (1);
 }
 
 int gicv_setup(struct domain *d)
-- 
1.7.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 Feb 14 16:38:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61oh-0006Sb-Hn; Thu, 14 Feb 2013 16:37:47 +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 1U61og-0006S5-Gl
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:37:46 +0000
Received: from [85.158.139.211:36528] by server-15.bemta-5.messagelabs.com id
	48/B3-18914-7D21D115; Thu, 14 Feb 2013 16:37:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360859860!19792028!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22905 invoked from network); 14 Feb 2013 16:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527742"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-Qf;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:12 +0000
Message-ID: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 6/7] xen/arm: introduce gic callbacks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 callbacks to receive notifications from the GIC when a
specific IRQ has been EOI'd by the guest.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c        |   12 ++++++++++++
 xen/arch/arm/setup.c      |    1 +
 xen/include/asm-arm/gic.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1c8219d..0ecc0f1 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -52,6 +52,7 @@ static struct {
 static irq_desc_t irq_desc[NR_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
 static DEFINE_PER_CPU(uint64_t, lr_mask);
+static gic_callback_fn_t gic_callbacks[NR_IRQS];
 
 unsigned nr_lrs;
 
@@ -619,6 +620,12 @@ int gicv_setup(struct domain *d)
                         gic.vbase);
 }
 
+void register_gic_callback(int irq, gic_callback_fn_t fn)
+{
+    ASSERT(irq < NR_IRQS);
+    gic_callbacks[irq] = fn;
+}
+
 static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
     int i = 0, virq;
@@ -655,6 +662,11 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         list_del_init(&p->inflight);
         spin_unlock_irq(&v->arch.vgic.lock);
 
+        if ( gic_callbacks[virq] != NULL )
+        {
+            gic_callbacks[virq](v, virq);
+        }
+
         i++;
     }
 }
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..5680c73 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,7 @@
 #include <asm/vfp.h>
 #include <asm/early_printk.h>
 #include <asm/gic.h>
+#include "vtimer.h"
 
 static __used void init_done(void)
 {
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index bf30fbd..f4b0324 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -153,6 +153,11 @@ extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern int gicv_setup(struct domain *d);
 
+typedef void (*gic_callback_fn_t)(struct vcpu *v, int irq);
+/* register a per-irq callback: the gic driver is going to call the
+ * callback when the guest EOIs that particular irq. */
+void register_gic_callback(int irq, gic_callback_fn_t fn);
+
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(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 Thu Feb 14 16:38:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61oh-0006Sb-Hn; Thu, 14 Feb 2013 16:37:47 +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 1U61og-0006S5-Gl
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:37:46 +0000
Received: from [85.158.139.211:36528] by server-15.bemta-5.messagelabs.com id
	48/B3-18914-7D21D115; Thu, 14 Feb 2013 16:37:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360859860!19792028!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22905 invoked from network); 14 Feb 2013 16:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527742"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-Qf;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:12 +0000
Message-ID: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 6/7] xen/arm: introduce gic callbacks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 callbacks to receive notifications from the GIC when a
specific IRQ has been EOI'd by the guest.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c        |   12 ++++++++++++
 xen/arch/arm/setup.c      |    1 +
 xen/include/asm-arm/gic.h |    5 +++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1c8219d..0ecc0f1 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -52,6 +52,7 @@ static struct {
 static irq_desc_t irq_desc[NR_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
 static DEFINE_PER_CPU(uint64_t, lr_mask);
+static gic_callback_fn_t gic_callbacks[NR_IRQS];
 
 unsigned nr_lrs;
 
@@ -619,6 +620,12 @@ int gicv_setup(struct domain *d)
                         gic.vbase);
 }
 
+void register_gic_callback(int irq, gic_callback_fn_t fn)
+{
+    ASSERT(irq < NR_IRQS);
+    gic_callbacks[irq] = fn;
+}
+
 static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
     int i = 0, virq;
@@ -655,6 +662,11 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         list_del_init(&p->inflight);
         spin_unlock_irq(&v->arch.vgic.lock);
 
+        if ( gic_callbacks[virq] != NULL )
+        {
+            gic_callbacks[virq](v, virq);
+        }
+
         i++;
     }
 }
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..5680c73 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,7 @@
 #include <asm/vfp.h>
 #include <asm/early_printk.h>
 #include <asm/gic.h>
+#include "vtimer.h"
 
 static __used void init_done(void)
 {
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index bf30fbd..f4b0324 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -153,6 +153,11 @@ extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
 extern int gicv_setup(struct domain *d);
 
+typedef void (*gic_callback_fn_t)(struct vcpu *v, int irq);
+/* register a per-irq callback: the gic driver is going to call the
+ * callback when the guest EOIs that particular irq. */
+void register_gic_callback(int irq, gic_callback_fn_t fn);
+
 /* Context switch */
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(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 Thu Feb 14 16:38:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61oh-0006SU-4o; Thu, 14 Feb 2013 16:37:47 +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 1U61oe-0006SA-Ql
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:37:45 +0000
Received: from [85.158.139.211:36652] by server-7.bemta-5.messagelabs.com id
	E9/33-11121-7D21D115; Thu, 14 Feb 2013 16:37:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360859861!22492608!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 14 Feb 2013 16:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527743"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-QC;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:11 +0000
Message-ID: <1360859833-16498-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 5/7] xen/vtimer: fixes and 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

Do not try to save and restore the vtimer for the idle domain.

Inject the vtimer interrupt from the Xen timer handler, taking care of
setting the timer as masked in the ctl field, so that at restore time it
is not going to fire the interrupt again.

No need to disable the vtimer before writing the new offset on restore:
the vtimer is already disabled.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 85201b5..f4326f8 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -40,7 +40,8 @@ static void phys_timer_expired(void *data)
 static void virt_timer_expired(void *data)
 {
     struct vtimer *t = data;
-    vcpu_wake(t->v);
+    t->ctl |= CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(t->v, 27, 1);
 }
  
 int vcpu_vtimer_init(struct vcpu *v)
@@ -73,6 +74,9 @@ void vcpu_timer_destroy(struct vcpu *v)
 
 int virt_timer_save(struct vcpu *v)
 {
+    if ( is_idle_domain(v->domain) )
+        return 0;
+
     v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
     WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
@@ -86,9 +90,11 @@ int virt_timer_save(struct vcpu *v)
 
 int virt_timer_restore(struct vcpu *v)
 {
+    if ( is_idle_domain(v->domain) )
+        return 0;
+
     stop_timer(&v->arch.virt_timer.timer);
 
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     WRITE_CP64(v->arch.virt_timer.offset, CNTVOFF);
     WRITE_CP64(v->arch.virt_timer.cval, CNTV_CVAL);
     WRITE_CP32(v->arch.virt_timer.ctl, CNTV_CTL);
-- 
1.7.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 Feb 14 16:38:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61oh-0006SU-4o; Thu, 14 Feb 2013 16:37:47 +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 1U61oe-0006SA-Ql
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:37:45 +0000
Received: from [85.158.139.211:36652] by server-7.bemta-5.messagelabs.com id
	E9/33-11121-7D21D115; Thu, 14 Feb 2013 16:37:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360859861!22492608!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 14 Feb 2013 16:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527743"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-QC;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:11 +0000
Message-ID: <1360859833-16498-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 5/7] xen/vtimer: fixes and 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

Do not try to save and restore the vtimer for the idle domain.

Inject the vtimer interrupt from the Xen timer handler, taking care of
setting the timer as masked in the ctl field, so that at restore time it
is not going to fire the interrupt again.

No need to disable the vtimer before writing the new offset on restore:
the vtimer is already disabled.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 85201b5..f4326f8 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -40,7 +40,8 @@ static void phys_timer_expired(void *data)
 static void virt_timer_expired(void *data)
 {
     struct vtimer *t = data;
-    vcpu_wake(t->v);
+    t->ctl |= CNTx_CTL_MASK;
+    vgic_vcpu_inject_irq(t->v, 27, 1);
 }
  
 int vcpu_vtimer_init(struct vcpu *v)
@@ -73,6 +74,9 @@ void vcpu_timer_destroy(struct vcpu *v)
 
 int virt_timer_save(struct vcpu *v)
 {
+    if ( is_idle_domain(v->domain) )
+        return 0;
+
     v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
     WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
@@ -86,9 +90,11 @@ int virt_timer_save(struct vcpu *v)
 
 int virt_timer_restore(struct vcpu *v)
 {
+    if ( is_idle_domain(v->domain) )
+        return 0;
+
     stop_timer(&v->arch.virt_timer.timer);
 
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     WRITE_CP64(v->arch.virt_timer.offset, CNTVOFF);
     WRITE_CP64(v->arch.virt_timer.cval, CNTV_CVAL);
     WRITE_CP32(v->arch.virt_timer.ctl, CNTV_CTL);
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61p8-0006Xo-0b; Thu, 14 Feb 2013 16:38:14 +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 1U61p6-0006X9-OY
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:12 +0000
Received: from [193.109.254.147:5279] by server-7.bemta-14.messagelabs.com id
	0D/01-13581-4F21D115; Thu, 14 Feb 2013 16:38:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4424 invoked from network); 14 Feb 2013 16:37:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527738"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-Nk;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:09 +0000
Message-ID: <1360859833-16498-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3/7] xen/arm: make lr_mask per_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

lr_mask, keeping track of the LR registers in use, should be a per_cpu
variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |   23 +++++++++++------------
 1 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 7627ad8..ff186d2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -47,11 +47,11 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
-    uint64_t lr_mask;
 } gic;
 
 static irq_desc_t irq_desc[NR_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
+static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 unsigned nr_lrs;
 
@@ -68,7 +68,7 @@ void gic_save_state(struct vcpu *v)
     spin_lock_irq(&gic.lock);
     for ( i=0; i<nr_lrs; i++)
         v->arch.gic_lr[i] = GICH[GICH_LR + i];
-    v->arch.lr_mask = gic.lr_mask;
+    v->arch.lr_mask = this_cpu(lr_mask);
     spin_unlock_irq(&gic.lock);
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
@@ -83,7 +83,7 @@ void gic_restore_state(struct vcpu *v)
         return;
 
     spin_lock_irq(&gic.lock);
-    gic.lr_mask = v->arch.lr_mask;
+    this_cpu(lr_mask) = v->arch.lr_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     spin_unlock_irq(&gic.lock);
@@ -305,6 +305,7 @@ static void __cpuinit gic_hyp_init(void)
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
 
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    this_cpu(lr_mask) = 0ULL;
 }
 
 static void __cpuinit gic_hyp_disable(void)
@@ -352,8 +353,6 @@ void __init gic_init(void)
     gic_cpu_init();
     gic_hyp_init();
 
-    gic.lr_mask = 0ULL;
-
     spin_unlock(&gic.lock);
 }
 
@@ -483,9 +482,9 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
     {
-        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
+        i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
-            set_bit(i, &gic.lr_mask);
+            set_bit(i, &this_cpu(lr_mask));
             gic_set_lr(i, virtual_irq, state, priority);
             goto out;
         }
@@ -517,13 +516,13 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
-        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
+        i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if ( i >= nr_lrs ) return;
 
         spin_lock_irq(&gic.lock);
         gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
         list_del_init(&p->lr_queue);
-        set_bit(i, &gic.lr_mask);
+        set_bit(i, &this_cpu(lr_mask));
         spin_unlock_irq(&gic.lock);
     }
 
@@ -549,7 +548,7 @@ static void gic_inject_irq_stop(void)
 
 void gic_inject(void)
 {
-    if (!gic.lr_mask)
+    if (!this_cpu(lr_mask))
         gic_inject_irq_stop();
     else
         gic_inject_irq_start();
@@ -629,13 +628,13 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
-        clear_bit(i, &gic.lr_mask);
+        clear_bit(i, &this_cpu(lr_mask));
 
         if ( !list_empty(&v->arch.vgic.lr_pending) ) {
             p = list_entry(v->arch.vgic.lr_pending.next, typeof(*p), lr_queue);
             gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
             list_del_init(&p->lr_queue);
-            set_bit(i, &gic.lr_mask);
+            set_bit(i, &this_cpu(lr_mask));
         } else {
             gic_inject_irq_stop();
         }
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61p8-0006Xo-0b; Thu, 14 Feb 2013 16:38:14 +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 1U61p6-0006X9-OY
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:12 +0000
Received: from [193.109.254.147:5279] by server-7.bemta-14.messagelabs.com id
	0D/01-13581-4F21D115; Thu, 14 Feb 2013 16:38:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4424 invoked from network); 14 Feb 2013 16:37:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527738"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-Nk;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:09 +0000
Message-ID: <1360859833-16498-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3/7] xen/arm: make lr_mask per_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

lr_mask, keeping track of the LR registers in use, should be a per_cpu
variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |   23 +++++++++++------------
 1 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 7627ad8..ff186d2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -47,11 +47,11 @@ static struct {
     unsigned int lines;
     unsigned int cpus;
     spinlock_t lock;
-    uint64_t lr_mask;
 } gic;
 
 static irq_desc_t irq_desc[NR_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
+static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 unsigned nr_lrs;
 
@@ -68,7 +68,7 @@ void gic_save_state(struct vcpu *v)
     spin_lock_irq(&gic.lock);
     for ( i=0; i<nr_lrs; i++)
         v->arch.gic_lr[i] = GICH[GICH_LR + i];
-    v->arch.lr_mask = gic.lr_mask;
+    v->arch.lr_mask = this_cpu(lr_mask);
     spin_unlock_irq(&gic.lock);
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
@@ -83,7 +83,7 @@ void gic_restore_state(struct vcpu *v)
         return;
 
     spin_lock_irq(&gic.lock);
-    gic.lr_mask = v->arch.lr_mask;
+    this_cpu(lr_mask) = v->arch.lr_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
     spin_unlock_irq(&gic.lock);
@@ -305,6 +305,7 @@ static void __cpuinit gic_hyp_init(void)
     nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
 
     GICH[GICH_MISR] = GICH_MISR_EOI;
+    this_cpu(lr_mask) = 0ULL;
 }
 
 static void __cpuinit gic_hyp_disable(void)
@@ -352,8 +353,6 @@ void __init gic_init(void)
     gic_cpu_init();
     gic_hyp_init();
 
-    gic.lr_mask = 0ULL;
-
     spin_unlock(&gic.lock);
 }
 
@@ -483,9 +482,9 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
     {
-        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
+        i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
-            set_bit(i, &gic.lr_mask);
+            set_bit(i, &this_cpu(lr_mask));
             gic_set_lr(i, virtual_irq, state, priority);
             goto out;
         }
@@ -517,13 +516,13 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
-        i = find_first_zero_bit(&gic.lr_mask, nr_lrs);
+        i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if ( i >= nr_lrs ) return;
 
         spin_lock_irq(&gic.lock);
         gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
         list_del_init(&p->lr_queue);
-        set_bit(i, &gic.lr_mask);
+        set_bit(i, &this_cpu(lr_mask));
         spin_unlock_irq(&gic.lock);
     }
 
@@ -549,7 +548,7 @@ static void gic_inject_irq_stop(void)
 
 void gic_inject(void)
 {
-    if (!gic.lr_mask)
+    if (!this_cpu(lr_mask))
         gic_inject_irq_stop();
     else
         gic_inject_irq_start();
@@ -629,13 +628,13 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
         lr = GICH[GICH_LR + i];
         virq = lr & GICH_LR_VIRTUAL_MASK;
         GICH[GICH_LR + i] = 0;
-        clear_bit(i, &gic.lr_mask);
+        clear_bit(i, &this_cpu(lr_mask));
 
         if ( !list_empty(&v->arch.vgic.lr_pending) ) {
             p = list_entry(v->arch.vgic.lr_pending.next, typeof(*p), lr_queue);
             gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
             list_del_init(&p->lr_queue);
-            set_bit(i, &gic.lr_mask);
+            set_bit(i, &this_cpu(lr_mask));
         } else {
             gic_inject_irq_stop();
         }
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61p9-0006YZ-QP; Thu, 14 Feb 2013 16:38:15 +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 1U61p7-0006Xa-WE
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:14 +0000
Received: from [193.109.254.147:47151] by server-11.bemta-14.messagelabs.com
	id C3/A3-30685-5F21D115; Thu, 14 Feb 2013 16:38:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4386 invoked from network); 14 Feb 2013 16:37:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527737"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-KO;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:07 +0000
Message-ID: <1360859833-16498-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/7] xen/arm: /spin_lock_irq/spin_lock_irqsave
	in gic_set_guest_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

gic_set_guest_irq can be called with irq disabled

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 165287c..7627ad8 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -477,8 +477,9 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 {
     int i;
     struct pending_irq *iter, *n;
+    unsigned long flags;
 
-    spin_lock_irq(&gic.lock);
+    spin_lock_irqsave(&gic.lock, flags);
 
     if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
     {
@@ -505,7 +506,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
 
 out:
-    spin_unlock_irq(&gic.lock);
+    spin_unlock_irqrestore(&gic.lock, flags);
     return;
 }
 
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61p9-0006YZ-QP; Thu, 14 Feb 2013 16:38:15 +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 1U61p7-0006Xa-WE
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:14 +0000
Received: from [193.109.254.147:47151] by server-11.bemta-14.messagelabs.com
	id C3/A3-30685-5F21D115; Thu, 14 Feb 2013 16:38:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4386 invoked from network); 14 Feb 2013 16:37:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527737"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-KO;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:07 +0000
Message-ID: <1360859833-16498-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/7] xen/arm: /spin_lock_irq/spin_lock_irqsave
	in gic_set_guest_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

gic_set_guest_irq can be called with irq disabled

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 165287c..7627ad8 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -477,8 +477,9 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 {
     int i;
     struct pending_irq *iter, *n;
+    unsigned long flags;
 
-    spin_lock_irq(&gic.lock);
+    spin_lock_irqsave(&gic.lock, flags);
 
     if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
     {
@@ -505,7 +506,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
     list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
 
 out:
-    spin_unlock_irq(&gic.lock);
+    spin_unlock_irqrestore(&gic.lock, flags);
     return;
 }
 
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61p9-0006YO-E8; Thu, 14 Feb 2013 16:38:15 +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 1U61p7-0006XE-72
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:13 +0000
Received: from [193.109.254.147:5296] by server-12.bemta-14.messagelabs.com id
	16/37-32582-4F21D115; Thu, 14 Feb 2013 16:38:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4500 invoked from network); 14 Feb 2013 16:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527744"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-R8;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:13 +0000
Message-ID: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.

Stop the Xen timer if the pending bit is already set and the phys_timer
is masked.

Register a gic callback to clear the pending bit in the ctl register.

Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/setup.c         |    1 +
 xen/arch/arm/vtimer.c        |   30 ++++++++++++++++++++++++------
 xen/arch/arm/vtimer.h        |    2 ++
 xen/include/asm-arm/domain.h |    4 ++--
 4 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5680c73..f1d15bb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -398,6 +398,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     init_timer_interrupt();
 
     timer_init();
+    init_ptimer();
 
     init_idle_domain();
 
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index f4326f8..e033191 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -18,6 +18,7 @@
  */
 
 #include <xen/config.h>
+#include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/timer.h>
 #include <xen/sched.h>
@@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
 {
     struct vtimer *t = data;
     t->ctl |= CNTx_CTL_PENDING;
-    t->ctl &= ~CNTx_CTL_MASK;
-    vgic_vcpu_inject_irq(t->v, 30, 1);
+    if ( !(t->ctl & CNTx_CTL_MASK) )
+        vgic_vcpu_inject_irq(t->v, 30, 1);
 }
 
 static void virt_timer_expired(void *data)
@@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
     vgic_vcpu_inject_irq(t->v, 27, 1);
 }
  
+static void phys_timer_gic_callback(struct vcpu *v, int irq)
+{
+    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
+}
+
+int __init init_ptimer(void)
+{
+    register_gic_callback(30, phys_timer_gic_callback);
+    return 0;
+}
+
 int vcpu_vtimer_init(struct vcpu *v)
 {
     struct vtimer *t = &v->arch.phys_timer;
@@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         {
             v->arch.phys_timer.ctl = *r;
 
-            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
+            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
+                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
+                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
+                stop_timer(&v->arch.phys_timer.timer);
+            else
             {
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
             }
-            else
-                stop_timer(&v->arch.phys_timer.timer);
         }
 
         return 1;
@@ -139,7 +153,11 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         else
         {
             v->arch.phys_timer.cval = now + ticks_to_ns(*r);
-            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
+            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
+                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
+                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
+                stop_timer(&v->arch.phys_timer.timer);
+            else
             {
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
index 43eef69..cbe0470 100644
--- a/xen/arch/arm/vtimer.h
+++ b/xen/arch/arm/vtimer.h
@@ -26,6 +26,8 @@ extern int virt_timer_save(struct vcpu *v);
 extern int virt_timer_restore(struct vcpu *v);
 extern void vcpu_timer_destroy(struct vcpu *v);
 
+int init_ptimer(void);
+
 #endif
 
 /*
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 577ad19..3e9cc37 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -75,8 +75,8 @@ struct vtimer {
         int irq;
         struct timer timer;
         uint32_t ctl;
-        s_time_t offset;
-        s_time_t cval;
+        uint64_t offset;
+        uint64_t cval;
 };
 
 struct arch_vcpu
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61p9-0006YO-E8; Thu, 14 Feb 2013 16:38:15 +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 1U61p7-0006XE-72
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:13 +0000
Received: from [193.109.254.147:5296] by server-12.bemta-14.messagelabs.com id
	16/37-32582-4F21D115; Thu, 14 Feb 2013 16:38:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4500 invoked from network); 14 Feb 2013 16:37:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527744"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-R8;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:13 +0000
Message-ID: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.

Stop the Xen timer if the pending bit is already set and the phys_timer
is masked.

Register a gic callback to clear the pending bit in the ctl register.

Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/setup.c         |    1 +
 xen/arch/arm/vtimer.c        |   30 ++++++++++++++++++++++++------
 xen/arch/arm/vtimer.h        |    2 ++
 xen/include/asm-arm/domain.h |    4 ++--
 4 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5680c73..f1d15bb 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -398,6 +398,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     init_timer_interrupt();
 
     timer_init();
+    init_ptimer();
 
     init_idle_domain();
 
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index f4326f8..e033191 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -18,6 +18,7 @@
  */
 
 #include <xen/config.h>
+#include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/timer.h>
 #include <xen/sched.h>
@@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
 {
     struct vtimer *t = data;
     t->ctl |= CNTx_CTL_PENDING;
-    t->ctl &= ~CNTx_CTL_MASK;
-    vgic_vcpu_inject_irq(t->v, 30, 1);
+    if ( !(t->ctl & CNTx_CTL_MASK) )
+        vgic_vcpu_inject_irq(t->v, 30, 1);
 }
 
 static void virt_timer_expired(void *data)
@@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
     vgic_vcpu_inject_irq(t->v, 27, 1);
 }
  
+static void phys_timer_gic_callback(struct vcpu *v, int irq)
+{
+    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
+}
+
+int __init init_ptimer(void)
+{
+    register_gic_callback(30, phys_timer_gic_callback);
+    return 0;
+}
+
 int vcpu_vtimer_init(struct vcpu *v)
 {
     struct vtimer *t = &v->arch.phys_timer;
@@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         {
             v->arch.phys_timer.ctl = *r;
 
-            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
+            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
+                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
+                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
+                stop_timer(&v->arch.phys_timer.timer);
+            else
             {
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
             }
-            else
-                stop_timer(&v->arch.phys_timer.timer);
         }
 
         return 1;
@@ -139,7 +153,11 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         else
         {
             v->arch.phys_timer.cval = now + ticks_to_ns(*r);
-            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
+            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
+                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
+                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
+                stop_timer(&v->arch.phys_timer.timer);
+            else
             {
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
diff --git a/xen/arch/arm/vtimer.h b/xen/arch/arm/vtimer.h
index 43eef69..cbe0470 100644
--- a/xen/arch/arm/vtimer.h
+++ b/xen/arch/arm/vtimer.h
@@ -26,6 +26,8 @@ extern int virt_timer_save(struct vcpu *v);
 extern int virt_timer_restore(struct vcpu *v);
 extern void vcpu_timer_destroy(struct vcpu *v);
 
+int init_ptimer(void);
+
 #endif
 
 /*
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 577ad19..3e9cc37 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -75,8 +75,8 @@ struct vtimer {
         int irq;
         struct timer timer;
         uint32_t ctl;
-        s_time_t offset;
-        s_time_t cval;
+        uint64_t offset;
+        uint64_t cval;
 };
 
 struct arch_vcpu
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61pA-0006Yi-7H; Thu, 14 Feb 2013 16:38:16 +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 1U61p8-0006Xf-1T
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:14 +0000
Received: from [193.109.254.147:26129] by server-9.bemta-14.messagelabs.com id
	12/37-30867-5F21D115; Thu, 14 Feb 2013 16:38:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4288 invoked from network); 14 Feb 2013 16:37:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527736"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-M5;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:08 +0000
Message-ID: <1360859833-16498-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/7] xen/arm: just return 0 on
	XENMEM_get_sharing_shared/freed_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

memory sharing is not implemented on ARM yet, so just return 0 for now

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/mm.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7621d1b..aaf0d68 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -751,6 +751,10 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         return rc;
     }
+    /* XXX: memsharing not working yet */
+    case XENMEM_get_sharing_shared_pages:
+    case XENMEM_get_sharing_freed_pages:
+        return 0;
 
     default:
         return -ENOSYS;
-- 
1.7.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 Feb 14 16:38:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:38: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 1U61pA-0006Yi-7H; Thu, 14 Feb 2013 16:38:16 +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 1U61p8-0006Xf-1T
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 16:38:14 +0000
Received: from [193.109.254.147:26129] by server-9.bemta-14.messagelabs.com id
	12/37-30867-5F21D115; Thu, 14 Feb 2013 16:38:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360859856!8746277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4288 invoked from network); 14 Feb 2013 16:37:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:37:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7527736"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:37:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:37:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U61oE-0000tT-M5;
	Thu, 14 Feb 2013 16:37:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 16:37:08 +0000
Message-ID: <1360859833-16498-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/7] xen/arm: just return 0 on
	XENMEM_get_sharing_shared/freed_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

memory sharing is not implemented on ARM yet, so just return 0 for now

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/mm.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7621d1b..aaf0d68 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -751,6 +751,10 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         return rc;
     }
+    /* XXX: memsharing not working yet */
+    case XENMEM_get_sharing_shared_pages:
+    case XENMEM_get_sharing_freed_pages:
+        return 0;
 
     default:
         return -ENOSYS;
-- 
1.7.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 Feb 14 16:39:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:39: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 1U61q2-0006uL-RT; Thu, 14 Feb 2013 16: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 1U61q1-0006tU-4U
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:39:09 +0000
Received: from [85.158.137.99:60468] by server-14.bemta-3.messagelabs.com id
	A4/5B-23533-C231D115; Thu, 14 Feb 2013 16:39:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360859947!18285462!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 14 Feb 2013 16:39:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:39:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1470436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16: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.297.1;
	Thu, 14 Feb 2013 16:39:04 +0000
Message-ID: <1360859941.20449.463.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "Christopher S. Aker"
	<caker@theshore.net>
Date: Thu, 14 Feb 2013 16:39:01 +0000
In-Reply-To: <1360847938-11185-2-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek
	Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen-netback: correctly return errors
 from netbk_count_requests()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> netbk_count_requests() could detect an error, call
> netbk_fatal_tx_error() but return 0.  The vif may then be used
> afterwards (e.g., in a call to netbk_tx_error().
> 
> Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
> be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
> if the vif is also removed).
> 
> Netback thread              Xenwatch thread
> -------------------------------------------
> netbk_fatal_tx_err()        netback_remove()
>                               xenvif_disconnect()
>                                 ...
>                                 free_netdev()
> netbk_tx_err() Oops!
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reported-by: Christopher S. Aker <caker@theshore.net>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I would like to add a Tested-by: Christopher too if possible.

David (M) this should go to stable please.

> ---
>  drivers/net/xen-netback/netback.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 2b9520c..cd49ba9 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -911,13 +911,13 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (frags >= work_to_do) {
>  			netdev_err(vif->dev, "Need more frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -ENODATA;
>  		}
>  
>  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
>  			netdev_err(vif->dev, "Too many frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -E2BIG;
>  		}
>  
>  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> @@ -925,7 +925,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (txp->size > first->size) {
>  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -EIO;
>  		}
>  
>  		first->size -= txp->size;
> @@ -935,7 +935,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
>  				 txp->offset, txp->size);
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -EINVAL;
>  		}
>  	} while ((txp++)->flags & XEN_NETTXF_more_data);
>  	return frags;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:39:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:39: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 1U61q2-0006uL-RT; Thu, 14 Feb 2013 16: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 1U61q1-0006tU-4U
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:39:09 +0000
Received: from [85.158.137.99:60468] by server-14.bemta-3.messagelabs.com id
	A4/5B-23533-C231D115; Thu, 14 Feb 2013 16:39:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360859947!18285462!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23853 invoked from network); 14 Feb 2013 16:39:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:39:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1470436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16: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.297.1;
	Thu, 14 Feb 2013 16:39:04 +0000
Message-ID: <1360859941.20449.463.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "Christopher S. Aker"
	<caker@theshore.net>
Date: Thu, 14 Feb 2013 16:39:01 +0000
In-Reply-To: <1360847938-11185-2-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, Konrad Rzeszutek
	Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, "Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen-netback: correctly return errors
 from netbk_count_requests()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> netbk_count_requests() could detect an error, call
> netbk_fatal_tx_error() but return 0.  The vif may then be used
> afterwards (e.g., in a call to netbk_tx_error().
> 
> Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
> be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
> if the vif is also removed).
> 
> Netback thread              Xenwatch thread
> -------------------------------------------
> netbk_fatal_tx_err()        netback_remove()
>                               xenvif_disconnect()
>                                 ...
>                                 free_netdev()
> netbk_tx_err() Oops!
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Reported-by: Christopher S. Aker <caker@theshore.net>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I would like to add a Tested-by: Christopher too if possible.

David (M) this should go to stable please.

> ---
>  drivers/net/xen-netback/netback.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 2b9520c..cd49ba9 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -911,13 +911,13 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (frags >= work_to_do) {
>  			netdev_err(vif->dev, "Need more frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -ENODATA;
>  		}
>  
>  		if (unlikely(frags >= MAX_SKB_FRAGS)) {
>  			netdev_err(vif->dev, "Too many frags\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -E2BIG;
>  		}
>  
>  		memcpy(txp, RING_GET_REQUEST(&vif->tx, cons + frags),
> @@ -925,7 +925,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  		if (txp->size > first->size) {
>  			netdev_err(vif->dev, "Frag is bigger than frame.\n");
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -EIO;
>  		}
>  
>  		first->size -= txp->size;
> @@ -935,7 +935,7 @@ static int netbk_count_requests(struct xenvif *vif,
>  			netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
>  				 txp->offset, txp->size);
>  			netbk_fatal_tx_err(vif);
> -			return -frags;
> +			return -EINVAL;
>  		}
>  	} while ((txp++)->flags & XEN_NETTXF_more_data);
>  	return frags;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:39:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:39: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 1U61q3-0006uY-9Q; Thu, 14 Feb 2013 16:39: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 1U61q1-0006to-U7
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:39:10 +0000
Received: from [85.158.137.99:16934] by server-4.bemta-3.messagelabs.com id
	2B/B7-17521-D231D115; Thu, 14 Feb 2013 16:39:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360859947!18285462!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23913 invoked from network); 14 Feb 2013 16:39:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1470437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16:39: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.297.1;
	Thu, 14 Feb 2013 16:39:08 +0000
Message-ID: <1360859947.20449.465.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "Christopher S. Aker"
	<caker@theshore.net>
Date: Thu, 14 Feb 2013 16:39:07 +0000
In-Reply-To: <1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Konrad Rzeszutek
	Wilk <konrad.wilk@oracle.com>, "Wei Liu
	\(3P\)" <wei.liu@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If the credit timer is left armed after calling
> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> the vif which will then oops as vif->netbk == NULL.
> 
> This may happen both in the fatal error path and during normal
> disconnection from the front end.
> 
> The sequencing during shutdown is critical to ensure that: a)
> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> is not freed.
> 
> 1. Mark as unschedulable (netif_carrier_off()).
> 2. Synchronously cancel the timer.
> 3. Remove the vif from the schedule list.
> 4. Remove it from it netback thread group.
> 5. Wait for vif->refcnt to become 0.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Was this one also Reported-by Christopher S. Aker or was it just
discovered in the process of investigating?

Another stable candidate please Dave.

> ---
>  drivers/net/xen-netback/interface.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b8c5193..221f426 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
>  static void xenvif_down(struct xenvif *vif)
>  {
>  	disable_irq(vif->irq);
> +	del_timer_sync(&vif->credit_timeout);
>  	xen_netbk_deschedule_xenvif(vif);
>  	xen_netbk_remove_xenvif(vif);
>  }
> @@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
>  	atomic_dec(&vif->refcnt);
>  	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
>  
> -	del_timer_sync(&vif->credit_timeout);
> -
>  	if (vif->irq)
>  		unbind_from_irqhandler(vif->irq, vif);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:39:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:39: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 1U61q3-0006uY-9Q; Thu, 14 Feb 2013 16:39: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 1U61q1-0006to-U7
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:39:10 +0000
Received: from [85.158.137.99:16934] by server-4.bemta-3.messagelabs.com id
	2B/B7-17521-D231D115; Thu, 14 Feb 2013 16:39:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360859947!18285462!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23913 invoked from network); 14 Feb 2013 16:39:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="1470437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16:39: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.297.1;
	Thu, 14 Feb 2013 16:39:08 +0000
Message-ID: <1360859947.20449.465.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>, "Christopher S. Aker"
	<caker@theshore.net>
Date: Thu, 14 Feb 2013 16:39:07 +0000
In-Reply-To: <1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Konrad Rzeszutek
	Wilk <konrad.wilk@oracle.com>, "Wei Liu
	\(3P\)" <wei.liu@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If the credit timer is left armed after calling
> xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> the vif which will then oops as vif->netbk == NULL.
> 
> This may happen both in the fatal error path and during normal
> disconnection from the front end.
> 
> The sequencing during shutdown is critical to ensure that: a)
> vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> is not freed.
> 
> 1. Mark as unschedulable (netif_carrier_off()).
> 2. Synchronously cancel the timer.
> 3. Remove the vif from the schedule list.
> 4. Remove it from it netback thread group.
> 5. Wait for vif->refcnt to become 0.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Was this one also Reported-by Christopher S. Aker or was it just
discovered in the process of investigating?

Another stable candidate please Dave.

> ---
>  drivers/net/xen-netback/interface.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b8c5193..221f426 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
>  static void xenvif_down(struct xenvif *vif)
>  {
>  	disable_irq(vif->irq);
> +	del_timer_sync(&vif->credit_timeout);
>  	xen_netbk_deschedule_xenvif(vif);
>  	xen_netbk_remove_xenvif(vif);
>  }
> @@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
>  	atomic_dec(&vif->refcnt);
>  	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
>  
> -	del_timer_sync(&vif->credit_timeout);
> -
>  	if (vif->irq)
>  		unbind_from_irqhandler(vif->irq, vif);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:47:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61xV-0007sB-8a; Thu, 14 Feb 2013 16:46:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U61xU-0007s6-71
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:46:52 +0000
Received: from [85.158.137.99:2441] by server-12.bemta-3.messagelabs.com id
	68/A5-05889-BF41D115; Thu, 14 Feb 2013 16:46:51 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360860410!21497905!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18994 invoked from network); 14 Feb 2013 16:46:50 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-13.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 16:46:50 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U61xP-0000z8-Sf; Thu, 14 Feb 2013 16:46:47 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U61xK-0002HE-OG; Thu, 14 Feb 2013 16:46:47 +0000
Message-ID: <1360860396.20449.471.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 14 Feb 2013 16:46:36 +0000
In-Reply-To: <1360851838.10581.248.camel@shinybook.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
> On Thu, 2013-02-14 at 14:08 +0000, Ian Campbell wrote:
> > The chap who did our OVMF stuff has moved on to pastures new but ISTR
> > him saying something about a build bug with GCC!=44, which had been
> > fixed in upstream OVMF but not yet sync'd into the Xen tree.
> 
> Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
> building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
> http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
> although I suspect it might be incomplete and I'm about to blow away my
> local build tree and configure from scratch to retest.
> 
> But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
> line which does
>         cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

Ack, thanks.

We try and support a reasonably wide range of hosts, usually we use
Debian Stable as our baseline (which is currently 4.4).

> 
> > Awesome! (I've CCd xen-devel just for their info, it's moderated for
> > non-subscribers but valid posters get whitelisted)
> 
> In that case I think the only context I need to add, for those who want
> to play along at home, is the location of my trees for OVMF and SeaBIOS.
> The OVMF one is above, and the SeaBIOS one is next to it:
> git:// or http://git.infradead.org/users/dwmw2/seabios.git
> 
> There's a README.CSM file in the SeaBIOS tree which describes how to
> build OVMF with CSM support.

Do I understand correctly from the README that once CSM support is
enabled at build time you can choose to use it dynamically at boot time?
If so, Neat!

I suppose this selection is persistent for a given VM, but where is it
saved?

>  The main reason I'm pointing you at my
> trees rather than upstream is the patch within each one that adds the
> UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
> parts of the UMB memory region should be made read-only. For Qemu with
> KVM that's a moot point because it doesn't get made read-only anyway, so
> you could just use upstream now. If you don't implement the PAM
> protection of those regions, I suspect the same might be true for you.
> Suck it and see, perhaps.

Right, we really need to find someone with hours to finish properly
integrating OVMF.

> 
> > > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > > PCIR structure unaligned. That was it.
> 
> > ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> > include? (rather than tools/firmware/vgabios/)
> 
> Yes, the one in /usr/share/qemu-xen. You want the patch from
> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

Thanks.

-- 
Ian Campbell
Current Noise: W.A.S.P. - Harder, Faster

We don't need no education, we don't need no thought control.
		-- Pink Floyd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:47:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61xV-0007sB-8a; Thu, 14 Feb 2013 16:46:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U61xU-0007s6-71
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:46:52 +0000
Received: from [85.158.137.99:2441] by server-12.bemta-3.messagelabs.com id
	68/A5-05889-BF41D115; Thu, 14 Feb 2013 16:46:51 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-13.tower-217.messagelabs.com!1360860410!21497905!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18994 invoked from network); 14 Feb 2013 16:46:50 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-13.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	14 Feb 2013 16:46:50 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U61xP-0000z8-Sf; Thu, 14 Feb 2013 16:46:47 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U61xK-0002HE-OG; Thu, 14 Feb 2013 16:46:47 +0000
Message-ID: <1360860396.20449.471.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 14 Feb 2013 16:46:36 +0000
In-Reply-To: <1360851838.10581.248.camel@shinybook.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
> On Thu, 2013-02-14 at 14:08 +0000, Ian Campbell wrote:
> > The chap who did our OVMF stuff has moved on to pastures new but ISTR
> > him saying something about a build bug with GCC!=44, which had been
> > fixed in upstream OVMF but not yet sync'd into the Xen tree.
> 
> Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
> building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
> http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
> although I suspect it might be incomplete and I'm about to blow away my
> local build tree and configure from scratch to retest.
> 
> But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
> line which does
>         cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

Ack, thanks.

We try and support a reasonably wide range of hosts, usually we use
Debian Stable as our baseline (which is currently 4.4).

> 
> > Awesome! (I've CCd xen-devel just for their info, it's moderated for
> > non-subscribers but valid posters get whitelisted)
> 
> In that case I think the only context I need to add, for those who want
> to play along at home, is the location of my trees for OVMF and SeaBIOS.
> The OVMF one is above, and the SeaBIOS one is next to it:
> git:// or http://git.infradead.org/users/dwmw2/seabios.git
> 
> There's a README.CSM file in the SeaBIOS tree which describes how to
> build OVMF with CSM support.

Do I understand correctly from the README that once CSM support is
enabled at build time you can choose to use it dynamically at boot time?
If so, Neat!

I suppose this selection is persistent for a given VM, but where is it
saved?

>  The main reason I'm pointing you at my
> trees rather than upstream is the patch within each one that adds the
> UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
> parts of the UMB memory region should be made read-only. For Qemu with
> KVM that's a moot point because it doesn't get made read-only anyway, so
> you could just use upstream now. If you don't implement the PAM
> protection of those regions, I suspect the same might be true for you.
> Suck it and see, perhaps.

Right, we really need to find someone with hours to finish properly
integrating OVMF.

> 
> > > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > > PCIR structure unaligned. That was it.
> 
> > ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> > include? (rather than tools/firmware/vgabios/)
> 
> Yes, the one in /usr/share/qemu-xen. You want the patch from
> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

Thanks.

-- 
Ian Campbell
Current Noise: W.A.S.P. - Harder, Faster

We don't need no education, we don't need no thought control.
		-- Pink Floyd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:48:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yV-0007vm-NU; Thu, 14 Feb 2013 16:47: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 1U61yT-0007vc-KJ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:47:54 +0000
Received: from [85.158.143.99:44994] by server-3.bemta-4.messagelabs.com id
	18/C0-08920-8351D115; Thu, 14 Feb 2013 16:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360860467!16134307!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6812 invoked from network); 14 Feb 2013 16:47:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; d="sh'?scan'208";a="1471006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16:47: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.297.1;
	Thu, 14 Feb 2013 16:47:46 +0000
Message-ID: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:45 +0000
Organization: Citrix Systems, Inc.
Content-Type: multipart/mixed; boundary="=-dRpJ3ja7xmka3hWbNPpT"
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: [Xen-devel] [PATCH 00/46] initial arm v8 (64-bit) 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

This is v2 of the arm64 bit series. It is based on current staging plus
the "xen: public interface (and foreign check) changes for arm" series,
second posting of that is
<1360857557.20449.436.camel@zakaz.uk.xensource.com>

I have implemented Tim's review comments with the exception of the
comments on use of WFE etc in the spinlock implementation (#8 last time)
and the comments on trap handling (#28 last time) which I intend to
return to. Many thanks to Tim for his copious comments and acks!

I have pushed the series, plus the prerequisite mentioned above and a
small number of Stefano's toolstack patches to:
        git://xenbits.xen.org/people/ianc/xen.git arm64-v2

As well as the above I have pushed the kernel tree I am using, which is
based on v3.8-rc3 to:
        git://xenbits.xen.org/people/ianc/linux.git arm64-v2
The kernel config is attached. Note that this is a 32-bit ARM kernel,
64-bit support for dom0 and domU is a WIP but not included here.

I am building the 64-bit hypervisor with the Linaro gcc,
gcc-linaro-aarch64-linux-gnu-4.7-2012.12-20121214_linux, from
http://www.linaro.org/engineering/armv8#tab3 
http://releases.linaro.org/13.01/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.7-2013.01-20130125_linux.tar.bz2

For the tools I am using the native armhf tools on a Debian Wheezy armhf
system (running on a cluster of IMX.5x loco boards). I have not tried
cross compiling the tools. FWIW I also build the 32-bit hypervisor
natively in this environment.

For the kernel I am using the kernel.org cross compiler,
gcc-4.6.3-nolibc / arm-unknown-linux-gnueabi, from
http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3

With all this I can boot a 32-bit dom0 and a 32-bit guest domain (using
the same kernel) on either a 64-bit hypervisor (on the RTSM_VE_AEMv8A
model, 0.8.4510) or a 32-bit hypervisor (RTSM_VE_Cortex-A15x1, 8.0.44).
You can also run 32-bit on the V8 model (using -C
cluster.cpu0.CONFIG64=0) if you comment out the ThumbEE in
ctxt_switch_from and ctxt_switch_to (making this dynamic is on my TODO
list).

My dom0 root filesystem is a Debian Wheezy armhf image, attached to the
emulated MMC (-C motherboard.mmc.p_mmc_file=rootfs.img)

To save running all of the dom0 initscripts (which is a bit boring on
the model) I boot using init=/root/init.sh (init.sh is attached), which
mounts the necessary filesystems, starts u-boot and the relevant xen
stuff.

Once booted into dom0 I run the attached guest.sh, which uses the
attached cfg and a guest.img (I use the one from the ARM 3rd party IP)
to start a guest and connect to its console The guest boots to a prompt.

I will at some point be updating
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions with
v8 specific info (and renaming the page s/v7//).

Ian.

--=-dRpJ3ja7xmka3hWbNPpT
Content-Disposition: attachment; filename="config"
Content-Type: text/plain; name="config"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.8.0-rc3 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_ARCH_VT8500_SINGLE is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_ARCH_SUNXI is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VT8500 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
# CONFIG_ARM_VIRT_EXT is not set
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_ARM_ERRATA_720789=y
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_ARM_ERRATA_775420 is not set
CONFIG_ARM_GIC=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_XEN_DOM0=y
CONFIG_XEN=y

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
# CONFIG_ARM_ATAG_DTB_COMPAT is not set
CONFIG_CMDLINE="earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw init=/bin/bash"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_OF_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_ATA_BMDMA is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_SEEQ=y
# CONFIG_SEEQ8005 is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_SMC91X=y
CONFIG_SMC911X=y
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_AS3711 is not set
CONFIG_VEXPRESS_CONFIG=y
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_LOGO is not set
# CONFIG_FB_SSD1307 is not set
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
CONFIG_SND_ARM=y
CONFIG_SND_ARMAACI=y
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#

#
# Xen driver support
#
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_XEN_PRIVCMD=y
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
CONFIG_DEBUG_VEXPRESS_UART0_RS1=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="debug/vexpress.S"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set

--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: application/x-shellscript; name="guest.sh"
Content-Disposition: attachment; filename="guest.sh"
Content-Transfer-Encoding: 7bit

#!/bin/bash
set -ex
losetup /dev/loop0 domU.img
losetup -a
#xcbuild
xl create /root/cfg
xenconsole 1

--=-dRpJ3ja7xmka3hWbNPpT
Content-Disposition: attachment; filename="cfg"
Content-Type: text/plain; name="cfg"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

kernel = "/root/guest.img"
name = "g"
memory = 128
vcpus = 1

disk = [ 'phy:/dev/loop0,xvda,w' ]


--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: application/x-shellscript; name="init.sh"
Content-Disposition: attachment; filename="init.sh"
Content-Transfer-Encoding: 7bit

#!/bin/sh
set -x
#PATH=/sbin:$PATH /etc/init.d/checkroot.sh start
mount -o remount,rw /
mount -t proc none /proc
mount -t sysfs none /sys
mount -t tmpfs none /run
mkdir /run/lock
/etc/init.d/udev start
mount -t devpts none /dev/pts
hostname -F /etc/hostname
/etc/init.d/xencommons start
echo 9 > /proc/sysrq-trigger 
cd /root
exec /bin/bash

--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-dRpJ3ja7xmka3hWbNPpT--


From xen-devel-bounces@lists.xen.org Thu Feb 14 16:48:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yV-0007vm-NU; Thu, 14 Feb 2013 16:47: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 1U61yT-0007vc-KJ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:47:54 +0000
Received: from [85.158.143.99:44994] by server-3.bemta-4.messagelabs.com id
	18/C0-08920-8351D115; Thu, 14 Feb 2013 16:47:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1360860467!16134307!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6812 invoked from network); 14 Feb 2013 16:47:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; d="sh'?scan'208";a="1471006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16:47: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.297.1;
	Thu, 14 Feb 2013 16:47:46 +0000
Message-ID: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:45 +0000
Organization: Citrix Systems, Inc.
Content-Type: multipart/mixed; boundary="=-dRpJ3ja7xmka3hWbNPpT"
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: [Xen-devel] [PATCH 00/46] initial arm v8 (64-bit) 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

This is v2 of the arm64 bit series. It is based on current staging plus
the "xen: public interface (and foreign check) changes for arm" series,
second posting of that is
<1360857557.20449.436.camel@zakaz.uk.xensource.com>

I have implemented Tim's review comments with the exception of the
comments on use of WFE etc in the spinlock implementation (#8 last time)
and the comments on trap handling (#28 last time) which I intend to
return to. Many thanks to Tim for his copious comments and acks!

I have pushed the series, plus the prerequisite mentioned above and a
small number of Stefano's toolstack patches to:
        git://xenbits.xen.org/people/ianc/xen.git arm64-v2

As well as the above I have pushed the kernel tree I am using, which is
based on v3.8-rc3 to:
        git://xenbits.xen.org/people/ianc/linux.git arm64-v2
The kernel config is attached. Note that this is a 32-bit ARM kernel,
64-bit support for dom0 and domU is a WIP but not included here.

I am building the 64-bit hypervisor with the Linaro gcc,
gcc-linaro-aarch64-linux-gnu-4.7-2012.12-20121214_linux, from
http://www.linaro.org/engineering/armv8#tab3 
http://releases.linaro.org/13.01/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.7-2013.01-20130125_linux.tar.bz2

For the tools I am using the native armhf tools on a Debian Wheezy armhf
system (running on a cluster of IMX.5x loco boards). I have not tried
cross compiling the tools. FWIW I also build the 32-bit hypervisor
natively in this environment.

For the kernel I am using the kernel.org cross compiler,
gcc-4.6.3-nolibc / arm-unknown-linux-gnueabi, from
http://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3

With all this I can boot a 32-bit dom0 and a 32-bit guest domain (using
the same kernel) on either a 64-bit hypervisor (on the RTSM_VE_AEMv8A
model, 0.8.4510) or a 32-bit hypervisor (RTSM_VE_Cortex-A15x1, 8.0.44).
You can also run 32-bit on the V8 model (using -C
cluster.cpu0.CONFIG64=0) if you comment out the ThumbEE in
ctxt_switch_from and ctxt_switch_to (making this dynamic is on my TODO
list).

My dom0 root filesystem is a Debian Wheezy armhf image, attached to the
emulated MMC (-C motherboard.mmc.p_mmc_file=rootfs.img)

To save running all of the dom0 initscripts (which is a bit boring on
the model) I boot using init=/root/init.sh (init.sh is attached), which
mounts the necessary filesystems, starts u-boot and the relevant xen
stuff.

Once booted into dom0 I run the attached guest.sh, which uses the
attached cfg and a guest.img (I use the one from the ARM 3rd party IP)
to start a guest and connect to its console The guest boots to a prompt.

I will at some point be updating
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions with
v8 specific info (and renaming the page s/v7//).

Ian.

--=-dRpJ3ja7xmka3hWbNPpT
Content-Disposition: attachment; filename="config"
Content-Type: text/plain; name="config"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.8.0-rc3 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_ARCH_VT8500_SINGLE is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_ARCH_SUNXI is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VT8500 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
# CONFIG_ARM_VIRT_EXT is not set
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_ARM_ERRATA_720789=y
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_ARM_ERRATA_775420 is not set
CONFIG_ARM_GIC=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_XEN_DOM0=y
CONFIG_XEN=y

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
# CONFIG_ARM_ATAG_DTB_COMPAT is not set
CONFIG_CMDLINE="earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 debug rw init=/bin/bash"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_OF_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_ATA_BMDMA is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_SEEQ=y
# CONFIG_SEEQ8005 is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_SMC91X=y
CONFIG_SMC911X=y
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_TS5500 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_AS3711 is not set
CONFIG_VEXPRESS_CONFIG=y
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_XEN_FBDEV_FRONTEND is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_LOGO is not set
# CONFIG_FB_SSD1307 is not set
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
CONFIG_SND_ARM=y
CONFIG_SND_ARMAACI=y
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#

#
# Xen driver support
#
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_XEN_PRIVCMD=y
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
CONFIG_DEBUG_VEXPRESS_UART0_RS1=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="debug/vexpress.S"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set

--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: application/x-shellscript; name="guest.sh"
Content-Disposition: attachment; filename="guest.sh"
Content-Transfer-Encoding: 7bit

#!/bin/bash
set -ex
losetup /dev/loop0 domU.img
losetup -a
#xcbuild
xl create /root/cfg
xenconsole 1

--=-dRpJ3ja7xmka3hWbNPpT
Content-Disposition: attachment; filename="cfg"
Content-Type: text/plain; name="cfg"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

kernel = "/root/guest.img"
name = "g"
memory = 128
vcpus = 1

disk = [ 'phy:/dev/loop0,xvda,w' ]


--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: application/x-shellscript; name="init.sh"
Content-Disposition: attachment; filename="init.sh"
Content-Transfer-Encoding: 7bit

#!/bin/sh
set -x
#PATH=/sbin:$PATH /etc/init.d/checkroot.sh start
mount -o remount,rw /
mount -t proc none /proc
mount -t sysfs none /sys
mount -t tmpfs none /run
mkdir /run/lock
/etc/init.d/udev start
mount -t devpts none /dev/pts
hostname -F /etc/hostname
/etc/init.d/xencommons start
echo 9 > /proc/sysrq-trigger 
cd /root
exec /bin/bash

--=-dRpJ3ja7xmka3hWbNPpT
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-dRpJ3ja7xmka3hWbNPpT--


From xen-devel-bounces@lists.xen.org Thu Feb 14 16:48:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yh-0007yH-7E; Thu, 14 Feb 2013 16:48:07 +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 1U61yf-0007xG-Hg
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:05 +0000
Received: from [85.158.139.83:32961] by server-8.bemta-5.messagelabs.com id
	F8/57-19075-4451D115; Thu, 14 Feb 2013 16:48:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 14 Feb 2013 16:48:04 -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;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159744"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-0k;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:17 +0000
Message-ID: <1360860480-9245-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 03/46] xen: arm: do not pass a machine ID 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

Xen relies on DTB and we pass in a suitable device-tree so we don't
need to (and shouldn't) pretend to be a Versatile Express here.

We already don't pass a machine ID to domU in the same way.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6abbb03..7403f1a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -349,7 +349,7 @@ int construct_dom0(struct domain *d)
  */
 
     regs->r0 = 0; /* SBZ */
-    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
     regs->r2 = kinfo.dtb_paddr;
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
-- 
1.7.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 Feb 14 16:48:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yh-0007yH-7E; Thu, 14 Feb 2013 16:48:07 +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 1U61yf-0007xG-Hg
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:05 +0000
Received: from [85.158.139.83:32961] by server-8.bemta-5.messagelabs.com id
	F8/57-19075-4451D115; Thu, 14 Feb 2013 16:48:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 14 Feb 2013 16:48:04 -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;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159744"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-0k;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:17 +0000
Message-ID: <1360860480-9245-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 03/46] xen: arm: do not pass a machine ID 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

Xen relies on DTB and we pass in a suitable device-tree so we don't
need to (and shouldn't) pretend to be a Versatile Express here.

We already don't pass a machine ID to domU in the same way.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6abbb03..7403f1a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -349,7 +349,7 @@ int construct_dom0(struct domain *d)
  */
 
     regs->r0 = 0; /* SBZ */
-    regs->r1 = 2272; /* Machine NR: Versatile Express */
+    regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
     regs->r2 = kinfo.dtb_paddr;
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
-- 
1.7.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 Feb 14 16:48:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yf-0007xK-Aw; Thu, 14 Feb 2013 16:48:05 +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 1U61ye-0007x5-E7
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:04 +0000
Received: from [85.158.139.83:32863] by server-9.bemta-5.messagelabs.com id
	DB/B2-24440-3451D115; Thu, 14 Feb 2013 16:48:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20107 invoked from network); 14 Feb 2013 16:48: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;
	14 Feb 2013 16:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159742"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61ya-00012f-TV;
	Thu, 14 Feb 2013 16:48:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:15 +0000
Message-ID: <1360860480-9245-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 01/46] xen: arm32: Don't bother with the
	bootloader provided ARM-Linux machine 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

Everything is DTB based and on 64-bit there is no such concept even in
Linux.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Update start_secondary too.
---
 xen/arch/arm/arm32/head.S |    7 +++----
 xen/arch/arm/setup.c      |    1 -
 xen/arch/arm/smpboot.c    |    1 -
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 20e9da6..92fc36c 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -72,7 +72,7 @@ past_zImage:
         cpsid aif                    /* Disable all interrupts */
 
         /* Save the bootloader arguments in less-clobberable registers */
-        mov   r7, r1                 /* r7 := ARM-linux machine type */
+        /* No need to save r1 == Unused ARM-linux machine type */
         mov   r8, r2                 /* r8 := ATAG base address */
 
         /* Find out where we are */
@@ -334,9 +334,8 @@ launch:
         add   sp, #STACK_SIZE        /* (which grows down from the top). */
         sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
         mov   r0, r10                /* Marshal args: - phys_offset */
-        mov   r1, r7                 /*               - machine type */
-        mov   r2, r8                 /*               - ATAG address */
-        movs  r3, r12                /*               - CPU ID */
+        mov   r1, r8                 /*               - ATAG address */
+        movs  r2, r12                /*               - CPU ID */
         beq   start_xen              /* and disappear into the land of C */
         b     start_secondary        /* (to the appropriate entry point) */
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index acb7abb..782d252 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -329,7 +329,6 @@ void __init setup_cache(void)
 
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
-                      unsigned long arm_type,
                       unsigned long atag_paddr,
                       unsigned long cpuid)
 {
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c7a586b..da4880c 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -132,7 +132,6 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
-                               unsigned long arm_type,
                                unsigned long atag_paddr,
                                unsigned long cpuid)
 {
-- 
1.7.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 Feb 14 16:48:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yf-0007xK-Aw; Thu, 14 Feb 2013 16:48:05 +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 1U61ye-0007x5-E7
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:04 +0000
Received: from [85.158.139.83:32863] by server-9.bemta-5.messagelabs.com id
	DB/B2-24440-3451D115; Thu, 14 Feb 2013 16:48:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20107 invoked from network); 14 Feb 2013 16:48: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;
	14 Feb 2013 16:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159742"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61ya-00012f-TV;
	Thu, 14 Feb 2013 16:48:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:15 +0000
Message-ID: <1360860480-9245-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 01/46] xen: arm32: Don't bother with the
	bootloader provided ARM-Linux machine 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

Everything is DTB based and on 64-bit there is no such concept even in
Linux.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Update start_secondary too.
---
 xen/arch/arm/arm32/head.S |    7 +++----
 xen/arch/arm/setup.c      |    1 -
 xen/arch/arm/smpboot.c    |    1 -
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 20e9da6..92fc36c 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -72,7 +72,7 @@ past_zImage:
         cpsid aif                    /* Disable all interrupts */
 
         /* Save the bootloader arguments in less-clobberable registers */
-        mov   r7, r1                 /* r7 := ARM-linux machine type */
+        /* No need to save r1 == Unused ARM-linux machine type */
         mov   r8, r2                 /* r8 := ATAG base address */
 
         /* Find out where we are */
@@ -334,9 +334,8 @@ launch:
         add   sp, #STACK_SIZE        /* (which grows down from the top). */
         sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
         mov   r0, r10                /* Marshal args: - phys_offset */
-        mov   r1, r7                 /*               - machine type */
-        mov   r2, r8                 /*               - ATAG address */
-        movs  r3, r12                /*               - CPU ID */
+        mov   r1, r8                 /*               - ATAG address */
+        movs  r2, r12                /*               - CPU ID */
         beq   start_xen              /* and disappear into the land of C */
         b     start_secondary        /* (to the appropriate entry point) */
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index acb7abb..782d252 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -329,7 +329,6 @@ void __init setup_cache(void)
 
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
-                      unsigned long arm_type,
                       unsigned long atag_paddr,
                       unsigned long cpuid)
 {
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c7a586b..da4880c 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -132,7 +132,6 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
-                               unsigned long arm_type,
                                unsigned long atag_paddr,
                                unsigned long cpuid)
 {
-- 
1.7.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 Feb 14 16:48:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yg-0007xy-O5; Thu, 14 Feb 2013 16:48: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 1U61yf-0007x9-4J
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:05 +0000
Received: from [85.158.139.83:49440] by server-4.bemta-5.messagelabs.com id
	B0/64-29496-4451D115; Thu, 14 Feb 2013 16:48:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20145 invoked from network); 14 Feb 2013 16:48: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;
	14 Feb 2013 16:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159743"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61ya-00012f-VO;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:16 +0000
Message-ID: <1360860480-9245-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 02/46] xen: arm: rename atag_paddr argument
	fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 support ATAGs and this is always actually an FDT address.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Update start_secondary too, s/ATAG/DTB in head.S comments
---
 xen/arch/arm/arm32/head.S |    4 ++--
 xen/arch/arm/setup.c      |    6 +++---
 xen/arch/arm/smpboot.c    |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 92fc36c..5ec46c3 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -73,7 +73,7 @@ past_zImage:
 
         /* Save the bootloader arguments in less-clobberable registers */
         /* No need to save r1 == Unused ARM-linux machine type */
-        mov   r8, r2                 /* r8 := ATAG base address */
+        mov   r8, r2                 /* r8 := DTB base address */
 
         /* Find out where we are */
         ldr   r0, =start
@@ -334,7 +334,7 @@ launch:
         add   sp, #STACK_SIZE        /* (which grows down from the top). */
         sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
         mov   r0, r10                /* Marshal args: - phys_offset */
-        mov   r1, r8                 /*               - ATAG address */
+        mov   r1, r8                 /*               - DTB address */
         movs  r2, r12                /*               - CPU ID */
         beq   start_xen              /* and disappear into the land of C */
         b     start_secondary        /* (to the appropriate entry point) */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 782d252..4e50b2b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -329,7 +329,7 @@ void __init setup_cache(void)
 
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
-                      unsigned long atag_paddr,
+                      unsigned long fdt_paddr,
                       unsigned long cpuid)
 {
     void *fdt;
@@ -341,7 +341,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     smp_clear_cpu_maps();
 
     fdt = (void *)BOOT_MISC_VIRT_START
-        + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
+        + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
     cpus = smp_get_max_cpus();
@@ -365,7 +365,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    setup_mm(atag_paddr, fdt_size);
+    setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index da4880c..60be1a4 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -132,7 +132,7 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
-                               unsigned long atag_paddr,
+                               unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
     memset(get_cpu_info(), 0, sizeof (struct cpu_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 Thu Feb 14 16:48:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yg-0007xy-O5; Thu, 14 Feb 2013 16:48: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 1U61yf-0007x9-4J
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:05 +0000
Received: from [85.158.139.83:49440] by server-4.bemta-5.messagelabs.com id
	B0/64-29496-4451D115; Thu, 14 Feb 2013 16:48:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20145 invoked from network); 14 Feb 2013 16:48: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;
	14 Feb 2013 16:48:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159743"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61ya-00012f-VO;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:16 +0000
Message-ID: <1360860480-9245-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 02/46] xen: arm: rename atag_paddr argument
	fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 support ATAGs and this is always actually an FDT address.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Update start_secondary too, s/ATAG/DTB in head.S comments
---
 xen/arch/arm/arm32/head.S |    4 ++--
 xen/arch/arm/setup.c      |    6 +++---
 xen/arch/arm/smpboot.c    |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 92fc36c..5ec46c3 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -73,7 +73,7 @@ past_zImage:
 
         /* Save the bootloader arguments in less-clobberable registers */
         /* No need to save r1 == Unused ARM-linux machine type */
-        mov   r8, r2                 /* r8 := ATAG base address */
+        mov   r8, r2                 /* r8 := DTB base address */
 
         /* Find out where we are */
         ldr   r0, =start
@@ -334,7 +334,7 @@ launch:
         add   sp, #STACK_SIZE        /* (which grows down from the top). */
         sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
         mov   r0, r10                /* Marshal args: - phys_offset */
-        mov   r1, r8                 /*               - ATAG address */
+        mov   r1, r8                 /*               - DTB address */
         movs  r2, r12                /*               - CPU ID */
         beq   start_xen              /* and disappear into the land of C */
         b     start_secondary        /* (to the appropriate entry point) */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 782d252..4e50b2b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -329,7 +329,7 @@ void __init setup_cache(void)
 
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
-                      unsigned long atag_paddr,
+                      unsigned long fdt_paddr,
                       unsigned long cpuid)
 {
     void *fdt;
@@ -341,7 +341,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     smp_clear_cpu_maps();
 
     fdt = (void *)BOOT_MISC_VIRT_START
-        + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
+        + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
     cpus = smp_get_max_cpus();
@@ -365,7 +365,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    setup_mm(atag_paddr, fdt_size);
+    setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index da4880c..60be1a4 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -132,7 +132,7 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
 
 /* Boot the current CPU */
 void __cpuinit start_secondary(unsigned long boot_phys_offset,
-                               unsigned long atag_paddr,
+                               unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
     memset(get_cpu_info(), 0, sizeof (struct cpu_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 Thu Feb 14 16:48:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61yj-0007zR-DZ; Thu, 14 Feb 2013 16:48: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 1U61yg-0007xw-Qs
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:07 +0000
Received: from [85.158.139.83:49615] by server-13.bemta-5.messagelabs.com id
	71/86-06769-6451D115; Thu, 14 Feb 2013 16:48:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20208 invoked from network); 14 Feb 2013 16:48:04 -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;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159747"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-2v;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:19 +0000
Message-ID: <1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 05/46] xen: arm64: initial build + config
	changes, start of day 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
      defining in head.S
    - Nuke hard tabs in head.S and mode_switch.S with expand(1)
---
 Config.mk                        |    2 +-
 config/arm64.mk                  |   12 ++
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/Rules.mk            |    6 +
 xen/arch/arm/arm64/Makefile      |    1 +
 xen/arch/arm/arm64/head.S        |  394 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
 xen/arch/arm/xen.lds.S           |    8 +-
 xen/include/asm-arm/page.h       |    1 +
 xen/include/public/arch-arm.h    |   14 ++
 xen/include/public/hvm/save.h    |    2 +-
 xen/include/public/xen.h         |    2 +-
 xen/include/xen/libelf.h         |    2 +-
 13 files changed, 523 insertions(+), 5 deletions(-)
 create mode 100644 config/arm64.mk
 create mode 100644 xen/arch/arm/arm64/Makefile
 create mode 100644 xen/arch/arm/arm64/head.S
 create mode 100644 xen/arch/arm/arm64/mode_switch.S

diff --git a/Config.mk b/Config.mk
index 64541c8..ea64925 100644
--- a/Config.mk
+++ b/Config.mk
@@ -15,7 +15,7 @@ debug_symbols ?= $(debug)
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
-                         -e s/armv7.*/arm32/)
+                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
 
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
diff --git a/config/arm64.mk b/config/arm64.mk
new file mode 100644
index 0000000..b2457eb
--- /dev/null
+++ b/config/arm64.mk
@@ -0,0 +1,12 @@
+CONFIG_ARM := y
+CONFIG_ARM_64 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+CFLAGS += #-marm -march= -mcpu= etc
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+LDFLAGS_DIRECT += -maarch64elf
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f2822f2..7ff67c7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-$(arm64) += arm64
 
 obj-y += early_printk.o
 obj-y += domain.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 5b5768a..29b605d 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -26,6 +26,12 @@ arm32 := y
 arm64 := n
 endif
 
+ifeq ($(TARGET_SUBARCH),arm64)
+CFLAGS += -mcpu=generic
+arm32 := n
+arm64 := y
+endif
+
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
new file mode 100644
index 0000000..dffbeb1
--- /dev/null
+++ b/xen/arch/arm/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
new file mode 100644
index 0000000..847043b
--- /dev/null
+++ b/xen/arch/arm/arm64/head.S
@@ -0,0 +1,394 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv8.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * Based on ARMv7-A head.S by
+ * Tim Deegan <tim@xen.org>
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
+#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
+#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
+#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+        adr   x0, 98f ; \
+        bl    puts    ; \
+        b     99f     ; \
+98:     .asciz _s     ; \
+        .align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+        /*.aarch64*/
+
+        /*
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * The requirements are:
+         *   MMU = off, D-cache = off, I-cache = on or off,
+         *   x0 = physical address to the FDT blob.
+         *
+         * This must be the very first address in the loaded image.
+         * It should be linked at XEN_VIRT_START, and loaded at any
+         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+         * or the initial pagetable code below will need adjustment.
+         */
+
+        .global start
+start:
+        /*
+         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
+         */
+        b       real_start           /* branch to kernel start, magic */
+        .long   0                    /* reserved */
+        .quad   0                    /* Image load offset from start of RAM */
+        .quad   0                    /* reserved */
+        .quad   0                    /* reserved */
+
+real_start:
+        msr   DAIFSet, 0xf           /* Disable all interrupts */
+
+        /* Save the bootloader arguments in less-clobberable registers */
+        mov   x21, x0                /* x21 := DTB, physical address  */
+
+        /* Find out where we are */
+        ldr   x0, =start
+        adr   x19, start             /* x19 := paddr (start) */
+        sub   x20, x19, x0           /* x20 := phys-offset */
+
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   x21, =_sdtb
+        add   x21, x21, x20          /* x21 := paddr(DTB) */
+#endif
+
+        /* Are we the boot CPU? */
+        mov   x22, #0                /* x22 := CPU ID */
+        mrs   x0, mpidr_el1
+        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
+        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
+
+        mov   x13, #(0xff << 24)
+        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
+        b.eq  boot_cpu               /* If we're CPU 0, boot now */
+
+        /* Non-boot CPUs wait here to be woken up one at a time. */
+1:      dsb   sy
+        ldr   x0, =smp_up_cpu        /* VA of gate */
+        add   x0, x0, x20            /* PA of gate */
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x22                /* Is it us? */
+        b.eq  2f
+        wfe
+        b     1b
+2:
+
+boot_cpu:
+#ifdef EARLY_UART_ADDRESS
+        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
+        cbnz  x22, 1f
+        bl    init_uart                 /* CPU 0 sets up the UART too */
+1:      PRINT("- CPU ")
+        mov   x0, x22
+        bl    putn
+        PRINT(" booting -\r\n")
+#endif
+
+        PRINT("- Current EL ")
+        mrs   x0, CurrentEL
+        bl    putn
+        PRINT(" -\r\n")
+
+        /* Are we in EL3 */
+        mrs   x0, CurrentEL
+        cmp   x0, #PSR_MODE_EL3t
+        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
+        b.eq  1f /* Yes */
+
+        /* Are we in EL2 */
+        cmp   x0, #PSR_MODE_EL2t
+        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
+        b.eq  2f /* Yes */
+
+        /* Otherwise, it must have been EL0 or EL1 */
+        PRINT("- CPU is not in EL3 or EL2 -\r\n")
+        b     fail
+
+1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
+        ldr   x1, =enter_el2_mode    /* VA of function */
+        add   x1, x1, x20            /* PA of function */
+        adr   x30, hyp               /* Set return address for call */
+        br    x1                     /* Call function */
+
+2:      PRINT("- Started in Hyp mode -\r\n")
+
+hyp:
+        /* Zero BSS On the boot CPU to avoid nasty surprises */
+        cbnz  x22, skip_bss
+
+        PRINT("- Zero BSS -\r\n")
+        ldr   x0, =__bss_start       /* Load start & end of bss */
+        ldr   x1, =__bss_end
+        add   x0, x0, x20            /* Apply physical offset */
+        add   x1, x1, x20
+
+1:      str   xzr, [x0], #8
+        cmp   x0, x1
+        b.lo  1b
+
+skip_bss:
+
+        PRINT("- Setting up control registers -\r\n")
+
+        /* Set up memory attribute type tables */
+        ldr   x0, =MAIRVAL
+        msr   mair_el2, x0
+
+        /* Set up the HTCR:
+         * PASize -- 4G
+         * Top byte is used
+         * PT walks use Outer-Shareable accesses,
+         * PT walks are write-back, no-write-allocate in both cache levels,
+         * Full 64-bit address space goes through this table. */
+        ldr   x0, =0x80802500
+        msr   tcr_el2, x0
+
+        /* Set up the HSCTLR:
+         * Exceptions in LE ARM,
+         * Low-latency IRQs disabled,
+         * Write-implies-XN disabled (for now),
+         * D-cache disabled (for now),
+         * I-cache enabled,
+         * Alignment checking enabled,
+         * MMU translation disabled (for now). */
+        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
+        msr   SCTLR_EL2, x0
+
+        /* Write Xen's PT's paddr into the HTTBR */
+        ldr   x4, =xen_pgtable
+        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
+        msr   TTBR0_EL2, x4
+
+        /* Non-boot CPUs don't need to rebuild the pagetable */
+        cbnz  x22, pt_ready
+
+        ldr   x1, =xen_first
+        add   x1, x1, x20            /* x1 := paddr (xen_first) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_first */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+
+        mov   x4, x1                 /* Next level into xen_first */
+
+       /* console fixmap */
+#ifdef EARLY_UART_ADDRESS
+        ldr   x1, =xen_fixmap
+        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
+        lsr   x2, x23, #12
+        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
+        mov   x3, #PT_DEV_L3
+        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
+        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
+#endif
+
+        /* Build the baseline idle pagetable's first-level entries */
+        ldr   x1, =xen_second
+        add   x1, x1, x20            /* x1 := paddr (xen_second) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_second */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
+
+        /* Now set up the second-level entries */
+        mov   x3, #PT_MEM
+        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
+        orr   x4, xzr, x19, lsr #18
+        str   x2, [x1, x4]           /* Map Xen there */
+        ldr   x4, =start
+        lsr   x4, x4, #18            /* Slot for vaddr(start) */
+        str   x2, [x1, x4]           /* Map Xen there too */
+
+        /* xen_fixmap pagetable */
+        ldr   x2, =xen_fixmap
+        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
+        mov   x3, #PT_PT
+        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
+
+        lsr   x2, x21, #21
+        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
+        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
+        orr   x2, x2, x3
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the early boot slot */
+
+pt_ready:
+        PRINT("- Turning on paging -\r\n")
+
+        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
+        mrs   x0, SCTLR_EL2
+        orr   x0, x0, #SCTLR_M       /* Enable MMU */
+        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
+        dsb   sy                     /* Flush PTE writes and finish reads */
+        msr   SCTLR_EL2, x0          /* now paging is enabled */
+        isb                          /* Now, flush the icache */
+        br    x1                     /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+        /* Use a virtual address to access the UART. */
+        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+#endif
+
+        PRINT("- Ready -\r\n")
+
+        /* The boot CPU should go straight into C now */
+        cbz   x22, launch
+
+        /* Non-boot CPUs need to move on to the relocated pagetables */
+        //mov   x0, #0
+        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
+        add   x4, x4, x20            /* PA of it */
+        ldr   x4, [x4]               /* Actual value */
+        dsb   sy
+        msr   TTBR0_EL2, x4
+        dsb   sy
+        isb
+        tlbi  alle2
+        dsb   sy                     /* Ensure completion of TLB flush */
+        isb
+
+        /* Non-boot CPUs report that they've got this far */
+        ldr   x0, =ready_cpus
+1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
+        add   x1, x1, #1             /* Atomically { ++                   } */
+        stlxr w2, x1, [x0]           /*            { writeback            } */
+        cbnz  w2, 1b
+        dsb   sy
+        dc    cvac, x0               /* Flush D-Cache */
+        dsb   sy
+
+        /* Here, the non-boot CPUs must wait again -- they're now running on
+         * the boot CPU's pagetables so it's safe for the boot CPU to
+         * overwrite the non-relocated copy of Xen.  Once it's done that,
+         * and brought up the memory allocator, non-boot CPUs can get their
+         * own stacks and enter C. */
+1:      wfe
+        dsb   sy
+        ldr   x0, =smp_up_cpu
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x12                /* Is it us? */
+        b.ne  1b
+
+launch:
+        ldr   x0, =init_stack        /* Find the boot-time stack */
+        ldr   x0, [x0]
+        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
+        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
+        mov   sp, x0
+
+        mov   x0, x20                /* Marshal args: - phys_offset */
+        mov   x1, x21                /*               - FDT */
+        mov   x2, x22                /*               - CPU ID */
+        cbz   x22, start_xen         /* and disappear into the land of C */
+        b     start_secondary        /* (to the appropriate entry point) */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:   PRINT("- Boot failed -\r\n")
+1:      wfe
+        b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+        mov   x1, #0x0
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+        mov   x1, #0x60              /* 8n1 */
+        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
+        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
+        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
+        adr   x0, 1f
+        b     puts
+1:      .asciz "- UART enabled -\r\n"
+        .align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  puts                   /* Wait for the UART to be ready */
+        ldrb  w2, [x0], #1           /* Load next char */
+        cbz   w2, 1f                 /* Exit on nul */
+        str   w2, [x23]              /* -> UARTDR (Data Register) */
+        b     puts
+1:
+        ret
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+        adr   x1, hex
+        mov   x3, #8
+1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  1b                     /* Wait for the UART to be ready */
+        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
+        lsr   x2, x2, #28
+        ldrb  w2, [x1, x2]           /* Convert to a char */
+        strb  w2, [x23]              /* -> UARTDR (Data Register) */
+        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
+        subs  x3, x3, #1
+        b.ne  1b
+        ret
+
+hex:    .ascii "0123456789abcdef"
+        .align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:   mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
new file mode 100644
index 0000000..d1f66e5
--- /dev/null
+++ b/xen/arch/arm/arm64/mode_switch.S
@@ -0,0 +1,83 @@
+/*
+ * xen/arch/arm/arm64/mode_switch.S
+ *
+ * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
+        bootwrapper.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+/* Get up a CPU into EL2.  Clobbers x0-x3.
+ *
+ * Expects x22 == CPU number
+ * Expects x30  == EL2 entry point
+ *
+ * This code is specific to the VE model, and not intended to be used
+ * on production systems.  As such it's a bit hackier than the main
+ * boot code in head.S.  In future it will be replaced by better
+ * integration with the bootloader/firmware so that Xen always starts
+ * at EL2.
+ */
+
+.globl enter_el2_mode
+enter_el2_mode:
+        mov     x0, #0x30                       // RES1
+        orr     x0, x0, #(1 << 0)               // Non-secure EL1
+        orr     x0, x0, #(1 << 8)               // HVC enable
+        orr     x0, x0, #(1 << 10)              // 64-bit EL2
+        msr     scr_el3, x0
+
+        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
+
+        ldr     x0, =0x01800000                 // 24Mhz
+        msr     cntfrq_el0, x0
+
+        /*
+         * Check for the primary CPU to avoid a race on the distributor
+         * registers.
+         */
+        cbnz    x22, 1f
+
+        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
+        mov     w0, #~0                         // Grp1 interrupts
+        str     w0, [x1], #4
+        b.ne    2f                              // Only local interrupts for secondary CPUs
+        str     w0, [x1], #4
+        str     w0, [x1], #4
+
+2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
+        ldr     w0, [x1]
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
+        str     w0, [x1, #4]                    // GICC_PMR
+
+        msr     sctlr_el2, xzr
+
+        /*
+         * Prepare the switch to the EL2_SP1 mode from EL3
+         */
+        msr     elr_el3, x30                    // Return to desired function
+        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+        msr     spsr_el3, x1
+        eret
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..b1f0a78 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -11,7 +11,13 @@
 
 ENTRY(start)
 
-OUTPUT_ARCH(arm)
+#if defined(__arm__)
+#define FORMAT arm
+#elif defined(__aarch64__)
+#define FORMAT aarch64
+#endif
+
+OUTPUT_ARCH(FORMAT)
 
 PHDRS
 {
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 9acd0af..e0a636f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -38,6 +38,7 @@
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
+#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
 
 /*
  * Attribute Indexes.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 8dd9062..dc12524 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -174,6 +174,8 @@ typedef uint64_t xen_callback_t;
 
 /* 0-4: Mode */
 #define PSR_MODE_MASK 0x1f
+
+/* 32 bit modes */
 #define PSR_MODE_USR 0x10
 #define PSR_MODE_FIQ 0x11
 #define PSR_MODE_IRQ 0x12
@@ -184,6 +186,18 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
+/* 64 bit modes */
+#ifdef CONFIG_ARM_64
+#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
+#define PSR_MODE_EL3h 0x0d
+#define PSR_MODE_EL3t 0x0c
+#define PSR_MODE_EL2h 0x09
+#define PSR_MODE_EL2t 0x08
+#define PSR_MODE_EL1h 0x05
+#define PSR_MODE_EL1t 0x04
+#define PSR_MODE_EL0t 0x00
+#endif
+
 #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
 #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
 #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index 5538d8e..cc8b5fd 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "../arch-x86/hvm/save.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined(__aarch64__)
 #include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 846f446..a1927c0 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -31,7 +31,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "arch-x86/xen.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined (__aarch64__)
 #include "arch-arm.h"
 #else
 #error "Unsupported architecture"
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index e8f6508..218bb18 100644
--- 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(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.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 Feb 14 16:48:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61yj-0007zR-DZ; Thu, 14 Feb 2013 16:48: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 1U61yg-0007xw-Qs
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:07 +0000
Received: from [85.158.139.83:49615] by server-13.bemta-5.messagelabs.com id
	71/86-06769-6451D115; Thu, 14 Feb 2013 16:48:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360860481!26923536!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20208 invoked from network); 14 Feb 2013 16:48:04 -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;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159747"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-2v;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:19 +0000
Message-ID: <1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 05/46] xen: arm64: initial build + config
	changes, start of day 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
      defining in head.S
    - Nuke hard tabs in head.S and mode_switch.S with expand(1)
---
 Config.mk                        |    2 +-
 config/arm64.mk                  |   12 ++
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/Rules.mk            |    6 +
 xen/arch/arm/arm64/Makefile      |    1 +
 xen/arch/arm/arm64/head.S        |  394 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
 xen/arch/arm/xen.lds.S           |    8 +-
 xen/include/asm-arm/page.h       |    1 +
 xen/include/public/arch-arm.h    |   14 ++
 xen/include/public/hvm/save.h    |    2 +-
 xen/include/public/xen.h         |    2 +-
 xen/include/xen/libelf.h         |    2 +-
 13 files changed, 523 insertions(+), 5 deletions(-)
 create mode 100644 config/arm64.mk
 create mode 100644 xen/arch/arm/arm64/Makefile
 create mode 100644 xen/arch/arm/arm64/head.S
 create mode 100644 xen/arch/arm/arm64/mode_switch.S

diff --git a/Config.mk b/Config.mk
index 64541c8..ea64925 100644
--- a/Config.mk
+++ b/Config.mk
@@ -15,7 +15,7 @@ debug_symbols ?= $(debug)
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
-                         -e s/armv7.*/arm32/)
+                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
 
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
diff --git a/config/arm64.mk b/config/arm64.mk
new file mode 100644
index 0000000..b2457eb
--- /dev/null
+++ b/config/arm64.mk
@@ -0,0 +1,12 @@
+CONFIG_ARM := y
+CONFIG_ARM_64 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+CFLAGS += #-marm -march= -mcpu= etc
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+LDFLAGS_DIRECT += -maarch64elf
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f2822f2..7ff67c7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-$(arm64) += arm64
 
 obj-y += early_printk.o
 obj-y += domain.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 5b5768a..29b605d 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -26,6 +26,12 @@ arm32 := y
 arm64 := n
 endif
 
+ifeq ($(TARGET_SUBARCH),arm64)
+CFLAGS += -mcpu=generic
+arm32 := n
+arm64 := y
+endif
+
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
new file mode 100644
index 0000000..dffbeb1
--- /dev/null
+++ b/xen/arch/arm/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
new file mode 100644
index 0000000..847043b
--- /dev/null
+++ b/xen/arch/arm/arm64/head.S
@@ -0,0 +1,394 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv8.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * Based on ARMv7-A head.S by
+ * Tim Deegan <tim@xen.org>
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
+#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
+#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
+#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+        adr   x0, 98f ; \
+        bl    puts    ; \
+        b     99f     ; \
+98:     .asciz _s     ; \
+        .align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+        /*.aarch64*/
+
+        /*
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * The requirements are:
+         *   MMU = off, D-cache = off, I-cache = on or off,
+         *   x0 = physical address to the FDT blob.
+         *
+         * This must be the very first address in the loaded image.
+         * It should be linked at XEN_VIRT_START, and loaded at any
+         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+         * or the initial pagetable code below will need adjustment.
+         */
+
+        .global start
+start:
+        /*
+         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
+         */
+        b       real_start           /* branch to kernel start, magic */
+        .long   0                    /* reserved */
+        .quad   0                    /* Image load offset from start of RAM */
+        .quad   0                    /* reserved */
+        .quad   0                    /* reserved */
+
+real_start:
+        msr   DAIFSet, 0xf           /* Disable all interrupts */
+
+        /* Save the bootloader arguments in less-clobberable registers */
+        mov   x21, x0                /* x21 := DTB, physical address  */
+
+        /* Find out where we are */
+        ldr   x0, =start
+        adr   x19, start             /* x19 := paddr (start) */
+        sub   x20, x19, x0           /* x20 := phys-offset */
+
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   x21, =_sdtb
+        add   x21, x21, x20          /* x21 := paddr(DTB) */
+#endif
+
+        /* Are we the boot CPU? */
+        mov   x22, #0                /* x22 := CPU ID */
+        mrs   x0, mpidr_el1
+        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
+        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
+
+        mov   x13, #(0xff << 24)
+        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
+        b.eq  boot_cpu               /* If we're CPU 0, boot now */
+
+        /* Non-boot CPUs wait here to be woken up one at a time. */
+1:      dsb   sy
+        ldr   x0, =smp_up_cpu        /* VA of gate */
+        add   x0, x0, x20            /* PA of gate */
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x22                /* Is it us? */
+        b.eq  2f
+        wfe
+        b     1b
+2:
+
+boot_cpu:
+#ifdef EARLY_UART_ADDRESS
+        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
+        cbnz  x22, 1f
+        bl    init_uart                 /* CPU 0 sets up the UART too */
+1:      PRINT("- CPU ")
+        mov   x0, x22
+        bl    putn
+        PRINT(" booting -\r\n")
+#endif
+
+        PRINT("- Current EL ")
+        mrs   x0, CurrentEL
+        bl    putn
+        PRINT(" -\r\n")
+
+        /* Are we in EL3 */
+        mrs   x0, CurrentEL
+        cmp   x0, #PSR_MODE_EL3t
+        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
+        b.eq  1f /* Yes */
+
+        /* Are we in EL2 */
+        cmp   x0, #PSR_MODE_EL2t
+        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
+        b.eq  2f /* Yes */
+
+        /* Otherwise, it must have been EL0 or EL1 */
+        PRINT("- CPU is not in EL3 or EL2 -\r\n")
+        b     fail
+
+1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
+        ldr   x1, =enter_el2_mode    /* VA of function */
+        add   x1, x1, x20            /* PA of function */
+        adr   x30, hyp               /* Set return address for call */
+        br    x1                     /* Call function */
+
+2:      PRINT("- Started in Hyp mode -\r\n")
+
+hyp:
+        /* Zero BSS On the boot CPU to avoid nasty surprises */
+        cbnz  x22, skip_bss
+
+        PRINT("- Zero BSS -\r\n")
+        ldr   x0, =__bss_start       /* Load start & end of bss */
+        ldr   x1, =__bss_end
+        add   x0, x0, x20            /* Apply physical offset */
+        add   x1, x1, x20
+
+1:      str   xzr, [x0], #8
+        cmp   x0, x1
+        b.lo  1b
+
+skip_bss:
+
+        PRINT("- Setting up control registers -\r\n")
+
+        /* Set up memory attribute type tables */
+        ldr   x0, =MAIRVAL
+        msr   mair_el2, x0
+
+        /* Set up the HTCR:
+         * PASize -- 4G
+         * Top byte is used
+         * PT walks use Outer-Shareable accesses,
+         * PT walks are write-back, no-write-allocate in both cache levels,
+         * Full 64-bit address space goes through this table. */
+        ldr   x0, =0x80802500
+        msr   tcr_el2, x0
+
+        /* Set up the HSCTLR:
+         * Exceptions in LE ARM,
+         * Low-latency IRQs disabled,
+         * Write-implies-XN disabled (for now),
+         * D-cache disabled (for now),
+         * I-cache enabled,
+         * Alignment checking enabled,
+         * MMU translation disabled (for now). */
+        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
+        msr   SCTLR_EL2, x0
+
+        /* Write Xen's PT's paddr into the HTTBR */
+        ldr   x4, =xen_pgtable
+        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
+        msr   TTBR0_EL2, x4
+
+        /* Non-boot CPUs don't need to rebuild the pagetable */
+        cbnz  x22, pt_ready
+
+        ldr   x1, =xen_first
+        add   x1, x1, x20            /* x1 := paddr (xen_first) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_first */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+
+        mov   x4, x1                 /* Next level into xen_first */
+
+       /* console fixmap */
+#ifdef EARLY_UART_ADDRESS
+        ldr   x1, =xen_fixmap
+        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
+        lsr   x2, x23, #12
+        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
+        mov   x3, #PT_DEV_L3
+        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
+        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
+#endif
+
+        /* Build the baseline idle pagetable's first-level entries */
+        ldr   x1, =xen_second
+        add   x1, x1, x20            /* x1 := paddr (xen_second) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_second */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
+
+        /* Now set up the second-level entries */
+        mov   x3, #PT_MEM
+        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
+        orr   x4, xzr, x19, lsr #18
+        str   x2, [x1, x4]           /* Map Xen there */
+        ldr   x4, =start
+        lsr   x4, x4, #18            /* Slot for vaddr(start) */
+        str   x2, [x1, x4]           /* Map Xen there too */
+
+        /* xen_fixmap pagetable */
+        ldr   x2, =xen_fixmap
+        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
+        mov   x3, #PT_PT
+        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
+
+        lsr   x2, x21, #21
+        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
+        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
+        orr   x2, x2, x3
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the early boot slot */
+
+pt_ready:
+        PRINT("- Turning on paging -\r\n")
+
+        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
+        mrs   x0, SCTLR_EL2
+        orr   x0, x0, #SCTLR_M       /* Enable MMU */
+        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
+        dsb   sy                     /* Flush PTE writes and finish reads */
+        msr   SCTLR_EL2, x0          /* now paging is enabled */
+        isb                          /* Now, flush the icache */
+        br    x1                     /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+        /* Use a virtual address to access the UART. */
+        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+#endif
+
+        PRINT("- Ready -\r\n")
+
+        /* The boot CPU should go straight into C now */
+        cbz   x22, launch
+
+        /* Non-boot CPUs need to move on to the relocated pagetables */
+        //mov   x0, #0
+        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
+        add   x4, x4, x20            /* PA of it */
+        ldr   x4, [x4]               /* Actual value */
+        dsb   sy
+        msr   TTBR0_EL2, x4
+        dsb   sy
+        isb
+        tlbi  alle2
+        dsb   sy                     /* Ensure completion of TLB flush */
+        isb
+
+        /* Non-boot CPUs report that they've got this far */
+        ldr   x0, =ready_cpus
+1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
+        add   x1, x1, #1             /* Atomically { ++                   } */
+        stlxr w2, x1, [x0]           /*            { writeback            } */
+        cbnz  w2, 1b
+        dsb   sy
+        dc    cvac, x0               /* Flush D-Cache */
+        dsb   sy
+
+        /* Here, the non-boot CPUs must wait again -- they're now running on
+         * the boot CPU's pagetables so it's safe for the boot CPU to
+         * overwrite the non-relocated copy of Xen.  Once it's done that,
+         * and brought up the memory allocator, non-boot CPUs can get their
+         * own stacks and enter C. */
+1:      wfe
+        dsb   sy
+        ldr   x0, =smp_up_cpu
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x12                /* Is it us? */
+        b.ne  1b
+
+launch:
+        ldr   x0, =init_stack        /* Find the boot-time stack */
+        ldr   x0, [x0]
+        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
+        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
+        mov   sp, x0
+
+        mov   x0, x20                /* Marshal args: - phys_offset */
+        mov   x1, x21                /*               - FDT */
+        mov   x2, x22                /*               - CPU ID */
+        cbz   x22, start_xen         /* and disappear into the land of C */
+        b     start_secondary        /* (to the appropriate entry point) */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:   PRINT("- Boot failed -\r\n")
+1:      wfe
+        b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+        mov   x1, #0x0
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+        mov   x1, #0x60              /* 8n1 */
+        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
+        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
+        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
+        adr   x0, 1f
+        b     puts
+1:      .asciz "- UART enabled -\r\n"
+        .align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  puts                   /* Wait for the UART to be ready */
+        ldrb  w2, [x0], #1           /* Load next char */
+        cbz   w2, 1f                 /* Exit on nul */
+        str   w2, [x23]              /* -> UARTDR (Data Register) */
+        b     puts
+1:
+        ret
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+        adr   x1, hex
+        mov   x3, #8
+1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  1b                     /* Wait for the UART to be ready */
+        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
+        lsr   x2, x2, #28
+        ldrb  w2, [x1, x2]           /* Convert to a char */
+        strb  w2, [x23]              /* -> UARTDR (Data Register) */
+        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
+        subs  x3, x3, #1
+        b.ne  1b
+        ret
+
+hex:    .ascii "0123456789abcdef"
+        .align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:   mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
new file mode 100644
index 0000000..d1f66e5
--- /dev/null
+++ b/xen/arch/arm/arm64/mode_switch.S
@@ -0,0 +1,83 @@
+/*
+ * xen/arch/arm/arm64/mode_switch.S
+ *
+ * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
+        bootwrapper.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+/* Get up a CPU into EL2.  Clobbers x0-x3.
+ *
+ * Expects x22 == CPU number
+ * Expects x30  == EL2 entry point
+ *
+ * This code is specific to the VE model, and not intended to be used
+ * on production systems.  As such it's a bit hackier than the main
+ * boot code in head.S.  In future it will be replaced by better
+ * integration with the bootloader/firmware so that Xen always starts
+ * at EL2.
+ */
+
+.globl enter_el2_mode
+enter_el2_mode:
+        mov     x0, #0x30                       // RES1
+        orr     x0, x0, #(1 << 0)               // Non-secure EL1
+        orr     x0, x0, #(1 << 8)               // HVC enable
+        orr     x0, x0, #(1 << 10)              // 64-bit EL2
+        msr     scr_el3, x0
+
+        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
+
+        ldr     x0, =0x01800000                 // 24Mhz
+        msr     cntfrq_el0, x0
+
+        /*
+         * Check for the primary CPU to avoid a race on the distributor
+         * registers.
+         */
+        cbnz    x22, 1f
+
+        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
+        mov     w0, #~0                         // Grp1 interrupts
+        str     w0, [x1], #4
+        b.ne    2f                              // Only local interrupts for secondary CPUs
+        str     w0, [x1], #4
+        str     w0, [x1], #4
+
+2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
+        ldr     w0, [x1]
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
+        str     w0, [x1, #4]                    // GICC_PMR
+
+        msr     sctlr_el2, xzr
+
+        /*
+         * Prepare the switch to the EL2_SP1 mode from EL3
+         */
+        msr     elr_el3, x30                    // Return to desired function
+        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+        msr     spsr_el3, x1
+        eret
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..b1f0a78 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -11,7 +11,13 @@
 
 ENTRY(start)
 
-OUTPUT_ARCH(arm)
+#if defined(__arm__)
+#define FORMAT arm
+#elif defined(__aarch64__)
+#define FORMAT aarch64
+#endif
+
+OUTPUT_ARCH(FORMAT)
 
 PHDRS
 {
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 9acd0af..e0a636f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -38,6 +38,7 @@
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
+#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
 
 /*
  * Attribute Indexes.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 8dd9062..dc12524 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -174,6 +174,8 @@ typedef uint64_t xen_callback_t;
 
 /* 0-4: Mode */
 #define PSR_MODE_MASK 0x1f
+
+/* 32 bit modes */
 #define PSR_MODE_USR 0x10
 #define PSR_MODE_FIQ 0x11
 #define PSR_MODE_IRQ 0x12
@@ -184,6 +186,18 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
+/* 64 bit modes */
+#ifdef CONFIG_ARM_64
+#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
+#define PSR_MODE_EL3h 0x0d
+#define PSR_MODE_EL3t 0x0c
+#define PSR_MODE_EL2h 0x09
+#define PSR_MODE_EL2t 0x08
+#define PSR_MODE_EL1h 0x05
+#define PSR_MODE_EL1t 0x04
+#define PSR_MODE_EL0t 0x00
+#endif
+
 #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
 #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
 #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index 5538d8e..cc8b5fd 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "../arch-x86/hvm/save.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined(__aarch64__)
 #include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 846f446..a1927c0 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -31,7 +31,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "arch-x86/xen.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined (__aarch64__)
 #include "arch-arm.h"
 #else
 #error "Unsupported architecture"
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index e8f6508..218bb18 100644
--- 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(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.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 Feb 14 16:48:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61yj-0007ze-Qr; Thu, 14 Feb 2013 16:48: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 1U61yi-0007yi-C9
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:08 +0000
Received: from [85.158.139.211:22028] by server-16.bemta-5.messagelabs.com id
	4C/11-14948-7451D115; Thu, 14 Feb 2013 16:48:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360860485!22524107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10374 invoked from network); 14 Feb 2013 16:48:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529947"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-5H;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:23 +0000
Message-ID: <1360860480-9245-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 09/46] xen: arm: refactor co-pro and sysreg
	reg 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

AArch64 has removed the concept of co-processors replacing them with a
combination of specific instructions (cache and tlb flushes etc) and
system registers (which are understood by name in the assembler).

However most system registers are equivalent to a particular AArch32
co-pro register and can be used by generic code in the same way. Note
that the names of the registers differ (often only slightly)

For consistency it would be better to use only set of names in the
common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
differ #defines will be provided on 32-bit.

HSR_CPREG and friends are required even on 64-bit in order to decode
traps from 32 bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/processor.h |   68 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/processor.h |   37 ++++++++++++++++++
 xen/include/asm-arm/cpregs.h          |   40 +++----------------
 xen/include/asm-arm/processor.h       |    9 +++-
 4 files changed, 118 insertions(+), 36 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/processor.h
 create mode 100644 xen/include/asm-arm/arm64/processor.h

diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
new file mode 100644
index 0000000..843fbd2
--- /dev/null
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -0,0 +1,68 @@
+#ifndef __ASM_ARM_ARM32_PROCESSOR_H
+#define __ASM_ARM_ARM32_PROCESSOR_H
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+#ifndef __ASSEMBLY__
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+/*
+ * C wrappers for accessing system registers.
+ *
+ * Registers come in 3 types:
+ * - those which are always 32-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG32).
+ * - those which are always 64-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG64).
+ * - those which vary between AArch32 and AArch64 (use {READ,WRITE}_SYSREG).
+ */
+#define READ_SYSREG32(R...)     READ_CP32(R)
+#define WRITE_SYSREG32(V, R...) WRITE_CP32(V, R)
+
+#define READ_SYSREG64(R...)     READ_CP64(R)
+#define WRITE_SYSREG64(V, R...) WRITE_CP64(V, R)
+
+#define READ_SYSREG(R...)       READ_SYSREG32(R)
+#define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM32_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
new file mode 100644
index 0000000..fdb0dab
--- /dev/null
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -0,0 +1,37 @@
+#ifndef __ASM_ARM_ARM64_PROCESSOR_H
+#define __ASM_ARM_ARM64_PROCESSOR_H
+
+#ifndef __ASSEMBLY__
+
+#define READ_SYSREG32(name) ({                          \
+    uint32_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+#define WRITE_SYSREG32(v, name) do {                    \
+    uint32_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+
+#define WRITE_SYSREG64(v, name) do {                    \
+    uint64_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+#define READ_SYSREG64(name) ({                          \
+    uint64_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+
+#define READ_SYSREG(name)     READ_SYSREG64(name)
+#define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM64_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 3b51845..7eaa50f 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -3,40 +3,12 @@
 
 #include <xen/stringify.h>
 
-/* Co-processor registers */
-
-/* Layout as used in assembly, with src/dest registers mixed in */
-#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
-#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
-#define CP32(r, name...) __CP32(r, name)
-#define CP64(r, name...) __CP64(r, name)
-
-/* Stringified for inline assembly */
-#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
-#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
-#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
-#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
-
-/* C wrappers */
-#define READ_CP32(name...) ({                                   \
-    register uint32_t _r;                                       \
-    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP32(v, name...) do {                             \
-    register uint32_t _r = (v);                                 \
-    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
-} while (0)
-
-#define READ_CP64(name...) ({                                   \
-    register uint64_t _r;                                       \
-    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP64(v, name...) do {                             \
-    register uint64_t _r = (v);                                 \
-    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
-} while (0)
+/*
+ * AArch32 Co-processor registers.
+ *
+ * Note that AArch64 requires many of these definitions in order to
+ * support 32-bit guests.
+ */
 
 #define __HSR_CPREG_c0  0
 #define __HSR_CPREG_c1  1
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 0c94f6b..0768cd4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -225,8 +225,13 @@ union hsr {
 #define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
 #define ID_PFR1_GT_v1    0x00010000
 
-#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
-#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/processor.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/processor.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #ifndef __ASSEMBLY__
 extern uint32_t hyp_traps_vector[8];
-- 
1.7.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 Feb 14 16:48:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16: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 1U61yj-0007ze-Qr; Thu, 14 Feb 2013 16:48: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 1U61yi-0007yi-C9
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:08 +0000
Received: from [85.158.139.211:22028] by server-16.bemta-5.messagelabs.com id
	4C/11-14948-7451D115; Thu, 14 Feb 2013 16:48:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360860485!22524107!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10374 invoked from network); 14 Feb 2013 16:48:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529947"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-5H;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:23 +0000
Message-ID: <1360860480-9245-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 09/46] xen: arm: refactor co-pro and sysreg
	reg 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

AArch64 has removed the concept of co-processors replacing them with a
combination of specific instructions (cache and tlb flushes etc) and
system registers (which are understood by name in the assembler).

However most system registers are equivalent to a particular AArch32
co-pro register and can be used by generic code in the same way. Note
that the names of the registers differ (often only slightly)

For consistency it would be better to use only set of names in the
common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
differ #defines will be provided on 32-bit.

HSR_CPREG and friends are required even on 64-bit in order to decode
traps from 32 bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/processor.h |   68 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/processor.h |   37 ++++++++++++++++++
 xen/include/asm-arm/cpregs.h          |   40 +++----------------
 xen/include/asm-arm/processor.h       |    9 +++-
 4 files changed, 118 insertions(+), 36 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/processor.h
 create mode 100644 xen/include/asm-arm/arm64/processor.h

diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
new file mode 100644
index 0000000..843fbd2
--- /dev/null
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -0,0 +1,68 @@
+#ifndef __ASM_ARM_ARM32_PROCESSOR_H
+#define __ASM_ARM_ARM32_PROCESSOR_H
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+#ifndef __ASSEMBLY__
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+/*
+ * C wrappers for accessing system registers.
+ *
+ * Registers come in 3 types:
+ * - those which are always 32-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG32).
+ * - those which are always 64-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG64).
+ * - those which vary between AArch32 and AArch64 (use {READ,WRITE}_SYSREG).
+ */
+#define READ_SYSREG32(R...)     READ_CP32(R)
+#define WRITE_SYSREG32(V, R...) WRITE_CP32(V, R)
+
+#define READ_SYSREG64(R...)     READ_CP64(R)
+#define WRITE_SYSREG64(V, R...) WRITE_CP64(V, R)
+
+#define READ_SYSREG(R...)       READ_SYSREG32(R)
+#define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM32_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
new file mode 100644
index 0000000..fdb0dab
--- /dev/null
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -0,0 +1,37 @@
+#ifndef __ASM_ARM_ARM64_PROCESSOR_H
+#define __ASM_ARM_ARM64_PROCESSOR_H
+
+#ifndef __ASSEMBLY__
+
+#define READ_SYSREG32(name) ({                          \
+    uint32_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+#define WRITE_SYSREG32(v, name) do {                    \
+    uint32_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+
+#define WRITE_SYSREG64(v, name) do {                    \
+    uint64_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+#define READ_SYSREG64(name) ({                          \
+    uint64_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+
+#define READ_SYSREG(name)     READ_SYSREG64(name)
+#define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM64_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 3b51845..7eaa50f 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -3,40 +3,12 @@
 
 #include <xen/stringify.h>
 
-/* Co-processor registers */
-
-/* Layout as used in assembly, with src/dest registers mixed in */
-#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
-#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
-#define CP32(r, name...) __CP32(r, name)
-#define CP64(r, name...) __CP64(r, name)
-
-/* Stringified for inline assembly */
-#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
-#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
-#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
-#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
-
-/* C wrappers */
-#define READ_CP32(name...) ({                                   \
-    register uint32_t _r;                                       \
-    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP32(v, name...) do {                             \
-    register uint32_t _r = (v);                                 \
-    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
-} while (0)
-
-#define READ_CP64(name...) ({                                   \
-    register uint64_t _r;                                       \
-    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP64(v, name...) do {                             \
-    register uint64_t _r = (v);                                 \
-    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
-} while (0)
+/*
+ * AArch32 Co-processor registers.
+ *
+ * Note that AArch64 requires many of these definitions in order to
+ * support 32-bit guests.
+ */
 
 #define __HSR_CPREG_c0  0
 #define __HSR_CPREG_c1  1
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 0c94f6b..0768cd4 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -225,8 +225,13 @@ union hsr {
 #define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
 #define ID_PFR1_GT_v1    0x00010000
 
-#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
-#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/processor.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/processor.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #ifndef __ASSEMBLY__
 extern uint32_t hyp_traps_vector[8];
-- 
1.7.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 Feb 14 16:48:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yh-0007yZ-PT; Thu, 14 Feb 2013 16:48:07 +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 1U61yg-0007x9-Gb
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:06 +0000
Received: from [85.158.139.211:49059] by server-4.bemta-5.messagelabs.com id
	71/74-29496-6451D115; Thu, 14 Feb 2013 16:48:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360860483!22241584!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16157 invoked from network); 14 Feb 2013 16:48:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159748"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-3S;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:20 +0000
Message-ID: <1360860480-9245-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 06/46] xen: arm64: basic config and types
	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

The 64-bit bitops are taken from the Linux asm-generic implementations. They
should be replaced with optimised versions from the Linux arm64 port when they
become available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: mention bitops heritage.
---
 xen/arch/arm/arm64/Makefile            |    2 +
 xen/arch/arm/arm64/lib/Makefile        |    1 +
 xen/arch/arm/arm64/lib/bitops.c        |   22 +++
 xen/arch/arm/arm64/lib/find_next_bit.c |  284 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm32/bitops.h     |   54 ++++++
 xen/include/asm-arm/arm64/bitops.h     |  283 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h           |   65 ++------
 xen/include/asm-arm/config.h           |   15 ++
 xen/include/asm-arm/types.h            |   17 ++-
 9 files changed, 686 insertions(+), 57 deletions(-)
 create mode 100644 xen/arch/arm/arm64/lib/Makefile
 create mode 100644 xen/arch/arm/arm64/lib/bitops.c
 create mode 100644 xen/arch/arm/arm64/lib/find_next_bit.c
 create mode 100644 xen/include/asm-arm/arm32/bitops.h
 create mode 100644 xen/include/asm-arm/arm64/bitops.h

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index dffbeb1..c447eaa 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1 +1,3 @@
+subdir-y += lib
+
 obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/lib/Makefile b/xen/arch/arm/arm64/lib/Makefile
new file mode 100644
index 0000000..32c02c4
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/Makefile
@@ -0,0 +1 @@
+obj-y += bitops.o find_next_bit.o
diff --git a/xen/arch/arm/arm64/lib/bitops.c b/xen/arch/arm/arm64/lib/bitops.c
new file mode 100644
index 0000000..02d8d78
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/bitops.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 ARM Limited
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/spinlock.h>
+#include <xen/bitops.h>
+
+spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] /*__lock_aligned*/ = {
+       [0 ... (ATOMIC_HASH_SIZE-1)]  = SPIN_LOCK_UNLOCKED
+};
diff --git a/xen/arch/arm/arm64/lib/find_next_bit.c b/xen/arch/arm/arm64/lib/find_next_bit.c
new file mode 100644
index 0000000..aea69c2
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/find_next_bit.c
@@ -0,0 +1,284 @@
+/* find_next_bit.c: fallback find next bit implementation
+ *
+ * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * 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 of the License, or (at your option) any later version.
+ */
+#include <xen/config.h>
+#include <xen/bitops.h>
+#include <asm/types.h>
+#include <asm/byteorder.h>
+
+#define BITOP_WORD(nr)		((nr) / BITS_PER_LONG)
+
+#ifndef find_next_bit
+/*
+ * Find the next set bit in a memory region.
+ */
+unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
+			    unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_next_bit);
+#endif
+
+#ifndef find_next_zero_bit
+/*
+ * This implementation of find_{first,next}_zero_bit was stolen from
+ * Linus' asm-alpha/bitops.h.
+ */
+unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
+				 unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp |= ~0UL >> (BITS_PER_LONG - offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_next_zero_bit);
+#endif
+
+#ifndef find_first_bit
+/*
+ * Find the first set bit in a memory region.
+ */
+unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) & (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_first_bit);
+#endif
+
+#ifndef find_first_zero_bit
+/*
+ * Find the first cleared bit in a memory region.
+ */
+unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) | (~0UL << size);
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_first_zero_bit);
+#endif
+
+#ifdef __BIG_ENDIAN
+
+/* include/linux/byteorder does not support "unsigned long" type */
+static inline unsigned long ext2_swabp(const unsigned long * x)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64p((u64 *) x);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32p((u32 *) x);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+/* include/linux/byteorder doesn't support "unsigned long" type */
+static inline unsigned long ext2_swab(const unsigned long y)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64((u64) y);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32((u32) y);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+#ifndef find_next_zero_bit_le
+unsigned long find_next_zero_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp |= (~0UL >> (BITS_PER_LONG - offset));
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size; /* Nope. Skip ffz */
+found_middle:
+	return result + ffz(tmp);
+
+found_middle_swap:
+	return result + ffz(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_zero_bit_le);
+#endif
+
+#ifndef find_next_bit_le
+unsigned long find_next_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		tmp = *(p++);
+		if (tmp)
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size; /* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+
+found_middle_swap:
+	return result + __ffs(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_bit_le);
+#endif
+
+#endif /* __BIG_ENDIAN */
diff --git a/xen/include/asm-arm/arm32/bitops.h b/xen/include/asm-arm/arm32/bitops.h
new file mode 100644
index 0000000..0d05258
--- /dev/null
+++ b/xen/include/asm-arm/arm32/bitops.h
@@ -0,0 +1,54 @@
+#ifndef _ARM_ARM32_BITOPS_H
+#define _ARM_ARM32_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+#endif /* _ARM_ARM32_BITOPS_H */
diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
new file mode 100644
index 0000000..847d65c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -0,0 +1,283 @@
+#ifndef _ARM_ARM64_BITOPS_H
+#define _ARM_ARM64_BITOPS_H
+
+/* Generic bitop support. Based on linux/include/asm-generic/bitops/atomic.h */
+
+#include <xen/spinlock.h>
+#include <xen/cache.h>          /* we use L1_CACHE_BYTES */
+
+/* Use an array of spinlocks for our atomic_ts.
+ * Hash function to index into a different SPINLOCK.
+ * Since "a" is usually an address, use one spinlock per cacheline.
+ */
+#  define ATOMIC_HASH_SIZE 4
+#  define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) a)/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
+
+extern spinlock_t __atomic_hash[ATOMIC_HASH_SIZE]/* __lock_aligned*/;
+
+#define _atomic_spin_lock_irqsave(l,f) do {     \
+       spinlock_t *s = ATOMIC_HASH(l);          \
+       spin_lock_irqsave(s, f);\
+} while(0)
+
+#define _atomic_spin_unlock_irqrestore(l,f) do {\
+        spinlock_t *s = ATOMIC_HASH(l);         \
+        spin_unlock_irqrestore(s,f);		\
+} while(0)
+
+#define FIXUP(_p, _mask)                        \
+    {                                           \
+        unsigned long __p = (unsigned long)_p;  \
+        if (__p & 0x7) {                        \
+            if (_mask > 0xffffffff) {           \
+             __p = (__p+32)&~0x7; _mask >>=32;  \
+            } else {                            \
+                __p &= ~0x7; _mask <<= 32;      \
+            }                                   \
+            if (0)printk("BITOPS: Fixup misaligned ptr %p => %#lx\n", _p, __p); \
+            _p = (void *)__p;                   \
+        }                                       \
+    }
+
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * This function is atomic and may not be reordered.  See __set_bit()
+ * if you do not require the atomic guarantees.
+ *
+ * Note: there are no guarantees that this function will not be reordered
+ * on non x86 architectures, so if you are writing portable code,
+ * make sure not to rely on its reordering guarantees.
+ *
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+
+static inline void set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        FIXUP(p, mask);
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        //printk("before *p is %#lx\n", *p);
+	_atomic_spin_lock_irqsave(p, flags);
+	*p  |= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+        //printk(" after *p is %#lx\n", *p);
+}
+
+/**
+ * clear_bit - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and may not be reordered.  However, it does
+ * not contain a memory barrier, so if it is used for locking purposes,
+ * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * in order to ensure changes are visible on other processors.
+ */
+static inline void clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p &= ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * change_bit - Toggle a bit in memory
+ * @nr: Bit to change
+ * @addr: Address to start counting from
+ *
+ * change_bit() is atomic and may not be reordered. It may be
+ * reordered on other architectures than x86.
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+static inline void change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p ^= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It may be reordered on other architectures than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old | mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It can be reorderdered on other architectures other than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old & ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_change_bit - Change a bit and return its old value
+ * @nr: Bit to change
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old ^ mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
+/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static /*__*/always_inline unsigned long __ffs(unsigned long word)
+{
+        return __builtin_ctzl(word);
+}
+
+/* Based on linux/include/asm-generic/bitops/ffz.h */
+/*
+ * ffz - find first zero in word.
+ * @word: The word to search
+ *
+ * Undefined if no zero exists, so code should check against ~0UL first.
+ */
+#define ffz(x)  __ffs(~(x))
+
+
+
+/* Based on linux/include/asm-generic/bitops/find.h */
+
+#ifndef find_next_bit
+/**
+ * find_next_bit - find the next set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
+		size, unsigned long offset);
+#endif
+
+#ifndef find_next_zero_bit
+/**
+ * find_next_zero_bit - find the next cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
+		long size, unsigned long offset);
+#endif
+
+#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
+
+/**
+ * find_first_bit - find the first set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first set bit.
+ */
+extern unsigned long find_first_bit(const unsigned long *addr,
+				    unsigned long size);
+
+/**
+ * find_first_zero_bit - find the first cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first cleared bit.
+ */
+extern unsigned long find_first_zero_bit(const unsigned long *addr,
+					 unsigned long size);
+#else /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
+#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 0)
+
+#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+
+#endif /* _ARM_ARM64_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
index 87de5db..563b4be 100644
--- a/xen/include/asm-arm/bitops.h
+++ b/xen/include/asm-arm/bitops.h
@@ -9,28 +9,14 @@
 #ifndef _ARM_BITOPS_H
 #define _ARM_BITOPS_H
 
-extern void _set_bit(int nr, volatile void * p);
-extern void _clear_bit(int nr, volatile void * p);
-extern void _change_bit(int nr, volatile void * p);
-extern int _test_and_set_bit(int nr, volatile void * p);
-extern int _test_and_clear_bit(int nr, volatile void * p);
-extern int _test_and_change_bit(int nr, volatile void * p);
-
-#define set_bit(n,p)              _set_bit(n,p)
-#define clear_bit(n,p)            _clear_bit(n,p)
-#define change_bit(n,p)           _change_bit(n,p)
-#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
-#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
-#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
-
 /*
  * Non-atomic bit manipulation.
  *
  * Implemented using atomics to be interrupt safe. Could alternatively
  * implement with local interrupt masking.
  */
-#define __set_bit(n,p)            _set_bit(n,p)
-#define __clear_bit(n,p)          _clear_bit(n,p)
+#define __set_bit(n,p)            set_bit(n,p)
+#define __clear_bit(n,p)          clear_bit(n,p)
 
 #define BIT(nr)                 (1UL << (nr))
 #define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
@@ -40,6 +26,14 @@ extern int _test_and_change_bit(int nr, volatile void * p);
 #define ADDR (*(volatile long *) addr)
 #define CONST_ADDR (*(const volatile long *) addr)
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/bitops.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/bitops.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /**
  * __test_and_set_bit - Set a bit and return its old value
  * @nr: Bit to set
@@ -104,42 +98,6 @@ static inline int test_bit(int nr, const volatile void *addr)
         return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
 }
 
-/*
- * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
- */
-extern int _find_first_zero_bit_le(const void * p, unsigned size);
-extern int _find_next_zero_bit_le(const void * p, int size, int offset);
-extern int _find_first_bit_le(const unsigned long *p, unsigned size);
-extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
-
-/*
- * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
- */
-extern int _find_first_zero_bit_be(const void * p, unsigned size);
-extern int _find_next_zero_bit_be(const void * p, int size, int offset);
-extern int _find_first_bit_be(const unsigned long *p, unsigned size);
-extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
-
-#ifndef __ARMEB__
-/*
- * These are the little endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
-
-#else
-/*
- * These are the big endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
-
-#endif
-
 static inline int constant_fls(int x)
 {
         int r = 32;
@@ -182,10 +140,11 @@ static inline int fls(int x)
                return constant_fls(x);
 
         asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
-        ret = 32 - ret;
+        ret = BITS_PER_LONG - ret;
         return ret;
 }
 
+
 #define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
 
 /**
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index e5dce5e..add70bd 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -7,6 +7,21 @@
 #ifndef __ARM_CONFIG_H__
 #define __ARM_CONFIG_H__
 
+#if defined(__aarch64__)
+# define CONFIG_ARM_64 1
+#elif defined(__arm__)
+# define CONFIG_ARM_32 1
+#endif
+
+#if defined(CONFIG_ARM_64)
+# define LONG_BYTEORDER 3
+#else
+# define LONG_BYTEORDER 2
+#endif
+
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
+#define BITS_PER_LONG (BYTES_PER_LONG << 3)
+
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..07f7898 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -15,8 +15,13 @@ typedef __signed__ int __s32;
 typedef unsigned int __u32;
 
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#if defined(CONFIG_ARM_32)
 typedef __signed__ long long __s64;
 typedef unsigned long long __u64;
+#elif defined (CONFIG_ARM_64)
+typedef __signed__ long __s64;
+typedef unsigned long __u64;
+#endif
 #endif
 
 typedef signed char s8;
@@ -28,11 +33,19 @@ typedef unsigned short u16;
 typedef signed int s32;
 typedef unsigned int u32;
 
+#if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+#elif defined (CONFIG_ARM_64)
+typedef signed long s64;
+typedef unsigned long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "016lx"
+#endif
 
 typedef unsigned long size_t;
 
@@ -42,10 +55,6 @@ typedef char bool_t;
 
 #endif /* __ASSEMBLY__ */
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
-#define LONG_BYTEORDER 2
-
 #endif /* __ARM_TYPES_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 14 16:48:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yh-0007yZ-PT; Thu, 14 Feb 2013 16:48:07 +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 1U61yg-0007x9-Gb
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:06 +0000
Received: from [85.158.139.211:49059] by server-4.bemta-5.messagelabs.com id
	71/74-29496-6451D115; Thu, 14 Feb 2013 16:48:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360860483!22241584!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16157 invoked from network); 14 Feb 2013 16:48:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159748"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-3S;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:20 +0000
Message-ID: <1360860480-9245-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 06/46] xen: arm64: basic config and types
	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

The 64-bit bitops are taken from the Linux asm-generic implementations. They
should be replaced with optimised versions from the Linux arm64 port when they
become available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: mention bitops heritage.
---
 xen/arch/arm/arm64/Makefile            |    2 +
 xen/arch/arm/arm64/lib/Makefile        |    1 +
 xen/arch/arm/arm64/lib/bitops.c        |   22 +++
 xen/arch/arm/arm64/lib/find_next_bit.c |  284 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm32/bitops.h     |   54 ++++++
 xen/include/asm-arm/arm64/bitops.h     |  283 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h           |   65 ++------
 xen/include/asm-arm/config.h           |   15 ++
 xen/include/asm-arm/types.h            |   17 ++-
 9 files changed, 686 insertions(+), 57 deletions(-)
 create mode 100644 xen/arch/arm/arm64/lib/Makefile
 create mode 100644 xen/arch/arm/arm64/lib/bitops.c
 create mode 100644 xen/arch/arm/arm64/lib/find_next_bit.c
 create mode 100644 xen/include/asm-arm/arm32/bitops.h
 create mode 100644 xen/include/asm-arm/arm64/bitops.h

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index dffbeb1..c447eaa 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1 +1,3 @@
+subdir-y += lib
+
 obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/lib/Makefile b/xen/arch/arm/arm64/lib/Makefile
new file mode 100644
index 0000000..32c02c4
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/Makefile
@@ -0,0 +1 @@
+obj-y += bitops.o find_next_bit.o
diff --git a/xen/arch/arm/arm64/lib/bitops.c b/xen/arch/arm/arm64/lib/bitops.c
new file mode 100644
index 0000000..02d8d78
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/bitops.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 ARM Limited
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/spinlock.h>
+#include <xen/bitops.h>
+
+spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] /*__lock_aligned*/ = {
+       [0 ... (ATOMIC_HASH_SIZE-1)]  = SPIN_LOCK_UNLOCKED
+};
diff --git a/xen/arch/arm/arm64/lib/find_next_bit.c b/xen/arch/arm/arm64/lib/find_next_bit.c
new file mode 100644
index 0000000..aea69c2
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/find_next_bit.c
@@ -0,0 +1,284 @@
+/* find_next_bit.c: fallback find next bit implementation
+ *
+ * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * 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 of the License, or (at your option) any later version.
+ */
+#include <xen/config.h>
+#include <xen/bitops.h>
+#include <asm/types.h>
+#include <asm/byteorder.h>
+
+#define BITOP_WORD(nr)		((nr) / BITS_PER_LONG)
+
+#ifndef find_next_bit
+/*
+ * Find the next set bit in a memory region.
+ */
+unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
+			    unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_next_bit);
+#endif
+
+#ifndef find_next_zero_bit
+/*
+ * This implementation of find_{first,next}_zero_bit was stolen from
+ * Linus' asm-alpha/bitops.h.
+ */
+unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
+				 unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp |= ~0UL >> (BITS_PER_LONG - offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_next_zero_bit);
+#endif
+
+#ifndef find_first_bit
+/*
+ * Find the first set bit in a memory region.
+ */
+unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) & (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_first_bit);
+#endif
+
+#ifndef find_first_zero_bit
+/*
+ * Find the first cleared bit in a memory region.
+ */
+unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) | (~0UL << size);
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_first_zero_bit);
+#endif
+
+#ifdef __BIG_ENDIAN
+
+/* include/linux/byteorder does not support "unsigned long" type */
+static inline unsigned long ext2_swabp(const unsigned long * x)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64p((u64 *) x);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32p((u32 *) x);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+/* include/linux/byteorder doesn't support "unsigned long" type */
+static inline unsigned long ext2_swab(const unsigned long y)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64((u64) y);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32((u32) y);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+#ifndef find_next_zero_bit_le
+unsigned long find_next_zero_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp |= (~0UL >> (BITS_PER_LONG - offset));
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size; /* Nope. Skip ffz */
+found_middle:
+	return result + ffz(tmp);
+
+found_middle_swap:
+	return result + ffz(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_zero_bit_le);
+#endif
+
+#ifndef find_next_bit_le
+unsigned long find_next_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		tmp = *(p++);
+		if (tmp)
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size; /* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+
+found_middle_swap:
+	return result + __ffs(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_bit_le);
+#endif
+
+#endif /* __BIG_ENDIAN */
diff --git a/xen/include/asm-arm/arm32/bitops.h b/xen/include/asm-arm/arm32/bitops.h
new file mode 100644
index 0000000..0d05258
--- /dev/null
+++ b/xen/include/asm-arm/arm32/bitops.h
@@ -0,0 +1,54 @@
+#ifndef _ARM_ARM32_BITOPS_H
+#define _ARM_ARM32_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+#endif /* _ARM_ARM32_BITOPS_H */
diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
new file mode 100644
index 0000000..847d65c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -0,0 +1,283 @@
+#ifndef _ARM_ARM64_BITOPS_H
+#define _ARM_ARM64_BITOPS_H
+
+/* Generic bitop support. Based on linux/include/asm-generic/bitops/atomic.h */
+
+#include <xen/spinlock.h>
+#include <xen/cache.h>          /* we use L1_CACHE_BYTES */
+
+/* Use an array of spinlocks for our atomic_ts.
+ * Hash function to index into a different SPINLOCK.
+ * Since "a" is usually an address, use one spinlock per cacheline.
+ */
+#  define ATOMIC_HASH_SIZE 4
+#  define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) a)/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
+
+extern spinlock_t __atomic_hash[ATOMIC_HASH_SIZE]/* __lock_aligned*/;
+
+#define _atomic_spin_lock_irqsave(l,f) do {     \
+       spinlock_t *s = ATOMIC_HASH(l);          \
+       spin_lock_irqsave(s, f);\
+} while(0)
+
+#define _atomic_spin_unlock_irqrestore(l,f) do {\
+        spinlock_t *s = ATOMIC_HASH(l);         \
+        spin_unlock_irqrestore(s,f);		\
+} while(0)
+
+#define FIXUP(_p, _mask)                        \
+    {                                           \
+        unsigned long __p = (unsigned long)_p;  \
+        if (__p & 0x7) {                        \
+            if (_mask > 0xffffffff) {           \
+             __p = (__p+32)&~0x7; _mask >>=32;  \
+            } else {                            \
+                __p &= ~0x7; _mask <<= 32;      \
+            }                                   \
+            if (0)printk("BITOPS: Fixup misaligned ptr %p => %#lx\n", _p, __p); \
+            _p = (void *)__p;                   \
+        }                                       \
+    }
+
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * This function is atomic and may not be reordered.  See __set_bit()
+ * if you do not require the atomic guarantees.
+ *
+ * Note: there are no guarantees that this function will not be reordered
+ * on non x86 architectures, so if you are writing portable code,
+ * make sure not to rely on its reordering guarantees.
+ *
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+
+static inline void set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        FIXUP(p, mask);
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        //printk("before *p is %#lx\n", *p);
+	_atomic_spin_lock_irqsave(p, flags);
+	*p  |= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+        //printk(" after *p is %#lx\n", *p);
+}
+
+/**
+ * clear_bit - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and may not be reordered.  However, it does
+ * not contain a memory barrier, so if it is used for locking purposes,
+ * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * in order to ensure changes are visible on other processors.
+ */
+static inline void clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p &= ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * change_bit - Toggle a bit in memory
+ * @nr: Bit to change
+ * @addr: Address to start counting from
+ *
+ * change_bit() is atomic and may not be reordered. It may be
+ * reordered on other architectures than x86.
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+static inline void change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p ^= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It may be reordered on other architectures than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old | mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It can be reorderdered on other architectures other than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old & ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_change_bit - Change a bit and return its old value
+ * @nr: Bit to change
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old ^ mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
+/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static /*__*/always_inline unsigned long __ffs(unsigned long word)
+{
+        return __builtin_ctzl(word);
+}
+
+/* Based on linux/include/asm-generic/bitops/ffz.h */
+/*
+ * ffz - find first zero in word.
+ * @word: The word to search
+ *
+ * Undefined if no zero exists, so code should check against ~0UL first.
+ */
+#define ffz(x)  __ffs(~(x))
+
+
+
+/* Based on linux/include/asm-generic/bitops/find.h */
+
+#ifndef find_next_bit
+/**
+ * find_next_bit - find the next set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
+		size, unsigned long offset);
+#endif
+
+#ifndef find_next_zero_bit
+/**
+ * find_next_zero_bit - find the next cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
+		long size, unsigned long offset);
+#endif
+
+#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
+
+/**
+ * find_first_bit - find the first set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first set bit.
+ */
+extern unsigned long find_first_bit(const unsigned long *addr,
+				    unsigned long size);
+
+/**
+ * find_first_zero_bit - find the first cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first cleared bit.
+ */
+extern unsigned long find_first_zero_bit(const unsigned long *addr,
+					 unsigned long size);
+#else /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
+#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 0)
+
+#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+
+#endif /* _ARM_ARM64_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
index 87de5db..563b4be 100644
--- a/xen/include/asm-arm/bitops.h
+++ b/xen/include/asm-arm/bitops.h
@@ -9,28 +9,14 @@
 #ifndef _ARM_BITOPS_H
 #define _ARM_BITOPS_H
 
-extern void _set_bit(int nr, volatile void * p);
-extern void _clear_bit(int nr, volatile void * p);
-extern void _change_bit(int nr, volatile void * p);
-extern int _test_and_set_bit(int nr, volatile void * p);
-extern int _test_and_clear_bit(int nr, volatile void * p);
-extern int _test_and_change_bit(int nr, volatile void * p);
-
-#define set_bit(n,p)              _set_bit(n,p)
-#define clear_bit(n,p)            _clear_bit(n,p)
-#define change_bit(n,p)           _change_bit(n,p)
-#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
-#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
-#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
-
 /*
  * Non-atomic bit manipulation.
  *
  * Implemented using atomics to be interrupt safe. Could alternatively
  * implement with local interrupt masking.
  */
-#define __set_bit(n,p)            _set_bit(n,p)
-#define __clear_bit(n,p)          _clear_bit(n,p)
+#define __set_bit(n,p)            set_bit(n,p)
+#define __clear_bit(n,p)          clear_bit(n,p)
 
 #define BIT(nr)                 (1UL << (nr))
 #define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
@@ -40,6 +26,14 @@ extern int _test_and_change_bit(int nr, volatile void * p);
 #define ADDR (*(volatile long *) addr)
 #define CONST_ADDR (*(const volatile long *) addr)
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/bitops.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/bitops.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /**
  * __test_and_set_bit - Set a bit and return its old value
  * @nr: Bit to set
@@ -104,42 +98,6 @@ static inline int test_bit(int nr, const volatile void *addr)
         return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
 }
 
-/*
- * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
- */
-extern int _find_first_zero_bit_le(const void * p, unsigned size);
-extern int _find_next_zero_bit_le(const void * p, int size, int offset);
-extern int _find_first_bit_le(const unsigned long *p, unsigned size);
-extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
-
-/*
- * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
- */
-extern int _find_first_zero_bit_be(const void * p, unsigned size);
-extern int _find_next_zero_bit_be(const void * p, int size, int offset);
-extern int _find_first_bit_be(const unsigned long *p, unsigned size);
-extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
-
-#ifndef __ARMEB__
-/*
- * These are the little endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
-
-#else
-/*
- * These are the big endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
-
-#endif
-
 static inline int constant_fls(int x)
 {
         int r = 32;
@@ -182,10 +140,11 @@ static inline int fls(int x)
                return constant_fls(x);
 
         asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
-        ret = 32 - ret;
+        ret = BITS_PER_LONG - ret;
         return ret;
 }
 
+
 #define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
 
 /**
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index e5dce5e..add70bd 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -7,6 +7,21 @@
 #ifndef __ARM_CONFIG_H__
 #define __ARM_CONFIG_H__
 
+#if defined(__aarch64__)
+# define CONFIG_ARM_64 1
+#elif defined(__arm__)
+# define CONFIG_ARM_32 1
+#endif
+
+#if defined(CONFIG_ARM_64)
+# define LONG_BYTEORDER 3
+#else
+# define LONG_BYTEORDER 2
+#endif
+
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
+#define BITS_PER_LONG (BYTES_PER_LONG << 3)
+
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..07f7898 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -15,8 +15,13 @@ typedef __signed__ int __s32;
 typedef unsigned int __u32;
 
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#if defined(CONFIG_ARM_32)
 typedef __signed__ long long __s64;
 typedef unsigned long long __u64;
+#elif defined (CONFIG_ARM_64)
+typedef __signed__ long __s64;
+typedef unsigned long __u64;
+#endif
 #endif
 
 typedef signed char s8;
@@ -28,11 +33,19 @@ typedef unsigned short u16;
 typedef signed int s32;
 typedef unsigned int u32;
 
+#if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+#elif defined (CONFIG_ARM_64)
+typedef signed long s64;
+typedef unsigned long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "016lx"
+#endif
 
 typedef unsigned long size_t;
 
@@ -42,10 +55,6 @@ typedef char bool_t;
 
 #endif /* __ASSEMBLY__ */
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
-#define LONG_BYTEORDER 2
-
 #endif /* __ARM_TYPES_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 14 16:48:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yl-00081H-TU; Thu, 14 Feb 2013 16:48: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 1U61yj-0007xw-Nr
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:10 +0000
Received: from [85.158.139.211:49234] by server-13.bemta-5.messagelabs.com id
	5B/96-06769-9451D115; Thu, 14 Feb 2013 16:48:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360860485!22524107!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10504 invoked from network); 14 Feb 2013 16:48:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529948"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-6v;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:24 +0000
Message-ID: <1360860480-9245-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 10/46] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
v2: remove comment wondering if they should be inner-shareable flushes, they
    shouldn't for now.

    combine with other patch titled "TLB flushes." which followed in a couple
    of patches time.

    remove flush_guest_tlb(), nothing was calling it

    remove stray reference to flush branch predictor, which isn't necessary on
    64-bit.
---
 xen/include/asm-arm/arm32/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm32/page.h     |   69 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm64/page.h     |   67 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/flushtlb.h       |   34 +++++------------
 xen/include/asm-arm/page.h           |   67 ++++-----------------------------
 6 files changed, 222 insertions(+), 83 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm32/page.h
 create mode 100644 xen/include/asm-arm/arm64/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm64/page.h

diff --git a/xen/include/asm-arm/arm32/flushtlb.h b/xen/include/asm-arm/arm32/flushtlb.h
new file mode 100644
index 0000000..3c2d5b6
--- /dev/null
+++ b/xen/include/asm-arm/arm32/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM32_FLUSHTLB_H__
+#define __ASM_ARM_ARM32_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALLIS);
+
+    dsb();
+    isb();
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
+
+    dsb();
+    isb();
+}
+
+#endif /* __ASM_ARM_ARM32_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
new file mode 100644
index 0000000..073b8d1
--- /dev/null
+++ b/xen/include/asm-arm/arm32/page.h
@@ -0,0 +1,69 @@
+#ifndef __ARM_ARM32_PAGE_H__
+#define __ARM_ARM32_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB and branch predictor.
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile (
+        "isb;"                        /* Ensure synchronization with previous changes to text */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (r0) /*dummy*/ : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile(STORE_CP32(0, TLBIMVAH)
+                     : : "r" (va) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM32_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/flushtlb.h b/xen/include/asm-arm/arm64/flushtlb.h
new file mode 100644
index 0000000..ca74fe3
--- /dev/null
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
+#define __ASM_ARM_ARM64_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi vmalle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi alle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+#endif /* __ASM_ARM_ARM64_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
new file mode 100644
index 0000000..636fb63
--- /dev/null
+++ b/xen/include/asm-arm/arm64/page.h
@@ -0,0 +1,67 @@
+#ifndef __ARM_ARM64_PAGE_H__
+#define __ARM_ARM64_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    asm volatile (
+        "isb;"       /* Ensure synchronization with previous changes to text */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "ic     iallu;"                 /* Flush I-cache */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    asm volatile (
+        "dsb    sy;"                    /* Ensure visibility of PTE writes */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile("tlbi vae2, %0;"
+                     : : "r" (va>>PAGE_SHIFT) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM64_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
index 210abfa..e7ce27b 100644
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -1,5 +1,5 @@
-#ifndef __FLUSHTLB_H__
-#define __FLUSHTLB_H__
+#ifndef __ASM_ARM_FLUSHTLB_H__
+#define __ASM_ARM_FLUSHTLB_H__
 
 #include <xen/cpumask.h>
 
@@ -14,32 +14,18 @@ do {                                                                    \
 
 #define tlbflush_current_time()                 (0)
 
-/* Flush local TLBs, current VMID only */
-static inline void flush_tlb_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALLIS);
-
-    dsb();
-    isb();
-}
-
-/* Flush local TLBs, all VMIDs, non-hypervisor mode */
-static inline void flush_tlb_all_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
-
-    dsb();
-    isb();
-}
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/flushtlb.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/flushtlb.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 /* Flush specified CPUs' TLBs */
 void flush_tlb_mask(const cpumask_t *mask);
 
-#endif /* __FLUSHTLB_H__ */
+#endif /* __ASM_ARM_FLUSHTLB_H__ */
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index e0a636f..709a508 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -250,6 +250,14 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/page.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/page.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /* Architectural minimum cacheline size is 4 32-bit words. */
 #define MIN_CACHELINE_BYTES 16
 /* Actual cacheline size on the boot CPU. */
@@ -282,65 +290,6 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
             : : "r" (_p), "m" (*_p));                                   \
 } while (0)
 
-
-/*
- * Flush all hypervisor mappings from the TLB and branch predictor.
- * This is needed after changing Xen code mappings.
- *
- * The caller needs to issue the necessary DSB and D-cache flushes
- * before calling flush_xen_text_tlb.
- */
-static inline void flush_xen_text_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile (
-        "isb;"                        /* Ensure synchronization with previous changes to text */
-        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
-        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
-        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
-        "dsb;"                        /* Ensure completion of TLB+BP flush */
-        "isb;"
-        : : "r" (r0) /*dummy*/ : "memory");
-}
-
-/*
- * Flush all hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile("dsb;" /* Ensure preceding are visible */
-                 STORE_CP32(0, TLBIALLH)
-                 "dsb;" /* Ensure completion of the TLB flush */
-                 "isb;"
-                 : : "r" (r0) /* dummy */: "memory");
-}
-
-/*
- * Flush a range of VA's hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
-{
-    unsigned long end = va + size;
-    dsb(); /* Ensure preceding are visible */
-    while ( va < end ) {
-        asm volatile(STORE_CP32(0, TLBIMVAH)
-                     : : "r" (va) : "memory");
-        va += PAGE_SIZE;
-    }
-    dsb(); /* Ensure completion of the TLB flush */
-    isb();
-}
-
-/* Flush all non-hypervisor mappings from the TLB */
-static inline void flush_guest_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
-}
-
 /* Print a walk of an arbitrary page table */
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
-- 
1.7.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 Feb 14 16:48:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yl-00081H-TU; Thu, 14 Feb 2013 16:48: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 1U61yj-0007xw-Nr
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:10 +0000
Received: from [85.158.139.211:49234] by server-13.bemta-5.messagelabs.com id
	5B/96-06769-9451D115; Thu, 14 Feb 2013 16:48:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360860485!22524107!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10504 invoked from network); 14 Feb 2013 16:48:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529948"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-6v;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:24 +0000
Message-ID: <1360860480-9245-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 10/46] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
v2: remove comment wondering if they should be inner-shareable flushes, they
    shouldn't for now.

    combine with other patch titled "TLB flushes." which followed in a couple
    of patches time.

    remove flush_guest_tlb(), nothing was calling it

    remove stray reference to flush branch predictor, which isn't necessary on
    64-bit.
---
 xen/include/asm-arm/arm32/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm32/page.h     |   69 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm64/page.h     |   67 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/flushtlb.h       |   34 +++++------------
 xen/include/asm-arm/page.h           |   67 ++++-----------------------------
 6 files changed, 222 insertions(+), 83 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm32/page.h
 create mode 100644 xen/include/asm-arm/arm64/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm64/page.h

diff --git a/xen/include/asm-arm/arm32/flushtlb.h b/xen/include/asm-arm/arm32/flushtlb.h
new file mode 100644
index 0000000..3c2d5b6
--- /dev/null
+++ b/xen/include/asm-arm/arm32/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM32_FLUSHTLB_H__
+#define __ASM_ARM_ARM32_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALLIS);
+
+    dsb();
+    isb();
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
+
+    dsb();
+    isb();
+}
+
+#endif /* __ASM_ARM_ARM32_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
new file mode 100644
index 0000000..073b8d1
--- /dev/null
+++ b/xen/include/asm-arm/arm32/page.h
@@ -0,0 +1,69 @@
+#ifndef __ARM_ARM32_PAGE_H__
+#define __ARM_ARM32_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB and branch predictor.
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile (
+        "isb;"                        /* Ensure synchronization with previous changes to text */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (r0) /*dummy*/ : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile(STORE_CP32(0, TLBIMVAH)
+                     : : "r" (va) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM32_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/flushtlb.h b/xen/include/asm-arm/arm64/flushtlb.h
new file mode 100644
index 0000000..ca74fe3
--- /dev/null
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
+#define __ASM_ARM_ARM64_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi vmalle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi alle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+#endif /* __ASM_ARM_ARM64_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
new file mode 100644
index 0000000..636fb63
--- /dev/null
+++ b/xen/include/asm-arm/arm64/page.h
@@ -0,0 +1,67 @@
+#ifndef __ARM_ARM64_PAGE_H__
+#define __ARM_ARM64_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    asm volatile (
+        "isb;"       /* Ensure synchronization with previous changes to text */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "ic     iallu;"                 /* Flush I-cache */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    asm volatile (
+        "dsb    sy;"                    /* Ensure visibility of PTE writes */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile("tlbi vae2, %0;"
+                     : : "r" (va>>PAGE_SHIFT) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM64_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
index 210abfa..e7ce27b 100644
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -1,5 +1,5 @@
-#ifndef __FLUSHTLB_H__
-#define __FLUSHTLB_H__
+#ifndef __ASM_ARM_FLUSHTLB_H__
+#define __ASM_ARM_FLUSHTLB_H__
 
 #include <xen/cpumask.h>
 
@@ -14,32 +14,18 @@ do {                                                                    \
 
 #define tlbflush_current_time()                 (0)
 
-/* Flush local TLBs, current VMID only */
-static inline void flush_tlb_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALLIS);
-
-    dsb();
-    isb();
-}
-
-/* Flush local TLBs, all VMIDs, non-hypervisor mode */
-static inline void flush_tlb_all_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
-
-    dsb();
-    isb();
-}
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/flushtlb.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/flushtlb.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 /* Flush specified CPUs' TLBs */
 void flush_tlb_mask(const cpumask_t *mask);
 
-#endif /* __FLUSHTLB_H__ */
+#endif /* __ASM_ARM_FLUSHTLB_H__ */
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index e0a636f..709a508 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -250,6 +250,14 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/page.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/page.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /* Architectural minimum cacheline size is 4 32-bit words. */
 #define MIN_CACHELINE_BYTES 16
 /* Actual cacheline size on the boot CPU. */
@@ -282,65 +290,6 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
             : : "r" (_p), "m" (*_p));                                   \
 } while (0)
 
-
-/*
- * Flush all hypervisor mappings from the TLB and branch predictor.
- * This is needed after changing Xen code mappings.
- *
- * The caller needs to issue the necessary DSB and D-cache flushes
- * before calling flush_xen_text_tlb.
- */
-static inline void flush_xen_text_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile (
-        "isb;"                        /* Ensure synchronization with previous changes to text */
-        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
-        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
-        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
-        "dsb;"                        /* Ensure completion of TLB+BP flush */
-        "isb;"
-        : : "r" (r0) /*dummy*/ : "memory");
-}
-
-/*
- * Flush all hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile("dsb;" /* Ensure preceding are visible */
-                 STORE_CP32(0, TLBIALLH)
-                 "dsb;" /* Ensure completion of the TLB flush */
-                 "isb;"
-                 : : "r" (r0) /* dummy */: "memory");
-}
-
-/*
- * Flush a range of VA's hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
-{
-    unsigned long end = va + size;
-    dsb(); /* Ensure preceding are visible */
-    while ( va < end ) {
-        asm volatile(STORE_CP32(0, TLBIMVAH)
-                     : : "r" (va) : "memory");
-        va += PAGE_SIZE;
-    }
-    dsb(); /* Ensure completion of the TLB flush */
-    isb();
-}
-
-/* Flush all non-hypervisor mappings from the TLB */
-static inline void flush_guest_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
-}
-
 /* Print a walk of an arbitrary page table */
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
-- 
1.7.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 Feb 14 16:48:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yl-00080q-Ek; Thu, 14 Feb 2013 16:48: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 1U61yj-0007z7-DD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:09 +0000
Received: from [85.158.139.211:22088] by server-7.bemta-5.messagelabs.com id
	53/B4-11121-8451D115; Thu, 14 Feb 2013 16:48:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360860485!22524107!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10422 invoked from network); 14 Feb 2013 16:48:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529949"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-4n;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:22 +0000
Message-ID: <1360860480-9245-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 08/46] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
v2: Remove unused, #if-0'd, 64-bit atomics.
---
 xen/include/asm-arm/arm32/atomic.h |  151 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/atomic.h |  163 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/atomic.h       |  186 +++++++-----------------------------
 3 files changed, 347 insertions(+), 153 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/atomic.h
 create mode 100644 xen/include/asm-arm/arm64/atomic.h

diff --git a/xen/include/asm-arm/arm32/atomic.h b/xen/include/asm-arm/arm32/atomic.h
new file mode 100644
index 0000000..4ee6626
--- /dev/null
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -0,0 +1,151 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * 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.
+ */
+#ifndef __ARCH_ARM_ARM32_ATOMIC__
+#define __ARCH_ARM_ARM32_ATOMIC__
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#endif /* __ARCH_ARM_ARM32_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/atomic.h b/xen/include/asm-arm/arm64/atomic.h
new file mode 100644
index 0000000..972d50c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -0,0 +1,163 @@
+/*
+ * Based on arch/arm64/include/asm/atomic.h
+ * which in turn is
+ * Based on arch/arm/include/asm/atomic.h
+ *
+ * Copyright (C) 1996 Russell King.
+ * Copyright (C) 2002 Deep Blue Solutions Ltd.
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ARCH_ARM_ARM64_ATOMIC
+#define __ARCH_ARM_ARM64_ATOMIC
+
+/*
+ * AArch64 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add\n"
+"1:	ldxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub\n"
+"1:	ldxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+	unsigned long tmp;
+	int oldval;
+
+	asm volatile("// atomic_cmpxchg\n"
+"1:	ldaxr	%w1, [%3]\n"
+"	cmp	%w1, %w4\n"
+"	b.ne	2f\n"
+"	stlxr	%w0, %w5, [%3]\n"
+"	cbnz	%w0, 1b\n"
+"2:"
+	: "=&r" (tmp), "=&r" (oldval), "+o" (ptr->counter)
+	: "r" (&ptr->counter), "Ir" (old), "r" (new)
+	: "cc");
+
+	return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+	unsigned long tmp, tmp2;
+
+	asm volatile("// atomic_clear_mask\n"
+"1:	ldxr	%0, [%3]\n"
+"	bic	%0, %0, %4\n"
+"	stxr	%w1, %0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (tmp), "=&r" (tmp2), "+o" (*addr)
+	: "r" (addr), "Ir" (mask)
+	: "cc");
+}
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+{
+	int c, old;
+
+	c = atomic_read(v);
+	while (c != u && (old = atomic_cmpxchg((v), c, c + a)) != c)
+		c = old;
+	return c;
+}
+
+#define atomic_inc(v)		atomic_add(1, v)
+#define atomic_dec(v)		atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)	(atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)	(atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#define smp_mb__before_atomic_dec()	smp_mb()
+#define smp_mb__after_atomic_dec()	smp_mb()
+#define smp_mb__before_atomic_inc()	smp_mb()
+#define smp_mb__after_atomic_inc()	smp_mb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index c7eadd6..b37b2d0 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -1,48 +1,49 @@
-/*
- *  arch/arm/include/asm/atomic.h
- *
- *  Copyright (C) 1996 Russell King.
- *  Copyright (C) 2002 Deep Blue Solutions Ltd.
- *
- * 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.
- */
 #ifndef __ARCH_ARM_ATOMIC__
 #define __ARCH_ARM_ATOMIC__
 
 #include <xen/config.h>
 #include <asm/system.h>
 
-#define build_atomic_read(name, size, type, reg)   \
+#define build_atomic_read(name, size, width, type, reg)\
 static inline type name(const volatile type *addr) \
 {                                                  \
     type ret;                                      \
-    asm volatile("ldr" size " %0,%1"               \
+    asm volatile("ldr" size " %" width "0,%1"      \
                  : reg (ret)                       \
                  : "m" (*(volatile type *)addr));  \
     return ret;                                    \
 }
 
-#define build_atomic_write(name, size, type, reg)      \
+#define build_atomic_write(name, size, width, type, reg) \
 static inline void name(volatile type *addr, type val) \
 {                                                      \
-    asm volatile("str" size " %1,%0"                   \
+    asm volatile("str" size " %"width"1,%0"            \
                  : "=m" (*(volatile type *)addr)       \
                  : reg (val));                         \
 }
 
-build_atomic_read(read_u8_atomic, "b", uint8_t, "=q")
-build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
-build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
-//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
-build_atomic_read(read_int_atomic, "", int, "=r")
-
-build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
-build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
-build_atomic_write(write_u32_atomic, "", uint32_t, "r")
-//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
-build_atomic_write(write_int_atomic, "", int, "r")
+#if defined (CONFIG_ARM_32)
+#define BYTE ""
+#define WORD ""
+#elif defined (CONFIG_ARM_64)
+#define BYTE "w"
+#define WORD "w"
+#endif
+
+build_atomic_read(read_u8_atomic,  "b", BYTE, uint8_t, "=r")
+build_atomic_read(read_u16_atomic, "h", WORD, uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "",  WORD, uint32_t, "=r")
+build_atomic_read(read_int_atomic, "",  WORD, int, "=r")
+
+build_atomic_write(write_u8_atomic,  "b", BYTE, uint8_t, "r")
+build_atomic_write(write_u16_atomic, "h", WORD, uint16_t, "r")
+build_atomic_write(write_u32_atomic, "",  WORD, uint32_t, "r")
+build_atomic_write(write_int_atomic, "",  WORD, int, "r")
+
+#if 0 /* defined (CONFIG_ARM_64) */
+build_atomic_read(read_u64_atomic, "x", uint64_t, "=r")
+build_atomic_write(write_u64_atomic, "x", uint64_t, "r")
+#endif
 
 void __bad_atomic_size(void);
 
@@ -88,134 +89,13 @@ typedef struct { int counter; } atomic_t;
 #define _atomic_set(v,i) (((v).counter) = (i))
 #define atomic_set(v,i) (((v)->counter) = (i))
 
-/*
- * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
- * store exclusive to ensure that these are atomic.  We may loop
- * to ensure that the update happens.
- */
-static inline void atomic_add(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_add\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_add_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_add_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline void atomic_sub(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_sub\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_sub_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_sub_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
-{
-        unsigned long oldval, res;
-
-        smp_mb();
-
-        do {
-                __asm__ __volatile__("@ atomic_cmpxchg\n"
-                "ldrex  %1, [%3]\n"
-                "mov    %0, #0\n"
-                "teq    %1, %4\n"
-                "strexeq %0, %5, [%3]\n"
-                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
-                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
-                    : "cc");
-        } while (res);
-
-        smp_mb();
-
-        return oldval;
-}
-
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
-{
-        unsigned long tmp, tmp2;
-
-        __asm__ __volatile__("@ atomic_clear_mask\n"
-"1:     ldrex   %0, [%3]\n"
-"       bic     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
-        : "r" (addr), "Ir" (mask)
-        : "cc");
-}
-
-#define atomic_inc(v)           atomic_add(1, v)
-#define atomic_dec(v)           atomic_sub(1, v)
-
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)    (atomic_add_return(1, v))
-#define atomic_dec_return(v)    (atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/atomic.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/atomic.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 static inline atomic_t atomic_compareandswap(
     atomic_t old, atomic_t new, atomic_t *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 Thu Feb 14 16:48:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61yl-00080q-Ek; Thu, 14 Feb 2013 16:48: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 1U61yj-0007z7-DD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:09 +0000
Received: from [85.158.139.211:22088] by server-7.bemta-5.messagelabs.com id
	53/B4-11121-8451D115; Thu, 14 Feb 2013 16:48:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360860485!22524107!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10422 invoked from network); 14 Feb 2013 16:48:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529949"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-4n;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:22 +0000
Message-ID: <1360860480-9245-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 08/46] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
v2: Remove unused, #if-0'd, 64-bit atomics.
---
 xen/include/asm-arm/arm32/atomic.h |  151 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/atomic.h |  163 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/atomic.h       |  186 +++++++-----------------------------
 3 files changed, 347 insertions(+), 153 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/atomic.h
 create mode 100644 xen/include/asm-arm/arm64/atomic.h

diff --git a/xen/include/asm-arm/arm32/atomic.h b/xen/include/asm-arm/arm32/atomic.h
new file mode 100644
index 0000000..4ee6626
--- /dev/null
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -0,0 +1,151 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * 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.
+ */
+#ifndef __ARCH_ARM_ARM32_ATOMIC__
+#define __ARCH_ARM_ARM32_ATOMIC__
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#endif /* __ARCH_ARM_ARM32_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/atomic.h b/xen/include/asm-arm/arm64/atomic.h
new file mode 100644
index 0000000..972d50c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -0,0 +1,163 @@
+/*
+ * Based on arch/arm64/include/asm/atomic.h
+ * which in turn is
+ * Based on arch/arm/include/asm/atomic.h
+ *
+ * Copyright (C) 1996 Russell King.
+ * Copyright (C) 2002 Deep Blue Solutions Ltd.
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ARCH_ARM_ARM64_ATOMIC
+#define __ARCH_ARM_ARM64_ATOMIC
+
+/*
+ * AArch64 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add\n"
+"1:	ldxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub\n"
+"1:	ldxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+	unsigned long tmp;
+	int oldval;
+
+	asm volatile("// atomic_cmpxchg\n"
+"1:	ldaxr	%w1, [%3]\n"
+"	cmp	%w1, %w4\n"
+"	b.ne	2f\n"
+"	stlxr	%w0, %w5, [%3]\n"
+"	cbnz	%w0, 1b\n"
+"2:"
+	: "=&r" (tmp), "=&r" (oldval), "+o" (ptr->counter)
+	: "r" (&ptr->counter), "Ir" (old), "r" (new)
+	: "cc");
+
+	return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+	unsigned long tmp, tmp2;
+
+	asm volatile("// atomic_clear_mask\n"
+"1:	ldxr	%0, [%3]\n"
+"	bic	%0, %0, %4\n"
+"	stxr	%w1, %0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (tmp), "=&r" (tmp2), "+o" (*addr)
+	: "r" (addr), "Ir" (mask)
+	: "cc");
+}
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+{
+	int c, old;
+
+	c = atomic_read(v);
+	while (c != u && (old = atomic_cmpxchg((v), c, c + a)) != c)
+		c = old;
+	return c;
+}
+
+#define atomic_inc(v)		atomic_add(1, v)
+#define atomic_dec(v)		atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)	(atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)	(atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#define smp_mb__before_atomic_dec()	smp_mb()
+#define smp_mb__after_atomic_dec()	smp_mb()
+#define smp_mb__before_atomic_inc()	smp_mb()
+#define smp_mb__after_atomic_inc()	smp_mb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index c7eadd6..b37b2d0 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -1,48 +1,49 @@
-/*
- *  arch/arm/include/asm/atomic.h
- *
- *  Copyright (C) 1996 Russell King.
- *  Copyright (C) 2002 Deep Blue Solutions Ltd.
- *
- * 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.
- */
 #ifndef __ARCH_ARM_ATOMIC__
 #define __ARCH_ARM_ATOMIC__
 
 #include <xen/config.h>
 #include <asm/system.h>
 
-#define build_atomic_read(name, size, type, reg)   \
+#define build_atomic_read(name, size, width, type, reg)\
 static inline type name(const volatile type *addr) \
 {                                                  \
     type ret;                                      \
-    asm volatile("ldr" size " %0,%1"               \
+    asm volatile("ldr" size " %" width "0,%1"      \
                  : reg (ret)                       \
                  : "m" (*(volatile type *)addr));  \
     return ret;                                    \
 }
 
-#define build_atomic_write(name, size, type, reg)      \
+#define build_atomic_write(name, size, width, type, reg) \
 static inline void name(volatile type *addr, type val) \
 {                                                      \
-    asm volatile("str" size " %1,%0"                   \
+    asm volatile("str" size " %"width"1,%0"            \
                  : "=m" (*(volatile type *)addr)       \
                  : reg (val));                         \
 }
 
-build_atomic_read(read_u8_atomic, "b", uint8_t, "=q")
-build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
-build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
-//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
-build_atomic_read(read_int_atomic, "", int, "=r")
-
-build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
-build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
-build_atomic_write(write_u32_atomic, "", uint32_t, "r")
-//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
-build_atomic_write(write_int_atomic, "", int, "r")
+#if defined (CONFIG_ARM_32)
+#define BYTE ""
+#define WORD ""
+#elif defined (CONFIG_ARM_64)
+#define BYTE "w"
+#define WORD "w"
+#endif
+
+build_atomic_read(read_u8_atomic,  "b", BYTE, uint8_t, "=r")
+build_atomic_read(read_u16_atomic, "h", WORD, uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "",  WORD, uint32_t, "=r")
+build_atomic_read(read_int_atomic, "",  WORD, int, "=r")
+
+build_atomic_write(write_u8_atomic,  "b", BYTE, uint8_t, "r")
+build_atomic_write(write_u16_atomic, "h", WORD, uint16_t, "r")
+build_atomic_write(write_u32_atomic, "",  WORD, uint32_t, "r")
+build_atomic_write(write_int_atomic, "",  WORD, int, "r")
+
+#if 0 /* defined (CONFIG_ARM_64) */
+build_atomic_read(read_u64_atomic, "x", uint64_t, "=r")
+build_atomic_write(write_u64_atomic, "x", uint64_t, "r")
+#endif
 
 void __bad_atomic_size(void);
 
@@ -88,134 +89,13 @@ typedef struct { int counter; } atomic_t;
 #define _atomic_set(v,i) (((v).counter) = (i))
 #define atomic_set(v,i) (((v)->counter) = (i))
 
-/*
- * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
- * store exclusive to ensure that these are atomic.  We may loop
- * to ensure that the update happens.
- */
-static inline void atomic_add(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_add\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_add_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_add_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline void atomic_sub(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_sub\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_sub_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_sub_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
-{
-        unsigned long oldval, res;
-
-        smp_mb();
-
-        do {
-                __asm__ __volatile__("@ atomic_cmpxchg\n"
-                "ldrex  %1, [%3]\n"
-                "mov    %0, #0\n"
-                "teq    %1, %4\n"
-                "strexeq %0, %5, [%3]\n"
-                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
-                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
-                    : "cc");
-        } while (res);
-
-        smp_mb();
-
-        return oldval;
-}
-
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
-{
-        unsigned long tmp, tmp2;
-
-        __asm__ __volatile__("@ atomic_clear_mask\n"
-"1:     ldrex   %0, [%3]\n"
-"       bic     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
-        : "r" (addr), "Ir" (mask)
-        : "cc");
-}
-
-#define atomic_inc(v)           atomic_add(1, v)
-#define atomic_dec(v)           atomic_sub(1, v)
-
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)    (atomic_add_return(1, v))
-#define atomic_dec_return(v)    (atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/atomic.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/atomic.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 static inline atomic_t atomic_compareandswap(
     atomic_t old, atomic_t new, atomic_t *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 Thu Feb 14 16:48:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61zQ-0008Rk-IB; Thu, 14 Feb 2013 16:48: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 1U61zP-0008Ql-GK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:51 +0000
Received: from [85.158.143.35:19072] by server-1.bemta-4.messagelabs.com id
	A2/96-08839-2751D115; Thu, 14 Feb 2013 16:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360860482!15626264!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27432 invoked from network); 14 Feb 2013 16:48:05 -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;
	14 Feb 2013 16:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529946"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-4J;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:21 +0000
Message-ID: <1360860480-9245-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 07/46] xen: arm64: 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>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: no change, but these need to be revisited considering the interaction of
sev/wfe etc. May need to rework the generic code in order to make best use of
wfe (on 32-bit ARM too)
---
 xen/include/asm-arm/arm32/spinlock.h |  141 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/spinlock.h |  125 ++++++++++++++++++++++++++++++
 xen/include/asm-arm/spinlock.h       |  135 ++------------------------------
 3 files changed, 273 insertions(+), 128 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/spinlock.h
 create mode 100644 xen/include/asm-arm/arm64/spinlock.h

diff --git a/xen/include/asm-arm/arm32/spinlock.h b/xen/include/asm-arm/arm32/spinlock.h
new file mode 100644
index 0000000..a7bcdbf
--- /dev/null
+++ b/xen/include/asm-arm/arm32/spinlock.h
@@ -0,0 +1,141 @@
+#ifndef __ASM_ARM32_SPINLOCK_H
+#define __ASM_ARM32_SPINLOCK_H
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/spinlock.h b/xen/include/asm-arm/arm64/spinlock.h
new file mode 100644
index 0000000..52ad688
--- /dev/null
+++ b/xen/include/asm-arm/arm64/spinlock.h
@@ -0,0 +1,125 @@
+/*
+ * Derived from Linux arch64 spinlock.h which is:
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM64_SPINLOCK_H
+#define __ASM_ARM64_SPINLOCK_H
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&lock->lock), "r" (0) : "memory");
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&lock->lock), "r" (1)
+        : "memory");
+
+    return !tmp;
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2 = 1;
+
+    asm volatile(
+        "       ldaxr   %w0, [%2]\n"
+        "       add     %w0, %w0, #1\n"
+        "       tbnz    %w0, #31, 1f\n"
+        "       stxr    %w1, %w0, [%2]\n"
+        "1:\n"
+        : "=&r" (tmp), "+r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+
+    return !tmp2;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&rw->lock), "r" (0x80000000)
+        : "memory");
+
+    return !tmp;
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2;
+
+    asm volatile(
+        "1:     ldxr    %w0, [%2]\n"
+        "       sub     %w0, %w0, #1\n"
+        "       stlxr   %w1, %w0, [%2]\n"
+        "       cbnz    %w1, 1b\n"
+        : "=&r" (tmp), "=&r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&rw->lock), "r" (0) : "memory");
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
index b1825c9..d753210 100644
--- a/xen/include/asm-arm/spinlock.h
+++ b/xen/include/asm-arm/spinlock.h
@@ -4,134 +4,13 @@
 #include <xen/config.h>
 #include <xen/lib.h>
 
-static inline void dsb_sev(void)
-{
-    __asm__ __volatile__ (
-        "dsb\n"
-        "sev\n"
-        );
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_spinlock_t;
-
-#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
-
-#define _raw_spin_is_locked(x)          ((x)->lock != 0)
-
-static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
-{
-    ASSERT(_raw_spin_is_locked(lock));
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"   str     %1, [%0]\n"
-    :
-    : "r" (&lock->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"   ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&lock->lock), "r" (1)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_rwlock_t;
-
-#define _RAW_RW_LOCK_UNLOCKED { 0 }
-
-static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2 = 1;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   adds    %0, %0, #1\n"
-"   strexpl %1, %0, [%2]\n"
-    : "=&r" (tmp), "+r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    smp_mb();
-    return tmp2 == 0;
-}
-
-static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&rw->lock), "r" (0x80000000)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-static inline void _raw_read_unlock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2;
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   sub     %0, %0, #1\n"
-"   strex   %1, %0, [%2]\n"
-"   teq     %1, #0\n"
-"   bne     1b"
-    : "=&r" (tmp), "=&r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    if (tmp == 0)
-        dsb_sev();
-}
-
-static inline void _raw_write_unlock(raw_rwlock_t *rw)
-{
-    smp_mb();
-
-    __asm__ __volatile__(
-    "str    %1, [%0]\n"
-    :
-    : "r" (&rw->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-#define _raw_rw_is_locked(x) ((x)->lock != 0)
-#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/spinlock.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/spinlock.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #endif /* __ASM_SPINLOCK_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 Thu Feb 14 16:48:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:48: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 1U61zQ-0008Rk-IB; Thu, 14 Feb 2013 16:48: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 1U61zP-0008Ql-GK
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:51 +0000
Received: from [85.158.143.35:19072] by server-1.bemta-4.messagelabs.com id
	A2/96-08839-2751D115; Thu, 14 Feb 2013 16:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360860482!15626264!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27432 invoked from network); 14 Feb 2013 16:48:05 -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;
	14 Feb 2013 16:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529946"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-4J;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:21 +0000
Message-ID: <1360860480-9245-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 07/46] xen: arm64: 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>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: no change, but these need to be revisited considering the interaction of
sev/wfe etc. May need to rework the generic code in order to make best use of
wfe (on 32-bit ARM too)
---
 xen/include/asm-arm/arm32/spinlock.h |  141 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/spinlock.h |  125 ++++++++++++++++++++++++++++++
 xen/include/asm-arm/spinlock.h       |  135 ++------------------------------
 3 files changed, 273 insertions(+), 128 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/spinlock.h
 create mode 100644 xen/include/asm-arm/arm64/spinlock.h

diff --git a/xen/include/asm-arm/arm32/spinlock.h b/xen/include/asm-arm/arm32/spinlock.h
new file mode 100644
index 0000000..a7bcdbf
--- /dev/null
+++ b/xen/include/asm-arm/arm32/spinlock.h
@@ -0,0 +1,141 @@
+#ifndef __ASM_ARM32_SPINLOCK_H
+#define __ASM_ARM32_SPINLOCK_H
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/spinlock.h b/xen/include/asm-arm/arm64/spinlock.h
new file mode 100644
index 0000000..52ad688
--- /dev/null
+++ b/xen/include/asm-arm/arm64/spinlock.h
@@ -0,0 +1,125 @@
+/*
+ * Derived from Linux arch64 spinlock.h which is:
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM64_SPINLOCK_H
+#define __ASM_ARM64_SPINLOCK_H
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&lock->lock), "r" (0) : "memory");
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&lock->lock), "r" (1)
+        : "memory");
+
+    return !tmp;
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2 = 1;
+
+    asm volatile(
+        "       ldaxr   %w0, [%2]\n"
+        "       add     %w0, %w0, #1\n"
+        "       tbnz    %w0, #31, 1f\n"
+        "       stxr    %w1, %w0, [%2]\n"
+        "1:\n"
+        : "=&r" (tmp), "+r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+
+    return !tmp2;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&rw->lock), "r" (0x80000000)
+        : "memory");
+
+    return !tmp;
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2;
+
+    asm volatile(
+        "1:     ldxr    %w0, [%2]\n"
+        "       sub     %w0, %w0, #1\n"
+        "       stlxr   %w1, %w0, [%2]\n"
+        "       cbnz    %w1, 1b\n"
+        : "=&r" (tmp), "=&r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&rw->lock), "r" (0) : "memory");
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
index b1825c9..d753210 100644
--- a/xen/include/asm-arm/spinlock.h
+++ b/xen/include/asm-arm/spinlock.h
@@ -4,134 +4,13 @@
 #include <xen/config.h>
 #include <xen/lib.h>
 
-static inline void dsb_sev(void)
-{
-    __asm__ __volatile__ (
-        "dsb\n"
-        "sev\n"
-        );
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_spinlock_t;
-
-#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
-
-#define _raw_spin_is_locked(x)          ((x)->lock != 0)
-
-static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
-{
-    ASSERT(_raw_spin_is_locked(lock));
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"   str     %1, [%0]\n"
-    :
-    : "r" (&lock->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"   ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&lock->lock), "r" (1)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_rwlock_t;
-
-#define _RAW_RW_LOCK_UNLOCKED { 0 }
-
-static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2 = 1;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   adds    %0, %0, #1\n"
-"   strexpl %1, %0, [%2]\n"
-    : "=&r" (tmp), "+r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    smp_mb();
-    return tmp2 == 0;
-}
-
-static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&rw->lock), "r" (0x80000000)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-static inline void _raw_read_unlock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2;
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   sub     %0, %0, #1\n"
-"   strex   %1, %0, [%2]\n"
-"   teq     %1, #0\n"
-"   bne     1b"
-    : "=&r" (tmp), "=&r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    if (tmp == 0)
-        dsb_sev();
-}
-
-static inline void _raw_write_unlock(raw_rwlock_t *rw)
-{
-    smp_mb();
-
-    __asm__ __volatile__(
-    "str    %1, [%0]\n"
-    :
-    : "r" (&rw->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-#define _raw_rw_is_locked(x) ((x)->lock != 0)
-#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/spinlock.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/spinlock.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #endif /* __ASM_SPINLOCK_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 Thu Feb 14 16:49:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:49: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 1U61zR-0008Sl-VA; Thu, 14 Feb 2013 16:48: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 1U61zP-0008R7-VO
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:52 +0000
Received: from [85.158.143.35:19102] by server-2.bemta-4.messagelabs.com id
	0A/FE-01597-3751D115; Thu, 14 Feb 2013 16:48:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360860482!15626264!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27298 invoked from network); 14 Feb 2013 16:48:04 -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;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529944"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-2Q;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:18 +0000
Message-ID: <1360860480-9245-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 04/46] arm: avoid inline asm for dsb, isb,
	wfi and sev.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
synonymous) on arm32 but we have a macro so lets use it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c  |    5 ++++-
 xen/arch/arm/smpboot.c |   10 ++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..e7d3ec6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -29,7 +29,10 @@ void idle_loop(void)
 
         local_irq_disable();
         if ( cpu_is_haltable(smp_processor_id()) )
-            asm volatile ("dsb; wfi");
+        {
+            dsb();
+            wfi();
+        }
         local_irq_enable();
 
         do_tasklet();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 60be1a4..86379b7 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -122,7 +122,8 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
         /* TODO: handle boards where CPUIDs are not contiguous */
         *gate = i;
         flush_xen_dcache(*gate);
-        asm volatile("isb; sev");
+        isb();
+        sev();
         /* And wait for it to respond */
         while ( ready_cpus < i )
             smp_rmb();
@@ -204,8 +205,8 @@ void stop_cpu(void)
     /* Make sure the write happens before we sleep forever */
     dsb();
     isb();
-    while ( 1 ) 
-        asm volatile("wfi");
+    while ( 1 )
+        wfi();
 }
 
 /* Bring up a remote CPU */
@@ -220,7 +221,8 @@ int __cpu_up(unsigned int cpu)
     /* we need to make sure that the change to smp_up_cpu is visible to
      * secondary cpus with D-cache off */
     flush_xen_dcache(smp_up_cpu);
-    asm volatile("isb; sev");
+    isb();
+    sev();
 
     while ( !cpu_online(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 Thu Feb 14 16:49:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:49: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 1U61zR-0008Sl-VA; Thu, 14 Feb 2013 16:48: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 1U61zP-0008R7-VO
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:48:52 +0000
Received: from [85.158.143.35:19102] by server-2.bemta-4.messagelabs.com id
	0A/FE-01597-3751D115; Thu, 14 Feb 2013 16:48:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360860482!15626264!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27298 invoked from network); 14 Feb 2013 16:48:04 -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;
	14 Feb 2013 16:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7529944"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:48:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:01 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-2Q;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:18 +0000
Message-ID: <1360860480-9245-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 04/46] arm: avoid inline asm for dsb, isb,
	wfi and sev.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
synonymous) on arm32 but we have a macro so lets use it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c  |    5 ++++-
 xen/arch/arm/smpboot.c |   10 ++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..e7d3ec6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -29,7 +29,10 @@ void idle_loop(void)
 
         local_irq_disable();
         if ( cpu_is_haltable(smp_processor_id()) )
-            asm volatile ("dsb; wfi");
+        {
+            dsb();
+            wfi();
+        }
         local_irq_enable();
 
         do_tasklet();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 60be1a4..86379b7 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -122,7 +122,8 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
         /* TODO: handle boards where CPUIDs are not contiguous */
         *gate = i;
         flush_xen_dcache(*gate);
-        asm volatile("isb; sev");
+        isb();
+        sev();
         /* And wait for it to respond */
         while ( ready_cpus < i )
             smp_rmb();
@@ -204,8 +205,8 @@ void stop_cpu(void)
     /* Make sure the write happens before we sleep forever */
     dsb();
     isb();
-    while ( 1 ) 
-        asm volatile("wfi");
+    while ( 1 )
+        wfi();
 }
 
 /* Bring up a remote CPU */
@@ -220,7 +221,8 @@ int __cpu_up(unsigned int cpu)
     /* we need to make sure that the change to smp_up_cpu is visible to
      * secondary cpus with D-cache off */
     flush_xen_dcache(smp_up_cpu);
-    asm volatile("isb; sev");
+    isb();
+    sev();
 
     while ( !cpu_online(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 Thu Feb 14 16:49:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:49: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 1U61zd-0000AL-EP; Thu, 14 Feb 2013 16:49:05 +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 1U61zc-00008W-2i
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:49:04 +0000
Received: from [85.158.139.83:55548] by server-9.bemta-5.messagelabs.com id
	F8/A4-24440-F751D115; Thu, 14 Feb 2013 16:49:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360860540!32358633!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20399 invoked from network); 14 Feb 2013 16:49:01 -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;
	14 Feb 2013 16:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159908"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:49:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:59 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U61zX-000148-HQ;
	Thu, 14 Feb 2013 16:48:59 +0000
Message-ID: <1360860539.16636.162.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 16:48:59 +0000
In-Reply-To: <1360859947.20449.465.camel@zakaz.uk.xensource.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360859947.20449.465.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 16:39 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > If the credit timer is left armed after calling
> > xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> > the vif which will then oops as vif->netbk == NULL.
> > 
> > This may happen both in the fatal error path and during normal
> > disconnection from the front end.
> > 
> > The sequencing during shutdown is critical to ensure that: a)
> > vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> > is not freed.
> > 
> > 1. Mark as unschedulable (netif_carrier_off()).
> > 2. Synchronously cancel the timer.
> > 3. Remove the vif from the schedule list.
> > 4. Remove it from it netback thread group.
> > 5. Wait for vif->refcnt to become 0.
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Was this one also Reported-by Christopher S. Aker or was it just
> discovered in the process of investigating?
> 

His bug report did prod me to look into this, so I think it is worth
adding

Reported-by: Christopher S. Aker <caker@theshore.net>


Wei.

> Another stable candidate please Dave.
> 
> > ---
> >  drivers/net/xen-netback/interface.c |    3 +--
> >  1 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index b8c5193..221f426 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
> >  static void xenvif_down(struct xenvif *vif)
> >  {
> >  	disable_irq(vif->irq);
> > +	del_timer_sync(&vif->credit_timeout);
> >  	xen_netbk_deschedule_xenvif(vif);
> >  	xen_netbk_remove_xenvif(vif);
> >  }
> > @@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
> >  	atomic_dec(&vif->refcnt);
> >  	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
> >  
> > -	del_timer_sync(&vif->credit_timeout);
> > -
> >  	if (vif->irq)
> >  		unbind_from_irqhandler(vif->irq, vif);
> >  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 16:49:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:49: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 1U61zd-0000AL-EP; Thu, 14 Feb 2013 16:49:05 +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 1U61zc-00008W-2i
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:49:04 +0000
Received: from [85.158.139.83:55548] by server-9.bemta-5.messagelabs.com id
	F8/A4-24440-F751D115; Thu, 14 Feb 2013 16:49:03 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360860540!32358633!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20399 invoked from network); 14 Feb 2013 16:49:01 -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;
	14 Feb 2013 16:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,665,1355097600"; 
   d="scan'208";a="7159908"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 16:49:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 11:48:59 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U61zX-000148-HQ;
	Thu, 14 Feb 2013 16:48:59 +0000
Message-ID: <1360860539.16636.162.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 14 Feb 2013 16:48:59 +0000
In-Reply-To: <1360859947.20449.465.camel@zakaz.uk.xensource.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<1360847938-11185-3-git-send-email-david.vrabel@citrix.com>
	<1360859947.20449.465.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen-netback: cancel the credit timer
 when taking the vif 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2013-02-14 at 16:39 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 13:18 +0000, David Vrabel wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > If the credit timer is left armed after calling
> > xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
> > the vif which will then oops as vif->netbk == NULL.
> > 
> > This may happen both in the fatal error path and during normal
> > disconnection from the front end.
> > 
> > The sequencing during shutdown is critical to ensure that: a)
> > vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
> > is not freed.
> > 
> > 1. Mark as unschedulable (netif_carrier_off()).
> > 2. Synchronously cancel the timer.
> > 3. Remove the vif from the schedule list.
> > 4. Remove it from it netback thread group.
> > 5. Wait for vif->refcnt to become 0.
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Was this one also Reported-by Christopher S. Aker or was it just
> discovered in the process of investigating?
> 

His bug report did prod me to look into this, so I think it is worth
adding

Reported-by: Christopher S. Aker <caker@theshore.net>


Wei.

> Another stable candidate please Dave.
> 
> > ---
> >  drivers/net/xen-netback/interface.c |    3 +--
> >  1 files changed, 1 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index b8c5193..221f426 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -132,6 +132,7 @@ static void xenvif_up(struct xenvif *vif)
> >  static void xenvif_down(struct xenvif *vif)
> >  {
> >  	disable_irq(vif->irq);
> > +	del_timer_sync(&vif->credit_timeout);
> >  	xen_netbk_deschedule_xenvif(vif);
> >  	xen_netbk_remove_xenvif(vif);
> >  }
> > @@ -363,8 +364,6 @@ void xenvif_disconnect(struct xenvif *vif)
> >  	atomic_dec(&vif->refcnt);
> >  	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
> >  
> > -	del_timer_sync(&vif->credit_timeout);
> > -
> >  	if (vif->irq)
> >  		unbind_from_irqhandler(vif->irq, vif);
> >  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 16:52:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:52: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 1U622a-0001Hl-33; Thu, 14 Feb 2013 16:52:08 +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 1U622Y-0001HV-K1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:52:06 +0000
Received: from [85.158.143.35:5794] by server-2.bemta-4.messagelabs.com id
	13/B2-01597-5361D115; Thu, 14 Feb 2013 16:52:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360860604!11670914!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 14 Feb 2013 16:50:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 16:50:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U620Z-000ND4-HK; Thu, 14 Feb 2013 16:50:03 +0000
Date: Thu, 14 Feb 2013 16:50:03 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130214165003.GR83752@ocelot.phlegethon.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511D202E02000078000BE68A@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 16:34 +0000 on 14 Feb (1360859678), Jan Beulich wrote:
> >>> On 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
> > @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
> >  #endif
> >  
> >      /* reduce max_samples if necessary to limit pages allocated */
> > -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
> > +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
> >      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
> >      if ( (unsigned)max_samples > max_max_samples )
> >          max_samples = max_max_samples;
> 
> I think the function would better return an error in that case. After
> all there's little point in setting up anything when we for sure don't
> know how many vCPU-s a domain is going to have.

Grand so:

# HG changeset patch
# Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
xen/xenoprof: avoid division by 0.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5a84cc531072 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
+++ b/xen/common/xenoprof.c	Thu Feb 14 16:48:49 2013 +0000
@@ -213,6 +213,9 @@ static int alloc_xenoprof_struct(
     for_each_vcpu ( d, v )
         nvcpu++;
 
+    if ( !nvcpu )
+        return -EINVAL;
+
     bufsize = sizeof(struct xenoprof_buf);
     i = sizeof(struct event_log);
 #ifdef CONFIG_COMPAT

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:52:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:52: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 1U622a-0001Hl-33; Thu, 14 Feb 2013 16:52:08 +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 1U622Y-0001HV-K1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:52:06 +0000
Received: from [85.158.143.35:5794] by server-2.bemta-4.messagelabs.com id
	13/B2-01597-5361D115; Thu, 14 Feb 2013 16:52:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360860604!11670914!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 14 Feb 2013 16:50:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 16:50:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U620Z-000ND4-HK; Thu, 14 Feb 2013 16:50:03 +0000
Date: Thu, 14 Feb 2013 16:50:03 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130214165003.GR83752@ocelot.phlegethon.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511D202E02000078000BE68A@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 16:34 +0000 on 14 Feb (1360859678), Jan Beulich wrote:
> >>> On 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
> > @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
> >  #endif
> >  
> >      /* reduce max_samples if necessary to limit pages allocated */
> > -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
> > +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
> >      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
> >      if ( (unsigned)max_samples > max_max_samples )
> >          max_samples = max_max_samples;
> 
> I think the function would better return an error in that case. After
> all there's little point in setting up anything when we for sure don't
> know how many vCPU-s a domain is going to have.

Grand so:

# HG changeset patch
# Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
xen/xenoprof: avoid division by 0.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5a84cc531072 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
+++ b/xen/common/xenoprof.c	Thu Feb 14 16:48:49 2013 +0000
@@ -213,6 +213,9 @@ static int alloc_xenoprof_struct(
     for_each_vcpu ( d, v )
         nvcpu++;
 
+    if ( !nvcpu )
+        return -EINVAL;
+
     bufsize = sizeof(struct xenoprof_buf);
     i = sizeof(struct event_log);
 #ifdef CONFIG_COMPAT

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:57:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:57: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 1U627m-0001dX-St; Thu, 14 Feb 2013 16:57:30 +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 1U627l-0001dS-Mi
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:57:29 +0000
Received: from [85.158.143.99:61954] by server-3.bemta-4.messagelabs.com id
	DA/7C-08920-8771D115; Thu, 14 Feb 2013 16:57:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360861048!27082505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24629 invoked from network); 14 Feb 2013 16:57:28 -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; 14 Feb 2013 16:57:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 16:57:27 +0000
Message-Id: <511D25C402000078000BE71E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 16:58:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part97A7D6A4.0__="
Subject: [Xen-devel] [PATCH] x86: use single definitions for a few constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part97A7D6A4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than having a C and an assembly one.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128]
=20
 #define CONFIG_COMPAT 1
=20
+#include <xen/const.h>
+
 #define PML4_ENTRY_BITS  39
-#ifndef __ASSEMBLY__
-#define PML4_ENTRY_BYTES (1UL << PML4_ENTRY_BITS)
-#define PML4_ADDR(_slot)                             \
-    ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \
-     (_slot ## UL << PML4_ENTRY_BITS))
-#define GB(_gb) (_gb ## UL << 30)
-#else
-#define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)
-#define PML4_ADDR(_slot)                             \
-    (((_slot >> 8) * 0xffff000000000000) | (_slot << PML4_ENTRY_BITS))
-#define GB(_gb) (_gb << 30)
-#endif
+#define PML4_ENTRY_BYTES (_AC(1,UL) << PML4_ENTRY_BITS)
+#define PML4_ADDR(_slot)                              \
+    (((_AC(_slot, UL) >> 8) * _AC(0xffff000000000000,UL)) | \
+     (_AC(_slot, UL) << PML4_ENTRY_BITS))
+#define GB(_gb) (_AC(_gb, UL) << 30)
=20
 /*
  * Memory layout:
@@ -242,7 +237,7 @@ extern unsigned char boot_edid_info[128]
                                                           PAGE_SHIFT)) + =
1)
 #define SPAGETABLE_SIZE         (SPAGETABLE_NR * sizeof(struct spage_info)=
)
 #define SPAGETABLE_VIRT_START   ((SPAGETABLE_VIRT_END - SPAGETABLE_SIZE) =
& \
-                                 (-1UL << SUPERPAGE_SHIFT))
+                                 (_AC(-1,UL) << SUPERPAGE_SHIFT))
 /* Slot 261: page-frame information array (128GB). */
 #define FRAMETABLE_VIRT_END     DIRECTMAP_VIRT_START
 #define FRAMETABLE_SIZE         GB(128)




--=__Part97A7D6A4.0__=
Content-Type: text/plain; name="x86-unify-constants.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-unify-constants.patch"

x86: use single definitions for a few constants=0A=0A... rather than =
having a C and an assembly one.=0A=0ASigned-off-by: Jan Beulich <jbeulich@s=
use.com>=0A=0A--- a/xen/include/asm-x86/config.h=0A+++ b/xen/include/asm-x8=
6/config.h=0A@@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128]=
=0A =0A #define CONFIG_COMPAT 1=0A =0A+#include <xen/const.h>=0A+=0A =
#define PML4_ENTRY_BITS  39=0A-#ifndef __ASSEMBLY__=0A-#define PML4_ENTRY_B=
YTES (1UL << PML4_ENTRY_BITS)=0A-#define PML4_ADDR(_slot)                  =
           \=0A-    ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \=0A- =
    (_slot ## UL << PML4_ENTRY_BITS))=0A-#define GB(_gb) (_gb ## UL << =
30)=0A-#else=0A-#define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)=0A-#define =
PML4_ADDR(_slot)                             \=0A-    (((_slot >> 8) * =
0xffff000000000000) | (_slot << PML4_ENTRY_BITS))=0A-#define GB(_gb) (_gb =
<< 30)=0A-#endif=0A+#define PML4_ENTRY_BYTES (_AC(1,UL) << PML4_ENTRY_BITS)=
=0A+#define PML4_ADDR(_slot)                              \=0A+    =
(((_AC(_slot, UL) >> 8) * _AC(0xffff000000000000,UL)) | \=0A+     =
(_AC(_slot, UL) << PML4_ENTRY_BITS))=0A+#define GB(_gb) (_AC(_gb, UL) << =
30)=0A =0A /*=0A  * Memory layout:=0A@@ -242,7 +237,7 @@ extern unsigned =
char boot_edid_info[128]=0A                                                =
           PAGE_SHIFT)) + 1)=0A #define SPAGETABLE_SIZE         (SPAGETABLE=
_NR * sizeof(struct spage_info))=0A #define SPAGETABLE_VIRT_START   =
((SPAGETABLE_VIRT_END - SPAGETABLE_SIZE) & \=0A-                           =
      (-1UL << SUPERPAGE_SHIFT))=0A+                                 =
(_AC(-1,UL) << SUPERPAGE_SHIFT))=0A /* Slot 261: page-frame information =
array (128GB). */=0A #define FRAMETABLE_VIRT_END     DIRECTMAP_VIRT_START=
=0A #define FRAMETABLE_SIZE         GB(128)=0A
--=__Part97A7D6A4.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

--=__Part97A7D6A4.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 16:57:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:57: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 1U627m-0001dX-St; Thu, 14 Feb 2013 16:57:30 +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 1U627l-0001dS-Mi
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:57:29 +0000
Received: from [85.158.143.99:61954] by server-3.bemta-4.messagelabs.com id
	DA/7C-08920-8771D115; Thu, 14 Feb 2013 16:57:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360861048!27082505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24629 invoked from network); 14 Feb 2013 16:57:28 -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; 14 Feb 2013 16:57:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 16:57:27 +0000
Message-Id: <511D25C402000078000BE71E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 16:58:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part97A7D6A4.0__="
Subject: [Xen-devel] [PATCH] x86: use single definitions for a few constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part97A7D6A4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than having a C and an assembly one.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128]
=20
 #define CONFIG_COMPAT 1
=20
+#include <xen/const.h>
+
 #define PML4_ENTRY_BITS  39
-#ifndef __ASSEMBLY__
-#define PML4_ENTRY_BYTES (1UL << PML4_ENTRY_BITS)
-#define PML4_ADDR(_slot)                             \
-    ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \
-     (_slot ## UL << PML4_ENTRY_BITS))
-#define GB(_gb) (_gb ## UL << 30)
-#else
-#define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)
-#define PML4_ADDR(_slot)                             \
-    (((_slot >> 8) * 0xffff000000000000) | (_slot << PML4_ENTRY_BITS))
-#define GB(_gb) (_gb << 30)
-#endif
+#define PML4_ENTRY_BYTES (_AC(1,UL) << PML4_ENTRY_BITS)
+#define PML4_ADDR(_slot)                              \
+    (((_AC(_slot, UL) >> 8) * _AC(0xffff000000000000,UL)) | \
+     (_AC(_slot, UL) << PML4_ENTRY_BITS))
+#define GB(_gb) (_AC(_gb, UL) << 30)
=20
 /*
  * Memory layout:
@@ -242,7 +237,7 @@ extern unsigned char boot_edid_info[128]
                                                           PAGE_SHIFT)) + =
1)
 #define SPAGETABLE_SIZE         (SPAGETABLE_NR * sizeof(struct spage_info)=
)
 #define SPAGETABLE_VIRT_START   ((SPAGETABLE_VIRT_END - SPAGETABLE_SIZE) =
& \
-                                 (-1UL << SUPERPAGE_SHIFT))
+                                 (_AC(-1,UL) << SUPERPAGE_SHIFT))
 /* Slot 261: page-frame information array (128GB). */
 #define FRAMETABLE_VIRT_END     DIRECTMAP_VIRT_START
 #define FRAMETABLE_SIZE         GB(128)




--=__Part97A7D6A4.0__=
Content-Type: text/plain; name="x86-unify-constants.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-unify-constants.patch"

x86: use single definitions for a few constants=0A=0A... rather than =
having a C and an assembly one.=0A=0ASigned-off-by: Jan Beulich <jbeulich@s=
use.com>=0A=0A--- a/xen/include/asm-x86/config.h=0A+++ b/xen/include/asm-x8=
6/config.h=0A@@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128]=
=0A =0A #define CONFIG_COMPAT 1=0A =0A+#include <xen/const.h>=0A+=0A =
#define PML4_ENTRY_BITS  39=0A-#ifndef __ASSEMBLY__=0A-#define PML4_ENTRY_B=
YTES (1UL << PML4_ENTRY_BITS)=0A-#define PML4_ADDR(_slot)                  =
           \=0A-    ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \=0A- =
    (_slot ## UL << PML4_ENTRY_BITS))=0A-#define GB(_gb) (_gb ## UL << =
30)=0A-#else=0A-#define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)=0A-#define =
PML4_ADDR(_slot)                             \=0A-    (((_slot >> 8) * =
0xffff000000000000) | (_slot << PML4_ENTRY_BITS))=0A-#define GB(_gb) (_gb =
<< 30)=0A-#endif=0A+#define PML4_ENTRY_BYTES (_AC(1,UL) << PML4_ENTRY_BITS)=
=0A+#define PML4_ADDR(_slot)                              \=0A+    =
(((_AC(_slot, UL) >> 8) * _AC(0xffff000000000000,UL)) | \=0A+     =
(_AC(_slot, UL) << PML4_ENTRY_BITS))=0A+#define GB(_gb) (_AC(_gb, UL) << =
30)=0A =0A /*=0A  * Memory layout:=0A@@ -242,7 +237,7 @@ extern unsigned =
char boot_edid_info[128]=0A                                                =
           PAGE_SHIFT)) + 1)=0A #define SPAGETABLE_SIZE         (SPAGETABLE=
_NR * sizeof(struct spage_info))=0A #define SPAGETABLE_VIRT_START   =
((SPAGETABLE_VIRT_END - SPAGETABLE_SIZE) & \=0A-                           =
      (-1UL << SUPERPAGE_SHIFT))=0A+                                 =
(_AC(-1,UL) << SUPERPAGE_SHIFT))=0A /* Slot 261: page-frame information =
array (128GB). */=0A #define FRAMETABLE_VIRT_END     DIRECTMAP_VIRT_START=
=0A #define FRAMETABLE_SIZE         GB(128)=0A
--=__Part97A7D6A4.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

--=__Part97A7D6A4.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 16:59:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:59: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 1U629R-0001lA-IJ; Thu, 14 Feb 2013 16:59: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 1U629Q-0001l3-GB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:59:12 +0000
Received: from [85.158.143.99:5260] by server-1.bemta-4.messagelabs.com id
	15/02-08839-FD71D115; Thu, 14 Feb 2013 16:59:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360861149!26981251!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10173 invoked from network); 14 Feb 2013 16:59:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:59:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="1471582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16:59: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.297.1;
	Thu, 14 Feb 2013 16:59:03 +0000
Message-ID: <1360861142.20449.478.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:59:02 +0000
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/46] initial arm v8 (64-bit) 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


> I am building the 64-bit hypervisor with the Linaro gcc,
> gcc-linaro-aarch64-linux-gnu-4.7-2012.12-20121214_linux, from
> http://www.linaro.org/engineering/armv8#tab3 
> http://releases.linaro.org/13.01/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.7-2013.01-20130125_linux.tar.bz2

I forgot to mention that for the DTB I am using
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb built by the kernel tree,
passing it to the Xen build on the make command line:
        make -C xen XEN_TARGET_ARCH=arm64
        CONFIG_DTB_FILE=/home/ianc/vexpress-v2p-ca15-tc1-linux.dtb
        debug=y CROSS_COMPILE=aarch64-linux-gnu- -j12 -s install

Xen is passed to the model directly as the image to boot (no
bootwrapper)

The dom0 kernel is passed to the hypervisor in the flash "-C
motherboard.flashloader0.fname=zImage". The arm64 boot-wrapper is not
yet advanced enough to be ported to the scheme used in "xen: arm: parse
modules from DT during early boot." per
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02469.html

For the guest I use arch/arm/boot/xenvm-4.2.dtb and append it to the
zImage (the kernel config has CONFIG_ARM_APPENDED_DTB).
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 16:59:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 16:59: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 1U629R-0001lA-IJ; Thu, 14 Feb 2013 16:59: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 1U629Q-0001l3-GB
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 16:59:12 +0000
Received: from [85.158.143.99:5260] by server-1.bemta-4.messagelabs.com id
	15/02-08839-FD71D115; Thu, 14 Feb 2013 16:59:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360861149!26981251!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10173 invoked from network); 14 Feb 2013 16:59:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 16:59:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="1471582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 16:59: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.297.1;
	Thu, 14 Feb 2013 16:59:03 +0000
Message-ID: <1360861142.20449.478.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:59:02 +0000
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 00/46] initial arm v8 (64-bit) 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


> I am building the 64-bit hypervisor with the Linaro gcc,
> gcc-linaro-aarch64-linux-gnu-4.7-2012.12-20121214_linux, from
> http://www.linaro.org/engineering/armv8#tab3 
> http://releases.linaro.org/13.01/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.7-2013.01-20130125_linux.tar.bz2

I forgot to mention that for the DTB I am using
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb built by the kernel tree,
passing it to the Xen build on the make command line:
        make -C xen XEN_TARGET_ARCH=arm64
        CONFIG_DTB_FILE=/home/ianc/vexpress-v2p-ca15-tc1-linux.dtb
        debug=y CROSS_COMPILE=aarch64-linux-gnu- -j12 -s install

Xen is passed to the model directly as the image to boot (no
bootwrapper)

The dom0 kernel is passed to the hypervisor in the flash "-C
motherboard.flashloader0.fname=zImage". The arm64 boot-wrapper is not
yet advanced enough to be ported to the scheme used in "xen: arm: parse
modules from DT during early boot." per
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02469.html

For the guest I use arch/arm/boot/xenvm-4.2.dtb and append it to the
zImage (the kernel config has CONFIG_ARM_APPENDED_DTB).
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:01:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:01: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 1U62BP-0001vF-2p; Thu, 14 Feb 2013 17:01: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 1U62BN-0001v6-VU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:01:14 +0000
Received: from [85.158.143.35:61020] by server-2.bemta-4.messagelabs.com id
	FB/4D-01597-9581D115; Thu, 14 Feb 2013 17:01:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360861253!11276123!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23301 invoked from network); 14 Feb 2013 17:00:53 -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; 14 Feb 2013 17:00:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 17:00:52 +0000
Message-Id: <511D269002000078000BE73A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 17:01:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAC9CED90.0__="
Subject: [Xen-devel] [PATCH] x86: move watchdog declarations from config.h
	to nmi.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>
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.

--=__PartAC9CED90.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

They don't belong into the former.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -18,6 +18,7 @@
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/irq.h>
+#include <xen/nmi.h>
 #include <xen/delay.h>
 #include <xen/time.h>
 #include <xen/sched.h>
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -12,6 +12,7 @@
 #include <xen/delay.h>
 #include <xen/dmi.h>
 #include <xen/irq.h>
+#include <xen/nmi.h>
 #include <xen/console.h>
 #include <xen/shutdown.h>
 #include <xen/acpi.h>
--- a/xen/common/gdbstub.c
+++ b/xen/common/gdbstub.c
@@ -38,6 +38,7 @@
 #include <xen/spinlock.h>
 #include <xen/serial.h>
 #include <xen/irq.h>
+#include <xen/nmi.h>
 #include <asm/debugger.h>
 #include <xen/init.h>
 #include <xen/smp.h>
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -12,6 +12,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/guest_access.h>
+#include <xen/nmi.h>
 #include <xen/sched.h>
 #include <xen/types.h>
 #include <xen/kexec.h>
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -16,6 +16,7 @@
 #include <xen/ctype.h>
 #include <xen/perfc.h>
 #include <xen/mm.h>
+#include <xen/nmi.h>
 #include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -4,6 +4,7 @@
 #include <xen/sched.h>
 #include <xen/domain.h>
 #include <xen/delay.h>
+#include <xen/nmi.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
 #ifdef CONFIG_KEXEC
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -20,6 +20,7 @@
 #include <xen/keyhandler.h>
 #include <xen/delay.h>
 #include <xen/guest_access.h>
+#include <xen/nmi.h>
 #include <xen/shutdown.h>
 #include <xen/video.h>
 #include <xen/kexec.h>
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -317,10 +317,4 @@ extern unsigned long xen_phys_start;
=20
 #define ARCH_CRASH_SAVE_VMCOREINFO
=20
-#ifndef __ASSEMBLY__
-extern void watchdog_disable(void);
-extern void watchdog_enable(void);
-extern void watchdog_setup(void);
-#endif
-
 #endif /* __X86_CONFIG_H__ */
--- a/xen/include/asm-x86/nmi.h
+++ b/xen/include/asm-x86/nmi.h
@@ -41,4 +41,8 @@ long register_guest_nmi_callback(unsigne
  */
 long unregister_guest_nmi_callback(void);
=20
+void watchdog_disable(void);
+void watchdog_enable(void);
+void watchdog_setup(void);
+
 #endif /* ASM_NMI_H */




--=__PartAC9CED90.0__=
Content-Type: text/plain; name="x86-move-watchdog-decls.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-move-watchdog-decls.patch"

x86: move watchdog declarations from config.h to nmi.h=0A=0AThey don't =
belong into the former.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/nmi.c=0A+++ b/xen/arch/x86/nmi.c=0A@@ -18,6 +18,7 =
@@=0A #include <xen/lib.h>=0A #include <xen/mm.h>=0A #include <xen/irq.h>=
=0A+#include <xen/nmi.h>=0A #include <xen/delay.h>=0A #include <xen/time.h>=
=0A #include <xen/sched.h>=0A--- a/xen/arch/x86/shutdown.c=0A+++ b/xen/arch=
/x86/shutdown.c=0A@@ -12,6 +12,7 @@=0A #include <xen/delay.h>=0A #include =
<xen/dmi.h>=0A #include <xen/irq.h>=0A+#include <xen/nmi.h>=0A #include =
<xen/console.h>=0A #include <xen/shutdown.h>=0A #include <xen/acpi.h>=0A---=
 a/xen/common/gdbstub.c=0A+++ b/xen/common/gdbstub.c=0A@@ -38,6 +38,7 =
@@=0A #include <xen/spinlock.h>=0A #include <xen/serial.h>=0A #include =
<xen/irq.h>=0A+#include <xen/nmi.h>=0A #include <asm/debugger.h>=0A =
#include <xen/init.h>=0A #include <xen/smp.h>=0A--- a/xen/common/kexec.c=0A=
+++ b/xen/common/kexec.c=0A@@ -12,6 +12,7 @@=0A #include <xen/ctype.h>=0A =
#include <xen/errno.h>=0A #include <xen/guest_access.h>=0A+#include =
<xen/nmi.h>=0A #include <xen/sched.h>=0A #include <xen/types.h>=0A =
#include <xen/kexec.h>=0A--- a/xen/common/keyhandler.c=0A+++ b/xen/common/k=
eyhandler.c=0A@@ -16,6 +16,7 @@=0A #include <xen/ctype.h>=0A #include =
<xen/perfc.h>=0A #include <xen/mm.h>=0A+#include <xen/nmi.h>=0A #include =
<xen/init.h>=0A #include <asm/debugger.h>=0A #include <asm/div64.h>=0A--- =
a/xen/common/shutdown.c=0A+++ b/xen/common/shutdown.c=0A@@ -4,6 +4,7 @@=0A =
#include <xen/sched.h>=0A #include <xen/domain.h>=0A #include <xen/delay.h>=
=0A+#include <xen/nmi.h>=0A #include <xen/shutdown.h>=0A #include =
<xen/console.h>=0A #ifdef CONFIG_KEXEC=0A--- a/xen/drivers/char/console.c=
=0A+++ b/xen/drivers/char/console.c=0A@@ -20,6 +20,7 @@=0A #include =
<xen/keyhandler.h>=0A #include <xen/delay.h>=0A #include <xen/guest_access.=
h>=0A+#include <xen/nmi.h>=0A #include <xen/shutdown.h>=0A #include =
<xen/video.h>=0A #include <xen/kexec.h>=0A--- a/xen/include/asm-x86/config.=
h=0A+++ b/xen/include/asm-x86/config.h=0A@@ -317,10 +317,4 @@ extern =
unsigned long xen_phys_start;=0A =0A #define ARCH_CRASH_SAVE_VMCOREINFO=0A =
=0A-#ifndef __ASSEMBLY__=0A-extern void watchdog_disable(void);=0A-extern =
void watchdog_enable(void);=0A-extern void watchdog_setup(void);=0A-#endif=
=0A-=0A #endif /* __X86_CONFIG_H__ */=0A--- a/xen/include/asm-x86/nmi.h=0A+=
++ b/xen/include/asm-x86/nmi.h=0A@@ -41,4 +41,8 @@ long register_guest_nmi_=
callback(unsigne=0A  */=0A long unregister_guest_nmi_callback(void);=0A =
=0A+void watchdog_disable(void);=0A+void watchdog_enable(void);=0A+void =
watchdog_setup(void);=0A+=0A #endif /* ASM_NMI_H */=0A
--=__PartAC9CED90.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

--=__PartAC9CED90.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 17:01:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:01: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 1U62BP-0001vF-2p; Thu, 14 Feb 2013 17:01: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 1U62BN-0001v6-VU
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:01:14 +0000
Received: from [85.158.143.35:61020] by server-2.bemta-4.messagelabs.com id
	FB/4D-01597-9581D115; Thu, 14 Feb 2013 17:01:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360861253!11276123!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23301 invoked from network); 14 Feb 2013 17:00:53 -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; 14 Feb 2013 17:00:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 17:00:52 +0000
Message-Id: <511D269002000078000BE73A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 17:01:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAC9CED90.0__="
Subject: [Xen-devel] [PATCH] x86: move watchdog declarations from config.h
	to nmi.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>
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.

--=__PartAC9CED90.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

They don't belong into the former.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -18,6 +18,7 @@
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/irq.h>
+#include <xen/nmi.h>
 #include <xen/delay.h>
 #include <xen/time.h>
 #include <xen/sched.h>
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -12,6 +12,7 @@
 #include <xen/delay.h>
 #include <xen/dmi.h>
 #include <xen/irq.h>
+#include <xen/nmi.h>
 #include <xen/console.h>
 #include <xen/shutdown.h>
 #include <xen/acpi.h>
--- a/xen/common/gdbstub.c
+++ b/xen/common/gdbstub.c
@@ -38,6 +38,7 @@
 #include <xen/spinlock.h>
 #include <xen/serial.h>
 #include <xen/irq.h>
+#include <xen/nmi.h>
 #include <asm/debugger.h>
 #include <xen/init.h>
 #include <xen/smp.h>
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -12,6 +12,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/guest_access.h>
+#include <xen/nmi.h>
 #include <xen/sched.h>
 #include <xen/types.h>
 #include <xen/kexec.h>
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -16,6 +16,7 @@
 #include <xen/ctype.h>
 #include <xen/perfc.h>
 #include <xen/mm.h>
+#include <xen/nmi.h>
 #include <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -4,6 +4,7 @@
 #include <xen/sched.h>
 #include <xen/domain.h>
 #include <xen/delay.h>
+#include <xen/nmi.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
 #ifdef CONFIG_KEXEC
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -20,6 +20,7 @@
 #include <xen/keyhandler.h>
 #include <xen/delay.h>
 #include <xen/guest_access.h>
+#include <xen/nmi.h>
 #include <xen/shutdown.h>
 #include <xen/video.h>
 #include <xen/kexec.h>
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -317,10 +317,4 @@ extern unsigned long xen_phys_start;
=20
 #define ARCH_CRASH_SAVE_VMCOREINFO
=20
-#ifndef __ASSEMBLY__
-extern void watchdog_disable(void);
-extern void watchdog_enable(void);
-extern void watchdog_setup(void);
-#endif
-
 #endif /* __X86_CONFIG_H__ */
--- a/xen/include/asm-x86/nmi.h
+++ b/xen/include/asm-x86/nmi.h
@@ -41,4 +41,8 @@ long register_guest_nmi_callback(unsigne
  */
 long unregister_guest_nmi_callback(void);
=20
+void watchdog_disable(void);
+void watchdog_enable(void);
+void watchdog_setup(void);
+
 #endif /* ASM_NMI_H */




--=__PartAC9CED90.0__=
Content-Type: text/plain; name="x86-move-watchdog-decls.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-move-watchdog-decls.patch"

x86: move watchdog declarations from config.h to nmi.h=0A=0AThey don't =
belong into the former.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/nmi.c=0A+++ b/xen/arch/x86/nmi.c=0A@@ -18,6 +18,7 =
@@=0A #include <xen/lib.h>=0A #include <xen/mm.h>=0A #include <xen/irq.h>=
=0A+#include <xen/nmi.h>=0A #include <xen/delay.h>=0A #include <xen/time.h>=
=0A #include <xen/sched.h>=0A--- a/xen/arch/x86/shutdown.c=0A+++ b/xen/arch=
/x86/shutdown.c=0A@@ -12,6 +12,7 @@=0A #include <xen/delay.h>=0A #include =
<xen/dmi.h>=0A #include <xen/irq.h>=0A+#include <xen/nmi.h>=0A #include =
<xen/console.h>=0A #include <xen/shutdown.h>=0A #include <xen/acpi.h>=0A---=
 a/xen/common/gdbstub.c=0A+++ b/xen/common/gdbstub.c=0A@@ -38,6 +38,7 =
@@=0A #include <xen/spinlock.h>=0A #include <xen/serial.h>=0A #include =
<xen/irq.h>=0A+#include <xen/nmi.h>=0A #include <asm/debugger.h>=0A =
#include <xen/init.h>=0A #include <xen/smp.h>=0A--- a/xen/common/kexec.c=0A=
+++ b/xen/common/kexec.c=0A@@ -12,6 +12,7 @@=0A #include <xen/ctype.h>=0A =
#include <xen/errno.h>=0A #include <xen/guest_access.h>=0A+#include =
<xen/nmi.h>=0A #include <xen/sched.h>=0A #include <xen/types.h>=0A =
#include <xen/kexec.h>=0A--- a/xen/common/keyhandler.c=0A+++ b/xen/common/k=
eyhandler.c=0A@@ -16,6 +16,7 @@=0A #include <xen/ctype.h>=0A #include =
<xen/perfc.h>=0A #include <xen/mm.h>=0A+#include <xen/nmi.h>=0A #include =
<xen/init.h>=0A #include <asm/debugger.h>=0A #include <asm/div64.h>=0A--- =
a/xen/common/shutdown.c=0A+++ b/xen/common/shutdown.c=0A@@ -4,6 +4,7 @@=0A =
#include <xen/sched.h>=0A #include <xen/domain.h>=0A #include <xen/delay.h>=
=0A+#include <xen/nmi.h>=0A #include <xen/shutdown.h>=0A #include =
<xen/console.h>=0A #ifdef CONFIG_KEXEC=0A--- a/xen/drivers/char/console.c=
=0A+++ b/xen/drivers/char/console.c=0A@@ -20,6 +20,7 @@=0A #include =
<xen/keyhandler.h>=0A #include <xen/delay.h>=0A #include <xen/guest_access.=
h>=0A+#include <xen/nmi.h>=0A #include <xen/shutdown.h>=0A #include =
<xen/video.h>=0A #include <xen/kexec.h>=0A--- a/xen/include/asm-x86/config.=
h=0A+++ b/xen/include/asm-x86/config.h=0A@@ -317,10 +317,4 @@ extern =
unsigned long xen_phys_start;=0A =0A #define ARCH_CRASH_SAVE_VMCOREINFO=0A =
=0A-#ifndef __ASSEMBLY__=0A-extern void watchdog_disable(void);=0A-extern =
void watchdog_enable(void);=0A-extern void watchdog_setup(void);=0A-#endif=
=0A-=0A #endif /* __X86_CONFIG_H__ */=0A--- a/xen/include/asm-x86/nmi.h=0A+=
++ b/xen/include/asm-x86/nmi.h=0A@@ -41,4 +41,8 @@ long register_guest_nmi_=
callback(unsigne=0A  */=0A long unregister_guest_nmi_callback(void);=0A =
=0A+void watchdog_disable(void);=0A+void watchdog_enable(void);=0A+void =
watchdog_setup(void);=0A+=0A #endif /* ASM_NMI_H */=0A
--=__PartAC9CED90.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

--=__PartAC9CED90.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 14 17:02:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cj-00024k-Ia; Thu, 14 Feb 2013 17: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.Campbell@citrix.com>) id 1U62Ch-00024J-TD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:36 +0000
Received: from [85.158.143.99:46737] by server-2.bemta-4.messagelabs.com id
	9B/DE-01597-BA81D115; Thu, 14 Feb 2013 17:02:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26255 invoked from network); 14 Feb 2013 17:02:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532843"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-BY;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:59 +0000
Message-ID: <1360860480-9245-45-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 45/46] xen: arm: Fix guest mode for 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Need to check for the 64-bit EL2 modes, not 32-bit HYP mode.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/regs.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index a723f92..6bfab38 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -13,10 +13,16 @@
 #define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
 #define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
 #define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
-#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
 #define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
 #define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
 
+#ifdef CONFIG_ARM_32
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#else
+#define hyp_mode(r)     (psr_mode((r)->cpsr,PSR_MODE_EL2h) || \
+                         psr_mode((r)->cpsr,PSR_MODE_EL2t))
+#endif
+
 #define guest_mode(r)                                                         \
 ({                                                                            \
     unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
-- 
1.7.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 Feb 14 17:02:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cj-00024k-Ia; Thu, 14 Feb 2013 17: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.Campbell@citrix.com>) id 1U62Ch-00024J-TD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:36 +0000
Received: from [85.158.143.99:46737] by server-2.bemta-4.messagelabs.com id
	9B/DE-01597-BA81D115; Thu, 14 Feb 2013 17:02:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26255 invoked from network); 14 Feb 2013 17:02:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532843"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-BY;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:59 +0000
Message-ID: <1360860480-9245-45-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 45/46] xen: arm: Fix guest mode for 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Need to check for the 64-bit EL2 modes, not 32-bit HYP mode.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/regs.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index a723f92..6bfab38 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -13,10 +13,16 @@
 #define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
 #define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
 #define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
-#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
 #define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
 #define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
 
+#ifdef CONFIG_ARM_32
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#else
+#define hyp_mode(r)     (psr_mode((r)->cpsr,PSR_MODE_EL2h) || \
+                         psr_mode((r)->cpsr,PSR_MODE_EL2t))
+#endif
+
 #define guest_mode(r)                                                         \
 ({                                                                            \
     unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
-- 
1.7.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 Feb 14 17:02:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cp-00026M-C0; Thu, 14 Feb 2013 17:02: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 1U62Cn-00025i-Oe
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:42 +0000
Received: from [85.158.143.99:33631] by server-3.bemta-4.messagelabs.com id
	30/03-08920-1B81D115; Thu, 14 Feb 2013 17:02:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26483 invoked from network); 14 Feb 2013 17:02:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532865"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:38 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Fy;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:33 +0000
Message-ID: <1360860480-9245-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 19/46] xen: arm64: changes to
	setup_pagetables and mm.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Make *_table_offset return an unsigned int and adjust callers where
    necessary.
    Print "TTBR" instead of "TTBR0_EL2" when it is obvious from the ctxt.
---
 xen/arch/arm/arm32/head.S    |    2 +-
 xen/arch/arm/mm.c            |   46 +++++++++++++++++++++++------------------
 xen/include/asm-arm/cpregs.h |    2 +
 xen/include/asm-arm/page.h   |   10 +++++---
 4 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 5ec46c3..db3baa0 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -292,7 +292,7 @@ paging:
 
         /* Non-boot CPUs need to move on to the relocated pagetables */
         mov   r0, #0
-        ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
+        ldr   r4, =boot_ttbr         /* VA of HTTBR value stashed by CPU 0 */
         add   r4, r4, r10            /* PA of it */
         ldrd  r4, r5, [r4]           /* Actual value */
         dsb
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index bcc109d..fa57efe 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -40,13 +40,17 @@
 struct domain *dom_xen, *dom_io, *dom_cow;
 
 /* Static start-of-day pagetables that we use before the allocators are up */
+/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#ifdef CONFIG_ARM_64
+lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#endif
 lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
 lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
 /* Non-boot CPUs use this to find the correct pagetables. */
-uint64_t boot_httbr;
+uint64_t boot_ttbr;
 
 static paddr_t phys_offset;
 
@@ -70,24 +74,21 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
     if ( first_table_offset(addr) >= LPAE_ENTRIES )
         return;
 
-    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
-           first_table_offset(addr),
+    printk("1ST[0x%x] = 0x%"PRIpaddr"\n", first_table_offset(addr),
            first[first_table_offset(addr)].bits);
     if ( !first[first_table_offset(addr)].walk.valid ||
          !first[first_table_offset(addr)].walk.table )
         goto done;
 
     second = map_domain_page(first[first_table_offset(addr)].walk.base);
-    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
-           second_table_offset(addr),
+    printk("2ND[0x%x] = 0x%"PRIpaddr"\n", second_table_offset(addr),
            second[second_table_offset(addr)].bits);
     if ( !second[second_table_offset(addr)].walk.valid ||
          !second[second_table_offset(addr)].walk.table )
         goto done;
 
     third = map_domain_page(second[second_table_offset(addr)].walk.base);
-    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
-           third_table_offset(addr),
+    printk("3RD[0x%x] = 0x%"PRIpaddr"\n", third_table_offset(addr),
            third[third_table_offset(addr)].bits);
 
 done:
@@ -96,14 +97,14 @@ done:
 
 }
 
-void dump_hyp_walk(uint32_t addr)
+void dump_hyp_walk(vaddr_t addr)
 {
-    uint64_t httbr = READ_CP64(HTTBR);
+    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
 
-    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
-           addr, httbr);
+    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR 0x%016"PRIx64"\n",
+           addr, ttbr);
 
-    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != xen_pgtable );
     dump_pt_walk(xen_pgtable, addr);
 }
 
@@ -132,7 +133,7 @@ void *map_domain_page(unsigned long mfn)
     unsigned long flags;
     lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
     unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
-    uint32_t va;
+    vaddr_t va;
     lpae_t pte;
     int i, slot;
 
@@ -272,26 +273,31 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 
     /* Update the copy of xen_pgtable to use the new paddrs */
     p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+#ifdef CONFIG_ARM_64
+    p[0].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_first + dest_va - (unsigned long) _start;
+#endif
     for ( i = 0; i < 4; i++)
         p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
     p = (void *) xen_second + dest_va - (unsigned long) _start;
     if ( boot_phys_offset != 0 )
     {
         /* Remove the old identity mapping of the boot paddr */
-        unsigned long va = (unsigned long)_start + boot_phys_offset;
+        vaddr_t va = (vaddr_t)_start + boot_phys_offset;
         p[second_linear_offset(va)].bits = 0;
     }
     for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
         if ( p[i].pt.valid )
-                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+            p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
 
     /* Change pagetables to the copy in the relocated Xen */
-    boot_httbr = (unsigned long) xen_pgtable + phys_offset;
-    flush_xen_dcache(boot_httbr);
+    boot_ttbr = (uintptr_t) xen_pgtable + phys_offset;
+    flush_xen_dcache(boot_ttbr);
     flush_xen_dcache_va_range((void*)dest_va, _end - _start);
     flush_xen_text_tlb();
 
-    WRITE_CP64(boot_httbr, HTTBR); /* Change translation base */
+    WRITE_SYSREG64(boot_ttbr, TTBR0_EL2);
     dsb();                         /* Ensure visibility of HTTBR update */
     flush_xen_text_tlb();
 
@@ -336,7 +342,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     /* TLBFLUSH and ISB would be needed here, but wait until we set WXN */
 
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     /* Flush everything after setting WXN bit. */
     flush_xen_text_tlb();
 }
@@ -345,7 +351,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 void __cpuinit mmu_init_secondary_cpu(void)
 {
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     flush_xen_text_tlb();
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 559be75..36da12e 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -242,6 +242,8 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define SCTLR_EL2               HSCTLR
+#define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index ad52567..11b5930 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -274,7 +274,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
 /* Print a walk of the hypervisor's page tables for a virtual addr. */
-extern void dump_hyp_walk(uint32_t addr);
+extern void dump_hyp_walk(vaddr_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
@@ -326,9 +326,11 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 #define first_linear_offset(va) (va >> FIRST_SHIFT)
 #define second_linear_offset(va) (va >> SECOND_SHIFT)
 #define third_linear_offset(va) (va >> THIRD_SHIFT)
-#define first_table_offset(va) (first_linear_offset(va))
-#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
-#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define TABLE_OFFSET(offs) ((unsigned int)(offs) & LPAE_ENTRY_MASK)
+#define first_table_offset(va)  TABLE_OFFSET(first_linear_offset(va))
+#define second_table_offset(va) TABLE_OFFSET(second_linear_offset(va))
+#define third_table_offset(va)  TABLE_OFFSET(third_linear_offset(va))
 
 #define clear_page(page)memset((void *)(page), 0, PAGE_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 Thu Feb 14 17:02:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cp-00026M-C0; Thu, 14 Feb 2013 17:02: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 1U62Cn-00025i-Oe
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:42 +0000
Received: from [85.158.143.99:33631] by server-3.bemta-4.messagelabs.com id
	30/03-08920-1B81D115; Thu, 14 Feb 2013 17:02:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26483 invoked from network); 14 Feb 2013 17:02:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532865"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:38 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Fy;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:33 +0000
Message-ID: <1360860480-9245-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 19/46] xen: arm64: changes to
	setup_pagetables and mm.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Make *_table_offset return an unsigned int and adjust callers where
    necessary.
    Print "TTBR" instead of "TTBR0_EL2" when it is obvious from the ctxt.
---
 xen/arch/arm/arm32/head.S    |    2 +-
 xen/arch/arm/mm.c            |   46 +++++++++++++++++++++++------------------
 xen/include/asm-arm/cpregs.h |    2 +
 xen/include/asm-arm/page.h   |   10 +++++---
 4 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 5ec46c3..db3baa0 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -292,7 +292,7 @@ paging:
 
         /* Non-boot CPUs need to move on to the relocated pagetables */
         mov   r0, #0
-        ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
+        ldr   r4, =boot_ttbr         /* VA of HTTBR value stashed by CPU 0 */
         add   r4, r4, r10            /* PA of it */
         ldrd  r4, r5, [r4]           /* Actual value */
         dsb
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index bcc109d..fa57efe 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -40,13 +40,17 @@
 struct domain *dom_xen, *dom_io, *dom_cow;
 
 /* Static start-of-day pagetables that we use before the allocators are up */
+/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#ifdef CONFIG_ARM_64
+lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#endif
 lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
 lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
 /* Non-boot CPUs use this to find the correct pagetables. */
-uint64_t boot_httbr;
+uint64_t boot_ttbr;
 
 static paddr_t phys_offset;
 
@@ -70,24 +74,21 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
     if ( first_table_offset(addr) >= LPAE_ENTRIES )
         return;
 
-    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
-           first_table_offset(addr),
+    printk("1ST[0x%x] = 0x%"PRIpaddr"\n", first_table_offset(addr),
            first[first_table_offset(addr)].bits);
     if ( !first[first_table_offset(addr)].walk.valid ||
          !first[first_table_offset(addr)].walk.table )
         goto done;
 
     second = map_domain_page(first[first_table_offset(addr)].walk.base);
-    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
-           second_table_offset(addr),
+    printk("2ND[0x%x] = 0x%"PRIpaddr"\n", second_table_offset(addr),
            second[second_table_offset(addr)].bits);
     if ( !second[second_table_offset(addr)].walk.valid ||
          !second[second_table_offset(addr)].walk.table )
         goto done;
 
     third = map_domain_page(second[second_table_offset(addr)].walk.base);
-    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
-           third_table_offset(addr),
+    printk("3RD[0x%x] = 0x%"PRIpaddr"\n", third_table_offset(addr),
            third[third_table_offset(addr)].bits);
 
 done:
@@ -96,14 +97,14 @@ done:
 
 }
 
-void dump_hyp_walk(uint32_t addr)
+void dump_hyp_walk(vaddr_t addr)
 {
-    uint64_t httbr = READ_CP64(HTTBR);
+    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
 
-    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
-           addr, httbr);
+    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR 0x%016"PRIx64"\n",
+           addr, ttbr);
 
-    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != xen_pgtable );
     dump_pt_walk(xen_pgtable, addr);
 }
 
@@ -132,7 +133,7 @@ void *map_domain_page(unsigned long mfn)
     unsigned long flags;
     lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
     unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
-    uint32_t va;
+    vaddr_t va;
     lpae_t pte;
     int i, slot;
 
@@ -272,26 +273,31 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 
     /* Update the copy of xen_pgtable to use the new paddrs */
     p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+#ifdef CONFIG_ARM_64
+    p[0].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_first + dest_va - (unsigned long) _start;
+#endif
     for ( i = 0; i < 4; i++)
         p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
     p = (void *) xen_second + dest_va - (unsigned long) _start;
     if ( boot_phys_offset != 0 )
     {
         /* Remove the old identity mapping of the boot paddr */
-        unsigned long va = (unsigned long)_start + boot_phys_offset;
+        vaddr_t va = (vaddr_t)_start + boot_phys_offset;
         p[second_linear_offset(va)].bits = 0;
     }
     for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
         if ( p[i].pt.valid )
-                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+            p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
 
     /* Change pagetables to the copy in the relocated Xen */
-    boot_httbr = (unsigned long) xen_pgtable + phys_offset;
-    flush_xen_dcache(boot_httbr);
+    boot_ttbr = (uintptr_t) xen_pgtable + phys_offset;
+    flush_xen_dcache(boot_ttbr);
     flush_xen_dcache_va_range((void*)dest_va, _end - _start);
     flush_xen_text_tlb();
 
-    WRITE_CP64(boot_httbr, HTTBR); /* Change translation base */
+    WRITE_SYSREG64(boot_ttbr, TTBR0_EL2);
     dsb();                         /* Ensure visibility of HTTBR update */
     flush_xen_text_tlb();
 
@@ -336,7 +342,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     /* TLBFLUSH and ISB would be needed here, but wait until we set WXN */
 
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     /* Flush everything after setting WXN bit. */
     flush_xen_text_tlb();
 }
@@ -345,7 +351,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 void __cpuinit mmu_init_secondary_cpu(void)
 {
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     flush_xen_text_tlb();
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 559be75..36da12e 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -242,6 +242,8 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define SCTLR_EL2               HSCTLR
+#define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index ad52567..11b5930 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -274,7 +274,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
 /* Print a walk of the hypervisor's page tables for a virtual addr. */
-extern void dump_hyp_walk(uint32_t addr);
+extern void dump_hyp_walk(vaddr_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
@@ -326,9 +326,11 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 #define first_linear_offset(va) (va >> FIRST_SHIFT)
 #define second_linear_offset(va) (va >> SECOND_SHIFT)
 #define third_linear_offset(va) (va >> THIRD_SHIFT)
-#define first_table_offset(va) (first_linear_offset(va))
-#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
-#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define TABLE_OFFSET(offs) ((unsigned int)(offs) & LPAE_ENTRY_MASK)
+#define first_table_offset(va)  TABLE_OFFSET(first_linear_offset(va))
+#define second_table_offset(va) TABLE_OFFSET(second_linear_offset(va))
+#define third_table_offset(va)  TABLE_OFFSET(third_linear_offset(va))
 
 #define clear_page(page)memset((void *)(page), 0, PAGE_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 Thu Feb 14 17:02:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Ck-00025B-VE; Thu, 14 Feb 2013 17:02: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 1U62Ck-00024J-7y
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:38 +0000
Received: from [85.158.143.99:33515] by server-2.bemta-4.messagelabs.com id
	65/EE-01597-EA81D115; Thu, 14 Feb 2013 17:02:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13973 invoked from network); 14 Feb 2013 17:02:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163150"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:34 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-4A;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:53 +0000
Message-ID: <1360860480-9245-39-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 39/46] xen: arm: guest stage 1 walks on
	64-bit 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

Still only supports non-LPAE 32-bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1e64be1..e00fef0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -780,8 +780,8 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
-    uint32_t ttbcr = READ_CP32(TTBCR);
-    uint64_t ttbr0 = READ_CP64(TTBR0);
+    uint32_t ttbcr = READ_SYSREG32(TCR_EL1);
+    uint64_t ttbr0 = READ_SYSREG64(TTBR0_EL1);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = 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 Thu Feb 14 17:02:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Ck-00025B-VE; Thu, 14 Feb 2013 17:02: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 1U62Ck-00024J-7y
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:38 +0000
Received: from [85.158.143.99:33515] by server-2.bemta-4.messagelabs.com id
	65/EE-01597-EA81D115; Thu, 14 Feb 2013 17:02:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13973 invoked from network); 14 Feb 2013 17:02:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163150"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:34 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-4A;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:53 +0000
Message-ID: <1360860480-9245-39-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 39/46] xen: arm: guest stage 1 walks on
	64-bit 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

Still only supports non-LPAE 32-bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1e64be1..e00fef0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -780,8 +780,8 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
-    uint32_t ttbcr = READ_CP32(TTBCR);
-    uint64_t ttbr0 = READ_CP64(TTBR0);
+    uint32_t ttbcr = READ_SYSREG32(TCR_EL1);
+    uint64_t ttbr0 = READ_SYSREG64(TTBR0_EL1);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = 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 Thu Feb 14 17:02:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Cq-00026m-Q0; Thu, 14 Feb 2013 17:02: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 1U62Co-00024J-Ne
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:42 +0000
Received: from [85.158.143.99:33685] by server-2.bemta-4.messagelabs.com id
	C5/FE-01597-2B81D115; Thu, 14 Feb 2013 17:02:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14426 invoked from network); 14 Feb 2013 17:02:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163179"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:40 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-8y;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:26 +0000
Message-ID: <1360860480-9245-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 12/46] xen: arm64: dcache 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 "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.

Abstract the actual flush operation into a macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: revert to inline asm
---
 xen/include/asm-arm/arm32/page.h |    3 +++
 xen/include/asm-arm/arm64/page.h |    3 +++
 xen/include/asm-arm/page.h       |    8 ++++----
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index a384f04..2b15c22 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 99b7296..4911ba3 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 4e245a9..b89238b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
     void *end;
     dsb();           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
-        WRITE_CP32((uint32_t) p, DCCMVAC);
+        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
     dsb();           /* So we know the flushes happen before continuing */
 }
 
@@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
         flush_xen_dcache_va_range(_p, sizeof(x));                       \
     else                                                                \
         asm volatile (                                                  \
-            "dsb;"   /* Finish all earlier writes */                    \
-            STORE_CP32(0, DCCMVAC)                                      \
-            "dsb;"   /* Finish flush before continuing */               \
+            "dsb sy;"   /* Finish all earlier writes */                 \
+            __flush_xen_dcache_one(0)                                   \
+            "dsb sy;"   /* Finish flush before continuing */            \
             : : "r" (_p), "m" (*_p));                                   \
 } while (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 Feb 14 17:02:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Cq-00026m-Q0; Thu, 14 Feb 2013 17:02: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 1U62Co-00024J-Ne
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:42 +0000
Received: from [85.158.143.99:33685] by server-2.bemta-4.messagelabs.com id
	C5/FE-01597-2B81D115; Thu, 14 Feb 2013 17:02:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14426 invoked from network); 14 Feb 2013 17:02:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163179"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:40 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-8y;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:26 +0000
Message-ID: <1360860480-9245-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 12/46] xen: arm64: dcache 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 "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.

Abstract the actual flush operation into a macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: revert to inline asm
---
 xen/include/asm-arm/arm32/page.h |    3 +++
 xen/include/asm-arm/arm64/page.h |    3 +++
 xen/include/asm-arm/page.h       |    8 ++++----
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index a384f04..2b15c22 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 99b7296..4911ba3 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 4e245a9..b89238b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
     void *end;
     dsb();           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
-        WRITE_CP32((uint32_t) p, DCCMVAC);
+        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
     dsb();           /* So we know the flushes happen before continuing */
 }
 
@@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
         flush_xen_dcache_va_range(_p, sizeof(x));                       \
     else                                                                \
         asm volatile (                                                  \
-            "dsb;"   /* Finish all earlier writes */                    \
-            STORE_CP32(0, DCCMVAC)                                      \
-            "dsb;"   /* Finish flush before continuing */               \
+            "dsb sy;"   /* Finish all earlier writes */                 \
+            __flush_xen_dcache_one(0)                                   \
+            "dsb sy;"   /* Finish flush before continuing */            \
             : : "r" (_p), "m" (*_p));                                   \
 } while (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 Feb 14 17:02:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Cs-00027X-Dm; Thu, 14 Feb 2013 17:02: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 1U62Cr-00025i-Oe
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:45 +0000
Received: from [85.158.143.99:47200] by server-3.bemta-4.messagelabs.com id
	C5/13-08920-5B81D115; Thu, 14 Feb 2013 17:02:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26603 invoked from network); 14 Feb 2013 17:02:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532900"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:42 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-9u;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:58 +0000
Message-ID: <1360860480-9245-44-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 44/46] xen: arm: print arm64 not arm32 in xen
	info when appropriate.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5f9c785..52af819 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -63,8 +63,13 @@ static void print_xen_info(void)
 {
     char taint_str[TAINT_STRING_MAX_LEN];
 
-    printk("----[ Xen-%d.%d%s  arm32  debug=%c  %s ]----\n",
+    printk("----[ Xen-%d.%d%s  %s  debug=%c  %s ]----\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
+#ifdef CONFIG_ARM_32
+           "arm32",
+#else
+           "arm64",
+#endif
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-- 
1.7.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 Feb 14 17:02:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Cs-00027X-Dm; Thu, 14 Feb 2013 17:02: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 1U62Cr-00025i-Oe
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:45 +0000
Received: from [85.158.143.99:47200] by server-3.bemta-4.messagelabs.com id
	C5/13-08920-5B81D115; Thu, 14 Feb 2013 17:02:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26603 invoked from network); 14 Feb 2013 17:02:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532900"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:42 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-9u;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:58 +0000
Message-ID: <1360860480-9245-44-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 44/46] xen: arm: print arm64 not arm32 in xen
	info when appropriate.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5f9c785..52af819 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -63,8 +63,13 @@ static void print_xen_info(void)
 {
     char taint_str[TAINT_STRING_MAX_LEN];
 
-    printk("----[ Xen-%d.%d%s  arm32  debug=%c  %s ]----\n",
+    printk("----[ Xen-%d.%d%s  %s  debug=%c  %s ]----\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
+#ifdef CONFIG_ARM_32
+           "arm32",
+#else
+           "arm64",
+#endif
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-- 
1.7.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 Feb 14 17:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cu-000293-Sp; Thu, 14 Feb 2013 17:02: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 1U62Ct-00027p-CA
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:47 +0000
Received: from [85.158.143.99:37848] by server-1.bemta-4.messagelabs.com id
	01/86-08839-6B81D115; Thu, 14 Feb 2013 17:02:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14693 invoked from network); 14 Feb 2013 17:02:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163217"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:45 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-0S;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:47 +0000
Message-ID: <1360860480-9245-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 33/46] xen: arm: gic: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 7627ad8..e1af33a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -267,7 +267,7 @@ static void __init gic_dist_init(void)
 
     /* Disable all global interrupts */
     for ( i = 32; i < gic.lines; i += 32 )
-        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+        GICD[GICD_ICENABLER + i / 32] = (uint32_t)~0ul;
 
     /* Turn on the distributor */
     GICD[GICD_CTLR] = GICD_CTL_ENABLE;
@@ -531,18 +531,16 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 
 static void gic_inject_irq_start(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr | HCR_VI, HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr | HCR_VI, HCR_EL2);
     isb();
 }
 
 static void gic_inject_irq_stop(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
     if (hcr & HCR_VI) {
-        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        WRITE_SYSREG(hcr & ~HCR_VI, HCR_EL2);
         isb();
     }
 }
-- 
1.7.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 Feb 14 17:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cu-000293-Sp; Thu, 14 Feb 2013 17:02: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 1U62Ct-00027p-CA
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:47 +0000
Received: from [85.158.143.99:37848] by server-1.bemta-4.messagelabs.com id
	01/86-08839-6B81D115; Thu, 14 Feb 2013 17:02:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14693 invoked from network); 14 Feb 2013 17:02:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163217"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:45 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-0S;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:47 +0000
Message-ID: <1360860480-9245-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 33/46] xen: arm: gic: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 7627ad8..e1af33a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -267,7 +267,7 @@ static void __init gic_dist_init(void)
 
     /* Disable all global interrupts */
     for ( i = 32; i < gic.lines; i += 32 )
-        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+        GICD[GICD_ICENABLER + i / 32] = (uint32_t)~0ul;
 
     /* Turn on the distributor */
     GICD[GICD_CTLR] = GICD_CTL_ENABLE;
@@ -531,18 +531,16 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 
 static void gic_inject_irq_start(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr | HCR_VI, HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr | HCR_VI, HCR_EL2);
     isb();
 }
 
 static void gic_inject_irq_stop(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
     if (hcr & HCR_VI) {
-        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        WRITE_SYSREG(hcr & ~HCR_VI, HCR_EL2);
         isb();
     }
 }
-- 
1.7.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 Feb 14 17:02:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cy-0002C2-NV; Thu, 14 Feb 2013 17:02: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 1U62Cx-00027p-Se
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:52 +0000
Received: from [85.158.143.99:47443] by server-1.bemta-4.messagelabs.com id
	2D/96-08839-BB81D115; Thu, 14 Feb 2013 17:02:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14932 invoked from network); 14 Feb 2013 17:02:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163234"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:49 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-By;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:48:00 +0000
Message-ID: <1360860480-9245-46-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 46/46] xen: arm: skanky "appended kernel"
	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

I'm using this with the ARMv8 Foundation model:

./Foundation_v8pkg/Foundation_v8 \
	--image xen-unstable/xen/xen-arm64 \
	--data flash.img@0x80400000

where flash.img is a zImage (what you would put in Flash in the VE
models)

(disabled by default edit config.h to enable)

Mostly throwing this out there in case others find it useful.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c         |   14 ++++++++++++++
 xen/include/asm-arm/config.h |    2 ++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 94e9754..967a8d4 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -368,6 +368,20 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+#ifdef CONFIG_KERNEL_APPEND
+    early_info.modules.module[1].start  = boot_phys_offset + (uintptr_t)_end;
+    early_info.modules.module[1].start += (2<<20)-1;
+    early_info.modules.module[1].start &= ~((2<<20)-1);
+
+    early_info.modules.module[1].size = 4<<20;
+    early_info.modules.nr_mods = 1;
+    early_printk("assuming kernel is appended at "
+                 "%"PRIpaddr"-%"PRIpaddr"\n",
+                 early_info.modules.module[1].start,
+                 early_info.modules.module[1].start
+                 + early_info.modules.module[1].size);
+#endif
+
     cpus = smp_get_max_cpus();
     cmdline_parse(device_tree_bootargs(fdt));
 
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index add70bd..d02ef6c 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -34,6 +34,8 @@
 
 #define CONFIG_DOMAIN_PAGE 1
 
+//#define CONFIG_KERNEL_APPEND 1
+
 #define OPT_CONSOLE_STR "com1"
 
 #ifdef MAX_PHYS_CPUS
-- 
1.7.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 Feb 14 17:02:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cy-0002C2-NV; Thu, 14 Feb 2013 17:02: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 1U62Cx-00027p-Se
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:52 +0000
Received: from [85.158.143.99:47443] by server-1.bemta-4.messagelabs.com id
	2D/96-08839-BB81D115; Thu, 14 Feb 2013 17:02:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360861356!22318845!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14932 invoked from network); 14 Feb 2013 17:02:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163234"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:49 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-By;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:48:00 +0000
Message-ID: <1360860480-9245-46-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 46/46] xen: arm: skanky "appended kernel"
	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

I'm using this with the ARMv8 Foundation model:

./Foundation_v8pkg/Foundation_v8 \
	--image xen-unstable/xen/xen-arm64 \
	--data flash.img@0x80400000

where flash.img is a zImage (what you would put in Flash in the VE
models)

(disabled by default edit config.h to enable)

Mostly throwing this out there in case others find it useful.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c         |   14 ++++++++++++++
 xen/include/asm-arm/config.h |    2 ++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 94e9754..967a8d4 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -368,6 +368,20 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+#ifdef CONFIG_KERNEL_APPEND
+    early_info.modules.module[1].start  = boot_phys_offset + (uintptr_t)_end;
+    early_info.modules.module[1].start += (2<<20)-1;
+    early_info.modules.module[1].start &= ~((2<<20)-1);
+
+    early_info.modules.module[1].size = 4<<20;
+    early_info.modules.nr_mods = 1;
+    early_printk("assuming kernel is appended at "
+                 "%"PRIpaddr"-%"PRIpaddr"\n",
+                 early_info.modules.module[1].start,
+                 early_info.modules.module[1].start
+                 + early_info.modules.module[1].size);
+#endif
+
     cpus = smp_get_max_cpus();
     cmdline_parse(device_tree_bootargs(fdt));
 
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index add70bd..d02ef6c 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -34,6 +34,8 @@
 
 #define CONFIG_DOMAIN_PAGE 1
 
+//#define CONFIG_KERNEL_APPEND 1
+
 #define OPT_CONSOLE_STR "com1"
 
 #ifdef MAX_PHYS_CPUS
-- 
1.7.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 Feb 14 17:02:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cy-0002Bh-AD; Thu, 14 Feb 2013 17:02: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 1U62Cw-00025i-Ff
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:50 +0000
Received: from [85.158.143.99:37995] by server-3.bemta-4.messagelabs.com id
	3A/23-08920-AB81D115; Thu, 14 Feb 2013 17:02:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27016 invoked from network); 14 Feb 2013 17:02:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532959"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:47 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Sy;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:44 +0000
Message-ID: <1360860480-9245-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 30/46] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

One side effect of this is that we now save the full 64-bit
TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
support LPAE guests (although this patch doesn't implement anything
other than the context switch).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Nuke XXX and rationalise naming:
 s/tpidrurw/tpidr_el0/
 s/tpidrprw/tpidr_el1/
 s/tpidruro/tpidrro_el0/
---
 xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
 xen/arch/arm/traps.c         |   14 +++---
 xen/include/asm-arm/cpregs.h |   21 +++++++-
 xen/include/asm-arm/domain.h |   29 ++++++++---
 4 files changed, 115 insertions(+), 62 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index f74caf4..e0707ff 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -43,55 +43,67 @@ void idle_loop(void)
 static void ctxt_switch_from(struct vcpu *p)
 {
     /* CP 15 */
-    p->arch.csselr = READ_CP32(CSSELR);
+    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
 
     /* Control Registers */
-    p->arch.actlr = READ_CP32(ACTLR);
-    p->arch.sctlr = READ_CP32(SCTLR);
-    p->arch.cpacr = READ_CP32(CPACR);
+    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
+    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
+    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
 
-    p->arch.contextidr = READ_CP32(CONTEXTIDR);
-    p->arch.tpidrurw = READ_CP32(TPIDRURW);
-    p->arch.tpidruro = READ_CP32(TPIDRURO);
-    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
+    p->arch.tpidr_el0 = READ_SYSREG(TPIDR_EL0);
+    p->arch.tpidrro_el0 = READ_SYSREG(TPIDRRO_EL0);
+    p->arch.tpidr_el1 = READ_SYSREG(TPIDR_EL1);
 
     /* Arch timer */
     virt_timer_save(p);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     p->arch.teecr = READ_CP32(TEECR);
     p->arch.teehbr = READ_CP32(TEEHBR);
 
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
+#endif
 
     isb();
 
     /* MMU */
-    p->arch.vbar = READ_CP32(VBAR);
-    p->arch.ttbcr = READ_CP32(TTBCR);
-    /* XXX save 64 bit TTBR if guest is LPAE */
-    p->arch.ttbr0 = READ_CP32(TTBR0);
-    p->arch.ttbr1 = READ_CP32(TTBR1);
-
-    p->arch.dacr = READ_CP32(DACR);
-    p->arch.par = READ_CP64(PAR);
+    p->arch.vbar = READ_SYSREG(VBAR_EL1);
+    p->arch.ttbcr = READ_SYSREG(TCR_EL1);
+    p->arch.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    p->arch.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+    if ( is_pv32_domain(p->domain) )
+        p->arch.dacr = READ_SYSREG(DACR32_EL2);
+    p->arch.par = READ_SYSREG64(PAR_EL1);
+#if defined(CONFIG_ARM_32)
     p->arch.mair0 = READ_CP32(MAIR0);
     p->arch.mair1 = READ_CP32(MAIR1);
+#else
+    p->arch.mair = READ_SYSREG64(MAIR_EL1);
+#endif
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     p->arch.dfar = READ_CP32(DFAR);
     p->arch.ifar = READ_CP32(IFAR);
     p->arch.dfsr = READ_CP32(DFSR);
-    p->arch.ifsr = READ_CP32(IFSR);
-    p->arch.adfsr = READ_CP32(ADFSR);
-    p->arch.aifsr = READ_CP32(AIFSR);
+#elif defined(CONFIG_ARM_64)
+    p->arch.far = READ_SYSREG64(FAR_EL1);
+    p->arch.esr = READ_SYSREG64(ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(p->domain) )
+        p->arch.ifsr  = READ_SYSREG(IFSR32_EL2);
+    p->arch.afsr0 = READ_SYSREG(AFSR0_EL1);
+    p->arch.afsr1 = READ_SYSREG(AFSR1_EL1);
 
     /* XXX MPU */
 
     /* XXX VFP */
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_save_state(p);
 
     isb();
@@ -100,16 +112,16 @@ static void ctxt_switch_from(struct vcpu *p)
 
 static void ctxt_switch_to(struct vcpu *n)
 {
-    uint32_t hcr;
+    register_t hcr;
 
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
     isb();
 
     p2m_load_VTTBR(n->domain);
     isb();
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_restore_state(n);
 
     /* XXX VFP */
@@ -117,51 +129,62 @@ static void ctxt_switch_to(struct vcpu *n)
     /* XXX MPU */
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.dfar, DFAR);
     WRITE_CP32(n->arch.ifar, IFAR);
     WRITE_CP32(n->arch.dfsr, DFSR);
-    WRITE_CP32(n->arch.ifsr, IFSR);
-    WRITE_CP32(n->arch.adfsr, ADFSR);
-    WRITE_CP32(n->arch.aifsr, AIFSR);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.far, FAR_EL1);
+    WRITE_SYSREG64(n->arch.esr, ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.ifsr, IFSR32_EL2);
+    WRITE_SYSREG(n->arch.afsr0, AFSR0_EL1);
+    WRITE_SYSREG(n->arch.afsr1, AFSR1_EL1);
 
     /* MMU */
-    WRITE_CP32(n->arch.vbar, VBAR);
-    WRITE_CP32(n->arch.ttbcr, TTBCR);
-    /* XXX restore 64 bit TTBR if guest is LPAE */
-    WRITE_CP32(n->arch.ttbr0, TTBR0);
-    WRITE_CP32(n->arch.ttbr1, TTBR1);
-
-    WRITE_CP32(n->arch.dacr, DACR);
-    WRITE_CP64(n->arch.par, PAR);
+    WRITE_SYSREG(n->arch.vbar, VBAR_EL1);
+    WRITE_SYSREG(n->arch.ttbcr, TCR_EL1);
+    WRITE_SYSREG64(n->arch.ttbr0, TTBR0_EL1);
+    WRITE_SYSREG64(n->arch.ttbr1, TTBR1_EL1);
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.dacr, DACR32_EL2);
+    WRITE_SYSREG64(n->arch.par, PAR_EL1);
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.mair0, MAIR0);
     WRITE_CP32(n->arch.mair1, MAIR1);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.mair, MAIR_EL1);
+#endif
     isb();
 
     /* Control Registers */
-    WRITE_CP32(n->arch.actlr, ACTLR);
-    WRITE_CP32(n->arch.sctlr, SCTLR);
-    WRITE_CP32(n->arch.cpacr, CPACR);
+    WRITE_SYSREG(n->arch.actlr, ACTLR_EL1);
+    WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
+    WRITE_SYSREG(n->arch.cpacr, CPACR_EL1);
 
-    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
-    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
-    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
-    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+    WRITE_SYSREG(n->arch.contextidr, CONTEXTIDR_EL1);
+    WRITE_SYSREG(n->arch.tpidr_el0, TPIDR_EL0);
+    WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
+    WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     WRITE_CP32(n->arch.teecr, TEECR);
     WRITE_CP32(n->arch.teehbr, TEEHBR);
 
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
-
+#endif
     isb();
 
     /* CP 15 */
-    WRITE_CP32(n->arch.csselr, CSSELR);
+    WRITE_SYSREG(n->arch.csselr, CSSELR_EL1);
 
     isb();
 
-    WRITE_CP32(hcr, HCR);
+    WRITE_SYSREG(hcr, HCR_EL2);
     isb();
 
     /* This is could trigger an hardware interrupt from the virtual
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d6bdaa7..97a29fb 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,8 +214,8 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 static void _show_registers(struct cpu_user_regs *regs,
                             struct reg_ctxt *ctxt,
@@ -265,7 +265,7 @@ static void _show_registers(struct cpu_user_regs *regs,
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
         printk("\n");
-        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
                ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
@@ -295,8 +295,8 @@ void show_registers(struct cpu_user_regs *regs)
     struct reg_ctxt ctxt;
     ctxt.sctlr = READ_CP32(SCTLR);
     ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP32(TTBR0);
-    ctxt.ttbr1 = READ_CP32(TTBR1);
+    ctxt.ttbr0 = READ_CP64(TTBR0);
+    ctxt.ttbr1 = READ_CP64(TTBR1);
     _show_registers(regs, &ctxt, guest_mode(regs));
 }
 
@@ -631,14 +631,14 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
-    uint32_t ttbr0 = READ_CP32(TTBR0);
+    uint64_t ttbr0 = READ_CP64(TTBR0);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
     printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
-    printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
+    printk("    TTBR0: 0x%010"PRIx64" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
 
     if ( ttbcr & TTBCR_EAE )
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index dc69a06..732f967 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -106,9 +106,9 @@
 #define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
 
 /* CP15 CR2: Translation Table Base and Control Registers */
-#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
-#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
 #define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define TTBR0           p15,0,c2        /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,1,c2        /* Translation Table Base Reg. 1 */
 #define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
 #define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
 #define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
@@ -225,10 +225,17 @@
 /* Aliases of AArch64 names for use in common code when building for AArch32 */
 #ifdef CONFIG_ARM_32
 /* Alphabetically... */
+#define ACTLR_EL1               ACTLR
+#define AFSR0_EL1               ADFSR
+#define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CONTEXTIDR_EL1          CONTEXTIDR
+#define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
+#define DACR32_EL2              DACR
 #define ESR_EL2                 HSR
+#define HCR_EL2                 HCR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
@@ -243,9 +250,19 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define IFSR32_EL2              IFSR
+#define PAR_EL1                 PAR
+#define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
+#define TCR_EL1                 TTBCR
+#define TPIDRRO_EL0             TPIDRURO
+#define TPIDR_EL0               TPIDRURW
+#define TPIDR_EL1               TPIDRPRW
 #define TPIDR_EL2               HTPIDR
+#define TTBR0_EL1               TTBR0
 #define TTBR0_EL2               HTTBR
+#define TTBR1_EL1               TTBR1
+#define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index ff6214b..4a4bf2f 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -133,30 +133,43 @@ struct arch_vcpu
     struct cpu_info *cpu_info;
 
     /* Fault Status */
+#ifdef CONFIG_ARM_32
+    uint32_t dfsr;
     uint32_t dfar, ifar;
-    uint32_t dfsr, ifsr;
-    uint32_t adfsr, aifsr;
+#else
+    uint64_t far;
+    uint32_t esr;
+#endif
+
+    uint32_t ifsr; /* 32-bit guests only */
+    uint32_t afsr0, afsr1;
 
     /* MMU */
-    uint32_t vbar;
+    register_t vbar;
     uint32_t ttbcr;
-    uint32_t ttbr0, ttbr1;
+    uint64_t ttbr0, ttbr1;
 
-    uint32_t dacr;
+    uint32_t dacr; /* 32-bit guests only */
     uint64_t par;
+#ifdef CONFIG_ARM_32
     uint32_t mair0, mair1;
+#else
+    uint64_t mair;
+#endif
 
     /* Control Registers */
     uint32_t actlr, sctlr;
     uint32_t cpacr;
 
     uint32_t contextidr;
-    uint32_t tpidrurw;
-    uint32_t tpidruro;
-    uint32_t tpidrprw;
+    register_t tpidr_el0;
+    register_t tpidr_el1;
+    register_t tpidrro_el0;
 
+#ifdef CONFIG_ARM_32
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
+#endif
 
     /* CP 15 */
     uint32_t csselr;
-- 
1.7.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 Feb 14 17:02:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62Cy-0002Bh-AD; Thu, 14 Feb 2013 17:02: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 1U62Cw-00025i-Ff
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:50 +0000
Received: from [85.158.143.99:37995] by server-3.bemta-4.messagelabs.com id
	3A/23-08920-AB81D115; Thu, 14 Feb 2013 17:02:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27016 invoked from network); 14 Feb 2013 17:02:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532959"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:47 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Sy;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:44 +0000
Message-ID: <1360860480-9245-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 30/46] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

One side effect of this is that we now save the full 64-bit
TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
support LPAE guests (although this patch doesn't implement anything
other than the context switch).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Nuke XXX and rationalise naming:
 s/tpidrurw/tpidr_el0/
 s/tpidrprw/tpidr_el1/
 s/tpidruro/tpidrro_el0/
---
 xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
 xen/arch/arm/traps.c         |   14 +++---
 xen/include/asm-arm/cpregs.h |   21 +++++++-
 xen/include/asm-arm/domain.h |   29 ++++++++---
 4 files changed, 115 insertions(+), 62 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index f74caf4..e0707ff 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -43,55 +43,67 @@ void idle_loop(void)
 static void ctxt_switch_from(struct vcpu *p)
 {
     /* CP 15 */
-    p->arch.csselr = READ_CP32(CSSELR);
+    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
 
     /* Control Registers */
-    p->arch.actlr = READ_CP32(ACTLR);
-    p->arch.sctlr = READ_CP32(SCTLR);
-    p->arch.cpacr = READ_CP32(CPACR);
+    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
+    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
+    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
 
-    p->arch.contextidr = READ_CP32(CONTEXTIDR);
-    p->arch.tpidrurw = READ_CP32(TPIDRURW);
-    p->arch.tpidruro = READ_CP32(TPIDRURO);
-    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
+    p->arch.tpidr_el0 = READ_SYSREG(TPIDR_EL0);
+    p->arch.tpidrro_el0 = READ_SYSREG(TPIDRRO_EL0);
+    p->arch.tpidr_el1 = READ_SYSREG(TPIDR_EL1);
 
     /* Arch timer */
     virt_timer_save(p);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     p->arch.teecr = READ_CP32(TEECR);
     p->arch.teehbr = READ_CP32(TEEHBR);
 
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
+#endif
 
     isb();
 
     /* MMU */
-    p->arch.vbar = READ_CP32(VBAR);
-    p->arch.ttbcr = READ_CP32(TTBCR);
-    /* XXX save 64 bit TTBR if guest is LPAE */
-    p->arch.ttbr0 = READ_CP32(TTBR0);
-    p->arch.ttbr1 = READ_CP32(TTBR1);
-
-    p->arch.dacr = READ_CP32(DACR);
-    p->arch.par = READ_CP64(PAR);
+    p->arch.vbar = READ_SYSREG(VBAR_EL1);
+    p->arch.ttbcr = READ_SYSREG(TCR_EL1);
+    p->arch.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    p->arch.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+    if ( is_pv32_domain(p->domain) )
+        p->arch.dacr = READ_SYSREG(DACR32_EL2);
+    p->arch.par = READ_SYSREG64(PAR_EL1);
+#if defined(CONFIG_ARM_32)
     p->arch.mair0 = READ_CP32(MAIR0);
     p->arch.mair1 = READ_CP32(MAIR1);
+#else
+    p->arch.mair = READ_SYSREG64(MAIR_EL1);
+#endif
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     p->arch.dfar = READ_CP32(DFAR);
     p->arch.ifar = READ_CP32(IFAR);
     p->arch.dfsr = READ_CP32(DFSR);
-    p->arch.ifsr = READ_CP32(IFSR);
-    p->arch.adfsr = READ_CP32(ADFSR);
-    p->arch.aifsr = READ_CP32(AIFSR);
+#elif defined(CONFIG_ARM_64)
+    p->arch.far = READ_SYSREG64(FAR_EL1);
+    p->arch.esr = READ_SYSREG64(ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(p->domain) )
+        p->arch.ifsr  = READ_SYSREG(IFSR32_EL2);
+    p->arch.afsr0 = READ_SYSREG(AFSR0_EL1);
+    p->arch.afsr1 = READ_SYSREG(AFSR1_EL1);
 
     /* XXX MPU */
 
     /* XXX VFP */
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_save_state(p);
 
     isb();
@@ -100,16 +112,16 @@ static void ctxt_switch_from(struct vcpu *p)
 
 static void ctxt_switch_to(struct vcpu *n)
 {
-    uint32_t hcr;
+    register_t hcr;
 
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
     isb();
 
     p2m_load_VTTBR(n->domain);
     isb();
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_restore_state(n);
 
     /* XXX VFP */
@@ -117,51 +129,62 @@ static void ctxt_switch_to(struct vcpu *n)
     /* XXX MPU */
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.dfar, DFAR);
     WRITE_CP32(n->arch.ifar, IFAR);
     WRITE_CP32(n->arch.dfsr, DFSR);
-    WRITE_CP32(n->arch.ifsr, IFSR);
-    WRITE_CP32(n->arch.adfsr, ADFSR);
-    WRITE_CP32(n->arch.aifsr, AIFSR);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.far, FAR_EL1);
+    WRITE_SYSREG64(n->arch.esr, ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.ifsr, IFSR32_EL2);
+    WRITE_SYSREG(n->arch.afsr0, AFSR0_EL1);
+    WRITE_SYSREG(n->arch.afsr1, AFSR1_EL1);
 
     /* MMU */
-    WRITE_CP32(n->arch.vbar, VBAR);
-    WRITE_CP32(n->arch.ttbcr, TTBCR);
-    /* XXX restore 64 bit TTBR if guest is LPAE */
-    WRITE_CP32(n->arch.ttbr0, TTBR0);
-    WRITE_CP32(n->arch.ttbr1, TTBR1);
-
-    WRITE_CP32(n->arch.dacr, DACR);
-    WRITE_CP64(n->arch.par, PAR);
+    WRITE_SYSREG(n->arch.vbar, VBAR_EL1);
+    WRITE_SYSREG(n->arch.ttbcr, TCR_EL1);
+    WRITE_SYSREG64(n->arch.ttbr0, TTBR0_EL1);
+    WRITE_SYSREG64(n->arch.ttbr1, TTBR1_EL1);
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.dacr, DACR32_EL2);
+    WRITE_SYSREG64(n->arch.par, PAR_EL1);
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.mair0, MAIR0);
     WRITE_CP32(n->arch.mair1, MAIR1);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.mair, MAIR_EL1);
+#endif
     isb();
 
     /* Control Registers */
-    WRITE_CP32(n->arch.actlr, ACTLR);
-    WRITE_CP32(n->arch.sctlr, SCTLR);
-    WRITE_CP32(n->arch.cpacr, CPACR);
+    WRITE_SYSREG(n->arch.actlr, ACTLR_EL1);
+    WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
+    WRITE_SYSREG(n->arch.cpacr, CPACR_EL1);
 
-    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
-    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
-    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
-    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+    WRITE_SYSREG(n->arch.contextidr, CONTEXTIDR_EL1);
+    WRITE_SYSREG(n->arch.tpidr_el0, TPIDR_EL0);
+    WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
+    WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     WRITE_CP32(n->arch.teecr, TEECR);
     WRITE_CP32(n->arch.teehbr, TEEHBR);
 
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
-
+#endif
     isb();
 
     /* CP 15 */
-    WRITE_CP32(n->arch.csselr, CSSELR);
+    WRITE_SYSREG(n->arch.csselr, CSSELR_EL1);
 
     isb();
 
-    WRITE_CP32(hcr, HCR);
+    WRITE_SYSREG(hcr, HCR_EL2);
     isb();
 
     /* This is could trigger an hardware interrupt from the virtual
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d6bdaa7..97a29fb 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,8 +214,8 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 static void _show_registers(struct cpu_user_regs *regs,
                             struct reg_ctxt *ctxt,
@@ -265,7 +265,7 @@ static void _show_registers(struct cpu_user_regs *regs,
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
         printk("\n");
-        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
                ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
@@ -295,8 +295,8 @@ void show_registers(struct cpu_user_regs *regs)
     struct reg_ctxt ctxt;
     ctxt.sctlr = READ_CP32(SCTLR);
     ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP32(TTBR0);
-    ctxt.ttbr1 = READ_CP32(TTBR1);
+    ctxt.ttbr0 = READ_CP64(TTBR0);
+    ctxt.ttbr1 = READ_CP64(TTBR1);
     _show_registers(regs, &ctxt, guest_mode(regs));
 }
 
@@ -631,14 +631,14 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
-    uint32_t ttbr0 = READ_CP32(TTBR0);
+    uint64_t ttbr0 = READ_CP64(TTBR0);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
     printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
-    printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
+    printk("    TTBR0: 0x%010"PRIx64" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
 
     if ( ttbcr & TTBCR_EAE )
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index dc69a06..732f967 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -106,9 +106,9 @@
 #define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
 
 /* CP15 CR2: Translation Table Base and Control Registers */
-#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
-#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
 #define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define TTBR0           p15,0,c2        /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,1,c2        /* Translation Table Base Reg. 1 */
 #define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
 #define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
 #define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
@@ -225,10 +225,17 @@
 /* Aliases of AArch64 names for use in common code when building for AArch32 */
 #ifdef CONFIG_ARM_32
 /* Alphabetically... */
+#define ACTLR_EL1               ACTLR
+#define AFSR0_EL1               ADFSR
+#define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CONTEXTIDR_EL1          CONTEXTIDR
+#define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
+#define DACR32_EL2              DACR
 #define ESR_EL2                 HSR
+#define HCR_EL2                 HCR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
@@ -243,9 +250,19 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define IFSR32_EL2              IFSR
+#define PAR_EL1                 PAR
+#define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
+#define TCR_EL1                 TTBCR
+#define TPIDRRO_EL0             TPIDRURO
+#define TPIDR_EL0               TPIDRURW
+#define TPIDR_EL1               TPIDRPRW
 #define TPIDR_EL2               HTPIDR
+#define TTBR0_EL1               TTBR0
 #define TTBR0_EL2               HTTBR
+#define TTBR1_EL1               TTBR1
+#define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index ff6214b..4a4bf2f 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -133,30 +133,43 @@ struct arch_vcpu
     struct cpu_info *cpu_info;
 
     /* Fault Status */
+#ifdef CONFIG_ARM_32
+    uint32_t dfsr;
     uint32_t dfar, ifar;
-    uint32_t dfsr, ifsr;
-    uint32_t adfsr, aifsr;
+#else
+    uint64_t far;
+    uint32_t esr;
+#endif
+
+    uint32_t ifsr; /* 32-bit guests only */
+    uint32_t afsr0, afsr1;
 
     /* MMU */
-    uint32_t vbar;
+    register_t vbar;
     uint32_t ttbcr;
-    uint32_t ttbr0, ttbr1;
+    uint64_t ttbr0, ttbr1;
 
-    uint32_t dacr;
+    uint32_t dacr; /* 32-bit guests only */
     uint64_t par;
+#ifdef CONFIG_ARM_32
     uint32_t mair0, mair1;
+#else
+    uint64_t mair;
+#endif
 
     /* Control Registers */
     uint32_t actlr, sctlr;
     uint32_t cpacr;
 
     uint32_t contextidr;
-    uint32_t tpidrurw;
-    uint32_t tpidruro;
-    uint32_t tpidrprw;
+    register_t tpidr_el0;
+    register_t tpidr_el1;
+    register_t tpidrro_el0;
 
+#ifdef CONFIG_ARM_32
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
+#endif
 
     /* CP 15 */
     uint32_t csselr;
-- 
1.7.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 Feb 14 17:02:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62D3-0002Fh-57; Thu, 14 Feb 2013 17:02: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 1U62D1-00025i-De
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:55 +0000
Received: from [85.158.143.99:38200] by server-3.bemta-4.messagelabs.com id
	F1/43-08920-FB81D115; Thu, 14 Feb 2013 17:02:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27260 invoked from network); 14 Feb 2013 17:02:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532988"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:53 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Dv;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:31 +0000
Message-ID: <1360860480-9245-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 17/46] xen: arm64: div64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/div64.h |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
index 7b00808..d5bdc76 100644
--- a/xen/include/asm-arm/div64.h
+++ b/xen/include/asm-arm/div64.h
@@ -21,6 +21,19 @@
  * calling convention for arguments and results (beware).
  */
 
+
+#if BITS_PER_LONG == 64
+
+# define do_div(n,base) ({                                      \
+        uint32_t __base = (base);                               \
+        uint32_t __rem;                                         \
+        __rem = ((uint64_t)(n)) % __base;                       \
+        (n) = ((uint64_t)(n)) / __base;                         \
+        __rem;                                                  \
+ })
+
+#elif BITS_PER_LONG == 32
+
 #ifdef __ARMEB__
 #define __xh "r0"
 #define __xl "r1"
@@ -222,7 +235,9 @@
 	__nr;								\
 })
 
-#endif
+#endif /* GCC version */
+
+#endif /* BITS_PER_LONG */
 
 #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 Feb 14 17:02:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:02: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 1U62D3-0002Fh-57; Thu, 14 Feb 2013 17:02: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 1U62D1-00025i-De
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:02:55 +0000
Received: from [85.158.143.99:38200] by server-3.bemta-4.messagelabs.com id
	F1/43-08920-FB81D115; Thu, 14 Feb 2013 17:02:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27260 invoked from network); 14 Feb 2013 17:02:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7532988"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:53 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Dv;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:31 +0000
Message-ID: <1360860480-9245-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 17/46] xen: arm64: div64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/div64.h |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
index 7b00808..d5bdc76 100644
--- a/xen/include/asm-arm/div64.h
+++ b/xen/include/asm-arm/div64.h
@@ -21,6 +21,19 @@
  * calling convention for arguments and results (beware).
  */
 
+
+#if BITS_PER_LONG == 64
+
+# define do_div(n,base) ({                                      \
+        uint32_t __base = (base);                               \
+        uint32_t __rem;                                         \
+        __rem = ((uint64_t)(n)) % __base;                       \
+        (n) = ((uint64_t)(n)) / __base;                         \
+        __rem;                                                  \
+ })
+
+#elif BITS_PER_LONG == 32
+
 #ifdef __ARMEB__
 #define __xh "r0"
 #define __xl "r1"
@@ -222,7 +235,9 @@
 	__nr;								\
 })
 
-#endif
+#endif /* GCC version */
+
+#endif /* BITS_PER_LONG */
 
 #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 Feb 14 17:03:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62D8-0002K6-KB; Thu, 14 Feb 2013 17:03: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 1U62D6-0002HT-3c
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:00 +0000
Received: from [85.158.139.83:3660] by server-8.bemta-5.messagelabs.com id
	46/1F-19075-3C81D115; Thu, 14 Feb 2013 17:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 486 invoked from network); 14 Feb 2013 17:02:58 -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;
	14 Feb 2013 17:02:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163249"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:55 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-I3;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:35 +0000
Message-ID: <1360860480-9245-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 21/46] xen: arm: extend HSR struct
	definitions to 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change is that the 4-bit register specifiers are extended
to 5 bits by taking in an adjacent SBZP bit.

Also 64-bit has two other properties indicting whether or not the
target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
instruction has acquire/release semantics.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/processor.h |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 0768cd4..8183d36 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -99,11 +99,11 @@ union hsr {
         unsigned long ec:6;    /* Exception Class */
     };
 
+    /* reg, reg0, reg1 are 4 bits on AArch32, the fifth bit is sbzp. */
     struct hsr_cp32 {
         unsigned long read:1;  /* Direction */
         unsigned long crm:4;   /* CRm */
-        unsigned long reg:4;   /* Rt */
-        unsigned long sbzp:1;
+        unsigned long reg:5;   /* Rt */
         unsigned long crn:4;   /* CRn */
         unsigned long op1:3;   /* Op1 */
         unsigned long op2:3;   /* Op2 */
@@ -116,10 +116,9 @@ union hsr {
     struct hsr_cp64 {
         unsigned long read:1;   /* Direction */
         unsigned long crm:4;    /* CRm */
-        unsigned long reg1:4;   /* Rt1 */
-        unsigned long sbzp1:1;
-        unsigned long reg2:4;   /* Rt2 */
-        unsigned long sbzp2:2;
+        unsigned long reg1:5;   /* Rt1 */
+        unsigned long reg2:5;   /* Rt2 */
+        unsigned long sbzp2:1;
         unsigned long op1:4;   /* Op1 */
         unsigned long cc:4;    /* Condition Code */
         unsigned long ccvalid:1;/* CC Valid */
@@ -133,9 +132,14 @@ union hsr {
         unsigned long s1ptw:1; /* */
         unsigned long cache:1; /* Cache Maintenance */
         unsigned long eat:1;   /* External Abort Type */
+#ifdef CONFIG_ARM_32
         unsigned long sbzp0:6;
-        unsigned long reg:4;   /* Register */
-        unsigned long sbzp1:1;
+#else
+        unsigned long sbzp0:4;
+        unsigned long ar:1;    /* Acquire Release */
+        unsigned long sf:1;    /* Sixty Four bit register */
+#endif
+        unsigned long reg:5;   /* Register */
         unsigned long sign:1;  /* Sign extend */
         unsigned long size:2;  /* Access Size */
         unsigned long valid:1; /* Syndrome Valid */
-- 
1.7.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 Feb 14 17:03:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62D8-0002K6-KB; Thu, 14 Feb 2013 17:03: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 1U62D6-0002HT-3c
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:00 +0000
Received: from [85.158.139.83:3660] by server-8.bemta-5.messagelabs.com id
	46/1F-19075-3C81D115; Thu, 14 Feb 2013 17:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 486 invoked from network); 14 Feb 2013 17:02:58 -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;
	14 Feb 2013 17:02:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163249"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:55 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-I3;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:35 +0000
Message-ID: <1360860480-9245-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 21/46] xen: arm: extend HSR struct
	definitions to 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change is that the 4-bit register specifiers are extended
to 5 bits by taking in an adjacent SBZP bit.

Also 64-bit has two other properties indicting whether or not the
target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
instruction has acquire/release semantics.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/processor.h |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 0768cd4..8183d36 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -99,11 +99,11 @@ union hsr {
         unsigned long ec:6;    /* Exception Class */
     };
 
+    /* reg, reg0, reg1 are 4 bits on AArch32, the fifth bit is sbzp. */
     struct hsr_cp32 {
         unsigned long read:1;  /* Direction */
         unsigned long crm:4;   /* CRm */
-        unsigned long reg:4;   /* Rt */
-        unsigned long sbzp:1;
+        unsigned long reg:5;   /* Rt */
         unsigned long crn:4;   /* CRn */
         unsigned long op1:3;   /* Op1 */
         unsigned long op2:3;   /* Op2 */
@@ -116,10 +116,9 @@ union hsr {
     struct hsr_cp64 {
         unsigned long read:1;   /* Direction */
         unsigned long crm:4;    /* CRm */
-        unsigned long reg1:4;   /* Rt1 */
-        unsigned long sbzp1:1;
-        unsigned long reg2:4;   /* Rt2 */
-        unsigned long sbzp2:2;
+        unsigned long reg1:5;   /* Rt1 */
+        unsigned long reg2:5;   /* Rt2 */
+        unsigned long sbzp2:1;
         unsigned long op1:4;   /* Op1 */
         unsigned long cc:4;    /* Condition Code */
         unsigned long ccvalid:1;/* CC Valid */
@@ -133,9 +132,14 @@ union hsr {
         unsigned long s1ptw:1; /* */
         unsigned long cache:1; /* Cache Maintenance */
         unsigned long eat:1;   /* External Abort Type */
+#ifdef CONFIG_ARM_32
         unsigned long sbzp0:6;
-        unsigned long reg:4;   /* Register */
-        unsigned long sbzp1:1;
+#else
+        unsigned long sbzp0:4;
+        unsigned long ar:1;    /* Acquire Release */
+        unsigned long sf:1;    /* Sixty Four bit register */
+#endif
+        unsigned long reg:5;   /* Register */
         unsigned long sign:1;  /* Sign extend */
         unsigned long size:2;  /* Access Size */
         unsigned long valid:1; /* Syndrome Valid */
-- 
1.7.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 Feb 14 17:03:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62D7-0002JE-P0; Thu, 14 Feb 2013 17:03: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 1U62D6-00025i-47
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:00 +0000
Received: from [85.158.143.99:47811] by server-3.bemta-4.messagelabs.com id
	09/53-08920-3C81D115; Thu, 14 Feb 2013 17:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27403 invoked from network); 14 Feb 2013 17:02:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533004"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:57 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-6C;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:55 +0000
Message-ID: <1360860480-9245-41-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 41/46] xen: arm: Enable VFP is a nop on
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/vfp.h |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/vfp.h b/xen/include/asm-arm/vfp.h
index 0bab2a8..5c61376 100644
--- a/xen/include/asm-arm/vfp.h
+++ b/xen/include/asm-arm/vfp.h
@@ -3,6 +3,9 @@
 
 #include <xen/types.h>
 
+
+#ifdef CONFIG_ARM_32
+
 #define FPEXC_EN (1u << 30)
 
 /* Save and restore FP state.
@@ -17,12 +20,17 @@
     asm volatile ("fmxr fp" #reg ", %0" : : "r" (val)); \
 } while (0)
 
-
 /* Start-of-day: Turn on VFP */
 static inline void enable_vfp(void)
 {
     WRITE_FP(exc, READ_FP(exc) | FPEXC_EN);
 }
+#else
+static inline void enable_vfp(void)
+{
+    /* Always enable on 64-bit */
+}
+#endif
 
 #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 Feb 14 17:03:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62D7-0002JE-P0; Thu, 14 Feb 2013 17:03: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 1U62D6-00025i-47
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:00 +0000
Received: from [85.158.143.99:47811] by server-3.bemta-4.messagelabs.com id
	09/53-08920-3C81D115; Thu, 14 Feb 2013 17:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360861352!17788725!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27403 invoked from network); 14 Feb 2013 17:02:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533004"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:02:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:02:57 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-6C;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:55 +0000
Message-ID: <1360860480-9245-41-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 41/46] xen: arm: Enable VFP is a nop on
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/vfp.h |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/vfp.h b/xen/include/asm-arm/vfp.h
index 0bab2a8..5c61376 100644
--- a/xen/include/asm-arm/vfp.h
+++ b/xen/include/asm-arm/vfp.h
@@ -3,6 +3,9 @@
 
 #include <xen/types.h>
 
+
+#ifdef CONFIG_ARM_32
+
 #define FPEXC_EN (1u << 30)
 
 /* Save and restore FP state.
@@ -17,12 +20,17 @@
     asm volatile ("fmxr fp" #reg ", %0" : : "r" (val)); \
 } while (0)
 
-
 /* Start-of-day: Turn on VFP */
 static inline void enable_vfp(void)
 {
     WRITE_FP(exc, READ_FP(exc) | FPEXC_EN);
 }
+#else
+static inline void enable_vfp(void)
+{
+    /* Always enable on 64-bit */
+}
+#endif
 
 #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 Feb 14 17:03:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DB-0002MI-2f; Thu, 14 Feb 2013 17:03:05 +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 1U62D9-0002Ke-On
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:03 +0000
Received: from [85.158.139.83:3948] by server-14.bemta-5.messagelabs.com id
	F6/CF-06967-6C81D115; Thu, 14 Feb 2013 17:03:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 628 invoked from network); 14 Feb 2013 17:03:01 -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;
	14 Feb 2013 17:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163261"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:00 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-SQ;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:43 +0000
Message-ID: <1360860480-9245-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 29/46] xen: arm64: percpu variable 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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/cpregs.h |    1 +
 xen/include/asm-arm/percpu.h |    5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 75b6287..dc69a06 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -244,6 +244,7 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define SCTLR_EL2               HSCTLR
+#define TPIDR_EL2               HTPIDR
 #define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
index ab27292..e955136 100644
--- a/xen/include/asm-arm/percpu.h
+++ b/xen/include/asm-arm/percpu.h
@@ -11,18 +11,17 @@ void percpu_init_areas(void);
     __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
-
 #define per_cpu(var, cpu)  \
     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
 #define __get_cpu_var(var) \
-    (*RELOC_HIDE(&per_cpu__##var, READ_CP32(HTPIDR)))
+    (*RELOC_HIDE(&per_cpu__##var, READ_SYSREG(TPIDR_EL2)))
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 
 DECLARE_PER_CPU(unsigned int, cpu_id);
 #define get_processor_id()    (this_cpu(cpu_id))
 #define set_processor_id(id)  do {                      \
-    WRITE_CP32(__per_cpu_offset[id], HTPIDR);           \
+    WRITE_SYSREG(__per_cpu_offset[id], TPIDR_EL2);      \
     this_cpu(cpu_id) = (id);                            \
 } while(0)
 #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 Feb 14 17:03:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DB-0002MI-2f; Thu, 14 Feb 2013 17:03:05 +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 1U62D9-0002Ke-On
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:03 +0000
Received: from [85.158.139.83:3948] by server-14.bemta-5.messagelabs.com id
	F6/CF-06967-6C81D115; Thu, 14 Feb 2013 17:03:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 628 invoked from network); 14 Feb 2013 17:03:01 -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;
	14 Feb 2013 17:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163261"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:00 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-SQ;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:43 +0000
Message-ID: <1360860480-9245-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 29/46] xen: arm64: percpu variable 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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/cpregs.h |    1 +
 xen/include/asm-arm/percpu.h |    5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 75b6287..dc69a06 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -244,6 +244,7 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define SCTLR_EL2               HSCTLR
+#define TPIDR_EL2               HTPIDR
 #define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
index ab27292..e955136 100644
--- a/xen/include/asm-arm/percpu.h
+++ b/xen/include/asm-arm/percpu.h
@@ -11,18 +11,17 @@ void percpu_init_areas(void);
     __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
-
 #define per_cpu(var, cpu)  \
     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
 #define __get_cpu_var(var) \
-    (*RELOC_HIDE(&per_cpu__##var, READ_CP32(HTPIDR)))
+    (*RELOC_HIDE(&per_cpu__##var, READ_SYSREG(TPIDR_EL2)))
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 
 DECLARE_PER_CPU(unsigned int, cpu_id);
 #define get_processor_id()    (this_cpu(cpu_id))
 #define set_processor_id(id)  do {                      \
-    WRITE_CP32(__per_cpu_offset[id], HTPIDR);           \
+    WRITE_SYSREG(__per_cpu_offset[id], TPIDR_EL2);      \
     this_cpu(cpu_id) = (id);                            \
 } while(0)
 #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 Feb 14 17:03:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DF-0002Qk-Hl; Thu, 14 Feb 2013 17:03: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 1U62DE-0002On-0r
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:08 +0000
Received: from [85.158.139.83:28868] by server-12.bemta-5.messagelabs.com id
	6B/C6-20195-9C81D115; Thu, 14 Feb 2013 17:03:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 774 invoked from network); 14 Feb 2013 17:03:03 -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;
	14 Feb 2013 17:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163270"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:02 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-EM;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:32 +0000
Message-ID: <1360860480-9245-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 18/46] xen: arm64: start of day changes to
	setup.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: s/CSSELR_EL1/CCSIDR_EL1
---
 xen/arch/arm/setup.c         |   54 ++++++++++++++++++++++++++++--------------
 xen/include/asm-arm/cpregs.h |   25 +++++++++++++++++++
 2 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4e50b2b..c1f06c9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,16 +56,34 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
-    printk("Processor Features: %08x %08x\n",
-           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
-    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
-    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
-    printk("Memory Model Features: %08x %08x %08x %08x\n",
-           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
-           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
-    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
-           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+#if defined(CONFIG_ARM_64)
+    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
+    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
+    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
+    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
+    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+#endif
+    /*
+     * On AArch64 these refer to the capabilities when running in
+     * AArch32 mode.
+     */
+    printk("32-bit Processor Features: %08x %08x\n",
+           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
+    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
+    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
+    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
+           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
+    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
+           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
+           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
+
 }
 
 void __init discard_initial_modules(void)
@@ -250,7 +268,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    printk("Xen heap: %lu pages  Dom heap: %lu pages\n",
+           xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -320,8 +339,8 @@ void __init setup_cache(void)
     uint32_t ccsid;
 
     /* Read the cache size ID register for the level-0 data cache */
-    WRITE_CP32(0, CSSELR);
-    ccsid = READ_CP32(CCSIDR);
+    WRITE_SYSREG32(0, CSSELR_EL1);
+    ccsid = READ_SYSREG32(CCSIDR_EL1);
 
     /* Low 3 bits are log2(cacheline size in words) - 2. */
     cacheline_bytes = 1U << (4 + (ccsid & 0x7));
@@ -368,16 +387,15 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
-    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
-           READ_CP32(HVBAR), hyp_traps_vector);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    isb();
 
     /* Setup Stage 2 address translation */
     /* SH0=00, ORGN0=IRGN0=01
      * SL0=01 (Level-1)
      * T0SZ=(1)1000 = -8 (40 bit physical addresses)
      */
-    WRITE_CP32(0x80002558, VTCR); isb();
+    WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
     processor_id();
 
@@ -455,7 +473,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* Switch on to the dynamically allocated stack for the idle vcpu
      * since the static one we're running on is about to be freed. */
-    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(), 
+    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
            sizeof(struct cpu_info));
     switch_stack_and_jump(idle_vcpu[0]->arch.cpu_info, init_done);
 }
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7eaa50f..559be75 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -222,6 +222,31 @@
 
 /* CP15 CR15: Implementation Defined Registers */
 
+/* Aliases of AArch64 names for use in common code when building for AArch32 */
+#ifdef CONFIG_ARM_32
+/* Alphabetically... */
+#define CCSIDR_EL1              CCSIDR
+#define CLIDR_EL1               CLIDR
+#define CSSELR_EL1              CSSELR
+#define ID_AFR0_EL1             ID_AFR0
+#define ID_DFR0_EL1             ID_DFR0
+#define ID_ISAR0_EL1            ID_ISAR0
+#define ID_ISAR1_EL1            ID_ISAR1
+#define ID_ISAR2_EL1            ID_ISAR2
+#define ID_ISAR3_EL1            ID_ISAR3
+#define ID_ISAR4_EL1            ID_ISAR4
+#define ID_ISAR5_EL1            ID_ISAR5
+#define ID_MMFR0_EL1            ID_MMFR0
+#define ID_MMFR1_EL1            ID_MMFR1
+#define ID_MMFR2_EL1            ID_MMFR2
+#define ID_MMFR3_EL1            ID_MMFR3
+#define ID_PFR0_EL1             ID_PFR0
+#define ID_PFR1_EL1             ID_PFR1
+#define VBAR_EL2                HVBAR
+#define VTCR_EL2                VTCR
+
+#endif
+
 #endif
 /*
  * Local variables:
-- 
1.7.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 Feb 14 17:03:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DF-0002Qk-Hl; Thu, 14 Feb 2013 17:03: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 1U62DE-0002On-0r
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:08 +0000
Received: from [85.158.139.83:28868] by server-12.bemta-5.messagelabs.com id
	6B/C6-20195-9C81D115; Thu, 14 Feb 2013 17:03:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 774 invoked from network); 14 Feb 2013 17:03:03 -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;
	14 Feb 2013 17:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163270"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:02 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-EM;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:32 +0000
Message-ID: <1360860480-9245-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 18/46] xen: arm64: start of day changes to
	setup.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: s/CSSELR_EL1/CCSIDR_EL1
---
 xen/arch/arm/setup.c         |   54 ++++++++++++++++++++++++++++--------------
 xen/include/asm-arm/cpregs.h |   25 +++++++++++++++++++
 2 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 4e50b2b..c1f06c9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,16 +56,34 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
-    printk("Processor Features: %08x %08x\n",
-           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
-    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
-    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
-    printk("Memory Model Features: %08x %08x %08x %08x\n",
-           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
-           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
-    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
-           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+#if defined(CONFIG_ARM_64)
+    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
+    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
+    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
+    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
+    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+#endif
+    /*
+     * On AArch64 these refer to the capabilities when running in
+     * AArch32 mode.
+     */
+    printk("32-bit Processor Features: %08x %08x\n",
+           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
+    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
+    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
+    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
+           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
+    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
+           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
+           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
+
 }
 
 void __init discard_initial_modules(void)
@@ -250,7 +268,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    printk("Xen heap: %lu pages  Dom heap: %lu pages\n",
+           xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -320,8 +339,8 @@ void __init setup_cache(void)
     uint32_t ccsid;
 
     /* Read the cache size ID register for the level-0 data cache */
-    WRITE_CP32(0, CSSELR);
-    ccsid = READ_CP32(CCSIDR);
+    WRITE_SYSREG32(0, CSSELR_EL1);
+    ccsid = READ_SYSREG32(CCSIDR_EL1);
 
     /* Low 3 bits are log2(cacheline size in words) - 2. */
     cacheline_bytes = 1U << (4 + (ccsid & 0x7));
@@ -368,16 +387,15 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
-    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
-           READ_CP32(HVBAR), hyp_traps_vector);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    isb();
 
     /* Setup Stage 2 address translation */
     /* SH0=00, ORGN0=IRGN0=01
      * SL0=01 (Level-1)
      * T0SZ=(1)1000 = -8 (40 bit physical addresses)
      */
-    WRITE_CP32(0x80002558, VTCR); isb();
+    WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
     processor_id();
 
@@ -455,7 +473,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* Switch on to the dynamically allocated stack for the idle vcpu
      * since the static one we're running on is about to be freed. */
-    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(), 
+    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
            sizeof(struct cpu_info));
     switch_stack_and_jump(idle_vcpu[0]->arch.cpu_info, init_done);
 }
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7eaa50f..559be75 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -222,6 +222,31 @@
 
 /* CP15 CR15: Implementation Defined Registers */
 
+/* Aliases of AArch64 names for use in common code when building for AArch32 */
+#ifdef CONFIG_ARM_32
+/* Alphabetically... */
+#define CCSIDR_EL1              CCSIDR
+#define CLIDR_EL1               CLIDR
+#define CSSELR_EL1              CSSELR
+#define ID_AFR0_EL1             ID_AFR0
+#define ID_DFR0_EL1             ID_DFR0
+#define ID_ISAR0_EL1            ID_ISAR0
+#define ID_ISAR1_EL1            ID_ISAR1
+#define ID_ISAR2_EL1            ID_ISAR2
+#define ID_ISAR3_EL1            ID_ISAR3
+#define ID_ISAR4_EL1            ID_ISAR4
+#define ID_ISAR5_EL1            ID_ISAR5
+#define ID_MMFR0_EL1            ID_MMFR0
+#define ID_MMFR1_EL1            ID_MMFR1
+#define ID_MMFR2_EL1            ID_MMFR2
+#define ID_MMFR3_EL1            ID_MMFR3
+#define ID_PFR0_EL1             ID_PFR0
+#define ID_PFR1_EL1             ID_PFR1
+#define VBAR_EL2                HVBAR
+#define VTCR_EL2                VTCR
+
+#endif
+
 #endif
 /*
  * Local variables:
-- 
1.7.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 Feb 14 17:03:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62DM-0002Xs-Up; Thu, 14 Feb 2013 17:03:16 +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 1U62DL-0002W4-Av
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:15 +0000
Received: from [85.158.139.83:29509] by server-15.bemta-5.messagelabs.com id
	04/D6-18914-2D81D115; Thu, 14 Feb 2013 17:03:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1016 invoked from network); 14 Feb 2013 17:03:08 -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;
	14 Feb 2013 17:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163292"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:07 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-LM;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:37 +0000
Message-ID: <1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
	native register size for the 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
but:
        This is mostly a matter of coding taste, so I'd like Stefano's
        ack/nack here as well.
---
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/smpboot.c      |    2 +-
 xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
 xen/arch/arm/vgic.c         |   18 ++++++++--------
 xen/arch/arm/vpl011.c       |    6 ++--
 xen/arch/arm/vtimer.c       |    6 ++--
 xen/include/asm-arm/regs.h  |    2 +-
 xen/include/asm-arm/types.h |    4 +++
 8 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7403f1a..30d014a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 86379b7..d8eb5d3 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index eaf1f52..0299b33 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -68,7 +68,7 @@ static void print_xen_info(void)
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
+register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
@@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 
     switch ( reg ) {
     case 0 ... 7: /* Unbanked registers */
-        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
+        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
         return &regs->r0 + reg;
     case 8 ... 12: /* Register banked in FIQ mode */
-        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
+        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
         if ( fiq_mode(regs) )
             return &regs->r8_fiq + reg - 8;
         else
             return &regs->r8 + reg - 8;
     case 13 ... 14: /* Banked SP + LR registers */
-        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
-        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
-        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
-        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
-        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
+        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
+        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
+        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
+        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
+        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
         switch ( regs->cpsr & PSR_MODE_MASK )
         {
         case PSR_MODE_USR:
@@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
     printk("GUEST STACK GOES HERE\n");
 }
 
-#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
 
 static void show_trace(struct cpu_user_regs *regs)
 {
-    uint32_t *frame, next, addr, low, high;
+    register_t *frame, next, addr, low, high;
 
     printk("Xen call trace:\n   ");
 
@@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
     print_symbol(" %s\n   ", regs->pc);
 
     /* Bounds for range of valid frame pointer. */
-    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
     high = (low & ~(STACK_SIZE - 1)) +
         (STACK_SIZE - sizeof(struct cpu_info));
 
@@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
             break;
         {
             /* Ordinary stack frame. */
-            frame = (uint32_t *)next;
+            frame = (register_t *)next;
             next  = frame[-1];
             addr  = frame[0];
         }
@@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
         printk("[<%p>]", _p(addr));
         print_symbol(" %s\n   ", addr);
 
-        low = (uint32_t)&frame[1];
+        low = (register_t)&frame[1];
     }
 
     printk("\n");
@@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
 
 void show_stack(struct cpu_user_regs *regs)
 {
-    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
     int i;
 
     if ( guest_mode(regs) )
@@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
-    uint32_t reg, *r;
+    register_t *r;
+    uint32_t reg;
     uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = select_user_reg(regs, reg);
-        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
                domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
+        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
         break;
     case 0xfe:
-        printk("%c", (char)(regs->r0 & 0xff));
+        r = select_user_reg(regs, 0);
+        printk("%c", (char)(*r & 0xff));
         break;
     case 0xff:
         printk("DOM%d: DEBUG\n", domid);
@@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
 
     if ( !cp32.ccvalid ) {
         dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
@@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
                cp32.read ? "mrc" : "mcr",
                cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
         panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
@@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
                cp64.read ? "mrrc" : "mcrr",
                cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
         panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 39b9775..57147d5 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISPENDR ... GICD_ISPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
         return 0;
 
     case GICD_ICPENDR ... GICD_ICPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
         return 0;
 
@@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_SGIR:
         if ( dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
                *r, gicd_reg - GICD_ICFGR);
         return 0;
 
     case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
         return 0;
 
     case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
         return 0;
 
@@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
         goto write_ignore;
 
     default:
-        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         return 0;
     }
 
 bad_width:
-    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
            dabt.size, dabt.reg, *r, offset);
     domain_crash_synchronous();
     return 0;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 7dcee90..db5094e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
         /* Silently ignore */
         return 1;
     default:
-        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         domain_crash_synchronous();
     }
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 85201b5..291b87e 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
     s_time_t now;
 
     switch ( hsr.bits & HSR_CP32_REGS_MASK )
@@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp64 cp64 = hsr.cp64;
-    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
-    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
+    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
+    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
     uint64_t ticks;
     s_time_t now;
 
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index 7486944..a723f92 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -34,7 +34,7 @@
  * Returns a pointer to the given register value in regs, taking the
  * processor mode (CPSR) into account.
  */
-extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
+extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index d3e16d8..9ca32f1 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,6 +41,8 @@ typedef u32 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+typedef u32 register_t;
+#define PRIregister "x"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
@@ -49,6 +51,8 @@ typedef u64 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
+typedef u64 register_t;
+#define PRIregister "lx"
 #endif
 
 typedef unsigned long size_t;
-- 
1.7.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 Feb 14 17:03:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62DM-0002Xs-Up; Thu, 14 Feb 2013 17:03:16 +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 1U62DL-0002W4-Av
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:15 +0000
Received: from [85.158.139.83:29509] by server-15.bemta-5.messagelabs.com id
	04/D6-18914-2D81D115; Thu, 14 Feb 2013 17:03:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1016 invoked from network); 14 Feb 2013 17:03:08 -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;
	14 Feb 2013 17:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163292"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:07 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-LM;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:37 +0000
Message-ID: <1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
	native register size for the 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
but:
        This is mostly a matter of coding taste, so I'd like Stefano's
        ack/nack here as well.
---
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/smpboot.c      |    2 +-
 xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
 xen/arch/arm/vgic.c         |   18 ++++++++--------
 xen/arch/arm/vpl011.c       |    6 ++--
 xen/arch/arm/vtimer.c       |    6 ++--
 xen/include/asm-arm/regs.h  |    2 +-
 xen/include/asm-arm/types.h |    4 +++
 8 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7403f1a..30d014a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 86379b7..d8eb5d3 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index eaf1f52..0299b33 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -68,7 +68,7 @@ static void print_xen_info(void)
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
+register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
@@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 
     switch ( reg ) {
     case 0 ... 7: /* Unbanked registers */
-        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
+        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
         return &regs->r0 + reg;
     case 8 ... 12: /* Register banked in FIQ mode */
-        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
+        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
         if ( fiq_mode(regs) )
             return &regs->r8_fiq + reg - 8;
         else
             return &regs->r8 + reg - 8;
     case 13 ... 14: /* Banked SP + LR registers */
-        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
-        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
-        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
-        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
-        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
+        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
+        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
+        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
+        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
+        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
         switch ( regs->cpsr & PSR_MODE_MASK )
         {
         case PSR_MODE_USR:
@@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
     printk("GUEST STACK GOES HERE\n");
 }
 
-#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
 
 static void show_trace(struct cpu_user_regs *regs)
 {
-    uint32_t *frame, next, addr, low, high;
+    register_t *frame, next, addr, low, high;
 
     printk("Xen call trace:\n   ");
 
@@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
     print_symbol(" %s\n   ", regs->pc);
 
     /* Bounds for range of valid frame pointer. */
-    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
     high = (low & ~(STACK_SIZE - 1)) +
         (STACK_SIZE - sizeof(struct cpu_info));
 
@@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
             break;
         {
             /* Ordinary stack frame. */
-            frame = (uint32_t *)next;
+            frame = (register_t *)next;
             next  = frame[-1];
             addr  = frame[0];
         }
@@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
         printk("[<%p>]", _p(addr));
         print_symbol(" %s\n   ", addr);
 
-        low = (uint32_t)&frame[1];
+        low = (register_t)&frame[1];
     }
 
     printk("\n");
@@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
 
 void show_stack(struct cpu_user_regs *regs)
 {
-    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
     int i;
 
     if ( guest_mode(regs) )
@@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
-    uint32_t reg, *r;
+    register_t *r;
+    uint32_t reg;
     uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = select_user_reg(regs, reg);
-        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
                domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
+        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
         break;
     case 0xfe:
-        printk("%c", (char)(regs->r0 & 0xff));
+        r = select_user_reg(regs, 0);
+        printk("%c", (char)(*r & 0xff));
         break;
     case 0xff:
         printk("DOM%d: DEBUG\n", domid);
@@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
 
     if ( !cp32.ccvalid ) {
         dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
@@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
                cp32.read ? "mrc" : "mcr",
                cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
         panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
@@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
                cp64.read ? "mrrc" : "mcrr",
                cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
         panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 39b9775..57147d5 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISPENDR ... GICD_ISPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
         return 0;
 
     case GICD_ICPENDR ... GICD_ICPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
         return 0;
 
@@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_SGIR:
         if ( dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
                *r, gicd_reg - GICD_ICFGR);
         return 0;
 
     case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
         return 0;
 
     case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
         return 0;
 
@@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
         goto write_ignore;
 
     default:
-        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         return 0;
     }
 
 bad_width:
-    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
            dabt.size, dabt.reg, *r, offset);
     domain_crash_synchronous();
     return 0;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 7dcee90..db5094e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
         /* Silently ignore */
         return 1;
     default:
-        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         domain_crash_synchronous();
     }
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 85201b5..291b87e 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
     s_time_t now;
 
     switch ( hsr.bits & HSR_CP32_REGS_MASK )
@@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp64 cp64 = hsr.cp64;
-    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
-    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
+    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
+    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
     uint64_t ticks;
     s_time_t now;
 
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index 7486944..a723f92 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -34,7 +34,7 @@
  * Returns a pointer to the given register value in regs, taking the
  * processor mode (CPSR) into account.
  */
-extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
+extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index d3e16d8..9ca32f1 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,6 +41,8 @@ typedef u32 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+typedef u32 register_t;
+#define PRIregister "x"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
@@ -49,6 +51,8 @@ typedef u64 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
+typedef u64 register_t;
+#define PRIregister "lx"
 #endif
 
 typedef unsigned long size_t;
-- 
1.7.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 Feb 14 17:03:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62DO-0002Zk-IC; Thu, 14 Feb 2013 17:03: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 1U62DN-0002YF-Qf
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:18 +0000
Received: from [85.158.139.83:29674] by server-12.bemta-5.messagelabs.com id
	7C/27-20195-5D81D115; Thu, 14 Feb 2013 17:03:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1250 invoked from network); 14 Feb 2013 17:03:11 -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;
	14 Feb 2013 17:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163303"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:10 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-CK;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:28 +0000
Message-ID: <1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 14/46] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/asm-arm/arm32/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   28 ++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   20 ++++++++------------
 3 files changed, 65 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/system.h
 create mode 100644 xen/include/asm-arm/arm64/system.h

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
new file mode 100644
index 0000000..91098a0
--- /dev/null
+++ b/xen/include/asm-arm/arm32/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_ARM32_SYSTEM_H
+#define __ASM_ARM32_SYSTEM_H
+
+#define sev() __asm__ __volatile__ ("sev" : : : "memory")
+#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
+#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
new file mode 100644
index 0000000..33c031d
--- /dev/null
+++ b/xen/include/asm-arm/arm64/system.h
@@ -0,0 +1,28 @@
+/* Portions taken from Linux arch arm64 */
+#ifndef __ASM_ARM64_SYSTEM_H
+#define __ASM_ARM64_SYSTEM_H
+
+#define sev()           asm volatile("sev" : : : "memory")
+#define wfe()           asm volatile("wfe" : : : "memory")
+#define wfi()           asm volatile("wfi" : : : "memory")
+
+#define isb()           asm volatile("isb" : : : "memory")
+#define dsb()           asm volatile("dsb sy" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           asm volatile("dsb ld" : : : "memory")
+#define wmb()           asm volatile("dsb st" : : : "memory")
+
+#define smp_mb()        asm volatile("dmb ish" : : : "memory")
+#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
+#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 216ef1f..8b4c97a 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -11,18 +11,6 @@
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
 
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
-
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           mb()
-
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
-
 /*
  * This is used to ensure the compiler did actually allocate the register we
  * asked it for some inline assembly sequences.  Apparently we can't trust
@@ -33,6 +21,14 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/system.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/system.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 extern void __bad_xchg(volatile void *, int);
 
 static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 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 Thu Feb 14 17:03:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62DO-0002Zk-IC; Thu, 14 Feb 2013 17:03: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 1U62DN-0002YF-Qf
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:18 +0000
Received: from [85.158.139.83:29674] by server-12.bemta-5.messagelabs.com id
	7C/27-20195-5D81D115; Thu, 14 Feb 2013 17:03:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1250 invoked from network); 14 Feb 2013 17:03:11 -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;
	14 Feb 2013 17:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163303"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:10 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-CK;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:28 +0000
Message-ID: <1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 14/46] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/asm-arm/arm32/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   28 ++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   20 ++++++++------------
 3 files changed, 65 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/system.h
 create mode 100644 xen/include/asm-arm/arm64/system.h

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
new file mode 100644
index 0000000..91098a0
--- /dev/null
+++ b/xen/include/asm-arm/arm32/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_ARM32_SYSTEM_H
+#define __ASM_ARM32_SYSTEM_H
+
+#define sev() __asm__ __volatile__ ("sev" : : : "memory")
+#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
+#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
new file mode 100644
index 0000000..33c031d
--- /dev/null
+++ b/xen/include/asm-arm/arm64/system.h
@@ -0,0 +1,28 @@
+/* Portions taken from Linux arch arm64 */
+#ifndef __ASM_ARM64_SYSTEM_H
+#define __ASM_ARM64_SYSTEM_H
+
+#define sev()           asm volatile("sev" : : : "memory")
+#define wfe()           asm volatile("wfe" : : : "memory")
+#define wfi()           asm volatile("wfi" : : : "memory")
+
+#define isb()           asm volatile("isb" : : : "memory")
+#define dsb()           asm volatile("dsb sy" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           asm volatile("dsb ld" : : : "memory")
+#define wmb()           asm volatile("dsb st" : : : "memory")
+
+#define smp_mb()        asm volatile("dmb ish" : : : "memory")
+#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
+#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 216ef1f..8b4c97a 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -11,18 +11,6 @@
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
 
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
-
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           mb()
-
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
-
 /*
  * This is used to ensure the compiler did actually allocate the register we
  * asked it for some inline assembly sequences.  Apparently we can't trust
@@ -33,6 +21,14 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/system.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/system.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 extern void __bad_xchg(volatile void *, int);
 
 static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 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 Thu Feb 14 17:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DY-0002l3-CV; Thu, 14 Feb 2013 17:03:28 +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 1U62DW-0002iO-LM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:26 +0000
Received: from [85.158.139.83:30139] by server-6.bemta-5.messagelabs.com id
	A4/44-01489-DD81D115; Thu, 14 Feb 2013 17:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1994 invoked from network); 14 Feb 2013 17:03:21 -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;
	14 Feb 2013 17:03:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163331"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:20 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-9U;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:57 +0000
Message-ID: <1360860480-9245-43-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 43/46] xen: arm: Explicitly setup VPIDR &
	VMPIDR at start of day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 are supposed to reset to the value of the underlying hardware
but appears not to be on at least some v8 models. There's no harm in
setting them explicitly.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/setup.c         |    5 +++++
 xen/include/asm-arm/cpregs.h |    6 ++++++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 299848e..94e9754 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,6 +56,11 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
+
+    /* Setup the virtual ID to match the physical */
+    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
+    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+
 #if defined(CONFIG_ARM_64)
     printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
            READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 676c8cf..908aad9 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -95,6 +95,8 @@
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+#define VPIDR           p15,4,c0,c0,0   /* Virtualization Processor ID Register */
+#define VMPIDR          p15,4,c0,c0,5   /* Virtualization Multiprocessor ID Register */
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
@@ -278,6 +280,10 @@
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
+#define MIDR_EL1                MIDR
+#define VPIDR_EL2               VPIDR
+#define MPIDR_EL1               MPIDR
+#define VMPIDR_EL2              VMPIDR
 
 #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 Feb 14 17:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DY-0002l3-CV; Thu, 14 Feb 2013 17:03:28 +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 1U62DW-0002iO-LM
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:26 +0000
Received: from [85.158.139.83:30139] by server-6.bemta-5.messagelabs.com id
	A4/44-01489-DD81D115; Thu, 14 Feb 2013 17:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1994 invoked from network); 14 Feb 2013 17:03:21 -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;
	14 Feb 2013 17:03:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163331"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:20 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-9U;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:57 +0000
Message-ID: <1360860480-9245-43-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 43/46] xen: arm: Explicitly setup VPIDR &
	VMPIDR at start of day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 are supposed to reset to the value of the underlying hardware
but appears not to be on at least some v8 models. There's no harm in
setting them explicitly.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/setup.c         |    5 +++++
 xen/include/asm-arm/cpregs.h |    6 ++++++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 299848e..94e9754 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,6 +56,11 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
+
+    /* Setup the virtual ID to match the physical */
+    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
+    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+
 #if defined(CONFIG_ARM_64)
     printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
            READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 676c8cf..908aad9 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -95,6 +95,8 @@
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+#define VPIDR           p15,4,c0,c0,0   /* Virtualization Processor ID Register */
+#define VMPIDR          p15,4,c0,c0,5   /* Virtualization Multiprocessor ID Register */
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
@@ -278,6 +280,10 @@
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
+#define MIDR_EL1                MIDR
+#define VPIDR_EL2               VPIDR
+#define MPIDR_EL1               MPIDR
+#define VMPIDR_EL2              VMPIDR
 
 #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 Feb 14 17:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DX-0002ke-W9; Thu, 14 Feb 2013 17:03: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 1U62DW-0002iG-DS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:26 +0000
Received: from [85.158.139.83:30116] by server-10.bemta-5.messagelabs.com id
	77/3A-04697-DD81D115; Thu, 14 Feb 2013 17:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 14 Feb 2013 17:03:16 -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;
	14 Feb 2013 17:03:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163316"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Mm;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:40 +0000
Message-ID: <1360860480-9245-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 26/46] xen: arm: move arm32 specific trap
	handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm32/Makefile     |    3 +-
 xen/arch/arm/arm32/traps.c      |   53 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c            |   22 +---------------
 xen/include/asm-arm/processor.h |    2 +
 4 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 xen/arch/arm/arm32/traps.c

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 29898ae..1ad3364 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -4,4 +4,5 @@ obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
 
-obj-y += domain.o
+obj-y += traps.o
+obj-y += domain.o
\ No newline at end of file
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
new file mode 100644
index 0000000..a93c2f7
--- /dev/null
+++ b/xen/arch/arm/arm32/traps.c
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/arm32/traps.c
+ *
+ * ARM AArch32 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <public/xen.h>
+
+#include <asm/processor.h>
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0299b33..cb8a8d2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -423,33 +423,13 @@ void vcpu_show_execution_state(struct vcpu *v)
     vcpu_unpause(v);
 }
 
-static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
     show_execution_state(regs);
     while(1);
 }
 
-asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Undefined Instruction", regs);
-}
-
-asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Supervisor Call", regs);
-}
-
-asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Prefetch Abort", regs);
-}
-
-asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Data Abort", regs);
-}
-
 unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 {
         printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 230c901..bd473a8 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,8 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs);
+
 void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
                            struct vcpu_guest_core_regs *regs);
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
-- 
1.7.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 Feb 14 17:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DX-0002ke-W9; Thu, 14 Feb 2013 17:03: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 1U62DW-0002iG-DS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:26 +0000
Received: from [85.158.139.83:30116] by server-10.bemta-5.messagelabs.com id
	77/3A-04697-DD81D115; Thu, 14 Feb 2013 17:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1360861377!21416696!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 14 Feb 2013 17:03:16 -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;
	14 Feb 2013 17:03:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163316"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:15 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Mm;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:40 +0000
Message-ID: <1360860480-9245-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 26/46] xen: arm: move arm32 specific trap
	handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm32/Makefile     |    3 +-
 xen/arch/arm/arm32/traps.c      |   53 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c            |   22 +---------------
 xen/include/asm-arm/processor.h |    2 +
 4 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 xen/arch/arm/arm32/traps.c

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 29898ae..1ad3364 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -4,4 +4,5 @@ obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
 
-obj-y += domain.o
+obj-y += traps.o
+obj-y += domain.o
\ No newline at end of file
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
new file mode 100644
index 0000000..a93c2f7
--- /dev/null
+++ b/xen/arch/arm/arm32/traps.c
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/arm32/traps.c
+ *
+ * ARM AArch32 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <public/xen.h>
+
+#include <asm/processor.h>
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0299b33..cb8a8d2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -423,33 +423,13 @@ void vcpu_show_execution_state(struct vcpu *v)
     vcpu_unpause(v);
 }
 
-static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
     show_execution_state(regs);
     while(1);
 }
 
-asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Undefined Instruction", regs);
-}
-
-asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Supervisor Call", regs);
-}
-
-asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Prefetch Abort", regs);
-}
-
-asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Data Abort", regs);
-}
-
 unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 {
         printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 230c901..bd473a8 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,8 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs);
+
 void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
                            struct vcpu_guest_core_regs *regs);
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
-- 
1.7.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 Feb 14 17:03:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DZ-0002mf-PF; Thu, 14 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U62DY-0002lE-UX
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:29 +0000
Received: from [85.158.137.99:49901] by server-6.bemta-3.messagelabs.com id
	55/56-29959-0E81D115; Thu, 14 Feb 2013 17:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4847 invoked from network); 14 Feb 2013 17:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533032"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:04 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-2x;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:50 +0000
Message-ID: <1360860480-9245-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 36/46] xen: arm: Use 64-bit compatible
	registers in vtimer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, don't crash the host if we fail to emulate a vtimer access,
just kill the guest.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c  |   14 ++++++++++++--
 xen/arch/arm/vtimer.c |   23 +++++++++++++----------
 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 642b0ea..20d2db9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -712,7 +712,12 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 32-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
@@ -742,7 +747,12 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 64-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 291b87e..0051ff7 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -42,7 +42,7 @@ static void virt_timer_expired(void *data)
     struct vtimer *t = data;
     vcpu_wake(t->v);
 }
- 
+
 int vcpu_vtimer_init(struct vcpu *v)
 {
     struct vtimer *t = &v->arch.phys_timer;
@@ -57,7 +57,7 @@ int vcpu_vtimer_init(struct vcpu *v)
     t = &v->arch.virt_timer;
     init_timer(&t->timer, virt_timer_expired, t, smp_processor_id());
     t->ctl = 0;
-    t->offset = READ_CP64(CNTVCT) + READ_CP64(CNTVOFF);
+    t->offset = READ_SYSREG64(CNTVCT_EL0) + READ_SYSREG64(CNTVOFF_EL2);
     t->cval = 0;
     t->irq = 27;
     t->v = v;
@@ -73,9 +73,9 @@ void vcpu_timer_destroy(struct vcpu *v)
 
 int virt_timer_save(struct vcpu *v)
 {
-    v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
-    v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
+    v->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL_EL0);
+    v->arch.virt_timer.cval = READ_SYSREG64(CNTV_CVAL_EL0);
     if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
@@ -88,13 +88,13 @@ int virt_timer_restore(struct vcpu *v)
 {
     stop_timer(&v->arch.virt_timer.timer);
 
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
-    WRITE_CP64(v->arch.virt_timer.offset, CNTVOFF);
-    WRITE_CP64(v->arch.virt_timer.cval, CNTV_CVAL);
-    WRITE_CP32(v->arch.virt_timer.ctl, CNTV_CTL);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL_EL0);
+    WRITE_SYSREG64(v->arch.virt_timer.offset, CNTVOFF_EL2);
+    WRITE_SYSREG64(v->arch.virt_timer.cval, CNTV_CVAL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl, CNTV_CTL_EL0);
     return 0;
 }
- 
+
 static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
@@ -180,6 +180,9 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 
 int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
 {
+    if ( !is_pv32_domain(current->domain) )
+        return -EINVAL;
+
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
         return vtimer_emulate_32(regs, hsr);
-- 
1.7.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 Feb 14 17:03:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62DZ-0002mf-PF; Thu, 14 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U62DY-0002lE-UX
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:29 +0000
Received: from [85.158.137.99:49901] by server-6.bemta-3.messagelabs.com id
	55/56-29959-0E81D115; Thu, 14 Feb 2013 17:03:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4847 invoked from network); 14 Feb 2013 17:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533032"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:04 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-2x;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:50 +0000
Message-ID: <1360860480-9245-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 36/46] xen: arm: Use 64-bit compatible
	registers in vtimer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, don't crash the host if we fail to emulate a vtimer access,
just kill the guest.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c  |   14 ++++++++++++--
 xen/arch/arm/vtimer.c |   23 +++++++++++++----------
 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 642b0ea..20d2db9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -712,7 +712,12 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 32-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
@@ -742,7 +747,12 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 64-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 291b87e..0051ff7 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -42,7 +42,7 @@ static void virt_timer_expired(void *data)
     struct vtimer *t = data;
     vcpu_wake(t->v);
 }
- 
+
 int vcpu_vtimer_init(struct vcpu *v)
 {
     struct vtimer *t = &v->arch.phys_timer;
@@ -57,7 +57,7 @@ int vcpu_vtimer_init(struct vcpu *v)
     t = &v->arch.virt_timer;
     init_timer(&t->timer, virt_timer_expired, t, smp_processor_id());
     t->ctl = 0;
-    t->offset = READ_CP64(CNTVCT) + READ_CP64(CNTVOFF);
+    t->offset = READ_SYSREG64(CNTVCT_EL0) + READ_SYSREG64(CNTVOFF_EL2);
     t->cval = 0;
     t->irq = 27;
     t->v = v;
@@ -73,9 +73,9 @@ void vcpu_timer_destroy(struct vcpu *v)
 
 int virt_timer_save(struct vcpu *v)
 {
-    v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
-    v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
+    v->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL_EL0);
+    v->arch.virt_timer.cval = READ_SYSREG64(CNTV_CVAL_EL0);
     if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
@@ -88,13 +88,13 @@ int virt_timer_restore(struct vcpu *v)
 {
     stop_timer(&v->arch.virt_timer.timer);
 
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
-    WRITE_CP64(v->arch.virt_timer.offset, CNTVOFF);
-    WRITE_CP64(v->arch.virt_timer.cval, CNTV_CVAL);
-    WRITE_CP32(v->arch.virt_timer.ctl, CNTV_CTL);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL_EL0);
+    WRITE_SYSREG64(v->arch.virt_timer.offset, CNTVOFF_EL2);
+    WRITE_SYSREG64(v->arch.virt_timer.cval, CNTV_CVAL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl, CNTV_CTL_EL0);
     return 0;
 }
- 
+
 static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
@@ -180,6 +180,9 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 
 int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
 {
+    if ( !is_pv32_domain(current->domain) )
+        return -EINVAL;
+
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
         return vtimer_emulate_32(regs, hsr);
-- 
1.7.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 Feb 14 17:03:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Dc-0002qC-63; Thu, 14 Feb 2013 17:03: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 1U62Da-0002mi-Bm
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:30 +0000
Received: from [85.158.137.99:49150] by server-12.bemta-3.messagelabs.com id
	9E/C1-05889-1E81D115; Thu, 14 Feb 2013 17:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4981 invoked from network); 14 Feb 2013 17:03:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533059"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:13 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Jg;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:36 +0000
Message-ID: <1360860480-9245-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 22/46] xen: arm: use vaddr_t more widely.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/guestcopy.c |   16 +++++++++-------
 xen/include/asm-arm/mm.h |    6 +++---
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 5504e19..de1a216 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -8,7 +8,7 @@
 unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -17,7 +17,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -38,7 +38,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 unsigned long raw_clear_guest(void *to, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -47,7 +47,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -66,19 +66,21 @@ unsigned long raw_clear_guest(void *to, unsigned len)
 
 unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned len)
 {
+    unsigned offset = (vaddr_t)from & ~PAGE_MASK;
+
     while ( len )
     {
         int rc;
         paddr_t g;
         void *p;
-        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
 
-        rc = gvirt_to_maddr((uint32_t) from & PAGE_MASK, &g);
+        rc = gvirt_to_maddr((vaddr_t) from & PAGE_MASK, &g);
         if ( rc )
             return rc;
 
         p = map_domain_page(g>>PAGE_SHIFT);
-        p += ((unsigned long)from & (~PAGE_MASK));
+        p += ((vaddr_t)from & (~PAGE_MASK));
 
         memcpy(to, p, size);
 
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f04829d..ff838b3 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -184,8 +184,8 @@ void* early_ioremap(paddr_t start, size_t len, unsigned attributes);
 
 static inline paddr_t virt_to_maddr(const void *va)
 {
-    uint64_t par = va_to_par((uint32_t)va);
-    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+    uint64_t par = va_to_par((vaddr_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((vaddr_t) va & ~PAGE_MASK);
 }
 
 static inline void *maddr_to_virt(paddr_t ma)
@@ -195,7 +195,7 @@ static inline void *maddr_to_virt(paddr_t ma)
     return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
 }
 
-static inline int gvirt_to_maddr(uint32_t va, paddr_t *pa)
+static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa)
 {
     uint64_t par = gva_to_ma_par(va);
     if ( par & PAR_F )
-- 
1.7.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 Feb 14 17:03:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Dc-0002qC-63; Thu, 14 Feb 2013 17:03: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 1U62Da-0002mi-Bm
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:30 +0000
Received: from [85.158.137.99:49150] by server-12.bemta-3.messagelabs.com id
	9E/C1-05889-1E81D115; Thu, 14 Feb 2013 17:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4981 invoked from network); 14 Feb 2013 17:03:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533059"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:13 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Jg;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:36 +0000
Message-ID: <1360860480-9245-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 22/46] xen: arm: use vaddr_t more widely.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/guestcopy.c |   16 +++++++++-------
 xen/include/asm-arm/mm.h |    6 +++---
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 5504e19..de1a216 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -8,7 +8,7 @@
 unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -17,7 +17,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -38,7 +38,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 unsigned long raw_clear_guest(void *to, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -47,7 +47,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -66,19 +66,21 @@ unsigned long raw_clear_guest(void *to, unsigned len)
 
 unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned len)
 {
+    unsigned offset = (vaddr_t)from & ~PAGE_MASK;
+
     while ( len )
     {
         int rc;
         paddr_t g;
         void *p;
-        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
 
-        rc = gvirt_to_maddr((uint32_t) from & PAGE_MASK, &g);
+        rc = gvirt_to_maddr((vaddr_t) from & PAGE_MASK, &g);
         if ( rc )
             return rc;
 
         p = map_domain_page(g>>PAGE_SHIFT);
-        p += ((unsigned long)from & (~PAGE_MASK));
+        p += ((vaddr_t)from & (~PAGE_MASK));
 
         memcpy(to, p, size);
 
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f04829d..ff838b3 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -184,8 +184,8 @@ void* early_ioremap(paddr_t start, size_t len, unsigned attributes);
 
 static inline paddr_t virt_to_maddr(const void *va)
 {
-    uint64_t par = va_to_par((uint32_t)va);
-    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+    uint64_t par = va_to_par((vaddr_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((vaddr_t) va & ~PAGE_MASK);
 }
 
 static inline void *maddr_to_virt(paddr_t ma)
@@ -195,7 +195,7 @@ static inline void *maddr_to_virt(paddr_t ma)
     return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
 }
 
-static inline int gvirt_to_maddr(uint32_t va, paddr_t *pa)
+static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa)
 {
     uint64_t par = gva_to_ma_par(va);
     if ( par & PAR_F )
-- 
1.7.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 Feb 14 17:03:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62De-0002tw-KW; Thu, 14 Feb 2013 17:03: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 1U62Dc-0002pw-Fm
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:32 +0000
Received: from [85.158.139.83:30510] by server-15.bemta-5.messagelabs.com id
	73/57-18914-3E81D115; Thu, 14 Feb 2013 17:03:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23099 invoked from network); 14 Feb 2013 17:03:30 -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;
	14 Feb 2013 17:03:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163344"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:28 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-0r;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:48 +0000
Message-ID: <1360860480-9245-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 34/46] xen: arm: time: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c          |   48 +++++++++++++++++++++--------------------
 xen/include/asm-arm/cpregs.h |   12 ++++++++++
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 3dad9b3..ee92d8c 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -76,9 +76,9 @@ static uint32_t calibrate_timer(void)
     sec = rtc[0] + 1;
     do {} while ( rtc[0] != sec );
     // Now time a few seconds
-    start = READ_CP64(CNTPCT);
+    start = READ_SYSREG64(CNTPCT_EL0);
     do {} while ( rtc[0] < sec + 32 );
-    end = READ_CP64(CNTPCT);
+    end = READ_SYSREG64(CNTPCT_EL0);
     printk("done.\n");
 
     clear_fixmap(FIXMAP_MISC);
@@ -90,11 +90,13 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
+#if defined(CONFIG_ARM_32)
     if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
         panic("CPU does not support the Generic Timer v1 interface.\n");
+#endif
 
-    cpu_khz = READ_CP32(CNTFRQ) / 1000;
-    boot_count = READ_CP64(CNTPCT);
+    cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+    boot_count = READ_SYSREG64(CNTPCT_EL0);
     printk("Using generic timer at %lu KHz\n", cpu_khz);
 
     return 0;
@@ -103,7 +105,7 @@ int __init init_xen_time(void)
 /* Return number of nanoseconds since boot */
 s_time_t get_s_time(void)
 {
-    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    uint64_t ticks = READ_SYSREG64(CNTPCT_EL0) - boot_count;
     return ticks_to_ns(ticks);
 }
 
@@ -117,20 +119,20 @@ int reprogram_timer(s_time_t timeout)
     if ( timeout == 0 )
     {
 #if USE_HYP_TIMER
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
 #else
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
 #endif
         return 1;
     }
 
     deadline = ns_to_ticks(timeout) + boot_count;
 #if USE_HYP_TIMER
-    WRITE_CP64(deadline, CNTHP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+    WRITE_SYSREG64(deadline, CNTHP_CVAL_EL2);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTHP_CTL_EL2);
 #else
-    WRITE_CP64(deadline, CNTP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+    WRITE_SYSREG64(deadline, CNTP_CVAL_EL0);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTP_CTL_EL0);
 #endif
     isb();
 
@@ -142,27 +144,27 @@ int reprogram_timer(s_time_t timeout)
 /* Handle the firing timer */
 static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    if ( irq == 26 && READ_SYSREG32(CNTHP_CTL_EL2) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
     }
 
-    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    if (irq == 30 && READ_SYSREG32(CNTP_CTL_EL0) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
     }
 }
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
+    current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, irq, 1);
 }
 
@@ -170,17 +172,17 @@ static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 void __cpuinit init_timer_interrupt(void)
 {
     /* Sensible defaults */
-    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
-    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+    WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
+    WRITE_SYSREG32(0, CNTKCTL_EL1);     /* No user-mode access */
 #if USE_HYP_TIMER
     /* Do not let the VMs program the physical timer, only read the physical counter */
-    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
+    WRITE_SYSREG32(CNTHCTL_PA, CNTHCTL_EL2);
 #else
     /* Cannot let VMs access physical counter if we are using it */
-    WRITE_CP32(0, CNTHCTL);
+    WRITE_SYSREG32(0, CNTHCTL_EL2);
 #endif
-    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
-    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    WRITE_SYSREG32(0, CNTP_CTL_EL0);    /* Physical timer disabled */
+    WRITE_SYSREG32(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
     isb();
 
     /* XXX Need to find this IRQ number from devicetree? */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 732f967..a374f5c 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -230,6 +230,18 @@
 #define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CNTFRQ_EL0              CNTFRQ
+#define CNTHCTL_EL2             CNTHCTL
+#define CNTHP_CTL_EL2           CNTHP_CTL
+#define CNTHP_CVAL_EL2          CNTHP_CVAL
+#define CNTKCTL_EL1             CNTKCTL
+#define CNTPCT_EL0              CNTPCT
+#define CNTP_CTL_EL0            CNTP_CTL
+#define CNTP_CVAL_EL0           CNTP_CVAL
+#define CNTVCT_EL0              CNTVCT
+#define CNTVOFF_EL2             CNTVOFF
+#define CNTV_CTL_EL0            CNTV_CTL
+#define CNTV_CVAL_EL0           CNTV_CVAL
 #define CONTEXTIDR_EL1          CONTEXTIDR
 #define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
-- 
1.7.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 Feb 14 17:03:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62De-0002tw-KW; Thu, 14 Feb 2013 17:03: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 1U62Dc-0002pw-Fm
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:32 +0000
Received: from [85.158.139.83:30510] by server-15.bemta-5.messagelabs.com id
	73/57-18914-3E81D115; Thu, 14 Feb 2013 17:03:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23099 invoked from network); 14 Feb 2013 17:03:30 -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;
	14 Feb 2013 17:03:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163344"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:28 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-0r;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:48 +0000
Message-ID: <1360860480-9245-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 34/46] xen: arm: time: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c          |   48 +++++++++++++++++++++--------------------
 xen/include/asm-arm/cpregs.h |   12 ++++++++++
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 3dad9b3..ee92d8c 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -76,9 +76,9 @@ static uint32_t calibrate_timer(void)
     sec = rtc[0] + 1;
     do {} while ( rtc[0] != sec );
     // Now time a few seconds
-    start = READ_CP64(CNTPCT);
+    start = READ_SYSREG64(CNTPCT_EL0);
     do {} while ( rtc[0] < sec + 32 );
-    end = READ_CP64(CNTPCT);
+    end = READ_SYSREG64(CNTPCT_EL0);
     printk("done.\n");
 
     clear_fixmap(FIXMAP_MISC);
@@ -90,11 +90,13 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
+#if defined(CONFIG_ARM_32)
     if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
         panic("CPU does not support the Generic Timer v1 interface.\n");
+#endif
 
-    cpu_khz = READ_CP32(CNTFRQ) / 1000;
-    boot_count = READ_CP64(CNTPCT);
+    cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+    boot_count = READ_SYSREG64(CNTPCT_EL0);
     printk("Using generic timer at %lu KHz\n", cpu_khz);
 
     return 0;
@@ -103,7 +105,7 @@ int __init init_xen_time(void)
 /* Return number of nanoseconds since boot */
 s_time_t get_s_time(void)
 {
-    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    uint64_t ticks = READ_SYSREG64(CNTPCT_EL0) - boot_count;
     return ticks_to_ns(ticks);
 }
 
@@ -117,20 +119,20 @@ int reprogram_timer(s_time_t timeout)
     if ( timeout == 0 )
     {
 #if USE_HYP_TIMER
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
 #else
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
 #endif
         return 1;
     }
 
     deadline = ns_to_ticks(timeout) + boot_count;
 #if USE_HYP_TIMER
-    WRITE_CP64(deadline, CNTHP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+    WRITE_SYSREG64(deadline, CNTHP_CVAL_EL2);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTHP_CTL_EL2);
 #else
-    WRITE_CP64(deadline, CNTP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+    WRITE_SYSREG64(deadline, CNTP_CVAL_EL0);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTP_CTL_EL0);
 #endif
     isb();
 
@@ -142,27 +144,27 @@ int reprogram_timer(s_time_t timeout)
 /* Handle the firing timer */
 static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    if ( irq == 26 && READ_SYSREG32(CNTHP_CTL_EL2) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
     }
 
-    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    if (irq == 30 && READ_SYSREG32(CNTP_CTL_EL0) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
     }
 }
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
+    current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, irq, 1);
 }
 
@@ -170,17 +172,17 @@ static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 void __cpuinit init_timer_interrupt(void)
 {
     /* Sensible defaults */
-    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
-    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+    WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
+    WRITE_SYSREG32(0, CNTKCTL_EL1);     /* No user-mode access */
 #if USE_HYP_TIMER
     /* Do not let the VMs program the physical timer, only read the physical counter */
-    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
+    WRITE_SYSREG32(CNTHCTL_PA, CNTHCTL_EL2);
 #else
     /* Cannot let VMs access physical counter if we are using it */
-    WRITE_CP32(0, CNTHCTL);
+    WRITE_SYSREG32(0, CNTHCTL_EL2);
 #endif
-    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
-    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    WRITE_SYSREG32(0, CNTP_CTL_EL0);    /* Physical timer disabled */
+    WRITE_SYSREG32(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
     isb();
 
     /* XXX Need to find this IRQ number from devicetree? */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 732f967..a374f5c 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -230,6 +230,18 @@
 #define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CNTFRQ_EL0              CNTFRQ
+#define CNTHCTL_EL2             CNTHCTL
+#define CNTHP_CTL_EL2           CNTHP_CTL
+#define CNTHP_CVAL_EL2          CNTHP_CVAL
+#define CNTKCTL_EL1             CNTKCTL
+#define CNTPCT_EL0              CNTPCT
+#define CNTP_CTL_EL0            CNTP_CTL
+#define CNTP_CVAL_EL0           CNTP_CVAL
+#define CNTVCT_EL0              CNTVCT
+#define CNTVOFF_EL2             CNTVOFF
+#define CNTV_CTL_EL0            CNTV_CTL
+#define CNTV_CVAL_EL0           CNTV_CVAL
 #define CONTEXTIDR_EL1          CONTEXTIDR
 #define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
-- 
1.7.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 Feb 14 17:03:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Df-0002ub-1P; Thu, 14 Feb 2013 17:03: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 1U62Dc-0002pz-IS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:33 +0000
Received: from [85.158.137.99:50097] by server-3.bemta-3.messagelabs.com id
	41/9E-31070-3E81D115; Thu, 14 Feb 2013 17:03:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5100 invoked from network); 14 Feb 2013 17:03:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533074"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:18 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Lp;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:38 +0000
Message-ID: <1360860480-9245-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 24/46] xen: arm: separate guest user regs
	from internal guest 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

struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).

This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.

So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.

In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.

This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Allow 32-bit to see 64-bit register names too, this is needed so that
    32-bit toolstacks can access/control 64-bit guests.
---
 tools/include/xen-foreign/mkheader.py    |   10 +++
 tools/include/xen-foreign/reference.size |    5 +-
 tools/include/xen-foreign/structs.py     |    1 +
 tools/libxc/xc_dom_arm.c                 |   10 ++--
 xen/arch/arm/arm32/Makefile              |    2 +
 xen/arch/arm/arm32/domain.c              |   51 +++++++++++++
 xen/arch/arm/arm64/Makefile              |    2 +
 xen/arch/arm/arm64/domain.c              |   66 +++++++++++++++++
 xen/arch/arm/domain.c                    |    4 +-
 xen/arch/arm/domctl.c                    |    4 +-
 xen/include/asm-arm/arm32/processor.h    |   52 +++++++++++++
 xen/include/asm-arm/arm64/processor.h    |   81 +++++++++++++++++++++
 xen/include/asm-arm/current.h            |    1 +
 xen/include/asm-arm/processor.h          |    5 ++
 xen/include/public/arch-arm.h            |  115 ++++++++++++++++++------------
 15 files changed, 353 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain.c
 create mode 100644 xen/arch/arm/arm64/domain.c

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 4858687..c57b55b 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -25,6 +25,11 @@ inttypes["arm32"] = {
 };
 header["arm32"] = """
 #define __arm___ARM32 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
 footer["arm32"] = """
 #undef __DECL_REG
@@ -38,6 +43,11 @@ inttypes["arm64"] = {
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
 footer["arm64"] = """
 #undef __DECL_REG
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 7659c64..b3347b4 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -3,8 +3,9 @@ structs                   |   arm32   arm64  x86_32  x86_64
 
 start_info                |       -       -    1112    1168
 trap_info                 |       -       -       8      16
-cpu_user_regs             |     160     160      68     200
-vcpu_guest_context        |     180     180    2800    5168
+cpu_user_regs             |       -       -      68     200
+vcpu_guest_core_regs      |     304     304       -       -
+vcpu_guest_context        |     336     336    2800    5168
 arch_vcpu_info            |       0       0      24      16
 vcpu_time_info            |      32      32      32      32
 vcpu_info                 |      48      48      64      64
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 5aec2c5..0b33a77 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -6,6 +6,7 @@ unions  = [ "vcpu_cr_regs",
 structs = [ "start_info",
             "trap_info",
             "cpu_user_regs",
+            "vcpu_guest_core_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 0cec774..e46cec9 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -107,17 +107,17 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     /* clear everything */
     memset(ctxt, 0, sizeof(*ctxt));
 
-    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.pc32 = dom->parms.virt_entry;
 
     /* Linux boot protocol. See linux.Documentation/arm/Booting. */
-    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r0_usr = 0; /* SBZ */
     /* Machine ID: We use DTB therefore no machine id */
-    ctxt->user_regs.r1 = 0xffffffff;
+    ctxt->user_regs.r1_usr = 0xffffffff;
     /* ATAGS/DTB: We currently require that the guest kernel to be
      * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look
      * like a valid pointer to a set of ATAGS or a DTB.
      */
-    ctxt->user_regs.r2 = 0xffffffff;
+    ctxt->user_regs.r2_usr = 0xffffffff;
 
     ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
 
@@ -130,7 +130,7 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     ctxt->flags = VGCF_online;
 
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
-           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
     return 0;
 }
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 20931fa..29898ae 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -3,3 +3,5 @@ subdir-y += lib
 obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm32/domain.c b/xen/arch/arm/arm32/domain.c
new file mode 100644
index 0000000..f75a2c6
--- /dev/null
+++ b/xen/arch/arm/arm32/domain.c
@@ -0,0 +1,51 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(r0,r0_usr);   C(r1,r1_usr);   C(r2,r2_usr);   C(r3,r3_usr);   \
+    C(r4,r4_usr);   C(r5,r5_usr);   C(r6,r6_usr);   C(r7,r7_usr);   \
+    C(r8,r8_usr);   C(r9,r9_usr);   C(r10,r10_usr); C(r11,r11_usr); \
+    C(r12,r12_usr); \
+    C(sp_usr,sp_usr); \
+    C(lr,lr_usr); \
+    C(spsr_irq,spsr_irq); C(lr_irq,lr_irq); C(sp_irq,sp_irq); \
+    C(spsr_svc,spsr_svc); C(lr_svc,lr_svc); C(sp_svc,sp_svc); \
+    C(spsr_abt,spsr_abt); C(lr_abt,lr_abt); C(sp_abt,sp_abt); \
+    C(spsr_und,spsr_und); C(lr_und,lr_und); C(sp_und,sp_und); \
+    C(spsr_fiq,spsr_fiq); C(sp_fiq,sp_fiq); C(sp_fiq,sp_fiq); \
+    C(r8_fiq,r8_fiq); C(r9_fiq,r9_fiq); \
+    C(r10_fiq,r10_fiq); C(r11_fiq,r11_fiq); C(r12_fiq,r12_fiq); \
+    C(pc,pc32); \
+    C(cpsr,cpsr)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c447eaa..815f305 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,3 +1,5 @@
 subdir-y += lib
 
 obj-y += mode_switch.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm64/domain.c b/xen/arch/arm/arm64/domain.c
new file mode 100644
index 0000000..05df29e
--- /dev/null
+++ b/xen/arch/arm/arm64/domain.c
@@ -0,0 +1,66 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(x0,x0);   C(x1,x1);   C(x2,x2);   C(x3,x3);   \
+    C(x4,x4);   C(x5,x5);   C(x6,x6);   C(x7,x7);   \
+    C(x8,x8);   C(x9,x9);   C(x10,x10); C(x11,x11); \
+    C(x12,x12); C(x13,x13); C(x14,x14); C(x15,x15); \
+    C(x16,x16); C(x17,x17); C(x18,x18); C(x19,x19); \
+    C(x20,x20); C(x21,x21); C(x22,x22); C(x23,x23); \
+    C(x24,x24); C(x25,x25); C(x26,x26); C(x27,x27); \
+    C(x28,x28); C(fp,x29);  C(lr,x30);  C(pc,pc64); \
+    C(cpsr, cpsr); C(spsr_el1, spsr_el1)
+
+#define ALLREGS32 C(spsr_fiq, spsr_fiq); C(spsr_irq,spsr_irq); \
+                  C(spsr_und,spsr_und); C(spsr_abt,spsr_abt)
+
+#define ALLREGS64 C(sp_el0,sp_el0); C(sp_el1,sp_el1); C(elr_el1,elr_el1)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e7d3ec6..3651fb2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,7 +486,7 @@ int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
     if ( !is_guest_psr(regs->cpsr) )
         return -EINVAL;
@@ -502,7 +502,7 @@ int arch_set_info_guest(
     if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
         return -EINVAL;
 
-    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+    vcpu_regs_user_to_hyp(v, regs);
 
     v->arch.sctlr = ctxt->sctlr;
     v->arch.ttbr0 = ctxt->ttbr0;
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index c7ffd8a..15f8537 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -20,9 +20,9 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
-    *regs = v->arch.cpu_info->guest_cpu_user_regs;
+    vcpu_regs_hyp_to_user(v, regs);
 
     ctxt->sctlr = v->arch.sctlr;
     ctxt->ttbr0 = v->arch.ttbr0;
diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
index 843fbd2..a782d96 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,58 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#ifndef __ASSEMBLY__
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+        uint32_t r11;
+        uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+        uint32_t lr_usr;
+    };
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_irq, lr_irq;
+    uint32_t sp_svc, lr_svc;
+    uint32_t sp_abt, lr_abt;
+    uint32_t sp_und, lr_und;
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+    uint32_t sp_fiq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
+};
+#endif
+
 /* Layout as used in assembly, with src/dest registers mixed in */
 #define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
 #define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
index fdb0dab..b4602fa 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,87 @@
 
 #ifndef __ASSEMBLY__
 
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+
+#define __DECL_REG(n64, n32) union {            \
+    uint64_t n64;                               \
+    uint32_t n32;                               \
+}
+
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0/*_usr*/);
+    __DECL_REG(x1,           r1/*_usr*/);
+    __DECL_REG(x2,           r2/*_usr*/);
+    __DECL_REG(x3,           r3/*_usr*/);
+    __DECL_REG(x4,           r4/*_usr*/);
+    __DECL_REG(x5,           r5/*_usr*/);
+    __DECL_REG(x6,           r6/*_usr*/);
+    __DECL_REG(x7,           r7/*_usr*/);
+    __DECL_REG(x8,           r8/*_usr*/);
+    __DECL_REG(x9,           r9/*_usr*/);
+    __DECL_REG(x10,          r10/*_usr*/);
+    __DECL_REG(x11 ,         r11/*_usr*/);
+    __DECL_REG(x12,          r12/*_usr*/);
+
+    __DECL_REG(x13,          /* r13_usr */ sp_usr);
+    __DECL_REG(x14,          /* r14_usr */ lr_usr);
+
+    __DECL_REG(x15,          /* r13_hyp */ __unused_sp_hyp);
+
+    __DECL_REG(x16,          /* r14_irq */ lr_irq);
+    __DECL_REG(x17,          /* r13_irq */ sp_irq);
+
+    __DECL_REG(x18,          /* r14_svc */ lr_svc);
+    __DECL_REG(x19,          /* r13_svc */ sp_svc);
+
+    __DECL_REG(x20,          /* r14_abt */ lr_abt);
+    __DECL_REG(x21,          /* r13_abt */ sp_abt);
+
+    __DECL_REG(x22,          /* r14_und */ lr_und);
+    __DECL_REG(x23,          /* r13_und */ sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+    __DECL_REG(/* x29 */ fp, /* r13_fiq */ sp_fiq);
+    __DECL_REG(/* x30 */ lr, /* r14_fiq */ lr_fiq);
+
+    register_t sp; /* Valid for hypervisor frames */
+
+    /* Return address and mode */
+    __DECL_REG(pc,           pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
+
+    uint64_t pad0;
+
+    /* Outer guest frame only from here on... */
+
+    union {
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
+    };
+
+    uint32_t pad1; /* Align */
+
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
+
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
+
+    uint64_t pad2; /* Doubleword-align the user half of the frame */
+};
+
+#undef __DECL_REG
+
+/* Access to system registers */
+
 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
     asm volatile("mrs  %0, "#name : "=r" (_r));         \
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index d20d7a8..c9c8ac7 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -6,6 +6,7 @@
 #include <public/xen.h>
 
 #include <asm/percpu.h>
+#include <asm/processor.h>
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 8183d36..230c901 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,11 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs);
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_H */
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index dc12524..91f80d8 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -86,55 +86,80 @@
 #endif
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-struct cpu_user_regs
-{
-    uint32_t r0;
-    uint32_t r1;
-    uint32_t r2;
-    uint32_t r3;
-    uint32_t r4;
-    uint32_t r5;
-    uint32_t r6;
-    uint32_t r7;
-    uint32_t r8;
-    uint32_t r9;
-    uint32_t r10;
-    union {
-        uint32_t r11;
-        uint32_t fp;
-    };
-    uint32_t r12;
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+# define __DECL_REG(n64, n32) union {          \
+        uint64_t n64;                          \
+        uint32_t n32;                          \
+    }
+#else
+/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
+#define __DECL_REG(n64, n32) uint64_t n64
+#endif
 
-    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+struct vcpu_guest_core_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0_usr);
+    __DECL_REG(x1,           r1_usr);
+    __DECL_REG(x2,           r2_usr);
+    __DECL_REG(x3,           r3_usr);
+    __DECL_REG(x4,           r4_usr);
+    __DECL_REG(x5,           r5_usr);
+    __DECL_REG(x6,           r6_usr);
+    __DECL_REG(x7,           r7_usr);
+    __DECL_REG(x8,           r8_usr);
+    __DECL_REG(x9,           r9_usr);
+    __DECL_REG(x10,          r10_usr);
+    __DECL_REG(x11,          r11_usr);
+    __DECL_REG(x12,          r12_usr);
+
+    __DECL_REG(x13,          sp_usr);
+    __DECL_REG(x14,          lr_usr);
+
+    __DECL_REG(x15,          __unused_sp_hyp);
+
+    __DECL_REG(x16,          lr_irq);
+    __DECL_REG(x17,          sp_irq);
+
+    __DECL_REG(x18,          lr_svc);
+    __DECL_REG(x19,          sp_svc);
+
+    __DECL_REG(x20,          lr_abt);
+    __DECL_REG(x21,          sp_abt);
+
+    __DECL_REG(x22,          lr_und);
+    __DECL_REG(x23,          sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+
+    __DECL_REG(x29,          sp_fiq);
+    __DECL_REG(x30,          lr_fiq);
+
+    /* Return address and mode */
+    __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
 
-    /* r14 - LR: is the same physical register as LR_usr */
     union {
-        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
-        uint32_t lr_usr;
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
     };
 
-    uint32_t pc; /* Return IP */
-    uint32_t cpsr; /* Return mode */
-    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
-
-    /* Outer guest frame only from here on... */
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
 
-    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
-
-    uint32_t sp_irq, lr_irq;
-    uint32_t sp_svc, lr_svc;
-    uint32_t sp_abt, lr_abt;
-    uint32_t sp_und, lr_und;
-
-    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
-    uint32_t sp_fiq, lr_fiq;
-
-    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
-
-    uint32_t pad1; /* Doubleword-align the user half of the frame */
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
 };
-typedef struct cpu_user_regs cpu_user_regs_t;
-DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+typedef struct vcpu_guest_core_regs vcpu_guest_core_regs_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
+
+#undef __DECL_REG
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
@@ -151,10 +176,10 @@ struct vcpu_guest_context {
 #define VGCF_online                    (1<<_VGCF_online)
     uint32_t flags;                         /* VGCF_* */
 
-    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    struct vcpu_guest_core_regs user_regs;  /* Core CPU registers */
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
1.7.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 Feb 14 17:03:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Df-0002ub-1P; Thu, 14 Feb 2013 17:03: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 1U62Dc-0002pz-IS
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:33 +0000
Received: from [85.158.137.99:50097] by server-3.bemta-3.messagelabs.com id
	41/9E-31070-3E81D115; Thu, 14 Feb 2013 17:03:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5100 invoked from network); 14 Feb 2013 17:03:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533074"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:18 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Lp;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:38 +0000
Message-ID: <1360860480-9245-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 24/46] xen: arm: separate guest user regs
	from internal guest 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

struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).

This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.

So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.

In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.

This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Allow 32-bit to see 64-bit register names too, this is needed so that
    32-bit toolstacks can access/control 64-bit guests.
---
 tools/include/xen-foreign/mkheader.py    |   10 +++
 tools/include/xen-foreign/reference.size |    5 +-
 tools/include/xen-foreign/structs.py     |    1 +
 tools/libxc/xc_dom_arm.c                 |   10 ++--
 xen/arch/arm/arm32/Makefile              |    2 +
 xen/arch/arm/arm32/domain.c              |   51 +++++++++++++
 xen/arch/arm/arm64/Makefile              |    2 +
 xen/arch/arm/arm64/domain.c              |   66 +++++++++++++++++
 xen/arch/arm/domain.c                    |    4 +-
 xen/arch/arm/domctl.c                    |    4 +-
 xen/include/asm-arm/arm32/processor.h    |   52 +++++++++++++
 xen/include/asm-arm/arm64/processor.h    |   81 +++++++++++++++++++++
 xen/include/asm-arm/current.h            |    1 +
 xen/include/asm-arm/processor.h          |    5 ++
 xen/include/public/arch-arm.h            |  115 ++++++++++++++++++------------
 15 files changed, 353 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain.c
 create mode 100644 xen/arch/arm/arm64/domain.c

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 4858687..c57b55b 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -25,6 +25,11 @@ inttypes["arm32"] = {
 };
 header["arm32"] = """
 #define __arm___ARM32 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
 footer["arm32"] = """
 #undef __DECL_REG
@@ -38,6 +43,11 @@ inttypes["arm64"] = {
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
 footer["arm64"] = """
 #undef __DECL_REG
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 7659c64..b3347b4 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -3,8 +3,9 @@ structs                   |   arm32   arm64  x86_32  x86_64
 
 start_info                |       -       -    1112    1168
 trap_info                 |       -       -       8      16
-cpu_user_regs             |     160     160      68     200
-vcpu_guest_context        |     180     180    2800    5168
+cpu_user_regs             |       -       -      68     200
+vcpu_guest_core_regs      |     304     304       -       -
+vcpu_guest_context        |     336     336    2800    5168
 arch_vcpu_info            |       0       0      24      16
 vcpu_time_info            |      32      32      32      32
 vcpu_info                 |      48      48      64      64
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 5aec2c5..0b33a77 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -6,6 +6,7 @@ unions  = [ "vcpu_cr_regs",
 structs = [ "start_info",
             "trap_info",
             "cpu_user_regs",
+            "vcpu_guest_core_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 0cec774..e46cec9 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -107,17 +107,17 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     /* clear everything */
     memset(ctxt, 0, sizeof(*ctxt));
 
-    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.pc32 = dom->parms.virt_entry;
 
     /* Linux boot protocol. See linux.Documentation/arm/Booting. */
-    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r0_usr = 0; /* SBZ */
     /* Machine ID: We use DTB therefore no machine id */
-    ctxt->user_regs.r1 = 0xffffffff;
+    ctxt->user_regs.r1_usr = 0xffffffff;
     /* ATAGS/DTB: We currently require that the guest kernel to be
      * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look
      * like a valid pointer to a set of ATAGS or a DTB.
      */
-    ctxt->user_regs.r2 = 0xffffffff;
+    ctxt->user_regs.r2_usr = 0xffffffff;
 
     ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
 
@@ -130,7 +130,7 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     ctxt->flags = VGCF_online;
 
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
-           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
     return 0;
 }
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 20931fa..29898ae 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -3,3 +3,5 @@ subdir-y += lib
 obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm32/domain.c b/xen/arch/arm/arm32/domain.c
new file mode 100644
index 0000000..f75a2c6
--- /dev/null
+++ b/xen/arch/arm/arm32/domain.c
@@ -0,0 +1,51 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(r0,r0_usr);   C(r1,r1_usr);   C(r2,r2_usr);   C(r3,r3_usr);   \
+    C(r4,r4_usr);   C(r5,r5_usr);   C(r6,r6_usr);   C(r7,r7_usr);   \
+    C(r8,r8_usr);   C(r9,r9_usr);   C(r10,r10_usr); C(r11,r11_usr); \
+    C(r12,r12_usr); \
+    C(sp_usr,sp_usr); \
+    C(lr,lr_usr); \
+    C(spsr_irq,spsr_irq); C(lr_irq,lr_irq); C(sp_irq,sp_irq); \
+    C(spsr_svc,spsr_svc); C(lr_svc,lr_svc); C(sp_svc,sp_svc); \
+    C(spsr_abt,spsr_abt); C(lr_abt,lr_abt); C(sp_abt,sp_abt); \
+    C(spsr_und,spsr_und); C(lr_und,lr_und); C(sp_und,sp_und); \
+    C(spsr_fiq,spsr_fiq); C(sp_fiq,sp_fiq); C(sp_fiq,sp_fiq); \
+    C(r8_fiq,r8_fiq); C(r9_fiq,r9_fiq); \
+    C(r10_fiq,r10_fiq); C(r11_fiq,r11_fiq); C(r12_fiq,r12_fiq); \
+    C(pc,pc32); \
+    C(cpsr,cpsr)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c447eaa..815f305 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,3 +1,5 @@
 subdir-y += lib
 
 obj-y += mode_switch.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm64/domain.c b/xen/arch/arm/arm64/domain.c
new file mode 100644
index 0000000..05df29e
--- /dev/null
+++ b/xen/arch/arm/arm64/domain.c
@@ -0,0 +1,66 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(x0,x0);   C(x1,x1);   C(x2,x2);   C(x3,x3);   \
+    C(x4,x4);   C(x5,x5);   C(x6,x6);   C(x7,x7);   \
+    C(x8,x8);   C(x9,x9);   C(x10,x10); C(x11,x11); \
+    C(x12,x12); C(x13,x13); C(x14,x14); C(x15,x15); \
+    C(x16,x16); C(x17,x17); C(x18,x18); C(x19,x19); \
+    C(x20,x20); C(x21,x21); C(x22,x22); C(x23,x23); \
+    C(x24,x24); C(x25,x25); C(x26,x26); C(x27,x27); \
+    C(x28,x28); C(fp,x29);  C(lr,x30);  C(pc,pc64); \
+    C(cpsr, cpsr); C(spsr_el1, spsr_el1)
+
+#define ALLREGS32 C(spsr_fiq, spsr_fiq); C(spsr_irq,spsr_irq); \
+                  C(spsr_und,spsr_und); C(spsr_abt,spsr_abt)
+
+#define ALLREGS64 C(sp_el0,sp_el0); C(sp_el1,sp_el1); C(elr_el1,elr_el1)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e7d3ec6..3651fb2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,7 +486,7 @@ int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
     if ( !is_guest_psr(regs->cpsr) )
         return -EINVAL;
@@ -502,7 +502,7 @@ int arch_set_info_guest(
     if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
         return -EINVAL;
 
-    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+    vcpu_regs_user_to_hyp(v, regs);
 
     v->arch.sctlr = ctxt->sctlr;
     v->arch.ttbr0 = ctxt->ttbr0;
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index c7ffd8a..15f8537 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -20,9 +20,9 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
-    *regs = v->arch.cpu_info->guest_cpu_user_regs;
+    vcpu_regs_hyp_to_user(v, regs);
 
     ctxt->sctlr = v->arch.sctlr;
     ctxt->ttbr0 = v->arch.ttbr0;
diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
index 843fbd2..a782d96 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,58 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#ifndef __ASSEMBLY__
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+        uint32_t r11;
+        uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+        uint32_t lr_usr;
+    };
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_irq, lr_irq;
+    uint32_t sp_svc, lr_svc;
+    uint32_t sp_abt, lr_abt;
+    uint32_t sp_und, lr_und;
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+    uint32_t sp_fiq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
+};
+#endif
+
 /* Layout as used in assembly, with src/dest registers mixed in */
 #define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
 #define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
index fdb0dab..b4602fa 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,87 @@
 
 #ifndef __ASSEMBLY__
 
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+
+#define __DECL_REG(n64, n32) union {            \
+    uint64_t n64;                               \
+    uint32_t n32;                               \
+}
+
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0/*_usr*/);
+    __DECL_REG(x1,           r1/*_usr*/);
+    __DECL_REG(x2,           r2/*_usr*/);
+    __DECL_REG(x3,           r3/*_usr*/);
+    __DECL_REG(x4,           r4/*_usr*/);
+    __DECL_REG(x5,           r5/*_usr*/);
+    __DECL_REG(x6,           r6/*_usr*/);
+    __DECL_REG(x7,           r7/*_usr*/);
+    __DECL_REG(x8,           r8/*_usr*/);
+    __DECL_REG(x9,           r9/*_usr*/);
+    __DECL_REG(x10,          r10/*_usr*/);
+    __DECL_REG(x11 ,         r11/*_usr*/);
+    __DECL_REG(x12,          r12/*_usr*/);
+
+    __DECL_REG(x13,          /* r13_usr */ sp_usr);
+    __DECL_REG(x14,          /* r14_usr */ lr_usr);
+
+    __DECL_REG(x15,          /* r13_hyp */ __unused_sp_hyp);
+
+    __DECL_REG(x16,          /* r14_irq */ lr_irq);
+    __DECL_REG(x17,          /* r13_irq */ sp_irq);
+
+    __DECL_REG(x18,          /* r14_svc */ lr_svc);
+    __DECL_REG(x19,          /* r13_svc */ sp_svc);
+
+    __DECL_REG(x20,          /* r14_abt */ lr_abt);
+    __DECL_REG(x21,          /* r13_abt */ sp_abt);
+
+    __DECL_REG(x22,          /* r14_und */ lr_und);
+    __DECL_REG(x23,          /* r13_und */ sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+    __DECL_REG(/* x29 */ fp, /* r13_fiq */ sp_fiq);
+    __DECL_REG(/* x30 */ lr, /* r14_fiq */ lr_fiq);
+
+    register_t sp; /* Valid for hypervisor frames */
+
+    /* Return address and mode */
+    __DECL_REG(pc,           pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
+
+    uint64_t pad0;
+
+    /* Outer guest frame only from here on... */
+
+    union {
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
+    };
+
+    uint32_t pad1; /* Align */
+
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
+
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
+
+    uint64_t pad2; /* Doubleword-align the user half of the frame */
+};
+
+#undef __DECL_REG
+
+/* Access to system registers */
+
 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
     asm volatile("mrs  %0, "#name : "=r" (_r));         \
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index d20d7a8..c9c8ac7 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -6,6 +6,7 @@
 #include <public/xen.h>
 
 #include <asm/percpu.h>
+#include <asm/processor.h>
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 8183d36..230c901 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,11 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs);
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_H */
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index dc12524..91f80d8 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -86,55 +86,80 @@
 #endif
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-struct cpu_user_regs
-{
-    uint32_t r0;
-    uint32_t r1;
-    uint32_t r2;
-    uint32_t r3;
-    uint32_t r4;
-    uint32_t r5;
-    uint32_t r6;
-    uint32_t r7;
-    uint32_t r8;
-    uint32_t r9;
-    uint32_t r10;
-    union {
-        uint32_t r11;
-        uint32_t fp;
-    };
-    uint32_t r12;
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+# define __DECL_REG(n64, n32) union {          \
+        uint64_t n64;                          \
+        uint32_t n32;                          \
+    }
+#else
+/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
+#define __DECL_REG(n64, n32) uint64_t n64
+#endif
 
-    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+struct vcpu_guest_core_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0_usr);
+    __DECL_REG(x1,           r1_usr);
+    __DECL_REG(x2,           r2_usr);
+    __DECL_REG(x3,           r3_usr);
+    __DECL_REG(x4,           r4_usr);
+    __DECL_REG(x5,           r5_usr);
+    __DECL_REG(x6,           r6_usr);
+    __DECL_REG(x7,           r7_usr);
+    __DECL_REG(x8,           r8_usr);
+    __DECL_REG(x9,           r9_usr);
+    __DECL_REG(x10,          r10_usr);
+    __DECL_REG(x11,          r11_usr);
+    __DECL_REG(x12,          r12_usr);
+
+    __DECL_REG(x13,          sp_usr);
+    __DECL_REG(x14,          lr_usr);
+
+    __DECL_REG(x15,          __unused_sp_hyp);
+
+    __DECL_REG(x16,          lr_irq);
+    __DECL_REG(x17,          sp_irq);
+
+    __DECL_REG(x18,          lr_svc);
+    __DECL_REG(x19,          sp_svc);
+
+    __DECL_REG(x20,          lr_abt);
+    __DECL_REG(x21,          sp_abt);
+
+    __DECL_REG(x22,          lr_und);
+    __DECL_REG(x23,          sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+
+    __DECL_REG(x29,          sp_fiq);
+    __DECL_REG(x30,          lr_fiq);
+
+    /* Return address and mode */
+    __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
 
-    /* r14 - LR: is the same physical register as LR_usr */
     union {
-        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
-        uint32_t lr_usr;
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
     };
 
-    uint32_t pc; /* Return IP */
-    uint32_t cpsr; /* Return mode */
-    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
-
-    /* Outer guest frame only from here on... */
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
 
-    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
-
-    uint32_t sp_irq, lr_irq;
-    uint32_t sp_svc, lr_svc;
-    uint32_t sp_abt, lr_abt;
-    uint32_t sp_und, lr_und;
-
-    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
-    uint32_t sp_fiq, lr_fiq;
-
-    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
-
-    uint32_t pad1; /* Doubleword-align the user half of the frame */
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
 };
-typedef struct cpu_user_regs cpu_user_regs_t;
-DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+typedef struct vcpu_guest_core_regs vcpu_guest_core_regs_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
+
+#undef __DECL_REG
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
@@ -151,10 +176,10 @@ struct vcpu_guest_context {
 #define VGCF_online                    (1<<_VGCF_online)
     uint32_t flags;                         /* VGCF_* */
 
-    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    struct vcpu_guest_core_regs user_regs;  /* Core CPU registers */
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
1.7.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 Feb 14 17:03:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Df-0002vR-IX; Thu, 14 Feb 2013 17:03:35 +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 1U62Dd-0002re-MA
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:33 +0000
Received: from [85.158.137.99:50185] by server-8.bemta-3.messagelabs.com id
	4D/CC-25687-4E81D115; Thu, 14 Feb 2013 17:03:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5228 invoked from network); 14 Feb 2013 17:03:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533089"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:21 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1U62DR-0001IC-9L;
	Thu, 14 Feb 2013 17:03:21 +0000
Message-ID: <511D18D8.10605@citrix.com>
Date: Thu, 14 Feb 2013 17:03:20 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: Sander Bogaert <sander.bogaert@elis.ugent.be>
References: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
In-Reply-To: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/13 15:09, Sander Bogaert wrote:
> Hi,
> 
> I'm trying to get Xen working on the Arndale Board

Hi, thanks for trying :).

> using these
> instructions:
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale

Sorry, this wiki page is probably not complete yet.

> When trying to build the Linux kernel from Linaro,
> http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
> (
> configured as specified on the Xen wiki page ) I run into the following
> error while compiling:
> 
> *drivers/xen/xenbus/xenbus_client.c: In function
> 'xenbus_map_ring_valloc_hvm':*
> *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of
> function 'page_to_section' [-Werror=implicit-function-declaration]*
> *cc1: some warnings being treated as errors*
> *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*
>
> I was wondering if anyone else ran into this and if so how best to solve it.

Yes, I've got a patch for it:
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..686142d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -35,6 +35,7 @@
 #include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
+#include <linux/mm.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>


> Booting Xen on the board hangs on "Turning on paging", is this related to
> not having a dom0?

Should not be, there is many things printed by Xen before it is trying
to boot dom0, and it would say that it can not find a dom0.

> *...*
> *Startinrrrrrrrrrrrrrrrr- UART enabled -*
> *- CPU 00000000 booting -*
> *- Started in Hyp mode -*
> *- Zero BSS -*
> *- Setting up control registers -*
> *- Turning on paging -*

All right, I've been able to reproduce the behaviour. Are you starting
Xen using the u-boot command "go"? Because this does not work with me.
It gave me some headache sometime ago. The command that works is "bootm
$xen_addr -"
So, I'm curious, how do you start Xen on the board?

Here is what env I have on u-boot:
ipaddr=10.y.y.y
ipconfig=10.y.y.y
kernel_addr_r=0x40007000
serverip=10.x.x.x
tftp_path=10.x.x.x:pxelinux.cfg
usbethaddr=00:40:5c:26:0a:5b
ethaddr=00:40:5c:26:0a:5b
xen_addr_r=0x50000000
bootcmd_load_linux=tftpboot 0x40007000 10.80.3.61:pxelinux.cfg/linux-zImage
boot_xen=run bootcmd_load_linux; tftpboot $xen_addr_r
$tftp_path/xen-uImage; bootm $xen_addr_r -
bootcmd=run boot_xen

with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp
server (or PXE server).

By the way, I've pushed a new branch: arndale-2013-02-13 which fix few
things.

This should make you pass the "turning on paging" step.

After that, you will probably need few patches for Linux. I'll push them
later.

Have fun,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:03:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Df-0002vR-IX; Thu, 14 Feb 2013 17:03:35 +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 1U62Dd-0002re-MA
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:33 +0000
Received: from [85.158.137.99:50185] by server-8.bemta-3.messagelabs.com id
	4D/CC-25687-4E81D115; Thu, 14 Feb 2013 17:03:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5228 invoked from network); 14 Feb 2013 17:03:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533089"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:21 -0500
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1U62DR-0001IC-9L;
	Thu, 14 Feb 2013 17:03:21 +0000
Message-ID: <511D18D8.10605@citrix.com>
Date: Thu, 14 Feb 2013 17:03:20 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130109 Thunderbird/17.0.2
MIME-Version: 1.0
To: Sander Bogaert <sander.bogaert@elis.ugent.be>
References: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
In-Reply-To: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/13 15:09, Sander Bogaert wrote:
> Hi,
> 
> I'm trying to get Xen working on the Arndale Board

Hi, thanks for trying :).

> using these
> instructions:
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale

Sorry, this wiki page is probably not complete yet.

> When trying to build the Linux kernel from Linaro,
> http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
> (
> configured as specified on the Xen wiki page ) I run into the following
> error while compiling:
> 
> *drivers/xen/xenbus/xenbus_client.c: In function
> 'xenbus_map_ring_valloc_hvm':*
> *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of
> function 'page_to_section' [-Werror=implicit-function-declaration]*
> *cc1: some warnings being treated as errors*
> *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*
>
> I was wondering if anyone else ran into this and if so how best to solve it.

Yes, I've got a patch for it:
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..686142d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -35,6 +35,7 @@
 #include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
+#include <linux/mm.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>


> Booting Xen on the board hangs on "Turning on paging", is this related to
> not having a dom0?

Should not be, there is many things printed by Xen before it is trying
to boot dom0, and it would say that it can not find a dom0.

> *...*
> *Startinrrrrrrrrrrrrrrrr- UART enabled -*
> *- CPU 00000000 booting -*
> *- Started in Hyp mode -*
> *- Zero BSS -*
> *- Setting up control registers -*
> *- Turning on paging -*

All right, I've been able to reproduce the behaviour. Are you starting
Xen using the u-boot command "go"? Because this does not work with me.
It gave me some headache sometime ago. The command that works is "bootm
$xen_addr -"
So, I'm curious, how do you start Xen on the board?

Here is what env I have on u-boot:
ipaddr=10.y.y.y
ipconfig=10.y.y.y
kernel_addr_r=0x40007000
serverip=10.x.x.x
tftp_path=10.x.x.x:pxelinux.cfg
usbethaddr=00:40:5c:26:0a:5b
ethaddr=00:40:5c:26:0a:5b
xen_addr_r=0x50000000
bootcmd_load_linux=tftpboot 0x40007000 10.80.3.61:pxelinux.cfg/linux-zImage
boot_xen=run bootcmd_load_linux; tftpboot $xen_addr_r
$tftp_path/xen-uImage; bootm $xen_addr_r -
bootcmd=run boot_xen

with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp
server (or PXE server).

By the way, I've pushed a new branch: arndale-2013-02-13 which fix few
things.

This should make you pass the "turning on paging" step.

After that, you will probably need few patches for Linux. I'll push them
later.

Have fun,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:03:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Dg-0002xQ-Hr; Thu, 14 Feb 2013 17:03: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 1U62De-0002mi-NJ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:34 +0000
Received: from [85.158.137.99:4028] by server-12.bemta-3.messagelabs.com id
	BC/E1-05889-6E81D115; Thu, 14 Feb 2013 17:03:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5342 invoked from network); 14 Feb 2013 17:03:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533105"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:23 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-7u;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:56 +0000
Message-ID: <1360860480-9245-42-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 42/46] xen: arm: Use generic mem{cpy, move,
	set, zero} on 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 optimised versions are available in Linux yet (meaning I couldn't
copy them).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/string.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
index f2d643d..e5d1e7e 100644
--- a/xen/include/asm-arm/string.h
+++ b/xen/include/asm-arm/string.h
@@ -3,6 +3,7 @@
 
 #include <xen/config.h>
 
+#if defined(CONFIG_ARM_32)
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);
 
@@ -27,6 +28,8 @@ extern void __memzero(void *ptr, __kernel_size_t n);
                 (__p);                                                  \
         })
 
+#endif
+
 #endif /* __ARM_STRING_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 14 17:03:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Dg-0002xQ-Hr; Thu, 14 Feb 2013 17:03: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 1U62De-0002mi-NJ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:34 +0000
Received: from [85.158.137.99:4028] by server-12.bemta-3.messagelabs.com id
	BC/E1-05889-6E81D115; Thu, 14 Feb 2013 17:03:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360861399!16709308!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5342 invoked from network); 14 Feb 2013 17:03:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:03:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533105"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:23 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-7u;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:56 +0000
Message-ID: <1360860480-9245-42-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 42/46] xen: arm: Use generic mem{cpy, move,
	set, zero} on 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 optimised versions are available in Linux yet (meaning I couldn't
copy them).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/string.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
index f2d643d..e5d1e7e 100644
--- a/xen/include/asm-arm/string.h
+++ b/xen/include/asm-arm/string.h
@@ -3,6 +3,7 @@
 
 #include <xen/config.h>
 
+#if defined(CONFIG_ARM_32)
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);
 
@@ -27,6 +28,8 @@ extern void __memzero(void *ptr, __kernel_size_t n);
                 (__p);                                                  \
         })
 
+#endif
+
 #endif /* __ARM_STRING_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 14 17:03:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Dh-0002zq-JA; Thu, 14 Feb 2013 17:03:37 +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 1U62Df-0002uP-Dn
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:35 +0000
Received: from [85.158.139.83:5826] by server-16.bemta-5.messagelabs.com id
	DA/6E-14948-6E81D115; Thu, 14 Feb 2013 17:03:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23304 invoked from network); 14 Feb 2013 17:03:33 -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;
	14 Feb 2013 17:03:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163352"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-MK;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:39 +0000
Message-ID: <1360860480-9245-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 25/46] xen: arm64: add guest type to domain
	field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 32 bit PV is the only option.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
v2: Remove nested CONFIG_ARM_64
---
 xen/arch/arm/kernel.c        |    4 ++++
 xen/arch/arm/kernel.h        |    4 ++++
 xen/include/asm-arm/domain.h |   16 ++++++++++++++++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index c08c230..0c7da54 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -228,6 +228,10 @@ int kernel_prepare(struct kernel_info *info)
     if (rc < 0)
         rc = kernel_try_elf_prepare(info, start, size);
 
+#ifdef CONFIG_ARM_64
+    info->type = DOMAIN_PV32; /* No 64-bit guest support yet */
+#endif
+
     return rc;
 }
 
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 49fe9da..7232d34 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -10,6 +10,10 @@
 #include <xen/device_tree.h>
 
 struct kernel_info {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
     struct dt_mem_info mem;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 29fe808..e9370a5 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -35,8 +35,24 @@ struct hvm_domain
     uint64_t              params[HVM_NR_PARAMS];
 }  __cacheline_aligned;
 
+#ifdef CONFIG_ARM_64
+enum domain_type {
+    DOMAIN_PV32,
+    DOMAIN_PV64,
+};
+#define is_pv32_domain(d) ((d)->arch.type == DOMAIN_PV32)
+#define is_pv64_domain(d) ((d)->arch.type == DOMAIN_PV64)
+#else
+#define is_pv32_domain(d) (1)
+#define is_pv64_domain(d) (0)
+#endif
+
 struct arch_domain
 {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     struct p2m_domain p2m;
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
-- 
1.7.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 Feb 14 17:03:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Dh-0002zq-JA; Thu, 14 Feb 2013 17:03:37 +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 1U62Df-0002uP-Dn
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:35 +0000
Received: from [85.158.139.83:5826] by server-16.bemta-5.messagelabs.com id
	DA/6E-14948-6E81D115; Thu, 14 Feb 2013 17:03:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23304 invoked from network); 14 Feb 2013 17:03:33 -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;
	14 Feb 2013 17:03:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163352"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-MK;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:39 +0000
Message-ID: <1360860480-9245-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 25/46] xen: arm64: add guest type to domain
	field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 32 bit PV is the only option.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
v2: Remove nested CONFIG_ARM_64
---
 xen/arch/arm/kernel.c        |    4 ++++
 xen/arch/arm/kernel.h        |    4 ++++
 xen/include/asm-arm/domain.h |   16 ++++++++++++++++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index c08c230..0c7da54 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -228,6 +228,10 @@ int kernel_prepare(struct kernel_info *info)
     if (rc < 0)
         rc = kernel_try_elf_prepare(info, start, size);
 
+#ifdef CONFIG_ARM_64
+    info->type = DOMAIN_PV32; /* No 64-bit guest support yet */
+#endif
+
     return rc;
 }
 
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 49fe9da..7232d34 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -10,6 +10,10 @@
 #include <xen/device_tree.h>
 
 struct kernel_info {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
     struct dt_mem_info mem;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 29fe808..e9370a5 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -35,8 +35,24 @@ struct hvm_domain
     uint64_t              params[HVM_NR_PARAMS];
 }  __cacheline_aligned;
 
+#ifdef CONFIG_ARM_64
+enum domain_type {
+    DOMAIN_PV32,
+    DOMAIN_PV64,
+};
+#define is_pv32_domain(d) ((d)->arch.type == DOMAIN_PV32)
+#define is_pv64_domain(d) ((d)->arch.type == DOMAIN_PV64)
+#else
+#define is_pv32_domain(d) (1)
+#define is_pv64_domain(d) (0)
+#endif
+
 struct arch_domain
 {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     struct p2m_domain p2m;
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
-- 
1.7.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 Feb 14 17:03:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Dm-00038F-AY; Thu, 14 Feb 2013 17:03: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 1U62Dj-00033e-VJ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:40 +0000
Received: from [85.158.139.83:8152] by server-11.bemta-5.messagelabs.com id
	95/29-19159-BE81D115; Thu, 14 Feb 2013 17:03:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23488 invoked from network); 14 Feb 2013 17:03:38 -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;
	14 Feb 2013 17:03:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163362"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:37 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-2X;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:49 +0000
Message-ID: <1360860480-9245-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 35/46] xen: arm: p2m: use 64-bit compatible
	registers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/p2m.c           |    2 +-
 xen/include/asm-arm/cpregs.h |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 852f0d8..aaa43ef 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -29,7 +29,7 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    WRITE_CP64(vttbr, VTTBR);
+    WRITE_SYSREG64(vttbr, VTTBR_EL2);
     isb(); /* Ensure update is visible */
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index a374f5c..676c8cf 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -277,6 +277,7 @@
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
+#define VTTBR_EL2               VTTBR
 
 #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 Feb 14 17:03:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Dm-00038F-AY; Thu, 14 Feb 2013 17:03: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 1U62Dj-00033e-VJ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:40 +0000
Received: from [85.158.139.83:8152] by server-11.bemta-5.messagelabs.com id
	95/29-19159-BE81D115; Thu, 14 Feb 2013 17:03:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23488 invoked from network); 14 Feb 2013 17:03:38 -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;
	14 Feb 2013 17:03:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163362"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:37 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-2X;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:49 +0000
Message-ID: <1360860480-9245-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 35/46] xen: arm: p2m: use 64-bit compatible
	registers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/p2m.c           |    2 +-
 xen/include/asm-arm/cpregs.h |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 852f0d8..aaa43ef 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -29,7 +29,7 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    WRITE_CP64(vttbr, VTTBR);
+    WRITE_SYSREG64(vttbr, VTTBR_EL2);
     isb(); /* Ensure update is visible */
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index a374f5c..676c8cf 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -277,6 +277,7 @@
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
+#define VTTBR_EL2               VTTBR
 
 #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 Feb 14 17:03:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U62Dq-0003Ft-Rf; Thu, 14 Feb 2013 17:03: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 1U62Do-0003BY-PR
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:44 +0000
Received: from [85.158.139.83:8482] by server-1.bemta-5.messagelabs.com id
	FE/C3-29263-FE81D115; Thu, 14 Feb 2013 17:03:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23888 invoked from network); 14 Feb 2013 17:03: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;
	14 Feb 2013 17:03:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163386"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:42 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-3l;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:52 +0000
Message-ID: <1360860480-9245-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 38/46] xen: arm: handle 32-bit guest CP
	register traps on 64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b2b9327..1e64be1 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -700,16 +700,16 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to write to read-only register CLIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CLIDR);
+        *r = READ_SYSREG32(CLIDR_EL1);
         break;
     case HSR_CPREG32(CCSIDR):
         if ( !cp32.read )
         {
             dprintk(XENLOG_ERR,
-                    "attempt to write to read-only register CSSIDR\n");
+                    "attempt to write to read-only register CCSIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CCSIDR);
+        *r = READ_SYSREG32(CCSIDR_EL1);
         break;
     case HSR_CPREG32(DCCISW):
         if ( cp32.read )
@@ -718,7 +718,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to read from write-only register DCCISW\n");
             domain_crash_synchronous();
         }
+#ifdef CONFIG_ARM_32
         WRITE_CP32(*r, DCCISW);
+#else
+        asm volatile("dc cisw, %0;" : : "r" (*r) : "memory");
+#endif
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-- 
1.7.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 Feb 14 17:03:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 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 1U62Dq-0003Ft-Rf; Thu, 14 Feb 2013 17:03: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 1U62Do-0003BY-PR
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:44 +0000
Received: from [85.158.139.83:8482] by server-1.bemta-5.messagelabs.com id
	FE/C3-29263-FE81D115; Thu, 14 Feb 2013 17:03:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23888 invoked from network); 14 Feb 2013 17:03: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;
	14 Feb 2013 17:03:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163386"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:42 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-3l;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:52 +0000
Message-ID: <1360860480-9245-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 38/46] xen: arm: handle 32-bit guest CP
	register traps on 64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b2b9327..1e64be1 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -700,16 +700,16 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to write to read-only register CLIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CLIDR);
+        *r = READ_SYSREG32(CLIDR_EL1);
         break;
     case HSR_CPREG32(CCSIDR):
         if ( !cp32.read )
         {
             dprintk(XENLOG_ERR,
-                    "attempt to write to read-only register CSSIDR\n");
+                    "attempt to write to read-only register CCSIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CCSIDR);
+        *r = READ_SYSREG32(CCSIDR_EL1);
         break;
     case HSR_CPREG32(DCCISW):
         if ( cp32.read )
@@ -718,7 +718,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to read from write-only register DCCISW\n");
             domain_crash_synchronous();
         }
+#ifdef CONFIG_ARM_32
         WRITE_CP32(*r, DCCISW);
+#else
+        asm volatile("dc cisw, %0;" : : "r" (*r) : "memory");
+#endif
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-- 
1.7.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 Feb 14 17:03:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Dv-0003Om-A6; Thu, 14 Feb 2013 17:03: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 1U62Dt-0003Kt-QC
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:50 +0000
Received: from [85.158.139.83:8865] by server-12.bemta-5.messagelabs.com id
	E4/18-20195-5F81D115; Thu, 14 Feb 2013 17:03:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24084 invoked from network); 14 Feb 2013 17:03:48 -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;
	14 Feb 2013 17:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163413"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:46 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-He;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:34 +0000
Message-ID: <1360860480-9245-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 20/46] xen: arm64: add to foreign struct
	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>
Content-Type: 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>
---
 .gitignore                               |    1 +
 tools/include/xen-foreign/Makefile       |    5 ++++-
 tools/include/xen-foreign/mkheader.py    |   19 +++++++++++++++++++
 tools/include/xen-foreign/reference.size |   20 ++++++++++----------
 tools/include/xen-foreign/structs.py     |    1 +
 5 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 73c5b77..2242344 100644
--- a/.gitignore
+++ b/.gitignore
@@ -364,6 +364,7 @@ tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
 tools/include/xen-foreign/arm32.h
+tools/include/xen-foreign/arm64.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 53cc6b4..06b844c 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm32 x86_32 x86_64
+architectures := arm32 arm64 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -25,6 +25,9 @@ check-headers: checker
 arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
+arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index b7c34b1..4858687 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -26,6 +26,22 @@ inttypes["arm32"] = {
 header["arm32"] = """
 #define __arm___ARM32 1
 """;
+footer["arm32"] = """
+#undef __DECL_REG
+"""
+
+inttypes["arm64"] = {
+    "unsigned long" : "__danger_unsigned_long_on_arm64",
+    "long"          : "__danger_long_on_arm64",
+    "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
+};
+header["arm64"] = """
+#define __aarch64___ARM64 1
+""";
+footer["arm64"] = """
+#undef __DECL_REG
+"""
 
 # x86_32
 inttypes["x86_32"] = {
@@ -59,6 +75,9 @@ header["x86_64"] = """
 #endif
 #define __x86_64___X86_64 1
 """;
+footer["x86_64"] = """
+#undef __DECL_REG
+"""
 
 ###########################################################################
 # main
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 0e5529d..7659c64 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,13 @@
 
-structs                   |   arm32  x86_32  x86_64
+structs                   |   arm32   arm64  x86_32  x86_64
 
-start_info                |       -    1112    1168
-trap_info                 |       -       8      16
-cpu_user_regs             |     160      68     200
-vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       0      24      16
-vcpu_time_info            |      32      32      32
-vcpu_info                 |      48      64      64
-arch_shared_info          |       0     268     280
-shared_info               |    1088    2584    3368
+start_info                |       -       -    1112    1168
+trap_info                 |       -       -       8      16
+cpu_user_regs             |     160     160      68     200
+vcpu_guest_context        |     180     180    2800    5168
+arch_vcpu_info            |       0       0      24      16
+vcpu_time_info            |      32      32      32      32
+vcpu_info                 |      48      48      64      64
+arch_shared_info          |       0       0     268     280
+shared_info               |    1088    1088    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 51a77c0..5aec2c5 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -14,6 +14,7 @@ structs = [ "start_info",
             "shared_info" ];
 
 defines = [ "__arm__",
+            "__aarch64__",
             "__i386__",
             "__x86_64__",
 
-- 
1.7.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 Feb 14 17:03:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:03: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 1U62Dv-0003Om-A6; Thu, 14 Feb 2013 17:03: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 1U62Dt-0003Kt-QC
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:50 +0000
Received: from [85.158.139.83:8865] by server-12.bemta-5.messagelabs.com id
	E4/18-20195-5F81D115; Thu, 14 Feb 2013 17:03:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24084 invoked from network); 14 Feb 2013 17:03:48 -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;
	14 Feb 2013 17:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163413"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:46 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-He;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:34 +0000
Message-ID: <1360860480-9245-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 20/46] xen: arm64: add to foreign struct
	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>
Content-Type: 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>
---
 .gitignore                               |    1 +
 tools/include/xen-foreign/Makefile       |    5 ++++-
 tools/include/xen-foreign/mkheader.py    |   19 +++++++++++++++++++
 tools/include/xen-foreign/reference.size |   20 ++++++++++----------
 tools/include/xen-foreign/structs.py     |    1 +
 5 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 73c5b77..2242344 100644
--- a/.gitignore
+++ b/.gitignore
@@ -364,6 +364,7 @@ tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
 tools/include/xen-foreign/arm32.h
+tools/include/xen-foreign/arm64.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 53cc6b4..06b844c 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm32 x86_32 x86_64
+architectures := arm32 arm64 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -25,6 +25,9 @@ check-headers: checker
 arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
+arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index b7c34b1..4858687 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -26,6 +26,22 @@ inttypes["arm32"] = {
 header["arm32"] = """
 #define __arm___ARM32 1
 """;
+footer["arm32"] = """
+#undef __DECL_REG
+"""
+
+inttypes["arm64"] = {
+    "unsigned long" : "__danger_unsigned_long_on_arm64",
+    "long"          : "__danger_long_on_arm64",
+    "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
+};
+header["arm64"] = """
+#define __aarch64___ARM64 1
+""";
+footer["arm64"] = """
+#undef __DECL_REG
+"""
 
 # x86_32
 inttypes["x86_32"] = {
@@ -59,6 +75,9 @@ header["x86_64"] = """
 #endif
 #define __x86_64___X86_64 1
 """;
+footer["x86_64"] = """
+#undef __DECL_REG
+"""
 
 ###########################################################################
 # main
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 0e5529d..7659c64 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,13 @@
 
-structs                   |   arm32  x86_32  x86_64
+structs                   |   arm32   arm64  x86_32  x86_64
 
-start_info                |       -    1112    1168
-trap_info                 |       -       8      16
-cpu_user_regs             |     160      68     200
-vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       0      24      16
-vcpu_time_info            |      32      32      32
-vcpu_info                 |      48      64      64
-arch_shared_info          |       0     268     280
-shared_info               |    1088    2584    3368
+start_info                |       -       -    1112    1168
+trap_info                 |       -       -       8      16
+cpu_user_regs             |     160     160      68     200
+vcpu_guest_context        |     180     180    2800    5168
+arch_vcpu_info            |       0       0      24      16
+vcpu_time_info            |      32      32      32      32
+vcpu_info                 |      48      48      64      64
+arch_shared_info          |       0       0     268     280
+shared_info               |    1088    1088    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 51a77c0..5aec2c5 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -14,6 +14,7 @@ structs = [ "start_info",
             "shared_info" ];
 
 defines = [ "__arm__",
+            "__aarch64__",
             "__i386__",
             "__x86_64__",
 
-- 
1.7.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 Feb 14 17:03:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Dz-0003XZ-IR; Thu, 14 Feb 2013 17:03: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 1U62Dx-0003TO-VQ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:54 +0000
Received: from [85.158.139.83:9151] by server-2.bemta-5.messagelabs.com id
	18/53-16911-9F81D115; Thu, 14 Feb 2013 17:03:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24577 invoked from network); 14 Feb 2013 17:03:52 -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;
	14 Feb 2013 17:03:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163431"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-5m;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:54 +0000
Message-ID: <1360860480-9245-40-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 40/46] xen: arm: implement do_multicall_call
	for both 32 and 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Obviously nothing is actually making multicalls even on 32-bit so
this isn't tested.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   22 ++++++++++++++++++++++
 xen/include/asm-arm/multicall.h |   11 +----------
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e00fef0..5f9c785 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -675,6 +675,28 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 #endif
 }
 
+void do_multicall_call(struct multicall_entry *multi)
+{
+    arm_hypercall_fn_t call = NULL;
+
+    if ( multi->op >= ARRAY_SIZE(arm_hypercall_table) )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    call = arm_hypercall_table[multi->op].fn;
+    if ( call == NULL )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    multi->result = call(multi->args[0], multi->args[1],
+                        multi->args[2], multi->args[3],
+                        multi->args[4]);
+}
+
 static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
index c800940..f717b51 100644
--- a/xen/include/asm-arm/multicall.h
+++ b/xen/include/asm-arm/multicall.h
@@ -1,16 +1,7 @@
 #ifndef __ASM_ARM_MULTICALL_H__
 #define __ASM_ARM_MULTICALL_H__
 
-#define do_multicall_call(_call)                             \
-    do {                                                     \
-        __asm__ __volatile__ (                               \
-            ".word 0xe7f000f0@; do_multicall_call\n"         \
-            "    mov r0,#0; @ do_multicall_call\n"           \
-            "    str r0, [r0];\n"                            \
-            :                                                \
-            :                                                \
-            : );                                             \
-    } while ( 0 )
+extern void do_multicall_call(struct multicall_entry *call);
 
 #endif /* __ASM_ARM_MULTICALL_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 Thu Feb 14 17:03:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Dz-0003XZ-IR; Thu, 14 Feb 2013 17:03: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 1U62Dx-0003TO-VQ
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:54 +0000
Received: from [85.158.139.83:9151] by server-2.bemta-5.messagelabs.com id
	18/53-16911-9F81D115; Thu, 14 Feb 2013 17:03:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24577 invoked from network); 14 Feb 2013 17:03:52 -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;
	14 Feb 2013 17:03:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163431"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-5m;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:54 +0000
Message-ID: <1360860480-9245-40-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 40/46] xen: arm: implement do_multicall_call
	for both 32 and 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Obviously nothing is actually making multicalls even on 32-bit so
this isn't tested.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   22 ++++++++++++++++++++++
 xen/include/asm-arm/multicall.h |   11 +----------
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e00fef0..5f9c785 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -675,6 +675,28 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 #endif
 }
 
+void do_multicall_call(struct multicall_entry *multi)
+{
+    arm_hypercall_fn_t call = NULL;
+
+    if ( multi->op >= ARRAY_SIZE(arm_hypercall_table) )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    call = arm_hypercall_table[multi->op].fn;
+    if ( call == NULL )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    multi->result = call(multi->args[0], multi->args[1],
+                        multi->args[2], multi->args[3],
+                        multi->args[4]);
+}
+
 static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
index c800940..f717b51 100644
--- a/xen/include/asm-arm/multicall.h
+++ b/xen/include/asm-arm/multicall.h
@@ -1,16 +1,7 @@
 #ifndef __ASM_ARM_MULTICALL_H__
 #define __ASM_ARM_MULTICALL_H__
 
-#define do_multicall_call(_call)                             \
-    do {                                                     \
-        __asm__ __volatile__ (                               \
-            ".word 0xe7f000f0@; do_multicall_call\n"         \
-            "    mov r0,#0; @ do_multicall_call\n"           \
-            "    str r0, [r0];\n"                            \
-            :                                                \
-            :                                                \
-            : );                                             \
-    } while ( 0 )
+extern void do_multicall_call(struct multicall_entry *call);
 
 #endif /* __ASM_ARM_MULTICALL_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 Thu Feb 14 17:04:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62E4-0003fc-1i; Thu, 14 Feb 2013 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.Campbell@citrix.com>) id 1U62E2-0003ci-Nz
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:59 +0000
Received: from [85.158.139.83:34563] by server-10.bemta-5.messagelabs.com id
	8B/1B-04697-DF81D115; Thu, 14 Feb 2013 17:03:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24895 invoked from network); 14 Feb 2013 17:03:56 -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;
	14 Feb 2013 17:03:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163444"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:55 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-NF;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:41 +0000
Message-ID: <1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
    restoring state.
---
 xen/arch/arm/arm64/Makefile      |    2 +
 xen/arch/arm/arm64/asm-offsets.c |   64 ++++++++++
 xen/arch/arm/arm64/entry.S       |  256 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/traps.c       |   56 ++++++++
 xen/arch/arm/io.h                |    2 +-
 xen/arch/arm/setup.c             |    2 +-
 xen/arch/arm/smpboot.c           |    2 +-
 xen/arch/arm/traps.c             |   17 ++-
 xen/include/asm-arm/cpregs.h     |    1 +
 xen/include/asm-arm/processor.h  |    2 +-
 10 files changed, 396 insertions(+), 8 deletions(-)
 create mode 100644 xen/arch/arm/arm64/asm-offsets.c
 create mode 100644 xen/arch/arm/arm64/entry.S
 create mode 100644 xen/arch/arm/arm64/traps.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 815f305..be41f43 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,5 +1,7 @@
 subdir-y += lib
 
+obj-y += entry.o
 obj-y += mode_switch.o
 
+obj-y += traps.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
new file mode 100644
index 0000000..691d6d5
--- /dev/null
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -0,0 +1,64 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_LR, struct cpu_user_regs, lr);
+
+   OFFSET(UREGS_SP, struct cpu_user_regs, sp);
+   OFFSET(UREGS_PC, struct cpu_user_regs, pc);
+   OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
+
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_el0, struct cpu_user_regs, sp_el0);
+   OFFSET(UREGS_SP_el1, struct cpu_user_regs, sp_el1);
+   OFFSET(UREGS_ELR_el1, struct cpu_user_regs, elr_el1);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
new file mode 100644
index 0000000..1b2c4ad
--- /dev/null
+++ b/xen/arch/arm/arm64/entry.S
@@ -0,0 +1,256 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+/*
+ * Register aliases.
+ */
+lr      .req    x30             // link register
+
+/*
+ * Stack pushing/popping (register pairs only). Equivalent to store decrement
+ * before, load increment after.
+ */
+        .macro  push, xreg1, xreg2
+        stp     \xreg1, \xreg2, [sp, #-16]!
+        .endm
+
+        .macro  pop, xreg1, xreg2
+        ldp     \xreg1, \xreg2, [sp], #16
+        .endm
+
+/*
+ * Save/restore guest mode specific state, outer stack frame
+ */
+        .macro  entry_guest, compat
+
+        add     x21, sp, #UREGS_SPSR_el1
+        mrs     x23, SPSR_EL1
+        str     x23, [x21]
+
+        .if \compat == 0 /* Aarch64 mode */
+
+        add     x21, sp, #UREGS_SP_el0
+        mrs     x22, SP_el0
+        str     x22, [x21]
+
+        add     x21, sp, #UREGS_ELR_el1
+        mrs     x22, SP_el1
+        mrs     x23, ELR_el1
+        stp     x22, x23, [x21]
+
+        .else             /* Aarch32 mode */
+
+        add     x21, sp, #UREGS_SPSR_fiq
+        mrs     x22, spsr_fiq
+        mrs     x23, spsr_irq
+        stp     w22, w23, [x21]
+
+        add     x21, sp, #UREGS_SPSR_und
+        mrs     x22, spsr_und
+        mrs     x23, spsr_abt
+        stp     w22, w23, [x21]
+
+        .endif
+
+        .endm
+
+/*
+ * Save state on entry to hypervisor
+ */
+        .macro  entry, hyp, compat
+        sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_SP)
+        push    x28, x29
+        push    x26, x27
+        push    x24, x25
+        push    x22, x23
+        push    x20, x21
+        push    x18, x19
+        push    x16, x17
+        push    x14, x15
+        push    x12, x13
+        push    x10, x11
+        push    x8, x9
+        push    x6, x7
+        push    x4, x5
+        push    x2, x3
+        push    x0, x1
+
+        .if \hyp == 1        /* Hypervisor mode */
+
+        add     x21, sp, #(UREGS_X0 - UREGS_SP)
+
+        .else                /* Guest mode */
+
+        entry_guest \compat
+        mov     x21, ~0 /* sp only valid for hyp frame XXX */
+
+        .endif
+
+        stp     lr, x21, [sp, #UREGS_LR]
+
+        mrs     x22, elr_el2
+        mrs     x23, spsr_el2
+        stp     x22, x23, [sp, #UREGS_PC]
+
+        .endm
+
+/*
+ * Bad Abort numbers
+ *-----------------
+ */
+#define BAD_SYNC        0
+#define BAD_IRQ         1
+#define BAD_FIQ         2
+#define BAD_ERROR       3
+
+        .macro  invalid, reason
+        mov     x0, sp
+        mov     x1, #\reason
+        b       do_bad_mode
+        .endm
+
+hyp_sync_invalid:
+        entry   hyp=1
+        invalid BAD_SYNC
+
+hyp_irq_invalid:
+        entry   hyp=1
+        invalid BAD_IRQ
+
+hyp_fiq_invalid:
+        entry   hyp=1
+        invalid BAD_FIQ
+
+hyp_error_invalid:
+        entry   hyp=1
+        invalid BAD_ERROR
+
+/* Traps taken in Current EL with SP_ELx */
+hyp_sync:
+        entry   hyp=1
+        msr     daifclr, #2
+        adr     lr, return_to_hypervisor
+        mov     x0, sp
+        b       do_trap_hypervisor
+
+hyp_irq:
+        entry   hyp=1
+        adr     lr, return_to_hypervisor
+        mov     x0, sp
+        b       do_trap_irq
+
+guest_sync:
+        entry   hyp=0, compat=0
+        invalid BAD_SYNC /* No AArch64 guest support yet */
+
+guest_irq:
+        entry   hyp=0, compat=0
+        invalid BAD_IRQ /* No AArch64 guest support yet */
+
+guest_fiq_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_FIQ
+
+guest_error_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_ERROR
+
+guest_sync_compat:
+        entry   hyp=0, compat=1
+        msr     daifclr, #2
+        adr     lr, return_to_guest
+        mov     x0, sp
+        b       do_trap_hypervisor
+
+guest_irq_compat:
+        entry   hyp=0, compat=1
+        adr     lr, return_to_guest
+        mov     x0, sp
+        b       do_trap_irq
+
+guest_fiq_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_FIQ
+
+guest_error_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_ERROR
+
+ENTRY(return_to_new_vcpu)
+        ldr     x21, [sp, #UREGS_CPSR]
+        and     x21, x21, #PSR_MODE_MASK
+        /* Returning to EL2? */
+        cmp     x21, #PSR_MODE_EL2t
+        ccmp    x21, #PSR_MODE_EL2h, #0x4, ne
+        b.eq    return_to_hypervisor /* Yes */
+        /* Fall thru */
+ENTRY(return_to_guest)
+        bl      leave_hypervisor_tail /* Disables interrupts on return */
+        /* Fall thru */
+ENTRY(return_to_hypervisor)
+        msr     daifset, #2 /* Mask interrupts */
+
+        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
+
+        pop     x0, x1
+        pop     x2, x3
+        pop     x4, x5
+        pop     x6, x7
+        pop     x8, x9
+
+        /* XXX handle return to guest tasks, soft irqs etc */
+        
+        msr     elr_el2, x21                    // set up the return data
+        msr     spsr_el2, x22
+
+        pop     x10, x11
+        pop     x12, x13
+        pop     x14, x15
+        pop     x16, x17
+        pop     x18, x19
+        pop     x20, x21
+        pop     x22, x23
+        pop     x24, x25
+        pop     x26, x27
+        pop     x28, x29
+
+        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
+        eret
+
+/*
+ * Exception vectors.
+ */
+        .macro  ventry  label
+        .align  7
+        b       \label
+        .endm
+
+        .align  11
+ENTRY(hyp_traps_vector)
+        ventry  hyp_sync_invalid                // Synchronous EL2t
+        ventry  hyp_irq_invalid                 // IRQ EL2t
+        ventry  hyp_fiq_invalid                 // FIQ EL2t
+        ventry  hyp_error_invalid               // Error EL2t
+
+        ventry  hyp_sync                        // Synchronous EL2h
+        ventry  hyp_irq                         // IRQ EL2h
+        ventry  hyp_fiq_invalid                 // FIQ EL2h
+        ventry  hyp_error_invalid               // Error EL2h
+
+        ventry  guest_sync                      // Synchronous 64-bit EL0/EL1
+        ventry  guest_irq                       // IRQ 64-bit EL0/EL1
+        ventry  guest_fiq_invalid               // FIQ 64-bit EL0/EL1
+        ventry  guest_error_invalid             // Error 64-bit EL0/EL1
+
+        ventry  guest_sync_compat               // Synchronous 32-bit EL0/EL1
+        ventry  guest_irq_compat                // IRQ 32-bit EL0/EL1
+        ventry  guest_fiq_invalid_compat        // FIQ 32-bit EL0/EL1
+        ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
new file mode 100644
index 0000000..02ef992
--- /dev/null
+++ b/xen/arch/arm/arm64/traps.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/traps.c
+ *
+ * ARM AArch64 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <asm/system.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
+{
+    panic("Unhandled serror trap\n");
+}
+
+static const char *handler[]= {
+        "Synchronous Abort",
+        "IRQ",
+        "FIQ",
+        "Error"
+};
+
+asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
+{
+    uint64_t esr = READ_SYSREG64(ESR_EL2);
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
+           handler[reason], esr);
+
+    local_irq_disable();
+    panic("bad mode");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 0933aa8..883afd8 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -26,7 +26,7 @@
 typedef struct
 {
     struct hsr_dabt dabt;
-    uint32_t gva;
+    vaddr_t gva;
     paddr_t gpa;
 } mmio_info_t;
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c1f06c9..299848e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -387,7 +387,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
-    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    WRITE_SYSREG((vaddr_t)&hyp_traps_vector, VBAR_EL2);
     isb();
 
     /* Setup Stage 2 address translation */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d8eb5d3..b18f137 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
+    WRITE_SYSREG((vaddr_t)&hyp_traps_vector, VBAR_EL2);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index cb8a8d2..d6bdaa7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -628,7 +628,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
-void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
     uint32_t ttbr0 = READ_CP32(TTBR0);
@@ -636,7 +636,7 @@ void dump_guest_s1_walk(struct domain *d, uint32_t addr)
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
-    printk("dom%d VA 0x%08"PRIx32"\n", d->domain_id, addr);
+    printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
     printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
@@ -692,7 +692,11 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     mmio_info_t info;
 
     info.dabt = dabt;
+#ifdef CONFIG_ARM_32
     info.gva = READ_CP32(HDFAR);
+#else
+    info.gva = READ_SYSREG64(FAR_EL2);
+#endif
 
     if (dabt.s1ptw)
         goto bad_data_abort;
@@ -713,7 +717,7 @@ bad_data_abort:
 
     /* XXX inject a suitable fault into the guest */
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32"\n",
+           "    gva=%"PRIvaddr"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
            info.gva);
@@ -736,13 +740,17 @@ bad_data_abort:
 
 asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
 {
-    union hsr hsr = { .bits = READ_CP32(HSR) };
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
 
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_32(regs, hsr);
         break;
     case HSR_EC_CP15_64:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_64(regs, hsr);
         break;
     case HSR_EC_HVC:
@@ -754,6 +762,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
     default:
+ bad_trap:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
         do_unexpected_trap("Hypervisor", regs);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 36da12e..75b6287 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -228,6 +228,7 @@
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
 #define CSSELR_EL1              CSSELR
+#define ESR_EL2                 HSR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index bd473a8..396ec41 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -238,7 +238,7 @@ union hsr {
 #endif
 
 #ifndef __ASSEMBLY__
-extern uint32_t hyp_traps_vector[8];
+extern uint32_t hyp_traps_vector;
 
 void panic_PAR(uint64_t par);
 
-- 
1.7.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 Feb 14 17:04:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62E4-0003fc-1i; Thu, 14 Feb 2013 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.Campbell@citrix.com>) id 1U62E2-0003ci-Nz
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:03:59 +0000
Received: from [85.158.139.83:34563] by server-10.bemta-5.messagelabs.com id
	8B/1B-04697-DF81D115; Thu, 14 Feb 2013 17:03:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24895 invoked from network); 14 Feb 2013 17:03:56 -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;
	14 Feb 2013 17:03:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163444"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:55 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-NF;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:41 +0000
Message-ID: <1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
    restoring state.
---
 xen/arch/arm/arm64/Makefile      |    2 +
 xen/arch/arm/arm64/asm-offsets.c |   64 ++++++++++
 xen/arch/arm/arm64/entry.S       |  256 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/traps.c       |   56 ++++++++
 xen/arch/arm/io.h                |    2 +-
 xen/arch/arm/setup.c             |    2 +-
 xen/arch/arm/smpboot.c           |    2 +-
 xen/arch/arm/traps.c             |   17 ++-
 xen/include/asm-arm/cpregs.h     |    1 +
 xen/include/asm-arm/processor.h  |    2 +-
 10 files changed, 396 insertions(+), 8 deletions(-)
 create mode 100644 xen/arch/arm/arm64/asm-offsets.c
 create mode 100644 xen/arch/arm/arm64/entry.S
 create mode 100644 xen/arch/arm/arm64/traps.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 815f305..be41f43 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,5 +1,7 @@
 subdir-y += lib
 
+obj-y += entry.o
 obj-y += mode_switch.o
 
+obj-y += traps.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
new file mode 100644
index 0000000..691d6d5
--- /dev/null
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -0,0 +1,64 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_LR, struct cpu_user_regs, lr);
+
+   OFFSET(UREGS_SP, struct cpu_user_regs, sp);
+   OFFSET(UREGS_PC, struct cpu_user_regs, pc);
+   OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
+
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_el0, struct cpu_user_regs, sp_el0);
+   OFFSET(UREGS_SP_el1, struct cpu_user_regs, sp_el1);
+   OFFSET(UREGS_ELR_el1, struct cpu_user_regs, elr_el1);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
new file mode 100644
index 0000000..1b2c4ad
--- /dev/null
+++ b/xen/arch/arm/arm64/entry.S
@@ -0,0 +1,256 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+/*
+ * Register aliases.
+ */
+lr      .req    x30             // link register
+
+/*
+ * Stack pushing/popping (register pairs only). Equivalent to store decrement
+ * before, load increment after.
+ */
+        .macro  push, xreg1, xreg2
+        stp     \xreg1, \xreg2, [sp, #-16]!
+        .endm
+
+        .macro  pop, xreg1, xreg2
+        ldp     \xreg1, \xreg2, [sp], #16
+        .endm
+
+/*
+ * Save/restore guest mode specific state, outer stack frame
+ */
+        .macro  entry_guest, compat
+
+        add     x21, sp, #UREGS_SPSR_el1
+        mrs     x23, SPSR_EL1
+        str     x23, [x21]
+
+        .if \compat == 0 /* Aarch64 mode */
+
+        add     x21, sp, #UREGS_SP_el0
+        mrs     x22, SP_el0
+        str     x22, [x21]
+
+        add     x21, sp, #UREGS_ELR_el1
+        mrs     x22, SP_el1
+        mrs     x23, ELR_el1
+        stp     x22, x23, [x21]
+
+        .else             /* Aarch32 mode */
+
+        add     x21, sp, #UREGS_SPSR_fiq
+        mrs     x22, spsr_fiq
+        mrs     x23, spsr_irq
+        stp     w22, w23, [x21]
+
+        add     x21, sp, #UREGS_SPSR_und
+        mrs     x22, spsr_und
+        mrs     x23, spsr_abt
+        stp     w22, w23, [x21]
+
+        .endif
+
+        .endm
+
+/*
+ * Save state on entry to hypervisor
+ */
+        .macro  entry, hyp, compat
+        sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_SP)
+        push    x28, x29
+        push    x26, x27
+        push    x24, x25
+        push    x22, x23
+        push    x20, x21
+        push    x18, x19
+        push    x16, x17
+        push    x14, x15
+        push    x12, x13
+        push    x10, x11
+        push    x8, x9
+        push    x6, x7
+        push    x4, x5
+        push    x2, x3
+        push    x0, x1
+
+        .if \hyp == 1        /* Hypervisor mode */
+
+        add     x21, sp, #(UREGS_X0 - UREGS_SP)
+
+        .else                /* Guest mode */
+
+        entry_guest \compat
+        mov     x21, ~0 /* sp only valid for hyp frame XXX */
+
+        .endif
+
+        stp     lr, x21, [sp, #UREGS_LR]
+
+        mrs     x22, elr_el2
+        mrs     x23, spsr_el2
+        stp     x22, x23, [sp, #UREGS_PC]
+
+        .endm
+
+/*
+ * Bad Abort numbers
+ *-----------------
+ */
+#define BAD_SYNC        0
+#define BAD_IRQ         1
+#define BAD_FIQ         2
+#define BAD_ERROR       3
+
+        .macro  invalid, reason
+        mov     x0, sp
+        mov     x1, #\reason
+        b       do_bad_mode
+        .endm
+
+hyp_sync_invalid:
+        entry   hyp=1
+        invalid BAD_SYNC
+
+hyp_irq_invalid:
+        entry   hyp=1
+        invalid BAD_IRQ
+
+hyp_fiq_invalid:
+        entry   hyp=1
+        invalid BAD_FIQ
+
+hyp_error_invalid:
+        entry   hyp=1
+        invalid BAD_ERROR
+
+/* Traps taken in Current EL with SP_ELx */
+hyp_sync:
+        entry   hyp=1
+        msr     daifclr, #2
+        adr     lr, return_to_hypervisor
+        mov     x0, sp
+        b       do_trap_hypervisor
+
+hyp_irq:
+        entry   hyp=1
+        adr     lr, return_to_hypervisor
+        mov     x0, sp
+        b       do_trap_irq
+
+guest_sync:
+        entry   hyp=0, compat=0
+        invalid BAD_SYNC /* No AArch64 guest support yet */
+
+guest_irq:
+        entry   hyp=0, compat=0
+        invalid BAD_IRQ /* No AArch64 guest support yet */
+
+guest_fiq_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_FIQ
+
+guest_error_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_ERROR
+
+guest_sync_compat:
+        entry   hyp=0, compat=1
+        msr     daifclr, #2
+        adr     lr, return_to_guest
+        mov     x0, sp
+        b       do_trap_hypervisor
+
+guest_irq_compat:
+        entry   hyp=0, compat=1
+        adr     lr, return_to_guest
+        mov     x0, sp
+        b       do_trap_irq
+
+guest_fiq_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_FIQ
+
+guest_error_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_ERROR
+
+ENTRY(return_to_new_vcpu)
+        ldr     x21, [sp, #UREGS_CPSR]
+        and     x21, x21, #PSR_MODE_MASK
+        /* Returning to EL2? */
+        cmp     x21, #PSR_MODE_EL2t
+        ccmp    x21, #PSR_MODE_EL2h, #0x4, ne
+        b.eq    return_to_hypervisor /* Yes */
+        /* Fall thru */
+ENTRY(return_to_guest)
+        bl      leave_hypervisor_tail /* Disables interrupts on return */
+        /* Fall thru */
+ENTRY(return_to_hypervisor)
+        msr     daifset, #2 /* Mask interrupts */
+
+        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
+
+        pop     x0, x1
+        pop     x2, x3
+        pop     x4, x5
+        pop     x6, x7
+        pop     x8, x9
+
+        /* XXX handle return to guest tasks, soft irqs etc */
+        
+        msr     elr_el2, x21                    // set up the return data
+        msr     spsr_el2, x22
+
+        pop     x10, x11
+        pop     x12, x13
+        pop     x14, x15
+        pop     x16, x17
+        pop     x18, x19
+        pop     x20, x21
+        pop     x22, x23
+        pop     x24, x25
+        pop     x26, x27
+        pop     x28, x29
+
+        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
+        eret
+
+/*
+ * Exception vectors.
+ */
+        .macro  ventry  label
+        .align  7
+        b       \label
+        .endm
+
+        .align  11
+ENTRY(hyp_traps_vector)
+        ventry  hyp_sync_invalid                // Synchronous EL2t
+        ventry  hyp_irq_invalid                 // IRQ EL2t
+        ventry  hyp_fiq_invalid                 // FIQ EL2t
+        ventry  hyp_error_invalid               // Error EL2t
+
+        ventry  hyp_sync                        // Synchronous EL2h
+        ventry  hyp_irq                         // IRQ EL2h
+        ventry  hyp_fiq_invalid                 // FIQ EL2h
+        ventry  hyp_error_invalid               // Error EL2h
+
+        ventry  guest_sync                      // Synchronous 64-bit EL0/EL1
+        ventry  guest_irq                       // IRQ 64-bit EL0/EL1
+        ventry  guest_fiq_invalid               // FIQ 64-bit EL0/EL1
+        ventry  guest_error_invalid             // Error 64-bit EL0/EL1
+
+        ventry  guest_sync_compat               // Synchronous 32-bit EL0/EL1
+        ventry  guest_irq_compat                // IRQ 32-bit EL0/EL1
+        ventry  guest_fiq_invalid_compat        // FIQ 32-bit EL0/EL1
+        ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
new file mode 100644
index 0000000..02ef992
--- /dev/null
+++ b/xen/arch/arm/arm64/traps.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/traps.c
+ *
+ * ARM AArch64 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <asm/system.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
+{
+    panic("Unhandled serror trap\n");
+}
+
+static const char *handler[]= {
+        "Synchronous Abort",
+        "IRQ",
+        "FIQ",
+        "Error"
+};
+
+asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
+{
+    uint64_t esr = READ_SYSREG64(ESR_EL2);
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
+           handler[reason], esr);
+
+    local_irq_disable();
+    panic("bad mode");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 0933aa8..883afd8 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -26,7 +26,7 @@
 typedef struct
 {
     struct hsr_dabt dabt;
-    uint32_t gva;
+    vaddr_t gva;
     paddr_t gpa;
 } mmio_info_t;
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c1f06c9..299848e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -387,7 +387,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_mm(fdt_paddr, fdt_size);
 
     /* Setup Hyp vector base */
-    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    WRITE_SYSREG((vaddr_t)&hyp_traps_vector, VBAR_EL2);
     isb();
 
     /* Setup Stage 2 address translation */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d8eb5d3..b18f137 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
+    WRITE_SYSREG((vaddr_t)&hyp_traps_vector, VBAR_EL2);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index cb8a8d2..d6bdaa7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -628,7 +628,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
-void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
     uint32_t ttbr0 = READ_CP32(TTBR0);
@@ -636,7 +636,7 @@ void dump_guest_s1_walk(struct domain *d, uint32_t addr)
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
-    printk("dom%d VA 0x%08"PRIx32"\n", d->domain_id, addr);
+    printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
     printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
@@ -692,7 +692,11 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     mmio_info_t info;
 
     info.dabt = dabt;
+#ifdef CONFIG_ARM_32
     info.gva = READ_CP32(HDFAR);
+#else
+    info.gva = READ_SYSREG64(FAR_EL2);
+#endif
 
     if (dabt.s1ptw)
         goto bad_data_abort;
@@ -713,7 +717,7 @@ bad_data_abort:
 
     /* XXX inject a suitable fault into the guest */
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32"\n",
+           "    gva=%"PRIvaddr"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
            info.gva);
@@ -736,13 +740,17 @@ bad_data_abort:
 
 asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
 {
-    union hsr hsr = { .bits = READ_CP32(HSR) };
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
 
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_32(regs, hsr);
         break;
     case HSR_EC_CP15_64:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_64(regs, hsr);
         break;
     case HSR_EC_HVC:
@@ -754,6 +762,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
     default:
+ bad_trap:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
         do_unexpected_trap("Hypervisor", regs);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 36da12e..75b6287 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -228,6 +228,7 @@
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
 #define CSSELR_EL1              CSSELR
+#define ESR_EL2                 HSR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index bd473a8..396ec41 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -238,7 +238,7 @@ union hsr {
 #endif
 
 #ifndef __ASSEMBLY__
-extern uint32_t hyp_traps_vector[8];
+extern uint32_t hyp_traps_vector;
 
 void panic_PAR(uint64_t par);
 
-- 
1.7.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 Feb 14 17:04:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62E9-0003ou-2x; Thu, 14 Feb 2013 17:04:05 +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 1U62E7-0003lI-K2
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:04 +0000
Received: from [85.158.139.83:34944] by server-12.bemta-5.messagelabs.com id
	97/88-20195-2091D115; Thu, 14 Feb 2013 17:04:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25314 invoked from network); 14 Feb 2013 17:04:01 -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;
	14 Feb 2013 17:04:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163475"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:04:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:04:00 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Ck;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:29 +0000
Message-ID: <1360860480-9245-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 15/46] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |  114 --------------------------
 3 files changed, 270 insertions(+), 114 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 91098a0..9dbe8e3 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -18,6 +18,121 @@
 #define smp_rmb()       dmb()
 #define smp_wmb()       dmb()
 
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 33c031d..6fd26f8 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -17,6 +17,161 @@
 #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
 #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
 
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret, tmp;
+
+        switch (size) {
+        case 1:
+                asm volatile("//        __xchg1\n"
+                "1:     ldaxrb  %w0, [%3]\n"
+                "       stlxrb  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 2:
+                asm volatile("//        __xchg2\n"
+                "1:     ldaxrh  %w0, [%3]\n"
+                "       stlxrh  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("//        __xchg4\n"
+                "1:     ldaxr   %w0, [%3]\n"
+                "       stlxr   %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 8:
+                asm volatile("//        __xchg8\n"
+                "1:     ldaxr   %0, [%3]\n"
+                "       stlxr   %w1, %2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+
+        return ret;
+}
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
+                                      unsigned long new, int size)
+{
+        unsigned long oldval = 0, res;
+
+        switch (size) {
+        case 1:
+                do {
+                        asm volatile("// __cmpxchg1\n"
+                        "       ldxrb   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrb   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 2:
+                do {
+                        asm volatile("// __cmpxchg2\n"
+                        "       ldxrh   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrh   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "memory", "cc");
+                } while (res);
+                break;
+
+        case 4:
+                do {
+                        asm volatile("// __cmpxchg4\n"
+                        "       ldxr    %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 8:
+                do {
+                        asm volatile("// __cmpxchg8\n"
+                        "       ldxr    %1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %1, %3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        default:
+		__bad_cmpxchg(ptr, size);
+		oldval = 0;
+        }
+
+        return oldval;
+}
+
+static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
+                                         unsigned long new, int size)
+{
+        unsigned long ret;
+
+        smp_mb();
+        ret = __cmpxchg(ptr, old, new, size);
+        smp_mb();
+
+        return ret;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+        ((__typeof__(*(ptr)))__cmpxchg_mb((ptr),                        \
+                                          (unsigned long)(o),           \
+                                          (unsigned long)(n),           \
+                                          sizeof(*(ptr))))
+
+#define cmpxchg_local(ptr,o,n)                                          \
+        ((__typeof__(*(ptr)))__cmpxchg((ptr),                           \
+                                       (unsigned long)(o),              \
+                                       (unsigned long)(n),              \
+                                       sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 8b4c97a..e4cb99c 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,120 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-extern void __bad_xchg(volatile void *, int);
-
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
-{
-        unsigned long ret;
-        unsigned int tmp;
-
-        smp_mb();
-
-        switch (size) {
-        case 1:
-                asm volatile("@ __xchg1\n"
-                "1:     ldrexb  %0, [%3]\n"
-                "       strexb  %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        case 4:
-                asm volatile("@ __xchg4\n"
-                "1:     ldrex   %0, [%3]\n"
-                "       strex   %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        default:
-                __bad_xchg(ptr, size), ret = 0;
-                break;
-        }
-        smp_mb();
-
-        return ret;
-}
-
-/*
- * Atomic compare and exchange.  Compare OLD with MEM, if identical,
- * store NEW in MEM.  Return the initial value in MEM.  Success is
- * indicated by comparing RETURN with OLD.
- */
-
-extern void __bad_cmpxchg(volatile void *ptr, int size);
-
-static always_inline unsigned long __cmpxchg(
-    volatile void *ptr, unsigned long old, unsigned long new, int size)
-{
-    unsigned long /*long*/ oldval, res;
-
-    switch (size) {
-    case 1:
-        do {
-            asm volatile("@ __cmpxchg1\n"
-                         "       ldrexb  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexbeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 2:
-        do {
-            asm volatile("@ __cmpxchg2\n"
-                         "       ldrexh  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexheq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 4:
-        do {
-            asm volatile("@ __cmpxchg4\n"
-                         "       ldrex   %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#if 0
-    case 8:
-        do {
-            asm volatile("@ __cmpxchg8\n"
-                         "       ldrexd   %1, [%2]\n"
-                         "       mov      %0, #0\n"
-                         "       teq      %1, %3\n"
-                         "       strexdeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#endif
-    default:
-        __bad_cmpxchg(ptr, size);
-        oldval = 0;
-    }
-
-    return oldval;
-}
-#define cmpxchg(ptr,o,n)                                                \
-    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
-                                   (unsigned long)(n),sizeof(*(ptr))))
-
 #define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
 #define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
 
-- 
1.7.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 Feb 14 17:04:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62E9-0003ou-2x; Thu, 14 Feb 2013 17:04:05 +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 1U62E7-0003lI-K2
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:04 +0000
Received: from [85.158.139.83:34944] by server-12.bemta-5.messagelabs.com id
	97/88-20195-2091D115; Thu, 14 Feb 2013 17:04:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360861409!27139650!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25314 invoked from network); 14 Feb 2013 17:04:01 -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;
	14 Feb 2013 17:04:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7163475"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:04:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:04:00 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Ck;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:29 +0000
Message-ID: <1360860480-9245-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 15/46] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |  114 --------------------------
 3 files changed, 270 insertions(+), 114 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 91098a0..9dbe8e3 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -18,6 +18,121 @@
 #define smp_rmb()       dmb()
 #define smp_wmb()       dmb()
 
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 33c031d..6fd26f8 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -17,6 +17,161 @@
 #define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
 #define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
 
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret, tmp;
+
+        switch (size) {
+        case 1:
+                asm volatile("//        __xchg1\n"
+                "1:     ldaxrb  %w0, [%3]\n"
+                "       stlxrb  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 2:
+                asm volatile("//        __xchg2\n"
+                "1:     ldaxrh  %w0, [%3]\n"
+                "       stlxrh  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("//        __xchg4\n"
+                "1:     ldaxr   %w0, [%3]\n"
+                "       stlxr   %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 8:
+                asm volatile("//        __xchg8\n"
+                "1:     ldaxr   %0, [%3]\n"
+                "       stlxr   %w1, %2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+
+        return ret;
+}
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
+                                      unsigned long new, int size)
+{
+        unsigned long oldval = 0, res;
+
+        switch (size) {
+        case 1:
+                do {
+                        asm volatile("// __cmpxchg1\n"
+                        "       ldxrb   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrb   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 2:
+                do {
+                        asm volatile("// __cmpxchg2\n"
+                        "       ldxrh   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrh   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "memory", "cc");
+                } while (res);
+                break;
+
+        case 4:
+                do {
+                        asm volatile("// __cmpxchg4\n"
+                        "       ldxr    %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 8:
+                do {
+                        asm volatile("// __cmpxchg8\n"
+                        "       ldxr    %1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %1, %3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        default:
+		__bad_cmpxchg(ptr, size);
+		oldval = 0;
+        }
+
+        return oldval;
+}
+
+static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
+                                         unsigned long new, int size)
+{
+        unsigned long ret;
+
+        smp_mb();
+        ret = __cmpxchg(ptr, old, new, size);
+        smp_mb();
+
+        return ret;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+        ((__typeof__(*(ptr)))__cmpxchg_mb((ptr),                        \
+                                          (unsigned long)(o),           \
+                                          (unsigned long)(n),           \
+                                          sizeof(*(ptr))))
+
+#define cmpxchg_local(ptr,o,n)                                          \
+        ((__typeof__(*(ptr)))__cmpxchg((ptr),                           \
+                                       (unsigned long)(o),              \
+                                       (unsigned long)(n),              \
+                                       sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 8b4c97a..e4cb99c 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,120 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-extern void __bad_xchg(volatile void *, int);
-
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
-{
-        unsigned long ret;
-        unsigned int tmp;
-
-        smp_mb();
-
-        switch (size) {
-        case 1:
-                asm volatile("@ __xchg1\n"
-                "1:     ldrexb  %0, [%3]\n"
-                "       strexb  %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        case 4:
-                asm volatile("@ __xchg4\n"
-                "1:     ldrex   %0, [%3]\n"
-                "       strex   %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        default:
-                __bad_xchg(ptr, size), ret = 0;
-                break;
-        }
-        smp_mb();
-
-        return ret;
-}
-
-/*
- * Atomic compare and exchange.  Compare OLD with MEM, if identical,
- * store NEW in MEM.  Return the initial value in MEM.  Success is
- * indicated by comparing RETURN with OLD.
- */
-
-extern void __bad_cmpxchg(volatile void *ptr, int size);
-
-static always_inline unsigned long __cmpxchg(
-    volatile void *ptr, unsigned long old, unsigned long new, int size)
-{
-    unsigned long /*long*/ oldval, res;
-
-    switch (size) {
-    case 1:
-        do {
-            asm volatile("@ __cmpxchg1\n"
-                         "       ldrexb  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexbeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 2:
-        do {
-            asm volatile("@ __cmpxchg2\n"
-                         "       ldrexh  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexheq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 4:
-        do {
-            asm volatile("@ __cmpxchg4\n"
-                         "       ldrex   %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#if 0
-    case 8:
-        do {
-            asm volatile("@ __cmpxchg8\n"
-                         "       ldrexd   %1, [%2]\n"
-                         "       mov      %0, #0\n"
-                         "       teq      %1, %3\n"
-                         "       strexdeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#endif
-    default:
-        __bad_cmpxchg(ptr, size);
-        oldval = 0;
-    }
-
-    return oldval;
-}
-#define cmpxchg(ptr,o,n)                                                \
-    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
-                                   (unsigned long)(n),sizeof(*(ptr))))
-
 #define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
 #define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
 
-- 
1.7.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 Feb 14 17:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EE-0003z9-MM; Thu, 14 Feb 2013 17:04: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 1U62EC-0003lI-Oy
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:08 +0000
Received: from [85.158.139.211:36988] by server-12.bemta-5.messagelabs.com id
	57/B8-20195-8091D115; Thu, 14 Feb 2013 17:04:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9067 invoked from network); 14 Feb 2013 17:04:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533118"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:30 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Nj;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:42 +0000
Message-ID: <1360860480-9245-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 28/46] xen: arm: pcpu context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm64/entry.S   |   30 ++++++++++++++++++++++++++++++
 xen/arch/arm/domain.c        |    4 ++--
 xen/include/asm-arm/domain.h |   33 +++++++++++++++++++++++----------
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 1b2c4ad..a09dfcb 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -249,6 +249,36 @@ ENTRY(hyp_traps_vector)
         ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
 
 /*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * x0 - prev
+ * x1 - next
+ *
+ * Returns prev in x0
+ */
+ENTRY(__context_switch)
+        add     x8, x0, #VCPU_arch_saved_context
+        mov     x9, sp
+        stp     x19, x20, [x8], #16             // store callee-saved registers
+        stp     x21, x22, [x8], #16
+        stp     x23, x24, [x8], #16
+        stp     x25, x26, [x8], #16
+        stp     x27, x28, [x8], #16
+        stp     x29, x9, [x8], #16
+        str     lr, [x8]
+
+        add     x8, x1, #VCPU_arch_saved_context
+        ldp     x19, x20, [x8], #16             // restore callee-saved registers
+        ldp     x21, x22, [x8], #16
+        ldp     x23, x24, [x8], #16
+        ldp     x25, x26, [x8], #16
+        ldp     x27, x28, [x8], #16
+        ldp     x29, x9, [x8], #16
+        ldr     lr, [x8]
+        mov     sp, x9
+        ret
+
+/*
  * Local variables:
  * mode: ASM
  * indent-tabs-mode: nil
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3651fb2..f74caf4 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -387,8 +387,8 @@ int vcpu_initialise(struct vcpu *v)
                                            - sizeof(struct cpu_info));
 
     memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
-    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
-    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+    v->arch.saved_context.sp = (register_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (register_t)continue_new_vcpu;
 
     /* Idle VCPUs don't need the rest of this setup */
     if ( is_idle_vcpu(v) )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index e9370a5..ff6214b 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -99,16 +99,29 @@ struct vtimer {
 struct arch_vcpu
 {
     struct {
-        uint32_t    r4;
-        uint32_t    r5;
-        uint32_t    r6;
-        uint32_t    r7;
-        uint32_t    r8;
-        uint32_t    r9;
-        uint32_t    sl;
-        uint32_t    fp;
-        uint32_t    sp;
-        uint32_t    pc;
+#ifdef CONFIG_ARM_32
+        register_t r4;
+        register_t r5;
+        register_t r6;
+        register_t r7;
+        register_t r8;
+        register_t r9;
+        register_t sl;
+#else
+        register_t x19;
+        register_t x20;
+        register_t x21;
+        register_t x22;
+        register_t x23;
+        register_t x24;
+        register_t x25;
+        register_t x26;
+        register_t x27;
+        register_t x28;
+#endif
+        register_t fp;
+        register_t sp;
+        register_t pc;
     } saved_context;
 
     void *stack;
-- 
1.7.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 Feb 14 17:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EE-0003z9-MM; Thu, 14 Feb 2013 17:04: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 1U62EC-0003lI-Oy
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:08 +0000
Received: from [85.158.139.211:36988] by server-12.bemta-5.messagelabs.com id
	57/B8-20195-8091D115; Thu, 14 Feb 2013 17:04:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9067 invoked from network); 14 Feb 2013 17:04:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533118"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:30 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Nj;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:42 +0000
Message-ID: <1360860480-9245-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 28/46] xen: arm: pcpu context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm64/entry.S   |   30 ++++++++++++++++++++++++++++++
 xen/arch/arm/domain.c        |    4 ++--
 xen/include/asm-arm/domain.h |   33 +++++++++++++++++++++++----------
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 1b2c4ad..a09dfcb 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -249,6 +249,36 @@ ENTRY(hyp_traps_vector)
         ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
 
 /*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * x0 - prev
+ * x1 - next
+ *
+ * Returns prev in x0
+ */
+ENTRY(__context_switch)
+        add     x8, x0, #VCPU_arch_saved_context
+        mov     x9, sp
+        stp     x19, x20, [x8], #16             // store callee-saved registers
+        stp     x21, x22, [x8], #16
+        stp     x23, x24, [x8], #16
+        stp     x25, x26, [x8], #16
+        stp     x27, x28, [x8], #16
+        stp     x29, x9, [x8], #16
+        str     lr, [x8]
+
+        add     x8, x1, #VCPU_arch_saved_context
+        ldp     x19, x20, [x8], #16             // restore callee-saved registers
+        ldp     x21, x22, [x8], #16
+        ldp     x23, x24, [x8], #16
+        ldp     x25, x26, [x8], #16
+        ldp     x27, x28, [x8], #16
+        ldp     x29, x9, [x8], #16
+        ldr     lr, [x8]
+        mov     sp, x9
+        ret
+
+/*
  * Local variables:
  * mode: ASM
  * indent-tabs-mode: nil
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3651fb2..f74caf4 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -387,8 +387,8 @@ int vcpu_initialise(struct vcpu *v)
                                            - sizeof(struct cpu_info));
 
     memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
-    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
-    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+    v->arch.saved_context.sp = (register_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (register_t)continue_new_vcpu;
 
     /* Idle VCPUs don't need the rest of this setup */
     if ( is_idle_vcpu(v) )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index e9370a5..ff6214b 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -99,16 +99,29 @@ struct vtimer {
 struct arch_vcpu
 {
     struct {
-        uint32_t    r4;
-        uint32_t    r5;
-        uint32_t    r6;
-        uint32_t    r7;
-        uint32_t    r8;
-        uint32_t    r9;
-        uint32_t    sl;
-        uint32_t    fp;
-        uint32_t    sp;
-        uint32_t    pc;
+#ifdef CONFIG_ARM_32
+        register_t r4;
+        register_t r5;
+        register_t r6;
+        register_t r7;
+        register_t r8;
+        register_t r9;
+        register_t sl;
+#else
+        register_t x19;
+        register_t x20;
+        register_t x21;
+        register_t x22;
+        register_t x23;
+        register_t x24;
+        register_t x25;
+        register_t x26;
+        register_t x27;
+        register_t x28;
+#endif
+        register_t fp;
+        register_t sp;
+        register_t pc;
     } saved_context;
 
     void *stack;
-- 
1.7.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 Feb 14 17:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EF-0003zp-32; Thu, 14 Feb 2013 17:04: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 1U62ED-0003vV-83
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:09 +0000
Received: from [85.158.139.211:24846] by server-16.bemta-5.messagelabs.com id
	F0/6F-14948-8091D115; Thu, 14 Feb 2013 17:04:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9139 invoked from network); 14 Feb 2013 17:04:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533131"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:34 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-3M;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:51 +0000
Message-ID: <1360860480-9245-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 37/46] xen: arm: select_user_reg support for
	64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 20d2db9..b2b9327 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -72,6 +72,7 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
+#ifdef CONFIG_ARM_32
     /*
      * We rely heavily on the layout of cpu_user_regs to avoid having
      * to handle all of the registers individually. Use BUILD_BUG_ON to
@@ -124,6 +125,15 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
         BUG();
     }
 #undef REGOFFS
+#else
+    /* In 64 bit the syndrome register contains the AArch64 register
+     * number even if the trap was from AArch32 mode. Except that
+     * AArch32 R15 (PC) is encoded as 0b11111.
+     */
+    if ( reg == 0x1f /* && is aarch32 guest */)
+        return &regs->pc;
+    return &regs->x0 + reg;
+#endif
 }
 
 static const char *decode_fsc(uint32_t fsc, 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 Feb 14 17:04:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EF-0003zp-32; Thu, 14 Feb 2013 17:04: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 1U62ED-0003vV-83
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:09 +0000
Received: from [85.158.139.211:24846] by server-16.bemta-5.messagelabs.com id
	F0/6F-14948-8091D115; Thu, 14 Feb 2013 17:04:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9139 invoked from network); 14 Feb 2013 17:04:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533131"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:34 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yc-00012f-3M;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:51 +0000
Message-ID: <1360860480-9245-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 37/46] xen: arm: select_user_reg support for
	64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 20d2db9..b2b9327 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -72,6 +72,7 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
+#ifdef CONFIG_ARM_32
     /*
      * We rely heavily on the layout of cpu_user_regs to avoid having
      * to handle all of the registers individually. Use BUILD_BUG_ON to
@@ -124,6 +125,15 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
         BUG();
     }
 #undef REGOFFS
+#else
+    /* In 64 bit the syndrome register contains the AArch64 register
+     * number even if the trap was from AArch32 mode. Except that
+     * AArch32 R15 (PC) is encoded as 0b11111.
+     */
+    if ( reg == 0x1f /* && is aarch32 guest */)
+        return &regs->pc;
+    return &regs->x0 + reg;
+#endif
 }
 
 static const char *decode_fsc(uint32_t fsc, 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 Feb 14 17:04:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62EJ-00047l-Ja; Thu, 14 Feb 2013 17:04: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 1U62EG-00041J-FH
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:13 +0000
Received: from [85.158.143.35:15308] by server-1.bemta-4.messagelabs.com id
	0C/A7-08839-B091D115; Thu, 14 Feb 2013 17:04:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360861449!10136844!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14623 invoked from network); 14 Feb 2013 17:04:11 -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;
	14 Feb 2013 17:04:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533217"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:53 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Ae;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:27 +0000
Message-ID: <1360860480-9245-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 13/46] xen: arm64: address translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
I'm torn between unsigned long and vaddr_t...
---
 xen/include/asm-arm/arm32/page.h |   34 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   35 +++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/page.h       |   38 ++------------------------------------
 xen/include/asm-arm/types.h      |    4 ++++
 4 files changed, 75 insertions(+), 36 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 2b15c22..d295316 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -77,6 +77,40 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM32_PAGE_H__ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 4911ba3..9bf41fb 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -70,6 +70,41 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e2r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s12e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM64_PAGE_H__ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b89238b..ad52567 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -278,19 +278,7 @@ extern void dump_hyp_walk(uint32_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
-/* Ask the MMU to translate a VA for us */
-static inline uint64_t __va_to_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1HR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline uint64_t va_to_par(uint32_t va)
+static inline uint64_t va_to_par(vaddr_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
@@ -302,29 +290,7 @@ static inline uint64_t va_to_par(uint32_t va)
     return par;
 }
 
-/* Ask the MMU to translate a Guest VA for us */
-static inline uint64_t gva_to_ma_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS12NSOPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-static inline uint64_t gva_to_ipa_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1CPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline int gva_to_ipa(uint32_t va, paddr_t *paddr)
+static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 {
     uint64_t par = gva_to_ipa_par(va);
     if ( par & PAR_F )
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 07f7898..d3e16d8 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -36,12 +36,16 @@ typedef unsigned int u32;
 #if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
+typedef u32 vaddr_t;
+#define PRIvaddr PRIx32
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
+typedef u64 vaddr_t;
+#define PRIvaddr PRIx64
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
-- 
1.7.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 Feb 14 17:04:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62EJ-00047l-Ja; Thu, 14 Feb 2013 17:04: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 1U62EG-00041J-FH
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:13 +0000
Received: from [85.158.143.35:15308] by server-1.bemta-4.messagelabs.com id
	0C/A7-08839-B091D115; Thu, 14 Feb 2013 17:04:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360861449!10136844!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14623 invoked from network); 14 Feb 2013 17:04:11 -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;
	14 Feb 2013 17:04:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533217"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:53 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-Ae;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:27 +0000
Message-ID: <1360860480-9245-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 13/46] xen: arm64: address translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
I'm torn between unsigned long and vaddr_t...
---
 xen/include/asm-arm/arm32/page.h |   34 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   35 +++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/page.h       |   38 ++------------------------------------
 xen/include/asm-arm/types.h      |    4 ++++
 4 files changed, 75 insertions(+), 36 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 2b15c22..d295316 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -77,6 +77,40 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM32_PAGE_H__ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 4911ba3..9bf41fb 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -70,6 +70,41 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e2r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s12e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM64_PAGE_H__ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index b89238b..ad52567 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -278,19 +278,7 @@ extern void dump_hyp_walk(uint32_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
-/* Ask the MMU to translate a VA for us */
-static inline uint64_t __va_to_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1HR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline uint64_t va_to_par(uint32_t va)
+static inline uint64_t va_to_par(vaddr_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
@@ -302,29 +290,7 @@ static inline uint64_t va_to_par(uint32_t va)
     return par;
 }
 
-/* Ask the MMU to translate a Guest VA for us */
-static inline uint64_t gva_to_ma_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS12NSOPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-static inline uint64_t gva_to_ipa_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1CPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline int gva_to_ipa(uint32_t va, paddr_t *paddr)
+static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 {
     uint64_t par = gva_to_ipa_par(va);
     if ( par & PAR_F )
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 07f7898..d3e16d8 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -36,12 +36,16 @@ typedef unsigned int u32;
 #if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
+typedef u32 vaddr_t;
+#define PRIvaddr PRIx32
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
+typedef u64 vaddr_t;
+#define PRIvaddr PRIx64
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
-- 
1.7.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 Feb 14 17:04:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62EK-000493-5m; Thu, 14 Feb 2013 17:04: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 1U62EH-000433-Op
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:14 +0000
Received: from [85.158.143.35:12667] by server-2.bemta-4.messagelabs.com id
	45/30-01597-D091D115; Thu, 14 Feb 2013 17:04:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360861449!10136844!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14721 invoked from network); 14 Feb 2013 17:04:12 -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;
	14 Feb 2013 17:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533206"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:48 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-TS;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:45 +0000
Message-ID: <1360860480-9245-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 31/46] xen: arm: show_registers() support for
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |  176 +++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 151 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 97a29fb..642b0ea 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,12 +214,19 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr, ttbcr;
+    uint32_t sctlr, tcr;
     uint64_t ttbr0, ttbr1;
+#ifdef CONFIG_ARM_32
+    uint32_t dfar, ifar;
+#else
+    uint64_t far;
+#endif
 };
-static void _show_registers(struct cpu_user_regs *regs,
-                            struct reg_ctxt *ctxt,
-                            int guest_mode)
+
+static void show_registers_32(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -233,25 +240,34 @@ static void _show_registers(struct cpu_user_regs *regs,
        [PSR_MODE_SYS] = "SYS"
     };
 
-    print_xen_info();
-    printk("CPU:    %d\n", smp_processor_id());
+#ifdef CONFIG_ARM_64
+    printk("PC:     %08"PRIx32"\n", regs->pc32);
+#else
     printk("PC:     %08"PRIx32, regs->pc);
     if ( !guest_mode )
-            print_symbol(" %s", regs->pc);
+        print_symbol(" %s", regs->pc);
     printk("\n");
-    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
-           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+#endif
+    printk("CPSR:   %08"PRIx32" MODE:%s%s\n", regs->cpsr,
+           guest_mode ? "32-bit Guest " : "Hypervisor",
+           guest_mode ? mode_strings[regs->cpsr & PSR_MODE_MASK] : "");
     printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
            regs->r0, regs->r1, regs->r2, regs->r3);
     printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
            regs->r4, regs->r5, regs->r6, regs->r7);
     printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
-           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+           regs->r8, regs->r9, regs->r10,
+#ifdef CONFIG_ARM_64
+           regs->r11,
+#else
+           regs->fp,
+#endif
+           regs->r12);
 
     if ( guest_mode )
     {
-        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
-               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIregister"\n",
+               regs->sp_usr, regs->lr);
         printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
                regs->sp_svc, regs->lr_svc, regs->spsr_svc);
         printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
@@ -264,50 +280,160 @@ static void _show_registers(struct cpu_user_regs *regs,
                regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
-        printk("\n");
-        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
-               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+    }
+#ifndef CONFIG_ARM_64
+    else
+    {
+        printk("HYP: SP: %08"PRIx32" LR: %08"PRIregister"\n", regs->sp, regs->lr);
+    }
+#endif
+    printk("\n");
+
+    if ( guest_mode )
+    {
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TCR %08"PRIx32"\n",
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->tcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
-        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("IFAR %08"PRIx32" DFAR %08"PRIx32"\n",
+#ifdef CONFIG_ARM_64
+               (uint32_t)(ctxt->far >> 32),
+               (uint32_t)(ctxt->far & 0xffffffff)
+#else
+               ctxt->ifar, ctxt->dfar
+#endif
+            );
         printk("\n");
     }
-    else
+}
+
+#ifdef CONFIG_ARM_64
+static void show_registers_64(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
+{
+    printk("PC:     %016"PRIx64, regs->pc);
+    if ( !guest_mode )
+        print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("SP:     %08"PRIx64"\n", regs->sp);
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           guest_mode ? "64-bit Guest" : "Hypervisor");
+    printk("     X0: %016"PRIx64"  X1: %016"PRIx64"  X2: %016"PRIx64"\n",
+           regs->x0, regs->x1, regs->x2);
+    printk("     X3: %016"PRIx64"  X4: %016"PRIx64"  X5: %016"PRIx64"\n",
+           regs->x3, regs->x4, regs->x5);
+    printk("     X6: %016"PRIx64"  X7: %016"PRIx64"  X8: %016"PRIx64"\n",
+           regs->x6, regs->x7, regs->x8);
+    printk("     X9: %016"PRIx64" X10: %016"PRIx64" X11: %016"PRIx64"\n",
+           regs->x9, regs->x10, regs->x11);
+    printk("    X12: %016"PRIx64" X13: %016"PRIx64" X14: %016"PRIx64"\n",
+           regs->x12, regs->x13, regs->x14);
+    printk("    X15: %016"PRIx64" X16: %016"PRIx64" X17: %016"PRIx64"\n",
+           regs->x15, regs->x16, regs->x17);
+    printk("    X18: %016"PRIx64" X19: %016"PRIx64" X20: %016"PRIx64"\n",
+           regs->x18, regs->x19, regs->x20);
+    printk("    X21: %016"PRIx64" X22: %016"PRIx64" X23: %016"PRIx64"\n",
+           regs->x21, regs->x22, regs->x23);
+    printk("    X24: %016"PRIx64" X25: %016"PRIx64" X26: %016"PRIx64"\n",
+           regs->x24, regs->x25, regs->x26);
+    printk("    X27: %016"PRIx64" X28: %016"PRIx64" X29: %016"PRIx64"\n",
+           regs->x27, regs->x28, regs->lr);
+    printk("\n");
+
+    if ( guest_mode )
     {
-        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
+        printk("  TCR_EL1: %08"PRIx32"\n", ctxt->tcr);
+        printk("TTBR0_EL1: %010"PRIx64"\n", ctxt->ttbr0);
+        printk("TTBR1_EL1: %010"PRIx64"\n", ctxt->ttbr1);
+        printk("  FAR_EL1: %010"PRIx64"\n", ctxt->far);
         printk("\n");
     }
+}
+#endif
+
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode,
+                            const struct vcpu *v)
+{
+    print_xen_info();
+
+    printk("CPU:    %d\n", smp_processor_id());
+
+    if ( guest_mode )
+    {
+        if ( is_pv32_domain(v->domain) )
+            show_registers_32(regs, ctxt, guest_mode, v);
+#ifdef CONFIG_ARM_64
+        else if ( is_pv64_domain(v->domain) )
+            show_registers_64(regs, ctxt, guest_mode, v);
+#endif
+    }
+    else
+    {
+#ifdef CONFIG_ARM_64
+        show_registers_64(regs, ctxt, guest_mode, v);
+#else
+        show_registers_32(regs, ctxt, guest_mode, v);
+#endif
+    }
 
+#ifdef CONFIG_ARM_32
     printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
     printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
     printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
     printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
     printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
     printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
     printk("\n");
 
     printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
     printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
     printk("\n");
+#else
+    printk("TTBR0_EL2: %"PRIx64"\n", READ_SYSREG64(TTBR0_EL2));
+    printk("  FAR_EL2: %"PRIx64"\n", READ_SYSREG64(FAR_EL2));
+    printk("HPFAR_EL2: %"PRIx64"\n", READ_SYSREG64(HPFAR_EL2));
+    printk("  HCR_EL2: %"PRIx64"\n", READ_SYSREG64(HCR_EL2));
+    printk("  ESR_EL2: %"PRIx64"\n", READ_SYSREG64(ESR_EL2));
+    printk("VTTBR_EL2: %"PRIx64"\n", READ_SYSREG64(VTTBR_EL2));
+    printk("\n");
+#endif
 }
 
 void show_registers(struct cpu_user_regs *regs)
 {
     struct reg_ctxt ctxt;
-    ctxt.sctlr = READ_CP32(SCTLR);
-    ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP64(TTBR0);
-    ctxt.ttbr1 = READ_CP64(TTBR1);
-    _show_registers(regs, &ctxt, guest_mode(regs));
+    ctxt.sctlr = READ_SYSREG(SCTLR_EL1);
+    ctxt.tcr = READ_SYSREG(TCR_EL1);
+    ctxt.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    ctxt.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = READ_CP32(DFAR);
+    ctxt.ifar = READ_CP32(IFAR);
+#else
+    ctxt.far = READ_SYSREG(FAR_EL1);
+#endif
+    _show_registers(regs, &ctxt, guest_mode(regs), current);
 }
 
 void vcpu_show_registers(const struct vcpu *v)
 {
     struct reg_ctxt ctxt;
     ctxt.sctlr = v->arch.sctlr;
-    ctxt.ttbcr = v->arch.ttbcr;
+    ctxt.tcr = v->arch.ttbcr;
     ctxt.ttbr0 = v->arch.ttbr0;
     ctxt.ttbr1 = v->arch.ttbr1;
-    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = v->arch.dfar;
+    ctxt.ifar = v->arch.ifar;
+#else
+    ctxt.far = v->arch.far;
+#endif
+    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1, v);
 }
 
 static void show_guest_stack(struct cpu_user_regs *regs)
-- 
1.7.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 Feb 14 17:04:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62EK-000493-5m; Thu, 14 Feb 2013 17:04: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 1U62EH-000433-Op
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:14 +0000
Received: from [85.158.143.35:12667] by server-2.bemta-4.messagelabs.com id
	45/30-01597-D091D115; Thu, 14 Feb 2013 17:04:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360861449!10136844!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14721 invoked from network); 14 Feb 2013 17:04:12 -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;
	14 Feb 2013 17:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533206"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:48 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-TS;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:45 +0000
Message-ID: <1360860480-9245-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 31/46] xen: arm: show_registers() support for
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/arch/arm/traps.c |  176 +++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 151 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 97a29fb..642b0ea 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,12 +214,19 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr, ttbcr;
+    uint32_t sctlr, tcr;
     uint64_t ttbr0, ttbr1;
+#ifdef CONFIG_ARM_32
+    uint32_t dfar, ifar;
+#else
+    uint64_t far;
+#endif
 };
-static void _show_registers(struct cpu_user_regs *regs,
-                            struct reg_ctxt *ctxt,
-                            int guest_mode)
+
+static void show_registers_32(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -233,25 +240,34 @@ static void _show_registers(struct cpu_user_regs *regs,
        [PSR_MODE_SYS] = "SYS"
     };
 
-    print_xen_info();
-    printk("CPU:    %d\n", smp_processor_id());
+#ifdef CONFIG_ARM_64
+    printk("PC:     %08"PRIx32"\n", regs->pc32);
+#else
     printk("PC:     %08"PRIx32, regs->pc);
     if ( !guest_mode )
-            print_symbol(" %s", regs->pc);
+        print_symbol(" %s", regs->pc);
     printk("\n");
-    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
-           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+#endif
+    printk("CPSR:   %08"PRIx32" MODE:%s%s\n", regs->cpsr,
+           guest_mode ? "32-bit Guest " : "Hypervisor",
+           guest_mode ? mode_strings[regs->cpsr & PSR_MODE_MASK] : "");
     printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
            regs->r0, regs->r1, regs->r2, regs->r3);
     printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
            regs->r4, regs->r5, regs->r6, regs->r7);
     printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
-           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+           regs->r8, regs->r9, regs->r10,
+#ifdef CONFIG_ARM_64
+           regs->r11,
+#else
+           regs->fp,
+#endif
+           regs->r12);
 
     if ( guest_mode )
     {
-        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
-               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIregister"\n",
+               regs->sp_usr, regs->lr);
         printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
                regs->sp_svc, regs->lr_svc, regs->spsr_svc);
         printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
@@ -264,50 +280,160 @@ static void _show_registers(struct cpu_user_regs *regs,
                regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
-        printk("\n");
-        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
-               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+    }
+#ifndef CONFIG_ARM_64
+    else
+    {
+        printk("HYP: SP: %08"PRIx32" LR: %08"PRIregister"\n", regs->sp, regs->lr);
+    }
+#endif
+    printk("\n");
+
+    if ( guest_mode )
+    {
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TCR %08"PRIx32"\n",
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->tcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
-        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("IFAR %08"PRIx32" DFAR %08"PRIx32"\n",
+#ifdef CONFIG_ARM_64
+               (uint32_t)(ctxt->far >> 32),
+               (uint32_t)(ctxt->far & 0xffffffff)
+#else
+               ctxt->ifar, ctxt->dfar
+#endif
+            );
         printk("\n");
     }
-    else
+}
+
+#ifdef CONFIG_ARM_64
+static void show_registers_64(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
+{
+    printk("PC:     %016"PRIx64, regs->pc);
+    if ( !guest_mode )
+        print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("SP:     %08"PRIx64"\n", regs->sp);
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           guest_mode ? "64-bit Guest" : "Hypervisor");
+    printk("     X0: %016"PRIx64"  X1: %016"PRIx64"  X2: %016"PRIx64"\n",
+           regs->x0, regs->x1, regs->x2);
+    printk("     X3: %016"PRIx64"  X4: %016"PRIx64"  X5: %016"PRIx64"\n",
+           regs->x3, regs->x4, regs->x5);
+    printk("     X6: %016"PRIx64"  X7: %016"PRIx64"  X8: %016"PRIx64"\n",
+           regs->x6, regs->x7, regs->x8);
+    printk("     X9: %016"PRIx64" X10: %016"PRIx64" X11: %016"PRIx64"\n",
+           regs->x9, regs->x10, regs->x11);
+    printk("    X12: %016"PRIx64" X13: %016"PRIx64" X14: %016"PRIx64"\n",
+           regs->x12, regs->x13, regs->x14);
+    printk("    X15: %016"PRIx64" X16: %016"PRIx64" X17: %016"PRIx64"\n",
+           regs->x15, regs->x16, regs->x17);
+    printk("    X18: %016"PRIx64" X19: %016"PRIx64" X20: %016"PRIx64"\n",
+           regs->x18, regs->x19, regs->x20);
+    printk("    X21: %016"PRIx64" X22: %016"PRIx64" X23: %016"PRIx64"\n",
+           regs->x21, regs->x22, regs->x23);
+    printk("    X24: %016"PRIx64" X25: %016"PRIx64" X26: %016"PRIx64"\n",
+           regs->x24, regs->x25, regs->x26);
+    printk("    X27: %016"PRIx64" X28: %016"PRIx64" X29: %016"PRIx64"\n",
+           regs->x27, regs->x28, regs->lr);
+    printk("\n");
+
+    if ( guest_mode )
     {
-        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
+        printk("  TCR_EL1: %08"PRIx32"\n", ctxt->tcr);
+        printk("TTBR0_EL1: %010"PRIx64"\n", ctxt->ttbr0);
+        printk("TTBR1_EL1: %010"PRIx64"\n", ctxt->ttbr1);
+        printk("  FAR_EL1: %010"PRIx64"\n", ctxt->far);
         printk("\n");
     }
+}
+#endif
+
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode,
+                            const struct vcpu *v)
+{
+    print_xen_info();
+
+    printk("CPU:    %d\n", smp_processor_id());
+
+    if ( guest_mode )
+    {
+        if ( is_pv32_domain(v->domain) )
+            show_registers_32(regs, ctxt, guest_mode, v);
+#ifdef CONFIG_ARM_64
+        else if ( is_pv64_domain(v->domain) )
+            show_registers_64(regs, ctxt, guest_mode, v);
+#endif
+    }
+    else
+    {
+#ifdef CONFIG_ARM_64
+        show_registers_64(regs, ctxt, guest_mode, v);
+#else
+        show_registers_32(regs, ctxt, guest_mode, v);
+#endif
+    }
 
+#ifdef CONFIG_ARM_32
     printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
     printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
     printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
     printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
     printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
     printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
     printk("\n");
 
     printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
     printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
     printk("\n");
+#else
+    printk("TTBR0_EL2: %"PRIx64"\n", READ_SYSREG64(TTBR0_EL2));
+    printk("  FAR_EL2: %"PRIx64"\n", READ_SYSREG64(FAR_EL2));
+    printk("HPFAR_EL2: %"PRIx64"\n", READ_SYSREG64(HPFAR_EL2));
+    printk("  HCR_EL2: %"PRIx64"\n", READ_SYSREG64(HCR_EL2));
+    printk("  ESR_EL2: %"PRIx64"\n", READ_SYSREG64(ESR_EL2));
+    printk("VTTBR_EL2: %"PRIx64"\n", READ_SYSREG64(VTTBR_EL2));
+    printk("\n");
+#endif
 }
 
 void show_registers(struct cpu_user_regs *regs)
 {
     struct reg_ctxt ctxt;
-    ctxt.sctlr = READ_CP32(SCTLR);
-    ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP64(TTBR0);
-    ctxt.ttbr1 = READ_CP64(TTBR1);
-    _show_registers(regs, &ctxt, guest_mode(regs));
+    ctxt.sctlr = READ_SYSREG(SCTLR_EL1);
+    ctxt.tcr = READ_SYSREG(TCR_EL1);
+    ctxt.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    ctxt.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = READ_CP32(DFAR);
+    ctxt.ifar = READ_CP32(IFAR);
+#else
+    ctxt.far = READ_SYSREG(FAR_EL1);
+#endif
+    _show_registers(regs, &ctxt, guest_mode(regs), current);
 }
 
 void vcpu_show_registers(const struct vcpu *v)
 {
     struct reg_ctxt ctxt;
     ctxt.sctlr = v->arch.sctlr;
-    ctxt.ttbcr = v->arch.ttbcr;
+    ctxt.tcr = v->arch.ttbcr;
     ctxt.ttbr0 = v->arch.ttbr0;
     ctxt.ttbr1 = v->arch.ttbr1;
-    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = v->arch.dfar;
+    ctxt.ifar = v->arch.ifar;
+#else
+    ctxt.far = v->arch.far;
+#endif
+    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1, v);
 }
 
 static void show_guest_stack(struct cpu_user_regs *regs)
-- 
1.7.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 Feb 14 17:04:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EK-0004AF-PA; Thu, 14 Feb 2013 17:04: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 1U62EI-00043w-61
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:14 +0000
Received: from [85.158.143.35:15381] by server-3.bemta-4.messagelabs.com id
	59/44-08920-D091D115; Thu, 14 Feb 2013 17:04:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360861449!10136844!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14772 invoked from network); 14 Feb 2013 17:04:12 -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;
	14 Feb 2013 17:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533228"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:58 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-V2;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:46 +0000
Message-ID: <1360860480-9245-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 32/46] xen: arm: make dom0 builder work on
	64-bit 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

This still only builds a 32-bit dom0, although it lays a bit of
simple ground work for 64-bit dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c |   53 ++++++++++++++++++++++++++++--------------
 1 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 30d014a..29cef73 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -68,7 +68,7 @@ static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
             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);
+        printk("Populate P2M %#"PRIx64"->%#"PRIx64"\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;
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
@@ -319,7 +319,8 @@ int construct_dom0(struct domain *d)
     gic_route_irq_to_guest(d, 47, "eth");
 
     /* Enable second stage translation */
-    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+    WRITE_SYSREG(READ_SYSREG(HCR_EL2) | HCR_VM, HCR_EL2);
+    isb();
 
     /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
@@ -337,24 +338,40 @@ int construct_dom0(struct domain *d)
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
-/* FROM LINUX head.S
-
- * Kernel startup entry point.
- * ---------------------------
- *
- * This is normally called from the decompressor code.  The requirements
- * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
- * r1 = machine nr, r2 = atags or dtb pointer.
- *...
- */
+#ifdef CONFIG_ARM_64
+    d->arch.type = kinfo.type;
+#endif
 
-    regs->r0 = 0; /* SBZ */
-    regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
-    regs->r2 = kinfo.dtb_paddr;
+    if ( is_pv32_domain(d) )
+    {
+        /* FROM LINUX head.S
+         *
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * This is normally called from the decompressor code.  The requirements
+         * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+         * r1 = machine nr, r2 = atags or dtb pointer.
+         *...
+         */
+        regs->r0 = 0; /* SBZ */
+        regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
+        regs->r2 = kinfo.dtb_paddr;
+    }
+#ifdef CONFIG_ARM_64
+    else
+    {
+        /* From linux/Documentation/arm64/booting.txt */
+        regs->x0 = kinfo.dtb_paddr;
+        regs->x1 = 0; /* Reserved for future use */
+        regs->x2 = 0; /* Reserved for future use */
+        regs->x3 = 0; /* Reserved for future use */
+    }
+#endif
 
-    WRITE_CP32(SCTLR_BASE, SCTLR);
+    v->arch.sctlr = SCTLR_BASE;
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_SYSREG(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR_EL2);
     isb();
 
     local_abort_enable();
-- 
1.7.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 Feb 14 17:04:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EK-0004AF-PA; Thu, 14 Feb 2013 17:04: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 1U62EI-00043w-61
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:14 +0000
Received: from [85.158.143.35:15381] by server-3.bemta-4.messagelabs.com id
	59/44-08920-D091D115; Thu, 14 Feb 2013 17:04:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360861449!10136844!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14772 invoked from network); 14 Feb 2013 17:04:12 -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;
	14 Feb 2013 17:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533228"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:58 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-V2;
	Thu, 14 Feb 2013 16:48:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:46 +0000
Message-ID: <1360860480-9245-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 32/46] xen: arm: make dom0 builder work on
	64-bit 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

This still only builds a 32-bit dom0, although it lays a bit of
simple ground work for 64-bit dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c |   53 ++++++++++++++++++++++++++++--------------
 1 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 30d014a..29cef73 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -68,7 +68,7 @@ static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
             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);
+        printk("Populate P2M %#"PRIx64"->%#"PRIx64"\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;
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
@@ -319,7 +319,8 @@ int construct_dom0(struct domain *d)
     gic_route_irq_to_guest(d, 47, "eth");
 
     /* Enable second stage translation */
-    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+    WRITE_SYSREG(READ_SYSREG(HCR_EL2) | HCR_VM, HCR_EL2);
+    isb();
 
     /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
@@ -337,24 +338,40 @@ int construct_dom0(struct domain *d)
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
-/* FROM LINUX head.S
-
- * Kernel startup entry point.
- * ---------------------------
- *
- * This is normally called from the decompressor code.  The requirements
- * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
- * r1 = machine nr, r2 = atags or dtb pointer.
- *...
- */
+#ifdef CONFIG_ARM_64
+    d->arch.type = kinfo.type;
+#endif
 
-    regs->r0 = 0; /* SBZ */
-    regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
-    regs->r2 = kinfo.dtb_paddr;
+    if ( is_pv32_domain(d) )
+    {
+        /* FROM LINUX head.S
+         *
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * This is normally called from the decompressor code.  The requirements
+         * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+         * r1 = machine nr, r2 = atags or dtb pointer.
+         *...
+         */
+        regs->r0 = 0; /* SBZ */
+        regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
+        regs->r2 = kinfo.dtb_paddr;
+    }
+#ifdef CONFIG_ARM_64
+    else
+    {
+        /* From linux/Documentation/arm64/booting.txt */
+        regs->x0 = kinfo.dtb_paddr;
+        regs->x1 = 0; /* Reserved for future use */
+        regs->x2 = 0; /* Reserved for future use */
+        regs->x3 = 0; /* Reserved for future use */
+    }
+#endif
 
-    WRITE_CP32(SCTLR_BASE, SCTLR);
+    v->arch.sctlr = SCTLR_BASE;
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_SYSREG(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR_EL2);
     isb();
 
     local_abort_enable();
-- 
1.7.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 Feb 14 17:04:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62ES-0004PE-IB; Thu, 14 Feb 2013 17:04: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 1U62EQ-0004Kw-S1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:23 +0000
Received: from [85.158.139.211:37048] by server-14.bemta-5.messagelabs.com id
	7A/42-06967-6191D115; Thu, 14 Feb 2013 17:04:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9153 invoked from network); 14 Feb 2013 17:04:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533143"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:39 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-DT;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:30 +0000
Message-ID: <1360860480-9245-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 16/46] xen: arm64: interrupt/abort mask/unmask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |   44 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   54 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   44 -----------------------------
 3 files changed, 98 insertions(+), 44 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 9dbe8e3..ac8fcb0 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -133,6 +133,50 @@ static always_inline unsigned long __cmpxchg(
     ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
                                    (unsigned long)(n),sizeof(*(ptr))))
 
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 6fd26f8..cc7b959 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -172,6 +172,60 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
                                        (unsigned long)(n),              \
                                        sizeof(*(ptr))))
 
+/* Uses uimm4 as a bitmask to select the clearing of one or more of
+ * the DAIF exception mask bits:
+ * bit 3 selects the D mask,
+ * bit 2 the A mask,
+ * bit 1 the I mask and
+ * bit 0 the F mask.
+*/
+
+#define local_fiq_disable()   asm volatile ( "msr daifset, #1\n" ::: "memory" )
+#define local_fiq_enable()    asm volatile ( "msr daifclr, #1\n" ::: "memory" )
+#define local_irq_disable()   asm volatile ( "msr daifset, #2\n" ::: "memory" )
+#define local_irq_enable()    asm volatile ( "msr daifclr, #2\n" ::: "memory" )
+#define local_abort_disable() asm volatile ( "msr daifset, #4\n" ::: "memory" )
+#define local_abort_enable()  asm volatile ( "msr daifclr, #4\n" ::: "memory" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile(                                                \
+        "mrs    %0, daif    // local_save_flags\n"               \
+                : "=r" (x)                                       \
+                :                                                \
+                : "memory");                                     \
+})
+
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+        "msr    daif, %0                // local_irq_restore"    \
+        :                                                        \
+        : "r" (flags)                                            \
+        : "memory");                                             \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index e4cb99c..a26936b 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,50 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
-#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
-
-#define local_save_flags(x)                                      \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
-                  : "=r" (x) :: "memory", "cc" );                \
-})
-#define local_irq_save(x)                                        \
-({                                                               \
-    local_save_flags(x);                                         \
-    local_irq_disable();                                         \
-})
-#define local_irq_restore(x)                                     \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile (                                               \
-            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
-            :                                                    \
-            : "r" (flags)                                        \
-            : "memory", "cc");                                   \
-})
-
-static inline int local_irq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !(flags & PSR_IRQ_MASK);
-}
-
-#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
-#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
-
-#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
-#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
-
-static inline int local_fiq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !!(flags & PSR_FIQ_MASK);
-}
-
 extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
 
 #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 Feb 14 17:04:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62ES-0004PE-IB; Thu, 14 Feb 2013 17:04: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 1U62EQ-0004Kw-S1
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:23 +0000
Received: from [85.158.139.211:37048] by server-14.bemta-5.messagelabs.com id
	7A/42-06967-6191D115; Thu, 14 Feb 2013 17:04:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9153 invoked from network); 14 Feb 2013 17:04:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533143"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:39 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-DT;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:30 +0000
Message-ID: <1360860480-9245-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 16/46] xen: arm64: interrupt/abort mask/unmask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |   44 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   54 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   44 -----------------------------
 3 files changed, 98 insertions(+), 44 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 9dbe8e3..ac8fcb0 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -133,6 +133,50 @@ static always_inline unsigned long __cmpxchg(
     ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
                                    (unsigned long)(n),sizeof(*(ptr))))
 
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 6fd26f8..cc7b959 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -172,6 +172,60 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
                                        (unsigned long)(n),              \
                                        sizeof(*(ptr))))
 
+/* Uses uimm4 as a bitmask to select the clearing of one or more of
+ * the DAIF exception mask bits:
+ * bit 3 selects the D mask,
+ * bit 2 the A mask,
+ * bit 1 the I mask and
+ * bit 0 the F mask.
+*/
+
+#define local_fiq_disable()   asm volatile ( "msr daifset, #1\n" ::: "memory" )
+#define local_fiq_enable()    asm volatile ( "msr daifclr, #1\n" ::: "memory" )
+#define local_irq_disable()   asm volatile ( "msr daifset, #2\n" ::: "memory" )
+#define local_irq_enable()    asm volatile ( "msr daifclr, #2\n" ::: "memory" )
+#define local_abort_disable() asm volatile ( "msr daifset, #4\n" ::: "memory" )
+#define local_abort_enable()  asm volatile ( "msr daifclr, #4\n" ::: "memory" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile(                                                \
+        "mrs    %0, daif    // local_save_flags\n"               \
+                : "=r" (x)                                       \
+                :                                                \
+                : "memory");                                     \
+})
+
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+        "msr    daif, %0                // local_irq_restore"    \
+        :                                                        \
+        : "r" (flags)                                            \
+        : "memory");                                             \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index e4cb99c..a26936b 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,50 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
-#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
-
-#define local_save_flags(x)                                      \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
-                  : "=r" (x) :: "memory", "cc" );                \
-})
-#define local_irq_save(x)                                        \
-({                                                               \
-    local_save_flags(x);                                         \
-    local_irq_disable();                                         \
-})
-#define local_irq_restore(x)                                     \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile (                                               \
-            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
-            :                                                    \
-            : "r" (flags)                                        \
-            : "memory", "cc");                                   \
-})
-
-static inline int local_irq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !(flags & PSR_IRQ_MASK);
-}
-
-#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
-#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
-
-#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
-#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
-
-static inline int local_fiq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !!(flags & PSR_FIQ_MASK);
-}
-
 extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
 
 #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 Feb 14 17:04:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EV-0004VA-5m; Thu, 14 Feb 2013 17:04: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 1U62ET-0004QZ-G9
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:25 +0000
Received: from [85.158.139.211:24898] by server-13.bemta-5.messagelabs.com id
	98/36-06769-8191D115; Thu, 14 Feb 2013 17:04:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9167 invoked from network); 14 Feb 2013 17:04:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533183"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:44 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-7M;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:25 +0000
Message-ID: <1360860480-9245-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 11/46] xen: arm64: PTE 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/page.h |   20 ++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   15 +++++++++++++++
 xen/include/asm-arm/page.h       |   20 --------------------
 3 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 073b8d1..a384f04 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -3,6 +3,26 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry.
+ *
+ * If the table entry is changing a text mapping, it is responsibility
+ * of the caller to issue an ISB after write_pte.
+ */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb;"
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        "dsb;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 636fb63..99b7296 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -3,6 +3,21 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb sy;"
+        "str %0, [%1];"         /* Write the entry */
+        "dsb sy;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        "dc cvac, %1;"
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb sy;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 709a508..4e245a9 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -230,26 +230,6 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
     return e;
 }
 
-/* Write a pagetable entry.
- *
- * If the table entry is changing a text mapping, it is responsibility
- * of the caller to issue an ISB after write_pte.
- */
-static inline void write_pte(lpae_t *p, lpae_t pte)
-{
-    asm volatile (
-        /* Ensure any writes have completed with the old mappings. */
-        "dsb;"
-        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
-        "strd %0, %H0, [%1];"
-        "dsb;"
-        /* Push this cacheline to the PoC so the rest of the system sees it. */
-        STORE_CP32(1, DCCMVAC)
-        /* Ensure that the data flush is completed before proceeding */
-        "dsb;"
-        : : "r" (pte.bits), "r" (p) : "memory");
-}
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/page.h>
 #elif defined(CONFIG_ARM_64)
-- 
1.7.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 Feb 14 17:04:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:04: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 1U62EV-0004VA-5m; Thu, 14 Feb 2013 17:04: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 1U62ET-0004QZ-G9
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:25 +0000
Received: from [85.158.139.211:24898] by server-13.bemta-5.messagelabs.com id
	98/36-06769-8191D115; Thu, 14 Feb 2013 17:04:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360861441!22536869!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9167 invoked from network); 14 Feb 2013 17:04:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7533183"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:03:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:03:44 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U61yb-00012f-7M;
	Thu, 14 Feb 2013 16:48:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 14 Feb 2013 16:47:25 +0000
Message-ID: <1360860480-9245-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 11/46] xen: arm64: PTE 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/page.h |   20 ++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   15 +++++++++++++++
 xen/include/asm-arm/page.h       |   20 --------------------
 3 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 073b8d1..a384f04 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -3,6 +3,26 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry.
+ *
+ * If the table entry is changing a text mapping, it is responsibility
+ * of the caller to issue an ISB after write_pte.
+ */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb;"
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        "dsb;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 636fb63..99b7296 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -3,6 +3,21 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb sy;"
+        "str %0, [%1];"         /* Write the entry */
+        "dsb sy;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        "dc cvac, %1;"
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb sy;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 709a508..4e245a9 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -230,26 +230,6 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
     return e;
 }
 
-/* Write a pagetable entry.
- *
- * If the table entry is changing a text mapping, it is responsibility
- * of the caller to issue an ISB after write_pte.
- */
-static inline void write_pte(lpae_t *p, lpae_t pte)
-{
-    asm volatile (
-        /* Ensure any writes have completed with the old mappings. */
-        "dsb;"
-        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
-        "strd %0, %H0, [%1];"
-        "dsb;"
-        /* Push this cacheline to the PoC so the rest of the system sees it. */
-        STORE_CP32(1, DCCMVAC)
-        /* Ensure that the data flush is completed before proceeding */
-        "dsb;"
-        : : "r" (pte.bits), "r" (p) : "memory");
-}
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/page.h>
 #elif defined(CONFIG_ARM_64)
-- 
1.7.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 Feb 14 17:04:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Ee-0004mU-4o; Thu, 14 Feb 2013 17:04: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 1U62Ec-0004js-W2
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:35 +0000
Received: from [85.158.143.99:44962] by server-1.bemta-4.messagelabs.com id
	9A/18-08839-2291D115; Thu, 14 Feb 2013 17:04:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360861473!26981911!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29505 invoked from network); 14 Feb 2013 17:04:33 -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; 14 Feb 2013 17:04:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 17:04:32 +0000
Message-Id: <511D276A02000078000BE73D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 17:05:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
	<20130214165003.GR83752@ocelot.phlegethon.org>
In-Reply-To: <20130214165003.GR83752@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 14.02.13 at 17:50, Tim Deegan <tim@xen.org> wrote:
> At 16:34 +0000 on 14 Feb (1360859678), Jan Beulich wrote:
>> >>> On 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
>> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
>> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
>> > @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
>> >  #endif
>> >  
>> >      /* reduce max_samples if necessary to limit pages allocated */
>> > -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
>> > +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
>> >      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
>> >      if ( (unsigned)max_samples > max_max_samples )
>> >          max_samples = max_max_samples;
>> 
>> I think the function would better return an error in that case. After
>> all there's little point in setting up anything when we for sure don't
>> know how many vCPU-s a domain is going to have.
> 
> Grand so:
> 
> # HG changeset patch
> # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
> xen/xenoprof: avoid division by 0.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 5a84cc531072 xen/common/xenoprof.c
> --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> +++ b/xen/common/xenoprof.c	Thu Feb 14 16:48:49 2013 +0000
> @@ -213,6 +213,9 @@ static int alloc_xenoprof_struct(
>      for_each_vcpu ( d, v )
>          nvcpu++;
>  
> +    if ( !nvcpu )
> +        return -EINVAL;

Missing some cleanup here? Or move the preceding loop and this
addition to the top of the function?

Jan

> +
>      bufsize = sizeof(struct xenoprof_buf);
>      i = sizeof(struct event_log);
>  #ifdef CONFIG_COMPAT




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:04:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Ee-0004mU-4o; Thu, 14 Feb 2013 17:04: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 1U62Ec-0004js-W2
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:04:35 +0000
Received: from [85.158.143.99:44962] by server-1.bemta-4.messagelabs.com id
	9A/18-08839-2291D115; Thu, 14 Feb 2013 17:04:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360861473!26981911!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29505 invoked from network); 14 Feb 2013 17:04:33 -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; 14 Feb 2013 17:04:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 14 Feb 2013 17:04:32 +0000
Message-Id: <511D276A02000078000BE73D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 14 Feb 2013 17:05:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
	<20130214165003.GR83752@ocelot.phlegethon.org>
In-Reply-To: <20130214165003.GR83752@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 14.02.13 at 17:50, Tim Deegan <tim@xen.org> wrote:
> At 16:34 +0000 on 14 Feb (1360859678), Jan Beulich wrote:
>> >>> On 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
>> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
>> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
>> > @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
>> >  #endif
>> >  
>> >      /* reduce max_samples if necessary to limit pages allocated */
>> > -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
>> > +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
>> >      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
>> >      if ( (unsigned)max_samples > max_max_samples )
>> >          max_samples = max_max_samples;
>> 
>> I think the function would better return an error in that case. After
>> all there's little point in setting up anything when we for sure don't
>> know how many vCPU-s a domain is going to have.
> 
> Grand so:
> 
> # HG changeset patch
> # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
> xen/xenoprof: avoid division by 0.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 5a84cc531072 xen/common/xenoprof.c
> --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> +++ b/xen/common/xenoprof.c	Thu Feb 14 16:48:49 2013 +0000
> @@ -213,6 +213,9 @@ static int alloc_xenoprof_struct(
>      for_each_vcpu ( d, v )
>          nvcpu++;
>  
> +    if ( !nvcpu )
> +        return -EINVAL;

Missing some cleanup here? Or move the preceding loop and this
addition to the top of the function?

Jan

> +
>      bufsize = sizeof(struct xenoprof_buf);
>      i = sizeof(struct event_log);
>  #ifdef CONFIG_COMPAT




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:10:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62K7-00088L-NN; Thu, 14 Feb 2013 17:10:15 +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 1U62K6-00088D-C8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:10:14 +0000
Received: from [85.158.139.83:10003] by server-16.bemta-5.messagelabs.com id
	5D/1A-14948-57A1D115; Thu, 14 Feb 2013 17:10:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360861807!26927178!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21083 invoked from network); 14 Feb 2013 17:10:08 -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; 14 Feb 2013 17:10:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U62Jw-000NPr-Qt; Thu, 14 Feb 2013 17:10:04 +0000
Date: Thu, 14 Feb 2013 17:10:04 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130214171004.GS83752@ocelot.phlegethon.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
	<20130214165003.GR83752@ocelot.phlegethon.org>
	<511D276A02000078000BE73D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511D276A02000078000BE73D@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 17:05 +0000 on 14 Feb (1360861530), Jan Beulich wrote:
> >>> On 14.02.13 at 17:50, Tim Deegan <tim@xen.org> wrote:
> > At 16:34 +0000 on 14 Feb (1360859678), Jan Beulich wrote:
> >> >>> On 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
> >> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> >> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
> >> > @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
> >> >  #endif
> >> >  
> >> >      /* reduce max_samples if necessary to limit pages allocated */
> >> > -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
> >> > +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
> >> >      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
> >> >      if ( (unsigned)max_samples > max_max_samples )
> >> >          max_samples = max_max_samples;
> >> 
> >> I think the function would better return an error in that case. After
> >> all there's little point in setting up anything when we for sure don't
> >> know how many vCPU-s a domain is going to have.
> > 
> > Grand so:
> > 
> > # HG changeset patch
> > # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
> > xen/xenoprof: avoid division by 0.
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r 5a84cc531072 xen/common/xenoprof.c
> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:48:49 2013 +0000
> > @@ -213,6 +213,9 @@ static int alloc_xenoprof_struct(
> >      for_each_vcpu ( d, v )
> >          nvcpu++;
> >  
> > +    if ( !nvcpu )
> > +        return -EINVAL;
> 
> Missing some cleanup here? Or move the preceding loop and this
> addition to the top of the function?

D'oh, yes.  Trying again:

# HG changeset patch
# Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
xen/xenoprof: avoid division by 0.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5a84cc531072 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
+++ b/xen/common/xenoprof.c	Thu Feb 14 17:07:41 2013 +0000
@@ -193,6 +193,13 @@ static int alloc_xenoprof_struct(
     unsigned max_max_samples;
     int i;
 
+    nvcpu = 0;
+    for_each_vcpu ( d, v )
+        nvcpu++;
+
+    if ( !nvcpu )
+        return -EINVAL;
+
     d->xenoprof = xzalloc(struct xenoprof);
     if ( d->xenoprof == NULL )
     {
@@ -209,10 +216,6 @@ static int alloc_xenoprof_struct(
         return -ENOMEM;
     }
 
-    nvcpu = 0;
-    for_each_vcpu ( d, v )
-        nvcpu++;
-
     bufsize = sizeof(struct xenoprof_buf);
     i = sizeof(struct event_log);
 #ifdef CONFIG_COMPAT

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:10:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62K7-00088L-NN; Thu, 14 Feb 2013 17:10:15 +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 1U62K6-00088D-C8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:10:14 +0000
Received: from [85.158.139.83:10003] by server-16.bemta-5.messagelabs.com id
	5D/1A-14948-57A1D115; Thu, 14 Feb 2013 17:10:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360861807!26927178!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21083 invoked from network); 14 Feb 2013 17:10:08 -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; 14 Feb 2013 17:10:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U62Jw-000NPr-Qt; Thu, 14 Feb 2013 17:10:04 +0000
Date: Thu, 14 Feb 2013 17:10:04 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130214171004.GS83752@ocelot.phlegethon.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
	<20130214165003.GR83752@ocelot.phlegethon.org>
	<511D276A02000078000BE73D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511D276A02000078000BE73D@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 17:05 +0000 on 14 Feb (1360861530), Jan Beulich wrote:
> >>> On 14.02.13 at 17:50, Tim Deegan <tim@xen.org> wrote:
> > At 16:34 +0000 on 14 Feb (1360859678), Jan Beulich wrote:
> >> >>> On 14.02.13 at 17:16, Tim Deegan <tim@xen.org> wrote:
> >> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> >> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:16:17 2013 +0000
> >> > @@ -225,7 +225,7 @@ static int alloc_xenoprof_struct(
> >> >  #endif
> >> >  
> >> >      /* reduce max_samples if necessary to limit pages allocated */
> >> > -    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu;
> >> > +    max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / (nvcpu ?: 1);
> >> >      max_max_samples = ( (max_bufsize - bufsize) / i ) + 1;
> >> >      if ( (unsigned)max_samples > max_max_samples )
> >> >          max_samples = max_max_samples;
> >> 
> >> I think the function would better return an error in that case. After
> >> all there's little point in setting up anything when we for sure don't
> >> know how many vCPU-s a domain is going to have.
> > 
> > Grand so:
> > 
> > # HG changeset patch
> > # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
> > xen/xenoprof: avoid division by 0.
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> > 
> > diff -r 5a84cc531072 xen/common/xenoprof.c
> > --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> > +++ b/xen/common/xenoprof.c	Thu Feb 14 16:48:49 2013 +0000
> > @@ -213,6 +213,9 @@ static int alloc_xenoprof_struct(
> >      for_each_vcpu ( d, v )
> >          nvcpu++;
> >  
> > +    if ( !nvcpu )
> > +        return -EINVAL;
> 
> Missing some cleanup here? Or move the preceding loop and this
> addition to the top of the function?

D'oh, yes.  Trying again:

# HG changeset patch
# Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
xen/xenoprof: avoid division by 0.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5a84cc531072 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
+++ b/xen/common/xenoprof.c	Thu Feb 14 17:07:41 2013 +0000
@@ -193,6 +193,13 @@ static int alloc_xenoprof_struct(
     unsigned max_max_samples;
     int i;
 
+    nvcpu = 0;
+    for_each_vcpu ( d, v )
+        nvcpu++;
+
+    if ( !nvcpu )
+        return -EINVAL;
+
     d->xenoprof = xzalloc(struct xenoprof);
     if ( d->xenoprof == NULL )
     {
@@ -209,10 +216,6 @@ static int alloc_xenoprof_struct(
         return -ENOMEM;
     }
 
-    nvcpu = 0;
-    for_each_vcpu ( d, v )
-        nvcpu++;
-
     bufsize = sizeof(struct xenoprof_buf);
     i = sizeof(struct event_log);
 #ifdef CONFIG_COMPAT

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:12:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Lr-0008LK-Dn; Thu, 14 Feb 2013 17:12:03 +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 1U62Lo-0008L1-Ir
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:12:00 +0000
Received: from [85.158.143.99:44826] by server-2.bemta-4.messagelabs.com id
	3A/19-01597-FDA1D115; Thu, 14 Feb 2013 17:11:59 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360861918!24199977!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18279 invoked from network); 14 Feb 2013 17:11:58 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-216.messagelabs.com with SMTP;
	14 Feb 2013 17:11:58 -0000
Received: from p5b2e3d19.dip.t-dialin.net ([91.46.61.25] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1U62Ll-00084O-Ox; Thu, 14 Feb 2013 17:11:57 +0000
From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Feb 2013 18:11:56 +0100
Message-Id: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when not
	covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 a machine that could not cover all its RAM with MTRR ranges,
a crash on boot as dom0 was caused by dom0 trying to create
kernel mapping tables for the clipped range.

(XEN) WARNING: MTRRs do not cover all of memory.
(XEN) Truncating RAM from 9109504kB to 9043968kB
...
(XEN)  0000000228000000 - 000000022c000000 (unusable)
...
[    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
[    0.000000]  0228000000 - 022c000000 page 4k
[    0.000000] kernel direct mapping tables up to 22c000000 @
               1e97d8000-1e97fa000
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
(XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
(XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
      type 1000000000000000: caf=8000000000000003 taf=1000000000000001
(XEN) mm.c:2985:d0 Error while pinning mfn 81de

Setting the range in E820 to E280_UNUSABLE seems ambigous as
this is the same type that gets used for memory to be used only
as guest memory (using dom0_mem=).

To avoid this, the clipped memory should be dropped completely
from E820 (as it is done if setting the memory type fails).
This is currently restricted to only the case of memory not
coverable by MTRRs (which could be tested). Maybe it should
be done in other cases, too.

BugLink: http://bugs.launchpad.net/bugs/1111470

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/arch/x86/e820.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 55fe0d6..8dfe427 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -372,7 +372,7 @@ static unsigned long __init find_max_pfn(void)
     return max_pfn;
 }
 
-static void __init clip_to_limit(uint64_t limit, char *warnmsg)
+static void __init clip_to_limit(uint64_t limit, char *warnmsg, int drop)
 {
     int i;
     char _warnmsg[160];
@@ -394,7 +394,8 @@ static void __init clip_to_limit(uint64_t limit, char *warnmsg)
             uint64_t, old_limit, e820.map[i].addr + e820.map[i].size);
 
         /* We try to convert clipped RAM areas to E820_UNUSABLE. */
-        if ( e820_change_range_type(&e820, max(e820.map[i].addr, limit),
+        if ( !drop &&
+             e820_change_range_type(&e820, max(e820.map[i].addr, limit),
                                     e820.map[i].addr + e820.map[i].size,
                                     E820_RAM, E820_UNUSABLE) )
             continue;
@@ -524,7 +525,7 @@ static void __init machine_specific_memory_setup(
     (void)copy_e820_map(raw, nr);
 
     if ( opt_mem )
-        clip_to_limit(opt_mem, NULL);
+        clip_to_limit(opt_mem, NULL, 0);
 
     if ( opt_availmem )
     {
@@ -534,7 +535,7 @@ static void __init machine_specific_memory_setup(
         if ( size > opt_availmem )
             clip_to_limit(
                 e820.map[i-1].addr + e820.map[i-1].size - (size-opt_availmem),
-                NULL);
+                NULL, 0);
     }
 
     mpt_limit = ((RDWR_MPT_VIRT_END - RDWR_MPT_VIRT_START)
@@ -545,13 +546,13 @@ static void __init machine_specific_memory_setup(
         mpt_limit = ro_mpt_limit;
     clip_to_limit(mpt_limit,
                   "Only the first %lu GB of the physical "
-                  "memory map can be accessed by Xen.");
+                  "memory map can be accessed by Xen.", 0);
 
     reserve_dmi_region();
 
     top_of_ram = mtrr_top_of_ram();
     if ( top_of_ram )
-        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.");
+        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.", 1);
 }
 
 /* This function relies on the passed in e820->map[] being sorted. */
-- 
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 Thu Feb 14 17:12:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62Lr-0008LK-Dn; Thu, 14 Feb 2013 17:12:03 +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 1U62Lo-0008L1-Ir
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:12:00 +0000
Received: from [85.158.143.99:44826] by server-2.bemta-4.messagelabs.com id
	3A/19-01597-FDA1D115; Thu, 14 Feb 2013 17:11:59 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360861918!24199977!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18279 invoked from network); 14 Feb 2013 17:11:58 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-7.tower-216.messagelabs.com with SMTP;
	14 Feb 2013 17:11:58 -0000
Received: from p5b2e3d19.dip.t-dialin.net ([91.46.61.25] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1U62Ll-00084O-Ox; Thu, 14 Feb 2013 17:11:57 +0000
From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org
Date: Thu, 14 Feb 2013 18:11:56 +0100
Message-Id: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when not
	covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 a machine that could not cover all its RAM with MTRR ranges,
a crash on boot as dom0 was caused by dom0 trying to create
kernel mapping tables for the clipped range.

(XEN) WARNING: MTRRs do not cover all of memory.
(XEN) Truncating RAM from 9109504kB to 9043968kB
...
(XEN)  0000000228000000 - 000000022c000000 (unusable)
...
[    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
[    0.000000]  0228000000 - 022c000000 page 4k
[    0.000000] kernel direct mapping tables up to 22c000000 @
               1e97d8000-1e97fa000
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
(XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
(XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
      type 1000000000000000: caf=8000000000000003 taf=1000000000000001
(XEN) mm.c:2985:d0 Error while pinning mfn 81de

Setting the range in E820 to E280_UNUSABLE seems ambigous as
this is the same type that gets used for memory to be used only
as guest memory (using dom0_mem=).

To avoid this, the clipped memory should be dropped completely
from E820 (as it is done if setting the memory type fails).
This is currently restricted to only the case of memory not
coverable by MTRRs (which could be tested). Maybe it should
be done in other cases, too.

BugLink: http://bugs.launchpad.net/bugs/1111470

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/arch/x86/e820.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 55fe0d6..8dfe427 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -372,7 +372,7 @@ static unsigned long __init find_max_pfn(void)
     return max_pfn;
 }
 
-static void __init clip_to_limit(uint64_t limit, char *warnmsg)
+static void __init clip_to_limit(uint64_t limit, char *warnmsg, int drop)
 {
     int i;
     char _warnmsg[160];
@@ -394,7 +394,8 @@ static void __init clip_to_limit(uint64_t limit, char *warnmsg)
             uint64_t, old_limit, e820.map[i].addr + e820.map[i].size);
 
         /* We try to convert clipped RAM areas to E820_UNUSABLE. */
-        if ( e820_change_range_type(&e820, max(e820.map[i].addr, limit),
+        if ( !drop &&
+             e820_change_range_type(&e820, max(e820.map[i].addr, limit),
                                     e820.map[i].addr + e820.map[i].size,
                                     E820_RAM, E820_UNUSABLE) )
             continue;
@@ -524,7 +525,7 @@ static void __init machine_specific_memory_setup(
     (void)copy_e820_map(raw, nr);
 
     if ( opt_mem )
-        clip_to_limit(opt_mem, NULL);
+        clip_to_limit(opt_mem, NULL, 0);
 
     if ( opt_availmem )
     {
@@ -534,7 +535,7 @@ static void __init machine_specific_memory_setup(
         if ( size > opt_availmem )
             clip_to_limit(
                 e820.map[i-1].addr + e820.map[i-1].size - (size-opt_availmem),
-                NULL);
+                NULL, 0);
     }
 
     mpt_limit = ((RDWR_MPT_VIRT_END - RDWR_MPT_VIRT_START)
@@ -545,13 +546,13 @@ static void __init machine_specific_memory_setup(
         mpt_limit = ro_mpt_limit;
     clip_to_limit(mpt_limit,
                   "Only the first %lu GB of the physical "
-                  "memory map can be accessed by Xen.");
+                  "memory map can be accessed by Xen.", 0);
 
     reserve_dmi_region();
 
     top_of_ram = mtrr_top_of_ram();
     if ( top_of_ram )
-        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.");
+        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.", 1);
 }
 
 /* This function relies on the passed in e820->map[] being sorted. */
-- 
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 Thu Feb 14 17:14:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:14: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 1U62O5-0000AQ-VT; Thu, 14 Feb 2013 17:14:21 +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 1U62O5-0000AC-4r
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:14:21 +0000
Received: from [85.158.139.211:7008] by server-12.bemta-5.messagelabs.com id
	A3/2B-20195-C6B1D115; Thu, 14 Feb 2013 17:14:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360862059!19798384!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjgyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjgyNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27437 invoked from network); 14 Feb 2013 17:14:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 17:14:19 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pFTU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-027.pools.arcor-ip.net [84.57.80.27])
	by smtp.strato.de (jored mo15) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U028fdp1EGKxpN
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 18:14:19 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B43731863F
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 18:14:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0f9c7503650fa1b1103b769e1129d66ff614b2ad
Message-Id: <0f9c7503650fa1b1103b.1360862057@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Thu, 14 Feb 2013 18:14:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xend: Only add cpuid and cpuid_check to
	sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jim Fehlig <jfehlig@suse.com>
# Date 1360861948 -3600
# Node ID 0f9c7503650fa1b1103b769e1129d66ff614b2ad
# Parent  cffb489a6df37d8d114e7d2d53a7a85d14e8f968
tools/xend: Only add cpuid and cpuid_check to sexpr once

When converting a XendConfig object to sexpr, cpuid and cpuid_check
were being emitted twice in the resulting sexpr.  The first conversion
writes incorrect sexpr, causing parsing of the sexpr to fail when xend
is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
are read and parsed.

This patch skips the first conversion, and uses only the custom
cpuid{_check} conversion methods called later.  It is not pretty, but
is the least invasive fix in this complex code.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r cffb489a6df3 -r 0f9c7503650f tools/python/xen/xend/XendConfig.py
--- a/tools/python/xen/xend/XendConfig.py
+++ b/tools/python/xen/xend/XendConfig.py
@@ -1124,6 +1124,10 @@ class XendConfig(dict):
         else:
             for name, typ in XENAPI_CFG_TYPES.items():
                 if name in self and self[name] not in (None, []):
+                    # Skip cpuid and cpuid_check.  Custom conversion
+                    # methods for these are called below.
+                    if name in ("cpuid", "cpuid_check"):
+                        continue
                     if typ == dict:
                         s = self[name].items()
                     elif typ == list:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:14:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:14: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 1U62O5-0000AQ-VT; Thu, 14 Feb 2013 17:14:21 +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 1U62O5-0000AC-4r
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:14:21 +0000
Received: from [85.158.139.211:7008] by server-12.bemta-5.messagelabs.com id
	A3/2B-20195-C6B1D115; Thu, 14 Feb 2013 17:14:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360862059!19798384!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjgyNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NjgyNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27437 invoked from network); 14 Feb 2013 17:14:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 17:14:19 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2c7pFTU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-027.pools.arcor-ip.net [84.57.80.27])
	by smtp.strato.de (jored mo15) (RZmta 31.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U028fdp1EGKxpN
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 18:14:19 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B43731863F
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 18:14:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0f9c7503650fa1b1103b769e1129d66ff614b2ad
Message-Id: <0f9c7503650fa1b1103b.1360862057@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Thu, 14 Feb 2013 18:14:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xend: Only add cpuid and cpuid_check to
	sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jim Fehlig <jfehlig@suse.com>
# Date 1360861948 -3600
# Node ID 0f9c7503650fa1b1103b769e1129d66ff614b2ad
# Parent  cffb489a6df37d8d114e7d2d53a7a85d14e8f968
tools/xend: Only add cpuid and cpuid_check to sexpr once

When converting a XendConfig object to sexpr, cpuid and cpuid_check
were being emitted twice in the resulting sexpr.  The first conversion
writes incorrect sexpr, causing parsing of the sexpr to fail when xend
is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
are read and parsed.

This patch skips the first conversion, and uses only the custom
cpuid{_check} conversion methods called later.  It is not pretty, but
is the least invasive fix in this complex code.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r cffb489a6df3 -r 0f9c7503650f tools/python/xen/xend/XendConfig.py
--- a/tools/python/xen/xend/XendConfig.py
+++ b/tools/python/xen/xend/XendConfig.py
@@ -1124,6 +1124,10 @@ class XendConfig(dict):
         else:
             for name, typ in XENAPI_CFG_TYPES.items():
                 if name in self and self[name] not in (None, []):
+                    # Skip cpuid and cpuid_check.  Custom conversion
+                    # methods for these are called below.
+                    if name in ("cpuid", "cpuid_check"):
+                        continue
                     if typ == dict:
                         s = self[name].items()
                     elif typ == list:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 17:30:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62dV-0000qF-Nl; Thu, 14 Feb 2013 17:30:17 +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 1U62dS-0000qA-Gn
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:30:16 +0000
Received: from [85.158.138.51:31893] by server-13.bemta-3.messagelabs.com id
	D1/19-20653-52F1D115; Thu, 14 Feb 2013 17:30:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360863011!18710477!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17975 invoked from network); 14 Feb 2013 17:30:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7169416"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dO-0001uz-21;
	Thu, 14 Feb 2013 17:30:10 +0000
Date: Thu, 14 Feb 2013 17:30:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 0/5] xen: ARM HDLCD video 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 all,
these are the remaining unapplied patches of the ARM HDLCD patch series.


Changes in v7:
- rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0;
- turn more printk and panic into early_printk and early_panic.

Changes in v6:
- rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795;
- remove useless initializations to NULL in lfb_init;
- more compact checks in lfb_init.


Changes in v5:
- move the barriers outside the loop in flush_xen_data_tlb_range_va;
- move out of "introduce early_ioremap" any changes related to
flush_xen_data_tlb_range_va and PAGE masks;
- remove lfb_alloc and the now unused __initdata variables;
- fix indentation and long lines;
- reword commit message of "move setup_mm right after setup_pagetables";
- turn printk in setup_mm into an early_printk in setup_mm;
- actually include the Makefile for xen/arch/arm/platforms.


Changes in v4:
- rename flush_xen_data_tlb_range to flush_xen_data_tlb_range_va;
- replace all the calls to flush_xen_data_tlb_va, with calls to
flush_xen_data_tlb_range_va;
- flush the entire 2MB mapping at BOOT_MISC_VIRT_START rather than just
the first 4k;
- remove flush_xen_data_tlb_va;
- fix indentation;
- rename EARLY_VMAP_START/END to EARLY_VMAP_VIRT_START/END;
- mark early_ioremap as __init;
- reduce the amount of casts in early_ioremap;
- squash the vesa.c changes into this patch;
- rename fb* to lfb*;
- pass a pointer to fb_init;
- use %u for screen dimensions;
- specify loglevel in printk;
- call fb_free on error in fb_alloc;
- no __init on declarations;
- do not break messages to fit 80 columns;
- remove "preserve DTB mappings";
- introduce a new "move setup_mm right after setup_pagetables" patch;
- stop iterating over the DT nodes in device_tree_for_each_node if
func returns a value != 0;
- return 1 from _find_compatible_node when a node is found;
- move the wait loop and the syscfg cfgctrl write into a separate
function;
- fix comments;
- define all registers in write;
- move platform_vexpress.c to platforms/vexpress.c;
- move platform_vexpress.h to arm-arm/platforms/vexpress.h;
- use a lookup table to set the color masks;
- fix indentation;
- make sure mode_string is not NULL and is not bigger than 16 chars
before continuing;
- introduce 2 separate error messages for !hdlcd_start and
!framebuffer_start at the beginning of video_init;
- mark get_color_masks and set_pixclock as __init;
- check that we are running on a vexpress machine before calling
vexpress_syscfg.


Changes in v3:
- rename fb_cr to fb_carriage_return.


Changes in v2:
- rebase on latest xen-unstable;
- add support for multiple resolutions;
- add support to dynamically change the OSC5 motherboard timer;
- add the patch "preserve DTB mappings".

Stefano Stabellini (5):
      xen: introduce a generic framebuffer driver
      xen/arm: move setup_mm right after setup_pagetables
      xen/device_tree: introduce find_compatible_node
      xen/arm: introduce vexpress_syscfg
      xen/arm: introduce a driver for the ARM HDLCD controller

 xen/arch/arm/Makefile                    |    1 +
 xen/arch/arm/Rules.mk                    |    1 +
 xen/arch/arm/arm32/mode_switch.S         |    2 +-
 xen/arch/arm/platforms/Makefile          |    1 +
 xen/arch/arm/platforms/vexpress.c        |  100 +++++++++++
 xen/arch/arm/setup.c                     |   14 +-
 xen/common/device_tree.c                 |   56 ++++++-
 xen/common/page_alloc.c                  |    6 -
 xen/drivers/video/Makefile               |    2 +
 xen/drivers/video/arm_hdlcd.c            |  276 ++++++++++++++++++++++++++++++
 xen/drivers/video/lfb.c                  |  183 ++++++++++++++++++++
 xen/drivers/video/lfb.h                  |   46 +++++
 xen/drivers/video/modelines.h            |   77 +++++++++
 xen/drivers/video/vesa.c                 |  177 +++-----------------
 xen/include/asm-arm/config.h             |    2 +
 xen/include/asm-arm/platform_vexpress.h  |   17 --
 xen/include/asm-arm/platforms/vexpress.h |   40 +++++
 xen/include/xen/device_tree.h            |    3 +
 18 files changed, 817 insertions(+), 187 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 Feb 14 17:30:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62dV-0000qF-Nl; Thu, 14 Feb 2013 17:30:17 +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 1U62dS-0000qA-Gn
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:30:16 +0000
Received: from [85.158.138.51:31893] by server-13.bemta-3.messagelabs.com id
	D1/19-20653-52F1D115; Thu, 14 Feb 2013 17:30:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1360863011!18710477!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17975 invoked from network); 14 Feb 2013 17:30:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7169416"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dO-0001uz-21;
	Thu, 14 Feb 2013 17:30:10 +0000
Date: Thu, 14 Feb 2013 17:30:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v7 0/5] xen: ARM HDLCD video 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 all,
these are the remaining unapplied patches of the ARM HDLCD patch series.


Changes in v7:
- rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0;
- turn more printk and panic into early_printk and early_panic.

Changes in v6:
- rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795;
- remove useless initializations to NULL in lfb_init;
- more compact checks in lfb_init.


Changes in v5:
- move the barriers outside the loop in flush_xen_data_tlb_range_va;
- move out of "introduce early_ioremap" any changes related to
flush_xen_data_tlb_range_va and PAGE masks;
- remove lfb_alloc and the now unused __initdata variables;
- fix indentation and long lines;
- reword commit message of "move setup_mm right after setup_pagetables";
- turn printk in setup_mm into an early_printk in setup_mm;
- actually include the Makefile for xen/arch/arm/platforms.


Changes in v4:
- rename flush_xen_data_tlb_range to flush_xen_data_tlb_range_va;
- replace all the calls to flush_xen_data_tlb_va, with calls to
flush_xen_data_tlb_range_va;
- flush the entire 2MB mapping at BOOT_MISC_VIRT_START rather than just
the first 4k;
- remove flush_xen_data_tlb_va;
- fix indentation;
- rename EARLY_VMAP_START/END to EARLY_VMAP_VIRT_START/END;
- mark early_ioremap as __init;
- reduce the amount of casts in early_ioremap;
- squash the vesa.c changes into this patch;
- rename fb* to lfb*;
- pass a pointer to fb_init;
- use %u for screen dimensions;
- specify loglevel in printk;
- call fb_free on error in fb_alloc;
- no __init on declarations;
- do not break messages to fit 80 columns;
- remove "preserve DTB mappings";
- introduce a new "move setup_mm right after setup_pagetables" patch;
- stop iterating over the DT nodes in device_tree_for_each_node if
func returns a value != 0;
- return 1 from _find_compatible_node when a node is found;
- move the wait loop and the syscfg cfgctrl write into a separate
function;
- fix comments;
- define all registers in write;
- move platform_vexpress.c to platforms/vexpress.c;
- move platform_vexpress.h to arm-arm/platforms/vexpress.h;
- use a lookup table to set the color masks;
- fix indentation;
- make sure mode_string is not NULL and is not bigger than 16 chars
before continuing;
- introduce 2 separate error messages for !hdlcd_start and
!framebuffer_start at the beginning of video_init;
- mark get_color_masks and set_pixclock as __init;
- check that we are running on a vexpress machine before calling
vexpress_syscfg.


Changes in v3:
- rename fb_cr to fb_carriage_return.


Changes in v2:
- rebase on latest xen-unstable;
- add support for multiple resolutions;
- add support to dynamically change the OSC5 motherboard timer;
- add the patch "preserve DTB mappings".

Stefano Stabellini (5):
      xen: introduce a generic framebuffer driver
      xen/arm: move setup_mm right after setup_pagetables
      xen/device_tree: introduce find_compatible_node
      xen/arm: introduce vexpress_syscfg
      xen/arm: introduce a driver for the ARM HDLCD controller

 xen/arch/arm/Makefile                    |    1 +
 xen/arch/arm/Rules.mk                    |    1 +
 xen/arch/arm/arm32/mode_switch.S         |    2 +-
 xen/arch/arm/platforms/Makefile          |    1 +
 xen/arch/arm/platforms/vexpress.c        |  100 +++++++++++
 xen/arch/arm/setup.c                     |   14 +-
 xen/common/device_tree.c                 |   56 ++++++-
 xen/common/page_alloc.c                  |    6 -
 xen/drivers/video/Makefile               |    2 +
 xen/drivers/video/arm_hdlcd.c            |  276 ++++++++++++++++++++++++++++++
 xen/drivers/video/lfb.c                  |  183 ++++++++++++++++++++
 xen/drivers/video/lfb.h                  |   46 +++++
 xen/drivers/video/modelines.h            |   77 +++++++++
 xen/drivers/video/vesa.c                 |  177 +++-----------------
 xen/include/asm-arm/config.h             |    2 +
 xen/include/asm-arm/platform_vexpress.h  |   17 --
 xen/include/asm-arm/platforms/vexpress.h |   40 +++++
 xen/include/xen/device_tree.h            |    3 +
 18 files changed, 817 insertions(+), 187 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 Feb 14 17:31:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:31: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 1U62eZ-0000xD-7q; Thu, 14 Feb 2013 17:31: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 1U62eY-0000x1-3y
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:22 +0000
Received: from [85.158.143.35:34417] by server-2.bemta-4.messagelabs.com id
	19/2C-01597-96F1D115; Thu, 14 Feb 2013 17:31:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19208 invoked from network); 14 Feb 2013 17:30:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538905"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-Bu;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:40 +0000
Message-ID: <1360863042-19845-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 3/5] xen/device_tree: introduce
	find_compatible_node
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 find_compatible_node function that can be used by device
drivers to find the node corresponding to their device in the device
tree.

Initialize device_tree_flattened early in start_xen, so that it is
available before setup_mm. Get rid of fdt in the process.

Also add device_tree_node_compatible to device_tree.h, that is currently
missing.

Changes in v4:
- stop iterating over the DT nodes in device_tree_for_each_node if func
returns a value != 0;
- return 1 from _find_compatible_node when a node is found.

Changes in v2:
- remove fdt;
- return early from _find_compatible_node, if a node has already been
found.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c          |    7 ++---
 xen/common/device_tree.c      |   56 +++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/device_tree.h |    3 ++
 3 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c568be5..52d2e7a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -333,7 +333,6 @@ void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long atag_paddr,
                       unsigned long cpuid)
 {
-    void *fdt;
     size_t fdt_size;
     int cpus, i;
 
@@ -341,12 +340,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     smp_clear_cpu_maps();
 
-    fdt = (void *)BOOT_MISC_VIRT_START
+    device_tree_flattened = (void *)BOOT_MISC_VIRT_START
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
-    fdt_size = device_tree_early_init(fdt);
+    fdt_size = device_tree_early_init(device_tree_flattened);
 
     cpus = smp_get_max_cpus();
-    cmdline_parse(device_tree_bootargs(fdt));
+    cmdline_parse(device_tree_bootargs(device_tree_flattened));
 
     setup_pagetables(boot_phys_offset, get_xen_paddr());
     setup_mm(atag_paddr, fdt_size);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 260c2d4..cef4b88 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -140,7 +140,7 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
  * 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.
+ * returns a value different from 0, that value is returned immediately.
  */
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data)
@@ -169,12 +169,64 @@ int device_tree_for_each_node(const void *fdt,
 
         ret = func(fdt, node, name, depth,
                    address_cells[depth-1], size_cells[depth-1], data);
-        if ( ret < 0 )
+        if ( ret != 0 )
             return ret;
     }
     return 0;
 }
 
+struct find_compat {
+    const char *compatible;
+    int found;
+    int node;
+    int depth;
+    u32 address_cells;
+    u32 size_cells;
+};
+
+static int _find_compatible_node(const void *fdt,
+                             int node, const char *name, int depth,
+                             u32 address_cells, u32 size_cells,
+                             void *data)
+{
+    struct find_compat *c = (struct find_compat *) data;
+
+    if (  c->found  )
+        return 1;
+
+    if ( device_tree_node_compatible(fdt, node, c->compatible) )
+    {
+        c->found = 1;
+        c->node = node;
+        c->depth = depth;
+        c->address_cells = address_cells;
+        c->size_cells = size_cells;
+        return 1;
+    }
+    return 0;
+}
+ 
+int find_compatible_node(const char *compatible, int *node, int *depth,
+                u32 *address_cells, u32 *size_cells)
+{
+    int ret;
+    struct find_compat c;
+    c.compatible = compatible;
+    c.found = 0;
+
+    ret = device_tree_for_each_node(device_tree_flattened, _find_compatible_node, &c);
+    if ( !c.found )
+        return ret;
+    else
+    {
+        *node = c.node;
+        *depth = c.depth;
+        *address_cells = c.address_cells;
+        *size_cells = c.size_cells;
+        return 1;
+    }
+}
+
 /**
  * device_tree_bootargs - return the bootargs (the Xen command line)
  * @fdt flat device tree.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 52ef258..1d04e4f 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -68,6 +68,9 @@ 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);
+bool_t device_tree_node_compatible(const void *fdt, int node, const char *match);
+int find_compatible_node(const char *compatible, int *node, int *depth,
+                u32 *address_cells, u32 *size_cells);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 const char *device_tree_bootargs(const void *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 Thu Feb 14 17:31:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:31: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 1U62eZ-0000xD-7q; Thu, 14 Feb 2013 17:31: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 1U62eY-0000x1-3y
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:22 +0000
Received: from [85.158.143.35:34417] by server-2.bemta-4.messagelabs.com id
	19/2C-01597-96F1D115; Thu, 14 Feb 2013 17:31:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19208 invoked from network); 14 Feb 2013 17:30:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538905"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-Bu;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:40 +0000
Message-ID: <1360863042-19845-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 3/5] xen/device_tree: introduce
	find_compatible_node
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 find_compatible_node function that can be used by device
drivers to find the node corresponding to their device in the device
tree.

Initialize device_tree_flattened early in start_xen, so that it is
available before setup_mm. Get rid of fdt in the process.

Also add device_tree_node_compatible to device_tree.h, that is currently
missing.

Changes in v4:
- stop iterating over the DT nodes in device_tree_for_each_node if func
returns a value != 0;
- return 1 from _find_compatible_node when a node is found.

Changes in v2:
- remove fdt;
- return early from _find_compatible_node, if a node has already been
found.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c          |    7 ++---
 xen/common/device_tree.c      |   56 +++++++++++++++++++++++++++++++++++++++-
 xen/include/xen/device_tree.h |    3 ++
 3 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c568be5..52d2e7a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -333,7 +333,6 @@ void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long atag_paddr,
                       unsigned long cpuid)
 {
-    void *fdt;
     size_t fdt_size;
     int cpus, i;
 
@@ -341,12 +340,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     smp_clear_cpu_maps();
 
-    fdt = (void *)BOOT_MISC_VIRT_START
+    device_tree_flattened = (void *)BOOT_MISC_VIRT_START
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
-    fdt_size = device_tree_early_init(fdt);
+    fdt_size = device_tree_early_init(device_tree_flattened);
 
     cpus = smp_get_max_cpus();
-    cmdline_parse(device_tree_bootargs(fdt));
+    cmdline_parse(device_tree_bootargs(device_tree_flattened));
 
     setup_pagetables(boot_phys_offset, get_xen_paddr());
     setup_mm(atag_paddr, fdt_size);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 260c2d4..cef4b88 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -140,7 +140,7 @@ u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
  * 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.
+ * returns a value different from 0, that value is returned immediately.
  */
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data)
@@ -169,12 +169,64 @@ int device_tree_for_each_node(const void *fdt,
 
         ret = func(fdt, node, name, depth,
                    address_cells[depth-1], size_cells[depth-1], data);
-        if ( ret < 0 )
+        if ( ret != 0 )
             return ret;
     }
     return 0;
 }
 
+struct find_compat {
+    const char *compatible;
+    int found;
+    int node;
+    int depth;
+    u32 address_cells;
+    u32 size_cells;
+};
+
+static int _find_compatible_node(const void *fdt,
+                             int node, const char *name, int depth,
+                             u32 address_cells, u32 size_cells,
+                             void *data)
+{
+    struct find_compat *c = (struct find_compat *) data;
+
+    if (  c->found  )
+        return 1;
+
+    if ( device_tree_node_compatible(fdt, node, c->compatible) )
+    {
+        c->found = 1;
+        c->node = node;
+        c->depth = depth;
+        c->address_cells = address_cells;
+        c->size_cells = size_cells;
+        return 1;
+    }
+    return 0;
+}
+ 
+int find_compatible_node(const char *compatible, int *node, int *depth,
+                u32 *address_cells, u32 *size_cells)
+{
+    int ret;
+    struct find_compat c;
+    c.compatible = compatible;
+    c.found = 0;
+
+    ret = device_tree_for_each_node(device_tree_flattened, _find_compatible_node, &c);
+    if ( !c.found )
+        return ret;
+    else
+    {
+        *node = c.node;
+        *depth = c.depth;
+        *address_cells = c.address_cells;
+        *size_cells = c.size_cells;
+        return 1;
+    }
+}
+
 /**
  * device_tree_bootargs - return the bootargs (the Xen command line)
  * @fdt flat device tree.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 52ef258..1d04e4f 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -68,6 +68,9 @@ 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);
+bool_t device_tree_node_compatible(const void *fdt, int node, const char *match);
+int find_compatible_node(const char *compatible, int *node, int *depth,
+                u32 *address_cells, u32 *size_cells);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 const char *device_tree_bootargs(const void *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 Thu Feb 14 17:31:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:31: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 1U62em-000108-Qn; Thu, 14 Feb 2013 17:31: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 1U62ek-0000zS-Rc
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:35 +0000
Received: from [85.158.143.35:34843] by server-1.bemta-4.messagelabs.com id
	1C/A3-08839-67F1D115; Thu, 14 Feb 2013 17:31:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19150 invoked from network); 14 Feb 2013 17:30:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538904"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-A6;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:39 +0000
Message-ID: <1360863042-19845-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 2/5] xen/arm: move setup_mm right after
	setup_pagetables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 moment we destroy the DTB mappings we have in setup_pagetables
and we restore them only in setup_mm.

Move setup_mm right after setup_pagetables.
This ensures we have a valid DTB mapping while running the subsequent
initialization code.

Changes in v7:
- turn more printk's into early_printk.

Changes in v5:
- reword commit message;
- turn printk in setup_mm into an early_printk.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/setup.c    |    7 +++----
 xen/common/page_alloc.c |    6 ------
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..c568be5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -246,11 +246,11 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     } while ( xenheap_pages > 128<<(20-PAGE_SHIFT) );
 
     if ( ! e )
-        panic("Not not enough space for xenheap\n");
+        early_panic("Not not enough space for xenheap\n");
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -349,6 +349,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     cmdline_parse(device_tree_bootargs(fdt));
 
     setup_pagetables(boot_phys_offset, get_xen_paddr());
+    setup_mm(atag_paddr, fdt_size);
 
 #ifdef EARLY_UART_ADDRESS
     /* TODO Need to get device tree or command line for UART address */
@@ -366,8 +367,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    setup_mm(atag_paddr, fdt_size);
-
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
     printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 6b8bc39..6c2215b 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -182,12 +182,6 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
         else if ( *p != '\0' )
             break;
 
-        if ( bad_epfn == bad_spfn )
-            printk("Marking page %lx as bad\n", bad_spfn);
-        else
-            printk("Marking pages %lx through %lx as bad\n",
-                   bad_spfn, bad_epfn);
-
         bootmem_region_zap(bad_spfn, bad_epfn+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 Thu Feb 14 17:31:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:31: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 1U62em-000108-Qn; Thu, 14 Feb 2013 17:31: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 1U62ek-0000zS-Rc
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:35 +0000
Received: from [85.158.143.35:34843] by server-1.bemta-4.messagelabs.com id
	1C/A3-08839-67F1D115; Thu, 14 Feb 2013 17:31:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19150 invoked from network); 14 Feb 2013 17:30:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538904"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-A6;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:39 +0000
Message-ID: <1360863042-19845-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 2/5] xen/arm: move setup_mm right after
	setup_pagetables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 moment we destroy the DTB mappings we have in setup_pagetables
and we restore them only in setup_mm.

Move setup_mm right after setup_pagetables.
This ensures we have a valid DTB mapping while running the subsequent
initialization code.

Changes in v7:
- turn more printk's into early_printk.

Changes in v5:
- reword commit message;
- turn printk in setup_mm into an early_printk.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/setup.c    |    7 +++----
 xen/common/page_alloc.c |    6 ------
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e1ab7f6..c568be5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -246,11 +246,11 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     } while ( xenheap_pages > 128<<(20-PAGE_SHIFT) );
 
     if ( ! e )
-        panic("Not not enough space for xenheap\n");
+        early_panic("Not not enough space for xenheap\n");
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -349,6 +349,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     cmdline_parse(device_tree_bootargs(fdt));
 
     setup_pagetables(boot_phys_offset, get_xen_paddr());
+    setup_mm(atag_paddr, fdt_size);
 
 #ifdef EARLY_UART_ADDRESS
     /* TODO Need to get device tree or command line for UART address */
@@ -366,8 +367,6 @@ void __init start_xen(unsigned long boot_phys_offset,
     set_current((struct vcpu *)0xfffff000); /* debug sanity */
     idle_vcpu[0] = current;
 
-    setup_mm(atag_paddr, fdt_size);
-
     /* Setup Hyp vector base */
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
     printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 6b8bc39..6c2215b 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -182,12 +182,6 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
         else if ( *p != '\0' )
             break;
 
-        if ( bad_epfn == bad_spfn )
-            printk("Marking page %lx as bad\n", bad_spfn);
-        else
-            printk("Marking pages %lx through %lx as bad\n",
-                   bad_spfn, bad_epfn);
-
         bootmem_region_zap(bad_spfn, bad_epfn+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 Thu Feb 14 17:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:31: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 1U62eo-00010W-8B; Thu, 14 Feb 2013 17:31: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 1U62en-000105-2F
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:37 +0000
Received: from [85.158.143.35:27546] by server-2.bemta-4.messagelabs.com id
	CA/5C-01597-87F1D115; Thu, 14 Feb 2013 17:31:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19292 invoked from network); 14 Feb 2013 17:30:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538907"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-ED;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:42 +0000
Message-ID: <1360863042-19845-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 5/5] xen/arm: introduce a driver for the ARM
	HDLCD controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the screen resolution setting from device tree, find the
corresponding modeline in a small table of standard video modes, set the
hardware accordingly.

Use vexpress_syscfg to configure the pixel clock.

Use the generic framebuffer functions to print on the screen.

Changes in v4:
- use a lookup table to set the color masks;
- fix indentation;
- make sure mode_string is not NULL and is not bigger than 16 chars
before continuing;
- introduce 2 separate error messages for !hdlcd_start and
!framebuffer_start at the beginning of video_init;
- mark get_color_masks and set_pixclock as __init;
- check that we are running on a vexpress machine before calling
vexpress_syscfg.

Changes in v2:
- read mode from DT;
- support multiple resolutions;
- use vexpress_syscfg to set the pixclock.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Rules.mk         |    1 +
 xen/drivers/video/Makefile    |    1 +
 xen/drivers/video/arm_hdlcd.c |  276 +++++++++++++++++++++++++++++++++++++++++
 xen/drivers/video/modelines.h |   77 ++++++++++++
 xen/include/asm-arm/config.h  |    2 +
 5 files changed, 357 insertions(+), 0 deletions(-)
 create mode 100644 xen/drivers/video/arm_hdlcd.c
 create mode 100644 xen/drivers/video/modelines.h

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 5b5768a..0843e50 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -8,6 +8,7 @@
 
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
+HAS_ARM_HDLCD := y
 
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
 CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 77f9d5d..a756292 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,3 +4,4 @@ obj-$(HAS_VIDEO) += font_8x16.o
 obj-$(HAS_VIDEO) += font_8x8.o
 obj-$(HAS_VIDEO) += lfb.o
 obj-$(HAS_VGA) += vesa.o
+obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
new file mode 100644
index 0000000..45f9d64
--- /dev/null
+++ b/xen/drivers/video/arm_hdlcd.c
@@ -0,0 +1,276 @@
+/*
+ * xen/drivers/video/arm_hdlcd.c
+ *
+ * Driver for ARM HDLCD Controller
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Copyright (c) 2013 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/delay.h>
+#include <asm/types.h>
+#include <asm/platforms/vexpress.h>
+#include <xen/config.h>
+#include <xen/device_tree.h>
+#include <xen/libfdt/libfdt.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include "font.h"
+#include "lfb.h"
+#include "modelines.h"
+
+#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
+
+#define HDLCD_INTMASK       (0x18/4)
+#define HDLCD_FBBASE        (0x100/4)
+#define HDLCD_LINELENGTH    (0x104/4)
+#define HDLCD_LINECOUNT     (0x108/4)
+#define HDLCD_LINEPITCH     (0x10C/4)
+#define HDLCD_BUS           (0x110/4)
+#define HDLCD_VSYNC         (0x200/4)
+#define HDLCD_VBACK         (0x204/4)
+#define HDLCD_VDATA         (0x208/4)
+#define HDLCD_VFRONT        (0x20C/4)
+#define HDLCD_HSYNC         (0x210/4)
+#define HDLCD_HBACK         (0x214/4)
+#define HDLCD_HDATA         (0x218/4)
+#define HDLCD_HFRONT        (0x21C/4)
+#define HDLCD_POLARITIES    (0x220/4)
+#define HDLCD_COMMAND       (0x230/4)
+#define HDLCD_PF            (0x240/4)
+#define HDLCD_RED           (0x244/4)
+#define HDLCD_GREEN         (0x248/4)
+#define HDLCD_BLUE          (0x24C/4)
+
+struct color_masks {
+    int red_shift;
+    int red_size;
+    int green_shift;
+    int green_size;
+    int blue_shift;
+    int blue_size;
+};
+
+struct pixel_colors {
+    const char* bpp;
+    struct color_masks colors;
+};
+
+struct pixel_colors __initdata colors[] = {
+    { "16", { 0, 5, 11, 5, 6, 5 } },
+    { "24", { 0, 8, 16, 8, 8, 8 } },
+    { "32", { 0, 8, 16, 8, 8, 8 } },
+};
+
+static void vga_noop_puts(const char *s) {}
+void (*video_puts)(const char *) = vga_noop_puts;
+
+static void hdlcd_flush(void)
+{
+    dsb();
+}
+
+static int __init get_color_masks(const char* bpp, struct color_masks **masks)
+{
+    int i;
+    for ( i = 0; i < ARRAY_SIZE(colors); i++ )
+    {
+        if ( !strncmp(colors[i].bpp, bpp, 2) )
+        {
+            *masks = &colors[i].colors;
+            return 0;
+        }
+    }
+    return -1;
+}
+
+static void __init set_pixclock(uint32_t pixclock)
+{
+    if ( device_tree_node_compatible(device_tree_flattened, 0, "arm,vexpress") )
+            vexpress_syscfg(1, V2M_SYS_CFG_OSC_FUNC,
+                            V2M_SYS_CFG_OSC5, &pixclock);
+}
+
+void __init video_init(void)
+{
+    int node, depth;
+    u32 address_cells, size_cells;
+    struct lfb_prop lfbp;
+    unsigned char *lfb;
+    paddr_t hdlcd_start, hdlcd_size;
+    paddr_t framebuffer_start, framebuffer_size;
+    const struct fdt_property *prop;
+    const u32 *cell;
+    const char *mode_string;
+    char _mode_string[16];
+    int bytes_per_pixel = 4;
+    struct color_masks *c = NULL;
+    struct modeline *videomode = NULL;
+    int i;
+
+    if ( find_compatible_node("arm,hdlcd", &node, &depth,
+                &address_cells, &size_cells) <= 0 )
+        return;
+
+    prop = fdt_get_property(device_tree_flattened, node, "reg", NULL);
+    if ( !prop )
+        return;
+
+    cell = (const u32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells,
+            &hdlcd_start, &hdlcd_size); 
+
+    prop = fdt_get_property(device_tree_flattened, node, "framebuffer", NULL);
+    if ( !prop )
+        return;
+
+    cell = (const u32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells,
+            &framebuffer_start, &framebuffer_size); 
+
+    if ( !hdlcd_start )
+    {
+        printk(KERN_ERR "HDLCD address missing from device tree, disabling driver\n");
+        return;
+    }
+
+    if ( !hdlcd_start || !framebuffer_start )
+    {
+        printk(KERN_ERR "HDLCD: framebuffer address missing from device tree, disabling driver\n");
+        return;
+    }
+
+    mode_string = fdt_getprop(device_tree_flattened, node, "mode", NULL);
+    if ( !mode_string )
+    {
+        get_color_masks("32", &c);
+        memcpy(_mode_string, "1280x1024@60", strlen("1280x1024@60") + 1);
+        bytes_per_pixel = 4;
+    }
+    else if ( strlen(mode_string) < strlen("800x600@60") ||
+            strlen(mode_string) > sizeof(_mode_string) - 1 )
+    {
+        printk(KERN_ERR "HDLCD: invalid modeline=%s\n", mode_string);
+        return;
+    } else {
+        char *s = strchr(mode_string, '-');
+        if ( !s )
+        {
+            printk(KERN_INFO "HDLCD: bpp not found in modeline %s, assume 32 bpp\n",
+                    mode_string);
+            get_color_masks("32", &c);
+            memcpy(_mode_string, mode_string, strlen(mode_string) + 1);
+            bytes_per_pixel = 4;
+        } else {
+            if ( strlen(s) < 6 )
+            {
+                printk(KERN_ERR "HDLCD: invalid mode %s\n", mode_string);
+                return;
+            }
+            s++;
+            if ( get_color_masks(s, &c) < 0 )
+            {
+                printk(KERN_WARNING "HDLCD: unsupported bpp %s\n", s);
+                return;
+            }
+            bytes_per_pixel = simple_strtoll(s, NULL, 10) / 8;
+        }
+        i = s - mode_string - 1;
+        memcpy(_mode_string, mode_string, i);
+        memcpy(_mode_string + i, mode_string + i + 3, 4);
+    }
+
+    for ( i = 0; i < ARRAY_SIZE(videomodes); i++ ) {
+        if ( !strcmp(_mode_string, videomodes[i].mode) )
+        {
+            videomode = &videomodes[i];
+            break;
+        }
+    }
+    if ( !videomode )
+    {
+        printk(KERN_WARNING "HDLCD: unsupported videomode %s\n", _mode_string);
+        return;
+    }
+
+    if ( framebuffer_size < bytes_per_pixel * videomode->xres * videomode->yres )
+    {
+        printk(KERN_ERR "HDLCD: the framebuffer is too small, disabling the HDLCD driver\n");
+        return;
+    }
+
+    printk(KERN_INFO "Initializing HDLCD driver\n");
+
+    lfb = early_ioremap(framebuffer_start, framebuffer_size, DEV_WC);
+    if ( !lfb )
+    {
+        printk(KERN_ERR "Couldn't map the framebuffer\n");
+        return;
+    }
+    memset(lfb, 0x00, bytes_per_pixel * videomode->xres * videomode->yres);
+
+    /* uses FIXMAP_MISC */
+    set_pixclock(videomode->pixclock);
+
+    set_fixmap(FIXMAP_MISC, hdlcd_start >> PAGE_SHIFT, DEV_SHARED);
+    HDLCD[HDLCD_COMMAND] = 0;
+
+    HDLCD[HDLCD_LINELENGTH] = videomode->xres * bytes_per_pixel;
+    HDLCD[HDLCD_LINECOUNT] = videomode->yres - 1;
+    HDLCD[HDLCD_LINEPITCH] = videomode->xres * bytes_per_pixel;
+    HDLCD[HDLCD_PF] = ((bytes_per_pixel - 1) << 3);
+    HDLCD[HDLCD_INTMASK] = 0;
+    HDLCD[HDLCD_FBBASE] = framebuffer_start;
+    HDLCD[HDLCD_BUS] = 0xf00 | (1 << 4);
+    HDLCD[HDLCD_VBACK] = videomode->vback - 1;
+    HDLCD[HDLCD_VSYNC] = videomode->vsync - 1;
+    HDLCD[HDLCD_VDATA] = videomode->yres - 1;
+    HDLCD[HDLCD_VFRONT] = videomode->vfront - 1;
+    HDLCD[HDLCD_HBACK] = videomode->hback - 1;
+    HDLCD[HDLCD_HSYNC] = videomode->hsync - 1;
+    HDLCD[HDLCD_HDATA] = videomode->xres - 1;
+    HDLCD[HDLCD_HFRONT] = videomode->hfront - 1;
+    HDLCD[HDLCD_POLARITIES] = (1 << 2) | (1 << 3);
+    HDLCD[HDLCD_RED] = (c->red_size << 8) | c->red_shift;
+    HDLCD[HDLCD_GREEN] = (c->green_size << 8) | c->green_shift;
+    HDLCD[HDLCD_BLUE] = (c->blue_size << 8) | c->blue_shift;
+    HDLCD[HDLCD_COMMAND] = 1;
+    clear_fixmap(FIXMAP_MISC);
+
+    lfbp.pixel_on = (((1 << c->red_size) - 1) << c->red_shift) |
+        (((1 << c->green_size) - 1) << c->green_shift) |
+        (((1 << c->blue_size) - 1) << c->blue_shift);
+    lfbp.lfb = lfb;
+    lfbp.font = &font_vga_8x16;
+    lfbp.bits_per_pixel = bytes_per_pixel*8;
+    lfbp.bytes_per_line = bytes_per_pixel*videomode->xres;
+    lfbp.width = videomode->xres;
+    lfbp.height = videomode->yres;
+    lfbp.flush = hdlcd_flush;
+    lfbp.text_columns = videomode->xres / 8;
+    lfbp.text_rows = videomode->yres / 16;
+    if ( lfb_init(&lfbp) < 0 )
+            return;
+    video_puts = lfb_scroll_puts;
+}
+
+void __init video_endboot(void) { }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/video/modelines.h b/xen/drivers/video/modelines.h
new file mode 100644
index 0000000..9cb7cdd
--- /dev/null
+++ b/xen/drivers/video/modelines.h
@@ -0,0 +1,77 @@
+/*
+ * xen/drivers/video/modelines.h
+ *
+ * Timings for many popular monitor resolutions
+ *
+ * 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.
+ *
+ * Copyright (c) 1999 by The XFree86 Project, Inc.
+ * Copyright (c) 2013 Citrix Systems
+ */
+
+#ifndef _XEN_MODLINES_H
+#define _XEN_MODLINES_H
+
+struct modeline {
+    const char* mode;  /* in the form 1280x1024@60 */
+    uint32_t pixclock; /* Khz */
+    uint32_t xres;
+    uint32_t hfront;   /* horizontal front porch in pixels */
+    uint32_t hsync;    /* horizontal sync pulse in pixels */
+    uint32_t hback;    /* horizontal back porch in pixels */
+    uint32_t yres;
+    uint32_t vfront;   /* vertical front porch in lines */
+    uint32_t vsync;    /* vertical sync pulse in lines */
+    uint32_t vback;    /* vertical back  porch in lines */
+};
+
+struct modeline __initdata videomodes[] = {
+    { "640x480@60",   25175,  640,  16,   96,   48,   480,  11,   2,    31 },
+    { "640x480@72",   31500,  640,  24,   40,   128,  480,  9,    3,    28 },
+    { "640x480@75",   31500,  640,  16,   96,   48,   480,  11,   2,    32 },
+    { "640x480@85",   36000,  640,  32,   48,   112,  480,  1,    3,    25 },
+    { "800x600@56",   38100,  800,  32,   128,  128,  600,  1,    4,    14 },
+    { "800x600@60",   40000,  800,  40,   128,  88 ,  600,  1,    4,    23 },
+    { "800x600@72",   50000,  800,  56,   120,  64 ,  600,  37,   6,    23 },
+    { "800x600@75",   49500,  800,  16,   80,   160,  600,  1,    2,    21 },
+    { "800x600@85",   56250,  800,  32,   64,   152,  600,  1,    3,    27 },
+    { "1024x768@60",  65000,  1024, 24,   136,  160,  768,  3,    6,    29 },
+    { "1024x768@70",  75000,  1024, 24,   136,  144,  768,  3,    6,    29 },
+    { "1024x768@75",  78750,  1024, 16,   96,   176,  768,  1,    3,    28 },
+    { "1024x768@85",  94500,  1024, 48,   96,   208,  768,  1,    3,    36 },
+    { "1280x1024@60", 108000, 1280, 48,   112,  248,  1024, 1,    3,    38 },
+    { "1280x1024@75", 135000, 1280, 16,   144,  248,  1024, 1,    3,    38 },
+    { "1280x1024@85", 157500, 1280, 64,   160,  224,  1024, 1,    3,    44 },
+    { "1400x1050@60", 122610, 1400, 88,   152,  240,  1050, 1,    3,    33 },
+    { "1400x1050@75", 155850, 1400, 96,   152,  248,  1050, 1,    3,    42 },
+    { "1600x1200@60", 162000, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@65", 175500, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@70", 189000, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@75", 202500, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@85", 229500, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1792x1344@60", 204800, 1792, 128,  200,  328,  1344, 1,    3,    46 },
+    { "1792x1344@75", 261000, 1792, 96,   216,  352,  1344, 1,    3,    69 },
+    { "1856x1392@60", 218300, 1856, 96,   224,  352,  1392, 1,    3,    43 },
+    { "1856x1392@75", 288000, 1856, 128,  224,  352,  1392, 1,    3,    104 },
+    { "1920x1200@75", 193160, 1920, 128,  208,  336,  1200, 1,    3,    38 },
+    { "1920x1440@60", 234000, 1920, 128,  208,  344,  1440, 1,    3,    56 },
+    { "1920x1440@75", 297000, 1920, 144,  224,  352,  1440, 1,    3,    56 },
+};
+
+#endif
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index e5dce5e..8e934a4 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -19,6 +19,8 @@
 
 #define CONFIG_DOMAIN_PAGE 1
 
+#define CONFIG_VIDEO 1
+
 #define OPT_CONSOLE_STR "com1"
 
 #ifdef MAX_PHYS_CPUS
-- 
1.7.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 Feb 14 17:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:31: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 1U62eo-00010W-8B; Thu, 14 Feb 2013 17:31: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 1U62en-000105-2F
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:37 +0000
Received: from [85.158.143.35:27546] by server-2.bemta-4.messagelabs.com id
	CA/5C-01597-87F1D115; Thu, 14 Feb 2013 17:31:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19292 invoked from network); 14 Feb 2013 17:30:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:30:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538907"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-ED;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:42 +0000
Message-ID: <1360863042-19845-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 5/5] xen/arm: introduce a driver for the ARM
	HDLCD controller
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the screen resolution setting from device tree, find the
corresponding modeline in a small table of standard video modes, set the
hardware accordingly.

Use vexpress_syscfg to configure the pixel clock.

Use the generic framebuffer functions to print on the screen.

Changes in v4:
- use a lookup table to set the color masks;
- fix indentation;
- make sure mode_string is not NULL and is not bigger than 16 chars
before continuing;
- introduce 2 separate error messages for !hdlcd_start and
!framebuffer_start at the beginning of video_init;
- mark get_color_masks and set_pixclock as __init;
- check that we are running on a vexpress machine before calling
vexpress_syscfg.

Changes in v2:
- read mode from DT;
- support multiple resolutions;
- use vexpress_syscfg to set the pixclock.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/Rules.mk         |    1 +
 xen/drivers/video/Makefile    |    1 +
 xen/drivers/video/arm_hdlcd.c |  276 +++++++++++++++++++++++++++++++++++++++++
 xen/drivers/video/modelines.h |   77 ++++++++++++
 xen/include/asm-arm/config.h  |    2 +
 5 files changed, 357 insertions(+), 0 deletions(-)
 create mode 100644 xen/drivers/video/arm_hdlcd.c
 create mode 100644 xen/drivers/video/modelines.h

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 5b5768a..0843e50 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -8,6 +8,7 @@
 
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
+HAS_ARM_HDLCD := y
 
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
 CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 77f9d5d..a756292 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,3 +4,4 @@ obj-$(HAS_VIDEO) += font_8x16.o
 obj-$(HAS_VIDEO) += font_8x8.o
 obj-$(HAS_VIDEO) += lfb.o
 obj-$(HAS_VGA) += vesa.o
+obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
new file mode 100644
index 0000000..45f9d64
--- /dev/null
+++ b/xen/drivers/video/arm_hdlcd.c
@@ -0,0 +1,276 @@
+/*
+ * xen/drivers/video/arm_hdlcd.c
+ *
+ * Driver for ARM HDLCD Controller
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Copyright (c) 2013 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/delay.h>
+#include <asm/types.h>
+#include <asm/platforms/vexpress.h>
+#include <xen/config.h>
+#include <xen/device_tree.h>
+#include <xen/libfdt/libfdt.h>
+#include <xen/init.h>
+#include <xen/mm.h>
+#include "font.h"
+#include "lfb.h"
+#include "modelines.h"
+
+#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
+
+#define HDLCD_INTMASK       (0x18/4)
+#define HDLCD_FBBASE        (0x100/4)
+#define HDLCD_LINELENGTH    (0x104/4)
+#define HDLCD_LINECOUNT     (0x108/4)
+#define HDLCD_LINEPITCH     (0x10C/4)
+#define HDLCD_BUS           (0x110/4)
+#define HDLCD_VSYNC         (0x200/4)
+#define HDLCD_VBACK         (0x204/4)
+#define HDLCD_VDATA         (0x208/4)
+#define HDLCD_VFRONT        (0x20C/4)
+#define HDLCD_HSYNC         (0x210/4)
+#define HDLCD_HBACK         (0x214/4)
+#define HDLCD_HDATA         (0x218/4)
+#define HDLCD_HFRONT        (0x21C/4)
+#define HDLCD_POLARITIES    (0x220/4)
+#define HDLCD_COMMAND       (0x230/4)
+#define HDLCD_PF            (0x240/4)
+#define HDLCD_RED           (0x244/4)
+#define HDLCD_GREEN         (0x248/4)
+#define HDLCD_BLUE          (0x24C/4)
+
+struct color_masks {
+    int red_shift;
+    int red_size;
+    int green_shift;
+    int green_size;
+    int blue_shift;
+    int blue_size;
+};
+
+struct pixel_colors {
+    const char* bpp;
+    struct color_masks colors;
+};
+
+struct pixel_colors __initdata colors[] = {
+    { "16", { 0, 5, 11, 5, 6, 5 } },
+    { "24", { 0, 8, 16, 8, 8, 8 } },
+    { "32", { 0, 8, 16, 8, 8, 8 } },
+};
+
+static void vga_noop_puts(const char *s) {}
+void (*video_puts)(const char *) = vga_noop_puts;
+
+static void hdlcd_flush(void)
+{
+    dsb();
+}
+
+static int __init get_color_masks(const char* bpp, struct color_masks **masks)
+{
+    int i;
+    for ( i = 0; i < ARRAY_SIZE(colors); i++ )
+    {
+        if ( !strncmp(colors[i].bpp, bpp, 2) )
+        {
+            *masks = &colors[i].colors;
+            return 0;
+        }
+    }
+    return -1;
+}
+
+static void __init set_pixclock(uint32_t pixclock)
+{
+    if ( device_tree_node_compatible(device_tree_flattened, 0, "arm,vexpress") )
+            vexpress_syscfg(1, V2M_SYS_CFG_OSC_FUNC,
+                            V2M_SYS_CFG_OSC5, &pixclock);
+}
+
+void __init video_init(void)
+{
+    int node, depth;
+    u32 address_cells, size_cells;
+    struct lfb_prop lfbp;
+    unsigned char *lfb;
+    paddr_t hdlcd_start, hdlcd_size;
+    paddr_t framebuffer_start, framebuffer_size;
+    const struct fdt_property *prop;
+    const u32 *cell;
+    const char *mode_string;
+    char _mode_string[16];
+    int bytes_per_pixel = 4;
+    struct color_masks *c = NULL;
+    struct modeline *videomode = NULL;
+    int i;
+
+    if ( find_compatible_node("arm,hdlcd", &node, &depth,
+                &address_cells, &size_cells) <= 0 )
+        return;
+
+    prop = fdt_get_property(device_tree_flattened, node, "reg", NULL);
+    if ( !prop )
+        return;
+
+    cell = (const u32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells,
+            &hdlcd_start, &hdlcd_size); 
+
+    prop = fdt_get_property(device_tree_flattened, node, "framebuffer", NULL);
+    if ( !prop )
+        return;
+
+    cell = (const u32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells,
+            &framebuffer_start, &framebuffer_size); 
+
+    if ( !hdlcd_start )
+    {
+        printk(KERN_ERR "HDLCD address missing from device tree, disabling driver\n");
+        return;
+    }
+
+    if ( !hdlcd_start || !framebuffer_start )
+    {
+        printk(KERN_ERR "HDLCD: framebuffer address missing from device tree, disabling driver\n");
+        return;
+    }
+
+    mode_string = fdt_getprop(device_tree_flattened, node, "mode", NULL);
+    if ( !mode_string )
+    {
+        get_color_masks("32", &c);
+        memcpy(_mode_string, "1280x1024@60", strlen("1280x1024@60") + 1);
+        bytes_per_pixel = 4;
+    }
+    else if ( strlen(mode_string) < strlen("800x600@60") ||
+            strlen(mode_string) > sizeof(_mode_string) - 1 )
+    {
+        printk(KERN_ERR "HDLCD: invalid modeline=%s\n", mode_string);
+        return;
+    } else {
+        char *s = strchr(mode_string, '-');
+        if ( !s )
+        {
+            printk(KERN_INFO "HDLCD: bpp not found in modeline %s, assume 32 bpp\n",
+                    mode_string);
+            get_color_masks("32", &c);
+            memcpy(_mode_string, mode_string, strlen(mode_string) + 1);
+            bytes_per_pixel = 4;
+        } else {
+            if ( strlen(s) < 6 )
+            {
+                printk(KERN_ERR "HDLCD: invalid mode %s\n", mode_string);
+                return;
+            }
+            s++;
+            if ( get_color_masks(s, &c) < 0 )
+            {
+                printk(KERN_WARNING "HDLCD: unsupported bpp %s\n", s);
+                return;
+            }
+            bytes_per_pixel = simple_strtoll(s, NULL, 10) / 8;
+        }
+        i = s - mode_string - 1;
+        memcpy(_mode_string, mode_string, i);
+        memcpy(_mode_string + i, mode_string + i + 3, 4);
+    }
+
+    for ( i = 0; i < ARRAY_SIZE(videomodes); i++ ) {
+        if ( !strcmp(_mode_string, videomodes[i].mode) )
+        {
+            videomode = &videomodes[i];
+            break;
+        }
+    }
+    if ( !videomode )
+    {
+        printk(KERN_WARNING "HDLCD: unsupported videomode %s\n", _mode_string);
+        return;
+    }
+
+    if ( framebuffer_size < bytes_per_pixel * videomode->xres * videomode->yres )
+    {
+        printk(KERN_ERR "HDLCD: the framebuffer is too small, disabling the HDLCD driver\n");
+        return;
+    }
+
+    printk(KERN_INFO "Initializing HDLCD driver\n");
+
+    lfb = early_ioremap(framebuffer_start, framebuffer_size, DEV_WC);
+    if ( !lfb )
+    {
+        printk(KERN_ERR "Couldn't map the framebuffer\n");
+        return;
+    }
+    memset(lfb, 0x00, bytes_per_pixel * videomode->xres * videomode->yres);
+
+    /* uses FIXMAP_MISC */
+    set_pixclock(videomode->pixclock);
+
+    set_fixmap(FIXMAP_MISC, hdlcd_start >> PAGE_SHIFT, DEV_SHARED);
+    HDLCD[HDLCD_COMMAND] = 0;
+
+    HDLCD[HDLCD_LINELENGTH] = videomode->xres * bytes_per_pixel;
+    HDLCD[HDLCD_LINECOUNT] = videomode->yres - 1;
+    HDLCD[HDLCD_LINEPITCH] = videomode->xres * bytes_per_pixel;
+    HDLCD[HDLCD_PF] = ((bytes_per_pixel - 1) << 3);
+    HDLCD[HDLCD_INTMASK] = 0;
+    HDLCD[HDLCD_FBBASE] = framebuffer_start;
+    HDLCD[HDLCD_BUS] = 0xf00 | (1 << 4);
+    HDLCD[HDLCD_VBACK] = videomode->vback - 1;
+    HDLCD[HDLCD_VSYNC] = videomode->vsync - 1;
+    HDLCD[HDLCD_VDATA] = videomode->yres - 1;
+    HDLCD[HDLCD_VFRONT] = videomode->vfront - 1;
+    HDLCD[HDLCD_HBACK] = videomode->hback - 1;
+    HDLCD[HDLCD_HSYNC] = videomode->hsync - 1;
+    HDLCD[HDLCD_HDATA] = videomode->xres - 1;
+    HDLCD[HDLCD_HFRONT] = videomode->hfront - 1;
+    HDLCD[HDLCD_POLARITIES] = (1 << 2) | (1 << 3);
+    HDLCD[HDLCD_RED] = (c->red_size << 8) | c->red_shift;
+    HDLCD[HDLCD_GREEN] = (c->green_size << 8) | c->green_shift;
+    HDLCD[HDLCD_BLUE] = (c->blue_size << 8) | c->blue_shift;
+    HDLCD[HDLCD_COMMAND] = 1;
+    clear_fixmap(FIXMAP_MISC);
+
+    lfbp.pixel_on = (((1 << c->red_size) - 1) << c->red_shift) |
+        (((1 << c->green_size) - 1) << c->green_shift) |
+        (((1 << c->blue_size) - 1) << c->blue_shift);
+    lfbp.lfb = lfb;
+    lfbp.font = &font_vga_8x16;
+    lfbp.bits_per_pixel = bytes_per_pixel*8;
+    lfbp.bytes_per_line = bytes_per_pixel*videomode->xres;
+    lfbp.width = videomode->xres;
+    lfbp.height = videomode->yres;
+    lfbp.flush = hdlcd_flush;
+    lfbp.text_columns = videomode->xres / 8;
+    lfbp.text_rows = videomode->yres / 16;
+    if ( lfb_init(&lfbp) < 0 )
+            return;
+    video_puts = lfb_scroll_puts;
+}
+
+void __init video_endboot(void) { }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/video/modelines.h b/xen/drivers/video/modelines.h
new file mode 100644
index 0000000..9cb7cdd
--- /dev/null
+++ b/xen/drivers/video/modelines.h
@@ -0,0 +1,77 @@
+/*
+ * xen/drivers/video/modelines.h
+ *
+ * Timings for many popular monitor resolutions
+ *
+ * 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.
+ *
+ * Copyright (c) 1999 by The XFree86 Project, Inc.
+ * Copyright (c) 2013 Citrix Systems
+ */
+
+#ifndef _XEN_MODLINES_H
+#define _XEN_MODLINES_H
+
+struct modeline {
+    const char* mode;  /* in the form 1280x1024@60 */
+    uint32_t pixclock; /* Khz */
+    uint32_t xres;
+    uint32_t hfront;   /* horizontal front porch in pixels */
+    uint32_t hsync;    /* horizontal sync pulse in pixels */
+    uint32_t hback;    /* horizontal back porch in pixels */
+    uint32_t yres;
+    uint32_t vfront;   /* vertical front porch in lines */
+    uint32_t vsync;    /* vertical sync pulse in lines */
+    uint32_t vback;    /* vertical back  porch in lines */
+};
+
+struct modeline __initdata videomodes[] = {
+    { "640x480@60",   25175,  640,  16,   96,   48,   480,  11,   2,    31 },
+    { "640x480@72",   31500,  640,  24,   40,   128,  480,  9,    3,    28 },
+    { "640x480@75",   31500,  640,  16,   96,   48,   480,  11,   2,    32 },
+    { "640x480@85",   36000,  640,  32,   48,   112,  480,  1,    3,    25 },
+    { "800x600@56",   38100,  800,  32,   128,  128,  600,  1,    4,    14 },
+    { "800x600@60",   40000,  800,  40,   128,  88 ,  600,  1,    4,    23 },
+    { "800x600@72",   50000,  800,  56,   120,  64 ,  600,  37,   6,    23 },
+    { "800x600@75",   49500,  800,  16,   80,   160,  600,  1,    2,    21 },
+    { "800x600@85",   56250,  800,  32,   64,   152,  600,  1,    3,    27 },
+    { "1024x768@60",  65000,  1024, 24,   136,  160,  768,  3,    6,    29 },
+    { "1024x768@70",  75000,  1024, 24,   136,  144,  768,  3,    6,    29 },
+    { "1024x768@75",  78750,  1024, 16,   96,   176,  768,  1,    3,    28 },
+    { "1024x768@85",  94500,  1024, 48,   96,   208,  768,  1,    3,    36 },
+    { "1280x1024@60", 108000, 1280, 48,   112,  248,  1024, 1,    3,    38 },
+    { "1280x1024@75", 135000, 1280, 16,   144,  248,  1024, 1,    3,    38 },
+    { "1280x1024@85", 157500, 1280, 64,   160,  224,  1024, 1,    3,    44 },
+    { "1400x1050@60", 122610, 1400, 88,   152,  240,  1050, 1,    3,    33 },
+    { "1400x1050@75", 155850, 1400, 96,   152,  248,  1050, 1,    3,    42 },
+    { "1600x1200@60", 162000, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@65", 175500, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@70", 189000, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@75", 202500, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1600x1200@85", 229500, 1600, 64,   192,  304,  1200, 1,    3,    46 },
+    { "1792x1344@60", 204800, 1792, 128,  200,  328,  1344, 1,    3,    46 },
+    { "1792x1344@75", 261000, 1792, 96,   216,  352,  1344, 1,    3,    69 },
+    { "1856x1392@60", 218300, 1856, 96,   224,  352,  1392, 1,    3,    43 },
+    { "1856x1392@75", 288000, 1856, 128,  224,  352,  1392, 1,    3,    104 },
+    { "1920x1200@75", 193160, 1920, 128,  208,  336,  1200, 1,    3,    38 },
+    { "1920x1440@60", 234000, 1920, 128,  208,  344,  1440, 1,    3,    56 },
+    { "1920x1440@75", 297000, 1920, 144,  224,  352,  1440, 1,    3,    56 },
+};
+
+#endif
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index e5dce5e..8e934a4 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -19,6 +19,8 @@
 
 #define CONFIG_DOMAIN_PAGE 1
 
+#define CONFIG_VIDEO 1
+
 #define OPT_CONSOLE_STR "com1"
 
 #ifdef MAX_PHYS_CPUS
-- 
1.7.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 Feb 14 17:31:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62es-00011o-MB; Thu, 14 Feb 2013 17:31: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 1U62er-00011D-8Q
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:41 +0000
Received: from [85.158.143.35:27682] by server-3.bemta-4.messagelabs.com id
	74/80-08920-C7F1D115; Thu, 14 Feb 2013 17:31:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19470 invoked from network); 14 Feb 2013 17:31:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538906"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-94;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:38 +0000
Message-ID: <1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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

Abstract away from vesa.c the funcions to handle a linear framebuffer
and print characters to it.
Make use of the new functions in vesa.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>

Changes in v6:
- remove useless initializations to NULL in lfb_init;
- more compact checks in lfb_init.

Changes in v5:
- remove lfb_alloc and the now unused __initdata variables;
- fix indentation and long lines.

Changes in v4:
- squash the vesa.c changes into this patch;
- rename fb* to lfb*;
- pass a pointer to fb_init;
- use %u for screen dimensions;
- specify loglevel in printk;
- call fb_free on error in fb_alloc;
- no __init on declarations;
- do not break messages to fit 80 columns.
---
 xen/drivers/video/Makefile |    1 +
 xen/drivers/video/lfb.c    |  183 ++++++++++++++++++++++++++++++++++++++++++++
 xen/drivers/video/lfb.h    |   46 +++++++++++
 xen/drivers/video/vesa.c   |  177 ++++++------------------------------------
 4 files changed, 254 insertions(+), 153 deletions(-)
 create mode 100644 xen/drivers/video/lfb.c
 create mode 100644 xen/drivers/video/lfb.h

diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2993c39..77f9d5d 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -2,4 +2,5 @@ obj-$(HAS_VGA) := vga.o
 obj-$(HAS_VIDEO) += font_8x14.o
 obj-$(HAS_VIDEO) += font_8x16.o
 obj-$(HAS_VIDEO) += font_8x8.o
+obj-$(HAS_VIDEO) += lfb.o
 obj-$(HAS_VGA) += vesa.o
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
new file mode 100644
index 0000000..cc7f7ac
--- /dev/null
+++ b/xen/drivers/video/lfb.c
@@ -0,0 +1,183 @@
+/******************************************************************************
+ * lfb.c
+ *
+ * linear frame buffer handling.
+ */
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include "lfb.h"
+#include "font.h"
+
+#define MAX_XRES 1900
+#define MAX_YRES 1200
+#define MAX_BPP 4
+#define MAX_FONT_W 8
+#define MAX_FONT_H 16
+
+struct lfb_status {
+    struct lfb_prop lfbp;
+
+    unsigned char *lbuf, *text_buf;
+    unsigned int *line_len;
+    unsigned int xpos, ypos;
+};
+static struct lfb_status lfb;
+
+static void lfb_show_line(
+    const unsigned char *text_line,
+    unsigned char *video_line,
+    unsigned int nr_chars,
+    unsigned int nr_cells)
+{
+    unsigned int i, j, b, bpp, pixel;
+
+    bpp = (lfb.lfbp.bits_per_pixel + 7) >> 3;
+
+    for ( i = 0; i < lfb.lfbp.font->height; i++ )
+    {
+        unsigned char *ptr = lfb.lbuf;
+
+        for ( j = 0; j < nr_chars; j++ )
+        {
+            const unsigned char *bits = lfb.lfbp.font->data;
+            bits += ((text_line[j] * lfb.lfbp.font->height + i) *
+                     ((lfb.lfbp.font->width + 7) >> 3));
+            for ( b = lfb.lfbp.font->width; b--; )
+            {
+                pixel = (*bits & (1u<<b)) ? lfb.lfbp.pixel_on : 0;
+                memcpy(ptr, &pixel, bpp);
+                ptr += bpp;
+            }
+        }
+
+        memset(ptr, 0, (lfb.lfbp.width - nr_chars * lfb.lfbp.font->width) * bpp);
+        memcpy(video_line, lfb.lbuf, nr_cells * lfb.lfbp.font->width * bpp);
+        video_line += lfb.lfbp.bytes_per_line;
+    }
+}
+
+/* Fast mode which redraws all modified parts of a 2D text buffer. */
+void lfb_redraw_puts(const char *s)
+{
+    unsigned int i, min_redraw_y = lfb.ypos;
+    char c;
+
+    /* Paste characters into text buffer. */
+    while ( (c = *s++) != '\0' )
+    {
+        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
+        {
+            if ( ++lfb.ypos >= lfb.lfbp.text_rows )
+            {
+                min_redraw_y = 0;
+                lfb.ypos = lfb.lfbp.text_rows - 1;
+                memmove(lfb.text_buf, lfb.text_buf + lfb.lfbp.text_columns,
+                        lfb.ypos * lfb.lfbp.text_columns);
+                memset(lfb.text_buf + lfb.ypos * lfb.lfbp.text_columns, 0, lfb.xpos);
+            }
+            lfb.xpos = 0;
+        }
+
+        if ( c != '\n' )
+            lfb.text_buf[lfb.xpos++ + lfb.ypos * lfb.lfbp.text_columns] = c;
+    }
+
+    /* Render modified section of text buffer to VESA linear framebuffer. */
+    for ( i = min_redraw_y; i <= lfb.ypos; i++ )
+    {
+        const unsigned char *line = lfb.text_buf + i * lfb.lfbp.text_columns;
+        unsigned int width;
+
+        for ( width = lfb.lfbp.text_columns; width; --width )
+            if ( line[width - 1] )
+                 break;
+        lfb_show_line(line,
+                       lfb.lfbp.lfb + i * lfb.lfbp.font->height * lfb.lfbp.bytes_per_line,
+                       width, max(lfb.line_len[i], width));
+        lfb.line_len[i] = width;
+    }
+
+    lfb.lfbp.flush();
+}
+
+/* Slower line-based scroll mode which interacts better with dom0. */
+void lfb_scroll_puts(const char *s)
+{
+    unsigned int i;
+    char c;
+
+    while ( (c = *s++) != '\0' )
+    {
+        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
+        {
+            unsigned int bytes = (lfb.lfbp.width *
+                                  ((lfb.lfbp.bits_per_pixel + 7) >> 3));
+            unsigned char *src = lfb.lfbp.lfb + lfb.lfbp.font->height * lfb.lfbp.bytes_per_line;
+            unsigned char *dst = lfb.lfbp.lfb;
+
+            /* New line: scroll all previous rows up one line. */
+            for ( i = lfb.lfbp.font->height; i < lfb.lfbp.height; i++ )
+            {
+                memcpy(dst, src, bytes);
+                src += lfb.lfbp.bytes_per_line;
+                dst += lfb.lfbp.bytes_per_line;
+            }
+
+            /* Render new line. */
+            lfb_show_line(
+                lfb.text_buf,
+                lfb.lfbp.lfb + (lfb.lfbp.text_rows-1) * lfb.lfbp.font->height *
+                lfb.lfbp.bytes_per_line,
+                lfb.xpos, lfb.lfbp.text_columns);
+
+            lfb.xpos = 0;
+        }
+
+        if ( c != '\n' )
+            lfb.text_buf[lfb.xpos++] = c;
+    }
+
+    lfb.lfbp.flush();
+}
+
+void lfb_carriage_return(void)
+{
+    lfb.xpos = 0;
+}
+
+int __init lfb_init(struct lfb_prop *lfbp)
+{
+    if ( lfbp->width > MAX_XRES || lfbp->height > MAX_YRES )
+    {
+        printk(XENLOG_WARNING "Couldn't initialize a %ux%u framebuffer early.\n",
+               lfbp->width, lfbp->height);
+        return -EINVAL;
+    }
+
+    lfb.lfbp = *lfbp;
+
+    lfb.lbuf = xmalloc_bytes(lfb.lfbp.bytes_per_line);
+    lfb.text_buf = xzalloc_bytes(lfb.lfbp.text_columns * lfb.lfbp.text_rows);
+    lfb.line_len = xzalloc_array(unsigned int, lfb.lfbp.text_columns);
+
+    if ( !lfb.lbuf || !lfb.text_buf || !lfb.line_len )
+        goto fail;
+
+    return 0;
+
+fail:
+    printk(XENLOG_ERR "Couldn't allocate enough memory to drive the framebuffer\n");
+    lfb_free();
+
+    return -ENOMEM;
+}
+
+void lfb_free(void)
+{
+    xfree(lfb.lbuf);
+    xfree(lfb.text_buf);
+    xfree(lfb.line_len);
+}
diff --git a/xen/drivers/video/lfb.h b/xen/drivers/video/lfb.h
new file mode 100644
index 0000000..ac40a66
--- /dev/null
+++ b/xen/drivers/video/lfb.h
@@ -0,0 +1,46 @@
+/*
+ * xen/drivers/video/lfb.h
+ *
+ * Cross-platform framebuffer library
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Copyright (c) 2013 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#ifndef _XEN_LFB_H
+#define _XEN_LFB_H
+
+#include <xen/init.h>
+
+struct lfb_prop {
+    const struct font_desc *font;
+    unsigned char *lfb;
+    unsigned int pixel_on;
+    uint16_t width, height;
+    uint16_t bytes_per_line;
+    uint16_t bits_per_pixel;
+    void (*flush)(void);
+
+    unsigned int text_columns;
+    unsigned int text_rows;
+};
+
+void lfb_redraw_puts(const char *s);
+void lfb_scroll_puts(const char *s);
+void lfb_carriage_return(void);
+void lfb_free(void);
+
+/* initialize the framebuffer */
+int lfb_init(struct lfb_prop *lfbp);
+
+#endif
diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
index aaf8b23..1144f76 100644
--- a/xen/drivers/video/vesa.c
+++ b/xen/drivers/video/vesa.c
@@ -13,20 +13,15 @@
 #include <asm/io.h>
 #include <asm/page.h>
 #include "font.h"
+#include "lfb.h"
 
 #define vlfb_info    vga_console_info.u.vesa_lfb
-#define text_columns (vlfb_info.width / font->width)
-#define text_rows    (vlfb_info.height / font->height)
 
-static void vesa_redraw_puts(const char *s);
-static void vesa_scroll_puts(const char *s);
+static void lfb_flush(void);
 
-static unsigned char *lfb, *lbuf, *text_buf;
-static unsigned int *__initdata line_len;
+static unsigned char *lfb;
 static const struct font_desc *font;
 static bool_t vga_compat;
-static unsigned int pixel_on;
-static unsigned int xpos, ypos;
 
 static unsigned int vram_total;
 integer_param("vesa-ram", vram_total);
@@ -87,29 +82,26 @@ void __init vesa_early_init(void)
 
 void __init vesa_init(void)
 {
-    if ( !font )
-        goto fail;
-
-    lbuf = xmalloc_bytes(vlfb_info.bytes_per_line);
-    if ( !lbuf )
-        goto fail;
+    struct lfb_prop lfbp;
 
-    text_buf = xzalloc_bytes(text_columns * text_rows);
-    if ( !text_buf )
-        goto fail;
+    if ( !font )
+        return;
 
-    line_len = xzalloc_array(unsigned int, text_columns);
-    if ( !line_len )
-        goto fail;
+    lfbp.font = font;
+    lfbp.bits_per_pixel = vlfb_info.bits_per_pixel;
+    lfbp.bytes_per_line = vlfb_info.bytes_per_line;
+    lfbp.width = vlfb_info.width;
+    lfbp.height = vlfb_info.height;
+    lfbp.flush = lfb_flush;
+    lfbp.text_columns = vlfb_info.width / font->width;
+    lfbp.text_rows = vlfb_info.height / font->height;
 
-    lfb = ioremap(vlfb_info.lfb_base, vram_remap);
+    lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap);
     if ( !lfb )
-        goto fail;
+        return;
 
     memset(lfb, 0, vram_remap);
 
-    video_puts = vesa_redraw_puts;
-
     printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
            "using %uk, total %uk\n",
            vlfb_info.lfb_base, lfb,
@@ -131,7 +123,7 @@ void __init vesa_init(void)
     {
         /* Light grey in truecolor. */
         unsigned int grey = 0xaaaaaaaa;
-        pixel_on = 
+        fbp.pixel_on = 
             ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
             ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
             ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_pos);
@@ -139,15 +131,12 @@ void __init vesa_init(void)
     else
     {
         /* White(ish) in default pseudocolor palette. */
-        pixel_on = 7;
+        fbp.pixel_on = 7;
     }
 
-    return;
-
- fail:
-    xfree(lbuf);
-    xfree(text_buf);
-    xfree(line_len);
+    if ( lfb_init(&lfbp) < 0 )
+        return;
+    video_puts = lfb_redraw_puts;
 }
 
 #include <asm/mtrr.h>
@@ -192,8 +181,8 @@ void __init vesa_endboot(bool_t keep)
 {
     if ( keep )
     {
-        xpos = 0;
-        video_puts = vesa_scroll_puts;
+        video_puts = lfb_scroll_puts;
+        lfb_carriage_return();
     }
     else
     {
@@ -202,124 +191,6 @@ void __init vesa_endboot(bool_t keep)
             memset(lfb + i * vlfb_info.bytes_per_line, 0,
                    vlfb_info.width * bpp);
         lfb_flush();
+        lfb_free();
     }
-
-    xfree(line_len);
-}
-
-/* Render one line of text to given linear framebuffer line. */
-static void vesa_show_line(
-    const unsigned char *text_line,
-    unsigned char *video_line,
-    unsigned int nr_chars,
-    unsigned int nr_cells)
-{
-    unsigned int i, j, b, bpp, pixel;
-
-    bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
-
-    for ( i = 0; i < font->height; i++ )
-    {
-        unsigned char *ptr = lbuf;
-
-        for ( j = 0; j < nr_chars; j++ )
-        {
-            const unsigned char *bits = font->data;
-            bits += ((text_line[j] * font->height + i) *
-                     ((font->width + 7) >> 3));
-            for ( b = font->width; b--; )
-            {
-                pixel = (*bits & (1u<<b)) ? pixel_on : 0;
-                memcpy(ptr, &pixel, bpp);
-                ptr += bpp;
-            }
-        }
-
-        memset(ptr, 0, (vlfb_info.width - nr_chars * font->width) * bpp);
-        memcpy(video_line, lbuf, nr_cells * font->width * bpp);
-        video_line += vlfb_info.bytes_per_line;
-    }
-}
-
-/* Fast mode which redraws all modified parts of a 2D text buffer. */
-static void __init vesa_redraw_puts(const char *s)
-{
-    unsigned int i, min_redraw_y = ypos;
-    char c;
-
-    /* Paste characters into text buffer. */
-    while ( (c = *s++) != '\0' )
-    {
-        if ( (c == '\n') || (xpos >= text_columns) )
-        {
-            if ( ++ypos >= text_rows )
-            {
-                min_redraw_y = 0;
-                ypos = text_rows - 1;
-                memmove(text_buf, text_buf + text_columns,
-                        ypos * text_columns);
-                memset(text_buf + ypos * text_columns, 0, xpos);
-            }
-            xpos = 0;
-        }
-
-        if ( c != '\n' )
-            text_buf[xpos++ + ypos * text_columns] = c;
-    }
-
-    /* Render modified section of text buffer to VESA linear framebuffer. */
-    for ( i = min_redraw_y; i <= ypos; i++ )
-    {
-        const unsigned char *line = text_buf + i * text_columns;
-        unsigned int width;
-
-        for ( width = text_columns; width; --width )
-            if ( line[width - 1] )
-                 break;
-        vesa_show_line(line,
-                       lfb + i * font->height * vlfb_info.bytes_per_line,
-                       width, max(line_len[i], width));
-        line_len[i] = width;
-    }
-
-    lfb_flush();
-}
-
-/* Slower line-based scroll mode which interacts better with dom0. */
-static void vesa_scroll_puts(const char *s)
-{
-    unsigned int i;
-    char c;
-
-    while ( (c = *s++) != '\0' )
-    {
-        if ( (c == '\n') || (xpos >= text_columns) )
-        {
-            unsigned int bytes = (vlfb_info.width *
-                                  ((vlfb_info.bits_per_pixel + 7) >> 3));
-            unsigned char *src = lfb + font->height * vlfb_info.bytes_per_line;
-            unsigned char *dst = lfb;
-            
-            /* New line: scroll all previous rows up one line. */
-            for ( i = font->height; i < vlfb_info.height; i++ )
-            {
-                memcpy(dst, src, bytes);
-                src += vlfb_info.bytes_per_line;
-                dst += vlfb_info.bytes_per_line;
-            }
-
-            /* Render new line. */
-            vesa_show_line(
-                text_buf,
-                lfb + (text_rows-1) * font->height * vlfb_info.bytes_per_line,
-                xpos, text_columns);
-
-            xpos = 0;
-        }
-
-        if ( c != '\n' )
-            text_buf[xpos++] = c;
-    }
-
-    lfb_flush();
 }
-- 
1.7.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 Feb 14 17:31:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62es-00011o-MB; Thu, 14 Feb 2013 17:31: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 1U62er-00011D-8Q
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:41 +0000
Received: from [85.158.143.35:27682] by server-3.bemta-4.messagelabs.com id
	74/80-08920-C7F1D115; Thu, 14 Feb 2013 17:31:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360863051!13137950!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19470 invoked from network); 14 Feb 2013 17:31:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 17:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7538906"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-94;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:38 +0000
Message-ID: <1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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

Abstract away from vesa.c the funcions to handle a linear framebuffer
and print characters to it.
Make use of the new functions in vesa.c.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>

Changes in v6:
- remove useless initializations to NULL in lfb_init;
- more compact checks in lfb_init.

Changes in v5:
- remove lfb_alloc and the now unused __initdata variables;
- fix indentation and long lines.

Changes in v4:
- squash the vesa.c changes into this patch;
- rename fb* to lfb*;
- pass a pointer to fb_init;
- use %u for screen dimensions;
- specify loglevel in printk;
- call fb_free on error in fb_alloc;
- no __init on declarations;
- do not break messages to fit 80 columns.
---
 xen/drivers/video/Makefile |    1 +
 xen/drivers/video/lfb.c    |  183 ++++++++++++++++++++++++++++++++++++++++++++
 xen/drivers/video/lfb.h    |   46 +++++++++++
 xen/drivers/video/vesa.c   |  177 ++++++------------------------------------
 4 files changed, 254 insertions(+), 153 deletions(-)
 create mode 100644 xen/drivers/video/lfb.c
 create mode 100644 xen/drivers/video/lfb.h

diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2993c39..77f9d5d 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -2,4 +2,5 @@ obj-$(HAS_VGA) := vga.o
 obj-$(HAS_VIDEO) += font_8x14.o
 obj-$(HAS_VIDEO) += font_8x16.o
 obj-$(HAS_VIDEO) += font_8x8.o
+obj-$(HAS_VIDEO) += lfb.o
 obj-$(HAS_VGA) += vesa.o
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
new file mode 100644
index 0000000..cc7f7ac
--- /dev/null
+++ b/xen/drivers/video/lfb.c
@@ -0,0 +1,183 @@
+/******************************************************************************
+ * lfb.c
+ *
+ * linear frame buffer handling.
+ */
+
+#include <xen/config.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include "lfb.h"
+#include "font.h"
+
+#define MAX_XRES 1900
+#define MAX_YRES 1200
+#define MAX_BPP 4
+#define MAX_FONT_W 8
+#define MAX_FONT_H 16
+
+struct lfb_status {
+    struct lfb_prop lfbp;
+
+    unsigned char *lbuf, *text_buf;
+    unsigned int *line_len;
+    unsigned int xpos, ypos;
+};
+static struct lfb_status lfb;
+
+static void lfb_show_line(
+    const unsigned char *text_line,
+    unsigned char *video_line,
+    unsigned int nr_chars,
+    unsigned int nr_cells)
+{
+    unsigned int i, j, b, bpp, pixel;
+
+    bpp = (lfb.lfbp.bits_per_pixel + 7) >> 3;
+
+    for ( i = 0; i < lfb.lfbp.font->height; i++ )
+    {
+        unsigned char *ptr = lfb.lbuf;
+
+        for ( j = 0; j < nr_chars; j++ )
+        {
+            const unsigned char *bits = lfb.lfbp.font->data;
+            bits += ((text_line[j] * lfb.lfbp.font->height + i) *
+                     ((lfb.lfbp.font->width + 7) >> 3));
+            for ( b = lfb.lfbp.font->width; b--; )
+            {
+                pixel = (*bits & (1u<<b)) ? lfb.lfbp.pixel_on : 0;
+                memcpy(ptr, &pixel, bpp);
+                ptr += bpp;
+            }
+        }
+
+        memset(ptr, 0, (lfb.lfbp.width - nr_chars * lfb.lfbp.font->width) * bpp);
+        memcpy(video_line, lfb.lbuf, nr_cells * lfb.lfbp.font->width * bpp);
+        video_line += lfb.lfbp.bytes_per_line;
+    }
+}
+
+/* Fast mode which redraws all modified parts of a 2D text buffer. */
+void lfb_redraw_puts(const char *s)
+{
+    unsigned int i, min_redraw_y = lfb.ypos;
+    char c;
+
+    /* Paste characters into text buffer. */
+    while ( (c = *s++) != '\0' )
+    {
+        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
+        {
+            if ( ++lfb.ypos >= lfb.lfbp.text_rows )
+            {
+                min_redraw_y = 0;
+                lfb.ypos = lfb.lfbp.text_rows - 1;
+                memmove(lfb.text_buf, lfb.text_buf + lfb.lfbp.text_columns,
+                        lfb.ypos * lfb.lfbp.text_columns);
+                memset(lfb.text_buf + lfb.ypos * lfb.lfbp.text_columns, 0, lfb.xpos);
+            }
+            lfb.xpos = 0;
+        }
+
+        if ( c != '\n' )
+            lfb.text_buf[lfb.xpos++ + lfb.ypos * lfb.lfbp.text_columns] = c;
+    }
+
+    /* Render modified section of text buffer to VESA linear framebuffer. */
+    for ( i = min_redraw_y; i <= lfb.ypos; i++ )
+    {
+        const unsigned char *line = lfb.text_buf + i * lfb.lfbp.text_columns;
+        unsigned int width;
+
+        for ( width = lfb.lfbp.text_columns; width; --width )
+            if ( line[width - 1] )
+                 break;
+        lfb_show_line(line,
+                       lfb.lfbp.lfb + i * lfb.lfbp.font->height * lfb.lfbp.bytes_per_line,
+                       width, max(lfb.line_len[i], width));
+        lfb.line_len[i] = width;
+    }
+
+    lfb.lfbp.flush();
+}
+
+/* Slower line-based scroll mode which interacts better with dom0. */
+void lfb_scroll_puts(const char *s)
+{
+    unsigned int i;
+    char c;
+
+    while ( (c = *s++) != '\0' )
+    {
+        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
+        {
+            unsigned int bytes = (lfb.lfbp.width *
+                                  ((lfb.lfbp.bits_per_pixel + 7) >> 3));
+            unsigned char *src = lfb.lfbp.lfb + lfb.lfbp.font->height * lfb.lfbp.bytes_per_line;
+            unsigned char *dst = lfb.lfbp.lfb;
+
+            /* New line: scroll all previous rows up one line. */
+            for ( i = lfb.lfbp.font->height; i < lfb.lfbp.height; i++ )
+            {
+                memcpy(dst, src, bytes);
+                src += lfb.lfbp.bytes_per_line;
+                dst += lfb.lfbp.bytes_per_line;
+            }
+
+            /* Render new line. */
+            lfb_show_line(
+                lfb.text_buf,
+                lfb.lfbp.lfb + (lfb.lfbp.text_rows-1) * lfb.lfbp.font->height *
+                lfb.lfbp.bytes_per_line,
+                lfb.xpos, lfb.lfbp.text_columns);
+
+            lfb.xpos = 0;
+        }
+
+        if ( c != '\n' )
+            lfb.text_buf[lfb.xpos++] = c;
+    }
+
+    lfb.lfbp.flush();
+}
+
+void lfb_carriage_return(void)
+{
+    lfb.xpos = 0;
+}
+
+int __init lfb_init(struct lfb_prop *lfbp)
+{
+    if ( lfbp->width > MAX_XRES || lfbp->height > MAX_YRES )
+    {
+        printk(XENLOG_WARNING "Couldn't initialize a %ux%u framebuffer early.\n",
+               lfbp->width, lfbp->height);
+        return -EINVAL;
+    }
+
+    lfb.lfbp = *lfbp;
+
+    lfb.lbuf = xmalloc_bytes(lfb.lfbp.bytes_per_line);
+    lfb.text_buf = xzalloc_bytes(lfb.lfbp.text_columns * lfb.lfbp.text_rows);
+    lfb.line_len = xzalloc_array(unsigned int, lfb.lfbp.text_columns);
+
+    if ( !lfb.lbuf || !lfb.text_buf || !lfb.line_len )
+        goto fail;
+
+    return 0;
+
+fail:
+    printk(XENLOG_ERR "Couldn't allocate enough memory to drive the framebuffer\n");
+    lfb_free();
+
+    return -ENOMEM;
+}
+
+void lfb_free(void)
+{
+    xfree(lfb.lbuf);
+    xfree(lfb.text_buf);
+    xfree(lfb.line_len);
+}
diff --git a/xen/drivers/video/lfb.h b/xen/drivers/video/lfb.h
new file mode 100644
index 0000000..ac40a66
--- /dev/null
+++ b/xen/drivers/video/lfb.h
@@ -0,0 +1,46 @@
+/*
+ * xen/drivers/video/lfb.h
+ *
+ * Cross-platform framebuffer library
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Copyright (c) 2013 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#ifndef _XEN_LFB_H
+#define _XEN_LFB_H
+
+#include <xen/init.h>
+
+struct lfb_prop {
+    const struct font_desc *font;
+    unsigned char *lfb;
+    unsigned int pixel_on;
+    uint16_t width, height;
+    uint16_t bytes_per_line;
+    uint16_t bits_per_pixel;
+    void (*flush)(void);
+
+    unsigned int text_columns;
+    unsigned int text_rows;
+};
+
+void lfb_redraw_puts(const char *s);
+void lfb_scroll_puts(const char *s);
+void lfb_carriage_return(void);
+void lfb_free(void);
+
+/* initialize the framebuffer */
+int lfb_init(struct lfb_prop *lfbp);
+
+#endif
diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
index aaf8b23..1144f76 100644
--- a/xen/drivers/video/vesa.c
+++ b/xen/drivers/video/vesa.c
@@ -13,20 +13,15 @@
 #include <asm/io.h>
 #include <asm/page.h>
 #include "font.h"
+#include "lfb.h"
 
 #define vlfb_info    vga_console_info.u.vesa_lfb
-#define text_columns (vlfb_info.width / font->width)
-#define text_rows    (vlfb_info.height / font->height)
 
-static void vesa_redraw_puts(const char *s);
-static void vesa_scroll_puts(const char *s);
+static void lfb_flush(void);
 
-static unsigned char *lfb, *lbuf, *text_buf;
-static unsigned int *__initdata line_len;
+static unsigned char *lfb;
 static const struct font_desc *font;
 static bool_t vga_compat;
-static unsigned int pixel_on;
-static unsigned int xpos, ypos;
 
 static unsigned int vram_total;
 integer_param("vesa-ram", vram_total);
@@ -87,29 +82,26 @@ void __init vesa_early_init(void)
 
 void __init vesa_init(void)
 {
-    if ( !font )
-        goto fail;
-
-    lbuf = xmalloc_bytes(vlfb_info.bytes_per_line);
-    if ( !lbuf )
-        goto fail;
+    struct lfb_prop lfbp;
 
-    text_buf = xzalloc_bytes(text_columns * text_rows);
-    if ( !text_buf )
-        goto fail;
+    if ( !font )
+        return;
 
-    line_len = xzalloc_array(unsigned int, text_columns);
-    if ( !line_len )
-        goto fail;
+    lfbp.font = font;
+    lfbp.bits_per_pixel = vlfb_info.bits_per_pixel;
+    lfbp.bytes_per_line = vlfb_info.bytes_per_line;
+    lfbp.width = vlfb_info.width;
+    lfbp.height = vlfb_info.height;
+    lfbp.flush = lfb_flush;
+    lfbp.text_columns = vlfb_info.width / font->width;
+    lfbp.text_rows = vlfb_info.height / font->height;
 
-    lfb = ioremap(vlfb_info.lfb_base, vram_remap);
+    lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap);
     if ( !lfb )
-        goto fail;
+        return;
 
     memset(lfb, 0, vram_remap);
 
-    video_puts = vesa_redraw_puts;
-
     printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
            "using %uk, total %uk\n",
            vlfb_info.lfb_base, lfb,
@@ -131,7 +123,7 @@ void __init vesa_init(void)
     {
         /* Light grey in truecolor. */
         unsigned int grey = 0xaaaaaaaa;
-        pixel_on = 
+        fbp.pixel_on = 
             ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
             ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
             ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_pos);
@@ -139,15 +131,12 @@ void __init vesa_init(void)
     else
     {
         /* White(ish) in default pseudocolor palette. */
-        pixel_on = 7;
+        fbp.pixel_on = 7;
     }
 
-    return;
-
- fail:
-    xfree(lbuf);
-    xfree(text_buf);
-    xfree(line_len);
+    if ( lfb_init(&lfbp) < 0 )
+        return;
+    video_puts = lfb_redraw_puts;
 }
 
 #include <asm/mtrr.h>
@@ -192,8 +181,8 @@ void __init vesa_endboot(bool_t keep)
 {
     if ( keep )
     {
-        xpos = 0;
-        video_puts = vesa_scroll_puts;
+        video_puts = lfb_scroll_puts;
+        lfb_carriage_return();
     }
     else
     {
@@ -202,124 +191,6 @@ void __init vesa_endboot(bool_t keep)
             memset(lfb + i * vlfb_info.bytes_per_line, 0,
                    vlfb_info.width * bpp);
         lfb_flush();
+        lfb_free();
     }
-
-    xfree(line_len);
-}
-
-/* Render one line of text to given linear framebuffer line. */
-static void vesa_show_line(
-    const unsigned char *text_line,
-    unsigned char *video_line,
-    unsigned int nr_chars,
-    unsigned int nr_cells)
-{
-    unsigned int i, j, b, bpp, pixel;
-
-    bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
-
-    for ( i = 0; i < font->height; i++ )
-    {
-        unsigned char *ptr = lbuf;
-
-        for ( j = 0; j < nr_chars; j++ )
-        {
-            const unsigned char *bits = font->data;
-            bits += ((text_line[j] * font->height + i) *
-                     ((font->width + 7) >> 3));
-            for ( b = font->width; b--; )
-            {
-                pixel = (*bits & (1u<<b)) ? pixel_on : 0;
-                memcpy(ptr, &pixel, bpp);
-                ptr += bpp;
-            }
-        }
-
-        memset(ptr, 0, (vlfb_info.width - nr_chars * font->width) * bpp);
-        memcpy(video_line, lbuf, nr_cells * font->width * bpp);
-        video_line += vlfb_info.bytes_per_line;
-    }
-}
-
-/* Fast mode which redraws all modified parts of a 2D text buffer. */
-static void __init vesa_redraw_puts(const char *s)
-{
-    unsigned int i, min_redraw_y = ypos;
-    char c;
-
-    /* Paste characters into text buffer. */
-    while ( (c = *s++) != '\0' )
-    {
-        if ( (c == '\n') || (xpos >= text_columns) )
-        {
-            if ( ++ypos >= text_rows )
-            {
-                min_redraw_y = 0;
-                ypos = text_rows - 1;
-                memmove(text_buf, text_buf + text_columns,
-                        ypos * text_columns);
-                memset(text_buf + ypos * text_columns, 0, xpos);
-            }
-            xpos = 0;
-        }
-
-        if ( c != '\n' )
-            text_buf[xpos++ + ypos * text_columns] = c;
-    }
-
-    /* Render modified section of text buffer to VESA linear framebuffer. */
-    for ( i = min_redraw_y; i <= ypos; i++ )
-    {
-        const unsigned char *line = text_buf + i * text_columns;
-        unsigned int width;
-
-        for ( width = text_columns; width; --width )
-            if ( line[width - 1] )
-                 break;
-        vesa_show_line(line,
-                       lfb + i * font->height * vlfb_info.bytes_per_line,
-                       width, max(line_len[i], width));
-        line_len[i] = width;
-    }
-
-    lfb_flush();
-}
-
-/* Slower line-based scroll mode which interacts better with dom0. */
-static void vesa_scroll_puts(const char *s)
-{
-    unsigned int i;
-    char c;
-
-    while ( (c = *s++) != '\0' )
-    {
-        if ( (c == '\n') || (xpos >= text_columns) )
-        {
-            unsigned int bytes = (vlfb_info.width *
-                                  ((vlfb_info.bits_per_pixel + 7) >> 3));
-            unsigned char *src = lfb + font->height * vlfb_info.bytes_per_line;
-            unsigned char *dst = lfb;
-            
-            /* New line: scroll all previous rows up one line. */
-            for ( i = font->height; i < vlfb_info.height; i++ )
-            {
-                memcpy(dst, src, bytes);
-                src += vlfb_info.bytes_per_line;
-                dst += vlfb_info.bytes_per_line;
-            }
-
-            /* Render new line. */
-            vesa_show_line(
-                text_buf,
-                lfb + (text_rows-1) * font->height * vlfb_info.bytes_per_line,
-                xpos, text_columns);
-
-            xpos = 0;
-        }
-
-        if ( c != '\n' )
-            text_buf[xpos++] = c;
-    }
-
-    lfb_flush();
 }
-- 
1.7.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 Feb 14 17:32:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62fB-00018m-61; Thu, 14 Feb 2013 17:32: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 1U62f9-000180-1P
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:59 +0000
Received: from [85.158.139.83:18189] by server-7.bemta-5.messagelabs.com id
	A7/96-11121-E8F1D115; Thu, 14 Feb 2013 17:31:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360863112!23697605!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28763 invoked from network); 14 Feb 2013 17:31:53 -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;
	14 Feb 2013 17:31:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7169520"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-Da;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:41 +0000
Message-ID: <1360863042-19845-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 4/5] xen/arm: introduce vexpress_syscfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Versatile Express specific function to read/write
motherboard settings.


Changes in v5:
- actually include the Makefile.

Changes in v4:
- move the wait loop and the syscfg cfgctrl write into a separate
function;
- fix comments;
- define all registers in write;
- move platform_vexpress.c to platforms/vexpress.c;
- move platform_vexpress.h to arm-arm/platforms/vexpress.h.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile                    |    1 +
 xen/arch/arm/arm32/mode_switch.S         |    2 +-
 xen/arch/arm/platforms/Makefile          |    1 +
 xen/arch/arm/platforms/vexpress.c        |  100 ++++++++++++++++++++++++++++++
 xen/include/asm-arm/platform_vexpress.h  |   17 -----
 xen/include/asm-arm/platforms/vexpress.h |   40 ++++++++++++
 6 files changed, 143 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/platforms/Makefile
 create mode 100644 xen/arch/arm/platforms/vexpress.c
 delete mode 100644 xen/include/asm-arm/platform_vexpress.h
 create mode 100644 xen/include/asm-arm/platforms/vexpress.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f2822f2..3954dbb 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-y += platforms
 
 obj-y += early_printk.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm32/mode_switch.S b/xen/arch/arm/arm32/mode_switch.S
index 411eb92..bc2be74 100644
--- a/xen/arch/arm/arm32/mode_switch.S
+++ b/xen/arch/arm/arm32/mode_switch.S
@@ -19,7 +19,7 @@
 
 #include <asm/config.h>
 #include <asm/page.h>
-#include <asm/platform_vexpress.h>
+#include <asm/platforms/vexpress.h>
 #include <asm/asm_defns.h>
 #include <asm/gic.h>
 
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
new file mode 100644
index 0000000..4313e95
--- /dev/null
+++ b/xen/arch/arm/platforms/Makefile
@@ -0,0 +1 @@
+obj-y += vexpress.o
diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
new file mode 100644
index 0000000..b57b62e
--- /dev/null
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -0,0 +1,100 @@
+/*
+ * xen/arch/arm/platform_vexpress.c
+ *
+ * Versatile Express specific settings
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Copyright (c) 2013 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/platforms/vexpress.h>
+#include <xen/mm.h>
+
+#define DCC_SHIFT      26
+#define FUNCTION_SHIFT 20
+#define SITE_SHIFT     16
+#define POSITION_SHIFT 12
+#define DEVICE_SHIFT   0
+
+static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
+                                      int function, int device)
+{
+    int dcc = 0; /* DCC to access */
+    int site = 0; /* motherboard */
+    int position = 0; /* daughterboard */
+    uint32_t stat;
+
+    /* set control register */
+    syscfg[V2M_SYS_CFGCTRL/4] = V2M_SYS_CFG_START |
+        (write ? V2M_SYS_CFG_WRITE : 0) |
+        (dcc << DCC_SHIFT) | (function << FUNCTION_SHIFT) |
+        (site << SITE_SHIFT) | (position << POSITION_SHIFT) |
+        (device << DEVICE_SHIFT);
+
+    /* wait for complete flag to be set */
+    do {
+        stat = syscfg[V2M_SYS_CFGSTAT/4];
+        dsb();
+    } while ( !(stat & V2M_SYS_CFG_COMPLETE) );
+
+    /* check error status and return error flag if set */
+    if ( stat & V2M_SYS_CFG_ERROR )
+    {
+        printk(KERN_ERR "V2M SYS_CFGSTAT reported a configuration error\n");
+        return -1;
+    }
+    return 0;
+}
+
+int vexpress_syscfg(int write, int function, int device, uint32_t *data)
+{
+    uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+    int ret = -1;
+
+    set_fixmap(FIXMAP_MISC, V2M_SYS_MMIO_BASE >> PAGE_SHIFT, DEV_SHARED);
+
+    if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
+        goto out;
+
+    /* clear the complete bit in the V2M_SYS_CFGSTAT status register */
+    syscfg[V2M_SYS_CFGSTAT/4] = 0;
+
+    if ( write )
+    {
+        /* write data */
+        syscfg[V2M_SYS_CFGDATA/4] = *data;
+
+        if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
+            goto out;
+    } else {
+        if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
+            goto out;
+        else
+            /* read data */
+            *data = syscfg[V2M_SYS_CFGDATA/4];
+    }
+
+    ret = 0;
+out:
+    clear_fixmap(FIXMAP_MISC);
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/platform_vexpress.h b/xen/include/asm-arm/platform_vexpress.h
deleted file mode 100644
index 3556af3..0000000
--- a/xen/include/asm-arm/platform_vexpress.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef __ASM_ARM_PLATFORM_H
-#define __ASM_ARM_PLATFORM_H
-
-/* V2M */
-#define V2M_SYS_MMIO_BASE     (0x1c010000)
-#define V2M_SYS_FLAGSSET      (0x30)
-#define V2M_SYS_FLAGSCLR      (0x34)
-
-#endif /* __ASM_ARM_PLATFORM_H */
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/platforms/vexpress.h b/xen/include/asm-arm/platforms/vexpress.h
new file mode 100644
index 0000000..e464913
--- /dev/null
+++ b/xen/include/asm-arm/platforms/vexpress.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_ARM_PLATFORMS_VEXPRESS_H
+#define __ASM_ARM_PLATFORMS_VEXPRESS_H
+
+/* V2M */
+#define V2M_SYS_MMIO_BASE     (0x1c010000)
+#define V2M_SYS_FLAGSSET      (0x30)
+#define V2M_SYS_FLAGSCLR      (0x34)
+
+#define V2M_SYS_CFGDATA       (0x00A0)
+#define V2M_SYS_CFGCTRL       (0x00A4)
+#define V2M_SYS_CFGSTAT       (0x00A8)
+
+#define V2M_SYS_CFG_START     (1<<31)
+#define V2M_SYS_CFG_WRITE     (1<<30)
+#define V2M_SYS_CFG_ERROR     (1<<1)
+#define V2M_SYS_CFG_COMPLETE  (1<<0)
+
+#define V2M_SYS_CFG_OSC_FUNC  1
+#define V2M_SYS_CFG_OSC0      0
+#define V2M_SYS_CFG_OSC1      1
+#define V2M_SYS_CFG_OSC2      2
+#define V2M_SYS_CFG_OSC3      3
+#define V2M_SYS_CFG_OSC4      4
+#define V2M_SYS_CFG_OSC5      5
+
+#ifndef __ASSEMBLY__
+#include <xen/inttypes.h>
+
+int vexpress_syscfg(int write, int function, int device, uint32_t *data);
+#endif
+
+#endif /* __ASM_ARM_PLATFORMS_VEXPRESS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.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 Feb 14 17:32:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17: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 1U62fB-00018m-61; Thu, 14 Feb 2013 17:32: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 1U62f9-000180-1P
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:31:59 +0000
Received: from [85.158.139.83:18189] by server-7.bemta-5.messagelabs.com id
	A7/96-11121-E8F1D115; Thu, 14 Feb 2013 17:31:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360863112!23697605!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28763 invoked from network); 14 Feb 2013 17:31:53 -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;
	14 Feb 2013 17:31:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7169520"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:30:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:30:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62dz-0001vt-Da;
	Thu, 14 Feb 2013 17:30:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 17:30:41 +0000
Message-ID: <1360863042-19845-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v7 4/5] xen/arm: introduce vexpress_syscfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Versatile Express specific function to read/write
motherboard settings.


Changes in v5:
- actually include the Makefile.

Changes in v4:
- move the wait loop and the syscfg cfgctrl write into a separate
function;
- fix comments;
- define all registers in write;
- move platform_vexpress.c to platforms/vexpress.c;
- move platform_vexpress.h to arm-arm/platforms/vexpress.h.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile                    |    1 +
 xen/arch/arm/arm32/mode_switch.S         |    2 +-
 xen/arch/arm/platforms/Makefile          |    1 +
 xen/arch/arm/platforms/vexpress.c        |  100 ++++++++++++++++++++++++++++++
 xen/include/asm-arm/platform_vexpress.h  |   17 -----
 xen/include/asm-arm/platforms/vexpress.h |   40 ++++++++++++
 6 files changed, 143 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/platforms/Makefile
 create mode 100644 xen/arch/arm/platforms/vexpress.c
 delete mode 100644 xen/include/asm-arm/platform_vexpress.h
 create mode 100644 xen/include/asm-arm/platforms/vexpress.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f2822f2..3954dbb 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-y += platforms
 
 obj-y += early_printk.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm32/mode_switch.S b/xen/arch/arm/arm32/mode_switch.S
index 411eb92..bc2be74 100644
--- a/xen/arch/arm/arm32/mode_switch.S
+++ b/xen/arch/arm/arm32/mode_switch.S
@@ -19,7 +19,7 @@
 
 #include <asm/config.h>
 #include <asm/page.h>
-#include <asm/platform_vexpress.h>
+#include <asm/platforms/vexpress.h>
 #include <asm/asm_defns.h>
 #include <asm/gic.h>
 
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
new file mode 100644
index 0000000..4313e95
--- /dev/null
+++ b/xen/arch/arm/platforms/Makefile
@@ -0,0 +1 @@
+obj-y += vexpress.o
diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
new file mode 100644
index 0000000..b57b62e
--- /dev/null
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -0,0 +1,100 @@
+/*
+ * xen/arch/arm/platform_vexpress.c
+ *
+ * Versatile Express specific settings
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Copyright (c) 2013 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/platforms/vexpress.h>
+#include <xen/mm.h>
+
+#define DCC_SHIFT      26
+#define FUNCTION_SHIFT 20
+#define SITE_SHIFT     16
+#define POSITION_SHIFT 12
+#define DEVICE_SHIFT   0
+
+static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
+                                      int function, int device)
+{
+    int dcc = 0; /* DCC to access */
+    int site = 0; /* motherboard */
+    int position = 0; /* daughterboard */
+    uint32_t stat;
+
+    /* set control register */
+    syscfg[V2M_SYS_CFGCTRL/4] = V2M_SYS_CFG_START |
+        (write ? V2M_SYS_CFG_WRITE : 0) |
+        (dcc << DCC_SHIFT) | (function << FUNCTION_SHIFT) |
+        (site << SITE_SHIFT) | (position << POSITION_SHIFT) |
+        (device << DEVICE_SHIFT);
+
+    /* wait for complete flag to be set */
+    do {
+        stat = syscfg[V2M_SYS_CFGSTAT/4];
+        dsb();
+    } while ( !(stat & V2M_SYS_CFG_COMPLETE) );
+
+    /* check error status and return error flag if set */
+    if ( stat & V2M_SYS_CFG_ERROR )
+    {
+        printk(KERN_ERR "V2M SYS_CFGSTAT reported a configuration error\n");
+        return -1;
+    }
+    return 0;
+}
+
+int vexpress_syscfg(int write, int function, int device, uint32_t *data)
+{
+    uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
+    int ret = -1;
+
+    set_fixmap(FIXMAP_MISC, V2M_SYS_MMIO_BASE >> PAGE_SHIFT, DEV_SHARED);
+
+    if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
+        goto out;
+
+    /* clear the complete bit in the V2M_SYS_CFGSTAT status register */
+    syscfg[V2M_SYS_CFGSTAT/4] = 0;
+
+    if ( write )
+    {
+        /* write data */
+        syscfg[V2M_SYS_CFGDATA/4] = *data;
+
+        if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
+            goto out;
+    } else {
+        if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
+            goto out;
+        else
+            /* read data */
+            *data = syscfg[V2M_SYS_CFGDATA/4];
+    }
+
+    ret = 0;
+out:
+    clear_fixmap(FIXMAP_MISC);
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/platform_vexpress.h b/xen/include/asm-arm/platform_vexpress.h
deleted file mode 100644
index 3556af3..0000000
--- a/xen/include/asm-arm/platform_vexpress.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef __ASM_ARM_PLATFORM_H
-#define __ASM_ARM_PLATFORM_H
-
-/* V2M */
-#define V2M_SYS_MMIO_BASE     (0x1c010000)
-#define V2M_SYS_FLAGSSET      (0x30)
-#define V2M_SYS_FLAGSCLR      (0x34)
-
-#endif /* __ASM_ARM_PLATFORM_H */
-/*
- * Local variables:
- * mode: C
- * c-set-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/platforms/vexpress.h b/xen/include/asm-arm/platforms/vexpress.h
new file mode 100644
index 0000000..e464913
--- /dev/null
+++ b/xen/include/asm-arm/platforms/vexpress.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_ARM_PLATFORMS_VEXPRESS_H
+#define __ASM_ARM_PLATFORMS_VEXPRESS_H
+
+/* V2M */
+#define V2M_SYS_MMIO_BASE     (0x1c010000)
+#define V2M_SYS_FLAGSSET      (0x30)
+#define V2M_SYS_FLAGSCLR      (0x34)
+
+#define V2M_SYS_CFGDATA       (0x00A0)
+#define V2M_SYS_CFGCTRL       (0x00A4)
+#define V2M_SYS_CFGSTAT       (0x00A8)
+
+#define V2M_SYS_CFG_START     (1<<31)
+#define V2M_SYS_CFG_WRITE     (1<<30)
+#define V2M_SYS_CFG_ERROR     (1<<1)
+#define V2M_SYS_CFG_COMPLETE  (1<<0)
+
+#define V2M_SYS_CFG_OSC_FUNC  1
+#define V2M_SYS_CFG_OSC0      0
+#define V2M_SYS_CFG_OSC1      1
+#define V2M_SYS_CFG_OSC2      2
+#define V2M_SYS_CFG_OSC3      3
+#define V2M_SYS_CFG_OSC4      4
+#define V2M_SYS_CFG_OSC5      5
+
+#ifndef __ASSEMBLY__
+#include <xen/inttypes.h>
+
+int vexpress_syscfg(int write, int function, int device, uint32_t *data);
+#endif
+
+#endif /* __ASM_ARM_PLATFORMS_VEXPRESS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.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 Feb 14 17:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:32: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 1U62fV-0001IJ-6H; Thu, 14 Feb 2013 17:32:21 +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 1U62fT-0001H9-ND
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:32:19 +0000
Received: from [85.158.138.51:63889] by server-14.bemta-3.messagelabs.com id
	31/D2-23533-2AF1D115; Thu, 14 Feb 2013 17:32:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360863136!19519251!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4287 invoked from network); 14 Feb 2013 17:32:18 -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;
	14 Feb 2013 17:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7169780"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:32:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:32:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62fP-0001wz-VJ;
	Thu, 14 Feb 2013 17:32:15 +0000
Date: Thu, 14 Feb 2013 17:32:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1360863042-19845-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1302141731430.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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] [PATCH v7 2/5] xen/arm: move setup_mm right after
 setup_pagetables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Stefano Stabellini wrote:
> At the moment we destroy the DTB mappings we have in setup_pagetables
> and we restore them only in setup_mm.
> 
> Move setup_mm right after setup_pagetables.
> This ensures we have a valid DTB mapping while running the subsequent
> initialization code.
> 
> Changes in v7:
> - turn more printk's into early_printk.

I forgot to mention in the changelog that I removed two printks
from init_boot_pages.


> Changes in v5:
> - reword commit message;
> - turn printk in setup_mm into an early_printk.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/setup.c    |    7 +++----
>  xen/common/page_alloc.c |    6 ------
>  2 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index e1ab7f6..c568be5 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -246,11 +246,11 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
>      } while ( xenheap_pages > 128<<(20-PAGE_SHIFT) );
>  
>      if ( ! e )
> -        panic("Not not enough space for xenheap\n");
> +        early_panic("Not not enough space for xenheap\n");
>  
>      domheap_pages = heap_pages - xenheap_pages;
>  
> -    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
> +    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
>  
>      setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
>  
> @@ -349,6 +349,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>      cmdline_parse(device_tree_bootargs(fdt));
>  
>      setup_pagetables(boot_phys_offset, get_xen_paddr());
> +    setup_mm(atag_paddr, fdt_size);
>  
>  #ifdef EARLY_UART_ADDRESS
>      /* TODO Need to get device tree or command line for UART address */
> @@ -366,8 +367,6 @@ void __init start_xen(unsigned long boot_phys_offset,
>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>      idle_vcpu[0] = current;
>  
> -    setup_mm(atag_paddr, fdt_size);
> -
>      /* Setup Hyp vector base */
>      WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
>      printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 6b8bc39..6c2215b 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -182,12 +182,6 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
>          else if ( *p != '\0' )
>              break;
>  
> -        if ( bad_epfn == bad_spfn )
> -            printk("Marking page %lx as bad\n", bad_spfn);
> -        else
> -            printk("Marking pages %lx through %lx as bad\n",
> -                   bad_spfn, bad_epfn);
> -
>          bootmem_region_zap(bad_spfn, bad_epfn+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 Thu Feb 14 17:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:32: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 1U62fV-0001IJ-6H; Thu, 14 Feb 2013 17:32:21 +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 1U62fT-0001H9-ND
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 17:32:19 +0000
Received: from [85.158.138.51:63889] by server-14.bemta-3.messagelabs.com id
	31/D2-23533-2AF1D115; Thu, 14 Feb 2013 17:32:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360863136!19519251!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4287 invoked from network); 14 Feb 2013 17:32:18 -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;
	14 Feb 2013 17:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7169780"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 17:32:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 12:32:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U62fP-0001wz-VJ;
	Thu, 14 Feb 2013 17:32:15 +0000
Date: Thu, 14 Feb 2013 17:32:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1360863042-19845-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1302141731430.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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] [PATCH v7 2/5] xen/arm: move setup_mm right after
 setup_pagetables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Stefano Stabellini wrote:
> At the moment we destroy the DTB mappings we have in setup_pagetables
> and we restore them only in setup_mm.
> 
> Move setup_mm right after setup_pagetables.
> This ensures we have a valid DTB mapping while running the subsequent
> initialization code.
> 
> Changes in v7:
> - turn more printk's into early_printk.

I forgot to mention in the changelog that I removed two printks
from init_boot_pages.


> Changes in v5:
> - reword commit message;
> - turn printk in setup_mm into an early_printk.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/setup.c    |    7 +++----
>  xen/common/page_alloc.c |    6 ------
>  2 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index e1ab7f6..c568be5 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -246,11 +246,11 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
>      } while ( xenheap_pages > 128<<(20-PAGE_SHIFT) );
>  
>      if ( ! e )
> -        panic("Not not enough space for xenheap\n");
> +        early_panic("Not not enough space for xenheap\n");
>  
>      domheap_pages = heap_pages - xenheap_pages;
>  
> -    printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
> +    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
>  
>      setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
>  
> @@ -349,6 +349,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>      cmdline_parse(device_tree_bootargs(fdt));
>  
>      setup_pagetables(boot_phys_offset, get_xen_paddr());
> +    setup_mm(atag_paddr, fdt_size);
>  
>  #ifdef EARLY_UART_ADDRESS
>      /* TODO Need to get device tree or command line for UART address */
> @@ -366,8 +367,6 @@ void __init start_xen(unsigned long boot_phys_offset,
>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>      idle_vcpu[0] = current;
>  
> -    setup_mm(atag_paddr, fdt_size);
> -
>      /* Setup Hyp vector base */
>      WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
>      printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 6b8bc39..6c2215b 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -182,12 +182,6 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
>          else if ( *p != '\0' )
>              break;
>  
> -        if ( bad_epfn == bad_spfn )
> -            printk("Marking page %lx as bad\n", bad_spfn);
> -        else
> -            printk("Marking pages %lx through %lx as bad\n",
> -                   bad_spfn, bad_epfn);
> -
>          bootmem_region_zap(bad_spfn, bad_epfn+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 Thu Feb 14 17:43:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:43: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 1U62pd-0002lF-22; Thu, 14 Feb 2013 17:42:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U62pc-0002lA-1X
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:42:48 +0000
Received: from [85.158.139.211:3157] by server-16.bemta-5.messagelabs.com id
	A9/0E-14948-7122D115; Thu, 14 Feb 2013 17:42:47 +0000
X-Env-Sender: BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360863765!22249669!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTc5MDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 825 invoked from network); 14 Feb 2013 17:42:46 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 17:42:46 -0000
Received: from shinybook.infradead.org ([2001:8b0:10b:1:e6ce:8fff:fe1f:f2c0])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U62pR-0000UB-Vr; Thu, 14 Feb 2013 17:42:38 +0000
Message-ID: <1360863751.10581.270.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Thu, 14 Feb 2013 17:42:31 +0000
In-Reply-To: <1360860396.20449.471.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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: multipart/mixed; boundary="===============1638528783955529126=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1638528783955529126==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-xAV3N/vNUa7k+UCRO72B"


--=-xAV3N/vNUa7k+UCRO72B
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 16:46 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
> > git.infradead.org/users/dwmw2/seabios.git
> >=20
> > There's a README.CSM file in the SeaBIOS tree which describes how to
> > build OVMF with CSM support.
>=20
> Do I understand correctly from the README that once CSM support is
> enabled at build time you can choose to use it dynamically at boot time?
> If so, Neat!

Right. It's just another boot target. The UEFI device path for each of
the bot targets, and the bootorder variable which sets their relative
priorities, are stored in persistent nvram storage...

> I suppose this selection is persistent for a given VM, but where is it
> saved?

That's another item on my TODO list. On real hardware it's actually
stored in flash. On OVMF we don't have an answer. There's a dirty hack
which stores them in a *file* on the EFI system partition, but that
really isn't very helpful it stops working when the OS calls
ExitBootServices =E2=80=94 because you can't be touching the file system at=
 the
same time the OS might be. So when an OS installer does its install and
then sets the NV variables to boot into the newly-installed OS... it
can't work.

There was some initial work on supporting -pflash for qemu on i386 and
working exactly like real hardware does =E2=80=94 which meant firmware upgr=
ades
had to be done the same way since the firmware and the variables were
all in the same image. And it didn't work with KVM.

I'm looking at fixing this to use a flash device *other* than the one
that the firmware runs from, adjacent to it at the top of memory. Or
something like that. But it's not quite solved yet. It'll *need* to be,
for OVMF to be usable in the general case. And then it's solved
automatically for CSM too.

--=20
dwmw2


--=-xAV3N/vNUa7k+UCRO72B
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE0MTc0MjMxWjAjBgkqhkiG9w0BCQQx
FgQUkY3+RhDSbMlU0ngpVJOj6d0xEwUwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQBOGvETbiaK8Nap+Q/zngO9rA6h
6Z7X0IT3OjIgWTMtavrIq0j4PGZSJrXQylwusHO5xOz5ICNmlfgs5kV2NAErSFsl3t1Yj0kH1IWn
BhllhD6Dc3gO09m29Bkwi5UnovxGljNBjauopSYX3Gdsbocr6DBy5xtYCa6rk+pYew94hbbU0Maj
eVu8MCdXzOLXjbUS9UE3iaUdNRVu0os0vwrEbRPCv+VKH7n+tKmxYeSze/ci8wvCs/GmHDh03IVd
stwHDgqpeY/wfxJoHpXOjZHddHk4rAp8d0U0VwQ2/WNH9KJoCfBqltSZ8EOEzA9b1hAfZ/GElVT/
AfEcoXrpV2C2AAAAAAAA


--=-xAV3N/vNUa7k+UCRO72B--



--===============1638528783955529126==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1638528783955529126==--



From xen-devel-bounces@lists.xen.org Thu Feb 14 17:43:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 17:43: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 1U62pd-0002lF-22; Thu, 14 Feb 2013 17:42:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U62pc-0002lA-1X
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 17:42:48 +0000
Received: from [85.158.139.211:3157] by server-16.bemta-5.messagelabs.com id
	A9/0E-14948-7122D115; Thu, 14 Feb 2013 17:42:47 +0000
X-Env-Sender: BATV+45100fbe0682edf5f6a7+3462+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360863765!22249669!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTc5MDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 825 invoked from network); 14 Feb 2013 17:42:46 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Feb 2013 17:42:46 -0000
Received: from shinybook.infradead.org ([2001:8b0:10b:1:e6ce:8fff:fe1f:f2c0])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U62pR-0000UB-Vr; Thu, 14 Feb 2013 17:42:38 +0000
Message-ID: <1360863751.10581.270.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Thu, 14 Feb 2013 17:42:31 +0000
In-Reply-To: <1360860396.20449.471.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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: multipart/mixed; boundary="===============1638528783955529126=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1638528783955529126==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-xAV3N/vNUa7k+UCRO72B"


--=-xAV3N/vNUa7k+UCRO72B
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 16:46 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
> > git.infradead.org/users/dwmw2/seabios.git
> >=20
> > There's a README.CSM file in the SeaBIOS tree which describes how to
> > build OVMF with CSM support.
>=20
> Do I understand correctly from the README that once CSM support is
> enabled at build time you can choose to use it dynamically at boot time?
> If so, Neat!

Right. It's just another boot target. The UEFI device path for each of
the bot targets, and the bootorder variable which sets their relative
priorities, are stored in persistent nvram storage...

> I suppose this selection is persistent for a given VM, but where is it
> saved?

That's another item on my TODO list. On real hardware it's actually
stored in flash. On OVMF we don't have an answer. There's a dirty hack
which stores them in a *file* on the EFI system partition, but that
really isn't very helpful it stops working when the OS calls
ExitBootServices =E2=80=94 because you can't be touching the file system at=
 the
same time the OS might be. So when an OS installer does its install and
then sets the NV variables to boot into the newly-installed OS... it
can't work.

There was some initial work on supporting -pflash for qemu on i386 and
working exactly like real hardware does =E2=80=94 which meant firmware upgr=
ades
had to be done the same way since the firmware and the variables were
all in the same image. And it didn't work with KVM.

I'm looking at fixing this to use a flash device *other* than the one
that the firmware runs from, adjacent to it at the top of memory. Or
something like that. But it's not quite solved yet. It'll *need* to be,
for OVMF to be usable in the general case. And then it's solved
automatically for CSM too.

--=20
dwmw2


--=-xAV3N/vNUa7k+UCRO72B
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE0MTc0MjMxWjAjBgkqhkiG9w0BCQQx
FgQUkY3+RhDSbMlU0ngpVJOj6d0xEwUwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQBOGvETbiaK8Nap+Q/zngO9rA6h
6Z7X0IT3OjIgWTMtavrIq0j4PGZSJrXQylwusHO5xOz5ICNmlfgs5kV2NAErSFsl3t1Yj0kH1IWn
BhllhD6Dc3gO09m29Bkwi5UnovxGljNBjauopSYX3Gdsbocr6DBy5xtYCa6rk+pYew94hbbU0Maj
eVu8MCdXzOLXjbUS9UE3iaUdNRVu0os0vwrEbRPCv+VKH7n+tKmxYeSze/ci8wvCs/GmHDh03IVd
stwHDgqpeY/wfxJoHpXOjZHddHk4rAp8d0U0VwQ2/WNH9KJoCfBqltSZ8EOEzA9b1hAfZ/GElVT/
AfEcoXrpV2C2AAAAAAAA


--=-xAV3N/vNUa7k+UCRO72B--



--===============1638528783955529126==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1638528783955529126==--



From xen-devel-bounces@lists.xen.org Thu Feb 14 18:07:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Ct-0003bC-Nh; Thu, 14 Feb 2013 18:06:51 +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 1U63Cs-0003ai-FI
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:50 +0000
Received: from [85.158.143.35:62817] by server-2.bemta-4.messagelabs.com id
	8B/38-01597-9B72D115; Thu, 14 Feb 2013 18:06:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6947 invoked from network); 14 Feb 2013 18:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545090"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-Em;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:30 +0000
Message-ID: <1360865193-22148-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/4] xen: move XEN_SYSCTL_physinfo,
	XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common 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

Move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and
XEN_SYSCTL_topologyinfo from x86/sysctl.c to common/sysctl.c.

The implementation of XEN_SYSCTL_physinfo is mostly generic but needs to
fill in few arch specific details: introduce arch_do_physinfo to do that.

The implementation of XEN_SYSCTL_physinfo relies on two global
variables: total_pages and cpu_khz. Make them available on ARM.

Implement node_spanned_pages and __node_distance on ARM, assuming 1 numa
node for now.

Changes in v3:
- move node_spanned_pages and __node_distance definitions to numa.h.

Changes in v2:
- cpu_khz is khz while cntfrq is hz: take care of the conversion;
- rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/mm.c          |    1 +
 xen/arch/arm/setup.c       |    2 +-
 xen/arch/arm/sysctl.c      |    2 +
 xen/arch/arm/time.c        |   10 ++--
 xen/arch/x86/sysctl.c      |  123 +++----------------------------------------
 xen/common/sysctl.c        |  109 +++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/numa.h |    4 ++
 xen/include/xen/sched.h    |    2 +
 8 files changed, 133 insertions(+), 120 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7621d1b..f1011b9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -59,6 +59,7 @@ unsigned long frametable_base_mfn __read_mostly;
 unsigned long frametable_virt_end __read_mostly;
 
 unsigned long max_page;
+unsigned long total_pages;
 
 extern char __init_begin[], __init_end[];
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 52d2e7a..389bdac 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -219,7 +219,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     ram_start = early_info.mem.bank[0].start;
     ram_size  = early_info.mem.bank[0].size;
     ram_end = ram_start + ram_size;
-    ram_pages = ram_size >> PAGE_SHIFT;
+    total_pages = ram_pages = ram_size >> PAGE_SHIFT;
 
     /*
      * Locate the xenheap using these constraints:
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index a286abe..a5d9cf0 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,6 +12,8 @@
 #include <xen/errno.h>
 #include <public/sysctl.h>
 
+void arch_do_physinfo(xen_sysctl_physinfo_t *pi) { }
+
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 07628e1..3dad9b3 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -43,16 +43,16 @@ uint64_t __read_mostly boot_count;
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
 
 /*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
 {
-    return muldiv64(ticks, SECONDS(1), cntfrq);
+    return muldiv64(ticks, SECONDS(1), 1000 * cpu_khz);
 }
 
 /*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
 {
-    return muldiv64(ns, cntfrq, SECONDS(1));
+    return muldiv64(ns, 1000 * cpu_khz, SECONDS(1));
 }
 
 /* TODO: On a real system the firmware would have set the frequency in
@@ -93,9 +93,9 @@ int __init init_xen_time(void)
     if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
         panic("CPU does not support the Generic Timer v1 interface.\n");
 
-    cntfrq = READ_CP32(CNTFRQ);
+    cpu_khz = READ_CP32(CNTFRQ) / 1000;
     boot_count = READ_CP64(CNTPCT);
-    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+    printk("Using generic timer at %lu KHz\n", cpu_khz);
 
     return 0;
 }
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index d0be4be..b4d3e32 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -57,6 +57,15 @@ long cpu_down_helper(void *data)
     return ret;
 }
 
+void arch_do_physinfo(xen_sysctl_physinfo_t *pi)
+{
+    memcpy(pi->hw_cap, boot_cpu_data.x86_capability, NCAPINTS*4);
+    if ( hvm_enabled )
+        pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
+    if ( iommu_enabled )
+        pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
+}
+
 long arch_do_sysctl(
     struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -65,120 +74,6 @@ long arch_do_sysctl(
     switch ( sysctl->cmd )
     {
 
-    case XEN_SYSCTL_physinfo:
-    {
-        xen_sysctl_physinfo_t *pi = &sysctl->u.physinfo;
-
-        memset(pi, 0, sizeof(*pi));
-        pi->threads_per_core =
-            cpumask_weight(per_cpu(cpu_sibling_mask, 0));
-        pi->cores_per_socket =
-            cpumask_weight(per_cpu(cpu_core_mask, 0)) / pi->threads_per_core;
-        pi->nr_cpus = num_online_cpus();
-        pi->nr_nodes = num_online_nodes();
-        pi->max_node_id = MAX_NUMNODES-1;
-        pi->max_cpu_id = nr_cpu_ids - 1;
-        pi->total_pages = total_pages;
-        pi->free_pages = avail_domheap_pages();
-        pi->scrub_pages = 0;
-        pi->cpu_khz = cpu_khz;
-        memcpy(pi->hw_cap, boot_cpu_data.x86_capability, NCAPINTS*4);
-        if ( hvm_enabled )
-            pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
-        if ( iommu_enabled )
-            pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
-
-        if ( __copy_field_to_guest(u_sysctl, sysctl, u.physinfo) )
-            ret = -EFAULT;
-    }
-    break;
-        
-    case XEN_SYSCTL_topologyinfo:
-    {
-        uint32_t i, max_cpu_index, last_online_cpu;
-        xen_sysctl_topologyinfo_t *ti = &sysctl->u.topologyinfo;
-
-        last_online_cpu = cpumask_last(&cpu_online_map);
-        max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
-        ti->max_cpu_index = last_online_cpu;
-
-        for ( i = 0; i <= max_cpu_index; i++ )
-        {
-            if ( !guest_handle_is_null(ti->cpu_to_core) )
-            {
-                uint32_t core = cpu_online(i) ? cpu_to_core(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_core, i, &core, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ti->cpu_to_socket) )
-            {
-                uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_socket, i, &socket, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ti->cpu_to_node) )
-            {
-                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_node, i, &node, 1) )
-                    break;
-            }
-        }
-
-        ret = ((i <= max_cpu_index) ||
-               __copy_field_to_guest(u_sysctl, sysctl, u.topologyinfo))
-            ? -EFAULT : 0;
-    }
-    break;
-
-    case XEN_SYSCTL_numainfo:
-    {
-        uint32_t i, j, max_node_index, last_online_node;
-        xen_sysctl_numainfo_t *ni = &sysctl->u.numainfo;
-
-        last_online_node = last_node(node_online_map);
-        max_node_index = min_t(uint32_t, ni->max_node_index, last_online_node);
-        ni->max_node_index = last_online_node;
-
-        for ( i = 0; i <= max_node_index; i++ )
-        {
-            if ( !guest_handle_is_null(ni->node_to_memsize) )
-            {
-                uint64_t memsize = node_online(i) ? 
-                                   node_spanned_pages(i) << PAGE_SHIFT : 0ul;
-                if ( copy_to_guest_offset(ni->node_to_memsize, i, &memsize, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ni->node_to_memfree) )
-            {
-                uint64_t memfree = node_online(i) ? 
-                                   avail_node_heap_pages(i) << PAGE_SHIFT : 0ul;
-                if ( copy_to_guest_offset(ni->node_to_memfree, i, &memfree, 1) )
-                    break;
-            }
-
-            if ( !guest_handle_is_null(ni->node_to_node_distance) )
-            {
-                for ( j = 0; j <= max_node_index; j++)
-                {
-                    uint32_t distance = ~0u;
-                    if ( node_online(i) && node_online(j) )
-                        distance = __node_distance(i, j);
-                    if ( copy_to_guest_offset(
-                        ni->node_to_node_distance, 
-                        i*(max_node_index+1) + j, &distance, 1) )
-                        break;
-                }
-                if ( j <= max_node_index )
-                    break;
-            }
-        }
-
-        ret = ((i <= max_node_index) ||
-               __copy_field_to_guest(u_sysctl, sysctl, u.numainfo))
-            ? -EFAULT : 0;
-    }
-    break;
-    
     case XEN_SYSCTL_cpu_hotplug:
     {
         unsigned int cpu = sysctl->u.cpu_hotplug.cpu;
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..20bb864 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -249,6 +249,115 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_physinfo:
+    {
+        xen_sysctl_physinfo_t *pi = &op->u.physinfo;
+
+        memset(pi, 0, sizeof(*pi));
+        pi->threads_per_core =
+            cpumask_weight(per_cpu(cpu_sibling_mask, 0));
+        pi->cores_per_socket =
+            cpumask_weight(per_cpu(cpu_core_mask, 0)) / pi->threads_per_core;
+        pi->nr_cpus = num_online_cpus();
+        pi->nr_nodes = num_online_nodes();
+        pi->max_node_id = MAX_NUMNODES-1;
+        pi->max_cpu_id = nr_cpu_ids - 1;
+        pi->total_pages = total_pages;
+        pi->free_pages = avail_domheap_pages();
+        pi->scrub_pages = 0;
+        pi->cpu_khz = cpu_khz;
+        arch_do_physinfo(pi);
+
+        if ( copy_to_guest(u_sysctl, op, 1) )
+            ret = -EFAULT;
+    }
+    break;
+
+    case XEN_SYSCTL_numainfo:
+    {
+        uint32_t i, j, max_node_index, last_online_node;
+        xen_sysctl_numainfo_t *ni = &op->u.numainfo;
+
+        last_online_node = last_node(node_online_map);
+        max_node_index = min_t(uint32_t, ni->max_node_index, last_online_node);
+        ni->max_node_index = last_online_node;
+
+        for ( i = 0; i <= max_node_index; i++ )
+        {
+            if ( !guest_handle_is_null(ni->node_to_memsize) )
+            {
+                uint64_t memsize = node_online(i) ?
+                                   node_spanned_pages(i) << PAGE_SHIFT : 0ul;
+                if ( copy_to_guest_offset(ni->node_to_memsize, i, &memsize, 1) )
+                    break;
+            }
+            if ( !guest_handle_is_null(ni->node_to_memfree) )
+            {
+                uint64_t memfree = node_online(i) ?
+                                   avail_node_heap_pages(i) << PAGE_SHIFT : 0ul;
+                if ( copy_to_guest_offset(ni->node_to_memfree, i, &memfree, 1) )
+                    break;
+            }
+
+            if ( !guest_handle_is_null(ni->node_to_node_distance) )
+            {
+                for ( j = 0; j <= max_node_index; j++)
+                {
+                    uint32_t distance = ~0u;
+                    if ( node_online(i) && node_online(j) )
+                        distance = __node_distance(i, j);
+                    if ( copy_to_guest_offset(
+                        ni->node_to_node_distance,
+                        i*(max_node_index+1) + j, &distance, 1) )
+                        break;
+                }
+                if ( j <= max_node_index )
+                    break;
+            }
+        }
+
+        ret = ((i <= max_node_index) || copy_to_guest(u_sysctl, op, 1))
+            ? -EFAULT : 0;
+    }
+    break;
+
+    case XEN_SYSCTL_topologyinfo:
+    {
+        uint32_t i, max_cpu_index, last_online_cpu;
+        xen_sysctl_topologyinfo_t *ti = &op->u.topologyinfo;
+
+        last_online_cpu = cpumask_last(&cpu_online_map);
+        max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
+        ti->max_cpu_index = last_online_cpu;
+
+        for ( i = 0; i <= max_cpu_index; i++ )
+        {
+            if ( !guest_handle_is_null(ti->cpu_to_core) )
+            {
+                uint32_t core = cpu_online(i) ? cpu_to_core(i) : ~0u;
+                if ( copy_to_guest_offset(ti->cpu_to_core, i, &core, 1) )
+                    break;
+            }
+            if ( !guest_handle_is_null(ti->cpu_to_socket) )
+            {
+                uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
+                if ( copy_to_guest_offset(ti->cpu_to_socket, i, &socket, 1) )
+                    break;
+            }
+            if ( !guest_handle_is_null(ti->cpu_to_node) )
+            {
+                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
+                if ( copy_to_guest_offset(ti->cpu_to_node, i, &node, 1) )
+                    break;
+            }
+        }
+
+        ret = ((i <= max_cpu_index) || copy_to_guest(u_sysctl, op, 1))
+            ? -EFAULT : 0;
+    }
+    break;
+
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a1b1f58..86f0183 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -10,6 +10,10 @@ static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
     return 0;
 }
 
+/* XXX: implement NUMA support */
+#define node_spanned_pages(nid)	(total_pages)
+#define __node_distance(a, b) (20)
+
 #endif /* __ARCH_ARM_NUMA_H */
 /*
  * Local variables:
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 90a6537..ba0f2f8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -748,6 +748,8 @@ extern void dump_runq(unsigned char key);
 
 #define num_cpupool_cpus(c) cpumask_weight((c)->cpu_valid)
 
+void arch_do_physinfo(xen_sysctl_physinfo_t *pi);
+
 #endif /* __SCHED_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 Thu Feb 14 18:07:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Ct-0003bC-Nh; Thu, 14 Feb 2013 18:06:51 +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 1U63Cs-0003ai-FI
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:50 +0000
Received: from [85.158.143.35:62817] by server-2.bemta-4.messagelabs.com id
	8B/38-01597-9B72D115; Thu, 14 Feb 2013 18:06:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6947 invoked from network); 14 Feb 2013 18:06:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545090"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-Em;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:30 +0000
Message-ID: <1360865193-22148-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/4] xen: move XEN_SYSCTL_physinfo,
	XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common 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

Move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and
XEN_SYSCTL_topologyinfo from x86/sysctl.c to common/sysctl.c.

The implementation of XEN_SYSCTL_physinfo is mostly generic but needs to
fill in few arch specific details: introduce arch_do_physinfo to do that.

The implementation of XEN_SYSCTL_physinfo relies on two global
variables: total_pages and cpu_khz. Make them available on ARM.

Implement node_spanned_pages and __node_distance on ARM, assuming 1 numa
node for now.

Changes in v3:
- move node_spanned_pages and __node_distance definitions to numa.h.

Changes in v2:
- cpu_khz is khz while cntfrq is hz: take care of the conversion;
- rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/mm.c          |    1 +
 xen/arch/arm/setup.c       |    2 +-
 xen/arch/arm/sysctl.c      |    2 +
 xen/arch/arm/time.c        |   10 ++--
 xen/arch/x86/sysctl.c      |  123 +++----------------------------------------
 xen/common/sysctl.c        |  109 +++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/numa.h |    4 ++
 xen/include/xen/sched.h    |    2 +
 8 files changed, 133 insertions(+), 120 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7621d1b..f1011b9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -59,6 +59,7 @@ unsigned long frametable_base_mfn __read_mostly;
 unsigned long frametable_virt_end __read_mostly;
 
 unsigned long max_page;
+unsigned long total_pages;
 
 extern char __init_begin[], __init_end[];
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 52d2e7a..389bdac 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -219,7 +219,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     ram_start = early_info.mem.bank[0].start;
     ram_size  = early_info.mem.bank[0].size;
     ram_end = ram_start + ram_size;
-    ram_pages = ram_size >> PAGE_SHIFT;
+    total_pages = ram_pages = ram_size >> PAGE_SHIFT;
 
     /*
      * Locate the xenheap using these constraints:
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index a286abe..a5d9cf0 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,6 +12,8 @@
 #include <xen/errno.h>
 #include <public/sysctl.h>
 
+void arch_do_physinfo(xen_sysctl_physinfo_t *pi) { }
+
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 07628e1..3dad9b3 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -43,16 +43,16 @@ uint64_t __read_mostly boot_count;
 
 /* For fine-grained timekeeping, we use the ARM "Generic Timer", a
  * register-mapped time source in the SoC. */
-static uint32_t __read_mostly cntfrq;      /* Ticks per second */
+unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
 
 /*static inline*/ s_time_t ticks_to_ns(uint64_t ticks)
 {
-    return muldiv64(ticks, SECONDS(1), cntfrq);
+    return muldiv64(ticks, SECONDS(1), 1000 * cpu_khz);
 }
 
 /*static inline*/ uint64_t ns_to_ticks(s_time_t ns)
 {
-    return muldiv64(ns, cntfrq, SECONDS(1));
+    return muldiv64(ns, 1000 * cpu_khz, SECONDS(1));
 }
 
 /* TODO: On a real system the firmware would have set the frequency in
@@ -93,9 +93,9 @@ int __init init_xen_time(void)
     if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
         panic("CPU does not support the Generic Timer v1 interface.\n");
 
-    cntfrq = READ_CP32(CNTFRQ);
+    cpu_khz = READ_CP32(CNTFRQ) / 1000;
     boot_count = READ_CP64(CNTPCT);
-    printk("Using generic timer at %"PRIu32" Hz\n", cntfrq);
+    printk("Using generic timer at %lu KHz\n", cpu_khz);
 
     return 0;
 }
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index d0be4be..b4d3e32 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -57,6 +57,15 @@ long cpu_down_helper(void *data)
     return ret;
 }
 
+void arch_do_physinfo(xen_sysctl_physinfo_t *pi)
+{
+    memcpy(pi->hw_cap, boot_cpu_data.x86_capability, NCAPINTS*4);
+    if ( hvm_enabled )
+        pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
+    if ( iommu_enabled )
+        pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
+}
+
 long arch_do_sysctl(
     struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -65,120 +74,6 @@ long arch_do_sysctl(
     switch ( sysctl->cmd )
     {
 
-    case XEN_SYSCTL_physinfo:
-    {
-        xen_sysctl_physinfo_t *pi = &sysctl->u.physinfo;
-
-        memset(pi, 0, sizeof(*pi));
-        pi->threads_per_core =
-            cpumask_weight(per_cpu(cpu_sibling_mask, 0));
-        pi->cores_per_socket =
-            cpumask_weight(per_cpu(cpu_core_mask, 0)) / pi->threads_per_core;
-        pi->nr_cpus = num_online_cpus();
-        pi->nr_nodes = num_online_nodes();
-        pi->max_node_id = MAX_NUMNODES-1;
-        pi->max_cpu_id = nr_cpu_ids - 1;
-        pi->total_pages = total_pages;
-        pi->free_pages = avail_domheap_pages();
-        pi->scrub_pages = 0;
-        pi->cpu_khz = cpu_khz;
-        memcpy(pi->hw_cap, boot_cpu_data.x86_capability, NCAPINTS*4);
-        if ( hvm_enabled )
-            pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
-        if ( iommu_enabled )
-            pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
-
-        if ( __copy_field_to_guest(u_sysctl, sysctl, u.physinfo) )
-            ret = -EFAULT;
-    }
-    break;
-        
-    case XEN_SYSCTL_topologyinfo:
-    {
-        uint32_t i, max_cpu_index, last_online_cpu;
-        xen_sysctl_topologyinfo_t *ti = &sysctl->u.topologyinfo;
-
-        last_online_cpu = cpumask_last(&cpu_online_map);
-        max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
-        ti->max_cpu_index = last_online_cpu;
-
-        for ( i = 0; i <= max_cpu_index; i++ )
-        {
-            if ( !guest_handle_is_null(ti->cpu_to_core) )
-            {
-                uint32_t core = cpu_online(i) ? cpu_to_core(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_core, i, &core, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ti->cpu_to_socket) )
-            {
-                uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_socket, i, &socket, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ti->cpu_to_node) )
-            {
-                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
-                if ( copy_to_guest_offset(ti->cpu_to_node, i, &node, 1) )
-                    break;
-            }
-        }
-
-        ret = ((i <= max_cpu_index) ||
-               __copy_field_to_guest(u_sysctl, sysctl, u.topologyinfo))
-            ? -EFAULT : 0;
-    }
-    break;
-
-    case XEN_SYSCTL_numainfo:
-    {
-        uint32_t i, j, max_node_index, last_online_node;
-        xen_sysctl_numainfo_t *ni = &sysctl->u.numainfo;
-
-        last_online_node = last_node(node_online_map);
-        max_node_index = min_t(uint32_t, ni->max_node_index, last_online_node);
-        ni->max_node_index = last_online_node;
-
-        for ( i = 0; i <= max_node_index; i++ )
-        {
-            if ( !guest_handle_is_null(ni->node_to_memsize) )
-            {
-                uint64_t memsize = node_online(i) ? 
-                                   node_spanned_pages(i) << PAGE_SHIFT : 0ul;
-                if ( copy_to_guest_offset(ni->node_to_memsize, i, &memsize, 1) )
-                    break;
-            }
-            if ( !guest_handle_is_null(ni->node_to_memfree) )
-            {
-                uint64_t memfree = node_online(i) ? 
-                                   avail_node_heap_pages(i) << PAGE_SHIFT : 0ul;
-                if ( copy_to_guest_offset(ni->node_to_memfree, i, &memfree, 1) )
-                    break;
-            }
-
-            if ( !guest_handle_is_null(ni->node_to_node_distance) )
-            {
-                for ( j = 0; j <= max_node_index; j++)
-                {
-                    uint32_t distance = ~0u;
-                    if ( node_online(i) && node_online(j) )
-                        distance = __node_distance(i, j);
-                    if ( copy_to_guest_offset(
-                        ni->node_to_node_distance, 
-                        i*(max_node_index+1) + j, &distance, 1) )
-                        break;
-                }
-                if ( j <= max_node_index )
-                    break;
-            }
-        }
-
-        ret = ((i <= max_node_index) ||
-               __copy_field_to_guest(u_sysctl, sysctl, u.numainfo))
-            ? -EFAULT : 0;
-    }
-    break;
-    
     case XEN_SYSCTL_cpu_hotplug:
     {
         unsigned int cpu = sysctl->u.cpu_hotplug.cpu;
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d663ed7..20bb864 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -249,6 +249,115 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         ret = sched_adjust_global(&op->u.scheduler_op);
         break;
 
+    case XEN_SYSCTL_physinfo:
+    {
+        xen_sysctl_physinfo_t *pi = &op->u.physinfo;
+
+        memset(pi, 0, sizeof(*pi));
+        pi->threads_per_core =
+            cpumask_weight(per_cpu(cpu_sibling_mask, 0));
+        pi->cores_per_socket =
+            cpumask_weight(per_cpu(cpu_core_mask, 0)) / pi->threads_per_core;
+        pi->nr_cpus = num_online_cpus();
+        pi->nr_nodes = num_online_nodes();
+        pi->max_node_id = MAX_NUMNODES-1;
+        pi->max_cpu_id = nr_cpu_ids - 1;
+        pi->total_pages = total_pages;
+        pi->free_pages = avail_domheap_pages();
+        pi->scrub_pages = 0;
+        pi->cpu_khz = cpu_khz;
+        arch_do_physinfo(pi);
+
+        if ( copy_to_guest(u_sysctl, op, 1) )
+            ret = -EFAULT;
+    }
+    break;
+
+    case XEN_SYSCTL_numainfo:
+    {
+        uint32_t i, j, max_node_index, last_online_node;
+        xen_sysctl_numainfo_t *ni = &op->u.numainfo;
+
+        last_online_node = last_node(node_online_map);
+        max_node_index = min_t(uint32_t, ni->max_node_index, last_online_node);
+        ni->max_node_index = last_online_node;
+
+        for ( i = 0; i <= max_node_index; i++ )
+        {
+            if ( !guest_handle_is_null(ni->node_to_memsize) )
+            {
+                uint64_t memsize = node_online(i) ?
+                                   node_spanned_pages(i) << PAGE_SHIFT : 0ul;
+                if ( copy_to_guest_offset(ni->node_to_memsize, i, &memsize, 1) )
+                    break;
+            }
+            if ( !guest_handle_is_null(ni->node_to_memfree) )
+            {
+                uint64_t memfree = node_online(i) ?
+                                   avail_node_heap_pages(i) << PAGE_SHIFT : 0ul;
+                if ( copy_to_guest_offset(ni->node_to_memfree, i, &memfree, 1) )
+                    break;
+            }
+
+            if ( !guest_handle_is_null(ni->node_to_node_distance) )
+            {
+                for ( j = 0; j <= max_node_index; j++)
+                {
+                    uint32_t distance = ~0u;
+                    if ( node_online(i) && node_online(j) )
+                        distance = __node_distance(i, j);
+                    if ( copy_to_guest_offset(
+                        ni->node_to_node_distance,
+                        i*(max_node_index+1) + j, &distance, 1) )
+                        break;
+                }
+                if ( j <= max_node_index )
+                    break;
+            }
+        }
+
+        ret = ((i <= max_node_index) || copy_to_guest(u_sysctl, op, 1))
+            ? -EFAULT : 0;
+    }
+    break;
+
+    case XEN_SYSCTL_topologyinfo:
+    {
+        uint32_t i, max_cpu_index, last_online_cpu;
+        xen_sysctl_topologyinfo_t *ti = &op->u.topologyinfo;
+
+        last_online_cpu = cpumask_last(&cpu_online_map);
+        max_cpu_index = min_t(uint32_t, ti->max_cpu_index, last_online_cpu);
+        ti->max_cpu_index = last_online_cpu;
+
+        for ( i = 0; i <= max_cpu_index; i++ )
+        {
+            if ( !guest_handle_is_null(ti->cpu_to_core) )
+            {
+                uint32_t core = cpu_online(i) ? cpu_to_core(i) : ~0u;
+                if ( copy_to_guest_offset(ti->cpu_to_core, i, &core, 1) )
+                    break;
+            }
+            if ( !guest_handle_is_null(ti->cpu_to_socket) )
+            {
+                uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
+                if ( copy_to_guest_offset(ti->cpu_to_socket, i, &socket, 1) )
+                    break;
+            }
+            if ( !guest_handle_is_null(ti->cpu_to_node) )
+            {
+                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
+                if ( copy_to_guest_offset(ti->cpu_to_node, i, &node, 1) )
+                    break;
+            }
+        }
+
+        ret = ((i <= max_cpu_index) || copy_to_guest(u_sysctl, op, 1))
+            ? -EFAULT : 0;
+    }
+    break;
+
+
     default:
         ret = arch_do_sysctl(op, u_sysctl);
         copyback = 0;
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a1b1f58..86f0183 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -10,6 +10,10 @@ static inline __attribute__((pure)) int phys_to_nid(paddr_t addr)
     return 0;
 }
 
+/* XXX: implement NUMA support */
+#define node_spanned_pages(nid)	(total_pages)
+#define __node_distance(a, b) (20)
+
 #endif /* __ARCH_ARM_NUMA_H */
 /*
  * Local variables:
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 90a6537..ba0f2f8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -748,6 +748,8 @@ extern void dump_runq(unsigned char key);
 
 #define num_cpupool_cpus(c) cpumask_weight((c)->cpu_valid)
 
+void arch_do_physinfo(xen_sysctl_physinfo_t *pi);
+
 #endif /* __SCHED_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 Thu Feb 14 18:07:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Cr-0003ae-SP; Thu, 14 Feb 2013 18:06:49 +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 1U63Cp-0003a6-TT
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:48 +0000
Received: from [85.158.143.35:62721] by server-1.bemta-4.messagelabs.com id
	41/BF-08839-7B72D115; Thu, 14 Feb 2013 18:06:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6880 invoked from network); 14 Feb 2013 18:06:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545088"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-H4;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:32 +0000
Message-ID: <1360865193-22148-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/4] libxc: fixes for the ARM 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

Make xc_dom_feature_translated an arch-dependent function.

alloc_magic_pages: save console and xenstore pfn's in xc_dom_image.
alloc_magic_pages: set HVM_PARAM_CONSOLE_EVTCHN and
HVM_PARAM_STORE_EVTCHN hvm_params using the event channels allocated by
the toolstack.

Call xc_dom_gnttab_hvm_seed instead of xc_dom_gnttab_seed in
xc_dom_gnttab_init for autotranslated guests.


Changes in v3:
- rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0;
- implement xc_dom_feature_translated in xc_dom_{arm/x86}.c.

Changes on v2:
- add xc_dom_gnttab_init changes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_dom.h      |    6 +-----
 tools/libxc/xc_dom_arm.c  |   24 +++++++++++++++++-------
 tools/libxc/xc_dom_boot.c |   23 ++++++++++-------------
 tools/libxc/xc_dom_x86.c  |    5 +++++
 4 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index eccc516..7583d8c 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -250,6 +250,7 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
                        xen_pfn_t xenstore_gmfn,
                        domid_t console_domid,
                        domid_t xenstore_domid);
+int xc_dom_feature_translated(struct xc_dom_image *dom);
 
 /* --- debugging bits ---------------------------------------------- */
 
@@ -312,11 +313,6 @@ static inline void *xc_dom_vaddr_to_ptr(struct xc_dom_image *dom,
     return (ptr ? (ptr + offset) : NULL);
 }
 
-static inline int xc_dom_feature_translated(struct xc_dom_image *dom)
-{
-    return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
-}
-
 static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index b743a6c..62bd3cf 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -51,7 +51,7 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
     int rc, i;
-    xen_pfn_t store_pfn, console_pfn, p2m[NR_MAGIC_PAGES];
+    xen_pfn_t p2m[NR_MAGIC_PAGES];
 
     DOMPRINTF_CALLED(dom->xch);
 
@@ -64,15 +64,20 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
     if ( rc < 0 )
         return rc;
 
-    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
-    store_pfn = dom->rambase_pfn + dom->total_pages + XENSTORE_PFN_OFFSET;
+    dom->console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
+    dom->xenstore_pfn = dom->rambase_pfn + dom->total_pages + XENSTORE_PFN_OFFSET;
 
-    xc_clear_domain_page(dom->xch, dom->guest_domid, console_pfn);
-    xc_clear_domain_page(dom->xch, dom->guest_domid, store_pfn);
+    xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
+    xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
     xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
-            console_pfn);
+            dom->console_pfn);
     xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
-            store_pfn);
+            dom->xenstore_pfn);
+    /* allocated by toolstack */
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
+            dom->console_evtchn);
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
+            dom->xenstore_evtchn);
 
     return 0;
 }
@@ -196,6 +201,11 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
     return 0;
 }
 
+int xc_dom_feature_translated(struct xc_dom_image *dom)
+{ 
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index f83aa12..c7f04a8 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -416,19 +416,16 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
 
 int xc_dom_gnttab_init(struct xc_dom_image *dom)
 {
-    xen_pfn_t console_gmfn;
-    xen_pfn_t xenstore_gmfn;
-    int autotranslated;
-
-    autotranslated = xc_dom_feature_translated(dom);
-    console_gmfn = autotranslated ?
-           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
-    xenstore_gmfn = autotranslated ?
-           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
-
-    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
-                              console_gmfn, xenstore_gmfn,
-                              dom->console_domid, dom->xenstore_domid);
+    if ( xc_dom_feature_translated(dom) ) {
+        return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
+                                      dom->console_pfn, dom->xenstore_pfn,
+                                      dom->console_domid, dom->xenstore_domid);
+    } else {
+        return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                                  xc_dom_p2m_host(dom, dom->console_pfn),
+                                  xc_dom_p2m_host(dom, dom->xenstore_pfn),
+                                  dom->console_domid, dom->xenstore_domid);
+    }
 }
 
 /*
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index be2ad66..9cbdd62 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -822,6 +822,11 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
     return 0;
 }
 
+int xc_dom_feature_translated(struct xc_dom_image *dom)
+{
+    return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.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 Feb 14 18:07:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Cr-0003ae-SP; Thu, 14 Feb 2013 18:06:49 +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 1U63Cp-0003a6-TT
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:48 +0000
Received: from [85.158.143.35:62721] by server-1.bemta-4.messagelabs.com id
	41/BF-08839-7B72D115; Thu, 14 Feb 2013 18:06:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6880 invoked from network); 14 Feb 2013 18:06:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545088"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-H4;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:32 +0000
Message-ID: <1360865193-22148-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/4] libxc: fixes for the ARM 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

Make xc_dom_feature_translated an arch-dependent function.

alloc_magic_pages: save console and xenstore pfn's in xc_dom_image.
alloc_magic_pages: set HVM_PARAM_CONSOLE_EVTCHN and
HVM_PARAM_STORE_EVTCHN hvm_params using the event channels allocated by
the toolstack.

Call xc_dom_gnttab_hvm_seed instead of xc_dom_gnttab_seed in
xc_dom_gnttab_init for autotranslated guests.


Changes in v3:
- rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0;
- implement xc_dom_feature_translated in xc_dom_{arm/x86}.c.

Changes on v2:
- add xc_dom_gnttab_init changes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_dom.h      |    6 +-----
 tools/libxc/xc_dom_arm.c  |   24 +++++++++++++++++-------
 tools/libxc/xc_dom_boot.c |   23 ++++++++++-------------
 tools/libxc/xc_dom_x86.c  |    5 +++++
 4 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index eccc516..7583d8c 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -250,6 +250,7 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
                        xen_pfn_t xenstore_gmfn,
                        domid_t console_domid,
                        domid_t xenstore_domid);
+int xc_dom_feature_translated(struct xc_dom_image *dom);
 
 /* --- debugging bits ---------------------------------------------- */
 
@@ -312,11 +313,6 @@ static inline void *xc_dom_vaddr_to_ptr(struct xc_dom_image *dom,
     return (ptr ? (ptr + offset) : NULL);
 }
 
-static inline int xc_dom_feature_translated(struct xc_dom_image *dom)
-{
-    return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
-}
-
 static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
     if (dom->shadow_enabled)
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index b743a6c..62bd3cf 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -51,7 +51,7 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {
     int rc, i;
-    xen_pfn_t store_pfn, console_pfn, p2m[NR_MAGIC_PAGES];
+    xen_pfn_t p2m[NR_MAGIC_PAGES];
 
     DOMPRINTF_CALLED(dom->xch);
 
@@ -64,15 +64,20 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
     if ( rc < 0 )
         return rc;
 
-    console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
-    store_pfn = dom->rambase_pfn + dom->total_pages + XENSTORE_PFN_OFFSET;
+    dom->console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET;
+    dom->xenstore_pfn = dom->rambase_pfn + dom->total_pages + XENSTORE_PFN_OFFSET;
 
-    xc_clear_domain_page(dom->xch, dom->guest_domid, console_pfn);
-    xc_clear_domain_page(dom->xch, dom->guest_domid, store_pfn);
+    xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
+    xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
     xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
-            console_pfn);
+            dom->console_pfn);
     xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
-            store_pfn);
+            dom->xenstore_pfn);
+    /* allocated by toolstack */
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
+            dom->console_evtchn);
+    xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
+            dom->xenstore_evtchn);
 
     return 0;
 }
@@ -196,6 +201,11 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
     return 0;
 }
 
+int xc_dom_feature_translated(struct xc_dom_image *dom)
+{ 
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index f83aa12..c7f04a8 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -416,19 +416,16 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
 
 int xc_dom_gnttab_init(struct xc_dom_image *dom)
 {
-    xen_pfn_t console_gmfn;
-    xen_pfn_t xenstore_gmfn;
-    int autotranslated;
-
-    autotranslated = xc_dom_feature_translated(dom);
-    console_gmfn = autotranslated ?
-           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
-    xenstore_gmfn = autotranslated ?
-           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
-
-    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
-                              console_gmfn, xenstore_gmfn,
-                              dom->console_domid, dom->xenstore_domid);
+    if ( xc_dom_feature_translated(dom) ) {
+        return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
+                                      dom->console_pfn, dom->xenstore_pfn,
+                                      dom->console_domid, dom->xenstore_domid);
+    } else {
+        return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                                  xc_dom_p2m_host(dom, dom->console_pfn),
+                                  xc_dom_p2m_host(dom, dom->xenstore_pfn),
+                                  dom->console_domid, dom->xenstore_domid);
+    }
 }
 
 /*
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index be2ad66..9cbdd62 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -822,6 +822,11 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
     return 0;
 }
 
+int xc_dom_feature_translated(struct xc_dom_image *dom)
+{
+    return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.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 Feb 14 18:07:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Cs-0003ar-9u; Thu, 14 Feb 2013 18:06:50 +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 1U63Cr-0003aW-Fg
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:49 +0000
Received: from [85.158.143.35:62763] by server-3.bemta-4.messagelabs.com id
	95/4D-08920-8B72D115; Thu, 14 Feb 2013 18:06:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6919 invoked from network); 14 Feb 2013 18:06:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545089"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-Is;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:33 +0000
Message-ID: <1360865193-22148-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 4/4] xen/arm: compile and run libxl/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

Move tsc, rtc, memmap_limit, localtime and shadow settings from
libxl__build_pre to libxl__arch_domain_create.

Get the console and xenstore pfn's from struct xc_dom_image for
autotranslated guests.


Changes in v2:
- move the xc_dom_gnttab_hvm_seed changes into the libxc patch.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |   54 ++++++----------------------------------------
 tools/libxl/libxl_x86.c |   48 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 47 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6b3b3c3..65d9fa0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -202,9 +202,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     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);
 
@@ -233,49 +231,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
 
     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,
-                (info->max_memkb + info->u.pv.slack_memkb));
-    switch (info->tsc_mode) {
-    case LIBXL_TSC_MODE_DEFAULT:
-        tsc_mode = 0;
-        break;
-    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
-        tsc_mode = 1;
-        break;
-    case LIBXL_TSC_MODE_NATIVE:
-        tsc_mode = 2;
-        break;
-    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
-        tsc_mode = 3;
-        break;
-    default:
-        abort();
-    }
-    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if (libxl_defbool_val(info->disable_migrate))
-        xc_domain_disable_migrate(ctx->xch, domid);
-
-    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;
-        shadow = (info->shadow_memkb + 1023) / 1024;
-        xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
-    }
-
     xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
     state->store_domid = xs_domid ? atoi(xs_domid) : 0;
     free(xs_domid);
@@ -443,8 +398,13 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         goto out;
     }
 
-    state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
-    state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
+    if (xc_dom_feature_translated(dom)) {
+        state->console_mfn = dom->console_pfn;
+        state->store_mfn = dom->xenstore_pfn;
+    } else {
+        state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
+        state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
+    }
 
     libxl__file_reference_unmap(&state->pv_kernel);
     libxl__file_reference_unmap(&state->pv_ramdisk);
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 590e39d..a17f6ae 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -248,6 +248,54 @@ int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         uint32_t domid)
 {
     int ret = 0;
+    int tsc_mode;
+    uint32_t rtc_timeoffset;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    if (d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV)
+        xc_domain_set_memmap_limit(ctx->xch, domid,
+                                   (d_config->b_info.max_memkb +
+                                    d_config->b_info.u.pv.slack_memkb));
+
+    switch (d_config->b_info.tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
+    if (libxl_defbool_val(d_config->b_info.disable_migrate))
+        xc_domain_disable_migrate(ctx->xch, domid);
+    rtc_timeoffset = d_config->b_info.rtc_timeoffset;
+    if (libxl_defbool_val(d_config->b_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 (d_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
+        unsigned long shadow;
+        shadow = (d_config->b_info.shadow_memkb + 1023) / 1024;
+        xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
+    }
+
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
             libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         ret = libxl__e820_alloc(gc, domid, d_config);
-- 
1.7.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 Feb 14 18:07:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Cs-0003ar-9u; Thu, 14 Feb 2013 18:06:50 +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 1U63Cr-0003aW-Fg
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:49 +0000
Received: from [85.158.143.35:62763] by server-3.bemta-4.messagelabs.com id
	95/4D-08920-8B72D115; Thu, 14 Feb 2013 18:06:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6919 invoked from network); 14 Feb 2013 18:06:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545089"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-Is;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:33 +0000
Message-ID: <1360865193-22148-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 4/4] xen/arm: compile and run libxl/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

Move tsc, rtc, memmap_limit, localtime and shadow settings from
libxl__build_pre to libxl__arch_domain_create.

Get the console and xenstore pfn's from struct xc_dom_image for
autotranslated guests.


Changes in v2:
- move the xc_dom_gnttab_hvm_seed changes into the libxc patch.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c |   54 ++++++----------------------------------------
 tools/libxl/libxl_x86.c |   48 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 47 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6b3b3c3..65d9fa0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -202,9 +202,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     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);
 
@@ -233,49 +231,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
     libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
 
     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,
-                (info->max_memkb + info->u.pv.slack_memkb));
-    switch (info->tsc_mode) {
-    case LIBXL_TSC_MODE_DEFAULT:
-        tsc_mode = 0;
-        break;
-    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
-        tsc_mode = 1;
-        break;
-    case LIBXL_TSC_MODE_NATIVE:
-        tsc_mode = 2;
-        break;
-    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
-        tsc_mode = 3;
-        break;
-    default:
-        abort();
-    }
-    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if (libxl_defbool_val(info->disable_migrate))
-        xc_domain_disable_migrate(ctx->xch, domid);
-
-    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;
-        shadow = (info->shadow_memkb + 1023) / 1024;
-        xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
-    }
-
     xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
     state->store_domid = xs_domid ? atoi(xs_domid) : 0;
     free(xs_domid);
@@ -443,8 +398,13 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         goto out;
     }
 
-    state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
-    state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
+    if (xc_dom_feature_translated(dom)) {
+        state->console_mfn = dom->console_pfn;
+        state->store_mfn = dom->xenstore_pfn;
+    } else {
+        state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
+        state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
+    }
 
     libxl__file_reference_unmap(&state->pv_kernel);
     libxl__file_reference_unmap(&state->pv_ramdisk);
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 590e39d..a17f6ae 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -248,6 +248,54 @@ int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
         uint32_t domid)
 {
     int ret = 0;
+    int tsc_mode;
+    uint32_t rtc_timeoffset;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    if (d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV)
+        xc_domain_set_memmap_limit(ctx->xch, domid,
+                                   (d_config->b_info.max_memkb +
+                                    d_config->b_info.u.pv.slack_memkb));
+
+    switch (d_config->b_info.tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
+    if (libxl_defbool_val(d_config->b_info.disable_migrate))
+        xc_domain_disable_migrate(ctx->xch, domid);
+    rtc_timeoffset = d_config->b_info.rtc_timeoffset;
+    if (libxl_defbool_val(d_config->b_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 (d_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
+        unsigned long shadow;
+        shadow = (d_config->b_info.shadow_memkb + 1023) / 1024;
+        xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
+    }
+
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
             libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         ret = libxl__e820_alloc(gc, domid, d_config);
-- 
1.7.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 Feb 14 18:07:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Cq-0003aF-Ao; Thu, 14 Feb 2013 18:06:48 +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 1U63Cp-0003a6-Cu
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:47 +0000
Received: from [85.158.143.35:7238] by server-1.bemta-4.messagelabs.com id
	FD/AF-08839-6B72D115; Thu, 14 Feb 2013 18:06:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6857 invoked from network); 14 Feb 2013 18:06:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545086"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-FO;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:31 +0000
Message-ID: <1360865193-22148-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/4] xen/arm: implement
	gnttab_create_shared_page and gnttab_shared_gmfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 simple pfn array, grant_table_gpfn, to keep track of the
grant table pages mapped in guest gpfn space.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c             |    3 +++
 xen/arch/arm/mm.c                 |    2 ++
 xen/include/asm-arm/domain.h      |    1 +
 xen/include/asm-arm/grant_table.h |   13 +++++++++++--
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0aa261a..e37ec54 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -6,6 +6,7 @@
 #include <xen/wait.h>
 #include <xen/errno.h>
 #include <xen/bitops.h>
+#include <xen/grant_table.h>
 
 #include <asm/current.h>
 #include <asm/event.h>
@@ -329,11 +330,13 @@ struct domain *alloc_domain_struct(void)
     d = alloc_xenheap_pages(0, 0);
     if ( d != NULL )
         clear_page(d);
+    d->arch.grant_table_gpfn = xmalloc_array(xen_pfn_t, max_nr_grant_frames);
     return d;
 }
 
 void free_domain_struct(struct domain *d)
 {
+    xfree(d->arch.grant_table_gpfn);
     free_xenheap_page(d);
 }
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f1011b9..b341a5b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -592,6 +592,8 @@ static int xenmem_add_to_physmap_one(
             if ( idx < nr_grant_frames(d->grant_table) )
                 mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
         }
+        
+        d->arch.grant_table_gpfn[idx] = gpfn;
 
         spin_unlock(&d->grant_table->lock);
         break;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 577ad19..29fe808 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -39,6 +39,7 @@ struct arch_domain
 {
     struct p2m_domain p2m;
     struct hvm_domain hvm_domain;
+    xen_pfn_t *grant_table_gpfn;
 
     struct {
         /*
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
index e49aa8d..3fa270d 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -15,8 +15,6 @@ int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
         unsigned long new_gpaddr, unsigned int flags);
 void gnttab_mark_dirty(struct domain *d, unsigned long l);
 #define gnttab_create_status_page(d, t, i) do {} while (0)
-#define gnttab_create_shared_page(d, t, i) do {} while (0)
-#define gnttab_shared_gmfn(d, t, i) (0)
 #define gnttab_status_gmfn(d, t, i) (0)
 #define gnttab_release_host_mappings(domain) 1
 static inline int replace_grant_supported(void)
@@ -24,6 +22,17 @@ static inline int replace_grant_supported(void)
     return 1;
 }
 
+#define gnttab_create_shared_page(d, t, i)                               \
+    do {                                                                 \
+        share_xen_page_with_guest(                                       \
+            virt_to_page((char *)(t)->shared_raw[i]),                    \
+            (d), XENSHARE_writable);                                     \
+    } while ( 0 )
+
+#define gnttab_shared_gmfn(d, t, i)                                      \
+    ( ((i >= nr_grant_frames(d->grant_table)) &&                         \
+     (i < max_nr_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
+
 #endif /* __ASM_GRANT_TABLE_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 14 18:07:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Cq-0003aF-Ao; Thu, 14 Feb 2013 18:06:48 +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 1U63Cp-0003a6-Cu
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:06:47 +0000
Received: from [85.158.143.35:7238] by server-1.bemta-4.messagelabs.com id
	FD/AF-08839-6B72D115; Thu, 14 Feb 2013 18:06:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360865204!3980338!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6857 invoked from network); 14 Feb 2013 18:06:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 18:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7545086"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:06:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:06:43 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63Cg-0002Qo-FO;
	Thu, 14 Feb 2013 18:06:38 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 14 Feb 2013 18:06:31 +0000
Message-ID: <1360865193-22148-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/4] xen/arm: implement
	gnttab_create_shared_page and gnttab_shared_gmfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 simple pfn array, grant_table_gpfn, to keep track of the
grant table pages mapped in guest gpfn space.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c             |    3 +++
 xen/arch/arm/mm.c                 |    2 ++
 xen/include/asm-arm/domain.h      |    1 +
 xen/include/asm-arm/grant_table.h |   13 +++++++++++--
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0aa261a..e37ec54 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -6,6 +6,7 @@
 #include <xen/wait.h>
 #include <xen/errno.h>
 #include <xen/bitops.h>
+#include <xen/grant_table.h>
 
 #include <asm/current.h>
 #include <asm/event.h>
@@ -329,11 +330,13 @@ struct domain *alloc_domain_struct(void)
     d = alloc_xenheap_pages(0, 0);
     if ( d != NULL )
         clear_page(d);
+    d->arch.grant_table_gpfn = xmalloc_array(xen_pfn_t, max_nr_grant_frames);
     return d;
 }
 
 void free_domain_struct(struct domain *d)
 {
+    xfree(d->arch.grant_table_gpfn);
     free_xenheap_page(d);
 }
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f1011b9..b341a5b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -592,6 +592,8 @@ static int xenmem_add_to_physmap_one(
             if ( idx < nr_grant_frames(d->grant_table) )
                 mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
         }
+        
+        d->arch.grant_table_gpfn[idx] = gpfn;
 
         spin_unlock(&d->grant_table->lock);
         break;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 577ad19..29fe808 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -39,6 +39,7 @@ struct arch_domain
 {
     struct p2m_domain p2m;
     struct hvm_domain hvm_domain;
+    xen_pfn_t *grant_table_gpfn;
 
     struct {
         /*
diff --git a/xen/include/asm-arm/grant_table.h b/xen/include/asm-arm/grant_table.h
index e49aa8d..3fa270d 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -15,8 +15,6 @@ int replace_grant_host_mapping(unsigned long gpaddr, unsigned long mfn,
         unsigned long new_gpaddr, unsigned int flags);
 void gnttab_mark_dirty(struct domain *d, unsigned long l);
 #define gnttab_create_status_page(d, t, i) do {} while (0)
-#define gnttab_create_shared_page(d, t, i) do {} while (0)
-#define gnttab_shared_gmfn(d, t, i) (0)
 #define gnttab_status_gmfn(d, t, i) (0)
 #define gnttab_release_host_mappings(domain) 1
 static inline int replace_grant_supported(void)
@@ -24,6 +22,17 @@ static inline int replace_grant_supported(void)
     return 1;
 }
 
+#define gnttab_create_shared_page(d, t, i)                               \
+    do {                                                                 \
+        share_xen_page_with_guest(                                       \
+            virt_to_page((char *)(t)->shared_raw[i]),                    \
+            (d), XENSHARE_writable);                                     \
+    } while ( 0 )
+
+#define gnttab_shared_gmfn(d, t, i)                                      \
+    ( ((i >= nr_grant_frames(d->grant_table)) &&                         \
+     (i < max_nr_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
+
 #endif /* __ASM_GRANT_TABLE_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 14 18:07:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Dc-0003ky-CD; Thu, 14 Feb 2013 18:07: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 1U63Db-0003kY-3L
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:07:35 +0000
Received: from [85.158.143.35:2591] by server-3.bemta-4.messagelabs.com id
	E9/BD-08920-6E72D115; Thu, 14 Feb 2013 18:07:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360865159!14439278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23615 invoked from network); 14 Feb 2013 18:06:01 -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;
	14 Feb 2013 18:06:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7544943"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:05:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:05:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63C2-0002Pv-IJ;
	Thu, 14 Feb 2013 18:05:58 +0000
Date: Thu, 14 Feb 2013 18:05:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/4] xen/arm: compile and run 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

Hi all,
this small patch series contains the changes necessary to compile and
run xl on ARM. Xl can be used to create VMs.

The first two patches are hypervisor changes, while the last two are
libxc and libxli multiarch fixes.


Changes in v3:
- rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0;
- move node_spanned_pages and __node_distance definitions to numa.h;
- implement xc_dom_feature_translated in xc_dom_{arm/x86}.c.

Changes in v2:
- rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795;
- cpu_khz is khz while cntfrq is hz: take care of the conversion;
- move the xc_dom_gnttab_hvm_seed changes into the libxc patch.


Stefano Stabellini (4):
      xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common code
      xen/arm: implement gnttab_create_shared_page and gnttab_shared_gmfn
      libxc: fixes for the ARM platform
      xen/arm: compile and run libxl/xl

 tools/libxc/xc_dom.h              |    6 +--
 tools/libxc/xc_dom_arm.c          |   24 +++++--
 tools/libxc/xc_dom_boot.c         |   23 +++----
 tools/libxc/xc_dom_x86.c          |    5 ++
 tools/libxl/libxl_dom.c           |   54 ++--------------
 tools/libxl/libxl_x86.c           |   48 ++++++++++++++
 xen/arch/arm/domain.c             |    3 +
 xen/arch/arm/mm.c                 |    3 +
 xen/arch/arm/setup.c              |    2 +-
 xen/arch/arm/sysctl.c             |    2 +
 xen/arch/arm/time.c               |   10 ++--
 xen/arch/x86/sysctl.c             |  123 +++----------------------------------
 xen/common/sysctl.c               |  109 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h      |    1 +
 xen/include/asm-arm/grant_table.h |   13 +++-
 xen/include/asm-arm/numa.h        |    4 +
 xen/include/xen/sched.h           |    2 +
 17 files changed, 238 insertions(+), 194 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 Feb 14 18:07:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18:07: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 1U63Dc-0003ky-CD; Thu, 14 Feb 2013 18:07: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 1U63Db-0003kY-3L
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 18:07:35 +0000
Received: from [85.158.143.35:2591] by server-3.bemta-4.messagelabs.com id
	E9/BD-08920-6E72D115; Thu, 14 Feb 2013 18:07:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360865159!14439278!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23615 invoked from network); 14 Feb 2013 18:06:01 -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;
	14 Feb 2013 18:06:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7544943"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 18:05:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 13:05:58 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U63C2-0002Pv-IJ;
	Thu, 14 Feb 2013 18:05:58 +0000
Date: Thu, 14 Feb 2013 18:05:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/4] xen/arm: compile and run 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

Hi all,
this small patch series contains the changes necessary to compile and
run xl on ARM. Xl can be used to create VMs.

The first two patches are hypervisor changes, while the last two are
libxc and libxli multiarch fixes.


Changes in v3:
- rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0;
- move node_spanned_pages and __node_distance definitions to numa.h;
- implement xc_dom_feature_translated in xc_dom_{arm/x86}.c.

Changes in v2:
- rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795;
- cpu_khz is khz while cntfrq is hz: take care of the conversion;
- move the xc_dom_gnttab_hvm_seed changes into the libxc patch.


Stefano Stabellini (4):
      xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common code
      xen/arm: implement gnttab_create_shared_page and gnttab_shared_gmfn
      libxc: fixes for the ARM platform
      xen/arm: compile and run libxl/xl

 tools/libxc/xc_dom.h              |    6 +--
 tools/libxc/xc_dom_arm.c          |   24 +++++--
 tools/libxc/xc_dom_boot.c         |   23 +++----
 tools/libxc/xc_dom_x86.c          |    5 ++
 tools/libxl/libxl_dom.c           |   54 ++--------------
 tools/libxl/libxl_x86.c           |   48 ++++++++++++++
 xen/arch/arm/domain.c             |    3 +
 xen/arch/arm/mm.c                 |    3 +
 xen/arch/arm/setup.c              |    2 +-
 xen/arch/arm/sysctl.c             |    2 +
 xen/arch/arm/time.c               |   10 ++--
 xen/arch/x86/sysctl.c             |  123 +++----------------------------------
 xen/common/sysctl.c               |  109 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h      |    1 +
 xen/include/asm-arm/grant_table.h |   13 +++-
 xen/include/asm-arm/numa.h        |    4 +
 xen/include/xen/sched.h           |    2 +
 17 files changed, 238 insertions(+), 194 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 Feb 14 18:23:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18: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 1U63Sr-0004n8-US; Thu, 14 Feb 2013 18:23:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U63Sq-0004n3-MD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 18:23:20 +0000
Received: from [85.158.139.83:35645] by server-10.bemta-5.messagelabs.com id
	93/CB-04697-79B2D115; Thu, 14 Feb 2013 18:23:19 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360866198!31483951!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19408 invoked from network); 14 Feb 2013 18:23:19 -0000
Received: from unknown (HELO shards.monkeyblade.net) (149.20.54.216)
	by server-13.tower-182.messagelabs.com with SMTP;
	14 Feb 2013 18:23:19 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id EF9965810B7;
	Thu, 14 Feb 2013 10:21:22 -0800 (PST)
Date: Thu, 14 Feb 2013 13:21:18 -0500 (EST)
Message-Id: <20130214.132118.1110984061087346493.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: ian.campbell@citrix.com, konrad.wilk@oracle.com, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, jbeulich@suse.com, wei.liu@citrix.com
Subject: Re: [Xen-devel] xen-netback: fix oopes during shutdown and error
	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

From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 13:18:56 +0000

> These two netback patches fix oopes that may occur during shutdown or
> if a specific fatal error occurs.
> 
> They are stable candidants.

Both applied and queued up for -stable, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 18:23:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 18: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 1U63Sr-0004n8-US; Thu, 14 Feb 2013 18:23:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U63Sq-0004n3-MD
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 18:23:20 +0000
Received: from [85.158.139.83:35645] by server-10.bemta-5.messagelabs.com id
	93/CB-04697-79B2D115; Thu, 14 Feb 2013 18:23:19 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360866198!31483951!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19408 invoked from network); 14 Feb 2013 18:23:19 -0000
Received: from unknown (HELO shards.monkeyblade.net) (149.20.54.216)
	by server-13.tower-182.messagelabs.com with SMTP;
	14 Feb 2013 18:23:19 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id EF9965810B7;
	Thu, 14 Feb 2013 10:21:22 -0800 (PST)
Date: Thu, 14 Feb 2013 13:21:18 -0500 (EST)
Message-Id: <20130214.132118.1110984061087346493.davem@davemloft.net>
To: david.vrabel@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: ian.campbell@citrix.com, konrad.wilk@oracle.com, netdev@vger.kernel.org,
	xen-devel@lists.xen.org, jbeulich@suse.com, wei.liu@citrix.com
Subject: Re: [Xen-devel] xen-netback: fix oopes during shutdown and error
	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

From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 14 Feb 2013 13:18:56 +0000

> These two netback patches fix oopes that may occur during shutdown or
> if a specific fatal error occurs.
> 
> They are stable candidants.

Both applied and queued up for -stable, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 19:30:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19: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 1U64Uw-0006Bb-L6; Thu, 14 Feb 2013 19:29:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U64Uu-0006BW-In
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 19:29:32 +0000
Received: from [85.158.137.99:17158] by server-6.bemta-3.messagelabs.com id
	13/28-29959-A1B3D115; Thu, 14 Feb 2013 19:29:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360870168!18304422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25045 invoked from network); 14 Feb 2013 19:29:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 19:29:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7560847"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 19:29:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 14:29:12 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U64Ua-0003fj-0D;
	Thu, 14 Feb 2013 19:29:12 +0000
MIME-Version: 1.0
X-Mercurial-Node: 39ae53386eb2ef675ce0187de871f244bc9d87be
Message-ID: <39ae53386eb2ef675ce0.1360870152@andrewcoop.uk.xensource.com>
In-Reply-To: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 14 Feb 2013 19:29:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large.  Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1daa30509f1c -r 39ae53386eb2 tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -51,21 +51,22 @@
 	i1 = (uint32_t) Int64_val(Field(input, 0)); \
 	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
 
-#define ERROR_STRLEN 1024
 void failwith_xc(xc_interface *xch)
 {
-	static char error_str[ERROR_STRLEN];
+	char error_str[256];
 	if (xch) {
 		const xc_error *error = xc_get_last_error(xch);
 		if (error->code == XC_ERROR_NONE)
-                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
+                	snprintf(error_str, sizeof(error_str),
+				 "%d: %s", errno, strerror(errno));
 		else
-			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
-				 error->code,
+			snprintf(error_str, sizeof(error_str),
+				 "%d: %s: %s", error->code,
 				 xc_error_code_to_desc(error->code),
 				 error->message);
 	} else {
-		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
+		snprintf(error_str, sizeof(error_str),
+			 "Unable to open XC interface");
 	}
 	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 19:30:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19: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 1U64Uw-0006Bb-L6; Thu, 14 Feb 2013 19:29:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U64Uu-0006BW-In
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 19:29:32 +0000
Received: from [85.158.137.99:17158] by server-6.bemta-3.messagelabs.com id
	13/28-29959-A1B3D115; Thu, 14 Feb 2013 19:29:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360870168!18304422!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25045 invoked from network); 14 Feb 2013 19:29:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 19:29:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7560847"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 19:29:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 14:29:12 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U64Ua-0003fj-0D;
	Thu, 14 Feb 2013 19:29:12 +0000
MIME-Version: 1.0
X-Mercurial-Node: 39ae53386eb2ef675ce0187de871f244bc9d87be
Message-ID: <39ae53386eb2ef675ce0.1360870152@andrewcoop.uk.xensource.com>
In-Reply-To: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 14 Feb 2013 19:29:12 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large.  Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1daa30509f1c -r 39ae53386eb2 tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -51,21 +51,22 @@
 	i1 = (uint32_t) Int64_val(Field(input, 0)); \
 	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
 
-#define ERROR_STRLEN 1024
 void failwith_xc(xc_interface *xch)
 {
-	static char error_str[ERROR_STRLEN];
+	char error_str[256];
 	if (xch) {
 		const xc_error *error = xc_get_last_error(xch);
 		if (error->code == XC_ERROR_NONE)
-                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
+                	snprintf(error_str, sizeof(error_str),
+				 "%d: %s", errno, strerror(errno));
 		else
-			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
-				 error->code,
+			snprintf(error_str, sizeof(error_str),
+				 "%d: %s: %s", error->code,
 				 xc_error_code_to_desc(error->code),
 				 error->message);
 	} else {
-		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
+		snprintf(error_str, sizeof(error_str),
+			 "Unable to open XC interface");
 	}
 	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 19:30:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19: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 1U64V0-0006Bp-0W; Thu, 14 Feb 2013 19:29:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U64Uy-0006Bi-P8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 19:29:36 +0000
Received: from [85.158.137.99:29087] by server-5.bemta-3.messagelabs.com id
	52/09-04457-B1B3D115; Thu, 14 Feb 2013 19:29:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360870168!18304422!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25070 invoked from network); 14 Feb 2013 19:29:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 19:29:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7560846"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 19:29:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 14:29:12 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U64UZ-0003fj-W4;
	Thu, 14 Feb 2013 19:29:11 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1daa30509f1cf37b0988179a202c6a237bae76ea
Message-ID: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 14 Feb 2013 19:29:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two problems with this function:
  * The caml_{enter,leave}_blocking_section() calls mean that two threads can
    compete for use of the static ring[] buffer.
  * It fails to retrieve the entire buffer if the hypervisor has used 32K or
    more of its console ring.

Unfortunately, fixing the code in a sensible is rather difficult.  The Ocaml
caller expects to get the entire console ring in a single buffer.  There are
no mechanisms to ask Xen for the size of the console ring (which is fixed
after boot).  Even if there was a way to get the size of the console ring, the
XEN_SYSCTL_readconsole hypercall itself races with printk(), leading to
possibly discontinuities if the ring is full.  The requirement for a NULL
terminating string means that a full console ring will appear to fail when use
the correct power of two, forcing us to double up again.  Furthermore, libxc
will bounce the allocated buffer, as will caml_copy_string().

On the other hand, this is very definitely for debugging and testing, so lets
do the best we can to get the entire buffer, and accept the inefficiencies.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 63594ce1708f -r 1daa30509f1c tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -523,27 +523,55 @@ CAMLprim value stub_xc_evtchn_reset(valu
 	CAMLreturn(Val_unit);
 }
 
-
-#define RING_SIZE 32768
-static char ring[RING_SIZE];
-
+/* Maximum size of console ring we are prepared to read, 16MB */
+#define MAX_CONSOLE_RING_SIZE (1U << 24)
 CAMLprim value stub_xc_readconsolering(value xch)
 {
-	unsigned int size = RING_SIZE - 1;
-	char *ring_ptr = ring;
-	int retval;
+	/* 32K starting size (adj for loop doubling at start) */
+	unsigned int ring_size = 1U << 14;
+	unsigned int nr_chars = ring_size;
+	char * ring = NULL;
+	int r;
 
 	CAMLparam1(xch);
+	CAMLlocal1(conring);
 
-	caml_enter_blocking_section();
-	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
-	caml_leave_blocking_section();
+	do
+	{
+		ring_size *= 2;
+		if ( ring_size > MAX_CONSOLE_RING_SIZE )
+		{
+			caml_failwith("Console ring too large");
+			CAMLreturn(Val_unit);
+		}
+		nr_chars = ring_size;
 
-	if (retval)
-		failwith_xc(_H(xch));
+		free(ring);
+		if ( ! ( ring = malloc(ring_size) ) )
+		{
+			caml_failwith("Out of memory");
+			CAMLreturn(Val_unit);
+		}
 
-	ring[size] = '\0';
-	CAMLreturn(caml_copy_string(ring));
+		caml_enter_blocking_section();
+		r = xc_readconsolering(_H(xch), ring, &nr_chars, 0, 0, NULL);
+		caml_leave_blocking_section();
+
+		if ( r )
+		{
+			failwith_xc(_H(xch));
+			free(ring);
+			CAMLreturn(Val_unit);
+		}
+
+		/* If nr_chars == ring_size, we have not read the entire ring.
+		 * Try again with a larger buffer. */
+	} while ( nr_chars >= ring_size );
+
+	ring[nr_chars] = '\0';
+	conring = caml_copy_string(ring);
+	free(ring);
+	CAMLreturn(conring);
 }
 
 CAMLprim value stub_xc_send_debug_keys(value xch, value keys)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 19:30:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19: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 1U64V0-0006Bp-0W; Thu, 14 Feb 2013 19:29:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U64Uy-0006Bi-P8
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 19:29:36 +0000
Received: from [85.158.137.99:29087] by server-5.bemta-3.messagelabs.com id
	52/09-04457-B1B3D115; Thu, 14 Feb 2013 19:29:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1360870168!18304422!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTg3NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25070 invoked from network); 14 Feb 2013 19:29:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 19:29:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="7560846"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	14 Feb 2013 19:29:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 14 Feb 2013 14:29:12 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U64UZ-0003fj-W4;
	Thu, 14 Feb 2013 19:29:11 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1daa30509f1cf37b0988179a202c6a237bae76ea
Message-ID: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 14 Feb 2013 19:29:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two problems with this function:
  * The caml_{enter,leave}_blocking_section() calls mean that two threads can
    compete for use of the static ring[] buffer.
  * It fails to retrieve the entire buffer if the hypervisor has used 32K or
    more of its console ring.

Unfortunately, fixing the code in a sensible is rather difficult.  The Ocaml
caller expects to get the entire console ring in a single buffer.  There are
no mechanisms to ask Xen for the size of the console ring (which is fixed
after boot).  Even if there was a way to get the size of the console ring, the
XEN_SYSCTL_readconsole hypercall itself races with printk(), leading to
possibly discontinuities if the ring is full.  The requirement for a NULL
terminating string means that a full console ring will appear to fail when use
the correct power of two, forcing us to double up again.  Furthermore, libxc
will bounce the allocated buffer, as will caml_copy_string().

On the other hand, this is very definitely for debugging and testing, so lets
do the best we can to get the entire buffer, and accept the inefficiencies.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 63594ce1708f -r 1daa30509f1c tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -523,27 +523,55 @@ CAMLprim value stub_xc_evtchn_reset(valu
 	CAMLreturn(Val_unit);
 }
 
-
-#define RING_SIZE 32768
-static char ring[RING_SIZE];
-
+/* Maximum size of console ring we are prepared to read, 16MB */
+#define MAX_CONSOLE_RING_SIZE (1U << 24)
 CAMLprim value stub_xc_readconsolering(value xch)
 {
-	unsigned int size = RING_SIZE - 1;
-	char *ring_ptr = ring;
-	int retval;
+	/* 32K starting size (adj for loop doubling at start) */
+	unsigned int ring_size = 1U << 14;
+	unsigned int nr_chars = ring_size;
+	char * ring = NULL;
+	int r;
 
 	CAMLparam1(xch);
+	CAMLlocal1(conring);
 
-	caml_enter_blocking_section();
-	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
-	caml_leave_blocking_section();
+	do
+	{
+		ring_size *= 2;
+		if ( ring_size > MAX_CONSOLE_RING_SIZE )
+		{
+			caml_failwith("Console ring too large");
+			CAMLreturn(Val_unit);
+		}
+		nr_chars = ring_size;
 
-	if (retval)
-		failwith_xc(_H(xch));
+		free(ring);
+		if ( ! ( ring = malloc(ring_size) ) )
+		{
+			caml_failwith("Out of memory");
+			CAMLreturn(Val_unit);
+		}
 
-	ring[size] = '\0';
-	CAMLreturn(caml_copy_string(ring));
+		caml_enter_blocking_section();
+		r = xc_readconsolering(_H(xch), ring, &nr_chars, 0, 0, NULL);
+		caml_leave_blocking_section();
+
+		if ( r )
+		{
+			failwith_xc(_H(xch));
+			free(ring);
+			CAMLreturn(Val_unit);
+		}
+
+		/* If nr_chars == ring_size, we have not read the entire ring.
+		 * Try again with a larger buffer. */
+	} while ( nr_chars >= ring_size );
+
+	ring[nr_chars] = '\0';
+	conring = caml_copy_string(ring);
+	free(ring);
+	CAMLreturn(conring);
 }
 
 CAMLprim value stub_xc_send_debug_keys(value xch, value keys)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 19:35:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19:35: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 1U64aZ-0006TA-Q5; Thu, 14 Feb 2013 19:35: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 1U64aY-0006T5-HC
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 19:35:22 +0000
Received: from [85.158.138.51:2970] by server-6.bemta-3.messagelabs.com id
	6F/EB-29959-97C3D115; Thu, 14 Feb 2013 19:35:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1360870520!27522308!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4562 invoked from network); 14 Feb 2013 19:35:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 19:35:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="1479116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 19:35: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.297.1; Thu, 14 Feb 2013 19:35:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U64aV-0000Sj-HD;
	Thu, 14 Feb 2013 19:35:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U64aV-0006ho-Em;
	Thu, 14 Feb 2013 19:35:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16171-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 14 Feb 2013 19:35:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16171: 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 16171 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16171/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16161

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  788f4551580d
baseline version:
 xen                  63594ce1708f

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
  Sander Eikelenboom <linux@eikelenboom.it>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=788f4551580d
+ . 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 788f4551580d
+ branch=xen-unstable
+ revision=788f4551580d
+ . 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/hg/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 788f4551580d 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 10 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 Feb 14 19:35:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19:35: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 1U64aZ-0006TA-Q5; Thu, 14 Feb 2013 19:35: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 1U64aY-0006T5-HC
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 19:35:22 +0000
Received: from [85.158.138.51:2970] by server-6.bemta-3.messagelabs.com id
	6F/EB-29959-97C3D115; Thu, 14 Feb 2013 19:35:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1360870520!27522308!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4562 invoked from network); 14 Feb 2013 19:35:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 19:35:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; 
   d="scan'208";a="1479116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Feb 2013 19:35: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.297.1; Thu, 14 Feb 2013 19:35:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U64aV-0000Sj-HD;
	Thu, 14 Feb 2013 19:35:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U64aV-0006ho-Em;
	Thu, 14 Feb 2013 19:35:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16171-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 14 Feb 2013 19:35:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16171: 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 16171 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16171/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16161
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16161

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           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-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  788f4551580d
baseline version:
 xen                  63594ce1708f

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
  Sander Eikelenboom <linux@eikelenboom.it>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=788f4551580d
+ . 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 788f4551580d
+ branch=xen-unstable
+ revision=788f4551580d
+ . 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/hg/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 788f4551580d 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 10 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 Feb 14 19:52:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19: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 1U64r0-0007As-SE; Thu, 14 Feb 2013 19:52:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ipavlikevich@gmail.com>) id 1U5z1X-0000rO-9t
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:38:51 +0000
Received: from [85.158.143.35:55915] by server-1.bemta-4.messagelabs.com id
	7D/3C-08839-AE8EC115; Thu, 14 Feb 2013 13:38:50 +0000
X-Env-Sender: ipavlikevich@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360848715!14407148!1
X-Originating-IP: [209.85.223.177]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26527 invoked from network); 14 Feb 2013 13:31:57 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:31:57 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so3095614iea.8
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:31:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=d3L9qhdX3QecJNMtbxvvbjQGmMJJFOHV+cU7Il5fkTk=;
	b=QuzV2KimeLytnOQEXqNApiYsJ4RorYDRfS/rsIVNTNZ4jOpKmsDHaX20BF9GTtfjuh
	YRHGsE/8NVZx/pkgVdtzUyIrDEclkUUClM+Un8EltcNVkyfLp2thVRzA3/g1cB7Bql5y
	hZuYNJ2+k7buxOFDY38E86yf45E7fzniJgsWdb6ZTw4eIgUTcYIR7MHUBxNze4V0OaC5
	Ncpu5eb2deofDEFheI9XfNmI3+QJTMSSv5ER8y3OFH6tJTdwbV7nYIgg0/5rEwob/eew
	QBjQveO0cZXyrJokbX8Aqtp9IsaqdorOhg1KbKtHh6xKacojfz7u7rWZI8eLL2nGl2pc
	jDAw==
MIME-Version: 1.0
X-Received: by 10.50.108.161 with SMTP id hl1mr17298338igb.101.1360848715328; 
	Thu, 14 Feb 2013 05:31:55 -0800 (PST)
Received: by 10.43.47.202 with HTTP; Thu, 14 Feb 2013 05:31:55 -0800 (PST)
Date: Thu, 14 Feb 2013 17:31:55 +0400
Message-ID: <CA+O_+ExgxTbNuJhntsiDEcqzmcc_gUEN40FaDaKmsbENmw0oBg@mail.gmail.com>
From: Igor Pavlikevich <ipavlikevich@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 14 Feb 2013 19:52:20 +0000
Subject: [Xen-devel] PLE and/or timer 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: multipart/mixed; boundary="===============2521159303382506406=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2521159303382506406==
Content-Type: multipart/alternative; boundary=f46d0402a9af452bd204d5af48d3

--f46d0402a9af452bd204d5af48d3
Content-Type: text/plain; charset=ISO-8859-1

Hi there.

Under some circumstances Windows HVM with vcpu>=2 stuck with vcpu (one or
all) runstate offline.
Next parts of trace file shows that vcpu start yielding the pcpu after
PAUSE_INSTRUCTION vmexit reason and finally runstate_change to offline
without waking back.

]178.854695610 |||-|||||||-|----|--|||x d808v1 mmio_assist r gpa fee00300
data 2f
              [vla] d808v1 icr status idle
]178.854705889 ||--|||||||-|----||-|||x d808v1 vmentry cycles 24664 !
]178.854707083 ||--|||||||-|----||-|||x d808v1 vmexit exit_reason
APIC_ACCESS eip fffff80001810f82
]178.854707083 ||--|||||||-|----||-|||x d808v1 mmio_assist w gpa fee00310
data 1000000
]178.854713398 ||--|||||||-|- --||-|||x d808v1 vmentry cycles 15152 !
]178.854714458 ||--|||||||-|-|--||-|||x d808v1 vmexit exit_reason
APIC_ACCESS eip fffff80001810f89
]178.854714458 ||--|||||||-|-|--||-|||x d808v1 mmio_assist w gpa fee00300
data 8e1
              [vla] d808v1 icr vec 225 dest_field
]178.854720294 |||-|||||||---|--||||||x d808v1 vmentry cycles 14004 !
]178.854723805 |||-|||||||-------|||||x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.854724469 |||-|||||||--------||||x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.854726237 |||-|||||||--------||||x d808v1 runstate_continue d808v1
running->running
]178.854727041 |||-|||||||--------||||x d808v1 vmentry cycles 7764
]178.854729877 |||-|||||||--------||||x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.854730157 |||-|||||||--------||||x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.854731035 |||-|||||||--------||||x d808v1 runstate_continue d808v1
running->running
...
<huge amount of PAUSE_INSTRUCTION/28005>
...
]178.857438583 |||--------------|---|-x d808v1 vmentry cycles 1972
]178.857440840 |||--------------|---|-x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.857441010 |||--------------|---|-x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.857441405 |||--------------|---|-x d808v1 runstate_continue d808v1
running->running
]178.857441634 |||--------------|---|-x d808v1 vmentry cycles 1904
]178.857443891 |||--------------|---|-x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.857444064 |||--------------|---|-x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.857444458 |||--------------|---|-x d808v1 runstate_continue d808v1
running->running
]178.857444686 |||--------------|---|-x d808v1 vmentry cycles 1908
]178.857446940 |||--------------|---|-x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.857447253 |||--------------|---|-x d808v1   28005(2:8:5) 2 [ 328 1 ]
]178.857449979 |||--------------|---|-x d808v1   2800e(2:8:e) 2 [ 328
1e1278 ]
]178.857450122 |||--------------|---|-x d808v1   2800f(2:8:f) 3 [ 7fff
82fb0c ffffffff ]
]178.857450264 |||--------------|---|-x d808v1   2800a(2:8:a) 4 [ 328 1
7fff 17 ]
 178.857450394 |||--------------|---|-x d808v1 runstate_change d808v1
running->offline
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
....

d808v0 stuck a little bit later:
]179.737341628 -|------------|x|-|---|- d808v0 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff800018d4dde
]179.737341876 -|------------|x|-|---|- d808v0   28005(2:8:5) 2 [ 328 0 ]
 179.737343055 -|------------|x|-|---|- d808v0 runstate_continue d808v0
running->running
]179.737343785 -|------------|x|-|---|- d808v0 vmentry cycles 5176
]179.737347024 -|------------|x|-|---|- d808v0 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff800018d4dde
]179.737347306 -|------------|x|-|---|- d808v0   28005(2:8:5) 2 [ 328 0 ]
 179.737348500 -|------------|x|-|---|- d808v0 runstate_continue d808v0
running->running
]179.737349432 -|------------|x|-|---|- d808v0 vmentry cycles 5776
]179.737352022 -|------------|x|-|---|- d808v0 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff800018d4dde
]179.737354408 -|------------|x|-|---|- d808v0   28005(2:8:5) 2 [ 328 0 ]
]179.737356033 -|------------|x|-|---|- d808v0   2800e(2:8:e) 2 [ 328
1c6e79 ]
]179.737356177 -|------------|x|-|---|- d808v0   2800f(2:8:f) 3 [ 7fff
1caa98 ffffffff ]
]179.737356367 -|------------|x|-|---|- d808v0   2800a(2:8:a) 4 [ 328 0
7fff f ]
 179.737356528 -|------------|x|-|---|- d808v0 runstate_change d808v0
running->offline
process_lost_records: setting d808v0 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v0
process_lost_records: setting d808v0 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v0
...

and that's it - no more information about domid 808.

Is this patch
http://lists.xen.org/archives/html/xen-devel/2011-12/msg01884.html can be
suitable in my situation or maybe some more info needed to solve this issue.

Thanks!

--f46d0402a9af452bd204d5af48d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi there.<br><br></div>Under some <span cla=
ss=3D"">circumstance</span>s Windows HVM with vcpu&gt;=3D2 stuck with vcpu =
(one or all) runstate offline.<br></div>Next parts of trace file shows that=
 vcpu start yielding the pcpu after PAUSE_INSTRUCTION vmexit reason and fin=
ally runstate_change to offline without waking back.<br>
<br>]178.854695610 |||-|||||||-|----|--|||x d808v1 mmio_assist r gpa fee003=
00 data 2f<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [vla] d808v1 icr stat=
us idle<br>]178.854705889 ||--|||||||-|----||-|||x d808v1 vmentry cycles 24=
664 !<br>]178.854707083 ||--|||||||-|----||-|||x d808v1 vmexit exit_reason =
APIC_ACCESS eip fffff80001810f82<br>
]178.854707083 ||--|||||||-|----||-|||x d808v1 mmio_assist w gpa fee00310 d=
ata 1000000<br>]178.854713398 ||--|||||||-|- --||-|||x d808v1 vmentry cycle=
s 15152 !<br>]178.854714458 ||--|||||||-|-|--||-|||x d808v1 vmexit exit_rea=
son APIC_ACCESS eip fffff80001810f89<br>
]178.854714458 ||--|||||||-|-|--||-|||x d808v1 mmio_assist w gpa fee00300 d=
ata 8e1<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [vla] d808v1 icr vec 225=
 dest_field<br>]178.854720294 |||-|||||||---|--||||||x d808v1 vmentry cycle=
s 14004 !<br>]178.854723805 |||-|||||||-------|||||x d808v1 vmexit exit_rea=
son PAUSE_INSTRUCTION eip fffff8000190157f<br>
]178.854724469 |||-|||||||--------||||x d808v1=A0=A0 28005(2:8:5) 2 [ 328 1=
 ]<br>=A0178.854726237 |||-|||||||--------||||x d808v1 runstate_continue d8=
08v1 running-&gt;running<br>]178.854727041 |||-|||||||--------||||x d808v1 =
vmentry cycles 7764<br>
]178.854729877 |||-|||||||--------||||x d808v1 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff8000190157f<br>]178.854730157 |||-|||||||--------||||x d8=
08v1=A0=A0 28005(2:8:5) 2 [ 328 1 ]<br>=A0178.854731035 |||-|||||||--------=
||||x d808v1 runstate_continue d808v1 running-&gt;running<br>
</div>...<br>&lt;huge amount of PAUSE_INSTRUCTION/28005&gt;<br><div><div>..=
.<br>]178.857438583 |||--------------|---|-x d808v1 vmentry cycles 1972<br>=
]178.857440840 |||--------------|---|-x d808v1 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff8000190157f<br>
]178.857441010 |||--------------|---|-x d808v1=A0=A0 28005(2:8:5) 2 [ 328 1=
 ]<br>=A0178.857441405 |||--------------|---|-x d808v1 runstate_continue d8=
08v1 running-&gt;running<br>]178.857441634 |||--------------|---|-x d808v1 =
vmentry cycles 1904<br>
]178.857443891 |||--------------|---|-x d808v1 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff8000190157f<br>]178.857444064 |||--------------|---|-x d8=
08v1=A0=A0 28005(2:8:5) 2 [ 328 1 ]<br>=A0178.857444458 |||--------------|-=
--|-x d808v1 runstate_continue d808v1 running-&gt;running<br>
]178.857444686 |||--------------|---|-x d808v1 vmentry cycles 1908<br>]178.=
857446940 |||--------------|---|-x d808v1 vmexit exit_reason PAUSE_INSTRUCT=
ION eip fffff8000190157f<br>]178.857447253 |||--------------|---|-x d808v1=
=A0=A0 28005(2:8:5) 2 [ 328 1 ]<br>
]178.857449979 |||--------------|---|-x d808v1=A0=A0 2800e(2:8:e) 2 [ 328 1=
e1278 ]<br>]178.857450122 |||--------------|---|-x d808v1=A0=A0 2800f(2:8:f=
) 3 [ 7fff 82fb0c ffffffff ]<br>]178.857450264 |||--------------|---|-x d80=
8v1=A0=A0 2800a(2:8:a) 4 [ 328 1 7fff 17 ]<br>
=A0178.857450394 |||--------------|---|-x d808v1 runstate_change d808v1 run=
ning-&gt;offline<br></div><div>process_lost_records: setting d808v1 to RUNS=
TATE_LOST<br>=A0[w2h] Clearing w2h state for d808v1<br>process_lost_records=
: setting d808v1 to RUNSTATE_LOST<br>
=A0[w2h] Clearing w2h state for d808v1<br>process_lost_records: setting d80=
8v1 to RUNSTATE_LOST<br>=A0[w2h] Clearing w2h state for d808v1<br>process_l=
ost_records: setting d808v1 to RUNSTATE_LOST<br>=A0[w2h] Clearing w2h state=
 for d808v1<br>
process_lost_records: setting d808v1 to RUNSTATE_LOST<br>....<br></div><div=
><br></div><div>d808v0 stuck a little bit later:<br>]179.737341628 -|------=
------|x|-|---|- d808v0 vmexit exit_reason PAUSE_INSTRUCTION eip fffff80001=
8d4dde<br>
]179.737341876 -|------------|x|-|---|- d808v0=A0=A0 28005(2:8:5) 2 [ 328 0=
 ]<br>=A0179.737343055 -|------------|x|-|---|- d808v0 runstate_continue d8=
08v0 running-&gt;running<br>]179.737343785 -|------------|x|-|---|- d808v0 =
vmentry cycles 5176<br>
]179.737347024 -|------------|x|-|---|- d808v0 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff800018d4dde<br>]179.737347306 -|------------|x|-|---|- d8=
08v0=A0=A0 28005(2:8:5) 2 [ 328 0 ]<br>=A0179.737348500 -|------------|x|-|=
---|- d808v0 runstate_continue d808v0 running-&gt;running<br>
]179.737349432 -|------------|x|-|---|- d808v0 vmentry cycles 5776<br>]179.=
737352022 -|------------|x|-|---|- d808v0 vmexit exit_reason PAUSE_INSTRUCT=
ION eip fffff800018d4dde<br>]179.737354408 -|------------|x|-|---|- d808v0=
=A0=A0 28005(2:8:5) 2 [ 328 0 ]<br>
]179.737356033 -|------------|x|-|---|- d808v0=A0=A0 2800e(2:8:e) 2 [ 328 1=
c6e79 ]<br>]179.737356177 -|------------|x|-|---|- d808v0=A0=A0 2800f(2:8:f=
) 3 [ 7fff 1caa98 ffffffff ]<br>]179.737356367 -|------------|x|-|---|- d80=
8v0=A0=A0 2800a(2:8:a) 4 [ 328 0 7fff f ]<br>
=A0179.737356528 -|------------|x|-|---|- d808v0 runstate_change d808v0 run=
ning-&gt;offline<br>process_lost_records: setting d808v0 to RUNSTATE_LOST<b=
r>=A0[w2h] Clearing w2h state for d808v0<br>process_lost_records: setting d=
808v0 to RUNSTATE_LOST<br>
=A0[w2h] Clearing w2h state for d808v0<br>...<br></div><div><br></div><div>=
and that&#39;s it - no more information about domid 808.<br><br></div><div>=
Is this patch <a href=3D"http://lists.xen.org/archives/html/xen-devel/2011-=
12/msg01884.html">http://lists.xen.org/archives/html/xen-devel/2011-12/msg0=
1884.html</a> can be suitable in my situation or maybe some more info neede=
d to solve this issue.<br>
<br></div><div>Thanks!<br></div><div><br></div><div><br></div></div></div>

--f46d0402a9af452bd204d5af48d3--


--===============2521159303382506406==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2521159303382506406==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 19:52:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 19: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 1U64r0-0007As-SE; Thu, 14 Feb 2013 19:52:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ipavlikevich@gmail.com>) id 1U5z1X-0000rO-9t
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 13:38:51 +0000
Received: from [85.158.143.35:55915] by server-1.bemta-4.messagelabs.com id
	7D/3C-08839-AE8EC115; Thu, 14 Feb 2013 13:38:50 +0000
X-Env-Sender: ipavlikevich@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360848715!14407148!1
X-Originating-IP: [209.85.223.177]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26527 invoked from network); 14 Feb 2013 13:31:57 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 13:31:57 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so3095614iea.8
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 05:31:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=d3L9qhdX3QecJNMtbxvvbjQGmMJJFOHV+cU7Il5fkTk=;
	b=QuzV2KimeLytnOQEXqNApiYsJ4RorYDRfS/rsIVNTNZ4jOpKmsDHaX20BF9GTtfjuh
	YRHGsE/8NVZx/pkgVdtzUyIrDEclkUUClM+Un8EltcNVkyfLp2thVRzA3/g1cB7Bql5y
	hZuYNJ2+k7buxOFDY38E86yf45E7fzniJgsWdb6ZTw4eIgUTcYIR7MHUBxNze4V0OaC5
	Ncpu5eb2deofDEFheI9XfNmI3+QJTMSSv5ER8y3OFH6tJTdwbV7nYIgg0/5rEwob/eew
	QBjQveO0cZXyrJokbX8Aqtp9IsaqdorOhg1KbKtHh6xKacojfz7u7rWZI8eLL2nGl2pc
	jDAw==
MIME-Version: 1.0
X-Received: by 10.50.108.161 with SMTP id hl1mr17298338igb.101.1360848715328; 
	Thu, 14 Feb 2013 05:31:55 -0800 (PST)
Received: by 10.43.47.202 with HTTP; Thu, 14 Feb 2013 05:31:55 -0800 (PST)
Date: Thu, 14 Feb 2013 17:31:55 +0400
Message-ID: <CA+O_+ExgxTbNuJhntsiDEcqzmcc_gUEN40FaDaKmsbENmw0oBg@mail.gmail.com>
From: Igor Pavlikevich <ipavlikevich@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 14 Feb 2013 19:52:20 +0000
Subject: [Xen-devel] PLE and/or timer 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: multipart/mixed; boundary="===============2521159303382506406=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2521159303382506406==
Content-Type: multipart/alternative; boundary=f46d0402a9af452bd204d5af48d3

--f46d0402a9af452bd204d5af48d3
Content-Type: text/plain; charset=ISO-8859-1

Hi there.

Under some circumstances Windows HVM with vcpu>=2 stuck with vcpu (one or
all) runstate offline.
Next parts of trace file shows that vcpu start yielding the pcpu after
PAUSE_INSTRUCTION vmexit reason and finally runstate_change to offline
without waking back.

]178.854695610 |||-|||||||-|----|--|||x d808v1 mmio_assist r gpa fee00300
data 2f
              [vla] d808v1 icr status idle
]178.854705889 ||--|||||||-|----||-|||x d808v1 vmentry cycles 24664 !
]178.854707083 ||--|||||||-|----||-|||x d808v1 vmexit exit_reason
APIC_ACCESS eip fffff80001810f82
]178.854707083 ||--|||||||-|----||-|||x d808v1 mmio_assist w gpa fee00310
data 1000000
]178.854713398 ||--|||||||-|- --||-|||x d808v1 vmentry cycles 15152 !
]178.854714458 ||--|||||||-|-|--||-|||x d808v1 vmexit exit_reason
APIC_ACCESS eip fffff80001810f89
]178.854714458 ||--|||||||-|-|--||-|||x d808v1 mmio_assist w gpa fee00300
data 8e1
              [vla] d808v1 icr vec 225 dest_field
]178.854720294 |||-|||||||---|--||||||x d808v1 vmentry cycles 14004 !
]178.854723805 |||-|||||||-------|||||x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.854724469 |||-|||||||--------||||x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.854726237 |||-|||||||--------||||x d808v1 runstate_continue d808v1
running->running
]178.854727041 |||-|||||||--------||||x d808v1 vmentry cycles 7764
]178.854729877 |||-|||||||--------||||x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.854730157 |||-|||||||--------||||x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.854731035 |||-|||||||--------||||x d808v1 runstate_continue d808v1
running->running
...
<huge amount of PAUSE_INSTRUCTION/28005>
...
]178.857438583 |||--------------|---|-x d808v1 vmentry cycles 1972
]178.857440840 |||--------------|---|-x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.857441010 |||--------------|---|-x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.857441405 |||--------------|---|-x d808v1 runstate_continue d808v1
running->running
]178.857441634 |||--------------|---|-x d808v1 vmentry cycles 1904
]178.857443891 |||--------------|---|-x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.857444064 |||--------------|---|-x d808v1   28005(2:8:5) 2 [ 328 1 ]
 178.857444458 |||--------------|---|-x d808v1 runstate_continue d808v1
running->running
]178.857444686 |||--------------|---|-x d808v1 vmentry cycles 1908
]178.857446940 |||--------------|---|-x d808v1 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff8000190157f
]178.857447253 |||--------------|---|-x d808v1   28005(2:8:5) 2 [ 328 1 ]
]178.857449979 |||--------------|---|-x d808v1   2800e(2:8:e) 2 [ 328
1e1278 ]
]178.857450122 |||--------------|---|-x d808v1   2800f(2:8:f) 3 [ 7fff
82fb0c ffffffff ]
]178.857450264 |||--------------|---|-x d808v1   2800a(2:8:a) 4 [ 328 1
7fff 17 ]
 178.857450394 |||--------------|---|-x d808v1 runstate_change d808v1
running->offline
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v1
process_lost_records: setting d808v1 to RUNSTATE_LOST
....

d808v0 stuck a little bit later:
]179.737341628 -|------------|x|-|---|- d808v0 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff800018d4dde
]179.737341876 -|------------|x|-|---|- d808v0   28005(2:8:5) 2 [ 328 0 ]
 179.737343055 -|------------|x|-|---|- d808v0 runstate_continue d808v0
running->running
]179.737343785 -|------------|x|-|---|- d808v0 vmentry cycles 5176
]179.737347024 -|------------|x|-|---|- d808v0 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff800018d4dde
]179.737347306 -|------------|x|-|---|- d808v0   28005(2:8:5) 2 [ 328 0 ]
 179.737348500 -|------------|x|-|---|- d808v0 runstate_continue d808v0
running->running
]179.737349432 -|------------|x|-|---|- d808v0 vmentry cycles 5776
]179.737352022 -|------------|x|-|---|- d808v0 vmexit exit_reason
PAUSE_INSTRUCTION eip fffff800018d4dde
]179.737354408 -|------------|x|-|---|- d808v0   28005(2:8:5) 2 [ 328 0 ]
]179.737356033 -|------------|x|-|---|- d808v0   2800e(2:8:e) 2 [ 328
1c6e79 ]
]179.737356177 -|------------|x|-|---|- d808v0   2800f(2:8:f) 3 [ 7fff
1caa98 ffffffff ]
]179.737356367 -|------------|x|-|---|- d808v0   2800a(2:8:a) 4 [ 328 0
7fff f ]
 179.737356528 -|------------|x|-|---|- d808v0 runstate_change d808v0
running->offline
process_lost_records: setting d808v0 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v0
process_lost_records: setting d808v0 to RUNSTATE_LOST
 [w2h] Clearing w2h state for d808v0
...

and that's it - no more information about domid 808.

Is this patch
http://lists.xen.org/archives/html/xen-devel/2011-12/msg01884.html can be
suitable in my situation or maybe some more info needed to solve this issue.

Thanks!

--f46d0402a9af452bd204d5af48d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi there.<br><br></div>Under some <span cla=
ss=3D"">circumstance</span>s Windows HVM with vcpu&gt;=3D2 stuck with vcpu =
(one or all) runstate offline.<br></div>Next parts of trace file shows that=
 vcpu start yielding the pcpu after PAUSE_INSTRUCTION vmexit reason and fin=
ally runstate_change to offline without waking back.<br>
<br>]178.854695610 |||-|||||||-|----|--|||x d808v1 mmio_assist r gpa fee003=
00 data 2f<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [vla] d808v1 icr stat=
us idle<br>]178.854705889 ||--|||||||-|----||-|||x d808v1 vmentry cycles 24=
664 !<br>]178.854707083 ||--|||||||-|----||-|||x d808v1 vmexit exit_reason =
APIC_ACCESS eip fffff80001810f82<br>
]178.854707083 ||--|||||||-|----||-|||x d808v1 mmio_assist w gpa fee00310 d=
ata 1000000<br>]178.854713398 ||--|||||||-|- --||-|||x d808v1 vmentry cycle=
s 15152 !<br>]178.854714458 ||--|||||||-|-|--||-|||x d808v1 vmexit exit_rea=
son APIC_ACCESS eip fffff80001810f89<br>
]178.854714458 ||--|||||||-|-|--||-|||x d808v1 mmio_assist w gpa fee00300 d=
ata 8e1<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [vla] d808v1 icr vec 225=
 dest_field<br>]178.854720294 |||-|||||||---|--||||||x d808v1 vmentry cycle=
s 14004 !<br>]178.854723805 |||-|||||||-------|||||x d808v1 vmexit exit_rea=
son PAUSE_INSTRUCTION eip fffff8000190157f<br>
]178.854724469 |||-|||||||--------||||x d808v1=A0=A0 28005(2:8:5) 2 [ 328 1=
 ]<br>=A0178.854726237 |||-|||||||--------||||x d808v1 runstate_continue d8=
08v1 running-&gt;running<br>]178.854727041 |||-|||||||--------||||x d808v1 =
vmentry cycles 7764<br>
]178.854729877 |||-|||||||--------||||x d808v1 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff8000190157f<br>]178.854730157 |||-|||||||--------||||x d8=
08v1=A0=A0 28005(2:8:5) 2 [ 328 1 ]<br>=A0178.854731035 |||-|||||||--------=
||||x d808v1 runstate_continue d808v1 running-&gt;running<br>
</div>...<br>&lt;huge amount of PAUSE_INSTRUCTION/28005&gt;<br><div><div>..=
.<br>]178.857438583 |||--------------|---|-x d808v1 vmentry cycles 1972<br>=
]178.857440840 |||--------------|---|-x d808v1 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff8000190157f<br>
]178.857441010 |||--------------|---|-x d808v1=A0=A0 28005(2:8:5) 2 [ 328 1=
 ]<br>=A0178.857441405 |||--------------|---|-x d808v1 runstate_continue d8=
08v1 running-&gt;running<br>]178.857441634 |||--------------|---|-x d808v1 =
vmentry cycles 1904<br>
]178.857443891 |||--------------|---|-x d808v1 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff8000190157f<br>]178.857444064 |||--------------|---|-x d8=
08v1=A0=A0 28005(2:8:5) 2 [ 328 1 ]<br>=A0178.857444458 |||--------------|-=
--|-x d808v1 runstate_continue d808v1 running-&gt;running<br>
]178.857444686 |||--------------|---|-x d808v1 vmentry cycles 1908<br>]178.=
857446940 |||--------------|---|-x d808v1 vmexit exit_reason PAUSE_INSTRUCT=
ION eip fffff8000190157f<br>]178.857447253 |||--------------|---|-x d808v1=
=A0=A0 28005(2:8:5) 2 [ 328 1 ]<br>
]178.857449979 |||--------------|---|-x d808v1=A0=A0 2800e(2:8:e) 2 [ 328 1=
e1278 ]<br>]178.857450122 |||--------------|---|-x d808v1=A0=A0 2800f(2:8:f=
) 3 [ 7fff 82fb0c ffffffff ]<br>]178.857450264 |||--------------|---|-x d80=
8v1=A0=A0 2800a(2:8:a) 4 [ 328 1 7fff 17 ]<br>
=A0178.857450394 |||--------------|---|-x d808v1 runstate_change d808v1 run=
ning-&gt;offline<br></div><div>process_lost_records: setting d808v1 to RUNS=
TATE_LOST<br>=A0[w2h] Clearing w2h state for d808v1<br>process_lost_records=
: setting d808v1 to RUNSTATE_LOST<br>
=A0[w2h] Clearing w2h state for d808v1<br>process_lost_records: setting d80=
8v1 to RUNSTATE_LOST<br>=A0[w2h] Clearing w2h state for d808v1<br>process_l=
ost_records: setting d808v1 to RUNSTATE_LOST<br>=A0[w2h] Clearing w2h state=
 for d808v1<br>
process_lost_records: setting d808v1 to RUNSTATE_LOST<br>....<br></div><div=
><br></div><div>d808v0 stuck a little bit later:<br>]179.737341628 -|------=
------|x|-|---|- d808v0 vmexit exit_reason PAUSE_INSTRUCTION eip fffff80001=
8d4dde<br>
]179.737341876 -|------------|x|-|---|- d808v0=A0=A0 28005(2:8:5) 2 [ 328 0=
 ]<br>=A0179.737343055 -|------------|x|-|---|- d808v0 runstate_continue d8=
08v0 running-&gt;running<br>]179.737343785 -|------------|x|-|---|- d808v0 =
vmentry cycles 5176<br>
]179.737347024 -|------------|x|-|---|- d808v0 vmexit exit_reason PAUSE_INS=
TRUCTION eip fffff800018d4dde<br>]179.737347306 -|------------|x|-|---|- d8=
08v0=A0=A0 28005(2:8:5) 2 [ 328 0 ]<br>=A0179.737348500 -|------------|x|-|=
---|- d808v0 runstate_continue d808v0 running-&gt;running<br>
]179.737349432 -|------------|x|-|---|- d808v0 vmentry cycles 5776<br>]179.=
737352022 -|------------|x|-|---|- d808v0 vmexit exit_reason PAUSE_INSTRUCT=
ION eip fffff800018d4dde<br>]179.737354408 -|------------|x|-|---|- d808v0=
=A0=A0 28005(2:8:5) 2 [ 328 0 ]<br>
]179.737356033 -|------------|x|-|---|- d808v0=A0=A0 2800e(2:8:e) 2 [ 328 1=
c6e79 ]<br>]179.737356177 -|------------|x|-|---|- d808v0=A0=A0 2800f(2:8:f=
) 3 [ 7fff 1caa98 ffffffff ]<br>]179.737356367 -|------------|x|-|---|- d80=
8v0=A0=A0 2800a(2:8:a) 4 [ 328 0 7fff f ]<br>
=A0179.737356528 -|------------|x|-|---|- d808v0 runstate_change d808v0 run=
ning-&gt;offline<br>process_lost_records: setting d808v0 to RUNSTATE_LOST<b=
r>=A0[w2h] Clearing w2h state for d808v0<br>process_lost_records: setting d=
808v0 to RUNSTATE_LOST<br>
=A0[w2h] Clearing w2h state for d808v0<br>...<br></div><div><br></div><div>=
and that&#39;s it - no more information about domid 808.<br><br></div><div>=
Is this patch <a href=3D"http://lists.xen.org/archives/html/xen-devel/2011-=
12/msg01884.html">http://lists.xen.org/archives/html/xen-devel/2011-12/msg0=
1884.html</a> can be suitable in my situation or maybe some more info neede=
d to solve this issue.<br>
<br></div><div>Thanks!<br></div><div><br></div><div><br></div></div></div>

--f46d0402a9af452bd204d5af48d3--


--===============2521159303382506406==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2521159303382506406==--


From xen-devel-bounces@lists.xen.org Thu Feb 14 20:53:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 20: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 1U65o6-00087s-TB; Thu, 14 Feb 2013 20:53:26 +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 1U65o5-00087i-Ar
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 20:53:25 +0000
Received: from [85.158.139.83:32135] by server-15.bemta-5.messagelabs.com id
	D6/A0-18914-4CE4D115; Thu, 14 Feb 2013 20:53:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360875202!29225852!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20357 invoked from network); 14 Feb 2013 20:53:22 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 20:53:22 -0000
Received: by mail-wi0-f182.google.com with SMTP id hi18so404077wib.3
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 12:53:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LGIyqobjGV1TrbeIwJQUGi8JKQgG5VyCYCygRqOhZo4=;
	b=FRimcIgevQH+DPFY5JclashubZgMUYtF1KqpJO1LQ8IXFFAqgzTe/FW6iZUQvxG/zt
	8v1iPZcG/5Bbfeyr5SB38hg3hqp8Hl4DqvJ6GtCDeFPOhtWN64Nuz1zW2UhxNm4TgP1j
	tQTs7bYRB1BM70R48+3nb4HI0kyVN2IFn56hf7hA0vb9ZooCvnL6Wsvjf4FtuzOIir+s
	/twar3YylIlabCTw/AHb72d3Hkh43TCRvahe5LsuXKPfFy5KCgvHuFBRtRw6dQ5fY/12
	eD8nRTFavcSVgRpT6BECdBWVdL+YWC6A4Yzc0fkrRbNbOyG1nJ1PGG6jnFrsS4E9Mxyj
	Fc4Q==
X-Received: by 10.180.7.232 with SMTP id m8mr170081wia.8.1360875188637;
	Thu, 14 Feb 2013 12:53:08 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id m6sm1636419wic.2.2013.02.14.12.53.05
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 12:53:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 20:52:52 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD42FF24.5AFE1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: use single definitions for a few
	constants
Thread-Index: Ac4K9UFZQHQMq45Kj0GlOAM81H4i7g==
In-Reply-To: <511D25C402000078000BE71E@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: use single definitions for a few
 constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/2013 16:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... rather than having a C and an assembly one.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128]
>  
>  #define CONFIG_COMPAT 1
>  
> +#include <xen/const.h>
> +
>  #define PML4_ENTRY_BITS  39
> -#ifndef __ASSEMBLY__
> -#define PML4_ENTRY_BYTES (1UL << PML4_ENTRY_BITS)
> -#define PML4_ADDR(_slot)                             \
> -    ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \
> -     (_slot ## UL << PML4_ENTRY_BITS))
> -#define GB(_gb) (_gb ## UL << 30)
> -#else
> -#define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)
> -#define PML4_ADDR(_slot)                             \
> -    (((_slot >> 8) * 0xffff000000000000) | (_slot << PML4_ENTRY_BITS))
> -#define GB(_gb) (_gb << 30)
> -#endif
> +#define PML4_ENTRY_BYTES (_AC(1,UL) << PML4_ENTRY_BITS)
> +#define PML4_ADDR(_slot)                              \
> +    (((_AC(_slot, UL) >> 8) * _AC(0xffff000000000000,UL)) | \
> +     (_AC(_slot, UL) << PML4_ENTRY_BITS))
> +#define GB(_gb) (_AC(_gb, UL) << 30)
>  
>  /*
>   * Memory layout:
> @@ -242,7 +237,7 @@ extern unsigned char boot_edid_info[128]
>                                                            PAGE_SHIFT)) + 1)
>  #define SPAGETABLE_SIZE         (SPAGETABLE_NR * sizeof(struct spage_info))
>  #define SPAGETABLE_VIRT_START   ((SPAGETABLE_VIRT_END - SPAGETABLE_SIZE) & \
> -                                 (-1UL << SUPERPAGE_SHIFT))
> +                                 (_AC(-1,UL) << SUPERPAGE_SHIFT))
>  /* Slot 261: page-frame information array (128GB). */
>  #define FRAMETABLE_VIRT_END     DIRECTMAP_VIRT_START
>  #define FRAMETABLE_SIZE         GB(128)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 20:53:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 20: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 1U65o6-00087s-TB; Thu, 14 Feb 2013 20:53:26 +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 1U65o5-00087i-Ar
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 20:53:25 +0000
Received: from [85.158.139.83:32135] by server-15.bemta-5.messagelabs.com id
	D6/A0-18914-4CE4D115; Thu, 14 Feb 2013 20:53:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360875202!29225852!1
X-Originating-IP: [209.85.212.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20357 invoked from network); 14 Feb 2013 20:53:22 -0000
Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com)
	(209.85.212.182)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 20:53:22 -0000
Received: by mail-wi0-f182.google.com with SMTP id hi18so404077wib.3
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 12:53:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LGIyqobjGV1TrbeIwJQUGi8JKQgG5VyCYCygRqOhZo4=;
	b=FRimcIgevQH+DPFY5JclashubZgMUYtF1KqpJO1LQ8IXFFAqgzTe/FW6iZUQvxG/zt
	8v1iPZcG/5Bbfeyr5SB38hg3hqp8Hl4DqvJ6GtCDeFPOhtWN64Nuz1zW2UhxNm4TgP1j
	tQTs7bYRB1BM70R48+3nb4HI0kyVN2IFn56hf7hA0vb9ZooCvnL6Wsvjf4FtuzOIir+s
	/twar3YylIlabCTw/AHb72d3Hkh43TCRvahe5LsuXKPfFy5KCgvHuFBRtRw6dQ5fY/12
	eD8nRTFavcSVgRpT6BECdBWVdL+YWC6A4Yzc0fkrRbNbOyG1nJ1PGG6jnFrsS4E9Mxyj
	Fc4Q==
X-Received: by 10.180.7.232 with SMTP id m8mr170081wia.8.1360875188637;
	Thu, 14 Feb 2013 12:53:08 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id m6sm1636419wic.2.2013.02.14.12.53.05
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 12:53:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 20:52:52 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD42FF24.5AFE1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: use single definitions for a few
	constants
Thread-Index: Ac4K9UFZQHQMq45Kj0GlOAM81H4i7g==
In-Reply-To: <511D25C402000078000BE71E@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: use single definitions for a few
 constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/2013 16:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... rather than having a C and an assembly one.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128]
>  
>  #define CONFIG_COMPAT 1
>  
> +#include <xen/const.h>
> +
>  #define PML4_ENTRY_BITS  39
> -#ifndef __ASSEMBLY__
> -#define PML4_ENTRY_BYTES (1UL << PML4_ENTRY_BITS)
> -#define PML4_ADDR(_slot)                             \
> -    ((((_slot ## UL) >> 8) * 0xffff000000000000UL) | \
> -     (_slot ## UL << PML4_ENTRY_BITS))
> -#define GB(_gb) (_gb ## UL << 30)
> -#else
> -#define PML4_ENTRY_BYTES (1 << PML4_ENTRY_BITS)
> -#define PML4_ADDR(_slot)                             \
> -    (((_slot >> 8) * 0xffff000000000000) | (_slot << PML4_ENTRY_BITS))
> -#define GB(_gb) (_gb << 30)
> -#endif
> +#define PML4_ENTRY_BYTES (_AC(1,UL) << PML4_ENTRY_BITS)
> +#define PML4_ADDR(_slot)                              \
> +    (((_AC(_slot, UL) >> 8) * _AC(0xffff000000000000,UL)) | \
> +     (_AC(_slot, UL) << PML4_ENTRY_BITS))
> +#define GB(_gb) (_AC(_gb, UL) << 30)
>  
>  /*
>   * Memory layout:
> @@ -242,7 +237,7 @@ extern unsigned char boot_edid_info[128]
>                                                            PAGE_SHIFT)) + 1)
>  #define SPAGETABLE_SIZE         (SPAGETABLE_NR * sizeof(struct spage_info))
>  #define SPAGETABLE_VIRT_START   ((SPAGETABLE_VIRT_END - SPAGETABLE_SIZE) & \
> -                                 (-1UL << SUPERPAGE_SHIFT))
> +                                 (_AC(-1,UL) << SUPERPAGE_SHIFT))
>  /* Slot 261: page-frame information array (128GB). */
>  #define FRAMETABLE_VIRT_END     DIRECTMAP_VIRT_START
>  #define FRAMETABLE_SIZE         GB(128)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 20:54:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 20: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 1U65oi-00089U-BW; Thu, 14 Feb 2013 20:54:04 +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 1U65oh-00089G-0y
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 20:54:03 +0000
Received: from [193.109.254.147:21764] by server-12.bemta-14.messagelabs.com
	id 08/ED-32582-AEE4D115; Thu, 14 Feb 2013 20:54:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360875234!11194932!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16646 invoked from network); 14 Feb 2013 20:53:55 -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;
	14 Feb 2013 20:53:55 -0000
Received: by mail-wi0-f171.google.com with SMTP id hn17so406409wib.10
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 12:53:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=iWci9mWokTdBa3Ug8v+J44zxU4ztM7+F9lZ0IoUcykY=;
	b=LtBNztgvD/4WP4XUQky86YTsJm2ZNzyRLInzPAJRrZ/E9SOufe/wW36IcwHS/e6sG9
	WAw7HoW6eozrVSd4DHn3rJqAR/hry5hdXA0ZVcCdvx6oTGcrXxcOhjLMKbS/LyxRn7C8
	+buJrgpvnrZZDt1RhpX/AgMfRtZXdZl8byuM4ER3/V+/Tfn14d6l8ZazbKiOIvJxa7BA
	TZZC3Z08rd602kXMd0bM+edSS08/kESbuLTFRt37wux2Y1fflfdixIVoW7nMtDYbQkKX
	BrBRgESk/YhpKHnlfz8OyvIIO8mJeJ5prRyMlrPxqP9qZpt8Vy0DseJ7DTm/yGSqOszv
	l2eA==
X-Received: by 10.180.102.201 with SMTP id fq9mr2080928wib.2.1360875190769;
	Thu, 14 Feb 2013 12:53:10 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id m6sm1636419wic.2.2013.02.14.12.53.08
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 12:53:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 20:53:05 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD42FF31.5AFE2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: move watchdog declarations from
	config.h to nmi.h
Thread-Index: Ac4K9UkZkti2YSCfCUqE2vVoZyd6/g==
In-Reply-To: <511D269002000078000BE73A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: move watchdog declarations from
 config.h to nmi.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 14/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:

> They don't belong into the former.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -18,6 +18,7 @@
>  #include <xen/lib.h>
>  #include <xen/mm.h>
>  #include <xen/irq.h>
> +#include <xen/nmi.h>
>  #include <xen/delay.h>
>  #include <xen/time.h>
>  #include <xen/sched.h>
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -12,6 +12,7 @@
>  #include <xen/delay.h>
>  #include <xen/dmi.h>
>  #include <xen/irq.h>
> +#include <xen/nmi.h>
>  #include <xen/console.h>
>  #include <xen/shutdown.h>
>  #include <xen/acpi.h>
> --- a/xen/common/gdbstub.c
> +++ b/xen/common/gdbstub.c
> @@ -38,6 +38,7 @@
>  #include <xen/spinlock.h>
>  #include <xen/serial.h>
>  #include <xen/irq.h>
> +#include <xen/nmi.h>
>  #include <asm/debugger.h>
>  #include <xen/init.h>
>  #include <xen/smp.h>
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -12,6 +12,7 @@
>  #include <xen/ctype.h>
>  #include <xen/errno.h>
>  #include <xen/guest_access.h>
> +#include <xen/nmi.h>
>  #include <xen/sched.h>
>  #include <xen/types.h>
>  #include <xen/kexec.h>
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -16,6 +16,7 @@
>  #include <xen/ctype.h>
>  #include <xen/perfc.h>
>  #include <xen/mm.h>
> +#include <xen/nmi.h>
>  #include <xen/init.h>
>  #include <asm/debugger.h>
>  #include <asm/div64.h>
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -4,6 +4,7 @@
>  #include <xen/sched.h>
>  #include <xen/domain.h>
>  #include <xen/delay.h>
> +#include <xen/nmi.h>
>  #include <xen/shutdown.h>
>  #include <xen/console.h>
>  #ifdef CONFIG_KEXEC
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -20,6 +20,7 @@
>  #include <xen/keyhandler.h>
>  #include <xen/delay.h>
>  #include <xen/guest_access.h>
> +#include <xen/nmi.h>
>  #include <xen/shutdown.h>
>  #include <xen/video.h>
>  #include <xen/kexec.h>
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -317,10 +317,4 @@ extern unsigned long xen_phys_start;
>  
>  #define ARCH_CRASH_SAVE_VMCOREINFO
>  
> -#ifndef __ASSEMBLY__
> -extern void watchdog_disable(void);
> -extern void watchdog_enable(void);
> -extern void watchdog_setup(void);
> -#endif
> -
>  #endif /* __X86_CONFIG_H__ */
> --- a/xen/include/asm-x86/nmi.h
> +++ b/xen/include/asm-x86/nmi.h
> @@ -41,4 +41,8 @@ long register_guest_nmi_callback(unsigne
>   */
>  long unregister_guest_nmi_callback(void);
>  
> +void watchdog_disable(void);
> +void watchdog_enable(void);
> +void watchdog_setup(void);
> +
>  #endif /* ASM_NMI_H */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 20:54:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 20: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 1U65oi-00089U-BW; Thu, 14 Feb 2013 20:54:04 +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 1U65oh-00089G-0y
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 20:54:03 +0000
Received: from [193.109.254.147:21764] by server-12.bemta-14.messagelabs.com
	id 08/ED-32582-AEE4D115; Thu, 14 Feb 2013 20:54:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1360875234!11194932!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16646 invoked from network); 14 Feb 2013 20:53:55 -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;
	14 Feb 2013 20:53:55 -0000
Received: by mail-wi0-f171.google.com with SMTP id hn17so406409wib.10
	for <xen-devel@lists.xen.org>; Thu, 14 Feb 2013 12:53:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=iWci9mWokTdBa3Ug8v+J44zxU4ztM7+F9lZ0IoUcykY=;
	b=LtBNztgvD/4WP4XUQky86YTsJm2ZNzyRLInzPAJRrZ/E9SOufe/wW36IcwHS/e6sG9
	WAw7HoW6eozrVSd4DHn3rJqAR/hry5hdXA0ZVcCdvx6oTGcrXxcOhjLMKbS/LyxRn7C8
	+buJrgpvnrZZDt1RhpX/AgMfRtZXdZl8byuM4ER3/V+/Tfn14d6l8ZazbKiOIvJxa7BA
	TZZC3Z08rd602kXMd0bM+edSS08/kESbuLTFRt37wux2Y1fflfdixIVoW7nMtDYbQkKX
	BrBRgESk/YhpKHnlfz8OyvIIO8mJeJ5prRyMlrPxqP9qZpt8Vy0DseJ7DTm/yGSqOszv
	l2eA==
X-Received: by 10.180.102.201 with SMTP id fq9mr2080928wib.2.1360875190769;
	Thu, 14 Feb 2013 12:53:10 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id m6sm1636419wic.2.2013.02.14.12.53.08
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 12:53:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 14 Feb 2013 20:53:05 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD42FF31.5AFE2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: move watchdog declarations from
	config.h to nmi.h
Thread-Index: Ac4K9UkZkti2YSCfCUqE2vVoZyd6/g==
In-Reply-To: <511D269002000078000BE73A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: move watchdog declarations from
 config.h to nmi.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 14/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:

> They don't belong into the former.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -18,6 +18,7 @@
>  #include <xen/lib.h>
>  #include <xen/mm.h>
>  #include <xen/irq.h>
> +#include <xen/nmi.h>
>  #include <xen/delay.h>
>  #include <xen/time.h>
>  #include <xen/sched.h>
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -12,6 +12,7 @@
>  #include <xen/delay.h>
>  #include <xen/dmi.h>
>  #include <xen/irq.h>
> +#include <xen/nmi.h>
>  #include <xen/console.h>
>  #include <xen/shutdown.h>
>  #include <xen/acpi.h>
> --- a/xen/common/gdbstub.c
> +++ b/xen/common/gdbstub.c
> @@ -38,6 +38,7 @@
>  #include <xen/spinlock.h>
>  #include <xen/serial.h>
>  #include <xen/irq.h>
> +#include <xen/nmi.h>
>  #include <asm/debugger.h>
>  #include <xen/init.h>
>  #include <xen/smp.h>
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -12,6 +12,7 @@
>  #include <xen/ctype.h>
>  #include <xen/errno.h>
>  #include <xen/guest_access.h>
> +#include <xen/nmi.h>
>  #include <xen/sched.h>
>  #include <xen/types.h>
>  #include <xen/kexec.h>
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -16,6 +16,7 @@
>  #include <xen/ctype.h>
>  #include <xen/perfc.h>
>  #include <xen/mm.h>
> +#include <xen/nmi.h>
>  #include <xen/init.h>
>  #include <asm/debugger.h>
>  #include <asm/div64.h>
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -4,6 +4,7 @@
>  #include <xen/sched.h>
>  #include <xen/domain.h>
>  #include <xen/delay.h>
> +#include <xen/nmi.h>
>  #include <xen/shutdown.h>
>  #include <xen/console.h>
>  #ifdef CONFIG_KEXEC
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -20,6 +20,7 @@
>  #include <xen/keyhandler.h>
>  #include <xen/delay.h>
>  #include <xen/guest_access.h>
> +#include <xen/nmi.h>
>  #include <xen/shutdown.h>
>  #include <xen/video.h>
>  #include <xen/kexec.h>
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -317,10 +317,4 @@ extern unsigned long xen_phys_start;
>  
>  #define ARCH_CRASH_SAVE_VMCOREINFO
>  
> -#ifndef __ASSEMBLY__
> -extern void watchdog_disable(void);
> -extern void watchdog_enable(void);
> -extern void watchdog_setup(void);
> -#endif
> -
>  #endif /* __X86_CONFIG_H__ */
> --- a/xen/include/asm-x86/nmi.h
> +++ b/xen/include/asm-x86/nmi.h
> @@ -41,4 +41,8 @@ long register_guest_nmi_callback(unsigne
>   */
>  long unregister_guest_nmi_callback(void);
>  
> +void watchdog_disable(void);
> +void watchdog_enable(void);
> +void watchdog_setup(void);
> +
>  #endif /* ASM_NMI_H */
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 21:53:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 21:53: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 1U66jC-0000SG-51; Thu, 14 Feb 2013 21:52:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1U66jA-0000SB-DL
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 21:52:24 +0000
Received: from [85.158.139.211:42501] by server-14.bemta-5.messagelabs.com id
	AC/A3-06967-79C5D115; Thu, 14 Feb 2013 21:52:23 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360878740!22271930!1
X-Originating-IP: [209.85.220.49]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6403 invoked from network); 14 Feb 2013 21:52:22 -0000
Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com)
	(209.85.220.49)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 21:52:22 -0000
Received: by mail-pa0-f49.google.com with SMTP id kp6so1480022pab.36
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Feb 2013 13:52:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:mime-version
	:content-type:content-disposition:user-agent;
	bh=zoX2EZtrexrPnZh/5uggqFUfbxQgCQYa9m0XPP1qj2c=;
	b=FOQEg1/tNXlhMY5ndF0O490lvipn6CcHfnpERVak7OQ4EU0jxemlYE2dxYR358xTr8
	iSThPTs92U1VGsp1W3hZTGVLp8RcJ/O/6gVCKzuRqyQowZUTE3r4T4wEuDlTEr8qtktq
	LCHijwoB9MUEK6uOvAJ5UdVwuVDNaVmrCIXHU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:mime-version
	:content-type:content-disposition:user-agent:x-gm-message-state;
	bh=zoX2EZtrexrPnZh/5uggqFUfbxQgCQYa9m0XPP1qj2c=;
	b=Ve0WLmtgfSPplI/0qJAEOz5S2akhG0AoEAV6EFGmqFteM1vk5BxZV1FEsstOl3MhmL
	cfl1G89DML5fW5HXKbfossIEVMu2dtqnN4x0TszQs3xUDg5fU7NeXa76z7B6mSMUou05
	OeS8tLiXvY8kwKgVfy2UNFv+Kg7FUCqM0mBMfr4pddkUjn2jf99wF8Q2+Oa03QpP0Swb
	epBzguk10BhdjdV5zXHL8emH8UgJkQv2JNRmrJpyfAh3LLAYFL0+1VTaX+IxLwURaHKl
	xZQFTVYc8amnbJQnwmCNyMZvi5hjCHQLhL67N8uQgXjRLjg0Tv7RA43sWaPa1s90/l/4
	Vfsg==
X-Received: by 10.66.75.136 with SMTP id c8mr7692419paw.25.1360878740162;
	Thu, 14 Feb 2013 13:52:20 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id d8sm91311894pax.23.2013.02.14.13.52.17
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 13:52:19 -0800 (PST)
Date: Thu, 14 Feb 2013 13:52:16 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Jan Beulich <JBeulich@suse.com>, Petr Matousek <pmatouse@redhat.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130214215216.GA18740@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlqI5VFTI5AaUU7Z8AgiM1OGeEcabusyqjo5Z08NW/s+ar6TIopDMS3lh2K1AxV0zn1BMql
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	stable@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, any reason why this patch isn't in Linus's tree already, and why it
wasn't marked for inclusion in a -stable kernel release?

thanks,

greg k-h


On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote:
> This fixes CVE-2013-0228 / XSA-42
> 
> Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
> in 32bit PV guest can use to crash the > guest with the panic like this:
> 
> -------------
> general protection fault: 0000 [#1] SMP
> last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
> mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
> unloaded: scsi_wait_scan]
> 
> Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
> EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
> EIP is at xen_iret+0x12/0x2b
> EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
> ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
>  DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
> Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
> Stack:
>  00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
> Call Trace:
> Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
> 8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
> 10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
> EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
> general protection fault: 0000 [#2]
> ---[ end trace ab0d29a492dcd330 ]---
> Kernel panic - not syncing: Fatal exception
> Pid: 1250, comm: r Tainted: G      D    ---------------
> 2.6.32-356.el6.i686 #1
> Call Trace:
>  [<c08476df>] ? panic+0x6e/0x122
>  [<c084b63c>] ? oops_end+0xbc/0xd0
>  [<c084b260>] ? do_general_protection+0x0/0x210
>  [<c084a9b7>] ? error_code+0x73/
> -------------
> 
> Petr says: "
>  I've analysed the bug and I think that xen_iret() cannot cope with
>  mangled DS, in this case zeroed out (null selector/descriptor) by either
>  xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
>  entry was invalidated by the reproducer. "
> 
> Jan took a look at the preliminary patch and came up a fix that solves
> this problem:
> 
> "This code gets called after all registers other than those handled by
> IRET got already restored, hence a null selector in %ds or a non-null
> one that got loaded from a code or read-only data descriptor would
> cause a kernel mode fault (with the potential of crashing the kernel
> as a whole, if panic_on_oops is set)."
> 
> The way to fix this is to realize that the we can only relay on the
> registers that IRET restores. The two that are guaranteed are the
> %cs and %ss as they are always fixed GDT selectors. Also they are
> inaccessible from user mode - so they cannot be altered. This is
> the approach taken in this patch.
> 
> Another alternative option suggested by Jan would be to relay on
> the subtle realization that using the %ebp or %esp relative references uses
> the %ss segment.  In which case we could switch from using %eax to %ebp and
> would not need the %ss over-rides. That would also require one extra
> instruction to compensate for the one place where the register is used
> as scaled index. However Andrew pointed out that is too subtle and if
> further work was to be done in this code-path it could escape folks attention
> and lead to accidents.
> 
> Reviewed-by: Petr Matousek <pmatouse@redhat.com>
> Reported-by: Petr Matousek <pmatouse@redhat.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/xen-asm_32.S | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
> index f9643fc..33ca6e4 100644
> --- a/arch/x86/xen/xen-asm_32.S
> +++ b/arch/x86/xen/xen-asm_32.S
> @@ -89,11 +89,11 @@ ENTRY(xen_iret)
>  	 */
>  #ifdef CONFIG_SMP
>  	GET_THREAD_INFO(%eax)
> -	movl TI_cpu(%eax), %eax
> -	movl __per_cpu_offset(,%eax,4), %eax
> -	mov xen_vcpu(%eax), %eax
> +	movl %ss:TI_cpu(%eax), %eax
> +	movl %ss:__per_cpu_offset(,%eax,4), %eax
> +	mov %ss:xen_vcpu(%eax), %eax
>  #else
> -	movl xen_vcpu, %eax
> +	movl %ss:xen_vcpu, %eax
>  #endif
>  
>  	/* check IF state we're restoring */
> @@ -106,11 +106,11 @@ ENTRY(xen_iret)
>  	 * resuming the code, so we don't have to be worried about
>  	 * being preempted to another CPU.
>  	 */
> -	setz XEN_vcpu_info_mask(%eax)
> +	setz %ss:XEN_vcpu_info_mask(%eax)
>  xen_iret_start_crit:
>  
>  	/* check for unmasked and pending */
> -	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
> +	cmpw $0x0001, %ss:XEN_vcpu_info_pending(%eax)
>  
>  	/*
>  	 * If there's something pending, mask events again so we can
> @@ -118,7 +118,7 @@ xen_iret_start_crit:
>  	 * touch XEN_vcpu_info_mask.
>  	 */
>  	jne 1f
> -	movb $1, XEN_vcpu_info_mask(%eax)
> +	movb $1, %ss:XEN_vcpu_info_mask(%eax)
>  
>  1:	popl %eax
>  
> -- 
> 1.8.0.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 21:53:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 21:53: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 1U66jC-0000SG-51; Thu, 14 Feb 2013 21:52:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1U66jA-0000SB-DL
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 21:52:24 +0000
Received: from [85.158.139.211:42501] by server-14.bemta-5.messagelabs.com id
	AC/A3-06967-79C5D115; Thu, 14 Feb 2013 21:52:23 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360878740!22271930!1
X-Originating-IP: [209.85.220.49]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6403 invoked from network); 14 Feb 2013 21:52:22 -0000
Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com)
	(209.85.220.49)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Feb 2013 21:52:22 -0000
Received: by mail-pa0-f49.google.com with SMTP id kp6so1480022pab.36
	for <xen-devel@lists.xensource.com>;
	Thu, 14 Feb 2013 13:52:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:mime-version
	:content-type:content-disposition:user-agent;
	bh=zoX2EZtrexrPnZh/5uggqFUfbxQgCQYa9m0XPP1qj2c=;
	b=FOQEg1/tNXlhMY5ndF0O490lvipn6CcHfnpERVak7OQ4EU0jxemlYE2dxYR358xTr8
	iSThPTs92U1VGsp1W3hZTGVLp8RcJ/O/6gVCKzuRqyQowZUTE3r4T4wEuDlTEr8qtktq
	LCHijwoB9MUEK6uOvAJ5UdVwuVDNaVmrCIXHU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:mime-version
	:content-type:content-disposition:user-agent:x-gm-message-state;
	bh=zoX2EZtrexrPnZh/5uggqFUfbxQgCQYa9m0XPP1qj2c=;
	b=Ve0WLmtgfSPplI/0qJAEOz5S2akhG0AoEAV6EFGmqFteM1vk5BxZV1FEsstOl3MhmL
	cfl1G89DML5fW5HXKbfossIEVMu2dtqnN4x0TszQs3xUDg5fU7NeXa76z7B6mSMUou05
	OeS8tLiXvY8kwKgVfy2UNFv+Kg7FUCqM0mBMfr4pddkUjn2jf99wF8Q2+Oa03QpP0Swb
	epBzguk10BhdjdV5zXHL8emH8UgJkQv2JNRmrJpyfAh3LLAYFL0+1VTaX+IxLwURaHKl
	xZQFTVYc8amnbJQnwmCNyMZvi5hjCHQLhL67N8uQgXjRLjg0Tv7RA43sWaPa1s90/l/4
	Vfsg==
X-Received: by 10.66.75.136 with SMTP id c8mr7692419paw.25.1360878740162;
	Thu, 14 Feb 2013 13:52:20 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id d8sm91311894pax.23.2013.02.14.13.52.17
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 14 Feb 2013 13:52:19 -0800 (PST)
Date: Thu, 14 Feb 2013 13:52:16 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Jan Beulich <JBeulich@suse.com>, Petr Matousek <pmatouse@redhat.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130214215216.GA18740@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlqI5VFTI5AaUU7Z8AgiM1OGeEcabusyqjo5Z08NW/s+ar6TIopDMS3lh2K1AxV0zn1BMql
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	stable@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, any reason why this patch isn't in Linus's tree already, and why it
wasn't marked for inclusion in a -stable kernel release?

thanks,

greg k-h


On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote:
> This fixes CVE-2013-0228 / XSA-42
> 
> Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
> in 32bit PV guest can use to crash the > guest with the panic like this:
> 
> -------------
> general protection fault: 0000 [#1] SMP
> last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
> mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
> unloaded: scsi_wait_scan]
> 
> Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
> EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
> EIP is at xen_iret+0x12/0x2b
> EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
> ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
>  DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
> Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
> Stack:
>  00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
> Call Trace:
> Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
> 8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
> 10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
> EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
> general protection fault: 0000 [#2]
> ---[ end trace ab0d29a492dcd330 ]---
> Kernel panic - not syncing: Fatal exception
> Pid: 1250, comm: r Tainted: G      D    ---------------
> 2.6.32-356.el6.i686 #1
> Call Trace:
>  [<c08476df>] ? panic+0x6e/0x122
>  [<c084b63c>] ? oops_end+0xbc/0xd0
>  [<c084b260>] ? do_general_protection+0x0/0x210
>  [<c084a9b7>] ? error_code+0x73/
> -------------
> 
> Petr says: "
>  I've analysed the bug and I think that xen_iret() cannot cope with
>  mangled DS, in this case zeroed out (null selector/descriptor) by either
>  xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
>  entry was invalidated by the reproducer. "
> 
> Jan took a look at the preliminary patch and came up a fix that solves
> this problem:
> 
> "This code gets called after all registers other than those handled by
> IRET got already restored, hence a null selector in %ds or a non-null
> one that got loaded from a code or read-only data descriptor would
> cause a kernel mode fault (with the potential of crashing the kernel
> as a whole, if panic_on_oops is set)."
> 
> The way to fix this is to realize that the we can only relay on the
> registers that IRET restores. The two that are guaranteed are the
> %cs and %ss as they are always fixed GDT selectors. Also they are
> inaccessible from user mode - so they cannot be altered. This is
> the approach taken in this patch.
> 
> Another alternative option suggested by Jan would be to relay on
> the subtle realization that using the %ebp or %esp relative references uses
> the %ss segment.  In which case we could switch from using %eax to %ebp and
> would not need the %ss over-rides. That would also require one extra
> instruction to compensate for the one place where the register is used
> as scaled index. However Andrew pointed out that is too subtle and if
> further work was to be done in this code-path it could escape folks attention
> and lead to accidents.
> 
> Reviewed-by: Petr Matousek <pmatouse@redhat.com>
> Reported-by: Petr Matousek <pmatouse@redhat.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/xen-asm_32.S | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
> index f9643fc..33ca6e4 100644
> --- a/arch/x86/xen/xen-asm_32.S
> +++ b/arch/x86/xen/xen-asm_32.S
> @@ -89,11 +89,11 @@ ENTRY(xen_iret)
>  	 */
>  #ifdef CONFIG_SMP
>  	GET_THREAD_INFO(%eax)
> -	movl TI_cpu(%eax), %eax
> -	movl __per_cpu_offset(,%eax,4), %eax
> -	mov xen_vcpu(%eax), %eax
> +	movl %ss:TI_cpu(%eax), %eax
> +	movl %ss:__per_cpu_offset(,%eax,4), %eax
> +	mov %ss:xen_vcpu(%eax), %eax
>  #else
> -	movl xen_vcpu, %eax
> +	movl %ss:xen_vcpu, %eax
>  #endif
>  
>  	/* check IF state we're restoring */
> @@ -106,11 +106,11 @@ ENTRY(xen_iret)
>  	 * resuming the code, so we don't have to be worried about
>  	 * being preempted to another CPU.
>  	 */
> -	setz XEN_vcpu_info_mask(%eax)
> +	setz %ss:XEN_vcpu_info_mask(%eax)
>  xen_iret_start_crit:
>  
>  	/* check for unmasked and pending */
> -	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
> +	cmpw $0x0001, %ss:XEN_vcpu_info_pending(%eax)
>  
>  	/*
>  	 * If there's something pending, mask events again so we can
> @@ -118,7 +118,7 @@ xen_iret_start_crit:
>  	 * touch XEN_vcpu_info_mask.
>  	 */
>  	jne 1f
> -	movb $1, XEN_vcpu_info_mask(%eax)
> +	movb $1, %ss:XEN_vcpu_info_mask(%eax)
>  
>  1:	popl %eax
>  
> -- 
> 1.8.0.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 21:58:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 21:58: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 1U66oc-0000eo-Vp; Thu, 14 Feb 2013 21:58:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U66ob-0000ei-59
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 21:58:01 +0000
Received: from [85.158.139.83:23198] by server-7.bemta-5.messagelabs.com id
	E6/91-11121-8ED5D115; Thu, 14 Feb 2013 21:58:00 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360879079!29960931!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8979 invoked from network); 14 Feb 2013 21:57:59 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-5.tower-182.messagelabs.com with SMTP;
	14 Feb 2013 21:57:59 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1ELvp3t001394;
	Thu, 14 Feb 2013 16:57:51 -0500
Message-ID: <511D5DDF.7040000@theshore.net>
Date: Thu, 14 Feb 2013 16:57:51 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: Re: [Xen-devel] xen-netback: fix oopes during shutdown and error
 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-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 2/14/13 8:18 AM, David Vrabel wrote:
> These two netback patches fix oopes that may occur during shutdown or
> if a specific fatal error occurs.

On 2/14/13 11:39 AM, Ian Campbell wrote:
> Although I would like to add a Tested-by: Christopher too if
> possible.

Tested-by: Christopher S. Aker <caker@theshore.net> (and team)

We are no longer able to trigger the last OOPs we provided by downing 
the vif.  Further testing of the other issues will take time, but we're 
deploying a few patched hosts now.

Thanks!
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 21:58:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 21:58: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 1U66oc-0000eo-Vp; Thu, 14 Feb 2013 21:58:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <caker@theshore.net>) id 1U66ob-0000ei-59
	for xen-devel@lists.xen.org; Thu, 14 Feb 2013 21:58:01 +0000
Received: from [85.158.139.83:23198] by server-7.bemta-5.messagelabs.com id
	E6/91-11121-8ED5D115; Thu, 14 Feb 2013 21:58:00 +0000
X-Env-Sender: caker@theshore.net
X-Msg-Ref: server-5.tower-182.messagelabs.com!1360879079!29960931!1
X-Originating-IP: [67.18.92.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8979 invoked from network); 14 Feb 2013 21:57:59 -0000
Received: from ns.theshore.net (HELO www.theshore.net) (67.18.92.50)
	by server-5.tower-182.messagelabs.com with SMTP;
	14 Feb 2013 21:57:59 -0000
Received: from beefcake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by www.theshore.net (8.13.6/8.9.1) with ESMTP id r1ELvp3t001394;
	Thu, 14 Feb 2013 16:57:51 -0500
Message-ID: <511D5DDF.7040000@theshore.net>
Date: Thu, 14 Feb 2013 16:57:51 -0500
From: "Christopher S. Aker" <caker@theshore.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	netdev@vger.kernel.org, xen-devel@lists.xen.org,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu@citrix.com>
Subject: Re: [Xen-devel] xen-netback: fix oopes during shutdown and error
 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-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 2/14/13 8:18 AM, David Vrabel wrote:
> These two netback patches fix oopes that may occur during shutdown or
> if a specific fatal error occurs.

On 2/14/13 11:39 AM, Ian Campbell wrote:
> Although I would like to add a Tested-by: Christopher too if
> possible.

Tested-by: Christopher S. Aker <caker@theshore.net> (and team)

We are no longer able to trigger the last OOPs we provided by downing 
the vif.  Further testing of the other issues will take time, but we're 
deploying a few patched hosts now.

Thanks!
-Chris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 14 22:56:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 22: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 1U67il-0001Mb-05; Thu, 14 Feb 2013 22:56:03 +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 1U67ij-0001MW-1P
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 22:56:01 +0000
Received: from [85.158.139.83:9557] by server-12.bemta-5.messagelabs.com id
	2F/01-20195-08B6D115; Thu, 14 Feb 2013 22:56:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360882558!23856167!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIzOTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1731 invoked from network); 14 Feb 2013 22:55:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 22:55:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EMtnOd003532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 22:55:50 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
	r1EMtmSI012949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 22:55:48 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
	r1EMtkM2011131; Thu, 14 Feb 2013 16:55:46 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 14:55:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A9C611C387B; Thu, 14 Feb 2013 17:55:44 -0500 (EST)
Date: Thu, 14 Feb 2013 17:55:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Message-ID: <20130214225544.GA8068@phenom.dumpdata.com>
References: <20130214215216.GA18740@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130214215216.GA18740@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 14, 2013 at 01:52:16PM -0800, Greg KH wrote:
> Jan, any reason why this patch isn't in Linus's tree already, and why it

Sent out the GIT PULL this week to Linus
> wasn't marked for inclusion in a -stable kernel release?

I forgot to stick that. Do please include it in the stable tree.

> 
> thanks,
> 
> greg k-h
> 
> 
> On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote:
> > This fixes CVE-2013-0228 / XSA-42
> > 
> > Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
> > in 32bit PV guest can use to crash the > guest with the panic like this:
> > 
> > -------------
> > general protection fault: 0000 [#1] SMP
> > last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
> > Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> > iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> > xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
> > mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
> > unloaded: scsi_wait_scan]
> > 
> > Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
> > EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
> > EIP is at xen_iret+0x12/0x2b
> > EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
> > ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
> >  DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
> > Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
> > Stack:
> >  00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
> > Call Trace:
> > Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
> > 8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
> > 10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
> > EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
> > general protection fault: 0000 [#2]
> > ---[ end trace ab0d29a492dcd330 ]---
> > Kernel panic - not syncing: Fatal exception
> > Pid: 1250, comm: r Tainted: G      D    ---------------
> > 2.6.32-356.el6.i686 #1
> > Call Trace:
> >  [<c08476df>] ? panic+0x6e/0x122
> >  [<c084b63c>] ? oops_end+0xbc/0xd0
> >  [<c084b260>] ? do_general_protection+0x0/0x210
> >  [<c084a9b7>] ? error_code+0x73/
> > -------------
> > 
> > Petr says: "
> >  I've analysed the bug and I think that xen_iret() cannot cope with
> >  mangled DS, in this case zeroed out (null selector/descriptor) by either
> >  xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
> >  entry was invalidated by the reproducer. "
> > 
> > Jan took a look at the preliminary patch and came up a fix that solves
> > this problem:
> > 
> > "This code gets called after all registers other than those handled by
> > IRET got already restored, hence a null selector in %ds or a non-null
> > one that got loaded from a code or read-only data descriptor would
> > cause a kernel mode fault (with the potential of crashing the kernel
> > as a whole, if panic_on_oops is set)."
> > 
> > The way to fix this is to realize that the we can only relay on the
> > registers that IRET restores. The two that are guaranteed are the
> > %cs and %ss as they are always fixed GDT selectors. Also they are
> > inaccessible from user mode - so they cannot be altered. This is
> > the approach taken in this patch.
> > 
> > Another alternative option suggested by Jan would be to relay on
> > the subtle realization that using the %ebp or %esp relative references uses
> > the %ss segment.  In which case we could switch from using %eax to %ebp and
> > would not need the %ss over-rides. That would also require one extra
> > instruction to compensate for the one place where the register is used
> > as scaled index. However Andrew pointed out that is too subtle and if
> > further work was to be done in this code-path it could escape folks attention
> > and lead to accidents.
> > 
> > Reviewed-by: Petr Matousek <pmatouse@redhat.com>
> > Reported-by: Petr Matousek <pmatouse@redhat.com>
> > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/xen-asm_32.S | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
> > index f9643fc..33ca6e4 100644
> > --- a/arch/x86/xen/xen-asm_32.S
> > +++ b/arch/x86/xen/xen-asm_32.S
> > @@ -89,11 +89,11 @@ ENTRY(xen_iret)
> >  	 */
> >  #ifdef CONFIG_SMP
> >  	GET_THREAD_INFO(%eax)
> > -	movl TI_cpu(%eax), %eax
> > -	movl __per_cpu_offset(,%eax,4), %eax
> > -	mov xen_vcpu(%eax), %eax
> > +	movl %ss:TI_cpu(%eax), %eax
> > +	movl %ss:__per_cpu_offset(,%eax,4), %eax
> > +	mov %ss:xen_vcpu(%eax), %eax
> >  #else
> > -	movl xen_vcpu, %eax
> > +	movl %ss:xen_vcpu, %eax
> >  #endif
> >  
> >  	/* check IF state we're restoring */
> > @@ -106,11 +106,11 @@ ENTRY(xen_iret)
> >  	 * resuming the code, so we don't have to be worried about
> >  	 * being preempted to another CPU.
> >  	 */
> > -	setz XEN_vcpu_info_mask(%eax)
> > +	setz %ss:XEN_vcpu_info_mask(%eax)
> >  xen_iret_start_crit:
> >  
> >  	/* check for unmasked and pending */
> > -	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
> > +	cmpw $0x0001, %ss:XEN_vcpu_info_pending(%eax)
> >  
> >  	/*
> >  	 * If there's something pending, mask events again so we can
> > @@ -118,7 +118,7 @@ xen_iret_start_crit:
> >  	 * touch XEN_vcpu_info_mask.
> >  	 */
> >  	jne 1f
> > -	movb $1, XEN_vcpu_info_mask(%eax)
> > +	movb $1, %ss:XEN_vcpu_info_mask(%eax)
> >  
> >  1:	popl %eax
> >  
> > -- 
> > 1.8.0.2
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 14 22:56:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 14 Feb 2013 22: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 1U67il-0001Mb-05; Thu, 14 Feb 2013 22:56:03 +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 1U67ij-0001MW-1P
	for xen-devel@lists.xensource.com; Thu, 14 Feb 2013 22:56:01 +0000
Received: from [85.158.139.83:9557] by server-12.bemta-5.messagelabs.com id
	2F/01-20195-08B6D115; Thu, 14 Feb 2013 22:56:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360882558!23856167!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIzOTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1731 invoked from network); 14 Feb 2013 22:55:59 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Feb 2013 22:55:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1EMtnOd003532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 14 Feb 2013 22:55:50 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
	r1EMtmSI012949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 14 Feb 2013 22:55:48 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
	r1EMtkM2011131; Thu, 14 Feb 2013 16:55:46 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 14:55:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A9C611C387B; Thu, 14 Feb 2013 17:55:44 -0500 (EST)
Date: Thu, 14 Feb 2013 17:55:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Message-ID: <20130214225544.GA8068@phenom.dumpdata.com>
References: <20130214215216.GA18740@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130214215216.GA18740@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 14, 2013 at 01:52:16PM -0800, Greg KH wrote:
> Jan, any reason why this patch isn't in Linus's tree already, and why it

Sent out the GIT PULL this week to Linus
> wasn't marked for inclusion in a -stable kernel release?

I forgot to stick that. Do please include it in the stable tree.

> 
> thanks,
> 
> greg k-h
> 
> 
> On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote:
> > This fixes CVE-2013-0228 / XSA-42
> > 
> > Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
> > in 32bit PV guest can use to crash the > guest with the panic like this:
> > 
> > -------------
> > general protection fault: 0000 [#1] SMP
> > last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
> > Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> > iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> > xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
> > mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
> > unloaded: scsi_wait_scan]
> > 
> > Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
> > EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
> > EIP is at xen_iret+0x12/0x2b
> > EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
> > ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
> >  DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
> > Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
> > Stack:
> >  00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
> > Call Trace:
> > Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
> > 8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
> > 10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
> > EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
> > general protection fault: 0000 [#2]
> > ---[ end trace ab0d29a492dcd330 ]---
> > Kernel panic - not syncing: Fatal exception
> > Pid: 1250, comm: r Tainted: G      D    ---------------
> > 2.6.32-356.el6.i686 #1
> > Call Trace:
> >  [<c08476df>] ? panic+0x6e/0x122
> >  [<c084b63c>] ? oops_end+0xbc/0xd0
> >  [<c084b260>] ? do_general_protection+0x0/0x210
> >  [<c084a9b7>] ? error_code+0x73/
> > -------------
> > 
> > Petr says: "
> >  I've analysed the bug and I think that xen_iret() cannot cope with
> >  mangled DS, in this case zeroed out (null selector/descriptor) by either
> >  xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
> >  entry was invalidated by the reproducer. "
> > 
> > Jan took a look at the preliminary patch and came up a fix that solves
> > this problem:
> > 
> > "This code gets called after all registers other than those handled by
> > IRET got already restored, hence a null selector in %ds or a non-null
> > one that got loaded from a code or read-only data descriptor would
> > cause a kernel mode fault (with the potential of crashing the kernel
> > as a whole, if panic_on_oops is set)."
> > 
> > The way to fix this is to realize that the we can only relay on the
> > registers that IRET restores. The two that are guaranteed are the
> > %cs and %ss as they are always fixed GDT selectors. Also they are
> > inaccessible from user mode - so they cannot be altered. This is
> > the approach taken in this patch.
> > 
> > Another alternative option suggested by Jan would be to relay on
> > the subtle realization that using the %ebp or %esp relative references uses
> > the %ss segment.  In which case we could switch from using %eax to %ebp and
> > would not need the %ss over-rides. That would also require one extra
> > instruction to compensate for the one place where the register is used
> > as scaled index. However Andrew pointed out that is too subtle and if
> > further work was to be done in this code-path it could escape folks attention
> > and lead to accidents.
> > 
> > Reviewed-by: Petr Matousek <pmatouse@redhat.com>
> > Reported-by: Petr Matousek <pmatouse@redhat.com>
> > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/xen-asm_32.S | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
> > index f9643fc..33ca6e4 100644
> > --- a/arch/x86/xen/xen-asm_32.S
> > +++ b/arch/x86/xen/xen-asm_32.S
> > @@ -89,11 +89,11 @@ ENTRY(xen_iret)
> >  	 */
> >  #ifdef CONFIG_SMP
> >  	GET_THREAD_INFO(%eax)
> > -	movl TI_cpu(%eax), %eax
> > -	movl __per_cpu_offset(,%eax,4), %eax
> > -	mov xen_vcpu(%eax), %eax
> > +	movl %ss:TI_cpu(%eax), %eax
> > +	movl %ss:__per_cpu_offset(,%eax,4), %eax
> > +	mov %ss:xen_vcpu(%eax), %eax
> >  #else
> > -	movl xen_vcpu, %eax
> > +	movl %ss:xen_vcpu, %eax
> >  #endif
> >  
> >  	/* check IF state we're restoring */
> > @@ -106,11 +106,11 @@ ENTRY(xen_iret)
> >  	 * resuming the code, so we don't have to be worried about
> >  	 * being preempted to another CPU.
> >  	 */
> > -	setz XEN_vcpu_info_mask(%eax)
> > +	setz %ss:XEN_vcpu_info_mask(%eax)
> >  xen_iret_start_crit:
> >  
> >  	/* check for unmasked and pending */
> > -	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
> > +	cmpw $0x0001, %ss:XEN_vcpu_info_pending(%eax)
> >  
> >  	/*
> >  	 * If there's something pending, mask events again so we can
> > @@ -118,7 +118,7 @@ xen_iret_start_crit:
> >  	 * touch XEN_vcpu_info_mask.
> >  	 */
> >  	jne 1f
> > -	movb $1, XEN_vcpu_info_mask(%eax)
> > +	movb $1, %ss:XEN_vcpu_info_mask(%eax)
> >  
> >  1:	popl %eax
> >  
> > -- 
> > 1.8.0.2
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 15 00:44:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 00:44: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 1U69PX-0002Pj-N3; Fri, 15 Feb 2013 00:44: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 1U69PV-0002Pe-LY
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 00:44:17 +0000
Received: from [85.158.143.99:56885] by server-1.bemta-4.messagelabs.com id
	10/20-08839-0E48D115; Fri, 15 Feb 2013 00:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360889056!24235375!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29402 invoked from network); 15 Feb 2013 00:44:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 00:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,668,1355097600"; 
   d="scan'208";a="1489465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 00: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.297.1; Fri, 15 Feb 2013 00:44:15 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U69PT-0001z2-Iw;
	Fri, 15 Feb 2013 00:44:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U69PT-0001nd-GU;
	Fri, 15 Feb 2013 00:44:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16179-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Feb 2013 00:44:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16179: 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 16179 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16179/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-saverestore.2   fail pass in 16164
 test-amd64-i386-rhel6hvm-intel  4 xen-install      fail in 16164 pass in 16179
 test-amd64-i386-qemut-win-vcpus1 8 guest-saverestore fail in 16164 pass in 16179

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              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-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 16164 never pass

version targeted for testing:
 linux                a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 11 08:27:49 2013 -0800

    Linux 3.0.63

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 00:44:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 00:44: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 1U69PX-0002Pj-N3; Fri, 15 Feb 2013 00:44: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 1U69PV-0002Pe-LY
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 00:44:17 +0000
Received: from [85.158.143.99:56885] by server-1.bemta-4.messagelabs.com id
	10/20-08839-0E48D115; Fri, 15 Feb 2013 00:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360889056!24235375!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNTYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29402 invoked from network); 15 Feb 2013 00:44:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 00:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,668,1355097600"; 
   d="scan'208";a="1489465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 00: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.297.1; Fri, 15 Feb 2013 00:44:15 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U69PT-0001z2-Iw;
	Fri, 15 Feb 2013 00:44:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U69PT-0001nd-GU;
	Fri, 15 Feb 2013 00:44:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16179-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 15 Feb 2013 00:44:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16179: 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 16179 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16179/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-saverestore.2   fail pass in 16164
 test-amd64-i386-rhel6hvm-intel  4 xen-install      fail in 16164 pass in 16179
 test-amd64-i386-qemut-win-vcpus1 8 guest-saverestore fail in 16164 pass in 16179

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              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-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 16164 never pass

version targeted for testing:
 linux                a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 a96dbfbcb58afeec72c2a0a03d205e0e1457ea3d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 11 08:27:49 2013 -0800

    Linux 3.0.63

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 02:31:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 02: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 1U6B4x-0006xi-49; Fri, 15 Feb 2013 02:31:11 +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 1U6B4v-0006xd-2P
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 02:31:09 +0000
Received: from [85.158.143.99:54570] by server-2.bemta-4.messagelabs.com id
	1D/37-01597-CED9D115; Fri, 15 Feb 2013 02:31:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360895465!27125080!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzUxMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11589 invoked from network); 15 Feb 2013 02:31:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 02:31:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1F2V0iq031383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 02:31:01 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
	r1F2UxSR021246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 02:31:00 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
	r1F2UwTM023093; Thu, 14 Feb 2013 20:30:59 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 18:30:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E82C81C387B; Thu, 14 Feb 2013 21:30:56 -0500 (EST)
Date: Thu, 14 Feb 2013 21:30:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130215023056.GD8440@phenom.dumpdata.com>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130214151509.GA31892@aepfle.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <20130214151509.GA31892@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Feb 14, 2013 at 04:15:09PM +0100, Olaf Hering wrote:
> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:
> 
> > Any thoughts of what might be wrong?
> 
> After a quick browsing of the involved code I dont see anything obvious.
> Since kexec for PVonHVM does not work anyway even with this patch,
> please revert 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f and
> a7be94ac8d69c037d08f0fd94b45a593f1d45176 to avoid the regression.

OK.
> 
> Please also send the .config for the guest, and say if dom0 is 32bit as
> well.

Dom0 is 64-bit.  And attached is the config.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=".config"

#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.8.0-rc7 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="upstream"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_INITRAMFS_COMPRESSION_NONE is not set
CONFIG_INITRAMFS_COMPRESSION_GZIP=y
# CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set
# CONFIG_INITRAMFS_COMPRESSION_LZMA is not set
# CONFIG_INITRAMFS_COMPRESSION_XZ is not set
# CONFIG_INITRAMFS_COMPRESSION_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
CONFIG_OPTPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_GENERIC_SIGALTSTACK=y
CONFIG_CLONE_BACKWARDS=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_MPPARSE=y
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_X86_32_IRIS is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=64
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_KVM_GUEST=y
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_SPINLOCKS=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
# CONFIG_X86_PPRO_FENCE is not set
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_ANCIENT_MCE=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=y
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_HIGHPTE=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
CONFIG_EFI=y
# CONFIG_EFI_STUB is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_I2C=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
# CONFIG_ACPI_BGRT is not set
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_EINJ=y
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
# CONFIG_SFI is not set
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# x86 CPU frequency scaling drivers
#
# CONFIG_X86_PCC_CPUFREQ is not set
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
CONFIG_X86_POWERNOW_K8=m
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
# CONFIG_PCI_IOAPIC is not set
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_SCx200 is not set
# CONFIG_ALIX is not set
# CONFIG_NET5501 is not set
# CONFIG_GEOS is not set
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_ADVANCED is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_IRC=y
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CT_NETLINK=y
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
# CONFIG_NF_NAT_AMANDA is not set
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
# CONFIG_NF_NAT_TFTP is not set
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
CONFIG_NETFILTER_XT_TARGET_LOG=m
# CONFIG_NETFILTER_XT_TARGET_NETMAP is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_REDIRECT is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y

#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT_IPV4=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_RAW is not set

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=y
CONFIG_NF_CONNTRACK_IPV6=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
# CONFIG_IP6_NF_RAW is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFB is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
# CONFIG_NET_SCH_QFQ is not set
# CONFIG_NET_SCH_CODEL is not set
# CONFIG_NET_SCH_FQ_CODEL is not set
# CONFIG_NET_SCH_INGRESS is not set
# CONFIG_NET_SCH_PLUG is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
# CONFIG_NET_ACT_CSUM is not set
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_VIRTIO_BLK=m
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_INTEL_MID_PTI is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_VMWARE_BALLOON is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_PCH_PHUB is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_BE2ISCSI is not set
CONFIG_BLK_DEV_3W_XXXX_RAID=m
# CONFIG_SCSI_HPSA is not set
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_3W_SAS is not set
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=m
# CONFIG_AIC94XX_DEBUG is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
# CONFIG_SCSI_MVSAS_TASKLET is not set
# CONFIG_SCSI_MVUMI is not set
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_UFSHCD is not set
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_FLASHPOINT=y
# CONFIG_VMWARE_PVSCSI is not set
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
# CONFIG_FCOE_FNIC is not set
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_ISCI=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
# CONFIG_TCM_QLA2XXX is not set
# CONFIG_SCSI_QLA_ISCSI is not set
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_DEBUG=m
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
CONFIG_SCSI_SRP=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
# CONFIG_SCSI_CHELSIO_FCOE is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_SATA_INIC162X=m
# CONFIG_SATA_ACARD_AHCI is not set
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_HIGHBANK is not set
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARASAN_CF is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
CONFIG_PATA_EFAR=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
CONFIG_PATA_MARVELL=m
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
CONFIG_PATA_PDC_OLD=m
CONFIG_PATA_RADISYS=m
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=m
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
CONFIG_PATA_SIS=m
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
CONFIG_PATA_WINBOND=m

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
CONFIG_PATA_PCMCIA=m
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_PATA_ACPI is not set
CONFIG_ATA_GENERIC=m
CONFIG_PATA_LEGACY=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
# CONFIG_MULTICORE_RAID456 is not set
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
# CONFIG_DM_THIN_PROVISIONING is not set
CONFIG_DM_MIRROR=m
# CONFIG_DM_RAID is not set
# CONFIG_DM_LOG_USERSPACE is not set
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
# CONFIG_DM_MULTIPATH_QL is not set
# CONFIG_DM_MULTIPATH_ST is not set
CONFIG_DM_DELAY=m
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
CONFIG_LOOPBACK_TARGET=m
CONFIG_TCM_FC=m
CONFIG_ISCSI_TARGET=m
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
CONFIG_MII=m
# CONFIG_IFB is not set
# CONFIG_NET_TEAM is not set
CONFIG_MACVLAN=y
CONFIG_MACVTAP=y
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=y
# CONFIG_VETH is not set
CONFIG_VIRTIO_NET=m
CONFIG_SUNGEM_PHY=m
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_MDIO=m
CONFIG_NET_VENDOR_3COM=y
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_3C589 is not set
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_NET_VENDOR_ADAPTEC=y
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
# CONFIG_PCMCIA_NMCLAN is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
CONFIG_ATL1C=m
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=m
# CONFIG_CNIC is not set
CONFIG_TIGON3=y
CONFIG_BNX2X=m
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_NET_VENDOR_CISCO=y
# CONFIG_ENIC is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
CONFIG_NET_VENDOR_FUJITSU=y
# CONFIG_PCMCIA_FMVJ18X is not set
CONFIG_NET_VENDOR_HP=y
# CONFIG_HP100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E100=m
CONFIG_E1000=m
CONFIG_E1000E=m
CONFIG_IGB=m
CONFIG_IGB_DCA=y
CONFIG_IGBVF=m
CONFIG_IXGB=m
CONFIG_IXGBE=m
CONFIG_IXGBE_HWMON=y
CONFIG_IXGBE_DCA=y
CONFIG_IXGBE_DCB=y
CONFIG_IXGBEVF=y
CONFIG_NET_VENDOR_I825XX=y
# CONFIG_ZNET is not set
# CONFIG_IP1000 is not set
# CONFIG_JME is not set
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_SKGE=m
# CONFIG_SKGE_DEBUG is not set
# CONFIG_SKGE_GENESIS is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_KSZ884X_PCI is not set
CONFIG_NET_VENDOR_MYRI=y
# CONFIG_MYRI10GE is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
# CONFIG_NATSEMI is not set
# CONFIG_NS83820 is not set
CONFIG_NET_VENDOR_8390=y
# CONFIG_PCMCIA_AXNET is not set
CONFIG_NE2K_PCI=m
# CONFIG_PCMCIA_PCNET is not set
CONFIG_NET_VENDOR_NVIDIA=y
CONFIG_FORCEDETH=y
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
# CONFIG_ETHOC is not set
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
# CONFIG_QLGE is not set
# CONFIG_NETXEN_NIC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=m
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
CONFIG_NET_VENDOR_SEEQ=y
# CONFIG_SEEQ8005 is not set
CONFIG_NET_VENDOR_SILAN=y
CONFIG_SC92031=m
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
# CONFIG_SIS190 is not set
# CONFIG_SFC is not set
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
# CONFIG_NIU is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
CONFIG_TLAN=m
CONFIG_NET_VENDOR_VIA=y
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_VIA_VELOCITY=m
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_NET_VENDOR_XIRCOM=y
# CONFIG_PCMCIA_XIRC2PS is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
# CONFIG_MDIO_BITBANG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=y
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_POLLDEV is not set
CONFIG_INPUT_SPARSEKMAP=y
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_AS5011 is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_HANWANG is not set
# CONFIG_TABLET_USB_KBTAB is not set
# CONFIG_TABLET_USB_WACOM is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_KGDB_NMI is not set
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_ARC is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_GEODE=y
CONFIG_HW_RANDOM_VIA=y
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_HW_RANDOM_TPM=y
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=m
# CONFIG_TCG_TIS_I2C_INFINEON is not set
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_FAIR_SHARE is not set
CONFIG_STEP_WISE=y
# CONFIG_USER_SPACE is not set
# CONFIG_CPU_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_CS5535 is not set
# CONFIG_LPC_SCH is not set
# CONFIG_LPC_ICH is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_KMS=y
CONFIG_DRM_NOUVEAU=m
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
# CONFIG_DRM_NOUVEAU_BACKLIGHT is not set

#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
# CONFIG_DRM_I810 is not set
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_STUB_POULSBO is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=y
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=m
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_APPLE is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=m
CONFIG_HIDRAW=y
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=m

#
# Special HID drivers
#
CONFIG_HID_A4TECH=m
# CONFIG_HID_ACRUX is not set
CONFIG_HID_APPLE=m
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=m
CONFIG_HID_CHERRY=m
CONFIG_HID_CHICONY=m
CONFIG_HID_CYPRESS=m
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
CONFIG_HID_EZKEY=m
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
CONFIG_HID_GYRATION=m
# CONFIG_HID_TWINHAN is not set
CONFIG_HID_KENSINGTON=m
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
CONFIG_HID_LOGITECH=m
# CONFIG_HID_LOGITECH_DJ is not set
CONFIG_LOGITECH_FF=y
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
CONFIG_LOGIWHEELS_FF=y
CONFIG_HID_MICROSOFT=m
CONFIG_HID_MONTEREY=m
# CONFIG_HID_MULTITOUCH is not set
CONFIG_HID_NTRIG=m
# CONFIG_HID_ORTEK is not set
CONFIG_HID_PANTHERLORD=m
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=m
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
# CONFIG_HID_SPEEDLINK is not set
CONFIG_HID_SUNPLUS=m
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
CONFIG_HID_TOPSEED=m
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=m
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set

#
# USB Physical Layer drivers
#
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_DELL_NETBOOKS is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=y
# CONFIG_EDAC_MCE_INJ is not set
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
CONFIG_INTEL_IOATDMA=y
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
CONFIG_DCA=y
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SELFBALLOONING=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PRIVCMD=m
CONFIG_XEN_ACPI_PROCESSOR=y
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_STAGING=y
# CONFIG_ET131X is not set
# CONFIG_SLICOSS is not set
# CONFIG_USBIP_CORE is not set
# CONFIG_ECHO is not set
# CONFIG_COMEDI is not set
# CONFIG_ASUS_OLED is not set
# CONFIG_RTS5139 is not set
# CONFIG_TRANZPORT is not set
# CONFIG_IDE_PHISON is not set
# CONFIG_DX_SEP is not set
CONFIG_ZRAM=y
# CONFIG_ZRAM_DEBUG is not set
CONFIG_ZCACHE=y
CONFIG_ZSMALLOC=y
# CONFIG_FB_SM7XX is not set
# CONFIG_CRYSTALHD is not set
# CONFIG_FB_XGI is not set
# CONFIG_ACPI_QUICKSTART is not set
# CONFIG_USB_ENESTORAGE is not set
# CONFIG_BCM_WIMAX is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_WIMAX_GDM72XX is not set
CONFIG_NET_VENDOR_SILICOM=y
# CONFIG_SBYPASS is not set
# CONFIG_BPCTL is not set
# CONFIG_CED1401 is not set
# CONFIG_DGRP is not set
# CONFIG_SB105X is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ACERHDF is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_DELL_WMI is not set
# CONFIG_DELL_WMI_AIO is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_FUJITSU_TABLET is not set
# CONFIG_AMILO_RFKILL is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_HP_ACCEL is not set
# CONFIG_HP_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_IDEAPAD_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ASUS_WMI is not set
CONFIG_ACPI_WMI=m
# CONFIG_MSI_WMI is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_TOSHIBA_BT_RFKILL is not set
# CONFIG_ACPI_CMPC is not set
# CONFIG_INTEL_IPS is not set
# CONFIG_IBM_RTL is not set
# CONFIG_XO15_EBOOK is not set
# CONFIG_SAMSUNG_LAPTOP is not set
CONFIG_MXM_WMI=m
# CONFIG_INTEL_OAKTRAIL is not set
# CONFIG_SAMSUNG_Q10 is not set
# CONFIG_APPLE_GMUX is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_INTEL_IOMMU is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_DMI_SYSFS is not set
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
# CONFIG_GOOGLE_FIRMWARE is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=m
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_FS_XIP=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_RAM is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_REDUCED=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
# CONFIG_FAIL_PAGE_ALLOC is not set
CONFIG_FAIL_MAKE_REQUEST=y
# CONFIG_FAIL_IO_TIMEOUT is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
# CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENT=y
# CONFIG_UPROBE_EVENT is not set
CONFIG_PROBE_EVENTS=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_ASYNC_RAID6_TEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
# CONFIG_KGDB_LOW_LEVEL_TRAP is not set
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_KMEMCHECK is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
CONFIG_DEBUG_SET_MODULE_RONX=y
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
CONFIG_LSM_MMAP_MIN_ADDR=65534
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32C_INTEL=m
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_586 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
# CONFIG_KVM_MMU_AUDIT is not set
CONFIG_VHOST_NET=y
# CONFIG_TCM_VHOST is not set
# CONFIG_LGUEST is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--C7zPtVaVf+AK4Oqc--


From xen-devel-bounces@lists.xen.org Fri Feb 15 02:31:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 02: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 1U6B4x-0006xi-49; Fri, 15 Feb 2013 02:31:11 +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 1U6B4v-0006xd-2P
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 02:31:09 +0000
Received: from [85.158.143.99:54570] by server-2.bemta-4.messagelabs.com id
	1D/37-01597-CED9D115; Fri, 15 Feb 2013 02:31:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360895465!27125080!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzUxMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11589 invoked from network); 15 Feb 2013 02:31:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 02:31:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1F2V0iq031383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 02:31:01 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
	r1F2UxSR021246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 02:31:00 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
	r1F2UwTM023093; Thu, 14 Feb 2013 20:30:59 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 18:30:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E82C81C387B; Thu, 14 Feb 2013 21:30:56 -0500 (EST)
Date: Thu, 14 Feb 2013 21:30:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130215023056.GD8440@phenom.dumpdata.com>
References: <20130213181103.GC20042@phenom.dumpdata.com>
	<20130214151509.GA31892@aepfle.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <20130214151509.GA31892@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f (xen
 PVonHVM: use E820_Reserved area for shared_info) causes regression with
 32-bit PVHVM guests (v3.8-rcX) on Xen 4.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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Feb 14, 2013 at 04:15:09PM +0100, Olaf Hering wrote:
> On Wed, Feb 13, Konrad Rzeszutek Wilk wrote:
> 
> > Any thoughts of what might be wrong?
> 
> After a quick browsing of the involved code I dont see anything obvious.
> Since kexec for PVonHVM does not work anyway even with this patch,
> please revert 9d02b43dee0d7fb18dfb13a00915550b1a3daa9f and
> a7be94ac8d69c037d08f0fd94b45a593f1d45176 to avoid the regression.

OK.
> 
> Please also send the .config for the guest, and say if dom0 is 32bit as
> well.

Dom0 is 64-bit.  And attached is the config.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=".config"

#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.8.0-rc7 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="upstream"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_INITRAMFS_COMPRESSION_NONE is not set
CONFIG_INITRAMFS_COMPRESSION_GZIP=y
# CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set
# CONFIG_INITRAMFS_COMPRESSION_LZMA is not set
# CONFIG_INITRAMFS_COMPRESSION_XZ is not set
# CONFIG_INITRAMFS_COMPRESSION_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
CONFIG_OPTPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_GENERIC_SIGALTSTACK=y
CONFIG_CLONE_BACKWARDS=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_MPPARSE=y
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_X86_32_IRIS is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=64
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_KVM_GUEST=y
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_SPINLOCKS=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
# CONFIG_X86_PPRO_FENCE is not set
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_ANCIENT_MCE=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=y
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_HIGHPTE=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
CONFIG_EFI=y
# CONFIG_EFI_STUB is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_I2C=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
# CONFIG_ACPI_BGRT is not set
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_EINJ=y
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
# CONFIG_SFI is not set
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# x86 CPU frequency scaling drivers
#
# CONFIG_X86_PCC_CPUFREQ is not set
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
CONFIG_X86_POWERNOW_K8=m
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
# CONFIG_PCI_IOAPIC is not set
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_SCx200 is not set
# CONFIG_ALIX is not set
# CONFIG_NET5501 is not set
# CONFIG_GEOS is not set
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_ADVANCED is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_IRC=y
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CT_NETLINK=y
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
# CONFIG_NF_NAT_AMANDA is not set
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
# CONFIG_NF_NAT_TFTP is not set
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
CONFIG_NETFILTER_XT_TARGET_LOG=m
# CONFIG_NETFILTER_XT_TARGET_NETMAP is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_REDIRECT is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y

#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT_IPV4=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_RAW is not set

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=y
CONFIG_NF_CONNTRACK_IPV6=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
# CONFIG_IP6_NF_RAW is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFB is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
# CONFIG_NET_SCH_QFQ is not set
# CONFIG_NET_SCH_CODEL is not set
# CONFIG_NET_SCH_FQ_CODEL is not set
# CONFIG_NET_SCH_INGRESS is not set
# CONFIG_NET_SCH_PLUG is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
# CONFIG_NET_ACT_CSUM is not set
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_VIRTIO_BLK=m
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_INTEL_MID_PTI is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_VMWARE_BALLOON is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_PCH_PHUB is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_BE2ISCSI is not set
CONFIG_BLK_DEV_3W_XXXX_RAID=m
# CONFIG_SCSI_HPSA is not set
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_3W_SAS is not set
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=m
# CONFIG_AIC94XX_DEBUG is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
# CONFIG_SCSI_MVSAS_TASKLET is not set
# CONFIG_SCSI_MVUMI is not set
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_UFSHCD is not set
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_FLASHPOINT=y
# CONFIG_VMWARE_PVSCSI is not set
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
# CONFIG_FCOE_FNIC is not set
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_ISCI=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
# CONFIG_TCM_QLA2XXX is not set
# CONFIG_SCSI_QLA_ISCSI is not set
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_DEBUG=m
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
CONFIG_SCSI_SRP=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
# CONFIG_SCSI_CHELSIO_FCOE is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_SATA_INIC162X=m
# CONFIG_SATA_ACARD_AHCI is not set
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_HIGHBANK is not set
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARASAN_CF is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
CONFIG_PATA_EFAR=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
CONFIG_PATA_MARVELL=m
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
CONFIG_PATA_PDC_OLD=m
CONFIG_PATA_RADISYS=m
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=m
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
CONFIG_PATA_SIS=m
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
CONFIG_PATA_WINBOND=m

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
CONFIG_PATA_PCMCIA=m
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_PATA_ACPI is not set
CONFIG_ATA_GENERIC=m
CONFIG_PATA_LEGACY=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
# CONFIG_MULTICORE_RAID456 is not set
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
# CONFIG_DM_THIN_PROVISIONING is not set
CONFIG_DM_MIRROR=m
# CONFIG_DM_RAID is not set
# CONFIG_DM_LOG_USERSPACE is not set
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
# CONFIG_DM_MULTIPATH_QL is not set
# CONFIG_DM_MULTIPATH_ST is not set
CONFIG_DM_DELAY=m
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
CONFIG_LOOPBACK_TARGET=m
CONFIG_TCM_FC=m
CONFIG_ISCSI_TARGET=m
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
CONFIG_MII=m
# CONFIG_IFB is not set
# CONFIG_NET_TEAM is not set
CONFIG_MACVLAN=y
CONFIG_MACVTAP=y
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=y
# CONFIG_VETH is not set
CONFIG_VIRTIO_NET=m
CONFIG_SUNGEM_PHY=m
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_MDIO=m
CONFIG_NET_VENDOR_3COM=y
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_3C589 is not set
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_NET_VENDOR_ADAPTEC=y
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
# CONFIG_PCMCIA_NMCLAN is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
CONFIG_ATL1C=m
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=m
# CONFIG_CNIC is not set
CONFIG_TIGON3=y
CONFIG_BNX2X=m
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_NET_VENDOR_CISCO=y
# CONFIG_ENIC is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
CONFIG_NET_VENDOR_FUJITSU=y
# CONFIG_PCMCIA_FMVJ18X is not set
CONFIG_NET_VENDOR_HP=y
# CONFIG_HP100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E100=m
CONFIG_E1000=m
CONFIG_E1000E=m
CONFIG_IGB=m
CONFIG_IGB_DCA=y
CONFIG_IGBVF=m
CONFIG_IXGB=m
CONFIG_IXGBE=m
CONFIG_IXGBE_HWMON=y
CONFIG_IXGBE_DCA=y
CONFIG_IXGBE_DCB=y
CONFIG_IXGBEVF=y
CONFIG_NET_VENDOR_I825XX=y
# CONFIG_ZNET is not set
# CONFIG_IP1000 is not set
# CONFIG_JME is not set
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_SKGE=m
# CONFIG_SKGE_DEBUG is not set
# CONFIG_SKGE_GENESIS is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_KSZ884X_PCI is not set
CONFIG_NET_VENDOR_MYRI=y
# CONFIG_MYRI10GE is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
# CONFIG_NATSEMI is not set
# CONFIG_NS83820 is not set
CONFIG_NET_VENDOR_8390=y
# CONFIG_PCMCIA_AXNET is not set
CONFIG_NE2K_PCI=m
# CONFIG_PCMCIA_PCNET is not set
CONFIG_NET_VENDOR_NVIDIA=y
CONFIG_FORCEDETH=y
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
# CONFIG_ETHOC is not set
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
# CONFIG_QLGE is not set
# CONFIG_NETXEN_NIC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=m
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
CONFIG_NET_VENDOR_SEEQ=y
# CONFIG_SEEQ8005 is not set
CONFIG_NET_VENDOR_SILAN=y
CONFIG_SC92031=m
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
# CONFIG_SIS190 is not set
# CONFIG_SFC is not set
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
# CONFIG_NIU is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
CONFIG_TLAN=m
CONFIG_NET_VENDOR_VIA=y
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_VIA_VELOCITY=m
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_NET_VENDOR_XIRCOM=y
# CONFIG_PCMCIA_XIRC2PS is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
# CONFIG_MDIO_BITBANG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=y
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_POLLDEV is not set
CONFIG_INPUT_SPARSEKMAP=y
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_AS5011 is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_HANWANG is not set
# CONFIG_TABLET_USB_KBTAB is not set
# CONFIG_TABLET_USB_WACOM is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_KGDB_NMI is not set
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_ARC is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_GEODE=y
CONFIG_HW_RANDOM_VIA=y
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_HW_RANDOM_TPM=y
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=m
# CONFIG_TCG_TIS_I2C_INFINEON is not set
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_FAIR_SHARE is not set
CONFIG_STEP_WISE=y
# CONFIG_USER_SPACE is not set
# CONFIG_CPU_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_CS5535 is not set
# CONFIG_LPC_SCH is not set
# CONFIG_LPC_ICH is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_KMS=y
CONFIG_DRM_NOUVEAU=m
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
# CONFIG_DRM_NOUVEAU_BACKLIGHT is not set

#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
# CONFIG_DRM_I810 is not set
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_STUB_POULSBO is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=y
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=m
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_APPLE is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=m
CONFIG_HIDRAW=y
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=m

#
# Special HID drivers
#
CONFIG_HID_A4TECH=m
# CONFIG_HID_ACRUX is not set
CONFIG_HID_APPLE=m
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=m
CONFIG_HID_CHERRY=m
CONFIG_HID_CHICONY=m
CONFIG_HID_CYPRESS=m
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
CONFIG_HID_EZKEY=m
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
CONFIG_HID_GYRATION=m
# CONFIG_HID_TWINHAN is not set
CONFIG_HID_KENSINGTON=m
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
CONFIG_HID_LOGITECH=m
# CONFIG_HID_LOGITECH_DJ is not set
CONFIG_LOGITECH_FF=y
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
CONFIG_LOGIWHEELS_FF=y
CONFIG_HID_MICROSOFT=m
CONFIG_HID_MONTEREY=m
# CONFIG_HID_MULTITOUCH is not set
CONFIG_HID_NTRIG=m
# CONFIG_HID_ORTEK is not set
CONFIG_HID_PANTHERLORD=m
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=m
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
# CONFIG_HID_SPEEDLINK is not set
CONFIG_HID_SUNPLUS=m
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
CONFIG_HID_TOPSEED=m
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=m
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set

#
# USB Physical Layer drivers
#
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_DELL_NETBOOKS is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=y
# CONFIG_EDAC_MCE_INJ is not set
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
CONFIG_INTEL_IOATDMA=y
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
CONFIG_DCA=y
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SELFBALLOONING=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PRIVCMD=m
CONFIG_XEN_ACPI_PROCESSOR=y
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_STAGING=y
# CONFIG_ET131X is not set
# CONFIG_SLICOSS is not set
# CONFIG_USBIP_CORE is not set
# CONFIG_ECHO is not set
# CONFIG_COMEDI is not set
# CONFIG_ASUS_OLED is not set
# CONFIG_RTS5139 is not set
# CONFIG_TRANZPORT is not set
# CONFIG_IDE_PHISON is not set
# CONFIG_DX_SEP is not set
CONFIG_ZRAM=y
# CONFIG_ZRAM_DEBUG is not set
CONFIG_ZCACHE=y
CONFIG_ZSMALLOC=y
# CONFIG_FB_SM7XX is not set
# CONFIG_CRYSTALHD is not set
# CONFIG_FB_XGI is not set
# CONFIG_ACPI_QUICKSTART is not set
# CONFIG_USB_ENESTORAGE is not set
# CONFIG_BCM_WIMAX is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_WIMAX_GDM72XX is not set
CONFIG_NET_VENDOR_SILICOM=y
# CONFIG_SBYPASS is not set
# CONFIG_BPCTL is not set
# CONFIG_CED1401 is not set
# CONFIG_DGRP is not set
# CONFIG_SB105X is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ACERHDF is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_DELL_WMI is not set
# CONFIG_DELL_WMI_AIO is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_FUJITSU_TABLET is not set
# CONFIG_AMILO_RFKILL is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_HP_ACCEL is not set
# CONFIG_HP_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_IDEAPAD_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ASUS_WMI is not set
CONFIG_ACPI_WMI=m
# CONFIG_MSI_WMI is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_TOSHIBA_BT_RFKILL is not set
# CONFIG_ACPI_CMPC is not set
# CONFIG_INTEL_IPS is not set
# CONFIG_IBM_RTL is not set
# CONFIG_XO15_EBOOK is not set
# CONFIG_SAMSUNG_LAPTOP is not set
CONFIG_MXM_WMI=m
# CONFIG_INTEL_OAKTRAIL is not set
# CONFIG_SAMSUNG_Q10 is not set
# CONFIG_APPLE_GMUX is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_INTEL_IOMMU is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_DMI_SYSFS is not set
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
# CONFIG_GOOGLE_FIRMWARE is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=m
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_FS_XIP=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_RAM is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_REDUCED=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
# CONFIG_FAIL_PAGE_ALLOC is not set
CONFIG_FAIL_MAKE_REQUEST=y
# CONFIG_FAIL_IO_TIMEOUT is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
# CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENT=y
# CONFIG_UPROBE_EVENT is not set
CONFIG_PROBE_EVENTS=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_ASYNC_RAID6_TEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
# CONFIG_KGDB_LOW_LEVEL_TRAP is not set
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_KMEMCHECK is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
CONFIG_DEBUG_SET_MODULE_RONX=y
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
CONFIG_LSM_MMAP_MIN_ADDR=65534
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32C_INTEL=m
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_586 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
# CONFIG_KVM_MMU_AUDIT is not set
CONFIG_VHOST_NET=y
# CONFIG_TCM_VHOST is not set
# CONFIG_LGUEST is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--C7zPtVaVf+AK4Oqc--


From xen-devel-bounces@lists.xen.org Fri Feb 15 02:46:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 02:46: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 1U6BJN-00079x-Sp; Fri, 15 Feb 2013 02:46:05 +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 1U6BJM-00079s-BX
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 02:46:04 +0000
Received: from [85.158.139.211:27429] by server-9.bemta-5.messagelabs.com id
	E1/7B-24440-B61AD115; Fri, 15 Feb 2013 02:46:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360896361!22571290!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIzOTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24708 invoked from network); 15 Feb 2013 02:46:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 02:46:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1F2jwQK012207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 02:45: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
	r1F2jv0d022144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 02:45:58 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1F2jvFQ029727; Thu, 14 Feb 2013 20:45:57 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 18:45:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1B1091C387B; Thu, 14 Feb 2013 21:45:56 -0500 (EST)
Date: Thu, 14 Feb 2013 21:45:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20130215024556.GA10506@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
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
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.8-rc7-tag-two
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Linus,

Please git pull one more tag (or if you haven't pulled the earlier one,
then just pull this one instead).


 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.8-rc7-tag-two

This has two reverts for patches added in the v3.8 time-frame. They introduced
a regression with the older hypervisors (Xen 4.1) so lets take these patches
out.

 arch/x86/xen/enlighten.c | 77 +++++++++++++++---------------------------------
 arch/x86/xen/suspend.c   |  2 +-
 arch/x86/xen/xen-ops.h   |  2 +-
 3 files changed, 25 insertions(+), 56 deletions(-)

Konrad Rzeszutek Wilk (2):
      Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info"
      Revert "xen PVonHVM: use E820_Reserved area for shared_info"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 02:46:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 02:46: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 1U6BJN-00079x-Sp; Fri, 15 Feb 2013 02:46:05 +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 1U6BJM-00079s-BX
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 02:46:04 +0000
Received: from [85.158.139.211:27429] by server-9.bemta-5.messagelabs.com id
	E1/7B-24440-B61AD115; Fri, 15 Feb 2013 02:46:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360896361!22571290!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIzOTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24708 invoked from network); 15 Feb 2013 02:46:02 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 02:46:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1F2jwQK012207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 02:45: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
	r1F2jv0d022144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 02:45:58 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1F2jvFQ029727; Thu, 14 Feb 2013 20:45:57 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 18:45:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1B1091C387B; Thu, 14 Feb 2013 21:45:56 -0500 (EST)
Date: Thu, 14 Feb 2013 21:45:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20130215024556.GA10506@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
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
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.8-rc7-tag-two
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Linus,

Please git pull one more tag (or if you haven't pulled the earlier one,
then just pull this one instead).


 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.8-rc7-tag-two

This has two reverts for patches added in the v3.8 time-frame. They introduced
a regression with the older hypervisors (Xen 4.1) so lets take these patches
out.

 arch/x86/xen/enlighten.c | 77 +++++++++++++++---------------------------------
 arch/x86/xen/suspend.c   |  2 +-
 arch/x86/xen/xen-ops.h   |  2 +-
 3 files changed, 25 insertions(+), 56 deletions(-)

Konrad Rzeszutek Wilk (2):
      Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info"
      Revert "xen PVonHVM: use E820_Reserved area for shared_info"


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 02:52:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 02: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 1U6BPV-0007JW-NP; Fri, 15 Feb 2013 02:52:25 +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 1U6BPU-0007JR-M3
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 02:52:24 +0000
Received: from [85.158.138.51:17199] by server-14.bemta-3.messagelabs.com id
	BF/72-23533-7E2AD115; Fri, 15 Feb 2013 02:52:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360896741!19708847!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIzOTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29772 invoked from network); 15 Feb 2013 02:52:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 02:52:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1F2qJAl016526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 02:52:19 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
	r1F2qIIv016428
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 02:52:19 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1F2qIZh032638; Thu, 14 Feb 2013 20:52:18 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 18:52:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5E21B1C387B; Thu, 14 Feb 2013 21:52:17 -0500 (EST)
Date: Thu, 14 Feb 2013 21:52:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130215025217.GC10506@phenom.dumpdata.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
	<20130214132318.GC2506@phenom.dumpdata.com>
	<511CFC93.9070205@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511CFC93.9070205@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 14, 2013 at 04:02:43PM +0100, Roger Pau Monn=E9 wrote:
> On 14/02/13 14:23, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 14, 2013 at 11:12:09AM +0100, Roger Pau Monne wrote:
> >> With current persistent grants implementation we are not freeing the
> >> persistent grants after we disconnect the device. Since grant map
> > =

> > Can you explain this in more details please? Isn't gnttab_set_unmap_op
> > in free_persistent_gnts doing the right job of putting in the right
> > mfn in? And then we could free the page?
> =

> No, after gnttab_unmap_refs the page still points to the grant frame
> mfn. All the users of grant frames either have an internal buffer of
> pages that are reused (like blkback), or use balloon pages (like gntdev).
> =

> I could probably modify gnttab_map to store the mfn and set it back at
> gnttab_unmap, but that will surely require more work than this simple fix.

Simple fix is what we want right now.
> =

> > =

> > =

> >> operations change the mfn of the allocated page, and we can no longer
> >> pass it to __free_page without setting the mfn to a sane value, use
> >> balloon grant pages instead, as the gntdev device does.
> > =

> > =

> > Wow. I did not realize that we leaving such a huge memory leak behind!
> > But I guess that was never an issue as we would recycle those persistent
> > grants to other domains.
> =

> No, we didn't recycle them AFAIK, we allocated them using alloc_page,
> passed them to gnttab_map, used them, and when closing the backend we
> only unmapped them, but they where never freed.

Ghastly!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 02:52:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 02: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 1U6BPV-0007JW-NP; Fri, 15 Feb 2013 02:52:25 +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 1U6BPU-0007JR-M3
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 02:52:24 +0000
Received: from [85.158.138.51:17199] by server-14.bemta-3.messagelabs.com id
	BF/72-23533-7E2AD115; Fri, 15 Feb 2013 02:52:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360896741!19708847!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjIzOTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29772 invoked from network); 15 Feb 2013 02:52:23 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 02:52:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1F2qJAl016526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 02:52:19 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
	r1F2qIIv016428
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 02:52:19 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1F2qIZh032638; Thu, 14 Feb 2013 20:52:18 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 14 Feb 2013 18:52:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5E21B1C387B; Thu, 14 Feb 2013 21:52:17 -0500 (EST)
Date: Thu, 14 Feb 2013 21:52:17 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130215025217.GC10506@phenom.dumpdata.com>
References: <1360836729-17874-1-git-send-email-roger.pau@citrix.com>
	<20130214132318.GC2506@phenom.dumpdata.com>
	<511CFC93.9070205@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511CFC93.9070205@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkback: use balloon pages for
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 14, 2013 at 04:02:43PM +0100, Roger Pau Monn=E9 wrote:
> On 14/02/13 14:23, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 14, 2013 at 11:12:09AM +0100, Roger Pau Monne wrote:
> >> With current persistent grants implementation we are not freeing the
> >> persistent grants after we disconnect the device. Since grant map
> > =

> > Can you explain this in more details please? Isn't gnttab_set_unmap_op
> > in free_persistent_gnts doing the right job of putting in the right
> > mfn in? And then we could free the page?
> =

> No, after gnttab_unmap_refs the page still points to the grant frame
> mfn. All the users of grant frames either have an internal buffer of
> pages that are reused (like blkback), or use balloon pages (like gntdev).
> =

> I could probably modify gnttab_map to store the mfn and set it back at
> gnttab_unmap, but that will surely require more work than this simple fix.

Simple fix is what we want right now.
> =

> > =

> > =

> >> operations change the mfn of the allocated page, and we can no longer
> >> pass it to __free_page without setting the mfn to a sane value, use
> >> balloon grant pages instead, as the gntdev device does.
> > =

> > =

> > Wow. I did not realize that we leaving such a huge memory leak behind!
> > But I guess that was never an issue as we would recycle those persistent
> > grants to other domains.
> =

> No, we didn't recycle them AFAIK, we allocated them using alloc_page,
> passed them to gnttab_map, used them, and when closing the backend we
> only unmapped them, but they where never freed.

Ghastly!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 07:56:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 07:56: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 1U6G8d-0001MV-Sb; Fri, 15 Feb 2013 07:55:19 +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 1U6G8c-0001MQ-Hy
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 07:55:18 +0000
Received: from [85.158.139.211:13524] by server-11.bemta-5.messagelabs.com id
	45/2D-19159-5E9ED115; Fri, 15 Feb 2013 07:55:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360914915!20943258!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5187 invoked from network); 15 Feb 2013 07:55:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 07:55:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 07:55:13 +0000
Message-Id: <511DF82A02000078000BE932@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 07:56:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Greg KH" <gregkh@linuxfoundation.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130214215216.GA18740@kroah.com>
In-Reply-To: <20130214215216.GA18740@kroah.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 22:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> Jan, any reason why this patch isn't in Linus's tree already,

I see Konrad answered that already, and with the embargo on the
CVE having expired only on Tuesday, I think it's not unreasonable
to not see this there yet.

> and why it
> wasn't marked for inclusion in a -stable kernel release?

Forgot to put the tag on when putting the patch together, and
then none of the reviewers noticed either. I'm sorry for that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 07:56:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 07:56: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 1U6G8d-0001MV-Sb; Fri, 15 Feb 2013 07:55:19 +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 1U6G8c-0001MQ-Hy
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 07:55:18 +0000
Received: from [85.158.139.211:13524] by server-11.bemta-5.messagelabs.com id
	45/2D-19159-5E9ED115; Fri, 15 Feb 2013 07:55:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360914915!20943258!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5187 invoked from network); 15 Feb 2013 07:55:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 07:55:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 07:55:13 +0000
Message-Id: <511DF82A02000078000BE932@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 07:56:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Greg KH" <gregkh@linuxfoundation.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130214215216.GA18740@kroah.com>
In-Reply-To: <20130214215216.GA18740@kroah.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 22:52, Greg KH <gregkh@linuxfoundation.org> wrote:
> Jan, any reason why this patch isn't in Linus's tree already,

I see Konrad answered that already, and with the embargo on the
CVE having expired only on Tuesday, I think it's not unreasonable
to not see this there yet.

> and why it
> wasn't marked for inclusion in a -stable kernel release?

Forgot to put the tag on when putting the patch together, and
then none of the reviewers noticed either. I'm sorry for that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:09:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:09: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 1U6GM6-00023G-MQ; Fri, 15 Feb 2013 08:09:14 +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 1U6GM4-000239-I1
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:09:12 +0000
Received: from [85.158.139.83:26055] by server-8.bemta-5.messagelabs.com id
	A4/72-19075-72DED115; Fri, 15 Feb 2013 08:09:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360915750!26716915!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15541 invoked from network); 15 Feb 2013 08:09:11 -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; 15 Feb 2013 08:09:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 08:09:10 +0000
Message-Id: <511DFB6F02000078000BE94E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 08:10:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
	<20130214165003.GR83752@ocelot.phlegethon.org>
	<511D276A02000078000BE73D@nat28.tlf.novell.com>
	<20130214171004.GS83752@ocelot.phlegethon.org>
In-Reply-To: <20130214171004.GS83752@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 14.02.13 at 18:10, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
> xen/xenoprof: avoid division by 0.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 5a84cc531072 xen/common/xenoprof.c
> --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> +++ b/xen/common/xenoprof.c	Thu Feb 14 17:07:41 2013 +0000
> @@ -193,6 +193,13 @@ static int alloc_xenoprof_struct(
>      unsigned max_max_samples;
>      int i;
>  
> +    nvcpu = 0;
> +    for_each_vcpu ( d, v )
> +        nvcpu++;
> +
> +    if ( !nvcpu )
> +        return -EINVAL;
> +
>      d->xenoprof = xzalloc(struct xenoprof);
>      if ( d->xenoprof == NULL )
>      {
> @@ -209,10 +216,6 @@ static int alloc_xenoprof_struct(
>          return -ENOMEM;
>      }
>  
> -    nvcpu = 0;
> -    for_each_vcpu ( d, v )
> -        nvcpu++;
> -
>      bufsize = sizeof(struct xenoprof_buf);
>      i = sizeof(struct event_log);
>  #ifdef CONFIG_COMPAT




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:09:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:09: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 1U6GM6-00023G-MQ; Fri, 15 Feb 2013 08:09:14 +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 1U6GM4-000239-I1
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:09:12 +0000
Received: from [85.158.139.83:26055] by server-8.bemta-5.messagelabs.com id
	A4/72-19075-72DED115; Fri, 15 Feb 2013 08:09:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360915750!26716915!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15541 invoked from network); 15 Feb 2013 08:09:11 -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; 15 Feb 2013 08:09:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 08:09:10 +0000
Message-Id: <511DFB6F02000078000BE94E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 08:10:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <68308aac7872c07631cb.1360858593@whitby.uk.xensource.com>
	<511D202E02000078000BE68A@nat28.tlf.novell.com>
	<20130214165003.GR83752@ocelot.phlegethon.org>
	<511D276A02000078000BE73D@nat28.tlf.novell.com>
	<20130214171004.GS83752@ocelot.phlegethon.org>
In-Reply-To: <20130214171004.GS83752@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 14.02.13 at 18:10, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
> xen/xenoprof: avoid division by 0.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 5a84cc531072 xen/common/xenoprof.c
> --- a/xen/common/xenoprof.c	Thu Feb 14 15:46:56 2013 +0000
> +++ b/xen/common/xenoprof.c	Thu Feb 14 17:07:41 2013 +0000
> @@ -193,6 +193,13 @@ static int alloc_xenoprof_struct(
>      unsigned max_max_samples;
>      int i;
>  
> +    nvcpu = 0;
> +    for_each_vcpu ( d, v )
> +        nvcpu++;
> +
> +    if ( !nvcpu )
> +        return -EINVAL;
> +
>      d->xenoprof = xzalloc(struct xenoprof);
>      if ( d->xenoprof == NULL )
>      {
> @@ -209,10 +216,6 @@ static int alloc_xenoprof_struct(
>          return -ENOMEM;
>      }
>  
> -    nvcpu = 0;
> -    for_each_vcpu ( d, v )
> -        nvcpu++;
> -
>      bufsize = sizeof(struct xenoprof_buf);
>      i = sizeof(struct event_log);
>  #ifdef CONFIG_COMPAT




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:20:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:20: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 1U6GWo-0002Oi-Tt; Fri, 15 Feb 2013 08:20:18 +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 1U6GWn-0002Od-Ko
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:20:17 +0000
Received: from [85.158.139.211:22952] by server-1.bemta-5.messagelabs.com id
	1A/F7-29263-0CFED115; Fri, 15 Feb 2013 08:20:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360916415!19809198!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12109 invoked from network); 15 Feb 2013 08:20:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 08:20:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 08:20:15 +0000
Message-Id: <511DFE0802000078000BE95D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 08:21:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
	<511CD8C202000078000BE280@nat28.tlf.novell.com>
	<511CFAD4.9040905@oracle.com>
In-Reply-To: <511CFAD4.9040905@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 14.02.13 at 15:55, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 02/14/2013 06:29 AM, Jan Beulich wrote:
>>>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>>> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
>>>
>>> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9 
>> This is really odd: The "iommu=debug" output you made available
>> shows that while there are further devices that have no associated
>> IOMMU, the bus scan done in the hypervisor didn't even find a
>> device at 06:00.1. Which I see possible only in two ways: Either
>> the device becomes visible on the bus only when the driver for
>> 06:00.0 loads (and is otherwise detectable only by other means,
>> e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
>> properly set. That latter aspect could be checked by looking at
>> the raw (hex) config space dump of 06:00.0.
> 
> If I read this correctly, Linux enables multi-functionness (?):
> 
> http://lxr.linux.no/#linux+v3.7.7/drivers/pci/quirks.c#L1494 
> 
> So you are probably right. BIOS does not enumerate 06:00.1 in IVRS because
> it doesn't see it enabled yet.

Indeed, and it has been that way since 2.6.18 (i.e. virtually
forever; commit 15e0c694367332d7e7114c7c73044bc5fed9ee48).

I've got a patch mostly ready to deal with non-zero functions
when we at least know something about function zero.

But I don't think we can easily deal with the single IOMMU
case, making that IOMMU cover all devices, as we would
still need to figure out the requestor ID for each device. That
requires looking at the PCI bus topology iiuc, and while we
have the necessary logic for VT-d, it seems not really strait
forward (mainly because risky) to make use of this in the AMD Vi
code too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:20:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:20: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 1U6GWo-0002Oi-Tt; Fri, 15 Feb 2013 08:20:18 +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 1U6GWn-0002Od-Ko
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:20:17 +0000
Received: from [85.158.139.211:22952] by server-1.bemta-5.messagelabs.com id
	1A/F7-29263-0CFED115; Fri, 15 Feb 2013 08:20:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1360916415!19809198!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12109 invoked from network); 15 Feb 2013 08:20:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 08:20:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 08:20:15 +0000
Message-Id: <511DFE0802000078000BE95D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 08:21:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<CACvNfPyb9FLGcRX4+TJgnQLV1G6TWyA7AeY3gyfhF0iFoEvhZg@mail.gmail.com>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
	<511CD8C202000078000BE280@nat28.tlf.novell.com>
	<511CFAD4.9040905@oracle.com>
In-Reply-To: <511CFAD4.9040905@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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

>>> On 14.02.13 at 15:55, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 02/14/2013 06:29 AM, Jan Beulich wrote:
>>>>> On 13.02.13 at 19:21, povder <povder@gmail.com> wrote:
>>> I don't see 06:00.1 device in IOMMU enabling process on which Xen crashes.
>>>
>>> lspci output: http://pastebin.com/raw.php?i=3wpKPQT9 
>> This is really odd: The "iommu=debug" output you made available
>> shows that while there are further devices that have no associated
>> IOMMU, the bus scan done in the hypervisor didn't even find a
>> device at 06:00.1. Which I see possible only in two ways: Either
>> the device becomes visible on the bus only when the driver for
>> 06:00.0 loads (and is otherwise detectable only by other means,
>> e.g. ACPI), or 06:00.0 doesn't have the multi function device flag
>> properly set. That latter aspect could be checked by looking at
>> the raw (hex) config space dump of 06:00.0.
> 
> If I read this correctly, Linux enables multi-functionness (?):
> 
> http://lxr.linux.no/#linux+v3.7.7/drivers/pci/quirks.c#L1494 
> 
> So you are probably right. BIOS does not enumerate 06:00.1 in IVRS because
> it doesn't see it enabled yet.

Indeed, and it has been that way since 2.6.18 (i.e. virtually
forever; commit 15e0c694367332d7e7114c7c73044bc5fed9ee48).

I've got a patch mostly ready to deal with non-zero functions
when we at least know something about function zero.

But I don't think we can easily deal with the single IOMMU
case, making that IOMMU cover all devices, as we would
still need to figure out the requestor ID for each device. That
requires looking at the PCI bus topology iiuc, and while we
have the necessary logic for VT-d, it seems not really strait
forward (mainly because risky) to make use of this in the AMD Vi
code too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:24:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08: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 1U6Gay-0002Yr-KC; Fri, 15 Feb 2013 08:24:36 +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 1U6Gax-0002Yk-7t
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:24:35 +0000
Received: from [85.158.143.35:39138] by server-2.bemta-4.messagelabs.com id
	40/46-01597-2C0FD115; Fri, 15 Feb 2013 08:24:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360916659!10203614!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13858 invoked from network); 15 Feb 2013 08:24:19 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 08:24:19 -0000
Received: by mail-wi0-f172.google.com with SMTP id ez12so820305wid.5
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 00:24:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GgeKMtRKL6M/cJ6NUek4+iS4gCu2a519Mb09yTjS0BE=;
	b=0wvZnIb12G3GLEqIAzABaiMiDIHdGva/9Xmj+pneKSV0cyQsFtYXXQNBUjp9qQSO6i
	zPZdQhTSZu5w5DvwMEQl5W0Tuw1RGLlF9xaPxDu33awgNOdhW4cB49Ruq2jClZZS4QTT
	GQjpajPDE2J7y0thKp/q1UmC0J/YLsdQOc4cxusAhWd6undMzAEvj9dkeOQk1sTknzhk
	RcIUqJX/iScxHpOCFnxx1O67dYiFvUy1x7BGqjSQi/erThUKssy3yvGFB9In8vPckpuB
	Sd/Ffr5x3m5QJfJnKqhTrroHSFUIH8fEThQ5D/Qpfzh74JwCSg44R4MwprjLruuajEdf
	faaw==
X-Received: by 10.181.13.175 with SMTP id ez15mr4309961wid.8.1360916659344;
	Fri, 15 Feb 2013 00:24:19 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id fg6sm3754512wib.10.2013.02.15.00.24.17
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 00:24:18 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 08:24:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD43A12F.4BF6F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 0
Thread-Index: Ac4LVdclUNVgbJfRQ0y/CqGvTNmNow==
In-Reply-To: <511DFB6F02000078000BE94E@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 15/02/2013 08:10, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 14.02.13 at 18:10, Tim Deegan <tim@xen.org> wrote:
>> # HG changeset patch
>> # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
>> xen/xenoprof: avoid division by 0.
>> 
>> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

>> diff -r 5a84cc531072 xen/common/xenoprof.c
>> --- a/xen/common/xenoprof.c Thu Feb 14 15:46:56 2013 +0000
>> +++ b/xen/common/xenoprof.c Thu Feb 14 17:07:41 2013 +0000
>> @@ -193,6 +193,13 @@ static int alloc_xenoprof_struct(
>>      unsigned max_max_samples;
>>      int i;
>>  
>> +    nvcpu = 0;
>> +    for_each_vcpu ( d, v )
>> +        nvcpu++;
>> +
>> +    if ( !nvcpu )
>> +        return -EINVAL;
>> +
>>      d->xenoprof = xzalloc(struct xenoprof);
>>      if ( d->xenoprof == NULL )
>>      {
>> @@ -209,10 +216,6 @@ static int alloc_xenoprof_struct(
>>          return -ENOMEM;
>>      }
>>  
>> -    nvcpu = 0;
>> -    for_each_vcpu ( d, v )
>> -        nvcpu++;
>> -
>>      bufsize = sizeof(struct xenoprof_buf);
>>      i = sizeof(struct event_log);
>>  #ifdef CONFIG_COMPAT
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 15 08:24:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08: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 1U6Gay-0002Yr-KC; Fri, 15 Feb 2013 08:24:36 +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 1U6Gax-0002Yk-7t
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:24:35 +0000
Received: from [85.158.143.35:39138] by server-2.bemta-4.messagelabs.com id
	40/46-01597-2C0FD115; Fri, 15 Feb 2013 08:24:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360916659!10203614!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13858 invoked from network); 15 Feb 2013 08:24:19 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 08:24:19 -0000
Received: by mail-wi0-f172.google.com with SMTP id ez12so820305wid.5
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 00:24:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GgeKMtRKL6M/cJ6NUek4+iS4gCu2a519Mb09yTjS0BE=;
	b=0wvZnIb12G3GLEqIAzABaiMiDIHdGva/9Xmj+pneKSV0cyQsFtYXXQNBUjp9qQSO6i
	zPZdQhTSZu5w5DvwMEQl5W0Tuw1RGLlF9xaPxDu33awgNOdhW4cB49Ruq2jClZZS4QTT
	GQjpajPDE2J7y0thKp/q1UmC0J/YLsdQOc4cxusAhWd6undMzAEvj9dkeOQk1sTknzhk
	RcIUqJX/iScxHpOCFnxx1O67dYiFvUy1x7BGqjSQi/erThUKssy3yvGFB9In8vPckpuB
	Sd/Ffr5x3m5QJfJnKqhTrroHSFUIH8fEThQ5D/Qpfzh74JwCSg44R4MwprjLruuajEdf
	faaw==
X-Received: by 10.181.13.175 with SMTP id ez15mr4309961wid.8.1360916659344;
	Fri, 15 Feb 2013 00:24:19 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id fg6sm3754512wib.10.2013.02.15.00.24.17
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 00:24:18 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 08:24:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD43A12F.4BF6F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 0
Thread-Index: Ac4LVdclUNVgbJfRQ0y/CqGvTNmNow==
In-Reply-To: <511DFB6F02000078000BE94E@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/xenoprof: avoid division by 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 15/02/2013 08:10, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 14.02.13 at 18:10, Tim Deegan <tim@xen.org> wrote:
>> # HG changeset patch
>> # Parent 5a84cc531072378e6e5ff89b4c0e9a35000dc56f
>> xen/xenoprof: avoid division by 0.
>> 
>> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

>> diff -r 5a84cc531072 xen/common/xenoprof.c
>> --- a/xen/common/xenoprof.c Thu Feb 14 15:46:56 2013 +0000
>> +++ b/xen/common/xenoprof.c Thu Feb 14 17:07:41 2013 +0000
>> @@ -193,6 +193,13 @@ static int alloc_xenoprof_struct(
>>      unsigned max_max_samples;
>>      int i;
>>  
>> +    nvcpu = 0;
>> +    for_each_vcpu ( d, v )
>> +        nvcpu++;
>> +
>> +    if ( !nvcpu )
>> +        return -EINVAL;
>> +
>>      d->xenoprof = xzalloc(struct xenoprof);
>>      if ( d->xenoprof == NULL )
>>      {
>> @@ -209,10 +216,6 @@ static int alloc_xenoprof_struct(
>>          return -ENOMEM;
>>      }
>>  
>> -    nvcpu = 0;
>> -    for_each_vcpu ( d, v )
>> -        nvcpu++;
>> -
>>      bufsize = sizeof(struct xenoprof_buf);
>>      i = sizeof(struct event_log);
>>  #ifdef CONFIG_COMPAT
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 15 08:41:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:41: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 1U6Gr4-0002mT-91; Fri, 15 Feb 2013 08:41:14 +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 1U6Gr2-0002mO-MU
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:41:12 +0000
Received: from [85.158.139.83:15052] by server-11.bemta-5.messagelabs.com id
	5A/BE-19159-8A4FD115; Fri, 15 Feb 2013 08:41:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360917671!23530713!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18253 invoked from network); 15 Feb 2013 08:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 08:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; 
   d="scan'208";a="1500973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 08:41: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.297.1;
	Fri, 15 Feb 2013 08:41:10 +0000
Message-ID: <1360917669.25448.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 08:41:09 +0000
In-Reply-To: <1360748602-9357-1-git-send-email-ian.campbell@citrix.com>
References: <1360748602-9357-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
	full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can I get an ACK or NACK for this please, we really should update XSA-38
ASAP...

On Wed, 2013-02-13 at 09:43 +0000, Ian Campbell wrote:
> Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
> caused us to ignore rather than process a completely full ring. Check if
> producer and consumer are equal before masking to avoid this, since prod ==
> cons + PAGE_SIZE after masking becomes prod == cons.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
> index 4888ac5..fdd9983 100644
> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
> @@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
>  	cons = *(volatile uint32*)&intf->req_cons;
>  	prod = *(volatile uint32*)&intf->req_prod;
>  	xen_mb();
> -	cons = MASK_XENSTORE_IDX(cons);
> -	prod = MASK_XENSTORE_IDX(prod);
>  	if (prod == cons)
>  		return 0;
> +	cons = MASK_XENSTORE_IDX(cons);
> +	prod = MASK_XENSTORE_IDX(prod);
>  	if (prod > cons)
>  		to_read = prod - cons;
>  	else



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:41:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:41: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 1U6Gr4-0002mT-91; Fri, 15 Feb 2013 08:41:14 +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 1U6Gr2-0002mO-MU
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:41:12 +0000
Received: from [85.158.139.83:15052] by server-11.bemta-5.messagelabs.com id
	5A/BE-19159-8A4FD115; Fri, 15 Feb 2013 08:41:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360917671!23530713!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18253 invoked from network); 15 Feb 2013 08:41:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 08:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; 
   d="scan'208";a="1500973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 08:41: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.297.1;
	Fri, 15 Feb 2013 08:41:10 +0000
Message-ID: <1360917669.25448.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 08:41:09 +0000
In-Reply-To: <1360748602-9357-1-git-send-email-ian.campbell@citrix.com>
References: <1360748602-9357-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
	full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can I get an ACK or NACK for this please, we really should update XSA-38
ASAP...

On Wed, 2013-02-13 at 09:43 +0000, Ian Campbell wrote:
> Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
> caused us to ignore rather than process a completely full ring. Check if
> producer and consumer are equal before masking to avoid this, since prod ==
> cons + PAGE_SIZE after masking becomes prod == cons.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c b/tools/ocaml/libs/xb/xs_ring_stubs.c
> index 4888ac5..fdd9983 100644
> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
> @@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
>  	cons = *(volatile uint32*)&intf->req_cons;
>  	prod = *(volatile uint32*)&intf->req_prod;
>  	xen_mb();
> -	cons = MASK_XENSTORE_IDX(cons);
> -	prod = MASK_XENSTORE_IDX(prod);
>  	if (prod == cons)
>  		return 0;
> +	cons = MASK_XENSTORE_IDX(cons);
> +	prod = MASK_XENSTORE_IDX(prod);
>  	if (prod > cons)
>  		to_read = prod - cons;
>  	else



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:45:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:45: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 1U6Gux-0002vC-1X; Fri, 15 Feb 2013 08:45: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 1U6Guw-0002v7-CP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:45:14 +0000
Received: from [193.109.254.147:10809] by server-2.bemta-14.messagelabs.com id
	B0/47-16277-995FD115; Fri, 15 Feb 2013 08:45:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360917912!8504113!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27446 invoked from network); 15 Feb 2013 08:45:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 08:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; 
   d="scan'208";a="1501161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 08:45: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.297.1;
	Fri, 15 Feb 2013 08:45:12 +0000
Message-ID: <1360917911.25448.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Fri, 15 Feb 2013 08:45:11 +0000
In-Reply-To: <511D5DDF.7040000@theshore.net>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<511D5DDF.7040000@theshore.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	"Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] xen-netback: fix oopes during shutdown and error
 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 Thu, 2013-02-14 at 21:57 +0000, Christopher S. Aker wrote:
> On 2/14/13 8:18 AM, David Vrabel wrote:
> > These two netback patches fix oopes that may occur during shutdown or
> > if a specific fatal error occurs.
> 
> On 2/14/13 11:39 AM, Ian Campbell wrote:
> > Although I would like to add a Tested-by: Christopher too if
> > possible.
> 
> Tested-by: Christopher S. Aker <caker@theshore.net> (and team)

Thank you!

> We are no longer able to trigger the last OOPs we provided by downing 
> the vif.  Further testing of the other issues will take time, but we're 
> deploying a few patched hosts now.

Great, please let me know how you get on.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 08:45:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 08:45: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 1U6Gux-0002vC-1X; Fri, 15 Feb 2013 08:45: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 1U6Guw-0002v7-CP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 08:45:14 +0000
Received: from [193.109.254.147:10809] by server-2.bemta-14.messagelabs.com id
	B0/47-16277-995FD115; Fri, 15 Feb 2013 08:45:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360917912!8504113!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27446 invoked from network); 15 Feb 2013 08:45:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 08:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; 
   d="scan'208";a="1501161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 08:45: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.297.1;
	Fri, 15 Feb 2013 08:45:12 +0000
Message-ID: <1360917911.25448.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Christopher S. Aker" <caker@theshore.net>
Date: Fri, 15 Feb 2013 08:45:11 +0000
In-Reply-To: <511D5DDF.7040000@theshore.net>
References: <1360847938-11185-1-git-send-email-david.vrabel@citrix.com>
	<511D5DDF.7040000@theshore.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	"Wei Liu \(3P\)" <wei.liu@citrix.com>
Subject: Re: [Xen-devel] xen-netback: fix oopes during shutdown and error
 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 Thu, 2013-02-14 at 21:57 +0000, Christopher S. Aker wrote:
> On 2/14/13 8:18 AM, David Vrabel wrote:
> > These two netback patches fix oopes that may occur during shutdown or
> > if a specific fatal error occurs.
> 
> On 2/14/13 11:39 AM, Ian Campbell wrote:
> > Although I would like to add a Tested-by: Christopher too if
> > possible.
> 
> Tested-by: Christopher S. Aker <caker@theshore.net> (and team)

Thank you!

> We are no longer able to trigger the last OOPs we provided by downing 
> the vif.  Further testing of the other issues will take time, but we're 
> deploying a few patched hosts now.

Great, please let me know how you get on.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 09:02:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6HBd-0003Ee-At; Fri, 15 Feb 2013 09:02:29 +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 1U6HBb-0003EZ-KT
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:02:27 +0000
Received: from [85.158.139.211:37982] by server-13.bemta-5.messagelabs.com id
	A9/58-06769-2A9FD115; Fri, 15 Feb 2013 09:02:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360918946!22480131!1
X-Originating-IP: [74.125.82.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32737 invoked from network); 15 Feb 2013 09:02:26 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 09:02:26 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so2634632wey.26
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 01:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=imNxc6PYulugsg2o2w4xF9Glfk/2At6oGZrJftYqDDg=;
	b=TOXpa+GYrysQmUGY6p8mGx4C2u5WGcdurXK9KvM0v9KgzPD9ahF3w3gXv+BU4WNvAC
	zjX9VuEP5w/FhqERvl1fmRkmXG7aKrhCYWTG1UgrofAH9LLE0CyVpuRz4SLI1SrLYelR
	8OH2gc1i4Fd07rcHjXwJaOypkeBl+NsmBI1V2QbHi6/VHMEk6876iOWDwg0i3EKu37Hq
	426e/oH9P11PTiY7jSLDVTmn//Ml6pBwNqzf6f1ldbKf1GJjD5mwbvhDItqQgRezpbG5
	PcESvQIwE8/ccRG3g0bFhr4YbuNp5I9GZjZ8dsXVtM5gi6dp6eFGAmm93g0hPm4kth6y
	nxsw==
X-Received: by 10.194.109.10 with SMTP id ho10mr2732526wjb.16.1360918946020;
	Fri, 15 Feb 2013 01:02:26 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id gy2sm3968778wib.3.2013.02.15.01.02.23
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 01:02:25 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 09:02:19 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD43AA1B.5B046%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
	full ring.
Thread-Index: Ac4LWyiEYtIn0aChxUODzdJWJl6VvA==
In-Reply-To: <1360917669.25448.6.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Who are you looking for an Ack from? The patch makes pefect sense to me so
you can have mine if you want it.

Acked-by: Keir Fraser <keir@xen.org>


On 15/02/2013 08:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> Can I get an ACK or NACK for this please, we really should update XSA-38
> ASAP...
> 
> On Wed, 2013-02-13 at 09:43 +0000, Ian Campbell wrote:
>> Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
>> caused us to ignore rather than process a completely full ring. Check if
>> producer and consumer are equal before masking to avoid this, since prod ==
>> cons + PAGE_SIZE after masking becomes prod == cons.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> ---
>>  tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c
>> b/tools/ocaml/libs/xb/xs_ring_stubs.c
>> index 4888ac5..fdd9983 100644
>> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
>> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
>> @@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
>> cons = *(volatile uint32*)&intf->req_cons;
>> prod = *(volatile uint32*)&intf->req_prod;
>> xen_mb();
>> - cons = MASK_XENSTORE_IDX(cons);
>> - prod = MASK_XENSTORE_IDX(prod);
>> if (prod == cons)
>> return 0;
>> + cons = MASK_XENSTORE_IDX(cons);
>> + prod = MASK_XENSTORE_IDX(prod);
>> if (prod > cons)
>> to_read = prod - cons;
>> 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 Fri Feb 15 09:02:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6HBd-0003Ee-At; Fri, 15 Feb 2013 09:02:29 +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 1U6HBb-0003EZ-KT
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:02:27 +0000
Received: from [85.158.139.211:37982] by server-13.bemta-5.messagelabs.com id
	A9/58-06769-2A9FD115; Fri, 15 Feb 2013 09:02:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360918946!22480131!1
X-Originating-IP: [74.125.82.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32737 invoked from network); 15 Feb 2013 09:02:26 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 09:02:26 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so2634632wey.26
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 01:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=imNxc6PYulugsg2o2w4xF9Glfk/2At6oGZrJftYqDDg=;
	b=TOXpa+GYrysQmUGY6p8mGx4C2u5WGcdurXK9KvM0v9KgzPD9ahF3w3gXv+BU4WNvAC
	zjX9VuEP5w/FhqERvl1fmRkmXG7aKrhCYWTG1UgrofAH9LLE0CyVpuRz4SLI1SrLYelR
	8OH2gc1i4Fd07rcHjXwJaOypkeBl+NsmBI1V2QbHi6/VHMEk6876iOWDwg0i3EKu37Hq
	426e/oH9P11PTiY7jSLDVTmn//Ml6pBwNqzf6f1ldbKf1GJjD5mwbvhDItqQgRezpbG5
	PcESvQIwE8/ccRG3g0bFhr4YbuNp5I9GZjZ8dsXVtM5gi6dp6eFGAmm93g0hPm4kth6y
	nxsw==
X-Received: by 10.194.109.10 with SMTP id ho10mr2732526wjb.16.1360918946020;
	Fri, 15 Feb 2013 01:02:26 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id gy2sm3968778wib.3.2013.02.15.01.02.23
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 01:02:25 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 09:02:19 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD43AA1B.5B046%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
	full ring.
Thread-Index: Ac4LWyiEYtIn0aChxUODzdJWJl6VvA==
In-Reply-To: <1360917669.25448.6.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Who are you looking for an Ack from? The patch makes pefect sense to me so
you can have mine if you want it.

Acked-by: Keir Fraser <keir@xen.org>


On 15/02/2013 08:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> Can I get an ACK or NACK for this please, we really should update XSA-38
> ASAP...
> 
> On Wed, 2013-02-13 at 09:43 +0000, Ian Campbell wrote:
>> Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
>> caused us to ignore rather than process a completely full ring. Check if
>> producer and consumer are equal before masking to avoid this, since prod ==
>> cons + PAGE_SIZE after masking becomes prod == cons.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> ---
>>  tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c
>> b/tools/ocaml/libs/xb/xs_ring_stubs.c
>> index 4888ac5..fdd9983 100644
>> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
>> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
>> @@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
>> cons = *(volatile uint32*)&intf->req_cons;
>> prod = *(volatile uint32*)&intf->req_prod;
>> xen_mb();
>> - cons = MASK_XENSTORE_IDX(cons);
>> - prod = MASK_XENSTORE_IDX(prod);
>> if (prod == cons)
>> return 0;
>> + cons = MASK_XENSTORE_IDX(cons);
>> + prod = MASK_XENSTORE_IDX(prod);
>> if (prod > cons)
>> to_read = prod - cons;
>> 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 Fri Feb 15 09:11:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 09:11: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 1U6HK4-0003Ol-CA; Fri, 15 Feb 2013 09:11: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 1U6HK3-0003Og-FR
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:11:11 +0000
Received: from [85.158.138.51:26128] by server-15.bemta-3.messagelabs.com id
	D9/17-25405-EABFD115; Fri, 15 Feb 2013 09:11:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360919468!19741108!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29766 invoked from network); 15 Feb 2013 09:11:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 09:11:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; 
   d="scan'208";a="1502323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 09:11: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.297.1;
	Fri, 15 Feb 2013 09:11:03 +0000
Message-ID: <1360919461.31407.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Fri, 15 Feb 2013 09:11:01 +0000
In-Reply-To: <CD43AA1B.5B046%keir@xen.org>
References: <CD43AA1B.5B046%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

You'll do :-P

On Fri, 2013-02-15 at 09:02 +0000, Keir Fraser wrote:
> Who are you looking for an Ack from? The patch makes pefect sense to me so
> you can have mine if you want it.
> 
> Acked-by: Keir Fraser <keir@xen.org>
> 
> 
> On 15/02/2013 08:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > Can I get an ACK or NACK for this please, we really should update XSA-38
> > ASAP...
> > 
> > On Wed, 2013-02-13 at 09:43 +0000, Ian Campbell wrote:
> >> Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
> >> caused us to ignore rather than process a completely full ring. Check if
> >> producer and consumer are equal before masking to avoid this, since prod ==
> >> cons + PAGE_SIZE after masking becomes prod == cons.
> >> 
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> ---
> >>  tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
> >>  1 files changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> b/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> index 4888ac5..fdd9983 100644
> >> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> @@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
> >> cons = *(volatile uint32*)&intf->req_cons;
> >> prod = *(volatile uint32*)&intf->req_prod;
> >> xen_mb();
> >> - cons = MASK_XENSTORE_IDX(cons);
> >> - prod = MASK_XENSTORE_IDX(prod);
> >> if (prod == cons)
> >> return 0;
> >> + cons = MASK_XENSTORE_IDX(cons);
> >> + prod = MASK_XENSTORE_IDX(prod);
> >> if (prod > cons)
> >> to_read = prod - cons;
> >> 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 Fri Feb 15 09:11:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 09:11: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 1U6HK4-0003Ol-CA; Fri, 15 Feb 2013 09:11: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 1U6HK3-0003Og-FR
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:11:11 +0000
Received: from [85.158.138.51:26128] by server-15.bemta-3.messagelabs.com id
	D9/17-25405-EABFD115; Fri, 15 Feb 2013 09:11:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360919468!19741108!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjgz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29766 invoked from network); 15 Feb 2013 09:11:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 09:11:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,671,1355097600"; 
   d="scan'208";a="1502323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 09:11: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.297.1;
	Fri, 15 Feb 2013 09:11:03 +0000
Message-ID: <1360919461.31407.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Fri, 15 Feb 2013 09:11:01 +0000
In-Reply-To: <CD43AA1B.5B046%keir@xen.org>
References: <CD43AA1B.5B046%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

You'll do :-P

On Fri, 2013-02-15 at 09:02 +0000, Keir Fraser wrote:
> Who are you looking for an Ack from? The patch makes pefect sense to me so
> you can have mine if you want it.
> 
> Acked-by: Keir Fraser <keir@xen.org>
> 
> 
> On 15/02/2013 08:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > Can I get an ACK or NACK for this please, we really should update XSA-38
> > ASAP...
> > 
> > On Wed, 2013-02-13 at 09:43 +0000, Ian Campbell wrote:
> >> Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly
> >> caused us to ignore rather than process a completely full ring. Check if
> >> producer and consumer are equal before masking to avoid this, since prod ==
> >> cons + PAGE_SIZE after masking becomes prod == cons.
> >> 
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> ---
> >>  tools/ocaml/libs/xb/xs_ring_stubs.c |    4 ++--
> >>  1 files changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> b/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> index 4888ac5..fdd9983 100644
> >> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
> >> @@ -45,10 +45,10 @@ static int xs_ring_read(struct mmap_interface *interface,
> >> cons = *(volatile uint32*)&intf->req_cons;
> >> prod = *(volatile uint32*)&intf->req_prod;
> >> xen_mb();
> >> - cons = MASK_XENSTORE_IDX(cons);
> >> - prod = MASK_XENSTORE_IDX(prod);
> >> if (prod == cons)
> >> return 0;
> >> + cons = MASK_XENSTORE_IDX(cons);
> >> + prod = MASK_XENSTORE_IDX(prod);
> >> if (prod > cons)
> >> to_read = prod - cons;
> >> 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 Fri Feb 15 09:19:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 09:19: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 1U6HRR-0003YZ-BQ; Fri, 15 Feb 2013 09:18:49 +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 1U6HRP-0003YU-GM
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:18:47 +0000
Received: from [85.158.139.83:13805] by server-11.bemta-5.messagelabs.com id
	80/D4-19159-67DFD115; Fri, 15 Feb 2013 09:18:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360919925!27686117!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3467 invoked from network); 15 Feb 2013 09:18:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 09:18:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 09:18:44 +0000
Message-Id: <511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 09:19:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
In-Reply-To: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrote:
> On a machine that could not cover all its RAM with MTRR ranges,
> a crash on boot as dom0 was caused by dom0 trying to create
> kernel mapping tables for the clipped range.
> 
> (XEN) WARNING: MTRRs do not cover all of memory.
> (XEN) Truncating RAM from 9109504kB to 9043968kB
> ...
> (XEN)  0000000228000000 - 000000022c000000 (unusable)
> ...
> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
> [    0.000000]  0228000000 - 022c000000 page 4k
> [    0.000000] kernel direct mapping tables up to 22c000000 @
>                1e97d8000-1e97fa000
> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
> 
> Setting the range in E820 to E280_UNUSABLE seems ambigous as
> this is the same type that gets used for memory to be used only
> as guest memory (using dom0_mem=).

Since when is E820_UNUSABLE memory being used as guest
memory? If that's indeed the case, that's the bug to fix. The
above data to me shows, however, that the range above
228000000 is considered invalid. So then the question is why the
kernel tries to map that memory in the first place (the hypervisor
rejecting the attempt, despite Dom0 being privileged, seems
correct to me, as the range is also known not to be MMIO).

> To avoid this, the clipped memory should be dropped completely
> from E820 (as it is done if setting the memory type fails).
> This is currently restricted to only the case of memory not
> coverable by MTRRs (which could be tested). Maybe it should
> be done in other cases, too.

No, that's wrong. When dropping the range completely, the
Dom0 kernel then could allocate MMIO resources in that address
range, and the devices using those MMIO resources then would
not work.

Bottom line - I think this needs to be fixed in the kernel.

Jan

> BugLink: http://bugs.launchpad.net/bugs/1111470 
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/arch/x86/e820.c |   13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> index 55fe0d6..8dfe427 100644
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -372,7 +372,7 @@ static unsigned long __init find_max_pfn(void)
>      return max_pfn;
>  }
>  
> -static void __init clip_to_limit(uint64_t limit, char *warnmsg)
> +static void __init clip_to_limit(uint64_t limit, char *warnmsg, int drop)
>  {
>      int i;
>      char _warnmsg[160];
> @@ -394,7 +394,8 @@ static void __init clip_to_limit(uint64_t limit, char 
> *warnmsg)
>              uint64_t, old_limit, e820.map[i].addr + e820.map[i].size);
>  
>          /* We try to convert clipped RAM areas to E820_UNUSABLE. */
> -        if ( e820_change_range_type(&e820, max(e820.map[i].addr, limit),
> +        if ( !drop &&
> +             e820_change_range_type(&e820, max(e820.map[i].addr, limit),
>                                      e820.map[i].addr + e820.map[i].size,
>                                      E820_RAM, E820_UNUSABLE) )
>              continue;
> @@ -524,7 +525,7 @@ static void __init machine_specific_memory_setup(
>      (void)copy_e820_map(raw, nr);
>  
>      if ( opt_mem )
> -        clip_to_limit(opt_mem, NULL);
> +        clip_to_limit(opt_mem, NULL, 0);
>  
>      if ( opt_availmem )
>      {
> @@ -534,7 +535,7 @@ static void __init machine_specific_memory_setup(
>          if ( size > opt_availmem )
>              clip_to_limit(
>                  e820.map[i-1].addr + e820.map[i-1].size - (size-opt_availmem),
> -                NULL);
> +                NULL, 0);
>      }
>  
>      mpt_limit = ((RDWR_MPT_VIRT_END - RDWR_MPT_VIRT_START)
> @@ -545,13 +546,13 @@ static void __init machine_specific_memory_setup(
>          mpt_limit = ro_mpt_limit;
>      clip_to_limit(mpt_limit,
>                    "Only the first %lu GB of the physical "
> -                  "memory map can be accessed by Xen.");
> +                  "memory map can be accessed by Xen.", 0);
>  
>      reserve_dmi_region();
>  
>      top_of_ram = mtrr_top_of_ram();
>      if ( top_of_ram )
> -        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.");
> +        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.", 1);
>  }
>  
>  /* This function relies on the passed in e820->map[] being sorted. */
> -- 
> 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 Fri Feb 15 09:19:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 09:19: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 1U6HRR-0003YZ-BQ; Fri, 15 Feb 2013 09:18:49 +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 1U6HRP-0003YU-GM
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:18:47 +0000
Received: from [85.158.139.83:13805] by server-11.bemta-5.messagelabs.com id
	80/D4-19159-67DFD115; Fri, 15 Feb 2013 09:18:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360919925!27686117!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3467 invoked from network); 15 Feb 2013 09:18:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 09:18:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 09:18:44 +0000
Message-Id: <511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 09:19:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
In-Reply-To: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrote:
> On a machine that could not cover all its RAM with MTRR ranges,
> a crash on boot as dom0 was caused by dom0 trying to create
> kernel mapping tables for the clipped range.
> 
> (XEN) WARNING: MTRRs do not cover all of memory.
> (XEN) Truncating RAM from 9109504kB to 9043968kB
> ...
> (XEN)  0000000228000000 - 000000022c000000 (unusable)
> ...
> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
> [    0.000000]  0228000000 - 022c000000 page 4k
> [    0.000000] kernel direct mapping tables up to 22c000000 @
>                1e97d8000-1e97fa000
> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
> 
> Setting the range in E820 to E280_UNUSABLE seems ambigous as
> this is the same type that gets used for memory to be used only
> as guest memory (using dom0_mem=).

Since when is E820_UNUSABLE memory being used as guest
memory? If that's indeed the case, that's the bug to fix. The
above data to me shows, however, that the range above
228000000 is considered invalid. So then the question is why the
kernel tries to map that memory in the first place (the hypervisor
rejecting the attempt, despite Dom0 being privileged, seems
correct to me, as the range is also known not to be MMIO).

> To avoid this, the clipped memory should be dropped completely
> from E820 (as it is done if setting the memory type fails).
> This is currently restricted to only the case of memory not
> coverable by MTRRs (which could be tested). Maybe it should
> be done in other cases, too.

No, that's wrong. When dropping the range completely, the
Dom0 kernel then could allocate MMIO resources in that address
range, and the devices using those MMIO resources then would
not work.

Bottom line - I think this needs to be fixed in the kernel.

Jan

> BugLink: http://bugs.launchpad.net/bugs/1111470 
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  xen/arch/x86/e820.c |   13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> index 55fe0d6..8dfe427 100644
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -372,7 +372,7 @@ static unsigned long __init find_max_pfn(void)
>      return max_pfn;
>  }
>  
> -static void __init clip_to_limit(uint64_t limit, char *warnmsg)
> +static void __init clip_to_limit(uint64_t limit, char *warnmsg, int drop)
>  {
>      int i;
>      char _warnmsg[160];
> @@ -394,7 +394,8 @@ static void __init clip_to_limit(uint64_t limit, char 
> *warnmsg)
>              uint64_t, old_limit, e820.map[i].addr + e820.map[i].size);
>  
>          /* We try to convert clipped RAM areas to E820_UNUSABLE. */
> -        if ( e820_change_range_type(&e820, max(e820.map[i].addr, limit),
> +        if ( !drop &&
> +             e820_change_range_type(&e820, max(e820.map[i].addr, limit),
>                                      e820.map[i].addr + e820.map[i].size,
>                                      E820_RAM, E820_UNUSABLE) )
>              continue;
> @@ -524,7 +525,7 @@ static void __init machine_specific_memory_setup(
>      (void)copy_e820_map(raw, nr);
>  
>      if ( opt_mem )
> -        clip_to_limit(opt_mem, NULL);
> +        clip_to_limit(opt_mem, NULL, 0);
>  
>      if ( opt_availmem )
>      {
> @@ -534,7 +535,7 @@ static void __init machine_specific_memory_setup(
>          if ( size > opt_availmem )
>              clip_to_limit(
>                  e820.map[i-1].addr + e820.map[i-1].size - (size-opt_availmem),
> -                NULL);
> +                NULL, 0);
>      }
>  
>      mpt_limit = ((RDWR_MPT_VIRT_END - RDWR_MPT_VIRT_START)
> @@ -545,13 +546,13 @@ static void __init machine_specific_memory_setup(
>          mpt_limit = ro_mpt_limit;
>      clip_to_limit(mpt_limit,
>                    "Only the first %lu GB of the physical "
> -                  "memory map can be accessed by Xen.");
> +                  "memory map can be accessed by Xen.", 0);
>  
>      reserve_dmi_region();
>  
>      top_of_ram = mtrr_top_of_ram();
>      if ( top_of_ram )
> -        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.");
> +        clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.", 1);
>  }
>  
>  /* This function relies on the passed in e820->map[] being sorted. */
> -- 
> 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 Fri Feb 15 09:26:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 09:26: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 1U6HYu-0003j0-9r; Fri, 15 Feb 2013 09:26: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 1U6HYs-0003iv-Ho
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:26:30 +0000
Received: from [85.158.138.51:43938] by server-13.bemta-3.messagelabs.com id
	CE/F9-20653-54FFD115; Fri, 15 Feb 2013 09:26:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360920380!19647644!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18113 invoked from network); 15 Feb 2013 09:26:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 09:26:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,672,1355097600"; 
   d="scan'208";a="1503041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 09:26: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.297.1;
	Fri, 15 Feb 2013 09:26:19 +0000
Message-ID: <1360920378.31407.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>
Date: Fri, 15 Feb 2013 09:26:18 +0000
In-Reply-To: <1360919461.31407.7.camel@zakaz.uk.xensource.com>
References: <CD43AA1B.5B046%keir@xen.org>
	<1360919461.31407.7.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 09:02 +0000, Keir Fraser wrote:
> > Who are you looking for an Ack from? The patch makes pefect sense to me so
> > you can have mine if you want it.
> > 
> > Acked-by: Keir Fraser <keir@xen.org>

Committed, thanks.

Ian: Can you backport 26539:759574df84a6 to everywhere the original
patches went please.

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 Feb 15 09:26:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 09:26: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 1U6HYu-0003j0-9r; Fri, 15 Feb 2013 09:26: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 1U6HYs-0003iv-Ho
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 09:26:30 +0000
Received: from [85.158.138.51:43938] by server-13.bemta-3.messagelabs.com id
	CE/F9-20653-54FFD115; Fri, 15 Feb 2013 09:26:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360920380!19647644!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18113 invoked from network); 15 Feb 2013 09:26:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 09:26:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,672,1355097600"; 
   d="scan'208";a="1503041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 09:26: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.297.1;
	Fri, 15 Feb 2013 09:26:19 +0000
Message-ID: <1360920378.31407.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>
Date: Fri, 15 Feb 2013 09:26:18 +0000
In-Reply-To: <1360919461.31407.7.camel@zakaz.uk.xensource.com>
References: <CD43AA1B.5B046%keir@xen.org>
	<1360919461.31407.7.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 09:02 +0000, Keir Fraser wrote:
> > Who are you looking for an Ack from? The patch makes pefect sense to me so
> > you can have mine if you want it.
> > 
> > Acked-by: Keir Fraser <keir@xen.org>

Committed, thanks.

Ian: Can you backport 26539:759574df84a6 to everywhere the original
patches went please.

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 Feb 15 10:16:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 10: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 1U6IKN-00048P-BD; Fri, 15 Feb 2013 10:15:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1U6IKM-00048K-G2
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 10:15:34 +0000
Received: from [85.158.138.51:17809] by server-12.bemta-3.messagelabs.com id
	2E/C7-05889-5CA0E115; Fri, 15 Feb 2013 10:15:33 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360923332!27657140!1
X-Originating-IP: [74.125.83.53]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6877 invoked from network); 15 Feb 2013 10:15:32 -0000
Received: from mail-ee0-f53.google.com (HELO mail-ee0-f53.google.com)
	(74.125.83.53)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 10:15:32 -0000
Received: by mail-ee0-f53.google.com with SMTP id e53so1751723eek.40
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 02:15:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=eY7DxtXR+Z9jc1ybaXN8ef/MQHNcortt5oaXGNDJCVc=;
	b=DTfC+t/b6xOExzLgua6xWUfTWblxQevs2/Rb3X3Xyt9GY4OcJ282xuvGTvsPjVTZtE
	5N0LVYMjjWrgtoKSGucv2MHwZujFav6sg0nl19rpycO20Ch8ycwWhy/6h+sHjRjA636o
	NZ11rp300G+wYdt4oBU03ORQ7EOM6TnwDP/0g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=eY7DxtXR+Z9jc1ybaXN8ef/MQHNcortt5oaXGNDJCVc=;
	b=NIyza0EDR+GrH1b5rWy31lgIQza0NNljiFOI6rkj25hou5Csa5+0gr5qQA4m5DGM+e
	6O6+aVO6YWNefJgHX8QvgNC5tIKp9Q4ZKcRto0Wm8sVg1QMTgxVnL4jcUl8S0d2HrKMV
	bBLAVhqPawbUk/ZadhizKtZp4OD/imIh2jsDTBqqkLNuf3hVAlh+OS476p6p8pcdRGJD
	FFvS4uwt72tsPaL2NWWEtWQ3NIqd5/ZNN5p+tpFGcUJzBqGmrkimkoSVK7ewMFsEHkQx
	NyJI/DUO0s5h53gbiAGmc+PQ+KgLgPxB3hJuQBi4ZPSVMChx3z2qHBkasZTPSM5SqzId
	j/8A==
X-Received: by 10.14.218.71 with SMTP id j47mr6750638eep.28.1360923332251;
	Fri, 15 Feb 2013 02:15:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.145.135 with HTTP; Fri, 15 Feb 2013 02:15:16 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <511CF283.3080608@gmail.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
	<CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
	<1360851217.20449.395.camel@zakaz.uk.xensource.com>
	<511CF283.3080608@gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 15 Feb 2013 14:15:16 +0400
X-Google-Sender-Auth: X-KqatSVWotLaDpveh7QWsO6bEw
Message-ID: <CACaajQt37dU3oMoiba4P94wf3UUgZqqr=v7_dZK6FhN0NJec0g@mail.gmail.com>
To: Razvan Cojocaru <rzvncj@gmail.com>
X-Gm-Message-State: ALoCoQnOpXyRidfx0HJsamv/baN+PjMExMNH3egtVzZVrv+4Dq5HdXlhLCJgPe0jM5k1paIHpIRF
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
	destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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. Now after fired watch on @releaseDomain i'm check all domains
for my own domain id and get it status.

2013/2/14 Razvan Cojocaru <rzvncj@gmail.com>:
>>> As i understand if i want to know what domains dies i need after fired
>>> watch enumerate all domains and check its status.
>>
>>
>> Well, if you only care about one domain you just need to check that one
>> domain.
>>
>> Otherwise you should look at the libxl functionality I mentioned before.
>
>
> There's also tools/xenpaging/xenpaging.c that can be used as an example.
>
> Cheers,
> Razvan Cojocaru
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--
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 Feb 15 10:16:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 10: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 1U6IKN-00048P-BD; Fri, 15 Feb 2013 10:15:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1U6IKM-00048K-G2
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 10:15:34 +0000
Received: from [85.158.138.51:17809] by server-12.bemta-3.messagelabs.com id
	2E/C7-05889-5CA0E115; Fri, 15 Feb 2013 10:15:33 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360923332!27657140!1
X-Originating-IP: [74.125.83.53]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6877 invoked from network); 15 Feb 2013 10:15:32 -0000
Received: from mail-ee0-f53.google.com (HELO mail-ee0-f53.google.com)
	(74.125.83.53)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 10:15:32 -0000
Received: by mail-ee0-f53.google.com with SMTP id e53so1751723eek.40
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 02:15:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=x-received:mime-version:sender:x-originating-ip:in-reply-to
	:references:from:date:x-google-sender-auth:message-id:subject:to:cc
	:content-type; bh=eY7DxtXR+Z9jc1ybaXN8ef/MQHNcortt5oaXGNDJCVc=;
	b=DTfC+t/b6xOExzLgua6xWUfTWblxQevs2/Rb3X3Xyt9GY4OcJ282xuvGTvsPjVTZtE
	5N0LVYMjjWrgtoKSGucv2MHwZujFav6sg0nl19rpycO20Ch8ycwWhy/6h+sHjRjA636o
	NZ11rp300G+wYdt4oBU03ORQ7EOM6TnwDP/0g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=eY7DxtXR+Z9jc1ybaXN8ef/MQHNcortt5oaXGNDJCVc=;
	b=NIyza0EDR+GrH1b5rWy31lgIQza0NNljiFOI6rkj25hou5Csa5+0gr5qQA4m5DGM+e
	6O6+aVO6YWNefJgHX8QvgNC5tIKp9Q4ZKcRto0Wm8sVg1QMTgxVnL4jcUl8S0d2HrKMV
	bBLAVhqPawbUk/ZadhizKtZp4OD/imIh2jsDTBqqkLNuf3hVAlh+OS476p6p8pcdRGJD
	FFvS4uwt72tsPaL2NWWEtWQ3NIqd5/ZNN5p+tpFGcUJzBqGmrkimkoSVK7ewMFsEHkQx
	NyJI/DUO0s5h53gbiAGmc+PQ+KgLgPxB3hJuQBi4ZPSVMChx3z2qHBkasZTPSM5SqzId
	j/8A==
X-Received: by 10.14.218.71 with SMTP id j47mr6750638eep.28.1360923332251;
	Fri, 15 Feb 2013 02:15:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.145.135 with HTTP; Fri, 15 Feb 2013 02:15:16 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <511CF283.3080608@gmail.com>
References: <CACaajQvO8Vi50Extpzq=Q=M-R3fxNtK8qohKgcGcShuj5dQhKA@mail.gmail.com>
	<1360848973.20449.369.camel@zakaz.uk.xensource.com>
	<CACaajQvdoExTDYL8AfoAUFf9r=E9mY-SFNEpFi40LSRemw+yBw@mail.gmail.com>
	<1360851217.20449.395.camel@zakaz.uk.xensource.com>
	<511CF283.3080608@gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 15 Feb 2013 14:15:16 +0400
X-Google-Sender-Auth: X-KqatSVWotLaDpveh7QWsO6bEw
Message-ID: <CACaajQt37dU3oMoiba4P94wf3UUgZqqr=v7_dZK6FhN0NJec0g@mail.gmail.com>
To: Razvan Cojocaru <rzvncj@gmail.com>
X-Gm-Message-State: ALoCoQnOpXyRidfx0HJsamv/baN+PjMExMNH3egtVzZVrv+4Dq5HdXlhLCJgPe0jM5k1paIHpIRF
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] using @releaseDomain to subscribe for domain
	destruction
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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. Now after fired watch on @releaseDomain i'm check all domains
for my own domain id and get it status.

2013/2/14 Razvan Cojocaru <rzvncj@gmail.com>:
>>> As i understand if i want to know what domains dies i need after fired
>>> watch enumerate all domains and check its status.
>>
>>
>> Well, if you only care about one domain you just need to check that one
>> domain.
>>
>> Otherwise you should look at the libxl functionality I mentioned before.
>
>
> There's also tools/xenpaging/xenpaging.c that can be used as an example.
>
> Cheers,
> Razvan Cojocaru
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--
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 Feb 15 10:35:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 10: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 1U6IdN-0004LG-5B; Fri, 15 Feb 2013 10:35:13 +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 1U6IdL-0004LB-OM
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 10:35:12 +0000
Received: from [85.158.143.99:12477] by server-1.bemta-4.messagelabs.com id
	71/C5-08839-F5F0E115; Fri, 15 Feb 2013 10:35:11 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360924504!27681007!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 15 Feb 2013 10:35:04 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-216.messagelabs.com with SMTP;
	15 Feb 2013 10:35:04 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] 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 1U6Icq-0002Zq-SQ; Fri, 15 Feb 2013 10:34:41 +0000
Message-ID: <511E0F34.6010107@canonical.com>
Date: Fri, 15 Feb 2013 11:34:28 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
In-Reply-To: <511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.6
Cc: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3729548918811074619=="
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)
--===============3729548918811074619==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig11445852A98028C9EB012F6F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11445852A98028C9EB012F6F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15.02.2013 10:19, Jan Beulich wrote:
>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> On a machine that could not cover all its RAM with MTRR ranges,
>> a crash on boot as dom0 was caused by dom0 trying to create
>> kernel mapping tables for the clipped range.
>>
>> (XEN) WARNING: MTRRs do not cover all of memory.
>> (XEN) Truncating RAM from 9109504kB to 9043968kB
>> ...
>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
>> ...
>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
>> [    0.000000]  0228000000 - 022c000000 page 4k
>> [    0.000000] kernel direct mapping tables up to 22c000000 @
>>                1e97d8000-1e97fa000
>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000=

>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>>       type 1000000000000000: caf=3D8000000000000003 taf=3D100000000000=
0001
>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
>>
>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
>> this is the same type that gets used for memory to be used only
>> as guest memory (using dom0_mem=3D).
>=20
> Since when is E820_UNUSABLE memory being used as guest
> memory? If that's indeed the case, that's the bug to fix. The
> above data to me shows, however, that the range above
> 228000000 is considered invalid. So then the question is why the
> kernel tries to map that memory in the first place (the hypervisor
> rejecting the attempt, despite Dom0 being privileged, seems
> correct to me, as the range is also known not to be MMIO).

That seems to be done for a while now... On my testbox, when using dom0_m=
em=3D:

(XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
(XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
(XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
(XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
(XEN)  00000000ffe00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000820000000 (usable)

In dom0:
[    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
[    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data=

[    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
[    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable

[    0.000000] init_memory_mapping: [mem 0x100000000-0x2e063ffff]
[    0.000000]  [mem 0x100000000-0x2e063ffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x2e063ffff @ [mem
0x3f163000-0x4006ffff]

[   10.288549] e820: reserve RAM buffer [mem 0xdfe90000-0xdfffffff]
[   10.288555] e820: reserve RAM buffer [mem 0x2e0640000-0x2e3ffffff]

There the majority of memory appears as E820_UNUSABLE for dom0 and is use=
d for
guests. Ok, in that case not trying to do any kernel mappings...
Hm, not sure whether I should be worried about that first reserve RAM buf=
fer
covering the type 9 (whatever that is... I think it appeared when I upgra=
ded the
BIOS to get IOMMU back after xsa-36) range...

It seems to be arch/x86/xen/setup.c:xen_memory_setup() that changes thing=
s to
unusable...

-Stefan
>=20
>> To avoid this, the clipped memory should be dropped completely
>> from E820 (as it is done if setting the memory type fails).
>> This is currently restricted to only the case of memory not
>> coverable by MTRRs (which could be tested). Maybe it should
>> be done in other cases, too.
>=20
> No, that's wrong. When dropping the range completely, the
> Dom0 kernel then could allocate MMIO resources in that address
> range, and the devices using those MMIO resources then would
> not work.
>=20
> Bottom line - I think this needs to be fixed in the kernel.
>=20
> Jan


--------------enig11445852A98028C9EB012F6F
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHg8/AAoJEOhnXe7L7s6jHd8P/RCwATyHCK31aNgvDXhtgIWp
M/D1UCtPHbPJD2/xVzLmz2JcAqIpW2FVtQRyNTqeNBTfz0sg8z7oWSwlpUA1Q0QJ
ALoUSJ2BrZBb5qwDFYRFxODbuHUtd+G+uSCR6Cs0FE1xR2nbhQEkp/mg66Na8sO4
REgb7asJ9pj1qEFaivS9pCZ2LQt7KWYfNwMsSenxEKritbw1EDnctYcdLRBvZkZf
jRuPKM5/DfmW7cYjEX9xJCDmdfzRoG1OZukFb14UGBfWZkq7/NGPfOOzrEWrNdvH
jc1lTVAHtY/eLvbeeCLYtlRtgqH+NBULr4ufbJjyk6Q/6LMv4qDlby5nRqWDeaZM
5Z92zCw63Ef2aaQ2TsXtVUSWdLBR3hucfqtN1BDDZzfKzbbWfPMEFGZ4LDi0J96i
x+Wizmrz4e9Pn6s3yBceEv1/BfmEzWac/bT8S7Vi2fAwYxS+rILisqfhqdkouLCa
QAimOK4DG/zD+bC9yQGW7/nsuBRTeU4W/NtFb+KaGQwU32DXynFGuEELJVekfQDb
LLoyqCiLoTKAEYVXKSfRw06l2mfieU4IGtmE6ySmgMkP8wc1a0+Qb75VaFbugJUw
AMEksAN8ceTWKtvL2qkCGwuF/jc3NQrLYKY5UCGrgKUP99dIsYNFAyIVOT70C1jh
WiFGMrCXkgbq+NNpecge
=2gjf
-----END PGP SIGNATURE-----

--------------enig11445852A98028C9EB012F6F--


--===============3729548918811074619==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3729548918811074619==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 10:35:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 10: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 1U6IdN-0004LG-5B; Fri, 15 Feb 2013 10:35:13 +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 1U6IdL-0004LB-OM
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 10:35:12 +0000
Received: from [85.158.143.99:12477] by server-1.bemta-4.messagelabs.com id
	71/C5-08839-F5F0E115; Fri, 15 Feb 2013 10:35:11 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360924504!27681007!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 15 Feb 2013 10:35:04 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-216.messagelabs.com with SMTP;
	15 Feb 2013 10:35:04 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] 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 1U6Icq-0002Zq-SQ; Fri, 15 Feb 2013 10:34:41 +0000
Message-ID: <511E0F34.6010107@canonical.com>
Date: Fri, 15 Feb 2013 11:34:28 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
In-Reply-To: <511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.6
Cc: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3729548918811074619=="
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)
--===============3729548918811074619==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig11445852A98028C9EB012F6F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11445852A98028C9EB012F6F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15.02.2013 10:19, Jan Beulich wrote:
>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> On a machine that could not cover all its RAM with MTRR ranges,
>> a crash on boot as dom0 was caused by dom0 trying to create
>> kernel mapping tables for the clipped range.
>>
>> (XEN) WARNING: MTRRs do not cover all of memory.
>> (XEN) Truncating RAM from 9109504kB to 9043968kB
>> ...
>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
>> ...
>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
>> [    0.000000]  0228000000 - 022c000000 page 4k
>> [    0.000000] kernel direct mapping tables up to 22c000000 @
>>                1e97d8000-1e97fa000
>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000=

>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>>       type 1000000000000000: caf=3D8000000000000003 taf=3D100000000000=
0001
>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
>>
>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
>> this is the same type that gets used for memory to be used only
>> as guest memory (using dom0_mem=3D).
>=20
> Since when is E820_UNUSABLE memory being used as guest
> memory? If that's indeed the case, that's the bug to fix. The
> above data to me shows, however, that the range above
> 228000000 is considered invalid. So then the question is why the
> kernel tries to map that memory in the first place (the hypervisor
> rejecting the attempt, despite Dom0 being privileged, seems
> correct to me, as the range is also known not to be MMIO).

That seems to be done for a while now... On my testbox, when using dom0_m=
em=3D:

(XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
(XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
(XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
(XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
(XEN)  00000000ffe00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000820000000 (usable)

In dom0:
[    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
[    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data=

[    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
[    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable

[    0.000000] init_memory_mapping: [mem 0x100000000-0x2e063ffff]
[    0.000000]  [mem 0x100000000-0x2e063ffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x2e063ffff @ [mem
0x3f163000-0x4006ffff]

[   10.288549] e820: reserve RAM buffer [mem 0xdfe90000-0xdfffffff]
[   10.288555] e820: reserve RAM buffer [mem 0x2e0640000-0x2e3ffffff]

There the majority of memory appears as E820_UNUSABLE for dom0 and is use=
d for
guests. Ok, in that case not trying to do any kernel mappings...
Hm, not sure whether I should be worried about that first reserve RAM buf=
fer
covering the type 9 (whatever that is... I think it appeared when I upgra=
ded the
BIOS to get IOMMU back after xsa-36) range...

It seems to be arch/x86/xen/setup.c:xen_memory_setup() that changes thing=
s to
unusable...

-Stefan
>=20
>> To avoid this, the clipped memory should be dropped completely
>> from E820 (as it is done if setting the memory type fails).
>> This is currently restricted to only the case of memory not
>> coverable by MTRRs (which could be tested). Maybe it should
>> be done in other cases, too.
>=20
> No, that's wrong. When dropping the range completely, the
> Dom0 kernel then could allocate MMIO resources in that address
> range, and the devices using those MMIO resources then would
> not work.
>=20
> Bottom line - I think this needs to be fixed in the kernel.
>=20
> Jan


--------------enig11445852A98028C9EB012F6F
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHg8/AAoJEOhnXe7L7s6jHd8P/RCwATyHCK31aNgvDXhtgIWp
M/D1UCtPHbPJD2/xVzLmz2JcAqIpW2FVtQRyNTqeNBTfz0sg8z7oWSwlpUA1Q0QJ
ALoUSJ2BrZBb5qwDFYRFxODbuHUtd+G+uSCR6Cs0FE1xR2nbhQEkp/mg66Na8sO4
REgb7asJ9pj1qEFaivS9pCZ2LQt7KWYfNwMsSenxEKritbw1EDnctYcdLRBvZkZf
jRuPKM5/DfmW7cYjEX9xJCDmdfzRoG1OZukFb14UGBfWZkq7/NGPfOOzrEWrNdvH
jc1lTVAHtY/eLvbeeCLYtlRtgqH+NBULr4ufbJjyk6Q/6LMv4qDlby5nRqWDeaZM
5Z92zCw63Ef2aaQ2TsXtVUSWdLBR3hucfqtN1BDDZzfKzbbWfPMEFGZ4LDi0J96i
x+Wizmrz4e9Pn6s3yBceEv1/BfmEzWac/bT8S7Vi2fAwYxS+rILisqfhqdkouLCa
QAimOK4DG/zD+bC9yQGW7/nsuBRTeU4W/NtFb+KaGQwU32DXynFGuEELJVekfQDb
LLoyqCiLoTKAEYVXKSfRw06l2mfieU4IGtmE6ySmgMkP8wc1a0+Qb75VaFbugJUw
AMEksAN8ceTWKtvL2qkCGwuF/jc3NQrLYKY5UCGrgKUP99dIsYNFAyIVOT70C1jh
WiFGMrCXkgbq+NNpecge
=2gjf
-----END PGP SIGNATURE-----

--------------enig11445852A98028C9EB012F6F--


--===============3729548918811074619==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3729548918811074619==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 10:53:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 10: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 1U6IuR-0004ZU-1V; Fri, 15 Feb 2013 10:52:51 +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 1U6IuO-0004ZP-Sw
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 10:52:49 +0000
Received: from [193.109.254.147:52347] by server-10.bemta-14.messagelabs.com
	id 14/B6-12679-0831E115; Fri, 15 Feb 2013 10:52:48 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360925556!8519895!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15380 invoked from network); 15 Feb 2013 10:52:36 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-27.messagelabs.com with SMTP;
	15 Feb 2013 10:52:36 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1U6IuC-00036K-3g; Fri, 15 Feb 2013 10:52:36 +0000
From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Feb 2013 11:52:35 +0100
Message-Id: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Hopefully not mis-parsing Jan's last comments on the other thread,
this would be the fix covering things until a better implementation
is done.
This also prevents the hang on older kernels, where it could be re-
produced reliably.

-Stefan

>From 7e042a253b06da96409a0e059744c217f396a17f Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 15 Feb 2013 09:48:52 +0100
Subject: [PATCH] xen: Send spinlock IPI to all waiters

There is a loophole between Xen's current implementation of
pv-spinlocks and the scheduler. This was triggerable through
a testcase until v3.6 changed the TLB flushing code. The
problem potentially is still there just not observable in the
same way.

What could happen was (is):

1. CPU n tries to schedule task x away and goes into a slow
   wait for the runq lock of CPU n-# (must be one with a lower
   number).
2. CPU n-#, while processing softirqs, tries to balance domains
   and goes into a slow wait for its own runq lock (for updating
   some records). Since this is a spin_lock_irqsave in softirq
   context, interrupts will be re-enabled for the duration of
   the poll_irq hypercall used by Xen.
3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
   an interrupt (e.g. endio) and when processing the interrupt,
   tries to wake up task x. But that is in schedule and still
   on_cpu, so try_to_wake_up goes into a tight loop.
4. The runq lock of CPU n-# gets unlocked, but the message only
   gets sent to the first waiter, which is CPU n-# and that is
   busily stuck.

To avoid this and since the unlocking code has no real sense of
which waiter is best suited to grab the lock, just send the IPI
to all of them. This causes the waiters to return from the hyper-
call (those not interrupted at least) and do active spinlocking.

BugLink: http://bugs.launchpad.net/bugs/1011792

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Cc: stable@vger.kernel.org
---
 arch/x86/xen/spinlock.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83e866d..f7a080e 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
 		if (per_cpu(lock_spinners, cpu) == xl) {
 			ADD_STATS(released_slow_kicked, 1);
 			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
-			break;
 		}
 	}
 }
-- 
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 Fri Feb 15 10:53:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 10: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 1U6IuR-0004ZU-1V; Fri, 15 Feb 2013 10:52:51 +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 1U6IuO-0004ZP-Sw
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 10:52:49 +0000
Received: from [193.109.254.147:52347] by server-10.bemta-14.messagelabs.com
	id 14/B6-12679-0831E115; Fri, 15 Feb 2013 10:52:48 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360925556!8519895!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15380 invoked from network); 15 Feb 2013 10:52:36 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-27.messagelabs.com with SMTP;
	15 Feb 2013 10:52:36 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1U6IuC-00036K-3g; Fri, 15 Feb 2013 10:52:36 +0000
From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org
Date: Fri, 15 Feb 2013 11:52:35 +0100
Message-Id: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Hopefully not mis-parsing Jan's last comments on the other thread,
this would be the fix covering things until a better implementation
is done.
This also prevents the hang on older kernels, where it could be re-
produced reliably.

-Stefan

>From 7e042a253b06da96409a0e059744c217f396a17f Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 15 Feb 2013 09:48:52 +0100
Subject: [PATCH] xen: Send spinlock IPI to all waiters

There is a loophole between Xen's current implementation of
pv-spinlocks and the scheduler. This was triggerable through
a testcase until v3.6 changed the TLB flushing code. The
problem potentially is still there just not observable in the
same way.

What could happen was (is):

1. CPU n tries to schedule task x away and goes into a slow
   wait for the runq lock of CPU n-# (must be one with a lower
   number).
2. CPU n-#, while processing softirqs, tries to balance domains
   and goes into a slow wait for its own runq lock (for updating
   some records). Since this is a spin_lock_irqsave in softirq
   context, interrupts will be re-enabled for the duration of
   the poll_irq hypercall used by Xen.
3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
   an interrupt (e.g. endio) and when processing the interrupt,
   tries to wake up task x. But that is in schedule and still
   on_cpu, so try_to_wake_up goes into a tight loop.
4. The runq lock of CPU n-# gets unlocked, but the message only
   gets sent to the first waiter, which is CPU n-# and that is
   busily stuck.

To avoid this and since the unlocking code has no real sense of
which waiter is best suited to grab the lock, just send the IPI
to all of them. This causes the waiters to return from the hyper-
call (those not interrupted at least) and do active spinlocking.

BugLink: http://bugs.launchpad.net/bugs/1011792

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Cc: stable@vger.kernel.org
---
 arch/x86/xen/spinlock.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83e866d..f7a080e 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
 		if (per_cpu(lock_spinners, cpu) == xl) {
 			ADD_STATS(released_slow_kicked, 1);
 			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
-			break;
 		}
 	}
 }
-- 
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 Fri Feb 15 11:10:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:10: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 1U6JBF-0004n5-PO; Fri, 15 Feb 2013 11:10: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 1U6JBE-0004n0-Ip
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:10:12 +0000
Received: from [85.158.143.99:6002] by server-2.bemta-4.messagelabs.com id
	E3/8D-01597-3971E115; Fri, 15 Feb 2013 11:10:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360926609!22381373!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24131 invoked from network); 15 Feb 2013 11:10:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 11:10:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1508242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 11:10: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.297.1;
	Fri, 15 Feb 2013 11:10:09 +0000
Message-ID: <1360926607.31407.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 15 Feb 2013 11:10:07 +0000
In-Reply-To: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 83e866d..f7a080e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>  		if (per_cpu(lock_spinners, cpu) == xl) {
>  			ADD_STATS(released_slow_kicked, 1);
>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;

It would be more efficient to build a mask and use xen_send_IPI_mask().

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:10:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:10: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 1U6JBF-0004n5-PO; Fri, 15 Feb 2013 11:10: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 1U6JBE-0004n0-Ip
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:10:12 +0000
Received: from [85.158.143.99:6002] by server-2.bemta-4.messagelabs.com id
	E3/8D-01597-3971E115; Fri, 15 Feb 2013 11:10:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360926609!22381373!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24131 invoked from network); 15 Feb 2013 11:10:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 11:10:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1508242"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 11:10: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.297.1;
	Fri, 15 Feb 2013 11:10:09 +0000
Message-ID: <1360926607.31407.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 15 Feb 2013 11:10:07 +0000
In-Reply-To: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 83e866d..f7a080e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>  		if (per_cpu(lock_spinners, cpu) == xl) {
>  			ADD_STATS(released_slow_kicked, 1);
>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;

It would be more efficient to build a mask and use xen_send_IPI_mask().

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:15:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JFz-0004wE-H0; Fri, 15 Feb 2013 11:15:07 +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 1U6JFy-0004w6-7Z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:15:06 +0000
Received: from [85.158.139.211:38891] by server-14.bemta-5.messagelabs.com id
	82/83-06967-9B81E115; Fri, 15 Feb 2013 11:15:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360926903!22503455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25642 invoked from network); 15 Feb 2013 11:15:04 -0000
Received: from unknown (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 11:15:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 11:13:56 +0000
Message-Id: <511E268002000078000BE9FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 11:13:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
In-Reply-To: <511E0F34.6010107@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@canonical.com> wrote:
> On 15.02.2013 10:19, Jan Beulich wrote:
>>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrote:
>>> On a machine that could not cover all its RAM with MTRR ranges,
>>> a crash on boot as dom0 was caused by dom0 trying to create
>>> kernel mapping tables for the clipped range.
>>>
>>> (XEN) WARNING: MTRRs do not cover all of memory.
>>> (XEN) Truncating RAM from 9109504kB to 9043968kB
>>> ...
>>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
>>> ...
>>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
>>> [    0.000000]  0228000000 - 022c000000 page 4k
>>> [    0.000000] kernel direct mapping tables up to 22c000000 @
>>>                1e97d8000-1e97fa000
>>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
>>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
>>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>>>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
>>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
>>>
>>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
>>> this is the same type that gets used for memory to be used only
>>> as guest memory (using dom0_mem=).
>> 
>> Since when is E820_UNUSABLE memory being used as guest
>> memory? If that's indeed the case, that's the bug to fix. The
>> above data to me shows, however, that the range above
>> 228000000 is considered invalid. So then the question is why the
>> kernel tries to map that memory in the first place (the hypervisor
>> rejecting the attempt, despite Dom0 being privileged, seems
>> correct to me, as the range is also known not to be MMIO).
> 
> That seems to be done for a while now... On my testbox, when using 
> dom0_mem=:
> 
> (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
> (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
> (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
> (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
> (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000820000000 (usable)

All that counts is what you see above.

> In dom0:
> [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
> [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data
> [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
> [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
> [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable

What Dom0 does to its representation of the E820 map is of no
concern to the hypervisor. So are we in agreement then that the
hypervisor code is fine without any changes?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:15:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JFz-0004wE-H0; Fri, 15 Feb 2013 11:15:07 +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 1U6JFy-0004w6-7Z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:15:06 +0000
Received: from [85.158.139.211:38891] by server-14.bemta-5.messagelabs.com id
	82/83-06967-9B81E115; Fri, 15 Feb 2013 11:15:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360926903!22503455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25642 invoked from network); 15 Feb 2013 11:15:04 -0000
Received: from unknown (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 11:15:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 11:13:56 +0000
Message-Id: <511E268002000078000BE9FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 11:13:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
In-Reply-To: <511E0F34.6010107@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@canonical.com> wrote:
> On 15.02.2013 10:19, Jan Beulich wrote:
>>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrote:
>>> On a machine that could not cover all its RAM with MTRR ranges,
>>> a crash on boot as dom0 was caused by dom0 trying to create
>>> kernel mapping tables for the clipped range.
>>>
>>> (XEN) WARNING: MTRRs do not cover all of memory.
>>> (XEN) Truncating RAM from 9109504kB to 9043968kB
>>> ...
>>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
>>> ...
>>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
>>> [    0.000000]  0228000000 - 022c000000 page 4k
>>> [    0.000000] kernel direct mapping tables up to 22c000000 @
>>>                1e97d8000-1e97fa000
>>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
>>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
>>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>>>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
>>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
>>>
>>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
>>> this is the same type that gets used for memory to be used only
>>> as guest memory (using dom0_mem=).
>> 
>> Since when is E820_UNUSABLE memory being used as guest
>> memory? If that's indeed the case, that's the bug to fix. The
>> above data to me shows, however, that the range above
>> 228000000 is considered invalid. So then the question is why the
>> kernel tries to map that memory in the first place (the hypervisor
>> rejecting the attempt, despite Dom0 being privileged, seems
>> correct to me, as the range is also known not to be MMIO).
> 
> That seems to be done for a while now... On my testbox, when using 
> dom0_mem=:
> 
> (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
> (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
> (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
> (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
> (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000000820000000 (usable)

All that counts is what you see above.

> In dom0:
> [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
> [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data
> [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
> [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
> [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable

What Dom0 does to its representation of the E820 map is of no
concern to the hypervisor. So are we in agreement then that the
hypervisor code is fine without any changes?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:20:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JLF-000568-Fh; Fri, 15 Feb 2013 11:20:33 +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 1U6JLD-000562-UA
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:20:32 +0000
Received: from [85.158.139.211:53243] by server-15.bemta-5.messagelabs.com id
	F7/17-18914-EF91E115; Fri, 15 Feb 2013 11:20:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360927229!22595157!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14763 invoked from network); 15 Feb 2013 11:20:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 11:20:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 11:20:31 +0000
Message-Id: <511E280A02000078000BEA18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 11:20:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.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: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(resending with proper list address)

>>> On 15.02.13 at 11:50, Stefan Bader <stefan.bader@canonical.com> wrote:
> Hopefully not mis-parsing Jan's last comments on the other thread,
> this would be the fix covering things until a better implementation
> is done.
> This also prevents the hang on older kernels, where it could be re-
> produced reliably.
> 
> -Stefan
> 
> From 7e042a253b06da96409a0e059744c217f396a17f Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Feb 2013 09:48:52 +0100
> Subject: [PATCH] xen: Send spinlock IPI to all waiters
> 
> There is a loophole between Xen's current implementation of
> pv-spinlocks and the scheduler. This was triggerable through
> a testcase until v3.6 changed the TLB flushing code. The
> problem potentially is still there just not observable in the
> same way.
> 
> What could happen was (is):
> 
> 1. CPU n tries to schedule task x away and goes into a slow
>    wait for the runq lock of CPU n-# (must be one with a lower
>    number).
> 2. CPU n-#, while processing softirqs, tries to balance domains
>    and goes into a slow wait for its own runq lock (for updating
>    some records). Since this is a spin_lock_irqsave in softirq
>    context, interrupts will be re-enabled for the duration of
>    the poll_irq hypercall used by Xen.
> 3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
>    an interrupt (e.g. endio) and when processing the interrupt,
>    tries to wake up task x. But that is in schedule and still
>    on_cpu, so try_to_wake_up goes into a tight loop.
> 4. The runq lock of CPU n-# gets unlocked, but the message only
>    gets sent to the first waiter, which is CPU n-# and that is
>    busily stuck.
> 
> To avoid this and since the unlocking code has no real sense of
> which waiter is best suited to grab the lock, just send the IPI
> to all of them. This causes the waiters to return from the hyper-
> call (those not interrupted at least) and do active spinlocking.
> 
> BugLink: http://bugs.launchpad.net/bugs/1011792 
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

(but see below)

> Cc: stable@vger.kernel.org 

(back to 3.0; earlier kernels shouldn't be affected)

> ---
>  arch/x86/xen/spinlock.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 83e866d..f7a080e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> xen_spinlock *xl)
>  		if (per_cpu(lock_spinners, cpu) == xl) {
>  			ADD_STATS(released_slow_kicked, 1);
>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;

Of course that's the minimal fix. Would be nice if this could be done
as a batch, since even if congestion on locks might be rare, it's
specifically that case where the biggest gain from doing things
quickly can be had.

But of course, as said earlier, switching to ticket locks should be the
real goal.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:20:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JLF-000568-Fh; Fri, 15 Feb 2013 11:20:33 +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 1U6JLD-000562-UA
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:20:32 +0000
Received: from [85.158.139.211:53243] by server-15.bemta-5.messagelabs.com id
	F7/17-18914-EF91E115; Fri, 15 Feb 2013 11:20:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360927229!22595157!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14763 invoked from network); 15 Feb 2013 11:20:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 11:20:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 11:20:31 +0000
Message-Id: <511E280A02000078000BEA18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 11:20:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.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: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(resending with proper list address)

>>> On 15.02.13 at 11:50, Stefan Bader <stefan.bader@canonical.com> wrote:
> Hopefully not mis-parsing Jan's last comments on the other thread,
> this would be the fix covering things until a better implementation
> is done.
> This also prevents the hang on older kernels, where it could be re-
> produced reliably.
> 
> -Stefan
> 
> From 7e042a253b06da96409a0e059744c217f396a17f Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Feb 2013 09:48:52 +0100
> Subject: [PATCH] xen: Send spinlock IPI to all waiters
> 
> There is a loophole between Xen's current implementation of
> pv-spinlocks and the scheduler. This was triggerable through
> a testcase until v3.6 changed the TLB flushing code. The
> problem potentially is still there just not observable in the
> same way.
> 
> What could happen was (is):
> 
> 1. CPU n tries to schedule task x away and goes into a slow
>    wait for the runq lock of CPU n-# (must be one with a lower
>    number).
> 2. CPU n-#, while processing softirqs, tries to balance domains
>    and goes into a slow wait for its own runq lock (for updating
>    some records). Since this is a spin_lock_irqsave in softirq
>    context, interrupts will be re-enabled for the duration of
>    the poll_irq hypercall used by Xen.
> 3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
>    an interrupt (e.g. endio) and when processing the interrupt,
>    tries to wake up task x. But that is in schedule and still
>    on_cpu, so try_to_wake_up goes into a tight loop.
> 4. The runq lock of CPU n-# gets unlocked, but the message only
>    gets sent to the first waiter, which is CPU n-# and that is
>    busily stuck.
> 
> To avoid this and since the unlocking code has no real sense of
> which waiter is best suited to grab the lock, just send the IPI
> to all of them. This causes the waiters to return from the hyper-
> call (those not interrupted at least) and do active spinlocking.
> 
> BugLink: http://bugs.launchpad.net/bugs/1011792 
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

(but see below)

> Cc: stable@vger.kernel.org 

(back to 3.0; earlier kernels shouldn't be affected)

> ---
>  arch/x86/xen/spinlock.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 83e866d..f7a080e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> xen_spinlock *xl)
>  		if (per_cpu(lock_spinners, cpu) == xl) {
>  			ADD_STATS(released_slow_kicked, 1);
>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;

Of course that's the minimal fix. Would be nice if this could be done
as a batch, since even if congestion on locks might be rare, it's
specifically that case where the biggest gain from doing things
quickly can be had.

But of course, as said earlier, switching to ticket locks should be the
real goal.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:26:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:26: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 1U6JR1-0005H3-D9; Fri, 15 Feb 2013 11:26:31 +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 1U6JR1-0005Gy-1j
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:26:31 +0000
Received: from [193.109.254.147:59728] by server-4.bemta-14.messagelabs.com id
	C3/31-20719-66B1E115; Fri, 15 Feb 2013 11:26:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360927587!837097!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7272 invoked from network); 15 Feb 2013 11:26:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 11:26:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 11:26:28 +0000
Message-Id: <511E296D02000078000BEA27@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 11:26:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>,
	"Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360926607.31407.10.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
>> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>> index 83e866d..f7a080e 100644
>> --- a/arch/x86/xen/spinlock.c
>> +++ b/arch/x86/xen/spinlock.c
>> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> xen_spinlock *xl)
>>  		if (per_cpu(lock_spinners, cpu) == xl) {
>>  			ADD_STATS(released_slow_kicked, 1);
>>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
>> -			break;
> 
> It would be more efficient to build a mask and use xen_send_IPI_mask().

In order for __xen_send_IPI_mask() to then take the list apart
again and call xen_send_IPI_one()? There's no batching
implemented currently...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:26:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:26: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 1U6JR1-0005H3-D9; Fri, 15 Feb 2013 11:26:31 +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 1U6JR1-0005Gy-1j
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:26:31 +0000
Received: from [193.109.254.147:59728] by server-4.bemta-14.messagelabs.com id
	C3/31-20719-66B1E115; Fri, 15 Feb 2013 11:26:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360927587!837097!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7272 invoked from network); 15 Feb 2013 11:26:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 11:26:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 11:26:28 +0000
Message-Id: <511E296D02000078000BEA27@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 11:26:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>,
	"Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360926607.31407.10.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
>> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>> index 83e866d..f7a080e 100644
>> --- a/arch/x86/xen/spinlock.c
>> +++ b/arch/x86/xen/spinlock.c
>> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> xen_spinlock *xl)
>>  		if (per_cpu(lock_spinners, cpu) == xl) {
>>  			ADD_STATS(released_slow_kicked, 1);
>>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
>> -			break;
> 
> It would be more efficient to build a mask and use xen_send_IPI_mask().

In order for __xen_send_IPI_mask() to then take the list apart
again and call xen_send_IPI_one()? There's no batching
implemented currently...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:31:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JVn-0005R3-5P; Fri, 15 Feb 2013 11:31:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U6JVm-0005Qy-7Z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:31:26 +0000
Received: from [85.158.143.99:33343] by server-2.bemta-4.messagelabs.com id
	97/09-01597-D8C1E115; Fri, 15 Feb 2013 11:31:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360927884!22385465!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28916 invoked from network); 15 Feb 2013 11:31:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 11:31:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1509587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 11:31: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.297.1;
	Fri, 15 Feb 2013 11:31:24 +0000
Message-ID: <1360927883.31407.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 11:31:23 +0000
In-Reply-To: <511E296D02000078000BEA27@nat28.tlf.novell.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> >> index 83e866d..f7a080e 100644
> >> --- a/arch/x86/xen/spinlock.c
> >> +++ b/arch/x86/xen/spinlock.c
> >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> > xen_spinlock *xl)
> >>  		if (per_cpu(lock_spinners, cpu) == xl) {
> >>  			ADD_STATS(released_slow_kicked, 1);
> >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> >> -			break;
> > 
> > It would be more efficient to build a mask and use xen_send_IPI_mask().
> 
> In order for __xen_send_IPI_mask() to then take the list apart
> again and call xen_send_IPI_one()? There's no batching
> implemented currently...

Oh, I simply assumed it must obviously do that!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:31:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JVn-0005R3-5P; Fri, 15 Feb 2013 11:31:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U6JVm-0005Qy-7Z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:31:26 +0000
Received: from [85.158.143.99:33343] by server-2.bemta-4.messagelabs.com id
	97/09-01597-D8C1E115; Fri, 15 Feb 2013 11:31:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1360927884!22385465!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28916 invoked from network); 15 Feb 2013 11:31:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 11:31:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1509587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 11:31: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.297.1;
	Fri, 15 Feb 2013 11:31:24 +0000
Message-ID: <1360927883.31407.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 11:31:23 +0000
In-Reply-To: <511E296D02000078000BEA27@nat28.tlf.novell.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> >> index 83e866d..f7a080e 100644
> >> --- a/arch/x86/xen/spinlock.c
> >> +++ b/arch/x86/xen/spinlock.c
> >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> > xen_spinlock *xl)
> >>  		if (per_cpu(lock_spinners, cpu) == xl) {
> >>  			ADD_STATS(released_slow_kicked, 1);
> >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> >> -			break;
> > 
> > It would be more efficient to build a mask and use xen_send_IPI_mask().
> 
> In order for __xen_send_IPI_mask() to then take the list apart
> again and call xen_send_IPI_one()? There's no batching
> implemented currently...

Oh, I simply assumed it must obviously do that!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:32:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JWI-0005T2-LU; Fri, 15 Feb 2013 11:31:58 +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 1U6JWH-0005Sp-EQ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:31:57 +0000
Received: from [85.158.138.51:26636] by server-14.bemta-3.messagelabs.com id
	59/85-23533-CAC1E115; Fri, 15 Feb 2013 11:31:56 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360927915!21359740!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16449 invoked from network); 15 Feb 2013 11:31:55 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-174.messagelabs.com with SMTP;
	15 Feb 2013 11:31:55 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] 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 1U6JWF-0001iy-0g; Fri, 15 Feb 2013 11:31:55 +0000
Message-ID: <511E1CA9.7080000@canonical.com>
Date: Fri, 15 Feb 2013 12:31:53 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
In-Reply-To: <511E268002000078000BE9FA@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.6
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6764879784649301016=="
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)
--===============6764879784649301016==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig9308D58B7775E0CF205389A4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9308D58B7775E0CF205389A4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15.02.2013 12:13, Jan Beulich wrote:
>>>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> On 15.02.2013 10:19, Jan Beulich wrote:
>>>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wr=
ote:
>>>> On a machine that could not cover all its RAM with MTRR ranges,
>>>> a crash on boot as dom0 was caused by dom0 trying to create
>>>> kernel mapping tables for the clipped range.
>>>>
>>>> (XEN) WARNING: MTRRs do not cover all of memory.
>>>> (XEN) Truncating RAM from 9109504kB to 9043968kB
>>>> ...
>>>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
>>>> ...
>>>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c00000=
0
>>>> [    0.000000]  0228000000 - 022c000000 page 4k
>>>> [    0.000000] kernel direct mapping tables up to 22c000000 @
>>>>                1e97d8000-1e97fa000
>>>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 002280=
00
>>>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
>>>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>>>>       type 1000000000000000: caf=3D8000000000000003 taf=3D1000000000=
000001
>>>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
>>>>
>>>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
>>>> this is the same type that gets used for memory to be used only
>>>> as guest memory (using dom0_mem=3D).
>>>
>>> Since when is E820_UNUSABLE memory being used as guest
>>> memory? If that's indeed the case, that's the bug to fix. The
>>> above data to me shows, however, that the range above
>>> 228000000 is considered invalid. So then the question is why the
>>> kernel tries to map that memory in the first place (the hypervisor
>>> rejecting the attempt, despite Dom0 being privileged, seems
>>> correct to me, as the range is also known not to be MMIO).
>>
>> That seems to be done for a while now... On my testbox, when using=20
>> dom0_mem=3D:
>>
>> (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
>> (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
>> (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
>> (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
>> (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
>> (XEN)  0000000100000000 - 0000000820000000 (usable)
>=20
> All that counts is what you see above.
>=20
>> In dom0:
>> [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9=

>> [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI d=
ata
>> [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI N=
VS
>> [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserv=
ed
>> [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable=

>> [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusab=
le
>=20
> What Dom0 does to its representation of the E820 map is of no
> concern to the hypervisor. So are we in agreement then that the
> hypervisor code is fine without any changes?

Yes, if we also agree that using unusable for something that is then used=
 is
wrong. So lets drop the xen patch and I try to figure fixing the kernel.

-Stefan



--------------enig9308D58B7775E0CF205389A4
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHhypAAoJEOhnXe7L7s6jBPQP/i1b2mz6f0aflYheSnsKbgNe
KS04lFOGIN087FLNhY5qVNqj5fVxusXE2Rszq/IGlWg3Hv0SJj6176B0vK7ljKeT
ZR5nXDPBhfwIGJGfjhb0i6/jP37W+1ATGxNHBaCP3PguI33MJQHn5D2GwXZ1Hsbi
4y3WGiMx9nW3LWBRTZfE7MMAZpaVmUUuvRgnDfqN5ol4dLNjHPNt8N+u/CaukuVm
iwaMdeSsDpotqk06LzrPykr19DxKhql0DoUz0M1Eo7uNLWRDO9HPHOrU0nxqh/7a
CLybSNKRLUqDIBGmaOynxtHjjZd+43hhcbiiFei8SBo3Pc4tR6Qv3g3BU9xYufso
nFA41OBx8QfgU2JItKAiFGbP6gMBZUokziPMfYUI4yBN+EVxdsO/9sRQW1Sh6fzU
zyQjdwyhvDNawrUUH+yAfwMhzhnlikC5HS/Q/1dA6zoGbOuE8SxzPQYMlBKFpHGb
t1uSVn0Fs8O/a/piowuaAaKUofViq0y4q2zFmtKfeEDVxcU/GNE73TcCu4Rxizy4
Y07dK4U9WWh4c8W8g4aabQldOyLcNran2HLUvicgYNDW4y0Xms6/2G5SNCLkqPiw
6Rw37+JRXCMzrpMGkEVwA7/9O2iObGO8Qd9CNK14uILdfpcVZK9R7JSPldJ7MoAR
fEoawRIJf6ywESuebAkA
=8OM+
-----END PGP SIGNATURE-----

--------------enig9308D58B7775E0CF205389A4--


--===============6764879784649301016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6764879784649301016==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 11:32:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6JWI-0005T2-LU; Fri, 15 Feb 2013 11:31:58 +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 1U6JWH-0005Sp-EQ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:31:57 +0000
Received: from [85.158.138.51:26636] by server-14.bemta-3.messagelabs.com id
	59/85-23533-CAC1E115; Fri, 15 Feb 2013 11:31:56 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1360927915!21359740!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16449 invoked from network); 15 Feb 2013 11:31:55 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-174.messagelabs.com with SMTP;
	15 Feb 2013 11:31:55 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] 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 1U6JWF-0001iy-0g; Fri, 15 Feb 2013 11:31:55 +0000
Message-ID: <511E1CA9.7080000@canonical.com>
Date: Fri, 15 Feb 2013 12:31:53 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
In-Reply-To: <511E268002000078000BE9FA@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.6
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6764879784649301016=="
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)
--===============6764879784649301016==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig9308D58B7775E0CF205389A4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9308D58B7775E0CF205389A4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15.02.2013 12:13, Jan Beulich wrote:
>>>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> On 15.02.2013 10:19, Jan Beulich wrote:
>>>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wr=
ote:
>>>> On a machine that could not cover all its RAM with MTRR ranges,
>>>> a crash on boot as dom0 was caused by dom0 trying to create
>>>> kernel mapping tables for the clipped range.
>>>>
>>>> (XEN) WARNING: MTRRs do not cover all of memory.
>>>> (XEN) Truncating RAM from 9109504kB to 9043968kB
>>>> ...
>>>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
>>>> ...
>>>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c00000=
0
>>>> [    0.000000]  0228000000 - 022c000000 page 4k
>>>> [    0.000000] kernel direct mapping tables up to 22c000000 @
>>>>                1e97d8000-1e97fa000
>>>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 002280=
00
>>>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
>>>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
>>>>       type 1000000000000000: caf=3D8000000000000003 taf=3D1000000000=
000001
>>>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
>>>>
>>>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
>>>> this is the same type that gets used for memory to be used only
>>>> as guest memory (using dom0_mem=3D).
>>>
>>> Since when is E820_UNUSABLE memory being used as guest
>>> memory? If that's indeed the case, that's the bug to fix. The
>>> above data to me shows, however, that the range above
>>> 228000000 is considered invalid. So then the question is why the
>>> kernel tries to map that memory in the first place (the hypervisor
>>> rejecting the attempt, despite Dom0 being privileged, seems
>>> correct to me, as the range is also known not to be MMIO).
>>
>> That seems to be done for a while now... On my testbox, when using=20
>> dom0_mem=3D:
>>
>> (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
>> (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
>> (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
>> (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
>> (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
>> (XEN)  0000000100000000 - 0000000820000000 (usable)
>=20
> All that counts is what you see above.
>=20
>> In dom0:
>> [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9=

>> [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI d=
ata
>> [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI N=
VS
>> [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserv=
ed
>> [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserv=
ed
>> [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable=

>> [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusab=
le
>=20
> What Dom0 does to its representation of the E820 map is of no
> concern to the hypervisor. So are we in agreement then that the
> hypervisor code is fine without any changes?

Yes, if we also agree that using unusable for something that is then used=
 is
wrong. So lets drop the xen patch and I try to figure fixing the kernel.

-Stefan



--------------enig9308D58B7775E0CF205389A4
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHhypAAoJEOhnXe7L7s6jBPQP/i1b2mz6f0aflYheSnsKbgNe
KS04lFOGIN087FLNhY5qVNqj5fVxusXE2Rszq/IGlWg3Hv0SJj6176B0vK7ljKeT
ZR5nXDPBhfwIGJGfjhb0i6/jP37W+1ATGxNHBaCP3PguI33MJQHn5D2GwXZ1Hsbi
4y3WGiMx9nW3LWBRTZfE7MMAZpaVmUUuvRgnDfqN5ol4dLNjHPNt8N+u/CaukuVm
iwaMdeSsDpotqk06LzrPykr19DxKhql0DoUz0M1Eo7uNLWRDO9HPHOrU0nxqh/7a
CLybSNKRLUqDIBGmaOynxtHjjZd+43hhcbiiFei8SBo3Pc4tR6Qv3g3BU9xYufso
nFA41OBx8QfgU2JItKAiFGbP6gMBZUokziPMfYUI4yBN+EVxdsO/9sRQW1Sh6fzU
zyQjdwyhvDNawrUUH+yAfwMhzhnlikC5HS/Q/1dA6zoGbOuE8SxzPQYMlBKFpHGb
t1uSVn0Fs8O/a/piowuaAaKUofViq0y4q2zFmtKfeEDVxcU/GNE73TcCu4Rxizy4
Y07dK4U9WWh4c8W8g4aabQldOyLcNran2HLUvicgYNDW4y0Xms6/2G5SNCLkqPiw
6Rw37+JRXCMzrpMGkEVwA7/9O2iObGO8Qd9CNK14uILdfpcVZK9R7JSPldJ7MoAR
fEoawRIJf6ywESuebAkA
=8OM+
-----END PGP SIGNATURE-----

--------------enig9308D58B7775E0CF205389A4--


--===============6764879784649301016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6764879784649301016==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 11:36:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6Jan-0005jx-LH; Fri, 15 Feb 2013 11:36:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefan.Hausotte@gdata.de>) id 1U6Jal-0005jo-Ab
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:36:36 +0000
Received: from [85.158.137.99:44524] by server-5.bemta-3.messagelabs.com id
	64/7F-04457-2CD1E115; Fri, 15 Feb 2013 11:36:34 +0000
X-Env-Sender: Stefan.Hausotte@gdata.de
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360928188!12236467!1
X-Originating-IP: [212.23.140.98]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6694 invoked from network); 15 Feb 2013 11:36:28 -0000
Received: from domain.gdata.de (HELO domain.gdata.de) (212.23.140.98)
	by server-7.tower-217.messagelabs.com with SMTP;
	15 Feb 2013 11:36:28 -0000
Received: from mx1.gdata.de (unknown [212.23.140.110])
	by domain.gdata.de (Postfix) with SMTP id 8E63818E629C
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 12:34:14 +0100 (CET)
Received: from [192.168.10.11] (helo=e1.gdata.de)
	by mx1.gdata.de with G Data MailSecurity;
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 12:36:28 +0100
Received: from E3.gdata.de (192.168.10.13) by e1.gdata.de (192.168.10.11) with
	Microsoft SMTP Server (TLS) id 14.1.438.0;
	Fri, 15 Feb 2013 12:36:27 +0100
Received: from E1.gdata.de ([fe80::9e9:cce9:5d91:ce06]) by e3.gdata.de
	([fe80::cc2f:accb:5bab:d2e3%10]) with mapi id 14.01.0438.000;
	Fri, 15 Feb 2013 12:36:27 +0100
Date: Fri, 15 Feb 2013 11:36:27 +0000
From: <Stefan.Hausotte@gdata.de>
To: <xen-devel@lists.xen.org>
MIME-Version: 1.0
Message-ID: <09ED90B020890C46AC23A0F84475B37F0E98B6A5@e1.gdata.de>
Thread-Topic: Build win-pv Error
Thread-Index: Ac4LcLCIOIcIVI1KT4qAm+pB4jGrfg==
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.215.12.96]
X-AVK-Virus-Check: AVA 22.7969;15.02.2013
Subject: [Xen-devel] Build win-pv 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: multipart/mixed; boundary="===============3921283788317877739=="
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.

--===============3921283788317877739==
Content-Language: de-DE
Content-Type: multipart/alternative;
	boundary="_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_"

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.

--_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi XEN-Community,

I'm trying to build the actual version of the XEN gplpv (win-pv) drivers.
I use the a Windows XP machine with the WinDDK 7600.16385.1 and Wix 3.0 like=
 suggested  in the BUILD.txt
The building process itself seems to be working, at least there are no compi=
ler error.  (I just made the "makedist")
Instead, the final *.msi files and the drivers itself are nowhere to be foun=
d, but they should be in the "target" directory.
It seems that some files are missing, which can be seen in the build output.=
=2E I've tried some day to figure it out, but I have no
idea where this files are, or why they are not where they should be.

So please help me! Thanks for your answers.

Greetings Stefan

OUTPUT OF THE BUILD PROCESS:

Das System kann den angegebenen Pfad nicht finden.
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:17:36 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objchk_wxp_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wxp_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wxp_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wxp_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objchk_wxp_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wxp_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wxp_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WINXP
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wxp_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:03 2013
BUILD: Done


    71 files compiled
    2 libraries built
    7 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:18:04 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objchk_wnet_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wnet_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wnet_x86\i386\xenvbd=
filter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objchk_wnet_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wnet_x86\i386\copyconfig.e=
xe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wnet_x86\i386\shutdownmo=
n.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wnet_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:14 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:18:15 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objchk_wnet_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wnet_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wnet_amd64\amd64\xen=
vbdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objchk_wnet_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wnet_amd64\amd64\copyconfi=
g.exe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wnet_amd64\amd64\shutdow=
nmon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wnet_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:36 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:18:37 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objchk_wlh_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wlh_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wlh_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objchk_wlh_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wlh_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wlh_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wlh_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:50 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:18:50 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objchk_wlh_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wlh_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wlh_amd64\amd64\xenv=
bdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objchk_wlh_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wlh_amd64\amd64\copyconfig=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wlh_amd64\amd64\shutdown=
mon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wlh_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:19:10 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
Das System kann den angegebenen Pfad nicht finden.
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:19:10 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objfre_wxp_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wxp_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wxp_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wxp_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objfre_wxp_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wxp_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wxp_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WINXP
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wxp_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:19:42 2013
BUILD: Done


    71 files compiled
    2 libraries built
    7 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:19:42 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objfre_wnet_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wnet_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wnet_x86\i386\xenvbd=
filter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objfre_wnet_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wnet_x86\i386\copyconfig.e=
xe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wnet_x86\i386\shutdownmo=
n.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wnet_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:20:21 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:20:22 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objfre_wnet_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wnet_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wnet_amd64\amd64\xen=
vbdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objfre_wnet_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wnet_amd64\amd64\copyconfi=
g.exe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wnet_amd64\amd64\shutdow=
nmon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wnet_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:20:40 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:20:40 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objfre_wlh_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wlh_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wlh_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objfre_wlh_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wlh_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wlh_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wlh_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:20:52 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:20:53 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objfre_wlh_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wlh_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wlh_amd64\amd64\xenv=
bdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objfre_wlh_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wlh_amd64\amd64\copyconfig=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wlh_amd64\amd64\shutdown=
mon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wlh_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:21:09 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t

____________
Virus checked by G Data AntiVirus
Version: AVA 22.7969 dated 15.02.2013
Virus news: www.antiviruslab.com
--_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_
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" x=
mlns: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 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0cm;
	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;}
span.E-MailFormatvorlage17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
=2E.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
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"DE" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi XEN-Community,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I&#8217;m trying to build the ac=
tual version of the XEN gplpv (win-pv) drivers.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I use the a Windows XP machine w=
ith the WinDDK 7600.16385.1 and Wix 3.0 like suggested &nbsp;in the BUILD.tx=
t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The building process itself seem=
s to be working, at least there are no compiler error. &nbsp;(I just made th=
e &#8220;makedist&#8221;)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Instead, the final *.msi files a=
nd the drivers itself are nowhere to be found, but they should be in the &#8=
220;target&#8221; directory.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">It seems that some files are mis=
sing, which can be seen in the build output. I&#8217;ve tried some day to fi=
gure it out, but I have no<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">idea where this files are, or wh=
y they are not where they should be.<o:p></o:p></span></p>
<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">So please help me! Thanks for yo=
ur answers.<o:p></o:p></span></p>
<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">Greetings Stefan<o:p></o:p></spa=
n></p>
<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">OUTPUT OF THE BUILD PROCESS:<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:17:36 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wxp_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wxp_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wxp_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wxp_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wxp_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wxp_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wxp_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wxp_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:03 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 71 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>7 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:04 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wnet_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wnet_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wnet_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wnet_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wnet_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wnet_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wnet_x86\i386\waitnopendin=
ginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:14 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:15 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wnet_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wnet_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wnet_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wnet_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wnet_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wnet_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wnet_amd64\amd64\waitnopen=
dinginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:36 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:37 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wlh_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wlh_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wlh_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wlh_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wlh_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wlh_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wlh_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:50 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:50 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wlh_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wlh_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wlh_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wlh_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wlh_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wlh_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wlh_amd64\amd64\waitnopend=
inginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:19:10 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:19:10 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wxp_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wxp_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wxp_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wxp_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wxp_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wxp_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wxp_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wxp_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:19:42 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 71 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>7 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:19:42 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wnet_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wnet_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wnet_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wnet_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wnet_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wnet_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wnet_x86\i386\waitnopendin=
ginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:20:21 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:20:22 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wnet_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wnet_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wnet_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wnet_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wnet_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wnet_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wnet_amd64\amd64\waitnopen=
dinginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:20:40 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:20:40 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wlh_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wlh_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wlh_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wlh_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wlh_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wlh_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wlh_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:20:52 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:20:53 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wlh_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wlh_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wlh_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wlh_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wlh_amd64\amd64\waitnopend=
inginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:21:09 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
</div>
<BR>
____________<BR>
Virus checked by G Data AntiVirus<BR>
Version: AVA 22.7969 dated 15.02.2013<BR>
Virus news: <a href=3D"http://www.antiviruslab.com">www.antiviruslab.com</a>=
<BR>
</body>
</html>
--_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_--



--===============3921283788317877739==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3921283788317877739==--



From xen-devel-bounces@lists.xen.org Fri Feb 15 11:36:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11: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 1U6Jan-0005jx-LH; Fri, 15 Feb 2013 11:36:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefan.Hausotte@gdata.de>) id 1U6Jal-0005jo-Ab
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:36:36 +0000
Received: from [85.158.137.99:44524] by server-5.bemta-3.messagelabs.com id
	64/7F-04457-2CD1E115; Fri, 15 Feb 2013 11:36:34 +0000
X-Env-Sender: Stefan.Hausotte@gdata.de
X-Msg-Ref: server-7.tower-217.messagelabs.com!1360928188!12236467!1
X-Originating-IP: [212.23.140.98]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6694 invoked from network); 15 Feb 2013 11:36:28 -0000
Received: from domain.gdata.de (HELO domain.gdata.de) (212.23.140.98)
	by server-7.tower-217.messagelabs.com with SMTP;
	15 Feb 2013 11:36:28 -0000
Received: from mx1.gdata.de (unknown [212.23.140.110])
	by domain.gdata.de (Postfix) with SMTP id 8E63818E629C
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 12:34:14 +0100 (CET)
Received: from [192.168.10.11] (helo=e1.gdata.de)
	by mx1.gdata.de with G Data MailSecurity;
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 12:36:28 +0100
Received: from E3.gdata.de (192.168.10.13) by e1.gdata.de (192.168.10.11) with
	Microsoft SMTP Server (TLS) id 14.1.438.0;
	Fri, 15 Feb 2013 12:36:27 +0100
Received: from E1.gdata.de ([fe80::9e9:cce9:5d91:ce06]) by e3.gdata.de
	([fe80::cc2f:accb:5bab:d2e3%10]) with mapi id 14.01.0438.000;
	Fri, 15 Feb 2013 12:36:27 +0100
Date: Fri, 15 Feb 2013 11:36:27 +0000
From: <Stefan.Hausotte@gdata.de>
To: <xen-devel@lists.xen.org>
MIME-Version: 1.0
Message-ID: <09ED90B020890C46AC23A0F84475B37F0E98B6A5@e1.gdata.de>
Thread-Topic: Build win-pv Error
Thread-Index: Ac4LcLCIOIcIVI1KT4qAm+pB4jGrfg==
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.215.12.96]
X-AVK-Virus-Check: AVA 22.7969;15.02.2013
Subject: [Xen-devel] Build win-pv 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: multipart/mixed; boundary="===============3921283788317877739=="
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.

--===============3921283788317877739==
Content-Language: de-DE
Content-Type: multipart/alternative;
	boundary="_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_"

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.

--_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi XEN-Community,

I'm trying to build the actual version of the XEN gplpv (win-pv) drivers.
I use the a Windows XP machine with the WinDDK 7600.16385.1 and Wix 3.0 like=
 suggested  in the BUILD.txt
The building process itself seems to be working, at least there are no compi=
ler error.  (I just made the "makedist")
Instead, the final *.msi files and the drivers itself are nowhere to be foun=
d, but they should be in the "target" directory.
It seems that some files are missing, which can be seen in the build output.=
=2E I've tried some day to figure it out, but I have no
idea where this files are, or why they are not where they should be.

So please help me! Thanks for your answers.

Greetings Stefan

OUTPUT OF THE BUILD PROCESS:

Das System kann den angegebenen Pfad nicht finden.
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:17:36 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objchk_wxp_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wxp_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wxp_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wxp_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objchk_wxp_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wxp_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wxp_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WINXP
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wxp_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:03 2013
BUILD: Done


    71 files compiled
    2 libraries built
    7 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:18:04 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objchk_wnet_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wnet_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wnet_x86\i386\xenvbd=
filter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objchk_wnet_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wnet_x86\i386\copyconfig.e=
xe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wnet_x86\i386\shutdownmo=
n.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wnet_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:14 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:18:15 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objchk_wnet_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wnet_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wnet_amd64\amd64\xen=
vbdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objchk_wnet_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wnet_amd64\amd64\copyconfi=
g.exe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wnet_amd64\amd64\shutdow=
nmon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wnet_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:36 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:18:37 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objchk_wlh_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wlh_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wlh_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objchk_wlh_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wlh_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wlh_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wlh_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:18:50 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:18:50 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objchk_wlh_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objchk_wlh_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objchk_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objchk_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objchk_wlh_amd64\amd64\xenv=
bdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objchk_wlh_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objchk_wlh_amd64\amd64\copyconfig=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objchk_wlh_amd64\amd64\shutdown=
mon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjchk_wlh_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:19:10 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
Das System kann den angegebenen Pfad nicht finden.
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:19:10 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WINXP
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objfre_wxp_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wxp_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wxp_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wxp_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WINXP
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objfre_wxp_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wxp_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WINXP
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wxp_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WINXP
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wxp_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:19:42 2013
BUILD: Done


    71 files compiled
    2 libraries built
    7 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:19:42 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objfre_wnet_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wnet_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wnet_x86\i386\xe=
nvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wnet_x86\i386\xenvbd=
filter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objfre_wnet_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wnet_x86\i386\copyconfig.e=
xe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wnet_x86\i386\shutdownmo=
n.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wnet_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:20:21 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:20:22 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
_NT_TARGET_VERSION SET TO WS03
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
_NT_TARGET_VERSION SET TO WS03
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objfre_wnet_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wnet_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wnet_amd64\amd64=
\xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wnet_amd64\amd64\xen=
vbdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
_NT_TARGET_VERSION SET TO WS03
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objfre_wnet_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
_NT_TARGET_VERSION SET TO WS03
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wnet_amd64\amd64\copyconfi=
g.exe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
_NT_TARGET_VERSION SET TO WS03
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wnet_amd64\amd64\shutdow=
nmon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
_NT_TARGET_VERSION SET TO WS03
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wnet_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:20:40 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for x86
BUILD: Start time: Fri Feb 15 12:20:40 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\generating code...
Building Library - liblfds.6\bin\i386\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\i386\tpr_emulate.asm
Assembling - xenpci\i386\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Compiling - xenpci\generating code...
Building Library - xenpci\xenpci\objfre_wlh_x86\i386\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wlh_x86\i386\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wlh_x86\i386\xen=
vbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wlh_x86\i386\xenvbdf=
ilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Compiling - xennet\generating code...
Linking Executable - xennet\xennet\objfre_wlh_x86\i386\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wlh_x86\i386\copyconfig.ex=
e
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wlh_x86\i386\shutdownmon=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wlh_x86\i386\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:20:52 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t
BUILD: Compile and Link for AMD64
BUILD: Start time: Fri Feb 15 12:20:53 2013
BUILD: Examining c:\win-pvdrivers directory tree for files to compile.
    c:\win-pvdrivers
    c:\win-pvdrivers\liblfds.6
    c:\win-pvdrivers\liblfds.6\src
    c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kernel
    c:\win-pvdrivers\xenpci
    c:\win-pvdrivers\xenvbd_scsiport
    c:\win-pvdrivers\xenvbd_storport
    c:\win-pvdrivers\xenvbd_filter
    c:\win-pvdrivers\xennet
    c:\win-pvdrivers\copyconfig
    c:\win-pvdrivers\shutdownmon
    c:\win-pvdrivers\waitnopendinginstallevents
BUILD: Building generated files in c:\win-pvdrivers\xenpci directory
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_scsiport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xenvbd_storport director=
y
BUILD: Building generated files in c:\win-pvdrivers\xennet directory
BUILD: Compiling c:\win-pvdrivers\liblfds.6\src\single_dir_for_windows_kerne=
l directory
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
free.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_aligned_=
malloc.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_cas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_dcas.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\abstraction_incremen=
t.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_get_and_set=
=2Ec
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_pop_push.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\freelist_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\queue_queue.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_get_and_p=
ut.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\ringbuffer_query.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_get_and_set.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_link.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\slist_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_delete.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_new.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_push_pop.c
Compiling - liblfds.6\src\single_dir_for_windows_kernel\stack_query.c
Building Library - liblfds.6\bin\amd64\liblfds.lib
BUILD: Compiling c:\win-pvdrivers\xenpci directory
Assembling - xenpci\amd64\hypercall.asm
Assembling - xenpci\amd64\dbgprint_hook.asm
Compiling - xenpci\xenpci.c
Compiling - xenpci\xenpci_fdo.c
Compiling - xenpci\xenpci_pdo.c
Compiling - xenpci\xenpci_export.c
Compiling - xenpci\evtchn.c
Compiling - xenpci\gnttbl.c
Compiling - xenpci\xenbus.c
Compiling - xenpci\memory.c
Compiling - xenpci\xenpci_device_interface.c
Compiling - xenpci\xenbus_device_interface.c
Compiling - xenpci\xenpci_highsync.c
Compiling - xenpci\xenpci_patch_kernel.c
Compiling - xenpci\xenpci_dbgprint.c
Building Library - xenpci\xenpci\objfre_wlh_amd64\amd64\xenpci.lib
BUILD: Linking for c:\win-pvdrivers\xenpci directory
Compiling resources - xenpci\xenpci.rc
Linking Executable - xenpci\xenpci\objfre_wlh_amd64\amd64\xenpci.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_scsiport directory
Compiling resources - xenvbd_scsiport\xenvbd.rc
Compiling - xenvbd_scsiport\xenvbd.c
Linking Executable - xenvbd_scsiport\xenvbd_scsiport\objfre_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_storport directory
Compiling resources - xenvbd_storport\xenvbd.rc
Compiling - xenvbd_storport\xenvbd.c
Linking Executable - xenvbd_storport\xenvbd_storport\objfre_wlh_amd64\amd64\=
xenvbd.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xenvbd_filter directory
Compiling resources - xenvbd_filter\xenvbd_filter.rc
Compiling - xenvbd_filter\xenvbd_filter.c
Linking Executable - xenvbd_filter\xenvbd_filter\objfre_wlh_amd64\amd64\xenv=
bdfilter.sys
BUILD: Compiling and Linking c:\win-pvdrivers\xennet directory
Compiling resources - xennet\xennet.rc
Compiling - xennet\xennet.c
Compiling - xennet\xennet_tx.c
Compiling - xennet\xennet_rx.c
Compiling - xennet\xennet_oid.c
Compiling - xennet\xennet_common.c
Linking Executable - xennet\xennet\objfre_wlh_amd64\amd64\xennet.sys
BUILD: Compiling and Linking c:\win-pvdrivers\copyconfig directory
Compiling - copyconfig\copyconfig.c
Linking Executable - copyconfig\copyconfig\objfre_wlh_amd64\amd64\copyconfig=
=2Eexe
BUILD: Compiling and Linking c:\win-pvdrivers\shutdownmon directory
Compiling - shutdownmon\shutdownmon.c
Linking Executable - shutdownmon\shutdownmon\objfre_wlh_amd64\amd64\shutdown=
mon.exe
BUILD: Compiling and Linking c:\win-pvdrivers\waitnopendinginstallevents dir=
ectory
Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c
Linking Executable - waitnopendinginstallevents\waitnopendinginstallevents\o=
bjfre_wlh_amd64\amd64\waitnopendinginstallevents.exe
BUILD: Finish time: Fri Feb 15 12:21:09 2013
BUILD: Done


    75 files compiled
    2 libraries built
    8 executables built
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t

____________
Virus checked by G Data AntiVirus
Version: AVA 22.7969 dated 15.02.2013
Virus news: www.antiviruslab.com
--_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_
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" x=
mlns: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 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0cm;
	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;}
span.E-MailFormatvorlage17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
=2E.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
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"DE" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi XEN-Community,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I&#8217;m trying to build the ac=
tual version of the XEN gplpv (win-pv) drivers.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I use the a Windows XP machine w=
ith the WinDDK 7600.16385.1 and Wix 3.0 like suggested &nbsp;in the BUILD.tx=
t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The building process itself seem=
s to be working, at least there are no compiler error. &nbsp;(I just made th=
e &#8220;makedist&#8221;)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Instead, the final *.msi files a=
nd the drivers itself are nowhere to be found, but they should be in the &#8=
220;target&#8221; directory.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">It seems that some files are mis=
sing, which can be seen in the build output. I&#8217;ve tried some day to fi=
gure it out, but I have no<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">idea where this files are, or wh=
y they are not where they should be.<o:p></o:p></span></p>
<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">So please help me! Thanks for yo=
ur answers.<o:p></o:p></span></p>
<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">Greetings Stefan<o:p></o:p></spa=
n></p>
<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">OUTPUT OF THE BUILD PROCESS:<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:17:36 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wxp_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wxp_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wxp_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wxp_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wxp_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wxp_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wxp_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wxp_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:03 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 71 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>7 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:04 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wnet_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wnet_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wnet_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wnet_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wnet_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wnet_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wnet_x86\i386\waitnopendin=
ginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:14 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:15 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wnet_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wnet_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wnet_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wnet_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wnet_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wnet_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wnet_amd64\amd64\waitnopen=
dinginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:36 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:37 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wlh_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wlh_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wlh_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wlh_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wlh_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wlh_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wlh_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:18:50 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:18:50 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objchk_wlh_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objchk_wlh_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objchk_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objchk_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objchk_wlh_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objchk_wlh_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objchk_wlh_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objchk_wlh_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objchk_wlh_amd64\amd64\waitnopend=
inginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:19:10 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:19:10 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wxp_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wxp_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wxp_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wxp_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wxp_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wxp_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wxp_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WINXP<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wxp_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:19:42 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 71 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>7 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:19:42 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wnet_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wnet_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wnet_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wnet_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wnet_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wnet_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wnet_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wnet_x86\i386\waitnopendin=
ginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:20:21 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:20:22 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wnet_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wnet_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wnet_amd64\amd64\xenvbd.sys<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wnet_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wnet_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wnet_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wnet_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">_NT_TARGET_VERSION SET TO WS03<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wnet_amd64\amd64\waitnopen=
dinginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:20:40 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for x86<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:20:40 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\generating code...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\i386\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\tpr_emu=
late.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\i386\dbgprin=
t_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wlh_x86\i386\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wlh_x86\i386\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wlh_x86\i386\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wlh_x86\i386\xenvbdfilter.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\generating co=
de...<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wlh_x86\i386\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wlh_x86\i386\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wlh_x86\i386\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wlh_x86\i386\waitnopending=
installevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:20:52 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compile and Link for AMD6=
4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Start time: Fri Feb 15 12=
:20:53 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Examining c:\win-pvdriver=
s directory tree for files to compile.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; c:\win-pvdriv=
ers <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6 <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\liblfds.6\src\single_dir_for_windows_kernel
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenpci <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_scsiport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_storport <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xenvbd_filter <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\xennet <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\copyconfig <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\shutdownmon <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;c:\win-p=
vdrivers\waitnopendinginstallevents
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Building generated files=
 in c:\win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\liblfds.6\src\single_dir_for_windows_kernel directory<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_free.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_aligned_malloc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_cas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_dcas.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\abstraction_increment.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_pop_push.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\freelist_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\queue_queue.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_get_and_put.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\ringbuffer_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_get_and_set.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_link.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\slist_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_delete.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_new.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_push_pop.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - liblfds.6\src\single=
_dir_for_windows_kernel\stack_query.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - liblfds.6\bin=
\amd64\liblfds.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling c:\win-pvdriver=
s\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\hyperc=
all.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Assembling - xenpci\amd64\dbgpri=
nt_hook.asm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_fdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_pdo.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_export=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\evtchn.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\gnttbl.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\memory.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenbus_device=
_interface.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_highsy=
nc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_patch_=
kernel.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenpci\xenpci_dbgpri=
nt.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Building Library - xenpci\xenpci=
\objfre_wlh_amd64\amd64\xenpci.lib<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Linking for c:\win-pvdriv=
ers\xenpci directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenpci\xen=
pci.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenpci\xenp=
ci\objfre_wlh_amd64\amd64\xenpci.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_scsiport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_scs=
iport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_scsiport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_scsi=
port\xenvbd_scsiport\objfre_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_storport directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_sto=
rport\xenvbd.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_storport\xenv=
bd.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_stor=
port\xenvbd_storport\objfre_wlh_amd64\amd64\xenvbd.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xenvbd_filter directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xenvbd_fil=
ter\xenvbd_filter.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xenvbd_filter\xenvbd=
_filter.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xenvbd_filt=
er\xenvbd_filter\objfre_wlh_amd64\amd64\xenvbdfilter.sys<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\xennet directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling resources - xennet\xen=
net.rc<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet.c<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_tx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_rx.c<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_oid.c<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - xennet\xennet_common=
=2Ec<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - xennet\xenn=
et\objfre_wlh_amd64\amd64\xennet.sys<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\copyconfig directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - copyconfig\copyconfi=
g.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - copyconfig\=
copyconfig\objfre_wlh_amd64\amd64\copyconfig.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\shutdownmon directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - shutdownmon\shutdown=
mon.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - shutdownmon=
\shutdownmon\objfre_wlh_amd64\amd64\shutdownmon.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Compiling and Linking c:\=
win-pvdrivers\waitnopendinginstallevents directory<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Compiling - waitnopendinginstall=
events\waitnopendinginstallevents.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Linking Executable - waitnopendi=
nginstallevents\waitnopendinginstallevents\objfre_wlh_amd64\amd64\waitnopend=
inginstallevents.exe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Finish time: Fri Feb 15 1=
2:21:09 2013<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">BUILD: Done<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 75 files comp=
iled<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; 2 libraries b=
uilt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp; </span>8 exec=
utables built<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal">Das System kann den angegebenen Pfad nicht finden.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">SignTool Error: File not found:=
 /t<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
</div>
<BR>
____________<BR>
Virus checked by G Data AntiVirus<BR>
Version: AVA 22.7969 dated 15.02.2013<BR>
Virus news: <a href=3D"http://www.antiviruslab.com">www.antiviruslab.com</a>=
<BR>
</body>
</html>
--_000_09ED90B020890C46AC23A0F84475B37F0E98B6A5e1gdatade_--



--===============3921283788317877739==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3921283788317877739==--



From xen-devel-bounces@lists.xen.org Fri Feb 15 11:43:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:43: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 1U6Jgx-0005xH-Nw; Fri, 15 Feb 2013 11:42:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U6Jgv-0005ww-Av; Fri, 15 Feb 2013 11:42:57 +0000
Received: from [85.158.138.51:23424] by server-3.bemta-3.messagelabs.com id
	CF/2C-31070-04F1E115; Fri, 15 Feb 2013 11:42:56 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360928487!19616301!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10916 invoked from network); 15 Feb 2013 11:41:30 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Feb 2013 11:41:30 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U6JfM-0001hk-PT; Fri, 15 Feb 2013 11:41:20 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U6JfM-0003Qu-0l; Fri, 15 Feb 2013 11:41:20 +0000
Date: Fri, 15 Feb 2013 11:41:20 +0000
Message-Id: <E1U6JfM-0003Qu-0l@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 38 (CVE-2013-0215) - oxenstored
 incorrect handling of certain Xenbus ring 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

         Xen Security Advisory CVE-2013-0215 / XSA-38
			      version 3

    oxenstored incorrect handling of certain Xenbus ring states

UPDATES IN VERSION 3
====================

The patch supplied contained an error which would cause a failure when
the ring became full. An updated patch is attached. The incremental
fix can be found at:
    http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/759574df84a6

ISSUE DESCRIPTION
=================

The oxenstored daemon (the ocaml version of the xenstore daemon) does
not correctly handle unusual or malicious contents in the xenstore
ring.  A malicious guest can exploit this to cause oxenstored to read
past the end of the ring (and very likely crash) or to allocate large
amounts of RAM.

IMPACT
======

A malicious guest administrator can mount a denial of service attack
affecting domain control and management functions.

In more detail:

A malicious guest administrator can cause oxenstored to crash; after
this many host control operations (for example, starting and stopping
domains, device hotplug, and some monitoring functions), will be
unavailable.  Domains which are already running are not directly
affected.

Such an attacker can also cause a memory exhaustion in the domain
running oxenstored; often this will make the host's management
functions unavailable.

Information leak of control plane data is also theoretically possible.

VULNERABLE SYSTEMS
==================

Any system running oxenstored is vulnerable. oxenstored was introduced
in Xen version 4.1.

oxenstored was made the default in Xen 4.2.if a suitable ocaml
toolchain was installed at build time.

Systems running a 32-bit oxenstored are vulnerable only to the crash
and not to the large memory allocation issue.

MITIGATION
==========

Running the C version of xenstored will avoid this issue.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa38.patch             Xen 4.1.x, Xen 4.2.x, xen-unstable

$ sha256sum xsa38*.patch
9912d3239a6f784418fcec53fad7c316588a421e352462f661cd1070fcf21d4b  xsa38.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRHh6yAAoJEIP+FMlX6CvZekUH/AsBw9dg8t2QLsPd391zxX6C
XUJGW616979+tVCGVr+ahyRKnE2T598LBD+Vojvi7/jL+k59/j48jOkJIen9NfV6
aawnCrDWICa1Hq4/7xoj1ZagmdQuRuESbdsV6VbzF7v6eBybzKHjhFLNg2cSw6YB
Zhay6tqpQGQIZrqWZla0OzNf34gWFZAnD4SL3CzlQaMlUb4gab1qprb2kOHttfcK
wlPxy+U3CPppiRHR5Zs9RmGqnRCA9YpZF2JjxuunrZhFtvY1v+udLCiMkdUGblss
tKimBDyxC1Qlthye6MTVftvRSsmBmhRJV7R9Wia3s7iAW4KASeobxS+4wicbcHM=
=GBLo
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa38.patch"
Content-Disposition: attachment; filename="xsa38.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbCBi
L3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbAppbmRleCAzNTU4ODg5
Li5kNGQxYzdiIDEwMDY0NAotLS0gYS90b29scy9vY2FtbC9saWJzL3hiL3Bh
cnRpYWwubWwKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi9wYXJ0aWFsLm1s
CkBAIC0yNyw4ICsyNywxNSBAQCBleHRlcm5hbCBoZWFkZXJfc2l6ZTogdW5p
dCAtPiBpbnQgPSAic3R1Yl9oZWFkZXJfc2l6ZSIKIGV4dGVybmFsIGhlYWRl
cl9vZl9zdHJpbmdfaW50ZXJuYWw6IHN0cmluZyAtPiBpbnQgKiBpbnQgKiBp
bnQgKiBpbnQKICAgICAgICAgID0gInN0dWJfaGVhZGVyX29mX3N0cmluZyIK
IAorbGV0IHhlbnN0b3JlX3BheWxvYWRfbWF4ID0gNDA5NiAoKiB4ZW4vaW5j
bHVkZS9wdWJsaWMvaW8veHNfd2lyZS5oICopCisKIGxldCBvZl9zdHJpbmcg
cyA9CiAJbGV0IHRpZCwgcmlkLCBvcGludCwgZGxlbiA9IGhlYWRlcl9vZl9z
dHJpbmdfaW50ZXJuYWwgcyBpbgorCSgqIEEgcGFja2V0IHdoaWNoIGlzIGJp
Z2dlciB0aGFuIHhlbnN0b3JlX3BheWxvYWRfbWF4IGlzIGlsbGVnYWwuCisJ
ICAgVGhpcyB3aWxsIGxlYXZlIHRoZSBndWVzdCBjb25uZWN0aW9uIGlzIGEg
YmFkIHN0YXRlIGFuZCB3aWxsCisJICAgYmUgaGFyZCB0byByZWNvdmVyIGZy
b20gd2l0aG91dCByZXN0YXJ0aW5nIHRoZSBjb25uZWN0aW9uCisJICAgKGll
IHJlYm9vdGluZyB0aGUgZ3Vlc3QpICopCisJbGV0IGRsZW4gPSBtaW4geGVu
c3RvcmVfcGF5bG9hZF9tYXggZGxlbiBpbgogCXsKIAkJdGlkID0gdGlkOwog
CQlyaWQgPSByaWQ7CkBAIC0zOCw2ICs0NSw3IEBAIGxldCBvZl9zdHJpbmcg
cyA9CiAJfQogCiBsZXQgYXBwZW5kIHBrdCBzIHN6ID0KKwlpZiBwa3QubGVu
ID4gNDA5NiB0aGVuIGZhaWx3aXRoICJCdWZmZXIuYWRkOiBjYW5ub3QgZ3Jv
dyBidWZmZXIiOwogCUJ1ZmZlci5hZGRfc3RyaW5nIHBrdC5idWYgKFN0cmlu
Zy5zdWIgcyAwIHN6KQogCiBsZXQgdG9fY29tcGxldGUgcGt0ID0KZGlmZiAt
LWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIveHNfcmluZ19zdHVicy5jIGIv
dG9vbHMvb2NhbWwvbGlicy94Yi94c19yaW5nX3N0dWJzLmMKaW5kZXggMDA0
MTRjNS4uNDg4OGFjNSAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwvbGlicy94
Yi94c19yaW5nX3N0dWJzLmMKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi94
c19yaW5nX3N0dWJzLmMKQEAgLTM5LDIxICszOSwyMyBAQCBzdGF0aWMgaW50
IHhzX3JpbmdfcmVhZChzdHJ1Y3QgbW1hcF9pbnRlcmZhY2UgKmludGVyZmFj
ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqYnVmZmVy
LCBpbnQgbGVuKQogewogCXN0cnVjdCB4ZW5zdG9yZV9kb21haW5faW50ZXJm
YWNlICppbnRmID0gaW50ZXJmYWNlLT5hZGRyOwotCVhFTlNUT1JFX1JJTkdf
SURYIGNvbnMsIHByb2Q7CisJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJv
ZDsgLyogb2Zmc2V0cyBvbmx5ICovCiAJaW50IHRvX3JlYWQ7CiAKLQljb25z
ID0gaW50Zi0+cmVxX2NvbnM7Ci0JcHJvZCA9IGludGYtPnJlcV9wcm9kOwor
CWNvbnMgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9jb25zOwor
CXByb2QgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9wcm9kOwog
CXhlbl9tYigpOwogCWlmIChwcm9kID09IGNvbnMpCiAJCXJldHVybiAwOwot
CWlmIChNQVNLX1hFTlNUT1JFX0lEWChwcm9kKSA+IE1BU0tfWEVOU1RPUkVf
SURYKGNvbnMpKSAKKwljb25zID0gTUFTS19YRU5TVE9SRV9JRFgoY29ucyk7
CisJcHJvZCA9IE1BU0tfWEVOU1RPUkVfSURYKHByb2QpOworCWlmIChwcm9k
ID4gY29ucykKIAkJdG9fcmVhZCA9IHByb2QgLSBjb25zOwogCWVsc2UKLQkJ
dG9fcmVhZCA9IFhFTlNUT1JFX1JJTkdfU0laRSAtIE1BU0tfWEVOU1RPUkVf
SURYKGNvbnMpOworCQl0b19yZWFkID0gWEVOU1RPUkVfUklOR19TSVpFIC0g
Y29uczsKIAlpZiAodG9fcmVhZCA8IGxlbikKIAkJbGVuID0gdG9fcmVhZDsK
LQltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBNQVNLX1hFTlNUT1JFX0lE
WChjb25zKSwgbGVuKTsKKwltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBj
b25zLCBsZW4pOwogCXhlbl9tYigpOwogCWludGYtPnJlcV9jb25zICs9IGxl
bjsKIAlyZXR1cm4gbGVuOwpAQCAtNjYsOCArNjgsOCBAQCBzdGF0aWMgaW50
IHhzX3Jpbmdfd3JpdGUoc3RydWN0IG1tYXBfaW50ZXJmYWNlICppbnRlcmZh
Y2UsCiAJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJvZDsKIAlpbnQgY2Fu
X3dyaXRlOwogCi0JY29ucyA9IGludGYtPnJzcF9jb25zOwotCXByb2QgPSBp
bnRmLT5yc3BfcHJvZDsKKwljb25zID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfY29uczsKKwlwcm9kID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfcHJvZDsKIAl4ZW5fbWIoKTsKIAlpZiAoIChwcm9kIC0gY29u
cykgPj0gWEVOU1RPUkVfUklOR19TSVpFICkKIAkJcmV0dXJuIDA7Cg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Feb 15 11:43:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:43: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 1U6Jgx-0005xH-Nw; Fri, 15 Feb 2013 11:42:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U6Jgv-0005ww-Av; Fri, 15 Feb 2013 11:42:57 +0000
Received: from [85.158.138.51:23424] by server-3.bemta-3.messagelabs.com id
	CF/2C-31070-04F1E115; Fri, 15 Feb 2013 11:42:56 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360928487!19616301!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10916 invoked from network); 15 Feb 2013 11:41:30 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Feb 2013 11:41:30 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U6JfM-0001hk-PT; Fri, 15 Feb 2013 11:41:20 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U6JfM-0003Qu-0l; Fri, 15 Feb 2013 11:41:20 +0000
Date: Fri, 15 Feb 2013 11:41:20 +0000
Message-Id: <E1U6JfM-0003Qu-0l@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 38 (CVE-2013-0215) - oxenstored
 incorrect handling of certain Xenbus ring 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

         Xen Security Advisory CVE-2013-0215 / XSA-38
			      version 3

    oxenstored incorrect handling of certain Xenbus ring states

UPDATES IN VERSION 3
====================

The patch supplied contained an error which would cause a failure when
the ring became full. An updated patch is attached. The incremental
fix can be found at:
    http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/759574df84a6

ISSUE DESCRIPTION
=================

The oxenstored daemon (the ocaml version of the xenstore daemon) does
not correctly handle unusual or malicious contents in the xenstore
ring.  A malicious guest can exploit this to cause oxenstored to read
past the end of the ring (and very likely crash) or to allocate large
amounts of RAM.

IMPACT
======

A malicious guest administrator can mount a denial of service attack
affecting domain control and management functions.

In more detail:

A malicious guest administrator can cause oxenstored to crash; after
this many host control operations (for example, starting and stopping
domains, device hotplug, and some monitoring functions), will be
unavailable.  Domains which are already running are not directly
affected.

Such an attacker can also cause a memory exhaustion in the domain
running oxenstored; often this will make the host's management
functions unavailable.

Information leak of control plane data is also theoretically possible.

VULNERABLE SYSTEMS
==================

Any system running oxenstored is vulnerable. oxenstored was introduced
in Xen version 4.1.

oxenstored was made the default in Xen 4.2.if a suitable ocaml
toolchain was installed at build time.

Systems running a 32-bit oxenstored are vulnerable only to the crash
and not to the large memory allocation issue.

MITIGATION
==========

Running the C version of xenstored will avoid this issue.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa38.patch             Xen 4.1.x, Xen 4.2.x, xen-unstable

$ sha256sum xsa38*.patch
9912d3239a6f784418fcec53fad7c316588a421e352462f661cd1070fcf21d4b  xsa38.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRHh6yAAoJEIP+FMlX6CvZekUH/AsBw9dg8t2QLsPd391zxX6C
XUJGW616979+tVCGVr+ahyRKnE2T598LBD+Vojvi7/jL+k59/j48jOkJIen9NfV6
aawnCrDWICa1Hq4/7xoj1ZagmdQuRuESbdsV6VbzF7v6eBybzKHjhFLNg2cSw6YB
Zhay6tqpQGQIZrqWZla0OzNf34gWFZAnD4SL3CzlQaMlUb4gab1qprb2kOHttfcK
wlPxy+U3CPppiRHR5Zs9RmGqnRCA9YpZF2JjxuunrZhFtvY1v+udLCiMkdUGblss
tKimBDyxC1Qlthye6MTVftvRSsmBmhRJV7R9Wia3s7iAW4KASeobxS+4wicbcHM=
=GBLo
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa38.patch"
Content-Disposition: attachment; filename="xsa38.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbCBi
L3Rvb2xzL29jYW1sL2xpYnMveGIvcGFydGlhbC5tbAppbmRleCAzNTU4ODg5
Li5kNGQxYzdiIDEwMDY0NAotLS0gYS90b29scy9vY2FtbC9saWJzL3hiL3Bh
cnRpYWwubWwKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi9wYXJ0aWFsLm1s
CkBAIC0yNyw4ICsyNywxNSBAQCBleHRlcm5hbCBoZWFkZXJfc2l6ZTogdW5p
dCAtPiBpbnQgPSAic3R1Yl9oZWFkZXJfc2l6ZSIKIGV4dGVybmFsIGhlYWRl
cl9vZl9zdHJpbmdfaW50ZXJuYWw6IHN0cmluZyAtPiBpbnQgKiBpbnQgKiBp
bnQgKiBpbnQKICAgICAgICAgID0gInN0dWJfaGVhZGVyX29mX3N0cmluZyIK
IAorbGV0IHhlbnN0b3JlX3BheWxvYWRfbWF4ID0gNDA5NiAoKiB4ZW4vaW5j
bHVkZS9wdWJsaWMvaW8veHNfd2lyZS5oICopCisKIGxldCBvZl9zdHJpbmcg
cyA9CiAJbGV0IHRpZCwgcmlkLCBvcGludCwgZGxlbiA9IGhlYWRlcl9vZl9z
dHJpbmdfaW50ZXJuYWwgcyBpbgorCSgqIEEgcGFja2V0IHdoaWNoIGlzIGJp
Z2dlciB0aGFuIHhlbnN0b3JlX3BheWxvYWRfbWF4IGlzIGlsbGVnYWwuCisJ
ICAgVGhpcyB3aWxsIGxlYXZlIHRoZSBndWVzdCBjb25uZWN0aW9uIGlzIGEg
YmFkIHN0YXRlIGFuZCB3aWxsCisJICAgYmUgaGFyZCB0byByZWNvdmVyIGZy
b20gd2l0aG91dCByZXN0YXJ0aW5nIHRoZSBjb25uZWN0aW9uCisJICAgKGll
IHJlYm9vdGluZyB0aGUgZ3Vlc3QpICopCisJbGV0IGRsZW4gPSBtaW4geGVu
c3RvcmVfcGF5bG9hZF9tYXggZGxlbiBpbgogCXsKIAkJdGlkID0gdGlkOwog
CQlyaWQgPSByaWQ7CkBAIC0zOCw2ICs0NSw3IEBAIGxldCBvZl9zdHJpbmcg
cyA9CiAJfQogCiBsZXQgYXBwZW5kIHBrdCBzIHN6ID0KKwlpZiBwa3QubGVu
ID4gNDA5NiB0aGVuIGZhaWx3aXRoICJCdWZmZXIuYWRkOiBjYW5ub3QgZ3Jv
dyBidWZmZXIiOwogCUJ1ZmZlci5hZGRfc3RyaW5nIHBrdC5idWYgKFN0cmlu
Zy5zdWIgcyAwIHN6KQogCiBsZXQgdG9fY29tcGxldGUgcGt0ID0KZGlmZiAt
LWdpdCBhL3Rvb2xzL29jYW1sL2xpYnMveGIveHNfcmluZ19zdHVicy5jIGIv
dG9vbHMvb2NhbWwvbGlicy94Yi94c19yaW5nX3N0dWJzLmMKaW5kZXggMDA0
MTRjNS4uNDg4OGFjNSAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwvbGlicy94
Yi94c19yaW5nX3N0dWJzLmMKKysrIGIvdG9vbHMvb2NhbWwvbGlicy94Yi94
c19yaW5nX3N0dWJzLmMKQEAgLTM5LDIxICszOSwyMyBAQCBzdGF0aWMgaW50
IHhzX3JpbmdfcmVhZChzdHJ1Y3QgbW1hcF9pbnRlcmZhY2UgKmludGVyZmFj
ZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqYnVmZmVy
LCBpbnQgbGVuKQogewogCXN0cnVjdCB4ZW5zdG9yZV9kb21haW5faW50ZXJm
YWNlICppbnRmID0gaW50ZXJmYWNlLT5hZGRyOwotCVhFTlNUT1JFX1JJTkdf
SURYIGNvbnMsIHByb2Q7CisJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJv
ZDsgLyogb2Zmc2V0cyBvbmx5ICovCiAJaW50IHRvX3JlYWQ7CiAKLQljb25z
ID0gaW50Zi0+cmVxX2NvbnM7Ci0JcHJvZCA9IGludGYtPnJlcV9wcm9kOwor
CWNvbnMgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9jb25zOwor
CXByb2QgPSAqKHZvbGF0aWxlIHVpbnQzMiopJmludGYtPnJlcV9wcm9kOwog
CXhlbl9tYigpOwogCWlmIChwcm9kID09IGNvbnMpCiAJCXJldHVybiAwOwot
CWlmIChNQVNLX1hFTlNUT1JFX0lEWChwcm9kKSA+IE1BU0tfWEVOU1RPUkVf
SURYKGNvbnMpKSAKKwljb25zID0gTUFTS19YRU5TVE9SRV9JRFgoY29ucyk7
CisJcHJvZCA9IE1BU0tfWEVOU1RPUkVfSURYKHByb2QpOworCWlmIChwcm9k
ID4gY29ucykKIAkJdG9fcmVhZCA9IHByb2QgLSBjb25zOwogCWVsc2UKLQkJ
dG9fcmVhZCA9IFhFTlNUT1JFX1JJTkdfU0laRSAtIE1BU0tfWEVOU1RPUkVf
SURYKGNvbnMpOworCQl0b19yZWFkID0gWEVOU1RPUkVfUklOR19TSVpFIC0g
Y29uczsKIAlpZiAodG9fcmVhZCA8IGxlbikKIAkJbGVuID0gdG9fcmVhZDsK
LQltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBNQVNLX1hFTlNUT1JFX0lE
WChjb25zKSwgbGVuKTsKKwltZW1jcHkoYnVmZmVyLCBpbnRmLT5yZXEgKyBj
b25zLCBsZW4pOwogCXhlbl9tYigpOwogCWludGYtPnJlcV9jb25zICs9IGxl
bjsKIAlyZXR1cm4gbGVuOwpAQCAtNjYsOCArNjgsOCBAQCBzdGF0aWMgaW50
IHhzX3Jpbmdfd3JpdGUoc3RydWN0IG1tYXBfaW50ZXJmYWNlICppbnRlcmZh
Y2UsCiAJWEVOU1RPUkVfUklOR19JRFggY29ucywgcHJvZDsKIAlpbnQgY2Fu
X3dyaXRlOwogCi0JY29ucyA9IGludGYtPnJzcF9jb25zOwotCXByb2QgPSBp
bnRmLT5yc3BfcHJvZDsKKwljb25zID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfY29uczsKKwlwcm9kID0gKih2b2xhdGlsZSB1aW50MzIqKSZp
bnRmLT5yc3BfcHJvZDsKIAl4ZW5fbWIoKTsKIAlpZiAoIChwcm9kIC0gY29u
cykgPj0gWEVOU1RPUkVfUklOR19TSVpFICkKIAkJcmV0dXJuIDA7Cg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Feb 15 11:51:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:51: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 1U6JpP-0006ib-KZ; Fri, 15 Feb 2013 11:51:43 +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 1U6JpO-0006iT-Si
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:51:43 +0000
Received: from [85.158.139.83:28102] by server-11.bemta-5.messagelabs.com id
	24/B2-19159-E412E115; Fri, 15 Feb 2013 11:51:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360929101!20092843!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21347 invoked from network); 15 Feb 2013 11:51:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 11:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1510629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 11:51: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.297.1; Fri, 15 Feb 2013 11:51:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6JpN-0004a3-5g; Fri, 15 Feb 2013 11:51:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6JpM-0000Xi-VJ;
	Fri, 15 Feb 2013 11:51:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.8524.812473.78604@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 11:51:40 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360920378.31407.9.camel@zakaz.uk.xensource.com>
References: <CD43AA1B.5B046%keir@xen.org>
	<1360919461.31407.7.camel@zakaz.uk.xensource.com>
	<1360920378.31407.9.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/ocaml: oxenstored: correctly handle a full ring."):
> > On Fri, 2013-02-15 at 09:02 +0000, Keir Fraser wrote:
> > > Who are you looking for an Ack from? The patch makes pefect sense to me so
> > > you can have mine if you want it.
> > > 
> > > Acked-by: Keir Fraser <keir@xen.org>
> 
> Committed, thanks.
> 
> Ian: Can you backport 26539:759574df84a6 to everywhere the original
> patches went please.

Done.  Sorry for making this mess.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:51:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:51: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 1U6JpP-0006ib-KZ; Fri, 15 Feb 2013 11:51:43 +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 1U6JpO-0006iT-Si
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:51:43 +0000
Received: from [85.158.139.83:28102] by server-11.bemta-5.messagelabs.com id
	24/B2-19159-E412E115; Fri, 15 Feb 2013 11:51:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360929101!20092843!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21347 invoked from network); 15 Feb 2013 11:51:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 11:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1510629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 11:51: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.297.1; Fri, 15 Feb 2013 11:51:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6JpN-0004a3-5g; Fri, 15 Feb 2013 11:51:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6JpM-0000Xi-VJ;
	Fri, 15 Feb 2013 11:51:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.8524.812473.78604@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 11:51:40 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360920378.31407.9.camel@zakaz.uk.xensource.com>
References: <CD43AA1B.5B046%keir@xen.org>
	<1360919461.31407.7.camel@zakaz.uk.xensource.com>
	<1360920378.31407.9.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools/ocaml: oxenstored: correctly handle a
 full ring.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/ocaml: oxenstored: correctly handle a full ring."):
> > On Fri, 2013-02-15 at 09:02 +0000, Keir Fraser wrote:
> > > Who are you looking for an Ack from? The patch makes pefect sense to me so
> > > you can have mine if you want it.
> > > 
> > > Acked-by: Keir Fraser <keir@xen.org>
> 
> Committed, thanks.
> 
> Ian: Can you backport 26539:759574df84a6 to everywhere the original
> patches went please.

Done.  Sorry for making this mess.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:58:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:58: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 1U6JvT-00074H-Ix; Fri, 15 Feb 2013 11:57:59 +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 1U6JvR-00074A-Nn
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:57:57 +0000
Received: from [85.158.139.83:63157] by server-3.bemta-5.messagelabs.com id
	20/46-07037-5C22E115; Fri, 15 Feb 2013 11:57:57 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360929472!27439961!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9138 invoked from network); 15 Feb 2013 11:57:55 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Feb 2013 11:57:55 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U6JvG-0002Hy-IC; Fri, 15 Feb 2013 22:57:46 +1100
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 id
	14.01.0438.000; Fri, 15 Feb 2013 22:57:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "Stefan.Hausotte@gdata.de" <Stefan.Hausotte@gdata.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Build win-pv Error
Thread-Index: Ac4LcLCIOIcIVI1KT4qAm+pB4jGrfgAAkmaQ
Date: Fri, 15 Feb 2013 11:57:45 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567A47B@BITCOM1.int.sbss.com.au>
References: <09ED90B020890C46AC23A0F84475B37F0E98B6A5@e1.gdata.de>
In-Reply-To: <09ED90B020890C46AC23A0F84475B37F0E98B6A5@e1.gdata.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19638.005
x-tm-as-result: No--32.549700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] Build win-pv 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

> 
> I'm trying to build the actual version of the XEN gplpv (win-pv) drivers.
> 
> I use the a Windows XP machine with the WinDDK 7600.16385.1 and Wix 3.0
> like suggested  in the BUILD.txt
> 
> The building process itself seems to be working, at least there are no
> compiler error.  (I just made the "makedist")
> 
> Instead, the final *.msi files and the drivers itself are nowhere to be found,
> but they should be in the "target" directory.
> 
> It seems that some files are missing, which can be seen in the build output.
> I've tried some day to figure it out, but I have no
> 
> idea where this files are, or why they are not where they should be.
> 

What is the English translation of this:

Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t

It can't sign the files and so can't proceed to create the msi etc, but I don't know german so I don't know what that text says and if it's important or not.

The sign.bat file which is called by makedist.bat first loads a file called sign_config.bat, which should contain something like:

SET CERT_FILENAME=GPLPV_Test_Cert.pfx
SET CERT_PASSWORD=password
SET CERT_CROSS_CERT_FILENAME=
SET CERT_PUBLIC_FILENAME=GPLPV_Test_Cert.cer

Does this file exist on your build computer?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:58:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:58: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 1U6JvT-00074H-Ix; Fri, 15 Feb 2013 11:57:59 +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 1U6JvR-00074A-Nn
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:57:57 +0000
Received: from [85.158.139.83:63157] by server-3.bemta-5.messagelabs.com id
	20/46-07037-5C22E115; Fri, 15 Feb 2013 11:57:57 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-182.messagelabs.com!1360929472!27439961!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9138 invoked from network); 15 Feb 2013 11:57:55 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Feb 2013 11:57:55 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U6JvG-0002Hy-IC; Fri, 15 Feb 2013 22:57:46 +1100
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 id
	14.01.0438.000; Fri, 15 Feb 2013 22:57:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "Stefan.Hausotte@gdata.de" <Stefan.Hausotte@gdata.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Build win-pv Error
Thread-Index: Ac4LcLCIOIcIVI1KT4qAm+pB4jGrfgAAkmaQ
Date: Fri, 15 Feb 2013 11:57:45 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567A47B@BITCOM1.int.sbss.com.au>
References: <09ED90B020890C46AC23A0F84475B37F0E98B6A5@e1.gdata.de>
In-Reply-To: <09ED90B020890C46AC23A0F84475B37F0E98B6A5@e1.gdata.de>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19638.005
x-tm-as-result: No--32.549700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] Build win-pv 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

> 
> I'm trying to build the actual version of the XEN gplpv (win-pv) drivers.
> 
> I use the a Windows XP machine with the WinDDK 7600.16385.1 and Wix 3.0
> like suggested  in the BUILD.txt
> 
> The building process itself seems to be working, at least there are no
> compiler error.  (I just made the "makedist")
> 
> Instead, the final *.msi files and the drivers itself are nowhere to be found,
> but they should be in the "target" directory.
> 
> It seems that some files are missing, which can be seen in the build output.
> I've tried some day to figure it out, but I have no
> 
> idea where this files are, or why they are not where they should be.
> 

What is the English translation of this:

Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
SignTool Error: File not found: /t

It can't sign the files and so can't proceed to create the msi etc, but I don't know german so I don't know what that text says and if it's important or not.

The sign.bat file which is called by makedist.bat first loads a file called sign_config.bat, which should contain something like:

SET CERT_FILENAME=GPLPV_Test_Cert.pfx
SET CERT_PASSWORD=password
SET CERT_CROSS_CERT_FILENAME=
SET CERT_PUBLIC_FILENAME=GPLPV_Test_Cert.cer

Does this file exist on your build computer?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 11:59:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:59: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 1U6JwE-00077L-1r; Fri, 15 Feb 2013 11:58:46 +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 1U6JwC-00077A-E6
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:58:44 +0000
Received: from [193.109.254.147:38891] by server-10.bemta-14.messagelabs.com
	id D1/99-12679-3F22E115; Fri, 15 Feb 2013 11:58:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360929521!1717427!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28330 invoked from network); 15 Feb 2013 11:58:42 -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;
	15 Feb 2013 11:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7293620"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 11:58:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 06:58:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6Jw8-0001Ut-H4;
	Fri, 15 Feb 2013 11:58:40 +0000
Date: Fri, 15 Feb 2013 11:58:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360857591-24979-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151158070.8231@kaball.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
	<1360857591-24979-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  tools/include/xen-foreign/mkheader.py |    4 +++-
>  xen/include/public/xen.h              |    8 ++++----
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index eee28f3..e3e61f3 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,17 +21,18 @@ inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
>  };
>  header["arm32"] = """
>  #define __arm___ARM32 1
>  """;
>  
> -
>  # x86_32
>  inttypes["x86_32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint32_t",
> +    "xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -46,6 +47,7 @@ inttypes["x86_64"] = {
>      "unsigned long" : "__align8__ uint64_t",
>      "long"          : "__align8__ uint64_t",
>      "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>      /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>       */
>      uint8_t evtchn_upcall_pending;
>      uint8_t evtchn_upcall_mask;
> -    unsigned long evtchn_pending_sel;
> +    xen_ulong_t evtchn_pending_sel;
>      struct arch_vcpu_info arch;
>      struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>       * per-vcpu selector word to be set. Each bit in the selector covers a
>       * 'C long' in the PENDING bitfield array.
>       */
> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>      /*
>       * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.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 Feb 15 11:59:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 11:59: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 1U6JwE-00077L-1r; Fri, 15 Feb 2013 11:58:46 +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 1U6JwC-00077A-E6
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 11:58:44 +0000
Received: from [193.109.254.147:38891] by server-10.bemta-14.messagelabs.com
	id D1/99-12679-3F22E115; Fri, 15 Feb 2013 11:58:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1360929521!1717427!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28330 invoked from network); 15 Feb 2013 11:58:42 -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;
	15 Feb 2013 11:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7293620"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 11:58:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 06:58:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6Jw8-0001Ut-H4;
	Fri, 15 Feb 2013 11:58:40 +0000
Date: Fri, 15 Feb 2013 11:58:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360857591-24979-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151158070.8231@kaball.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
	<1360857591-24979-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  tools/include/xen-foreign/mkheader.py |    4 +++-
>  xen/include/public/xen.h              |    8 ++++----
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index eee28f3..e3e61f3 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,17 +21,18 @@ inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
>  };
>  header["arm32"] = """
>  #define __arm___ARM32 1
>  """;
>  
> -
>  # x86_32
>  inttypes["x86_32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint32_t",
> +    "xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -46,6 +47,7 @@ inttypes["x86_64"] = {
>      "unsigned long" : "__align8__ uint64_t",
>      "long"          : "__align8__ uint64_t",
>      "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>      /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>       */
>      uint8_t evtchn_upcall_pending;
>      uint8_t evtchn_upcall_mask;
> -    unsigned long evtchn_pending_sel;
> +    xen_ulong_t evtchn_pending_sel;
>      struct arch_vcpu_info arch;
>      struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>       * per-vcpu selector word to be set. Each bit in the selector covers a
>       * 'C long' in the PENDING bitfield array.
>       */
> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>      /*
>       * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.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 Feb 15 12:09:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6K69-0007oj-Bl; Fri, 15 Feb 2013 12:09: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 1U6K68-0007oe-4h
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:09:00 +0000
Received: from [85.158.143.35:27138] by server-3.bemta-4.messagelabs.com id
	EC/4D-08920-B552E115; Fri, 15 Feb 2013 12:08:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360930137!4786043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27307 invoked from network); 15 Feb 2013 12:08:58 -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;
	15 Feb 2013 12:08:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7666985"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:08:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:08:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6K64-0001eV-9L;
	Fri, 15 Feb 2013 12:08:56 +0000
Date: Fri, 15 Feb 2013 12:08:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> ARM has no start info. Although it does not existing in the hypervisor ABI we
> synthesize one for the benefit of the common code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/arm/include/asm/xen/interface.h |   24 +++++++++++++++++++++++
>  arch/x86/include/asm/xen/interface.h |   35 ++++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h          |   33 --------------------------------
>  3 files changed, 59 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 1151188..1db40d5 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
> +/*
> + * On ARM this is not part of the hypervisor ABI but we provide it
> + * internally for the benefit of common code.
> + */
> +struct start_info {
> +        uint32_t flags;             /* SIF_xxx flags.                         */
> +        uint32_t store_evtchn;      /* Event channel for store communication. */
> +        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> +        union {
> +                struct {
> +                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> +                        uint32_t  evtchn;   /* Event channel for console page.        */
> +                } domU;
> +                struct {
> +                        uint32_t info_off;  /* Offset of console_info struct.         */
> +                        uint32_t info_size; /* Size of console_info struct from start.*/
> +                } dom0;
> +        } console;
> +	/* UNUSED ON ARM */
> +        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> +};
> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> +
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
>  
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index fd9cb76..ca9a203 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -131,6 +131,41 @@ struct arch_shared_info {
>  #include <asm/pvclock-abi.h>
>  
>  #ifndef __ASSEMBLY__
> +
> +
> +#define MAX_GUEST_CMDLINE 1024
> +struct start_info {
> +    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> +    char magic[32];             /* "xen-<version>-<platform>".            */
> +    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> +    unsigned long shared_info;  /* MACHINE address of shared info struct. */
> +    uint32_t flags;             /* SIF_xxx flags.                         */
> +    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> +    uint32_t store_evtchn;      /* Event channel for store communication. */
> +    union {
> +        struct {
> +            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> +            uint32_t  evtchn;   /* Event channel for console page.        */
> +        } domU;
> +        struct {
> +            uint32_t info_off;  /* Offset of console_info struct.         */
> +            uint32_t info_size; /* Size of console_info struct from start.*/
> +        } dom0;
> +    } console;
> +    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
> +    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
> +    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
> +    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
> +    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
> +    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> +    int8_t cmd_line[MAX_GUEST_CMDLINE];
> +};
> +
> +/* These flags are passed in the 'flags' field of start_info_t. */
> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> +#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
> +
>  /*
>   * The following is all CPU context. Note that the fpu_ctxt block is filled
>   * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 53ec416..a9075df 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -422,34 +422,6 @@ struct shared_info {
>   *     extended by an extra 4MB to ensure this.
>   */
>  
> -#define MAX_GUEST_CMDLINE 1024
> -struct start_info {
> -	/* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> -	char magic[32];             /* "xen-<version>-<platform>".            */
> -	unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> -	unsigned long shared_info;  /* MACHINE address of shared info struct. */
> -	uint32_t flags;             /* SIF_xxx flags.                         */
> -	xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> -	uint32_t store_evtchn;      /* Event channel for store communication. */
> -	union {
> -		struct {
> -			xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> -			uint32_t  evtchn;   /* Event channel for console page.        */
> -		} domU;
> -		struct {
> -			uint32_t info_off;  /* Offset of console_info struct.         */
> -			uint32_t info_size; /* Size of console_info struct from start.*/
> -		} dom0;
> -	} console;
> -	/* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
> -	unsigned long pt_base;      /* VIRTUAL address of page directory.     */
> -	unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
> -	unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
> -	unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
> -	unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> -	int8_t cmd_line[MAX_GUEST_CMDLINE];
> -};
> -
>  struct dom0_vga_console_info {
>  	uint8_t video_type;
>  #define XEN_VGATYPE_TEXT_MODE_3 0x03
> @@ -490,11 +462,6 @@ struct dom0_vga_console_info {
>  	} u;
>  };
>  
> -/* These flags are passed in the 'flags' field of start_info_t. */
> -#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> -#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> -#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
> -
>  typedef uint64_t cpumap_t;
>  
>  typedef uint8_t xen_domain_handle_t[16];
> -- 
> 1.7.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 Feb 15 12:09:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6K69-0007oj-Bl; Fri, 15 Feb 2013 12:09: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 1U6K68-0007oe-4h
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:09:00 +0000
Received: from [85.158.143.35:27138] by server-3.bemta-4.messagelabs.com id
	EC/4D-08920-B552E115; Fri, 15 Feb 2013 12:08:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360930137!4786043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27307 invoked from network); 15 Feb 2013 12:08:58 -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;
	15 Feb 2013 12:08:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7666985"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:08:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:08:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6K64-0001eV-9L;
	Fri, 15 Feb 2013 12:08:56 +0000
Date: Fri, 15 Feb 2013 12:08:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> ARM has no start info. Although it does not existing in the hypervisor ABI we
> synthesize one for the benefit of the common code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/arm/include/asm/xen/interface.h |   24 +++++++++++++++++++++++
>  arch/x86/include/asm/xen/interface.h |   35 ++++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h          |   33 --------------------------------
>  3 files changed, 59 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 1151188..1db40d5 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
> +/*
> + * On ARM this is not part of the hypervisor ABI but we provide it
> + * internally for the benefit of common code.
> + */
> +struct start_info {
> +        uint32_t flags;             /* SIF_xxx flags.                         */
> +        uint32_t store_evtchn;      /* Event channel for store communication. */
> +        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> +        union {
> +                struct {
> +                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> +                        uint32_t  evtchn;   /* Event channel for console page.        */
> +                } domU;
> +                struct {
> +                        uint32_t info_off;  /* Offset of console_info struct.         */
> +                        uint32_t info_size; /* Size of console_info struct from start.*/
> +                } dom0;
> +        } console;
> +	/* UNUSED ON ARM */
> +        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> +};
> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> +
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
>  
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index fd9cb76..ca9a203 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -131,6 +131,41 @@ struct arch_shared_info {
>  #include <asm/pvclock-abi.h>
>  
>  #ifndef __ASSEMBLY__
> +
> +
> +#define MAX_GUEST_CMDLINE 1024
> +struct start_info {
> +    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> +    char magic[32];             /* "xen-<version>-<platform>".            */
> +    unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> +    unsigned long shared_info;  /* MACHINE address of shared info struct. */
> +    uint32_t flags;             /* SIF_xxx flags.                         */
> +    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> +    uint32_t store_evtchn;      /* Event channel for store communication. */
> +    union {
> +        struct {
> +            xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> +            uint32_t  evtchn;   /* Event channel for console page.        */
> +        } domU;
> +        struct {
> +            uint32_t info_off;  /* Offset of console_info struct.         */
> +            uint32_t info_size; /* Size of console_info struct from start.*/
> +        } dom0;
> +    } console;
> +    /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
> +    unsigned long pt_base;      /* VIRTUAL address of page directory.     */
> +    unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
> +    unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
> +    unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
> +    unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> +    int8_t cmd_line[MAX_GUEST_CMDLINE];
> +};
> +
> +/* These flags are passed in the 'flags' field of start_info_t. */
> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> +#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
> +
>  /*
>   * The following is all CPU context. Note that the fpu_ctxt block is filled
>   * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 53ec416..a9075df 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -422,34 +422,6 @@ struct shared_info {
>   *     extended by an extra 4MB to ensure this.
>   */
>  
> -#define MAX_GUEST_CMDLINE 1024
> -struct start_info {
> -	/* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
> -	char magic[32];             /* "xen-<version>-<platform>".            */
> -	unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> -	unsigned long shared_info;  /* MACHINE address of shared info struct. */
> -	uint32_t flags;             /* SIF_xxx flags.                         */
> -	xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> -	uint32_t store_evtchn;      /* Event channel for store communication. */
> -	union {
> -		struct {
> -			xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> -			uint32_t  evtchn;   /* Event channel for console page.        */
> -		} domU;
> -		struct {
> -			uint32_t info_off;  /* Offset of console_info struct.         */
> -			uint32_t info_size; /* Size of console_info struct from start.*/
> -		} dom0;
> -	} console;
> -	/* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
> -	unsigned long pt_base;      /* VIRTUAL address of page directory.     */
> -	unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
> -	unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
> -	unsigned long mod_start;    /* VIRTUAL address of pre-loaded module.  */
> -	unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> -	int8_t cmd_line[MAX_GUEST_CMDLINE];
> -};
> -
>  struct dom0_vga_console_info {
>  	uint8_t video_type;
>  #define XEN_VGATYPE_TEXT_MODE_3 0x03
> @@ -490,11 +462,6 @@ struct dom0_vga_console_info {
>  	} u;
>  };
>  
> -/* These flags are passed in the 'flags' field of start_info_t. */
> -#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> -#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> -#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
> -
>  typedef uint64_t cpumap_t;
>  
>  typedef uint8_t xen_domain_handle_t[16];
> -- 
> 1.7.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 Feb 15 12:09:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6K6N-0007pS-P2; Fri, 15 Feb 2013 12:09: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 1U6K6M-0007pJ-9T
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:09:14 +0000
Received: from [193.109.254.147:3889] by server-15.bemta-14.messagelabs.com id
	21/01-24599-9652E115; Fri, 15 Feb 2013 12:09:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1360930009!6104135!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7693 invoked from network); 15 Feb 2013 12:06:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:06:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1511594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:06: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.297.1;
	Fri, 15 Feb 2013 12:06:49 +0000
Message-ID: <1360930007.31407.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 12:06:47 +0000
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: arm: implement cpuinfo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> You can also run 32-bit on the V8 model (using -C
> cluster.cpu0.CONFIG64=0) if you comment out the ThumbEE in
> ctxt_switch_from and ctxt_switch_to (making this dynamic is on my TODO
> list). 

8<-----------------------------------------------

>From e45c4e4f45e72e404052629c619af8810dadd76f Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 15 Feb 2013 10:30:48 +0000
Subject: [PATCH] xen: arm: implement cpuinfo

Use to:

 - Only context switch ThumbEE state if the processor implements it. In
   particular the ARMv8 FastModels do not.
 - Detect the generic timer, and therefore call identify_cpu before
   init_xen_time.

Also improve the boot time messages a bit.

I haven't added decoding for all of the CPUID words, it seems like overkill
for the moment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: tim@xen.org
Cc: stefano.stabellini@citrix.com
---
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/cpu.c               |   69 +++++++++++++++++++++
 xen/arch/arm/domain.c            |   39 ++++++++++---
 xen/arch/arm/setup.c             |  109 +++++++++++++++++++++++++---------
 xen/arch/arm/smpboot.c           |    7 ++
 xen/arch/arm/time.c              |    5 +-
 xen/include/asm-arm/cpregs.h     |   11 ++--
 xen/include/asm-arm/cpufeature.h |   40 +++++++++++++
 xen/include/asm-arm/domain.h     |   10 +++-
 xen/include/asm-arm/processor.h  |  121 ++++++++++++++++++++++++++++++++++++-
 10 files changed, 364 insertions(+), 48 deletions(-)
 create mode 100644 xen/arch/arm/cpu.c
 create mode 100644 xen/include/asm-arm/cpufeature.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7ff67c7..a43e7c9 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
 subdir-$(arm64) += arm64
 
 obj-y += early_printk.o
+obj-y += cpu.o
 obj-y += domain.o
 obj-y += domctl.o
 obj-y += sysctl.o
diff --git a/xen/arch/arm/cpu.c b/xen/arch/arm/cpu.c
new file mode 100644
index 0000000..7a8ad33
--- /dev/null
+++ b/xen/arch/arm/cpu.c
@@ -0,0 +1,69 @@
+/*
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+
+#include <asm/processor.h>
+
+void __cpuinit identify_cpu(struct cpuinfo_arm *c)
+{
+        c->midr.bits = READ_SYSREG32(MIDR_EL1);
+        c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
+
+#ifdef CONFIG_ARM_64
+        c->pfr64.bits[0] = READ_SYSREG64(ID_AA64PFR0_EL1);
+        c->pfr64.bits[1] = READ_SYSREG64(ID_AA64PFR1_EL1);
+
+        c->dbg64.bits[0] = READ_SYSREG64(ID_AA64DFR0_EL1);
+        c->dbg64.bits[1] = READ_SYSREG64(ID_AA64DFR1_EL1);
+
+        c->aux64.bits[0] = READ_SYSREG64(ID_AA64AFR0_EL1);
+        c->aux64.bits[1] = READ_SYSREG64(ID_AA64AFR1_EL1);
+
+        c->mm64.bits[0]  = READ_SYSREG64(ID_AA64MMFR0_EL1);
+        c->mm64.bits[1]  = READ_SYSREG64(ID_AA64MMFR1_EL1);
+
+        c->isa64.bits[0] = READ_SYSREG64(ID_AA64ISAR0_EL1);
+        c->isa64.bits[1] = READ_SYSREG64(ID_AA64ISAR1_EL1);
+#endif
+
+        c->pfr32.bits[0] = READ_SYSREG32(ID_PFR0_EL1);
+        c->pfr32.bits[1] = READ_SYSREG32(ID_PFR1_EL1);
+
+        c->dbg32.bits[0] = READ_SYSREG32(ID_DFR0_EL1);
+
+        c->aux32.bits[0] = READ_SYSREG32(ID_AFR0_EL1);
+
+        c->mm32.bits[0]  = READ_SYSREG32(ID_MMFR0_EL1);
+        c->mm32.bits[1]  = READ_SYSREG32(ID_MMFR1_EL1);
+        c->mm32.bits[2]  = READ_SYSREG32(ID_MMFR2_EL1);
+        c->mm32.bits[3]  = READ_SYSREG32(ID_MMFR3_EL1);
+
+        c->isa32.bits[0] = READ_SYSREG32(ID_ISAR0_EL1);
+        c->isa32.bits[1] = READ_SYSREG32(ID_ISAR1_EL1);
+        c->isa32.bits[2] = READ_SYSREG32(ID_ISAR2_EL1);
+        c->isa32.bits[3] = READ_SYSREG32(ID_ISAR3_EL1);
+        c->isa32.bits[4] = READ_SYSREG32(ID_ISAR4_EL1);
+        c->isa32.bits[5] = READ_SYSREG32(ID_ISAR5_EL1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 494bed6..de1d837 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1,3 +1,14 @@
+/*
+ * 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 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.
+ */
 #include <xen/config.h>
 #include <xen/init.h>
 #include <xen/lib.h>
@@ -13,6 +24,7 @@
 #include <asm/regs.h>
 #include <asm/p2m.h>
 #include <asm/irq.h>
+#include <asm/cpufeature.h>
 
 #include <asm/gic.h>
 #include "vtimer.h"
@@ -58,11 +70,13 @@ static void ctxt_switch_from(struct vcpu *p)
     /* Arch timer */
     virt_timer_save(p);
 
-#if defined(CONFIG_ARM_32x)
-    /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    p->arch.teecr = READ_CP32(TEECR);
-    p->arch.teehbr = READ_CP32(TEEHBR);
+    if ( is_pv32_domain(p->domain) && cpu_has_thumbee )
+    {
+        p->arch.teecr = READ_SYSREG32(TEECR32_EL1);
+        p->arch.teehbr = READ_SYSREG32(TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
 #endif
@@ -121,6 +135,9 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
     isb();
 
+    WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
+    WRITE_SYSREG(n->domain->arch.vmpidr, VMPIDR_EL2);
+
     /* VGIC */
     gic_restore_state(n);
 
@@ -169,11 +186,13 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
     WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
-#if defined(CONFIG_ARM_32x)
-    /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    WRITE_CP32(n->arch.teecr, TEECR);
-    WRITE_CP32(n->arch.teehbr, TEEHBR);
+    if ( is_pv32_domain(n->domain) && cpu_has_thumbee )
+    {
+        WRITE_SYSREG32(n->arch.teecr, TEECR32_EL1);
+        WRITE_SYSREG32(n->arch.teehbr, TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
 #endif
@@ -447,6 +466,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
         goto fail;
 
+    /* Default the virtual ID to match the physical */
+    d->arch.vpidr = boot_cpu_data.midr.bits;
+    d->arch.vmpidr = boot_cpu_data.mpidr.bits;
+
     clear_page(d->shared_info);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 967a8d4..d13e45d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,9 @@
 #include <asm/vfp.h>
 #include <asm/early_printk.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
+
+struct cpuinfo_arm __read_mostly boot_cpu_data;
 
 static __used void init_done(void)
 {
@@ -54,41 +57,93 @@ static void __init init_idle_domain(void)
     /* TODO: setup_idle_pagetable(); */
 }
 
+static const char * __initdata processor_implementers[] = {
+    ['A'] = "ARM Limited",
+    ['D'] = "Digital Equipment Corp",
+    ['M'] = "Motorola, Freescale Semiconductor Inc.",
+    ['Q'] = "Qualcomm Inc.",
+    ['V'] = "Marvell Semiconductor Inc.",
+    ['i'] = "Intel Corporation",
+};
+
 static void __init processor_id(void)
 {
+    const char *implementer = "Unknown";
+    struct cpuinfo_arm *c = &boot_cpu_data;
+
+    identify_cpu(c);
+    current_cpu_data = *c;
+
+    if ( c->midr.implementer < ARRAY_SIZE(processor_implementers) &&
+         processor_implementers[c->midr.implementer] )
+        implementer = processor_implementers[c->midr.implementer];
 
-    /* Setup the virtual ID to match the physical */
-    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
-    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+    if ( c->midr.architecture != 0xf )
+        printk("Huh, cpu architecture %x, expected 0xf (defined by cpuid)\n",
+               c->midr.architecture);
+
+    printk("Processor: \"%s\", variant: 0x%x, part 0x%03x, rev 0x%x\n",
+           implementer, c->midr.variant, c->midr.part_number, c->midr.revision);
 
 #if defined(CONFIG_ARM_64)
-    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
-    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
-    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
-    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
-    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+    printk("64-bit Execution:\n");
+    printk("  Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.pfr64.bits[0], boot_cpu_data.pfr64.bits[1]);
+    printk("    Exception Levels: EL3:%s EL2:%s EL1:%s EL0:%s\n",
+           cpu_has_el3_32 ? "64+32" : cpu_has_el3_64 ? "64" : "No",
+           cpu_has_el2_32 ? "64+32" : cpu_has_el2_64 ? "64" : "No",
+           cpu_has_el1_32 ? "64+32" : cpu_has_el1_64 ? "64" : "No",
+           cpu_has_el0_32 ? "64+32" : cpu_has_el0_64 ? "64" : "No");
+    printk("    Extensions:%s%s\n",
+           cpu_has_fp ? " FloatingPoint" : "",
+           cpu_has_simd ? " AdvancedSIMD" : "");
+
+    printk("  Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
+    printk("  Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.aux64.bits[0], boot_cpu_data.aux64.bits[1]);
+    printk("  Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.mm64.bits[0], boot_cpu_data.mm64.bits[1]);
+    printk("  ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.isa64.bits[0], boot_cpu_data.isa64.bits[1]);
 #endif
+
     /*
      * On AArch64 these refer to the capabilities when running in
      * AArch32 mode.
      */
-    printk("32-bit Processor Features: %08x %08x\n",
-           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
-    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
-    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
-    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
-           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
-    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
-           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
-           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
-
+    if ( cpu_has_aarch32 )
+    {
+        printk("32-bit Execution:\n");
+        printk("  Processor Features: %08"PRIx32":%08"PRIx32"\n",
+               boot_cpu_data.pfr32.bits[0], boot_cpu_data.pfr32.bits[1]);
+        printk("    Instruction Sets:%s%s%s%s%s\n",
+               cpu_has_aarch32 ? " AArch32" : "",
+               cpu_has_thumb ? " Thumb" : "",
+               cpu_has_thumb2 ? " Thumb-2" : "",
+               cpu_has_thumbee ? " ThumbEE" : "",
+               cpu_has_jazelle ? " Jazelle" : "");
+        printk("    Extensions:%s%s\n",
+               cpu_has_gentimer ? " GenericTimer" : "",
+               cpu_has_security ? " Security" : "");
+
+        printk("  Debug Features: %08"PRIx32"\n",
+               boot_cpu_data.dbg32.bits[0]);
+        printk("  Auxiliary Features: %08"PRIx32"\n",
+               boot_cpu_data.aux32.bits[0]);
+        printk("  Memory Model Features: "
+               "%08"PRIx32" %08"PRIx32" %08"PRIx32" %08"PRIx32"\n",
+               boot_cpu_data.mm32.bits[0], boot_cpu_data.mm32.bits[1],
+               boot_cpu_data.mm32.bits[2], boot_cpu_data.mm32.bits[3]);
+        printk(" ISA Features: %08x %08x %08x %08x %08x %08x\n",
+               boot_cpu_data.isa32.bits[0], boot_cpu_data.isa32.bits[1],
+               boot_cpu_data.isa32.bits[2], boot_cpu_data.isa32.bits[3],
+               boot_cpu_data.isa32.bits[4], boot_cpu_data.isa32.bits[5]);
+    }
+    else
+    {
+        printk("32-bit Execution: Unsupported\n");
+    }
 }
 
 void __init discard_initial_modules(void)
@@ -393,6 +448,8 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
+    processor_id();
+
     init_xen_time();
 
     gic_init();
@@ -416,8 +473,6 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
-    processor_id();
-
     enable_vfp();
 
     softirq_init();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b18f137..cadf79f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -38,6 +38,8 @@ EXPORT_SYMBOL(cpu_online_map);
 cpumask_t cpu_possible_map;
 EXPORT_SYMBOL(cpu_possible_map);
 
+struct cpuinfo_arm cpu_data[NR_CPUS];
+
 /* Fake one node for now. See also include/asm-arm/numa.h */
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
@@ -136,11 +138,16 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
                                unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
+    struct cpuinfo_arm *c = cpu_data + cpuid;
+
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));
 
     /* TODO: handle boards where CPUIDs are not contiguous */
     set_processor_id(cpuid);
 
+    *c = boot_cpu_data;
+    identify_cpu(c);
+
     /* Setup Hyp vector base */
     WRITE_SYSREG((vaddr_t)&hyp_traps_vector, VBAR_EL2);
 
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index ee92d8c..81d490d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -31,6 +31,7 @@
 #include <asm/system.h>
 #include <asm/time.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
 
 /*
  * Unfortunately the hypervisor timer interrupt appears to be buggy in
@@ -90,10 +91,8 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
-#if defined(CONFIG_ARM_32)
-    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+    if ( !cpu_has_gentimer )
         panic("CPU does not support the Generic Timer v1 interface.\n");
-#endif
 
     cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
     boot_count = READ_SYSREG64(CNTPCT_EL0);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 908aad9..a72ca62 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -265,10 +265,14 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define IFSR32_EL2              IFSR
+#define MIDR_EL1                MIDR
+#define MPIDR_EL1               MPIDR
 #define PAR_EL1                 PAR
 #define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
 #define TCR_EL1                 TTBCR
+#define TEECR32_EL1             TEECR
+#define TEEHBR32_EL1            TEEHBR
 #define TPIDRRO_EL0             TPIDRURO
 #define TPIDR_EL0               TPIDRURW
 #define TPIDR_EL1               TPIDRPRW
@@ -278,13 +282,10 @@
 #define TTBR1_EL1               TTBR1
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
+#define VMPIDR_EL2              VMPIDR
+#define VPIDR_EL2               VPIDR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
-#define MIDR_EL1                MIDR
-#define VPIDR_EL2               VPIDR
-#define MPIDR_EL1               MPIDR
-#define VMPIDR_EL2              VMPIDR
-
 #endif
 
 #endif
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
new file mode 100644
index 0000000..e633239
--- /dev/null
+++ b/xen/include/asm-arm/cpufeature.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_ARM_CPUFEATURE_H
+#define __ASM_ARM_CPUFEATURE_H
+
+#ifdef CONFIG_ARM_64
+#define cpu_feature64(c, feat)         ((c)->pfr64.feat)
+#define boot_cpu_feature64(feat)       (boot_cpu_data.pfr64.feat)
+
+#define cpu_has_el0_32    (boot_cpu_feature64(el0) == 2)
+#define cpu_has_el0_64    (boot_cpu_feature64(el0) >= 1)
+#define cpu_has_el1_32    (boot_cpu_feature64(el1) == 2)
+#define cpu_has_el1_64    (boot_cpu_feature64(el1) >= 1)
+#define cpu_has_el2_32    (boot_cpu_feature64(el2) == 2)
+#define cpu_has_el2_64    (boot_cpu_feature64(el2) >= 1)
+#define cpu_has_el3_32    (boot_cpu_feature64(el3) == 2)
+#define cpu_has_el3_64    (boot_cpu_feature64(el3) >= 1)
+#define cpu_has_fp        (boot_cpu_feature64(fp) == 0)
+#define cpu_has_simd      (boot_cpu_feature64(simd) == 0)
+#endif
+
+#define cpu_feature32(c, feat)         ((c)->pfr32.feat)
+#define boot_cpu_feature32(feat)       (boot_cpu_data.pfr32.feat)
+
+#define cpu_has_aarch32   (boot_cpu_feature32(arm) == 1)
+#define cpu_has_thumb     (boot_cpu_feature32(thumb) >= 1)
+#define cpu_has_thumb2    (boot_cpu_feature32(thumb) >= 3)
+#define cpu_has_jazelle   (boot_cpu_feature32(jazelle) >= 0)
+#define cpu_has_thumbee   (boot_cpu_feature32(thumbee) == 1)
+
+#define cpu_has_gentimer  (boot_cpu_feature32(gentimer) == 1)
+#define cpu_has_security  (boot_cpu_feature32(security) > 0)
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4a4bf2f..601e972 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,10 @@ struct arch_domain
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
 
+    /* Virtual CPUID */
+    uint32_t vpidr;
+    register_t vmpidr;
+
     struct {
         /*
          * Covers access to other members of this struct _except_ for
@@ -166,8 +170,12 @@ struct arch_vcpu
     register_t tpidr_el1;
     register_t tpidrro_el0;
 
+    uint32_t teecr, teehbr; /* ThumbEE, 32-bit guests only */
 #ifdef CONFIG_ARM_32
-    uint32_t teecr, teehbr;
+    /*
+     * ARMv8 only supports a trivial implementation on Jazelle when in AArch32
+     * mode and therefore has no extended control registers.
+     */
     uint32_t joscr, jmcr;
 #endif
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1072aa2..0515986 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -91,6 +91,123 @@
 #define HSR_EC_DATA_ABORT_HYP       0x25
 
 #ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+
+struct cpuinfo_arm {
+    union {
+        uint32_t bits;
+        struct {
+            unsigned long revision:4;
+            unsigned long part_number:12;
+            unsigned long architecture:4;
+            unsigned long variant:4;
+            unsigned long implementer:8;
+        };
+    } midr;
+    union {
+        register_t bits;
+        struct {
+            unsigned long aff0:8;
+            unsigned long aff1:8;
+            unsigned long aff2:8;
+            unsigned long mt:1; /* Multi-thread, iff MP == 1 */
+            unsigned long __res0:5;
+            unsigned long up:1; /* UP system, iff MP == 1 */
+            unsigned long mp:1; /* MP extensions */
+
+#ifdef CONFIG_ARM_64
+            unsigned long aff3:8;
+            unsigned long __res1:24;
+#endif
+        };
+    } mpidr;
+
+#ifdef CONFIG_ARM_64
+    /* 64-bit CPUID registers. */
+    union {
+        uint64_t bits[2];
+        struct {
+            unsigned long el0:4;
+            unsigned long el1:4;
+            unsigned long el2:4;
+            unsigned long el3:4;
+            unsigned long fp:4;   /* Floating Point */
+            unsigned long simd:4; /* Advanced SIMD */
+            unsigned long __res0:8;
+
+            unsigned long __res1;
+        };
+    } pfr64;
+
+    struct {
+        uint64_t bits[2];
+    } dbg64;
+
+    struct {
+        uint64_t bits[2];
+    } aux64;
+
+    struct {
+        uint64_t bits[2];
+    } mm64;
+
+    struct {
+        uint64_t bits[2];
+    } isa64;
+
+#endif
+
+    /*
+     * 32-bit CPUID registers. On ARMv8 these describe the properties
+     * when running in 32-bit mode.
+     */
+    union {
+        uint32_t bits[2];
+        struct {
+            unsigned long arm:4;
+            unsigned long thumb:4;
+            unsigned long jazelle:4;
+            unsigned long thumbee:4;
+            unsigned long __res0:16;
+
+            unsigned long progmodel:4;
+            unsigned long security:4;
+            unsigned long mprofile:4;
+            unsigned long virt:4;
+            unsigned long gentimer:4;
+            unsigned long __res1:12;
+        };
+    } pfr32;
+
+    struct {
+        uint32_t bits[1];
+    } dbg32;
+
+    struct {
+        uint32_t bits[1];
+    } aux32;
+
+    struct {
+        uint32_t bits[4];
+    } mm32;
+
+    struct {
+        uint32_t bits[6];
+    } isa32;
+};
+
+/*
+ * capabilities of CPUs
+ */
+
+extern struct cpuinfo_arm boot_cpu_data;
+
+extern void identify_cpu(struct cpuinfo_arm *);
+
+extern struct cpuinfo_arm cpu_data[];
+#define current_cpu_data cpu_data[smp_processor_id()]
+
 union hsr {
     uint32_t bits;
     struct {
@@ -225,10 +342,6 @@ union hsr {
 #define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
 #define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
 
-/* CPUID bits */
-#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
-#define ID_PFR1_GT_v1    0x00010000
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/processor.h>
 #elif defined(CONFIG_ARM_64)
-- 
1.7.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 Feb 15 12:09:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6K6N-0007pS-P2; Fri, 15 Feb 2013 12:09: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 1U6K6M-0007pJ-9T
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:09:14 +0000
Received: from [193.109.254.147:3889] by server-15.bemta-14.messagelabs.com id
	21/01-24599-9652E115; Fri, 15 Feb 2013 12:09:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1360930009!6104135!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7693 invoked from network); 15 Feb 2013 12:06:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:06:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1511594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:06: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.297.1;
	Fri, 15 Feb 2013 12:06:49 +0000
Message-ID: <1360930007.31407.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 12:06:47 +0000
In-Reply-To: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen: arm: implement cpuinfo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> You can also run 32-bit on the V8 model (using -C
> cluster.cpu0.CONFIG64=0) if you comment out the ThumbEE in
> ctxt_switch_from and ctxt_switch_to (making this dynamic is on my TODO
> list). 

8<-----------------------------------------------

>From e45c4e4f45e72e404052629c619af8810dadd76f Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 15 Feb 2013 10:30:48 +0000
Subject: [PATCH] xen: arm: implement cpuinfo

Use to:

 - Only context switch ThumbEE state if the processor implements it. In
   particular the ARMv8 FastModels do not.
 - Detect the generic timer, and therefore call identify_cpu before
   init_xen_time.

Also improve the boot time messages a bit.

I haven't added decoding for all of the CPUID words, it seems like overkill
for the moment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: tim@xen.org
Cc: stefano.stabellini@citrix.com
---
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/cpu.c               |   69 +++++++++++++++++++++
 xen/arch/arm/domain.c            |   39 ++++++++++---
 xen/arch/arm/setup.c             |  109 +++++++++++++++++++++++++---------
 xen/arch/arm/smpboot.c           |    7 ++
 xen/arch/arm/time.c              |    5 +-
 xen/include/asm-arm/cpregs.h     |   11 ++--
 xen/include/asm-arm/cpufeature.h |   40 +++++++++++++
 xen/include/asm-arm/domain.h     |   10 +++-
 xen/include/asm-arm/processor.h  |  121 ++++++++++++++++++++++++++++++++++++-
 10 files changed, 364 insertions(+), 48 deletions(-)
 create mode 100644 xen/arch/arm/cpu.c
 create mode 100644 xen/include/asm-arm/cpufeature.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7ff67c7..a43e7c9 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
 subdir-$(arm64) += arm64
 
 obj-y += early_printk.o
+obj-y += cpu.o
 obj-y += domain.o
 obj-y += domctl.o
 obj-y += sysctl.o
diff --git a/xen/arch/arm/cpu.c b/xen/arch/arm/cpu.c
new file mode 100644
index 0000000..7a8ad33
--- /dev/null
+++ b/xen/arch/arm/cpu.c
@@ -0,0 +1,69 @@
+/*
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+
+#include <asm/processor.h>
+
+void __cpuinit identify_cpu(struct cpuinfo_arm *c)
+{
+        c->midr.bits = READ_SYSREG32(MIDR_EL1);
+        c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
+
+#ifdef CONFIG_ARM_64
+        c->pfr64.bits[0] = READ_SYSREG64(ID_AA64PFR0_EL1);
+        c->pfr64.bits[1] = READ_SYSREG64(ID_AA64PFR1_EL1);
+
+        c->dbg64.bits[0] = READ_SYSREG64(ID_AA64DFR0_EL1);
+        c->dbg64.bits[1] = READ_SYSREG64(ID_AA64DFR1_EL1);
+
+        c->aux64.bits[0] = READ_SYSREG64(ID_AA64AFR0_EL1);
+        c->aux64.bits[1] = READ_SYSREG64(ID_AA64AFR1_EL1);
+
+        c->mm64.bits[0]  = READ_SYSREG64(ID_AA64MMFR0_EL1);
+        c->mm64.bits[1]  = READ_SYSREG64(ID_AA64MMFR1_EL1);
+
+        c->isa64.bits[0] = READ_SYSREG64(ID_AA64ISAR0_EL1);
+        c->isa64.bits[1] = READ_SYSREG64(ID_AA64ISAR1_EL1);
+#endif
+
+        c->pfr32.bits[0] = READ_SYSREG32(ID_PFR0_EL1);
+        c->pfr32.bits[1] = READ_SYSREG32(ID_PFR1_EL1);
+
+        c->dbg32.bits[0] = READ_SYSREG32(ID_DFR0_EL1);
+
+        c->aux32.bits[0] = READ_SYSREG32(ID_AFR0_EL1);
+
+        c->mm32.bits[0]  = READ_SYSREG32(ID_MMFR0_EL1);
+        c->mm32.bits[1]  = READ_SYSREG32(ID_MMFR1_EL1);
+        c->mm32.bits[2]  = READ_SYSREG32(ID_MMFR2_EL1);
+        c->mm32.bits[3]  = READ_SYSREG32(ID_MMFR3_EL1);
+
+        c->isa32.bits[0] = READ_SYSREG32(ID_ISAR0_EL1);
+        c->isa32.bits[1] = READ_SYSREG32(ID_ISAR1_EL1);
+        c->isa32.bits[2] = READ_SYSREG32(ID_ISAR2_EL1);
+        c->isa32.bits[3] = READ_SYSREG32(ID_ISAR3_EL1);
+        c->isa32.bits[4] = READ_SYSREG32(ID_ISAR4_EL1);
+        c->isa32.bits[5] = READ_SYSREG32(ID_ISAR5_EL1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 494bed6..de1d837 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1,3 +1,14 @@
+/*
+ * 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 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.
+ */
 #include <xen/config.h>
 #include <xen/init.h>
 #include <xen/lib.h>
@@ -13,6 +24,7 @@
 #include <asm/regs.h>
 #include <asm/p2m.h>
 #include <asm/irq.h>
+#include <asm/cpufeature.h>
 
 #include <asm/gic.h>
 #include "vtimer.h"
@@ -58,11 +70,13 @@ static void ctxt_switch_from(struct vcpu *p)
     /* Arch timer */
     virt_timer_save(p);
 
-#if defined(CONFIG_ARM_32x)
-    /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    p->arch.teecr = READ_CP32(TEECR);
-    p->arch.teehbr = READ_CP32(TEEHBR);
+    if ( is_pv32_domain(p->domain) && cpu_has_thumbee )
+    {
+        p->arch.teecr = READ_SYSREG32(TEECR32_EL1);
+        p->arch.teehbr = READ_SYSREG32(TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
 #endif
@@ -121,6 +135,9 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
     isb();
 
+    WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
+    WRITE_SYSREG(n->domain->arch.vmpidr, VMPIDR_EL2);
+
     /* VGIC */
     gic_restore_state(n);
 
@@ -169,11 +186,13 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
     WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
-#if defined(CONFIG_ARM_32x)
-    /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    WRITE_CP32(n->arch.teecr, TEECR);
-    WRITE_CP32(n->arch.teehbr, TEEHBR);
+    if ( is_pv32_domain(n->domain) && cpu_has_thumbee )
+    {
+        WRITE_SYSREG32(n->arch.teecr, TEECR32_EL1);
+        WRITE_SYSREG32(n->arch.teehbr, TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
 #endif
@@ -447,6 +466,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
         goto fail;
 
+    /* Default the virtual ID to match the physical */
+    d->arch.vpidr = boot_cpu_data.midr.bits;
+    d->arch.vmpidr = boot_cpu_data.mpidr.bits;
+
     clear_page(d->shared_info);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 967a8d4..d13e45d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,9 @@
 #include <asm/vfp.h>
 #include <asm/early_printk.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
+
+struct cpuinfo_arm __read_mostly boot_cpu_data;
 
 static __used void init_done(void)
 {
@@ -54,41 +57,93 @@ static void __init init_idle_domain(void)
     /* TODO: setup_idle_pagetable(); */
 }
 
+static const char * __initdata processor_implementers[] = {
+    ['A'] = "ARM Limited",
+    ['D'] = "Digital Equipment Corp",
+    ['M'] = "Motorola, Freescale Semiconductor Inc.",
+    ['Q'] = "Qualcomm Inc.",
+    ['V'] = "Marvell Semiconductor Inc.",
+    ['i'] = "Intel Corporation",
+};
+
 static void __init processor_id(void)
 {
+    const char *implementer = "Unknown";
+    struct cpuinfo_arm *c = &boot_cpu_data;
+
+    identify_cpu(c);
+    current_cpu_data = *c;
+
+    if ( c->midr.implementer < ARRAY_SIZE(processor_implementers) &&
+         processor_implementers[c->midr.implementer] )
+        implementer = processor_implementers[c->midr.implementer];
 
-    /* Setup the virtual ID to match the physical */
-    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
-    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+    if ( c->midr.architecture != 0xf )
+        printk("Huh, cpu architecture %x, expected 0xf (defined by cpuid)\n",
+               c->midr.architecture);
+
+    printk("Processor: \"%s\", variant: 0x%x, part 0x%03x, rev 0x%x\n",
+           implementer, c->midr.variant, c->midr.part_number, c->midr.revision);
 
 #if defined(CONFIG_ARM_64)
-    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
-    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
-    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
-    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
-    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+    printk("64-bit Execution:\n");
+    printk("  Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.pfr64.bits[0], boot_cpu_data.pfr64.bits[1]);
+    printk("    Exception Levels: EL3:%s EL2:%s EL1:%s EL0:%s\n",
+           cpu_has_el3_32 ? "64+32" : cpu_has_el3_64 ? "64" : "No",
+           cpu_has_el2_32 ? "64+32" : cpu_has_el2_64 ? "64" : "No",
+           cpu_has_el1_32 ? "64+32" : cpu_has_el1_64 ? "64" : "No",
+           cpu_has_el0_32 ? "64+32" : cpu_has_el0_64 ? "64" : "No");
+    printk("    Extensions:%s%s\n",
+           cpu_has_fp ? " FloatingPoint" : "",
+           cpu_has_simd ? " AdvancedSIMD" : "");
+
+    printk("  Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
+    printk("  Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.aux64.bits[0], boot_cpu_data.aux64.bits[1]);
+    printk("  Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.mm64.bits[0], boot_cpu_data.mm64.bits[1]);
+    printk("  ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.isa64.bits[0], boot_cpu_data.isa64.bits[1]);
 #endif
+
     /*
      * On AArch64 these refer to the capabilities when running in
      * AArch32 mode.
      */
-    printk("32-bit Processor Features: %08x %08x\n",
-           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
-    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
-    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
-    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
-           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
-    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
-           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
-           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
-
+    if ( cpu_has_aarch32 )
+    {
+        printk("32-bit Execution:\n");
+        printk("  Processor Features: %08"PRIx32":%08"PRIx32"\n",
+               boot_cpu_data.pfr32.bits[0], boot_cpu_data.pfr32.bits[1]);
+        printk("    Instruction Sets:%s%s%s%s%s\n",
+               cpu_has_aarch32 ? " AArch32" : "",
+               cpu_has_thumb ? " Thumb" : "",
+               cpu_has_thumb2 ? " Thumb-2" : "",
+               cpu_has_thumbee ? " ThumbEE" : "",
+               cpu_has_jazelle ? " Jazelle" : "");
+        printk("    Extensions:%s%s\n",
+               cpu_has_gentimer ? " GenericTimer" : "",
+               cpu_has_security ? " Security" : "");
+
+        printk("  Debug Features: %08"PRIx32"\n",
+               boot_cpu_data.dbg32.bits[0]);
+        printk("  Auxiliary Features: %08"PRIx32"\n",
+               boot_cpu_data.aux32.bits[0]);
+        printk("  Memory Model Features: "
+               "%08"PRIx32" %08"PRIx32" %08"PRIx32" %08"PRIx32"\n",
+               boot_cpu_data.mm32.bits[0], boot_cpu_data.mm32.bits[1],
+               boot_cpu_data.mm32.bits[2], boot_cpu_data.mm32.bits[3]);
+        printk(" ISA Features: %08x %08x %08x %08x %08x %08x\n",
+               boot_cpu_data.isa32.bits[0], boot_cpu_data.isa32.bits[1],
+               boot_cpu_data.isa32.bits[2], boot_cpu_data.isa32.bits[3],
+               boot_cpu_data.isa32.bits[4], boot_cpu_data.isa32.bits[5]);
+    }
+    else
+    {
+        printk("32-bit Execution: Unsupported\n");
+    }
 }
 
 void __init discard_initial_modules(void)
@@ -393,6 +448,8 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
+    processor_id();
+
     init_xen_time();
 
     gic_init();
@@ -416,8 +473,6 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
-    processor_id();
-
     enable_vfp();
 
     softirq_init();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b18f137..cadf79f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -38,6 +38,8 @@ EXPORT_SYMBOL(cpu_online_map);
 cpumask_t cpu_possible_map;
 EXPORT_SYMBOL(cpu_possible_map);
 
+struct cpuinfo_arm cpu_data[NR_CPUS];
+
 /* Fake one node for now. See also include/asm-arm/numa.h */
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
@@ -136,11 +138,16 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
                                unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
+    struct cpuinfo_arm *c = cpu_data + cpuid;
+
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));
 
     /* TODO: handle boards where CPUIDs are not contiguous */
     set_processor_id(cpuid);
 
+    *c = boot_cpu_data;
+    identify_cpu(c);
+
     /* Setup Hyp vector base */
     WRITE_SYSREG((vaddr_t)&hyp_traps_vector, VBAR_EL2);
 
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index ee92d8c..81d490d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -31,6 +31,7 @@
 #include <asm/system.h>
 #include <asm/time.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
 
 /*
  * Unfortunately the hypervisor timer interrupt appears to be buggy in
@@ -90,10 +91,8 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
-#if defined(CONFIG_ARM_32)
-    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+    if ( !cpu_has_gentimer )
         panic("CPU does not support the Generic Timer v1 interface.\n");
-#endif
 
     cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
     boot_count = READ_SYSREG64(CNTPCT_EL0);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 908aad9..a72ca62 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -265,10 +265,14 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define IFSR32_EL2              IFSR
+#define MIDR_EL1                MIDR
+#define MPIDR_EL1               MPIDR
 #define PAR_EL1                 PAR
 #define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
 #define TCR_EL1                 TTBCR
+#define TEECR32_EL1             TEECR
+#define TEEHBR32_EL1            TEEHBR
 #define TPIDRRO_EL0             TPIDRURO
 #define TPIDR_EL0               TPIDRURW
 #define TPIDR_EL1               TPIDRPRW
@@ -278,13 +282,10 @@
 #define TTBR1_EL1               TTBR1
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
+#define VMPIDR_EL2              VMPIDR
+#define VPIDR_EL2               VPIDR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
-#define MIDR_EL1                MIDR
-#define VPIDR_EL2               VPIDR
-#define MPIDR_EL1               MPIDR
-#define VMPIDR_EL2              VMPIDR
-
 #endif
 
 #endif
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
new file mode 100644
index 0000000..e633239
--- /dev/null
+++ b/xen/include/asm-arm/cpufeature.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_ARM_CPUFEATURE_H
+#define __ASM_ARM_CPUFEATURE_H
+
+#ifdef CONFIG_ARM_64
+#define cpu_feature64(c, feat)         ((c)->pfr64.feat)
+#define boot_cpu_feature64(feat)       (boot_cpu_data.pfr64.feat)
+
+#define cpu_has_el0_32    (boot_cpu_feature64(el0) == 2)
+#define cpu_has_el0_64    (boot_cpu_feature64(el0) >= 1)
+#define cpu_has_el1_32    (boot_cpu_feature64(el1) == 2)
+#define cpu_has_el1_64    (boot_cpu_feature64(el1) >= 1)
+#define cpu_has_el2_32    (boot_cpu_feature64(el2) == 2)
+#define cpu_has_el2_64    (boot_cpu_feature64(el2) >= 1)
+#define cpu_has_el3_32    (boot_cpu_feature64(el3) == 2)
+#define cpu_has_el3_64    (boot_cpu_feature64(el3) >= 1)
+#define cpu_has_fp        (boot_cpu_feature64(fp) == 0)
+#define cpu_has_simd      (boot_cpu_feature64(simd) == 0)
+#endif
+
+#define cpu_feature32(c, feat)         ((c)->pfr32.feat)
+#define boot_cpu_feature32(feat)       (boot_cpu_data.pfr32.feat)
+
+#define cpu_has_aarch32   (boot_cpu_feature32(arm) == 1)
+#define cpu_has_thumb     (boot_cpu_feature32(thumb) >= 1)
+#define cpu_has_thumb2    (boot_cpu_feature32(thumb) >= 3)
+#define cpu_has_jazelle   (boot_cpu_feature32(jazelle) >= 0)
+#define cpu_has_thumbee   (boot_cpu_feature32(thumbee) == 1)
+
+#define cpu_has_gentimer  (boot_cpu_feature32(gentimer) == 1)
+#define cpu_has_security  (boot_cpu_feature32(security) > 0)
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4a4bf2f..601e972 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,10 @@ struct arch_domain
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
 
+    /* Virtual CPUID */
+    uint32_t vpidr;
+    register_t vmpidr;
+
     struct {
         /*
          * Covers access to other members of this struct _except_ for
@@ -166,8 +170,12 @@ struct arch_vcpu
     register_t tpidr_el1;
     register_t tpidrro_el0;
 
+    uint32_t teecr, teehbr; /* ThumbEE, 32-bit guests only */
 #ifdef CONFIG_ARM_32
-    uint32_t teecr, teehbr;
+    /*
+     * ARMv8 only supports a trivial implementation on Jazelle when in AArch32
+     * mode and therefore has no extended control registers.
+     */
     uint32_t joscr, jmcr;
 #endif
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1072aa2..0515986 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -91,6 +91,123 @@
 #define HSR_EC_DATA_ABORT_HYP       0x25
 
 #ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+
+struct cpuinfo_arm {
+    union {
+        uint32_t bits;
+        struct {
+            unsigned long revision:4;
+            unsigned long part_number:12;
+            unsigned long architecture:4;
+            unsigned long variant:4;
+            unsigned long implementer:8;
+        };
+    } midr;
+    union {
+        register_t bits;
+        struct {
+            unsigned long aff0:8;
+            unsigned long aff1:8;
+            unsigned long aff2:8;
+            unsigned long mt:1; /* Multi-thread, iff MP == 1 */
+            unsigned long __res0:5;
+            unsigned long up:1; /* UP system, iff MP == 1 */
+            unsigned long mp:1; /* MP extensions */
+
+#ifdef CONFIG_ARM_64
+            unsigned long aff3:8;
+            unsigned long __res1:24;
+#endif
+        };
+    } mpidr;
+
+#ifdef CONFIG_ARM_64
+    /* 64-bit CPUID registers. */
+    union {
+        uint64_t bits[2];
+        struct {
+            unsigned long el0:4;
+            unsigned long el1:4;
+            unsigned long el2:4;
+            unsigned long el3:4;
+            unsigned long fp:4;   /* Floating Point */
+            unsigned long simd:4; /* Advanced SIMD */
+            unsigned long __res0:8;
+
+            unsigned long __res1;
+        };
+    } pfr64;
+
+    struct {
+        uint64_t bits[2];
+    } dbg64;
+
+    struct {
+        uint64_t bits[2];
+    } aux64;
+
+    struct {
+        uint64_t bits[2];
+    } mm64;
+
+    struct {
+        uint64_t bits[2];
+    } isa64;
+
+#endif
+
+    /*
+     * 32-bit CPUID registers. On ARMv8 these describe the properties
+     * when running in 32-bit mode.
+     */
+    union {
+        uint32_t bits[2];
+        struct {
+            unsigned long arm:4;
+            unsigned long thumb:4;
+            unsigned long jazelle:4;
+            unsigned long thumbee:4;
+            unsigned long __res0:16;
+
+            unsigned long progmodel:4;
+            unsigned long security:4;
+            unsigned long mprofile:4;
+            unsigned long virt:4;
+            unsigned long gentimer:4;
+            unsigned long __res1:12;
+        };
+    } pfr32;
+
+    struct {
+        uint32_t bits[1];
+    } dbg32;
+
+    struct {
+        uint32_t bits[1];
+    } aux32;
+
+    struct {
+        uint32_t bits[4];
+    } mm32;
+
+    struct {
+        uint32_t bits[6];
+    } isa32;
+};
+
+/*
+ * capabilities of CPUs
+ */
+
+extern struct cpuinfo_arm boot_cpu_data;
+
+extern void identify_cpu(struct cpuinfo_arm *);
+
+extern struct cpuinfo_arm cpu_data[];
+#define current_cpu_data cpu_data[smp_processor_id()]
+
 union hsr {
     uint32_t bits;
     struct {
@@ -225,10 +342,6 @@ union hsr {
 #define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
 #define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
 
-/* CPUID bits */
-#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
-#define ID_PFR1_GT_v1    0x00010000
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/processor.h>
 #elif defined(CONFIG_ARM_64)
-- 
1.7.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 Feb 15 12:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:10: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 1U6K76-0007v4-Cc; Fri, 15 Feb 2013 12:10:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+a3e01b864c7328904b3a+3463+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U6K74-0007ul-QT
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:09:59 +0000
Received: from [85.158.139.211:44020] by server-13.bemta-5.messagelabs.com id
	F0/9A-06769-5952E115; Fri, 15 Feb 2013 12:09:57 +0000
X-Env-Sender: BATV+a3e01b864c7328904b3a+3463+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360930196!21171999!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTgxMzk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26244 invoked from network); 15 Feb 2013 12:09:57 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 12:09:57 -0000
Received: from i7.infradead.org ([2001:8b0:10b:1:225:64ff:fee8:e9df])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U6K6x-0000tQ-ML; Fri, 15 Feb 2013 12:09:52 +0000
Message-ID: <1360930184.6534.16.camel@i7.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Fri, 15 Feb 2013 12:09:44 +0000
In-Reply-To: <1360860396.20449.471.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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: multipart/mixed; boundary="===============8515652335821685675=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8515652335821685675==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-ugWV3jn0nW+PR5aQB6uz"


--=-ugWV3jn0nW+PR5aQB6uz
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 16:46 +0000, Ian Campbell wrote:
> Right, we really need to find someone with hours to finish properly
> integrating OVMF.

Hm, that 'someone' may end up being me=C2=B9.

So... from the Xen point of view, what needs doing? There are some
things on my TODO list which apply to Qemu/KVM too =E2=80=94 most important=
ly,
fixing bootorder handling, which basically involves fixing the general
case of NV variable storage for UEFI as discussed. But is there anything
Xen-specific that I'm likely to miss?

And on the subject of the NV storage... does -pflash work on qemu-xen,
as long as we're not actually running *code* from the device and we're
only using it for data storage? Are you content with my stated plan to
provide a "disk" image for that, which is something like a 256KiB file
on the host side, exposed as a flash device to the guest?

--=20
dwmw2

=C2=B9 Statements that refer to plans and expectations for the year and the
  future are forward-looking statements that involve a number of risks
  and uncertainties. Words such as =E2=80=9Canticipates,=E2=80=9D =E2=80=9C=
expects,=E2=80=9D =E2=80=9Cintends,=E2=80=9D
  =E2=80=9Cplans,=E2=80=9D =E2=80=9Cbelieves,=E2=80=9D =E2=80=9Cseeks,=E2=
=80=9D =E2=80=9Cestimates,=E2=80=9D =E2=80=9Cmay,=E2=80=9D =E2=80=9Cwill,=
=E2=80=9D =E2=80=9Cshould=E2=80=9D
  and their variations identify forward-looking statements. Statements
  that refer to or are based on projections, uncertain events or
  assumptions also identify forward-looking statements. Many factors
  could affect actual results, and variances from current expectations
  regarding such factors could cause actual results to differ materially
  from those expressed in these forward-looking statements.

--=-ugWV3jn0nW+PR5aQB6uz
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE1MTIwOTQ0WjAjBgkqhkiG9w0BCQQx
FgQUY+mFPpCy1YQ7Nvtey7Wge6+T80swgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQAZyDYKoFpw5sEwng3RaTU47tnZ
UssCNUnwRm3NQLuXrQfI7t3eCE/aM7DD94pHXm7X764g9FnlrFRyAQTiFSl1TZ0MbbSQjWEmnAfQ
W9eeP73yaFpBzwCPZuqrPzG7gPS7+1rxEttcvWWm4C1RkJnlrxHyE1kB2Cc9V5KPuG9J/aBhL7Zp
Hf2IA0Im1oAFC1Pi2FEbbiiZT3O7qSBxL9N0LB/QQ7tu2EVAtlGmnN51i55NHLnOpHpBvH4CPZAg
3Tsrh4fFqCVEu+AY9SeCE/FQSRCpp7ffqrCiz3YfBfamgF8ccTyWkvNSAPqrVdR+k+nEWbo3PMcB
1Ak5BI7Zr9I3AAAAAAAA


--=-ugWV3jn0nW+PR5aQB6uz--



--===============8515652335821685675==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8515652335821685675==--



From xen-devel-bounces@lists.xen.org Fri Feb 15 12:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:10: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 1U6K76-0007v4-Cc; Fri, 15 Feb 2013 12:10:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+a3e01b864c7328904b3a+3463+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U6K74-0007ul-QT
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:09:59 +0000
Received: from [85.158.139.211:44020] by server-13.bemta-5.messagelabs.com id
	F0/9A-06769-5952E115; Fri, 15 Feb 2013 12:09:57 +0000
X-Env-Sender: BATV+a3e01b864c7328904b3a+3463+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1360930196!21171999!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTgxMzk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26244 invoked from network); 15 Feb 2013 12:09:57 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 12:09:57 -0000
Received: from i7.infradead.org ([2001:8b0:10b:1:225:64ff:fee8:e9df])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U6K6x-0000tQ-ML; Fri, 15 Feb 2013 12:09:52 +0000
Message-ID: <1360930184.6534.16.camel@i7.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Fri, 15 Feb 2013 12:09:44 +0000
In-Reply-To: <1360860396.20449.471.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Dario Faggioli <dario.faggioli@citrix.com>, seabios@seabios.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
	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: multipart/mixed; boundary="===============8515652335821685675=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8515652335821685675==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-ugWV3jn0nW+PR5aQB6uz"


--=-ugWV3jn0nW+PR5aQB6uz
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 16:46 +0000, Ian Campbell wrote:
> Right, we really need to find someone with hours to finish properly
> integrating OVMF.

Hm, that 'someone' may end up being me=C2=B9.

So... from the Xen point of view, what needs doing? There are some
things on my TODO list which apply to Qemu/KVM too =E2=80=94 most important=
ly,
fixing bootorder handling, which basically involves fixing the general
case of NV variable storage for UEFI as discussed. But is there anything
Xen-specific that I'm likely to miss?

And on the subject of the NV storage... does -pflash work on qemu-xen,
as long as we're not actually running *code* from the device and we're
only using it for data storage? Are you content with my stated plan to
provide a "disk" image for that, which is something like a 256KiB file
on the host side, exposed as a flash device to the guest?

--=20
dwmw2

=C2=B9 Statements that refer to plans and expectations for the year and the
  future are forward-looking statements that involve a number of risks
  and uncertainties. Words such as =E2=80=9Canticipates,=E2=80=9D =E2=80=9C=
expects,=E2=80=9D =E2=80=9Cintends,=E2=80=9D
  =E2=80=9Cplans,=E2=80=9D =E2=80=9Cbelieves,=E2=80=9D =E2=80=9Cseeks,=E2=
=80=9D =E2=80=9Cestimates,=E2=80=9D =E2=80=9Cmay,=E2=80=9D =E2=80=9Cwill,=
=E2=80=9D =E2=80=9Cshould=E2=80=9D
  and their variations identify forward-looking statements. Statements
  that refer to or are based on projections, uncertain events or
  assumptions also identify forward-looking statements. Many factors
  could affect actual results, and variances from current expectations
  regarding such factors could cause actual results to differ materially
  from those expressed in these forward-looking statements.

--=-ugWV3jn0nW+PR5aQB6uz
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE1MTIwOTQ0WjAjBgkqhkiG9w0BCQQx
FgQUY+mFPpCy1YQ7Nvtey7Wge6+T80swgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQAZyDYKoFpw5sEwng3RaTU47tnZ
UssCNUnwRm3NQLuXrQfI7t3eCE/aM7DD94pHXm7X764g9FnlrFRyAQTiFSl1TZ0MbbSQjWEmnAfQ
W9eeP73yaFpBzwCPZuqrPzG7gPS7+1rxEttcvWWm4C1RkJnlrxHyE1kB2Cc9V5KPuG9J/aBhL7Zp
Hf2IA0Im1oAFC1Pi2FEbbiiZT3O7qSBxL9N0LB/QQ7tu2EVAtlGmnN51i55NHLnOpHpBvH4CPZAg
3Tsrh4fFqCVEu+AY9SeCE/FQSRCpp7ffqrCiz3YfBfamgF8ccTyWkvNSAPqrVdR+k+nEWbo3PMcB
1Ak5BI7Zr9I3AAAAAAAA


--=-ugWV3jn0nW+PR5aQB6uz--



--===============8515652335821685675==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8515652335821685675==--



From xen-devel-bounces@lists.xen.org Fri Feb 15 12:18:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6KF6-0008Kd-Du; Fri, 15 Feb 2013 12:18: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 1U6KF4-0008KY-Rd
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:18:14 +0000
Received: from [85.158.138.51:20331] by server-1.bemta-3.messagelabs.com id
	52/56-08955-5872E115; Fri, 15 Feb 2013 12:18:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360930693!27738690!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28850 invoked from network); 15 Feb 2013 12:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1512174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:18: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.297.1;
	Fri, 15 Feb 2013 12:18:13 +0000
Message-ID: <1360930691.31407.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Fri, 15 Feb 2013 12:18:11 +0000
In-Reply-To: <5111301B.8080304@heliman.it>
References: <5111301B.8080304@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] tools/libxl: Disable useless empty floppy
 drive with 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

On Tue, 2013-02-05 at 16:15 +0000, Fabio Fantoni wrote:
> tools/libxl: Disable useless empty floppy drive with
>   qemu-xen
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   tools/libxl/libxl_dm.c |    3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..c265618 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -406,6 +406,9 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>       if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           int ioemu_nics = 0;
> 
> +        /* Disable useless empty floppy drive */
> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
> +
>           if (b_info->u.hvm.serial) {
>               flexarray_vappend(dm_args, "-serial", 
> b_info->u.hvm.serial, NULL);

I'm afraid this patch is whitespace corrupted. 

I strongly recommend that you investigate the use of git send-email.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:18:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6KF6-0008Kd-Du; Fri, 15 Feb 2013 12:18: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 1U6KF4-0008KY-Rd
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:18:14 +0000
Received: from [85.158.138.51:20331] by server-1.bemta-3.messagelabs.com id
	52/56-08955-5872E115; Fri, 15 Feb 2013 12:18:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360930693!27738690!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28850 invoked from network); 15 Feb 2013 12:18:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1512174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:18: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.297.1;
	Fri, 15 Feb 2013 12:18:13 +0000
Message-ID: <1360930691.31407.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Fri, 15 Feb 2013 12:18:11 +0000
In-Reply-To: <5111301B.8080304@heliman.it>
References: <5111301B.8080304@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] tools/libxl: Disable useless empty floppy
 drive with 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

On Tue, 2013-02-05 at 16:15 +0000, Fabio Fantoni wrote:
> tools/libxl: Disable useless empty floppy drive with
>   qemu-xen
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>   tools/libxl/libxl_dm.c |    3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..c265618 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -406,6 +406,9 @@ static char ** 
> libxl__build_device_model_args_new(libxl__gc *gc,
>       if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           int ioemu_nics = 0;
> 
> +        /* Disable useless empty floppy drive */
> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
> +
>           if (b_info->u.hvm.serial) {
>               flexarray_vappend(dm_args, "-serial", 
> b_info->u.hvm.serial, NULL);

I'm afraid this patch is whitespace corrupted. 

I strongly recommend that you investigate the use of git send-email.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:23:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:23: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 1U6KJj-0008UW-5R; Fri, 15 Feb 2013 12:23: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 1U6KJh-0008UN-Bj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:23:01 +0000
Received: from [85.158.137.99:59549] by server-7.bemta-3.messagelabs.com id
	78/51-10367-4A82E115; Fri, 15 Feb 2013 12:23:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360930977!18447010!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25266 invoked from network); 15 Feb 2013 12:22:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297010"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:22:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:22:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KJc-0001ry-En;
	Fri, 15 Feb 2013 12:22:56 +0000
Date: Fri, 15 Feb 2013 12:22:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151217310.8231@kaball.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++++++++++
>  arch/x86/include/asm/xen/events.h |    2 +
>  drivers/xen/events.c              |   75 ++++++++++++++++++++----------------
>  include/xen/interface/xen.h       |    8 ++--
>  4 files changed, 70 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..92dbb89 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
>  
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xen_read_evtchn_pending_sel(struct vcpu_info *vcpu_info)
> +{
> +	xen_ulong_t val;
> +	unsigned int tmp;
> +
> +	wmb();
> +	asm volatile("@ read_evtchn_pending_sel\n"
> +		"1:     ldrexd  %0, %H0, [%3]\n"
> +		"       strexd  %1, %2, %H2, [%3]\n"
> +		"       teq     %1, #0\n"
> +		"       bne     1b"
> +			: "=&r" (val), "=&r" (tmp)
> +			: "r" (0), "r" (&vcpu_info->evtchn_pending_sel)
> +			: "memory", "cc");
> +	return val;
> +}

At this point we might as well introduce an xchg64, it is going to be
more useful to us in the future and to other non-Xen people too.



>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index cc146d5..55edd58 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,6 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->flags);
>  }
>  
> +#define xen_read_evtchn_pending_sel(v) xchg(&(v)->evtchn_pending_sel, 0)
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 0be4df3..e90a440 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -80,6 +80,12 @@ enum xen_irq_type {
>  };
>  
>  /*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +
> +/*
>   * Packed IRQ information:
>   * type - enum xen_irq_type
>   * event channel - irq->event channel mapping
> @@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>  		      cpu_evtchn_mask);
>  
>  /* Xen will never allocate port zero for any purpose. */
> @@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>  	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
>  #endif
>  
> -	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> +	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> +	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
>  
>  	info_for_irq(irq)->cpu = cpu;
>  }
> @@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
>  static inline void clear_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_clear_bit(port, &s->evtchn_pending[0]);
> +	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline void set_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_pending[0]);
> +	sync_set_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline int test_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_bit(port, &s->evtchn_pending[0]);
> +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  

Are you sure that the implementation of sync_test_bit, sync_set_bit,
etc, can cope with a bit > 32?
For example ____atomic_set_bit blatantly (bit & 31) at the beginning of
the function.


> @@ -375,7 +383,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  static void mask_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_mask[0]);
> +	sync_set_bit(port, BM(&s->evtchn_mask[0]));
>  }
>  
>  static void unmask_evtchn(int port)
> @@ -389,7 +397,7 @@ static void unmask_evtchn(int port)
>  	if (unlikely((cpu != cpu_from_evtchn(port))))
>  		do_hypercall = 1;
>  	else
> -		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> +		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  
>  	if (unlikely(evtchn_pending && xen_hvm_domain()))
>  		do_hypercall = 1;
> @@ -403,7 +411,7 @@ static void unmask_evtchn(int port)
>  	} else {
>  		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>  
> -		sync_clear_bit(port, &s->evtchn_mask[0]);
> +		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
>  
>  		/*
>  		 * The following is basically the equivalent of
> @@ -411,8 +419,8 @@ static void unmask_evtchn(int port)
>  		 * the interrupt edge' if the channel is masked.
>  		 */
>  		if (evtchn_pending &&
> -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> -					   &vcpu_info->evtchn_pending_sel))
> +		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> +					   BM(&vcpu_info->evtchn_pending_sel)))
>  			vcpu_info->evtchn_upcall_pending = 1;
>  	}
>  
> @@ -1189,7 +1197,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
>  	struct shared_info *sh = HYPERVISOR_shared_info;
>  	int cpu = smp_processor_id();
> -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
>  	int i;
>  	unsigned long flags;
>  	static DEFINE_SPINLOCK(debug_lock);
> @@ -1205,7 +1213,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		pending = (get_irq_regs() && i == cpu)
>  			? xen_irqs_disabled(get_irq_regs())
>  			: v->evtchn_upcall_mask;
> -		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> +		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
>  		       pending, v->evtchn_upcall_pending,
>  		       (int)(sizeof(v->evtchn_pending_sel)*2),
>  		       v->evtchn_pending_sel);
> @@ -1214,25 +1222,27 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  
>  	printk("\npending:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)sizeof(sh->evtchn_pending[0])*2,
>  		       sh->evtchn_pending[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  	printk("\nglobal mask:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s",
> +		printk("%0*"PRI_xen_ulong"%s",
>  		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nglobally unmasked:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nlocal cpu%d mask:\n   ", cpu);
> -	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> +	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> +		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
>  		       cpu_evtchn[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
> @@ -1247,16 +1257,16 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  
>  	printk("\npending list:\n");
>  	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -		if (sync_test_bit(i, sh->evtchn_pending)) {
> -			int word_idx = i / BITS_PER_LONG;
> +		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> +			int word_idx = i / BITS_PER_EVTCHN_WORD;
>  			printk("  %d: event %d -> irq %d%s%s%s\n",
>  			       cpu_from_evtchn(i), i,
>  			       evtchn_to_irq[i],
> -			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
>  					     ? "" : " l2-clear",
> -			       !sync_test_bit(i, sh->evtchn_mask)
> +			       !sync_test_bit(i, BM(sh->evtchn_mask))
>  					     ? "" : " globally-masked",
> -			       sync_test_bit(i, cpu_evtchn)
> +			       sync_test_bit(i, BM(cpu_evtchn))
>  					     ? "" : " locally-masked");
>  		}
>  	}
> @@ -1304,9 +1314,8 @@ static void __xen_evtchn_do_upcall(void)
>  
>  #ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
>  		/* Clear master flag /before/ clearing selector flag. */
> -		wmb();
>  #endif
> -		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +		pending_words = xen_read_evtchn_pending_sel(vcpu_info);
>  
>  		start_word_idx = __this_cpu_read(current_word_idx);
>  		start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1355,7 +1364,7 @@ static void __xen_evtchn_do_upcall(void)
>  				bit_idx = __ffs(bits);
>  
>  				/* Process port. */
> -				port = (word_idx * BITS_PER_LONG) + bit_idx;
> +				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
>  				irq = evtchn_to_irq[port];
>  
>  				if (irq != -1) {
> @@ -1364,12 +1373,12 @@ static void __xen_evtchn_do_upcall(void)
>  						generic_handle_irq_desc(irq, desc);
>  				}
>  
> -				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
>  
>  				/* Next caller starts at last processed + 1 */
>  				__this_cpu_write(current_word_idx,
>  						 bit_idx ? word_idx :
> -						 (word_idx+1) % BITS_PER_LONG);
> +						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
>  				__this_cpu_write(current_bit_idx, bit_idx);
>  			} while (bit_idx != 0);
>  
> @@ -1377,7 +1386,7 @@ static void __xen_evtchn_do_upcall(void)
>  			if ((word_idx != start_word_idx) || (i != 0))
>  				pending_words &= ~(1UL << word_idx);
>  
> -			word_idx = (word_idx + 1) % BITS_PER_LONG;
> +			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
>  		}
>  
>  		BUG_ON(!irqs_disabled());
> @@ -1487,8 +1496,8 @@ int resend_irq_on_evtchn(unsigned int irq)
>  	if (!VALID_EVTCHN(evtchn))
>  		return 1;
>  
> -	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> -	sync_set_bit(evtchn, s->evtchn_pending);
> +	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> +	sync_set_bit(evtchn, BM(s->evtchn_pending));
>  	if (!masked)
>  		unmask_evtchn(evtchn);
>  
> @@ -1536,8 +1545,8 @@ static int retrigger_dynirq(struct irq_data *data)
>  	if (VALID_EVTCHN(evtchn)) {
>  		int masked;
>  
> -		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> -		sync_set_bit(evtchn, sh->evtchn_pending);
> +		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> +		sync_set_bit(evtchn, BM(sh->evtchn_pending));
>  		if (!masked)
>  			unmask_evtchn(evtchn);
>  		ret = 1;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 886a5d8..53ec416 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>  	/*
> @@ -341,7 +341,7 @@ struct vcpu_info {
>  	 */
>  	uint8_t evtchn_upcall_pending;
>  	uint8_t evtchn_upcall_mask;
> -	unsigned long evtchn_pending_sel;
> +	xen_ulong_t evtchn_pending_sel;
>  	struct arch_vcpu_info arch;
>  	struct pvclock_vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -384,8 +384,8 @@ struct shared_info {
>  	 * per-vcpu selector word to be set. Each bit in the selector covers a
>  	 * 'C long' in the PENDING bitfield array.
>  	 */
> -	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>  	/*
>  	 * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.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 Feb 15 12:23:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:23: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 1U6KJj-0008UW-5R; Fri, 15 Feb 2013 12:23: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 1U6KJh-0008UN-Bj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:23:01 +0000
Received: from [85.158.137.99:59549] by server-7.bemta-3.messagelabs.com id
	78/51-10367-4A82E115; Fri, 15 Feb 2013 12:23:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360930977!18447010!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25266 invoked from network); 15 Feb 2013 12:22:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297010"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:22:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:22:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KJc-0001ry-En;
	Fri, 15 Feb 2013 12:22:56 +0000
Date: Fri, 15 Feb 2013 12:22:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151217310.8231@kaball.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++++++++++
>  arch/x86/include/asm/xen/events.h |    2 +
>  drivers/xen/events.c              |   75 ++++++++++++++++++++----------------
>  include/xen/interface/xen.h       |    8 ++--
>  4 files changed, 70 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..92dbb89 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
>  
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xen_read_evtchn_pending_sel(struct vcpu_info *vcpu_info)
> +{
> +	xen_ulong_t val;
> +	unsigned int tmp;
> +
> +	wmb();
> +	asm volatile("@ read_evtchn_pending_sel\n"
> +		"1:     ldrexd  %0, %H0, [%3]\n"
> +		"       strexd  %1, %2, %H2, [%3]\n"
> +		"       teq     %1, #0\n"
> +		"       bne     1b"
> +			: "=&r" (val), "=&r" (tmp)
> +			: "r" (0), "r" (&vcpu_info->evtchn_pending_sel)
> +			: "memory", "cc");
> +	return val;
> +}

At this point we might as well introduce an xchg64, it is going to be
more useful to us in the future and to other non-Xen people too.



>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index cc146d5..55edd58 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,6 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->flags);
>  }
>  
> +#define xen_read_evtchn_pending_sel(v) xchg(&(v)->evtchn_pending_sel, 0)
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 0be4df3..e90a440 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -80,6 +80,12 @@ enum xen_irq_type {
>  };
>  
>  /*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +
> +/*
>   * Packed IRQ information:
>   * type - enum xen_irq_type
>   * event channel - irq->event channel mapping
> @@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>  		      cpu_evtchn_mask);
>  
>  /* Xen will never allocate port zero for any purpose. */
> @@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>  	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
>  #endif
>  
> -	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> +	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> +	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
>  
>  	info_for_irq(irq)->cpu = cpu;
>  }
> @@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
>  static inline void clear_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_clear_bit(port, &s->evtchn_pending[0]);
> +	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline void set_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_pending[0]);
> +	sync_set_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline int test_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_bit(port, &s->evtchn_pending[0]);
> +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  

Are you sure that the implementation of sync_test_bit, sync_set_bit,
etc, can cope with a bit > 32?
For example ____atomic_set_bit blatantly (bit & 31) at the beginning of
the function.


> @@ -375,7 +383,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  static void mask_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_mask[0]);
> +	sync_set_bit(port, BM(&s->evtchn_mask[0]));
>  }
>  
>  static void unmask_evtchn(int port)
> @@ -389,7 +397,7 @@ static void unmask_evtchn(int port)
>  	if (unlikely((cpu != cpu_from_evtchn(port))))
>  		do_hypercall = 1;
>  	else
> -		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> +		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  
>  	if (unlikely(evtchn_pending && xen_hvm_domain()))
>  		do_hypercall = 1;
> @@ -403,7 +411,7 @@ static void unmask_evtchn(int port)
>  	} else {
>  		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>  
> -		sync_clear_bit(port, &s->evtchn_mask[0]);
> +		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
>  
>  		/*
>  		 * The following is basically the equivalent of
> @@ -411,8 +419,8 @@ static void unmask_evtchn(int port)
>  		 * the interrupt edge' if the channel is masked.
>  		 */
>  		if (evtchn_pending &&
> -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> -					   &vcpu_info->evtchn_pending_sel))
> +		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> +					   BM(&vcpu_info->evtchn_pending_sel)))
>  			vcpu_info->evtchn_upcall_pending = 1;
>  	}
>  
> @@ -1189,7 +1197,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
>  	struct shared_info *sh = HYPERVISOR_shared_info;
>  	int cpu = smp_processor_id();
> -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
>  	int i;
>  	unsigned long flags;
>  	static DEFINE_SPINLOCK(debug_lock);
> @@ -1205,7 +1213,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		pending = (get_irq_regs() && i == cpu)
>  			? xen_irqs_disabled(get_irq_regs())
>  			: v->evtchn_upcall_mask;
> -		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> +		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
>  		       pending, v->evtchn_upcall_pending,
>  		       (int)(sizeof(v->evtchn_pending_sel)*2),
>  		       v->evtchn_pending_sel);
> @@ -1214,25 +1222,27 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  
>  	printk("\npending:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)sizeof(sh->evtchn_pending[0])*2,
>  		       sh->evtchn_pending[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  	printk("\nglobal mask:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s",
> +		printk("%0*"PRI_xen_ulong"%s",
>  		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nglobally unmasked:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nlocal cpu%d mask:\n   ", cpu);
> -	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> +	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> +		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
>  		       cpu_evtchn[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
> @@ -1247,16 +1257,16 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  
>  	printk("\npending list:\n");
>  	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -		if (sync_test_bit(i, sh->evtchn_pending)) {
> -			int word_idx = i / BITS_PER_LONG;
> +		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> +			int word_idx = i / BITS_PER_EVTCHN_WORD;
>  			printk("  %d: event %d -> irq %d%s%s%s\n",
>  			       cpu_from_evtchn(i), i,
>  			       evtchn_to_irq[i],
> -			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
>  					     ? "" : " l2-clear",
> -			       !sync_test_bit(i, sh->evtchn_mask)
> +			       !sync_test_bit(i, BM(sh->evtchn_mask))
>  					     ? "" : " globally-masked",
> -			       sync_test_bit(i, cpu_evtchn)
> +			       sync_test_bit(i, BM(cpu_evtchn))
>  					     ? "" : " locally-masked");
>  		}
>  	}
> @@ -1304,9 +1314,8 @@ static void __xen_evtchn_do_upcall(void)
>  
>  #ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
>  		/* Clear master flag /before/ clearing selector flag. */
> -		wmb();
>  #endif
> -		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +		pending_words = xen_read_evtchn_pending_sel(vcpu_info);
>  
>  		start_word_idx = __this_cpu_read(current_word_idx);
>  		start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1355,7 +1364,7 @@ static void __xen_evtchn_do_upcall(void)
>  				bit_idx = __ffs(bits);
>  
>  				/* Process port. */
> -				port = (word_idx * BITS_PER_LONG) + bit_idx;
> +				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
>  				irq = evtchn_to_irq[port];
>  
>  				if (irq != -1) {
> @@ -1364,12 +1373,12 @@ static void __xen_evtchn_do_upcall(void)
>  						generic_handle_irq_desc(irq, desc);
>  				}
>  
> -				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
>  
>  				/* Next caller starts at last processed + 1 */
>  				__this_cpu_write(current_word_idx,
>  						 bit_idx ? word_idx :
> -						 (word_idx+1) % BITS_PER_LONG);
> +						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
>  				__this_cpu_write(current_bit_idx, bit_idx);
>  			} while (bit_idx != 0);
>  
> @@ -1377,7 +1386,7 @@ static void __xen_evtchn_do_upcall(void)
>  			if ((word_idx != start_word_idx) || (i != 0))
>  				pending_words &= ~(1UL << word_idx);
>  
> -			word_idx = (word_idx + 1) % BITS_PER_LONG;
> +			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
>  		}
>  
>  		BUG_ON(!irqs_disabled());
> @@ -1487,8 +1496,8 @@ int resend_irq_on_evtchn(unsigned int irq)
>  	if (!VALID_EVTCHN(evtchn))
>  		return 1;
>  
> -	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> -	sync_set_bit(evtchn, s->evtchn_pending);
> +	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> +	sync_set_bit(evtchn, BM(s->evtchn_pending));
>  	if (!masked)
>  		unmask_evtchn(evtchn);
>  
> @@ -1536,8 +1545,8 @@ static int retrigger_dynirq(struct irq_data *data)
>  	if (VALID_EVTCHN(evtchn)) {
>  		int masked;
>  
> -		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> -		sync_set_bit(evtchn, sh->evtchn_pending);
> +		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> +		sync_set_bit(evtchn, BM(sh->evtchn_pending));
>  		if (!masked)
>  			unmask_evtchn(evtchn);
>  		ret = 1;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 886a5d8..53ec416 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>  	/*
> @@ -341,7 +341,7 @@ struct vcpu_info {
>  	 */
>  	uint8_t evtchn_upcall_pending;
>  	uint8_t evtchn_upcall_mask;
> -	unsigned long evtchn_pending_sel;
> +	xen_ulong_t evtchn_pending_sel;
>  	struct arch_vcpu_info arch;
>  	struct pvclock_vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -384,8 +384,8 @@ struct shared_info {
>  	 * per-vcpu selector word to be set. Each bit in the selector covers a
>  	 * 'C long' in the PENDING bitfield array.
>  	 */
> -	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>  	/*
>  	 * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.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 Feb 15 12:27:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:27: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 1U6KNi-0000FD-18; Fri, 15 Feb 2013 12:27: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 1U6KNh-0000F7-Co
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:27:09 +0000
Received: from [85.158.139.83:64211] by server-6.bemta-5.messagelabs.com id
	3C/3F-01489-C992E115; Fri, 15 Feb 2013 12:27:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360931226!27719343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20910 invoked from network); 15 Feb 2013 12:27:07 -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;
	15 Feb 2013 12:27:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297509"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:27:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:27:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KNd-0001vW-6v;
	Fri, 15 Feb 2013 12:27:05 +0000
Date: Fri, 15 Feb 2013 12:27:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Zhou Peng <zpengxen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="qxl"
> 
> Changes from v8:
> - vga=qxl instead of qxl=1 to use it.
> - Show an error and exit if vga="qxl" without qemu upstream.
> - Other small improvements.
> 
> Required patches:
> - Improve videoram setting v5
> - Added vga parameter for hvm domUs
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> Signed-off-by: Zhou Peng <zpengxen@gmail.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5       |   10 +++++++++-
>  tools/libxl/libxl_create.c  |   17 +++++++++++++++++
>  tools/libxl/libxl_dm.c      |   13 +++++++++++++
>  tools/libxl/libxl_types.idl |    1 +
>  tools/libxl/xl_cmdimpl.c    |    3 +++
>  5 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9862842..a3b3645 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
>  
> +For B<qxl> vga, the default is both default and minimal 128MB.
> +If B<videoram> is set less than 128MB, an error will be triggered.
> +
>  =item B<stdvga=BOOLEAN>
>  
>  Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> @@ -995,9 +998,14 @@ This option is deprecated, use vga="stdvga" instead.
>  
>  =item B<vga="STRING">
>  
> -Selects the emulated video card (stdvga|cirrus).
> +Selects the emulated video card (stdvga|cirrus|qxl).
>  The default is cirrus.
>  
> +In general, QXL should work with the Spice remote display protocol
> +for acceleration, and QXL driver is necessary in guest in this case.
> +QXL can also work with the VNC protocol, but it will be like a standard
> +VGA without acceleration.
> +
>  =item B<vnc=BOOLEAN>
>  
>  Allow access to the display via the VNC protocol.  This enables the
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index cf545ef..67b5e6e 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -197,6 +197,23 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>      case LIBXL_DOMAIN_TYPE_HVM:
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
> +
> +        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->device_model_version ==
> +               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                    b_info->video_memkb = (128 * 1024);
> +                }else if (b_info->video_memkb < (128 * 1024)) {
> +                    LOG(ERROR,
> +                    "128 Mib videoram is the minimum for qxl default");
> +                    return ERROR_INVAL;
> +                }
> +            } else {
> +                LOG(ERROR,"qemu upstream required for qxl vga");
> +                return ERROR_INVAL;
> +            }
> +        }
> +
>          if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->video_memkb = 8 * 1024;
>          else if (b_info->video_memkb < 8192){
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index a2c99bd..59fc86a 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            break;
>          }
>  
>          if (b_info->u.hvm.boot) {
> @@ -440,6 +442,17 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                  NULL);
>              }
>              break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            /*QXL have 2 ram regions, ram and vram*/
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), "-global",
> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), NULL);
> +            }
> +            break;
>          }
>  
>          if (b_info->u.hvm.boot) {
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index acc4bc9..3f90f12 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
>  libxl_vga_interface_type = Enumeration("vga_interface_type", [
>      (1, "CIRRUS"),
>      (2, "STD"),
> +    (3, "QXL"),
>      ], init_val = 0)
>  
>  #
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index f9101ba..b20c185 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1476,6 +1476,9 @@ skip_vfb:
>              } else if (!strcmp(buf, "cirrus")) {
>                  b_info->u.hvm.vga.kind
>                  = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +            }else if (!strcmp(buf, "qxl")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_QXL;
>              } else {
>                  fprintf(stderr,
>                  "Unknown vga \"%s\" specified\n", buf);
> -- 
> 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 Fri Feb 15 12:27:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:27: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 1U6KNi-0000FD-18; Fri, 15 Feb 2013 12:27: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 1U6KNh-0000F7-Co
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:27:09 +0000
Received: from [85.158.139.83:64211] by server-6.bemta-5.messagelabs.com id
	3C/3F-01489-C992E115; Fri, 15 Feb 2013 12:27:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360931226!27719343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20910 invoked from network); 15 Feb 2013 12:27:07 -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;
	15 Feb 2013 12:27:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297509"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:27:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:27:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KNd-0001vW-6v;
	Fri, 15 Feb 2013 12:27:05 +0000
Date: Fri, 15 Feb 2013 12:27:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Zhou Peng <zpengxen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="qxl"
> 
> Changes from v8:
> - vga=qxl instead of qxl=1 to use it.
> - Show an error and exit if vga="qxl" without qemu upstream.
> - Other small improvements.
> 
> Required patches:
> - Improve videoram setting v5
> - Added vga parameter for hvm domUs
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> Signed-off-by: Zhou Peng <zpengxen@gmail.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5       |   10 +++++++++-
>  tools/libxl/libxl_create.c  |   17 +++++++++++++++++
>  tools/libxl/libxl_dm.c      |   13 +++++++++++++
>  tools/libxl/libxl_types.idl |    1 +
>  tools/libxl/xl_cmdimpl.c    |    3 +++
>  5 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9862842..a3b3645 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -984,6 +984,9 @@ the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
>  
> +For B<qxl> vga, the default is both default and minimal 128MB.
> +If B<videoram> is set less than 128MB, an error will be triggered.
> +
>  =item B<stdvga=BOOLEAN>
>  
>  Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> @@ -995,9 +998,14 @@ This option is deprecated, use vga="stdvga" instead.
>  
>  =item B<vga="STRING">
>  
> -Selects the emulated video card (stdvga|cirrus).
> +Selects the emulated video card (stdvga|cirrus|qxl).
>  The default is cirrus.
>  
> +In general, QXL should work with the Spice remote display protocol
> +for acceleration, and QXL driver is necessary in guest in this case.
> +QXL can also work with the VNC protocol, but it will be like a standard
> +VGA without acceleration.
> +
>  =item B<vnc=BOOLEAN>
>  
>  Allow access to the display via the VNC protocol.  This enables the
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index cf545ef..67b5e6e 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -197,6 +197,23 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>      case LIBXL_DOMAIN_TYPE_HVM:
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
> +
> +        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->device_model_version ==
> +               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                    b_info->video_memkb = (128 * 1024);
> +                }else if (b_info->video_memkb < (128 * 1024)) {
> +                    LOG(ERROR,
> +                    "128 Mib videoram is the minimum for qxl default");
> +                    return ERROR_INVAL;
> +                }
> +            } else {
> +                LOG(ERROR,"qemu upstream required for qxl vga");
> +                return ERROR_INVAL;
> +            }
> +        }
> +
>          if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->video_memkb = 8 * 1024;
>          else if (b_info->video_memkb < 8192){
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index a2c99bd..59fc86a 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            break;
>          }
>  
>          if (b_info->u.hvm.boot) {
> @@ -440,6 +442,17 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                  NULL);
>              }
>              break;
> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            /*QXL have 2 ram regions, ram and vram*/
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), "-global",
> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), NULL);
> +            }
> +            break;
>          }
>  
>          if (b_info->u.hvm.boot) {
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index acc4bc9..3f90f12 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
>  libxl_vga_interface_type = Enumeration("vga_interface_type", [
>      (1, "CIRRUS"),
>      (2, "STD"),
> +    (3, "QXL"),
>      ], init_val = 0)
>  
>  #
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index f9101ba..b20c185 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1476,6 +1476,9 @@ skip_vfb:
>              } else if (!strcmp(buf, "cirrus")) {
>                  b_info->u.hvm.vga.kind
>                  = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +            }else if (!strcmp(buf, "qxl")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_QXL;
>              } else {
>                  fprintf(stderr,
>                  "Unknown vga \"%s\" specified\n", buf);
> -- 
> 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 Fri Feb 15 12:27:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:27: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 1U6KO7-0000H4-Ei; Fri, 15 Feb 2013 12:27: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 1U6KO5-0000Gp-PJ
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:27:33 +0000
Received: from [85.158.139.211:65186] by server-3.bemta-5.messagelabs.com id
	E7/0B-07037-4B92E115; Fri, 15 Feb 2013 12:27:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360931250!22220245!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8835 invoked from network); 15 Feb 2013 12:27:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:27:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7669318"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:27:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:27:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KO1-0001vl-QD;
	Fri, 15 Feb 2013 12:27:29 +0000
Date: Fri, 15 Feb 2013 12:27:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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

On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> - If videoram setting is less than 8 mb shows error and exit.
> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
> - Updated xl.cfg man.
> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>   qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
>   (qemu 1.3 doesn't complain about it, probably buggy).
> 
> Changes from v5:
> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>   qemu is being used.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5      |   14 +++++---------
>  tools/libxl/libxl_create.c |   18 +++++++++++++++++-
>  tools/libxl/libxl_dm.c     |    6 ++++++
>  3 files changed, 28 insertions(+), 10 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index caba162..9c5cdcd 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
>  
>  Sets the amount of RAM which the emulated video card will contain,
>  which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B<stdvga>
> -option (see below).
> +available.
>  The default amount of video ram for stdvga is 8MB which is sufficient
> -for e.g. 1600x1200 at 32bpp.
> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
> +only when using the qemu-xen-traditional device-model.
>  
>  When using the emulated Cirrus graphics card (B<stdvga=0>)
>  the amount of video ram is fixed at 4MB which is sufficient
> -for 1024x768 at 32 bpp.
> -
> -videoram option is currently only available when using the
> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
> -currently does not support changing the amount of video memory for the
> -emulated graphics device.
> +for 1024x768 at 32 bpp and videoram option is currently working
> +only when using the upstream qemu-xen device-model.
>  
>  =item B<stdvga=BOOLEAN>
>  
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a8dfe61..fa81f88 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -197,8 +197,24 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>      case LIBXL_DOMAIN_TYPE_HVM:
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
> -        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +
> +        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
> +            b_info->device_model_version ==
> +            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +                    b_info->video_memkb = 16 * 1024;
> +                else if (b_info->video_memkb < (16 * 1024) ){
> +                    LOG(ERROR,
> +                    "videoram must be at least 16 mb with stdvga");
> +                    return ERROR_INVAL;
> +                }
> +        } else if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->video_memkb = 8 * 1024;
> +        else if (b_info->video_memkb < (8 * 1024) ){
> +            LOG(ERROR,"videoram must be at least 8 mb");
> +            return ERROR_INVAL;
> +        }
> +
>          if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
>              b_info->u.hvm.timer_mode =
>                  LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..465b1fd 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -430,6 +430,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "vga.vram_size_mb=%d",
> +                libxl__sizekb_to_mb(b_info->video_memkb)),
> +                NULL);
> +            }
>              break;
>          }
>  
> -- 
> 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 Fri Feb 15 12:27:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:27: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 1U6KO7-0000H4-Ei; Fri, 15 Feb 2013 12:27: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 1U6KO5-0000Gp-PJ
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:27:33 +0000
Received: from [85.158.139.211:65186] by server-3.bemta-5.messagelabs.com id
	E7/0B-07037-4B92E115; Fri, 15 Feb 2013 12:27:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360931250!22220245!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8835 invoked from network); 15 Feb 2013 12:27:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:27:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7669318"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:27:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:27:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KO1-0001vl-QD;
	Fri, 15 Feb 2013 12:27:29 +0000
Date: Fri, 15 Feb 2013 12:27:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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

On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> - If videoram setting is less than 8 mb shows error and exit.
> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
> - Updated xl.cfg man.
> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>   qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
>   (qemu 1.3 doesn't complain about it, probably buggy).
> 
> Changes from v5:
> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>   qemu is being used.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5      |   14 +++++---------
>  tools/libxl/libxl_create.c |   18 +++++++++++++++++-
>  tools/libxl/libxl_dm.c     |    6 ++++++
>  3 files changed, 28 insertions(+), 10 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index caba162..9c5cdcd 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -974,19 +974,15 @@ in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
>  
>  Sets the amount of RAM which the emulated video card will contain,
>  which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B<stdvga>
> -option (see below).
> +available.
>  The default amount of video ram for stdvga is 8MB which is sufficient
> -for e.g. 1600x1200 at 32bpp.
> +for e.g. 1600x1200 at 32bpp and videoram option is currently working
> +only when using the qemu-xen-traditional device-model.
>  
>  When using the emulated Cirrus graphics card (B<stdvga=0>)
>  the amount of video ram is fixed at 4MB which is sufficient
> -for 1024x768 at 32 bpp.
> -
> -videoram option is currently only available when using the
> -qemu-xen-traditional device-model. Upstream qemu-xen device-model
> -currently does not support changing the amount of video memory for the
> -emulated graphics device.
> +for 1024x768 at 32 bpp and videoram option is currently working
> +only when using the upstream qemu-xen device-model.
>  
>  =item B<stdvga=BOOLEAN>
>  
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index a8dfe61..fa81f88 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -197,8 +197,24 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>      case LIBXL_DOMAIN_TYPE_HVM:
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
> -        if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +
> +        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
> +            b_info->device_model_version ==
> +            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
> +                    b_info->video_memkb = 16 * 1024;
> +                else if (b_info->video_memkb < (16 * 1024) ){
> +                    LOG(ERROR,
> +                    "videoram must be at least 16 mb with stdvga");
> +                    return ERROR_INVAL;
> +                }
> +        } else if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->video_memkb = 8 * 1024;
> +        else if (b_info->video_memkb < (8 * 1024) ){
> +            LOG(ERROR,"videoram must be at least 8 mb");
> +            return ERROR_INVAL;
> +        }
> +
>          if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
>              b_info->u.hvm.timer_mode =
>                  LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 51f9914..465b1fd 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -430,6 +430,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "vga.vram_size_mb=%d",
> +                libxl__sizekb_to_mb(b_info->video_memkb)),
> +                NULL);
> +            }
>              break;
>          }
>  
> -- 
> 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 Fri Feb 15 12:29:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6KPc-0000RV-Ul; Fri, 15 Feb 2013 12:29: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 1U6KPb-0000RH-53
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:29:07 +0000
Received: from [85.158.143.35:14975] by server-2.bemta-4.messagelabs.com id
	6D/73-01597-21A2E115; Fri, 15 Feb 2013 12:29:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360931208!11643883!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22388 invoked from network); 15 Feb 2013 12:26:49 -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;
	15 Feb 2013 12:26:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297489"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:26:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:26:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KNK-0001ur-Ud;
	Fri, 15 Feb 2013 12:26:46 +0000
Date: Fri, 15 Feb 2013 12:26:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="stdvga"|"cirrus"
> 
> - Default option is cirrus.
> - Prints error and exit if unknown value is passed.
> - stdvga parameter is now deprecated.
> - Updated xl.cfg man.
> 
> Required patch: Improve videoram setting v5
> Is prerequisite for patch: Add qxl support v9
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5    |    8 +++++++-
>  tools/libxl/xl_cmdimpl.c |   14 +++++++++++++-
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9c5cdcd..9862842 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -979,7 +979,7 @@ The default amount of video ram for stdvga is 8MB which is sufficient
>  for e.g. 1600x1200 at 32bpp and videoram option is currently working
>  only when using the qemu-xen-traditional device-model.
>  
> -When using the emulated Cirrus graphics card (B<stdvga=0>)
> +When using the emulated Cirrus graphics card (B<vga="cirrus">)
>  the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
> @@ -991,6 +991,12 @@ emulated graphics device. The default is false which means to emulate
>  a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>  later (e.g. Windows XP onwards) then you should enable this.
>  stdvga supports more video ram and bigger resolutions than Cirrus.
> +This option is deprecated, use vga="stdvga" instead.
> +
> +=item B<vga="STRING">
> +
> +Selects the emulated video card (stdvga|cirrus).
> +The default is cirrus.
>  
>  =item B<vnc=BOOLEAN>
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080bbd8..f9101ba 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1469,7 +1469,19 @@ skip_vfb:
>  #undef parse_extra_args
>  
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +        if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_STD;
> +            } else if (!strcmp(buf, "cirrus")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +            } else {
> +                fprintf(stderr,
> +                "Unknown vga \"%s\" specified\n", buf);
> +                exit(1);
> +            }
> +        } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>              b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
>                                           LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>  
> -- 
> 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 Fri Feb 15 12:29:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6KPc-0000RV-Ul; Fri, 15 Feb 2013 12:29: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 1U6KPb-0000RH-53
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:29:07 +0000
Received: from [85.158.143.35:14975] by server-2.bemta-4.messagelabs.com id
	6D/73-01597-21A2E115; Fri, 15 Feb 2013 12:29:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360931208!11643883!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22388 invoked from network); 15 Feb 2013 12:26:49 -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;
	15 Feb 2013 12:26:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297489"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:26:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:26:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KNK-0001ur-Ud;
	Fri, 15 Feb 2013 12:26:46 +0000
Date: Fri, 15 Feb 2013 12:26:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="stdvga"|"cirrus"
> 
> - Default option is cirrus.
> - Prints error and exit if unknown value is passed.
> - stdvga parameter is now deprecated.
> - Updated xl.cfg man.
> 
> Required patch: Improve videoram setting v5
> Is prerequisite for patch: Add qxl support v9
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5    |    8 +++++++-
>  tools/libxl/xl_cmdimpl.c |   14 +++++++++++++-
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9c5cdcd..9862842 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -979,7 +979,7 @@ The default amount of video ram for stdvga is 8MB which is sufficient
>  for e.g. 1600x1200 at 32bpp and videoram option is currently working
>  only when using the qemu-xen-traditional device-model.
>  
> -When using the emulated Cirrus graphics card (B<stdvga=0>)
> +When using the emulated Cirrus graphics card (B<vga="cirrus">)
>  the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
> @@ -991,6 +991,12 @@ emulated graphics device. The default is false which means to emulate
>  a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>  later (e.g. Windows XP onwards) then you should enable this.
>  stdvga supports more video ram and bigger resolutions than Cirrus.
> +This option is deprecated, use vga="stdvga" instead.
> +
> +=item B<vga="STRING">
> +
> +Selects the emulated video card (stdvga|cirrus).
> +The default is cirrus.
>  
>  =item B<vnc=BOOLEAN>
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080bbd8..f9101ba 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1469,7 +1469,19 @@ skip_vfb:
>  #undef parse_extra_args
>  
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +        if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_STD;
> +            } else if (!strcmp(buf, "cirrus")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +            } else {
> +                fprintf(stderr,
> +                "Unknown vga \"%s\" specified\n", buf);
> +                exit(1);
> +            }
> +        } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>              b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
>                                           LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>  
> -- 
> 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 Fri Feb 15 12:30:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6KR5-0000Za-FD; Fri, 15 Feb 2013 12:30:39 +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 1U6KR3-0000ZM-G5
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:30:37 +0000
Received: from [193.109.254.147:40259] by server-10.bemta-14.messagelabs.com
	id 24/20-12679-C6A2E115; Fri, 15 Feb 2013 12:30:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360931430!8606318!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25409 invoked from network); 15 Feb 2013 12:30:31 -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;
	15 Feb 2013 12:30:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297489"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:26:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:26:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KNK-0001ur-Ud;
	Fri, 15 Feb 2013 12:26:46 +0000
Date: Fri, 15 Feb 2013 12:26:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="stdvga"|"cirrus"
> 
> - Default option is cirrus.
> - Prints error and exit if unknown value is passed.
> - stdvga parameter is now deprecated.
> - Updated xl.cfg man.
> 
> Required patch: Improve videoram setting v5
> Is prerequisite for patch: Add qxl support v9
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5    |    8 +++++++-
>  tools/libxl/xl_cmdimpl.c |   14 +++++++++++++-
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9c5cdcd..9862842 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -979,7 +979,7 @@ The default amount of video ram for stdvga is 8MB which is sufficient
>  for e.g. 1600x1200 at 32bpp and videoram option is currently working
>  only when using the qemu-xen-traditional device-model.
>  
> -When using the emulated Cirrus graphics card (B<stdvga=0>)
> +When using the emulated Cirrus graphics card (B<vga="cirrus">)
>  the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
> @@ -991,6 +991,12 @@ emulated graphics device. The default is false which means to emulate
>  a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>  later (e.g. Windows XP onwards) then you should enable this.
>  stdvga supports more video ram and bigger resolutions than Cirrus.
> +This option is deprecated, use vga="stdvga" instead.
> +
> +=item B<vga="STRING">
> +
> +Selects the emulated video card (stdvga|cirrus).
> +The default is cirrus.
>  
>  =item B<vnc=BOOLEAN>
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080bbd8..f9101ba 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1469,7 +1469,19 @@ skip_vfb:
>  #undef parse_extra_args
>  
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +        if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_STD;
> +            } else if (!strcmp(buf, "cirrus")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +            } else {
> +                fprintf(stderr,
> +                "Unknown vga \"%s\" specified\n", buf);
> +                exit(1);
> +            }
> +        } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>              b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
>                                           LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>  
> -- 
> 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 Fri Feb 15 12:30:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6KR5-0000Za-FD; Fri, 15 Feb 2013 12:30:39 +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 1U6KR3-0000ZM-G5
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:30:37 +0000
Received: from [193.109.254.147:40259] by server-10.bemta-14.messagelabs.com
	id 24/20-12679-C6A2E115; Fri, 15 Feb 2013 12:30:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360931430!8606318!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25409 invoked from network); 15 Feb 2013 12:30:31 -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;
	15 Feb 2013 12:30:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7297489"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:26:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:26:47 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KNK-0001ur-Ud;
	Fri, 15 Feb 2013 12:26:46 +0000
Date: Fri, 15 Feb 2013 12:26:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="stdvga"|"cirrus"
> 
> - Default option is cirrus.
> - Prints error and exit if unknown value is passed.
> - stdvga parameter is now deprecated.
> - Updated xl.cfg man.
> 
> Required patch: Improve videoram setting v5
> Is prerequisite for patch: Add qxl support v9
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/man/xl.cfg.pod.5    |    8 +++++++-
>  tools/libxl/xl_cmdimpl.c |   14 +++++++++++++-
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 9c5cdcd..9862842 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -979,7 +979,7 @@ The default amount of video ram for stdvga is 8MB which is sufficient
>  for e.g. 1600x1200 at 32bpp and videoram option is currently working
>  only when using the qemu-xen-traditional device-model.
>  
> -When using the emulated Cirrus graphics card (B<stdvga=0>)
> +When using the emulated Cirrus graphics card (B<vga="cirrus">)
>  the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
> @@ -991,6 +991,12 @@ emulated graphics device. The default is false which means to emulate
>  a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
>  later (e.g. Windows XP onwards) then you should enable this.
>  stdvga supports more video ram and bigger resolutions than Cirrus.
> +This option is deprecated, use vga="stdvga" instead.
> +
> +=item B<vga="STRING">
> +
> +Selects the emulated video card (stdvga|cirrus).
> +The default is cirrus.
>  
>  =item B<vnc=BOOLEAN>
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080bbd8..f9101ba 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1469,7 +1469,19 @@ skip_vfb:
>  #undef parse_extra_args
>  
>      if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> -        if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
> +        if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_STD;
> +            } else if (!strcmp(buf, "cirrus")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +            } else {
> +                fprintf(stderr,
> +                "Unknown vga \"%s\" specified\n", buf);
> +                exit(1);
> +            }
> +        } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>              b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
>                                           LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>  
> -- 
> 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 Fri Feb 15 12:42:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6Kby-0000wi-1n; Fri, 15 Feb 2013 12:41:54 +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 1U6Kbw-0000wd-69
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:41:52 +0000
Received: from [85.158.137.99:24406] by server-11.bemta-3.messagelabs.com id
	F5/3A-10249-F0D2E115; Fri, 15 Feb 2013 12:41:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360932107!21585018!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20215 invoked from network); 15 Feb 2013 12:41:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:41:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1513337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:41: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.297.1;
	Fri, 15 Feb 2013 12:41:46 +0000
Message-ID: <1360932105.31407.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 12:41:45 +0000
In-Reply-To: <1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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

Keir, are you OK with this change?

On Thu, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
> Abstract away from vesa.c the funcions to handle a linear framebuffer
> and print characters to it.
> Make use of the new functions in vesa.c.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Jan Beulich <JBeulich@suse.com>
> 
> Changes in v6:
> - remove useless initializations to NULL in lfb_init;
> - more compact checks in lfb_init.
> 
> Changes in v5:
> - remove lfb_alloc and the now unused __initdata variables;
> - fix indentation and long lines.
> 
> Changes in v4:
> - squash the vesa.c changes into this patch;
> - rename fb* to lfb*;
> - pass a pointer to fb_init;
> - use %u for screen dimensions;
> - specify loglevel in printk;
> - call fb_free on error in fb_alloc;
> - no __init on declarations;
> - do not break messages to fit 80 columns.
> ---
>  xen/drivers/video/Makefile |    1 +
>  xen/drivers/video/lfb.c    |  183 ++++++++++++++++++++++++++++++++++++++++++++
>  xen/drivers/video/lfb.h    |   46 +++++++++++
>  xen/drivers/video/vesa.c   |  177 ++++++------------------------------------
>  4 files changed, 254 insertions(+), 153 deletions(-)
>  create mode 100644 xen/drivers/video/lfb.c
>  create mode 100644 xen/drivers/video/lfb.h
> 
> diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
> index 2993c39..77f9d5d 100644
> --- a/xen/drivers/video/Makefile
> +++ b/xen/drivers/video/Makefile
> @@ -2,4 +2,5 @@ obj-$(HAS_VGA) := vga.o
>  obj-$(HAS_VIDEO) += font_8x14.o
>  obj-$(HAS_VIDEO) += font_8x16.o
>  obj-$(HAS_VIDEO) += font_8x8.o
> +obj-$(HAS_VIDEO) += lfb.o
>  obj-$(HAS_VGA) += vesa.o
> diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
> new file mode 100644
> index 0000000..cc7f7ac
> --- /dev/null
> +++ b/xen/drivers/video/lfb.c
> @@ -0,0 +1,183 @@
> +/******************************************************************************
> + * lfb.c
> + *
> + * linear frame buffer handling.
> + */
> +
> +#include <xen/config.h>
> +#include <xen/kernel.h>
> +#include <xen/lib.h>
> +#include <xen/errno.h>
> +#include "lfb.h"
> +#include "font.h"
> +
> +#define MAX_XRES 1900
> +#define MAX_YRES 1200
> +#define MAX_BPP 4
> +#define MAX_FONT_W 8
> +#define MAX_FONT_H 16
> +
> +struct lfb_status {
> +    struct lfb_prop lfbp;
> +
> +    unsigned char *lbuf, *text_buf;
> +    unsigned int *line_len;
> +    unsigned int xpos, ypos;
> +};
> +static struct lfb_status lfb;
> +
> +static void lfb_show_line(
> +    const unsigned char *text_line,
> +    unsigned char *video_line,
> +    unsigned int nr_chars,
> +    unsigned int nr_cells)
> +{
> +    unsigned int i, j, b, bpp, pixel;
> +
> +    bpp = (lfb.lfbp.bits_per_pixel + 7) >> 3;
> +
> +    for ( i = 0; i < lfb.lfbp.font->height; i++ )
> +    {
> +        unsigned char *ptr = lfb.lbuf;
> +
> +        for ( j = 0; j < nr_chars; j++ )
> +        {
> +            const unsigned char *bits = lfb.lfbp.font->data;
> +            bits += ((text_line[j] * lfb.lfbp.font->height + i) *
> +                     ((lfb.lfbp.font->width + 7) >> 3));
> +            for ( b = lfb.lfbp.font->width; b--; )
> +            {
> +                pixel = (*bits & (1u<<b)) ? lfb.lfbp.pixel_on : 0;
> +                memcpy(ptr, &pixel, bpp);
> +                ptr += bpp;
> +            }
> +        }
> +
> +        memset(ptr, 0, (lfb.lfbp.width - nr_chars * lfb.lfbp.font->width) * bpp);
> +        memcpy(video_line, lfb.lbuf, nr_cells * lfb.lfbp.font->width * bpp);
> +        video_line += lfb.lfbp.bytes_per_line;
> +    }
> +}
> +
> +/* Fast mode which redraws all modified parts of a 2D text buffer. */
> +void lfb_redraw_puts(const char *s)
> +{
> +    unsigned int i, min_redraw_y = lfb.ypos;
> +    char c;
> +
> +    /* Paste characters into text buffer. */
> +    while ( (c = *s++) != '\0' )
> +    {
> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
> +        {
> +            if ( ++lfb.ypos >= lfb.lfbp.text_rows )
> +            {
> +                min_redraw_y = 0;
> +                lfb.ypos = lfb.lfbp.text_rows - 1;
> +                memmove(lfb.text_buf, lfb.text_buf + lfb.lfbp.text_columns,
> +                        lfb.ypos * lfb.lfbp.text_columns);
> +                memset(lfb.text_buf + lfb.ypos * lfb.lfbp.text_columns, 0, lfb.xpos);
> +            }
> +            lfb.xpos = 0;
> +        }
> +
> +        if ( c != '\n' )
> +            lfb.text_buf[lfb.xpos++ + lfb.ypos * lfb.lfbp.text_columns] = c;
> +    }
> +
> +    /* Render modified section of text buffer to VESA linear framebuffer. */
> +    for ( i = min_redraw_y; i <= lfb.ypos; i++ )
> +    {
> +        const unsigned char *line = lfb.text_buf + i * lfb.lfbp.text_columns;
> +        unsigned int width;
> +
> +        for ( width = lfb.lfbp.text_columns; width; --width )
> +            if ( line[width - 1] )
> +                 break;
> +        lfb_show_line(line,
> +                       lfb.lfbp.lfb + i * lfb.lfbp.font->height * lfb.lfbp.bytes_per_line,
> +                       width, max(lfb.line_len[i], width));
> +        lfb.line_len[i] = width;
> +    }
> +
> +    lfb.lfbp.flush();
> +}
> +
> +/* Slower line-based scroll mode which interacts better with dom0. */
> +void lfb_scroll_puts(const char *s)
> +{
> +    unsigned int i;
> +    char c;
> +
> +    while ( (c = *s++) != '\0' )
> +    {
> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
> +        {
> +            unsigned int bytes = (lfb.lfbp.width *
> +                                  ((lfb.lfbp.bits_per_pixel + 7) >> 3));
> +            unsigned char *src = lfb.lfbp.lfb + lfb.lfbp.font->height * lfb.lfbp.bytes_per_line;
> +            unsigned char *dst = lfb.lfbp.lfb;
> +
> +            /* New line: scroll all previous rows up one line. */
> +            for ( i = lfb.lfbp.font->height; i < lfb.lfbp.height; i++ )
> +            {
> +                memcpy(dst, src, bytes);
> +                src += lfb.lfbp.bytes_per_line;
> +                dst += lfb.lfbp.bytes_per_line;
> +            }
> +
> +            /* Render new line. */
> +            lfb_show_line(
> +                lfb.text_buf,
> +                lfb.lfbp.lfb + (lfb.lfbp.text_rows-1) * lfb.lfbp.font->height *
> +                lfb.lfbp.bytes_per_line,
> +                lfb.xpos, lfb.lfbp.text_columns);
> +
> +            lfb.xpos = 0;
> +        }
> +
> +        if ( c != '\n' )
> +            lfb.text_buf[lfb.xpos++] = c;
> +    }
> +
> +    lfb.lfbp.flush();
> +}
> +
> +void lfb_carriage_return(void)
> +{
> +    lfb.xpos = 0;
> +}
> +
> +int __init lfb_init(struct lfb_prop *lfbp)
> +{
> +    if ( lfbp->width > MAX_XRES || lfbp->height > MAX_YRES )
> +    {
> +        printk(XENLOG_WARNING "Couldn't initialize a %ux%u framebuffer early.\n",
> +               lfbp->width, lfbp->height);
> +        return -EINVAL;
> +    }
> +
> +    lfb.lfbp = *lfbp;
> +
> +    lfb.lbuf = xmalloc_bytes(lfb.lfbp.bytes_per_line);
> +    lfb.text_buf = xzalloc_bytes(lfb.lfbp.text_columns * lfb.lfbp.text_rows);
> +    lfb.line_len = xzalloc_array(unsigned int, lfb.lfbp.text_columns);
> +
> +    if ( !lfb.lbuf || !lfb.text_buf || !lfb.line_len )
> +        goto fail;
> +
> +    return 0;
> +
> +fail:
> +    printk(XENLOG_ERR "Couldn't allocate enough memory to drive the framebuffer\n");
> +    lfb_free();
> +
> +    return -ENOMEM;
> +}
> +
> +void lfb_free(void)
> +{
> +    xfree(lfb.lbuf);
> +    xfree(lfb.text_buf);
> +    xfree(lfb.line_len);
> +}
> diff --git a/xen/drivers/video/lfb.h b/xen/drivers/video/lfb.h
> new file mode 100644
> index 0000000..ac40a66
> --- /dev/null
> +++ b/xen/drivers/video/lfb.h
> @@ -0,0 +1,46 @@
> +/*
> + * xen/drivers/video/lfb.h
> + *
> + * Cross-platform framebuffer library
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> + * Copyright (c) 2013 Citrix Systems.
> + *
> + * 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 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.
> + */
> +
> +#ifndef _XEN_LFB_H
> +#define _XEN_LFB_H
> +
> +#include <xen/init.h>
> +
> +struct lfb_prop {
> +    const struct font_desc *font;
> +    unsigned char *lfb;
> +    unsigned int pixel_on;
> +    uint16_t width, height;
> +    uint16_t bytes_per_line;
> +    uint16_t bits_per_pixel;
> +    void (*flush)(void);
> +
> +    unsigned int text_columns;
> +    unsigned int text_rows;
> +};
> +
> +void lfb_redraw_puts(const char *s);
> +void lfb_scroll_puts(const char *s);
> +void lfb_carriage_return(void);
> +void lfb_free(void);
> +
> +/* initialize the framebuffer */
> +int lfb_init(struct lfb_prop *lfbp);
> +
> +#endif
> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
> index aaf8b23..1144f76 100644
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -13,20 +13,15 @@
>  #include <asm/io.h>
>  #include <asm/page.h>
>  #include "font.h"
> +#include "lfb.h"
> 
>  #define vlfb_info    vga_console_info.u.vesa_lfb
> -#define text_columns (vlfb_info.width / font->width)
> -#define text_rows    (vlfb_info.height / font->height)
> 
> -static void vesa_redraw_puts(const char *s);
> -static void vesa_scroll_puts(const char *s);
> +static void lfb_flush(void);
> 
> -static unsigned char *lfb, *lbuf, *text_buf;
> -static unsigned int *__initdata line_len;
> +static unsigned char *lfb;
>  static const struct font_desc *font;
>  static bool_t vga_compat;
> -static unsigned int pixel_on;
> -static unsigned int xpos, ypos;
> 
>  static unsigned int vram_total;
>  integer_param("vesa-ram", vram_total);
> @@ -87,29 +82,26 @@ void __init vesa_early_init(void)
> 
>  void __init vesa_init(void)
>  {
> -    if ( !font )
> -        goto fail;
> -
> -    lbuf = xmalloc_bytes(vlfb_info.bytes_per_line);
> -    if ( !lbuf )
> -        goto fail;
> +    struct lfb_prop lfbp;
> 
> -    text_buf = xzalloc_bytes(text_columns * text_rows);
> -    if ( !text_buf )
> -        goto fail;
> +    if ( !font )
> +        return;
> 
> -    line_len = xzalloc_array(unsigned int, text_columns);
> -    if ( !line_len )
> -        goto fail;
> +    lfbp.font = font;
> +    lfbp.bits_per_pixel = vlfb_info.bits_per_pixel;
> +    lfbp.bytes_per_line = vlfb_info.bytes_per_line;
> +    lfbp.width = vlfb_info.width;
> +    lfbp.height = vlfb_info.height;
> +    lfbp.flush = lfb_flush;
> +    lfbp.text_columns = vlfb_info.width / font->width;
> +    lfbp.text_rows = vlfb_info.height / font->height;
> 
> -    lfb = ioremap(vlfb_info.lfb_base, vram_remap);
> +    lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap);
>      if ( !lfb )
> -        goto fail;
> +        return;
> 
>      memset(lfb, 0, vram_remap);
> 
> -    video_puts = vesa_redraw_puts;
> -
>      printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
>             "using %uk, total %uk\n",
>             vlfb_info.lfb_base, lfb,
> @@ -131,7 +123,7 @@ void __init vesa_init(void)
>      {
>          /* Light grey in truecolor. */
>          unsigned int grey = 0xaaaaaaaa;
> -        pixel_on =
> +        fbp.pixel_on =
>              ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
>              ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
>              ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_pos);
> @@ -139,15 +131,12 @@ void __init vesa_init(void)
>      else
>      {
>          /* White(ish) in default pseudocolor palette. */
> -        pixel_on = 7;
> +        fbp.pixel_on = 7;
>      }
> 
> -    return;
> -
> - fail:
> -    xfree(lbuf);
> -    xfree(text_buf);
> -    xfree(line_len);
> +    if ( lfb_init(&lfbp) < 0 )
> +        return;
> +    video_puts = lfb_redraw_puts;
>  }
> 
>  #include <asm/mtrr.h>
> @@ -192,8 +181,8 @@ void __init vesa_endboot(bool_t keep)
>  {
>      if ( keep )
>      {
> -        xpos = 0;
> -        video_puts = vesa_scroll_puts;
> +        video_puts = lfb_scroll_puts;
> +        lfb_carriage_return();
>      }
>      else
>      {
> @@ -202,124 +191,6 @@ void __init vesa_endboot(bool_t keep)
>              memset(lfb + i * vlfb_info.bytes_per_line, 0,
>                     vlfb_info.width * bpp);
>          lfb_flush();
> +        lfb_free();
>      }
> -
> -    xfree(line_len);
> -}
> -
> -/* Render one line of text to given linear framebuffer line. */
> -static void vesa_show_line(
> -    const unsigned char *text_line,
> -    unsigned char *video_line,
> -    unsigned int nr_chars,
> -    unsigned int nr_cells)
> -{
> -    unsigned int i, j, b, bpp, pixel;
> -
> -    bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
> -
> -    for ( i = 0; i < font->height; i++ )
> -    {
> -        unsigned char *ptr = lbuf;
> -
> -        for ( j = 0; j < nr_chars; j++ )
> -        {
> -            const unsigned char *bits = font->data;
> -            bits += ((text_line[j] * font->height + i) *
> -                     ((font->width + 7) >> 3));
> -            for ( b = font->width; b--; )
> -            {
> -                pixel = (*bits & (1u<<b)) ? pixel_on : 0;
> -                memcpy(ptr, &pixel, bpp);
> -                ptr += bpp;
> -            }
> -        }
> -
> -        memset(ptr, 0, (vlfb_info.width - nr_chars * font->width) * bpp);
> -        memcpy(video_line, lbuf, nr_cells * font->width * bpp);
> -        video_line += vlfb_info.bytes_per_line;
> -    }
> -}
> -
> -/* Fast mode which redraws all modified parts of a 2D text buffer. */
> -static void __init vesa_redraw_puts(const char *s)
> -{
> -    unsigned int i, min_redraw_y = ypos;
> -    char c;
> -
> -    /* Paste characters into text buffer. */
> -    while ( (c = *s++) != '\0' )
> -    {
> -        if ( (c == '\n') || (xpos >= text_columns) )
> -        {
> -            if ( ++ypos >= text_rows )
> -            {
> -                min_redraw_y = 0;
> -                ypos = text_rows - 1;
> -                memmove(text_buf, text_buf + text_columns,
> -                        ypos * text_columns);
> -                memset(text_buf + ypos * text_columns, 0, xpos);
> -            }
> -            xpos = 0;
> -        }
> -
> -        if ( c != '\n' )
> -            text_buf[xpos++ + ypos * text_columns] = c;
> -    }
> -
> -    /* Render modified section of text buffer to VESA linear framebuffer. */
> -    for ( i = min_redraw_y; i <= ypos; i++ )
> -    {
> -        const unsigned char *line = text_buf + i * text_columns;
> -        unsigned int width;
> -
> -        for ( width = text_columns; width; --width )
> -            if ( line[width - 1] )
> -                 break;
> -        vesa_show_line(line,
> -                       lfb + i * font->height * vlfb_info.bytes_per_line,
> -                       width, max(line_len[i], width));
> -        line_len[i] = width;
> -    }
> -
> -    lfb_flush();
> -}
> -
> -/* Slower line-based scroll mode which interacts better with dom0. */
> -static void vesa_scroll_puts(const char *s)
> -{
> -    unsigned int i;
> -    char c;
> -
> -    while ( (c = *s++) != '\0' )
> -    {
> -        if ( (c == '\n') || (xpos >= text_columns) )
> -        {
> -            unsigned int bytes = (vlfb_info.width *
> -                                  ((vlfb_info.bits_per_pixel + 7) >> 3));
> -            unsigned char *src = lfb + font->height * vlfb_info.bytes_per_line;
> -            unsigned char *dst = lfb;
> -
> -            /* New line: scroll all previous rows up one line. */
> -            for ( i = font->height; i < vlfb_info.height; i++ )
> -            {
> -                memcpy(dst, src, bytes);
> -                src += vlfb_info.bytes_per_line;
> -                dst += vlfb_info.bytes_per_line;
> -            }
> -
> -            /* Render new line. */
> -            vesa_show_line(
> -                text_buf,
> -                lfb + (text_rows-1) * font->height * vlfb_info.bytes_per_line,
> -                xpos, text_columns);
> -
> -            xpos = 0;
> -        }
> -
> -        if ( c != '\n' )
> -            text_buf[xpos++] = c;
> -    }
> -
> -    lfb_flush();
>  }
> --
> 1.7.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 Feb 15 12:42:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6Kby-0000wi-1n; Fri, 15 Feb 2013 12:41:54 +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 1U6Kbw-0000wd-69
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:41:52 +0000
Received: from [85.158.137.99:24406] by server-11.bemta-3.messagelabs.com id
	F5/3A-10249-F0D2E115; Fri, 15 Feb 2013 12:41:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360932107!21585018!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20215 invoked from network); 15 Feb 2013 12:41:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:41:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1513337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:41: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.297.1;
	Fri, 15 Feb 2013 12:41:46 +0000
Message-ID: <1360932105.31407.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 12:41:45 +0000
In-Reply-To: <1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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

Keir, are you OK with this change?

On Thu, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
> Abstract away from vesa.c the funcions to handle a linear framebuffer
> and print characters to it.
> Make use of the new functions in vesa.c.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Jan Beulich <JBeulich@suse.com>
> 
> Changes in v6:
> - remove useless initializations to NULL in lfb_init;
> - more compact checks in lfb_init.
> 
> Changes in v5:
> - remove lfb_alloc and the now unused __initdata variables;
> - fix indentation and long lines.
> 
> Changes in v4:
> - squash the vesa.c changes into this patch;
> - rename fb* to lfb*;
> - pass a pointer to fb_init;
> - use %u for screen dimensions;
> - specify loglevel in printk;
> - call fb_free on error in fb_alloc;
> - no __init on declarations;
> - do not break messages to fit 80 columns.
> ---
>  xen/drivers/video/Makefile |    1 +
>  xen/drivers/video/lfb.c    |  183 ++++++++++++++++++++++++++++++++++++++++++++
>  xen/drivers/video/lfb.h    |   46 +++++++++++
>  xen/drivers/video/vesa.c   |  177 ++++++------------------------------------
>  4 files changed, 254 insertions(+), 153 deletions(-)
>  create mode 100644 xen/drivers/video/lfb.c
>  create mode 100644 xen/drivers/video/lfb.h
> 
> diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
> index 2993c39..77f9d5d 100644
> --- a/xen/drivers/video/Makefile
> +++ b/xen/drivers/video/Makefile
> @@ -2,4 +2,5 @@ obj-$(HAS_VGA) := vga.o
>  obj-$(HAS_VIDEO) += font_8x14.o
>  obj-$(HAS_VIDEO) += font_8x16.o
>  obj-$(HAS_VIDEO) += font_8x8.o
> +obj-$(HAS_VIDEO) += lfb.o
>  obj-$(HAS_VGA) += vesa.o
> diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
> new file mode 100644
> index 0000000..cc7f7ac
> --- /dev/null
> +++ b/xen/drivers/video/lfb.c
> @@ -0,0 +1,183 @@
> +/******************************************************************************
> + * lfb.c
> + *
> + * linear frame buffer handling.
> + */
> +
> +#include <xen/config.h>
> +#include <xen/kernel.h>
> +#include <xen/lib.h>
> +#include <xen/errno.h>
> +#include "lfb.h"
> +#include "font.h"
> +
> +#define MAX_XRES 1900
> +#define MAX_YRES 1200
> +#define MAX_BPP 4
> +#define MAX_FONT_W 8
> +#define MAX_FONT_H 16
> +
> +struct lfb_status {
> +    struct lfb_prop lfbp;
> +
> +    unsigned char *lbuf, *text_buf;
> +    unsigned int *line_len;
> +    unsigned int xpos, ypos;
> +};
> +static struct lfb_status lfb;
> +
> +static void lfb_show_line(
> +    const unsigned char *text_line,
> +    unsigned char *video_line,
> +    unsigned int nr_chars,
> +    unsigned int nr_cells)
> +{
> +    unsigned int i, j, b, bpp, pixel;
> +
> +    bpp = (lfb.lfbp.bits_per_pixel + 7) >> 3;
> +
> +    for ( i = 0; i < lfb.lfbp.font->height; i++ )
> +    {
> +        unsigned char *ptr = lfb.lbuf;
> +
> +        for ( j = 0; j < nr_chars; j++ )
> +        {
> +            const unsigned char *bits = lfb.lfbp.font->data;
> +            bits += ((text_line[j] * lfb.lfbp.font->height + i) *
> +                     ((lfb.lfbp.font->width + 7) >> 3));
> +            for ( b = lfb.lfbp.font->width; b--; )
> +            {
> +                pixel = (*bits & (1u<<b)) ? lfb.lfbp.pixel_on : 0;
> +                memcpy(ptr, &pixel, bpp);
> +                ptr += bpp;
> +            }
> +        }
> +
> +        memset(ptr, 0, (lfb.lfbp.width - nr_chars * lfb.lfbp.font->width) * bpp);
> +        memcpy(video_line, lfb.lbuf, nr_cells * lfb.lfbp.font->width * bpp);
> +        video_line += lfb.lfbp.bytes_per_line;
> +    }
> +}
> +
> +/* Fast mode which redraws all modified parts of a 2D text buffer. */
> +void lfb_redraw_puts(const char *s)
> +{
> +    unsigned int i, min_redraw_y = lfb.ypos;
> +    char c;
> +
> +    /* Paste characters into text buffer. */
> +    while ( (c = *s++) != '\0' )
> +    {
> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
> +        {
> +            if ( ++lfb.ypos >= lfb.lfbp.text_rows )
> +            {
> +                min_redraw_y = 0;
> +                lfb.ypos = lfb.lfbp.text_rows - 1;
> +                memmove(lfb.text_buf, lfb.text_buf + lfb.lfbp.text_columns,
> +                        lfb.ypos * lfb.lfbp.text_columns);
> +                memset(lfb.text_buf + lfb.ypos * lfb.lfbp.text_columns, 0, lfb.xpos);
> +            }
> +            lfb.xpos = 0;
> +        }
> +
> +        if ( c != '\n' )
> +            lfb.text_buf[lfb.xpos++ + lfb.ypos * lfb.lfbp.text_columns] = c;
> +    }
> +
> +    /* Render modified section of text buffer to VESA linear framebuffer. */
> +    for ( i = min_redraw_y; i <= lfb.ypos; i++ )
> +    {
> +        const unsigned char *line = lfb.text_buf + i * lfb.lfbp.text_columns;
> +        unsigned int width;
> +
> +        for ( width = lfb.lfbp.text_columns; width; --width )
> +            if ( line[width - 1] )
> +                 break;
> +        lfb_show_line(line,
> +                       lfb.lfbp.lfb + i * lfb.lfbp.font->height * lfb.lfbp.bytes_per_line,
> +                       width, max(lfb.line_len[i], width));
> +        lfb.line_len[i] = width;
> +    }
> +
> +    lfb.lfbp.flush();
> +}
> +
> +/* Slower line-based scroll mode which interacts better with dom0. */
> +void lfb_scroll_puts(const char *s)
> +{
> +    unsigned int i;
> +    char c;
> +
> +    while ( (c = *s++) != '\0' )
> +    {
> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
> +        {
> +            unsigned int bytes = (lfb.lfbp.width *
> +                                  ((lfb.lfbp.bits_per_pixel + 7) >> 3));
> +            unsigned char *src = lfb.lfbp.lfb + lfb.lfbp.font->height * lfb.lfbp.bytes_per_line;
> +            unsigned char *dst = lfb.lfbp.lfb;
> +
> +            /* New line: scroll all previous rows up one line. */
> +            for ( i = lfb.lfbp.font->height; i < lfb.lfbp.height; i++ )
> +            {
> +                memcpy(dst, src, bytes);
> +                src += lfb.lfbp.bytes_per_line;
> +                dst += lfb.lfbp.bytes_per_line;
> +            }
> +
> +            /* Render new line. */
> +            lfb_show_line(
> +                lfb.text_buf,
> +                lfb.lfbp.lfb + (lfb.lfbp.text_rows-1) * lfb.lfbp.font->height *
> +                lfb.lfbp.bytes_per_line,
> +                lfb.xpos, lfb.lfbp.text_columns);
> +
> +            lfb.xpos = 0;
> +        }
> +
> +        if ( c != '\n' )
> +            lfb.text_buf[lfb.xpos++] = c;
> +    }
> +
> +    lfb.lfbp.flush();
> +}
> +
> +void lfb_carriage_return(void)
> +{
> +    lfb.xpos = 0;
> +}
> +
> +int __init lfb_init(struct lfb_prop *lfbp)
> +{
> +    if ( lfbp->width > MAX_XRES || lfbp->height > MAX_YRES )
> +    {
> +        printk(XENLOG_WARNING "Couldn't initialize a %ux%u framebuffer early.\n",
> +               lfbp->width, lfbp->height);
> +        return -EINVAL;
> +    }
> +
> +    lfb.lfbp = *lfbp;
> +
> +    lfb.lbuf = xmalloc_bytes(lfb.lfbp.bytes_per_line);
> +    lfb.text_buf = xzalloc_bytes(lfb.lfbp.text_columns * lfb.lfbp.text_rows);
> +    lfb.line_len = xzalloc_array(unsigned int, lfb.lfbp.text_columns);
> +
> +    if ( !lfb.lbuf || !lfb.text_buf || !lfb.line_len )
> +        goto fail;
> +
> +    return 0;
> +
> +fail:
> +    printk(XENLOG_ERR "Couldn't allocate enough memory to drive the framebuffer\n");
> +    lfb_free();
> +
> +    return -ENOMEM;
> +}
> +
> +void lfb_free(void)
> +{
> +    xfree(lfb.lbuf);
> +    xfree(lfb.text_buf);
> +    xfree(lfb.line_len);
> +}
> diff --git a/xen/drivers/video/lfb.h b/xen/drivers/video/lfb.h
> new file mode 100644
> index 0000000..ac40a66
> --- /dev/null
> +++ b/xen/drivers/video/lfb.h
> @@ -0,0 +1,46 @@
> +/*
> + * xen/drivers/video/lfb.h
> + *
> + * Cross-platform framebuffer library
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> + * Copyright (c) 2013 Citrix Systems.
> + *
> + * 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 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.
> + */
> +
> +#ifndef _XEN_LFB_H
> +#define _XEN_LFB_H
> +
> +#include <xen/init.h>
> +
> +struct lfb_prop {
> +    const struct font_desc *font;
> +    unsigned char *lfb;
> +    unsigned int pixel_on;
> +    uint16_t width, height;
> +    uint16_t bytes_per_line;
> +    uint16_t bits_per_pixel;
> +    void (*flush)(void);
> +
> +    unsigned int text_columns;
> +    unsigned int text_rows;
> +};
> +
> +void lfb_redraw_puts(const char *s);
> +void lfb_scroll_puts(const char *s);
> +void lfb_carriage_return(void);
> +void lfb_free(void);
> +
> +/* initialize the framebuffer */
> +int lfb_init(struct lfb_prop *lfbp);
> +
> +#endif
> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
> index aaf8b23..1144f76 100644
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -13,20 +13,15 @@
>  #include <asm/io.h>
>  #include <asm/page.h>
>  #include "font.h"
> +#include "lfb.h"
> 
>  #define vlfb_info    vga_console_info.u.vesa_lfb
> -#define text_columns (vlfb_info.width / font->width)
> -#define text_rows    (vlfb_info.height / font->height)
> 
> -static void vesa_redraw_puts(const char *s);
> -static void vesa_scroll_puts(const char *s);
> +static void lfb_flush(void);
> 
> -static unsigned char *lfb, *lbuf, *text_buf;
> -static unsigned int *__initdata line_len;
> +static unsigned char *lfb;
>  static const struct font_desc *font;
>  static bool_t vga_compat;
> -static unsigned int pixel_on;
> -static unsigned int xpos, ypos;
> 
>  static unsigned int vram_total;
>  integer_param("vesa-ram", vram_total);
> @@ -87,29 +82,26 @@ void __init vesa_early_init(void)
> 
>  void __init vesa_init(void)
>  {
> -    if ( !font )
> -        goto fail;
> -
> -    lbuf = xmalloc_bytes(vlfb_info.bytes_per_line);
> -    if ( !lbuf )
> -        goto fail;
> +    struct lfb_prop lfbp;
> 
> -    text_buf = xzalloc_bytes(text_columns * text_rows);
> -    if ( !text_buf )
> -        goto fail;
> +    if ( !font )
> +        return;
> 
> -    line_len = xzalloc_array(unsigned int, text_columns);
> -    if ( !line_len )
> -        goto fail;
> +    lfbp.font = font;
> +    lfbp.bits_per_pixel = vlfb_info.bits_per_pixel;
> +    lfbp.bytes_per_line = vlfb_info.bytes_per_line;
> +    lfbp.width = vlfb_info.width;
> +    lfbp.height = vlfb_info.height;
> +    lfbp.flush = lfb_flush;
> +    lfbp.text_columns = vlfb_info.width / font->width;
> +    lfbp.text_rows = vlfb_info.height / font->height;
> 
> -    lfb = ioremap(vlfb_info.lfb_base, vram_remap);
> +    lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap);
>      if ( !lfb )
> -        goto fail;
> +        return;
> 
>      memset(lfb, 0, vram_remap);
> 
> -    video_puts = vesa_redraw_puts;
> -
>      printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
>             "using %uk, total %uk\n",
>             vlfb_info.lfb_base, lfb,
> @@ -131,7 +123,7 @@ void __init vesa_init(void)
>      {
>          /* Light grey in truecolor. */
>          unsigned int grey = 0xaaaaaaaa;
> -        pixel_on =
> +        fbp.pixel_on =
>              ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
>              ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
>              ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_pos);
> @@ -139,15 +131,12 @@ void __init vesa_init(void)
>      else
>      {
>          /* White(ish) in default pseudocolor palette. */
> -        pixel_on = 7;
> +        fbp.pixel_on = 7;
>      }
> 
> -    return;
> -
> - fail:
> -    xfree(lbuf);
> -    xfree(text_buf);
> -    xfree(line_len);
> +    if ( lfb_init(&lfbp) < 0 )
> +        return;
> +    video_puts = lfb_redraw_puts;
>  }
> 
>  #include <asm/mtrr.h>
> @@ -192,8 +181,8 @@ void __init vesa_endboot(bool_t keep)
>  {
>      if ( keep )
>      {
> -        xpos = 0;
> -        video_puts = vesa_scroll_puts;
> +        video_puts = lfb_scroll_puts;
> +        lfb_carriage_return();
>      }
>      else
>      {
> @@ -202,124 +191,6 @@ void __init vesa_endboot(bool_t keep)
>              memset(lfb + i * vlfb_info.bytes_per_line, 0,
>                     vlfb_info.width * bpp);
>          lfb_flush();
> +        lfb_free();
>      }
> -
> -    xfree(line_len);
> -}
> -
> -/* Render one line of text to given linear framebuffer line. */
> -static void vesa_show_line(
> -    const unsigned char *text_line,
> -    unsigned char *video_line,
> -    unsigned int nr_chars,
> -    unsigned int nr_cells)
> -{
> -    unsigned int i, j, b, bpp, pixel;
> -
> -    bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
> -
> -    for ( i = 0; i < font->height; i++ )
> -    {
> -        unsigned char *ptr = lbuf;
> -
> -        for ( j = 0; j < nr_chars; j++ )
> -        {
> -            const unsigned char *bits = font->data;
> -            bits += ((text_line[j] * font->height + i) *
> -                     ((font->width + 7) >> 3));
> -            for ( b = font->width; b--; )
> -            {
> -                pixel = (*bits & (1u<<b)) ? pixel_on : 0;
> -                memcpy(ptr, &pixel, bpp);
> -                ptr += bpp;
> -            }
> -        }
> -
> -        memset(ptr, 0, (vlfb_info.width - nr_chars * font->width) * bpp);
> -        memcpy(video_line, lbuf, nr_cells * font->width * bpp);
> -        video_line += vlfb_info.bytes_per_line;
> -    }
> -}
> -
> -/* Fast mode which redraws all modified parts of a 2D text buffer. */
> -static void __init vesa_redraw_puts(const char *s)
> -{
> -    unsigned int i, min_redraw_y = ypos;
> -    char c;
> -
> -    /* Paste characters into text buffer. */
> -    while ( (c = *s++) != '\0' )
> -    {
> -        if ( (c == '\n') || (xpos >= text_columns) )
> -        {
> -            if ( ++ypos >= text_rows )
> -            {
> -                min_redraw_y = 0;
> -                ypos = text_rows - 1;
> -                memmove(text_buf, text_buf + text_columns,
> -                        ypos * text_columns);
> -                memset(text_buf + ypos * text_columns, 0, xpos);
> -            }
> -            xpos = 0;
> -        }
> -
> -        if ( c != '\n' )
> -            text_buf[xpos++ + ypos * text_columns] = c;
> -    }
> -
> -    /* Render modified section of text buffer to VESA linear framebuffer. */
> -    for ( i = min_redraw_y; i <= ypos; i++ )
> -    {
> -        const unsigned char *line = text_buf + i * text_columns;
> -        unsigned int width;
> -
> -        for ( width = text_columns; width; --width )
> -            if ( line[width - 1] )
> -                 break;
> -        vesa_show_line(line,
> -                       lfb + i * font->height * vlfb_info.bytes_per_line,
> -                       width, max(line_len[i], width));
> -        line_len[i] = width;
> -    }
> -
> -    lfb_flush();
> -}
> -
> -/* Slower line-based scroll mode which interacts better with dom0. */
> -static void vesa_scroll_puts(const char *s)
> -{
> -    unsigned int i;
> -    char c;
> -
> -    while ( (c = *s++) != '\0' )
> -    {
> -        if ( (c == '\n') || (xpos >= text_columns) )
> -        {
> -            unsigned int bytes = (vlfb_info.width *
> -                                  ((vlfb_info.bits_per_pixel + 7) >> 3));
> -            unsigned char *src = lfb + font->height * vlfb_info.bytes_per_line;
> -            unsigned char *dst = lfb;
> -
> -            /* New line: scroll all previous rows up one line. */
> -            for ( i = font->height; i < vlfb_info.height; i++ )
> -            {
> -                memcpy(dst, src, bytes);
> -                src += vlfb_info.bytes_per_line;
> -                dst += vlfb_info.bytes_per_line;
> -            }
> -
> -            /* Render new line. */
> -            vesa_show_line(
> -                text_buf,
> -                lfb + (text_rows-1) * font->height * vlfb_info.bytes_per_line,
> -                xpos, text_columns);
> -
> -            xpos = 0;
> -        }
> -
> -        if ( c != '\n' )
> -            text_buf[xpos++] = c;
> -    }
> -
> -    lfb_flush();
>  }
> --
> 1.7.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 Feb 15 12:44:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:44: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 1U6Kdy-00015N-RY; Fri, 15 Feb 2013 12:43:58 +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 1U6Kdx-00015F-0C
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:43:57 +0000
Received: from [85.158.139.211:9362] by server-1.bemta-5.messagelabs.com id
	2C/93-29263-C8D2E115; Fri, 15 Feb 2013 12:43:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360932221!21600115!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18713 invoked from network); 15 Feb 2013 12:43:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7299098"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:43:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:43:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6Kdg-0002B7-8X;
	Fri, 15 Feb 2013 12:43:40 +0000
Date: Fri, 15 Feb 2013 12:43:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> If a node does not have #*-cells then the parent's value should be
> used. Currently we were asssuming zero which is useless.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c   |    6 ++++--
>  xen/common/device_tree.c      |   12 ++++++++----
>  xen/include/xen/device_tree.h |    3 ++-
>  3 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..bfbe7c7 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -198,8 +198,10 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>          while ( last_depth-- >= depth )
>              fdt_end_node(kinfo->fdt);
>  
> -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> +                                    depth > 0 ? address_cells[depth-1] : 0);
> +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> +                                    depth > 0 ? size_cells[depth-1] : 0);
>  
>          fdt_begin_node(kinfo->fdt, name);

The depth is always increasing by steps of 1 in this loop, right?
Because retrieving address-cells and size-cells should be recursive: if
n-1 doesn't have them, let's look at n-2, etc. Of course if we start from
depth = 0 and go from there without missing any levels the results will
be the same.

I think I convinced myself that this is correct.


> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 260c2d4..f10ba1b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
>      set_val(cell, size_cells, size);
>  }
>  
> -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> +                        u32 dflt)
>  {
>      const struct fdt_property *prop;
>  
>      prop = fdt_get_property(fdt, node, prop_name, NULL);
>      if ( !prop || prop->len < sizeof(u32) )
> -        return 0; /* default to 0 */
> +        return dflt;
>  
>      return fdt32_to_cpu(*(uint32_t*)prop->data);
>  }

where did the vowels go? :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:44:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:44: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 1U6Kdy-00015N-RY; Fri, 15 Feb 2013 12:43:58 +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 1U6Kdx-00015F-0C
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:43:57 +0000
Received: from [85.158.139.211:9362] by server-1.bemta-5.messagelabs.com id
	2C/93-29263-C8D2E115; Fri, 15 Feb 2013 12:43:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1360932221!21600115!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18713 invoked from network); 15 Feb 2013 12:43:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7299098"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:43:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:43:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6Kdg-0002B7-8X;
	Fri, 15 Feb 2013 12:43:40 +0000
Date: Fri, 15 Feb 2013 12:43:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> If a node does not have #*-cells then the parent's value should be
> used. Currently we were asssuming zero which is useless.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c   |    6 ++++--
>  xen/common/device_tree.c      |   12 ++++++++----
>  xen/include/xen/device_tree.h |    3 ++-
>  3 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..bfbe7c7 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -198,8 +198,10 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>          while ( last_depth-- >= depth )
>              fdt_end_node(kinfo->fdt);
>  
> -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> +                                    depth > 0 ? address_cells[depth-1] : 0);
> +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> +                                    depth > 0 ? size_cells[depth-1] : 0);
>  
>          fdt_begin_node(kinfo->fdt, name);

The depth is always increasing by steps of 1 in this loop, right?
Because retrieving address-cells and size-cells should be recursive: if
n-1 doesn't have them, let's look at n-2, etc. Of course if we start from
depth = 0 and go from there without missing any levels the results will
be the same.

I think I convinced myself that this is correct.


> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 260c2d4..f10ba1b 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
>      set_val(cell, size_cells, size);
>  }
>  
> -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> +                        u32 dflt)
>  {
>      const struct fdt_property *prop;
>  
>      prop = fdt_get_property(fdt, node, prop_name, NULL);
>      if ( !prop || prop->len < sizeof(u32) )
> -        return 0; /* default to 0 */
> +        return dflt;
>  
>      return fdt32_to_cpu(*(uint32_t*)prop->data);
>  }

where did the vowels go? :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:53:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:53: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 1U6KmP-0001Ml-Ve; Fri, 15 Feb 2013 12:52: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 1U6KmP-0001Mg-0J
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:52:41 +0000
Received: from [85.158.139.83:11191] by server-7.bemta-5.messagelabs.com id
	47/48-11121-89F2E115; Fri, 15 Feb 2013 12:52:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360932758!26906481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31555 invoked from network); 15 Feb 2013 12:52:39 -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;
	15 Feb 2013 12:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7671729"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:52:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:52:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KmK-0002JF-Sn;
	Fri, 15 Feb 2013 12:52:36 +0000
Date: Fri, 15 Feb 2013 12:52:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151252260.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 4/4] xen: arm: create dom0 DTB /hypervisor/
 node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> I initially added hypervisor-new and confirmed via /proc/device-model
> that the content is the same before changing it to drop and replace
> an existing node.
> 
> NB: There is an ambiguity in the compatibility property.
> linux/arch/arm/boot/dts/xenvm-4.2.dts says "xen,xen-4.2" while
> Documentation/devicetree/bindings/arm/xen.txt says "xen,xen-4.3". I
> don't know which is correct but I've erred on the side of the DTS.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain_build.c |   53 +++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bb10096..d3ef180 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -34,7 +34,7 @@ custom_param("dom0_mem", parse_dom0_mem);
>   * are added (yet) but one terminating reserve map entry (16 bytes) is
>   * added.
>   */
> -#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
> +#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>  
>  struct vcpu *__init alloc_dom0_vcpu0(void)
>  {
> @@ -186,6 +186,13 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
>              break;
>  
> +        /* Skip /hypervisor/ node. We will inject our own. */
> +        if ( fdt_node_check_compatible(fdt, node, "xen,xen" ) == 0 )
> +        {
> +            printk("Device-tree contains \"xen,xen\" node. Ignoring.\n");
> +            continue;
> +        }
> +
>          /* Skip multiboot subnodes */
>          if ( fdt_node_check_compatible(fdt, node,
>                                         "xen,multiboot-module" ) == 0 )
> @@ -199,6 +206,45 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>      return node;
>  }
>  
> +static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
> +{
> +    const char compat[] = "xen,xen-4.2\0xen,xen";
> +    u32 reg[4];
> +    u32 intr[3];
> +    u32 *cell;
> +
> +    /*
> +     * Sanity-check address sizes, since addresses and sizes which do not take
> +     * up exactly 4 or 8 bytes are not supported.
> +     */
> +    if ((addrcells != 1 && addrcells != 2) ||
> +        (sizecells != 1 && sizecells != 2))
> +        panic("Cannot cope with this size");
> +
> +    /* See linux Documentation/devicetree/bindings/arm/xen.txt */
> +    fdt_begin_node(fdt, "hypervisor");
> +
> +    fdt_property(fdt, "compatible", compat, sizeof(compat) + 1);
> +
> +    /* reg 0 is grant table space */
> +    cell = &reg[0];
> +    device_tree_set_reg(&cell, addrcells, sizecells, 0xb0000000, 0x20000);
> +    fdt_property(fdt, "reg", reg,
> +                 sizeof(reg[0]) * (addrcells + sizecells));
> +
> +    /*
> +     * interrupts is evtchn upcall  <1 15 0xf08>
> +     * See linux Documentation/devicetree/bindings/arm/gic.txt
> +     */
> +    intr[0] = cpu_to_fdt32(1); /* is a PPI */
> +    intr[1] = cpu_to_fdt32(VGIC_IRQ_EVTCHN_CALLBACK - 16); /* PPIs start at 16 */
> +    intr[2] = cpu_to_fdt32(0xf08); /* Active-low level-sensitive */
> +
> +    fdt_property(fdt, "interrupts", intr, sizeof(intr[0]) * 3);
> +
> +    fdt_end_node(fdt);
> +}
> +
>  static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>                         const void *fdt)
>  {
> @@ -241,9 +287,12 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>          last_depth = depth;
>      }
>  
> -    while ( last_depth-- >= 0 )
> +    while ( last_depth-- >= 1 )
>          fdt_end_node(kinfo->fdt);
>  
> +    make_hypervisor_node(kinfo->fdt, address_cells[0], size_cells[0]);
> +
> +    fdt_end_node(kinfo->fdt);
>      return 0;
>  }
>  
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:53:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:53: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 1U6KmP-0001Ml-Ve; Fri, 15 Feb 2013 12:52: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 1U6KmP-0001Mg-0J
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:52:41 +0000
Received: from [85.158.139.83:11191] by server-7.bemta-5.messagelabs.com id
	47/48-11121-89F2E115; Fri, 15 Feb 2013 12:52:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360932758!26906481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31555 invoked from network); 15 Feb 2013 12:52:39 -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;
	15 Feb 2013 12:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7671729"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:52:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:52:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KmK-0002JF-Sn;
	Fri, 15 Feb 2013 12:52:36 +0000
Date: Fri, 15 Feb 2013 12:52:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151252260.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 4/4] xen: arm: create dom0 DTB /hypervisor/
 node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> I initially added hypervisor-new and confirmed via /proc/device-model
> that the content is the same before changing it to drop and replace
> an existing node.
> 
> NB: There is an ambiguity in the compatibility property.
> linux/arch/arm/boot/dts/xenvm-4.2.dts says "xen,xen-4.2" while
> Documentation/devicetree/bindings/arm/xen.txt says "xen,xen-4.3". I
> don't know which is correct but I've erred on the side of the DTS.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  xen/arch/arm/domain_build.c |   53 +++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bb10096..d3ef180 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -34,7 +34,7 @@ custom_param("dom0_mem", parse_dom0_mem);
>   * are added (yet) but one terminating reserve map entry (16 bytes) is
>   * added.
>   */
> -#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
> +#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>  
>  struct vcpu *__init alloc_dom0_vcpu0(void)
>  {
> @@ -186,6 +186,13 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
>              break;
>  
> +        /* Skip /hypervisor/ node. We will inject our own. */
> +        if ( fdt_node_check_compatible(fdt, node, "xen,xen" ) == 0 )
> +        {
> +            printk("Device-tree contains \"xen,xen\" node. Ignoring.\n");
> +            continue;
> +        }
> +
>          /* Skip multiboot subnodes */
>          if ( fdt_node_check_compatible(fdt, node,
>                                         "xen,multiboot-module" ) == 0 )
> @@ -199,6 +206,45 @@ static int fdt_next_dom0_node(const void *fdt, int node,
>      return node;
>  }
>  
> +static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
> +{
> +    const char compat[] = "xen,xen-4.2\0xen,xen";
> +    u32 reg[4];
> +    u32 intr[3];
> +    u32 *cell;
> +
> +    /*
> +     * Sanity-check address sizes, since addresses and sizes which do not take
> +     * up exactly 4 or 8 bytes are not supported.
> +     */
> +    if ((addrcells != 1 && addrcells != 2) ||
> +        (sizecells != 1 && sizecells != 2))
> +        panic("Cannot cope with this size");
> +
> +    /* See linux Documentation/devicetree/bindings/arm/xen.txt */
> +    fdt_begin_node(fdt, "hypervisor");
> +
> +    fdt_property(fdt, "compatible", compat, sizeof(compat) + 1);
> +
> +    /* reg 0 is grant table space */
> +    cell = &reg[0];
> +    device_tree_set_reg(&cell, addrcells, sizecells, 0xb0000000, 0x20000);
> +    fdt_property(fdt, "reg", reg,
> +                 sizeof(reg[0]) * (addrcells + sizecells));
> +
> +    /*
> +     * interrupts is evtchn upcall  <1 15 0xf08>
> +     * See linux Documentation/devicetree/bindings/arm/gic.txt
> +     */
> +    intr[0] = cpu_to_fdt32(1); /* is a PPI */
> +    intr[1] = cpu_to_fdt32(VGIC_IRQ_EVTCHN_CALLBACK - 16); /* PPIs start at 16 */
> +    intr[2] = cpu_to_fdt32(0xf08); /* Active-low level-sensitive */
> +
> +    fdt_property(fdt, "interrupts", intr, sizeof(intr[0]) * 3);
> +
> +    fdt_end_node(fdt);
> +}
> +
>  static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>                         const void *fdt)
>  {
> @@ -241,9 +287,12 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>          last_depth = depth;
>      }
>  
> -    while ( last_depth-- >= 0 )
> +    while ( last_depth-- >= 1 )
>          fdt_end_node(kinfo->fdt);
>  
> +    make_hypervisor_node(kinfo->fdt, address_cells[0], size_cells[0]);
> +
> +    fdt_end_node(kinfo->fdt);
>      return 0;
>  }
>  
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:54:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:54: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 1U6Kng-0001Qj-Fh; Fri, 15 Feb 2013 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1U6Knf-0001Qb-Aj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:53:59 +0000
Received: from [85.158.138.51:42779] by server-6.bemta-3.messagelabs.com id
	DD/34-29959-6EF2E115; Fri, 15 Feb 2013 12:53:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360932835!9035595!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 15 Feb 2013 12:53:57 -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;
	15 Feb 2013 12:53:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7671871"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:53:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:53:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6Kna-0002Kl-Sb;
	Fri, 15 Feb 2013 12:53:54 +0000
Date: Fri, 15 Feb 2013 12:53:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-3-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151253420.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 3/4] xen: strip xen,
 multiboot-module nodes from dom0 device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> These nodes are used by Xen to find the initial modules.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> v6 - filter based on compatibility node name and not path.
> v4 - /chosen/modules/modules@N not /chosen/module@N
> v3 - use a helper to filter out DT elements which are not for dom0.
>      Better than an ad-hoc break in the middle of a loop.
> ---
>  xen/arch/arm/domain_build.c |   32 ++++++++++++++++++++++++++++++--
>  1 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bfbe7c7..bb10096 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -172,6 +172,33 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>      return prop;
>  }
>  
> +/* Returns the next node in fdt (starting from offset) which should be
> + * passed through to dom0.
> + */
> +static int fdt_next_dom0_node(const void *fdt, int node,
> +                              int *depth_out)
> +{
> +    int depth = *depth_out;
> +
> +    while ( (node = fdt_next_node(fdt, node, &depth)) &&
> +            node >= 0 && depth >= 0 )
> +    {
> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +            break;
> +
> +        /* Skip multiboot subnodes */
> +        if ( fdt_node_check_compatible(fdt, node,
> +                                       "xen,multiboot-module" ) == 0 )
> +            continue;
> +
> +        /* We've arrived at a node which dom0 is interested in. */
> +        break;
> +    }
> +
> +    *depth_out = depth;
> +    return node;
> +}
> +
>  static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>                         const void *fdt)
>  {
> @@ -183,7 +210,7 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>  
>      for ( node = 0, depth = 0;
>            node >= 0 && depth >= 0;
> -          node = fdt_next_node(fdt, node, &depth) )
> +          node = fdt_next_dom0_node(fdt, node, &depth) )
>      {
>          const char *name;
>  
> @@ -191,7 +218,8 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>  
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
>          {
> -            printk("warning: node `%s' is nested too deep\n", name);
> +            printk("warning: node `%s' is nested too deep (%d)\n",
> +                   name, depth);
>              continue;
>          }
>  
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:54:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:54: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 1U6Kng-0001Qj-Fh; Fri, 15 Feb 2013 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1U6Knf-0001Qb-Aj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:53:59 +0000
Received: from [85.158.138.51:42779] by server-6.bemta-3.messagelabs.com id
	DD/34-29959-6EF2E115; Fri, 15 Feb 2013 12:53:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360932835!9035595!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6056 invoked from network); 15 Feb 2013 12:53:57 -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;
	15 Feb 2013 12:53:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7671871"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:53:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:53:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6Kna-0002Kl-Sb;
	Fri, 15 Feb 2013 12:53:54 +0000
Date: Fri, 15 Feb 2013 12:53:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-3-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151253420.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 3/4] xen: strip xen,
 multiboot-module nodes from dom0 device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> These nodes are used by Xen to find the initial modules.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> v6 - filter based on compatibility node name and not path.
> v4 - /chosen/modules/modules@N not /chosen/module@N
> v3 - use a helper to filter out DT elements which are not for dom0.
>      Better than an ad-hoc break in the middle of a loop.
> ---
>  xen/arch/arm/domain_build.c |   32 ++++++++++++++++++++++++++++++--
>  1 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bfbe7c7..bb10096 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -172,6 +172,33 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>      return prop;
>  }
>  
> +/* Returns the next node in fdt (starting from offset) which should be
> + * passed through to dom0.
> + */
> +static int fdt_next_dom0_node(const void *fdt, int node,
> +                              int *depth_out)
> +{
> +    int depth = *depth_out;
> +
> +    while ( (node = fdt_next_node(fdt, node, &depth)) &&
> +            node >= 0 && depth >= 0 )
> +    {
> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +            break;
> +
> +        /* Skip multiboot subnodes */
> +        if ( fdt_node_check_compatible(fdt, node,
> +                                       "xen,multiboot-module" ) == 0 )
> +            continue;
> +
> +        /* We've arrived at a node which dom0 is interested in. */
> +        break;
> +    }
> +
> +    *depth_out = depth;
> +    return node;
> +}
> +
>  static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>                         const void *fdt)
>  {
> @@ -183,7 +210,7 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>  
>      for ( node = 0, depth = 0;
>            node >= 0 && depth >= 0;
> -          node = fdt_next_node(fdt, node, &depth) )
> +          node = fdt_next_dom0_node(fdt, node, &depth) )
>      {
>          const char *name;
>  
> @@ -191,7 +218,8 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>  
>          if ( depth >= DEVICE_TREE_MAX_DEPTH )
>          {
> -            printk("warning: node `%s' is nested too deep\n", name);
> +            printk("warning: node `%s' is nested too deep (%d)\n",
> +                   name, depth);
>              continue;
>          }
>  
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:56:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:56: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 1U6KpW-0001Yw-2n; Fri, 15 Feb 2013 12:55: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 1U6KpT-0001Yf-Ra
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:55:52 +0000
Received: from [85.158.143.99:29930] by server-1.bemta-4.messagelabs.com id
	60/BB-08839-7503E115; Fri, 15 Feb 2013 12:55:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360932947!24316455!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25548 invoked from network); 15 Feb 2013 12:55:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7300144"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:55:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:55:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KpO-0002Ld-LO;
	Fri, 15 Feb 2013 12:55:46 +0000
Date: Fri, 15 Feb 2013 12:55:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151247180.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 2/4] xen: arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> The bootloader should populate /chosen/modules/module@<N>/ for each
> module it wishes to pass to the hypervisor. The content of these nodes
> is described in docs/misc/arm/device-tree/booting.txt
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v6: Match based on compatibility instead of path
> v5: Moved later in the series
> v4: Use /chosen/modules/module@N
>     Identify module type by compatible property not number.
> v3: Use a reg = < > property for the module address/length.
> v2: Reserve the zeroeth module for Xen itself (not used yet)
>     Use a more idiomatic DT layout
>     Document said layout

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/misc/arm/device-tree/booting.txt |   25 +++++++++++++++
>  xen/common/device_tree.c              |   54 ++++++++++++++++++++++++++++++++-
>  2 files changed, 78 insertions(+), 1 deletions(-)
>  create mode 100644 docs/misc/arm/device-tree/booting.txt
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> new file mode 100644
> index 0000000..94cd3f1
> --- /dev/null
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -0,0 +1,25 @@
> +Xen is passed the dom0 kernel and initrd via a reference in the /chosen
> +node of the device tree.
> +
> +Each node has the form /chosen/modules/module@<N> and contains the following
> +properties:
> +
> +- compatible
> +
> +	Must be:
> +
> +		"xen,<type>", "xen,multiboot-module"
> +
> +	where <type> must be one of:
> +
> +	- "linux-zimage" -- the dom0 kernel
> +	- "linux-initrd" -- the dom0 ramdisk
> +
> +- reg
> +
> +	Specifies the physical address of the module in RAM and the
> +	length of the module.
> +
> +- bootargs (optional)
> +
> +	Command line associated with this module
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f10ba1b..c92f8ca 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -341,6 +341,48 @@ static void __init process_gic_node(const void *fdt, int node,
>      early_info.gic.gic_vcpu_addr = start;
>  }
>  
> +static void __init process_multiboot_node(const void *fdt, int node,
> +                                          const char *name,
> +                                          u32 address_cells, u32 size_cells)
> +{
> +    const struct fdt_property *prop;
> +    const u32 *cell;
> +    int nr;
> +    struct dt_mb_module *mod;
> +    int len;
> +
> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
> +        nr = 1;
> +    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0)
> +        nr = 2;
> +    else
> +        early_panic("%s not a known xen multiboot type\n", name);
> +
> +    mod = &early_info.modules.module[nr];
> +
> +    prop = fdt_get_property(fdt, node, "reg", NULL);
> +    if ( !prop )
> +        early_panic("node %s missing `reg' property\n", name);
> +
> +    cell = (const u32 *)prop->data;
> +    device_tree_get_reg(&cell, address_cells, size_cells,
> +                        &mod->start, &mod->size);
> +
> +    prop = fdt_get_property(fdt, node, "bootargs", &len);
> +    if ( prop )
> +    {
> +        if ( len > sizeof(mod->cmdline) )
> +            early_panic("module %d command line too long\n", nr);
> +
> +        safe_strcpy(mod->cmdline, prop->data);
> +    }
> +    else
> +        mod->cmdline[0] = 0;
> +
> +    if ( nr > early_info.modules.nr_mods )
> +        early_info.modules.nr_mods = nr;
> +}
> +
>  static int __init early_scan_node(const void *fdt,
>                                    int node, const char *name, int depth,
>                                    u32 address_cells, u32 size_cells,
> @@ -352,6 +394,8 @@ static int __init early_scan_node(const void *fdt,
>          process_cpu_node(fdt, node, name, address_cells, size_cells);
>      else if ( device_tree_node_compatible(fdt, node, "arm,cortex-a15-gic") )
>          process_gic_node(fdt, node, name, address_cells, size_cells);
> +    else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) )
> +        process_multiboot_node(fdt, node, name, address_cells, size_cells);
>  
>      return 0;
>  }
> @@ -359,12 +403,20 @@ static int __init early_scan_node(const void *fdt,
>  static void __init early_print_info(void)
>  {
>      struct dt_mem_info *mi = &early_info.mem;
> +    struct dt_module_info *mods = &early_info.modules;
>      int i;
>  
>      for ( i = 0; i < mi->nr_banks; i++ )
> -        early_printk("RAM: %016llx - %016llx\n",
> +        early_printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
>                       mi->bank[i].start,
>                       mi->bank[i].start + mi->bank[i].size - 1);
> +    early_printk("\n");
> +    for ( i = 1 ; i < mods->nr_mods + 1; i++ )
> +        early_printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %s\n",
> +                     i,
> +                     mods->module[i].start,
> +                     mods->module[i].start + mods->module[i].size,
> +                     mods->module[i].cmdline);
>  }
>  
>  /**
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:56:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12:56: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 1U6KpW-0001Yw-2n; Fri, 15 Feb 2013 12:55: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 1U6KpT-0001Yf-Ra
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 12:55:52 +0000
Received: from [85.158.143.99:29930] by server-1.bemta-4.messagelabs.com id
	60/BB-08839-7503E115; Fri, 15 Feb 2013 12:55:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1360932947!24316455!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25548 invoked from network); 15 Feb 2013 12:55:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7300144"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 12:55:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 07:55:46 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6KpO-0002Ld-LO;
	Fri, 15 Feb 2013 12:55:46 +0000
Date: Fri, 15 Feb 2013 12:55:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1359555990-12186-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302151247180.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 2/4] xen: arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 30 Jan 2013, Ian Campbell wrote:
> The bootloader should populate /chosen/modules/module@<N>/ for each
> module it wishes to pass to the hypervisor. The content of these nodes
> is described in docs/misc/arm/device-tree/booting.txt
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v6: Match based on compatibility instead of path
> v5: Moved later in the series
> v4: Use /chosen/modules/module@N
>     Identify module type by compatible property not number.
> v3: Use a reg = < > property for the module address/length.
> v2: Reserve the zeroeth module for Xen itself (not used yet)
>     Use a more idiomatic DT layout
>     Document said layout

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  docs/misc/arm/device-tree/booting.txt |   25 +++++++++++++++
>  xen/common/device_tree.c              |   54 ++++++++++++++++++++++++++++++++-
>  2 files changed, 78 insertions(+), 1 deletions(-)
>  create mode 100644 docs/misc/arm/device-tree/booting.txt
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> new file mode 100644
> index 0000000..94cd3f1
> --- /dev/null
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -0,0 +1,25 @@
> +Xen is passed the dom0 kernel and initrd via a reference in the /chosen
> +node of the device tree.
> +
> +Each node has the form /chosen/modules/module@<N> and contains the following
> +properties:
> +
> +- compatible
> +
> +	Must be:
> +
> +		"xen,<type>", "xen,multiboot-module"
> +
> +	where <type> must be one of:
> +
> +	- "linux-zimage" -- the dom0 kernel
> +	- "linux-initrd" -- the dom0 ramdisk
> +
> +- reg
> +
> +	Specifies the physical address of the module in RAM and the
> +	length of the module.
> +
> +- bootargs (optional)
> +
> +	Command line associated with this module
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index f10ba1b..c92f8ca 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -341,6 +341,48 @@ static void __init process_gic_node(const void *fdt, int node,
>      early_info.gic.gic_vcpu_addr = start;
>  }
>  
> +static void __init process_multiboot_node(const void *fdt, int node,
> +                                          const char *name,
> +                                          u32 address_cells, u32 size_cells)
> +{
> +    const struct fdt_property *prop;
> +    const u32 *cell;
> +    int nr;
> +    struct dt_mb_module *mod;
> +    int len;
> +
> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
> +        nr = 1;
> +    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0)
> +        nr = 2;
> +    else
> +        early_panic("%s not a known xen multiboot type\n", name);
> +
> +    mod = &early_info.modules.module[nr];
> +
> +    prop = fdt_get_property(fdt, node, "reg", NULL);
> +    if ( !prop )
> +        early_panic("node %s missing `reg' property\n", name);
> +
> +    cell = (const u32 *)prop->data;
> +    device_tree_get_reg(&cell, address_cells, size_cells,
> +                        &mod->start, &mod->size);
> +
> +    prop = fdt_get_property(fdt, node, "bootargs", &len);
> +    if ( prop )
> +    {
> +        if ( len > sizeof(mod->cmdline) )
> +            early_panic("module %d command line too long\n", nr);
> +
> +        safe_strcpy(mod->cmdline, prop->data);
> +    }
> +    else
> +        mod->cmdline[0] = 0;
> +
> +    if ( nr > early_info.modules.nr_mods )
> +        early_info.modules.nr_mods = nr;
> +}
> +
>  static int __init early_scan_node(const void *fdt,
>                                    int node, const char *name, int depth,
>                                    u32 address_cells, u32 size_cells,
> @@ -352,6 +394,8 @@ static int __init early_scan_node(const void *fdt,
>          process_cpu_node(fdt, node, name, address_cells, size_cells);
>      else if ( device_tree_node_compatible(fdt, node, "arm,cortex-a15-gic") )
>          process_gic_node(fdt, node, name, address_cells, size_cells);
> +    else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) )
> +        process_multiboot_node(fdt, node, name, address_cells, size_cells);
>  
>      return 0;
>  }
> @@ -359,12 +403,20 @@ static int __init early_scan_node(const void *fdt,
>  static void __init early_print_info(void)
>  {
>      struct dt_mem_info *mi = &early_info.mem;
> +    struct dt_module_info *mods = &early_info.modules;
>      int i;
>  
>      for ( i = 0; i < mi->nr_banks; i++ )
> -        early_printk("RAM: %016llx - %016llx\n",
> +        early_printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
>                       mi->bank[i].start,
>                       mi->bank[i].start + mi->bank[i].size - 1);
> +    early_printk("\n");
> +    for ( i = 1 ; i < mods->nr_mods + 1; i++ )
> +        early_printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %s\n",
> +                     i,
> +                     mods->module[i].start,
> +                     mods->module[i].start + mods->module[i].size,
> +                     mods->module[i].cmdline);
>  }
>  
>  /**
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:57:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6Kqx-0001gq-Ip; Fri, 15 Feb 2013 12:57: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 1U6Kqw-0001gf-Fl
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:57:22 +0000
Received: from [85.158.143.35:3340] by server-2.bemta-4.messagelabs.com id
	C5/A5-01597-1B03E115; Fri, 15 Feb 2013 12:57:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360933041!3909197!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20075 invoked from network); 15 Feb 2013 12:57:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1514053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:57: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.297.1;
	Fri, 15 Feb 2013 12:57:21 +0000
Message-ID: <1360933039.31407.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 12:57:19 +0000
In-Reply-To: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 6/7] xen/arm: introduce gic callbacks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:37 +0000, Stefano Stabellini wrote:
> Introduce callbacks to receive notifications from the GIC when a
> specific IRQ has been EOI'd by the guest.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c        |   12 ++++++++++++
>  xen/arch/arm/setup.c      |    1 +
>  xen/include/asm-arm/gic.h |    5 +++++
>  3 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 1c8219d..0ecc0f1 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -52,6 +52,7 @@ static struct {
>  static irq_desc_t irq_desc[NR_IRQS];
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
> +static gic_callback_fn_t gic_callbacks[NR_IRQS];

I think this should rather go in struct arch_irq_desc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 12:57:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 12: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 1U6Kqx-0001gq-Ip; Fri, 15 Feb 2013 12:57: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 1U6Kqw-0001gf-Fl
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 12:57:22 +0000
Received: from [85.158.143.35:3340] by server-2.bemta-4.messagelabs.com id
	C5/A5-01597-1B03E115; Fri, 15 Feb 2013 12:57:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1360933041!3909197!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20075 invoked from network); 15 Feb 2013 12:57:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 12:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1514053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 12:57: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.297.1;
	Fri, 15 Feb 2013 12:57:21 +0000
Message-ID: <1360933039.31407.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 12:57:19 +0000
In-Reply-To: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 6/7] xen/arm: introduce gic callbacks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:37 +0000, Stefano Stabellini wrote:
> Introduce callbacks to receive notifications from the GIC when a
> specific IRQ has been EOI'd by the guest.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/gic.c        |   12 ++++++++++++
>  xen/arch/arm/setup.c      |    1 +
>  xen/include/asm-arm/gic.h |    5 +++++
>  3 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 1c8219d..0ecc0f1 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -52,6 +52,7 @@ static struct {
>  static irq_desc_t irq_desc[NR_IRQS];
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
> +static gic_callback_fn_t gic_callbacks[NR_IRQS];

I think this should rather go in struct arch_irq_desc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:01:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6Kv7-0001xl-8R; Fri, 15 Feb 2013 13:01:41 +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 1U6Kv5-0001xg-P4
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:01:39 +0000
Received: from [85.158.138.51:41481] by server-16.bemta-3.messagelabs.com id
	4B/F5-02727-2B13E115; Fri, 15 Feb 2013 13:01:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360933279!27744797!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4736 invoked from network); 15 Feb 2013 13:01: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; 15 Feb 2013 13:01:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 13:03:28 +0000
Message-Id: <511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 13:01:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 13:08, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 14 Feb 2013, Ian Campbell wrote:
>> --- a/arch/arm/include/asm/xen/interface.h
>> +++ b/arch/arm/include/asm/xen/interface.h
>> @@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
>>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>>  
>> +/*
>> + * On ARM this is not part of the hypervisor ABI but we provide it
>> + * internally for the benefit of common code.
>> + */
>> +struct start_info {
>> +        uint32_t flags;             /* SIF_xxx flags.                         */
>> +        uint32_t store_evtchn;      /* Event channel for store communication. */
>> +        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
>> +        union {
>> +                struct {
>> +                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
>> +                        uint32_t  evtchn;   /* Event channel for console page.        */
>> +                } domU;
>> +                struct {
>> +                        uint32_t info_off;  /* Offset of console_info struct.         */
>> +                        uint32_t info_size; /* Size of console_info struct from start.*/
>> +                } dom0;
>> +        } console;
>> +	/* UNUSED ON ARM */
>> +        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
>> +};
>> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
>> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */

With this it's even less clear to me why you want all of it removed
from a architecture independent header.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:01:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6Kv7-0001xl-8R; Fri, 15 Feb 2013 13:01:41 +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 1U6Kv5-0001xg-P4
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:01:39 +0000
Received: from [85.158.138.51:41481] by server-16.bemta-3.messagelabs.com id
	4B/F5-02727-2B13E115; Fri, 15 Feb 2013 13:01:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1360933279!27744797!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4736 invoked from network); 15 Feb 2013 13:01: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; 15 Feb 2013 13:01:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 13:03:28 +0000
Message-Id: <511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 13:01:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 13:08, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 14 Feb 2013, Ian Campbell wrote:
>> --- a/arch/arm/include/asm/xen/interface.h
>> +++ b/arch/arm/include/asm/xen/interface.h
>> @@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
>>  DEFINE_GUEST_HANDLE(xen_pfn_t);
>>  DEFINE_GUEST_HANDLE(xen_ulong_t);
>>  
>> +/*
>> + * On ARM this is not part of the hypervisor ABI but we provide it
>> + * internally for the benefit of common code.
>> + */
>> +struct start_info {
>> +        uint32_t flags;             /* SIF_xxx flags.                         */
>> +        uint32_t store_evtchn;      /* Event channel for store communication. */
>> +        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
>> +        union {
>> +                struct {
>> +                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
>> +                        uint32_t  evtchn;   /* Event channel for console page.        */
>> +                } domU;
>> +                struct {
>> +                        uint32_t info_off;  /* Offset of console_info struct.         */
>> +                        uint32_t info_size; /* Size of console_info struct from start.*/
>> +                } dom0;
>> +        } console;
>> +	/* UNUSED ON ARM */
>> +        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
>> +};
>> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
>> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */

With this it's even less clear to me why you want all of it removed
from a architecture independent header.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:04:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6KxS-000287-Vc; Fri, 15 Feb 2013 13:04: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 1U6KxQ-000281-Ln
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:04:04 +0000
Received: from [85.158.139.83:62965] by server-13.bemta-5.messagelabs.com id
	5C/0C-06769-3423E115; Fri, 15 Feb 2013 13:04:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360933443!26908367!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24707 invoked from network); 15 Feb 2013 13:04:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:04:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1514307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:04: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.297.1;
	Fri, 15 Feb 2013 13:04:03 +0000
Message-ID: <1360933441.31407.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:04:01 +0000
In-Reply-To: <1360933039.31407.29.camel@zakaz.uk.xensource.com>
References: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933039.31407.29.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 6/7] xen/arm: introduce gic callbacks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:57 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:37 +0000, Stefano Stabellini wrote:
> > Introduce callbacks to receive notifications from the GIC when a
> > specific IRQ has been EOI'd by the guest.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c        |   12 ++++++++++++
> >  xen/arch/arm/setup.c      |    1 +
> >  xen/include/asm-arm/gic.h |    5 +++++
> >  3 files changed, 18 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 1c8219d..0ecc0f1 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -52,6 +52,7 @@ static struct {
> >  static irq_desc_t irq_desc[NR_IRQS];
> >  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> > +static gic_callback_fn_t gic_callbacks[NR_IRQS];
> 
> I think this should rather go in struct arch_irq_desc.

Actually, aren't these *virtual* interrupt callbacks?

It is possible that IRQ30 for one guest might not have the same use as
IRQ30 in another, which suggests that this belongs in some domain
specific location, like struct pending_irq.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:04:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6KxS-000287-Vc; Fri, 15 Feb 2013 13:04: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 1U6KxQ-000281-Ln
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:04:04 +0000
Received: from [85.158.139.83:62965] by server-13.bemta-5.messagelabs.com id
	5C/0C-06769-3423E115; Fri, 15 Feb 2013 13:04:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1360933443!26908367!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24707 invoked from network); 15 Feb 2013 13:04:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:04:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1514307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:04: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.297.1;
	Fri, 15 Feb 2013 13:04:03 +0000
Message-ID: <1360933441.31407.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:04:01 +0000
In-Reply-To: <1360933039.31407.29.camel@zakaz.uk.xensource.com>
References: <1360859833-16498-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933039.31407.29.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 6/7] xen/arm: introduce gic callbacks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:57 +0000, Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:37 +0000, Stefano Stabellini wrote:
> > Introduce callbacks to receive notifications from the GIC when a
> > specific IRQ has been EOI'd by the guest.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/gic.c        |   12 ++++++++++++
> >  xen/arch/arm/setup.c      |    1 +
> >  xen/include/asm-arm/gic.h |    5 +++++
> >  3 files changed, 18 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index 1c8219d..0ecc0f1 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -52,6 +52,7 @@ static struct {
> >  static irq_desc_t irq_desc[NR_IRQS];
> >  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
> >  static DEFINE_PER_CPU(uint64_t, lr_mask);
> > +static gic_callback_fn_t gic_callbacks[NR_IRQS];
> 
> I think this should rather go in struct arch_irq_desc.

Actually, aren't these *virtual* interrupt callbacks?

It is possible that IRQ30 for one guest might not have the same use as
IRQ30 in another, which suggests that this belongs in some domain
specific location, like struct pending_irq.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:05:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6Kyn-0002EQ-Fs; Fri, 15 Feb 2013 13:05: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 1U6Kym-0002EH-Qh
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:05:29 +0000
Received: from [85.158.138.51:11524] by server-15.bemta-3.messagelabs.com id
	17/B4-25405-9823E115; Fri, 15 Feb 2013 13:05:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360933490!19686780!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25432 invoked from network); 15 Feb 2013 13:04:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:04:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1514355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:04: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.297.1;
	Fri, 15 Feb 2013 13:04:50 +0000
Message-ID: <1360933488.31407.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:04:48 +0000
In-Reply-To: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

> @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
>  {
>      struct vtimer *t = data;
>      t->ctl |= CNTx_CTL_PENDING;
> -    t->ctl &= ~CNTx_CTL_MASK;
> -    vgic_vcpu_inject_irq(t->v, 30, 1);
> +    if ( !(t->ctl & CNTx_CTL_MASK) )
> +        vgic_vcpu_inject_irq(t->v, 30, 1);

Thinking about the previous discussion about exposing the change of the
mask bit to the guest, it just occurred to me that t->ctl.MASK need not
actually represent the state of the underlying physical mask bit, since
we do emulate accesses after all.

>  }
>  
>  static void virt_timer_expired(void *data)
> @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
>      vgic_vcpu_inject_irq(t->v, 27, 1);
>  }
>   
> +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> +{
> +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> +}
> +
> +int __init init_ptimer(void)
> +{
> +    register_gic_callback(30, phys_timer_gic_callback);
> +    return 0;
> +}
> +
>  int vcpu_vtimer_init(struct vcpu *v)
>  {
>      struct vtimer *t = &v->arch.phys_timer;
> @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>          {
>              v->arch.phys_timer.ctl = *r;
>  
> -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||

Why does PENDING matter here and below?

> +                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
> +                stop_timer(&v->arch.phys_timer.timer);
> +            else
>              {
>                  set_timer(&v->arch.phys_timer.timer,
>                            v->arch.phys_timer.cval + v->arch.phys_timer.offset);
>              }
> -            else
> -                stop_timer(&v->arch.phys_timer.timer);
>          }
>  
>          return 1;
> @@ -139,7 +153,11 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>          else
>          {
>              v->arch.phys_timer.cval = now + ticks_to_ns(*r);
> -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> +                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
> +                stop_timer(&v->arch.phys_timer.timer);
> +            else
>              {
>                  set_timer(&v->arch.phys_timer.timer,
>                            v->arch.phys_timer.cval + v->arch.phys_timer.offset);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:05:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6Kyn-0002EQ-Fs; Fri, 15 Feb 2013 13:05: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 1U6Kym-0002EH-Qh
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:05:29 +0000
Received: from [85.158.138.51:11524] by server-15.bemta-3.messagelabs.com id
	17/B4-25405-9823E115; Fri, 15 Feb 2013 13:05:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1360933490!19686780!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25432 invoked from network); 15 Feb 2013 13:04:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:04:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1514355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:04: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.297.1;
	Fri, 15 Feb 2013 13:04:50 +0000
Message-ID: <1360933488.31407.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:04:48 +0000
In-Reply-To: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

> @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
>  {
>      struct vtimer *t = data;
>      t->ctl |= CNTx_CTL_PENDING;
> -    t->ctl &= ~CNTx_CTL_MASK;
> -    vgic_vcpu_inject_irq(t->v, 30, 1);
> +    if ( !(t->ctl & CNTx_CTL_MASK) )
> +        vgic_vcpu_inject_irq(t->v, 30, 1);

Thinking about the previous discussion about exposing the change of the
mask bit to the guest, it just occurred to me that t->ctl.MASK need not
actually represent the state of the underlying physical mask bit, since
we do emulate accesses after all.

>  }
>  
>  static void virt_timer_expired(void *data)
> @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
>      vgic_vcpu_inject_irq(t->v, 27, 1);
>  }
>   
> +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> +{
> +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> +}
> +
> +int __init init_ptimer(void)
> +{
> +    register_gic_callback(30, phys_timer_gic_callback);
> +    return 0;
> +}
> +
>  int vcpu_vtimer_init(struct vcpu *v)
>  {
>      struct vtimer *t = &v->arch.phys_timer;
> @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>          {
>              v->arch.phys_timer.ctl = *r;
>  
> -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||

Why does PENDING matter here and below?

> +                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
> +                stop_timer(&v->arch.phys_timer.timer);
> +            else
>              {
>                  set_timer(&v->arch.phys_timer.timer,
>                            v->arch.phys_timer.cval + v->arch.phys_timer.offset);
>              }
> -            else
> -                stop_timer(&v->arch.phys_timer.timer);
>          }
>  
>          return 1;
> @@ -139,7 +153,11 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>          else
>          {
>              v->arch.phys_timer.cval = now + ticks_to_ns(*r);
> -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> +                 !(v->arch.phys_timer.ctl & CNTx_CTL_ENABLE) )
> +                stop_timer(&v->arch.phys_timer.timer);
> +            else
>              {
>                  set_timer(&v->arch.phys_timer.timer,
>                            v->arch.phys_timer.cval + v->arch.phys_timer.offset);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:14:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6L7D-0002Ws-Qf; Fri, 15 Feb 2013 13:14:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6L7C-0002Wn-8b
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:14:10 +0000
Received: from [85.158.139.211:62274] by server-6.bemta-5.messagelabs.com id
	02/AF-01489-1A43E115; Fri, 15 Feb 2013 13:14:09 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360934048!22227405!1
X-Originating-IP: [209.85.215.179]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15192 invoked from network); 15 Feb 2013 13:14:08 -0000
Received: from mail-ea0-f179.google.com (HELO mail-ea0-f179.google.com)
	(209.85.215.179)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:14:08 -0000
Received: by mail-ea0-f179.google.com with SMTP id d12so1311438eaa.24
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Feb 2013 05:14:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=9Bs20r7Ln8SKDgteWR5Ibu5RPAcfwIgpePj1DySiF/Q=;
	b=GsONbf4ZTSEjAINoVb3OuenyBGzzFsThJLZcHTina+3UCu/7E+z+mERYZeAB8kfjMr
	XEPmCymD1BU9s7do2UhOXwO6cuy6h0ragEkhiRPyTXAgaYo5fhKLAZAaqiYoSPxB56vn
	KJNbYyNK9nb7oaipK2iD2JydLR4PNtHRCd21SP/1+tuHnN71NnGEFqy15qQHdf4uDM1H
	YsNlrdVOx4bb4zh9H1FGRe2eA77rJsa4vr8ZtwYlRLg2cdV9opaVutLa/o6wUuFTPFyC
	sApGqehTSQdPDfKE097TD3VNp+ePvfFYgcJbFZvkR/NmnalucZayFPRTTfWtiOIGUheO
	n0/A==
X-Received: by 10.14.219.129 with SMTP id m1mr8369779eep.16.1360934048519;
	Fri, 15 Feb 2013 05:14:08 -0800 (PST)
Received: from [192.168.0.162]
	(host143-150-static.38-79-b.business.telecomitalia.it.
	[79.38.150.143])
	by mx.google.com with ESMTPS id f47sm37933631eep.13.2013.02.15.05.14.06
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 05:14:07 -0800 (PST)
Message-ID: <511E34A8.9090706@heliman.it>
Date: Fri, 15 Feb 2013 14:14:16 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5111301B.8080304@heliman.it>
	<1360930691.31407.20.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360930691.31407.20.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQnOCK/Bah38POB4gXHplNodoJWIzRaJYNztZ/rKr4J30Ekvhvr1rd/OyOzhT9XI+TcvvYie
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Disable useless empty floppy
 drive with 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-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

Il 15/02/2013 13:18, Ian Campbell ha scritto:
> On Tue, 2013-02-05 at 16:15 +0000, Fabio Fantoni wrote:
>> tools/libxl: Disable useless empty floppy drive with
>>    qemu-xen
>>
>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> ---
>>    tools/libxl/libxl_dm.c |    3 +++
>>    1 file changed, 3 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 51f9914..c265618 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -406,6 +406,9 @@ static char **
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>>            int ioemu_nics = 0;
>>
>> +        /* Disable useless empty floppy drive */
>> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
>> +
>>            if (b_info->u.hvm.serial) {
>>                flexarray_vappend(dm_args, "-serial",
>> b_info->u.hvm.serial, NULL);
> I'm afraid this patch is whitespace corrupted.
>
> I strongly recommend that you investigate the use of git send-email.
>
> Ian.
>
I already resent with git send-email:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:14:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6L7D-0002Ws-Qf; Fri, 15 Feb 2013 13:14:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6L7C-0002Wn-8b
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:14:10 +0000
Received: from [85.158.139.211:62274] by server-6.bemta-5.messagelabs.com id
	02/AF-01489-1A43E115; Fri, 15 Feb 2013 13:14:09 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360934048!22227405!1
X-Originating-IP: [209.85.215.179]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15192 invoked from network); 15 Feb 2013 13:14:08 -0000
Received: from mail-ea0-f179.google.com (HELO mail-ea0-f179.google.com)
	(209.85.215.179)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:14:08 -0000
Received: by mail-ea0-f179.google.com with SMTP id d12so1311438eaa.24
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Feb 2013 05:14:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=9Bs20r7Ln8SKDgteWR5Ibu5RPAcfwIgpePj1DySiF/Q=;
	b=GsONbf4ZTSEjAINoVb3OuenyBGzzFsThJLZcHTina+3UCu/7E+z+mERYZeAB8kfjMr
	XEPmCymD1BU9s7do2UhOXwO6cuy6h0ragEkhiRPyTXAgaYo5fhKLAZAaqiYoSPxB56vn
	KJNbYyNK9nb7oaipK2iD2JydLR4PNtHRCd21SP/1+tuHnN71NnGEFqy15qQHdf4uDM1H
	YsNlrdVOx4bb4zh9H1FGRe2eA77rJsa4vr8ZtwYlRLg2cdV9opaVutLa/o6wUuFTPFyC
	sApGqehTSQdPDfKE097TD3VNp+ePvfFYgcJbFZvkR/NmnalucZayFPRTTfWtiOIGUheO
	n0/A==
X-Received: by 10.14.219.129 with SMTP id m1mr8369779eep.16.1360934048519;
	Fri, 15 Feb 2013 05:14:08 -0800 (PST)
Received: from [192.168.0.162]
	(host143-150-static.38-79-b.business.telecomitalia.it.
	[79.38.150.143])
	by mx.google.com with ESMTPS id f47sm37933631eep.13.2013.02.15.05.14.06
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 05:14:07 -0800 (PST)
Message-ID: <511E34A8.9090706@heliman.it>
Date: Fri, 15 Feb 2013 14:14:16 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5111301B.8080304@heliman.it>
	<1360930691.31407.20.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360930691.31407.20.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQnOCK/Bah38POB4gXHplNodoJWIzRaJYNztZ/rKr4J30Ekvhvr1rd/OyOzhT9XI+TcvvYie
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Disable useless empty floppy
 drive with 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-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

Il 15/02/2013 13:18, Ian Campbell ha scritto:
> On Tue, 2013-02-05 at 16:15 +0000, Fabio Fantoni wrote:
>> tools/libxl: Disable useless empty floppy drive with
>>    qemu-xen
>>
>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> ---
>>    tools/libxl/libxl_dm.c |    3 +++
>>    1 file changed, 3 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 51f9914..c265618 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -406,6 +406,9 @@ static char **
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>>            int ioemu_nics = 0;
>>
>> +        /* Disable useless empty floppy drive */
>> +        flexarray_vappend(dm_args, "-global", "isa-fdc.driveA=", NULL);
>> +
>>            if (b_info->u.hvm.serial) {
>>                flexarray_vappend(dm_args, "-serial",
>> b_info->u.hvm.serial, NULL);
> I'm afraid this patch is whitespace corrupted.
>
> I strongly recommend that you investigate the use of git send-email.
>
> Ian.
>
I already resent with git send-email:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg00391.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:14:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6L7K-0002XH-63; Fri, 15 Feb 2013 13:14: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 1U6L7J-0002XA-Ly
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:14:17 +0000
Received: from [193.109.254.147:7891] by server-9.bemta-14.messagelabs.com id
	45/2A-30867-8A43E115; Fri, 15 Feb 2013 13:14:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360934054!1683609!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 15 Feb 2013 13:14:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 13:14:15 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FDE9Y1005056
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 13:14:10 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
	r1FDE7gP001370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 13:14:08 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1FDE7Go006434; Fri, 15 Feb 2013 07:14:07 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 05:14:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3099D1C387B; Fri, 15 Feb 2013 08:14:06 -0500 (EST)
Date: Fri, 15 Feb 2013 08:14:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@kernel.dk, linux-kernel@vger.kernel.org
Message-ID: <20130215131406.GA11630@phenom.dumpdata.com>
References: <20130214232630.GA8440@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130214232630.GA8440@phenom.dumpdata.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: [Xen-devel] One more: Re: [GIT PULL] (xen) stable/for-jens-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 14, 2013 at 06:26:30PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> Please git pull the following branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8
> 
> which has fixes to the blkback that I hope you can push to Linus for 3.8.
> The one that is quite vicious is the "xen-blkfront: drop the use of
> llist_for_each_entry_safe". It is a fix to re-do an "free-ing" loop - otherwise
> we hit a GCC 4.1.1 bug (so RHEL5 based) that turns the loop in an unbound one.
> 
> Please pull!
> 
>  drivers/block/xen-blkback/blkback.c |  1 -
>  drivers/block/xen-blkback/xenbus.c  | 49 ++++++++++++++++++-------------------
>  drivers/block/xen-blkfront.c        | 13 +++++++---
>  include/linux/llist.h               | 25 -------------------
>  4 files changed, 34 insertions(+), 54 deletions(-)
> 
> Jan Beulich (1):
>       xen-blkback: do not leak mode property
> 
> Konrad Rzeszutek Wilk (2):
>       xen/blkback: Don't trust the handle from the frontend.
>       xen-blkfront: drop the use of llist_for_each_entry_safe
> 

And on the hells of that one, I've got one more ! (yeah, I am sure you
are thrilled about it).

Same branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8

This time fixing a memory leak in the xen-blkback with the persistent
grants feature.

 drivers/block/xen-blkback/blkback.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Roger Pau Monne (1):
      xen-blkback: use balloon pages for persistent grants

Please pull!

If you want to delay pushing them to Linus until 3.9 I can poke Greg
about back-porting those to the stable tree - your call.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:14:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6L7K-0002XH-63; Fri, 15 Feb 2013 13:14: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 1U6L7J-0002XA-Ly
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:14:17 +0000
Received: from [193.109.254.147:7891] by server-9.bemta-14.messagelabs.com id
	45/2A-30867-8A43E115; Fri, 15 Feb 2013 13:14:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360934054!1683609!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8574 invoked from network); 15 Feb 2013 13:14:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 13:14:15 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FDE9Y1005056
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 13:14:10 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
	r1FDE7gP001370
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 13:14:08 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1FDE7Go006434; Fri, 15 Feb 2013 07:14:07 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 05:14:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3099D1C387B; Fri, 15 Feb 2013 08:14:06 -0500 (EST)
Date: Fri, 15 Feb 2013 08:14:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@kernel.dk, linux-kernel@vger.kernel.org
Message-ID: <20130215131406.GA11630@phenom.dumpdata.com>
References: <20130214232630.GA8440@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130214232630.GA8440@phenom.dumpdata.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: [Xen-devel] One more: Re: [GIT PULL] (xen) stable/for-jens-3.8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 14, 2013 at 06:26:30PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> Please git pull the following branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8
> 
> which has fixes to the blkback that I hope you can push to Linus for 3.8.
> The one that is quite vicious is the "xen-blkfront: drop the use of
> llist_for_each_entry_safe". It is a fix to re-do an "free-ing" loop - otherwise
> we hit a GCC 4.1.1 bug (so RHEL5 based) that turns the loop in an unbound one.
> 
> Please pull!
> 
>  drivers/block/xen-blkback/blkback.c |  1 -
>  drivers/block/xen-blkback/xenbus.c  | 49 ++++++++++++++++++-------------------
>  drivers/block/xen-blkfront.c        | 13 +++++++---
>  include/linux/llist.h               | 25 -------------------
>  4 files changed, 34 insertions(+), 54 deletions(-)
> 
> Jan Beulich (1):
>       xen-blkback: do not leak mode property
> 
> Konrad Rzeszutek Wilk (2):
>       xen/blkback: Don't trust the handle from the frontend.
>       xen-blkfront: drop the use of llist_for_each_entry_safe
> 

And on the hells of that one, I've got one more ! (yeah, I am sure you
are thrilled about it).

Same branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8

This time fixing a memory leak in the xen-blkback with the persistent
grants feature.

 drivers/block/xen-blkback/blkback.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Roger Pau Monne (1):
      xen-blkback: use balloon pages for persistent grants

Please pull!

If you want to delay pushing them to Linus until 3.9 I can poke Greg
about back-porting those to the stable tree - your call.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:16:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:16: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 1U6L92-0002h4-Ml; Fri, 15 Feb 2013 13:16: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 1U6L91-0002gv-Iy
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:16:04 +0000
Received: from [85.158.139.211:13224] by server-13.bemta-5.messagelabs.com id
	12/74-06769-2153E115; Fri, 15 Feb 2013 13:16:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360934160!22644179!1
X-Originating-IP: [74.125.82.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28343 invoked from network); 15 Feb 2013 13:16:00 -0000
Received: from mail-we0-f170.google.com (HELO mail-we0-f170.google.com)
	(74.125.82.170)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:16:00 -0000
Received: by mail-we0-f170.google.com with SMTP id z53so3005769wey.1
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Feb 2013 05:16:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=7wLAV9vqkhYJ8XJIs/ECAAQwDSZM2psgoYL19YCnB9c=;
	b=fsrECGXs/aw3bFJNOye5HUtFItXoIrYZAywpGSBlJ/jMacrku4oOmILttl8K6D55er
	7vX15ipoMizDST1t7zevBAxEJatxb3dFgfRCZkFPUGHziOgfoyDCXXOBK6Z+UUTNUhLV
	iLSbNFMWf1cWYCMuWr3/mX/AQ/vDxDDx+Ta3G1asniKrzLH0yrLc5McKWvnr0SRXFVeO
	e1FiMYZNA1kHj48/sRzJKQseRj1k89WEjdZumtWIoDr6z8+xetV9Aauae6WeBGOVDPSE
	t9pjM4oocUV/DHPIJoTK1vF2YaxCcq2pnTxacANeVEjrAbAjjYJEI5X2itMo9B3ShIKQ
	trXQ==
X-Received: by 10.194.174.234 with SMTP id bv10mr4082236wjc.47.1360934159963; 
	Fri, 15 Feb 2013 05:15:59 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id j4sm2945514wiz.10.2013.02.15.05.15.57
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 05:15:59 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 13:15:55 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <CD43E58B.5B119%keir@xen.org>
Thread-Topic: [PATCH v7 1/5] xen: introduce a generic framebuffer driver
Thread-Index: Ac4LfpX1X0k7sZNJM0mUBbPddt3lKg==
In-Reply-To: <1360932105.31407.25.camel@zakaz.uk.xensource.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] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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

Yep

Acked-by: Keir Fraser <keir@xen.org>


On 15/02/2013 12:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> Keir, are you OK with this change?
> 
> On Thu, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
>> Abstract away from vesa.c the funcions to handle a linear framebuffer
>> and print characters to it.
>> Make use of the new functions in vesa.c.
>> 
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Acked-by: Jan Beulich <JBeulich@suse.com>
>> 
>> Changes in v6:
>> - remove useless initializations to NULL in lfb_init;
>> - more compact checks in lfb_init.
>> 
>> Changes in v5:
>> - remove lfb_alloc and the now unused __initdata variables;
>> - fix indentation and long lines.
>> 
>> Changes in v4:
>> - squash the vesa.c changes into this patch;
>> - rename fb* to lfb*;
>> - pass a pointer to fb_init;
>> - use %u for screen dimensions;
>> - specify loglevel in printk;
>> - call fb_free on error in fb_alloc;
>> - no __init on declarations;
>> - do not break messages to fit 80 columns.
>> ---
>>  xen/drivers/video/Makefile |    1 +
>>  xen/drivers/video/lfb.c    |  183
>> ++++++++++++++++++++++++++++++++++++++++++++
>>  xen/drivers/video/lfb.h    |   46 +++++++++++
>>  xen/drivers/video/vesa.c   |  177 ++++++------------------------------------
>>  4 files changed, 254 insertions(+), 153 deletions(-)
>>  create mode 100644 xen/drivers/video/lfb.c
>>  create mode 100644 xen/drivers/video/lfb.h
>> 
>> diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
>> index 2993c39..77f9d5d 100644
>> --- a/xen/drivers/video/Makefile
>> +++ b/xen/drivers/video/Makefile
>> @@ -2,4 +2,5 @@ obj-$(HAS_VGA) := vga.o
>>  obj-$(HAS_VIDEO) += font_8x14.o
>>  obj-$(HAS_VIDEO) += font_8x16.o
>>  obj-$(HAS_VIDEO) += font_8x8.o
>> +obj-$(HAS_VIDEO) += lfb.o
>>  obj-$(HAS_VGA) += vesa.o
>> diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
>> new file mode 100644
>> index 0000000..cc7f7ac
>> --- /dev/null
>> +++ b/xen/drivers/video/lfb.c
>> @@ -0,0 +1,183 @@
>> +/***************************************************************************
>> ***
>> + * lfb.c
>> + *
>> + * linear frame buffer handling.
>> + */
>> +
>> +#include <xen/config.h>
>> +#include <xen/kernel.h>
>> +#include <xen/lib.h>
>> +#include <xen/errno.h>
>> +#include "lfb.h"
>> +#include "font.h"
>> +
>> +#define MAX_XRES 1900
>> +#define MAX_YRES 1200
>> +#define MAX_BPP 4
>> +#define MAX_FONT_W 8
>> +#define MAX_FONT_H 16
>> +
>> +struct lfb_status {
>> +    struct lfb_prop lfbp;
>> +
>> +    unsigned char *lbuf, *text_buf;
>> +    unsigned int *line_len;
>> +    unsigned int xpos, ypos;
>> +};
>> +static struct lfb_status lfb;
>> +
>> +static void lfb_show_line(
>> +    const unsigned char *text_line,
>> +    unsigned char *video_line,
>> +    unsigned int nr_chars,
>> +    unsigned int nr_cells)
>> +{
>> +    unsigned int i, j, b, bpp, pixel;
>> +
>> +    bpp = (lfb.lfbp.bits_per_pixel + 7) >> 3;
>> +
>> +    for ( i = 0; i < lfb.lfbp.font->height; i++ )
>> +    {
>> +        unsigned char *ptr = lfb.lbuf;
>> +
>> +        for ( j = 0; j < nr_chars; j++ )
>> +        {
>> +            const unsigned char *bits = lfb.lfbp.font->data;
>> +            bits += ((text_line[j] * lfb.lfbp.font->height + i) *
>> +                     ((lfb.lfbp.font->width + 7) >> 3));
>> +            for ( b = lfb.lfbp.font->width; b--; )
>> +            {
>> +                pixel = (*bits & (1u<<b)) ? lfb.lfbp.pixel_on : 0;
>> +                memcpy(ptr, &pixel, bpp);
>> +                ptr += bpp;
>> +            }
>> +        }
>> +
>> +        memset(ptr, 0, (lfb.lfbp.width - nr_chars * lfb.lfbp.font->width) *
>> bpp);
>> +        memcpy(video_line, lfb.lbuf, nr_cells * lfb.lfbp.font->width * bpp);
>> +        video_line += lfb.lfbp.bytes_per_line;
>> +    }
>> +}
>> +
>> +/* Fast mode which redraws all modified parts of a 2D text buffer. */
>> +void lfb_redraw_puts(const char *s)
>> +{
>> +    unsigned int i, min_redraw_y = lfb.ypos;
>> +    char c;
>> +
>> +    /* Paste characters into text buffer. */
>> +    while ( (c = *s++) != '\0' )
>> +    {
>> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
>> +        {
>> +            if ( ++lfb.ypos >= lfb.lfbp.text_rows )
>> +            {
>> +                min_redraw_y = 0;
>> +                lfb.ypos = lfb.lfbp.text_rows - 1;
>> +                memmove(lfb.text_buf, lfb.text_buf + lfb.lfbp.text_columns,
>> +                        lfb.ypos * lfb.lfbp.text_columns);
>> +                memset(lfb.text_buf + lfb.ypos * lfb.lfbp.text_columns, 0,
>> lfb.xpos);
>> +            }
>> +            lfb.xpos = 0;
>> +        }
>> +
>> +        if ( c != '\n' )
>> +            lfb.text_buf[lfb.xpos++ + lfb.ypos * lfb.lfbp.text_columns] = c;
>> +    }
>> +
>> +    /* Render modified section of text buffer to VESA linear framebuffer. */
>> +    for ( i = min_redraw_y; i <= lfb.ypos; i++ )
>> +    {
>> +        const unsigned char *line = lfb.text_buf + i *
>> lfb.lfbp.text_columns;
>> +        unsigned int width;
>> +
>> +        for ( width = lfb.lfbp.text_columns; width; --width )
>> +            if ( line[width - 1] )
>> +                 break;
>> +        lfb_show_line(line,
>> +                       lfb.lfbp.lfb + i * lfb.lfbp.font->height *
>> lfb.lfbp.bytes_per_line,
>> +                       width, max(lfb.line_len[i], width));
>> +        lfb.line_len[i] = width;
>> +    }
>> +
>> +    lfb.lfbp.flush();
>> +}
>> +
>> +/* Slower line-based scroll mode which interacts better with dom0. */
>> +void lfb_scroll_puts(const char *s)
>> +{
>> +    unsigned int i;
>> +    char c;
>> +
>> +    while ( (c = *s++) != '\0' )
>> +    {
>> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
>> +        {
>> +            unsigned int bytes = (lfb.lfbp.width *
>> +                                  ((lfb.lfbp.bits_per_pixel + 7) >> 3));
>> +            unsigned char *src = lfb.lfbp.lfb + lfb.lfbp.font->height *
>> lfb.lfbp.bytes_per_line;
>> +            unsigned char *dst = lfb.lfbp.lfb;
>> +
>> +            /* New line: scroll all previous rows up one line. */
>> +            for ( i = lfb.lfbp.font->height; i < lfb.lfbp.height; i++ )
>> +            {
>> +                memcpy(dst, src, bytes);
>> +                src += lfb.lfbp.bytes_per_line;
>> +                dst += lfb.lfbp.bytes_per_line;
>> +            }
>> +
>> +            /* Render new line. */
>> +            lfb_show_line(
>> +                lfb.text_buf,
>> +                lfb.lfbp.lfb + (lfb.lfbp.text_rows-1) *
>> lfb.lfbp.font->height *
>> +                lfb.lfbp.bytes_per_line,
>> +                lfb.xpos, lfb.lfbp.text_columns);
>> +
>> +            lfb.xpos = 0;
>> +        }
>> +
>> +        if ( c != '\n' )
>> +            lfb.text_buf[lfb.xpos++] = c;
>> +    }
>> +
>> +    lfb.lfbp.flush();
>> +}
>> +
>> +void lfb_carriage_return(void)
>> +{
>> +    lfb.xpos = 0;
>> +}
>> +
>> +int __init lfb_init(struct lfb_prop *lfbp)
>> +{
>> +    if ( lfbp->width > MAX_XRES || lfbp->height > MAX_YRES )
>> +    {
>> +        printk(XENLOG_WARNING "Couldn't initialize a %ux%u framebuffer
>> early.\n",
>> +               lfbp->width, lfbp->height);
>> +        return -EINVAL;
>> +    }
>> +
>> +    lfb.lfbp = *lfbp;
>> +
>> +    lfb.lbuf = xmalloc_bytes(lfb.lfbp.bytes_per_line);
>> +    lfb.text_buf = xzalloc_bytes(lfb.lfbp.text_columns *
>> lfb.lfbp.text_rows);
>> +    lfb.line_len = xzalloc_array(unsigned int, lfb.lfbp.text_columns);
>> +
>> +    if ( !lfb.lbuf || !lfb.text_buf || !lfb.line_len )
>> +        goto fail;
>> +
>> +    return 0;
>> +
>> +fail:
>> +    printk(XENLOG_ERR "Couldn't allocate enough memory to drive the
>> framebuffer\n");
>> +    lfb_free();
>> +
>> +    return -ENOMEM;
>> +}
>> +
>> +void lfb_free(void)
>> +{
>> +    xfree(lfb.lbuf);
>> +    xfree(lfb.text_buf);
>> +    xfree(lfb.line_len);
>> +}
>> diff --git a/xen/drivers/video/lfb.h b/xen/drivers/video/lfb.h
>> new file mode 100644
>> index 0000000..ac40a66
>> --- /dev/null
>> +++ b/xen/drivers/video/lfb.h
>> @@ -0,0 +1,46 @@
>> +/*
>> + * xen/drivers/video/lfb.h
>> + *
>> + * Cross-platform framebuffer library
>> + *
>> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> + * Copyright (c) 2013 Citrix Systems.
>> + *
>> + * 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 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.
>> + */
>> +
>> +#ifndef _XEN_LFB_H
>> +#define _XEN_LFB_H
>> +
>> +#include <xen/init.h>
>> +
>> +struct lfb_prop {
>> +    const struct font_desc *font;
>> +    unsigned char *lfb;
>> +    unsigned int pixel_on;
>> +    uint16_t width, height;
>> +    uint16_t bytes_per_line;
>> +    uint16_t bits_per_pixel;
>> +    void (*flush)(void);
>> +
>> +    unsigned int text_columns;
>> +    unsigned int text_rows;
>> +};
>> +
>> +void lfb_redraw_puts(const char *s);
>> +void lfb_scroll_puts(const char *s);
>> +void lfb_carriage_return(void);
>> +void lfb_free(void);
>> +
>> +/* initialize the framebuffer */
>> +int lfb_init(struct lfb_prop *lfbp);
>> +
>> +#endif
>> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
>> index aaf8b23..1144f76 100644
>> --- a/xen/drivers/video/vesa.c
>> +++ b/xen/drivers/video/vesa.c
>> @@ -13,20 +13,15 @@
>>  #include <asm/io.h>
>>  #include <asm/page.h>
>>  #include "font.h"
>> +#include "lfb.h"
>> 
>>  #define vlfb_info    vga_console_info.u.vesa_lfb
>> -#define text_columns (vlfb_info.width / font->width)
>> -#define text_rows    (vlfb_info.height / font->height)
>> 
>> -static void vesa_redraw_puts(const char *s);
>> -static void vesa_scroll_puts(const char *s);
>> +static void lfb_flush(void);
>> 
>> -static unsigned char *lfb, *lbuf, *text_buf;
>> -static unsigned int *__initdata line_len;
>> +static unsigned char *lfb;
>>  static const struct font_desc *font;
>>  static bool_t vga_compat;
>> -static unsigned int pixel_on;
>> -static unsigned int xpos, ypos;
>> 
>>  static unsigned int vram_total;
>>  integer_param("vesa-ram", vram_total);
>> @@ -87,29 +82,26 @@ void __init vesa_early_init(void)
>> 
>>  void __init vesa_init(void)
>>  {
>> -    if ( !font )
>> -        goto fail;
>> -
>> -    lbuf = xmalloc_bytes(vlfb_info.bytes_per_line);
>> -    if ( !lbuf )
>> -        goto fail;
>> +    struct lfb_prop lfbp;
>> 
>> -    text_buf = xzalloc_bytes(text_columns * text_rows);
>> -    if ( !text_buf )
>> -        goto fail;
>> +    if ( !font )
>> +        return;
>> 
>> -    line_len = xzalloc_array(unsigned int, text_columns);
>> -    if ( !line_len )
>> -        goto fail;
>> +    lfbp.font = font;
>> +    lfbp.bits_per_pixel = vlfb_info.bits_per_pixel;
>> +    lfbp.bytes_per_line = vlfb_info.bytes_per_line;
>> +    lfbp.width = vlfb_info.width;
>> +    lfbp.height = vlfb_info.height;
>> +    lfbp.flush = lfb_flush;
>> +    lfbp.text_columns = vlfb_info.width / font->width;
>> +    lfbp.text_rows = vlfb_info.height / font->height;
>> 
>> -    lfb = ioremap(vlfb_info.lfb_base, vram_remap);
>> +    lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap);
>>      if ( !lfb )
>> -        goto fail;
>> +        return;
>> 
>>      memset(lfb, 0, vram_remap);
>> 
>> -    video_puts = vesa_redraw_puts;
>> -
>>      printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
>>             "using %uk, total %uk\n",
>>             vlfb_info.lfb_base, lfb,
>> @@ -131,7 +123,7 @@ void __init vesa_init(void)
>>      {
>>          /* Light grey in truecolor. */
>>          unsigned int grey = 0xaaaaaaaa;
>> -        pixel_on =
>> +        fbp.pixel_on =
>>              ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
>>              ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
>>              ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_pos);
>> @@ -139,15 +131,12 @@ void __init vesa_init(void)
>>      else
>>      {
>>          /* White(ish) in default pseudocolor palette. */
>> -        pixel_on = 7;
>> +        fbp.pixel_on = 7;
>>      }
>> 
>> -    return;
>> -
>> - fail:
>> -    xfree(lbuf);
>> -    xfree(text_buf);
>> -    xfree(line_len);
>> +    if ( lfb_init(&lfbp) < 0 )
>> +        return;
>> +    video_puts = lfb_redraw_puts;
>>  }
>> 
>>  #include <asm/mtrr.h>
>> @@ -192,8 +181,8 @@ void __init vesa_endboot(bool_t keep)
>>  {
>>      if ( keep )
>>      {
>> -        xpos = 0;
>> -        video_puts = vesa_scroll_puts;
>> +        video_puts = lfb_scroll_puts;
>> +        lfb_carriage_return();
>>      }
>>      else
>>      {
>> @@ -202,124 +191,6 @@ void __init vesa_endboot(bool_t keep)
>>              memset(lfb + i * vlfb_info.bytes_per_line, 0,
>>                     vlfb_info.width * bpp);
>>          lfb_flush();
>> +        lfb_free();
>>      }
>> -
>> -    xfree(line_len);
>> -}
>> -
>> -/* Render one line of text to given linear framebuffer line. */
>> -static void vesa_show_line(
>> -    const unsigned char *text_line,
>> -    unsigned char *video_line,
>> -    unsigned int nr_chars,
>> -    unsigned int nr_cells)
>> -{
>> -    unsigned int i, j, b, bpp, pixel;
>> -
>> -    bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
>> -
>> -    for ( i = 0; i < font->height; i++ )
>> -    {
>> -        unsigned char *ptr = lbuf;
>> -
>> -        for ( j = 0; j < nr_chars; j++ )
>> -        {
>> -            const unsigned char *bits = font->data;
>> -            bits += ((text_line[j] * font->height + i) *
>> -                     ((font->width + 7) >> 3));
>> -            for ( b = font->width; b--; )
>> -            {
>> -                pixel = (*bits & (1u<<b)) ? pixel_on : 0;
>> -                memcpy(ptr, &pixel, bpp);
>> -                ptr += bpp;
>> -            }
>> -        }
>> -
>> -        memset(ptr, 0, (vlfb_info.width - nr_chars * font->width) * bpp);
>> -        memcpy(video_line, lbuf, nr_cells * font->width * bpp);
>> -        video_line += vlfb_info.bytes_per_line;
>> -    }
>> -}
>> -
>> -/* Fast mode which redraws all modified parts of a 2D text buffer. */
>> -static void __init vesa_redraw_puts(const char *s)
>> -{
>> -    unsigned int i, min_redraw_y = ypos;
>> -    char c;
>> -
>> -    /* Paste characters into text buffer. */
>> -    while ( (c = *s++) != '\0' )
>> -    {
>> -        if ( (c == '\n') || (xpos >= text_columns) )
>> -        {
>> -            if ( ++ypos >= text_rows )
>> -            {
>> -                min_redraw_y = 0;
>> -                ypos = text_rows - 1;
>> -                memmove(text_buf, text_buf + text_columns,
>> -                        ypos * text_columns);
>> -                memset(text_buf + ypos * text_columns, 0, xpos);
>> -            }
>> -            xpos = 0;
>> -        }
>> -
>> -        if ( c != '\n' )
>> -            text_buf[xpos++ + ypos * text_columns] = c;
>> -    }
>> -
>> -    /* Render modified section of text buffer to VESA linear framebuffer. */
>> -    for ( i = min_redraw_y; i <= ypos; i++ )
>> -    {
>> -        const unsigned char *line = text_buf + i * text_columns;
>> -        unsigned int width;
>> -
>> -        for ( width = text_columns; width; --width )
>> -            if ( line[width - 1] )
>> -                 break;
>> -        vesa_show_line(line,
>> -                       lfb + i * font->height * vlfb_info.bytes_per_line,
>> -                       width, max(line_len[i], width));
>> -        line_len[i] = width;
>> -    }
>> -
>> -    lfb_flush();
>> -}
>> -
>> -/* Slower line-based scroll mode which interacts better with dom0. */
>> -static void vesa_scroll_puts(const char *s)
>> -{
>> -    unsigned int i;
>> -    char c;
>> -
>> -    while ( (c = *s++) != '\0' )
>> -    {
>> -        if ( (c == '\n') || (xpos >= text_columns) )
>> -        {
>> -            unsigned int bytes = (vlfb_info.width *
>> -                                  ((vlfb_info.bits_per_pixel + 7) >> 3));
>> -            unsigned char *src = lfb + font->height *
>> vlfb_info.bytes_per_line;
>> -            unsigned char *dst = lfb;
>> -
>> -            /* New line: scroll all previous rows up one line. */
>> -            for ( i = font->height; i < vlfb_info.height; i++ )
>> -            {
>> -                memcpy(dst, src, bytes);
>> -                src += vlfb_info.bytes_per_line;
>> -                dst += vlfb_info.bytes_per_line;
>> -            }
>> -
>> -            /* Render new line. */
>> -            vesa_show_line(
>> -                text_buf,
>> -                lfb + (text_rows-1) * font->height *
>> vlfb_info.bytes_per_line,
>> -                xpos, text_columns);
>> -
>> -            xpos = 0;
>> -        }
>> -
>> -        if ( c != '\n' )
>> -            text_buf[xpos++] = c;
>> -    }
>> -
>> -    lfb_flush();
>>  }
>> --
>> 1.7.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 Feb 15 13:16:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:16: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 1U6L92-0002h4-Ml; Fri, 15 Feb 2013 13:16: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 1U6L91-0002gv-Iy
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:16:04 +0000
Received: from [85.158.139.211:13224] by server-13.bemta-5.messagelabs.com id
	12/74-06769-2153E115; Fri, 15 Feb 2013 13:16:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360934160!22644179!1
X-Originating-IP: [74.125.82.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28343 invoked from network); 15 Feb 2013 13:16:00 -0000
Received: from mail-we0-f170.google.com (HELO mail-we0-f170.google.com)
	(74.125.82.170)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:16:00 -0000
Received: by mail-we0-f170.google.com with SMTP id z53so3005769wey.1
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Feb 2013 05:16:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=7wLAV9vqkhYJ8XJIs/ECAAQwDSZM2psgoYL19YCnB9c=;
	b=fsrECGXs/aw3bFJNOye5HUtFItXoIrYZAywpGSBlJ/jMacrku4oOmILttl8K6D55er
	7vX15ipoMizDST1t7zevBAxEJatxb3dFgfRCZkFPUGHziOgfoyDCXXOBK6Z+UUTNUhLV
	iLSbNFMWf1cWYCMuWr3/mX/AQ/vDxDDx+Ta3G1asniKrzLH0yrLc5McKWvnr0SRXFVeO
	e1FiMYZNA1kHj48/sRzJKQseRj1k89WEjdZumtWIoDr6z8+xetV9Aauae6WeBGOVDPSE
	t9pjM4oocUV/DHPIJoTK1vF2YaxCcq2pnTxacANeVEjrAbAjjYJEI5X2itMo9B3ShIKQ
	trXQ==
X-Received: by 10.194.174.234 with SMTP id bv10mr4082236wjc.47.1360934159963; 
	Fri, 15 Feb 2013 05:15:59 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id j4sm2945514wiz.10.2013.02.15.05.15.57
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 05:15:59 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 13:15:55 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <CD43E58B.5B119%keir@xen.org>
Thread-Topic: [PATCH v7 1/5] xen: introduce a generic framebuffer driver
Thread-Index: Ac4LfpX1X0k7sZNJM0mUBbPddt3lKg==
In-Reply-To: <1360932105.31407.25.camel@zakaz.uk.xensource.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] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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

Yep

Acked-by: Keir Fraser <keir@xen.org>


On 15/02/2013 12:41, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> Keir, are you OK with this change?
> 
> On Thu, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
>> Abstract away from vesa.c the funcions to handle a linear framebuffer
>> and print characters to it.
>> Make use of the new functions in vesa.c.
>> 
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Acked-by: Jan Beulich <JBeulich@suse.com>
>> 
>> Changes in v6:
>> - remove useless initializations to NULL in lfb_init;
>> - more compact checks in lfb_init.
>> 
>> Changes in v5:
>> - remove lfb_alloc and the now unused __initdata variables;
>> - fix indentation and long lines.
>> 
>> Changes in v4:
>> - squash the vesa.c changes into this patch;
>> - rename fb* to lfb*;
>> - pass a pointer to fb_init;
>> - use %u for screen dimensions;
>> - specify loglevel in printk;
>> - call fb_free on error in fb_alloc;
>> - no __init on declarations;
>> - do not break messages to fit 80 columns.
>> ---
>>  xen/drivers/video/Makefile |    1 +
>>  xen/drivers/video/lfb.c    |  183
>> ++++++++++++++++++++++++++++++++++++++++++++
>>  xen/drivers/video/lfb.h    |   46 +++++++++++
>>  xen/drivers/video/vesa.c   |  177 ++++++------------------------------------
>>  4 files changed, 254 insertions(+), 153 deletions(-)
>>  create mode 100644 xen/drivers/video/lfb.c
>>  create mode 100644 xen/drivers/video/lfb.h
>> 
>> diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
>> index 2993c39..77f9d5d 100644
>> --- a/xen/drivers/video/Makefile
>> +++ b/xen/drivers/video/Makefile
>> @@ -2,4 +2,5 @@ obj-$(HAS_VGA) := vga.o
>>  obj-$(HAS_VIDEO) += font_8x14.o
>>  obj-$(HAS_VIDEO) += font_8x16.o
>>  obj-$(HAS_VIDEO) += font_8x8.o
>> +obj-$(HAS_VIDEO) += lfb.o
>>  obj-$(HAS_VGA) += vesa.o
>> diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
>> new file mode 100644
>> index 0000000..cc7f7ac
>> --- /dev/null
>> +++ b/xen/drivers/video/lfb.c
>> @@ -0,0 +1,183 @@
>> +/***************************************************************************
>> ***
>> + * lfb.c
>> + *
>> + * linear frame buffer handling.
>> + */
>> +
>> +#include <xen/config.h>
>> +#include <xen/kernel.h>
>> +#include <xen/lib.h>
>> +#include <xen/errno.h>
>> +#include "lfb.h"
>> +#include "font.h"
>> +
>> +#define MAX_XRES 1900
>> +#define MAX_YRES 1200
>> +#define MAX_BPP 4
>> +#define MAX_FONT_W 8
>> +#define MAX_FONT_H 16
>> +
>> +struct lfb_status {
>> +    struct lfb_prop lfbp;
>> +
>> +    unsigned char *lbuf, *text_buf;
>> +    unsigned int *line_len;
>> +    unsigned int xpos, ypos;
>> +};
>> +static struct lfb_status lfb;
>> +
>> +static void lfb_show_line(
>> +    const unsigned char *text_line,
>> +    unsigned char *video_line,
>> +    unsigned int nr_chars,
>> +    unsigned int nr_cells)
>> +{
>> +    unsigned int i, j, b, bpp, pixel;
>> +
>> +    bpp = (lfb.lfbp.bits_per_pixel + 7) >> 3;
>> +
>> +    for ( i = 0; i < lfb.lfbp.font->height; i++ )
>> +    {
>> +        unsigned char *ptr = lfb.lbuf;
>> +
>> +        for ( j = 0; j < nr_chars; j++ )
>> +        {
>> +            const unsigned char *bits = lfb.lfbp.font->data;
>> +            bits += ((text_line[j] * lfb.lfbp.font->height + i) *
>> +                     ((lfb.lfbp.font->width + 7) >> 3));
>> +            for ( b = lfb.lfbp.font->width; b--; )
>> +            {
>> +                pixel = (*bits & (1u<<b)) ? lfb.lfbp.pixel_on : 0;
>> +                memcpy(ptr, &pixel, bpp);
>> +                ptr += bpp;
>> +            }
>> +        }
>> +
>> +        memset(ptr, 0, (lfb.lfbp.width - nr_chars * lfb.lfbp.font->width) *
>> bpp);
>> +        memcpy(video_line, lfb.lbuf, nr_cells * lfb.lfbp.font->width * bpp);
>> +        video_line += lfb.lfbp.bytes_per_line;
>> +    }
>> +}
>> +
>> +/* Fast mode which redraws all modified parts of a 2D text buffer. */
>> +void lfb_redraw_puts(const char *s)
>> +{
>> +    unsigned int i, min_redraw_y = lfb.ypos;
>> +    char c;
>> +
>> +    /* Paste characters into text buffer. */
>> +    while ( (c = *s++) != '\0' )
>> +    {
>> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
>> +        {
>> +            if ( ++lfb.ypos >= lfb.lfbp.text_rows )
>> +            {
>> +                min_redraw_y = 0;
>> +                lfb.ypos = lfb.lfbp.text_rows - 1;
>> +                memmove(lfb.text_buf, lfb.text_buf + lfb.lfbp.text_columns,
>> +                        lfb.ypos * lfb.lfbp.text_columns);
>> +                memset(lfb.text_buf + lfb.ypos * lfb.lfbp.text_columns, 0,
>> lfb.xpos);
>> +            }
>> +            lfb.xpos = 0;
>> +        }
>> +
>> +        if ( c != '\n' )
>> +            lfb.text_buf[lfb.xpos++ + lfb.ypos * lfb.lfbp.text_columns] = c;
>> +    }
>> +
>> +    /* Render modified section of text buffer to VESA linear framebuffer. */
>> +    for ( i = min_redraw_y; i <= lfb.ypos; i++ )
>> +    {
>> +        const unsigned char *line = lfb.text_buf + i *
>> lfb.lfbp.text_columns;
>> +        unsigned int width;
>> +
>> +        for ( width = lfb.lfbp.text_columns; width; --width )
>> +            if ( line[width - 1] )
>> +                 break;
>> +        lfb_show_line(line,
>> +                       lfb.lfbp.lfb + i * lfb.lfbp.font->height *
>> lfb.lfbp.bytes_per_line,
>> +                       width, max(lfb.line_len[i], width));
>> +        lfb.line_len[i] = width;
>> +    }
>> +
>> +    lfb.lfbp.flush();
>> +}
>> +
>> +/* Slower line-based scroll mode which interacts better with dom0. */
>> +void lfb_scroll_puts(const char *s)
>> +{
>> +    unsigned int i;
>> +    char c;
>> +
>> +    while ( (c = *s++) != '\0' )
>> +    {
>> +        if ( (c == '\n') || (lfb.xpos >= lfb.lfbp.text_columns) )
>> +        {
>> +            unsigned int bytes = (lfb.lfbp.width *
>> +                                  ((lfb.lfbp.bits_per_pixel + 7) >> 3));
>> +            unsigned char *src = lfb.lfbp.lfb + lfb.lfbp.font->height *
>> lfb.lfbp.bytes_per_line;
>> +            unsigned char *dst = lfb.lfbp.lfb;
>> +
>> +            /* New line: scroll all previous rows up one line. */
>> +            for ( i = lfb.lfbp.font->height; i < lfb.lfbp.height; i++ )
>> +            {
>> +                memcpy(dst, src, bytes);
>> +                src += lfb.lfbp.bytes_per_line;
>> +                dst += lfb.lfbp.bytes_per_line;
>> +            }
>> +
>> +            /* Render new line. */
>> +            lfb_show_line(
>> +                lfb.text_buf,
>> +                lfb.lfbp.lfb + (lfb.lfbp.text_rows-1) *
>> lfb.lfbp.font->height *
>> +                lfb.lfbp.bytes_per_line,
>> +                lfb.xpos, lfb.lfbp.text_columns);
>> +
>> +            lfb.xpos = 0;
>> +        }
>> +
>> +        if ( c != '\n' )
>> +            lfb.text_buf[lfb.xpos++] = c;
>> +    }
>> +
>> +    lfb.lfbp.flush();
>> +}
>> +
>> +void lfb_carriage_return(void)
>> +{
>> +    lfb.xpos = 0;
>> +}
>> +
>> +int __init lfb_init(struct lfb_prop *lfbp)
>> +{
>> +    if ( lfbp->width > MAX_XRES || lfbp->height > MAX_YRES )
>> +    {
>> +        printk(XENLOG_WARNING "Couldn't initialize a %ux%u framebuffer
>> early.\n",
>> +               lfbp->width, lfbp->height);
>> +        return -EINVAL;
>> +    }
>> +
>> +    lfb.lfbp = *lfbp;
>> +
>> +    lfb.lbuf = xmalloc_bytes(lfb.lfbp.bytes_per_line);
>> +    lfb.text_buf = xzalloc_bytes(lfb.lfbp.text_columns *
>> lfb.lfbp.text_rows);
>> +    lfb.line_len = xzalloc_array(unsigned int, lfb.lfbp.text_columns);
>> +
>> +    if ( !lfb.lbuf || !lfb.text_buf || !lfb.line_len )
>> +        goto fail;
>> +
>> +    return 0;
>> +
>> +fail:
>> +    printk(XENLOG_ERR "Couldn't allocate enough memory to drive the
>> framebuffer\n");
>> +    lfb_free();
>> +
>> +    return -ENOMEM;
>> +}
>> +
>> +void lfb_free(void)
>> +{
>> +    xfree(lfb.lbuf);
>> +    xfree(lfb.text_buf);
>> +    xfree(lfb.line_len);
>> +}
>> diff --git a/xen/drivers/video/lfb.h b/xen/drivers/video/lfb.h
>> new file mode 100644
>> index 0000000..ac40a66
>> --- /dev/null
>> +++ b/xen/drivers/video/lfb.h
>> @@ -0,0 +1,46 @@
>> +/*
>> + * xen/drivers/video/lfb.h
>> + *
>> + * Cross-platform framebuffer library
>> + *
>> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> + * Copyright (c) 2013 Citrix Systems.
>> + *
>> + * 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 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.
>> + */
>> +
>> +#ifndef _XEN_LFB_H
>> +#define _XEN_LFB_H
>> +
>> +#include <xen/init.h>
>> +
>> +struct lfb_prop {
>> +    const struct font_desc *font;
>> +    unsigned char *lfb;
>> +    unsigned int pixel_on;
>> +    uint16_t width, height;
>> +    uint16_t bytes_per_line;
>> +    uint16_t bits_per_pixel;
>> +    void (*flush)(void);
>> +
>> +    unsigned int text_columns;
>> +    unsigned int text_rows;
>> +};
>> +
>> +void lfb_redraw_puts(const char *s);
>> +void lfb_scroll_puts(const char *s);
>> +void lfb_carriage_return(void);
>> +void lfb_free(void);
>> +
>> +/* initialize the framebuffer */
>> +int lfb_init(struct lfb_prop *lfbp);
>> +
>> +#endif
>> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
>> index aaf8b23..1144f76 100644
>> --- a/xen/drivers/video/vesa.c
>> +++ b/xen/drivers/video/vesa.c
>> @@ -13,20 +13,15 @@
>>  #include <asm/io.h>
>>  #include <asm/page.h>
>>  #include "font.h"
>> +#include "lfb.h"
>> 
>>  #define vlfb_info    vga_console_info.u.vesa_lfb
>> -#define text_columns (vlfb_info.width / font->width)
>> -#define text_rows    (vlfb_info.height / font->height)
>> 
>> -static void vesa_redraw_puts(const char *s);
>> -static void vesa_scroll_puts(const char *s);
>> +static void lfb_flush(void);
>> 
>> -static unsigned char *lfb, *lbuf, *text_buf;
>> -static unsigned int *__initdata line_len;
>> +static unsigned char *lfb;
>>  static const struct font_desc *font;
>>  static bool_t vga_compat;
>> -static unsigned int pixel_on;
>> -static unsigned int xpos, ypos;
>> 
>>  static unsigned int vram_total;
>>  integer_param("vesa-ram", vram_total);
>> @@ -87,29 +82,26 @@ void __init vesa_early_init(void)
>> 
>>  void __init vesa_init(void)
>>  {
>> -    if ( !font )
>> -        goto fail;
>> -
>> -    lbuf = xmalloc_bytes(vlfb_info.bytes_per_line);
>> -    if ( !lbuf )
>> -        goto fail;
>> +    struct lfb_prop lfbp;
>> 
>> -    text_buf = xzalloc_bytes(text_columns * text_rows);
>> -    if ( !text_buf )
>> -        goto fail;
>> +    if ( !font )
>> +        return;
>> 
>> -    line_len = xzalloc_array(unsigned int, text_columns);
>> -    if ( !line_len )
>> -        goto fail;
>> +    lfbp.font = font;
>> +    lfbp.bits_per_pixel = vlfb_info.bits_per_pixel;
>> +    lfbp.bytes_per_line = vlfb_info.bytes_per_line;
>> +    lfbp.width = vlfb_info.width;
>> +    lfbp.height = vlfb_info.height;
>> +    lfbp.flush = lfb_flush;
>> +    lfbp.text_columns = vlfb_info.width / font->width;
>> +    lfbp.text_rows = vlfb_info.height / font->height;
>> 
>> -    lfb = ioremap(vlfb_info.lfb_base, vram_remap);
>> +    lfbp.lfb = lfb = ioremap(vlfb_info.lfb_base, vram_remap);
>>      if ( !lfb )
>> -        goto fail;
>> +        return;
>> 
>>      memset(lfb, 0, vram_remap);
>> 
>> -    video_puts = vesa_redraw_puts;
>> -
>>      printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
>>             "using %uk, total %uk\n",
>>             vlfb_info.lfb_base, lfb,
>> @@ -131,7 +123,7 @@ void __init vesa_init(void)
>>      {
>>          /* Light grey in truecolor. */
>>          unsigned int grey = 0xaaaaaaaa;
>> -        pixel_on =
>> +        fbp.pixel_on =
>>              ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
>>              ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
>>              ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_pos);
>> @@ -139,15 +131,12 @@ void __init vesa_init(void)
>>      else
>>      {
>>          /* White(ish) in default pseudocolor palette. */
>> -        pixel_on = 7;
>> +        fbp.pixel_on = 7;
>>      }
>> 
>> -    return;
>> -
>> - fail:
>> -    xfree(lbuf);
>> -    xfree(text_buf);
>> -    xfree(line_len);
>> +    if ( lfb_init(&lfbp) < 0 )
>> +        return;
>> +    video_puts = lfb_redraw_puts;
>>  }
>> 
>>  #include <asm/mtrr.h>
>> @@ -192,8 +181,8 @@ void __init vesa_endboot(bool_t keep)
>>  {
>>      if ( keep )
>>      {
>> -        xpos = 0;
>> -        video_puts = vesa_scroll_puts;
>> +        video_puts = lfb_scroll_puts;
>> +        lfb_carriage_return();
>>      }
>>      else
>>      {
>> @@ -202,124 +191,6 @@ void __init vesa_endboot(bool_t keep)
>>              memset(lfb + i * vlfb_info.bytes_per_line, 0,
>>                     vlfb_info.width * bpp);
>>          lfb_flush();
>> +        lfb_free();
>>      }
>> -
>> -    xfree(line_len);
>> -}
>> -
>> -/* Render one line of text to given linear framebuffer line. */
>> -static void vesa_show_line(
>> -    const unsigned char *text_line,
>> -    unsigned char *video_line,
>> -    unsigned int nr_chars,
>> -    unsigned int nr_cells)
>> -{
>> -    unsigned int i, j, b, bpp, pixel;
>> -
>> -    bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
>> -
>> -    for ( i = 0; i < font->height; i++ )
>> -    {
>> -        unsigned char *ptr = lbuf;
>> -
>> -        for ( j = 0; j < nr_chars; j++ )
>> -        {
>> -            const unsigned char *bits = font->data;
>> -            bits += ((text_line[j] * font->height + i) *
>> -                     ((font->width + 7) >> 3));
>> -            for ( b = font->width; b--; )
>> -            {
>> -                pixel = (*bits & (1u<<b)) ? pixel_on : 0;
>> -                memcpy(ptr, &pixel, bpp);
>> -                ptr += bpp;
>> -            }
>> -        }
>> -
>> -        memset(ptr, 0, (vlfb_info.width - nr_chars * font->width) * bpp);
>> -        memcpy(video_line, lbuf, nr_cells * font->width * bpp);
>> -        video_line += vlfb_info.bytes_per_line;
>> -    }
>> -}
>> -
>> -/* Fast mode which redraws all modified parts of a 2D text buffer. */
>> -static void __init vesa_redraw_puts(const char *s)
>> -{
>> -    unsigned int i, min_redraw_y = ypos;
>> -    char c;
>> -
>> -    /* Paste characters into text buffer. */
>> -    while ( (c = *s++) != '\0' )
>> -    {
>> -        if ( (c == '\n') || (xpos >= text_columns) )
>> -        {
>> -            if ( ++ypos >= text_rows )
>> -            {
>> -                min_redraw_y = 0;
>> -                ypos = text_rows - 1;
>> -                memmove(text_buf, text_buf + text_columns,
>> -                        ypos * text_columns);
>> -                memset(text_buf + ypos * text_columns, 0, xpos);
>> -            }
>> -            xpos = 0;
>> -        }
>> -
>> -        if ( c != '\n' )
>> -            text_buf[xpos++ + ypos * text_columns] = c;
>> -    }
>> -
>> -    /* Render modified section of text buffer to VESA linear framebuffer. */
>> -    for ( i = min_redraw_y; i <= ypos; i++ )
>> -    {
>> -        const unsigned char *line = text_buf + i * text_columns;
>> -        unsigned int width;
>> -
>> -        for ( width = text_columns; width; --width )
>> -            if ( line[width - 1] )
>> -                 break;
>> -        vesa_show_line(line,
>> -                       lfb + i * font->height * vlfb_info.bytes_per_line,
>> -                       width, max(line_len[i], width));
>> -        line_len[i] = width;
>> -    }
>> -
>> -    lfb_flush();
>> -}
>> -
>> -/* Slower line-based scroll mode which interacts better with dom0. */
>> -static void vesa_scroll_puts(const char *s)
>> -{
>> -    unsigned int i;
>> -    char c;
>> -
>> -    while ( (c = *s++) != '\0' )
>> -    {
>> -        if ( (c == '\n') || (xpos >= text_columns) )
>> -        {
>> -            unsigned int bytes = (vlfb_info.width *
>> -                                  ((vlfb_info.bits_per_pixel + 7) >> 3));
>> -            unsigned char *src = lfb + font->height *
>> vlfb_info.bytes_per_line;
>> -            unsigned char *dst = lfb;
>> -
>> -            /* New line: scroll all previous rows up one line. */
>> -            for ( i = font->height; i < vlfb_info.height; i++ )
>> -            {
>> -                memcpy(dst, src, bytes);
>> -                src += vlfb_info.bytes_per_line;
>> -                dst += vlfb_info.bytes_per_line;
>> -            }
>> -
>> -            /* Render new line. */
>> -            vesa_show_line(
>> -                text_buf,
>> -                lfb + (text_rows-1) * font->height *
>> vlfb_info.bytes_per_line,
>> -                xpos, text_columns);
>> -
>> -            xpos = 0;
>> -        }
>> -
>> -        if ( c != '\n' )
>> -            text_buf[xpos++] = c;
>> -    }
>> -
>> -    lfb_flush();
>>  }
>> --
>> 1.7.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 Feb 15 13:19:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LBl-0002tv-FL; Fri, 15 Feb 2013 13:18:53 +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 1U6LBk-0002to-0a
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:18:52 +0000
Received: from [85.158.138.51:54327] by server-14.bemta-3.messagelabs.com id
	8B/65-23533-BB53E115; Fri, 15 Feb 2013 13:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360934330!19783085!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17266 invoked from network); 15 Feb 2013 13:18:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1515147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:18: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.297.1;
	Fri, 15 Feb 2013 13:18:50 +0000
Message-ID: <1360934328.31407.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:18:48 +0000
In-Reply-To: <alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:43 +0000, Stefano Stabellini wrote:
> On Wed, 30 Jan 2013, Ian Campbell wrote:
> > If a node does not have #*-cells then the parent's value should be
> > used. Currently we were asssuming zero which is useless.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain_build.c   |    6 ++++--
> >  xen/common/device_tree.c      |   12 ++++++++----
> >  xen/include/xen/device_tree.h |    3 ++-
> >  3 files changed, 14 insertions(+), 7 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 7403f1a..bfbe7c7 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -198,8 +198,10 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
> >          while ( last_depth-- >= depth )
> >              fdt_end_node(kinfo->fdt);
> >  
> > -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> > -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> > +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> > +                                    depth > 0 ? address_cells[depth-1] : 0);
> > +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> > +                                    depth > 0 ? size_cells[depth-1] : 0);
> >  
> >          fdt_begin_node(kinfo->fdt, name);
> 
> The depth is always increasing by steps of 1 in this loop, right?
> Because retrieving address-cells and size-cells should be recursive: if
> n-1 doesn't have them, let's look at n-2, etc. Of course if we start from
> depth = 0 and go from there without missing any levels the results will
> be the same.

That was what I thought too. Perhaps it is too subtle?

I bet my "xen: strip xen,multiboot-module nodes from dom0 device tree"
patch changes this invariant. Better to make it explicitly walk
backwards now I think. (or maybe set things for level in
last_depth..depth). I'll change things along these lines.

> I think I convinced myself that this is correct.
> 
> 
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > index 260c2d4..f10ba1b 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
> >      set_val(cell, size_cells, size);
> >  }
> >  
> > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > +                        u32 dflt)
> >  {
> >      const struct fdt_property *prop;
> >  
> >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> >      if ( !prop || prop->len < sizeof(u32) )
> > -        return 0; /* default to 0 */
> > +        return dflt;
> >  
> >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> >  }
> 
> where did the vowels go? :)

Not sure. Unlike 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 Feb 15 13:19:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LBl-0002tv-FL; Fri, 15 Feb 2013 13:18:53 +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 1U6LBk-0002to-0a
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:18:52 +0000
Received: from [85.158.138.51:54327] by server-14.bemta-3.messagelabs.com id
	8B/65-23533-BB53E115; Fri, 15 Feb 2013 13:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1360934330!19783085!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17266 invoked from network); 15 Feb 2013 13:18:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:18:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1515147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:18: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.297.1;
	Fri, 15 Feb 2013 13:18:50 +0000
Message-ID: <1360934328.31407.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:18:48 +0000
In-Reply-To: <alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:43 +0000, Stefano Stabellini wrote:
> On Wed, 30 Jan 2013, Ian Campbell wrote:
> > If a node does not have #*-cells then the parent's value should be
> > used. Currently we were asssuming zero which is useless.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain_build.c   |    6 ++++--
> >  xen/common/device_tree.c      |   12 ++++++++----
> >  xen/include/xen/device_tree.h |    3 ++-
> >  3 files changed, 14 insertions(+), 7 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 7403f1a..bfbe7c7 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -198,8 +198,10 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
> >          while ( last_depth-- >= depth )
> >              fdt_end_node(kinfo->fdt);
> >  
> > -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> > -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> > +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> > +                                    depth > 0 ? address_cells[depth-1] : 0);
> > +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> > +                                    depth > 0 ? size_cells[depth-1] : 0);
> >  
> >          fdt_begin_node(kinfo->fdt, name);
> 
> The depth is always increasing by steps of 1 in this loop, right?
> Because retrieving address-cells and size-cells should be recursive: if
> n-1 doesn't have them, let's look at n-2, etc. Of course if we start from
> depth = 0 and go from there without missing any levels the results will
> be the same.

That was what I thought too. Perhaps it is too subtle?

I bet my "xen: strip xen,multiboot-module nodes from dom0 device tree"
patch changes this invariant. Better to make it explicitly walk
backwards now I think. (or maybe set things for level in
last_depth..depth). I'll change things along these lines.

> I think I convinced myself that this is correct.
> 
> 
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > index 260c2d4..f10ba1b 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
> >      set_val(cell, size_cells, size);
> >  }
> >  
> > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > +                        u32 dflt)
> >  {
> >      const struct fdt_property *prop;
> >  
> >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> >      if ( !prop || prop->len < sizeof(u32) )
> > -        return 0; /* default to 0 */
> > +        return dflt;
> >  
> >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> >  }
> 
> where did the vowels go? :)

Not sure. Unlike 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 Feb 15 13:24:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LGw-0003Ab-84; Fri, 15 Feb 2013 13:24:14 +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 1U6LGv-0003AW-0F
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:24:13 +0000
Received: from [85.158.139.211:54467] by server-9.bemta-5.messagelabs.com id
	62/A0-24440-CF63E115; Fri, 15 Feb 2013 13:24:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360934651!22615599!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25054 invoked from network); 15 Feb 2013 13:24:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:24:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1515375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:24: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.297.1;
	Fri, 15 Feb 2013 13:24:11 +0000
Message-ID: <1360934649.31407.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 13:24:09 +0000
In-Reply-To: <511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 13:01 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 13:08, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 14 Feb 2013, Ian Campbell wrote:
> >> --- a/arch/arm/include/asm/xen/interface.h
> >> +++ b/arch/arm/include/asm/xen/interface.h
> >> @@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
> >>  
> >> +/*
> >> + * On ARM this is not part of the hypervisor ABI but we provide it
> >> + * internally for the benefit of common code.
> >> + */
> >> +struct start_info {
> >> +        uint32_t flags;             /* SIF_xxx flags.                         */
> >> +        uint32_t store_evtchn;      /* Event channel for store communication. */
> >> +        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> >> +        union {
> >> +                struct {
> >> +                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> >> +                        uint32_t  evtchn;   /* Event channel for console page.        */
> >> +                } domU;
> >> +                struct {
> >> +                        uint32_t info_off;  /* Offset of console_info struct.         */
> >> +                        uint32_t info_size; /* Size of console_info struct from start.*/
> >> +                } dom0;
> >> +        } console;
> >> +	/* UNUSED ON ARM */
> >> +        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> >> +};
> >> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> >> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> 
> With this it's even less clear to me why you want all of it removed
> from a architecture independent header.

struct start_info is a hypervisor on x86, on ARM it is not, it's use is
a purely internal convenience for the guest, to allow it to share common
code between x86 and ARM.

Maybe moving things on the guest side is overkill, I did it for symmetry
with the Xen side patches.

All I actually care about is the removal of struct start_info from the
canonical copy of the hypervisor ABI (that is xen/include/public) for
ARM.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:24:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LGw-0003Ab-84; Fri, 15 Feb 2013 13:24:14 +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 1U6LGv-0003AW-0F
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:24:13 +0000
Received: from [85.158.139.211:54467] by server-9.bemta-5.messagelabs.com id
	62/A0-24440-CF63E115; Fri, 15 Feb 2013 13:24:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360934651!22615599!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25054 invoked from network); 15 Feb 2013 13:24:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:24:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1515375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:24: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.297.1;
	Fri, 15 Feb 2013 13:24:11 +0000
Message-ID: <1360934649.31407.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 13:24:09 +0000
In-Reply-To: <511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 13:01 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 13:08, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 14 Feb 2013, Ian Campbell wrote:
> >> --- a/arch/arm/include/asm/xen/interface.h
> >> +++ b/arch/arm/include/asm/xen/interface.h
> >> @@ -51,6 +51,30 @@ DEFINE_GUEST_HANDLE(uint32_t);
> >>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> >>  DEFINE_GUEST_HANDLE(xen_ulong_t);
> >>  
> >> +/*
> >> + * On ARM this is not part of the hypervisor ABI but we provide it
> >> + * internally for the benefit of common code.
> >> + */
> >> +struct start_info {
> >> +        uint32_t flags;             /* SIF_xxx flags.                         */
> >> +        uint32_t store_evtchn;      /* Event channel for store communication. */
> >> +        xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
> >> +        union {
> >> +                struct {
> >> +                        xen_pfn_t mfn;      /* MACHINE page number of console page.   */
> >> +                        uint32_t  evtchn;   /* Event channel for console page.        */
> >> +                } domU;
> >> +                struct {
> >> +                        uint32_t info_off;  /* Offset of console_info struct.         */
> >> +                        uint32_t info_size; /* Size of console_info struct from start.*/
> >> +                } dom0;
> >> +        } console;
> >> +	/* UNUSED ON ARM */
> >> +        unsigned long nr_pages;     /* Total pages allocated to this domain.  */
> >> +};
> >> +#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> >> +#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> 
> With this it's even less clear to me why you want all of it removed
> from a architecture independent header.

struct start_info is a hypervisor on x86, on ARM it is not, it's use is
a purely internal convenience for the guest, to allow it to share common
code between x86 and ARM.

Maybe moving things on the guest side is overkill, I did it for symmetry
with the Xen side patches.

All I actually care about is the removal of struct start_info from the
canonical copy of the hypervisor ABI (that is xen/include/public) for
ARM.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:30:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:30: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 1U6LMz-0003KD-2p; Fri, 15 Feb 2013 13:30: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 1U6LMx-0003K6-EY
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:30:27 +0000
Received: from [85.158.143.99:42077] by server-1.bemta-4.messagelabs.com id
	AA/C4-08839-2783E115; Fri, 15 Feb 2013 13:30:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360935024!27710619!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6048 invoked from network); 15 Feb 2013 13:30:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1515753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:30: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.297.1;
	Fri, 15 Feb 2013 13:30:24 +0000
Message-ID: <1360935023.31407.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 13:30:23 +0000
In-Reply-To: <511D0ED202000078000BE5BF@nat28.tlf.novell.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
	<1360853210.20449.414.camel@zakaz.uk.xensource.com>
	<511D0ED202000078000BE5BF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 15:20 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 15:46, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2013-02-14 at 14:43 +0000, Jan Beulich wrote:
> >> >>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > Most of this struct is PV MMU specific and it is not used on ARM at all.
> >> 
> >> I'm not convinced this is the right move.
> >> 
> >> > --- a/xen/include/public/xen.h
> >> > +++ b/xen/include/public/xen.h
> >> > @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
> >> >   *     extended by an extra 4MB to ensure this.
> >> >   */
> >> >  
> >> > -#define MAX_GUEST_CMDLINE 1024
> >> > -struct start_info {
> >> > -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    
> > */
> >> > -    char magic[32];             /* "xen-<version>-<platform>".            */
> >> > -    unsigned long nr_pages;     /* Total pages allocated to this domain.  
> > */
> >> > -    unsigned long shared_info;  /* MACHINE address of shared info struct. 
> > */
> >> > -    uint32_t flags;             /* SIF_xxx flags.                         
> > */
> >> > -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    
> > */
> >> > -    uint32_t store_evtchn;      /* Event channel for store communication. 
> > */
> >> > -    union {
> >> > -        struct {
> >> > -            xen_pfn_t mfn;      /* MACHINE page number of console page.   
> > */
> >> > -            uint32_t  evtchn;   /* Event channel for console page.        
> > */
> >> > -        } domU;
> >> > -        struct {
> >> > -            uint32_t info_off;  /* Offset of console_info struct.         
> > */
> >> > -            uint32_t info_size; /* Size of console_info struct from 
> > start.*/
> >> > -        } dom0;
> >> > -    } console;
> >> 
> >> What is PV MMU related up to here?
> > 
> > Hrm, perhaps categorising this as PV MMU was a mistake on my part.
> > 
> > These are all unused on ARM in terms of the hypervisor ABI since it uses
> > HVM like mechanisms for those which are appropriate and doesn't use a
> > bunch of the others at all.
> 
> But nothing here makes this structure x86 specific, so I'd really like
> to keep it that way. If ARM doesn't use the structure at all, then
> I don't see the point in removing it from the common headers. If
> part of it (the flags come to mind) are being used by ARM, let's
> find a reasonable abstraction so that ARM doesn't need to carry
> useless baggage (e.g. a XEN_ARCH_HVM_ONLY #define).

Even the flags are unused on ARM (as part of the hypervisor ABI), which
uses XENFEAT_dom0 and not SIF_*.

I'd be as happy to ifdef this in the public headers instead of moving
them if that is what people prefer. I don't think XEN_ARCH_HVM_ONLY is
quite the right name though. XEN_HAVE_PV_GUEST_ENTRY perhaps? This makes
some sense by virtue of start_info not being useful on ARM partly
because we use the normal native entry points which don't allow for it.

Do we think that it is likely that a new architecture port which doesn't
use hardware virtualisation extensions instead of PV is very likely?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:30:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:30: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 1U6LMz-0003KD-2p; Fri, 15 Feb 2013 13:30: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 1U6LMx-0003K6-EY
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:30:27 +0000
Received: from [85.158.143.99:42077] by server-1.bemta-4.messagelabs.com id
	AA/C4-08839-2783E115; Fri, 15 Feb 2013 13:30:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1360935024!27710619!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6048 invoked from network); 15 Feb 2013 13:30:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:30:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1515753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:30: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.297.1;
	Fri, 15 Feb 2013 13:30:24 +0000
Message-ID: <1360935023.31407.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 13:30:23 +0000
In-Reply-To: <511D0ED202000078000BE5BF@nat28.tlf.novell.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
	<1360853210.20449.414.camel@zakaz.uk.xensource.com>
	<511D0ED202000078000BE5BF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 15:20 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 15:46, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2013-02-14 at 14:43 +0000, Jan Beulich wrote:
> >> >>> On 14.02.13 at 15:16, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > Most of this struct is PV MMU specific and it is not used on ARM at all.
> >> 
> >> I'm not convinced this is the right move.
> >> 
> >> > --- a/xen/include/public/xen.h
> >> > +++ b/xen/include/public/xen.h
> >> > @@ -706,79 +706,6 @@ typedef struct shared_info shared_info_t;
> >> >   *     extended by an extra 4MB to ensure this.
> >> >   */
> >> >  
> >> > -#define MAX_GUEST_CMDLINE 1024
> >> > -struct start_info {
> >> > -    /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    
> > */
> >> > -    char magic[32];             /* "xen-<version>-<platform>".            */
> >> > -    unsigned long nr_pages;     /* Total pages allocated to this domain.  
> > */
> >> > -    unsigned long shared_info;  /* MACHINE address of shared info struct. 
> > */
> >> > -    uint32_t flags;             /* SIF_xxx flags.                         
> > */
> >> > -    xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    
> > */
> >> > -    uint32_t store_evtchn;      /* Event channel for store communication. 
> > */
> >> > -    union {
> >> > -        struct {
> >> > -            xen_pfn_t mfn;      /* MACHINE page number of console page.   
> > */
> >> > -            uint32_t  evtchn;   /* Event channel for console page.        
> > */
> >> > -        } domU;
> >> > -        struct {
> >> > -            uint32_t info_off;  /* Offset of console_info struct.         
> > */
> >> > -            uint32_t info_size; /* Size of console_info struct from 
> > start.*/
> >> > -        } dom0;
> >> > -    } console;
> >> 
> >> What is PV MMU related up to here?
> > 
> > Hrm, perhaps categorising this as PV MMU was a mistake on my part.
> > 
> > These are all unused on ARM in terms of the hypervisor ABI since it uses
> > HVM like mechanisms for those which are appropriate and doesn't use a
> > bunch of the others at all.
> 
> But nothing here makes this structure x86 specific, so I'd really like
> to keep it that way. If ARM doesn't use the structure at all, then
> I don't see the point in removing it from the common headers. If
> part of it (the flags come to mind) are being used by ARM, let's
> find a reasonable abstraction so that ARM doesn't need to carry
> useless baggage (e.g. a XEN_ARCH_HVM_ONLY #define).

Even the flags are unused on ARM (as part of the hypervisor ABI), which
uses XENFEAT_dom0 and not SIF_*.

I'd be as happy to ifdef this in the public headers instead of moving
them if that is what people prefer. I don't think XEN_ARCH_HVM_ONLY is
quite the right name though. XEN_HAVE_PV_GUEST_ENTRY perhaps? This makes
some sense by virtue of start_info not being useful on ARM partly
because we use the normal native entry points which don't allow for it.

Do we think that it is likely that a new architecture port which doesn't
use hardware virtualisation extensions instead of PV is very likely?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:35:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:35: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 1U6LRz-0003Ww-ST; Fri, 15 Feb 2013 13:35: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 1U6LRy-0003Wr-D1
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:35:38 +0000
Received: from [85.158.139.83:9388] by server-11.bemta-5.messagelabs.com id
	43/F0-19159-9A93E115; Fri, 15 Feb 2013 13:35:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360935336!20110556!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11896 invoked from network); 15 Feb 2013 13:35:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:35: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.297.1;
	Fri, 15 Feb 2013 13:35:36 +0000
Message-ID: <1360935335.31407.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Fri, 15 Feb 2013 13:35:35 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458383@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458383@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 13:54 +0000, Frediano Ziglio wrote:
> Reuse the string of hexadecimal numbers to simplify printnum implementation
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Acked-by: Keir Fraser <keir@xen.org>

Applied.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:35:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:35: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 1U6LRz-0003Ww-ST; Fri, 15 Feb 2013 13:35: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 1U6LRy-0003Wr-D1
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:35:38 +0000
Received: from [85.158.139.83:9388] by server-11.bemta-5.messagelabs.com id
	43/F0-19159-9A93E115; Fri, 15 Feb 2013 13:35:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360935336!20110556!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11896 invoked from network); 15 Feb 2013 13:35:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:35: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.297.1;
	Fri, 15 Feb 2013 13:35:36 +0000
Message-ID: <1360935335.31407.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Fri, 15 Feb 2013 13:35:35 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458383@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458383@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] trivial: Optimize printnum
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 13:54 +0000, Frediano Ziglio wrote:
> Reuse the string of hexadecimal numbers to simplify printnum implementation
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Acked-by: Keir Fraser <keir@xen.org>

Applied.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:35:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:35: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 1U6LS5-0003XM-8v; Fri, 15 Feb 2013 13:35:45 +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 1U6LS3-0003XA-4Y
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:35:43 +0000
Received: from [85.158.139.83:9648] by server-6.bemta-5.messagelabs.com id
	8A/32-01489-EA93E115; Fri, 15 Feb 2013 13:35:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360935336!20110556!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12220 invoked from network); 15 Feb 2013 13:35:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:35:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:35: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.297.1;
	Fri, 15 Feb 2013 13:35:40 +0000
Message-ID: <1360935339.31407.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 15 Feb 2013 13:35:39 +0000
In-Reply-To: <4b01cc2c2c1f4836e7fb.1360845424@whitby.uk.xensource.com>
References: <4b01cc2c2c1f4836e7fb.1360845424@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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: comment the use of
	second_linear_offset() in mm.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 Thu, 2013-02-14 at 12:37 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1360845361 0
> # Node ID 4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
> # Parent  6ad763d9f964859d045380baef43edf18399bdb0
> arm: comment the use of second_linear_offset() in mm.c
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked + applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:35:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:35: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 1U6LS5-0003XM-8v; Fri, 15 Feb 2013 13:35:45 +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 1U6LS3-0003XA-4Y
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:35:43 +0000
Received: from [85.158.139.83:9648] by server-6.bemta-5.messagelabs.com id
	8A/32-01489-EA93E115; Fri, 15 Feb 2013 13:35:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1360935336!20110556!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12220 invoked from network); 15 Feb 2013 13:35:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:35:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:35: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.297.1;
	Fri, 15 Feb 2013 13:35:40 +0000
Message-ID: <1360935339.31407.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 15 Feb 2013 13:35:39 +0000
In-Reply-To: <4b01cc2c2c1f4836e7fb.1360845424@whitby.uk.xensource.com>
References: <4b01cc2c2c1f4836e7fb.1360845424@whitby.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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: comment the use of
	second_linear_offset() in mm.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 Thu, 2013-02-14 at 12:37 +0000, Tim Deegan wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1360845361 0
> # Node ID 4b01cc2c2c1f4836e7fb34a58bc13e125d67969e
> # Parent  6ad763d9f964859d045380baef43edf18399bdb0
> arm: comment the use of second_linear_offset() in mm.c
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked + applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:36:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:36: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 1U6LT6-0003eF-O7; Fri, 15 Feb 2013 13:36: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 1U6LT5-0003dy-Hz
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:36:47 +0000
Received: from [85.158.143.99:25637] by server-1.bemta-4.messagelabs.com id
	87/CB-08839-EE93E115; Fri, 15 Feb 2013 13:36:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360935406!18064136!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16188 invoked from network); 15 Feb 2013 13:36:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:36:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:36: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.297.1;
	Fri, 15 Feb 2013 13:36:25 +0000
Message-ID: <1360935383.31407.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 13:36:23 +0000
In-Reply-To: <1360860480-9245-1-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 01/46] xen: arm32: Don't bother with the
 bootloader provided ARM-Linux machine 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 Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> Everything is DTB based and on 64-bit there is no such concept even in
> Linux.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Stefano Acked in
<alpine.DEB.2.02.1301241739070.29727@kaball.uk.xensource.com> which I
missed picking up here. Applied, thanks.

> ---
> v2: Update start_secondary too.
> ---
>  xen/arch/arm/arm32/head.S |    7 +++----
>  xen/arch/arm/setup.c      |    1 -
>  xen/arch/arm/smpboot.c    |    1 -
>  3 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> index 20e9da6..92fc36c 100644
> --- a/xen/arch/arm/arm32/head.S
> +++ b/xen/arch/arm/arm32/head.S
> @@ -72,7 +72,7 @@ past_zImage:
>          cpsid aif                    /* Disable all interrupts */
>  
>          /* Save the bootloader arguments in less-clobberable registers */
> -        mov   r7, r1                 /* r7 := ARM-linux machine type */
> +        /* No need to save r1 == Unused ARM-linux machine type */
>          mov   r8, r2                 /* r8 := ATAG base address */
>  
>          /* Find out where we are */
> @@ -334,9 +334,8 @@ launch:
>          add   sp, #STACK_SIZE        /* (which grows down from the top). */
>          sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
>          mov   r0, r10                /* Marshal args: - phys_offset */
> -        mov   r1, r7                 /*               - machine type */
> -        mov   r2, r8                 /*               - ATAG address */
> -        movs  r3, r12                /*               - CPU ID */
> +        mov   r1, r8                 /*               - ATAG address */
> +        movs  r2, r12                /*               - CPU ID */
>          beq   start_xen              /* and disappear into the land of C */
>          b     start_secondary        /* (to the appropriate entry point) */
>  
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index acb7abb..782d252 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -329,7 +329,6 @@ void __init setup_cache(void)
>  
>  /* C entry point for boot CPU */
>  void __init start_xen(unsigned long boot_phys_offset,
> -                      unsigned long arm_type,
>                        unsigned long atag_paddr,
>                        unsigned long cpuid)
>  {
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index c7a586b..da4880c 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -132,7 +132,6 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
>  
>  /* Boot the current CPU */
>  void __cpuinit start_secondary(unsigned long boot_phys_offset,
> -                               unsigned long arm_type,
>                                 unsigned long atag_paddr,
>                                 unsigned long cpuid)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:36:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:36: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 1U6LT6-0003eF-O7; Fri, 15 Feb 2013 13:36: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 1U6LT5-0003dy-Hz
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:36:47 +0000
Received: from [85.158.143.99:25637] by server-1.bemta-4.messagelabs.com id
	87/CB-08839-EE93E115; Fri, 15 Feb 2013 13:36:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360935406!18064136!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16188 invoked from network); 15 Feb 2013 13:36:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:36:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:36: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.297.1;
	Fri, 15 Feb 2013 13:36:25 +0000
Message-ID: <1360935383.31407.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 13:36:23 +0000
In-Reply-To: <1360860480-9245-1-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 01/46] xen: arm32: Don't bother with the
 bootloader provided ARM-Linux machine 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 Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> Everything is DTB based and on 64-bit there is no such concept even in
> Linux.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Stefano Acked in
<alpine.DEB.2.02.1301241739070.29727@kaball.uk.xensource.com> which I
missed picking up here. Applied, thanks.

> ---
> v2: Update start_secondary too.
> ---
>  xen/arch/arm/arm32/head.S |    7 +++----
>  xen/arch/arm/setup.c      |    1 -
>  xen/arch/arm/smpboot.c    |    1 -
>  3 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> index 20e9da6..92fc36c 100644
> --- a/xen/arch/arm/arm32/head.S
> +++ b/xen/arch/arm/arm32/head.S
> @@ -72,7 +72,7 @@ past_zImage:
>          cpsid aif                    /* Disable all interrupts */
>  
>          /* Save the bootloader arguments in less-clobberable registers */
> -        mov   r7, r1                 /* r7 := ARM-linux machine type */
> +        /* No need to save r1 == Unused ARM-linux machine type */
>          mov   r8, r2                 /* r8 := ATAG base address */
>  
>          /* Find out where we are */
> @@ -334,9 +334,8 @@ launch:
>          add   sp, #STACK_SIZE        /* (which grows down from the top). */
>          sub   sp, #CPUINFO_sizeof    /* Make room for CPU save record */
>          mov   r0, r10                /* Marshal args: - phys_offset */
> -        mov   r1, r7                 /*               - machine type */
> -        mov   r2, r8                 /*               - ATAG address */
> -        movs  r3, r12                /*               - CPU ID */
> +        mov   r1, r8                 /*               - ATAG address */
> +        movs  r2, r12                /*               - CPU ID */
>          beq   start_xen              /* and disappear into the land of C */
>          b     start_secondary        /* (to the appropriate entry point) */
>  
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index acb7abb..782d252 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -329,7 +329,6 @@ void __init setup_cache(void)
>  
>  /* C entry point for boot CPU */
>  void __init start_xen(unsigned long boot_phys_offset,
> -                      unsigned long arm_type,
>                        unsigned long atag_paddr,
>                        unsigned long cpuid)
>  {
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index c7a586b..da4880c 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -132,7 +132,6 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
>  
>  /* Boot the current CPU */
>  void __cpuinit start_secondary(unsigned long boot_phys_offset,
> -                               unsigned long arm_type,
>                                 unsigned long atag_paddr,
>                                 unsigned long cpuid)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:37:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LTA-0003eu-55; Fri, 15 Feb 2013 13:36: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 1U6LT9-0003dy-59
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:36:51 +0000
Received: from [85.158.143.99:2357] by server-1.bemta-4.messagelabs.com id
	AC/DB-08839-2F93E115; Fri, 15 Feb 2013 13:36:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360935406!18064136!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16533 invoked from network); 15 Feb 2013 13:36:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:36:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:36: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.297.1;
	Fri, 15 Feb 2013 13:36:50 +0000
Message-ID: <1360935408.31407.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 13:36:48 +0000
In-Reply-To: <1360860480-9245-2-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-2-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 02/46] xen: arm: rename atag_paddr
	argument fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> We don't support ATAGs and this is always actually an FDT address.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:37:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LTA-0003eu-55; Fri, 15 Feb 2013 13:36: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 1U6LT9-0003dy-59
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:36:51 +0000
Received: from [85.158.143.99:2357] by server-1.bemta-4.messagelabs.com id
	AC/DB-08839-2F93E115; Fri, 15 Feb 2013 13:36:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360935406!18064136!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16533 invoked from network); 15 Feb 2013 13:36:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:36:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:36: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.297.1;
	Fri, 15 Feb 2013 13:36:50 +0000
Message-ID: <1360935408.31407.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 13:36:48 +0000
In-Reply-To: <1360860480-9245-2-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-2-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 02/46] xen: arm: rename atag_paddr
	argument fdt_paddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> We don't support ATAGs and this is always actually an FDT address.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:37:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LTi-0003lw-ON; Fri, 15 Feb 2013 13:37:26 +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 1U6LTg-0003lY-Ou
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:37:24 +0000
Received: from [85.158.138.51:16525] by server-3.bemta-3.messagelabs.com id
	EB/66-31070-31A3E115; Fri, 15 Feb 2013 13:37:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360935443!9043453!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22921 invoked from network); 15 Feb 2013 13:37:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:37: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.297.1;
	Fri, 15 Feb 2013 13:37:05 +0000
Message-ID: <1360935423.31407.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 13:37:03 +0000
In-Reply-To: <1360860480-9245-3-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-3-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 03/46] xen: arm: do not pass a machine ID
	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 Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> Xen relies on DTB and we pass in a suitable device-tree so we don't
> need to (and shouldn't) pretend to be a Versatile Express here.
> 
> We already don't pass a machine ID to domU in the same way.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:37:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LTi-0003lw-ON; Fri, 15 Feb 2013 13:37:26 +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 1U6LTg-0003lY-Ou
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:37:24 +0000
Received: from [85.158.138.51:16525] by server-3.bemta-3.messagelabs.com id
	EB/66-31070-31A3E115; Fri, 15 Feb 2013 13:37:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360935443!9043453!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22921 invoked from network); 15 Feb 2013 13:37:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:37: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.297.1;
	Fri, 15 Feb 2013 13:37:05 +0000
Message-ID: <1360935423.31407.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 15 Feb 2013 13:37:03 +0000
In-Reply-To: <1360860480-9245-3-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-3-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 03/46] xen: arm: do not pass a machine ID
	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 Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> Xen relies on DTB and we pass in a suitable device-tree so we don't
> need to (and shouldn't) pretend to be a Versatile Express here.
> 
> We already don't pass a machine ID to domU in the same way.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:37:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LTj-0003m8-4X; Fri, 15 Feb 2013 13:37: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 1U6LTh-0003lY-7Z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:37:25 +0000
Received: from [85.158.138.51:63487] by server-3.bemta-3.messagelabs.com id
	FC/66-31070-41A3E115; Fri, 15 Feb 2013 13:37:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360935443!9043453!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22928 invoked from network); 15 Feb 2013 13:37:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516097"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:37: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.297.1;
	Fri, 15 Feb 2013 13:37:23 +0000
Message-ID: <1360935441.31407.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Fri, 15 Feb 2013 13:37:21 +0000
In-Reply-To: <CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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 Mon, 2013-02-11 at 13:22 +0000, Shakeel Butt wrote:
> > Please can you describe what goes wrong with it where it is?
> Executing "./configure --enable-stubdom" doesn't call
> stubdom/configure and I think the following patch will fix it
> correctly.

I rewrote your commit message as followed and checked this in. Please
try and supply a usable commit message with a meaningful subject in the
future.

>From f478258a4d3b5b9f27b265af8014617c53b83368 Mon Sep 17 00:00:00 2001
From: Shakeel Butt <shakeel.butt@gmail.com>
Date: Mon, 11 Feb 2013 08:22:48 -0500
Subject: [PATCH] configure: configure a subsystem when explicitly requested.

Executing "./configure --enable-stubdom" doesn't call stubdom/configure, fix
this.

Signed-off-by: Shakeel Butt <shakeel.butt@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 configure       |    6 +++---
 m4/subsystem.m4 |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 69803a7..06c0e99 100755
--- a/configure
+++ b/configure
@@ -2000,6 +2000,9 @@ stubdom=n
 
 fi
 
+fi
+
+
 if test -e "stubdom/configure"; then :
 
 if test "x$stubdom" = "xy" || test "x$stubdom" = "x" ; then
@@ -2011,9 +2014,6 @@ fi
 
 
 
-fi
-
-
 
 # Check whether --enable-docs was given.
 if test "${enable_docs+set}" = set; then :
diff --git a/m4/subsystem.m4 b/m4/subsystem.m4
index 9e1e61f..5e2eb58 100644
--- a/m4/subsystem.m4
+++ b/m4/subsystem.m4
@@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
 ],[
 AX_DISABLE_SUBSYSTEM([$1])
 ])
+])
 AX_SUBSYSTEM_CONFIGURE([$1])
 AC_SUBST($1)
 ])
-])
 
 AC_DEFUN([AX_SUBSYSTEM_FINISH], [
 AC_SUBST(SUBSYSTEMS)
-- 
1.7.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 Feb 15 13:37:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LTj-0003m8-4X; Fri, 15 Feb 2013 13:37: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 1U6LTh-0003lY-7Z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:37:25 +0000
Received: from [85.158.138.51:63487] by server-3.bemta-3.messagelabs.com id
	FC/66-31070-41A3E115; Fri, 15 Feb 2013 13:37:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360935443!9043453!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22928 invoked from network); 15 Feb 2013 13:37:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516097"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:37: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.297.1;
	Fri, 15 Feb 2013 13:37:23 +0000
Message-ID: <1360935441.31407.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shakeel Butt <shakeel.butt@gmail.com>
Date: Fri, 15 Feb 2013 13:37:21 +0000
In-Reply-To: <CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
References: <CAGj-7pVT8-pM7foq4mN6f033rro3-R27D+SKhuXJDNhPFX3WtA@mail.gmail.com>
	<1360583122.29432.135.camel@zakaz.uk.xensource.com>
	<CAGj-7pWWQ12yntHZOh1iOQ7k8R+K-FMPvGkp4f=Pm2aP6gLnMQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] bug fix in configure 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 Mon, 2013-02-11 at 13:22 +0000, Shakeel Butt wrote:
> > Please can you describe what goes wrong with it where it is?
> Executing "./configure --enable-stubdom" doesn't call
> stubdom/configure and I think the following patch will fix it
> correctly.

I rewrote your commit message as followed and checked this in. Please
try and supply a usable commit message with a meaningful subject in the
future.

>From f478258a4d3b5b9f27b265af8014617c53b83368 Mon Sep 17 00:00:00 2001
From: Shakeel Butt <shakeel.butt@gmail.com>
Date: Mon, 11 Feb 2013 08:22:48 -0500
Subject: [PATCH] configure: configure a subsystem when explicitly requested.

Executing "./configure --enable-stubdom" doesn't call stubdom/configure, fix
this.

Signed-off-by: Shakeel Butt <shakeel.butt@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 configure       |    6 +++---
 m4/subsystem.m4 |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 69803a7..06c0e99 100755
--- a/configure
+++ b/configure
@@ -2000,6 +2000,9 @@ stubdom=n
 
 fi
 
+fi
+
+
 if test -e "stubdom/configure"; then :
 
 if test "x$stubdom" = "xy" || test "x$stubdom" = "x" ; then
@@ -2011,9 +2014,6 @@ fi
 
 
 
-fi
-
-
 
 # Check whether --enable-docs was given.
 if test "${enable_docs+set}" = set; then :
diff --git a/m4/subsystem.m4 b/m4/subsystem.m4
index 9e1e61f..5e2eb58 100644
--- a/m4/subsystem.m4
+++ b/m4/subsystem.m4
@@ -39,10 +39,10 @@ AX_ENABLE_SUBSYSTEM([$1])
 ],[
 AX_DISABLE_SUBSYSTEM([$1])
 ])
+])
 AX_SUBSYSTEM_CONFIGURE([$1])
 AC_SUBST($1)
 ])
-])
 
 AC_DEFUN([AX_SUBSYSTEM_FINISH], [
 AC_SUBST(SUBSYSTEMS)
-- 
1.7.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 Feb 15 13:37:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:37: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 1U6LTu-0003qQ-Is; Fri, 15 Feb 2013 13:37:38 +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 1U6LTt-0003pl-02
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:37:37 +0000
Received: from [193.109.254.147:54566] by server-13.bemta-14.messagelabs.com
	id 1F/77-30639-02A3E115; Fri, 15 Feb 2013 13:37:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360935455!8549891!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30467 invoked from network); 15 Feb 2013 13:37:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:37:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:37: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.297.1;
	Fri, 15 Feb 2013 13:37:35 +0000
Message-ID: <1360935454.31407.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 15 Feb 2013 13:37:34 +0000
In-Reply-To: <20130208154349.GA93591@ocelot.phlegethon.org>
References: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
	<20130208154349.GA93591@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] xen: arm32: Use system wide TLB flushes,
 not just inner-shareable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 15:43 +0000, Tim Deegan wrote:
> At 15:40 +0000 on 08 Feb (1360338056), Ian Campbell wrote:
> > We currently setup page table walks etc as outer-shareable. Given we don't
> > really make the distinction between inner- and outer-shareable yet err on
> > theside of safety.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:37:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:37: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 1U6LTu-0003qQ-Is; Fri, 15 Feb 2013 13:37:38 +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 1U6LTt-0003pl-02
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:37:37 +0000
Received: from [193.109.254.147:54566] by server-13.bemta-14.messagelabs.com
	id 1F/77-30639-02A3E115; Fri, 15 Feb 2013 13:37:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360935455!8549891!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30467 invoked from network); 15 Feb 2013 13:37:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:37:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:37: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.297.1;
	Fri, 15 Feb 2013 13:37:35 +0000
Message-ID: <1360935454.31407.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 15 Feb 2013 13:37:34 +0000
In-Reply-To: <20130208154349.GA93591@ocelot.phlegethon.org>
References: <1360338056-31812-1-git-send-email-ian.campbell@citrix.com>
	<20130208154349.GA93591@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] xen: arm32: Use system wide TLB flushes,
 not just inner-shareable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-08 at 15:43 +0000, Tim Deegan wrote:
> At 15:40 +0000 on 08 Feb (1360338056), Ian Campbell wrote:
> > We currently setup page table walks etc as outer-shareable. Given we don't
> > really make the distinction between inner- and outer-shareable yet err on
> > theside of safety.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:38:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:38: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 1U6LV7-0004Be-3r; Fri, 15 Feb 2013 13:38:53 +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 1U6LV5-0004BC-5p
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:38:51 +0000
Received: from [85.158.139.211:5732] by server-1.bemta-5.messagelabs.com id
	A4/8D-29263-A6A3E115; Fri, 15 Feb 2013 13:38:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360935529!22637495!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32743 invoked from network); 15 Feb 2013 13:38:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:38:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:38: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.297.1;
	Fri, 15 Feb 2013 13:38:48 +0000
Message-ID: <1360935526.31407.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 15 Feb 2013 13:38:46 +0000
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 7] various changes for xm migrate
 logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-13 at 15:52 +0000, Olaf Hering wrote:
> Changes:
> tools/xc: fix logic error in stdiostream_progress
> tools/xc: handle tty output differently in stdiostream_progress
> tools/xc: turn XCFLAGS_* into shifts
> tools/xc: restore logging in xc_save
> tools/xc: log pid in xc_save/xc_restore output
> xl: correct help text of xl migrate
> libxl: pass debug flag down to libxl_domain_suspend

All acked = applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:38:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:38: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 1U6LV7-0004Be-3r; Fri, 15 Feb 2013 13:38:53 +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 1U6LV5-0004BC-5p
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:38:51 +0000
Received: from [85.158.139.211:5732] by server-1.bemta-5.messagelabs.com id
	A4/8D-29263-A6A3E115; Fri, 15 Feb 2013 13:38:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1360935529!22637495!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32743 invoked from network); 15 Feb 2013 13:38:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:38:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:38: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.297.1;
	Fri, 15 Feb 2013 13:38:48 +0000
Message-ID: <1360935526.31407.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 15 Feb 2013 13:38:46 +0000
In-Reply-To: <patchbomb.1360770778@probook.site>
References: <patchbomb.1360770778@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 7] various changes for xm migrate
 logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-13 at 15:52 +0000, Olaf Hering wrote:
> Changes:
> tools/xc: fix logic error in stdiostream_progress
> tools/xc: handle tty output differently in stdiostream_progress
> tools/xc: turn XCFLAGS_* into shifts
> tools/xc: restore logging in xc_save
> tools/xc: log pid in xc_save/xc_restore output
> xl: correct help text of xl migrate
> libxl: pass debug flag down to libxl_domain_suspend

All acked = applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:40:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:40: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 1U6LW5-0004Nf-IA; Fri, 15 Feb 2013 13:39:53 +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 1U6LW4-0004NL-SV
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:39:52 +0000
Received: from [85.158.137.99:54966] by server-1.bemta-3.messagelabs.com id
	77/2B-08955-8AA3E115; Fri, 15 Feb 2013 13:39:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360935577!21594163!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29327 invoked from network); 15 Feb 2013 13:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:39: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.297.1;
	Fri, 15 Feb 2013 13:39:08 +0000
Message-ID: <1360935547.31407.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <ross.philipson@citrix.com>
Date: Fri, 15 Feb 2013 13:39:07 +0000
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough libxl
 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, 2013-02-13 at 21:52 +0000, Ross Philipson wrote:
> This patch series is a follow-up to the earlier HVM firmware passthrough
> patch set. It introduces support in libxl for specifying and loading the
> ACPI and SMBIOS firmware blobs that are passed to libxc.
> 
> There are 3 patches in the series:
> 01 - Switch xl to use the new xc_hvm_build() libxc API.
> 02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
>      Doc changes to the man page for xl.cfg describing the new params.
> 03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> 
> This version cleans up some of the logging and error handling in the
> new firmware passthrough code.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

Acked + applied. All three patches had the same title here, please give
patches unique and descriptive titles in the future. I retitled them as:

libxl: switch to using the new xc_hvm_build() libxc API.
libxl: HVM firmware passthrough support
libxl: Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:40:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:40: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 1U6LW5-0004Nf-IA; Fri, 15 Feb 2013 13:39:53 +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 1U6LW4-0004NL-SV
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:39:52 +0000
Received: from [85.158.137.99:54966] by server-1.bemta-3.messagelabs.com id
	77/2B-08955-8AA3E115; Fri, 15 Feb 2013 13:39:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360935577!21594163!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29327 invoked from network); 15 Feb 2013 13:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:39: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.297.1;
	Fri, 15 Feb 2013 13:39:08 +0000
Message-ID: <1360935547.31407.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ross Philipson <ross.philipson@citrix.com>
Date: Fri, 15 Feb 2013 13:39:07 +0000
In-Reply-To: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough libxl
 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, 2013-02-13 at 21:52 +0000, Ross Philipson wrote:
> This patch series is a follow-up to the earlier HVM firmware passthrough
> patch set. It introduces support in libxl for specifying and loading the
> ACPI and SMBIOS firmware blobs that are passed to libxc.
> 
> There are 3 patches in the series:
> 01 - Switch xl to use the new xc_hvm_build() libxc API.
> 02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
>      Doc changes to the man page for xl.cfg describing the new params.
> 03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> 
> This version cleans up some of the logging and error handling in the
> new firmware passthrough code.
> 
> Signed-off-by: Ross Philipson <ross.philipson@citrix.com>

Acked + applied. All three patches had the same title here, please give
patches unique and descriptive titles in the future. I retitled them as:

libxl: switch to using the new xc_hvm_build() libxc API.
libxl: HVM firmware passthrough support
libxl: Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:40:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:40: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 1U6LWC-0004PW-Us; Fri, 15 Feb 2013 13:40: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 1U6LWB-0004P3-MX
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:39:59 +0000
Received: from [85.158.137.99:3349] by server-6.bemta-3.messagelabs.com id
	D3/52-29959-EAA3E115; Fri, 15 Feb 2013 13:39:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360935577!21594163!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29348 invoked from network); 15 Feb 2013 13:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:39: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.297.1;
	Fri, 15 Feb 2013 13:39:37 +0000
Message-ID: <1360935576.31407.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:39:36 +0000
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v7 0/5] xen: ARM HDLCD video 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, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
> Stefano Stabellini (5):
>       xen: introduce a generic framebuffer driver

Needed ack from Keir when I first went through my queue. He has given it
now so I'll go back to this one.

>       xen/arm: move setup_mm right after setup_pagetables
>       xen/device_tree: introduce find_compatible_node
>       xen/arm: introduce vexpress_syscfg

Acked + applied these with s/atag_paddr/fdt_paddr/ since it was on top
of " xen: arm: rename atag_paddr argument fdt_paddr"

>       xen/arm: introduce a driver for the ARM HDLCD controller

Needs the first one.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:40:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:40: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 1U6LWC-0004PW-Us; Fri, 15 Feb 2013 13:40: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 1U6LWB-0004P3-MX
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:39:59 +0000
Received: from [85.158.137.99:3349] by server-6.bemta-3.messagelabs.com id
	D3/52-29959-EAA3E115; Fri, 15 Feb 2013 13:39:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360935577!21594163!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29348 invoked from network); 15 Feb 2013 13:39:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:39:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516194"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:39: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.297.1;
	Fri, 15 Feb 2013 13:39:37 +0000
Message-ID: <1360935576.31407.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:39:36 +0000
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v7 0/5] xen: ARM HDLCD video 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, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
> Stefano Stabellini (5):
>       xen: introduce a generic framebuffer driver

Needed ack from Keir when I first went through my queue. He has given it
now so I'll go back to this one.

>       xen/arm: move setup_mm right after setup_pagetables
>       xen/device_tree: introduce find_compatible_node
>       xen/arm: introduce vexpress_syscfg

Acked + applied these with s/atag_paddr/fdt_paddr/ since it was on top
of " xen: arm: rename atag_paddr argument fdt_paddr"

>       xen/arm: introduce a driver for the ARM HDLCD controller

Needs the first one.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:41:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LXE-0004gA-DU; Fri, 15 Feb 2013 13:41:04 +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 1U6LXC-0004fV-RO
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:41:02 +0000
Received: from [85.158.139.211:19077] by server-16.bemta-5.messagelabs.com id
	16/8C-14948-DEA3E115; Fri, 15 Feb 2013 13:41:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360935652!22359127!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6006 invoked from network); 15 Feb 2013 13:40:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:40:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:40: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.297.1;
	Fri, 15 Feb 2013 13:40:52 +0000
Message-ID: <1360935650.31407.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:40:50 +0000
In-Reply-To: <1360859833-16498-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1360859833-16498-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 1/7] xen/arm:
 /spin_lock_irq/spin_lock_irqsave in gic_set_guest_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:37 +0000, Stefano Stabellini wrote:
> gic_set_guest_irq can be called with irq disabled
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked + applied #1-#5

I commented on #6 and 7.

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 Feb 15 13:41:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LXE-0004gA-DU; Fri, 15 Feb 2013 13:41:04 +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 1U6LXC-0004fV-RO
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:41:02 +0000
Received: from [85.158.139.211:19077] by server-16.bemta-5.messagelabs.com id
	16/8C-14948-DEA3E115; Fri, 15 Feb 2013 13:41:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360935652!22359127!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6006 invoked from network); 15 Feb 2013 13:40:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:40:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:40: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.297.1;
	Fri, 15 Feb 2013 13:40:52 +0000
Message-ID: <1360935650.31407.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:40:50 +0000
In-Reply-To: <1360859833-16498-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1360859833-16498-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 1/7] xen/arm:
 /spin_lock_irq/spin_lock_irqsave in gic_set_guest_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 16:37 +0000, Stefano Stabellini wrote:
> gic_set_guest_irq can be called with irq disabled
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked + applied #1-#5

I commented on #6 and 7.

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 Feb 15 13:41:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:41: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 1U6LXH-0004h4-QP; Fri, 15 Feb 2013 13:41: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 1U6LXG-0004ge-FD
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:41:06 +0000
Received: from [193.109.254.147:31787] by server-4.bemta-14.messagelabs.com id
	72/D9-20719-1FA3E115; Fri, 15 Feb 2013 13:41:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360935664!8550326!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9084 invoked from network); 15 Feb 2013 13:41:04 -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; 15 Feb 2013 13:41:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 13:41:03 +0000
Message-Id: <511E48FC02000078000BEB2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 13:41:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
	<1360934649.31407.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360934649.31407.44.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 14:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> All I actually care about is the removal of struct start_info from the
> canonical copy of the hypervisor ABI (that is xen/include/public) for
> ARM.

But as already said - to me this looks wrong. The structure has
generally useful fields (and unless ARM uses _none_ of them,
then it must have some other way to communicate the respective
stuff, in which case I'd ask why a second mechanism got invented
when there already was one available), and even more so from
the abstract PV perspective.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:41:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:41: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 1U6LXH-0004h4-QP; Fri, 15 Feb 2013 13:41: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 1U6LXG-0004ge-FD
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:41:06 +0000
Received: from [193.109.254.147:31787] by server-4.bemta-14.messagelabs.com id
	72/D9-20719-1FA3E115; Fri, 15 Feb 2013 13:41:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1360935664!8550326!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9084 invoked from network); 15 Feb 2013 13:41:04 -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; 15 Feb 2013 13:41:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 13:41:03 +0000
Message-Id: <511E48FC02000078000BEB2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 13:41:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
	<1360934649.31407.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360934649.31407.44.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 14:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> All I actually care about is the removal of struct start_info from the
> canonical copy of the hypervisor ABI (that is xen/include/public) for
> ARM.

But as already said - to me this looks wrong. The structure has
generally useful fields (and unless ARM uses _none_ of them,
then it must have some other way to communicate the respective
stuff, in which case I'd ask why a second mechanism got invented
when there already was one available), and even more so from
the abstract PV perspective.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:42:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:42: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 1U6LY5-0004xY-A3; Fri, 15 Feb 2013 13:41:57 +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 1U6LY4-0004wu-Aa
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:41:56 +0000
Received: from [85.158.138.51:48643] by server-10.bemta-3.messagelabs.com id
	E4/A4-10609-32B3E115; Fri, 15 Feb 2013 13:41:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360935708!19635219!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2233 invoked from network); 15 Feb 2013 13:41:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:41:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:41: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.297.1;
	Fri, 15 Feb 2013 13:41:48 +0000
Message-ID: <1360935706.31407.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:41:46 +0000
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v3 0/4] xen/arm: compile and run 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

On Thu, 2013-02-14 at 18:05 +0000, Stefano Stabellini wrote:

> Stefano Stabellini (4):
>       xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common code
>       xen/arm: implement gnttab_create_shared_page and gnttab_shared_gmfn
>       libxc: fixes for the ARM platform
>       xen/arm: compile and run libxl/xl

All acked + applied, 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 Feb 15 13:42:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:42: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 1U6LY5-0004xY-A3; Fri, 15 Feb 2013 13:41:57 +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 1U6LY4-0004wu-Aa
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:41:56 +0000
Received: from [85.158.138.51:48643] by server-10.bemta-3.messagelabs.com id
	E4/A4-10609-32B3E115; Fri, 15 Feb 2013 13:41:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1360935708!19635219!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2233 invoked from network); 15 Feb 2013 13:41:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:41:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:41: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.297.1;
	Fri, 15 Feb 2013 13:41:48 +0000
Message-ID: <1360935706.31407.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:41:46 +0000
In-Reply-To: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141804010.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v3 0/4] xen/arm: compile and run 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

On Thu, 2013-02-14 at 18:05 +0000, Stefano Stabellini wrote:

> Stefano Stabellini (4):
>       xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common code
>       xen/arm: implement gnttab_create_shared_page and gnttab_shared_gmfn
>       libxc: fixes for the ARM platform
>       xen/arm: compile and run libxl/xl

All acked + applied, 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 Feb 15 13:46:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:46: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 1U6Lbw-0005Xi-Uq; Fri, 15 Feb 2013 13:45: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 1U6Lbv-0005Xa-RA
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:45:56 +0000
Received: from [85.158.143.35:58496] by server-3.bemta-4.messagelabs.com id
	06/F5-08920-31C3E115; Fri, 15 Feb 2013 13:45:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360935944!11654095!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8037 invoked from network); 15 Feb 2013 13:45:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 13:45:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 13:45:43 +0000
Message-Id: <511E4A1402000078000BEB63@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 13:45:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
	<1360853210.20449.414.camel@zakaz.uk.xensource.com>
	<511D0ED202000078000BE5BF@nat28.tlf.novell.com>
	<1360935023.31407.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360935023.31407.50.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 14:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I'd be as happy to ifdef this in the public headers instead of moving
> them if that is what people prefer. I don't think XEN_ARCH_HVM_ONLY is
> quite the right name though. XEN_HAVE_PV_GUEST_ENTRY perhaps? This makes
> some sense by virtue of start_info not being useful on ARM partly
> because we use the normal native entry points which don't allow for it.

I don't care much about the name - what you suggest reads fine
to me.

> Do we think that it is likely that a new architecture port which doesn't
> use hardware virtualisation extensions instead of PV is very likely?

I'd like to keep interfaces independent of actual implementations.
And in the case here, PV is what Xen started with, so if nothing
else I'd like to keep the interface this generic way for historical
reasons (not that I consider it likely to be revived, but ia64 surely
also used it).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:46:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:46: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 1U6Lbw-0005Xi-Uq; Fri, 15 Feb 2013 13:45: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 1U6Lbv-0005Xa-RA
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:45:56 +0000
Received: from [85.158.143.35:58496] by server-3.bemta-4.messagelabs.com id
	06/F5-08920-31C3E115; Fri, 15 Feb 2013 13:45:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1360935944!11654095!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8037 invoked from network); 15 Feb 2013 13:45:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 13:45:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 13:45:43 +0000
Message-Id: <511E4A1402000078000BEB63@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 13:45:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851324.20449.396.camel@zakaz.uk.xensource.com>
	<1360851374-28326-3-git-send-email-ian.campbell@citrix.com>
	<511D062202000078000BE541@nat28.tlf.novell.com>
	<1360853210.20449.414.camel@zakaz.uk.xensource.com>
	<511D0ED202000078000BE5BF@nat28.tlf.novell.com>
	<1360935023.31407.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360935023.31407.50.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 14:30, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I'd be as happy to ifdef this in the public headers instead of moving
> them if that is what people prefer. I don't think XEN_ARCH_HVM_ONLY is
> quite the right name though. XEN_HAVE_PV_GUEST_ENTRY perhaps? This makes
> some sense by virtue of start_info not being useful on ARM partly
> because we use the normal native entry points which don't allow for it.

I don't care much about the name - what you suggest reads fine
to me.

> Do we think that it is likely that a new architecture port which doesn't
> use hardware virtualisation extensions instead of PV is very likely?

I'd like to keep interfaces independent of actual implementations.
And in the case here, PV is what Xen started with, so if nothing
else I'd like to keep the interface this generic way for historical
reasons (not that I consider it likely to be revived, but ia64 surely
also used it).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:46:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:46: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 1U6Lc8-0005Zh-I8; Fri, 15 Feb 2013 13:46: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 1U6Lc6-0005ZJ-Pv
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:46:06 +0000
Received: from [85.158.137.99:8358] by server-16.bemta-3.messagelabs.com id
	4C/D8-02727-91C3E115; Fri, 15 Feb 2013 13:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360935950!13208709!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14292 invoked from network); 15 Feb 2013 13:45:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:45: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.297.1;
	Fri, 15 Feb 2013 13:45:50 +0000
Message-ID: <1360935948.31407.65.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:45:48 +0000
In-Reply-To: <alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:26 +0000, Stefano Stabellini wrote:
> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > Usage:
> >   vga="stdvga"|"cirrus"
> > 
> > - Default option is cirrus.
> > - Prints error and exit if unknown value is passed.
> > - stdvga parameter is now deprecated.
> > - Updated xl.cfg man.
> > 
> > Required patch: Improve videoram setting v5
> > Is prerequisite for patch: Add qxl support v9
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:46:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:46: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 1U6Lc8-0005Zh-I8; Fri, 15 Feb 2013 13:46: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 1U6Lc6-0005ZJ-Pv
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:46:06 +0000
Received: from [85.158.137.99:8358] by server-16.bemta-3.messagelabs.com id
	4C/D8-02727-91C3E115; Fri, 15 Feb 2013 13:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360935950!13208709!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14292 invoked from network); 15 Feb 2013 13:45:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:45: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.297.1;
	Fri, 15 Feb 2013 13:45:50 +0000
Message-ID: <1360935948.31407.65.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:45:48 +0000
In-Reply-To: <alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226130.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:26 +0000, Stefano Stabellini wrote:
> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > Usage:
> >   vga="stdvga"|"cirrus"
> > 
> > - Default option is cirrus.
> > - Prints error and exit if unknown value is passed.
> > - stdvga parameter is now deprecated.
> > - Updated xl.cfg man.
> > 
> > Required patch: Improve videoram setting v5
> > Is prerequisite for patch: Add qxl support v9
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:46:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LcM-0005bu-V8; Fri, 15 Feb 2013 13:46:22 +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 1U6LcM-0005bg-BL
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:46:22 +0000
Received: from [85.158.139.211:21144] by server-3.bemta-5.messagelabs.com id
	43/4C-07037-D2C3E115; Fri, 15 Feb 2013 13:46:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360935979!22360506!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8985 invoked from network); 15 Feb 2013 13:46:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:46: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.297.1;
	Fri, 15 Feb 2013 13:46:19 +0000
Message-ID: <1360935977.31407.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:46:17 +0000
In-Reply-To: <alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Zhou Peng <zpengxen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Fabio
	Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > Usage:
> >   vga="qxl"
> > 
> > Changes from v8:
> > - vga=qxl instead of qxl=1 to use it.
> > - Show an error and exit if vga="qxl" without qemu upstream.
> > - Other small improvements.
> > 
> > Required patches:
> > - Improve videoram setting v5
> > - Added vga parameter for hvm domUs
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> > Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied thanks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:46:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LcM-0005bu-V8; Fri, 15 Feb 2013 13:46:22 +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 1U6LcM-0005bg-BL
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:46:22 +0000
Received: from [85.158.139.211:21144] by server-3.bemta-5.messagelabs.com id
	43/4C-07037-D2C3E115; Fri, 15 Feb 2013 13:46:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360935979!22360506!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8985 invoked from network); 15 Feb 2013 13:46:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:46: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.297.1;
	Fri, 15 Feb 2013 13:46:19 +0000
Message-ID: <1360935977.31407.66.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:46:17 +0000
In-Reply-To: <alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Zhou Peng <zpengxen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Fabio
	Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > Usage:
> >   vga="qxl"
> > 
> > Changes from v8:
> > - vga=qxl instead of qxl=1 to use it.
> > - Show an error and exit if vga="qxl" without qemu upstream.
> > - Other small improvements.
> > 
> > Required patches:
> > - Improve videoram setting v5
> > - Added vga parameter for hvm domUs
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> > Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied thanks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:47:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:47: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 1U6Lcx-0005jx-D4; Fri, 15 Feb 2013 13:46: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 1U6Lcv-0005jP-TA
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:46:58 +0000
Received: from [85.158.139.83:20865] by server-15.bemta-5.messagelabs.com id
	1A/4E-18914-15C3E115; Fri, 15 Feb 2013 13:46:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360936016!26766972!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9540 invoked from network); 15 Feb 2013 13:46:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:46:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:46: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.297.1;
	Fri, 15 Feb 2013 13:46:56 +0000
Message-ID: <1360936015.31407.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:46:55 +0000
In-Reply-To: <alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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

On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > - If videoram setting is less than 8 mb shows error and exit.
> > - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
> > - Updated xl.cfg man.
> > - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
> >   qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
> >   (qemu 1.3 doesn't complain about it, probably buggy).
> > 
> > Changes from v5:
> > - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
> >   qemu is being used.
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:47:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:47: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 1U6Lcx-0005jx-D4; Fri, 15 Feb 2013 13:46: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 1U6Lcv-0005jP-TA
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 13:46:58 +0000
Received: from [85.158.139.83:20865] by server-15.bemta-5.messagelabs.com id
	1A/4E-18914-15C3E115; Fri, 15 Feb 2013 13:46:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360936016!26766972!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9540 invoked from network); 15 Feb 2013 13:46:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 13:46:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1516561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 13:46: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.297.1;
	Fri, 15 Feb 2013 13:46:56 +0000
Message-ID: <1360936015.31407.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 13:46:55 +0000
In-Reply-To: <alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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

On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > - If videoram setting is less than 8 mb shows error and exit.
> > - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
> > - Updated xl.cfg man.
> > - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
> >   qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
> >   (qemu 1.3 doesn't complain about it, probably buggy).
> > 
> > Changes from v5:
> > - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
> >   qemu is being used.
> > 
> > Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:47:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LdX-0005rz-RL; Fri, 15 Feb 2013 13:47:35 +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 1U6LdW-0005ri-Je
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:47:34 +0000
Received: from [193.109.254.147:11197] by server-7.bemta-14.messagelabs.com id
	96/F1-13581-57C3E115; Fri, 15 Feb 2013 13:47:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360936047!8572149!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11443 invoked from network); 15 Feb 2013 13:47:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 13:47:29 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FDlNHH000573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 13:47: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
	r1FDlMIK024711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 13:47:23 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
	r1FDlMtw025515; Fri, 15 Feb 2013 07:47:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 05:47:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4F3B01C387B; Fri, 15 Feb 2013 08:47:20 -0500 (EST)
Date: Fri, 15 Feb 2013 08:47:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130215134720.GG11777@phenom.dumpdata.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E268002000078000BE9FA@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 11:13:52AM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 15.02.2013 10:19, Jan Beulich wrote:
> >>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>> On a machine that could not cover all its RAM with MTRR ranges,
> >>> a crash on boot as dom0 was caused by dom0 trying to create
> >>> kernel mapping tables for the clipped range.
> >>>
> >>> (XEN) WARNING: MTRRs do not cover all of memory.
> >>> (XEN) Truncating RAM from 9109504kB to 9043968kB
> >>> ...
> >>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
> >>> ...
> >>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
> >>> [    0.000000]  0228000000 - 022c000000 page 4k
> >>> [    0.000000] kernel direct mapping tables up to 22c000000 @
> >>>                1e97d8000-1e97fa000
> >>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
> >>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
> >>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
> >>>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
> >>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
> >>>
> >>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
> >>> this is the same type that gets used for memory to be used only
> >>> as guest memory (using dom0_mem=).
> >> 
> >> Since when is E820_UNUSABLE memory being used as guest
> >> memory? If that's indeed the case, that's the bug to fix. The
> >> above data to me shows, however, that the range above
> >> 228000000 is considered invalid. So then the question is why the
> >> kernel tries to map that memory in the first place (the hypervisor
> >> rejecting the attempt, despite Dom0 being privileged, seems
> >> correct to me, as the range is also known not to be MMIO).

B/c it gets the E820 from the hypervisor, which shows that area as
E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
creating pagetables for it.

> > 
> > That seems to be done for a while now... On my testbox, when using 
> > dom0_mem=:
> > 
> > (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
> > (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
> > (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
> > (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
> > (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
> > (XEN)  0000000100000000 - 0000000820000000 (usable)
> 
> All that counts is what you see above.
> 
> > In dom0:
> > [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
> > [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data
> > [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
> > [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
> > [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> > [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
> > [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> > [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
> > [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
> > [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable
> 
> What Dom0 does to its representation of the E820 map is of no
> concern to the hypervisor. So are we in agreement then that the
> hypervisor code is fine without any changes?

I am not clear on what the right fix is. Dom0 could interpret E820_UNUSABLE
as memory to be considered as E820_RESERVED - but then I am wondering what
to do with hotplug memory. As in, does the BIOS mark memory that can be hotplugged
as E820_RESERVED or E820_UNUSABLE? So if we mark the memory as E820_RESERVED
and the hotplug memory code expects that - will we confuse it as there are now
new ranges of it?

Perhaps dom0 should just eviscerate that range altogether. But then it will
be considered as MMIO region and that will lead to trouble with i915 at least.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:47:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13: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 1U6LdX-0005rz-RL; Fri, 15 Feb 2013 13:47:35 +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 1U6LdW-0005ri-Je
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:47:34 +0000
Received: from [193.109.254.147:11197] by server-7.bemta-14.messagelabs.com id
	96/F1-13581-57C3E115; Fri, 15 Feb 2013 13:47:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360936047!8572149!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11443 invoked from network); 15 Feb 2013 13:47:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 13:47:29 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FDlNHH000573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 13:47: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
	r1FDlMIK024711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 13:47:23 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
	r1FDlMtw025515; Fri, 15 Feb 2013 07:47:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 05:47:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4F3B01C387B; Fri, 15 Feb 2013 08:47:20 -0500 (EST)
Date: Fri, 15 Feb 2013 08:47:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130215134720.GG11777@phenom.dumpdata.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E268002000078000BE9FA@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 11:13:52AM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 15.02.2013 10:19, Jan Beulich wrote:
> >>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>> On a machine that could not cover all its RAM with MTRR ranges,
> >>> a crash on boot as dom0 was caused by dom0 trying to create
> >>> kernel mapping tables for the clipped range.
> >>>
> >>> (XEN) WARNING: MTRRs do not cover all of memory.
> >>> (XEN) Truncating RAM from 9109504kB to 9043968kB
> >>> ...
> >>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
> >>> ...
> >>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
> >>> [    0.000000]  0228000000 - 022c000000 page 4k
> >>> [    0.000000] kernel direct mapping tables up to 22c000000 @
> >>>                1e97d8000-1e97fa000
> >>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
> >>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
> >>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
> >>>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
> >>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
> >>>
> >>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
> >>> this is the same type that gets used for memory to be used only
> >>> as guest memory (using dom0_mem=).
> >> 
> >> Since when is E820_UNUSABLE memory being used as guest
> >> memory? If that's indeed the case, that's the bug to fix. The
> >> above data to me shows, however, that the range above
> >> 228000000 is considered invalid. So then the question is why the
> >> kernel tries to map that memory in the first place (the hypervisor
> >> rejecting the attempt, despite Dom0 being privileged, seems
> >> correct to me, as the range is also known not to be MMIO).

B/c it gets the E820 from the hypervisor, which shows that area as
E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
creating pagetables for it.

> > 
> > That seems to be done for a while now... On my testbox, when using 
> > dom0_mem=:
> > 
> > (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
> > (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
> > (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
> > (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
> > (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
> > (XEN)  0000000100000000 - 0000000820000000 (usable)
> 
> All that counts is what you see above.
> 
> > In dom0:
> > [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
> > [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data
> > [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
> > [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
> > [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> > [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
> > [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> > [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
> > [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
> > [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable
> 
> What Dom0 does to its representation of the E820 map is of no
> concern to the hypervisor. So are we in agreement then that the
> hypervisor code is fine without any changes?

I am not clear on what the right fix is. Dom0 could interpret E820_UNUSABLE
as memory to be considered as E820_RESERVED - but then I am wondering what
to do with hotplug memory. As in, does the BIOS mark memory that can be hotplugged
as E820_RESERVED or E820_UNUSABLE? So if we mark the memory as E820_RESERVED
and the hotplug memory code expects that - will we confuse it as there are now
new ranges of it?

Perhaps dom0 should just eviscerate that range altogether. But then it will
be considered as MMIO region and that will lead to trouble with i915 at least.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:55:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:55: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 1U6Lkf-0006QR-D4; Fri, 15 Feb 2013 13:54:57 +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 1U6Lke-0006QF-EU
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:54:56 +0000
Received: from [193.109.254.147:14096] by server-9.bemta-14.messagelabs.com id
	7B/07-30867-F2E3E115; Fri, 15 Feb 2013 13:54:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360936486!3392236!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1334 invoked from network); 15 Feb 2013 13:54:47 -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;
	15 Feb 2013 13:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7306264"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 13:54:44 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 08:54:45 -0500
Message-ID: <511E3E24.2040202@citrix.com>
Date: Fri, 15 Feb 2013 13:54:44 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/13 14:19, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.

Does this actually work for all possible events?  In a 32-bit guest on a
64-bit hypervisor, does the __ffs() find set bits in the upper 32-bit
word of the pending selector?  I don't think so.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 13:55:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 13:55: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 1U6Lkf-0006QR-D4; Fri, 15 Feb 2013 13:54:57 +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 1U6Lke-0006QF-EU
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 13:54:56 +0000
Received: from [193.109.254.147:14096] by server-9.bemta-14.messagelabs.com id
	7B/07-30867-F2E3E115; Fri, 15 Feb 2013 13:54:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1360936486!3392236!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1334 invoked from network); 15 Feb 2013 13:54:47 -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;
	15 Feb 2013 13:54:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7306264"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 13:54:44 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 08:54:45 -0500
Message-ID: <511E3E24.2040202@citrix.com>
Date: Fri, 15 Feb 2013 13:54:44 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/02/13 14:19, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.

Does this actually work for all possible events?  In a 32-bit guest on a
64-bit hypervisor, does the __ffs() find set bits in the upper 32-bit
word of the pending selector?  I don't think so.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:01:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6Lqo-0006q0-BW; Fri, 15 Feb 2013 14:01:18 +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 1U6Lqm-0006pt-TS
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:01:17 +0000
Received: from [85.158.139.211:37412] by server-1.bemta-5.messagelabs.com id
	49/A1-29263-CAF3E115; Fri, 15 Feb 2013 14:01:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360936873!21002748!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14029 invoked from network); 15 Feb 2013 14:01:14 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:01:14 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so1371243wib.1
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 06:01:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=WfXIloXZlUKsjRtolFek95aWe7O08DGpznFrOfgX5J8=;
	b=0HbXLG0XxWqfgUeXwDCu0YCEE96YEwUP1Wn7/nPNQpcg20KhEyFp5Cl71m7F6Otj3c
	OeSILV1X2mni6kAfdVFvd1SiFNHnTwj2j9/O2C3G1/qlQv5aVEsXzveyZS/QJiMaDCv/
	rka6cbcwIoNP2MU6Iq3EWS4FVhtE1zzvpp60imnT6Bh6Kv/jl7QYAAt4kaln/1kgxqw3
	HKRVmj1fSijLwpQXbWoXUxxe5i+uLKi6LhbrmpnDpt6TB4qP0ko3+AvtXD1xOJlSsin5
	sRnFI8QcqxvcH/YHeVSWocdOKZxYrnJTlO9hu2ec16vOR95TAobgflXy4+/EH7/oPCbJ
	NJig==
X-Received: by 10.194.9.71 with SMTP id x7mr4316441wja.53.1360936865514;
	Fri, 15 Feb 2013 06:01:05 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ec3sm5111361wib.1.2013.02.15.06.01.02
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 06:01:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 14:00:59 +0000
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CD43F01B.5BCF4%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
	not covered by MTRRs
Thread-Index: Ac4LhOGrtjAiDQwlC0SINd4Pp/89vw==
In-Reply-To: <20130215134720.GG11777@phenom.dumpdata.com>
Mime-version: 1.0
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/2013 13:47, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:

>> What Dom0 does to its representation of the E820 map is of no
>> concern to the hypervisor. So are we in agreement then that the
>> hypervisor code is fine without any changes?
> 
> I am not clear on what the right fix is. Dom0 could interpret E820_UNUSABLE
> as memory to be considered as E820_RESERVED - but then I am wondering what
> to do with hotplug memory. As in, does the BIOS mark memory that can be
> hotplugged
> as E820_RESERVED or E820_UNUSABLE? So if we mark the memory as E820_RESERVED
> and the hotplug memory code expects that - will we confuse it as there are now
> new ranges of it?
> 
> Perhaps dom0 should just eviscerate that range altogether. But then it will
> be considered as MMIO region and that will lead to trouble with i915 at least.

I don't think E820_RESERVED is specifically for hotplug use only, and we
could use it here in place of E820_UNUSABLE. That may be more correct, since
E820_UNUSABLE is specifically intended for RAM in which errors have been
detected.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:01:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6Lqo-0006q0-BW; Fri, 15 Feb 2013 14:01:18 +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 1U6Lqm-0006pt-TS
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:01:17 +0000
Received: from [85.158.139.211:37412] by server-1.bemta-5.messagelabs.com id
	49/A1-29263-CAF3E115; Fri, 15 Feb 2013 14:01:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1360936873!21002748!1
X-Originating-IP: [209.85.212.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14029 invoked from network); 15 Feb 2013 14:01:14 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:01:14 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so1371243wib.1
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 06:01:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=WfXIloXZlUKsjRtolFek95aWe7O08DGpznFrOfgX5J8=;
	b=0HbXLG0XxWqfgUeXwDCu0YCEE96YEwUP1Wn7/nPNQpcg20KhEyFp5Cl71m7F6Otj3c
	OeSILV1X2mni6kAfdVFvd1SiFNHnTwj2j9/O2C3G1/qlQv5aVEsXzveyZS/QJiMaDCv/
	rka6cbcwIoNP2MU6Iq3EWS4FVhtE1zzvpp60imnT6Bh6Kv/jl7QYAAt4kaln/1kgxqw3
	HKRVmj1fSijLwpQXbWoXUxxe5i+uLKi6LhbrmpnDpt6TB4qP0ko3+AvtXD1xOJlSsin5
	sRnFI8QcqxvcH/YHeVSWocdOKZxYrnJTlO9hu2ec16vOR95TAobgflXy4+/EH7/oPCbJ
	NJig==
X-Received: by 10.194.9.71 with SMTP id x7mr4316441wja.53.1360936865514;
	Fri, 15 Feb 2013 06:01:05 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ec3sm5111361wib.1.2013.02.15.06.01.02
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 06:01:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Fri, 15 Feb 2013 14:00:59 +0000
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CD43F01B.5BCF4%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
	not covered by MTRRs
Thread-Index: Ac4LhOGrtjAiDQwlC0SINd4Pp/89vw==
In-Reply-To: <20130215134720.GG11777@phenom.dumpdata.com>
Mime-version: 1.0
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/2013 13:47, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:

>> What Dom0 does to its representation of the E820 map is of no
>> concern to the hypervisor. So are we in agreement then that the
>> hypervisor code is fine without any changes?
> 
> I am not clear on what the right fix is. Dom0 could interpret E820_UNUSABLE
> as memory to be considered as E820_RESERVED - but then I am wondering what
> to do with hotplug memory. As in, does the BIOS mark memory that can be
> hotplugged
> as E820_RESERVED or E820_UNUSABLE? So if we mark the memory as E820_RESERVED
> and the hotplug memory code expects that - will we confuse it as there are now
> new ranges of it?
> 
> Perhaps dom0 should just eviscerate that range altogether. But then it will
> be considered as MMIO region and that will lead to trouble with i915 at least.

I don't think E820_RESERVED is specifically for hotplug use only, and we
could use it here in place of E820_UNUSABLE. That may be more correct, since
E820_UNUSABLE is specifically intended for RAM in which errors have been
detected.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:06:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:06: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 1U6Lvk-00076f-5M; Fri, 15 Feb 2013 14:06:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>) id 1U6Lvi-00076Y-8d
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:06:22 +0000
Received: from [85.158.138.51:54999] by server-11.bemta-3.messagelabs.com id
	B8/64-10249-DD04E115; Fri, 15 Feb 2013 14:06:21 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360937180!27735493!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12938 invoked from network); 15 Feb 2013 14:06:20 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 14:06:20 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U6Lve-0008T2-OZ; Fri, 15 Feb 2013 15:06:18 +0100
Message-ID: <511E40D8.5070603@hosteurope.de>
Date: Fri, 15 Feb 2013 15:06:16 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de> <511D000C.9030908@citrix.com>
In-Reply-To: <511D000C.9030908@citrix.com>
X-Enigmail-Version: 1.5
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1731728706422466349=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1731728706422466349==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2JUUVXJOBSTMIVCFEKWCL"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2JUUVXJOBSTMIVCFEKWCL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Roger,
hello everybody,

sorry for the late reply.

On 14.02.2013 16:17, Roger Pau Monn=C3=A9 wrote:
> Could you take a look at tools/libxl/libxl_types.idl?
>
> You should have something like the following chunk:
>
> libxl_device_nic =3D Struct("device_nic", [
>     ("backend_domid", libxl_domid),
>     ("devid", libxl_devid),
>     ("mtu", integer),
>     ("model", string),
>     ("mac", libxl_mac),
>     ("ip", string),
>     ("bridge", string),
>     ("ifname", string),
>     ("script", string),
>     ("nictype", libxl_nic_type),
>     ("rate_bytes_per_interval", uint64),
>     ("rate_interval_usecs", uint32),
>     ("gatewaydev", string),
>     ])
>
> (With only one "gatewaydev").
>
That was my copy'n'paste mistake - fixed.

I could see that after applying patches V1 the parameter "netdev" is
parsed correctly and the main ip is passed to xen scripts.
However, I could not get xen 4.3 running so I had to test 4.3 tools on
4.2.1 hypervisor, which could not start the domU, but debug output of
the scripts showed me everything is parsed as expected.

The mac address still is not parsed if digits are not padded with
leading zero, like "mac=3Dde:ad:a:1e:42:3" - the rest of the line is
ignored without any error.

However, I was not able to apply patches V2 after that, they do not seem
to work together with the first patch series.
Only patching with V2 resulted in missing "netdev" member in
libxl_device_nic (libxl_types.idl). After editing the file and adding
the definition, it compiled so far.

xl with only patches V2 applied does parse neither netdev nor gatewaydev
as it seems.


Best regards,
Ulf



------enig2JUUVXJOBSTMIVCFEKWCL
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEeQNgACgkQhHSVerqjg04KEgCcCSqCdche0b7UqZG6iIpj0Id2
ppQAnj18MHwXAdMSGuey36kBmzYQXITF
=UMH9
-----END PGP SIGNATURE-----

------enig2JUUVXJOBSTMIVCFEKWCL--


--===============1731728706422466349==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1731728706422466349==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 14:06:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:06: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 1U6Lvk-00076f-5M; Fri, 15 Feb 2013 14:06:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>) id 1U6Lvi-00076Y-8d
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:06:22 +0000
Received: from [85.158.138.51:54999] by server-11.bemta-3.messagelabs.com id
	B8/64-10249-DD04E115; Fri, 15 Feb 2013 14:06:21 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360937180!27735493!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12938 invoked from network); 15 Feb 2013 14:06:20 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 14:06:20 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U6Lve-0008T2-OZ; Fri, 15 Feb 2013 15:06:18 +0100
Message-ID: <511E40D8.5070603@hosteurope.de>
Date: Fri, 15 Feb 2013 15:06:16 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de> <511D000C.9030908@citrix.com>
In-Reply-To: <511D000C.9030908@citrix.com>
X-Enigmail-Version: 1.5
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1731728706422466349=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1731728706422466349==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2JUUVXJOBSTMIVCFEKWCL"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2JUUVXJOBSTMIVCFEKWCL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Roger,
hello everybody,

sorry for the late reply.

On 14.02.2013 16:17, Roger Pau Monn=C3=A9 wrote:
> Could you take a look at tools/libxl/libxl_types.idl?
>
> You should have something like the following chunk:
>
> libxl_device_nic =3D Struct("device_nic", [
>     ("backend_domid", libxl_domid),
>     ("devid", libxl_devid),
>     ("mtu", integer),
>     ("model", string),
>     ("mac", libxl_mac),
>     ("ip", string),
>     ("bridge", string),
>     ("ifname", string),
>     ("script", string),
>     ("nictype", libxl_nic_type),
>     ("rate_bytes_per_interval", uint64),
>     ("rate_interval_usecs", uint32),
>     ("gatewaydev", string),
>     ])
>
> (With only one "gatewaydev").
>
That was my copy'n'paste mistake - fixed.

I could see that after applying patches V1 the parameter "netdev" is
parsed correctly and the main ip is passed to xen scripts.
However, I could not get xen 4.3 running so I had to test 4.3 tools on
4.2.1 hypervisor, which could not start the domU, but debug output of
the scripts showed me everything is parsed as expected.

The mac address still is not parsed if digits are not padded with
leading zero, like "mac=3Dde:ad:a:1e:42:3" - the rest of the line is
ignored without any error.

However, I was not able to apply patches V2 after that, they do not seem
to work together with the first patch series.
Only patching with V2 resulted in missing "netdev" member in
libxl_device_nic (libxl_types.idl). After editing the file and adding
the definition, it compiled so far.

xl with only patches V2 applied does parse neither netdev nor gatewaydev
as it seems.


Best regards,
Ulf



------enig2JUUVXJOBSTMIVCFEKWCL
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEeQNgACgkQhHSVerqjg04KEgCcCSqCdche0b7UqZG6iIpj0Id2
ppQAnj18MHwXAdMSGuey36kBmzYQXITF
=UMH9
-----END PGP SIGNATURE-----

------enig2JUUVXJOBSTMIVCFEKWCL--


--===============1731728706422466349==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1731728706422466349==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 14:06:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:06: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 1U6Lw1-00078U-It; Fri, 15 Feb 2013 14:06:41 +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 1U6Lw0-00078K-RU
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:06:41 +0000
Received: from [193.109.254.147:64642] by server-5.bemta-14.messagelabs.com id
	52/20-21539-0F04E115; Fri, 15 Feb 2013 14:06:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360937198!8541979!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27422 invoked from network); 15 Feb 2013 14:06:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:06: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.297.1;
	Fri, 15 Feb 2013 14:06:38 +0000
Message-ID: <1360937196.31407.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 14:06:36 +0000
In-Reply-To: <511E48FC02000078000BEB2E@nat28.tlf.novell.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
	<1360934649.31407.44.camel@zakaz.uk.xensource.com>
	<511E48FC02000078000BEB2E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 13:41 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 14:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > All I actually care about is the removal of struct start_info from the
> > canonical copy of the hypervisor ABI (that is xen/include/public) for
> > ARM.
> 
> But as already said - to me this looks wrong. The structure has
> generally useful fields (and unless ARM uses _none_ of them,

This is right, ARM uses none of them, at the hypervisor ABI level at
least. There's actually no way to pass a start info to an ARM guest
because they are launched via the native code paths.

> then it must have some other way to communicate the respective
> stuff, in which case I'd ask why a second mechanism got invented
> when there already was one available), and even more so from
> the abstract PV perspective.

ARM uses HVM params (e.g. the xenstore and console ring + evtchn) and
XENFEAT_dom0 etc (for privilegedness).

I guess it is obvious why HVM params were needed on HVM and you invented
XENFEAT_dom0 IIRC :-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:06:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:06: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 1U6Lw1-00078U-It; Fri, 15 Feb 2013 14:06:41 +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 1U6Lw0-00078K-RU
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:06:41 +0000
Received: from [193.109.254.147:64642] by server-5.bemta-14.messagelabs.com id
	52/20-21539-0F04E115; Fri, 15 Feb 2013 14:06:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360937198!8541979!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27422 invoked from network); 15 Feb 2013 14:06:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:06: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.297.1;
	Fri, 15 Feb 2013 14:06:38 +0000
Message-ID: <1360937196.31407.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 14:06:36 +0000
In-Reply-To: <511E48FC02000078000BEB2E@nat28.tlf.novell.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
	<1360934649.31407.44.camel@zakaz.uk.xensource.com>
	<511E48FC02000078000BEB2E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 13:41 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 14:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > All I actually care about is the removal of struct start_info from the
> > canonical copy of the hypervisor ABI (that is xen/include/public) for
> > ARM.
> 
> But as already said - to me this looks wrong. The structure has
> generally useful fields (and unless ARM uses _none_ of them,

This is right, ARM uses none of them, at the hypervisor ABI level at
least. There's actually no way to pass a start info to an ARM guest
because they are launched via the native code paths.

> then it must have some other way to communicate the respective
> stuff, in which case I'd ask why a second mechanism got invented
> when there already was one available), and even more so from
> the abstract PV perspective.

ARM uses HVM params (e.g. the xenstore and console ring + evtchn) and
XENFEAT_dom0 etc (for privilegedness).

I guess it is obvious why HVM params were needed on HVM and you invented
XENFEAT_dom0 IIRC :-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:07:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6LwY-0007Ch-6c; Fri, 15 Feb 2013 14:07: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 1U6LwW-0007CE-Hu
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:07:12 +0000
Received: from [85.158.143.35:26134] by server-3.bemta-4.messagelabs.com id
	2C/22-08920-F014E115; Fri, 15 Feb 2013 14:07:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360936982!12360562!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25026 invoked from network); 15 Feb 2013 14:03:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:03:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 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.297.1;
	Fri, 15 Feb 2013 14:03:02 +0000
Message-ID: <1360936980.31407.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 14:03:00 +0000
In-Reply-To: <alpine.DEB.2.02.1302151217310.8231@kaball.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151217310.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:22 +0000, Stefano Stabellini wrote:
> On Thu, 14 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/include/asm/xen/events.h |   22 +++++++++++
> >  arch/x86/include/asm/xen/events.h |    2 +
> >  drivers/xen/events.c              |   75 ++++++++++++++++++++----------------
> >  include/xen/interface/xen.h       |    8 ++--
> >  4 files changed, 70 insertions(+), 37 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..92dbb89 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
> >  }
> >  
> > +/*
> > + * We cannot use xchg because it does not support 8-byte
> > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > + * platforms which Xen can run on support those instructions.
> > + */
> > +static inline xen_ulong_t xen_read_evtchn_pending_sel(struct vcpu_info *vcpu_info)
> > +{
> > +	xen_ulong_t val;
> > +	unsigned int tmp;
> > +
> > +	wmb();
> > +	asm volatile("@ read_evtchn_pending_sel\n"
> > +		"1:     ldrexd  %0, %H0, [%3]\n"
> > +		"       strexd  %1, %2, %H2, [%3]\n"
> > +		"       teq     %1, #0\n"
> > +		"       bne     1b"
> > +			: "=&r" (val), "=&r" (tmp)
> > +			: "r" (0), "r" (&vcpu_info->evtchn_pending_sel)
> > +			: "memory", "cc");
> > +	return val;
> > +}
> 
> At this point we might as well introduce an xchg64, it is going to be
> more useful to us in the future and to other non-Xen people too.

The problem with that is the conditional nature of these instructions.
We are guaranteed to have them because LPAE and/or the virtualisation
extensions require them, but other ARMv7 implementations may not have
this.

> >  static inline int test_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	return sync_test_bit(port, &s->evtchn_pending[0]);
> > +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> 
> Are you sure that the implementation of sync_test_bit, sync_set_bit,
> etc, can cope with a bit > 32?
> For example ____atomic_set_bit blatantly (bit & 31) at the beginning of
> the function.

I must confess I thought that these bit mask functions were designed to
work on arbitrary sized bitmaps. I was so sure I didn't even check...

        static inline void ____atomic_set_bit(unsigned int bit, volatile unsigned long *p)
        {
                unsigned long flags;
                unsigned long mask = 1UL << (bit & 31);
        
                p += bit >> 5;
        
                raw_local_irq_save(flags);
                *p |= mask;
                raw_local_irq_restore(flags);
        }
        
This is OK, it figures out the mask for the word containing @bit and
then increments @p to point to that word. The other bit ops are similar.

I think David V is right to be concerned about __ffs though, I'll need
to investigate that one further.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:07:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6LwY-0007Ch-6c; Fri, 15 Feb 2013 14:07: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 1U6LwW-0007CE-Hu
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:07:12 +0000
Received: from [85.158.143.35:26134] by server-3.bemta-4.messagelabs.com id
	2C/22-08920-F014E115; Fri, 15 Feb 2013 14:07:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360936982!12360562!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25026 invoked from network); 15 Feb 2013 14:03:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:03:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 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.297.1;
	Fri, 15 Feb 2013 14:03:02 +0000
Message-ID: <1360936980.31407.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 14:03:00 +0000
In-Reply-To: <alpine.DEB.2.02.1302151217310.8231@kaball.uk.xensource.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151217310.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 12:22 +0000, Stefano Stabellini wrote:
> On Thu, 14 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/include/asm/xen/events.h |   22 +++++++++++
> >  arch/x86/include/asm/xen/events.h |    2 +
> >  drivers/xen/events.c              |   75 ++++++++++++++++++++----------------
> >  include/xen/interface/xen.h       |    8 ++--
> >  4 files changed, 70 insertions(+), 37 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..92dbb89 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
> >  }
> >  
> > +/*
> > + * We cannot use xchg because it does not support 8-byte
> > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > + * platforms which Xen can run on support those instructions.
> > + */
> > +static inline xen_ulong_t xen_read_evtchn_pending_sel(struct vcpu_info *vcpu_info)
> > +{
> > +	xen_ulong_t val;
> > +	unsigned int tmp;
> > +
> > +	wmb();
> > +	asm volatile("@ read_evtchn_pending_sel\n"
> > +		"1:     ldrexd  %0, %H0, [%3]\n"
> > +		"       strexd  %1, %2, %H2, [%3]\n"
> > +		"       teq     %1, #0\n"
> > +		"       bne     1b"
> > +			: "=&r" (val), "=&r" (tmp)
> > +			: "r" (0), "r" (&vcpu_info->evtchn_pending_sel)
> > +			: "memory", "cc");
> > +	return val;
> > +}
> 
> At this point we might as well introduce an xchg64, it is going to be
> more useful to us in the future and to other non-Xen people too.

The problem with that is the conditional nature of these instructions.
We are guaranteed to have them because LPAE and/or the virtualisation
extensions require them, but other ARMv7 implementations may not have
this.

> >  static inline int test_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	return sync_test_bit(port, &s->evtchn_pending[0]);
> > +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> 
> Are you sure that the implementation of sync_test_bit, sync_set_bit,
> etc, can cope with a bit > 32?
> For example ____atomic_set_bit blatantly (bit & 31) at the beginning of
> the function.

I must confess I thought that these bit mask functions were designed to
work on arbitrary sized bitmaps. I was so sure I didn't even check...

        static inline void ____atomic_set_bit(unsigned int bit, volatile unsigned long *p)
        {
                unsigned long flags;
                unsigned long mask = 1UL << (bit & 31);
        
                p += bit >> 5;
        
                raw_local_irq_save(flags);
                *p |= mask;
                raw_local_irq_restore(flags);
        }
        
This is OK, it figures out the mask for the word containing @bit and
then increments @p to point to that word. The other bit ops are similar.

I think David V is right to be concerned about __ffs though, I'll need
to investigate that one further.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:07: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 1U6Lwf-0007E2-Km; Fri, 15 Feb 2013 14:07:21 +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 1U6Lwd-0007DZ-Pi
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:07:19 +0000
Received: from [193.109.254.147:9154] by server-7.bemta-14.messagelabs.com id
	AB/48-13581-7114E115; Fri, 15 Feb 2013 14:07:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360937225!8401251!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21413 invoked from network); 15 Feb 2013 14:07:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14: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.297.1;
	Fri, 15 Feb 2013 14:07:05 +0000
Message-ID: <1360937223.31407.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 14:07:03 +0000
In-Reply-To: <1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v7 1/5] xen: introduce a generic framebuffer
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEzLTAyLTE0IGF0IDE3OjMwICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gIHhlbi9kcml2ZXJzL3ZpZGVvL01ha2VmaWxlIHwgICAgMSArCj4gIHhlbi9kcml2ZXJz
L3ZpZGVvL2xmYi5jICAgIHwgIDE4MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKwo+ICB4ZW4vZHJpdmVycy92aWRlby9sZmIuaCAgICB8ICAgNDYgKysrKysrKysr
KysKPiAgeGVuL2RyaXZlcnMvdmlkZW8vdmVzYS5jICAgfCAgMTc3ICsrKysrKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKT24geDg2XzY0OwoKdmVzYS5jOiBJbiBmdW5jdGlv
biDigJh2ZXNhX2luaXTigJk6CnZlc2EuYzoxMjY6IGVycm9yOiDigJhmYnDigJkgdW5kZWNsYXJl
ZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCnZlc2EuYzoxMjY6IGVycm9yOiAoRWFjaCB1
bmRlY2xhcmVkIGlkZW50aWZpZXIgaXMgcmVwb3J0ZWQgb25seSBvbmNlCnZlc2EuYzoxMjY6IGVy
cm9yOiBmb3IgZWFjaCBmdW5jdGlvbiBpdCBhcHBlYXJzIGluLikKCkkgdGhpbmsgdGhpcyBmaXhl
cyBpdCwgaWYgaXQgZG9lcyB0aGVuIEknbSBoYXBweSB0byByb2xlIGluIGFzIEkgYXBwbHkuCgpk
aWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdmlkZW8vdmVzYS5jIGIveGVuL2RyaXZlcnMvdmlkZW8v
dmVzYS5jCmluZGV4IDFmYmU5NTkuLjU3NWRiNjIgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJzL3Zp
ZGVvL3Zlc2EuYworKysgYi94ZW4vZHJpdmVycy92aWRlby92ZXNhLmMKQEAgLTEyMyw3ICsxMjMs
NyBAQCB2b2lkIF9faW5pdCB2ZXNhX2luaXQodm9pZCkKICAgICB7CiAgICAgICAgIC8qIExpZ2h0
IGdyZXkgaW4gdHJ1ZWNvbG9yLiAqLwogICAgICAgICB1bnNpZ25lZCBpbnQgZ3JleSA9IDB4YWFh
YWFhYWE7Ci0gICAgICAgIGZicC5waXhlbF9vbiA9CisgICAgICAgIGxmYnAucGl4ZWxfb24gPQog
ICAgICAgICAgICAgKChncmV5ID4+ICgzMiAtIHZsZmJfaW5mby4gIHJlZF9zaXplKSkgPDwgdmxm
Yl9pbmZvLiAgcmVkX3BvcykgfAogICAgICAgICAgICAgKChncmV5ID4+ICgzMiAtIHZsZmJfaW5m
by5ncmVlbl9zaXplKSkgPDwgdmxmYl9pbmZvLmdyZWVuX3BvcykgfAogICAgICAgICAgICAgKChn
cmV5ID4+ICgzMiAtIHZsZmJfaW5mby4gYmx1ZV9zaXplKSkgPDwgdmxmYl9pbmZvLiBibHVlX3Bv
cyk7CkBAIC0xMzEsNyArMTMxLDcgQEAgdm9pZCBfX2luaXQgdmVzYV9pbml0KHZvaWQpCiAgICAg
ZWxzZQogICAgIHsKICAgICAgICAgLyogV2hpdGUoaXNoKSBpbiBkZWZhdWx0IHBzZXVkb2NvbG9y
IHBhbGV0dGUuICovCi0gICAgICAgIGZicC5waXhlbF9vbiA9IDc7CisgICAgICAgIGxmYnAucGl4
ZWxfb24gPSA3OwogICAgIH0KIAogICAgIGlmICggbGZiX2luaXQoJmxmYnApIDwgMCApCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:07: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 1U6Lwf-0007E2-Km; Fri, 15 Feb 2013 14:07:21 +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 1U6Lwd-0007DZ-Pi
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:07:19 +0000
Received: from [193.109.254.147:9154] by server-7.bemta-14.messagelabs.com id
	AB/48-13581-7114E115; Fri, 15 Feb 2013 14:07:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360937225!8401251!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21413 invoked from network); 15 Feb 2013 14:07:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14: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.297.1;
	Fri, 15 Feb 2013 14:07:05 +0000
Message-ID: <1360937223.31407.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 14:07:03 +0000
In-Reply-To: <1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v7 1/5] xen: introduce a generic framebuffer
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEzLTAyLTE0IGF0IDE3OjMwICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gIHhlbi9kcml2ZXJzL3ZpZGVvL01ha2VmaWxlIHwgICAgMSArCj4gIHhlbi9kcml2ZXJz
L3ZpZGVvL2xmYi5jICAgIHwgIDE4MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKwo+ICB4ZW4vZHJpdmVycy92aWRlby9sZmIuaCAgICB8ICAgNDYgKysrKysrKysr
KysKPiAgeGVuL2RyaXZlcnMvdmlkZW8vdmVzYS5jICAgfCAgMTc3ICsrKysrKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKT24geDg2XzY0OwoKdmVzYS5jOiBJbiBmdW5jdGlv
biDigJh2ZXNhX2luaXTigJk6CnZlc2EuYzoxMjY6IGVycm9yOiDigJhmYnDigJkgdW5kZWNsYXJl
ZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCnZlc2EuYzoxMjY6IGVycm9yOiAoRWFjaCB1
bmRlY2xhcmVkIGlkZW50aWZpZXIgaXMgcmVwb3J0ZWQgb25seSBvbmNlCnZlc2EuYzoxMjY6IGVy
cm9yOiBmb3IgZWFjaCBmdW5jdGlvbiBpdCBhcHBlYXJzIGluLikKCkkgdGhpbmsgdGhpcyBmaXhl
cyBpdCwgaWYgaXQgZG9lcyB0aGVuIEknbSBoYXBweSB0byByb2xlIGluIGFzIEkgYXBwbHkuCgpk
aWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdmlkZW8vdmVzYS5jIGIveGVuL2RyaXZlcnMvdmlkZW8v
dmVzYS5jCmluZGV4IDFmYmU5NTkuLjU3NWRiNjIgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJzL3Zp
ZGVvL3Zlc2EuYworKysgYi94ZW4vZHJpdmVycy92aWRlby92ZXNhLmMKQEAgLTEyMyw3ICsxMjMs
NyBAQCB2b2lkIF9faW5pdCB2ZXNhX2luaXQodm9pZCkKICAgICB7CiAgICAgICAgIC8qIExpZ2h0
IGdyZXkgaW4gdHJ1ZWNvbG9yLiAqLwogICAgICAgICB1bnNpZ25lZCBpbnQgZ3JleSA9IDB4YWFh
YWFhYWE7Ci0gICAgICAgIGZicC5waXhlbF9vbiA9CisgICAgICAgIGxmYnAucGl4ZWxfb24gPQog
ICAgICAgICAgICAgKChncmV5ID4+ICgzMiAtIHZsZmJfaW5mby4gIHJlZF9zaXplKSkgPDwgdmxm
Yl9pbmZvLiAgcmVkX3BvcykgfAogICAgICAgICAgICAgKChncmV5ID4+ICgzMiAtIHZsZmJfaW5m
by5ncmVlbl9zaXplKSkgPDwgdmxmYl9pbmZvLmdyZWVuX3BvcykgfAogICAgICAgICAgICAgKChn
cmV5ID4+ICgzMiAtIHZsZmJfaW5mby4gYmx1ZV9zaXplKSkgPDwgdmxmYl9pbmZvLiBibHVlX3Bv
cyk7CkBAIC0xMzEsNyArMTMxLDcgQEAgdm9pZCBfX2luaXQgdmVzYV9pbml0KHZvaWQpCiAgICAg
ZWxzZQogICAgIHsKICAgICAgICAgLyogV2hpdGUoaXNoKSBpbiBkZWZhdWx0IHBzZXVkb2NvbG9y
IHBhbGV0dGUuICovCi0gICAgICAgIGZicC5waXhlbF9vbiA9IDc7CisgICAgICAgIGxmYnAucGl4
ZWxfb24gPSA3OwogICAgIH0KIAogICAgIGlmICggbGZiX2luaXQoJmxmYnApIDwgMCApCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:09:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:09: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 1U6LyR-0007WJ-6W; Fri, 15 Feb 2013 14:09:11 +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 1U6LyP-0007WB-Sn
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:09:10 +0000
Received: from [85.158.139.211:40906] by server-2.bemta-5.messagelabs.com id
	90/3B-16911-5814E115; Fri, 15 Feb 2013 14:09:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360937346!22622926!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31258 invoked from network); 15 Feb 2013 14:09:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:09:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7308128"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 14:09:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 09:09:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6LyL-0003U5-St;
	Fri, 15 Feb 2013 14:09:05 +0000
Date: Fri, 15 Feb 2013 14:09:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360937223.31407.77.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302151408460.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360937223.31407.77.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1842853698-1360937340=:8231"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1842853698-1360937340=:8231
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 15 Feb 2013, Ian Campbell wrote:
> On Thu, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
> >  xen/drivers/video/Makefile |    1 +
> >  xen/drivers/video/lfb.c    |  183 ++++++++++++++++++++++++++++++++++++=
++++++++
> >  xen/drivers/video/lfb.h    |   46 +++++++++++
> >  xen/drivers/video/vesa.c   |  177 ++++++------------------------------=
------
>=20
> On x86_64;
>=20
> vesa.c: In function =E2=80=98vesa_init=E2=80=99:
> vesa.c:126: error: =E2=80=98fbp=E2=80=99 undeclared (first use in this fu=
nction)
> vesa.c:126: error: (Each undeclared identifier is reported only once
> vesa.c:126: error: for each function it appears in.)
>=20
> I think this fixes it, if it does then I'm happy to role in as I apply.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
> index 1fbe959..575db62 100644
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -123,7 +123,7 @@ void __init vesa_init(void)
>      {
>          /* Light grey in truecolor. */
>          unsigned int grey =3D 0xaaaaaaaa;
> -        fbp.pixel_on =3D
> +        lfbp.pixel_on =3D
>              ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_po=
s) |
>              ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_po=
s) |
>              ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_po=
s);
> @@ -131,7 +131,7 @@ void __init vesa_init(void)
>      else
>      {
>          /* White(ish) in default pseudocolor palette. */
> -        fbp.pixel_on =3D 7;
> +        lfbp.pixel_on =3D 7;
>      }
> =20
>      if ( lfb_init(&lfbp) < 0 )
>=20
>=20
>=20
--1342847746-1842853698-1360937340=:8231
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1842853698-1360937340=:8231--


From xen-devel-bounces@lists.xen.org Fri Feb 15 14:09:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:09: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 1U6LyR-0007WJ-6W; Fri, 15 Feb 2013 14:09:11 +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 1U6LyP-0007WB-Sn
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:09:10 +0000
Received: from [85.158.139.211:40906] by server-2.bemta-5.messagelabs.com id
	90/3B-16911-5814E115; Fri, 15 Feb 2013 14:09:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360937346!22622926!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31258 invoked from network); 15 Feb 2013 14:09:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:09:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7308128"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 14:09:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 09:09:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6LyL-0003U5-St;
	Fri, 15 Feb 2013 14:09:05 +0000
Date: Fri, 15 Feb 2013 14:09:00 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360937223.31407.77.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302151408460.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
	<1360863042-19845-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360937223.31407.77.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1842853698-1360937340=:8231"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v7 1/5] xen: introduce a generic framebuffer
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1842853698-1360937340=:8231
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 15 Feb 2013, Ian Campbell wrote:
> On Thu, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:
> >  xen/drivers/video/Makefile |    1 +
> >  xen/drivers/video/lfb.c    |  183 ++++++++++++++++++++++++++++++++++++=
++++++++
> >  xen/drivers/video/lfb.h    |   46 +++++++++++
> >  xen/drivers/video/vesa.c   |  177 ++++++------------------------------=
------
>=20
> On x86_64;
>=20
> vesa.c: In function =E2=80=98vesa_init=E2=80=99:
> vesa.c:126: error: =E2=80=98fbp=E2=80=99 undeclared (first use in this fu=
nction)
> vesa.c:126: error: (Each undeclared identifier is reported only once
> vesa.c:126: error: for each function it appears in.)
>=20
> I think this fixes it, if it does then I'm happy to role in as I apply.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
> index 1fbe959..575db62 100644
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -123,7 +123,7 @@ void __init vesa_init(void)
>      {
>          /* Light grey in truecolor. */
>          unsigned int grey =3D 0xaaaaaaaa;
> -        fbp.pixel_on =3D
> +        lfbp.pixel_on =3D
>              ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_po=
s) |
>              ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_po=
s) |
>              ((grey >> (32 - vlfb_info. blue_size)) << vlfb_info. blue_po=
s);
> @@ -131,7 +131,7 @@ void __init vesa_init(void)
>      else
>      {
>          /* White(ish) in default pseudocolor palette. */
> -        fbp.pixel_on =3D 7;
> +        lfbp.pixel_on =3D 7;
>      }
> =20
>      if ( lfb_init(&lfbp) < 0 )
>=20
>=20
>=20
--1342847746-1842853698-1360937340=:8231
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1842853698-1360937340=:8231--


From xen-devel-bounces@lists.xen.org Fri Feb 15 14:18:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6M6r-0007zM-9v; Fri, 15 Feb 2013 14:17:53 +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 1U6M6p-0007zH-Ly
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:17:51 +0000
Received: from [193.109.254.147:51389] by server-7.bemta-14.messagelabs.com id
	D6/D4-13581-E834E115; Fri, 15 Feb 2013 14:17:50 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360937860!821988!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29584 invoked from network); 15 Feb 2013 14:17:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 14:17:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FEHa6r012418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 14:17:37 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
	r1FEHZSP023140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 14:17:36 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
	r1FEHZHX015714; Fri, 15 Feb 2013 08:17:35 -0600
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 06:17:34 -0800
Date: Fri, 15 Feb 2013 17:17:28 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: jinsong.liu@intel.com
Message-ID: <20130215141728.GA27966@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kbuild@01.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] xen/acpi: ACPI memory hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Liu Jinsong,

This is a semi-automatic email about new static checker warnings.

The patch 259f201cb7ea: "xen/acpi: ACPI memory hotplug" from Jan 24, 
2013, leads to the following Smatch complaint:

drivers/xen/xen-acpi-memhotplug.c:198 acpi_memory_get_device()
	 error: we previously assumed 'device' could be null (see line 171)

drivers/xen/xen-acpi-memhotplug.c
   170	
   171		if (!acpi_bus_get_device(handle, &device) && device)
                                                             ^^^^^^
New check.

Btw, checking device is unnecessary.

		if (acpi_bus_get_device(handle, &device) == 0)
			goto end;

A successful "Get Device" means that "device" is non-NULL; that's built
into the name.  Anyway, if acpi_bus_get_device() fails either something
else will fail or we will Oops in the call to acpi_driver_data().

   172			goto end;
   173	
   174		status = acpi_get_parent(handle, &phandle);
   175		if (ACPI_FAILURE(status)) {
   176			pr_warn(PREFIX "Cannot find acpi parent\n");
   177			return -EINVAL;
   178		}
   179	
   180		/* Get the parent device */
   181		result = acpi_bus_get_device(phandle, &pdevice);
   182		if (result) {
   183			pr_warn(PREFIX "Cannot get acpi bus device\n");
   184			return -EINVAL;
   185		}
   186	
   187		/*
   188		 * Now add the notified device.  This creates the acpi_device
   189		 * and invokes .add function
   190		 */
   191		result = acpi_bus_scan(handle);
   192		if (result) {
   193			pr_warn(PREFIX "Cannot add acpi bus\n");
   194			return -EINVAL;
   195		}
   196	
   197	end:
   198		*mem_device = acpi_driver_data(device);
                                               ^^^^^^
Dereference.

   199		if (!(*mem_device)) {
   200			pr_err(PREFIX "Driver data not found\n");

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 Feb 15 14:18:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6M6r-0007zM-9v; Fri, 15 Feb 2013 14:17:53 +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 1U6M6p-0007zH-Ly
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:17:51 +0000
Received: from [193.109.254.147:51389] by server-7.bemta-14.messagelabs.com id
	D6/D4-13581-E834E115; Fri, 15 Feb 2013 14:17:50 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1360937860!821988!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29584 invoked from network); 15 Feb 2013 14:17:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 14:17:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FEHa6r012418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 14:17:37 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
	r1FEHZSP023140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 14:17:36 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
	r1FEHZHX015714; Fri, 15 Feb 2013 08:17:35 -0600
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 06:17:34 -0800
Date: Fri, 15 Feb 2013 17:17:28 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: jinsong.liu@intel.com
Message-ID: <20130215141728.GA27966@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kbuild@01.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] xen/acpi: ACPI memory hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Liu Jinsong,

This is a semi-automatic email about new static checker warnings.

The patch 259f201cb7ea: "xen/acpi: ACPI memory hotplug" from Jan 24, 
2013, leads to the following Smatch complaint:

drivers/xen/xen-acpi-memhotplug.c:198 acpi_memory_get_device()
	 error: we previously assumed 'device' could be null (see line 171)

drivers/xen/xen-acpi-memhotplug.c
   170	
   171		if (!acpi_bus_get_device(handle, &device) && device)
                                                             ^^^^^^
New check.

Btw, checking device is unnecessary.

		if (acpi_bus_get_device(handle, &device) == 0)
			goto end;

A successful "Get Device" means that "device" is non-NULL; that's built
into the name.  Anyway, if acpi_bus_get_device() fails either something
else will fail or we will Oops in the call to acpi_driver_data().

   172			goto end;
   173	
   174		status = acpi_get_parent(handle, &phandle);
   175		if (ACPI_FAILURE(status)) {
   176			pr_warn(PREFIX "Cannot find acpi parent\n");
   177			return -EINVAL;
   178		}
   179	
   180		/* Get the parent device */
   181		result = acpi_bus_get_device(phandle, &pdevice);
   182		if (result) {
   183			pr_warn(PREFIX "Cannot get acpi bus device\n");
   184			return -EINVAL;
   185		}
   186	
   187		/*
   188		 * Now add the notified device.  This creates the acpi_device
   189		 * and invokes .add function
   190		 */
   191		result = acpi_bus_scan(handle);
   192		if (result) {
   193			pr_warn(PREFIX "Cannot add acpi bus\n");
   194			return -EINVAL;
   195		}
   196	
   197	end:
   198		*mem_device = acpi_driver_data(device);
                                               ^^^^^^
Dereference.

   199		if (!(*mem_device)) {
   200			pr_err(PREFIX "Driver data not found\n");

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 Feb 15 14:18:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:18: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 1U6M77-00080f-O4; Fri, 15 Feb 2013 14:18:09 +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 1U6M76-00080U-Hg
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:18:08 +0000
Received: from [85.158.137.99:26165] by server-16.bemta-3.messagelabs.com id
	0D/46-02727-F934E115; Fri, 15 Feb 2013 14:18:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360937885!21599330!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24295 invoked from network); 15 Feb 2013 14:18:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:18: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.297.1; Fri, 15 Feb 2013 14:18:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6M72-0005Vh-Ny; Fri, 15 Feb 2013 14:18:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6M72-0000ix-JC;
	Fri, 15 Feb 2013 14:18:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.17306.447484.975154@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:18:02 +0000
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CD4180FB.5ACFE%keir@xen.org>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<CD4180FB.5ACFE%keir@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fraser writes ("Re: Moving xen*.hg to git"):
> On 13/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > We have some background infrastructure work which needs to be complete
> > before we make this switch, but we are currently expecting/hoping this
> > to be ready next week.  We tentatively intend to make the switch on
> > Thursday the 13th of February, assuming none of the committers object.
> 
> Do you mean 14th Feb (tomorrow)?

No, I meant the 21st, next week.  I have no idea where "13th" came
from.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:18:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:18: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 1U6M77-00080f-O4; Fri, 15 Feb 2013 14:18:09 +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 1U6M76-00080U-Hg
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:18:08 +0000
Received: from [85.158.137.99:26165] by server-16.bemta-3.messagelabs.com id
	0D/46-02727-F934E115; Fri, 15 Feb 2013 14:18:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1360937885!21599330!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24295 invoked from network); 15 Feb 2013 14:18:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1517881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:18: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.297.1; Fri, 15 Feb 2013 14:18:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6M72-0005Vh-Ny; Fri, 15 Feb 2013 14:18:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6M72-0000ix-JC;
	Fri, 15 Feb 2013 14:18:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.17306.447484.975154@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:18:02 +0000
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CD4180FB.5ACFE%keir@xen.org>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<CD4180FB.5ACFE%keir@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fraser writes ("Re: Moving xen*.hg to git"):
> On 13/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > We have some background infrastructure work which needs to be complete
> > before we make this switch, but we are currently expecting/hoping this
> > to be ready next week.  We tentatively intend to make the switch on
> > Thursday the 13th of February, assuming none of the committers object.
> 
> Do you mean 14th Feb (tomorrow)?

No, I meant the 21st, next week.  I have no idea where "13th" came
from.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:20:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6M9a-0008CJ-AM; Fri, 15 Feb 2013 14:20: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 1U6M9Y-0008C8-U4
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:20:41 +0000
Received: from [85.158.138.51:49863] by server-9.bemta-3.messagelabs.com id
	0F/3B-09484-4344E115; Fri, 15 Feb 2013 14:20:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360938031!9050479!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16474 invoked from network); 15 Feb 2013 14:20:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:20: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.297.1; Fri, 15 Feb 2013 14:20:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6M9O-0005WS-JZ; Fri, 15 Feb 2013 14:20:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6M9O-0000kJ-Ej;
	Fri, 15 Feb 2013 14:20:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.17454.228231.256868@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:20:30 +0000
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CD4182B1.5ACFF%keir@xen.org>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<CD4182B1.5ACFF%keir@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fraser writes ("Re: Moving xen*.hg to git"):
> On 13/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > It has a branch corresponding to each xen*.hg tree:
> >   master                xen-unstable.hg
> >   stable-4.0            xen-4.0-testing.hg
> >   stable-4.1            xen-4.1-testing.hg
> >   stable-4.2            xen-4.2-testing.hg
> 
> Is it possible to make these branches unpushable by committers?

I think so, with a pre-receive hook as described in git-receive-pack.
(This wouldn't prevent someone deliberately bypassing the check, but
it would stop accidents.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:20:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6M9a-0008CJ-AM; Fri, 15 Feb 2013 14:20: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 1U6M9Y-0008C8-U4
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:20:41 +0000
Received: from [85.158.138.51:49863] by server-9.bemta-3.messagelabs.com id
	0F/3B-09484-4344E115; Fri, 15 Feb 2013 14:20:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1360938031!9050479!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16474 invoked from network); 15 Feb 2013 14:20:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:20: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.297.1; Fri, 15 Feb 2013 14:20:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6M9O-0005WS-JZ; Fri, 15 Feb 2013 14:20:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6M9O-0000kJ-Ej;
	Fri, 15 Feb 2013 14:20:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.17454.228231.256868@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:20:30 +0000
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CD4182B1.5ACFF%keir@xen.org>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<CD4182B1.5ACFF%keir@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fraser writes ("Re: Moving xen*.hg to git"):
> On 13/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > It has a branch corresponding to each xen*.hg tree:
> >   master                xen-unstable.hg
> >   stable-4.0            xen-4.0-testing.hg
> >   stable-4.1            xen-4.1-testing.hg
> >   stable-4.2            xen-4.2-testing.hg
> 
> Is it possible to make these branches unpushable by committers?

I think so, with a pre-receive hook as described in git-receive-pack.
(This wouldn't prevent someone deliberately bypassing the check, but
it would stop accidents.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:24:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6MDQ-0008Sw-0f; Fri, 15 Feb 2013 14:24: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 1U6MDO-0008Sq-Fi
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:24:38 +0000
Received: from [193.109.254.147:29276] by server-15.bemta-14.messagelabs.com
	id 74/64-24599-5254E115; Fri, 15 Feb 2013 14:24:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360938228!8577639!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32426 invoked from network); 15 Feb 2013 14:23:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:23: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.297.1; Fri, 15 Feb 2013 14:23:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6MCa-0005XY-FK; Fri, 15 Feb 2013 14:23:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6MCa-0000ke-BZ;
	Fri, 15 Feb 2013 14:23:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.17652.261781.486865@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:23:48 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1360780340-19117-2-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
	<1360780340-19117-2-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] libxl_json: Export json_object
	related 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

Alex Bligh writes ("[PATCH 01/11] libxl_json: Export json_object related function."):
> Export libxl__json_object_alloc and libxl__json_object_append_to to
> use them in a later patch.
> 
> Backported from xen-unstable patch:
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693129 -3600
> : Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
> : Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>

Thanks for this.

Unfortunately you have dropped the acks that I posted in response to
your previous series.  That makes it hard to see where to focus review
effort and to see what state the series is in.

Also, I see you have this in git.  Would it be possible for you to
publish your git branch somewhere ?  That will make the patch
shoveling a lot easier.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:24:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6MDQ-0008Sw-0f; Fri, 15 Feb 2013 14:24: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 1U6MDO-0008Sq-Fi
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:24:38 +0000
Received: from [193.109.254.147:29276] by server-15.bemta-14.messagelabs.com
	id 74/64-24599-5254E115; Fri, 15 Feb 2013 14:24:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360938228!8577639!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32426 invoked from network); 15 Feb 2013 14:23:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:23:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:23: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.297.1; Fri, 15 Feb 2013 14:23:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6MCa-0005XY-FK; Fri, 15 Feb 2013 14:23:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6MCa-0000ke-BZ;
	Fri, 15 Feb 2013 14:23:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.17652.261781.486865@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:23:48 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1360780340-19117-2-git-send-email-alex@alex.org.uk>
References: <1360780340-19117-1-git-send-email-alex@alex.org.uk>
	<1360780340-19117-2-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] libxl_json: Export json_object
	related 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

Alex Bligh writes ("[PATCH 01/11] libxl_json: Export json_object related function."):
> Export libxl__json_object_alloc and libxl__json_object_append_to to
> use them in a later patch.
> 
> Backported from xen-unstable patch:
> : User Anthony PERARD <anthony.perard@citrix.com>
> : Date 1349693129 -3600
> : Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
> : Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>

Thanks for this.

Unfortunately you have dropped the acks that I posted in response to
your previous series.  That makes it hard to see where to focus review
effort and to see what state the series is in.

Also, I see you have this in git.  Would it be possible for you to
publish your git branch somewhere ?  That will make the patch
shoveling a lot easier.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:29:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6MHh-0000Ca-St; Fri, 15 Feb 2013 14:29:05 +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 1U6MHg-0000CT-1b
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:29:04 +0000
Received: from [85.158.139.83:27959] by server-6.bemta-5.messagelabs.com id
	23/AB-01489-F264E115; Fri, 15 Feb 2013 14:29:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360938397!23191599!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 15 Feb 2013 14:26:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:26:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:26: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.297.1;
	Fri, 15 Feb 2013 14:26:17 +0000
Message-ID: <1360938376.31407.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 15 Feb 2013 14:26:16 +0000
In-Reply-To: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 1 of 2] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 19:29 +0000, Andrew Cooper wrote:
> There are two problems with this function:
>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>     compete for use of the static ring[] buffer.
>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>     more of its console ring.
> 
> Unfortunately, fixing the code in a sensible is rather difficult.  The Ocaml
> caller expects to get the entire console ring in a single buffer.  There are
> no mechanisms to ask Xen for the size of the console ring (which is fixed
> after boot).

It would be easy to add a sysctl to get this

>   Even if there was a way to get the size of the console ring, the
> XEN_SYSCTL_readconsole hypercall itself races with printk(), leading to
> possibly discontinuities if the ring is full.

Right, that one is tricky, but as you say we could accept the
inefficiencies here.

>   The requirement for a NULL
> terminating string means that a full console ring will appear to fail when use
> the correct power of two, forcing us to double up again.

Double? Or just allocate buffersize + 1? We could also consider fixing
the XEN_SYSCTL_readconsole interface to remove this issue.

> Furthermore, libxc will bounce the allocated buffer, as will caml_copy_string().

You could avoid the first of these by using xc_hypercall_buffer_alloc or
xc_hypercall_buffer_alloc_pages in the caller, these are exposed from
libxc exactly to allow us to avoid bouncing of larger objects.


> On the other hand, this is very definitely for debugging and testing, so lets
> do the best we can to get the entire buffer, and accept the inefficiencies.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 63594ce1708f -r 1daa30509f1c tools/ocaml/libs/xc/xenctrl_stubs.c
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -523,27 +523,55 @@ CAMLprim value stub_xc_evtchn_reset(valu
>  	CAMLreturn(Val_unit);
>  }
>  
> -
> -#define RING_SIZE 32768
> -static char ring[RING_SIZE];
> -
> +/* Maximum size of console ring we are prepared to read, 16MB */
> +#define MAX_CONSOLE_RING_SIZE (1U << 24)
>  CAMLprim value stub_xc_readconsolering(value xch)
>  {
> -	unsigned int size = RING_SIZE - 1;
> -	char *ring_ptr = ring;
> -	int retval;
> +	/* 32K starting size (adj for loop doubling at start) */
> +	unsigned int ring_size = 1U << 14;
> +	unsigned int nr_chars = ring_size;
> +	char * ring = NULL;
> +	int r;
>  
>  	CAMLparam1(xch);
> +	CAMLlocal1(conring);
>  
> -	caml_enter_blocking_section();
> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
> -	caml_leave_blocking_section();
> +	do
> +	{
> +		ring_size *= 2;
> +		if ( ring_size > MAX_CONSOLE_RING_SIZE )
> +		{
> +			caml_failwith("Console ring too large");
> +			CAMLreturn(Val_unit);
> +		}
> +		nr_chars = ring_size;
>  
> -	if (retval)
> -		failwith_xc(_H(xch));
> +		free(ring);
> +		if ( ! ( ring = malloc(ring_size) ) )
> +		{
> +			caml_failwith("Out of memory");
> +			CAMLreturn(Val_unit);
> +		}
>  
> -	ring[size] = '\0';
> -	CAMLreturn(caml_copy_string(ring));
> +		caml_enter_blocking_section();
> +		r = xc_readconsolering(_H(xch), ring, &nr_chars, 0, 0, NULL);
> +		caml_leave_blocking_section();
> +
> +		if ( r )
> +		{
> +			failwith_xc(_H(xch));
> +			free(ring);
> +			CAMLreturn(Val_unit);
> +		}
> +
> +		/* If nr_chars == ring_size, we have not read the entire ring.
> +		 * Try again with a larger buffer. */
> +	} while ( nr_chars >= ring_size );
> +
> +	ring[nr_chars] = '\0';
> +	conring = caml_copy_string(ring);
> +	free(ring);
> +	CAMLreturn(conring);
>  }
>  
>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:29:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6MHh-0000Ca-St; Fri, 15 Feb 2013 14:29:05 +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 1U6MHg-0000CT-1b
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:29:04 +0000
Received: from [85.158.139.83:27959] by server-6.bemta-5.messagelabs.com id
	23/AB-01489-F264E115; Fri, 15 Feb 2013 14:29:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1360938397!23191599!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 15 Feb 2013 14:26:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:26:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:26: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.297.1;
	Fri, 15 Feb 2013 14:26:17 +0000
Message-ID: <1360938376.31407.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 15 Feb 2013 14:26:16 +0000
In-Reply-To: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 1 of 2] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 19:29 +0000, Andrew Cooper wrote:
> There are two problems with this function:
>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>     compete for use of the static ring[] buffer.
>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>     more of its console ring.
> 
> Unfortunately, fixing the code in a sensible is rather difficult.  The Ocaml
> caller expects to get the entire console ring in a single buffer.  There are
> no mechanisms to ask Xen for the size of the console ring (which is fixed
> after boot).

It would be easy to add a sysctl to get this

>   Even if there was a way to get the size of the console ring, the
> XEN_SYSCTL_readconsole hypercall itself races with printk(), leading to
> possibly discontinuities if the ring is full.

Right, that one is tricky, but as you say we could accept the
inefficiencies here.

>   The requirement for a NULL
> terminating string means that a full console ring will appear to fail when use
> the correct power of two, forcing us to double up again.

Double? Or just allocate buffersize + 1? We could also consider fixing
the XEN_SYSCTL_readconsole interface to remove this issue.

> Furthermore, libxc will bounce the allocated buffer, as will caml_copy_string().

You could avoid the first of these by using xc_hypercall_buffer_alloc or
xc_hypercall_buffer_alloc_pages in the caller, these are exposed from
libxc exactly to allow us to avoid bouncing of larger objects.


> On the other hand, this is very definitely for debugging and testing, so lets
> do the best we can to get the entire buffer, and accept the inefficiencies.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 63594ce1708f -r 1daa30509f1c tools/ocaml/libs/xc/xenctrl_stubs.c
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -523,27 +523,55 @@ CAMLprim value stub_xc_evtchn_reset(valu
>  	CAMLreturn(Val_unit);
>  }
>  
> -
> -#define RING_SIZE 32768
> -static char ring[RING_SIZE];
> -
> +/* Maximum size of console ring we are prepared to read, 16MB */
> +#define MAX_CONSOLE_RING_SIZE (1U << 24)
>  CAMLprim value stub_xc_readconsolering(value xch)
>  {
> -	unsigned int size = RING_SIZE - 1;
> -	char *ring_ptr = ring;
> -	int retval;
> +	/* 32K starting size (adj for loop doubling at start) */
> +	unsigned int ring_size = 1U << 14;
> +	unsigned int nr_chars = ring_size;
> +	char * ring = NULL;
> +	int r;
>  
>  	CAMLparam1(xch);
> +	CAMLlocal1(conring);
>  
> -	caml_enter_blocking_section();
> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
> -	caml_leave_blocking_section();
> +	do
> +	{
> +		ring_size *= 2;
> +		if ( ring_size > MAX_CONSOLE_RING_SIZE )
> +		{
> +			caml_failwith("Console ring too large");
> +			CAMLreturn(Val_unit);
> +		}
> +		nr_chars = ring_size;
>  
> -	if (retval)
> -		failwith_xc(_H(xch));
> +		free(ring);
> +		if ( ! ( ring = malloc(ring_size) ) )
> +		{
> +			caml_failwith("Out of memory");
> +			CAMLreturn(Val_unit);
> +		}
>  
> -	ring[size] = '\0';
> -	CAMLreturn(caml_copy_string(ring));
> +		caml_enter_blocking_section();
> +		r = xc_readconsolering(_H(xch), ring, &nr_chars, 0, 0, NULL);
> +		caml_leave_blocking_section();
> +
> +		if ( r )
> +		{
> +			failwith_xc(_H(xch));
> +			free(ring);
> +			CAMLreturn(Val_unit);
> +		}
> +
> +		/* If nr_chars == ring_size, we have not read the entire ring.
> +		 * Try again with a larger buffer. */
> +	} while ( nr_chars >= ring_size );
> +
> +	ring[nr_chars] = '\0';
> +	conring = caml_copy_string(ring);
> +	free(ring);
> +	CAMLreturn(conring);
>  }
>  
>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:30:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6MJ7-0000HX-Ci; Fri, 15 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U6MJ6-0000HN-B5
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:30:32 +0000
Received: from [85.158.143.99:48992] by server-1.bemta-4.messagelabs.com id
	FE/F9-08839-7864E115; Fri, 15 Feb 2013 14:30:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360938629!27215444!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19611 invoked from network); 15 Feb 2013 14:30:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:30:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:30: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.297.1;
	Fri, 15 Feb 2013 14:30:30 +0000
Message-ID: <1360938628.31407.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 14:30:28 +0000
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v7 0/5] xen: ARM HDLCD video 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, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:

> Stefano Stabellini (5):
>       xen: introduce a generic framebuffer driver
>       xen/arm: introduce a driver for the ARM HDLCD controller

I've now applied these as well, with the fixes to the first as
previously discussed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:30:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14: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 1U6MJ7-0000HX-Ci; Fri, 15 Feb 2013 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 <Ian.Campbell@citrix.com>) id 1U6MJ6-0000HN-B5
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:30:32 +0000
Received: from [85.158.143.99:48992] by server-1.bemta-4.messagelabs.com id
	FE/F9-08839-7864E115; Fri, 15 Feb 2013 14:30:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360938629!27215444!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19611 invoked from network); 15 Feb 2013 14:30:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:30:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:30: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.297.1;
	Fri, 15 Feb 2013 14:30:30 +0000
Message-ID: <1360938628.31407.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 14:30:28 +0000
In-Reply-To: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302141727250.8231@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v7 0/5] xen: ARM HDLCD video 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, 2013-02-14 at 17:30 +0000, Stefano Stabellini wrote:

> Stefano Stabellini (5):
>       xen: introduce a generic framebuffer driver
>       xen/arm: introduce a driver for the ARM HDLCD controller

I've now applied these as well, with the fixes to the first as
previously discussed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:31:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:31: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 1U6MKH-0000Pu-RK; Fri, 15 Feb 2013 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 1U6MKG-0000Ph-Dv
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:31:44 +0000
Received: from [85.158.143.99:58148] by server-3.bemta-4.messagelabs.com id
	3B/1F-08920-FC64E115; Fri, 15 Feb 2013 14:31:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360938466!18073277!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9774 invoked from network); 15 Feb 2013 14:27:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:27: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.297.1;
	Fri, 15 Feb 2013 14:27:47 +0000
Message-ID: <1360938465.31407.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 15 Feb 2013 14:27:45 +0000
In-Reply-To: <39ae53386eb2ef675ce0.1360870152@andrewcoop.uk.xensource.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
	<39ae53386eb2ef675ce0.1360870152@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 2 of 2] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 19:29 +0000, Andrew Cooper wrote:
> The static error_str[] buffer is not thread-safe, and 1024 bytes is
> unreasonably large.  Reduce to 256 bytes (which is still much larger than any
> current use), and move it to being a stack variable.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Looks plausible to me, but please could you cc xen-api@ for ocaml
changes so someone who knows ocaml can comment.

> 
> diff -r 1daa30509f1c -r 39ae53386eb2 tools/ocaml/libs/xc/xenctrl_stubs.c
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -51,21 +51,22 @@
>  	i1 = (uint32_t) Int64_val(Field(input, 0)); \
>  	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
>  
> -#define ERROR_STRLEN 1024
>  void failwith_xc(xc_interface *xch)
>  {
> -	static char error_str[ERROR_STRLEN];
> +	char error_str[256];
>  	if (xch) {
>  		const xc_error *error = xc_get_last_error(xch);
>  		if (error->code == XC_ERROR_NONE)
> -                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
> +                	snprintf(error_str, sizeof(error_str),
> +				 "%d: %s", errno, strerror(errno));
>  		else
> -			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
> -				 error->code,
> +			snprintf(error_str, sizeof(error_str),
> +				 "%d: %s: %s", error->code,
>  				 xc_error_code_to_desc(error->code),
>  				 error->message);
>  	} else {
> -		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
> +		snprintf(error_str, sizeof(error_str),
> +			 "Unable to open XC interface");
>  	}
>  	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:31:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:31: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 1U6MKH-0000Pu-RK; Fri, 15 Feb 2013 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 1U6MKG-0000Ph-Dv
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:31:44 +0000
Received: from [85.158.143.99:58148] by server-3.bemta-4.messagelabs.com id
	3B/1F-08920-FC64E115; Fri, 15 Feb 2013 14:31:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360938466!18073277!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9774 invoked from network); 15 Feb 2013 14:27:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:27: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.297.1;
	Fri, 15 Feb 2013 14:27:47 +0000
Message-ID: <1360938465.31407.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri, 15 Feb 2013 14:27:45 +0000
In-Reply-To: <39ae53386eb2ef675ce0.1360870152@andrewcoop.uk.xensource.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
	<39ae53386eb2ef675ce0.1360870152@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 2 of 2] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-14 at 19:29 +0000, Andrew Cooper wrote:
> The static error_str[] buffer is not thread-safe, and 1024 bytes is
> unreasonably large.  Reduce to 256 bytes (which is still much larger than any
> current use), and move it to being a stack variable.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Looks plausible to me, but please could you cc xen-api@ for ocaml
changes so someone who knows ocaml can comment.

> 
> diff -r 1daa30509f1c -r 39ae53386eb2 tools/ocaml/libs/xc/xenctrl_stubs.c
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -51,21 +51,22 @@
>  	i1 = (uint32_t) Int64_val(Field(input, 0)); \
>  	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
>  
> -#define ERROR_STRLEN 1024
>  void failwith_xc(xc_interface *xch)
>  {
> -	static char error_str[ERROR_STRLEN];
> +	char error_str[256];
>  	if (xch) {
>  		const xc_error *error = xc_get_last_error(xch);
>  		if (error->code == XC_ERROR_NONE)
> -                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
> +                	snprintf(error_str, sizeof(error_str),
> +				 "%d: %s", errno, strerror(errno));
>  		else
> -			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
> -				 error->code,
> +			snprintf(error_str, sizeof(error_str),
> +				 "%d: %s: %s", error->code,
>  				 xc_error_code_to_desc(error->code),
>  				 error->message);
>  	} else {
> -		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
> +		snprintf(error_str, sizeof(error_str),
> +			 "Unable to open XC interface");
>  	}
>  	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:32:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:32: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 1U6MKf-0000Sg-8g; Fri, 15 Feb 2013 14:32: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 1U6MKd-0000SP-J1
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:32:07 +0000
Received: from [193.109.254.147:31720] by server-9.bemta-14.messagelabs.com id
	85/17-30867-6E64E115; Fri, 15 Feb 2013 14:32:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360938716!8525856!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20599 invoked from network); 15 Feb 2013 14:31:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:31:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:30: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.297.1;
	Fri, 15 Feb 2013 14:30:56 +0000
Message-ID: <1360938654.31407.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Fri, 15 Feb 2013 14:30:54 +0000
In-Reply-To: <1360147112-7003-1-git-send-email-fantonifabio@tiscali.it>
References: <1360147112-7003-1-git-send-email-fantonifabio@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RESEND] tools/libxl: Disable useless empty
 floppy drive with 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

On Wed, 2013-02-06 at 10:38 +0000, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Applied with Stefano's  ack, thanks.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:32:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:32: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 1U6MKf-0000Sg-8g; Fri, 15 Feb 2013 14:32: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 1U6MKd-0000SP-J1
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:32:07 +0000
Received: from [193.109.254.147:31720] by server-9.bemta-14.messagelabs.com id
	85/17-30867-6E64E115; Fri, 15 Feb 2013 14:32:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360938716!8525856!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20599 invoked from network); 15 Feb 2013 14:31:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:31:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="1518417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:30: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.297.1;
	Fri, 15 Feb 2013 14:30:56 +0000
Message-ID: <1360938654.31407.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Fri, 15 Feb 2013 14:30:54 +0000
In-Reply-To: <1360147112-7003-1-git-send-email-fantonifabio@tiscali.it>
References: <1360147112-7003-1-git-send-email-fantonifabio@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RESEND] tools/libxl: Disable useless empty
 floppy drive with 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

On Wed, 2013-02-06 at 10:38 +0000, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

Applied with Stefano's  ack, thanks.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:32:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6ML7-0000Wp-MG; Fri, 15 Feb 2013 14:32:37 +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 1U6ML5-0000WO-6N
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:32:35 +0000
Received: from [85.158.139.211:57853] by server-15.bemta-5.messagelabs.com id
	9E/CD-18914-2074E115; Fri, 15 Feb 2013 14:32:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360938751!22368785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17530 invoked from network); 15 Feb 2013 14:32:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:32:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7683515"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 14:32:31 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 09:32:30 -0500
Message-ID: <511E46FD.3010605@citrix.com>
Date: Fri, 15 Feb 2013 14:32:29 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Here is a design for a FIFO-based event channel ABI for Xen.  It has a
number of benefits over the 3-level design currently being proposed by
Wei Liu.

* The use of FIFOs for events ensures fairness.
* 16 event priorities.
* The same ABI regardless of the native word size (a 32-bit or 64-bit
hypervisor provides the same ABI to both 32 and 64-bit guests).
* Reduced memory requirements (only 1 additional page per domU).
* Room for even more event channels with trivial ABI changes.

This is an update from the original draft A and includes clarifications
and corrections for almost all the comments received so far.  The key
changes are summarized in the beginning of the document.

Except for a lack of information of the required memory barriers (to be
included in draft C), this should now be completely enough to start on a
prototype (any volunteers? ;).

The PDF version is easier to read and has diagrams and readable maths
but the original markdown format document is included below (for ease of
commenting).

http://xenbits.xen.org/people/dvrabel/event-channels-B.pdf

Introduction
============

Revision History
----------------

--------------------------------------------------------------------
Version  Date         Changes
-------  -----------  ----------------------------------------------
Draft A  4 Feb 2013   Initial draft.

Draft B  15 Feb 2013  Clarified that the event array is per-domain.

                      Control block is no longer part of the vcpu_info
                      but does reside in the same page.

                      Hypercall changes: structures are now 32/64-bit
                      clean, added notes on handling failures,
                      `expand_array` has its `vcpu` field removed,
                      use `expand_array` to add first page.

                      Added an upcall section.

                      Added a READY field to the control block to make
                      finding the highest priority non-empty event
                      queue more efficient.

                      Note that memory barriers will be required but
                      leave the details to a future draft.
--------------------------------------------------------------------


Purpose
-------

Xen uses event channels to signal events (interrupts) to (fully or
partially) paravirtualized guests.  The current event channel ABI
provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
(for 64-bit guests) event channels.  This is limiting scalability as
support for more VMs, VCPUs and devices is required.

Events also cannot be serviced fairly as information on the ordering
of events is lost.  This can result in events from some VMs
experiencing (potentially significantly) longer than average latency.

The existing ABI does not easily allow events to have different
priorities.  Current Linux kernels prioritize the timer event by
special casing this but this is not generalizable to more events.
Event priorities may be useful for prioritizing MMIO emulation
requests over bulk data traffic (such as network or disk).

This design replaces the existing event channel ABI with one that:

- is scalable to more than 100,000 event channels, with scope for
increasing this further with minimal ABI changes.

- allows events to be serviced fairly.

- allows guests to use up-to 16 different event priorities.

- has an ABI that is the same regardless of the natural word size.

System Overview
---------------

[FIXME: diagram showing Xen and guest and shared memory block for events?]

Design Map
----------

A new event channel ABI requires changes to Xen and the guest kernels.

References
----------

[FIXME: link to alternate proposal?]

Design Considerations
=====================

Assumptions
-----------

* Atomic read-modify-write of 32-bit words is possible on all
  supported platforms.  This can be with a linked-load /
  store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
  (e.g., x86's cmpxchg).

Constraints
-----------

* The existing ABI must continue to be useable.  Compatibilty with
  existing guests is mandatory.

Risks and Volatile Areas
------------------------

* Should the 3-level proposal be merged into Xen then this design does
  not offer enough improvements to warrant the cost of maintaining
  three different event channel ABIs in Xen and guest kernels.

* The performance of some operations may be decreased.  Specifically,
  retriggering an event now always requires a hypercall.

Architecture
============

Overview
--------

The event channel ABI uses a data structure that is shared between Xen
and the guest.  Access to the structure is done with lock-less
operations (except for some less common operations where the guest
must use a hypercall).  The guest is responsible for allocating this
structure and registering it with Xen during VCPU bring-up.

Events are reported to a guest's VCPU using a FIFO _event queue_.
There is a queue for each priority level and each VCPU.

Each event has a _pending_ and a _masked_ bit.  The pending bit
indicates the event has been raised.  The masked bit is used by the
guest to prevent delivery of that specific event.


High Level Design
=================

Shared Event Data Structure
---------------------------

The shared event data structure has a per-domain _event array_, and a
per-VCPU _control block_.

- _event array_: A logical array of _event words_ (one per event
  channel) which contains the pending and mask bits and the link index
  for next event in the queue.  The event array is shared between all
  of the guest's VCPUs.

- _control block_: This contains the meta data for the event
  queues: the _ready bits_ and the _head index_ and _tail index_ for
  each priority level.  Each VCPU has its own control block and this
  is contained in the same page as the existing `struct vcpu_info`.

### Event Array

![\label{fig_event-word}Event Array Word](event-word.pdf)

The pages within the event array need not be physically nor virtually
contiguous, but the guest or Xen may make the virtually contiguous for
ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
Linux.  Pages are added by the guest as required to accomodate the
event with the highest port number.

Only 17 bits are currently defined for the LINK field, allowing 2^17^
(131,072) events.  This limit can be trivially increased without any
other changes to the ABI.  Bits [28:17] are reserved for future
expansion or for other uses.

Instead of the L bit, a magic value for the LINK field could be used
to indicate whether an event is in a queue.  However, using the L bit
has two advantages: a) the guest may clear it with a single bit clear
operation; and b) it does not require changing a magic value if the
size of the LINK field changes.

### Control Block

![\label{fig_control-block}Control Block](control-block.pdf)

The READY field contains a bit for each priority's queue.  A set bit
indicates that there are events pending on that queue.  A queue's
ready bit is set by Xen when an event is placed on an empty queue and
cleared by the guest when it empties the queue.

There are N HEAD and TAIL indexes, one for each priority.

The HEAD index is the first event in the queue or zero if the queue is
empty.  HEAD is set by the guest as it consumes events and only set by
Xen when adding an event to an empty queue.

The TAIL index is the last event in the queue.  It is undefined if the
queue is empty.  TAIL is only set by Xen.

Event State Machine
-------------------

Event channels are bound to a port in the domain using the existing
ABI.

A bound event may be in one of three main states.

State    Abbrev.  PML Bits  Meaning
-----    -------  --------  -------
BOUND    B        000       The event is bound but not pending.
PENDING  P        100       The event has been raised and not yet
acknowledged.
LINKED   L        101       The event is on an event queue.

Additionally, events may be UNMASKED or MASKED (M).

![\label{events_sm}Event State Machine](event-sm.pdf)

The state of an event is tracked using 3 bits within the event word:
the P (pending), M (masked), and L (linked) bits.  Only state
transitions that change a single bit are valid.

Event Queues
------------

The event queues use a singly-linked list of event array words (see
figure \ref{fig_event-word} and \ref{fig_event-queue}).  Each VCPU has
an event queues for each priority.

![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)

Each event queue has a head and tail index stored in the control
block.  The head index is the index of the first element in the queue.
The tail index is the last element in the queue.  Every element within
the queue has the L bit set.

The LINK field in the event word indexes the next event in the queue.
LINK is zero for the last word in the queue.

The queue is empty when the head index is zero (zero is not a valid
event channel).

Hypercalls
----------

Four new EVTCHNOP hypercall sub-operations are added:

* `EVTCHNOP_init_control`

* `EVTCHNOP_expand_array`

* `EVTCHNOP_set_priority`

* `EVTCHNOP_set_limit`

### `EVTCHNOP_init_control`

This call initializes a single VCPU's control block.

A guest should call this during initial VCPU bring up.  The guest must
have already successfully registered a vcpu_info structure and the
control block must be in the same page.

If this call fails on the boot VCPU, the guest should continue to use
the 2-level event channel ABI for all VCPUs.  If this call fails on
any non-boot VCPU then the VCPU will be unable to receive events and
the guest should offline the VCPU.

> Note: This only initializes the control block. At least one page
> needs to be added to the event arrary with `EVTCHNOP_expand_array`.

    struct evtchnop_init_control {
        uint64_t control_pfn;
        uint32_t offset;
        uint32_t vcpu;
    };

Field          Purpose
-----          -------
`control_pfn`  [in] The PFN or GMFN of the page containing the control
block.
`offset`       [in] Offset in bytes from the start of the page to the
beginning of the control block.
`vcpu`         [in] The VCPU number.

Error code  Reason
----------  ------
EINVAL      `vcpu` is invalid or already initialized.
EINVAL      `control_pfn` is not a valid frame for the domain.
EINVAL      `control_pfn` is not the same frame as the vcpu_info structure.
EINVAL      `offset` is not a multiple of 8 or the control block would
cross a page boundary.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_expand_array`

This call expands the event array by appending an additional page.

A guest should call this when a new event channel is required and
there is insufficient space in the current event array.

It is not possible to shrink the event array once it has been
expanded.

If this call fails, then subsequent attempts to bind event channels
may fail with -ENOSPC.  If the first page cannot be added then the
guest cannot receive any events and it should panic.

    struct evtchnop_expand_array {
        uint64_t array_pfn;
    };

Field          Purpose
-----          -------
`array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
               of the event array.

Error code  Reason
----------  ------
EINVAL      `array_pfn` is not a valid frame for the domain.
EINVAL      The event array already has the maximum number of pages.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_set_priority`

This call sets the priority for an event channel.  The event channel
may be bound or unbound.

The meaning and the use of the priority are up to the guest.  Valid
priorities are 0 - 15 and the default is 7.  0 is the highest
priority.

If the priority is changed on a bound event channel then at most one
event may be signalled at the previous priority.

    struct evtchnop_set_priority {
        uint32_t port;
        uint32_t priority;
    };

Field       Purpose
-----       -------
`port`      [in] The event channel.
`priority`  [in] The priority for the event channel.

Error code  Reason
----------  ------
EINVAL      `port` is invalid.
EINVAL      `priority` is outside the range 0 - 15.

### `EVTCHNOP_set_limit`

This privileged call sets the highest port number a domain can bind an
event channel to.  The default for dom0 is the maximum supported
($2^{17}-1$).  Other domains default to 1023 (requiring only a single
page for their event array).

The limit only affects future attempts to bind event channels.  Event
channels that are already bound are not affected.

It is recommended that the toolstack only calls this during domain
creation before the guest is started.

    struct evtchnop_set_limit {
        uint32_t domid;
        uint32_t max_port;
    };

Field       Purpose
-----       -------
`domid`     [in] The domain ID.
`max_port`  [in] The highest port number that the domain may bound an
event channel to.

Error code  Reason
----------  ------
EINVAL      `domid` is invalid.
EPERM       The calling domain has insufficient privileges.

Memory Usage
------------

### Event Arrays

Xen needs to map every domains' event array into its address space.
The space reserved for these global mappings is limited to 1 GiB on
x86-64 (262144 pages) and is shared with other users.

It is non-trivial to calculate the maximum number of VMs that can be
supported as this depends on the system configuration (how many driver
domains etc.) and VM configuration.  We can make some assuptions and
derive an approximate limit.

Each page of the event array has space for 1024 events ($E_P$) so a
regular domU will only require a single page.  Since event channels
have two ends, the upper bound on the total number of pages is $2
\times\text{number of VMs}$.

If the guests are further restricted in the number of event channels
($E_V$) then this upper bound can be reduced further.  By assuming
that each event event channel has one end in a domU and the other in
dom0 (or a small number of driver domains) then the ends in dom0 will
be packed together within the event array.

The number of VMs ($V$) with a limit of $P$ total event array pages is
approximately:
\begin{equation*}
V = P \div \left(1 + \frac{E_V}{E_P}\right)
\end{equation*}

Using only half the available pages and limiting guests to only 64
events gives:
\begin{eqnarray*}
V & = & (262144 / 2) \div (1 + 64 / 1024) \\
  & = & 123 \times 10^3\text{ VMs}
\end{eqnarray*}

Alternatively, we can consider a system with $D$ driver domains, each
of which requires $E_D$ events, and a dom0 using the maximum number of
pages (128).  The number of pages left over, hence the number of
guests is:
\begin{eqnarray*}
V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
\end{eqnarray*}

With, for example, 16 driver domains each using the maximum number of pages:
\begin{eqnarray*}
V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
   & = & 129 \times 10^3\text{ VMs}
\end{eqnarray*}

In summary, there is space to map the event arrays for over 100,000
VMs.  This is more than the limit imposed by the 16 bit domain ID
(~32,000 VMs).

### Control Block

With $L$ priority levels and two 32-bit words for the head and tail
indexes, the amount of space ($S$) required for the control block is:
\begin{eqnarray*}
S & = & L \times 2 \times 4 + 8 \\
  & = & 16 \times 2 \times 4 + 8\\
  & = & 136\text{ bytes}
\end{eqnarray*}

This allows the `struct vcpu_info` and the control block to
comfortably packed into a single page.


Low Level Design
================

In the pseudo code in this section, all memory accesses are atomic,
including those to bit-fields within the event word.  All memory
accesses are considered to be strongly ordered.  The required memory
barriers for real processors will be considered in a future draft.

The following variables are used for parts of the shared data
structures. Lowercase variables are local.

Variable  Purpose
--------  -------
E         Event array.
C         Per-VCPU control block.
H         Head index for a specific queue.
T         Tail index for a specific queue.

Raising an Event
----------------

When Xen raises an event it marks it pending and (if it is not masked)
adds it tail of event queue.

    E[p].pending = 1
    if not E[p].linked and not E[p].masked
        E[p].linked = 1
        E[p].link = 0
        if H == 0
            H = p
        else
            E[T].link = p
        T = p

Concurrent access by Xen to the event queue must be protected by a
per-event queue spin lock.

Consuming Events
----------------

The guest consumes events starting at the head until it reaches the
tail.  Events in the queue that are not pending or are masked are
consumed but not handled.

To consume a single event:

    p = H
    H = E[p].link
    if H == 0
        H = E[p].link
    E[p].linked = 0
    if not E[p].masked
        handle(p)

handle() clears `E[p].pending` and EOIs level-triggered PIRQs.

> Note: When the event queue contains a single event, removing the
> event may race with Xen appending another event because the load of
> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> the guest must recheck `E[p].link` if the list appeared empty.

Upcall
------

When Xen places an event on an empty queue it sets the queue as ready
in the control block.  If the ready bit transitions from 0 to 1, a new
event is signalled to the guest.

The guest uses the control block's ready field to find the highest
priority queue with pending events.  The bit in the ready word is
cleared when the queue is emptied.

Higher priority events do not need to preempt lower priority event
handlers so the guest can handle events by taking one event off the
currently ready queue with highest priority.

    r = C.ready
    while r
        q = find_first_set_bit(r)
        consume_one_event_from_queue(q)
        if C.queue[q].H == 0
            C.ready[q] = 0
            r[b] = 0
            if C.queue[q].H != 0
                C.ready[q] = 1
        r |= C.ready

> Note: The clear of the `C.ready[q]` bit may race with Xen placing
> another event on the queue.  After clearing the bit the queue must
> be checked again.

Since the upcall is reentrant the guest should ensure that nested
upcalls return immediately without processing any events.  A per-VCPU
nesting count may be used for this.

Masking Events
--------------

Events are masked by setting the masked bit.  If the event is pending
and linked it does not need to be unlinked.

    E[p].masked = 1

Unmasking Events
----------------

Events are unmasked by the guest by clearing the masked bit.  If the
event is pending the guest must call the event channel unmask
hypercall so Xen can link the event into the correct event queue.

    E[p].masked = 0
    if E[p].pending
        hypercall(EVTCHN_unmask)

The expectation here is that unmasking a pending event will be rare,
so the performance hit of the hypercall is minimal.

> Note: After clearing the mask bit, the event may be raised and thus
> it may already be linked by the time the hypercall is done.  The
> mask must be cleared before testing the pending bit to avoid racing
> with the event becoming pending.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:32:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6ML7-0000Wp-MG; Fri, 15 Feb 2013 14:32:37 +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 1U6ML5-0000WO-6N
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:32:35 +0000
Received: from [85.158.139.211:57853] by server-15.bemta-5.messagelabs.com id
	9E/CD-18914-2074E115; Fri, 15 Feb 2013 14:32:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1360938751!22368785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17530 invoked from network); 15 Feb 2013 14:32:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:32:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,673,1355097600"; 
   d="scan'208";a="7683515"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 14:32:31 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 09:32:30 -0500
Message-ID: <511E46FD.3010605@citrix.com>
Date: Fri, 15 Feb 2013 14:32:29 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Here is a design for a FIFO-based event channel ABI for Xen.  It has a
number of benefits over the 3-level design currently being proposed by
Wei Liu.

* The use of FIFOs for events ensures fairness.
* 16 event priorities.
* The same ABI regardless of the native word size (a 32-bit or 64-bit
hypervisor provides the same ABI to both 32 and 64-bit guests).
* Reduced memory requirements (only 1 additional page per domU).
* Room for even more event channels with trivial ABI changes.

This is an update from the original draft A and includes clarifications
and corrections for almost all the comments received so far.  The key
changes are summarized in the beginning of the document.

Except for a lack of information of the required memory barriers (to be
included in draft C), this should now be completely enough to start on a
prototype (any volunteers? ;).

The PDF version is easier to read and has diagrams and readable maths
but the original markdown format document is included below (for ease of
commenting).

http://xenbits.xen.org/people/dvrabel/event-channels-B.pdf

Introduction
============

Revision History
----------------

--------------------------------------------------------------------
Version  Date         Changes
-------  -----------  ----------------------------------------------
Draft A  4 Feb 2013   Initial draft.

Draft B  15 Feb 2013  Clarified that the event array is per-domain.

                      Control block is no longer part of the vcpu_info
                      but does reside in the same page.

                      Hypercall changes: structures are now 32/64-bit
                      clean, added notes on handling failures,
                      `expand_array` has its `vcpu` field removed,
                      use `expand_array` to add first page.

                      Added an upcall section.

                      Added a READY field to the control block to make
                      finding the highest priority non-empty event
                      queue more efficient.

                      Note that memory barriers will be required but
                      leave the details to a future draft.
--------------------------------------------------------------------


Purpose
-------

Xen uses event channels to signal events (interrupts) to (fully or
partially) paravirtualized guests.  The current event channel ABI
provided by Xen only supports up-to 1024 (for 32-bit guests) or 4096
(for 64-bit guests) event channels.  This is limiting scalability as
support for more VMs, VCPUs and devices is required.

Events also cannot be serviced fairly as information on the ordering
of events is lost.  This can result in events from some VMs
experiencing (potentially significantly) longer than average latency.

The existing ABI does not easily allow events to have different
priorities.  Current Linux kernels prioritize the timer event by
special casing this but this is not generalizable to more events.
Event priorities may be useful for prioritizing MMIO emulation
requests over bulk data traffic (such as network or disk).

This design replaces the existing event channel ABI with one that:

- is scalable to more than 100,000 event channels, with scope for
increasing this further with minimal ABI changes.

- allows events to be serviced fairly.

- allows guests to use up-to 16 different event priorities.

- has an ABI that is the same regardless of the natural word size.

System Overview
---------------

[FIXME: diagram showing Xen and guest and shared memory block for events?]

Design Map
----------

A new event channel ABI requires changes to Xen and the guest kernels.

References
----------

[FIXME: link to alternate proposal?]

Design Considerations
=====================

Assumptions
-----------

* Atomic read-modify-write of 32-bit words is possible on all
  supported platforms.  This can be with a linked-load /
  store-conditional (e.g., ARMv8's ldrx/strx) or a compare-and-swap
  (e.g., x86's cmpxchg).

Constraints
-----------

* The existing ABI must continue to be useable.  Compatibilty with
  existing guests is mandatory.

Risks and Volatile Areas
------------------------

* Should the 3-level proposal be merged into Xen then this design does
  not offer enough improvements to warrant the cost of maintaining
  three different event channel ABIs in Xen and guest kernels.

* The performance of some operations may be decreased.  Specifically,
  retriggering an event now always requires a hypercall.

Architecture
============

Overview
--------

The event channel ABI uses a data structure that is shared between Xen
and the guest.  Access to the structure is done with lock-less
operations (except for some less common operations where the guest
must use a hypercall).  The guest is responsible for allocating this
structure and registering it with Xen during VCPU bring-up.

Events are reported to a guest's VCPU using a FIFO _event queue_.
There is a queue for each priority level and each VCPU.

Each event has a _pending_ and a _masked_ bit.  The pending bit
indicates the event has been raised.  The masked bit is used by the
guest to prevent delivery of that specific event.


High Level Design
=================

Shared Event Data Structure
---------------------------

The shared event data structure has a per-domain _event array_, and a
per-VCPU _control block_.

- _event array_: A logical array of _event words_ (one per event
  channel) which contains the pending and mask bits and the link index
  for next event in the queue.  The event array is shared between all
  of the guest's VCPUs.

- _control block_: This contains the meta data for the event
  queues: the _ready bits_ and the _head index_ and _tail index_ for
  each priority level.  Each VCPU has its own control block and this
  is contained in the same page as the existing `struct vcpu_info`.

### Event Array

![\label{fig_event-word}Event Array Word](event-word.pdf)

The pages within the event array need not be physically nor virtually
contiguous, but the guest or Xen may make the virtually contiguous for
ease of implementation.  e.g., by using vmap() in Xen or vmalloc() in
Linux.  Pages are added by the guest as required to accomodate the
event with the highest port number.

Only 17 bits are currently defined for the LINK field, allowing 2^17^
(131,072) events.  This limit can be trivially increased without any
other changes to the ABI.  Bits [28:17] are reserved for future
expansion or for other uses.

Instead of the L bit, a magic value for the LINK field could be used
to indicate whether an event is in a queue.  However, using the L bit
has two advantages: a) the guest may clear it with a single bit clear
operation; and b) it does not require changing a magic value if the
size of the LINK field changes.

### Control Block

![\label{fig_control-block}Control Block](control-block.pdf)

The READY field contains a bit for each priority's queue.  A set bit
indicates that there are events pending on that queue.  A queue's
ready bit is set by Xen when an event is placed on an empty queue and
cleared by the guest when it empties the queue.

There are N HEAD and TAIL indexes, one for each priority.

The HEAD index is the first event in the queue or zero if the queue is
empty.  HEAD is set by the guest as it consumes events and only set by
Xen when adding an event to an empty queue.

The TAIL index is the last event in the queue.  It is undefined if the
queue is empty.  TAIL is only set by Xen.

Event State Machine
-------------------

Event channels are bound to a port in the domain using the existing
ABI.

A bound event may be in one of three main states.

State    Abbrev.  PML Bits  Meaning
-----    -------  --------  -------
BOUND    B        000       The event is bound but not pending.
PENDING  P        100       The event has been raised and not yet
acknowledged.
LINKED   L        101       The event is on an event queue.

Additionally, events may be UNMASKED or MASKED (M).

![\label{events_sm}Event State Machine](event-sm.pdf)

The state of an event is tracked using 3 bits within the event word:
the P (pending), M (masked), and L (linked) bits.  Only state
transitions that change a single bit are valid.

Event Queues
------------

The event queues use a singly-linked list of event array words (see
figure \ref{fig_event-word} and \ref{fig_event-queue}).  Each VCPU has
an event queues for each priority.

![\label{fig_event-queue}Empty and Non-empty Event Queues](event-queue.pdf)

Each event queue has a head and tail index stored in the control
block.  The head index is the index of the first element in the queue.
The tail index is the last element in the queue.  Every element within
the queue has the L bit set.

The LINK field in the event word indexes the next event in the queue.
LINK is zero for the last word in the queue.

The queue is empty when the head index is zero (zero is not a valid
event channel).

Hypercalls
----------

Four new EVTCHNOP hypercall sub-operations are added:

* `EVTCHNOP_init_control`

* `EVTCHNOP_expand_array`

* `EVTCHNOP_set_priority`

* `EVTCHNOP_set_limit`

### `EVTCHNOP_init_control`

This call initializes a single VCPU's control block.

A guest should call this during initial VCPU bring up.  The guest must
have already successfully registered a vcpu_info structure and the
control block must be in the same page.

If this call fails on the boot VCPU, the guest should continue to use
the 2-level event channel ABI for all VCPUs.  If this call fails on
any non-boot VCPU then the VCPU will be unable to receive events and
the guest should offline the VCPU.

> Note: This only initializes the control block. At least one page
> needs to be added to the event arrary with `EVTCHNOP_expand_array`.

    struct evtchnop_init_control {
        uint64_t control_pfn;
        uint32_t offset;
        uint32_t vcpu;
    };

Field          Purpose
-----          -------
`control_pfn`  [in] The PFN or GMFN of the page containing the control
block.
`offset`       [in] Offset in bytes from the start of the page to the
beginning of the control block.
`vcpu`         [in] The VCPU number.

Error code  Reason
----------  ------
EINVAL      `vcpu` is invalid or already initialized.
EINVAL      `control_pfn` is not a valid frame for the domain.
EINVAL      `control_pfn` is not the same frame as the vcpu_info structure.
EINVAL      `offset` is not a multiple of 8 or the control block would
cross a page boundary.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_expand_array`

This call expands the event array by appending an additional page.

A guest should call this when a new event channel is required and
there is insufficient space in the current event array.

It is not possible to shrink the event array once it has been
expanded.

If this call fails, then subsequent attempts to bind event channels
may fail with -ENOSPC.  If the first page cannot be added then the
guest cannot receive any events and it should panic.

    struct evtchnop_expand_array {
        uint64_t array_pfn;
    };

Field          Purpose
-----          -------
`array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
               of the event array.

Error code  Reason
----------  ------
EINVAL      `array_pfn` is not a valid frame for the domain.
EINVAL      The event array already has the maximum number of pages.
ENOMEM      Insufficient memory to allocate internal structures.

### `EVTCHNOP_set_priority`

This call sets the priority for an event channel.  The event channel
may be bound or unbound.

The meaning and the use of the priority are up to the guest.  Valid
priorities are 0 - 15 and the default is 7.  0 is the highest
priority.

If the priority is changed on a bound event channel then at most one
event may be signalled at the previous priority.

    struct evtchnop_set_priority {
        uint32_t port;
        uint32_t priority;
    };

Field       Purpose
-----       -------
`port`      [in] The event channel.
`priority`  [in] The priority for the event channel.

Error code  Reason
----------  ------
EINVAL      `port` is invalid.
EINVAL      `priority` is outside the range 0 - 15.

### `EVTCHNOP_set_limit`

This privileged call sets the highest port number a domain can bind an
event channel to.  The default for dom0 is the maximum supported
($2^{17}-1$).  Other domains default to 1023 (requiring only a single
page for their event array).

The limit only affects future attempts to bind event channels.  Event
channels that are already bound are not affected.

It is recommended that the toolstack only calls this during domain
creation before the guest is started.

    struct evtchnop_set_limit {
        uint32_t domid;
        uint32_t max_port;
    };

Field       Purpose
-----       -------
`domid`     [in] The domain ID.
`max_port`  [in] The highest port number that the domain may bound an
event channel to.

Error code  Reason
----------  ------
EINVAL      `domid` is invalid.
EPERM       The calling domain has insufficient privileges.

Memory Usage
------------

### Event Arrays

Xen needs to map every domains' event array into its address space.
The space reserved for these global mappings is limited to 1 GiB on
x86-64 (262144 pages) and is shared with other users.

It is non-trivial to calculate the maximum number of VMs that can be
supported as this depends on the system configuration (how many driver
domains etc.) and VM configuration.  We can make some assuptions and
derive an approximate limit.

Each page of the event array has space for 1024 events ($E_P$) so a
regular domU will only require a single page.  Since event channels
have two ends, the upper bound on the total number of pages is $2
\times\text{number of VMs}$.

If the guests are further restricted in the number of event channels
($E_V$) then this upper bound can be reduced further.  By assuming
that each event event channel has one end in a domU and the other in
dom0 (or a small number of driver domains) then the ends in dom0 will
be packed together within the event array.

The number of VMs ($V$) with a limit of $P$ total event array pages is
approximately:
\begin{equation*}
V = P \div \left(1 + \frac{E_V}{E_P}\right)
\end{equation*}

Using only half the available pages and limiting guests to only 64
events gives:
\begin{eqnarray*}
V & = & (262144 / 2) \div (1 + 64 / 1024) \\
  & = & 123 \times 10^3\text{ VMs}
\end{eqnarray*}

Alternatively, we can consider a system with $D$ driver domains, each
of which requires $E_D$ events, and a dom0 using the maximum number of
pages (128).  The number of pages left over, hence the number of
guests is:
\begin{eqnarray*}
V & = & P - \left(128 + D \times \frac{E_D}{E_P}\right)
\end{eqnarray*}

With, for example, 16 driver domains each using the maximum number of pages:
\begin{eqnarray*}
V  & = & (262144/2) - (128 + 16 \times \frac{2^{17}}{1024}) \\
   & = & 129 \times 10^3\text{ VMs}
\end{eqnarray*}

In summary, there is space to map the event arrays for over 100,000
VMs.  This is more than the limit imposed by the 16 bit domain ID
(~32,000 VMs).

### Control Block

With $L$ priority levels and two 32-bit words for the head and tail
indexes, the amount of space ($S$) required for the control block is:
\begin{eqnarray*}
S & = & L \times 2 \times 4 + 8 \\
  & = & 16 \times 2 \times 4 + 8\\
  & = & 136\text{ bytes}
\end{eqnarray*}

This allows the `struct vcpu_info` and the control block to
comfortably packed into a single page.


Low Level Design
================

In the pseudo code in this section, all memory accesses are atomic,
including those to bit-fields within the event word.  All memory
accesses are considered to be strongly ordered.  The required memory
barriers for real processors will be considered in a future draft.

The following variables are used for parts of the shared data
structures. Lowercase variables are local.

Variable  Purpose
--------  -------
E         Event array.
C         Per-VCPU control block.
H         Head index for a specific queue.
T         Tail index for a specific queue.

Raising an Event
----------------

When Xen raises an event it marks it pending and (if it is not masked)
adds it tail of event queue.

    E[p].pending = 1
    if not E[p].linked and not E[p].masked
        E[p].linked = 1
        E[p].link = 0
        if H == 0
            H = p
        else
            E[T].link = p
        T = p

Concurrent access by Xen to the event queue must be protected by a
per-event queue spin lock.

Consuming Events
----------------

The guest consumes events starting at the head until it reaches the
tail.  Events in the queue that are not pending or are masked are
consumed but not handled.

To consume a single event:

    p = H
    H = E[p].link
    if H == 0
        H = E[p].link
    E[p].linked = 0
    if not E[p].masked
        handle(p)

handle() clears `E[p].pending` and EOIs level-triggered PIRQs.

> Note: When the event queue contains a single event, removing the
> event may race with Xen appending another event because the load of
> `E[p].link` and the store of `H` is not atomic.  To avoid this race,
> the guest must recheck `E[p].link` if the list appeared empty.

Upcall
------

When Xen places an event on an empty queue it sets the queue as ready
in the control block.  If the ready bit transitions from 0 to 1, a new
event is signalled to the guest.

The guest uses the control block's ready field to find the highest
priority queue with pending events.  The bit in the ready word is
cleared when the queue is emptied.

Higher priority events do not need to preempt lower priority event
handlers so the guest can handle events by taking one event off the
currently ready queue with highest priority.

    r = C.ready
    while r
        q = find_first_set_bit(r)
        consume_one_event_from_queue(q)
        if C.queue[q].H == 0
            C.ready[q] = 0
            r[b] = 0
            if C.queue[q].H != 0
                C.ready[q] = 1
        r |= C.ready

> Note: The clear of the `C.ready[q]` bit may race with Xen placing
> another event on the queue.  After clearing the bit the queue must
> be checked again.

Since the upcall is reentrant the guest should ensure that nested
upcalls return immediately without processing any events.  A per-VCPU
nesting count may be used for this.

Masking Events
--------------

Events are masked by setting the masked bit.  If the event is pending
and linked it does not need to be unlinked.

    E[p].masked = 1

Unmasking Events
----------------

Events are unmasked by the guest by clearing the masked bit.  If the
event is pending the guest must call the event channel unmask
hypercall so Xen can link the event into the correct event queue.

    E[p].masked = 0
    if E[p].pending
        hypercall(EVTCHN_unmask)

The expectation here is that unmasking a pending event will be rare,
so the performance hit of the hypercall is minimal.

> Note: After clearing the mask bit, the event may be raised and thus
> it may already be linked by the time the hypercall is done.  The
> mask must be cleared before testing the pending bit to avoid racing
> with the event becoming pending.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:52:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:52: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 1U6Me0-0001A3-P4; Fri, 15 Feb 2013 14:52: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 1U6Mdz-00019v-I3
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:52:07 +0000
Received: from [85.158.143.99:58075] by server-1.bemta-4.messagelabs.com id
	7E/13-08839-69B4E115; Fri, 15 Feb 2013 14:52:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360939922!22386824!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32578 invoked from network); 15 Feb 2013 14:52:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:52:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:52: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.297.1;
	Fri, 15 Feb 2013 14:52:02 +0000
Message-ID: <1360939921.31407.92.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 15 Feb 2013 14:52:01 +0000
In-Reply-To: <1360071105.7477.139.camel@zion.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
	<1360061930.17017.34.camel@zakaz.uk.xensource.com>
	<1360071105.7477.139.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 13:31 +0000, Wei Liu wrote:

> -----8<----
> From 22a7b50b8b0be62aeae7c86242a27dac1ffdb929 Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Mon, 21 Jan 2013 19:07:37 +0000
> Subject: [PATCH] Switch to poll() in cxenstored's IO loop
> 
> Poll() can support more file descriptors than select(). We've done this for
> xenconsoled, now do this for cxenstored as well.
> 
> The code is taken from xenconsoled and modified to adapt to cxenstored.
> 
> Updated:
> * reopen pipe if polling on reopen_log_pipe fails.
> * exit if polling on some critical fds fails.
> * clean up POLL*.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Does this build for you? It fails to build for me in a fairly obvious
way with:
        xenstored_core.c:22:18: error: poll.h: No such file or directory
followed by the inevitable fallout.

Oh, this is the stubdomain build! I suppose mini-os lacks poll support.

Faced with either making xenstored able to use poll or select as a
compile time option and implementing poll for mini-os I'd probably go
for the latter, presuming that most of the infrastructure is present
already...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:52:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:52: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 1U6Me0-0001A3-P4; Fri, 15 Feb 2013 14:52: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 1U6Mdz-00019v-I3
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:52:07 +0000
Received: from [85.158.143.99:58075] by server-1.bemta-4.messagelabs.com id
	7E/13-08839-69B4E115; Fri, 15 Feb 2013 14:52:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1360939922!22386824!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32578 invoked from network); 15 Feb 2013 14:52:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:52:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:52: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.297.1;
	Fri, 15 Feb 2013 14:52:02 +0000
Message-ID: <1360939921.31407.92.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Fri, 15 Feb 2013 14:52:01 +0000
In-Reply-To: <1360071105.7477.139.camel@zion.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
	<1360061930.17017.34.camel@zakaz.uk.xensource.com>
	<1360071105.7477.139.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 13:31 +0000, Wei Liu wrote:

> -----8<----
> From 22a7b50b8b0be62aeae7c86242a27dac1ffdb929 Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Mon, 21 Jan 2013 19:07:37 +0000
> Subject: [PATCH] Switch to poll() in cxenstored's IO loop
> 
> Poll() can support more file descriptors than select(). We've done this for
> xenconsoled, now do this for cxenstored as well.
> 
> The code is taken from xenconsoled and modified to adapt to cxenstored.
> 
> Updated:
> * reopen pipe if polling on reopen_log_pipe fails.
> * exit if polling on some critical fds fails.
> * clean up POLL*.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Does this build for you? It fails to build for me in a fairly obvious
way with:
        xenstored_core.c:22:18: error: poll.h: No such file or directory
followed by the inevitable fallout.

Oh, this is the stubdomain build! I suppose mini-os lacks poll support.

Faced with either making xenstored able to use poll or select as a
compile time option and implementing poll for mini-os I'd probably go
for the latter, presuming that most of the infrastructure is present
already...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:53:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:53: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 1U6Mee-0001Bd-6q; Fri, 15 Feb 2013 14:52:48 +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 1U6Mec-0001BV-E7
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:52:46 +0000
Received: from [85.158.143.99:4600] by server-2.bemta-4.messagelabs.com id
	52/FF-01597-DBB4E115; Fri, 15 Feb 2013 14:52:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360939965!21304227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4241 invoked from network); 15 Feb 2013 14:52:45 -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; 15 Feb 2013 14:52:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 14:52:44 +0000
Message-Id: <511E59C902000078000BEC18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 14:52:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
In-Reply-To: <20130215134720.GG11777@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> >> Since when is E820_UNUSABLE memory being used as guest
>> >> memory? If that's indeed the case, that's the bug to fix. The
>> >> above data to me shows, however, that the range above
>> >> 228000000 is considered invalid. So then the question is why the
>> >> kernel tries to map that memory in the first place (the hypervisor
>> >> rejecting the attempt, despite Dom0 being privileged, seems
>> >> correct to me, as the range is also known not to be MMIO).
> 
> B/c it gets the E820 from the hypervisor, which shows that area as
> E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
> creating pagetables for it.

That would be wrong even on native, and I don't see how that
would happen: memblock_add() gets called from
memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
ranges.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:53:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:53: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 1U6Mee-0001Bd-6q; Fri, 15 Feb 2013 14:52:48 +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 1U6Mec-0001BV-E7
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:52:46 +0000
Received: from [85.158.143.99:4600] by server-2.bemta-4.messagelabs.com id
	52/FF-01597-DBB4E115; Fri, 15 Feb 2013 14:52:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1360939965!21304227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4241 invoked from network); 15 Feb 2013 14:52:45 -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; 15 Feb 2013 14:52:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 14:52:44 +0000
Message-Id: <511E59C902000078000BEC18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 14:52:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
In-Reply-To: <20130215134720.GG11777@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> >> Since when is E820_UNUSABLE memory being used as guest
>> >> memory? If that's indeed the case, that's the bug to fix. The
>> >> above data to me shows, however, that the range above
>> >> 228000000 is considered invalid. So then the question is why the
>> >> kernel tries to map that memory in the first place (the hypervisor
>> >> rejecting the attempt, despite Dom0 being privileged, seems
>> >> correct to me, as the range is also known not to be MMIO).
> 
> B/c it gets the E820 from the hypervisor, which shows that area as
> E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
> creating pagetables for it.

That would be wrong even on native, and I don't see how that
would happen: memblock_add() gets called from
memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
ranges.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:57:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:57: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 1U6MjA-0001QB-W7; Fri, 15 Feb 2013 14:57: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 1U6Mj8-0001Px-QP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:57:26 +0000
Received: from [85.158.143.35:36909] by server-1.bemta-4.messagelabs.com id
	C6/69-08839-6DC4E115; Fri, 15 Feb 2013 14:57:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360940118!13274143!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1350 invoked from network); 15 Feb 2013 14:55: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; 15 Feb 2013 14:55:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 14:55:17 +0000
Message-Id: <511E5A6202000078000BEC1B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 14:55:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
	<1360934649.31407.44.camel@zakaz.uk.xensource.com>
	<511E48FC02000078000BEB2E@nat28.tlf.novell.com>
	<1360937196.31407.76.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360937196.31407.76.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 15:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I guess it is obvious why HVM params were needed on HVM and you invented
> XENFEAT_dom0 IIRC :-)

Yeah, as capability indication from the kernel to the hypervisor. The
inverse (indicating the granted privilege to the kernel) was only a
side effect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:57:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:57: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 1U6MjA-0001QB-W7; Fri, 15 Feb 2013 14:57: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 1U6Mj8-0001Px-QP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:57:26 +0000
Received: from [85.158.143.35:36909] by server-1.bemta-4.messagelabs.com id
	C6/69-08839-6DC4E115; Fri, 15 Feb 2013 14:57:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1360940118!13274143!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1350 invoked from network); 15 Feb 2013 14:55: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; 15 Feb 2013 14:55:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 14:55:17 +0000
Message-Id: <511E5A6202000078000BEC1B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 14:55:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1360851380.20449.397.camel@zakaz.uk.xensource.com>
	<1360851590-2539-2-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151208430.8231@kaball.uk.xensource.com>
	<511E3FAB02000078000BEAD2@nat28.tlf.novell.com>
	<1360934649.31407.44.camel@zakaz.uk.xensource.com>
	<511E48FC02000078000BEB2E@nat28.tlf.novell.com>
	<1360937196.31407.76.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360937196.31407.76.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen: make start_info x86 specific.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 15:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> I guess it is obvious why HVM params were needed on HVM and you invented
> XENFEAT_dom0 IIRC :-)

Yeah, as capability indication from the kernel to the hypervisor. The
inverse (indicating the granted privilege to the kernel) was only a
side effect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 14:58:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:58: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 1U6MkL-0001UM-F1; Fri, 15 Feb 2013 14:58: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 1U6MkK-0001UD-FU
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:58:40 +0000
Received: from [85.158.139.83:61310] by server-6.bemta-5.messagelabs.com id
	FD/8E-01489-F1D4E115; Fri, 15 Feb 2013 14:58:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360940319!24747969!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12149 invoked from network); 15 Feb 2013 14:58:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:58: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.297.1; Fri, 15 Feb 2013 14:58:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6Mk4-0005iJ-IL; Fri, 15 Feb 2013 14:58:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6Mk4-0000sC-Df;
	Fri, 15 Feb 2013 14:58:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.19728.50115.273012@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:58:24 +0000
To: Lalith Suresh <suresh.lalith@gmail.com>
In-Reply-To: <5ba8cd0c47cb4fe961a1.1360840081@irule>
References: <5ba8cd0c47cb4fe961a1.1360840081@irule>
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] xm: fix description of xm vcpu-set 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

Lalith Suresh writes ("[PATCH] xm: fix description of xm vcpu-set command"):
> Minor language correction in the description of the xm vcpu-set command.
> 
> Signed-off-by: Lalith Suresh <suresh.lalith@gmail.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

(NB that xm and xend are deprecated and in the deep freeze
maintenance-wise, and will receive only bugfixes.  Your patch was a
clear bugfix so I have applied 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 Fri Feb 15 14:58:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 14:58: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 1U6MkL-0001UM-F1; Fri, 15 Feb 2013 14:58: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 1U6MkK-0001UD-FU
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 14:58:40 +0000
Received: from [85.158.139.83:61310] by server-6.bemta-5.messagelabs.com id
	FD/8E-01489-F1D4E115; Fri, 15 Feb 2013 14:58:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360940319!24747969!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12149 invoked from network); 15 Feb 2013 14:58:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:58:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:58: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.297.1; Fri, 15 Feb 2013 14:58:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6Mk4-0005iJ-IL; Fri, 15 Feb 2013 14:58:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6Mk4-0000sC-Df;
	Fri, 15 Feb 2013 14:58:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.19728.50115.273012@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:58:24 +0000
To: Lalith Suresh <suresh.lalith@gmail.com>
In-Reply-To: <5ba8cd0c47cb4fe961a1.1360840081@irule>
References: <5ba8cd0c47cb4fe961a1.1360840081@irule>
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] xm: fix description of xm vcpu-set 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

Lalith Suresh writes ("[PATCH] xm: fix description of xm vcpu-set command"):
> Minor language correction in the description of the xm vcpu-set command.
> 
> Signed-off-by: Lalith Suresh <suresh.lalith@gmail.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

(NB that xm and xend are deprecated and in the deep freeze
maintenance-wise, and will receive only bugfixes.  Your patch was a
clear bugfix so I have applied 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 Fri Feb 15 15:00:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6MlY-0001a6-UW; Fri, 15 Feb 2013 14:59: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 1U6MlX-0001Zp-Gj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:59:55 +0000
Received: from [85.158.137.99:16886] by server-7.bemta-3.messagelabs.com id
	15/C8-10367-96D4E115; Fri, 15 Feb 2013 14:59:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360940392!13221460!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15816 invoked from network); 15 Feb 2013 14:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:59: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.297.1; Fri, 15 Feb 2013 14:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6MlU-0005ij-D2; Fri, 15 Feb 2013 14:59:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6MlU-0000sS-9I;
	Fri, 15 Feb 2013 14:59:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.19816.146502.391776@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:59:52 +0000
To: Frediano Ziglio <frediano.ziglio@citrix.com>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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

Frediano Ziglio writes ("[PATCH] doc: Improve xc_domain_restore inline documentation"):
> Was not clear that xc_domain_restore did not resume the machine.
> ---
>  tools/libxc/xenguest.h |    2 ++
>  1 file changed, 2 insertions(+)

I'm afraid we need your confirmation that the Developer's Certificate
of Origin applies.  See http://wiki.xen.org/wiki/SubmittingXenPatches

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 Feb 15 15:00:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6MlY-0001a6-UW; Fri, 15 Feb 2013 14:59: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 1U6MlX-0001Zp-Gj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 14:59:55 +0000
Received: from [85.158.137.99:16886] by server-7.bemta-3.messagelabs.com id
	15/C8-10367-96D4E115; Fri, 15 Feb 2013 14:59:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360940392!13221460!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15816 invoked from network); 15 Feb 2013 14:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 14:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 14:59: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.297.1; Fri, 15 Feb 2013 14:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6MlU-0005ij-D2; Fri, 15 Feb 2013 14:59:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6MlU-0000sS-9I;
	Fri, 15 Feb 2013 14:59:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.19816.146502.391776@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 14:59:52 +0000
To: Frediano Ziglio <frediano.ziglio@citrix.com>
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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

Frediano Ziglio writes ("[PATCH] doc: Improve xc_domain_restore inline documentation"):
> Was not clear that xc_domain_restore did not resume the machine.
> ---
>  tools/libxc/xenguest.h |    2 ++
>  1 file changed, 2 insertions(+)

I'm afraid we need your confirmation that the Developer's Certificate
of Origin applies.  See http://wiki.xen.org/wiki/SubmittingXenPatches

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 Feb 15 15:05:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6MrB-0001ux-W4; Fri, 15 Feb 2013 15:05:45 +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 1U6Mr9-0001uh-Qj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:05:44 +0000
Received: from [85.158.137.99:39110] by server-2.bemta-3.messagelabs.com id
	76/65-25961-6CE4E115; Fri, 15 Feb 2013 15:05:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360940741!16216369!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8336 invoked from network); 15 Feb 2013 15:05:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:05:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:05:41 +0000
Message-Id: <511E5CD202000078000BEC4F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:05:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <511E46FD.3010605@citrix.com>
In-Reply-To: <511E46FD.3010605@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 15:32, David Vrabel <david.vrabel@citrix.com> wrote:
> ### Control Block
> 
> ![\label{fig_control-block}Control Block](control-block.pdf)
> 
> The READY field contains a bit for each priority's queue.  A set bit
> indicates that there are events pending on that queue.  A queue's
> ready bit is set by Xen when an event is placed on an empty queue and
> cleared by the guest when it empties the queue.
> 
> There are N HEAD and TAIL indexes, one for each priority.
> 
> The HEAD index is the first event in the queue or zero if the queue is
> empty.  HEAD is set by the guest as it consumes events and only set by
> Xen when adding an event to an empty queue.
> 
> The TAIL index is the last event in the queue.  It is undefined if the
> queue is empty.  TAIL is only set by Xen.

One thing I continue to wonder is why tail it part of the control
block at all - from all I can tell, it's not consumed by the guest (end
of list being indicated by a zero LINK field), and hence is an
implementation detail of the hypervisor. And given that the
hypervisor reads that field, not exposing the field also avoids the
need to validate is each time it gets read from the control block.

Additionally, I think the number of significant bits of the LINK field
should actually be obtained from the hypervisor, rather than being
baked at 17 (for the time being). This again is an implementation
detail (and the value could easily be command line controllable).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:05:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6MrB-0001ux-W4; Fri, 15 Feb 2013 15:05:45 +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 1U6Mr9-0001uh-Qj
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:05:44 +0000
Received: from [85.158.137.99:39110] by server-2.bemta-3.messagelabs.com id
	76/65-25961-6CE4E115; Fri, 15 Feb 2013 15:05:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360940741!16216369!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8336 invoked from network); 15 Feb 2013 15:05:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:05:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:05:41 +0000
Message-Id: <511E5CD202000078000BEC4F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:05:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <511E46FD.3010605@citrix.com>
In-Reply-To: <511E46FD.3010605@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 15:32, David Vrabel <david.vrabel@citrix.com> wrote:
> ### Control Block
> 
> ![\label{fig_control-block}Control Block](control-block.pdf)
> 
> The READY field contains a bit for each priority's queue.  A set bit
> indicates that there are events pending on that queue.  A queue's
> ready bit is set by Xen when an event is placed on an empty queue and
> cleared by the guest when it empties the queue.
> 
> There are N HEAD and TAIL indexes, one for each priority.
> 
> The HEAD index is the first event in the queue or zero if the queue is
> empty.  HEAD is set by the guest as it consumes events and only set by
> Xen when adding an event to an empty queue.
> 
> The TAIL index is the last event in the queue.  It is undefined if the
> queue is empty.  TAIL is only set by Xen.

One thing I continue to wonder is why tail it part of the control
block at all - from all I can tell, it's not consumed by the guest (end
of list being indicated by a zero LINK field), and hence is an
implementation detail of the hypervisor. And given that the
hypervisor reads that field, not exposing the field also avoids the
need to validate is each time it gets read from the control block.

Additionally, I think the number of significant bits of the LINK field
should actually be obtained from the hypervisor, rather than being
baked at 17 (for the time being). This again is an implementation
detail (and the value could easily be command line controllable).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:06:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:06: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 1U6MrK-0001w1-Cp; Fri, 15 Feb 2013 15:05:54 +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 1U6MrI-0001va-Nb
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:05:52 +0000
Received: from [85.158.139.211:35129] by server-15.bemta-5.messagelabs.com id
	61/95-18914-FCE4E115; Fri, 15 Feb 2013 15:05:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360940723!22660299!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18827 invoked from network); 15 Feb 2013 15:05:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 15:05:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FF5KT5006728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:05:21 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
	r1FF5JFp015201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:05:20 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
	r1FF5JDc019530; Fri, 15 Feb 2013 09:05:19 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:05:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 525151C387B; Fri, 15 Feb 2013 10:05:18 -0500 (EST)
Date: Fri, 15 Feb 2013 10:05:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130215150518.GB12178@phenom.dumpdata.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 11:52:35AM +0100, Stefan Bader wrote:
> Hopefully not mis-parsing Jan's last comments on the other thread,
> this would be the fix covering things until a better implementation
> is done.
> This also prevents the hang on older kernels, where it could be re-
> produced reliably.
> 
> -Stefan
> 
> >From 7e042a253b06da96409a0e059744c217f396a17f Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Feb 2013 09:48:52 +0100
> Subject: [PATCH] xen: Send spinlock IPI to all waiters
> 
> There is a loophole between Xen's current implementation of
> pv-spinlocks and the scheduler. This was triggerable through
> a testcase until v3.6 changed the TLB flushing code. The
> problem potentially is still there just not observable in the
> same way.
> 
> What could happen was (is):
> 
> 1. CPU n tries to schedule task x away and goes into a slow
>    wait for the runq lock of CPU n-# (must be one with a lower
>    number).
> 2. CPU n-#, while processing softirqs, tries to balance domains
>    and goes into a slow wait for its own runq lock (for updating
>    some records). Since this is a spin_lock_irqsave in softirq
>    context, interrupts will be re-enabled for the duration of
>    the poll_irq hypercall used by Xen.
> 3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
>    an interrupt (e.g. endio) and when processing the interrupt,
>    tries to wake up task x. But that is in schedule and still
>    on_cpu, so try_to_wake_up goes into a tight loop.
> 4. The runq lock of CPU n-# gets unlocked, but the message only
>    gets sent to the first waiter, which is CPU n-# and that is
>    busily stuck.

Just for completness:

5. The 3) (so CPU n-1) sits in its tight loop and never exits
   as nothing ever interrupted it.


> 
> To avoid this and since the unlocking code has no real sense of
> which waiter is best suited to grab the lock, just send the IPI
> to all of them. This causes the waiters to return from the hyper-
> call (those not interrupted at least) and do active spinlocking.
> 
> BugLink: http://bugs.launchpad.net/bugs/1011792
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> Cc: stable@vger.kernel.org
> ---
>  arch/x86/xen/spinlock.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 83e866d..f7a080e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>  		if (per_cpu(lock_spinners, cpu) == xl) {
>  			ADD_STATS(released_slow_kicked, 1);
>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;
>  		}
>  	}
>  }
> -- 
> 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 Fri Feb 15 15:06:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:06: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 1U6MrK-0001w1-Cp; Fri, 15 Feb 2013 15:05:54 +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 1U6MrI-0001va-Nb
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:05:52 +0000
Received: from [85.158.139.211:35129] by server-15.bemta-5.messagelabs.com id
	61/95-18914-FCE4E115; Fri, 15 Feb 2013 15:05:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360940723!22660299!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18827 invoked from network); 15 Feb 2013 15:05:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 15:05:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FF5KT5006728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:05:21 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
	r1FF5JFp015201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:05:20 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
	r1FF5JDc019530; Fri, 15 Feb 2013 09:05:19 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:05:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 525151C387B; Fri, 15 Feb 2013 10:05:18 -0500 (EST)
Date: Fri, 15 Feb 2013 10:05:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130215150518.GB12178@phenom.dumpdata.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 11:52:35AM +0100, Stefan Bader wrote:
> Hopefully not mis-parsing Jan's last comments on the other thread,
> this would be the fix covering things until a better implementation
> is done.
> This also prevents the hang on older kernels, where it could be re-
> produced reliably.
> 
> -Stefan
> 
> >From 7e042a253b06da96409a0e059744c217f396a17f Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Feb 2013 09:48:52 +0100
> Subject: [PATCH] xen: Send spinlock IPI to all waiters
> 
> There is a loophole between Xen's current implementation of
> pv-spinlocks and the scheduler. This was triggerable through
> a testcase until v3.6 changed the TLB flushing code. The
> problem potentially is still there just not observable in the
> same way.
> 
> What could happen was (is):
> 
> 1. CPU n tries to schedule task x away and goes into a slow
>    wait for the runq lock of CPU n-# (must be one with a lower
>    number).
> 2. CPU n-#, while processing softirqs, tries to balance domains
>    and goes into a slow wait for its own runq lock (for updating
>    some records). Since this is a spin_lock_irqsave in softirq
>    context, interrupts will be re-enabled for the duration of
>    the poll_irq hypercall used by Xen.
> 3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
>    an interrupt (e.g. endio) and when processing the interrupt,
>    tries to wake up task x. But that is in schedule and still
>    on_cpu, so try_to_wake_up goes into a tight loop.
> 4. The runq lock of CPU n-# gets unlocked, but the message only
>    gets sent to the first waiter, which is CPU n-# and that is
>    busily stuck.

Just for completness:

5. The 3) (so CPU n-1) sits in its tight loop and never exits
   as nothing ever interrupted it.


> 
> To avoid this and since the unlocking code has no real sense of
> which waiter is best suited to grab the lock, just send the IPI
> to all of them. This causes the waiters to return from the hyper-
> call (those not interrupted at least) and do active spinlocking.
> 
> BugLink: http://bugs.launchpad.net/bugs/1011792
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> Cc: stable@vger.kernel.org
> ---
>  arch/x86/xen/spinlock.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 83e866d..f7a080e 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>  		if (per_cpu(lock_spinners, cpu) == xl) {
>  			ADD_STATS(released_slow_kicked, 1);
>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;
>  		}
>  	}
>  }
> -- 
> 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 Fri Feb 15 15:07:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:07: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 1U6Msj-00028z-TG; Fri, 15 Feb 2013 15:07:21 +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 1U6Msh-00028Q-VB
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:07:20 +0000
Received: from [85.158.137.99:18537] by server-10.bemta-3.messagelabs.com id
	9B/97-10609-72F4E115; Fri, 15 Feb 2013 15:07:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360940838!13222962!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25985 invoked from network); 15 Feb 2013 15:07:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:07:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 15:07: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.297.1; Fri, 15 Feb 2013 15:07:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6Msg-0005mR-0Q; Fri, 15 Feb 2013 15:07:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6Msf-0000tw-SA;
	Fri, 15 Feb 2013 15:07:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.20261.610456.470380@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 15:07:17 +0000
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <510939A6.8050905@citrix.com>
References: <5108E419.9060603@canonical.com>
	<51090F9502000078000BAB01@nat28.tlf.novell.com>
	<51090387.6070305@canonical.com> <510939A6.8050905@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>, Stefan Bader <stefan.bader@canonical.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 cherry-pick 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

Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2 cherry-pick proposal"):
> On the subject of backport requests,
> 
> Can I request the backport of rev 26373:56daf05bcf69 to xen-4.2, which
> fixes SBDF encoding in the ocaml bindings.

Done.

> Rev 26374 is also a possibility, but as it is not strictly a fix, it is
> rather less important.

I'm not sure whether it's a good idea to take this.  Personally I
would be inclined to do so, because it will make any future patches
here easier if they don't divert, but I would like to ask the Jan's
opinion as the stable maintainer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:07:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:07: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 1U6Msj-00028z-TG; Fri, 15 Feb 2013 15:07:21 +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 1U6Msh-00028Q-VB
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:07:20 +0000
Received: from [85.158.137.99:18537] by server-10.bemta-3.messagelabs.com id
	9B/97-10609-72F4E115; Fri, 15 Feb 2013 15:07:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360940838!13222962!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25985 invoked from network); 15 Feb 2013 15:07:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:07:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1519728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 15:07: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.297.1; Fri, 15 Feb 2013 15:07:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6Msg-0005mR-0Q; Fri, 15 Feb 2013 15:07:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6Msf-0000tw-SA;
	Fri, 15 Feb 2013 15:07:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.20261.610456.470380@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 15:07:17 +0000
To: Andrew Cooper <andrew.cooper3@citrix.com>
In-Reply-To: <510939A6.8050905@citrix.com>
References: <5108E419.9060603@canonical.com>
	<51090F9502000078000BAB01@nat28.tlf.novell.com>
	<51090387.6070305@canonical.com> <510939A6.8050905@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>, Stefan Bader <stefan.bader@canonical.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 cherry-pick 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

Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2 cherry-pick proposal"):
> On the subject of backport requests,
> 
> Can I request the backport of rev 26373:56daf05bcf69 to xen-4.2, which
> fixes SBDF encoding in the ocaml bindings.

Done.

> Rev 26374 is also a possibility, but as it is not strictly a fix, it is
> rather less important.

I'm not sure whether it's a good idea to take this.  Personally I
would be inclined to do so, because it will make any future patches
here easier if they don't divert, but I would like to ask the Jan's
opinion as the stable maintainer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6MyA-0002YE-PY; Fri, 15 Feb 2013 15:12:58 +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 1U6My9-0002Y8-1Y
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:12:57 +0000
Received: from [193.109.254.147:5564] by server-16.bemta-14.messagelabs.com id
	D9/C8-25906-8705E115; Fri, 15 Feb 2013 15:12:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360941175!8550702!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12587 invoked from network); 15 Feb 2013 15:12:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:12:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:12:54 +0000
Message-Id: <511E5E8202000078000BEC6D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:12:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <5108E419.9060603@canonical.com>
	<51090F9502000078000BAB01@nat28.tlf.novell.com>
	<51090387.6070305@canonical.com> <510939A6.8050905@citrix.com>
	<20766.20261.610456.470380@mariner.uk.xensource.com>
In-Reply-To: <20766.20261.610456.470380@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefan Bader <stefan.bader@canonical.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 cherry-pick 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 15.02.13 at 16:07, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2 cherry-pick proposal"):
>> Rev 26374 is also a possibility, but as it is not strictly a fix, it is
>> rather less important.
> 
> I'm not sure whether it's a good idea to take this.  Personally I
> would be inclined to do so, because it will make any future patches
> here easier if they don't divert, but I would like to ask the Jan's
> opinion as the stable maintainer.

If the "no functional change" is true (which it looks like it is), then
I don't mind this being put in if it helps going forward.

That said, the change looks questionable in one aspect: PCI
terminology uses "device" and "slot" interchangeably, and hence
it was pointless to do that part of the renaming.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:13:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6MyA-0002YE-PY; Fri, 15 Feb 2013 15:12:58 +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 1U6My9-0002Y8-1Y
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:12:57 +0000
Received: from [193.109.254.147:5564] by server-16.bemta-14.messagelabs.com id
	D9/C8-25906-8705E115; Fri, 15 Feb 2013 15:12:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1360941175!8550702!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12587 invoked from network); 15 Feb 2013 15:12:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:12:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:12:54 +0000
Message-Id: <511E5E8202000078000BEC6D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:12:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <5108E419.9060603@canonical.com>
	<51090F9502000078000BAB01@nat28.tlf.novell.com>
	<51090387.6070305@canonical.com> <510939A6.8050905@citrix.com>
	<20766.20261.610456.470380@mariner.uk.xensource.com>
In-Reply-To: <20766.20261.610456.470380@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefan Bader <stefan.bader@canonical.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 cherry-pick 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 15.02.13 at 16:07, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2 cherry-pick proposal"):
>> Rev 26374 is also a possibility, but as it is not strictly a fix, it is
>> rather less important.
> 
> I'm not sure whether it's a good idea to take this.  Personally I
> would be inclined to do so, because it will make any future patches
> here easier if they don't divert, but I would like to ask the Jan's
> opinion as the stable maintainer.

If the "no functional change" is true (which it looks like it is), then
I don't mind this being put in if it helps going forward.

That said, the change looks questionable in one aspect: PCI
terminology uses "device" and "slot" interchangeably, and hence
it was pointless to do that part of the renaming.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:14:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:14: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 1U6MzR-0002cf-DP; Fri, 15 Feb 2013 15:14:17 +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 1U6MzP-0002cU-Vu
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:14:16 +0000
Received: from [85.158.143.99:53609] by server-1.bemta-4.messagelabs.com id
	AF/1E-08839-7C05E115; Fri, 15 Feb 2013 15:14:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360941253!27672929!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25488 invoked from network); 15 Feb 2013 15:14:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:14:14 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FFE7Tl009073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:14:08 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
	r1FFE7FZ001217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:14:07 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
	r1FFE7EO026277; Fri, 15 Feb 2013 09:14:07 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:14:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 116AC1C387B; Fri, 15 Feb 2013 10:14:06 -0500 (EST)
Date: Fri, 15 Feb 2013 10:14:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130215151406.GD12178@phenom.dumpdata.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
	<1360927883.31407.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360927883.31407.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefan Bader <stefan.bader@canonical.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 11:31:23AM +0000, Ian Campbell wrote:
> On Fri, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
> > >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> > >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> > >> index 83e866d..f7a080e 100644
> > >> --- a/arch/x86/xen/spinlock.c
> > >> +++ b/arch/x86/xen/spinlock.c
> > >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> > > xen_spinlock *xl)
> > >>  		if (per_cpu(lock_spinners, cpu) == xl) {
> > >>  			ADD_STATS(released_slow_kicked, 1);
> > >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> > >> -			break;
> > > 
> > > It would be more efficient to build a mask and use xen_send_IPI_mask().
> > 
> > In order for __xen_send_IPI_mask() to then take the list apart
> > again and call xen_send_IPI_one()? There's no batching
> > implemented currently...
> 
> Oh, I simply assumed it must obviously do that!

Perhaps if it was done via a multicall? We could batch then things up. But I recall
you saying that for homogeneous calls it is silly to use multicalls.

> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:14:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:14: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 1U6MzR-0002cf-DP; Fri, 15 Feb 2013 15:14:17 +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 1U6MzP-0002cU-Vu
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:14:16 +0000
Received: from [85.158.143.99:53609] by server-1.bemta-4.messagelabs.com id
	AF/1E-08839-7C05E115; Fri, 15 Feb 2013 15:14:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1360941253!27672929!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25488 invoked from network); 15 Feb 2013 15:14:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:14:14 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FFE7Tl009073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:14:08 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
	r1FFE7FZ001217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:14:07 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
	r1FFE7EO026277; Fri, 15 Feb 2013 09:14:07 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:14:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 116AC1C387B; Fri, 15 Feb 2013 10:14:06 -0500 (EST)
Date: Fri, 15 Feb 2013 10:14:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130215151406.GD12178@phenom.dumpdata.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
	<1360927883.31407.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360927883.31407.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefan Bader <stefan.bader@canonical.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 11:31:23AM +0000, Ian Campbell wrote:
> On Fri, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
> > >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> > >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> > >> index 83e866d..f7a080e 100644
> > >> --- a/arch/x86/xen/spinlock.c
> > >> +++ b/arch/x86/xen/spinlock.c
> > >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> > > xen_spinlock *xl)
> > >>  		if (per_cpu(lock_spinners, cpu) == xl) {
> > >>  			ADD_STATS(released_slow_kicked, 1);
> > >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> > >> -			break;
> > > 
> > > It would be more efficient to build a mask and use xen_send_IPI_mask().
> > 
> > In order for __xen_send_IPI_mask() to then take the list apart
> > again and call xen_send_IPI_one()? There's no batching
> > implemented currently...
> 
> Oh, I simply assumed it must obviously do that!

Perhaps if it was done via a multicall? We could batch then things up. But I recall
you saying that for homogeneous calls it is silly to use multicalls.

> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:17:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:17: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 1U6N2Y-0002pa-0r; Fri, 15 Feb 2013 15:17:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U6N2V-0002pR-Ul
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:17:28 +0000
Received: from [85.158.139.211:6692] by server-13.bemta-5.messagelabs.com id
	8C/EE-06769-7815E115; Fri, 15 Feb 2013 15:17:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360941444!18729359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21690 invoked from network); 15 Feb 2013 15:17:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7690394"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 15:17:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 10:17:23 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U6N2M-0004jp-Bm;
	Fri, 15 Feb 2013 15:17:18 +0000
Message-ID: <511E517E.7090709@citrix.com>
Date: Fri, 15 Feb 2013 15:17:18 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
	<1360938376.31407.83.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360938376.31407.83.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/ocaml: libxc bindings: Fix
	stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/13 14:26, Ian Campbell wrote:
> On Thu, 2013-02-14 at 19:29 +0000, Andrew Cooper wrote:
>> There are two problems with this function:
>>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>>     compete for use of the static ring[] buffer.
>>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>>     more of its console ring.
>>
>> Unfortunately, fixing the code in a sensible is rather difficult.  The Ocaml
>> caller expects to get the entire console ring in a single buffer.  There are
>> no mechanisms to ask Xen for the size of the console ring (which is fixed
>> after boot).
> It would be easy to add a sysctl to get this

Yes.  I didn't because of a combination of the reasons below, and
because I needed a fix for our automated testing, but I think I have had
a cunning idea.

>
>>   Even if there was a way to get the size of the console ring, the
>> XEN_SYSCTL_readconsole hypercall itself races with printk(), leading to
>> possibly discontinuities if the ring is full.
> Right, that one is tricky, but as you say we could accept the
> inefficiencies here.
>
>>   The requirement for a NULL
>> terminating string means that a full console ring will appear to fail when use
>> the correct power of two, forcing us to double up again.
> Double? Or just allocate buffersize + 1? We could also consider fixing
> the XEN_SYSCTL_readconsole interface to remove this issue.

Requires buffersize + 1 + nr_of_chars_from_a_raced_printk to get any
indication back from the hypercall that we have indeed read the full ring.

Choosing buffersize rounded up to the next PAGE_SIZE will suffice except
in extreme circumstances.

>
>> Furthermore, libxc will bounce the allocated buffer, as will caml_copy_string().
> You could avoid the first of these by using xc_hypercall_buffer_alloc or
> xc_hypercall_buffer_alloc_pages in the caller, these are exposed from
> libxc exactly to allow us to avoid bouncing of larger objects.

I will investigate using these.

~Andrew

>
>
>> On the other hand, this is very definitely for debugging and testing, so lets
>> do the best we can to get the entire buffer, and accept the inefficiencies.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 63594ce1708f -r 1daa30509f1c tools/ocaml/libs/xc/xenctrl_stubs.c
>> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
>> @@ -523,27 +523,55 @@ CAMLprim value stub_xc_evtchn_reset(valu
>>  	CAMLreturn(Val_unit);
>>  }
>>  
>> -
>> -#define RING_SIZE 32768
>> -static char ring[RING_SIZE];
>> -
>> +/* Maximum size of console ring we are prepared to read, 16MB */
>> +#define MAX_CONSOLE_RING_SIZE (1U << 24)
>>  CAMLprim value stub_xc_readconsolering(value xch)
>>  {
>> -	unsigned int size = RING_SIZE - 1;
>> -	char *ring_ptr = ring;
>> -	int retval;
>> +	/* 32K starting size (adj for loop doubling at start) */
>> +	unsigned int ring_size = 1U << 14;
>> +	unsigned int nr_chars = ring_size;
>> +	char * ring = NULL;
>> +	int r;
>>  
>>  	CAMLparam1(xch);
>> +	CAMLlocal1(conring);
>>  
>> -	caml_enter_blocking_section();
>> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
>> -	caml_leave_blocking_section();
>> +	do
>> +	{
>> +		ring_size *= 2;
>> +		if ( ring_size > MAX_CONSOLE_RING_SIZE )
>> +		{
>> +			caml_failwith("Console ring too large");
>> +			CAMLreturn(Val_unit);
>> +		}
>> +		nr_chars = ring_size;
>>  
>> -	if (retval)
>> -		failwith_xc(_H(xch));
>> +		free(ring);
>> +		if ( ! ( ring = malloc(ring_size) ) )
>> +		{
>> +			caml_failwith("Out of memory");
>> +			CAMLreturn(Val_unit);
>> +		}
>>  
>> -	ring[size] = '\0';
>> -	CAMLreturn(caml_copy_string(ring));
>> +		caml_enter_blocking_section();
>> +		r = xc_readconsolering(_H(xch), ring, &nr_chars, 0, 0, NULL);
>> +		caml_leave_blocking_section();
>> +
>> +		if ( r )
>> +		{
>> +			failwith_xc(_H(xch));
>> +			free(ring);
>> +			CAMLreturn(Val_unit);
>> +		}
>> +
>> +		/* If nr_chars == ring_size, we have not read the entire ring.
>> +		 * Try again with a larger buffer. */
>> +	} while ( nr_chars >= ring_size );
>> +
>> +	ring[nr_chars] = '\0';
>> +	conring = caml_copy_string(ring);
>> +	free(ring);
>> +	CAMLreturn(conring);
>>  }
>>  
>>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:17:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:17: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 1U6N2Y-0002pa-0r; Fri, 15 Feb 2013 15:17:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U6N2V-0002pR-Ul
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:17:28 +0000
Received: from [85.158.139.211:6692] by server-13.bemta-5.messagelabs.com id
	8C/EE-06769-7815E115; Fri, 15 Feb 2013 15:17:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360941444!18729359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21690 invoked from network); 15 Feb 2013 15:17:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7690394"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 15:17:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 10:17:23 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U6N2M-0004jp-Bm;
	Fri, 15 Feb 2013 15:17:18 +0000
Message-ID: <511E517E.7090709@citrix.com>
Date: Fri, 15 Feb 2013 15:17:18 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1daa30509f1cf37b0988.1360870151@andrewcoop.uk.xensource.com>
	<1360938376.31407.83.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360938376.31407.83.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2] tools/ocaml: libxc bindings: Fix
	stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/13 14:26, Ian Campbell wrote:
> On Thu, 2013-02-14 at 19:29 +0000, Andrew Cooper wrote:
>> There are two problems with this function:
>>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>>     compete for use of the static ring[] buffer.
>>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>>     more of its console ring.
>>
>> Unfortunately, fixing the code in a sensible is rather difficult.  The Ocaml
>> caller expects to get the entire console ring in a single buffer.  There are
>> no mechanisms to ask Xen for the size of the console ring (which is fixed
>> after boot).
> It would be easy to add a sysctl to get this

Yes.  I didn't because of a combination of the reasons below, and
because I needed a fix for our automated testing, but I think I have had
a cunning idea.

>
>>   Even if there was a way to get the size of the console ring, the
>> XEN_SYSCTL_readconsole hypercall itself races with printk(), leading to
>> possibly discontinuities if the ring is full.
> Right, that one is tricky, but as you say we could accept the
> inefficiencies here.
>
>>   The requirement for a NULL
>> terminating string means that a full console ring will appear to fail when use
>> the correct power of two, forcing us to double up again.
> Double? Or just allocate buffersize + 1? We could also consider fixing
> the XEN_SYSCTL_readconsole interface to remove this issue.

Requires buffersize + 1 + nr_of_chars_from_a_raced_printk to get any
indication back from the hypercall that we have indeed read the full ring.

Choosing buffersize rounded up to the next PAGE_SIZE will suffice except
in extreme circumstances.

>
>> Furthermore, libxc will bounce the allocated buffer, as will caml_copy_string().
> You could avoid the first of these by using xc_hypercall_buffer_alloc or
> xc_hypercall_buffer_alloc_pages in the caller, these are exposed from
> libxc exactly to allow us to avoid bouncing of larger objects.

I will investigate using these.

~Andrew

>
>
>> On the other hand, this is very definitely for debugging and testing, so lets
>> do the best we can to get the entire buffer, and accept the inefficiencies.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 63594ce1708f -r 1daa30509f1c tools/ocaml/libs/xc/xenctrl_stubs.c
>> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
>> @@ -523,27 +523,55 @@ CAMLprim value stub_xc_evtchn_reset(valu
>>  	CAMLreturn(Val_unit);
>>  }
>>  
>> -
>> -#define RING_SIZE 32768
>> -static char ring[RING_SIZE];
>> -
>> +/* Maximum size of console ring we are prepared to read, 16MB */
>> +#define MAX_CONSOLE_RING_SIZE (1U << 24)
>>  CAMLprim value stub_xc_readconsolering(value xch)
>>  {
>> -	unsigned int size = RING_SIZE - 1;
>> -	char *ring_ptr = ring;
>> -	int retval;
>> +	/* 32K starting size (adj for loop doubling at start) */
>> +	unsigned int ring_size = 1U << 14;
>> +	unsigned int nr_chars = ring_size;
>> +	char * ring = NULL;
>> +	int r;
>>  
>>  	CAMLparam1(xch);
>> +	CAMLlocal1(conring);
>>  
>> -	caml_enter_blocking_section();
>> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
>> -	caml_leave_blocking_section();
>> +	do
>> +	{
>> +		ring_size *= 2;
>> +		if ( ring_size > MAX_CONSOLE_RING_SIZE )
>> +		{
>> +			caml_failwith("Console ring too large");
>> +			CAMLreturn(Val_unit);
>> +		}
>> +		nr_chars = ring_size;
>>  
>> -	if (retval)
>> -		failwith_xc(_H(xch));
>> +		free(ring);
>> +		if ( ! ( ring = malloc(ring_size) ) )
>> +		{
>> +			caml_failwith("Out of memory");
>> +			CAMLreturn(Val_unit);
>> +		}
>>  
>> -	ring[size] = '\0';
>> -	CAMLreturn(caml_copy_string(ring));
>> +		caml_enter_blocking_section();
>> +		r = xc_readconsolering(_H(xch), ring, &nr_chars, 0, 0, NULL);
>> +		caml_leave_blocking_section();
>> +
>> +		if ( r )
>> +		{
>> +			failwith_xc(_H(xch));
>> +			free(ring);
>> +			CAMLreturn(Val_unit);
>> +		}
>> +
>> +		/* If nr_chars == ring_size, we have not read the entire ring.
>> +		 * Try again with a larger buffer. */
>> +	} while ( nr_chars >= ring_size );
>> +
>> +	ring[nr_chars] = '\0';
>> +	conring = caml_copy_string(ring);
>> +	free(ring);
>> +	CAMLreturn(conring);
>>  }
>>  
>>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:18:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:18: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 1U6N37-0002sc-EO; Fri, 15 Feb 2013 15:18:05 +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 1U6N35-0002sE-DD
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:18:03 +0000
Received: from [85.158.139.211:12599] by server-5.bemta-5.messagelabs.com id
	7B/A4-11945-8A15E115; Fri, 15 Feb 2013 15:18:00 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360941478!22545898!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31863 invoked from network); 15 Feb 2013 15:18:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:18:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7317391"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 15:17:57 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 10:17:57 -0500
Message-ID: <511E51A4.9020503@citrix.com>
Date: Fri, 15 Feb 2013 15:17:56 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E46FD.3010605@citrix.com>
	<511E5CD202000078000BEC4F@nat28.tlf.novell.com>
In-Reply-To: <511E5CD202000078000BEC4F@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/13 15:05, Jan Beulich wrote:
>>>> On 15.02.13 at 15:32, David Vrabel <david.vrabel@citrix.com> wrote:
>> ### Control Block
>>
>> ![\label{fig_control-block}Control Block](control-block.pdf)
>>
>> The READY field contains a bit for each priority's queue.  A set bit
>> indicates that there are events pending on that queue.  A queue's
>> ready bit is set by Xen when an event is placed on an empty queue and
>> cleared by the guest when it empties the queue.
>>
>> There are N HEAD and TAIL indexes, one for each priority.
>>
>> The HEAD index is the first event in the queue or zero if the queue is
>> empty.  HEAD is set by the guest as it consumes events and only set by
>> Xen when adding an event to an empty queue.
>>
>> The TAIL index is the last event in the queue.  It is undefined if the
>> queue is empty.  TAIL is only set by Xen.
> 
> One thing I continue to wonder is why tail it part of the control
> block at all - from all I can tell, it's not consumed by the guest (end
> of list being indicated by a zero LINK field), and hence is an
> implementation detail of the hypervisor. And given that the
> hypervisor reads that field, not exposing the field also avoids the
> need to validate is each time it gets read from the control block.

Some of my initial back-of-envelope designs used it and I left it in
"just in case".

But the validation point is good, so I'll remove the TAIL field.

> Additionally, I think the number of significant bits of the LINK field
> should actually be obtained from the hypervisor, rather than being
> baked at 17 (for the time being). This again is an implementation
> detail (and the value could easily be command line controllable).

I'd considered something like this but decided to defer this to a future
date when it needed to be extended.

How about adding an EVTCHNOP_get_limit which gets the maximum permitted
port?  The guest can then round up the result of this to get the maximum
number of LINK bits.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:18:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:18: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 1U6N37-0002sc-EO; Fri, 15 Feb 2013 15:18:05 +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 1U6N35-0002sE-DD
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:18:03 +0000
Received: from [85.158.139.211:12599] by server-5.bemta-5.messagelabs.com id
	7B/A4-11945-8A15E115; Fri, 15 Feb 2013 15:18:00 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360941478!22545898!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31863 invoked from network); 15 Feb 2013 15:18:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:18:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7317391"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 15:17:57 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 10:17:57 -0500
Message-ID: <511E51A4.9020503@citrix.com>
Date: Fri, 15 Feb 2013 15:17:56 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E46FD.3010605@citrix.com>
	<511E5CD202000078000BEC4F@nat28.tlf.novell.com>
In-Reply-To: <511E5CD202000078000BEC4F@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/13 15:05, Jan Beulich wrote:
>>>> On 15.02.13 at 15:32, David Vrabel <david.vrabel@citrix.com> wrote:
>> ### Control Block
>>
>> ![\label{fig_control-block}Control Block](control-block.pdf)
>>
>> The READY field contains a bit for each priority's queue.  A set bit
>> indicates that there are events pending on that queue.  A queue's
>> ready bit is set by Xen when an event is placed on an empty queue and
>> cleared by the guest when it empties the queue.
>>
>> There are N HEAD and TAIL indexes, one for each priority.
>>
>> The HEAD index is the first event in the queue or zero if the queue is
>> empty.  HEAD is set by the guest as it consumes events and only set by
>> Xen when adding an event to an empty queue.
>>
>> The TAIL index is the last event in the queue.  It is undefined if the
>> queue is empty.  TAIL is only set by Xen.
> 
> One thing I continue to wonder is why tail it part of the control
> block at all - from all I can tell, it's not consumed by the guest (end
> of list being indicated by a zero LINK field), and hence is an
> implementation detail of the hypervisor. And given that the
> hypervisor reads that field, not exposing the field also avoids the
> need to validate is each time it gets read from the control block.

Some of my initial back-of-envelope designs used it and I left it in
"just in case".

But the validation point is good, so I'll remove the TAIL field.

> Additionally, I think the number of significant bits of the LINK field
> should actually be obtained from the hypervisor, rather than being
> baked at 17 (for the time being). This again is an implementation
> detail (and the value could easily be command line controllable).

I'd considered something like this but decided to defer this to a future
date when it needed to be extended.

How about adding an EVTCHNOP_get_limit which gets the maximum permitted
port?  The guest can then round up the result of this to get the maximum
number of LINK bits.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:22:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6N79-00038p-6f; Fri, 15 Feb 2013 15:22:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6N77-00038h-Kv
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:22:13 +0000
Received: from [85.158.139.83:15061] by server-11.bemta-5.messagelabs.com id
	78/C6-19159-4A25E115; Fri, 15 Feb 2013 15:22:12 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360941714!26783877!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17243 invoked from network); 15 Feb 2013 15:21:56 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 15:21:56 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FFLqoI018798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:21:53 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
	r1FFLpQH007880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:21:51 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
	r1FFLoH4002809; Fri, 15 Feb 2013 09:21:50 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:21:49 -0800
Message-ID: <511E527E.6090605@oracle.com>
Date: Fri, 15 Feb 2013 10:21:34 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
	<511CD8C202000078000BE280@nat28.tlf.novell.com>
	<511CFAD4.9040905@oracle.com>
	<511DFE0802000078000BE95D@nat28.tlf.novell.com>
In-Reply-To: <511DFE0802000078000BE95D@nat28.tlf.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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-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/15/2013 03:21 AM, Jan Beulich wrote:
>
> But I don't think we can easily deal with the single IOMMU
> case, making that IOMMU cover all devices, as we would
> still need to figure out the requestor ID for each device. That
> requires looking at the PCI bus topology iiuc, and while we
> have the necessary logic for VT-d, it seems not really strait
> forward (mainly because risky) to make use of this in the AMD Vi
> code too.

Scanning PCI for devices would effectively mean that we are ignoring 
IVHD (device portion of IVRS). That would be somewhat unfortunate (but 
maybe unavoidable, given the state of BIOSes).


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:22:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6N79-00038p-6f; Fri, 15 Feb 2013 15:22:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6N77-00038h-Kv
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:22:13 +0000
Received: from [85.158.139.83:15061] by server-11.bemta-5.messagelabs.com id
	78/C6-19159-4A25E115; Fri, 15 Feb 2013 15:22:12 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1360941714!26783877!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17243 invoked from network); 15 Feb 2013 15:21:56 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 15:21:56 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FFLqoI018798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:21:53 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
	r1FFLpQH007880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:21:51 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
	r1FFLoH4002809; Fri, 15 Feb 2013 09:21:50 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:21:49 -0800
Message-ID: <511E527E.6090605@oracle.com>
Date: Fri, 15 Feb 2013 10:21:34 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7d6022b9-fff5-4cca-b091-347d3e869909@default>
	<511A2FA402000078000BDAF7@nat28.tlf.novell.com>
	<CACvNfPz5Wu7_p2s2=10z=_L3qRh=snF04u2J_r5szP7iL3jLRA@mail.gmail.com>
	<511A33F302000078000BDB2B@nat28.tlf.novell.com>
	<511A35C402000078000BDB47@nat28.tlf.novell.com>
	<511A5DC3.4010106@oracle.com>
	<CACvNfPy8u3OnXoJnZEhwbm6cx7wSF9TO_zW1P_nUuA1Po6N89Q@mail.gmail.com>
	<511A763302000078000BDC82@nat28.tlf.novell.com>
	<CACvNfPwwo+343gwMn_ws9fFYPqJ1txAUSOmvpZb6kTt1pQ304g@mail.gmail.com>
	<CACvNfPz7h0BYpJyXPqVfxseck0taizV1WtkOs6hX1SNHDdMu4w@mail.gmail.com>
	<CACvNfPxpyUu_mkC1-sNsrO7BF=2HLWZ9j5cVS+MCXyNeXDcLww@mail.gmail.com>
	<511B574902000078000BDE41@nat28.tlf.novell.com>
	<CACvNfPyCDPuyaJaFm+ZswWbxt54XzFEnYRPRFopSBTnnMGTJBQ@mail.gmail.com>
	<511B5EE102000078000BDE8A@nat28.tlf.novell.com>
	<CACvNfPwB4+5mJ1qaLjf55QTK+Nno7XDKHoFkJzPYt-xURi3Cdg@mail.gmail.com>
	<511CD8C202000078000BE280@nat28.tlf.novell.com>
	<511CFAD4.9040905@oracle.com>
	<511DFE0802000078000BE95D@nat28.tlf.novell.com>
In-Reply-To: <511DFE0802000078000BE95D@nat28.tlf.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: povder <povder@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1 boot failure with IOMMU 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-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/15/2013 03:21 AM, Jan Beulich wrote:
>
> But I don't think we can easily deal with the single IOMMU
> case, making that IOMMU cover all devices, as we would
> still need to figure out the requestor ID for each device. That
> requires looking at the PCI bus topology iiuc, and while we
> have the necessary logic for VT-d, it seems not really strait
> forward (mainly because risky) to make use of this in the AMD Vi
> code too.

Scanning PCI for devices would effectively mean that we are ignoring 
IVHD (device portion of IVRS). That would be somewhat unfortunate (but 
maybe unavoidable, given the state of BIOSes).


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:36:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6NKl-0003Qz-IE; Fri, 15 Feb 2013 15:36:19 +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 1U6NKj-0003Qu-Un
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:36:18 +0000
Received: from [85.158.139.211:54134] by server-8.bemta-5.messagelabs.com id
	FC/D0-19075-CE55E115; Fri, 15 Feb 2013 15:36:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360942571!18731882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30244 invoked from network); 15 Feb 2013 15:36:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:36:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:36:10 +0000
Message-Id: <511E63F802000078000BECAA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:36:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<511E5CD202000078000BEC4F@nat28.tlf.novell.com>
	<511E51A4.9020503@citrix.com>
In-Reply-To: <511E51A4.9020503@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 16:17, David Vrabel <david.vrabel@citrix.com> wrote:
> On 15/02/13 15:05, Jan Beulich wrote:
>> Additionally, I think the number of significant bits of the LINK field
>> should actually be obtained from the hypervisor, rather than being
>> baked at 17 (for the time being). This again is an implementation
>> detail (and the value could easily be command line controllable).
> 
> I'd considered something like this but decided to defer this to a future
> date when it needed to be extended.
> 
> How about adding an EVTCHNOP_get_limit which gets the maximum permitted
> port?  The guest can then round up the result of this to get the maximum
> number of LINK bits.

I'd actually want to make this an output of the setup operation.
Whether to return a bit count or the number of ports is secondary
to me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:36:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15: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 1U6NKl-0003Qz-IE; Fri, 15 Feb 2013 15:36:19 +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 1U6NKj-0003Qu-Un
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:36:18 +0000
Received: from [85.158.139.211:54134] by server-8.bemta-5.messagelabs.com id
	FC/D0-19075-CE55E115; Fri, 15 Feb 2013 15:36:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1360942571!18731882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30244 invoked from network); 15 Feb 2013 15:36:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:36:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:36:10 +0000
Message-Id: <511E63F802000078000BECAA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:36:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<511E5CD202000078000BEC4F@nat28.tlf.novell.com>
	<511E51A4.9020503@citrix.com>
In-Reply-To: <511E51A4.9020503@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 16:17, David Vrabel <david.vrabel@citrix.com> wrote:
> On 15/02/13 15:05, Jan Beulich wrote:
>> Additionally, I think the number of significant bits of the LINK field
>> should actually be obtained from the hypervisor, rather than being
>> baked at 17 (for the time being). This again is an implementation
>> detail (and the value could easily be command line controllable).
> 
> I'd considered something like this but decided to defer this to a future
> date when it needed to be extended.
> 
> How about adding an EVTCHNOP_get_limit which gets the maximum permitted
> port?  The guest can then round up the result of this to get the maximum
> number of LINK bits.

I'd actually want to make this an output of the setup operation.
Whether to return a bit count or the number of ports is secondary
to me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:44:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:44: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 1U6NSk-0003sf-65; Fri, 15 Feb 2013 15:44:34 +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 1U6NSi-0003sU-F5
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:44:32 +0000
Received: from [193.109.254.147:51433] by server-15.bemta-14.messagelabs.com
	id AD/28-24599-FD75E115; Fri, 15 Feb 2013 15:44:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360942936!8586842!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11139 invoked from network); 15 Feb 2013 15:42:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 15:42:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FFgBpj021363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:42:12 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
	r1FFgAY4026139
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:42:11 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
	r1FFgA17011399; Fri, 15 Feb 2013 09:42:10 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:42:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2CBF51C387B; Fri, 15 Feb 2013 10:42:09 -0500 (EST)
Date: Fri, 15 Feb 2013 10:42:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olivier Bonvalet <xen.list@daevel.fr>
Message-ID: <20130215154209.GA13439@phenom.dumpdata.com>
References: <1360431862.27289.8.camel@boolette.noo>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360431862.27289.8.camel@boolette.noo>
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" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [blkfront] max_segments & max_segment_size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 09, 2013 at 06:44:22PM +0100, Olivier Bonvalet wrote:
> Hi,
> 
> I have (very) poor write performance with Xen PV, used over RBD, and I
> suppose it's because of very short values for max_segments and
> max_segment_size.
> (I have 250MB/s write speed in Dom0 vs 40MB/s write speed in DomU)
> 
> >From what I read, there is already a patch to fix that, called "multi
> page ring support for block devices" : 
>    http://lists.xen.org/archives/html/xen-devel/2012-03/msg00388.html
> 
> But it doesn't seem to have been accepted.
> 
> So, does it exist an other solution to fix that kind of problem ?

They are in development.
> 
> Thanks,
> Olivier
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 15 15:44:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:44: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 1U6NSk-0003sf-65; Fri, 15 Feb 2013 15:44:34 +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 1U6NSi-0003sU-F5
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:44:32 +0000
Received: from [193.109.254.147:51433] by server-15.bemta-14.messagelabs.com
	id AD/28-24599-FD75E115; Fri, 15 Feb 2013 15:44:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1360942936!8586842!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11139 invoked from network); 15 Feb 2013 15:42:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 15:42:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FFgBpj021363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 15:42:12 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
	r1FFgAY4026139
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 15:42:11 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
	r1FFgA17011399; Fri, 15 Feb 2013 09:42:10 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 07:42:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2CBF51C387B; Fri, 15 Feb 2013 10:42:09 -0500 (EST)
Date: Fri, 15 Feb 2013 10:42:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olivier Bonvalet <xen.list@daevel.fr>
Message-ID: <20130215154209.GA13439@phenom.dumpdata.com>
References: <1360431862.27289.8.camel@boolette.noo>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360431862.27289.8.camel@boolette.noo>
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" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [blkfront] max_segments & max_segment_size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 09, 2013 at 06:44:22PM +0100, Olivier Bonvalet wrote:
> Hi,
> 
> I have (very) poor write performance with Xen PV, used over RBD, and I
> suppose it's because of very short values for max_segments and
> max_segment_size.
> (I have 250MB/s write speed in Dom0 vs 40MB/s write speed in DomU)
> 
> >From what I read, there is already a patch to fix that, called "multi
> page ring support for block devices" : 
>    http://lists.xen.org/archives/html/xen-devel/2012-03/msg00388.html
> 
> But it doesn't seem to have been accepted.
> 
> So, does it exist an other solution to fix that kind of problem ?

They are in development.
> 
> Thanks,
> Olivier
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 15 15:47:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:47: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 1U6NVL-00042R-Ol; Fri, 15 Feb 2013 15:47: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 1U6NVK-00042K-MH
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:47:14 +0000
Received: from [85.158.143.35:18062] by server-2.bemta-4.messagelabs.com id
	EE/7F-01597-2885E115; Fri, 15 Feb 2013 15:47:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360943206!10257173!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24339 invoked from network); 15 Feb 2013 15:46:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:46:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:46:46 +0000
Message-Id: <511E667202000078000BECB7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:46:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
	<1360927883.31407.11.camel@zakaz.uk.xensource.com>
	<20130215151406.GD12178@phenom.dumpdata.com>
In-Reply-To: <20130215151406.GD12178@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 16:14, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Feb 15, 2013 at 11:31:23AM +0000, Ian Campbell wrote:
>> On Fri, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
>> > >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
>> > >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>> > >> index 83e866d..f7a080e 100644
>> > >> --- a/arch/x86/xen/spinlock.c
>> > >> +++ b/arch/x86/xen/spinlock.c
>> > >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
>> > > xen_spinlock *xl)
>> > >>  		if (per_cpu(lock_spinners, cpu) == xl) {
>> > >>  			ADD_STATS(released_slow_kicked, 1);
>> > >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
>> > >> -			break;
>> > > 
>> > > It would be more efficient to build a mask and use xen_send_IPI_mask().
>> > 
>> > In order for __xen_send_IPI_mask() to then take the list apart
>> > again and call xen_send_IPI_one()? There's no batching
>> > implemented currently...
>> 
>> Oh, I simply assumed it must obviously do that!
> 
> Perhaps if it was done via a multicall? We could batch then things up. But I 
> recall you saying that for homogeneous calls it is silly to use multicalls.

Aren't you mixing this up with it being pointless to use multicalls
for things that already allow for batching, like grant table ops?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:47:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:47: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 1U6NVL-00042R-Ol; Fri, 15 Feb 2013 15:47: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 1U6NVK-00042K-MH
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:47:14 +0000
Received: from [85.158.143.35:18062] by server-2.bemta-4.messagelabs.com id
	EE/7F-01597-2885E115; Fri, 15 Feb 2013 15:47:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1360943206!10257173!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24339 invoked from network); 15 Feb 2013 15:46:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 15:46:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 15:46:46 +0000
Message-Id: <511E667202000078000BECB7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 15:46:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
	<1360927883.31407.11.camel@zakaz.uk.xensource.com>
	<20130215151406.GD12178@phenom.dumpdata.com>
In-Reply-To: <20130215151406.GD12178@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 16:14, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Feb 15, 2013 at 11:31:23AM +0000, Ian Campbell wrote:
>> On Fri, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
>> > >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
>> > >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>> > >> index 83e866d..f7a080e 100644
>> > >> --- a/arch/x86/xen/spinlock.c
>> > >> +++ b/arch/x86/xen/spinlock.c
>> > >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
>> > > xen_spinlock *xl)
>> > >>  		if (per_cpu(lock_spinners, cpu) == xl) {
>> > >>  			ADD_STATS(released_slow_kicked, 1);
>> > >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
>> > >> -			break;
>> > > 
>> > > It would be more efficient to build a mask and use xen_send_IPI_mask().
>> > 
>> > In order for __xen_send_IPI_mask() to then take the list apart
>> > again and call xen_send_IPI_one()? There's no batching
>> > implemented currently...
>> 
>> Oh, I simply assumed it must obviously do that!
> 
> Perhaps if it was done via a multicall? We could batch then things up. But I 
> recall you saying that for homogeneous calls it is silly to use multicalls.

Aren't you mixing this up with it being pointless to use multicalls
for things that already allow for batching, like grant table ops?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:48:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:48: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 1U6NWe-0004AK-B4; Fri, 15 Feb 2013 15:48:36 +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 1U6NWd-0004AC-QH
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 15:48:36 +0000
Received: from [85.158.137.99:39614] by server-8.bemta-3.messagelabs.com id
	F0/0F-25687-EC85E115; Fri, 15 Feb 2013 15:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360943309!19325832!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28600 invoked from network); 15 Feb 2013 15:48:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1521393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 15:48: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.297.1; Fri, 15 Feb 2013 15:48:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6NWX-0005yv-1M; Fri, 15 Feb 2013 15:48:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6NWW-0000xF-TS;
	Fri, 15 Feb 2013 15:48:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.22732.806518.892544@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 15:48:28 +0000
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="stdvga"|"cirrus"
> 
> - Default option is cirrus.
> - Prints error and exit if unknown value is passed.
> - stdvga parameter is now deprecated.
> - Updated xl.cfg man.
> 
> Required patch: Improve videoram setting v5
> Is prerequisite for patch: Add qxl support v9

The code looks good to me, but there are a couple of formatting
problems.  Your wrapping of the longer lines is odd (particularly, you
fail to indent the continuations), and there's a spurious space after
xlu_cfg_get_string.  Can you please repost following the style used
elsewhere ?

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 Feb 15 15:48:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 15:48: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 1U6NWe-0004AK-B4; Fri, 15 Feb 2013 15:48:36 +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 1U6NWd-0004AC-QH
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 15:48:36 +0000
Received: from [85.158.137.99:39614] by server-8.bemta-3.messagelabs.com id
	F0/0F-25687-EC85E115; Fri, 15 Feb 2013 15:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360943309!19325832!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28600 invoked from network); 15 Feb 2013 15:48:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:48:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1521393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 15:48: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.297.1; Fri, 15 Feb 2013 15:48:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U6NWX-0005yv-1M; Fri, 15 Feb 2013 15:48:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U6NWW-0000xF-TS;
	Fri, 15 Feb 2013 15:48:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20766.22732.806518.892544@mariner.uk.xensource.com>
Date: Fri, 15 Feb 2013 15:48:28 +0000
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
	domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="stdvga"|"cirrus"
> 
> - Default option is cirrus.
> - Prints error and exit if unknown value is passed.
> - stdvga parameter is now deprecated.
> - Updated xl.cfg man.
> 
> Required patch: Improve videoram setting v5
> Is prerequisite for patch: Add qxl support v9

The code looks good to me, but there are a couple of formatting
problems.  Your wrapping of the longer lines is odd (particularly, you
fail to indent the continuations), and there's a spurious space after
xlu_cfg_get_string.  Can you please repost following the style used
elsewhere ?

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 Feb 15 15:59:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6Ngy-0004WS-FH; Fri, 15 Feb 2013 15:59: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 1U6Ngx-0004WN-35
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:59:15 +0000
Received: from [85.158.137.99:30004] by server-16.bemta-3.messagelabs.com id
	DB/C7-02727-25B5E115; Fri, 15 Feb 2013 15:59:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360943944!18219494!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16063 invoked from network); 15 Feb 2013 15:59:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:59:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1522024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 15:59: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.297.1;
	Fri, 15 Feb 2013 15:59:04 +0000
Message-ID: <1360943942.31407.94.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 15:59:02 +0000
In-Reply-To: <511E667202000078000BECB7@nat28.tlf.novell.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
	<1360927883.31407.11.camel@zakaz.uk.xensource.com>
	<20130215151406.GD12178@phenom.dumpdata.com>
	<511E667202000078000BECB7@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 15:46 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 16:14, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Fri, Feb 15, 2013 at 11:31:23AM +0000, Ian Campbell wrote:
> >> On Fri, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
> >> > >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> >> > >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> >> > >> index 83e866d..f7a080e 100644
> >> > >> --- a/arch/x86/xen/spinlock.c
> >> > >> +++ b/arch/x86/xen/spinlock.c
> >> > >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> >> > > xen_spinlock *xl)
> >> > >>  		if (per_cpu(lock_spinners, cpu) == xl) {
> >> > >>  			ADD_STATS(released_slow_kicked, 1);
> >> > >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> >> > >> -			break;
> >> > > 
> >> > > It would be more efficient to build a mask and use xen_send_IPI_mask().
> >> > 
> >> > In order for __xen_send_IPI_mask() to then take the list apart
> >> > again and call xen_send_IPI_one()? There's no batching
> >> > implemented currently...
> >> 
> >> Oh, I simply assumed it must obviously do that!
> > 
> > Perhaps if it was done via a multicall? We could batch then things up. But I 
> > recall you saying that for homogeneous calls it is silly to use multicalls.
> 
> Aren't you mixing this up with it being pointless to use multicalls
> for things that already allow for batching, like grant table ops?

Right, it is only silly to use multicalls for homogeneous calls which
already natively support batching.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 15:59:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6Ngy-0004WS-FH; Fri, 15 Feb 2013 15:59: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 1U6Ngx-0004WN-35
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 15:59:15 +0000
Received: from [85.158.137.99:30004] by server-16.bemta-3.messagelabs.com id
	DB/C7-02727-25B5E115; Fri, 15 Feb 2013 15:59:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1360943944!18219494!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16063 invoked from network); 15 Feb 2013 15:59:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 15:59:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1522024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 15:59: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.297.1;
	Fri, 15 Feb 2013 15:59:04 +0000
Message-ID: <1360943942.31407.94.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 15:59:02 +0000
In-Reply-To: <511E667202000078000BECB7@nat28.tlf.novell.com>
References: <1360925555-15078-1-git-send-email-stefan.bader@canonical.com>
	<1360926607.31407.10.camel@zakaz.uk.xensource.com>
	<511E296D02000078000BEA27@nat28.tlf.novell.com>
	<1360927883.31407.11.camel@zakaz.uk.xensource.com>
	<20130215151406.GD12178@phenom.dumpdata.com>
	<511E667202000078000BECB7@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: Send spinlock IPI to all waiters
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 15:46 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 16:14, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Fri, Feb 15, 2013 at 11:31:23AM +0000, Ian Campbell wrote:
> >> On Fri, 2013-02-15 at 11:26 +0000, Jan Beulich wrote:
> >> > >>> On 15.02.13 at 12:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > > On Fri, 2013-02-15 at 10:52 +0000, Stefan Bader wrote:
> >> > >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> >> > >> index 83e866d..f7a080e 100644
> >> > >> --- a/arch/x86/xen/spinlock.c
> >> > >> +++ b/arch/x86/xen/spinlock.c
> >> > >> @@ -328,7 +328,6 @@ static noinline void xen_spin_unlock_slow(struct 
> >> > > xen_spinlock *xl)
> >> > >>  		if (per_cpu(lock_spinners, cpu) == xl) {
> >> > >>  			ADD_STATS(released_slow_kicked, 1);
> >> > >>  			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> >> > >> -			break;
> >> > > 
> >> > > It would be more efficient to build a mask and use xen_send_IPI_mask().
> >> > 
> >> > In order for __xen_send_IPI_mask() to then take the list apart
> >> > again and call xen_send_IPI_one()? There's no batching
> >> > implemented currently...
> >> 
> >> Oh, I simply assumed it must obviously do that!
> > 
> > Perhaps if it was done via a multicall? We could batch then things up. But I 
> > recall you saying that for homogeneous calls it is silly to use multicalls.
> 
> Aren't you mixing this up with it being pointless to use multicalls
> for things that already allow for batching, like grant table ops?

Right, it is only silly to use multicalls for homogeneous calls which
already natively support batching.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:00:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6Ni6-0004y3-U9; Fri, 15 Feb 2013 16:00: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 1U6Ni4-0004sv-Tt
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 16:00:25 +0000
Received: from [85.158.139.211:58641] by server-11.bemta-5.messagelabs.com id
	3E/97-19159-89B5E115; Fri, 15 Feb 2013 16:00:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360944022!22640490!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6002 invoked from network); 15 Feb 2013 16:00:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:00:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1522058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 16:00: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.297.1;
	Fri, 15 Feb 2013 16:00:23 +0000
Message-ID: <1360944021.31407.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 15 Feb 2013 16:00:21 +0000
In-Reply-To: <20766.22732.806518.892544@mariner.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Fabio
	Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 15:48 +0000, Ian Jackson wrote:
> fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > Usage:
> >   vga="stdvga"|"cirrus"
> > 
> > - Default option is cirrus.
> > - Prints error and exit if unknown value is passed.
> > - stdvga parameter is now deprecated.
> > - Updated xl.cfg man.
> > 
> > Required patch: Improve videoram setting v5
> > Is prerequisite for patch: Add qxl support v9
> 
> The code looks good to me, but there are a couple of formatting
> problems.  Your wrapping of the longer lines is odd (particularly, you
> fail to indent the continuations), and there's a spurious space after
> xlu_cfg_get_string.  Can you please repost following the style used
> elsewhere ?

I'm afraid I have already committed this. Sorry for not noticing these
style errors.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:00:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6Ni6-0004y3-U9; Fri, 15 Feb 2013 16:00: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 1U6Ni4-0004sv-Tt
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 16:00:25 +0000
Received: from [85.158.139.211:58641] by server-11.bemta-5.messagelabs.com id
	3E/97-19159-89B5E115; Fri, 15 Feb 2013 16:00:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1360944022!22640490!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6002 invoked from network); 15 Feb 2013 16:00:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:00:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1522058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 16:00: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.297.1;
	Fri, 15 Feb 2013 16:00:23 +0000
Message-ID: <1360944021.31407.95.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 15 Feb 2013 16:00:21 +0000
In-Reply-To: <20766.22732.806518.892544@mariner.uk.xensource.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Fabio
	Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 15:48 +0000, Ian Jackson wrote:
> fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
> > From: Fabio Fantoni <fabio.fantoni@heliman.it>
> > 
> > Usage:
> >   vga="stdvga"|"cirrus"
> > 
> > - Default option is cirrus.
> > - Prints error and exit if unknown value is passed.
> > - stdvga parameter is now deprecated.
> > - Updated xl.cfg man.
> > 
> > Required patch: Improve videoram setting v5
> > Is prerequisite for patch: Add qxl support v9
> 
> The code looks good to me, but there are a couple of formatting
> problems.  Your wrapping of the longer lines is odd (particularly, you
> fail to indent the continuations), and there's a spurious space after
> xlu_cfg_get_string.  Can you please repost following the style used
> elsewhere ?

I'm afraid I have already committed this. Sorry for not noticing these
style errors.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:01:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:01: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 1U6Nic-00051D-Cl; Fri, 15 Feb 2013 16:00:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U6Nib-000510-0z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:00:57 +0000
Received: from [85.158.138.51:30125] by server-5.bemta-3.messagelabs.com id
	23/45-04457-8BB5E115; Fri, 15 Feb 2013 16:00:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360944053!27816507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15153 invoked from network); 15 Feb 2013 16:00:55 -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;
	15 Feb 2013 16:00:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7324903"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-GM;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:04 +0000
Message-ID: <1360944010-15336-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] netback: get/put module along with vif
	connect/disconnect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 there is vif running and user unloads netback, guest's network interface
just mysteriously stops working. So we need to prevent unloading netback
module if there is vif running.

The disconnect function of vif may get called by the generic framework even
before vif connects, so thers is an extra check on whether we actually need to
put module when disconnecting a vif.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 221f426..db638e1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -314,6 +314,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -341,6 +343,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
+	module_put(THIS_MODULE);
 	return err;
 }
 
@@ -358,18 +361,31 @@ void xenvif_carrier_off(struct xenvif *vif)
 
 void xenvif_disconnect(struct xenvif *vif)
 {
+	/*
+	 * This function may get called even before vif connets, set
+	 * need_module_put if vif->irq != 0, which means vif has
+	 * already connected, we should call module_put to balance the
+	 * previous __module_get.
+	 */
+	int need_module_put = 0;
+
 	if (netif_carrier_ok(vif->dev))
 		xenvif_carrier_off(vif);
 
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
 
-	if (vif->irq)
+	if (vif->irq) {
 		unbind_from_irqhandler(vif->irq, vif);
+		need_module_put = 1;
+	}
 
 	unregister_netdev(vif->dev);
 
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	if (need_module_put)
+		module_put(THIS_MODULE);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:01:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:01: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 1U6Nic-00051D-Cl; Fri, 15 Feb 2013 16:00:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U6Nib-000510-0z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:00:57 +0000
Received: from [85.158.138.51:30125] by server-5.bemta-3.messagelabs.com id
	23/45-04457-8BB5E115; Fri, 15 Feb 2013 16:00:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1360944053!27816507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15153 invoked from network); 15 Feb 2013 16:00:55 -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;
	15 Feb 2013 16:00:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7324903"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-GM;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:04 +0000
Message-ID: <1360944010-15336-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] netback: get/put module along with vif
	connect/disconnect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 there is vif running and user unloads netback, guest's network interface
just mysteriously stops working. So we need to prevent unloading netback
module if there is vif running.

The disconnect function of vif may get called by the generic framework even
before vif connects, so thers is an extra check on whether we actually need to
put module when disconnecting a vif.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 221f426..db638e1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -314,6 +314,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -341,6 +343,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
+	module_put(THIS_MODULE);
 	return err;
 }
 
@@ -358,18 +361,31 @@ void xenvif_carrier_off(struct xenvif *vif)
 
 void xenvif_disconnect(struct xenvif *vif)
 {
+	/*
+	 * This function may get called even before vif connets, set
+	 * need_module_put if vif->irq != 0, which means vif has
+	 * already connected, we should call module_put to balance the
+	 * previous __module_get.
+	 */
+	int need_module_put = 0;
+
 	if (netif_carrier_ok(vif->dev))
 		xenvif_carrier_off(vif);
 
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
 
-	if (vif->irq)
+	if (vif->irq) {
 		unbind_from_irqhandler(vif->irq, vif);
+		need_module_put = 1;
+	}
 
 	unregister_netdev(vif->dev);
 
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	if (need_module_put)
+		module_put(THIS_MODULE);
 }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6NjZ-00057u-Rx; Fri, 15 Feb 2013 16:01:57 +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 1U6NjZ-00057i-9z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:01:57 +0000
Received: from [193.109.254.147:65226] by server-5.bemta-14.messagelabs.com id
	B4/F6-21539-4FB5E115; Fri, 15 Feb 2013 16:01:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26542 invoked from network); 15 Feb 2013 16:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697855"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-BU;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:01 +0000
Message-ID: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen network
	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

This patch series contains a small fix plus mechanical works for xen network
driver.

 * bug fix: don't bind kthread to specific cpu core
 * allow host admin to unload netback
 * multi-page ring support
 * split event channels support


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6NjZ-00057u-Rx; Fri, 15 Feb 2013 16:01:57 +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 1U6NjZ-00057i-9z
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:01:57 +0000
Received: from [193.109.254.147:65226] by server-5.bemta-14.messagelabs.com id
	B4/F6-21539-4FB5E115; Fri, 15 Feb 2013 16:01:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26542 invoked from network); 15 Feb 2013 16:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697855"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-BU;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:01 +0000
Message-ID: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen network
	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

This patch series contains a small fix plus mechanical works for xen network
driver.

 * bug fix: don't bind kthread to specific cpu core
 * allow host admin to unload netback
 * multi-page ring support
 * split event channels support


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njc-00058d-MG; Fri, 15 Feb 2013 16:02:00 +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 1U6Nja-000587-No
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:01:58 +0000
Received: from [193.109.254.147:2385] by server-16.bemta-14.messagelabs.com id
	5D/93-25906-6FB5E115; Fri, 15 Feb 2013 16:01:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 15 Feb 2013 16:01:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697857"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-FC;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:03 +0000
Message-ID: <1360944010-15336-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] netback: add module unload 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

Enable users to unload netback module. Users should make sure there is not vif
runnig.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   18 ++++++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 24 insertions(+)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 9d7f172..35d8772 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -120,6 +120,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index db8d45a..de59098 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1761,5 +1761,23 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int group, i;
+	xenvif_xenbus_exit();
+	for (group = 0; group < xen_netbk_group_nr; group++) {
+		struct xen_netbk *netbk = &xen_netbk[group];
+		for (i = 0; i < MAX_PENDING_REQS; i++) {
+			if (netbk->mmap_pages[i])
+				__free_page(netbk->mmap_pages[i]);
+		}
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+}
+
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njc-00058d-MG; Fri, 15 Feb 2013 16:02:00 +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 1U6Nja-000587-No
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:01:58 +0000
Received: from [193.109.254.147:2385] by server-16.bemta-14.messagelabs.com id
	5D/93-25906-6FB5E115; Fri, 15 Feb 2013 16:01:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26673 invoked from network); 15 Feb 2013 16:01:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697857"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-FC;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:03 +0000
Message-ID: <1360944010-15336-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] netback: add module unload 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

Enable users to unload netback module. Users should make sure there is not vif
runnig.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   18 ++++++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 24 insertions(+)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 9d7f172..35d8772 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -120,6 +120,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index db8d45a..de59098 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1761,5 +1761,23 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int group, i;
+	xenvif_xenbus_exit();
+	for (group = 0; group < xen_netbk_group_nr; group++) {
+		struct xen_netbk *netbk = &xen_netbk[group];
+		for (i = 0; i < MAX_PENDING_REQS; i++) {
+			if (netbk->mmap_pages[i])
+				__free_page(netbk->mmap_pages[i]);
+		}
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+}
+
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njb-00058I-9K; Fri, 15 Feb 2013 16:01:59 +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 1U6Nja-00057s-0c
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:01:58 +0000
Received: from [193.109.254.147:65266] by server-7.bemta-14.messagelabs.com id
	50/DE-13581-5FB5E115; Fri, 15 Feb 2013 16:01:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26609 invoked from network); 15 Feb 2013 16:01:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697856"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-DK;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:02 +0000
Message-ID: <1360944010-15336-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] netback: don't bind kthread to 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

The initialization process makes an assumption that the online cpus are
numbered from 0 to xen_netbk_group_nr-1,  which is not always true.

As we only need a pool of worker threads, simply don't bind them to specific
cpus.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3ae49b1..db8d45a 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1729,8 +1729,6 @@ static int __init netback_init(void)
 			goto failed_init;
 		}
 
-		kthread_bind(netbk->task, group);
-
 		INIT_LIST_HEAD(&netbk->net_schedule_list);
 
 		spin_lock_init(&netbk->net_schedule_list_lock);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njb-00058I-9K; Fri, 15 Feb 2013 16:01:59 +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 1U6Nja-00057s-0c
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:01:58 +0000
Received: from [193.109.254.147:65266] by server-7.bemta-14.messagelabs.com id
	50/DE-13581-5FB5E115; Fri, 15 Feb 2013 16:01:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26609 invoked from network); 15 Feb 2013 16:01:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697856"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-DK;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:02 +0000
Message-ID: <1360944010-15336-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] netback: don't bind kthread to 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

The initialization process makes an assumption that the online cpus are
numbered from 0 to xen_netbk_group_nr-1,  which is not always true.

As we only need a pool of worker threads, simply don't bind them to specific
cpus.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3ae49b1..db8d45a 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1729,8 +1729,6 @@ static int __init netback_init(void)
 			goto failed_init;
 		}
 
-		kthread_bind(netbk->task, group);
-
 		INIT_LIST_HEAD(&netbk->net_schedule_list);
 
 		spin_lock_init(&netbk->net_schedule_list_lock);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njd-00058v-57; Fri, 15 Feb 2013 16:02:01 +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 1U6Njb-00058K-NY
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:00 +0000
Received: from [193.109.254.147:6527] by server-11.bemta-14.messagelabs.com id
	11/9D-30685-7FB5E115; Fri, 15 Feb 2013 16:01:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26720 invoked from network); 15 Feb 2013 16:01:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697860"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Kd;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:08 +0000
Message-ID: <1360944010-15336-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] netback: split event channels 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

Netback and netfront only use one event channel to do tx / rx notification.
This may cause unnecessary wake-up of process routines. This patch adds a new
feature called feautre-split-event-channel to netback, enabling it to handle
Tx and Rx event separately.

Netback will use tx_irq to notify guest for tx completion, rx_irq for rx
notification.

If frontend doesn't support this feature, tx_irq = rx_irq.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   10 +++--
 drivers/net/xen-netback/interface.c |   78 ++++++++++++++++++++++++++++-------
 drivers/net/xen-netback/netback.c   |    7 ++--
 drivers/net/xen-netback/xenbus.c    |   44 ++++++++++++++++----
 4 files changed, 109 insertions(+), 30 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f541ba9..cc2a9f0 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -63,8 +63,11 @@ struct xenvif {
 
 	u8               fe_dev_addr[6];
 
-	/* Physical parameters of the comms window. */
-	unsigned int     irq;
+	/* Physical parameters of the comms window.
+	 * When feature-split-event-channels = 0, tx_irq = rx_irq.
+	 */
+	unsigned int tx_irq;
+	unsigned int rx_irq;
 
 	/* List of frontends to notify after a batch of frames sent. */
 	struct list_head notify_list;
@@ -122,10 +125,11 @@ struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
+/* When feature-split-event-channels == 0, tx_evtchn == rx_evtchn */
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long *tx_ring_ref, unsigned int tx_ring_order,
 		   unsigned long *rx_ring_ref, unsigned int rx_ring_order,
-		   unsigned int evtchn);
+		   unsigned int tx_evtchn, unsigned int rx_evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 void xenvif_get(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index fa4d46d..c9ebe21 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -60,7 +60,8 @@ static int xenvif_rx_schedulable(struct xenvif *vif)
 	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
 }
 
-static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+/* Tx interrupt handler used when feature-split-event-channels == 1 */
+static irqreturn_t xenvif_tx_interrupt(int tx_irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
@@ -69,12 +70,31 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 
 	xen_netbk_schedule_xenvif(vif);
 
+	return IRQ_HANDLED;
+}
+
+/* Rx interrupt handler used when feature-split-event-channels == 1 */
+static irqreturn_t xenvif_rx_interrupt(int rx_irq, void *dev_id)
+{
+	struct xenvif *vif = dev_id;
+
+	if (vif->netbk == NULL)
+		return IRQ_NONE;
+
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
 	return IRQ_HANDLED;
 }
 
+/* Used when feature-split-event-channels == 0 */
+static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+{
+	xenvif_tx_interrupt(irq, dev_id);
+	xenvif_rx_interrupt(irq, dev_id);
+	return IRQ_HANDLED;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -125,13 +145,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 static void xenvif_up(struct xenvif *vif)
 {
 	xen_netbk_add_xenvif(vif);
-	enable_irq(vif->irq);
+	enable_irq(vif->tx_irq);
+	enable_irq(vif->rx_irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
-	disable_irq(vif->irq);
+	disable_irq(vif->tx_irq);
+	disable_irq(vif->rx_irq);
 	del_timer_sync(&vif->credit_timeout);
 	xen_netbk_deschedule_xenvif(vif);
 	xen_netbk_remove_xenvif(vif);
@@ -308,7 +330,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long *tx_ring_ref, unsigned int tx_ring_ref_count,
 		   unsigned long *rx_ring_ref, unsigned int rx_ring_ref_count,
-		   unsigned int evtchn)
+		   unsigned int tx_evtchn, unsigned int rx_evtchn)
 {
 	int err = -ENOMEM;
 	void *addr;
@@ -317,7 +339,7 @@ int xenvif_connect(struct xenvif *vif,
 	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
-	if (vif->irq)
+	if (vif->tx_irq)
 		return 0;
 
 	__module_get(THIS_MODULE);
@@ -347,13 +369,32 @@ int xenvif_connect(struct xenvif *vif,
 	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
 	vif->nr_rx_handles = rx_ring_ref_count;
 
-	err = bind_interdomain_evtchn_to_irqhandler(
-		vif->domid, evtchn, xenvif_interrupt, 0,
-		vif->dev->name, vif);
-	if (err < 0)
-		goto err_rx_unmap;
-	vif->irq = err;
-	disable_irq(vif->irq);
+	if (tx_evtchn == rx_evtchn) { /* feature-split-event-channels == 0 */
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = vif->rx_irq = err;
+		disable_irq(vif->tx_irq);
+		disable_irq(vif->rx_irq);
+	} else { /* feature-split-event-channels == 1 */
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = err;
+		disable_irq(vif->tx_irq);
+
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_tx_unbind;
+		vif->rx_irq = err;
+		disable_irq(vif->rx_irq);
+	}
 
 	xenvif_get(vif);
 
@@ -367,6 +408,10 @@ int xenvif_connect(struct xenvif *vif,
 	rtnl_unlock();
 
 	return 0;
+
+err_tx_unbind:
+	unbind_from_irqhandler(vif->tx_irq, vif);
+	vif->tx_irq = 0;
 err_rx_unmap:
 	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
 	vif->nr_rx_handles = 0;
@@ -406,8 +451,13 @@ void xenvif_disconnect(struct xenvif *vif)
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
 
-	if (vif->irq) {
-		unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq) {
+		if (vif->tx_irq == vif->rx_irq)
+			unbind_from_irqhandler(vif->tx_irq, vif);
+		else {
+			unbind_from_irqhandler(vif->tx_irq, vif);
+			unbind_from_irqhandler(vif->rx_irq, vif);
+		}
 		need_module_put = 1;
 	}
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 644c760..5ac8c35 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -639,7 +639,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 {
 	struct xenvif *vif = NULL, *tmp;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -750,7 +750,6 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
 		if (ret && list_empty(&vif->notify_list))
 			list_add_tail(&vif->notify_list, &notify);
 
@@ -762,7 +761,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	}
 
 	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->rx_irq);
 		list_del_init(&vif->notify_list);
 	}
 
@@ -1595,7 +1594,7 @@ static void make_tx_response(struct xenvif *vif,
 	vif->tx.rsp_prod_pvt = ++i;
 	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->tx, notify);
 	if (notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->tx_irq);
 }
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 1791807..6822d89 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -141,6 +141,15 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		/* Split event channels support */
+		err = xenbus_printf(xbt, dev->nodename,
+				    "feature-split-event-channels",
+				    "%u", 1);
+		if (err) {
+			message = "writing feature-split-event-channels";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -419,7 +428,7 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned int evtchn, rx_copy;
+	unsigned int tx_evtchn, rx_evtchn, rx_copy;
 	int err;
 	int val;
 	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
@@ -428,12 +437,22 @@ static int connect_rings(struct backend_info *be)
 	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "event-channel", "%u", &evtchn, NULL);
+			    "event-channel", "%u", &tx_evtchn, NULL);
 	if (err) {
-		xenbus_dev_fatal(dev, err,
-				 "reading %s/event-channel",
-				 dev->otherend);
-		return err;
+		/* try split event channels */
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-tx", "%u", &tx_evtchn,
+				    "event-channel-rx", "%u", &rx_evtchn,
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel(-tx/rx)",
+					 dev->otherend);
+			return err;
+		}
+	} else { /* frontend doesn't support split event channels */
+		rx_evtchn = tx_evtchn;
+		dev_info(&dev->dev, "single event channel\n");
 	}
 
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
@@ -568,12 +587,19 @@ static int connect_rings(struct backend_info *be)
 	/* Map the shared frame, irq etc. */
 	err = xenvif_connect(vif, tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn);
+			     tx_evtchn, rx_evtchn);
 	if (err) {
 		/* construct 1 2 3 / 4 5 6 */
 		int i;
 		char txs[3 * (1U << MODPARM_netback_max_tx_ring_page_order)];
 		char rxs[3 * (1U << MODPARM_netback_max_rx_ring_page_order)];
+		char evtchns[20];
+
+		if (tx_evtchn == rx_evtchn)
+			snprintf(evtchns, sizeof(evtchns)-1, "%u", tx_evtchn);
+		else
+			snprintf(evtchns, sizeof(evtchns)-1, "%u/%u",
+				 tx_evtchn, rx_evtchn);
 
 		txs[0] = rxs[0] = 0;
 
@@ -586,8 +612,8 @@ static int connect_rings(struct backend_info *be)
 				 " %lu", rx_ring_ref[i]);
 
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames%s /%s port %u",
-				 txs, rxs, evtchn);
+				 "mapping shared-frames%s /%s port %s",
+				 txs, rxs, evtchns);
 		return err;
 	}
 	return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njd-00058v-57; Fri, 15 Feb 2013 16:02:01 +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 1U6Njb-00058K-NY
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:00 +0000
Received: from [193.109.254.147:6527] by server-11.bemta-14.messagelabs.com id
	11/9D-30685-7FB5E115; Fri, 15 Feb 2013 16:01:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26720 invoked from network); 15 Feb 2013 16:01:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697860"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Kd;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:08 +0000
Message-ID: <1360944010-15336-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] netback: split event channels 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

Netback and netfront only use one event channel to do tx / rx notification.
This may cause unnecessary wake-up of process routines. This patch adds a new
feature called feautre-split-event-channel to netback, enabling it to handle
Tx and Rx event separately.

Netback will use tx_irq to notify guest for tx completion, rx_irq for rx
notification.

If frontend doesn't support this feature, tx_irq = rx_irq.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   10 +++--
 drivers/net/xen-netback/interface.c |   78 ++++++++++++++++++++++++++++-------
 drivers/net/xen-netback/netback.c   |    7 ++--
 drivers/net/xen-netback/xenbus.c    |   44 ++++++++++++++++----
 4 files changed, 109 insertions(+), 30 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f541ba9..cc2a9f0 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -63,8 +63,11 @@ struct xenvif {
 
 	u8               fe_dev_addr[6];
 
-	/* Physical parameters of the comms window. */
-	unsigned int     irq;
+	/* Physical parameters of the comms window.
+	 * When feature-split-event-channels = 0, tx_irq = rx_irq.
+	 */
+	unsigned int tx_irq;
+	unsigned int rx_irq;
 
 	/* List of frontends to notify after a batch of frames sent. */
 	struct list_head notify_list;
@@ -122,10 +125,11 @@ struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
+/* When feature-split-event-channels == 0, tx_evtchn == rx_evtchn */
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long *tx_ring_ref, unsigned int tx_ring_order,
 		   unsigned long *rx_ring_ref, unsigned int rx_ring_order,
-		   unsigned int evtchn);
+		   unsigned int tx_evtchn, unsigned int rx_evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 void xenvif_get(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index fa4d46d..c9ebe21 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -60,7 +60,8 @@ static int xenvif_rx_schedulable(struct xenvif *vif)
 	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
 }
 
-static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+/* Tx interrupt handler used when feature-split-event-channels == 1 */
+static irqreturn_t xenvif_tx_interrupt(int tx_irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
@@ -69,12 +70,31 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 
 	xen_netbk_schedule_xenvif(vif);
 
+	return IRQ_HANDLED;
+}
+
+/* Rx interrupt handler used when feature-split-event-channels == 1 */
+static irqreturn_t xenvif_rx_interrupt(int rx_irq, void *dev_id)
+{
+	struct xenvif *vif = dev_id;
+
+	if (vif->netbk == NULL)
+		return IRQ_NONE;
+
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
 	return IRQ_HANDLED;
 }
 
+/* Used when feature-split-event-channels == 0 */
+static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+{
+	xenvif_tx_interrupt(irq, dev_id);
+	xenvif_rx_interrupt(irq, dev_id);
+	return IRQ_HANDLED;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -125,13 +145,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 static void xenvif_up(struct xenvif *vif)
 {
 	xen_netbk_add_xenvif(vif);
-	enable_irq(vif->irq);
+	enable_irq(vif->tx_irq);
+	enable_irq(vif->rx_irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
-	disable_irq(vif->irq);
+	disable_irq(vif->tx_irq);
+	disable_irq(vif->rx_irq);
 	del_timer_sync(&vif->credit_timeout);
 	xen_netbk_deschedule_xenvif(vif);
 	xen_netbk_remove_xenvif(vif);
@@ -308,7 +330,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long *tx_ring_ref, unsigned int tx_ring_ref_count,
 		   unsigned long *rx_ring_ref, unsigned int rx_ring_ref_count,
-		   unsigned int evtchn)
+		   unsigned int tx_evtchn, unsigned int rx_evtchn)
 {
 	int err = -ENOMEM;
 	void *addr;
@@ -317,7 +339,7 @@ int xenvif_connect(struct xenvif *vif,
 	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
-	if (vif->irq)
+	if (vif->tx_irq)
 		return 0;
 
 	__module_get(THIS_MODULE);
@@ -347,13 +369,32 @@ int xenvif_connect(struct xenvif *vif,
 	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
 	vif->nr_rx_handles = rx_ring_ref_count;
 
-	err = bind_interdomain_evtchn_to_irqhandler(
-		vif->domid, evtchn, xenvif_interrupt, 0,
-		vif->dev->name, vif);
-	if (err < 0)
-		goto err_rx_unmap;
-	vif->irq = err;
-	disable_irq(vif->irq);
+	if (tx_evtchn == rx_evtchn) { /* feature-split-event-channels == 0 */
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = vif->rx_irq = err;
+		disable_irq(vif->tx_irq);
+		disable_irq(vif->rx_irq);
+	} else { /* feature-split-event-channels == 1 */
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, tx_evtchn, xenvif_tx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = err;
+		disable_irq(vif->tx_irq);
+
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, rx_evtchn, xenvif_rx_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_tx_unbind;
+		vif->rx_irq = err;
+		disable_irq(vif->rx_irq);
+	}
 
 	xenvif_get(vif);
 
@@ -367,6 +408,10 @@ int xenvif_connect(struct xenvif *vif,
 	rtnl_unlock();
 
 	return 0;
+
+err_tx_unbind:
+	unbind_from_irqhandler(vif->tx_irq, vif);
+	vif->tx_irq = 0;
 err_rx_unmap:
 	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
 	vif->nr_rx_handles = 0;
@@ -406,8 +451,13 @@ void xenvif_disconnect(struct xenvif *vif)
 	atomic_dec(&vif->refcnt);
 	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
 
-	if (vif->irq) {
-		unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq) {
+		if (vif->tx_irq == vif->rx_irq)
+			unbind_from_irqhandler(vif->tx_irq, vif);
+		else {
+			unbind_from_irqhandler(vif->tx_irq, vif);
+			unbind_from_irqhandler(vif->rx_irq, vif);
+		}
 		need_module_put = 1;
 	}
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 644c760..5ac8c35 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -639,7 +639,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 {
 	struct xenvif *vif = NULL, *tmp;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -750,7 +750,6 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
 		if (ret && list_empty(&vif->notify_list))
 			list_add_tail(&vif->notify_list, &notify);
 
@@ -762,7 +761,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	}
 
 	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->rx_irq);
 		list_del_init(&vif->notify_list);
 	}
 
@@ -1595,7 +1594,7 @@ static void make_tx_response(struct xenvif *vif,
 	vif->tx.rsp_prod_pvt = ++i;
 	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->tx, notify);
 	if (notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->tx_irq);
 }
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 1791807..6822d89 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -141,6 +141,15 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		/* Split event channels support */
+		err = xenbus_printf(xbt, dev->nodename,
+				    "feature-split-event-channels",
+				    "%u", 1);
+		if (err) {
+			message = "writing feature-split-event-channels";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -419,7 +428,7 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned int evtchn, rx_copy;
+	unsigned int tx_evtchn, rx_evtchn, rx_copy;
 	int err;
 	int val;
 	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
@@ -428,12 +437,22 @@ static int connect_rings(struct backend_info *be)
 	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "event-channel", "%u", &evtchn, NULL);
+			    "event-channel", "%u", &tx_evtchn, NULL);
 	if (err) {
-		xenbus_dev_fatal(dev, err,
-				 "reading %s/event-channel",
-				 dev->otherend);
-		return err;
+		/* try split event channels */
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-tx", "%u", &tx_evtchn,
+				    "event-channel-rx", "%u", &rx_evtchn,
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel(-tx/rx)",
+					 dev->otherend);
+			return err;
+		}
+	} else { /* frontend doesn't support split event channels */
+		rx_evtchn = tx_evtchn;
+		dev_info(&dev->dev, "single event channel\n");
 	}
 
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
@@ -568,12 +587,19 @@ static int connect_rings(struct backend_info *be)
 	/* Map the shared frame, irq etc. */
 	err = xenvif_connect(vif, tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn);
+			     tx_evtchn, rx_evtchn);
 	if (err) {
 		/* construct 1 2 3 / 4 5 6 */
 		int i;
 		char txs[3 * (1U << MODPARM_netback_max_tx_ring_page_order)];
 		char rxs[3 * (1U << MODPARM_netback_max_rx_ring_page_order)];
+		char evtchns[20];
+
+		if (tx_evtchn == rx_evtchn)
+			snprintf(evtchns, sizeof(evtchns)-1, "%u", tx_evtchn);
+		else
+			snprintf(evtchns, sizeof(evtchns)-1, "%u/%u",
+				 tx_evtchn, rx_evtchn);
 
 		txs[0] = rxs[0] = 0;
 
@@ -586,8 +612,8 @@ static int connect_rings(struct backend_info *be)
 				 " %lu", rx_ring_ref[i]);
 
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames%s /%s port %u",
-				 txs, rxs, evtchn);
+				 "mapping shared-frames%s /%s port %s",
+				 txs, rxs, evtchns);
 		return err;
 	}
 	return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njd-000597-Jc; Fri, 15 Feb 2013 16:02:01 +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 1U6Njc-00058U-DW
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:00 +0000
Received: from [193.109.254.147:6564] by server-9.bemta-14.messagelabs.com id
	F8/75-30867-7FB5E115; Fri, 15 Feb 2013 16:01:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26761 invoked from network); 15 Feb 2013 16:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697862"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Lf;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:09 +0000
Message-ID: <1360944010-15336-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] netfront: split event channels 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

If this feature is not activated, rx_irq = tx_irq. See corresponding netback
change log for details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  184 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 152 insertions(+), 32 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index de73a71..ea9b656 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -100,7 +100,12 @@ struct netfront_info {
 
 	struct napi_struct napi;
 
-	unsigned int evtchn;
+	/* 
+	 * Split event channels support, tx_* == rx_* when using
+	 * single event channel.
+	 */
+	unsigned int tx_evtchn, rx_evtchn;
+	unsigned int tx_irq, rx_irq;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
@@ -344,7 +349,7 @@ no_skb:
  push:
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->rx_irq);
 }
 
 static int xennet_open(struct net_device *dev)
@@ -633,7 +638,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->tx_irq);
 
 	u64_stats_update_begin(&stats->syncp);
 	stats->tx_bytes += skb->len;
@@ -1263,26 +1268,41 @@ static int xennet_set_features(struct net_device *dev,
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+/* Used for tx completion */
+static irqreturn_t xennet_tx_interrupt(int tx_irq, void *dev_id)
 {
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
 	unsigned long flags;
 
 	spin_lock_irqsave(&np->tx_lock, flags);
+	xennet_tx_buf_gc(dev);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
+	return IRQ_HANDLED;
+}
 
-	spin_unlock_irqrestore(&np->tx_lock, flags);
+/* Used for rx */
+static irqreturn_t xennet_rx_interrupt(int rx_irq, void *dev_id)
+{
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
+
+	if (likely(netif_carrier_ok(dev) &&
+		   RING_HAS_UNCONSUMED_RESPONSES(&np->rx)))
+		napi_schedule(&np->napi);
 
 	return IRQ_HANDLED;
 }
 
+/* Used for single event channel configuration */
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	xennet_tx_interrupt(irq, dev_id);
+	xennet_rx_interrupt(irq, dev_id);
+	return IRQ_HANDLED;
+}
+
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static void xennet_poll_controller(struct net_device *dev)
 {
@@ -1451,9 +1471,14 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 	spin_unlock_irq(&info->tx_lock);
 	spin_unlock_bh(&info->rx_lock);
 
-	if (info->netdev->irq)
-		unbind_from_irqhandler(info->netdev->irq, info->netdev);
-	info->evtchn = info->netdev->irq = 0;
+	if (info->tx_irq && (info->tx_irq == info->rx_irq))
+		unbind_from_irqhandler(info->tx_irq, info);
+	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
+		unbind_from_irqhandler(info->tx_irq, info);
+		unbind_from_irqhandler(info->rx_irq, info);
+	}
+	info->tx_evtchn = info->rx_evtchn = 0;
+	info->tx_irq = info->rx_irq = 0;
 
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
 	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
@@ -1503,11 +1528,86 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
 	return 0;
 }
 
+static int setup_netfront_single(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+	if (err < 0)
+		goto fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_fail;
+	info->rx_evtchn = info->tx_evtchn;
+	info->rx_irq = info->tx_irq = err;
+	dev_info(&info->xbdev->dev,
+		 "single event channel, evtchn = %d, irq = %d\n",
+		 info->tx_evtchn, info->tx_irq);
+
+	return 0;
+
+bind_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+	info->tx_evtchn = 0;
+fail:
+	return err;
+}
+
+static int setup_netfront_split(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+	if (err)
+		goto fail;
+	err = xenbus_alloc_evtchn(info->xbdev, &info->rx_evtchn);
+	if (err)
+		goto alloc_rx_evtchn_fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_tx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_tx_fail;
+	info->tx_irq = err;
+
+	err = bind_evtchn_to_irqhandler(info->rx_evtchn,
+					xennet_rx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_rx_fail;
+
+	info->rx_irq = err;
+
+	dev_info(&info->xbdev->dev,
+		 "split event channels, tx_evtchn/irq = %d/%d, rx_evtchn/irq = %d/%d",
+		 info->tx_evtchn, info->tx_irq,
+		 info->rx_evtchn, info->rx_irq);
+
+	return 0;
+
+bind_rx_fail:
+	unbind_from_irqhandler(info->tx_irq, info);
+	info->tx_irq = 0;
+bind_tx_fail:
+	xenbus_free_evtchn(info->xbdev, info->rx_evtchn);
+	info->rx_evtchn = 0;
+alloc_rx_evtchn_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+	info->tx_evtchn = 0;
+fail:
+	return err;
+}
+
 static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 {
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	unsigned int feature_split_evtchn;
 	struct net_device *netdev = info->netdev;
 	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
 	int i;
@@ -1527,6 +1627,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 
 	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-split-event-channels", "%u",
+			   &feature_split_evtchn);
+	if (err < 0)
+		feature_split_evtchn = 0;
+
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
 			   "max-tx-ring-page-order", "%u",
 			   &max_tx_ring_page_order);
 	if (err < 0) {
@@ -1598,20 +1704,17 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	if (err < 0)
 		goto grant_rx_ring_fail;
 
-	err = xenbus_alloc_evtchn(dev, &info->evtchn);
+	if (feature_split_evtchn)
+		err = setup_netfront_split(info);
+	else
+		err = setup_netfront_single(info);
+
 	if (err)
-		goto alloc_evtchn_fail;
+		goto setup_evtchn_fail;
 
-	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					0, netdev->name, netdev);
-	if (err < 0)
-		goto bind_fail;
-	netdev->irq = err;
 	return 0;
 
-bind_fail:
-	xenbus_free_evtchn(dev, info->evtchn);
-alloc_evtchn_fail:
+setup_evtchn_fail:
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
 grant_rx_ring_fail:
 	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
@@ -1696,11 +1799,26 @@ again:
 		}
 	}
 
-	err = xenbus_printf(xbt, dev->nodename,
-			    "event-channel", "%u", info->evtchn);
-	if (err) {
-		message = "writing event-channel";
-		goto abort_transaction;
+	if (info->tx_evtchn == info->rx_evtchn) {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-tx", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel-tx";
+			goto abort_transaction;
+		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-rx", "%u", info->rx_evtchn);
+		if (err) {
+			message = "writing event-channel-rx";
+			goto abort_transaction;
+		}
 	}
 
 	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
@@ -1814,7 +1932,9 @@ static int xennet_connect(struct net_device *dev)
 	 * packets.
 	 */
 	netif_carrier_on(np->netdev);
-	notify_remote_via_irq(np->netdev->irq);
+	notify_remote_via_irq(np->tx_irq);
+	if (np->tx_irq != np->rx_irq)
+		notify_remote_via_irq(np->rx_irq);
 	xennet_tx_buf_gc(dev);
 	xennet_alloc_rx_buffers(dev);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njd-000597-Jc; Fri, 15 Feb 2013 16:02:01 +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 1U6Njc-00058U-DW
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:00 +0000
Received: from [193.109.254.147:6564] by server-9.bemta-14.messagelabs.com id
	F8/75-30867-7FB5E115; Fri, 15 Feb 2013 16:01:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26761 invoked from network); 15 Feb 2013 16:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697862"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Lf;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:09 +0000
Message-ID: <1360944010-15336-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] netfront: split event channels 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

If this feature is not activated, rx_irq = tx_irq. See corresponding netback
change log for details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  184 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 152 insertions(+), 32 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index de73a71..ea9b656 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -100,7 +100,12 @@ struct netfront_info {
 
 	struct napi_struct napi;
 
-	unsigned int evtchn;
+	/* 
+	 * Split event channels support, tx_* == rx_* when using
+	 * single event channel.
+	 */
+	unsigned int tx_evtchn, rx_evtchn;
+	unsigned int tx_irq, rx_irq;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
@@ -344,7 +349,7 @@ no_skb:
  push:
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->rx_irq);
 }
 
 static int xennet_open(struct net_device *dev)
@@ -633,7 +638,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->tx_irq);
 
 	u64_stats_update_begin(&stats->syncp);
 	stats->tx_bytes += skb->len;
@@ -1263,26 +1268,41 @@ static int xennet_set_features(struct net_device *dev,
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+/* Used for tx completion */
+static irqreturn_t xennet_tx_interrupt(int tx_irq, void *dev_id)
 {
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
 	unsigned long flags;
 
 	spin_lock_irqsave(&np->tx_lock, flags);
+	xennet_tx_buf_gc(dev);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
+	return IRQ_HANDLED;
+}
 
-	spin_unlock_irqrestore(&np->tx_lock, flags);
+/* Used for rx */
+static irqreturn_t xennet_rx_interrupt(int rx_irq, void *dev_id)
+{
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
+
+	if (likely(netif_carrier_ok(dev) &&
+		   RING_HAS_UNCONSUMED_RESPONSES(&np->rx)))
+		napi_schedule(&np->napi);
 
 	return IRQ_HANDLED;
 }
 
+/* Used for single event channel configuration */
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	xennet_tx_interrupt(irq, dev_id);
+	xennet_rx_interrupt(irq, dev_id);
+	return IRQ_HANDLED;
+}
+
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static void xennet_poll_controller(struct net_device *dev)
 {
@@ -1451,9 +1471,14 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 	spin_unlock_irq(&info->tx_lock);
 	spin_unlock_bh(&info->rx_lock);
 
-	if (info->netdev->irq)
-		unbind_from_irqhandler(info->netdev->irq, info->netdev);
-	info->evtchn = info->netdev->irq = 0;
+	if (info->tx_irq && (info->tx_irq == info->rx_irq))
+		unbind_from_irqhandler(info->tx_irq, info);
+	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
+		unbind_from_irqhandler(info->tx_irq, info);
+		unbind_from_irqhandler(info->rx_irq, info);
+	}
+	info->tx_evtchn = info->rx_evtchn = 0;
+	info->tx_irq = info->rx_irq = 0;
 
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
 	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
@@ -1503,11 +1528,86 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
 	return 0;
 }
 
+static int setup_netfront_single(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+	if (err < 0)
+		goto fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_fail;
+	info->rx_evtchn = info->tx_evtchn;
+	info->rx_irq = info->tx_irq = err;
+	dev_info(&info->xbdev->dev,
+		 "single event channel, evtchn = %d, irq = %d\n",
+		 info->tx_evtchn, info->tx_irq);
+
+	return 0;
+
+bind_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+	info->tx_evtchn = 0;
+fail:
+	return err;
+}
+
+static int setup_netfront_split(struct netfront_info *info)
+{
+	int err;
+
+	err = xenbus_alloc_evtchn(info->xbdev, &info->tx_evtchn);
+	if (err)
+		goto fail;
+	err = xenbus_alloc_evtchn(info->xbdev, &info->rx_evtchn);
+	if (err)
+		goto alloc_rx_evtchn_fail;
+
+	err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+					xennet_tx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_tx_fail;
+	info->tx_irq = err;
+
+	err = bind_evtchn_to_irqhandler(info->rx_evtchn,
+					xennet_rx_interrupt,
+					0, info->netdev->name, info);
+	if (err < 0)
+		goto bind_rx_fail;
+
+	info->rx_irq = err;
+
+	dev_info(&info->xbdev->dev,
+		 "split event channels, tx_evtchn/irq = %d/%d, rx_evtchn/irq = %d/%d",
+		 info->tx_evtchn, info->tx_irq,
+		 info->rx_evtchn, info->rx_irq);
+
+	return 0;
+
+bind_rx_fail:
+	unbind_from_irqhandler(info->tx_irq, info);
+	info->tx_irq = 0;
+bind_tx_fail:
+	xenbus_free_evtchn(info->xbdev, info->rx_evtchn);
+	info->rx_evtchn = 0;
+alloc_rx_evtchn_fail:
+	xenbus_free_evtchn(info->xbdev, info->tx_evtchn);
+	info->tx_evtchn = 0;
+fail:
+	return err;
+}
+
 static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 {
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	unsigned int feature_split_evtchn;
 	struct net_device *netdev = info->netdev;
 	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
 	int i;
@@ -1527,6 +1627,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 
 	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "feature-split-event-channels", "%u",
+			   &feature_split_evtchn);
+	if (err < 0)
+		feature_split_evtchn = 0;
+
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
 			   "max-tx-ring-page-order", "%u",
 			   &max_tx_ring_page_order);
 	if (err < 0) {
@@ -1598,20 +1704,17 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	if (err < 0)
 		goto grant_rx_ring_fail;
 
-	err = xenbus_alloc_evtchn(dev, &info->evtchn);
+	if (feature_split_evtchn)
+		err = setup_netfront_split(info);
+	else
+		err = setup_netfront_single(info);
+
 	if (err)
-		goto alloc_evtchn_fail;
+		goto setup_evtchn_fail;
 
-	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					0, netdev->name, netdev);
-	if (err < 0)
-		goto bind_fail;
-	netdev->irq = err;
 	return 0;
 
-bind_fail:
-	xenbus_free_evtchn(dev, info->evtchn);
-alloc_evtchn_fail:
+setup_evtchn_fail:
 	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
 grant_rx_ring_fail:
 	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
@@ -1696,11 +1799,26 @@ again:
 		}
 	}
 
-	err = xenbus_printf(xbt, dev->nodename,
-			    "event-channel", "%u", info->evtchn);
-	if (err) {
-		message = "writing event-channel";
-		goto abort_transaction;
+	if (info->tx_evtchn == info->rx_evtchn) {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-tx", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel-tx";
+			goto abort_transaction;
+		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-rx", "%u", info->rx_evtchn);
+		if (err) {
+			message = "writing event-channel-rx";
+			goto abort_transaction;
+		}
 	}
 
 	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
@@ -1814,7 +1932,9 @@ static int xennet_connect(struct net_device *dev)
 	 * packets.
 	 */
 	netif_carrier_on(np->netdev);
-	notify_remote_via_irq(np->netdev->irq);
+	notify_remote_via_irq(np->tx_irq);
+	if (np->tx_irq != np->rx_irq)
+		notify_remote_via_irq(np->rx_irq);
 	xennet_tx_buf_gc(dev);
 	xennet_alloc_rx_buffers(dev);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njf-0005AI-U6; Fri, 15 Feb 2013 16:02:03 +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 1U6Njd-000595-VP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:02 +0000
Received: from [193.109.254.147:8007] by server-8.bemta-14.messagelabs.com id
	9E/D0-17325-9FB5E115; Fri, 15 Feb 2013 16:02:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26797 invoked from network); 15 Feb 2013 16:01:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697864"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Hd;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:05 +0000
Message-ID: <1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to support
	multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bundle fixes for xen frontends and backends in this patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 drivers/block/xen-blkback/xenbus.c |   14 +-
 drivers/block/xen-blkfront.c       |    6 +-
 drivers/net/xen-netback/netback.c  |    4 +-
 drivers/net/xen-netfront.c         |    9 +-
 drivers/pci/xen-pcifront.c         |    5 +-
 drivers/xen/xen-pciback/xenbus.c   |   10 +-
 drivers/xen/xenbus/xenbus_client.c |  314 ++++++++++++++++++++++++++----------
 include/xen/xenbus.h               |   17 +-
 8 files changed, 270 insertions(+), 109 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 6398072..384ff24 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -122,7 +122,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	return blkif;
 }
 
-static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
+static int xen_blkif_map(struct xen_blkif *blkif, int *shared_pages,
+			 int nr_pages,
 			 unsigned int evtchn)
 {
 	int err;
@@ -131,7 +132,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
 	if (blkif->irq)
 		return 0;
 
-	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring);
+	err = xenbus_map_ring_valloc(blkif->be->dev, shared_pages,
+				     nr_pages, &blkif->blk_ring);
 	if (err < 0)
 		return err;
 
@@ -726,7 +728,7 @@ again:
 static int connect_ring(struct backend_info *be)
 {
 	struct xenbus_device *dev = be->dev;
-	unsigned long ring_ref;
+	int ring_ref;
 	unsigned int evtchn;
 	unsigned int pers_grants;
 	char protocol[64] = "";
@@ -767,14 +769,14 @@ static int connect_ring(struct backend_info *be)
 	be->blkif->vbd.feature_gnt_persistent = pers_grants;
 	be->blkif->vbd.overflow_max_grants = 0;
 
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) %s\n",
+	pr_info(DRV_PFX "ring-ref %d, event-channel %d, protocol %d (%s) %s\n",
 		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
 		pers_grants ? "persistent grants" : "");
 
 	/* Map the shared frame, irq etc. */
-	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
+	err = xen_blkif_map(be->blkif, &ring_ref, 1, evtchn);
 	if (err) {
-		xenbus_dev_fatal(dev, err, "mapping ring-ref %lu port %u",
+		xenbus_dev_fatal(dev, err, "mapping ring-ref %u port %u",
 				 ring_ref, evtchn);
 		return err;
 	}
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 96e9b00..12c9ebd 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -991,6 +991,7 @@ static int setup_blkring(struct xenbus_device *dev,
 {
 	struct blkif_sring *sring;
 	int err;
+	int grefs[1];
 
 	info->ring_ref = GRANT_INVALID_REF;
 
@@ -1004,13 +1005,14 @@ static int setup_blkring(struct xenbus_device *dev,
 
 	sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(info->ring.sring));
+	err = xenbus_grant_ring(dev, info->ring.sring,
+				1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)sring);
 		info->ring.sring = NULL;
 		goto fail;
 	}
-	info->ring_ref = err;
+	info->ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index de59098..98ccea9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1665,7 +1665,7 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	int err = -ENOMEM;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     tx_ring_ref, &addr);
+				     &tx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
@@ -1673,7 +1673,7 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     rx_ring_ref, &addr);
+				     &rx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 7ffa43b..8bd75a1 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1501,6 +1501,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	int grefs[1];
 	struct net_device *netdev = info->netdev;
 
 	info->tx_ring_ref = GRANT_INVALID_REF;
@@ -1524,13 +1525,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(txs);
 	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	err = xenbus_grant_ring(dev, txs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)txs);
 		goto fail;
 	}
 
-	info->tx_ring_ref = err;
+	info->tx_ring_ref = grefs[0];
 	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
@@ -1540,12 +1541,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(rxs);
 	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
+	err = xenbus_grant_ring(dev, rxs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)rxs);
 		goto fail;
 	}
-	info->rx_ring_ref = err;
+	info->rx_ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 966abc6..016a2bb 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -772,12 +772,13 @@ static int pcifront_publish_info(struct pcifront_device *pdev)
 {
 	int err = 0;
 	struct xenbus_transaction trans;
+	int grefs[1];
 
-	err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
+	err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, grefs);
 	if (err < 0)
 		goto out;
 
-	pdev->gnt_ref = err;
+	pdev->gnt_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
 	if (err)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 64b11f9..4655851 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -98,17 +98,17 @@ static void free_pdev(struct xen_pcibk_device *pdev)
 	kfree(pdev);
 }
 
-static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref,
-			     int remote_evtchn)
+static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int *gnt_ref,
+			       int nr_grefs, int remote_evtchn)
 {
 	int err = 0;
 	void *vaddr;
 
 	dev_dbg(&pdev->xdev->dev,
 		"Attaching to frontend resources - gnt_ref=%d evtchn=%d\n",
-		gnt_ref, remote_evtchn);
+		gnt_ref[0], remote_evtchn);
 
-	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr);
+	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, nr_grefs, &vaddr);
 	if (err < 0) {
 		xenbus_dev_fatal(pdev->xdev, err,
 				"Error mapping other domain page in ours.");
@@ -172,7 +172,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
 		goto out;
 	}
 
-	err = xen_pcibk_do_attach(pdev, gnt_ref, remote_evtchn);
+	err = xen_pcibk_do_attach(pdev, &gnt_ref, 1, remote_evtchn);
 	if (err)
 		goto out;
 
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1bac743..7c1bd49 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -54,14 +54,16 @@ struct xenbus_map_node {
 		struct vm_struct *area; /* PV */
 		struct page *page;     /* HVM */
 	};
-	grant_handle_t handle;
+	grant_handle_t handle[XENBUS_MAX_RING_PAGES];
+	unsigned int   nr_handles;
 };
 
 static DEFINE_SPINLOCK(xenbus_valloc_lock);
 static LIST_HEAD(xenbus_valloc_pages);
 
 struct xenbus_ring_ops {
-	int (*map)(struct xenbus_device *dev, int gnt, void **vaddr);
+	int (*map)(struct xenbus_device *dev, int *gnt, int nr_gnts,
+		   void **vaddr);
 	int (*unmap)(struct xenbus_device *dev, void *vaddr);
 };
 
@@ -357,17 +359,39 @@ static void xenbus_switch_fatal(struct xenbus_device *dev, int depth, int err,
 /**
  * xenbus_grant_ring
  * @dev: xenbus device
- * @ring_mfn: mfn of ring to grant
-
- * Grant access to the given @ring_mfn to the peer of the given device.  Return
- * 0 on success, or -errno on error.  On error, the device will switch to
+ * @vaddr: starting virtual address of the ring
+ * @nr_pages: number of pages to be granted
+ * @grefs: grant reference array to be filled in
+ *
+ * Grant access to the given @vaddr to the peer of the given device.
+ * Then fill in @grefs with grant references.  Return 0 on success, or
+ * -errno on error.  On error, the device will switch to
  * XenbusStateClosing, and the error will be saved in the store.
  */
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn)
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_pages, int *grefs)
 {
-	int err = gnttab_grant_foreign_access(dev->otherend_id, ring_mfn, 0);
-	if (err < 0)
-		xenbus_dev_fatal(dev, err, "granting access to ring page");
+	int i;
+	int err;
+
+	for (i = 0; i < nr_pages; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		err = gnttab_grant_foreign_access(dev->otherend_id,
+						  virt_to_mfn(addr), 0);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err,
+					 "granting access to ring page");
+			goto fail;
+		}
+		grefs[i] = err;
+	}
+
+	return 0;
+
+fail:
+	for ( ; i >= 0; i--)
+		gnttab_end_foreign_access_ref(grefs[i], 0);
 	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_grant_ring);
@@ -448,7 +472,8 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 /**
  * xenbus_map_ring_valloc
  * @dev: xenbus device
- * @gnt_ref: grant reference
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant references
  * @vaddr: pointer to address to be filled out by mapping
  *
  * Based on Rusty Russell's skeleton driver's map_page.
@@ -459,51 +484,61 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
  * or -ENOMEM on error. If an error is returned, device will switch to
  * XenbusStateClosing and the error message will be saved in XenStore.
  */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int *gnt_ref,
+			   int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_ref, vaddr);
+	return ring_ops->map(dev, gnt_ref, nr_grefs, vaddr);
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
-				     int gnt_ref, void **vaddr)
+				     int *gnt_ref, int nr_grefs, void **vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
-		.ref   = gnt_ref,
-		.dom   = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op;
 	struct xenbus_map_node *node;
 	struct vm_struct *area;
-	pte_t *pte;
+	pte_t *pte[XENBUS_MAX_RING_PAGES];
+	int i;
+	int err = GNTST_okay;
+	int vma_leaked; /* used in rollback */
 
 	*vaddr = NULL;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	area = alloc_vm_area(PAGE_SIZE, &pte);
+	area = alloc_vm_area(PAGE_SIZE * nr_grefs, pte);
 	if (!area) {
 		kfree(node);
 		return -ENOMEM;
 	}
 
-	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
-
-	if (op.status != GNTST_okay) {
-		free_vm_area(area);
-		kfree(node);
-		xenbus_dev_fatal(dev, op.status,
-				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-		return op.status;
+	/* Issue hypercall for individual entry, rollback if error occurs. */
+	for (i = 0; i < nr_grefs; i++) {
+		op.flags = GNTMAP_host_map | GNTMAP_contains_pte;
+		op.ref   = gnt_ref[i];
+		op.dom   = dev->otherend_id;
+		op.host_addr = arbitrary_virt_to_machine(pte[i]).maddr;
+
+		if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
+			BUG();
+
+		if (op.status != GNTST_okay) {
+			err = op.status;
+			xenbus_dev_fatal(dev, op.status,
+				 "mapping in shared page (%d/%d) %d from domain %d",
+				 i+1, nr_grefs, gnt_ref[i], dev->otherend_id);
+			node->handle[i] = INVALID_GRANT_HANDLE;
+			goto rollback;
+		} else
+			node->handle[i] = op.handle;
 	}
 
-	node->handle = op.handle;
+	node->nr_handles = nr_grefs;
 	node->area = area;
 
 	spin_lock(&xenbus_valloc_lock);
@@ -512,31 +547,73 @@ static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
 
 	*vaddr = area->addr;
 	return 0;
+
+rollback:
+	vma_leaked = 0;
+	for ( ; i >= 0; i--) {
+		if (node->handle[i] != INVALID_GRANT_HANDLE) {
+			struct gnttab_unmap_grant_ref unmap_op;
+			unmap_op.dev_bus_addr = 0;
+			unmap_op.host_addr =
+				arbitrary_virt_to_machine(pte[i]).maddr;
+			unmap_op.handle = node->handle[i];
+
+			if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+						      &unmap_op, 1))
+				BUG();
+
+			if (unmap_op.status != GNTST_okay) {
+				pr_alert("rollback mapping (%d/%d) %d from domain %d, err = %d",
+					 i+1, nr_grefs, gnt_ref[i],
+					 dev->otherend_id,
+					 unmap_op.status);
+				vma_leaked = 1;
+			}
+			node->handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
+
+	if (!vma_leaked)
+		free_vm_area(area);
+	else
+		pr_alert("leaking vm area %p size %d page(s)", area, nr_grefs);
+
+	kfree(node);
+
+	return err;
 }
 
 static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
-				      int gnt_ref, void **vaddr)
+				      int *gnt_ref, int nr_grefs, void **vaddr)
 {
 	struct xenbus_map_node *node;
 	int err;
 	void *addr;
+	int vma_leaked;
 
 	*vaddr = NULL;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	err = alloc_xenballooned_pages(nr_grefs, &node->page,
+				       false /* lowmem */);
 	if (err)
 		goto out_err;
 
 	addr = pfn_to_kaddr(page_to_pfn(node->page));
 
-	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	err = xenbus_map_ring(dev, gnt_ref, nr_grefs, node->handle,
+			      addr, &vma_leaked);
 	if (err)
 		goto out_err;
 
+	node->nr_handles = nr_grefs;
+
 	spin_lock(&xenbus_valloc_lock);
 	list_add(&node->next, &xenbus_valloc_pages);
 	spin_unlock(&xenbus_valloc_lock);
@@ -545,7 +622,8 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 	return 0;
 
  out_err:
-	free_xenballooned_pages(1, &node->page);
+	if (!vma_leaked)
+		free_xenballooned_pages(nr_grefs, &node->page);
 	kfree(node);
 	return err;
 }
@@ -554,36 +632,75 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 /**
  * xenbus_map_ring
  * @dev: xenbus device
- * @gnt_ref: grant reference
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant reference
  * @handle: pointer to grant handle to be filled
  * @vaddr: address to be mapped to
+ * @vma_leaked: cannot clean up a failed mapping, vma leaked
  *
- * Map a page of memory into this domain from another domain's grant table.
+ * Map pages of memory into this domain from another domain's grant table.
  * xenbus_map_ring does not allocate the virtual address space (you must do
- * this yourself!). It only maps in the page to the specified address.
+ * this yourself!). It only maps in the pages to the specified address.
  * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
  * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
+ * XenbusStateClosing and the last error message will be saved in XenStore.
  */
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-		    grant_handle_t *handle, void *vaddr)
+int xenbus_map_ring(struct xenbus_device *dev, int *gnt_ref, int nr_grefs,
+		    grant_handle_t *handle, void *vaddr, int *vma_leaked)
 {
 	struct gnttab_map_grant_ref op;
+	int i;
+	int err = GNTST_okay;
+
+	for (i = 0; i < nr_grefs; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		gnttab_set_map_op(&op, (unsigned long)addr,
+				  GNTMAP_host_map, gnt_ref[i],
+				  dev->otherend_id);
+
+		if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
+					      &op, 1))
+			BUG();
+
+		if (op.status != GNTST_okay) {
+			xenbus_dev_fatal(dev, op.status,
+				 "mapping in shared page (%d/%d) %d from domain %d",
+				 i+1, nr_grefs, gnt_ref[i], dev->otherend_id);
+			handle[i] = INVALID_GRANT_HANDLE;
+			goto rollback;
+		} else
+			handle[i] = op.handle;
+	}
 
-	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map, gnt_ref,
-			  dev->otherend_id);
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	return 0;
 
-	if (op.status != GNTST_okay) {
-		xenbus_dev_fatal(dev, op.status,
-				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-	} else
-		*handle = op.handle;
+rollback:
+	*vma_leaked = 0;
+	for ( ; i >= 0; i--) {
+		if (handle[i] != INVALID_GRANT_HANDLE) {
+			struct gnttab_unmap_grant_ref unmap_op;
+			unsigned long addr = (unsigned long)vaddr +
+				(PAGE_SIZE * i);
+			gnttab_set_unmap_op(&unmap_op, (phys_addr_t)addr,
+					    GNTMAP_host_map, handle[i]);
+
+			if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+						      &unmap_op, 1))
+				BUG();
+
+			if (unmap_op.status != GNTST_okay) {
+				pr_alert("rollback mapping (%d/%d) %d from domain %d, err = %d",
+					 i+1, nr_grefs, gnt_ref[i],
+					 dev->otherend_id,
+					 unmap_op.status);
+				*vma_leaked = 1;
+			}
+			handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
 
-	return op.status;
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
@@ -609,10 +726,11 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct xenbus_map_node *node;
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-	};
+	struct gnttab_unmap_grant_ref op[XENBUS_MAX_RING_PAGES];
 	unsigned int level;
+	int i;
+	int last_error = GNTST_okay;
+	int vma_leaked;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_for_each_entry(node, &xenbus_valloc_pages, next) {
@@ -631,22 +749,39 @@ static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = node->handle;
-	op.host_addr = arbitrary_virt_to_machine(
-		lookup_address((unsigned long)vaddr, &level)).maddr;
+	for (i = 0; i < node->nr_handles; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		op[i].dev_bus_addr = 0;
+		op[i].handle = node->handle[i];
+		op[i].host_addr = arbitrary_virt_to_machine(
+			lookup_address((unsigned long)addr, &level)).maddr;
+	}
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op,
+				      node->nr_handles))
 		BUG();
 
-	if (op.status == GNTST_okay)
+	vma_leaked = 0;
+	for (i = 0; i < node->nr_handles; i++) {
+		if (op[i].status != GNTST_okay) {
+			last_error = op[i].status;
+			vma_leaked = 1;
+			xenbus_dev_error(dev, op[i].status,
+				 "unmapping page (%d/%d) at handle %d error %d",
+				 i+1, node->nr_handles, node->handle[i],
+				 op[i].status);
+		}
+	}
+
+	if (!vma_leaked)
 		free_vm_area(node->area);
 	else
-		xenbus_dev_error(dev, op.status,
-				 "unmapping page at handle %d error %d",
-				 node->handle, op.status);
+		pr_alert("leaking vm area %p size %d page(s)",
+			 node->area, node->nr_handles);
 
 	kfree(node);
-	return op.status;
+	return last_error;
 }
 
 static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
@@ -673,10 +808,10 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	rv = xenbus_unmap_ring(dev, node->handle, addr);
+	rv = xenbus_unmap_ring(dev, node->handle, node->nr_handles, addr);
 
 	if (!rv)
-		free_xenballooned_pages(1, &node->page);
+		free_xenballooned_pages(node->nr_handles, &node->page);
 	else
 		WARN(1, "Leaking %p\n", vaddr);
 
@@ -687,7 +822,8 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 /**
  * xenbus_unmap_ring
  * @dev: xenbus device
- * @handle: grant handle
+ * @handle: grant handle array
+ * @nr_handles: number of grant handles
  * @vaddr: addr to unmap
  *
  * Unmap a page of memory in this domain that was imported from another domain.
@@ -695,21 +831,33 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
  * (see xen/include/interface/grant_table.h).
  */
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr)
+		      grant_handle_t *handle, int nr_handles,
+		      void *vaddr)
 {
 	struct gnttab_unmap_grant_ref op;
+	int last_error = GNTST_okay;
+	int i;
+
+	for (i = 0; i < nr_handles; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		gnttab_set_unmap_op(&op, (unsigned long)addr,
+				    GNTMAP_host_map, handle[i]);
+		handle[i] = INVALID_GRANT_HANDLE;
+
+		if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+					      &op, 1))
+			BUG();
+
+		if (op.status != GNTST_okay) {
+			xenbus_dev_error(dev, op.status,
+				 "unmapping page (%d/%d) at handle %d error %d",
+				 i+1, nr_handles, handle[i], op.status);
+			last_error = op.status;
+		}
+	}
 
-	gnttab_set_unmap_op(&op, (unsigned long)vaddr, GNTMAP_host_map, handle);
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
-		BUG();
-
-	if (op.status != GNTST_okay)
-		xenbus_dev_error(dev, op.status,
-				 "unmapping page at handle %d error %d",
-				 handle, op.status);
-
-	return op.status;
+	return last_error;
 }
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring);
 
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 0a7515c..b7d9613 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -46,6 +46,11 @@
 #include <xen/interface/io/xenbus.h>
 #include <xen/interface/io/xs_wire.h>
 
+/* Max pages supported by multi-page ring in the backend */
+#define XENBUS_MAX_RING_PAGE_ORDER  2
+#define XENBUS_MAX_RING_PAGES       (1U << XENBUS_MAX_RING_PAGE_ORDER)
+#define INVALID_GRANT_HANDLE        (~0U)
+
 /* Register callback to watch this node. */
 struct xenbus_watch
 {
@@ -195,15 +200,17 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch,
 			 const char *pathfmt, ...);
 
 int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn);
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_gages, int *grefs);
 int xenbus_map_ring_valloc(struct xenbus_device *dev,
-			   int gnt_ref, void **vaddr);
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-			   grant_handle_t *handle, void *vaddr);
+			   int *gnt_ref, int nr_grefs, void **vaddr);
+int xenbus_map_ring(struct xenbus_device *dev, int *gnt_ref, int nr_grefs,
+		    grant_handle_t *handle, void *vaddr, int *vma_leaked);
 
 int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr);
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr);
+		      grant_handle_t *handle, int nr_handles,
+		      void *vaddr);
 
 int xenbus_alloc_evtchn(struct xenbus_device *dev, int *port);
 int xenbus_bind_evtchn(struct xenbus_device *dev, int remote_port, int *port);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njf-0005AI-U6; Fri, 15 Feb 2013 16:02:03 +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 1U6Njd-000595-VP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:02 +0000
Received: from [193.109.254.147:8007] by server-8.bemta-14.messagelabs.com id
	9E/D0-17325-9FB5E115; Fri, 15 Feb 2013 16:02:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1360944113!8527079!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26797 invoked from network); 15 Feb 2013 16:01:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697864"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Hd;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:05 +0000
Message-ID: <1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to support
	multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bundle fixes for xen frontends and backends in this patch.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
---
 drivers/block/xen-blkback/xenbus.c |   14 +-
 drivers/block/xen-blkfront.c       |    6 +-
 drivers/net/xen-netback/netback.c  |    4 +-
 drivers/net/xen-netfront.c         |    9 +-
 drivers/pci/xen-pcifront.c         |    5 +-
 drivers/xen/xen-pciback/xenbus.c   |   10 +-
 drivers/xen/xenbus/xenbus_client.c |  314 ++++++++++++++++++++++++++----------
 include/xen/xenbus.h               |   17 +-
 8 files changed, 270 insertions(+), 109 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 6398072..384ff24 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -122,7 +122,8 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	return blkif;
 }
 
-static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
+static int xen_blkif_map(struct xen_blkif *blkif, int *shared_pages,
+			 int nr_pages,
 			 unsigned int evtchn)
 {
 	int err;
@@ -131,7 +132,8 @@ static int xen_blkif_map(struct xen_blkif *blkif, unsigned long shared_page,
 	if (blkif->irq)
 		return 0;
 
-	err = xenbus_map_ring_valloc(blkif->be->dev, shared_page, &blkif->blk_ring);
+	err = xenbus_map_ring_valloc(blkif->be->dev, shared_pages,
+				     nr_pages, &blkif->blk_ring);
 	if (err < 0)
 		return err;
 
@@ -726,7 +728,7 @@ again:
 static int connect_ring(struct backend_info *be)
 {
 	struct xenbus_device *dev = be->dev;
-	unsigned long ring_ref;
+	int ring_ref;
 	unsigned int evtchn;
 	unsigned int pers_grants;
 	char protocol[64] = "";
@@ -767,14 +769,14 @@ static int connect_ring(struct backend_info *be)
 	be->blkif->vbd.feature_gnt_persistent = pers_grants;
 	be->blkif->vbd.overflow_max_grants = 0;
 
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) %s\n",
+	pr_info(DRV_PFX "ring-ref %d, event-channel %d, protocol %d (%s) %s\n",
 		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
 		pers_grants ? "persistent grants" : "");
 
 	/* Map the shared frame, irq etc. */
-	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
+	err = xen_blkif_map(be->blkif, &ring_ref, 1, evtchn);
 	if (err) {
-		xenbus_dev_fatal(dev, err, "mapping ring-ref %lu port %u",
+		xenbus_dev_fatal(dev, err, "mapping ring-ref %u port %u",
 				 ring_ref, evtchn);
 		return err;
 	}
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 96e9b00..12c9ebd 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -991,6 +991,7 @@ static int setup_blkring(struct xenbus_device *dev,
 {
 	struct blkif_sring *sring;
 	int err;
+	int grefs[1];
 
 	info->ring_ref = GRANT_INVALID_REF;
 
@@ -1004,13 +1005,14 @@ static int setup_blkring(struct xenbus_device *dev,
 
 	sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(info->ring.sring));
+	err = xenbus_grant_ring(dev, info->ring.sring,
+				1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)sring);
 		info->ring.sring = NULL;
 		goto fail;
 	}
-	info->ring_ref = err;
+	info->ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index de59098..98ccea9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1665,7 +1665,7 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	int err = -ENOMEM;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     tx_ring_ref, &addr);
+				     &tx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
@@ -1673,7 +1673,7 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     rx_ring_ref, &addr);
+				     &rx_ring_ref, 1, &addr);
 	if (err)
 		goto err;
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 7ffa43b..8bd75a1 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1501,6 +1501,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
+	int grefs[1];
 	struct net_device *netdev = info->netdev;
 
 	info->tx_ring_ref = GRANT_INVALID_REF;
@@ -1524,13 +1525,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(txs);
 	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	err = xenbus_grant_ring(dev, txs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)txs);
 		goto fail;
 	}
 
-	info->tx_ring_ref = err;
+	info->tx_ring_ref = grefs[0];
 	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
@@ -1540,12 +1541,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	SHARED_RING_INIT(rxs);
 	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
+	err = xenbus_grant_ring(dev, rxs, 1, grefs);
 	if (err < 0) {
 		free_page((unsigned long)rxs);
 		goto fail;
 	}
-	info->rx_ring_ref = err;
+	info->rx_ring_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 966abc6..016a2bb 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -772,12 +772,13 @@ static int pcifront_publish_info(struct pcifront_device *pdev)
 {
 	int err = 0;
 	struct xenbus_transaction trans;
+	int grefs[1];
 
-	err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
+	err = xenbus_grant_ring(pdev->xdev, pdev->sh_info, 1, grefs);
 	if (err < 0)
 		goto out;
 
-	pdev->gnt_ref = err;
+	pdev->gnt_ref = grefs[0];
 
 	err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
 	if (err)
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 64b11f9..4655851 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -98,17 +98,17 @@ static void free_pdev(struct xen_pcibk_device *pdev)
 	kfree(pdev);
 }
 
-static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int gnt_ref,
-			     int remote_evtchn)
+static int xen_pcibk_do_attach(struct xen_pcibk_device *pdev, int *gnt_ref,
+			       int nr_grefs, int remote_evtchn)
 {
 	int err = 0;
 	void *vaddr;
 
 	dev_dbg(&pdev->xdev->dev,
 		"Attaching to frontend resources - gnt_ref=%d evtchn=%d\n",
-		gnt_ref, remote_evtchn);
+		gnt_ref[0], remote_evtchn);
 
-	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, &vaddr);
+	err = xenbus_map_ring_valloc(pdev->xdev, gnt_ref, nr_grefs, &vaddr);
 	if (err < 0) {
 		xenbus_dev_fatal(pdev->xdev, err,
 				"Error mapping other domain page in ours.");
@@ -172,7 +172,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
 		goto out;
 	}
 
-	err = xen_pcibk_do_attach(pdev, gnt_ref, remote_evtchn);
+	err = xen_pcibk_do_attach(pdev, &gnt_ref, 1, remote_evtchn);
 	if (err)
 		goto out;
 
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1bac743..7c1bd49 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -54,14 +54,16 @@ struct xenbus_map_node {
 		struct vm_struct *area; /* PV */
 		struct page *page;     /* HVM */
 	};
-	grant_handle_t handle;
+	grant_handle_t handle[XENBUS_MAX_RING_PAGES];
+	unsigned int   nr_handles;
 };
 
 static DEFINE_SPINLOCK(xenbus_valloc_lock);
 static LIST_HEAD(xenbus_valloc_pages);
 
 struct xenbus_ring_ops {
-	int (*map)(struct xenbus_device *dev, int gnt, void **vaddr);
+	int (*map)(struct xenbus_device *dev, int *gnt, int nr_gnts,
+		   void **vaddr);
 	int (*unmap)(struct xenbus_device *dev, void *vaddr);
 };
 
@@ -357,17 +359,39 @@ static void xenbus_switch_fatal(struct xenbus_device *dev, int depth, int err,
 /**
  * xenbus_grant_ring
  * @dev: xenbus device
- * @ring_mfn: mfn of ring to grant
-
- * Grant access to the given @ring_mfn to the peer of the given device.  Return
- * 0 on success, or -errno on error.  On error, the device will switch to
+ * @vaddr: starting virtual address of the ring
+ * @nr_pages: number of pages to be granted
+ * @grefs: grant reference array to be filled in
+ *
+ * Grant access to the given @vaddr to the peer of the given device.
+ * Then fill in @grefs with grant references.  Return 0 on success, or
+ * -errno on error.  On error, the device will switch to
  * XenbusStateClosing, and the error will be saved in the store.
  */
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn)
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_pages, int *grefs)
 {
-	int err = gnttab_grant_foreign_access(dev->otherend_id, ring_mfn, 0);
-	if (err < 0)
-		xenbus_dev_fatal(dev, err, "granting access to ring page");
+	int i;
+	int err;
+
+	for (i = 0; i < nr_pages; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		err = gnttab_grant_foreign_access(dev->otherend_id,
+						  virt_to_mfn(addr), 0);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err,
+					 "granting access to ring page");
+			goto fail;
+		}
+		grefs[i] = err;
+	}
+
+	return 0;
+
+fail:
+	for ( ; i >= 0; i--)
+		gnttab_end_foreign_access_ref(grefs[i], 0);
 	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_grant_ring);
@@ -448,7 +472,8 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 /**
  * xenbus_map_ring_valloc
  * @dev: xenbus device
- * @gnt_ref: grant reference
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant references
  * @vaddr: pointer to address to be filled out by mapping
  *
  * Based on Rusty Russell's skeleton driver's map_page.
@@ -459,51 +484,61 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
  * or -ENOMEM on error. If an error is returned, device will switch to
  * XenbusStateClosing and the error message will be saved in XenStore.
  */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int *gnt_ref,
+			   int nr_grefs, void **vaddr)
 {
-	return ring_ops->map(dev, gnt_ref, vaddr);
+	return ring_ops->map(dev, gnt_ref, nr_grefs, vaddr);
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
-				     int gnt_ref, void **vaddr)
+				     int *gnt_ref, int nr_grefs, void **vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
-		.ref   = gnt_ref,
-		.dom   = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op;
 	struct xenbus_map_node *node;
 	struct vm_struct *area;
-	pte_t *pte;
+	pte_t *pte[XENBUS_MAX_RING_PAGES];
+	int i;
+	int err = GNTST_okay;
+	int vma_leaked; /* used in rollback */
 
 	*vaddr = NULL;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	area = alloc_vm_area(PAGE_SIZE, &pte);
+	area = alloc_vm_area(PAGE_SIZE * nr_grefs, pte);
 	if (!area) {
 		kfree(node);
 		return -ENOMEM;
 	}
 
-	op.host_addr = arbitrary_virt_to_machine(pte).maddr;
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
-
-	if (op.status != GNTST_okay) {
-		free_vm_area(area);
-		kfree(node);
-		xenbus_dev_fatal(dev, op.status,
-				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-		return op.status;
+	/* Issue hypercall for individual entry, rollback if error occurs. */
+	for (i = 0; i < nr_grefs; i++) {
+		op.flags = GNTMAP_host_map | GNTMAP_contains_pte;
+		op.ref   = gnt_ref[i];
+		op.dom   = dev->otherend_id;
+		op.host_addr = arbitrary_virt_to_machine(pte[i]).maddr;
+
+		if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
+			BUG();
+
+		if (op.status != GNTST_okay) {
+			err = op.status;
+			xenbus_dev_fatal(dev, op.status,
+				 "mapping in shared page (%d/%d) %d from domain %d",
+				 i+1, nr_grefs, gnt_ref[i], dev->otherend_id);
+			node->handle[i] = INVALID_GRANT_HANDLE;
+			goto rollback;
+		} else
+			node->handle[i] = op.handle;
 	}
 
-	node->handle = op.handle;
+	node->nr_handles = nr_grefs;
 	node->area = area;
 
 	spin_lock(&xenbus_valloc_lock);
@@ -512,31 +547,73 @@ static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
 
 	*vaddr = area->addr;
 	return 0;
+
+rollback:
+	vma_leaked = 0;
+	for ( ; i >= 0; i--) {
+		if (node->handle[i] != INVALID_GRANT_HANDLE) {
+			struct gnttab_unmap_grant_ref unmap_op;
+			unmap_op.dev_bus_addr = 0;
+			unmap_op.host_addr =
+				arbitrary_virt_to_machine(pte[i]).maddr;
+			unmap_op.handle = node->handle[i];
+
+			if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+						      &unmap_op, 1))
+				BUG();
+
+			if (unmap_op.status != GNTST_okay) {
+				pr_alert("rollback mapping (%d/%d) %d from domain %d, err = %d",
+					 i+1, nr_grefs, gnt_ref[i],
+					 dev->otherend_id,
+					 unmap_op.status);
+				vma_leaked = 1;
+			}
+			node->handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
+
+	if (!vma_leaked)
+		free_vm_area(area);
+	else
+		pr_alert("leaking vm area %p size %d page(s)", area, nr_grefs);
+
+	kfree(node);
+
+	return err;
 }
 
 static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
-				      int gnt_ref, void **vaddr)
+				      int *gnt_ref, int nr_grefs, void **vaddr)
 {
 	struct xenbus_map_node *node;
 	int err;
 	void *addr;
+	int vma_leaked;
 
 	*vaddr = NULL;
 
+	if (nr_grefs > XENBUS_MAX_RING_PAGES)
+		return -EINVAL;
+
 	node = kzalloc(sizeof(*node), GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;
 
-	err = alloc_xenballooned_pages(1, &node->page, false /* lowmem */);
+	err = alloc_xenballooned_pages(nr_grefs, &node->page,
+				       false /* lowmem */);
 	if (err)
 		goto out_err;
 
 	addr = pfn_to_kaddr(page_to_pfn(node->page));
 
-	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	err = xenbus_map_ring(dev, gnt_ref, nr_grefs, node->handle,
+			      addr, &vma_leaked);
 	if (err)
 		goto out_err;
 
+	node->nr_handles = nr_grefs;
+
 	spin_lock(&xenbus_valloc_lock);
 	list_add(&node->next, &xenbus_valloc_pages);
 	spin_unlock(&xenbus_valloc_lock);
@@ -545,7 +622,8 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 	return 0;
 
  out_err:
-	free_xenballooned_pages(1, &node->page);
+	if (!vma_leaked)
+		free_xenballooned_pages(nr_grefs, &node->page);
 	kfree(node);
 	return err;
 }
@@ -554,36 +632,75 @@ static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
 /**
  * xenbus_map_ring
  * @dev: xenbus device
- * @gnt_ref: grant reference
+ * @gnt_ref: grant reference array
+ * @nr_grefs: number of grant reference
  * @handle: pointer to grant handle to be filled
  * @vaddr: address to be mapped to
+ * @vma_leaked: cannot clean up a failed mapping, vma leaked
  *
- * Map a page of memory into this domain from another domain's grant table.
+ * Map pages of memory into this domain from another domain's grant table.
  * xenbus_map_ring does not allocate the virtual address space (you must do
- * this yourself!). It only maps in the page to the specified address.
+ * this yourself!). It only maps in the pages to the specified address.
  * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
  * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
+ * XenbusStateClosing and the last error message will be saved in XenStore.
  */
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-		    grant_handle_t *handle, void *vaddr)
+int xenbus_map_ring(struct xenbus_device *dev, int *gnt_ref, int nr_grefs,
+		    grant_handle_t *handle, void *vaddr, int *vma_leaked)
 {
 	struct gnttab_map_grant_ref op;
+	int i;
+	int err = GNTST_okay;
+
+	for (i = 0; i < nr_grefs; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		gnttab_set_map_op(&op, (unsigned long)addr,
+				  GNTMAP_host_map, gnt_ref[i],
+				  dev->otherend_id);
+
+		if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
+					      &op, 1))
+			BUG();
+
+		if (op.status != GNTST_okay) {
+			xenbus_dev_fatal(dev, op.status,
+				 "mapping in shared page (%d/%d) %d from domain %d",
+				 i+1, nr_grefs, gnt_ref[i], dev->otherend_id);
+			handle[i] = INVALID_GRANT_HANDLE;
+			goto rollback;
+		} else
+			handle[i] = op.handle;
+	}
 
-	gnttab_set_map_op(&op, (unsigned long)vaddr, GNTMAP_host_map, gnt_ref,
-			  dev->otherend_id);
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
-		BUG();
+	return 0;
 
-	if (op.status != GNTST_okay) {
-		xenbus_dev_fatal(dev, op.status,
-				 "mapping in shared page %d from domain %d",
-				 gnt_ref, dev->otherend_id);
-	} else
-		*handle = op.handle;
+rollback:
+	*vma_leaked = 0;
+	for ( ; i >= 0; i--) {
+		if (handle[i] != INVALID_GRANT_HANDLE) {
+			struct gnttab_unmap_grant_ref unmap_op;
+			unsigned long addr = (unsigned long)vaddr +
+				(PAGE_SIZE * i);
+			gnttab_set_unmap_op(&unmap_op, (phys_addr_t)addr,
+					    GNTMAP_host_map, handle[i]);
+
+			if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+						      &unmap_op, 1))
+				BUG();
+
+			if (unmap_op.status != GNTST_okay) {
+				pr_alert("rollback mapping (%d/%d) %d from domain %d, err = %d",
+					 i+1, nr_grefs, gnt_ref[i],
+					 dev->otherend_id,
+					 unmap_op.status);
+				*vma_leaked = 1;
+			}
+			handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
 
-	return op.status;
+	return err;
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
@@ -609,10 +726,11 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct xenbus_map_node *node;
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-	};
+	struct gnttab_unmap_grant_ref op[XENBUS_MAX_RING_PAGES];
 	unsigned int level;
+	int i;
+	int last_error = GNTST_okay;
+	int vma_leaked;
 
 	spin_lock(&xenbus_valloc_lock);
 	list_for_each_entry(node, &xenbus_valloc_pages, next) {
@@ -631,22 +749,39 @@ static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	op.handle = node->handle;
-	op.host_addr = arbitrary_virt_to_machine(
-		lookup_address((unsigned long)vaddr, &level)).maddr;
+	for (i = 0; i < node->nr_handles; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		op[i].dev_bus_addr = 0;
+		op[i].handle = node->handle[i];
+		op[i].host_addr = arbitrary_virt_to_machine(
+			lookup_address((unsigned long)addr, &level)).maddr;
+	}
 
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
+	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, op,
+				      node->nr_handles))
 		BUG();
 
-	if (op.status == GNTST_okay)
+	vma_leaked = 0;
+	for (i = 0; i < node->nr_handles; i++) {
+		if (op[i].status != GNTST_okay) {
+			last_error = op[i].status;
+			vma_leaked = 1;
+			xenbus_dev_error(dev, op[i].status,
+				 "unmapping page (%d/%d) at handle %d error %d",
+				 i+1, node->nr_handles, node->handle[i],
+				 op[i].status);
+		}
+	}
+
+	if (!vma_leaked)
 		free_vm_area(node->area);
 	else
-		xenbus_dev_error(dev, op.status,
-				 "unmapping page at handle %d error %d",
-				 node->handle, op.status);
+		pr_alert("leaking vm area %p size %d page(s)",
+			 node->area, node->nr_handles);
 
 	kfree(node);
-	return op.status;
+	return last_error;
 }
 
 static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
@@ -673,10 +808,10 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 		return GNTST_bad_virt_addr;
 	}
 
-	rv = xenbus_unmap_ring(dev, node->handle, addr);
+	rv = xenbus_unmap_ring(dev, node->handle, node->nr_handles, addr);
 
 	if (!rv)
-		free_xenballooned_pages(1, &node->page);
+		free_xenballooned_pages(node->nr_handles, &node->page);
 	else
 		WARN(1, "Leaking %p\n", vaddr);
 
@@ -687,7 +822,8 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
 /**
  * xenbus_unmap_ring
  * @dev: xenbus device
- * @handle: grant handle
+ * @handle: grant handle array
+ * @nr_handles: number of grant handles
  * @vaddr: addr to unmap
  *
  * Unmap a page of memory in this domain that was imported from another domain.
@@ -695,21 +831,33 @@ static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
  * (see xen/include/interface/grant_table.h).
  */
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr)
+		      grant_handle_t *handle, int nr_handles,
+		      void *vaddr)
 {
 	struct gnttab_unmap_grant_ref op;
+	int last_error = GNTST_okay;
+	int i;
+
+	for (i = 0; i < nr_handles; i++) {
+		unsigned long addr = (unsigned long)vaddr +
+			(PAGE_SIZE * i);
+		gnttab_set_unmap_op(&op, (unsigned long)addr,
+				    GNTMAP_host_map, handle[i]);
+		handle[i] = INVALID_GRANT_HANDLE;
+
+		if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+					      &op, 1))
+			BUG();
+
+		if (op.status != GNTST_okay) {
+			xenbus_dev_error(dev, op.status,
+				 "unmapping page (%d/%d) at handle %d error %d",
+				 i+1, nr_handles, handle[i], op.status);
+			last_error = op.status;
+		}
+	}
 
-	gnttab_set_unmap_op(&op, (unsigned long)vaddr, GNTMAP_host_map, handle);
-
-	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
-		BUG();
-
-	if (op.status != GNTST_okay)
-		xenbus_dev_error(dev, op.status,
-				 "unmapping page at handle %d error %d",
-				 handle, op.status);
-
-	return op.status;
+	return last_error;
 }
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring);
 
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 0a7515c..b7d9613 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -46,6 +46,11 @@
 #include <xen/interface/io/xenbus.h>
 #include <xen/interface/io/xs_wire.h>
 
+/* Max pages supported by multi-page ring in the backend */
+#define XENBUS_MAX_RING_PAGE_ORDER  2
+#define XENBUS_MAX_RING_PAGES       (1U << XENBUS_MAX_RING_PAGE_ORDER)
+#define INVALID_GRANT_HANDLE        (~0U)
+
 /* Register callback to watch this node. */
 struct xenbus_watch
 {
@@ -195,15 +200,17 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch,
 			 const char *pathfmt, ...);
 
 int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);
-int xenbus_grant_ring(struct xenbus_device *dev, unsigned long ring_mfn);
+int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
+		      int nr_gages, int *grefs);
 int xenbus_map_ring_valloc(struct xenbus_device *dev,
-			   int gnt_ref, void **vaddr);
-int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
-			   grant_handle_t *handle, void *vaddr);
+			   int *gnt_ref, int nr_grefs, void **vaddr);
+int xenbus_map_ring(struct xenbus_device *dev, int *gnt_ref, int nr_grefs,
+		    grant_handle_t *handle, void *vaddr, int *vma_leaked);
 
 int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr);
 int xenbus_unmap_ring(struct xenbus_device *dev,
-		      grant_handle_t handle, void *vaddr);
+		      grant_handle_t *handle, int nr_handles,
+		      void *vaddr);
 
 int xenbus_alloc_evtchn(struct xenbus_device *dev, int *port);
 int xenbus_bind_evtchn(struct xenbus_device *dev, int remote_port, int *port);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njg-0005Ad-Bi; Fri, 15 Feb 2013 16:02:04 +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 1U6Njd-000593-SP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:02 +0000
Received: from [85.158.139.211:18401] by server-14.bemta-5.messagelabs.com id
	D3/A4-06967-9FB5E115; Fri, 15 Feb 2013 16:02:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360944117!22681763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8334 invoked from network); 15 Feb 2013 16:01:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697863"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-JY;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:07 +0000
Message-ID: <1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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>
---
 drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
 1 file changed, 174 insertions(+), 72 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8bd75a1..de73a71 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -67,9 +67,19 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
+#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
+#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
+
+
+#define NET_TX_RING_SIZE(_nr_pages)			\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define NET_RX_RING_SIZE(_nr_pages)			\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
+
+#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
+#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
+
+#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
 
 struct netfront_stats {
 	u64			rx_packets;
@@ -80,6 +90,11 @@ struct netfront_stats {
 };
 
 struct netfront_info {
+	/* Statistics */
+	struct netfront_stats __percpu *stats;
+
+	unsigned long rx_gso_checksum_fixup;
+
 	struct list_head list;
 	struct net_device *netdev;
 
@@ -90,7 +105,9 @@ struct netfront_info {
 
 	spinlock_t   tx_lock;
 	struct xen_netif_tx_front_ring tx;
-	int tx_ring_ref;
+	int tx_ring_ref[XENNET_MAX_RING_PAGES];
+	unsigned int tx_ring_page_order;
+	unsigned int tx_ring_pages;
 
 	/*
 	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
@@ -104,36 +121,33 @@ struct netfront_info {
 	union skb_entry {
 		struct sk_buff *skb;
 		unsigned long link;
-	} tx_skbs[NET_TX_RING_SIZE];
+	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
 	grant_ref_t gref_tx_head;
-	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
 	unsigned tx_skb_freelist;
 
 	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
 	struct xen_netif_rx_front_ring rx;
-	int rx_ring_ref;
+	int rx_ring_ref[XENNET_MAX_RING_PAGES];
+	unsigned int rx_ring_page_order;
+	unsigned int rx_ring_pages;
 
 	/* Receive-ring batched refills. */
 #define RX_MIN_TARGET 8
 #define RX_DFL_MIN_TARGET 64
-#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE(1), 256)
 	unsigned rx_min_target, rx_max_target, rx_target;
 	struct sk_buff_head rx_batch;
 
 	struct timer_list rx_refill_timer;
 
-	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
 	grant_ref_t gref_rx_head;
-	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
-
-	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
-	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
-	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
-
-	/* Statistics */
-	struct netfront_stats __percpu *stats;
+	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
 
-	unsigned long rx_gso_checksum_fixup;
+	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
 };
 
 struct netfront_rx_info {
@@ -171,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
 	return id;
 }
 
-static int xennet_rxidx(RING_IDX idx)
+static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
 {
-	return idx & (NET_RX_RING_SIZE - 1);
+	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
 }
 
 static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 					 RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	struct sk_buff *skb = np->rx_skbs[i];
 	np->rx_skbs[i] = NULL;
 	return skb;
@@ -188,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
 					    RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	grant_ref_t ref = np->grant_rx_ref[i];
 	np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	return ref;
@@ -301,7 +315,7 @@ no_skb:
 
 		skb->dev = dev;
 
-		id = xennet_rxidx(req_prod + i);
+		id = xennet_rxidx(req_prod + i, np);
 
 		BUG_ON(np->rx_skbs[id]);
 		np->rx_skbs[id] = skb;
@@ -653,7 +667,7 @@ static int xennet_close(struct net_device *dev)
 static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
 				grant_ref_t ref)
 {
-	int new = xennet_rxidx(np->rx.req_prod_pvt);
+	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
 
 	BUG_ON(np->rx_skbs[new]);
 	np->rx_skbs[new] = skb;
@@ -1109,7 +1123,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
 	struct sk_buff *skb;
 	int i;
 
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
 		/* Skip over entries which are actually freelist references */
 		if (skb_entry_is_link(&np->tx_skbs[i]))
 			continue;
@@ -1143,7 +1157,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
 
 	spin_lock_bh(&np->rx_lock);
 
-	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
 		ref = np->grant_rx_ref[id];
 		if (ref == GRANT_INVALID_REF) {
 			unused++;
@@ -1324,13 +1338,13 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	np->tx_skb_freelist = 0;
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
 		skb_entry_set_link(&np->tx_skbs[i], i+1);
 		np->grant_tx_ref[i] = GRANT_INVALID_REF;
 	}
 
 	/* Clear out rx_skbs */
-	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
 		np->rx_skbs[i] = NULL;
 		np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	}
@@ -1428,13 +1442,6 @@ static int netfront_probe(struct xenbus_device *dev,
 	return err;
 }
 
-static void xennet_end_access(int ref, void *page)
-{
-	/* This frees the page as a side-effect */
-	if (ref != GRANT_INVALID_REF)
-		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
-}
-
 static void xennet_disconnect_backend(struct netfront_info *info)
 {
 	/* Stop old i/f to prevent errors whilst we rebuild the state. */
@@ -1448,12 +1455,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 		unbind_from_irqhandler(info->netdev->irq, info->netdev);
 	info->evtchn = info->netdev->irq = 0;
 
-	/* End access and free the pages */
-	xennet_end_access(info->tx_ring_ref, info->tx.sring);
-	xennet_end_access(info->rx_ring_ref, info->rx.sring);
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
 	info->tx.sring = NULL;
 	info->rx.sring = NULL;
 }
@@ -1501,11 +1508,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
-	int grefs[1];
 	struct net_device *netdev = info->netdev;
+	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	int i;
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
+	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
 	netdev->irq = 0;
@@ -1516,50 +1526,100 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-tx-ring-page-order", "%u",
+			   &max_tx_ring_page_order);
+	if (err < 0) {
+		info->tx_ring_page_order = 0;
+		dev_info(&dev->dev, "single tx ring\n");
+	} else {
+		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_info(&dev->dev,
+				 "backend ring page order %d too large, clamp to %d\n",
+				 max_tx_ring_page_order,
+				 XENNET_MAX_RING_PAGE_ORDER);
+			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
+		info->tx_ring_page_order = max_tx_ring_page_order;
+		dev_info(&dev->dev, "multi-page tx ring, order = %d\n",
+			 info->tx_ring_page_order);
+	}
+	info->tx_ring_pages = (1U << info->tx_ring_page_order);
+
+	txs = (struct xen_netif_tx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->tx_ring_page_order);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
 		goto fail;
 	}
 	SHARED_RING_INIT(txs);
-	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
+
+	err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
+				info->tx_ring_ref);
+	if (err < 0)
+		goto grant_tx_ring_fail;
 
-	err = xenbus_grant_ring(dev, txs, 1, grefs);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-rx-ring-page-order", "%u",
+			   &max_rx_ring_page_order);
 	if (err < 0) {
-		free_page((unsigned long)txs);
-		goto fail;
+		info->rx_ring_page_order = 0;
+		dev_info(&dev->dev, "single rx ring\n");
+	} else {
+		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_info(&dev->dev,
+				 "backend ring page order %d too large, clamp to %d\n",
+				 max_rx_ring_page_order,
+				 XENNET_MAX_RING_PAGE_ORDER);
+			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
+		info->rx_ring_page_order = max_rx_ring_page_order;
+		dev_info(&dev->dev, "multi-page rx ring, order = %d\n",
+			 info->rx_ring_page_order);
 	}
+	info->rx_ring_pages = (1U << info->rx_ring_page_order);
 
-	info->tx_ring_ref = grefs[0];
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	rxs = (struct xen_netif_rx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->rx_ring_page_order);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
-		goto fail;
+		goto alloc_rx_ring_fail;
 	}
 	SHARED_RING_INIT(rxs);
-	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
-	err = xenbus_grant_ring(dev, rxs, 1, grefs);
-	if (err < 0) {
-		free_page((unsigned long)rxs);
-		goto fail;
-	}
-	info->rx_ring_ref = grefs[0];
+	err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
+				info->rx_ring_ref);
+	if (err < 0)
+		goto grant_rx_ring_fail;
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
-		goto fail;
+		goto alloc_evtchn_fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
 					0, netdev->name, netdev);
 	if (err < 0)
-		goto fail;
+		goto bind_fail;
 	netdev->irq = err;
 	return 0;
 
- fail:
+bind_fail:
+	xenbus_free_evtchn(dev, info->evtchn);
+alloc_evtchn_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+grant_rx_ring_fail:
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
+alloc_rx_ring_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+grant_tx_ring_fail:
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+fail:
 	return err;
 }
 
@@ -1570,6 +1630,7 @@ static int talk_to_netback(struct xenbus_device *dev,
 	const char *message;
 	struct xenbus_transaction xbt;
 	int err;
+	int i;
 
 	/* Create shared ring, alloc event channel. */
 	err = setup_netfront(dev, info);
@@ -1583,18 +1644,58 @@ again:
 		goto destroy_ring;
 	}
 
-	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
-			    info->tx_ring_ref);
-	if (err) {
-		message = "writing tx ring-ref";
-		goto abort_transaction;
+	if (info->tx_ring_page_order == 0) {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
+				    info->tx_ring_ref[0]);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
+				    info->tx_ring_page_order);
+		if (err) {
+			message = "writing tx-ring-order";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->tx_ring_pages; i++) {
+			char name[sizeof("tx-ring-ref")+3];
+			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->tx_ring_ref[i]);
+			if (err) {
+				message = "writing tx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
-	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
-			    info->rx_ring_ref);
-	if (err) {
-		message = "writing rx ring-ref";
-		goto abort_transaction;
+
+	if (info->rx_ring_page_order == 0) {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
+				    info->rx_ring_ref[0]);
+		if (err) {
+			message = "writing rx ring-ref";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
+				    info->rx_ring_page_order);
+		if (err) {
+			message = "writing rx-ring-order";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->rx_ring_pages; i++) {
+			char name[sizeof("rx-ring-ref")+3];
+			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->rx_ring_ref[i]);
+			if (err) {
+				message = "writing rx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
+
 	err = xenbus_printf(xbt, dev->nodename,
 			    "event-channel", "%u", info->evtchn);
 	if (err) {
@@ -1681,7 +1782,8 @@ static int xennet_connect(struct net_device *dev)
 	xennet_release_tx_bufs(np);
 
 	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
-	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
+	     i++) {
 		skb_frag_t *frag;
 		const struct page *page;
 		if (!np->rx_skbs[i])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njg-0005Ad-Bi; Fri, 15 Feb 2013 16:02:04 +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 1U6Njd-000593-SP
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:02 +0000
Received: from [85.158.139.211:18401] by server-14.bemta-5.messagelabs.com id
	D3/A4-06967-9FB5E115; Fri, 15 Feb 2013 16:02:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1360944117!22681763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8334 invoked from network); 15 Feb 2013 16:01:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697863"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-JY;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:07 +0000
Message-ID: <1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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>
---
 drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
 1 file changed, 174 insertions(+), 72 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8bd75a1..de73a71 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -67,9 +67,19 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
+#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
+#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
+
+
+#define NET_TX_RING_SIZE(_nr_pages)			\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define NET_RX_RING_SIZE(_nr_pages)			\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
+
+#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
+#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
+
+#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
 
 struct netfront_stats {
 	u64			rx_packets;
@@ -80,6 +90,11 @@ struct netfront_stats {
 };
 
 struct netfront_info {
+	/* Statistics */
+	struct netfront_stats __percpu *stats;
+
+	unsigned long rx_gso_checksum_fixup;
+
 	struct list_head list;
 	struct net_device *netdev;
 
@@ -90,7 +105,9 @@ struct netfront_info {
 
 	spinlock_t   tx_lock;
 	struct xen_netif_tx_front_ring tx;
-	int tx_ring_ref;
+	int tx_ring_ref[XENNET_MAX_RING_PAGES];
+	unsigned int tx_ring_page_order;
+	unsigned int tx_ring_pages;
 
 	/*
 	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
@@ -104,36 +121,33 @@ struct netfront_info {
 	union skb_entry {
 		struct sk_buff *skb;
 		unsigned long link;
-	} tx_skbs[NET_TX_RING_SIZE];
+	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
 	grant_ref_t gref_tx_head;
-	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
 	unsigned tx_skb_freelist;
 
 	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
 	struct xen_netif_rx_front_ring rx;
-	int rx_ring_ref;
+	int rx_ring_ref[XENNET_MAX_RING_PAGES];
+	unsigned int rx_ring_page_order;
+	unsigned int rx_ring_pages;
 
 	/* Receive-ring batched refills. */
 #define RX_MIN_TARGET 8
 #define RX_DFL_MIN_TARGET 64
-#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE(1), 256)
 	unsigned rx_min_target, rx_max_target, rx_target;
 	struct sk_buff_head rx_batch;
 
 	struct timer_list rx_refill_timer;
 
-	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
 	grant_ref_t gref_rx_head;
-	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
-
-	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
-	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
-	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
-
-	/* Statistics */
-	struct netfront_stats __percpu *stats;
+	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
 
-	unsigned long rx_gso_checksum_fixup;
+	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
 };
 
 struct netfront_rx_info {
@@ -171,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
 	return id;
 }
 
-static int xennet_rxidx(RING_IDX idx)
+static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
 {
-	return idx & (NET_RX_RING_SIZE - 1);
+	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
 }
 
 static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 					 RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	struct sk_buff *skb = np->rx_skbs[i];
 	np->rx_skbs[i] = NULL;
 	return skb;
@@ -188,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
 					    RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	grant_ref_t ref = np->grant_rx_ref[i];
 	np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	return ref;
@@ -301,7 +315,7 @@ no_skb:
 
 		skb->dev = dev;
 
-		id = xennet_rxidx(req_prod + i);
+		id = xennet_rxidx(req_prod + i, np);
 
 		BUG_ON(np->rx_skbs[id]);
 		np->rx_skbs[id] = skb;
@@ -653,7 +667,7 @@ static int xennet_close(struct net_device *dev)
 static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
 				grant_ref_t ref)
 {
-	int new = xennet_rxidx(np->rx.req_prod_pvt);
+	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
 
 	BUG_ON(np->rx_skbs[new]);
 	np->rx_skbs[new] = skb;
@@ -1109,7 +1123,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
 	struct sk_buff *skb;
 	int i;
 
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
 		/* Skip over entries which are actually freelist references */
 		if (skb_entry_is_link(&np->tx_skbs[i]))
 			continue;
@@ -1143,7 +1157,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
 
 	spin_lock_bh(&np->rx_lock);
 
-	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
 		ref = np->grant_rx_ref[id];
 		if (ref == GRANT_INVALID_REF) {
 			unused++;
@@ -1324,13 +1338,13 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	np->tx_skb_freelist = 0;
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
 		skb_entry_set_link(&np->tx_skbs[i], i+1);
 		np->grant_tx_ref[i] = GRANT_INVALID_REF;
 	}
 
 	/* Clear out rx_skbs */
-	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
 		np->rx_skbs[i] = NULL;
 		np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	}
@@ -1428,13 +1442,6 @@ static int netfront_probe(struct xenbus_device *dev,
 	return err;
 }
 
-static void xennet_end_access(int ref, void *page)
-{
-	/* This frees the page as a side-effect */
-	if (ref != GRANT_INVALID_REF)
-		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
-}
-
 static void xennet_disconnect_backend(struct netfront_info *info)
 {
 	/* Stop old i/f to prevent errors whilst we rebuild the state. */
@@ -1448,12 +1455,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 		unbind_from_irqhandler(info->netdev->irq, info->netdev);
 	info->evtchn = info->netdev->irq = 0;
 
-	/* End access and free the pages */
-	xennet_end_access(info->tx_ring_ref, info->tx.sring);
-	xennet_end_access(info->rx_ring_ref, info->rx.sring);
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
 	info->tx.sring = NULL;
 	info->rx.sring = NULL;
 }
@@ -1501,11 +1508,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_tx_sring *txs;
 	struct xen_netif_rx_sring *rxs;
 	int err;
-	int grefs[1];
 	struct net_device *netdev = info->netdev;
+	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	int i;
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
+	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
 	netdev->irq = 0;
@@ -1516,50 +1526,100 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-tx-ring-page-order", "%u",
+			   &max_tx_ring_page_order);
+	if (err < 0) {
+		info->tx_ring_page_order = 0;
+		dev_info(&dev->dev, "single tx ring\n");
+	} else {
+		if (max_tx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_info(&dev->dev,
+				 "backend ring page order %d too large, clamp to %d\n",
+				 max_tx_ring_page_order,
+				 XENNET_MAX_RING_PAGE_ORDER);
+			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
+		info->tx_ring_page_order = max_tx_ring_page_order;
+		dev_info(&dev->dev, "multi-page tx ring, order = %d\n",
+			 info->tx_ring_page_order);
+	}
+	info->tx_ring_pages = (1U << info->tx_ring_page_order);
+
+	txs = (struct xen_netif_tx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->tx_ring_page_order);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
 		goto fail;
 	}
 	SHARED_RING_INIT(txs);
-	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
+
+	err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
+				info->tx_ring_ref);
+	if (err < 0)
+		goto grant_tx_ring_fail;
 
-	err = xenbus_grant_ring(dev, txs, 1, grefs);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-rx-ring-page-order", "%u",
+			   &max_rx_ring_page_order);
 	if (err < 0) {
-		free_page((unsigned long)txs);
-		goto fail;
+		info->rx_ring_page_order = 0;
+		dev_info(&dev->dev, "single rx ring\n");
+	} else {
+		if (max_rx_ring_page_order > XENNET_MAX_RING_PAGE_ORDER) {
+			dev_info(&dev->dev,
+				 "backend ring page order %d too large, clamp to %d\n",
+				 max_rx_ring_page_order,
+				 XENNET_MAX_RING_PAGE_ORDER);
+			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
+		}
+		info->rx_ring_page_order = max_rx_ring_page_order;
+		dev_info(&dev->dev, "multi-page rx ring, order = %d\n",
+			 info->rx_ring_page_order);
 	}
+	info->rx_ring_pages = (1U << info->rx_ring_page_order);
 
-	info->tx_ring_ref = grefs[0];
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	rxs = (struct xen_netif_rx_sring *)
+		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
+				 info->rx_ring_page_order);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
-		goto fail;
+		goto alloc_rx_ring_fail;
 	}
 	SHARED_RING_INIT(rxs);
-	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
 
-	err = xenbus_grant_ring(dev, rxs, 1, grefs);
-	if (err < 0) {
-		free_page((unsigned long)rxs);
-		goto fail;
-	}
-	info->rx_ring_ref = grefs[0];
+	err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
+				info->rx_ring_ref);
+	if (err < 0)
+		goto grant_rx_ring_fail;
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
-		goto fail;
+		goto alloc_evtchn_fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
 					0, netdev->name, netdev);
 	if (err < 0)
-		goto fail;
+		goto bind_fail;
 	netdev->irq = err;
 	return 0;
 
- fail:
+bind_fail:
+	xenbus_free_evtchn(dev, info->evtchn);
+alloc_evtchn_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
+grant_rx_ring_fail:
+	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
+alloc_rx_ring_fail:
+	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
+grant_tx_ring_fail:
+	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
+fail:
 	return err;
 }
 
@@ -1570,6 +1630,7 @@ static int talk_to_netback(struct xenbus_device *dev,
 	const char *message;
 	struct xenbus_transaction xbt;
 	int err;
+	int i;
 
 	/* Create shared ring, alloc event channel. */
 	err = setup_netfront(dev, info);
@@ -1583,18 +1644,58 @@ again:
 		goto destroy_ring;
 	}
 
-	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
-			    info->tx_ring_ref);
-	if (err) {
-		message = "writing tx ring-ref";
-		goto abort_transaction;
+	if (info->tx_ring_page_order == 0) {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
+				    info->tx_ring_ref[0]);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
+				    info->tx_ring_page_order);
+		if (err) {
+			message = "writing tx-ring-order";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->tx_ring_pages; i++) {
+			char name[sizeof("tx-ring-ref")+3];
+			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->tx_ring_ref[i]);
+			if (err) {
+				message = "writing tx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
-	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
-			    info->rx_ring_ref);
-	if (err) {
-		message = "writing rx ring-ref";
-		goto abort_transaction;
+
+	if (info->rx_ring_page_order == 0) {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
+				    info->rx_ring_ref[0]);
+		if (err) {
+			message = "writing rx ring-ref";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
+				    info->rx_ring_page_order);
+		if (err) {
+			message = "writing rx-ring-order";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->rx_ring_pages; i++) {
+			char name[sizeof("rx-ring-ref")+3];
+			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->rx_ring_ref[i]);
+			if (err) {
+				message = "writing rx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
+
 	err = xenbus_printf(xbt, dev->nodename,
 			    "event-channel", "%u", info->evtchn);
 	if (err) {
@@ -1681,7 +1782,8 @@ static int xennet_connect(struct net_device *dev)
 	xennet_release_tx_bufs(np);
 
 	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
-	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
+	     i++) {
 		skb_frag_t *frag;
 		const struct page *page;
 		if (!np->rx_skbs[i])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njj-0005D3-Ux; Fri, 15 Feb 2013 16:02:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U6Nji-0005Bc-5w
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:06 +0000
Received: from [85.158.137.99:6207] by server-16.bemta-3.messagelabs.com id
	BA/ED-02727-DFB5E115; Fri, 15 Feb 2013 16:02:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360944116!21617897!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3578 invoked from network); 15 Feb 2013 16:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697861"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Ib;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:06 +0000
Message-ID: <1360944010-15336-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] netback: multi-page ring 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>
---
 drivers/net/xen-netback/common.h    |   30 ++++++--
 drivers/net/xen-netback/interface.c |   46 +++++++++--
 drivers/net/xen-netback/netback.c   |   73 ++++++++----------
 drivers/net/xen-netback/xenbus.c    |  143 +++++++++++++++++++++++++++++++++--
 4 files changed, 229 insertions(+), 63 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 35d8772..f541ba9 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#define NETBK_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
+#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
+
+#define NETBK_MAX_TX_RING_SIZE XEN_NETIF_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
+#define NETBK_MAX_RX_RING_SIZE XEN_NETIF_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
+
 struct xen_netbk;
 
 struct xenvif {
@@ -66,6 +72,8 @@ struct xenvif {
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
+	unsigned int nr_tx_handles;
+	unsigned int nr_rx_handles;
 
 	/* Frontend feature information. */
 	u8 can_sg:1;
@@ -105,15 +113,19 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define XEN_NETIF_TX_RING_SIZE(_nr_pages)		\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define XEN_NETIF_RX_RING_SIZE(_nr_pages)		\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
 
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn);
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long *tx_ring_ref, unsigned int tx_ring_order,
+		   unsigned long *rx_ring_ref, unsigned int rx_ring_order,
+		   unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 void xenvif_get(struct xenvif *vif);
@@ -129,10 +141,12 @@ int xen_netbk_rx_ring_full(struct xenvif *vif);
 int xen_netbk_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
+void xen_netbk_unmap_frontend_rings(struct xenvif *vif, void *addr);
 int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+				 void **addr,
+				 int domid,
+				 int *ring_ref,
+				 unsigned int ring_ref_count);
 
 /* (De)Register a xenvif with the netback backend. */
 void xen_netbk_add_xenvif(struct xenvif *vif);
@@ -158,4 +172,6 @@ void xenvif_carrier_off(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+extern unsigned int MODPARM_netback_max_tx_ring_page_order;
+extern unsigned int MODPARM_netback_max_rx_ring_page_order;
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index db638e1..fa4d46d 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -305,10 +305,16 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn)
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long *tx_ring_ref, unsigned int tx_ring_ref_count,
+		   unsigned long *rx_ring_ref, unsigned int rx_ring_ref_count,
+		   unsigned int evtchn)
 {
 	int err = -ENOMEM;
+	void *addr;
+	struct xen_netif_tx_sring *txs;
+	struct xen_netif_rx_sring *rxs;
+	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -316,15 +322,36 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	for (i = 0; i < tx_ring_ref_count; i++)
+		tmp[i] = tx_ring_ref[i];
+
+	err = xen_netbk_map_frontend_rings(vif, &addr, vif->domid,
+					   tmp, tx_ring_ref_count);
 	if (err < 0)
 		goto err;
 
+	txs = addr;
+	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE * tx_ring_ref_count);
+	vif->nr_tx_handles = tx_ring_ref_count;
+
+	for (i = 0; i < rx_ring_ref_count; i++)
+		tmp[i] = rx_ring_ref[i];
+
+	err = xen_netbk_map_frontend_rings(vif, &addr, vif->domid,
+					   tmp, rx_ring_ref_count);
+
+	if (err < 0)
+		goto err_tx_unmap;
+
+	rxs = addr;
+	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
+	vif->nr_rx_handles = rx_ring_ref_count;
+
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
 		vif->dev->name, vif);
 	if (err < 0)
-		goto err_unmap;
+		goto err_rx_unmap;
 	vif->irq = err;
 	disable_irq(vif->irq);
 
@@ -340,8 +367,12 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	rtnl_unlock();
 
 	return 0;
-err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+err_rx_unmap:
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
+	vif->nr_rx_handles = 0;
+err_tx_unmap:
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->tx.sring);
+	vif->nr_tx_handles = 0;
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -382,7 +413,8 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->tx.sring);
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 98ccea9..644c760 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -47,6 +47,19 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_rx_ring_page_order,
+		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_ring_page_order,
+		 "Maximum supported receiver ring page order");
+
+unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_tx_ring_page_order,
+		   MODPARM_netback_max_tx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_tx_ring_page_order,
+		 "Maximum supported transmitter ring page order");
+
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 	struct xenvif *vif;
@@ -59,7 +72,7 @@ struct netbk_rx_meta {
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
+#define MAX_PENDING_REQS NETBK_MAX_TX_RING_SIZE
 
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
@@ -111,8 +124,8 @@ struct xen_netbk {
 	 * head/fragment page uses 2 copy operations because it
 	 * straddles two buffers in the frontend.
 	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
+	struct gnttab_copy grant_copy_op[2*NETBK_MAX_RX_RING_SIZE];
+	struct netbk_rx_meta meta[2*NETBK_MAX_RX_RING_SIZE];
 };
 
 static struct xen_netbk *xen_netbk;
@@ -262,7 +275,8 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	RING_IDX needed = max_required_rx_slots(vif);
 
 	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
+	       ((vif->rx.rsp_prod_pvt +
+		 XEN_NETIF_RX_RING_SIZE(vif->nr_rx_handles) - peek) < needed);
 }
 
 int xen_netbk_must_stop_queue(struct xenvif *vif)
@@ -657,7 +671,8 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 		__skb_queue_tail(&rxq, skb);
 
 		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
+		if (count + MAX_SKB_FRAGS >=
+		    XEN_NETIF_RX_RING_SIZE(vif->nr_rx_handles))
 			break;
 	}
 
@@ -1292,12 +1307,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			continue;
 
 		if (vif->tx.sring->req_prod - vif->tx.req_cons >
-		    XEN_NETIF_TX_RING_SIZE) {
+		    XEN_NETIF_TX_RING_SIZE(vif->nr_tx_handles)) {
 			netdev_err(vif->dev,
 				   "Impossible number of requests. "
 				   "req_prod %d, req_cons %d, size %ld\n",
 				   vif->tx.sring->req_prod, vif->tx.req_cons,
-				   XEN_NETIF_TX_RING_SIZE);
+				   XEN_NETIF_TX_RING_SIZE(vif->nr_tx_handles));
 			netbk_fatal_tx_err(vif);
 			continue;
 		}
@@ -1644,48 +1659,22 @@ static int xen_netbk_kthread(void *data)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xen_netbk_unmap_frontend_rings(struct xenvif *vif, void *addr)
 {
-	if (vif->tx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->tx.sring);
-	if (vif->rx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->rx.sring);
+	if (addr)
+		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), addr);
 }
 
 int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+				 void **vaddr,
+				 int domid,
+				 int *ring_ref,
+				 unsigned int ring_ref_count)
 {
-	void *addr;
-	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
-
-	int err = -ENOMEM;
-
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &tx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
+	int err = 0;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &rx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
-
-	vif->rx_req_cons_peek = 0;
-
-	return 0;
-
-err:
-	xen_netbk_unmap_frontend_rings(vif);
+				     ring_ref, ring_ref_count, vaddr);
 	return err;
 }
 
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..1791807 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -114,6 +114,33 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		/* Multi-page ring support */
+		if (MODPARM_netback_max_tx_ring_page_order >
+		    NETBK_MAX_RING_PAGE_ORDER)
+			MODPARM_netback_max_tx_ring_page_order =
+				NETBK_MAX_RING_PAGE_ORDER;
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-tx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_tx_ring_page_order);
+		if (err) {
+			message = "writing max-tx-ring-page-order";
+			goto abort_transaction;
+		}
+
+		if (MODPARM_netback_max_rx_ring_page_order >
+		    NETBK_MAX_RING_PAGE_ORDER)
+			MODPARM_netback_max_rx_ring_page_order =
+				NETBK_MAX_RING_PAGE_ORDER;
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-rx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_rx_ring_page_order);
+		if (err) {
+			message = "writing max-rx-ring-page-order";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -392,22 +419,107 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned long tx_ring_ref, rx_ring_ref;
 	unsigned int evtchn, rx_copy;
 	int err;
 	int val;
+	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned int  tx_ring_order;
+	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "tx-ring-ref", "%lu", &tx_ring_ref,
-			    "rx-ring-ref", "%lu", &rx_ring_ref,
 			    "event-channel", "%u", &evtchn, NULL);
 	if (err) {
 		xenbus_dev_fatal(dev, err,
-				 "reading %s/ring-ref and event-channel",
+				 "reading %s/event-channel",
 				 dev->otherend);
 		return err;
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
+			   &tx_ring_order);
+	if (err < 0) {
+		tx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
+				   &tx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
+			err = -EINVAL;
+			xenbus_dev_fatal(dev, err,
+					 "%s/tx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << tx_ring_order); i++) {
+			char ring_ref_name[sizeof("tx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "tx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &tx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-order", "%u",
+			   &rx_ring_order);
+	if (err < 0) {
+		rx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-ref", "%lu",
+				   &rx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/rx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (rx_ring_order > MODPARM_netback_max_rx_ring_page_order) {
+			err = -EINVAL;
+			xenbus_dev_fatal(dev, err,
+					 "%s/rx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << rx_ring_order); i++) {
+			char ring_ref_name[sizeof("rx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "rx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &rx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -454,11 +566,28 @@ static int connect_rings(struct backend_info *be)
 	vif->csum = !val;
 
 	/* Map the shared frame, irq etc. */
-	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
+	err = xenvif_connect(vif, tx_ring_ref, (1U << tx_ring_order),
+			     rx_ring_ref, (1U << rx_ring_order),
+			     evtchn);
 	if (err) {
+		/* construct 1 2 3 / 4 5 6 */
+		int i;
+		char txs[3 * (1U << MODPARM_netback_max_tx_ring_page_order)];
+		char rxs[3 * (1U << MODPARM_netback_max_rx_ring_page_order)];
+
+		txs[0] = rxs[0] = 0;
+
+		for (i = 0; i < (1U << tx_ring_order); i++)
+			snprintf(txs+strlen(txs), sizeof(txs)-strlen(txs)-1,
+				 " %lu", tx_ring_ref[i]);
+
+		for (i = 0; i < (1U << rx_ring_order); i++)
+			snprintf(rxs+strlen(rxs), sizeof(rxs)-strlen(rxs)-1,
+				 " %lu", rx_ring_ref[i]);
+
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames %lu/%lu port %u",
-				 tx_ring_ref, rx_ring_ref, evtchn);
+				 "mapping shared-frames%s /%s port %u",
+				 txs, rxs, evtchn);
 		return err;
 	}
 	return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:02:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:02: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 1U6Njj-0005D3-Ux; Fri, 15 Feb 2013 16:02:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U6Nji-0005Bc-5w
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:02:06 +0000
Received: from [85.158.137.99:6207] by server-16.bemta-3.messagelabs.com id
	BA/ED-02727-DFB5E115; Fri, 15 Feb 2013 16:02:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1360944116!21617897!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3578 invoked from network); 15 Feb 2013 16:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7697861"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:00:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:00:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6NiW-0005WO-Ib;
	Fri, 15 Feb 2013 16:00:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>, <annie.li@oracle.com>
Date: Fri, 15 Feb 2013 16:00:06 +0000
Message-ID: <1360944010-15336-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] netback: multi-page ring 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>
---
 drivers/net/xen-netback/common.h    |   30 ++++++--
 drivers/net/xen-netback/interface.c |   46 +++++++++--
 drivers/net/xen-netback/netback.c   |   73 ++++++++----------
 drivers/net/xen-netback/xenbus.c    |  143 +++++++++++++++++++++++++++++++++--
 4 files changed, 229 insertions(+), 63 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 35d8772..f541ba9 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#define NETBK_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
+#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
+
+#define NETBK_MAX_TX_RING_SIZE XEN_NETIF_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
+#define NETBK_MAX_RX_RING_SIZE XEN_NETIF_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
+
 struct xen_netbk;
 
 struct xenvif {
@@ -66,6 +72,8 @@ struct xenvif {
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
+	unsigned int nr_tx_handles;
+	unsigned int nr_rx_handles;
 
 	/* Frontend feature information. */
 	u8 can_sg:1;
@@ -105,15 +113,19 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define XEN_NETIF_TX_RING_SIZE(_nr_pages)		\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define XEN_NETIF_RX_RING_SIZE(_nr_pages)		\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
 
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn);
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long *tx_ring_ref, unsigned int tx_ring_order,
+		   unsigned long *rx_ring_ref, unsigned int rx_ring_order,
+		   unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 void xenvif_get(struct xenvif *vif);
@@ -129,10 +141,12 @@ int xen_netbk_rx_ring_full(struct xenvif *vif);
 int xen_netbk_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
+void xen_netbk_unmap_frontend_rings(struct xenvif *vif, void *addr);
 int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+				 void **addr,
+				 int domid,
+				 int *ring_ref,
+				 unsigned int ring_ref_count);
 
 /* (De)Register a xenvif with the netback backend. */
 void xen_netbk_add_xenvif(struct xenvif *vif);
@@ -158,4 +172,6 @@ void xenvif_carrier_off(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+extern unsigned int MODPARM_netback_max_tx_ring_page_order;
+extern unsigned int MODPARM_netback_max_rx_ring_page_order;
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index db638e1..fa4d46d 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -305,10 +305,16 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn)
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long *tx_ring_ref, unsigned int tx_ring_ref_count,
+		   unsigned long *rx_ring_ref, unsigned int rx_ring_ref_count,
+		   unsigned int evtchn)
 {
 	int err = -ENOMEM;
+	void *addr;
+	struct xen_netif_tx_sring *txs;
+	struct xen_netif_rx_sring *rxs;
+	int tmp[NETBK_MAX_RING_PAGES], i;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -316,15 +322,36 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	for (i = 0; i < tx_ring_ref_count; i++)
+		tmp[i] = tx_ring_ref[i];
+
+	err = xen_netbk_map_frontend_rings(vif, &addr, vif->domid,
+					   tmp, tx_ring_ref_count);
 	if (err < 0)
 		goto err;
 
+	txs = addr;
+	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE * tx_ring_ref_count);
+	vif->nr_tx_handles = tx_ring_ref_count;
+
+	for (i = 0; i < rx_ring_ref_count; i++)
+		tmp[i] = rx_ring_ref[i];
+
+	err = xen_netbk_map_frontend_rings(vif, &addr, vif->domid,
+					   tmp, rx_ring_ref_count);
+
+	if (err < 0)
+		goto err_tx_unmap;
+
+	rxs = addr;
+	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
+	vif->nr_rx_handles = rx_ring_ref_count;
+
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
 		vif->dev->name, vif);
 	if (err < 0)
-		goto err_unmap;
+		goto err_rx_unmap;
 	vif->irq = err;
 	disable_irq(vif->irq);
 
@@ -340,8 +367,12 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	rtnl_unlock();
 
 	return 0;
-err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+err_rx_unmap:
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
+	vif->nr_rx_handles = 0;
+err_tx_unmap:
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->tx.sring);
+	vif->nr_tx_handles = 0;
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -382,7 +413,8 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->tx.sring);
+	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 98ccea9..644c760 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -47,6 +47,19 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_rx_ring_page_order,
+		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_ring_page_order,
+		 "Maximum supported receiver ring page order");
+
+unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_tx_ring_page_order,
+		   MODPARM_netback_max_tx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_tx_ring_page_order,
+		 "Maximum supported transmitter ring page order");
+
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 	struct xenvif *vif;
@@ -59,7 +72,7 @@ struct netbk_rx_meta {
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
+#define MAX_PENDING_REQS NETBK_MAX_TX_RING_SIZE
 
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
@@ -111,8 +124,8 @@ struct xen_netbk {
 	 * head/fragment page uses 2 copy operations because it
 	 * straddles two buffers in the frontend.
 	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
+	struct gnttab_copy grant_copy_op[2*NETBK_MAX_RX_RING_SIZE];
+	struct netbk_rx_meta meta[2*NETBK_MAX_RX_RING_SIZE];
 };
 
 static struct xen_netbk *xen_netbk;
@@ -262,7 +275,8 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	RING_IDX needed = max_required_rx_slots(vif);
 
 	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
+	       ((vif->rx.rsp_prod_pvt +
+		 XEN_NETIF_RX_RING_SIZE(vif->nr_rx_handles) - peek) < needed);
 }
 
 int xen_netbk_must_stop_queue(struct xenvif *vif)
@@ -657,7 +671,8 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 		__skb_queue_tail(&rxq, skb);
 
 		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
+		if (count + MAX_SKB_FRAGS >=
+		    XEN_NETIF_RX_RING_SIZE(vif->nr_rx_handles))
 			break;
 	}
 
@@ -1292,12 +1307,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			continue;
 
 		if (vif->tx.sring->req_prod - vif->tx.req_cons >
-		    XEN_NETIF_TX_RING_SIZE) {
+		    XEN_NETIF_TX_RING_SIZE(vif->nr_tx_handles)) {
 			netdev_err(vif->dev,
 				   "Impossible number of requests. "
 				   "req_prod %d, req_cons %d, size %ld\n",
 				   vif->tx.sring->req_prod, vif->tx.req_cons,
-				   XEN_NETIF_TX_RING_SIZE);
+				   XEN_NETIF_TX_RING_SIZE(vif->nr_tx_handles));
 			netbk_fatal_tx_err(vif);
 			continue;
 		}
@@ -1644,48 +1659,22 @@ static int xen_netbk_kthread(void *data)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xen_netbk_unmap_frontend_rings(struct xenvif *vif, void *addr)
 {
-	if (vif->tx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->tx.sring);
-	if (vif->rx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->rx.sring);
+	if (addr)
+		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif), addr);
 }
 
 int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+				 void **vaddr,
+				 int domid,
+				 int *ring_ref,
+				 unsigned int ring_ref_count)
 {
-	void *addr;
-	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
-
-	int err = -ENOMEM;
-
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &tx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
+	int err = 0;
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     &rx_ring_ref, 1, &addr);
-	if (err)
-		goto err;
-
-	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
-
-	vif->rx_req_cons_peek = 0;
-
-	return 0;
-
-err:
-	xen_netbk_unmap_frontend_rings(vif);
+				     ring_ref, ring_ref_count, vaddr);
 	return err;
 }
 
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..1791807 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -114,6 +114,33 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		/* Multi-page ring support */
+		if (MODPARM_netback_max_tx_ring_page_order >
+		    NETBK_MAX_RING_PAGE_ORDER)
+			MODPARM_netback_max_tx_ring_page_order =
+				NETBK_MAX_RING_PAGE_ORDER;
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-tx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_tx_ring_page_order);
+		if (err) {
+			message = "writing max-tx-ring-page-order";
+			goto abort_transaction;
+		}
+
+		if (MODPARM_netback_max_rx_ring_page_order >
+		    NETBK_MAX_RING_PAGE_ORDER)
+			MODPARM_netback_max_rx_ring_page_order =
+				NETBK_MAX_RING_PAGE_ORDER;
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-rx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_rx_ring_page_order);
+		if (err) {
+			message = "writing max-rx-ring-page-order";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -392,22 +419,107 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned long tx_ring_ref, rx_ring_ref;
 	unsigned int evtchn, rx_copy;
 	int err;
 	int val;
+	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned int  tx_ring_order;
+	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "tx-ring-ref", "%lu", &tx_ring_ref,
-			    "rx-ring-ref", "%lu", &rx_ring_ref,
 			    "event-channel", "%u", &evtchn, NULL);
 	if (err) {
 		xenbus_dev_fatal(dev, err,
-				 "reading %s/ring-ref and event-channel",
+				 "reading %s/event-channel",
 				 dev->otherend);
 		return err;
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
+			   &tx_ring_order);
+	if (err < 0) {
+		tx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
+				   &tx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
+			err = -EINVAL;
+			xenbus_dev_fatal(dev, err,
+					 "%s/tx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << tx_ring_order); i++) {
+			char ring_ref_name[sizeof("tx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "tx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &tx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-order", "%u",
+			   &rx_ring_order);
+	if (err < 0) {
+		rx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-ref", "%lu",
+				   &rx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/rx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (rx_ring_order > MODPARM_netback_max_rx_ring_page_order) {
+			err = -EINVAL;
+			xenbus_dev_fatal(dev, err,
+					 "%s/rx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << rx_ring_order); i++) {
+			char ring_ref_name[sizeof("rx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "rx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &rx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -454,11 +566,28 @@ static int connect_rings(struct backend_info *be)
 	vif->csum = !val;
 
 	/* Map the shared frame, irq etc. */
-	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
+	err = xenvif_connect(vif, tx_ring_ref, (1U << tx_ring_order),
+			     rx_ring_ref, (1U << rx_ring_order),
+			     evtchn);
 	if (err) {
+		/* construct 1 2 3 / 4 5 6 */
+		int i;
+		char txs[3 * (1U << MODPARM_netback_max_tx_ring_page_order)];
+		char rxs[3 * (1U << MODPARM_netback_max_rx_ring_page_order)];
+
+		txs[0] = rxs[0] = 0;
+
+		for (i = 0; i < (1U << tx_ring_order); i++)
+			snprintf(txs+strlen(txs), sizeof(txs)-strlen(txs)-1,
+				 " %lu", tx_ring_ref[i]);
+
+		for (i = 0; i < (1U << rx_ring_order); i++)
+			snprintf(rxs+strlen(rxs), sizeof(rxs)-strlen(rxs)-1,
+				 " %lu", rx_ring_ref[i]);
+
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames %lu/%lu port %u",
-				 tx_ring_ref, rx_ring_ref, evtchn);
+				 "mapping shared-frames%s /%s port %u",
+				 txs, rxs, evtchn);
 		return err;
 	}
 	return 0;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:05:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6Nn3-0006L9-Rf; Fri, 15 Feb 2013 16:05:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U6Nn2-0006Ko-K9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:05:32 +0000
Received: from [85.158.138.51:64035] by server-5.bemta-3.messagelabs.com id
	14/FC-04457-BCC5E115; Fri, 15 Feb 2013 16:05:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360944330!27753308!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12109 invoked from network); 15 Feb 2013 16:05:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:05:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1522333"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 16:05:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 15 Feb 2013
	16:05:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 15 Feb 2013 16:05:29 +0000
Thread-Topic: [PATCH] doc: Improve xc_domain_restore inline documentation
Thread-Index: Ac4Llkan6IinIQnjRWep6gjSTKm1VQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45838C@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@LONPMAILBOX01.citrite.net>
	<20766.19816.146502.391776@mariner.uk.xensource.com>
In-Reply-To: <20766.19816.146502.391776@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
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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 Fri, 2013-02-15 at 14:59 +0000, Ian Jackson wrote:
> Frediano Ziglio writes ("[PATCH] doc: Improve xc_domain_restore inline documentation"):
> > Was not clear that xc_domain_restore did not resume the machine.
> > ---
> >  tools/libxc/xenguest.h |    2 ++
> >  1 file changed, 2 insertions(+)
> 
> I'm afraid we need your confirmation that the Developer's Certificate
> of Origin applies.  See http://wiki.xen.org/wiki/SubmittingXenPatches
> 
> Thanks,
> Ian.

Thanks,
  I posted again my patch with the signed off.

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:05:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6Nn3-0006L9-Rf; Fri, 15 Feb 2013 16:05:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U6Nn2-0006Ko-K9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:05:32 +0000
Received: from [85.158.138.51:64035] by server-5.bemta-3.messagelabs.com id
	14/FC-04457-BCC5E115; Fri, 15 Feb 2013 16:05:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1360944330!27753308!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12109 invoked from network); 15 Feb 2013 16:05:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:05:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1522333"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 16:05:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 15 Feb 2013
	16:05:30 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 15 Feb 2013 16:05:29 +0000
Thread-Topic: [PATCH] doc: Improve xc_domain_restore inline documentation
Thread-Index: Ac4Llkan6IinIQnjRWep6gjSTKm1VQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45838C@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458380@LONPMAILBOX01.citrite.net>
	<20766.19816.146502.391776@mariner.uk.xensource.com>
In-Reply-To: <20766.19816.146502.391776@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
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] doc: Improve xc_domain_restore inline
	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 Fri, 2013-02-15 at 14:59 +0000, Ian Jackson wrote:
> Frediano Ziglio writes ("[PATCH] doc: Improve xc_domain_restore inline documentation"):
> > Was not clear that xc_domain_restore did not resume the machine.
> > ---
> >  tools/libxc/xenguest.h |    2 ++
> >  1 file changed, 2 insertions(+)
> 
> I'm afraid we need your confirmation that the Developer's Certificate
> of Origin applies.  See http://wiki.xen.org/wiki/SubmittingXenPatches
> 
> Thanks,
> Ian.

Thanks,
  I posted again my patch with the signed off.

Frediano


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:07:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6Np0-0006gs-DW; Fri, 15 Feb 2013 16:07:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangzhi2022@hotmail.com>) id 1U6Noz-0006gi-Dq
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:07:33 +0000
Received: from [85.158.143.35:45176] by server-1.bemta-4.messagelabs.com id
	FC/43-08839-44D5E115; Fri, 15 Feb 2013 16:07:32 +0000
X-Env-Sender: zhangzhi2022@hotmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360944034!11392816!1
X-Originating-IP: [65.55.111.147]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7192 invoked from network); 15 Feb 2013 16:00:37 -0000
Received: from unknown (HELO blu0-omc4-s8.blu0.hotmail.com) (65.55.111.147)
	by server-11.tower-21.messagelabs.com with SMTP;
	15 Feb 2013 16:00:37 -0000
Received: from BLU170-DS34 ([65.55.111.136]) by blu0-omc4-s8.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 15 Feb 2013 07:59:24 -0800
X-EIP: [KQINVQW677kRYVe4jhNV905lDYd4CTIf]
X-Originating-Email: [zhangzhi2022@hotmail.com]
Message-ID: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>
From: zhang zhi <zhangzhi2022@hotmail.com>
To: "'Tim Deegan'" <tim@xen.org>
Date: Fri, 15 Feb 2013 23:59:23 +0800
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4LlNW3VBaqgHuxT6SEC/D+EVUBsw==
Content-Language: zh-cn
X-OriginalArrivalTime: 15 Feb 2013 15:59:24.0138 (UTC)
	FILETIME=[6CA924A0:01CE0B95]
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] ipi(inter-processor interrupt) about xen 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: multipart/mixed; boundary="===============0614268556441374483=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0614268556441374483==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002A_01CE0BD8.7ACFE710"
Content-Language: zh-cn

------=_NextPart_000_002A_01CE0BD8.7ACFE710
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Mr. Tim,

          I wanna ask you a question, hope you won't mind the inconvenience
that I gave to you. 

 

         In the context of multi-core mode, core 1 is in root-mode, meaning
that it's running VMM. And core 2 is in non-root mode, meaning that it's
running guest OS in kernel level. If core 1 wants core2 to execute a
pre-defined program located in kernel-mode, say a syscall or a virtual
external interrupt handler(the program is completed via syscall or another
kernel module). Considering that core1 is in vmm mode, and core2 is not
supposed to vm-exit, so I can't use the method of event-delivery. What kind
of thing should core 1 do ? 

         Can you give me some advice ? 

Thanks a lot !

 

Best Regards,

Zhang.

 


------=_NextPart_000_002A_01CE0BD8.7ACFE710
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-microsoft-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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator 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: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;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
/* Page Definitions */
@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=3DZH-CN link=3Dblue =
vlink=3Dpurple style=3D'text-justify-trim:punctuation'><div =
class=3DWordSection1><p class=3DMsoNormal><span lang=3DEN-US>Dear Mr. =
Tim,<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US> =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;I =
wanna ask you a question, hope you won&#8217;t mind the inconvenience =
that I gave to you. <o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the =
context of multi-core mode, core 1 is in root-mode, meaning that =
it&#8217;s running VMM. And core 2 is in non-root mode, meaning that =
it&#8217;s running guest OS in kernel level. If core 1 wants core2 to =
execute a pre-defined program located in kernel-mode, say a syscall or a =
virtual external interrupt handler(the program is completed via syscall =
or another kernel module). Considering that core1 is in vmm mode, and =
core2 is not supposed to vm-exit, so I can&#8217;t use the method of =
event-delivery. What kind of thing should core 1 do ? =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can you =
give me some advice ? <o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-indent:26.25pt'><span lang=3DEN-US>Thanks a lot =
!<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>Best Regards,<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>Zhang.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p></div></body></html>
------=_NextPart_000_002A_01CE0BD8.7ACFE710--


--===============0614268556441374483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0614268556441374483==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:07:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6Np0-0006gs-DW; Fri, 15 Feb 2013 16:07:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangzhi2022@hotmail.com>) id 1U6Noz-0006gi-Dq
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:07:33 +0000
Received: from [85.158.143.35:45176] by server-1.bemta-4.messagelabs.com id
	FC/43-08839-44D5E115; Fri, 15 Feb 2013 16:07:32 +0000
X-Env-Sender: zhangzhi2022@hotmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1360944034!11392816!1
X-Originating-IP: [65.55.111.147]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7192 invoked from network); 15 Feb 2013 16:00:37 -0000
Received: from unknown (HELO blu0-omc4-s8.blu0.hotmail.com) (65.55.111.147)
	by server-11.tower-21.messagelabs.com with SMTP;
	15 Feb 2013 16:00:37 -0000
Received: from BLU170-DS34 ([65.55.111.136]) by blu0-omc4-s8.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 15 Feb 2013 07:59:24 -0800
X-EIP: [KQINVQW677kRYVe4jhNV905lDYd4CTIf]
X-Originating-Email: [zhangzhi2022@hotmail.com]
Message-ID: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>
From: zhang zhi <zhangzhi2022@hotmail.com>
To: "'Tim Deegan'" <tim@xen.org>
Date: Fri, 15 Feb 2013 23:59:23 +0800
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4LlNW3VBaqgHuxT6SEC/D+EVUBsw==
Content-Language: zh-cn
X-OriginalArrivalTime: 15 Feb 2013 15:59:24.0138 (UTC)
	FILETIME=[6CA924A0:01CE0B95]
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] ipi(inter-processor interrupt) about xen 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: multipart/mixed; boundary="===============0614268556441374483=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0614268556441374483==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002A_01CE0BD8.7ACFE710"
Content-Language: zh-cn

------=_NextPart_000_002A_01CE0BD8.7ACFE710
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Mr. Tim,

          I wanna ask you a question, hope you won't mind the inconvenience
that I gave to you. 

 

         In the context of multi-core mode, core 1 is in root-mode, meaning
that it's running VMM. And core 2 is in non-root mode, meaning that it's
running guest OS in kernel level. If core 1 wants core2 to execute a
pre-defined program located in kernel-mode, say a syscall or a virtual
external interrupt handler(the program is completed via syscall or another
kernel module). Considering that core1 is in vmm mode, and core2 is not
supposed to vm-exit, so I can't use the method of event-delivery. What kind
of thing should core 1 do ? 

         Can you give me some advice ? 

Thanks a lot !

 

Best Regards,

Zhang.

 


------=_NextPart_000_002A_01CE0BD8.7ACFE710
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-microsoft-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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator 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: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;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
/* Page Definitions */
@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=3DZH-CN link=3Dblue =
vlink=3Dpurple style=3D'text-justify-trim:punctuation'><div =
class=3DWordSection1><p class=3DMsoNormal><span lang=3DEN-US>Dear Mr. =
Tim,<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US> =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;I =
wanna ask you a question, hope you won&#8217;t mind the inconvenience =
that I gave to you. <o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the =
context of multi-core mode, core 1 is in root-mode, meaning that =
it&#8217;s running VMM. And core 2 is in non-root mode, meaning that =
it&#8217;s running guest OS in kernel level. If core 1 wants core2 to =
execute a pre-defined program located in kernel-mode, say a syscall or a =
virtual external interrupt handler(the program is completed via syscall =
or another kernel module). Considering that core1 is in vmm mode, and =
core2 is not supposed to vm-exit, so I can&#8217;t use the method of =
event-delivery. What kind of thing should core 1 do ? =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can you =
give me some advice ? <o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-indent:26.25pt'><span lang=3DEN-US>Thanks a lot =
!<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>Best Regards,<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>Zhang.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p></div></body></html>
------=_NextPart_000_002A_01CE0BD8.7ACFE710--


--===============0614268556441374483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0614268556441374483==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:15:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:15: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 1U6Nwq-00071i-DP; Fri, 15 Feb 2013 16:15:40 +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 1U6Nwo-00071d-Q9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:15:38 +0000
Received: from [85.158.143.35:48977] by server-2.bemta-4.messagelabs.com id
	FF/20-01597-92F5E115; Fri, 15 Feb 2013 16:15:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360944801!12375007!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10786 invoked from network); 15 Feb 2013 16:13:22 -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; 15 Feb 2013 16:13:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:13:20 +0000
Message-Id: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:13:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/4] AMD IOMMU: misc 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

This is to improve dealing with systems that have incorrect ACPI
tables, an erratum workaround ported over from Linux, and a
little bit of cleanup.

1: don't BUG() when we don't have to
2: cover all functions of a device even if ACPI only tells us of func 0
3: Family15h Model10-1Fh erratum 746 Workaround
4: use __ioapic_read_entry() instead of open coding it

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:15:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:15: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 1U6Nwq-00071i-DP; Fri, 15 Feb 2013 16:15:40 +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 1U6Nwo-00071d-Q9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:15:38 +0000
Received: from [85.158.143.35:48977] by server-2.bemta-4.messagelabs.com id
	FF/20-01597-92F5E115; Fri, 15 Feb 2013 16:15:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360944801!12375007!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10786 invoked from network); 15 Feb 2013 16:13:22 -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; 15 Feb 2013 16:13:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:13:20 +0000
Message-Id: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:13:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/4] AMD IOMMU: misc 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

This is to improve dealing with systems that have incorrect ACPI
tables, an erratum workaround ported over from Linux, and a
little bit of cleanup.

1: don't BUG() when we don't have to
2: cover all functions of a device even if ACPI only tells us of func 0
3: Family15h Model10-1Fh erratum 746 Workaround
4: use __ioapic_read_entry() instead of open coding it

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:17:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6NyP-00076K-TX; Fri, 15 Feb 2013 16:17: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 1U6NyP-00076E-7F
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:17:17 +0000
Received: from [193.109.254.147:59852] by server-13.bemta-14.messagelabs.com
	id BF/BC-30639-C8F5E115; Fri, 15 Feb 2013 16:17:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360945035!8538381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19317 invoked from network); 15 Feb 2013 16:17:16 -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; 15 Feb 2013 16:17:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:17:14 +0000
Message-Id: <511E6D9702000078000BED23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:17:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	netdev@vger.kernel.org, konrad.wilk@oracle.com,
	xen-devel@lists.xen.org, annie.li@oracle.com,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
> Also bundle fixes for xen frontends and backends in this patch.

Could you at least enumerate those fixes in the patch description?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:17:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6NyP-00076K-TX; Fri, 15 Feb 2013 16:17: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 1U6NyP-00076E-7F
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:17:17 +0000
Received: from [193.109.254.147:59852] by server-13.bemta-14.messagelabs.com
	id BF/BC-30639-C8F5E115; Fri, 15 Feb 2013 16:17:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360945035!8538381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19317 invoked from network); 15 Feb 2013 16:17:16 -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; 15 Feb 2013 16:17:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:17:14 +0000
Message-Id: <511E6D9702000078000BED23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:17:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	netdev@vger.kernel.org, konrad.wilk@oracle.com,
	xen-devel@lists.xen.org, annie.li@oracle.com,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
> Also bundle fixes for xen frontends and backends in this patch.

Could you at least enumerate those fixes in the patch description?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:20:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:20: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 1U6O0y-0007Fx-G2; Fri, 15 Feb 2013 16:19:56 +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 1U6O0w-0007Fj-PF
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:19:54 +0000
Received: from [193.109.254.147:38578] by server-16.bemta-14.messagelabs.com
	id 70/69-25906-A206E115; Fri, 15 Feb 2013 16:19:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360945193!8631918!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 15 Feb 2013 16:19:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:19:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:19:52 +0000
Message-Id: <511E6E3502000078000BED4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:19:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part72423035.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 1/4] AMD IOMMU: don't BUG() when we don't have to
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part72423035.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

find_iommu_for_device() can easily return NULL instead, as all of its
callers are prepared for that.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for_device(
 {
     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);
=20
-    BUG_ON ( bdf >=3D ivrs_bdf_entries );
-    return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;
+    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].io=
mmu
+                                                   : NULL;
 }
=20
 /*




--=__Part72423035.1__=
Content-Type: text/plain; name="AMD-IOMMU-replace-BUG_ON.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-replace-BUG_ON.patch"

AMD IOMMU: don't BUG() when we don't have to=0A=0Afind_iommu_for_device() =
can easily return NULL instead, as all of its=0Acallers are prepared for =
that.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A+++ b/xen/drivers/passthrou=
gh/amd/pci_amd_iommu.c=0A@@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for=
_device(=0A {=0A     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappi=
ngs(seg);=0A =0A-    BUG_ON ( bdf >=3D ivrs_bdf_entries );=0A-    return =
ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;=0A+    return ivrs_mapping=
s && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu=0A+                 =
                                  : NULL;=0A }=0A =0A /*=0A
--=__Part72423035.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

--=__Part72423035.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:20:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:20: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 1U6O0y-0007Fx-G2; Fri, 15 Feb 2013 16:19:56 +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 1U6O0w-0007Fj-PF
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:19:54 +0000
Received: from [193.109.254.147:38578] by server-16.bemta-14.messagelabs.com
	id 70/69-25906-A206E115; Fri, 15 Feb 2013 16:19:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360945193!8631918!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 15 Feb 2013 16:19:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:19:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:19:52 +0000
Message-Id: <511E6E3502000078000BED4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:19:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part72423035.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 1/4] AMD IOMMU: don't BUG() when we don't have to
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part72423035.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

find_iommu_for_device() can easily return NULL instead, as all of its
callers are prepared for that.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for_device(
 {
     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);
=20
-    BUG_ON ( bdf >=3D ivrs_bdf_entries );
-    return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;
+    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].io=
mmu
+                                                   : NULL;
 }
=20
 /*




--=__Part72423035.1__=
Content-Type: text/plain; name="AMD-IOMMU-replace-BUG_ON.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-replace-BUG_ON.patch"

AMD IOMMU: don't BUG() when we don't have to=0A=0Afind_iommu_for_device() =
can easily return NULL instead, as all of its=0Acallers are prepared for =
that.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A+++ b/xen/drivers/passthrou=
gh/amd/pci_amd_iommu.c=0A@@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for=
_device(=0A {=0A     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappi=
ngs(seg);=0A =0A-    BUG_ON ( bdf >=3D ivrs_bdf_entries );=0A-    return =
ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;=0A+    return ivrs_mapping=
s && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu=0A+                 =
                                  : NULL;=0A }=0A =0A /*=0A
--=__Part72423035.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

--=__Part72423035.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:20:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:20: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 1U6O1e-0007Jx-Uk; Fri, 15 Feb 2013 16:20:38 +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 1U6O1d-0007Jl-HC
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:20:37 +0000
Received: from [193.109.254.147:40462] by server-16.bemta-14.messagelabs.com
	id F1/3A-25906-4506E115; Fri, 15 Feb 2013 16:20:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360945233!1707720!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24521 invoked from network); 15 Feb 2013 16:20:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:20:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:20:33 +0000
Message-Id: <511E6E5F02000078000BED4E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:20:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part18285A5F.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 2/4] AMD IOMMU: cover all functions of a device
 even if ACPI only tells us of func 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>
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.

--=__Part18285A5F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This ought to work as all functions of a device have the same place in
the bus topology, i.e. use the same IOMMU.

Also fix the type of ivrs_bdf_entries (when it's 'unsigned short' and
the last device found on a segment is ff:1f.x, it would otherwise end
up being zero).

And drop the bogus 'last_bdf' static variable, which conflicted anyway
with various functions' parameters.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -54,8 +54,6 @@ union acpi_ivhd_device {
    struct acpi_ivrs_device8c special;
 };
=20
-static unsigned short __initdata last_bdf;
-
 static void __init add_ivrs_mapping_entry(
     u16 bdf, u16 alias_id, u8 flags, struct amd_iommu *iommu)
 {
@@ -991,6 +989,7 @@ static int __init get_last_bdf_ivhd(
 {
     const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
+    int last_bdf =3D 0;
=20
     if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
@@ -1051,27 +1050,34 @@ static int __init get_last_bdf_ivhd(
             return -ENODEV;
     }
=20
-    return 0;
+    return last_bdf;
 }
=20
 static int __init get_last_bdf_acpi(struct acpi_table_header *table)
 {
     const struct acpi_ivrs_header *ivrs_block;
     unsigned long length =3D sizeof(struct acpi_table_ivrs);
+    int last_bdf =3D 0;
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
-             get_last_bdf_ivhd(
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE )
+        {
+            int ret =3D get_last_bdf_ivhd(
                  container_of(ivrs_block, const struct acpi_ivrs_hardware,=

-                              header)) !=3D 0 )
-            return -ENODEV;
+                              header));
+
+            if ( ret < 0 )
+                return ret;
+            UPDATE_LAST_BDF(ret);
+        }
         length +=3D ivrs_block->length;
     }
-   return 0;
+
+    return last_bdf;
 }
=20
 int __init amd_iommu_detect_acpi(void)
@@ -1081,8 +1087,9 @@ int __init amd_iommu_detect_acpi(void)
=20
 int __init amd_iommu_get_ivrs_dev_entries(void)
 {
-    acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
-    return last_bdf + 1;
+    int ret =3D acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
+
+    return ret < 0 ? ret : (ret | PCI_FUNC(~0)) + 1;
 }
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -35,7 +35,7 @@ static int __initdata nr_amd_iommus;
=20
 static struct tasklet amd_iommu_irq_tasklet;
=20
-unsigned short ivrs_bdf_entries;
+unsigned int __read_mostly ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -28,12 +28,38 @@
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include "../ats.h"
=20
+static bool_t __read_mostly init_done;
+
 struct amd_iommu *find_iommu_for_device(int seg, int bdf)
 {
     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);
=20
-    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].io=
mmu
-                                                   : NULL;
+    if ( !ivrs_mappings || bdf >=3D ivrs_bdf_entries )
+        return NULL;
+
+    if ( unlikely(!ivrs_mappings[bdf].iommu) && likely(init_done) )
+    {
+        unsigned int bd0 =3D bdf & ~PCI_FUNC(~0);
+
+        if ( ivrs_mappings[bd0].iommu )
+        {
+            struct ivrs_mappings tmp =3D ivrs_mappings[bd0];
+
+            tmp.iommu =3D NULL;
+            if ( tmp.dte_requestor_id =3D=3D bd0 )
+                tmp.dte_requestor_id =3D bdf;
+            ivrs_mappings[bdf] =3D tmp;
+
+            printk(XENLOG_WARNING "%04x:%02x:%02x.%u not found in ACPI =
tables;"
+                   " using same IOMMU as function 0\n",
+                   seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf));
+
+            /* write iommu field last */
+            ivrs_mappings[bdf].iommu =3D ivrs_mappings[bd0].iommu;
+        }
+    }
+
+    return ivrs_mappings[bdf].iommu;
 }
=20
 /*
@@ -179,6 +205,8 @@ int __init amd_iov_detect(void)
         return -ENODEV;
     }
=20
+    init_done =3D 1;
+
     /*
      * AMD IOMMUs don't distinguish between vectors destined for
      * different cpus when doing interrupt remapping.  This means
--- a/xen/include/asm-x86/amd-iommu.h
+++ b/xen/include/asm-x86/amd-iommu.h
@@ -125,7 +125,7 @@ struct ivrs_mappings {
     u8 device_flags;
 };
=20
-extern unsigned short ivrs_bdf_entries;
+extern unsigned int ivrs_bdf_entries;
=20
 struct ivrs_mappings *get_ivrs_mappings(u16 seg);
 int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));



--=__Part18285A5F.1__=
Content-Type: text/plain; name="AMD-IOMMU-cover-all-functions.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-cover-all-functions.patch"

AMD IOMMU: cover all functions of a device even if ACPI only tells us of =
func 0=0A=0AThis ought to work as all functions of a device have the same =
place in=0Athe bus topology, i.e. use the same IOMMU.=0A=0AAlso fix the =
type of ivrs_bdf_entries (when it's 'unsigned short' and=0Athe last device =
found on a segment is ff:1f.x, it would otherwise end=0Aup being =
zero).=0A=0AAnd drop the bogus 'last_bdf' static variable, which conflicted=
 anyway=0Awith various functions' parameters.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_ac=
pi.c=0A+++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -54,8 +54,6 @@ =
union acpi_ivhd_device {=0A    struct acpi_ivrs_device8c special;=0A };=0A =
=0A-static unsigned short __initdata last_bdf;=0A-=0A static void __init =
add_ivrs_mapping_entry(=0A     u16 bdf, u16 alias_id, u8 flags, struct =
amd_iommu *iommu)=0A {=0A@@ -991,6 +989,7 @@ static int __init get_last_bdf=
_ivhd(=0A {=0A     const union acpi_ivhd_device *ivhd_device;=0A     u16 =
block_length, dev_length;=0A+    int last_bdf =3D 0;=0A =0A     if ( =
ivhd_block->header.length < sizeof(*ivhd_block) )=0A     {=0A@@ -1051,27 =
+1050,34 @@ static int __init get_last_bdf_ivhd(=0A             return =
-ENODEV;=0A     }=0A =0A-    return 0;=0A+    return last_bdf;=0A }=0A =0A =
static int __init get_last_bdf_acpi(struct acpi_table_header *table)=0A =
{=0A     const struct acpi_ivrs_header *ivrs_block;=0A     unsigned long =
length =3D sizeof(struct acpi_table_ivrs);=0A+    int last_bdf =3D 0;=0A =
=0A     while ( table->length > (length + sizeof(*ivrs_block)) )=0A     =
{=0A         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A         if ( table->length < (length + ivrs_block->length) =
)=0A             return -ENODEV;=0A-        if ( ivrs_block->type =3D=3D =
ACPI_IVRS_TYPE_HARDWARE &&=0A-             get_last_bdf_ivhd(=0A+        =
if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE )=0A+        {=0A+    =
        int ret =3D get_last_bdf_ivhd(=0A                  container_of(ivr=
s_block, const struct acpi_ivrs_hardware,=0A-                              =
header)) !=3D 0 )=0A-            return -ENODEV;=0A+                       =
       header));=0A+=0A+            if ( ret < 0 )=0A+                =
return ret;=0A+            UPDATE_LAST_BDF(ret);=0A+        }=0A         =
length +=3D ivrs_block->length;=0A     }=0A-   return 0;=0A+=0A+    return =
last_bdf;=0A }=0A =0A int __init amd_iommu_detect_acpi(void)=0A@@ -1081,8 =
+1087,9 @@ int __init amd_iommu_detect_acpi(void)=0A =0A int __init =
amd_iommu_get_ivrs_dev_entries(void)=0A {=0A-    acpi_table_parse(ACPI_SIG_=
IVRS, get_last_bdf_acpi);=0A-    return last_bdf + 1;=0A+    int ret =3D =
acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);=0A+=0A+    return ret =
< 0 ? ret : (ret | PCI_FUNC(~0)) + 1;=0A }=0A =0A int __init amd_iommu_upda=
te_ivrs_mapping_acpi(void)=0A--- a/xen/drivers/passthrough/amd/iommu_init.c=
=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -35,7 +35,7 @@ =
static int __initdata nr_amd_iommus;=0A =0A static struct tasklet =
amd_iommu_irq_tasklet;=0A =0A-unsigned short ivrs_bdf_entries;=0A+unsigned =
int __read_mostly ivrs_bdf_entries;=0A static struct radix_tree_root =
ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct =
device_table;=0A--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A+++ =
b/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A@@ -28,12 +28,38 @@=0A =
#include <asm/hvm/svm/amd-iommu-proto.h>=0A #include "../ats.h"=0A =
=0A+static bool_t __read_mostly init_done;=0A+=0A struct amd_iommu =
*find_iommu_for_device(int seg, int bdf)=0A {=0A     struct ivrs_mappings =
*ivrs_mappings =3D get_ivrs_mappings(seg);=0A =0A-    return ivrs_mappings =
&& bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu=0A-                   =
                                : NULL;=0A+    if ( !ivrs_mappings || bdf =
>=3D ivrs_bdf_entries )=0A+        return NULL;=0A+=0A+    if ( unlikely(!i=
vrs_mappings[bdf].iommu) && likely(init_done) )=0A+    {=0A+        =
unsigned int bd0 =3D bdf & ~PCI_FUNC(~0);=0A+=0A+        if ( ivrs_mappings=
[bd0].iommu )=0A+        {=0A+            struct ivrs_mappings tmp =3D =
ivrs_mappings[bd0];=0A+=0A+            tmp.iommu =3D NULL;=0A+            =
if ( tmp.dte_requestor_id =3D=3D bd0 )=0A+                tmp.dte_requestor=
_id =3D bdf;=0A+            ivrs_mappings[bdf] =3D tmp;=0A+=0A+            =
printk(XENLOG_WARNING "%04x:%02x:%02x.%u not found in ACPI tables;"=0A+    =
               " using same IOMMU as function 0\n",=0A+                   =
seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf));=0A+=0A+            /* =
write iommu field last */=0A+            ivrs_mappings[bdf].iommu =3D =
ivrs_mappings[bd0].iommu;=0A+        }=0A+    }=0A+=0A+    return =
ivrs_mappings[bdf].iommu;=0A }=0A =0A /*=0A@@ -179,6 +205,8 @@ int __init =
amd_iov_detect(void)=0A         return -ENODEV;=0A     }=0A =0A+    =
init_done =3D 1;=0A+=0A     /*=0A      * AMD IOMMUs don't distinguish =
between vectors destined for=0A      * different cpus when doing interrupt =
remapping.  This means=0A--- a/xen/include/asm-x86/amd-iommu.h=0A+++ =
b/xen/include/asm-x86/amd-iommu.h=0A@@ -125,7 +125,7 @@ struct ivrs_mapping=
s {=0A     u8 device_flags;=0A };=0A =0A-extern unsigned short ivrs_bdf_ent=
ries;=0A+extern unsigned int ivrs_bdf_entries;=0A =0A struct ivrs_mappings =
*get_ivrs_mappings(u16 seg);=0A int iterate_ivrs_mappings(int (*)(u16 seg, =
struct ivrs_mappings *));=0A
--=__Part18285A5F.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

--=__Part18285A5F.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:20:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:20: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 1U6O1e-0007Jx-Uk; Fri, 15 Feb 2013 16:20:38 +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 1U6O1d-0007Jl-HC
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:20:37 +0000
Received: from [193.109.254.147:40462] by server-16.bemta-14.messagelabs.com
	id F1/3A-25906-4506E115; Fri, 15 Feb 2013 16:20:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360945233!1707720!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24521 invoked from network); 15 Feb 2013 16:20:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:20:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:20:33 +0000
Message-Id: <511E6E5F02000078000BED4E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:20:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part18285A5F.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 2/4] AMD IOMMU: cover all functions of a device
 even if ACPI only tells us of func 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>
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.

--=__Part18285A5F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This ought to work as all functions of a device have the same place in
the bus topology, i.e. use the same IOMMU.

Also fix the type of ivrs_bdf_entries (when it's 'unsigned short' and
the last device found on a segment is ff:1f.x, it would otherwise end
up being zero).

And drop the bogus 'last_bdf' static variable, which conflicted anyway
with various functions' parameters.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -54,8 +54,6 @@ union acpi_ivhd_device {
    struct acpi_ivrs_device8c special;
 };
=20
-static unsigned short __initdata last_bdf;
-
 static void __init add_ivrs_mapping_entry(
     u16 bdf, u16 alias_id, u8 flags, struct amd_iommu *iommu)
 {
@@ -991,6 +989,7 @@ static int __init get_last_bdf_ivhd(
 {
     const union acpi_ivhd_device *ivhd_device;
     u16 block_length, dev_length;
+    int last_bdf =3D 0;
=20
     if ( ivhd_block->header.length < sizeof(*ivhd_block) )
     {
@@ -1051,27 +1050,34 @@ static int __init get_last_bdf_ivhd(
             return -ENODEV;
     }
=20
-    return 0;
+    return last_bdf;
 }
=20
 static int __init get_last_bdf_acpi(struct acpi_table_header *table)
 {
     const struct acpi_ivrs_header *ivrs_block;
     unsigned long length =3D sizeof(struct acpi_table_ivrs);
+    int last_bdf =3D 0;
=20
     while ( table->length > (length + sizeof(*ivrs_block)) )
     {
         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
         if ( table->length < (length + ivrs_block->length) )
             return -ENODEV;
-        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE &&
-             get_last_bdf_ivhd(
+        if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE )
+        {
+            int ret =3D get_last_bdf_ivhd(
                  container_of(ivrs_block, const struct acpi_ivrs_hardware,=

-                              header)) !=3D 0 )
-            return -ENODEV;
+                              header));
+
+            if ( ret < 0 )
+                return ret;
+            UPDATE_LAST_BDF(ret);
+        }
         length +=3D ivrs_block->length;
     }
-   return 0;
+
+    return last_bdf;
 }
=20
 int __init amd_iommu_detect_acpi(void)
@@ -1081,8 +1087,9 @@ int __init amd_iommu_detect_acpi(void)
=20
 int __init amd_iommu_get_ivrs_dev_entries(void)
 {
-    acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
-    return last_bdf + 1;
+    int ret =3D acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);
+
+    return ret < 0 ? ret : (ret | PCI_FUNC(~0)) + 1;
 }
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -35,7 +35,7 @@ static int __initdata nr_amd_iommus;
=20
 static struct tasklet amd_iommu_irq_tasklet;
=20
-unsigned short ivrs_bdf_entries;
+unsigned int __read_mostly ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
 struct table_struct device_table;
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -28,12 +28,38 @@
 #include <asm/hvm/svm/amd-iommu-proto.h>
 #include "../ats.h"
=20
+static bool_t __read_mostly init_done;
+
 struct amd_iommu *find_iommu_for_device(int seg, int bdf)
 {
     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);
=20
-    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].io=
mmu
-                                                   : NULL;
+    if ( !ivrs_mappings || bdf >=3D ivrs_bdf_entries )
+        return NULL;
+
+    if ( unlikely(!ivrs_mappings[bdf].iommu) && likely(init_done) )
+    {
+        unsigned int bd0 =3D bdf & ~PCI_FUNC(~0);
+
+        if ( ivrs_mappings[bd0].iommu )
+        {
+            struct ivrs_mappings tmp =3D ivrs_mappings[bd0];
+
+            tmp.iommu =3D NULL;
+            if ( tmp.dte_requestor_id =3D=3D bd0 )
+                tmp.dte_requestor_id =3D bdf;
+            ivrs_mappings[bdf] =3D tmp;
+
+            printk(XENLOG_WARNING "%04x:%02x:%02x.%u not found in ACPI =
tables;"
+                   " using same IOMMU as function 0\n",
+                   seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf));
+
+            /* write iommu field last */
+            ivrs_mappings[bdf].iommu =3D ivrs_mappings[bd0].iommu;
+        }
+    }
+
+    return ivrs_mappings[bdf].iommu;
 }
=20
 /*
@@ -179,6 +205,8 @@ int __init amd_iov_detect(void)
         return -ENODEV;
     }
=20
+    init_done =3D 1;
+
     /*
      * AMD IOMMUs don't distinguish between vectors destined for
      * different cpus when doing interrupt remapping.  This means
--- a/xen/include/asm-x86/amd-iommu.h
+++ b/xen/include/asm-x86/amd-iommu.h
@@ -125,7 +125,7 @@ struct ivrs_mappings {
     u8 device_flags;
 };
=20
-extern unsigned short ivrs_bdf_entries;
+extern unsigned int ivrs_bdf_entries;
=20
 struct ivrs_mappings *get_ivrs_mappings(u16 seg);
 int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));



--=__Part18285A5F.1__=
Content-Type: text/plain; name="AMD-IOMMU-cover-all-functions.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-cover-all-functions.patch"

AMD IOMMU: cover all functions of a device even if ACPI only tells us of =
func 0=0A=0AThis ought to work as all functions of a device have the same =
place in=0Athe bus topology, i.e. use the same IOMMU.=0A=0AAlso fix the =
type of ivrs_bdf_entries (when it's 'unsigned short' and=0Athe last device =
found on a segment is ff:1f.x, it would otherwise end=0Aup being =
zero).=0A=0AAnd drop the bogus 'last_bdf' static variable, which conflicted=
 anyway=0Awith various functions' parameters.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_ac=
pi.c=0A+++ b/xen/drivers/passthrough/amd/iommu_acpi.c=0A@@ -54,8 +54,6 @@ =
union acpi_ivhd_device {=0A    struct acpi_ivrs_device8c special;=0A };=0A =
=0A-static unsigned short __initdata last_bdf;=0A-=0A static void __init =
add_ivrs_mapping_entry(=0A     u16 bdf, u16 alias_id, u8 flags, struct =
amd_iommu *iommu)=0A {=0A@@ -991,6 +989,7 @@ static int __init get_last_bdf=
_ivhd(=0A {=0A     const union acpi_ivhd_device *ivhd_device;=0A     u16 =
block_length, dev_length;=0A+    int last_bdf =3D 0;=0A =0A     if ( =
ivhd_block->header.length < sizeof(*ivhd_block) )=0A     {=0A@@ -1051,27 =
+1050,34 @@ static int __init get_last_bdf_ivhd(=0A             return =
-ENODEV;=0A     }=0A =0A-    return 0;=0A+    return last_bdf;=0A }=0A =0A =
static int __init get_last_bdf_acpi(struct acpi_table_header *table)=0A =
{=0A     const struct acpi_ivrs_header *ivrs_block;=0A     unsigned long =
length =3D sizeof(struct acpi_table_ivrs);=0A+    int last_bdf =3D 0;=0A =
=0A     while ( table->length > (length + sizeof(*ivrs_block)) )=0A     =
{=0A         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A         if ( table->length < (length + ivrs_block->length) =
)=0A             return -ENODEV;=0A-        if ( ivrs_block->type =3D=3D =
ACPI_IVRS_TYPE_HARDWARE &&=0A-             get_last_bdf_ivhd(=0A+        =
if ( ivrs_block->type =3D=3D ACPI_IVRS_TYPE_HARDWARE )=0A+        {=0A+    =
        int ret =3D get_last_bdf_ivhd(=0A                  container_of(ivr=
s_block, const struct acpi_ivrs_hardware,=0A-                              =
header)) !=3D 0 )=0A-            return -ENODEV;=0A+                       =
       header));=0A+=0A+            if ( ret < 0 )=0A+                =
return ret;=0A+            UPDATE_LAST_BDF(ret);=0A+        }=0A         =
length +=3D ivrs_block->length;=0A     }=0A-   return 0;=0A+=0A+    return =
last_bdf;=0A }=0A =0A int __init amd_iommu_detect_acpi(void)=0A@@ -1081,8 =
+1087,9 @@ int __init amd_iommu_detect_acpi(void)=0A =0A int __init =
amd_iommu_get_ivrs_dev_entries(void)=0A {=0A-    acpi_table_parse(ACPI_SIG_=
IVRS, get_last_bdf_acpi);=0A-    return last_bdf + 1;=0A+    int ret =3D =
acpi_table_parse(ACPI_SIG_IVRS, get_last_bdf_acpi);=0A+=0A+    return ret =
< 0 ? ret : (ret | PCI_FUNC(~0)) + 1;=0A }=0A =0A int __init amd_iommu_upda=
te_ivrs_mapping_acpi(void)=0A--- a/xen/drivers/passthrough/amd/iommu_init.c=
=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -35,7 +35,7 @@ =
static int __initdata nr_amd_iommus;=0A =0A static struct tasklet =
amd_iommu_irq_tasklet;=0A =0A-unsigned short ivrs_bdf_entries;=0A+unsigned =
int __read_mostly ivrs_bdf_entries;=0A static struct radix_tree_root =
ivrs_maps;=0A struct list_head amd_iommu_head;=0A struct table_struct =
device_table;=0A--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A+++ =
b/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A@@ -28,12 +28,38 @@=0A =
#include <asm/hvm/svm/amd-iommu-proto.h>=0A #include "../ats.h"=0A =
=0A+static bool_t __read_mostly init_done;=0A+=0A struct amd_iommu =
*find_iommu_for_device(int seg, int bdf)=0A {=0A     struct ivrs_mappings =
*ivrs_mappings =3D get_ivrs_mappings(seg);=0A =0A-    return ivrs_mappings =
&& bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu=0A-                   =
                                : NULL;=0A+    if ( !ivrs_mappings || bdf =
>=3D ivrs_bdf_entries )=0A+        return NULL;=0A+=0A+    if ( unlikely(!i=
vrs_mappings[bdf].iommu) && likely(init_done) )=0A+    {=0A+        =
unsigned int bd0 =3D bdf & ~PCI_FUNC(~0);=0A+=0A+        if ( ivrs_mappings=
[bd0].iommu )=0A+        {=0A+            struct ivrs_mappings tmp =3D =
ivrs_mappings[bd0];=0A+=0A+            tmp.iommu =3D NULL;=0A+            =
if ( tmp.dte_requestor_id =3D=3D bd0 )=0A+                tmp.dte_requestor=
_id =3D bdf;=0A+            ivrs_mappings[bdf] =3D tmp;=0A+=0A+            =
printk(XENLOG_WARNING "%04x:%02x:%02x.%u not found in ACPI tables;"=0A+    =
               " using same IOMMU as function 0\n",=0A+                   =
seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf));=0A+=0A+            /* =
write iommu field last */=0A+            ivrs_mappings[bdf].iommu =3D =
ivrs_mappings[bd0].iommu;=0A+        }=0A+    }=0A+=0A+    return =
ivrs_mappings[bdf].iommu;=0A }=0A =0A /*=0A@@ -179,6 +205,8 @@ int __init =
amd_iov_detect(void)=0A         return -ENODEV;=0A     }=0A =0A+    =
init_done =3D 1;=0A+=0A     /*=0A      * AMD IOMMUs don't distinguish =
between vectors destined for=0A      * different cpus when doing interrupt =
remapping.  This means=0A--- a/xen/include/asm-x86/amd-iommu.h=0A+++ =
b/xen/include/asm-x86/amd-iommu.h=0A@@ -125,7 +125,7 @@ struct ivrs_mapping=
s {=0A     u8 device_flags;=0A };=0A =0A-extern unsigned short ivrs_bdf_ent=
ries;=0A+extern unsigned int ivrs_bdf_entries;=0A =0A struct ivrs_mappings =
*get_ivrs_mappings(u16 seg);=0A int iterate_ivrs_mappings(int (*)(u16 seg, =
struct ivrs_mappings *));=0A
--=__Part18285A5F.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

--=__Part18285A5F.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:21:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:21: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 1U6O2a-0007Tg-Ki; Fri, 15 Feb 2013 16:21:36 +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 1U6O2Z-0007TS-21
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:21:35 +0000
Received: from [193.109.254.147:20735] by server-11.bemta-14.messagelabs.com
	id 05/F5-30685-E806E115; Fri, 15 Feb 2013 16:21:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360945293!8632107!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32149 invoked from network); 15 Feb 2013 16:21:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:21:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:21:32 +0000
Message-Id: <511E6E9A02000078000BED52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:21:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDED9F9A.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, suravee.suthikulpanit@amd.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 3/4] IOMMU,
 AMD Family15h Model10-1Fh erratum 746 Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartDDED9F9A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The IOMMU may stop processing page translations due to a perceived lack
of credits for writing upstream peripheral page service request (PPR)
or event logs. If the L2B miscellaneous clock gating feature is enabled
the IOMMU does not properly register credits after the log request has
completed, leading to a potential system hang.

BIOSes are supposed to disable L2B micellaneous clock gating by setting
L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) =3D 1b. This
patch corrects that for those which do not enable this workaround.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -792,6 +792,42 @@ static bool_t __init set_iommu_interrupt
     return 1;
 }
=20
+/*
+ * Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translatio=
ns)
+ * Workaround:
+ *     BIOS should disable L2B micellaneous clock gating by setting
+ *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) =3D =
1b
+ */
+static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu)
+{
+    u32 value;
+    u8 bus =3D PCI_BUS(iommu->bdf);
+    u8 dev =3D PCI_SLOT(iommu->bdf);
+    u8 func =3D PCI_FUNC(iommu->bdf);
+
+    if ( (boot_cpu_data.x86 !=3D 0x15) ||
+         (boot_cpu_data.x86_model < 0x10) ||
+         (boot_cpu_data.x86_model > 0x1f) )
+        return;
+
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
+    value =3D pci_conf_read32(iommu->seg, bus, dev, func, 0xf4);
+
+    if ( value & (1 << 2) )
+        return;
+
+    /* Select NB indirect register 0x90 and enable writing */
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90 | (1 << 8));
+
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf4, value | (1 << 2));
+    printk(XENLOG_INFO
+           "AMD-Vi: Applying erratum 746 workaround for IOMMU at =
%04x:%02x:%02x.%u\n",
+           iommu->seg, bus, dev, func);
+
+    /* Clear the enable writing bit */
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
+}
+
 static void enable_iommu(struct amd_iommu *iommu)
 {
     unsigned long flags;
@@ -805,6 +841,8 @@ static void enable_iommu(struct amd_iomm
         return;
     }
=20
+    amd_iommu_erratum_746_workaround(iommu);
+
     register_iommu_dev_table_in_mmio_space(iommu);
     register_iommu_cmd_buffer_in_mmio_space(iommu);
     register_iommu_event_log_in_mmio_space(iommu);




--=__PartDDED9F9A.1__=
Content-Type: text/plain; name="AMD-IOMMU-erratum-746.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-erratum-746.patch"

IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround=0A=0AThe IOMMU may =
stop processing page translations due to a perceived lack=0Aof credits for =
writing upstream peripheral page service request (PPR)=0Aor event logs. If =
the L2B miscellaneous clock gating feature is enabled=0Athe IOMMU does not =
properly register credits after the log request has=0Acompleted, leading =
to a potential system hang.=0A=0ABIOSes are supposed to disable L2B =
micellaneous clock gating by setting=0AL2_L2B_CK_GATE_CONTROL[CKGateL2BMisc=
Disable](D0F2xF4_x90[2]) =3D 1b. This=0Apatch corrects that for those =
which do not enable this workaround.=0A=0ASigned-off-by: Suravee Suthikulpa=
nit <suravee.suthikulpanit@amd.com>=0ASigned-off-by: Jan Beulich <jbeulich@=
suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -792,6 +792,42 @@ static =
bool_t __init set_iommu_interrupt=0A     return 1;=0A }=0A =0A+/*=0A+ * =
Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translations)=
=0A+ * Workaround:=0A+ *     BIOS should disable L2B micellaneous clock =
gating by setting=0A+ *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0=
F2xF4_x90[2]) =3D 1b=0A+ */=0A+static void amd_iommu_erratum_746_workaround=
(struct amd_iommu *iommu)=0A+{=0A+    u32 value;=0A+    u8 bus =3D =
PCI_BUS(iommu->bdf);=0A+    u8 dev =3D PCI_SLOT(iommu->bdf);=0A+    u8 =
func =3D PCI_FUNC(iommu->bdf);=0A+=0A+    if ( (boot_cpu_data.x86 !=3D =
0x15) ||=0A+         (boot_cpu_data.x86_model < 0x10) ||=0A+         =
(boot_cpu_data.x86_model > 0x1f) )=0A+        return;=0A+=0A+    pci_conf_w=
rite32(iommu->seg, bus, dev, func, 0xf0, 0x90);=0A+    value =3D pci_conf_r=
ead32(iommu->seg, bus, dev, func, 0xf4);=0A+=0A+    if ( value & (1 << 2) =
)=0A+        return;=0A+=0A+    /* Select NB indirect register 0x90 and =
enable writing */=0A+    pci_conf_write32(iommu->seg, bus, dev, func, =
0xf0, 0x90 | (1 << 8));=0A+=0A+    pci_conf_write32(iommu->seg, bus, dev, =
func, 0xf4, value | (1 << 2));=0A+    printk(XENLOG_INFO=0A+           =
"AMD-Vi: Applying erratum 746 workaround for IOMMU at %04x:%02x:%02x.%u\n",=
=0A+           iommu->seg, bus, dev, func);=0A+=0A+    /* Clear the enable =
writing bit */=0A+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, =
0x90);=0A+}=0A+=0A static void enable_iommu(struct amd_iommu *iommu)=0A =
{=0A     unsigned long flags;=0A@@ -805,6 +841,8 @@ static void enable_iomm=
u(struct amd_iomm=0A         return;=0A     }=0A =0A+    amd_iommu_erratum_=
746_workaround(iommu);=0A+=0A     register_iommu_dev_table_in_mmio_space(io=
mmu);=0A     register_iommu_cmd_buffer_in_mmio_space(iommu);=0A     =
register_iommu_event_log_in_mmio_space(iommu);=0A
--=__PartDDED9F9A.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

--=__PartDDED9F9A.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:21:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:21: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 1U6O2a-0007Tg-Ki; Fri, 15 Feb 2013 16:21:36 +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 1U6O2Z-0007TS-21
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:21:35 +0000
Received: from [193.109.254.147:20735] by server-11.bemta-14.messagelabs.com
	id 05/F5-30685-E806E115; Fri, 15 Feb 2013 16:21:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360945293!8632107!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32149 invoked from network); 15 Feb 2013 16:21:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:21:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:21:32 +0000
Message-Id: <511E6E9A02000078000BED52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:21:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDED9F9A.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, suravee.suthikulpanit@amd.com,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 3/4] IOMMU,
 AMD Family15h Model10-1Fh erratum 746 Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartDDED9F9A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The IOMMU may stop processing page translations due to a perceived lack
of credits for writing upstream peripheral page service request (PPR)
or event logs. If the L2B miscellaneous clock gating feature is enabled
the IOMMU does not properly register credits after the log request has
completed, leading to a potential system hang.

BIOSes are supposed to disable L2B micellaneous clock gating by setting
L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) =3D 1b. This
patch corrects that for those which do not enable this workaround.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -792,6 +792,42 @@ static bool_t __init set_iommu_interrupt
     return 1;
 }
=20
+/*
+ * Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translatio=
ns)
+ * Workaround:
+ *     BIOS should disable L2B micellaneous clock gating by setting
+ *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) =3D =
1b
+ */
+static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu)
+{
+    u32 value;
+    u8 bus =3D PCI_BUS(iommu->bdf);
+    u8 dev =3D PCI_SLOT(iommu->bdf);
+    u8 func =3D PCI_FUNC(iommu->bdf);
+
+    if ( (boot_cpu_data.x86 !=3D 0x15) ||
+         (boot_cpu_data.x86_model < 0x10) ||
+         (boot_cpu_data.x86_model > 0x1f) )
+        return;
+
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
+    value =3D pci_conf_read32(iommu->seg, bus, dev, func, 0xf4);
+
+    if ( value & (1 << 2) )
+        return;
+
+    /* Select NB indirect register 0x90 and enable writing */
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90 | (1 << 8));
+
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf4, value | (1 << 2));
+    printk(XENLOG_INFO
+           "AMD-Vi: Applying erratum 746 workaround for IOMMU at =
%04x:%02x:%02x.%u\n",
+           iommu->seg, bus, dev, func);
+
+    /* Clear the enable writing bit */
+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
+}
+
 static void enable_iommu(struct amd_iommu *iommu)
 {
     unsigned long flags;
@@ -805,6 +841,8 @@ static void enable_iommu(struct amd_iomm
         return;
     }
=20
+    amd_iommu_erratum_746_workaround(iommu);
+
     register_iommu_dev_table_in_mmio_space(iommu);
     register_iommu_cmd_buffer_in_mmio_space(iommu);
     register_iommu_event_log_in_mmio_space(iommu);




--=__PartDDED9F9A.1__=
Content-Type: text/plain; name="AMD-IOMMU-erratum-746.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-erratum-746.patch"

IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround=0A=0AThe IOMMU may =
stop processing page translations due to a perceived lack=0Aof credits for =
writing upstream peripheral page service request (PPR)=0Aor event logs. If =
the L2B miscellaneous clock gating feature is enabled=0Athe IOMMU does not =
properly register credits after the log request has=0Acompleted, leading =
to a potential system hang.=0A=0ABIOSes are supposed to disable L2B =
micellaneous clock gating by setting=0AL2_L2B_CK_GATE_CONTROL[CKGateL2BMisc=
Disable](D0F2xF4_x90[2]) =3D 1b. This=0Apatch corrects that for those =
which do not enable this workaround.=0A=0ASigned-off-by: Suravee Suthikulpa=
nit <suravee.suthikulpanit@amd.com>=0ASigned-off-by: Jan Beulich <jbeulich@=
suse.com>=0A=0A--- a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ -792,6 +792,42 @@ static =
bool_t __init set_iommu_interrupt=0A     return 1;=0A }=0A =0A+/*=0A+ * =
Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translations)=
=0A+ * Workaround:=0A+ *     BIOS should disable L2B micellaneous clock =
gating by setting=0A+ *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0=
F2xF4_x90[2]) =3D 1b=0A+ */=0A+static void amd_iommu_erratum_746_workaround=
(struct amd_iommu *iommu)=0A+{=0A+    u32 value;=0A+    u8 bus =3D =
PCI_BUS(iommu->bdf);=0A+    u8 dev =3D PCI_SLOT(iommu->bdf);=0A+    u8 =
func =3D PCI_FUNC(iommu->bdf);=0A+=0A+    if ( (boot_cpu_data.x86 !=3D =
0x15) ||=0A+         (boot_cpu_data.x86_model < 0x10) ||=0A+         =
(boot_cpu_data.x86_model > 0x1f) )=0A+        return;=0A+=0A+    pci_conf_w=
rite32(iommu->seg, bus, dev, func, 0xf0, 0x90);=0A+    value =3D pci_conf_r=
ead32(iommu->seg, bus, dev, func, 0xf4);=0A+=0A+    if ( value & (1 << 2) =
)=0A+        return;=0A+=0A+    /* Select NB indirect register 0x90 and =
enable writing */=0A+    pci_conf_write32(iommu->seg, bus, dev, func, =
0xf0, 0x90 | (1 << 8));=0A+=0A+    pci_conf_write32(iommu->seg, bus, dev, =
func, 0xf4, value | (1 << 2));=0A+    printk(XENLOG_INFO=0A+           =
"AMD-Vi: Applying erratum 746 workaround for IOMMU at %04x:%02x:%02x.%u\n",=
=0A+           iommu->seg, bus, dev, func);=0A+=0A+    /* Clear the enable =
writing bit */=0A+    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, =
0x90);=0A+}=0A+=0A static void enable_iommu(struct amd_iommu *iommu)=0A =
{=0A     unsigned long flags;=0A@@ -805,6 +841,8 @@ static void enable_iomm=
u(struct amd_iomm=0A         return;=0A     }=0A =0A+    amd_iommu_erratum_=
746_workaround(iommu);=0A+=0A     register_iommu_dev_table_in_mmio_space(io=
mmu);=0A     register_iommu_cmd_buffer_in_mmio_space(iommu);=0A     =
register_iommu_event_log_in_mmio_space(iommu);=0A
--=__PartDDED9F9A.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

--=__PartDDED9F9A.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:23:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6O3s-0007eR-4o; Fri, 15 Feb 2013 16:22:56 +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 1U6O3q-0007eD-Bb
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:22:54 +0000
Received: from [193.109.254.147:28124] by server-16.bemta-14.messagelabs.com
	id B9/CC-25906-DD06E115; Fri, 15 Feb 2013 16:22:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360945372!8417521!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6192 invoked from network); 15 Feb 2013 16:22:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:22:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:22:52 +0000
Message-Id: <511E6EEA02000078000BED56@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:22:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8DBDCFCA.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 4/4] AMD IOMMU: use __ioapic_read_entry()
 instead of open coding 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

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.

--=__Part8DBDCFCA.1__=
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/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -144,7 +144,7 @@ static void update_intremap_entry_from_i
=20
 int __init amd_iommu_setup_ioapic_remapping(void)
 {
-    struct IO_APIC_route_entry rte =3D {0};
+    struct IO_APIC_route_entry rte;
     unsigned long flags;
     u32* entry;
     int apic, pin;
@@ -159,9 +159,7 @@ int __init amd_iommu_setup_ioapic_remapp
     {
         for ( pin =3D 0; pin < nr_ioapic_entries[apic]; pin++ )
         {
-            *(((int *)&rte) + 1) =3D io_apic_read(apic, 0x11 + 2 * pin);
-            *(((int *)&rte) + 0) =3D io_apic_read(apic, 0x10 + 2 * pin);
-
+            rte =3D __ioapic_read_entry(apic, pin, 1);
             if ( rte.mask =3D=3D 1 )
                 continue;
=20




--=__Part8DBDCFCA.1__=
Content-Type: text/plain; name="AMD-IOMMU-use-ioapic_read_entry.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-use-ioapic_read_entry.patch"

AMD IOMMU: use __ioapic_read_entry() instead of open coding it=0A=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/=
amd/iommu_intr.c=0A+++ b/xen/drivers/passthrough/amd/iommu_intr.c=0A@@ =
-144,7 +144,7 @@ static void update_intremap_entry_from_i=0A =0A int =
__init amd_iommu_setup_ioapic_remapping(void)=0A {=0A-    struct IO_APIC_ro=
ute_entry rte =3D {0};=0A+    struct IO_APIC_route_entry rte;=0A     =
unsigned long flags;=0A     u32* entry;=0A     int apic, pin;=0A@@ -159,9 =
+159,7 @@ int __init amd_iommu_setup_ioapic_remapp=0A     {=0A         for =
( pin =3D 0; pin < nr_ioapic_entries[apic]; pin++ )=0A         {=0A-       =
     *(((int *)&rte) + 1) =3D io_apic_read(apic, 0x11 + 2 * pin);=0A-      =
      *(((int *)&rte) + 0) =3D io_apic_read(apic, 0x10 + 2 * pin);=0A-=0A+ =
           rte =3D __ioapic_read_entry(apic, pin, 1);=0A             if ( =
rte.mask =3D=3D 1 )=0A                 continue;=0A =0A
--=__Part8DBDCFCA.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

--=__Part8DBDCFCA.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:23:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6O3s-0007eR-4o; Fri, 15 Feb 2013 16:22:56 +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 1U6O3q-0007eD-Bb
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:22:54 +0000
Received: from [193.109.254.147:28124] by server-16.bemta-14.messagelabs.com
	id B9/CC-25906-DD06E115; Fri, 15 Feb 2013 16:22:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1360945372!8417521!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6192 invoked from network); 15 Feb 2013 16:22:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:22:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:22:52 +0000
Message-Id: <511E6EEA02000078000BED56@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:22:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
In-Reply-To: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8DBDCFCA.1__="
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: [Xen-devel] [PATCH 4/4] AMD IOMMU: use __ioapic_read_entry()
 instead of open coding 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

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.

--=__Part8DBDCFCA.1__=
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/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -144,7 +144,7 @@ static void update_intremap_entry_from_i
=20
 int __init amd_iommu_setup_ioapic_remapping(void)
 {
-    struct IO_APIC_route_entry rte =3D {0};
+    struct IO_APIC_route_entry rte;
     unsigned long flags;
     u32* entry;
     int apic, pin;
@@ -159,9 +159,7 @@ int __init amd_iommu_setup_ioapic_remapp
     {
         for ( pin =3D 0; pin < nr_ioapic_entries[apic]; pin++ )
         {
-            *(((int *)&rte) + 1) =3D io_apic_read(apic, 0x11 + 2 * pin);
-            *(((int *)&rte) + 0) =3D io_apic_read(apic, 0x10 + 2 * pin);
-
+            rte =3D __ioapic_read_entry(apic, pin, 1);
             if ( rte.mask =3D=3D 1 )
                 continue;
=20




--=__Part8DBDCFCA.1__=
Content-Type: text/plain; name="AMD-IOMMU-use-ioapic_read_entry.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="AMD-IOMMU-use-ioapic_read_entry.patch"

AMD IOMMU: use __ioapic_read_entry() instead of open coding it=0A=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/=
amd/iommu_intr.c=0A+++ b/xen/drivers/passthrough/amd/iommu_intr.c=0A@@ =
-144,7 +144,7 @@ static void update_intremap_entry_from_i=0A =0A int =
__init amd_iommu_setup_ioapic_remapping(void)=0A {=0A-    struct IO_APIC_ro=
ute_entry rte =3D {0};=0A+    struct IO_APIC_route_entry rte;=0A     =
unsigned long flags;=0A     u32* entry;=0A     int apic, pin;=0A@@ -159,9 =
+159,7 @@ int __init amd_iommu_setup_ioapic_remapp=0A     {=0A         for =
( pin =3D 0; pin < nr_ioapic_entries[apic]; pin++ )=0A         {=0A-       =
     *(((int *)&rte) + 1) =3D io_apic_read(apic, 0x11 + 2 * pin);=0A-      =
      *(((int *)&rte) + 0) =3D io_apic_read(apic, 0x10 + 2 * pin);=0A-=0A+ =
           rte =3D __ioapic_read_entry(apic, pin, 1);=0A             if ( =
rte.mask =3D=3D 1 )=0A                 continue;=0A =0A
--=__Part8DBDCFCA.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

--=__Part8DBDCFCA.1__=--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:27:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6O7n-0007zZ-Sb; Fri, 15 Feb 2013 16:26:59 +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 1U6O7m-0007zR-F4
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 16:26:58 +0000
Received: from [85.158.138.51:16488] by server-7.bemta-3.messagelabs.com id
	50/B6-10367-1D16E115; Fri, 15 Feb 2013 16:26:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360945615!27721028!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23021 invoked from network); 15 Feb 2013 16:26:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 16:26:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FGQrd7014341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 16:26:54 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
	r1FGQrYp010516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 16:26:53 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
	r1FGQrlt023165; Fri, 15 Feb 2013 10:26:53 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 08:26:53 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D19001C387B; Fri, 15 Feb 2013 11:26:51 -0500 (EST)
Date: Fri, 15 Feb 2013 11:26:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Message-ID: <20130215162651.GB13775@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]
Cc: gavin.bowe@oracle.com, kurt.hackel@oracle.com
Subject: [Xen-devel] What went in Linux 3.6, 3.7 and 3.8 from Xen standpoint.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

I realized I hadn't done my usual 'here is what goes in' for about half-a-year.

So catching up and doing it all at once.

v3.6:
 - Fix a lot of bugs: Systems with MP BIOS failing, Systems with ACPI NUMA failing,
   FLR in xen-pciback leaving the devices unusable, 32-bit PCI sounds cards in dom0
   not working, fix crashes when using acpidump, fix crashes with CONFIG_MAX_DOMAIN_PAGES=512
 - Make the P2M interaction on MMIO ranges use less memory during booting
   (aka, Reuse existing P2M leafs).
 - Simplification and cleanups in the code base. Coverity fixes
 - Performance optimizations by caching TLS and GDT descriptors
 - Performance optimizations in PTE page manipulations
 - Xen MCE driver added (to see MCE events that Xen hypervisor gets)
 - Xen PCPU driver added (to online/offline physical CPUs via dom0)

v3.7:
 - Initial support for ARM working under Xen as both guest and initial domain.
 - Security fixes.
 - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
   gntdev driver, fix some pvops calls failing, Fixes in
   xen-[kbd|fb|blk|net|hvc]-backend to deal with CLOSED transition
 - Allow xen/privcmd to use v2 of MMAPBATCH command (and fixes for it)
 - Support Xen backends to work with paged out grants (meaning work with HVM
   guests that have its memory paged out)
 - Performance optimization in xen/privcmd for migrating guests.
 - Performance improvements when doing kdump for PVonHVM guests.
 - Xen DBGP driver added (USB EHCI debug driver)
 - FLR support in xen-pciback.
 - Support wildcards in xen-pciback.hide=(*) argument parsing.
 - Xen EFI support, and keyboard shift status flag.
 - Late usage of Xen-SWIOTLB allowing PV PCI passthrough guest to boot without
   'iommu=soft' as an argument and late initialization of SWIOTLB.
 - Support more than 128GB in a PV guest.
 - Cleanups in the initial pagetable creation.

v3.8:
 - Persistent feature grant in xen-block system allowing greater performance.
 - More fixes in the Xen-pciback for wildcard parsing
 - Xen Processor Aggregator Device (PAD) added.
 - Optimizations for xen/privcmd for ARM and PVH via new hypercall (add_to_physmap_range)
 - Xen ARM can use the balloon driver
 - Fixes for vcpu onlining/offlining, grant table initialization, parsing of cpu
   onlining/offlining values, checks in xen-pciback, locking fixes in gtndev,
   fix stack corruptions, fix xen_iret checks. xen-pciback DoSing dom0 with
   messages, fix mmap batch ioctl error path.
 - Further enh to allow PVHVM backend drivers (so moving dom0 functionality in guests)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:27:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6O7n-0007zZ-Sb; Fri, 15 Feb 2013 16:26:59 +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 1U6O7m-0007zR-F4
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 16:26:58 +0000
Received: from [85.158.138.51:16488] by server-7.bemta-3.messagelabs.com id
	50/B6-10367-1D16E115; Fri, 15 Feb 2013 16:26:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1360945615!27721028!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23021 invoked from network); 15 Feb 2013 16:26:56 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 16:26:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FGQrd7014341
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 16:26:54 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
	r1FGQrYp010516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 16:26:53 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
	r1FGQrlt023165; Fri, 15 Feb 2013 10:26:53 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 08:26:53 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D19001C387B; Fri, 15 Feb 2013 11:26:51 -0500 (EST)
Date: Fri, 15 Feb 2013 11:26:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Message-ID: <20130215162651.GB13775@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]
Cc: gavin.bowe@oracle.com, kurt.hackel@oracle.com
Subject: [Xen-devel] What went in Linux 3.6, 3.7 and 3.8 from Xen standpoint.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

I realized I hadn't done my usual 'here is what goes in' for about half-a-year.

So catching up and doing it all at once.

v3.6:
 - Fix a lot of bugs: Systems with MP BIOS failing, Systems with ACPI NUMA failing,
   FLR in xen-pciback leaving the devices unusable, 32-bit PCI sounds cards in dom0
   not working, fix crashes when using acpidump, fix crashes with CONFIG_MAX_DOMAIN_PAGES=512
 - Make the P2M interaction on MMIO ranges use less memory during booting
   (aka, Reuse existing P2M leafs).
 - Simplification and cleanups in the code base. Coverity fixes
 - Performance optimizations by caching TLS and GDT descriptors
 - Performance optimizations in PTE page manipulations
 - Xen MCE driver added (to see MCE events that Xen hypervisor gets)
 - Xen PCPU driver added (to online/offline physical CPUs via dom0)

v3.7:
 - Initial support for ARM working under Xen as both guest and initial domain.
 - Security fixes.
 - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
   gntdev driver, fix some pvops calls failing, Fixes in
   xen-[kbd|fb|blk|net|hvc]-backend to deal with CLOSED transition
 - Allow xen/privcmd to use v2 of MMAPBATCH command (and fixes for it)
 - Support Xen backends to work with paged out grants (meaning work with HVM
   guests that have its memory paged out)
 - Performance optimization in xen/privcmd for migrating guests.
 - Performance improvements when doing kdump for PVonHVM guests.
 - Xen DBGP driver added (USB EHCI debug driver)
 - FLR support in xen-pciback.
 - Support wildcards in xen-pciback.hide=(*) argument parsing.
 - Xen EFI support, and keyboard shift status flag.
 - Late usage of Xen-SWIOTLB allowing PV PCI passthrough guest to boot without
   'iommu=soft' as an argument and late initialization of SWIOTLB.
 - Support more than 128GB in a PV guest.
 - Cleanups in the initial pagetable creation.

v3.8:
 - Persistent feature grant in xen-block system allowing greater performance.
 - More fixes in the Xen-pciback for wildcard parsing
 - Xen Processor Aggregator Device (PAD) added.
 - Optimizations for xen/privcmd for ARM and PVH via new hypercall (add_to_physmap_range)
 - Xen ARM can use the balloon driver
 - Fixes for vcpu onlining/offlining, grant table initialization, parsing of cpu
   onlining/offlining values, checks in xen-pciback, locking fixes in gtndev,
   fix stack corruptions, fix xen_iret checks. xen-pciback DoSing dom0 with
   messages, fix mmap batch ioctl error path.
 - Further enh to allow PVHVM backend drivers (so moving dom0 functionality in guests)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:32:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:32: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 1U6OCu-0008GT-LW; Fri, 15 Feb 2013 16:32:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U6OCr-0008GN-CL
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:32:14 +0000
Received: from [85.158.138.51:45691] by server-4.bemta-3.messagelabs.com id
	84/46-17521-C036E115; Fri, 15 Feb 2013 16:32:12 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360945931!23707624!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18962 invoked from network); 15 Feb 2013 16:32:11 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Feb 2013 16:32:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID;
	bh=3crEGG4AsD0jpe/XRjjhxLu6AEvW13SU8XjdFiLQ3gM=; 
	b=F8S9me7iXFJdE7mAIgRlzk712aRXrypUlFTO5Mrj1ZHVZ5bTwU+x1E8QHMc0kBPgdvtkKa3nzXbzbioQv+k84o3A0IJw+ZiSMZkj1E8sELs2p3cXVYOZcwiKJLW/TUWHRFd61xxsJ4WwJAchjhXmnG+U/oxPifK8JN7ikkXuKJ0=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U6OCl-00010R-S9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:32:07 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id ROc1Nv9Fg2XK for <xen-devel@lists.xen.org>;
	Fri, 15 Feb 2013 17:32:02 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U6OCg-0000z2-IH
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:32:02 +0100
Message-ID: <511E62FB.90804@crysys.hu>
Date: Fri, 15 Feb 2013 17:31:55 +0100
From: =?ISO-8859-1?Q?G=E1bor_P=C9K?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Subject: [Xen-devel] direct PIO/MMIO 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

Hi all,

I would like to access the configuration registers of my passthrough
device from my HVM guest under Xen 4.2 via MMIO/PIO directly. Is there
any option for this in the config file of the guest? I know about the
ioports=[''] option for PIO accesses, but is there any way to do the
same with MMIO BAR registers? As far as I know the permissive flag works
only for PV guests. Does the ioports option allow direct access to
config space (0xcf8-0xcfc)? According to in xen/arch/x86/trap.c it is
not allowed.

    /*
     * Port 0xcf8 (CONFIG_ADDRESS) is only visible for DWORD accesses.
     * We never permit direct access to that register.
     */

What about Dom0?

Thank you!
-gabor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:32:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:32: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 1U6OCu-0008GT-LW; Fri, 15 Feb 2013 16:32:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U6OCr-0008GN-CL
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:32:14 +0000
Received: from [85.158.138.51:45691] by server-4.bemta-3.messagelabs.com id
	84/46-17521-C036E115; Fri, 15 Feb 2013 16:32:12 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360945931!23707624!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18962 invoked from network); 15 Feb 2013 16:32:11 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Feb 2013 16:32:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID;
	bh=3crEGG4AsD0jpe/XRjjhxLu6AEvW13SU8XjdFiLQ3gM=; 
	b=F8S9me7iXFJdE7mAIgRlzk712aRXrypUlFTO5Mrj1ZHVZ5bTwU+x1E8QHMc0kBPgdvtkKa3nzXbzbioQv+k84o3A0IJw+ZiSMZkj1E8sELs2p3cXVYOZcwiKJLW/TUWHRFd61xxsJ4WwJAchjhXmnG+U/oxPifK8JN7ikkXuKJ0=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U6OCl-00010R-S9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:32:07 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id ROc1Nv9Fg2XK for <xen-devel@lists.xen.org>;
	Fri, 15 Feb 2013 17:32:02 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U6OCg-0000z2-IH
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:32:02 +0100
Message-ID: <511E62FB.90804@crysys.hu>
Date: Fri, 15 Feb 2013 17:31:55 +0100
From: =?ISO-8859-1?Q?G=E1bor_P=C9K?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Subject: [Xen-devel] direct PIO/MMIO 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

Hi all,

I would like to access the configuration registers of my passthrough
device from my HVM guest under Xen 4.2 via MMIO/PIO directly. Is there
any option for this in the config file of the guest? I know about the
ioports=[''] option for PIO accesses, but is there any way to do the
same with MMIO BAR registers? As far as I know the permissive flag works
only for PV guests. Does the ioports option allow direct access to
config space (0xcf8-0xcfc)? According to in xen/arch/x86/trap.c it is
not allowed.

    /*
     * Port 0xcf8 (CONFIG_ADDRESS) is only visible for DWORD accesses.
     * We never permit direct access to that register.
     */

What about Dom0?

Thank you!
-gabor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:33:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6OE1-0008KN-4F; Fri, 15 Feb 2013 16:33:25 +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 1U6ODz-0008KC-FG
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:33:23 +0000
Received: from [85.158.143.35:48072] by server-1.bemta-4.messagelabs.com id
	4F/33-08839-2536E115; Fri, 15 Feb 2013 16:33:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360946000!13259776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12457 invoked from network); 15 Feb 2013 16:33:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:33:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7706452"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:33:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:33:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6ODv-00064u-91;
	Fri, 15 Feb 2013 16:33:19 +0000
Message-ID: <1360945999.16636.169.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 16:33:19 +0000
In-Reply-To: <511E6D9702000078000BED23@nat28.tlf.novell.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
	<511E6D9702000078000BED23@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>, Roger Pau
	Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 16:17 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
> > Also bundle fixes for xen frontends and backends in this patch.
> 
> Could you at least enumerate those fixes in the patch description?
> 
> Jan
> 

Mostly mechanical fixes to adapt to new xenbus client interface, which
includes: xen-pciback, xen-pcifront, xen-blkback, xen-blkfront,
xen-netback, xen-netfront.

The above description will be added to patch description.

Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:33:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6OE1-0008KN-4F; Fri, 15 Feb 2013 16:33:25 +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 1U6ODz-0008KC-FG
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:33:23 +0000
Received: from [85.158.143.35:48072] by server-1.bemta-4.messagelabs.com id
	4F/33-08839-2536E115; Fri, 15 Feb 2013 16:33:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360946000!13259776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12457 invoked from network); 15 Feb 2013 16:33:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 16:33:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7706452"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 16:33:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 11:33:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6ODv-00064u-91;
	Fri, 15 Feb 2013 16:33:19 +0000
Message-ID: <1360945999.16636.169.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 16:33:19 +0000
In-Reply-To: <511E6D9702000078000BED23@nat28.tlf.novell.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
	<511E6D9702000078000BED23@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>, Roger Pau
	Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 16:17 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
> > Also bundle fixes for xen frontends and backends in this patch.
> 
> Could you at least enumerate those fixes in the patch description?
> 
> Jan
> 

Mostly mechanical fixes to adapt to new xenbus client interface, which
includes: xen-pciback, xen-pcifront, xen-blkback, xen-blkfront,
xen-netback, xen-netfront.

The above description will be added to patch description.

Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:40:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6OKj-00007u-96; Fri, 15 Feb 2013 16:40:21 +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 1U6OKh-00007p-Cc
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:40:19 +0000
Received: from [85.158.143.35:38015] by server-3.bemta-4.messagelabs.com id
	EA/C8-08920-2F46E115; Fri, 15 Feb 2013 16:40:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360946415!12378617!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1015 invoked from network); 15 Feb 2013 16:40:17 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 16:40:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FGeDRe022069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 16:40:13 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
	r1FGeCAT005347
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 16:40:12 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
	r1FGeBoT001530; Fri, 15 Feb 2013 10:40:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 08:40:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA4141C387B; Fri, 15 Feb 2013 11:40:10 -0500 (EST)
Date: Fri, 15 Feb 2013 11:40:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130215164010.GE13775@phenom.dumpdata.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E59C902000078000BEC18@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 02:52:41PM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> >> Since when is E820_UNUSABLE memory being used as guest
> >> >> memory? If that's indeed the case, that's the bug to fix. The
> >> >> above data to me shows, however, that the range above
> >> >> 228000000 is considered invalid. So then the question is why the
> >> >> kernel tries to map that memory in the first place (the hypervisor
> >> >> rejecting the attempt, despite Dom0 being privileged, seems
> >> >> correct to me, as the range is also known not to be MMIO).
> > 
> > B/c it gets the E820 from the hypervisor, which shows that area as
> > E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
> > creating pagetables for it.
> 
> That would be wrong even on native, and I don't see how that
> would happen: memblock_add() gets called from
> memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
> ranges.

Hm, the bug report shows that the ranges (which are E820_UNUSABLE)
do get called with init_memory_mapping.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:40:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6OKj-00007u-96; Fri, 15 Feb 2013 16:40:21 +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 1U6OKh-00007p-Cc
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:40:19 +0000
Received: from [85.158.143.35:38015] by server-3.bemta-4.messagelabs.com id
	EA/C8-08920-2F46E115; Fri, 15 Feb 2013 16:40:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360946415!12378617!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1015 invoked from network); 15 Feb 2013 16:40:17 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 16:40:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FGeDRe022069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 16:40:13 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
	r1FGeCAT005347
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 16:40:12 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
	r1FGeBoT001530; Fri, 15 Feb 2013 10:40:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 08:40:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA4141C387B; Fri, 15 Feb 2013 11:40:10 -0500 (EST)
Date: Fri, 15 Feb 2013 11:40:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130215164010.GE13775@phenom.dumpdata.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E59C902000078000BEC18@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 02:52:41PM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> >> Since when is E820_UNUSABLE memory being used as guest
> >> >> memory? If that's indeed the case, that's the bug to fix. The
> >> >> above data to me shows, however, that the range above
> >> >> 228000000 is considered invalid. So then the question is why the
> >> >> kernel tries to map that memory in the first place (the hypervisor
> >> >> rejecting the attempt, despite Dom0 being privileged, seems
> >> >> correct to me, as the range is also known not to be MMIO).
> > 
> > B/c it gets the E820 from the hypervisor, which shows that area as
> > E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
> > creating pagetables for it.
> 
> That would be wrong even on native, and I don't see how that
> would happen: memblock_add() gets called from
> memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
> ranges.

Hm, the bug report shows that the ranges (which are E820_UNUSABLE)
do get called with init_memory_mapping.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:45:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:45: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 1U6OPH-0000L6-0E; Fri, 15 Feb 2013 16:45:03 +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 1U6OPF-0000Ky-Bz
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 16:45:01 +0000
Received: from [85.158.143.99:24275] by server-3.bemta-4.messagelabs.com id
	C2/BD-08920-C066E115; Fri, 15 Feb 2013 16:45:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360946099!27125013!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26686 invoked from network); 15 Feb 2013 16:35:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 16:35:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FGYsdW015115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 16:34:55 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
	r1FGYrX7025071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 16:34:54 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
	r1FGYqOs026678; Fri, 15 Feb 2013 10:34:52 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 08:34:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B433E1C387B; Fri, 15 Feb 2013 11:34:51 -0500 (EST)
Date: Fri, 15 Feb 2013 11:34:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Message-ID: <20130215163451.GD13775@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]
Cc: jinsong.liu@intel.com, roger.pau@citrix.com
Subject: [Xen-devel] Patches for v3.9 for the Linux 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

The v3.8 is going to be released soon. The patches that I have in
my tree that I was thinking to push for v3.9 are:

If I am missing anything pls tell me.


Alexander Duyck (1):
      x86/xen: Use __pa_symbol instead of __pa on C visible symbols

Dan Carpenter (1):
      xen/privcmd: fix condition in privcmd_close()

Ian Campbell (2):
      xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
      xen: implement updated XENMEM_add_to_physmap_range ABI

Konrad Rzeszutek Wilk (5):
      xen/smp: Move the common CPU init code a bit to prep for PVH patch.
      Merge branch 'stable/pvh.v7' into stable/for-linus-3.9
      Revert "xen/pvh linux: Use ballooning to allocate grant table pages"
      Merge branch 'stable/pvh.v7' into stable/for-linus-3.9
      Merge branch 'stable/for-linus-3.9' into HEAD

Liu Jinsong (6):
      xen/stub: driver for memory hotplug
      xen/acpi: ACPI memory hotplug
      xen/stub: driver for CPU hotplug
      xen/acpi: Move xen_acpi_get_pxm to Xen's acpi.h
      xen/acpi: ACPI cpu hotplug
      xen/acpi: move xen_acpi_get_pxm under CONFIG_XEN_DOM0

Mukesh Rathor (9):
      xen/pvh: Support ParaVirtualized Hardware extensions.
      xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
      xen/pvh: Implement MMU changes for PVH.
      xen/pvh: bootup and setup (E820) related changes.
      xen/pvh: balloon and grant changes.
      xen/pvh: specify xen features strings cleanly for PVH
      xen/pvh: remove code to map iomem from guest
      xen/pvh linux: Use ballooning to allocate grant table pages
      xen/pvh: Use ballooning to allocate grant table pages [v2]

Wei Yongjun (1):
      xen/x86: remove duplicated include from enlighten.c


I know that the PVH patches are not in the Xen tree. I am hoping that
at least the hypercalls _are_ OK with everybody so we can continue on
with this.

There are some patches in the for-jens-3.8 tree that will be
part of the v3.9:

Jan Beulich (1):
      xen-blkback: do not leak mode property

Konrad Rzeszutek Wilk (3):
      xen/blkback: Don't trust the handle from the frontend.
      xen-blkfront: drop the use of llist_for_each_entry_safe
      Merge branch 'stable/for-jens-3.8' into HEAD

Roger Pau Monne (1):
      xen-blkback: use balloon pages for persistent grants


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:45:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:45: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 1U6OPH-0000L6-0E; Fri, 15 Feb 2013 16:45:03 +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 1U6OPF-0000Ky-Bz
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 16:45:01 +0000
Received: from [85.158.143.99:24275] by server-3.bemta-4.messagelabs.com id
	C2/BD-08920-C066E115; Fri, 15 Feb 2013 16:45:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360946099!27125013!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26686 invoked from network); 15 Feb 2013 16:35:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 16:35:00 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FGYsdW015115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 16:34:55 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
	r1FGYrX7025071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 16:34:54 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
	r1FGYqOs026678; Fri, 15 Feb 2013 10:34:52 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 08:34:52 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B433E1C387B; Fri, 15 Feb 2013 11:34:51 -0500 (EST)
Date: Fri, 15 Feb 2013 11:34:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Message-ID: <20130215163451.GD13775@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]
Cc: jinsong.liu@intel.com, roger.pau@citrix.com
Subject: [Xen-devel] Patches for v3.9 for the Linux 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

The v3.8 is going to be released soon. The patches that I have in
my tree that I was thinking to push for v3.9 are:

If I am missing anything pls tell me.


Alexander Duyck (1):
      x86/xen: Use __pa_symbol instead of __pa on C visible symbols

Dan Carpenter (1):
      xen/privcmd: fix condition in privcmd_close()

Ian Campbell (2):
      xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
      xen: implement updated XENMEM_add_to_physmap_range ABI

Konrad Rzeszutek Wilk (5):
      xen/smp: Move the common CPU init code a bit to prep for PVH patch.
      Merge branch 'stable/pvh.v7' into stable/for-linus-3.9
      Revert "xen/pvh linux: Use ballooning to allocate grant table pages"
      Merge branch 'stable/pvh.v7' into stable/for-linus-3.9
      Merge branch 'stable/for-linus-3.9' into HEAD

Liu Jinsong (6):
      xen/stub: driver for memory hotplug
      xen/acpi: ACPI memory hotplug
      xen/stub: driver for CPU hotplug
      xen/acpi: Move xen_acpi_get_pxm to Xen's acpi.h
      xen/acpi: ACPI cpu hotplug
      xen/acpi: move xen_acpi_get_pxm under CONFIG_XEN_DOM0

Mukesh Rathor (9):
      xen/pvh: Support ParaVirtualized Hardware extensions.
      xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
      xen/pvh: Implement MMU changes for PVH.
      xen/pvh: bootup and setup (E820) related changes.
      xen/pvh: balloon and grant changes.
      xen/pvh: specify xen features strings cleanly for PVH
      xen/pvh: remove code to map iomem from guest
      xen/pvh linux: Use ballooning to allocate grant table pages
      xen/pvh: Use ballooning to allocate grant table pages [v2]

Wei Yongjun (1):
      xen/x86: remove duplicated include from enlighten.c


I know that the PVH patches are not in the Xen tree. I am hoping that
at least the hypercalls _are_ OK with everybody so we can continue on
with this.

There are some patches in the for-jens-3.8 tree that will be
part of the v3.9:

Jan Beulich (1):
      xen-blkback: do not leak mode property

Konrad Rzeszutek Wilk (3):
      xen/blkback: Don't trust the handle from the frontend.
      xen-blkfront: drop the use of llist_for_each_entry_safe
      Merge branch 'stable/for-jens-3.8' into HEAD

Roger Pau Monne (1):
      xen-blkback: use balloon pages for persistent grants


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:45:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:45: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 1U6OPY-0000N7-IC; Fri, 15 Feb 2013 16:45:20 +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 1U6OPX-0000Ms-91
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:45:19 +0000
Received: from [85.158.139.83:48017] by server-8.bemta-5.messagelabs.com id
	D7/D0-19075-E166E115; Fri, 15 Feb 2013 16:45:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360946717!16214213!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25761 invoked from network); 15 Feb 2013 16:45:17 -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; 15 Feb 2013 16:45:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:45:16 +0000
Message-Id: <511E742A02000078000BEDAE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:45:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kouya Shimura" <kouya@jp.fujitsu.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
	<511A42E902000078000BDB5E@nat28.tlf.novell.com>
	<511C7FB7.90907@jp.fujitsu.com>
In-Reply-To: <511C7FB7.90907@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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 14.02.13 at 07:09, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>@@ -244,21 +245,13 @@ static int handle_pmt_io(
> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
> {
>     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>     int rc;
> 
>     spin_lock(&s->lock);
> 
>-    /* Update the counter to the guest's current time.  We always save
>-     * with the domain paused, so the saved time should be after the
>-     * last_gtime, but just in case, make sure we only go forwards */

So you lose this property of guaranteeing no backward move.

>-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>-    if ( x < 1UL<<31 )
>-        s->pm.tmr_val += x;
>-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>-        s->pm.pm1a_sts |= TMR_STS;
>     /* No point in setting the SCI here because we'll already have saved the 
>      * IRQ and *PIC state; we'll fix it up when we restore the domain */
>+    pmt_update_time(s, 0);

And using this function you also have the new side effect of
s->last_gtime being updated.

Perhaps the new parameter should be renamed (to, say,
"saving"), and then allow suppressing all these behavioral
changes.

Also, in delay_for_missed_ticks mode you now use a slightly
different time for updating s->pm - did you double check that
this is not going to be a problem? Or else, the flag above could
similarly be used to circumvent this, or hvm_get_guest_time()
could be made return the frozen time (I suppose, but didn't
verify - as it appears to be an assumption already before your
patch -, that pt_freeze_time() runs before pmtimer_save()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:45:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:45: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 1U6OPY-0000N7-IC; Fri, 15 Feb 2013 16:45:20 +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 1U6OPX-0000Ms-91
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:45:19 +0000
Received: from [85.158.139.83:48017] by server-8.bemta-5.messagelabs.com id
	D7/D0-19075-E166E115; Fri, 15 Feb 2013 16:45:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1360946717!16214213!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25761 invoked from network); 15 Feb 2013 16:45:17 -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; 15 Feb 2013 16:45:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:45:16 +0000
Message-Id: <511E742A02000078000BEDAE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:45:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Kouya Shimura" <kouya@jp.fujitsu.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
	<511A42E902000078000BDB5E@nat28.tlf.novell.com>
	<511C7FB7.90907@jp.fujitsu.com>
In-Reply-To: <511C7FB7.90907@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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 14.02.13 at 07:09, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>@@ -244,21 +245,13 @@ static int handle_pmt_io(
> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
> {
>     PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>-    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>     int rc;
> 
>     spin_lock(&s->lock);
> 
>-    /* Update the counter to the guest's current time.  We always save
>-     * with the domain paused, so the saved time should be after the
>-     * last_gtime, but just in case, make sure we only go forwards */

So you lose this property of guaranteeing no backward move.

>-    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>-    if ( x < 1UL<<31 )
>-        s->pm.tmr_val += x;
>-    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>-        s->pm.pm1a_sts |= TMR_STS;
>     /* No point in setting the SCI here because we'll already have saved the 
>      * IRQ and *PIC state; we'll fix it up when we restore the domain */
>+    pmt_update_time(s, 0);

And using this function you also have the new side effect of
s->last_gtime being updated.

Perhaps the new parameter should be renamed (to, say,
"saving"), and then allow suppressing all these behavioral
changes.

Also, in delay_for_missed_ticks mode you now use a slightly
different time for updating s->pm - did you double check that
this is not going to be a problem? Or else, the flag above could
similarly be used to circumvent this, or hvm_get_guest_time()
could be made return the frozen time (I suppose, but didn't
verify - as it appears to be an assumption already before your
patch -, that pt_freeze_time() runs before pmtimer_save()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:45:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6OPn-0000PI-W5; Fri, 15 Feb 2013 16:45:35 +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 1U6OPm-0000Ok-LA
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:45:34 +0000
Received: from [85.158.137.99:58093] by server-1.bemta-3.messagelabs.com id
	BF/F5-08955-D266E115; Fri, 15 Feb 2013 16:45:33 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360946705!19334387!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17968 invoked from network); 15 Feb 2013 16:45:05 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-217.messagelabs.com with SMTP;
	15 Feb 2013 16:45:05 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] 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 1U6OPH-0002uA-VZ; Fri, 15 Feb 2013 16:45:04 +0000
Message-ID: <511E660E.7000107@canonical.com>
Date: Fri, 15 Feb 2013 17:45:02 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
	<20130215164010.GE13775@phenom.dumpdata.com>
In-Reply-To: <20130215164010.GE13775@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.6
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0733904675662248270=="
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)
--===============0733904675662248270==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigDCA60700F5CE5FB7743BCB99"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDCA60700F5CE5FB7743BCB99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15.02.2013 17:40, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 15, 2013 at 02:52:41PM +0000, Jan Beulich wrote:
>>>>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com=
> wrote:
>>>>>> Since when is E820_UNUSABLE memory being used as guest
>>>>>> memory? If that's indeed the case, that's the bug to fix. The
>>>>>> above data to me shows, however, that the range above
>>>>>> 228000000 is considered invalid. So then the question is why the
>>>>>> kernel tries to map that memory in the first place (the hypervisor=

>>>>>> rejecting the attempt, despite Dom0 being privileged, seems
>>>>>> correct to me, as the range is also known not to be MMIO).
>>>
>>> B/c it gets the E820 from the hypervisor, which shows that area as
>>> E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
>>> creating pagetables for it.
>>
>> That would be wrong even on native, and I don't see how that
>> would happen: memblock_add() gets called from
>> memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
>> ranges.
>=20
> Hm, the bug report shows that the ranges (which are E820_UNUSABLE)
> do get called with init_memory_mapping.
>=20
Not sure it makes the difference but keep in mind that the report is abou=
t a 3.2
kernel. They initially claimed that 3.5 works, but then some comments see=
m to
say that was when using dom0_mem=3D which would in that case work around =
the bug.
Maybe time to go back and ask whether a recent kernel without dom0_mem on=
 the
same machine still crashes...



--------------enigDCA60700F5CE5FB7743BCB99
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHmYOAAoJEOhnXe7L7s6j8m8P/0VwnsL5XKGc6JFZtLw5EsyJ
woWvstEUGzp15oMVtJB5wn8puyN6iC91GZaVnVA2XrkQ7wUluk1r/dyXWjkXjr2N
rG6tWteKGCyidCbmS6DEr6Z1GzKmBUaA7kPjBlD2PH4BEatZrOmyK8HZ2m/+f08/
4k+r3GnmlfEd1L/c6hpaq0S5CH77Ijk9gnAB/oSm5GXMX/7Pcwl/6Z4ChLSZYenQ
sFwgQXv1AludSC7NqToSSlgF2OWJMLq2OI5fcsvTYMRB0IL7blo9dVJ0cSP4YIFO
0lHiz+q+lLcOQPRXJwg5Q+Z8jd8052dFBhcYP98PhH6oIwjUhcAqf+hYmsqDbBnR
qr7zVrJ7o/d2kAj5UjtZgcmdeCmG6TutYtGpE03FWpPPxfuuSln0V9PA88VXGYwI
hxTO8/gi9fpMZ2YxiFvwmAt+s780Qbc5D7nrPVsb2GfquD2VWVHoGfmEArrnmYOW
+QuugLGhxNAiIBXmYDndZ7Gt8cjYajZTtMvKusCOQe0Dq/7V5E4TYBRHVPLk8m4w
qc71/OONsCX56USkfITld9uMzKsZqjd+t3mnDGi2sYOt+TCOMxX+MLR95zJPKXgX
lTSq6T1qklfabtm3+sxzSo1n9ccbqhnYkRA28jhBr8horv0FGZgFI+WH9it+NTj/
79Q/e23YlMyQxS9P9PTw
=7od/
-----END PGP SIGNATURE-----

--------------enigDCA60700F5CE5FB7743BCB99--


--===============0733904675662248270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0733904675662248270==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:45:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16: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 1U6OPn-0000PI-W5; Fri, 15 Feb 2013 16:45:35 +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 1U6OPm-0000Ok-LA
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:45:34 +0000
Received: from [85.158.137.99:58093] by server-1.bemta-3.messagelabs.com id
	BF/F5-08955-D266E115; Fri, 15 Feb 2013 16:45:33 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1360946705!19334387!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17968 invoked from network); 15 Feb 2013 16:45:05 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-217.messagelabs.com with SMTP;
	15 Feb 2013 16:45:05 -0000
Received: from p5b2e2035.dip.t-dialin.net ([91.46.32.53] 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 1U6OPH-0002uA-VZ; Fri, 15 Feb 2013 16:45:04 +0000
Message-ID: <511E660E.7000107@canonical.com>
Date: Fri, 15 Feb 2013 17:45:02 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
	<20130215164010.GE13775@phenom.dumpdata.com>
In-Reply-To: <20130215164010.GE13775@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.6
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0733904675662248270=="
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)
--===============0733904675662248270==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigDCA60700F5CE5FB7743BCB99"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDCA60700F5CE5FB7743BCB99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15.02.2013 17:40, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 15, 2013 at 02:52:41PM +0000, Jan Beulich wrote:
>>>>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com=
> wrote:
>>>>>> Since when is E820_UNUSABLE memory being used as guest
>>>>>> memory? If that's indeed the case, that's the bug to fix. The
>>>>>> above data to me shows, however, that the range above
>>>>>> 228000000 is considered invalid. So then the question is why the
>>>>>> kernel tries to map that memory in the first place (the hypervisor=

>>>>>> rejecting the attempt, despite Dom0 being privileged, seems
>>>>>> correct to me, as the range is also known not to be MMIO).
>>>
>>> B/c it gets the E820 from the hypervisor, which shows that area as
>>> E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
>>> creating pagetables for it.
>>
>> That would be wrong even on native, and I don't see how that
>> would happen: memblock_add() gets called from
>> memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
>> ranges.
>=20
> Hm, the bug report shows that the ranges (which are E820_UNUSABLE)
> do get called with init_memory_mapping.
>=20
Not sure it makes the difference but keep in mind that the report is abou=
t a 3.2
kernel. They initially claimed that 3.5 works, but then some comments see=
m to
say that was when using dom0_mem=3D which would in that case work around =
the bug.
Maybe time to go back and ask whether a recent kernel without dom0_mem on=
 the
same machine still crashes...



--------------enigDCA60700F5CE5FB7743BCB99
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRHmYOAAoJEOhnXe7L7s6j8m8P/0VwnsL5XKGc6JFZtLw5EsyJ
woWvstEUGzp15oMVtJB5wn8puyN6iC91GZaVnVA2XrkQ7wUluk1r/dyXWjkXjr2N
rG6tWteKGCyidCbmS6DEr6Z1GzKmBUaA7kPjBlD2PH4BEatZrOmyK8HZ2m/+f08/
4k+r3GnmlfEd1L/c6hpaq0S5CH77Ijk9gnAB/oSm5GXMX/7Pcwl/6Z4ChLSZYenQ
sFwgQXv1AludSC7NqToSSlgF2OWJMLq2OI5fcsvTYMRB0IL7blo9dVJ0cSP4YIFO
0lHiz+q+lLcOQPRXJwg5Q+Z8jd8052dFBhcYP98PhH6oIwjUhcAqf+hYmsqDbBnR
qr7zVrJ7o/d2kAj5UjtZgcmdeCmG6TutYtGpE03FWpPPxfuuSln0V9PA88VXGYwI
hxTO8/gi9fpMZ2YxiFvwmAt+s780Qbc5D7nrPVsb2GfquD2VWVHoGfmEArrnmYOW
+QuugLGhxNAiIBXmYDndZ7Gt8cjYajZTtMvKusCOQe0Dq/7V5E4TYBRHVPLk8m4w
qc71/OONsCX56USkfITld9uMzKsZqjd+t3mnDGi2sYOt+TCOMxX+MLR95zJPKXgX
lTSq6T1qklfabtm3+sxzSo1n9ccbqhnYkRA28jhBr8horv0FGZgFI+WH9it+NTj/
79Q/e23YlMyQxS9P9PTw
=7od/
-----END PGP SIGNATURE-----

--------------enigDCA60700F5CE5FB7743BCB99--


--===============0733904675662248270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0733904675662248270==--


From xen-devel-bounces@lists.xen.org Fri Feb 15 16:48:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:48: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 1U6OS2-0000gV-IV; Fri, 15 Feb 2013 16:47: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 1U6OS0-0000gE-IC
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:47:52 +0000
Received: from [85.158.139.83:61211] by server-16.bemta-5.messagelabs.com id
	82/50-14948-7B66E115; Fri, 15 Feb 2013 16:47:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360946870!23608666!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24912 invoked from network); 15 Feb 2013 16:47:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:47:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:47:50 +0000
Message-Id: <511E74C302000078000BEDB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:47:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130215162651.GB13775@phenom.dumpdata.com>
In-Reply-To: <20130215162651.GB13775@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: gavin.bowe@oracle.com, kurt.hackel@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] What went in Linux 3.6,
 3.7 and 3.8 from Xen standpoint.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 17:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> v3.7:
>  - Initial support for ARM working under Xen as both guest and initial 
> domain.
>  - Security fixes.
>  - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
>    gntdev driver, fix some pvops calls failing, Fixes in
>    xen-[kbd|fb|blk|net|hvc]-backend to deal with CLOSED transition
>  - Allow xen/privcmd to use v2 of MMAPBATCH command (and fixes for it)
>  - Support Xen backends to work with paged out grants (meaning work with HVM
>    guests that have its memory paged out)
>  - Performance optimization in xen/privcmd for migrating guests.
>  - Performance improvements when doing kdump for PVonHVM guests.
>  - Xen DBGP driver added (USB EHCI debug driver)
>  - FLR support in xen-pciback.
>  - Support wildcards in xen-pciback.hide=(*) argument parsing.
>  - Xen EFI support,

Where?

> and keyboard shift status flag.
>  - Late usage of Xen-SWIOTLB allowing PV PCI passthrough guest to boot without
>    'iommu=soft' as an argument and late initialization of SWIOTLB.
>  - Support more than 128GB in a PV guest.
>  - Cleanups in the initial pagetable creation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:48:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:48: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 1U6OS2-0000gV-IV; Fri, 15 Feb 2013 16:47: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 1U6OS0-0000gE-IC
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:47:52 +0000
Received: from [85.158.139.83:61211] by server-16.bemta-5.messagelabs.com id
	82/50-14948-7B66E115; Fri, 15 Feb 2013 16:47:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1360946870!23608666!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24912 invoked from network); 15 Feb 2013 16:47:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:47:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:47:50 +0000
Message-Id: <511E74C302000078000BEDB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:47:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130215162651.GB13775@phenom.dumpdata.com>
In-Reply-To: <20130215162651.GB13775@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: gavin.bowe@oracle.com, kurt.hackel@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] What went in Linux 3.6,
 3.7 and 3.8 from Xen standpoint.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 17:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> v3.7:
>  - Initial support for ARM working under Xen as both guest and initial 
> domain.
>  - Security fixes.
>  - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
>    gntdev driver, fix some pvops calls failing, Fixes in
>    xen-[kbd|fb|blk|net|hvc]-backend to deal with CLOSED transition
>  - Allow xen/privcmd to use v2 of MMAPBATCH command (and fixes for it)
>  - Support Xen backends to work with paged out grants (meaning work with HVM
>    guests that have its memory paged out)
>  - Performance optimization in xen/privcmd for migrating guests.
>  - Performance improvements when doing kdump for PVonHVM guests.
>  - Xen DBGP driver added (USB EHCI debug driver)
>  - FLR support in xen-pciback.
>  - Support wildcards in xen-pciback.hide=(*) argument parsing.
>  - Xen EFI support,

Where?

> and keyboard shift status flag.
>  - Late usage of Xen-SWIOTLB allowing PV PCI passthrough guest to boot without
>    'iommu=soft' as an argument and late initialization of SWIOTLB.
>  - Support more than 128GB in a PV guest.
>  - Cleanups in the initial pagetable creation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:51:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:51: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 1U6OVL-00010k-6W; Fri, 15 Feb 2013 16:51:19 +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 1U6OVJ-00010d-RI
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:51:17 +0000
Received: from [85.158.139.83:19665] by server-8.bemta-5.messagelabs.com id
	55/E8-19075-4876E115; Fri, 15 Feb 2013 16:51:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360947076!24764150!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15588 invoked from network); 15 Feb 2013 16:51:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:51:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:51:15 +0000
Message-Id: <511E759002000078000BEDD5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:51:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?R8OhYm9yIFDDiUs=?=" <pek@crysys.hu>
References: <511E62FB.90804@crysys.hu>
In-Reply-To: <511E62FB.90804@crysys.hu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] direct PIO/MMIO 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE1LjAyLjEzIGF0IDE3OjMxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90
ZToKPiBJIHdvdWxkIGxpa2UgdG8gYWNjZXNzIHRoZSBjb25maWd1cmF0aW9uIHJlZ2lzdGVycyBv
ZiBteSBwYXNzdGhyb3VnaAo+IGRldmljZSBmcm9tIG15IEhWTSBndWVzdCB1bmRlciBYZW4gNC4y
IHZpYSBNTUlPL1BJTyBkaXJlY3RseS4gSXMgdGhlcmUKPiBhbnkgb3B0aW9uIGZvciB0aGlzIGlu
IHRoZSBjb25maWcgZmlsZSBvZiB0aGUgZ3Vlc3Q/IEkga25vdyBhYm91dCB0aGUKPiBpb3BvcnRz
PVsnJ10gb3B0aW9uIGZvciBQSU8gYWNjZXNzZXMsIGJ1dCBpcyB0aGVyZSBhbnkgd2F5IHRvIGRv
IHRoZQo+IHNhbWUgd2l0aCBNTUlPIEJBUiByZWdpc3RlcnM/CgpGb3IgYSBQQ0kgZGV2aWNlLCBu
byBleHRyYSBvcHRpb24gc2hvdWxkIGJlIG5lZWRlZCBmb3IgZWl0aGVyCklPIHBvcnRzIG9yIE1N
SU8gcmVnaW9ucy4KCj4gQXMgZmFyIGFzIEkga25vdyB0aGUgcGVybWlzc2l2ZSBmbGFnIHdvcmtz
Cj4gb25seSBmb3IgUFYgZ3Vlc3RzLiBEb2VzIHRoZSBpb3BvcnRzIG9wdGlvbiBhbGxvdyBkaXJl
Y3QgYWNjZXNzIHRvCj4gY29uZmlnIHNwYWNlICgweGNmOC0weGNmYyk/IEFjY29yZGluZyB0byBp
biB4ZW4vYXJjaC94ODYvdHJhcC5jIGl0IGlzCj4gbm90IGFsbG93ZWQuCgpDb3JyZWN0LCBhbGJl
aXQgdGhhdCBjb2RlIGRvZXNuJ3QgY29udHJvbCBIVk0gZ3Vlc3RzLiBCdXQgaWYgeW91CmdhdmUg
SFZNIGd1ZXN0cyBhY2Nlc3MgdG8gdGhlc2UgX3BoeXNpY2FsXyBwb3J0cywgdGhleSBjb3VsZAph
dCBvbmNlIGNvbnRyb2wgYWxsIG90aGVyIFBDSSBkZXZpY2VzLiBTbyBJJ20gc3VyZSB5b3UgZG9u
J3Qgd2FudAp0byBkbyB0aGF0LgoKPiAgICAgLyoKPiAgICAgICogUG9ydCAweGNmOCAoQ09ORklH
X0FERFJFU1MpIGlzIG9ubHkgdmlzaWJsZSBmb3IgRFdPUkQgYWNjZXNzZXMuCj4gICAgICAqIFdl
IG5ldmVyIHBlcm1pdCBkaXJlY3QgYWNjZXNzIHRvIHRoYXQgcmVnaXN0ZXIuCj4gICAgICAqLwo+
IAo+IFdoYXQgYWJvdXQgRG9tMD8KCk5vdCBldmVuIERvbTAuIFRoaXMgZ2V0cyBlbXVsYXRlZCBp
biBYZW4uCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:51:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:51: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 1U6OVL-00010k-6W; Fri, 15 Feb 2013 16:51:19 +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 1U6OVJ-00010d-RI
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:51:17 +0000
Received: from [85.158.139.83:19665] by server-8.bemta-5.messagelabs.com id
	55/E8-19075-4876E115; Fri, 15 Feb 2013 16:51:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1360947076!24764150!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15588 invoked from network); 15 Feb 2013 16:51:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:51:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:51:15 +0000
Message-Id: <511E759002000078000BEDD5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:51:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?R8OhYm9yIFDDiUs=?=" <pek@crysys.hu>
References: <511E62FB.90804@crysys.hu>
In-Reply-To: <511E62FB.90804@crysys.hu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] direct PIO/MMIO 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE1LjAyLjEzIGF0IDE3OjMxLCBHw6Fib3IgUMOJSzxwZWtAY3J5c3lzLmh1PiB3cm90
ZToKPiBJIHdvdWxkIGxpa2UgdG8gYWNjZXNzIHRoZSBjb25maWd1cmF0aW9uIHJlZ2lzdGVycyBv
ZiBteSBwYXNzdGhyb3VnaAo+IGRldmljZSBmcm9tIG15IEhWTSBndWVzdCB1bmRlciBYZW4gNC4y
IHZpYSBNTUlPL1BJTyBkaXJlY3RseS4gSXMgdGhlcmUKPiBhbnkgb3B0aW9uIGZvciB0aGlzIGlu
IHRoZSBjb25maWcgZmlsZSBvZiB0aGUgZ3Vlc3Q/IEkga25vdyBhYm91dCB0aGUKPiBpb3BvcnRz
PVsnJ10gb3B0aW9uIGZvciBQSU8gYWNjZXNzZXMsIGJ1dCBpcyB0aGVyZSBhbnkgd2F5IHRvIGRv
IHRoZQo+IHNhbWUgd2l0aCBNTUlPIEJBUiByZWdpc3RlcnM/CgpGb3IgYSBQQ0kgZGV2aWNlLCBu
byBleHRyYSBvcHRpb24gc2hvdWxkIGJlIG5lZWRlZCBmb3IgZWl0aGVyCklPIHBvcnRzIG9yIE1N
SU8gcmVnaW9ucy4KCj4gQXMgZmFyIGFzIEkga25vdyB0aGUgcGVybWlzc2l2ZSBmbGFnIHdvcmtz
Cj4gb25seSBmb3IgUFYgZ3Vlc3RzLiBEb2VzIHRoZSBpb3BvcnRzIG9wdGlvbiBhbGxvdyBkaXJl
Y3QgYWNjZXNzIHRvCj4gY29uZmlnIHNwYWNlICgweGNmOC0weGNmYyk/IEFjY29yZGluZyB0byBp
biB4ZW4vYXJjaC94ODYvdHJhcC5jIGl0IGlzCj4gbm90IGFsbG93ZWQuCgpDb3JyZWN0LCBhbGJl
aXQgdGhhdCBjb2RlIGRvZXNuJ3QgY29udHJvbCBIVk0gZ3Vlc3RzLiBCdXQgaWYgeW91CmdhdmUg
SFZNIGd1ZXN0cyBhY2Nlc3MgdG8gdGhlc2UgX3BoeXNpY2FsXyBwb3J0cywgdGhleSBjb3VsZAph
dCBvbmNlIGNvbnRyb2wgYWxsIG90aGVyIFBDSSBkZXZpY2VzLiBTbyBJJ20gc3VyZSB5b3UgZG9u
J3Qgd2FudAp0byBkbyB0aGF0LgoKPiAgICAgLyoKPiAgICAgICogUG9ydCAweGNmOCAoQ09ORklH
X0FERFJFU1MpIGlzIG9ubHkgdmlzaWJsZSBmb3IgRFdPUkQgYWNjZXNzZXMuCj4gICAgICAqIFdl
IG5ldmVyIHBlcm1pdCBkaXJlY3QgYWNjZXNzIHRvIHRoYXQgcmVnaXN0ZXIuCj4gICAgICAqLwo+
IAo+IFdoYXQgYWJvdXQgRG9tMD8KCk5vdCBldmVuIERvbTAuIFRoaXMgZ2V0cyBlbXVsYXRlZCBp
biBYZW4uCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:53:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:53: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 1U6OXT-000188-PG; Fri, 15 Feb 2013 16:53: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 1U6OXS-000180-KE
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:53:30 +0000
Received: from [85.158.139.83:31351] by server-12.bemta-5.messagelabs.com id
	45/01-20195-9086E115; Fri, 15 Feb 2013 16:53:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360947209!27762728!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 15 Feb 2013 16:53:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:53:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:53:28 +0000
Message-Id: <511E761402000078000BEDD8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:53:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130215163451.GD13775@phenom.dumpdata.com>
In-Reply-To: <20130215163451.GD13775@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jinsong.liu@intel.com, xen-devel <xen-devel@lists.xen.org>,
	linux-kernel@vger.kernel.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Patches for v3.9 for the Linux 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 15.02.13 at 17:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> I know that the PVH patches are not in the Xen tree. I am hoping that
> at least the hypercalls _are_ OK with everybody so we can continue on
> with this.

Please don't commit to anything that isn't in the hypervisor tree
yet. IOW I'd like you to not push the PVH bits that use
uncommitted hypervisor interfaces (anything preparatory of
course is okay).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:53:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:53: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 1U6OXT-000188-PG; Fri, 15 Feb 2013 16:53: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 1U6OXS-000180-KE
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:53:30 +0000
Received: from [85.158.139.83:31351] by server-12.bemta-5.messagelabs.com id
	45/01-20195-9086E115; Fri, 15 Feb 2013 16:53:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1360947209!27762728!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 15 Feb 2013 16:53:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Feb 2013 16:53:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:53:28 +0000
Message-Id: <511E761402000078000BEDD8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:53:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130215163451.GD13775@phenom.dumpdata.com>
In-Reply-To: <20130215163451.GD13775@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jinsong.liu@intel.com, xen-devel <xen-devel@lists.xen.org>,
	linux-kernel@vger.kernel.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Patches for v3.9 for the Linux 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 15.02.13 at 17:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> I know that the PVH patches are not in the Xen tree. I am hoping that
> at least the hypercalls _are_ OK with everybody so we can continue on
> with this.

Please don't commit to anything that isn't in the hypervisor tree
yet. IOW I'd like you to not push the PVH bits that use
uncommitted hypervisor interfaces (anything preparatory of
course is okay).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:59:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:59: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 1U6Od7-0001K2-J8; Fri, 15 Feb 2013 16:59: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 1U6Od5-0001Jx-VQ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:59:20 +0000
Received: from [85.158.138.51:12498] by server-4.bemta-3.messagelabs.com id
	A9/57-17521-7696E115; Fri, 15 Feb 2013 16:59:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360947558!23710793!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16312 invoked from network); 15 Feb 2013 16:59: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; 15 Feb 2013 16:59:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:59:16 +0000
Message-Id: <511E777102000078000BEDFF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:59:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
	<511E6D9702000078000BED23@nat28.tlf.novell.com>
	<1360945999.16636.169.camel@zion.uk.xensource.com>
In-Reply-To: <1360945999.16636.169.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	Roger PauMonne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 17:33, Wei Liu <wei.liu2@citrix.com> wrote:
> On Fri, 2013-02-15 at 16:17 +0000, Jan Beulich wrote:
>> >>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
>> > Also bundle fixes for xen frontends and backends in this patch.
>> 
>> Could you at least enumerate those fixes in the patch description?
> 
> Mostly mechanical fixes to adapt to new xenbus client interface, which
> includes: xen-pciback, xen-pcifront, xen-blkback, xen-blkfront,
> xen-netback, xen-netfront.

But "fixes" and "changes" are two different terms.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 16:59:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 16:59: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 1U6Od7-0001K2-J8; Fri, 15 Feb 2013 16:59: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 1U6Od5-0001Jx-VQ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 16:59:20 +0000
Received: from [85.158.138.51:12498] by server-4.bemta-3.messagelabs.com id
	A9/57-17521-7696E115; Fri, 15 Feb 2013 16:59:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1360947558!23710793!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16312 invoked from network); 15 Feb 2013 16:59: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; 15 Feb 2013 16:59:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 15 Feb 2013 16:59:16 +0000
Message-Id: <511E777102000078000BEDFF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 15 Feb 2013 16:59:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
	<511E6D9702000078000BED23@nat28.tlf.novell.com>
	<1360945999.16636.169.camel@zion.uk.xensource.com>
In-Reply-To: <1360945999.16636.169.camel@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	Roger PauMonne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 17:33, Wei Liu <wei.liu2@citrix.com> wrote:
> On Fri, 2013-02-15 at 16:17 +0000, Jan Beulich wrote:
>> >>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
>> > Also bundle fixes for xen frontends and backends in this patch.
>> 
>> Could you at least enumerate those fixes in the patch description?
> 
> Mostly mechanical fixes to adapt to new xenbus client interface, which
> includes: xen-pciback, xen-pcifront, xen-blkback, xen-blkfront,
> xen-netback, xen-netfront.

But "fixes" and "changes" are two different terms.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:01:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6OfL-0001Su-4M; Fri, 15 Feb 2013 17:01:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U6OfJ-0001Sn-S9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:01:38 +0000
Received: from [85.158.137.99:63114] by server-9.bemta-3.messagelabs.com id
	76/01-09484-CE96E115; Fri, 15 Feb 2013 17:01:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360947683!20824063!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19261 invoked from network); 15 Feb 2013 17:01:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 17:01:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7339857"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 17:01:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 12:01:21 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6Of3-0006Td-OX;
	Fri, 15 Feb 2013 17:01:21 +0000
Message-ID: <1360947681.16636.170.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 17:01:21 +0000
In-Reply-To: <511E777102000078000BEDFF@nat28.tlf.novell.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
	<511E6D9702000078000BED23@nat28.tlf.novell.com>
	<1360945999.16636.169.camel@zion.uk.xensource.com>
	<511E777102000078000BEDFF@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>, Roger Pau
	Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 16:59 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:33, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Fri, 2013-02-15 at 16:17 +0000, Jan Beulich wrote:
> >> >>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > Also bundle fixes for xen frontends and backends in this patch.
> >> 
> >> Could you at least enumerate those fixes in the patch description?
> > 
> > Mostly mechanical fixes to adapt to new xenbus client interface, which
> > includes: xen-pciback, xen-pcifront, xen-blkback, xen-blkfront,
> > xen-netback, xen-netfront.
> 
> But "fixes" and "changes" are two different terms.
> 

I "fixed" the build breakage. :-)


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:01:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6OfL-0001Su-4M; Fri, 15 Feb 2013 17:01:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U6OfJ-0001Sn-S9
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:01:38 +0000
Received: from [85.158.137.99:63114] by server-9.bemta-3.messagelabs.com id
	76/01-09484-CE96E115; Fri, 15 Feb 2013 17:01:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1360947683!20824063!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19261 invoked from network); 15 Feb 2013 17:01:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 17:01:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7339857"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 17:01:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 12:01:21 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6Of3-0006Td-OX;
	Fri, 15 Feb 2013 17:01:21 +0000
Message-ID: <1360947681.16636.170.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 15 Feb 2013 17:01:21 +0000
In-Reply-To: <511E777102000078000BEDFF@nat28.tlf.novell.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-5-git-send-email-wei.liu2@citrix.com>
	<511E6D9702000078000BED23@nat28.tlf.novell.com>
	<1360945999.16636.169.camel@zion.uk.xensource.com>
	<511E777102000078000BEDFF@nat28.tlf.novell.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>, Roger Pau
	Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/8] xenbus_client: Extend interface to
 support multi-page ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 16:59 +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:33, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Fri, 2013-02-15 at 16:17 +0000, Jan Beulich wrote:
> >> >>> On 15.02.13 at 17:00, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > Also bundle fixes for xen frontends and backends in this patch.
> >> 
> >> Could you at least enumerate those fixes in the patch description?
> > 
> > Mostly mechanical fixes to adapt to new xenbus client interface, which
> > includes: xen-pciback, xen-pcifront, xen-blkback, xen-blkfront,
> > xen-netback, xen-netfront.
> 
> But "fixes" and "changes" are two different terms.
> 

I "fixed" the build breakage. :-)


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:05:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:05: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 1U6OiS-0001cv-ON; Fri, 15 Feb 2013 17:04: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 1U6OiR-0001cn-Q3
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:04:51 +0000
Received: from [85.158.143.35:12486] by server-2.bemta-4.messagelabs.com id
	F3/26-01597-3BA6E115; Fri, 15 Feb 2013 17:04:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360947887!15751068!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18020 invoked from network); 15 Feb 2013 17:04:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 17:04:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1524450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 17:04: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.297.1;
	Fri, 15 Feb 2013 17:04:31 +0000
Message-ID: <1360947870.31407.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 17:04:30 +0000
In-Reply-To: <1360934328.31407.41.camel@zakaz.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > > +                        u32 dflt)
> > >  {
> > >      const struct fdt_property *prop;
> > >  
> > >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> > >      if ( !prop || prop->len < sizeof(u32) )
> > > -        return 0; /* default to 0 */
> > > +        return dflt;
> > >  
> > >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> > >  }
> > 
> > where did the vowels go? :)
> 
> Not sure. Unlike me ;-)

I remembered when I went to change it, default is a C keyword...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:05:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:05: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 1U6OiS-0001cv-ON; Fri, 15 Feb 2013 17:04: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 1U6OiR-0001cn-Q3
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:04:51 +0000
Received: from [85.158.143.35:12486] by server-2.bemta-4.messagelabs.com id
	F3/26-01597-3BA6E115; Fri, 15 Feb 2013 17:04:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360947887!15751068!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18020 invoked from network); 15 Feb 2013 17:04:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 17:04:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1524450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 17:04: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.297.1;
	Fri, 15 Feb 2013 17:04:31 +0000
Message-ID: <1360947870.31407.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 15 Feb 2013 17:04:30 +0000
In-Reply-To: <1360934328.31407.41.camel@zakaz.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > > +                        u32 dflt)
> > >  {
> > >      const struct fdt_property *prop;
> > >  
> > >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> > >      if ( !prop || prop->len < sizeof(u32) )
> > > -        return 0; /* default to 0 */
> > > +        return dflt;
> > >  
> > >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> > >  }
> > 
> > where did the vowels go? :)
> 
> Not sure. Unlike me ;-)

I remembered when I went to change it, default is a C keyword...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:06:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:06: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 1U6OkH-0001kP-8i; Fri, 15 Feb 2013 17:06:45 +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 1U6OkF-0001kB-Fk
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:06:43 +0000
Received: from [85.158.143.99:56021] by server-2.bemta-4.messagelabs.com id
	A6/08-01597-22B6E115; Fri, 15 Feb 2013 17:06:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360948000!22470124!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxNzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27738 invoked from network); 15 Feb 2013 17:06:41 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-12.tower-216.messagelabs.com with SMTP;
	15 Feb 2013 17:06:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 15 Feb 2013 09:06:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,674,1355126400"; 
	d="scan'208,223";a="257545152"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 15 Feb 2013 09:06:39 -0800
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:06:33 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:06:33 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 01:06:31 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stephen Rothwell
	<sfr@canb.auug.org.au>, "Rafael J. Wysocki" <rjw@sisk.pl>, "Wu, Fengguang"
	<fengguang.wu@intel.com>
Thread-Topic: [PATCH] xen/acpi: updates the argument of .remove operation of
	xen cpu/mem hotplug
Thread-Index: Ac4LnswpXP+OkzAJSRiFL0LSDoC8QQ==
Date: Fri, 15 Feb 2013 17:06:30 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FBF3A@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_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/acpi: updates the argument of .remove
 operation of xen cpu/mem hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 3e27e90049354a0f52fd006970fc8ecd80b08152 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sat, 16 Feb 2013 00:42:45 +0800
Subject: [PATCH] xen/acpi: updates the argument of .remove operation of xen=
 cpu/mem hotplug

Rafael removed useless type argument of acpi driver .remove operation.
This patch updates the argument of .remove operation of xen cpu/memory
driver accordingly.

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen-acpi-cpuhotplug.c |    2 +-
 drivers/xen/xen-acpi-memhotplug.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuho=
tplug.c
index acc5b12..7578279 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -113,7 +113,7 @@ static int __cpuinit xen_acpi_processor_add(struct acpi=
_device *device)
 	return ret;
 }
=20
-static int xen_acpi_processor_remove(struct acpi_device *device, int type)
+static int xen_acpi_processor_remove(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
=20
diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memho=
tplug.c
index 164287b..853b12d 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -329,7 +329,7 @@ static int xen_acpi_memory_device_add(struct acpi_devic=
e *device)
 	return result;
 }
=20
-static int xen_acpi_memory_device_remove(struct acpi_device *device, int t=
ype)
+static int xen_acpi_memory_device_remove(struct acpi_device *device)
 {
 	struct acpi_memory_device *mem_device =3D NULL;
=20
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-acpi-updates-the-argument-of-.remove-operation-o.patch"
Content-Description: 0001-xen-acpi-updates-the-argument-of-.remove-operation-o.patch
Content-Disposition: attachment;
	filename="0001-xen-acpi-updates-the-argument-of-.remove-operation-o.patch";
	size=1598; creation-date="Fri, 15 Feb 2013 16:54:20 GMT";
	modification-date="Sat, 16 Feb 2013 00:44:00 GMT"
Content-Transfer-Encoding: base64

RnJvbSAzZTI3ZTkwMDQ5MzU0YTBmNTJmZDAwNjk3MGZjOGVjZDgwYjA4MTUyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTYXQsIDE2IEZlYiAyMDEzIDAwOjQyOjQ1ICswODAwClN1YmplY3Q6IFtQQVRDSF0geGVu
L2FjcGk6IHVwZGF0ZXMgdGhlIGFyZ3VtZW50IG9mIC5yZW1vdmUgb3BlcmF0aW9uIG9mIHhlbiBj
cHUvbWVtIGhvdHBsdWcKClJhZmFlbCByZW1vdmVkIHVzZWxlc3MgdHlwZSBhcmd1bWVudCBvZiBh
Y3BpIGRyaXZlciAucmVtb3ZlIG9wZXJhdGlvbi4KVGhpcyBwYXRjaCB1cGRhdGVzIHRoZSBhcmd1
bWVudCBvZiAucmVtb3ZlIG9wZXJhdGlvbiBvZiB4ZW4gY3B1L21lbW9yeQpkcml2ZXIgYWNjb3Jk
aW5nbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29t
PgotLS0KIGRyaXZlcnMveGVuL3hlbi1hY3BpLWNwdWhvdHBsdWcuYyB8ICAgIDIgKy0KIGRyaXZl
cnMveGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYyB8ICAgIDIgKy0KIDIgZmlsZXMgY2hhbmdlZCwg
MiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L3hlbi1hY3BpLWNwdWhvdHBsdWcuYyBiL2RyaXZlcnMveGVuL3hlbi1hY3BpLWNwdWhvdHBsdWcu
YwppbmRleCBhY2M1YjEyLi43NTc4Mjc5IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4tYWNw
aS1jcHVob3RwbHVnLmMKKysrIGIvZHJpdmVycy94ZW4veGVuLWFjcGktY3B1aG90cGx1Zy5jCkBA
IC0xMTMsNyArMTEzLDcgQEAgc3RhdGljIGludCBfX2NwdWluaXQgeGVuX2FjcGlfcHJvY2Vzc29y
X2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1cm4gcmV0OwogfQogCi1zdGF0
aWMgaW50IHhlbl9hY3BpX3Byb2Nlc3Nvcl9yZW1vdmUoc3RydWN0IGFjcGlfZGV2aWNlICpkZXZp
Y2UsIGludCB0eXBlKQorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfcmVtb3ZlKHN0cnVj
dCBhY3BpX2RldmljZSAqZGV2aWNlKQogewogCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHI7CiAK
ZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYyBiL2RyaXZlcnMv
eGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYwppbmRleCAxNjQyODdiLi44NTNiMTJkIDEwMDY0NAot
LS0gYS9kcml2ZXJzL3hlbi94ZW4tYWNwaS1tZW1ob3RwbHVnLmMKKysrIGIvZHJpdmVycy94ZW4v
eGVuLWFjcGktbWVtaG90cGx1Zy5jCkBAIC0zMjksNyArMzI5LDcgQEAgc3RhdGljIGludCB4ZW5f
YWNwaV9tZW1vcnlfZGV2aWNlX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1
cm4gcmVzdWx0OwogfQogCi1zdGF0aWMgaW50IHhlbl9hY3BpX21lbW9yeV9kZXZpY2VfcmVtb3Zl
KHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlLCBpbnQgdHlwZSkKK3N0YXRpYyBpbnQgeGVuX2Fj
cGlfbWVtb3J5X2RldmljZV9yZW1vdmUoc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2UpCiB7CiAJ
c3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqbWVtX2RldmljZSA9IE5VTEw7CiAKLS0gCjEuNy4x
Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Feb 15 17:06:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:06: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 1U6OkH-0001kP-8i; Fri, 15 Feb 2013 17:06:45 +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 1U6OkF-0001kB-Fk
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:06:43 +0000
Received: from [85.158.143.99:56021] by server-2.bemta-4.messagelabs.com id
	A6/08-01597-22B6E115; Fri, 15 Feb 2013 17:06:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1360948000!22470124!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUxNzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27738 invoked from network); 15 Feb 2013 17:06:41 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-12.tower-216.messagelabs.com with SMTP;
	15 Feb 2013 17:06:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 15 Feb 2013 09:06:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,674,1355126400"; 
	d="scan'208,223";a="257545152"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 15 Feb 2013 09:06:39 -0800
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:06:33 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:06:33 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 01:06:31 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stephen Rothwell
	<sfr@canb.auug.org.au>, "Rafael J. Wysocki" <rjw@sisk.pl>, "Wu, Fengguang"
	<fengguang.wu@intel.com>
Thread-Topic: [PATCH] xen/acpi: updates the argument of .remove operation of
	xen cpu/mem hotplug
Thread-Index: Ac4LnswpXP+OkzAJSRiFL0LSDoC8QQ==
Date: Fri, 15 Feb 2013 17:06:30 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FBF3A@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_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH] xen/acpi: updates the argument of .remove
 operation of xen cpu/mem hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 3e27e90049354a0f52fd006970fc8ecd80b08152 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sat, 16 Feb 2013 00:42:45 +0800
Subject: [PATCH] xen/acpi: updates the argument of .remove operation of xen=
 cpu/mem hotplug

Rafael removed useless type argument of acpi driver .remove operation.
This patch updates the argument of .remove operation of xen cpu/memory
driver accordingly.

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen-acpi-cpuhotplug.c |    2 +-
 drivers/xen/xen-acpi-memhotplug.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuho=
tplug.c
index acc5b12..7578279 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -113,7 +113,7 @@ static int __cpuinit xen_acpi_processor_add(struct acpi=
_device *device)
 	return ret;
 }
=20
-static int xen_acpi_processor_remove(struct acpi_device *device, int type)
+static int xen_acpi_processor_remove(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
=20
diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memho=
tplug.c
index 164287b..853b12d 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -329,7 +329,7 @@ static int xen_acpi_memory_device_add(struct acpi_devic=
e *device)
 	return result;
 }
=20
-static int xen_acpi_memory_device_remove(struct acpi_device *device, int t=
ype)
+static int xen_acpi_memory_device_remove(struct acpi_device *device)
 {
 	struct acpi_memory_device *mem_device =3D NULL;
=20
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-acpi-updates-the-argument-of-.remove-operation-o.patch"
Content-Description: 0001-xen-acpi-updates-the-argument-of-.remove-operation-o.patch
Content-Disposition: attachment;
	filename="0001-xen-acpi-updates-the-argument-of-.remove-operation-o.patch";
	size=1598; creation-date="Fri, 15 Feb 2013 16:54:20 GMT";
	modification-date="Sat, 16 Feb 2013 00:44:00 GMT"
Content-Transfer-Encoding: base64

RnJvbSAzZTI3ZTkwMDQ5MzU0YTBmNTJmZDAwNjk3MGZjOGVjZDgwYjA4MTUyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTYXQsIDE2IEZlYiAyMDEzIDAwOjQyOjQ1ICswODAwClN1YmplY3Q6IFtQQVRDSF0geGVu
L2FjcGk6IHVwZGF0ZXMgdGhlIGFyZ3VtZW50IG9mIC5yZW1vdmUgb3BlcmF0aW9uIG9mIHhlbiBj
cHUvbWVtIGhvdHBsdWcKClJhZmFlbCByZW1vdmVkIHVzZWxlc3MgdHlwZSBhcmd1bWVudCBvZiBh
Y3BpIGRyaXZlciAucmVtb3ZlIG9wZXJhdGlvbi4KVGhpcyBwYXRjaCB1cGRhdGVzIHRoZSBhcmd1
bWVudCBvZiAucmVtb3ZlIG9wZXJhdGlvbiBvZiB4ZW4gY3B1L21lbW9yeQpkcml2ZXIgYWNjb3Jk
aW5nbHkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29t
PgotLS0KIGRyaXZlcnMveGVuL3hlbi1hY3BpLWNwdWhvdHBsdWcuYyB8ICAgIDIgKy0KIGRyaXZl
cnMveGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYyB8ICAgIDIgKy0KIDIgZmlsZXMgY2hhbmdlZCwg
MiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L3hlbi1hY3BpLWNwdWhvdHBsdWcuYyBiL2RyaXZlcnMveGVuL3hlbi1hY3BpLWNwdWhvdHBsdWcu
YwppbmRleCBhY2M1YjEyLi43NTc4Mjc5IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4tYWNw
aS1jcHVob3RwbHVnLmMKKysrIGIvZHJpdmVycy94ZW4veGVuLWFjcGktY3B1aG90cGx1Zy5jCkBA
IC0xMTMsNyArMTEzLDcgQEAgc3RhdGljIGludCBfX2NwdWluaXQgeGVuX2FjcGlfcHJvY2Vzc29y
X2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1cm4gcmV0OwogfQogCi1zdGF0
aWMgaW50IHhlbl9hY3BpX3Byb2Nlc3Nvcl9yZW1vdmUoc3RydWN0IGFjcGlfZGV2aWNlICpkZXZp
Y2UsIGludCB0eXBlKQorc3RhdGljIGludCB4ZW5fYWNwaV9wcm9jZXNzb3JfcmVtb3ZlKHN0cnVj
dCBhY3BpX2RldmljZSAqZGV2aWNlKQogewogCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHI7CiAK
ZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYyBiL2RyaXZlcnMv
eGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYwppbmRleCAxNjQyODdiLi44NTNiMTJkIDEwMDY0NAot
LS0gYS9kcml2ZXJzL3hlbi94ZW4tYWNwaS1tZW1ob3RwbHVnLmMKKysrIGIvZHJpdmVycy94ZW4v
eGVuLWFjcGktbWVtaG90cGx1Zy5jCkBAIC0zMjksNyArMzI5LDcgQEAgc3RhdGljIGludCB4ZW5f
YWNwaV9tZW1vcnlfZGV2aWNlX2FkZChzdHJ1Y3QgYWNwaV9kZXZpY2UgKmRldmljZSkKIAlyZXR1
cm4gcmVzdWx0OwogfQogCi1zdGF0aWMgaW50IHhlbl9hY3BpX21lbW9yeV9kZXZpY2VfcmVtb3Zl
KHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlLCBpbnQgdHlwZSkKK3N0YXRpYyBpbnQgeGVuX2Fj
cGlfbWVtb3J5X2RldmljZV9yZW1vdmUoc3RydWN0IGFjcGlfZGV2aWNlICpkZXZpY2UpCiB7CiAJ
c3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqbWVtX2RldmljZSA9IE5VTEw7CiAKLS0gCjEuNy4x
Cgo=

--_002_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353FBF3ASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Feb 15 17:20:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6OxM-0002BV-Rz; Fri, 15 Feb 2013 17:20:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1U6OxL-0002BQ-NY
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:20:15 +0000
Received: from [85.158.139.211:61539] by server-2.bemta-5.messagelabs.com id
	68/34-16911-E4E6E115; Fri, 15 Feb 2013 17:20:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360948812!19951079!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxNzQwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23333 invoked from network); 15 Feb 2013 17:20:13 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-206.messagelabs.com with SMTP;
	15 Feb 2013 17:20:13 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 15 Feb 2013 09:20:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,674,1355126400"; d="scan'208";a="291733466"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 15 Feb 2013 09:20:10 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:20:10 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 01:20:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stephen Rothwell
	<sfr@canb.auug.org.au>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHOC4AoTyBHFMmDoE2LH83uWllZQ5h7KcvQ
Date: Fri, 15 Feb 2013 17:20:07 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FBF85@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<20130215132624.GB11777@phenom.dumpdata.com>
In-Reply-To: <20130215132624.GB11777@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: "Rafael J.
	Wysocki" <rjw@sisk.pl>, "Wu, Fengguang" <fengguang.wu@intel.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fri, Feb 15, 2013 at 03:45:51PM +1100, Stephen Rothwell wrote:
>> Hi Konrad,
>> 
>> After merging the xen-two tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
> 
> Good morning!
>> 
>> drivers/xen/xen-acpi-memhotplug.c: In function
>> 'acpi_memory_get_device': 
>> drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration
>> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
>> drivers/xen/xen-acpi-memhotplug.c: At top level: 
>> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization
>> from incompatible pointer type [enabled by default]
>> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near
>> initialization for 'xen_acpi_memory_device_driver.ops.remove')
>> [enabled by default]   
>> 
>> Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").
>> 
>> drivers/xen/xen-acpi-cpuhotplug.c: In function
>> 'acpi_processor_device_add': 
>> drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration
>> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
>> drivers/xen/xen-acpi-cpuhotplug.c: At top level: 
>> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization
>> from incompatible pointer type [enabled by default]
>> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near
>> initialization for 'xen_acpi_processor_driver.ops.remove') [enabled
>> by default]   
>> 
>> Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").
> 
> Grrrreat! Jinsong, can you please fix that ? A patch on top of the
> #linux-next
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 

Done, warning fixed.

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 Feb 15 17:20:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6OxM-0002BV-Rz; Fri, 15 Feb 2013 17:20:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1U6OxL-0002BQ-NY
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:20:15 +0000
Received: from [85.158.139.211:61539] by server-2.bemta-5.messagelabs.com id
	68/34-16911-E4E6E115; Fri, 15 Feb 2013 17:20:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1360948812!19951079!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxNzQwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23333 invoked from network); 15 Feb 2013 17:20:13 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-206.messagelabs.com with SMTP;
	15 Feb 2013 17:20:13 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 15 Feb 2013 09:20:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,674,1355126400"; d="scan'208";a="291733466"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 15 Feb 2013 09:20:10 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:20:10 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 01:20:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stephen Rothwell
	<sfr@canb.auug.org.au>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHOC4AoTyBHFMmDoE2LH83uWllZQ5h7KcvQ
Date: Fri, 15 Feb 2013 17:20:07 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FBF85@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<20130215132624.GB11777@phenom.dumpdata.com>
In-Reply-To: <20130215132624.GB11777@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: "Rafael J.
	Wysocki" <rjw@sisk.pl>, "Wu, Fengguang" <fengguang.wu@intel.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Fri, Feb 15, 2013 at 03:45:51PM +1100, Stephen Rothwell wrote:
>> Hi Konrad,
>> 
>> After merging the xen-two tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
> 
> Good morning!
>> 
>> drivers/xen/xen-acpi-memhotplug.c: In function
>> 'acpi_memory_get_device': 
>> drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration
>> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
>> drivers/xen/xen-acpi-memhotplug.c: At top level: 
>> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization
>> from incompatible pointer type [enabled by default]
>> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near
>> initialization for 'xen_acpi_memory_device_driver.ops.remove')
>> [enabled by default]   
>> 
>> Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").
>> 
>> drivers/xen/xen-acpi-cpuhotplug.c: In function
>> 'acpi_processor_device_add': 
>> drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration
>> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
>> drivers/xen/xen-acpi-cpuhotplug.c: At top level: 
>> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization
>> from incompatible pointer type [enabled by default]
>> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near
>> initialization for 'xen_acpi_processor_driver.ops.remove') [enabled
>> by default]   
>> 
>> Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").
> 
> Grrrreat! Jinsong, can you please fix that ? A patch on top of the
> #linux-next
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 

Done, warning fixed.

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 Feb 15 17:22:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:22: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 1U6Oz5-0002FZ-CC; Fri, 15 Feb 2013 17:22:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6Oz3-0002FQ-So
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:22:02 +0000
Received: from [85.158.139.211:8814] by server-9.bemta-5.messagelabs.com id
	29/AC-24440-9BE6E115; Fri, 15 Feb 2013 17:22:01 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360948918!22679252!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22454 invoked from network); 15 Feb 2013 17:22:00 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:22:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHLucH018816
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:21:57 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
	r1FHLuo8018693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:21:56 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
	r1FHLtFS031099; Fri, 15 Feb 2013 11:21:55 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:21:55 -0800
Message-ID: <511E6EA4.9050009@oracle.com>
Date: Fri, 15 Feb 2013 12:21:40 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E5F02000078000BED4E@nat28.tlf.novell.com>
In-Reply-To: <511E6E5F02000078000BED4E@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] AMD IOMMU: cover all functions of a
 device even if ACPI only tells us of func 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-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/15/2013 11:20 AM, Jan Beulich wrote:
>   
>   static int __init get_last_bdf_acpi(struct acpi_table_header *table)
>   {
>       const struct acpi_ivrs_header *ivrs_block;
>       unsigned long length = sizeof(struct acpi_table_ivrs);
> +    int last_bdf = 0;
>   
>       while ( table->length > (length + sizeof(*ivrs_block)) )
>       {
>           ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>           if ( table->length < (length + ivrs_block->length) )
>               return -ENODEV;
> -        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE &&
> -             get_last_bdf_ivhd(
> +        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE )
> +        {
> +            int ret = get_last_bdf_ivhd(
>                    container_of(ivrs_block, const struct acpi_ivrs_hardware,
> -                              header)) != 0 )
> -            return -ENODEV;
> +                              header));
> +
> +            if ( ret < 0 )
> +                return ret;
> +            UPDATE_LAST_BDF(ret);

Why do we need UPDATE_LAST_BDF () here? It is updated in 
get_last_bdf_ivhd () above.

> +        }
>           length += ivrs_block->length;
>       }
> -   return 0;
> +
> +    return last_bdf;
>   }

...

> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -28,12 +28,38 @@
>   #include <asm/hvm/svm/amd-iommu-proto.h>
>   #include "../ats.h"
>   
> +static bool_t __read_mostly init_done;
> +
>   struct amd_iommu *find_iommu_for_device(int seg, int bdf)
>   {
>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
>   
> -    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
> -                                                   : NULL;
> +    if ( !ivrs_mappings || bdf >= ivrs_bdf_entries )
> +        return NULL;
> +
> +    if ( unlikely(!ivrs_mappings[bdf].iommu) && likely(init_done) )
> +    {
> +        unsigned int bd0 = bdf & ~PCI_FUNC(~0);
> +
> +        if ( ivrs_mappings[bd0].iommu )
> +        {
> +            struct ivrs_mappings tmp = ivrs_mappings[bd0];
> +
> +            tmp.iommu = NULL;
> +            if ( tmp.dte_requestor_id == bd0 )
> +                tmp.dte_requestor_id = bdf;

Is it possible to have tmp.dte_requestor_id != bd0


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:22:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:22: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 1U6Oz5-0002FZ-CC; Fri, 15 Feb 2013 17:22:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6Oz3-0002FQ-So
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:22:02 +0000
Received: from [85.158.139.211:8814] by server-9.bemta-5.messagelabs.com id
	29/AC-24440-9BE6E115; Fri, 15 Feb 2013 17:22:01 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1360948918!22679252!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22454 invoked from network); 15 Feb 2013 17:22:00 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:22:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHLucH018816
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:21:57 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
	r1FHLuo8018693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:21:56 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
	r1FHLtFS031099; Fri, 15 Feb 2013 11:21:55 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:21:55 -0800
Message-ID: <511E6EA4.9050009@oracle.com>
Date: Fri, 15 Feb 2013 12:21:40 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E5F02000078000BED4E@nat28.tlf.novell.com>
In-Reply-To: <511E6E5F02000078000BED4E@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] AMD IOMMU: cover all functions of a
 device even if ACPI only tells us of func 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-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/15/2013 11:20 AM, Jan Beulich wrote:
>   
>   static int __init get_last_bdf_acpi(struct acpi_table_header *table)
>   {
>       const struct acpi_ivrs_header *ivrs_block;
>       unsigned long length = sizeof(struct acpi_table_ivrs);
> +    int last_bdf = 0;
>   
>       while ( table->length > (length + sizeof(*ivrs_block)) )
>       {
>           ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>           if ( table->length < (length + ivrs_block->length) )
>               return -ENODEV;
> -        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE &&
> -             get_last_bdf_ivhd(
> +        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE )
> +        {
> +            int ret = get_last_bdf_ivhd(
>                    container_of(ivrs_block, const struct acpi_ivrs_hardware,
> -                              header)) != 0 )
> -            return -ENODEV;
> +                              header));
> +
> +            if ( ret < 0 )
> +                return ret;
> +            UPDATE_LAST_BDF(ret);

Why do we need UPDATE_LAST_BDF () here? It is updated in 
get_last_bdf_ivhd () above.

> +        }
>           length += ivrs_block->length;
>       }
> -   return 0;
> +
> +    return last_bdf;
>   }

...

> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -28,12 +28,38 @@
>   #include <asm/hvm/svm/amd-iommu-proto.h>
>   #include "../ats.h"
>   
> +static bool_t __read_mostly init_done;
> +
>   struct amd_iommu *find_iommu_for_device(int seg, int bdf)
>   {
>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
>   
> -    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
> -                                                   : NULL;
> +    if ( !ivrs_mappings || bdf >= ivrs_bdf_entries )
> +        return NULL;
> +
> +    if ( unlikely(!ivrs_mappings[bdf].iommu) && likely(init_done) )
> +    {
> +        unsigned int bd0 = bdf & ~PCI_FUNC(~0);
> +
> +        if ( ivrs_mappings[bd0].iommu )
> +        {
> +            struct ivrs_mappings tmp = ivrs_mappings[bd0];
> +
> +            tmp.iommu = NULL;
> +            if ( tmp.dte_requestor_id == bd0 )
> +                tmp.dte_requestor_id = bdf;

Is it possible to have tmp.dte_requestor_id != bd0


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:28:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6P5L-0002Yq-7J; Fri, 15 Feb 2013 17:28:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jun.nakajima@intel.com>) id 1U6P5J-0002Yl-PI
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:28:29 +0000
Received: from [85.158.143.99:56641] by server-2.bemta-4.messagelabs.com id
	3F/0A-01597-D307E115; Fri, 15 Feb 2013 17:28:29 +0000
X-Env-Sender: jun.nakajima@intel.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360949307!27239610!1
X-Originating-IP: [209.85.217.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19124 invoked from network); 15 Feb 2013 17:28:28 -0000
Received: from mail-lb0-f181.google.com (HELO mail-lb0-f181.google.com)
	(209.85.217.181)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 17:28:28 -0000
Received: by mail-lb0-f181.google.com with SMTP id gm6so2775836lbb.40
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 09:28:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=uj9AQzPlo7jHp1VBmObmzE+/t9s9vmEaN4th70oK0+o=;
	b=LVftxhBKe7vOer6E3nWAXqIo1yHs0/2bV2RWKHsnV6ZILrxLLO/nKGP+FYQrUujtxc
	/PUF1eGvm84YXdGbenh8VG27W9XBRvtinw2miHS3YRUGDNvmrXiKTaMNeJhei5dMUPI8
	237fNeUIPQcMf+rjbcAmw8nthUIwQdBf/ydVAh3tnhHSNbDnnGy/Gj3PrgRxYyVtREMd
	WWoIt8XABRqkQACGY2grbCV5wgqWMQcKapvGYxvlVPjhuHzPaumD854FEHKX/DYyA7J1
	JQr6K1Ljvn3CfzlCHBJkyS5rr7vtfqKf0hkd8xSbb9JVw8GbNq9Qxj0H34g2r7A2f+H5
	EabQ==
MIME-Version: 1.0
X-Received: by 10.112.26.10 with SMTP id h10mr2435857lbg.63.1360949307677;
	Fri, 15 Feb 2013 09:28:27 -0800 (PST)
Received: by 10.114.29.103 with HTTP; Fri, 15 Feb 2013 09:28:27 -0800 (PST)
In-Reply-To: <511A817B02000078000BDCAC@nat28.tlf.novell.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
	<511A817B02000078000BDCAC@nat28.tlf.novell.com>
Date: Fri, 15 Feb 2013 09:28:27 -0800
Message-ID: <CAL54oT2xvYjZCiPPr+x51NunbRjoVt=WNsiNt6PbyTLLpd5DTA@mail.gmail.com>
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlQfCp82bis+/X8AIXQgueHVcePjU7iUCBkAr1qq4BCxjb5cPtYP94lfXsrApjhRctXtOqJ
Cc: Jiongxi Li <jiongxi.li@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 12, 2013 at 8:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 30.01.13 at 04:23, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> This patchset fixes some APICV issues, including a potential issue while
>> doing live migration and enabling APICV while guest is in X2APIC mode.
>>
>> PATCH 1/2: Xen: Fix live migration while enabling APICV.
>>
>> PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling APICV.
>
> Jun, Eddie - we're still waiting for an ack of at least one of you
> on these two...
>

Acked-by: Jun Nakajima <jun.nakajima@intel.com>

-- 
Jun
Intel Open Source Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:28:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6P5L-0002Yq-7J; Fri, 15 Feb 2013 17:28:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jun.nakajima@intel.com>) id 1U6P5J-0002Yl-PI
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:28:29 +0000
Received: from [85.158.143.99:56641] by server-2.bemta-4.messagelabs.com id
	3F/0A-01597-D307E115; Fri, 15 Feb 2013 17:28:29 +0000
X-Env-Sender: jun.nakajima@intel.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360949307!27239610!1
X-Originating-IP: [209.85.217.181]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19124 invoked from network); 15 Feb 2013 17:28:28 -0000
Received: from mail-lb0-f181.google.com (HELO mail-lb0-f181.google.com)
	(209.85.217.181)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 17:28:28 -0000
Received: by mail-lb0-f181.google.com with SMTP id gm6so2775836lbb.40
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 09:28:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=uj9AQzPlo7jHp1VBmObmzE+/t9s9vmEaN4th70oK0+o=;
	b=LVftxhBKe7vOer6E3nWAXqIo1yHs0/2bV2RWKHsnV6ZILrxLLO/nKGP+FYQrUujtxc
	/PUF1eGvm84YXdGbenh8VG27W9XBRvtinw2miHS3YRUGDNvmrXiKTaMNeJhei5dMUPI8
	237fNeUIPQcMf+rjbcAmw8nthUIwQdBf/ydVAh3tnhHSNbDnnGy/Gj3PrgRxYyVtREMd
	WWoIt8XABRqkQACGY2grbCV5wgqWMQcKapvGYxvlVPjhuHzPaumD854FEHKX/DYyA7J1
	JQr6K1Ljvn3CfzlCHBJkyS5rr7vtfqKf0hkd8xSbb9JVw8GbNq9Qxj0H34g2r7A2f+H5
	EabQ==
MIME-Version: 1.0
X-Received: by 10.112.26.10 with SMTP id h10mr2435857lbg.63.1360949307677;
	Fri, 15 Feb 2013 09:28:27 -0800 (PST)
Received: by 10.114.29.103 with HTTP; Fri, 15 Feb 2013 09:28:27 -0800 (PST)
In-Reply-To: <511A817B02000078000BDCAC@nat28.tlf.novell.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
	<511A817B02000078000BDCAC@nat28.tlf.novell.com>
Date: Fri, 15 Feb 2013 09:28:27 -0800
Message-ID: <CAL54oT2xvYjZCiPPr+x51NunbRjoVt=WNsiNt6PbyTLLpd5DTA@mail.gmail.com>
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQlQfCp82bis+/X8AIXQgueHVcePjU7iUCBkAr1qq4BCxjb5cPtYP94lfXsrApjhRctXtOqJ
Cc: Jiongxi Li <jiongxi.li@intel.com>, Keir Fraser <keir.xen@gmail.com>,
	Eddie Dong <eddie.dong@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 12, 2013 at 8:52 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 30.01.13 at 04:23, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> This patchset fixes some APICV issues, including a potential issue while
>> doing live migration and enabling APICV while guest is in X2APIC mode.
>>
>> PATCH 1/2: Xen: Fix live migration while enabling APICV.
>>
>> PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling APICV.
>
> Jun, Eddie - we're still waiting for an ack of at least one of you
> on these two...
>

Acked-by: Jun Nakajima <jun.nakajima@intel.com>

-- 
Jun
Intel Open Source Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:29:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:29: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 1U6P5a-0002Zq-Jx; Fri, 15 Feb 2013 17:28:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6P5Z-0002ZX-KZ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:28:45 +0000
Received: from [85.158.137.99:41474] by server-1.bemta-3.messagelabs.com id
	EE/F6-08955-C407E115; Fri, 15 Feb 2013 17:28:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360949322!16235425!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9511 invoked from network); 15 Feb 2013 17:28:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:28:43 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHSd4s015716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:28:40 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
	r1FHScXm005393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:28:39 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
	r1FHSc0h030376; Fri, 15 Feb 2013 11:28:38 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:28:38 -0800
Message-ID: <511E7037.7040603@oracle.com>
Date: Fri, 15 Feb 2013 12:28:23 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6EEA02000078000BED56@nat28.tlf.novell.com>
In-Reply-To: <511E6EEA02000078000BED56@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/4] AMD IOMMU: use __ioapic_read_entry()
 instead of open coding 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-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/15/2013 11:22 AM, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

>
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -144,7 +144,7 @@ static void update_intremap_entry_from_i
>   
>   int __init amd_iommu_setup_ioapic_remapping(void)
>   {
> -    struct IO_APIC_route_entry rte = {0};
> +    struct IO_APIC_route_entry rte;
>       unsigned long flags;
>       u32* entry;
>       int apic, pin;
> @@ -159,9 +159,7 @@ int __init amd_iommu_setup_ioapic_remapp
>       {
>           for ( pin = 0; pin < nr_ioapic_entries[apic]; pin++ )
>           {
> -            *(((int *)&rte) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
> -            *(((int *)&rte) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
> -
> +            rte = __ioapic_read_entry(apic, pin, 1);
>               if ( rte.mask == 1 )
>                   continue;
>   
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:29:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:29: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 1U6P5a-0002Zq-Jx; Fri, 15 Feb 2013 17:28:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6P5Z-0002ZX-KZ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:28:45 +0000
Received: from [85.158.137.99:41474] by server-1.bemta-3.messagelabs.com id
	EE/F6-08955-C407E115; Fri, 15 Feb 2013 17:28:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1360949322!16235425!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9511 invoked from network); 15 Feb 2013 17:28:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:28:43 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHSd4s015716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:28:40 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
	r1FHScXm005393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:28:39 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
	r1FHSc0h030376; Fri, 15 Feb 2013 11:28:38 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:28:38 -0800
Message-ID: <511E7037.7040603@oracle.com>
Date: Fri, 15 Feb 2013 12:28:23 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6EEA02000078000BED56@nat28.tlf.novell.com>
In-Reply-To: <511E6EEA02000078000BED56@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4/4] AMD IOMMU: use __ioapic_read_entry()
 instead of open coding 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-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/15/2013 11:22 AM, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

>
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -144,7 +144,7 @@ static void update_intremap_entry_from_i
>   
>   int __init amd_iommu_setup_ioapic_remapping(void)
>   {
> -    struct IO_APIC_route_entry rte = {0};
> +    struct IO_APIC_route_entry rte;
>       unsigned long flags;
>       u32* entry;
>       int apic, pin;
> @@ -159,9 +159,7 @@ int __init amd_iommu_setup_ioapic_remapp
>       {
>           for ( pin = 0; pin < nr_ioapic_entries[apic]; pin++ )
>           {
> -            *(((int *)&rte) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
> -            *(((int *)&rte) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
> -
> +            rte = __ioapic_read_entry(apic, pin, 1);
>               if ( rte.mask == 1 )
>                   continue;
>   
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:31: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 1U6P7Z-0002jp-5i; Fri, 15 Feb 2013 17:30: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 1U6P7Y-0002jg-4h
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:30:48 +0000
Received: from [193.109.254.147:42925] by server-15.bemta-14.messagelabs.com
	id FB/5A-24599-7C07E115; Fri, 15 Feb 2013 17:30:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360949444!8545138!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23118 invoked from network); 15 Feb 2013 17:30:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:30:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHUhWG029200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:30:44 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
	r1FHUgT9009559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:30:43 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
	r1FHUgZH007682; Fri, 15 Feb 2013 11:30:42 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:30:42 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 526E61C387B; Fri, 15 Feb 2013 12:30:41 -0500 (EST)
Date: Fri, 15 Feb 2013 12:30:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130215173041.GB10133@phenom.dumpdata.com>
References: <20130215162651.GB13775@phenom.dumpdata.com>
	<511E74C302000078000BEDB1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E74C302000078000BEDB1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: gavin.bowe@oracle.com, kurt.hackel@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] What went in Linux 3.6,
 3.7 and 3.8 from Xen standpoint.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 04:47:47PM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > v3.7:
> >  - Initial support for ARM working under Xen as both guest and initial 
> > domain.
> >  - Security fixes.
> >  - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
> >    gntdev driver, fix some pvops calls failing, Fixes in
> >    xen-[kbd|fb|blk|net|hvc]-backend to deal with CLOSED transition
> >  - Allow xen/privcmd to use v2 of MMAPBATCH command (and fixes for it)
> >  - Support Xen backends to work with paged out grants (meaning work with HVM
> >    guests that have its memory paged out)
> >  - Performance optimization in xen/privcmd for migrating guests.
> >  - Performance improvements when doing kdump for PVonHVM guests.
> >  - Xen DBGP driver added (USB EHCI debug driver)
> >  - FLR support in xen-pciback.
> >  - Support wildcards in xen-pciback.hide=(*) argument parsing.
> >  - Xen EFI support,
> 
> Where?

That should have said Xen VESA EFI support. Thanks for spotting that.

> 
> > and keyboard shift status flag.
> >  - Late usage of Xen-SWIOTLB allowing PV PCI passthrough guest to boot without
> >    'iommu=soft' as an argument and late initialization of SWIOTLB.
> >  - Support more than 128GB in a PV guest.
> >  - Cleanups in the initial pagetable creation.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:31: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 1U6P7Z-0002jp-5i; Fri, 15 Feb 2013 17:30: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 1U6P7Y-0002jg-4h
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:30:48 +0000
Received: from [193.109.254.147:42925] by server-15.bemta-14.messagelabs.com
	id FB/5A-24599-7C07E115; Fri, 15 Feb 2013 17:30:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1360949444!8545138!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23118 invoked from network); 15 Feb 2013 17:30:46 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:30:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHUhWG029200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:30:44 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
	r1FHUgT9009559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:30:43 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
	r1FHUgZH007682; Fri, 15 Feb 2013 11:30:42 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:30:42 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 526E61C387B; Fri, 15 Feb 2013 12:30:41 -0500 (EST)
Date: Fri, 15 Feb 2013 12:30:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130215173041.GB10133@phenom.dumpdata.com>
References: <20130215162651.GB13775@phenom.dumpdata.com>
	<511E74C302000078000BEDB1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E74C302000078000BEDB1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: gavin.bowe@oracle.com, kurt.hackel@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] What went in Linux 3.6,
 3.7 and 3.8 from Xen standpoint.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 04:47:47PM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > v3.7:
> >  - Initial support for ARM working under Xen as both guest and initial 
> > domain.
> >  - Security fixes.
> >  - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
> >    gntdev driver, fix some pvops calls failing, Fixes in
> >    xen-[kbd|fb|blk|net|hvc]-backend to deal with CLOSED transition
> >  - Allow xen/privcmd to use v2 of MMAPBATCH command (and fixes for it)
> >  - Support Xen backends to work with paged out grants (meaning work with HVM
> >    guests that have its memory paged out)
> >  - Performance optimization in xen/privcmd for migrating guests.
> >  - Performance improvements when doing kdump for PVonHVM guests.
> >  - Xen DBGP driver added (USB EHCI debug driver)
> >  - FLR support in xen-pciback.
> >  - Support wildcards in xen-pciback.hide=(*) argument parsing.
> >  - Xen EFI support,
> 
> Where?

That should have said Xen VESA EFI support. Thanks for spotting that.

> 
> > and keyboard shift status flag.
> >  - Late usage of Xen-SWIOTLB allowing PV PCI passthrough guest to boot without
> >    'iommu=soft' as an argument and late initialization of SWIOTLB.
> >  - Support more than 128GB in a PV guest.
> >  - Cleanups in the initial pagetable creation.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:32:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6P8d-0002vk-Ka; Fri, 15 Feb 2013 17:31:55 +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 1U6P8c-0002vb-JW
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:31:54 +0000
Received: from [85.158.143.99:8415] by server-1.bemta-4.messagelabs.com id
	E8/59-08839-9017E115; Fri, 15 Feb 2013 17:31:53 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360949511!27239998!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29281 invoked from network); 15 Feb 2013 17:31:52 -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;
	15 Feb 2013 17:31:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7721360"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 17:31:51 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Fri, 15 Feb 2013
	12:31:50 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 15 Feb 2013 12:31:57 -0500
Thread-Topic: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough libxl
	support
Thread-Index: Ac4LgdWX/NylBXPnRcyo7O+nADwvWwAIHPuQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320CC2D98@FTLPMAILBOX02.citrite.net>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
	<1360935547.31407.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360935547.31407.61.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 0 of 3] [v3] HVM firmware passthrough libxl
 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

Wilco, thank you.

> -----Original Message-----
> From: Ian Campbell
> Sent: Friday, February 15, 2013 8:39 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough
> libxl support
> 
> On Wed, 2013-02-13 at 21:52 +0000, Ross Philipson wrote:
> > This patch series is a follow-up to the earlier HVM firmware
> passthrough
> > patch set. It introduces support in libxl for specifying and loading
> the
> > ACPI and SMBIOS firmware blobs that are passed to libxc.
> >
> > There are 3 patches in the series:
> > 01 - Switch xl to use the new xc_hvm_build() libxc API.
> > 02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
> >      Doc changes to the man page for xl.cfg describing the new params.
> > 03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> >
> > This version cleans up some of the logging and error handling in the
> > new firmware passthrough code.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> Acked + applied. All three patches had the same title here, please give
> patches unique and descriptive titles in the future. I retitled them as:
> 
> libxl: switch to using the new xc_hvm_build() libxc API.
> libxl: HVM firmware passthrough support
> libxl: Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:32:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17: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 1U6P8d-0002vk-Ka; Fri, 15 Feb 2013 17:31:55 +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 1U6P8c-0002vb-JW
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:31:54 +0000
Received: from [85.158.143.99:8415] by server-1.bemta-4.messagelabs.com id
	E8/59-08839-9017E115; Fri, 15 Feb 2013 17:31:53 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1360949511!27239998!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29281 invoked from network); 15 Feb 2013 17:31:52 -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;
	15 Feb 2013 17:31:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7721360"
Received: from accessns.citrite.net (HELO FTLPMAILMX01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 17:31:51 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Fri, 15 Feb 2013
	12:31:50 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 15 Feb 2013 12:31:57 -0500
Thread-Topic: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough libxl
	support
Thread-Index: Ac4LgdWX/NylBXPnRcyo7O+nADwvWwAIHPuQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320CC2D98@FTLPMAILBOX02.citrite.net>
References: <patchbomb.1360792341@colonel-moodus.bos.xci-test.com>
	<1360935547.31407.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360935547.31407.61.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 0 of 3] [v3] HVM firmware passthrough libxl
 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

Wilco, thank you.

> -----Original Message-----
> From: Ian Campbell
> Sent: Friday, February 15, 2013 8:39 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 3] [v3] HVM firmware passthrough
> libxl support
> 
> On Wed, 2013-02-13 at 21:52 +0000, Ross Philipson wrote:
> > This patch series is a follow-up to the earlier HVM firmware
> passthrough
> > patch set. It introduces support in libxl for specifying and loading
> the
> > ACPI and SMBIOS firmware blobs that are passed to libxc.
> >
> > There are 3 patches in the series:
> > 01 - Switch xl to use the new xc_hvm_build() libxc API.
> > 02 - Xen xl toolstack changes to load ACPI and SMBIOS firmware files.
> >      Doc changes to the man page for xl.cfg describing the new params.
> > 03 - Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> >
> > This version cleans up some of the logging and error handling in the
> > new firmware passthrough code.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
> 
> Acked + applied. All three patches had the same title here, please give
> patches unique and descriptive titles in the future. I retitled them as:
> 
> libxl: switch to using the new xc_hvm_build() libxc API.
> libxl: HVM firmware passthrough support
> libxl: Cleanup, use LOG* and GCSPRINTF macro in libxl_dom.c
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:35:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:35: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 1U6PBj-0003BQ-9B; Fri, 15 Feb 2013 17:35:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6PBg-0003BK-UT
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:35:05 +0000
Received: from [85.158.143.35:14192] by server-3.bemta-4.messagelabs.com id
	7A/7B-08920-8C17E115; Fri, 15 Feb 2013 17:35:04 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360949701!15754382!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27066 invoked from network); 15 Feb 2013 17:35:03 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:35:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHYwoc001855
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:34:59 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
	r1FHYvMM017916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:34:58 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
	r1FHYvv2002538; Fri, 15 Feb 2013 11:34:57 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:34:57 -0800
Message-ID: <511E71B2.7010007@oracle.com>
Date: Fri, 15 Feb 2013 12:34:42 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E3502000078000BED4A@nat28.tlf.novell.com>
In-Reply-To: <511E6E3502000078000BED4A@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] AMD IOMMU: don't BUG() when we don't
	have to
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/15/2013 11:19 AM, Jan Beulich wrote:
> find_iommu_for_device() can easily return NULL instead, as all of its
> callers are prepared for that.

This patch is obsoleted by the second patch ("[PATCH 2/4] AMD IOMMU: 
cover all functions of a device even if ACPI only tells us of func 0"), 
isn't it?

-boris

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for_device(
>   {
>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
>   
> -    BUG_ON ( bdf >= ivrs_bdf_entries );
> -    return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;
> +    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
> +                                                   : NULL;
>   }
>   
>   /*
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:35:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:35: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 1U6PBj-0003BQ-9B; Fri, 15 Feb 2013 17:35:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1U6PBg-0003BK-UT
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:35:05 +0000
Received: from [85.158.143.35:14192] by server-3.bemta-4.messagelabs.com id
	7A/7B-08920-8C17E115; Fri, 15 Feb 2013 17:35:04 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1360949701!15754382!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27066 invoked from network); 15 Feb 2013 17:35:03 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:35:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHYwoc001855
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:34:59 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
	r1FHYvMM017916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:34:58 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
	r1FHYvv2002538; Fri, 15 Feb 2013 11:34:57 -0600
Received: from [10.152.54.14] (/10.152.54.14)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:34:57 -0800
Message-ID: <511E71B2.7010007@oracle.com>
Date: Fri, 15 Feb 2013 12:34:42 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E3502000078000BED4A@nat28.tlf.novell.com>
In-Reply-To: <511E6E3502000078000BED4A@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] AMD IOMMU: don't BUG() when we don't
	have to
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/15/2013 11:19 AM, Jan Beulich wrote:
> find_iommu_for_device() can easily return NULL instead, as all of its
> callers are prepared for that.

This patch is obsoleted by the second patch ("[PATCH 2/4] AMD IOMMU: 
cover all functions of a device even if ACPI only tells us of func 0"), 
isn't it?

-boris

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -32,8 +32,8 @@ struct amd_iommu *find_iommu_for_device(
>   {
>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
>   
> -    BUG_ON ( bdf >= ivrs_bdf_entries );
> -    return ivrs_mappings ? ivrs_mappings[bdf].iommu : NULL;
> +    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
> +                                                   : NULL;
>   }
>   
>   /*
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:40:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6PGP-0003Ne-DS; Fri, 15 Feb 2013 17:39: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 1U6PGO-0003NY-7w
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:39:56 +0000
Received: from [85.158.143.35:36323] by server-2.bemta-4.messagelabs.com id
	4A/62-01597-BE27E115; Fri, 15 Feb 2013 17:39:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360949953!4829308!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28962 invoked from network); 15 Feb 2013 17:39:15 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:39:15 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHd7uL027796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:39: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
	r1FHd6tt012938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:39:07 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1FHd6CR010886; Fri, 15 Feb 2013 11:39:06 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:39:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CFF3A1C387B; Fri, 15 Feb 2013 12:39:04 -0500 (EST)
Date: Fri, 15 Feb 2013 12:39:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20130215173904.GC10133@phenom.dumpdata.com>
References: <20130215163451.GD13775@phenom.dumpdata.com>
	<511E761402000078000BEDD8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E761402000078000BEDD8@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: jinsong.liu@intel.com, xen-devel <xen-devel@lists.xen.org>,
	linux-kernel@vger.kernel.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Patches for v3.9 for the Linux 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 Fri, Feb 15, 2013 at 04:53:24PM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > I know that the PVH patches are not in the Xen tree. I am hoping that
> > at least the hypercalls _are_ OK with everybody so we can continue on
> > with this.
> 
> Please don't commit to anything that isn't in the hypervisor tree
> yet. IOW I'd like you to not push the PVH bits that use
> uncommitted hypervisor interfaces (anything preparatory of
> course is okay).

Hm, I believe the only one that was of contention was the 'PHYSDEVOP_map_iomem'
which Mukesh reverted.

The other one is the XENMEM_add_to_physmap_range, which Ian has for ARM.
That is the git commit b6eafa71fa87f4c831e9c2eac736e8ac20b3ea1c
in stable/pvh.v7 tree.

Oh, there is one change in this git commit b8724d6bd1c09e34b6c76b57d07ea4d3fbd8ed4c
..and that gets reverted in 68c5bb99d8b8abbf70b3380bed8eca69648193f5 (by Ian).

So from a hypercall perspective - Ian, is the XENMEM_add_to_physmap_range fully
baked ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:40:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6PGP-0003Ne-DS; Fri, 15 Feb 2013 17:39: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 1U6PGO-0003NY-7w
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 17:39:56 +0000
Received: from [85.158.143.35:36323] by server-2.bemta-4.messagelabs.com id
	4A/62-01597-BE27E115; Fri, 15 Feb 2013 17:39:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1360949953!4829308!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28962 invoked from network); 15 Feb 2013 17:39:15 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 17:39:15 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FHd7uL027796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 17:39: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
	r1FHd6tt012938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 17:39:07 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1FHd6CR010886; Fri, 15 Feb 2013 11:39:06 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 09:39:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CFF3A1C387B; Fri, 15 Feb 2013 12:39:04 -0500 (EST)
Date: Fri, 15 Feb 2013 12:39:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20130215173904.GC10133@phenom.dumpdata.com>
References: <20130215163451.GD13775@phenom.dumpdata.com>
	<511E761402000078000BEDD8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E761402000078000BEDD8@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: jinsong.liu@intel.com, xen-devel <xen-devel@lists.xen.org>,
	linux-kernel@vger.kernel.org, roger.pau@citrix.com
Subject: Re: [Xen-devel] Patches for v3.9 for the Linux 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 Fri, Feb 15, 2013 at 04:53:24PM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 17:34, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > I know that the PVH patches are not in the Xen tree. I am hoping that
> > at least the hypercalls _are_ OK with everybody so we can continue on
> > with this.
> 
> Please don't commit to anything that isn't in the hypervisor tree
> yet. IOW I'd like you to not push the PVH bits that use
> uncommitted hypervisor interfaces (anything preparatory of
> course is okay).

Hm, I believe the only one that was of contention was the 'PHYSDEVOP_map_iomem'
which Mukesh reverted.

The other one is the XENMEM_add_to_physmap_range, which Ian has for ARM.
That is the git commit b6eafa71fa87f4c831e9c2eac736e8ac20b3ea1c
in stable/pvh.v7 tree.

Oh, there is one change in this git commit b8724d6bd1c09e34b6c76b57d07ea4d3fbd8ed4c
..and that gets reverted in 68c5bb99d8b8abbf70b3380bed8eca69648193f5 (by Ian).

So from a hypercall perspective - Ian, is the XENMEM_add_to_physmap_range fully
baked ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 17:47:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:47: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 1U6PND-0003dL-AC; Fri, 15 Feb 2013 17:46: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 1U6PNB-0003dG-EO
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:46:57 +0000
Received: from [193.109.254.147:9071] by server-2.bemta-14.messagelabs.com id
	CA/3A-16277-0947E115; Fri, 15 Feb 2013 17:46:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360950412!8639573!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ4ODMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27349 invoked from network); 15 Feb 2013 17:46:53 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-27.messagelabs.com with SMTP;
	15 Feb 2013 17:46:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 15 Feb 2013 09:46:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,674,1355126400"; d="scan'208";a="286331259"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 15 Feb 2013 09:46:51 -0800
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:46:51 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:46:50 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 01:46:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>, "Rafael J. Wysocki"
	<rjw@sisk.pl>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHOC4wOTyBHFMmDoE2LH83uWllZQ5h7KthA
Date: Fri, 15 Feb 2013 17:46:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FC036@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<20130215132624.GB11777@phenom.dumpdata.com>
	<20130216005014.c8ce70e041f655d4c195c9fb@canb.auug.org.au>
	<2185970.g9YrD945My@vostro.rjw.lan>
	<20130216015200.1e58bec1aff05592ac2ae98f@canb.auug.org.au>
In-Reply-To: <20130216015200.1e58bec1aff05592ac2ae98f@canb.auug.org.au>
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>, "Wu,
	Fengguang" <fengguang.wu@intel.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stephen Rothwell wrote:
> Hi Rafael,
> 
> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
> wrote: 
>> 
>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
>>> 
>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote: 
>>>> 
>>>> Thank you. I keep on forgetting - but would it be OK for me to
>>>> take this patch in my tree? Or should I not since this is a new
>>>> functionality that Rafael is going to introduce in v3.9?
>>> 
>>> It is an API change in the pm tree that is not yet in Linus' tree.
>>> 
>>>> And if so, perhaps I should tack it on in my tree, once Rafael
>>>> does a git pull to Linus? Or just point Linus to this git commit?
>>> 
>>> You should point Linus at this patch if the pm tree is merged
>>> first, or 
>>> Rafael should do the same if the reverse happens.
>> 
>> Alternatively, Konrad can pull the acpi-scan branch containing the
>> changes in question from my tree into his tree and rebase the new
>> material on top of that.
> 
> Or pull the acpi-scan branch into his tree and use my conflict
> resolution in the resulting merge thus requiring no rebasing. 
> However, Linus likes to see such interactions, so it can be left up
> to when the latter of the two tress is merged by Linus.

Per my understanding, currently in git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git, it has included
1). 636458de36f1, 0cd6ac52b333, b8bd759acd05: 	from pm tree (Rafael), drop acpi_bus_add, update argument of acpi_bus_scan
2). 259f201cb7ea, 181232c249f0:			from xen tree (Jinsong), use acpi_bus_add
3). 36bd3c64bfe2					Stephen fix confliction of 1) and 2)
Currently these are only some compiling warning left, so the only thing need to do is to add my patch to fix compile warning (just sent out minutes ago) to the top of git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ?


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 Feb 15 17:47:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 17:47: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 1U6PND-0003dL-AC; Fri, 15 Feb 2013 17:46: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 1U6PNB-0003dG-EO
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 17:46:57 +0000
Received: from [193.109.254.147:9071] by server-2.bemta-14.messagelabs.com id
	CA/3A-16277-0947E115; Fri, 15 Feb 2013 17:46:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1360950412!8639573!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ4ODMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27349 invoked from network); 15 Feb 2013 17:46:53 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-27.messagelabs.com with SMTP;
	15 Feb 2013 17:46:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 15 Feb 2013 09:46:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,674,1355126400"; d="scan'208";a="286331259"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 15 Feb 2013 09:46:51 -0800
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:46:51 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 15 Feb 2013 09:46:50 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 01:46:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>, "Rafael J. Wysocki"
	<rjw@sisk.pl>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHOC4wOTyBHFMmDoE2LH83uWllZQ5h7KthA
Date: Fri, 15 Feb 2013 17:46:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FC036@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<20130215132624.GB11777@phenom.dumpdata.com>
	<20130216005014.c8ce70e041f655d4c195c9fb@canb.auug.org.au>
	<2185970.g9YrD945My@vostro.rjw.lan>
	<20130216015200.1e58bec1aff05592ac2ae98f@canb.auug.org.au>
In-Reply-To: <20130216015200.1e58bec1aff05592ac2ae98f@canb.auug.org.au>
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>, "Wu,
	Fengguang" <fengguang.wu@intel.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stephen Rothwell wrote:
> Hi Rafael,
> 
> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
> wrote: 
>> 
>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
>>> 
>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote: 
>>>> 
>>>> Thank you. I keep on forgetting - but would it be OK for me to
>>>> take this patch in my tree? Or should I not since this is a new
>>>> functionality that Rafael is going to introduce in v3.9?
>>> 
>>> It is an API change in the pm tree that is not yet in Linus' tree.
>>> 
>>>> And if so, perhaps I should tack it on in my tree, once Rafael
>>>> does a git pull to Linus? Or just point Linus to this git commit?
>>> 
>>> You should point Linus at this patch if the pm tree is merged
>>> first, or 
>>> Rafael should do the same if the reverse happens.
>> 
>> Alternatively, Konrad can pull the acpi-scan branch containing the
>> changes in question from my tree into his tree and rebase the new
>> material on top of that.
> 
> Or pull the acpi-scan branch into his tree and use my conflict
> resolution in the resulting merge thus requiring no rebasing. 
> However, Linus likes to see such interactions, so it can be left up
> to when the latter of the two tress is merged by Linus.

Per my understanding, currently in git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git, it has included
1). 636458de36f1, 0cd6ac52b333, b8bd759acd05: 	from pm tree (Rafael), drop acpi_bus_add, update argument of acpi_bus_scan
2). 259f201cb7ea, 181232c249f0:			from xen tree (Jinsong), use acpi_bus_add
3). 36bd3c64bfe2					Stephen fix confliction of 1) and 2)
Currently these are only some compiling warning left, so the only thing need to do is to add my patch to fix compile warning (just sent out minutes ago) to the top of git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ?


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 Feb 15 18:05:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:05: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 1U6PeY-0003zH-6L; Fri, 15 Feb 2013 18:04:54 +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 1U6PeX-0003zC-6I
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 18:04:53 +0000
Received: from [85.158.143.35:28365] by server-2.bemta-4.messagelabs.com id
	F4/22-01597-4C87E115; Fri, 15 Feb 2013 18:04:52 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360951446!13268381!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21868 invoked from network); 15 Feb 2013 18:04:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 18:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1525978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 18:04:06 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Fri, 15 Feb 2013 18:04:06 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 15 Feb 2013 19:03:01 +0100
Message-ID: <1360951381-26313-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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVwbGFjZSB0aGUgdXNlIG9mIGxsaXN0IHdpdGggbGlzdC4KCmxsaXN0X2Zvcl9lYWNoX2VudHJ5
X3NhZmUgY2FuIHRyaWdnZXIgYSBidWcgaW4gR0NDIDQuMSwgc28gaXQncyBiZXN0CnRvIHJlbW92
ZSBpdCBhbmQgdXNlIGEgZG91Ymx5IGxpbmtlZCBsaXN0LCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2
ZWx5CmluIHRoZSBrZXJuZWwgYWxyZWFkeS4KClNwZWNpZmljYWxseSB0aGlzIGJ1ZyBjYW4gYmUg
dHJpZ2dlcmVkIGJ5IGhvdC11bnBsdWdnaW5nIGEgZGlzaywKZWl0aGVyIGJ5IGRvaW5nIHhtIGJs
b2NrLWRldGFjaCBvciBieSBzYXZlL3Jlc3RvcmUgY3ljbGUuCgpCVUc6IHVuYWJsZSB0byBoYW5k
bGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZmZmZmZmZmZmZmZjAKSVA6IFs8ZmZmZmZm
ZmZhMDA0NzIyMz5dIGJsa2lmX2ZyZWUrMHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpUaGUgY3Jh
c2ggY2FsbCB0cmFjZSBpczoKCS4uLgpiYWRfYXJlYV9ub3NlbWFwaG9yZSsweDEzLzB4MjAKZG9f
cGFnZV9mYXVsdCsweDI1ZS8weDRiMApwYWdlX2ZhdWx0KzB4MjUvMHgzMAo/IGJsa2lmX2ZyZWUr
MHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpibGtmcm9udF9yZXN1bWUrMHg0Ni8weGEwIFt4ZW5f
YmxrZnJvbnRdCnhlbmJ1c19kZXZfcmVzdW1lKzB4NmMvMHgxNDAKcG1fb3ArMHgxOTIvMHgxYjAK
ZGV2aWNlX3Jlc3VtZSsweDgyLzB4MWUwCmRwbV9yZXN1bWUrMHhjOS8weDFhMApkcG1fcmVzdW1l
X2VuZCsweDE1LzB4MzAKZG9fc3VzcGVuZCsweDExNy8weDFlMAoKV2hlbiBkcmlsbGluZyBkb3du
IHRvIHRoZSBhc3NlbWJsZXIgY29kZSwgb24gbmV3ZXIgR0NDIGl0IGRvZXMKLkwyOToKICAgICAg
ICBjbXBxICAgICQtMTYsICVyMTIgICAgICAjLCBwZXJzaXN0ZW50X2dudCBjaGVjawogICAgICAg
IGplICAgICAgLkwzMCAgICAJIywgb3V0IG9mIHRoZSBsb29wCi5MMjU6CgkuLi4gY29kZSBpbiB0
aGUgbG9vcAogICAgICAgIHRlc3RxICAgJXIxMywgJXIxMyAgICAgICMgbgogICAgICAgIGplICAg
ICAgLkwyOSAgICAJIywgYmFjayB0byB0aGUgdG9wIG9mIHRoZSBsb29wCiAgICAgICAgY21wcSAg
ICAkLTE2LCAlcjEyICAgICAgIywgcGVyc2lzdGVudF9nbnQgY2hlY2sKICAgICAgICBtb3ZxICAg
IDE2KCVyMTIpLCAlcjEzICAjIDx2YXJpYWJsZT4ubm9kZS5uZXh0LCBuCiAgICAgICAgam5lICAg
ICAuTDI1ICAgIAkjLAliYWNrIHRvIHRoZSB0b3Agb2YgdGhlIGxvb3AKLkwzMDoKCldoaWxlIG9u
IEdDQyA0LjEsIGl0IGlzOgpMNzg6CgkuLi4gY29kZSBpbiB0aGUgbG9vcAoJdGVzdHEgICAlcjEz
LCAlcjEzICAgICAgIyBuCiAgICAgICAgamUgICAgICAuTDc4ICAgICMsCWJhY2sgdG8gdGhlIHRv
cCBvZiB0aGUgbG9vcAogICAgICAgIG1vdnEgICAgMTYoJXJieCksICVyMTMgICMgPHZhcmlhYmxl
Pi5ub2RlLm5leHQsIG4KICAgICAgICBqbXAgICAgIC5MNzggICAgIywJYmFjayB0byB0aGUgdG9w
IG9mIHRoZSBsb29wCgpXaGljaCBiYXNpY2FsbHkgbWVhbnMgdGhhdCB0aGUgZXhpdCBsb29wIGNv
bmRpdGlvbiBpbnN0ZWFkIG9mCmJlaW5nOgoKCSYocG9zKS0+bWVtYmVyICE9IE5VTEw7CgppczoK
CTsKCndoaWNoIG1ha2VzIHRoZSBsb29wIHVuYm91bmQuCgpTaW5jZSB3ZSBhbHdheXMgbWFuaXB1
bGF0ZSB0aGUgbGlzdCB3aGlsZSBob2xkaW5nIHRoZSBpb19sb2NrLCB0aGVyZSdzCm5vIG5lZWQg
Zm9yIGFkZGl0aW9uYWwgbG9ja2luZyAobGxpc3QgdXNlZCBwcmV2aW91c2x5IGlzIHNhZmUgdG8g
dXNlCmNvbmN1cnJlbnRseSB3aXRob3V0IGFkZGl0aW9uYWwgbG9ja2luZykuCgpTaG91bGQgYmUg
YmFja3BvcnRlZCB0byAzLjggc3RhYmxlLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CltQYXJ0IG9mIHRoZSBkZXNjcmlwdGlvbl0KU2lnbmVk
LW9mZi1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpD
YzogeGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9u
dC5jIHwgICAyNyArKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvbGludXgvbGxp
c3QuaCAgICAgICAgfCAgIDI1IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDIgZmlsZXMgY2hh
bmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgMzggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJp
dmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMK
aW5kZXggMTEwNDNjMS4uMDFiOTFhNSAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxr
ZnJvbnQuYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jCkBAIC00NCw3ICs0NCw3
IEBACiAjaW5jbHVkZSA8bGludXgvbXV0ZXguaD4KICNpbmNsdWRlIDxsaW51eC9zY2F0dGVybGlz
dC5oPgogI2luY2x1ZGUgPGxpbnV4L2JpdG1hcC5oPgotI2luY2x1ZGUgPGxpbnV4L2xsaXN0Lmg+
CisjaW5jbHVkZSA8bGludXgvbGlzdC5oPgogCiAjaW5jbHVkZSA8eGVuL3hlbi5oPgogI2luY2x1
ZGUgPHhlbi94ZW5idXMuaD4KQEAgLTY4LDcgKzY4LDcgQEAgZW51bSBibGtpZl9zdGF0ZSB7CiBz
dHJ1Y3QgZ3JhbnQgewogCWdyYW50X3JlZl90IGdyZWY7CiAJdW5zaWduZWQgbG9uZyBwZm47Ci0J
c3RydWN0IGxsaXN0X25vZGUgbm9kZTsKKwlzdHJ1Y3QgbGlzdF9oZWFkIG5vZGU7CiB9OwogCiBz
dHJ1Y3QgYmxrX3NoYWRvdyB7CkBAIC0xMDUsNyArMTA1LDcgQEAgc3RydWN0IGJsa2Zyb250X2lu
Zm8KIAlzdHJ1Y3Qgd29ya19zdHJ1Y3Qgd29yazsKIAlzdHJ1Y3QgZ250dGFiX2ZyZWVfY2FsbGJh
Y2sgY2FsbGJhY2s7CiAJc3RydWN0IGJsa19zaGFkb3cgc2hhZG93W0JMS19SSU5HX1NJWkVdOwot
CXN0cnVjdCBsbGlzdF9oZWFkIHBlcnNpc3RlbnRfZ250czsKKwlzdHJ1Y3QgbGlzdF9oZWFkIHBl
cnNpc3RlbnRfZ250czsKIAl1bnNpZ25lZCBpbnQgcGVyc2lzdGVudF9nbnRzX2M7CiAJdW5zaWdu
ZWQgbG9uZyBzaGFkb3dfZnJlZTsKIAl1bnNpZ25lZCBpbnQgZmVhdHVyZV9mbHVzaDsKQEAgLTM3
MSwxMCArMzcxLDExIEBAIHN0YXRpYyBpbnQgYmxraWZfcXVldWVfcmVxdWVzdChzdHJ1Y3QgcmVx
dWVzdCAqcmVxKQogCQkJbHNlY3QgPSBmc2VjdCArIChzZy0+bGVuZ3RoID4+IDkpIC0gMTsKIAog
CQkJaWYgKGluZm8tPnBlcnNpc3RlbnRfZ250c19jKSB7Ci0JCQkJQlVHX09OKGxsaXN0X2VtcHR5
KCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpKTsKLQkJCQlnbnRfbGlzdF9lbnRyeSA9IGxsaXN0X2Vu
dHJ5KAotCQkJCQlsbGlzdF9kZWxfZmlyc3QoJmluZm8tPnBlcnNpc3RlbnRfZ250cyksCi0JCQkJ
CXN0cnVjdCBncmFudCwgbm9kZSk7CisJCQkJQlVHX09OKGxpc3RfZW1wdHkoJmluZm8tPnBlcnNp
c3RlbnRfZ250cykpOworCQkJCWdudF9saXN0X2VudHJ5ID0gbGlzdF9maXJzdF9lbnRyeSgKKwkJ
CQkgICAgICAgICAgICAgICAgICAgICAgJmluZm8tPnBlcnNpc3RlbnRfZ250cywKKwkJCQkgICAg
ICAgICAgICAgICAgICAgICAgc3RydWN0IGdyYW50LCBub2RlKTsKKwkJCQlsaXN0X2RlbCgmZ250
X2xpc3RfZW50cnktPm5vZGUpOwogCiAJCQkJcmVmID0gZ250X2xpc3RfZW50cnktPmdyZWY7CiAJ
CQkJYnVmZmVyX21mbiA9IHBmbl90b19tZm4oZ250X2xpc3RfZW50cnktPnBmbik7CkBAIC03OTAs
OSArNzkxLDggQEAgc3RhdGljIHZvaWQgYmxraWZfcmVzdGFydF9xdWV1ZShzdHJ1Y3Qgd29ya19z
dHJ1Y3QgKndvcmspCiAKIHN0YXRpYyB2b2lkIGJsa2lmX2ZyZWUoc3RydWN0IGJsa2Zyb250X2lu
Zm8gKmluZm8sIGludCBzdXNwZW5kKQogewotCXN0cnVjdCBsbGlzdF9ub2RlICphbGxfZ250czsK
IAlzdHJ1Y3QgZ3JhbnQgKnBlcnNpc3RlbnRfZ250OwotCXN0cnVjdCBsbGlzdF9ub2RlICpuOwor
CXN0cnVjdCBncmFudCAqbjsKIAogCS8qIFByZXZlbnQgbmV3IHJlcXVlc3RzIGJlaW5nIGlzc3Vl
ZCB1bnRpbCB3ZSBmaXggdGhpbmdzIHVwLiAqLwogCXNwaW5fbG9ja19pcnEoJmluZm8tPmlvX2xv
Y2spOwpAQCAtODA0LDggKzgwNCw5IEBAIHN0YXRpYyB2b2lkIGJsa2lmX2ZyZWUoc3RydWN0IGJs
a2Zyb250X2luZm8gKmluZm8sIGludCBzdXNwZW5kKQogCiAJLyogUmVtb3ZlIGFsbCBwZXJzaXN0
ZW50IGdyYW50cyAqLwogCWlmIChpbmZvLT5wZXJzaXN0ZW50X2dudHNfYykgewotCQlhbGxfZ250
cyA9IGxsaXN0X2RlbF9hbGwoJmluZm8tPnBlcnNpc3RlbnRfZ250cyk7Ci0JCWxsaXN0X2Zvcl9l
YWNoX2VudHJ5X3NhZmUocGVyc2lzdGVudF9nbnQsIG4sIGFsbF9nbnRzLCBub2RlKSB7CisJCWxp
c3RfZm9yX2VhY2hfZW50cnlfc2FmZShwZXJzaXN0ZW50X2dudCwgbiwKKwkJICAgICAgICAgICAg
ICAgICAgICAgICAgICZpbmZvLT5wZXJzaXN0ZW50X2dudHMsIG5vZGUpIHsKKwkJCWxpc3RfZGVs
KCZwZXJzaXN0ZW50X2dudC0+bm9kZSk7CiAJCQlnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzKHBl
cnNpc3RlbnRfZ250LT5ncmVmLCAwLCAwVUwpOwogCQkJX19mcmVlX3BhZ2UocGZuX3RvX3BhZ2Uo
cGVyc2lzdGVudF9nbnQtPnBmbikpOwogCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOwpAQCAtODY4
LDcgKzg2OSw3IEBAIHN0YXRpYyB2b2lkIGJsa2lmX2NvbXBsZXRpb24oc3RydWN0IGJsa19zaGFk
b3cgKnMsIHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvLAogCX0KIAkvKiBBZGQgdGhlIHBlcnNp
c3RlbnQgZ3JhbnQgaW50byB0aGUgbGlzdCBvZiBmcmVlIGdyYW50cyAqLwogCWZvciAoaSA9IDA7
IGkgPCBzLT5yZXEudS5ydy5ucl9zZWdtZW50czsgaSsrKSB7Ci0JCWxsaXN0X2FkZCgmcy0+Z3Jh
bnRzX3VzZWRbaV0tPm5vZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOworCQlsaXN0X2FkZCgm
cy0+Z3JhbnRzX3VzZWRbaV0tPm5vZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCQlpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYysrOwogCX0KIH0KQEAgLTExNjQsNyArMTE2NSw3IEBAIHN0YXRp
YyBpbnQgYmxrZnJvbnRfcHJvYmUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwKIAlzcGluX2xv
Y2tfaW5pdCgmaW5mby0+aW9fbG9jayk7CiAJaW5mby0+eGJkZXYgPSBkZXY7CiAJaW5mby0+dmRl
dmljZSA9IHZkZXZpY2U7Ci0JaW5pdF9sbGlzdF9oZWFkKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMp
OworCUlOSVRfTElTVF9IRUFEKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCWluZm8tPnBlcnNp
c3RlbnRfZ250c19jID0gMDsKIAlpbmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFURV9ESVNDT05O
RUNURUQ7CiAJSU5JVF9XT1JLKCZpbmZvLT53b3JrLCBibGtpZl9yZXN0YXJ0X3F1ZXVlKTsKZGlm
ZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGxpc3QuaCBiL2luY2x1ZGUvbGludXgvbGxpc3QuaApp
bmRleCBkMGFiOThmLi5hNTE5OWY2IDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L2xsaXN0LmgK
KysrIGIvaW5jbHVkZS9saW51eC9sbGlzdC5oCkBAIC0xMjUsMzEgKzEyNSw2IEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBpbml0X2xsaXN0X2hlYWQoc3RydWN0IGxsaXN0X2hlYWQgKmxpc3QpCiAJICAg
ICAocG9zKSA9IGxsaXN0X2VudHJ5KChwb3MpLT5tZW1iZXIubmV4dCwgdHlwZW9mKCoocG9zKSks
IG1lbWJlcikpCiAKIC8qKgotICogbGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZSAtIGl0ZXJhdGUg
c2FmZWx5IGFnYWluc3QgcmVtb3ZlIG92ZXIgc29tZSBlbnRyaWVzCi0gKiBvZiBsb2NrLWxlc3Mg
bGlzdCBvZiBnaXZlbiB0eXBlLgotICogQHBvczoJdGhlIHR5cGUgKiB0byB1c2UgYXMgYSBsb29w
IGN1cnNvci4KLSAqIEBuOgkJYW5vdGhlciB0eXBlICogdG8gdXNlIGFzIGEgdGVtcG9yYXJ5IHN0
b3JhZ2UuCi0gKiBAbm9kZToJdGhlIGZpc3QgZW50cnkgb2YgZGVsZXRlZCBsaXN0IGVudHJpZXMu
Ci0gKiBAbWVtYmVyOgl0aGUgbmFtZSBvZiB0aGUgbGxpc3Rfbm9kZSB3aXRoIHRoZSBzdHJ1Y3Qu
Ci0gKgotICogSW4gZ2VuZXJhbCwgc29tZSBlbnRyaWVzIG9mIHRoZSBsb2NrLWxlc3MgbGlzdCBj
YW4gYmUgdHJhdmVyc2VkCi0gKiBzYWZlbHkgb25seSBhZnRlciBiZWluZyByZW1vdmVkIGZyb20g
bGlzdCwgc28gc3RhcnQgd2l0aCBhbiBlbnRyeQotICogaW5zdGVhZCBvZiBsaXN0IGhlYWQuIFRo
aXMgdmFyaWFudCBhbGxvd3MgcmVtb3ZhbCBvZiBlbnRyaWVzCi0gKiBhcyB3ZSBpdGVyYXRlLgot
ICoKLSAqIElmIGJlaW5nIHVzZWQgb24gZW50cmllcyBkZWxldGVkIGZyb20gbG9jay1sZXNzIGxp
c3QgZGlyZWN0bHksIHRoZQotICogdHJhdmVyc2Ugb3JkZXIgaXMgZnJvbSB0aGUgbmV3ZXN0IHRv
IHRoZSBvbGRlc3QgYWRkZWQgZW50cnkuICBJZgotICogeW91IHdhbnQgdG8gdHJhdmVyc2UgZnJv
bSB0aGUgb2xkZXN0IHRvIHRoZSBuZXdlc3QsIHlvdSBtdXN0Ci0gKiByZXZlcnNlIHRoZSBvcmRl
ciBieSB5b3Vyc2VsZiBiZWZvcmUgdHJhdmVyc2luZy4KLSAqLwotI2RlZmluZSBsbGlzdF9mb3Jf
ZWFjaF9lbnRyeV9zYWZlKHBvcywgbiwgbm9kZSwgbWVtYmVyKQkJXAotCWZvciAoKHBvcykgPSBs
bGlzdF9lbnRyeSgobm9kZSksIHR5cGVvZigqKHBvcykpLCBtZW1iZXIpLAlcCi0JICAgICAobikg
PSAocG9zKS0+bWVtYmVyLm5leHQ7CQkJCQlcCi0JICAgICAmKHBvcyktPm1lbWJlciAhPSBOVUxM
OwkJCQkJXAotCSAgICAgKHBvcykgPSBsbGlzdF9lbnRyeShuLCB0eXBlb2YoKihwb3MpKSwgbWVt
YmVyKSwJCVwKLQkgICAgIChuKSA9ICgmKHBvcyktPm1lbWJlciAhPSBOVUxMKSA/IChwb3MpLT5t
ZW1iZXIubmV4dCA6IE5VTEwpCi0KLS8qKgogICogbGxpc3RfZW1wdHkgLSB0ZXN0cyB3aGV0aGVy
IGEgbG9jay1sZXNzIGxpc3QgaXMgZW1wdHkKICAqIEBoZWFkOgl0aGUgbGlzdCB0byB0ZXN0CiAg
KgotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Feb 15 18:05:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:05: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 1U6PeY-0003zH-6L; Fri, 15 Feb 2013 18:04:54 +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 1U6PeX-0003zC-6I
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 18:04:53 +0000
Received: from [85.158.143.35:28365] by server-2.bemta-4.messagelabs.com id
	F4/22-01597-4C87E115; Fri, 15 Feb 2013 18:04:52 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360951446!13268381!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21868 invoked from network); 15 Feb 2013 18:04:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 18:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="1525978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 18:04:06 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Fri, 15 Feb 2013 18:04:06 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>
Date: Fri, 15 Feb 2013 19:03:01 +0100
Message-ID: <1360951381-26313-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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVwbGFjZSB0aGUgdXNlIG9mIGxsaXN0IHdpdGggbGlzdC4KCmxsaXN0X2Zvcl9lYWNoX2VudHJ5
X3NhZmUgY2FuIHRyaWdnZXIgYSBidWcgaW4gR0NDIDQuMSwgc28gaXQncyBiZXN0CnRvIHJlbW92
ZSBpdCBhbmQgdXNlIGEgZG91Ymx5IGxpbmtlZCBsaXN0LCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2
ZWx5CmluIHRoZSBrZXJuZWwgYWxyZWFkeS4KClNwZWNpZmljYWxseSB0aGlzIGJ1ZyBjYW4gYmUg
dHJpZ2dlcmVkIGJ5IGhvdC11bnBsdWdnaW5nIGEgZGlzaywKZWl0aGVyIGJ5IGRvaW5nIHhtIGJs
b2NrLWRldGFjaCBvciBieSBzYXZlL3Jlc3RvcmUgY3ljbGUuCgpCVUc6IHVuYWJsZSB0byBoYW5k
bGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZmZmZmZmZmZmZmZjAKSVA6IFs8ZmZmZmZm
ZmZhMDA0NzIyMz5dIGJsa2lmX2ZyZWUrMHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpUaGUgY3Jh
c2ggY2FsbCB0cmFjZSBpczoKCS4uLgpiYWRfYXJlYV9ub3NlbWFwaG9yZSsweDEzLzB4MjAKZG9f
cGFnZV9mYXVsdCsweDI1ZS8weDRiMApwYWdlX2ZhdWx0KzB4MjUvMHgzMAo/IGJsa2lmX2ZyZWUr
MHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpibGtmcm9udF9yZXN1bWUrMHg0Ni8weGEwIFt4ZW5f
YmxrZnJvbnRdCnhlbmJ1c19kZXZfcmVzdW1lKzB4NmMvMHgxNDAKcG1fb3ArMHgxOTIvMHgxYjAK
ZGV2aWNlX3Jlc3VtZSsweDgyLzB4MWUwCmRwbV9yZXN1bWUrMHhjOS8weDFhMApkcG1fcmVzdW1l
X2VuZCsweDE1LzB4MzAKZG9fc3VzcGVuZCsweDExNy8weDFlMAoKV2hlbiBkcmlsbGluZyBkb3du
IHRvIHRoZSBhc3NlbWJsZXIgY29kZSwgb24gbmV3ZXIgR0NDIGl0IGRvZXMKLkwyOToKICAgICAg
ICBjbXBxICAgICQtMTYsICVyMTIgICAgICAjLCBwZXJzaXN0ZW50X2dudCBjaGVjawogICAgICAg
IGplICAgICAgLkwzMCAgICAJIywgb3V0IG9mIHRoZSBsb29wCi5MMjU6CgkuLi4gY29kZSBpbiB0
aGUgbG9vcAogICAgICAgIHRlc3RxICAgJXIxMywgJXIxMyAgICAgICMgbgogICAgICAgIGplICAg
ICAgLkwyOSAgICAJIywgYmFjayB0byB0aGUgdG9wIG9mIHRoZSBsb29wCiAgICAgICAgY21wcSAg
ICAkLTE2LCAlcjEyICAgICAgIywgcGVyc2lzdGVudF9nbnQgY2hlY2sKICAgICAgICBtb3ZxICAg
IDE2KCVyMTIpLCAlcjEzICAjIDx2YXJpYWJsZT4ubm9kZS5uZXh0LCBuCiAgICAgICAgam5lICAg
ICAuTDI1ICAgIAkjLAliYWNrIHRvIHRoZSB0b3Agb2YgdGhlIGxvb3AKLkwzMDoKCldoaWxlIG9u
IEdDQyA0LjEsIGl0IGlzOgpMNzg6CgkuLi4gY29kZSBpbiB0aGUgbG9vcAoJdGVzdHEgICAlcjEz
LCAlcjEzICAgICAgIyBuCiAgICAgICAgamUgICAgICAuTDc4ICAgICMsCWJhY2sgdG8gdGhlIHRv
cCBvZiB0aGUgbG9vcAogICAgICAgIG1vdnEgICAgMTYoJXJieCksICVyMTMgICMgPHZhcmlhYmxl
Pi5ub2RlLm5leHQsIG4KICAgICAgICBqbXAgICAgIC5MNzggICAgIywJYmFjayB0byB0aGUgdG9w
IG9mIHRoZSBsb29wCgpXaGljaCBiYXNpY2FsbHkgbWVhbnMgdGhhdCB0aGUgZXhpdCBsb29wIGNv
bmRpdGlvbiBpbnN0ZWFkIG9mCmJlaW5nOgoKCSYocG9zKS0+bWVtYmVyICE9IE5VTEw7CgppczoK
CTsKCndoaWNoIG1ha2VzIHRoZSBsb29wIHVuYm91bmQuCgpTaW5jZSB3ZSBhbHdheXMgbWFuaXB1
bGF0ZSB0aGUgbGlzdCB3aGlsZSBob2xkaW5nIHRoZSBpb19sb2NrLCB0aGVyZSdzCm5vIG5lZWQg
Zm9yIGFkZGl0aW9uYWwgbG9ja2luZyAobGxpc3QgdXNlZCBwcmV2aW91c2x5IGlzIHNhZmUgdG8g
dXNlCmNvbmN1cnJlbnRseSB3aXRob3V0IGFkZGl0aW9uYWwgbG9ja2luZykuCgpTaG91bGQgYmUg
YmFja3BvcnRlZCB0byAzLjggc3RhYmxlLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CltQYXJ0IG9mIHRoZSBkZXNjcmlwdGlvbl0KU2lnbmVk
LW9mZi1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpD
YzogeGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9u
dC5jIHwgICAyNyArKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0KIGluY2x1ZGUvbGludXgvbGxp
c3QuaCAgICAgICAgfCAgIDI1IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDIgZmlsZXMgY2hh
bmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgMzggZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJp
dmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMK
aW5kZXggMTEwNDNjMS4uMDFiOTFhNSAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxr
ZnJvbnQuYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jCkBAIC00NCw3ICs0NCw3
IEBACiAjaW5jbHVkZSA8bGludXgvbXV0ZXguaD4KICNpbmNsdWRlIDxsaW51eC9zY2F0dGVybGlz
dC5oPgogI2luY2x1ZGUgPGxpbnV4L2JpdG1hcC5oPgotI2luY2x1ZGUgPGxpbnV4L2xsaXN0Lmg+
CisjaW5jbHVkZSA8bGludXgvbGlzdC5oPgogCiAjaW5jbHVkZSA8eGVuL3hlbi5oPgogI2luY2x1
ZGUgPHhlbi94ZW5idXMuaD4KQEAgLTY4LDcgKzY4LDcgQEAgZW51bSBibGtpZl9zdGF0ZSB7CiBz
dHJ1Y3QgZ3JhbnQgewogCWdyYW50X3JlZl90IGdyZWY7CiAJdW5zaWduZWQgbG9uZyBwZm47Ci0J
c3RydWN0IGxsaXN0X25vZGUgbm9kZTsKKwlzdHJ1Y3QgbGlzdF9oZWFkIG5vZGU7CiB9OwogCiBz
dHJ1Y3QgYmxrX3NoYWRvdyB7CkBAIC0xMDUsNyArMTA1LDcgQEAgc3RydWN0IGJsa2Zyb250X2lu
Zm8KIAlzdHJ1Y3Qgd29ya19zdHJ1Y3Qgd29yazsKIAlzdHJ1Y3QgZ250dGFiX2ZyZWVfY2FsbGJh
Y2sgY2FsbGJhY2s7CiAJc3RydWN0IGJsa19zaGFkb3cgc2hhZG93W0JMS19SSU5HX1NJWkVdOwot
CXN0cnVjdCBsbGlzdF9oZWFkIHBlcnNpc3RlbnRfZ250czsKKwlzdHJ1Y3QgbGlzdF9oZWFkIHBl
cnNpc3RlbnRfZ250czsKIAl1bnNpZ25lZCBpbnQgcGVyc2lzdGVudF9nbnRzX2M7CiAJdW5zaWdu
ZWQgbG9uZyBzaGFkb3dfZnJlZTsKIAl1bnNpZ25lZCBpbnQgZmVhdHVyZV9mbHVzaDsKQEAgLTM3
MSwxMCArMzcxLDExIEBAIHN0YXRpYyBpbnQgYmxraWZfcXVldWVfcmVxdWVzdChzdHJ1Y3QgcmVx
dWVzdCAqcmVxKQogCQkJbHNlY3QgPSBmc2VjdCArIChzZy0+bGVuZ3RoID4+IDkpIC0gMTsKIAog
CQkJaWYgKGluZm8tPnBlcnNpc3RlbnRfZ250c19jKSB7Ci0JCQkJQlVHX09OKGxsaXN0X2VtcHR5
KCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpKTsKLQkJCQlnbnRfbGlzdF9lbnRyeSA9IGxsaXN0X2Vu
dHJ5KAotCQkJCQlsbGlzdF9kZWxfZmlyc3QoJmluZm8tPnBlcnNpc3RlbnRfZ250cyksCi0JCQkJ
CXN0cnVjdCBncmFudCwgbm9kZSk7CisJCQkJQlVHX09OKGxpc3RfZW1wdHkoJmluZm8tPnBlcnNp
c3RlbnRfZ250cykpOworCQkJCWdudF9saXN0X2VudHJ5ID0gbGlzdF9maXJzdF9lbnRyeSgKKwkJ
CQkgICAgICAgICAgICAgICAgICAgICAgJmluZm8tPnBlcnNpc3RlbnRfZ250cywKKwkJCQkgICAg
ICAgICAgICAgICAgICAgICAgc3RydWN0IGdyYW50LCBub2RlKTsKKwkJCQlsaXN0X2RlbCgmZ250
X2xpc3RfZW50cnktPm5vZGUpOwogCiAJCQkJcmVmID0gZ250X2xpc3RfZW50cnktPmdyZWY7CiAJ
CQkJYnVmZmVyX21mbiA9IHBmbl90b19tZm4oZ250X2xpc3RfZW50cnktPnBmbik7CkBAIC03OTAs
OSArNzkxLDggQEAgc3RhdGljIHZvaWQgYmxraWZfcmVzdGFydF9xdWV1ZShzdHJ1Y3Qgd29ya19z
dHJ1Y3QgKndvcmspCiAKIHN0YXRpYyB2b2lkIGJsa2lmX2ZyZWUoc3RydWN0IGJsa2Zyb250X2lu
Zm8gKmluZm8sIGludCBzdXNwZW5kKQogewotCXN0cnVjdCBsbGlzdF9ub2RlICphbGxfZ250czsK
IAlzdHJ1Y3QgZ3JhbnQgKnBlcnNpc3RlbnRfZ250OwotCXN0cnVjdCBsbGlzdF9ub2RlICpuOwor
CXN0cnVjdCBncmFudCAqbjsKIAogCS8qIFByZXZlbnQgbmV3IHJlcXVlc3RzIGJlaW5nIGlzc3Vl
ZCB1bnRpbCB3ZSBmaXggdGhpbmdzIHVwLiAqLwogCXNwaW5fbG9ja19pcnEoJmluZm8tPmlvX2xv
Y2spOwpAQCAtODA0LDggKzgwNCw5IEBAIHN0YXRpYyB2b2lkIGJsa2lmX2ZyZWUoc3RydWN0IGJs
a2Zyb250X2luZm8gKmluZm8sIGludCBzdXNwZW5kKQogCiAJLyogUmVtb3ZlIGFsbCBwZXJzaXN0
ZW50IGdyYW50cyAqLwogCWlmIChpbmZvLT5wZXJzaXN0ZW50X2dudHNfYykgewotCQlhbGxfZ250
cyA9IGxsaXN0X2RlbF9hbGwoJmluZm8tPnBlcnNpc3RlbnRfZ250cyk7Ci0JCWxsaXN0X2Zvcl9l
YWNoX2VudHJ5X3NhZmUocGVyc2lzdGVudF9nbnQsIG4sIGFsbF9nbnRzLCBub2RlKSB7CisJCWxp
c3RfZm9yX2VhY2hfZW50cnlfc2FmZShwZXJzaXN0ZW50X2dudCwgbiwKKwkJICAgICAgICAgICAg
ICAgICAgICAgICAgICZpbmZvLT5wZXJzaXN0ZW50X2dudHMsIG5vZGUpIHsKKwkJCWxpc3RfZGVs
KCZwZXJzaXN0ZW50X2dudC0+bm9kZSk7CiAJCQlnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzKHBl
cnNpc3RlbnRfZ250LT5ncmVmLCAwLCAwVUwpOwogCQkJX19mcmVlX3BhZ2UocGZuX3RvX3BhZ2Uo
cGVyc2lzdGVudF9nbnQtPnBmbikpOwogCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOwpAQCAtODY4
LDcgKzg2OSw3IEBAIHN0YXRpYyB2b2lkIGJsa2lmX2NvbXBsZXRpb24oc3RydWN0IGJsa19zaGFk
b3cgKnMsIHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvLAogCX0KIAkvKiBBZGQgdGhlIHBlcnNp
c3RlbnQgZ3JhbnQgaW50byB0aGUgbGlzdCBvZiBmcmVlIGdyYW50cyAqLwogCWZvciAoaSA9IDA7
IGkgPCBzLT5yZXEudS5ydy5ucl9zZWdtZW50czsgaSsrKSB7Ci0JCWxsaXN0X2FkZCgmcy0+Z3Jh
bnRzX3VzZWRbaV0tPm5vZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOworCQlsaXN0X2FkZCgm
cy0+Z3JhbnRzX3VzZWRbaV0tPm5vZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCQlpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYysrOwogCX0KIH0KQEAgLTExNjQsNyArMTE2NSw3IEBAIHN0YXRp
YyBpbnQgYmxrZnJvbnRfcHJvYmUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwKIAlzcGluX2xv
Y2tfaW5pdCgmaW5mby0+aW9fbG9jayk7CiAJaW5mby0+eGJkZXYgPSBkZXY7CiAJaW5mby0+dmRl
dmljZSA9IHZkZXZpY2U7Ci0JaW5pdF9sbGlzdF9oZWFkKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMp
OworCUlOSVRfTElTVF9IRUFEKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCWluZm8tPnBlcnNp
c3RlbnRfZ250c19jID0gMDsKIAlpbmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFURV9ESVNDT05O
RUNURUQ7CiAJSU5JVF9XT1JLKCZpbmZvLT53b3JrLCBibGtpZl9yZXN0YXJ0X3F1ZXVlKTsKZGlm
ZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGxpc3QuaCBiL2luY2x1ZGUvbGludXgvbGxpc3QuaApp
bmRleCBkMGFiOThmLi5hNTE5OWY2IDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L2xsaXN0LmgK
KysrIGIvaW5jbHVkZS9saW51eC9sbGlzdC5oCkBAIC0xMjUsMzEgKzEyNSw2IEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBpbml0X2xsaXN0X2hlYWQoc3RydWN0IGxsaXN0X2hlYWQgKmxpc3QpCiAJICAg
ICAocG9zKSA9IGxsaXN0X2VudHJ5KChwb3MpLT5tZW1iZXIubmV4dCwgdHlwZW9mKCoocG9zKSks
IG1lbWJlcikpCiAKIC8qKgotICogbGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZSAtIGl0ZXJhdGUg
c2FmZWx5IGFnYWluc3QgcmVtb3ZlIG92ZXIgc29tZSBlbnRyaWVzCi0gKiBvZiBsb2NrLWxlc3Mg
bGlzdCBvZiBnaXZlbiB0eXBlLgotICogQHBvczoJdGhlIHR5cGUgKiB0byB1c2UgYXMgYSBsb29w
IGN1cnNvci4KLSAqIEBuOgkJYW5vdGhlciB0eXBlICogdG8gdXNlIGFzIGEgdGVtcG9yYXJ5IHN0
b3JhZ2UuCi0gKiBAbm9kZToJdGhlIGZpc3QgZW50cnkgb2YgZGVsZXRlZCBsaXN0IGVudHJpZXMu
Ci0gKiBAbWVtYmVyOgl0aGUgbmFtZSBvZiB0aGUgbGxpc3Rfbm9kZSB3aXRoIHRoZSBzdHJ1Y3Qu
Ci0gKgotICogSW4gZ2VuZXJhbCwgc29tZSBlbnRyaWVzIG9mIHRoZSBsb2NrLWxlc3MgbGlzdCBj
YW4gYmUgdHJhdmVyc2VkCi0gKiBzYWZlbHkgb25seSBhZnRlciBiZWluZyByZW1vdmVkIGZyb20g
bGlzdCwgc28gc3RhcnQgd2l0aCBhbiBlbnRyeQotICogaW5zdGVhZCBvZiBsaXN0IGhlYWQuIFRo
aXMgdmFyaWFudCBhbGxvd3MgcmVtb3ZhbCBvZiBlbnRyaWVzCi0gKiBhcyB3ZSBpdGVyYXRlLgot
ICoKLSAqIElmIGJlaW5nIHVzZWQgb24gZW50cmllcyBkZWxldGVkIGZyb20gbG9jay1sZXNzIGxp
c3QgZGlyZWN0bHksIHRoZQotICogdHJhdmVyc2Ugb3JkZXIgaXMgZnJvbSB0aGUgbmV3ZXN0IHRv
IHRoZSBvbGRlc3QgYWRkZWQgZW50cnkuICBJZgotICogeW91IHdhbnQgdG8gdHJhdmVyc2UgZnJv
bSB0aGUgb2xkZXN0IHRvIHRoZSBuZXdlc3QsIHlvdSBtdXN0Ci0gKiByZXZlcnNlIHRoZSBvcmRl
ciBieSB5b3Vyc2VsZiBiZWZvcmUgdHJhdmVyc2luZy4KLSAqLwotI2RlZmluZSBsbGlzdF9mb3Jf
ZWFjaF9lbnRyeV9zYWZlKHBvcywgbiwgbm9kZSwgbWVtYmVyKQkJXAotCWZvciAoKHBvcykgPSBs
bGlzdF9lbnRyeSgobm9kZSksIHR5cGVvZigqKHBvcykpLCBtZW1iZXIpLAlcCi0JICAgICAobikg
PSAocG9zKS0+bWVtYmVyLm5leHQ7CQkJCQlcCi0JICAgICAmKHBvcyktPm1lbWJlciAhPSBOVUxM
OwkJCQkJXAotCSAgICAgKHBvcykgPSBsbGlzdF9lbnRyeShuLCB0eXBlb2YoKihwb3MpKSwgbWVt
YmVyKSwJCVwKLQkgICAgIChuKSA9ICgmKHBvcyktPm1lbWJlciAhPSBOVUxMKSA/IChwb3MpLT5t
ZW1iZXIubmV4dCA6IE5VTEwpCi0KLS8qKgogICogbGxpc3RfZW1wdHkgLSB0ZXN0cyB3aGV0aGVy
IGEgbG9jay1sZXNzIGxpc3QgaXMgZW1wdHkKICAqIEBoZWFkOgl0aGUgbGlzdCB0byB0ZXN0CiAg
KgotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Feb 15 18:21:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:21: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 1U6Pts-0004NE-Sr; Fri, 15 Feb 2013 18:20:44 +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 1U6Ptr-0004N7-Ey
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:20:43 +0000
Received: from [85.158.143.99:57715] by server-1.bemta-4.messagelabs.com id
	F6/B9-08839-A7C7E115; Fri, 15 Feb 2013 18:20:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360952440!27136062!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18985 invoked from network); 15 Feb 2013 18:20:41 -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;
	15 Feb 2013 18:20:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7357360"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:19:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:19:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6Pso-0007jp-Qo;
	Fri, 15 Feb 2013 18:19:38 +0000
Message-ID: <1360952378.16636.195.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 15 Feb 2013 18:19:38 +0000
In-Reply-To: <511E46FD.3010605@citrix.com>
References: <511E46FD.3010605@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Apart from the TAIL field, I have some comments on the hypercall
interface. Please see inline comments.

On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init_control`
> 
> * `EVTCHNOP_expand_array`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init_control`
> 
> This call initializes a single VCPU's control block.
> 
> A guest should call this during initial VCPU bring up.  The guest must
> have already successfully registered a vcpu_info structure and the
> control block must be in the same page.
> 
> If this call fails on the boot VCPU, the guest should continue to use
> the 2-level event channel ABI for all VCPUs.  If this call fails on
> any non-boot VCPU then the VCPU will be unable to receive events and
> the guest should offline the VCPU.
> 

Why offline this CPU? This call only registers control block, we can
switch back to use 2-level for all CPUs.

This is not a right or wrong question, but consider, how many vcpus will
a guest have? If the number is small, user would probably choose to have
all their cpus online over the new event interface.

> > Note: This only initializes the control block. At least one page
> > needs to be added to the event arrary with `EVTCHNOP_expand_array`.
> 
>     struct evtchnop_init_control {
>         uint64_t control_pfn;
>         uint32_t offset;
>         uint32_t vcpu;
>     };
> 
> Field          Purpose
> -----          -------
> `control_pfn`  [in] The PFN or GMFN of the page containing the control
> block.
> `offset`       [in] Offset in bytes from the start of the page to the
> beginning of the control block.
> `vcpu`         [in] The VCPU number.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `control_pfn` is not a valid frame for the domain.
> EINVAL      `control_pfn` is not the same frame as the vcpu_info structure.

Hmm... then you can omit control_pfn entirely?

> EINVAL      `offset` is not a multiple of 8 or the control block would
> cross a page boundary.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand_array`
> 
> This call expands the event array by appending an additional page.
> 

A bit implementation detail:

What state should guest / hypervisor be in when issuing this call?

> A guest should call this when a new event channel is required and
> there is insufficient space in the current event array.
> 
> It is not possible to shrink the event array once it has been
> expanded.
> 
> If this call fails, then subsequent attempts to bind event channels
> may fail with -ENOSPC.  If the first page cannot be added then the
> guest cannot receive any events and it should panic.
> 
>     struct evtchnop_expand_array {
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `array_pfn` is not a valid frame for the domain.
> EINVAL      The event array already has the maximum number of pages.
> ENOMEM      Insufficient memory to allocate internal structures.
[snip]
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the highest port number a domain can bind an
> event channel to.  The default for dom0 is the maximum supported
> ($2^{17}-1$).  Other domains default to 1023 (requiring only a single
> page for their event array).
> 
> The limit only affects future attempts to bind event channels.  Event
> channels that are already bound are not affected.
> 
> It is recommended that the toolstack only calls this during domain
> creation before the guest is started.
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_port;
>     };
> 
> Field       Purpose
> -----       -------
> `domid`     [in] The domain ID.
> `max_port`  [in] The highest port number that the domain may bound an
> event channel to.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 

Is it OK to shrink port limit?

> 
> Upcall
> ------
> 
> When Xen places an event on an empty queue it sets the queue as ready
> in the control block.  If the ready bit transitions from 0 to 1, a new
> event is signalled to the guest.
> 
> The guest uses the control block's ready field to find the highest
> priority queue with pending events.  The bit in the ready word is
> cleared when the queue is emptied.
> 
> Higher priority events do not need to preempt lower priority event
> handlers so the guest can handle events by taking one event off the
> currently ready queue with highest priority.
> 
>     r = C.ready
>     while r
>         q = find_first_set_bit(r)
>         consume_one_event_from_queue(q)
>         if C.queue[q].H == 0
>             C.ready[q] = 0
>             r[b] = 0

What is b? Could be clear_bit(r,q)?


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 18:21:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:21: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 1U6Pts-0004NE-Sr; Fri, 15 Feb 2013 18:20:44 +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 1U6Ptr-0004N7-Ey
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:20:43 +0000
Received: from [85.158.143.99:57715] by server-1.bemta-4.messagelabs.com id
	F6/B9-08839-A7C7E115; Fri, 15 Feb 2013 18:20:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1360952440!27136062!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18985 invoked from network); 15 Feb 2013 18:20:41 -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;
	15 Feb 2013 18:20:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; 
   d="scan'208";a="7357360"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:19:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:19:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6Pso-0007jp-Qo;
	Fri, 15 Feb 2013 18:19:38 +0000
Message-ID: <1360952378.16636.195.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 15 Feb 2013 18:19:38 +0000
In-Reply-To: <511E46FD.3010605@citrix.com>
References: <511E46FD.3010605@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Apart from the TAIL field, I have some comments on the hypercall
interface. Please see inline comments.

On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> 
> Hypercalls
> ----------
> 
> Four new EVTCHNOP hypercall sub-operations are added:
> 
> * `EVTCHNOP_init_control`
> 
> * `EVTCHNOP_expand_array`
> 
> * `EVTCHNOP_set_priority`
> 
> * `EVTCHNOP_set_limit`
> 
> ### `EVTCHNOP_init_control`
> 
> This call initializes a single VCPU's control block.
> 
> A guest should call this during initial VCPU bring up.  The guest must
> have already successfully registered a vcpu_info structure and the
> control block must be in the same page.
> 
> If this call fails on the boot VCPU, the guest should continue to use
> the 2-level event channel ABI for all VCPUs.  If this call fails on
> any non-boot VCPU then the VCPU will be unable to receive events and
> the guest should offline the VCPU.
> 

Why offline this CPU? This call only registers control block, we can
switch back to use 2-level for all CPUs.

This is not a right or wrong question, but consider, how many vcpus will
a guest have? If the number is small, user would probably choose to have
all their cpus online over the new event interface.

> > Note: This only initializes the control block. At least one page
> > needs to be added to the event arrary with `EVTCHNOP_expand_array`.
> 
>     struct evtchnop_init_control {
>         uint64_t control_pfn;
>         uint32_t offset;
>         uint32_t vcpu;
>     };
> 
> Field          Purpose
> -----          -------
> `control_pfn`  [in] The PFN or GMFN of the page containing the control
> block.
> `offset`       [in] Offset in bytes from the start of the page to the
> beginning of the control block.
> `vcpu`         [in] The VCPU number.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `vcpu` is invalid or already initialized.
> EINVAL      `control_pfn` is not a valid frame for the domain.
> EINVAL      `control_pfn` is not the same frame as the vcpu_info structure.

Hmm... then you can omit control_pfn entirely?

> EINVAL      `offset` is not a multiple of 8 or the control block would
> cross a page boundary.
> ENOMEM      Insufficient memory to allocate internal structures.
> 
> ### `EVTCHNOP_expand_array`
> 
> This call expands the event array by appending an additional page.
> 

A bit implementation detail:

What state should guest / hypervisor be in when issuing this call?

> A guest should call this when a new event channel is required and
> there is insufficient space in the current event array.
> 
> It is not possible to shrink the event array once it has been
> expanded.
> 
> If this call fails, then subsequent attempts to bind event channels
> may fail with -ENOSPC.  If the first page cannot be added then the
> guest cannot receive any events and it should panic.
> 
>     struct evtchnop_expand_array {
>         uint64_t array_pfn;
>     };
> 
> Field          Purpose
> -----          -------
> `array_pfn`    [in] The PFN or GMFN of a page to be used for the next page
>                of the event array.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `array_pfn` is not a valid frame for the domain.
> EINVAL      The event array already has the maximum number of pages.
> ENOMEM      Insufficient memory to allocate internal structures.
[snip]
> 
> ### `EVTCHNOP_set_limit`
> 
> This privileged call sets the highest port number a domain can bind an
> event channel to.  The default for dom0 is the maximum supported
> ($2^{17}-1$).  Other domains default to 1023 (requiring only a single
> page for their event array).
> 
> The limit only affects future attempts to bind event channels.  Event
> channels that are already bound are not affected.
> 
> It is recommended that the toolstack only calls this during domain
> creation before the guest is started.
> 
>     struct evtchnop_set_limit {
>         uint32_t domid;
>         uint32_t max_port;
>     };
> 
> Field       Purpose
> -----       -------
> `domid`     [in] The domain ID.
> `max_port`  [in] The highest port number that the domain may bound an
> event channel to.
> 
> Error code  Reason
> ----------  ------
> EINVAL      `domid` is invalid.
> EPERM       The calling domain has insufficient privileges.
> 

Is it OK to shrink port limit?

> 
> Upcall
> ------
> 
> When Xen places an event on an empty queue it sets the queue as ready
> in the control block.  If the ready bit transitions from 0 to 1, a new
> event is signalled to the guest.
> 
> The guest uses the control block's ready field to find the highest
> priority queue with pending events.  The bit in the ready word is
> cleared when the queue is emptied.
> 
> Higher priority events do not need to preempt lower priority event
> handlers so the guest can handle events by taking one event off the
> currently ready queue with highest priority.
> 
>     r = C.ready
>     while r
>         q = find_first_set_bit(r)
>         consume_one_event_from_queue(q)
>         if C.queue[q].H == 0
>             C.ready[q] = 0
>             r[b] = 0

What is b? Could be clear_bit(r,q)?


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 18:47:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QJG-0004oy-5a; Fri, 15 Feb 2013 18:46:58 +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 1U6QJD-0004ot-Ty
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:46:56 +0000
Received: from [85.158.139.83:61297] by server-6.bemta-5.messagelabs.com id
	38/53-01489-F928E115; Fri, 15 Feb 2013 18:46:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360954012!23547000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31561 invoked from network); 15 Feb 2013 18:46:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 18:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362221"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:46:52 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:46:51 -0500
Message-ID: <511E829B.8020800@citrix.com>
Date: Fri, 15 Feb 2013 18:46:51 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1360952378.16636.195.camel@zion.uk.xensource.com>
In-Reply-To: <1360952378.16636.195.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/13 18:19, Wei Liu wrote:
> Apart from the TAIL field, I have some comments on the hypercall
> interface. Please see inline comments.
> 
> On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
>>
>> ### `EVTCHNOP_init_control`
>>
>> This call initializes a single VCPU's control block.
>>
>> A guest should call this during initial VCPU bring up.  The guest must
>> have already successfully registered a vcpu_info structure and the
>> control block must be in the same page.
>>
>> If this call fails on the boot VCPU, the guest should continue to use
>> the 2-level event channel ABI for all VCPUs.  If this call fails on
>> any non-boot VCPU then the VCPU will be unable to receive events and
>> the guest should offline the VCPU.
>>
> 
> Why offline this CPU? This call only registers control block, we can
> switch back to use 2-level for all CPUs.

Because switching back for the other VCPUs is potentially impossible (we
may have hotplugged this new VCPU and more than 4096 event channels may
be currently in use).  It would also require migrating events between
the new and old data structures which is hard.

I would expect this call to never fail in normal operation (except on
the boot VCPU where support may be missing).  i.e., it will only fail if
xenheap or map space is exhausted.  Both the xenheap and the map space
should be large enough so we run out of other resources (e.g,, domheap)
first.

> This is not a right or wrong question, but consider, how many vcpus will
> a guest have? If the number is small, user would probably choose to have
> all their cpus online over the new event interface.
> 
>>> Note: This only initializes the control block. At least one page
>>> needs to be added to the event arrary with `EVTCHNOP_expand_array`.
>>
>>     struct evtchnop_init_control {
>>         uint64_t control_pfn;
>>         uint32_t offset;
>>         uint32_t vcpu;
>>     };
>>
>> Field          Purpose
>> -----          -------
>> `control_pfn`  [in] The PFN or GMFN of the page containing the control
>> block.
>> `offset`       [in] Offset in bytes from the start of the page to the
>> beginning of the control block.
>> `vcpu`         [in] The VCPU number.
>>
>> Error code  Reason
>> ----------  ------
>> EINVAL      `vcpu` is invalid or already initialized.
>> EINVAL      `control_pfn` is not a valid frame for the domain.
>> EINVAL      `control_pfn` is not the same frame as the vcpu_info structure.
> 
> Hmm... then you can omit control_pfn entirely?

I left it in so the requirement that the two structures share pages can
be relaxed in the future.

And it will catch callers that haven't laid out their structures
correctly which is useful.

>> EINVAL      `offset` is not a multiple of 8 or the control block would
>> cross a page boundary.
>> ENOMEM      Insufficient memory to allocate internal structures.
>>
>> ### `EVTCHNOP_expand_array`
>>
>> This call expands the event array by appending an additional page.
>>
> 
> A bit implementation detail:
> 
> What state should guest / hypervisor be in when issuing this call?

The boot VCPU shall have successfully initialized its control block.  I
don't think there are any other restrictions on this call.

>> ### `EVTCHNOP_set_limit`
>>
>> This privileged call sets the highest port number a domain can bind an
>> event channel to.  The default for dom0 is the maximum supported
>> ($2^{17}-1$).  Other domains default to 1023 (requiring only a single
>> page for their event array).
>>
>> The limit only affects future attempts to bind event channels.  Event
>> channels that are already bound are not affected.
>>
>> It is recommended that the toolstack only calls this during domain
>> creation before the guest is started.
>>
> 
> Is it OK to shrink port limit?

Yes, but note the affect this has:

"The limit only affects future attempts to bind event channels.  Event
channels that are already bound are not affected."

>> Upcall
>> ------
>>
>> When Xen places an event on an empty queue it sets the queue as ready
>> in the control block.  If the ready bit transitions from 0 to 1, a new
>> event is signalled to the guest.
>>
>> The guest uses the control block's ready field to find the highest
>> priority queue with pending events.  The bit in the ready word is
>> cleared when the queue is emptied.
>>
>> Higher priority events do not need to preempt lower priority event
>> handlers so the guest can handle events by taking one event off the
>> currently ready queue with highest priority.
>>
>>     r = C.ready
>>     while r
>>         q = find_first_set_bit(r)
>>         consume_one_event_from_queue(q)
>>         if C.queue[q].H == 0
>>             C.ready[q] = 0
>>             r[b] = 0
> 
> What is b? Could be clear_bit(r,q)?

Typo, oops.

r[q] = 0

i.e., clear the q'th bit of r, so clear_bit(q, r) yes.

Typos not withstanding, would the pseudocode be clearer if it used Linux
style bit ops?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 18:47:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QJG-0004oy-5a; Fri, 15 Feb 2013 18:46:58 +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 1U6QJD-0004ot-Ty
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:46:56 +0000
Received: from [85.158.139.83:61297] by server-6.bemta-5.messagelabs.com id
	38/53-01489-F928E115; Fri, 15 Feb 2013 18:46:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1360954012!23547000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31561 invoked from network); 15 Feb 2013 18:46:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 18:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362221"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:46:52 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:46:51 -0500
Message-ID: <511E829B.8020800@citrix.com>
Date: Fri, 15 Feb 2013 18:46:51 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1360952378.16636.195.camel@zion.uk.xensource.com>
In-Reply-To: <1360952378.16636.195.camel@zion.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/02/13 18:19, Wei Liu wrote:
> Apart from the TAIL field, I have some comments on the hypercall
> interface. Please see inline comments.
> 
> On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
>>
>> ### `EVTCHNOP_init_control`
>>
>> This call initializes a single VCPU's control block.
>>
>> A guest should call this during initial VCPU bring up.  The guest must
>> have already successfully registered a vcpu_info structure and the
>> control block must be in the same page.
>>
>> If this call fails on the boot VCPU, the guest should continue to use
>> the 2-level event channel ABI for all VCPUs.  If this call fails on
>> any non-boot VCPU then the VCPU will be unable to receive events and
>> the guest should offline the VCPU.
>>
> 
> Why offline this CPU? This call only registers control block, we can
> switch back to use 2-level for all CPUs.

Because switching back for the other VCPUs is potentially impossible (we
may have hotplugged this new VCPU and more than 4096 event channels may
be currently in use).  It would also require migrating events between
the new and old data structures which is hard.

I would expect this call to never fail in normal operation (except on
the boot VCPU where support may be missing).  i.e., it will only fail if
xenheap or map space is exhausted.  Both the xenheap and the map space
should be large enough so we run out of other resources (e.g,, domheap)
first.

> This is not a right or wrong question, but consider, how many vcpus will
> a guest have? If the number is small, user would probably choose to have
> all their cpus online over the new event interface.
> 
>>> Note: This only initializes the control block. At least one page
>>> needs to be added to the event arrary with `EVTCHNOP_expand_array`.
>>
>>     struct evtchnop_init_control {
>>         uint64_t control_pfn;
>>         uint32_t offset;
>>         uint32_t vcpu;
>>     };
>>
>> Field          Purpose
>> -----          -------
>> `control_pfn`  [in] The PFN or GMFN of the page containing the control
>> block.
>> `offset`       [in] Offset in bytes from the start of the page to the
>> beginning of the control block.
>> `vcpu`         [in] The VCPU number.
>>
>> Error code  Reason
>> ----------  ------
>> EINVAL      `vcpu` is invalid or already initialized.
>> EINVAL      `control_pfn` is not a valid frame for the domain.
>> EINVAL      `control_pfn` is not the same frame as the vcpu_info structure.
> 
> Hmm... then you can omit control_pfn entirely?

I left it in so the requirement that the two structures share pages can
be relaxed in the future.

And it will catch callers that haven't laid out their structures
correctly which is useful.

>> EINVAL      `offset` is not a multiple of 8 or the control block would
>> cross a page boundary.
>> ENOMEM      Insufficient memory to allocate internal structures.
>>
>> ### `EVTCHNOP_expand_array`
>>
>> This call expands the event array by appending an additional page.
>>
> 
> A bit implementation detail:
> 
> What state should guest / hypervisor be in when issuing this call?

The boot VCPU shall have successfully initialized its control block.  I
don't think there are any other restrictions on this call.

>> ### `EVTCHNOP_set_limit`
>>
>> This privileged call sets the highest port number a domain can bind an
>> event channel to.  The default for dom0 is the maximum supported
>> ($2^{17}-1$).  Other domains default to 1023 (requiring only a single
>> page for their event array).
>>
>> The limit only affects future attempts to bind event channels.  Event
>> channels that are already bound are not affected.
>>
>> It is recommended that the toolstack only calls this during domain
>> creation before the guest is started.
>>
> 
> Is it OK to shrink port limit?

Yes, but note the affect this has:

"The limit only affects future attempts to bind event channels.  Event
channels that are already bound are not affected."

>> Upcall
>> ------
>>
>> When Xen places an event on an empty queue it sets the queue as ready
>> in the control block.  If the ready bit transitions from 0 to 1, a new
>> event is signalled to the guest.
>>
>> The guest uses the control block's ready field to find the highest
>> priority queue with pending events.  The bit in the ready word is
>> cleared when the queue is emptied.
>>
>> Higher priority events do not need to preempt lower priority event
>> handlers so the guest can handle events by taking one event off the
>> currently ready queue with highest priority.
>>
>>     r = C.ready
>>     while r
>>         q = find_first_set_bit(r)
>>         consume_one_event_from_queue(q)
>>         if C.queue[q].H == 0
>>             C.ready[q] = 0
>>             r[b] = 0
> 
> What is b? Could be clear_bit(r,q)?

Typo, oops.

r[q] = 0

i.e., clear the q'th bit of r, so clear_bit(q, r) yes.

Typos not withstanding, would the pseudocode be clearer if it used Linux
style bit ops?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 18:49:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QLr-0004vq-UD; Fri, 15 Feb 2013 18:49:39 +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 1U6QLr-0004vg-0I
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:39 +0000
Received: from [193.109.254.147:45247] by server-10.bemta-14.messagelabs.com
	id 52/93-12679-2438E115; Fri, 15 Feb 2013 18:49:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360954176!1719951!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21587 invoked from network); 15 Feb 2013 18:49:37 -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;
	15 Feb 2013 18:49:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362636"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-UD;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:14 +0000
Message-ID: <1360954157-4412-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/4] xen/arm: trap guest WFI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Trap guest WFI, block the guest VCPU unless it has pending interrupts.
Awake the guest vcpu when a new interrupt for it arrrives.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/traps.c        |    6 ++++++
 xen/arch/arm/vgic.c         |    4 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e9776d..aa0f191 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -331,7 +331,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM|HCR_TWI, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5347dce..c3e6404 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -29,6 +29,7 @@
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
 #include <xen/domain_page.h>
+#include <public/sched.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -781,6 +782,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
     case HSR_EC_DATA_ABORT_GUEST:
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
+    case HSR_EC_WFI_WFE:
+		if ( list_empty(&current->arch.vgic.inflight_irqs) )
+			do_sched_op_compat(SCHEDOP_block, 0);
+        regs->pc += hsr.len ? 4 : 2;
+        break;
     default:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 39b9775..8495384 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -608,12 +608,14 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         {
             list_add_tail(&n->inflight, &iter->inflight);
             spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
-            return;
+            goto out;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
     spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
+out:
+    vcpu_unblock(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 Fri Feb 15 18:49:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QLr-0004vq-UD; Fri, 15 Feb 2013 18:49:39 +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 1U6QLr-0004vg-0I
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:39 +0000
Received: from [193.109.254.147:45247] by server-10.bemta-14.messagelabs.com
	id 52/93-12679-2438E115; Fri, 15 Feb 2013 18:49:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360954176!1719951!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21587 invoked from network); 15 Feb 2013 18:49:37 -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;
	15 Feb 2013 18:49:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362636"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-UD;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:14 +0000
Message-ID: <1360954157-4412-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/4] xen/arm: trap guest WFI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Trap guest WFI, block the guest VCPU unless it has pending interrupts.
Awake the guest vcpu when a new interrupt for it arrrives.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/traps.c        |    6 ++++++
 xen/arch/arm/vgic.c         |    4 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e9776d..aa0f191 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -331,7 +331,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM|HCR_TWI, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5347dce..c3e6404 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -29,6 +29,7 @@
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
 #include <xen/domain_page.h>
+#include <public/sched.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -781,6 +782,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
     case HSR_EC_DATA_ABORT_GUEST:
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
+    case HSR_EC_WFI_WFE:
+		if ( list_empty(&current->arch.vgic.inflight_irqs) )
+			do_sched_op_compat(SCHEDOP_block, 0);
+        regs->pc += hsr.len ? 4 : 2;
+        break;
     default:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 39b9775..8495384 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -608,12 +608,14 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         {
             list_add_tail(&n->inflight, &iter->inflight);
             spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
-            return;
+            goto out;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
     spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
+out:
+    vcpu_unblock(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 Fri Feb 15 18:49:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QLv-0004wW-5W; Fri, 15 Feb 2013 18:49: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 1U6QLs-0004vx-LO
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:40 +0000
Received: from [85.158.143.99:45657] by server-3.bemta-4.messagelabs.com id
	52/8C-08920-4438E115; Fri, 15 Feb 2013 18:49:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360954178!18106447!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14819 invoked from network); 15 Feb 2013 18:49:39 -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;
	15 Feb 2013 18:49:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362639"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-Vy;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:17 +0000
Message-ID: <1360954157-4412-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen/arm: more virt_timer 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

Do not set the Xen internal timer if the virt_timer is masked.

Disable interrupts while saving the virt_timer registers to avoid
conflicts with possible virt_timer interrupts coming through.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e033191..67fa513 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -89,10 +89,13 @@ int virt_timer_save(struct vcpu *v)
     if ( is_idle_domain(v->domain) )
         return 0;
 
+    local_irq_disable();
     v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
     WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
-    if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
+    local_irq_enable();
+    if ( (v->arch.virt_timer.ctl & CNTx_CTL_ENABLE) &&
+         !(v->arch.virt_timer.ctl & CNTx_CTL_MASK))
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
                   v->arch.virt_timer.offset - boot_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 Fri Feb 15 18:49:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QLv-0004wW-5W; Fri, 15 Feb 2013 18:49: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 1U6QLs-0004vx-LO
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:40 +0000
Received: from [85.158.143.99:45657] by server-3.bemta-4.messagelabs.com id
	52/8C-08920-4438E115; Fri, 15 Feb 2013 18:49:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1360954178!18106447!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14819 invoked from network); 15 Feb 2013 18:49:39 -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;
	15 Feb 2013 18:49:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362639"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-Vy;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:17 +0000
Message-ID: <1360954157-4412-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] xen/arm: more virt_timer 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

Do not set the Xen internal timer if the virt_timer is masked.

Disable interrupts while saving the virt_timer registers to avoid
conflicts with possible virt_timer interrupts coming through.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e033191..67fa513 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -89,10 +89,13 @@ int virt_timer_save(struct vcpu *v)
     if ( is_idle_domain(v->domain) )
         return 0;
 
+    local_irq_disable();
     v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
     WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
-    if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
+    local_irq_enable();
+    if ( (v->arch.virt_timer.ctl & CNTx_CTL_ENABLE) &&
+         !(v->arch.virt_timer.ctl & CNTx_CTL_MASK))
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
                   v->arch.virt_timer.offset - boot_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 Fri Feb 15 18:50:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:50: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 1U6QLu-0004wN-Oo; Fri, 15 Feb 2013 18:49:42 +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 1U6QLs-0004vu-GX
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:40 +0000
Received: from [193.109.254.147:40355] by server-3.bemta-14.messagelabs.com id
	1A/6B-22141-3438E115; Fri, 15 Feb 2013 18:49:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360954176!1719951!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21673 invoked from network); 15 Feb 2013 18:49:38 -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;
	15 Feb 2013 18:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362638"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-VU;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:16 +0000
Message-ID: <1360954157-4412-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/4] xen/arm: dump gic debug info from
	arch_dump_domain_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

Print some useful GIC debug information when arch_dump_domain_info is
called ('q' debug key).

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    6 ++++++
 xen/arch/arm/gic.c        |   27 +++++++++++++++++++++++++++
 xen/include/asm-arm/gic.h |    3 +++
 3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..817e800 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -568,6 +568,12 @@ int domain_relinquish_resources(struct domain *d)
 
 void arch_dump_domain_info(struct domain *d)
 {
+	struct vcpu *v;
+
+	for_each_vcpu ( d, v )
+	{
+		gic_dump_info(v);
+	}
 }
 
 long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 88f2d3a..9db1f57 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -677,6 +677,33 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     }
 }
 
+void gic_dump_info(struct vcpu *v)
+{
+    int i;
+    struct pending_irq *p;
+
+    printk("GICH_LRs (vcpu %d) mask=%llx\n", v->vcpu_id, v->arch.lr_mask);
+    if ( v == gic_running )
+    {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   HW_LR[%d]=%x\n", i, GICH[GICH_LR + i]);
+    } else {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   VCPU_LR[%d]=%x\n", i, v->arch.gic_lr[i]);
+    }
+
+    list_for_each_entry ( p, &v->arch.vgic.inflight_irqs, inflight )
+    {
+        printk("Inflight irq=%d\n", p->irq);
+    }
+
+    list_for_each_entry( p, &v->arch.vgic.lr_pending, lr_queue )
+    {
+        printk("Pending irq=%d\n", p->irq);
+    }
+
+}
+ 
 void __cpuinit init_maintenance_interrupt(void)
 {
     request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index f4b0324..7c9499e 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -162,6 +162,9 @@ void register_gic_callback(int irq, gic_callback_fn_t fn);
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(struct vcpu *v);
 
+/* print useful debug info */
+extern void gic_dump_info(struct vcpu *v);
+
 #endif /* __ASSEMBLY__ */
 #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 Feb 15 18:50:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:50: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 1U6QLt-0004w9-Ae; Fri, 15 Feb 2013 18:49:41 +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 1U6QLr-0004vg-FV
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:39 +0000
Received: from [193.109.254.147:45271] by server-10.bemta-14.messagelabs.com
	id 84/93-12679-2438E115; Fri, 15 Feb 2013 18:49:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360954176!1719951!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21648 invoked from network); 15 Feb 2013 18:49:38 -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;
	15 Feb 2013 18:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362637"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-Ul;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:15 +0000
Message-ID: <1360954157-4412-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/4] xen/arm: do not use is_running to decide
	whether we can write directly to the LR registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 context switch is_running is set for the next vcpu before the
gic state is actually saved.
This leads to possible nasty races when interrupts need to be injected
after is_running is set to the next vcpu but before the currently
running gic state has been saved from the previous vcpu.
Introduce a new gic_running internal variable to precisely determine
which one is the vcpu currently using the gic.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 0ecc0f1..88f2d3a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -53,6 +53,7 @@ static irq_desc_t irq_desc[NR_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
 static DEFINE_PER_CPU(uint64_t, lr_mask);
 static gic_callback_fn_t gic_callbacks[NR_IRQS];
+static struct vcpu *gic_running;
 
 unsigned nr_lrs;
 
@@ -70,6 +71,7 @@ void gic_save_state(struct vcpu *v)
     for ( i=0; i<nr_lrs; i++)
         v->arch.gic_lr[i] = GICH[GICH_LR + i];
     v->arch.lr_mask = this_cpu(lr_mask);
+    gic_running = NULL;
     spin_unlock_irq(&gic.lock);
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
@@ -81,12 +83,16 @@ void gic_restore_state(struct vcpu *v)
     int i;
 
     if ( is_idle_vcpu(v) )
+    {
+        gic_running = v;
         return;
+    }
 
     spin_lock_irq(&gic.lock);
     this_cpu(lr_mask) = v->arch.lr_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
+    gic_running = v;
     spin_unlock_irq(&gic.lock);
     GICH[GICH_HCR] = GICH_HCR_EN;
     isb();
@@ -481,7 +487,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     spin_lock_irqsave(&gic.lock, flags);
 
-    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
+    if ( v == gic_running && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
-- 
1.7.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 Feb 15 18:50:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:50: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 1U6QLt-0004w9-Ae; Fri, 15 Feb 2013 18:49:41 +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 1U6QLr-0004vg-FV
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:39 +0000
Received: from [193.109.254.147:45271] by server-10.bemta-14.messagelabs.com
	id 84/93-12679-2438E115; Fri, 15 Feb 2013 18:49:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360954176!1719951!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21648 invoked from network); 15 Feb 2013 18:49:38 -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;
	15 Feb 2013 18:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362637"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-Ul;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:15 +0000
Message-ID: <1360954157-4412-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/4] xen/arm: do not use is_running to decide
	whether we can write directly to the LR registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 context switch is_running is set for the next vcpu before the
gic state is actually saved.
This leads to possible nasty races when interrupts need to be injected
after is_running is set to the next vcpu but before the currently
running gic state has been saved from the previous vcpu.
Introduce a new gic_running internal variable to precisely determine
which one is the vcpu currently using the gic.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/gic.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 0ecc0f1..88f2d3a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -53,6 +53,7 @@ static irq_desc_t irq_desc[NR_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
 static DEFINE_PER_CPU(uint64_t, lr_mask);
 static gic_callback_fn_t gic_callbacks[NR_IRQS];
+static struct vcpu *gic_running;
 
 unsigned nr_lrs;
 
@@ -70,6 +71,7 @@ void gic_save_state(struct vcpu *v)
     for ( i=0; i<nr_lrs; i++)
         v->arch.gic_lr[i] = GICH[GICH_LR + i];
     v->arch.lr_mask = this_cpu(lr_mask);
+    gic_running = NULL;
     spin_unlock_irq(&gic.lock);
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
@@ -81,12 +83,16 @@ void gic_restore_state(struct vcpu *v)
     int i;
 
     if ( is_idle_vcpu(v) )
+    {
+        gic_running = v;
         return;
+    }
 
     spin_lock_irq(&gic.lock);
     this_cpu(lr_mask) = v->arch.lr_mask;
     for ( i=0; i<nr_lrs; i++)
         GICH[GICH_LR + i] = v->arch.gic_lr[i];
+    gic_running = v;
     spin_unlock_irq(&gic.lock);
     GICH[GICH_HCR] = GICH_HCR_EN;
     isb();
@@ -481,7 +487,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     spin_lock_irqsave(&gic.lock, flags);
 
-    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
+    if ( v == gic_running && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
-- 
1.7.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 Feb 15 18:50:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18:50: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 1U6QLu-0004wN-Oo; Fri, 15 Feb 2013 18:49:42 +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 1U6QLs-0004vu-GX
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 18:49:40 +0000
Received: from [193.109.254.147:40355] by server-3.bemta-14.messagelabs.com id
	1A/6B-22141-3438E115; Fri, 15 Feb 2013 18:49:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1360954176!1719951!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDI2Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21673 invoked from network); 15 Feb 2013 18:49:38 -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;
	15 Feb 2013 18:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7362638"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 18:49:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 13:49:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6QLb-0008CW-VU;
	Fri, 15 Feb 2013 18:49:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 15 Feb 2013 18:49:16 +0000
Message-ID: <1360954157-4412-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/4] xen/arm: dump gic debug info from
	arch_dump_domain_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

Print some useful GIC debug information when arch_dump_domain_info is
called ('q' debug key).

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    6 ++++++
 xen/arch/arm/gic.c        |   27 +++++++++++++++++++++++++++
 xen/include/asm-arm/gic.h |    3 +++
 3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..817e800 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -568,6 +568,12 @@ int domain_relinquish_resources(struct domain *d)
 
 void arch_dump_domain_info(struct domain *d)
 {
+	struct vcpu *v;
+
+	for_each_vcpu ( d, v )
+	{
+		gic_dump_info(v);
+	}
 }
 
 long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 88f2d3a..9db1f57 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -677,6 +677,33 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     }
 }
 
+void gic_dump_info(struct vcpu *v)
+{
+    int i;
+    struct pending_irq *p;
+
+    printk("GICH_LRs (vcpu %d) mask=%llx\n", v->vcpu_id, v->arch.lr_mask);
+    if ( v == gic_running )
+    {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   HW_LR[%d]=%x\n", i, GICH[GICH_LR + i]);
+    } else {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   VCPU_LR[%d]=%x\n", i, v->arch.gic_lr[i]);
+    }
+
+    list_for_each_entry ( p, &v->arch.vgic.inflight_irqs, inflight )
+    {
+        printk("Inflight irq=%d\n", p->irq);
+    }
+
+    list_for_each_entry( p, &v->arch.vgic.lr_pending, lr_queue )
+    {
+        printk("Pending irq=%d\n", p->irq);
+    }
+
+}
+ 
 void __cpuinit init_maintenance_interrupt(void)
 {
     request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index f4b0324..7c9499e 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -162,6 +162,9 @@ void register_gic_callback(int irq, gic_callback_fn_t fn);
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(struct vcpu *v);
 
+/* print useful debug info */
+extern void gic_dump_info(struct vcpu *v);
+
 #endif /* __ASSEMBLY__ */
 #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 Feb 15 18:59:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QUo-0005gk-73; Fri, 15 Feb 2013 18:58: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 1U6QUm-0005ge-LJ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 18:58:52 +0000
Received: from [85.158.143.35:25257] by server-1.bemta-4.messagelabs.com id
	FC/24-08839-C658E115; Fri, 15 Feb 2013 18:58:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360954609!14568873!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29450 invoked from network); 15 Feb 2013 18:56:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 18:56:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FIukb8011693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 18:56:47 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
	r1FIujtI027663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 18:56:46 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
	r1FIuj20031950; Fri, 15 Feb 2013 12:56:45 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 10:56:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 243D01C387B; Fri, 15 Feb 2013 13:56:44 -0500 (EST)
Date: Fri, 15 Feb 2013 13:56:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130215185644.GB29539@phenom.dumpdata.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Should be backported to 3.8 stable.

Lets do one thing at a time.

The patch I have in the tree (and that I've asked Jens to pull for 3.9 - so
he might have already in his tree) is the old hybrid where we still use lli=
st
but change the loop from 'for' to 'while'.

This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/linux/=
kernel/git/konrad/xen.git =


Could you rebase your patch on top of that tree and just simplify the loop?

Sorry about the mess about this - but I had already pulled the trigger
so to say - hoping that Jens would pull the tree and do a git pull to Linus.

And you are absolutly sure that we don't need any extra locking when switch=
ing
over to list_head? Say if blkif_completion is called while we are
processing in blkif_queue_request and doing ?

> =

> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> [Part of the description]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xen.org
> ---
>  drivers/block/xen-blkfront.c |   27 ++++++++++++++-------------
>  include/linux/llist.h        |   25 -------------------------
>  2 files changed, 14 insertions(+), 38 deletions(-)
> =

> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 11043c1..01b91a5 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -44,7 +44,7 @@
>  #include <linux/mutex.h>
>  #include <linux/scatterlist.h>
>  #include <linux/bitmap.h>
> -#include <linux/llist.h>
> +#include <linux/list.h>
>  =

>  #include <xen/xen.h>
>  #include <xen/xenbus.h>
> @@ -68,7 +68,7 @@ enum blkif_state {
>  struct grant {
>  	grant_ref_t gref;
>  	unsigned long pfn;
> -	struct llist_node node;
> +	struct list_head node;
>  };
>  =

>  struct blk_shadow {
> @@ -105,7 +105,7 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> -	struct llist_head persistent_gnts;
> +	struct list_head persistent_gnts;
>  	unsigned int persistent_gnts_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
> @@ -371,10 +371,11 @@ static int blkif_queue_request(struct request *req)
>  			lsect =3D fsect + (sg->length >> 9) - 1;
>  =

>  			if (info->persistent_gnts_c) {
> -				BUG_ON(llist_empty(&info->persistent_gnts));
> -				gnt_list_entry =3D llist_entry(
> -					llist_del_first(&info->persistent_gnts),
> -					struct grant, node);
> +				BUG_ON(list_empty(&info->persistent_gnts));
> +				gnt_list_entry =3D list_first_entry(
> +				                      &info->persistent_gnts,
> +				                      struct grant, node);
> +				list_del(&gnt_list_entry->node);
>  =

>  				ref =3D gnt_list_entry->gref;
>  				buffer_mfn =3D pfn_to_mfn(gnt_list_entry->pfn);
> @@ -790,9 +791,8 @@ static void blkif_restart_queue(struct work_struct *w=
ork)
>  =

>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> -	struct llist_node *all_gnts;
>  	struct grant *persistent_gnt;
> -	struct llist_node *n;
> +	struct grant *n;
>  =

>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
> @@ -804,8 +804,9 @@ static void blkif_free(struct blkfront_info *info, in=
t suspend)
>  =

>  	/* Remove all persistent grants */
>  	if (info->persistent_gnts_c) {
> -		all_gnts =3D llist_del_all(&info->persistent_gnts);
> -		llist_for_each_entry_safe(persistent_gnt, n, all_gnts, node) {
> +		list_for_each_entry_safe(persistent_gnt, n,
> +		                         &info->persistent_gnts, node) {
> +			list_del(&persistent_gnt->node);
>  			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
>  			__free_page(pfn_to_page(persistent_gnt->pfn));
>  			kfree(persistent_gnt);
> @@ -868,7 +869,7 @@ static void blkif_completion(struct blk_shadow *s, st=
ruct blkfront_info *info,
>  	}
>  	/* Add the persistent grant into the list of free grants */
>  	for (i =3D 0; i < s->req.u.rw.nr_segments; i++) {
> -		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
> +		list_add(&s->grants_used[i]->node, &info->persistent_gnts);
>  		info->persistent_gnts_c++;
>  	}
>  }
> @@ -1164,7 +1165,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev =3D dev;
>  	info->vdevice =3D vdevice;
> -	init_llist_head(&info->persistent_gnts);
> +	INIT_LIST_HEAD(&info->persistent_gnts);
>  	info->persistent_gnts_c =3D 0;
>  	info->connected =3D BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index d0ab98f..a5199f6 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -125,31 +125,6 @@ static inline void init_llist_head(struct llist_head=
 *list)
>  	     (pos) =3D llist_entry((pos)->member.next, typeof(*(pos)), member))
>  =

>  /**
> - * llist_for_each_entry_safe - iterate safely against remove over some e=
ntries
> - * of lock-less list of given type.
> - * @pos:	the type * to use as a loop cursor.
> - * @n:		another type * to use as a temporary storage.
> - * @node:	the fist entry of deleted list entries.
> - * @member:	the name of the llist_node with the struct.
> - *
> - * In general, some entries of the lock-less list can be traversed
> - * safely only after being removed from list, so start with an entry
> - * instead of list head. This variant allows removal of entries
> - * as we iterate.
> - *
> - * If being used on entries deleted from lock-less list directly, the
> - * traverse order is from the newest to the oldest added entry.  If
> - * you want to traverse from the oldest to the newest, you must
> - * reverse the order by yourself before traversing.
> - */
> -#define llist_for_each_entry_safe(pos, n, node, member)		\
> -	for ((pos) =3D llist_entry((node), typeof(*(pos)), member),	\
> -	     (n) =3D (pos)->member.next;					\
> -	     &(pos)->member !=3D NULL;					\
> -	     (pos) =3D llist_entry(n, typeof(*(pos)), member),		\
> -	     (n) =3D (&(pos)->member !=3D NULL) ? (pos)->member.next : NULL)
> -
> -/**
>   * llist_empty - tests whether a lock-less list is empty
>   * @head:	the list to test
>   *
> -- =

> 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 Feb 15 18:59:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 18: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 1U6QUo-0005gk-73; Fri, 15 Feb 2013 18:58: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 1U6QUm-0005ge-LJ
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 18:58:52 +0000
Received: from [85.158.143.35:25257] by server-1.bemta-4.messagelabs.com id
	FC/24-08839-C658E115; Fri, 15 Feb 2013 18:58:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1360954609!14568873!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI1NTY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29450 invoked from network); 15 Feb 2013 18:56:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Feb 2013 18:56:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1FIukb8011693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 15 Feb 2013 18:56:47 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
	r1FIujtI027663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 15 Feb 2013 18:56:46 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
	r1FIuj20031950; Fri, 15 Feb 2013 12:56:45 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 10:56:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 243D01C387B; Fri, 15 Feb 2013 13:56:44 -0500 (EST)
Date: Fri, 15 Feb 2013 13:56:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <20130215185644.GB29539@phenom.dumpdata.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Should be backported to 3.8 stable.

Lets do one thing at a time.

The patch I have in the tree (and that I've asked Jens to pull for 3.9 - so
he might have already in his tree) is the old hybrid where we still use lli=
st
but change the loop from 'for' to 'while'.

This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/linux/=
kernel/git/konrad/xen.git =


Could you rebase your patch on top of that tree and just simplify the loop?

Sorry about the mess about this - but I had already pulled the trigger
so to say - hoping that Jens would pull the tree and do a git pull to Linus.

And you are absolutly sure that we don't need any extra locking when switch=
ing
over to list_head? Say if blkif_completion is called while we are
processing in blkif_queue_request and doing ?

> =

> Signed-off-by: Roger Pau Monn=E9 <roger.pau@citrix.com>
> [Part of the description]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xen.org
> ---
>  drivers/block/xen-blkfront.c |   27 ++++++++++++++-------------
>  include/linux/llist.h        |   25 -------------------------
>  2 files changed, 14 insertions(+), 38 deletions(-)
> =

> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 11043c1..01b91a5 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -44,7 +44,7 @@
>  #include <linux/mutex.h>
>  #include <linux/scatterlist.h>
>  #include <linux/bitmap.h>
> -#include <linux/llist.h>
> +#include <linux/list.h>
>  =

>  #include <xen/xen.h>
>  #include <xen/xenbus.h>
> @@ -68,7 +68,7 @@ enum blkif_state {
>  struct grant {
>  	grant_ref_t gref;
>  	unsigned long pfn;
> -	struct llist_node node;
> +	struct list_head node;
>  };
>  =

>  struct blk_shadow {
> @@ -105,7 +105,7 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> -	struct llist_head persistent_gnts;
> +	struct list_head persistent_gnts;
>  	unsigned int persistent_gnts_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
> @@ -371,10 +371,11 @@ static int blkif_queue_request(struct request *req)
>  			lsect =3D fsect + (sg->length >> 9) - 1;
>  =

>  			if (info->persistent_gnts_c) {
> -				BUG_ON(llist_empty(&info->persistent_gnts));
> -				gnt_list_entry =3D llist_entry(
> -					llist_del_first(&info->persistent_gnts),
> -					struct grant, node);
> +				BUG_ON(list_empty(&info->persistent_gnts));
> +				gnt_list_entry =3D list_first_entry(
> +				                      &info->persistent_gnts,
> +				                      struct grant, node);
> +				list_del(&gnt_list_entry->node);
>  =

>  				ref =3D gnt_list_entry->gref;
>  				buffer_mfn =3D pfn_to_mfn(gnt_list_entry->pfn);
> @@ -790,9 +791,8 @@ static void blkif_restart_queue(struct work_struct *w=
ork)
>  =

>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> -	struct llist_node *all_gnts;
>  	struct grant *persistent_gnt;
> -	struct llist_node *n;
> +	struct grant *n;
>  =

>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
> @@ -804,8 +804,9 @@ static void blkif_free(struct blkfront_info *info, in=
t suspend)
>  =

>  	/* Remove all persistent grants */
>  	if (info->persistent_gnts_c) {
> -		all_gnts =3D llist_del_all(&info->persistent_gnts);
> -		llist_for_each_entry_safe(persistent_gnt, n, all_gnts, node) {
> +		list_for_each_entry_safe(persistent_gnt, n,
> +		                         &info->persistent_gnts, node) {
> +			list_del(&persistent_gnt->node);
>  			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
>  			__free_page(pfn_to_page(persistent_gnt->pfn));
>  			kfree(persistent_gnt);
> @@ -868,7 +869,7 @@ static void blkif_completion(struct blk_shadow *s, st=
ruct blkfront_info *info,
>  	}
>  	/* Add the persistent grant into the list of free grants */
>  	for (i =3D 0; i < s->req.u.rw.nr_segments; i++) {
> -		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
> +		list_add(&s->grants_used[i]->node, &info->persistent_gnts);
>  		info->persistent_gnts_c++;
>  	}
>  }
> @@ -1164,7 +1165,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev =3D dev;
>  	info->vdevice =3D vdevice;
> -	init_llist_head(&info->persistent_gnts);
> +	INIT_LIST_HEAD(&info->persistent_gnts);
>  	info->persistent_gnts_c =3D 0;
>  	info->connected =3D BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index d0ab98f..a5199f6 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -125,31 +125,6 @@ static inline void init_llist_head(struct llist_head=
 *list)
>  	     (pos) =3D llist_entry((pos)->member.next, typeof(*(pos)), member))
>  =

>  /**
> - * llist_for_each_entry_safe - iterate safely against remove over some e=
ntries
> - * of lock-less list of given type.
> - * @pos:	the type * to use as a loop cursor.
> - * @n:		another type * to use as a temporary storage.
> - * @node:	the fist entry of deleted list entries.
> - * @member:	the name of the llist_node with the struct.
> - *
> - * In general, some entries of the lock-less list can be traversed
> - * safely only after being removed from list, so start with an entry
> - * instead of list head. This variant allows removal of entries
> - * as we iterate.
> - *
> - * If being used on entries deleted from lock-less list directly, the
> - * traverse order is from the newest to the oldest added entry.  If
> - * you want to traverse from the oldest to the newest, you must
> - * reverse the order by yourself before traversing.
> - */
> -#define llist_for_each_entry_safe(pos, n, node, member)		\
> -	for ((pos) =3D llist_entry((node), typeof(*(pos)), member),	\
> -	     (n) =3D (pos)->member.next;					\
> -	     &(pos)->member !=3D NULL;					\
> -	     (pos) =3D llist_entry(n, typeof(*(pos)), member),		\
> -	     (n) =3D (&(pos)->member !=3D NULL) ? (pos)->member.next : NULL)
> -
> -/**
>   * llist_empty - tests whether a lock-less list is empty
>   * @head:	the list to test
>   *
> -- =

> 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 Feb 15 19:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 19:04: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 1U6QaL-0005xE-1P; Fri, 15 Feb 2013 19:04:37 +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 1U6QaJ-0005x7-P0
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 19:04:35 +0000
Received: from [85.158.139.211:25731] by server-9.bemta-5.messagelabs.com id
	BA/3B-24440-3C68E115; Fri, 15 Feb 2013 19:04:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360955073!22573799!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24873 invoked from network); 15 Feb 2013 19:04:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 19:04:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7741344"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 19:04:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 14:04:27 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6QaB-0008Q9-1T;
	Fri, 15 Feb 2013 19:04:27 +0000
Message-ID: <1360955067.16636.201.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 15 Feb 2013 19:04:27 +0000
In-Reply-To: <511E829B.8020800@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1360952378.16636.195.camel@zion.uk.xensource.com>
	<511E829B.8020800@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 18:46 +0000, David Vrabel wrote:
> On 15/02/13 18:19, Wei Liu wrote:
> > Apart from the TAIL field, I have some comments on the hypercall
> > interface. Please see inline comments.
> > 
> > On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> >>
> >> ### `EVTCHNOP_init_control`
> >>
> >> This call initializes a single VCPU's control block.
> >>
> >> A guest should call this during initial VCPU bring up.  The guest must
> >> have already successfully registered a vcpu_info structure and the
> >> control block must be in the same page.
> >>
> >> If this call fails on the boot VCPU, the guest should continue to use
> >> the 2-level event channel ABI for all VCPUs.  If this call fails on
> >> any non-boot VCPU then the VCPU will be unable to receive events and
> >> the guest should offline the VCPU.
> >>
> > 
> > Why offline this CPU? This call only registers control block, we can
> > switch back to use 2-level for all CPUs.
> 
> Because switching back for the other VCPUs is potentially impossible (we
> may have hotplugged this new VCPU and more than 4096 event channels may
> be currently in use).  It would also require migrating events between
> the new and old data structures which is hard.
> 

If you hot plug a vcpu, can it possibly bypass the cpu_possible_map
limit?

VCPU info placement call is issued for all possible CPU's, in this case,
you can have new ABI setup for all possible CPUs at start-of-day, so
there is no migration needed.

> I would expect this call to never fail in normal operation (except on
> the boot VCPU where support may be missing).  i.e., it will only fail if
> xenheap or map space is exhausted.  Both the xenheap and the map space
> should be large enough so we run out of other resources (e.g,, domheap)
> first.
> 
[snip]
> 
> The boot VCPU shall have successfully initialized its control block.  I
> don't think there are any other restrictions on this call.
> 

So do you mean that this is only called when guest starts?


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 19:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 19:04: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 1U6QaL-0005xE-1P; Fri, 15 Feb 2013 19:04:37 +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 1U6QaJ-0005x7-P0
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 19:04:35 +0000
Received: from [85.158.139.211:25731] by server-9.bemta-5.messagelabs.com id
	BA/3B-24440-3C68E115; Fri, 15 Feb 2013 19:04:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1360955073!22573799!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24873 invoked from network); 15 Feb 2013 19:04:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 19:04:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7741344"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 19:04:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 14:04:27 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6QaB-0008Q9-1T;
	Fri, 15 Feb 2013 19:04:27 +0000
Message-ID: <1360955067.16636.201.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 15 Feb 2013 19:04:27 +0000
In-Reply-To: <511E829B.8020800@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1360952378.16636.195.camel@zion.uk.xensource.com>
	<511E829B.8020800@citrix.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 18:46 +0000, David Vrabel wrote:
> On 15/02/13 18:19, Wei Liu wrote:
> > Apart from the TAIL field, I have some comments on the hypercall
> > interface. Please see inline comments.
> > 
> > On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> >>
> >> ### `EVTCHNOP_init_control`
> >>
> >> This call initializes a single VCPU's control block.
> >>
> >> A guest should call this during initial VCPU bring up.  The guest must
> >> have already successfully registered a vcpu_info structure and the
> >> control block must be in the same page.
> >>
> >> If this call fails on the boot VCPU, the guest should continue to use
> >> the 2-level event channel ABI for all VCPUs.  If this call fails on
> >> any non-boot VCPU then the VCPU will be unable to receive events and
> >> the guest should offline the VCPU.
> >>
> > 
> > Why offline this CPU? This call only registers control block, we can
> > switch back to use 2-level for all CPUs.
> 
> Because switching back for the other VCPUs is potentially impossible (we
> may have hotplugged this new VCPU and more than 4096 event channels may
> be currently in use).  It would also require migrating events between
> the new and old data structures which is hard.
> 

If you hot plug a vcpu, can it possibly bypass the cpu_possible_map
limit?

VCPU info placement call is issued for all possible CPU's, in this case,
you can have new ABI setup for all possible CPUs at start-of-day, so
there is no migration needed.

> I would expect this call to never fail in normal operation (except on
> the boot VCPU where support may be missing).  i.e., it will only fail if
> xenheap or map space is exhausted.  Both the xenheap and the map space
> should be large enough so we run out of other resources (e.g,, domheap)
> first.
> 
[snip]
> 
> The boot VCPU shall have successfully initialized its control block.  I
> don't think there are any other restrictions on this call.
> 

So do you mean that this is only called when guest starts?


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 19:12:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 19:12: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 1U6Qi1-0006Eq-5E; Fri, 15 Feb 2013 19:12:33 +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 1U6Qi0-0006El-5e
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 19:12:32 +0000
Received: from [85.158.139.211:30136] by server-5.bemta-5.messagelabs.com id
	C6/33-11945-F988E115; Fri, 15 Feb 2013 19:12:31 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360955550!22276062!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32633 invoked from network); 15 Feb 2013 19:12:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 19:12:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="1527701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 19:12:31 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Fri, 15 Feb 2013 19:12:30 +0000
Message-ID: <511E88B4.7060205@citrix.com>
Date: Fri, 15 Feb 2013 20:12:52 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
In-Reply-To: <20130215185644.GB29539@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
>> Should be backported to 3.8 stable.
> 
> Lets do one thing at a time.
> 
> The patch I have in the tree (and that I've asked Jens to pull for 3.9 - so
> he might have already in his tree) is the old hybrid where we still use llist
> but change the loop from 'for' to 'while'.
> 
> This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
> 
> Could you rebase your patch on top of that tree and just simplify the loop?
> 
> Sorry about the mess about this - but I had already pulled the trigger
> so to say - hoping that Jens would pull the tree and do a git pull to Linus.
> 
> And you are absolutly sure that we don't need any extra locking when switching
> over to list_head? Say if blkif_completion is called while we are
> processing in blkif_queue_request and doing ?

Will recheck it, but blkif_completition is called with the io_lock hold,
as does blkif_queue_request (I've added extra assert_spin_locked before
every list modification).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 19:12:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 19:12: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 1U6Qi1-0006Eq-5E; Fri, 15 Feb 2013 19:12:33 +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 1U6Qi0-0006El-5e
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 19:12:32 +0000
Received: from [85.158.139.211:30136] by server-5.bemta-5.messagelabs.com id
	C6/33-11945-F988E115; Fri, 15 Feb 2013 19:12:31 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1360955550!22276062!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNzgw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32633 invoked from network); 15 Feb 2013 19:12:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 19:12:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="1527701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Feb 2013 19:12:31 +0000
Received: from Roger-2.local (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Fri, 15 Feb 2013 19:12:30 +0000
Message-ID: <511E88B4.7060205@citrix.com>
Date: Fri, 15 Feb 2013 20:12:52 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
In-Reply-To: <20130215185644.GB29539@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
>> Should be backported to 3.8 stable.
> 
> Lets do one thing at a time.
> 
> The patch I have in the tree (and that I've asked Jens to pull for 3.9 - so
> he might have already in his tree) is the old hybrid where we still use llist
> but change the loop from 'for' to 'while'.
> 
> This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
> 
> Could you rebase your patch on top of that tree and just simplify the loop?
> 
> Sorry about the mess about this - but I had already pulled the trigger
> so to say - hoping that Jens would pull the tree and do a git pull to Linus.
> 
> And you are absolutly sure that we don't need any extra locking when switching
> over to list_head? Say if blkif_completion is called while we are
> processing in blkif_queue_request and doing ?

Will recheck it, but blkif_completition is called with the io_lock hold,
as does blkif_queue_request (I've added extra assert_spin_locked before
every list modification).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 19:51:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 19:51: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 1U6RJI-0006oM-Hb; Fri, 15 Feb 2013 19:51: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 1U6RJG-0006mT-Qo
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 19:51:03 +0000
Received: from [85.158.143.99:48580] by server-2.bemta-4.messagelabs.com id
	CC/8C-01597-6A19E115; Fri, 15 Feb 2013 19:51:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360957856!17960141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5571 invoked from network); 15 Feb 2013 19:50:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 19:50:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7751412"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 19:50:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 14:50:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6RJ9-0000gx-5I;
	Fri, 15 Feb 2013 19:50:55 +0000
Date: Fri, 15 Feb 2013 19:50:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1360954157-4412-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1302151949490.8231@kaball.uk.xensource.com>
References: <1360954157-4412-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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] [PATCH 2/4] xen/arm: do not use is_running to
 decide whether we can write directly to the LR registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 15 Feb 2013, Stefano Stabellini wrote:
> During context switch is_running is set for the next vcpu before the
> gic state is actually saved.
> This leads to possible nasty races when interrupts need to be injected
> after is_running is set to the next vcpu but before the currently
> running gic state has been saved from the previous vcpu.
> Introduce a new gic_running internal variable to precisely determine
> which one is the vcpu currently using the gic.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Although the description of the problem is accurate, the fix doesn't
take SMP into consideration. Probably gic_running needs to be a per_cpu
variable.
In any case, I'll rework and resent the patch.


>  xen/arch/arm/gic.c |    8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 0ecc0f1..88f2d3a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -53,6 +53,7 @@ static irq_desc_t irq_desc[NR_IRQS];
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>  static gic_callback_fn_t gic_callbacks[NR_IRQS];
> +static struct vcpu *gic_running;
>  
>  unsigned nr_lrs;
>  
> @@ -70,6 +71,7 @@ void gic_save_state(struct vcpu *v)
>      for ( i=0; i<nr_lrs; i++)
>          v->arch.gic_lr[i] = GICH[GICH_LR + i];
>      v->arch.lr_mask = this_cpu(lr_mask);
> +    gic_running = NULL;
>      spin_unlock_irq(&gic.lock);
>      /* Disable until next VCPU scheduled */
>      GICH[GICH_HCR] = 0;
> @@ -81,12 +83,16 @@ void gic_restore_state(struct vcpu *v)
>      int i;
>  
>      if ( is_idle_vcpu(v) )
> +    {
> +        gic_running = v;
>          return;
> +    }
>  
>      spin_lock_irq(&gic.lock);
>      this_cpu(lr_mask) = v->arch.lr_mask;
>      for ( i=0; i<nr_lrs; i++)
>          GICH[GICH_LR + i] = v->arch.gic_lr[i];
> +    gic_running = v;
>      spin_unlock_irq(&gic.lock);
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      isb();
> @@ -481,7 +487,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>  
>      spin_lock_irqsave(&gic.lock, flags);
>  
> -    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
> +    if ( v == gic_running && list_empty(&v->arch.vgic.lr_pending) )
>      {
>          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
>          if (i < nr_lrs) {
> -- 
> 1.7.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 Feb 15 19:51:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 19:51: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 1U6RJI-0006oM-Hb; Fri, 15 Feb 2013 19:51: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 1U6RJG-0006mT-Qo
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 19:51:03 +0000
Received: from [85.158.143.99:48580] by server-2.bemta-4.messagelabs.com id
	CC/8C-01597-6A19E115; Fri, 15 Feb 2013 19:51:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1360957856!17960141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTkwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5571 invoked from network); 15 Feb 2013 19:50:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 19:50:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; 
   d="scan'208";a="7751412"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	15 Feb 2013 19:50:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 15 Feb 2013 14:50:55 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U6RJ9-0000gx-5I;
	Fri, 15 Feb 2013 19:50:55 +0000
Date: Fri, 15 Feb 2013 19:50:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1360954157-4412-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1302151949490.8231@kaball.uk.xensource.com>
References: <1360954157-4412-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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] [PATCH 2/4] xen/arm: do not use is_running to
 decide whether we can write directly to the LR registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 15 Feb 2013, Stefano Stabellini wrote:
> During context switch is_running is set for the next vcpu before the
> gic state is actually saved.
> This leads to possible nasty races when interrupts need to be injected
> after is_running is set to the next vcpu but before the currently
> running gic state has been saved from the previous vcpu.
> Introduce a new gic_running internal variable to precisely determine
> which one is the vcpu currently using the gic.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Although the description of the problem is accurate, the fix doesn't
take SMP into consideration. Probably gic_running needs to be a per_cpu
variable.
In any case, I'll rework and resent the patch.


>  xen/arch/arm/gic.c |    8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 0ecc0f1..88f2d3a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -53,6 +53,7 @@ static irq_desc_t irq_desc[NR_IRQS];
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>  static gic_callback_fn_t gic_callbacks[NR_IRQS];
> +static struct vcpu *gic_running;
>  
>  unsigned nr_lrs;
>  
> @@ -70,6 +71,7 @@ void gic_save_state(struct vcpu *v)
>      for ( i=0; i<nr_lrs; i++)
>          v->arch.gic_lr[i] = GICH[GICH_LR + i];
>      v->arch.lr_mask = this_cpu(lr_mask);
> +    gic_running = NULL;
>      spin_unlock_irq(&gic.lock);
>      /* Disable until next VCPU scheduled */
>      GICH[GICH_HCR] = 0;
> @@ -81,12 +83,16 @@ void gic_restore_state(struct vcpu *v)
>      int i;
>  
>      if ( is_idle_vcpu(v) )
> +    {
> +        gic_running = v;
>          return;
> +    }
>  
>      spin_lock_irq(&gic.lock);
>      this_cpu(lr_mask) = v->arch.lr_mask;
>      for ( i=0; i<nr_lrs; i++)
>          GICH[GICH_LR + i] = v->arch.gic_lr[i];
> +    gic_running = v;
>      spin_unlock_irq(&gic.lock);
>      GICH[GICH_HCR] = GICH_HCR_EN;
>      isb();
> @@ -481,7 +487,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
>  
>      spin_lock_irqsave(&gic.lock, flags);
>  
> -    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
> +    if ( v == gic_running && list_empty(&v->arch.vgic.lr_pending) )
>      {
>          i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
>          if (i < nr_lrs) {
> -- 
> 1.7.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 Feb 15 20:08:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 20: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 1U6RZR-00077z-4b; Fri, 15 Feb 2013 20:07:45 +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 1U6RZO-00077s-Qt
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 20:07:43 +0000
Received: from [85.158.143.35:64881] by server-2.bemta-4.messagelabs.com id
	37/3B-01597-E859E115; Fri, 15 Feb 2013 20:07:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360958845!12399902!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5706 invoked from network); 15 Feb 2013 20:07:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-21.messagelabs.com with SMTP;
	15 Feb 2013 20:07:26 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5rDWwSHkAos=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-072-132.pools.arcor-ip.net [88.65.72.132])
	by smtp.strato.de (jored mo45) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 600e37p1FJvqmz
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 21:07:25 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 070731863F
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 21:07:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 83a05c99299d60197fbb7eac219054b371d61eff
Message-Id: <83a05c99299d60197fbb.1360958844@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Fri, 15 Feb 2013 21:07:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: print messages from xc_save with
	xc_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360958742 -3600
# Node ID 83a05c99299d60197fbb7eac219054b371d61eff
# Parent  6ff99ddc4c41af31863393cd2239bc03fb63642c
tools/xc: print messages from xc_save with xc_report

Make use of xc_report in xc_save to log also pid if some error occoured.
Rework code in switch_qemu_logdirty, fix memleak.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6ff99ddc4c41 -r 83a05c99299d tools/libxc/xc_private.h
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -119,6 +119,7 @@ void xc_report_progress_step(xc_interfac
 
 /* anamorphic macros:  struct xc_interface *xch  must be in scope */
 
+#define WPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_WARN,0, _f , ## _a)
 #define IPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_INFO,0, _f , ## _a)
 #define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DETAIL,0, _f , ## _a)
 #define DBGPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DEBUG,0, _f , ## _a)
diff -r 6ff99ddc4c41 -r 83a05c99299d tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -56,6 +56,7 @@ main(int argc, char **argv)
 
     if ( ret == 0 )
     {
+	/* xend expects this output, part of protocol */
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
diff -r 6ff99ddc4c41 -r 83a05c99299d tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -7,6 +7,7 @@
  *
  */
 
+#define _GNU_SOURCE
 #include <err.h>
 #include <stdlib.h>
 #include <stdint.h>
@@ -19,6 +20,7 @@
 #include <fcntl.h>
 #include <err.h>
 
+#include <xc_private.h>
 #include <xenstore.h>
 #include <xenctrl.h>
 #include <xenguest.h>
@@ -51,16 +53,17 @@ static int compat_suspend(void)
  * receive the acknowledgement from the subscribe event channel. */
 static int evtchn_suspend(void)
 {
+    xc_interface *xch = si.xch;
     int rc;
 
     rc = xc_evtchn_notify(si.xce, si.suspend_evtchn);
     if (rc < 0) {
-        warnx("failed to notify suspend request channel: %d", rc);
+        WPRINTF("failed to notify suspend request channel: %d", rc);
         return 0;
     }
 
     if (xc_await_suspend(si.xch, si.xce, si.suspend_evtchn) < 0) {
-        warnx("suspend failed");
+        WPRINTF("suspend failed");
         return 0;
     }
 
@@ -104,61 +107,66 @@ static int suspend(void* data)
 
 static int switch_qemu_logdirty(int domid, unsigned int enable, void *data)
 {
+    xc_interface *xch = si.xch;
     struct xs_handle *xs;
-    char *path, *p, *ret_str, *cmd_str, **watch;
+    char *path, *p, *ret_str, **watch;
+    const char *cmd_str;
     unsigned int len;
+    int ret, again;
     struct timeval tv;
     fd_set fdset;
 
-    if ((xs = xs_daemon_open()) == NULL)
-        errx(1, "Couldn't contact xenstore");
-    if (!(path = strdup("/local/domain/0/device-model/")))
-        errx(1, "can't get domain path in store");
-    if (!(path = realloc(path, strlen(path) 
-                         + 10 
-                         + strlen("/logdirty/cmd") + 1)))
-        errx(1, "no memory for constructing xenstore path");
-    snprintf(path + strlen(path), 11, "%i", domid);
-    strcat(path, "/logdirty/");
-    p = path + strlen(path);
+    if ((xs = xs_daemon_open()) == NULL) {
+        PERROR("Couldn't contact xenstore");
+        exit(1);
+    }
 
+    ret = asprintf(&path, "/local/domain/0/device-model/%i/logdirty/ret", domid);
+    if (ret < 0) {
+        ERROR("no memory for constructing xenstore path");
+        exit(1);
+    }
+    p = path + ret - 3;
 
     /* Watch for qemu's return value */
-    strcpy(p, "ret");
-    if (!xs_watch(xs, path, "qemu-logdirty-ret"))
-        errx(1, "can't set watch in store (%s)\n", path);
+    if (!xs_watch(xs, path, "qemu-logdirty-ret")) {
+        PERROR("can't set watch in store (%s)", path);
+        exit(1);
+    }
 
-    if (!(cmd_str = strdup( enable == 0 ? "disable" : "enable")))
-        errx(1, "can't get logdirty cmd path in store");
+    cmd_str = enable ? "enable" : "disable";
 
-    /* Tell qemu that we want it to start logging dirty page to Xen */
+    /* Tell qemu that we want it to start logging dirty pages to Xen */
     strcpy(p, "cmd");
-    if (!xs_write(xs, XBT_NULL, path, cmd_str, strlen(cmd_str)))
-        errx(1, "can't write  to store path (%s)\n",
-             path);
+    if (!xs_write(xs, XBT_NULL, path, cmd_str, strlen(cmd_str))) {
+        PERROR("can't write to store path (%s)", path);
+        exit(1);
+    }
 
-    /* Wait a while for qemu to signal that it has service logdirty command */
- read_again:
-    tv.tv_sec = 5;
-    tv.tv_usec = 0;
-    FD_ZERO(&fdset);
-    FD_SET(xs_fileno(xs), &fdset);
+    /* Wait a while for qemu to signal that it has serviced logdirty command */
+    do {
+        tv.tv_sec = 5;
+        tv.tv_usec = 0;
+        FD_ZERO(&fdset);
+        FD_SET(xs_fileno(xs), &fdset);
+        errno = 0;
 
-    if ((select(xs_fileno(xs) + 1, &fdset, NULL, NULL, &tv)) != 1)
-        errx(1, "timed out waiting for qemu logdirty response.\n");
-
-    watch = xs_read_watch(xs, &len);
-    free(watch);
-
-    strcpy(p, "ret");
-    ret_str = xs_read(xs, XBT_NULL, path, &len);
-    if (ret_str == NULL || strcmp(ret_str, cmd_str))
+        if ((select(xs_fileno(xs) + 1, &fdset, NULL, NULL, &tv)) != 1) {
+            PERROR("timed out waiting for qemu logdirty response.");
+            exit(1);
+        }
+    
+        watch = xs_read_watch(xs, &len);
+        free(watch);
+    
+        strcpy(p, "ret");
+        ret_str = xs_read(xs, XBT_NULL, path, &len);
+        again = ret_str == NULL || strcmp(ret_str, cmd_str);
+        free(ret_str);
         /* Watch fired but value is not yet right */
-        goto read_again;
+    } while (again);
 
     free(path);
-    free(cmd_str);
-    free(ret_str);
 
     return 0;
 }
@@ -166,6 +174,7 @@ static int switch_qemu_logdirty(int domi
 int
 main(int argc, char **argv)
 {
+    xc_interface *xch;
     unsigned int maxit, max_f, lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
@@ -186,26 +195,26 @@ main(int argc, char **argv)
     lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
     lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
     l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
-    si.xch = xc_interface_open(l, 0, 0);
+    xch = si.xch = xc_interface_open(l, 0, 0);
     if (!si.xch)
         errx(1, "failed to open control interface");
 
     si.xce = xc_evtchn_open(NULL, 0);
     if (si.xce == NULL)
-        warnx("failed to open event channel handle");
+        WPRINTF("failed to open event channel handle");
     else
     {
         port = xs_suspend_evtchn_port(si.domid);
 
         if (port < 0)
-            warnx("failed to get the suspend evtchn port\n");
+            WPRINTF("failed to get the suspend evtchn port\n");
         else
         {
             si.suspend_evtchn =
               xc_suspend_evtchn_init(si.xch, si.xce, si.domid, port);
 
             if (si.suspend_evtchn < 0)
-                warnx("suspend event channel initialization failed, "
+                WPRINTF("suspend event channel initialization failed, "
                        "using slow path");
         }
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 20:08:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 20: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 1U6RZR-00077z-4b; Fri, 15 Feb 2013 20:07:45 +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 1U6RZO-00077s-Qt
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 20:07:43 +0000
Received: from [85.158.143.35:64881] by server-2.bemta-4.messagelabs.com id
	37/3B-01597-E859E115; Fri, 15 Feb 2013 20:07:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1360958845!12399902!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5706 invoked from network); 15 Feb 2013 20:07:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-21.messagelabs.com with SMTP;
	15 Feb 2013 20:07:26 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5rDWwSHkAos=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-072-132.pools.arcor-ip.net [88.65.72.132])
	by smtp.strato.de (jored mo45) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 600e37p1FJvqmz
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 21:07:25 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 070731863F
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 21:07:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 83a05c99299d60197fbb7eac219054b371d61eff
Message-Id: <83a05c99299d60197fbb.1360958844@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Fri, 15 Feb 2013 21:07:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: print messages from xc_save with
	xc_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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1360958742 -3600
# Node ID 83a05c99299d60197fbb7eac219054b371d61eff
# Parent  6ff99ddc4c41af31863393cd2239bc03fb63642c
tools/xc: print messages from xc_save with xc_report

Make use of xc_report in xc_save to log also pid if some error occoured.
Rework code in switch_qemu_logdirty, fix memleak.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6ff99ddc4c41 -r 83a05c99299d tools/libxc/xc_private.h
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -119,6 +119,7 @@ void xc_report_progress_step(xc_interfac
 
 /* anamorphic macros:  struct xc_interface *xch  must be in scope */
 
+#define WPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_WARN,0, _f , ## _a)
 #define IPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_INFO,0, _f , ## _a)
 #define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DETAIL,0, _f , ## _a)
 #define DBGPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DEBUG,0, _f , ## _a)
diff -r 6ff99ddc4c41 -r 83a05c99299d tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -56,6 +56,7 @@ main(int argc, char **argv)
 
     if ( ret == 0 )
     {
+	/* xend expects this output, part of protocol */
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
diff -r 6ff99ddc4c41 -r 83a05c99299d tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -7,6 +7,7 @@
  *
  */
 
+#define _GNU_SOURCE
 #include <err.h>
 #include <stdlib.h>
 #include <stdint.h>
@@ -19,6 +20,7 @@
 #include <fcntl.h>
 #include <err.h>
 
+#include <xc_private.h>
 #include <xenstore.h>
 #include <xenctrl.h>
 #include <xenguest.h>
@@ -51,16 +53,17 @@ static int compat_suspend(void)
  * receive the acknowledgement from the subscribe event channel. */
 static int evtchn_suspend(void)
 {
+    xc_interface *xch = si.xch;
     int rc;
 
     rc = xc_evtchn_notify(si.xce, si.suspend_evtchn);
     if (rc < 0) {
-        warnx("failed to notify suspend request channel: %d", rc);
+        WPRINTF("failed to notify suspend request channel: %d", rc);
         return 0;
     }
 
     if (xc_await_suspend(si.xch, si.xce, si.suspend_evtchn) < 0) {
-        warnx("suspend failed");
+        WPRINTF("suspend failed");
         return 0;
     }
 
@@ -104,61 +107,66 @@ static int suspend(void* data)
 
 static int switch_qemu_logdirty(int domid, unsigned int enable, void *data)
 {
+    xc_interface *xch = si.xch;
     struct xs_handle *xs;
-    char *path, *p, *ret_str, *cmd_str, **watch;
+    char *path, *p, *ret_str, **watch;
+    const char *cmd_str;
     unsigned int len;
+    int ret, again;
     struct timeval tv;
     fd_set fdset;
 
-    if ((xs = xs_daemon_open()) == NULL)
-        errx(1, "Couldn't contact xenstore");
-    if (!(path = strdup("/local/domain/0/device-model/")))
-        errx(1, "can't get domain path in store");
-    if (!(path = realloc(path, strlen(path) 
-                         + 10 
-                         + strlen("/logdirty/cmd") + 1)))
-        errx(1, "no memory for constructing xenstore path");
-    snprintf(path + strlen(path), 11, "%i", domid);
-    strcat(path, "/logdirty/");
-    p = path + strlen(path);
+    if ((xs = xs_daemon_open()) == NULL) {
+        PERROR("Couldn't contact xenstore");
+        exit(1);
+    }
 
+    ret = asprintf(&path, "/local/domain/0/device-model/%i/logdirty/ret", domid);
+    if (ret < 0) {
+        ERROR("no memory for constructing xenstore path");
+        exit(1);
+    }
+    p = path + ret - 3;
 
     /* Watch for qemu's return value */
-    strcpy(p, "ret");
-    if (!xs_watch(xs, path, "qemu-logdirty-ret"))
-        errx(1, "can't set watch in store (%s)\n", path);
+    if (!xs_watch(xs, path, "qemu-logdirty-ret")) {
+        PERROR("can't set watch in store (%s)", path);
+        exit(1);
+    }
 
-    if (!(cmd_str = strdup( enable == 0 ? "disable" : "enable")))
-        errx(1, "can't get logdirty cmd path in store");
+    cmd_str = enable ? "enable" : "disable";
 
-    /* Tell qemu that we want it to start logging dirty page to Xen */
+    /* Tell qemu that we want it to start logging dirty pages to Xen */
     strcpy(p, "cmd");
-    if (!xs_write(xs, XBT_NULL, path, cmd_str, strlen(cmd_str)))
-        errx(1, "can't write  to store path (%s)\n",
-             path);
+    if (!xs_write(xs, XBT_NULL, path, cmd_str, strlen(cmd_str))) {
+        PERROR("can't write to store path (%s)", path);
+        exit(1);
+    }
 
-    /* Wait a while for qemu to signal that it has service logdirty command */
- read_again:
-    tv.tv_sec = 5;
-    tv.tv_usec = 0;
-    FD_ZERO(&fdset);
-    FD_SET(xs_fileno(xs), &fdset);
+    /* Wait a while for qemu to signal that it has serviced logdirty command */
+    do {
+        tv.tv_sec = 5;
+        tv.tv_usec = 0;
+        FD_ZERO(&fdset);
+        FD_SET(xs_fileno(xs), &fdset);
+        errno = 0;
 
-    if ((select(xs_fileno(xs) + 1, &fdset, NULL, NULL, &tv)) != 1)
-        errx(1, "timed out waiting for qemu logdirty response.\n");
-
-    watch = xs_read_watch(xs, &len);
-    free(watch);
-
-    strcpy(p, "ret");
-    ret_str = xs_read(xs, XBT_NULL, path, &len);
-    if (ret_str == NULL || strcmp(ret_str, cmd_str))
+        if ((select(xs_fileno(xs) + 1, &fdset, NULL, NULL, &tv)) != 1) {
+            PERROR("timed out waiting for qemu logdirty response.");
+            exit(1);
+        }
+    
+        watch = xs_read_watch(xs, &len);
+        free(watch);
+    
+        strcpy(p, "ret");
+        ret_str = xs_read(xs, XBT_NULL, path, &len);
+        again = ret_str == NULL || strcmp(ret_str, cmd_str);
+        free(ret_str);
         /* Watch fired but value is not yet right */
-        goto read_again;
+    } while (again);
 
     free(path);
-    free(cmd_str);
-    free(ret_str);
 
     return 0;
 }
@@ -166,6 +174,7 @@ static int switch_qemu_logdirty(int domi
 int
 main(int argc, char **argv)
 {
+    xc_interface *xch;
     unsigned int maxit, max_f, lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
@@ -186,26 +195,26 @@ main(int argc, char **argv)
     lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
     lflags = XTL_STDIOSTREAM_SHOW_PID | XTL_STDIOSTREAM_HIDE_PROGRESS;
     l = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, lvl, lflags);
-    si.xch = xc_interface_open(l, 0, 0);
+    xch = si.xch = xc_interface_open(l, 0, 0);
     if (!si.xch)
         errx(1, "failed to open control interface");
 
     si.xce = xc_evtchn_open(NULL, 0);
     if (si.xce == NULL)
-        warnx("failed to open event channel handle");
+        WPRINTF("failed to open event channel handle");
     else
     {
         port = xs_suspend_evtchn_port(si.domid);
 
         if (port < 0)
-            warnx("failed to get the suspend evtchn port\n");
+            WPRINTF("failed to get the suspend evtchn port\n");
         else
         {
             si.suspend_evtchn =
               xc_suspend_evtchn_init(si.xch, si.xce, si.domid, port);
 
             if (si.suspend_evtchn < 0)
-                warnx("suspend event channel initialization failed, "
+                WPRINTF("suspend event channel initialization failed, "
                        "using slow path");
         }
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 20:37:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 20:37: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 1U6S1V-0007aH-LD; Fri, 15 Feb 2013 20:36:45 +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 1U6S1U-0007aA-Jl
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 20:36:44 +0000
Received: from [85.158.143.35:44248] by server-3.bemta-4.messagelabs.com id
	2E/FF-08920-B5C9E115; Fri, 15 Feb 2013 20:36:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360960602!13284207!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28022 invoked from network); 15 Feb 2013 20:36:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with SMTP;
	15 Feb 2013 20:36:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5rDWwSHkAos=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-072-132.pools.arcor-ip.net [88.65.72.132])
	by smtp.strato.de (jored mo36) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x00c85p1FJCerM
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 21:36:42 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 117CB1884C; Fri, 15 Feb 2013 21:36:41 +0100 (CET)
Date: Fri, 15 Feb 2013 21:36:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130215203641.GA15504@aepfle.de>
References: <83a05c99299d60197fbb.1360958844@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <83a05c99299d60197fbb.1360958844@probook.site>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: Re: [Xen-devel] [PATCH] tools/xc: print messages from xc_save with
 xc_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 Fri, Feb 15, Olaf Hering wrote:

> +++ b/tools/xcutils/xc_save.c

>      si.xce = xc_evtchn_open(NULL, 0);
>      if (si.xce == NULL)
> -        warnx("failed to open event channel handle");
> +        WPRINTF("failed to open event channel handle");
>      else
>      {
>          port = xs_suspend_evtchn_port(si.domid);
>  
>          if (port < 0)
> -            warnx("failed to get the suspend evtchn port\n");
> +            WPRINTF("failed to get the suspend evtchn port\n");
>          else
>          {
>              si.suspend_evtchn =
>                xc_suspend_evtchn_init(si.xch, si.xce, si.domid, port);
>  
>              if (si.suspend_evtchn < 0)
> -                warnx("suspend event channel initialization failed, "
> +                WPRINTF("suspend event channel initialization failed, "
>                         "using slow path");
>          }

Is this path well tested, or should these three be fatal errors?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 20:37:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 20:37: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 1U6S1V-0007aH-LD; Fri, 15 Feb 2013 20:36:45 +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 1U6S1U-0007aA-Jl
	for xen-devel@lists.xen.org; Fri, 15 Feb 2013 20:36:44 +0000
Received: from [85.158.143.35:44248] by server-3.bemta-4.messagelabs.com id
	2E/FF-08920-B5C9E115; Fri, 15 Feb 2013 20:36:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360960602!13284207!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28022 invoked from network); 15 Feb 2013 20:36:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with SMTP;
	15 Feb 2013 20:36:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5rDWwSHkAos=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-072-132.pools.arcor-ip.net [88.65.72.132])
	by smtp.strato.de (jored mo36) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x00c85p1FJCerM
	for <xen-devel@lists.xen.org>; Fri, 15 Feb 2013 21:36:42 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 117CB1884C; Fri, 15 Feb 2013 21:36:41 +0100 (CET)
Date: Fri, 15 Feb 2013 21:36:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130215203641.GA15504@aepfle.de>
References: <83a05c99299d60197fbb.1360958844@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <83a05c99299d60197fbb.1360958844@probook.site>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: Re: [Xen-devel] [PATCH] tools/xc: print messages from xc_save with
 xc_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 Fri, Feb 15, Olaf Hering wrote:

> +++ b/tools/xcutils/xc_save.c

>      si.xce = xc_evtchn_open(NULL, 0);
>      if (si.xce == NULL)
> -        warnx("failed to open event channel handle");
> +        WPRINTF("failed to open event channel handle");
>      else
>      {
>          port = xs_suspend_evtchn_port(si.domid);
>  
>          if (port < 0)
> -            warnx("failed to get the suspend evtchn port\n");
> +            WPRINTF("failed to get the suspend evtchn port\n");
>          else
>          {
>              si.suspend_evtchn =
>                xc_suspend_evtchn_init(si.xch, si.xce, si.domid, port);
>  
>              if (si.suspend_evtchn < 0)
> -                warnx("suspend event channel initialization failed, "
> +                WPRINTF("suspend event channel initialization failed, "
>                         "using slow path");
>          }

Is this path well tested, or should these three be fatal errors?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 21:55:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6TFH-0000AQ-Ri; Fri, 15 Feb 2013 21:55:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6TFG-0000AL-AT
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 21:55:02 +0000
Received: from [85.158.139.83:45355] by server-16.bemta-5.messagelabs.com id
	E1/67-14948-5BEAE115; Fri, 15 Feb 2013 21:55:01 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360965297!27515026!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8396 invoked from network); 15 Feb 2013 21:54:57 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 21:54:57 -0000
Received: by mail-ee0-f43.google.com with SMTP id c50so2022735eek.2
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Feb 2013 13:54:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=Ak0Tb0SPfqaO3T3quI3jCiWcDGcshTut0nY4BNF43ys=;
	b=NHDNqYokNdE+gRv2eAkJORv32FB82hBtK/X9eg+vTMf0UjQrjizlV4JlaQSaXNnR1I
	+BclaT5ywZafQhswFJhI2BIFUOoy/yX3CiJOgSiz9dQlPUXey/OUyJmOMbc44eM9n7nr
	r6tRd/0bTj94p4cRzST/TtBH/LGSCtoQoPIGannBXTQHtPyFTqyeGWC4VjjNX7tOSeIU
	c3PIM8HWn/IZz0LhjUpWiBICPWl7+qzCWaK4uZULOHKwbvLZWcj0DEWgG3nYAvbAHATQ
	5ZrGUZqsWcQzlw8hiHl367aQ4TSrsPXGcjOASoJkUUNBNuxeOZwVuE2lgGqi0jYzFjbK
	Cyhw==
X-Received: by 10.14.179.194 with SMTP id h42mr12664525eem.46.1360965296898;
	Fri, 15 Feb 2013 13:54:56 -0800 (PST)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it. [87.4.79.231])
	by mx.google.com with ESMTPS id a1sm60317871eep.2.2013.02.15.13.54.54
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 13:54:56 -0800 (PST)
Message-ID: <511EAEA9.5040109@heliman.it>
Date: Fri, 15 Feb 2013 22:54:49 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
In-Reply-To: <20766.22732.806518.892544@mariner.uk.xensource.com>
X-Gm-Message-State: ALoCoQnDf3zpvvqAqOWTKFprKUts3cxSvof5BVwUdmt+paHFqrrpQCuf1lesI4Jbqj2q7XUcYXRT
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, fantonifabio@tiscali.it
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Il 15/02/2013 16:48, Ian Jackson ha scritto:
> fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>
>> Usage:
>>    vga="stdvga"|"cirrus"
>>
>> - Default option is cirrus.
>> - Prints error and exit if unknown value is passed.
>> - stdvga parameter is now deprecated.
>> - Updated xl.cfg man.
>>
>> Required patch: Improve videoram setting v5
>> Is prerequisite for patch: Add qxl support v9
> The code looks good to me, but there are a couple of formatting
> problems.  Your wrapping of the longer lines is odd (particularly, you
> fail to indent the continuations), and there's a spurious space after
> xlu_cfg_get_string.  Can you please repost following the style used
> elsewhere ?
>
> Thanks,
> Ian.
Sorry.
Can you explain me the error of indentation did I do please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 15 21:55:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 15 Feb 2013 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 1U6TFH-0000AQ-Ri; Fri, 15 Feb 2013 21:55:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6TFG-0000AL-AT
	for xen-devel@lists.xensource.com; Fri, 15 Feb 2013 21:55:02 +0000
Received: from [85.158.139.83:45355] by server-16.bemta-5.messagelabs.com id
	E1/67-14948-5BEAE115; Fri, 15 Feb 2013 21:55:01 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1360965297!27515026!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8396 invoked from network); 15 Feb 2013 21:54:57 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Feb 2013 21:54:57 -0000
Received: by mail-ee0-f43.google.com with SMTP id c50so2022735eek.2
	for <xen-devel@lists.xensource.com>;
	Fri, 15 Feb 2013 13:54:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=Ak0Tb0SPfqaO3T3quI3jCiWcDGcshTut0nY4BNF43ys=;
	b=NHDNqYokNdE+gRv2eAkJORv32FB82hBtK/X9eg+vTMf0UjQrjizlV4JlaQSaXNnR1I
	+BclaT5ywZafQhswFJhI2BIFUOoy/yX3CiJOgSiz9dQlPUXey/OUyJmOMbc44eM9n7nr
	r6tRd/0bTj94p4cRzST/TtBH/LGSCtoQoPIGannBXTQHtPyFTqyeGWC4VjjNX7tOSeIU
	c3PIM8HWn/IZz0LhjUpWiBICPWl7+qzCWaK4uZULOHKwbvLZWcj0DEWgG3nYAvbAHATQ
	5ZrGUZqsWcQzlw8hiHl367aQ4TSrsPXGcjOASoJkUUNBNuxeOZwVuE2lgGqi0jYzFjbK
	Cyhw==
X-Received: by 10.14.179.194 with SMTP id h42mr12664525eem.46.1360965296898;
	Fri, 15 Feb 2013 13:54:56 -0800 (PST)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it. [87.4.79.231])
	by mx.google.com with ESMTPS id a1sm60317871eep.2.2013.02.15.13.54.54
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 15 Feb 2013 13:54:56 -0800 (PST)
Message-ID: <511EAEA9.5040109@heliman.it>
Date: Fri, 15 Feb 2013 22:54:49 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
In-Reply-To: <20766.22732.806518.892544@mariner.uk.xensource.com>
X-Gm-Message-State: ALoCoQnDf3zpvvqAqOWTKFprKUts3cxSvof5BVwUdmt+paHFqrrpQCuf1lesI4Jbqj2q7XUcYXRT
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, fantonifabio@tiscali.it
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Il 15/02/2013 16:48, Ian Jackson ha scritto:
> fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>
>> Usage:
>>    vga="stdvga"|"cirrus"
>>
>> - Default option is cirrus.
>> - Prints error and exit if unknown value is passed.
>> - stdvga parameter is now deprecated.
>> - Updated xl.cfg man.
>>
>> Required patch: Improve videoram setting v5
>> Is prerequisite for patch: Add qxl support v9
> The code looks good to me, but there are a couple of formatting
> problems.  Your wrapping of the longer lines is odd (particularly, you
> fail to indent the continuations), and there's a spurious space after
> xlu_cfg_get_string.  Can you please repost following the style used
> elsewhere ?
>
> Thanks,
> Ian.
Sorry.
Can you explain me the error of indentation did I do please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 00:18:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 00:18: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 1U6VTR-0002cm-CA; Sat, 16 Feb 2013 00:17:49 +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 1U6VTQ-0002ch-21
	for Xen-devel@lists.xensource.com; Sat, 16 Feb 2013 00:17:48 +0000
Received: from [85.158.137.99:20820] by server-16.bemta-3.messagelabs.com id
	A4/FF-02727-820DE115; Sat, 16 Feb 2013 00:17:44 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360973862!13256760!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29425 invoked from network); 16 Feb 2013 00:17:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2013 00:17:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1G0Hd5f018346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 16 Feb 2013 00:17:40 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
	r1G0Hc9H008444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Feb 2013 00:17:39 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
	r1G0HcLl024425; Fri, 15 Feb 2013 18:17:38 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 16:17:38 -0800
Date: Fri, 15 Feb 2013 16:17:35 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130215161735.0d25c6dd@mantra.us.oracle.com>
In-Reply-To: <20130214103927.GE83752@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@mantra.us.oracle.com>
	<20130214103927.GE83752@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 14/16]: PVH xen: add
 xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013 10:39:27 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:18 -0800 on 11 Feb (1360606704), Mukesh Rathor wrote:
> > > > +        if (!is_hvm_domain(fdom)) {
> > > > +            printk("mmio type for non-hvm domain. fd:%d
> > > > fgmfn:%lx gpfn:%lx\n",
> > > > +                   foreign_domid, fgmfn, gpfn);
> > > > +            return -EINVAL;
> > > > +        }
> > > > +        mfn = fgmfn;     /* map 1 to 1 */
> > > 
> > > Surely not -- you want to map the _actual_ MMIO range, right, not
> > > just whatever GFN-address the foreigh domain mapped it at?
> > 
> > Actually, fgmfn here is the machine address of the mmio page. 
> 
> I hope not!  You've just passed it to a p2m lookup a little earlier,
> so it had better be a gfn.  (And in either case it could do with a
> more explicit name: maybe fmfn if it's an mfn or fgfn if it's a gfn?

Yup, already changed the name to fgfn last week.

>It may be that the memory is genuinely not there - since qemu doesn't
>build the guest itself it doesn't necessarily know exactly where the
>builder put all the memory.

>If that's the case, then just failing the mapping is the right
>response. 

Correct, and thats what PV dom0 does. I had it blatantly wrong! Fixed. 

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 Feb 16 00:18:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 00:18: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 1U6VTR-0002cm-CA; Sat, 16 Feb 2013 00:17:49 +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 1U6VTQ-0002ch-21
	for Xen-devel@lists.xensource.com; Sat, 16 Feb 2013 00:17:48 +0000
Received: from [85.158.137.99:20820] by server-16.bemta-3.messagelabs.com id
	A4/FF-02727-820DE115; Sat, 16 Feb 2013 00:17:44 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1360973862!13256760!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzY3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29425 invoked from network); 16 Feb 2013 00:17:44 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2013 00:17:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1G0Hd5f018346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 16 Feb 2013 00:17:40 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
	r1G0Hc9H008444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Feb 2013 00:17:39 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
	r1G0HcLl024425; Fri, 15 Feb 2013 18:17:38 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 16:17:38 -0800
Date: Fri, 15 Feb 2013 16:17:35 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130215161735.0d25c6dd@mantra.us.oracle.com>
In-Reply-To: <20130214103927.GE83752@ocelot.phlegethon.org>
References: <20130111181103.5bfeed98@mantra.us.oracle.com>
	<20130124173118.GN20551@ocelot.phlegethon.org>
	<20130211181824.169b9d05@mantra.us.oracle.com>
	<20130214103927.GE83752@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 14/16]: PVH xen: add
 xenmem_add_foreign_to_pmap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 14 Feb 2013 10:39:27 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:18 -0800 on 11 Feb (1360606704), Mukesh Rathor wrote:
> > > > +        if (!is_hvm_domain(fdom)) {
> > > > +            printk("mmio type for non-hvm domain. fd:%d
> > > > fgmfn:%lx gpfn:%lx\n",
> > > > +                   foreign_domid, fgmfn, gpfn);
> > > > +            return -EINVAL;
> > > > +        }
> > > > +        mfn = fgmfn;     /* map 1 to 1 */
> > > 
> > > Surely not -- you want to map the _actual_ MMIO range, right, not
> > > just whatever GFN-address the foreigh domain mapped it at?
> > 
> > Actually, fgmfn here is the machine address of the mmio page. 
> 
> I hope not!  You've just passed it to a p2m lookup a little earlier,
> so it had better be a gfn.  (And in either case it could do with a
> more explicit name: maybe fmfn if it's an mfn or fgfn if it's a gfn?

Yup, already changed the name to fgfn last week.

>It may be that the memory is genuinely not there - since qemu doesn't
>build the guest itself it doesn't necessarily know exactly where the
>builder put all the memory.

>If that's the case, then just failing the mapping is the right
>response. 

Correct, and thats what PV dom0 does. I had it blatantly wrong! Fixed. 

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 Feb 16 00:36:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 00:36: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 1U6Vkf-00030S-8a; Sat, 16 Feb 2013 00:35:37 +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 1U6Vkd-00030N-I3
	for Xen-devel@lists.xensource.com; Sat, 16 Feb 2013 00:35:35 +0000
Received: from [85.158.143.35:25256] by server-2.bemta-4.messagelabs.com id
	45/E8-01597-654DE115; Sat, 16 Feb 2013 00:35:34 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360974927!13301603!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI2ODIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 16 Feb 2013 00:35:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2013 00:35:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1G0ZP2T012736
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 16 Feb 2013 00:35:26 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
	r1G0ZPEK013963
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Feb 2013 00:35:25 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
	r1G0ZPYt025724; Fri, 15 Feb 2013 18:35:25 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 16:35:24 -0800
Date: Fri, 15 Feb 2013 16:35:23 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130215163523.28d00600@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]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH]: PVH linux: don't print warning in case of
	failed mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 printing of warning in case of failed mappings. Sometimes
they are expected as in case of Qemu mapping pages during HVM guest
creation.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

---
 arch/x86/xen/mmu.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index fbf6a63..afa6af6 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2499,9 +2499,6 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 	set_xen_guest_handle(xatpr.gpfns, &gpfn);
 
 	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatpr);
-	if (rc)
-		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
-			rc, lpfn, fgmfn);
 	return rc;
 }
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 00:36:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 00:36: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 1U6Vkf-00030S-8a; Sat, 16 Feb 2013 00:35:37 +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 1U6Vkd-00030N-I3
	for Xen-devel@lists.xensource.com; Sat, 16 Feb 2013 00:35:35 +0000
Received: from [85.158.143.35:25256] by server-2.bemta-4.messagelabs.com id
	45/E8-01597-654DE115; Sat, 16 Feb 2013 00:35:34 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1360974927!13301603!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjI2ODIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 16 Feb 2013 00:35:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2013 00:35:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1G0ZP2T012736
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 16 Feb 2013 00:35:26 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
	r1G0ZPEK013963
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Feb 2013 00:35:25 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
	r1G0ZPYt025724; Fri, 15 Feb 2013 18:35:25 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 16:35:24 -0800
Date: Fri, 15 Feb 2013 16:35:23 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130215163523.28d00600@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]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH]: PVH linux: don't print warning in case of
	failed mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 printing of warning in case of failed mappings. Sometimes
they are expected as in case of Qemu mapping pages during HVM guest
creation.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

---
 arch/x86/xen/mmu.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index fbf6a63..afa6af6 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2499,9 +2499,6 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 	set_xen_guest_handle(xatpr.gpfns, &gpfn);
 
 	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatpr);
-	if (rc)
-		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
-			rc, lpfn, fgmfn);
 	return rc;
 }
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 05:39:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 05: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 1U6aUN-0002Qw-TB; Sat, 16 Feb 2013 05:39:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U6aUM-0002Qr-Va
	for xen-devel@lists.xen.org; Sat, 16 Feb 2013 05:39:07 +0000
Received: from [85.158.137.99:59425] by server-4.bemta-3.messagelabs.com id
	F6/DE-17521-97B1F115; Sat, 16 Feb 2013 05:39:05 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360993143!18526577!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzgwMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29320 invoked from network); 16 Feb 2013 05:39:05 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2013 05:39:05 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1G5d0Y0021608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 16 Feb 2013 05:39:01 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
	r1G5cxUW016700
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Feb 2013 05:39:00 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
	r1G5cx80020581; Fri, 15 Feb 2013 23:38:59 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 21:38:59 -0800
Message-ID: <511F1B6D.2010502@oracle.com>
Date: Sat, 16 Feb 2013 13:38:53 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360057377.17017.7.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 02/05/13 17:42, Ian Campbell wrote:
> On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
>> > execute xl-destroy twice crashed my server!
> Can you give more details please.
> 
Hi Ian,

Sorry the server not available for test now.

Would you please help to review my patch for xm-destroy?

Thanks,
Joe

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 05:39:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 05: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 1U6aUN-0002Qw-TB; Sat, 16 Feb 2013 05:39:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U6aUM-0002Qr-Va
	for xen-devel@lists.xen.org; Sat, 16 Feb 2013 05:39:07 +0000
Received: from [85.158.137.99:59425] by server-4.bemta-3.messagelabs.com id
	F6/DE-17521-97B1F115; Sat, 16 Feb 2013 05:39:05 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1360993143!18526577!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzgwMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29320 invoked from network); 16 Feb 2013 05:39:05 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Feb 2013 05:39:05 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1G5d0Y0021608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 16 Feb 2013 05:39:01 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
	r1G5cxUW016700
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 16 Feb 2013 05:39:00 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
	r1G5cx80020581; Fri, 15 Feb 2013 23:38:59 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 15 Feb 2013 21:38:59 -0800
Message-ID: <511F1B6D.2010502@oracle.com>
Date: Sat, 16 Feb 2013 13:38:53 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360057377.17017.7.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 02/05/13 17:42, Ian Campbell wrote:
> On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
>> > execute xl-destroy twice crashed my server!
> Can you give more details please.
> 
Hi Ian,

Sorry the server not available for test now.

Would you please help to review my patch for xm-destroy?

Thanks,
Joe

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 08:58:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 08: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 1U6dax-0005mE-LV; Sat, 16 Feb 2013 08:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1U6dav-0005m9-E4
	for xen-devel@lists.xen.org; Sat, 16 Feb 2013 08:58:05 +0000
Received: from [85.158.138.51:38955] by server-2.bemta-3.messagelabs.com id
	2D/E9-25961-C1A4F115; Sat, 16 Feb 2013 08:58:04 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361005081!9119140!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM2ODc5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20376 invoked from network); 16 Feb 2013 08:58:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-174.messagelabs.com with SMTP;
	16 Feb 2013 08:58:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 16 Feb 2013 00:57:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,678,1355126400"; d="scan'208";a="291962195"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 16 Feb 2013 00:57:59 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 00:57:59 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 16:57:56 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Dong, Eddie" <eddie.dong@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Thread-Topic: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
Thread-Index: AQHOCUF5jxFxc3DI+0+LAbSQsEcIwJh8Mzog
Date: Sat, 16 Feb 2013 08:57:55 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87F4BC7@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
	<511A817B02000078000BDCAC@nat28.tlf.novell.com>
In-Reply-To: <511A817B02000078000BDCAC@nat28.tlf.novell.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="_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jan,
Eddie had already ack the patches.

BR,
Li Jiongxi

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, February 13, 2013 12:53 AM
> To: Dong, Eddie; Nakajima, Jun
> Cc: Keir Fraser; Li, Jiongxi; xen-devel
> Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
>=20
> >>> On 30.01.13 at 04:23, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> > This patchset fixes some APICV issues, including a potential issue
> > while doing live migration and enabling APICV while guest is in X2APIC =
mode.
> >
> > PATCH 1/2: Xen: Fix live migration while enabling APICV.
> >
> > PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling
> APICV.
>=20
> Jun, Eddie - we're still waiting for an ack of at least one of you on the=
se two...
>=20
> Thanks, Jan
>=20
> > Changes v4 to v5
> > Correct coding style. Add debug log in msr enable/disable intercept
> > function for out of range case.
> >
> > Changes v3 to v4
> > According to Jan's comment, add define for numbers used in
> > GUEST_INTR_STATUS, change function name.
> > Use 'set_bit/clear_bit' instead of '__set_bit/__clear_bit'
> >
> > Changes v2 to v3
> > When enabling APICV for x2apic mode, ppr, tmict tmcct MSR read still
> > need to be intercepted.
> >
> > Changes v1 to v2
> > According to Keir's comment, don't change the save/restore order for
> > compatibility.
>=20
>=20


--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Sat, 16 Feb 2013 08:57:53 GMT";
	modification-date="Sat, 16 Feb 2013 08:57:53 GMT"

Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
 SHSMSX151.ccr.corp.intel.com (10.239.6.50) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Thu, 31 Jan 2013 23:07:10 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.181]) by
 SHSMSX101.ccr.corp.intel.com ([169.254.1.236]) with mapi id 14.01.0355.002;
 Thu, 31 Jan 2013 23:07:09 +0800
From: "Dong, Eddie" <eddie.dong@intel.com>
To: "Li, Jiongxi" <jiongxi.li@intel.com>, "'xen-devel@lists.xen.org'"
	<xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
CC: Keir Fraser <keir.xen@gmail.com>, "Dong, Eddie" <eddie.dong@intel.com>
Subject: RE: [Xen-devel] [PATCH v5 1/2] Xen: Fix live migration while
 enabling	APICV
Thread-Topic: [Xen-devel] [PATCH v5 1/2] Xen: Fix live migration while
 enabling	APICV
Thread-Index: Ac3+mKfWcDSdaS3cQOGHEexhpD9N1QBK/H2w
Date: Thu, 31 Jan 2013 15:07:09 +0000
Message-ID: <A12AC9D104E08D47BAF23C492F83C53B23CF8611@SHSMSX102.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62CD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87E62CD@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: SHSMSX101.ccr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Acked by: Eddie Dong <eddie.dong@intel.com>

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Li, Jiongxi
> Sent: Wednesday, January 30, 2013 11:23 AM
> To: 'xen-devel@lists.xen.org'; Jan Beulich
> Cc: Keir Fraser
> Subject: [Xen-devel] [PATCH v5 1/2] Xen: Fix live migration while enablin=
g
> APICV
>
> SVI should be restored in case guest is processing virtual interrupt
> while saveing a domain state. Otherwise SVI would be missed when
> virtual interrupt delivery is enabled.
>
> Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
>
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index ee2294c..38ff216 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1198,6 +1198,9 @@ static int lapic_load_regs(struct domain *d,
> hvm_domain_context_t *h)
>      if ( hvm_load_entry(LAPIC_REGS, h, s->regs) !=3D 0 )
>          return -EINVAL;
>
> +    if ( hvm_funcs.process_isr )
> +        hvm_funcs.process_isr(vlapic_find_highest_isr(s), v);
> +
>      vlapic_adjust_i8259_target(d);
>      lapic_rearm(s);
>      return 0;
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index c5c503e..c961782 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -290,8 +290,8 @@ void vmx_intr_assist(void)
>              vmx_set_eoi_exit_bitmap(v, pt_vector);
>
>          /* we need update the RVI field */
> -        status &=3D ~(unsigned long)0x0FF;
> -        status |=3D (unsigned long)0x0FF &
> +        status &=3D ~VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK;
> +        status |=3D VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK &
>                      intack.vector;
>          __vmwrite(GUEST_INTR_STATUS, status);
>          if (v->arch.hvm_vmx.eoi_exitmap_changed) {
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 4d7c93f..362273b 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1419,6 +1419,29 @@ static int
> vmx_virtual_intr_delivery_enabled(void)
>      return cpu_has_vmx_virtual_intr_delivery;
>  }
>
> +static void vmx_process_isr(int isr, struct vcpu *v)
> +{
> +    unsigned long status;
> +    u8 old;
> +
> +    if ( !cpu_has_vmx_virtual_intr_delivery )
> +        return;
> +
> +    if ( isr < 0 )
> +        isr =3D 0;
> +
> +    vmx_vmcs_enter(v);
> +    status =3D __vmread(GUEST_INTR_STATUS);
> +    old =3D status >> VMX_GUEST_INTR_STATUS_SVI_OFFSET;
> +    if ( isr !=3D old )
> +    {
> +        status &=3D VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK;
> +        status |=3D isr << VMX_GUEST_INTR_STATUS_SVI_OFFSET;
> +        __vmwrite(GUEST_INTR_STATUS, status);
> +    }
> +    vmx_vmcs_exit(v);
> +}
> +
>  static struct hvm_function_table __read_mostly vmx_function_table =3D {
>      .name                 =3D "VMX",
>      .cpu_up_prepare       =3D vmx_cpu_up_prepare,
> @@ -1468,6 +1491,7 @@ static struct hvm_function_table __read_mostly
> vmx_function_table =3D {
>      .nhvm_domain_relinquish_resources =3D
> nvmx_domain_relinquish_resources,
>      .update_eoi_exit_bitmap =3D vmx_update_eoi_exit_bitmap,
>      .virtual_intr_delivery_enabled =3D vmx_virtual_intr_delivery_enabled=
,
> +    .process_isr          =3D vmx_process_isr,
>      .nhvm_hap_walk_L1_p2m =3D nvmx_hap_walk_L1_p2m,
>  };
>
> diff --git a/xen/include/asm-x86/hvm/hvm.h
> b/xen/include/asm-x86/hvm/hvm.h
> index 76e9cc8..011a6a3 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -183,6 +183,7 @@ struct hvm_function_table {
>      /* Virtual interrupt delivery */
>      void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
>      int (*virtual_intr_delivery_enabled)(void);
> +    void (*process_isr)(int isr, struct vcpu *v);
>
>      /*Walk nested p2m  */
>      int (*nhvm_hap_walk_L1_p2m)(struct vcpu *v, paddr_t L2_gpa,
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index 51df81e..d4958c3 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -257,6 +257,10 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
>   */
>  #define VMX_BASIC_DEFAULT1_ZERO              (1ULL << 55)
>
> +/* Guest interrupt status */
> +#define VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK  0x0FF
> +#define VMX_GUEST_INTR_STATUS_SVI_OFFSET        8
> +
>  /* VMCS field encodings. */
>  enum vmcs_field {
>      VIRTUAL_PROCESSOR_ID            =3D 0x00000000,
> --
> 1.7.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Sat, 16 Feb 2013 08:57:54 GMT";
	modification-date="Sat, 16 Feb 2013 08:57:54 GMT"

Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.181]) by
 SHSMSX151.ccr.corp.intel.com ([169.254.3.30]) with mapi id 14.01.0355.002;
 Thu, 31 Jan 2013 23:07:34 +0800
From: "Dong, Eddie" <eddie.dong@intel.com>
To: "Li, Jiongxi" <jiongxi.li@intel.com>, "'xen-devel@lists.xen.org'"
	<xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
CC: Keir Fraser <keir.xen@gmail.com>, "Dong, Eddie" <eddie.dong@intel.com>
Subject: RE: [Xen-devel] [PATCH v5 2/2] Xen: Fix VMCS setting for x2APIC
 mode guest while enabling APICV
Thread-Topic: [Xen-devel] [PATCH v5 2/2] Xen: Fix VMCS setting for x2APIC
 mode guest while enabling APICV
Thread-Index: Ac3+mO4Ykgoi2iucSgy8eIfx4NRuuwBK7iDw
Date: Thu, 31 Jan 2013 15:07:33 +0000
Message-ID: <A12AC9D104E08D47BAF23C492F83C53B23CF862B@SHSMSX102.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62D2@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87E62D2@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: SHSMSX151.ccr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Acked-by: Eddie Dong <eddie.dong@intel.com>

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Li, Jiongxi
> Sent: Wednesday, January 30, 2013 11:24 AM
> To: 'xen-devel@lists.xen.org'; Jan Beulich
> Cc: Keir Fraser
> Subject: [Xen-devel] [PATCH v5 2/2] Xen: Fix VMCS setting for x2APIC mode
> guest while enabling APICV
>
> The "APIC-register virtualization" and "virtual-interrupt deliver"
> VM-execution control has no effect on the behavior of RDMSR/WRMSR if
> the "virtualize x2APIC mode" VM-execution control is 0.
> When guest uses x2APIC mode, we should enable "virtualize x2APIC mode"
> for APICV first.
>
> Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
>
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index de22e03..8abdf6d 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -190,7 +190,8 @@ static int vmx_init_vmcs_config(void)
>           */
>          if ( _vmx_cpu_based_exec_control &
> CPU_BASED_TPR_SHADOW )
>              opt |=3D SECONDARY_EXEC_APIC_REGISTER_VIRT |
> -                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
> +                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
> +                   SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
>
>
>          _vmx_secondary_exec_control =3D adjust_vmx_controls(
> @@ -658,19 +659,60 @@ void vmx_disable_intercept_for_msr(struct vcpu
> *v, u32 msr, int type)
>       */
>      if ( msr <=3D 0x1fff )
>      {
> -        if (type & MSR_TYPE_R)
> -            __clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /*
> read-low */
> -        if (type & MSR_TYPE_W)
> -            __clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /*
> write-low */
> +        if ( type & MSR_TYPE_R )
> +            clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /*
> read-low */
> +        if ( type & MSR_TYPE_W )
> +            clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /*
> write-low */
>      }
>      else if ( (msr >=3D 0xc0000000) && (msr <=3D 0xc0001fff) )
>      {
>          msr &=3D 0x1fff;
> -        if (type & MSR_TYPE_R)
> -            __clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /*
> read-high */
> -        if (type & MSR_TYPE_W)
> -            __clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /*
> write-high */
> +        if ( type & MSR_TYPE_R )
> +            clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /*
> read-high */
> +        if ( type & MSR_TYPE_W )
> +            clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /*
> write-high */
>      }
> +    else
> +        HVM_DBG_LOG(DBG_LEVEL_0,
> +                   "msr %x is out of the control range"
> +                   "0x00000000-0x00001fff and
> 0xc0000000-0xc0001fff"
> +                   "RDMSR or WRMSR will cause a VM exit", msr);
> +
> +}
> +
> +void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
> +{
> +    unsigned long *msr_bitmap =3D v->arch.hvm_vmx.msr_bitmap;
> +
> +    /* VMX MSR bitmap supported? */
> +    if ( msr_bitmap =3D=3D NULL )
> +        return;
> +
> +    /*
> +     * See Intel PRM Vol. 3, 20.6.9 (MSR-Bitmap Address). Early manuals
> +     * have the write-low and read-high bitmap offsets the wrong way
> round.
> +     * We can control MSRs 0x00000000-0x00001fff and
> 0xc0000000-0xc0001fff.
> +     */
> +    if ( msr <=3D 0x1fff )
> +    {
> +        if ( type & MSR_TYPE_R )
> +            set_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /*
> read-low */
> +        if ( type & MSR_TYPE_W )
> +            set_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /*
> write-low */
> +    }
> +    else if ( (msr >=3D 0xc0000000) && (msr <=3D 0xc0001fff) )
> +    {
> +        msr &=3D 0x1fff;
> +        if ( type & MSR_TYPE_R )
> +            set_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /*
> read-high */
> +        if ( type & MSR_TYPE_W )
> +            set_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /*
> write-high */
> +    }
> +    else
> +        HVM_DBG_LOG(DBG_LEVEL_0,
> +                   "msr %x is out of the control range"
> +                   "0x00000000-0x00001fff and
> 0xc0000000-0xc0001fff"
> +                   "RDMSR or WRMSR will cause a VM exit", msr);
>  }
>
>  /*
> @@ -764,6 +806,9 @@ static int construct_vmcs(struct vcpu *v)
>          vmentry_ctl &=3D ~VM_ENTRY_LOAD_GUEST_PAT;
>      }
>
> +    /* Disable Virtualize x2APIC mode by default. */
> +    v->arch.hvm_vmx.secondary_exec_control &=3D
> ~SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
> +
>      /* Do not enable Monitor Trap Flag unless start single step debug */
>      v->arch.hvm_vmx.exec_control &=3D
> ~CPU_BASED_MONITOR_TRAP_FLAG;
>
> @@ -800,18 +845,6 @@ static int construct_vmcs(struct vcpu *v)
>          vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP,
> MSR_TYPE_R | MSR_TYPE_W);
>          if ( cpu_has_vmx_pat && paging_mode_hap(d) )
>              vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT,
> MSR_TYPE_R | MSR_TYPE_W);
> -        if ( cpu_has_vmx_apic_reg_virt )
> -        {
> -            int msr;
> -            for (msr =3D MSR_IA32_APICBASE_MSR; msr <=3D
> MSR_IA32_APICBASE_MSR + 0xff; msr++)
> -                vmx_disable_intercept_for_msr(v, msr, MSR_TYPE_R);
> -        }
> -        if ( cpu_has_vmx_virtual_intr_delivery )
> -        {
> -            vmx_disable_intercept_for_msr(v, MSR_IA32_APICTPR_MSR,
> MSR_TYPE_W);
> -            vmx_disable_intercept_for_msr(v, MSR_IA32_APICEOI_MSR,
> MSR_TYPE_W);
> -            vmx_disable_intercept_for_msr(v, MSR_IA32_APICSELF_MSR,
> MSR_TYPE_W);
> -        }
>      }
>
>      /* I/O access bitmap. */
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 362273b..855a003 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1887,18 +1887,61 @@ static void vmx_install_vlapic_mapping(struct
> vcpu *v)
>
>  void vmx_vlapic_msr_changed(struct vcpu *v)
>  {
> +    int virtualize_x2apic_mode;
>      struct vlapic *vlapic =3D vcpu_vlapic(v);
>
> -    if ( !cpu_has_vmx_virtualize_apic_accesses )
> +    virtualize_x2apic_mode =3D ( (cpu_has_vmx_apic_reg_virt ||
> +                                cpu_has_vmx_virtual_intr_delivery)
> &&
> +
> cpu_has_vmx_virtualize_x2apic_mode );
> +
> +    if ( !cpu_has_vmx_virtualize_apic_accesses &&
> +         !virtualize_x2apic_mode )
>          return;
>
>      vmx_vmcs_enter(v);
>      v->arch.hvm_vmx.secondary_exec_control &=3D
> -        ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +        ~(SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
> +          SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE);
>      if ( !vlapic_hw_disabled(vlapic) &&
>           (vlapic_base_address(vlapic) =3D=3D APIC_DEFAULT_PHYS_BASE) )
> -        v->arch.hvm_vmx.secondary_exec_control |=3D
> -            SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +    {
> +        if ( virtualize_x2apic_mode && vlapic_x2apic_mode(vlapic) )
> +        {
> +            v->arch.hvm_vmx.secondary_exec_control |=3D
> +                SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
> +            if ( cpu_has_vmx_apic_reg_virt )
> +            {
> +                for (int msr =3D MSR_IA32_APICBASE_MSR;
> +                     msr <=3D MSR_IA32_APICBASE_MSR + 0xff; msr++)
> +                    vmx_disable_intercept_for_msr(v, msr,
> MSR_TYPE_R);
> +
> +                vmx_enable_intercept_for_msr(v,
> MSR_IA32_APICPPR_MSR,
> +                                             MSR_TYPE_R);
> +                vmx_enable_intercept_for_msr(v,
> MSR_IA32_APICTMICT_MSR,
> +                                             MSR_TYPE_R);
> +                vmx_enable_intercept_for_msr(v,
> MSR_IA32_APICTMCCT_MSR,
> +                                             MSR_TYPE_R);
> +            }
> +            if ( cpu_has_vmx_virtual_intr_delivery )
> +            {
> +                vmx_disable_intercept_for_msr(v,
> MSR_IA32_APICTPR_MSR,
> +                                              MSR_TYPE_W);
> +                vmx_disable_intercept_for_msr(v,
> MSR_IA32_APICEOI_MSR,
> +                                              MSR_TYPE_W);
> +                vmx_disable_intercept_for_msr(v,
> MSR_IA32_APICSELF_MSR,
> +                                              MSR_TYPE_W);
> +            }
> +        }
> +        else
> +        {
> +            v->arch.hvm_vmx.secondary_exec_control |=3D
> +                SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +            for (int msr =3D MSR_IA32_APICBASE_MSR;
> +                 msr <=3D MSR_IA32_APICBASE_MSR + 0xff; msr++)
> +                vmx_enable_intercept_for_msr(v, msr,
> +                                             MSR_TYPE_R |
> MSR_TYPE_W);
> +        }
> +    }
>      vmx_update_secondary_exec_control(v);
>      vmx_vmcs_exit(v);
>  }
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index d4958c3..25c94a6 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -184,6 +184,7 @@ extern u32 vmx_vmentry_control;
>  #define SECONDARY_EXEC_ENABLE_EPT               0x00000002
>  #define SECONDARY_EXEC_DESCRIPTOR_TABLE_EXITING 0x00000004
>  #define SECONDARY_EXEC_ENABLE_RDTSCP            0x00000008
> +#define SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x00000010
>  #define SECONDARY_EXEC_ENABLE_VPID              0x00000020
>  #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
>  #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
> @@ -244,6 +245,8 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
>      (vmx_secondary_exec_control &
> SECONDARY_EXEC_APIC_REGISTER_VIRT)
>  #define cpu_has_vmx_virtual_intr_delivery \
>      (vmx_secondary_exec_control &
> SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY)
> +#define cpu_has_vmx_virtualize_x2apic_mode \
> +    (vmx_secondary_exec_control &
> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE)
>
>  /* GUEST_INTERRUPTIBILITY_INFO flags. */
>  #define VMX_INTR_SHADOW_STI             0x00000001
> @@ -434,6 +437,7 @@ enum vmcs_field {
>  #define MSR_TYPE_R 1
>  #define MSR_TYPE_W 2
>  void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
> +void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
>  int vmx_read_guest_msr(u32 msr, u64 *val);
>  int vmx_write_guest_msr(u32 msr, u64 val);
>  int vmx_add_guest_msr(u32 msr);
> diff --git a/xen/include/asm-x86/msr-index.h
> b/xen/include/asm-x86/msr-index.h
> index 5c1de6e..f500efd 100644
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -300,7 +300,10 @@
>  #define MSR_IA32_APICBASE_BASE               (0xfffff<<12)
>  #define MSR_IA32_APICBASE_MSR           0x800
>  #define MSR_IA32_APICTPR_MSR            0x808
> +#define MSR_IA32_APICPPR_MSR            0x80a
>  #define MSR_IA32_APICEOI_MSR            0x80b
> +#define MSR_IA32_APICTMICT_MSR          0x838
> +#define MSR_IA32_APICTMCCT_MSR          0x839
>  #define MSR_IA32_APICSELF_MSR           0x83f
>
>  #define MSR_IA32_UCODE_WRITE         0x00000079
> --
> 1.7.1
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Sat Feb 16 08:58:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 08: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 1U6dax-0005mE-LV; Sat, 16 Feb 2013 08:58:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1U6dav-0005m9-E4
	for xen-devel@lists.xen.org; Sat, 16 Feb 2013 08:58:05 +0000
Received: from [85.158.138.51:38955] by server-2.bemta-3.messagelabs.com id
	2D/E9-25961-C1A4F115; Sat, 16 Feb 2013 08:58:04 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361005081!9119140!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM2ODc5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20376 invoked from network); 16 Feb 2013 08:58:02 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-174.messagelabs.com with SMTP;
	16 Feb 2013 08:58:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 16 Feb 2013 00:57:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,678,1355126400"; d="scan'208";a="291962195"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 16 Feb 2013 00:57:59 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 00:57:59 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sat, 16 Feb 2013 16:57:56 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Dong, Eddie" <eddie.dong@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Thread-Topic: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
Thread-Index: AQHOCUF5jxFxc3DI+0+LAbSQsEcIwJh8Mzog
Date: Sat, 16 Feb 2013 08:57:55 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87F4BC7@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
	<511A817B02000078000BDCAC@nat28.tlf.novell.com>
In-Reply-To: <511A817B02000078000BDCAC@nat28.tlf.novell.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="_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jan,
Eddie had already ack the patches.

BR,
Li Jiongxi

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, February 13, 2013 12:53 AM
> To: Dong, Eddie; Nakajima, Jun
> Cc: Keir Fraser; Li, Jiongxi; xen-devel
> Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
>=20
> >>> On 30.01.13 at 04:23, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> > This patchset fixes some APICV issues, including a potential issue
> > while doing live migration and enabling APICV while guest is in X2APIC =
mode.
> >
> > PATCH 1/2: Xen: Fix live migration while enabling APICV.
> >
> > PATCH 2/2: Xen: Fix VMCS setting for x2APIC mode guest while enabling
> APICV.
>=20
> Jun, Eddie - we're still waiting for an ack of at least one of you on the=
se two...
>=20
> Thanks, Jan
>=20
> > Changes v4 to v5
> > Correct coding style. Add debug log in msr enable/disable intercept
> > function for out of range case.
> >
> > Changes v3 to v4
> > According to Jan's comment, add define for numbers used in
> > GUEST_INTR_STATUS, change function name.
> > Use 'set_bit/clear_bit' instead of '__set_bit/__clear_bit'
> >
> > Changes v2 to v3
> > When enabling APICV for x2apic mode, ppr, tmict tmcct MSR read still
> > need to be intercepted.
> >
> > Changes v1 to v2
> > According to Keir's comment, don't change the save/restore order for
> > compatibility.
>=20
>=20


--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Sat, 16 Feb 2013 08:57:53 GMT";
	modification-date="Sat, 16 Feb 2013 08:57:53 GMT"

Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
 SHSMSX151.ccr.corp.intel.com (10.239.6.50) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Thu, 31 Jan 2013 23:07:10 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.181]) by
 SHSMSX101.ccr.corp.intel.com ([169.254.1.236]) with mapi id 14.01.0355.002;
 Thu, 31 Jan 2013 23:07:09 +0800
From: "Dong, Eddie" <eddie.dong@intel.com>
To: "Li, Jiongxi" <jiongxi.li@intel.com>, "'xen-devel@lists.xen.org'"
	<xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
CC: Keir Fraser <keir.xen@gmail.com>, "Dong, Eddie" <eddie.dong@intel.com>
Subject: RE: [Xen-devel] [PATCH v5 1/2] Xen: Fix live migration while
 enabling	APICV
Thread-Topic: [Xen-devel] [PATCH v5 1/2] Xen: Fix live migration while
 enabling	APICV
Thread-Index: Ac3+mKfWcDSdaS3cQOGHEexhpD9N1QBK/H2w
Date: Thu, 31 Jan 2013 15:07:09 +0000
Message-ID: <A12AC9D104E08D47BAF23C492F83C53B23CF8611@SHSMSX102.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62CD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87E62CD@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: SHSMSX101.ccr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Acked by: Eddie Dong <eddie.dong@intel.com>

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Li, Jiongxi
> Sent: Wednesday, January 30, 2013 11:23 AM
> To: 'xen-devel@lists.xen.org'; Jan Beulich
> Cc: Keir Fraser
> Subject: [Xen-devel] [PATCH v5 1/2] Xen: Fix live migration while enablin=
g
> APICV
>
> SVI should be restored in case guest is processing virtual interrupt
> while saveing a domain state. Otherwise SVI would be missed when
> virtual interrupt delivery is enabled.
>
> Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
>
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index ee2294c..38ff216 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1198,6 +1198,9 @@ static int lapic_load_regs(struct domain *d,
> hvm_domain_context_t *h)
>      if ( hvm_load_entry(LAPIC_REGS, h, s->regs) !=3D 0 )
>          return -EINVAL;
>
> +    if ( hvm_funcs.process_isr )
> +        hvm_funcs.process_isr(vlapic_find_highest_isr(s), v);
> +
>      vlapic_adjust_i8259_target(d);
>      lapic_rearm(s);
>      return 0;
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index c5c503e..c961782 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -290,8 +290,8 @@ void vmx_intr_assist(void)
>              vmx_set_eoi_exit_bitmap(v, pt_vector);
>
>          /* we need update the RVI field */
> -        status &=3D ~(unsigned long)0x0FF;
> -        status |=3D (unsigned long)0x0FF &
> +        status &=3D ~VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK;
> +        status |=3D VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK &
>                      intack.vector;
>          __vmwrite(GUEST_INTR_STATUS, status);
>          if (v->arch.hvm_vmx.eoi_exitmap_changed) {
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 4d7c93f..362273b 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1419,6 +1419,29 @@ static int
> vmx_virtual_intr_delivery_enabled(void)
>      return cpu_has_vmx_virtual_intr_delivery;
>  }
>
> +static void vmx_process_isr(int isr, struct vcpu *v)
> +{
> +    unsigned long status;
> +    u8 old;
> +
> +    if ( !cpu_has_vmx_virtual_intr_delivery )
> +        return;
> +
> +    if ( isr < 0 )
> +        isr =3D 0;
> +
> +    vmx_vmcs_enter(v);
> +    status =3D __vmread(GUEST_INTR_STATUS);
> +    old =3D status >> VMX_GUEST_INTR_STATUS_SVI_OFFSET;
> +    if ( isr !=3D old )
> +    {
> +        status &=3D VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK;
> +        status |=3D isr << VMX_GUEST_INTR_STATUS_SVI_OFFSET;
> +        __vmwrite(GUEST_INTR_STATUS, status);
> +    }
> +    vmx_vmcs_exit(v);
> +}
> +
>  static struct hvm_function_table __read_mostly vmx_function_table =3D {
>      .name                 =3D "VMX",
>      .cpu_up_prepare       =3D vmx_cpu_up_prepare,
> @@ -1468,6 +1491,7 @@ static struct hvm_function_table __read_mostly
> vmx_function_table =3D {
>      .nhvm_domain_relinquish_resources =3D
> nvmx_domain_relinquish_resources,
>      .update_eoi_exit_bitmap =3D vmx_update_eoi_exit_bitmap,
>      .virtual_intr_delivery_enabled =3D vmx_virtual_intr_delivery_enabled=
,
> +    .process_isr          =3D vmx_process_isr,
>      .nhvm_hap_walk_L1_p2m =3D nvmx_hap_walk_L1_p2m,
>  };
>
> diff --git a/xen/include/asm-x86/hvm/hvm.h
> b/xen/include/asm-x86/hvm/hvm.h
> index 76e9cc8..011a6a3 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -183,6 +183,7 @@ struct hvm_function_table {
>      /* Virtual interrupt delivery */
>      void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
>      int (*virtual_intr_delivery_enabled)(void);
> +    void (*process_isr)(int isr, struct vcpu *v);
>
>      /*Walk nested p2m  */
>      int (*nhvm_hap_walk_L1_p2m)(struct vcpu *v, paddr_t L2_gpa,
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index 51df81e..d4958c3 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -257,6 +257,10 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
>   */
>  #define VMX_BASIC_DEFAULT1_ZERO              (1ULL << 55)
>
> +/* Guest interrupt status */
> +#define VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK  0x0FF
> +#define VMX_GUEST_INTR_STATUS_SVI_OFFSET        8
> +
>  /* VMCS field encodings. */
>  enum vmcs_field {
>      VIRTUAL_PROCESSOR_ID            =3D 0x00000000,
> --
> 1.7.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Sat, 16 Feb 2013 08:57:54 GMT";
	modification-date="Sat, 16 Feb 2013 08:57:54 GMT"

Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.181]) by
 SHSMSX151.ccr.corp.intel.com ([169.254.3.30]) with mapi id 14.01.0355.002;
 Thu, 31 Jan 2013 23:07:34 +0800
From: "Dong, Eddie" <eddie.dong@intel.com>
To: "Li, Jiongxi" <jiongxi.li@intel.com>, "'xen-devel@lists.xen.org'"
	<xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>
CC: Keir Fraser <keir.xen@gmail.com>, "Dong, Eddie" <eddie.dong@intel.com>
Subject: RE: [Xen-devel] [PATCH v5 2/2] Xen: Fix VMCS setting for x2APIC
 mode guest while enabling APICV
Thread-Topic: [Xen-devel] [PATCH v5 2/2] Xen: Fix VMCS setting for x2APIC
 mode guest while enabling APICV
Thread-Index: Ac3+mO4Ykgoi2iucSgy8eIfx4NRuuwBK7iDw
Date: Thu, 31 Jan 2013 15:07:33 +0000
Message-ID: <A12AC9D104E08D47BAF23C492F83C53B23CF862B@SHSMSX102.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62D2@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87E62D2@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: SHSMSX151.ccr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Acked-by: Eddie Dong <eddie.dong@intel.com>

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Li, Jiongxi
> Sent: Wednesday, January 30, 2013 11:24 AM
> To: 'xen-devel@lists.xen.org'; Jan Beulich
> Cc: Keir Fraser
> Subject: [Xen-devel] [PATCH v5 2/2] Xen: Fix VMCS setting for x2APIC mode
> guest while enabling APICV
>
> The "APIC-register virtualization" and "virtual-interrupt deliver"
> VM-execution control has no effect on the behavior of RDMSR/WRMSR if
> the "virtualize x2APIC mode" VM-execution control is 0.
> When guest uses x2APIC mode, we should enable "virtualize x2APIC mode"
> for APICV first.
>
> Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
>
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index de22e03..8abdf6d 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -190,7 +190,8 @@ static int vmx_init_vmcs_config(void)
>           */
>          if ( _vmx_cpu_based_exec_control &
> CPU_BASED_TPR_SHADOW )
>              opt |=3D SECONDARY_EXEC_APIC_REGISTER_VIRT |
> -                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
> +                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
> +                   SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
>
>
>          _vmx_secondary_exec_control =3D adjust_vmx_controls(
> @@ -658,19 +659,60 @@ void vmx_disable_intercept_for_msr(struct vcpu
> *v, u32 msr, int type)
>       */
>      if ( msr <=3D 0x1fff )
>      {
> -        if (type & MSR_TYPE_R)
> -            __clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /*
> read-low */
> -        if (type & MSR_TYPE_W)
> -            __clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /*
> write-low */
> +        if ( type & MSR_TYPE_R )
> +            clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /*
> read-low */
> +        if ( type & MSR_TYPE_W )
> +            clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /*
> write-low */
>      }
>      else if ( (msr >=3D 0xc0000000) && (msr <=3D 0xc0001fff) )
>      {
>          msr &=3D 0x1fff;
> -        if (type & MSR_TYPE_R)
> -            __clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /*
> read-high */
> -        if (type & MSR_TYPE_W)
> -            __clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /*
> write-high */
> +        if ( type & MSR_TYPE_R )
> +            clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /*
> read-high */
> +        if ( type & MSR_TYPE_W )
> +            clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /*
> write-high */
>      }
> +    else
> +        HVM_DBG_LOG(DBG_LEVEL_0,
> +                   "msr %x is out of the control range"
> +                   "0x00000000-0x00001fff and
> 0xc0000000-0xc0001fff"
> +                   "RDMSR or WRMSR will cause a VM exit", msr);
> +
> +}
> +
> +void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
> +{
> +    unsigned long *msr_bitmap =3D v->arch.hvm_vmx.msr_bitmap;
> +
> +    /* VMX MSR bitmap supported? */
> +    if ( msr_bitmap =3D=3D NULL )
> +        return;
> +
> +    /*
> +     * See Intel PRM Vol. 3, 20.6.9 (MSR-Bitmap Address). Early manuals
> +     * have the write-low and read-high bitmap offsets the wrong way
> round.
> +     * We can control MSRs 0x00000000-0x00001fff and
> 0xc0000000-0xc0001fff.
> +     */
> +    if ( msr <=3D 0x1fff )
> +    {
> +        if ( type & MSR_TYPE_R )
> +            set_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /*
> read-low */
> +        if ( type & MSR_TYPE_W )
> +            set_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /*
> write-low */
> +    }
> +    else if ( (msr >=3D 0xc0000000) && (msr <=3D 0xc0001fff) )
> +    {
> +        msr &=3D 0x1fff;
> +        if ( type & MSR_TYPE_R )
> +            set_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /*
> read-high */
> +        if ( type & MSR_TYPE_W )
> +            set_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /*
> write-high */
> +    }
> +    else
> +        HVM_DBG_LOG(DBG_LEVEL_0,
> +                   "msr %x is out of the control range"
> +                   "0x00000000-0x00001fff and
> 0xc0000000-0xc0001fff"
> +                   "RDMSR or WRMSR will cause a VM exit", msr);
>  }
>
>  /*
> @@ -764,6 +806,9 @@ static int construct_vmcs(struct vcpu *v)
>          vmentry_ctl &=3D ~VM_ENTRY_LOAD_GUEST_PAT;
>      }
>
> +    /* Disable Virtualize x2APIC mode by default. */
> +    v->arch.hvm_vmx.secondary_exec_control &=3D
> ~SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
> +
>      /* Do not enable Monitor Trap Flag unless start single step debug */
>      v->arch.hvm_vmx.exec_control &=3D
> ~CPU_BASED_MONITOR_TRAP_FLAG;
>
> @@ -800,18 +845,6 @@ static int construct_vmcs(struct vcpu *v)
>          vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP,
> MSR_TYPE_R | MSR_TYPE_W);
>          if ( cpu_has_vmx_pat && paging_mode_hap(d) )
>              vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT,
> MSR_TYPE_R | MSR_TYPE_W);
> -        if ( cpu_has_vmx_apic_reg_virt )
> -        {
> -            int msr;
> -            for (msr =3D MSR_IA32_APICBASE_MSR; msr <=3D
> MSR_IA32_APICBASE_MSR + 0xff; msr++)
> -                vmx_disable_intercept_for_msr(v, msr, MSR_TYPE_R);
> -        }
> -        if ( cpu_has_vmx_virtual_intr_delivery )
> -        {
> -            vmx_disable_intercept_for_msr(v, MSR_IA32_APICTPR_MSR,
> MSR_TYPE_W);
> -            vmx_disable_intercept_for_msr(v, MSR_IA32_APICEOI_MSR,
> MSR_TYPE_W);
> -            vmx_disable_intercept_for_msr(v, MSR_IA32_APICSELF_MSR,
> MSR_TYPE_W);
> -        }
>      }
>
>      /* I/O access bitmap. */
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 362273b..855a003 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1887,18 +1887,61 @@ static void vmx_install_vlapic_mapping(struct
> vcpu *v)
>
>  void vmx_vlapic_msr_changed(struct vcpu *v)
>  {
> +    int virtualize_x2apic_mode;
>      struct vlapic *vlapic =3D vcpu_vlapic(v);
>
> -    if ( !cpu_has_vmx_virtualize_apic_accesses )
> +    virtualize_x2apic_mode =3D ( (cpu_has_vmx_apic_reg_virt ||
> +                                cpu_has_vmx_virtual_intr_delivery)
> &&
> +
> cpu_has_vmx_virtualize_x2apic_mode );
> +
> +    if ( !cpu_has_vmx_virtualize_apic_accesses &&
> +         !virtualize_x2apic_mode )
>          return;
>
>      vmx_vmcs_enter(v);
>      v->arch.hvm_vmx.secondary_exec_control &=3D
> -        ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +        ~(SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
> +          SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE);
>      if ( !vlapic_hw_disabled(vlapic) &&
>           (vlapic_base_address(vlapic) =3D=3D APIC_DEFAULT_PHYS_BASE) )
> -        v->arch.hvm_vmx.secondary_exec_control |=3D
> -            SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +    {
> +        if ( virtualize_x2apic_mode && vlapic_x2apic_mode(vlapic) )
> +        {
> +            v->arch.hvm_vmx.secondary_exec_control |=3D
> +                SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE;
> +            if ( cpu_has_vmx_apic_reg_virt )
> +            {
> +                for (int msr =3D MSR_IA32_APICBASE_MSR;
> +                     msr <=3D MSR_IA32_APICBASE_MSR + 0xff; msr++)
> +                    vmx_disable_intercept_for_msr(v, msr,
> MSR_TYPE_R);
> +
> +                vmx_enable_intercept_for_msr(v,
> MSR_IA32_APICPPR_MSR,
> +                                             MSR_TYPE_R);
> +                vmx_enable_intercept_for_msr(v,
> MSR_IA32_APICTMICT_MSR,
> +                                             MSR_TYPE_R);
> +                vmx_enable_intercept_for_msr(v,
> MSR_IA32_APICTMCCT_MSR,
> +                                             MSR_TYPE_R);
> +            }
> +            if ( cpu_has_vmx_virtual_intr_delivery )
> +            {
> +                vmx_disable_intercept_for_msr(v,
> MSR_IA32_APICTPR_MSR,
> +                                              MSR_TYPE_W);
> +                vmx_disable_intercept_for_msr(v,
> MSR_IA32_APICEOI_MSR,
> +                                              MSR_TYPE_W);
> +                vmx_disable_intercept_for_msr(v,
> MSR_IA32_APICSELF_MSR,
> +                                              MSR_TYPE_W);
> +            }
> +        }
> +        else
> +        {
> +            v->arch.hvm_vmx.secondary_exec_control |=3D
> +                SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> +            for (int msr =3D MSR_IA32_APICBASE_MSR;
> +                 msr <=3D MSR_IA32_APICBASE_MSR + 0xff; msr++)
> +                vmx_enable_intercept_for_msr(v, msr,
> +                                             MSR_TYPE_R |
> MSR_TYPE_W);
> +        }
> +    }
>      vmx_update_secondary_exec_control(v);
>      vmx_vmcs_exit(v);
>  }
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index d4958c3..25c94a6 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -184,6 +184,7 @@ extern u32 vmx_vmentry_control;
>  #define SECONDARY_EXEC_ENABLE_EPT               0x00000002
>  #define SECONDARY_EXEC_DESCRIPTOR_TABLE_EXITING 0x00000004
>  #define SECONDARY_EXEC_ENABLE_RDTSCP            0x00000008
> +#define SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x00000010
>  #define SECONDARY_EXEC_ENABLE_VPID              0x00000020
>  #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
>  #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
> @@ -244,6 +245,8 @@ extern bool_t cpu_has_vmx_ins_outs_instr_info;
>      (vmx_secondary_exec_control &
> SECONDARY_EXEC_APIC_REGISTER_VIRT)
>  #define cpu_has_vmx_virtual_intr_delivery \
>      (vmx_secondary_exec_control &
> SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY)
> +#define cpu_has_vmx_virtualize_x2apic_mode \
> +    (vmx_secondary_exec_control &
> SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE)
>
>  /* GUEST_INTERRUPTIBILITY_INFO flags. */
>  #define VMX_INTR_SHADOW_STI             0x00000001
> @@ -434,6 +437,7 @@ enum vmcs_field {
>  #define MSR_TYPE_R 1
>  #define MSR_TYPE_W 2
>  void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
> +void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
>  int vmx_read_guest_msr(u32 msr, u64 *val);
>  int vmx_write_guest_msr(u32 msr, u64 val);
>  int vmx_add_guest_msr(u32 msr);
> diff --git a/xen/include/asm-x86/msr-index.h
> b/xen/include/asm-x86/msr-index.h
> index 5c1de6e..f500efd 100644
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -300,7 +300,10 @@
>  #define MSR_IA32_APICBASE_BASE               (0xfffff<<12)
>  #define MSR_IA32_APICBASE_MSR           0x800
>  #define MSR_IA32_APICTPR_MSR            0x808
> +#define MSR_IA32_APICPPR_MSR            0x80a
>  #define MSR_IA32_APICEOI_MSR            0x80b
> +#define MSR_IA32_APICTMICT_MSR          0x838
> +#define MSR_IA32_APICTMCCT_MSR          0x839
>  #define MSR_IA32_APICSELF_MSR           0x83f
>
>  #define MSR_IA32_UCODE_WRITE         0x00000079
> --
> 1.7.1
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_D9137FCD9CFF644B965863BCFBEDABB87F4BC7SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Sat Feb 16 12:41:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 12:41: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 1U6h4h-0001I6-Oi; Sat, 16 Feb 2013 12:41:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6h4g-0001I1-AV
	for xen-devel@lists.xensource.com; Sat, 16 Feb 2013 12:41:02 +0000
Received: from [85.158.143.35:56784] by server-3.bemta-4.messagelabs.com id
	4E/84-08920-D5E7F115; Sat, 16 Feb 2013 12:41:01 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361018414!11754052!1
X-Originating-IP: [74.125.83.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22075 invoked from network); 16 Feb 2013 12:40:14 -0000
Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com)
	(74.125.83.47)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 12:40:14 -0000
Received: by mail-ee0-f47.google.com with SMTP id e52so2184427eek.34
	for <xen-devel@lists.xensource.com>;
	Sat, 16 Feb 2013 04:40:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=iE4Z5k4qiU7gkl8BZHZgubyxy5UznfLlw9+l0rkPNDs=;
	b=RN5H5k0oeZa82GrNVLWfuYf9qUElIa2vh7KgMtDVbWweY/y471243n7UDY/tTKw+EI
	bcKg53os6Bl829s1/ZeQd1d8GcVy7dMcAM57jS1uG/aD+j73k5c2hIWeDIOxxZw4b46S
	0WYUhCfb3xrAhtTKeUji7UnNIH5Ch1I/IOixV+jmzgcrR5UfLz63EDRSLbaNQwcP8pft
	WOSgV4egfjsfYmZGk7c/Nbb2Nhwa8AwbOCRInLFgyfI5THXFsAi64pJ7wOBF2UCf+7zB
	5aGP4RFH6gcBEmbPBY1BRvvPpFGm7GkOccrT0Fdb5ElM/uUN7qoaT+cs8cT2By8ZcITn
	2K6Q==
X-Received: by 10.14.215.193 with SMTP id e41mr20274763eep.32.1361018414149;
	Sat, 16 Feb 2013 04:40:14 -0800 (PST)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it. [87.4.79.231])
	by mx.google.com with ESMTPS id q42sm79077788eem.14.2013.02.16.04.40.12
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 16 Feb 2013 04:40:13 -0800 (PST)
Message-ID: <511F7E25.7040307@heliman.it>
Date: Sat, 16 Feb 2013 13:40:05 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360935977.31407.66.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQnAk3Ebqda/3kmSl4QdNkRK9+0kJnkPz8w6E3eTApA6DMuqdzFhVVJWRYiisdtuzgvrt0vI
Cc: Zhou Peng <zpengxen@gmail.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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-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

Il 15/02/2013 14:46, Ian Campbell ha scritto:
> On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
>> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>
>>> Usage:
>>>    vga="qxl"
>>>
>>> Changes from v8:
>>> - vga=qxl instead of qxl=1 to use it.
>>> - Show an error and exit if vga="qxl" without qemu upstream.
>>> - Other small improvements.
>>>
>>> Required patches:
>>> - Improve videoram setting v5
>>> - Added vga parameter for hvm domUs
>>>
>>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>>> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Applied thanks
>
>
I do not see this patch in the staging branch, there are problems of 
code style?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 12:41:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 12:41: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 1U6h4h-0001I6-Oi; Sat, 16 Feb 2013 12:41:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6h4g-0001I1-AV
	for xen-devel@lists.xensource.com; Sat, 16 Feb 2013 12:41:02 +0000
Received: from [85.158.143.35:56784] by server-3.bemta-4.messagelabs.com id
	4E/84-08920-D5E7F115; Sat, 16 Feb 2013 12:41:01 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361018414!11754052!1
X-Originating-IP: [74.125.83.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22075 invoked from network); 16 Feb 2013 12:40:14 -0000
Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com)
	(74.125.83.47)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 12:40:14 -0000
Received: by mail-ee0-f47.google.com with SMTP id e52so2184427eek.34
	for <xen-devel@lists.xensource.com>;
	Sat, 16 Feb 2013 04:40:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=iE4Z5k4qiU7gkl8BZHZgubyxy5UznfLlw9+l0rkPNDs=;
	b=RN5H5k0oeZa82GrNVLWfuYf9qUElIa2vh7KgMtDVbWweY/y471243n7UDY/tTKw+EI
	bcKg53os6Bl829s1/ZeQd1d8GcVy7dMcAM57jS1uG/aD+j73k5c2hIWeDIOxxZw4b46S
	0WYUhCfb3xrAhtTKeUji7UnNIH5Ch1I/IOixV+jmzgcrR5UfLz63EDRSLbaNQwcP8pft
	WOSgV4egfjsfYmZGk7c/Nbb2Nhwa8AwbOCRInLFgyfI5THXFsAi64pJ7wOBF2UCf+7zB
	5aGP4RFH6gcBEmbPBY1BRvvPpFGm7GkOccrT0Fdb5ElM/uUN7qoaT+cs8cT2By8ZcITn
	2K6Q==
X-Received: by 10.14.215.193 with SMTP id e41mr20274763eep.32.1361018414149;
	Sat, 16 Feb 2013 04:40:14 -0800 (PST)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it. [87.4.79.231])
	by mx.google.com with ESMTPS id q42sm79077788eem.14.2013.02.16.04.40.12
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 16 Feb 2013 04:40:13 -0800 (PST)
Message-ID: <511F7E25.7040307@heliman.it>
Date: Sat, 16 Feb 2013 13:40:05 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360935977.31407.66.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQnAk3Ebqda/3kmSl4QdNkRK9+0kJnkPz8w6E3eTApA6DMuqdzFhVVJWRYiisdtuzgvrt0vI
Cc: Zhou Peng <zpengxen@gmail.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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-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

Il 15/02/2013 14:46, Ian Campbell ha scritto:
> On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
>> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>
>>> Usage:
>>>    vga="qxl"
>>>
>>> Changes from v8:
>>> - vga=qxl instead of qxl=1 to use it.
>>> - Show an error and exit if vga="qxl" without qemu upstream.
>>> - Other small improvements.
>>>
>>> Required patches:
>>> - Improve videoram setting v5
>>> - Added vga parameter for hvm domUs
>>>
>>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>>> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Applied thanks
>
>
I do not see this patch in the staging branch, there are problems of 
code style?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 13:21:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 13:21: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 1U6hgw-0001uC-2T; Sat, 16 Feb 2013 13:20: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 1U6hgu-0001u7-KY
	for xen-devel@lists.xensource.com; Sat, 16 Feb 2013 13:20:32 +0000
Received: from [85.158.138.51:58152] by server-1.bemta-3.messagelabs.com id
	71/2E-08955-F978F115; Sat, 16 Feb 2013 13:20:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361020830!27888694!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMDg0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30969 invoked from network); 16 Feb 2013 13:20:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 13:20:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,678,1355097600"; 
   d="scan'208";a="1539586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2013 13:20:30 +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.297.1;
	Sat, 16 Feb 2013 13:20:29 +0000
Message-ID: <1361020829.18663.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Sat, 16 Feb 2013 13:20:29 +0000
In-Reply-To: <511F7E25.7040307@heliman.it>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
	<511F7E25.7040307@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Zhou Peng <zpengxen@gmail.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

On Sat, 2013-02-16 at 12:40 +0000, Fabio Fantoni wrote:
> Il 15/02/2013 14:46, Ian Campbell ha scritto:
> > On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
> >> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> >>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> >>>
> >>> Usage:
> >>>    vga="qxl"
> >>>
> >>> Changes from v8:
> >>> - vga=qxl instead of qxl=1 to use it.
> >>> - Show an error and exit if vga="qxl" without qemu upstream.
> >>> - Other small improvements.
> >>>
> >>> Required patches:
> >>> - Improve videoram setting v5
> >>> - Added vga parameter for hvm domUs
> >>>
> >>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> >>> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> >> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Applied thanks
> >
> >
> I do not see this patch in the staging branch, there are problems of 
> code style?

I think I just managed to miss actually applying this one in among all
the other stuff I applied on Friday. I'll take another look next week.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 13:21:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 13:21: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 1U6hgw-0001uC-2T; Sat, 16 Feb 2013 13:20: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 1U6hgu-0001u7-KY
	for xen-devel@lists.xensource.com; Sat, 16 Feb 2013 13:20:32 +0000
Received: from [85.158.138.51:58152] by server-1.bemta-3.messagelabs.com id
	71/2E-08955-F978F115; Sat, 16 Feb 2013 13:20:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361020830!27888694!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMDg0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30969 invoked from network); 16 Feb 2013 13:20:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 13:20:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,678,1355097600"; 
   d="scan'208";a="1539586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Feb 2013 13:20:30 +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.297.1;
	Sat, 16 Feb 2013 13:20:29 +0000
Message-ID: <1361020829.18663.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Sat, 16 Feb 2013 13:20:29 +0000
In-Reply-To: <511F7E25.7040307@heliman.it>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
	<511F7E25.7040307@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Zhou Peng <zpengxen@gmail.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

On Sat, 2013-02-16 at 12:40 +0000, Fabio Fantoni wrote:
> Il 15/02/2013 14:46, Ian Campbell ha scritto:
> > On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
> >> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
> >>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> >>>
> >>> Usage:
> >>>    vga="qxl"
> >>>
> >>> Changes from v8:
> >>> - vga=qxl instead of qxl=1 to use it.
> >>> - Show an error and exit if vga="qxl" without qemu upstream.
> >>> - Other small improvements.
> >>>
> >>> Required patches:
> >>> - Improve videoram setting v5
> >>> - Added vga parameter for hvm domUs
> >>>
> >>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> >>> Signed-off-by: Zhou Peng <zpengxen@gmail.com>
> >> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Applied thanks
> >
> >
> I do not see this patch in the staging branch, there are problems of 
> code style?

I think I just managed to miss actually applying this one in among all
the other stuff I applied on Friday. I'll take another look next week.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 14:57:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 14:57: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 1U6jCZ-0003H3-OA; Sat, 16 Feb 2013 14:57:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6jCY-0003Gy-9n
	for xen-devel@lists.xensource.com; Sat, 16 Feb 2013 14:57:18 +0000
Received: from [85.158.139.211:13624] by server-15.bemta-5.messagelabs.com id
	4D/C1-18914-D4E9F115; Sat, 16 Feb 2013 14:57:17 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361026637!21301259!1
X-Originating-IP: [74.125.83.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21387 invoked from network); 16 Feb 2013 14:57:17 -0000
Received: from mail-ee0-f49.google.com (HELO mail-ee0-f49.google.com)
	(74.125.83.49)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 14:57:17 -0000
Received: by mail-ee0-f49.google.com with SMTP id d4so2210652eek.22
	for <xen-devel@lists.xensource.com>;
	Sat, 16 Feb 2013 06:57:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=/2r0fa6tBEaozihfFFide7pCZRT1F/gPmBIdbUmIhPk=;
	b=PApzAnoKhajd+7irqa6MNgFoe4XgUq36y5G9QMgTEiU22eYOa17H1fdS/0ozMJYEQv
	WzssWEvrXlAGuX4ZUOsf9wL8lMIk//UowSB6Q4En0OZkWOc8ACeQOuEobQC0Y0QGIkEb
	De+LuJ5d1ns5YglCDNM/hj03dDwWRGVxOe/Zcgk10DaIosixzkKy2mPemNlojbDMveZK
	LI4WUddL6zRS3Awoj7I9Q5AEYHae5xWjcoAY3wy7Y/No+GS3zJSNCtMjYKl89BQMDqzg
	pzHYhk1+13XAlexd4pExd18iDXzJmb/c1Z+2sdEoQElTxyWVEi1gvomPANIT56ztH0RQ
	n6wA==
X-Received: by 10.14.220.135 with SMTP id o7mr21800269eep.3.1361026636717;
	Sat, 16 Feb 2013 06:57:16 -0800 (PST)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it. [87.4.79.231])
	by mx.google.com with ESMTPS id k7sm86176135een.8.2013.02.16.06.57.14
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 16 Feb 2013 06:57:15 -0800 (PST)
Message-ID: <511F9E44.1020702@heliman.it>
Date: Sat, 16 Feb 2013 15:57:08 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
	<1360936015.31407.67.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360936015.31407.67.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQkfng9+/109pdcIeCUUc4887cFjuEd0xDyNcxTvcxZaA2vJq1jNNm7uLEth1wKS9GQmqBxi
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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-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

Il 15/02/2013 14:46, Ian Campbell ha scritto:
> On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
>> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>
>>> - If videoram setting is less than 8 mb shows error and exit.
>>> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
>>> - Updated xl.cfg man.
>>> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>>>    qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
>>>    (qemu 1.3 doesn't complain about it, probably buggy).
>>>
>>> Changes from v5:
>>> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>>>    qemu is being used.
>>>
>>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Applied, thanks.
>
This patch should be backported to xen 4.2.x for fix crash of qemu 1.4 
with stdvga (tested with debian experimental package)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 14:57:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 14:57: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 1U6jCZ-0003H3-OA; Sat, 16 Feb 2013 14:57:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U6jCY-0003Gy-9n
	for xen-devel@lists.xensource.com; Sat, 16 Feb 2013 14:57:18 +0000
Received: from [85.158.139.211:13624] by server-15.bemta-5.messagelabs.com id
	4D/C1-18914-D4E9F115; Sat, 16 Feb 2013 14:57:17 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361026637!21301259!1
X-Originating-IP: [74.125.83.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21387 invoked from network); 16 Feb 2013 14:57:17 -0000
Received: from mail-ee0-f49.google.com (HELO mail-ee0-f49.google.com)
	(74.125.83.49)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 14:57:17 -0000
Received: by mail-ee0-f49.google.com with SMTP id d4so2210652eek.22
	for <xen-devel@lists.xensource.com>;
	Sat, 16 Feb 2013 06:57:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=/2r0fa6tBEaozihfFFide7pCZRT1F/gPmBIdbUmIhPk=;
	b=PApzAnoKhajd+7irqa6MNgFoe4XgUq36y5G9QMgTEiU22eYOa17H1fdS/0ozMJYEQv
	WzssWEvrXlAGuX4ZUOsf9wL8lMIk//UowSB6Q4En0OZkWOc8ACeQOuEobQC0Y0QGIkEb
	De+LuJ5d1ns5YglCDNM/hj03dDwWRGVxOe/Zcgk10DaIosixzkKy2mPemNlojbDMveZK
	LI4WUddL6zRS3Awoj7I9Q5AEYHae5xWjcoAY3wy7Y/No+GS3zJSNCtMjYKl89BQMDqzg
	pzHYhk1+13XAlexd4pExd18iDXzJmb/c1Z+2sdEoQElTxyWVEi1gvomPANIT56ztH0RQ
	n6wA==
X-Received: by 10.14.220.135 with SMTP id o7mr21800269eep.3.1361026636717;
	Sat, 16 Feb 2013 06:57:16 -0800 (PST)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it. [87.4.79.231])
	by mx.google.com with ESMTPS id k7sm86176135een.8.2013.02.16.06.57.14
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 16 Feb 2013 06:57:15 -0800 (PST)
Message-ID: <511F9E44.1020702@heliman.it>
Date: Sat, 16 Feb 2013 15:57:08 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
	<1360936015.31407.67.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360936015.31407.67.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQkfng9+/109pdcIeCUUc4887cFjuEd0xDyNcxTvcxZaA2vJq1jNNm7uLEth1wKS9GQmqBxi
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v6] tools/libxl: Improve videoram 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-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

Il 15/02/2013 14:46, Ian Campbell ha scritto:
> On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
>> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>
>>> - If videoram setting is less than 8 mb shows error and exit.
>>> - Added videoram setting for qemu upstream with cirrus (added in qemu 1.3).
>>> - Updated xl.cfg man.
>>> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>>>    qemu is being used. This is required by qemu 1.4 to avoid a xen memory error
>>>    (qemu 1.3 doesn't complain about it, probably buggy).
>>>
>>> Changes from v5:
>>> - Default and minimal videoram changed to 16 mb if stdvga is set and upstream
>>>    qemu is being used.
>>>
>>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Applied, thanks.
>
This patch should be backported to xen 4.2.x for fix crash of qemu 1.4 
with stdvga (tested with debian experimental package)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 16 17:56:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 17:56: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 1U6lzl-0006wM-B4; Sat, 16 Feb 2013 17:56:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U6lzj-0006wE-0t; Sat, 16 Feb 2013 17:56:15 +0000
Received: from [85.158.137.99:18629] by server-5.bemta-3.messagelabs.com id
	1F/AF-04457-938CF115; Sat, 16 Feb 2013 17:56:09 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361037368!20890405!1
X-Originating-IP: [74.125.82.180]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9784 invoked from network); 16 Feb 2013 17:56:08 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 17:56:08 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so3609941wer.25
	for <multiple recipients>; Sat, 16 Feb 2013 09:56:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=OTK7eymCYKF2YI2rRCLHzvl1r7ql/1cDLWX2b81ZK1Q=;
	b=aPYrnWYKVqjQStfuwi6yPZ24oBCK0sxWR4AU2XECP+Cty2p6HodMMYpAtICcRbqdla
	za7ZZJk4JkcMKrxbTuTpADiOgsWIvk7/Ky3XrPF7vsihqV2vhawAYLt9jBXult9A08jZ
	vccd5W8h5Brf+RLfFWMaDxw/kMKxbrLKFZRHq5TNri4IPN3APmxUDJAmYdHOBfH9s2L9
	h2/c2EB/d/qBe1eGu/k2WEQUeohAKsHIZsSN02ONfmhcffwqCMJ9Wsk6WH0P6h8ytaK8
	UsiXuuSey18u2r+c0y+mRqCapHfX16ea1tFDUz5hxpPq8OJRi3bBGf2wwe+a1bIi8/9b
	6MEA==
MIME-Version: 1.0
X-Received: by 10.180.85.103 with SMTP id g7mr10238221wiz.29.1361037368062;
	Sat, 16 Feb 2013 09:56:08 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Sat, 16 Feb 2013 09:56:07 -0800 (PST)
Date: Sat, 16 Feb 2013 18:56:07 +0100
Message-ID: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2620370568437994005=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2620370568437994005==
Content-Type: multipart/alternative; boundary=f46d043bdce6d9728f04d5db3412

--f46d043bdce6d9728f04d5db3412
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I am configure my machine to run the remus disk replication. I am using xen
4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0 and
DomU.
I have install the blktap and its work properly with configuration string
phy or tap2 like this :
disk = ['phy:/dev/vggroup/DomU,xvda,w']
or
disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']

and remus command

remus --no-net myvm mybackuphost


However when I change the string as suggested on remus pages to enable the
disk replication its still failed :

name = "DomU"
memory = 1024
disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
vif = ['ip=192.168.1.55,bridge=xenbr0']
bootloader = "pygrub"

with error messages :

name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
Using config file "/etc/xen/DomU.cfg".
Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed
(512  )

and on the log file :


name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
    mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
  File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
line 3987, in create_vbd
    devid = dev_control.createDevice(config)
  File
"/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
line 174, in createDevice
    device = TapdiskController.create(params, file)
  File
"/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
line 286, in create
    return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
  File
"/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
line 233, in exc
    (args, rc, out, err))
TapdiskException: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
failed (512  )

Any hints and help would very appreciated.

Regards,

Agya

--f46d043bdce6d9728f04d5db3412
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear all,<div><br></div><div>I am configure my machine to run the remus dis=
k replication. I am using xen 4.2.3 installed from sources and Ubuntu 12.04=
 64 bit both for Dom0 and DomU.=A0</div><div><span style=3D"color:rgb(34,34=
,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,2=
55,255)">I have install the blktap and its work properly with configuration=
 string phy or tap2 like this :</span><div style=3D"color:rgb(34,34,34);fon=
t-size:13px;background-color:rgb(255,255,255)">
<div><font face=3D"courier new, monospace">disk =3D [&#39;phy:/dev/vggroup/=
DomU,xvda,w&#39;]</font></div><div style=3D"font-family:arial,sans-serif">o=
r</div><div><font face=3D"courier new, monospace">disk =3D [&#39;tap2:tapdi=
sk:aio:/dev/vggroup/DomU,xvda,w&#39;]</font></div>
</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:13px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:r=
gb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:r=
gb(255,255,255)">
and remus command=A0</div><div style=3D"color:rgb(34,34,34);font-family:ari=
al,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><=
div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,25=
5,255)">
<span style=3D"color:rgb(96,96,96);font-size:12px"><font face=3D"courier ne=
w, monospace">remus --no-net myvm mybackuphost</font></span></div><div styl=
e=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;backgr=
ound-color:rgb(255,255,255)">
<span style=3D"color:rgb(96,96,96);font-family:monospace;font-size:12px"><b=
r></span></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-ser=
if;font-size:13px;background-color:rgb(255,255,255)"><span style=3D"color:r=
gb(96,96,96);font-family:monospace;font-size:12px"><br>
</span></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:13px;background-color:rgb(255,255,255)">However when I change th=
e string as suggested on remus pages to enable the disk replication its sti=
ll failed :</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13=
px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:rgb(34,=
34,34);font-size:13px;background-color:rgb(255,255,255)"><div><font face=3D=
"courier new, monospace">name =3D &quot;DomU&quot;</font></div>
<div><font face=3D"courier new, monospace">memory =3D 1024</font></div><div=
><font face=3D"courier new, monospace">disk =3D [&#39;tap2:remus:10.10.10.3=
:8002|aio:/dev/vggroup/DomU,xvda,w&#39;] =A0</font></div><div><font face=3D=
"courier new, monospace">vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#3=
9;]</font></div>
<div><font face=3D"courier new, monospace">bootloader =3D &quot;pygrub&quot=
;</font></div><div style=3D"font-family:arial,sans-serif"><br></div><font f=
ace=3D"arial, sans-serif">with error messages :</font></div><div style=3D"c=
olor:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-c=
olor:rgb(255,255,255)">
<br></div><div style=3D"color:rgb(34,34,34);font-size:13px;background-color=
:rgb(255,255,255)"><div><font face=3D"courier new, monospace">name1@machine=
1:~$ sudo xm create -c /etc/xen/DomU.cfg</font></div><div><font face=3D"cou=
rier new, monospace">Using config file &quot;/etc/xen/DomU.cfg&quot;.</font=
></div>
<div><font face=3D"courier new, monospace">Error: (&#39;create&#39;, &#39;-=
aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) failed (512 =A0)</font><=
/div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"fo=
nt-family:arial,sans-serif">
and on the log file :</div><div style=3D"font-family:arial,sans-serif"><br>=
</div><div><div style=3D"font-family:arial,sans-serif"><br></div><div><font=
 face=3D"courier new, monospace">name1@machine1:~$ sudo sudo tail /var/log/=
xen/xend.log</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 mounted_vbd_uuid =3D dom=
0.create_vbd(vbd, disk);</font></div><div><font face=3D"courier new, monosp=
ace">=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom=
ainInfo.py&quot;, line 3987, in create_vbd</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 devid =3D dev_control.cr=
eateDevice(config)</font></div><div><font face=3D"courier new, monospace">=
=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;, line 174, in createDevice</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 device =3D TapdiskContro=
ller.create(params, file)</font></div><div><font face=3D"courier new, monos=
pace">=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server=
/BlktapController.py&quot;, line 286, in create</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 return TapdiskController=
.exc(&#39;create&#39;, &#39;-a%s:%s&#39; % (dtype, image))</font></div><div=
><font face=3D"courier new, monospace">=A0 File &quot;/usr/local/lib/python=
2.7/dist-packages/xen/xend/server/BlktapController.py&quot;, line 233, in e=
xc</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 (args, rc, out, err))</f=
ont></div><div><font face=3D"courier new, monospace">TapdiskException: (&#3=
9;create&#39;, &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) fai=
led (512 =A0)</font></div>
</div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"f=
ont-family:arial,sans-serif">Any hints and help would very appreciated.</di=
v><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"font-=
family:arial,sans-serif">
Regards,</div><div style=3D"font-family:arial,sans-serif"><br></div><div st=
yle=3D"font-family:arial,sans-serif">Agya</div><div class=3D"yj6qo ajU" sty=
le=3D"font-family:arial,sans-serif;outline:none;padding:10px 0px;width:22px=
;margin:2px 0px 0px">
<br></div></div></div>

--f46d043bdce6d9728f04d5db3412--


--===============2620370568437994005==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2620370568437994005==--


From xen-devel-bounces@lists.xen.org Sat Feb 16 17:56:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 16 Feb 2013 17:56: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 1U6lzl-0006wM-B4; Sat, 16 Feb 2013 17:56:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U6lzj-0006wE-0t; Sat, 16 Feb 2013 17:56:15 +0000
Received: from [85.158.137.99:18629] by server-5.bemta-3.messagelabs.com id
	1F/AF-04457-938CF115; Sat, 16 Feb 2013 17:56:09 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361037368!20890405!1
X-Originating-IP: [74.125.82.180]
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-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9784 invoked from network); 16 Feb 2013 17:56:08 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 17:56:08 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so3609941wer.25
	for <multiple recipients>; Sat, 16 Feb 2013 09:56:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=OTK7eymCYKF2YI2rRCLHzvl1r7ql/1cDLWX2b81ZK1Q=;
	b=aPYrnWYKVqjQStfuwi6yPZ24oBCK0sxWR4AU2XECP+Cty2p6HodMMYpAtICcRbqdla
	za7ZZJk4JkcMKrxbTuTpADiOgsWIvk7/Ky3XrPF7vsihqV2vhawAYLt9jBXult9A08jZ
	vccd5W8h5Brf+RLfFWMaDxw/kMKxbrLKFZRHq5TNri4IPN3APmxUDJAmYdHOBfH9s2L9
	h2/c2EB/d/qBe1eGu/k2WEQUeohAKsHIZsSN02ONfmhcffwqCMJ9Wsk6WH0P6h8ytaK8
	UsiXuuSey18u2r+c0y+mRqCapHfX16ea1tFDUz5hxpPq8OJRi3bBGf2wwe+a1bIi8/9b
	6MEA==
MIME-Version: 1.0
X-Received: by 10.180.85.103 with SMTP id g7mr10238221wiz.29.1361037368062;
	Sat, 16 Feb 2013 09:56:08 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Sat, 16 Feb 2013 09:56:07 -0800 (PST)
Date: Sat, 16 Feb 2013 18:56:07 +0100
Message-ID: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2620370568437994005=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2620370568437994005==
Content-Type: multipart/alternative; boundary=f46d043bdce6d9728f04d5db3412

--f46d043bdce6d9728f04d5db3412
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I am configure my machine to run the remus disk replication. I am using xen
4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0 and
DomU.
I have install the blktap and its work properly with configuration string
phy or tap2 like this :
disk = ['phy:/dev/vggroup/DomU,xvda,w']
or
disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']

and remus command

remus --no-net myvm mybackuphost


However when I change the string as suggested on remus pages to enable the
disk replication its still failed :

name = "DomU"
memory = 1024
disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
vif = ['ip=192.168.1.55,bridge=xenbr0']
bootloader = "pygrub"

with error messages :

name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
Using config file "/etc/xen/DomU.cfg".
Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed
(512  )

and on the log file :


name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
    mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
  File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
line 3987, in create_vbd
    devid = dev_control.createDevice(config)
  File
"/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
line 174, in createDevice
    device = TapdiskController.create(params, file)
  File
"/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
line 286, in create
    return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
  File
"/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
line 233, in exc
    (args, rc, out, err))
TapdiskException: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
failed (512  )

Any hints and help would very appreciated.

Regards,

Agya

--f46d043bdce6d9728f04d5db3412
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear all,<div><br></div><div>I am configure my machine to run the remus dis=
k replication. I am using xen 4.2.3 installed from sources and Ubuntu 12.04=
 64 bit both for Dom0 and DomU.=A0</div><div><span style=3D"color:rgb(34,34=
,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,2=
55,255)">I have install the blktap and its work properly with configuration=
 string phy or tap2 like this :</span><div style=3D"color:rgb(34,34,34);fon=
t-size:13px;background-color:rgb(255,255,255)">
<div><font face=3D"courier new, monospace">disk =3D [&#39;phy:/dev/vggroup/=
DomU,xvda,w&#39;]</font></div><div style=3D"font-family:arial,sans-serif">o=
r</div><div><font face=3D"courier new, monospace">disk =3D [&#39;tap2:tapdi=
sk:aio:/dev/vggroup/DomU,xvda,w&#39;]</font></div>
</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:13px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:r=
gb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:r=
gb(255,255,255)">
and remus command=A0</div><div style=3D"color:rgb(34,34,34);font-family:ari=
al,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><=
div style=3D"color:rgb(34,34,34);font-size:13px;background-color:rgb(255,25=
5,255)">
<span style=3D"color:rgb(96,96,96);font-size:12px"><font face=3D"courier ne=
w, monospace">remus --no-net myvm mybackuphost</font></span></div><div styl=
e=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;backgr=
ound-color:rgb(255,255,255)">
<span style=3D"color:rgb(96,96,96);font-family:monospace;font-size:12px"><b=
r></span></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-ser=
if;font-size:13px;background-color:rgb(255,255,255)"><span style=3D"color:r=
gb(96,96,96);font-family:monospace;font-size:12px"><br>
</span></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:13px;background-color:rgb(255,255,255)">However when I change th=
e string as suggested on remus pages to enable the disk replication its sti=
ll failed :</div>
<div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13=
px;background-color:rgb(255,255,255)"><br></div><div style=3D"color:rgb(34,=
34,34);font-size:13px;background-color:rgb(255,255,255)"><div><font face=3D=
"courier new, monospace">name =3D &quot;DomU&quot;</font></div>
<div><font face=3D"courier new, monospace">memory =3D 1024</font></div><div=
><font face=3D"courier new, monospace">disk =3D [&#39;tap2:remus:10.10.10.3=
:8002|aio:/dev/vggroup/DomU,xvda,w&#39;] =A0</font></div><div><font face=3D=
"courier new, monospace">vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#3=
9;]</font></div>
<div><font face=3D"courier new, monospace">bootloader =3D &quot;pygrub&quot=
;</font></div><div style=3D"font-family:arial,sans-serif"><br></div><font f=
ace=3D"arial, sans-serif">with error messages :</font></div><div style=3D"c=
olor:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-c=
olor:rgb(255,255,255)">
<br></div><div style=3D"color:rgb(34,34,34);font-size:13px;background-color=
:rgb(255,255,255)"><div><font face=3D"courier new, monospace">name1@machine=
1:~$ sudo xm create -c /etc/xen/DomU.cfg</font></div><div><font face=3D"cou=
rier new, monospace">Using config file &quot;/etc/xen/DomU.cfg&quot;.</font=
></div>
<div><font face=3D"courier new, monospace">Error: (&#39;create&#39;, &#39;-=
aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) failed (512 =A0)</font><=
/div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"fo=
nt-family:arial,sans-serif">
and on the log file :</div><div style=3D"font-family:arial,sans-serif"><br>=
</div><div><div style=3D"font-family:arial,sans-serif"><br></div><div><font=
 face=3D"courier new, monospace">name1@machine1:~$ sudo sudo tail /var/log/=
xen/xend.log</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 mounted_vbd_uuid =3D dom=
0.create_vbd(vbd, disk);</font></div><div><font face=3D"courier new, monosp=
ace">=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom=
ainInfo.py&quot;, line 3987, in create_vbd</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 devid =3D dev_control.cr=
eateDevice(config)</font></div><div><font face=3D"courier new, monospace">=
=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;, line 174, in createDevice</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 device =3D TapdiskContro=
ller.create(params, file)</font></div><div><font face=3D"courier new, monos=
pace">=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server=
/BlktapController.py&quot;, line 286, in create</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 return TapdiskController=
.exc(&#39;create&#39;, &#39;-a%s:%s&#39; % (dtype, image))</font></div><div=
><font face=3D"courier new, monospace">=A0 File &quot;/usr/local/lib/python=
2.7/dist-packages/xen/xend/server/BlktapController.py&quot;, line 233, in e=
xc</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 (args, rc, out, err))</f=
ont></div><div><font face=3D"courier new, monospace">TapdiskException: (&#3=
9;create&#39;, &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) fai=
led (512 =A0)</font></div>
</div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"f=
ont-family:arial,sans-serif">Any hints and help would very appreciated.</di=
v><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"font-=
family:arial,sans-serif">
Regards,</div><div style=3D"font-family:arial,sans-serif"><br></div><div st=
yle=3D"font-family:arial,sans-serif">Agya</div><div class=3D"yj6qo ajU" sty=
le=3D"font-family:arial,sans-serif;outline:none;padding:10px 0px;width:22px=
;margin:2px 0px 0px">
<br></div></div></div>

--f46d043bdce6d9728f04d5db3412--


--===============2620370568437994005==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2620370568437994005==--


From xen-devel-bounces@lists.xen.org Sun Feb 17 03:54:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 03:54: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 1U6vJO-0003my-Ub; Sun, 17 Feb 2013 03:53:10 +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 1U6vJN-0003mt-2C
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 03:53:09 +0000
Received: from [85.158.139.211:44799] by server-14.bemta-5.messagelabs.com id
	52/6C-06967-42450215; Sun, 17 Feb 2013 03:53:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361073186!22768107!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5217 invoked from network); 17 Feb 2013 03:53:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2013 03:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,681,1355097600"; 
   d="scan'208";a="7483454"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	17 Feb 2013 03:53:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Sat, 16 Feb 2013 22:53:04 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6vJI-0004Tv-TO;
	Sun, 17 Feb 2013 03:53:04 +0000
Message-ID: <1361073184.16636.212.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Sun, 17 Feb 2013 03:53:04 +0000
In-Reply-To: <1360939921.31407.92.camel@zakaz.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
	<1360061930.17017.34.camel@zakaz.uk.xensource.com>
	<1360071105.7477.139.camel@zion.uk.xensource.com>
	<1360939921.31407.92.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 14:52 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 13:31 +0000, Wei Liu wrote:
> 
> > -----8<----
> > From 22a7b50b8b0be62aeae7c86242a27dac1ffdb929 Mon Sep 17 00:00:00 2001
> > From: Wei Liu <wei.liu2@citrix.com>
> > Date: Mon, 21 Jan 2013 19:07:37 +0000
> > Subject: [PATCH] Switch to poll() in cxenstored's IO loop
> > 
> > Poll() can support more file descriptors than select(). We've done this for
> > xenconsoled, now do this for cxenstored as well.
> > 
> > The code is taken from xenconsoled and modified to adapt to cxenstored.
> > 
> > Updated:
> > * reopen pipe if polling on reopen_log_pipe fails.
> > * exit if polling on some critical fds fails.
> > * clean up POLL*.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Does this build for you? It fails to build for me in a fairly obvious
> way with:
>         xenstored_core.c:22:18: error: poll.h: No such file or directory
> followed by the inevitable fallout.
> 
> Oh, this is the stubdomain build! I suppose mini-os lacks poll support.
> 
> Faced with either making xenstored able to use poll or select as a
> compile time option and implementing poll for mini-os I'd probably go
> for the latter, presuming that most of the infrastructure is present
> already...
> 

Right. The header file is easy. Stefano introduced that years ago back
in 2008, but the implementation is missing.

Looking deeper in the code, poll is also missing in LWIP, but I think I
can skip that at the moment, or use lwip_select in Mini-OS's poll as
well...

Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 03:54:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 03:54: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 1U6vJO-0003my-Ub; Sun, 17 Feb 2013 03:53:10 +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 1U6vJN-0003mt-2C
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 03:53:09 +0000
Received: from [85.158.139.211:44799] by server-14.bemta-5.messagelabs.com id
	52/6C-06967-42450215; Sun, 17 Feb 2013 03:53:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361073186!22768107!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5217 invoked from network); 17 Feb 2013 03:53:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2013 03:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,681,1355097600"; 
   d="scan'208";a="7483454"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	17 Feb 2013 03:53:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Sat, 16 Feb 2013 22:53:04 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U6vJI-0004Tv-TO;
	Sun, 17 Feb 2013 03:53:04 +0000
Message-ID: <1361073184.16636.212.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Sun, 17 Feb 2013 03:53:04 +0000
In-Reply-To: <1360939921.31407.92.camel@zakaz.uk.xensource.com>
References: <1358796212-24178-1-git-send-email-wei.liu2@citrix.com>
	<1358848038.3279.296.camel@zakaz.uk.xensource.com>
	<1358863999.1836.23.camel@zion.uk.xensource.com>
	<1358864727.3279.374.camel@zakaz.uk.xensource.com>
	<1358866214.1836.35.camel@zion.uk.xensource.com>
	<1360061930.17017.34.camel@zakaz.uk.xensource.com>
	<1360071105.7477.139.camel@zion.uk.xensource.com>
	<1360939921.31407.92.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 14:52 +0000, Ian Campbell wrote:
> On Tue, 2013-02-05 at 13:31 +0000, Wei Liu wrote:
> 
> > -----8<----
> > From 22a7b50b8b0be62aeae7c86242a27dac1ffdb929 Mon Sep 17 00:00:00 2001
> > From: Wei Liu <wei.liu2@citrix.com>
> > Date: Mon, 21 Jan 2013 19:07:37 +0000
> > Subject: [PATCH] Switch to poll() in cxenstored's IO loop
> > 
> > Poll() can support more file descriptors than select(). We've done this for
> > xenconsoled, now do this for cxenstored as well.
> > 
> > The code is taken from xenconsoled and modified to adapt to cxenstored.
> > 
> > Updated:
> > * reopen pipe if polling on reopen_log_pipe fails.
> > * exit if polling on some critical fds fails.
> > * clean up POLL*.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Does this build for you? It fails to build for me in a fairly obvious
> way with:
>         xenstored_core.c:22:18: error: poll.h: No such file or directory
> followed by the inevitable fallout.
> 
> Oh, this is the stubdomain build! I suppose mini-os lacks poll support.
> 
> Faced with either making xenstored able to use poll or select as a
> compile time option and implementing poll for mini-os I'd probably go
> for the latter, presuming that most of the infrastructure is present
> already...
> 

Right. The header file is easy. Stefano introduced that years ago back
in 2008, but the implementation is missing.

Looking deeper in the code, poll is also missing in LWIP, but I think I
can skip that at the moment, or use lwip_select in Mini-OS's poll as
well...

Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 04:05:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 04: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 1U6vUl-00048P-A1; Sun, 17 Feb 2013 04:04:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U6vUj-00048K-Tm
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 04:04:54 +0000
Received: from [85.158.143.99:23720] by server-2.bemta-4.messagelabs.com id
	B6/46-01597-5E650215; Sun, 17 Feb 2013 04:04:53 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361073890!20816099!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzk5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30215 invoked from network); 17 Feb 2013 04:04:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2013 04:04:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1H44lBk012152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 17 Feb 2013 04:04:48 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
	r1H44kBx024288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Feb 2013 04:04:47 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1H44kx1022061; Sat, 16 Feb 2013 22:04:46 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 16 Feb 2013 20:04:44 -0800
Message-ID: <512056D5.6080507@oracle.com>
Date: Sun, 17 Feb 2013 12:04:37 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360057377.17017.7.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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

I got serial console output now and mostly like panic happened by "xl create":

(XEN) HVM1: Detected Xen v4.1.2-OVM
(XEN) HVM1: CPU speed is 2926 MHz
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 13
(XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 04:0 INTA->IRQ5
(XEN) HVM1: pci dev 05:0 INTA->IRQ10
(XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM1: pci dev 04:0 bar 30 size 00080000: f3000000
(XEN) HVM1: pci dev 05:0 bar 30 size 00080000: f3080000
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40
(XEN) HVM1: pci dev 04:0 bar 1c size 00040000: f3100004
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40
(XEN) HVM1: pci dev 05:0 bar 1c size 00040000: f3140004
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3182 mfn=df03e nr_mfns=1
(XEN) HVM1: pci dev 04:0 bar 14 size 00004000: f3180004
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3184 mfn=df63c nr_mfns=4
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3186 mfn=df63e nr_mfns=1
(XEN) HVM1: pci dev 05:0 bar 14 size 00004000: f3184004
(XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3188000
(XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM1: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
(XEN) HVM1: pci dev 05:0 bar 10 size 00000100: 0000c201
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
(XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c301
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU6 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU7 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU8 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU9 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU10 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU11 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: 10364 bytes of ROMBIOS high-memory extensions:
(XEN) HVM1:   Relocating to 0xfc000000-0xfc00287c ... done
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading Cirrus VGABIOS ...
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3000 mfn=df080 nr_mfns=80
(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=df080 nr_mfns=80
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3080 mfn=df680 nr_mfns=80
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3080 mfn=df680 nr_mfns=80
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1:  - Lo data: 000ea020-000ea04f
(XEN) HVM1:  - Hi data: fc002c00-fc00eb4f
(XEN) HVM1: vm86 TSS at fc00ec00
(XEN) HVM1: BIOS map:
(XEN) HVM1:  c0000-c8fff: VGA BIOS
(XEN) HVM1:  c9000-d4fff: PCI Option ROMs
(XEN) HVM1:  eb000-eb302: SMBIOS tables
(XEN) HVM1:  f0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM1:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [04]: 00000000:00100000 - 00000000:f0000000: RAM
(XEN) HVM1:  HOLE: 00000000:f0000000 - 00000000:fc000000
(XEN) HVM1:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1:  [06]: 00000001:00000000 - 00000004:0f800000: RAM
(XEN) HVM1: Invoking ROMBIOS ...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM1: Bochs BIOS - build: 06/23/99
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM1: Options: apmbios pcibios eltorito PMM 
(XEN) HVM1: 
(XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (60000 MBytes)
(XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  97 GBytes)
(XEN) HVM1: ata1-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata1 master: QEMU HARDDISK ATA-7 Hard-Disk (20000 MBytes)
(XEN) HVM1: IDE time out
(XEN) HVM1: 
(XEN) HVM1: PCI device 1000:0070 not found at index 0
(XEN) HVM1: PCI device 1000:0072 not found at index 2
(XEN) HVM1: PCI device 1000:0074 not found at index 0
(XEN) HVM1: PCI device 1000:0076 not found at index 0
(XEN) HVM1: PCI device 1000:0077 not found at index 0
(XEN) HVM1: PCI device 1000:0064 not found at index 0
(XEN) HVM1: PCI device 1000:0065 not found at index 0
(XEN) HVM1: PCI device 1000:0080 not found at index 0
(XEN) HVM1: PCI device 1000:0081 not found at index 0
(XEN) HVM1: PCI device 1000:0082 not found at index 0
(XEN) HVM1: PCI device 1000:0083 not found at index 0
(XEN) HVM1: PCI device 1000:0084 not found at index 0
(XEN) HVM1: PCI device 1000:0085 not found at index 0
(XEN) HVM1: PCI device 1000:0086 not found at index 0
(XEN) HVM1: PCI device 1000:0087 not found at index 0
(XEN) HVM1: PCI device 1000:0070 not found at index 0
(XEN) HVM1: PCI device 1000:0072 not found at index 2
(XEN) HVM1: PCI device 1000:0074 not found at index 0
(XEN) HVM1: PCI device 1000:0076 not found at index 0
(XEN) HVM1: PCI device 1000:0077 not found at index 0
(XEN) HVM1: PCI device 1000:0064 not found at index 0
(XEN) HVM1: PCI device 1000:0065 not found at index 0
(XEN) HVM1: PCI device 1000:0080 not found at index 0
(XEN) HVM1: PCI device 1000:0081 not found at index 0
(XEN) HVM1: PCI device 1000:0082 not found at index 0
(XEN) HVM1: PCI device 1000:0083 not found at index 0
(XEN) HVM1: PCI device 1000:0084 not found at index 0
(XEN) HVM1: PCI device 1000:0085 not found at index 0
(XEN) HVM1: PCI device 1000:0086 not found at index 0
(XEN) HVM1: PCI device 1000:0087 not found at index 0
(XEN) HVM1: 
(XEN) HVM1: 
(XEN) HVM1: Press F12 for boot menu.
(XEN) HVM1: 
(XEN) HVM1: Booting from Hard Disk...
(XEN) HVM1: Booting from 0000:7c00
(XEN) HVM1: *** int 15h function AX=00c0, BX=0000 not yet supported!
(XEN) HVM1: *** int 15h function AX=ec00, BX=0002 not yet supported!
(XEN) HVM1: KBD: unsupported int 16h function 03
(XEN) HVM1: *** int 15h function AX=e980, BX=0000 not yet supported!
(XEN) irq.c:330: Dom1 callback via changed to Direct Vector 0xe9
(XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
(XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=100
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
(XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x22d/0x240()
Hardware name: SUN FIRE X4370 M2 SERVER       
remove_proc_entry: removing non-empty directory 'irq/536', leaking at least 'eth7'
Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]
Pid: 19329, comm: qemu-dm Not tainted 2.6.39-200.1.15.el5uek #1
Call Trace:
 [<ffffffff811d10dd>] ? remove_proc_entry+0x22d/0x240
 [<ffffffff8106de10>] warn_slowpath_common+0x90/0xc0
 [<ffffffff8106df3e>] warn_slowpath_fmt+0x6e/0x70
 [<ffffffff8100a7cf>] ? xen_restore_fl_direct_reloc+0x4/0x4
 [<ffffffff8125cf98>] ? sprintf+0x68/0x70
 [<ffffffff811cfef1>] ? __xlate_proc_name+0x41/0xc0
 [<ffffffff81501b9e>] ? _raw_spin_lock+0xe/0x20
 [<ffffffff811d10dd>] remove_proc_entry+0x22d/0x240
 [<ffffffff8113232c>] ? zap_pte_range+0x1ec/0x400
 [<ffffffff810d9430>] unregister_irq_proc+0xd0/0xf0
 [<ffffffff810d571a>] free_desc+0x2a/0x70
 [<ffffffff810d579e>] irq_free_descs+0x3e/0x80
 [<ffffffff812f7822>] xen_free_irq+0x52/0x70
 [<ffffffff812f82cb>] unbind_from_irq+0xeb/0x180
 [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff812f837f>] evtchn_put+0x1f/0x40
 [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
 [<ffffffff812640e1>] ? list_del+0x11/0x40
 [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
 [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
 [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
 [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
 [<ffffffff8113a740>] ? do_munmap+0x240/0x280
 [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
 [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
---[ end trace fa61ba514bac93c7 ]---
BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
PGD 6a2cb067 PUD 71d8c067 PMD 0 
Oops: 0000 [#1] SMP 
CPU 0 
Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]

Pid: 19329, comm: qemu-dm Tainted: G        W   2.6.39-200.1.15.el5uek #1 ORACLE CORPORATION SUN FIRE X4370 M2 SERVER       /ASSY,SC_BD,T4         
RIP: e030:[<ffffffff812f6a76>]  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
RSP: e02b:ffff88006cfc5dd8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88007e38be48
RDX: 0000000000000000 RSI: 0000000000000218 RDI: ffff88007e38bd70
RBP: ffff88006cfc5dd8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000218
R13: 0000000000000000 R14: 0000000000000017 R15: 0000000000104701
FS:  00007ff36f4046e0(0000) GS:ffff88007f49a000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 000000005f445000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-dm (pid: 19329, threadinfo ffff88006cfc4000, task ffff880067084200)
Stack:
 ffff88006cfc5e38 ffffffff812f81fc 00007ff36e620000 0000003e38e10000
 ffff88006cfc5e38 000000000000014f 0000000000000206 ffff88006b2e8138
 ffffffff81009f0d ffff88006b951cc0 ffff88006b951cc0 0000000000000000
Call Trace:
 [<ffffffff812f81fc>] unbind_from_irq+0x1c/0x180
 [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff812f837f>] evtchn_put+0x1f/0x40
 [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
 [<ffffffff812640e1>] ? list_del+0x11/0x40
 [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
 [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
 [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
 [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
 [<ffffffff8113a740>] ? do_munmap+0x240/0x280
 [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
 [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
Code: 8b 64 24 08 c9 c3 0f 1f 80 00 00 00 00 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 39 3d f1 16 4c 00 76 0b e8 ea fa ff ff <0f> b7 40 1c c9 c3 89 f9 31 c0 48 c7 c2 2f 72 70 81 be d1 00 00 
RIP  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
 RSP <ffff88006cfc5dd8>
CR2: 000000000000001c

Thanks,
Joe
On 02/05/13 17:42, Ian Campbell wrote:
> On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
>> execute xl-destroy twice crashed my server!
> 
> Can you give more details please.
> 
> Ian.
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 04:05:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 04: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 1U6vUl-00048P-A1; Sun, 17 Feb 2013 04:04:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U6vUj-00048K-Tm
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 04:04:54 +0000
Received: from [85.158.143.99:23720] by server-2.bemta-4.messagelabs.com id
	B6/46-01597-5E650215; Sun, 17 Feb 2013 04:04:53 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361073890!20816099!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzk5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30215 invoked from network); 17 Feb 2013 04:04:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Feb 2013 04:04:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1H44lBk012152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 17 Feb 2013 04:04:48 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
	r1H44kBx024288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Feb 2013 04:04:47 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1H44kx1022061; Sat, 16 Feb 2013 22:04:46 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 16 Feb 2013 20:04:44 -0800
Message-ID: <512056D5.6080507@oracle.com>
Date: Sun, 17 Feb 2013 12:04:37 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
In-Reply-To: <1360057377.17017.7.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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

I got serial console output now and mostly like panic happened by "xl create":

(XEN) HVM1: Detected Xen v4.1.2-OVM
(XEN) HVM1: CPU speed is 2926 MHz
(XEN) HVM1: Xenbus rings @0xfeffc000, event channel 13
(XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10
(XEN) HVM1: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11
(XEN) HVM1: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5
(XEN) HVM1: PCI-ISA link 3 routed to IRQ5
(XEN) HVM1: pci dev 01:3 INTA->IRQ10
(XEN) HVM1: pci dev 03:0 INTA->IRQ5
(XEN) HVM1: pci dev 04:0 INTA->IRQ5
(XEN) HVM1: pci dev 05:0 INTA->IRQ10
(XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM1: pci dev 04:0 bar 30 size 00080000: f3000000
(XEN) HVM1: pci dev 05:0 bar 30 size 00080000: f3080000
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40
(XEN) HVM1: pci dev 04:0 bar 1c size 00040000: f3100004
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40
(XEN) HVM1: pci dev 05:0 bar 1c size 00040000: f3140004
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3182 mfn=df03e nr_mfns=1
(XEN) HVM1: pci dev 04:0 bar 14 size 00004000: f3180004
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3184 mfn=df63c nr_mfns=4
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3186 mfn=df63e nr_mfns=1
(XEN) HVM1: pci dev 05:0 bar 14 size 00004000: f3184004
(XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3188000
(XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM1: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
(XEN) HVM1: pci dev 05:0 bar 10 size 00000100: 0000c201
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
(XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c301
(XEN) HVM1: Multiprocessor initialisation:
(XEN) HVM1:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU6 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU7 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU8 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU9 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU10 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1:  - CPU11 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM1: Writing SMBIOS tables ...
(XEN) HVM1: Loading ROMBIOS ...
(XEN) HVM1: 10364 bytes of ROMBIOS high-memory extensions:
(XEN) HVM1:   Relocating to 0xfc000000-0xfc00287c ... done
(XEN) HVM1: Creating MP tables ...
(XEN) HVM1: Loading Cirrus VGABIOS ...
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3000 mfn=df080 nr_mfns=80
(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=df080 nr_mfns=80
(XEN) domctl.c:985:d0 memory_map:add: gfn=f3080 mfn=df680 nr_mfns=80
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3080 mfn=df680 nr_mfns=80
(XEN) HVM1: Loading ACPI ...
(XEN) HVM1:  - Lo data: 000ea020-000ea04f
(XEN) HVM1:  - Hi data: fc002c00-fc00eb4f
(XEN) HVM1: vm86 TSS at fc00ec00
(XEN) HVM1: BIOS map:
(XEN) HVM1:  c0000-c8fff: VGA BIOS
(XEN) HVM1:  c9000-d4fff: PCI Option ROMs
(XEN) HVM1:  eb000-eb302: SMBIOS tables
(XEN) HVM1:  f0000-fffff: Main BIOS
(XEN) HVM1: E820 table:
(XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
(XEN) HVM1:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
(XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM1:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM1:  [04]: 00000000:00100000 - 00000000:f0000000: RAM
(XEN) HVM1:  HOLE: 00000000:f0000000 - 00000000:fc000000
(XEN) HVM1:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM1:  [06]: 00000001:00000000 - 00000004:0f800000: RAM
(XEN) HVM1: Invoking ROMBIOS ...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM1: Bochs BIOS - build: 06/23/99
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM1: Options: apmbios pcibios eltorito PMM 
(XEN) HVM1: 
(XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (60000 MBytes)
(XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  97 GBytes)
(XEN) HVM1: ata1-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM1: ata1 master: QEMU HARDDISK ATA-7 Hard-Disk (20000 MBytes)
(XEN) HVM1: IDE time out
(XEN) HVM1: 
(XEN) HVM1: PCI device 1000:0070 not found at index 0
(XEN) HVM1: PCI device 1000:0072 not found at index 2
(XEN) HVM1: PCI device 1000:0074 not found at index 0
(XEN) HVM1: PCI device 1000:0076 not found at index 0
(XEN) HVM1: PCI device 1000:0077 not found at index 0
(XEN) HVM1: PCI device 1000:0064 not found at index 0
(XEN) HVM1: PCI device 1000:0065 not found at index 0
(XEN) HVM1: PCI device 1000:0080 not found at index 0
(XEN) HVM1: PCI device 1000:0081 not found at index 0
(XEN) HVM1: PCI device 1000:0082 not found at index 0
(XEN) HVM1: PCI device 1000:0083 not found at index 0
(XEN) HVM1: PCI device 1000:0084 not found at index 0
(XEN) HVM1: PCI device 1000:0085 not found at index 0
(XEN) HVM1: PCI device 1000:0086 not found at index 0
(XEN) HVM1: PCI device 1000:0087 not found at index 0
(XEN) HVM1: PCI device 1000:0070 not found at index 0
(XEN) HVM1: PCI device 1000:0072 not found at index 2
(XEN) HVM1: PCI device 1000:0074 not found at index 0
(XEN) HVM1: PCI device 1000:0076 not found at index 0
(XEN) HVM1: PCI device 1000:0077 not found at index 0
(XEN) HVM1: PCI device 1000:0064 not found at index 0
(XEN) HVM1: PCI device 1000:0065 not found at index 0
(XEN) HVM1: PCI device 1000:0080 not found at index 0
(XEN) HVM1: PCI device 1000:0081 not found at index 0
(XEN) HVM1: PCI device 1000:0082 not found at index 0
(XEN) HVM1: PCI device 1000:0083 not found at index 0
(XEN) HVM1: PCI device 1000:0084 not found at index 0
(XEN) HVM1: PCI device 1000:0085 not found at index 0
(XEN) HVM1: PCI device 1000:0086 not found at index 0
(XEN) HVM1: PCI device 1000:0087 not found at index 0
(XEN) HVM1: 
(XEN) HVM1: 
(XEN) HVM1: Press F12 for boot menu.
(XEN) HVM1: 
(XEN) HVM1: Booting from Hard Disk...
(XEN) HVM1: Booting from 0000:7c00
(XEN) HVM1: *** int 15h function AX=00c0, BX=0000 not yet supported!
(XEN) HVM1: *** int 15h function AX=ec00, BX=0002 not yet supported!
(XEN) HVM1: KBD: unsupported int 16h function 03
(XEN) HVM1: *** int 15h function AX=e980, BX=0000 not yet supported!
(XEN) irq.c:330: Dom1 callback via changed to Direct Vector 0xe9
(XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
(XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=100
(XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
(XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x22d/0x240()
Hardware name: SUN FIRE X4370 M2 SERVER       
remove_proc_entry: removing non-empty directory 'irq/536', leaking at least 'eth7'
Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]
Pid: 19329, comm: qemu-dm Not tainted 2.6.39-200.1.15.el5uek #1
Call Trace:
 [<ffffffff811d10dd>] ? remove_proc_entry+0x22d/0x240
 [<ffffffff8106de10>] warn_slowpath_common+0x90/0xc0
 [<ffffffff8106df3e>] warn_slowpath_fmt+0x6e/0x70
 [<ffffffff8100a7cf>] ? xen_restore_fl_direct_reloc+0x4/0x4
 [<ffffffff8125cf98>] ? sprintf+0x68/0x70
 [<ffffffff811cfef1>] ? __xlate_proc_name+0x41/0xc0
 [<ffffffff81501b9e>] ? _raw_spin_lock+0xe/0x20
 [<ffffffff811d10dd>] remove_proc_entry+0x22d/0x240
 [<ffffffff8113232c>] ? zap_pte_range+0x1ec/0x400
 [<ffffffff810d9430>] unregister_irq_proc+0xd0/0xf0
 [<ffffffff810d571a>] free_desc+0x2a/0x70
 [<ffffffff810d579e>] irq_free_descs+0x3e/0x80
 [<ffffffff812f7822>] xen_free_irq+0x52/0x70
 [<ffffffff812f82cb>] unbind_from_irq+0xeb/0x180
 [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff812f837f>] evtchn_put+0x1f/0x40
 [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
 [<ffffffff812640e1>] ? list_del+0x11/0x40
 [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
 [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
 [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
 [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
 [<ffffffff8113a740>] ? do_munmap+0x240/0x280
 [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
 [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
---[ end trace fa61ba514bac93c7 ]---
BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
IP: [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
PGD 6a2cb067 PUD 71d8c067 PMD 0 
Oops: 0000 [#1] SMP 
CPU 0 
Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]

Pid: 19329, comm: qemu-dm Tainted: G        W   2.6.39-200.1.15.el5uek #1 ORACLE CORPORATION SUN FIRE X4370 M2 SERVER       /ASSY,SC_BD,T4         
RIP: e030:[<ffffffff812f6a76>]  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
RSP: e02b:ffff88006cfc5dd8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88007e38be48
RDX: 0000000000000000 RSI: 0000000000000218 RDI: ffff88007e38bd70
RBP: ffff88006cfc5dd8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000218
R13: 0000000000000000 R14: 0000000000000017 R15: 0000000000104701
FS:  00007ff36f4046e0(0000) GS:ffff88007f49a000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000001c CR3: 000000005f445000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-dm (pid: 19329, threadinfo ffff88006cfc4000, task ffff880067084200)
Stack:
 ffff88006cfc5e38 ffffffff812f81fc 00007ff36e620000 0000003e38e10000
 ffff88006cfc5e38 000000000000014f 0000000000000206 ffff88006b2e8138
 ffffffff81009f0d ffff88006b951cc0 ffff88006b951cc0 0000000000000000
Call Trace:
 [<ffffffff812f81fc>] unbind_from_irq+0x1c/0x180
 [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff812f837f>] evtchn_put+0x1f/0x40
 [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
 [<ffffffff812640e1>] ? list_del+0x11/0x40
 [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
 [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
 [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
 [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
 [<ffffffff8113a740>] ? do_munmap+0x240/0x280
 [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
 [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
Code: 8b 64 24 08 c9 c3 0f 1f 80 00 00 00 00 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 39 3d f1 16 4c 00 76 0b e8 ea fa ff ff <0f> b7 40 1c c9 c3 89 f9 31 c0 48 c7 c2 2f 72 70 81 be d1 00 00 
RIP  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
 RSP <ffff88006cfc5dd8>
CR2: 000000000000001c

Thanks,
Joe
On 02/05/13 17:42, Ian Campbell wrote:
> On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
>> execute xl-destroy twice crashed my server!
> 
> Can you give more details please.
> 
> Ian.
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 05:08:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 05:08: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 1U6wTN-0005Hh-Uj; Sun, 17 Feb 2013 05:07:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U6wTM-0005Hc-5n
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 05:07:32 +0000
Received: from [85.158.139.211:46470] by server-2.bemta-5.messagelabs.com id
	49/03-16911-39560215; Sun, 17 Feb 2013 05:07:31 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361077648!20014443!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzk5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31234 invoked from network); 17 Feb 2013 05:07:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2013 05:07:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1H57PZh012106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 17 Feb 2013 05:07:26 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
	r1H57O2Y008832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Feb 2013 05:07:24 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
	r1H57OmY011200; Sat, 16 Feb 2013 23:07:24 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 16 Feb 2013 21:07:23 -0800
Message-ID: <51206584.8060200@oracle.com>
Date: Sun, 17 Feb 2013 13:07:16 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Joe Jin <joe.jin@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
	<512056D5.6080507@oracle.com>
In-Reply-To: <512056D5.6080507@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Roger Pau Monne <roger.pau@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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

Execute "xl-destroy" twice lead the dom0 panic:
config file as below:

vncunused = 1
kernel = '/usr/lib/xen/boot/hvmloader'
vnc = 1
name = 'test'
memory = '16384'
#memory = '1024'
timer_mode = 0
device_model = '/usr/lib64/xen/bin/qemu-dm'
builder = 'hvm'
vnclisten = '0.0.0.0'
cpus = '0,2,4,6,8,11,1,3,5,7,9,10'
#on_crash = 'coredump-restart'
#on_crash = 'preserve'
on_crash = 'destroy'
on_reboot = 'restart'
vcpus = 12
pci = ['0d:00.0', '1f:00.0']
#pci = ['0d:00.0']
pae = 1
apic = 1
vif = ['type=netfront,bridge=priv1', 'type=netfront,bridge=net1', 'type=netfront,bridge=net2', 'type=netfront,bridge=net3', 'type=netfront,bridge=net4']
serial = 'pty'
disk = ['file:/path/System.img,xvda,w', 'file:/path/u01.img,xvdb,w', 'file:/path/swap.img,xvdc,w']
acpi = 1

Crash info from serial console:

(XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3180 mfn=df03c nr_mfns=4
(XEN) p2m.c:2797:d0 clear_mmio_p2m_entry: gfn_to_mfn failed! gfn=000f3182
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3100 mfn=df040 nr_mfns=40
------------[ cut here ]------------
kernel BUG at drivers/pci/access.c:423!
invalid opcode: 0000 [#1] SMP 
CPU 18 
Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport igb ses enclosure ixgbe mdio e1000e snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore i2c_i801 snd_page_alloc ghes iTCO_wdt i2c_core pcspkr iTCO_vendor_support i7core_edac ioatdma edac_core hed dca dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]

Pid: 20399, comm: xl Not tainted 2.6.39-200.1.15.el5uek #1 ORACLE CORPORATION SUN FIRE X4370 M2 SERVER       /ASSY,SC_BD,T4         
RIP: e030:[<ffffffff812704bf>]  [<ffffffff812704bf>] pci_block_user_cfg_access+0x4f/0x60
RSP: e02b:ffff88006e609dd8  EFLAGS: 00010202
RAX: 0000000000000024 RBX: 0000000000000001 RCX: 00000000800d0004
RDX: 0000000000000400 RSI: 0000000000000200 RDI: 0000000000000200
RBP: ffff88006e609de8 R08: 0000000000000002 R09: 0000000000000400
R10: 0000000000000000 R11: 0000000000000202 R12: ffff8800731e4000
R13: ffff8800731e4000 R14: ffffffff81565e20 R15: ffff8800731e40a0
FS:  00007fb7b5dfa730(0000) GS:ffff88007f66e000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003340613000 CR3: 0000000068440000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process xl (pid: 20399, threadinfo ffff88006e608000, task ffff880071fe0500)
Stack:
 0000000000000000 0000000000000000 ffff88006e609e18 ffffffff812749dc
 ffff8800731e4000 0000000000000000 ffff8800731e4000 00000000ffffffed
 ffff88006e609e38 ffffffff812764c4 ffff8800731e4090 0000000000000001
Call Trace:
 [<ffffffff812749dc>] pci_dev_reset+0x6c/0xd0
 [<ffffffff812764c4>] pci_reset_function+0x54/0x70
 [<ffffffff8127a6ba>] reset_store+0x5a/0x70
 [<ffffffff81342070>] dev_attr_store+0x20/0x30
 [<ffffffff811db48f>] flush_write_buffer+0x5f/0x90
 [<ffffffff811db856>] sysfs_write_file+0x66/0xa0
 [<ffffffff8116dd8e>] vfs_write+0xce/0x190
 [<ffffffff8116e3e5>] sys_write+0x55/0x90
 [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
Code: 07 00 00 48 c7 c7 e0 73 d7 81 89 c3 83 c8 20 c0 eb 05 41 88 84 24 80 07 00 00 83 e3 01 e8 6a 17 29 00 85 db 75 05 5b 41 5c c9 c3 <0f> 0b eb fe 66 0f 1f 44 00 00 0f 1f 80 00 00 00 00 55 48 89 e5 
RIP  [<ffffffff812704bf>] pci_block_user_cfg_access+0x4f/0x60
 RSP <ffff88006e609dd8>
pciback 0000:0d:


BTW: xm-create work fine but xl-create trigger the panic as below:

On 02/17/13 12:04, Joe Jin wrote:
> I got serial console output now and mostly like panic happened by "xl create":
> 
> (XEN) HVM1: Detected Xen v4.1.2-OVM
> (XEN) HVM1: CPU speed is 2926 MHz
> (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 13
> (XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5
> (XEN) HVM1: PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10
> (XEN) HVM1: PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11
> (XEN) HVM1: PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5
> (XEN) HVM1: PCI-ISA link 3 routed to IRQ5
> (XEN) HVM1: pci dev 01:3 INTA->IRQ10
> (XEN) HVM1: pci dev 03:0 INTA->IRQ5
> (XEN) HVM1: pci dev 04:0 INTA->IRQ5
> (XEN) HVM1: pci dev 05:0 INTA->IRQ10
> (XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
> (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
> (XEN) HVM1: pci dev 04:0 bar 30 size 00080000: f3000000
> (XEN) HVM1: pci dev 05:0 bar 30 size 00080000: f3080000
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40
> (XEN) HVM1: pci dev 04:0 bar 1c size 00040000: f3100004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40
> (XEN) HVM1: pci dev 05:0 bar 1c size 00040000: f3140004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3182 mfn=df03e nr_mfns=1
> (XEN) HVM1: pci dev 04:0 bar 14 size 00004000: f3180004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3184 mfn=df63c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3186 mfn=df63e nr_mfns=1
> (XEN) HVM1: pci dev 05:0 bar 14 size 00004000: f3184004
> (XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3188000
> (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
> (XEN) HVM1: pci dev 04:0 bar 10 size 00000100: 0000c101
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) HVM1: pci dev 05:0 bar 10 size 00000100: 0000c201
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c301
> (XEN) HVM1: Multiprocessor initialisation:
> (XEN) HVM1:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU6 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU7 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU8 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU9 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU10 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU11 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1: Writing SMBIOS tables ...
> (XEN) HVM1: Loading ROMBIOS ...
> (XEN) HVM1: 10364 bytes of ROMBIOS high-memory extensions:
> (XEN) HVM1:   Relocating to 0xfc000000-0xfc00287c ... done
> (XEN) HVM1: Creating MP tables ...
> (XEN) HVM1: Loading Cirrus VGABIOS ...
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3000 mfn=df080 nr_mfns=80
> (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=df080 nr_mfns=80
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) HVM1: Loading ACPI ...
> (XEN) HVM1:  - Lo data: 000ea020-000ea04f
> (XEN) HVM1:  - Hi data: fc002c00-fc00eb4f
> (XEN) HVM1: vm86 TSS at fc00ec00
> (XEN) HVM1: BIOS map:
> (XEN) HVM1:  c0000-c8fff: VGA BIOS
> (XEN) HVM1:  c9000-d4fff: PCI Option ROMs
> (XEN) HVM1:  eb000-eb302: SMBIOS tables
> (XEN) HVM1:  f0000-fffff: Main BIOS
> (XEN) HVM1: E820 table:
> (XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
> (XEN) HVM1:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
> (XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM1:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM1:  [04]: 00000000:00100000 - 00000000:f0000000: RAM
> (XEN) HVM1:  HOLE: 00000000:f0000000 - 00000000:fc000000
> (XEN) HVM1:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (XEN) HVM1:  [06]: 00000001:00000000 - 00000004:0f800000: RAM
> (XEN) HVM1: Invoking ROMBIOS ...
> (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) stdvga.c:147:d1 entering stdvga and caching modes
> (XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> (XEN) HVM1: Bochs BIOS - build: 06/23/99
> (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) HVM1: Options: apmbios pcibios eltorito PMM 
> (XEN) HVM1: 
> (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (60000 MBytes)
> (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM1: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  97 GBytes)
> (XEN) HVM1: ata1-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM1: ata1 master: QEMU HARDDISK ATA-7 Hard-Disk (20000 MBytes)
> (XEN) HVM1: IDE time out
> (XEN) HVM1: 
> (XEN) HVM1: PCI device 1000:0070 not found at index 0
> (XEN) HVM1: PCI device 1000:0072 not found at index 2
> (XEN) HVM1: PCI device 1000:0074 not found at index 0
> (XEN) HVM1: PCI device 1000:0076 not found at index 0
> (XEN) HVM1: PCI device 1000:0077 not found at index 0
> (XEN) HVM1: PCI device 1000:0064 not found at index 0
> (XEN) HVM1: PCI device 1000:0065 not found at index 0
> (XEN) HVM1: PCI device 1000:0080 not found at index 0
> (XEN) HVM1: PCI device 1000:0081 not found at index 0
> (XEN) HVM1: PCI device 1000:0082 not found at index 0
> (XEN) HVM1: PCI device 1000:0083 not found at index 0
> (XEN) HVM1: PCI device 1000:0084 not found at index 0
> (XEN) HVM1: PCI device 1000:0085 not found at index 0
> (XEN) HVM1: PCI device 1000:0086 not found at index 0
> (XEN) HVM1: PCI device 1000:0087 not found at index 0
> (XEN) HVM1: PCI device 1000:0070 not found at index 0
> (XEN) HVM1: PCI device 1000:0072 not found at index 2
> (XEN) HVM1: PCI device 1000:0074 not found at index 0
> (XEN) HVM1: PCI device 1000:0076 not found at index 0
> (XEN) HVM1: PCI device 1000:0077 not found at index 0
> (XEN) HVM1: PCI device 1000:0064 not found at index 0
> (XEN) HVM1: PCI device 1000:0065 not found at index 0
> (XEN) HVM1: PCI device 1000:0080 not found at index 0
> (XEN) HVM1: PCI device 1000:0081 not found at index 0
> (XEN) HVM1: PCI device 1000:0082 not found at index 0
> (XEN) HVM1: PCI device 1000:0083 not found at index 0
> (XEN) HVM1: PCI device 1000:0084 not found at index 0
> (XEN) HVM1: PCI device 1000:0085 not found at index 0
> (XEN) HVM1: PCI device 1000:0086 not found at index 0
> (XEN) HVM1: PCI device 1000:0087 not found at index 0
> (XEN) HVM1: 
> (XEN) HVM1: 
> (XEN) HVM1: Press F12 for boot menu.
> (XEN) HVM1: 
> (XEN) HVM1: Booting from Hard Disk...
> (XEN) HVM1: Booting from 0000:7c00
> (XEN) HVM1: *** int 15h function AX=00c0, BX=0000 not yet supported!
> (XEN) HVM1: *** int 15h function AX=ec00, BX=0002 not yet supported!
> (XEN) HVM1: KBD: unsupported int 16h function 03
> (XEN) HVM1: *** int 15h function AX=e980, BX=0000 not yet supported!
> (XEN) irq.c:330: Dom1 callback via changed to Direct Vector 0xe9
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0
> (XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0
> (XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0
> (XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0
> ------------[ cut here ]------------
> WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x22d/0x240()
> Hardware name: SUN FIRE X4370 M2 SERVER       
> remove_proc_entry: removing non-empty directory 'irq/536', leaking at least 'eth7'
> Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]
> Pid: 19329, comm: qemu-dm Not tainted 2.6.39-200.1.15.el5uek #1
> Call Trace:
>  [<ffffffff811d10dd>] ? remove_proc_entry+0x22d/0x240
>  [<ffffffff8106de10>] warn_slowpath_common+0x90/0xc0
>  [<ffffffff8106df3e>] warn_slowpath_fmt+0x6e/0x70
>  [<ffffffff8100a7cf>] ? xen_restore_fl_direct_reloc+0x4/0x4
>  [<ffffffff8125cf98>] ? sprintf+0x68/0x70
>  [<ffffffff811cfef1>] ? __xlate_proc_name+0x41/0xc0
>  [<ffffffff81501b9e>] ? _raw_spin_lock+0xe/0x20
>  [<ffffffff811d10dd>] remove_proc_entry+0x22d/0x240
>  [<ffffffff8113232c>] ? zap_pte_range+0x1ec/0x400
>  [<ffffffff810d9430>] unregister_irq_proc+0xd0/0xf0
>  [<ffffffff810d571a>] free_desc+0x2a/0x70
>  [<ffffffff810d579e>] irq_free_descs+0x3e/0x80
>  [<ffffffff812f7822>] xen_free_irq+0x52/0x70
>  [<ffffffff812f82cb>] unbind_from_irq+0xeb/0x180
>  [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff812f837f>] evtchn_put+0x1f/0x40
>  [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
>  [<ffffffff812640e1>] ? list_del+0x11/0x40
>  [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
>  [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
>  [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
>  [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
>  [<ffffffff8113a740>] ? do_munmap+0x240/0x280
>  [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
>  [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
> ---[ end trace fa61ba514bac93c7 ]---
> BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> IP: [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
> PGD 6a2cb067 PUD 71d8c067 PMD 0 
> Oops: 0000 [#1] SMP 
> CPU 0 
> Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]
> 
> Pid: 19329, comm: qemu-dm Tainted: G        W   2.6.39-200.1.15.el5uek #1 ORACLE CORPORATION SUN FIRE X4370 M2 SERVER       /ASSY,SC_BD,T4         
> RIP: e030:[<ffffffff812f6a76>]  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
> RSP: e02b:ffff88006cfc5dd8  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88007e38be48
> RDX: 0000000000000000 RSI: 0000000000000218 RDI: ffff88007e38bd70
> RBP: ffff88006cfc5dd8 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000218
> R13: 0000000000000000 R14: 0000000000000017 R15: 0000000000104701
> FS:  00007ff36f4046e0(0000) GS:ffff88007f49a000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000000001c CR3: 000000005f445000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process qemu-dm (pid: 19329, threadinfo ffff88006cfc4000, task ffff880067084200)
> Stack:
>  ffff88006cfc5e38 ffffffff812f81fc 00007ff36e620000 0000003e38e10000
>  ffff88006cfc5e38 000000000000014f 0000000000000206 ffff88006b2e8138
>  ffffffff81009f0d ffff88006b951cc0 ffff88006b951cc0 0000000000000000
> Call Trace:
>  [<ffffffff812f81fc>] unbind_from_irq+0x1c/0x180
>  [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff812f837f>] evtchn_put+0x1f/0x40
>  [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
>  [<ffffffff812640e1>] ? list_del+0x11/0x40
>  [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
>  [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
>  [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
>  [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
>  [<ffffffff8113a740>] ? do_munmap+0x240/0x280
>  [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
>  [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
> Code: 8b 64 24 08 c9 c3 0f 1f 80 00 00 00 00 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 39 3d f1 16 4c 00 76 0b e8 ea fa ff ff <0f> b7 40 1c c9 c3 89 f9 31 c0 48 c7 c2 2f 72 70 81 be d1 00 00 
> RIP  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
>  RSP <ffff88006cfc5dd8>
> CR2: 000000000000001c
> 
> Thanks,
> Joe
> On 02/05/13 17:42, Ian Campbell wrote:
>> On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
>>> execute xl-destroy twice crashed my server!
>>
>> Can you give more details please.
>>
>> Ian.
>>
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 05:08:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 05:08: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 1U6wTN-0005Hh-Uj; Sun, 17 Feb 2013 05:07:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe.jin@oracle.com>) id 1U6wTM-0005Hc-5n
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 05:07:32 +0000
Received: from [85.158.139.211:46470] by server-2.bemta-5.messagelabs.com id
	49/03-16911-39560215; Sun, 17 Feb 2013 05:07:31 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361077648!20014443!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMzk5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31234 invoked from network); 17 Feb 2013 05:07:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Feb 2013 05:07:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1H57PZh012106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 17 Feb 2013 05:07:26 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
	r1H57O2Y008832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 17 Feb 2013 05:07:24 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
	r1H57OmY011200; Sat, 16 Feb 2013 23:07:24 -0600
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 16 Feb 2013 21:07:23 -0800
Message-ID: <51206584.8060200@oracle.com>
Date: Sun, 17 Feb 2013 13:07:16 +0800
From: Joe Jin <joe.jin@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Joe Jin <joe.jin@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
	<512056D5.6080507@oracle.com>
In-Reply-To: <512056D5.6080507@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Roger Pau Monne <roger.pau@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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

Execute "xl-destroy" twice lead the dom0 panic:
config file as below:

vncunused = 1
kernel = '/usr/lib/xen/boot/hvmloader'
vnc = 1
name = 'test'
memory = '16384'
#memory = '1024'
timer_mode = 0
device_model = '/usr/lib64/xen/bin/qemu-dm'
builder = 'hvm'
vnclisten = '0.0.0.0'
cpus = '0,2,4,6,8,11,1,3,5,7,9,10'
#on_crash = 'coredump-restart'
#on_crash = 'preserve'
on_crash = 'destroy'
on_reboot = 'restart'
vcpus = 12
pci = ['0d:00.0', '1f:00.0']
#pci = ['0d:00.0']
pae = 1
apic = 1
vif = ['type=netfront,bridge=priv1', 'type=netfront,bridge=net1', 'type=netfront,bridge=net2', 'type=netfront,bridge=net3', 'type=netfront,bridge=net4']
serial = 'pty'
disk = ['file:/path/System.img,xvda,w', 'file:/path/u01.img,xvdb,w', 'file:/path/swap.img,xvdc,w']
acpi = 1

Crash info from serial console:

(XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3180 mfn=df03c nr_mfns=4
(XEN) p2m.c:2797:d0 clear_mmio_p2m_entry: gfn_to_mfn failed! gfn=000f3182
(XEN) domctl.c:995:d0 memory_map:remove: gfn=f3100 mfn=df040 nr_mfns=40
------------[ cut here ]------------
kernel BUG at drivers/pci/access.c:423!
invalid opcode: 0000 [#1] SMP 
CPU 18 
Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport igb ses enclosure ixgbe mdio e1000e snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore i2c_i801 snd_page_alloc ghes iTCO_wdt i2c_core pcspkr iTCO_vendor_support i7core_edac ioatdma edac_core hed dca dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]

Pid: 20399, comm: xl Not tainted 2.6.39-200.1.15.el5uek #1 ORACLE CORPORATION SUN FIRE X4370 M2 SERVER       /ASSY,SC_BD,T4         
RIP: e030:[<ffffffff812704bf>]  [<ffffffff812704bf>] pci_block_user_cfg_access+0x4f/0x60
RSP: e02b:ffff88006e609dd8  EFLAGS: 00010202
RAX: 0000000000000024 RBX: 0000000000000001 RCX: 00000000800d0004
RDX: 0000000000000400 RSI: 0000000000000200 RDI: 0000000000000200
RBP: ffff88006e609de8 R08: 0000000000000002 R09: 0000000000000400
R10: 0000000000000000 R11: 0000000000000202 R12: ffff8800731e4000
R13: ffff8800731e4000 R14: ffffffff81565e20 R15: ffff8800731e40a0
FS:  00007fb7b5dfa730(0000) GS:ffff88007f66e000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003340613000 CR3: 0000000068440000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process xl (pid: 20399, threadinfo ffff88006e608000, task ffff880071fe0500)
Stack:
 0000000000000000 0000000000000000 ffff88006e609e18 ffffffff812749dc
 ffff8800731e4000 0000000000000000 ffff8800731e4000 00000000ffffffed
 ffff88006e609e38 ffffffff812764c4 ffff8800731e4090 0000000000000001
Call Trace:
 [<ffffffff812749dc>] pci_dev_reset+0x6c/0xd0
 [<ffffffff812764c4>] pci_reset_function+0x54/0x70
 [<ffffffff8127a6ba>] reset_store+0x5a/0x70
 [<ffffffff81342070>] dev_attr_store+0x20/0x30
 [<ffffffff811db48f>] flush_write_buffer+0x5f/0x90
 [<ffffffff811db856>] sysfs_write_file+0x66/0xa0
 [<ffffffff8116dd8e>] vfs_write+0xce/0x190
 [<ffffffff8116e3e5>] sys_write+0x55/0x90
 [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
Code: 07 00 00 48 c7 c7 e0 73 d7 81 89 c3 83 c8 20 c0 eb 05 41 88 84 24 80 07 00 00 83 e3 01 e8 6a 17 29 00 85 db 75 05 5b 41 5c c9 c3 <0f> 0b eb fe 66 0f 1f 44 00 00 0f 1f 80 00 00 00 00 55 48 89 e5 
RIP  [<ffffffff812704bf>] pci_block_user_cfg_access+0x4f/0x60
 RSP <ffff88006e609dd8>
pciback 0000:0d:


BTW: xm-create work fine but xl-create trigger the panic as below:

On 02/17/13 12:04, Joe Jin wrote:
> I got serial console output now and mostly like panic happened by "xl create":
> 
> (XEN) HVM1: Detected Xen v4.1.2-OVM
> (XEN) HVM1: CPU speed is 2926 MHz
> (XEN) HVM1: Xenbus rings @0xfeffc000, event channel 13
> (XEN) irq.c:264: Dom1 PCI link 0 changed 0 -> 5
> (XEN) HVM1: PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:264: Dom1 PCI link 1 changed 0 -> 10
> (XEN) HVM1: PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:264: Dom1 PCI link 2 changed 0 -> 11
> (XEN) HVM1: PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:264: Dom1 PCI link 3 changed 0 -> 5
> (XEN) HVM1: PCI-ISA link 3 routed to IRQ5
> (XEN) HVM1: pci dev 01:3 INTA->IRQ10
> (XEN) HVM1: pci dev 03:0 INTA->IRQ5
> (XEN) HVM1: pci dev 04:0 INTA->IRQ5
> (XEN) HVM1: pci dev 05:0 INTA->IRQ10
> (XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008
> (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008
> (XEN) HVM1: pci dev 04:0 bar 30 size 00080000: f3000000
> (XEN) HVM1: pci dev 05:0 bar 30 size 00080000: f3080000
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40
> (XEN) HVM1: pci dev 04:0 bar 1c size 00040000: f3100004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40
> (XEN) HVM1: pci dev 05:0 bar 1c size 00040000: f3140004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3182 mfn=df03e nr_mfns=1
> (XEN) HVM1: pci dev 04:0 bar 14 size 00004000: f3180004
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3184 mfn=df63c nr_mfns=4
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3186 mfn=df63e nr_mfns=1
> (XEN) HVM1: pci dev 05:0 bar 14 size 00004000: f3184004
> (XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3188000
> (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c001
> (XEN) HVM1: pci dev 04:0 bar 10 size 00000100: 0000c101
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) HVM1: pci dev 05:0 bar 10 size 00000100: 0000c201
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c301
> (XEN) HVM1: Multiprocessor initialisation:
> (XEN) HVM1:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU4 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU5 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU6 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU7 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU8 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU9 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU10 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1:  - CPU11 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (XEN) HVM1: Writing SMBIOS tables ...
> (XEN) HVM1: Loading ROMBIOS ...
> (XEN) HVM1: 10364 bytes of ROMBIOS high-memory extensions:
> (XEN) HVM1:   Relocating to 0xfc000000-0xfc00287c ... done
> (XEN) HVM1: Creating MP tables ...
> (XEN) HVM1: Loading Cirrus VGABIOS ...
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3000 mfn=df080 nr_mfns=80
> (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=df080 nr_mfns=80
> (XEN) domctl.c:985:d0 memory_map:add: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3080 mfn=df680 nr_mfns=80
> (XEN) HVM1: Loading ACPI ...
> (XEN) HVM1:  - Lo data: 000ea020-000ea04f
> (XEN) HVM1:  - Hi data: fc002c00-fc00eb4f
> (XEN) HVM1: vm86 TSS at fc00ec00
> (XEN) HVM1: BIOS map:
> (XEN) HVM1:  c0000-c8fff: VGA BIOS
> (XEN) HVM1:  c9000-d4fff: PCI Option ROMs
> (XEN) HVM1:  eb000-eb302: SMBIOS tables
> (XEN) HVM1:  f0000-fffff: Main BIOS
> (XEN) HVM1: E820 table:
> (XEN) HVM1:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM1:  [01]: 00000000:0009e000 - 00000000:0009fc00: RESERVED
> (XEN) HVM1:  [02]: 00000000:0009fc00 - 00000000:000a0000: RESERVED
> (XEN) HVM1:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM1:  [03]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM1:  [04]: 00000000:00100000 - 00000000:f0000000: RAM
> (XEN) HVM1:  HOLE: 00000000:f0000000 - 00000000:fc000000
> (XEN) HVM1:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (XEN) HVM1:  [06]: 00000001:00000000 - 00000004:0f800000: RAM
> (XEN) HVM1: Invoking ROMBIOS ...
> (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) stdvga.c:147:d1 entering stdvga and caching modes
> (XEN) HVM1: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> (XEN) HVM1: Bochs BIOS - build: 06/23/99
> (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) HVM1: Options: apmbios pcibios eltorito PMM 
> (XEN) HVM1: 
> (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (60000 MBytes)
> (XEN) HVM1: ata0-1: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM1: ata0  slave: QEMU HARDDISK ATA-7 Hard-Disk (  97 GBytes)
> (XEN) HVM1: ata1-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> (XEN) HVM1: ata1 master: QEMU HARDDISK ATA-7 Hard-Disk (20000 MBytes)
> (XEN) HVM1: IDE time out
> (XEN) HVM1: 
> (XEN) HVM1: PCI device 1000:0070 not found at index 0
> (XEN) HVM1: PCI device 1000:0072 not found at index 2
> (XEN) HVM1: PCI device 1000:0074 not found at index 0
> (XEN) HVM1: PCI device 1000:0076 not found at index 0
> (XEN) HVM1: PCI device 1000:0077 not found at index 0
> (XEN) HVM1: PCI device 1000:0064 not found at index 0
> (XEN) HVM1: PCI device 1000:0065 not found at index 0
> (XEN) HVM1: PCI device 1000:0080 not found at index 0
> (XEN) HVM1: PCI device 1000:0081 not found at index 0
> (XEN) HVM1: PCI device 1000:0082 not found at index 0
> (XEN) HVM1: PCI device 1000:0083 not found at index 0
> (XEN) HVM1: PCI device 1000:0084 not found at index 0
> (XEN) HVM1: PCI device 1000:0085 not found at index 0
> (XEN) HVM1: PCI device 1000:0086 not found at index 0
> (XEN) HVM1: PCI device 1000:0087 not found at index 0
> (XEN) HVM1: PCI device 1000:0070 not found at index 0
> (XEN) HVM1: PCI device 1000:0072 not found at index 2
> (XEN) HVM1: PCI device 1000:0074 not found at index 0
> (XEN) HVM1: PCI device 1000:0076 not found at index 0
> (XEN) HVM1: PCI device 1000:0077 not found at index 0
> (XEN) HVM1: PCI device 1000:0064 not found at index 0
> (XEN) HVM1: PCI device 1000:0065 not found at index 0
> (XEN) HVM1: PCI device 1000:0080 not found at index 0
> (XEN) HVM1: PCI device 1000:0081 not found at index 0
> (XEN) HVM1: PCI device 1000:0082 not found at index 0
> (XEN) HVM1: PCI device 1000:0083 not found at index 0
> (XEN) HVM1: PCI device 1000:0084 not found at index 0
> (XEN) HVM1: PCI device 1000:0085 not found at index 0
> (XEN) HVM1: PCI device 1000:0086 not found at index 0
> (XEN) HVM1: PCI device 1000:0087 not found at index 0
> (XEN) HVM1: 
> (XEN) HVM1: 
> (XEN) HVM1: Press F12 for boot menu.
> (XEN) HVM1: 
> (XEN) HVM1: Booting from Hard Disk...
> (XEN) HVM1: Booting from 0000:7c00
> (XEN) HVM1: *** int 15h function AX=00c0, BX=0000 not yet supported!
> (XEN) HVM1: *** int 15h function AX=ec00, BX=0002 not yet supported!
> (XEN) HVM1: KBD: unsupported int 16h function 03
> (XEN) HVM1: *** int 15h function AX=e980, BX=0000 not yet supported!
> (XEN) irq.c:330: Dom1 callback via changed to Direct Vector 0xe9
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c100 f_mport=9000 np=100
> (XEN) domctl.c:1065:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=100
> (XEN) domctl.c:1041:d0 ioport_map:add f_gport=c200 f_mport=d000 np=100
> (XEN) irq.c:264: Dom1 PCI link 0 changed 5 -> 0
> (XEN) irq.c:264: Dom1 PCI link 1 changed 10 -> 0
> (XEN) irq.c:264: Dom1 PCI link 2 changed 11 -> 0
> (XEN) irq.c:264: Dom1 PCI link 3 changed 5 -> 0
> ------------[ cut here ]------------
> WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x22d/0x240()
> Hardware name: SUN FIRE X4370 M2 SERVER       
> remove_proc_entry: removing non-empty directory 'irq/536', leaking at least 'eth7'
> Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]
> Pid: 19329, comm: qemu-dm Not tainted 2.6.39-200.1.15.el5uek #1
> Call Trace:
>  [<ffffffff811d10dd>] ? remove_proc_entry+0x22d/0x240
>  [<ffffffff8106de10>] warn_slowpath_common+0x90/0xc0
>  [<ffffffff8106df3e>] warn_slowpath_fmt+0x6e/0x70
>  [<ffffffff8100a7cf>] ? xen_restore_fl_direct_reloc+0x4/0x4
>  [<ffffffff8125cf98>] ? sprintf+0x68/0x70
>  [<ffffffff811cfef1>] ? __xlate_proc_name+0x41/0xc0
>  [<ffffffff81501b9e>] ? _raw_spin_lock+0xe/0x20
>  [<ffffffff811d10dd>] remove_proc_entry+0x22d/0x240
>  [<ffffffff8113232c>] ? zap_pte_range+0x1ec/0x400
>  [<ffffffff810d9430>] unregister_irq_proc+0xd0/0xf0
>  [<ffffffff810d571a>] free_desc+0x2a/0x70
>  [<ffffffff810d579e>] irq_free_descs+0x3e/0x80
>  [<ffffffff812f7822>] xen_free_irq+0x52/0x70
>  [<ffffffff812f82cb>] unbind_from_irq+0xeb/0x180
>  [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff812f837f>] evtchn_put+0x1f/0x40
>  [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
>  [<ffffffff812640e1>] ? list_del+0x11/0x40
>  [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
>  [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
>  [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
>  [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
>  [<ffffffff8113a740>] ? do_munmap+0x240/0x280
>  [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
>  [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
> ---[ end trace fa61ba514bac93c7 ]---
> BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> IP: [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
> PGD 6a2cb067 PUD 71d8c067 PMD 0 
> Oops: 0000 [#1] SMP 
> CPU 0 
> Modules linked in: xt_physdev iptable_filter ip_tables xen_blkback xen_netback xen_pciback xen_gntdev xen_evtchn ipmi_devintf ipmi_si lockd sunrpc bridge stp llc bonding dm_round_robin dm_multipath be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi xenfs xen_privcmd dm_mirror video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler parport_pc lp parport ses enclosure ixgbe igb e1000e mdio snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core i7core_edac iTCO_wdt pcspkr ioatdma iTCO_vendor_support edac_core dca ghes hed dm_region_hash dm_log dm_mod usb_storage shpchp sg ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache [last unloaded: raid_class]
> 
> Pid: 19329, comm: qemu-dm Tainted: G        W   2.6.39-200.1.15.el5uek #1 ORACLE CORPORATION SUN FIRE X4370 M2 SERVER       /ASSY,SC_BD,T4         
> RIP: e030:[<ffffffff812f6a76>]  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
> RSP: e02b:ffff88006cfc5dd8  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88007e38be48
> RDX: 0000000000000000 RSI: 0000000000000218 RDI: ffff88007e38bd70
> RBP: ffff88006cfc5dd8 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000218
> R13: 0000000000000000 R14: 0000000000000017 R15: 0000000000104701
> FS:  00007ff36f4046e0(0000) GS:ffff88007f49a000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000000001c CR3: 000000005f445000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process qemu-dm (pid: 19329, threadinfo ffff88006cfc4000, task ffff880067084200)
> Stack:
>  ffff88006cfc5e38 ffffffff812f81fc 00007ff36e620000 0000003e38e10000
>  ffff88006cfc5e38 000000000000014f 0000000000000206 ffff88006b2e8138
>  ffffffff81009f0d ffff88006b951cc0 ffff88006b951cc0 0000000000000000
> Call Trace:
>  [<ffffffff812f81fc>] unbind_from_irq+0x1c/0x180
>  [<ffffffff81009f0d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff812f837f>] evtchn_put+0x1f/0x40
>  [<ffffffffa055b4e9>] gntdev_put_map+0x39/0x110 [xen_gntdev]
>  [<ffffffff812640e1>] ? list_del+0x11/0x40
>  [<ffffffffa055c38c>] gntdev_ioctl_unmap_grant_ref+0xac/0xd0 [xen_gntdev]
>  [<ffffffffa055c708>] gntdev_ioctl+0x98/0xa0 [xen_gntdev]
>  [<ffffffff8117eb8d>] vfs_ioctl+0x1d/0x50
>  [<ffffffff8117f623>] do_vfs_ioctl+0x63/0x1b0
>  [<ffffffff8113a740>] ? do_munmap+0x240/0x280
>  [<ffffffff8117f804>] sys_ioctl+0x94/0xa0
>  [<ffffffff8150a242>] system_call_fastpath+0x16/0x1b
> Code: 8b 64 24 08 c9 c3 0f 1f 80 00 00 00 00 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 39 3d f1 16 4c 00 76 0b e8 ea fa ff ff <0f> b7 40 1c c9 c3 89 f9 31 c0 48 c7 c2 2f 72 70 81 be d1 00 00 
> RIP  [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40
>  RSP <ffff88006cfc5dd8>
> CR2: 000000000000001c
> 
> Thanks,
> Joe
> On 02/05/13 17:42, Ian Campbell wrote:
>> On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
>>> execute xl-destroy twice crashed my server!
>>
>> Can you give more details please.
>>
>> Ian.
>>
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 07:27:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07: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 1U6ye6-00088G-TD; Sun, 17 Feb 2013 07:26:46 +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 1U6ye5-00088B-CF
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:26:45 +0000
Received: from [193.109.254.147:34437] by server-8.bemta-14.messagelabs.com id
	7A/B9-17325-43680215; Sun, 17 Feb 2013 07:26:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361086002!8550422!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ5MzA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21801 invoked from network); 17 Feb 2013 07:26:43 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Feb 2013 07:26:43 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Feb 2013 23:25:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; d="scan'208";a="263683337"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:25:24 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:25:24 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:25:23 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:25:22 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Thread-Topic: xen/acpi: ACPI memory hotplug
Thread-Index: AQHOC4c6FTtXskWumkKddzUxlPCoxJh9qKmA
Date: Sun, 17 Feb 2013 07:25:21 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCC82@SHSMSX101.ccr.corp.intel.com>
References: <20130215141728.GA27966@elgon.mountain>
In-Reply-To: <20130215141728.GA27966@elgon.mountain>
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: "kbuild@01.org" <kbuild@01.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] xen/acpi: ACPI memory hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Carpenter wrote:
> Hello Liu Jinsong,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch 259f201cb7ea: "xen/acpi: ACPI memory hotplug" from Jan 24,
> 2013, leads to the following Smatch complaint:
> 
> drivers/xen/xen-acpi-memhotplug.c:198 acpi_memory_get_device()
> 	 error: we previously assumed 'device' could be null (see line 171)
> 
> drivers/xen/xen-acpi-memhotplug.c
>    170
>    171		if (!acpi_bus_get_device(handle, &device) && device)
>                                                              ^^^^^^
> New check.
> 
> Btw, checking device is unnecessary.
> 
> 		if (acpi_bus_get_device(handle, &device) == 0)
> 			goto end;
> 
> A successful "Get Device" means that "device" is non-NULL; that's
> built into the name.  Anyway, if acpi_bus_get_device() fails either
> something else will fail or we will Oops in the call to
> acpi_driver_data(). 
> 
>    172			goto end;
>    173
>    174		status = acpi_get_parent(handle, &phandle);
>    175		if (ACPI_FAILURE(status)) {
>    176			pr_warn(PREFIX "Cannot find acpi parent\n");
>    177			return -EINVAL;
>    178		}
>    179
>    180		/* Get the parent device */
>    181		result = acpi_bus_get_device(phandle, &pdevice);
>    182		if (result) {
>    183			pr_warn(PREFIX "Cannot get acpi bus device\n");
>    184			return -EINVAL;
>    185		}
>    186
>    187		/*
>    188		 * Now add the notified device.  This creates the acpi_device
>    189		 * and invokes .add function
>    190		 */
>    191		result = acpi_bus_scan(handle);
>    192		if (result) {
>    193			pr_warn(PREFIX "Cannot add acpi bus\n");
>    194			return -EINVAL;
>    195		}
>    196
>    197	end:
>    198		*mem_device = acpi_driver_data(device);
>                                                ^^^^^^
> Dereference.
> 
>    199		if (!(*mem_device)) {
>    200			pr_err(PREFIX "Driver data not found\n");
> 
> regards,
> dan carpenter

Thanks Dan, updated, will send out minutes later.

Regards,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 07:27:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07: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 1U6ye6-00088G-TD; Sun, 17 Feb 2013 07:26:46 +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 1U6ye5-00088B-CF
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:26:45 +0000
Received: from [193.109.254.147:34437] by server-8.bemta-14.messagelabs.com id
	7A/B9-17325-43680215; Sun, 17 Feb 2013 07:26:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361086002!8550422!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ5MzA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21801 invoked from network); 17 Feb 2013 07:26:43 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Feb 2013 07:26:43 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Feb 2013 23:25:28 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; d="scan'208";a="263683337"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:25:24 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:25:24 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:25:23 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:25:22 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Thread-Topic: xen/acpi: ACPI memory hotplug
Thread-Index: AQHOC4c6FTtXskWumkKddzUxlPCoxJh9qKmA
Date: Sun, 17 Feb 2013 07:25:21 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCC82@SHSMSX101.ccr.corp.intel.com>
References: <20130215141728.GA27966@elgon.mountain>
In-Reply-To: <20130215141728.GA27966@elgon.mountain>
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: "kbuild@01.org" <kbuild@01.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] xen/acpi: ACPI memory hotplug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Carpenter wrote:
> Hello Liu Jinsong,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch 259f201cb7ea: "xen/acpi: ACPI memory hotplug" from Jan 24,
> 2013, leads to the following Smatch complaint:
> 
> drivers/xen/xen-acpi-memhotplug.c:198 acpi_memory_get_device()
> 	 error: we previously assumed 'device' could be null (see line 171)
> 
> drivers/xen/xen-acpi-memhotplug.c
>    170
>    171		if (!acpi_bus_get_device(handle, &device) && device)
>                                                              ^^^^^^
> New check.
> 
> Btw, checking device is unnecessary.
> 
> 		if (acpi_bus_get_device(handle, &device) == 0)
> 			goto end;
> 
> A successful "Get Device" means that "device" is non-NULL; that's
> built into the name.  Anyway, if acpi_bus_get_device() fails either
> something else will fail or we will Oops in the call to
> acpi_driver_data(). 
> 
>    172			goto end;
>    173
>    174		status = acpi_get_parent(handle, &phandle);
>    175		if (ACPI_FAILURE(status)) {
>    176			pr_warn(PREFIX "Cannot find acpi parent\n");
>    177			return -EINVAL;
>    178		}
>    179
>    180		/* Get the parent device */
>    181		result = acpi_bus_get_device(phandle, &pdevice);
>    182		if (result) {
>    183			pr_warn(PREFIX "Cannot get acpi bus device\n");
>    184			return -EINVAL;
>    185		}
>    186
>    187		/*
>    188		 * Now add the notified device.  This creates the acpi_device
>    189		 * and invokes .add function
>    190		 */
>    191		result = acpi_bus_scan(handle);
>    192		if (result) {
>    193			pr_warn(PREFIX "Cannot add acpi bus\n");
>    194			return -EINVAL;
>    195		}
>    196
>    197	end:
>    198		*mem_device = acpi_driver_data(device);
>                                                ^^^^^^
> Dereference.
> 
>    199		if (!(*mem_device)) {
>    200			pr_err(PREFIX "Driver data not found\n");
> 
> regards,
> dan carpenter

Thanks Dan, updated, will send out minutes later.

Regards,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 07:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07:32: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 1U6yj4-0008Mq-Lk; Sun, 17 Feb 2013 07:31:54 +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 1U6yj3-0008Ml-LF
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:31:53 +0000
Received: from [85.158.138.51:63968] by server-10.bemta-3.messagelabs.com id
	15/3D-10609-66780215; Sun, 17 Feb 2013 07:31:50 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361086307!27878749!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg1ODU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22409 invoked from network); 17 Feb 2013 07:31:50 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-174.messagelabs.com with SMTP;
	17 Feb 2013 07:31:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 16 Feb 2013 23:30:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; d="scan'208";a="263684463"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:31:40 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:31:39 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:31:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>, Stephen Rothwell
	<sfr@canb.auug.org.au>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHODIHETyBHFMmDoE2LH83uWllZQ5h9p5rA
Date: Sun, 17 Feb 2013 07:31:37 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<2185970.g9YrD945My@vostro.rjw.lan>
	<20130216015200.1e58bec1aff05592ac2ae98f@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
In-Reply-To: <11850955.SHqxVBsJqI@vostro.rjw.lan>
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-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rafael J. Wysocki wrote:
> On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
>> Hi Rafael,
> 
> Hi,
> 
>> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
>> wrote: 
>>> 
>>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
>>>> 
>>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
>>>> <konrad.wilk@oracle.com> wrote: 
>>>>> 
>>>>> Thank you. I keep on forgetting - but would it be OK for me to
>>>>> take this patch in my tree? Or should I not since this is a new
>>>>> functionality that Rafael is going to introduce in v3.9?
>>>> 
>>>> It is an API change in the pm tree that is not yet in Linus' tree.
>>>> 
>>>>> And if so, perhaps I should tack it on in my tree, once Rafael
>>>>> does a git pull to Linus? Or just point Linus to this git commit?
>>>> 
>>>> You should point Linus at this patch if the pm tree is merged
>>>> first, or 
>>>> Rafael should do the same if the reverse happens.
>>> 
>>> Alternatively, Konrad can pull the acpi-scan branch containing the
>>> changes in question from my tree into his tree and rebase the new
>>> material on top of that.
>> 
>> Or pull the acpi-scan branch into his tree and use my conflict
>> resolution in the resulting merge thus requiring no rebasing. 
>> However, Linus likes to see such interactions, so it can be left up
>> to when the latter of the two tress is merged by Linus.
> 
> Well, I'm afraid this won't be sufficient this time, because of this
> commit in my tree (which is not on the acpi-scan branch):
> 
> commit 3757b94802fb65d8f696597a74053cf21738da0b
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Wed Feb 13 14:36:47 2013 +0100
> 
>     ACPI / hotplug: Fix concurrency issues and memory leaks
> 
> after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> acpi_scan_lock (new in my tree as well).

Yes, we noticed that and only need minor updates at xen side, will send out 2 xen patches later accordingly, for cleanup and adding lock.

Thanks,
Jinsong

> 
> Moreover, I think that the introduction of ACPI-based CPU hotplug
> into Xen and this point would be premature, because we need to rework
> the original ACPI-based CPU hotplug and quite frankly it shouldn't
> call acpi_bus_scan() directly at all.
> 
> Konrad?
> 
> Thanks,
> Rafael


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 07:32:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07:32: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 1U6yj4-0008Mq-Lk; Sun, 17 Feb 2013 07:31:54 +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 1U6yj3-0008Ml-LF
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:31:53 +0000
Received: from [85.158.138.51:63968] by server-10.bemta-3.messagelabs.com id
	15/3D-10609-66780215; Sun, 17 Feb 2013 07:31:50 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361086307!27878749!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg1ODU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22409 invoked from network); 17 Feb 2013 07:31:50 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-174.messagelabs.com with SMTP;
	17 Feb 2013 07:31:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 16 Feb 2013 23:30:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; d="scan'208";a="263684463"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:31:40 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:31:39 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:31:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>, Stephen Rothwell
	<sfr@canb.auug.org.au>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHODIHETyBHFMmDoE2LH83uWllZQ5h9p5rA
Date: Sun, 17 Feb 2013 07:31:37 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<2185970.g9YrD945My@vostro.rjw.lan>
	<20130216015200.1e58bec1aff05592ac2ae98f@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
In-Reply-To: <11850955.SHqxVBsJqI@vostro.rjw.lan>
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-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Rafael J. Wysocki wrote:
> On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
>> Hi Rafael,
> 
> Hi,
> 
>> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
>> wrote: 
>>> 
>>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
>>>> 
>>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
>>>> <konrad.wilk@oracle.com> wrote: 
>>>>> 
>>>>> Thank you. I keep on forgetting - but would it be OK for me to
>>>>> take this patch in my tree? Or should I not since this is a new
>>>>> functionality that Rafael is going to introduce in v3.9?
>>>> 
>>>> It is an API change in the pm tree that is not yet in Linus' tree.
>>>> 
>>>>> And if so, perhaps I should tack it on in my tree, once Rafael
>>>>> does a git pull to Linus? Or just point Linus to this git commit?
>>>> 
>>>> You should point Linus at this patch if the pm tree is merged
>>>> first, or 
>>>> Rafael should do the same if the reverse happens.
>>> 
>>> Alternatively, Konrad can pull the acpi-scan branch containing the
>>> changes in question from my tree into his tree and rebase the new
>>> material on top of that.
>> 
>> Or pull the acpi-scan branch into his tree and use my conflict
>> resolution in the resulting merge thus requiring no rebasing. 
>> However, Linus likes to see such interactions, so it can be left up
>> to when the latter of the two tress is merged by Linus.
> 
> Well, I'm afraid this won't be sufficient this time, because of this
> commit in my tree (which is not on the acpi-scan branch):
> 
> commit 3757b94802fb65d8f696597a74053cf21738da0b
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Wed Feb 13 14:36:47 2013 +0100
> 
>     ACPI / hotplug: Fix concurrency issues and memory leaks
> 
> after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> acpi_scan_lock (new in my tree as well).

Yes, we noticed that and only need minor updates at xen side, will send out 2 xen patches later accordingly, for cleanup and adding lock.

Thanks,
Jinsong

> 
> Moreover, I think that the introduction of ACPI-based CPU hotplug
> into Xen and this point would be premature, because we need to rework
> the original ACPI-based CPU hotplug and quite frankly it shouldn't
> call acpi_bus_scan() directly at all.
> 
> Konrad?
> 
> Thanks,
> Rafael


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 07:38:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07: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 1U6yoh-00006T-L3; Sun, 17 Feb 2013 07:37:43 +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 1U6yof-00006O-MZ
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:37:42 +0000
Received: from [85.158.137.99:36124] by server-4.bemta-3.messagelabs.com id
	E0/A2-17521-4C880215; Sun, 17 Feb 2013 07:37:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361086658!19455277!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ5MzA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2154 invoked from network); 17 Feb 2013 07:37:39 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-217.messagelabs.com with SMTP;
	17 Feb 2013 07:37:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Feb 2013 23:37:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; 
	d="scan'208,223";a="263685221"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:37:37 -0800
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:37:37 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:37:36 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:37:35 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Wysocki, Rafael J"
	<rafael.j.wysocki@intel.com>, Stephen Rothwell <sfr@canb.auug.org.au>
Thread-Topic: [PATCH 1/2] xen/acpi: xen memory hotplug minor updates
Thread-Index: Ac4M4abEDm8BJ5/PS2+i93UswO8RQQ==
Date: Sun, 17 Feb 2013 07:37:34 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCCC8@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_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] xen/acpi: xen memory hotplug minor updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From aa363f1a4f862fab2f50dfe3ad602bb8dd234709 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sat, 16 Feb 2013 16:59:03 +0800
Subject: [PATCH 1/2] xen/acpi: xen memory hotplug minor updates

Dan Carpenter found current xen memory hotplug logic
has potential issue: at func acpi_memory_get_device()
*mem_device =3D acpi_driver_data(device);
while the device may be NULL and then dereference.

At native side, Rafael recently updated acpi_memory_get_device(),
dropping acpi_bus_add, adding lock, and avoiding above issue.

This patch updates xen memory hotplug logic accordingly, removing
redundant logic, adding lock, and avoiding dereference.

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen-acpi-memhotplug.c |   52 ++++++++++++++++++---------------=
---
 1 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memho=
tplug.c
index 853b12d..faef5b3 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -158,31 +158,17 @@ acpi_memory_get_device_resources(struct acpi_memory_d=
evice *mem_device)
 	return 0;
 }
=20
-static int
-acpi_memory_get_device(acpi_handle handle,
-		       struct acpi_memory_device **mem_device)
+static int acpi_memory_get_device(acpi_handle handle,
+				  struct acpi_memory_device **mem_device)
 {
-	acpi_status status;
-	acpi_handle phandle;
 	struct acpi_device *device =3D NULL;
-	struct acpi_device *pdevice =3D NULL;
-	int result;
+	int result =3D 0;
=20
-	if (!acpi_bus_get_device(handle, &device) && device)
-		goto end;
+	acpi_scan_lock_acquire();
=20
-	status =3D acpi_get_parent(handle, &phandle);
-	if (ACPI_FAILURE(status)) {
-		pr_warn(PREFIX "Cannot find acpi parent\n");
-		return -EINVAL;
-	}
-
-	/* Get the parent device */
-	result =3D acpi_bus_get_device(phandle, &pdevice);
-	if (result) {
-		pr_warn(PREFIX "Cannot get acpi bus device\n");
-		return -EINVAL;
-	}
+	acpi_bus_get_device(handle, &device);
+	if (device)
+		goto end;
=20
 	/*
 	 * Now add the notified device.  This creates the acpi_device
@@ -190,18 +176,28 @@ acpi_memory_get_device(acpi_handle handle,
 	 */
 	result =3D acpi_bus_scan(handle);
 	if (result) {
-		pr_warn(PREFIX "Cannot add acpi bus\n");
-		return -EINVAL;
+		pr_warn(PREFIX "ACPI namespace scan failed\n");
+		result =3D -EINVAL;
+		goto out;
+	}
+	result =3D acpi_bus_get_device(handle, &device);
+	if (result) {
+		pr_warn(PREFIX "Missing device object\n");
+		result =3D -EINVAL;
+		goto out;
 	}
=20
 end:
 	*mem_device =3D acpi_driver_data(device);
 	if (!(*mem_device)) {
-		pr_err(PREFIX "Driver data not found\n");
-		return -ENODEV;
+		pr_err(PREFIX "driver data not found\n");
+		result =3D -ENODEV;
+		goto out;
 	}
=20
-	return 0;
+out:
+	acpi_scan_lock_release();
+	return result;
 }
=20
 static int acpi_memory_check_device(struct acpi_memory_device *mem_device)
@@ -259,12 +255,15 @@ static void acpi_memory_device_notify(acpi_handle han=
dle, u32 event, void *data)
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 			"\nReceived EJECT REQUEST notification for device\n"));
=20
+		acpi_scan_lock_acquire();
 		if (acpi_bus_get_device(handle, &device)) {
+			acpi_scan_lock_release();
 			pr_err(PREFIX "Device doesn't exist\n");
 			break;
 		}
 		mem_device =3D acpi_driver_data(device);
 		if (!mem_device) {
+			acpi_scan_lock_release();
 			pr_err(PREFIX "Driver Data is NULL\n");
 			break;
 		}
@@ -274,6 +273,7 @@ static void acpi_memory_device_notify(acpi_handle handl=
e, u32 event, void *data)
 		 * acpi_bus_remove if Xen support hotremove in the future
 		 */
 		acpi_memory_disable_device(mem_device);
+		acpi_scan_lock_release();
 		break;
=20
 	default:
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-acpi-xen-memory-hotplug-minor-updates.patch"
Content-Description: 0001-xen-acpi-xen-memory-hotplug-minor-updates.patch
Content-Disposition: attachment;
	filename="0001-xen-acpi-xen-memory-hotplug-minor-updates.patch"; size=3664;
	creation-date="Sun, 17 Feb 2013 07:24:14 GMT";
	modification-date="Sun, 17 Feb 2013 15:14:12 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhYTM2M2YxYTRmODYyZmFiMmY1MGRmZTNhZDYwMmJiOGRkMjM0NzA5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTYXQsIDE2IEZlYiAyMDEzIDE2OjU5OjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAxLzJd
IHhlbi9hY3BpOiB4ZW4gbWVtb3J5IGhvdHBsdWcgbWlub3IgdXBkYXRlcwoKRGFuIENhcnBlbnRl
ciBmb3VuZCBjdXJyZW50IHhlbiBtZW1vcnkgaG90cGx1ZyBsb2dpYwpoYXMgcG90ZW50aWFsIGlz
c3VlOiBhdCBmdW5jIGFjcGlfbWVtb3J5X2dldF9kZXZpY2UoKQoqbWVtX2RldmljZSA9IGFjcGlf
ZHJpdmVyX2RhdGEoZGV2aWNlKTsKd2hpbGUgdGhlIGRldmljZSBtYXkgYmUgTlVMTCBhbmQgdGhl
biBkZXJlZmVyZW5jZS4KCkF0IG5hdGl2ZSBzaWRlLCBSYWZhZWwgcmVjZW50bHkgdXBkYXRlZCBh
Y3BpX21lbW9yeV9nZXRfZGV2aWNlKCksCmRyb3BwaW5nIGFjcGlfYnVzX2FkZCwgYWRkaW5nIGxv
Y2ssIGFuZCBhdm9pZGluZyBhYm92ZSBpc3N1ZS4KClRoaXMgcGF0Y2ggdXBkYXRlcyB4ZW4gbWVt
b3J5IGhvdHBsdWcgbG9naWMgYWNjb3JkaW5nbHksIHJlbW92aW5nCnJlZHVuZGFudCBsb2dpYywg
YWRkaW5nIGxvY2ssIGFuZCBhdm9pZGluZyBkZXJlZmVyZW5jZS4KClNpZ25lZC1vZmYtYnk6IExp
dSBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4veGVuLWFj
cGktbWVtaG90cGx1Zy5jIHwgICA1MiArKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0t
LS0KIDEgZmlsZXMgY2hhbmdlZCwgMjYgaW5zZXJ0aW9ucygrKSwgMjYgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuLWFjcGktbWVtaG90cGx1Zy5jIGIvZHJpdmVycy94
ZW4veGVuLWFjcGktbWVtaG90cGx1Zy5jCmluZGV4IDg1M2IxMmQuLmZhZWY1YjMgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYworKysgYi9kcml2ZXJzL3hlbi94
ZW4tYWNwaS1tZW1ob3RwbHVnLmMKQEAgLTE1OCwzMSArMTU4LDE3IEBAIGFjcGlfbWVtb3J5X2dl
dF9kZXZpY2VfcmVzb3VyY2VzKHN0cnVjdCBhY3BpX21lbW9yeV9kZXZpY2UgKm1lbV9kZXZpY2Up
CiAJcmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbnQKLWFjcGlfbWVtb3J5X2dldF9kZXZpY2UoYWNw
aV9oYW5kbGUgaGFuZGxlLAotCQkgICAgICAgc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqKm1l
bV9kZXZpY2UpCitzdGF0aWMgaW50IGFjcGlfbWVtb3J5X2dldF9kZXZpY2UoYWNwaV9oYW5kbGUg
aGFuZGxlLAorCQkJCSAgc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqKm1lbV9kZXZpY2UpCiB7
Ci0JYWNwaV9zdGF0dXMgc3RhdHVzOwotCWFjcGlfaGFuZGxlIHBoYW5kbGU7CiAJc3RydWN0IGFj
cGlfZGV2aWNlICpkZXZpY2UgPSBOVUxMOwotCXN0cnVjdCBhY3BpX2RldmljZSAqcGRldmljZSA9
IE5VTEw7Ci0JaW50IHJlc3VsdDsKKwlpbnQgcmVzdWx0ID0gMDsKIAotCWlmICghYWNwaV9idXNf
Z2V0X2RldmljZShoYW5kbGUsICZkZXZpY2UpICYmIGRldmljZSkKLQkJZ290byBlbmQ7CisJYWNw
aV9zY2FuX2xvY2tfYWNxdWlyZSgpOwogCi0Jc3RhdHVzID0gYWNwaV9nZXRfcGFyZW50KGhhbmRs
ZSwgJnBoYW5kbGUpOwotCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkgewotCQlwcl93YXJuKFBS
RUZJWCAiQ2Fubm90IGZpbmQgYWNwaSBwYXJlbnRcbiIpOwotCQlyZXR1cm4gLUVJTlZBTDsKLQl9
Ci0KLQkvKiBHZXQgdGhlIHBhcmVudCBkZXZpY2UgKi8KLQlyZXN1bHQgPSBhY3BpX2J1c19nZXRf
ZGV2aWNlKHBoYW5kbGUsICZwZGV2aWNlKTsKLQlpZiAocmVzdWx0KSB7Ci0JCXByX3dhcm4oUFJF
RklYICJDYW5ub3QgZ2V0IGFjcGkgYnVzIGRldmljZVxuIik7Ci0JCXJldHVybiAtRUlOVkFMOwot
CX0KKwlhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRsZSwgJmRldmljZSk7CisJaWYgKGRldmljZSkK
KwkJZ290byBlbmQ7CiAKIAkvKgogCSAqIE5vdyBhZGQgdGhlIG5vdGlmaWVkIGRldmljZS4gIFRo
aXMgY3JlYXRlcyB0aGUgYWNwaV9kZXZpY2UKQEAgLTE5MCwxOCArMTc2LDI4IEBAIGFjcGlfbWVt
b3J5X2dldF9kZXZpY2UoYWNwaV9oYW5kbGUgaGFuZGxlLAogCSAqLwogCXJlc3VsdCA9IGFjcGlf
YnVzX3NjYW4oaGFuZGxlKTsKIAlpZiAocmVzdWx0KSB7Ci0JCXByX3dhcm4oUFJFRklYICJDYW5u
b3QgYWRkIGFjcGkgYnVzXG4iKTsKLQkJcmV0dXJuIC1FSU5WQUw7CisJCXByX3dhcm4oUFJFRklY
ICJBQ1BJIG5hbWVzcGFjZSBzY2FuIGZhaWxlZFxuIik7CisJCXJlc3VsdCA9IC1FSU5WQUw7CisJ
CWdvdG8gb3V0OworCX0KKwlyZXN1bHQgPSBhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRsZSwgJmRl
dmljZSk7CisJaWYgKHJlc3VsdCkgeworCQlwcl93YXJuKFBSRUZJWCAiTWlzc2luZyBkZXZpY2Ug
b2JqZWN0XG4iKTsKKwkJcmVzdWx0ID0gLUVJTlZBTDsKKwkJZ290byBvdXQ7CiAJfQogCiBlbmQ6
CiAJKm1lbV9kZXZpY2UgPSBhY3BpX2RyaXZlcl9kYXRhKGRldmljZSk7CiAJaWYgKCEoKm1lbV9k
ZXZpY2UpKSB7Ci0JCXByX2VycihQUkVGSVggIkRyaXZlciBkYXRhIG5vdCBmb3VuZFxuIik7Ci0J
CXJldHVybiAtRU5PREVWOworCQlwcl9lcnIoUFJFRklYICJkcml2ZXIgZGF0YSBub3QgZm91bmRc
biIpOworCQlyZXN1bHQgPSAtRU5PREVWOworCQlnb3RvIG91dDsKIAl9CiAKLQlyZXR1cm4gMDsK
K291dDoKKwlhY3BpX3NjYW5fbG9ja19yZWxlYXNlKCk7CisJcmV0dXJuIHJlc3VsdDsKIH0KIAog
c3RhdGljIGludCBhY3BpX21lbW9yeV9jaGVja19kZXZpY2Uoc3RydWN0IGFjcGlfbWVtb3J5X2Rl
dmljZSAqbWVtX2RldmljZSkKQEAgLTI1OSwxMiArMjU1LDE1IEBAIHN0YXRpYyB2b2lkIGFjcGlf
bWVtb3J5X2RldmljZV9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZlbnQsIHZvaWQg
KmRhdGEpCiAJCUFDUElfREVCVUdfUFJJTlQoKEFDUElfREJfSU5GTywKIAkJCSJcblJlY2VpdmVk
IEVKRUNUIFJFUVVFU1Qgbm90aWZpY2F0aW9uIGZvciBkZXZpY2VcbiIpKTsKIAorCQlhY3BpX3Nj
YW5fbG9ja19hY3F1aXJlKCk7CiAJCWlmIChhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRsZSwgJmRl
dmljZSkpIHsKKwkJCWFjcGlfc2Nhbl9sb2NrX3JlbGVhc2UoKTsKIAkJCXByX2VycihQUkVGSVgg
IkRldmljZSBkb2Vzbid0IGV4aXN0XG4iKTsKIAkJCWJyZWFrOwogCQl9CiAJCW1lbV9kZXZpY2Ug
PSBhY3BpX2RyaXZlcl9kYXRhKGRldmljZSk7CiAJCWlmICghbWVtX2RldmljZSkgeworCQkJYWNw
aV9zY2FuX2xvY2tfcmVsZWFzZSgpOwogCQkJcHJfZXJyKFBSRUZJWCAiRHJpdmVyIERhdGEgaXMg
TlVMTFxuIik7CiAJCQlicmVhazsKIAkJfQpAQCAtMjc0LDYgKzI3Myw3IEBAIHN0YXRpYyB2b2lk
IGFjcGlfbWVtb3J5X2RldmljZV9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZlbnQs
IHZvaWQgKmRhdGEpCiAJCSAqIGFjcGlfYnVzX3JlbW92ZSBpZiBYZW4gc3VwcG9ydCBob3RyZW1v
dmUgaW4gdGhlIGZ1dHVyZQogCQkgKi8KIAkJYWNwaV9tZW1vcnlfZGlzYWJsZV9kZXZpY2UobWVt
X2RldmljZSk7CisJCWFjcGlfc2Nhbl9sb2NrX3JlbGVhc2UoKTsKIAkJYnJlYWs7CiAKIAlkZWZh
dWx0OgotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Sun Feb 17 07:38:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07: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 1U6yoh-00006T-L3; Sun, 17 Feb 2013 07:37:43 +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 1U6yof-00006O-MZ
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:37:42 +0000
Received: from [85.158.137.99:36124] by server-4.bemta-3.messagelabs.com id
	E0/A2-17521-4C880215; Sun, 17 Feb 2013 07:37:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361086658!19455277!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ5MzA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2154 invoked from network); 17 Feb 2013 07:37:39 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-217.messagelabs.com with SMTP;
	17 Feb 2013 07:37:39 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Feb 2013 23:37:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; 
	d="scan'208,223";a="263685221"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:37:37 -0800
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:37:37 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:37:36 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:37:35 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Wysocki, Rafael J"
	<rafael.j.wysocki@intel.com>, Stephen Rothwell <sfr@canb.auug.org.au>
Thread-Topic: [PATCH 1/2] xen/acpi: xen memory hotplug minor updates
Thread-Index: Ac4M4abEDm8BJ5/PS2+i93UswO8RQQ==
Date: Sun, 17 Feb 2013 07:37:34 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCCC8@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_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] xen/acpi: xen memory hotplug minor updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From aa363f1a4f862fab2f50dfe3ad602bb8dd234709 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sat, 16 Feb 2013 16:59:03 +0800
Subject: [PATCH 1/2] xen/acpi: xen memory hotplug minor updates

Dan Carpenter found current xen memory hotplug logic
has potential issue: at func acpi_memory_get_device()
*mem_device =3D acpi_driver_data(device);
while the device may be NULL and then dereference.

At native side, Rafael recently updated acpi_memory_get_device(),
dropping acpi_bus_add, adding lock, and avoiding above issue.

This patch updates xen memory hotplug logic accordingly, removing
redundant logic, adding lock, and avoiding dereference.

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen-acpi-memhotplug.c |   52 ++++++++++++++++++---------------=
---
 1 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memho=
tplug.c
index 853b12d..faef5b3 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -158,31 +158,17 @@ acpi_memory_get_device_resources(struct acpi_memory_d=
evice *mem_device)
 	return 0;
 }
=20
-static int
-acpi_memory_get_device(acpi_handle handle,
-		       struct acpi_memory_device **mem_device)
+static int acpi_memory_get_device(acpi_handle handle,
+				  struct acpi_memory_device **mem_device)
 {
-	acpi_status status;
-	acpi_handle phandle;
 	struct acpi_device *device =3D NULL;
-	struct acpi_device *pdevice =3D NULL;
-	int result;
+	int result =3D 0;
=20
-	if (!acpi_bus_get_device(handle, &device) && device)
-		goto end;
+	acpi_scan_lock_acquire();
=20
-	status =3D acpi_get_parent(handle, &phandle);
-	if (ACPI_FAILURE(status)) {
-		pr_warn(PREFIX "Cannot find acpi parent\n");
-		return -EINVAL;
-	}
-
-	/* Get the parent device */
-	result =3D acpi_bus_get_device(phandle, &pdevice);
-	if (result) {
-		pr_warn(PREFIX "Cannot get acpi bus device\n");
-		return -EINVAL;
-	}
+	acpi_bus_get_device(handle, &device);
+	if (device)
+		goto end;
=20
 	/*
 	 * Now add the notified device.  This creates the acpi_device
@@ -190,18 +176,28 @@ acpi_memory_get_device(acpi_handle handle,
 	 */
 	result =3D acpi_bus_scan(handle);
 	if (result) {
-		pr_warn(PREFIX "Cannot add acpi bus\n");
-		return -EINVAL;
+		pr_warn(PREFIX "ACPI namespace scan failed\n");
+		result =3D -EINVAL;
+		goto out;
+	}
+	result =3D acpi_bus_get_device(handle, &device);
+	if (result) {
+		pr_warn(PREFIX "Missing device object\n");
+		result =3D -EINVAL;
+		goto out;
 	}
=20
 end:
 	*mem_device =3D acpi_driver_data(device);
 	if (!(*mem_device)) {
-		pr_err(PREFIX "Driver data not found\n");
-		return -ENODEV;
+		pr_err(PREFIX "driver data not found\n");
+		result =3D -ENODEV;
+		goto out;
 	}
=20
-	return 0;
+out:
+	acpi_scan_lock_release();
+	return result;
 }
=20
 static int acpi_memory_check_device(struct acpi_memory_device *mem_device)
@@ -259,12 +255,15 @@ static void acpi_memory_device_notify(acpi_handle han=
dle, u32 event, void *data)
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 			"\nReceived EJECT REQUEST notification for device\n"));
=20
+		acpi_scan_lock_acquire();
 		if (acpi_bus_get_device(handle, &device)) {
+			acpi_scan_lock_release();
 			pr_err(PREFIX "Device doesn't exist\n");
 			break;
 		}
 		mem_device =3D acpi_driver_data(device);
 		if (!mem_device) {
+			acpi_scan_lock_release();
 			pr_err(PREFIX "Driver Data is NULL\n");
 			break;
 		}
@@ -274,6 +273,7 @@ static void acpi_memory_device_notify(acpi_handle handl=
e, u32 event, void *data)
 		 * acpi_bus_remove if Xen support hotremove in the future
 		 */
 		acpi_memory_disable_device(mem_device);
+		acpi_scan_lock_release();
 		break;
=20
 	default:
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-xen-acpi-xen-memory-hotplug-minor-updates.patch"
Content-Description: 0001-xen-acpi-xen-memory-hotplug-minor-updates.patch
Content-Disposition: attachment;
	filename="0001-xen-acpi-xen-memory-hotplug-minor-updates.patch"; size=3664;
	creation-date="Sun, 17 Feb 2013 07:24:14 GMT";
	modification-date="Sun, 17 Feb 2013 15:14:12 GMT"
Content-Transfer-Encoding: base64

RnJvbSBhYTM2M2YxYTRmODYyZmFiMmY1MGRmZTNhZDYwMmJiOGRkMjM0NzA5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTYXQsIDE2IEZlYiAyMDEzIDE2OjU5OjAzICswODAwClN1YmplY3Q6IFtQQVRDSCAxLzJd
IHhlbi9hY3BpOiB4ZW4gbWVtb3J5IGhvdHBsdWcgbWlub3IgdXBkYXRlcwoKRGFuIENhcnBlbnRl
ciBmb3VuZCBjdXJyZW50IHhlbiBtZW1vcnkgaG90cGx1ZyBsb2dpYwpoYXMgcG90ZW50aWFsIGlz
c3VlOiBhdCBmdW5jIGFjcGlfbWVtb3J5X2dldF9kZXZpY2UoKQoqbWVtX2RldmljZSA9IGFjcGlf
ZHJpdmVyX2RhdGEoZGV2aWNlKTsKd2hpbGUgdGhlIGRldmljZSBtYXkgYmUgTlVMTCBhbmQgdGhl
biBkZXJlZmVyZW5jZS4KCkF0IG5hdGl2ZSBzaWRlLCBSYWZhZWwgcmVjZW50bHkgdXBkYXRlZCBh
Y3BpX21lbW9yeV9nZXRfZGV2aWNlKCksCmRyb3BwaW5nIGFjcGlfYnVzX2FkZCwgYWRkaW5nIGxv
Y2ssIGFuZCBhdm9pZGluZyBhYm92ZSBpc3N1ZS4KClRoaXMgcGF0Y2ggdXBkYXRlcyB4ZW4gbWVt
b3J5IGhvdHBsdWcgbG9naWMgYWNjb3JkaW5nbHksIHJlbW92aW5nCnJlZHVuZGFudCBsb2dpYywg
YWRkaW5nIGxvY2ssIGFuZCBhdm9pZGluZyBkZXJlZmVyZW5jZS4KClNpZ25lZC1vZmYtYnk6IExp
dSBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4veGVuLWFj
cGktbWVtaG90cGx1Zy5jIHwgICA1MiArKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0t
LS0KIDEgZmlsZXMgY2hhbmdlZCwgMjYgaW5zZXJ0aW9ucygrKSwgMjYgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuLWFjcGktbWVtaG90cGx1Zy5jIGIvZHJpdmVycy94
ZW4veGVuLWFjcGktbWVtaG90cGx1Zy5jCmluZGV4IDg1M2IxMmQuLmZhZWY1YjMgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL3hlbi1hY3BpLW1lbWhvdHBsdWcuYworKysgYi9kcml2ZXJzL3hlbi94
ZW4tYWNwaS1tZW1ob3RwbHVnLmMKQEAgLTE1OCwzMSArMTU4LDE3IEBAIGFjcGlfbWVtb3J5X2dl
dF9kZXZpY2VfcmVzb3VyY2VzKHN0cnVjdCBhY3BpX21lbW9yeV9kZXZpY2UgKm1lbV9kZXZpY2Up
CiAJcmV0dXJuIDA7CiB9CiAKLXN0YXRpYyBpbnQKLWFjcGlfbWVtb3J5X2dldF9kZXZpY2UoYWNw
aV9oYW5kbGUgaGFuZGxlLAotCQkgICAgICAgc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqKm1l
bV9kZXZpY2UpCitzdGF0aWMgaW50IGFjcGlfbWVtb3J5X2dldF9kZXZpY2UoYWNwaV9oYW5kbGUg
aGFuZGxlLAorCQkJCSAgc3RydWN0IGFjcGlfbWVtb3J5X2RldmljZSAqKm1lbV9kZXZpY2UpCiB7
Ci0JYWNwaV9zdGF0dXMgc3RhdHVzOwotCWFjcGlfaGFuZGxlIHBoYW5kbGU7CiAJc3RydWN0IGFj
cGlfZGV2aWNlICpkZXZpY2UgPSBOVUxMOwotCXN0cnVjdCBhY3BpX2RldmljZSAqcGRldmljZSA9
IE5VTEw7Ci0JaW50IHJlc3VsdDsKKwlpbnQgcmVzdWx0ID0gMDsKIAotCWlmICghYWNwaV9idXNf
Z2V0X2RldmljZShoYW5kbGUsICZkZXZpY2UpICYmIGRldmljZSkKLQkJZ290byBlbmQ7CisJYWNw
aV9zY2FuX2xvY2tfYWNxdWlyZSgpOwogCi0Jc3RhdHVzID0gYWNwaV9nZXRfcGFyZW50KGhhbmRs
ZSwgJnBoYW5kbGUpOwotCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkgewotCQlwcl93YXJuKFBS
RUZJWCAiQ2Fubm90IGZpbmQgYWNwaSBwYXJlbnRcbiIpOwotCQlyZXR1cm4gLUVJTlZBTDsKLQl9
Ci0KLQkvKiBHZXQgdGhlIHBhcmVudCBkZXZpY2UgKi8KLQlyZXN1bHQgPSBhY3BpX2J1c19nZXRf
ZGV2aWNlKHBoYW5kbGUsICZwZGV2aWNlKTsKLQlpZiAocmVzdWx0KSB7Ci0JCXByX3dhcm4oUFJF
RklYICJDYW5ub3QgZ2V0IGFjcGkgYnVzIGRldmljZVxuIik7Ci0JCXJldHVybiAtRUlOVkFMOwot
CX0KKwlhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRsZSwgJmRldmljZSk7CisJaWYgKGRldmljZSkK
KwkJZ290byBlbmQ7CiAKIAkvKgogCSAqIE5vdyBhZGQgdGhlIG5vdGlmaWVkIGRldmljZS4gIFRo
aXMgY3JlYXRlcyB0aGUgYWNwaV9kZXZpY2UKQEAgLTE5MCwxOCArMTc2LDI4IEBAIGFjcGlfbWVt
b3J5X2dldF9kZXZpY2UoYWNwaV9oYW5kbGUgaGFuZGxlLAogCSAqLwogCXJlc3VsdCA9IGFjcGlf
YnVzX3NjYW4oaGFuZGxlKTsKIAlpZiAocmVzdWx0KSB7Ci0JCXByX3dhcm4oUFJFRklYICJDYW5u
b3QgYWRkIGFjcGkgYnVzXG4iKTsKLQkJcmV0dXJuIC1FSU5WQUw7CisJCXByX3dhcm4oUFJFRklY
ICJBQ1BJIG5hbWVzcGFjZSBzY2FuIGZhaWxlZFxuIik7CisJCXJlc3VsdCA9IC1FSU5WQUw7CisJ
CWdvdG8gb3V0OworCX0KKwlyZXN1bHQgPSBhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRsZSwgJmRl
dmljZSk7CisJaWYgKHJlc3VsdCkgeworCQlwcl93YXJuKFBSRUZJWCAiTWlzc2luZyBkZXZpY2Ug
b2JqZWN0XG4iKTsKKwkJcmVzdWx0ID0gLUVJTlZBTDsKKwkJZ290byBvdXQ7CiAJfQogCiBlbmQ6
CiAJKm1lbV9kZXZpY2UgPSBhY3BpX2RyaXZlcl9kYXRhKGRldmljZSk7CiAJaWYgKCEoKm1lbV9k
ZXZpY2UpKSB7Ci0JCXByX2VycihQUkVGSVggIkRyaXZlciBkYXRhIG5vdCBmb3VuZFxuIik7Ci0J
CXJldHVybiAtRU5PREVWOworCQlwcl9lcnIoUFJFRklYICJkcml2ZXIgZGF0YSBub3QgZm91bmRc
biIpOworCQlyZXN1bHQgPSAtRU5PREVWOworCQlnb3RvIG91dDsKIAl9CiAKLQlyZXR1cm4gMDsK
K291dDoKKwlhY3BpX3NjYW5fbG9ja19yZWxlYXNlKCk7CisJcmV0dXJuIHJlc3VsdDsKIH0KIAog
c3RhdGljIGludCBhY3BpX21lbW9yeV9jaGVja19kZXZpY2Uoc3RydWN0IGFjcGlfbWVtb3J5X2Rl
dmljZSAqbWVtX2RldmljZSkKQEAgLTI1OSwxMiArMjU1LDE1IEBAIHN0YXRpYyB2b2lkIGFjcGlf
bWVtb3J5X2RldmljZV9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZlbnQsIHZvaWQg
KmRhdGEpCiAJCUFDUElfREVCVUdfUFJJTlQoKEFDUElfREJfSU5GTywKIAkJCSJcblJlY2VpdmVk
IEVKRUNUIFJFUVVFU1Qgbm90aWZpY2F0aW9uIGZvciBkZXZpY2VcbiIpKTsKIAorCQlhY3BpX3Nj
YW5fbG9ja19hY3F1aXJlKCk7CiAJCWlmIChhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRsZSwgJmRl
dmljZSkpIHsKKwkJCWFjcGlfc2Nhbl9sb2NrX3JlbGVhc2UoKTsKIAkJCXByX2VycihQUkVGSVgg
IkRldmljZSBkb2Vzbid0IGV4aXN0XG4iKTsKIAkJCWJyZWFrOwogCQl9CiAJCW1lbV9kZXZpY2Ug
PSBhY3BpX2RyaXZlcl9kYXRhKGRldmljZSk7CiAJCWlmICghbWVtX2RldmljZSkgeworCQkJYWNw
aV9zY2FuX2xvY2tfcmVsZWFzZSgpOwogCQkJcHJfZXJyKFBSRUZJWCAiRHJpdmVyIERhdGEgaXMg
TlVMTFxuIik7CiAJCQlicmVhazsKIAkJfQpAQCAtMjc0LDYgKzI3Myw3IEBAIHN0YXRpYyB2b2lk
IGFjcGlfbWVtb3J5X2RldmljZV9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZlbnQs
IHZvaWQgKmRhdGEpCiAJCSAqIGFjcGlfYnVzX3JlbW92ZSBpZiBYZW4gc3VwcG9ydCBob3RyZW1v
dmUgaW4gdGhlIGZ1dHVyZQogCQkgKi8KIAkJYWNwaV9tZW1vcnlfZGlzYWJsZV9kZXZpY2UobWVt
X2RldmljZSk7CisJCWFjcGlfc2Nhbl9sb2NrX3JlbGVhc2UoKTsKIAkJYnJlYWs7CiAKIAlkZWZh
dWx0OgotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353FCCC8SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Sun Feb 17 07:40:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07: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 1U6yqv-0000CU-6M; Sun, 17 Feb 2013 07:40:01 +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 1U6yqt-0000CO-7b
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:39:59 +0000
Received: from [85.158.143.35:39418] by server-2.bemta-4.messagelabs.com id
	06/8B-01597-E4980215; Sun, 17 Feb 2013 07:39:58 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361086795!11810065!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ5MzA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27395 invoked from network); 17 Feb 2013 07:39:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-21.messagelabs.com with SMTP;
	17 Feb 2013 07:39:57 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Feb 2013 23:39:54 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; 
	d="scan'208,223";a="263685543"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:39:54 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:39:54 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:39:53 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:39:52 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Wysocki, Rafael J"
	<rafael.j.wysocki@intel.com>, Stephen Rothwell <sfr@canb.auug.org.au>
Thread-Topic: [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates
Thread-Index: Ac4M4fgaVCcyNOGFQf2uUoQZIyZF5A==
Date: Sun, 17 Feb 2013 07:39:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCCD5@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_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 195df2bf6174959baa025ccb249041bb53d6060a Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 17 Feb 2013 11:47:24 +0800
Subject: [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates

Recently at native Rafael did some cleanup for acpi, say, drop
acpi_bus_add, remove unnecessary argument of acpi_bus_scan,
and run acpi_bus_scan under acpi_scan_lock.

This patch does similar cleanup for xen cpu hotplug, removing
redundant logic, and adding lock.

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen-acpi-cpuhotplug.c |   34 ++++++++++++---------------------=
-
 1 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuho=
tplug.c
index 7578279..18c742b 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -239,24 +239,6 @@ static acpi_status xen_acpi_cpu_hotadd(struct acpi_pro=
cessor *pr)
 	return AE_OK;
 }
=20
-static
-int acpi_processor_device_add(acpi_handle handle, struct acpi_device **dev=
ice)
-{
-	acpi_handle phandle;
-	struct acpi_device *pdev;
-
-	if (acpi_get_parent(handle, &phandle))
-		return -ENODEV;
-
-	if (acpi_bus_get_device(phandle, &pdev))
-		return -ENODEV;
-
-	if (acpi_bus_scan(handle))
-		return -ENODEV;
-
-	return 0;
-}
-
 static int acpi_processor_device_remove(struct acpi_device *device)
 {
 	pr_debug(PREFIX "Xen does not support CPU hotremove\n");
@@ -272,6 +254,8 @@ static void acpi_processor_hotplug_notify(acpi_handle h=
andle,
 	u32 ost_code =3D ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
 	int result;
=20
+	acpi_scan_lock_acquire();
+
 	switch (event) {
 	case ACPI_NOTIFY_BUS_CHECK:
 	case ACPI_NOTIFY_DEVICE_CHECK:
@@ -286,12 +270,16 @@ static void acpi_processor_hotplug_notify(acpi_handle=
 handle,
 		if (!acpi_bus_get_device(handle, &device))
 			break;
=20
-		result =3D acpi_processor_device_add(handle, &device);
+		result =3D acpi_bus_scan(handle);
 		if (result) {
 			pr_err(PREFIX "Unable to add the device\n");
 			break;
 		}
-
+		result =3D acpi_bus_get_device(handle, &device);
+		if (result) {
+			pr_err(PREFIX "Missing device object\n");
+			break;
+		}
 		ost_code =3D ACPI_OST_SC_SUCCESS;
 		break;
=20
@@ -321,11 +309,13 @@ static void acpi_processor_hotplug_notify(acpi_handle=
 handle,
 				  "Unsupported event [0x%x]\n", event));
=20
 		/* non-hotplug event; possibly handled by other handler */
-		return;
+		goto out;
 	}
=20
 	(void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
-	return;
+
+out:
+	acpi_scan_lock_release();
 }
=20
 static acpi_status is_processor_device(acpi_handle handle)
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch"
Content-Description: 0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch
Content-Disposition: attachment;
	filename="0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch"; size=2614;
	creation-date="Sun, 17 Feb 2013 07:24:14 GMT";
	modification-date="Sun, 17 Feb 2013 15:14:24 GMT"
Content-Transfer-Encoding: base64

RnJvbSAxOTVkZjJiZjYxNzQ5NTliYWEwMjVjY2IyNDkwNDFiYjUzZDYwNjBhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDE3IEZlYiAyMDEzIDExOjQ3OjI0ICswODAwClN1YmplY3Q6IFtQQVRDSCAyLzJd
IHhlbi9hY3BpOiB4ZW4gY3B1IGhvdHBsdWcgbWlub3IgdXBkYXRlcwoKUmVjZW50bHkgYXQgbmF0
aXZlIFJhZmFlbCBkaWQgc29tZSBjbGVhbnVwIGZvciBhY3BpLCBzYXksIGRyb3AKYWNwaV9idXNf
YWRkLCByZW1vdmUgdW5uZWNlc3NhcnkgYXJndW1lbnQgb2YgYWNwaV9idXNfc2NhbiwKYW5kIHJ1
biBhY3BpX2J1c19zY2FuIHVuZGVyIGFjcGlfc2Nhbl9sb2NrLgoKVGhpcyBwYXRjaCBkb2VzIHNp
bWlsYXIgY2xlYW51cCBmb3IgeGVuIGNwdSBob3RwbHVnLCByZW1vdmluZwpyZWR1bmRhbnQgbG9n
aWMsIGFuZCBhZGRpbmcgbG9jay4KClNpZ25lZC1vZmYtYnk6IExpdSBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4veGVuLWFjcGktY3B1aG90cGx1Zy5jIHwg
ICAzNCArKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQs
IDEyIGluc2VydGlvbnMoKyksIDIyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMv
eGVuL3hlbi1hY3BpLWNwdWhvdHBsdWcuYyBiL2RyaXZlcnMveGVuL3hlbi1hY3BpLWNwdWhvdHBs
dWcuYwppbmRleCA3NTc4Mjc5Li4xOGM3NDJiIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4t
YWNwaS1jcHVob3RwbHVnLmMKKysrIGIvZHJpdmVycy94ZW4veGVuLWFjcGktY3B1aG90cGx1Zy5j
CkBAIC0yMzksMjQgKzIzOSw2IEBAIHN0YXRpYyBhY3BpX3N0YXR1cyB4ZW5fYWNwaV9jcHVfaG90
YWRkKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCiAJcmV0dXJuIEFFX09LOwogfQogCi1zdGF0
aWMKLWludCBhY3BpX3Byb2Nlc3Nvcl9kZXZpY2VfYWRkKGFjcGlfaGFuZGxlIGhhbmRsZSwgc3Ry
dWN0IGFjcGlfZGV2aWNlICoqZGV2aWNlKQotewotCWFjcGlfaGFuZGxlIHBoYW5kbGU7Ci0Jc3Ry
dWN0IGFjcGlfZGV2aWNlICpwZGV2OwotCi0JaWYgKGFjcGlfZ2V0X3BhcmVudChoYW5kbGUsICZw
aGFuZGxlKSkKLQkJcmV0dXJuIC1FTk9ERVY7Ci0KLQlpZiAoYWNwaV9idXNfZ2V0X2RldmljZShw
aGFuZGxlLCAmcGRldikpCi0JCXJldHVybiAtRU5PREVWOwotCi0JaWYgKGFjcGlfYnVzX3NjYW4o
aGFuZGxlKSkKLQkJcmV0dXJuIC1FTk9ERVY7Ci0KLQlyZXR1cm4gMDsKLX0KLQogc3RhdGljIGlu
dCBhY3BpX3Byb2Nlc3Nvcl9kZXZpY2VfcmVtb3ZlKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNl
KQogewogCXByX2RlYnVnKFBSRUZJWCAiWGVuIGRvZXMgbm90IHN1cHBvcnQgQ1BVIGhvdHJlbW92
ZVxuIik7CkBAIC0yNzIsNiArMjU0LDggQEAgc3RhdGljIHZvaWQgYWNwaV9wcm9jZXNzb3JfaG90
cGx1Z19ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLAogCXUzMiBvc3RfY29kZSA9IEFDUElfT1NU
X1NDX05PTl9TUEVDSUZJQ19GQUlMVVJFOyAvKiBkZWZhdWx0ICovCiAJaW50IHJlc3VsdDsKIAor
CWFjcGlfc2Nhbl9sb2NrX2FjcXVpcmUoKTsKKwogCXN3aXRjaCAoZXZlbnQpIHsKIAljYXNlIEFD
UElfTk9USUZZX0JVU19DSEVDSzoKIAljYXNlIEFDUElfTk9USUZZX0RFVklDRV9DSEVDSzoKQEAg
LTI4NiwxMiArMjcwLDE2IEBAIHN0YXRpYyB2b2lkIGFjcGlfcHJvY2Vzc29yX2hvdHBsdWdfbm90
aWZ5KGFjcGlfaGFuZGxlIGhhbmRsZSwKIAkJaWYgKCFhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRs
ZSwgJmRldmljZSkpCiAJCQlicmVhazsKIAotCQlyZXN1bHQgPSBhY3BpX3Byb2Nlc3Nvcl9kZXZp
Y2VfYWRkKGhhbmRsZSwgJmRldmljZSk7CisJCXJlc3VsdCA9IGFjcGlfYnVzX3NjYW4oaGFuZGxl
KTsKIAkJaWYgKHJlc3VsdCkgewogCQkJcHJfZXJyKFBSRUZJWCAiVW5hYmxlIHRvIGFkZCB0aGUg
ZGV2aWNlXG4iKTsKIAkJCWJyZWFrOwogCQl9Ci0KKwkJcmVzdWx0ID0gYWNwaV9idXNfZ2V0X2Rl
dmljZShoYW5kbGUsICZkZXZpY2UpOworCQlpZiAocmVzdWx0KSB7CisJCQlwcl9lcnIoUFJFRklY
ICJNaXNzaW5nIGRldmljZSBvYmplY3RcbiIpOworCQkJYnJlYWs7CisJCX0KIAkJb3N0X2NvZGUg
PSBBQ1BJX09TVF9TQ19TVUNDRVNTOwogCQlicmVhazsKIApAQCAtMzIxLDExICszMDksMTMgQEAg
c3RhdGljIHZvaWQgYWNwaV9wcm9jZXNzb3JfaG90cGx1Z19ub3RpZnkoYWNwaV9oYW5kbGUgaGFu
ZGxlLAogCQkJCSAgIlVuc3VwcG9ydGVkIGV2ZW50IFsweCV4XVxuIiwgZXZlbnQpKTsKIAogCQkv
KiBub24taG90cGx1ZyBldmVudDsgcG9zc2libHkgaGFuZGxlZCBieSBvdGhlciBoYW5kbGVyICov
Ci0JCXJldHVybjsKKwkJZ290byBvdXQ7CiAJfQogCiAJKHZvaWQpIGFjcGlfZXZhbHVhdGVfaG90
cGx1Z19vc3QoaGFuZGxlLCBldmVudCwgb3N0X2NvZGUsIE5VTEwpOwotCXJldHVybjsKKworb3V0
OgorCWFjcGlfc2Nhbl9sb2NrX3JlbGVhc2UoKTsKIH0KIAogc3RhdGljIGFjcGlfc3RhdHVzIGlz
X3Byb2Nlc3Nvcl9kZXZpY2UoYWNwaV9oYW5kbGUgaGFuZGxlKQotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Sun Feb 17 07:40:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 07: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 1U6yqv-0000CU-6M; Sun, 17 Feb 2013 07:40:01 +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 1U6yqt-0000CO-7b
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 07:39:59 +0000
Received: from [85.158.143.35:39418] by server-2.bemta-4.messagelabs.com id
	06/8B-01597-E4980215; Sun, 17 Feb 2013 07:39:58 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361086795!11810065!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzQ5MzA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27395 invoked from network); 17 Feb 2013 07:39:57 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-21.messagelabs.com with SMTP;
	17 Feb 2013 07:39:57 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Feb 2013 23:39:54 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,682,1355126400"; 
	d="scan'208,223";a="263685543"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 16 Feb 2013 23:39:54 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:39:54 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sat, 16 Feb 2013 23:39:53 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Sun, 17 Feb 2013 15:39:52 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Wysocki, Rafael J"
	<rafael.j.wysocki@intel.com>, Stephen Rothwell <sfr@canb.auug.org.au>
Thread-Topic: [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates
Thread-Index: Ac4M4fgaVCcyNOGFQf2uUoQZIyZF5A==
Date: Sun, 17 Feb 2013 07:39:51 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353FCCD5@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_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 195df2bf6174959baa025ccb249041bb53d6060a Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Sun, 17 Feb 2013 11:47:24 +0800
Subject: [PATCH 2/2] xen/acpi: xen cpu hotplug minor updates

Recently at native Rafael did some cleanup for acpi, say, drop
acpi_bus_add, remove unnecessary argument of acpi_bus_scan,
and run acpi_bus_scan under acpi_scan_lock.

This patch does similar cleanup for xen cpu hotplug, removing
redundant logic, and adding lock.

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
---
 drivers/xen/xen-acpi-cpuhotplug.c |   34 ++++++++++++---------------------=
-
 1 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuho=
tplug.c
index 7578279..18c742b 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -239,24 +239,6 @@ static acpi_status xen_acpi_cpu_hotadd(struct acpi_pro=
cessor *pr)
 	return AE_OK;
 }
=20
-static
-int acpi_processor_device_add(acpi_handle handle, struct acpi_device **dev=
ice)
-{
-	acpi_handle phandle;
-	struct acpi_device *pdev;
-
-	if (acpi_get_parent(handle, &phandle))
-		return -ENODEV;
-
-	if (acpi_bus_get_device(phandle, &pdev))
-		return -ENODEV;
-
-	if (acpi_bus_scan(handle))
-		return -ENODEV;
-
-	return 0;
-}
-
 static int acpi_processor_device_remove(struct acpi_device *device)
 {
 	pr_debug(PREFIX "Xen does not support CPU hotremove\n");
@@ -272,6 +254,8 @@ static void acpi_processor_hotplug_notify(acpi_handle h=
andle,
 	u32 ost_code =3D ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
 	int result;
=20
+	acpi_scan_lock_acquire();
+
 	switch (event) {
 	case ACPI_NOTIFY_BUS_CHECK:
 	case ACPI_NOTIFY_DEVICE_CHECK:
@@ -286,12 +270,16 @@ static void acpi_processor_hotplug_notify(acpi_handle=
 handle,
 		if (!acpi_bus_get_device(handle, &device))
 			break;
=20
-		result =3D acpi_processor_device_add(handle, &device);
+		result =3D acpi_bus_scan(handle);
 		if (result) {
 			pr_err(PREFIX "Unable to add the device\n");
 			break;
 		}
-
+		result =3D acpi_bus_get_device(handle, &device);
+		if (result) {
+			pr_err(PREFIX "Missing device object\n");
+			break;
+		}
 		ost_code =3D ACPI_OST_SC_SUCCESS;
 		break;
=20
@@ -321,11 +309,13 @@ static void acpi_processor_hotplug_notify(acpi_handle=
 handle,
 				  "Unsupported event [0x%x]\n", event));
=20
 		/* non-hotplug event; possibly handled by other handler */
-		return;
+		goto out;
 	}
=20
 	(void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
-	return;
+
+out:
+	acpi_scan_lock_release();
 }
=20
 static acpi_status is_processor_device(acpi_handle handle)
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch"
Content-Description: 0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch
Content-Disposition: attachment;
	filename="0002-xen-acpi-xen-cpu-hotplug-minor-updates.patch"; size=2614;
	creation-date="Sun, 17 Feb 2013 07:24:14 GMT";
	modification-date="Sun, 17 Feb 2013 15:14:24 GMT"
Content-Transfer-Encoding: base64

RnJvbSAxOTVkZjJiZjYxNzQ5NTliYWEwMjVjY2IyNDkwNDFiYjUzZDYwNjBhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpE
YXRlOiBTdW4sIDE3IEZlYiAyMDEzIDExOjQ3OjI0ICswODAwClN1YmplY3Q6IFtQQVRDSCAyLzJd
IHhlbi9hY3BpOiB4ZW4gY3B1IGhvdHBsdWcgbWlub3IgdXBkYXRlcwoKUmVjZW50bHkgYXQgbmF0
aXZlIFJhZmFlbCBkaWQgc29tZSBjbGVhbnVwIGZvciBhY3BpLCBzYXksIGRyb3AKYWNwaV9idXNf
YWRkLCByZW1vdmUgdW5uZWNlc3NhcnkgYXJndW1lbnQgb2YgYWNwaV9idXNfc2NhbiwKYW5kIHJ1
biBhY3BpX2J1c19zY2FuIHVuZGVyIGFjcGlfc2Nhbl9sb2NrLgoKVGhpcyBwYXRjaCBkb2VzIHNp
bWlsYXIgY2xlYW51cCBmb3IgeGVuIGNwdSBob3RwbHVnLCByZW1vdmluZwpyZWR1bmRhbnQgbG9n
aWMsIGFuZCBhZGRpbmcgbG9jay4KClNpZ25lZC1vZmYtYnk6IExpdSBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4veGVuLWFjcGktY3B1aG90cGx1Zy5jIHwg
ICAzNCArKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQs
IDEyIGluc2VydGlvbnMoKyksIDIyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMv
eGVuL3hlbi1hY3BpLWNwdWhvdHBsdWcuYyBiL2RyaXZlcnMveGVuL3hlbi1hY3BpLWNwdWhvdHBs
dWcuYwppbmRleCA3NTc4Mjc5Li4xOGM3NDJiIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4t
YWNwaS1jcHVob3RwbHVnLmMKKysrIGIvZHJpdmVycy94ZW4veGVuLWFjcGktY3B1aG90cGx1Zy5j
CkBAIC0yMzksMjQgKzIzOSw2IEBAIHN0YXRpYyBhY3BpX3N0YXR1cyB4ZW5fYWNwaV9jcHVfaG90
YWRkKHN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHIpCiAJcmV0dXJuIEFFX09LOwogfQogCi1zdGF0
aWMKLWludCBhY3BpX3Byb2Nlc3Nvcl9kZXZpY2VfYWRkKGFjcGlfaGFuZGxlIGhhbmRsZSwgc3Ry
dWN0IGFjcGlfZGV2aWNlICoqZGV2aWNlKQotewotCWFjcGlfaGFuZGxlIHBoYW5kbGU7Ci0Jc3Ry
dWN0IGFjcGlfZGV2aWNlICpwZGV2OwotCi0JaWYgKGFjcGlfZ2V0X3BhcmVudChoYW5kbGUsICZw
aGFuZGxlKSkKLQkJcmV0dXJuIC1FTk9ERVY7Ci0KLQlpZiAoYWNwaV9idXNfZ2V0X2RldmljZShw
aGFuZGxlLCAmcGRldikpCi0JCXJldHVybiAtRU5PREVWOwotCi0JaWYgKGFjcGlfYnVzX3NjYW4o
aGFuZGxlKSkKLQkJcmV0dXJuIC1FTk9ERVY7Ci0KLQlyZXR1cm4gMDsKLX0KLQogc3RhdGljIGlu
dCBhY3BpX3Byb2Nlc3Nvcl9kZXZpY2VfcmVtb3ZlKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNl
KQogewogCXByX2RlYnVnKFBSRUZJWCAiWGVuIGRvZXMgbm90IHN1cHBvcnQgQ1BVIGhvdHJlbW92
ZVxuIik7CkBAIC0yNzIsNiArMjU0LDggQEAgc3RhdGljIHZvaWQgYWNwaV9wcm9jZXNzb3JfaG90
cGx1Z19ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLAogCXUzMiBvc3RfY29kZSA9IEFDUElfT1NU
X1NDX05PTl9TUEVDSUZJQ19GQUlMVVJFOyAvKiBkZWZhdWx0ICovCiAJaW50IHJlc3VsdDsKIAor
CWFjcGlfc2Nhbl9sb2NrX2FjcXVpcmUoKTsKKwogCXN3aXRjaCAoZXZlbnQpIHsKIAljYXNlIEFD
UElfTk9USUZZX0JVU19DSEVDSzoKIAljYXNlIEFDUElfTk9USUZZX0RFVklDRV9DSEVDSzoKQEAg
LTI4NiwxMiArMjcwLDE2IEBAIHN0YXRpYyB2b2lkIGFjcGlfcHJvY2Vzc29yX2hvdHBsdWdfbm90
aWZ5KGFjcGlfaGFuZGxlIGhhbmRsZSwKIAkJaWYgKCFhY3BpX2J1c19nZXRfZGV2aWNlKGhhbmRs
ZSwgJmRldmljZSkpCiAJCQlicmVhazsKIAotCQlyZXN1bHQgPSBhY3BpX3Byb2Nlc3Nvcl9kZXZp
Y2VfYWRkKGhhbmRsZSwgJmRldmljZSk7CisJCXJlc3VsdCA9IGFjcGlfYnVzX3NjYW4oaGFuZGxl
KTsKIAkJaWYgKHJlc3VsdCkgewogCQkJcHJfZXJyKFBSRUZJWCAiVW5hYmxlIHRvIGFkZCB0aGUg
ZGV2aWNlXG4iKTsKIAkJCWJyZWFrOwogCQl9Ci0KKwkJcmVzdWx0ID0gYWNwaV9idXNfZ2V0X2Rl
dmljZShoYW5kbGUsICZkZXZpY2UpOworCQlpZiAocmVzdWx0KSB7CisJCQlwcl9lcnIoUFJFRklY
ICJNaXNzaW5nIGRldmljZSBvYmplY3RcbiIpOworCQkJYnJlYWs7CisJCX0KIAkJb3N0X2NvZGUg
PSBBQ1BJX09TVF9TQ19TVUNDRVNTOwogCQlicmVhazsKIApAQCAtMzIxLDExICszMDksMTMgQEAg
c3RhdGljIHZvaWQgYWNwaV9wcm9jZXNzb3JfaG90cGx1Z19ub3RpZnkoYWNwaV9oYW5kbGUgaGFu
ZGxlLAogCQkJCSAgIlVuc3VwcG9ydGVkIGV2ZW50IFsweCV4XVxuIiwgZXZlbnQpKTsKIAogCQkv
KiBub24taG90cGx1ZyBldmVudDsgcG9zc2libHkgaGFuZGxlZCBieSBvdGhlciBoYW5kbGVyICov
Ci0JCXJldHVybjsKKwkJZ290byBvdXQ7CiAJfQogCiAJKHZvaWQpIGFjcGlfZXZhbHVhdGVfaG90
cGx1Z19vc3QoaGFuZGxlLCBldmVudCwgb3N0X2NvZGUsIE5VTEwpOwotCXJldHVybjsKKworb3V0
OgorCWFjcGlfc2Nhbl9sb2NrX3JlbGVhc2UoKTsKIH0KIAogc3RhdGljIGFjcGlfc3RhdHVzIGlz
X3Byb2Nlc3Nvcl9kZXZpY2UoYWNwaV9oYW5kbGUgaGFuZGxlKQotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353FCCD5SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Sun Feb 17 10:11:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 10:11: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 1U71Cr-0002tI-Fb; Sun, 17 Feb 2013 10:10:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U6lE9-0005i7-Io
	for xen-devel@lists.xen.org; Sat, 16 Feb 2013 17:07:05 +0000
Received: from [85.158.138.51:53427] by server-3.bemta-3.messagelabs.com id
	DE/F5-31070-8BCBF115; Sat, 16 Feb 2013 17:07:04 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361034422!27734400!1
X-Originating-IP: [209.85.216.169]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30427 invoked from network); 16 Feb 2013 17:07:03 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 17:07:03 -0000
Received: by mail-qc0-f169.google.com with SMTP id t2so1602785qcq.28
	for <xen-devel@lists.xen.org>; Sat, 16 Feb 2013 09:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=7G5F4dFggfpWT4pci4cdimkRD4B2rPK+MayHfD4/Lh4=;
	b=pTgF4/UIlE2xnx9vZQM6HfmuZDO7Gzm4+yWrZmrEuTAfcsZD7HLpTFVafWejORV1TV
	szCy+7dU9NrWAr4Gp7nAkwvXG+3BKTMk1fHkwlW1B131TfBDTbNFpvDd9Dkyc0a3ycKu
	6ydubZ5IDospCTfk5mNmOuccUK9KfTkGsTVWtGFyMWebfDswynekEo3w1qo1EYJmwhwy
	7dd4EGdCWKi92DRX440oftMeEag0DfGIrfh14af4BQQwlAMETPvVjSzzDISnSYKkNK2p
	ITNwX9pX8K/JkVEtGgo4GDqD3WPyntfASvt82hMIyWWxJZwA2vzju4ZD8wlu29rwnsS0
	2O0A==
MIME-Version: 1.0
X-Received: by 10.49.120.225 with SMTP id lf1mr2580978qeb.14.1361034422624;
	Sat, 16 Feb 2013 09:07:02 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Sat, 16 Feb 2013 09:07:02 -0800 (PST)
In-Reply-To: <7839105284694601472@unknownmsgid>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
	<20130212215655.GA18127@phenom.dumpdata.com>
	<511B5C8402000078000BDE5A@nat28.tlf.novell.com>
	<7839105284694601472@unknownmsgid>
Date: Sat, 16 Feb 2013 18:07:02 +0100
Message-ID: <CAKbSZ9Y-Eh4uwJY-nEz2xPhKZ=3U6McMG9X5-eYMTBivF-nTcQ@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Ben Guthro <ben.guthro@gmail.com>
X-Mailman-Approved-At: Sun, 17 Feb 2013 10:10:48 +0000
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============6541251607456549726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6541251607456549726==
Content-Type: multipart/alternative; boundary=047d7bea3e2649a18904d5da85b3

--047d7bea3e2649a18904d5da85b3
Content-Type: text/plain; charset=ISO-8859-1

Still not working. I tried it only using tty without X, without KMS
drivers(nomodeset in kernel parameters and with module i915 removed) and
with and without dom0_pin_vcpus parameter. No success.
Strangely, I remember it used to work with some earlier version of kernel
and/or Xen (unfortunately I can't remember which combination of Xen and
kernel it was)

--047d7bea3e2649a18904d5da85b3
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><div>Still not working. I tried it only using tty without X, without KMS drivers(nomodeset in kernel parameters and with module i915 removed) and with and without dom0_pin_vcpus parameter. No success.<br></div>
Strangely, I remember it used to work with some earlier version of kernel and/or Xen (unfortunately I can&#39;t remember which combination of Xen and kernel it was)<br></div>

--047d7bea3e2649a18904d5da85b3--


--===============6541251607456549726==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6541251607456549726==--


From xen-devel-bounces@lists.xen.org Sun Feb 17 10:11:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 10:11: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 1U71Cr-0002tI-Fb; Sun, 17 Feb 2013 10:10:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <milan.opath@gmail.com>) id 1U6lE9-0005i7-Io
	for xen-devel@lists.xen.org; Sat, 16 Feb 2013 17:07:05 +0000
Received: from [85.158.138.51:53427] by server-3.bemta-3.messagelabs.com id
	DE/F5-31070-8BCBF115; Sat, 16 Feb 2013 17:07:04 +0000
X-Env-Sender: milan.opath@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361034422!27734400!1
X-Originating-IP: [209.85.216.169]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30427 invoked from network); 16 Feb 2013 17:07:03 -0000
Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com)
	(209.85.216.169)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Feb 2013 17:07:03 -0000
Received: by mail-qc0-f169.google.com with SMTP id t2so1602785qcq.28
	for <xen-devel@lists.xen.org>; Sat, 16 Feb 2013 09:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=7G5F4dFggfpWT4pci4cdimkRD4B2rPK+MayHfD4/Lh4=;
	b=pTgF4/UIlE2xnx9vZQM6HfmuZDO7Gzm4+yWrZmrEuTAfcsZD7HLpTFVafWejORV1TV
	szCy+7dU9NrWAr4Gp7nAkwvXG+3BKTMk1fHkwlW1B131TfBDTbNFpvDd9Dkyc0a3ycKu
	6ydubZ5IDospCTfk5mNmOuccUK9KfTkGsTVWtGFyMWebfDswynekEo3w1qo1EYJmwhwy
	7dd4EGdCWKi92DRX440oftMeEag0DfGIrfh14af4BQQwlAMETPvVjSzzDISnSYKkNK2p
	ITNwX9pX8K/JkVEtGgo4GDqD3WPyntfASvt82hMIyWWxJZwA2vzju4ZD8wlu29rwnsS0
	2O0A==
MIME-Version: 1.0
X-Received: by 10.49.120.225 with SMTP id lf1mr2580978qeb.14.1361034422624;
	Sat, 16 Feb 2013 09:07:02 -0800 (PST)
Received: by 10.49.94.78 with HTTP; Sat, 16 Feb 2013 09:07:02 -0800 (PST)
In-Reply-To: <7839105284694601472@unknownmsgid>
References: <CAKbSZ9aGO+ADCZhXpA1r+H27Jr1ivK9rJ=z6b5omDwGuLDirHw@mail.gmail.com>
	<CAOvdn6UbfeMu1Rxrjor6SaEqAsjUfA8o3K=F+Hkps4z8rwDcYQ@mail.gmail.com>
	<510F91CA02000078000BB6AA@nat28.tlf.novell.com>
	<510F885B.2040603@citrix.com>
	<20130205183236.GB5652@konrad-lan.dumpdata.com>
	<5114CF55.5000303@citrix.com>
	<CACJDEmo4CMhRdYaVPwz01DS37z+_BMo+NbS2cSCKa-YRUAfxUA@mail.gmail.com>
	<CAKbSZ9b2e93mkUdfR4gborSdwrs03L0+_Pssi+KhzjYJ89qCWg@mail.gmail.com>
	<20130212200203.GR3016@phenom.dumpdata.com>
	<CAKbSZ9aDLkQmAiM0+sffwweLeaxbnsOxsUg9A7Qw-DKApLDYaA@mail.gmail.com>
	<20130212215655.GA18127@phenom.dumpdata.com>
	<511B5C8402000078000BDE5A@nat28.tlf.novell.com>
	<7839105284694601472@unknownmsgid>
Date: Sat, 16 Feb 2013 18:07:02 +0100
Message-ID: <CAKbSZ9Y-Eh4uwJY-nEz2xPhKZ=3U6McMG9X5-eYMTBivF-nTcQ@mail.gmail.com>
From: Milan opath <milan.opath@gmail.com>
To: Ben Guthro <ben.guthro@gmail.com>
X-Mailman-Approved-At: Sun, 17 Feb 2013 10:10:48 +0000
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
Subject: Re: [Xen-devel] resume from S3 sleep not working in Dom0 - Xen4.2.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: multipart/mixed; boundary="===============6541251607456549726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6541251607456549726==
Content-Type: multipart/alternative; boundary=047d7bea3e2649a18904d5da85b3

--047d7bea3e2649a18904d5da85b3
Content-Type: text/plain; charset=ISO-8859-1

Still not working. I tried it only using tty without X, without KMS
drivers(nomodeset in kernel parameters and with module i915 removed) and
with and without dom0_pin_vcpus parameter. No success.
Strangely, I remember it used to work with some earlier version of kernel
and/or Xen (unfortunately I can't remember which combination of Xen and
kernel it was)

--047d7bea3e2649a18904d5da85b3
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><div>Still not working. I tried it only using tty without X, without KMS drivers(nomodeset in kernel parameters and with module i915 removed) and with and without dom0_pin_vcpus parameter. No success.<br></div>
Strangely, I remember it used to work with some earlier version of kernel and/or Xen (unfortunately I can&#39;t remember which combination of Xen and kernel it was)<br></div>

--047d7bea3e2649a18904d5da85b3--


--===============6541251607456549726==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6541251607456549726==--


From xen-devel-bounces@lists.xen.org Sun Feb 17 14:02:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 14:02: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 1U74o8-0006m2-B9; Sun, 17 Feb 2013 14:01:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1U74o7-0006jx-Eu
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 14:01:31 +0000
Received: from [85.158.143.99:34555] by server-2.bemta-4.messagelabs.com id
	85/85-01597-AB2E0215; Sun, 17 Feb 2013 14:01:30 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361109690!26959159!1
X-Originating-IP: [212.160.235.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20628 invoked from network); 17 Feb 2013 14:01:30 -0000
Received: from hydra.sisk.pl (HELO hydra.sisk.pl) (212.160.235.94)
	by server-13.tower-216.messagelabs.com with SMTP;
	17 Feb 2013 14:01:30 -0000
Received: from vostro.rjw.lan (afav7.neoplus.adsl.tpnet.pl [95.49.21.7])
	by hydra.sisk.pl (Postfix) with ESMTPSA id 8FCEBE3DA6;
	Sun, 17 Feb 2013 15:01:12 +0100 (CET)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Date: Sun, 17 Feb 2013 15:08:02 +0100
Message-ID: <4696812.SKkpQQd9iW@vostro.rjw.lan>
User-Agent: KMail/4.9.5 (Linux/3.8.0-rc7; KDE/4.9.5; x86_64; ; )
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
	<DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, February 17, 2013 07:31:37 AM Liu, Jinsong wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
> >> Hi Rafael,
> > 
> > Hi,
> > 
> >> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
> >> wrote: 
> >>> 
> >>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
> >>>> 
> >>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
> >>>> <konrad.wilk@oracle.com> wrote: 
> >>>>> 
> >>>>> Thank you. I keep on forgetting - but would it be OK for me to
> >>>>> take this patch in my tree? Or should I not since this is a new
> >>>>> functionality that Rafael is going to introduce in v3.9?
> >>>> 
> >>>> It is an API change in the pm tree that is not yet in Linus' tree.
> >>>> 
> >>>>> And if so, perhaps I should tack it on in my tree, once Rafael
> >>>>> does a git pull to Linus? Or just point Linus to this git commit?
> >>>> 
> >>>> You should point Linus at this patch if the pm tree is merged
> >>>> first, or 
> >>>> Rafael should do the same if the reverse happens.
> >>> 
> >>> Alternatively, Konrad can pull the acpi-scan branch containing the
> >>> changes in question from my tree into his tree and rebase the new
> >>> material on top of that.
> >> 
> >> Or pull the acpi-scan branch into his tree and use my conflict
> >> resolution in the resulting merge thus requiring no rebasing. 
> >> However, Linus likes to see such interactions, so it can be left up
> >> to when the latter of the two tress is merged by Linus.
> > 
> > Well, I'm afraid this won't be sufficient this time, because of this
> > commit in my tree (which is not on the acpi-scan branch):
> > 
> > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Wed Feb 13 14:36:47 2013 +0100
> > 
> >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > 
> > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > acpi_scan_lock (new in my tree as well).
> 
> Yes, we noticed that and only need minor updates at xen side, will send out
> 2 xen patches later accordingly, for cleanup and adding lock.

Thanks, but those new changes will only make sense after merging the Xen tree
with the PM tree.  Why don't we queue them up for merging later after both
the Xen and PM trees have been pulled from?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 14:02:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 14:02: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 1U74o8-0006m2-B9; Sun, 17 Feb 2013 14:01:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1U74o7-0006jx-Eu
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 14:01:31 +0000
Received: from [85.158.143.99:34555] by server-2.bemta-4.messagelabs.com id
	85/85-01597-AB2E0215; Sun, 17 Feb 2013 14:01:30 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361109690!26959159!1
X-Originating-IP: [212.160.235.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20628 invoked from network); 17 Feb 2013 14:01:30 -0000
Received: from hydra.sisk.pl (HELO hydra.sisk.pl) (212.160.235.94)
	by server-13.tower-216.messagelabs.com with SMTP;
	17 Feb 2013 14:01:30 -0000
Received: from vostro.rjw.lan (afav7.neoplus.adsl.tpnet.pl [95.49.21.7])
	by hydra.sisk.pl (Postfix) with ESMTPSA id 8FCEBE3DA6;
	Sun, 17 Feb 2013 15:01:12 +0100 (CET)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Date: Sun, 17 Feb 2013 15:08:02 +0100
Message-ID: <4696812.SKkpQQd9iW@vostro.rjw.lan>
User-Agent: KMail/4.9.5 (Linux/3.8.0-rc7; KDE/4.9.5; x86_64; ; )
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
	<DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, February 17, 2013 07:31:37 AM Liu, Jinsong wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
> >> Hi Rafael,
> > 
> > Hi,
> > 
> >> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
> >> wrote: 
> >>> 
> >>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
> >>>> 
> >>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
> >>>> <konrad.wilk@oracle.com> wrote: 
> >>>>> 
> >>>>> Thank you. I keep on forgetting - but would it be OK for me to
> >>>>> take this patch in my tree? Or should I not since this is a new
> >>>>> functionality that Rafael is going to introduce in v3.9?
> >>>> 
> >>>> It is an API change in the pm tree that is not yet in Linus' tree.
> >>>> 
> >>>>> And if so, perhaps I should tack it on in my tree, once Rafael
> >>>>> does a git pull to Linus? Or just point Linus to this git commit?
> >>>> 
> >>>> You should point Linus at this patch if the pm tree is merged
> >>>> first, or 
> >>>> Rafael should do the same if the reverse happens.
> >>> 
> >>> Alternatively, Konrad can pull the acpi-scan branch containing the
> >>> changes in question from my tree into his tree and rebase the new
> >>> material on top of that.
> >> 
> >> Or pull the acpi-scan branch into his tree and use my conflict
> >> resolution in the resulting merge thus requiring no rebasing. 
> >> However, Linus likes to see such interactions, so it can be left up
> >> to when the latter of the two tress is merged by Linus.
> > 
> > Well, I'm afraid this won't be sufficient this time, because of this
> > commit in my tree (which is not on the acpi-scan branch):
> > 
> > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Wed Feb 13 14:36:47 2013 +0100
> > 
> >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > 
> > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > acpi_scan_lock (new in my tree as well).
> 
> Yes, we noticed that and only need minor updates at xen side, will send out
> 2 xen patches later accordingly, for cleanup and adding lock.

Thanks, but those new changes will only make sense after merging the Xen tree
with the PM tree.  Why don't we queue them up for merging later after both
the Xen and PM trees have been pulled from?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 14:31:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 14: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 1U75GK-0007CZ-2p; Sun, 17 Feb 2013 14:30:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darren.s.shepherd@gmail.com>) id 1U75GJ-0007CP-2K
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 14:30:39 +0000
Received: from [85.158.143.35:43597] by server-2.bemta-4.messagelabs.com id
	C2/FB-01597-E89E0215; Sun, 17 Feb 2013 14:30:38 +0000
X-Env-Sender: darren.s.shepherd@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1361111435!13442250!1
X-Originating-IP: [209.85.217.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21610 invoked from network); 17 Feb 2013 14:30:36 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2013 14:30:36 -0000
Received: by mail-lb0-f178.google.com with SMTP id n1so3688375lba.37
	for <xen-devel@lists.xen.org>; Sun, 17 Feb 2013 06:30:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=xfcVRZ8rx7HAX/IDE1CcLHMuTRrs/j5ocGKh9MtF1zw=;
	b=U6UiGTKiMCM/IslZgjXI/whGzUHuIh2FaUq6WabHLyZ4LonUkx/H7o37butbF6VVkw
	GscOid4Fs3AmYCewWLhBquONNXx5z5aMoEd+YqxPcIer7cRTKkCQbhqJYUcG3VKiYHA1
	tYdyZjoM2iOVf1gqCgLQE2n4CDzvSfZJKqME4n9+mP9HzPZJsGHTFdZV3blzOfH+yESk
	ixHghczeZWhQ0oyZrsVHPJIg2uWbjSn8fydOm8GDAyd66Gk1HtZUZWnLQRwO+7TvJh7m
	y85MtX4HD1kBh1BD3TOvrNuCaPHCfr+CAHwxfK/8bk/RGHx5/fq1J2W+co6O2hjZi2UO
	YZow==
MIME-Version: 1.0
X-Received: by 10.152.132.36 with SMTP id or4mr6209811lab.8.1361111435335;
	Sun, 17 Feb 2013 06:30:35 -0800 (PST)
Received: by 10.112.118.42 with HTTP; Sun, 17 Feb 2013 06:30:35 -0800 (PST)
Date: Sun, 17 Feb 2013 07:30:35 -0700
Message-ID: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
From: Darren Shepherd <darren.s.shepherd@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wondering if someone can shed some light on why vhd files
created with qemu-img don't really work right with vhd-util and
consequentially blktap in general.  To validate the incompatiblity its
simple enough to do

qemu-img create -f vpc test.vhd 40g
vhd-util snapshot -n child.vhd -p test.vhd

Which will show the below and then the headers don't display the BATMAP summary:

primary footer invalid: creation time in future
test.vhd appears invalid; dumping metadata
Failed to open test.vhd: -22

Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
you the same 22 error.

I was going to start researching this with the eventual goal of
changing qemu-img, but I thought I'd ask the experts first.

Thanks,
Darren

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 14:31:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 14: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 1U75GK-0007CZ-2p; Sun, 17 Feb 2013 14:30:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darren.s.shepherd@gmail.com>) id 1U75GJ-0007CP-2K
	for xen-devel@lists.xen.org; Sun, 17 Feb 2013 14:30:39 +0000
Received: from [85.158.143.35:43597] by server-2.bemta-4.messagelabs.com id
	C2/FB-01597-E89E0215; Sun, 17 Feb 2013 14:30:38 +0000
X-Env-Sender: darren.s.shepherd@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1361111435!13442250!1
X-Originating-IP: [209.85.217.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21610 invoked from network); 17 Feb 2013 14:30:36 -0000
Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com)
	(209.85.217.178)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Feb 2013 14:30:36 -0000
Received: by mail-lb0-f178.google.com with SMTP id n1so3688375lba.37
	for <xen-devel@lists.xen.org>; Sun, 17 Feb 2013 06:30:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=xfcVRZ8rx7HAX/IDE1CcLHMuTRrs/j5ocGKh9MtF1zw=;
	b=U6UiGTKiMCM/IslZgjXI/whGzUHuIh2FaUq6WabHLyZ4LonUkx/H7o37butbF6VVkw
	GscOid4Fs3AmYCewWLhBquONNXx5z5aMoEd+YqxPcIer7cRTKkCQbhqJYUcG3VKiYHA1
	tYdyZjoM2iOVf1gqCgLQE2n4CDzvSfZJKqME4n9+mP9HzPZJsGHTFdZV3blzOfH+yESk
	ixHghczeZWhQ0oyZrsVHPJIg2uWbjSn8fydOm8GDAyd66Gk1HtZUZWnLQRwO+7TvJh7m
	y85MtX4HD1kBh1BD3TOvrNuCaPHCfr+CAHwxfK/8bk/RGHx5/fq1J2W+co6O2hjZi2UO
	YZow==
MIME-Version: 1.0
X-Received: by 10.152.132.36 with SMTP id or4mr6209811lab.8.1361111435335;
	Sun, 17 Feb 2013 06:30:35 -0800 (PST)
Received: by 10.112.118.42 with HTTP; Sun, 17 Feb 2013 06:30:35 -0800 (PST)
Date: Sun, 17 Feb 2013 07:30:35 -0700
Message-ID: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
From: Darren Shepherd <darren.s.shepherd@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wondering if someone can shed some light on why vhd files
created with qemu-img don't really work right with vhd-util and
consequentially blktap in general.  To validate the incompatiblity its
simple enough to do

qemu-img create -f vpc test.vhd 40g
vhd-util snapshot -n child.vhd -p test.vhd

Which will show the below and then the headers don't display the BATMAP summary:

primary footer invalid: creation time in future
test.vhd appears invalid; dumping metadata
Failed to open test.vhd: -22

Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
you the same 22 error.

I was going to start researching this with the eventual goal of
changing qemu-img, but I thought I'd ask the experts first.

Thanks,
Darren

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 17 19:14:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 19: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 1U79fp-00056e-Hh; Sun, 17 Feb 2013 19:13:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben@decadent.org.uk>) id 1U79fn-00056R-Qv
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 19:13:16 +0000
Received: from [193.109.254.147:55334] by server-14.bemta-14.messagelabs.com
	id F4/EE-02031-BCB21215; Sun, 17 Feb 2013 19:13:15 +0000
X-Env-Sender: ben@decadent.org.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361128391!8705597!1
X-Originating-IP: [88.96.1.126]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18665 invoked from network); 17 Feb 2013 19:13:12 -0000
Received: from shadbolt.e.decadent.org.uk (HELO shadbolt.e.decadent.org.uk)
	(88.96.1.126)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2013 19:13:12 -0000
Received: from [2001:470:1f08:1539:a11:96ff:fec6:70c4]
	(helo=deadeye.wl.decadent.org.uk)
	by shadbolt.decadent.org.uk with esmtps
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ben@decadent.org.uk>)
	id 1U79fZ-0006Op-Kd; Sun, 17 Feb 2013 19:13:01 +0000
Received: from ben by deadeye.wl.decadent.org.uk with local (Exim 4.80)
	(envelope-from <ben@decadent.org.uk>)
	id 1U79fY-0000oa-Ex; Sun, 17 Feb 2013 19:13:00 +0000
Message-ID: <1361128380.5374.483.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sun, 17 Feb 2013 19:13:00 +0000
In-Reply-To: <20130214225544.GA8068@phenom.dumpdata.com>
References: <20130214215216.GA18740@kroah.com>
	<20130214225544.GA8068@phenom.dumpdata.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 2001:470:1f08:1539:a11:96ff:fec6:70c4
X-SA-Exim-Mail-From: ben@decadent.org.uk
X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk);
	SAEximRunCond expanded to false
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Jan Beulich <JBeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6824682382432337787=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6824682382432337787==
Content-Type: multipart/signed; micalg="pgp-sha512";
	protocol="application/pgp-signature"; boundary="=-LjVZHGFQIQL7m4ze19cP"


--=-LjVZHGFQIQL7m4ze19cP
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 17:55 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 14, 2013 at 01:52:16PM -0800, Greg KH wrote:
> > Jan, any reason why this patch isn't in Linus's tree already, and why i=
t
>=20
> Sent out the GIT PULL this week to Linus
> > wasn't marked for inclusion in a -stable kernel release?
>=20
> I forgot to stick that. Do please include it in the stable tree.
[...]

I've queued this up for 3.2.

Ben.

--=20
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones=
.

--=-LjVZHGFQIQL7m4ze19cP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUAUSErvOe/yOyVhhEJAQp3rg//XsyaxtD3UuiqqUmuBo37oI2Oryxnsg4W
JpeFQ1LZUGAkwK9LsW1rbjWhfENINyU540il0heBhqCewrQ29O7T9eBKGxrXJdVC
we5Euc+ldJaHzFk5Q50et56fLSsZcBdQJjqhqqZHu275tX6DdvJcgSGZwr+NH/0n
LEu9GoOxBbGgwsl3k5eRVwZaXewpFQ/ks6lwOdSzk18HVBJi1j0gzP99D3GewNhO
nfhu7ijC550nMC2o0Hc2txvR6r1O4V0Bw7FvIrKCMgkCYE9jjLaMSo8xlwftXW6W
RA7hwiEQVvKcvV+bRE+v4MHynhfkgBLO9uU44jsCKVn4NdnqshwIQlPJIRjKfJyr
xPtPGeRFUwW8EeUEUGTPbio5gY7t2/P8x5Qnu7CQkzhUY8Wefsn25XsoP7oJtnq9
BgdM53QEPYFHRJZ0NLOv3mVXwkUC3JQoPkPGd8F4GXl7BKvkEC1B0N0GSKbD3Y/c
Ti0KKUsMl7i96iAD/Sz0xa0y+Cfxm+diomkX8KDFGT4AfuFtbqY003jEVTBe+Y4i
gezn8ybAWFZdcjxgYaZReI+nXgRgivtGbA8X1Xo5qQxMeZlUcDhCY9kxyuqvX/oF
Dr7D8KIkrrySq0cqPa62qRd5Bgvc0M2iSojmhpYvW60GqqfcH8qS9WV6XDmBu4ZB
8fXbVTgiIso=
=K2T+
-----END PGP SIGNATURE-----

--=-LjVZHGFQIQL7m4ze19cP--


--===============6824682382432337787==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6824682382432337787==--


From xen-devel-bounces@lists.xen.org Sun Feb 17 19:14:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 17 Feb 2013 19: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 1U79fp-00056e-Hh; Sun, 17 Feb 2013 19:13:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben@decadent.org.uk>) id 1U79fn-00056R-Qv
	for xen-devel@lists.xensource.com; Sun, 17 Feb 2013 19:13:16 +0000
Received: from [193.109.254.147:55334] by server-14.bemta-14.messagelabs.com
	id F4/EE-02031-BCB21215; Sun, 17 Feb 2013 19:13:15 +0000
X-Env-Sender: ben@decadent.org.uk
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361128391!8705597!1
X-Originating-IP: [88.96.1.126]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18665 invoked from network); 17 Feb 2013 19:13:12 -0000
Received: from shadbolt.e.decadent.org.uk (HELO shadbolt.e.decadent.org.uk)
	(88.96.1.126)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Feb 2013 19:13:12 -0000
Received: from [2001:470:1f08:1539:a11:96ff:fec6:70c4]
	(helo=deadeye.wl.decadent.org.uk)
	by shadbolt.decadent.org.uk with esmtps
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72)
	(envelope-from <ben@decadent.org.uk>)
	id 1U79fZ-0006Op-Kd; Sun, 17 Feb 2013 19:13:01 +0000
Received: from ben by deadeye.wl.decadent.org.uk with local (Exim 4.80)
	(envelope-from <ben@decadent.org.uk>)
	id 1U79fY-0000oa-Ex; Sun, 17 Feb 2013 19:13:00 +0000
Message-ID: <1361128380.5374.483.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Sun, 17 Feb 2013 19:13:00 +0000
In-Reply-To: <20130214225544.GA8068@phenom.dumpdata.com>
References: <20130214215216.GA18740@kroah.com>
	<20130214225544.GA8068@phenom.dumpdata.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 2001:470:1f08:1539:a11:96ff:fec6:70c4
X-SA-Exim-Mail-From: ben@decadent.org.uk
X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk);
	SAEximRunCond expanded to false
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Petr Matousek <pmatouse@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>, stable@vger.kernel.org,
	virtualization@lists.linux-foundation.org, Jan Beulich <JBeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/xen: don't assume %ds is usable in
 xen_iret for 32-bit PVOPS.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6824682382432337787=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6824682382432337787==
Content-Type: multipart/signed; micalg="pgp-sha512";
	protocol="application/pgp-signature"; boundary="=-LjVZHGFQIQL7m4ze19cP"


--=-LjVZHGFQIQL7m4ze19cP
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-14 at 17:55 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 14, 2013 at 01:52:16PM -0800, Greg KH wrote:
> > Jan, any reason why this patch isn't in Linus's tree already, and why i=
t
>=20
> Sent out the GIT PULL this week to Linus
> > wasn't marked for inclusion in a -stable kernel release?
>=20
> I forgot to stick that. Do please include it in the stable tree.
[...]

I've queued this up for 3.2.

Ben.

--=20
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones=
.

--=-LjVZHGFQIQL7m4ze19cP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUAUSErvOe/yOyVhhEJAQp3rg//XsyaxtD3UuiqqUmuBo37oI2Oryxnsg4W
JpeFQ1LZUGAkwK9LsW1rbjWhfENINyU540il0heBhqCewrQ29O7T9eBKGxrXJdVC
we5Euc+ldJaHzFk5Q50et56fLSsZcBdQJjqhqqZHu275tX6DdvJcgSGZwr+NH/0n
LEu9GoOxBbGgwsl3k5eRVwZaXewpFQ/ks6lwOdSzk18HVBJi1j0gzP99D3GewNhO
nfhu7ijC550nMC2o0Hc2txvR6r1O4V0Bw7FvIrKCMgkCYE9jjLaMSo8xlwftXW6W
RA7hwiEQVvKcvV+bRE+v4MHynhfkgBLO9uU44jsCKVn4NdnqshwIQlPJIRjKfJyr
xPtPGeRFUwW8EeUEUGTPbio5gY7t2/P8x5Qnu7CQkzhUY8Wefsn25XsoP7oJtnq9
BgdM53QEPYFHRJZ0NLOv3mVXwkUC3JQoPkPGd8F4GXl7BKvkEC1B0N0GSKbD3Y/c
Ti0KKUsMl7i96iAD/Sz0xa0y+Cfxm+diomkX8KDFGT4AfuFtbqY003jEVTBe+Y4i
gezn8ybAWFZdcjxgYaZReI+nXgRgivtGbA8X1Xo5qQxMeZlUcDhCY9kxyuqvX/oF
Dr7D8KIkrrySq0cqPa62qRd5Bgvc0M2iSojmhpYvW60GqqfcH8qS9WV6XDmBu4ZB
8fXbVTgiIso=
=K2T+
-----END PGP SIGNATURE-----

--=-LjVZHGFQIQL7m4ze19cP--


--===============6824682382432337787==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6824682382432337787==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 01:16:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 01: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 1U7FKc-0003zY-AU; Mon, 18 Feb 2013 01:15:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U7FKa-0003zR-G1
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 01:15:44 +0000
Received: from [193.109.254.147:61267] by server-2.bemta-14.messagelabs.com id
	7E/52-16277-FB081215; Mon, 18 Feb 2013 01:15:43 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361150139!1904408!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31807 invoked from network); 18 Feb 2013 01:15:42 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-11.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 01:15:42 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U7FKR-0006uX-6b
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 12:15:36 +1100
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 id
	14.01.0438.000; Mon, 18 Feb 2013 12:15:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: where does uuid in xenstore come from for block device
Thread-Index: Ac4NdIltZwsMdAyLRsmCEpOLsw803g==
Date: Mon, 18 Feb 2013 01:15:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567DD3D@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19644.003
x-tm-as-result: No--28.138800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] where does uuid in xenstore come from for block 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

Where does the xenstore /local/domain/<device dom>/backend/vbd/<domu>/<vbd device>/uuid come from?

In my case /local/domain/0/backend/vbd/335/51712/uuid = bdc23468-1ea6-f395-8ef0-67e45cb59009 and the corresponding lv uuid is k6HeO6-utKp-3mop-aaBp-vB4n-ykuI-Beptm6 but the latter is not a conventionally expressed UUID and at least as base64 doesn't match the xentore uuid...

I'm looking for something to tell Windows is a unique identifier for the disk

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 01:16:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 01: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 1U7FKc-0003zY-AU; Mon, 18 Feb 2013 01:15:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U7FKa-0003zR-G1
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 01:15:44 +0000
Received: from [193.109.254.147:61267] by server-2.bemta-14.messagelabs.com id
	7E/52-16277-FB081215; Mon, 18 Feb 2013 01:15:43 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361150139!1904408!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31807 invoked from network); 18 Feb 2013 01:15:42 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-11.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 01:15:42 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U7FKR-0006uX-6b
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 12:15:36 +1100
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 id
	14.01.0438.000; Mon, 18 Feb 2013 12:15:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: where does uuid in xenstore come from for block device
Thread-Index: Ac4NdIltZwsMdAyLRsmCEpOLsw803g==
Date: Mon, 18 Feb 2013 01:15:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567DD3D@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19644.003
x-tm-as-result: No--28.138800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] where does uuid in xenstore come from for block 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

Where does the xenstore /local/domain/<device dom>/backend/vbd/<domu>/<vbd device>/uuid come from?

In my case /local/domain/0/backend/vbd/335/51712/uuid = bdc23468-1ea6-f395-8ef0-67e45cb59009 and the corresponding lv uuid is k6HeO6-utKp-3mop-aaBp-vB4n-ykuI-Beptm6 but the latter is not a conventionally expressed UUID and at least as base64 doesn't match the xentore uuid...

I'm looking for something to tell Windows is a unique identifier for the disk

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 07:39:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 07:39: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 1U7LJ8-00083y-9T; Mon, 18 Feb 2013 07:38:38 +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 1U7LJ6-00083r-Iq
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 07:38:36 +0000
Received: from [85.158.143.35:11172] by server-1.bemta-4.messagelabs.com id
	09/5B-08839-B7AD1215; Mon, 18 Feb 2013 07:38:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1361173080!5036727!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2419 invoked from network); 18 Feb 2013 07:38:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 07:38:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,684,1355097600"; 
   d="scan'208";a="1556702"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 07:38:01 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Mon, 18 Feb 2013 07:38:00 +0000
Message-ID: <5121DA78.2000708@citrix.com>
Date: Mon, 18 Feb 2013 08:38:32 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de> <511D000C.9030908@citrix.com>
	<511E40D8.5070603@hosteurope.de>
In-Reply-To: <511E40D8.5070603@hosteurope.de>
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTUvMDIvMTMgMTU6MDYsIFVsZiBLcmV1dHpiZXJnIHdyb3RlOgo+IEhlbGxvIFJvZ2VyLAo+
IGhlbGxvIGV2ZXJ5Ym9keSwKPiAKPiBzb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuCj4gCj4gT24g
MTQuMDIuMjAxMyAxNjoxNywgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4gQ291bGQgeW91IHRh
a2UgYSBsb29rIGF0IHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbD8KPj4KPj4gWW91IHNob3Vs
ZCBoYXZlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgY2h1bms6Cj4+Cj4+IGxpYnhsX2Rl
dmljZV9uaWMgPSBTdHJ1Y3QoImRldmljZV9uaWMiLCBbCj4+ICAgICAoImJhY2tlbmRfZG9taWQi
LCBsaWJ4bF9kb21pZCksCj4+ICAgICAoImRldmlkIiwgbGlieGxfZGV2aWQpLAo+PiAgICAgKCJt
dHUiLCBpbnRlZ2VyKSwKPj4gICAgICgibW9kZWwiLCBzdHJpbmcpLAo+PiAgICAgKCJtYWMiLCBs
aWJ4bF9tYWMpLAo+PiAgICAgKCJpcCIsIHN0cmluZyksCj4+ICAgICAoImJyaWRnZSIsIHN0cmlu
ZyksCj4+ICAgICAoImlmbmFtZSIsIHN0cmluZyksCj4+ICAgICAoInNjcmlwdCIsIHN0cmluZyks
Cj4+ICAgICAoIm5pY3R5cGUiLCBsaWJ4bF9uaWNfdHlwZSksCj4+ICAgICAoInJhdGVfYnl0ZXNf
cGVyX2ludGVydmFsIiwgdWludDY0KSwKPj4gICAgICgicmF0ZV9pbnRlcnZhbF91c2VjcyIsIHVp
bnQzMiksCj4+ICAgICAoImdhdGV3YXlkZXYiLCBzdHJpbmcpLAo+PiAgICAgXSkKPj4KPj4gKFdp
dGggb25seSBvbmUgImdhdGV3YXlkZXYiKS4KPj4KPiBUaGF0IHdhcyBteSBjb3B5J24ncGFzdGUg
bWlzdGFrZSAtIGZpeGVkLgo+IAo+IEkgY291bGQgc2VlIHRoYXQgYWZ0ZXIgYXBwbHlpbmcgcGF0
Y2hlcyBWMSB0aGUgcGFyYW1ldGVyICJuZXRkZXYiIGlzCj4gcGFyc2VkIGNvcnJlY3RseSBhbmQg
dGhlIG1haW4gaXAgaXMgcGFzc2VkIHRvIHhlbiBzY3JpcHRzLgo+IEhvd2V2ZXIsIEkgY291bGQg
bm90IGdldCB4ZW4gNC4zIHJ1bm5pbmcgc28gSSBoYWQgdG8gdGVzdCA0LjMgdG9vbHMgb24KPiA0
LjIuMSBoeXBlcnZpc29yLCB3aGljaCBjb3VsZCBub3Qgc3RhcnQgdGhlIGRvbVUsIGJ1dCBkZWJ1
ZyBvdXRwdXQgb2YKPiB0aGUgc2NyaXB0cyBzaG93ZWQgbWUgZXZlcnl0aGluZyBpcyBwYXJzZWQg
YXMgZXhwZWN0ZWQuCj4gCj4gVGhlIG1hYyBhZGRyZXNzIHN0aWxsIGlzIG5vdCBwYXJzZWQgaWYg
ZGlnaXRzIGFyZSBub3QgcGFkZGVkIHdpdGgKPiBsZWFkaW5nIHplcm8sIGxpa2UgIm1hYz1kZTph
ZDphOjFlOjQyOjMiIC0gdGhlIHJlc3Qgb2YgdGhlIGxpbmUgaXMKPiBpZ25vcmVkIHdpdGhvdXQg
YW55IGVycm9yLgo+IAo+IEhvd2V2ZXIsIEkgd2FzIG5vdCBhYmxlIHRvIGFwcGx5IHBhdGNoZXMg
VjIgYWZ0ZXIgdGhhdCwgdGhleSBkbyBub3Qgc2VlbQo+IHRvIHdvcmsgdG9nZXRoZXIgd2l0aCB0
aGUgZmlyc3QgcGF0Y2ggc2VyaWVzLgoKSGVsbG8gVWxmLAoKVmVyc2lvbiB2MiBzaG91bGQgYmUg
YXBwbGllZCB3aXRob3V0IHYxLCB0aGV5IGFyZSBub3QgYWRkaXRpb25hbApwYXRjaGVzLCBpdCdz
IGEgcmV2aXNpb24gb2YgdGhlIHNhbWUgcGF0Y2hlcyAodHJ5aW5nIHRvIGFwcGx5IGJvdGggd2ls
bApsZWFkIHRvIGVycm9ycykuIFRvIHNpbXBsaWZ5IGl0IEkndmUgcHVzaGVkIHRoZSBwYXRjaGVz
IHRvIG15IGdpdCByZXBvLApzbyB5b3UgY2FuIGZldGNoIHRoZW0gZWFzaWx5OgoKJCBnaXQgY2xv
bmUgLWIgdmlmX3JvdXRlX3YyIGdpdDovL3hlbmJpdHMueGVuLm9yZy9wZW9wbGUvcm95Z2VyL3hl
bi5naXQKCk1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGJ1aWxkIFhlbiBmcm9tIHNvdXJj
ZSBjYW4gYmUgZm91bmQgYXQKaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL0NvbXBpbGluZ19YZW5f
RnJvbV9Tb3VyY2UjQnVpbGRpbmdfZnJvbV9Tb3VyY2UuCgpIb3BlIHRoaXMgaGVscHMsIFJvZ2Vy
LgoKPiBPbmx5IHBhdGNoaW5nIHdpdGggVjIgcmVzdWx0ZWQgaW4gbWlzc2luZyAibmV0ZGV2IiBt
ZW1iZXIgaW4KPiBsaWJ4bF9kZXZpY2VfbmljIChsaWJ4bF90eXBlcy5pZGwpLiBBZnRlciBlZGl0
aW5nIHRoZSBmaWxlIGFuZCBhZGRpbmcKPiB0aGUgZGVmaW5pdGlvbiwgaXQgY29tcGlsZWQgc28g
ZmFyLgo+IAo+IHhsIHdpdGggb25seSBwYXRjaGVzIFYyIGFwcGxpZWQgZG9lcyBwYXJzZSBuZWl0
aGVyIG5ldGRldiBub3IgZ2F0ZXdheWRldgo+IGFzIGl0IHNlZW1zLgo+IAo+IAo+IEJlc3QgcmVn
YXJkcywKPiBVbGYKPiAKPiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 18 07:39:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 07:39: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 1U7LJ8-00083y-9T; Mon, 18 Feb 2013 07:38:38 +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 1U7LJ6-00083r-Iq
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 07:38:36 +0000
Received: from [85.158.143.35:11172] by server-1.bemta-4.messagelabs.com id
	09/5B-08839-B7AD1215; Mon, 18 Feb 2013 07:38:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1361173080!5036727!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2419 invoked from network); 18 Feb 2013 07:38:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 07:38:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,684,1355097600"; 
   d="scan'208";a="1556702"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 07:38:01 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Mon, 18 Feb 2013 07:38:00 +0000
Message-ID: <5121DA78.2000708@citrix.com>
Date: Mon, 18 Feb 2013 08:38:32 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de> <511D000C.9030908@citrix.com>
	<511E40D8.5070603@hosteurope.de>
In-Reply-To: <511E40D8.5070603@hosteurope.de>
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTUvMDIvMTMgMTU6MDYsIFVsZiBLcmV1dHpiZXJnIHdyb3RlOgo+IEhlbGxvIFJvZ2VyLAo+
IGhlbGxvIGV2ZXJ5Ym9keSwKPiAKPiBzb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuCj4gCj4gT24g
MTQuMDIuMjAxMyAxNjoxNywgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4gQ291bGQgeW91IHRh
a2UgYSBsb29rIGF0IHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbD8KPj4KPj4gWW91IHNob3Vs
ZCBoYXZlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgY2h1bms6Cj4+Cj4+IGxpYnhsX2Rl
dmljZV9uaWMgPSBTdHJ1Y3QoImRldmljZV9uaWMiLCBbCj4+ICAgICAoImJhY2tlbmRfZG9taWQi
LCBsaWJ4bF9kb21pZCksCj4+ICAgICAoImRldmlkIiwgbGlieGxfZGV2aWQpLAo+PiAgICAgKCJt
dHUiLCBpbnRlZ2VyKSwKPj4gICAgICgibW9kZWwiLCBzdHJpbmcpLAo+PiAgICAgKCJtYWMiLCBs
aWJ4bF9tYWMpLAo+PiAgICAgKCJpcCIsIHN0cmluZyksCj4+ICAgICAoImJyaWRnZSIsIHN0cmlu
ZyksCj4+ICAgICAoImlmbmFtZSIsIHN0cmluZyksCj4+ICAgICAoInNjcmlwdCIsIHN0cmluZyks
Cj4+ICAgICAoIm5pY3R5cGUiLCBsaWJ4bF9uaWNfdHlwZSksCj4+ICAgICAoInJhdGVfYnl0ZXNf
cGVyX2ludGVydmFsIiwgdWludDY0KSwKPj4gICAgICgicmF0ZV9pbnRlcnZhbF91c2VjcyIsIHVp
bnQzMiksCj4+ICAgICAoImdhdGV3YXlkZXYiLCBzdHJpbmcpLAo+PiAgICAgXSkKPj4KPj4gKFdp
dGggb25seSBvbmUgImdhdGV3YXlkZXYiKS4KPj4KPiBUaGF0IHdhcyBteSBjb3B5J24ncGFzdGUg
bWlzdGFrZSAtIGZpeGVkLgo+IAo+IEkgY291bGQgc2VlIHRoYXQgYWZ0ZXIgYXBwbHlpbmcgcGF0
Y2hlcyBWMSB0aGUgcGFyYW1ldGVyICJuZXRkZXYiIGlzCj4gcGFyc2VkIGNvcnJlY3RseSBhbmQg
dGhlIG1haW4gaXAgaXMgcGFzc2VkIHRvIHhlbiBzY3JpcHRzLgo+IEhvd2V2ZXIsIEkgY291bGQg
bm90IGdldCB4ZW4gNC4zIHJ1bm5pbmcgc28gSSBoYWQgdG8gdGVzdCA0LjMgdG9vbHMgb24KPiA0
LjIuMSBoeXBlcnZpc29yLCB3aGljaCBjb3VsZCBub3Qgc3RhcnQgdGhlIGRvbVUsIGJ1dCBkZWJ1
ZyBvdXRwdXQgb2YKPiB0aGUgc2NyaXB0cyBzaG93ZWQgbWUgZXZlcnl0aGluZyBpcyBwYXJzZWQg
YXMgZXhwZWN0ZWQuCj4gCj4gVGhlIG1hYyBhZGRyZXNzIHN0aWxsIGlzIG5vdCBwYXJzZWQgaWYg
ZGlnaXRzIGFyZSBub3QgcGFkZGVkIHdpdGgKPiBsZWFkaW5nIHplcm8sIGxpa2UgIm1hYz1kZTph
ZDphOjFlOjQyOjMiIC0gdGhlIHJlc3Qgb2YgdGhlIGxpbmUgaXMKPiBpZ25vcmVkIHdpdGhvdXQg
YW55IGVycm9yLgo+IAo+IEhvd2V2ZXIsIEkgd2FzIG5vdCBhYmxlIHRvIGFwcGx5IHBhdGNoZXMg
VjIgYWZ0ZXIgdGhhdCwgdGhleSBkbyBub3Qgc2VlbQo+IHRvIHdvcmsgdG9nZXRoZXIgd2l0aCB0
aGUgZmlyc3QgcGF0Y2ggc2VyaWVzLgoKSGVsbG8gVWxmLAoKVmVyc2lvbiB2MiBzaG91bGQgYmUg
YXBwbGllZCB3aXRob3V0IHYxLCB0aGV5IGFyZSBub3QgYWRkaXRpb25hbApwYXRjaGVzLCBpdCdz
IGEgcmV2aXNpb24gb2YgdGhlIHNhbWUgcGF0Y2hlcyAodHJ5aW5nIHRvIGFwcGx5IGJvdGggd2ls
bApsZWFkIHRvIGVycm9ycykuIFRvIHNpbXBsaWZ5IGl0IEkndmUgcHVzaGVkIHRoZSBwYXRjaGVz
IHRvIG15IGdpdCByZXBvLApzbyB5b3UgY2FuIGZldGNoIHRoZW0gZWFzaWx5OgoKJCBnaXQgY2xv
bmUgLWIgdmlmX3JvdXRlX3YyIGdpdDovL3hlbmJpdHMueGVuLm9yZy9wZW9wbGUvcm95Z2VyL3hl
bi5naXQKCk1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGJ1aWxkIFhlbiBmcm9tIHNvdXJj
ZSBjYW4gYmUgZm91bmQgYXQKaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL0NvbXBpbGluZ19YZW5f
RnJvbV9Tb3VyY2UjQnVpbGRpbmdfZnJvbV9Tb3VyY2UuCgpIb3BlIHRoaXMgaGVscHMsIFJvZ2Vy
LgoKPiBPbmx5IHBhdGNoaW5nIHdpdGggVjIgcmVzdWx0ZWQgaW4gbWlzc2luZyAibmV0ZGV2IiBt
ZW1iZXIgaW4KPiBsaWJ4bF9kZXZpY2VfbmljIChsaWJ4bF90eXBlcy5pZGwpLiBBZnRlciBlZGl0
aW5nIHRoZSBmaWxlIGFuZCBhZGRpbmcKPiB0aGUgZGVmaW5pdGlvbiwgaXQgY29tcGlsZWQgc28g
ZmFyLgo+IAo+IHhsIHdpdGggb25seSBwYXRjaGVzIFYyIGFwcGxpZWQgZG9lcyBwYXJzZSBuZWl0
aGVyIG5ldGRldiBub3IgZ2F0ZXdheWRldgo+IGFzIGl0IHNlZW1zLgo+IAo+IAo+IEJlc3QgcmVn
YXJkcywKPiBVbGYKPiAKPiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Feb 18 07:59:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 07:59: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 1U7Lcp-0008QY-7H; Mon, 18 Feb 2013 07:58: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 1U7Lcn-0008QT-0X
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 07:58:57 +0000
Received: from [85.158.143.99:36702] by server-3.bemta-4.messagelabs.com id
	F1/31-08920-04FD1215; Mon, 18 Feb 2013 07:58:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361174335!18160941!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19514 invoked from network); 18 Feb 2013 07:58:55 -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; 18 Feb 2013 07:58:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 07:58:53 +0000
Message-Id: <5121ED4B02000078000BF0FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 07:58:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E3502000078000BED4A@nat28.tlf.novell.com>
	<511E71B2.7010007@oracle.com>
In-Reply-To: <511E71B2.7010007@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/4] AMD IOMMU: don't BUG() when we don't
	have to
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 18:34, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 02/15/2013 11:19 AM, Jan Beulich wrote:
>> find_iommu_for_device() can easily return NULL instead, as all of its
>> callers are prepared for that.
> 
> This patch is obsoleted by the second patch ("[PATCH 2/4] AMD IOMMU: 
> cover all functions of a device even if ACPI only tells us of func 0"), 
> isn't it?

Yes it is, but it is an (I think) obviously correct thing to do, and
hence much more of a backporting candidate than the other one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 07:59:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 07:59: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 1U7Lcp-0008QY-7H; Mon, 18 Feb 2013 07:58: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 1U7Lcn-0008QT-0X
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 07:58:57 +0000
Received: from [85.158.143.99:36702] by server-3.bemta-4.messagelabs.com id
	F1/31-08920-04FD1215; Mon, 18 Feb 2013 07:58:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361174335!18160941!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19514 invoked from network); 18 Feb 2013 07:58:55 -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; 18 Feb 2013 07:58:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 07:58:53 +0000
Message-Id: <5121ED4B02000078000BF0FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 07:58:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E3502000078000BED4A@nat28.tlf.novell.com>
	<511E71B2.7010007@oracle.com>
In-Reply-To: <511E71B2.7010007@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 1/4] AMD IOMMU: don't BUG() when we don't
	have to
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 18:34, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 02/15/2013 11:19 AM, Jan Beulich wrote:
>> find_iommu_for_device() can easily return NULL instead, as all of its
>> callers are prepared for that.
> 
> This patch is obsoleted by the second patch ("[PATCH 2/4] AMD IOMMU: 
> cover all functions of a device even if ACPI only tells us of func 0"), 
> isn't it?

Yes it is, but it is an (I think) obviously correct thing to do, and
hence much more of a backporting candidate than the other one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 08:01:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 08:01: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 1U7Lei-0000VD-50; Mon, 18 Feb 2013 08:00: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 1U7Leg-0000V5-OG
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 08:00:54 +0000
Received: from [85.158.143.99:46926] by server-3.bemta-4.messagelabs.com id
	1C/23-08920-6BFD1215; Mon, 18 Feb 2013 08:00:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361174452!18314953!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11578 invoked from network); 18 Feb 2013 08:00:53 -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; 18 Feb 2013 08:00:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 08:00:52 +0000
Message-Id: <5121EDC202000078000BF106@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 08:00:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E5F02000078000BED4E@nat28.tlf.novell.com>
	<511E6EA4.9050009@oracle.com>
In-Reply-To: <511E6EA4.9050009@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 2/4] AMD IOMMU: cover all functions of a
 device even if ACPI only tells us of func 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 15.02.13 at 18:21, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 02/15/2013 11:20 AM, Jan Beulich wrote:
>>   
>>   static int __init get_last_bdf_acpi(struct acpi_table_header *table)
>>   {
>>       const struct acpi_ivrs_header *ivrs_block;
>>       unsigned long length = sizeof(struct acpi_table_ivrs);
>> +    int last_bdf = 0;
>>   
>>       while ( table->length > (length + sizeof(*ivrs_block)) )
>>       {
>>           ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>>           if ( table->length < (length + ivrs_block->length) )
>>               return -ENODEV;
>> -        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE &&
>> -             get_last_bdf_ivhd(
>> +        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE )
>> +        {
>> +            int ret = get_last_bdf_ivhd(
>>                    container_of(ivrs_block, const struct acpi_ivrs_hardware,
>> -                              header)) != 0 )
>> -            return -ENODEV;
>> +                              header));
>> +
>> +            if ( ret < 0 )
>> +                return ret;
>> +            UPDATE_LAST_BDF(ret);
> 
> Why do we need UPDATE_LAST_BDF () here? It is updated in 
> get_last_bdf_ivhd () above.

No, because "last_bdf" now is a local variable.

>> +        }
>>           length += ivrs_block->length;
>>       }
>> -   return 0;
>> +
>> +    return last_bdf;
>>   }
> 
> ...
> 
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -28,12 +28,38 @@
>>   #include <asm/hvm/svm/amd-iommu-proto.h>
>>   #include "../ats.h"
>>   
>> +static bool_t __read_mostly init_done;
>> +
>>   struct amd_iommu *find_iommu_for_device(int seg, int bdf)
>>   {
>>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
>>   
>> -    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
>> -                                                   : NULL;
>> +    if ( !ivrs_mappings || bdf >= ivrs_bdf_entries )
>> +        return NULL;
>> +
>> +    if ( unlikely(!ivrs_mappings[bdf].iommu) && likely(init_done) )
>> +    {
>> +        unsigned int bd0 = bdf & ~PCI_FUNC(~0);
>> +
>> +        if ( ivrs_mappings[bd0].iommu )
>> +        {
>> +            struct ivrs_mappings tmp = ivrs_mappings[bd0];
>> +
>> +            tmp.iommu = NULL;
>> +            if ( tmp.dte_requestor_id == bd0 )
>> +                tmp.dte_requestor_id = bdf;
> 
> Is it possible to have tmp.dte_requestor_id != bd0

Sure - when there was an alias entry for it (I assume e.g. in the
case of the device sitting behind a legacy PCI bridge).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 08:01:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 08:01: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 1U7Lei-0000VD-50; Mon, 18 Feb 2013 08:00: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 1U7Leg-0000V5-OG
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 08:00:54 +0000
Received: from [85.158.143.99:46926] by server-3.bemta-4.messagelabs.com id
	1C/23-08920-6BFD1215; Mon, 18 Feb 2013 08:00:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361174452!18314953!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11578 invoked from network); 18 Feb 2013 08:00:53 -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; 18 Feb 2013 08:00:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 08:00:52 +0000
Message-Id: <5121EDC202000078000BF106@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 08:00:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E5F02000078000BED4E@nat28.tlf.novell.com>
	<511E6EA4.9050009@oracle.com>
In-Reply-To: <511E6EA4.9050009@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 2/4] AMD IOMMU: cover all functions of a
 device even if ACPI only tells us of func 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 15.02.13 at 18:21, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> On 02/15/2013 11:20 AM, Jan Beulich wrote:
>>   
>>   static int __init get_last_bdf_acpi(struct acpi_table_header *table)
>>   {
>>       const struct acpi_ivrs_header *ivrs_block;
>>       unsigned long length = sizeof(struct acpi_table_ivrs);
>> +    int last_bdf = 0;
>>   
>>       while ( table->length > (length + sizeof(*ivrs_block)) )
>>       {
>>           ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>>           if ( table->length < (length + ivrs_block->length) )
>>               return -ENODEV;
>> -        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE &&
>> -             get_last_bdf_ivhd(
>> +        if ( ivrs_block->type == ACPI_IVRS_TYPE_HARDWARE )
>> +        {
>> +            int ret = get_last_bdf_ivhd(
>>                    container_of(ivrs_block, const struct acpi_ivrs_hardware,
>> -                              header)) != 0 )
>> -            return -ENODEV;
>> +                              header));
>> +
>> +            if ( ret < 0 )
>> +                return ret;
>> +            UPDATE_LAST_BDF(ret);
> 
> Why do we need UPDATE_LAST_BDF () here? It is updated in 
> get_last_bdf_ivhd () above.

No, because "last_bdf" now is a local variable.

>> +        }
>>           length += ivrs_block->length;
>>       }
>> -   return 0;
>> +
>> +    return last_bdf;
>>   }
> 
> ...
> 
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -28,12 +28,38 @@
>>   #include <asm/hvm/svm/amd-iommu-proto.h>
>>   #include "../ats.h"
>>   
>> +static bool_t __read_mostly init_done;
>> +
>>   struct amd_iommu *find_iommu_for_device(int seg, int bdf)
>>   {
>>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
>>   
>> -    return ivrs_mappings && bdf < ivrs_bdf_entries ? ivrs_mappings[bdf].iommu
>> -                                                   : NULL;
>> +    if ( !ivrs_mappings || bdf >= ivrs_bdf_entries )
>> +        return NULL;
>> +
>> +    if ( unlikely(!ivrs_mappings[bdf].iommu) && likely(init_done) )
>> +    {
>> +        unsigned int bd0 = bdf & ~PCI_FUNC(~0);
>> +
>> +        if ( ivrs_mappings[bd0].iommu )
>> +        {
>> +            struct ivrs_mappings tmp = ivrs_mappings[bd0];
>> +
>> +            tmp.iommu = NULL;
>> +            if ( tmp.dte_requestor_id == bd0 )
>> +                tmp.dte_requestor_id = bdf;
> 
> Is it possible to have tmp.dte_requestor_id != bd0

Sure - when there was an alias entry for it (I assume e.g. in the
case of the device sitting behind a legacy PCI bridge).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 08:37:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7MDO-0000so-6x; Mon, 18 Feb 2013 08:36: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 1U7MDM-0000sj-TN
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 08:36:45 +0000
Received: from [85.158.138.51:35533] by server-3.bemta-3.messagelabs.com id
	4C/70-31070-C18E1215; Mon, 18 Feb 2013 08:36:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361176601!23913741!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2327 invoked from network); 18 Feb 2013 08:36:42 -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; 18 Feb 2013 08:36:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 08:36:41 +0000
Message-Id: <5121F62402000078000BF120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 08:36:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
	<511A817B02000078000BDCAC@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB87F4BC7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87F4BC7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:57, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> Eddie had already ack the patches.

Oh, sorry, somehow I managed to overlook this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 08:37:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7MDO-0000so-6x; Mon, 18 Feb 2013 08:36: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 1U7MDM-0000sj-TN
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 08:36:45 +0000
Received: from [85.158.138.51:35533] by server-3.bemta-3.messagelabs.com id
	4C/70-31070-C18E1215; Mon, 18 Feb 2013 08:36:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361176601!23913741!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2327 invoked from network); 18 Feb 2013 08:36:42 -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; 18 Feb 2013 08:36:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 08:36:41 +0000
Message-Id: <5121F62402000078000BF120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 08:36:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87E62C8@SHSMSX101.ccr.corp.intel.com>
	<511A817B02000078000BDCAC@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB87F4BC7@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87F4BC7@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Patch v5 0/2] bug fixes for APICV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:57, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> Eddie had already ack the patches.

Oh, sorry, somehow I managed to overlook this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 08:58:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 08: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 1U7MXI-0001Bb-OJ; Mon, 18 Feb 2013 08:57:20 +0000
Received: from mail1.bemta4.messagelabs.com ([85.158.143.250])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1U7MXH-0001BW-AI
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 08:57:19 +0000
Received: from [85.158.143.35:31656] by server-3.bemta-4.messagelabs.com id
	C6/C0-08920-EECE1215; Mon, 18 Feb 2013 08:57:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1361175052!4795806!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 807 invoked from network); 18 Feb 2013 08:10:52 -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; 18 Feb 2013 08:10:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 08:10:51 +0000
Message-Id: <5121F01702000078000BF117@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 08:10:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1360952378.16636.195.camel@zion.uk.xensource.com>
	<511E829B.8020800@citrix.com>
In-Reply-To: <511E829B.8020800@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 19:46, David Vrabel <david.vrabel@citrix.com> wrote:
> I would expect this call to never fail in normal operation (except on
> the boot VCPU where support may be missing).  i.e., it will only fail if
> xenheap or map space is exhausted.  Both the xenheap and the map space
> should be large enough so we run out of other resources (e.g,, domheap)
> first.

This is a questionable assumption, considering that the Xen heap is
a subset of the domain one (on x86-64 at least), and the map space
size has no correlation to either.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 08:58:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 08: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 1U7MXI-0001Bb-OJ; Mon, 18 Feb 2013 08:57:20 +0000
Received: from mail1.bemta4.messagelabs.com ([85.158.143.250])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1U7MXH-0001BW-AI
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 08:57:19 +0000
Received: from [85.158.143.35:31656] by server-3.bemta-4.messagelabs.com id
	C6/C0-08920-EECE1215; Mon, 18 Feb 2013 08:57:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1361175052!4795806!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 807 invoked from network); 18 Feb 2013 08:10:52 -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; 18 Feb 2013 08:10:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 08:10:51 +0000
Message-Id: <5121F01702000078000BF117@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 08:10:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1360952378.16636.195.camel@zion.uk.xensource.com>
	<511E829B.8020800@citrix.com>
In-Reply-To: <511E829B.8020800@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.02.13 at 19:46, David Vrabel <david.vrabel@citrix.com> wrote:
> I would expect this call to never fail in normal operation (except on
> the boot VCPU where support may be missing).  i.e., it will only fail if
> xenheap or map space is exhausted.  Both the xenheap and the map space
> should be large enough so we run out of other resources (e.g,, domheap)
> first.

This is a questionable assumption, considering that the Xen heap is
a subset of the domain one (on x86-64 at least), and the map space
size has no correlation to either.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 09:14:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 09:14: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 1U7Mn3-0001Rc-Kb; Mon, 18 Feb 2013 09:13:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1U7Mn2-0001RX-Fu
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 09:13:36 +0000
Received: from [85.158.139.211:14984] by server-13.bemta-5.messagelabs.com id
	9E/76-06769-FB0F1215; Mon, 18 Feb 2013 09:13:35 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361178813!17985757!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29844 invoked from network); 18 Feb 2013 09:13:34 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 09:13:34 -0000
Received: by mail-vc0-f174.google.com with SMTP id n11so3485247vch.33
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 01:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=rOt2UQ1RwMNnp6jqEbjj+XrSnsmqEEsVU52uh1zm/sU=;
	b=jZt1udG84LU9djVlITMeNkJaq/6oGjQNlnTD8n3Xv9PwI0lZgAWFLxkcddSjEhzgHY
	SBOzopnwlVOM6O6W+ocLoMSh6PaFaDinbXlL6CuUhecYYAKow2K8x0VL9m2FeNSzjQF/
	ykG/GbPtr+APw2sR8s3WRY8HSjWdRcmQmJs9d+WgatFZTkYOp8cxA1vjdUBXo39qvMwF
	udqS5KqzPA4KnPehpAF3ytdgsYfOkWTc9bcffpFb4NKlGlqLAlwqiXzYosrJC0rS3WKA
	hCiwRTb0MJ7iPNYzimi40vs+iSEXKdXnV6d4Z6NyFL58HCqnRRfwvkYV2IBxl2vIxJEd
	ETkA==
X-Received: by 10.58.132.170 with SMTP id ov10mr14634495veb.57.1361178810368; 
	Mon, 18 Feb 2013 01:13:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.1.37 with HTTP; Mon, 18 Feb 2013 01:13:10 -0800 (PST)
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Mon, 18 Feb 2013 10:13:10 +0100
X-Google-Sender-Auth: Hi3P85U0AGuuVW4KP4t1DwYOqY4
Message-ID: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5000586697615454615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5000586697615454615==
Content-Type: multipart/alternative; boundary=047d7b6da8f877c38d04d5fc23a1

--047d7b6da8f877c38d04d5fc23a1
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have some difficulties with drivers GPLPV. When I try to install the
GPLPV on windows 7 and 2008 R2.
I have tried some version:
gplpv_Vista2008x64_signed_0.11.0.308.msi
gplpv_Vista2008x64_signed_0.11.0.356.msi

During installation, I obtained a BSOD about IRQ. I suppose that is block
device drivers cause troubles.

On windows XP, I try :
gplpv_XP_signed_0.11.0.308.msi
gplpv_XP_signed_0.11.0.356.msi
gplpv_XP_signed_0.11.0.356.msi

I obtained for Block device "this peripheral cannot start error 10".

What is the best way to troubleshoot that ?


Did i forget something anything in file configuration of domu?

builder='hvm'
memory = 2048
name = "Windows2008R2"
vif = [ 'type=ioemu, mac=00:16:3e:00:00:13, bridge=br0' ]
disk = [ 'file:/home/VM/Volumes/win2008R2.img,hda,w', 'file:/home/Soft/ISO
Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hdc:cdrom,r'
,'file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r' ]
boot="dc"
sdl=0
opengl=1
vnc=1
vnclisten="127.0.0.1"
vncpasswd='???????'
stdvga=0
serial='pty'
tsc_mode="default"
keymap='fr'


Thanks for you help and sorry for my english.

Erwan

--047d7b6da8f877c38d04d5fc23a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>I have some difficulties with=
 drivers GPLPV. When I try to install the GPLPV on windows 7 and 2008 R2.</=
div><div style>I have tried some version:</div><div style>gplpv_Vista2008x6=
4_signed_0.11.0.308.msi<br>

</div><div style>gplpv_Vista2008x64_signed_0.11.0.356.msi<br></div><div sty=
le><br></div><div style>During installation, I obtained a BSOD about IRQ. I=
 suppose that is block device drivers cause troubles.</div><div style>
<br>
</div><div style>On windows XP, I try :</div><div style>gplpv_XP_signed_0.1=
1.0.308.msi<br></div><div style>gplpv_XP_signed_0.11.0.356.msi</div><div st=
yle>gplpv_XP_signed_0.11.0.356.msi<br></div><div style><br></div><div style=
>

I obtained for Block device &quot;this peripheral cannot start error 10&quo=
t;.</div><div style><br></div><div style>What is the best way to troublesho=
ot that ?</div><div style><br></div><div style><br></div><div style>Did i f=
orget something anything in file configuration of domu?</div>

<div style><div><br></div><div>builder=3D&#39;hvm&#39;</div><div>memory =3D=
 2048</div><div>name =3D &quot;Windows2008R2&quot;</div><div>vif =3D [ &#39=
;type=3Dioemu, mac=3D00:16:3e:00:00:13, bridge=3Dbr0&#39; ]</div><div>disk =
=3D [ &#39;file:/home/VM/Volumes/win2008R2.img,hda,w&#39;, &#39;file:/home/=
Soft/ISO Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hd=
c:cdrom,r&#39; ,&#39;file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r&#39; ]</di=
v>

<div>boot=3D&quot;dc&quot;</div><div>sdl=3D0</div><div>opengl=3D1</div><div=
>vnc=3D1</div><div>vnclisten=3D&quot;127.0.0.1&quot;</div><div>vncpasswd=3D=
&#39;???????&#39;</div><div>stdvga=3D0</div><div>serial=3D&#39;pty&#39;</di=
v><div>tsc_mode=3D&quot;default&quot;</div>

<div>keymap=3D&#39;fr&#39;</div><div><br></div></div><div style><br></div><=
div style>Thanks for you help and sorry for my english.</div><div style><br=
></div><div style>Erwan</div><div style><br></div></div>

--047d7b6da8f877c38d04d5fc23a1--


--===============5000586697615454615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5000586697615454615==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 09:14:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 09:14: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 1U7Mn3-0001Rc-Kb; Mon, 18 Feb 2013 09:13:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1U7Mn2-0001RX-Fu
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 09:13:36 +0000
Received: from [85.158.139.211:14984] by server-13.bemta-5.messagelabs.com id
	9E/76-06769-FB0F1215; Mon, 18 Feb 2013 09:13:35 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361178813!17985757!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29844 invoked from network); 18 Feb 2013 09:13:34 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 09:13:34 -0000
Received: by mail-vc0-f174.google.com with SMTP id n11so3485247vch.33
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 01:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=rOt2UQ1RwMNnp6jqEbjj+XrSnsmqEEsVU52uh1zm/sU=;
	b=jZt1udG84LU9djVlITMeNkJaq/6oGjQNlnTD8n3Xv9PwI0lZgAWFLxkcddSjEhzgHY
	SBOzopnwlVOM6O6W+ocLoMSh6PaFaDinbXlL6CuUhecYYAKow2K8x0VL9m2FeNSzjQF/
	ykG/GbPtr+APw2sR8s3WRY8HSjWdRcmQmJs9d+WgatFZTkYOp8cxA1vjdUBXo39qvMwF
	udqS5KqzPA4KnPehpAF3ytdgsYfOkWTc9bcffpFb4NKlGlqLAlwqiXzYosrJC0rS3WKA
	hCiwRTb0MJ7iPNYzimi40vs+iSEXKdXnV6d4Z6NyFL58HCqnRRfwvkYV2IBxl2vIxJEd
	ETkA==
X-Received: by 10.58.132.170 with SMTP id ov10mr14634495veb.57.1361178810368; 
	Mon, 18 Feb 2013 01:13:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.1.37 with HTTP; Mon, 18 Feb 2013 01:13:10 -0800 (PST)
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Mon, 18 Feb 2013 10:13:10 +0100
X-Google-Sender-Auth: Hi3P85U0AGuuVW4KP4t1DwYOqY4
Message-ID: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5000586697615454615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5000586697615454615==
Content-Type: multipart/alternative; boundary=047d7b6da8f877c38d04d5fc23a1

--047d7b6da8f877c38d04d5fc23a1
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have some difficulties with drivers GPLPV. When I try to install the
GPLPV on windows 7 and 2008 R2.
I have tried some version:
gplpv_Vista2008x64_signed_0.11.0.308.msi
gplpv_Vista2008x64_signed_0.11.0.356.msi

During installation, I obtained a BSOD about IRQ. I suppose that is block
device drivers cause troubles.

On windows XP, I try :
gplpv_XP_signed_0.11.0.308.msi
gplpv_XP_signed_0.11.0.356.msi
gplpv_XP_signed_0.11.0.356.msi

I obtained for Block device "this peripheral cannot start error 10".

What is the best way to troubleshoot that ?


Did i forget something anything in file configuration of domu?

builder='hvm'
memory = 2048
name = "Windows2008R2"
vif = [ 'type=ioemu, mac=00:16:3e:00:00:13, bridge=br0' ]
disk = [ 'file:/home/VM/Volumes/win2008R2.img,hda,w', 'file:/home/Soft/ISO
Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hdc:cdrom,r'
,'file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r' ]
boot="dc"
sdl=0
opengl=1
vnc=1
vnclisten="127.0.0.1"
vncpasswd='???????'
stdvga=0
serial='pty'
tsc_mode="default"
keymap='fr'


Thanks for you help and sorry for my english.

Erwan

--047d7b6da8f877c38d04d5fc23a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>I have some difficulties with=
 drivers GPLPV. When I try to install the GPLPV on windows 7 and 2008 R2.</=
div><div style>I have tried some version:</div><div style>gplpv_Vista2008x6=
4_signed_0.11.0.308.msi<br>

</div><div style>gplpv_Vista2008x64_signed_0.11.0.356.msi<br></div><div sty=
le><br></div><div style>During installation, I obtained a BSOD about IRQ. I=
 suppose that is block device drivers cause troubles.</div><div style>
<br>
</div><div style>On windows XP, I try :</div><div style>gplpv_XP_signed_0.1=
1.0.308.msi<br></div><div style>gplpv_XP_signed_0.11.0.356.msi</div><div st=
yle>gplpv_XP_signed_0.11.0.356.msi<br></div><div style><br></div><div style=
>

I obtained for Block device &quot;this peripheral cannot start error 10&quo=
t;.</div><div style><br></div><div style>What is the best way to troublesho=
ot that ?</div><div style><br></div><div style><br></div><div style>Did i f=
orget something anything in file configuration of domu?</div>

<div style><div><br></div><div>builder=3D&#39;hvm&#39;</div><div>memory =3D=
 2048</div><div>name =3D &quot;Windows2008R2&quot;</div><div>vif =3D [ &#39=
;type=3Dioemu, mac=3D00:16:3e:00:00:13, bridge=3Dbr0&#39; ]</div><div>disk =
=3D [ &#39;file:/home/VM/Volumes/win2008R2.img,hda,w&#39;, &#39;file:/home/=
Soft/ISO Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hd=
c:cdrom,r&#39; ,&#39;file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r&#39; ]</di=
v>

<div>boot=3D&quot;dc&quot;</div><div>sdl=3D0</div><div>opengl=3D1</div><div=
>vnc=3D1</div><div>vnclisten=3D&quot;127.0.0.1&quot;</div><div>vncpasswd=3D=
&#39;???????&#39;</div><div>stdvga=3D0</div><div>serial=3D&#39;pty&#39;</di=
v><div>tsc_mode=3D&quot;default&quot;</div>

<div>keymap=3D&#39;fr&#39;</div><div><br></div></div><div style><br></div><=
div style>Thanks for you help and sorry for my english.</div><div style><br=
></div><div style>Erwan</div><div style><br></div></div>

--047d7b6da8f877c38d04d5fc23a1--


--===============5000586697615454615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5000586697615454615==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 09:33:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 09: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 1U7N5q-0001pb-9G; Mon, 18 Feb 2013 09:33: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 1U7N5o-0001pN-ET
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 09:33:00 +0000
Received: from [85.158.143.99:35132] by server-1.bemta-4.messagelabs.com id
	B1/40-08839-B45F1215; Mon, 18 Feb 2013 09:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361179979!27922017!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23534 invoked from network); 18 Feb 2013 09:32:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 09:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1561128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 09:32: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.297.1;
	Mon, 18 Feb 2013 09:32:58 +0000
Message-ID: <1361179976.31407.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Feb 2013 09:32:56 +0000
In-Reply-To: <osstest-16171-mainreport@xen.org>
References: <osstest-16171-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16171: 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 Thu, 2013-02-14 at 19:35 +0000, xen.org wrote:

This seems to have been the last test report I've seen, and there was a
fairly substantial load of patches pushed on Friday which are still in
staging. The resource plan doesn't show much in the way of ongoing
tests.

Any idea 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 Mon Feb 18 09:33:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 09: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 1U7N5q-0001pb-9G; Mon, 18 Feb 2013 09:33: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 1U7N5o-0001pN-ET
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 09:33:00 +0000
Received: from [85.158.143.99:35132] by server-1.bemta-4.messagelabs.com id
	B1/40-08839-B45F1215; Mon, 18 Feb 2013 09:32:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361179979!27922017!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23534 invoked from network); 18 Feb 2013 09:32:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 09:32:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1561128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 09:32: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.297.1;
	Mon, 18 Feb 2013 09:32:58 +0000
Message-ID: <1361179976.31407.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 18 Feb 2013 09:32:56 +0000
In-Reply-To: <osstest-16171-mainreport@xen.org>
References: <osstest-16171-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16171: 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 Thu, 2013-02-14 at 19:35 +0000, xen.org wrote:

This seems to have been the last test report I've seen, and there was a
fairly substantial load of patches pushed on Friday which are still in
staging. The resource plan doesn't show much in the way of ongoing
tests.

Any idea 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 Mon Feb 18 10:02:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7NXu-0002Ia-OH; Mon, 18 Feb 2013 10:02:02 +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 1U7NXt-0002IV-5t
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:02:01 +0000
Received: from [85.158.138.51:8624] by server-9.bemta-3.messagelabs.com id
	0F/86-09484-31CF1215; Mon, 18 Feb 2013 10:01:55 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361181711!28002741!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6570 invoked from network); 18 Feb 2013 10:01:54 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 10:01:54 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7NXe-0007Oj-Vs; Mon, 18 Feb 2013 21:01:47 +1100
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 id
	14.01.0438.000; Mon, 18 Feb 2013 21:01:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Erwan RIGOLLOT <erwan@rigollot.me>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] GPLPV
Thread-Index: AQHODblRtbwo4yxEekWAGSmkTVhptZh/Yaeg
Date: Mon, 18 Feb 2013 10:01:44 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
In-Reply-To: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19644.005
x-tm-as-result: No--34.670000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 have some difficulties with drivers GPLPV. When I try to install the GPLPV
> on windows 7 and 2008 R2.
> I have tried some version:
> gplpv_Vista2008x64_signed_0.11.0.308.msi
> 
> gplpv_Vista2008x64_signed_0.11.0.356.msi
> 
> During installation, I obtained a BSOD about IRQ. I suppose that is block
> device drivers cause troubles.
> 
> On windows XP, I try :
> gplpv_XP_signed_0.11.0.308.msi
> 
> gplpv_XP_signed_0.11.0.356.msi
> gplpv_XP_signed_0.11.0.356.msi
> 
> 
> I obtained for Block device "this peripheral cannot start error 10".
> 
> What is the best way to troubleshoot that ?
> 
> 
> Did i forget something anything in file configuration of domu?
> 
> builder='hvm'
> memory = 2048
> name = "Windows2008R2"
> vif = [ 'type=ioemu, mac=00:16:3e:00:00:13, bridge=br0' ]
> disk = [ 'file:/home/VM/Volumes/win2008R2.img,hda,w',
> 'file:/home/Soft/ISO
> Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hdc:
> cdrom,r' ,'file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r' ]
> boot="dc"
> sdl=0
> opengl=1
> vnc=1
> vnclisten="127.0.0.1"
> vncpasswd='???????'
> stdvga=0
> serial='pty'
> tsc_mode="default"
> keymap='fr'
> 
> Thanks for you help and sorry for my english.
> 

That all looks okay. Can you try installing the debug version and then send me the output of /var/log/xen/qemu-dm-<domu-name>.log

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:02:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7NXu-0002Ia-OH; Mon, 18 Feb 2013 10:02:02 +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 1U7NXt-0002IV-5t
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:02:01 +0000
Received: from [85.158.138.51:8624] by server-9.bemta-3.messagelabs.com id
	0F/86-09484-31CF1215; Mon, 18 Feb 2013 10:01:55 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361181711!28002741!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6570 invoked from network); 18 Feb 2013 10:01:54 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 10:01:54 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7NXe-0007Oj-Vs; Mon, 18 Feb 2013 21:01:47 +1100
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 id
	14.01.0438.000; Mon, 18 Feb 2013 21:01:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Erwan RIGOLLOT <erwan@rigollot.me>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] GPLPV
Thread-Index: AQHODblRtbwo4yxEekWAGSmkTVhptZh/Yaeg
Date: Mon, 18 Feb 2013 10:01:44 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
In-Reply-To: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19644.005
x-tm-as-result: No--34.670000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 have some difficulties with drivers GPLPV. When I try to install the GPLPV
> on windows 7 and 2008 R2.
> I have tried some version:
> gplpv_Vista2008x64_signed_0.11.0.308.msi
> 
> gplpv_Vista2008x64_signed_0.11.0.356.msi
> 
> During installation, I obtained a BSOD about IRQ. I suppose that is block
> device drivers cause troubles.
> 
> On windows XP, I try :
> gplpv_XP_signed_0.11.0.308.msi
> 
> gplpv_XP_signed_0.11.0.356.msi
> gplpv_XP_signed_0.11.0.356.msi
> 
> 
> I obtained for Block device "this peripheral cannot start error 10".
> 
> What is the best way to troubleshoot that ?
> 
> 
> Did i forget something anything in file configuration of domu?
> 
> builder='hvm'
> memory = 2048
> name = "Windows2008R2"
> vif = [ 'type=ioemu, mac=00:16:3e:00:00:13, bridge=br0' ]
> disk = [ 'file:/home/VM/Volumes/win2008R2.img,hda,w',
> 'file:/home/Soft/ISO
> Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hdc:
> cdrom,r' ,'file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r' ]
> boot="dc"
> sdl=0
> opengl=1
> vnc=1
> vnclisten="127.0.0.1"
> vncpasswd='???????'
> stdvga=0
> serial='pty'
> tsc_mode="default"
> keymap='fr'
> 
> Thanks for you help and sorry for my english.
> 

That all looks okay. Can you try installing the debug version and then send me the output of /var/log/xen/qemu-dm-<domu-name>.log

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:07:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7Ncf-0002Rk-G4; Mon, 18 Feb 2013 10:06:57 +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 1U7Ncd-0002RZ-HQ
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:06:55 +0000
Received: from [85.158.137.99:42529] by server-11.bemta-3.messagelabs.com id
	EA/1E-10249-E3DF1215; Mon, 18 Feb 2013 10:06:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361182013!16467912!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13995 invoked from network); 18 Feb 2013 10:06:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:06:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1562730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:06: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.297.1;
	Mon, 18 Feb 2013 10:06:53 +0000
Message-ID: <1361182012.31407.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Mon, 18 Feb 2013 10:06:52 +0000
In-Reply-To: <511EAEA9.5040109@heliman.it>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
	<511EAEA9.5040109@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 21:54 +0000, Fabio Fantoni wrote:
> Il 15/02/2013 16:48, Ian Jackson ha scritto:
> > fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
> >> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> >>
> >> Usage:
> >>    vga="stdvga"|"cirrus"
> >>
> >> - Default option is cirrus.
> >> - Prints error and exit if unknown value is passed.
> >> - stdvga parameter is now deprecated.
> >> - Updated xl.cfg man.
> >>
> >> Required patch: Improve videoram setting v5
> >> Is prerequisite for patch: Add qxl support v9
> > The code looks good to me, but there are a couple of formatting
> > problems.  Your wrapping of the longer lines is odd (particularly, you
> > fail to indent the continuations), and there's a spurious space after
> > xlu_cfg_get_string.  Can you please repost following the style used
> > elsewhere ?
> >
> > Thanks,
> > Ian.
> Sorry.
> Can you explain me the error of indentation did I do please?

The spurious space after xlu_cfg_get_string, e.g. 
		xlu_cfg_get_string (config,
should have been
		xlu_cfg_get_string(config,

However, I count 44 instances with the space and 3 without in this file,
so I think you can be forgiven. This extra space has been there from day
one...

The more important one IMHO is:

+            if (!strcmp(buf, "stdvga")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_STD;

I noticed this when I reviewed but when I looked at the file I concluded
you were just copying a prevailing style so I let it slide. Looking
again I think I was looking at the file with this patch applied, which
makes that logic rather circular ;-)

It seems like you were trying to avoid going over the 80 column limit,
although in this case it doesn't seem like the line would actually be
that long. If wrapping is required then it would be more normal to
indent as:

+            if (!strcmp(buf, "stdvga")) {
+                b_info->u.hvm.vga.kind
+                    = LIBXL_VGA_INTERFACE_TYPE_STD;

(i.e indent the wrapped line by one level). However given that all these
things fit on one line using at most 72 columns:

8<------
xl: fix line wrapping oddness

These lines are strangely wrapped and in any case fit within 80 columns
when unwrapped.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..a80cda6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1476,14 +1476,11 @@ skip_vfb:
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
             if (!strcmp(buf, "stdvga")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_STD;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
             } else if (!strcmp(buf, "cirrus")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
             } else {
-                fprintf(stderr,
-                "Unknown vga \"%s\" specified\n", buf);
+                fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
                 exit(1);
             }
         } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:07:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7Ncf-0002Rk-G4; Mon, 18 Feb 2013 10:06:57 +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 1U7Ncd-0002RZ-HQ
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:06:55 +0000
Received: from [85.158.137.99:42529] by server-11.bemta-3.messagelabs.com id
	EA/1E-10249-E3DF1215; Mon, 18 Feb 2013 10:06:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361182013!16467912!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13995 invoked from network); 18 Feb 2013 10:06:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:06:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1562730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:06: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.297.1;
	Mon, 18 Feb 2013 10:06:53 +0000
Message-ID: <1361182012.31407.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Mon, 18 Feb 2013 10:06:52 +0000
In-Reply-To: <511EAEA9.5040109@heliman.it>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
	<511EAEA9.5040109@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 21:54 +0000, Fabio Fantoni wrote:
> Il 15/02/2013 16:48, Ian Jackson ha scritto:
> > fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
> >> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> >>
> >> Usage:
> >>    vga="stdvga"|"cirrus"
> >>
> >> - Default option is cirrus.
> >> - Prints error and exit if unknown value is passed.
> >> - stdvga parameter is now deprecated.
> >> - Updated xl.cfg man.
> >>
> >> Required patch: Improve videoram setting v5
> >> Is prerequisite for patch: Add qxl support v9
> > The code looks good to me, but there are a couple of formatting
> > problems.  Your wrapping of the longer lines is odd (particularly, you
> > fail to indent the continuations), and there's a spurious space after
> > xlu_cfg_get_string.  Can you please repost following the style used
> > elsewhere ?
> >
> > Thanks,
> > Ian.
> Sorry.
> Can you explain me the error of indentation did I do please?

The spurious space after xlu_cfg_get_string, e.g. 
		xlu_cfg_get_string (config,
should have been
		xlu_cfg_get_string(config,

However, I count 44 instances with the space and 3 without in this file,
so I think you can be forgiven. This extra space has been there from day
one...

The more important one IMHO is:

+            if (!strcmp(buf, "stdvga")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_STD;

I noticed this when I reviewed but when I looked at the file I concluded
you were just copying a prevailing style so I let it slide. Looking
again I think I was looking at the file with this patch applied, which
makes that logic rather circular ;-)

It seems like you were trying to avoid going over the 80 column limit,
although in this case it doesn't seem like the line would actually be
that long. If wrapping is required then it would be more normal to
indent as:

+            if (!strcmp(buf, "stdvga")) {
+                b_info->u.hvm.vga.kind
+                    = LIBXL_VGA_INTERFACE_TYPE_STD;

(i.e indent the wrapped line by one level). However given that all these
things fit on one line using at most 72 columns:

8<------
xl: fix line wrapping oddness

These lines are strangely wrapped and in any case fit within 80 columns
when unwrapped.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..a80cda6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1476,14 +1476,11 @@ skip_vfb:
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
             if (!strcmp(buf, "stdvga")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_STD;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
             } else if (!strcmp(buf, "cirrus")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
             } else {
-                fprintf(stderr,
-                "Unknown vga \"%s\" specified\n", buf);
+                fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
                 exit(1);
             }
         } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:13:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7Nj0-0002fF-Be; Mon, 18 Feb 2013 10:13:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7Niz-0002f2-4K
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:13:29 +0000
Received: from [85.158.137.99:8547] by server-3.bemta-3.messagelabs.com id
	A4/90-31070-5CEF1215; Mon, 18 Feb 2013 10:13:25 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361182402!21783386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30134 invoked from network); 18 Feb 2013 10:13:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7574543"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 10:13:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 05:13:22 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7Nir-0007qE-N0;
	Mon, 18 Feb 2013 10:13:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Winston Wang <winston.l.wang@intel.com>, Gang Wei <gang.wei@intel.com>,
	Jan Beulich <jbeulich@suse.com>
Date: Mon, 18 Feb 2013 10:10:52 +0000
Message-ID: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/2] genid: ACPI Windows generation ID updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 patch update Windows generation ID support on ACPI.

First patch mainly update to new specifications while second one
introduce again the device in ACPI table.

Frediano Ziglio (2):
  genid: Update Windows generation ID
  genid: Introduce again Windows generation ID device

 docs/misc/xenstore-paths.markdown      |    6 ++++
 tools/firmware/hvmloader/acpi/build.c  |   49 ++++++++++++++++++++++----------
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 ++++++++++++++++
 3 files changed, 65 insertions(+), 15 deletions(-)

-- 
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 Mon Feb 18 10:13:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7Nj0-0002fF-Be; Mon, 18 Feb 2013 10:13:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7Niz-0002f2-4K
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:13:29 +0000
Received: from [85.158.137.99:8547] by server-3.bemta-3.messagelabs.com id
	A4/90-31070-5CEF1215; Mon, 18 Feb 2013 10:13:25 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361182402!21783386!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30134 invoked from network); 18 Feb 2013 10:13:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7574543"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 10:13:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 05:13:22 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7Nir-0007qE-N0;
	Mon, 18 Feb 2013 10:13:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Winston Wang <winston.l.wang@intel.com>, Gang Wei <gang.wei@intel.com>,
	Jan Beulich <jbeulich@suse.com>
Date: Mon, 18 Feb 2013 10:10:52 +0000
Message-ID: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/2] genid: ACPI Windows generation ID updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 patch update Windows generation ID support on ACPI.

First patch mainly update to new specifications while second one
introduce again the device in ACPI table.

Frediano Ziglio (2):
  genid: Update Windows generation ID
  genid: Introduce again Windows generation ID device

 docs/misc/xenstore-paths.markdown      |    6 ++++
 tools/firmware/hvmloader/acpi/build.c  |   49 ++++++++++++++++++++++----------
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 ++++++++++++++++
 3 files changed, 65 insertions(+), 15 deletions(-)

-- 
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 Mon Feb 18 10:13:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7Nj0-0002fQ-N4; Mon, 18 Feb 2013 10:13:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7Niz-0002f2-Il
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:13:29 +0000
Received: from [85.158.137.99:8715] by server-3.bemta-3.messagelabs.com id
	4C/90-31070-7CEF1215; Mon, 18 Feb 2013 10:13:27 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361182402!21783386!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 18 Feb 2013 10:13:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:13:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7574544"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 10:13:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 05:13:22 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7Nir-0007qE-P0;
	Mon, 18 Feb 2013 10:13:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Winston Wang <winston.l.wang@intel.com>, Gang Wei <gang.wei@intel.com>,
	Jan Beulich <jbeulich@suse.com>
Date: Mon, 18 Feb 2013 10:10:53 +0000
Message-ID: <1361182254-4745-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] genid: Update Windows generation 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

First draft specification document it as a 64bit counter, now are a 128bit
value handled as a couple of 64bit values.

Allow to disable the device is values are all zeroes.

Add documentation for platform/generation-id key.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 docs/misc/xenstore-paths.markdown     |    6 ++++
 tools/firmware/hvmloader/acpi/build.c |   49 +++++++++++++++++++++++----------
 2 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index 09e551b..535830e 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -164,6 +164,12 @@ Various platform properties.
 * acpi_s3 -- is ACPI S3 support enabled for this domain
 * acpi_s4 -- is ACPI S4 support enabled for this domain
 
+#### ~/platform/generation-id = INTEGER ":" INTEGER [HVM,INTERNAL]
+
+Two 64 bit values that represent the Windows Generation ID.
+Is used by the BIOS initializer to get this value.
+If not present or "0:0" (all zeroes) device will not be present to the machine.
+
 ### Frontend device paths
 
 Paravirtual device frontends are generally specified by their own
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 9026e09..ad9fbb7 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -349,24 +349,45 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     return nr_tables;
 }
 
-unsigned long new_vm_gid(void)
+/**
+ * Allocate and initialize Windows Generation ID
+ * If value is not present in the XenStore or if all zeroes
+ * the device will be not active
+ *
+ * Return 0 if memory failure, != 0 if success
+ */
+static int new_vm_gid(struct acpi_info *acpi_info)
 {
-    uint64_t gid;
-    unsigned char *buf;
-    char addr[11];
-
-    buf = mem_alloc(8, 8);
-    if (!buf) return 0;
+    uint64_t vm_gid[2], *buf;
+    char addr[12];
+    const char * s;
+    char *end;
+
+    acpi_info->vm_gid_addr = 0;
+
+    /* read ID and check for 0 */
+    s = xenstore_read("platform/generation-id", "0:0");
+    vm_gid[0] = strtoll(s, &end, 0);
+    vm_gid[1] = 0;
+    if ( end && end[0] == ':' )
+        vm_gid[1] = strtoll(end+1, NULL, 0);
+    if ( !vm_gid[0] && !vm_gid[1] )
+        return 1;
+
+    /* copy to allocate BIOS memory */
+    buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+    if ( !buf )
+        return 0;
+    memcpy(buf, vm_gid, sizeof(vm_gid));
 
+    /* set into ACPI table and XenStore the address */
+    acpi_info->vm_gid_addr = virt_to_phys(buf);
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
     xenstore_write("hvmloader/generation-id-address", addr);
 
-    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
-    *(uint64_t *)buf = gid;
-
-    return virt_to_phys(buf);    
+    return 1;
 }
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
@@ -381,7 +402,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     unsigned char       *dsdt;
     unsigned long        secondary_tables[ACPI_MAX_SECONDARY_TABLES];
     int                  nr_secondaries, i;
-    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -494,8 +514,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
-    vm_gid_addr = new_vm_gid();
-    if (!vm_gid_addr) goto oom;
+    if ( !new_vm_gid(acpi_info) )
+        goto oom;
 
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
@@ -503,7 +523,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
-    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
-- 
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 Mon Feb 18 10:13:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7Nj0-0002fQ-N4; Mon, 18 Feb 2013 10:13:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7Niz-0002f2-Il
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:13:29 +0000
Received: from [85.158.137.99:8715] by server-3.bemta-3.messagelabs.com id
	4C/90-31070-7CEF1215; Mon, 18 Feb 2013 10:13:27 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361182402!21783386!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 18 Feb 2013 10:13:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:13:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7574544"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 10:13:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 05:13:22 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7Nir-0007qE-P0;
	Mon, 18 Feb 2013 10:13:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Winston Wang <winston.l.wang@intel.com>, Gang Wei <gang.wei@intel.com>,
	Jan Beulich <jbeulich@suse.com>
Date: Mon, 18 Feb 2013 10:10:53 +0000
Message-ID: <1361182254-4745-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] genid: Update Windows generation 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

First draft specification document it as a 64bit counter, now are a 128bit
value handled as a couple of 64bit values.

Allow to disable the device is values are all zeroes.

Add documentation for platform/generation-id key.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 docs/misc/xenstore-paths.markdown     |    6 ++++
 tools/firmware/hvmloader/acpi/build.c |   49 +++++++++++++++++++++++----------
 2 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index 09e551b..535830e 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -164,6 +164,12 @@ Various platform properties.
 * acpi_s3 -- is ACPI S3 support enabled for this domain
 * acpi_s4 -- is ACPI S4 support enabled for this domain
 
+#### ~/platform/generation-id = INTEGER ":" INTEGER [HVM,INTERNAL]
+
+Two 64 bit values that represent the Windows Generation ID.
+Is used by the BIOS initializer to get this value.
+If not present or "0:0" (all zeroes) device will not be present to the machine.
+
 ### Frontend device paths
 
 Paravirtual device frontends are generally specified by their own
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 9026e09..ad9fbb7 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -349,24 +349,45 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     return nr_tables;
 }
 
-unsigned long new_vm_gid(void)
+/**
+ * Allocate and initialize Windows Generation ID
+ * If value is not present in the XenStore or if all zeroes
+ * the device will be not active
+ *
+ * Return 0 if memory failure, != 0 if success
+ */
+static int new_vm_gid(struct acpi_info *acpi_info)
 {
-    uint64_t gid;
-    unsigned char *buf;
-    char addr[11];
-
-    buf = mem_alloc(8, 8);
-    if (!buf) return 0;
+    uint64_t vm_gid[2], *buf;
+    char addr[12];
+    const char * s;
+    char *end;
+
+    acpi_info->vm_gid_addr = 0;
+
+    /* read ID and check for 0 */
+    s = xenstore_read("platform/generation-id", "0:0");
+    vm_gid[0] = strtoll(s, &end, 0);
+    vm_gid[1] = 0;
+    if ( end && end[0] == ':' )
+        vm_gid[1] = strtoll(end+1, NULL, 0);
+    if ( !vm_gid[0] && !vm_gid[1] )
+        return 1;
+
+    /* copy to allocate BIOS memory */
+    buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+    if ( !buf )
+        return 0;
+    memcpy(buf, vm_gid, sizeof(vm_gid));
 
+    /* set into ACPI table and XenStore the address */
+    acpi_info->vm_gid_addr = virt_to_phys(buf);
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
     xenstore_write("hvmloader/generation-id-address", addr);
 
-    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
-    *(uint64_t *)buf = gid;
-
-    return virt_to_phys(buf);    
+    return 1;
 }
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
@@ -381,7 +402,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     unsigned char       *dsdt;
     unsigned long        secondary_tables[ACPI_MAX_SECONDARY_TABLES];
     int                  nr_secondaries, i;
-    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -494,8 +514,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
-    vm_gid_addr = new_vm_gid();
-    if (!vm_gid_addr) goto oom;
+    if ( !new_vm_gid(acpi_info) )
+        goto oom;
 
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
@@ -503,7 +523,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
-    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
-- 
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 Mon Feb 18 10:13:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7Nj2-0002fh-8P; Mon, 18 Feb 2013 10:13:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7Nj0-0002f2-8V
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:13:30 +0000
Received: from [85.158.137.99:8798] by server-3.bemta-3.messagelabs.com id
	90/A0-31070-8CEF1215; Mon, 18 Feb 2013 10:13:28 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361182402!21783386!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30394 invoked from network); 18 Feb 2013 10:13:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:13:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7574545"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 10:13:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 05:13:22 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7Nir-0007qE-PT;
	Mon, 18 Feb 2013 10:13:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Winston Wang <winston.l.wang@intel.com>, Gang Wei <gang.wei@intel.com>,
	Jan Beulich <jbeulich@suse.com>
Date: Mon, 18 Feb 2013 10:10:54 +0000
Message-ID: <1361182254-4745-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] genid: Introduce again Windows generation
	ID 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

This device was removed due to change in specifications.
Original patch written by Paul Durrant

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/tools/firmware/hvmloader/acpi/dsdt.asl
index 64896ce..247a8ad 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -397,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
                         IRQNoFlags () {7}
                     })
                 }
+
+                Device(VGID) {
+                    Name(_HID, EisaId ("XEN0000"))
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }
-- 
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 Mon Feb 18 10:13:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7Nj2-0002fh-8P; Mon, 18 Feb 2013 10:13:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7Nj0-0002f2-8V
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:13:30 +0000
Received: from [85.158.137.99:8798] by server-3.bemta-3.messagelabs.com id
	90/A0-31070-8CEF1215; Mon, 18 Feb 2013 10:13:28 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361182402!21783386!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30394 invoked from network); 18 Feb 2013 10:13:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:13:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7574545"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 10:13:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 05:13:22 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7Nir-0007qE-PT;
	Mon, 18 Feb 2013 10:13:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Winston Wang <winston.l.wang@intel.com>, Gang Wei <gang.wei@intel.com>,
	Jan Beulich <jbeulich@suse.com>
Date: Mon, 18 Feb 2013 10:10:54 +0000
Message-ID: <1361182254-4745-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361182254-4745-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] genid: Introduce again Windows generation
	ID 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

This device was removed due to change in specifications.
Original patch written by Paul Durrant

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/tools/firmware/hvmloader/acpi/dsdt.asl
index 64896ce..247a8ad 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -397,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
                         IRQNoFlags () {7}
                     })
                 }
+
+                Device(VGID) {
+                    Name(_HID, EisaId ("XEN0000"))
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }
-- 
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 Mon Feb 18 10:22:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:22: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 1U7Nr4-00039Y-AA; Mon, 18 Feb 2013 10:21:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U7Nr3-00039T-4d
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:21:49 +0000
Received: from [85.158.139.211:42425] by server-14.bemta-5.messagelabs.com id
	6B/DA-06967-CB002215; Mon, 18 Feb 2013 10:21:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361182907!18010984!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6638 invoked from network); 18 Feb 2013 10:21:47 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 10:21:47 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:49847 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 1U7Nxm-000375-Oo
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:28:46 +0100
Date: Mon, 18 Feb 2013 11:21:44 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <16282745.20130218112144@eikelenboom.it>
To: "xen-devel" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] xl segfaults on latest staging/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

Hi All,

Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
Previous pull was working fine and was about 3 or 4 days ago.

Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]

--

Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:22:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:22: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 1U7Nr4-00039Y-AA; Mon, 18 Feb 2013 10:21:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U7Nr3-00039T-4d
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:21:49 +0000
Received: from [85.158.139.211:42425] by server-14.bemta-5.messagelabs.com id
	6B/DA-06967-CB002215; Mon, 18 Feb 2013 10:21:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361182907!18010984!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6638 invoked from network); 18 Feb 2013 10:21:47 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 10:21:47 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:49847 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 1U7Nxm-000375-Oo
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:28:46 +0100
Date: Mon, 18 Feb 2013 11:21:44 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <16282745.20130218112144@eikelenboom.it>
To: "xen-devel" <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] xl segfaults on latest staging/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

Hi All,

Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
Previous pull was working fine and was about 3 or 4 days ago.

Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]

--

Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:33:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O2Q-0003zV-D3; Mon, 18 Feb 2013 10:33:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sander.bogaert@elis.ugent.be>) id 1U7O2O-0003zM-PW
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:33:33 +0000
Received: from [193.109.254.147:8482] by server-3.bemta-14.messagelabs.com id
	7A/F6-22141-C7302215; Mon, 18 Feb 2013 10:33:32 +0000
X-Env-Sender: sander.bogaert@elis.ugent.be
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361183610!1049176!1
X-Originating-IP: [157.193.49.127]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU3LjE5My40OS4xMjcgPT4gMTcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28338 invoked from network); 18 Feb 2013 10:33:31 -0000
Received: from smtp3.ugent.be (HELO smtp3.ugent.be) (157.193.49.127)
	by server-7.tower-27.messagelabs.com with SMTP;
	18 Feb 2013 10:33:31 -0000
Received: from localhost (mcheck2.ugent.be [157.193.49.249])
	by smtp3.ugent.be (Postfix) with ESMTP id CEF5DC448
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:30 +0100 (CET)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.ugent.be ([157.193.49.127])
	by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new,
	port 10024) with ESMTP id XBb6w_jRaEYr for <xen-devel@lists.xen.org>;
	Mon, 18 Feb 2013 11:33:30 +0100 (CET)
Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48])
	by smtp3.ugent.be (Postfix) with ESMTP id F3425C451
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:29 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mail.elis.ugent.be (Postfix) with ESMTP id E85EAAA30043
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at elis.ugent.be
Received: from mail.elis.ugent.be ([127.0.0.1])
	by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8XygGBDOaay9 for <xen-devel@lists.xen.org>;
	Mon, 18 Feb 2013 11:33:21 +0100 (CET)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com
	[209.85.219.47])
	by mail.elis.ugent.be (Postfix) with ESMTP id 236F1918C63
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:21 +0100 (CET)
Received: by mail-oa0-f47.google.com with SMTP id o17so5753329oag.34
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 02:33:19 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.27.9 with SMTP id p9mr5973435oeg.72.1361183599456; Mon,
	18 Feb 2013 02:33:19 -0800 (PST)
Received: by 10.60.77.39 with HTTP; Mon, 18 Feb 2013 02:33:19 -0800 (PST)
In-Reply-To: <511D18D8.10605@citrix.com>
References: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
	<511D18D8.10605@citrix.com>
Date: Mon, 18 Feb 2013 11:33:19 +0100
Message-ID: <CANO7gZcE6YxVx7MPDqGJJUBwv0Y+kyfKoQxR3V=eBwS+gSHPSQ@mail.gmail.com>
From: Sander Bogaert <sander.bogaert@elis.ugent.be>
To: Anthony PERARD <anthony.perard@citrix.com>
X-Miltered: at jchkm3 with ID 51220379.003 by Joe's j-chkmail
	(http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 51220379.003 from
	mail.elis.UGent.be/mail.elis.UGent.be/157.193.206.48/mail.elis.ugent.be/<sander.bogaert@elis.ugent.be>
X-j-chkmail-Score: MSGID : 51220379.003 on smtp3.ugent.be : j-chkmail score :
	. : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2800408660310514137=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2800408660310514137==
Content-Type: multipart/alternative; boundary=e89a8fb2062eeb735404d5fd402b

--e89a8fb2062eeb735404d5fd402b
Content-Type: text/plain; charset=ISO-8859-1

On 14 February 2013 18:03, Anthony PERARD <anthony.perard@citrix.com> wrote:

> On 14/02/13 15:09, Sander Bogaert wrote:
> > Hi,
> >
> > I'm trying to get Xen working on the Arndale Board
>
> Hi, thanks for trying :).
>
> > using these
> > instructions:
> >
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale
>
> Sorry, this wiki page is probably not complete yet.
>
> > When trying to build the Linux kernel from Linaro,
> >
> http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
> > (
> > configured as specified on the Xen wiki page ) I run into the following
> > error while compiling:
> >
> > *drivers/xen/xenbus/xenbus_client.c: In function
> > 'xenbus_map_ring_valloc_hvm':*
> > *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of
> > function 'page_to_section' [-Werror=implicit-function-declaration]*
> > *cc1: some warnings being treated as errors*
> > *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*
> >
> > I was wondering if anyone else ran into this and if so how best to solve
> it.
>
> Yes, I've got a patch for it:
> diff --git a/drivers/xen/xenbus/xenbus_client.c
> b/drivers/xen/xenbus/xenbus_client.c
> index bcf3ba4..686142d 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -35,6 +35,7 @@
>  #include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/export.h>
> +#include <linux/mm.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/page.h>
>  #include <xen/interface/xen.h>
>

Thanks, this fixes the compilation problem.


>
>
> > Booting Xen on the board hangs on "Turning on paging", is this related to
> > not having a dom0?
>
> Should not be, there is many things printed by Xen before it is trying
> to boot dom0, and it would say that it can not find a dom0.
>
> > *...*
> > *Startinrrrrrrrrrrrrrrrr- UART enabled -*
> > *- CPU 00000000 booting -*
> > *- Started in Hyp mode -*
> > *- Zero BSS -*
> > *- Setting up control registers -*
> > *- Turning on paging -*
>
> All right, I've been able to reproduce the behaviour. Are you starting
> Xen using the u-boot command "go"? Because this does not work with me.
> It gave me some headache sometime ago. The command that works is "bootm
> $xen_addr -"
> So, I'm curious, how do you start Xen on the board?
>
> Here is what env I have on u-boot:
> ipaddr=10.y.y.y
> ipconfig=10.y.y.y
> kernel_addr_r=0x40007000
> serverip=10.x.x.x
> tftp_path=10.x.x.x:pxelinux.cfg
> usbethaddr=00:40:5c:26:0a:5b
> ethaddr=00:40:5c:26:0a:5b
> xen_addr_r=0x50000000
> bootcmd_load_linux=tftpboot 0x40007000 10.80.3.61:
> pxelinux.cfg/linux-zImage
> boot_xen=run bootcmd_load_linux; tftpboot $xen_addr_r
> $tftp_path/xen-uImage; bootm $xen_addr_r -
> bootcmd=run boot_xen
>
> with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp
> server (or PXE server).
>
> By the way, I've pushed a new branch: arndale-2013-02-13 which fix few
> things.
>

This is the branch I've been using so far, I have been monitoring the
repository for updates too and this still seems to be the latest right?


>
> This should make you pass the "turning on paging" step.
>

I'm still stuck at this step. Here is my environement:

ARNDALE5250 # pri
baudrate=115200
boot_xen=run fatload_cmd; bootm 0x50000000 -
bootargs=root=/dev/mmcblk1p1   rw rootwait console=ttySAC2,115200n8 init
--no-log
bootcmd=run boot_xen
bootdelay=3
dt_addr_r=0x42000000
ethact=asx0
fatload_cmd=fatload mmc0 0 40007000 linaroarndalekernel;fatload mmc0 0
42000000 dt.dtb;fatload mmc0 0 50000000 xen_uimage
filesize=88308
kernel_addr_r=0x40007000
preboot=usb start
stderr=serial
stdin=serial
stdout=serial
usbethaddr=00:40:5c:26:0a:5b
xen_addr_r=0x50000000

Environment size: 514/16380 bytes

A big difference is that I'm not trying to boot over PXE, instead I'm using
the microSD card to load all the files. It has a FAT partition which I load
from ( as you can see in the env ). I'm still stuck at the same stage, any
ideas? I just try 'run boot_xen' to boot. I took the 0x50000000 from your
environement.

Two other questions;

* Don't we need to supply a device tree somewhere?
* I read on the wiki (
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale ):
"So don't expect to have a usable dom0 yet." and was wondering if this is
still the case or if someone has a working installation already. If not,
can I see the progress somewhere ( notes? ) or can you tell me what the
current problems are?



>
> After that, you will probably need few patches for Linux. I'll push them
> later.
>
> Have fun,
>
> --
> Anthony PERARD
>

Thanks a lot for your help so far!

Sander

--e89a8fb2062eeb735404d5fd402b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 14 February 2013 18:03, Anthony PERARD <span dir=3D"ltr=
">&lt;<a href=3D"mailto:anthony.perard@citrix.com" target=3D"_blank">anthon=
y.perard@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On 14/02/13 15:09, Sander Bogaert wrote:=
<br>

&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m trying to get Xen working on the Arndale Board<br>
<br>
</div>Hi, thanks for trying :).<br>
<div class=3D"im"><br>
&gt; using these<br>
&gt; instructions:<br>
&gt; <a href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Exte=
nsions/Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_V=
irtualization_Extensions/Arndale</a><br>
<br>
</div>Sorry, this wiki page is probably not complete yet.<br>
<div class=3D"im"><br>
&gt; When trying to build the Linux kernel from Linaro,<br>
&gt; <a href=3D"http://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_sta=
ble.git;a=3Dshortlog;h=3Drefs/heads/lue_arndale_3.7" target=3D"_blank">http=
://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_stable.git;a=3Dshortlog=
;h=3Drefs/heads/lue_arndale_3.7</a><br>

&gt; (<br>
&gt; configured as specified on the Xen wiki page ) I run into the followin=
g<br>
&gt; error while compiling:<br>
&gt;<br>
</div>&gt; *drivers/xen/xenbus/xenbus_client.c: In function<br>
&gt; &#39;xenbus_map_ring_valloc_hvm&#39;:*<br>
&gt; *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration=
 of<br>
&gt; function &#39;page_to_section&#39; [-Werror=3Dimplicit-function-declar=
ation]*<br>
&gt; *cc1: some warnings being treated as errors*<br>
&gt; *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*<br>
<div class=3D"im">&gt;<br>
&gt; I was wondering if anyone else ran into this and if so how best to sol=
ve it.<br>
<br>
</div>Yes, I&#39;ve got a patch for it:<br>
diff --git a/drivers/xen/xenbus/xenbus_client.c<br>
b/drivers/xen/xenbus/xenbus_client.c<br>
index bcf3ba4..686142d 100644<br>
--- a/drivers/xen/xenbus/xenbus_client.c<br>
+++ b/drivers/xen/xenbus/xenbus_client.c<br>
@@ -35,6 +35,7 @@<br>
=A0#include &lt;linux/spinlock.h&gt;<br>
=A0#include &lt;linux/vmalloc.h&gt;<br>
=A0#include &lt;linux/export.h&gt;<br>
+#include &lt;linux/mm.h&gt;<br>
=A0#include &lt;asm/xen/hypervisor.h&gt;<br>
=A0#include &lt;asm/xen/page.h&gt;<br>
=A0#include &lt;xen/interface/xen.h&gt;<br></blockquote><div><br></div><div=
><span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px=
">Thanks, this fixes the compilation problem.</span></div><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">

<div class=3D"im"><br>
<br>
&gt; Booting Xen on the board hangs on &quot;Turning on paging&quot;, is th=
is related to<br>
&gt; not having a dom0?<br>
<br>
</div>Should not be, there is many things printed by Xen before it is tryin=
g<br>
to boot dom0, and it would say that it can not find a dom0.<br>
<br>
&gt; *...*<br>
&gt; *Startinrrrrrrrrrrrrrrrr- UART enabled -*<br>
&gt; *- CPU 00000000 booting -*<br>
&gt; *- Started in Hyp mode -*<br>
&gt; *- Zero BSS -*<br>
&gt; *- Setting up control registers -*<br>
&gt; *- Turning on paging -*<br>
<br>
All right, I&#39;ve been able to reproduce the behaviour. Are you starting<=
br>
Xen using the u-boot command &quot;go&quot;? Because this does not work wit=
h me.<br>
It gave me some headache sometime ago. The command that works is &quot;boot=
m<br>
$xen_addr -&quot;<br>
So, I&#39;m curious, how do you start Xen on the board?<br>
<br>
Here is what env I have on u-boot:<br>
ipaddr=3D10.y.y.y<br>
ipconfig=3D10.y.y.y<br>
kernel_addr_r=3D0x40007000<br>
serverip=3D10.x.x.x<br>
tftp_path=3D10.x.x.x:pxelinux.cfg<br>
usbethaddr=3D00:40:5c:26:0a:5b<br>
ethaddr=3D00:40:5c:26:0a:5b<br>
xen_addr_r=3D0x50000000<br>
bootcmd_load_linux=3Dtftpboot 0x40007000 10.80.3.61:pxelinux.cfg/linux-zIma=
ge<br>
boot_xen=3Drun bootcmd_load_linux; tftpboot $xen_addr_r<br>
$tftp_path/xen-uImage; bootm $xen_addr_r -<br>
bootcmd=3Drun boot_xen<br>
<br>
with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp<br>
server (or PXE server).<br>
<br>
By the way, I&#39;ve pushed a new branch: arndale-2013-02-13 which fix few<=
br>
things.<br></blockquote><div><br></div><div><span style=3D"font-family:aria=
l,sans-serif;font-size:13.333333969116211px">This is the branch I&#39;ve be=
en using so far, I have been monitoring the repository for updates too and =
this still seems to be the latest right?</span></div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<br>
This should make you pass the &quot;turning on paging&quot; step.<br></bloc=
kquote><div><br></div><div class=3D"gmail_extra" style=3D"font-family:arial=
,sans-serif;font-size:13.333333969116211px"><div class=3D"gmail_quote"><div=
>
I&#39;m still stuck at this step. Here is my environement:</div><div><br></=
div><div>ARNDALE5250 # pri</div><div>baudrate=3D115200</div><div>boot_xen=
=3Drun fatload_cmd; bootm 0x50000000 -</div><div>bootargs=3Droot=3D/dev/mmc=
blk1p1 =A0 rw rootwait console=3DttySAC2,115200n8 init --no-log</div>
<div>bootcmd=3Drun boot_xen</div><div>bootdelay=3D3</div><div>dt_addr_r=3D0=
x42000000</div><div>ethact=3Dasx0</div><div>fatload_cmd=3Dfatload mmc0 0 40=
007000 linaroarndalekernel;fatload mmc0 0 42000000 dt.dtb;fatload mmc0 0 50=
000000 xen_uimage</div>
<div>filesize=3D88308</div><div>kernel_addr_r=3D0x40007000</div><div>preboo=
t=3Dusb start</div><div>stderr=3Dserial</div><div>stdin=3Dserial</div><div>=
stdout=3Dserial</div><div class=3D"im">usbethaddr=3D00:40:5c:26:0a:5b</div>=
<div>xen_addr_r=3D0x50000000</div>
<div><br></div><div>Environment size: 514/16380 bytes</div><div><br></div><=
div>A big difference is that I&#39;m not trying to boot over PXE, instead I=
&#39;m using the microSD card to load all the files. It has a FAT partition=
 which I load from ( as you can see in the env ). I&#39;m still stuck at th=
e same stage, any ideas? I just try &#39;run boot_xen&#39; to boot. I took =
the 0x50000000 from your environement.</div>
<div><br></div><div>Two other questions;=A0</div></div></div><blockquote st=
yle=3D"font-family:arial,sans-serif;font-size:13.333333969116211px;margin:0=
px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote">
* Don&#39;t we need to supply a device tree somewhere?=A0</div></div><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">* I read on the wiki (=A0<a=
 href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/=
Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtuali=
zation_Extensions/Arndale</a>=A0): &quot;So don&#39;t expect to have a usab=
le dom0 yet.&quot; and was wondering if this is still the case or if someon=
e has a working installation already. If not, can I see the progress somewh=
ere ( notes? ) or can you tell me what the current problems are?</div>
</div></blockquote><div><span style=3D"font-family:arial,sans-serif;font-si=
ze:13.333333969116211px">=A0</span>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
After that, you will probably need few patches for Linux. I&#39;ll push the=
m<br>
later.<br>
<br>
Have fun,<br>
<span class=3D""><font color=3D"#888888"><br>
--<br>
Anthony PERARD<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra"><span=
 style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">Than=
ks a lot for your help so far!</span><br></div><div class=3D"gmail_extra"><=
span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">=
<br>
</span></div><div class=3D"gmail_extra" style><span style=3D"font-family:ar=
ial,sans-serif;font-size:13.333333969116211px">Sander</span></div></div>

--e89a8fb2062eeb735404d5fd402b--


--===============2800408660310514137==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2800408660310514137==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 10:33:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O2Q-0003zV-D3; Mon, 18 Feb 2013 10:33:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sander.bogaert@elis.ugent.be>) id 1U7O2O-0003zM-PW
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:33:33 +0000
Received: from [193.109.254.147:8482] by server-3.bemta-14.messagelabs.com id
	7A/F6-22141-C7302215; Mon, 18 Feb 2013 10:33:32 +0000
X-Env-Sender: sander.bogaert@elis.ugent.be
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361183610!1049176!1
X-Originating-IP: [157.193.49.127]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU3LjE5My40OS4xMjcgPT4gMTcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28338 invoked from network); 18 Feb 2013 10:33:31 -0000
Received: from smtp3.ugent.be (HELO smtp3.ugent.be) (157.193.49.127)
	by server-7.tower-27.messagelabs.com with SMTP;
	18 Feb 2013 10:33:31 -0000
Received: from localhost (mcheck2.ugent.be [157.193.49.249])
	by smtp3.ugent.be (Postfix) with ESMTP id CEF5DC448
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:30 +0100 (CET)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.ugent.be ([157.193.49.127])
	by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new,
	port 10024) with ESMTP id XBb6w_jRaEYr for <xen-devel@lists.xen.org>;
	Mon, 18 Feb 2013 11:33:30 +0100 (CET)
Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48])
	by smtp3.ugent.be (Postfix) with ESMTP id F3425C451
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:29 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mail.elis.ugent.be (Postfix) with ESMTP id E85EAAA30043
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at elis.ugent.be
Received: from mail.elis.ugent.be ([127.0.0.1])
	by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8XygGBDOaay9 for <xen-devel@lists.xen.org>;
	Mon, 18 Feb 2013 11:33:21 +0100 (CET)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com
	[209.85.219.47])
	by mail.elis.ugent.be (Postfix) with ESMTP id 236F1918C63
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 11:33:21 +0100 (CET)
Received: by mail-oa0-f47.google.com with SMTP id o17so5753329oag.34
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 02:33:19 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.27.9 with SMTP id p9mr5973435oeg.72.1361183599456; Mon,
	18 Feb 2013 02:33:19 -0800 (PST)
Received: by 10.60.77.39 with HTTP; Mon, 18 Feb 2013 02:33:19 -0800 (PST)
In-Reply-To: <511D18D8.10605@citrix.com>
References: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
	<511D18D8.10605@citrix.com>
Date: Mon, 18 Feb 2013 11:33:19 +0100
Message-ID: <CANO7gZcE6YxVx7MPDqGJJUBwv0Y+kyfKoQxR3V=eBwS+gSHPSQ@mail.gmail.com>
From: Sander Bogaert <sander.bogaert@elis.ugent.be>
To: Anthony PERARD <anthony.perard@citrix.com>
X-Miltered: at jchkm3 with ID 51220379.003 by Joe's j-chkmail
	(http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 51220379.003 from
	mail.elis.UGent.be/mail.elis.UGent.be/157.193.206.48/mail.elis.ugent.be/<sander.bogaert@elis.ugent.be>
X-j-chkmail-Score: MSGID : 51220379.003 on smtp3.ugent.be : j-chkmail score :
	. : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2800408660310514137=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2800408660310514137==
Content-Type: multipart/alternative; boundary=e89a8fb2062eeb735404d5fd402b

--e89a8fb2062eeb735404d5fd402b
Content-Type: text/plain; charset=ISO-8859-1

On 14 February 2013 18:03, Anthony PERARD <anthony.perard@citrix.com> wrote:

> On 14/02/13 15:09, Sander Bogaert wrote:
> > Hi,
> >
> > I'm trying to get Xen working on the Arndale Board
>
> Hi, thanks for trying :).
>
> > using these
> > instructions:
> >
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale
>
> Sorry, this wiki page is probably not complete yet.
>
> > When trying to build the Linux kernel from Linaro,
> >
> http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
> > (
> > configured as specified on the Xen wiki page ) I run into the following
> > error while compiling:
> >
> > *drivers/xen/xenbus/xenbus_client.c: In function
> > 'xenbus_map_ring_valloc_hvm':*
> > *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration of
> > function 'page_to_section' [-Werror=implicit-function-declaration]*
> > *cc1: some warnings being treated as errors*
> > *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*
> >
> > I was wondering if anyone else ran into this and if so how best to solve
> it.
>
> Yes, I've got a patch for it:
> diff --git a/drivers/xen/xenbus/xenbus_client.c
> b/drivers/xen/xenbus/xenbus_client.c
> index bcf3ba4..686142d 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -35,6 +35,7 @@
>  #include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/export.h>
> +#include <linux/mm.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/page.h>
>  #include <xen/interface/xen.h>
>

Thanks, this fixes the compilation problem.


>
>
> > Booting Xen on the board hangs on "Turning on paging", is this related to
> > not having a dom0?
>
> Should not be, there is many things printed by Xen before it is trying
> to boot dom0, and it would say that it can not find a dom0.
>
> > *...*
> > *Startinrrrrrrrrrrrrrrrr- UART enabled -*
> > *- CPU 00000000 booting -*
> > *- Started in Hyp mode -*
> > *- Zero BSS -*
> > *- Setting up control registers -*
> > *- Turning on paging -*
>
> All right, I've been able to reproduce the behaviour. Are you starting
> Xen using the u-boot command "go"? Because this does not work with me.
> It gave me some headache sometime ago. The command that works is "bootm
> $xen_addr -"
> So, I'm curious, how do you start Xen on the board?
>
> Here is what env I have on u-boot:
> ipaddr=10.y.y.y
> ipconfig=10.y.y.y
> kernel_addr_r=0x40007000
> serverip=10.x.x.x
> tftp_path=10.x.x.x:pxelinux.cfg
> usbethaddr=00:40:5c:26:0a:5b
> ethaddr=00:40:5c:26:0a:5b
> xen_addr_r=0x50000000
> bootcmd_load_linux=tftpboot 0x40007000 10.80.3.61:
> pxelinux.cfg/linux-zImage
> boot_xen=run bootcmd_load_linux; tftpboot $xen_addr_r
> $tftp_path/xen-uImage; bootm $xen_addr_r -
> bootcmd=run boot_xen
>
> with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp
> server (or PXE server).
>
> By the way, I've pushed a new branch: arndale-2013-02-13 which fix few
> things.
>

This is the branch I've been using so far, I have been monitoring the
repository for updates too and this still seems to be the latest right?


>
> This should make you pass the "turning on paging" step.
>

I'm still stuck at this step. Here is my environement:

ARNDALE5250 # pri
baudrate=115200
boot_xen=run fatload_cmd; bootm 0x50000000 -
bootargs=root=/dev/mmcblk1p1   rw rootwait console=ttySAC2,115200n8 init
--no-log
bootcmd=run boot_xen
bootdelay=3
dt_addr_r=0x42000000
ethact=asx0
fatload_cmd=fatload mmc0 0 40007000 linaroarndalekernel;fatload mmc0 0
42000000 dt.dtb;fatload mmc0 0 50000000 xen_uimage
filesize=88308
kernel_addr_r=0x40007000
preboot=usb start
stderr=serial
stdin=serial
stdout=serial
usbethaddr=00:40:5c:26:0a:5b
xen_addr_r=0x50000000

Environment size: 514/16380 bytes

A big difference is that I'm not trying to boot over PXE, instead I'm using
the microSD card to load all the files. It has a FAT partition which I load
from ( as you can see in the env ). I'm still stuck at the same stage, any
ideas? I just try 'run boot_xen' to boot. I took the 0x50000000 from your
environement.

Two other questions;

* Don't we need to supply a device tree somewhere?
* I read on the wiki (
http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale ):
"So don't expect to have a usable dom0 yet." and was wondering if this is
still the case or if someone has a working installation already. If not,
can I see the progress somewhere ( notes? ) or can you tell me what the
current problems are?



>
> After that, you will probably need few patches for Linux. I'll push them
> later.
>
> Have fun,
>
> --
> Anthony PERARD
>

Thanks a lot for your help so far!

Sander

--e89a8fb2062eeb735404d5fd402b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 14 February 2013 18:03, Anthony PERARD <span dir=3D"ltr=
">&lt;<a href=3D"mailto:anthony.perard@citrix.com" target=3D"_blank">anthon=
y.perard@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On 14/02/13 15:09, Sander Bogaert wrote:=
<br>

&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m trying to get Xen working on the Arndale Board<br>
<br>
</div>Hi, thanks for trying :).<br>
<div class=3D"im"><br>
&gt; using these<br>
&gt; instructions:<br>
&gt; <a href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Exte=
nsions/Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_V=
irtualization_Extensions/Arndale</a><br>
<br>
</div>Sorry, this wiki page is probably not complete yet.<br>
<div class=3D"im"><br>
&gt; When trying to build the Linux kernel from Linaro,<br>
&gt; <a href=3D"http://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_sta=
ble.git;a=3Dshortlog;h=3Drefs/heads/lue_arndale_3.7" target=3D"_blank">http=
://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_stable.git;a=3Dshortlog=
;h=3Drefs/heads/lue_arndale_3.7</a><br>

&gt; (<br>
&gt; configured as specified on the Xen wiki page ) I run into the followin=
g<br>
&gt; error while compiling:<br>
&gt;<br>
</div>&gt; *drivers/xen/xenbus/xenbus_client.c: In function<br>
&gt; &#39;xenbus_map_ring_valloc_hvm&#39;:*<br>
&gt; *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration=
 of<br>
&gt; function &#39;page_to_section&#39; [-Werror=3Dimplicit-function-declar=
ation]*<br>
&gt; *cc1: some warnings being treated as errors*<br>
&gt; *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*<br>
<div class=3D"im">&gt;<br>
&gt; I was wondering if anyone else ran into this and if so how best to sol=
ve it.<br>
<br>
</div>Yes, I&#39;ve got a patch for it:<br>
diff --git a/drivers/xen/xenbus/xenbus_client.c<br>
b/drivers/xen/xenbus/xenbus_client.c<br>
index bcf3ba4..686142d 100644<br>
--- a/drivers/xen/xenbus/xenbus_client.c<br>
+++ b/drivers/xen/xenbus/xenbus_client.c<br>
@@ -35,6 +35,7 @@<br>
=A0#include &lt;linux/spinlock.h&gt;<br>
=A0#include &lt;linux/vmalloc.h&gt;<br>
=A0#include &lt;linux/export.h&gt;<br>
+#include &lt;linux/mm.h&gt;<br>
=A0#include &lt;asm/xen/hypervisor.h&gt;<br>
=A0#include &lt;asm/xen/page.h&gt;<br>
=A0#include &lt;xen/interface/xen.h&gt;<br></blockquote><div><br></div><div=
><span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px=
">Thanks, this fixes the compilation problem.</span></div><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">

<div class=3D"im"><br>
<br>
&gt; Booting Xen on the board hangs on &quot;Turning on paging&quot;, is th=
is related to<br>
&gt; not having a dom0?<br>
<br>
</div>Should not be, there is many things printed by Xen before it is tryin=
g<br>
to boot dom0, and it would say that it can not find a dom0.<br>
<br>
&gt; *...*<br>
&gt; *Startinrrrrrrrrrrrrrrrr- UART enabled -*<br>
&gt; *- CPU 00000000 booting -*<br>
&gt; *- Started in Hyp mode -*<br>
&gt; *- Zero BSS -*<br>
&gt; *- Setting up control registers -*<br>
&gt; *- Turning on paging -*<br>
<br>
All right, I&#39;ve been able to reproduce the behaviour. Are you starting<=
br>
Xen using the u-boot command &quot;go&quot;? Because this does not work wit=
h me.<br>
It gave me some headache sometime ago. The command that works is &quot;boot=
m<br>
$xen_addr -&quot;<br>
So, I&#39;m curious, how do you start Xen on the board?<br>
<br>
Here is what env I have on u-boot:<br>
ipaddr=3D10.y.y.y<br>
ipconfig=3D10.y.y.y<br>
kernel_addr_r=3D0x40007000<br>
serverip=3D10.x.x.x<br>
tftp_path=3D10.x.x.x:pxelinux.cfg<br>
usbethaddr=3D00:40:5c:26:0a:5b<br>
ethaddr=3D00:40:5c:26:0a:5b<br>
xen_addr_r=3D0x50000000<br>
bootcmd_load_linux=3Dtftpboot 0x40007000 10.80.3.61:pxelinux.cfg/linux-zIma=
ge<br>
boot_xen=3Drun bootcmd_load_linux; tftpboot $xen_addr_r<br>
$tftp_path/xen-uImage; bootm $xen_addr_r -<br>
bootcmd=3Drun boot_xen<br>
<br>
with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp<br>
server (or PXE server).<br>
<br>
By the way, I&#39;ve pushed a new branch: arndale-2013-02-13 which fix few<=
br>
things.<br></blockquote><div><br></div><div><span style=3D"font-family:aria=
l,sans-serif;font-size:13.333333969116211px">This is the branch I&#39;ve be=
en using so far, I have been monitoring the repository for updates too and =
this still seems to be the latest right?</span></div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<br>
This should make you pass the &quot;turning on paging&quot; step.<br></bloc=
kquote><div><br></div><div class=3D"gmail_extra" style=3D"font-family:arial=
,sans-serif;font-size:13.333333969116211px"><div class=3D"gmail_quote"><div=
>
I&#39;m still stuck at this step. Here is my environement:</div><div><br></=
div><div>ARNDALE5250 # pri</div><div>baudrate=3D115200</div><div>boot_xen=
=3Drun fatload_cmd; bootm 0x50000000 -</div><div>bootargs=3Droot=3D/dev/mmc=
blk1p1 =A0 rw rootwait console=3DttySAC2,115200n8 init --no-log</div>
<div>bootcmd=3Drun boot_xen</div><div>bootdelay=3D3</div><div>dt_addr_r=3D0=
x42000000</div><div>ethact=3Dasx0</div><div>fatload_cmd=3Dfatload mmc0 0 40=
007000 linaroarndalekernel;fatload mmc0 0 42000000 dt.dtb;fatload mmc0 0 50=
000000 xen_uimage</div>
<div>filesize=3D88308</div><div>kernel_addr_r=3D0x40007000</div><div>preboo=
t=3Dusb start</div><div>stderr=3Dserial</div><div>stdin=3Dserial</div><div>=
stdout=3Dserial</div><div class=3D"im">usbethaddr=3D00:40:5c:26:0a:5b</div>=
<div>xen_addr_r=3D0x50000000</div>
<div><br></div><div>Environment size: 514/16380 bytes</div><div><br></div><=
div>A big difference is that I&#39;m not trying to boot over PXE, instead I=
&#39;m using the microSD card to load all the files. It has a FAT partition=
 which I load from ( as you can see in the env ). I&#39;m still stuck at th=
e same stage, any ideas? I just try &#39;run boot_xen&#39; to boot. I took =
the 0x50000000 from your environement.</div>
<div><br></div><div>Two other questions;=A0</div></div></div><blockquote st=
yle=3D"font-family:arial,sans-serif;font-size:13.333333969116211px;margin:0=
px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote">
* Don&#39;t we need to supply a device tree somewhere?=A0</div></div><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">* I read on the wiki (=A0<a=
 href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/=
Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtuali=
zation_Extensions/Arndale</a>=A0): &quot;So don&#39;t expect to have a usab=
le dom0 yet.&quot; and was wondering if this is still the case or if someon=
e has a working installation already. If not, can I see the progress somewh=
ere ( notes? ) or can you tell me what the current problems are?</div>
</div></blockquote><div><span style=3D"font-family:arial,sans-serif;font-si=
ze:13.333333969116211px">=A0</span>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
After that, you will probably need few patches for Linux. I&#39;ll push the=
m<br>
later.<br>
<br>
Have fun,<br>
<span class=3D""><font color=3D"#888888"><br>
--<br>
Anthony PERARD<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra"><span=
 style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">Than=
ks a lot for your help so far!</span><br></div><div class=3D"gmail_extra"><=
span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">=
<br>
</span></div><div class=3D"gmail_extra" style><span style=3D"font-family:ar=
ial,sans-serif;font-size:13.333333969116211px">Sander</span></div></div>

--e89a8fb2062eeb735404d5fd402b--


--===============2800408660310514137==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2800408660310514137==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 10:34:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O2q-000428-8F; Mon, 18 Feb 2013 10:34: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 1U7O2p-00041m-2B
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:33:59 +0000
Received: from [85.158.138.51:17160] by server-1.bemta-3.messagelabs.com id
	DC/98-08955-69302215; Mon, 18 Feb 2013 10:33:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361183637!27956767!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13733 invoked from network); 18 Feb 2013 10:33:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:33:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1563805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:33: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.297.1;
	Mon, 18 Feb 2013 10:33:57 +0000
Message-ID: <1361183635.31407.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joe Jin <joe.jin@oracle.com>
Date: Mon, 18 Feb 2013 10:33:55 +0000
In-Reply-To: <511F1B6D.2010502@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
	<511F1B6D.2010502@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 Sat, 2013-02-16 at 05:38 +0000, Joe Jin wrote:
> On 02/05/13 17:42, Ian Campbell wrote:
> > On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
> >> > execute xl-destroy twice crashed my server!
> > Can you give more details please.
> > 
> Hi Ian,
> 
> Sorry the server not available for test now.

OK, please let us know if/when you can gather details. Oh I see you
already have, thanks!

> Would you please help to review my patch for xm-destroy?

xend is deprecated and I'm afraid I don't have many spare cycles to
spend on it. I think really it needs to be down to those who want to
keep xend alive to review each others patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:34:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O2q-000428-8F; Mon, 18 Feb 2013 10:34: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 1U7O2p-00041m-2B
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:33:59 +0000
Received: from [85.158.138.51:17160] by server-1.bemta-3.messagelabs.com id
	DC/98-08955-69302215; Mon, 18 Feb 2013 10:33:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361183637!27956767!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13733 invoked from network); 18 Feb 2013 10:33:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:33:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1563805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:33: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.297.1;
	Mon, 18 Feb 2013 10:33:57 +0000
Message-ID: <1361183635.31407.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joe Jin <joe.jin@oracle.com>
Date: Mon, 18 Feb 2013 10:33:55 +0000
In-Reply-To: <511F1B6D.2010502@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
	<511F1B6D.2010502@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 Sat, 2013-02-16 at 05:38 +0000, Joe Jin wrote:
> On 02/05/13 17:42, Ian Campbell wrote:
> > On Tue, 2013-02-05 at 06:47 +0000, Joe Jin wrote:
> >> > execute xl-destroy twice crashed my server!
> > Can you give more details please.
> > 
> Hi Ian,
> 
> Sorry the server not available for test now.

OK, please let us know if/when you can gather details. Oh I see you
already have, thanks!

> Would you please help to review my patch for xm-destroy?

xend is deprecated and I'm afraid I don't have many spare cycles to
spend on it. I think really it needs to be down to those who want to
keep xend alive to review each others patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:34:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:34: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 1U7O2p-000421-RI; Mon, 18 Feb 2013 10:33:59 +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 1U7O2o-00041k-To
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:33:59 +0000
Received: from [85.158.138.51:17152] by server-12.bemta-3.messagelabs.com id
	12/27-05889-69302215; Mon, 18 Feb 2013 10:33:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361183637!26231258!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27400 invoked from network); 18 Feb 2013 10:33:57 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-15.tower-174.messagelabs.com with SMTP;
	18 Feb 2013 10:33:57 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 58F25643790;
	Mon, 18 Feb 2013 11:33:56 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 18 Feb 2013 11:33:45 +0100
Message-Id: <1361183625-3640-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v10] tools/libxl: Add qxl vga interface support
	for upstream 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="qxl"

Changes from v8:
- vga=qxl instead of qxl=1 to use it.
- Show an error and exit if vga="qxl" without qemu upstream.
- Other small improvements.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
---
 docs/man/xl.cfg.pod.5       |   10 +++++++++-
 tools/libxl/libxl_create.c  |   16 ++++++++++++++++
 tools/libxl/libxl_dm.c      |   13 +++++++++++++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    3 +++
 5 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9c5def4..25523c9 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1003,6 +1003,9 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
+For B<qxl> vga, the default is both default and minimal 128MB.
+If B<videoram> is set less than 128MB, an error will be triggered.
+
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -1014,9 +1017,14 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus).
+Selects the emulated video card (stdvga|cirrus|qxl).
 The default is cirrus.
 
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.
+
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa81f88..eea885c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -198,6 +198,22 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
 
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->device_model_version ==
+               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                    b_info->video_memkb = (128 * 1024);
+                }else if (b_info->video_memkb < (128 * 1024)) {
+                    LOG(ERROR,
+                    "128 Mib videoram is the minimum for qxl default");
+                    return ERROR_INVAL;
+                }
+            } else {
+                LOG(ERROR,"qemu upstream required for qxl vga");
+                return ERROR_INVAL;
+            }
+        }
+
         if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
             b_info->device_model_version ==
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2c99bd..59fc86a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -440,6 +442,17 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                 NULL);
             }
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            /*QXL have 2 ram regions, ram and vram*/
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), "-global",
+                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), NULL);
+            }
+            break;
         }
 
         if (b_info->u.hvm.boot) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 89a8030..5b080ed 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..f36a293 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1481,6 +1481,9 @@ skip_vfb:
             } else if (!strcmp(buf, "cirrus")) {
                 b_info->u.hvm.vga.kind
                 = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }else if (!strcmp(buf, "qxl")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
                 fprintf(stderr,
                 "Unknown vga \"%s\" specified\n", buf);
-- 
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 Mon Feb 18 10:34:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:34: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 1U7O2p-000421-RI; Mon, 18 Feb 2013 10:33:59 +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 1U7O2o-00041k-To
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:33:59 +0000
Received: from [85.158.138.51:17152] by server-12.bemta-3.messagelabs.com id
	12/27-05889-69302215; Mon, 18 Feb 2013 10:33:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361183637!26231258!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27400 invoked from network); 18 Feb 2013 10:33:57 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-15.tower-174.messagelabs.com with SMTP;
	18 Feb 2013 10:33:57 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 58F25643790;
	Mon, 18 Feb 2013 11:33:56 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 18 Feb 2013 11:33:45 +0100
Message-Id: <1361183625-3640-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v10] tools/libxl: Add qxl vga interface support
	for upstream 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="qxl"

Changes from v8:
- vga=qxl instead of qxl=1 to use it.
- Show an error and exit if vga="qxl" without qemu upstream.
- Other small improvements.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
---
 docs/man/xl.cfg.pod.5       |   10 +++++++++-
 tools/libxl/libxl_create.c  |   16 ++++++++++++++++
 tools/libxl/libxl_dm.c      |   13 +++++++++++++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    3 +++
 5 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9c5def4..25523c9 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1003,6 +1003,9 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
+For B<qxl> vga, the default is both default and minimal 128MB.
+If B<videoram> is set less than 128MB, an error will be triggered.
+
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -1014,9 +1017,14 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus).
+Selects the emulated video card (stdvga|cirrus|qxl).
 The default is cirrus.
 
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.
+
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa81f88..eea885c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -198,6 +198,22 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
 
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->device_model_version ==
+               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                    b_info->video_memkb = (128 * 1024);
+                }else if (b_info->video_memkb < (128 * 1024)) {
+                    LOG(ERROR,
+                    "128 Mib videoram is the minimum for qxl default");
+                    return ERROR_INVAL;
+                }
+            } else {
+                LOG(ERROR,"qemu upstream required for qxl vga");
+                return ERROR_INVAL;
+            }
+        }
+
         if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
             b_info->device_model_version ==
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2c99bd..59fc86a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -440,6 +442,17 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                 NULL);
             }
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            /*QXL have 2 ram regions, ram and vram*/
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), "-global",
+                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
+                (b_info->video_memkb/2/1024)), NULL);
+            }
+            break;
         }
 
         if (b_info->u.hvm.boot) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 89a8030..5b080ed 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..f36a293 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1481,6 +1481,9 @@ skip_vfb:
             } else if (!strcmp(buf, "cirrus")) {
                 b_info->u.hvm.vga.kind
                 = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }else if (!strcmp(buf, "qxl")) {
+                b_info->u.hvm.vga.kind
+                = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
                 fprintf(stderr,
                 "Unknown vga \"%s\" specified\n", buf);
-- 
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 Mon Feb 18 10:38:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O79-0004X4-4Y; Mon, 18 Feb 2013 10:38:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herydians@gmail.com>)
	id 1U7O78-0004Wp-Ex; Mon, 18 Feb 2013 10:38:26 +0000
Received: from [85.158.138.51:59053] by server-16.bemta-3.messagelabs.com id
	6D/12-02727-1A402215; Mon, 18 Feb 2013 10:38:25 +0000
X-Env-Sender: herydians@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361183904!20049769!1
X-Originating-IP: [74.125.82.47]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 18 Feb 2013 10:38:24 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:38:24 -0000
Received: by mail-wg0-f47.google.com with SMTP id dr13so4537187wgb.14
	for <multiple recipients>; Mon, 18 Feb 2013 02:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=SpMEUvIIm0NqY5rga6t9hyR7wMN9Qrup5mJFFdaDWj4=;
	b=CMUX5cuCH0wBU+zRg6iiBFwo4HbvN+dFpb+d3Ta2e7k6vWUFUICpKYPPKK4KYmxtBu
	PAIQJhKhDk/0JDQ88ROV2DbOAse6ZVu9uyhq3PNEdShlmVsxQwoCc9DC888u/aMtRm9H
	1ANs8Bsc3p21fPKEMHdZyTz0hYSYh8p/XMMeDTXTLcTER+ER2eiLze4ZIAOL3G3iFDPL
	1pVT2fQ9f0fHVJxtzCVAiTwbCxNJal9mq9hYFz+Hxmp8F7jmJVw8Vo3c/18fLIQaI1QU
	UHA8z1r9B1x3XnMED9WvyP2W8XW53pbRgimejBDdaL3zOpPzG/XocizGi0MAsYxPmr2R
	5zLQ==
MIME-Version: 1.0
X-Received: by 10.194.236.233 with SMTP id ux9mr17814549wjc.36.1361183904021; 
	Mon, 18 Feb 2013 02:38:24 -0800 (PST)
Received: by 10.216.107.132 with HTTP; Mon, 18 Feb 2013 02:38:23 -0800 (PST)
In-Reply-To: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
Date: Mon, 18 Feb 2013 11:38:23 +0100
Message-ID: <CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
From: Hery Dian Septama <herydians@gmail.com>
To: agya naila <agya.naila@gmail.com>
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7168085194524874421=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7168085194524874421==
Content-Type: multipart/alternative; boundary=089e01493ee412bb3c04d5fd5341

--089e01493ee412bb3c04d5fd5341
Content-Type: text/plain; charset=UTF-8

Hello, Anyone have a clue? I have tried but still failed :(

On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com> wrote:

> Dear all,
>
> I am configure my machine to run the remus disk replication. I am using
> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0 and
> DomU.
> I have install the blktap and its work properly with configuration string
> phy or tap2 like this :
> disk = ['phy:/dev/vggroup/DomU,xvda,w']
> or
> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>
> and remus command
>
> remus --no-net myvm mybackuphost
>
>
> However when I change the string as suggested on remus pages to enable the
> disk replication its still failed :
>
> name = "DomU"
> memory = 1024
> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
> vif = ['ip=192.168.1.55,bridge=xenbr0']
> bootloader = "pygrub"
>
> with error messages :
>
> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
> Using config file "/etc/xen/DomU.cfg".
> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed
> (512  )
>
> and on the log file :
>
>
> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line
> 3987, in create_vbd
>     devid = dev_control.createDevice(config)
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> line 174, in createDevice
>     device = TapdiskController.create(params, file)
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> line 286, in create
>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> line 233, in exc
>     (args, rc, out, err))
> TapdiskException: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
> failed (512  )
>
> Any hints and help would very appreciated.
>
> Regards,
>
> Agya
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--089e01493ee412bb3c04d5fd5341
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello, Anyone have a clue? I have tried but still failed :(<br><br><div cla=
ss=3D"gmail_quote">On Sat, Feb 16, 2013 at 6:56 PM, agya naila <span dir=3D=
"ltr">&lt;<a href=3D"mailto:agya.naila@gmail.com" target=3D"_blank">agya.na=
ila@gmail.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">Dear all,<div><br></div><div>I am configure =
my machine to run the remus disk replication. I am using xen 4.2.3 installe=
d from sources and Ubuntu 12.04 64 bit both for Dom0 and DomU.=C2=A0</div>
<div><span style=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sa=
ns-serif">I have install the blktap and its work properly with configuratio=
n string phy or tap2 like this :</span><div style=3D"color:rgb(34,34,34);fo=
nt-size:13px">

<div><font face=3D"courier new, monospace">disk =3D [&#39;phy:/dev/vggroup/=
DomU,xvda,w&#39;]</font></div><div style=3D"font-family:arial,sans-serif">o=
r</div><div><font face=3D"courier new, monospace">disk =3D [&#39;tap2:tapdi=
sk:aio:/dev/vggroup/DomU,xvda,w&#39;]</font></div>

</div><div style=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sa=
ns-serif"><br></div><div style=3D"color:rgb(34,34,34);font-size:13px;font-f=
amily:arial,sans-serif">
and remus command=C2=A0</div><div style=3D"color:rgb(34,34,34);font-size:13=
px;font-family:arial,sans-serif"><br></div><div style=3D"color:rgb(34,34,34=
);font-size:13px">
<span style=3D"color:rgb(96,96,96);font-size:12px"><font face=3D"courier ne=
w, monospace">remus --no-net myvm mybackuphost</font></span></div><div styl=
e=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style=3D"color:rgb(96,96,96);font-family:monospace;font-size:12px"><b=
r></span></div><div style=3D"color:rgb(34,34,34);font-size:13px;font-family=
:arial,sans-serif"><span style=3D"color:rgb(96,96,96);font-family:monospace=
;font-size:12px"><br>

</span></div><div style=3D"color:rgb(34,34,34);font-size:13px;font-family:a=
rial,sans-serif">However when I change the string as suggested on remus pag=
es to enable the disk replication its still failed :</div>
<div style=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:13px"><div><font =
face=3D"courier new, monospace">name =3D &quot;DomU&quot;</font></div>
<div><font face=3D"courier new, monospace">memory =3D 1024</font></div><div=
><font face=3D"courier new, monospace">disk =3D [&#39;tap2:remus:10.10.10.3=
:8002|aio:/dev/vggroup/DomU,xvda,w&#39;] =C2=A0</font></div><div><font face=
=3D"courier new, monospace">vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0=
&#39;]</font></div>

<div><font face=3D"courier new, monospace">bootloader =3D &quot;pygrub&quot=
;</font></div><div style=3D"font-family:arial,sans-serif"><br></div><font f=
ace=3D"arial, sans-serif">with error messages :</font></div><div style=3D"c=
olor:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">

<br></div><div style=3D"color:rgb(34,34,34);font-size:13px"><div><font face=
=3D"courier new, monospace">name1@machine1:~$ sudo xm create -c /etc/xen/Do=
mU.cfg</font></div><div><font face=3D"courier new, monospace">Using config =
file &quot;/etc/xen/DomU.cfg&quot;.</font></div>

<div><font face=3D"courier new, monospace">Error: (&#39;create&#39;, &#39;-=
aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) failed (512 =C2=A0)</fon=
t></div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D=
"font-family:arial,sans-serif">

and on the log file :</div><div style=3D"font-family:arial,sans-serif"><br>=
</div><div><div style=3D"font-family:arial,sans-serif"><br></div><div><font=
 face=3D"courier new, monospace">name1@machine1:~$ sudo sudo tail /var/log/=
xen/xend.log</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 mounted_vbd_uuid =
=3D dom0.create_vbd(vbd, disk);</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xe=
nd/XendDomainInfo.py&quot;, line 3987, in create_vbd</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 devid =3D dev_cont=
rol.createDevice(config)</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/serv=
er/BlktapController.py&quot;, line 174, in createDevice</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 device =3D Tapdisk=
Controller.create(params, file)</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xe=
nd/server/BlktapController.py&quot;, line 286, in create</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 return TapdiskCont=
roller.exc(&#39;create&#39;, &#39;-a%s:%s&#39; % (dtype, image))</font></di=
v><div><font face=3D"courier new, monospace">=C2=A0 File &quot;/usr/local/l=
ib/python2.7/dist-packages/xen/xend/server/BlktapController.py&quot;, line =
233, in exc</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 (args, rc, out, er=
r))</font></div><div><font face=3D"courier new, monospace">TapdiskException=
: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39=
;) failed (512 =C2=A0)</font></div>

</div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"f=
ont-family:arial,sans-serif">Any hints and help would very appreciated.</di=
v><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"font-=
family:arial,sans-serif">

Regards,</div><div style=3D"font-family:arial,sans-serif"><br></div><div st=
yle=3D"font-family:arial,sans-serif">Agya</div><div style=3D"font-family:ar=
ial,sans-serif;outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px"=
>

<br></div></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.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br>

--089e01493ee412bb3c04d5fd5341--


--===============7168085194524874421==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7168085194524874421==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 10:38:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O79-0004X4-4Y; Mon, 18 Feb 2013 10:38:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <herydians@gmail.com>)
	id 1U7O78-0004Wp-Ex; Mon, 18 Feb 2013 10:38:26 +0000
Received: from [85.158.138.51:59053] by server-16.bemta-3.messagelabs.com id
	6D/12-02727-1A402215; Mon, 18 Feb 2013 10:38:25 +0000
X-Env-Sender: herydians@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361183904!20049769!1
X-Originating-IP: [74.125.82.47]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 18 Feb 2013 10:38:24 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:38:24 -0000
Received: by mail-wg0-f47.google.com with SMTP id dr13so4537187wgb.14
	for <multiple recipients>; Mon, 18 Feb 2013 02:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=SpMEUvIIm0NqY5rga6t9hyR7wMN9Qrup5mJFFdaDWj4=;
	b=CMUX5cuCH0wBU+zRg6iiBFwo4HbvN+dFpb+d3Ta2e7k6vWUFUICpKYPPKK4KYmxtBu
	PAIQJhKhDk/0JDQ88ROV2DbOAse6ZVu9uyhq3PNEdShlmVsxQwoCc9DC888u/aMtRm9H
	1ANs8Bsc3p21fPKEMHdZyTz0hYSYh8p/XMMeDTXTLcTER+ER2eiLze4ZIAOL3G3iFDPL
	1pVT2fQ9f0fHVJxtzCVAiTwbCxNJal9mq9hYFz+Hxmp8F7jmJVw8Vo3c/18fLIQaI1QU
	UHA8z1r9B1x3XnMED9WvyP2W8XW53pbRgimejBDdaL3zOpPzG/XocizGi0MAsYxPmr2R
	5zLQ==
MIME-Version: 1.0
X-Received: by 10.194.236.233 with SMTP id ux9mr17814549wjc.36.1361183904021; 
	Mon, 18 Feb 2013 02:38:24 -0800 (PST)
Received: by 10.216.107.132 with HTTP; Mon, 18 Feb 2013 02:38:23 -0800 (PST)
In-Reply-To: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
Date: Mon, 18 Feb 2013 11:38:23 +0100
Message-ID: <CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
From: Hery Dian Septama <herydians@gmail.com>
To: agya naila <agya.naila@gmail.com>
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7168085194524874421=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7168085194524874421==
Content-Type: multipart/alternative; boundary=089e01493ee412bb3c04d5fd5341

--089e01493ee412bb3c04d5fd5341
Content-Type: text/plain; charset=UTF-8

Hello, Anyone have a clue? I have tried but still failed :(

On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com> wrote:

> Dear all,
>
> I am configure my machine to run the remus disk replication. I am using
> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0 and
> DomU.
> I have install the blktap and its work properly with configuration string
> phy or tap2 like this :
> disk = ['phy:/dev/vggroup/DomU,xvda,w']
> or
> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>
> and remus command
>
> remus --no-net myvm mybackuphost
>
>
> However when I change the string as suggested on remus pages to enable the
> disk replication its still failed :
>
> name = "DomU"
> memory = 1024
> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
> vif = ['ip=192.168.1.55,bridge=xenbr0']
> bootloader = "pygrub"
>
> with error messages :
>
> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
> Using config file "/etc/xen/DomU.cfg".
> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed
> (512  )
>
> and on the log file :
>
>
> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line
> 3987, in create_vbd
>     devid = dev_control.createDevice(config)
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> line 174, in createDevice
>     device = TapdiskController.create(params, file)
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> line 286, in create
>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
>   File
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> line 233, in exc
>     (args, rc, out, err))
> TapdiskException: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
> failed (512  )
>
> Any hints and help would very appreciated.
>
> Regards,
>
> Agya
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--089e01493ee412bb3c04d5fd5341
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello, Anyone have a clue? I have tried but still failed :(<br><br><div cla=
ss=3D"gmail_quote">On Sat, Feb 16, 2013 at 6:56 PM, agya naila <span dir=3D=
"ltr">&lt;<a href=3D"mailto:agya.naila@gmail.com" target=3D"_blank">agya.na=
ila@gmail.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">Dear all,<div><br></div><div>I am configure =
my machine to run the remus disk replication. I am using xen 4.2.3 installe=
d from sources and Ubuntu 12.04 64 bit both for Dom0 and DomU.=C2=A0</div>
<div><span style=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sa=
ns-serif">I have install the blktap and its work properly with configuratio=
n string phy or tap2 like this :</span><div style=3D"color:rgb(34,34,34);fo=
nt-size:13px">

<div><font face=3D"courier new, monospace">disk =3D [&#39;phy:/dev/vggroup/=
DomU,xvda,w&#39;]</font></div><div style=3D"font-family:arial,sans-serif">o=
r</div><div><font face=3D"courier new, monospace">disk =3D [&#39;tap2:tapdi=
sk:aio:/dev/vggroup/DomU,xvda,w&#39;]</font></div>

</div><div style=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sa=
ns-serif"><br></div><div style=3D"color:rgb(34,34,34);font-size:13px;font-f=
amily:arial,sans-serif">
and remus command=C2=A0</div><div style=3D"color:rgb(34,34,34);font-size:13=
px;font-family:arial,sans-serif"><br></div><div style=3D"color:rgb(34,34,34=
);font-size:13px">
<span style=3D"color:rgb(96,96,96);font-size:12px"><font face=3D"courier ne=
w, monospace">remus --no-net myvm mybackuphost</font></span></div><div styl=
e=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style=3D"color:rgb(96,96,96);font-family:monospace;font-size:12px"><b=
r></span></div><div style=3D"color:rgb(34,34,34);font-size:13px;font-family=
:arial,sans-serif"><span style=3D"color:rgb(96,96,96);font-family:monospace=
;font-size:12px"><br>

</span></div><div style=3D"color:rgb(34,34,34);font-size:13px;font-family:a=
rial,sans-serif">However when I change the string as suggested on remus pag=
es to enable the disk replication its still failed :</div>
<div style=3D"color:rgb(34,34,34);font-size:13px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:13px"><div><font =
face=3D"courier new, monospace">name =3D &quot;DomU&quot;</font></div>
<div><font face=3D"courier new, monospace">memory =3D 1024</font></div><div=
><font face=3D"courier new, monospace">disk =3D [&#39;tap2:remus:10.10.10.3=
:8002|aio:/dev/vggroup/DomU,xvda,w&#39;] =C2=A0</font></div><div><font face=
=3D"courier new, monospace">vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0=
&#39;]</font></div>

<div><font face=3D"courier new, monospace">bootloader =3D &quot;pygrub&quot=
;</font></div><div style=3D"font-family:arial,sans-serif"><br></div><font f=
ace=3D"arial, sans-serif">with error messages :</font></div><div style=3D"c=
olor:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">

<br></div><div style=3D"color:rgb(34,34,34);font-size:13px"><div><font face=
=3D"courier new, monospace">name1@machine1:~$ sudo xm create -c /etc/xen/Do=
mU.cfg</font></div><div><font face=3D"courier new, monospace">Using config =
file &quot;/etc/xen/DomU.cfg&quot;.</font></div>

<div><font face=3D"courier new, monospace">Error: (&#39;create&#39;, &#39;-=
aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) failed (512 =C2=A0)</fon=
t></div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D=
"font-family:arial,sans-serif">

and on the log file :</div><div style=3D"font-family:arial,sans-serif"><br>=
</div><div><div style=3D"font-family:arial,sans-serif"><br></div><div><font=
 face=3D"courier new, monospace">name1@machine1:~$ sudo sudo tail /var/log/=
xen/xend.log</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 mounted_vbd_uuid =
=3D dom0.create_vbd(vbd, disk);</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xe=
nd/XendDomainInfo.py&quot;, line 3987, in create_vbd</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 devid =3D dev_cont=
rol.createDevice(config)</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/serv=
er/BlktapController.py&quot;, line 174, in createDevice</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 device =3D Tapdisk=
Controller.create(params, file)</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 File &quot;/usr/local/lib/python2.7/dist-packages/xen/xe=
nd/server/BlktapController.py&quot;, line 286, in create</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 return TapdiskCont=
roller.exc(&#39;create&#39;, &#39;-a%s:%s&#39; % (dtype, image))</font></di=
v><div><font face=3D"courier new, monospace">=C2=A0 File &quot;/usr/local/l=
ib/python2.7/dist-packages/xen/xend/server/BlktapController.py&quot;, line =
233, in exc</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 (args, rc, out, er=
r))</font></div><div><font face=3D"courier new, monospace">TapdiskException=
: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39=
;) failed (512 =C2=A0)</font></div>

</div><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"f=
ont-family:arial,sans-serif">Any hints and help would very appreciated.</di=
v><div style=3D"font-family:arial,sans-serif"><br></div><div style=3D"font-=
family:arial,sans-serif">

Regards,</div><div style=3D"font-family:arial,sans-serif"><br></div><div st=
yle=3D"font-family:arial,sans-serif">Agya</div><div style=3D"font-family:ar=
ial,sans-serif;outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px"=
>

<br></div></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.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br>

--089e01493ee412bb3c04d5fd5341--


--===============7168085194524874421==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7168085194524874421==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 10:41:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O9t-0004uy-GK; Mon, 18 Feb 2013 10:41:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erwan@rigollot.me>) id 1U7O9r-0004uk-N8
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:41:16 +0000
Received: from [85.158.139.83:57627] by server-13.bemta-5.messagelabs.com id
	96/17-06769-A4502215; Mon, 18 Feb 2013 10:41:14 +0000
X-Env-Sender: erwan@rigollot.me
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361184072!27049826!1
X-Originating-IP: [212.27.42.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjI3LjQyLjEgPT4gMTg3MzIw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19265 invoked from network); 18 Feb 2013 10:41:13 -0000
Received: from smtp1-g21.free.fr (HELO smtp1-g21.free.fr) (212.27.42.1)
	by server-9.tower-182.messagelabs.com with SMTP;
	18 Feb 2013 10:41:13 -0000
Received: from [127.0.0.1] (unknown [82.231.4.123])
	by smtp1-g21.free.fr (Postfix) with ESMTP id 87AB89401F6;
	Mon, 18 Feb 2013 11:41:07 +0100 (CET)
Message-ID: <5122053F.9050400@rigollot.me>
Date: Mon, 18 Feb 2013 11:41:03 +0100
From: Erwan RIGOLLOT <erwan@rigollot.me>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
Content-Type: multipart/mixed; boundary="------------010606010000060309000109"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------010606010000060309000109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Le 18/02/2013 11:01, James Harper a écrit :
>> Hi,
>>
>> I have some difficulties with drivers GPLPV. When I try to install the GPLPV
>> on windows 7 and 2008 R2.
>> I have tried some version:
>> gplpv_Vista2008x64_signed_0.11.0.308.msi
>>
>> gplpv_Vista2008x64_signed_0.11.0.356.msi
>>
>> During installation, I obtained a BSOD about IRQ. I suppose that is block
>> device drivers cause troubles.
>>
>> On windows XP, I try :
>> gplpv_XP_signed_0.11.0.308.msi
>>
>> gplpv_XP_signed_0.11.0.356.msi
>> gplpv_XP_signed_0.11.0.356.msi
>>
>>
>> I obtained for Block device "this peripheral cannot start error 10".
>>
>> What is the best way to troubleshoot that ?
>>
>>
>> Did i forget something anything in file configuration of domu?
>>
>> builder='hvm'
>> memory = 2048
>> name = "Windows2008R2"
>> vif = [ 'type=ioemu, mac=00:16:3e:00:00:13, bridge=br0' ]
>> disk = [ 'file:/home/VM/Volumes/win2008R2.img,hda,w',
>> 'file:/home/Soft/ISO
>> Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hdc:
>> cdrom,r' ,'file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r' ]
>> boot="dc"
>> sdl=0
>> opengl=1
>> vnc=1
>> vnclisten="127.0.0.1"
>> vncpasswd='???????'
>> stdvga=0
>> serial='pty'
>> tsc_mode="default"
>> keymap='fr'
>>
>> Thanks for you help and sorry for my english.
>>
> That all looks okay. Can you try installing the debug version and then send me the output of /var/log/xen/qemu-dm-<domu-name>.log
>
> James
I try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64 bits.
Look attachement for logs.

Thanks
Erwan


--------------010606010000060309000109
Content-Type: text/plain; charset=windows-1252;
 name="qemu-dm-Windows7GPLPV.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows7GPLPV.log"

domid: 102
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /home/VM/Volumes/win7GPLPV.img (drv 'aio')
Using file /home/VM/Volumes/win7GPLPV.img in read-write mode
Strip off blktap sub-type prefix to /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso (drv 'aio')
Using file /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso in read-only mode
Strip off blktap sub-type prefix to /home/VM/Volumes/GPLPV.iso (drv 'aio')
Using file /home/VM/Volumes/GPLPV.iso in read-only mode
Watching /local/domain/0/device-model/102/logdirty/cmd
Watching /local/domain/0/device-model/102/command
Watching /local/domain/102/cpu
char device redirected to /dev/pts/6
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = f8f93756-91be-4adb-8ae4-620c482abf4b
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
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/102/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdd' (index: 2): aio:/home/VM/Volumes/GPLPV.iso
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/102/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/102/log-throttling'
medium change watch on `/local/domain/102/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.

--------------010606010000060309000109
Content-Type: text/plain; charset=windows-1252;
 name="qemu-dm-Windows7GPLPV.log.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows7GPLPV.log.1"

domid: 101
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /home/VM/Volumes/win7GPLPV.img (drv 'aio')
Using file /home/VM/Volumes/win7GPLPV.img in read-write mode
Strip off blktap sub-type prefix to /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso (drv 'aio')
Using file /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso in read-only mode
Strip off blktap sub-type prefix to /home/VM/Volumes/GPLPV.iso (drv 'aio')
Using file /home/VM/Volumes/GPLPV.iso in read-only mode
Watching /local/domain/0/device-model/101/logdirty/cmd
Watching /local/domain/0/device-model/101/command
Watching /local/domain/101/cpu
char device redirected to /dev/pts/7
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = b8a888ad-9a5e-44d2-86b9-170f46cebb44
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
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/101/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdd' (index: 2): aio:/home/VM/Volumes/GPLPV.iso
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/101/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/101/log-throttling'
medium change watch on `/local/domain/101/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.
13005657181814: XenPCI --> XenPci_InitialBalloonDown
13005657181814: XenPCI     base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000002
13005657181814: XenPCI     Hypercall area at FFFFFA80010E1000
13005657181814: XenPCI     XENMEM_maximum_reservation = 262400
13005657181814: XenPCI     XENMEM_current_reservation = 261113
13005657181814: XenPCI     Trying to give 5148 KB (5 MB) to Xen
13005657182032: XenPCI <-- XenPci_InitialBalloonDown
13005657182032: XenPCI     KeInitializeCrashDumpHeader status = c00000f2, size = 8192
13005657182032: XenPCI GPLPV 0.10.0.356
13005657182032: XenPCI --> XenPci_FixLoadOrder
13005657182032: XenPCI     dummy_group_index = -1
13005657182032: XenPCI     wdf_load_group_index = 2
13005657182032: XenPCI     xenpci_group_index = -1
13005657182032: XenPCI     boot_bus_extender_index = 3
13005657182032: XenPCI <-- XenPci_FixLoadOrder
13005657182032: XenPCI     SystemStartOptions =  NOEXECUTE=OPTIN
13005657182032: XenPCI <-- DriverEntry
13005657182032: XenPCI     Xen PCI device found - must be fdo
13005657182032: XenPCI --> XenPci_EvtDeviceAdd_XenPci
13005657182032: XenPCI <-- XenPci_EvtDeviceAdd_XenPci
13005657182048: XenPCI --> XenPci_EvtDevicePrepareHardware
13005657182048: XenPCI     IoPort Address(c000) Length: 256
13005657182048: XenPCI     Private Data: 0x01 0x00 0x00
13005657182048: XenPCI     Memory mapped CSR:(f2000000:0) Length:(16777216)
13005657182048: XenPCI     Memory flags = 0084
13005657182048: XenPCI     Private Data: 0x01 0x01 0x00
13005657182048: XenPCI     irq_number = 01c
13005657182048: XenPCI     irq_vector = 0b2
13005657182048: XenPCI     irq_level = 00b
13005657182048: XenPCI     irq_mode = LevelSensitive
13005657182048: XenPCI     ShareDisposition = CmResourceShareShared
13005657182048: XenPCI <-- XenPci_EvtDevicePrepareHardware
13005657182048: XenPCI --> XenPci_EvtDeviceD0Entry
13005657182048: XenPCI     WdfPowerDeviceD3Final
13005657182048: XenPCI --> XenPci_Init
13005657182048: XenPCI     base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000002
13005657182048: XenPCI     Hypercall area at FFFFFA80010CC000
13005657182048: XenPCI     shared_info_area_unmapped.QuadPart = f2000000
13005657182048: XenPCI     gpfn = f2000
13005657182048: XenPCI     hypervisor memory op (XENMAPSPACE_shared_info) ret = 0
13005657182048: XenPCI <-- XenPci_Init
13005657182048: XenPCI --> GntTbl_Init
13005657182048: XenPCI     grant_frames = 32
13005657182048: XenPCI     grant_entries = 16384
13005657182048: XenPCI     pfn = 3f0fb
13005657182048: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fb
13005657182064: XenPCI     decreased 1 pages for grant table frame 0
13005657182064: XenPCI     pfn = 3f0fc
13005657182064: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fc
13005657182079: XenPCI     decreased 1 pages for grant table frame 1
13005657182079: XenPCI     pfn = 3f0fd
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fd
13005657182079: XenPCI     decreased 1 pages for grant table frame 2
13005657182079: XenPCI     pfn = 3f0fe
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fe
13005657182079: XenPCI     decreased 1 pages for grant table frame 3
13005657182079: XenPCI     pfn = 3f0ff
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0ff
13005657182079: XenPCI     decreased 1 pages for grant table frame 4
13005657182079: XenPCI     pfn = 3f100
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f100
13005657182079: XenPCI     decreased 1 pages for grant table frame 5
13005657182079: XenPCI     pfn = 3f101
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f101
13005657182079: XenPCI     decreased 1 pages for grant table frame 6
13005657182079: XenPCI     pfn = 3f102
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f102
13005657182079: XenPCI     decreased 1 pages for grant table frame 7
13005657182079: XenPCI     pfn = 3f103
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f103
13005657182079: XenPCI     decreased 1 pages for grant table frame 8
13005657182079: XenPCI     pfn = 3f104
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f104
13005657182079: XenPCI     decreased 1 pages for grant table frame 9
13005657182079: XenPCI     pfn = 3f105
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f105
13005657182095: XenPCI     decreased 1 pages for grant table frame 10
13005657182095: XenPCI     pfn = 3f106
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f106
13005657182095: XenPCI     decreased 1 pages for grant table frame 11
13005657182095: XenPCI     pfn = 3f107
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f107
13005657182095: XenPCI     decreased 1 pages for grant table frame 12
13005657182095: XenPCI     pfn = 3f108
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f108
13005657182095: XenPCI     decreased 1 pages for grant table frame 13
13005657182095: XenPCI     pfn = 3f109
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f109
13005657182095: XenPCI     decreased 1 pages for grant table frame 14
13005657182095: XenPCI     pfn = 3f10a
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10a
13005657182095: XenPCI     decreased 1 pages for grant table frame 15
13005657182095: XenPCI     pfn = 3f10b
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10b
13005657182095: XenPCI     decreased 1 pages for grant table frame 16
13005657182095: XenPCI     pfn = 3f10c
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10c
13005657182095: XenPCI     decreased 1 pages for grant table frame 17
13005657182095: XenPCI     pfn = 3f10d
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10d
13005657182095: XenPCI     decreased 1 pages for grant table frame 18
13005657182095: XenPCI     pfn = 3f10e
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10e
13005657182095: XenPCI     decreased 1 pages for grant table frame 19
13005657182095: XenPCI     pfn = 3f10f
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10f
13005657182110: XenPCI     decreased 1 pages for grant table frame 20
13005657182110: XenPCI     pfn = 3f110
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f110
13005657182110: XenPCI     decreased 1 pages for grant table frame 21
13005657182110: XenPCI     pfn = 3f111
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f111
13005657182110: XenPCI     decreased 1 pages for grant table frame 22
13005657182110: XenPCI     pfn = 3f112
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f112
13005657182110: XenPCI     decreased 1 pages for grant table frame 23
13005657182110: XenPCI     pfn = 3f113
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f113
13005657182110: XenPCI     decreased 1 pages for grant table frame 24
13005657182110: XenPCI     pfn = 3f114
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f114
13005657182110: XenPCI     decreased 1 pages for grant table frame 25
13005657182110: XenPCI     pfn = 3f115
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f115
13005657182110: XenPCI     decreased 1 pages for grant table frame 26
13005657182110: XenPCI     pfn = 3f116
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f116
13005657182110: XenPCI     decreased 1 pages for grant table frame 27
13005657182110: XenPCI     pfn = 3f117
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f117
13005657182110: XenPCI     decreased 1 pages for grant table frame 28
13005657182110: XenPCI     pfn = 3f118
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f118
13005657182110: XenPCI     decreased 1 pages for grant table frame 29
13005657182110: XenPCI     pfn = 3f119
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f119
13005657182126: XenPCI     decreased 1 pages for grant table frame 30
13005657182126: XenPCI     pfn = 3f11a
13005657182126: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f11a
13005657182126: XenPCI     decreased 1 pages for grant table frame 31
13005657182126: XenPCI --> GntTbl_Map
13005657182126: XenPCI <-- GntTbl_Map
13005657182126: XenPCI <-- GntTbl_Init
13005657182126: XenPCI --> EvtChn_Init
13005657182126: XenPCI --> _hvm_set_parameter
13005657182126: XenPCI HYPERVISOR_hvm_op retval = 0
13005657182126: XenPCI <-- _hvm_set_parameter
13005657182126: XenPCI     hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0
13005657182126: XenPCI --> EvtChn_AllocIpi
13005657182126: XenPCI <-- EvtChn_AllocIpi
13005657182126: XenPCI --> EvtChn_BindDpc
13005657182126: XenPCI <-- EvtChn_BindDpc
13005657182126: XenPCI     pdo_event_channel = 5
13005657182126: XenPCI <-- EvtChn_Init
13005657182126: XenPCI <-- XenPci_EvtDeviceD0Entry
13005657182126: XenPCI --> EvtChn_EvtInterruptEnable
13005657182126: XenPCI <-- EvtChn_EvtInterruptEnable
13005657182126: XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled
13005657182126: XenPCI --> XenBus_Init
13005657182142: XenPCI --> _hvm_get_parameter
13005657182142: XenPCI HYPERVISOR_hvm_op retval = 0
13005657182142: XenPCI <-- _hvm_get_parameter
13005657182142: XenPCI --> _hvm_get_parameter
13005657182142: XenPCI HYPERVISOR_hvm_op retval = 0
13005657182142: XenPCI <-- _hvm_get_parameter
13005657182142: XenPCI --> EvtChn_BindDpc
13005657182142: XenPCI <-- EvtChn_BindDpc
13005657182142: XenPCI <-- XenBus_Init
13005657182142: XenPCI     suspend event channel = 6
13005657182142: XenPCI --> EvtChn_BindDpc
13005657182142: XenPCI <-- EvtChn_BindDpc
13005657182142: XenPCI --> XenPci_SysrqHandler
13005657182142: XenPCI     SysRq Value = (null)
13005657182142: XenPCI <-- XenPci_SysrqHandler
13005657182142: XenPCI --> XenPci_ShutdownHandler
13005657182142: XenPCI     Initial Memory Value = 1040384 (1040384)
13005657182142: XenPCI     Shutdown value = 
13005657182142: XenPCI <-- XenPci_ShutdownHandler
13005657182142: XenPCI --> XenPci_DeviceWatchHandler
13005657182142: XenPCI <-- XenPci_DeviceWatchHandler
13005657182142: XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled
13005657182142: XenPCI --> XenPci_EvtChildListScanForChildren
13005657182142: XenPCI --> XenPci_BalloonHandler
13005657182142: XenPCI     Found path = device/vbd/768
13005657182142: XenPCI     Found path = device/vbd/5632
13005657182142: XenPCI     Found path = device/vbd/5696
13005657182142: XenPCI     Found path = device/vif/0
13005657182142: XenPCI <-- XenPci_EvtChildListScanForChildren
13005657182142: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182142: XenPCI     device = 'vbd', index = '768', path = 'device/vbd/768'
13005657182142: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182142: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182142: XenPCI     device = 'vbd', index = '5632', path = 'device/vbd/5632'
13005657182142: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182157: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182157: XenPCI     device = 'vbd', index = '5696', path = 'device/vbd/5696'
13005657182157: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182157: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182157: XenPCI     device = 'vif', index = '0', path = 'device/vif/0'
13005657182157: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182157: XenPCI     target memory value = 1040384 (1040384)
13005657182157: XenPCI --> XenPci_BalloonThreadProc
13005657182157: XenPCI     low_mem_event = FFFFFA8000D00430, state = 0
13005657182204: XenPCI <-- XenPci_BalloonHandler
13005657182204: XenPCI     Got balloon event, current = 1040384, target = 1040384
13005657182204: XenPCI     No change to memory
13005657184201: XenVbd --> DriverEntry
13005657184201: XenVbd     IRQL = 0
13005657184201: XenVbd     DriverObject = FFFFFA80014EA490, RegistryPath = FFFFFA800146A000
13005657184201: XenVbd <-- DriverEntry
13005657184201: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
13005657184216: XenPCI     device/vbd/768
13005657184216: XenPCI     CmResourceTypeMemory (0)
13005657184216: XenPCI     Start = f2000000, Length = 0
13005657184216: XenPCI     pfn[0] = 0000cf91
13005657184216: XenPCI     New Start = 000000000cf91000, Length = 4096
13005657184216: XenPCI     CmResourceTypeMemory (1)
13005657184216: XenPCI     Start = f2000001, Length = 0
13005657184216: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
13005657184216: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
13005657184216: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
13005657184216: XenPCI --> XenPciPdo_EvtDeviceD0Entry
13005657184216: XenPCI     path = device/vbd/768
13005657184216: XenPCI     WdfPowerDeviceD3Final
13005657184216: XenPCI --> XenPci_GetBackendAndAddWatch
13005657184216: XenPCI <-- XenPci_GetBackendAndAddWatch
13005657184216: XenPCI --> XenConfig_InitConfigPage
13005657184216: XenPCI     fdo_driver_object = FFFFFA80014EA490
13005657184216: XenPCI     fdo_driver_extension = 0000000000000000
13005657184216: XenPCI     fdo_driver_object = FFFFFA80022A0B20
13005657184216: XenPCI     fdo_driver_extension = 0000000000000000
13005657184216: XenPCI <-- XenConfig_InitConfigPage
13005657184216: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
13005657184216: XenPCI --> XenPci_ChangeFrontendStateMap
13005657184216: XenPCI <-- XenPci_ChangeFrontendStateMap
13005657184216: XenPCI --> XenPci_ChangeFrontendStateMap
13005657184216: XenPCI <-- XenPci_ChangeFrontendStateMap
13005657184216: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
13005657184216: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
13005657184216: XenVbd --> XenVbd_VirtualHwStorFindAdapter
13005657184216: XenVbd     IRQL = 0
13005657184216: XenVbd     xvdd = FFFFFA800146E008
13005657184216: XenVbd     BusInterruptLevel = 28
13005657184216: XenVbd     BusInterruptVector = 01c
13005657184216: XenVbd     NumberOfAccessRanges = 1
13005657184216: XenVbd     RangeStart = 0cf91000, RangeLength = 00001000
13005657184232: XenVbd --> XenVbd_InitConfig
13005657184232: XenVbd     XEN_INIT_TYPE_13
13005657184232: XenVbd     XEN_INIT_TYPE_VECTORS
13005657184232: XenVbd     XEN_INIT_TYPE_11
13005657184232: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
13005657184232: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800147D000
13005657184232: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
13005657184232: XenPCI --> XenPci_UpdateBackendState
13005657184232: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7
13005657184232: XenPCI     Backend State Changed to Initialising
13005657184232: XenPCI <-- XenPci_UpdateBackendState
13005657184232: XenPCI --> XenPci_DeviceWatchHandler
13005657184232: XenPCI <-- XenPci_DeviceWatchHandler
13005657184232: XenPCI --> EvtChn_BindDpc
13005657184232: XenPCI <-- EvtChn_BindDpc
13005657184232: XenPCI --> XenPci_ChangeFrontendStateMap
13005657184232: XenPCI --> XenPci_ChangeFrontendState
13005657184232: XenPCI --> XenPci_DeviceWatchHandler
13005657184232: XenPCI <-- XenPci_DeviceWatchHandler
13005657184232: XenPCI --> XenPci_DeviceWatchHandler
13005657184232: XenPCI <-- XenPci_DeviceWatchHandler
13005657185246: XenPCI --> XenPci_UpdateBackendState
13005657185246: XenPCI     state unchanged
13005657185246: XenPCI     Still waiting for 4 (currently 1)...
13005657186260: XenPCI --> XenPci_UpdateBackendState
13005657186260: XenPCI     state unchanged
13005657186260: XenPCI     Timed out waiting for 4!
13005657186260: XenPCI <-- XenPci_ChangeFrontendStateMap
13005657186260: XenPCI     Error
13005657186260: XenPCI --> XenPci_ChangeFrontendState
13005657186260: XenPCI --> XenPci_DeviceWatchHandler
13005657186260: XenPCI <-- XenPci_DeviceWatchHandler
13005657187274: XenPCI --> XenPci_UpdateBackendState
13005657187274: XenPCI     state unchanged
13005657187274: XenPCI     Still waiting for 2 (currently 1)...
13005657188288: XenPCI --> XenPci_UpdateBackendState
13005657188288: XenPCI     state unchanged
13005657188288: XenPCI     Timed out waiting for 2!
13005657188288: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers, status = c0000001
13005657188288: Failed to complete device configuration (c0000001)
13005657188288: XenVbd <-- XenVbd_InitConfig
13005657188288: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
XenPCI     Bug check 0x000000D1 (0x0000000000000040, 0x0000000000000002, 0x0000000000000001, 0xFFFFF880031E03C0)
reset requested in cpu_handle_ioreq.
Issued domain 101 reboot

--------------010606010000060309000109
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010606010000060309000109--


From xen-devel-bounces@lists.xen.org Mon Feb 18 10:41:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7O9t-0004uy-GK; Mon, 18 Feb 2013 10:41:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erwan@rigollot.me>) id 1U7O9r-0004uk-N8
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:41:16 +0000
Received: from [85.158.139.83:57627] by server-13.bemta-5.messagelabs.com id
	96/17-06769-A4502215; Mon, 18 Feb 2013 10:41:14 +0000
X-Env-Sender: erwan@rigollot.me
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361184072!27049826!1
X-Originating-IP: [212.27.42.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjI3LjQyLjEgPT4gMTg3MzIw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19265 invoked from network); 18 Feb 2013 10:41:13 -0000
Received: from smtp1-g21.free.fr (HELO smtp1-g21.free.fr) (212.27.42.1)
	by server-9.tower-182.messagelabs.com with SMTP;
	18 Feb 2013 10:41:13 -0000
Received: from [127.0.0.1] (unknown [82.231.4.123])
	by smtp1-g21.free.fr (Postfix) with ESMTP id 87AB89401F6;
	Mon, 18 Feb 2013 11:41:07 +0100 (CET)
Message-ID: <5122053F.9050400@rigollot.me>
Date: Mon, 18 Feb 2013 11:41:03 +0100
From: Erwan RIGOLLOT <erwan@rigollot.me>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
Content-Type: multipart/mixed; boundary="------------010606010000060309000109"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------010606010000060309000109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Le 18/02/2013 11:01, James Harper a écrit :
>> Hi,
>>
>> I have some difficulties with drivers GPLPV. When I try to install the GPLPV
>> on windows 7 and 2008 R2.
>> I have tried some version:
>> gplpv_Vista2008x64_signed_0.11.0.308.msi
>>
>> gplpv_Vista2008x64_signed_0.11.0.356.msi
>>
>> During installation, I obtained a BSOD about IRQ. I suppose that is block
>> device drivers cause troubles.
>>
>> On windows XP, I try :
>> gplpv_XP_signed_0.11.0.308.msi
>>
>> gplpv_XP_signed_0.11.0.356.msi
>> gplpv_XP_signed_0.11.0.356.msi
>>
>>
>> I obtained for Block device "this peripheral cannot start error 10".
>>
>> What is the best way to troubleshoot that ?
>>
>>
>> Did i forget something anything in file configuration of domu?
>>
>> builder='hvm'
>> memory = 2048
>> name = "Windows2008R2"
>> vif = [ 'type=ioemu, mac=00:16:3e:00:00:13, bridge=br0' ]
>> disk = [ 'file:/home/VM/Volumes/win2008R2.img,hda,w',
>> 'file:/home/Soft/ISO
>> Microsoft/fr_windows_server_2008_r2_with_sp1_x64_dvd_617591.iso,hdc:
>> cdrom,r' ,'file:/home/VM/Volumes/GPLPV.iso,hdd:cdrom,r' ]
>> boot="dc"
>> sdl=0
>> opengl=1
>> vnc=1
>> vnclisten="127.0.0.1"
>> vncpasswd='???????'
>> stdvga=0
>> serial='pty'
>> tsc_mode="default"
>> keymap='fr'
>>
>> Thanks for you help and sorry for my english.
>>
> That all looks okay. Can you try installing the debug version and then send me the output of /var/log/xen/qemu-dm-<domu-name>.log
>
> James
I try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64 bits.
Look attachement for logs.

Thanks
Erwan


--------------010606010000060309000109
Content-Type: text/plain; charset=windows-1252;
 name="qemu-dm-Windows7GPLPV.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows7GPLPV.log"

domid: 102
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /home/VM/Volumes/win7GPLPV.img (drv 'aio')
Using file /home/VM/Volumes/win7GPLPV.img in read-write mode
Strip off blktap sub-type prefix to /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso (drv 'aio')
Using file /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso in read-only mode
Strip off blktap sub-type prefix to /home/VM/Volumes/GPLPV.iso (drv 'aio')
Using file /home/VM/Volumes/GPLPV.iso in read-only mode
Watching /local/domain/0/device-model/102/logdirty/cmd
Watching /local/domain/0/device-model/102/command
Watching /local/domain/102/cpu
char device redirected to /dev/pts/6
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = f8f93756-91be-4adb-8ae4-620c482abf4b
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
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/102/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdd' (index: 2): aio:/home/VM/Volumes/GPLPV.iso
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/102/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/102/log-throttling'
medium change watch on `/local/domain/102/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.

--------------010606010000060309000109
Content-Type: text/plain; charset=windows-1252;
 name="qemu-dm-Windows7GPLPV.log.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows7GPLPV.log.1"

domid: 101
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /home/VM/Volumes/win7GPLPV.img (drv 'aio')
Using file /home/VM/Volumes/win7GPLPV.img in read-write mode
Strip off blktap sub-type prefix to /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso (drv 'aio')
Using file /home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso in read-only mode
Strip off blktap sub-type prefix to /home/VM/Volumes/GPLPV.iso (drv 'aio')
Using file /home/VM/Volumes/GPLPV.iso in read-only mode
Watching /local/domain/0/device-model/101/logdirty/cmd
Watching /local/domain/0/device-model/101/command
Watching /local/domain/101/cpu
char device redirected to /dev/pts/7
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = b8a888ad-9a5e-44d2-86b9-170f46cebb44
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
xen be core: xen be core: can't open gnttab device
can't open gnttab device
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/101/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/Soft/ISO Microsoft/fr_windows_7_ultimate_with_sp1_x64_dvd_u_677299.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
medium change watch on `hdd' (index: 2): aio:/home/VM/Volumes/GPLPV.iso
Log-dirty: no command yet.
vcpu-set: watch node error.
xs_read(/local/domain/101/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/101/log-throttling'
medium change watch on `/local/domain/101/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.
13005657181814: XenPCI --> XenPci_InitialBalloonDown
13005657181814: XenPCI     base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000002
13005657181814: XenPCI     Hypercall area at FFFFFA80010E1000
13005657181814: XenPCI     XENMEM_maximum_reservation = 262400
13005657181814: XenPCI     XENMEM_current_reservation = 261113
13005657181814: XenPCI     Trying to give 5148 KB (5 MB) to Xen
13005657182032: XenPCI <-- XenPci_InitialBalloonDown
13005657182032: XenPCI     KeInitializeCrashDumpHeader status = c00000f2, size = 8192
13005657182032: XenPCI GPLPV 0.10.0.356
13005657182032: XenPCI --> XenPci_FixLoadOrder
13005657182032: XenPCI     dummy_group_index = -1
13005657182032: XenPCI     wdf_load_group_index = 2
13005657182032: XenPCI     xenpci_group_index = -1
13005657182032: XenPCI     boot_bus_extender_index = 3
13005657182032: XenPCI <-- XenPci_FixLoadOrder
13005657182032: XenPCI     SystemStartOptions =  NOEXECUTE=OPTIN
13005657182032: XenPCI <-- DriverEntry
13005657182032: XenPCI     Xen PCI device found - must be fdo
13005657182032: XenPCI --> XenPci_EvtDeviceAdd_XenPci
13005657182032: XenPCI <-- XenPci_EvtDeviceAdd_XenPci
13005657182048: XenPCI --> XenPci_EvtDevicePrepareHardware
13005657182048: XenPCI     IoPort Address(c000) Length: 256
13005657182048: XenPCI     Private Data: 0x01 0x00 0x00
13005657182048: XenPCI     Memory mapped CSR:(f2000000:0) Length:(16777216)
13005657182048: XenPCI     Memory flags = 0084
13005657182048: XenPCI     Private Data: 0x01 0x01 0x00
13005657182048: XenPCI     irq_number = 01c
13005657182048: XenPCI     irq_vector = 0b2
13005657182048: XenPCI     irq_level = 00b
13005657182048: XenPCI     irq_mode = LevelSensitive
13005657182048: XenPCI     ShareDisposition = CmResourceShareShared
13005657182048: XenPCI <-- XenPci_EvtDevicePrepareHardware
13005657182048: XenPCI --> XenPci_EvtDeviceD0Entry
13005657182048: XenPCI     WdfPowerDeviceD3Final
13005657182048: XenPCI --> XenPci_Init
13005657182048: XenPCI     base = 0x40000000, Xen Signature = XenVMMXenVMM, EAX = 0x40000002
13005657182048: XenPCI     Hypercall area at FFFFFA80010CC000
13005657182048: XenPCI     shared_info_area_unmapped.QuadPart = f2000000
13005657182048: XenPCI     gpfn = f2000
13005657182048: XenPCI     hypervisor memory op (XENMAPSPACE_shared_info) ret = 0
13005657182048: XenPCI <-- XenPci_Init
13005657182048: XenPCI --> GntTbl_Init
13005657182048: XenPCI     grant_frames = 32
13005657182048: XenPCI     grant_entries = 16384
13005657182048: XenPCI     pfn = 3f0fb
13005657182048: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fb
13005657182064: XenPCI     decreased 1 pages for grant table frame 0
13005657182064: XenPCI     pfn = 3f0fc
13005657182064: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fc
13005657182079: XenPCI     decreased 1 pages for grant table frame 1
13005657182079: XenPCI     pfn = 3f0fd
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fd
13005657182079: XenPCI     decreased 1 pages for grant table frame 2
13005657182079: XenPCI     pfn = 3f0fe
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0fe
13005657182079: XenPCI     decreased 1 pages for grant table frame 3
13005657182079: XenPCI     pfn = 3f0ff
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f0ff
13005657182079: XenPCI     decreased 1 pages for grant table frame 4
13005657182079: XenPCI     pfn = 3f100
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f100
13005657182079: XenPCI     decreased 1 pages for grant table frame 5
13005657182079: XenPCI     pfn = 3f101
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f101
13005657182079: XenPCI     decreased 1 pages for grant table frame 6
13005657182079: XenPCI     pfn = 3f102
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f102
13005657182079: XenPCI     decreased 1 pages for grant table frame 7
13005657182079: XenPCI     pfn = 3f103
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f103
13005657182079: XenPCI     decreased 1 pages for grant table frame 8
13005657182079: XenPCI     pfn = 3f104
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f104
13005657182079: XenPCI     decreased 1 pages for grant table frame 9
13005657182079: XenPCI     pfn = 3f105
13005657182079: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f105
13005657182095: XenPCI     decreased 1 pages for grant table frame 10
13005657182095: XenPCI     pfn = 3f106
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f106
13005657182095: XenPCI     decreased 1 pages for grant table frame 11
13005657182095: XenPCI     pfn = 3f107
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f107
13005657182095: XenPCI     decreased 1 pages for grant table frame 12
13005657182095: XenPCI     pfn = 3f108
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f108
13005657182095: XenPCI     decreased 1 pages for grant table frame 13
13005657182095: XenPCI     pfn = 3f109
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f109
13005657182095: XenPCI     decreased 1 pages for grant table frame 14
13005657182095: XenPCI     pfn = 3f10a
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10a
13005657182095: XenPCI     decreased 1 pages for grant table frame 15
13005657182095: XenPCI     pfn = 3f10b
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10b
13005657182095: XenPCI     decreased 1 pages for grant table frame 16
13005657182095: XenPCI     pfn = 3f10c
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10c
13005657182095: XenPCI     decreased 1 pages for grant table frame 17
13005657182095: XenPCI     pfn = 3f10d
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10d
13005657182095: XenPCI     decreased 1 pages for grant table frame 18
13005657182095: XenPCI     pfn = 3f10e
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10e
13005657182095: XenPCI     decreased 1 pages for grant table frame 19
13005657182095: XenPCI     pfn = 3f10f
13005657182095: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f10f
13005657182110: XenPCI     decreased 1 pages for grant table frame 20
13005657182110: XenPCI     pfn = 3f110
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f110
13005657182110: XenPCI     decreased 1 pages for grant table frame 21
13005657182110: XenPCI     pfn = 3f111
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f111
13005657182110: XenPCI     decreased 1 pages for grant table frame 22
13005657182110: XenPCI     pfn = 3f112
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f112
13005657182110: XenPCI     decreased 1 pages for grant table frame 23
13005657182110: XenPCI     pfn = 3f113
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f113
13005657182110: XenPCI     decreased 1 pages for grant table frame 24
13005657182110: XenPCI     pfn = 3f114
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f114
13005657182110: XenPCI     decreased 1 pages for grant table frame 25
13005657182110: XenPCI     pfn = 3f115
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f115
13005657182110: XenPCI     decreased 1 pages for grant table frame 26
13005657182110: XenPCI     pfn = 3f116
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f116
13005657182110: XenPCI     decreased 1 pages for grant table frame 27
13005657182110: XenPCI     pfn = 3f117
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f117
13005657182110: XenPCI     decreased 1 pages for grant table frame 28
13005657182110: XenPCI     pfn = 3f118
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f118
13005657182110: XenPCI     decreased 1 pages for grant table frame 29
13005657182110: XenPCI     pfn = 3f119
13005657182110: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f119
13005657182126: XenPCI     decreased 1 pages for grant table frame 30
13005657182126: XenPCI     pfn = 3f11a
13005657182126: XenPCI     Calling HYPERVISOR_memory_op - pfn = 3f11a
13005657182126: XenPCI     decreased 1 pages for grant table frame 31
13005657182126: XenPCI --> GntTbl_Map
13005657182126: XenPCI <-- GntTbl_Map
13005657182126: XenPCI <-- GntTbl_Init
13005657182126: XenPCI --> EvtChn_Init
13005657182126: XenPCI --> _hvm_set_parameter
13005657182126: XenPCI HYPERVISOR_hvm_op retval = 0
13005657182126: XenPCI <-- _hvm_set_parameter
13005657182126: XenPCI     hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, 28) = 0
13005657182126: XenPCI --> EvtChn_AllocIpi
13005657182126: XenPCI <-- EvtChn_AllocIpi
13005657182126: XenPCI --> EvtChn_BindDpc
13005657182126: XenPCI <-- EvtChn_BindDpc
13005657182126: XenPCI     pdo_event_channel = 5
13005657182126: XenPCI <-- EvtChn_Init
13005657182126: XenPCI <-- XenPci_EvtDeviceD0Entry
13005657182126: XenPCI --> EvtChn_EvtInterruptEnable
13005657182126: XenPCI <-- EvtChn_EvtInterruptEnable
13005657182126: XenPCI --> XenPci_EvtDeviceD0EntryPostInterruptsEnabled
13005657182126: XenPCI --> XenBus_Init
13005657182142: XenPCI --> _hvm_get_parameter
13005657182142: XenPCI HYPERVISOR_hvm_op retval = 0
13005657182142: XenPCI <-- _hvm_get_parameter
13005657182142: XenPCI --> _hvm_get_parameter
13005657182142: XenPCI HYPERVISOR_hvm_op retval = 0
13005657182142: XenPCI <-- _hvm_get_parameter
13005657182142: XenPCI --> EvtChn_BindDpc
13005657182142: XenPCI <-- EvtChn_BindDpc
13005657182142: XenPCI <-- XenBus_Init
13005657182142: XenPCI     suspend event channel = 6
13005657182142: XenPCI --> EvtChn_BindDpc
13005657182142: XenPCI <-- EvtChn_BindDpc
13005657182142: XenPCI --> XenPci_SysrqHandler
13005657182142: XenPCI     SysRq Value = (null)
13005657182142: XenPCI <-- XenPci_SysrqHandler
13005657182142: XenPCI --> XenPci_ShutdownHandler
13005657182142: XenPCI     Initial Memory Value = 1040384 (1040384)
13005657182142: XenPCI     Shutdown value = 
13005657182142: XenPCI <-- XenPci_ShutdownHandler
13005657182142: XenPCI --> XenPci_DeviceWatchHandler
13005657182142: XenPCI <-- XenPci_DeviceWatchHandler
13005657182142: XenPCI <-- XenPci_EvtDeviceD0EntryPostInterruptsEnabled
13005657182142: XenPCI --> XenPci_EvtChildListScanForChildren
13005657182142: XenPCI --> XenPci_BalloonHandler
13005657182142: XenPCI     Found path = device/vbd/768
13005657182142: XenPCI     Found path = device/vbd/5632
13005657182142: XenPCI     Found path = device/vbd/5696
13005657182142: XenPCI     Found path = device/vif/0
13005657182142: XenPCI <-- XenPci_EvtChildListScanForChildren
13005657182142: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182142: XenPCI     device = 'vbd', index = '768', path = 'device/vbd/768'
13005657182142: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182142: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182142: XenPCI     device = 'vbd', index = '5632', path = 'device/vbd/5632'
13005657182142: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182157: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182157: XenPCI     device = 'vbd', index = '5696', path = 'device/vbd/5696'
13005657182157: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182157: XenPCI --> XenPci_EvtChildListCreateDevice
13005657182157: XenPCI     device = 'vif', index = '0', path = 'device/vif/0'
13005657182157: XenPCI <-- XenPci_EvtChildListCreateDevice
13005657182157: XenPCI     target memory value = 1040384 (1040384)
13005657182157: XenPCI --> XenPci_BalloonThreadProc
13005657182157: XenPCI     low_mem_event = FFFFFA8000D00430, state = 0
13005657182204: XenPCI <-- XenPci_BalloonHandler
13005657182204: XenPCI     Got balloon event, current = 1040384, target = 1040384
13005657182204: XenPCI     No change to memory
13005657184201: XenVbd --> DriverEntry
13005657184201: XenVbd     IRQL = 0
13005657184201: XenVbd     DriverObject = FFFFFA80014EA490, RegistryPath = FFFFFA800146A000
13005657184201: XenVbd <-- DriverEntry
13005657184201: XenPCI --> XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
13005657184216: XenPCI     device/vbd/768
13005657184216: XenPCI     CmResourceTypeMemory (0)
13005657184216: XenPCI     Start = f2000000, Length = 0
13005657184216: XenPCI     pfn[0] = 0000cf91
13005657184216: XenPCI     New Start = 000000000cf91000, Length = 4096
13005657184216: XenPCI     CmResourceTypeMemory (1)
13005657184216: XenPCI     Start = f2000001, Length = 0
13005657184216: XenPCI <-- XenPciPdo_EvtDeviceWdmIrpPreprocess_START_DEVICE
13005657184216: XenPCI --> XenPciPdo_EvtDevicePrepareHardware
13005657184216: XenPCI <-- XenPciPdo_EvtDevicePrepareHardware
13005657184216: XenPCI --> XenPciPdo_EvtDeviceD0Entry
13005657184216: XenPCI     path = device/vbd/768
13005657184216: XenPCI     WdfPowerDeviceD3Final
13005657184216: XenPCI --> XenPci_GetBackendAndAddWatch
13005657184216: XenPCI <-- XenPci_GetBackendAndAddWatch
13005657184216: XenPCI --> XenConfig_InitConfigPage
13005657184216: XenPCI     fdo_driver_object = FFFFFA80014EA490
13005657184216: XenPCI     fdo_driver_extension = 0000000000000000
13005657184216: XenPCI     fdo_driver_object = FFFFFA80022A0B20
13005657184216: XenPCI     fdo_driver_extension = 0000000000000000
13005657184216: XenPCI <-- XenConfig_InitConfigPage
13005657184216: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
13005657184216: XenPCI --> XenPci_ChangeFrontendStateMap
13005657184216: XenPCI <-- XenPci_ChangeFrontendStateMap
13005657184216: XenPCI --> XenPci_ChangeFrontendStateMap
13005657184216: XenPCI <-- XenPci_ChangeFrontendStateMap
13005657184216: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers
13005657184216: XenPCI <-- XenPciPdo_EvtDeviceD0Entry
13005657184216: XenVbd --> XenVbd_VirtualHwStorFindAdapter
13005657184216: XenVbd     IRQL = 0
13005657184216: XenVbd     xvdd = FFFFFA800146E008
13005657184216: XenVbd     BusInterruptLevel = 28
13005657184216: XenVbd     BusInterruptVector = 01c
13005657184216: XenVbd     NumberOfAccessRanges = 1
13005657184216: XenVbd     RangeStart = 0cf91000, RangeLength = 00001000
13005657184232: XenVbd --> XenVbd_InitConfig
13005657184232: XenVbd     XEN_INIT_TYPE_13
13005657184232: XenVbd     XEN_INIT_TYPE_VECTORS
13005657184232: XenVbd     XEN_INIT_TYPE_11
13005657184232: XenPCI --> XenPci_XenConfigDeviceSpecifyBuffers
13005657184232: XenPCI     XEN_INIT_TYPE_RING - ring-ref = FFFFFA800147D000
13005657184232: XenPCI     XEN_INIT_TYPE_RING - ring-ref = 16383
13005657184232: XenPCI --> XenPci_UpdateBackendState
13005657184232: XenPCI     XEN_INIT_TYPE_EVENT_CHANNEL - event-channel = 7
13005657184232: XenPCI     Backend State Changed to Initialising
13005657184232: XenPCI <-- XenPci_UpdateBackendState
13005657184232: XenPCI --> XenPci_DeviceWatchHandler
13005657184232: XenPCI <-- XenPci_DeviceWatchHandler
13005657184232: XenPCI --> EvtChn_BindDpc
13005657184232: XenPCI <-- EvtChn_BindDpc
13005657184232: XenPCI --> XenPci_ChangeFrontendStateMap
13005657184232: XenPCI --> XenPci_ChangeFrontendState
13005657184232: XenPCI --> XenPci_DeviceWatchHandler
13005657184232: XenPCI <-- XenPci_DeviceWatchHandler
13005657184232: XenPCI --> XenPci_DeviceWatchHandler
13005657184232: XenPCI <-- XenPci_DeviceWatchHandler
13005657185246: XenPCI --> XenPci_UpdateBackendState
13005657185246: XenPCI     state unchanged
13005657185246: XenPCI     Still waiting for 4 (currently 1)...
13005657186260: XenPCI --> XenPci_UpdateBackendState
13005657186260: XenPCI     state unchanged
13005657186260: XenPCI     Timed out waiting for 4!
13005657186260: XenPCI <-- XenPci_ChangeFrontendStateMap
13005657186260: XenPCI     Error
13005657186260: XenPCI --> XenPci_ChangeFrontendState
13005657186260: XenPCI --> XenPci_DeviceWatchHandler
13005657186260: XenPCI <-- XenPci_DeviceWatchHandler
13005657187274: XenPCI --> XenPci_UpdateBackendState
13005657187274: XenPCI     state unchanged
13005657187274: XenPCI     Still waiting for 2 (currently 1)...
13005657188288: XenPCI --> XenPci_UpdateBackendState
13005657188288: XenPCI     state unchanged
13005657188288: XenPCI     Timed out waiting for 2!
13005657188288: XenPCI <-- XenPci_XenConfigDeviceSpecifyBuffers, status = c0000001
13005657188288: Failed to complete device configuration (c0000001)
13005657188288: XenVbd <-- XenVbd_InitConfig
13005657188288: XenVbd <-- XenVbd_VirtualHwStorFindAdapter
XenPCI     Bug check 0x000000D1 (0x0000000000000040, 0x0000000000000002, 0x0000000000000001, 0xFFFFF880031E03C0)
reset requested in cpu_handle_ioreq.
Issued domain 101 reboot

--------------010606010000060309000109
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010606010000060309000109--


From xen-devel-bounces@lists.xen.org Mon Feb 18 10:47:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7OFt-0005Pm-7I; Mon, 18 Feb 2013 10:47:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7OFr-0005PV-CG
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:47:27 +0000
Received: from [193.109.254.147:14871] by server-14.bemta-14.messagelabs.com
	id 8A/F3-02031-EB602215; Mon, 18 Feb 2013 10:47:26 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361184443!8801383!1
X-Originating-IP: [209.85.214.53]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15574 invoked from network); 18 Feb 2013 10:47:24 -0000
Received: from mail-bk0-f53.google.com (HELO mail-bk0-f53.google.com)
	(209.85.214.53)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:47:24 -0000
Received: by mail-bk0-f53.google.com with SMTP id j10so2438989bkw.26
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 02:47:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=VKfZH1VsRuHy0Xl1Ol2KyzZXzpn6fxUnFbDUntbmmOM=;
	b=LX1t6SmTKkziqJX7t73mgHAk11dAsm25iH2tiZRm8v4flqhKV9+i+roIz2mbnhXNq2
	yBdKoBQwQuakGDa0zCmKsxffNTpyaEFrHOftSmzTLACaccH1JYAkrqgH6xak6r+flGQ+
	JbVA37KxU1HYNpuqOMdoBBzqstT4At5hUjpx35dVlTmONSqMIt3tWSidX6ZV/+1UtdUX
	6UcYjUcwfSYl0R+EZ8YrYvJ6ae6SS9NEZ6kiASo1OWu3qS8KQS6PPqAU2u8VwPiySv/a
	3PGLtE7Mq7Ee3rakDsNgTDx1qvKnzlAE+XbpBGzodkxHyO7vmu4uSEbZtaB3U5WsCd1V
	EuRw==
MIME-Version: 1.0
X-Received: by 10.204.154.5 with SMTP id m5mr4399640bkw.30.1361184442889; Mon,
	18 Feb 2013 02:47:22 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 02:47:22 -0800 (PST)
Date: Mon, 18 Feb 2013 11:47:22 +0100
Message-ID: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQm4KtoALMJhNi8++jsKN11dU4ZoNDI/LwP7xrezeQeUPMB32p0QEfVK0MEdB3K9p4duSDnZ
Subject: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking order
 violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've just installed a self-built Xen 4.2.1 package on a debian wheezy
and when trying to run a HVM VM (that I was previously running with
the official xen 4.0 package on squeeze), it starts fine and I can
even use the VM for a few minutes then suddenly I loose all
communication with VM and the Dom0 and it just reboots ...

I enabled the xen serial console and this is what I got when the crash happens:


(XEN) mm locking order violation: 260 > 222
(XEN) Xen BUG at mm-locks.h:118
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
(XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
(XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
(XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
(XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
(XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
(XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
(XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff82c48029f978:
(XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
(XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
(XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
(XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
(XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
(XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
(XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
(XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
(XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
(XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
(XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
(XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
(XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
(XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
(XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
(XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
(XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
(XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
(XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
(XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
(XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
(XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
(XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
(XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
(XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
(XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
(XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
(XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
(XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
(XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
(XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
(XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
(XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
(XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
(XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
(XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
(XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
(XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
(XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
(XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at mm-locks.h:118
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


Any suggestions ?

It is very reproducible and it's on a test machine I can reboot any
time, so if you need more debug info, I can collect it.
I don't have any different hw to test on unfortunately.


Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:47:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7OFt-0005Pm-7I; Mon, 18 Feb 2013 10:47:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7OFr-0005PV-CG
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:47:27 +0000
Received: from [193.109.254.147:14871] by server-14.bemta-14.messagelabs.com
	id 8A/F3-02031-EB602215; Mon, 18 Feb 2013 10:47:26 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361184443!8801383!1
X-Originating-IP: [209.85.214.53]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15574 invoked from network); 18 Feb 2013 10:47:24 -0000
Received: from mail-bk0-f53.google.com (HELO mail-bk0-f53.google.com)
	(209.85.214.53)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:47:24 -0000
Received: by mail-bk0-f53.google.com with SMTP id j10so2438989bkw.26
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 02:47:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=VKfZH1VsRuHy0Xl1Ol2KyzZXzpn6fxUnFbDUntbmmOM=;
	b=LX1t6SmTKkziqJX7t73mgHAk11dAsm25iH2tiZRm8v4flqhKV9+i+roIz2mbnhXNq2
	yBdKoBQwQuakGDa0zCmKsxffNTpyaEFrHOftSmzTLACaccH1JYAkrqgH6xak6r+flGQ+
	JbVA37KxU1HYNpuqOMdoBBzqstT4At5hUjpx35dVlTmONSqMIt3tWSidX6ZV/+1UtdUX
	6UcYjUcwfSYl0R+EZ8YrYvJ6ae6SS9NEZ6kiASo1OWu3qS8KQS6PPqAU2u8VwPiySv/a
	3PGLtE7Mq7Ee3rakDsNgTDx1qvKnzlAE+XbpBGzodkxHyO7vmu4uSEbZtaB3U5WsCd1V
	EuRw==
MIME-Version: 1.0
X-Received: by 10.204.154.5 with SMTP id m5mr4399640bkw.30.1361184442889; Mon,
	18 Feb 2013 02:47:22 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 02:47:22 -0800 (PST)
Date: Mon, 18 Feb 2013 11:47:22 +0100
Message-ID: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQm4KtoALMJhNi8++jsKN11dU4ZoNDI/LwP7xrezeQeUPMB32p0QEfVK0MEdB3K9p4duSDnZ
Subject: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking order
 violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've just installed a self-built Xen 4.2.1 package on a debian wheezy
and when trying to run a HVM VM (that I was previously running with
the official xen 4.0 package on squeeze), it starts fine and I can
even use the VM for a few minutes then suddenly I loose all
communication with VM and the Dom0 and it just reboots ...

I enabled the xen serial console and this is what I got when the crash happens:


(XEN) mm locking order violation: 260 > 222
(XEN) Xen BUG at mm-locks.h:118
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
(XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
(XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
(XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
(XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
(XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
(XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
(XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff82c48029f978:
(XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
(XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
(XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
(XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
(XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
(XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
(XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
(XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
(XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
(XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
(XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
(XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
(XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
(XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
(XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
(XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
(XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
(XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
(XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
(XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
(XEN) Xen call trace:
(XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
(XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
(XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
(XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
(XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
(XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
(XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
(XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
(XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
(XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
(XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
(XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
(XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
(XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
(XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
(XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
(XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
(XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
(XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
(XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
(XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at mm-locks.h:118
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


Any suggestions ?

It is very reproducible and it's on a test machine I can reboot any
time, so if you need more debug info, I can collect it.
I don't have any different hw to test on unfortunately.


Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:51:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7OJa-0005jT-1P; Mon, 18 Feb 2013 10:51:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U7OJX-0005jI-Tt
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:51:16 +0000
Received: from [85.158.137.99:35792] by server-14.bemta-3.messagelabs.com id
	E7/83-23533-3A702215; Mon, 18 Feb 2013 10:51:15 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361184674!21864040!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27655 invoked from network); 18 Feb 2013 10:51:14 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:51:14 -0000
Received: by mail-ea0-f173.google.com with SMTP id i1so2246700eaa.4
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 02:51:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=H/QU23Ku3sYh2JMyg09su7fkpWtQeel7Tknj+bNgZQM=;
	b=mn2Gns5JCdI0+PiBicg5ByfxI2dalb85HpDmvKVrZdj0vAFa05xCNWanHnYe1Bx/I+
	xjCOhxyllg88fn5egRMVYBuQ/jA98CRIfgvOxC309o4sgAVpkCxB2ponZrQK0gxSA+gK
	f/RMRXfsUXLDni/MwHVPSgcRxsgOPgG0mVDnTgJQbpB9tn8NgX36SuKu9cov0k1Ws4uU
	CC9Flp3OVfJvRMk2yWZyKHhmC8cgnkA+64tdN4PrwMcmDV7UOA3AAkV+KobFfy3IWUBZ
	z2R67wTNHCs1MCGcXF6Yw7u5gPMQ8gwJGvInVTwHc0HJB1fR9u+k4BVwwKn34q+K1rMW
	/O3A==
X-Received: by 10.14.209.131 with SMTP id s3mr43232489eeo.26.1361184673745;
	Mon, 18 Feb 2013 02:51:13 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id r4sm53325531eeo.12.2013.02.18.02.51.11
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 02:51:12 -0800 (PST)
Message-ID: <5122079E.1090600@heliman.it>
Date: Mon, 18 Feb 2013 11:51:10 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
	<511EAEA9.5040109@heliman.it>
	<1361182012.31407.122.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361182012.31407.122.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQlkASmPeJpgM5ZZTufnwtG1oPc+FSnzuio/l78pf5zf6X5u58FHmXYBcrGy9VtKL9YNHVTq
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>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Il 18/02/2013 11:06, Ian Campbell ha scritto:
> On Fri, 2013-02-15 at 21:54 +0000, Fabio Fantoni wrote:
>> Il 15/02/2013 16:48, Ian Jackson ha scritto:
>>> fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
>>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>>
>>>> Usage:
>>>>     vga="stdvga"|"cirrus"
>>>>
>>>> - Default option is cirrus.
>>>> - Prints error and exit if unknown value is passed.
>>>> - stdvga parameter is now deprecated.
>>>> - Updated xl.cfg man.
>>>>
>>>> Required patch: Improve videoram setting v5
>>>> Is prerequisite for patch: Add qxl support v9
>>> The code looks good to me, but there are a couple of formatting
>>> problems.  Your wrapping of the longer lines is odd (particularly, you
>>> fail to indent the continuations), and there's a spurious space after
>>> xlu_cfg_get_string.  Can you please repost following the style used
>>> elsewhere ?
>>>
>>> Thanks,
>>> Ian.
>> Sorry.
>> Can you explain me the error of indentation did I do please?
> The spurious space after xlu_cfg_get_string, e.g.
> 		xlu_cfg_get_string (config,
> should have been
> 		xlu_cfg_get_string(config,
>
> However, I count 44 instances with the space and 3 without in this file,
> so I think you can be forgiven. This extra space has been there from day
> one...
>
> The more important one IMHO is:
>
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_STD;
>
> I noticed this when I reviewed but when I looked at the file I concluded
> you were just copying a prevailing style so I let it slide. Looking
> again I think I was looking at the file with this patch applied, which
> makes that logic rather circular ;-)
>
> It seems like you were trying to avoid going over the 80 column limit,
> although in this case it doesn't seem like the line would actually be
> that long. If wrapping is required then it would be more normal to
> indent as:
>
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                    = LIBXL_VGA_INTERFACE_TYPE_STD;
>
> (i.e indent the wrapped line by one level). However given that all these
> things fit on one line using at most 72 columns:
>
> 8<------
> xl: fix line wrapping oddness
>
> These lines are strangely wrapped and in any case fit within 80 columns
> when unwrapped.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 003b129..a80cda6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1476,14 +1476,11 @@ skip_vfb:
>       if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
>               if (!strcmp(buf, "stdvga")) {
> -                b_info->u.hvm.vga.kind
> -                = LIBXL_VGA_INTERFACE_TYPE_STD;
> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
>               } else if (!strcmp(buf, "cirrus")) {
> -                b_info->u.hvm.vga.kind
> -                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>               } else {
> -                fprintf(stderr,
> -                "Unknown vga \"%s\" specified\n", buf);
> +                fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
>                   exit(1);
>               }
>           } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>
>
>
>
Sorry for my coding style errors, I saw this mail only after posting v10 
of qxl patch, I'll do v11 after posting your coding style fix.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:51:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7OJa-0005jT-1P; Mon, 18 Feb 2013 10:51:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1U7OJX-0005jI-Tt
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:51:16 +0000
Received: from [85.158.137.99:35792] by server-14.bemta-3.messagelabs.com id
	E7/83-23533-3A702215; Mon, 18 Feb 2013 10:51:15 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361184674!21864040!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27655 invoked from network); 18 Feb 2013 10:51:14 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:51:14 -0000
Received: by mail-ea0-f173.google.com with SMTP id i1so2246700eaa.4
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 02:51:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=H/QU23Ku3sYh2JMyg09su7fkpWtQeel7Tknj+bNgZQM=;
	b=mn2Gns5JCdI0+PiBicg5ByfxI2dalb85HpDmvKVrZdj0vAFa05xCNWanHnYe1Bx/I+
	xjCOhxyllg88fn5egRMVYBuQ/jA98CRIfgvOxC309o4sgAVpkCxB2ponZrQK0gxSA+gK
	f/RMRXfsUXLDni/MwHVPSgcRxsgOPgG0mVDnTgJQbpB9tn8NgX36SuKu9cov0k1Ws4uU
	CC9Flp3OVfJvRMk2yWZyKHhmC8cgnkA+64tdN4PrwMcmDV7UOA3AAkV+KobFfy3IWUBZ
	z2R67wTNHCs1MCGcXF6Yw7u5gPMQ8gwJGvInVTwHc0HJB1fR9u+k4BVwwKn34q+K1rMW
	/O3A==
X-Received: by 10.14.209.131 with SMTP id s3mr43232489eeo.26.1361184673745;
	Mon, 18 Feb 2013 02:51:13 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id r4sm53325531eeo.12.2013.02.18.02.51.11
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 02:51:12 -0800 (PST)
Message-ID: <5122079E.1090600@heliman.it>
Date: Mon, 18 Feb 2013 11:51:10 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1360580242-4972-1-git-send-email-fantonifabio@tiscali.it>
	<20766.22732.806518.892544@mariner.uk.xensource.com>
	<511EAEA9.5040109@heliman.it>
	<1361182012.31407.122.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361182012.31407.122.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQlkASmPeJpgM5ZZTufnwtG1oPc+FSnzuio/l78pf5zf6X5u58FHmXYBcrGy9VtKL9YNHVTq
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>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm
 domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Il 18/02/2013 11:06, Ian Campbell ha scritto:
> On Fri, 2013-02-15 at 21:54 +0000, Fabio Fantoni wrote:
>> Il 15/02/2013 16:48, Ian Jackson ha scritto:
>>> fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH] tools/libxl: Added vga parameter for hvm domUs"):
>>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>>
>>>> Usage:
>>>>     vga="stdvga"|"cirrus"
>>>>
>>>> - Default option is cirrus.
>>>> - Prints error and exit if unknown value is passed.
>>>> - stdvga parameter is now deprecated.
>>>> - Updated xl.cfg man.
>>>>
>>>> Required patch: Improve videoram setting v5
>>>> Is prerequisite for patch: Add qxl support v9
>>> The code looks good to me, but there are a couple of formatting
>>> problems.  Your wrapping of the longer lines is odd (particularly, you
>>> fail to indent the continuations), and there's a spurious space after
>>> xlu_cfg_get_string.  Can you please repost following the style used
>>> elsewhere ?
>>>
>>> Thanks,
>>> Ian.
>> Sorry.
>> Can you explain me the error of indentation did I do please?
> The spurious space after xlu_cfg_get_string, e.g.
> 		xlu_cfg_get_string (config,
> should have been
> 		xlu_cfg_get_string(config,
>
> However, I count 44 instances with the space and 3 without in this file,
> so I think you can be forgiven. This extra space has been there from day
> one...
>
> The more important one IMHO is:
>
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_STD;
>
> I noticed this when I reviewed but when I looked at the file I concluded
> you were just copying a prevailing style so I let it slide. Looking
> again I think I was looking at the file with this patch applied, which
> makes that logic rather circular ;-)
>
> It seems like you were trying to avoid going over the 80 column limit,
> although in this case it doesn't seem like the line would actually be
> that long. If wrapping is required then it would be more normal to
> indent as:
>
> +            if (!strcmp(buf, "stdvga")) {
> +                b_info->u.hvm.vga.kind
> +                    = LIBXL_VGA_INTERFACE_TYPE_STD;
>
> (i.e indent the wrapped line by one level). However given that all these
> things fit on one line using at most 72 columns:
>
> 8<------
> xl: fix line wrapping oddness
>
> These lines are strangely wrapped and in any case fit within 80 columns
> when unwrapped.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 003b129..a80cda6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1476,14 +1476,11 @@ skip_vfb:
>       if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>           if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
>               if (!strcmp(buf, "stdvga")) {
> -                b_info->u.hvm.vga.kind
> -                = LIBXL_VGA_INTERFACE_TYPE_STD;
> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
>               } else if (!strcmp(buf, "cirrus")) {
> -                b_info->u.hvm.vga.kind
> -                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> +                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
>               } else {
> -                fprintf(stderr,
> -                "Unknown vga \"%s\" specified\n", buf);
> +                fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
>                   exit(1);
>               }
>           } else if (!xlu_cfg_get_long(config, "stdvga", &l, 0))
>
>
>
>
Sorry for my coding style errors, I saw this mail only after posting v10 
of qxl patch, I'll do v11 after posting your coding style fix.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:53:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:53: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 1U7OL5-0005sR-Ie; Mon, 18 Feb 2013 10:52: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 1U7OL4-0005sE-7C
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:52:50 +0000
Received: from [85.158.139.211:55582] by server-1.bemta-5.messagelabs.com id
	F2/83-29263-10802215; Mon, 18 Feb 2013 10:52:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361184765!17986746!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27679 invoked from network); 18 Feb 2013 10:52:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:52:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1564740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:52: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.297.1;
	Mon, 18 Feb 2013 10:52:40 +0000
Message-ID: <1361184758.31407.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Mon, 18 Feb 2013 10:52:38 +0000
In-Reply-To: <16282745.20130218112144@eikelenboom.it>
References: <16282745.20130218112144@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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 Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
> Hi All,
> 
> Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
> Previous pull was working fine and was about 3 or 4 days ago.

Do you happen to know the exact revisions?

Please can you try running xl under gdb and get a backtrace.

> Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
> Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
> Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
> Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]
> 
> --
> 
> Sander
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 10:53:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:53: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 1U7OL5-0005sR-Ie; Mon, 18 Feb 2013 10:52: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 1U7OL4-0005sE-7C
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:52:50 +0000
Received: from [85.158.139.211:55582] by server-1.bemta-5.messagelabs.com id
	F2/83-29263-10802215; Mon, 18 Feb 2013 10:52:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361184765!17986746!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27679 invoked from network); 18 Feb 2013 10:52:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:52:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1564740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:52: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.297.1;
	Mon, 18 Feb 2013 10:52:40 +0000
Message-ID: <1361184758.31407.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Mon, 18 Feb 2013 10:52:38 +0000
In-Reply-To: <16282745.20130218112144@eikelenboom.it>
References: <16282745.20130218112144@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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 Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
> Hi All,
> 
> Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
> Previous pull was working fine and was about 3 or 4 days ago.

Do you happen to know the exact revisions?

Please can you try running xl under gdb and get a backtrace.

> Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
> Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
> Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
> Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
> Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]
> 
> --
> 
> Sander
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 10:57:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:57: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 1U7OPB-0006II-Vs; Mon, 18 Feb 2013 10:57:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U7OPA-0006IC-QI
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:57:04 +0000
Received: from [193.109.254.147:9997] by server-11.bemta-14.messagelabs.com id
	D6/B6-30685-00902215; Mon, 18 Feb 2013 10:57:04 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361184989!3117239!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2015 invoked from network); 18 Feb 2013 10:56:33 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 10:56:33 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7OOa-0007be-BL; Mon, 18 Feb 2013 21:56:28 +1100
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 id
	14.01.0438.000; Mon, 18 Feb 2013 21:56:28 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Erwan RIGOLLOT <erwan@rigollot.me>
Thread-Topic: [Xen-devel] GPLPV
Thread-Index: AQHODblRtbwo4yxEekWAGSmkTVhptZh/Yaeg//9TZICAALx3wA==
Date: Mon, 18 Feb 2013 10:56:26 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
	<5122053F.9050400@rigollot.me>
In-Reply-To: <5122053F.9050400@rigollot.me>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19644.006
x-tm-as-result: No--26.196800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64
> bits.
> Look attachement for logs.
> 

I think the problem might be related to this:

xen be core: xen be core: can't open gnttab device

but I don't know how to fix it. Maybe start a new thread with that as the subject?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:57:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10:57: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 1U7OPB-0006II-Vs; Mon, 18 Feb 2013 10:57:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1U7OPA-0006IC-QI
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 10:57:04 +0000
Received: from [193.109.254.147:9997] by server-11.bemta-14.messagelabs.com id
	D6/B6-30685-00902215; Mon, 18 Feb 2013 10:57:04 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361184989!3117239!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2015 invoked from network); 18 Feb 2013 10:56:33 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 10:56:33 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7OOa-0007be-BL; Mon, 18 Feb 2013 21:56:28 +1100
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 id
	14.01.0438.000; Mon, 18 Feb 2013 21:56:28 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Erwan RIGOLLOT <erwan@rigollot.me>
Thread-Topic: [Xen-devel] GPLPV
Thread-Index: AQHODblRtbwo4yxEekWAGSmkTVhptZh/Yaeg//9TZICAALx3wA==
Date: Mon, 18 Feb 2013 10:56:26 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
	<5122053F.9050400@rigollot.me>
In-Reply-To: <5122053F.9050400@rigollot.me>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19644.006
x-tm-as-result: No--26.196800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64
> bits.
> Look attachement for logs.
> 

I think the problem might be related to this:

xen be core: xen be core: can't open gnttab device

but I don't know how to fix it. Maybe start a new thread with that as the subject?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:59:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7ORG-0006Ua-HV; Mon, 18 Feb 2013 10: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 1U7ORF-0006UB-AB
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:59:13 +0000
Received: from [85.158.143.35:48604] by server-3.bemta-4.messagelabs.com id
	5F/D9-08920-08902215; Mon, 18 Feb 2013 10:59:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1361183989!4697440!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3344 invoked from network); 18 Feb 2013 10:39:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:39:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1564064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:39: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.297.1;
	Mon, 18 Feb 2013 10:39:48 +0000
Message-ID: <1361183987.31407.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joe Jin <joe.jin@oracle.com>
Date: Mon, 18 Feb 2013 10:39:47 +0000
In-Reply-To: <51206584.8060200@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
	<512056D5.6080507@oracle.com> <51206584.8060200@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 Sun, 2013-02-17 at 05:07 +0000, Joe Jin wrote:
> Execute "xl-destroy" twice lead the dom0 panic:
> config file as below:

Thanks.

> kernel BUG at drivers/pci/access.c:423!
[...]
> BTW: xm-create work fine but xl-create trigger the panic as below:

Both the panic above and the warn+panic below seem like kernel bugs
which are simply exposed by xl rather than xl bugs as such. Presumably
xl just tickles things different to xm.

The dom0 kernel you are using is a bit dated and appears (from the
revision) to be rather heavily patched.

> > WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x22d/0x240()
> > Hardware name: SUN FIRE X4370 M2 SERVER
> > remove_proc_entry: removing non-empty directory 'irq/536', leaking at least 'eth7'
[..]
> > BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> > IP: [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40

Wei recently posted a bug fix for an issue which looked a bit like this
last one. That was something do with error handling on allocation
failure though so I doubt it represents the actual root cause though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 10:59:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 10: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 1U7ORG-0006Ua-HV; Mon, 18 Feb 2013 10: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 1U7ORF-0006UB-AB
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 10:59:13 +0000
Received: from [85.158.143.35:48604] by server-3.bemta-4.messagelabs.com id
	5F/D9-08920-08902215; Mon, 18 Feb 2013 10:59:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1361183989!4697440!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3344 invoked from network); 18 Feb 2013 10:39:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 10:39:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1564064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 10:39: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.297.1;
	Mon, 18 Feb 2013 10:39:48 +0000
Message-ID: <1361183987.31407.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joe Jin <joe.jin@oracle.com>
Date: Mon, 18 Feb 2013 10:39:47 +0000
In-Reply-To: <51206584.8060200@oracle.com>
References: <510F14CF.6050801@oracle.com> <510F84C2.9090505@citrix.com>
	<5110AAFA.7060602@oracle.com>
	<1360057377.17017.7.camel@zakaz.uk.xensource.com>
	<512056D5.6080507@oracle.com> <51206584.8060200@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xend: disallow multiple destroy() 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 Sun, 2013-02-17 at 05:07 +0000, Joe Jin wrote:
> Execute "xl-destroy" twice lead the dom0 panic:
> config file as below:

Thanks.

> kernel BUG at drivers/pci/access.c:423!
[...]
> BTW: xm-create work fine but xl-create trigger the panic as below:

Both the panic above and the warn+panic below seem like kernel bugs
which are simply exposed by xl rather than xl bugs as such. Presumably
xl just tickles things different to xm.

The dom0 kernel you are using is a bit dated and appears (from the
revision) to be rather heavily patched.

> > WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x22d/0x240()
> > Hardware name: SUN FIRE X4370 M2 SERVER
> > remove_proc_entry: removing non-empty directory 'irq/536', leaking at least 'eth7'
[..]
> > BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> > IP: [<ffffffff812f6a76>] evtchn_from_irq+0x16/0x40

Wei recently posted a bug fix for an issue which looked a bit like this
last one. That was something do with error handling on allocation
failure though so I doubt it represents the actual root cause though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 11:05:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:05: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 1U7OX7-0007WJ-Mn; Mon, 18 Feb 2013 11:05:17 +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 1U7OX6-0007WA-Ll
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:05:16 +0000
Received: from [85.158.139.211:6204] by server-11.bemta-5.messagelabs.com id
	C5/04-19159-BEA02215; Mon, 18 Feb 2013 11:05:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361185511!17982414!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3337 invoked from network); 18 Feb 2013 11:05:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Feb 2013 11:05:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 11:05:11 +0000
Message-Id: <512218F202000078000BF1C5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 11:05:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sylvain Munaut" <s.munaut@whatever-company.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:47, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
> It is very reproducible and it's on a test machine I can reboot any
> time, so if you need more debug info, I can collect it.
> I don't have any different hw to test on unfortunately.

Minimally you will want to let us know at what changeset you
cloned your tree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 11:05:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:05: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 1U7OX7-0007WJ-Mn; Mon, 18 Feb 2013 11:05:17 +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 1U7OX6-0007WA-Ll
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:05:16 +0000
Received: from [85.158.139.211:6204] by server-11.bemta-5.messagelabs.com id
	C5/04-19159-BEA02215; Mon, 18 Feb 2013 11:05:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361185511!17982414!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3337 invoked from network); 18 Feb 2013 11:05:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Feb 2013 11:05:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 11:05:11 +0000
Message-Id: <512218F202000078000BF1C5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 11:05:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sylvain Munaut" <s.munaut@whatever-company.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:47, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
> It is very reproducible and it's on a test machine I can reboot any
> time, so if you need more debug info, I can collect it.
> I don't have any different hw to test on unfortunately.

Minimally you will want to let us know at what changeset you
cloned your tree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 11:13:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:13: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 1U7Oek-0007zg-PR; Mon, 18 Feb 2013 11:13: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 1U7Oei-0007zQ-To
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:13:09 +0000
Received: from [85.158.137.99:49454] by server-10.bemta-3.messagelabs.com id
	9E/AF-10609-FBC02215; Mon, 18 Feb 2013 11:13:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361185982!18477559!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13571 invoked from network); 18 Feb 2013 11:13:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 11:13:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1565850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 11:13: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.297.1;
	Mon, 18 Feb 2013 11:13:02 +0000
Message-ID: <1361185981.31407.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Date: Mon, 18 Feb 2013 11:13:01 +0000
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 10:47 +0000, Sylvain Munaut wrote:
> Hi,
> 
> 
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy

Is this exactly 4.2.1, some later revision from 4.2-testing or otherwise
patches? Can you let us know the comit id.

> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...

Please can you share the domain configuration. Are you running PV
drivers (esp. ballooning) within it?

> I enabled the xen serial console and this is what I got when the crash happens:
> 
> 
> (XEN) mm locking order violation: 260 > 222

260 == pod lock, 222 is the p2m lock. I've CCd George and Tim.

> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
> (XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
> (XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
> (XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
> (XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
> (XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
> (XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
> (XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c48029f978:
> (XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
> (XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
> (XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
> (XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
> (XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
> (XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
> (XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
> (XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
> (XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
> (XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
> (XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
> (XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
> (XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
> (XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
> (XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
> (XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
> (XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
> (XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
> (XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
> (XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> 
> 
> Any suggestions ?
> 
> It is very reproducible and it's on a test machine I can reboot any
> time, so if you need more debug info, I can collect it.
> I don't have any different hw to test on unfortunately.
> 
> 
> Cheers,
> 
>     Sylvain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 11:13:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:13: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 1U7Oek-0007zg-PR; Mon, 18 Feb 2013 11:13: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 1U7Oei-0007zQ-To
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:13:09 +0000
Received: from [85.158.137.99:49454] by server-10.bemta-3.messagelabs.com id
	9E/AF-10609-FBC02215; Mon, 18 Feb 2013 11:13:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361185982!18477559!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13571 invoked from network); 18 Feb 2013 11:13:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 11:13:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1565850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 11:13: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.297.1;
	Mon, 18 Feb 2013 11:13:02 +0000
Message-ID: <1361185981.31407.152.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Date: Mon, 18 Feb 2013 11:13:01 +0000
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 10:47 +0000, Sylvain Munaut wrote:
> Hi,
> 
> 
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy

Is this exactly 4.2.1, some later revision from 4.2-testing or otherwise
patches? Can you let us know the comit id.

> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...

Please can you share the domain configuration. Are you running PV
drivers (esp. ballooning) within it?

> I enabled the xen serial console and this is what I got when the crash happens:
> 
> 
> (XEN) mm locking order violation: 260 > 222

260 == pod lock, 222 is the p2m lock. I've CCd George and Tim.

> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
> (XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
> (XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
> (XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
> (XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
> (XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
> (XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
> (XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c48029f978:
> (XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
> (XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
> (XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
> (XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
> (XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
> (XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
> (XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
> (XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
> (XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
> (XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
> (XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
> (XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
> (XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
> (XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
> (XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
> (XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
> (XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
> (XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
> (XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
> (XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> 
> 
> Any suggestions ?
> 
> It is very reproducible and it's on a test machine I can reboot any
> time, so if you need more debug info, I can collect it.
> I don't have any different hw to test on unfortunately.
> 
> 
> Cheers,
> 
>     Sylvain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 11:20:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:20: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 1U7Olq-0008K9-T7; Mon, 18 Feb 2013 11:20:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7Olq-0008K4-0e
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:20:30 +0000
Received: from [85.158.139.211:19389] by server-8.bemta-5.messagelabs.com id
	26/91-19075-D7E02215; Mon, 18 Feb 2013 11:20:29 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361186427!18032190!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3297 invoked from network); 18 Feb 2013 11:20:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 11:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7581924"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 11:20:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 06:20:26 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U7Ob2-0000Gq-Ep;
	Mon, 18 Feb 2013 11:09:20 +0000
Message-ID: <51220BE0.3030600@citrix.com>
Date: Mon, 18 Feb 2013 11:09:20 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Sylvain Munaut <s.munaut@whatever-company.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 10:47, Sylvain Munaut wrote:
> Hi,
>
>
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...
>
> I enabled the xen serial console and this is what I got when the crash happens:
>
>
> (XEN) mm locking order violation: 260 > 222
> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
> (XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
> (XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
> (XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
> (XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
> (XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
> (XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
> (XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c48029f978:
> (XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
> (XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
> (XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
> (XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
> (XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
> (XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
> (XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
> (XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
> (XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
> (XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
> (XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
> (XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
> (XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
> (XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
> (XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
> (XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
> (XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
> (XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
> (XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
> (XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
> Any suggestions ?
>
> It is very reproducible and it's on a test machine I can reboot any
> time, so if you need more debug info, I can collect it.
> I don't have any different hw to test on unfortunately.
>
>
> Cheers,
>
>     Sylvain

>From the stack trace, I assume that the guest is running in shadow mode
?  Can you confirm this?

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 11:20:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:20: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 1U7Olq-0008K9-T7; Mon, 18 Feb 2013 11:20:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7Olq-0008K4-0e
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:20:30 +0000
Received: from [85.158.139.211:19389] by server-8.bemta-5.messagelabs.com id
	26/91-19075-D7E02215; Mon, 18 Feb 2013 11:20:29 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361186427!18032190!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3297 invoked from network); 18 Feb 2013 11:20:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 11:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="7581924"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 11:20:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 06:20:26 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U7Ob2-0000Gq-Ep;
	Mon, 18 Feb 2013 11:09:20 +0000
Message-ID: <51220BE0.3030600@citrix.com>
Date: Mon, 18 Feb 2013 11:09:20 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Sylvain Munaut <s.munaut@whatever-company.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
X-Enigmail-Version: 1.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 10:47, Sylvain Munaut wrote:
> Hi,
>
>
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...
>
> I enabled the xen serial console and this is what I got when the crash happens:
>
>
> (XEN) mm locking order violation: 260 > 222
> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
> (XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
> (XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
> (XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
> (XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
> (XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
> (XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
> (XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c48029f978:
> (XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
> (XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
> (XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
> (XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
> (XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
> (XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
> (XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
> (XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
> (XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
> (XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
> (XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
> (XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
> (XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
> (XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
> (XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
> (XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
> (XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
> (XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
> (XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
> (XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at mm-locks.h:118
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
> Any suggestions ?
>
> It is very reproducible and it's on a test machine I can reboot any
> time, so if you need more debug info, I can collect it.
> I don't have any different hw to test on unfortunately.
>
>
> Cheers,
>
>     Sylvain

>From the stack trace, I assume that the guest is running in shadow mode
?  Can you confirm this?

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 11:22:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:22: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 1U7Onl-0008R5-Fb; Mon, 18 Feb 2013 11:22: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 1U7Onj-0008Qr-Lz
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:22:27 +0000
Received: from [85.158.139.83:24707] by server-11.bemta-5.messagelabs.com id
	4A/C0-19159-2FE02215; Mon, 18 Feb 2013 11:22:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361186544!23472885!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20772 invoked from network); 18 Feb 2013 11:22:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 11:22:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1566239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 11:22: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.297.1;
	Mon, 18 Feb 2013 11:22:24 +0000
Message-ID: <1361186543.31407.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 11:22:23 +0000
In-Reply-To: <1360934328.31407.41.camel@zakaz.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 13:18 +0000, Ian Campbell wrote:
> On Fri, 2013-02-15 at 12:43 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Jan 2013, Ian Campbell wrote:
> > > If a node does not have #*-cells then the parent's value should be
> > > used. Currently we were asssuming zero which is useless.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/domain_build.c   |    6 ++++--
> > >  xen/common/device_tree.c      |   12 ++++++++----
> > >  xen/include/xen/device_tree.h |    3 ++-
> > >  3 files changed, 14 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 7403f1a..bfbe7c7 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -198,8 +198,10 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
> > >          while ( last_depth-- >= depth )
> > >              fdt_end_node(kinfo->fdt);
> > >  
> > > -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> > > -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> > > +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> > > +                                    depth > 0 ? address_cells[depth-1] : 0);
> > > +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> > > +                                    depth > 0 ? size_cells[depth-1] : 0);
> > >  
> > >          fdt_begin_node(kinfo->fdt, name);
> > 
> > The depth is always increasing by steps of 1 in this loop, right?
> > Because retrieving address-cells and size-cells should be recursive: if
> > n-1 doesn't have them, let's look at n-2, etc. Of course if we start from
> > depth = 0 and go from there without missing any levels the results will
> > be the same.
> 
> That was what I thought too. Perhaps it is too subtle?
> 
> I bet my "xen: strip xen,multiboot-module nodes from dom0 device tree"
> patch changes this invariant. Better to make it explicitly walk
> backwards now I think. (or maybe set things for level in
> last_depth..depth). I'll change things along these lines.

I looked into this and even with that patch the invariant that we cannot
skip levels is present. This turns out to be obviously the case because
you have actually open the node and name it... I'll add an ASSERT here
though just in case.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 11:22:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:22: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 1U7Onl-0008R5-Fb; Mon, 18 Feb 2013 11:22: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 1U7Onj-0008Qr-Lz
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:22:27 +0000
Received: from [85.158.139.83:24707] by server-11.bemta-5.messagelabs.com id
	4A/C0-19159-2FE02215; Mon, 18 Feb 2013 11:22:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361186544!23472885!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20772 invoked from network); 18 Feb 2013 11:22:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 11:22:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,686,1355097600"; 
   d="scan'208";a="1566239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 11:22: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.297.1;
	Mon, 18 Feb 2013 11:22:24 +0000
Message-ID: <1361186543.31407.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 11:22:23 +0000
In-Reply-To: <1360934328.31407.41.camel@zakaz.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 13:18 +0000, Ian Campbell wrote:
> On Fri, 2013-02-15 at 12:43 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Jan 2013, Ian Campbell wrote:
> > > If a node does not have #*-cells then the parent's value should be
> > > used. Currently we were asssuming zero which is useless.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > >  xen/arch/arm/domain_build.c   |    6 ++++--
> > >  xen/common/device_tree.c      |   12 ++++++++----
> > >  xen/include/xen/device_tree.h |    3 ++-
> > >  3 files changed, 14 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 7403f1a..bfbe7c7 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -198,8 +198,10 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
> > >          while ( last_depth-- >= depth )
> > >              fdt_end_node(kinfo->fdt);
> > >  
> > > -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> > > -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> > > +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> > > +                                    depth > 0 ? address_cells[depth-1] : 0);
> > > +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> > > +                                    depth > 0 ? size_cells[depth-1] : 0);
> > >  
> > >          fdt_begin_node(kinfo->fdt, name);
> > 
> > The depth is always increasing by steps of 1 in this loop, right?
> > Because retrieving address-cells and size-cells should be recursive: if
> > n-1 doesn't have them, let's look at n-2, etc. Of course if we start from
> > depth = 0 and go from there without missing any levels the results will
> > be the same.
> 
> That was what I thought too. Perhaps it is too subtle?
> 
> I bet my "xen: strip xen,multiboot-module nodes from dom0 device tree"
> patch changes this invariant. Better to make it explicitly walk
> backwards now I think. (or maybe set things for level in
> last_depth..depth). I'll change things along these lines.

I looked into this and even with that patch the invariant that we cannot
skip levels is present. This turns out to be obviously the case because
you have actually open the node and name it... I'll add an ASSERT here
though just in case.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 11:36:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:36: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 1U7P0h-0000M9-1m; Mon, 18 Feb 2013 11:35: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 1U7P0f-0000M4-31
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:35:49 +0000
Received: from [85.158.143.99:42272] by server-3.bemta-4.messagelabs.com id
	73/2F-08920-41212215; Mon, 18 Feb 2013 11:35:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361187342!28001891!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 18 Feb 2013 11:35:43 -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 Feb 2013 11:35:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U7P0X-000Kbz-Fq; Mon, 18 Feb 2013 11:35:41 +0000
Date: Mon, 18 Feb 2013 11:35:41 +0000
From: Tim Deegan <tim@xen.org>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Message-ID: <20130218113541.GA77310@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
	order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Hi, 

Thanks for the report. 

At 11:47 +0100 on 18 Feb (1361188042), Sylvain Munaut wrote:
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...

Did you make any changes to Xen before you built it, or were you just
building your own to get 4.2?

> (XEN) mm locking order violation: 260 > 222
> (XEN) Xen BUG at mm-locks.h:118

Hmm, taking the p2m lock with the pod lock held. :( My guess would be
the p2m_lock() in p2m_pod_emergency_sweep().

Do you by any chance have the xen-syms file from when you built Xen?
That would let us see exactly what's happened.

In the meantime, perhaps you could try the attached (untested) patch.
If my guess is right, it ought to stop the crashes but you might find
the VM's performance suffers.

Cheers,

Tim.

> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

diff -r 4efc7f87d749 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 14 17:07:41 2013 +0000
+++ b/xen/arch/x86/mm/p2m.c	Mon Feb 18 11:32:44 2013 +0000
@@ -219,7 +219,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);
 
@@ -248,8 +248,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;
 

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--jI8keyz6grp/JLjh--


From xen-devel-bounces@lists.xen.org Mon Feb 18 11:36:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 11:36: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 1U7P0h-0000M9-1m; Mon, 18 Feb 2013 11:35: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 1U7P0f-0000M4-31
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 11:35:49 +0000
Received: from [85.158.143.99:42272] by server-3.bemta-4.messagelabs.com id
	73/2F-08920-41212215; Mon, 18 Feb 2013 11:35:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361187342!28001891!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 18 Feb 2013 11:35:43 -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 Feb 2013 11:35:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U7P0X-000Kbz-Fq; Mon, 18 Feb 2013 11:35:41 +0000
Date: Mon, 18 Feb 2013 11:35:41 +0000
From: Tim Deegan <tim@xen.org>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Message-ID: <20130218113541.GA77310@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline
In-Reply-To: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
	order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Hi, 

Thanks for the report. 

At 11:47 +0100 on 18 Feb (1361188042), Sylvain Munaut wrote:
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...

Did you make any changes to Xen before you built it, or were you just
building your own to get 4.2?

> (XEN) mm locking order violation: 260 > 222
> (XEN) Xen BUG at mm-locks.h:118

Hmm, taking the p2m lock with the pod lock held. :( My guess would be
the p2m_lock() in p2m_pod_emergency_sweep().

Do you by any chance have the xen-syms file from when you built Xen?
That would let us see exactly what's happened.

In the meantime, perhaps you could try the attached (untested) patch.
If my guess is right, it ought to stop the crashes but you might find
the VM's performance suffers.

Cheers,

Tim.

> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

diff -r 4efc7f87d749 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 14 17:07:41 2013 +0000
+++ b/xen/arch/x86/mm/p2m.c	Mon Feb 18 11:32:44 2013 +0000
@@ -219,7 +219,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);
 
@@ -248,8 +248,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;
 

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--jI8keyz6grp/JLjh--


From xen-devel-bounces@lists.xen.org Mon Feb 18 12:10:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 12:10: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 1U7PYM-0001me-Gj; Mon, 18 Feb 2013 12:10:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U7PYK-0001mY-Ry
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:10:37 +0000
Received: from [85.158.143.35:61569] by server-1.bemta-4.messagelabs.com id
	A9/CE-08839-C3A12215; Mon, 18 Feb 2013 12:10:36 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361189430!11664197!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4449 invoked from network); 18 Feb 2013 12:10:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 12:10:34 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:51601 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 1U7Pf0-0003mu-8C; Mon, 18 Feb 2013 13:17:30 +0100
Date: Mon, 18 Feb 2013 13:10:28 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1056719956.20130218131028@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361184758.31407.145.camel@zakaz.uk.xensource.com>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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


Monday, February 18, 2013, 11:52:38 AM, you wrote:

> On Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
>> Hi All,
>> 
>> Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
>> Previous pull was working fine and was about 3 or 4 days ago.

> Do you happen to know the exact revisions?

bad: 26579 (tip)
good: 26532

So it has to be somewhere in between.

> Please can you try running xl under gdb and get a backtrace.

Will see if i have the time this afternoon, for the moment i have to have the machine up and running.

>> Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
>> Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]
>> 
>> --
>> 
>> Sander
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 18 12:10:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 12:10: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 1U7PYM-0001me-Gj; Mon, 18 Feb 2013 12:10:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1U7PYK-0001mY-Ry
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:10:37 +0000
Received: from [85.158.143.35:61569] by server-1.bemta-4.messagelabs.com id
	A9/CE-08839-C3A12215; Mon, 18 Feb 2013 12:10:36 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361189430!11664197!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4449 invoked from network); 18 Feb 2013 12:10:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 12:10:34 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:51601 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 1U7Pf0-0003mu-8C; Mon, 18 Feb 2013 13:17:30 +0100
Date: Mon, 18 Feb 2013 13:10:28 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1056719956.20130218131028@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361184758.31407.145.camel@zakaz.uk.xensource.com>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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


Monday, February 18, 2013, 11:52:38 AM, you wrote:

> On Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
>> Hi All,
>> 
>> Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
>> Previous pull was working fine and was about 3 or 4 days ago.

> Do you happen to know the exact revisions?

bad: 26579 (tip)
good: 26532

So it has to be somewhere in between.

> Please can you try running xl under gdb and get a backtrace.

Will see if i have the time this afternoon, for the moment i have to have the machine up and running.

>> Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
>> Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]
>> 
>> --
>> 
>> Sander
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 18 12:39:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 12:39: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 1U7PzY-0003fg-L6; Mon, 18 Feb 2013 12:38:44 +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 1U7PzW-0003fY-UW
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:38:43 +0000
Received: from [85.158.143.35:50965] by server-3.bemta-4.messagelabs.com id
	55/C9-08920-2D022215; Mon, 18 Feb 2013 12:38:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361191032!11668125!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20207 invoked from network); 18 Feb 2013 12:37:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Feb 2013 12:37:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 12:37:11 +0000
Message-Id: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 12:37:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part58682663.1__="
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part58682663.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This should help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -19,6 +19,7 @@
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
 #include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/keyhandler.h>
 #include <xen/trace.h>
@@ -136,6 +137,7 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
     atomic_t credit;
+    unsigned int residual;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
     uint16_t flags;
     int16_t pri;
@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
+    uint64_t val;
     unsigned int credits;
=20
     /* Assert svc is current */
@@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
     if ( (delta =3D now - svc->start_time) <=3D 0 )
         return;
=20
-    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / =
MILLISECS(1);
+    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
+    svc->residual =3D do_div(val, MILLISECS(1));
+    credits =3D val;
+    ASSERT(credits =3D=3D val);
     atomic_sub(credits, &svc->credit);
     svc->start_time +=3D (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSE=
C;
 }
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
=20
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue =
*/
-    int max_weight;
+    unsigned int max_weight;
=20
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already =
targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
=20
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
=20
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -275,12 +276,15 @@ struct csched_dom {
  */
 static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, =
struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val =3D time * rqd->max_weight + svc->residual;
+
+    svc->residual =3D do_div(val, svc->weight);
+    return val;
 }
=20
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, =
struct csched_vcpu *svc)
 {
-    return credit * svc->weight / rqd->max_weight;
+    return (credit * svc->weight - svc->residual) / rqd->max_weight;
 }
=20
 /*




--=__Part58682663.1__=
Content-Type: text/plain; name="sched-credit-residual.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sched-credit-residual.patch"

credit: track residual from divisions done during accounting=0A=0AThis =
should help with under-accounting of vCPU-s running for extremly=0Ashort =
periods of time, but becoming runnable again at a high frequency.=0A=0ASign=
ed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/sched_cred=
it.c=0A+++ b/xen/common/sched_credit.c=0A@@ -19,6 +19,7 @@=0A #include =
<xen/sched-if.h>=0A #include <xen/softirq.h>=0A #include <asm/atomic.h>=0A+=
#include <asm/div64.h>=0A #include <xen/errno.h>=0A #include <xen/keyhandle=
r.h>=0A #include <xen/trace.h>=0A@@ -136,6 +137,7 @@ struct csched_vcpu =
{=0A     struct csched_dom *sdom;=0A     struct vcpu *vcpu;=0A     =
atomic_t credit;=0A+    unsigned int residual;=0A     s_time_t start_time; =
  /* When we were scheduled (used for credit) */=0A     uint16_t flags;=0A =
    int16_t pri;=0A@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu =
*svc)=0A static void burn_credits(struct csched_vcpu *svc, s_time_t =
now)=0A {=0A     s_time_t delta;=0A+    uint64_t val;=0A     unsigned int =
credits;=0A =0A     /* Assert svc is current */=0A@@ -250,7 +253,10 @@ =
static void burn_credits(struct csched_v=0A     if ( (delta =3D now - =
svc->start_time) <=3D 0 )=0A         return;=0A =0A-    credits =3D =
(delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);=0A+    =
val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;=0A+    svc->residu=
al =3D do_div(val, MILLISECS(1));=0A+    credits =3D val;=0A+    ASSERT(cre=
dits =3D=3D val);=0A     atomic_sub(credits, &svc->credit);=0A     =
svc->start_time +=3D (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;=0A=
 }=0A--- a/xen/common/sched_credit2.c=0A+++ b/xen/common/sched_credit2.c=0A=
@@ -21,7 +21,7 @@=0A #include <xen/perfc.h>=0A #include <xen/sched-if.h>=0A=
 #include <xen/softirq.h>=0A-#include <asm/atomic.h>=0A+#include <asm/div64=
.h>=0A #include <xen/errno.h>=0A #include <xen/trace.h>=0A #include =
<xen/cpu.h>=0A@@ -205,7 +205,7 @@ struct csched_runqueue_data {=0A =0A     =
struct list_head runq; /* Ordered list of runnable vms */=0A     struct =
list_head svc;  /* List of all vcpus assigned to this runqueue */=0A-    =
int max_weight;=0A+    unsigned int max_weight;=0A =0A     cpumask_t idle, =
       /* Currently idle */=0A         tickled;           /* Another cpu =
in the queue is already targeted for this one */=0A@@ -244,7 +244,8 @@ =
struct csched_vcpu {=0A     struct csched_dom *sdom;=0A     struct vcpu =
*vcpu;=0A =0A-    int weight;=0A+    unsigned int weight;=0A+    unsigned =
int residual;=0A =0A     int credit;=0A     s_time_t start_time; /* When =
we were scheduled (used for credit) */=0A@@ -275,12 +276,15 @@ struct =
csched_dom {=0A  */=0A static s_time_t t2c(struct csched_runqueue_data =
*rqd, s_time_t time, struct csched_vcpu *svc)=0A {=0A-    return time * =
rqd->max_weight / svc->weight;=0A+    uint64_t val =3D time * rqd->max_weig=
ht + svc->residual;=0A+=0A+    svc->residual =3D do_div(val, svc->weight);=
=0A+    return val;=0A }=0A =0A static s_time_t c2t(struct csched_runqueue_=
data *rqd, s_time_t credit, struct csched_vcpu *svc)=0A {=0A-    return =
credit * svc->weight / rqd->max_weight;=0A+    return (credit * svc->weight=
 - svc->residual) / rqd->max_weight;=0A }=0A =0A /*=0A
--=__Part58682663.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

--=__Part58682663.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 18 12:39:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 12:39: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 1U7PzY-0003fg-L6; Mon, 18 Feb 2013 12:38:44 +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 1U7PzW-0003fY-UW
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:38:43 +0000
Received: from [85.158.143.35:50965] by server-3.bemta-4.messagelabs.com id
	55/C9-08920-2D022215; Mon, 18 Feb 2013 12:38:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361191032!11668125!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20207 invoked from network); 18 Feb 2013 12:37:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Feb 2013 12:37:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 12:37:11 +0000
Message-Id: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 12:37:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part58682663.1__="
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part58682663.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This should help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -19,6 +19,7 @@
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
 #include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/keyhandler.h>
 #include <xen/trace.h>
@@ -136,6 +137,7 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
     atomic_t credit;
+    unsigned int residual;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
     uint16_t flags;
     int16_t pri;
@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
+    uint64_t val;
     unsigned int credits;
=20
     /* Assert svc is current */
@@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
     if ( (delta =3D now - svc->start_time) <=3D 0 )
         return;
=20
-    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / =
MILLISECS(1);
+    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
+    svc->residual =3D do_div(val, MILLISECS(1));
+    credits =3D val;
+    ASSERT(credits =3D=3D val);
     atomic_sub(credits, &svc->credit);
     svc->start_time +=3D (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSE=
C;
 }
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
=20
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue =
*/
-    int max_weight;
+    unsigned int max_weight;
=20
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already =
targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
=20
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
=20
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -275,12 +276,15 @@ struct csched_dom {
  */
 static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, =
struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val =3D time * rqd->max_weight + svc->residual;
+
+    svc->residual =3D do_div(val, svc->weight);
+    return val;
 }
=20
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, =
struct csched_vcpu *svc)
 {
-    return credit * svc->weight / rqd->max_weight;
+    return (credit * svc->weight - svc->residual) / rqd->max_weight;
 }
=20
 /*




--=__Part58682663.1__=
Content-Type: text/plain; name="sched-credit-residual.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sched-credit-residual.patch"

credit: track residual from divisions done during accounting=0A=0AThis =
should help with under-accounting of vCPU-s running for extremly=0Ashort =
periods of time, but becoming runnable again at a high frequency.=0A=0ASign=
ed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/sched_cred=
it.c=0A+++ b/xen/common/sched_credit.c=0A@@ -19,6 +19,7 @@=0A #include =
<xen/sched-if.h>=0A #include <xen/softirq.h>=0A #include <asm/atomic.h>=0A+=
#include <asm/div64.h>=0A #include <xen/errno.h>=0A #include <xen/keyhandle=
r.h>=0A #include <xen/trace.h>=0A@@ -136,6 +137,7 @@ struct csched_vcpu =
{=0A     struct csched_dom *sdom;=0A     struct vcpu *vcpu;=0A     =
atomic_t credit;=0A+    unsigned int residual;=0A     s_time_t start_time; =
  /* When we were scheduled (used for credit) */=0A     uint16_t flags;=0A =
    int16_t pri;=0A@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu =
*svc)=0A static void burn_credits(struct csched_vcpu *svc, s_time_t =
now)=0A {=0A     s_time_t delta;=0A+    uint64_t val;=0A     unsigned int =
credits;=0A =0A     /* Assert svc is current */=0A@@ -250,7 +253,10 @@ =
static void burn_credits(struct csched_v=0A     if ( (delta =3D now - =
svc->start_time) <=3D 0 )=0A         return;=0A =0A-    credits =3D =
(delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);=0A+    =
val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;=0A+    svc->residu=
al =3D do_div(val, MILLISECS(1));=0A+    credits =3D val;=0A+    ASSERT(cre=
dits =3D=3D val);=0A     atomic_sub(credits, &svc->credit);=0A     =
svc->start_time +=3D (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;=0A=
 }=0A--- a/xen/common/sched_credit2.c=0A+++ b/xen/common/sched_credit2.c=0A=
@@ -21,7 +21,7 @@=0A #include <xen/perfc.h>=0A #include <xen/sched-if.h>=0A=
 #include <xen/softirq.h>=0A-#include <asm/atomic.h>=0A+#include <asm/div64=
.h>=0A #include <xen/errno.h>=0A #include <xen/trace.h>=0A #include =
<xen/cpu.h>=0A@@ -205,7 +205,7 @@ struct csched_runqueue_data {=0A =0A     =
struct list_head runq; /* Ordered list of runnable vms */=0A     struct =
list_head svc;  /* List of all vcpus assigned to this runqueue */=0A-    =
int max_weight;=0A+    unsigned int max_weight;=0A =0A     cpumask_t idle, =
       /* Currently idle */=0A         tickled;           /* Another cpu =
in the queue is already targeted for this one */=0A@@ -244,7 +244,8 @@ =
struct csched_vcpu {=0A     struct csched_dom *sdom;=0A     struct vcpu =
*vcpu;=0A =0A-    int weight;=0A+    unsigned int weight;=0A+    unsigned =
int residual;=0A =0A     int credit;=0A     s_time_t start_time; /* When =
we were scheduled (used for credit) */=0A@@ -275,12 +276,15 @@ struct =
csched_dom {=0A  */=0A static s_time_t t2c(struct csched_runqueue_data =
*rqd, s_time_t time, struct csched_vcpu *svc)=0A {=0A-    return time * =
rqd->max_weight / svc->weight;=0A+    uint64_t val =3D time * rqd->max_weig=
ht + svc->residual;=0A+=0A+    svc->residual =3D do_div(val, svc->weight);=
=0A+    return val;=0A }=0A =0A static s_time_t c2t(struct csched_runqueue_=
data *rqd, s_time_t credit, struct csched_vcpu *svc)=0A {=0A-    return =
credit * svc->weight / rqd->max_weight;=0A+    return (credit * svc->weight=
 - svc->residual) / rqd->max_weight;=0A }=0A =0A /*=0A
--=__Part58682663.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

--=__Part58682663.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 18 12:47:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 12:47: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 1U7Q8A-0003yH-Lv; Mon, 18 Feb 2013 12:47:38 +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 1U7Q89-0003yC-Km
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:47:38 +0000
Received: from [85.158.143.99:15126] by server-2.bemta-4.messagelabs.com id
	44/A7-12656-8E222215; Mon, 18 Feb 2013 12:47:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361191656!27515623!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28933 invoked from network); 18 Feb 2013 12:47:36 -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; 18 Feb 2013 12:47:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 12:45:35 +0000
Message-Id: <5122307D02000078000BF20C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 12:45:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part44743A7D.0__="
Subject: [Xen-devel] [PATCH] xmalloc: make close-to-PAGE_SIZE allocations
 more efficient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part44743A7D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than bumping their sizes to slightly above (a multiple of)
PAGE_SIZE (in order to store tracking information), thus requiring
a non-order-0 allocation even when no more than a page is being
requested, return the result of alloc_xenheap_pages() directly, and use
the struct page_info field underlying PFN_ORDER() to store the actual
size (needed for freeing the memory).

This leverages the fact that sub-allocation of memory obtained from the
page allocator can only ever result in non-page-aligned memory chunks
(with the exception of zero size allocations with sufficiently high
alignment being requested, which is why zero-size allocations now get
special cased).

Use the new property to simplify allocation of the trap info array for
PV guests on x86.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -369,13 +369,6 @@ int switch_compat(struct domain *d)
     return -ENOMEM;
 }
=20
-static inline bool_t standalone_trap_ctxt(struct vcpu *v)
-{
-    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > =
PAGE_SIZE);
-    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
-           > PAGE_SIZE;
-}
-
 int vcpu_initialise(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
@@ -427,19 +420,15 @@ int vcpu_initialise(struct vcpu *v)
=20
     if ( !is_idle_domain(d) )
     {
-        if ( standalone_trap_ctxt(v) )
+        BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
+                     PAGE_SIZE);
+        v->arch.pv_vcpu.trap_ctxt =3D xzalloc_array(struct trap_info,
+                                                  NR_VECTORS);
+        if ( !v->arch.pv_vcpu.trap_ctxt )
         {
-            v->arch.pv_vcpu.trap_ctxt =3D alloc_xenheap_page();
-            if ( !v->arch.pv_vcpu.trap_ctxt )
-            {
-                rc =3D -ENOMEM;
-                goto done;
-            }
-            clear_page(v->arch.pv_vcpu.trap_ctxt);
+            rc =3D -ENOMEM;
+            goto done;
         }
-        else
-            v->arch.pv_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -
-                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
=20
         /* PV guests by default have a 100Hz ticker. */
         v->periodic_period =3D MILLISECS(10);
@@ -467,8 +456,8 @@ int vcpu_initialise(struct vcpu *v)
     {
         vcpu_destroy_fpu(v);
=20
-        if ( !is_hvm_domain(d) && standalone_trap_ctxt(v) )
-            free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
+        if ( !is_hvm_domain(d) )
+            xfree(v->arch.pv_vcpu.trap_ctxt);
     }
=20
     return rc;
@@ -483,8 +472,8 @@ void vcpu_destroy(struct vcpu *v)
=20
     if ( is_hvm_vcpu(v) )
         hvm_vcpu_destroy(v);
-    else if ( standalone_trap_ctxt(v) )
-        free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
+    else
+        xfree(v->arch.pv_vcpu.trap_ctxt);
 }
=20
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -26,6 +26,7 @@
 #include <xen/config.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
+#include <xen/pfn.h>
 #include <asm/time.h>
=20
 #define MAX_POOL_NAME_LEN       16
@@ -524,25 +525,30 @@ static void xmalloc_pool_put(void *p)
     free_xenheap_page(p);
 }
=20
-static void *xmalloc_whole_pages(unsigned long size)
+static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
 {
-    struct bhdr *b;
-    unsigned int i, pageorder =3D get_order_from_bytes(size + BHDR_OVERHEA=
D);
-    char *p;
+    unsigned int i, order =3D get_order_from_bytes(size);
+    void *res, *p;
+
+    if ( align > size )
+        get_order_from_bytes(align);
=20
-    b =3D alloc_xenheap_pages(pageorder, 0);
-    if ( b =3D=3D NULL )
+    res =3D alloc_xenheap_pages(order, 0);
+    if ( res =3D=3D NULL )
         return NULL;
=20
-    b->size =3D PAGE_ALIGN(size + BHDR_OVERHEAD);
-    for ( p =3D (char *)b + b->size, i =3D 0; i < pageorder; ++i )
+    for ( p =3D res + PAGE_ALIGN(size), i =3D 0; i < order; ++i )
         if ( (unsigned long)p & (PAGE_SIZE << i) )
         {
             free_xenheap_pages(p, i);
             p +=3D PAGE_SIZE << i;
         }
=20
-    return (void *)b->ptr.buffer;
+    PFN_ORDER(virt_to_page(res)) =3D PFN_UP(size);
+    /* Check that there was no truncation: */
+    ASSERT(PFN_ORDER(virt_to_page(res)) =3D=3D PFN_UP(size));
+
+    return res;
 }
=20
 static void tlsf_init(void)
@@ -559,6 +565,11 @@ static void tlsf_init(void)
  * xmalloc()
  */
=20
+#ifndef ZERO_BLOCK_PTR
+/* Return value for zero-size allocation, distinguished from NULL. */
+#define ZERO_BLOCK_PTR ((void *)-1L)
+#endif
+
 void *_xmalloc(unsigned long size, unsigned long align)
 {
     void *p =3D NULL;
@@ -566,6 +577,9 @@ void *_xmalloc(unsigned long size, unsig
=20
     ASSERT(!in_irq());
=20
+    if ( !size )
+        return ZERO_BLOCK_PTR;
+
     ASSERT((align & (align - 1)) =3D=3D 0);
     if ( align < MEM_ALIGN )
         align =3D MEM_ALIGN;
@@ -577,7 +591,7 @@ void *_xmalloc(unsigned long size, unsig
     if ( size < PAGE_SIZE )
         p =3D xmem_pool_alloc(size, xenpool);
     if ( p =3D=3D NULL )
-        p =3D xmalloc_whole_pages(size);
+        return xmalloc_whole_pages(size - align + MEM_ALIGN, align);
=20
     /* Add alignment padding. */
     if ( (pad =3D -(long)p & (align - 1)) !=3D 0 )
@@ -604,11 +618,28 @@ void xfree(void *p)
 {
     struct bhdr *b;
=20
-    if ( p =3D=3D NULL )
+    if ( p =3D=3D NULL || p =3D=3D ZERO_BLOCK_PTR )
         return;
=20
     ASSERT(!in_irq());
=20
+    if ( !((unsigned long)p & (PAGE_SIZE - 1)) )
+    {
+        unsigned long size =3D PFN_ORDER(virt_to_page(p));
+        unsigned int i, order =3D get_order_from_pages(size);
+
+        BUG_ON((unsigned long)p & ((PAGE_SIZE << order) - 1));
+        for ( i =3D 0; ; ++i )
+        {
+            if ( !(size & (1 << i)) )
+                continue;
+            size -=3D 1 << i;
+            free_xenheap_pages(p + (size << PAGE_SHIFT), i);
+            if ( i + 1 >=3D order )
+                return;
+        }
+    }
+
     /* Strip alignment padding. */
     b =3D (struct bhdr *)((char *) p - BHDR_OVERHEAD);
     if ( b->size & 1 )
@@ -618,21 +649,5 @@ void xfree(void *p)
         ASSERT(!(b->size & 1));
     }
=20
-    if ( b->size >=3D PAGE_SIZE )
-    {
-        unsigned int i, order =3D get_order_from_bytes(b->size);
-
-        BUG_ON((unsigned long)b & ((PAGE_SIZE << order) - 1));
-        for ( i =3D 0; ; ++i )
-        {
-            if ( !(b->size & (PAGE_SIZE << i)) )
-                continue;
-            b->size -=3D PAGE_SIZE << i;
-            free_xenheap_pages((void *)b + b->size, i);
-            if ( i + 1 >=3D order )
-                break;
-        }
-    }
-    else
-        xmem_pool_free(p, xenpool);
+    xmem_pool_free(p, xenpool);
 }
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -91,6 +91,9 @@
 /* Primary stack is restricted to 8kB by guard pages. */
 #define PRIMARY_STACK_SIZE 8192
=20
+/* Return value for zero-size _xmalloc(), distinguished from NULL. */
+#define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
+
 #ifndef __ASSEMBLY__
 extern unsigned long trampoline_phys;
 #define bootsym_phys(sym)                                 \



--=__Part44743A7D.0__=
Content-Type: text/plain; name="xmalloc-exact-pages.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xmalloc-exact-pages.patch"

xmalloc: make close-to-PAGE_SIZE allocations more efficient=0A=0ARather =
than bumping their sizes to slightly above (a multiple of)=0APAGE_SIZE (in =
order to store tracking information), thus requiring=0Aa non-order-0 =
allocation even when no more than a page is being=0Arequested, return the =
result of alloc_xenheap_pages() directly, and use=0Athe struct page_info =
field underlying PFN_ORDER() to store the actual=0Asize (needed for =
freeing the memory).=0A=0AThis leverages the fact that sub-allocation of =
memory obtained from the=0Apage allocator can only ever result in =
non-page-aligned memory chunks=0A(with the exception of zero size =
allocations with sufficiently high=0Aalignment being requested, which is =
why zero-size allocations now get=0Aspecial cased).=0A=0AUse the new =
property to simplify allocation of the trap info array for=0APV guests on =
x86.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -369,13 +369,6 =
@@ int switch_compat(struct domain *d)=0A     return -ENOMEM;=0A }=0A =
=0A-static inline bool_t standalone_trap_ctxt(struct vcpu *v)=0A-{=0A-    =
BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=
=0A-    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)=
=0A-           > PAGE_SIZE;=0A-}=0A-=0A int vcpu_initialise(struct vcpu =
*v)=0A {=0A     struct domain *d =3D v->domain;=0A@@ -427,19 +420,15 @@ =
int vcpu_initialise(struct vcpu *v)=0A =0A     if ( !is_idle_domain(d) =
)=0A     {=0A-        if ( standalone_trap_ctxt(v) )=0A+        BUILD_BUG_O=
N(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >=0A+                    =
 PAGE_SIZE);=0A+        v->arch.pv_vcpu.trap_ctxt =3D xzalloc_array(struct =
trap_info,=0A+                                                  NR_VECTORS)=
;=0A+        if ( !v->arch.pv_vcpu.trap_ctxt )=0A         {=0A-            =
v->arch.pv_vcpu.trap_ctxt =3D alloc_xenheap_page();=0A-            if ( =
!v->arch.pv_vcpu.trap_ctxt )=0A-            {=0A-                rc =3D =
-ENOMEM;=0A-                goto done;=0A-            }=0A-            =
clear_page(v->arch.pv_vcpu.trap_ctxt);=0A+            rc =3D -ENOMEM;=0A+  =
          goto done;=0A         }=0A-        else=0A-            v->arch.pv=
_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -=0A-                NR_VECTORS =
* sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A =0A         /* PV guests by =
default have a 100Hz ticker. */=0A         v->periodic_period =3D =
MILLISECS(10);=0A@@ -467,8 +456,8 @@ int vcpu_initialise(struct vcpu =
*v)=0A     {=0A         vcpu_destroy_fpu(v);=0A =0A-        if ( !is_hvm_do=
main(d) && standalone_trap_ctxt(v) )=0A-            free_xenheap_page(v->ar=
ch.pv_vcpu.trap_ctxt);=0A+        if ( !is_hvm_domain(d) )=0A+            =
xfree(v->arch.pv_vcpu.trap_ctxt);=0A     }=0A =0A     return rc;=0A@@ =
-483,8 +472,8 @@ void vcpu_destroy(struct vcpu *v)=0A =0A     if ( =
is_hvm_vcpu(v) )=0A         hvm_vcpu_destroy(v);=0A-    else if ( =
standalone_trap_ctxt(v) )=0A-        free_xenheap_page(v->arch.pv_vcpu.trap=
_ctxt);=0A+    else=0A+        xfree(v->arch.pv_vcpu.trap_ctxt);=0A }=0A =
=0A int arch_domain_create(struct domain *d, unsigned int domcr_flags)=0A--=
- a/xen/common/xmalloc_tlsf.c=0A+++ b/xen/common/xmalloc_tlsf.c=0A@@ -26,6 =
+26,7 @@=0A #include <xen/config.h>=0A #include <xen/irq.h>=0A #include =
<xen/mm.h>=0A+#include <xen/pfn.h>=0A #include <asm/time.h>=0A =0A #define =
MAX_POOL_NAME_LEN       16=0A@@ -524,25 +525,30 @@ static void xmalloc_pool=
_put(void *p)=0A     free_xenheap_page(p);=0A }=0A =0A-static void =
*xmalloc_whole_pages(unsigned long size)=0A+static void *xmalloc_whole_page=
s(unsigned long size, unsigned long align)=0A {=0A-    struct bhdr *b;=0A- =
   unsigned int i, pageorder =3D get_order_from_bytes(size + BHDR_OVERHEAD)=
;=0A-    char *p;=0A+    unsigned int i, order =3D get_order_from_bytes(siz=
e);=0A+    void *res, *p;=0A+=0A+    if ( align > size )=0A+        =
get_order_from_bytes(align);=0A =0A-    b =3D alloc_xenheap_pages(pageorder=
, 0);=0A-    if ( b =3D=3D NULL )=0A+    res =3D alloc_xenheap_pages(order,=
 0);=0A+    if ( res =3D=3D NULL )=0A         return NULL;=0A =0A-    =
b->size =3D PAGE_ALIGN(size + BHDR_OVERHEAD);=0A-    for ( p =3D (char *)b =
+ b->size, i =3D 0; i < pageorder; ++i )=0A+    for ( p =3D res + =
PAGE_ALIGN(size), i =3D 0; i < order; ++i )=0A         if ( (unsigned =
long)p & (PAGE_SIZE << i) )=0A         {=0A             free_xenheap_pages(=
p, i);=0A             p +=3D PAGE_SIZE << i;=0A         }=0A =0A-    =
return (void *)b->ptr.buffer;=0A+    PFN_ORDER(virt_to_page(res)) =3D =
PFN_UP(size);=0A+    /* Check that there was no truncation: */=0A+    =
ASSERT(PFN_ORDER(virt_to_page(res)) =3D=3D PFN_UP(size));=0A+=0A+    =
return res;=0A }=0A =0A static void tlsf_init(void)=0A@@ -559,6 +565,11 @@ =
static void tlsf_init(void)=0A  * xmalloc()=0A  */=0A =0A+#ifndef =
ZERO_BLOCK_PTR=0A+/* Return value for zero-size allocation, distinguished =
from NULL. */=0A+#define ZERO_BLOCK_PTR ((void *)-1L)=0A+#endif=0A+=0A =
void *_xmalloc(unsigned long size, unsigned long align)=0A {=0A     void =
*p =3D NULL;=0A@@ -566,6 +577,9 @@ void *_xmalloc(unsigned long size, =
unsig=0A =0A     ASSERT(!in_irq());=0A =0A+    if ( !size )=0A+        =
return ZERO_BLOCK_PTR;=0A+=0A     ASSERT((align & (align - 1)) =3D=3D =
0);=0A     if ( align < MEM_ALIGN )=0A         align =3D MEM_ALIGN;=0A@@ =
-577,7 +591,7 @@ void *_xmalloc(unsigned long size, unsig=0A     if ( size =
< PAGE_SIZE )=0A         p =3D xmem_pool_alloc(size, xenpool);=0A     if ( =
p =3D=3D NULL )=0A-        p =3D xmalloc_whole_pages(size);=0A+        =
return xmalloc_whole_pages(size - align + MEM_ALIGN, align);=0A =0A     /* =
Add alignment padding. */=0A     if ( (pad =3D -(long)p & (align - 1)) =
!=3D 0 )=0A@@ -604,11 +618,28 @@ void xfree(void *p)=0A {=0A     struct =
bhdr *b;=0A =0A-    if ( p =3D=3D NULL )=0A+    if ( p =3D=3D NULL || p =
=3D=3D ZERO_BLOCK_PTR )=0A         return;=0A =0A     ASSERT(!in_irq());=0A=
 =0A+    if ( !((unsigned long)p & (PAGE_SIZE - 1)) )=0A+    {=0A+        =
unsigned long size =3D PFN_ORDER(virt_to_page(p));=0A+        unsigned int =
i, order =3D get_order_from_pages(size);=0A+=0A+        BUG_ON((unsigned =
long)p & ((PAGE_SIZE << order) - 1));=0A+        for ( i =3D 0; ; ++i =
)=0A+        {=0A+            if ( !(size & (1 << i)) )=0A+                =
continue;=0A+            size -=3D 1 << i;=0A+            free_xenheap_page=
s(p + (size << PAGE_SHIFT), i);=0A+            if ( i + 1 >=3D order )=0A+ =
               return;=0A+        }=0A+    }=0A+=0A     /* Strip alignment =
padding. */=0A     b =3D (struct bhdr *)((char *) p - BHDR_OVERHEAD);=0A   =
  if ( b->size & 1 )=0A@@ -618,21 +649,5 @@ void xfree(void *p)=0A         =
ASSERT(!(b->size & 1));=0A     }=0A =0A-    if ( b->size >=3D PAGE_SIZE =
)=0A-    {=0A-        unsigned int i, order =3D get_order_from_bytes(b->siz=
e);=0A-=0A-        BUG_ON((unsigned long)b & ((PAGE_SIZE << order) - =
1));=0A-        for ( i =3D 0; ; ++i )=0A-        {=0A-            if ( =
!(b->size & (PAGE_SIZE << i)) )=0A-                continue;=0A-           =
 b->size -=3D PAGE_SIZE << i;=0A-            free_xenheap_pages((void *)b =
+ b->size, i);=0A-            if ( i + 1 >=3D order )=0A-                =
break;=0A-        }=0A-    }=0A-    else=0A-        xmem_pool_free(p, =
xenpool);=0A+    xmem_pool_free(p, xenpool);=0A }=0A--- a/xen/include/asm-x=
86/config.h=0A+++ b/xen/include/asm-x86/config.h=0A@@ -91,6 +91,9 @@=0A /* =
Primary stack is restricted to 8kB by guard pages. */=0A #define PRIMARY_ST=
ACK_SIZE 8192=0A =0A+/* Return value for zero-size _xmalloc(), distinguishe=
d from NULL. */=0A+#define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)=0A=
+=0A #ifndef __ASSEMBLY__=0A extern unsigned long trampoline_phys;=0A =
#define bootsym_phys(sym)                                 \=0A
--=__Part44743A7D.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

--=__Part44743A7D.0__=--


From xen-devel-bounces@lists.xen.org Mon Feb 18 12:47:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 12:47: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 1U7Q8A-0003yH-Lv; Mon, 18 Feb 2013 12:47:38 +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 1U7Q89-0003yC-Km
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:47:38 +0000
Received: from [85.158.143.99:15126] by server-2.bemta-4.messagelabs.com id
	44/A7-12656-8E222215; Mon, 18 Feb 2013 12:47:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361191656!27515623!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28933 invoked from network); 18 Feb 2013 12:47:36 -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; 18 Feb 2013 12:47:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 18 Feb 2013 12:45:35 +0000
Message-Id: <5122307D02000078000BF20C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 18 Feb 2013 12:45:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part44743A7D.0__="
Subject: [Xen-devel] [PATCH] xmalloc: make close-to-PAGE_SIZE allocations
 more efficient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part44743A7D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than bumping their sizes to slightly above (a multiple of)
PAGE_SIZE (in order to store tracking information), thus requiring
a non-order-0 allocation even when no more than a page is being
requested, return the result of alloc_xenheap_pages() directly, and use
the struct page_info field underlying PFN_ORDER() to store the actual
size (needed for freeing the memory).

This leverages the fact that sub-allocation of memory obtained from the
page allocator can only ever result in non-page-aligned memory chunks
(with the exception of zero size allocations with sufficiently high
alignment being requested, which is why zero-size allocations now get
special cased).

Use the new property to simplify allocation of the trap info array for
PV guests on x86.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -369,13 +369,6 @@ int switch_compat(struct domain *d)
     return -ENOMEM;
 }
=20
-static inline bool_t standalone_trap_ctxt(struct vcpu *v)
-{
-    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > =
PAGE_SIZE);
-    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
-           > PAGE_SIZE;
-}
-
 int vcpu_initialise(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
@@ -427,19 +420,15 @@ int vcpu_initialise(struct vcpu *v)
=20
     if ( !is_idle_domain(d) )
     {
-        if ( standalone_trap_ctxt(v) )
+        BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
+                     PAGE_SIZE);
+        v->arch.pv_vcpu.trap_ctxt =3D xzalloc_array(struct trap_info,
+                                                  NR_VECTORS);
+        if ( !v->arch.pv_vcpu.trap_ctxt )
         {
-            v->arch.pv_vcpu.trap_ctxt =3D alloc_xenheap_page();
-            if ( !v->arch.pv_vcpu.trap_ctxt )
-            {
-                rc =3D -ENOMEM;
-                goto done;
-            }
-            clear_page(v->arch.pv_vcpu.trap_ctxt);
+            rc =3D -ENOMEM;
+            goto done;
         }
-        else
-            v->arch.pv_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -
-                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
=20
         /* PV guests by default have a 100Hz ticker. */
         v->periodic_period =3D MILLISECS(10);
@@ -467,8 +456,8 @@ int vcpu_initialise(struct vcpu *v)
     {
         vcpu_destroy_fpu(v);
=20
-        if ( !is_hvm_domain(d) && standalone_trap_ctxt(v) )
-            free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
+        if ( !is_hvm_domain(d) )
+            xfree(v->arch.pv_vcpu.trap_ctxt);
     }
=20
     return rc;
@@ -483,8 +472,8 @@ void vcpu_destroy(struct vcpu *v)
=20
     if ( is_hvm_vcpu(v) )
         hvm_vcpu_destroy(v);
-    else if ( standalone_trap_ctxt(v) )
-        free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
+    else
+        xfree(v->arch.pv_vcpu.trap_ctxt);
 }
=20
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -26,6 +26,7 @@
 #include <xen/config.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
+#include <xen/pfn.h>
 #include <asm/time.h>
=20
 #define MAX_POOL_NAME_LEN       16
@@ -524,25 +525,30 @@ static void xmalloc_pool_put(void *p)
     free_xenheap_page(p);
 }
=20
-static void *xmalloc_whole_pages(unsigned long size)
+static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
 {
-    struct bhdr *b;
-    unsigned int i, pageorder =3D get_order_from_bytes(size + BHDR_OVERHEA=
D);
-    char *p;
+    unsigned int i, order =3D get_order_from_bytes(size);
+    void *res, *p;
+
+    if ( align > size )
+        get_order_from_bytes(align);
=20
-    b =3D alloc_xenheap_pages(pageorder, 0);
-    if ( b =3D=3D NULL )
+    res =3D alloc_xenheap_pages(order, 0);
+    if ( res =3D=3D NULL )
         return NULL;
=20
-    b->size =3D PAGE_ALIGN(size + BHDR_OVERHEAD);
-    for ( p =3D (char *)b + b->size, i =3D 0; i < pageorder; ++i )
+    for ( p =3D res + PAGE_ALIGN(size), i =3D 0; i < order; ++i )
         if ( (unsigned long)p & (PAGE_SIZE << i) )
         {
             free_xenheap_pages(p, i);
             p +=3D PAGE_SIZE << i;
         }
=20
-    return (void *)b->ptr.buffer;
+    PFN_ORDER(virt_to_page(res)) =3D PFN_UP(size);
+    /* Check that there was no truncation: */
+    ASSERT(PFN_ORDER(virt_to_page(res)) =3D=3D PFN_UP(size));
+
+    return res;
 }
=20
 static void tlsf_init(void)
@@ -559,6 +565,11 @@ static void tlsf_init(void)
  * xmalloc()
  */
=20
+#ifndef ZERO_BLOCK_PTR
+/* Return value for zero-size allocation, distinguished from NULL. */
+#define ZERO_BLOCK_PTR ((void *)-1L)
+#endif
+
 void *_xmalloc(unsigned long size, unsigned long align)
 {
     void *p =3D NULL;
@@ -566,6 +577,9 @@ void *_xmalloc(unsigned long size, unsig
=20
     ASSERT(!in_irq());
=20
+    if ( !size )
+        return ZERO_BLOCK_PTR;
+
     ASSERT((align & (align - 1)) =3D=3D 0);
     if ( align < MEM_ALIGN )
         align =3D MEM_ALIGN;
@@ -577,7 +591,7 @@ void *_xmalloc(unsigned long size, unsig
     if ( size < PAGE_SIZE )
         p =3D xmem_pool_alloc(size, xenpool);
     if ( p =3D=3D NULL )
-        p =3D xmalloc_whole_pages(size);
+        return xmalloc_whole_pages(size - align + MEM_ALIGN, align);
=20
     /* Add alignment padding. */
     if ( (pad =3D -(long)p & (align - 1)) !=3D 0 )
@@ -604,11 +618,28 @@ void xfree(void *p)
 {
     struct bhdr *b;
=20
-    if ( p =3D=3D NULL )
+    if ( p =3D=3D NULL || p =3D=3D ZERO_BLOCK_PTR )
         return;
=20
     ASSERT(!in_irq());
=20
+    if ( !((unsigned long)p & (PAGE_SIZE - 1)) )
+    {
+        unsigned long size =3D PFN_ORDER(virt_to_page(p));
+        unsigned int i, order =3D get_order_from_pages(size);
+
+        BUG_ON((unsigned long)p & ((PAGE_SIZE << order) - 1));
+        for ( i =3D 0; ; ++i )
+        {
+            if ( !(size & (1 << i)) )
+                continue;
+            size -=3D 1 << i;
+            free_xenheap_pages(p + (size << PAGE_SHIFT), i);
+            if ( i + 1 >=3D order )
+                return;
+        }
+    }
+
     /* Strip alignment padding. */
     b =3D (struct bhdr *)((char *) p - BHDR_OVERHEAD);
     if ( b->size & 1 )
@@ -618,21 +649,5 @@ void xfree(void *p)
         ASSERT(!(b->size & 1));
     }
=20
-    if ( b->size >=3D PAGE_SIZE )
-    {
-        unsigned int i, order =3D get_order_from_bytes(b->size);
-
-        BUG_ON((unsigned long)b & ((PAGE_SIZE << order) - 1));
-        for ( i =3D 0; ; ++i )
-        {
-            if ( !(b->size & (PAGE_SIZE << i)) )
-                continue;
-            b->size -=3D PAGE_SIZE << i;
-            free_xenheap_pages((void *)b + b->size, i);
-            if ( i + 1 >=3D order )
-                break;
-        }
-    }
-    else
-        xmem_pool_free(p, xenpool);
+    xmem_pool_free(p, xenpool);
 }
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -91,6 +91,9 @@
 /* Primary stack is restricted to 8kB by guard pages. */
 #define PRIMARY_STACK_SIZE 8192
=20
+/* Return value for zero-size _xmalloc(), distinguished from NULL. */
+#define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
+
 #ifndef __ASSEMBLY__
 extern unsigned long trampoline_phys;
 #define bootsym_phys(sym)                                 \



--=__Part44743A7D.0__=
Content-Type: text/plain; name="xmalloc-exact-pages.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xmalloc-exact-pages.patch"

xmalloc: make close-to-PAGE_SIZE allocations more efficient=0A=0ARather =
than bumping their sizes to slightly above (a multiple of)=0APAGE_SIZE (in =
order to store tracking information), thus requiring=0Aa non-order-0 =
allocation even when no more than a page is being=0Arequested, return the =
result of alloc_xenheap_pages() directly, and use=0Athe struct page_info =
field underlying PFN_ORDER() to store the actual=0Asize (needed for =
freeing the memory).=0A=0AThis leverages the fact that sub-allocation of =
memory obtained from the=0Apage allocator can only ever result in =
non-page-aligned memory chunks=0A(with the exception of zero size =
allocations with sufficiently high=0Aalignment being requested, which is =
why zero-size allocations now get=0Aspecial cased).=0A=0AUse the new =
property to simplify allocation of the trap info array for=0APV guests on =
x86.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -369,13 +369,6 =
@@ int switch_compat(struct domain *d)=0A     return -ENOMEM;=0A }=0A =
=0A-static inline bool_t standalone_trap_ctxt(struct vcpu *v)=0A-{=0A-    =
BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=
=0A-    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)=
=0A-           > PAGE_SIZE;=0A-}=0A-=0A int vcpu_initialise(struct vcpu =
*v)=0A {=0A     struct domain *d =3D v->domain;=0A@@ -427,19 +420,15 @@ =
int vcpu_initialise(struct vcpu *v)=0A =0A     if ( !is_idle_domain(d) =
)=0A     {=0A-        if ( standalone_trap_ctxt(v) )=0A+        BUILD_BUG_O=
N(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >=0A+                    =
 PAGE_SIZE);=0A+        v->arch.pv_vcpu.trap_ctxt =3D xzalloc_array(struct =
trap_info,=0A+                                                  NR_VECTORS)=
;=0A+        if ( !v->arch.pv_vcpu.trap_ctxt )=0A         {=0A-            =
v->arch.pv_vcpu.trap_ctxt =3D alloc_xenheap_page();=0A-            if ( =
!v->arch.pv_vcpu.trap_ctxt )=0A-            {=0A-                rc =3D =
-ENOMEM;=0A-                goto done;=0A-            }=0A-            =
clear_page(v->arch.pv_vcpu.trap_ctxt);=0A+            rc =3D -ENOMEM;=0A+  =
          goto done;=0A         }=0A-        else=0A-            v->arch.pv=
_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -=0A-                NR_VECTORS =
* sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A =0A         /* PV guests by =
default have a 100Hz ticker. */=0A         v->periodic_period =3D =
MILLISECS(10);=0A@@ -467,8 +456,8 @@ int vcpu_initialise(struct vcpu =
*v)=0A     {=0A         vcpu_destroy_fpu(v);=0A =0A-        if ( !is_hvm_do=
main(d) && standalone_trap_ctxt(v) )=0A-            free_xenheap_page(v->ar=
ch.pv_vcpu.trap_ctxt);=0A+        if ( !is_hvm_domain(d) )=0A+            =
xfree(v->arch.pv_vcpu.trap_ctxt);=0A     }=0A =0A     return rc;=0A@@ =
-483,8 +472,8 @@ void vcpu_destroy(struct vcpu *v)=0A =0A     if ( =
is_hvm_vcpu(v) )=0A         hvm_vcpu_destroy(v);=0A-    else if ( =
standalone_trap_ctxt(v) )=0A-        free_xenheap_page(v->arch.pv_vcpu.trap=
_ctxt);=0A+    else=0A+        xfree(v->arch.pv_vcpu.trap_ctxt);=0A }=0A =
=0A int arch_domain_create(struct domain *d, unsigned int domcr_flags)=0A--=
- a/xen/common/xmalloc_tlsf.c=0A+++ b/xen/common/xmalloc_tlsf.c=0A@@ -26,6 =
+26,7 @@=0A #include <xen/config.h>=0A #include <xen/irq.h>=0A #include =
<xen/mm.h>=0A+#include <xen/pfn.h>=0A #include <asm/time.h>=0A =0A #define =
MAX_POOL_NAME_LEN       16=0A@@ -524,25 +525,30 @@ static void xmalloc_pool=
_put(void *p)=0A     free_xenheap_page(p);=0A }=0A =0A-static void =
*xmalloc_whole_pages(unsigned long size)=0A+static void *xmalloc_whole_page=
s(unsigned long size, unsigned long align)=0A {=0A-    struct bhdr *b;=0A- =
   unsigned int i, pageorder =3D get_order_from_bytes(size + BHDR_OVERHEAD)=
;=0A-    char *p;=0A+    unsigned int i, order =3D get_order_from_bytes(siz=
e);=0A+    void *res, *p;=0A+=0A+    if ( align > size )=0A+        =
get_order_from_bytes(align);=0A =0A-    b =3D alloc_xenheap_pages(pageorder=
, 0);=0A-    if ( b =3D=3D NULL )=0A+    res =3D alloc_xenheap_pages(order,=
 0);=0A+    if ( res =3D=3D NULL )=0A         return NULL;=0A =0A-    =
b->size =3D PAGE_ALIGN(size + BHDR_OVERHEAD);=0A-    for ( p =3D (char *)b =
+ b->size, i =3D 0; i < pageorder; ++i )=0A+    for ( p =3D res + =
PAGE_ALIGN(size), i =3D 0; i < order; ++i )=0A         if ( (unsigned =
long)p & (PAGE_SIZE << i) )=0A         {=0A             free_xenheap_pages(=
p, i);=0A             p +=3D PAGE_SIZE << i;=0A         }=0A =0A-    =
return (void *)b->ptr.buffer;=0A+    PFN_ORDER(virt_to_page(res)) =3D =
PFN_UP(size);=0A+    /* Check that there was no truncation: */=0A+    =
ASSERT(PFN_ORDER(virt_to_page(res)) =3D=3D PFN_UP(size));=0A+=0A+    =
return res;=0A }=0A =0A static void tlsf_init(void)=0A@@ -559,6 +565,11 @@ =
static void tlsf_init(void)=0A  * xmalloc()=0A  */=0A =0A+#ifndef =
ZERO_BLOCK_PTR=0A+/* Return value for zero-size allocation, distinguished =
from NULL. */=0A+#define ZERO_BLOCK_PTR ((void *)-1L)=0A+#endif=0A+=0A =
void *_xmalloc(unsigned long size, unsigned long align)=0A {=0A     void =
*p =3D NULL;=0A@@ -566,6 +577,9 @@ void *_xmalloc(unsigned long size, =
unsig=0A =0A     ASSERT(!in_irq());=0A =0A+    if ( !size )=0A+        =
return ZERO_BLOCK_PTR;=0A+=0A     ASSERT((align & (align - 1)) =3D=3D =
0);=0A     if ( align < MEM_ALIGN )=0A         align =3D MEM_ALIGN;=0A@@ =
-577,7 +591,7 @@ void *_xmalloc(unsigned long size, unsig=0A     if ( size =
< PAGE_SIZE )=0A         p =3D xmem_pool_alloc(size, xenpool);=0A     if ( =
p =3D=3D NULL )=0A-        p =3D xmalloc_whole_pages(size);=0A+        =
return xmalloc_whole_pages(size - align + MEM_ALIGN, align);=0A =0A     /* =
Add alignment padding. */=0A     if ( (pad =3D -(long)p & (align - 1)) =
!=3D 0 )=0A@@ -604,11 +618,28 @@ void xfree(void *p)=0A {=0A     struct =
bhdr *b;=0A =0A-    if ( p =3D=3D NULL )=0A+    if ( p =3D=3D NULL || p =
=3D=3D ZERO_BLOCK_PTR )=0A         return;=0A =0A     ASSERT(!in_irq());=0A=
 =0A+    if ( !((unsigned long)p & (PAGE_SIZE - 1)) )=0A+    {=0A+        =
unsigned long size =3D PFN_ORDER(virt_to_page(p));=0A+        unsigned int =
i, order =3D get_order_from_pages(size);=0A+=0A+        BUG_ON((unsigned =
long)p & ((PAGE_SIZE << order) - 1));=0A+        for ( i =3D 0; ; ++i =
)=0A+        {=0A+            if ( !(size & (1 << i)) )=0A+                =
continue;=0A+            size -=3D 1 << i;=0A+            free_xenheap_page=
s(p + (size << PAGE_SHIFT), i);=0A+            if ( i + 1 >=3D order )=0A+ =
               return;=0A+        }=0A+    }=0A+=0A     /* Strip alignment =
padding. */=0A     b =3D (struct bhdr *)((char *) p - BHDR_OVERHEAD);=0A   =
  if ( b->size & 1 )=0A@@ -618,21 +649,5 @@ void xfree(void *p)=0A         =
ASSERT(!(b->size & 1));=0A     }=0A =0A-    if ( b->size >=3D PAGE_SIZE =
)=0A-    {=0A-        unsigned int i, order =3D get_order_from_bytes(b->siz=
e);=0A-=0A-        BUG_ON((unsigned long)b & ((PAGE_SIZE << order) - =
1));=0A-        for ( i =3D 0; ; ++i )=0A-        {=0A-            if ( =
!(b->size & (PAGE_SIZE << i)) )=0A-                continue;=0A-           =
 b->size -=3D PAGE_SIZE << i;=0A-            free_xenheap_pages((void *)b =
+ b->size, i);=0A-            if ( i + 1 >=3D order )=0A-                =
break;=0A-        }=0A-    }=0A-    else=0A-        xmem_pool_free(p, =
xenpool);=0A+    xmem_pool_free(p, xenpool);=0A }=0A--- a/xen/include/asm-x=
86/config.h=0A+++ b/xen/include/asm-x86/config.h=0A@@ -91,6 +91,9 @@=0A /* =
Primary stack is restricted to 8kB by guard pages. */=0A #define PRIMARY_ST=
ACK_SIZE 8192=0A =0A+/* Return value for zero-size _xmalloc(), distinguishe=
d from NULL. */=0A+#define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)=0A=
+=0A #ifndef __ASSEMBLY__=0A extern unsigned long trampoline_phys;=0A =
#define bootsym_phys(sym)                                 \=0A
--=__Part44743A7D.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

--=__Part44743A7D.0__=--


From xen-devel-bounces@lists.xen.org Mon Feb 18 13:12:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13: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 1U7QVa-0004ZY-0r; Mon, 18 Feb 2013 13:11:50 +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 1U7QVY-0004ZS-Ot
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:11:48 +0000
Received: from [85.158.143.35:50879] by server-3.bemta-4.messagelabs.com id
	1D/F6-08920-49822215; Mon, 18 Feb 2013 13:11:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1361193105!16014322!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20934 invoked from network); 18 Feb 2013 13:11:47 -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;
	18 Feb 2013 13:11:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,687,1355097600"; 
   d="scan'208";a="7597763"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 13:11:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 08:11:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7QVU-0002FK-GN;
	Mon, 18 Feb 2013 13:11:44 +0000
Date: Mon, 18 Feb 2013 13:11:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360947870.31407.97.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181311200.4654@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
	<1360947870.31407.97.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 15 Feb 2013, Ian Campbell wrote:
> > > > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > > > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > > > +                        u32 dflt)
> > > >  {
> > > >      const struct fdt_property *prop;
> > > >  
> > > >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> > > >      if ( !prop || prop->len < sizeof(u32) )
> > > > -        return 0; /* default to 0 */
> > > > +        return dflt;
> > > >  
> > > >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> > > >  }
> > > 
> > > where did the vowels go? :)
> > 
> > Not sure. Unlike me ;-)
> 
> I remembered when I went to change it, default is a C keyword...

I would have gone for _default, but I am OK with this too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:12:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13: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 1U7QVa-0004ZY-0r; Mon, 18 Feb 2013 13:11:50 +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 1U7QVY-0004ZS-Ot
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:11:48 +0000
Received: from [85.158.143.35:50879] by server-3.bemta-4.messagelabs.com id
	1D/F6-08920-49822215; Mon, 18 Feb 2013 13:11:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1361193105!16014322!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20934 invoked from network); 18 Feb 2013 13:11:47 -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;
	18 Feb 2013 13:11:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,687,1355097600"; 
   d="scan'208";a="7597763"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 13:11:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 08:11:44 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7QVU-0002FK-GN;
	Mon, 18 Feb 2013 13:11:44 +0000
Date: Mon, 18 Feb 2013 13:11:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360947870.31407.97.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181311200.4654@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
	<1360947870.31407.97.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 15 Feb 2013, Ian Campbell wrote:
> > > > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > > > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > > > +                        u32 dflt)
> > > >  {
> > > >      const struct fdt_property *prop;
> > > >  
> > > >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> > > >      if ( !prop || prop->len < sizeof(u32) )
> > > > -        return 0; /* default to 0 */
> > > > +        return dflt;
> > > >  
> > > >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> > > >  }
> > > 
> > > where did the vowels go? :)
> > 
> > Not sure. Unlike me ;-)
> 
> I remembered when I went to change it, default is a C keyword...

I would have gone for _default, but I am OK with this too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:15:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:15: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 1U7QZH-0004mW-MM; Mon, 18 Feb 2013 13:15:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1U7QZG-0004mN-4S
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 13:15:38 +0000
Received: from [193.109.254.147:58465] by server-7.bemta-14.messagelabs.com id
	EE/06-13581-97922215; Mon, 18 Feb 2013 13:15:37 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361193326!8761449!1
X-Originating-IP: [209.85.212.46]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1766 invoked from network); 18 Feb 2013 13:15:28 -0000
Received: from mail-vb0-f46.google.com (HELO mail-vb0-f46.google.com)
	(209.85.212.46)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:15:28 -0000
Received: by mail-vb0-f46.google.com with SMTP id b13so3512663vby.5
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 05:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=fqsciieM0fXCWgme6YK+jHeuY6rtr1PHQmwh/zgoyRk=;
	b=EPLr3+983NWrjXKcFhuj7Q/aTtUaCZsayulOlVtrLojEFY2IAIBL4QkUnWO2Q0GnK1
	Q1qocoDVQ06vtvqbiyXFbL2xFD/pftvA+bpLCN5yv9Fbl/I/vydpV26eZQ0FOO9O3d2Q
	jPjeE8Dc16EmB9s2Y9UWp42tD07f5rMFgB5zfU8VYScLBG/HqUtp9PxP10xGmUZpdrtW
	rcToRCqhZMaGFUDe2risEo5e7710uvdK8tHipYvyJBzjJrcW6k4L1TCBLNDDO/I/r9hB
	vBiV0apeL1RoQ8nZOpAXaRMrFQGpbd9R8uCrb5Rc2Wb8Z8qDeaR9vZd8YhAVMZOdxx7k
	mHVw==
X-Received: by 10.220.142.71 with SMTP id p7mr15192590vcu.3.1361193311092;
	Mon, 18 Feb 2013 05:15:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.1.37 with HTTP; Mon, 18 Feb 2013 05:14:02 -0800 (PST)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
	<5122053F.9050400@rigollot.me>
	<6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Mon, 18 Feb 2013 14:14:02 +0100
X-Google-Sender-Auth: I5M1qTN5Ihsgm8pcPyBh53xj-Tc
Message-ID: <CAAxhNBD=n+eeVeNf2CV_34p-R5HuJGziUYEOOPxyKMD7+2RMAA@mail.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] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0417330918629829679=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0417330918629829679==
Content-Type: multipart/alternative; boundary=f46d0434bf0cc73fc704d5ff83ef

--f46d0434bf0cc73fc704d5ff83ef
Content-Type: text/plain; charset=ISO-8859-1

I have resoled this problem.
The kernel module xen_gntdev wasn't loaded. It was built as a module....

Now, the install of GPLPV has done successfuly and all is good in device
manager with VL drivers.

Thanks you !!!!!

I have a question, is it still necessary to put GPLPV option at windows
boot?
(LOADOPTIONS "GPLPV" or /GPLPV)

What is the objective of that?

Thanks

Erwan


2013/2/18 James Harper <james.harper@bendigoit.com.au>

>
> > I try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64
> > bits.
> > Look attachement for logs.
> >
>
> I think the problem might be related to this:
>
> xen be core: xen be core: can't open gnttab device
>
> but I don't know how to fix it. Maybe start a new thread with that as the
> subject?
>
> James
>

--f46d0434bf0cc73fc704d5ff83ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have resoled this problem.<div style>The kernel module=
=A0xen_gntdev wasn&#39;t loaded. It was built as a module....</div><div sty=
le><br></div><div style>Now, the install of GPLPV has done successfuly and =
all is good in device manager with VL drivers.</div>

<div style><br></div><div style>Thanks you !!!!!</div><div style><br></div>=
<div style>I have a question, is it still necessary to put GPLPV option at =
windows boot?</div><div style>(<span style=3D"background-color:rgb(249,249,=
249);color:rgb(0,0,0);line-height:1.3em">LOADOPTIONS &quot;GPLPV&quot; or /=
GPLPV)</span></div>

<div style><span style=3D"background-color:rgb(249,249,249);color:rgb(0,0,0=
);line-height:1.3em"><br></span></div><div style><span style=3D"background-=
color:rgb(249,249,249);color:rgb(0,0,0);line-height:1.3em">What is the obje=
ctive of that?</span></div>

<div style><span style=3D"background-color:rgb(249,249,249);color:rgb(0,0,0=
);line-height:1.3em"><br></span></div><div style><span style=3D"background-=
color:rgb(249,249,249);color:rgb(0,0,0);line-height:1.3em">Thanks</span></d=
iv>

<div style><span style=3D"background-color:rgb(249,249,249);color:rgb(0,0,0=
);line-height:1.3em"><br></span></div><div style><span style=3D"background-=
color:rgb(249,249,249);color:rgb(0,0,0);line-height:1.3em">Erwan</span></di=
v>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/2/=
18 James Harper <span dir=3D"ltr">&lt;<a href=3D"mailto:james.harper@bendig=
oit.com.au" target=3D"_blank">james.harper@bendigoit.com.au</a>&gt;</span><=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">

<br>
&gt; I try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64=
<br>
&gt; bits.<br>
&gt; Look attachement for logs.<br>
&gt;<br>
<br>
I think the problem might be related to this:<br>
<br>
xen be core: xen be core: can&#39;t open gnttab device<br>
<br>
but I don&#39;t know how to fix it. Maybe start a new thread with that as t=
he subject?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
James<br>
</font></span></blockquote></div><br></div>

--f46d0434bf0cc73fc704d5ff83ef--


--===============0417330918629829679==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0417330918629829679==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 13:15:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:15: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 1U7QZH-0004mW-MM; Mon, 18 Feb 2013 13:15:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1U7QZG-0004mN-4S
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 13:15:38 +0000
Received: from [193.109.254.147:58465] by server-7.bemta-14.messagelabs.com id
	EE/06-13581-97922215; Mon, 18 Feb 2013 13:15:37 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361193326!8761449!1
X-Originating-IP: [209.85.212.46]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1766 invoked from network); 18 Feb 2013 13:15:28 -0000
Received: from mail-vb0-f46.google.com (HELO mail-vb0-f46.google.com)
	(209.85.212.46)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:15:28 -0000
Received: by mail-vb0-f46.google.com with SMTP id b13so3512663vby.5
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 05:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=fqsciieM0fXCWgme6YK+jHeuY6rtr1PHQmwh/zgoyRk=;
	b=EPLr3+983NWrjXKcFhuj7Q/aTtUaCZsayulOlVtrLojEFY2IAIBL4QkUnWO2Q0GnK1
	Q1qocoDVQ06vtvqbiyXFbL2xFD/pftvA+bpLCN5yv9Fbl/I/vydpV26eZQ0FOO9O3d2Q
	jPjeE8Dc16EmB9s2Y9UWp42tD07f5rMFgB5zfU8VYScLBG/HqUtp9PxP10xGmUZpdrtW
	rcToRCqhZMaGFUDe2risEo5e7710uvdK8tHipYvyJBzjJrcW6k4L1TCBLNDDO/I/r9hB
	vBiV0apeL1RoQ8nZOpAXaRMrFQGpbd9R8uCrb5Rc2Wb8Z8qDeaR9vZd8YhAVMZOdxx7k
	mHVw==
X-Received: by 10.220.142.71 with SMTP id p7mr15192590vcu.3.1361193311092;
	Mon, 18 Feb 2013 05:15:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.1.37 with HTTP; Mon, 18 Feb 2013 05:14:02 -0800 (PST)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
	<5122053F.9050400@rigollot.me>
	<6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Mon, 18 Feb 2013 14:14:02 +0100
X-Google-Sender-Auth: I5M1qTN5Ihsgm8pcPyBh53xj-Tc
Message-ID: <CAAxhNBD=n+eeVeNf2CV_34p-R5HuJGziUYEOOPxyKMD7+2RMAA@mail.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] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0417330918629829679=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0417330918629829679==
Content-Type: multipart/alternative; boundary=f46d0434bf0cc73fc704d5ff83ef

--f46d0434bf0cc73fc704d5ff83ef
Content-Type: text/plain; charset=ISO-8859-1

I have resoled this problem.
The kernel module xen_gntdev wasn't loaded. It was built as a module....

Now, the install of GPLPV has done successfuly and all is good in device
manager with VL drivers.

Thanks you !!!!!

I have a question, is it still necessary to put GPLPV option at windows
boot?
(LOADOPTIONS "GPLPV" or /GPLPV)

What is the objective of that?

Thanks

Erwan


2013/2/18 James Harper <james.harper@bendigoit.com.au>

>
> > I try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64
> > bits.
> > Look attachement for logs.
> >
>
> I think the problem might be related to this:
>
> xen be core: xen be core: can't open gnttab device
>
> but I don't know how to fix it. Maybe start a new thread with that as the
> subject?
>
> James
>

--f46d0434bf0cc73fc704d5ff83ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have resoled this problem.<div style>The kernel module=
=A0xen_gntdev wasn&#39;t loaded. It was built as a module....</div><div sty=
le><br></div><div style>Now, the install of GPLPV has done successfuly and =
all is good in device manager with VL drivers.</div>

<div style><br></div><div style>Thanks you !!!!!</div><div style><br></div>=
<div style>I have a question, is it still necessary to put GPLPV option at =
windows boot?</div><div style>(<span style=3D"background-color:rgb(249,249,=
249);color:rgb(0,0,0);line-height:1.3em">LOADOPTIONS &quot;GPLPV&quot; or /=
GPLPV)</span></div>

<div style><span style=3D"background-color:rgb(249,249,249);color:rgb(0,0,0=
);line-height:1.3em"><br></span></div><div style><span style=3D"background-=
color:rgb(249,249,249);color:rgb(0,0,0);line-height:1.3em">What is the obje=
ctive of that?</span></div>

<div style><span style=3D"background-color:rgb(249,249,249);color:rgb(0,0,0=
);line-height:1.3em"><br></span></div><div style><span style=3D"background-=
color:rgb(249,249,249);color:rgb(0,0,0);line-height:1.3em">Thanks</span></d=
iv>

<div style><span style=3D"background-color:rgb(249,249,249);color:rgb(0,0,0=
);line-height:1.3em"><br></span></div><div style><span style=3D"background-=
color:rgb(249,249,249);color:rgb(0,0,0);line-height:1.3em">Erwan</span></di=
v>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/2/=
18 James Harper <span dir=3D"ltr">&lt;<a href=3D"mailto:james.harper@bendig=
oit.com.au" target=3D"_blank">james.harper@bendigoit.com.au</a>&gt;</span><=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">

<br>
&gt; I try gplpv_Vista2008x64_signed_0.11.0.356_debug.msi on a windows 7 64=
<br>
&gt; bits.<br>
&gt; Look attachement for logs.<br>
&gt;<br>
<br>
I think the problem might be related to this:<br>
<br>
xen be core: xen be core: can&#39;t open gnttab device<br>
<br>
but I don&#39;t know how to fix it. Maybe start a new thread with that as t=
he subject?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
James<br>
</font></span></blockquote></div><br></div>

--f46d0434bf0cc73fc704d5ff83ef--


--===============0417330918629829679==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0417330918629829679==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 13:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:19: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 1U7Qcu-0004yn-Co; Mon, 18 Feb 2013 13:19:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7Qcs-0004yf-UM
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:19:23 +0000
Received: from [85.158.139.83:31341] by server-11.bemta-5.messagelabs.com id
	64/08-19159-A5A22215; Mon, 18 Feb 2013 13:19:22 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361193561!20533451!1
X-Originating-IP: [209.85.214.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9009 invoked from network); 18 Feb 2013 13:19:21 -0000
Received: from unknown (HELO mail-bk0-f50.google.com) (209.85.214.50)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:19:21 -0000
Received: by mail-bk0-f50.google.com with SMTP id jg9so2518561bkc.9
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 05:17:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=mzMzwhhekrc6z8kDNO9Kbkl5Y92HqiVNbCETABOn9MA=;
	b=YcYRCkiKeY4/50BeFy6YlNp7FibBGCf+R4Z3qS6+NPOEGAl6XM1yeQkeePa/e21fdk
	3CoqvEF4gvpUnOOpwIxlD/I6ZmuWfEAcehFl49GNYojDl7UXzc9jJdz1liDSWejg1IOa
	j9oPbucJdcD7j/VCRan6ncJTbk0s4ydsDNMr1+rE3d9LCXIPMY24GoHLaQpQRlGapYQV
	Yoqdc1DZvwqvXR1GVZuASf7NXb7Uj2f2QqFk0IE8ECo3kIaJ2qBssOjRAuVt57RD7oeR
	umbmW0nrDnFu35US8XDE/8FPaWlvVSK/2PQOtzGJsEmTmtYSCf0U6L1NKbegeCCgsjn1
	MhUQ==
MIME-Version: 1.0
X-Received: by 10.205.119.19 with SMTP id fs19mr4670593bkc.105.1361193442695; 
	Mon, 18 Feb 2013 05:17:22 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 05:17:22 -0800 (PST)
In-Reply-To: <20130218113541.GA77310@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
Date: Mon, 18 Feb 2013 14:17:22 +0100
Message-ID: <CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, andrew.cooper3@citrix.com
X-Gm-Message-State: ALoCoQnqoOqJyl0islICh4wqe6ydnucUbODi5MnBtEdLDNTdOq9s1biagJ/ObDXfnD+lPMSyvUNU
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Thanks for the feedback, let me try to answer the various questions.


> Did you make any changes to Xen before you built it, or were you just
> building your own to get 4.2?

It's based on the official .tar.bz2 from the website, and built using
the debian/ from the 4.2.0 debian package. There are some patches
applied in the debian build but I don't see any that patch the actual
code, just small adaptation to the build and install system to follow
the debian conventions.

So it should be functionally equivalent to an official 4.2.1 . I can
put the compiled binary online if needed.


> Please can you share the domain configuration. Are you running PV
> drivers (esp. ballooning) within it?

There is no xen driver running in there.

Here's the config which is based on the example hvm config:

---------
builder = "hvm"
name   = "wxp-00"
vcpus = 2
memory = 1536
maxmem = 2048
viridian = 1
vif = [ 'type=ioemu,bridge=br0,mac=00:16:3e:35:ad:12' ]
disk = [ '/dev/xen-disks/wxp-00-test,raw,xvda,w', ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
vnc=1
vncunused=0
vnclisten = '0.0.0.0'
vncdisplay=0
vncconsole=1
vncpasswd='xxx'
--------


> Do you by any chance have the xen-syms file from when you built Xen?
> That would let us see exactly what's happened.

You can get it at http://ge.tt/7DBEjmY/v/0


> In the meantime, perhaps you could try the attached (untested) patch.
> If my guess is right, it ought to stop the crashes but you might find
> the VM's performance suffers.

I'll try it and report here.


> From the stack trace, I assume that the guest is running in shadow mode
> ?  Can you confirm this?

Sorry, no idea what this means. How can I check / test ?  I didn't
configure anything relative to "shadow mode" at least.


Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:19:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:19: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 1U7Qcu-0004yn-Co; Mon, 18 Feb 2013 13:19:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7Qcs-0004yf-UM
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:19:23 +0000
Received: from [85.158.139.83:31341] by server-11.bemta-5.messagelabs.com id
	64/08-19159-A5A22215; Mon, 18 Feb 2013 13:19:22 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361193561!20533451!1
X-Originating-IP: [209.85.214.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9009 invoked from network); 18 Feb 2013 13:19:21 -0000
Received: from unknown (HELO mail-bk0-f50.google.com) (209.85.214.50)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:19:21 -0000
Received: by mail-bk0-f50.google.com with SMTP id jg9so2518561bkc.9
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 05:17:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=mzMzwhhekrc6z8kDNO9Kbkl5Y92HqiVNbCETABOn9MA=;
	b=YcYRCkiKeY4/50BeFy6YlNp7FibBGCf+R4Z3qS6+NPOEGAl6XM1yeQkeePa/e21fdk
	3CoqvEF4gvpUnOOpwIxlD/I6ZmuWfEAcehFl49GNYojDl7UXzc9jJdz1liDSWejg1IOa
	j9oPbucJdcD7j/VCRan6ncJTbk0s4ydsDNMr1+rE3d9LCXIPMY24GoHLaQpQRlGapYQV
	Yoqdc1DZvwqvXR1GVZuASf7NXb7Uj2f2QqFk0IE8ECo3kIaJ2qBssOjRAuVt57RD7oeR
	umbmW0nrDnFu35US8XDE/8FPaWlvVSK/2PQOtzGJsEmTmtYSCf0U6L1NKbegeCCgsjn1
	MhUQ==
MIME-Version: 1.0
X-Received: by 10.205.119.19 with SMTP id fs19mr4670593bkc.105.1361193442695; 
	Mon, 18 Feb 2013 05:17:22 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 05:17:22 -0800 (PST)
In-Reply-To: <20130218113541.GA77310@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
Date: Mon, 18 Feb 2013 14:17:22 +0100
Message-ID: <CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, andrew.cooper3@citrix.com
X-Gm-Message-State: ALoCoQnqoOqJyl0islICh4wqe6ydnucUbODi5MnBtEdLDNTdOq9s1biagJ/ObDXfnD+lPMSyvUNU
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Thanks for the feedback, let me try to answer the various questions.


> Did you make any changes to Xen before you built it, or were you just
> building your own to get 4.2?

It's based on the official .tar.bz2 from the website, and built using
the debian/ from the 4.2.0 debian package. There are some patches
applied in the debian build but I don't see any that patch the actual
code, just small adaptation to the build and install system to follow
the debian conventions.

So it should be functionally equivalent to an official 4.2.1 . I can
put the compiled binary online if needed.


> Please can you share the domain configuration. Are you running PV
> drivers (esp. ballooning) within it?

There is no xen driver running in there.

Here's the config which is based on the example hvm config:

---------
builder = "hvm"
name   = "wxp-00"
vcpus = 2
memory = 1536
maxmem = 2048
viridian = 1
vif = [ 'type=ioemu,bridge=br0,mac=00:16:3e:35:ad:12' ]
disk = [ '/dev/xen-disks/wxp-00-test,raw,xvda,w', ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
vnc=1
vncunused=0
vnclisten = '0.0.0.0'
vncdisplay=0
vncconsole=1
vncpasswd='xxx'
--------


> Do you by any chance have the xen-syms file from when you built Xen?
> That would let us see exactly what's happened.

You can get it at http://ge.tt/7DBEjmY/v/0


> In the meantime, perhaps you could try the attached (untested) patch.
> If my guess is right, it ought to stop the crashes but you might find
> the VM's performance suffers.

I'll try it and report here.


> From the stack trace, I assume that the guest is running in shadow mode
> ?  Can you confirm this?

Sorry, no idea what this means. How can I check / test ?  I didn't
configure anything relative to "shadow mode" at least.


Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:24:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13: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 1U7Qho-0005BF-7F; Mon, 18 Feb 2013 13:24:28 +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 1U7Qhm-0005B8-RS
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 13:24:26 +0000
Received: from [85.158.137.99:52828] by server-4.bemta-3.messagelabs.com id
	9C/A6-17521-58B22215; Mon, 18 Feb 2013 13:24:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361193857!12565344!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9676 invoked from network); 18 Feb 2013 13:24:17 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-7.tower-217.messagelabs.com with SMTP;
	18 Feb 2013 13:24:17 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id CA9C3646CA4;
	Mon, 18 Feb 2013 14:24:16 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 18 Feb 2013 14:24:10 +0100
Message-Id: <1361193850-5028-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] tools/firmware: Fix ovmf build with gcc version
	different from 4.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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/firmware/ovmf-makefile |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile
index c3cd466..72fe99d 100644
--- a/tools/firmware/ovmf-makefile
+++ b/tools/firmware/ovmf-makefile
@@ -1,6 +1,8 @@
 # OVMF building system is not ready yet to run in parallel.
 # Force it to be serial in order to exploit parallelism for neighbors.
 
+GCCVERSION = $(shell gcc --version | grep -om1 '[0-9]\+[.][0-9]\+' | tr -d . | tail -n1)
+
 .NOTPARALLEL:
 MAKEFLAGS  += -j1
 
@@ -10,7 +12,7 @@ all: ovmf.bin
 .PHONY: ovmf.bin
 ovmf.bin:
 	OvmfPkg/build.sh -a X64
-	cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
+	cp Build/OvmfX64/DEBUG_GCC$(GCCVERSION)/FV/OVMF.fd ovmf.bin
 
 .PHONY: clean
 clean:
-- 
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 Mon Feb 18 13:24:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13: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 1U7Qho-0005BF-7F; Mon, 18 Feb 2013 13:24:28 +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 1U7Qhm-0005B8-RS
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 13:24:26 +0000
Received: from [85.158.137.99:52828] by server-4.bemta-3.messagelabs.com id
	9C/A6-17521-58B22215; Mon, 18 Feb 2013 13:24:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361193857!12565344!1
X-Originating-IP: [62.94.10.166]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,sa_preprocessor: 
	QmFkIElQOiA2Mi45NC4xMC4xNjYgPT4gNDI4NTk=\n,ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9676 invoked from network); 18 Feb 2013 13:24:17 -0000
Received: from mp1-smtp-6.eutelia.it (HELO smtp.eutelia.it) (62.94.10.166)
	by server-7.tower-217.messagelabs.com with SMTP;
	18 Feb 2013 13:24:17 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id CA9C3646CA4;
	Mon, 18 Feb 2013 14:24:16 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Mon, 18 Feb 2013 14:24:10 +0100
Message-Id: <1361193850-5028-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] tools/firmware: Fix ovmf build with gcc version
	different from 4.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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/firmware/ovmf-makefile |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile
index c3cd466..72fe99d 100644
--- a/tools/firmware/ovmf-makefile
+++ b/tools/firmware/ovmf-makefile
@@ -1,6 +1,8 @@
 # OVMF building system is not ready yet to run in parallel.
 # Force it to be serial in order to exploit parallelism for neighbors.
 
+GCCVERSION = $(shell gcc --version | grep -om1 '[0-9]\+[.][0-9]\+' | tr -d . | tail -n1)
+
 .NOTPARALLEL:
 MAKEFLAGS  += -j1
 
@@ -10,7 +12,7 @@ all: ovmf.bin
 .PHONY: ovmf.bin
 ovmf.bin:
 	OvmfPkg/build.sh -a X64
-	cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
+	cp Build/OvmfX64/DEBUG_GCC$(GCCVERSION)/FV/OVMF.fd ovmf.bin
 
 .PHONY: clean
 clean:
-- 
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 Mon Feb 18 13:26:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:26: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 1U7QjJ-0005GV-N4; Mon, 18 Feb 2013 13:26: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 1U7QjH-0005GM-Qz
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:26:00 +0000
Received: from [85.158.143.35:15605] by server-3.bemta-4.messagelabs.com id
	E2/17-08920-7EB22215; Mon, 18 Feb 2013 13:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1361193957!13512218!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18612 invoked from network); 18 Feb 2013 13:25:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,687,1355097600"; 
   d="scan'208";a="1570986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 13:25: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.297.1;
	Mon, 18 Feb 2013 13:25:57 +0000
Message-ID: <1361193955.31407.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 13:25:55 +0000
In-Reply-To: <alpine.DEB.2.02.1302181311200.4654@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
	<1360947870.31407.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181311200.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 13:11 +0000, Stefano Stabellini wrote:
> On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > > > > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > > > > +                        u32 dflt)
> > > > >  {
> > > > >      const struct fdt_property *prop;
> > > > >  
> > > > >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> > > > >      if ( !prop || prop->len < sizeof(u32) )
> > > > > -        return 0; /* default to 0 */
> > > > > +        return dflt;
> > > > >  
> > > > >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> > > > >  }
> > > > 
> > > > where did the vowels go? :)
> > > 
> > > Not sure. Unlike me ;-)
> > 
> > I remembered when I went to change it, default is a C keyword...
> 
> I would have gone for _default, but I am OK with this too.

Technically _default is reserved for the implementation (compiler or
system libraries, I forget which).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:26:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:26: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 1U7QjJ-0005GV-N4; Mon, 18 Feb 2013 13:26: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 1U7QjH-0005GM-Qz
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:26:00 +0000
Received: from [85.158.143.35:15605] by server-3.bemta-4.messagelabs.com id
	E2/17-08920-7EB22215; Mon, 18 Feb 2013 13:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1361193957!13512218!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18612 invoked from network); 18 Feb 2013 13:25:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,687,1355097600"; 
   d="scan'208";a="1570986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 13:25: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.297.1;
	Mon, 18 Feb 2013 13:25:57 +0000
Message-ID: <1361193955.31407.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 13:25:55 +0000
In-Reply-To: <alpine.DEB.2.02.1302181311200.4654@kaball.uk.xensource.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302151229060.8231@kaball.uk.xensource.com>
	<1360934328.31407.41.camel@zakaz.uk.xensource.com>
	<1360947870.31407.97.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181311200.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] dtb: correct handling of #address-cells
 and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 13:11 +0000, Stefano Stabellini wrote:
> On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > > -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> > > > > +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> > > > > +                        u32 dflt)
> > > > >  {
> > > > >      const struct fdt_property *prop;
> > > > >  
> > > > >      prop = fdt_get_property(fdt, node, prop_name, NULL);
> > > > >      if ( !prop || prop->len < sizeof(u32) )
> > > > > -        return 0; /* default to 0 */
> > > > > +        return dflt;
> > > > >  
> > > > >      return fdt32_to_cpu(*(uint32_t*)prop->data);
> > > > >  }
> > > > 
> > > > where did the vowels go? :)
> > > 
> > > Not sure. Unlike me ;-)
> > 
> > I remembered when I went to change it, default is a C keyword...
> 
> I would have gone for _default, but I am OK with this too.

Technically _default is reserved for the implementation (compiler or
system libraries, I forget which).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:27:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13: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 1U7QkW-0005Lv-TP; Mon, 18 Feb 2013 13:27:16 +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 1U7QkV-0005Ll-En
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:27:15 +0000
Received: from [85.158.143.99:10558] by server-1.bemta-4.messagelabs.com id
	AC/D4-08839-23C22215; Mon, 18 Feb 2013 13:27:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361194033!22713192!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 18 Feb 2013 13:27:13 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:27:13 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so2700803wgb.4
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 05:27:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MNIzsogWdsbMVzBB01vuMpKuHA8g6XwnLjQhzJSWSkU=;
	b=imWG6BqdXzNcfmYbMubu3Y0D0IdPCYroTB8ItI4Idio8f5wFD3NOUlocqxoVfNVcib
	wj1PsSpdSc9TlfkoQ/Q/XPlocXtvH3JylQEiN01U3E/kJHLlwqe9PjEg+qNeVbT6kEwX
	V8NysUCm81sktBXOqedRxW9ciwgO7i8pT7Fsu/MahMXcC6eabJ3JH5Gflq97NBguY6rY
	ZiAd26UZp4elAVA+ZIdepVfqpJnJHHCutmAMzj9rDUS2cNtODCUtYpohfJqPy3P33udy
	hG3yeK7lJEWgKCS0EYdzQg4FPgRWrGEeALj6QyGyT+mKVGmxzFXIxFhOW04IQjK63Aii
	/t1g==
X-Received: by 10.194.109.102 with SMTP id hr6mr19012656wjb.24.1361194029557; 
	Mon, 18 Feb 2013 05:27:09 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ex15sm19918291wid.5.2013.02.18.05.27.06
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 05:27:08 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 18 Feb 2013 13:26:56 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD47DCA0.5BEA7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xmalloc: make close-to-PAGE_SIZE allocations
	more efficient
Thread-Index: Ac4N258vD9DDVxlbMUq7xaN+CTjpDQ==
In-Reply-To: <5122307D02000078000BF20C@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xmalloc: make close-to-PAGE_SIZE
 allocations more efficient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 12:45, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than bumping their sizes to slightly above (a multiple of)
> PAGE_SIZE (in order to store tracking information), thus requiring
> a non-order-0 allocation even when no more than a page is being
> requested, return the result of alloc_xenheap_pages() directly, and use
> the struct page_info field underlying PFN_ORDER() to store the actual
> size (needed for freeing the memory).
> 
> This leverages the fact that sub-allocation of memory obtained from the
> page allocator can only ever result in non-page-aligned memory chunks
> (with the exception of zero size allocations with sufficiently high
> alignment being requested, which is why zero-size allocations now get
> special cased).
> 
> Use the new property to simplify allocation of the trap info array for
> PV guests on x86.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -369,13 +369,6 @@ int switch_compat(struct domain *d)
>      return -ENOMEM;
>  }
>  
> -static inline bool_t standalone_trap_ctxt(struct vcpu *v)
> -{
> -    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
> PAGE_SIZE);
> -    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
> -           > PAGE_SIZE;
> -}
> -
>  int vcpu_initialise(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> @@ -427,19 +420,15 @@ int vcpu_initialise(struct vcpu *v)
>  
>      if ( !is_idle_domain(d) )
>      {
> -        if ( standalone_trap_ctxt(v) )
> +        BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
> +                     PAGE_SIZE);
> +        v->arch.pv_vcpu.trap_ctxt = xzalloc_array(struct trap_info,
> +                                                  NR_VECTORS);
> +        if ( !v->arch.pv_vcpu.trap_ctxt )
>          {
> -            v->arch.pv_vcpu.trap_ctxt = alloc_xenheap_page();
> -            if ( !v->arch.pv_vcpu.trap_ctxt )
> -            {
> -                rc = -ENOMEM;
> -                goto done;
> -            }
> -            clear_page(v->arch.pv_vcpu.trap_ctxt);
> +            rc = -ENOMEM;
> +            goto done;
>          }
> -        else
> -            v->arch.pv_vcpu.trap_ctxt = (void *)v + PAGE_SIZE -
> -                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
>  
>          /* PV guests by default have a 100Hz ticker. */
>          v->periodic_period = MILLISECS(10);
> @@ -467,8 +456,8 @@ int vcpu_initialise(struct vcpu *v)
>      {
>          vcpu_destroy_fpu(v);
>  
> -        if ( !is_hvm_domain(d) && standalone_trap_ctxt(v) )
> -            free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
> +        if ( !is_hvm_domain(d) )
> +            xfree(v->arch.pv_vcpu.trap_ctxt);
>      }
>  
>      return rc;
> @@ -483,8 +472,8 @@ void vcpu_destroy(struct vcpu *v)
>  
>      if ( is_hvm_vcpu(v) )
>          hvm_vcpu_destroy(v);
> -    else if ( standalone_trap_ctxt(v) )
> -        free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
> +    else
> +        xfree(v->arch.pv_vcpu.trap_ctxt);
>  }
>  
>  int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -26,6 +26,7 @@
>  #include <xen/config.h>
>  #include <xen/irq.h>
>  #include <xen/mm.h>
> +#include <xen/pfn.h>
>  #include <asm/time.h>
>  
>  #define MAX_POOL_NAME_LEN       16
> @@ -524,25 +525,30 @@ static void xmalloc_pool_put(void *p)
>      free_xenheap_page(p);
>  }
>  
> -static void *xmalloc_whole_pages(unsigned long size)
> +static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
>  {
> -    struct bhdr *b;
> -    unsigned int i, pageorder = get_order_from_bytes(size + BHDR_OVERHEAD);
> -    char *p;
> +    unsigned int i, order = get_order_from_bytes(size);
> +    void *res, *p;
> +
> +    if ( align > size )
> +        get_order_from_bytes(align);
>  
> -    b = alloc_xenheap_pages(pageorder, 0);
> -    if ( b == NULL )
> +    res = alloc_xenheap_pages(order, 0);
> +    if ( res == NULL )
>          return NULL;
>  
> -    b->size = PAGE_ALIGN(size + BHDR_OVERHEAD);
> -    for ( p = (char *)b + b->size, i = 0; i < pageorder; ++i )
> +    for ( p = res + PAGE_ALIGN(size), i = 0; i < order; ++i )
>          if ( (unsigned long)p & (PAGE_SIZE << i) )
>          {
>              free_xenheap_pages(p, i);
>              p += PAGE_SIZE << i;
>          }
>  
> -    return (void *)b->ptr.buffer;
> +    PFN_ORDER(virt_to_page(res)) = PFN_UP(size);
> +    /* Check that there was no truncation: */
> +    ASSERT(PFN_ORDER(virt_to_page(res)) == PFN_UP(size));
> +
> +    return res;
>  }
>  
>  static void tlsf_init(void)
> @@ -559,6 +565,11 @@ static void tlsf_init(void)
>   * xmalloc()
>   */
>  
> +#ifndef ZERO_BLOCK_PTR
> +/* Return value for zero-size allocation, distinguished from NULL. */
> +#define ZERO_BLOCK_PTR ((void *)-1L)
> +#endif
> +
>  void *_xmalloc(unsigned long size, unsigned long align)
>  {
>      void *p = NULL;
> @@ -566,6 +577,9 @@ void *_xmalloc(unsigned long size, unsig
>  
>      ASSERT(!in_irq());
>  
> +    if ( !size )
> +        return ZERO_BLOCK_PTR;
> +
>      ASSERT((align & (align - 1)) == 0);
>      if ( align < MEM_ALIGN )
>          align = MEM_ALIGN;
> @@ -577,7 +591,7 @@ void *_xmalloc(unsigned long size, unsig
>      if ( size < PAGE_SIZE )
>          p = xmem_pool_alloc(size, xenpool);
>      if ( p == NULL )
> -        p = xmalloc_whole_pages(size);
> +        return xmalloc_whole_pages(size - align + MEM_ALIGN, align);
>  
>      /* Add alignment padding. */
>      if ( (pad = -(long)p & (align - 1)) != 0 )
> @@ -604,11 +618,28 @@ void xfree(void *p)
>  {
>      struct bhdr *b;
>  
> -    if ( p == NULL )
> +    if ( p == NULL || p == ZERO_BLOCK_PTR )
>          return;
>  
>      ASSERT(!in_irq());
>  
> +    if ( !((unsigned long)p & (PAGE_SIZE - 1)) )
> +    {
> +        unsigned long size = PFN_ORDER(virt_to_page(p));
> +        unsigned int i, order = get_order_from_pages(size);
> +
> +        BUG_ON((unsigned long)p & ((PAGE_SIZE << order) - 1));
> +        for ( i = 0; ; ++i )
> +        {
> +            if ( !(size & (1 << i)) )
> +                continue;
> +            size -= 1 << i;
> +            free_xenheap_pages(p + (size << PAGE_SHIFT), i);
> +            if ( i + 1 >= order )
> +                return;
> +        }
> +    }
> +
>      /* Strip alignment padding. */
>      b = (struct bhdr *)((char *) p - BHDR_OVERHEAD);
>      if ( b->size & 1 )
> @@ -618,21 +649,5 @@ void xfree(void *p)
>          ASSERT(!(b->size & 1));
>      }
>  
> -    if ( b->size >= PAGE_SIZE )
> -    {
> -        unsigned int i, order = get_order_from_bytes(b->size);
> -
> -        BUG_ON((unsigned long)b & ((PAGE_SIZE << order) - 1));
> -        for ( i = 0; ; ++i )
> -        {
> -            if ( !(b->size & (PAGE_SIZE << i)) )
> -                continue;
> -            b->size -= PAGE_SIZE << i;
> -            free_xenheap_pages((void *)b + b->size, i);
> -            if ( i + 1 >= order )
> -                break;
> -        }
> -    }
> -    else
> -        xmem_pool_free(p, xenpool);
> +    xmem_pool_free(p, xenpool);
>  }
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -91,6 +91,9 @@
>  /* Primary stack is restricted to 8kB by guard pages. */
>  #define PRIMARY_STACK_SIZE 8192
>  
> +/* Return value for zero-size _xmalloc(), distinguished from NULL. */
> +#define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
> +
>  #ifndef __ASSEMBLY__
>  extern unsigned long trampoline_phys;
>  #define bootsym_phys(sym)                                 \
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 13:27:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13: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 1U7QkW-0005Lv-TP; Mon, 18 Feb 2013 13:27:16 +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 1U7QkV-0005Ll-En
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:27:15 +0000
Received: from [85.158.143.99:10558] by server-1.bemta-4.messagelabs.com id
	AC/D4-08839-23C22215; Mon, 18 Feb 2013 13:27:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361194033!22713192!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 18 Feb 2013 13:27:13 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:27:13 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so2700803wgb.4
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 05:27:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MNIzsogWdsbMVzBB01vuMpKuHA8g6XwnLjQhzJSWSkU=;
	b=imWG6BqdXzNcfmYbMubu3Y0D0IdPCYroTB8ItI4Idio8f5wFD3NOUlocqxoVfNVcib
	wj1PsSpdSc9TlfkoQ/Q/XPlocXtvH3JylQEiN01U3E/kJHLlwqe9PjEg+qNeVbT6kEwX
	V8NysUCm81sktBXOqedRxW9ciwgO7i8pT7Fsu/MahMXcC6eabJ3JH5Gflq97NBguY6rY
	ZiAd26UZp4elAVA+ZIdepVfqpJnJHHCutmAMzj9rDUS2cNtODCUtYpohfJqPy3P33udy
	hG3yeK7lJEWgKCS0EYdzQg4FPgRWrGEeALj6QyGyT+mKVGmxzFXIxFhOW04IQjK63Aii
	/t1g==
X-Received: by 10.194.109.102 with SMTP id hr6mr19012656wjb.24.1361194029557; 
	Mon, 18 Feb 2013 05:27:09 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ex15sm19918291wid.5.2013.02.18.05.27.06
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 05:27:08 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 18 Feb 2013 13:26:56 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD47DCA0.5BEA7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xmalloc: make close-to-PAGE_SIZE allocations
	more efficient
Thread-Index: Ac4N258vD9DDVxlbMUq7xaN+CTjpDQ==
In-Reply-To: <5122307D02000078000BF20C@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xmalloc: make close-to-PAGE_SIZE
 allocations more efficient
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 12:45, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than bumping their sizes to slightly above (a multiple of)
> PAGE_SIZE (in order to store tracking information), thus requiring
> a non-order-0 allocation even when no more than a page is being
> requested, return the result of alloc_xenheap_pages() directly, and use
> the struct page_info field underlying PFN_ORDER() to store the actual
> size (needed for freeing the memory).
> 
> This leverages the fact that sub-allocation of memory obtained from the
> page allocator can only ever result in non-page-aligned memory chunks
> (with the exception of zero size allocations with sufficiently high
> alignment being requested, which is why zero-size allocations now get
> special cased).
> 
> Use the new property to simplify allocation of the trap info array for
> PV guests on x86.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -369,13 +369,6 @@ int switch_compat(struct domain *d)
>      return -ENOMEM;
>  }
>  
> -static inline bool_t standalone_trap_ctxt(struct vcpu *v)
> -{
> -    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
> PAGE_SIZE);
> -    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
> -           > PAGE_SIZE;
> -}
> -
>  int vcpu_initialise(struct vcpu *v)
>  {
>      struct domain *d = v->domain;
> @@ -427,19 +420,15 @@ int vcpu_initialise(struct vcpu *v)
>  
>      if ( !is_idle_domain(d) )
>      {
> -        if ( standalone_trap_ctxt(v) )
> +        BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
> +                     PAGE_SIZE);
> +        v->arch.pv_vcpu.trap_ctxt = xzalloc_array(struct trap_info,
> +                                                  NR_VECTORS);
> +        if ( !v->arch.pv_vcpu.trap_ctxt )
>          {
> -            v->arch.pv_vcpu.trap_ctxt = alloc_xenheap_page();
> -            if ( !v->arch.pv_vcpu.trap_ctxt )
> -            {
> -                rc = -ENOMEM;
> -                goto done;
> -            }
> -            clear_page(v->arch.pv_vcpu.trap_ctxt);
> +            rc = -ENOMEM;
> +            goto done;
>          }
> -        else
> -            v->arch.pv_vcpu.trap_ctxt = (void *)v + PAGE_SIZE -
> -                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
>  
>          /* PV guests by default have a 100Hz ticker. */
>          v->periodic_period = MILLISECS(10);
> @@ -467,8 +456,8 @@ int vcpu_initialise(struct vcpu *v)
>      {
>          vcpu_destroy_fpu(v);
>  
> -        if ( !is_hvm_domain(d) && standalone_trap_ctxt(v) )
> -            free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
> +        if ( !is_hvm_domain(d) )
> +            xfree(v->arch.pv_vcpu.trap_ctxt);
>      }
>  
>      return rc;
> @@ -483,8 +472,8 @@ void vcpu_destroy(struct vcpu *v)
>  
>      if ( is_hvm_vcpu(v) )
>          hvm_vcpu_destroy(v);
> -    else if ( standalone_trap_ctxt(v) )
> -        free_xenheap_page(v->arch.pv_vcpu.trap_ctxt);
> +    else
> +        xfree(v->arch.pv_vcpu.trap_ctxt);
>  }
>  
>  int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -26,6 +26,7 @@
>  #include <xen/config.h>
>  #include <xen/irq.h>
>  #include <xen/mm.h>
> +#include <xen/pfn.h>
>  #include <asm/time.h>
>  
>  #define MAX_POOL_NAME_LEN       16
> @@ -524,25 +525,30 @@ static void xmalloc_pool_put(void *p)
>      free_xenheap_page(p);
>  }
>  
> -static void *xmalloc_whole_pages(unsigned long size)
> +static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
>  {
> -    struct bhdr *b;
> -    unsigned int i, pageorder = get_order_from_bytes(size + BHDR_OVERHEAD);
> -    char *p;
> +    unsigned int i, order = get_order_from_bytes(size);
> +    void *res, *p;
> +
> +    if ( align > size )
> +        get_order_from_bytes(align);
>  
> -    b = alloc_xenheap_pages(pageorder, 0);
> -    if ( b == NULL )
> +    res = alloc_xenheap_pages(order, 0);
> +    if ( res == NULL )
>          return NULL;
>  
> -    b->size = PAGE_ALIGN(size + BHDR_OVERHEAD);
> -    for ( p = (char *)b + b->size, i = 0; i < pageorder; ++i )
> +    for ( p = res + PAGE_ALIGN(size), i = 0; i < order; ++i )
>          if ( (unsigned long)p & (PAGE_SIZE << i) )
>          {
>              free_xenheap_pages(p, i);
>              p += PAGE_SIZE << i;
>          }
>  
> -    return (void *)b->ptr.buffer;
> +    PFN_ORDER(virt_to_page(res)) = PFN_UP(size);
> +    /* Check that there was no truncation: */
> +    ASSERT(PFN_ORDER(virt_to_page(res)) == PFN_UP(size));
> +
> +    return res;
>  }
>  
>  static void tlsf_init(void)
> @@ -559,6 +565,11 @@ static void tlsf_init(void)
>   * xmalloc()
>   */
>  
> +#ifndef ZERO_BLOCK_PTR
> +/* Return value for zero-size allocation, distinguished from NULL. */
> +#define ZERO_BLOCK_PTR ((void *)-1L)
> +#endif
> +
>  void *_xmalloc(unsigned long size, unsigned long align)
>  {
>      void *p = NULL;
> @@ -566,6 +577,9 @@ void *_xmalloc(unsigned long size, unsig
>  
>      ASSERT(!in_irq());
>  
> +    if ( !size )
> +        return ZERO_BLOCK_PTR;
> +
>      ASSERT((align & (align - 1)) == 0);
>      if ( align < MEM_ALIGN )
>          align = MEM_ALIGN;
> @@ -577,7 +591,7 @@ void *_xmalloc(unsigned long size, unsig
>      if ( size < PAGE_SIZE )
>          p = xmem_pool_alloc(size, xenpool);
>      if ( p == NULL )
> -        p = xmalloc_whole_pages(size);
> +        return xmalloc_whole_pages(size - align + MEM_ALIGN, align);
>  
>      /* Add alignment padding. */
>      if ( (pad = -(long)p & (align - 1)) != 0 )
> @@ -604,11 +618,28 @@ void xfree(void *p)
>  {
>      struct bhdr *b;
>  
> -    if ( p == NULL )
> +    if ( p == NULL || p == ZERO_BLOCK_PTR )
>          return;
>  
>      ASSERT(!in_irq());
>  
> +    if ( !((unsigned long)p & (PAGE_SIZE - 1)) )
> +    {
> +        unsigned long size = PFN_ORDER(virt_to_page(p));
> +        unsigned int i, order = get_order_from_pages(size);
> +
> +        BUG_ON((unsigned long)p & ((PAGE_SIZE << order) - 1));
> +        for ( i = 0; ; ++i )
> +        {
> +            if ( !(size & (1 << i)) )
> +                continue;
> +            size -= 1 << i;
> +            free_xenheap_pages(p + (size << PAGE_SHIFT), i);
> +            if ( i + 1 >= order )
> +                return;
> +        }
> +    }
> +
>      /* Strip alignment padding. */
>      b = (struct bhdr *)((char *) p - BHDR_OVERHEAD);
>      if ( b->size & 1 )
> @@ -618,21 +649,5 @@ void xfree(void *p)
>          ASSERT(!(b->size & 1));
>      }
>  
> -    if ( b->size >= PAGE_SIZE )
> -    {
> -        unsigned int i, order = get_order_from_bytes(b->size);
> -
> -        BUG_ON((unsigned long)b & ((PAGE_SIZE << order) - 1));
> -        for ( i = 0; ; ++i )
> -        {
> -            if ( !(b->size & (PAGE_SIZE << i)) )
> -                continue;
> -            b->size -= PAGE_SIZE << i;
> -            free_xenheap_pages((void *)b + b->size, i);
> -            if ( i + 1 >= order )
> -                break;
> -        }
> -    }
> -    else
> -        xmem_pool_free(p, xenpool);
> +    xmem_pool_free(p, xenpool);
>  }
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -91,6 +91,9 @@
>  /* Primary stack is restricted to 8kB by guard pages. */
>  #define PRIMARY_STACK_SIZE 8192
>  
> +/* Return value for zero-size _xmalloc(), distinguished from NULL. */
> +#define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
> +
>  #ifndef __ASSEMBLY__
>  extern unsigned long trampoline_phys;
>  #define bootsym_phys(sym)                                 \
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 18 13:36:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:36: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 1U7Qsy-0005gd-3W; Mon, 18 Feb 2013 13:36:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1U7Ptb-0003J7-42
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:32:35 +0000
Received: from [85.158.143.35:58769] by server-1.bemta-4.messagelabs.com id
	0B/5D-08839-26F12215; Mon, 18 Feb 2013 12:32:34 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1361190735!14424131!1
X-Originating-IP: [209.85.212.180]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12677 invoked from network); 18 Feb 2013 12:32:16 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 12:32:16 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi8so3429027wib.7
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 04:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:from:date:message-id:subject:to
	:content-type; bh=nROUWjgNfNWdBskXX6XijEp1nafxjL0IbmeNW1vaYHE=;
	b=wdn8w/82Uv/zkuoHxFvTwlBANIVmK7okxiGpfxnnaEMxuMdjfm4SqDfhLp+rcaSqDB
	FYrZKroLvYyqxQt13YUD0tTyPQnH6FOPwIY+9xEalA+elu0jWsu8MiR+NuPYKSADLrh0
	44Ivotqaa1i2H+UGXO9DiEzK/pNk/I/TRbdQ4ibWU+5RmsyYU7sFJDVOgYrnpl+ePalw
	Px7qDlJVG3GFQCHhcRmidFaBAhmjvz88M0M14HVm5+MySou74kkXSKzXY3CfjJmpXw5+
	4u2mmo4HTwj8qPiHTDt2Pw4G/u7QZj1k8fBSCmxLoHnFXRhsyKU6YzzC7pie6+McUvDb
	jZRA==
X-Received: by 10.180.101.103 with SMTP id ff7mr1991171wib.1.1361190734174;
	Mon, 18 Feb 2013 04:32:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.155.72 with HTTP; Mon, 18 Feb 2013 04:31:34 -0800 (PST)
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 18:01:34 +0530
Message-ID: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 18 Feb 2013 13:35:59 +0000
Subject: [Xen-devel] DomU trying to write on an IO 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: multipart/mixed; boundary="===============4036258395711003637=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4036258395711003637==
Content-Type: multipart/alternative; boundary=f46d041826282e98fb04d5feea75

--f46d041826282e98fb04d5feea75
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I am running xen-hypervisor over qemu. Now while running domU I want to
write on an IO port, which I'll be handling inside Qemu. Basically, this is
a communication mechanism for me to communicate with qemu. I am writing on
port number '0x378' as a root user using "outl" function. But when I run
this code in domU, it does not reach qemu.

So my question is: Is there  some mechanism in xen which handles writing on
IO ports and in case its not a valid IO Port then just discards the write.

-- 
Regards,
Nitin Gupta

--f46d041826282e98fb04d5feea75
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br></div>I am running xen-hypervisor over qem=
u. Now while running domU I want to write on an IO port, which I&#39;ll be =
handling inside Qemu. Basically, this is a communication mechanism for me t=
o communicate with qemu. I am writing on port number &#39;0x378&#39; as a r=
oot user using &quot;outl&quot; function. But when I run this code in domU,=
 it does not reach qemu. <br>

<br>So my question is: Is there=A0 some mechanism in xen which handles writ=
ing on IO ports and in case its not a valid IO Port then just discards the =
write.<br clear=3D"all"><div><div><div><div><div><br>-- <br>Regards,<br>Nit=
in Gupta<br>

<br>
</div></div></div></div></div></div>

--f46d041826282e98fb04d5feea75--


--===============4036258395711003637==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4036258395711003637==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 13:36:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:36: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 1U7Qsy-0005gd-3W; Mon, 18 Feb 2013 13:36:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1U7Ptb-0003J7-42
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 12:32:35 +0000
Received: from [85.158.143.35:58769] by server-1.bemta-4.messagelabs.com id
	0B/5D-08839-26F12215; Mon, 18 Feb 2013 12:32:34 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1361190735!14424131!1
X-Originating-IP: [209.85.212.180]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12677 invoked from network); 18 Feb 2013 12:32:16 -0000
Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com)
	(209.85.212.180)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 12:32:16 -0000
Received: by mail-wi0-f180.google.com with SMTP id hi8so3429027wib.7
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 04:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:from:date:message-id:subject:to
	:content-type; bh=nROUWjgNfNWdBskXX6XijEp1nafxjL0IbmeNW1vaYHE=;
	b=wdn8w/82Uv/zkuoHxFvTwlBANIVmK7okxiGpfxnnaEMxuMdjfm4SqDfhLp+rcaSqDB
	FYrZKroLvYyqxQt13YUD0tTyPQnH6FOPwIY+9xEalA+elu0jWsu8MiR+NuPYKSADLrh0
	44Ivotqaa1i2H+UGXO9DiEzK/pNk/I/TRbdQ4ibWU+5RmsyYU7sFJDVOgYrnpl+ePalw
	Px7qDlJVG3GFQCHhcRmidFaBAhmjvz88M0M14HVm5+MySou74kkXSKzXY3CfjJmpXw5+
	4u2mmo4HTwj8qPiHTDt2Pw4G/u7QZj1k8fBSCmxLoHnFXRhsyKU6YzzC7pie6+McUvDb
	jZRA==
X-Received: by 10.180.101.103 with SMTP id ff7mr1991171wib.1.1361190734174;
	Mon, 18 Feb 2013 04:32:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.155.72 with HTTP; Mon, 18 Feb 2013 04:31:34 -0800 (PST)
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 18:01:34 +0530
Message-ID: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 18 Feb 2013 13:35:59 +0000
Subject: [Xen-devel] DomU trying to write on an IO 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: multipart/mixed; boundary="===============4036258395711003637=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4036258395711003637==
Content-Type: multipart/alternative; boundary=f46d041826282e98fb04d5feea75

--f46d041826282e98fb04d5feea75
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I am running xen-hypervisor over qemu. Now while running domU I want to
write on an IO port, which I'll be handling inside Qemu. Basically, this is
a communication mechanism for me to communicate with qemu. I am writing on
port number '0x378' as a root user using "outl" function. But when I run
this code in domU, it does not reach qemu.

So my question is: Is there  some mechanism in xen which handles writing on
IO ports and in case its not a valid IO Port then just discards the write.

-- 
Regards,
Nitin Gupta

--f46d041826282e98fb04d5feea75
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br></div>I am running xen-hypervisor over qem=
u. Now while running domU I want to write on an IO port, which I&#39;ll be =
handling inside Qemu. Basically, this is a communication mechanism for me t=
o communicate with qemu. I am writing on port number &#39;0x378&#39; as a r=
oot user using &quot;outl&quot; function. But when I run this code in domU,=
 it does not reach qemu. <br>

<br>So my question is: Is there=A0 some mechanism in xen which handles writ=
ing on IO ports and in case its not a valid IO Port then just discards the =
write.<br clear=3D"all"><div><div><div><div><div><br>-- <br>Regards,<br>Nit=
in Gupta<br>

<br>
</div></div></div></div></div></div>

--f46d041826282e98fb04d5feea75--


--===============4036258395711003637==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4036258395711003637==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 13:46:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:46: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 1U7R39-0005s9-8d; Mon, 18 Feb 2013 13:46: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 1U7R38-0005s4-6n
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:46:30 +0000
Received: from [85.158.137.99:44452] by server-14.bemta-3.messagelabs.com id
	9E/59-23533-5B032215; Mon, 18 Feb 2013 13:46:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361195181!19616046!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6774 invoked from network); 18 Feb 2013 13:46:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:46:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1571862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 13:46: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.297.1;
	Mon, 18 Feb 2013 13:46:21 +0000
Message-ID: <1361195180.31407.164.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 13:46:20 +0000
In-Reply-To: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
References: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] DomU trying to write on an IO 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 Mon, 2013-02-18 at 12:31 +0000, Nitin Gupta wrote:
> Hi,
> 
> 
> I am running xen-hypervisor over qemu.

You mean running Xen in a virtual machine provided by qemu? Or are you
talking about the qemu which is associated with an HVM domain under Xen
(i.e. the one running in dom0 or a stub domain).

>  Now while running domU I want to write on an IO port, which I'll be
> handling inside Qemu. Basically, this is a communication mechanism for
> me to communicate with qemu. I am writing on port number '0x378' as a
> root user using "outl" function. But when I run this code in domU, it
> does not reach qemu. 
> 
> So my question is: Is there  some mechanism in xen which handles
> writing on IO ports and in case its not a valid IO Port then just
> discards the write.
> 
> -- 
> Regards,
> Nitin Gupta
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 13:46:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 13:46: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 1U7R39-0005s9-8d; Mon, 18 Feb 2013 13:46: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 1U7R38-0005s4-6n
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 13:46:30 +0000
Received: from [85.158.137.99:44452] by server-14.bemta-3.messagelabs.com id
	9E/59-23533-5B032215; Mon, 18 Feb 2013 13:46:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361195181!19616046!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6774 invoked from network); 18 Feb 2013 13:46:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 13:46:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1571862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 13:46: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.297.1;
	Mon, 18 Feb 2013 13:46:21 +0000
Message-ID: <1361195180.31407.164.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 13:46:20 +0000
In-Reply-To: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
References: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] DomU trying to write on an IO 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 Mon, 2013-02-18 at 12:31 +0000, Nitin Gupta wrote:
> Hi,
> 
> 
> I am running xen-hypervisor over qemu.

You mean running Xen in a virtual machine provided by qemu? Or are you
talking about the qemu which is associated with an HVM domain under Xen
(i.e. the one running in dom0 or a stub domain).

>  Now while running domU I want to write on an IO port, which I'll be
> handling inside Qemu. Basically, this is a communication mechanism for
> me to communicate with qemu. I am writing on port number '0x378' as a
> root user using "outl" function. But when I run this code in domU, it
> does not reach qemu. 
> 
> So my question is: Is there  some mechanism in xen which handles
> writing on IO ports and in case its not a valid IO Port then just
> discards the write.
> 
> -- 
> Regards,
> Nitin Gupta
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:05:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7RKx-0006Qj-M5; Mon, 18 Feb 2013 14:04:55 +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 1U7RKw-0006Qd-RB
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:04:54 +0000
Received: from [85.158.137.99:14523] by server-1.bemta-3.messagelabs.com id
	D1/46-08955-10532215; Mon, 18 Feb 2013 14:04:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361196286!18512390!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1883 invoked from network); 18 Feb 2013 14:04:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:04:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1572689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 14:04: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.297.1;
	Mon, 18 Feb 2013 14:04:46 +0000
Message-ID: <1361196284.31407.167.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 18 Feb 2013 14:04:44 +0000
In-Reply-To: <5110EC7B.1060804@citrix.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
	<5110EC7B.1060804@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
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 4/4] xen: arm: create dom0 DTB /hypervisor/
 node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:26 +0000, Anthony PERARD wrote:
> > +    /*
> > +     * Sanity-check address sizes, since addresses and sizes which do not take
> > +     * up exactly 4 or 8 bytes are not supported.
> > +     */
> > +    if ((addrcells != 1 && addrcells != 2) ||
> > +        (sizecells != 1 && sizecells != 2))
> > +        panic("Cannot cope with this size");
> 
> You could add those two properties in the hypervisor node if they don't
> match what we expect them to be. This would avoid panicking with a
> device tree that have different default values.

Unfortunately the #address-cells nodes etc affect only the children of
the current node. The sizes for this node are controlled by the parent's
sizes.

In practice #address-cells more than 2 (i.e. using 16 or more bytes)
seem like they are going to be rather rare.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:05:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7RKx-0006Qj-M5; Mon, 18 Feb 2013 14:04:55 +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 1U7RKw-0006Qd-RB
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:04:54 +0000
Received: from [85.158.137.99:14523] by server-1.bemta-3.messagelabs.com id
	D1/46-08955-10532215; Mon, 18 Feb 2013 14:04:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361196286!18512390!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1883 invoked from network); 18 Feb 2013 14:04:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:04:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1572689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 14:04: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.297.1;
	Mon, 18 Feb 2013 14:04:46 +0000
Message-ID: <1361196284.31407.167.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 18 Feb 2013 14:04:44 +0000
In-Reply-To: <5110EC7B.1060804@citrix.com>
References: <1359555969.12252.231.camel@zakaz.uk.xensource.com>
	<1359555990-12186-4-git-send-email-ian.campbell@citrix.com>
	<5110EC7B.1060804@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
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 4/4] xen: arm: create dom0 DTB /hypervisor/
 node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-05 at 11:26 +0000, Anthony PERARD wrote:
> > +    /*
> > +     * Sanity-check address sizes, since addresses and sizes which do not take
> > +     * up exactly 4 or 8 bytes are not supported.
> > +     */
> > +    if ((addrcells != 1 && addrcells != 2) ||
> > +        (sizecells != 1 && sizecells != 2))
> > +        panic("Cannot cope with this size");
> 
> You could add those two properties in the hypervisor node if they don't
> match what we expect them to be. This would avoid panicking with a
> device tree that have different default values.

Unfortunately the #address-cells nodes etc affect only the children of
the current node. The sizes for this node are controlled by the parent's
sizes.

In practice #address-cells more than 2 (i.e. using 16 or more bytes)
seem like they are going to be rather rare.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:16:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7RVS-0006eB-W5; Mon, 18 Feb 2013 14:15:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1U7RT9-0006dS-Ru
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:13:24 +0000
Received: from [85.158.139.211:51373] by server-9.bemta-5.messagelabs.com id
	9E/B9-24440-20732215; Mon, 18 Feb 2013 14:13:22 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361196802!18017108!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4793 invoked from network); 18 Feb 2013 14:13:22 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:13:22 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so3531699wie.14
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=7Y/3rTvs1gfZkT8iP/qUuZ2F7WaRH8Y9FMaHbeuehlc=;
	b=OtH4IwUd1kbTHC7+gLTT/FfIW2K4velirWqdOKyquFsQQNIUBiMYu/+Qoj7U4vrZsV
	1iM6oUOb/8sg/1Adf1rTw6rBQqU4nnhVgugVV9vKu4wzwZskP5Tle+jGiB1DTJwxHVln
	sFL9hC2eRQo1OozeKJnjh1yJiX6RPKrmPoIFDbthSczja6ewVXcFoUFabjZ+k6gLzylo
	u6D8ePlBXywhYCjS2fprnSVNi8Mr4sqp/6tzAVrl8FM6twVKs4Novite455bJXC0SNuE
	aliOtxvqLNiNlMSpHPPxX7c/THyfL4eMSGwlhVyTzniQGZDeFpB5DpVH4ioo/64EGGN2
	65mg==
X-Received: by 10.194.60.195 with SMTP id j3mr19296251wjr.33.1361196802038;
	Mon, 18 Feb 2013 06:13:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.155.72 with HTTP; Mon, 18 Feb 2013 06:12:41 -0800 (PST)
In-Reply-To: <1361195180.31407.164.camel@zakaz.uk.xensource.com>
References: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
	<1361195180.31407.164.camel@zakaz.uk.xensource.com>
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 19:42:41 +0530
Message-ID: <CAESzvYTNqPWctyw3i+7nWGSnNrerS7DrgLhWVUK3_6Prw=xUgw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 18 Feb 2013 14:15:45 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] DomU trying to write on an IO 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: multipart/mixed; boundary="===============0762893574676767942=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0762893574676767942==
Content-Type: multipart/alternative; boundary=047d7b86e2f8dadbba04d60053d3

--047d7b86e2f8dadbba04d60053d3
Content-Type: text/plain; charset=ISO-8859-1

I am running Xen in a virtual machine provided by qemu (qemu-system
emulation) without KVM.


On Mon, Feb 18, 2013 at 7:16 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2013-02-18 at 12:31 +0000, Nitin Gupta wrote:
> > Hi,
> >
> >
> > I am running xen-hypervisor over qemu.
>
> You mean running Xen in a virtual machine provided by qemu? Or are you
> talking about the qemu which is associated with an HVM domain under Xen
> (i.e. the one running in dom0 or a stub domain).
>
> >  Now while running domU I want to write on an IO port, which I'll be
> > handling inside Qemu. Basically, this is a communication mechanism for
> > me to communicate with qemu. I am writing on port number '0x378' as a
> > root user using "outl" function. But when I run this code in domU, it
> > does not reach qemu.
> >
> > So my question is: Is there  some mechanism in xen which handles
> > writing on IO ports and in case its not a valid IO Port then just
> > discards the write.
> >
> > --
> > Regards,
> > Nitin Gupta
> >
> >
>
>
>


-- 
Regards,
Nitin Gupta
M.Tech. CSE, IIT Delhi

--047d7b86e2f8dadbba04d60053d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am running Xen in a virtual machine provided by qemu (qe=
mu-system emulation) without KVM.<br></div><div class=3D"gmail_extra"><br><=
br><div class=3D"gmail_quote">On Mon, Feb 18, 2013 at 7:16 PM, Ian Campbell=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D=
"_blank">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 class=3D"im">On Mon, 2013-02-18 at 12:3=
1 +0000, Nitin Gupta wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; I am running xen-hypervisor over qemu.<br>
<br>
</div>You mean running Xen in a virtual machine provided by qemu? Or are yo=
u<br>
talking about the qemu which is associated with an HVM domain under Xen<br>
(i.e. the one running in dom0 or a stub domain).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; =A0Now while running domU I want to write on an IO port, which I&#39;l=
l be<br>
&gt; handling inside Qemu. Basically, this is a communication mechanism for=
<br>
&gt; me to communicate with qemu. I am writing on port number &#39;0x378&#3=
9; as a<br>
&gt; root user using &quot;outl&quot; function. But when I run this code in=
 domU, it<br>
&gt; does not reach qemu.<br>
&gt;<br>
&gt; So my question is: Is there =A0some mechanism in xen which handles<br>
&gt; writing on IO ports and in case its not a valid IO Port then just<br>
&gt; discards the write.<br>
&gt;<br>
&gt; --<br>
&gt; Regards,<br>
&gt; Nitin Gupta<br>
&gt;<br>
&gt;<br>
<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards,<br=
>Nitin Gupta<br>M.Tech. CSE, IIT Delhi<br>
</div>

--047d7b86e2f8dadbba04d60053d3--


--===============0762893574676767942==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0762893574676767942==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 14:16:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7RVS-0006eB-W5; Mon, 18 Feb 2013 14:15:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1U7RT9-0006dS-Ru
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:13:24 +0000
Received: from [85.158.139.211:51373] by server-9.bemta-5.messagelabs.com id
	9E/B9-24440-20732215; Mon, 18 Feb 2013 14:13:22 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361196802!18017108!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4793 invoked from network); 18 Feb 2013 14:13:22 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:13:22 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so3531699wie.14
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=7Y/3rTvs1gfZkT8iP/qUuZ2F7WaRH8Y9FMaHbeuehlc=;
	b=OtH4IwUd1kbTHC7+gLTT/FfIW2K4velirWqdOKyquFsQQNIUBiMYu/+Qoj7U4vrZsV
	1iM6oUOb/8sg/1Adf1rTw6rBQqU4nnhVgugVV9vKu4wzwZskP5Tle+jGiB1DTJwxHVln
	sFL9hC2eRQo1OozeKJnjh1yJiX6RPKrmPoIFDbthSczja6ewVXcFoUFabjZ+k6gLzylo
	u6D8ePlBXywhYCjS2fprnSVNi8Mr4sqp/6tzAVrl8FM6twVKs4Novite455bJXC0SNuE
	aliOtxvqLNiNlMSpHPPxX7c/THyfL4eMSGwlhVyTzniQGZDeFpB5DpVH4ioo/64EGGN2
	65mg==
X-Received: by 10.194.60.195 with SMTP id j3mr19296251wjr.33.1361196802038;
	Mon, 18 Feb 2013 06:13:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.155.72 with HTTP; Mon, 18 Feb 2013 06:12:41 -0800 (PST)
In-Reply-To: <1361195180.31407.164.camel@zakaz.uk.xensource.com>
References: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
	<1361195180.31407.164.camel@zakaz.uk.xensource.com>
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 19:42:41 +0530
Message-ID: <CAESzvYTNqPWctyw3i+7nWGSnNrerS7DrgLhWVUK3_6Prw=xUgw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Mon, 18 Feb 2013 14:15:45 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] DomU trying to write on an IO 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: multipart/mixed; boundary="===============0762893574676767942=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0762893574676767942==
Content-Type: multipart/alternative; boundary=047d7b86e2f8dadbba04d60053d3

--047d7b86e2f8dadbba04d60053d3
Content-Type: text/plain; charset=ISO-8859-1

I am running Xen in a virtual machine provided by qemu (qemu-system
emulation) without KVM.


On Mon, Feb 18, 2013 at 7:16 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2013-02-18 at 12:31 +0000, Nitin Gupta wrote:
> > Hi,
> >
> >
> > I am running xen-hypervisor over qemu.
>
> You mean running Xen in a virtual machine provided by qemu? Or are you
> talking about the qemu which is associated with an HVM domain under Xen
> (i.e. the one running in dom0 or a stub domain).
>
> >  Now while running domU I want to write on an IO port, which I'll be
> > handling inside Qemu. Basically, this is a communication mechanism for
> > me to communicate with qemu. I am writing on port number '0x378' as a
> > root user using "outl" function. But when I run this code in domU, it
> > does not reach qemu.
> >
> > So my question is: Is there  some mechanism in xen which handles
> > writing on IO ports and in case its not a valid IO Port then just
> > discards the write.
> >
> > --
> > Regards,
> > Nitin Gupta
> >
> >
>
>
>


-- 
Regards,
Nitin Gupta
M.Tech. CSE, IIT Delhi

--047d7b86e2f8dadbba04d60053d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am running Xen in a virtual machine provided by qemu (qe=
mu-system emulation) without KVM.<br></div><div class=3D"gmail_extra"><br><=
br><div class=3D"gmail_quote">On Mon, Feb 18, 2013 at 7:16 PM, Ian Campbell=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D=
"_blank">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 class=3D"im">On Mon, 2013-02-18 at 12:3=
1 +0000, Nitin Gupta wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt;<br>
&gt; I am running xen-hypervisor over qemu.<br>
<br>
</div>You mean running Xen in a virtual machine provided by qemu? Or are yo=
u<br>
talking about the qemu which is associated with an HVM domain under Xen<br>
(i.e. the one running in dom0 or a stub domain).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; =A0Now while running domU I want to write on an IO port, which I&#39;l=
l be<br>
&gt; handling inside Qemu. Basically, this is a communication mechanism for=
<br>
&gt; me to communicate with qemu. I am writing on port number &#39;0x378&#3=
9; as a<br>
&gt; root user using &quot;outl&quot; function. But when I run this code in=
 domU, it<br>
&gt; does not reach qemu.<br>
&gt;<br>
&gt; So my question is: Is there =A0some mechanism in xen which handles<br>
&gt; writing on IO ports and in case its not a valid IO Port then just<br>
&gt; discards the write.<br>
&gt;<br>
&gt; --<br>
&gt; Regards,<br>
&gt; Nitin Gupta<br>
&gt;<br>
&gt;<br>
<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards,<br=
>Nitin Gupta<br>M.Tech. CSE, IIT Delhi<br>
</div>

--047d7b86e2f8dadbba04d60053d3--


--===============0762893574676767942==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0762893574676767942==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 14:18:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7RXk-0006jV-ID; Mon, 18 Feb 2013 14:18:08 +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 1U7RXi-0006jN-OO
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 14:18:06 +0000
Received: from [85.158.139.83:42671] by server-2.bemta-5.messagelabs.com id
	77/3A-16911-D1832215; Mon, 18 Feb 2013 14:18:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361197085!27809908!1
X-Originating-IP: [74.125.82.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11948 invoked from network); 18 Feb 2013 14:18:05 -0000
Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com)
	(74.125.82.182)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:18:05 -0000
Received: by mail-we0-f182.google.com with SMTP id t57so4842104wey.13
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 06:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=m8IMmV3VYpX+JqG4tsXR9lDBZ49J4kj2RS1bEFmukc4=;
	b=aJqNkGagvIUXzj+/tXNczctMN0+flNQ0cAQpzNO5EDl3iYn8zzB2BGp2NR5KaxLjP4
	kyQM37S6nJiBHh3Z44i6vby8T7VSSCbBtDH+jxbmaeSzUdz/+EbblO7+BTciINwk+y7T
	m2ohtV3coV31SYXUnFITuVyDGQ1mFoxoSCUBaiNmS4jdvcS/uYBJ5eiFriNFsIpJzXN8
	2uaos82OArqrte87EejKXuHKRnrR8s6yo4lNsxCVG9Iut5CqEVWU2Q0nnrxsVxJmOlN8
	zU+VBYZoC4rEL6mCnKBDiZ4kDGRqnxVueK1jKvre4mMXYXiLMGpd+ASOqQYRMPhmeDO2
	yFgg==
X-Received: by 10.180.95.199 with SMTP id dm7mr6217777wib.20.1361197084866;
	Mon, 18 Feb 2013 06:18:04 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id cg4sm7038683wib.3.2013.02.18.06.17.57
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 06:18:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 18 Feb 2013 14:17:50 +0000
From: Keir Fraser <keir@xen.org>
To: <fantonifabio@tiscali.it>,
	<xen-devel@lists.xensource.com>
Message-ID: <CD47E88E.5BEB3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] tools/firmware: Fix ovmf build with gcc
	version different from 4.4
Thread-Index: Ac4N4ruCnDT1/PCSP0mKRE51G3n2aA==
In-Reply-To: <1361193850-5028-1-git-send-email-fantonifabio@tiscali.it>
Mime-version: 1.0
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: Fix ovmf build with gcc
 version different from 4.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 18/02/2013 13:24, "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
wrote:

> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

They have a separate config for every version of gcc? That's mad. :)

 -- Keir

> ---
>  tools/firmware/ovmf-makefile |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile
> index c3cd466..72fe99d 100644
> --- a/tools/firmware/ovmf-makefile
> +++ b/tools/firmware/ovmf-makefile
> @@ -1,6 +1,8 @@
>  # OVMF building system is not ready yet to run in parallel.
>  # Force it to be serial in order to exploit parallelism for neighbors.
>  
> +GCCVERSION = $(shell gcc --version | grep -om1 '[0-9]\+[.][0-9]\+' | tr -d .
> | tail -n1)
> +
>  .NOTPARALLEL:
>  MAKEFLAGS  += -j1
>  
> @@ -10,7 +12,7 @@ all: ovmf.bin
>  .PHONY: ovmf.bin
>  ovmf.bin:
> OvmfPkg/build.sh -a X64
> - cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
> + cp Build/OvmfX64/DEBUG_GCC$(GCCVERSION)/FV/OVMF.fd ovmf.bin
>  
>  .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 Mon Feb 18 14:18:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7RXk-0006jV-ID; Mon, 18 Feb 2013 14:18:08 +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 1U7RXi-0006jN-OO
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 14:18:06 +0000
Received: from [85.158.139.83:42671] by server-2.bemta-5.messagelabs.com id
	77/3A-16911-D1832215; Mon, 18 Feb 2013 14:18:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361197085!27809908!1
X-Originating-IP: [74.125.82.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11948 invoked from network); 18 Feb 2013 14:18:05 -0000
Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com)
	(74.125.82.182)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:18:05 -0000
Received: by mail-we0-f182.google.com with SMTP id t57so4842104wey.13
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 06:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=m8IMmV3VYpX+JqG4tsXR9lDBZ49J4kj2RS1bEFmukc4=;
	b=aJqNkGagvIUXzj+/tXNczctMN0+flNQ0cAQpzNO5EDl3iYn8zzB2BGp2NR5KaxLjP4
	kyQM37S6nJiBHh3Z44i6vby8T7VSSCbBtDH+jxbmaeSzUdz/+EbblO7+BTciINwk+y7T
	m2ohtV3coV31SYXUnFITuVyDGQ1mFoxoSCUBaiNmS4jdvcS/uYBJ5eiFriNFsIpJzXN8
	2uaos82OArqrte87EejKXuHKRnrR8s6yo4lNsxCVG9Iut5CqEVWU2Q0nnrxsVxJmOlN8
	zU+VBYZoC4rEL6mCnKBDiZ4kDGRqnxVueK1jKvre4mMXYXiLMGpd+ASOqQYRMPhmeDO2
	yFgg==
X-Received: by 10.180.95.199 with SMTP id dm7mr6217777wib.20.1361197084866;
	Mon, 18 Feb 2013 06:18:04 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id cg4sm7038683wib.3.2013.02.18.06.17.57
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 06:18:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 18 Feb 2013 14:17:50 +0000
From: Keir Fraser <keir@xen.org>
To: <fantonifabio@tiscali.it>,
	<xen-devel@lists.xensource.com>
Message-ID: <CD47E88E.5BEB3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] tools/firmware: Fix ovmf build with gcc
	version different from 4.4
Thread-Index: Ac4N4ruCnDT1/PCSP0mKRE51G3n2aA==
In-Reply-To: <1361193850-5028-1-git-send-email-fantonifabio@tiscali.it>
Mime-version: 1.0
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Campbell@citrix.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools/firmware: Fix ovmf build with gcc
 version different from 4.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 18/02/2013 13:24, "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
wrote:

> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

They have a separate config for every version of gcc? That's mad. :)

 -- Keir

> ---
>  tools/firmware/ovmf-makefile |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile
> index c3cd466..72fe99d 100644
> --- a/tools/firmware/ovmf-makefile
> +++ b/tools/firmware/ovmf-makefile
> @@ -1,6 +1,8 @@
>  # OVMF building system is not ready yet to run in parallel.
>  # Force it to be serial in order to exploit parallelism for neighbors.
>  
> +GCCVERSION = $(shell gcc --version | grep -om1 '[0-9]\+[.][0-9]\+' | tr -d .
> | tail -n1)
> +
>  .NOTPARALLEL:
>  MAKEFLAGS  += -j1
>  
> @@ -10,7 +12,7 @@ all: ovmf.bin
>  .PHONY: ovmf.bin
>  ovmf.bin:
> OvmfPkg/build.sh -a X64
> - cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin
> + cp Build/OvmfX64/DEBUG_GCC$(GCCVERSION)/FV/OVMF.fd ovmf.bin
>  
>  .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 Mon Feb 18 14:21:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14:21: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 1U7RaL-0006qz-4N; Mon, 18 Feb 2013 14: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 1U7RaJ-0006qs-Ii
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:20:47 +0000
Received: from [85.158.137.99:54858] by server-16.bemta-3.messagelabs.com id
	08/3D-02727-EB832215; Mon, 18 Feb 2013 14:20:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361197242!21109948!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 18 Feb 2013 14:20:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:20:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1573310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 14:20: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.297.1;
	Mon, 18 Feb 2013 14:20:42 +0000
Message-ID: <1361197241.32047.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 14:20:41 +0000
In-Reply-To: <CAESzvYTNqPWctyw3i+7nWGSnNrerS7DrgLhWVUK3_6Prw=xUgw@mail.gmail.com>
References: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
	<1361195180.31407.164.camel@zakaz.uk.xensource.com>
	<CAESzvYTNqPWctyw3i+7nWGSnNrerS7DrgLhWVUK3_6Prw=xUgw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] DomU trying to write on an IO 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 Mon, 2013-02-18 at 14:12 +0000, Nitin Gupta wrote:
> I am running Xen in a virtual machine provided by qemu (qemu-system
> emulation) without KVM.

Please don't top post.

> On Mon, Feb 18, 2013 at 7:16 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

>         
>         >  Now while running domU I want to write on an IO port, which I'll be
>         > handling inside Qemu. Basically, this is a communication mechanism for
>         > me to communicate with qemu. I am writing on port number '0x378' as a
>         > root user using "outl" function. But when I run this code in domU, it
>         > does not reach qemu.
>         >
>         > So my question is: Is there  some mechanism in xen which handles
>         > writing on IO ports and in case its not a valid IO Port then just
>         > discards the write.

It should be pretty obvious that I/O operations performed by guests are
by default virtualised and not passed to the underlying hardware (which
is qemu in this case).

If you want a guest to be able to access real hardware then you need to
configure it appropriately.  In this case by using the "ioports"
directive in your guest configuration file (see xl.cfg(5)).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:21:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14:21: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 1U7RaL-0006qz-4N; Mon, 18 Feb 2013 14: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 1U7RaJ-0006qs-Ii
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:20:47 +0000
Received: from [85.158.137.99:54858] by server-16.bemta-3.messagelabs.com id
	08/3D-02727-EB832215; Mon, 18 Feb 2013 14:20:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361197242!21109948!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28567 invoked from network); 18 Feb 2013 14:20:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:20:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1573310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 14:20: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.297.1;
	Mon, 18 Feb 2013 14:20:42 +0000
Message-ID: <1361197241.32047.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nitin Gupta <nitin.kobain@gmail.com>
Date: Mon, 18 Feb 2013 14:20:41 +0000
In-Reply-To: <CAESzvYTNqPWctyw3i+7nWGSnNrerS7DrgLhWVUK3_6Prw=xUgw@mail.gmail.com>
References: <CAESzvYQEMHEuiW0tvcWBo4-8E3S=_FtWb6=jNxF3roPUv1veCA@mail.gmail.com>
	<1361195180.31407.164.camel@zakaz.uk.xensource.com>
	<CAESzvYTNqPWctyw3i+7nWGSnNrerS7DrgLhWVUK3_6Prw=xUgw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] DomU trying to write on an IO 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 Mon, 2013-02-18 at 14:12 +0000, Nitin Gupta wrote:
> I am running Xen in a virtual machine provided by qemu (qemu-system
> emulation) without KVM.

Please don't top post.

> On Mon, Feb 18, 2013 at 7:16 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

>         
>         >  Now while running domU I want to write on an IO port, which I'll be
>         > handling inside Qemu. Basically, this is a communication mechanism for
>         > me to communicate with qemu. I am writing on port number '0x378' as a
>         > root user using "outl" function. But when I run this code in domU, it
>         > does not reach qemu.
>         >
>         > So my question is: Is there  some mechanism in xen which handles
>         > writing on IO ports and in case its not a valid IO Port then just
>         > discards the write.

It should be pretty obvious that I/O operations performed by guests are
by default virtualised and not passed to the underlying hardware (which
is qemu in this case).

If you want a guest to be able to access real hardware then you need to
configure it appropriately.  In this case by using the "ioports"
directive in your guest configuration file (see xl.cfg(5)).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:27:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7Rh4-0007Dv-Ld; Mon, 18 Feb 2013 14:27:46 +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 1U7Rh2-0007Dk-NK
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:27:44 +0000
Received: from [85.158.143.99:2170] by server-2.bemta-4.messagelabs.com id
	A4/0F-12656-06A32215; Mon, 18 Feb 2013 14:27:44 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361197661!27536282!1
X-Originating-IP: [209.85.223.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15948 invoked from network); 18 Feb 2013 14:27:42 -0000
Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com)
	(209.85.223.175)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:27:42 -0000
Received: by mail-ie0-f175.google.com with SMTP id c12so7330043ieb.34
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:27:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=eaVySLHk91KrrsRDgxunVaf/kgkeJvknp66c0vb92Wc=;
	b=pWhwVEELvo6Y0J6HJ397vQQKJTYkGIGTPVgneJZJbiIWhvp8HjKwhoOXr9bY7Lh4HJ
	jR6ecUqXY56BxrCEMTljIehdmNx/qI1qH0kY6ZuDq42Ry7OTDADG4Tcb1VBGAfcrN5ua
	YNvmRjJx8jTeVVJm9/9VvCzSsuZx+V1IpUhpMLOx3x2g35T8HUe+ZDXV3gQh0o1s/0yR
	PBJ9vjj0yJSW03PvvRC9fA+9YIdwgjB0bspTuQOuV5NimAU6kf7qMP1QS7sASgIw01O9
	UJveSfEZgLbSEUuzSXjmMQgQ+7cEHPwhBm+jVU61/kXuJYkp3wXiU8ZT9b4PMftaO3dT
	hbOQ==
X-Received: by 10.50.57.200 with SMTP id k8mr7523197igq.44.1361197661066;
	Mon, 18 Feb 2013 06:27:41 -0800 (PST)
Received: from [192.168.1.101] (69-165-137-14.dsl.teksavvy.com.
	[69.165.137.14])
	by mx.google.com with ESMTPS id ee5sm2268933igc.0.2013.02.18.06.27.38
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 06:27:39 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.24059.1361185990.1399.xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 09:27:41 -0500
Message-Id: <2A2E031D-D98E-4131-A4CF-F3C753BFF2F3@gridcentric.ca>
References: <mailman.24059.1361185990.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkXMPyFj7zMJx56nE6ZVMUh2Sq5Ia/5/66xSiaPC+XA3jFo14V9qtrDnwOLngS0NhgziTpX
Cc: Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Sylvain Munaut <s.munaut@whatever-company.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
	order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've just installed a self-built Xen 4.2.1 package on a debian wheezy
> 
> Is this exactly 4.2.1, some later revision from 4.2-testing or otherwise
> patches? Can you let us know the comit id.
> 
>> and when trying to run a HVM VM (that I was previously running with
>> the official xen 4.0 package on squeeze), it starts fine and I can
>> even use the VM for a few minutes then suddenly I loose all
>> communication with VM and the Dom0 and it just reboots ...
> 
> Please can you share the domain configuration. Are you running PV
> drivers (esp. ballooning) within it?
> 
>> I enabled the xen serial console and this is what I got when the crash happens:
>> 
>> 
>> (XEN) mm locking order violation: 260 > 222
> 
> 260 == pod lock, 222 is the p2m lock. I've CCd George and Tim.

It's a bad locking interaction between shadow and PoD, introduced in 4.2. The one-line fix is to turn on locking p2m for shadow, as well. But we need to make sure that doing that doesn't introduce other regressions in shadow.

Andres
> 
>> (XEN) Xen BUG at mm-locks.h:118
>> (XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
>> (XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
>> (XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
>> (XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
>> (XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
>> (XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
>> (XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
>> (XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
>> (XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
>> (XEN) Xen stack trace from rsp=ffff82c48029f978:
>> (XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
>> (XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
>> (XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
>> (XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
>> (XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
>> (XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
>> (XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
>> (XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
>> (XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
>> (XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
>> (XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
>> (XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
>> (XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
>> (XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
>> (XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
>> (XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
>> (XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
>> (XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
>> (XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
>> (XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
>> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
>> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
>> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
>> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
>> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
>> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
>> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
>> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
>> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
>> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
>> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
>> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
>> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) Xen BUG at mm-locks.h:118
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>> 
>> 
>> Any suggestions ?
>> 
>> It is very reproducible and it's on a test machine I can reboot any
>> time, so if you need more debug info, I can collect it.
>> I don't have any different hw to test on unfortunately.
>> 
>> 
>> Cheers,
>> 
>>    Sylvain
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> End of Xen-devel Digest, Vol 96, Issue 248
> ******************************************


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:27:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7Rh4-0007Dv-Ld; Mon, 18 Feb 2013 14:27:46 +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 1U7Rh2-0007Dk-NK
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:27:44 +0000
Received: from [85.158.143.99:2170] by server-2.bemta-4.messagelabs.com id
	A4/0F-12656-06A32215; Mon, 18 Feb 2013 14:27:44 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361197661!27536282!1
X-Originating-IP: [209.85.223.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15948 invoked from network); 18 Feb 2013 14:27:42 -0000
Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com)
	(209.85.223.175)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:27:42 -0000
Received: by mail-ie0-f175.google.com with SMTP id c12so7330043ieb.34
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:27:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=eaVySLHk91KrrsRDgxunVaf/kgkeJvknp66c0vb92Wc=;
	b=pWhwVEELvo6Y0J6HJ397vQQKJTYkGIGTPVgneJZJbiIWhvp8HjKwhoOXr9bY7Lh4HJ
	jR6ecUqXY56BxrCEMTljIehdmNx/qI1qH0kY6ZuDq42Ry7OTDADG4Tcb1VBGAfcrN5ua
	YNvmRjJx8jTeVVJm9/9VvCzSsuZx+V1IpUhpMLOx3x2g35T8HUe+ZDXV3gQh0o1s/0yR
	PBJ9vjj0yJSW03PvvRC9fA+9YIdwgjB0bspTuQOuV5NimAU6kf7qMP1QS7sASgIw01O9
	UJveSfEZgLbSEUuzSXjmMQgQ+7cEHPwhBm+jVU61/kXuJYkp3wXiU8ZT9b4PMftaO3dT
	hbOQ==
X-Received: by 10.50.57.200 with SMTP id k8mr7523197igq.44.1361197661066;
	Mon, 18 Feb 2013 06:27:41 -0800 (PST)
Received: from [192.168.1.101] (69-165-137-14.dsl.teksavvy.com.
	[69.165.137.14])
	by mx.google.com with ESMTPS id ee5sm2268933igc.0.2013.02.18.06.27.38
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 06:27:39 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.24059.1361185990.1399.xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 09:27:41 -0500
Message-Id: <2A2E031D-D98E-4131-A4CF-F3C753BFF2F3@gridcentric.ca>
References: <mailman.24059.1361185990.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkXMPyFj7zMJx56nE6ZVMUh2Sq5Ia/5/66xSiaPC+XA3jFo14V9qtrDnwOLngS0NhgziTpX
Cc: Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Sylvain Munaut <s.munaut@whatever-company.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
	order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've just installed a self-built Xen 4.2.1 package on a debian wheezy
> 
> Is this exactly 4.2.1, some later revision from 4.2-testing or otherwise
> patches? Can you let us know the comit id.
> 
>> and when trying to run a HVM VM (that I was previously running with
>> the official xen 4.0 package on squeeze), it starts fine and I can
>> even use the VM for a few minutes then suddenly I loose all
>> communication with VM and the Dom0 and it just reboots ...
> 
> Please can you share the domain configuration. Are you running PV
> drivers (esp. ballooning) within it?
> 
>> I enabled the xen serial console and this is what I got when the crash happens:
>> 
>> 
>> (XEN) mm locking order violation: 260 > 222
> 
> 260 == pod lock, 222 is the p2m lock. I've CCd George and Tim.

It's a bad locking interaction between shadow and PoD, introduced in 4.2. The one-line fix is to turn on locking p2m for shadow, as well. But we need to make sure that doing that doesn't introduce other regressions in shadow.

Andres
> 
>> (XEN) Xen BUG at mm-locks.h:118
>> (XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    e008:[<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
>> (XEN) RFLAGS: 0000000000010296   CONTEXT: hypervisor
>> (XEN) rax: ffff82c4802e8e20   rbx: ffff8302278ee820   rcx: 0000000000000000
>> (XEN) rdx: ffff82c48029ff18   rsi: 000000000000000a   rdi: ffff82c480258640
>> (XEN) rbp: 0000000000000000   rsp: ffff82c48029f978   r8:  0000000000000004
>> (XEN) r9:  0000000000000003   r10: 0000000000000002   r11: ffff82c4802c8c80
>> (XEN) r12: 0000000000000000   r13: ffff83022795f000   r14: 000000000005f70a
>> (XEN) r15: 000000000005fb0a   cr0: 0000000080050033   cr4: 00000000000026f0
>> (XEN) cr3: 00000002277ac000   cr2: 00000000d8b86058
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
>> (XEN) Xen stack trace from rsp=ffff82c48029f978:
>> (XEN)    000000000017e26b 000000000005fb0b ffff8302278eed08 000000010a040000
>> (XEN)    ffff82c48029ff18 600000017e26b067 6000000203243267 60000002279be467
>> (XEN)    0000000000000100 0000000000000000 ffff8302278ee820 000000000000a040
>> (XEN)    ffff82c48029faf4 ffff82c48016a4bd 0000000000000000 ffff82c4801d6666
>> (XEN)    0000000000000000 ffff82c48029ff18 0000002000000020 ffff82c48029faf4
>> (XEN)    ffff8302278ee820 ffff82c48029fa70 000000000000a040 000000000005fb0b
>> (XEN)    ffff82c48029fbec 0000000000000000 ffff8000002fd858 ffff8302278ee820
>> (XEN)    0000000000000006 ffff82c4801dbec3 ffff83022795fad0 ffff82c400000001
>> (XEN)    0000000000000001 000000005fb0b000 000000000000a040 806000000010b000
>> (XEN)    6000000172210267 60000002015bd467 ffff83017e26b000 0000000000000001
>> (XEN)    ffff8302278ee820 000000000005fb0b ffff82c48029fbec ffff82c48029fbf4
>> (XEN)    0000000000000000 ffff82c4801d6666 0000000000000000 0000000000000000
>> (XEN)    0000000000001e00 ffff83022795f000 ffff8300d7d10000 000000000005fb0b
>> (XEN)    ffff82c48029ff18 0000000080000b0e ffff8300d7d10000 ffff82c4801fa23f
>> (XEN)    ffff830000000001 ffff83022795f000 0000000000000008 0000000000001e00
>> (XEN)    00007d0a00000006 00000000b9fb2000 000000000003fae9 ffff83022795fb40
>> (XEN)    000000000017ecb9 00000000000b9fb2 ffff82c4802e9c60 ffff83022795fad0
>> (XEN)    ffff8300d7d10920 0000000000000060 ffff82c48029ff18 0000000000000002
>> (XEN)    0000000000000e78 0000000000000000 00000000d7d10000 0000000000000d90
>> (XEN)    0000000000000000 ffff82c4801cdda8 00000004fffe0080 0000000700000000
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
>> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
>> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
>> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
>> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
>> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
>> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
>> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
>> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
>> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
>> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
>> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
>> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
>> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) Xen BUG at mm-locks.h:118
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>> 
>> 
>> Any suggestions ?
>> 
>> It is very reproducible and it's on a test machine I can reboot any
>> time, so if you need more debug info, I can collect it.
>> I don't have any different hw to test on unfortunately.
>> 
>> 
>> Cheers,
>> 
>>    Sylvain
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> End of Xen-devel Digest, Vol 96, Issue 248
> ******************************************


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:48:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7S0Z-0007zo-RH; Mon, 18 Feb 2013 14:47:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7S0Y-0007zc-TT
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:47:55 +0000
Received: from [85.158.139.211:30836] by server-15.bemta-5.messagelabs.com id
	C4/72-18914-A1F32215; Mon, 18 Feb 2013 14:47:54 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361198873!18023058!1
X-Originating-IP: [209.85.214.54]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11931 invoked from network); 18 Feb 2013 14:47:53 -0000
Received: from mail-bk0-f54.google.com (HELO mail-bk0-f54.google.com)
	(209.85.214.54)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:47:53 -0000
Received: by mail-bk0-f54.google.com with SMTP id w5so2623962bku.27
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:47:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=MJ0Y37TY68IZOGrQuas8hhwuY0UahD8Wo9xe+qlxKM8=;
	b=bsUEMGPzwLQvmGH8dNBqrwEkaNNkkKgJjj6v3fkTvglOd95NepkB9OuTp+eUisFuj7
	CSjy+wiv8feTA9xjVGJrh92DxWm4XI/wYttR6QcP7bggllooL+QRSKd9xWLjSZgpUfK4
	5Ukny3ix0WPkSrjTBN0n/7Q/HbUpt8+4OO8RxuxS0/umc6w6Ef2oeX70qc04MBM0WbzB
	cvN8icjNHy4ua01AhvnKQ25EgM4jPqWjRFQDU25nW2X/T4pJfQtYyAeu8O+vmL+dA32M
	bka8tR5PDoCP1yxk+QqyOn/GkynFWQUP36R9m1YCJknTq+CjwWvfHAZvbIco99xdbLdL
	OAxA==
MIME-Version: 1.0
X-Received: by 10.205.138.148 with SMTP id is20mr4869608bkc.45.1361198873027; 
	Mon, 18 Feb 2013 06:47:53 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 06:47:52 -0800 (PST)
In-Reply-To: <20130218113541.GA77310@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
Date: Mon, 18 Feb 2013 15:47:52 +0100
Message-ID: <CAF6-1L5j5tSCeLO5FhQywDOgBoMA=ugY6wwj_Ov6YnJxDLri+w@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQnutZ8bBVER7/GXhbl7e0LMF3NodfPDv8kjmd2LIG5Ad9pnj1hEFmuwo2UUf2v6nSg92sR3
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,


> In the meantime, perhaps you could try the attached (untested) patch.
> If my guess is right, it ought to stop the crashes but you might find
> the VM's performance suffers.

The patch seems to have fixed this issue.

I did however encounter a :

(XEN) p2m_pod_demand_populate: Dom1 out of PoD memory! (tot=392185
ents=131072 dom0)
(XEN) domain_crash called from p2m-pod.c:1077
(XEN) Domain 1 reported crashed by domain 0 on cpu#1:

The domU then rebooted and it doesn't seem to happen again, but since
it's related to PoD, it might be related to that same issue ...


Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:48:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7S0Z-0007zo-RH; Mon, 18 Feb 2013 14:47:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7S0Y-0007zc-TT
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:47:55 +0000
Received: from [85.158.139.211:30836] by server-15.bemta-5.messagelabs.com id
	C4/72-18914-A1F32215; Mon, 18 Feb 2013 14:47:54 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361198873!18023058!1
X-Originating-IP: [209.85.214.54]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11931 invoked from network); 18 Feb 2013 14:47:53 -0000
Received: from mail-bk0-f54.google.com (HELO mail-bk0-f54.google.com)
	(209.85.214.54)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:47:53 -0000
Received: by mail-bk0-f54.google.com with SMTP id w5so2623962bku.27
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:47:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=MJ0Y37TY68IZOGrQuas8hhwuY0UahD8Wo9xe+qlxKM8=;
	b=bsUEMGPzwLQvmGH8dNBqrwEkaNNkkKgJjj6v3fkTvglOd95NepkB9OuTp+eUisFuj7
	CSjy+wiv8feTA9xjVGJrh92DxWm4XI/wYttR6QcP7bggllooL+QRSKd9xWLjSZgpUfK4
	5Ukny3ix0WPkSrjTBN0n/7Q/HbUpt8+4OO8RxuxS0/umc6w6Ef2oeX70qc04MBM0WbzB
	cvN8icjNHy4ua01AhvnKQ25EgM4jPqWjRFQDU25nW2X/T4pJfQtYyAeu8O+vmL+dA32M
	bka8tR5PDoCP1yxk+QqyOn/GkynFWQUP36R9m1YCJknTq+CjwWvfHAZvbIco99xdbLdL
	OAxA==
MIME-Version: 1.0
X-Received: by 10.205.138.148 with SMTP id is20mr4869608bkc.45.1361198873027; 
	Mon, 18 Feb 2013 06:47:53 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 06:47:52 -0800 (PST)
In-Reply-To: <20130218113541.GA77310@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
Date: Mon, 18 Feb 2013 15:47:52 +0100
Message-ID: <CAF6-1L5j5tSCeLO5FhQywDOgBoMA=ugY6wwj_Ov6YnJxDLri+w@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQnutZ8bBVER7/GXhbl7e0LMF3NodfPDv8kjmd2LIG5Ad9pnj1hEFmuwo2UUf2v6nSg92sR3
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,


> In the meantime, perhaps you could try the attached (untested) patch.
> If my guess is right, it ought to stop the crashes but you might find
> the VM's performance suffers.

The patch seems to have fixed this issue.

I did however encounter a :

(XEN) p2m_pod_demand_populate: Dom1 out of PoD memory! (tot=392185
ents=131072 dom0)
(XEN) domain_crash called from p2m-pod.c:1077
(XEN) Domain 1 reported crashed by domain 0 on cpu#1:

The domU then rebooted and it doesn't seem to happen again, but since
it's related to PoD, it might be related to that same issue ...


Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:48:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7S0Y-0007zd-F3; Mon, 18 Feb 2013 14:47: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 1U7S0X-0007zX-1L
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 14:47:53 +0000
Received: from [85.158.143.99:56353] by server-2.bemta-4.messagelabs.com id
	EC/86-12656-81F32215; Mon, 18 Feb 2013 14:47:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361198664!27414171!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26217 invoked from network); 18 Feb 2013 14:44:27 -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;
	18 Feb 2013 14:44:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8002384"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:44:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:44:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7Rx9-0003i7-Gt;
	Mon, 18 Feb 2013 14:44:23 +0000
Date: Mon, 18 Feb 2013 14:44:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360933488.31407.35.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

On Fri, 15 Feb 2013, Ian Campbell wrote:
> > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> >  {
> >      struct vtimer *t = data;
> >      t->ctl |= CNTx_CTL_PENDING;
> > -    t->ctl &= ~CNTx_CTL_MASK;
> > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> 
> Thinking about the previous discussion about exposing the change of the
> mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> actually represent the state of the underlying physical mask bit, since
> we do emulate accesses after all.

Sure. However this change still makes sense: if the guest masked the
timer (no matter how we internally represent it), we should not inject
an interrupt.


> >  }
> >  
> >  static void virt_timer_expired(void *data)
> > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> >      vgic_vcpu_inject_irq(t->v, 27, 1);
> >  }
> >   
> > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > +{
> > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > +}
> > +
> > +int __init init_ptimer(void)
> > +{
> > +    register_gic_callback(30, phys_timer_gic_callback);
> > +    return 0;
> > +}
> > +
> >  int vcpu_vtimer_init(struct vcpu *v)
> >  {
> >      struct vtimer *t = &v->arch.phys_timer;
> > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >          {
> >              v->arch.phys_timer.ctl = *r;
> >  
> > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> 
> Why does PENDING matter here and below?

Doing tests on the physical hardware to better understand its behaviour,
I noticed that the pending bit gets set even if the timer is masked
(and therefore no interrupt is asserted).

However if the pending bit is already set there is no point for us to
try to set it again, so we skip setting the internal Xen timer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:48:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7S0Y-0007zd-F3; Mon, 18 Feb 2013 14:47: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 1U7S0X-0007zX-1L
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 14:47:53 +0000
Received: from [85.158.143.99:56353] by server-2.bemta-4.messagelabs.com id
	EC/86-12656-81F32215; Mon, 18 Feb 2013 14:47:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361198664!27414171!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26217 invoked from network); 18 Feb 2013 14:44:27 -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;
	18 Feb 2013 14:44:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8002384"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:44:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:44:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7Rx9-0003i7-Gt;
	Mon, 18 Feb 2013 14:44:23 +0000
Date: Mon, 18 Feb 2013 14:44:22 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1360933488.31407.35.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

On Fri, 15 Feb 2013, Ian Campbell wrote:
> > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> >  {
> >      struct vtimer *t = data;
> >      t->ctl |= CNTx_CTL_PENDING;
> > -    t->ctl &= ~CNTx_CTL_MASK;
> > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> 
> Thinking about the previous discussion about exposing the change of the
> mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> actually represent the state of the underlying physical mask bit, since
> we do emulate accesses after all.

Sure. However this change still makes sense: if the guest masked the
timer (no matter how we internally represent it), we should not inject
an interrupt.


> >  }
> >  
> >  static void virt_timer_expired(void *data)
> > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> >      vgic_vcpu_inject_irq(t->v, 27, 1);
> >  }
> >   
> > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > +{
> > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > +}
> > +
> > +int __init init_ptimer(void)
> > +{
> > +    register_gic_callback(30, phys_timer_gic_callback);
> > +    return 0;
> > +}
> > +
> >  int vcpu_vtimer_init(struct vcpu *v)
> >  {
> >      struct vtimer *t = &v->arch.phys_timer;
> > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >          {
> >              v->arch.phys_timer.ctl = *r;
> >  
> > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> 
> Why does PENDING matter here and below?

Doing tests on the physical hardware to better understand its behaviour,
I noticed that the pending bit gets set even if the timer is masked
(and therefore no interrupt is asserted).

However if the pending bit is already set there is no point for us to
try to set it again, so we skip setting the internal Xen timer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:58:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7SAW-0008IZ-5R; Mon, 18 Feb 2013 14:58:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7SAU-0008IP-JI
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:58:10 +0000
Received: from [85.158.137.99:2149] by server-12.bemta-3.messagelabs.com id
	EA/49-05889-18142215; Mon, 18 Feb 2013 14:58:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361199482!21843212!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7144 invoked from network); 18 Feb 2013 14:58:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8004509"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:58:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:58:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SAL-0003uJ-1c;
	Mon, 18 Feb 2013 14:58:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <konrad.wilk@oracle.com>
Date: Mon, 18 Feb 2013 14:57:57 +0000
Message-ID: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/2] xen-evtchn misc 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 misc fixes for Xen evtchn driver. The first one is a reposted version of a
bug fix, the second one is comment and output adjustment.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:58:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7SAW-0008IZ-5R; Mon, 18 Feb 2013 14:58:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7SAU-0008IP-JI
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:58:10 +0000
Received: from [85.158.137.99:2149] by server-12.bemta-3.messagelabs.com id
	EA/49-05889-18142215; Mon, 18 Feb 2013 14:58:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361199482!21843212!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7144 invoked from network); 18 Feb 2013 14:58:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8004509"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:58:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:58:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SAL-0003uJ-1c;
	Mon, 18 Feb 2013 14:58:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <konrad.wilk@oracle.com>
Date: Mon, 18 Feb 2013 14:57:57 +0000
Message-ID: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/2] xen-evtchn misc 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 misc fixes for Xen evtchn driver. The first one is a reposted version of a
bug fix, the second one is comment and output adjustment.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:58:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7SAa-0008J5-HX; Mon, 18 Feb 2013 14:58:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7SAZ-0008Ip-5C
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:58:15 +0000
Received: from [85.158.137.99:7876] by server-7.bemta-3.messagelabs.com id
	2D/0F-10367-68142215; Mon, 18 Feb 2013 14:58:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361199482!21843212!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7204 invoked from network); 18 Feb 2013 14:58:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8004510"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:58:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:58:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SAL-0003uJ-3L;
	Mon, 18 Feb 2013 14:58:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <konrad.wilk@oracle.com>
Date: Mon, 18 Feb 2013 14:57:58 +0000
Message-ID: <1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to irq
	fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/evtchn.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b1f60a0..b2db77e 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 				       u->name, (void *)(unsigned long)port);
 	if (rc >= 0)
 		rc = evtchn_make_refcounted(port);
+	else {
+		/* bind failed, should close the port now */
+		struct evtchn_close close;
+		close.port = port;
+		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
+			BUG();
+		set_port_user(port, NULL);
+	}
 
 	return rc;
 }
@@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
 {
 	int irq = irq_from_evtchn(port);
 
+	BUG_ON(irq < 0);
+
 	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
 
 	set_port_user(port, NULL);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:58:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7SAa-0008J5-HX; Mon, 18 Feb 2013 14:58:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7SAZ-0008Ip-5C
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:58:15 +0000
Received: from [85.158.137.99:7876] by server-7.bemta-3.messagelabs.com id
	2D/0F-10367-68142215; Mon, 18 Feb 2013 14:58:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361199482!21843212!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7204 invoked from network); 18 Feb 2013 14:58:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8004510"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:58:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:58:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SAL-0003uJ-3L;
	Mon, 18 Feb 2013 14:58:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <konrad.wilk@oracle.com>
Date: Mon, 18 Feb 2013 14:57:58 +0000
Message-ID: <1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to irq
	fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 drivers/xen/evtchn.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b1f60a0..b2db77e 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 				       u->name, (void *)(unsigned long)port);
 	if (rc >= 0)
 		rc = evtchn_make_refcounted(port);
+	else {
+		/* bind failed, should close the port now */
+		struct evtchn_close close;
+		close.port = port;
+		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
+			BUG();
+		set_port_user(port, NULL);
+	}
 
 	return rc;
 }
@@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
 {
 	int irq = irq_from_evtchn(port);
 
+	BUG_ON(irq < 0);
+
 	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
 
 	set_port_user(port, NULL);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:58:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14:58: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 1U7SAb-0008JK-Tb; Mon, 18 Feb 2013 14:58:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7SAa-0008J2-MK
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:58:16 +0000
Received: from [85.158.137.99:11999] by server-15.bemta-3.messagelabs.com id
	D0/C2-25405-78142215; Mon, 18 Feb 2013 14:58:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361199482!21843212!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7261 invoked from network); 18 Feb 2013 14:58:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8004511"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:58:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:58:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SAL-0003uJ-3s;
	Mon, 18 Feb 2013 14:58:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <konrad.wilk@oracle.com>
Date: Mon, 18 Feb 2013 14:57:59 +0000
Message-ID: <1361199479-26059-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] xen-evtchn: correct comment and error 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

The evtchn device has been moved to /dev/xen. Also change log level to
KERN_ERR as other xen drivers.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/evtchn.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b2db77e..45c8efa 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -544,10 +544,10 @@ static int __init evtchn_init(void)
 
 	spin_lock_init(&port_user_lock);
 
-	/* Create '/dev/misc/evtchn'. */
+	/* Create '/dev/xen/evtchn'. */
 	err = misc_register(&evtchn_miscdev);
 	if (err != 0) {
-		printk(KERN_ALERT "Could not register /dev/misc/evtchn\n");
+		printk(KERN_ERR "Could not register /dev/xen/evtchn\n");
 		return err;
 	}
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:58:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14:58: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 1U7SAb-0008JK-Tb; Mon, 18 Feb 2013 14:58:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7SAa-0008J2-MK
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:58:16 +0000
Received: from [85.158.137.99:11999] by server-15.bemta-3.messagelabs.com id
	D0/C2-25405-78142215; Mon, 18 Feb 2013 14:58:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361199482!21843212!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7261 invoked from network); 18 Feb 2013 14:58:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8004511"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 14:58:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 09:58:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SAL-0003uJ-3s;
	Mon, 18 Feb 2013 14:58:01 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <konrad.wilk@oracle.com>
Date: Mon, 18 Feb 2013 14:57:59 +0000
Message-ID: <1361199479-26059-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] xen-evtchn: correct comment and error 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

The evtchn device has been moved to /dev/xen. Also change log level to
KERN_ERR as other xen drivers.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/xen/evtchn.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b2db77e..45c8efa 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -544,10 +544,10 @@ static int __init evtchn_init(void)
 
 	spin_lock_init(&port_user_lock);
 
-	/* Create '/dev/misc/evtchn'. */
+	/* Create '/dev/xen/evtchn'. */
 	err = misc_register(&evtchn_miscdev);
 	if (err != 0) {
-		printk(KERN_ALERT "Could not register /dev/misc/evtchn\n");
+		printk(KERN_ERR "Could not register /dev/xen/evtchn\n");
 		return err;
 	}
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:59:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7SBU-0008TA-Cg; Mon, 18 Feb 2013 14:59:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1U7SBT-0008Ss-8p
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:59:11 +0000
Received: from [85.158.139.211:61092] by server-16.bemta-5.messagelabs.com id
	16/5A-14948-EB142215; Mon, 18 Feb 2013 14:59:10 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361199548!16565582!1
X-Originating-IP: [209.85.210.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18748 invoked from network); 18 Feb 2013 14:59:09 -0000
Received: from mail-ia0-f181.google.com (HELO mail-ia0-f181.google.com)
	(209.85.210.181)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:59:09 -0000
Received: by mail-ia0-f181.google.com with SMTP id e16so4896468iaa.26
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:59:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=Lf6lBUxdAdCvHf7+CjbOFYQInzyaiKuJxv5JLRL9q6M=;
	b=QVJj5v8EzFBqvw2Pu+/5bBUn2W6oW0Ai9OLPB056vI2aOMV4rcWCtPaMxPrccGFBsR
	qr4qqkl6L8TjgUouIjpVA+cEq0iSz4PJb9VFGjXQipwcTmq3Q9TWxKk4w80G26h9Wr8n
	zlilWfrP8fRpjKsAitFBeLqMkBAUr9P8uDImo8UEnMqERbZ2uAiRW8XIftgKZGVn8lbq
	KTdFKEUI0jegTre1X+5t3Mp7EdxCZvLrIm78OLR6kcYItCbsGDqx2Y3wA6hj9K50AZ+w
	eybveQSWbEOkFlK7ewAK++W9OM2cyZbCnOVDIxfTxSDKprLhqx4dcQa6rxTjs0/0cA34
	g4AQ==
X-Received: by 10.50.207.39 with SMTP id lt7mr3272834igc.110.1361199547508;
	Mon, 18 Feb 2013 06:59:07 -0800 (PST)
Received: from [192.168.1.101] (69-165-137-14.dsl.teksavvy.com.
	[69.165.137.14])
	by mx.google.com with ESMTPS id dy5sm3268906igc.1.2013.02.18.06.59.04
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 06:59:06 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.7.1361188802.4771.xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 09:59:08 -0500
Message-Id: <BCDEBE79-EDFC-4BB1-9BBB-3E342847E480@gridcentric.ca>
References: <mailman.7.1361188802.4771.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org,
 "Tim (Xen.org)" <tim@xen.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlULk+mq3zuF5FouCiRQ0jIPL3iGGwk8EUmarP0LA5LQs6gtpEB2i9jgX/AGbqovbabgeuM
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Sylvain Munaut <s.munaut@whatever-company.com>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 96, Issue 249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, 
> 
> Thanks for the report. 
> 
> At 11:47 +0100 on 18 Feb (1361188042), Sylvain Munaut wrote:
>> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
>> and when trying to run a HVM VM (that I was previously running with
>> the official xen 4.0 package on squeeze), it starts fine and I can
>> even use the VM for a few minutes then suddenly I loose all
>> communication with VM and the Dom0 and it just reboots ...
> 
> Did you make any changes to Xen before you built it, or were you just
> building your own to get 4.2?
> 
>> (XEN) mm locking order violation: 260 > 222
>> (XEN) Xen BUG at mm-locks.h:118
> 
> Hmm, taking the p2m lock with the pod lock held. :( My guess would be
> the p2m_lock() in p2m_pod_emergency_sweep().
> 
> Do you by any chance have the xen-syms file from when you built Xen?
> That would let us see exactly what's happened.
> 
> In the meantime, perhaps you could try the attached (untested) patch.
> If my guess is right, it ought to stop the crashes but you might find
> the VM's performance suffers.
> 
> Cheers,
> 
> Tim.
> 
>> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
>> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
>> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
>> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
>> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
>> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
>> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
>> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
>> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
>> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
>> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
>> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
>> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
>> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
> -------------- next part --------------
> diff -r 4efc7f87d749 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 14 17:07:41 2013 +0000
> +++ b/xen/arch/x86/mm/p2m.c	Mon Feb 18 11:32:44 2013 +0000
> @@ -219,7 +219,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
>     }
> 
>     /* For now only perform locking on hap domains */
Yeah, this is what I mean. For tree inclusion, the comment has to be updated as well.
Thanks
Andres
> -    if ( locked && (hap_enabled(p2m->domain)) )
> +    if ( locked )
>         /* Grab the lock here, don't release until put_gfn */
>         gfn_lock(p2m, gfn, 0);
> 
> @@ -248,8 +248,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
> 
> 
> End of Xen-devel Digest, Vol 96, Issue 249
> ******************************************


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 14:59:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 14: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 1U7SBU-0008TA-Cg; Mon, 18 Feb 2013 14:59:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1U7SBT-0008Ss-8p
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 14:59:11 +0000
Received: from [85.158.139.211:61092] by server-16.bemta-5.messagelabs.com id
	16/5A-14948-EB142215; Mon, 18 Feb 2013 14:59:10 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361199548!16565582!1
X-Originating-IP: [209.85.210.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18748 invoked from network); 18 Feb 2013 14:59:09 -0000
Received: from mail-ia0-f181.google.com (HELO mail-ia0-f181.google.com)
	(209.85.210.181)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 14:59:09 -0000
Received: by mail-ia0-f181.google.com with SMTP id e16so4896468iaa.26
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 06:59:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=Lf6lBUxdAdCvHf7+CjbOFYQInzyaiKuJxv5JLRL9q6M=;
	b=QVJj5v8EzFBqvw2Pu+/5bBUn2W6oW0Ai9OLPB056vI2aOMV4rcWCtPaMxPrccGFBsR
	qr4qqkl6L8TjgUouIjpVA+cEq0iSz4PJb9VFGjXQipwcTmq3Q9TWxKk4w80G26h9Wr8n
	zlilWfrP8fRpjKsAitFBeLqMkBAUr9P8uDImo8UEnMqERbZ2uAiRW8XIftgKZGVn8lbq
	KTdFKEUI0jegTre1X+5t3Mp7EdxCZvLrIm78OLR6kcYItCbsGDqx2Y3wA6hj9K50AZ+w
	eybveQSWbEOkFlK7ewAK++W9OM2cyZbCnOVDIxfTxSDKprLhqx4dcQa6rxTjs0/0cA34
	g4AQ==
X-Received: by 10.50.207.39 with SMTP id lt7mr3272834igc.110.1361199547508;
	Mon, 18 Feb 2013 06:59:07 -0800 (PST)
Received: from [192.168.1.101] (69-165-137-14.dsl.teksavvy.com.
	[69.165.137.14])
	by mx.google.com with ESMTPS id dy5sm3268906igc.1.2013.02.18.06.59.04
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 06:59:06 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.7.1361188802.4771.xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 09:59:08 -0500
Message-Id: <BCDEBE79-EDFC-4BB1-9BBB-3E342847E480@gridcentric.ca>
References: <mailman.7.1361188802.4771.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org,
 "Tim (Xen.org)" <tim@xen.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlULk+mq3zuF5FouCiRQ0jIPL3iGGwk8EUmarP0LA5LQs6gtpEB2i9jgX/AGbqovbabgeuM
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Sylvain Munaut <s.munaut@whatever-company.com>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen-devel Digest, Vol 96, Issue 249
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, 
> 
> Thanks for the report. 
> 
> At 11:47 +0100 on 18 Feb (1361188042), Sylvain Munaut wrote:
>> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
>> and when trying to run a HVM VM (that I was previously running with
>> the official xen 4.0 package on squeeze), it starts fine and I can
>> even use the VM for a few minutes then suddenly I loose all
>> communication with VM and the Dom0 and it just reboots ...
> 
> Did you make any changes to Xen before you built it, or were you just
> building your own to get 4.2?
> 
>> (XEN) mm locking order violation: 260 > 222
>> (XEN) Xen BUG at mm-locks.h:118
> 
> Hmm, taking the p2m lock with the pod lock held. :( My guess would be
> the p2m_lock() in p2m_pod_emergency_sweep().
> 
> Do you by any chance have the xen-syms file from when you built Xen?
> That would let us see exactly what's happened.
> 
> In the meantime, perhaps you could try the attached (untested) patch.
> If my guess is right, it ought to stop the crashes but you might find
> the VM's performance suffers.
> 
> Cheers,
> 
> Tim.
> 
>> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
>> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
>> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
>> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
>> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
>> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
>> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
>> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
>> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
>> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
>> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
>> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
>> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
>> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
>> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
>> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
>> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea
> -------------- next part --------------
> diff -r 4efc7f87d749 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Feb 14 17:07:41 2013 +0000
> +++ b/xen/arch/x86/mm/p2m.c	Mon Feb 18 11:32:44 2013 +0000
> @@ -219,7 +219,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
>     }
> 
>     /* For now only perform locking on hap domains */
Yeah, this is what I mean. For tree inclusion, the comment has to be updated as well.
Thanks
Andres
> -    if ( locked && (hap_enabled(p2m->domain)) )
> +    if ( locked )
>         /* Grab the lock here, don't release until put_gfn */
>         gfn_lock(p2m, gfn, 0);
> 
> @@ -248,8 +248,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
> 
> 
> End of Xen-devel Digest, Vol 96, Issue 249
> ******************************************


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SDu-0000NO-2R; Mon, 18 Feb 2013 15:01: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 1U7SDs-0000ND-3K
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:01:40 +0000
Received: from [193.109.254.147:12456] by server-12.bemta-14.messagelabs.com
	id 31/89-32582-35242215; Mon, 18 Feb 2013 15:01:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361199691!8677203!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29233 invoked from network); 18 Feb 2013 15:01:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:01:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1574970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:01: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.297.1;
	Mon, 18 Feb 2013 15:01:31 +0000
Message-ID: <1361199689.32047.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 15:01:29 +0000
In-Reply-To: <alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > >  {
> > >      struct vtimer *t = data;
> > >      t->ctl |= CNTx_CTL_PENDING;
> > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > 
> > Thinking about the previous discussion about exposing the change of the
> > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > actually represent the state of the underlying physical mask bit, since
> > we do emulate accesses after all.
> 
> Sure. However this change still makes sense: if the guest masked the
> timer (no matter how we internally represent it), we should not inject
> an interrupt.

Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
also, it should be set only when the guest masks the interrupt.


> 
> 
> > >  }
> > >  
> > >  static void virt_timer_expired(void *data)
> > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > >  }
> > >   
> > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > +{
> > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > +}
> > > +
> > > +int __init init_ptimer(void)
> > > +{
> > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > +    return 0;
> > > +}
> > > +
> > >  int vcpu_vtimer_init(struct vcpu *v)
> > >  {
> > >      struct vtimer *t = &v->arch.phys_timer;
> > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > >          {
> > >              v->arch.phys_timer.ctl = *r;
> > >  
> > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > 
> > Why does PENDING matter here and below?
> 
> Doing tests on the physical hardware to better understand its behaviour,
> I noticed that the pending bit gets set even if the timer is masked
> (and therefore no interrupt is asserted).

The manual says that the pending bit (which the newer docs call
"istatus") is the interrupt status before masking, so this statement
doesn't really make sense in that context because "even if the timer is
masked" doesn't really mean anything given that, since this bit is only
really useful when the interrupt is masked.

if there are discrepancies between the hardware and the documentation
(which is on the confusing side in this case, although the newest doc is
better) it would probably be better to get ARM to clarify than to guess
what the behaviour is suppose to be.

> However if the pending bit is already set there is no point for us to
> try to set it again, so we skip setting the internal Xen timer.

I have a feeling this is only true because we incorrectly set the
pending bit in phys_timer_expired().

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SDu-0000NO-2R; Mon, 18 Feb 2013 15:01: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 1U7SDs-0000ND-3K
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:01:40 +0000
Received: from [193.109.254.147:12456] by server-12.bemta-14.messagelabs.com
	id 31/89-32582-35242215; Mon, 18 Feb 2013 15:01:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361199691!8677203!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29233 invoked from network); 18 Feb 2013 15:01:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:01:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1574970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:01: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.297.1;
	Mon, 18 Feb 2013 15:01:31 +0000
Message-ID: <1361199689.32047.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 15:01:29 +0000
In-Reply-To: <alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > >  {
> > >      struct vtimer *t = data;
> > >      t->ctl |= CNTx_CTL_PENDING;
> > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > 
> > Thinking about the previous discussion about exposing the change of the
> > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > actually represent the state of the underlying physical mask bit, since
> > we do emulate accesses after all.
> 
> Sure. However this change still makes sense: if the guest masked the
> timer (no matter how we internally represent it), we should not inject
> an interrupt.

Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
also, it should be set only when the guest masks the interrupt.


> 
> 
> > >  }
> > >  
> > >  static void virt_timer_expired(void *data)
> > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > >  }
> > >   
> > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > +{
> > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > +}
> > > +
> > > +int __init init_ptimer(void)
> > > +{
> > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > +    return 0;
> > > +}
> > > +
> > >  int vcpu_vtimer_init(struct vcpu *v)
> > >  {
> > >      struct vtimer *t = &v->arch.phys_timer;
> > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > >          {
> > >              v->arch.phys_timer.ctl = *r;
> > >  
> > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > 
> > Why does PENDING matter here and below?
> 
> Doing tests on the physical hardware to better understand its behaviour,
> I noticed that the pending bit gets set even if the timer is masked
> (and therefore no interrupt is asserted).

The manual says that the pending bit (which the newer docs call
"istatus") is the interrupt status before masking, so this statement
doesn't really make sense in that context because "even if the timer is
masked" doesn't really mean anything given that, since this bit is only
really useful when the interrupt is masked.

if there are discrepancies between the hardware and the documentation
(which is on the confusing side in this case, although the newest doc is
better) it would probably be better to get ARM to clarify than to guess
what the behaviour is suppose to be.

> However if the pending bit is already set there is no point for us to
> try to set it again, so we skip setting the internal Xen timer.

I have a feeling this is only true because we incorrectly set the
pending bit in phys_timer_expired().

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:04:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SGg-0000dS-Rq; Mon, 18 Feb 2013 15:04: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 1U7SGf-0000dB-Pm
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:04:34 +0000
Received: from [85.158.139.83:20438] by server-12.bemta-5.messagelabs.com id
	9F/C3-20195-FF242215; Mon, 18 Feb 2013 15:04:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361199866!16514031!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13377 invoked from network); 18 Feb 2013 15:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1575023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:02: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.297.1;
	Mon, 18 Feb 2013 15:02:57 +0000
Message-ID: <1361199775.32047.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Date: Mon, 18 Feb 2013 15:02:55 +0000
In-Reply-To: <CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 13:17 +0000, Sylvain Munaut wrote:

> > Please can you share the domain configuration. Are you running PV
> > drivers (esp. ballooning) within it?
> 
> There is no xen driver running in there.
> 
> Here's the config which is based on the example hvm config:
> 
> ---------
> builder = "hvm"
> name   = "wxp-00"
> vcpus = 2
> memory = 1536
> maxmem = 2048


This is the cause of your second "Dom1 out of PoD memory" bug.

If you aren't running at least a balloon driver inside the guest then
this isn't valid, since you have requested a different initial memory
allocation to what you are actually giving the guest and something needs
to bridge that gap. Initially this is PoD but eventually a balloon
driver must come along, PoD is not intended for use other than during
boot until a balloon driver can be started.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:04:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SGg-0000dS-Rq; Mon, 18 Feb 2013 15:04: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 1U7SGf-0000dB-Pm
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:04:34 +0000
Received: from [85.158.139.83:20438] by server-12.bemta-5.messagelabs.com id
	9F/C3-20195-FF242215; Mon, 18 Feb 2013 15:04:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361199866!16514031!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13377 invoked from network); 18 Feb 2013 15:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1575023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:02: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.297.1;
	Mon, 18 Feb 2013 15:02:57 +0000
Message-ID: <1361199775.32047.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Date: Mon, 18 Feb 2013 15:02:55 +0000
In-Reply-To: <CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 13:17 +0000, Sylvain Munaut wrote:

> > Please can you share the domain configuration. Are you running PV
> > drivers (esp. ballooning) within it?
> 
> There is no xen driver running in there.
> 
> Here's the config which is based on the example hvm config:
> 
> ---------
> builder = "hvm"
> name   = "wxp-00"
> vcpus = 2
> memory = 1536
> maxmem = 2048


This is the cause of your second "Dom1 out of PoD memory" bug.

If you aren't running at least a balloon driver inside the guest then
this isn't valid, since you have requested a different initial memory
allocation to what you are actually giving the guest and something needs
to bridge that gap. Initially this is PoD but eventually a balloon
driver must come along, PoD is not intended for use other than during
boot until a balloon driver can be started.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:18:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:18: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 1U7SUI-00012p-TL; Mon, 18 Feb 2013 15:18:38 +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 1U7SUG-00012Q-PH; Mon, 18 Feb 2013 15:18:36 +0000
Received: from [193.109.254.147:60744] by server-10.bemta-14.messagelabs.com
	id B5/1A-12679-B4642215; Mon, 18 Feb 2013 15:18:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361200455!8799605!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7906 invoked from network); 18 Feb 2013 15:14:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:14:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8008026"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:14:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:14:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SQ1-0004CI-U7;
	Mon, 18 Feb 2013 15:14:13 +0000
Message-ID: <1361200453.3825.19.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	<xen-api@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	<xen-arm@lists.xen.org>
Date: Mon, 18 Feb 2013 15:14:13 +0000
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>, wei.liu2@citrix.com
Subject: [Xen-devel] Xen Document Day: Feb 25th,
	2013 on IRC freenode #xendocs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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

A quick reminder that the next Xen Document Day is happening next Monday
(Feb 25). More info on document days at

http://wiki.xen.org/wiki/Xen_Document_Days

Hope to see you on IRC! Feel free to add stuff to the TODO
list(http://wiki.xen.org/wiki/Xen_Document_Days/TODO) or put your name
besides an item if you intend to work on it.


Best Regards
Wei.


********************* 
* Xen Document Days * 
********************* 

We have another Xen document day come up next Monday. Xen Document Days
are for people who care about Xen Documentation and want to improve it.
We introduced Documentation Days, because working on documentation in
parallel with like minded-people, is just more fun than working alone!
Everybody who can contribute is welcome to join! 

For a list of items that need work, check out the community maintained
TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course,
you can work on anything you like: the list just provides suggestions. 

How do I participate? 
===================== 

- Join us on IRC: freenode channel #xendocs 
- 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!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:18:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:18: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 1U7SUI-00012p-TL; Mon, 18 Feb 2013 15:18:38 +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 1U7SUG-00012Q-PH; Mon, 18 Feb 2013 15:18:36 +0000
Received: from [193.109.254.147:60744] by server-10.bemta-14.messagelabs.com
	id B5/1A-12679-B4642215; Mon, 18 Feb 2013 15:18:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361200455!8799605!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7906 invoked from network); 18 Feb 2013 15:14:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:14:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8008026"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:14:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:14:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7SQ1-0004CI-U7;
	Mon, 18 Feb 2013 15:14:13 +0000
Message-ID: <1361200453.3825.19.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	<xen-api@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	<xen-arm@lists.xen.org>
Date: Mon, 18 Feb 2013 15:14:13 +0000
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>, wei.liu2@citrix.com
Subject: [Xen-devel] Xen Document Day: Feb 25th,
	2013 on IRC freenode #xendocs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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

A quick reminder that the next Xen Document Day is happening next Monday
(Feb 25). More info on document days at

http://wiki.xen.org/wiki/Xen_Document_Days

Hope to see you on IRC! Feel free to add stuff to the TODO
list(http://wiki.xen.org/wiki/Xen_Document_Days/TODO) or put your name
besides an item if you intend to work on it.


Best Regards
Wei.


********************* 
* Xen Document Days * 
********************* 

We have another Xen document day come up next Monday. Xen Document Days
are for people who care about Xen Documentation and want to improve it.
We introduced Documentation Days, because working on documentation in
parallel with like minded-people, is just more fun than working alone!
Everybody who can contribute is welcome to join! 

For a list of items that need work, check out the community maintained
TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course,
you can work on anything you like: the list just provides suggestions. 

How do I participate? 
===================== 

- Join us on IRC: freenode channel #xendocs 
- 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!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:19:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7SV8-0001BH-1X; Mon, 18 Feb 2013 15:19: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 1U7SV6-0001Ak-SX
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:19:28 +0000
Received: from [85.158.143.99:18812] by server-1.bemta-4.messagelabs.com id
	9E/34-08839-08642215; Mon, 18 Feb 2013 15:19:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361200767!18245624!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2531 invoked from network); 18 Feb 2013 15:19:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:19:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1575797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:19: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.297.1;
	Mon, 18 Feb 2013 15:19:27 +0000
Message-ID: <1361200766.1051.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 18 Feb 2013 15:19:26 +0000
In-Reply-To: <511E46FD.3010605@citrix.com>
References: <511E46FD.3010605@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> Except for a lack of information of the required memory barriers (to be
> included in draft C), this should now be completely enough to start on a
> prototype (any volunteers? ;).

I think the real question is whether you as creator of the design are
going to be working on the implementation. That would the usual
progression of things.

As I see it we have on the one hand a substantially complete
implementation of one solution and a design draft of the other with
nobody signed up to even implement a prototype at the moment.

Given that I think we should surely go with the available solution for
4.3, which does meet our current needs AFAICT (most of the stuff which
the other design adds is gravy AFAICT). If something better comes along
(be that the FIFO design or something else) in the future then we can
consider it on its merits 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 Feb 18 15:19:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 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 1U7SV8-0001BH-1X; Mon, 18 Feb 2013 15:19: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 1U7SV6-0001Ak-SX
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:19:28 +0000
Received: from [85.158.143.99:18812] by server-1.bemta-4.messagelabs.com id
	9E/34-08839-08642215; Mon, 18 Feb 2013 15:19:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361200767!18245624!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2531 invoked from network); 18 Feb 2013 15:19:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:19:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1575797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:19: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.297.1;
	Mon, 18 Feb 2013 15:19:27 +0000
Message-ID: <1361200766.1051.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 18 Feb 2013 15:19:26 +0000
In-Reply-To: <511E46FD.3010605@citrix.com>
References: <511E46FD.3010605@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> Except for a lack of information of the required memory barriers (to be
> included in draft C), this should now be completely enough to start on a
> prototype (any volunteers? ;).

I think the real question is whether you as creator of the design are
going to be working on the implementation. That would the usual
progression of things.

As I see it we have on the one hand a substantially complete
implementation of one solution and a design draft of the other with
nobody signed up to even implement a prototype at the moment.

Given that I think we should surely go with the available solution for
4.3, which does meet our current needs AFAICT (most of the stuff which
the other design adds is gravy AFAICT). If something better comes along
(be that the FIFO design or something else) in the future then we can
consider it on its merits 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 Feb 18 15:20:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:20: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 1U7SVy-0001Jz-Ge; Mon, 18 Feb 2013 15:20: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 1U7SVx-0001Jm-NI
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:21 +0000
Received: from [85.158.143.99:24593] by server-3.bemta-4.messagelabs.com id
	D7/5B-08920-5B642215; Mon, 18 Feb 2013 15:20:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361200819!27988694!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9258 invoked from network); 18 Feb 2013 15:20:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:20:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1575824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:20: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.297.1;
	Mon, 18 Feb 2013 15:20:19 +0000
Message-ID: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:18 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/4 V7] xen: arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Not much has changed here since v6.

Other than rebasing I've used the hypervisor version in
the /hypervisor/compatibility string and added an assert that we aren't
skipping levels in xen/arch/arm/domain_build.c:write_nodes

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:20: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 1U7SVy-0001Jz-Ge; Mon, 18 Feb 2013 15:20: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 1U7SVx-0001Jm-NI
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:21 +0000
Received: from [85.158.143.99:24593] by server-3.bemta-4.messagelabs.com id
	D7/5B-08920-5B642215; Mon, 18 Feb 2013 15:20:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361200819!27988694!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9258 invoked from network); 18 Feb 2013 15:20:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:20:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1575824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:20: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.297.1;
	Mon, 18 Feb 2013 15:20:19 +0000
Message-ID: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:18 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/4 V7] xen: arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Not much has changed here since v6.

Other than rebasing I've used the hypervisor version in
the /hypervisor/compatibility string and added an assert that we aren't
skipping levels in xen/arch/arm/domain_build.c:write_nodes

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:20: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 1U7SWH-0001Nn-Ub; Mon, 18 Feb 2013 15:20:41 +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 1U7SWG-0001NK-Kn
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:40 +0000
Received: from [193.109.254.147:34985] by server-13.bemta-14.messagelabs.com
	id 25/C3-30639-8C642215; Mon, 18 Feb 2013 15:20:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361200837!6376206!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7600 invoked from network); 18 Feb 2013 15:20:39 -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;
	18 Feb 2013 15:20:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8009620"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-IT;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:33 +0000
Message-ID: <1361200836-14481-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 1/4] dtb: correct handling of #address-cells
	and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a node does not have #*-cells then the parent's value should be
used. Currently we were asssuming zero which is useless.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v7: assert we don't skip any levels in the tree
---
 xen/arch/arm/domain_build.c   |    9 +++++++--
 xen/common/device_tree.c      |   12 ++++++++----
 xen/include/xen/device_tree.h |    3 ++-
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7403f1a..9ce661b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -195,11 +195,16 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
             continue;
         }
 
+        /* We cannot handle descending more than one level at a time */
+        ASSERT( depth <= last_depth + 1 );
+
         while ( last_depth-- >= depth )
             fdt_end_node(kinfo->fdt);
 
-        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
-        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
+                                    depth > 0 ? address_cells[depth-1] : 0);
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
+                                    depth > 0 ? size_cells[depth-1] : 0);
 
         fdt_begin_node(kinfo->fdt, name);
 
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 5301d63..f3d3aa1 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
     set_val(cell, size_cells, size);
 }
 
-u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
+                        u32 dflt)
 {
     const struct fdt_property *prop;
 
     prop = fdt_get_property(fdt, node, prop_name, NULL);
     if ( !prop || prop->len < sizeof(u32) )
-        return 0; /* default to 0 */
+        return dflt;
 
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
@@ -164,8 +165,11 @@ int device_tree_for_each_node(const void *fdt,
             continue;
         }
 
-        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
-        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
+                                depth > 0 ? address_cells[depth-1] : 0);
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
+                                depth > 0 ? size_cells[depth-1] : 0);
+
 
         ret = func(fdt, node, name, depth,
                    address_cells[depth-1], size_cells[depth-1], data);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 1d04e4f..19bda98 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -66,7 +66,8 @@ 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);
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
+			u32 dflt);
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 bool_t device_tree_node_compatible(const void *fdt, int node, const char *match);
 int find_compatible_node(const char *compatible, int *node, int *depth,
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:20: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 1U7SWH-0001Nn-Ub; Mon, 18 Feb 2013 15:20:41 +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 1U7SWG-0001NK-Kn
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:40 +0000
Received: from [193.109.254.147:34985] by server-13.bemta-14.messagelabs.com
	id 25/C3-30639-8C642215; Mon, 18 Feb 2013 15:20:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361200837!6376206!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7600 invoked from network); 18 Feb 2013 15:20:39 -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;
	18 Feb 2013 15:20:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8009620"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-IT;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:33 +0000
Message-ID: <1361200836-14481-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 1/4] dtb: correct handling of #address-cells
	and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a node does not have #*-cells then the parent's value should be
used. Currently we were asssuming zero which is useless.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v7: assert we don't skip any levels in the tree
---
 xen/arch/arm/domain_build.c   |    9 +++++++--
 xen/common/device_tree.c      |   12 ++++++++----
 xen/include/xen/device_tree.h |    3 ++-
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7403f1a..9ce661b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -195,11 +195,16 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
             continue;
         }
 
+        /* We cannot handle descending more than one level at a time */
+        ASSERT( depth <= last_depth + 1 );
+
         while ( last_depth-- >= depth )
             fdt_end_node(kinfo->fdt);
 
-        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
-        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
+                                    depth > 0 ? address_cells[depth-1] : 0);
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
+                                    depth > 0 ? size_cells[depth-1] : 0);
 
         fdt_begin_node(kinfo->fdt, name);
 
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 5301d63..f3d3aa1 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
     set_val(cell, size_cells, size);
 }
 
-u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
+                        u32 dflt)
 {
     const struct fdt_property *prop;
 
     prop = fdt_get_property(fdt, node, prop_name, NULL);
     if ( !prop || prop->len < sizeof(u32) )
-        return 0; /* default to 0 */
+        return dflt;
 
     return fdt32_to_cpu(*(uint32_t*)prop->data);
 }
@@ -164,8 +165,11 @@ int device_tree_for_each_node(const void *fdt,
             continue;
         }
 
-        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
-        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
+        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
+                                depth > 0 ? address_cells[depth-1] : 0);
+        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
+                                depth > 0 ? size_cells[depth-1] : 0);
+
 
         ret = func(fdt, node, name, depth,
                    address_cells[depth-1], size_cells[depth-1], data);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 1d04e4f..19bda98 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -66,7 +66,8 @@ 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);
+u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
+			u32 dflt);
 bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 bool_t device_tree_node_compatible(const void *fdt, int node, const char *match);
 int find_compatible_node(const char *compatible, int *node, int *depth,
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SWJ-0001OL-CF; Mon, 18 Feb 2013 15:20:43 +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 1U7SWH-0001NK-Mi
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:41 +0000
Received: from [193.109.254.147:15136] by server-13.bemta-14.messagelabs.com
	id 7E/C3-30639-9C642215; Mon, 18 Feb 2013 15:20:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361200837!6376206!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7791 invoked from network); 18 Feb 2013 15:20:40 -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;
	18 Feb 2013 15:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8009622"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-KH;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:34 +0000
Message-ID: <1361200836-14481-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 2/4] xen: arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bootloader should populate /chosen/modules/module@<N>/ for each
module it wishes to pass to the hypervisor. The content of these nodes
is described in docs/misc/arm/device-tree/booting.txt

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v6: Match based on compatibility instead of path
v5: Moved later in the series
v4: Use /chosen/modules/module@N
    Identify module type by compatible property not number.
v3: Use a reg = < > property for the module address/length.
v2: Reserve the zeroeth module for Xen itself (not used yet)
    Use a more idiomatic DT layout
    Document said layout
---
 docs/misc/arm/device-tree/booting.txt |   25 +++++++++++++++
 xen/common/device_tree.c              |   54 ++++++++++++++++++++++++++++++++-
 2 files changed, 78 insertions(+), 1 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/booting.txt

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
new file mode 100644
index 0000000..94cd3f1
--- /dev/null
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -0,0 +1,25 @@
+Xen is passed the dom0 kernel and initrd via a reference in the /chosen
+node of the device tree.
+
+Each node has the form /chosen/modules/module@<N> and contains the following
+properties:
+
+- compatible
+
+	Must be:
+
+		"xen,<type>", "xen,multiboot-module"
+
+	where <type> must be one of:
+
+	- "linux-zimage" -- the dom0 kernel
+	- "linux-initrd" -- the dom0 ramdisk
+
+- reg
+
+	Specifies the physical address of the module in RAM and the
+	length of the module.
+
+- bootargs (optional)
+
+	Command line associated with this module
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f3d3aa1..c1830a6 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -393,6 +393,48 @@ static void __init process_gic_node(const void *fdt, int node,
     early_info.gic.gic_vcpu_addr = start;
 }
 
+static void __init process_multiboot_node(const void *fdt, int node,
+                                          const char *name,
+                                          u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    const u32 *cell;
+    int nr;
+    struct dt_mb_module *mod;
+    int len;
+
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
+        nr = 1;
+    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0)
+        nr = 2;
+    else
+        early_panic("%s not a known xen multiboot type\n", name);
+
+    mod = &early_info.modules.module[nr];
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if ( !prop )
+        early_panic("node %s missing `reg' property\n", name);
+
+    cell = (const u32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells,
+                        &mod->start, &mod->size);
+
+    prop = fdt_get_property(fdt, node, "bootargs", &len);
+    if ( prop )
+    {
+        if ( len > sizeof(mod->cmdline) )
+            early_panic("module %d command line too long\n", nr);
+
+        safe_strcpy(mod->cmdline, prop->data);
+    }
+    else
+        mod->cmdline[0] = 0;
+
+    if ( nr > early_info.modules.nr_mods )
+        early_info.modules.nr_mods = nr;
+}
+
 static int __init early_scan_node(const void *fdt,
                                   int node, const char *name, int depth,
                                   u32 address_cells, u32 size_cells,
@@ -404,6 +446,8 @@ static int __init early_scan_node(const void *fdt,
         process_cpu_node(fdt, node, name, address_cells, size_cells);
     else if ( device_tree_node_compatible(fdt, node, "arm,cortex-a15-gic") )
         process_gic_node(fdt, node, name, address_cells, size_cells);
+    else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) )
+        process_multiboot_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
 }
@@ -411,12 +455,20 @@ static int __init early_scan_node(const void *fdt,
 static void __init early_print_info(void)
 {
     struct dt_mem_info *mi = &early_info.mem;
+    struct dt_module_info *mods = &early_info.modules;
     int i;
 
     for ( i = 0; i < mi->nr_banks; i++ )
-        early_printk("RAM: %016llx - %016llx\n",
+        early_printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
                      mi->bank[i].start,
                      mi->bank[i].start + mi->bank[i].size - 1);
+    early_printk("\n");
+    for ( i = 1 ; i < mods->nr_mods + 1; i++ )
+        early_printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %s\n",
+                     i,
+                     mods->module[i].start,
+                     mods->module[i].start + mods->module[i].size,
+                     mods->module[i].cmdline);
 }
 
 /**
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SWJ-0001OL-CF; Mon, 18 Feb 2013 15:20:43 +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 1U7SWH-0001NK-Mi
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:41 +0000
Received: from [193.109.254.147:15136] by server-13.bemta-14.messagelabs.com
	id 7E/C3-30639-9C642215; Mon, 18 Feb 2013 15:20:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361200837!6376206!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7791 invoked from network); 18 Feb 2013 15:20:40 -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;
	18 Feb 2013 15:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8009622"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-KH;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:34 +0000
Message-ID: <1361200836-14481-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 2/4] xen: arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 bootloader should populate /chosen/modules/module@<N>/ for each
module it wishes to pass to the hypervisor. The content of these nodes
is described in docs/misc/arm/device-tree/booting.txt

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v6: Match based on compatibility instead of path
v5: Moved later in the series
v4: Use /chosen/modules/module@N
    Identify module type by compatible property not number.
v3: Use a reg = < > property for the module address/length.
v2: Reserve the zeroeth module for Xen itself (not used yet)
    Use a more idiomatic DT layout
    Document said layout
---
 docs/misc/arm/device-tree/booting.txt |   25 +++++++++++++++
 xen/common/device_tree.c              |   54 ++++++++++++++++++++++++++++++++-
 2 files changed, 78 insertions(+), 1 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/booting.txt

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
new file mode 100644
index 0000000..94cd3f1
--- /dev/null
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -0,0 +1,25 @@
+Xen is passed the dom0 kernel and initrd via a reference in the /chosen
+node of the device tree.
+
+Each node has the form /chosen/modules/module@<N> and contains the following
+properties:
+
+- compatible
+
+	Must be:
+
+		"xen,<type>", "xen,multiboot-module"
+
+	where <type> must be one of:
+
+	- "linux-zimage" -- the dom0 kernel
+	- "linux-initrd" -- the dom0 ramdisk
+
+- reg
+
+	Specifies the physical address of the module in RAM and the
+	length of the module.
+
+- bootargs (optional)
+
+	Command line associated with this module
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f3d3aa1..c1830a6 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -393,6 +393,48 @@ static void __init process_gic_node(const void *fdt, int node,
     early_info.gic.gic_vcpu_addr = start;
 }
 
+static void __init process_multiboot_node(const void *fdt, int node,
+                                          const char *name,
+                                          u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    const u32 *cell;
+    int nr;
+    struct dt_mb_module *mod;
+    int len;
+
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
+        nr = 1;
+    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0)
+        nr = 2;
+    else
+        early_panic("%s not a known xen multiboot type\n", name);
+
+    mod = &early_info.modules.module[nr];
+
+    prop = fdt_get_property(fdt, node, "reg", NULL);
+    if ( !prop )
+        early_panic("node %s missing `reg' property\n", name);
+
+    cell = (const u32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells,
+                        &mod->start, &mod->size);
+
+    prop = fdt_get_property(fdt, node, "bootargs", &len);
+    if ( prop )
+    {
+        if ( len > sizeof(mod->cmdline) )
+            early_panic("module %d command line too long\n", nr);
+
+        safe_strcpy(mod->cmdline, prop->data);
+    }
+    else
+        mod->cmdline[0] = 0;
+
+    if ( nr > early_info.modules.nr_mods )
+        early_info.modules.nr_mods = nr;
+}
+
 static int __init early_scan_node(const void *fdt,
                                   int node, const char *name, int depth,
                                   u32 address_cells, u32 size_cells,
@@ -404,6 +446,8 @@ static int __init early_scan_node(const void *fdt,
         process_cpu_node(fdt, node, name, address_cells, size_cells);
     else if ( device_tree_node_compatible(fdt, node, "arm,cortex-a15-gic") )
         process_gic_node(fdt, node, name, address_cells, size_cells);
+    else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) )
+        process_multiboot_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
 }
@@ -411,12 +455,20 @@ static int __init early_scan_node(const void *fdt,
 static void __init early_print_info(void)
 {
     struct dt_mem_info *mi = &early_info.mem;
+    struct dt_module_info *mods = &early_info.modules;
     int i;
 
     for ( i = 0; i < mi->nr_banks; i++ )
-        early_printk("RAM: %016llx - %016llx\n",
+        early_printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
                      mi->bank[i].start,
                      mi->bank[i].start + mi->bank[i].size - 1);
+    early_printk("\n");
+    for ( i = 1 ; i < mods->nr_mods + 1; i++ )
+        early_printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %s\n",
+                     i,
+                     mods->module[i].start,
+                     mods->module[i].start + mods->module[i].size,
+                     mods->module[i].cmdline);
 }
 
 /**
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SWJ-0001OY-OB; Mon, 18 Feb 2013 15:20:43 +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 1U7SWH-0001Nb-Re
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:42 +0000
Received: from [193.109.254.147:15108] by server-4.bemta-14.messagelabs.com id
	BC/48-20719-8C642215; Mon, 18 Feb 2013 15:20:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361200837!6376206!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7695 invoked from network); 18 Feb 2013 15:20:39 -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;
	18 Feb 2013 15:20:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8009621"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-MG;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:35 +0000
Message-ID: <1361200836-14481-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 3/4] xen: strip xen,
	multiboot-module nodes from dom0 device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 nodes are used by Xen to find the initial modules.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v6 - filter based on compatibility node name and not path.
v4 - /chosen/modules/modules@N not /chosen/module@N
v3 - use a helper to filter out DT elements which are not for dom0.
     Better than an ad-hoc break in the middle of a loop.
---
 xen/arch/arm/domain_build.c |   32 ++++++++++++++++++++++++++++++--
 1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9ce661b..1c35c82 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -172,6 +172,33 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
     return prop;
 }
 
+/* Returns the next node in fdt (starting from offset) which should be
+ * passed through to dom0.
+ */
+static int fdt_next_dom0_node(const void *fdt, int node,
+                              int *depth_out)
+{
+    int depth = *depth_out;
+
+    while ( (node = fdt_next_node(fdt, node, &depth)) &&
+            node >= 0 && depth >= 0 )
+    {
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+            break;
+
+        /* Skip multiboot subnodes */
+        if ( fdt_node_check_compatible(fdt, node,
+                                       "xen,multiboot-module" ) == 0 )
+            continue;
+
+        /* We've arrived at a node which dom0 is interested in. */
+        break;
+    }
+
+    *depth_out = depth;
+    return node;
+}
+
 static int write_nodes(struct domain *d, struct kernel_info *kinfo,
                        const void *fdt)
 {
@@ -183,7 +210,7 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
 
     for ( node = 0, depth = 0;
           node >= 0 && depth >= 0;
-          node = fdt_next_node(fdt, node, &depth) )
+          node = fdt_next_dom0_node(fdt, node, &depth) )
     {
         const char *name;
 
@@ -191,7 +218,8 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
 
         if ( depth >= DEVICE_TREE_MAX_DEPTH )
         {
-            printk("warning: node `%s' is nested too deep\n", name);
+            printk("warning: node `%s' is nested too deep (%d)\n",
+                   name, depth);
             continue;
         }
 
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:20:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7SWJ-0001OY-OB; Mon, 18 Feb 2013 15:20:43 +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 1U7SWH-0001Nb-Re
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:42 +0000
Received: from [193.109.254.147:15108] by server-4.bemta-14.messagelabs.com id
	BC/48-20719-8C642215; Mon, 18 Feb 2013 15:20:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361200837!6376206!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7695 invoked from network); 18 Feb 2013 15:20:39 -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;
	18 Feb 2013 15:20:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8009621"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-MG;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:35 +0000
Message-ID: <1361200836-14481-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 3/4] xen: strip xen,
	multiboot-module nodes from dom0 device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 nodes are used by Xen to find the initial modules.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v6 - filter based on compatibility node name and not path.
v4 - /chosen/modules/modules@N not /chosen/module@N
v3 - use a helper to filter out DT elements which are not for dom0.
     Better than an ad-hoc break in the middle of a loop.
---
 xen/arch/arm/domain_build.c |   32 ++++++++++++++++++++++++++++++--
 1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9ce661b..1c35c82 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -172,6 +172,33 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
     return prop;
 }
 
+/* Returns the next node in fdt (starting from offset) which should be
+ * passed through to dom0.
+ */
+static int fdt_next_dom0_node(const void *fdt, int node,
+                              int *depth_out)
+{
+    int depth = *depth_out;
+
+    while ( (node = fdt_next_node(fdt, node, &depth)) &&
+            node >= 0 && depth >= 0 )
+    {
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+            break;
+
+        /* Skip multiboot subnodes */
+        if ( fdt_node_check_compatible(fdt, node,
+                                       "xen,multiboot-module" ) == 0 )
+            continue;
+
+        /* We've arrived at a node which dom0 is interested in. */
+        break;
+    }
+
+    *depth_out = depth;
+    return node;
+}
+
 static int write_nodes(struct domain *d, struct kernel_info *kinfo,
                        const void *fdt)
 {
@@ -183,7 +210,7 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
 
     for ( node = 0, depth = 0;
           node >= 0 && depth >= 0;
-          node = fdt_next_node(fdt, node, &depth) )
+          node = fdt_next_dom0_node(fdt, node, &depth) )
     {
         const char *name;
 
@@ -191,7 +218,8 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
 
         if ( depth >= DEVICE_TREE_MAX_DEPTH )
         {
-            printk("warning: node `%s' is nested too deep\n", name);
+            printk("warning: node `%s' is nested too deep (%d)\n",
+                   name, depth);
             continue;
         }
 
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:21:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:21: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 1U7SWX-0001U2-Cn; Mon, 18 Feb 2013 15:20:57 +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 1U7SWV-0001TI-Pl
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:56 +0000
Received: from [85.158.138.51:44363] by server-9.bemta-3.messagelabs.com id
	C4/72-09484-8C642215; Mon, 18 Feb 2013 15:20:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361200837!9362986!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8914 invoked from network); 18 Feb 2013 15:20:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:20:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7617335"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-PL;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:36 +0000
Message-ID: <1361200836-14481-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 4/4] xen: arm: create dom0 DTB /hypervisor/
	node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 initially added hypervisor-new and confirmed via /proc/device-model
that the content is the same before changing it to drop and replace
an existing node.

NB: There is an ambiguity in the compatibility property.
linux/arch/arm/boot/dts/xenvm-4.2.dts says "xen,xen-4.2" while
Documentation/devicetree/bindings/arm/xen.txt says "xen,xen-4.3".I have used
the actual hypervisor version as discussed in
http://marc.info/?l=xen-devel&m=135963416631423

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v7: Use Xen version in compatibility node.
---
 xen/arch/arm/domain_build.c |   57 +++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1c35c82..6efc36a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/init.h>
+#include <xen/compile.h>
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/domain_page.h>
@@ -34,7 +35,7 @@ custom_param("dom0_mem", parse_dom0_mem);
  * are added (yet) but one terminating reserve map entry (16 bytes) is
  * added.
  */
-#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
+#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
@@ -186,6 +187,13 @@ static int fdt_next_dom0_node(const void *fdt, int node,
         if ( depth >= DEVICE_TREE_MAX_DEPTH )
             break;
 
+        /* Skip /hypervisor/ node. We will inject our own. */
+        if ( fdt_node_check_compatible(fdt, node, "xen,xen" ) == 0 )
+        {
+            printk("Device-tree contains \"xen,xen\" node. Ignoring.\n");
+            continue;
+        }
+
         /* Skip multiboot subnodes */
         if ( fdt_node_check_compatible(fdt, node,
                                        "xen,multiboot-module" ) == 0 )
@@ -199,6 +207,48 @@ static int fdt_next_dom0_node(const void *fdt, int node,
     return node;
 }
 
+static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
+{
+    const char compat[] =
+        "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
+        "xen,xen";
+    u32 reg[4];
+    u32 intr[3];
+    u32 *cell;
+
+    /*
+     * Sanity-check address sizes, since addresses and sizes which do
+     * not take up exactly 4 or 8 bytes are not supported.
+     */
+    if ((addrcells != 1 && addrcells != 2) ||
+        (sizecells != 1 && sizecells != 2))
+        panic("Cannot cope with this size");
+
+    /* See linux Documentation/devicetree/bindings/arm/xen.txt */
+    fdt_begin_node(fdt, "hypervisor");
+
+    /* Cannot use fdt_property_string due to embedded nulls */
+    fdt_property(fdt, "compatible", compat, sizeof(compat) + 1);
+
+    /* reg 0 is grant table space */
+    cell = &reg[0];
+    device_tree_set_reg(&cell, addrcells, sizecells, 0xb0000000, 0x20000);
+    fdt_property(fdt, "reg", reg,
+                 sizeof(reg[0]) * (addrcells + sizecells));
+
+    /*
+     * interrupts is evtchn upcall  <1 15 0xf08>
+     * See linux Documentation/devicetree/bindings/arm/gic.txt
+     */
+    intr[0] = cpu_to_fdt32(1); /* is a PPI */
+    intr[1] = cpu_to_fdt32(VGIC_IRQ_EVTCHN_CALLBACK - 16); /* PPIs start at 16 */
+    intr[2] = cpu_to_fdt32(0xf08); /* Active-low level-sensitive */
+
+    fdt_property(fdt, "interrupts", intr, sizeof(intr[0]) * 3);
+
+    fdt_end_node(fdt);
+}
+
 static int write_nodes(struct domain *d, struct kernel_info *kinfo,
                        const void *fdt)
 {
@@ -244,9 +294,12 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
         last_depth = depth;
     }
 
-    while ( last_depth-- >= 0 )
+    while ( last_depth-- >= 1 )
         fdt_end_node(kinfo->fdt);
 
+    make_hypervisor_node(kinfo->fdt, address_cells[0], size_cells[0]);
+
+    fdt_end_node(kinfo->fdt);
     return 0;
 }
 
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:21:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:21: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 1U7SWX-0001U2-Cn; Mon, 18 Feb 2013 15:20:57 +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 1U7SWV-0001TI-Pl
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:20:56 +0000
Received: from [85.158.138.51:44363] by server-9.bemta-3.messagelabs.com id
	C4/72-09484-8C642215; Mon, 18 Feb 2013 15:20:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361200837!9362986!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8914 invoked from network); 18 Feb 2013 15:20:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:20:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7617335"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:20:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:20:36 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7SWC-0004Hb-PL;
	Mon, 18 Feb 2013 15:20:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 15:20:36 +0000
Message-ID: <1361200836-14481-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: anthony.perard@citrix.com, tim@xen.org, stefano.stabellini@citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v7 4/4] xen: arm: create dom0 DTB /hypervisor/
	node dynamically.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 initially added hypervisor-new and confirmed via /proc/device-model
that the content is the same before changing it to drop and replace
an existing node.

NB: There is an ambiguity in the compatibility property.
linux/arch/arm/boot/dts/xenvm-4.2.dts says "xen,xen-4.2" while
Documentation/devicetree/bindings/arm/xen.txt says "xen,xen-4.3".I have used
the actual hypervisor version as discussed in
http://marc.info/?l=xen-devel&m=135963416631423

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v7: Use Xen version in compatibility node.
---
 xen/arch/arm/domain_build.c |   57 +++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1c35c82..6efc36a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/init.h>
+#include <xen/compile.h>
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/domain_page.h>
@@ -34,7 +35,7 @@ custom_param("dom0_mem", parse_dom0_mem);
  * are added (yet) but one terminating reserve map entry (16 bytes) is
  * added.
  */
-#define DOM0_FDT_EXTRA_SIZE (sizeof(struct fdt_reserve_entry))
+#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
@@ -186,6 +187,13 @@ static int fdt_next_dom0_node(const void *fdt, int node,
         if ( depth >= DEVICE_TREE_MAX_DEPTH )
             break;
 
+        /* Skip /hypervisor/ node. We will inject our own. */
+        if ( fdt_node_check_compatible(fdt, node, "xen,xen" ) == 0 )
+        {
+            printk("Device-tree contains \"xen,xen\" node. Ignoring.\n");
+            continue;
+        }
+
         /* Skip multiboot subnodes */
         if ( fdt_node_check_compatible(fdt, node,
                                        "xen,multiboot-module" ) == 0 )
@@ -199,6 +207,48 @@ static int fdt_next_dom0_node(const void *fdt, int node,
     return node;
 }
 
+static void make_hypervisor_node(void *fdt, int addrcells, int sizecells)
+{
+    const char compat[] =
+        "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
+        "xen,xen";
+    u32 reg[4];
+    u32 intr[3];
+    u32 *cell;
+
+    /*
+     * Sanity-check address sizes, since addresses and sizes which do
+     * not take up exactly 4 or 8 bytes are not supported.
+     */
+    if ((addrcells != 1 && addrcells != 2) ||
+        (sizecells != 1 && sizecells != 2))
+        panic("Cannot cope with this size");
+
+    /* See linux Documentation/devicetree/bindings/arm/xen.txt */
+    fdt_begin_node(fdt, "hypervisor");
+
+    /* Cannot use fdt_property_string due to embedded nulls */
+    fdt_property(fdt, "compatible", compat, sizeof(compat) + 1);
+
+    /* reg 0 is grant table space */
+    cell = &reg[0];
+    device_tree_set_reg(&cell, addrcells, sizecells, 0xb0000000, 0x20000);
+    fdt_property(fdt, "reg", reg,
+                 sizeof(reg[0]) * (addrcells + sizecells));
+
+    /*
+     * interrupts is evtchn upcall  <1 15 0xf08>
+     * See linux Documentation/devicetree/bindings/arm/gic.txt
+     */
+    intr[0] = cpu_to_fdt32(1); /* is a PPI */
+    intr[1] = cpu_to_fdt32(VGIC_IRQ_EVTCHN_CALLBACK - 16); /* PPIs start at 16 */
+    intr[2] = cpu_to_fdt32(0xf08); /* Active-low level-sensitive */
+
+    fdt_property(fdt, "interrupts", intr, sizeof(intr[0]) * 3);
+
+    fdt_end_node(fdt);
+}
+
 static int write_nodes(struct domain *d, struct kernel_info *kinfo,
                        const void *fdt)
 {
@@ -244,9 +294,12 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
         last_depth = depth;
     }
 
-    while ( last_depth-- >= 0 )
+    while ( last_depth-- >= 1 )
         fdt_end_node(kinfo->fdt);
 
+    make_hypervisor_node(kinfo->fdt, address_cells[0], size_cells[0]);
+
+    fdt_end_node(kinfo->fdt);
     return 0;
 }
 
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:32:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7ShF-0002WL-Nt; Mon, 18 Feb 2013 15:32: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 1U7ShD-0002WG-Ku
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:31:59 +0000
Received: from [85.158.143.99:52366] by server-2.bemta-4.messagelabs.com id
	D4/1A-12656-F6942215; Mon, 18 Feb 2013 15:31:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361201516!22738570!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17450 invoked from network); 18 Feb 2013 15:31:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8011487"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:31:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:31:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7Sgi-0004Sf-Ii;
	Mon, 18 Feb 2013 15:31:28 +0000
Date: Mon, 18 Feb 2013 15:31:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361199689.32047.28.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

On Mon, 18 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> > On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > > >  {
> > > >      struct vtimer *t = data;
> > > >      t->ctl |= CNTx_CTL_PENDING;
> > > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > > 
> > > Thinking about the previous discussion about exposing the change of the
> > > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > > actually represent the state of the underlying physical mask bit, since
> > > we do emulate accesses after all.
> > 
> > Sure. However this change still makes sense: if the guest masked the
> > timer (no matter how we internally represent it), we should not inject
> > an interrupt.
> 
> Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
> also, it should be set only when the guest masks the interrupt.

I don't think so. It is a fact that the pending bit is set when an
interrupt is raised, in fact both Xen and Linux check for the pending
bit in the physical interrupt handler.

So the question is: should the pending bit also be set when an interrupt
should have been raised but it wasn't because the timer was masked?
As a matter of fact the answer is yes from my experiments on the
Versatile Express Cortex A15 machine I have.



> > > >  }
> > > >  
> > > >  static void virt_timer_expired(void *data)
> > > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > > >  }
> > > >   
> > > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > > +{
> > > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > > +}
> > > > +
> > > > +int __init init_ptimer(void)
> > > > +{
> > > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > > +    return 0;
> > > > +}
> > > > +
> > > >  int vcpu_vtimer_init(struct vcpu *v)
> > > >  {
> > > >      struct vtimer *t = &v->arch.phys_timer;
> > > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > > >          {
> > > >              v->arch.phys_timer.ctl = *r;
> > > >  
> > > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > > 
> > > Why does PENDING matter here and below?
> > 
> > Doing tests on the physical hardware to better understand its behaviour,
> > I noticed that the pending bit gets set even if the timer is masked
> > (and therefore no interrupt is asserted).
> 
> The manual says that the pending bit (which the newer docs call
> "istatus") is the interrupt status before masking, so this statement
> doesn't really make sense in that context because "even if the timer is
> masked" doesn't really mean anything given that, since this bit is only
> really useful when the interrupt is masked.

That is not true, both Xen and Linux test for that bit when receiving an
interrupt.
Also the manual states:

"""
The status of the timer interrupt:
0 Interrupt not asserted.
1 Interrupt asserted.
This bit is read-only.
A register write that sets IMASK to 1 latches this bit to reflect the
state of the interrupt immediately before that write.
"""

the fact that a register write that sets IMASK to 1 causes an update to
the pending bit, doesn't NOT mean that the pending bit is not also
updated when an interrupt is received.


> if there are discrepancies between the hardware and the documentation
> (which is on the confusing side in this case, although the newest doc is
> better) it would probably be better to get ARM to clarify than to guess
> what the behaviour is suppose to be.

I don't think is a discrepancy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:32:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7ShF-0002WL-Nt; Mon, 18 Feb 2013 15:32: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 1U7ShD-0002WG-Ku
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:31:59 +0000
Received: from [85.158.143.99:52366] by server-2.bemta-4.messagelabs.com id
	D4/1A-12656-F6942215; Mon, 18 Feb 2013 15:31:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361201516!22738570!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17450 invoked from network); 18 Feb 2013 15:31:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:31:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="8011487"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:31:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:31:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7Sgi-0004Sf-Ii;
	Mon, 18 Feb 2013 15:31:28 +0000
Date: Mon, 18 Feb 2013 15:31:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361199689.32047.28.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

On Mon, 18 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> > On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > > >  {
> > > >      struct vtimer *t = data;
> > > >      t->ctl |= CNTx_CTL_PENDING;
> > > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > > 
> > > Thinking about the previous discussion about exposing the change of the
> > > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > > actually represent the state of the underlying physical mask bit, since
> > > we do emulate accesses after all.
> > 
> > Sure. However this change still makes sense: if the guest masked the
> > timer (no matter how we internally represent it), we should not inject
> > an interrupt.
> 
> Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
> also, it should be set only when the guest masks the interrupt.

I don't think so. It is a fact that the pending bit is set when an
interrupt is raised, in fact both Xen and Linux check for the pending
bit in the physical interrupt handler.

So the question is: should the pending bit also be set when an interrupt
should have been raised but it wasn't because the timer was masked?
As a matter of fact the answer is yes from my experiments on the
Versatile Express Cortex A15 machine I have.



> > > >  }
> > > >  
> > > >  static void virt_timer_expired(void *data)
> > > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > > >  }
> > > >   
> > > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > > +{
> > > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > > +}
> > > > +
> > > > +int __init init_ptimer(void)
> > > > +{
> > > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > > +    return 0;
> > > > +}
> > > > +
> > > >  int vcpu_vtimer_init(struct vcpu *v)
> > > >  {
> > > >      struct vtimer *t = &v->arch.phys_timer;
> > > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > > >          {
> > > >              v->arch.phys_timer.ctl = *r;
> > > >  
> > > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > > 
> > > Why does PENDING matter here and below?
> > 
> > Doing tests on the physical hardware to better understand its behaviour,
> > I noticed that the pending bit gets set even if the timer is masked
> > (and therefore no interrupt is asserted).
> 
> The manual says that the pending bit (which the newer docs call
> "istatus") is the interrupt status before masking, so this statement
> doesn't really make sense in that context because "even if the timer is
> masked" doesn't really mean anything given that, since this bit is only
> really useful when the interrupt is masked.

That is not true, both Xen and Linux test for that bit when receiving an
interrupt.
Also the manual states:

"""
The status of the timer interrupt:
0 Interrupt not asserted.
1 Interrupt asserted.
This bit is read-only.
A register write that sets IMASK to 1 latches this bit to reflect the
state of the interrupt immediately before that write.
"""

the fact that a register write that sets IMASK to 1 causes an update to
the pending bit, doesn't NOT mean that the pending bit is not also
updated when an interrupt is received.


> if there are discrepancies between the hardware and the documentation
> (which is on the confusing side in this case, although the newest doc is
> better) it would probably be better to get ARM to clarify than to guess
> what the behaviour is suppose to be.

I don't think is a discrepancy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:33:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:33: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 1U7SiQ-0002a8-6p; Mon, 18 Feb 2013 15:33: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 1U7SiP-0002a0-BD
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:33:13 +0000
Received: from [85.158.143.99:37813] by server-1.bemta-4.messagelabs.com id
	D2/A5-08839-8B942215; Mon, 18 Feb 2013 15:33:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361201590!27550198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4856 invoked from network); 18 Feb 2013 15:33:11 -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;
	18 Feb 2013 15:33:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7619160"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:33:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:33:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7SiL-0004UW-49;
	Mon, 18 Feb 2013 15:33:09 +0000
Date: Mon, 18 Feb 2013 15:33:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361200836-14481-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302181532320.4654@kaball.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
	<1361200836-14481-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 v7 1/4] dtb: correct handling of
 #address-cells and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 18 Feb 2013, Ian Campbell wrote:
> If a node does not have #*-cells then the parent's value should be
> used. Currently we were asssuming zero which is useless.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> v7: assert we don't skip any levels in the tree
> ---
>  xen/arch/arm/domain_build.c   |    9 +++++++--
>  xen/common/device_tree.c      |   12 ++++++++----
>  xen/include/xen/device_tree.h |    3 ++-
>  3 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..9ce661b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -195,11 +195,16 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>              continue;
>          }
>  
> +        /* We cannot handle descending more than one level at a time */
> +        ASSERT( depth <= last_depth + 1 );
> +
>          while ( last_depth-- >= depth )
>              fdt_end_node(kinfo->fdt);
>  
> -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> +                                    depth > 0 ? address_cells[depth-1] : 0);
> +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> +                                    depth > 0 ? size_cells[depth-1] : 0);
>  
>          fdt_begin_node(kinfo->fdt, name);
>  
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 5301d63..f3d3aa1 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
>      set_val(cell, size_cells, size);
>  }
>  
> -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> +                        u32 dflt)
>  {
>      const struct fdt_property *prop;
>  
>      prop = fdt_get_property(fdt, node, prop_name, NULL);
>      if ( !prop || prop->len < sizeof(u32) )
> -        return 0; /* default to 0 */
> +        return dflt;
>  
>      return fdt32_to_cpu(*(uint32_t*)prop->data);
>  }
> @@ -164,8 +165,11 @@ int device_tree_for_each_node(const void *fdt,
>              continue;
>          }
>  
> -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> +                                depth > 0 ? address_cells[depth-1] : 0);
> +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> +                                depth > 0 ? size_cells[depth-1] : 0);
> +
>  
>          ret = func(fdt, node, name, depth,
>                     address_cells[depth-1], size_cells[depth-1], data);
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 1d04e4f..19bda98 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -66,7 +66,8 @@ 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);
> +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> +			u32 dflt);
>  bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
>  bool_t device_tree_node_compatible(const void *fdt, int node, const char *match);
>  int find_compatible_node(const char *compatible, int *node, int *depth,
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:33:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:33: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 1U7SiQ-0002a8-6p; Mon, 18 Feb 2013 15:33: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 1U7SiP-0002a0-BD
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:33:13 +0000
Received: from [85.158.143.99:37813] by server-1.bemta-4.messagelabs.com id
	D2/A5-08839-8B942215; Mon, 18 Feb 2013 15:33:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361201590!27550198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4856 invoked from network); 18 Feb 2013 15:33:11 -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;
	18 Feb 2013 15:33:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7619160"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:33:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:33:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7SiL-0004UW-49;
	Mon, 18 Feb 2013 15:33:09 +0000
Date: Mon, 18 Feb 2013 15:33:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361200836-14481-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302181532320.4654@kaball.uk.xensource.com>
References: <1361200818.1051.6.camel@zakaz.uk.xensource.com>
	<1361200836-14481-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	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 v7 1/4] dtb: correct handling of
 #address-cells and #size-cells.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 18 Feb 2013, Ian Campbell wrote:
> If a node does not have #*-cells then the parent's value should be
> used. Currently we were asssuming zero which is useless.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> v7: assert we don't skip any levels in the tree
> ---
>  xen/arch/arm/domain_build.c   |    9 +++++++--
>  xen/common/device_tree.c      |   12 ++++++++----
>  xen/include/xen/device_tree.h |    3 ++-
>  3 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..9ce661b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -195,11 +195,16 @@ static int write_nodes(struct domain *d, struct kernel_info *kinfo,
>              continue;
>          }
>  
> +        /* We cannot handle descending more than one level at a time */
> +        ASSERT( depth <= last_depth + 1 );
> +
>          while ( last_depth-- >= depth )
>              fdt_end_node(kinfo->fdt);
>  
> -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> +                                    depth > 0 ? address_cells[depth-1] : 0);
> +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> +                                    depth > 0 ? size_cells[depth-1] : 0);
>  
>          fdt_begin_node(kinfo->fdt, name);
>  
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 5301d63..f3d3aa1 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -120,13 +120,14 @@ void device_tree_set_reg(u32 **cell, u32 address_cells, u32 size_cells,
>      set_val(cell, size_cells, size);
>  }
>  
> -u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name)
> +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> +                        u32 dflt)
>  {
>      const struct fdt_property *prop;
>  
>      prop = fdt_get_property(fdt, node, prop_name, NULL);
>      if ( !prop || prop->len < sizeof(u32) )
> -        return 0; /* default to 0 */
> +        return dflt;
>  
>      return fdt32_to_cpu(*(uint32_t*)prop->data);
>  }
> @@ -164,8 +165,11 @@ int device_tree_for_each_node(const void *fdt,
>              continue;
>          }
>  
> -        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells");
> -        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells");
> +        address_cells[depth] = device_tree_get_u32(fdt, node, "#address-cells",
> +                                depth > 0 ? address_cells[depth-1] : 0);
> +        size_cells[depth] = device_tree_get_u32(fdt, node, "#size-cells",
> +                                depth > 0 ? size_cells[depth-1] : 0);
> +
>  
>          ret = func(fdt, node, name, depth,
>                     address_cells[depth-1], size_cells[depth-1], data);
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 1d04e4f..19bda98 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -66,7 +66,8 @@ 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);
> +u32 device_tree_get_u32(const void *fdt, int node, const char *prop_name,
> +			u32 dflt);
>  bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
>  bool_t device_tree_node_compatible(const void *fdt, int node, const char *match);
>  int find_compatible_node(const char *compatible, int *node, int *depth,
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:55:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7T3E-0002vM-9E; Mon, 18 Feb 2013 15:54: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 1U7T3C-0002vF-Ng
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:54:43 +0000
Received: from [85.158.143.99:14657] by server-3.bemta-4.messagelabs.com id
	8B/44-08920-1CE42215; Mon, 18 Feb 2013 15:54:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361202866!28053277!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19081 invoked from network); 18 Feb 2013 15:54:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1577001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:54: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.297.1;
	Mon, 18 Feb 2013 15:54:26 +0000
Message-ID: <1361202864.1051.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 15:54:24 +0000
In-Reply-To: <alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

On Mon, 2013-02-18 at 15:31 +0000, Stefano Stabellini wrote:
> On Mon, 18 Feb 2013, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> > > On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > > > >  {
> > > > >      struct vtimer *t = data;
> > > > >      t->ctl |= CNTx_CTL_PENDING;
> > > > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > 
> > > > Thinking about the previous discussion about exposing the change of the
> > > > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > > > actually represent the state of the underlying physical mask bit, since
> > > > we do emulate accesses after all.
> > > 
> > > Sure. However this change still makes sense: if the guest masked the
> > > timer (no matter how we internally represent it), we should not inject
> > > an interrupt.
> > 
> > Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
> > also, it should be set only when the guest masks the interrupt.
> 
> I don't think so. It is a fact that the pending bit is set when an
> interrupt is raised,

Perhaps it is the case that:
	MASKED == 0 => PENDING represents the "live" state of the 
			interrupt
	MASKED == 1 => PENDING is latched to what ever it was when the 
			mask bit was set
?

That is consistent with the docs as I read them, but not very explicit
(since they only really specify the MASKED==1 case). This would be worth
clarifying with ARM I think.

>  in fact both Xen and Linux check for the pending
> bit in the physical interrupt handler.

Right, if the behaviour is as I described then they are not buggy to do
so without masking the interrupt.

However even with the behaviour above this patch is not implementing the
pending behaviour correctly, since it is cleared unconditionally in
phys_timer_gic_callback(). Also it should be r/o from the guest point of
view.

> So the question is: should the pending bit also be set when an interrupt
> should have been raised but it wasn't because the timer was masked?
> As a matter of fact the answer is yes from my experiments on the
> Versatile Express Cortex A15 machine I have.

The answer may well be yes *on the Cortex A15*. That is why I would like
to see this clarified with ARM. Especially given that this is not
consistent with what the docs say, since they preclude PENDING changing
while MASK is set:
        A register write that sets IMASK to 1 latches this bit to
        reflect the state of the interrupt immediately before that
        write.

The key word is "latches" here -- although it's not clear until when I
think it is likely to be until the mask bit is cleared (another thing to
ask about I think).

It is certainly possible for the timer to fire but be masked and for it
to trigger the interrupt immediately when the mask bit is subsequently
cleared, but that does not imply that the pending bit changes at the
point where it would have fired while it was masked.

> > > > >  }
> > > > >  
> > > > >  static void virt_timer_expired(void *data)
> > > > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > > > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > > > >  }
> > > > >   
> > > > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > > > +{
> > > > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > > > +}
> > > > > +
> > > > > +int __init init_ptimer(void)
> > > > > +{
> > > > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > >  int vcpu_vtimer_init(struct vcpu *v)
> > > > >  {
> > > > >      struct vtimer *t = &v->arch.phys_timer;
> > > > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > > > >          {
> > > > >              v->arch.phys_timer.ctl = *r;
> > > > >  
> > > > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > > > 
> > > > Why does PENDING matter here and below?
> > > 
> > > Doing tests on the physical hardware to better understand its behaviour,
> > > I noticed that the pending bit gets set even if the timer is masked
> > > (and therefore no interrupt is asserted).
> > 
> > The manual says that the pending bit (which the newer docs call
> > "istatus") is the interrupt status before masking, so this statement
> > doesn't really make sense in that context because "even if the timer is
> > masked" doesn't really mean anything given that, since this bit is only
> > really useful when the interrupt is masked.
> 
> That is not true, both Xen and Linux test for that bit when receiving an
> interrupt.
> Also the manual states:
> 
> """
> The status of the timer interrupt:
> 0 Interrupt not asserted.
> 1 Interrupt asserted.
> This bit is read-only.
> A register write that sets IMASK to 1 latches this bit to reflect the
> state of the interrupt immediately before that write.
> """
> 
> the fact that a register write that sets IMASK to 1 causes an update to
> the pending bit, doesn't NOT mean that the pending bit is not also
> updated when an interrupt is received.

The word "latches" does (or at least could) cause it to mean that
though. 

> > if there are discrepancies between the hardware and the documentation
> > (which is on the confusing side in this case, although the newest doc is
> > better) it would probably be better to get ARM to clarify than to guess
> > what the behaviour is suppose to be.
> 
> I don't think is a discrepancy

At the very least the documentation is unclear, or we wouldn't be having
this conversation.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:55:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15: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 1U7T3E-0002vM-9E; Mon, 18 Feb 2013 15:54: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 1U7T3C-0002vF-Ng
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 15:54:43 +0000
Received: from [85.158.143.99:14657] by server-3.bemta-4.messagelabs.com id
	8B/44-08920-1CE42215; Mon, 18 Feb 2013 15:54:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361202866!28053277!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19081 invoked from network); 18 Feb 2013 15:54:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1577001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 15:54: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.297.1;
	Mon, 18 Feb 2013 15:54:26 +0000
Message-ID: <1361202864.1051.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 15:54:24 +0000
In-Reply-To: <alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

On Mon, 2013-02-18 at 15:31 +0000, Stefano Stabellini wrote:
> On Mon, 18 Feb 2013, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> > > On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > > > >  {
> > > > >      struct vtimer *t = data;
> > > > >      t->ctl |= CNTx_CTL_PENDING;
> > > > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > 
> > > > Thinking about the previous discussion about exposing the change of the
> > > > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > > > actually represent the state of the underlying physical mask bit, since
> > > > we do emulate accesses after all.
> > > 
> > > Sure. However this change still makes sense: if the guest masked the
> > > timer (no matter how we internally represent it), we should not inject
> > > an interrupt.
> > 
> > Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
> > also, it should be set only when the guest masks the interrupt.
> 
> I don't think so. It is a fact that the pending bit is set when an
> interrupt is raised,

Perhaps it is the case that:
	MASKED == 0 => PENDING represents the "live" state of the 
			interrupt
	MASKED == 1 => PENDING is latched to what ever it was when the 
			mask bit was set
?

That is consistent with the docs as I read them, but not very explicit
(since they only really specify the MASKED==1 case). This would be worth
clarifying with ARM I think.

>  in fact both Xen and Linux check for the pending
> bit in the physical interrupt handler.

Right, if the behaviour is as I described then they are not buggy to do
so without masking the interrupt.

However even with the behaviour above this patch is not implementing the
pending behaviour correctly, since it is cleared unconditionally in
phys_timer_gic_callback(). Also it should be r/o from the guest point of
view.

> So the question is: should the pending bit also be set when an interrupt
> should have been raised but it wasn't because the timer was masked?
> As a matter of fact the answer is yes from my experiments on the
> Versatile Express Cortex A15 machine I have.

The answer may well be yes *on the Cortex A15*. That is why I would like
to see this clarified with ARM. Especially given that this is not
consistent with what the docs say, since they preclude PENDING changing
while MASK is set:
        A register write that sets IMASK to 1 latches this bit to
        reflect the state of the interrupt immediately before that
        write.

The key word is "latches" here -- although it's not clear until when I
think it is likely to be until the mask bit is cleared (another thing to
ask about I think).

It is certainly possible for the timer to fire but be masked and for it
to trigger the interrupt immediately when the mask bit is subsequently
cleared, but that does not imply that the pending bit changes at the
point where it would have fired while it was masked.

> > > > >  }
> > > > >  
> > > > >  static void virt_timer_expired(void *data)
> > > > > @@ -44,6 +45,17 @@ static void virt_timer_expired(void *data)
> > > > >      vgic_vcpu_inject_irq(t->v, 27, 1);
> > > > >  }
> > > > >   
> > > > > +static void phys_timer_gic_callback(struct vcpu *v, int irq)
> > > > > +{
> > > > > +    v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
> > > > > +}
> > > > > +
> > > > > +int __init init_ptimer(void)
> > > > > +{
> > > > > +    register_gic_callback(30, phys_timer_gic_callback);
> > > > > +    return 0;
> > > > > +}
> > > > > +
> > > > >  int vcpu_vtimer_init(struct vcpu *v)
> > > > >  {
> > > > >      struct vtimer *t = &v->arch.phys_timer;
> > > > > @@ -119,13 +131,15 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > > > >          {
> > > > >              v->arch.phys_timer.ctl = *r;
> > > > >  
> > > > > -            if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > > > > +            if ( ((v->arch.phys_timer.ctl & CNTx_CTL_MASK) &&
> > > > > +                  (v->arch.phys_timer.ctl & CNTx_CTL_PENDING)) ||
> > > > 
> > > > Why does PENDING matter here and below?
> > > 
> > > Doing tests on the physical hardware to better understand its behaviour,
> > > I noticed that the pending bit gets set even if the timer is masked
> > > (and therefore no interrupt is asserted).
> > 
> > The manual says that the pending bit (which the newer docs call
> > "istatus") is the interrupt status before masking, so this statement
> > doesn't really make sense in that context because "even if the timer is
> > masked" doesn't really mean anything given that, since this bit is only
> > really useful when the interrupt is masked.
> 
> That is not true, both Xen and Linux test for that bit when receiving an
> interrupt.
> Also the manual states:
> 
> """
> The status of the timer interrupt:
> 0 Interrupt not asserted.
> 1 Interrupt asserted.
> This bit is read-only.
> A register write that sets IMASK to 1 latches this bit to reflect the
> state of the interrupt immediately before that write.
> """
> 
> the fact that a register write that sets IMASK to 1 causes an update to
> the pending bit, doesn't NOT mean that the pending bit is not also
> updated when an interrupt is received.

The word "latches" does (or at least could) cause it to mean that
though. 

> > if there are discrepancies between the hardware and the documentation
> > (which is on the confusing side in this case, although the newest doc is
> > better) it would probably be better to get ARM to clarify than to guess
> > what the behaviour is suppose to be.
> 
> I don't think is a discrepancy

At the very least the documentation is unclear, or we wouldn't be having
this conversation.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:57:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:57: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 1U7T5r-00031Y-SR; Mon, 18 Feb 2013 15:57:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7T5q-00031S-9p
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:57:26 +0000
Received: from [85.158.137.99:52456] by server-10.bemta-3.messagelabs.com id
	90/41-10609-56F42215; Mon, 18 Feb 2013 15:57:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361202886!13539141!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 18 Feb 2013 15:54:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7621787"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:54:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:54:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7Sps-0004ch-N4;
	Mon, 18 Feb 2013 15:40:56 +0000
Message-ID: <1361202056.3825.28.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>
Date: Mon, 18 Feb 2013 15:40:56 +0000
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Samuel and Daniel

I sent a patch to switch cxenstored's event loop from using select to
using poll several weeks ago, however this would break xenstore-stubdom
as Mini-OS has no poll(2) implementation at the moment.

I think implementing poll(2) for Mini-OS could be a good idea, but I
don't know how far I should go. I'm not familiar with xenstore-stubdom,
and I tried setting it up but it didn't work so I gave up. :-(

To my understanding we only care about the interface but not the
implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
that the internal file abstraction only supports up to 32 files. Is this
xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
more than 32 fds?

My main question is, is it possible to just wrap around select(2) in
Mini-OS to implement poll(2)? (as shown in the conceptual patch)



Wei.

conceptual patch like this:
-----8<----
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..d463231 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -678,6 +678,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+	 fd = pfd[i].fd;
+	 if (comma)
+	      printk(", ");
+	 printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+		pfd[i].events);
+	    comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1006,53 @@ out:
     return ret;
 }
 
+/*
+ * As Mini-OS only supports NOFILE files, we can just wrap around
+ * select?
+ */
+int poll(struct pollfd pfd[], int nfds, int timeout)
+{
+    int ret;
+    int i, fd;
+    struct timeval _timeo;
+    fd_set rfds, wfds;
+
+    DEBUG("poll(");
+    dump_pollfds(pfd, nfds, timeout);
+    DEBUG(")\n");
+
+    /* Timeout in poll is in second. */
+    _timeo.tv_sec  = timeout;
+    _timeo.tv_usec = 0;
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+	if (pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+	if (pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+    }
+
+    ret = select(&rfds, &wfds, NULL, &_timeo);
+
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+	if (FD_ISSET(fd, &rfds))
+            pfd[i].revents |= POLLIN;
+	if (FD_ISSET(fd, &wfds))
+            pfd[i].revents |= POLLOUT;
+    }
+
+    DEBUG("poll(");
+    dump_pollfds(pfd, nfds, timeout);
+    DEBUG(")\n");
+
+    return ret;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1430,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 15:57:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 15:57: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 1U7T5r-00031Y-SR; Mon, 18 Feb 2013 15:57:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7T5q-00031S-9p
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 15:57:26 +0000
Received: from [85.158.137.99:52456] by server-10.bemta-3.messagelabs.com id
	90/41-10609-56F42215; Mon, 18 Feb 2013 15:57:25 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361202886!13539141!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 18 Feb 2013 15:54:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 15:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7621787"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 15:54:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 10:54:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7Sps-0004ch-N4;
	Mon, 18 Feb 2013 15:40:56 +0000
Message-ID: <1361202056.3825.28.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Samuel Thibault
	<samuel.thibault@ens-lyon.org>
Date: Mon, 18 Feb 2013 15:40:56 +0000
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org
Subject: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Samuel and Daniel

I sent a patch to switch cxenstored's event loop from using select to
using poll several weeks ago, however this would break xenstore-stubdom
as Mini-OS has no poll(2) implementation at the moment.

I think implementing poll(2) for Mini-OS could be a good idea, but I
don't know how far I should go. I'm not familiar with xenstore-stubdom,
and I tried setting it up but it didn't work so I gave up. :-(

To my understanding we only care about the interface but not the
implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
that the internal file abstraction only supports up to 32 files. Is this
xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
more than 32 fds?

My main question is, is it possible to just wrap around select(2) in
Mini-OS to implement poll(2)? (as shown in the conceptual patch)



Wei.

conceptual patch like this:
-----8<----
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..d463231 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -678,6 +678,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+	 fd = pfd[i].fd;
+	 if (comma)
+	      printk(", ");
+	 printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+		pfd[i].events);
+	    comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1006,53 @@ out:
     return ret;
 }
 
+/*
+ * As Mini-OS only supports NOFILE files, we can just wrap around
+ * select?
+ */
+int poll(struct pollfd pfd[], int nfds, int timeout)
+{
+    int ret;
+    int i, fd;
+    struct timeval _timeo;
+    fd_set rfds, wfds;
+
+    DEBUG("poll(");
+    dump_pollfds(pfd, nfds, timeout);
+    DEBUG(")\n");
+
+    /* Timeout in poll is in second. */
+    _timeo.tv_sec  = timeout;
+    _timeo.tv_usec = 0;
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+	if (pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+	if (pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+    }
+
+    ret = select(&rfds, &wfds, NULL, &_timeo);
+
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+	if (FD_ISSET(fd, &rfds))
+            pfd[i].revents |= POLLIN;
+	if (FD_ISSET(fd, &wfds))
+            pfd[i].revents |= POLLOUT;
+    }
+
+    DEBUG("poll(");
+    dump_pollfds(pfd, nfds, timeout);
+    DEBUG(")\n");
+
+    return ret;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1430,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:02:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:02: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 1U7TAx-0003g1-5Q; Mon, 18 Feb 2013 16:02: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 1U7TAv-0003fa-Sx
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:42 +0000
Received: from [85.158.138.51:29795] by server-6.bemta-3.messagelabs.com id
	B6/52-29959-0A052215; Mon, 18 Feb 2013 16:02:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361203357!28069157!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28393 invoked from network); 18 Feb 2013 16:02:39 -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;
	18 Feb 2013 16:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622921"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-7X;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:27 +0000
Message-ID: <1361203349-24689-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/4] xen/arm: do not use is_running to decide
	whether we can write directly to the LR registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 context switch is_running is set for the next vcpu before the
gic state is actually saved.
This leads to possible nasty races when interrupts need to be injected
after is_running is set to the next vcpu but before the currently
running gic state has been saved from the previous vcpu.

Use current instead of is_running to check which one is the currently
running vcpu: set_current is called right before __context_switch and
schedule_tail with interrupt disabled.

Re-enabled interrupts after ctxt_switch_from, so that all the context
switch saving functions don't have to worry about receiving interrupts
while saving state.


Changes in v2:
- rework the patch to run ctxt_switch_from with interrupt disabled,
rather than introducing a gic_running internal variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |    5 ++---
 xen/arch/arm/gic.c    |    4 +---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..40979e2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -168,11 +168,10 @@ static void ctxt_switch_to(struct vcpu *n)
 
 static void schedule_tail(struct vcpu *prev)
 {
-    /* Re-enable interrupts before restoring state which may fault. */
-    local_irq_enable();
-
     ctxt_switch_from(prev);
 
+    local_irq_enable();
+
     /* TODO
        update_runstate_area(current);
     */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ac1f939..2d0b052 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -65,11 +65,9 @@ void gic_save_state(struct vcpu *v)
 {
     int i;
 
-    spin_lock_irq(&gic.lock);
     for ( i=0; i<nr_lrs; i++)
         v->arch.gic_lr[i] = GICH[GICH_LR + i];
     v->arch.lr_mask = this_cpu(lr_mask);
-    spin_unlock_irq(&gic.lock);
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
     isb();
@@ -480,7 +478,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     spin_lock_irqsave(&gic.lock, flags);
 
-    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
+    if ( v == current && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
-- 
1.7.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 Feb 18 16:02:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:02: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 1U7TAx-0003g1-5Q; Mon, 18 Feb 2013 16:02: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 1U7TAv-0003fa-Sx
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:42 +0000
Received: from [85.158.138.51:29795] by server-6.bemta-3.messagelabs.com id
	B6/52-29959-0A052215; Mon, 18 Feb 2013 16:02:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361203357!28069157!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28393 invoked from network); 18 Feb 2013 16:02:39 -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;
	18 Feb 2013 16:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622921"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-7X;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:27 +0000
Message-ID: <1361203349-24689-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/4] xen/arm: do not use is_running to decide
	whether we can write directly to the LR registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 context switch is_running is set for the next vcpu before the
gic state is actually saved.
This leads to possible nasty races when interrupts need to be injected
after is_running is set to the next vcpu but before the currently
running gic state has been saved from the previous vcpu.

Use current instead of is_running to check which one is the currently
running vcpu: set_current is called right before __context_switch and
schedule_tail with interrupt disabled.

Re-enabled interrupts after ctxt_switch_from, so that all the context
switch saving functions don't have to worry about receiving interrupts
while saving state.


Changes in v2:
- rework the patch to run ctxt_switch_from with interrupt disabled,
rather than introducing a gic_running internal variable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c |    5 ++---
 xen/arch/arm/gic.c    |    4 +---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..40979e2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -168,11 +168,10 @@ static void ctxt_switch_to(struct vcpu *n)
 
 static void schedule_tail(struct vcpu *prev)
 {
-    /* Re-enable interrupts before restoring state which may fault. */
-    local_irq_enable();
-
     ctxt_switch_from(prev);
 
+    local_irq_enable();
+
     /* TODO
        update_runstate_area(current);
     */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ac1f939..2d0b052 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -65,11 +65,9 @@ void gic_save_state(struct vcpu *v)
 {
     int i;
 
-    spin_lock_irq(&gic.lock);
     for ( i=0; i<nr_lrs; i++)
         v->arch.gic_lr[i] = GICH[GICH_LR + i];
     v->arch.lr_mask = this_cpu(lr_mask);
-    spin_unlock_irq(&gic.lock);
     /* Disable until next VCPU scheduled */
     GICH[GICH_HCR] = 0;
     isb();
@@ -480,7 +478,7 @@ void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     spin_lock_irqsave(&gic.lock, flags);
 
-    if ( v->is_running && list_empty(&v->arch.vgic.lr_pending) )
+    if ( v == current && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
-- 
1.7.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 Feb 18 16:02:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:02: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 1U7TAy-0003gF-IH; Mon, 18 Feb 2013 16:02:44 +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 1U7TAw-0003fm-Ho
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:42 +0000
Received: from [85.158.138.51:31819] by server-16.bemta-3.messagelabs.com id
	8E/FC-02727-1A052215; Mon, 18 Feb 2013 16:02:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361203357!28069157!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28503 invoked from network); 18 Feb 2013 16:02:40 -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;
	18 Feb 2013 16:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622922"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-8X;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:29 +0000
Message-ID: <1361203349-24689-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 4/4] xen/arm: don't set the internal Xen
	timer if virt_timer is masked
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 in v2:
- do not disable interrupts in virt_timer_save because they are already
disabled during the entirety of ctxt_switch_from by a previous patch.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index fec363b..5d650d7 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -87,7 +87,8 @@ int virt_timer_save(struct vcpu *v)
     v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
     WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
-    if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
+    if ( (v->arch.virt_timer.ctl & CNTx_CTL_ENABLE) &&
+         !(v->arch.virt_timer.ctl & CNTx_CTL_MASK))
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
                   v->arch.virt_timer.offset - boot_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 Feb 18 16:02:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:02: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 1U7TAy-0003gF-IH; Mon, 18 Feb 2013 16:02:44 +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 1U7TAw-0003fm-Ho
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:42 +0000
Received: from [85.158.138.51:31819] by server-16.bemta-3.messagelabs.com id
	8E/FC-02727-1A052215; Mon, 18 Feb 2013 16:02:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361203357!28069157!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28503 invoked from network); 18 Feb 2013 16:02:40 -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;
	18 Feb 2013 16:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622922"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-8X;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:29 +0000
Message-ID: <1361203349-24689-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 4/4] xen/arm: don't set the internal Xen
	timer if virt_timer is masked
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 in v2:
- do not disable interrupts in virt_timer_save because they are already
disabled during the entirety of ctxt_switch_from by a previous patch.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index fec363b..5d650d7 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -87,7 +87,8 @@ int virt_timer_save(struct vcpu *v)
     v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
     WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
     v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
-    if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
+    if ( (v->arch.virt_timer.ctl & CNTx_CTL_ENABLE) &&
+         !(v->arch.virt_timer.ctl & CNTx_CTL_MASK))
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
                   v->arch.virt_timer.offset - boot_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 Feb 18 16:02:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TAv-0003fh-PP; Mon, 18 Feb 2013 16:02:41 +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 1U7TAv-0003fa-70
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:41 +0000
Received: from [85.158.138.51:27691] by server-6.bemta-3.messagelabs.com id
	72/52-29959-0A052215; Mon, 18 Feb 2013 16:02:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361203357!28069157!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28254 invoked from network); 18 Feb 2013 16:02:39 -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;
	18 Feb 2013 16:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622920"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-5P;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:26 +0000
Message-ID: <1361203349-24689-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/4] xen/arm: trap guest WFI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Trap guest WFI, block the guest VCPU unless it has pending interrupts.
Awake the guest vcpu when a new interrupt for it arrrives.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/traps.c        |    7 +++++++
 xen/arch/arm/vgic.c         |    4 +++-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e9776d..aa0f191 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -331,7 +331,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM|HCR_TWI, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5347dce..b313e7a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -29,6 +29,7 @@
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
 #include <xen/domain_page.h>
+#include <public/sched.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -781,6 +782,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
     case HSR_EC_DATA_ABORT_GUEST:
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
+    /* at the moment we only trap WFI */
+    case HSR_EC_WFI_WFE:
+        if ( list_empty(&current->arch.vgic.inflight_irqs) )
+            do_sched_op_compat(SCHEDOP_block, 0);
+        regs->pc += hsr.len ? 4 : 2;
+        break;
     default:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 39b9775..8495384 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -608,12 +608,14 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         {
             list_add_tail(&n->inflight, &iter->inflight);
             spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
-            return;
+            goto out;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
     spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
+out:
+    vcpu_unblock(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 Mon Feb 18 16:02:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TAv-0003fh-PP; Mon, 18 Feb 2013 16:02:41 +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 1U7TAv-0003fa-70
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:41 +0000
Received: from [85.158.138.51:27691] by server-6.bemta-3.messagelabs.com id
	72/52-29959-0A052215; Mon, 18 Feb 2013 16:02:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361203357!28069157!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28254 invoked from network); 18 Feb 2013 16:02:39 -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;
	18 Feb 2013 16:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622920"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-5P;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:26 +0000
Message-ID: <1361203349-24689-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/4] xen/arm: trap guest WFI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Trap guest WFI, block the guest VCPU unless it has pending interrupts.
Awake the guest vcpu when a new interrupt for it arrrives.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/traps.c        |    7 +++++++
 xen/arch/arm/vgic.c         |    4 +++-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e9776d..aa0f191 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -331,7 +331,7 @@ int construct_dom0(struct domain *d)
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM|HCR_TWI, HCR);
     isb();
 
     local_abort_enable();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5347dce..b313e7a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -29,6 +29,7 @@
 #include <xen/hypercall.h>
 #include <xen/softirq.h>
 #include <xen/domain_page.h>
+#include <public/sched.h>
 #include <public/xen.h>
 #include <asm/regs.h>
 #include <asm/cpregs.h>
@@ -781,6 +782,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
     case HSR_EC_DATA_ABORT_GUEST:
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
+    /* at the moment we only trap WFI */
+    case HSR_EC_WFI_WFE:
+        if ( list_empty(&current->arch.vgic.inflight_irqs) )
+            do_sched_op_compat(SCHEDOP_block, 0);
+        regs->pc += hsr.len ? 4 : 2;
+        break;
     default:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 39b9775..8495384 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -608,12 +608,14 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
         {
             list_add_tail(&n->inflight, &iter->inflight);
             spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
-            return;
+            goto out;
         }
     }
     list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
     spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
     /* we have a new higher priority irq, inject it into the guest */
+out:
+    vcpu_unblock(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 Mon Feb 18 16:03:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TB3-0003h0-VS; Mon, 18 Feb 2013 16:02:49 +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 1U7TB2-0003gj-0T
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:48 +0000
Received: from [193.109.254.147:27417] by server-3.bemta-14.messagelabs.com id
	3B/00-22141-7A052215; Mon, 18 Feb 2013 16:02:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361203359!6382091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1451 invoked from network); 18 Feb 2013 16:02:41 -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;
	18 Feb 2013 16:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622923"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-81;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:28 +0000
Message-ID: <1361203349-24689-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 3/4] xen/arm: dump gic debug info from
	arch_dump_domain_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

Print some useful GIC debug information when arch_dump_domain_info is
called ('q' debug key).

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    6 ++++++
 xen/arch/arm/gic.c        |   27 +++++++++++++++++++++++++++
 xen/include/asm-arm/gic.h |    3 +++
 3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 40979e2..2506369 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -567,6 +567,12 @@ int domain_relinquish_resources(struct domain *d)
 
 void arch_dump_domain_info(struct domain *d)
 {
+	struct vcpu *v;
+
+	for_each_vcpu ( d, v )
+	{
+		gic_dump_info(v);
+	}
 }
 
 long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2d0b052..fd1ed79 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -678,6 +678,33 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     }
 }
 
+void gic_dump_info(struct vcpu *v)
+{
+    int i;
+    struct pending_irq *p;
+
+    printk("GICH_LRs (vcpu %d) mask=%llx\n", v->vcpu_id, v->arch.lr_mask);
+    if ( v == current )
+    {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   HW_LR[%d]=%x\n", i, GICH[GICH_LR + i]);
+    } else {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   VCPU_LR[%d]=%x\n", i, v->arch.gic_lr[i]);
+    }
+
+    list_for_each_entry ( p, &v->arch.vgic.inflight_irqs, inflight )
+    {
+        printk("Inflight irq=%d\n", p->irq);
+    }
+
+    list_for_each_entry( p, &v->arch.vgic.lr_pending, lr_queue )
+    {
+        printk("Pending irq=%d\n", p->irq);
+    }
+
+}
+ 
 void __cpuinit init_maintenance_interrupt(void)
 {
     request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 764f57e..aab9a05 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -163,6 +163,9 @@ int register_eoi_callback(struct vcpu *v, int irq, irq_callback_fn_t fn);
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(struct vcpu *v);
 
+/* print useful debug info */
+extern void gic_dump_info(struct vcpu *v);
+
 #endif /* __ASSEMBLY__ */
 #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 Feb 18 16:03:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TB3-0003h0-VS; Mon, 18 Feb 2013 16:02:49 +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 1U7TB2-0003gj-0T
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:02:48 +0000
Received: from [193.109.254.147:27417] by server-3.bemta-14.messagelabs.com id
	3B/00-22141-7A052215; Mon, 18 Feb 2013 16:02:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361203359!6382091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1451 invoked from network); 18 Feb 2013 16:02:41 -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;
	18 Feb 2013 16:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7622923"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:02:36 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TAl-000529-81;
	Mon, 18 Feb 2013 16:02:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 18 Feb 2013 16:02:28 +0000
Message-ID: <1361203349-24689-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 3/4] xen/arm: dump gic debug info from
	arch_dump_domain_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

Print some useful GIC debug information when arch_dump_domain_info is
called ('q' debug key).

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/domain.c     |    6 ++++++
 xen/arch/arm/gic.c        |   27 +++++++++++++++++++++++++++
 xen/include/asm-arm/gic.h |    3 +++
 3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 40979e2..2506369 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -567,6 +567,12 @@ int domain_relinquish_resources(struct domain *d)
 
 void arch_dump_domain_info(struct domain *d)
 {
+	struct vcpu *v;
+
+	for_each_vcpu ( d, v )
+	{
+		gic_dump_info(v);
+	}
 }
 
 long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2d0b052..fd1ed79 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -678,6 +678,33 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r
     }
 }
 
+void gic_dump_info(struct vcpu *v)
+{
+    int i;
+    struct pending_irq *p;
+
+    printk("GICH_LRs (vcpu %d) mask=%llx\n", v->vcpu_id, v->arch.lr_mask);
+    if ( v == current )
+    {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   HW_LR[%d]=%x\n", i, GICH[GICH_LR + i]);
+    } else {
+        for ( i = 0; i < nr_lrs; i++ )
+            printk("   VCPU_LR[%d]=%x\n", i, v->arch.gic_lr[i]);
+    }
+
+    list_for_each_entry ( p, &v->arch.vgic.inflight_irqs, inflight )
+    {
+        printk("Inflight irq=%d\n", p->irq);
+    }
+
+    list_for_each_entry( p, &v->arch.vgic.lr_pending, lr_queue )
+    {
+        printk("Pending irq=%d\n", p->irq);
+    }
+
+}
+ 
 void __cpuinit init_maintenance_interrupt(void)
 {
     request_irq(25, maintenance_interrupt, 0, "irq-maintenance", NULL);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 764f57e..aab9a05 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -163,6 +163,9 @@ int register_eoi_callback(struct vcpu *v, int irq, irq_callback_fn_t fn);
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(struct vcpu *v);
 
+/* print useful debug info */
+extern void gic_dump_info(struct vcpu *v);
+
 #endif /* __ASSEMBLY__ */
 #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 Feb 18 16:07:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TFI-0004HI-C0; Mon, 18 Feb 2013 16:07: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 1U7TFG-0004H3-T9
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:07:11 +0000
Received: from [85.158.137.99:5044] by server-1.bemta-3.messagelabs.com id
	39/2A-08955-EA152215; Mon, 18 Feb 2013 16:07:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361203620!21118255!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2080 invoked from network); 18 Feb 2013 16:07:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1577514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:07: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.297.1;
	Mon, 18 Feb 2013 16:07:00 +0000
Message-ID: <1361203619.1051.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 18 Feb 2013 16:06:59 +0000
In-Reply-To: <1361202056.3825.28.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> Hi Samuel and Daniel
> 
> I sent a patch to switch cxenstored's event loop from using select to
> using poll several weeks ago, however this would break xenstore-stubdom
> as Mini-OS has no poll(2) implementation at the moment.
> 
> I think implementing poll(2) for Mini-OS could be a good idea, but I
> don't know how far I should go. I'm not familiar with xenstore-stubdom,
> and I tried setting it up but it didn't work so I gave up. :-(
> 
> To my understanding we only care about the interface but not the
> implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> that the internal file abstraction only supports up to 32 files. Is this
> xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> more than 32 fds?

What do you mean? A stubdom must necessarily be dom!=0 but it should be
able to service all other domains, including dom0 and other domUs.

Do we use an fd per evtchn or only one in xenstore? If the former then
that's a bit of a limitation of the xenstore stubdom!

> My main question is, is it possible to just wrap around select(2) in
> Mini-OS to implement poll(2)? (as shown in the conceptual patch)
> 
> 
> 
> Wei.
> 
> conceptual patch like this:
> -----8<----
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 3cc3340..d463231 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -678,6 +678,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
>  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
>  #endif
>  
> +#ifdef LIBC_DEBUG
> +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> +{
> +    int i, comma, fd;
> +
> +    printk("[");
> +    comma = 0;
> +    for (i = 0; i < nfds; i++) {
> +	 fd = pfd[i].fd;
> +	 if (comma)
> +	      printk(", ");
> +	 printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> +		pfd[i].events);
> +	    comma = 1;
> +    }
> +    printk("]");
> +
> +    printk(", %d, %d", nfds, timeout);
> +}
> +#else
> +#define dump_pollfds(pfds, nfds, timeout)
> +#endif
> +
>  /* Just poll without blocking */
>  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
>  {
> @@ -983,6 +1006,53 @@ out:
>      return ret;
>  }
>  
> +/*
> + * As Mini-OS only supports NOFILE files, we can just wrap around
> + * select?
> + */
> +int poll(struct pollfd pfd[], int nfds, int timeout)
> +{
> +    int ret;
> +    int i, fd;
> +    struct timeval _timeo;
> +    fd_set rfds, wfds;
> +
> +    DEBUG("poll(");
> +    dump_pollfds(pfd, nfds, timeout);
> +    DEBUG(")\n");
> +
> +    /* Timeout in poll is in second. */
> +    _timeo.tv_sec  = timeout;
> +    _timeo.tv_usec = 0;
> +
> +    FD_ZERO(&rfds);
> +    FD_ZERO(&wfds);
> +
> +    for (i = 0; i < nfds; i++) {
> +        fd = pfd[i].fd;
> +	if (pfd[i].events & POLLIN)
> +            FD_SET(fd, &rfds);
> +	if (pfd[i].events & POLLOUT)
> +            FD_SET(fd, &wfds);
> +    }
> +
> +    ret = select(&rfds, &wfds, NULL, &_timeo);
> +
> +    for (i = 0; i < nfds; i++) {
> +        fd = pfd[i].fd;
> +	if (FD_ISSET(fd, &rfds))
> +            pfd[i].revents |= POLLIN;
> +	if (FD_ISSET(fd, &wfds))
> +            pfd[i].revents |= POLLOUT;
> +    }
> +
> +    DEBUG("poll(");
> +    dump_pollfds(pfd, nfds, timeout);
> +    DEBUG(")\n");
> +
> +    return ret;
> +}
> +
>  #ifdef HAVE_LWIP
>  int socket(int domain, int type, int protocol)
>  {
> @@ -1360,7 +1430,6 @@ unsupported_function(int, tcgetattr, 0);
>  unsupported_function(int, grantpt, -1);
>  unsupported_function(int, unlockpt, -1);
>  unsupported_function(char *, ptsname, NULL);
> -unsupported_function(int, poll, -1);
>  
>  /* net/if.h */
>  unsupported_function_log(unsigned int, if_nametoindex, -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 Mon Feb 18 16:07:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TFI-0004HI-C0; Mon, 18 Feb 2013 16:07: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 1U7TFG-0004H3-T9
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:07:11 +0000
Received: from [85.158.137.99:5044] by server-1.bemta-3.messagelabs.com id
	39/2A-08955-EA152215; Mon, 18 Feb 2013 16:07:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361203620!21118255!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2080 invoked from network); 18 Feb 2013 16:07:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1577514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:07: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.297.1;
	Mon, 18 Feb 2013 16:07:00 +0000
Message-ID: <1361203619.1051.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 18 Feb 2013 16:06:59 +0000
In-Reply-To: <1361202056.3825.28.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> Hi Samuel and Daniel
> 
> I sent a patch to switch cxenstored's event loop from using select to
> using poll several weeks ago, however this would break xenstore-stubdom
> as Mini-OS has no poll(2) implementation at the moment.
> 
> I think implementing poll(2) for Mini-OS could be a good idea, but I
> don't know how far I should go. I'm not familiar with xenstore-stubdom,
> and I tried setting it up but it didn't work so I gave up. :-(
> 
> To my understanding we only care about the interface but not the
> implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> that the internal file abstraction only supports up to 32 files. Is this
> xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> more than 32 fds?

What do you mean? A stubdom must necessarily be dom!=0 but it should be
able to service all other domains, including dom0 and other domUs.

Do we use an fd per evtchn or only one in xenstore? If the former then
that's a bit of a limitation of the xenstore stubdom!

> My main question is, is it possible to just wrap around select(2) in
> Mini-OS to implement poll(2)? (as shown in the conceptual patch)
> 
> 
> 
> Wei.
> 
> conceptual patch like this:
> -----8<----
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 3cc3340..d463231 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -678,6 +678,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
>  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
>  #endif
>  
> +#ifdef LIBC_DEBUG
> +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> +{
> +    int i, comma, fd;
> +
> +    printk("[");
> +    comma = 0;
> +    for (i = 0; i < nfds; i++) {
> +	 fd = pfd[i].fd;
> +	 if (comma)
> +	      printk(", ");
> +	 printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> +		pfd[i].events);
> +	    comma = 1;
> +    }
> +    printk("]");
> +
> +    printk(", %d, %d", nfds, timeout);
> +}
> +#else
> +#define dump_pollfds(pfds, nfds, timeout)
> +#endif
> +
>  /* Just poll without blocking */
>  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
>  {
> @@ -983,6 +1006,53 @@ out:
>      return ret;
>  }
>  
> +/*
> + * As Mini-OS only supports NOFILE files, we can just wrap around
> + * select?
> + */
> +int poll(struct pollfd pfd[], int nfds, int timeout)
> +{
> +    int ret;
> +    int i, fd;
> +    struct timeval _timeo;
> +    fd_set rfds, wfds;
> +
> +    DEBUG("poll(");
> +    dump_pollfds(pfd, nfds, timeout);
> +    DEBUG(")\n");
> +
> +    /* Timeout in poll is in second. */
> +    _timeo.tv_sec  = timeout;
> +    _timeo.tv_usec = 0;
> +
> +    FD_ZERO(&rfds);
> +    FD_ZERO(&wfds);
> +
> +    for (i = 0; i < nfds; i++) {
> +        fd = pfd[i].fd;
> +	if (pfd[i].events & POLLIN)
> +            FD_SET(fd, &rfds);
> +	if (pfd[i].events & POLLOUT)
> +            FD_SET(fd, &wfds);
> +    }
> +
> +    ret = select(&rfds, &wfds, NULL, &_timeo);
> +
> +    for (i = 0; i < nfds; i++) {
> +        fd = pfd[i].fd;
> +	if (FD_ISSET(fd, &rfds))
> +            pfd[i].revents |= POLLIN;
> +	if (FD_ISSET(fd, &wfds))
> +            pfd[i].revents |= POLLOUT;
> +    }
> +
> +    DEBUG("poll(");
> +    dump_pollfds(pfd, nfds, timeout);
> +    DEBUG(")\n");
> +
> +    return ret;
> +}
> +
>  #ifdef HAVE_LWIP
>  int socket(int domain, int type, int protocol)
>  {
> @@ -1360,7 +1430,6 @@ unsupported_function(int, tcgetattr, 0);
>  unsupported_function(int, grantpt, -1);
>  unsupported_function(int, unlockpt, -1);
>  unsupported_function(char *, ptsname, NULL);
> -unsupported_function(int, poll, -1);
>  
>  /* net/if.h */
>  unsupported_function_log(unsigned int, if_nametoindex, -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 Mon Feb 18 16:15:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TMs-0004fL-AW; Mon, 18 Feb 2013 16:15: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 1U7TMq-0004fG-8i
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:15:00 +0000
Received: from [85.158.139.83:37444] by server-2.bemta-5.messagelabs.com id
	BD/7D-16911-38352215; Mon, 18 Feb 2013 16:14:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361204097!23844461!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20852 invoked from network); 18 Feb 2013 16:14:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:14:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7624934"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:14:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:14:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TMm-0005Cc-Fp;
	Mon, 18 Feb 2013 16:14:56 +0000
Date: Mon, 18 Feb 2013 16:14:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361202864.1051.22.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com> 
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
	<1361202864.1051.22.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

On Mon, 18 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-02-18 at 15:31 +0000, Stefano Stabellini wrote:
> > On Mon, 18 Feb 2013, Ian Campbell wrote:
> > > On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> > > > On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > > > > >  {
> > > > > >      struct vtimer *t = data;
> > > > > >      t->ctl |= CNTx_CTL_PENDING;
> > > > > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > > > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > > > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > > 
> > > > > Thinking about the previous discussion about exposing the change of the
> > > > > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > > > > actually represent the state of the underlying physical mask bit, since
> > > > > we do emulate accesses after all.
> > > > 
> > > > Sure. However this change still makes sense: if the guest masked the
> > > > timer (no matter how we internally represent it), we should not inject
> > > > an interrupt.
> > > 
> > > Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
> > > also, it should be set only when the guest masks the interrupt.
> > 
> > I don't think so. It is a fact that the pending bit is set when an
> > interrupt is raised,
> 
> Perhaps it is the case that:
> 	MASKED == 0 => PENDING represents the "live" state of the 
> 			interrupt
> 	MASKED == 1 => PENDING is latched to what ever it was when the 
> 			mask bit was set
> ?
> 
> That is consistent with the docs as I read them, but not very explicit
> (since they only really specify the MASKED==1 case). This would be worth
> clarifying with ARM I think.
> 
> >  in fact both Xen and Linux check for the pending
> > bit in the physical interrupt handler.
> 
> Right, if the behaviour is as I described then they are not buggy to do
> so without masking the interrupt.
> 
> However even with the behaviour above this patch is not implementing the
> pending behaviour correctly, since it is cleared unconditionally in
> phys_timer_gic_callback(). Also it should be r/o from the guest point of
> view.

You are right about being RO. See below regarding the "latch" case.


> > So the question is: should the pending bit also be set when an interrupt
> > should have been raised but it wasn't because the timer was masked?
> > As a matter of fact the answer is yes from my experiments on the
> > Versatile Express Cortex A15 machine I have.
> 
> The answer may well be yes *on the Cortex A15*. That is why I would like
> to see this clarified with ARM. Especially given that this is not
> consistent with what the docs say, since they preclude PENDING changing
> while MASK is set:
>         A register write that sets IMASK to 1 latches this bit to
>         reflect the state of the interrupt immediately before that
>         write.
> 
> The key word is "latches" here -- although it's not clear until when I
> think it is likely to be until the mask bit is cleared (another thing to
> ask about I think).
> 
> It is certainly possible for the timer to fire but be masked and for it
> to trigger the interrupt immediately when the mask bit is subsequently
> cleared, but that does not imply that the pending bit changes at the
> point where it would have fired while it was masked.

I think they mean "latch" in electronic sense: they use an SR latch to
keep the pending bit high even if the guest EOIs the interrupt, as long
as the mask bit is 1.
In other words the pending bit cannot be reset if the mask bit is 1.

So I should prevent the guest from resetting this bit directly in all
cases and also I should not reset the bit on EOI if the mask bit is 1.

I agree that is confusing though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:15:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TMs-0004fL-AW; Mon, 18 Feb 2013 16:15: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 1U7TMq-0004fG-8i
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:15:00 +0000
Received: from [85.158.139.83:37444] by server-2.bemta-5.messagelabs.com id
	BD/7D-16911-38352215; Mon, 18 Feb 2013 16:14:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361204097!23844461!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20852 invoked from network); 18 Feb 2013 16:14:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:14:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7624934"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:14:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:14:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7TMm-0005Cc-Fp;
	Mon, 18 Feb 2013 16:14:56 +0000
Date: Mon, 18 Feb 2013 16:14:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361202864.1051.22.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com> 
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
	<1361202864.1051.22.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: phys_timer 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

On Mon, 18 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-02-18 at 15:31 +0000, Stefano Stabellini wrote:
> > On Mon, 18 Feb 2013, Ian Campbell wrote:
> > > On Mon, 2013-02-18 at 14:44 +0000, Stefano Stabellini wrote:
> > > > On Fri, 15 Feb 2013, Ian Campbell wrote:
> > > > > > @@ -33,8 +34,8 @@ static void phys_timer_expired(void *data)
> > > > > >  {
> > > > > >      struct vtimer *t = data;
> > > > > >      t->ctl |= CNTx_CTL_PENDING;
> > > > > > -    t->ctl &= ~CNTx_CTL_MASK;
> > > > > > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > > > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > > > > > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> > > > > 
> > > > > Thinking about the previous discussion about exposing the change of the
> > > > > mask bit to the guest, it just occurred to me that t->ctl.MASK need not
> > > > > actually represent the state of the underlying physical mask bit, since
> > > > > we do emulate accesses after all.
> > > > 
> > > > Sure. However this change still makes sense: if the guest masked the
> > > > timer (no matter how we internally represent it), we should not inject
> > > > an interrupt.
> > > 
> > > Yes. Actually, I think the setting of CNTx_CTL_PENDING here is wrong
> > > also, it should be set only when the guest masks the interrupt.
> > 
> > I don't think so. It is a fact that the pending bit is set when an
> > interrupt is raised,
> 
> Perhaps it is the case that:
> 	MASKED == 0 => PENDING represents the "live" state of the 
> 			interrupt
> 	MASKED == 1 => PENDING is latched to what ever it was when the 
> 			mask bit was set
> ?
> 
> That is consistent with the docs as I read them, but not very explicit
> (since they only really specify the MASKED==1 case). This would be worth
> clarifying with ARM I think.
> 
> >  in fact both Xen and Linux check for the pending
> > bit in the physical interrupt handler.
> 
> Right, if the behaviour is as I described then they are not buggy to do
> so without masking the interrupt.
> 
> However even with the behaviour above this patch is not implementing the
> pending behaviour correctly, since it is cleared unconditionally in
> phys_timer_gic_callback(). Also it should be r/o from the guest point of
> view.

You are right about being RO. See below regarding the "latch" case.


> > So the question is: should the pending bit also be set when an interrupt
> > should have been raised but it wasn't because the timer was masked?
> > As a matter of fact the answer is yes from my experiments on the
> > Versatile Express Cortex A15 machine I have.
> 
> The answer may well be yes *on the Cortex A15*. That is why I would like
> to see this clarified with ARM. Especially given that this is not
> consistent with what the docs say, since they preclude PENDING changing
> while MASK is set:
>         A register write that sets IMASK to 1 latches this bit to
>         reflect the state of the interrupt immediately before that
>         write.
> 
> The key word is "latches" here -- although it's not clear until when I
> think it is likely to be until the mask bit is cleared (another thing to
> ask about I think).
> 
> It is certainly possible for the timer to fire but be masked and for it
> to trigger the interrupt immediately when the mask bit is subsequently
> cleared, but that does not imply that the pending bit changes at the
> point where it would have fired while it was masked.

I think they mean "latch" in electronic sense: they use an SR latch to
keep the pending bit high even if the guest EOIs the interrupt, as long
as the mask bit is 1.
In other words the pending bit cannot be reset if the mask bit is 1.

So I should prevent the guest from resetting this bit directly in all
cases and also I should not reset the bit on EOI if the mask bit is 1.

I agree that is confusing though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:18:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TQ3-0004q9-3V; Mon, 18 Feb 2013 16:18:19 +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 1U7TQ1-0004pw-P0
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:18:17 +0000
Received: from [85.158.143.99:3062] by server-3.bemta-4.messagelabs.com id
	E8/CB-08920-94452215; Mon, 18 Feb 2013 16:18:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361204291!27999299!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7834 invoked from network); 18 Feb 2013 16:18:13 -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;
	18 Feb 2013 16:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7625555"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:18:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:18:10 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7TPu-0005HO-J3;
	Mon, 18 Feb 2013 16:18:10 +0000
Message-ID: <1361204290.3825.37.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Feb 2013 16:18:10 +0000
In-Reply-To: <1361203619.1051.25.camel@zakaz.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > Hi Samuel and Daniel
> > 
> > I sent a patch to switch cxenstored's event loop from using select to
> > using poll several weeks ago, however this would break xenstore-stubdom
> > as Mini-OS has no poll(2) implementation at the moment.
> > 
> > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > and I tried setting it up but it didn't work so I gave up. :-(
> > 
> > To my understanding we only care about the interface but not the
> > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > that the internal file abstraction only supports up to 32 files. Is this
> > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > more than 32 fds?
> 
> What do you mean? A stubdom must necessarily be dom!=0 but it should be
> able to service all other domains, including dom0 and other domUs.
> 

Hah? This is my first impression, but we still need a xenstored running
in Dom0, right? Otherwise what's the output of `xenstore-ls` in Dom0?

> Do we use an fd per evtchn or only one in xenstore? If the former then
> that's a bit of a limitation of the xenstore stubdom!
> 

Xenstore has a struct connection which has one fd for each connection.
So if there are too many connections, how can xenstore stubdom handle
this situation? As I can see in a xenstore process running in Dom0, it
can certainly opens more than 32 fds.


Wei.

> > My main question is, is it possible to just wrap around select(2) in
> > Mini-OS to implement poll(2)? (as shown in the conceptual patch)
> > 
> > 
> > 
> > Wei.
> > 
> > conceptual patch like this:
> > -----8<----
> > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > index 3cc3340..d463231 100644
> > --- a/extras/mini-os/lib/sys.c
> > +++ b/extras/mini-os/lib/sys.c
> > @@ -678,6 +678,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> >  #endif
> >  
> > +#ifdef LIBC_DEBUG
> > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > +{
> > +    int i, comma, fd;
> > +
> > +    printk("[");
> > +    comma = 0;
> > +    for (i = 0; i < nfds; i++) {
> > +	 fd = pfd[i].fd;
> > +	 if (comma)
> > +	      printk(", ");
> > +	 printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > +		pfd[i].events);
> > +	    comma = 1;
> > +    }
> > +    printk("]");
> > +
> > +    printk(", %d, %d", nfds, timeout);
> > +}
> > +#else
> > +#define dump_pollfds(pfds, nfds, timeout)
> > +#endif
> > +
> >  /* Just poll without blocking */
> >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> >  {
> > @@ -983,6 +1006,53 @@ out:
> >      return ret;
> >  }
> >  
> > +/*
> > + * As Mini-OS only supports NOFILE files, we can just wrap around
> > + * select?
> > + */
> > +int poll(struct pollfd pfd[], int nfds, int timeout)
> > +{
> > +    int ret;
> > +    int i, fd;
> > +    struct timeval _timeo;
> > +    fd_set rfds, wfds;
> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(pfd, nfds, timeout);
> > +    DEBUG(")\n");
> > +
> > +    /* Timeout in poll is in second. */
> > +    _timeo.tv_sec  = timeout;
> > +    _timeo.tv_usec = 0;
> > +
> > +    FD_ZERO(&rfds);
> > +    FD_ZERO(&wfds);
> > +
> > +    for (i = 0; i < nfds; i++) {
> > +        fd = pfd[i].fd;
> > +	if (pfd[i].events & POLLIN)
> > +            FD_SET(fd, &rfds);
> > +	if (pfd[i].events & POLLOUT)
> > +            FD_SET(fd, &wfds);
> > +    }
> > +
> > +    ret = select(&rfds, &wfds, NULL, &_timeo);
> > +
> > +    for (i = 0; i < nfds; i++) {
> > +        fd = pfd[i].fd;
> > +	if (FD_ISSET(fd, &rfds))
> > +            pfd[i].revents |= POLLIN;
> > +	if (FD_ISSET(fd, &wfds))
> > +            pfd[i].revents |= POLLOUT;
> > +    }
> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(pfd, nfds, timeout);
> > +    DEBUG(")\n");
> > +
> > +    return ret;
> > +}
> > +
> >  #ifdef HAVE_LWIP
> >  int socket(int domain, int type, int protocol)
> >  {
> > @@ -1360,7 +1430,6 @@ unsupported_function(int, tcgetattr, 0);
> >  unsupported_function(int, grantpt, -1);
> >  unsupported_function(int, unlockpt, -1);
> >  unsupported_function(char *, ptsname, NULL);
> > -unsupported_function(int, poll, -1);
> >  
> >  /* net/if.h */
> >  unsupported_function_log(unsigned int, if_nametoindex, -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 Mon Feb 18 16:18:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TQ3-0004q9-3V; Mon, 18 Feb 2013 16:18:19 +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 1U7TQ1-0004pw-P0
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:18:17 +0000
Received: from [85.158.143.99:3062] by server-3.bemta-4.messagelabs.com id
	E8/CB-08920-94452215; Mon, 18 Feb 2013 16:18:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361204291!27999299!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7834 invoked from network); 18 Feb 2013 16:18:13 -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;
	18 Feb 2013 16:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7625555"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 16:18:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 11:18:10 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7TPu-0005HO-J3;
	Mon, 18 Feb 2013 16:18:10 +0000
Message-ID: <1361204290.3825.37.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Feb 2013 16:18:10 +0000
In-Reply-To: <1361203619.1051.25.camel@zakaz.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > Hi Samuel and Daniel
> > 
> > I sent a patch to switch cxenstored's event loop from using select to
> > using poll several weeks ago, however this would break xenstore-stubdom
> > as Mini-OS has no poll(2) implementation at the moment.
> > 
> > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > and I tried setting it up but it didn't work so I gave up. :-(
> > 
> > To my understanding we only care about the interface but not the
> > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > that the internal file abstraction only supports up to 32 files. Is this
> > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > more than 32 fds?
> 
> What do you mean? A stubdom must necessarily be dom!=0 but it should be
> able to service all other domains, including dom0 and other domUs.
> 

Hah? This is my first impression, but we still need a xenstored running
in Dom0, right? Otherwise what's the output of `xenstore-ls` in Dom0?

> Do we use an fd per evtchn or only one in xenstore? If the former then
> that's a bit of a limitation of the xenstore stubdom!
> 

Xenstore has a struct connection which has one fd for each connection.
So if there are too many connections, how can xenstore stubdom handle
this situation? As I can see in a xenstore process running in Dom0, it
can certainly opens more than 32 fds.


Wei.

> > My main question is, is it possible to just wrap around select(2) in
> > Mini-OS to implement poll(2)? (as shown in the conceptual patch)
> > 
> > 
> > 
> > Wei.
> > 
> > conceptual patch like this:
> > -----8<----
> > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > index 3cc3340..d463231 100644
> > --- a/extras/mini-os/lib/sys.c
> > +++ b/extras/mini-os/lib/sys.c
> > @@ -678,6 +678,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> >  #endif
> >  
> > +#ifdef LIBC_DEBUG
> > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > +{
> > +    int i, comma, fd;
> > +
> > +    printk("[");
> > +    comma = 0;
> > +    for (i = 0; i < nfds; i++) {
> > +	 fd = pfd[i].fd;
> > +	 if (comma)
> > +	      printk(", ");
> > +	 printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > +		pfd[i].events);
> > +	    comma = 1;
> > +    }
> > +    printk("]");
> > +
> > +    printk(", %d, %d", nfds, timeout);
> > +}
> > +#else
> > +#define dump_pollfds(pfds, nfds, timeout)
> > +#endif
> > +
> >  /* Just poll without blocking */
> >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> >  {
> > @@ -983,6 +1006,53 @@ out:
> >      return ret;
> >  }
> >  
> > +/*
> > + * As Mini-OS only supports NOFILE files, we can just wrap around
> > + * select?
> > + */
> > +int poll(struct pollfd pfd[], int nfds, int timeout)
> > +{
> > +    int ret;
> > +    int i, fd;
> > +    struct timeval _timeo;
> > +    fd_set rfds, wfds;
> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(pfd, nfds, timeout);
> > +    DEBUG(")\n");
> > +
> > +    /* Timeout in poll is in second. */
> > +    _timeo.tv_sec  = timeout;
> > +    _timeo.tv_usec = 0;
> > +
> > +    FD_ZERO(&rfds);
> > +    FD_ZERO(&wfds);
> > +
> > +    for (i = 0; i < nfds; i++) {
> > +        fd = pfd[i].fd;
> > +	if (pfd[i].events & POLLIN)
> > +            FD_SET(fd, &rfds);
> > +	if (pfd[i].events & POLLOUT)
> > +            FD_SET(fd, &wfds);
> > +    }
> > +
> > +    ret = select(&rfds, &wfds, NULL, &_timeo);
> > +
> > +    for (i = 0; i < nfds; i++) {
> > +        fd = pfd[i].fd;
> > +	if (FD_ISSET(fd, &rfds))
> > +            pfd[i].revents |= POLLIN;
> > +	if (FD_ISSET(fd, &wfds))
> > +            pfd[i].revents |= POLLOUT;
> > +    }
> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(pfd, nfds, timeout);
> > +    DEBUG(")\n");
> > +
> > +    return ret;
> > +}
> > +
> >  #ifdef HAVE_LWIP
> >  int socket(int domain, int type, int protocol)
> >  {
> > @@ -1360,7 +1430,6 @@ unsupported_function(int, tcgetattr, 0);
> >  unsupported_function(int, grantpt, -1);
> >  unsupported_function(int, unlockpt, -1);
> >  unsupported_function(char *, ptsname, NULL);
> > -unsupported_function(int, poll, -1);
> >  
> >  /* net/if.h */
> >  unsupported_function_log(unsigned int, if_nametoindex, -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 Mon Feb 18 16:26:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:26: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 1U7TXK-00052t-0X; Mon, 18 Feb 2013 16:25: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 1U7TXI-00052o-EG
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:25:48 +0000
Received: from [193.109.254.147:7064] by server-8.bemta-14.messagelabs.com id
	2A/ED-17325-B0652215; Mon, 18 Feb 2013 16:25:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361204640!6385322!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1135 invoked from network); 18 Feb 2013 16:24:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:24:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578182"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:24: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.297.1;
	Mon, 18 Feb 2013 16:24:00 +0000
Message-ID: <1361204638.1051.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 16:23:58 +0000
In-Reply-To: <alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
	<1361202864.1051.22.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

On Mon, 2013-02-18 at 16:14 +0000, Stefano Stabellini wrote:
> I think they mean "latch" in electronic sense: they use an SR latch to
> keep the pending bit high even if the guest EOIs the interrupt, as long
> as the mask bit is 1.

> In other words the pending bit cannot be reset if the mask bit is 1.

"latching high" is a plausible interpretation of the docs given the
observed behaviour on the A15.

We shouldn't assume that just because it appears to behave on way on the
A15, for all we know the state of the PENDING bit while mask==0 is
explicitly implementation defined and just happens to follow the state
of the interrupt in this particular implementation (yes, this would make
Linux and Xen both buggy in their handling). After all we don't have any
alternative implementations to compare with...

So I'd still prefer to check with ARM, rather than potentially bake a
buggy "hardware" implementation into our interface.

> So I should prevent the guest from resetting this bit directly in all
> cases and also I should not reset the bit on EOI if the mask bit is 1.

You also need to do the right thing when the guest clears the mask bit,
which is going to require you to track if the interrupt has been EOId
separately from the pending bit.

> I agree that is confusing though.

Very!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:26:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:26: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 1U7TXK-00052t-0X; Mon, 18 Feb 2013 16:25: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 1U7TXI-00052o-EG
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 16:25:48 +0000
Received: from [193.109.254.147:7064] by server-8.bemta-14.messagelabs.com id
	2A/ED-17325-B0652215; Mon, 18 Feb 2013 16:25:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361204640!6385322!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1135 invoked from network); 18 Feb 2013 16:24:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:24:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578182"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:24: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.297.1;
	Mon, 18 Feb 2013 16:24:00 +0000
Message-ID: <1361204638.1051.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 18 Feb 2013 16:23:58 +0000
In-Reply-To: <alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.com>
References: <1360859833-16498-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<1360933488.31407.35.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181439180.4654@kaball.uk.xensource.com>
	<1361199689.32047.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181517480.4654@kaball.uk.xensource.com>
	<1361202864.1051.22.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302181603500.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 7/7] xen/arm: phys_timer 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

On Mon, 2013-02-18 at 16:14 +0000, Stefano Stabellini wrote:
> I think they mean "latch" in electronic sense: they use an SR latch to
> keep the pending bit high even if the guest EOIs the interrupt, as long
> as the mask bit is 1.

> In other words the pending bit cannot be reset if the mask bit is 1.

"latching high" is a plausible interpretation of the docs given the
observed behaviour on the A15.

We shouldn't assume that just because it appears to behave on way on the
A15, for all we know the state of the PENDING bit while mask==0 is
explicitly implementation defined and just happens to follow the state
of the interrupt in this particular implementation (yes, this would make
Linux and Xen both buggy in their handling). After all we don't have any
alternative implementations to compare with...

So I'd still prefer to check with ARM, rather than potentially bake a
buggy "hardware" implementation into our interface.

> So I should prevent the guest from resetting this bit directly in all
> cases and also I should not reset the bit on EOI if the mask bit is 1.

You also need to do the right thing when the guest clears the mask bit,
which is going to require you to track if the interrupt has been EOId
separately from the pending bit.

> I agree that is confusing though.

Very!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:26:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:26: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 1U7TXW-00053Y-DT; Mon, 18 Feb 2013 16:26: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 1U7TXT-00053H-V4
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:26:00 +0000
Received: from [85.158.139.83:61480] by server-3.bemta-5.messagelabs.com id
	D6/DC-07037-71652215; Mon, 18 Feb 2013 16:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361204756!27258910!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20880 invoked from network); 18 Feb 2013 16:25:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:25: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.297.1;
	Mon, 18 Feb 2013 16:25:56 +0000
Message-ID: <1361204755.1051.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 18 Feb 2013 16:25:55 +0000
In-Reply-To: <1361204290.3825.37.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
	<1361204290.3825.37.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > Hi Samuel and Daniel
> > > 
> > > I sent a patch to switch cxenstored's event loop from using select to
> > > using poll several weeks ago, however this would break xenstore-stubdom
> > > as Mini-OS has no poll(2) implementation at the moment.
> > > 
> > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > and I tried setting it up but it didn't work so I gave up. :-(
> > > 
> > > To my understanding we only care about the interface but not the
> > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > that the internal file abstraction only supports up to 32 files. Is this
> > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > more than 32 fds?
> > 
> > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > able to service all other domains, including dom0 and other domUs.
> > 
> 
> Hah? This is my first impression, but we still need a xenstored running
> in Dom0, right?

No

>  Otherwise what's the output of `xenstore-ls` in Dom0?

It talks to the remote stubdom, in the same way that a domU normally
would.

There is only one xenstored in the entire system. (Ignoring extreme
disaggregation like the XOAR paper).

> > Do we use an fd per evtchn or only one in xenstore? If the former then
> > that's a bit of a limitation of the xenstore stubdom!
> > 
> 
> Xenstore has a struct connection which has one fd for each connection.
> So if there are too many connections, how can xenstore stubdom handle
> this situation? As I can see in a xenstore process running in Dom0, it
> can certainly opens more than 32 fds.

In theory it could share the same /dev/xen/evtchn handle between all
connections.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:26:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:26: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 1U7TXW-00053Y-DT; Mon, 18 Feb 2013 16:26: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 1U7TXT-00053H-V4
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:26:00 +0000
Received: from [85.158.139.83:61480] by server-3.bemta-5.messagelabs.com id
	D6/DC-07037-71652215; Mon, 18 Feb 2013 16:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361204756!27258910!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20880 invoked from network); 18 Feb 2013 16:25:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:25: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.297.1;
	Mon, 18 Feb 2013 16:25:56 +0000
Message-ID: <1361204755.1051.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 18 Feb 2013 16:25:55 +0000
In-Reply-To: <1361204290.3825.37.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
	<1361204290.3825.37.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > Hi Samuel and Daniel
> > > 
> > > I sent a patch to switch cxenstored's event loop from using select to
> > > using poll several weeks ago, however this would break xenstore-stubdom
> > > as Mini-OS has no poll(2) implementation at the moment.
> > > 
> > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > and I tried setting it up but it didn't work so I gave up. :-(
> > > 
> > > To my understanding we only care about the interface but not the
> > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > that the internal file abstraction only supports up to 32 files. Is this
> > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > more than 32 fds?
> > 
> > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > able to service all other domains, including dom0 and other domUs.
> > 
> 
> Hah? This is my first impression, but we still need a xenstored running
> in Dom0, right?

No

>  Otherwise what's the output of `xenstore-ls` in Dom0?

It talks to the remote stubdom, in the same way that a domU normally
would.

There is only one xenstored in the entire system. (Ignoring extreme
disaggregation like the XOAR paper).

> > Do we use an fd per evtchn or only one in xenstore? If the former then
> > that's a bit of a limitation of the xenstore stubdom!
> > 
> 
> Xenstore has a struct connection which has one fd for each connection.
> So if there are too many connections, how can xenstore stubdom handle
> this situation? As I can see in a xenstore process running in Dom0, it
> can certainly opens more than 32 fds.

In theory it could share the same /dev/xen/evtchn handle between all
connections.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:32:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TdL-0005NA-B6; Mon, 18 Feb 2013 16:32:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7TdK-0005N5-0O
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:32:02 +0000
Received: from [85.158.137.99:40682] by server-3.bemta-3.messagelabs.com id
	42/91-31070-18752215; Mon, 18 Feb 2013 16:32:01 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361205116!21934709!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31525 invoked from network); 18 Feb 2013 16:31:56 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:31:56 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so2622450bkc.21
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 08:31:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=zl+hgaN2PI/JrkKgDX2k4lGcuDoHcIWP99d7rMvgNGc=;
	b=MHTmYrku0gpXWDI+msOoy8A5rSwwQ+WyFV7DmLpBnugXHvdxc3CN4bWIjXosZHqH5r
	2MqUZRHLZCVbHTfSD3Imz+CXnhPaeCy5x2213HdaEde9FDRDUapsFk38IFZJxJpnfujN
	OxsoPO99Aov8TPeCCmxcyOtMAcr1ITS1eJ+0FYsp2yMUVHVgfYDd3jmuWQCjdiBsca/P
	/91qXVMArMMAtOYwrTVDsiRP5P0lp/oTam+SOlVQdgGwcfz90A42CWMUJxyXIE5rF/ZF
	VD4IXC1RPyO3gzge215tbdzV7uowyPtxEcJNFrOYr1NEHcZW/AnHxhNJUun9KcJYF8yn
	WsfA==
MIME-Version: 1.0
X-Received: by 10.204.145.195 with SMTP id e3mr5044974bkv.27.1361205115855;
	Mon, 18 Feb 2013 08:31:55 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 08:31:55 -0800 (PST)
In-Reply-To: <1361199775.32047.29.camel@zakaz.uk.xensource.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
	<1361199775.32047.29.camel@zakaz.uk.xensource.com>
Date: Mon, 18 Feb 2013 17:31:55 +0100
Message-ID: <CAF6-1L7=d+p=m-hBov_-kHmj73diEnKvXM74tk_BCv5oXtoNRg@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQnGqFT/y/VeR8f7FLDfBpjFOOPZq/V3WavyxYJIkpaDeHkYIon9/+nkNMkpP2o+XoL9UArw
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

>> memory = 1536
>> maxmem = 2048
>
>
> This is the cause of your second "Dom1 out of PoD memory" bug.
>
> If you aren't running at least a balloon driver inside the guest then
> this isn't valid, since you have requested a different initial memory
> allocation to what you are actually giving the guest and something needs
> to bridge that gap. Initially this is PoD but eventually a balloon
> driver must come along, PoD is not intended for use other than during
> boot until a balloon driver can be started.

Indeed this fixed it.

Interestingly, it seems to avoid the first issue as well ... I guess
this is why nobody hit that before. Although hard rebooting the dom0
might be a severe punishement for a config mistake :p

Cheers & thanks to all.

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:32:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16: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 1U7TdL-0005NA-B6; Mon, 18 Feb 2013 16:32:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1U7TdK-0005N5-0O
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:32:02 +0000
Received: from [85.158.137.99:40682] by server-3.bemta-3.messagelabs.com id
	42/91-31070-18752215; Mon, 18 Feb 2013 16:32:01 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361205116!21934709!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31525 invoked from network); 18 Feb 2013 16:31:56 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:31:56 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so2622450bkc.21
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 08:31:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=zl+hgaN2PI/JrkKgDX2k4lGcuDoHcIWP99d7rMvgNGc=;
	b=MHTmYrku0gpXWDI+msOoy8A5rSwwQ+WyFV7DmLpBnugXHvdxc3CN4bWIjXosZHqH5r
	2MqUZRHLZCVbHTfSD3Imz+CXnhPaeCy5x2213HdaEde9FDRDUapsFk38IFZJxJpnfujN
	OxsoPO99Aov8TPeCCmxcyOtMAcr1ITS1eJ+0FYsp2yMUVHVgfYDd3jmuWQCjdiBsca/P
	/91qXVMArMMAtOYwrTVDsiRP5P0lp/oTam+SOlVQdgGwcfz90A42CWMUJxyXIE5rF/ZF
	VD4IXC1RPyO3gzge215tbdzV7uowyPtxEcJNFrOYr1NEHcZW/AnHxhNJUun9KcJYF8yn
	WsfA==
MIME-Version: 1.0
X-Received: by 10.204.145.195 with SMTP id e3mr5044974bkv.27.1361205115855;
	Mon, 18 Feb 2013 08:31:55 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 18 Feb 2013 08:31:55 -0800 (PST)
In-Reply-To: <1361199775.32047.29.camel@zakaz.uk.xensource.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
	<1361199775.32047.29.camel@zakaz.uk.xensource.com>
Date: Mon, 18 Feb 2013 17:31:55 +0100
Message-ID: <CAF6-1L7=d+p=m-hBov_-kHmj73diEnKvXM74tk_BCv5oXtoNRg@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQnGqFT/y/VeR8f7FLDfBpjFOOPZq/V3WavyxYJIkpaDeHkYIon9/+nkNMkpP2o+XoL9UArw
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

>> memory = 1536
>> maxmem = 2048
>
>
> This is the cause of your second "Dom1 out of PoD memory" bug.
>
> If you aren't running at least a balloon driver inside the guest then
> this isn't valid, since you have requested a different initial memory
> allocation to what you are actually giving the guest and something needs
> to bridge that gap. Initially this is PoD but eventually a balloon
> driver must come along, PoD is not intended for use other than during
> boot until a balloon driver can be started.

Indeed this fixed it.

Interestingly, it seems to avoid the first issue as well ... I guess
this is why nobody hit that before. Although hard rebooting the dom0
might be a severe punishement for a config mistake :p

Cheers & thanks to all.

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:42:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:42: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 1U7TnG-0005o7-6N; Mon, 18 Feb 2013 16:42: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 1U7TnE-0005o0-TP
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:42:17 +0000
Received: from [85.158.139.211:32994] by server-9.bemta-5.messagelabs.com id
	1F/C2-24440-8E952215; Mon, 18 Feb 2013 16:42:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361205729!18099698!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21523 invoked from network); 18 Feb 2013 16:42:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:42:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:42: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.297.1;
	Mon, 18 Feb 2013 16:42:09 +0000
Message-ID: <1361205728.1051.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Date: Mon, 18 Feb 2013 16:42:08 +0000
In-Reply-To: <CAF6-1L7=d+p=m-hBov_-kHmj73diEnKvXM74tk_BCv5oXtoNRg@mail.gmail.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
	<1361199775.32047.29.camel@zakaz.uk.xensource.com>
	<CAF6-1L7=d+p=m-hBov_-kHmj73diEnKvXM74tk_BCv5oXtoNRg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:31 +0000, Sylvain Munaut wrote:
> Hi Ian,
> 
> >> memory = 1536
> >> maxmem = 2048
> >
> >
> > This is the cause of your second "Dom1 out of PoD memory" bug.
> >
> > If you aren't running at least a balloon driver inside the guest then
> > this isn't valid, since you have requested a different initial memory
> > allocation to what you are actually giving the guest and something needs
> > to bridge that gap. Initially this is PoD but eventually a balloon
> > driver must come along, PoD is not intended for use other than during
> > boot until a balloon driver can be started.
> 
> Indeed this fixed it.

Good.

> Interestingly, it seems to avoid the first issue as well ...

If memory == maxmem then PoD (the crashing subsystem) is never activated
so that is to be expected.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:42:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:42: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 1U7TnG-0005o7-6N; Mon, 18 Feb 2013 16:42: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 1U7TnE-0005o0-TP
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:42:17 +0000
Received: from [85.158.139.211:32994] by server-9.bemta-5.messagelabs.com id
	1F/C2-24440-8E952215; Mon, 18 Feb 2013 16:42:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361205729!18099698!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21523 invoked from network); 18 Feb 2013 16:42:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:42:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:42: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.297.1;
	Mon, 18 Feb 2013 16:42:09 +0000
Message-ID: <1361205728.1051.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Date: Mon, 18 Feb 2013 16:42:08 +0000
In-Reply-To: <CAF6-1L7=d+p=m-hBov_-kHmj73diEnKvXM74tk_BCv5oXtoNRg@mail.gmail.com>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L7dCBVg-mDgsrxrB9GLCfzm6ck39sbwcKK+9nLLd=u05Q@mail.gmail.com>
	<1361199775.32047.29.camel@zakaz.uk.xensource.com>
	<CAF6-1L7=d+p=m-hBov_-kHmj73diEnKvXM74tk_BCv5oXtoNRg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
 order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:31 +0000, Sylvain Munaut wrote:
> Hi Ian,
> 
> >> memory = 1536
> >> maxmem = 2048
> >
> >
> > This is the cause of your second "Dom1 out of PoD memory" bug.
> >
> > If you aren't running at least a balloon driver inside the guest then
> > this isn't valid, since you have requested a different initial memory
> > allocation to what you are actually giving the guest and something needs
> > to bridge that gap. Initially this is PoD but eventually a balloon
> > driver must come along, PoD is not intended for use other than during
> > boot until a balloon driver can be started.
> 
> Indeed this fixed it.

Good.

> Interestingly, it seems to avoid the first issue as well ...

If memory == maxmem then PoD (the crashing subsystem) is never activated
so that is to be expected.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:43:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:43: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 1U7ToP-0005s5-MD; Mon, 18 Feb 2013 16:43: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 1U7ToN-0005ru-U0
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:43:28 +0000
Received: from [85.158.137.99:4012] by server-7.bemta-3.messagelabs.com id
	62/A1-10367-F2A52215; Mon, 18 Feb 2013 16:43:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361205806!21139570!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26729 invoked from network); 18 Feb 2013 16:43:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:43: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.297.1;
	Mon, 18 Feb 2013 16:43:25 +0000
Message-ID: <1361205804.1051.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 18 Feb 2013 16:43:24 +0000
In-Reply-To: <1360852785.20449.408.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
	<20130214142416.GW83752@ocelot.phlegethon.org>
	<1360852785.20449.408.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 28/45] xen: arm: arm64 trap 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 Thu, 2013-02-14 at 14:39 +0000, Ian Campbell wrote:
> > > +hyp_sync:
> > > +        entry   hyp=1
> > > +        msr     daifclr, #2
> > > +        adr     lr, return_to_hypervisor
> > > +        mov     x0, sp
> > > +        b       do_trap_hypervisor
> > 
> > This pattern (call fnX with arg0 == sp and lr == fnY) is repeated
> > quite a few times.  Could we have another tidying macro for it?
> 
> I'm half considering doing away with the preload lr+b and just using bl
> instead and putting the tail stuff in a macro like the entry stuff.
> 
> But if we do stick with this way then sure.

I didn't go the exit macro route (still undecided about that) but I did
decide to drop the lr+b stuff. I have a feeling that the branch
predictor will do better with the simple bl version, which ISTR reading
incorporates a hint to the predictor that this is a subroutine call (but
I can't find that reference right now. TBH even that smells a bit too
much of premature optimisation given there's no actual hardware yet, but
the bl version is the straightforward/obvious thing to use so lets go
with that.

I did experiment with a macro:

        @@ -96,6 +96,14 @@ lr      .req    x30             // link register
                 .endm
         
         /*
        + * Call a function, passing sp as the first and only argument
        + */
        +        .macro  call_with_sp, fn
        +        mov     x0, sp
        +        bl      \fn
        +        .endm
        +
        +/*
          * Bad Abort numbers
          *-----------------
          */
        @@ -130,15 +138,14 @@ hyp_error_invalid:
         hyp_sync:
                 entry   hyp=1
                 msr     daifclr, #2
        -        adr     lr, return_to_hypervisor
        -        mov     x0, sp
        -        b       do_trap_hypervisor
        +        call_with_sp do_trap_hypervisor
        +        b       return_to_hypervisor
         
         hyp_irq:
        
        
But TBH I think that looks worse than the open coded:
         hyp_irq:
                 entry   hyp=1
        -        adr     lr, return_to_hypervisor
                 mov     x0, sp
        -        b       do_trap_irq
        +        bl      do_trap_irq
        +        b       return_to_hypervisor

> 
> > 
> > > +ENTRY(return_to_new_vcpu)
> > > +ENTRY(return_to_guest)
> > > +ENTRY(return_to_hypervisor)
> > > +        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
> > > +
> > > +        pop     x0, x1
> > > +        pop     x2, x3
> > > +        pop     x4, x5
> > > +        pop     x6, x7
> > > +        pop     x8, x9
> > > +
> > > +        /* XXX handle return to guest tasks, soft irqs etc */
> > > +        
> > > +        msr     elr_el2, x21                    // set up the return data
> > > +        msr     spsr_el2, x22
> > 
> > Done here becasue it's roughly half-way between the load and the
> > overwrite below?  Should we be using x28/x29 for this to give ourselves
> > even more pipeline space?

x21/22 are used as scratch registers in this way in the rest of the file
too and I'd rather be consistent about that. As it stands there are 5
instructions either side of this usage, I think that will do, at least
in the absence of any useful ability to measure things...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 16:43:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 16:43: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 1U7ToP-0005s5-MD; Mon, 18 Feb 2013 16:43: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 1U7ToN-0005ru-U0
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 16:43:28 +0000
Received: from [85.158.137.99:4012] by server-7.bemta-3.messagelabs.com id
	62/A1-10367-F2A52215; Mon, 18 Feb 2013 16:43:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361205806!21139570!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26729 invoked from network); 18 Feb 2013 16:43:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 16:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="1578819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 16:43: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.297.1;
	Mon, 18 Feb 2013 16:43:25 +0000
Message-ID: <1361205804.1051.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 18 Feb 2013 16:43:24 +0000
In-Reply-To: <1360852785.20449.408.camel@zakaz.uk.xensource.com>
References: <1358956576.17440.60.camel@zakaz.uk.xensource.com>
	<1358956611-8432-28-git-send-email-ian.campbell@citrix.com>
	<20130214142416.GW83752@ocelot.phlegethon.org>
	<1360852785.20449.408.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH 28/45] xen: arm: arm64 trap 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 Thu, 2013-02-14 at 14:39 +0000, Ian Campbell wrote:
> > > +hyp_sync:
> > > +        entry   hyp=1
> > > +        msr     daifclr, #2
> > > +        adr     lr, return_to_hypervisor
> > > +        mov     x0, sp
> > > +        b       do_trap_hypervisor
> > 
> > This pattern (call fnX with arg0 == sp and lr == fnY) is repeated
> > quite a few times.  Could we have another tidying macro for it?
> 
> I'm half considering doing away with the preload lr+b and just using bl
> instead and putting the tail stuff in a macro like the entry stuff.
> 
> But if we do stick with this way then sure.

I didn't go the exit macro route (still undecided about that) but I did
decide to drop the lr+b stuff. I have a feeling that the branch
predictor will do better with the simple bl version, which ISTR reading
incorporates a hint to the predictor that this is a subroutine call (but
I can't find that reference right now. TBH even that smells a bit too
much of premature optimisation given there's no actual hardware yet, but
the bl version is the straightforward/obvious thing to use so lets go
with that.

I did experiment with a macro:

        @@ -96,6 +96,14 @@ lr      .req    x30             // link register
                 .endm
         
         /*
        + * Call a function, passing sp as the first and only argument
        + */
        +        .macro  call_with_sp, fn
        +        mov     x0, sp
        +        bl      \fn
        +        .endm
        +
        +/*
          * Bad Abort numbers
          *-----------------
          */
        @@ -130,15 +138,14 @@ hyp_error_invalid:
         hyp_sync:
                 entry   hyp=1
                 msr     daifclr, #2
        -        adr     lr, return_to_hypervisor
        -        mov     x0, sp
        -        b       do_trap_hypervisor
        +        call_with_sp do_trap_hypervisor
        +        b       return_to_hypervisor
         
         hyp_irq:
        
        
But TBH I think that looks worse than the open coded:
         hyp_irq:
                 entry   hyp=1
        -        adr     lr, return_to_hypervisor
                 mov     x0, sp
        -        b       do_trap_irq
        +        bl      do_trap_irq
        +        b       return_to_hypervisor

> 
> > 
> > > +ENTRY(return_to_new_vcpu)
> > > +ENTRY(return_to_guest)
> > > +ENTRY(return_to_hypervisor)
> > > +        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
> > > +
> > > +        pop     x0, x1
> > > +        pop     x2, x3
> > > +        pop     x4, x5
> > > +        pop     x6, x7
> > > +        pop     x8, x9
> > > +
> > > +        /* XXX handle return to guest tasks, soft irqs etc */
> > > +        
> > > +        msr     elr_el2, x21                    // set up the return data
> > > +        msr     spsr_el2, x22
> > 
> > Done here becasue it's roughly half-way between the load and the
> > overwrite below?  Should we be using x28/x29 for this to give ourselves
> > even more pipeline space?

x21/22 are used as scratch registers in this way in the rest of the file
too and I'd rather be consistent about that. As it stands there are 5
instructions either side of this usage, I think that will do, at least
in the absence of any useful ability to measure things...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:06:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UAY-0006FM-PX; Mon, 18 Feb 2013 17:06:22 +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 1U7UAW-0006FH-TA
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:06:21 +0000
Received: from [85.158.139.211:27361] by server-13.bemta-5.messagelabs.com id
	FA/E9-06769-B8F52215; Mon, 18 Feb 2013 17:06:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361207160!18139311!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21094 invoked from network); 18 Feb 2013 17:06:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:06:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7632497"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 17:06:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 12:05:59 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7UAB-0005yL-Cw;
	Mon, 18 Feb 2013 17:05:59 +0000
Message-ID: <1361207159.3825.40.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Feb 2013 17:05:59 +0000
In-Reply-To: <1361204755.1051.38.camel@zakaz.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
	<1361204290.3825.37.camel@zion.uk.xensource.com>
	<1361204755.1051.38.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:25 +0000, Ian Campbell wrote:
> On Mon, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> > On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > > Hi Samuel and Daniel
> > > > 
> > > > I sent a patch to switch cxenstored's event loop from using select to
> > > > using poll several weeks ago, however this would break xenstore-stubdom
> > > > as Mini-OS has no poll(2) implementation at the moment.
> > > > 
> > > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > > and I tried setting it up but it didn't work so I gave up. :-(
> > > > 
> > > > To my understanding we only care about the interface but not the
> > > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > > that the internal file abstraction only supports up to 32 files. Is this
> > > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > > more than 32 fds?
> > > 
> > > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > > able to service all other domains, including dom0 and other domUs.
> > > 
> > 
> > Hah? This is my first impression, but we still need a xenstored running
> > in Dom0, right?
> 
> No
> 
> >  Otherwise what's the output of `xenstore-ls` in Dom0?
> 
> It talks to the remote stubdom, in the same way that a domU normally
> would.
> 
> There is only one xenstored in the entire system. (Ignoring extreme
> disaggregation like the XOAR paper).
> 

OK.

> > > Do we use an fd per evtchn or only one in xenstore? If the former then
> > > that's a bit of a limitation of the xenstore stubdom!
> > > 
> > 
> > Xenstore has a struct connection which has one fd for each connection.
> > So if there are too many connections, how can xenstore stubdom handle
> > this situation? As I can see in a xenstore process running in Dom0, it
> > can certainly opens more than 32 fds.
> 
> In theory it could share the same /dev/xen/evtchn handle between all
> connections.
> 

I think the real magic is that in cxenstore's implementation there is
some ifdef around specific code to avoid using too many fds, but I
haven't gone too deep into that...


Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:06:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UAY-0006FM-PX; Mon, 18 Feb 2013 17:06:22 +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 1U7UAW-0006FH-TA
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:06:21 +0000
Received: from [85.158.139.211:27361] by server-13.bemta-5.messagelabs.com id
	FA/E9-06769-B8F52215; Mon, 18 Feb 2013 17:06:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361207160!18139311!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21094 invoked from network); 18 Feb 2013 17:06:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:06:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7632497"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 17:06:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 12:05:59 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7UAB-0005yL-Cw;
	Mon, 18 Feb 2013 17:05:59 +0000
Message-ID: <1361207159.3825.40.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Feb 2013 17:05:59 +0000
In-Reply-To: <1361204755.1051.38.camel@zakaz.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
	<1361204290.3825.37.camel@zion.uk.xensource.com>
	<1361204755.1051.38.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 16:25 +0000, Ian Campbell wrote:
> On Mon, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> > On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > > Hi Samuel and Daniel
> > > > 
> > > > I sent a patch to switch cxenstored's event loop from using select to
> > > > using poll several weeks ago, however this would break xenstore-stubdom
> > > > as Mini-OS has no poll(2) implementation at the moment.
> > > > 
> > > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > > and I tried setting it up but it didn't work so I gave up. :-(
> > > > 
> > > > To my understanding we only care about the interface but not the
> > > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > > that the internal file abstraction only supports up to 32 files. Is this
> > > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > > more than 32 fds?
> > > 
> > > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > > able to service all other domains, including dom0 and other domUs.
> > > 
> > 
> > Hah? This is my first impression, but we still need a xenstored running
> > in Dom0, right?
> 
> No
> 
> >  Otherwise what's the output of `xenstore-ls` in Dom0?
> 
> It talks to the remote stubdom, in the same way that a domU normally
> would.
> 
> There is only one xenstored in the entire system. (Ignoring extreme
> disaggregation like the XOAR paper).
> 

OK.

> > > Do we use an fd per evtchn or only one in xenstore? If the former then
> > > that's a bit of a limitation of the xenstore stubdom!
> > > 
> > 
> > Xenstore has a struct connection which has one fd for each connection.
> > So if there are too many connections, how can xenstore stubdom handle
> > this situation? As I can see in a xenstore process running in Dom0, it
> > can certainly opens more than 32 fds.
> 
> In theory it could share the same /dev/xen/evtchn handle between all
> connections.
> 

I think the real magic is that in cxenstore's implementation there is
some ifdef around specific code to avoid using too many fds, but I
haven't gone too deep into that...


Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:10:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17:10: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 1U7UE6-0006Nx-JA; Mon, 18 Feb 2013 17:10:02 +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 1U7UE5-0006No-Az
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:10:01 +0000
Received: from [85.158.143.99:28348] by server-2.bemta-4.messagelabs.com id
	33/46-12656-86062215; Mon, 18 Feb 2013 17:10:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361207398!18416354!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17455 invoked from network); 18 Feb 2013 17:10:00 -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;
	18 Feb 2013 17:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7633037"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 17:09:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 12:09:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7UDn-00061b-Nj;
	Mon, 18 Feb 2013 17:09:43 +0000
Message-ID: <1361207383.3825.41.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Feb 2013 17:09:43 +0000
In-Reply-To: <1361207159.3825.40.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
	<1361204290.3825.37.camel@zion.uk.xensource.com>
	<1361204755.1051.38.camel@zakaz.uk.xensource.com>
	<1361207159.3825.40.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 17:05 +0000, Wei Liu wrote:
> On Mon, 2013-02-18 at 16:25 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> > > On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > > > Hi Samuel and Daniel
> > > > > 
> > > > > I sent a patch to switch cxenstored's event loop from using select to
> > > > > using poll several weeks ago, however this would break xenstore-stubdom
> > > > > as Mini-OS has no poll(2) implementation at the moment.
> > > > > 
> > > > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > > > and I tried setting it up but it didn't work so I gave up. :-(
> > > > > 
> > > > > To my understanding we only care about the interface but not the
> > > > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > > > that the internal file abstraction only supports up to 32 files. Is this
> > > > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > > > more than 32 fds?
> > > > 
> > > > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > > > able to service all other domains, including dom0 and other domUs.
> > > > 
> > > 
> > > Hah? This is my first impression, but we still need a xenstored running
> > > in Dom0, right?
> > 
> > No
> > 
> > >  Otherwise what's the output of `xenstore-ls` in Dom0?
> > 
> > It talks to the remote stubdom, in the same way that a domU normally
> > would.
> > 
> > There is only one xenstored in the entire system. (Ignoring extreme
> > disaggregation like the XOAR paper).
> > 
> 
> OK.
> 
> > > > Do we use an fd per evtchn or only one in xenstore? If the former then
> > > > that's a bit of a limitation of the xenstore stubdom!
> > > > 
> > > 
> > > Xenstore has a struct connection which has one fd for each connection.
> > > So if there are too many connections, how can xenstore stubdom handle
> > > this situation? As I can see in a xenstore process running in Dom0, it
> > > can certainly opens more than 32 fds.
> > 
> > In theory it could share the same /dev/xen/evtchn handle between all
> > connections.
> > 
> 
> I think the real magic is that in cxenstore's implementation there is
> some ifdef around specific code to avoid using too many fds, but I
> haven't gone too deep into that...
> 

Oops, hit send for a mis-composted email, please ignore this... I'm
still investigating this.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:10:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17:10: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 1U7UE6-0006Nx-JA; Mon, 18 Feb 2013 17:10:02 +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 1U7UE5-0006No-Az
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:10:01 +0000
Received: from [85.158.143.99:28348] by server-2.bemta-4.messagelabs.com id
	33/46-12656-86062215; Mon, 18 Feb 2013 17:10:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361207398!18416354!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17455 invoked from network); 18 Feb 2013 17:10:00 -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;
	18 Feb 2013 17:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7633037"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 17:09:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 12:09:43 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7UDn-00061b-Nj;
	Mon, 18 Feb 2013 17:09:43 +0000
Message-ID: <1361207383.3825.41.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 18 Feb 2013 17:09:43 +0000
In-Reply-To: <1361207159.3825.40.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<1361203619.1051.25.camel@zakaz.uk.xensource.com>
	<1361204290.3825.37.camel@zion.uk.xensource.com>
	<1361204755.1051.38.camel@zakaz.uk.xensource.com>
	<1361207159.3825.40.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 17:05 +0000, Wei Liu wrote:
> On Mon, 2013-02-18 at 16:25 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> > > On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > > > Hi Samuel and Daniel
> > > > > 
> > > > > I sent a patch to switch cxenstored's event loop from using select to
> > > > > using poll several weeks ago, however this would break xenstore-stubdom
> > > > > as Mini-OS has no poll(2) implementation at the moment.
> > > > > 
> > > > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > > > and I tried setting it up but it didn't work so I gave up. :-(
> > > > > 
> > > > > To my understanding we only care about the interface but not the
> > > > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > > > that the internal file abstraction only supports up to 32 files. Is this
> > > > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > > > more than 32 fds?
> > > > 
> > > > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > > > able to service all other domains, including dom0 and other domUs.
> > > > 
> > > 
> > > Hah? This is my first impression, but we still need a xenstored running
> > > in Dom0, right?
> > 
> > No
> > 
> > >  Otherwise what's the output of `xenstore-ls` in Dom0?
> > 
> > It talks to the remote stubdom, in the same way that a domU normally
> > would.
> > 
> > There is only one xenstored in the entire system. (Ignoring extreme
> > disaggregation like the XOAR paper).
> > 
> 
> OK.
> 
> > > > Do we use an fd per evtchn or only one in xenstore? If the former then
> > > > that's a bit of a limitation of the xenstore stubdom!
> > > > 
> > > 
> > > Xenstore has a struct connection which has one fd for each connection.
> > > So if there are too many connections, how can xenstore stubdom handle
> > > this situation? As I can see in a xenstore process running in Dom0, it
> > > can certainly opens more than 32 fds.
> > 
> > In theory it could share the same /dev/xen/evtchn handle between all
> > connections.
> > 
> 
> I think the real magic is that in cxenstore's implementation there is
> some ifdef around specific code to avoid using too many fds, but I
> haven't gone too deep into that...
> 

Oops, hit send for a mis-composted email, please ignore this... I'm
still investigating this.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:12:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UGY-0006Wx-6n; Mon, 18 Feb 2013 17:12:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7UGW-0006Wn-IV
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:12:32 +0000
Received: from [193.109.254.147:15903] by server-15.bemta-14.messagelabs.com
	id C5/DC-24599-FF062215; Mon, 18 Feb 2013 17:12:31 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361207546!8694651!1
X-Originating-IP: [192.134.164.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13734 invoked from network); 18 Feb 2013 17:12:28 -0000
Received: from mail3-relais-sop.national.inria.fr (HELO
	mail3-relais-sop.national.inria.fr) (192.134.164.104)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355094000"; 
   d="scan'208";a="2618755"
Received: from nat-inria-bordeaux-53.bordeaux.inria.fr (HELO type.ipv6)
	([194.199.1.53])
	by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	18 Feb 2013 18:12:26 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7UGO-0005ao-IT; Mon, 18 Feb 2013 18:12:24 +0100
Date: Mon, 18 Feb 2013 18:12:24 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130218171224.GL17292@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361202056.3825.28.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Wei Liu, le Mon 18 Feb 2013 15:40:56 +0000, a =E9crit :
> I sent a patch to switch cxenstored's event loop from using select to
> using poll several weeks ago,

What is the rationale BTW?  Efficiency?

> My main question is, is it possible to just wrap around select(2) in
> Mini-OS to implement poll(2)? (as shown in the conceptual patch)

Yes, except that there are evil small differences between poll and
select, which we need to take care of.

About the 32 fd limitation, it indeed comes from the days when we always
had a bounded number of things to open.  We need to drop that limitation,
but it should be easy, by turning the `files' array into a reallocable
pointer.  There is just one important thing: the xenbus_event_queue
events field has to be made a pointer to a dynamically-allocated queue,
otherwise it will get moved by the reallocation and things will go wrong
very badly.

> +int poll(struct pollfd pfd[], int nfds, int timeout)
> +{
...
> +
> +    /* Timeout in poll is in second. */
> +    _timeo.tv_sec  =3D timeout;

FIXME: timeout is in ms, not sec.

> +    _timeo.tv_usec =3D 0;

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:12:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UGY-0006Wx-6n; Mon, 18 Feb 2013 17:12:34 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7UGW-0006Wn-IV
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:12:32 +0000
Received: from [193.109.254.147:15903] by server-15.bemta-14.messagelabs.com
	id C5/DC-24599-FF062215; Mon, 18 Feb 2013 17:12:31 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361207546!8694651!1
X-Originating-IP: [192.134.164.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13734 invoked from network); 18 Feb 2013 17:12:28 -0000
Received: from mail3-relais-sop.national.inria.fr (HELO
	mail3-relais-sop.national.inria.fr) (192.134.164.104)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355094000"; 
   d="scan'208";a="2618755"
Received: from nat-inria-bordeaux-53.bordeaux.inria.fr (HELO type.ipv6)
	([194.199.1.53])
	by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	18 Feb 2013 18:12:26 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7UGO-0005ao-IT; Mon, 18 Feb 2013 18:12:24 +0100
Date: Mon, 18 Feb 2013 18:12:24 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130218171224.GL17292@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361202056.3825.28.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Wei Liu, le Mon 18 Feb 2013 15:40:56 +0000, a =E9crit :
> I sent a patch to switch cxenstored's event loop from using select to
> using poll several weeks ago,

What is the rationale BTW?  Efficiency?

> My main question is, is it possible to just wrap around select(2) in
> Mini-OS to implement poll(2)? (as shown in the conceptual patch)

Yes, except that there are evil small differences between poll and
select, which we need to take care of.

About the 32 fd limitation, it indeed comes from the days when we always
had a bounded number of things to open.  We need to drop that limitation,
but it should be easy, by turning the `files' array into a reallocable
pointer.  There is just one important thing: the xenbus_event_queue
events field has to be made a pointer to a dynamically-allocated queue,
otherwise it will get moved by the reallocation and things will go wrong
very badly.

> +int poll(struct pollfd pfd[], int nfds, int timeout)
> +{
...
> +
> +    /* Timeout in poll is in second. */
> +    _timeo.tv_sec  =3D timeout;

FIXME: timeout is in ms, not sec.

> +    _timeo.tv_usec =3D 0;

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:14:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UHh-0006cX-Mo; Mon, 18 Feb 2013 17:13:45 +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 1U7UHh-0006cM-2l
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:13:45 +0000
Received: from [85.158.137.99:23059] by server-7.bemta-3.messagelabs.com id
	8F/AB-10367-84162215; Mon, 18 Feb 2013 17:13:44 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361207614!21971535!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDU3NjUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15814 invoked from network); 18 Feb 2013 17:13:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:13:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="asc'?scan'208";a="1579712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 17:13:34 +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.297.1;
	Mon, 18 Feb 2013 17:13:33 +0000
Message-ID: <1361207601.31175.6.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 18:13:21 +0100
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6837304239040890713=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6837304239040890713==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-G16wq6WlMqR8X5OBgeWs"

--=-G16wq6WlMqR8X5OBgeWs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2013-02-01 at 12:01 +0100, Dario Faggioli wrote:
> Hello Everyone,
>=20
> V3 of the NUMA aware scheduling series. It is nothing more than v2 with a=
ll
> the review comments I got, addressed... Or so I think. :-)
>=20
Ping?

There is a minor thing from Jurgen which I really plan to address and
repost, but I was hoping to be able to incorporate other people's
feedback as well while doing it.

In some more details...

> Here are the patches included in the series. I '*'-ed ones already receiv=
ed one
> or more acks during previous rounds. Of course, I retained these Ack-s on=
ly for
> the patches that have not been touched, or only underwent minor cluenups.=
 Of
> course, feel free to re-review everything, whatever your Ack is there or =
not!
>=20
>  * [ 1/11] xen, libxc: rename xenctl_cpumap to xenctl_bitmap
>  * [ 2/11] xen, libxc: introduce node maps and masks
>
Jan, are you ok with the changes I made, as a consequence of your
comments to v2 ?

>    [ 3/11] xen: sched_credit: when picking, make sure we get an idle one,=
 if any
>
George ack-ed this.

>    [ 4/11] xen: sched_credit: let the scheduler know about node-affinity
>
Goerge, whenever you're fine, any thoughts on how I addressed the points
you raise at v2 time?

>  * [ 5/11] xen: allow for explicitly specifying node-affinity
>  * [ 6/11] libxc: allow for explicitly specifying node-affinity
>  * [ 7/11] libxl: allow for explicitly specifying node-affinity
>    [ 8/11] libxl: optimize the calculation of how many VCPUs can run on a=
 candidate
>  * [ 9/11] libxl: automatic placement deals with node-affinity
>  * [10/11] xl: add node-affinity to the output of `xl list`
>
These all (apart from 8/11) already received one or more ack(-s), but,
for instance, neither of the Ian's commented, and since I'm touching
[lib]xl, that would be much appreciated. :-)

>    [11/11] docs: rearrange and update NUMA placement documentation
>=20
What about this? How bad the English was this time? :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-G16wq6WlMqR8X5OBgeWs
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)

iEYEABECAAYFAlEiYTEACgkQk4XaBE3IOsSBvgCgr5YJDdL5p1bh+Ht6C+Ijl4M0
mSEAnRPzeW6ihRiSud7+hOYQYiMgJ00/
=G6+v
-----END PGP SIGNATURE-----

--=-G16wq6WlMqR8X5OBgeWs--


--===============6837304239040890713==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6837304239040890713==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 17:14:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UHh-0006cX-Mo; Mon, 18 Feb 2013 17:13:45 +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 1U7UHh-0006cM-2l
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:13:45 +0000
Received: from [85.158.137.99:23059] by server-7.bemta-3.messagelabs.com id
	8F/AB-10367-84162215; Mon, 18 Feb 2013 17:13:44 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361207614!21971535!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDU3NjUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15814 invoked from network); 18 Feb 2013 17:13:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:13:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="asc'?scan'208";a="1579712"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 17:13:34 +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.297.1;
	Mon, 18 Feb 2013 17:13:33 +0000
Message-ID: <1361207601.31175.6.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 18:13:21 +0100
In-Reply-To: <patchbomb.1359716470@Solace>
References: <patchbomb.1359716470@Solace>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6837304239040890713=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6837304239040890713==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-G16wq6WlMqR8X5OBgeWs"

--=-G16wq6WlMqR8X5OBgeWs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2013-02-01 at 12:01 +0100, Dario Faggioli wrote:
> Hello Everyone,
>=20
> V3 of the NUMA aware scheduling series. It is nothing more than v2 with a=
ll
> the review comments I got, addressed... Or so I think. :-)
>=20
Ping?

There is a minor thing from Jurgen which I really plan to address and
repost, but I was hoping to be able to incorporate other people's
feedback as well while doing it.

In some more details...

> Here are the patches included in the series. I '*'-ed ones already receiv=
ed one
> or more acks during previous rounds. Of course, I retained these Ack-s on=
ly for
> the patches that have not been touched, or only underwent minor cluenups.=
 Of
> course, feel free to re-review everything, whatever your Ack is there or =
not!
>=20
>  * [ 1/11] xen, libxc: rename xenctl_cpumap to xenctl_bitmap
>  * [ 2/11] xen, libxc: introduce node maps and masks
>
Jan, are you ok with the changes I made, as a consequence of your
comments to v2 ?

>    [ 3/11] xen: sched_credit: when picking, make sure we get an idle one,=
 if any
>
George ack-ed this.

>    [ 4/11] xen: sched_credit: let the scheduler know about node-affinity
>
Goerge, whenever you're fine, any thoughts on how I addressed the points
you raise at v2 time?

>  * [ 5/11] xen: allow for explicitly specifying node-affinity
>  * [ 6/11] libxc: allow for explicitly specifying node-affinity
>  * [ 7/11] libxl: allow for explicitly specifying node-affinity
>    [ 8/11] libxl: optimize the calculation of how many VCPUs can run on a=
 candidate
>  * [ 9/11] libxl: automatic placement deals with node-affinity
>  * [10/11] xl: add node-affinity to the output of `xl list`
>
These all (apart from 8/11) already received one or more ack(-s), but,
for instance, neither of the Ian's commented, and since I'm touching
[lib]xl, that would be much appreciated. :-)

>    [11/11] docs: rearrange and update NUMA placement documentation
>=20
What about this? How bad the English was this time? :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-G16wq6WlMqR8X5OBgeWs
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)

iEYEABECAAYFAlEiYTEACgkQk4XaBE3IOsSBvgCgr5YJDdL5p1bh+Ht6C+Ijl4M0
mSEAnRPzeW6ihRiSud7+hOYQYiMgJ00/
=G6+v
-----END PGP SIGNATURE-----

--=-G16wq6WlMqR8X5OBgeWs--


--===============6837304239040890713==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6837304239040890713==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 17:18:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UM8-0006r4-G5; Mon, 18 Feb 2013 17:18:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Matthew.Fioravante@jhuapl.edu>)
	id 1U7UM7-0006qr-Ey; Mon, 18 Feb 2013 17:18:19 +0000
Received: from [85.158.137.99:55751] by server-12.bemta-3.messagelabs.com id
	8C/23-05889-95262215; Mon, 18 Feb 2013 17:18:17 +0000
X-Env-Sender: Matthew.Fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361207889!14156115!1
X-Originating-IP: [128.244.251.37]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32391 invoked from network); 18 Feb 2013 17:18:12 -0000
Received: from piper.jhuapl.edu (HELO piper.jhuapl.edu) (128.244.251.37)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2013 17:18:12 -0000
Received: from aplexcas1.dom1.jhuapl.edu (aplexcas1.dom1.jhuapl.edu
	[128.244.198.90]) by piper.jhuapl.edu with smtp
	(TLS: TLSv1/SSLv3,128bits,RC4-MD5)
	id 16ba_51e1_0e6ba42b_3a6f_4ec1_a363_6c2601379061;
	Mon, 18 Feb 2013 12:18:00 -0500
Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by
	aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Mon, 18 Feb 2013
	12:17:48 -0500
From: "Fioravante, Matthew E." <Matthew.Fioravante@jhuapl.edu>
To: tech mailinglists <mailinglists.tech@gmail.com>, "port-xen@netbsd.org"
	<port-xen@netbsd.org>, xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 12:17:47 -0500
Thread-Topic: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.0.1
Thread-Index: Ac4Gwmz5o5Rp8EDWRF23zBGAQ1QyYwHOUlgg
Message-ID: <068F06DC4D106941B297C0C5F9F446EA49199E95FD@aplesstripe.dom1.jhuapl.edu>
References: <CAMCOOJsH8vX-=fXM0xm0rqei_QVgo3X-Vcu70XjtTQkXe+5-7A@mail.gmail.com>
In-Reply-To: <CAMCOOJsH8vX-=fXM0xm0rqei_QVgo3X-Vcu70XjtTQkXe+5-7A@mail.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
Subject: Re: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.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: multipart/mixed; boundary="===============2868975249837997202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2868975249837997202==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_"

--_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've never tried to use vtpm on netbsd so I cannot say whether it will work=
 or not.

This is the old vtpm system which is now deprecated. Even if you can build =
it I wouldn't recommend using it.

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of tech mailinglists
Sent: Saturday, February 09, 2013 7:39 AM
To: port-xen@netbsd.org; xen-users; xen-devel@lists.xen.org
Subject: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.0.1


Hello all,

I try to build Xen 4.2.1 on NetBSD 6.0.1 with vTPM. I would say that depend=
encies are missing but I don't know it.
I have done the following:
I installed the building dependencies from pkgsrc
Run configure as follows:

./configure PYTHON=3D/usr/pkg/bin/python2.7 APPEND_INCLUDES=3D/usr/pkg/incl=
ude APPEND_LIB=3D/usr/pkg/lib --prefix=3D/usr/xen42 --enable-vtpm




Builded Xen itself successfully.

Run gmake for the tools target as follows:

gmake LD_LIBRARY_PATH=3D/usr/pkg/lib tools

This fails with the following error:

gmake[5]: Entering directory `/root/xen-4.2.1/tools/vtpm_manager/manager'
gcc  -Werror -g3 -D_GNU_SOURCE -DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|=
BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_VTPM))" -I/root/xen-4.2.1/tools/vtp=
m_manager/manager/../../../tools/vtpm_manager/crypto -I/root/xen-4.2.1/tool=
s/vtpm_manager/manager/../../../tools/vtpm_manager/util -I/root/xen-4.2.1/t=
ools/vtpm_manager/manager/../../../tools/vtpm_manager/tcs -I/root/xen-4.2.1=
/tools/vtpm_manager/manager/../../../tools/vtpm_manager/manager -pthread  -=
c -o vtpmd.o vtpmd.c  -I/usr/pkg/include


cc1: warnings being treated as errors
vtpmd.c: In function 'signal_handler':
vtpmd.c:96:3: error: passing argument 2 of '__libc_thr_equal' makes pointer=
 from integer without a cast
/usr/include/pthread.h:368:5: note: expected 'pthread_t' but argument is of=
 type '__pid_t'


vtpmd.c: In function 'main':
vtpmd.c:343:28: error: assignment makes integer from pointer without a cast
gmake[5]: *** [vtpmd.o] Error 1
gmake[5]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager/manager'


gmake[4]: *** [subdir-install-manager] Error 2
gmake[4]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'
gmake[3]: *** [subdirs-install] Error 2
gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'


gmake[2]: *** [subdir-install-vtpm_manager] Error 2
gmake[2]: Leaving directory `/root/xen-4.2.1/tools'
gmake[1]: *** [subdirs-install] Error 2
gmake[1]: Leaving directory `/root/xen-4.2.1/tools'
gmake: *** [install-tools] Error 2




So I know that already one dependency is missing I think it's libgmp but I =
found no way to build it on NetBSD.

Is vTPM buildable on NetBSD and what does this error/warning which was trea=
ted as error mean?




Best Regards

--_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_
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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 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: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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle19
	{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: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-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I&#8217;v=
e never tried to use vtpm on netbsd so I cannot say whether it will work or=
 not.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11=
.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></s=
pan></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif";color:#1F497D'>This is the old vtpm system which is no=
w deprecated. Even if you can build it I wouldn&#8217;t recommend using it.=
<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;=
font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span><=
/p><div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0=
in 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;pad=
ding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10=
.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font=
-size:10.0pt;font-family:"Tahoma","sans-serif"'> xen-devel-bounces@lists.xe=
n.org [mailto:xen-devel-bounces@lists.xen.org] <b>On Behalf Of </b>tech mai=
linglists<br><b>Sent:</b> Saturday, February 09, 2013 7:39 AM<br><b>To:</b>=
 port-xen@netbsd.org; xen-users; xen-devel@lists.xen.org<br><b>Subject:</b>=
 [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.0.1<o:p></o:p></span>=
</p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal style=3D=
'margin-bottom:12.0pt'>Hello all,<br><br>I try to build Xen 4.2.1 on NetBSD=
 6.0.1 with vTPM. I would say that dependencies are missing but I don't kno=
w it.<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'margin-bottom:=
12.0pt'>I have done the following:<o:p></o:p></p></div><div><p class=3DMsoN=
ormal style=3D'margin-bottom:12.0pt'>I installed the building dependencies =
from pkgsrc<o:p></o:p></p></div><div><p class=3DMsoNormal>Run configure as =
follows: <o:p></o:p></p><pre>./configure PYTHON=3D/usr/pkg/bin/python2.7 AP=
PEND_INCLUDES=3D/usr/pkg/include APPEND_LIB=3D/usr/pkg/lib --prefix=3D/usr/=
xen42 --enable-vtpm<br><br><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pr=
e style=3D'margin-bottom:12.0pt'>Builded Xen itself successfully.<o:p></o:p=
></pre><pre style=3D'margin-bottom:12.0pt'>Run gmake for the tools target a=
s follows: <br><br>gmake LD_LIBRARY_PATH=3D/usr/pkg/lib tools<o:p></o:p></p=
re><pre style=3D'margin-bottom:12.0pt'>This fails with the following error:=
<o:p></o:p></pre><pre>gmake[5]: Entering directory `/root/xen-4.2.1/tools/v=
tpm_manager/manager'<br>gcc&nbsp; -Werror -g3 -D_GNU_SOURCE -DLOGGING_MODUL=
ES=3D&quot;(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_V=
TPM))&quot; -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtp=
m_manager/crypto -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tool=
s/vtpm_manager/util -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../t=
ools/vtpm_manager/tcs -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../..=
/tools/vtpm_manager/manager -pthread&nbsp; -c -o vtpmd.o vtpmd.c&nbsp; -I/u=
sr/pkg/include<br><br><o:p></o:p></pre><pre>cc1: warnings being treated as =
errors<br>vtpmd.c: In function 'signal_handler':<br>vtpmd.c:96:3: error: pa=
ssing argument 2 of '__libc_thr_equal' makes pointer from integer without a=
 cast<br>/usr/include/pthread.h:368:5: note: expected 'pthread_t' but argum=
ent is of type '__pid_t'<br><br><o:p></o:p></pre><pre>vtpmd.c: In function =
'main':<br>vtpmd.c:343:28: error: assignment makes integer from pointer wit=
hout a cast<br>gmake[5]: *** [vtpmd.o] Error 1<br>gmake[5]: Leaving directo=
ry `/root/xen-4.2.1/tools/vtpm_manager/manager'<br><br><o:p></o:p></pre><pr=
e>gmake[4]: *** [subdir-install-manager] Error 2<br>gmake[4]: Leaving direc=
tory `/root/xen-4.2.1/tools/vtpm_manager'<br>gmake[3]: *** [subdirs-install=
] Error 2<br>gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manage=
r'<br><br><o:p></o:p></pre><pre>gmake[2]: *** [subdir-install-vtpm_manager]=
 Error 2<br>gmake[2]: Leaving directory `/root/xen-4.2.1/tools'<br>gmake[1]=
: *** [subdirs-install] Error 2<br>gmake[1]: Leaving directory `/root/xen-4=
.2.1/tools'<br>gmake: *** [install-tools] Error 2<br><br><o:p></o:p></pre><=
pre><o:p>&nbsp;</o:p></pre><pre style=3D'margin-bottom:12.0pt'>So I know th=
at already one dependency is missing I think it's libgmp but I found no way=
 to build it on NetBSD.<o:p></o:p></pre><pre>Is vTPM buildable on NetBSD an=
d what does this error/warning which was treated as error mean?<br><br><o:p=
></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Best Regards<o:p></o:p></pre>=
</div></div></div></div></body></html>=

--_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_--


--===============2868975249837997202==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2868975249837997202==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 17:18:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UM8-0006r4-G5; Mon, 18 Feb 2013 17:18:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Matthew.Fioravante@jhuapl.edu>)
	id 1U7UM7-0006qr-Ey; Mon, 18 Feb 2013 17:18:19 +0000
Received: from [85.158.137.99:55751] by server-12.bemta-3.messagelabs.com id
	8C/23-05889-95262215; Mon, 18 Feb 2013 17:18:17 +0000
X-Env-Sender: Matthew.Fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361207889!14156115!1
X-Originating-IP: [128.244.251.37]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32391 invoked from network); 18 Feb 2013 17:18:12 -0000
Received: from piper.jhuapl.edu (HELO piper.jhuapl.edu) (128.244.251.37)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2013 17:18:12 -0000
Received: from aplexcas1.dom1.jhuapl.edu (aplexcas1.dom1.jhuapl.edu
	[128.244.198.90]) by piper.jhuapl.edu with smtp
	(TLS: TLSv1/SSLv3,128bits,RC4-MD5)
	id 16ba_51e1_0e6ba42b_3a6f_4ec1_a363_6c2601379061;
	Mon, 18 Feb 2013 12:18:00 -0500
Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by
	aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Mon, 18 Feb 2013
	12:17:48 -0500
From: "Fioravante, Matthew E." <Matthew.Fioravante@jhuapl.edu>
To: tech mailinglists <mailinglists.tech@gmail.com>, "port-xen@netbsd.org"
	<port-xen@netbsd.org>, xen-users <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Mon, 18 Feb 2013 12:17:47 -0500
Thread-Topic: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.0.1
Thread-Index: Ac4Gwmz5o5Rp8EDWRF23zBGAQ1QyYwHOUlgg
Message-ID: <068F06DC4D106941B297C0C5F9F446EA49199E95FD@aplesstripe.dom1.jhuapl.edu>
References: <CAMCOOJsH8vX-=fXM0xm0rqei_QVgo3X-Vcu70XjtTQkXe+5-7A@mail.gmail.com>
In-Reply-To: <CAMCOOJsH8vX-=fXM0xm0rqei_QVgo3X-Vcu70XjtTQkXe+5-7A@mail.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
Subject: Re: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.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: multipart/mixed; boundary="===============2868975249837997202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2868975249837997202==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_"

--_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've never tried to use vtpm on netbsd so I cannot say whether it will work=
 or not.

This is the old vtpm system which is now deprecated. Even if you can build =
it I wouldn't recommend using it.

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of tech mailinglists
Sent: Saturday, February 09, 2013 7:39 AM
To: port-xen@netbsd.org; xen-users; xen-devel@lists.xen.org
Subject: [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.0.1


Hello all,

I try to build Xen 4.2.1 on NetBSD 6.0.1 with vTPM. I would say that depend=
encies are missing but I don't know it.
I have done the following:
I installed the building dependencies from pkgsrc
Run configure as follows:

./configure PYTHON=3D/usr/pkg/bin/python2.7 APPEND_INCLUDES=3D/usr/pkg/incl=
ude APPEND_LIB=3D/usr/pkg/lib --prefix=3D/usr/xen42 --enable-vtpm




Builded Xen itself successfully.

Run gmake for the tools target as follows:

gmake LD_LIBRARY_PATH=3D/usr/pkg/lib tools

This fails with the following error:

gmake[5]: Entering directory `/root/xen-4.2.1/tools/vtpm_manager/manager'
gcc  -Werror -g3 -D_GNU_SOURCE -DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|=
BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_VTPM))" -I/root/xen-4.2.1/tools/vtp=
m_manager/manager/../../../tools/vtpm_manager/crypto -I/root/xen-4.2.1/tool=
s/vtpm_manager/manager/../../../tools/vtpm_manager/util -I/root/xen-4.2.1/t=
ools/vtpm_manager/manager/../../../tools/vtpm_manager/tcs -I/root/xen-4.2.1=
/tools/vtpm_manager/manager/../../../tools/vtpm_manager/manager -pthread  -=
c -o vtpmd.o vtpmd.c  -I/usr/pkg/include


cc1: warnings being treated as errors
vtpmd.c: In function 'signal_handler':
vtpmd.c:96:3: error: passing argument 2 of '__libc_thr_equal' makes pointer=
 from integer without a cast
/usr/include/pthread.h:368:5: note: expected 'pthread_t' but argument is of=
 type '__pid_t'


vtpmd.c: In function 'main':
vtpmd.c:343:28: error: assignment makes integer from pointer without a cast
gmake[5]: *** [vtpmd.o] Error 1
gmake[5]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager/manager'


gmake[4]: *** [subdir-install-manager] Error 2
gmake[4]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'
gmake[3]: *** [subdirs-install] Error 2
gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manager'


gmake[2]: *** [subdir-install-vtpm_manager] Error 2
gmake[2]: Leaving directory `/root/xen-4.2.1/tools'
gmake[1]: *** [subdirs-install] Error 2
gmake[1]: Leaving directory `/root/xen-4.2.1/tools'
gmake: *** [install-tools] Error 2




So I know that already one dependency is missing I think it's libgmp but I =
found no way to build it on NetBSD.

Is vTPM buildable on NetBSD and what does this error/warning which was trea=
ted as error mean?




Best Regards

--_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_
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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 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: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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle19
	{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: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-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I&#8217;v=
e never tried to use vtpm on netbsd so I cannot say whether it will work or=
 not.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11=
.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></s=
pan></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif";color:#1F497D'>This is the old vtpm system which is no=
w deprecated. Even if you can build it I wouldn&#8217;t recommend using it.=
<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;=
font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span><=
/p><div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0=
in 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;pad=
ding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10=
.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font=
-size:10.0pt;font-family:"Tahoma","sans-serif"'> xen-devel-bounces@lists.xe=
n.org [mailto:xen-devel-bounces@lists.xen.org] <b>On Behalf Of </b>tech mai=
linglists<br><b>Sent:</b> Saturday, February 09, 2013 7:39 AM<br><b>To:</b>=
 port-xen@netbsd.org; xen-users; xen-devel@lists.xen.org<br><b>Subject:</b>=
 [Xen-devel] Building Xen 4.2.1 with vTPM on NetBSD 6.0.1<o:p></o:p></span>=
</p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal style=3D=
'margin-bottom:12.0pt'>Hello all,<br><br>I try to build Xen 4.2.1 on NetBSD=
 6.0.1 with vTPM. I would say that dependencies are missing but I don't kno=
w it.<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'margin-bottom:=
12.0pt'>I have done the following:<o:p></o:p></p></div><div><p class=3DMsoN=
ormal style=3D'margin-bottom:12.0pt'>I installed the building dependencies =
from pkgsrc<o:p></o:p></p></div><div><p class=3DMsoNormal>Run configure as =
follows: <o:p></o:p></p><pre>./configure PYTHON=3D/usr/pkg/bin/python2.7 AP=
PEND_INCLUDES=3D/usr/pkg/include APPEND_LIB=3D/usr/pkg/lib --prefix=3D/usr/=
xen42 --enable-vtpm<br><br><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pr=
e style=3D'margin-bottom:12.0pt'>Builded Xen itself successfully.<o:p></o:p=
></pre><pre style=3D'margin-bottom:12.0pt'>Run gmake for the tools target a=
s follows: <br><br>gmake LD_LIBRARY_PATH=3D/usr/pkg/lib tools<o:p></o:p></p=
re><pre style=3D'margin-bottom:12.0pt'>This fails with the following error:=
<o:p></o:p></pre><pre>gmake[5]: Entering directory `/root/xen-4.2.1/tools/v=
tpm_manager/manager'<br>gcc&nbsp; -Werror -g3 -D_GNU_SOURCE -DLOGGING_MODUL=
ES=3D&quot;(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMASK(VTPM_LOG_V=
TPM))&quot; -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tools/vtp=
m_manager/crypto -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../tool=
s/vtpm_manager/util -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../../t=
ools/vtpm_manager/tcs -I/root/xen-4.2.1/tools/vtpm_manager/manager/../../..=
/tools/vtpm_manager/manager -pthread&nbsp; -c -o vtpmd.o vtpmd.c&nbsp; -I/u=
sr/pkg/include<br><br><o:p></o:p></pre><pre>cc1: warnings being treated as =
errors<br>vtpmd.c: In function 'signal_handler':<br>vtpmd.c:96:3: error: pa=
ssing argument 2 of '__libc_thr_equal' makes pointer from integer without a=
 cast<br>/usr/include/pthread.h:368:5: note: expected 'pthread_t' but argum=
ent is of type '__pid_t'<br><br><o:p></o:p></pre><pre>vtpmd.c: In function =
'main':<br>vtpmd.c:343:28: error: assignment makes integer from pointer wit=
hout a cast<br>gmake[5]: *** [vtpmd.o] Error 1<br>gmake[5]: Leaving directo=
ry `/root/xen-4.2.1/tools/vtpm_manager/manager'<br><br><o:p></o:p></pre><pr=
e>gmake[4]: *** [subdir-install-manager] Error 2<br>gmake[4]: Leaving direc=
tory `/root/xen-4.2.1/tools/vtpm_manager'<br>gmake[3]: *** [subdirs-install=
] Error 2<br>gmake[3]: Leaving directory `/root/xen-4.2.1/tools/vtpm_manage=
r'<br><br><o:p></o:p></pre><pre>gmake[2]: *** [subdir-install-vtpm_manager]=
 Error 2<br>gmake[2]: Leaving directory `/root/xen-4.2.1/tools'<br>gmake[1]=
: *** [subdirs-install] Error 2<br>gmake[1]: Leaving directory `/root/xen-4=
.2.1/tools'<br>gmake: *** [install-tools] Error 2<br><br><o:p></o:p></pre><=
pre><o:p>&nbsp;</o:p></pre><pre style=3D'margin-bottom:12.0pt'>So I know th=
at already one dependency is missing I think it's libgmp but I found no way=
 to build it on NetBSD.<o:p></o:p></pre><pre>Is vTPM buildable on NetBSD an=
d what does this error/warning which was treated as error mean?<br><br><o:p=
></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Best Regards<o:p></o:p></pre>=
</div></div></div></div></body></html>=

--_000_068F06DC4D106941B297C0C5F9F446EA49199E95FDaplesstripedo_--


--===============2868975249837997202==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2868975249837997202==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 17:21:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17:21: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 1U7UOr-0006yg-7d; Mon, 18 Feb 2013 17:21:09 +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 1U7UOq-0006ya-0f
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:21:08 +0000
Received: from [193.109.254.147:45698] by server-14.bemta-14.messagelabs.com
	id DA/2A-02031-30362215; Mon, 18 Feb 2013 17:21:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361208063!8519376!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23579 invoked from network); 18 Feb 2013 17:21:06 -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;
	18 Feb 2013 17:21:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7634296"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 17:21:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 12:21:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7UOk-0006Dd-Oc;
	Mon, 18 Feb 2013 17:21:02 +0000
Message-ID: <1361208062.3825.47.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 18 Feb 2013 17:21:02 +0000
In-Reply-To: <20130218171224.GL17292@type.bordeaux.inria.fr>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<20130218171224.GL17292@type.bordeaux.inria.fr>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gTW9uLCAyMDEzLTAyLTE4IGF0IDE3OjEyICswMDAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gV2VpIExpdSwgbGUgTW9uIDE4IEZlYiAyMDEzIDE1OjQwOjU2ICswMDAwLCBhIMOpY3JpdCA6
Cj4gPiBJIHNlbnQgYSBwYXRjaCB0byBzd2l0Y2ggY3hlbnN0b3JlZCdzIGV2ZW50IGxvb3AgZnJv
bSB1c2luZyBzZWxlY3QgdG8KPiA+IHVzaW5nIHBvbGwgc2V2ZXJhbCB3ZWVrcyBhZ28sCj4gCj4g
V2hhdCBpcyB0aGUgcmF0aW9uYWxlIEJUVz8gIEVmZmljaWVuY3k/Cj4gCgpPaCwgdGhlIHJhdGlv
bmFsZSBpcyB0aGF0IHNlbGVjdCBjYW4gb25seSBzdXBwb3J0IDEwMjQgZmRzIGluIExpbnV4LiBJ
Zgp3ZSBydW4gbW9yZSB0aGFuIDEwMjQgZ3Vlc3QgKGluIGZhY3QgdGhlIHJlYWwgbGltaXQgaXMg
bGlrZSAxMDIyKSwKeGVuc3RvcmUgaGFuZ3MgYW5kIG1ha2VzIHRoZSB3aG9sZSBzeXN0ZW0gdW51
c2FibGUuCgo+ID4gTXkgbWFpbiBxdWVzdGlvbiBpcywgaXMgaXQgcG9zc2libGUgdG8ganVzdCB3
cmFwIGFyb3VuZCBzZWxlY3QoMikgaW4KPiA+IE1pbmktT1MgdG8gaW1wbGVtZW50IHBvbGwoMik/
IChhcyBzaG93biBpbiB0aGUgY29uY2VwdHVhbCBwYXRjaCkKPiAKPiBZZXMsIGV4Y2VwdCB0aGF0
IHRoZXJlIGFyZSBldmlsIHNtYWxsIGRpZmZlcmVuY2VzIGJldHdlZW4gcG9sbCBhbmQKPiBzZWxl
Y3QsIHdoaWNoIHdlIG5lZWQgdG8gdGFrZSBjYXJlIG9mLgo+IAoKU3VyZS4gOi0pCgo+IEFib3V0
IHRoZSAzMiBmZCBsaW1pdGF0aW9uLCBpdCBpbmRlZWQgY29tZXMgZnJvbSB0aGUgZGF5cyB3aGVu
IHdlIGFsd2F5cwo+IGhhZCBhIGJvdW5kZWQgbnVtYmVyIG9mIHRoaW5ncyB0byBvcGVuLiAgV2Ug
bmVlZCB0byBkcm9wIHRoYXQgbGltaXRhdGlvbiwKPiBidXQgaXQgc2hvdWxkIGJlIGVhc3ksIGJ5
IHR1cm5pbmcgdGhlIGBmaWxlcycgYXJyYXkgaW50byBhIHJlYWxsb2NhYmxlCj4gcG9pbnRlci4g
IFRoZXJlIGlzIGp1c3Qgb25lIGltcG9ydGFudCB0aGluZzogdGhlIHhlbmJ1c19ldmVudF9xdWV1
ZQo+IGV2ZW50cyBmaWVsZCBoYXMgdG8gYmUgbWFkZSBhIHBvaW50ZXIgdG8gYSBkeW5hbWljYWxs
eS1hbGxvY2F0ZWQgcXVldWUsCj4gb3RoZXJ3aXNlIGl0IHdpbGwgZ2V0IG1vdmVkIGJ5IHRoZSBy
ZWFsbG9jYXRpb24gYW5kIHRoaW5ncyB3aWxsIGdvIHdyb25nCj4gdmVyeSBiYWRseS4KPiAKClNv
IGFwYXJ0IGZyb20gdGhlIG1vZGlmaWNhdGlvbiBuZWVkZWQsIGlzIHRoaXMgIjMyIiByZWFsbHkg
YSBib3R0bGVuZWNrCmZvciB4ZW5zdG9yZS1zdHViZG9tPyBIb3cgbWFueSBkb21haW5zIGNhbiBh
IHhlbnN0b3JlLXN0dWJkb20gc2VydmU/IChJCnRoaW5rIHRoZXNlIHR3byBxdWVzdGlvbnMgYXJl
IGZvciBEYW5pZWwpCgoKV2VpLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:21:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17:21: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 1U7UOr-0006yg-7d; Mon, 18 Feb 2013 17:21:09 +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 1U7UOq-0006ya-0f
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:21:08 +0000
Received: from [193.109.254.147:45698] by server-14.bemta-14.messagelabs.com
	id DA/2A-02031-30362215; Mon, 18 Feb 2013 17:21:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361208063!8519376!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23579 invoked from network); 18 Feb 2013 17:21:06 -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;
	18 Feb 2013 17:21:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; 
   d="scan'208";a="7634296"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 17:21:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 12:21:02 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7UOk-0006Dd-Oc;
	Mon, 18 Feb 2013 17:21:02 +0000
Message-ID: <1361208062.3825.47.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Mon, 18 Feb 2013 17:21:02 +0000
In-Reply-To: <20130218171224.GL17292@type.bordeaux.inria.fr>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<20130218171224.GL17292@type.bordeaux.inria.fr>
X-Mailer: Evolution 3.6.2 (3.6.2-3.fc18) 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gTW9uLCAyMDEzLTAyLTE4IGF0IDE3OjEyICswMDAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gV2VpIExpdSwgbGUgTW9uIDE4IEZlYiAyMDEzIDE1OjQwOjU2ICswMDAwLCBhIMOpY3JpdCA6
Cj4gPiBJIHNlbnQgYSBwYXRjaCB0byBzd2l0Y2ggY3hlbnN0b3JlZCdzIGV2ZW50IGxvb3AgZnJv
bSB1c2luZyBzZWxlY3QgdG8KPiA+IHVzaW5nIHBvbGwgc2V2ZXJhbCB3ZWVrcyBhZ28sCj4gCj4g
V2hhdCBpcyB0aGUgcmF0aW9uYWxlIEJUVz8gIEVmZmljaWVuY3k/Cj4gCgpPaCwgdGhlIHJhdGlv
bmFsZSBpcyB0aGF0IHNlbGVjdCBjYW4gb25seSBzdXBwb3J0IDEwMjQgZmRzIGluIExpbnV4LiBJ
Zgp3ZSBydW4gbW9yZSB0aGFuIDEwMjQgZ3Vlc3QgKGluIGZhY3QgdGhlIHJlYWwgbGltaXQgaXMg
bGlrZSAxMDIyKSwKeGVuc3RvcmUgaGFuZ3MgYW5kIG1ha2VzIHRoZSB3aG9sZSBzeXN0ZW0gdW51
c2FibGUuCgo+ID4gTXkgbWFpbiBxdWVzdGlvbiBpcywgaXMgaXQgcG9zc2libGUgdG8ganVzdCB3
cmFwIGFyb3VuZCBzZWxlY3QoMikgaW4KPiA+IE1pbmktT1MgdG8gaW1wbGVtZW50IHBvbGwoMik/
IChhcyBzaG93biBpbiB0aGUgY29uY2VwdHVhbCBwYXRjaCkKPiAKPiBZZXMsIGV4Y2VwdCB0aGF0
IHRoZXJlIGFyZSBldmlsIHNtYWxsIGRpZmZlcmVuY2VzIGJldHdlZW4gcG9sbCBhbmQKPiBzZWxl
Y3QsIHdoaWNoIHdlIG5lZWQgdG8gdGFrZSBjYXJlIG9mLgo+IAoKU3VyZS4gOi0pCgo+IEFib3V0
IHRoZSAzMiBmZCBsaW1pdGF0aW9uLCBpdCBpbmRlZWQgY29tZXMgZnJvbSB0aGUgZGF5cyB3aGVu
IHdlIGFsd2F5cwo+IGhhZCBhIGJvdW5kZWQgbnVtYmVyIG9mIHRoaW5ncyB0byBvcGVuLiAgV2Ug
bmVlZCB0byBkcm9wIHRoYXQgbGltaXRhdGlvbiwKPiBidXQgaXQgc2hvdWxkIGJlIGVhc3ksIGJ5
IHR1cm5pbmcgdGhlIGBmaWxlcycgYXJyYXkgaW50byBhIHJlYWxsb2NhYmxlCj4gcG9pbnRlci4g
IFRoZXJlIGlzIGp1c3Qgb25lIGltcG9ydGFudCB0aGluZzogdGhlIHhlbmJ1c19ldmVudF9xdWV1
ZQo+IGV2ZW50cyBmaWVsZCBoYXMgdG8gYmUgbWFkZSBhIHBvaW50ZXIgdG8gYSBkeW5hbWljYWxs
eS1hbGxvY2F0ZWQgcXVldWUsCj4gb3RoZXJ3aXNlIGl0IHdpbGwgZ2V0IG1vdmVkIGJ5IHRoZSBy
ZWFsbG9jYXRpb24gYW5kIHRoaW5ncyB3aWxsIGdvIHdyb25nCj4gdmVyeSBiYWRseS4KPiAKClNv
IGFwYXJ0IGZyb20gdGhlIG1vZGlmaWNhdGlvbiBuZWVkZWQsIGlzIHRoaXMgIjMyIiByZWFsbHkg
YSBib3R0bGVuZWNrCmZvciB4ZW5zdG9yZS1zdHViZG9tPyBIb3cgbWFueSBkb21haW5zIGNhbiBh
IHhlbnN0b3JlLXN0dWJkb20gc2VydmU/IChJCnRoaW5rIHRoZXNlIHR3byBxdWVzdGlvbnMgYXJl
IGZvciBEYW5pZWwpCgoKV2VpLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:28:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UVr-0007D9-D7; Mon, 18 Feb 2013 17:28:23 +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 1U7UVp-0007D4-HK
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:28:21 +0000
Received: from [193.109.254.147:5971] by server-11.bemta-14.messagelabs.com id
	98/6A-30685-4B462215; Mon, 18 Feb 2013 17:28:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361208489!6393025!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2640 invoked from network); 18 Feb 2013 17:28:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:28:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,689,1355097600"; 
   d="scan'208";a="1580582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 17:28: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.297.1;
	Mon, 18 Feb 2013 17:28:08 +0000
Message-ID: <1361208487.1051.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 18 Feb 2013 17:28:07 +0000
In-Reply-To: <1361208062.3825.47.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<20130218171224.GL17292@type.bordeaux.inria.fr>
	<1361208062.3825.47.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 17:21 +0000, Wei Liu wrote:

> So apart from the modification needed, is this "32" really a bottleneck
> for xenstore-stubdom? How many domains can a xenstore-stubdom serve?

There's no reason in principal to expect this to be any less than
xenstored running in dom0 can support, issues like the one you've found
notwithstanding.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 17:28:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 17: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 1U7UVr-0007D9-D7; Mon, 18 Feb 2013 17:28:23 +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 1U7UVp-0007D4-HK
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 17:28:21 +0000
Received: from [193.109.254.147:5971] by server-11.bemta-14.messagelabs.com id
	98/6A-30685-4B462215; Mon, 18 Feb 2013 17:28:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361208489!6393025!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2640 invoked from network); 18 Feb 2013 17:28:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 17:28:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,689,1355097600"; 
   d="scan'208";a="1580582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Feb 2013 17:28: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.297.1;
	Mon, 18 Feb 2013 17:28:08 +0000
Message-ID: <1361208487.1051.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Mon, 18 Feb 2013 17:28:07 +0000
In-Reply-To: <1361208062.3825.47.camel@zion.uk.xensource.com>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<20130218171224.GL17292@type.bordeaux.inria.fr>
	<1361208062.3825.47.camel@zion.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-18 at 17:21 +0000, Wei Liu wrote:

> So apart from the modification needed, is this "32" really a bottleneck
> for xenstore-stubdom? How many domains can a xenstore-stubdom serve?

There's no reason in principal to expect this to be any less than
xenstored running in dom0 can support, issues like the one you've found
notwithstanding.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 18:11:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 18:11: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 1U7VBI-000075-IV; Mon, 18 Feb 2013 18:11:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7VBH-00006y-Hd
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 18:11:11 +0000
Received: from [85.158.139.83:4332] by server-10.bemta-5.messagelabs.com id
	CF/B5-04697-EBE62215; Mon, 18 Feb 2013 18:11:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361211068!27849588!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18329 invoked from network); 18 Feb 2013 18:11:10 -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;
	18 Feb 2013 18:11:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,689,1355097600"; 
   d="scan'208";a="7641497"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 18:11:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 13:11:07 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U7VBD-000705-Q6;
	Mon, 18 Feb 2013 18:11:07 +0000
Message-ID: <51226EBB.3030503@citrix.com>
Date: Mon, 18 Feb 2013 18:11:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>, George Dunlap
	<George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>, Jan Beulich
	<JBeulich@suse.com>
X-Enigmail-Version: 1.4
Subject: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Our testing has discovered a crash (pagefault at 0x0000000000000008)
which I have tracked down to bad __runq_remove() in csched_vcpu_sleep()
in sched_credit.c (because a static function of the same name also
exists in sched_credit2.c, which confused matters to start with)

The test case was a loop of localhost migrate of a 1vcpu HVM win8
domain.  The test case itself has passed many times in the past on the
same Xen codebase (Xen-4.1.3), indicating that it is very rare.  There
does not appear to be any relevant changes between the version of Xen in
the test and xen-4.1-testing.

The failure itself is because of a XEN_DOMCTL_scheduler_op (trace below)
from dom0, targeting the VCPU of the migrating domain.

(XEN) Xen call trace:
(XEN)       [<ffff82c480116a14>] csched_vcpu_sleep+0x44/0x70
(XEN)      0[<ffff82c480120117>] vcpu_sleep_nosync+0xe7/0x3b0
(XEN)     12[<ffff82c4801203e9>] vcpu_sleep_sync+0x9/0x50
(XEN)     14[<ffff82c48011fd4c>] sched_adjust+0xac/0x230
(XEN)     24[<ffff82c480102bc1>] do_domctl+0x731/0x1130
(XEN)     64[<ffff82c4802013c4>] compat_hypercall+0x74/0x80

The relevant part of csched_vcpu_sleep() is

    else if ( __vcpu_on_runq(svc) )
        __runq_remove(svc);

which disassembles to

ffff82c480116a01:       49 8b 10                mov    (%r8),%rdx
ffff82c480116a04:       4c 39 c2                cmp    %r8,%rdx
ffff82c480116a07:       75 07                   jne    ffff82c480116a10
<csched_vcpu_sleep+0x40>
ffff82c480116a09:       f3 c3                   repz retq
ffff82c480116a0b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
ffff82c480116a10:       49 8b 40 08             mov    0x8(%r8),%rax
ffff82c480116a14:       48 89 42 08             mov    %rax,0x8(%rdx) #
<- Pagefault here
ffff82c480116a18:       48 89 10                mov    %rdx,(%rax)
ffff82c480116a1b:       4d 89 40 08             mov    %r8,0x8(%r8)
ffff82c480116a1f:       4d 89 00                mov    %r8,(%r8)

The relevant crash registers from the pagefault are:
rax: 0000000000000000
rdx: 0000000000000000
 r8: ffff83080c89ed90

If I am reading the code correctly, this means that runq->next is NULL,
so we fail list_empty() and erroneously pass __vcpu_on_runq().  We then
fail with a fault when trying to update runq->prev, which is also NULL.

The only place I can spot in the code where the runq->{next,prev} could
conceivably be NULL is in csched_alloc_vdata() between the memset() and
INIT_LIST_HEAD().  This is logically sensible in combination with the
localhost migrate loop, and I cant immediately see anything to prevent
this race happening.

Can anyone with more knowledge than me in this area of code comment on
the plausibility of my analysis?  Unfortunately, I cant see an easy
solution.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 18:11:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 18:11: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 1U7VBI-000075-IV; Mon, 18 Feb 2013 18:11:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7VBH-00006y-Hd
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 18:11:11 +0000
Received: from [85.158.139.83:4332] by server-10.bemta-5.messagelabs.com id
	CF/B5-04697-EBE62215; Mon, 18 Feb 2013 18:11:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361211068!27849588!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMwNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18329 invoked from network); 18 Feb 2013 18:11:10 -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;
	18 Feb 2013 18:11:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,689,1355097600"; 
   d="scan'208";a="7641497"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 18:11:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 13:11:07 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U7VBD-000705-Q6;
	Mon, 18 Feb 2013 18:11:07 +0000
Message-ID: <51226EBB.3030503@citrix.com>
Date: Mon, 18 Feb 2013 18:11:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>, George Dunlap
	<George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>, Jan Beulich
	<JBeulich@suse.com>
X-Enigmail-Version: 1.4
Subject: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Our testing has discovered a crash (pagefault at 0x0000000000000008)
which I have tracked down to bad __runq_remove() in csched_vcpu_sleep()
in sched_credit.c (because a static function of the same name also
exists in sched_credit2.c, which confused matters to start with)

The test case was a loop of localhost migrate of a 1vcpu HVM win8
domain.  The test case itself has passed many times in the past on the
same Xen codebase (Xen-4.1.3), indicating that it is very rare.  There
does not appear to be any relevant changes between the version of Xen in
the test and xen-4.1-testing.

The failure itself is because of a XEN_DOMCTL_scheduler_op (trace below)
from dom0, targeting the VCPU of the migrating domain.

(XEN) Xen call trace:
(XEN)       [<ffff82c480116a14>] csched_vcpu_sleep+0x44/0x70
(XEN)      0[<ffff82c480120117>] vcpu_sleep_nosync+0xe7/0x3b0
(XEN)     12[<ffff82c4801203e9>] vcpu_sleep_sync+0x9/0x50
(XEN)     14[<ffff82c48011fd4c>] sched_adjust+0xac/0x230
(XEN)     24[<ffff82c480102bc1>] do_domctl+0x731/0x1130
(XEN)     64[<ffff82c4802013c4>] compat_hypercall+0x74/0x80

The relevant part of csched_vcpu_sleep() is

    else if ( __vcpu_on_runq(svc) )
        __runq_remove(svc);

which disassembles to

ffff82c480116a01:       49 8b 10                mov    (%r8),%rdx
ffff82c480116a04:       4c 39 c2                cmp    %r8,%rdx
ffff82c480116a07:       75 07                   jne    ffff82c480116a10
<csched_vcpu_sleep+0x40>
ffff82c480116a09:       f3 c3                   repz retq
ffff82c480116a0b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
ffff82c480116a10:       49 8b 40 08             mov    0x8(%r8),%rax
ffff82c480116a14:       48 89 42 08             mov    %rax,0x8(%rdx) #
<- Pagefault here
ffff82c480116a18:       48 89 10                mov    %rdx,(%rax)
ffff82c480116a1b:       4d 89 40 08             mov    %r8,0x8(%r8)
ffff82c480116a1f:       4d 89 00                mov    %r8,(%r8)

The relevant crash registers from the pagefault are:
rax: 0000000000000000
rdx: 0000000000000000
 r8: ffff83080c89ed90

If I am reading the code correctly, this means that runq->next is NULL,
so we fail list_empty() and erroneously pass __vcpu_on_runq().  We then
fail with a fault when trying to update runq->prev, which is also NULL.

The only place I can spot in the code where the runq->{next,prev} could
conceivably be NULL is in csched_alloc_vdata() between the memset() and
INIT_LIST_HEAD().  This is logically sensible in combination with the
localhost migrate loop, and I cant immediately see anything to prevent
this race happening.

Can anyone with more knowledge than me in this area of code comment on
the plausibility of my analysis?  Unfortunately, I cant see an easy
solution.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:10:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:10: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 1U7X1v-0000yk-L2; Mon, 18 Feb 2013 20:09:39 +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 1U7X1t-0000yR-Ro; Mon, 18 Feb 2013 20:09:38 +0000
Received: from [85.158.138.51:20976] by server-10.bemta-3.messagelabs.com id
	80/15-10609-08A82215; Mon, 18 Feb 2013 20:09:36 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361218174!28147797!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32767 invoked from network); 18 Feb 2013 20:09:35 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2013 20:09:35 -0000
Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com
	[209.85.210.176]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id r1IK9WQq027053
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL);
	Mon, 18 Feb 2013 12:09:32 -0800
Received: by mail-ia0-f176.google.com with SMTP id i18so5398378iac.35
	for <multiple recipients>; Mon, 18 Feb 2013 12:09:31 -0800 (PST)
X-Received: by 10.50.37.162 with SMTP id z2mr7215343igj.13.1361218170943; Mon,
	18 Feb 2013 12:09:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.2.67 with HTTP; Mon, 18 Feb 2013 12:08:50 -0800 (PST)
In-Reply-To: <CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 18 Feb 2013 15:08:50 -0500
Message-ID: <CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
To: Hery Dian Septama <herydians@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	agya naila <agya.naila@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
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: 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
 sorry for the delayed response. IIRC the blktap2 driver required for
tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
 I havent used it in a long time myself. I suggest trying disk
replication with DRBD.

thanks
shriram

On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com> wrote:
> Hello, Anyone have a clue? I have tried but still failed :(
>
> On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com> wrote:
>>
>> Dear all,
>>
>> I am configure my machine to run the remus disk replication. I am using
>> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0 and
>> DomU.
>> I have install the blktap and its work properly with configuration string
>> phy or tap2 like this :
>> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>> or
>> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>>
>> and remus command
>>
>> remus --no-net myvm mybackuphost
>>
>>
>> However when I change the string as suggested on remus pages to enable the
>> disk replication its still failed :
>>
>> name = "DomU"
>> memory = 1024
>> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>> vif = ['ip=192.168.1.55,bridge=xenbr0']
>> bootloader = "pygrub"
>>
>> with error messages :
>>
>> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>> Using config file "/etc/xen/DomU.cfg".
>> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed
>> (512  )
>>
>> and on the log file :
>>
>>
>> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line
>> 3987, in create_vbd
>>     devid = dev_control.createDevice(config)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> line 174, in createDevice
>>     device = TapdiskController.create(params, file)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> line 286, in create
>>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> line 233, in exc
>>     (args, rc, out, err))
>> TapdiskException: ('create',
>> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>>
>> Any hints and help would very appreciated.
>>
>> Regards,
>>
>> Agya
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Feb 18 20:10:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:10: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 1U7X1v-0000yk-L2; Mon, 18 Feb 2013 20:09:39 +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 1U7X1t-0000yR-Ro; Mon, 18 Feb 2013 20:09:38 +0000
Received: from [85.158.138.51:20976] by server-10.bemta-3.messagelabs.com id
	80/15-10609-08A82215; Mon, 18 Feb 2013 20:09:36 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361218174!28147797!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32767 invoked from network); 18 Feb 2013 20:09:35 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2013 20:09:35 -0000
Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com
	[209.85.210.176]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id r1IK9WQq027053
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL);
	Mon, 18 Feb 2013 12:09:32 -0800
Received: by mail-ia0-f176.google.com with SMTP id i18so5398378iac.35
	for <multiple recipients>; Mon, 18 Feb 2013 12:09:31 -0800 (PST)
X-Received: by 10.50.37.162 with SMTP id z2mr7215343igj.13.1361218170943; Mon,
	18 Feb 2013 12:09:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.2.67 with HTTP; Mon, 18 Feb 2013 12:08:50 -0800 (PST)
In-Reply-To: <CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 18 Feb 2013 15:08:50 -0500
Message-ID: <CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
To: Hery Dian Septama <herydians@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	agya naila <agya.naila@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
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: 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
 sorry for the delayed response. IIRC the blktap2 driver required for
tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
 I havent used it in a long time myself. I suggest trying disk
replication with DRBD.

thanks
shriram

On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com> wrote:
> Hello, Anyone have a clue? I have tried but still failed :(
>
> On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com> wrote:
>>
>> Dear all,
>>
>> I am configure my machine to run the remus disk replication. I am using
>> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0 and
>> DomU.
>> I have install the blktap and its work properly with configuration string
>> phy or tap2 like this :
>> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>> or
>> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>>
>> and remus command
>>
>> remus --no-net myvm mybackuphost
>>
>>
>> However when I change the string as suggested on remus pages to enable the
>> disk replication its still failed :
>>
>> name = "DomU"
>> memory = 1024
>> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>> vif = ['ip=192.168.1.55,bridge=xenbr0']
>> bootloader = "pygrub"
>>
>> with error messages :
>>
>> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>> Using config file "/etc/xen/DomU.cfg".
>> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed
>> (512  )
>>
>> and on the log file :
>>
>>
>> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line
>> 3987, in create_vbd
>>     devid = dev_control.createDevice(config)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> line 174, in createDevice
>>     device = TapdiskController.create(params, file)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> line 286, in create
>>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
>>   File
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> line 233, in exc
>>     (args, rc, out, err))
>> TapdiskException: ('create',
>> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>>
>> Any hints and help would very appreciated.
>>
>> Regards,
>>
>> Agya
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Feb 18 20:10:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:10: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 1U7X1u-0000ya-6Z; Mon, 18 Feb 2013 20:09:38 +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 1U7X1s-0000yQ-R8
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 20:09:37 +0000
Received: from [85.158.143.35:40259] by server-1.bemta-4.messagelabs.com id
	DF/24-08839-08A82215; Mon, 18 Feb 2013 20:09:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1361218173!3945040!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzIzNDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzIzNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9846 invoked from network); 18 Feb 2013 20:09:33 -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 SMTP;
	18 Feb 2013 20:09:33 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5rDcwdbPbyE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-078-137.pools.arcor-ip.net [88.65.78.137])
	by smtp.strato.de (joses mo44) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j01ed2p1IIwV48
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 21:09:32 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 25F1C1863F
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 21:09:32 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b096442271cf6a0d12510b4ee95d251f3dd63ea9
Message-Id: <b096442271cf6a0d1251.1361218171@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Mon, 18 Feb 2013 21:09:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/libxc: perpare xc_domain_save for
	upcoming changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1361218116 -3600
# Node ID b096442271cf6a0d12510b4ee95d251f3dd63ea9
# Parent  6e66717b75a9f3797b43b73ea6c328a9cb44f9f1
tools/libxc: perpare xc_domain_save for upcoming changes

An upcoming patch will pass min_remaining to xc_domain_save.
Because such a will be an API change, take the opportunity to change the
API so that it will be easier to pass more options in the future.

- remove the hvm parameter, its already in flags XCFLAGS_HVM
- move flags, max_iters, max_factor and vm_generation_addr into a new
  struct xc_domain_save_props
- bump SONAME due to the incompatible change

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6e66717b75a9 -r b096442271cf tools/libxc/Makefile
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -1,7 +1,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR    = 4.2
+MAJOR    = 4.3
 MINOR    = 0
 
 CTRL_SRCS-y       :=
diff -r 6e66717b75a9 -r b096442271cf tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -793,17 +793,19 @@ static int save_tsc_info(xc_interface *x
     return 0;
 }
 
-int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
-                   uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm,
-                   unsigned long vm_generationid_addr)
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
+                   struct xc_domain_save_props *props,
+                   struct save_callbacks *callbacks)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
 
+    uint32_t max_iters, max_factor;
+    uint32_t flags = props->flags;
     int rc = 1, frc, i, j, last_iter = 0, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
+    int hvm = (flags & XCFLAGS_HVM);
     int superpages = !!hvm;
     int race = 0, sent_last_iter, skip_this_iter = 0;
     unsigned int sent_this_iter = 0;
@@ -902,8 +904,8 @@ int xc_domain_save(xc_interface *xch, in
     memset(ctx, 0, sizeof(*ctx));
 
     /* If no explicit control parameters given, use defaults */
-    max_iters  = max_iters  ? : DEF_MAX_ITERS;
-    max_factor = max_factor ? : DEF_MAX_FACTOR;
+    max_iters  = props->max_iters  ? : DEF_MAX_ITERS;
+    max_factor = props->max_factor ? : DEF_MAX_FACTOR;
 
     if ( !get_platform_info(xch, dom,
                             &ctx->max_mfn, &ctx->hvirt_start, &ctx->pt_levels, &dinfo->guest_width) )
@@ -1623,7 +1625,7 @@ int xc_domain_save(xc_interface *xch, in
         } chunk = { 0, };
 
         chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
-        chunk.data = vm_generationid_addr;
+        chunk.data = props->vm_generationid_addr;
 
         if ( (chunk.data != 0) &&
              wrexact(io_fd, &chunk, sizeof(chunk)) )
diff -r 6e66717b75a9 -r b096442271cf tools/libxc/xc_nomigrate.c
--- a/tools/libxc/xc_nomigrate.c
+++ b/tools/libxc/xc_nomigrate.c
@@ -21,10 +21,9 @@
 #include <xenctrl.h>
 #include <xenguest.h>
 
-int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
-                   uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm,
-                   unsigned long vm_generationid_addr)
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
+                   struct xc_domain_save_props *props,
+                   struct save_callbacks *callbacks)
 {
     errno = ENOSYS;
     return -1;
diff -r 6e66717b75a9 -r b096442271cf tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -76,6 +76,13 @@ struct save_callbacks {
     void* data;
 };
 
+struct xc_domain_save_props {
+    uint32_t max_iters;
+    uint32_t max_factor;
+    uint32_t flags; /* XCFLAGS_xxx */
+    unsigned long vm_generationid_addr;
+};
+
 /**
  * This function will save a running domain.
  *
@@ -84,11 +91,9 @@ struct save_callbacks {
  * @parm dom the id of the domain
  * @return 0 on success, -1 on failure
  */
-int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
-                   uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm,
-                   unsigned long vm_generationid_addr);
-
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
+                   struct xc_domain_save_props *props,
+                   struct save_callbacks *callbacks);
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
diff -r 6e66717b75a9 -r b096442271cf tools/libxl/libxl_save_helper.c
--- a/tools/libxl/libxl_save_helper.c
+++ b/tools/libxl/libxl_save_helper.c
@@ -216,17 +216,17 @@ int main(int argc, char **argv)
     assert(mode);
 
     if (!strcmp(mode,"--save-domain")) {
-
-        int io_fd =                atoi(NEXTARG);
-        uint32_t dom =             strtoul(NEXTARG,0,10);
-        uint32_t max_iters =       strtoul(NEXTARG,0,10);
-        uint32_t max_factor =      strtoul(NEXTARG,0,10);
-        uint32_t flags =           strtoul(NEXTARG,0,10);
-        int hvm =                  atoi(NEXTARG);
-        unsigned long genidad =    strtoul(NEXTARG,0,10);
-        toolstack_save_fd  =       atoi(NEXTARG);
-        toolstack_save_len =       strtoul(NEXTARG,0,10);
-        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        struct xc_domain_save_props props = { };
+        unsigned cbflags;
+        int io_fd =                  atoi(NEXTARG);
+        uint32_t dom =               strtoul(NEXTARG,0,10);
+        props.max_iters =            strtoul(NEXTARG,0,10);
+        props.max_factor =           strtoul(NEXTARG,0,10);
+        props.flags =                strtoul(NEXTARG,0,10);
+        props.vm_generationid_addr = strtoul(NEXTARG,0,10);
+        toolstack_save_fd  =         atoi(NEXTARG);
+        toolstack_save_len =         strtoul(NEXTARG,0,10);
+        cbflags =                    strtoul(NEXTARG,0,10);
         assert(!*++argv);
 
         if (toolstack_save_fd >= 0)
@@ -235,8 +235,7 @@ int main(int argc, char **argv)
         helper_setcallbacks_save(&helper_save_callbacks, cbflags);
 
         startup("save");
-        r = xc_domain_save(xch, io_fd, dom, max_iters, max_factor, flags,
-                           &helper_save_callbacks, hvm, genidad);
+        r = xc_domain_save(xch, io_fd, dom, &props, &helper_save_callbacks);
         complete(r);
 
     } else if (!strcmp(mode,"--restore-domain")) {
diff -r 6e66717b75a9 -r b096442271cf tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
@@ -173,9 +173,8 @@ int checkpoint_start(checkpoint_state* s
 		     struct save_callbacks* callbacks,
 		     unsigned int remus_flags)
 {
+    struct xc_domain_save_props props = { .flags = XCFLAGS_LIVE };
     int hvm, rc;
-    int flags = XCFLAGS_LIVE;
-    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -192,22 +191,19 @@ int checkpoint_start(checkpoint_state* s
        sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
        addr = xs_read(s->xsh, XBT_NULL, path, NULL);
 
-       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       props.vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
        free(addr);
 
-       flags |= XCFLAGS_HVM;
+       props.flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
-    } else {
-       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
-      flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+      props.flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
-                        vm_generationid_addr);
+    rc = xc_domain_save(s->xch, fd, s->domid, &props, callbacks);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 6e66717b75a9 -r b096442271cf tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -175,7 +175,8 @@ int
 main(int argc, char **argv)
 {
     xc_interface *xch;
-    unsigned int maxit, max_f, lflags;
+    struct xc_domain_save_props props = { };
+    unsigned int lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
     xentoollog_level lvl;
@@ -186,10 +187,11 @@ main(int argc, char **argv)
 
     io_fd = atoi(argv[1]);
     si.domid = atoi(argv[2]);
-    maxit = atoi(argv[3]);
-    max_f = atoi(argv[4]);
+    props.max_iters = atoi(argv[3]);
+    props.max_factor = atoi(argv[4]);
     si.flags = atoi(argv[5]);
 
+    props.flags = si.flags;
     si.suspend_evtchn = -1;
 
     lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
@@ -221,8 +223,7 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
-    ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
+    ret = xc_domain_save(si.xch, io_fd, si.domid, &props, &callbacks);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:10:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:10: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 1U7X1u-0000ya-6Z; Mon, 18 Feb 2013 20:09:38 +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 1U7X1s-0000yQ-R8
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 20:09:37 +0000
Received: from [85.158.143.35:40259] by server-1.bemta-4.messagelabs.com id
	DF/24-08839-08A82215; Mon, 18 Feb 2013 20:09:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1361218173!3945040!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzIzNDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzIzNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9846 invoked from network); 18 Feb 2013 20:09:33 -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 SMTP;
	18 Feb 2013 20:09:33 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5rDcwdbPbyE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-078-137.pools.arcor-ip.net [88.65.78.137])
	by smtp.strato.de (joses mo44) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j01ed2p1IIwV48
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 21:09:32 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 25F1C1863F
	for <xen-devel@lists.xen.org>; Mon, 18 Feb 2013 21:09:32 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b096442271cf6a0d12510b4ee95d251f3dd63ea9
Message-Id: <b096442271cf6a0d1251.1361218171@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Mon, 18 Feb 2013 21:09:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/libxc: perpare xc_domain_save for
	upcoming changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1361218116 -3600
# Node ID b096442271cf6a0d12510b4ee95d251f3dd63ea9
# Parent  6e66717b75a9f3797b43b73ea6c328a9cb44f9f1
tools/libxc: perpare xc_domain_save for upcoming changes

An upcoming patch will pass min_remaining to xc_domain_save.
Because such a will be an API change, take the opportunity to change the
API so that it will be easier to pass more options in the future.

- remove the hvm parameter, its already in flags XCFLAGS_HVM
- move flags, max_iters, max_factor and vm_generation_addr into a new
  struct xc_domain_save_props
- bump SONAME due to the incompatible change

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 6e66717b75a9 -r b096442271cf tools/libxc/Makefile
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -1,7 +1,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR    = 4.2
+MAJOR    = 4.3
 MINOR    = 0
 
 CTRL_SRCS-y       :=
diff -r 6e66717b75a9 -r b096442271cf tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -793,17 +793,19 @@ static int save_tsc_info(xc_interface *x
     return 0;
 }
 
-int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
-                   uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm,
-                   unsigned long vm_generationid_addr)
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
+                   struct xc_domain_save_props *props,
+                   struct save_callbacks *callbacks)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
 
+    uint32_t max_iters, max_factor;
+    uint32_t flags = props->flags;
     int rc = 1, frc, i, j, last_iter = 0, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
+    int hvm = (flags & XCFLAGS_HVM);
     int superpages = !!hvm;
     int race = 0, sent_last_iter, skip_this_iter = 0;
     unsigned int sent_this_iter = 0;
@@ -902,8 +904,8 @@ int xc_domain_save(xc_interface *xch, in
     memset(ctx, 0, sizeof(*ctx));
 
     /* If no explicit control parameters given, use defaults */
-    max_iters  = max_iters  ? : DEF_MAX_ITERS;
-    max_factor = max_factor ? : DEF_MAX_FACTOR;
+    max_iters  = props->max_iters  ? : DEF_MAX_ITERS;
+    max_factor = props->max_factor ? : DEF_MAX_FACTOR;
 
     if ( !get_platform_info(xch, dom,
                             &ctx->max_mfn, &ctx->hvirt_start, &ctx->pt_levels, &dinfo->guest_width) )
@@ -1623,7 +1625,7 @@ int xc_domain_save(xc_interface *xch, in
         } chunk = { 0, };
 
         chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
-        chunk.data = vm_generationid_addr;
+        chunk.data = props->vm_generationid_addr;
 
         if ( (chunk.data != 0) &&
              wrexact(io_fd, &chunk, sizeof(chunk)) )
diff -r 6e66717b75a9 -r b096442271cf tools/libxc/xc_nomigrate.c
--- a/tools/libxc/xc_nomigrate.c
+++ b/tools/libxc/xc_nomigrate.c
@@ -21,10 +21,9 @@
 #include <xenctrl.h>
 #include <xenguest.h>
 
-int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
-                   uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm,
-                   unsigned long vm_generationid_addr)
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
+                   struct xc_domain_save_props *props,
+                   struct save_callbacks *callbacks)
 {
     errno = ENOSYS;
     return -1;
diff -r 6e66717b75a9 -r b096442271cf tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -76,6 +76,13 @@ struct save_callbacks {
     void* data;
 };
 
+struct xc_domain_save_props {
+    uint32_t max_iters;
+    uint32_t max_factor;
+    uint32_t flags; /* XCFLAGS_xxx */
+    unsigned long vm_generationid_addr;
+};
+
 /**
  * This function will save a running domain.
  *
@@ -84,11 +91,9 @@ struct save_callbacks {
  * @parm dom the id of the domain
  * @return 0 on success, -1 on failure
  */
-int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
-                   uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm,
-                   unsigned long vm_generationid_addr);
-
+int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom,
+                   struct xc_domain_save_props *props,
+                   struct save_callbacks *callbacks);
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
diff -r 6e66717b75a9 -r b096442271cf tools/libxl/libxl_save_helper.c
--- a/tools/libxl/libxl_save_helper.c
+++ b/tools/libxl/libxl_save_helper.c
@@ -216,17 +216,17 @@ int main(int argc, char **argv)
     assert(mode);
 
     if (!strcmp(mode,"--save-domain")) {
-
-        int io_fd =                atoi(NEXTARG);
-        uint32_t dom =             strtoul(NEXTARG,0,10);
-        uint32_t max_iters =       strtoul(NEXTARG,0,10);
-        uint32_t max_factor =      strtoul(NEXTARG,0,10);
-        uint32_t flags =           strtoul(NEXTARG,0,10);
-        int hvm =                  atoi(NEXTARG);
-        unsigned long genidad =    strtoul(NEXTARG,0,10);
-        toolstack_save_fd  =       atoi(NEXTARG);
-        toolstack_save_len =       strtoul(NEXTARG,0,10);
-        unsigned cbflags =         strtoul(NEXTARG,0,10);
+        struct xc_domain_save_props props = { };
+        unsigned cbflags;
+        int io_fd =                  atoi(NEXTARG);
+        uint32_t dom =               strtoul(NEXTARG,0,10);
+        props.max_iters =            strtoul(NEXTARG,0,10);
+        props.max_factor =           strtoul(NEXTARG,0,10);
+        props.flags =                strtoul(NEXTARG,0,10);
+        props.vm_generationid_addr = strtoul(NEXTARG,0,10);
+        toolstack_save_fd  =         atoi(NEXTARG);
+        toolstack_save_len =         strtoul(NEXTARG,0,10);
+        cbflags =                    strtoul(NEXTARG,0,10);
         assert(!*++argv);
 
         if (toolstack_save_fd >= 0)
@@ -235,8 +235,7 @@ int main(int argc, char **argv)
         helper_setcallbacks_save(&helper_save_callbacks, cbflags);
 
         startup("save");
-        r = xc_domain_save(xch, io_fd, dom, max_iters, max_factor, flags,
-                           &helper_save_callbacks, hvm, genidad);
+        r = xc_domain_save(xch, io_fd, dom, &props, &helper_save_callbacks);
         complete(r);
 
     } else if (!strcmp(mode,"--restore-domain")) {
diff -r 6e66717b75a9 -r b096442271cf tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
@@ -173,9 +173,8 @@ int checkpoint_start(checkpoint_state* s
 		     struct save_callbacks* callbacks,
 		     unsigned int remus_flags)
 {
+    struct xc_domain_save_props props = { .flags = XCFLAGS_LIVE };
     int hvm, rc;
-    int flags = XCFLAGS_LIVE;
-    unsigned long vm_generationid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -192,22 +191,19 @@ int checkpoint_start(checkpoint_state* s
        sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
        addr = xs_read(s->xsh, XBT_NULL, path, NULL);
 
-       vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       props.vm_generationid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
        free(addr);
 
-       flags |= XCFLAGS_HVM;
+       props.flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
-    } else {
-       vm_generationid_addr = 0;
     }
     if (remus_flags & CHECKPOINT_FLAGS_COMPRESSION)
-      flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+      props.flags |= XCFLAGS_CHECKPOINT_COMPRESS;
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm,
-                        vm_generationid_addr);
+    rc = xc_domain_save(s->xch, fd, s->domid, &props, callbacks);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 6e66717b75a9 -r b096442271cf tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c
+++ b/tools/xcutils/xc_save.c
@@ -175,7 +175,8 @@ int
 main(int argc, char **argv)
 {
     xc_interface *xch;
-    unsigned int maxit, max_f, lflags;
+    struct xc_domain_save_props props = { };
+    unsigned int lflags;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
     xentoollog_level lvl;
@@ -186,10 +187,11 @@ main(int argc, char **argv)
 
     io_fd = atoi(argv[1]);
     si.domid = atoi(argv[2]);
-    maxit = atoi(argv[3]);
-    max_f = atoi(argv[4]);
+    props.max_iters = atoi(argv[3]);
+    props.max_factor = atoi(argv[4]);
     si.flags = atoi(argv[5]);
 
+    props.flags = si.flags;
     si.suspend_evtchn = -1;
 
     lvl = si.flags & XCFLAGS_DEBUG ? XTL_DEBUG: XTL_DETAIL;
@@ -221,8 +223,7 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
-    ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM), 0);
+    ret = xc_domain_save(si.xch, io_fd, si.domid, &props, &callbacks);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:17:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:17: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 1U7X8r-0001YX-KK; Mon, 18 Feb 2013 20:16:49 +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 1U7X8p-0001YM-VK
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:16:48 +0000
Received: from [193.109.254.147:39818] by server-9.bemta-14.messagelabs.com id
	36/18-30867-F2C82215; Mon, 18 Feb 2013 20:16:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361218601!8682612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29603 invoked from network); 18 Feb 2013 20:16:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:16:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,690,1355097600"; 
   d="scan'208";a="8050167"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 20:16:41 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 15:16:40 -0500
Message-ID: <51228C27.7050000@citrix.com>
Date: Mon, 18 Feb 2013 20:16:39 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1361200766.1051.5.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361200766.1051.5.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 15:19, Ian Campbell wrote:
> On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
>> Except for a lack of information of the required memory barriers (to be
>> included in draft C), this should now be completely enough to start on a
>> prototype (any volunteers? ;).
> 
> I think the real question is whether you as creator of the design are
> going to be working on the implementation. That would the usual
> progression of things.

Yes, but I can't work on it full-time.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:17:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:17: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 1U7X8r-0001YX-KK; Mon, 18 Feb 2013 20:16:49 +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 1U7X8p-0001YM-VK
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:16:48 +0000
Received: from [193.109.254.147:39818] by server-9.bemta-14.messagelabs.com id
	36/18-30867-F2C82215; Mon, 18 Feb 2013 20:16:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361218601!8682612!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk1MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29603 invoked from network); 18 Feb 2013 20:16:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:16:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,690,1355097600"; 
   d="scan'208";a="8050167"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	18 Feb 2013 20:16:41 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 18 Feb 2013 15:16:40 -0500
Message-ID: <51228C27.7050000@citrix.com>
Date: Mon, 18 Feb 2013 20:16:39 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1361200766.1051.5.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361200766.1051.5.camel@zakaz.uk.xensource.com>
X-Originating-IP: [10.80.2.76]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 15:19, Ian Campbell wrote:
> On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
>> Except for a lack of information of the required memory barriers (to be
>> included in draft C), this should now be completely enough to start on a
>> prototype (any volunteers? ;).
> 
> I think the real question is whether you as creator of the design are
> going to be working on the implementation. That would the usual
> progression of things.

Yes, but I can't work on it full-time.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:21:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20: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 1U7XDW-0001wM-0s; Mon, 18 Feb 2013 20:21:38 +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 1U7XDU-0001wD-71
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:21:36 +0000
Received: from [85.158.139.211:18961] by server-10.bemta-5.messagelabs.com id
	2D/2D-04697-F4D82215; Mon, 18 Feb 2013 20:21:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361218894!18157901!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15735 invoked from network); 18 Feb 2013 20:21:34 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:21:34 -0000
Received: by mail-we0-f173.google.com with SMTP id r5so4900804wey.4
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 12:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Q7OUyaXYJ64y016exgzE4u8u/xrbr97MH6hH243Y/IA=;
	b=CmQabMYfW06afesDQZQ4V23K1gpajArNs6MZuTnZn8G336zIoD8A55ZwbkKHT3Bd/I
	N1NrAltYQ8cd7dBWnNlrMUN4KUaAOAAS4aBPRrvyGzRejO2bV1OWhYxIq5CykVOHz51U
	E6/rnPbEyOymoMvzBwZ2OGWv0Law2dCD276RI6uxgHZr0pppGLG6GFFB1ug21YxE2xLV
	4oD5OcOqUTqO4VfQP9dfTTwGTsjmXgDbb4L8nnrIwl9f9bVUnDcrxIlSgRxMdJqIHG40
	ixVCqKuP1VlDX9k+AjG7MXlAqUznctIcV9C4w5CjTeja+8ItNqR/1qDLCa2/JJdIL0V0
	rdBw==
X-Received: by 10.194.57.206 with SMTP id k14mr21714508wjq.26.1361218894485;
	Mon, 18 Feb 2013 12:21:34 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ec3sm22025305wib.1.2013.02.18.12.21.31
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 12:21:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 18 Feb 2013 20:21:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD483DC6.4C36E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] FIFO-based event channel ABI design (draft B)
Thread-Index: Ac4OFYbcr/pLdJtFv0eIVgrhaeQmmQ==
In-Reply-To: <1361200766.1051.5.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 15:19, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
>> Except for a lack of information of the required memory barriers (to be
>> included in draft C), this should now be completely enough to start on a
>> prototype (any volunteers? ;).
> 
> I think the real question is whether you as creator of the design are
> going to be working on the implementation. That would the usual
> progression of things.
> 
> As I see it we have on the one hand a substantially complete
> implementation of one solution and a design draft of the other with
> nobody signed up to even implement a prototype at the moment.
> 
> Given that I think we should surely go with the available solution for
> 4.3, which does meet our current needs AFAICT (most of the stuff which
> the other design adds is gravy AFAICT). If something better comes along
> (be that the FIFO design or something else) in the future then we can
> consider it on its merits then.

Oh this is certainly true. I assumed David was planning to implement his
stuff, but if that's not the case, it's nice but not really going to affect
the forward progress of the existing 3-level patches into xen-unstable.

 -- 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 Mon Feb 18 20:21:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20: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 1U7XDW-0001wM-0s; Mon, 18 Feb 2013 20:21:38 +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 1U7XDU-0001wD-71
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:21:36 +0000
Received: from [85.158.139.211:18961] by server-10.bemta-5.messagelabs.com id
	2D/2D-04697-F4D82215; Mon, 18 Feb 2013 20:21:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361218894!18157901!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15735 invoked from network); 18 Feb 2013 20:21:34 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:21:34 -0000
Received: by mail-we0-f173.google.com with SMTP id r5so4900804wey.4
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 12:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Q7OUyaXYJ64y016exgzE4u8u/xrbr97MH6hH243Y/IA=;
	b=CmQabMYfW06afesDQZQ4V23K1gpajArNs6MZuTnZn8G336zIoD8A55ZwbkKHT3Bd/I
	N1NrAltYQ8cd7dBWnNlrMUN4KUaAOAAS4aBPRrvyGzRejO2bV1OWhYxIq5CykVOHz51U
	E6/rnPbEyOymoMvzBwZ2OGWv0Law2dCD276RI6uxgHZr0pppGLG6GFFB1ug21YxE2xLV
	4oD5OcOqUTqO4VfQP9dfTTwGTsjmXgDbb4L8nnrIwl9f9bVUnDcrxIlSgRxMdJqIHG40
	ixVCqKuP1VlDX9k+AjG7MXlAqUznctIcV9C4w5CjTeja+8ItNqR/1qDLCa2/JJdIL0V0
	rdBw==
X-Received: by 10.194.57.206 with SMTP id k14mr21714508wjq.26.1361218894485;
	Mon, 18 Feb 2013 12:21:34 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ec3sm22025305wib.1.2013.02.18.12.21.31
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 18 Feb 2013 12:21:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 18 Feb 2013 20:21:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CD483DC6.4C36E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] FIFO-based event channel ABI design (draft B)
Thread-Index: Ac4OFYbcr/pLdJtFv0eIVgrhaeQmmQ==
In-Reply-To: <1361200766.1051.5.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 15:19, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
>> Except for a lack of information of the required memory barriers (to be
>> included in draft C), this should now be completely enough to start on a
>> prototype (any volunteers? ;).
> 
> I think the real question is whether you as creator of the design are
> going to be working on the implementation. That would the usual
> progression of things.
> 
> As I see it we have on the one hand a substantially complete
> implementation of one solution and a design draft of the other with
> nobody signed up to even implement a prototype at the moment.
> 
> Given that I think we should surely go with the available solution for
> 4.3, which does meet our current needs AFAICT (most of the stuff which
> the other design adds is gravy AFAICT). If something better comes along
> (be that the FIFO design or something else) in the future then we can
> consider it on its merits then.

Oh this is certainly true. I assumed David was planning to implement his
stuff, but if that's not the case, it's nice but not really going to affect
the forward progress of the existing 3-level patches into xen-unstable.

 -- 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 Mon Feb 18 20:30:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20: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 1U7XLS-0002Gm-Js; Mon, 18 Feb 2013 20:29:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1U7XLR-0002Gg-G7
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:29:49 +0000
Received: from [193.109.254.147:39590] by server-2.bemta-14.messagelabs.com id
	AE/D0-16277-C3F82215; Mon, 18 Feb 2013 20:29:48 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361219380!8869068!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM3MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12149 invoked from network); 18 Feb 2013 20:29:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	18 Feb 2013 20:29:41 -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 r1IKTOCQ007389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 18 Feb 2013 15:29:24 -0500
Received: from hawk.usersys.redhat.com (dhcp-1-196.brq.redhat.com
	[10.34.1.196])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r1IKTLHX023643; Mon, 18 Feb 2013 15:29:22 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com, ian.campbell@citrix.com
Date: Mon, 18 Feb 2013 21:29:20 +0100
Message-Id: <1361219360-29176-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
a xenvif_put(). As callers of netbk_fatal_tx_err should only
have one reference to the vif at this time, then the xenvif_put
in netbk_fatal_tx_err is one too many.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/net/xen-netback/netback.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2b9520c..c23b9ec 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -893,7 +893,6 @@ static void netbk_fatal_tx_err(struct xenvif *vif)
 {
 	netdev_err(vif->dev, "fatal error; disabling device\n");
 	xenvif_carrier_off(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:30:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20: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 1U7XLS-0002Gm-Js; Mon, 18 Feb 2013 20:29:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1U7XLR-0002Gg-G7
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:29:49 +0000
Received: from [193.109.254.147:39590] by server-2.bemta-14.messagelabs.com id
	AE/D0-16277-C3F82215; Mon, 18 Feb 2013 20:29:48 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361219380!8869068!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM3MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12149 invoked from network); 18 Feb 2013 20:29:41 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	18 Feb 2013 20:29:41 -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 r1IKTOCQ007389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 18 Feb 2013 15:29:24 -0500
Received: from hawk.usersys.redhat.com (dhcp-1-196.brq.redhat.com
	[10.34.1.196])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r1IKTLHX023643; Mon, 18 Feb 2013 15:29:22 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com, ian.campbell@citrix.com
Date: Mon, 18 Feb 2013 21:29:20 +0100
Message-Id: <1361219360-29176-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
a xenvif_put(). As callers of netbk_fatal_tx_err should only
have one reference to the vif at this time, then the xenvif_put
in netbk_fatal_tx_err is one too many.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/net/xen-netback/netback.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2b9520c..c23b9ec 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -893,7 +893,6 @@ static void netbk_fatal_tx_err(struct xenvif *vif)
 {
 	netdev_err(vif->dev, "fatal error; disabling device\n");
 	xenvif_carrier_off(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 20:51:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20: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 1U7Xfr-0002Vr-I3; Mon, 18 Feb 2013 20:50:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U7Xfp-0002Vm-IR
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:50:53 +0000
Received: from [85.158.138.51:14192] by server-9.bemta-3.messagelabs.com id
	00/2A-09484-C2492215; Mon, 18 Feb 2013 20:50:52 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361220651!27986960!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14734 invoked from network); 18 Feb 2013 20:50:51 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:50:51 -0000
Received: by mail-wi0-f172.google.com with SMTP id ez12so4042559wid.17
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 12:50:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=+MMiKyjGgQzTS2RLWPsXKJ5UMFs8KPViu8T5F/2kGpA=;
	b=Ndo6tbFwweoOIv93WZsgbbQo7eqjYN/v7fIW9R8CmF43PEHcTja52GFxP1ujNlxZJX
	SOXcAE/9LG7bE/3SkqH0idq0DHztwU8WmNpktNwfjDu3n09skmByA5teu1RRTlcw71og
	6GXwFTekuvwbZUbGhP+DEHp+O5X17umfs2T696HfqCErxdHTOC+SD+rgDbwDDRtN1kP3
	VK2hxw3K5YH6gZmGkL8r3YeJifBbjI/pkgr/qwysyxMh21JhoM4Da0IsVA8NSR6oLBkQ
	EIa64x/PMNfg7EN+qtvIl1Ss7RKQ46ay0K1L4NcnxlOIhj+LkyUq2AOZf3jFlxUbI5Pc
	qbkw==
X-Received: by 10.194.236.233 with SMTP id ux9mr21779391wjc.36.1361220650761; 
	Mon, 18 Feb 2013 12:50:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.84.229 with HTTP; Mon, 18 Feb 2013 12:50:20 -0800 (PST)
In-Reply-To: <51228C27.7050000@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1361200766.1051.5.camel@zakaz.uk.xensource.com>
	<51228C27.7050000@citrix.com>
From: Wei Liu <liuw@liuw.name>
Date: Mon, 18 Feb 2013 20:50:20 +0000
Message-ID: <CAOsiSVW4jA9JQkX5vXPA5rBSX7WUTL4seLF4J9hDnFFUFfD_nw@mail.gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQkZkxfp/Fb6zDLFrMF+4eg0ijZ5rBcPpo34qwRdU2vkjUzSiJ3QrqnFx3vgJIasVtwlHzEH
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7486848675757517416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7486848675757517416==
Content-Type: multipart/alternative; boundary=089e01493ee4597d1204d605e12a

--089e01493ee4597d1204d605e12a
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 18, 2013 at 8:16 PM, David Vrabel <david.vrabel@citrix.com>wrote:

> On 18/02/13 15:19, Ian Campbell wrote:
> > On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> >> Except for a lack of information of the required memory barriers (to be
> >> included in draft C), this should now be completely enough to start on a
> >> prototype (any volunteers? ;).
> >
> > I think the real question is whether you as creator of the design are
> > going to be working on the implementation. That would the usual
> > progression of things.
>
> Yes, but I can't work on it full-time.
>
>
I would really like to help, but I'm mainly occupied by Xen network
improvement
at the moment. I will be happy to join the discussion on the new design and
share my humble two cents.

One thing I do think about is the registration interface. The naming for now
mainly focuses on N-level event channel, but there might be other models in
the
future, so I will rename it to EVTCHNOP_register_extended_event_channel and
make registering each model a subcommand of that interface. Modifications to
toolstack will also need adjustment. AFAICT the FIFO-design will be enabled
for
all guests while the 3-level design only aims for Dom0 and driver domains.
Anyway, let's discuss this later, after I post my new series.


Wei.


 David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--089e01493ee4597d1204d605e12a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Feb 18, 2013 at 8:16 PM, David Vrabel <span dir=3D=
"ltr">&lt;<a href=3D"mailto:david.vrabel@citrix.com" target=3D"_blank">davi=
d.vrabel@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On 18/02/13 15:19, Ian Campbell wrote:<b=
r>


&gt; On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:<br>
&gt;&gt; Except for a lack of information of the required memory barriers (=
to be<br>
&gt;&gt; included in draft C), this should now be completely enough to star=
t on a<br>
&gt;&gt; prototype (any volunteers? ;).<br>
&gt;<br>
&gt; I think the real question is whether you as creator of the design are<=
br>
&gt; going to be working on the implementation. That would the usual<br>
&gt; progression of things.<br>
<br>
</div>Yes, but I can&#39;t work on it full-time.<br>
<span class=3D""><font color=3D"#888888"><br></font></span></blockquote><di=
v><br></div><div style></div><div class=3D"gmail_quote"><div class=3D"gmail=
_quote">I would really like to help, but I&#39;m mainly occupied by Xen net=
work improvement</div>

<div class=3D"gmail_quote">at the moment. I will be happy to join the discu=
ssion on the new design and</div><div class=3D"gmail_quote">share my humble=
 two cents.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">

One thing I do think about is the registration interface. The naming for no=
w</div><div class=3D"gmail_quote">mainly focuses on N-level event channel, =
but there might be other models in the</div><div class=3D"gmail_quote">futu=
re, so I will rename it to EVTCHNOP_register_extended_event_channel and</di=
v>

<div class=3D"gmail_quote">make registering each model a subcommand of that=
 interface. Modifications to</div><div class=3D"gmail_quote">toolstack will=
 also need adjustment. AFAICT the FIFO-design will be enabled for</div><div=
 class=3D"gmail_quote">

all guests while the 3-level design only aims for Dom0 and driver domains.<=
/div><div class=3D"gmail_quote">Anyway, let&#39;s discuss this later, after=
 I post my new series.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">

<br></div><div class=3D"gmail_quote">Wei.</div><div><br></div></div><br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">

<span class=3D""><font color=3D"#888888">
David<br>
</font></span><div class=3D""><div class=3D"h5"><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.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div></div>

--089e01493ee4597d1204d605e12a--


--===============7486848675757517416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7486848675757517416==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 20:51:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20: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 1U7Xfr-0002Vr-I3; Mon, 18 Feb 2013 20:50:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U7Xfp-0002Vm-IR
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:50:53 +0000
Received: from [85.158.138.51:14192] by server-9.bemta-3.messagelabs.com id
	00/2A-09484-C2492215; Mon, 18 Feb 2013 20:50:52 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361220651!27986960!1
X-Originating-IP: [209.85.212.172]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14734 invoked from network); 18 Feb 2013 20:50:51 -0000
Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com)
	(209.85.212.172)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:50:51 -0000
Received: by mail-wi0-f172.google.com with SMTP id ez12so4042559wid.17
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 12:50:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=+MMiKyjGgQzTS2RLWPsXKJ5UMFs8KPViu8T5F/2kGpA=;
	b=Ndo6tbFwweoOIv93WZsgbbQo7eqjYN/v7fIW9R8CmF43PEHcTja52GFxP1ujNlxZJX
	SOXcAE/9LG7bE/3SkqH0idq0DHztwU8WmNpktNwfjDu3n09skmByA5teu1RRTlcw71og
	6GXwFTekuvwbZUbGhP+DEHp+O5X17umfs2T696HfqCErxdHTOC+SD+rgDbwDDRtN1kP3
	VK2hxw3K5YH6gZmGkL8r3YeJifBbjI/pkgr/qwysyxMh21JhoM4Da0IsVA8NSR6oLBkQ
	EIa64x/PMNfg7EN+qtvIl1Ss7RKQ46ay0K1L4NcnxlOIhj+LkyUq2AOZf3jFlxUbI5Pc
	qbkw==
X-Received: by 10.194.236.233 with SMTP id ux9mr21779391wjc.36.1361220650761; 
	Mon, 18 Feb 2013 12:50:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.84.229 with HTTP; Mon, 18 Feb 2013 12:50:20 -0800 (PST)
In-Reply-To: <51228C27.7050000@citrix.com>
References: <511E46FD.3010605@citrix.com>
	<1361200766.1051.5.camel@zakaz.uk.xensource.com>
	<51228C27.7050000@citrix.com>
From: Wei Liu <liuw@liuw.name>
Date: Mon, 18 Feb 2013 20:50:20 +0000
Message-ID: <CAOsiSVW4jA9JQkX5vXPA5rBSX7WUTL4seLF4J9hDnFFUFfD_nw@mail.gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
X-Gm-Message-State: ALoCoQkZkxfp/Fb6zDLFrMF+4eg0ijZ5rBcPpo34qwRdU2vkjUzSiJ3QrqnFx3vgJIasVtwlHzEH
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7486848675757517416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7486848675757517416==
Content-Type: multipart/alternative; boundary=089e01493ee4597d1204d605e12a

--089e01493ee4597d1204d605e12a
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 18, 2013 at 8:16 PM, David Vrabel <david.vrabel@citrix.com>wrote:

> On 18/02/13 15:19, Ian Campbell wrote:
> > On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:
> >> Except for a lack of information of the required memory barriers (to be
> >> included in draft C), this should now be completely enough to start on a
> >> prototype (any volunteers? ;).
> >
> > I think the real question is whether you as creator of the design are
> > going to be working on the implementation. That would the usual
> > progression of things.
>
> Yes, but I can't work on it full-time.
>
>
I would really like to help, but I'm mainly occupied by Xen network
improvement
at the moment. I will be happy to join the discussion on the new design and
share my humble two cents.

One thing I do think about is the registration interface. The naming for now
mainly focuses on N-level event channel, but there might be other models in
the
future, so I will rename it to EVTCHNOP_register_extended_event_channel and
make registering each model a subcommand of that interface. Modifications to
toolstack will also need adjustment. AFAICT the FIFO-design will be enabled
for
all guests while the 3-level design only aims for Dom0 and driver domains.
Anyway, let's discuss this later, after I post my new series.


Wei.


 David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--089e01493ee4597d1204d605e12a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Feb 18, 2013 at 8:16 PM, David Vrabel <span dir=3D=
"ltr">&lt;<a href=3D"mailto:david.vrabel@citrix.com" target=3D"_blank">davi=
d.vrabel@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On 18/02/13 15:19, Ian Campbell wrote:<b=
r>


&gt; On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote:<br>
&gt;&gt; Except for a lack of information of the required memory barriers (=
to be<br>
&gt;&gt; included in draft C), this should now be completely enough to star=
t on a<br>
&gt;&gt; prototype (any volunteers? ;).<br>
&gt;<br>
&gt; I think the real question is whether you as creator of the design are<=
br>
&gt; going to be working on the implementation. That would the usual<br>
&gt; progression of things.<br>
<br>
</div>Yes, but I can&#39;t work on it full-time.<br>
<span class=3D""><font color=3D"#888888"><br></font></span></blockquote><di=
v><br></div><div style></div><div class=3D"gmail_quote"><div class=3D"gmail=
_quote">I would really like to help, but I&#39;m mainly occupied by Xen net=
work improvement</div>

<div class=3D"gmail_quote">at the moment. I will be happy to join the discu=
ssion on the new design and</div><div class=3D"gmail_quote">share my humble=
 two cents.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">

One thing I do think about is the registration interface. The naming for no=
w</div><div class=3D"gmail_quote">mainly focuses on N-level event channel, =
but there might be other models in the</div><div class=3D"gmail_quote">futu=
re, so I will rename it to EVTCHNOP_register_extended_event_channel and</di=
v>

<div class=3D"gmail_quote">make registering each model a subcommand of that=
 interface. Modifications to</div><div class=3D"gmail_quote">toolstack will=
 also need adjustment. AFAICT the FIFO-design will be enabled for</div><div=
 class=3D"gmail_quote">

all guests while the 3-level design only aims for Dom0 and driver domains.<=
/div><div class=3D"gmail_quote">Anyway, let&#39;s discuss this later, after=
 I post my new series.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">

<br></div><div class=3D"gmail_quote">Wei.</div><div><br></div></div><br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">

<span class=3D""><font color=3D"#888888">
David<br>
</font></span><div class=3D""><div class=3D"h5"><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.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div></div>

--089e01493ee4597d1204d605e12a--


--===============7486848675757517416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7486848675757517416==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 20:59:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:59: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 1U7Xnl-0002gY-HB; Mon, 18 Feb 2013 20:59:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U7Xnk-0002gT-PC
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:59:04 +0000
Received: from [85.158.139.211:32002] by server-4.bemta-5.messagelabs.com id
	18/DA-29496-81692215; Mon, 18 Feb 2013 20:59:04 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361221143!18174811!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	INFO_TLD,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16839 invoked from network); 18 Feb 2013 20:59:03 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:59:03 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so4055788wic.5
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 12:59:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=Abfi9a/eomDLvD4HBj3fQFAwwS3y4/kyFVaQP+PNkE0=;
	b=fKWCj54pKS7meSzDSUvC0hAZCN7O8WUQxOo7ojQCdCdhZmE3lJ6Y9o3qbjlki8raP8
	CwxB7PHm/DiRU0AErKMm0jFXvzxTPJ3V46VNOLID2SVcu5Zpr125VJsIsQNXxZ8wZU1W
	5p3Q49/5BxAGC7gfOV5E/247pUiJGmr8qSWetzR+K9UAp3L7wcPwAqkYAm+0KsPf3Jo5
	w57fnlXxf4dLt4+gtuYY4HZ3G2nG1KdcDF0SQCfEkmEa7RZfTHI4zsaRX4nd4KSRshyv
	m0+yh6aIYiz4eKHNvQj7oq7p1ZurRvf7wfjEmAtNTEf2OlcpcXLDfatQTAV1qlKKW9Zc
	H7gQ==
X-Received: by 10.180.108.229 with SMTP id hn5mr19341332wib.28.1361221142799; 
	Mon, 18 Feb 2013 12:59:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.84.229 with HTTP; Mon, 18 Feb 2013 12:58:32 -0800 (PST)
In-Reply-To: <1361219360-29176-1-git-send-email-drjones@redhat.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
From: Wei Liu <liuw@liuw.name>
Date: Mon, 18 Feb 2013 20:58:32 +0000
Message-ID: <CAOsiSVVb1idFC3wTcZLzUrsDN7z8asFHFRsVfoHERb--y_qz4w@mail.gmail.com>
To: Andrew Jones <drjones@redhat.com>
X-Gm-Message-State: ALoCoQl7upKD/tsxd/eWLQwWvvlvIrM1Qf0jd/pWOPV+AUTgvracpmLDUv5kDWOzP7hyil57sUww
Cc: netdev@vger.kernel.org,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3340379250672368185=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3340379250672368185==
Content-Type: multipart/alternative; boundary=e89a8f3b9d9fad641a04d605fed1

--e89a8f3b9d9fad641a04d605fed1
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 18, 2013 at 8:29 PM, Andrew Jones <drjones@redhat.com> wrote:

> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> have one reference to the vif at this time, then the xenvif_put
> in netbk_fatal_tx_err is one too many.
>
>
Hmm... we had a discussion on this not long ago.

http://marc.info/?l=xen-devel&m=136084174026977&w=2

Do you actually experiencing problem?


Wei.



> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/net/xen-netback/netback.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 2b9520c..c23b9ec 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -893,7 +893,6 @@ static void netbk_fatal_tx_err(struct xenvif *vif)
>  {
>         netdev_err(vif->dev, "fatal error; disabling device\n");
>         xenvif_carrier_off(vif);
> -       xenvif_put(vif);
>  }
>
>  static int netbk_count_requests(struct xenvif *vif,
> --
> 1.8.1.2
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--e89a8f3b9d9fad641a04d605fed1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Feb 18, 2013 at 8:29 PM, Andrew Jones <span dir=3D"ltr">&lt=
;<a href=3D"mailto:drjones@redhat.com" target=3D"_blank">drjones@redhat.com=
</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">netbk_fatal_tx_err() calls xenvif_carrier_off(), which doe=
s<br>


a xenvif_put(). As callers of netbk_fatal_tx_err should only<br>
have one reference to the vif at this time, then the xenvif_put<br>
in netbk_fatal_tx_err is one too many.<br>
<br></blockquote><div><br></div><div style><div>Hmm... we had a discussion =
on this not long ago.</div><div><br></div><div><a href=3D"http://marc.info/=
?l=3Dxen-devel&amp;m=3D136084174026977&amp;w=3D2">http://marc.info/?l=3Dxen=
-devel&amp;m=3D136084174026977&amp;w=3D2</a><br>

</div><div><br></div><div>Do you actually experiencing problem?</div><div><=
br></div><div><br></div><div>Wei.</div><div><br></div></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">


Signed-off-by: Andrew Jones &lt;<a href=3D"mailto:drjones@redhat.com">drjon=
es@redhat.com</a>&gt;<br>
---<br>
=C2=A0drivers/net/xen-netback/netback.c | 1 -<br>
=C2=A01 file changed, 1 deletion(-)<br>
<br>
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/ne=
tback.c<br>
index 2b9520c..c23b9ec 100644<br>
--- a/drivers/net/xen-netback/netback.c<br>
+++ b/drivers/net/xen-netback/netback.c<br>
@@ -893,7 +893,6 @@ static void netbk_fatal_tx_err(struct xenvif *vif)<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 netdev_err(vif-&gt;dev, &quot;fatal error; disa=
bling device\n&quot;);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xenvif_carrier_off(vif);<br>
- =C2=A0 =C2=A0 =C2=A0 xenvif_put(vif);<br>
=C2=A0}<br>
<br>
=C2=A0static int netbk_count_requests(struct xenvif *vif,<br>
<span class=3D""><font color=3D"#888888">--<br>
1.8.1.2<br>
<br>
<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.x=
en.org/xen-devel</a><br>
</font></span></blockquote></div><br></div></div>

--e89a8f3b9d9fad641a04d605fed1--


--===============3340379250672368185==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3340379250672368185==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 20:59:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 20:59: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 1U7Xnl-0002gY-HB; Mon, 18 Feb 2013 20:59:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuw@liuw.name>) id 1U7Xnk-0002gT-PC
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 20:59:04 +0000
Received: from [85.158.139.211:32002] by server-4.bemta-5.messagelabs.com id
	18/DA-29496-81692215; Mon, 18 Feb 2013 20:59:04 +0000
X-Env-Sender: liuw@liuw.name
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361221143!18174811!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=2.3 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	INFO_TLD,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16839 invoked from network); 18 Feb 2013 20:59:03 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 20:59:03 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so4055788wic.5
	for <xen-devel@lists.xensource.com>;
	Mon, 18 Feb 2013 12:59:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=Abfi9a/eomDLvD4HBj3fQFAwwS3y4/kyFVaQP+PNkE0=;
	b=fKWCj54pKS7meSzDSUvC0hAZCN7O8WUQxOo7ojQCdCdhZmE3lJ6Y9o3qbjlki8raP8
	CwxB7PHm/DiRU0AErKMm0jFXvzxTPJ3V46VNOLID2SVcu5Zpr125VJsIsQNXxZ8wZU1W
	5p3Q49/5BxAGC7gfOV5E/247pUiJGmr8qSWetzR+K9UAp3L7wcPwAqkYAm+0KsPf3Jo5
	w57fnlXxf4dLt4+gtuYY4HZ3G2nG1KdcDF0SQCfEkmEa7RZfTHI4zsaRX4nd4KSRshyv
	m0+yh6aIYiz4eKHNvQj7oq7p1ZurRvf7wfjEmAtNTEf2OlcpcXLDfatQTAV1qlKKW9Zc
	H7gQ==
X-Received: by 10.180.108.229 with SMTP id hn5mr19341332wib.28.1361221142799; 
	Mon, 18 Feb 2013 12:59:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.84.229 with HTTP; Mon, 18 Feb 2013 12:58:32 -0800 (PST)
In-Reply-To: <1361219360-29176-1-git-send-email-drjones@redhat.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
From: Wei Liu <liuw@liuw.name>
Date: Mon, 18 Feb 2013 20:58:32 +0000
Message-ID: <CAOsiSVVb1idFC3wTcZLzUrsDN7z8asFHFRsVfoHERb--y_qz4w@mail.gmail.com>
To: Andrew Jones <drjones@redhat.com>
X-Gm-Message-State: ALoCoQl7upKD/tsxd/eWLQwWvvlvIrM1Qf0jd/pWOPV+AUTgvracpmLDUv5kDWOzP7hyil57sUww
Cc: netdev@vger.kernel.org,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3340379250672368185=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3340379250672368185==
Content-Type: multipart/alternative; boundary=e89a8f3b9d9fad641a04d605fed1

--e89a8f3b9d9fad641a04d605fed1
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 18, 2013 at 8:29 PM, Andrew Jones <drjones@redhat.com> wrote:

> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> have one reference to the vif at this time, then the xenvif_put
> in netbk_fatal_tx_err is one too many.
>
>
Hmm... we had a discussion on this not long ago.

http://marc.info/?l=xen-devel&m=136084174026977&w=2

Do you actually experiencing problem?


Wei.



> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/net/xen-netback/netback.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 2b9520c..c23b9ec 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -893,7 +893,6 @@ static void netbk_fatal_tx_err(struct xenvif *vif)
>  {
>         netdev_err(vif->dev, "fatal error; disabling device\n");
>         xenvif_carrier_off(vif);
> -       xenvif_put(vif);
>  }
>
>  static int netbk_count_requests(struct xenvif *vif,
> --
> 1.8.1.2
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--e89a8f3b9d9fad641a04d605fed1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Feb 18, 2013 at 8:29 PM, Andrew Jones <span dir=3D"ltr">&lt=
;<a href=3D"mailto:drjones@redhat.com" target=3D"_blank">drjones@redhat.com=
</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">netbk_fatal_tx_err() calls xenvif_carrier_off(), which doe=
s<br>


a xenvif_put(). As callers of netbk_fatal_tx_err should only<br>
have one reference to the vif at this time, then the xenvif_put<br>
in netbk_fatal_tx_err is one too many.<br>
<br></blockquote><div><br></div><div style><div>Hmm... we had a discussion =
on this not long ago.</div><div><br></div><div><a href=3D"http://marc.info/=
?l=3Dxen-devel&amp;m=3D136084174026977&amp;w=3D2">http://marc.info/?l=3Dxen=
-devel&amp;m=3D136084174026977&amp;w=3D2</a><br>

</div><div><br></div><div>Do you actually experiencing problem?</div><div><=
br></div><div><br></div><div>Wei.</div><div><br></div></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">


Signed-off-by: Andrew Jones &lt;<a href=3D"mailto:drjones@redhat.com">drjon=
es@redhat.com</a>&gt;<br>
---<br>
=C2=A0drivers/net/xen-netback/netback.c | 1 -<br>
=C2=A01 file changed, 1 deletion(-)<br>
<br>
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/ne=
tback.c<br>
index 2b9520c..c23b9ec 100644<br>
--- a/drivers/net/xen-netback/netback.c<br>
+++ b/drivers/net/xen-netback/netback.c<br>
@@ -893,7 +893,6 @@ static void netbk_fatal_tx_err(struct xenvif *vif)<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 netdev_err(vif-&gt;dev, &quot;fatal error; disa=
bling device\n&quot;);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xenvif_carrier_off(vif);<br>
- =C2=A0 =C2=A0 =C2=A0 xenvif_put(vif);<br>
=C2=A0}<br>
<br>
=C2=A0static int netbk_count_requests(struct xenvif *vif,<br>
<span class=3D""><font color=3D"#888888">--<br>
1.8.1.2<br>
<br>
<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.x=
en.org/xen-devel</a><br>
</font></span></blockquote></div><br></div></div>

--e89a8f3b9d9fad641a04d605fed1--


--===============3340379250672368185==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3340379250672368185==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 21:12:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 21:12: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 1U7Y0X-0002v8-So; Mon, 18 Feb 2013 21:12:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7Y0V-0002v0-Th; Mon, 18 Feb 2013 21:12:16 +0000
Received: from [85.158.143.35:14584] by server-3.bemta-4.messagelabs.com id
	DE/58-08920-E2992215; Mon, 18 Feb 2013 21:12:14 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1361221873!4649684!1
X-Originating-IP: [74.125.82.42]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20165 invoked from network); 18 Feb 2013 21:11:14 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 21:11:14 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so3075520wgh.5
	for <multiple recipients>; Mon, 18 Feb 2013 13:11:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=dX4XXsrZw6ZKmgAo41Se82Ywy7T6tm3Bi27cTWZv++E=;
	b=SGICjMW14G/C6dJn4r54q9kS8+sU+1EGHFmDImL/LSY6xcYdpJMLrl9zrwzw8reUId
	Qnb1u9v9A4wRbcWqlG5b7+R387AiA6Rd5nYAwXVvwBGMzBjsXVXQF4YqeqXVF3MRnwFA
	KZZqxoEzxoVctk3tpApHJiLWudmSpS2/eEoBq4qVc4Ko9gRmHDfC99LcfpPKKelUpPZ/
	TtH4V6znEwN/Jel90NHoqehqeJyBVIj+KrThQfaKkBBisR0xk5h7oRUBr12/6ytf4hYN
	wolbt0zPEden3nbA2wl2vhibiU+BcOFJsz279qMMRhozL0tyJsNFzt7VG6i+tpxONVux
	HiJw==
MIME-Version: 1.0
X-Received: by 10.180.102.7 with SMTP id fk7mr21090960wib.27.1361221872860;
	Mon, 18 Feb 2013 13:11:12 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 13:11:12 -0800 (PST)
In-Reply-To: <CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
Date: Mon, 18 Feb 2013 22:11:12 +0100
Message-ID: <CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0374238427926267882=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0374238427926267882==
Content-Type: multipart/alternative; boundary=f46d0444e7d7313d5804d6062a44

--f46d0444e7d7313d5804d6062a44
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> hi
>

Thank you shriram.


>  sorry for the delayed response. IIRC the blktap2 driver required for
> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>  I havent used it in a long time myself. I suggest trying disk
> replication with DRBD.
>
>
I am also found some information here
http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2 problem
on amd64 architecture. I have tried to install and configure the DRBD but
its didn't connect each other.
I used drbd-8.3.11-remus and installed as follow

cd /usr/src/
wget http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
tar xzf drbd-8.3.9-remus.tar.gz
chown -R root:root drbd-8.3-remus
cd /usr/src/drbd-8.3-remus
chmod 777 autogen.sh
./autogen.sh
dpkg-buildpackage -b -uc
cd /usr/src/drbd-8.3-remus/drbd
make clean
make
make install
cd /usr/src/
cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
/etc/drbd.d/global_common.conf
cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
/etc/drbd.d/SystemHA_protoD.res

sudo apt-get install drbd8-utils

 from tutorial http://remusha.wikidot.com/configuring-and-installing-remus

My *.res configuration as follow :

resource drbd-vm{
  device    /dev/drbd1;
  disk      /dev/vgvoip/DomU;
  meta-disk internal;
  on machine1 {
    address   10.10.10.1:7789;
  }
  on machine2 {
    address   10.10.10.3:7789;
  }
}

and then I invoke command to create that meta

drbdadm create-md drbd-vm

However, when I try to make this configuration up by :

drbdadm up drbd-vm

Its come with error :

$ sudo drbdadm up drbd-vm
1: Failure: (124) Device is attached to a disk (use detach first)
Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
--set-defaults --create-device --fencing=dont-care
--on-io-error=pass_on' terminated with exit code 10

If I run the

$ sudo drbdadm detach drbd-vm

Its come error

$ sudo drbdadm detach drbd-vm
1: State change failed: (-2) Need access to UpToDate data
Command 'drbdsetup 1 detach' terminated with exit code 17

Here the /proc/drbd on both machine

Machine 1

$ sudo cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
root@machine1, 2013-02-18 18:49:57

 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b
def:0 chkpt:0 oos:10485404


Machine 2

$ sudo cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
root@machine2, 2013-02-18 19:26:57

 1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
chkpt:0 oos:10485404


Do you have some hints?

Thank you,


Agya


thanks
> shriram
>
> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com>
> wrote:
> > Hello, Anyone have a clue? I have tried but still failed :(
> >
> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
> wrote:
> >>
> >> Dear all,
> >>
> >> I am configure my machine to run the remus disk replication. I am using
> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0
> and
> >> DomU.
> >> I have install the blktap and its work properly with configuration
> string
> >> phy or tap2 like this :
> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
> >> or
> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
> >>
> >> and remus command
> >>
> >> remus --no-net myvm mybackuphost
> >>
> >>
> >> However when I change the string as suggested on remus pages to enable
> the
> >> disk replication its still failed :
> >>
> >> name = "DomU"
> >> memory = 1024
> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
> >> bootloader = "pygrub"
> >>
> >> with error messages :
> >>
> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
> >> Using config file "/etc/xen/DomU.cfg".
> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
> failed
> >> (512  )
> >>
> >> and on the log file :
> >>
> >>
> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
> >>   File
> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
> line
> >> 3987, in create_vbd
> >>     devid = dev_control.createDevice(config)
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> line 174, in createDevice
> >>     device = TapdiskController.create(params, file)
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> line 286, in create
> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> line 233, in exc
> >>     (args, rc, out, err))
> >> TapdiskException: ('create',
> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
> >>
> >> Any hints and help would very appreciated.
> >>
> >> Regards,
> >>
> >> Agya
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >>
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>

--f46d0444e7d7313d5804d6062a44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Mon, Feb 18, 2013 at 9:08 PM, Shriram Raj=
agopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca" target=
=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
hi<br></blockquote><div><br></div><div>Thank you shriram.</div><div>=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
=A0sorry for the delayed response. IIRC the blktap2 driver required for<br>
tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.<br>
=A0I havent used it in a long time myself. I suggest trying disk<br>
replication with DRBD.<br>
<br></blockquote><div><br></div><div>I am also found some information here=
=A0<a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html">http://o=
sdir.com/ml/xen-users/2011-07/msg00653.html</a> about blktap2 problem on am=
d64 architecture. I have tried to install and configure the DRBD but its di=
dn&#39;t connect each other.</div>
<div>I used=A0<span style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier=
 New&#39;,Courier,monospace;font-size:13px">drbd-8.3.11-remus and installed=
 as follow=A0</span></div><div><div class=3D"code" style=3D"border:1px dash=
ed rgb(221,221,221);background-color:rgb(247,247,247);padding:0px 1em;margi=
n:0.4em 0px;overflow:auto">
<pre style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Couri=
er,monospace;font-size:13px"><code style=3D"font-family:&#39;Andale Mono&#3=
9;,&#39;Courier New&#39;,Courier,monospace">cd /usr/src/
wget <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz">http://remusha.wikidot.com/local--f=
iles/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz</a>
tar xzf drbd-8.3.9-remus.tar.gz
chown -R root:root drbd-8.3-remus=20
cd /usr/src/drbd-8.3-remus
chmod 777 autogen.sh
./autogen.sh
dpkg-buildpackage -b -uc
cd /usr/src/drbd-8.3-remus/drbd
make clean
make
make install
cd /usr/src/
cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD /etc/drbd.d/gl=
obal_common.conf
cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res /etc/drbd.d/SystemHA_=
protoD.res</code></pre><pre><code><font face=3D"Andale Mono, Courier New, C=
ourier, monospace" size=3D"3">sudo apt-get install drbd8-utils</font></code=
></pre>
</div></div><div>=A0from tutorial=A0<a href=3D"http://remusha.wikidot.com/c=
onfiguring-and-installing-remus">http://remusha.wikidot.com/configuring-and=
-installing-remus</a></div><div><br></div><div>My *.res configuration as fo=
llow :</div>
<div><br></div><div><div><font face=3D"courier new, monospace">resource drb=
d-vm{</font></div><div><font face=3D"courier new, monospace">=A0 device =A0=
 =A0/dev/drbd1;</font></div><div><font face=3D"courier new, monospace">=A0 =
disk =A0 =A0 =A0/dev/vgvoip/DomU;</font></div>
<div><font face=3D"courier new, monospace">=A0 meta-disk internal;</font></=
div><div><font face=3D"courier new, monospace">=A0 on machine1 {</font></di=
v><div><font face=3D"courier new, monospace">=A0 =A0 address =A0 <a href=3D=
"http://10.10.10.1:7789">10.10.10.1:7789</a>;</font></div>
<div><font face=3D"courier new, monospace">=A0 }</font></div><div><font fac=
e=3D"courier new, monospace">=A0 on machine2 {</font></div><div><font face=
=3D"courier new, monospace">=A0 =A0 address =A0 <a href=3D"http://10.10.10.=
3:7789">10.10.10.3:7789</a>;</font></div>
<div><font face=3D"courier new, monospace">=A0 }</font></div><div><font fac=
e=3D"courier new, monospace">}</font></div></div><div><br></div><div>and th=
en I invoke command to create that meta</div><div><br></div><div><pre style=
=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Courier,monospa=
ce;font-size:13px">
<code style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Cour=
ier,monospace">drbdadm create-md drbd-vm</code></pre><pre><code><font face=
=3D"arial, helvetica, sans-serif">However, when I try to make this configur=
ation up by :</font></code></pre>
<pre style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Couri=
er,monospace;font-size:13px"><code style=3D"font-family:&#39;Andale Mono&#3=
9;,&#39;Courier New&#39;,Courier,monospace">drbdadm up drbd-vm</code></pre>
<pre style=3D"font-size:13px"><code><font face=3D"arial, helvetica, sans-se=
rif">Its come with error :</font></code></pre><pre><code><font face=3D"Anda=
le Mono, Courier New, Courier, monospace" size=3D"3">$ sudo drbdadm up drbd=
-vm
1: Failure: (124) Device is attached to a disk (use detach first)
Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal --=
set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dpass_on&=
#39; terminated with exit code 10</font></code><code style=3D"font-family:&=
#39;Andale Mono&#39;,&#39;Courier New&#39;,Courier,monospace;font-size:13px=
">
</code></pre></div><div><code><font face=3D"arial, helvetica, sans-serif">I=
f I run the=A0</font></code></div><div><br></div><div><pre><code><font face=
=3D"Andale Mono, Courier New, Courier, monospace" size=3D"3">$ sudo drbdadm=
 detach drbd-vm</font></code></pre>
<pre><code><font face=3D"arial, helvetica, sans-serif">Its come error</font=
><font size=3D"3" face=3D"arial, helvetica, sans-serif"> </font></code></pr=
e><pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" si=
ze=3D"3">$ sudo drbdadm detach drbd-vm
1: State change failed: (-2) Need access to UpToDate data
Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17</font></c=
ode></pre><pre><code><font face=3D"arial, helvetica, sans-serif">Here the /=
proc/drbd on both machine</font></code></pre><pre><code><font face=3D"arial=
, helvetica, sans-serif">Machine 1</font></code></pre>
<pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" size=
=3D"3">$ sudo cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine1, =
2013-02-18 18:49:57

 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0 ch=
kpt:0 oos:10485404
</font></code></pre><div><code><font face=3D"Andale Mono, Courier New, Cour=
ier, monospace" size=3D"3"><br></font></code></div><pre><code><font face=3D=
"arial, helvetica, sans-serif">Machine 2</font></code></pre><pre><code><fon=
t face=3D"Andale Mono, Courier New, Courier, monospace" size=3D"3">$ sudo c=
at /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine2, =
2013-02-18 19:26:57

 1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0 chkpt=
:0 oos:10485404
</font></code></pre><div><code><font face=3D"Andale Mono, Courier New, Cour=
ier, monospace" size=3D"3"><br></font></code></div><pre><code><font face=3D=
"Andale Mono, Courier New, Courier, monospace" size=3D"3">Do you have some =
hints?</font></code></pre>
<pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" size=
=3D"3">Thank you,</font></code></pre><pre><code><font face=3D"Andale Mono, =
Courier New, Courier, monospace" size=3D"3"><br></font></code></pre><pre><c=
ode><font face=3D"Andale Mono, Courier New, Courier, monospace" size=3D"3">=
Agya</font></code></pre>
<pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" size=
=3D"3"><br></font></code></pre></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888">shriram<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"mailto:he=
rydians@gmail.com">herydians@gmail.com</a>&gt; wrote:<br>
&gt; Hello, Anyone have a clue? I have tried but still failed :(<br>
&gt;<br>
&gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"mailto:agya=
.naila@gmail.com">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Dear all,<br>
&gt;&gt;<br>
&gt;&gt; I am configure my machine to run the remus disk replication. I am =
using<br>
&gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for =
Dom0 and<br>
&gt;&gt; DomU.<br>
&gt;&gt; I have install the blktap and its work properly with configuration=
 string<br>
&gt;&gt; phy or tap2 like this :<br>
&gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; or<br>
&gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt;<br>
&gt;&gt; and remus command<br>
&gt;&gt;<br>
&gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; However when I change the string as suggested on remus pages to en=
able the<br>
&gt;&gt; disk replication its still failed :<br>
&gt;&gt;<br>
&gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; memory =3D 1024<br>
&gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xv=
da,w&#39;]<br>
&gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt;<br>
&gt;&gt; with error messages :<br>
&gt;&gt;<br>
&gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|aio:/dev/vg=
group/DomU&#39;) failed<br>
&gt;&gt; (512 =A0)<br>
&gt;&gt;<br>
&gt;&gt; and on the log file :<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br>
&gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn=
fo.py&quot;, line<br>
&gt;&gt; 3987, in create_vbd<br>
&gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;,<br>
&gt;&gt; line 174, in createDevice<br>
&gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;,<br>
&gt;&gt; line 286, in create<br>
&gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#39;-a%s:%=
s&#39; % (dtype, image))<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;,<br>
&gt;&gt; line 233, in exc<br>
&gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) failed (5=
12 =A0)<br>
&gt;&gt;<br>
&gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt;<br>
&gt;&gt; Agya<br>
&gt;&gt;<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.org=
</a><br>
&gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http:=
//lists.xen.org/xen-devel</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<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>
&gt;<br>
</div></div></blockquote></div><br>

--f46d0444e7d7313d5804d6062a44--


--===============0374238427926267882==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0374238427926267882==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 21:12:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 21:12: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 1U7Y0X-0002v8-So; Mon, 18 Feb 2013 21:12:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7Y0V-0002v0-Th; Mon, 18 Feb 2013 21:12:16 +0000
Received: from [85.158.143.35:14584] by server-3.bemta-4.messagelabs.com id
	DE/58-08920-E2992215; Mon, 18 Feb 2013 21:12:14 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1361221873!4649684!1
X-Originating-IP: [74.125.82.42]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20165 invoked from network); 18 Feb 2013 21:11:14 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 21:11:14 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so3075520wgh.5
	for <multiple recipients>; Mon, 18 Feb 2013 13:11:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=dX4XXsrZw6ZKmgAo41Se82Ywy7T6tm3Bi27cTWZv++E=;
	b=SGICjMW14G/C6dJn4r54q9kS8+sU+1EGHFmDImL/LSY6xcYdpJMLrl9zrwzw8reUId
	Qnb1u9v9A4wRbcWqlG5b7+R387AiA6Rd5nYAwXVvwBGMzBjsXVXQF4YqeqXVF3MRnwFA
	KZZqxoEzxoVctk3tpApHJiLWudmSpS2/eEoBq4qVc4Ko9gRmHDfC99LcfpPKKelUpPZ/
	TtH4V6znEwN/Jel90NHoqehqeJyBVIj+KrThQfaKkBBisR0xk5h7oRUBr12/6ytf4hYN
	wolbt0zPEden3nbA2wl2vhibiU+BcOFJsz279qMMRhozL0tyJsNFzt7VG6i+tpxONVux
	HiJw==
MIME-Version: 1.0
X-Received: by 10.180.102.7 with SMTP id fk7mr21090960wib.27.1361221872860;
	Mon, 18 Feb 2013 13:11:12 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 13:11:12 -0800 (PST)
In-Reply-To: <CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
Date: Mon, 18 Feb 2013 22:11:12 +0100
Message-ID: <CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============0374238427926267882=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0374238427926267882==
Content-Type: multipart/alternative; boundary=f46d0444e7d7313d5804d6062a44

--f46d0444e7d7313d5804d6062a44
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> hi
>

Thank you shriram.


>  sorry for the delayed response. IIRC the blktap2 driver required for
> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>  I havent used it in a long time myself. I suggest trying disk
> replication with DRBD.
>
>
I am also found some information here
http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2 problem
on amd64 architecture. I have tried to install and configure the DRBD but
its didn't connect each other.
I used drbd-8.3.11-remus and installed as follow

cd /usr/src/
wget http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
tar xzf drbd-8.3.9-remus.tar.gz
chown -R root:root drbd-8.3-remus
cd /usr/src/drbd-8.3-remus
chmod 777 autogen.sh
./autogen.sh
dpkg-buildpackage -b -uc
cd /usr/src/drbd-8.3-remus/drbd
make clean
make
make install
cd /usr/src/
cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
/etc/drbd.d/global_common.conf
cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
/etc/drbd.d/SystemHA_protoD.res

sudo apt-get install drbd8-utils

 from tutorial http://remusha.wikidot.com/configuring-and-installing-remus

My *.res configuration as follow :

resource drbd-vm{
  device    /dev/drbd1;
  disk      /dev/vgvoip/DomU;
  meta-disk internal;
  on machine1 {
    address   10.10.10.1:7789;
  }
  on machine2 {
    address   10.10.10.3:7789;
  }
}

and then I invoke command to create that meta

drbdadm create-md drbd-vm

However, when I try to make this configuration up by :

drbdadm up drbd-vm

Its come with error :

$ sudo drbdadm up drbd-vm
1: Failure: (124) Device is attached to a disk (use detach first)
Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
--set-defaults --create-device --fencing=dont-care
--on-io-error=pass_on' terminated with exit code 10

If I run the

$ sudo drbdadm detach drbd-vm

Its come error

$ sudo drbdadm detach drbd-vm
1: State change failed: (-2) Need access to UpToDate data
Command 'drbdsetup 1 detach' terminated with exit code 17

Here the /proc/drbd on both machine

Machine 1

$ sudo cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
root@machine1, 2013-02-18 18:49:57

 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b
def:0 chkpt:0 oos:10485404


Machine 2

$ sudo cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
root@machine2, 2013-02-18 19:26:57

 1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
chkpt:0 oos:10485404


Do you have some hints?

Thank you,


Agya


thanks
> shriram
>
> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com>
> wrote:
> > Hello, Anyone have a clue? I have tried but still failed :(
> >
> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
> wrote:
> >>
> >> Dear all,
> >>
> >> I am configure my machine to run the remus disk replication. I am using
> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0
> and
> >> DomU.
> >> I have install the blktap and its work properly with configuration
> string
> >> phy or tap2 like this :
> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
> >> or
> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
> >>
> >> and remus command
> >>
> >> remus --no-net myvm mybackuphost
> >>
> >>
> >> However when I change the string as suggested on remus pages to enable
> the
> >> disk replication its still failed :
> >>
> >> name = "DomU"
> >> memory = 1024
> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
> >> bootloader = "pygrub"
> >>
> >> with error messages :
> >>
> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
> >> Using config file "/etc/xen/DomU.cfg".
> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
> failed
> >> (512  )
> >>
> >> and on the log file :
> >>
> >>
> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
> >>   File
> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
> line
> >> 3987, in create_vbd
> >>     devid = dev_control.createDevice(config)
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> line 174, in createDevice
> >>     device = TapdiskController.create(params, file)
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> line 286, in create
> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> line 233, in exc
> >>     (args, rc, out, err))
> >> TapdiskException: ('create',
> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
> >>
> >> Any hints and help would very appreciated.
> >>
> >> Regards,
> >>
> >> Agya
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >>
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>

--f46d0444e7d7313d5804d6062a44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Mon, Feb 18, 2013 at 9:08 PM, Shriram Raj=
agopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca" target=
=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
hi<br></blockquote><div><br></div><div>Thank you shriram.</div><div>=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
=A0sorry for the delayed response. IIRC the blktap2 driver required for<br>
tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.<br>
=A0I havent used it in a long time myself. I suggest trying disk<br>
replication with DRBD.<br>
<br></blockquote><div><br></div><div>I am also found some information here=
=A0<a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html">http://o=
sdir.com/ml/xen-users/2011-07/msg00653.html</a> about blktap2 problem on am=
d64 architecture. I have tried to install and configure the DRBD but its di=
dn&#39;t connect each other.</div>
<div>I used=A0<span style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier=
 New&#39;,Courier,monospace;font-size:13px">drbd-8.3.11-remus and installed=
 as follow=A0</span></div><div><div class=3D"code" style=3D"border:1px dash=
ed rgb(221,221,221);background-color:rgb(247,247,247);padding:0px 1em;margi=
n:0.4em 0px;overflow:auto">
<pre style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Couri=
er,monospace;font-size:13px"><code style=3D"font-family:&#39;Andale Mono&#3=
9;,&#39;Courier New&#39;,Courier,monospace">cd /usr/src/
wget <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz">http://remusha.wikidot.com/local--f=
iles/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz</a>
tar xzf drbd-8.3.9-remus.tar.gz
chown -R root:root drbd-8.3-remus=20
cd /usr/src/drbd-8.3-remus
chmod 777 autogen.sh
./autogen.sh
dpkg-buildpackage -b -uc
cd /usr/src/drbd-8.3-remus/drbd
make clean
make
make install
cd /usr/src/
cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD /etc/drbd.d/gl=
obal_common.conf
cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res /etc/drbd.d/SystemHA_=
protoD.res</code></pre><pre><code><font face=3D"Andale Mono, Courier New, C=
ourier, monospace" size=3D"3">sudo apt-get install drbd8-utils</font></code=
></pre>
</div></div><div>=A0from tutorial=A0<a href=3D"http://remusha.wikidot.com/c=
onfiguring-and-installing-remus">http://remusha.wikidot.com/configuring-and=
-installing-remus</a></div><div><br></div><div>My *.res configuration as fo=
llow :</div>
<div><br></div><div><div><font face=3D"courier new, monospace">resource drb=
d-vm{</font></div><div><font face=3D"courier new, monospace">=A0 device =A0=
 =A0/dev/drbd1;</font></div><div><font face=3D"courier new, monospace">=A0 =
disk =A0 =A0 =A0/dev/vgvoip/DomU;</font></div>
<div><font face=3D"courier new, monospace">=A0 meta-disk internal;</font></=
div><div><font face=3D"courier new, monospace">=A0 on machine1 {</font></di=
v><div><font face=3D"courier new, monospace">=A0 =A0 address =A0 <a href=3D=
"http://10.10.10.1:7789">10.10.10.1:7789</a>;</font></div>
<div><font face=3D"courier new, monospace">=A0 }</font></div><div><font fac=
e=3D"courier new, monospace">=A0 on machine2 {</font></div><div><font face=
=3D"courier new, monospace">=A0 =A0 address =A0 <a href=3D"http://10.10.10.=
3:7789">10.10.10.3:7789</a>;</font></div>
<div><font face=3D"courier new, monospace">=A0 }</font></div><div><font fac=
e=3D"courier new, monospace">}</font></div></div><div><br></div><div>and th=
en I invoke command to create that meta</div><div><br></div><div><pre style=
=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Courier,monospa=
ce;font-size:13px">
<code style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Cour=
ier,monospace">drbdadm create-md drbd-vm</code></pre><pre><code><font face=
=3D"arial, helvetica, sans-serif">However, when I try to make this configur=
ation up by :</font></code></pre>
<pre style=3D"font-family:&#39;Andale Mono&#39;,&#39;Courier New&#39;,Couri=
er,monospace;font-size:13px"><code style=3D"font-family:&#39;Andale Mono&#3=
9;,&#39;Courier New&#39;,Courier,monospace">drbdadm up drbd-vm</code></pre>
<pre style=3D"font-size:13px"><code><font face=3D"arial, helvetica, sans-se=
rif">Its come with error :</font></code></pre><pre><code><font face=3D"Anda=
le Mono, Courier New, Courier, monospace" size=3D"3">$ sudo drbdadm up drbd=
-vm
1: Failure: (124) Device is attached to a disk (use detach first)
Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal --=
set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dpass_on&=
#39; terminated with exit code 10</font></code><code style=3D"font-family:&=
#39;Andale Mono&#39;,&#39;Courier New&#39;,Courier,monospace;font-size:13px=
">
</code></pre></div><div><code><font face=3D"arial, helvetica, sans-serif">I=
f I run the=A0</font></code></div><div><br></div><div><pre><code><font face=
=3D"Andale Mono, Courier New, Courier, monospace" size=3D"3">$ sudo drbdadm=
 detach drbd-vm</font></code></pre>
<pre><code><font face=3D"arial, helvetica, sans-serif">Its come error</font=
><font size=3D"3" face=3D"arial, helvetica, sans-serif"> </font></code></pr=
e><pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" si=
ze=3D"3">$ sudo drbdadm detach drbd-vm
1: State change failed: (-2) Need access to UpToDate data
Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17</font></c=
ode></pre><pre><code><font face=3D"arial, helvetica, sans-serif">Here the /=
proc/drbd on both machine</font></code></pre><pre><code><font face=3D"arial=
, helvetica, sans-serif">Machine 1</font></code></pre>
<pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" size=
=3D"3">$ sudo cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine1, =
2013-02-18 18:49:57

 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0 ch=
kpt:0 oos:10485404
</font></code></pre><div><code><font face=3D"Andale Mono, Courier New, Cour=
ier, monospace" size=3D"3"><br></font></code></div><pre><code><font face=3D=
"arial, helvetica, sans-serif">Machine 2</font></code></pre><pre><code><fon=
t face=3D"Andale Mono, Courier New, Courier, monospace" size=3D"3">$ sudo c=
at /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine2, =
2013-02-18 19:26:57

 1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0 chkpt=
:0 oos:10485404
</font></code></pre><div><code><font face=3D"Andale Mono, Courier New, Cour=
ier, monospace" size=3D"3"><br></font></code></div><pre><code><font face=3D=
"Andale Mono, Courier New, Courier, monospace" size=3D"3">Do you have some =
hints?</font></code></pre>
<pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" size=
=3D"3">Thank you,</font></code></pre><pre><code><font face=3D"Andale Mono, =
Courier New, Courier, monospace" size=3D"3"><br></font></code></pre><pre><c=
ode><font face=3D"Andale Mono, Courier New, Courier, monospace" size=3D"3">=
Agya</font></code></pre>
<pre><code><font face=3D"Andale Mono, Courier New, Courier, monospace" size=
=3D"3"><br></font></code></pre></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888">shriram<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"mailto:he=
rydians@gmail.com">herydians@gmail.com</a>&gt; wrote:<br>
&gt; Hello, Anyone have a clue? I have tried but still failed :(<br>
&gt;<br>
&gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"mailto:agya=
.naila@gmail.com">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Dear all,<br>
&gt;&gt;<br>
&gt;&gt; I am configure my machine to run the remus disk replication. I am =
using<br>
&gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for =
Dom0 and<br>
&gt;&gt; DomU.<br>
&gt;&gt; I have install the blktap and its work properly with configuration=
 string<br>
&gt;&gt; phy or tap2 like this :<br>
&gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; or<br>
&gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt;<br>
&gt;&gt; and remus command<br>
&gt;&gt;<br>
&gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; However when I change the string as suggested on remus pages to en=
able the<br>
&gt;&gt; disk replication its still failed :<br>
&gt;&gt;<br>
&gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; memory =3D 1024<br>
&gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xv=
da,w&#39;]<br>
&gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt;<br>
&gt;&gt; with error messages :<br>
&gt;&gt;<br>
&gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|aio:/dev/vg=
group/DomU&#39;) failed<br>
&gt;&gt; (512 =A0)<br>
&gt;&gt;<br>
&gt;&gt; and on the log file :<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br>
&gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn=
fo.py&quot;, line<br>
&gt;&gt; 3987, in create_vbd<br>
&gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;,<br>
&gt;&gt; line 174, in createDevice<br>
&gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;,<br>
&gt;&gt; line 286, in create<br>
&gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#39;-a%s:%=
s&#39; % (dtype, image))<br>
&gt;&gt; =A0 File<br>
&gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/server/Blkta=
pController.py&quot;,<br>
&gt;&gt; line 233, in exc<br>
&gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) failed (5=
12 =A0)<br>
&gt;&gt;<br>
&gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt;<br>
&gt;&gt; Agya<br>
&gt;&gt;<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.org=
</a><br>
&gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http:=
//lists.xen.org/xen-devel</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<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>
&gt;<br>
</div></div></blockquote></div><br>

--f46d0444e7d7313d5804d6062a44--


--===============0374238427926267882==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0374238427926267882==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 21:35:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 21:35: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 1U7YMc-0003ro-FH; Mon, 18 Feb 2013 21:35:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1U7YMa-0003rS-UI; Mon, 18 Feb 2013 21:35:05 +0000
Received: from [85.158.143.35:40027] by server-1.bemta-4.messagelabs.com id
	F5/F4-08839-88E92215; Mon, 18 Feb 2013 21:35:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1361223295!13181757!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 18 Feb 2013 21:35:02 -0000
Received: from unknown (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2013 21:35:02 -0000
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com
	[209.85.223.181]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id r1ILXqXZ016075
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL);
	Mon, 18 Feb 2013 13:33:52 -0800
Received: by mail-ie0-f181.google.com with SMTP id 17so7774948iea.12
	for <multiple recipients>; Mon, 18 Feb 2013 13:33:51 -0800 (PST)
X-Received: by 10.50.214.67 with SMTP id ny3mr8068679igc.13.1361223231144;
	Mon, 18 Feb 2013 13:33:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.2.67 with HTTP; Mon, 18 Feb 2013 13:33:11 -0800 (PST)
In-Reply-To: <CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 18 Feb 2013 16:33:11 -0500
Message-ID: <CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
To: agya naila <agya.naila@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
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: 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 suggest you read up on the DRBD setup documentation from the
drbd.org website.
 The setup procedure is same. You can later flip to the remus
replication protocol by simply
 changing the protocol type (C to D).

thanks
shriram

On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com> wrote:
>
> On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>
> wrote:
>>
>> hi
>
>
> Thank you shriram.
>
>>
>>  sorry for the delayed response. IIRC the blktap2 driver required for
>> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>>  I havent used it in a long time myself. I suggest trying disk
>> replication with DRBD.
>>
>
> I am also found some information here
> http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2 problem on
> amd64 architecture. I have tried to install and configure the DRBD but its
> didn't connect each other.
> I used drbd-8.3.11-remus and installed as follow
>
> cd /usr/src/
> wget
> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
> tar xzf drbd-8.3.9-remus.tar.gz
> chown -R root:root drbd-8.3-remus
> cd /usr/src/drbd-8.3-remus
> chmod 777 autogen.sh
> ./autogen.sh
> dpkg-buildpackage -b -uc
> cd /usr/src/drbd-8.3-remus/drbd
> make clean
> make
> make install
> cd /usr/src/
> cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
> /etc/drbd.d/global_common.conf
> cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
> /etc/drbd.d/SystemHA_protoD.res
>
> sudo apt-get install drbd8-utils
>
>  from tutorial http://remusha.wikidot.com/configuring-and-installing-remus
>
> My *.res configuration as follow :
>
> resource drbd-vm{
>   device    /dev/drbd1;
>   disk      /dev/vgvoip/DomU;
>   meta-disk internal;
>   on machine1 {
>     address   10.10.10.1:7789;
>   }
>   on machine2 {
>     address   10.10.10.3:7789;
>   }
> }
>
> and then I invoke command to create that meta
>
> drbdadm create-md drbd-vm
>
> However, when I try to make this configuration up by :
>
> drbdadm up drbd-vm
>
> Its come with error :
>
> $ sudo drbdadm up drbd-vm
> 1: Failure: (124) Device is attached to a disk (use detach first)
> Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
> --set-defaults --create-device --fencing=dont-care --on-io-error=pass_on'
> terminated with exit code 10
>
> If I run the
>
> $ sudo drbdadm detach drbd-vm
>
> Its come error
>
> $ sudo drbdadm detach drbd-vm
> 1: State change failed: (-2) Need access to UpToDate data
> Command 'drbdsetup 1 detach' terminated with exit code 17
>
> Here the /proc/drbd on both machine
>
> Machine 1
>
> $ sudo cat /proc/drbd
> version: 8.3.11 (api:88/proto:86-96)
> GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine1,
> 2013-02-18 18:49:57
>
>  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
>     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> chkpt:0 oos:10485404
>
>
> Machine 2
>
> $ sudo cat /proc/drbd
> version: 8.3.11 (api:88/proto:86-96)
> GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine2,
> 2013-02-18 19:26:57
>
>  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
>     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> chkpt:0 oos:10485404
>
>
> Do you have some hints?
>
> Thank you,
>
>
> Agya
>
>
>> thanks
>> shriram
>>
>> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com>
>> wrote:
>> > Hello, Anyone have a clue? I have tried but still failed :(
>> >
>> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I am configure my machine to run the remus disk replication. I am using
>> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0
>> >> and
>> >> DomU.
>> >> I have install the blktap and its work properly with configuration
>> >> string
>> >> phy or tap2 like this :
>> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>> >> or
>> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>> >>
>> >> and remus command
>> >>
>> >> remus --no-net myvm mybackuphost
>> >>
>> >>
>> >> However when I change the string as suggested on remus pages to enable
>> >> the
>> >> disk replication its still failed :
>> >>
>> >> name = "DomU"
>> >> memory = 1024
>> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
>> >> bootloader = "pygrub"
>> >>
>> >> with error messages :
>> >>
>> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>> >> Using config file "/etc/xen/DomU.cfg".
>> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
>> >> failed
>> >> (512  )
>> >>
>> >> and on the log file :
>> >>
>> >>
>> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>> >>   File
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
>> >> line
>> >> 3987, in create_vbd
>> >>     devid = dev_control.createDevice(config)
>> >>   File
>> >>
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> line 174, in createDevice
>> >>     device = TapdiskController.create(params, file)
>> >>   File
>> >>
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> line 286, in create
>> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
>> >>   File
>> >>
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> line 233, in exc
>> >>     (args, rc, out, err))
>> >> TapdiskException: ('create',
>> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>> >>
>> >> Any hints and help would very appreciated.
>> >>
>> >> Regards,
>> >>
>> >> Agya
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@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 Feb 18 21:35:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 21:35: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 1U7YMc-0003ro-FH; Mon, 18 Feb 2013 21:35:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1U7YMa-0003rS-UI; Mon, 18 Feb 2013 21:35:05 +0000
Received: from [85.158.143.35:40027] by server-1.bemta-4.messagelabs.com id
	F5/F4-08839-88E92215; Mon, 18 Feb 2013 21:35:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1361223295!13181757!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 18 Feb 2013 21:35:02 -0000
Received: from unknown (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Feb 2013 21:35:02 -0000
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com
	[209.85.223.181]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id r1ILXqXZ016075
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL);
	Mon, 18 Feb 2013 13:33:52 -0800
Received: by mail-ie0-f181.google.com with SMTP id 17so7774948iea.12
	for <multiple recipients>; Mon, 18 Feb 2013 13:33:51 -0800 (PST)
X-Received: by 10.50.214.67 with SMTP id ny3mr8068679igc.13.1361223231144;
	Mon, 18 Feb 2013 13:33:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.2.67 with HTTP; Mon, 18 Feb 2013 13:33:11 -0800 (PST)
In-Reply-To: <CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 18 Feb 2013 16:33:11 -0500
Message-ID: <CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
To: agya naila <agya.naila@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
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: 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 suggest you read up on the DRBD setup documentation from the
drbd.org website.
 The setup procedure is same. You can later flip to the remus
replication protocol by simply
 changing the protocol type (C to D).

thanks
shriram

On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com> wrote:
>
> On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>
> wrote:
>>
>> hi
>
>
> Thank you shriram.
>
>>
>>  sorry for the delayed response. IIRC the blktap2 driver required for
>> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>>  I havent used it in a long time myself. I suggest trying disk
>> replication with DRBD.
>>
>
> I am also found some information here
> http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2 problem on
> amd64 architecture. I have tried to install and configure the DRBD but its
> didn't connect each other.
> I used drbd-8.3.11-remus and installed as follow
>
> cd /usr/src/
> wget
> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
> tar xzf drbd-8.3.9-remus.tar.gz
> chown -R root:root drbd-8.3-remus
> cd /usr/src/drbd-8.3-remus
> chmod 777 autogen.sh
> ./autogen.sh
> dpkg-buildpackage -b -uc
> cd /usr/src/drbd-8.3-remus/drbd
> make clean
> make
> make install
> cd /usr/src/
> cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
> /etc/drbd.d/global_common.conf
> cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
> /etc/drbd.d/SystemHA_protoD.res
>
> sudo apt-get install drbd8-utils
>
>  from tutorial http://remusha.wikidot.com/configuring-and-installing-remus
>
> My *.res configuration as follow :
>
> resource drbd-vm{
>   device    /dev/drbd1;
>   disk      /dev/vgvoip/DomU;
>   meta-disk internal;
>   on machine1 {
>     address   10.10.10.1:7789;
>   }
>   on machine2 {
>     address   10.10.10.3:7789;
>   }
> }
>
> and then I invoke command to create that meta
>
> drbdadm create-md drbd-vm
>
> However, when I try to make this configuration up by :
>
> drbdadm up drbd-vm
>
> Its come with error :
>
> $ sudo drbdadm up drbd-vm
> 1: Failure: (124) Device is attached to a disk (use detach first)
> Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
> --set-defaults --create-device --fencing=dont-care --on-io-error=pass_on'
> terminated with exit code 10
>
> If I run the
>
> $ sudo drbdadm detach drbd-vm
>
> Its come error
>
> $ sudo drbdadm detach drbd-vm
> 1: State change failed: (-2) Need access to UpToDate data
> Command 'drbdsetup 1 detach' terminated with exit code 17
>
> Here the /proc/drbd on both machine
>
> Machine 1
>
> $ sudo cat /proc/drbd
> version: 8.3.11 (api:88/proto:86-96)
> GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine1,
> 2013-02-18 18:49:57
>
>  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
>     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> chkpt:0 oos:10485404
>
>
> Machine 2
>
> $ sudo cat /proc/drbd
> version: 8.3.11 (api:88/proto:86-96)
> GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine2,
> 2013-02-18 19:26:57
>
>  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
>     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> chkpt:0 oos:10485404
>
>
> Do you have some hints?
>
> Thank you,
>
>
> Agya
>
>
>> thanks
>> shriram
>>
>> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com>
>> wrote:
>> > Hello, Anyone have a clue? I have tried but still failed :(
>> >
>> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I am configure my machine to run the remus disk replication. I am using
>> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for Dom0
>> >> and
>> >> DomU.
>> >> I have install the blktap and its work properly with configuration
>> >> string
>> >> phy or tap2 like this :
>> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>> >> or
>> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>> >>
>> >> and remus command
>> >>
>> >> remus --no-net myvm mybackuphost
>> >>
>> >>
>> >> However when I change the string as suggested on remus pages to enable
>> >> the
>> >> disk replication its still failed :
>> >>
>> >> name = "DomU"
>> >> memory = 1024
>> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
>> >> bootloader = "pygrub"
>> >>
>> >> with error messages :
>> >>
>> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>> >> Using config file "/etc/xen/DomU.cfg".
>> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
>> >> failed
>> >> (512  )
>> >>
>> >> and on the log file :
>> >>
>> >>
>> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>> >>   File
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
>> >> line
>> >> 3987, in create_vbd
>> >>     devid = dev_control.createDevice(config)
>> >>   File
>> >>
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> line 174, in createDevice
>> >>     device = TapdiskController.create(params, file)
>> >>   File
>> >>
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> line 286, in create
>> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype, image))
>> >>   File
>> >>
>> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> line 233, in exc
>> >>     (args, rc, out, err))
>> >> TapdiskException: ('create',
>> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>> >>
>> >> Any hints and help would very appreciated.
>> >>
>> >> Regards,
>> >>
>> >> Agya
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@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 Feb 18 22:11:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22: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 1U7YvP-0006DF-VF; Mon, 18 Feb 2013 22:11:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7YvN-0006Cz-0m; Mon, 18 Feb 2013 22:11:02 +0000
Received: from [85.158.143.99:14584] by server-2.bemta-4.messagelabs.com id
	26/C6-12656-4F6A2215; Mon, 18 Feb 2013 22:11:00 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361225457!18290330!1
X-Originating-IP: [209.85.212.170]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20714 invoked from network); 18 Feb 2013 22:10:57 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 22:10:57 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so4336841wib.5
	for <multiple recipients>; Mon, 18 Feb 2013 14:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Okoqn2pB87OLKdFFDuNQYBrOJhtIK5Aga9qnWih1HO4=;
	b=MtYpoagMnSNRKVFEgU7EI9zc6NDNacvu2mE4+wwUAE+ujttkgIXIVF4p4SsTBDbT80
	PcwMz8anhJaPnEWpxnETuJdqTpeE91iCJ+5yMEAwgl96WAiZzN0UQCg8+xEAzEPt80cR
	az3vyXdeOz/FhTXfLoKmbwWEHHIzVQareF7Jee2ZuK7oQQ6fLPgaHMpxbc5ZlR8iMoZ9
	yEyLRP8Ahdibfv6265Ww66GCOdpEzuCZjsN730h/VePWawmFu0RH+yorWrwHk+jywrKL
	M488Uwl0PKXu3kkbCn5XFGQl8HWTjB9bRs/I+pIG9LhV4uy6Oxjggrn4l6uH6xYbJ9Sl
	FwZA==
MIME-Version: 1.0
X-Received: by 10.194.94.40 with SMTP id cz8mr5703649wjb.15.1361224856940;
	Mon, 18 Feb 2013 14:00:56 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 14:00:56 -0800 (PST)
In-Reply-To: <CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
	<CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
Date: Mon, 18 Feb 2013 23:00:56 +0100
Message-ID: <CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4790152514405467051=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4790152514405467051==
Content-Type: multipart/alternative; boundary=047d7bb04c9a0eb1b904d606dc19

--047d7bb04c9a0eb1b904d606dc19
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> Hi,
>  I suggest you read up on the DRBD setup documentation from the
> drbd.org website.
>  The setup procedure is same. You can later flip to the remus
> replication protocol by simply
>  changing the protocol type (C to D).
>
> I am comparing my configuration with drbd website, however I got this
error :

$ sudo drbdadm up drbd-vm
*'D' is no valid protocol.*
*Command 'drbdsetup 1 net ipv4:10.10.10.1:7789 ipv4:10.10.10.3:7789 D
--set-defaults --create-device --rr-conflict=disconnect
--after-sb-2pri=disconnect --after-sb-1pri=discard-secondary
--after-sb-0pri=discard-younger-primary --allow-two-primaries --ko-count=4
--max-epoch-size=4096 --unplug-watermark=4096 --max-buffers=8192
--ping-timeout=20 --ping-int=3 --timeout=30' terminated with exit code 20*
*drbdadm connect drbd-vm: exited with code 20*
*
*
$ sudo drbd-overview
  1:drbd-vm  StandAlone Secondary/Unknown UpToDate/DUnknown r----s

Thank you,

Agya



> thanks
> shriram
>
> On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com> wrote:
> >
> > On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca
> >
> > wrote:
> >>
> >> hi
> >
> >
> > Thank you shriram.
> >
> >>
> >>  sorry for the delayed response. IIRC the blktap2 driver required for
> >> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
> >>  I havent used it in a long time myself. I suggest trying disk
> >> replication with DRBD.
> >>
> >
> > I am also found some information here
> > http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2
> problem on
> > amd64 architecture. I have tried to install and configure the DRBD but
> its
> > didn't connect each other.
> > I used drbd-8.3.11-remus and installed as follow
> >
> > cd /usr/src/
> > wget
> >
> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
> > tar xzf drbd-8.3.9-remus.tar.gz
> > chown -R root:root drbd-8.3-remus
> > cd /usr/src/drbd-8.3-remus
> > chmod 777 autogen.sh
> > ./autogen.sh
> > dpkg-buildpackage -b -uc
> > cd /usr/src/drbd-8.3-remus/drbd
> > make clean
> > make
> > make install
> > cd /usr/src/
> > cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
> > /etc/drbd.d/global_common.conf
> > cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
> > /etc/drbd.d/SystemHA_protoD.res
> >
> > sudo apt-get install drbd8-utils
> >
> >  from tutorial
> http://remusha.wikidot.com/configuring-and-installing-remus
> >
> > My *.res configuration as follow :
> >
> > resource drbd-vm{
> >   device    /dev/drbd1;
> >   disk      /dev/vgvoip/DomU;
> >   meta-disk internal;
> >   on machine1 {
> >     address   10.10.10.1:7789;
> >   }
> >   on machine2 {
> >     address   10.10.10.3:7789;
> >   }
> > }
> >
> > and then I invoke command to create that meta
> >
> > drbdadm create-md drbd-vm
> >
> > However, when I try to make this configuration up by :
> >
> > drbdadm up drbd-vm
> >
> > Its come with error :
> >
> > $ sudo drbdadm up drbd-vm
> > 1: Failure: (124) Device is attached to a disk (use detach first)
> > Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
> > --set-defaults --create-device --fencing=dont-care --on-io-error=pass_on'
> > terminated with exit code 10
> >
> > If I run the
> >
> > $ sudo drbdadm detach drbd-vm
> >
> > Its come error
> >
> > $ sudo drbdadm detach drbd-vm
> > 1: State change failed: (-2) Need access to UpToDate data
> > Command 'drbdsetup 1 detach' terminated with exit code 17
> >
> > Here the /proc/drbd on both machine
> >
> > Machine 1
> >
> > $ sudo cat /proc/drbd
> > version: 8.3.11 (api:88/proto:86-96)
> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine1
> ,
> > 2013-02-18 18:49:57
> >
> >  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
> >     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> > chkpt:0 oos:10485404
> >
> >
> > Machine 2
> >
> > $ sudo cat /proc/drbd
> > version: 8.3.11 (api:88/proto:86-96)
> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine2
> ,
> > 2013-02-18 19:26:57
> >
> >  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
> >     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> > chkpt:0 oos:10485404
> >
> >
> > Do you have some hints?
> >
> > Thank you,
> >
> >
> > Agya
> >
> >
> >> thanks
> >> shriram
> >>
> >> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com
> >
> >> wrote:
> >> > Hello, Anyone have a clue? I have tried but still failed :(
> >> >
> >> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
> >> > wrote:
> >> >>
> >> >> Dear all,
> >> >>
> >> >> I am configure my machine to run the remus disk replication. I am
> using
> >> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for
> Dom0
> >> >> and
> >> >> DomU.
> >> >> I have install the blktap and its work properly with configuration
> >> >> string
> >> >> phy or tap2 like this :
> >> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
> >> >> or
> >> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
> >> >>
> >> >> and remus command
> >> >>
> >> >> remus --no-net myvm mybackuphost
> >> >>
> >> >>
> >> >> However when I change the string as suggested on remus pages to
> enable
> >> >> the
> >> >> disk replication its still failed :
> >> >>
> >> >> name = "DomU"
> >> >> memory = 1024
> >> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
> >> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
> >> >> bootloader = "pygrub"
> >> >>
> >> >> with error messages :
> >> >>
> >> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
> >> >> Using config file "/etc/xen/DomU.cfg".
> >> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
> >> >> failed
> >> >> (512  )
> >> >>
> >> >> and on the log file :
> >> >>
> >> >>
> >> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
> >> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
> >> >>   File
> >> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
> >> >> line
> >> >> 3987, in create_vbd
> >> >>     devid = dev_control.createDevice(config)
> >> >>   File
> >> >>
> >> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> >> line 174, in createDevice
> >> >>     device = TapdiskController.create(params, file)
> >> >>   File
> >> >>
> >> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> >> line 286, in create
> >> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype,
> image))
> >> >>   File
> >> >>
> >> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> >> line 233, in exc
> >> >>     (args, rc, out, err))
> >> >> TapdiskException: ('create',
> >> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
> >> >>
> >> >> Any hints and help would very appreciated.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Agya
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Xen-devel mailing list
> >> >> Xen-devel@lists.xen.org
> >> >> http://lists.xen.org/xen-devel
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Xen-devel mailing list
> >> > Xen-devel@lists.xen.org
> >> > http://lists.xen.org/xen-devel
> >> >
> >
> >
>

--047d7bb04c9a0eb1b904d606dc19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <span dir=3D"ltr=
">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.u=
bc.ca</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
Hi,<br>
=A0I suggest you read up on the DRBD setup documentation from the<br>
<a href=3D"http://drbd.org" target=3D"_blank">drbd.org</a> website.<br>
=A0The setup procedure is same. You can later flip to the remus<br>
replication protocol by simply<br>
=A0changing the protocol type (C to D).<br>
<br></blockquote>I am comparing my configuration with drbd website, however=
 I got this error :<div><br></div><div><div><font face=3D"courier new, mono=
space">$ sudo drbdadm up drbd-vm</font></div><div><font face=3D"courier new=
, monospace"><b>&#39;D&#39; is no valid protocol.</b></font></div>
<div><font face=3D"courier new, monospace"><b>Command &#39;drbdsetup 1 net =
ipv4:<a href=3D"http://10.10.10.1:7789">10.10.10.1:7789</a> ipv4:<a href=3D=
"http://10.10.10.3:7789">10.10.10.3:7789</a> D --set-defaults --create-devi=
ce --rr-conflict=3Ddisconnect --after-sb-2pri=3Ddisconnect --after-sb-1pri=
=3Ddiscard-secondary --after-sb-0pri=3Ddiscard-younger-primary --allow-two-=
primaries --ko-count=3D4 --max-epoch-size=3D4096 --unplug-watermark=3D4096 =
--max-buffers=3D8192 --ping-timeout=3D20 --ping-int=3D3 --timeout=3D30&#39;=
 terminated with exit code 20</b></font></div>
<div><font face=3D"courier new, monospace"><b>drbdadm connect drbd-vm: exit=
ed with code 20</b></font></div><div><font face=3D"courier new, monospace">=
<b><br></b></font></div><div><font face=3D"courier new, monospace">$ sudo d=
rbd-overview</font></div>
</div><div><span style=3D"font-family:&#39;courier new&#39;,monospace">=A0 =
1:drbd-vm =A0StandAlone Secondary/Unknown UpToDate/DUnknown r----s</span></=
div><div><br></div><div>Thank you,</div><div><br></div><div>Agya</div><div>=
<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888">shriram<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Mon, Feb 18, 2013 at 4:11 PM, agya naila &lt;<a href=3D"mailto:agya.nail=
a@gmail.com">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan &lt;<a href=3D"ma=
ilto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; hi<br>
&gt;<br>
&gt;<br>
&gt; Thank you shriram.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0sorry for the delayed response. IIRC the blktap2 driver require=
d for<br>
&gt;&gt; tapdisk replication doesnt exist in the mainstream dom0 kernels, I=
IRC.<br>
&gt;&gt; =A0I havent used it in a long time myself. I suggest trying disk<b=
r>
&gt;&gt; replication with DRBD.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I am also found some information here<br>
&gt; <a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html" target=
=3D"_blank">http://osdir.com/ml/xen-users/2011-07/msg00653.html</a> about b=
lktap2 problem on<br>
&gt; amd64 architecture. I have tried to install and configure the DRBD but=
 its<br>
&gt; didn&#39;t connect each other.<br>
&gt; I used drbd-8.3.11-remus and installed as follow<br>
&gt;<br>
&gt; cd /usr/src/<br>
&gt; wget<br>
&gt; <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz" target=3D"_blank">http://remusha.wi=
kidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.t=
ar.gz</a><br>

&gt; tar xzf drbd-8.3.9-remus.tar.gz<br>
&gt; chown -R root:root drbd-8.3-remus<br>
&gt; cd /usr/src/drbd-8.3-remus<br>
&gt; chmod 777 autogen.sh<br>
&gt; ./autogen.sh<br>
&gt; dpkg-buildpackage -b -uc<br>
&gt; cd /usr/src/drbd-8.3-remus/drbd<br>
&gt; make clean<br>
&gt; make<br>
&gt; make install<br>
&gt; cd /usr/src/<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD<br>
&gt; /etc/drbd.d/global_common.conf<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res<br>
&gt; /etc/drbd.d/SystemHA_protoD.res<br>
&gt;<br>
&gt; sudo apt-get install drbd8-utils<br>
&gt;<br>
&gt; =A0from tutorial <a href=3D"http://remusha.wikidot.com/configuring-and=
-installing-remus" target=3D"_blank">http://remusha.wikidot.com/configuring=
-and-installing-remus</a><br>
&gt;<br>
&gt; My *.res configuration as follow :<br>
&gt;<br>
&gt; resource drbd-vm{<br>
&gt; =A0 device =A0 =A0/dev/drbd1;<br>
&gt; =A0 disk =A0 =A0 =A0/dev/vgvoip/DomU;<br>
&gt; =A0 meta-disk internal;<br>
&gt; =A0 on machine1 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.1:7789" target=3D"_blan=
k">10.10.10.1:7789</a>;<br>
&gt; =A0 }<br>
&gt; =A0 on machine2 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.3:7789" target=3D"_blan=
k">10.10.10.3:7789</a>;<br>
&gt; =A0 }<br>
&gt; }<br>
&gt;<br>
&gt; and then I invoke command to create that meta<br>
&gt;<br>
&gt; drbdadm create-md drbd-vm<br>
&gt;<br>
&gt; However, when I try to make this configuration up by :<br>
&gt;<br>
&gt; drbdadm up drbd-vm<br>
&gt;<br>
&gt; Its come with error :<br>
&gt;<br>
&gt; $ sudo drbdadm up drbd-vm<br>
&gt; 1: Failure: (124) Device is attached to a disk (use detach first)<br>
&gt; Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU intern=
al<br>
&gt; --set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dp=
ass_on&#39;<br>
&gt; terminated with exit code 10<br>
&gt;<br>
&gt; If I run the<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt;<br>
&gt; Its come error<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt; 1: State change failed: (-2) Need access to UpToDate data<br>
&gt; Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17<br>
&gt;<br>
&gt; Here the /proc/drbd on both machine<br>
&gt;<br>
&gt; Machine 1<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne1,<br>
&gt; 2013-02-18 18:49:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown =A0 r----s=
<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b=
 def:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Machine 2<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne2,<br>
&gt; 2013-02-18 19:26:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown =A0 =
r----s<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b de=
f:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Do you have some hints?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt;<br>
&gt; Agya<br>
&gt;<br>
&gt;<br>
&gt;&gt; thanks<br>
&gt;&gt; shriram<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"=
mailto:herydians@gmail.com">herydians@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hello, Anyone have a clue? I have tried but still failed :(<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"ma=
ilto:agya.naila@gmail.com">agya.naila@gmail.com</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Dear all,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I am configure my machine to run the remus disk replicati=
on. I am using<br>
&gt;&gt; &gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit =
both for Dom0<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; DomU.<br>
&gt;&gt; &gt;&gt; I have install the blktap and its work properly with conf=
iguration<br>
&gt;&gt; &gt;&gt; string<br>
&gt;&gt; &gt;&gt; phy or tap2 like this :<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; or<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&=
#39;]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and remus command<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; However when I change the string as suggested on remus pa=
ges to enable<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; disk replication its still failed :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; &gt;&gt; memory =3D 1024<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggrou=
p/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; &gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with error messages :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; &gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; &gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|ai=
o:/dev/vggroup/DomU&#39;)<br>
&gt;&gt; &gt;&gt; failed<br>
&gt;&gt; &gt;&gt; (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and on the log file :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br=
>
&gt;&gt; &gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<=
br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/Xen=
dDomainInfo.py&quot;,<br>
&gt;&gt; &gt;&gt; line<br>
&gt;&gt; &gt;&gt; 3987, in create_vbd<br>
&gt;&gt; &gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 174, in createDevice<br>
&gt;&gt; &gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)=
<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 286, in create<br>
&gt;&gt; &gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#=
39;-a%s:%s&#39; % (dtype, image))<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 233, in exc<br>
&gt;&gt; &gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; &gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) =
failed (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Agya<br>
&gt;&gt; &gt;&gt;<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@list=
s.xen.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_bla=
nk">http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Xen-devel mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xe=
n.org</a><br>
&gt;&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">=
http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>

--047d7bb04c9a0eb1b904d606dc19--


--===============4790152514405467051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4790152514405467051==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 22:11:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22: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 1U7YvP-0006DF-VF; Mon, 18 Feb 2013 22:11:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7YvN-0006Cz-0m; Mon, 18 Feb 2013 22:11:02 +0000
Received: from [85.158.143.99:14584] by server-2.bemta-4.messagelabs.com id
	26/C6-12656-4F6A2215; Mon, 18 Feb 2013 22:11:00 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361225457!18290330!1
X-Originating-IP: [209.85.212.170]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20714 invoked from network); 18 Feb 2013 22:10:57 -0000
Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com)
	(209.85.212.170)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 22:10:57 -0000
Received: by mail-wi0-f170.google.com with SMTP id hm11so4336841wib.5
	for <multiple recipients>; Mon, 18 Feb 2013 14:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Okoqn2pB87OLKdFFDuNQYBrOJhtIK5Aga9qnWih1HO4=;
	b=MtYpoagMnSNRKVFEgU7EI9zc6NDNacvu2mE4+wwUAE+ujttkgIXIVF4p4SsTBDbT80
	PcwMz8anhJaPnEWpxnETuJdqTpeE91iCJ+5yMEAwgl96WAiZzN0UQCg8+xEAzEPt80cR
	az3vyXdeOz/FhTXfLoKmbwWEHHIzVQareF7Jee2ZuK7oQQ6fLPgaHMpxbc5ZlR8iMoZ9
	yEyLRP8Ahdibfv6265Ww66GCOdpEzuCZjsN730h/VePWawmFu0RH+yorWrwHk+jywrKL
	M488Uwl0PKXu3kkbCn5XFGQl8HWTjB9bRs/I+pIG9LhV4uy6Oxjggrn4l6uH6xYbJ9Sl
	FwZA==
MIME-Version: 1.0
X-Received: by 10.194.94.40 with SMTP id cz8mr5703649wjb.15.1361224856940;
	Mon, 18 Feb 2013 14:00:56 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 14:00:56 -0800 (PST)
In-Reply-To: <CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
	<CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
Date: Mon, 18 Feb 2013 23:00:56 +0100
Message-ID: <CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============4790152514405467051=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4790152514405467051==
Content-Type: multipart/alternative; boundary=047d7bb04c9a0eb1b904d606dc19

--047d7bb04c9a0eb1b904d606dc19
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> Hi,
>  I suggest you read up on the DRBD setup documentation from the
> drbd.org website.
>  The setup procedure is same. You can later flip to the remus
> replication protocol by simply
>  changing the protocol type (C to D).
>
> I am comparing my configuration with drbd website, however I got this
error :

$ sudo drbdadm up drbd-vm
*'D' is no valid protocol.*
*Command 'drbdsetup 1 net ipv4:10.10.10.1:7789 ipv4:10.10.10.3:7789 D
--set-defaults --create-device --rr-conflict=disconnect
--after-sb-2pri=disconnect --after-sb-1pri=discard-secondary
--after-sb-0pri=discard-younger-primary --allow-two-primaries --ko-count=4
--max-epoch-size=4096 --unplug-watermark=4096 --max-buffers=8192
--ping-timeout=20 --ping-int=3 --timeout=30' terminated with exit code 20*
*drbdadm connect drbd-vm: exited with code 20*
*
*
$ sudo drbd-overview
  1:drbd-vm  StandAlone Secondary/Unknown UpToDate/DUnknown r----s

Thank you,

Agya



> thanks
> shriram
>
> On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com> wrote:
> >
> > On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca
> >
> > wrote:
> >>
> >> hi
> >
> >
> > Thank you shriram.
> >
> >>
> >>  sorry for the delayed response. IIRC the blktap2 driver required for
> >> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
> >>  I havent used it in a long time myself. I suggest trying disk
> >> replication with DRBD.
> >>
> >
> > I am also found some information here
> > http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2
> problem on
> > amd64 architecture. I have tried to install and configure the DRBD but
> its
> > didn't connect each other.
> > I used drbd-8.3.11-remus and installed as follow
> >
> > cd /usr/src/
> > wget
> >
> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
> > tar xzf drbd-8.3.9-remus.tar.gz
> > chown -R root:root drbd-8.3-remus
> > cd /usr/src/drbd-8.3-remus
> > chmod 777 autogen.sh
> > ./autogen.sh
> > dpkg-buildpackage -b -uc
> > cd /usr/src/drbd-8.3-remus/drbd
> > make clean
> > make
> > make install
> > cd /usr/src/
> > cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
> > /etc/drbd.d/global_common.conf
> > cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
> > /etc/drbd.d/SystemHA_protoD.res
> >
> > sudo apt-get install drbd8-utils
> >
> >  from tutorial
> http://remusha.wikidot.com/configuring-and-installing-remus
> >
> > My *.res configuration as follow :
> >
> > resource drbd-vm{
> >   device    /dev/drbd1;
> >   disk      /dev/vgvoip/DomU;
> >   meta-disk internal;
> >   on machine1 {
> >     address   10.10.10.1:7789;
> >   }
> >   on machine2 {
> >     address   10.10.10.3:7789;
> >   }
> > }
> >
> > and then I invoke command to create that meta
> >
> > drbdadm create-md drbd-vm
> >
> > However, when I try to make this configuration up by :
> >
> > drbdadm up drbd-vm
> >
> > Its come with error :
> >
> > $ sudo drbdadm up drbd-vm
> > 1: Failure: (124) Device is attached to a disk (use detach first)
> > Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
> > --set-defaults --create-device --fencing=dont-care --on-io-error=pass_on'
> > terminated with exit code 10
> >
> > If I run the
> >
> > $ sudo drbdadm detach drbd-vm
> >
> > Its come error
> >
> > $ sudo drbdadm detach drbd-vm
> > 1: State change failed: (-2) Need access to UpToDate data
> > Command 'drbdsetup 1 detach' terminated with exit code 17
> >
> > Here the /proc/drbd on both machine
> >
> > Machine 1
> >
> > $ sudo cat /proc/drbd
> > version: 8.3.11 (api:88/proto:86-96)
> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine1
> ,
> > 2013-02-18 18:49:57
> >
> >  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
> >     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> > chkpt:0 oos:10485404
> >
> >
> > Machine 2
> >
> > $ sudo cat /proc/drbd
> > version: 8.3.11 (api:88/proto:86-96)
> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machine2
> ,
> > 2013-02-18 19:26:57
> >
> >  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
> >     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
> > chkpt:0 oos:10485404
> >
> >
> > Do you have some hints?
> >
> > Thank you,
> >
> >
> > Agya
> >
> >
> >> thanks
> >> shriram
> >>
> >> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <herydians@gmail.com
> >
> >> wrote:
> >> > Hello, Anyone have a clue? I have tried but still failed :(
> >> >
> >> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
> >> > wrote:
> >> >>
> >> >> Dear all,
> >> >>
> >> >> I am configure my machine to run the remus disk replication. I am
> using
> >> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for
> Dom0
> >> >> and
> >> >> DomU.
> >> >> I have install the blktap and its work properly with configuration
> >> >> string
> >> >> phy or tap2 like this :
> >> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
> >> >> or
> >> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
> >> >>
> >> >> and remus command
> >> >>
> >> >> remus --no-net myvm mybackuphost
> >> >>
> >> >>
> >> >> However when I change the string as suggested on remus pages to
> enable
> >> >> the
> >> >> disk replication its still failed :
> >> >>
> >> >> name = "DomU"
> >> >> memory = 1024
> >> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
> >> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
> >> >> bootloader = "pygrub"
> >> >>
> >> >> with error messages :
> >> >>
> >> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
> >> >> Using config file "/etc/xen/DomU.cfg".
> >> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
> >> >> failed
> >> >> (512  )
> >> >>
> >> >> and on the log file :
> >> >>
> >> >>
> >> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
> >> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
> >> >>   File
> >> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
> >> >> line
> >> >> 3987, in create_vbd
> >> >>     devid = dev_control.createDevice(config)
> >> >>   File
> >> >>
> >> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> >> line 174, in createDevice
> >> >>     device = TapdiskController.create(params, file)
> >> >>   File
> >> >>
> >> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> >> line 286, in create
> >> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype,
> image))
> >> >>   File
> >> >>
> >> >>
> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
> >> >> line 233, in exc
> >> >>     (args, rc, out, err))
> >> >> TapdiskException: ('create',
> >> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
> >> >>
> >> >> Any hints and help would very appreciated.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Agya
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Xen-devel mailing list
> >> >> Xen-devel@lists.xen.org
> >> >> http://lists.xen.org/xen-devel
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Xen-devel mailing list
> >> > Xen-devel@lists.xen.org
> >> > http://lists.xen.org/xen-devel
> >> >
> >
> >
>

--047d7bb04c9a0eb1b904d606dc19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <span dir=3D"ltr=
">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.u=
bc.ca</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
Hi,<br>
=A0I suggest you read up on the DRBD setup documentation from the<br>
<a href=3D"http://drbd.org" target=3D"_blank">drbd.org</a> website.<br>
=A0The setup procedure is same. You can later flip to the remus<br>
replication protocol by simply<br>
=A0changing the protocol type (C to D).<br>
<br></blockquote>I am comparing my configuration with drbd website, however=
 I got this error :<div><br></div><div><div><font face=3D"courier new, mono=
space">$ sudo drbdadm up drbd-vm</font></div><div><font face=3D"courier new=
, monospace"><b>&#39;D&#39; is no valid protocol.</b></font></div>
<div><font face=3D"courier new, monospace"><b>Command &#39;drbdsetup 1 net =
ipv4:<a href=3D"http://10.10.10.1:7789">10.10.10.1:7789</a> ipv4:<a href=3D=
"http://10.10.10.3:7789">10.10.10.3:7789</a> D --set-defaults --create-devi=
ce --rr-conflict=3Ddisconnect --after-sb-2pri=3Ddisconnect --after-sb-1pri=
=3Ddiscard-secondary --after-sb-0pri=3Ddiscard-younger-primary --allow-two-=
primaries --ko-count=3D4 --max-epoch-size=3D4096 --unplug-watermark=3D4096 =
--max-buffers=3D8192 --ping-timeout=3D20 --ping-int=3D3 --timeout=3D30&#39;=
 terminated with exit code 20</b></font></div>
<div><font face=3D"courier new, monospace"><b>drbdadm connect drbd-vm: exit=
ed with code 20</b></font></div><div><font face=3D"courier new, monospace">=
<b><br></b></font></div><div><font face=3D"courier new, monospace">$ sudo d=
rbd-overview</font></div>
</div><div><span style=3D"font-family:&#39;courier new&#39;,monospace">=A0 =
1:drbd-vm =A0StandAlone Secondary/Unknown UpToDate/DUnknown r----s</span></=
div><div><br></div><div>Thank you,</div><div><br></div><div>Agya</div><div>=
<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888">shriram<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Mon, Feb 18, 2013 at 4:11 PM, agya naila &lt;<a href=3D"mailto:agya.nail=
a@gmail.com">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan &lt;<a href=3D"ma=
ilto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; hi<br>
&gt;<br>
&gt;<br>
&gt; Thank you shriram.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0sorry for the delayed response. IIRC the blktap2 driver require=
d for<br>
&gt;&gt; tapdisk replication doesnt exist in the mainstream dom0 kernels, I=
IRC.<br>
&gt;&gt; =A0I havent used it in a long time myself. I suggest trying disk<b=
r>
&gt;&gt; replication with DRBD.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I am also found some information here<br>
&gt; <a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html" target=
=3D"_blank">http://osdir.com/ml/xen-users/2011-07/msg00653.html</a> about b=
lktap2 problem on<br>
&gt; amd64 architecture. I have tried to install and configure the DRBD but=
 its<br>
&gt; didn&#39;t connect each other.<br>
&gt; I used drbd-8.3.11-remus and installed as follow<br>
&gt;<br>
&gt; cd /usr/src/<br>
&gt; wget<br>
&gt; <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz" target=3D"_blank">http://remusha.wi=
kidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.t=
ar.gz</a><br>

&gt; tar xzf drbd-8.3.9-remus.tar.gz<br>
&gt; chown -R root:root drbd-8.3-remus<br>
&gt; cd /usr/src/drbd-8.3-remus<br>
&gt; chmod 777 autogen.sh<br>
&gt; ./autogen.sh<br>
&gt; dpkg-buildpackage -b -uc<br>
&gt; cd /usr/src/drbd-8.3-remus/drbd<br>
&gt; make clean<br>
&gt; make<br>
&gt; make install<br>
&gt; cd /usr/src/<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD<br>
&gt; /etc/drbd.d/global_common.conf<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res<br>
&gt; /etc/drbd.d/SystemHA_protoD.res<br>
&gt;<br>
&gt; sudo apt-get install drbd8-utils<br>
&gt;<br>
&gt; =A0from tutorial <a href=3D"http://remusha.wikidot.com/configuring-and=
-installing-remus" target=3D"_blank">http://remusha.wikidot.com/configuring=
-and-installing-remus</a><br>
&gt;<br>
&gt; My *.res configuration as follow :<br>
&gt;<br>
&gt; resource drbd-vm{<br>
&gt; =A0 device =A0 =A0/dev/drbd1;<br>
&gt; =A0 disk =A0 =A0 =A0/dev/vgvoip/DomU;<br>
&gt; =A0 meta-disk internal;<br>
&gt; =A0 on machine1 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.1:7789" target=3D"_blan=
k">10.10.10.1:7789</a>;<br>
&gt; =A0 }<br>
&gt; =A0 on machine2 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.3:7789" target=3D"_blan=
k">10.10.10.3:7789</a>;<br>
&gt; =A0 }<br>
&gt; }<br>
&gt;<br>
&gt; and then I invoke command to create that meta<br>
&gt;<br>
&gt; drbdadm create-md drbd-vm<br>
&gt;<br>
&gt; However, when I try to make this configuration up by :<br>
&gt;<br>
&gt; drbdadm up drbd-vm<br>
&gt;<br>
&gt; Its come with error :<br>
&gt;<br>
&gt; $ sudo drbdadm up drbd-vm<br>
&gt; 1: Failure: (124) Device is attached to a disk (use detach first)<br>
&gt; Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU intern=
al<br>
&gt; --set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dp=
ass_on&#39;<br>
&gt; terminated with exit code 10<br>
&gt;<br>
&gt; If I run the<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt;<br>
&gt; Its come error<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt; 1: State change failed: (-2) Need access to UpToDate data<br>
&gt; Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17<br>
&gt;<br>
&gt; Here the /proc/drbd on both machine<br>
&gt;<br>
&gt; Machine 1<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne1,<br>
&gt; 2013-02-18 18:49:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown =A0 r----s=
<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b=
 def:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Machine 2<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne2,<br>
&gt; 2013-02-18 19:26:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown =A0 =
r----s<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b de=
f:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Do you have some hints?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt;<br>
&gt; Agya<br>
&gt;<br>
&gt;<br>
&gt;&gt; thanks<br>
&gt;&gt; shriram<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"=
mailto:herydians@gmail.com">herydians@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hello, Anyone have a clue? I have tried but still failed :(<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"ma=
ilto:agya.naila@gmail.com">agya.naila@gmail.com</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Dear all,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I am configure my machine to run the remus disk replicati=
on. I am using<br>
&gt;&gt; &gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit =
both for Dom0<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; DomU.<br>
&gt;&gt; &gt;&gt; I have install the blktap and its work properly with conf=
iguration<br>
&gt;&gt; &gt;&gt; string<br>
&gt;&gt; &gt;&gt; phy or tap2 like this :<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; or<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&=
#39;]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and remus command<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; However when I change the string as suggested on remus pa=
ges to enable<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; disk replication its still failed :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; &gt;&gt; memory =3D 1024<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggrou=
p/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; &gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with error messages :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; &gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; &gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|ai=
o:/dev/vggroup/DomU&#39;)<br>
&gt;&gt; &gt;&gt; failed<br>
&gt;&gt; &gt;&gt; (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and on the log file :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br=
>
&gt;&gt; &gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<=
br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/Xen=
dDomainInfo.py&quot;,<br>
&gt;&gt; &gt;&gt; line<br>
&gt;&gt; &gt;&gt; 3987, in create_vbd<br>
&gt;&gt; &gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 174, in createDevice<br>
&gt;&gt; &gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)=
<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 286, in create<br>
&gt;&gt; &gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#=
39;-a%s:%s&#39; % (dtype, image))<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 233, in exc<br>
&gt;&gt; &gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; &gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) =
failed (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Agya<br>
&gt;&gt; &gt;&gt;<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@list=
s.xen.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_bla=
nk">http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Xen-devel mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xe=
n.org</a><br>
&gt;&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">=
http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>

--047d7bb04c9a0eb1b904d606dc19--


--===============4790152514405467051==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4790152514405467051==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 22:14:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22: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 1U7YyC-0006aJ-Qe; Mon, 18 Feb 2013 22:13:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7YyB-0006a6-Gc; Mon, 18 Feb 2013 22:13:55 +0000
Received: from [85.158.143.99:26416] by server-2.bemta-4.messagelabs.com id
	A0/B7-12656-2A7A2215; Mon, 18 Feb 2013 22:13:54 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361225628!27150695!1
X-Originating-IP: [74.125.82.180]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28846 invoked from network); 18 Feb 2013 22:13:49 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 22:13:49 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so5012206wer.39
	for <multiple recipients>; Mon, 18 Feb 2013 14:13:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=p4g1tH8Rx62BX/0trQmexP0fgMXLXkZBzl1+42FIjbg=;
	b=nVB40bgxjmjErd9H5guGHrtiEoyrcD17O4DbKD+Xv2zwfy0JwlG72Mj4hNZiQo4VwL
	/vMYVqJZ7XSoQ96HK4qEcoJ/PxBTBFZ9sRjLjkyUDdjq7728v+eHRFCbAB0SBTPhAt0+
	sLj/yxV75drCecMAwYeT/NT717NAS0/CL9h1SidjBYc+J/gf4L+Hc5z8Yuex6xPrAkTX
	RlU3pU+4WwEwXMRLBKjU/Zv6qAdUxYcJs9bSZ3khbh9cHLhzdLt8tjHMQ7Mp1Ta0NJ7C
	IEVa8XQEFORExunPByNJvwZDYlBcJgYaaSxE/tikydw5U5h0bWHYG/KAWAH3RoJ8eLAD
	Ndkg==
MIME-Version: 1.0
X-Received: by 10.180.98.232 with SMTP id el8mr19975098wib.22.1361225628717;
	Mon, 18 Feb 2013 14:13:48 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 14:13:48 -0800 (PST)
In-Reply-To: <CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
	<CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
	<CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
Date: Mon, 18 Feb 2013 23:13:48 +0100
Message-ID: <CAN-nQwjGKc4rchMZnTdowb4ASMq6N02sVcy9XYddhbogZiCUKQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3998643178288505166=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3998643178288505166==
Content-Type: multipart/alternative; boundary=f46d0442885e0f10fe04d6070a66

--f46d0442885e0f10fe04d6070a66
Content-Type: text/plain; charset=ISO-8859-1

I forgot to told that its  work with protocol C

 $ sudo drbd-overview
  1:drbd-vm  SyncTarget Secondary/Secondary Inconsistent/UpToDate C r-----
        [=>..................] sync'ed: 12.0% (9016/10236)M

$ sudo drbd-overview
  1:drbd-vm  Connected Secondary/Secondary UpToDate/UpToDate C r-----


On Mon, Feb 18, 2013 at 11:00 PM, agya naila <agya.naila@gmail.com> wrote:

> On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:
>
>> Hi,
>>  I suggest you read up on the DRBD setup documentation from the
>> drbd.org website.
>>  The setup procedure is same. You can later flip to the remus
>> replication protocol by simply
>>  changing the protocol type (C to D).
>>
>> I am comparing my configuration with drbd website, however I got this
> error :
>
> $ sudo drbdadm up drbd-vm
> *'D' is no valid protocol.*
> *Command 'drbdsetup 1 net ipv4:10.10.10.1:7789 ipv4:10.10.10.3:7789 D
> --set-defaults --create-device --rr-conflict=disconnect
> --after-sb-2pri=disconnect --after-sb-1pri=discard-secondary
> --after-sb-0pri=discard-younger-primary --allow-two-primaries --ko-count=4
> --max-epoch-size=4096 --unplug-watermark=4096 --max-buffers=8192
> --ping-timeout=20 --ping-int=3 --timeout=30' terminated with exit code 20*
> *drbdadm connect drbd-vm: exited with code 20*
> *
> *
> $ sudo drbd-overview
>   1:drbd-vm  StandAlone Secondary/Unknown UpToDate/DUnknown r----s
>
> Thank you,
>
> Agya
>
>
>
>> thanks
>> shriram
>>
>> On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com> wrote:
>> >
>> > On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <
>> rshriram@cs.ubc.ca>
>> > wrote:
>> >>
>> >> hi
>> >
>> >
>> > Thank you shriram.
>> >
>> >>
>> >>  sorry for the delayed response. IIRC the blktap2 driver required for
>> >> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>> >>  I havent used it in a long time myself. I suggest trying disk
>> >> replication with DRBD.
>> >>
>> >
>> > I am also found some information here
>> > http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2
>> problem on
>> > amd64 architecture. I have tried to install and configure the DRBD but
>> its
>> > didn't connect each other.
>> > I used drbd-8.3.11-remus and installed as follow
>> >
>> > cd /usr/src/
>> > wget
>> >
>> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
>> > tar xzf drbd-8.3.9-remus.tar.gz
>> > chown -R root:root drbd-8.3-remus
>> > cd /usr/src/drbd-8.3-remus
>> > chmod 777 autogen.sh
>> > ./autogen.sh
>> > dpkg-buildpackage -b -uc
>> > cd /usr/src/drbd-8.3-remus/drbd
>> > make clean
>> > make
>> > make install
>> > cd /usr/src/
>> > cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
>> > /etc/drbd.d/global_common.conf
>> > cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
>> > /etc/drbd.d/SystemHA_protoD.res
>> >
>> > sudo apt-get install drbd8-utils
>> >
>> >  from tutorial
>> http://remusha.wikidot.com/configuring-and-installing-remus
>> >
>> > My *.res configuration as follow :
>> >
>> > resource drbd-vm{
>> >   device    /dev/drbd1;
>> >   disk      /dev/vgvoip/DomU;
>> >   meta-disk internal;
>> >   on machine1 {
>> >     address   10.10.10.1:7789;
>> >   }
>> >   on machine2 {
>> >     address   10.10.10.3:7789;
>> >   }
>> > }
>> >
>> > and then I invoke command to create that meta
>> >
>> > drbdadm create-md drbd-vm
>> >
>> > However, when I try to make this configuration up by :
>> >
>> > drbdadm up drbd-vm
>> >
>> > Its come with error :
>> >
>> > $ sudo drbdadm up drbd-vm
>> > 1: Failure: (124) Device is attached to a disk (use detach first)
>> > Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
>> > --set-defaults --create-device --fencing=dont-care
>> --on-io-error=pass_on'
>> > terminated with exit code 10
>> >
>> > If I run the
>> >
>> > $ sudo drbdadm detach drbd-vm
>> >
>> > Its come error
>> >
>> > $ sudo drbdadm detach drbd-vm
>> > 1: State change failed: (-2) Need access to UpToDate data
>> > Command 'drbdsetup 1 detach' terminated with exit code 17
>> >
>> > Here the /proc/drbd on both machine
>> >
>> > Machine 1
>> >
>> > $ sudo cat /proc/drbd
>> > version: 8.3.11 (api:88/proto:86-96)
>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>> root@machine1,
>> > 2013-02-18 18:49:57
>> >
>> >  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
>> >     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
>> > chkpt:0 oos:10485404
>> >
>> >
>> > Machine 2
>> >
>> > $ sudo cat /proc/drbd
>> > version: 8.3.11 (api:88/proto:86-96)
>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>> root@machine2,
>> > 2013-02-18 19:26:57
>> >
>> >  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
>> >     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
>> > chkpt:0 oos:10485404
>> >
>> >
>> > Do you have some hints?
>> >
>> > Thank you,
>> >
>> >
>> > Agya
>> >
>> >
>> >> thanks
>> >> shriram
>> >>
>> >> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <
>> herydians@gmail.com>
>> >> wrote:
>> >> > Hello, Anyone have a clue? I have tried but still failed :(
>> >> >
>> >> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Dear all,
>> >> >>
>> >> >> I am configure my machine to run the remus disk replication. I am
>> using
>> >> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for
>> Dom0
>> >> >> and
>> >> >> DomU.
>> >> >> I have install the blktap and its work properly with configuration
>> >> >> string
>> >> >> phy or tap2 like this :
>> >> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>> >> >> or
>> >> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>> >> >>
>> >> >> and remus command
>> >> >>
>> >> >> remus --no-net myvm mybackuphost
>> >> >>
>> >> >>
>> >> >> However when I change the string as suggested on remus pages to
>> enable
>> >> >> the
>> >> >> disk replication its still failed :
>> >> >>
>> >> >> name = "DomU"
>> >> >> memory = 1024
>> >> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>> >> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
>> >> >> bootloader = "pygrub"
>> >> >>
>> >> >> with error messages :
>> >> >>
>> >> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>> >> >> Using config file "/etc/xen/DomU.cfg".
>> >> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
>> >> >> failed
>> >> >> (512  )
>> >> >>
>> >> >> and on the log file :
>> >> >>
>> >> >>
>> >> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>> >> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>> >> >>   File
>> >> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
>> >> >> line
>> >> >> 3987, in create_vbd
>> >> >>     devid = dev_control.createDevice(config)
>> >> >>   File
>> >> >>
>> >> >>
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> >> line 174, in createDevice
>> >> >>     device = TapdiskController.create(params, file)
>> >> >>   File
>> >> >>
>> >> >>
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> >> line 286, in create
>> >> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype,
>> image))
>> >> >>   File
>> >> >>
>> >> >>
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> >> line 233, in exc
>> >> >>     (args, rc, out, err))
>> >> >> TapdiskException: ('create',
>> >> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>> >> >>
>> >> >> Any hints and help would very appreciated.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Agya
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Xen-devel mailing list
>> >> >> Xen-devel@lists.xen.org
>> >> >> http://lists.xen.org/xen-devel
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Xen-devel mailing list
>> >> > Xen-devel@lists.xen.org
>> >> > http://lists.xen.org/xen-devel
>> >> >
>> >
>> >
>>
>
>

--f46d0442885e0f10fe04d6070a66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I forgot to told that its =A0work with protocol C<div><br></div><div><div><=
font face=3D"courier new, monospace">=A0$ sudo drbd-overview</font></div><d=
iv><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0SyncTarget Second=
ary/Secondary Inconsistent/UpToDate C r-----</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 [=3D&gt;........=
..........] sync&#39;ed: 12.0% (9016/10236)M</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">$ sudo drbd-overview</font></div>
<div><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0Connected Secon=
dary/Secondary UpToDate/UpToDate C r-----</font></div><div><br></div><div><=
br></div><div class=3D"gmail_quote">On Mon, Feb 18, 2013 at 11:00 PM, agya =
naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.naila@gmail.com" target=
=3D"_blank">agya.naila@gmail.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"im"><div>On Mon, Feb 18, 2013 =
at 10:33 PM, Shriram Rajagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rs=
hriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote=
:</div>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
Hi,<br>
=A0I suggest you read up on the DRBD setup documentation from the<br>
<a href=3D"http://drbd.org" target=3D"_blank">drbd.org</a> website.<br>
=A0The setup procedure is same. You can later flip to the remus<br>
replication protocol by simply<br>
=A0changing the protocol type (C to D).<br>
<br></blockquote></div>I am comparing my configuration with drbd website, h=
owever I got this error :<div><br></div><div><div class=3D"im"><div><font f=
ace=3D"courier new, monospace">$ sudo drbdadm up drbd-vm</font></div></div>
<div><font face=3D"courier new, monospace"><b>&#39;D&#39; is no valid proto=
col.</b></font></div>
<div><font face=3D"courier new, monospace"><b>Command &#39;drbdsetup 1 net =
ipv4:<a href=3D"http://10.10.10.1:7789" target=3D"_blank">10.10.10.1:7789</=
a> ipv4:<a href=3D"http://10.10.10.3:7789" target=3D"_blank">10.10.10.3:778=
9</a> D --set-defaults --create-device --rr-conflict=3Ddisconnect --after-s=
b-2pri=3Ddisconnect --after-sb-1pri=3Ddiscard-secondary --after-sb-0pri=3Dd=
iscard-younger-primary --allow-two-primaries --ko-count=3D4 --max-epoch-siz=
e=3D4096 --unplug-watermark=3D4096 --max-buffers=3D8192 --ping-timeout=3D20=
 --ping-int=3D3 --timeout=3D30&#39; terminated with exit code 20</b></font>=
</div>

<div><font face=3D"courier new, monospace"><b>drbdadm connect drbd-vm: exit=
ed with code 20</b></font></div><div><font face=3D"courier new, monospace">=
<b><br></b></font></div><div><font face=3D"courier new, monospace">$ sudo d=
rbd-overview</font></div>

</div><div><span style=3D"font-family:&#39;courier new&#39;,monospace">=A0 =
1:drbd-vm =A0StandAlone Secondary/Unknown UpToDate/DUnknown r----s</span></=
div><div><div class=3D"h5"><div><br></div><div>Thank you,</div><div><br></d=
iv>
<div>Agya</div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span><font color=3D"#888888">shriram<br>
</font></span><div><div><br>
On Mon, Feb 18, 2013 at 4:11 PM, agya naila &lt;<a href=3D"mailto:agya.nail=
a@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan &lt;<a href=3D"ma=
ilto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; hi<br>
&gt;<br>
&gt;<br>
&gt; Thank you shriram.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0sorry for the delayed response. IIRC the blktap2 driver require=
d for<br>
&gt;&gt; tapdisk replication doesnt exist in the mainstream dom0 kernels, I=
IRC.<br>
&gt;&gt; =A0I havent used it in a long time myself. I suggest trying disk<b=
r>
&gt;&gt; replication with DRBD.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I am also found some information here<br>
&gt; <a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html" target=
=3D"_blank">http://osdir.com/ml/xen-users/2011-07/msg00653.html</a> about b=
lktap2 problem on<br>
&gt; amd64 architecture. I have tried to install and configure the DRBD but=
 its<br>
&gt; didn&#39;t connect each other.<br>
&gt; I used drbd-8.3.11-remus and installed as follow<br>
&gt;<br>
&gt; cd /usr/src/<br>
&gt; wget<br>
&gt; <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz" target=3D"_blank">http://remusha.wi=
kidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.t=
ar.gz</a><br>


&gt; tar xzf drbd-8.3.9-remus.tar.gz<br>
&gt; chown -R root:root drbd-8.3-remus<br>
&gt; cd /usr/src/drbd-8.3-remus<br>
&gt; chmod 777 autogen.sh<br>
&gt; ./autogen.sh<br>
&gt; dpkg-buildpackage -b -uc<br>
&gt; cd /usr/src/drbd-8.3-remus/drbd<br>
&gt; make clean<br>
&gt; make<br>
&gt; make install<br>
&gt; cd /usr/src/<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD<br>
&gt; /etc/drbd.d/global_common.conf<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res<br>
&gt; /etc/drbd.d/SystemHA_protoD.res<br>
&gt;<br>
&gt; sudo apt-get install drbd8-utils<br>
&gt;<br>
&gt; =A0from tutorial <a href=3D"http://remusha.wikidot.com/configuring-and=
-installing-remus" target=3D"_blank">http://remusha.wikidot.com/configuring=
-and-installing-remus</a><br>
&gt;<br>
&gt; My *.res configuration as follow :<br>
&gt;<br>
&gt; resource drbd-vm{<br>
&gt; =A0 device =A0 =A0/dev/drbd1;<br>
&gt; =A0 disk =A0 =A0 =A0/dev/vgvoip/DomU;<br>
&gt; =A0 meta-disk internal;<br>
&gt; =A0 on machine1 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.1:7789" target=3D"_blan=
k">10.10.10.1:7789</a>;<br>
&gt; =A0 }<br>
&gt; =A0 on machine2 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.3:7789" target=3D"_blan=
k">10.10.10.3:7789</a>;<br>
&gt; =A0 }<br>
&gt; }<br>
&gt;<br>
&gt; and then I invoke command to create that meta<br>
&gt;<br>
&gt; drbdadm create-md drbd-vm<br>
&gt;<br>
&gt; However, when I try to make this configuration up by :<br>
&gt;<br>
&gt; drbdadm up drbd-vm<br>
&gt;<br>
&gt; Its come with error :<br>
&gt;<br>
&gt; $ sudo drbdadm up drbd-vm<br>
&gt; 1: Failure: (124) Device is attached to a disk (use detach first)<br>
&gt; Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU intern=
al<br>
&gt; --set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dp=
ass_on&#39;<br>
&gt; terminated with exit code 10<br>
&gt;<br>
&gt; If I run the<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt;<br>
&gt; Its come error<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt; 1: State change failed: (-2) Need access to UpToDate data<br>
&gt; Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17<br>
&gt;<br>
&gt; Here the /proc/drbd on both machine<br>
&gt;<br>
&gt; Machine 1<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne1,<br>
&gt; 2013-02-18 18:49:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown =A0 r----s=
<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b=
 def:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Machine 2<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne2,<br>
&gt; 2013-02-18 19:26:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown =A0 =
r----s<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b de=
f:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Do you have some hints?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt;<br>
&gt; Agya<br>
&gt;<br>
&gt;<br>
&gt;&gt; thanks<br>
&gt;&gt; shriram<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"=
mailto:herydians@gmail.com" target=3D"_blank">herydians@gmail.com</a>&gt;<b=
r>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hello, Anyone have a clue? I have tried but still failed :(<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"ma=
ilto:agya.naila@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt;<b=
r>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Dear all,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I am configure my machine to run the remus disk replicati=
on. I am using<br>
&gt;&gt; &gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit =
both for Dom0<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; DomU.<br>
&gt;&gt; &gt;&gt; I have install the blktap and its work properly with conf=
iguration<br>
&gt;&gt; &gt;&gt; string<br>
&gt;&gt; &gt;&gt; phy or tap2 like this :<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; or<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&=
#39;]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and remus command<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; However when I change the string as suggested on remus pa=
ges to enable<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; disk replication its still failed :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; &gt;&gt; memory =3D 1024<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggrou=
p/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; &gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with error messages :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; &gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; &gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|ai=
o:/dev/vggroup/DomU&#39;)<br>
&gt;&gt; &gt;&gt; failed<br>
&gt;&gt; &gt;&gt; (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and on the log file :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br=
>
&gt;&gt; &gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<=
br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/Xen=
dDomainInfo.py&quot;,<br>
&gt;&gt; &gt;&gt; line<br>
&gt;&gt; &gt;&gt; 3987, in create_vbd<br>
&gt;&gt; &gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 174, in createDevice<br>
&gt;&gt; &gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)=
<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 286, in create<br>
&gt;&gt; &gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#=
39;-a%s:%s&#39; % (dtype, image))<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 233, in exc<br>
&gt;&gt; &gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; &gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) =
failed (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Agya<br>
&gt;&gt; &gt;&gt;<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" target=3D"_bla=
nk">Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_bla=
nk">http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Xen-devel mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">=
Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">=
http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br></div>

--f46d0442885e0f10fe04d6070a66--


--===============3998643178288505166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3998643178288505166==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 22:14:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22: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 1U7YyC-0006aJ-Qe; Mon, 18 Feb 2013 22:13:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7YyB-0006a6-Gc; Mon, 18 Feb 2013 22:13:55 +0000
Received: from [85.158.143.99:26416] by server-2.bemta-4.messagelabs.com id
	A0/B7-12656-2A7A2215; Mon, 18 Feb 2013 22:13:54 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361225628!27150695!1
X-Originating-IP: [74.125.82.180]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28846 invoked from network); 18 Feb 2013 22:13:49 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Feb 2013 22:13:49 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so5012206wer.39
	for <multiple recipients>; Mon, 18 Feb 2013 14:13:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=p4g1tH8Rx62BX/0trQmexP0fgMXLXkZBzl1+42FIjbg=;
	b=nVB40bgxjmjErd9H5guGHrtiEoyrcD17O4DbKD+Xv2zwfy0JwlG72Mj4hNZiQo4VwL
	/vMYVqJZ7XSoQ96HK4qEcoJ/PxBTBFZ9sRjLjkyUDdjq7728v+eHRFCbAB0SBTPhAt0+
	sLj/yxV75drCecMAwYeT/NT717NAS0/CL9h1SidjBYc+J/gf4L+Hc5z8Yuex6xPrAkTX
	RlU3pU+4WwEwXMRLBKjU/Zv6qAdUxYcJs9bSZ3khbh9cHLhzdLt8tjHMQ7Mp1Ta0NJ7C
	IEVa8XQEFORExunPByNJvwZDYlBcJgYaaSxE/tikydw5U5h0bWHYG/KAWAH3RoJ8eLAD
	Ndkg==
MIME-Version: 1.0
X-Received: by 10.180.98.232 with SMTP id el8mr19975098wib.22.1361225628717;
	Mon, 18 Feb 2013 14:13:48 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 14:13:48 -0800 (PST)
In-Reply-To: <CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
	<CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
	<CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
Date: Mon, 18 Feb 2013 23:13:48 +0100
Message-ID: <CAN-nQwjGKc4rchMZnTdowb4ASMq6N02sVcy9XYddhbogZiCUKQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3998643178288505166=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3998643178288505166==
Content-Type: multipart/alternative; boundary=f46d0442885e0f10fe04d6070a66

--f46d0442885e0f10fe04d6070a66
Content-Type: text/plain; charset=ISO-8859-1

I forgot to told that its  work with protocol C

 $ sudo drbd-overview
  1:drbd-vm  SyncTarget Secondary/Secondary Inconsistent/UpToDate C r-----
        [=>..................] sync'ed: 12.0% (9016/10236)M

$ sudo drbd-overview
  1:drbd-vm  Connected Secondary/Secondary UpToDate/UpToDate C r-----


On Mon, Feb 18, 2013 at 11:00 PM, agya naila <agya.naila@gmail.com> wrote:

> On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:
>
>> Hi,
>>  I suggest you read up on the DRBD setup documentation from the
>> drbd.org website.
>>  The setup procedure is same. You can later flip to the remus
>> replication protocol by simply
>>  changing the protocol type (C to D).
>>
>> I am comparing my configuration with drbd website, however I got this
> error :
>
> $ sudo drbdadm up drbd-vm
> *'D' is no valid protocol.*
> *Command 'drbdsetup 1 net ipv4:10.10.10.1:7789 ipv4:10.10.10.3:7789 D
> --set-defaults --create-device --rr-conflict=disconnect
> --after-sb-2pri=disconnect --after-sb-1pri=discard-secondary
> --after-sb-0pri=discard-younger-primary --allow-two-primaries --ko-count=4
> --max-epoch-size=4096 --unplug-watermark=4096 --max-buffers=8192
> --ping-timeout=20 --ping-int=3 --timeout=30' terminated with exit code 20*
> *drbdadm connect drbd-vm: exited with code 20*
> *
> *
> $ sudo drbd-overview
>   1:drbd-vm  StandAlone Secondary/Unknown UpToDate/DUnknown r----s
>
> Thank you,
>
> Agya
>
>
>
>> thanks
>> shriram
>>
>> On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com> wrote:
>> >
>> > On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <
>> rshriram@cs.ubc.ca>
>> > wrote:
>> >>
>> >> hi
>> >
>> >
>> > Thank you shriram.
>> >
>> >>
>> >>  sorry for the delayed response. IIRC the blktap2 driver required for
>> >> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>> >>  I havent used it in a long time myself. I suggest trying disk
>> >> replication with DRBD.
>> >>
>> >
>> > I am also found some information here
>> > http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2
>> problem on
>> > amd64 architecture. I have tried to install and configure the DRBD but
>> its
>> > didn't connect each other.
>> > I used drbd-8.3.11-remus and installed as follow
>> >
>> > cd /usr/src/
>> > wget
>> >
>> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
>> > tar xzf drbd-8.3.9-remus.tar.gz
>> > chown -R root:root drbd-8.3-remus
>> > cd /usr/src/drbd-8.3-remus
>> > chmod 777 autogen.sh
>> > ./autogen.sh
>> > dpkg-buildpackage -b -uc
>> > cd /usr/src/drbd-8.3-remus/drbd
>> > make clean
>> > make
>> > make install
>> > cd /usr/src/
>> > cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
>> > /etc/drbd.d/global_common.conf
>> > cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
>> > /etc/drbd.d/SystemHA_protoD.res
>> >
>> > sudo apt-get install drbd8-utils
>> >
>> >  from tutorial
>> http://remusha.wikidot.com/configuring-and-installing-remus
>> >
>> > My *.res configuration as follow :
>> >
>> > resource drbd-vm{
>> >   device    /dev/drbd1;
>> >   disk      /dev/vgvoip/DomU;
>> >   meta-disk internal;
>> >   on machine1 {
>> >     address   10.10.10.1:7789;
>> >   }
>> >   on machine2 {
>> >     address   10.10.10.3:7789;
>> >   }
>> > }
>> >
>> > and then I invoke command to create that meta
>> >
>> > drbdadm create-md drbd-vm
>> >
>> > However, when I try to make this configuration up by :
>> >
>> > drbdadm up drbd-vm
>> >
>> > Its come with error :
>> >
>> > $ sudo drbdadm up drbd-vm
>> > 1: Failure: (124) Device is attached to a disk (use detach first)
>> > Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
>> > --set-defaults --create-device --fencing=dont-care
>> --on-io-error=pass_on'
>> > terminated with exit code 10
>> >
>> > If I run the
>> >
>> > $ sudo drbdadm detach drbd-vm
>> >
>> > Its come error
>> >
>> > $ sudo drbdadm detach drbd-vm
>> > 1: State change failed: (-2) Need access to UpToDate data
>> > Command 'drbdsetup 1 detach' terminated with exit code 17
>> >
>> > Here the /proc/drbd on both machine
>> >
>> > Machine 1
>> >
>> > $ sudo cat /proc/drbd
>> > version: 8.3.11 (api:88/proto:86-96)
>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>> root@machine1,
>> > 2013-02-18 18:49:57
>> >
>> >  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
>> >     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
>> > chkpt:0 oos:10485404
>> >
>> >
>> > Machine 2
>> >
>> > $ sudo cat /proc/drbd
>> > version: 8.3.11 (api:88/proto:86-96)
>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>> root@machine2,
>> > 2013-02-18 19:26:57
>> >
>> >  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----s
>> >     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
>> > chkpt:0 oos:10485404
>> >
>> >
>> > Do you have some hints?
>> >
>> > Thank you,
>> >
>> >
>> > Agya
>> >
>> >
>> >> thanks
>> >> shriram
>> >>
>> >> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <
>> herydians@gmail.com>
>> >> wrote:
>> >> > Hello, Anyone have a clue? I have tried but still failed :(
>> >> >
>> >> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Dear all,
>> >> >>
>> >> >> I am configure my machine to run the remus disk replication. I am
>> using
>> >> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for
>> Dom0
>> >> >> and
>> >> >> DomU.
>> >> >> I have install the blktap and its work properly with configuration
>> >> >> string
>> >> >> phy or tap2 like this :
>> >> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>> >> >> or
>> >> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>> >> >>
>> >> >> and remus command
>> >> >>
>> >> >> remus --no-net myvm mybackuphost
>> >> >>
>> >> >>
>> >> >> However when I change the string as suggested on remus pages to
>> enable
>> >> >> the
>> >> >> disk replication its still failed :
>> >> >>
>> >> >> name = "DomU"
>> >> >> memory = 1024
>> >> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>> >> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
>> >> >> bootloader = "pygrub"
>> >> >>
>> >> >> with error messages :
>> >> >>
>> >> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>> >> >> Using config file "/etc/xen/DomU.cfg".
>> >> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
>> >> >> failed
>> >> >> (512  )
>> >> >>
>> >> >> and on the log file :
>> >> >>
>> >> >>
>> >> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>> >> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>> >> >>   File
>> >> >> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
>> >> >> line
>> >> >> 3987, in create_vbd
>> >> >>     devid = dev_control.createDevice(config)
>> >> >>   File
>> >> >>
>> >> >>
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> >> line 174, in createDevice
>> >> >>     device = TapdiskController.create(params, file)
>> >> >>   File
>> >> >>
>> >> >>
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> >> line 286, in create
>> >> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype,
>> image))
>> >> >>   File
>> >> >>
>> >> >>
>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>> >> >> line 233, in exc
>> >> >>     (args, rc, out, err))
>> >> >> TapdiskException: ('create',
>> >> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>> >> >>
>> >> >> Any hints and help would very appreciated.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Agya
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Xen-devel mailing list
>> >> >> Xen-devel@lists.xen.org
>> >> >> http://lists.xen.org/xen-devel
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Xen-devel mailing list
>> >> > Xen-devel@lists.xen.org
>> >> > http://lists.xen.org/xen-devel
>> >> >
>> >
>> >
>>
>
>

--f46d0442885e0f10fe04d6070a66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I forgot to told that its =A0work with protocol C<div><br></div><div><div><=
font face=3D"courier new, monospace">=A0$ sudo drbd-overview</font></div><d=
iv><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0SyncTarget Second=
ary/Secondary Inconsistent/UpToDate C r-----</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 [=3D&gt;........=
..........] sync&#39;ed: 12.0% (9016/10236)M</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">$ sudo drbd-overview</font></div>
<div><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0Connected Secon=
dary/Secondary UpToDate/UpToDate C r-----</font></div><div><br></div><div><=
br></div><div class=3D"gmail_quote">On Mon, Feb 18, 2013 at 11:00 PM, agya =
naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.naila@gmail.com" target=
=3D"_blank">agya.naila@gmail.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"im"><div>On Mon, Feb 18, 2013 =
at 10:33 PM, Shriram Rajagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rs=
hriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote=
:</div>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
Hi,<br>
=A0I suggest you read up on the DRBD setup documentation from the<br>
<a href=3D"http://drbd.org" target=3D"_blank">drbd.org</a> website.<br>
=A0The setup procedure is same. You can later flip to the remus<br>
replication protocol by simply<br>
=A0changing the protocol type (C to D).<br>
<br></blockquote></div>I am comparing my configuration with drbd website, h=
owever I got this error :<div><br></div><div><div class=3D"im"><div><font f=
ace=3D"courier new, monospace">$ sudo drbdadm up drbd-vm</font></div></div>
<div><font face=3D"courier new, monospace"><b>&#39;D&#39; is no valid proto=
col.</b></font></div>
<div><font face=3D"courier new, monospace"><b>Command &#39;drbdsetup 1 net =
ipv4:<a href=3D"http://10.10.10.1:7789" target=3D"_blank">10.10.10.1:7789</=
a> ipv4:<a href=3D"http://10.10.10.3:7789" target=3D"_blank">10.10.10.3:778=
9</a> D --set-defaults --create-device --rr-conflict=3Ddisconnect --after-s=
b-2pri=3Ddisconnect --after-sb-1pri=3Ddiscard-secondary --after-sb-0pri=3Dd=
iscard-younger-primary --allow-two-primaries --ko-count=3D4 --max-epoch-siz=
e=3D4096 --unplug-watermark=3D4096 --max-buffers=3D8192 --ping-timeout=3D20=
 --ping-int=3D3 --timeout=3D30&#39; terminated with exit code 20</b></font>=
</div>

<div><font face=3D"courier new, monospace"><b>drbdadm connect drbd-vm: exit=
ed with code 20</b></font></div><div><font face=3D"courier new, monospace">=
<b><br></b></font></div><div><font face=3D"courier new, monospace">$ sudo d=
rbd-overview</font></div>

</div><div><span style=3D"font-family:&#39;courier new&#39;,monospace">=A0 =
1:drbd-vm =A0StandAlone Secondary/Unknown UpToDate/DUnknown r----s</span></=
div><div><div class=3D"h5"><div><br></div><div>Thank you,</div><div><br></d=
iv>
<div>Agya</div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span><font color=3D"#888888">shriram<br>
</font></span><div><div><br>
On Mon, Feb 18, 2013 at 4:11 PM, agya naila &lt;<a href=3D"mailto:agya.nail=
a@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan &lt;<a href=3D"ma=
ilto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; hi<br>
&gt;<br>
&gt;<br>
&gt; Thank you shriram.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0sorry for the delayed response. IIRC the blktap2 driver require=
d for<br>
&gt;&gt; tapdisk replication doesnt exist in the mainstream dom0 kernels, I=
IRC.<br>
&gt;&gt; =A0I havent used it in a long time myself. I suggest trying disk<b=
r>
&gt;&gt; replication with DRBD.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I am also found some information here<br>
&gt; <a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html" target=
=3D"_blank">http://osdir.com/ml/xen-users/2011-07/msg00653.html</a> about b=
lktap2 problem on<br>
&gt; amd64 architecture. I have tried to install and configure the DRBD but=
 its<br>
&gt; didn&#39;t connect each other.<br>
&gt; I used drbd-8.3.11-remus and installed as follow<br>
&gt;<br>
&gt; cd /usr/src/<br>
&gt; wget<br>
&gt; <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz" target=3D"_blank">http://remusha.wi=
kidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.t=
ar.gz</a><br>


&gt; tar xzf drbd-8.3.9-remus.tar.gz<br>
&gt; chown -R root:root drbd-8.3-remus<br>
&gt; cd /usr/src/drbd-8.3-remus<br>
&gt; chmod 777 autogen.sh<br>
&gt; ./autogen.sh<br>
&gt; dpkg-buildpackage -b -uc<br>
&gt; cd /usr/src/drbd-8.3-remus/drbd<br>
&gt; make clean<br>
&gt; make<br>
&gt; make install<br>
&gt; cd /usr/src/<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD<br>
&gt; /etc/drbd.d/global_common.conf<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res<br>
&gt; /etc/drbd.d/SystemHA_protoD.res<br>
&gt;<br>
&gt; sudo apt-get install drbd8-utils<br>
&gt;<br>
&gt; =A0from tutorial <a href=3D"http://remusha.wikidot.com/configuring-and=
-installing-remus" target=3D"_blank">http://remusha.wikidot.com/configuring=
-and-installing-remus</a><br>
&gt;<br>
&gt; My *.res configuration as follow :<br>
&gt;<br>
&gt; resource drbd-vm{<br>
&gt; =A0 device =A0 =A0/dev/drbd1;<br>
&gt; =A0 disk =A0 =A0 =A0/dev/vgvoip/DomU;<br>
&gt; =A0 meta-disk internal;<br>
&gt; =A0 on machine1 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.1:7789" target=3D"_blan=
k">10.10.10.1:7789</a>;<br>
&gt; =A0 }<br>
&gt; =A0 on machine2 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.3:7789" target=3D"_blan=
k">10.10.10.3:7789</a>;<br>
&gt; =A0 }<br>
&gt; }<br>
&gt;<br>
&gt; and then I invoke command to create that meta<br>
&gt;<br>
&gt; drbdadm create-md drbd-vm<br>
&gt;<br>
&gt; However, when I try to make this configuration up by :<br>
&gt;<br>
&gt; drbdadm up drbd-vm<br>
&gt;<br>
&gt; Its come with error :<br>
&gt;<br>
&gt; $ sudo drbdadm up drbd-vm<br>
&gt; 1: Failure: (124) Device is attached to a disk (use detach first)<br>
&gt; Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU intern=
al<br>
&gt; --set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dp=
ass_on&#39;<br>
&gt; terminated with exit code 10<br>
&gt;<br>
&gt; If I run the<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt;<br>
&gt; Its come error<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt; 1: State change failed: (-2) Need access to UpToDate data<br>
&gt; Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17<br>
&gt;<br>
&gt; Here the /proc/drbd on both machine<br>
&gt;<br>
&gt; Machine 1<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne1,<br>
&gt; 2013-02-18 18:49:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown =A0 r----s=
<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b=
 def:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Machine 2<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne2,<br>
&gt; 2013-02-18 19:26:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown =A0 =
r----s<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b de=
f:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Do you have some hints?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt;<br>
&gt; Agya<br>
&gt;<br>
&gt;<br>
&gt;&gt; thanks<br>
&gt;&gt; shriram<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"=
mailto:herydians@gmail.com" target=3D"_blank">herydians@gmail.com</a>&gt;<b=
r>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hello, Anyone have a clue? I have tried but still failed :(<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"ma=
ilto:agya.naila@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt;<b=
r>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Dear all,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I am configure my machine to run the remus disk replicati=
on. I am using<br>
&gt;&gt; &gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit =
both for Dom0<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; DomU.<br>
&gt;&gt; &gt;&gt; I have install the blktap and its work properly with conf=
iguration<br>
&gt;&gt; &gt;&gt; string<br>
&gt;&gt; &gt;&gt; phy or tap2 like this :<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; or<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&=
#39;]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and remus command<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; However when I change the string as suggested on remus pa=
ges to enable<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; disk replication its still failed :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; &gt;&gt; memory =3D 1024<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggrou=
p/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; &gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with error messages :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; &gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; &gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|ai=
o:/dev/vggroup/DomU&#39;)<br>
&gt;&gt; &gt;&gt; failed<br>
&gt;&gt; &gt;&gt; (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and on the log file :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br=
>
&gt;&gt; &gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<=
br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/Xen=
dDomainInfo.py&quot;,<br>
&gt;&gt; &gt;&gt; line<br>
&gt;&gt; &gt;&gt; 3987, in create_vbd<br>
&gt;&gt; &gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 174, in createDevice<br>
&gt;&gt; &gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)=
<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 286, in create<br>
&gt;&gt; &gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#=
39;-a%s:%s&#39; % (dtype, image))<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 233, in exc<br>
&gt;&gt; &gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; &gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) =
failed (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Agya<br>
&gt;&gt; &gt;&gt;<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" target=3D"_bla=
nk">Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_bla=
nk">http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Xen-devel mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">=
Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">=
http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br></div>

--f46d0442885e0f10fe04d6070a66--


--===============3998643178288505166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3998643178288505166==--


From xen-devel-bounces@lists.xen.org Mon Feb 18 22:42:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22:42: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 1U7ZQ3-0008TD-CN; Mon, 18 Feb 2013 22:42:43 +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 1U7ZQ1-0008Sr-UW
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 22:42:42 +0000
Received: from [85.158.143.35:36274] by server-1.bemta-4.messagelabs.com id
	D8/1B-08839-16EA2215; Mon, 18 Feb 2013 22:42:41 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-21.messagelabs.com!1361227357!12402371!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28018 invoked from network); 18 Feb 2013 22:42:40 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-12.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 22:42:40 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7ZPv-0002JX-4o; Tue, 19 Feb 2013 09:42:35 +1100
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 id
	14.01.0438.000; Tue, 19 Feb 2013 09:42:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Erwan RIGOLLOT <erwan@rigollot.me>
Thread-Topic: [Xen-devel] GPLPV
Thread-Index: AQHODblRtbwo4yxEekWAGSmkTVhptZh/Yaeg//9TZICAALx3wP//bkgAgAFWb7A=
Date: Mon, 18 Feb 2013 22:42:33 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356801F6@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
	<5122053F.9050400@rigollot.me>
	<6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
	<CAAxhNBD=n+eeVeNf2CV_34p-R5HuJGziUYEOOPxyKMD7+2RMAA@mail.gmail.com>
In-Reply-To: <CAAxhNBD=n+eeVeNf2CV_34p-R5HuJGziUYEOOPxyKMD7+2RMAA@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:388:e000:712:2088:5a93:4fa0:263e]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19646.002
x-tm-as-result: No--40.541100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 resoled this problem.
> The kernel module xen_gntdev wasn't loaded. It was built as a module....
> 
> Now, the install of GPLPV has done successfuly and all is good in device
> manager with VL drivers.
> 

Hmm... I'll see if I can test that and make sure GPLPV doesn't actually crash. I might need a way to indicate this problem to the user though as in the absence of a crash the user might think it was working without knowing it wasn't.

> I have a question, is it still necessary to put GPLPV option at windows boot?
> (LOADOPTIONS "GPLPV" or /GPLPV)
> 
> What is the objective of that?
> 

That information is old. You would use /NOGPLPV to disable the drivers but in the absence of any options they would be disabled.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 22:42:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22:42: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 1U7ZQ3-0008TD-CN; Mon, 18 Feb 2013 22:42:43 +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 1U7ZQ1-0008Sr-UW
	for xen-devel@lists.xensource.com; Mon, 18 Feb 2013 22:42:42 +0000
Received: from [85.158.143.35:36274] by server-1.bemta-4.messagelabs.com id
	D8/1B-08839-16EA2215; Mon, 18 Feb 2013 22:42:41 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-21.messagelabs.com!1361227357!12402371!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28018 invoked from network); 18 Feb 2013 22:42:40 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-12.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 22:42:40 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7ZPv-0002JX-4o; Tue, 19 Feb 2013 09:42:35 +1100
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 id
	14.01.0438.000; Tue, 19 Feb 2013 09:42:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Erwan RIGOLLOT <erwan@rigollot.me>
Thread-Topic: [Xen-devel] GPLPV
Thread-Index: AQHODblRtbwo4yxEekWAGSmkTVhptZh/Yaeg//9TZICAALx3wP//bkgAgAFWb7A=
Date: Mon, 18 Feb 2013 22:42:33 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356801F6@BITCOM1.int.sbss.com.au>
References: <CAAxhNBASy_Vc-XPWJNwJGR_qL2B2zzLJoM-ndDvMLc2yb8_7OA@mail.gmail.com>
	<6035A0D088A63A46850C3988ED045A4B3567EC65@BITCOM1.int.sbss.com.au>
	<5122053F.9050400@rigollot.me>
	<6035A0D088A63A46850C3988ED045A4B3567EE38@BITCOM1.int.sbss.com.au>
	<CAAxhNBD=n+eeVeNf2CV_34p-R5HuJGziUYEOOPxyKMD7+2RMAA@mail.gmail.com>
In-Reply-To: <CAAxhNBD=n+eeVeNf2CV_34p-R5HuJGziUYEOOPxyKMD7+2RMAA@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:388:e000:712:2088:5a93:4fa0:263e]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19646.002
x-tm-as-result: No--40.541100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 resoled this problem.
> The kernel module xen_gntdev wasn't loaded. It was built as a module....
> 
> Now, the install of GPLPV has done successfuly and all is good in device
> manager with VL drivers.
> 

Hmm... I'll see if I can test that and make sure GPLPV doesn't actually crash. I might need a way to indicate this problem to the user though as in the absence of a crash the user might think it was working without knowing it wasn't.

> I have a question, is it still necessary to put GPLPV option at windows boot?
> (LOADOPTIONS "GPLPV" or /GPLPV)
> 
> What is the objective of that?
> 

That information is old. You would use /NOGPLPV to disable the drivers but in the absence of any options they would be disabled.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 18 22:58:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22:58: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 1U7Zev-0001Fk-G3; Mon, 18 Feb 2013 22:58:05 +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 1U7Zeu-0001Fa-2S
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 22:58:04 +0000
Received: from [193.109.254.147:6116] by server-8.bemta-14.messagelabs.com id
	B8/41-17325-BF1B2215; Mon, 18 Feb 2013 22:58:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361228282!8819772!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16642 invoked from network); 18 Feb 2013 22:58:02 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 22:58:02 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:58998 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 1U7Zlf-0007RC-DP; Tue, 19 Feb 2013 00:05:03 +0100
Date: Mon, 18 Feb 2013 23:58:00 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <836217002.20130218235800@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361184758.31407.145.camel@zakaz.uk.xensource.com>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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


Monday, February 18, 2013, 11:52:38 AM, you wrote:

> On Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
>> Hi All,
>> 
>> Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
>> Previous pull was working fine and was about 3 or 4 days ago.

> Do you happen to know the exact revisions?

> Please can you try running xl under gdb and get a backtrace.

Hmm sorry for the noise, didn't properly cleanup stale files from the reverted "install to /usr/local/" changes.
That went ok from jan 27th till now .. so it didn't immediately rang a bell.

--
Sander


>> Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
>> Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]
>> 
>> --
>> 
>> Sander
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 18 22:58:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 18 Feb 2013 22:58: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 1U7Zev-0001Fk-G3; Mon, 18 Feb 2013 22:58:05 +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 1U7Zeu-0001Fa-2S
	for xen-devel@lists.xen.org; Mon, 18 Feb 2013 22:58:04 +0000
Received: from [193.109.254.147:6116] by server-8.bemta-14.messagelabs.com id
	B8/41-17325-BF1B2215; Mon, 18 Feb 2013 22:58:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361228282!8819772!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16642 invoked from network); 18 Feb 2013 22:58:02 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Feb 2013 22:58:02 -0000
Received: from 190-64-ftth.on.nl ([88.159.64.190]:58998 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 1U7Zlf-0007RC-DP; Tue, 19 Feb 2013 00:05:03 +0100
Date: Mon, 18 Feb 2013 23:58:00 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <836217002.20130218235800@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361184758.31407.145.camel@zakaz.uk.xensource.com>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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


Monday, February 18, 2013, 11:52:38 AM, you wrote:

> On Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
>> Hi All,
>> 
>> Just tried the latest staging/xen-unstable (on debian squeeze dom0) but xl seems to segfaults (at least on domain creation):
>> Previous pull was working fine and was about 3 or 4 days ago.

> Do you happen to know the exact revisions?

> Please can you try running xl under gdb and get a backtrace.

Hmm sorry for the noise, didn't properly cleanup stale files from the reverted "install to /usr/local/" changes.
That went ok from jan 27th till now .. so it didn't immediately rang a bell.

--
Sander


>> Feb 18 11:16:34 serveerstertje kernel: [  108.202658] xl[6783]: segfault at 100000000 ip 00007f065126ff52 sp 00007fffdd05b5e0 error 4 in libxenlight.so.2.0.0[7f065123d000+59000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.677224] xl[6788]: segfault at 100000000 ip 00007f1fa4f6cf32 sp 00007fffa26e90d8 error 4 in libc-2.11.3.so[7f1fa4ef1000+159000]
>> Feb 18 11:16:34 serveerstertje kernel: [  108.713586] xl[6796]: segfault at 100000000 ip 00007f15429eaf52 sp 00007fffbdd89640 error 4 in libxenlight.so.2.0.0[7f15429b8000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.045944] xl[6801]: segfault at 61 ip 00007f4961f2a2d3 sp 00007fff76133320 error 4 in libxenlight.so.2.0.0[7f4961efa000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.096701] xl[6809]: segfault at 100000000 ip 00007f26198ebf52 sp 00007fff6eca8df0 error 4 in libxenlight.so.2.0.0[7f26198b9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.421280] xl[6814]: segfault at 61 ip 00007f77919112d3 sp 00007fff6e506e80 error 4 in libxenlight.so.2.0.0[7f77918e1000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.460799] xl[6822]: segfault at 100000000 ip 00007fa33638cf52 sp 00007fff91540ce0 error 4 in libxenlight.so.2.0.0[7fa33635a000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.787701] xl[6827]: segfault at 61 ip 00007fc844cd92d3 sp 00007fff9cd3a8f0 error 4 in libxenlight.so.2.0.0[7fc844ca9000+59000]
>> Feb 18 11:16:35 serveerstertje kernel: [  109.825382] xl[6835]: segfault at 100000000 ip 00007f834c0dcf52 sp 00007fff131d7590 error 4 in libxenlight.so.2.0.0[7f834c0aa000+59000]
>> Feb 18 11:16:36 serveerstertje kernel: [  110.153905] xl[6840]: segfault at 61 ip 00007fe964e5b2d3 sp 00007fff7920cf30 error 4 in libxenlight.so.2.0.0[7fe964e2b000+59000]
>> 
>> --
>> 
>> Sander
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 19 00:03:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 00: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 1U7ag3-0003qw-6b; Tue, 19 Feb 2013 00:03:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7ag1-0003qi-Eo
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 00:03:17 +0000
Received: from [85.158.139.83:24786] by server-2.bemta-5.messagelabs.com id
	DB/ED-16911-441C2215; Tue, 19 Feb 2013 00:03:16 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361232195!23963340!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29816 invoked from network); 19 Feb 2013 00:03:15 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 00:03:15 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id D66FF84080;
	Tue, 19 Feb 2013 01:03:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 2NfpMj6zGrIa; Tue, 19 Feb 2013 01:03:14 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 8A0F78407F;
	Tue, 19 Feb 2013 01:03:14 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7afx-0001VQ-A9; Tue, 19 Feb 2013 01:03:13 +0100
Date: Tue, 19 Feb 2013 01:03:13 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219000313.GN7019@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<20130218171224.GL17292@type.bordeaux.inria.fr>
	<1361208062.3825.47.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361208062.3825.47.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Wei Liu, le Mon 18 Feb 2013 17:21:02 +0000, a =E9crit :
> So apart from the modification needed, is this "32" really a bottleneck
> for xenstore-stubdom?

Actually I don't think it is: from what I see in the xenstore source,
different FDs are only used for connexions on the unix-connexion
socket, but for stubdoms, such socket does not make sense and is thus
disabled anyway.  So NOFILE being 32 is actually not an issue at all for
xenstore-stubdom.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 00:03:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 00: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 1U7ag3-0003qw-6b; Tue, 19 Feb 2013 00:03:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7ag1-0003qi-Eo
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 00:03:17 +0000
Received: from [85.158.139.83:24786] by server-2.bemta-5.messagelabs.com id
	DB/ED-16911-441C2215; Tue, 19 Feb 2013 00:03:16 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361232195!23963340!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29816 invoked from network); 19 Feb 2013 00:03:15 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 00:03:15 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id D66FF84080;
	Tue, 19 Feb 2013 01:03:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 2NfpMj6zGrIa; Tue, 19 Feb 2013 01:03:14 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 8A0F78407F;
	Tue, 19 Feb 2013 01:03:14 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7afx-0001VQ-A9; Tue, 19 Feb 2013 01:03:13 +0100
Date: Tue, 19 Feb 2013 01:03:13 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219000313.GN7019@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
	<20130218171224.GL17292@type.bordeaux.inria.fr>
	<1361208062.3825.47.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361208062.3825.47.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Wei Liu, le Mon 18 Feb 2013 17:21:02 +0000, a =E9crit :
> So apart from the modification needed, is this "32" really a bottleneck
> for xenstore-stubdom?

Actually I don't think it is: from what I see in the xenstore source,
different FDs are only used for connexions on the unix-connexion
socket, but for stubdoms, such socket does not make sense and is thus
disabled anyway.  So NOFILE being 32 is actually not an issue at all for
xenstore-stubdom.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 00:07:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 00:07: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 1U7ak2-00042y-S9; Tue, 19 Feb 2013 00:07:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7ak1-00042p-7t
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 00:07:25 +0000
Received: from [85.158.139.83:2047] by server-2.bemta-5.messagelabs.com id
	EC/80-16911-C32C2215; Tue, 19 Feb 2013 00:07:24 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361232443!27155745!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13001 invoked from network); 19 Feb 2013 00:07:24 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 00:07:24 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 8C8E484080;
	Tue, 19 Feb 2013 01:06:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id DMCz6hAXTWZQ; Tue, 19 Feb 2013 01:06:10 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 458CC8407F;
	Tue, 19 Feb 2013 01:06:10 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7aim-0001Xv-Ut; Tue, 19 Feb 2013 01:06:08 +0100
Date: Tue, 19 Feb 2013 01:06:08 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219000608.GO7019@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361202056.3825.28.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Wei Liu, le Mon 18 Feb 2013 15:40:56 +0000, a =E9crit :
> +    ret =3D select(&rfds, &wfds, NULL, &_timeo);
> +
> +    for (i =3D 0; i < nfds; i++) {
> +        fd =3D pfd[i].fd;

Here we have to set revents to 0 before adding some bits. The caller may
not have cleared revents already.

> +	if (FD_ISSET(fd, &rfds))
> +            pfd[i].revents |=3D POLLIN;
> +	if (FD_ISSET(fd, &wfds))
> +            pfd[i].revents |=3D POLLOUT;
> +    }

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 00:07:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 00:07: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 1U7ak2-00042y-S9; Tue, 19 Feb 2013 00:07:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7ak1-00042p-7t
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 00:07:25 +0000
Received: from [85.158.139.83:2047] by server-2.bemta-5.messagelabs.com id
	EC/80-16911-C32C2215; Tue, 19 Feb 2013 00:07:24 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361232443!27155745!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13001 invoked from network); 19 Feb 2013 00:07:24 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 00:07:24 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 8C8E484080;
	Tue, 19 Feb 2013 01:06:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id DMCz6hAXTWZQ; Tue, 19 Feb 2013 01:06:10 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 458CC8407F;
	Tue, 19 Feb 2013 01:06:10 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7aim-0001Xv-Ut; Tue, 19 Feb 2013 01:06:08 +0100
Date: Tue, 19 Feb 2013 01:06:08 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219000608.GO7019@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
References: <1361202056.3825.28.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361202056.3825.28.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Implementing poll(2) for Mini-OS?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Wei Liu, le Mon 18 Feb 2013 15:40:56 +0000, a =E9crit :
> +    ret =3D select(&rfds, &wfds, NULL, &_timeo);
> +
> +    for (i =3D 0; i < nfds; i++) {
> +        fd =3D pfd[i].fd;

Here we have to set revents to 0 before adding some bits. The caller may
not have cleared revents already.

> +	if (FD_ISSET(fd, &rfds))
> +            pfd[i].revents |=3D POLLIN;
> +	if (FD_ISSET(fd, &wfds))
> +            pfd[i].revents |=3D POLLOUT;
> +    }

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 01:39:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 01:39: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 1U7cAh-0000Q8-7b; Tue, 19 Feb 2013 01:39: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 1U7cAf-0000Q3-0L
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 01:39:01 +0000
Received: from [85.158.137.99:55907] by server-12.bemta-3.messagelabs.com id
	72/6A-05889-4B7D2215; Tue, 19 Feb 2013 01:39:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361237939!22012183!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13443 invoked from network); 19 Feb 2013 01:38:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 01:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; 
   d="scan'208";a="1586876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 01:39: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.297.1; Tue, 19 Feb 2013 01:38:59 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7cAc-0007Ae-Ox;
	Tue, 19 Feb 2013 01:38:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7cAc-0006Td-DN;
	Tue, 19 Feb 2013 01:38:58 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16206-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 01:38:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16206: 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 16206 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16206/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 16159
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16159

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  9f12bdd6b7f0
baseline version:
 xen                  cb92e40d8681

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Sander Eikelenboom <linux@eikelenboom.it>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=9f12bdd6b7f0
+ . 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 9f12bdd6b7f0
+ branch=xen-4.1-testing
+ revision=9f12bdd6b7f0
+ . 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/hg/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 9f12bdd6b7f0 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 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 Tue Feb 19 01:39:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 01:39: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 1U7cAh-0000Q8-7b; Tue, 19 Feb 2013 01:39: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 1U7cAf-0000Q3-0L
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 01:39:01 +0000
Received: from [85.158.137.99:55907] by server-12.bemta-3.messagelabs.com id
	72/6A-05889-4B7D2215; Tue, 19 Feb 2013 01:39:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361237939!22012183!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.7; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13443 invoked from network); 19 Feb 2013 01:38:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 01:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; 
   d="scan'208";a="1586876"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 01:39: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.297.1; Tue, 19 Feb 2013 01:38:59 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7cAc-0007Ae-Ox;
	Tue, 19 Feb 2013 01:38:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7cAc-0006Td-DN;
	Tue, 19 Feb 2013 01:38:58 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16206-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 01:38:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16206: 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 16206 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16206/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 16159
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16159

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  9f12bdd6b7f0
baseline version:
 xen                  cb92e40d8681

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Sander Eikelenboom <linux@eikelenboom.it>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=9f12bdd6b7f0
+ . 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 9f12bdd6b7f0
+ branch=xen-4.1-testing
+ revision=9f12bdd6b7f0
+ . 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/hg/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 9f12bdd6b7f0 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 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 Tue Feb 19 05:43:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 05: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 1U7fyK-0002Cn-Vk; Tue, 19 Feb 2013 05:42: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 1U7fyJ-0002Ci-3u
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 05:42:31 +0000
Received: from [85.158.138.51:25983] by server-1.bemta-3.messagelabs.com id
	29/04-08955-6C013215; Tue, 19 Feb 2013 05:42:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361252549!28123546!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9484 invoked from network); 19 Feb 2013 05:42:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 05:42:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; 
   d="scan'208";a="1588668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 05:42: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.297.1; Tue, 19 Feb 2013 05:42:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7fyG-0008ND-UG;
	Tue, 19 Feb 2013 05:42:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7fyG-00007N-Mv;
	Tue, 19 Feb 2013 05:42:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16207-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 05:42:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16207: 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 16207 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16207/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 16171

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16171

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win-vcpus1 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-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  620e5d3aa7cd
baseline version:
 xen                  788f4551580d

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Eddie Dong <eddie.dong@intel.com>
  Fabio Fantoni <fabio.fantoni@heliman.it>
  Frediano Ziglio <frediano.ziglio@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Lalith Suresh <suresh.lalith@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Ross Philipson <ross.philipson@citrix.com>
  Shakeel Butt <shakeel.butt@gmail.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 762 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 05:43:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 05: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 1U7fyK-0002Cn-Vk; Tue, 19 Feb 2013 05:42: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 1U7fyJ-0002Ci-3u
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 05:42:31 +0000
Received: from [85.158.138.51:25983] by server-1.bemta-3.messagelabs.com id
	29/04-08955-6C013215; Tue, 19 Feb 2013 05:42:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361252549!28123546!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9484 invoked from network); 19 Feb 2013 05:42:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 05:42:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; 
   d="scan'208";a="1588668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 05:42: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.297.1; Tue, 19 Feb 2013 05:42:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7fyG-0008ND-UG;
	Tue, 19 Feb 2013 05:42:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7fyG-00007N-Mv;
	Tue, 19 Feb 2013 05:42:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16207-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 05:42:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16207: 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 16207 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16207/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 16171

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16171

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win-vcpus1 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-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  620e5d3aa7cd
baseline version:
 xen                  788f4551580d

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Eddie Dong <eddie.dong@intel.com>
  Fabio Fantoni <fabio.fantoni@heliman.it>
  Frediano Ziglio <frediano.ziglio@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Lalith Suresh <suresh.lalith@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Ross Philipson <ross.philipson@citrix.com>
  Shakeel Butt <shakeel.butt@gmail.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

(No revision log; it would be 762 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 05:54:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 05:54: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 1U7g9R-0002O8-RL; Tue, 19 Feb 2013 05:54:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U7g9Q-0002O3-N5
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 05:54:00 +0000
Received: from [85.158.139.211:13680] by server-10.bemta-5.messagelabs.com id
	12/42-04697-77313215; Tue, 19 Feb 2013 05:53:59 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361253238!18143910!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17093 invoked from network); 19 Feb 2013 05:53:59 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 05:53:59 -0000
Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id C4872581169;
	Mon, 18 Feb 2013 21:54:00 -0800 (PST)
Date: Tue, 19 Feb 2013 00:53:56 -0500 (EST)
Message-Id: <20130219.005356.2288460992654639558.davem@davemloft.net>
To: drjones@redhat.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1361219360-29176-1-git-send-email-drjones@redhat.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(shards.monkeyblade.net [0.0.0.0]);
	Mon, 18 Feb 2013 21:54:01 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Date: Mon, 18 Feb 2013 21:29:20 +0100

> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> have one reference to the vif at this time, then the xenvif_put
> in netbk_fatal_tx_err is one too many.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 05:54:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 05:54: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 1U7g9R-0002O8-RL; Tue, 19 Feb 2013 05:54:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U7g9Q-0002O3-N5
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 05:54:00 +0000
Received: from [85.158.139.211:13680] by server-10.bemta-5.messagelabs.com id
	12/42-04697-77313215; Tue, 19 Feb 2013 05:53:59 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361253238!18143910!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17093 invoked from network); 19 Feb 2013 05:53:59 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-2.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 05:53:59 -0000
Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id C4872581169;
	Mon, 18 Feb 2013 21:54:00 -0800 (PST)
Date: Tue, 19 Feb 2013 00:53:56 -0500 (EST)
Message-Id: <20130219.005356.2288460992654639558.davem@davemloft.net>
To: drjones@redhat.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1361219360-29176-1-git-send-email-drjones@redhat.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(shards.monkeyblade.net [0.0.0.0]);
	Mon, 18 Feb 2013 21:54:01 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Date: Mon, 18 Feb 2013 21:29:20 +0100

> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> have one reference to the vif at this time, then the xenvif_put
> in netbk_fatal_tx_err is one too many.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 07:38:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 07:38: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 1U7hmI-0003DD-Ds; Tue, 19 Feb 2013 07:38:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7hmG-0003D5-I0; Tue, 19 Feb 2013 07:38:12 +0000
Received: from [193.109.254.147:14896] by server-14.bemta-14.messagelabs.com
	id 0D/7D-02031-3EB23215; Tue, 19 Feb 2013 07:38:11 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361259484!6446863!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27229 invoked from network); 19 Feb 2013 07:38:04 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 07:38:04 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so4432769wie.2
	for <multiple recipients>; Mon, 18 Feb 2013 23:38:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=CKZOqcNXKrcF7HX5ICq3Q42QROEcqiPmVHlN6MXIlIs=;
	b=o2qfu92JHwcGWfcQG0TLqNjZ/HcbYm1tHbxKRdygBWbwBtOHIwl5cuyH7RxsmlAnRL
	HGeCkjdN9JXQSJ42DUM7zv/8mcURMEjr8PUr9WmafiA1EOzXnzMpz4rKBln3gAbHkRtN
	CKo6ODTkJdDwa/OMImZqB6t/qvP8V1BaxnCxLkdqAqcEOWt6HwhGfc7yavlTBMVdko5J
	rmezZF37UPVKB/C5gSZmsN55Z07Iu1pB47e1O1f15MfJQ/2C6RSFUbUAQnWon+/GDVbc
	Xr/SYkXwG9KCfMiJIZzF9qQL5wyznJ/0pMA1dsDTbzYamlXdnNmJoSf/HN9nkd64efvQ
	XApQ==
MIME-Version: 1.0
X-Received: by 10.194.158.165 with SMTP id wv5mr23954132wjb.45.1361259484599; 
	Mon, 18 Feb 2013 23:38:04 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 23:38:04 -0800 (PST)
In-Reply-To: <CAN-nQwjGKc4rchMZnTdowb4ASMq6N02sVcy9XYddhbogZiCUKQ@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
	<CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
	<CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
	<CAN-nQwjGKc4rchMZnTdowb4ASMq6N02sVcy9XYddhbogZiCUKQ@mail.gmail.com>
Date: Tue, 19 Feb 2013 08:38:04 +0100
Message-ID: <CAN-nQwhBNn6-0WWxQn_tUJ7zVnp0vFnhfW20ag_LOvgA4yhavQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3277700120673485894=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3277700120673485894==
Content-Type: multipart/alternative; boundary=089e0122ef8806d75f04d60eecc2

--089e0122ef8806d75f04d60eecc2
Content-Type: text/plain; charset=ISO-8859-1

Okay, I solve it. I removed drbd8-utils and re-install drbd from sources.
DRBD connected with D protocol. I could go further with disk replication,
hopefully there is no mistaken step again :)

Regards,

Agya

On Mon, Feb 18, 2013 at 11:13 PM, agya naila <agya.naila@gmail.com> wrote:

> I forgot to told that its  work with protocol C
>
>  $ sudo drbd-overview
>   1:drbd-vm  SyncTarget Secondary/Secondary Inconsistent/UpToDate C r-----
>         [=>..................] sync'ed: 12.0% (9016/10236)M
>
> $ sudo drbd-overview
>   1:drbd-vm  Connected Secondary/Secondary UpToDate/UpToDate C r-----
>
>
> On Mon, Feb 18, 2013 at 11:00 PM, agya naila <agya.naila@gmail.com> wrote:
>
>> On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca
>> > wrote:
>>
>>> Hi,
>>>  I suggest you read up on the DRBD setup documentation from the
>>> drbd.org website.
>>>  The setup procedure is same. You can later flip to the remus
>>> replication protocol by simply
>>>  changing the protocol type (C to D).
>>>
>>> I am comparing my configuration with drbd website, however I got this
>> error :
>>
>> $ sudo drbdadm up drbd-vm
>> *'D' is no valid protocol.*
>> *Command 'drbdsetup 1 net ipv4:10.10.10.1:7789 ipv4:10.10.10.3:7789 D
>> --set-defaults --create-device --rr-conflict=disconnect
>> --after-sb-2pri=disconnect --after-sb-1pri=discard-secondary
>> --after-sb-0pri=discard-younger-primary --allow-two-primaries --ko-count=4
>> --max-epoch-size=4096 --unplug-watermark=4096 --max-buffers=8192
>> --ping-timeout=20 --ping-int=3 --timeout=30' terminated with exit code 20
>> *
>> *drbdadm connect drbd-vm: exited with code 20*
>> *
>> *
>> $ sudo drbd-overview
>>   1:drbd-vm  StandAlone Secondary/Unknown UpToDate/DUnknown r----s
>>
>> Thank you,
>>
>> Agya
>>
>>
>>
>>> thanks
>>> shriram
>>>
>>> On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com>
>>> wrote:
>>> >
>>> > On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <
>>> rshriram@cs.ubc.ca>
>>> > wrote:
>>> >>
>>> >> hi
>>> >
>>> >
>>> > Thank you shriram.
>>> >
>>> >>
>>> >>  sorry for the delayed response. IIRC the blktap2 driver required for
>>> >> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>>> >>  I havent used it in a long time myself. I suggest trying disk
>>> >> replication with DRBD.
>>> >>
>>> >
>>> > I am also found some information here
>>> > http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2
>>> problem on
>>> > amd64 architecture. I have tried to install and configure the DRBD but
>>> its
>>> > didn't connect each other.
>>> > I used drbd-8.3.11-remus and installed as follow
>>> >
>>> > cd /usr/src/
>>> > wget
>>> >
>>> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
>>> > tar xzf drbd-8.3.9-remus.tar.gz
>>> > chown -R root:root drbd-8.3-remus
>>> > cd /usr/src/drbd-8.3-remus
>>> > chmod 777 autogen.sh
>>> > ./autogen.sh
>>> > dpkg-buildpackage -b -uc
>>> > cd /usr/src/drbd-8.3-remus/drbd
>>> > make clean
>>> > make
>>> > make install
>>> > cd /usr/src/
>>> > cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
>>> > /etc/drbd.d/global_common.conf
>>> > cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
>>> > /etc/drbd.d/SystemHA_protoD.res
>>> >
>>> > sudo apt-get install drbd8-utils
>>> >
>>> >  from tutorial
>>> http://remusha.wikidot.com/configuring-and-installing-remus
>>> >
>>> > My *.res configuration as follow :
>>> >
>>> > resource drbd-vm{
>>> >   device    /dev/drbd1;
>>> >   disk      /dev/vgvoip/DomU;
>>> >   meta-disk internal;
>>> >   on machine1 {
>>> >     address   10.10.10.1:7789;
>>> >   }
>>> >   on machine2 {
>>> >     address   10.10.10.3:7789;
>>> >   }
>>> > }
>>> >
>>> > and then I invoke command to create that meta
>>> >
>>> > drbdadm create-md drbd-vm
>>> >
>>> > However, when I try to make this configuration up by :
>>> >
>>> > drbdadm up drbd-vm
>>> >
>>> > Its come with error :
>>> >
>>> > $ sudo drbdadm up drbd-vm
>>> > 1: Failure: (124) Device is attached to a disk (use detach first)
>>> > Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
>>> > --set-defaults --create-device --fencing=dont-care
>>> --on-io-error=pass_on'
>>> > terminated with exit code 10
>>> >
>>> > If I run the
>>> >
>>> > $ sudo drbdadm detach drbd-vm
>>> >
>>> > Its come error
>>> >
>>> > $ sudo drbdadm detach drbd-vm
>>> > 1: State change failed: (-2) Need access to UpToDate data
>>> > Command 'drbdsetup 1 detach' terminated with exit code 17
>>> >
>>> > Here the /proc/drbd on both machine
>>> >
>>> > Machine 1
>>> >
>>> > $ sudo cat /proc/drbd
>>> > version: 8.3.11 (api:88/proto:86-96)
>>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>>> root@machine1,
>>> > 2013-02-18 18:49:57
>>> >
>>> >  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
>>> >     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b
>>> def:0
>>> > chkpt:0 oos:10485404
>>> >
>>> >
>>> > Machine 2
>>> >
>>> > $ sudo cat /proc/drbd
>>> > version: 8.3.11 (api:88/proto:86-96)
>>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>>> root@machine2,
>>> > 2013-02-18 19:26:57
>>> >
>>> >  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown
>>> r----s
>>> >     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
>>> > chkpt:0 oos:10485404
>>> >
>>> >
>>> > Do you have some hints?
>>> >
>>> > Thank you,
>>> >
>>> >
>>> > Agya
>>> >
>>> >
>>> >> thanks
>>> >> shriram
>>> >>
>>> >> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <
>>> herydians@gmail.com>
>>> >> wrote:
>>> >> > Hello, Anyone have a clue? I have tried but still failed :(
>>> >> >
>>> >> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Dear all,
>>> >> >>
>>> >> >> I am configure my machine to run the remus disk replication. I am
>>> using
>>> >> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for
>>> Dom0
>>> >> >> and
>>> >> >> DomU.
>>> >> >> I have install the blktap and its work properly with configuration
>>> >> >> string
>>> >> >> phy or tap2 like this :
>>> >> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>>> >> >> or
>>> >> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>>> >> >>
>>> >> >> and remus command
>>> >> >>
>>> >> >> remus --no-net myvm mybackuphost
>>> >> >>
>>> >> >>
>>> >> >> However when I change the string as suggested on remus pages to
>>> enable
>>> >> >> the
>>> >> >> disk replication its still failed :
>>> >> >>
>>> >> >> name = "DomU"
>>> >> >> memory = 1024
>>> >> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>>> >> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
>>> >> >> bootloader = "pygrub"
>>> >> >>
>>> >> >> with error messages :
>>> >> >>
>>> >> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>>> >> >> Using config file "/etc/xen/DomU.cfg".
>>> >> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
>>> >> >> failed
>>> >> >> (512  )
>>> >> >>
>>> >> >> and on the log file :
>>> >> >>
>>> >> >>
>>> >> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>>> >> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>>> >> >>   File
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
>>> >> >> line
>>> >> >> 3987, in create_vbd
>>> >> >>     devid = dev_control.createDevice(config)
>>> >> >>   File
>>> >> >>
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>>> >> >> line 174, in createDevice
>>> >> >>     device = TapdiskController.create(params, file)
>>> >> >>   File
>>> >> >>
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>>> >> >> line 286, in create
>>> >> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype,
>>> image))
>>> >> >>   File
>>> >> >>
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>>> >> >> line 233, in exc
>>> >> >>     (args, rc, out, err))
>>> >> >> TapdiskException: ('create',
>>> >> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>>> >> >>
>>> >> >> Any hints and help would very appreciated.
>>> >> >>
>>> >> >> Regards,
>>> >> >>
>>> >> >> Agya
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Xen-devel mailing list
>>> >> >> Xen-devel@lists.xen.org
>>> >> >> http://lists.xen.org/xen-devel
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Xen-devel mailing list
>>> >> > Xen-devel@lists.xen.org
>>> >> > http://lists.xen.org/xen-devel
>>> >> >
>>> >
>>> >
>>>
>>
>>
>

--089e0122ef8806d75f04d60eecc2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Okay, I solve it. I removed drbd8-utils and re-install drbd from sources. D=
RBD connected with D protocol. I could go further with disk replication, ho=
pefully there is no mistaken step again :)<div><br></div><div>Regards,</div=
>
<div><br></div><div>Agya<br><br><div class=3D"gmail_quote">On Mon, Feb 18, =
2013 at 11:13 PM, agya naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.n=
aila@gmail.com" target=3D"_blank">agya.naila@gmail.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">I forgot to told that its =A0work with proto=
col C<div><br></div><div><div><font face=3D"courier new, monospace">=A0$ su=
do drbd-overview</font></div>
<div><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0SyncTarget Seco=
ndary/Secondary Inconsistent/UpToDate C r-----</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 [=3D&gt;........=
..........] sync&#39;ed: 12.0% (9016/10236)M</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">$ sudo drbd-overview</font></div>

<div><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0Connected Secon=
dary/Secondary UpToDate/UpToDate C r-----</font></div><div><div class=3D"h5=
"><div><br></div><div><br></div><div class=3D"gmail_quote">On Mon, Feb 18, =
2013 at 11:00 PM, agya naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.n=
aila@gmail.com" target=3D"_blank">agya.naila@gmail.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 Mon, Feb 18, 2013 at 10:33 PM, =
Shriram Rajagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc=
.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote:</div>

</div><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
=A0I suggest you read up on the DRBD setup documentation from the<br>
<a href=3D"http://drbd.org" target=3D"_blank">drbd.org</a> website.<br>
=A0The setup procedure is same. You can later flip to the remus<br>
replication protocol by simply<br>
=A0changing the protocol type (C to D).<br>
<br></blockquote></div>I am comparing my configuration with drbd website, h=
owever I got this error :<div><br></div><div><div><div><font face=3D"courie=
r new, monospace">$ sudo drbdadm up drbd-vm</font></div></div>
<div><font face=3D"courier new, monospace"><b>&#39;D&#39; is no valid proto=
col.</b></font></div>
<div><font face=3D"courier new, monospace"><b>Command &#39;drbdsetup 1 net =
ipv4:<a href=3D"http://10.10.10.1:7789" target=3D"_blank">10.10.10.1:7789</=
a> ipv4:<a href=3D"http://10.10.10.3:7789" target=3D"_blank">10.10.10.3:778=
9</a> D --set-defaults --create-device --rr-conflict=3Ddisconnect --after-s=
b-2pri=3Ddisconnect --after-sb-1pri=3Ddiscard-secondary --after-sb-0pri=3Dd=
iscard-younger-primary --allow-two-primaries --ko-count=3D4 --max-epoch-siz=
e=3D4096 --unplug-watermark=3D4096 --max-buffers=3D8192 --ping-timeout=3D20=
 --ping-int=3D3 --timeout=3D30&#39; terminated with exit code 20</b></font>=
</div>


<div><font face=3D"courier new, monospace"><b>drbdadm connect drbd-vm: exit=
ed with code 20</b></font></div><div><font face=3D"courier new, monospace">=
<b><br></b></font></div><div><font face=3D"courier new, monospace">$ sudo d=
rbd-overview</font></div>


</div><div><span style=3D"font-family:&#39;courier new&#39;,monospace">=A0 =
1:drbd-vm =A0StandAlone Secondary/Unknown UpToDate/DUnknown r----s</span></=
div><div><div><div><br></div><div>Thank you,</div><div><br></div>
<div>Agya</div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span><font color=3D"#888888">shriram<br>
</font></span><div><div><br>
On Mon, Feb 18, 2013 at 4:11 PM, agya naila &lt;<a href=3D"mailto:agya.nail=
a@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan &lt;<a href=3D"ma=
ilto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; hi<br>
&gt;<br>
&gt;<br>
&gt; Thank you shriram.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0sorry for the delayed response. IIRC the blktap2 driver require=
d for<br>
&gt;&gt; tapdisk replication doesnt exist in the mainstream dom0 kernels, I=
IRC.<br>
&gt;&gt; =A0I havent used it in a long time myself. I suggest trying disk<b=
r>
&gt;&gt; replication with DRBD.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I am also found some information here<br>
&gt; <a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html" target=
=3D"_blank">http://osdir.com/ml/xen-users/2011-07/msg00653.html</a> about b=
lktap2 problem on<br>
&gt; amd64 architecture. I have tried to install and configure the DRBD but=
 its<br>
&gt; didn&#39;t connect each other.<br>
&gt; I used drbd-8.3.11-remus and installed as follow<br>
&gt;<br>
&gt; cd /usr/src/<br>
&gt; wget<br>
&gt; <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz" target=3D"_blank">http://remusha.wi=
kidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.t=
ar.gz</a><br>



&gt; tar xzf drbd-8.3.9-remus.tar.gz<br>
&gt; chown -R root:root drbd-8.3-remus<br>
&gt; cd /usr/src/drbd-8.3-remus<br>
&gt; chmod 777 autogen.sh<br>
&gt; ./autogen.sh<br>
&gt; dpkg-buildpackage -b -uc<br>
&gt; cd /usr/src/drbd-8.3-remus/drbd<br>
&gt; make clean<br>
&gt; make<br>
&gt; make install<br>
&gt; cd /usr/src/<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD<br>
&gt; /etc/drbd.d/global_common.conf<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res<br>
&gt; /etc/drbd.d/SystemHA_protoD.res<br>
&gt;<br>
&gt; sudo apt-get install drbd8-utils<br>
&gt;<br>
&gt; =A0from tutorial <a href=3D"http://remusha.wikidot.com/configuring-and=
-installing-remus" target=3D"_blank">http://remusha.wikidot.com/configuring=
-and-installing-remus</a><br>
&gt;<br>
&gt; My *.res configuration as follow :<br>
&gt;<br>
&gt; resource drbd-vm{<br>
&gt; =A0 device =A0 =A0/dev/drbd1;<br>
&gt; =A0 disk =A0 =A0 =A0/dev/vgvoip/DomU;<br>
&gt; =A0 meta-disk internal;<br>
&gt; =A0 on machine1 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.1:7789" target=3D"_blan=
k">10.10.10.1:7789</a>;<br>
&gt; =A0 }<br>
&gt; =A0 on machine2 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.3:7789" target=3D"_blan=
k">10.10.10.3:7789</a>;<br>
&gt; =A0 }<br>
&gt; }<br>
&gt;<br>
&gt; and then I invoke command to create that meta<br>
&gt;<br>
&gt; drbdadm create-md drbd-vm<br>
&gt;<br>
&gt; However, when I try to make this configuration up by :<br>
&gt;<br>
&gt; drbdadm up drbd-vm<br>
&gt;<br>
&gt; Its come with error :<br>
&gt;<br>
&gt; $ sudo drbdadm up drbd-vm<br>
&gt; 1: Failure: (124) Device is attached to a disk (use detach first)<br>
&gt; Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU intern=
al<br>
&gt; --set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dp=
ass_on&#39;<br>
&gt; terminated with exit code 10<br>
&gt;<br>
&gt; If I run the<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt;<br>
&gt; Its come error<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt; 1: State change failed: (-2) Need access to UpToDate data<br>
&gt; Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17<br>
&gt;<br>
&gt; Here the /proc/drbd on both machine<br>
&gt;<br>
&gt; Machine 1<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne1,<br>
&gt; 2013-02-18 18:49:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown =A0 r----s=
<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b=
 def:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Machine 2<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne2,<br>
&gt; 2013-02-18 19:26:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown =A0 =
r----s<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b de=
f:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Do you have some hints?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt;<br>
&gt; Agya<br>
&gt;<br>
&gt;<br>
&gt;&gt; thanks<br>
&gt;&gt; shriram<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"=
mailto:herydians@gmail.com" target=3D"_blank">herydians@gmail.com</a>&gt;<b=
r>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hello, Anyone have a clue? I have tried but still failed :(<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"ma=
ilto:agya.naila@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt;<b=
r>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Dear all,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I am configure my machine to run the remus disk replicati=
on. I am using<br>
&gt;&gt; &gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit =
both for Dom0<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; DomU.<br>
&gt;&gt; &gt;&gt; I have install the blktap and its work properly with conf=
iguration<br>
&gt;&gt; &gt;&gt; string<br>
&gt;&gt; &gt;&gt; phy or tap2 like this :<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; or<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&=
#39;]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and remus command<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; However when I change the string as suggested on remus pa=
ges to enable<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; disk replication its still failed :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; &gt;&gt; memory =3D 1024<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggrou=
p/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; &gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with error messages :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; &gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; &gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|ai=
o:/dev/vggroup/DomU&#39;)<br>
&gt;&gt; &gt;&gt; failed<br>
&gt;&gt; &gt;&gt; (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and on the log file :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br=
>
&gt;&gt; &gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<=
br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/Xen=
dDomainInfo.py&quot;,<br>
&gt;&gt; &gt;&gt; line<br>
&gt;&gt; &gt;&gt; 3987, in create_vbd<br>
&gt;&gt; &gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 174, in createDevice<br>
&gt;&gt; &gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)=
<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 286, in create<br>
&gt;&gt; &gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#=
39;-a%s:%s&#39; % (dtype, image))<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 233, in exc<br>
&gt;&gt; &gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; &gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) =
failed (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Agya<br>
&gt;&gt; &gt;&gt;<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" target=3D"_bla=
nk">Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_bla=
nk">http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Xen-devel mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">=
Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">=
http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>

--089e0122ef8806d75f04d60eecc2--


--===============3277700120673485894==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3277700120673485894==--


From xen-devel-bounces@lists.xen.org Tue Feb 19 07:38:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 07:38: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 1U7hmI-0003DD-Ds; Tue, 19 Feb 2013 07:38:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agya.naila@gmail.com>)
	id 1U7hmG-0003D5-I0; Tue, 19 Feb 2013 07:38:12 +0000
Received: from [193.109.254.147:14896] by server-14.bemta-14.messagelabs.com
	id 0D/7D-02031-3EB23215; Tue, 19 Feb 2013 07:38:11 +0000
X-Env-Sender: agya.naila@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361259484!6446863!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27229 invoked from network); 19 Feb 2013 07:38:04 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 07:38:04 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so4432769wie.2
	for <multiple recipients>; Mon, 18 Feb 2013 23:38:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=CKZOqcNXKrcF7HX5ICq3Q42QROEcqiPmVHlN6MXIlIs=;
	b=o2qfu92JHwcGWfcQG0TLqNjZ/HcbYm1tHbxKRdygBWbwBtOHIwl5cuyH7RxsmlAnRL
	HGeCkjdN9JXQSJ42DUM7zv/8mcURMEjr8PUr9WmafiA1EOzXnzMpz4rKBln3gAbHkRtN
	CKo6ODTkJdDwa/OMImZqB6t/qvP8V1BaxnCxLkdqAqcEOWt6HwhGfc7yavlTBMVdko5J
	rmezZF37UPVKB/C5gSZmsN55Z07Iu1pB47e1O1f15MfJQ/2C6RSFUbUAQnWon+/GDVbc
	Xr/SYkXwG9KCfMiJIZzF9qQL5wyznJ/0pMA1dsDTbzYamlXdnNmJoSf/HN9nkd64efvQ
	XApQ==
MIME-Version: 1.0
X-Received: by 10.194.158.165 with SMTP id wv5mr23954132wjb.45.1361259484599; 
	Mon, 18 Feb 2013 23:38:04 -0800 (PST)
Received: by 10.216.236.13 with HTTP; Mon, 18 Feb 2013 23:38:04 -0800 (PST)
In-Reply-To: <CAN-nQwjGKc4rchMZnTdowb4ASMq6N02sVcy9XYddhbogZiCUKQ@mail.gmail.com>
References: <CAN-nQwjjbtXGaG9DUQw+FoFQExNq-SOXiWwYA7Uj5Zsocr7q4Q@mail.gmail.com>
	<CAOLjgn6A4_9v-GhxkzMV04Ar+=_ES--y=VhRN0aYpx6rRFdiog@mail.gmail.com>
	<CAP8mzPOw7scW2rKCDk=WN2r-wn69JzKM6-BkYJ0KcyL7DhztJw@mail.gmail.com>
	<CAN-nQwhpj_n8=AGj42NHF7HEe+NXVN9Y7MXYhwCqtXhQ01v-ng@mail.gmail.com>
	<CAP8mzPPYtem0n8UP_2zCvRfdzhXAT_g_gYVn0wehmzb2N5bfJQ@mail.gmail.com>
	<CAN-nQwgz7WaOJedcNOGiA7Q05syjPHRbQeNn2mf9bCP42gv4LA@mail.gmail.com>
	<CAN-nQwjGKc4rchMZnTdowb4ASMq6N02sVcy9XYddhbogZiCUKQ@mail.gmail.com>
Date: Tue, 19 Feb 2013 08:38:04 +0100
Message-ID: <CAN-nQwhBNn6-0WWxQn_tUJ7zVnp0vFnhfW20ag_LOvgA4yhavQ@mail.gmail.com>
From: agya naila <agya.naila@gmail.com>
To: rshriram@cs.ubc.ca
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Remus disk replication failed
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3277700120673485894=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3277700120673485894==
Content-Type: multipart/alternative; boundary=089e0122ef8806d75f04d60eecc2

--089e0122ef8806d75f04d60eecc2
Content-Type: text/plain; charset=ISO-8859-1

Okay, I solve it. I removed drbd8-utils and re-install drbd from sources.
DRBD connected with D protocol. I could go further with disk replication,
hopefully there is no mistaken step again :)

Regards,

Agya

On Mon, Feb 18, 2013 at 11:13 PM, agya naila <agya.naila@gmail.com> wrote:

> I forgot to told that its  work with protocol C
>
>  $ sudo drbd-overview
>   1:drbd-vm  SyncTarget Secondary/Secondary Inconsistent/UpToDate C r-----
>         [=>..................] sync'ed: 12.0% (9016/10236)M
>
> $ sudo drbd-overview
>   1:drbd-vm  Connected Secondary/Secondary UpToDate/UpToDate C r-----
>
>
> On Mon, Feb 18, 2013 at 11:00 PM, agya naila <agya.naila@gmail.com> wrote:
>
>> On Mon, Feb 18, 2013 at 10:33 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca
>> > wrote:
>>
>>> Hi,
>>>  I suggest you read up on the DRBD setup documentation from the
>>> drbd.org website.
>>>  The setup procedure is same. You can later flip to the remus
>>> replication protocol by simply
>>>  changing the protocol type (C to D).
>>>
>>> I am comparing my configuration with drbd website, however I got this
>> error :
>>
>> $ sudo drbdadm up drbd-vm
>> *'D' is no valid protocol.*
>> *Command 'drbdsetup 1 net ipv4:10.10.10.1:7789 ipv4:10.10.10.3:7789 D
>> --set-defaults --create-device --rr-conflict=disconnect
>> --after-sb-2pri=disconnect --after-sb-1pri=discard-secondary
>> --after-sb-0pri=discard-younger-primary --allow-two-primaries --ko-count=4
>> --max-epoch-size=4096 --unplug-watermark=4096 --max-buffers=8192
>> --ping-timeout=20 --ping-int=3 --timeout=30' terminated with exit code 20
>> *
>> *drbdadm connect drbd-vm: exited with code 20*
>> *
>> *
>> $ sudo drbd-overview
>>   1:drbd-vm  StandAlone Secondary/Unknown UpToDate/DUnknown r----s
>>
>> Thank you,
>>
>> Agya
>>
>>
>>
>>> thanks
>>> shriram
>>>
>>> On Mon, Feb 18, 2013 at 4:11 PM, agya naila <agya.naila@gmail.com>
>>> wrote:
>>> >
>>> > On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan <
>>> rshriram@cs.ubc.ca>
>>> > wrote:
>>> >>
>>> >> hi
>>> >
>>> >
>>> > Thank you shriram.
>>> >
>>> >>
>>> >>  sorry for the delayed response. IIRC the blktap2 driver required for
>>> >> tapdisk replication doesnt exist in the mainstream dom0 kernels, IIRC.
>>> >>  I havent used it in a long time myself. I suggest trying disk
>>> >> replication with DRBD.
>>> >>
>>> >
>>> > I am also found some information here
>>> > http://osdir.com/ml/xen-users/2011-07/msg00653.html about blktap2
>>> problem on
>>> > amd64 architecture. I have tried to install and configure the DRBD but
>>> its
>>> > didn't connect each other.
>>> > I used drbd-8.3.11-remus and installed as follow
>>> >
>>> > cd /usr/src/
>>> > wget
>>> >
>>> http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz
>>> > tar xzf drbd-8.3.9-remus.tar.gz
>>> > chown -R root:root drbd-8.3-remus
>>> > cd /usr/src/drbd-8.3-remus
>>> > chmod 777 autogen.sh
>>> > ./autogen.sh
>>> > dpkg-buildpackage -b -uc
>>> > cd /usr/src/drbd-8.3-remus/drbd
>>> > make clean
>>> > make
>>> > make install
>>> > cd /usr/src/
>>> > cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD
>>> > /etc/drbd.d/global_common.conf
>>> > cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res
>>> > /etc/drbd.d/SystemHA_protoD.res
>>> >
>>> > sudo apt-get install drbd8-utils
>>> >
>>> >  from tutorial
>>> http://remusha.wikidot.com/configuring-and-installing-remus
>>> >
>>> > My *.res configuration as follow :
>>> >
>>> > resource drbd-vm{
>>> >   device    /dev/drbd1;
>>> >   disk      /dev/vgvoip/DomU;
>>> >   meta-disk internal;
>>> >   on machine1 {
>>> >     address   10.10.10.1:7789;
>>> >   }
>>> >   on machine2 {
>>> >     address   10.10.10.3:7789;
>>> >   }
>>> > }
>>> >
>>> > and then I invoke command to create that meta
>>> >
>>> > drbdadm create-md drbd-vm
>>> >
>>> > However, when I try to make this configuration up by :
>>> >
>>> > drbdadm up drbd-vm
>>> >
>>> > Its come with error :
>>> >
>>> > $ sudo drbdadm up drbd-vm
>>> > 1: Failure: (124) Device is attached to a disk (use detach first)
>>> > Command 'drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU internal
>>> > --set-defaults --create-device --fencing=dont-care
>>> --on-io-error=pass_on'
>>> > terminated with exit code 10
>>> >
>>> > If I run the
>>> >
>>> > $ sudo drbdadm detach drbd-vm
>>> >
>>> > Its come error
>>> >
>>> > $ sudo drbdadm detach drbd-vm
>>> > 1: State change failed: (-2) Need access to UpToDate data
>>> > Command 'drbdsetup 1 detach' terminated with exit code 17
>>> >
>>> > Here the /proc/drbd on both machine
>>> >
>>> > Machine 1
>>> >
>>> > $ sudo cat /proc/drbd
>>> > version: 8.3.11 (api:88/proto:86-96)
>>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>>> root@machine1,
>>> > 2013-02-18 18:49:57
>>> >
>>> >  1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----s
>>> >     ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b
>>> def:0
>>> > chkpt:0 oos:10485404
>>> >
>>> >
>>> > Machine 2
>>> >
>>> > $ sudo cat /proc/drbd
>>> > version: 8.3.11 (api:88/proto:86-96)
>>> > GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by
>>> root@machine2,
>>> > 2013-02-18 19:26:57
>>> >
>>> >  1: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown
>>> r----s
>>> >     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b def:0
>>> > chkpt:0 oos:10485404
>>> >
>>> >
>>> > Do you have some hints?
>>> >
>>> > Thank you,
>>> >
>>> >
>>> > Agya
>>> >
>>> >
>>> >> thanks
>>> >> shriram
>>> >>
>>> >> On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama <
>>> herydians@gmail.com>
>>> >> wrote:
>>> >> > Hello, Anyone have a clue? I have tried but still failed :(
>>> >> >
>>> >> > On Sat, Feb 16, 2013 at 6:56 PM, agya naila <agya.naila@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Dear all,
>>> >> >>
>>> >> >> I am configure my machine to run the remus disk replication. I am
>>> using
>>> >> >> xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit both for
>>> Dom0
>>> >> >> and
>>> >> >> DomU.
>>> >> >> I have install the blktap and its work properly with configuration
>>> >> >> string
>>> >> >> phy or tap2 like this :
>>> >> >> disk = ['phy:/dev/vggroup/DomU,xvda,w']
>>> >> >> or
>>> >> >> disk = ['tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w']
>>> >> >>
>>> >> >> and remus command
>>> >> >>
>>> >> >> remus --no-net myvm mybackuphost
>>> >> >>
>>> >> >>
>>> >> >> However when I change the string as suggested on remus pages to
>>> enable
>>> >> >> the
>>> >> >> disk replication its still failed :
>>> >> >>
>>> >> >> name = "DomU"
>>> >> >> memory = 1024
>>> >> >> disk = ['tap2:remus:10.10.10.3:8002|aio:/dev/vggroup/DomU,xvda,w']
>>> >> >> vif = ['ip=192.168.1.55,bridge=xenbr0']
>>> >> >> bootloader = "pygrub"
>>> >> >>
>>> >> >> with error messages :
>>> >> >>
>>> >> >> name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg
>>> >> >> Using config file "/etc/xen/DomU.cfg".
>>> >> >> Error: ('create', '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU')
>>> >> >> failed
>>> >> >> (512  )
>>> >> >>
>>> >> >> and on the log file :
>>> >> >>
>>> >> >>
>>> >> >> name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log
>>> >> >>     mounted_vbd_uuid = dom0.create_vbd(vbd, disk);
>>> >> >>   File
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py",
>>> >> >> line
>>> >> >> 3987, in create_vbd
>>> >> >>     devid = dev_control.createDevice(config)
>>> >> >>   File
>>> >> >>
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>>> >> >> line 174, in createDevice
>>> >> >>     device = TapdiskController.create(params, file)
>>> >> >>   File
>>> >> >>
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>>> >> >> line 286, in create
>>> >> >>     return TapdiskController.exc('create', '-a%s:%s' % (dtype,
>>> image))
>>> >> >>   File
>>> >> >>
>>> >> >>
>>> "/usr/local/lib/python2.7/dist-packages/xen/xend/server/BlktapController.py",
>>> >> >> line 233, in exc
>>> >> >>     (args, rc, out, err))
>>> >> >> TapdiskException: ('create',
>>> >> >> '-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU') failed (512  )
>>> >> >>
>>> >> >> Any hints and help would very appreciated.
>>> >> >>
>>> >> >> Regards,
>>> >> >>
>>> >> >> Agya
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Xen-devel mailing list
>>> >> >> Xen-devel@lists.xen.org
>>> >> >> http://lists.xen.org/xen-devel
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Xen-devel mailing list
>>> >> > Xen-devel@lists.xen.org
>>> >> > http://lists.xen.org/xen-devel
>>> >> >
>>> >
>>> >
>>>
>>
>>
>

--089e0122ef8806d75f04d60eecc2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Okay, I solve it. I removed drbd8-utils and re-install drbd from sources. D=
RBD connected with D protocol. I could go further with disk replication, ho=
pefully there is no mistaken step again :)<div><br></div><div>Regards,</div=
>
<div><br></div><div>Agya<br><br><div class=3D"gmail_quote">On Mon, Feb 18, =
2013 at 11:13 PM, agya naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.n=
aila@gmail.com" target=3D"_blank">agya.naila@gmail.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">I forgot to told that its =A0work with proto=
col C<div><br></div><div><div><font face=3D"courier new, monospace">=A0$ su=
do drbd-overview</font></div>
<div><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0SyncTarget Seco=
ndary/Secondary Inconsistent/UpToDate C r-----</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 [=3D&gt;........=
..........] sync&#39;ed: 12.0% (9016/10236)M</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">$ sudo drbd-overview</font></div>

<div><font face=3D"courier new, monospace">=A0 1:drbd-vm =A0Connected Secon=
dary/Secondary UpToDate/UpToDate C r-----</font></div><div><div class=3D"h5=
"><div><br></div><div><br></div><div class=3D"gmail_quote">On Mon, Feb 18, =
2013 at 11:00 PM, agya naila <span dir=3D"ltr">&lt;<a href=3D"mailto:agya.n=
aila@gmail.com" target=3D"_blank">agya.naila@gmail.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 Mon, Feb 18, 2013 at 10:33 PM, =
Shriram Rajagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc=
.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote:</div>

</div><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
=A0I suggest you read up on the DRBD setup documentation from the<br>
<a href=3D"http://drbd.org" target=3D"_blank">drbd.org</a> website.<br>
=A0The setup procedure is same. You can later flip to the remus<br>
replication protocol by simply<br>
=A0changing the protocol type (C to D).<br>
<br></blockquote></div>I am comparing my configuration with drbd website, h=
owever I got this error :<div><br></div><div><div><div><font face=3D"courie=
r new, monospace">$ sudo drbdadm up drbd-vm</font></div></div>
<div><font face=3D"courier new, monospace"><b>&#39;D&#39; is no valid proto=
col.</b></font></div>
<div><font face=3D"courier new, monospace"><b>Command &#39;drbdsetup 1 net =
ipv4:<a href=3D"http://10.10.10.1:7789" target=3D"_blank">10.10.10.1:7789</=
a> ipv4:<a href=3D"http://10.10.10.3:7789" target=3D"_blank">10.10.10.3:778=
9</a> D --set-defaults --create-device --rr-conflict=3Ddisconnect --after-s=
b-2pri=3Ddisconnect --after-sb-1pri=3Ddiscard-secondary --after-sb-0pri=3Dd=
iscard-younger-primary --allow-two-primaries --ko-count=3D4 --max-epoch-siz=
e=3D4096 --unplug-watermark=3D4096 --max-buffers=3D8192 --ping-timeout=3D20=
 --ping-int=3D3 --timeout=3D30&#39; terminated with exit code 20</b></font>=
</div>


<div><font face=3D"courier new, monospace"><b>drbdadm connect drbd-vm: exit=
ed with code 20</b></font></div><div><font face=3D"courier new, monospace">=
<b><br></b></font></div><div><font face=3D"courier new, monospace">$ sudo d=
rbd-overview</font></div>


</div><div><span style=3D"font-family:&#39;courier new&#39;,monospace">=A0 =
1:drbd-vm =A0StandAlone Secondary/Unknown UpToDate/DUnknown r----s</span></=
div><div><div><div><br></div><div>Thank you,</div><div><br></div>
<div>Agya</div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks<br>
<span><font color=3D"#888888">shriram<br>
</font></span><div><div><br>
On Mon, Feb 18, 2013 at 4:11 PM, agya naila &lt;<a href=3D"mailto:agya.nail=
a@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Feb 18, 2013 at 9:08 PM, Shriram Rajagopalan &lt;<a href=3D"ma=
ilto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; hi<br>
&gt;<br>
&gt;<br>
&gt; Thank you shriram.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0sorry for the delayed response. IIRC the blktap2 driver require=
d for<br>
&gt;&gt; tapdisk replication doesnt exist in the mainstream dom0 kernels, I=
IRC.<br>
&gt;&gt; =A0I havent used it in a long time myself. I suggest trying disk<b=
r>
&gt;&gt; replication with DRBD.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I am also found some information here<br>
&gt; <a href=3D"http://osdir.com/ml/xen-users/2011-07/msg00653.html" target=
=3D"_blank">http://osdir.com/ml/xen-users/2011-07/msg00653.html</a> about b=
lktap2 problem on<br>
&gt; amd64 architecture. I have tried to install and configure the DRBD but=
 its<br>
&gt; didn&#39;t connect each other.<br>
&gt; I used drbd-8.3.11-remus and installed as follow<br>
&gt;<br>
&gt; cd /usr/src/<br>
&gt; wget<br>
&gt; <a href=3D"http://remusha.wikidot.com/local--files/configuring-and-ins=
talling-remus/drbd-8.3.11-remus.tar.gz" target=3D"_blank">http://remusha.wi=
kidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.t=
ar.gz</a><br>



&gt; tar xzf drbd-8.3.9-remus.tar.gz<br>
&gt; chown -R root:root drbd-8.3-remus<br>
&gt; cd /usr/src/drbd-8.3-remus<br>
&gt; chmod 777 autogen.sh<br>
&gt; ./autogen.sh<br>
&gt; dpkg-buildpackage -b -uc<br>
&gt; cd /usr/src/drbd-8.3-remus/drbd<br>
&gt; make clean<br>
&gt; make<br>
&gt; make install<br>
&gt; cd /usr/src/<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/global_common.conf.protoD<br>
&gt; /etc/drbd.d/global_common.conf<br>
&gt; cp /usr/src/drbd-8.3-remus/scripts/testvms_protoD.res<br>
&gt; /etc/drbd.d/SystemHA_protoD.res<br>
&gt;<br>
&gt; sudo apt-get install drbd8-utils<br>
&gt;<br>
&gt; =A0from tutorial <a href=3D"http://remusha.wikidot.com/configuring-and=
-installing-remus" target=3D"_blank">http://remusha.wikidot.com/configuring=
-and-installing-remus</a><br>
&gt;<br>
&gt; My *.res configuration as follow :<br>
&gt;<br>
&gt; resource drbd-vm{<br>
&gt; =A0 device =A0 =A0/dev/drbd1;<br>
&gt; =A0 disk =A0 =A0 =A0/dev/vgvoip/DomU;<br>
&gt; =A0 meta-disk internal;<br>
&gt; =A0 on machine1 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.1:7789" target=3D"_blan=
k">10.10.10.1:7789</a>;<br>
&gt; =A0 }<br>
&gt; =A0 on machine2 {<br>
&gt; =A0 =A0 address =A0 <a href=3D"http://10.10.10.3:7789" target=3D"_blan=
k">10.10.10.3:7789</a>;<br>
&gt; =A0 }<br>
&gt; }<br>
&gt;<br>
&gt; and then I invoke command to create that meta<br>
&gt;<br>
&gt; drbdadm create-md drbd-vm<br>
&gt;<br>
&gt; However, when I try to make this configuration up by :<br>
&gt;<br>
&gt; drbdadm up drbd-vm<br>
&gt;<br>
&gt; Its come with error :<br>
&gt;<br>
&gt; $ sudo drbdadm up drbd-vm<br>
&gt; 1: Failure: (124) Device is attached to a disk (use detach first)<br>
&gt; Command &#39;drbdsetup 1 disk /dev/vgvoip/DomU /dev/vgvoip/DomU intern=
al<br>
&gt; --set-defaults --create-device --fencing=3Ddont-care --on-io-error=3Dp=
ass_on&#39;<br>
&gt; terminated with exit code 10<br>
&gt;<br>
&gt; If I run the<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt;<br>
&gt; Its come error<br>
&gt;<br>
&gt; $ sudo drbdadm detach drbd-vm<br>
&gt; 1: State change failed: (-2) Need access to UpToDate data<br>
&gt; Command &#39;drbdsetup 1 detach&#39; terminated with exit code 17<br>
&gt;<br>
&gt; Here the /proc/drbd on both machine<br>
&gt;<br>
&gt; Machine 1<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne1,<br>
&gt; 2013-02-18 18:49:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown =A0 r----s=
<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:1712 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b=
 def:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Machine 2<br>
&gt;<br>
&gt; $ sudo cat /proc/drbd<br>
&gt; version: 8.3.11 (api:88/proto:86-96)<br>
&gt; GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@machi=
ne2,<br>
&gt; 2013-02-18 19:26:57<br>
&gt;<br>
&gt; =A01: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown =A0 =
r----s<br>
&gt; =A0 =A0 ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b de=
f:0<br>
&gt; chkpt:0 oos:10485404<br>
&gt;<br>
&gt;<br>
&gt; Do you have some hints?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt;<br>
&gt; Agya<br>
&gt;<br>
&gt;<br>
&gt;&gt; thanks<br>
&gt;&gt; shriram<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Feb 18, 2013 at 5:38 AM, Hery Dian Septama &lt;<a href=3D"=
mailto:herydians@gmail.com" target=3D"_blank">herydians@gmail.com</a>&gt;<b=
r>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hello, Anyone have a clue? I have tried but still failed :(<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Feb 16, 2013 at 6:56 PM, agya naila &lt;<a href=3D"ma=
ilto:agya.naila@gmail.com" target=3D"_blank">agya.naila@gmail.com</a>&gt;<b=
r>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Dear all,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I am configure my machine to run the remus disk replicati=
on. I am using<br>
&gt;&gt; &gt;&gt; xen 4.2.3 installed from sources and Ubuntu 12.04 64 bit =
both for Dom0<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; DomU.<br>
&gt;&gt; &gt;&gt; I have install the blktap and its work properly with conf=
iguration<br>
&gt;&gt; &gt;&gt; string<br>
&gt;&gt; &gt;&gt; phy or tap2 like this :<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;phy:/dev/vggroup/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; or<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:tapdisk:aio:/dev/vggroup/DomU,xvda,w&=
#39;]<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and remus command<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; remus --no-net myvm mybackuphost<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; However when I change the string as suggested on remus pa=
ges to enable<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; disk replication its still failed :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name =3D &quot;DomU&quot;<br>
&gt;&gt; &gt;&gt; memory =3D 1024<br>
&gt;&gt; &gt;&gt; disk =3D [&#39;tap2:remus:10.10.10.3:8002|aio:/dev/vggrou=
p/DomU,xvda,w&#39;]<br>
&gt;&gt; &gt;&gt; vif =3D [&#39;ip=3D192.168.1.55,bridge=3Dxenbr0&#39;]<br>
&gt;&gt; &gt;&gt; bootloader =3D &quot;pygrub&quot;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; with error messages :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo xm create -c /etc/xen/DomU.cfg<br>
&gt;&gt; &gt;&gt; Using config file &quot;/etc/xen/DomU.cfg&quot;.<br>
&gt;&gt; &gt;&gt; Error: (&#39;create&#39;, &#39;-aremus:10.10.10.3:8002|ai=
o:/dev/vggroup/DomU&#39;)<br>
&gt;&gt; &gt;&gt; failed<br>
&gt;&gt; &gt;&gt; (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; and on the log file :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; name1@machine1:~$ sudo sudo tail /var/log/xen/xend.log<br=
>
&gt;&gt; &gt;&gt; =A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);<=
br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/Xen=
dDomainInfo.py&quot;,<br>
&gt;&gt; &gt;&gt; line<br>
&gt;&gt; &gt;&gt; 3987, in create_vbd<br>
&gt;&gt; &gt;&gt; =A0 =A0 devid =3D dev_control.createDevice(config)<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 174, in createDevice<br>
&gt;&gt; &gt;&gt; =A0 =A0 device =3D TapdiskController.create(params, file)=
<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 286, in create<br>
&gt;&gt; &gt;&gt; =A0 =A0 return TapdiskController.exc(&#39;create&#39;, &#=
39;-a%s:%s&#39; % (dtype, image))<br>
&gt;&gt; &gt;&gt; =A0 File<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &quot;/usr/local/lib/python2.7/dist-packages/xen/xend/ser=
ver/BlktapController.py&quot;,<br>
&gt;&gt; &gt;&gt; line 233, in exc<br>
&gt;&gt; &gt;&gt; =A0 =A0 (args, rc, out, err))<br>
&gt;&gt; &gt;&gt; TapdiskException: (&#39;create&#39;,<br>
&gt;&gt; &gt;&gt; &#39;-aremus:10.10.10.3:8002|aio:/dev/vggroup/DomU&#39;) =
failed (512 =A0)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Any hints and help would very appreciated.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Agya<br>
&gt;&gt; &gt;&gt;<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" target=3D"_bla=
nk">Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_bla=
nk">http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Xen-devel mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">=
Xen-devel@lists.xen.org</a><br>
&gt;&gt; &gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">=
http://lists.xen.org/xen-devel</a><br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>

--089e0122ef8806d75f04d60eecc2--


--===============3277700120673485894==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3277700120673485894==--


From xen-devel-bounces@lists.xen.org Tue Feb 19 08:04:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08: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 1U7iBH-0004HC-Qg; Tue, 19 Feb 2013 08:04:03 +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 1U7iBG-0004H7-Qy
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 08:04:02 +0000
Received: from [193.109.254.147:13907] by server-7.bemta-14.messagelabs.com id
	B2/0B-13581-2F133215; Tue, 19 Feb 2013 08:04:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361261041!2062370!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23252 invoked from network); 19 Feb 2013 08:04:01 -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; 19 Feb 2013 08:04:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 08:04:00 +0000
Message-Id: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 08:03:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Miller" <davem@davemloft.net>,<drjones@redhat.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
In-Reply-To: <20130219.005356.2288460992654639558.davem@davemloft.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> From: Andrew Jones <drjones@redhat.com>
> Date: Mon, 18 Feb 2013 21:29:20 +0100
> 
>> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> have one reference to the vif at this time, then the xenvif_put
>> in netbk_fatal_tx_err is one too many.
>> 
>> Signed-off-by: Andrew Jones <drjones@redhat.com>
> 
> Applied.

But this is wrong from all we can tell, we discussed this before
(Wei pointed to the discussion in an earlier reply). The core of
it is that the put here parallels the one in netbk_tx_err(), and
the one in xenvif_carrier_off() matches the get from
xenvif_connect() (which normally would be done on the path
coming through xenvif_disconnect()).

And anyway - shouldn't changes to netback require an ack from
Ian?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:04:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08: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 1U7iBH-0004HC-Qg; Tue, 19 Feb 2013 08:04:03 +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 1U7iBG-0004H7-Qy
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 08:04:02 +0000
Received: from [193.109.254.147:13907] by server-7.bemta-14.messagelabs.com id
	B2/0B-13581-2F133215; Tue, 19 Feb 2013 08:04:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361261041!2062370!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23252 invoked from network); 19 Feb 2013 08:04:01 -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; 19 Feb 2013 08:04:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 08:04:00 +0000
Message-Id: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 08:03:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Miller" <davem@davemloft.net>,<drjones@redhat.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
In-Reply-To: <20130219.005356.2288460992654639558.davem@davemloft.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> From: Andrew Jones <drjones@redhat.com>
> Date: Mon, 18 Feb 2013 21:29:20 +0100
> 
>> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> have one reference to the vif at this time, then the xenvif_put
>> in netbk_fatal_tx_err is one too many.
>> 
>> Signed-off-by: Andrew Jones <drjones@redhat.com>
> 
> Applied.

But this is wrong from all we can tell, we discussed this before
(Wei pointed to the discussion in an earlier reply). The core of
it is that the put here parallels the one in netbk_tx_err(), and
the one in xenvif_carrier_off() matches the get from
xenvif_connect() (which normally would be done on the path
coming through xenvif_disconnect()).

And anyway - shouldn't changes to netback require an ack from
Ian?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:11:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08: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 1U7iIT-0004Rn-OH; Tue, 19 Feb 2013 08:11: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 1U7iIR-0004Ri-FW
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 08:11:27 +0000
Received: from [85.158.143.35:61611] by server-1.bemta-4.messagelabs.com id
	80/33-08839-EA333215; Tue, 19 Feb 2013 08:11:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361261466!11748637!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14770 invoked from network); 19 Feb 2013 08:11:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 08:11:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 08:11:05 +0000
Message-Id: <512341A702000078000BF4BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 08:11:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
In-Reply-To: <1361207601.31175.6.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Matt Wilson <msw@amazon.com>, Daniel DeGraaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:13, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>  * [ 2/11] xen, libxc: introduce node maps and masks
>>
> Jan, are you ok with the changes I made, as a consequence of your
> comments to v2 ?

Yes, I am. But I won't ack a mixed tools/hypervisor patch. And
the hypervisor part that's left is so obvious that I don't see it
needing an ack on its own.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:11:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08: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 1U7iIT-0004Rn-OH; Tue, 19 Feb 2013 08:11: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 1U7iIR-0004Ri-FW
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 08:11:27 +0000
Received: from [85.158.143.35:61611] by server-1.bemta-4.messagelabs.com id
	80/33-08839-EA333215; Tue, 19 Feb 2013 08:11:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1361261466!11748637!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14770 invoked from network); 19 Feb 2013 08:11:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 08:11:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 08:11:05 +0000
Message-Id: <512341A702000078000BF4BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 08:11:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
In-Reply-To: <1361207601.31175.6.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org,
	Matt Wilson <msw@amazon.com>, Daniel DeGraaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:13, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>  * [ 2/11] xen, libxc: introduce node maps and masks
>>
> Jan, are you ok with the changes I made, as a consequence of your
> comments to v2 ?

Yes, I am. But I won't ack a mixed tools/hypervisor patch. And
the hypervisor part that's left is so obvious that I don't see it
needing an ack on its own.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:52:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08:52: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 1U7ivd-0004to-VQ; Tue, 19 Feb 2013 08:51:57 +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 1U7ivc-0004ti-4l
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 08:51:56 +0000
Received: from [85.158.137.99:51991] by server-6.bemta-3.messagelabs.com id
	5D/F2-29959-B2D33215; Tue, 19 Feb 2013 08:51:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361263913!16856980!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8150 invoked from network); 19 Feb 2013 08:51:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 08:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="1593210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 08:51: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.297.1;
	Tue, 19 Feb 2013 08:51:53 +0000
Message-ID: <1361263912.1051.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 19 Feb 2013 08:51:52 +0000
In-Reply-To: <512341A702000078000BF4BF@nat28.tlf.novell.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
	<512341A702000078000BF4BF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Matt Wilson <msw@amazon.com>, Daniel DeGraaf <dgdegra@tycho.nsa.gov>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 08:11 +0000, Jan Beulich wrote:
> >>> On 18.02.13 at 18:13, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> >>  * [ 2/11] xen, libxc: introduce node maps and masks
> >>
> > Jan, are you ok with the changes I made, as a consequence of your
> > comments to v2 ?
> 
> Yes, I am. But I won't ack a mixed tools/hypervisor patch. And
> the hypervisor part that's left is so obvious that I don't see it
> needing an ack on its own.

I don't see any problem with acking a patch which is obvious, in general
I think it is better to be explicit, especially where multiple
maintainers involved, lest we all be waiting for each other.

You could say "I would ack this, but it is obvious" but it seems to me
it would be quicker to just say "ack" ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:52:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08:52: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 1U7ivd-0004to-VQ; Tue, 19 Feb 2013 08:51:57 +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 1U7ivc-0004ti-4l
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 08:51:56 +0000
Received: from [85.158.137.99:51991] by server-6.bemta-3.messagelabs.com id
	5D/F2-29959-B2D33215; Tue, 19 Feb 2013 08:51:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361263913!16856980!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8150 invoked from network); 19 Feb 2013 08:51:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 08:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="1593210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 08:51: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.297.1;
	Tue, 19 Feb 2013 08:51:53 +0000
Message-ID: <1361263912.1051.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 19 Feb 2013 08:51:52 +0000
In-Reply-To: <512341A702000078000BF4BF@nat28.tlf.novell.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
	<512341A702000078000BF4BF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Matt Wilson <msw@amazon.com>, Daniel DeGraaf <dgdegra@tycho.nsa.gov>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 08:11 +0000, Jan Beulich wrote:
> >>> On 18.02.13 at 18:13, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> >>  * [ 2/11] xen, libxc: introduce node maps and masks
> >>
> > Jan, are you ok with the changes I made, as a consequence of your
> > comments to v2 ?
> 
> Yes, I am. But I won't ack a mixed tools/hypervisor patch. And
> the hypervisor part that's left is so obvious that I don't see it
> needing an ack on its own.

I don't see any problem with acking a patch which is obvious, in general
I think it is better to be explicit, especially where multiple
maintainers involved, lest we all be waiting for each other.

You could say "I would ack this, but it is obvious" but it seems to me
it would be quicker to just say "ack" ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:57:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08:57: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 1U7j0i-00055l-Nj; Tue, 19 Feb 2013 08:57:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7j0h-00055c-Nd
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 08:57:11 +0000
Received: from [85.158.139.211:59976] by server-16.bemta-5.messagelabs.com id
	A2/42-14948-76E33215; Tue, 19 Feb 2013 08:57:11 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361264227!18148297!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14579 invoked from network); 19 Feb 2013 08:57:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 08:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="7712627"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 08:57:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 03:57:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7j0Y-0003Jv-Nx;
	Tue, 19 Feb 2013 08:57:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 19 Feb 2013 08:54:34 +0000
Message-ID: <1361264074-5606-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] genid: Introduce again Windows generation
	ID 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

This device was removed due to change in specifications.
Original patch written by Paul Durrant

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/tools/firmware/hvmloader/acpi/dsdt.asl
index 64896ce..247a8ad 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -397,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
                         IRQNoFlags () {7}
                     })
                 }
+
+                Device(VGID) {
+                    Name(_HID, EisaId ("XEN0000"))
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }
-- 
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 Tue Feb 19 08:57:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08:57: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 1U7j0i-00055l-Nj; Tue, 19 Feb 2013 08:57:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7j0h-00055c-Nd
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 08:57:11 +0000
Received: from [85.158.139.211:59976] by server-16.bemta-5.messagelabs.com id
	A2/42-14948-76E33215; Tue, 19 Feb 2013 08:57:11 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361264227!18148297!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14579 invoked from network); 19 Feb 2013 08:57:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 08:57:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="7712627"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 08:57:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 03:57:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7j0Y-0003Jv-Nx;
	Tue, 19 Feb 2013 08:57:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 19 Feb 2013 08:54:34 +0000
Message-ID: <1361264074-5606-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/2] genid: Introduce again Windows generation
	ID 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

This device was removed due to change in specifications.
Original patch written by Paul Durrant

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/tools/firmware/hvmloader/acpi/dsdt.asl
index 64896ce..247a8ad 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -397,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
                         IRQNoFlags () {7}
                     })
                 }
+
+                Device(VGID) {
+                    Name(_HID, EisaId ("XEN0000"))
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }
-- 
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 Tue Feb 19 08:58:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08:58: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 1U7j1q-0005Ab-7Y; Tue, 19 Feb 2013 08:58:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1U7j1o-0005AL-G2
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 08:58:20 +0000
Received: from [85.158.139.211:10293] by server-1.bemta-5.messagelabs.com id
	4D/9D-29263-BAE33215; Tue, 19 Feb 2013 08:58:19 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361264291!17727588!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30301 invoked from network); 19 Feb 2013 08:58:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 08:58:12 -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 r1J8w8c3022415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 03:58:08 -0500
Received: from hawk.usersys.redhat.com (dhcp-1-196.brq.redhat.com
	[10.34.1.196])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1J8w5Ol023796; Tue, 19 Feb 2013 03:58:06 -0500
Date: Tue, 19 Feb 2013 09:58:03 +0100
From: Andrew Jones <drjones@redhat.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20130219095803.17b28ec3@hawk.usersys.redhat.com>
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com, liuw@liuw.name,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013 08:03:49 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Jones <drjones@redhat.com>
> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> > 
> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> have one reference to the vif at this time, then the xenvif_put
> >> in netbk_fatal_tx_err is one too many.
> >> 
> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> > 
> > Applied.
> 
> But this is wrong from all we can tell, we discussed this before
> (Wei pointed to the discussion in an earlier reply). The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).

I see the balance described by Ian in [1] now. Sorry that I missed
that previous discussion and generated this noise.

[1] http://marc.info/?l=xen-devel&m=136084174026977&w=2

drew

> 
> And anyway - shouldn't changes to netback require an ack from
> Ian?
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 08:58:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 08:58: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 1U7j1q-0005Ab-7Y; Tue, 19 Feb 2013 08:58:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1U7j1o-0005AL-G2
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 08:58:20 +0000
Received: from [85.158.139.211:10293] by server-1.bemta-5.messagelabs.com id
	4D/9D-29263-BAE33215; Tue, 19 Feb 2013 08:58:19 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361264291!17727588!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30301 invoked from network); 19 Feb 2013 08:58:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 08:58:12 -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 r1J8w8c3022415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 03:58:08 -0500
Received: from hawk.usersys.redhat.com (dhcp-1-196.brq.redhat.com
	[10.34.1.196])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1J8w5Ol023796; Tue, 19 Feb 2013 03:58:06 -0500
Date: Tue, 19 Feb 2013 09:58:03 +0100
From: Andrew Jones <drjones@redhat.com>
To: "Jan Beulich" <JBeulich@suse.com>
Message-ID: <20130219095803.17b28ec3@hawk.usersys.redhat.com>
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com, liuw@liuw.name,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013 08:03:49 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Jones <drjones@redhat.com>
> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> > 
> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> have one reference to the vif at this time, then the xenvif_put
> >> in netbk_fatal_tx_err is one too many.
> >> 
> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> > 
> > Applied.
> 
> But this is wrong from all we can tell, we discussed this before
> (Wei pointed to the discussion in an earlier reply). The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).

I see the balance described by Ian in [1] now. Sorry that I missed
that previous discussion and generated this noise.

[1] http://marc.info/?l=xen-devel&m=136084174026977&w=2

drew

> 
> And anyway - shouldn't changes to netback require an ack from
> Ian?
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:00:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09:00: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 1U7j3W-0005Ll-Sa; Tue, 19 Feb 2013 09:00: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 1U7j3U-0005LU-Ni
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 09:00:04 +0000
Received: from [85.158.143.99:21306] by server-2.bemta-4.messagelabs.com id
	7C/E8-12656-41F33215; Tue, 19 Feb 2013 09:00:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361264403!28085278!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6690 invoked from network); 19 Feb 2013 09:00:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 09:00:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="1593463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 08:58: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.297.1;
	Tue, 19 Feb 2013 08:58:45 +0000
Message-ID: <1361264324.1051.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 19 Feb 2013 08:58:44 +0000
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Jones <drjones@redhat.com>
> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> > 
> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> have one reference to the vif at this time, then the xenvif_put
> >> in netbk_fatal_tx_err is one too many.
> >> 
> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> > 
> > Applied.
> 
> But this is wrong from all we can tell,

Yes, please can this be reverted.

>  we discussed this before
> (Wei pointed to the discussion in an earlier reply). The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).

Perhaps Andrew was looking at the tree before "xen-netback: correctly
return errors from netbk_count_requests()" which fixed a different case
of a double put which may have appeared to be fixed by this change too.

Ian.

> And anyway - shouldn't changes to netback require an ack from
> Ian?
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:00:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09:00: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 1U7j3W-0005Ll-Sa; Tue, 19 Feb 2013 09:00: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 1U7j3U-0005LU-Ni
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 09:00:04 +0000
Received: from [85.158.143.99:21306] by server-2.bemta-4.messagelabs.com id
	7C/E8-12656-41F33215; Tue, 19 Feb 2013 09:00:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361264403!28085278!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6690 invoked from network); 19 Feb 2013 09:00:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 09:00:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="1593463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 08:58: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.297.1;
	Tue, 19 Feb 2013 08:58:45 +0000
Message-ID: <1361264324.1051.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 19 Feb 2013 08:58:44 +0000
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> > From: Andrew Jones <drjones@redhat.com>
> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> > 
> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> have one reference to the vif at this time, then the xenvif_put
> >> in netbk_fatal_tx_err is one too many.
> >> 
> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> > 
> > Applied.
> 
> But this is wrong from all we can tell,

Yes, please can this be reverted.

>  we discussed this before
> (Wei pointed to the discussion in an earlier reply). The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).

Perhaps Andrew was looking at the tree before "xen-netback: correctly
return errors from netbk_count_requests()" which fixed a different case
of a double put which may have appeared to be fixed by this change too.

Ian.

> And anyway - shouldn't changes to netback require an ack from
> Ian?
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:03:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09: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 1U7j69-0005ZD-HM; Tue, 19 Feb 2013 09:02: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 1U7j68-0005Z3-C9
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 09:02:48 +0000
Received: from [85.158.137.99:42465] by server-13.bemta-3.messagelabs.com id
	BF/83-20653-7BF33215; Tue, 19 Feb 2013 09:02:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361264539!16973107!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11155 invoked from network); 19 Feb 2013 09:02:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 09:02:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="1593679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 09:02: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.297.1;
	Tue, 19 Feb 2013 09:02:18 +0000
Message-ID: <1361264537.1051.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 09:02:17 +0000
In-Reply-To: <osstest-16207-mainreport@xen.org>
References: <osstest-16207-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [xen-unstable test] 16207: 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 Tue, 2013-02-19 at 05:42 +0000, xen.org wrote:
> flight 16207 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16207/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 16171

This looks distressingly similar to the failure in 15401 which we
overrode with a manual push on the basis that 15179 was a fluke pass.
Although I suppose one Windows install regression looks much like any
other...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:03:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09: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 1U7j69-0005ZD-HM; Tue, 19 Feb 2013 09:02: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 1U7j68-0005Z3-C9
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 09:02:48 +0000
Received: from [85.158.137.99:42465] by server-13.bemta-3.messagelabs.com id
	BF/83-20653-7BF33215; Tue, 19 Feb 2013 09:02:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361264539!16973107!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMzg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11155 invoked from network); 19 Feb 2013 09:02:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 09:02:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="1593679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 09:02: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.297.1;
	Tue, 19 Feb 2013 09:02:18 +0000
Message-ID: <1361264537.1051.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 09:02:17 +0000
In-Reply-To: <osstest-16207-mainreport@xen.org>
References: <osstest-16207-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [xen-unstable test] 16207: 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 Tue, 2013-02-19 at 05:42 +0000, xen.org wrote:
> flight 16207 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16207/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 16171

This looks distressingly similar to the failure in 15401 which we
overrode with a manual push on the basis that 15179 was a fluke pass.
Although I suppose one Windows install regression looks much like any
other...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:04:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09: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 1U7j7G-0005fv-07; Tue, 19 Feb 2013 09:03:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7j7F-0005fh-25
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:03:57 +0000
Received: from [193.109.254.147:60859] by server-11.bemta-14.messagelabs.com
	id 98/CC-30685-CFF33215; Tue, 19 Feb 2013 09:03:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361264223!8857884!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20154 invoked from network); 19 Feb 2013 08:57:05 -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;
	19 Feb 2013 08:57:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="7712625"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 08:57:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 03:57:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7j0Y-0003Jv-Kl;
	Tue, 19 Feb 2013 08:57:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 19 Feb 2013 08:54:32 +0000
Message-ID: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/2] genid: ACPI Windows generation ID updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 patch update Windows generation ID support on ACPI.

First patch mainly update to new specifications while second one
introduce again the device in ACPI table.

Frediano Ziglio (2):
  genid: Update Windows generation ID
  genid: Introduce again Windows generation ID device

 docs/misc/xenstore-paths.markdown      |    6 ++++
 tools/firmware/hvmloader/acpi/build.c  |   49 ++++++++++++++++++++++----------
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 ++++++++++++++++
 3 files changed, 65 insertions(+), 15 deletions(-)

-- 
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 Tue Feb 19 09:04:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09: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 1U7j7G-0005fv-07; Tue, 19 Feb 2013 09:03:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7j7F-0005fh-25
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:03:57 +0000
Received: from [193.109.254.147:60859] by server-11.bemta-14.messagelabs.com
	id 98/CC-30685-CFF33215; Tue, 19 Feb 2013 09:03:56 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361264223!8857884!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20154 invoked from network); 19 Feb 2013 08:57:05 -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;
	19 Feb 2013 08:57:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="7712625"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 08:57:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 03:57:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7j0Y-0003Jv-Kl;
	Tue, 19 Feb 2013 08:57:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 19 Feb 2013 08:54:32 +0000
Message-ID: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0/2] genid: ACPI Windows generation ID updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 patch update Windows generation ID support on ACPI.

First patch mainly update to new specifications while second one
introduce again the device in ACPI table.

Frediano Ziglio (2):
  genid: Update Windows generation ID
  genid: Introduce again Windows generation ID device

 docs/misc/xenstore-paths.markdown      |    6 ++++
 tools/firmware/hvmloader/acpi/build.c  |   49 ++++++++++++++++++++++----------
 tools/firmware/hvmloader/acpi/dsdt.asl |   25 ++++++++++++++++
 3 files changed, 65 insertions(+), 15 deletions(-)

-- 
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 Tue Feb 19 09:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09:04: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 1U7j7x-0005lN-Ec; Tue, 19 Feb 2013 09:04:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7j7v-0005lA-Lw
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:04:39 +0000
Received: from [193.109.254.147:48790] by server-9.bemta-14.messagelabs.com id
	CE/DA-30867-62043215; Tue, 19 Feb 2013 09:04:38 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361264223!8857884!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20226 invoked from network); 19 Feb 2013 08:57:07 -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;
	19 Feb 2013 08:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="7712626"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 08:57:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 03:57:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7j0Y-0003Jv-MW;
	Tue, 19 Feb 2013 08:57:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 19 Feb 2013 08:54:33 +0000
Message-ID: <1361264074-5606-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] genid: Update Windows generation 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

First draft specification document it as a 64bit counter, now are a 128bit
value handled as a couple of 64bit values.

Allow to disable the device is values are all zeroes.

Add documentation for platform/generation-id key.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 docs/misc/xenstore-paths.markdown     |    6 ++++
 tools/firmware/hvmloader/acpi/build.c |   49 +++++++++++++++++++++++----------
 2 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index 09e551b..535830e 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -164,6 +164,12 @@ Various platform properties.
 * acpi_s3 -- is ACPI S3 support enabled for this domain
 * acpi_s4 -- is ACPI S4 support enabled for this domain
 
+#### ~/platform/generation-id = INTEGER ":" INTEGER [HVM,INTERNAL]
+
+Two 64 bit values that represent the Windows Generation ID.
+Is used by the BIOS initializer to get this value.
+If not present or "0:0" (all zeroes) device will not be present to the machine.
+
 ### Frontend device paths
 
 Paravirtual device frontends are generally specified by their own
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 9026e09..ad9fbb7 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -349,24 +349,45 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     return nr_tables;
 }
 
-unsigned long new_vm_gid(void)
+/**
+ * Allocate and initialize Windows Generation ID
+ * If value is not present in the XenStore or if all zeroes
+ * the device will be not active
+ *
+ * Return 0 if memory failure, != 0 if success
+ */
+static int new_vm_gid(struct acpi_info *acpi_info)
 {
-    uint64_t gid;
-    unsigned char *buf;
-    char addr[11];
-
-    buf = mem_alloc(8, 8);
-    if (!buf) return 0;
+    uint64_t vm_gid[2], *buf;
+    char addr[12];
+    const char * s;
+    char *end;
+
+    acpi_info->vm_gid_addr = 0;
+
+    /* read ID and check for 0 */
+    s = xenstore_read("platform/generation-id", "0:0");
+    vm_gid[0] = strtoll(s, &end, 0);
+    vm_gid[1] = 0;
+    if ( end && end[0] == ':' )
+        vm_gid[1] = strtoll(end+1, NULL, 0);
+    if ( !vm_gid[0] && !vm_gid[1] )
+        return 1;
+
+    /* copy to allocate BIOS memory */
+    buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+    if ( !buf )
+        return 0;
+    memcpy(buf, vm_gid, sizeof(vm_gid));
 
+    /* set into ACPI table and XenStore the address */
+    acpi_info->vm_gid_addr = virt_to_phys(buf);
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
     xenstore_write("hvmloader/generation-id-address", addr);
 
-    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
-    *(uint64_t *)buf = gid;
-
-    return virt_to_phys(buf);    
+    return 1;
 }
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
@@ -381,7 +402,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     unsigned char       *dsdt;
     unsigned long        secondary_tables[ACPI_MAX_SECONDARY_TABLES];
     int                  nr_secondaries, i;
-    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -494,8 +514,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
-    vm_gid_addr = new_vm_gid();
-    if (!vm_gid_addr) goto oom;
+    if ( !new_vm_gid(acpi_info) )
+        goto oom;
 
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
@@ -503,7 +523,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
-    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
-- 
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 Tue Feb 19 09:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09:04: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 1U7j7x-0005lN-Ec; Tue, 19 Feb 2013 09:04:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7j7v-0005lA-Lw
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:04:39 +0000
Received: from [193.109.254.147:48790] by server-9.bemta-14.messagelabs.com id
	CE/DA-30867-62043215; Tue, 19 Feb 2013 09:04:38 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361264223!8857884!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMxMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20226 invoked from network); 19 Feb 2013 08:57:07 -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;
	19 Feb 2013 08:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,693,1355097600"; 
   d="scan'208";a="7712626"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 08:57:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 03:57:02 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U7j0Y-0003Jv-MW;
	Tue, 19 Feb 2013 08:57:02 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 19 Feb 2013 08:54:33 +0000
Message-ID: <1361264074-5606-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361264074-5606-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/2] genid: Update Windows generation 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

First draft specification document it as a 64bit counter, now are a 128bit
value handled as a couple of 64bit values.

Allow to disable the device is values are all zeroes.

Add documentation for platform/generation-id key.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 docs/misc/xenstore-paths.markdown     |    6 ++++
 tools/firmware/hvmloader/acpi/build.c |   49 +++++++++++++++++++++++----------
 2 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index 09e551b..535830e 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -164,6 +164,12 @@ Various platform properties.
 * acpi_s3 -- is ACPI S3 support enabled for this domain
 * acpi_s4 -- is ACPI S4 support enabled for this domain
 
+#### ~/platform/generation-id = INTEGER ":" INTEGER [HVM,INTERNAL]
+
+Two 64 bit values that represent the Windows Generation ID.
+Is used by the BIOS initializer to get this value.
+If not present or "0:0" (all zeroes) device will not be present to the machine.
+
 ### Frontend device paths
 
 Paravirtual device frontends are generally specified by their own
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 9026e09..ad9fbb7 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -349,24 +349,45 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     return nr_tables;
 }
 
-unsigned long new_vm_gid(void)
+/**
+ * Allocate and initialize Windows Generation ID
+ * If value is not present in the XenStore or if all zeroes
+ * the device will be not active
+ *
+ * Return 0 if memory failure, != 0 if success
+ */
+static int new_vm_gid(struct acpi_info *acpi_info)
 {
-    uint64_t gid;
-    unsigned char *buf;
-    char addr[11];
-
-    buf = mem_alloc(8, 8);
-    if (!buf) return 0;
+    uint64_t vm_gid[2], *buf;
+    char addr[12];
+    const char * s;
+    char *end;
+
+    acpi_info->vm_gid_addr = 0;
+
+    /* read ID and check for 0 */
+    s = xenstore_read("platform/generation-id", "0:0");
+    vm_gid[0] = strtoll(s, &end, 0);
+    vm_gid[1] = 0;
+    if ( end && end[0] == ':' )
+        vm_gid[1] = strtoll(end+1, NULL, 0);
+    if ( !vm_gid[0] && !vm_gid[1] )
+        return 1;
+
+    /* copy to allocate BIOS memory */
+    buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+    if ( !buf )
+        return 0;
+    memcpy(buf, vm_gid, sizeof(vm_gid));
 
+    /* set into ACPI table and XenStore the address */
+    acpi_info->vm_gid_addr = virt_to_phys(buf);
     if ( snprintf(addr, sizeof(addr), "0x%lx", virt_to_phys(buf))
          >= sizeof(addr) )
         return 0;
     xenstore_write("hvmloader/generation-id-address", addr);
 
-    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
-    *(uint64_t *)buf = gid;
-
-    return virt_to_phys(buf);    
+    return 1;
 }
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
@@ -381,7 +402,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     unsigned char       *dsdt;
     unsigned long        secondary_tables[ACPI_MAX_SECONDARY_TABLES];
     int                  nr_secondaries, i;
-    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -494,8 +514,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
-    vm_gid_addr = new_vm_gid();
-    if (!vm_gid_addr) goto oom;
+    if ( !new_vm_gid(acpi_info) )
+        goto oom;
 
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
@@ -503,7 +523,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
-    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
-- 
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 Tue Feb 19 09:31:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7jXY-0006BS-OC; Tue, 19 Feb 2013 09:31:08 +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 1U7jXX-0006BK-TB
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:31:08 +0000
Received: from [85.158.143.99:39298] by server-3.bemta-4.messagelabs.com id
	71/5B-08920-B5643215; Tue, 19 Feb 2013 09:31:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361266256!24771206!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22905 invoked from network); 19 Feb 2013 09:30:56 -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; 19 Feb 2013 09:30:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 09:28:54 +0000
Message-Id: <512353E502000078000BF521@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 09:28:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <51226EBB.3030503@citrix.com>
In-Reply-To: <51226EBB.3030503@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDE4LjAyLjEzIGF0IDE5OjExLCBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj
aXRyaXguY29tPiB3cm90ZToKPiBIZWxsbywKPiAKPiBPdXIgdGVzdGluZyBoYXMgZGlzY292ZXJl
ZCBhIGNyYXNoIChwYWdlZmF1bHQgYXQgMHgwMDAwMDAwMDAwMDAwMDA4KQo+IHdoaWNoIEkgaGF2
ZSB0cmFja2VkIGRvd24gdG8gYmFkIF9fcnVucV9yZW1vdmUoKSBpbiBjc2NoZWRfdmNwdV9zbGVl
cCgpCj4gaW4gc2NoZWRfY3JlZGl0LmMgKGJlY2F1c2UgYSBzdGF0aWMgZnVuY3Rpb24gb2YgdGhl
IHNhbWUgbmFtZSBhbHNvCj4gZXhpc3RzIGluIHNjaGVkX2NyZWRpdDIuYywgd2hpY2ggY29uZnVz
ZWQgbWF0dGVycyB0byBzdGFydCB3aXRoKQo+IAo+IFRoZSB0ZXN0IGNhc2Ugd2FzIGEgbG9vcCBv
ZiBsb2NhbGhvc3QgbWlncmF0ZSBvZiBhIDF2Y3B1IEhWTSB3aW44Cj4gZG9tYWluLiAgVGhlIHRl
c3QgY2FzZSBpdHNlbGYgaGFzIHBhc3NlZCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IG9uIHRoZQo+
IHNhbWUgWGVuIGNvZGViYXNlIChYZW4tNC4xLjMpLCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdmVy
eSByYXJlLiAgVGhlcmUKPiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYW55IHJlbGV2YW50IGNoYW5n
ZXMgYmV0d2VlbiB0aGUgdmVyc2lvbiBvZiBYZW4gaW4KPiB0aGUgdGVzdCBhbmQgeGVuLTQuMS10
ZXN0aW5nLgo+IAo+IFRoZSBmYWlsdXJlIGl0c2VsZiBpcyBiZWNhdXNlIG9mIGEgWEVOX0RPTUNU
TF9zY2hlZHVsZXJfb3AgKHRyYWNlIGJlbG93KQo+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBW
Q1BVIG9mIHRoZSBtaWdyYXRpbmcgZG9tYWluLgo+IAo+IChYRU4pIFhlbiBjYWxsIHRyYWNlOgo+
IChYRU4pICAgICAgIFs8ZmZmZjgyYzQ4MDExNmExND5dIGNzY2hlZF92Y3B1X3NsZWVwKzB4NDQv
MHg3MAo+IChYRU4pICAgICAgMFs8ZmZmZjgyYzQ4MDEyMDExNz5dIHZjcHVfc2xlZXBfbm9zeW5j
KzB4ZTcvMHgzYjAKPiAoWEVOKSAgICAgMTJbPGZmZmY4MmM0ODAxMjAzZTk+XSB2Y3B1X3NsZWVw
X3N5bmMrMHg5LzB4NTAKPiAoWEVOKSAgICAgMTRbPGZmZmY4MmM0ODAxMWZkNGM+XSBzY2hlZF9h
ZGp1c3QrMHhhYy8weDIzMAo+IChYRU4pICAgICAyNFs8ZmZmZjgyYzQ4MDEwMmJjMT5dIGRvX2Rv
bWN0bCsweDczMS8weDExMzAKPiAoWEVOKSAgICAgNjRbPGZmZmY4MmM0ODAyMDEzYzQ+XSBjb21w
YXRfaHlwZXJjYWxsKzB4NzQvMHg4MAo+IAo+IFRoZSByZWxldmFudCBwYXJ0IG9mIGNzY2hlZF92
Y3B1X3NsZWVwKCkgaXMKPiAKPiAgICAgZWxzZSBpZiAoIF9fdmNwdV9vbl9ydW5xKHN2YykgKQo+
ICAgICAgICAgX19ydW5xX3JlbW92ZShzdmMpOwo+IAo+IHdoaWNoIGRpc2Fzc2VtYmxlcyB0bwo+
IAo+IGZmZmY4MmM0ODAxMTZhMDE6ICAgICAgIDQ5IDhiIDEwICAgICAgICAgICAgICAgIG1vdiAg
ICAoJXI4KSwlcmR4Cj4gZmZmZjgyYzQ4MDExNmEwNDogICAgICAgNGMgMzkgYzIgICAgICAgICAg
ICAgICAgY21wICAgICVyOCwlcmR4Cj4gZmZmZjgyYzQ4MDExNmEwNzogICAgICAgNzUgMDcgICAg
ICAgICAgICAgICAgICAgam5lICAgIGZmZmY4MmM0ODAxMTZhMTAKPiA8Y3NjaGVkX3ZjcHVfc2xl
ZXArMHg0MD4KPiBmZmZmODJjNDgwMTE2YTA5OiAgICAgICBmMyBjMyAgICAgICAgICAgICAgICAg
ICByZXB6IHJldHEKPiBmZmZmODJjNDgwMTE2YTBiOiAgICAgICAwZiAxZiA0NCAwMCAwMCAgICAg
ICAgICBub3BsICAgMHgwKCVyYXgsJXJheCwxKQo+IGZmZmY4MmM0ODAxMTZhMTA6ICAgICAgIDQ5
IDhiIDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAweDgoJXI4KSwlcmF4Cj4gZmZmZjgyYzQ4MDEx
NmExNDogICAgICAgNDggODkgNDIgMDggICAgICAgICAgICAgbW92ICAgICVyYXgsMHg4KCVyZHgp
ICMKPiA8LSBQYWdlZmF1bHQgaGVyZQo+IGZmZmY4MmM0ODAxMTZhMTg6ICAgICAgIDQ4IDg5IDEw
ICAgICAgICAgICAgICAgIG1vdiAgICAlcmR4LCglcmF4KQo+IGZmZmY4MmM0ODAxMTZhMWI6ICAg
ICAgIDRkIDg5IDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAlcjgsMHg4KCVyOCkKPiBmZmZmODJj
NDgwMTE2YTFmOiAgICAgICA0ZCA4OSAwMCAgICAgICAgICAgICAgICBtb3YgICAgJXI4LCglcjgp
Cj4gCj4gVGhlIHJlbGV2YW50IGNyYXNoIHJlZ2lzdGVycyBmcm9tIHRoZSBwYWdlZmF1bHQgYXJl
Ogo+IHJheDogMDAwMDAwMDAwMDAwMDAwMAo+IHJkeDogMDAwMDAwMDAwMDAwMDAwMAo+ICByODog
ZmZmZjgzMDgwYzg5ZWQ5MAo+IAo+IElmIEkgYW0gcmVhZGluZyB0aGUgY29kZSBjb3JyZWN0bHks
IHRoaXMgbWVhbnMgdGhhdCBydW5xLT5uZXh0IGlzIE5VTEwsCj4gc28gd2UgZmFpbCBsaXN0X2Vt
cHR5KCkgYW5kIGVycm9uZW91c2x5IHBhc3MgX192Y3B1X29uX3J1bnEoKS4gIFdlIHRoZW4KPiBm
YWlsIHdpdGggYSBmYXVsdCB3aGVuIHRyeWluZyB0byB1cGRhdGUgcnVucS0+cHJldiwgd2hpY2gg
aXMgYWxzbyBOVUxMLgo+IAo+IFRoZSBvbmx5IHBsYWNlIEkgY2FuIHNwb3QgaW4gdGhlIGNvZGUg
d2hlcmUgdGhlIHJ1bnEtPntuZXh0LHByZXZ9IGNvdWxkCj4gY29uY2VpdmFibHkgYmUgTlVMTCBp
cyBpbiBjc2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBtZW1zZXQoKSBhbmQKPiBJTklU
X0xJU1RfSEVBRCgpLiAgVGhpcyBpcyBsb2dpY2FsbHkgc2Vuc2libGUgaW4gY29tYmluYXRpb24g
d2l0aCB0aGUKPiBsb2NhbGhvc3QgbWlncmF0ZSBsb29wLCBhbmQgSSBjYW50IGltbWVkaWF0ZWx5
IHNlZSBhbnl0aGluZyB0byBwcmV2ZW50Cj4gdGhpcyByYWNlIGhhcHBlbmluZy4KCkJ1dCB0aGF0
IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVkX2FsbG9jX3ZkYXRhKCkgZG9lc24ndCBzdG9yZQpz
dmMgaW50byB2Yy0+c2NoZWRfcHJpdjsgdGhhdCdzIGJlaW5nIGRvbmUgYnkgdGhlIGdlbmVyaWMK
c2NoZWR1bGVyIGNvZGUgb25jZSB0aGUgYWN0b3IgcmV0dXJucy4KClNvIEknZCByYXRoZXIgc3Vz
cGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwgd2hpY2ggaXMgZWFzaWx5CnBvc3NpYmxl
IHdoZW4gcmFjaW5nIHdpdGggc2NoZWRfbW92ZV9kb21haW4oKSAoYXMgb3Bwb3NlZCB0bwpzY2hl
ZHVsZV9jcHVfc3dpdGNoKCksIHdoZXJlIHRoZSBuZXcgcG9pbnRlciBnZXRzIHN0b3JlZApfYmVm
b3JlXyBkZS1hbGxvY2F0aW5nIHRoZSBvbGQgb25lKS4KCkhvd2V2ZXIsIHNjaGVkX21vdmVfZG9t
YWluKCkgKGFzIHdlbGwgYXMgc2NoZWR1bGVfY3B1X3N3aXRjaCgpKQpnZXQgY2FsbGVkIG9ubHkg
ZnJvbSBDUFUgcG9vbHMgY29kZSwgYW5kIEkgd291bGQgZ3Vlc3MgQ1BVIHBvb2xzCmFyZW4ndCBp
bnZvbHZlZCBoZXJlLCBhbmQgeW91IGRvbid0IGluIHBhcmFsbGVsIHNvZnQgb2ZmbGluZS9vbmxp
bmUKcENQVS1zIChhcyBJJ20gc3VyZSB5b3Ugb3RoZXJ3aXNlIHdvdWxkIGhhdmUgbWVudGlvbmVk
IGl0KS4KCkJ1dCB3YWl0IC0gbGlieGxfX2RvbWFpbl9tYWtlKCkgX3VuY29uZGl0aW9uYWxseV8g
Y2FsbHMKeGNfY3B1cG9vbF9tb3ZlZG9tYWluKCksIGFzIGRvZXMgWGVuZERvbWFpbkluZm8ncwpf
Y29uc3RydWN0RG9tYWluKCkuIFRoZSByZWFzb24gZm9yIHRoaXMgZXNjYXBlcyBtZSAtIErDvHJn
ZW4/IFlldApJJ2QgZXhwZWN0IHRoZSBwb29sIElEIG1hdGNoaW5nIGNoZWNrIHRvIHNob3J0IGN1
dCB0aGUgcmVzdWx0aW5nCnN5c2N0bCwgaS5lLiBzY2hlZF9tb3ZlX2RvbWFpbigpIG91Z2h0IHRv
IG5vdCBiZSByZWFjaGVkIGFueXdheQood29ydGggdmVyaWZ5aW5nIG9mIGNvdXJzZSkuCgpUaGUg
cmFjZSB0aGVyZSBuZXZlcnRoZWxlc3Mgb3VnaHQgdG8gYmUgZml4ZWQuCgpKYW4KCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:31:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7jXY-0006BS-OC; Tue, 19 Feb 2013 09:31:08 +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 1U7jXX-0006BK-TB
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:31:08 +0000
Received: from [85.158.143.99:39298] by server-3.bemta-4.messagelabs.com id
	71/5B-08920-B5643215; Tue, 19 Feb 2013 09:31:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361266256!24771206!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22905 invoked from network); 19 Feb 2013 09:30:56 -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; 19 Feb 2013 09:30:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 09:28:54 +0000
Message-Id: <512353E502000078000BF521@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 09:28:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <51226EBB.3030503@citrix.com>
In-Reply-To: <51226EBB.3030503@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDE4LjAyLjEzIGF0IDE5OjExLCBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj
aXRyaXguY29tPiB3cm90ZToKPiBIZWxsbywKPiAKPiBPdXIgdGVzdGluZyBoYXMgZGlzY292ZXJl
ZCBhIGNyYXNoIChwYWdlZmF1bHQgYXQgMHgwMDAwMDAwMDAwMDAwMDA4KQo+IHdoaWNoIEkgaGF2
ZSB0cmFja2VkIGRvd24gdG8gYmFkIF9fcnVucV9yZW1vdmUoKSBpbiBjc2NoZWRfdmNwdV9zbGVl
cCgpCj4gaW4gc2NoZWRfY3JlZGl0LmMgKGJlY2F1c2UgYSBzdGF0aWMgZnVuY3Rpb24gb2YgdGhl
IHNhbWUgbmFtZSBhbHNvCj4gZXhpc3RzIGluIHNjaGVkX2NyZWRpdDIuYywgd2hpY2ggY29uZnVz
ZWQgbWF0dGVycyB0byBzdGFydCB3aXRoKQo+IAo+IFRoZSB0ZXN0IGNhc2Ugd2FzIGEgbG9vcCBv
ZiBsb2NhbGhvc3QgbWlncmF0ZSBvZiBhIDF2Y3B1IEhWTSB3aW44Cj4gZG9tYWluLiAgVGhlIHRl
c3QgY2FzZSBpdHNlbGYgaGFzIHBhc3NlZCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IG9uIHRoZQo+
IHNhbWUgWGVuIGNvZGViYXNlIChYZW4tNC4xLjMpLCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdmVy
eSByYXJlLiAgVGhlcmUKPiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYW55IHJlbGV2YW50IGNoYW5n
ZXMgYmV0d2VlbiB0aGUgdmVyc2lvbiBvZiBYZW4gaW4KPiB0aGUgdGVzdCBhbmQgeGVuLTQuMS10
ZXN0aW5nLgo+IAo+IFRoZSBmYWlsdXJlIGl0c2VsZiBpcyBiZWNhdXNlIG9mIGEgWEVOX0RPTUNU
TF9zY2hlZHVsZXJfb3AgKHRyYWNlIGJlbG93KQo+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBW
Q1BVIG9mIHRoZSBtaWdyYXRpbmcgZG9tYWluLgo+IAo+IChYRU4pIFhlbiBjYWxsIHRyYWNlOgo+
IChYRU4pICAgICAgIFs8ZmZmZjgyYzQ4MDExNmExND5dIGNzY2hlZF92Y3B1X3NsZWVwKzB4NDQv
MHg3MAo+IChYRU4pICAgICAgMFs8ZmZmZjgyYzQ4MDEyMDExNz5dIHZjcHVfc2xlZXBfbm9zeW5j
KzB4ZTcvMHgzYjAKPiAoWEVOKSAgICAgMTJbPGZmZmY4MmM0ODAxMjAzZTk+XSB2Y3B1X3NsZWVw
X3N5bmMrMHg5LzB4NTAKPiAoWEVOKSAgICAgMTRbPGZmZmY4MmM0ODAxMWZkNGM+XSBzY2hlZF9h
ZGp1c3QrMHhhYy8weDIzMAo+IChYRU4pICAgICAyNFs8ZmZmZjgyYzQ4MDEwMmJjMT5dIGRvX2Rv
bWN0bCsweDczMS8weDExMzAKPiAoWEVOKSAgICAgNjRbPGZmZmY4MmM0ODAyMDEzYzQ+XSBjb21w
YXRfaHlwZXJjYWxsKzB4NzQvMHg4MAo+IAo+IFRoZSByZWxldmFudCBwYXJ0IG9mIGNzY2hlZF92
Y3B1X3NsZWVwKCkgaXMKPiAKPiAgICAgZWxzZSBpZiAoIF9fdmNwdV9vbl9ydW5xKHN2YykgKQo+
ICAgICAgICAgX19ydW5xX3JlbW92ZShzdmMpOwo+IAo+IHdoaWNoIGRpc2Fzc2VtYmxlcyB0bwo+
IAo+IGZmZmY4MmM0ODAxMTZhMDE6ICAgICAgIDQ5IDhiIDEwICAgICAgICAgICAgICAgIG1vdiAg
ICAoJXI4KSwlcmR4Cj4gZmZmZjgyYzQ4MDExNmEwNDogICAgICAgNGMgMzkgYzIgICAgICAgICAg
ICAgICAgY21wICAgICVyOCwlcmR4Cj4gZmZmZjgyYzQ4MDExNmEwNzogICAgICAgNzUgMDcgICAg
ICAgICAgICAgICAgICAgam5lICAgIGZmZmY4MmM0ODAxMTZhMTAKPiA8Y3NjaGVkX3ZjcHVfc2xl
ZXArMHg0MD4KPiBmZmZmODJjNDgwMTE2YTA5OiAgICAgICBmMyBjMyAgICAgICAgICAgICAgICAg
ICByZXB6IHJldHEKPiBmZmZmODJjNDgwMTE2YTBiOiAgICAgICAwZiAxZiA0NCAwMCAwMCAgICAg
ICAgICBub3BsICAgMHgwKCVyYXgsJXJheCwxKQo+IGZmZmY4MmM0ODAxMTZhMTA6ICAgICAgIDQ5
IDhiIDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAweDgoJXI4KSwlcmF4Cj4gZmZmZjgyYzQ4MDEx
NmExNDogICAgICAgNDggODkgNDIgMDggICAgICAgICAgICAgbW92ICAgICVyYXgsMHg4KCVyZHgp
ICMKPiA8LSBQYWdlZmF1bHQgaGVyZQo+IGZmZmY4MmM0ODAxMTZhMTg6ICAgICAgIDQ4IDg5IDEw
ICAgICAgICAgICAgICAgIG1vdiAgICAlcmR4LCglcmF4KQo+IGZmZmY4MmM0ODAxMTZhMWI6ICAg
ICAgIDRkIDg5IDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAlcjgsMHg4KCVyOCkKPiBmZmZmODJj
NDgwMTE2YTFmOiAgICAgICA0ZCA4OSAwMCAgICAgICAgICAgICAgICBtb3YgICAgJXI4LCglcjgp
Cj4gCj4gVGhlIHJlbGV2YW50IGNyYXNoIHJlZ2lzdGVycyBmcm9tIHRoZSBwYWdlZmF1bHQgYXJl
Ogo+IHJheDogMDAwMDAwMDAwMDAwMDAwMAo+IHJkeDogMDAwMDAwMDAwMDAwMDAwMAo+ICByODog
ZmZmZjgzMDgwYzg5ZWQ5MAo+IAo+IElmIEkgYW0gcmVhZGluZyB0aGUgY29kZSBjb3JyZWN0bHks
IHRoaXMgbWVhbnMgdGhhdCBydW5xLT5uZXh0IGlzIE5VTEwsCj4gc28gd2UgZmFpbCBsaXN0X2Vt
cHR5KCkgYW5kIGVycm9uZW91c2x5IHBhc3MgX192Y3B1X29uX3J1bnEoKS4gIFdlIHRoZW4KPiBm
YWlsIHdpdGggYSBmYXVsdCB3aGVuIHRyeWluZyB0byB1cGRhdGUgcnVucS0+cHJldiwgd2hpY2gg
aXMgYWxzbyBOVUxMLgo+IAo+IFRoZSBvbmx5IHBsYWNlIEkgY2FuIHNwb3QgaW4gdGhlIGNvZGUg
d2hlcmUgdGhlIHJ1bnEtPntuZXh0LHByZXZ9IGNvdWxkCj4gY29uY2VpdmFibHkgYmUgTlVMTCBp
cyBpbiBjc2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBtZW1zZXQoKSBhbmQKPiBJTklU
X0xJU1RfSEVBRCgpLiAgVGhpcyBpcyBsb2dpY2FsbHkgc2Vuc2libGUgaW4gY29tYmluYXRpb24g
d2l0aCB0aGUKPiBsb2NhbGhvc3QgbWlncmF0ZSBsb29wLCBhbmQgSSBjYW50IGltbWVkaWF0ZWx5
IHNlZSBhbnl0aGluZyB0byBwcmV2ZW50Cj4gdGhpcyByYWNlIGhhcHBlbmluZy4KCkJ1dCB0aGF0
IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVkX2FsbG9jX3ZkYXRhKCkgZG9lc24ndCBzdG9yZQpz
dmMgaW50byB2Yy0+c2NoZWRfcHJpdjsgdGhhdCdzIGJlaW5nIGRvbmUgYnkgdGhlIGdlbmVyaWMK
c2NoZWR1bGVyIGNvZGUgb25jZSB0aGUgYWN0b3IgcmV0dXJucy4KClNvIEknZCByYXRoZXIgc3Vz
cGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwgd2hpY2ggaXMgZWFzaWx5CnBvc3NpYmxl
IHdoZW4gcmFjaW5nIHdpdGggc2NoZWRfbW92ZV9kb21haW4oKSAoYXMgb3Bwb3NlZCB0bwpzY2hl
ZHVsZV9jcHVfc3dpdGNoKCksIHdoZXJlIHRoZSBuZXcgcG9pbnRlciBnZXRzIHN0b3JlZApfYmVm
b3JlXyBkZS1hbGxvY2F0aW5nIHRoZSBvbGQgb25lKS4KCkhvd2V2ZXIsIHNjaGVkX21vdmVfZG9t
YWluKCkgKGFzIHdlbGwgYXMgc2NoZWR1bGVfY3B1X3N3aXRjaCgpKQpnZXQgY2FsbGVkIG9ubHkg
ZnJvbSBDUFUgcG9vbHMgY29kZSwgYW5kIEkgd291bGQgZ3Vlc3MgQ1BVIHBvb2xzCmFyZW4ndCBp
bnZvbHZlZCBoZXJlLCBhbmQgeW91IGRvbid0IGluIHBhcmFsbGVsIHNvZnQgb2ZmbGluZS9vbmxp
bmUKcENQVS1zIChhcyBJJ20gc3VyZSB5b3Ugb3RoZXJ3aXNlIHdvdWxkIGhhdmUgbWVudGlvbmVk
IGl0KS4KCkJ1dCB3YWl0IC0gbGlieGxfX2RvbWFpbl9tYWtlKCkgX3VuY29uZGl0aW9uYWxseV8g
Y2FsbHMKeGNfY3B1cG9vbF9tb3ZlZG9tYWluKCksIGFzIGRvZXMgWGVuZERvbWFpbkluZm8ncwpf
Y29uc3RydWN0RG9tYWluKCkuIFRoZSByZWFzb24gZm9yIHRoaXMgZXNjYXBlcyBtZSAtIErDvHJn
ZW4/IFlldApJJ2QgZXhwZWN0IHRoZSBwb29sIElEIG1hdGNoaW5nIGNoZWNrIHRvIHNob3J0IGN1
dCB0aGUgcmVzdWx0aW5nCnN5c2N0bCwgaS5lLiBzY2hlZF9tb3ZlX2RvbWFpbigpIG91Z2h0IHRv
IG5vdCBiZSByZWFjaGVkIGFueXdheQood29ydGggdmVyaWZ5aW5nIG9mIGNvdXJzZSkuCgpUaGUg
cmFjZSB0aGVyZSBuZXZlcnRoZWxlc3Mgb3VnaHQgdG8gYmUgZml4ZWQuCgpKYW4KCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:39:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09:39: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 1U7jer-0006MM-Qb; Tue, 19 Feb 2013 09:38:41 +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 1U7jeq-0006MH-7Z
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:38:40 +0000
Received: from [85.158.138.51:48704] by server-12.bemta-3.messagelabs.com id
	6A/D5-05889-F1843215; Tue, 19 Feb 2013 09:38:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361266718!20063753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17198 invoked from network); 19 Feb 2013 09:38:38 -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; 19 Feb 2013 09:38:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 09:38:37 +0000
Message-Id: <5123562A02000078000BF532@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 09:38:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-16207-mainreport@xen.org>
	<1361264537.1051.64.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361264537.1051.64.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen.org" <ian.jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 16207: 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 19.02.13 at 10:02, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-02-19 at 05:42 +0000, xen.org wrote:
>> flight 16207 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16207/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 
> 16171
> 
> This looks distressingly similar to the failure in 15401 which we
> overrode with a manual push on the basis that 15179 was a fluke pass.
> Although I suppose one Windows install regression looks much like any
> other...

On closer inspection I'm not as certain about the similarity: Back
then, Windows was not completing a shutdown, i.e. waiting for
some event to happen (looking at/playing with the LAPIC) to make
progress. Here, Windows sits at the logon screen (and both vCPU-s
are idle), yet the VM apparently can't be reached over the network.

But there nevertheless must be some sort of problem (possibly a
regression, but could as well be an intermittent problem now
being exposed more readily), as earlier that other qemut-win
test didn't consistently fail, and the test above didn't fail that
frequently either.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 09:39:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 09:39: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 1U7jer-0006MM-Qb; Tue, 19 Feb 2013 09:38:41 +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 1U7jeq-0006MH-7Z
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 09:38:40 +0000
Received: from [85.158.138.51:48704] by server-12.bemta-3.messagelabs.com id
	6A/D5-05889-F1843215; Tue, 19 Feb 2013 09:38:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361266718!20063753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17198 invoked from network); 19 Feb 2013 09:38:38 -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; 19 Feb 2013 09:38:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 09:38:37 +0000
Message-Id: <5123562A02000078000BF532@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 09:38:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-16207-mainreport@xen.org>
	<1361264537.1051.64.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361264537.1051.64.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen.org" <ian.jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 16207: 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 19.02.13 at 10:02, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-02-19 at 05:42 +0000, xen.org wrote:
>> flight 16207 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16207/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 
> 16171
> 
> This looks distressingly similar to the failure in 15401 which we
> overrode with a manual push on the basis that 15179 was a fluke pass.
> Although I suppose one Windows install regression looks much like any
> other...

On closer inspection I'm not as certain about the similarity: Back
then, Windows was not completing a shutdown, i.e. waiting for
some event to happen (looking at/playing with the LAPIC) to make
progress. Here, Windows sits at the logon screen (and both vCPU-s
are idle), yet the VM apparently can't be reached over the network.

But there nevertheless must be some sort of problem (possibly a
regression, but could as well be an intermittent problem now
being exposed more readily), as earlier that other qemut-win
test didn't consistently fail, and the test above didn't fail that
frequently either.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 10:21:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 10:21: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 1U7kK5-0006we-O2; Tue, 19 Feb 2013 10:21:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U7kK4-0006wZ-MN
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 10:21:16 +0000
Received: from [193.109.254.147:24206] by server-7.bemta-14.messagelabs.com id
	B8/BF-13581-B1253215; Tue, 19 Feb 2013 10:21:15 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361269273!8933155!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17657 invoked from network); 19 Feb 2013 10:21:14 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Feb 2013 10:21:14 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U7kJv-0001AN-5p; Tue, 19 Feb 2013 10:21:07 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U7kJr-0005Qz-Sv; Tue, 19 Feb 2013 10:21:06 +0000
Message-ID: <1361269257.1051.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Tue, 19 Feb 2013 10:20:57 +0000
In-Reply-To: <1360930184.6534.16.camel@i7.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEzLTAyLTE1IGF0IDEyOjA5ICswMDAwLCBEYXZpZCBXb29kaG91c2Ugd3JvdGU6
Cj4gT24gVGh1LCAyMDEzLTAyLTE0IGF0IDE2OjQ2ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6
Cj4gPiBSaWdodCwgd2UgcmVhbGx5IG5lZWQgdG8gZmluZCBzb21lb25lIHdpdGggaG91cnMgdG8g
ZmluaXNoIHByb3Blcmx5Cj4gPiBpbnRlZ3JhdGluZyBPVk1GLgo+IAo+IEhtLCB0aGF0ICdzb21l
b25lJyBtYXkgZW5kIHVwIGJlaW5nIG1lwrkuCgpUaGF0IHdvdWxkIGJlIGF3ZXNvbWUhCgpJIHdh
cyBhY3R1YWxseSB3b25kZXJpbmcgaWYgdGhpcyBtaWdodCBtYWtlIGEgZ29vZCBHU29DIHByb2pl
Y3QsIHRoZXJlCmhhcyBiZWVuIHNvbWVvbmUgKHRoZSBzYW1lIGd1eSBJSVJDKSBkb2luZyBUaWFu
b2NvcmUgb24gWGVuIHN0dWZmIGluIHRoZQpsYXN0IHR3byB5ZWFycywgdW5kZXIgdGhlIFRpYW5v
Y29yZSB1bWJyZWxsYSBhbHRob3VnaCB3aXRoIGEgWGVuLm9yZwpjby1tZW50b3IuCgo+IFNvLi4u
IGZyb20gdGhlIFhlbiBwb2ludCBvZiB2aWV3LCB3aGF0IG5lZWRzIGRvaW5nPwoKSSBoYXZlbid0
IGxvb2tlZCBhdCBvciBydW4gT1ZNRiBzdHVmZiBteXNlbGYgb24gWGVuIG9yIG90aGVyd2lzZSwg
c28KdGFrZSB0aGlzIHdpdGggYSBwaW5jaCBvZiBzYWx0Li4uCgpJIGV4cGVjdCB0aGVyZSB3aWxs
IGJlIHNvbWUgcm91Z2ggZWRnZXMgbGlrZSB0aGUgTlYgdmFyaWFibGUgdGhpbmcgLS0gSQpoYXZl
IGEgZmVlbGluZyB0aGVzZSB3aWxsIGhhdmUgYSBsb3QgaW4gY29tbW9uIHdpdGggcWVtdS9LVk0s
IHNpbmNlIHRoZXkKd291bGQgdGVuZCB0byBpbnRlcmFjdCB3aXRoIHRoZSAicGxhdGZvcm0iIChw
cm92aWRlZCBieSBxZW11LWRtIHVuZGVyClhlbikgcmF0aGVyIHRoYW4gcHJvY2Vzc29yIG9yIG1l
bW9yeSB2aXJ0IGV0Yy4KCkZvciB0aGUgbW9zdCBwYXJ0IHRoZSBJIHJlY2tvbiB0aGUgWGVuIHNw
ZWNpZmljIHRoaW5ncyB3aWxsIGJlIHJlc3luYwp3aXRoIGEgcmVjZW50IHVwc3RyZWFtIGFuZCBm
aXh1cCB0aGUgWGVuIGJ1aWxkIHN5c3RlbSBpbnRlZ3JhdGlvbiwgc3R1ZmYKbGlrZSB0aGF0LiAK
CldlJ2QgbGlrZSB0byBzZWUgUFYgSS9PIGRyaXZlcnMgYXQgc29tZSBwb2ludCBidXQgdGhhdCdz
IGEgc2VwYXJhdGUKcHJvamVjdCBpbiBpdHMgb3duIHJpZ2h0IEkgdGhpbmsuCgo+ICBUaGVyZSBh
cmUgc29tZQo+IHRoaW5ncyBvbiBteSBUT0RPIGxpc3Qgd2hpY2ggYXBwbHkgdG8gUWVtdS9LVk0g
dG9vIOKAlCBtb3N0IGltcG9ydGFudGx5LAo+IGZpeGluZyBib290b3JkZXIgaGFuZGxpbmcsIHdo
aWNoIGJhc2ljYWxseSBpbnZvbHZlcyBmaXhpbmcgdGhlIGdlbmVyYWwKPiBjYXNlIG9mIE5WIHZh
cmlhYmxlIHN0b3JhZ2UgZm9yIFVFRkkgYXMgZGlzY3Vzc2VkLiBCdXQgaXMgdGhlcmUgYW55dGhp
bmcKPiBYZW4tc3BlY2lmaWMgdGhhdCBJJ20gbGlrZWx5IHRvIG1pc3M/CgpUaGUgbWFpbiBkaWZm
ZXJlbmNlIGJldHdlZW4gWGVuIGFuZCBRZW11L0tWTSBpbiB0aGlzIGNvbnRleHQgaXMgdGhhdCBY
ZW4Kc3VwcGxpZWQgaXQncyBvd24gU01CSU9TICYgQUNQSSB0YWJsZXMgZXRjLiBUaGVyZSdzIGEg
bGlrZWx5aG9vZCBvZiBYZW4KYW5kIE9WTUYgZXhwb3NpbmcgZWFjaCBvdGhlcnMgYnVncyBpbiB0
aGF0IGFyZWEgSSBzdXNwZWN0LgoKPiBBbmQgb24gdGhlIHN1YmplY3Qgb2YgdGhlIE5WIHN0b3Jh
Z2UuLi4gZG9lcyAtcGZsYXNoIHdvcmsgb24gcWVtdS14ZW4sCj4gYXMgbG9uZyBhcyB3ZSdyZSBu
b3QgYWN0dWFsbHkgcnVubmluZyAqY29kZSogZnJvbSB0aGUgZGV2aWNlIGFuZCB3ZSdyZQo+IG9u
bHkgdXNpbmcgaXQgZm9yIGRhdGEgc3RvcmFnZT8KCkknbSBub3Qgc3VyZSwgSSd2ZSBDQydkIEFu
dGhvbnkgJiBTdGVmYW5vLiBBc3N1bWluZyB0aGUgWGVuIG1hY2hpbmUgdHlwZQppbiBRZW11IHdp
cmVzIGl0IHVwIHRoZW4gSSBkb24ndCBrbm93IHdoeSBpdCBzaG91bGRuJ3Qgd29yayBhbmQgaWYg
d2UKZG9uJ3Qgd2lyZSBpdCB1cCBJIGRvbid0IHNlZSB3aHkgd2UgY291bGRuJ3QuCgpIdm1sb2Fk
ZXIgbWlnaHQgbmVlZCB0byBiZSB0d2Vha2VkIHRvIHNldHVwIHRoZSBlODIwIGNvcnJlY3RseSBh
bmQKcGVyaGFwcyB0aGUgc29tZSB0YWJsZSBvciBvdGhlciB3b3VsZCBuZWVkIHRvIHJlZmVyIHRv
IGl0IGFsc28/CgpJZiB0aGUgQVJNIHdvcmxkIGNvbnRpbnVlcyBtb3ZpbmcgdG93YXJkcyBVRUZJ
IHRoZW4gZXZlbnR1YWxseSB3ZSB3aWxsCmxpa2VseSB3YW50IHRvIGVuYWJsZSB0aGlzIHRoZXJl
IHRvbywgYnV0IGxldHMgc29ydCBvdXQgeDg2IGZpcnN0LgoKPiAgQXJlIHlvdSBjb250ZW50IHdp
dGggbXkgc3RhdGVkIHBsYW4gdG8KPiBwcm92aWRlIGEgImRpc2siIGltYWdlIGZvciB0aGF0LCB3
aGljaCBpcyBzb21ldGhpbmcgbGlrZSBhIDI1NktpQiBmaWxlCj4gb24gdGhlIGhvc3Qgc2lkZSwg
ZXhwb3NlZCBhcyBhIGZsYXNoIGRldmljZSB0byB0aGUgZ3Vlc3Q/CgpJdCBzb3VuZHMgT0sgdG8g
bWUuIFRoZSBvdGhlciBvcHRpb24gd291bGQgYmUgdG8gc3Rhc2ggaXQgaW4geGVuc3RvcmUsCmJ1
dCB0aGF0IGRvZXNuJ3Qgc291bmQgbGlrZSB0aGUgcmlnaHQgb3B0aW9uIHRvIG1lLgoKSWFuLgoK
LS0gCklhbiBDYW1wYmVsbAoKRmFzY2luYXRpbmcgaXMgYSB3b3JkIEkgdXNlIGZvciB0aGUgdW5l
eHBlY3RlZC4KCQktLSBTcG9jaywgIlRoZSBTcXVpcmUgb2YgR290aG9zIiwgc3RhcmRhdGUgMjEy
NC41CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 19 10:21:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 10:21: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 1U7kK5-0006we-O2; Tue, 19 Feb 2013 10:21:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U7kK4-0006wZ-MN
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 10:21:16 +0000
Received: from [193.109.254.147:24206] by server-7.bemta-14.messagelabs.com id
	B8/BF-13581-B1253215; Tue, 19 Feb 2013 10:21:15 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361269273!8933155!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17657 invoked from network); 19 Feb 2013 10:21:14 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Feb 2013 10:21:14 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U7kJv-0001AN-5p; Tue, 19 Feb 2013 10:21:07 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U7kJr-0005Qz-Sv; Tue, 19 Feb 2013 10:21:06 +0000
Message-ID: <1361269257.1051.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Tue, 19 Feb 2013 10:20:57 +0000
In-Reply-To: <1360930184.6534.16.camel@i7.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEzLTAyLTE1IGF0IDEyOjA5ICswMDAwLCBEYXZpZCBXb29kaG91c2Ugd3JvdGU6
Cj4gT24gVGh1LCAyMDEzLTAyLTE0IGF0IDE2OjQ2ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6
Cj4gPiBSaWdodCwgd2UgcmVhbGx5IG5lZWQgdG8gZmluZCBzb21lb25lIHdpdGggaG91cnMgdG8g
ZmluaXNoIHByb3Blcmx5Cj4gPiBpbnRlZ3JhdGluZyBPVk1GLgo+IAo+IEhtLCB0aGF0ICdzb21l
b25lJyBtYXkgZW5kIHVwIGJlaW5nIG1lwrkuCgpUaGF0IHdvdWxkIGJlIGF3ZXNvbWUhCgpJIHdh
cyBhY3R1YWxseSB3b25kZXJpbmcgaWYgdGhpcyBtaWdodCBtYWtlIGEgZ29vZCBHU29DIHByb2pl
Y3QsIHRoZXJlCmhhcyBiZWVuIHNvbWVvbmUgKHRoZSBzYW1lIGd1eSBJSVJDKSBkb2luZyBUaWFu
b2NvcmUgb24gWGVuIHN0dWZmIGluIHRoZQpsYXN0IHR3byB5ZWFycywgdW5kZXIgdGhlIFRpYW5v
Y29yZSB1bWJyZWxsYSBhbHRob3VnaCB3aXRoIGEgWGVuLm9yZwpjby1tZW50b3IuCgo+IFNvLi4u
IGZyb20gdGhlIFhlbiBwb2ludCBvZiB2aWV3LCB3aGF0IG5lZWRzIGRvaW5nPwoKSSBoYXZlbid0
IGxvb2tlZCBhdCBvciBydW4gT1ZNRiBzdHVmZiBteXNlbGYgb24gWGVuIG9yIG90aGVyd2lzZSwg
c28KdGFrZSB0aGlzIHdpdGggYSBwaW5jaCBvZiBzYWx0Li4uCgpJIGV4cGVjdCB0aGVyZSB3aWxs
IGJlIHNvbWUgcm91Z2ggZWRnZXMgbGlrZSB0aGUgTlYgdmFyaWFibGUgdGhpbmcgLS0gSQpoYXZl
IGEgZmVlbGluZyB0aGVzZSB3aWxsIGhhdmUgYSBsb3QgaW4gY29tbW9uIHdpdGggcWVtdS9LVk0s
IHNpbmNlIHRoZXkKd291bGQgdGVuZCB0byBpbnRlcmFjdCB3aXRoIHRoZSAicGxhdGZvcm0iIChw
cm92aWRlZCBieSBxZW11LWRtIHVuZGVyClhlbikgcmF0aGVyIHRoYW4gcHJvY2Vzc29yIG9yIG1l
bW9yeSB2aXJ0IGV0Yy4KCkZvciB0aGUgbW9zdCBwYXJ0IHRoZSBJIHJlY2tvbiB0aGUgWGVuIHNw
ZWNpZmljIHRoaW5ncyB3aWxsIGJlIHJlc3luYwp3aXRoIGEgcmVjZW50IHVwc3RyZWFtIGFuZCBm
aXh1cCB0aGUgWGVuIGJ1aWxkIHN5c3RlbSBpbnRlZ3JhdGlvbiwgc3R1ZmYKbGlrZSB0aGF0LiAK
CldlJ2QgbGlrZSB0byBzZWUgUFYgSS9PIGRyaXZlcnMgYXQgc29tZSBwb2ludCBidXQgdGhhdCdz
IGEgc2VwYXJhdGUKcHJvamVjdCBpbiBpdHMgb3duIHJpZ2h0IEkgdGhpbmsuCgo+ICBUaGVyZSBh
cmUgc29tZQo+IHRoaW5ncyBvbiBteSBUT0RPIGxpc3Qgd2hpY2ggYXBwbHkgdG8gUWVtdS9LVk0g
dG9vIOKAlCBtb3N0IGltcG9ydGFudGx5LAo+IGZpeGluZyBib290b3JkZXIgaGFuZGxpbmcsIHdo
aWNoIGJhc2ljYWxseSBpbnZvbHZlcyBmaXhpbmcgdGhlIGdlbmVyYWwKPiBjYXNlIG9mIE5WIHZh
cmlhYmxlIHN0b3JhZ2UgZm9yIFVFRkkgYXMgZGlzY3Vzc2VkLiBCdXQgaXMgdGhlcmUgYW55dGhp
bmcKPiBYZW4tc3BlY2lmaWMgdGhhdCBJJ20gbGlrZWx5IHRvIG1pc3M/CgpUaGUgbWFpbiBkaWZm
ZXJlbmNlIGJldHdlZW4gWGVuIGFuZCBRZW11L0tWTSBpbiB0aGlzIGNvbnRleHQgaXMgdGhhdCBY
ZW4Kc3VwcGxpZWQgaXQncyBvd24gU01CSU9TICYgQUNQSSB0YWJsZXMgZXRjLiBUaGVyZSdzIGEg
bGlrZWx5aG9vZCBvZiBYZW4KYW5kIE9WTUYgZXhwb3NpbmcgZWFjaCBvdGhlcnMgYnVncyBpbiB0
aGF0IGFyZWEgSSBzdXNwZWN0LgoKPiBBbmQgb24gdGhlIHN1YmplY3Qgb2YgdGhlIE5WIHN0b3Jh
Z2UuLi4gZG9lcyAtcGZsYXNoIHdvcmsgb24gcWVtdS14ZW4sCj4gYXMgbG9uZyBhcyB3ZSdyZSBu
b3QgYWN0dWFsbHkgcnVubmluZyAqY29kZSogZnJvbSB0aGUgZGV2aWNlIGFuZCB3ZSdyZQo+IG9u
bHkgdXNpbmcgaXQgZm9yIGRhdGEgc3RvcmFnZT8KCkknbSBub3Qgc3VyZSwgSSd2ZSBDQydkIEFu
dGhvbnkgJiBTdGVmYW5vLiBBc3N1bWluZyB0aGUgWGVuIG1hY2hpbmUgdHlwZQppbiBRZW11IHdp
cmVzIGl0IHVwIHRoZW4gSSBkb24ndCBrbm93IHdoeSBpdCBzaG91bGRuJ3Qgd29yayBhbmQgaWYg
d2UKZG9uJ3Qgd2lyZSBpdCB1cCBJIGRvbid0IHNlZSB3aHkgd2UgY291bGRuJ3QuCgpIdm1sb2Fk
ZXIgbWlnaHQgbmVlZCB0byBiZSB0d2Vha2VkIHRvIHNldHVwIHRoZSBlODIwIGNvcnJlY3RseSBh
bmQKcGVyaGFwcyB0aGUgc29tZSB0YWJsZSBvciBvdGhlciB3b3VsZCBuZWVkIHRvIHJlZmVyIHRv
IGl0IGFsc28/CgpJZiB0aGUgQVJNIHdvcmxkIGNvbnRpbnVlcyBtb3ZpbmcgdG93YXJkcyBVRUZJ
IHRoZW4gZXZlbnR1YWxseSB3ZSB3aWxsCmxpa2VseSB3YW50IHRvIGVuYWJsZSB0aGlzIHRoZXJl
IHRvbywgYnV0IGxldHMgc29ydCBvdXQgeDg2IGZpcnN0LgoKPiAgQXJlIHlvdSBjb250ZW50IHdp
dGggbXkgc3RhdGVkIHBsYW4gdG8KPiBwcm92aWRlIGEgImRpc2siIGltYWdlIGZvciB0aGF0LCB3
aGljaCBpcyBzb21ldGhpbmcgbGlrZSBhIDI1NktpQiBmaWxlCj4gb24gdGhlIGhvc3Qgc2lkZSwg
ZXhwb3NlZCBhcyBhIGZsYXNoIGRldmljZSB0byB0aGUgZ3Vlc3Q/CgpJdCBzb3VuZHMgT0sgdG8g
bWUuIFRoZSBvdGhlciBvcHRpb24gd291bGQgYmUgdG8gc3Rhc2ggaXQgaW4geGVuc3RvcmUsCmJ1
dCB0aGF0IGRvZXNuJ3Qgc291bmQgbGlrZSB0aGUgcmlnaHQgb3B0aW9uIHRvIG1lLgoKSWFuLgoK
LS0gCklhbiBDYW1wYmVsbAoKRmFzY2luYXRpbmcgaXMgYSB3b3JkIEkgdXNlIGZvciB0aGUgdW5l
eHBlY3RlZC4KCQktLSBTcG9jaywgIlRoZSBTcXVpcmUgb2YgR290aG9zIiwgc3RhcmRhdGUgMjEy
NC41CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 19 10:51:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 10: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 1U7kn4-0007HT-DK; Tue, 19 Feb 2013 10:51:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+8fabbb2523c3c692ca3c+3467+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U7kn2-0007HO-HD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 10:51:12 +0000
Received: from [85.158.143.35:7173] by server-1.bemta-4.messagelabs.com id
	7A/BE-08839-F1953215; Tue, 19 Feb 2013 10:51:11 +0000
X-Env-Sender: BATV+8fabbb2523c3c692ca3c+3467+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1361271068!16112786!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTg4Njc2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12965 invoked from network); 19 Feb 2013 10:51:09 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 10:51:09 -0000
Received: from i7.infradead.org ([2001:8b0:10b:1:225:64ff:fee8:e9df])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U7kms-0002Tz-Fb; Tue, 19 Feb 2013 10:51:02 +0000
Message-ID: <1361271060.13482.184.camel@i7.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Tue, 19 Feb 2013 10:51:00 +0000
In-Reply-To: <1361269257.1051.91.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
 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: multipart/mixed; boundary="===============2277386010475716464=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2277386010475716464==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-e8OI9bhAEWM4nOrTc5Mx"


--=-e8OI9bhAEWM4nOrTc5Mx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote:
> I expect there will be some rough edges like the NV variable thing -- I
> have a feeling these will have a lot in common with qemu/KVM, since they
> would tend to interact with the "platform" (provided by qemu-dm under
> Xen) rather than processor or memory virt etc.

Well, it's mostly just storing text strings describing which device/path
to boot from. So hopefully if the flash storage itself is OK for Xen,
the rest should just work.

> For the most part the I reckon the Xen specific things will be resync
> with a recent upstream and fixup the Xen build system integration, stuff
> like that.=20

Current upstream OVMF works, AFAICT. Although as I said, I haven't even
tried booting an OS.

One thing I obviously *also* haven't tested, therefore, is *rebooting*.,
We've discovered a KVM bug on older CPUs without 'unrestricted guest'
mode, where after a reset it actually runs code from 0xffff0 and not
0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the
OVMF startup code that we *should* be running, that's kind of a problem.

If you have a similar bug, please go and fix it so I never have to
know :)

> We'd like to see PV I/O drivers at some point but that's a separate
> project in its own right I think.

If you have an option ROM for them, that might not be a high priority. I
think OVMF can thunk into INT 13h for disk access.

> > And on the subject of the NV storage... does -pflash work on qemu-xen,
> > as long as we're not actually running *code* from the device and we're
> > only using it for data storage?
>=20
> I'm not sure, I've CC'd Anthony & Stefano. Assuming the Xen machine type
> in Qemu wires it up then I don't know why it shouldn't work and if we
> don't wire it up I don't see why we couldn't.

Qemu does but not in KVM mode, because it can't *execute* from a region
and also catch writes to properly emulate flash. But for a flash device
that we *don't* execute from, because it's only used for NV storage and
not the firmware itself, that restriction isn't important. So I'll need
to fix that.

> Hvmloader might need to be tweaked to setup the e820 correctly and
> perhaps the some table or other would need to refer to it also?

Right. Haven't quite worked out how it would be 'found' by the firmware
yet. I was going to suggest making the address available via fw_cfg...
but you don't implement that.

--=20
dwmw2

--=-e8OI9bhAEWM4nOrTc5Mx
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE5MTA1MTAwWjAjBgkqhkiG9w0BCQQx
FgQUiFWNymYUbDJYIHGpYdUs4rw1tNgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQCw/TYr50oBAqNfjMozFL020eWu
aOx/CtZk7stcPIOjLYtgqlNwfht6qfP7BmjHu4ALMMqekQ4oeUdtO8vi8qcjOrri1KDMXb7JB9n4
/HIzcp6W8PlxAdFtHkShAcn6FUPYPxPl9v4dHpjbPlYXf4UE3Ek+Xa8jgn8PP0+XTiGLixe5dvmh
nucDEV+UqV1KCZfdEk9xSi82lG8zYdKG9z8CW51JTY7W8ZL/mITHeiANGB7q5sXry7P2Wj7R3Dke
D213+jAUkwm4a/RLEAkj81/6Q7neG6VPGVHDp7yCZotB8u7zAeHgg9iAb+YUo7ZX6NGmh0/B0Kpb
MUxgweHxRmC/AAAAAAAA


--=-e8OI9bhAEWM4nOrTc5Mx--



--===============2277386010475716464==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2277386010475716464==--



From xen-devel-bounces@lists.xen.org Tue Feb 19 10:51:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 10: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 1U7kn4-0007HT-DK; Tue, 19 Feb 2013 10:51:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from
	<BATV+8fabbb2523c3c692ca3c+3467+infradead.org+dwmw2@merlin.srs.infradead.org>)
	id 1U7kn2-0007HO-HD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 10:51:12 +0000
Received: from [85.158.143.35:7173] by server-1.bemta-4.messagelabs.com id
	7A/BE-08839-F1953215; Tue, 19 Feb 2013 10:51:11 +0000
X-Env-Sender: BATV+8fabbb2523c3c692ca3c+3467+infradead.org+dwmw2@merlin.s
	rs.infradead.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1361271068!16112786!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gMTg4Njc2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12965 invoked from network); 19 Feb 2013 10:51:09 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 10:51:09 -0000
Received: from i7.infradead.org ([2001:8b0:10b:1:225:64ff:fee8:e9df])
	by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1U7kms-0002Tz-Fb; Tue, 19 Feb 2013 10:51:02 +0000
Message-ID: <1361271060.13482.184.camel@i7.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Ian Campbell <ijc@hellion.org.uk>
Date: Tue, 19 Feb 2013 10:51:00 +0000
In-Reply-To: <1361269257.1051.91.camel@zakaz.uk.xensource.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
	merlin.infradead.org See http://www.infradead.org/rpr.html
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
 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: multipart/mixed; boundary="===============2277386010475716464=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2277386010475716464==
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature";
	boundary="=-e8OI9bhAEWM4nOrTc5Mx"


--=-e8OI9bhAEWM4nOrTc5Mx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote:
> I expect there will be some rough edges like the NV variable thing -- I
> have a feeling these will have a lot in common with qemu/KVM, since they
> would tend to interact with the "platform" (provided by qemu-dm under
> Xen) rather than processor or memory virt etc.

Well, it's mostly just storing text strings describing which device/path
to boot from. So hopefully if the flash storage itself is OK for Xen,
the rest should just work.

> For the most part the I reckon the Xen specific things will be resync
> with a recent upstream and fixup the Xen build system integration, stuff
> like that.=20

Current upstream OVMF works, AFAICT. Although as I said, I haven't even
tried booting an OS.

One thing I obviously *also* haven't tested, therefore, is *rebooting*.,
We've discovered a KVM bug on older CPUs without 'unrestricted guest'
mode, where after a reset it actually runs code from 0xffff0 and not
0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the
OVMF startup code that we *should* be running, that's kind of a problem.

If you have a similar bug, please go and fix it so I never have to
know :)

> We'd like to see PV I/O drivers at some point but that's a separate
> project in its own right I think.

If you have an option ROM for them, that might not be a high priority. I
think OVMF can thunk into INT 13h for disk access.

> > And on the subject of the NV storage... does -pflash work on qemu-xen,
> > as long as we're not actually running *code* from the device and we're
> > only using it for data storage?
>=20
> I'm not sure, I've CC'd Anthony & Stefano. Assuming the Xen machine type
> in Qemu wires it up then I don't know why it shouldn't work and if we
> don't wire it up I don't see why we couldn't.

Qemu does but not in KVM mode, because it can't *execute* from a region
and also catch writes to properly emulate flash. But for a flash device
that we *don't* execute from, because it's only used for NV storage and
not the firmware itself, that restriction isn't important. So I'll need
to fix that.

> Hvmloader might need to be tweaked to setup the e820 correctly and
> perhaps the some table or other would need to refer to it also?

Right. Haven't quite worked out how it would be 'found' by the firmware
yet. I was going to suggest making the address available via fw_cfg...
but you don't implement that.

--=20
dwmw2

--=-e8OI9bhAEWM4nOrTc5Mx
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUbjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHFzCCBf+g
AwIBAgIDBCZ6MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwNTAxMTI1ODI3WhcNMTMwNTAzMTEzNzIwWjBdMRkwFwYDVQQNExA4Y1VOSzUzMTc0ODRYRjk3
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYe7wo6MrtrB4uIGGbrY
4IifY/Xsq22pSv605yganL0+uyUdd8rCjrYlH6Q/ra5TVJCQFTgzaepkuqPQc79DC/Cxmzm6Qo+s
wLZy868oFsccsVokL2bPAWIPaRXfNPJKkYR1FTWQfZpWJVQmT+sPf1XFUullVBAK+d9RztopyacI
xWoZ/W/Cmv7mseQbttYTtGKJa0btX73nsQRWl6SgErWXo59zg9friCLTy1GXMXJYB8H+PtnuwX0w
MrAvWDdX1ABgIlA17W3FraCn0eW15ZM46eyu0/amGzJZNtemCWF73P7BAijzeV1jNmiJFXdZ0DT0
w+hmtMO9PxdDUyt78QIDAQABo4IDrjCCA6owCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTkfe5UOr3PcirsjApibyyUEfsyRzAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp
c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m
IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc
BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM
aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh
bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB
MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVu
dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAqDU1FKifNtCFJbLnvOi1BLRfk7mut55PMtPSZLJ4/AnG7AjmJnbBI4U5
DELwvVq3mIpwUpGqZUkqkZMEfBPIbfq517UZB3h4iANtqif+ULfTLhg5XgcK5eF8/T6EtX2c3epq
ylARdleCbj/0FwiUDvPlTsA6PIN4SCekjRLgjKERrL3heFz+Hteq1rtMAvMkNuyL0/0ijyyg2y45
NASAl2Afl9SLes/fnoh9nBwzfNQfb6qDYUFpnglfpGrq/0b1NtaOUb2z1SR+H1tKlb8bVJJIdvpu
mEi27kSRIhzk3h30uTfKkKetgy++ouyldxZ7KZ0PuoLQrBy465EoQLosETCCBxcwggX/oAMCAQIC
AwQmejANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDUw
MTEyNTgyN1oXDTEzMDUwMzExMzcyMFowXTEZMBcGA1UEDRMQOGNVTks1MzE3NDg0WEY5NzEcMBoG
A1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFk
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmHu8KOjK7aweLiBhm62OCIn2P1
7KttqUr+tOcoGpy9PrslHXfKwo62JR+kP62uU1SQkBU4M2nqZLqj0HO/QwvwsZs5ukKPrMC2cvOv
KBbHHLFaJC9mzwFiD2kV3zTySpGEdRU1kH2aViVUJk/rD39VxVLpZVQQCvnfUc7aKcmnCMVqGf1v
wpr+5rHkG7bWE7RiiWtG7V+957EEVpekoBK1l6Ofc4PX64gi08tRlzFyWAfB/j7Z7sF9MDKwL1g3
V9QAYCJQNe1txa2gp9HlteWTOOnsrtP2phsyWTbXpglhe9z+wQIo83ldYzZoiRV3WdA09MPoZrTD
vT8XQ1Mre/ECAwEAAaOCA64wggOqMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU5H3uVDq9z3Iq7IwKYm8slBH7MkcwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYB
BQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmls
aXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExp
bWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVo
dHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkG
CCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2Ew
QgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp
ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN
AQEFBQADggEBAKg1NRSonzbQhSWy57zotQS0X5O5rreeTzLT0mSyePwJxuwI5iZ2wSOFOQxC8L1a
t5iKcFKRqmVJKpGTBHwTyG36ude1GQd4eIgDbaon/lC30y4YOV4HCuXhfP0+hLV9nN3qaspQEXZX
gm4/9BcIlA7z5U7AOjyDeEgnpI0S4IyhEay94Xhc/h7Xqta7TALzJDbsi9P9Io8soNsuOTQEgJdg
H5fUi3rP356IfZwcM3zUH2+qg2FBaZ4JX6Rq6v9G9TbWjlG9s9Ukfh9bSpW/G1SSSHb6bphItu5E
kSIc5N4d9Lk3ypCnrYMvvqLspXcWeymdD7qC0KwcuOuRKEC6LBExggNvMIIDawIBATCBlDCBjDEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEJnowCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE5MTA1MTAwWjAjBgkqhkiG9w0BCQQx
FgQUiFWNymYUbDJYIHGpYdUs4rw1tNgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l
ZGlhdGUgQ2xpZW50IENBAgMEJnowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwQmejANBgkqhkiG9w0BAQEFAASCAQCw/TYr50oBAqNfjMozFL020eWu
aOx/CtZk7stcPIOjLYtgqlNwfht6qfP7BmjHu4ALMMqekQ4oeUdtO8vi8qcjOrri1KDMXb7JB9n4
/HIzcp6W8PlxAdFtHkShAcn6FUPYPxPl9v4dHpjbPlYXf4UE3Ek+Xa8jgn8PP0+XTiGLixe5dvmh
nucDEV+UqV1KCZfdEk9xSi82lG8zYdKG9z8CW51JTY7W8ZL/mITHeiANGB7q5sXry7P2Wj7R3Dke
D213+jAUkwm4a/RLEAkj81/6Q7neG6VPGVHDp7yCZotB8u7zAeHgg9iAb+YUo7ZX6NGmh0/B0Kpb
MUxgweHxRmC/AAAAAAAA


--=-e8OI9bhAEWM4nOrTc5Mx--



--===============2277386010475716464==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2277386010475716464==--



From xen-devel-bounces@lists.xen.org Tue Feb 19 11:42:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 11:42: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 1U7laX-0008HO-JY; Tue, 19 Feb 2013 11:42:21 +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 1U7laW-0008HF-K2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 11:42:20 +0000
Received: from [85.158.138.51:35552] by server-7.bemta-3.messagelabs.com id
	24/56-10367-B1563215; Tue, 19 Feb 2013 11:42:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361274138!20086675!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9144 invoked from network); 19 Feb 2013 11:42:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 11:42:18 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (josoe mo8) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f04433p1JAVcTR ;
	Tue, 19 Feb 2013 12:42:18 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 458611884C; Tue, 19 Feb 2013 12:42:17 +0100 (CET)
Date: Tue, 19 Feb 2013 12:42:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219114217.GA8133@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359983463.7743.23.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > +++ b/tools/libxl/libxl.h
> > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> >  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, uint32_t domid, int fd,
> > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> >                           int flags, /* LIBXL_SUSPEND_* */
> >                           const libxl_asyncop_how *ao_how)
> >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > +#ifdef LIBXL_API_VERSION
> > +#if LIBXL_API_VERSION == 0x040200
> > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> 
> int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                          int flags, /* LIBXL_SUSPEND_* */
>                          int max_iters, int max_factor,
>                          const libxl_asyncop_how *ao_how)
>                          LIBXL_EXTERNAL_CALLERS_ONLY;
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION == 0x040200
> #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
>             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> #endif /* LIBXL_API_VERSION == 0x040200 */
> #endif /* defined(LIBXL_API_VERSION) */
> 
> Should work?
> 
> Not sure if
> #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION == 0x040200
> works in CPP.
> 
> Maybe we should
> #ifndef LIBXL_API_VERSION
> #define LIBXL_API_VERSION LIBXL_API_VERSION_LATEST
> #endif
> ?

Here is another attempt to make use of LIBXL_API_VERSION. Two versions
just for testing. I would use the static inline variant because we code
in C, not cpp.


...
/* API compatibility. */
#ifdef LIBXL_API_VERSION
#if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300
#error Unknown LIBXL_API_VERSION
#endif
#endif

typedef struct {
    int xlflags; /* LIBXL_SUSPEND_* */
    int max_iters;
    int max_factor;
} libxl_save_properties;

int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                         const libxl_save_properties *props,
                         const libxl_asyncop_how *ao_how)
                         LIBXL_EXTERNAL_CALLERS_ONLY;
#ifdef LIBXL_API_VERSION
#if LIBXL_API_VERSION == 0x040200
#define libxl_domain_suspend(__ctx, __domid, __fd, __flags, __ao_how) \
({ \
    libxl_save_properties __props = { .xlflags = (__flags) }; \
    int __ret = libxl_domain_suspend((__ctx), (__domid), (__fd), &__props, (__ao_how)); \
    __ret; \
})
#elif LIBXL_API_VERSION == 0x040300
static inline int libxl_domain_suspend_0x040300(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, const libxl_asyncop_how *ao_how)
{
    libxl_save_properties props = { .xlflags = flags };
    return libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
}
#define libxl_domain_suspend libxl_domain_suspend_0x040300
#endif
#endif


/* cat > t.c
 * gcc -Wall -o t t.c --save-temps -g
 * -I tools/libxc -I tools/libxl
 * -Ltools/libxc -L tools/libxl -lxenlight
 * -Wl,-rpath,$PWD/tools/libxc,-rpath,$PWD/tools/libxl
 */
#define LIBXL_API_VERSION  0x040300

#include "tools/libxl/libxl.h"

int main(void)
{
	int ret;
#if LIBXL_API_VERSION == 0x040200
	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
#elif LIBXL_API_VERSION == 0x040300
	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
#else
	ret = libxl_domain_suspend(NULL, 0, 0, NULL, NULL);
#endif
	return ret;
}


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 11:42:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 11:42: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 1U7laX-0008HO-JY; Tue, 19 Feb 2013 11:42:21 +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 1U7laW-0008HF-K2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 11:42:20 +0000
Received: from [85.158.138.51:35552] by server-7.bemta-3.messagelabs.com id
	24/56-10367-B1563215; Tue, 19 Feb 2013 11:42:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361274138!20086675!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9144 invoked from network); 19 Feb 2013 11:42:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 11:42:18 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (josoe mo8) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f04433p1JAVcTR ;
	Tue, 19 Feb 2013 12:42:18 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 458611884C; Tue, 19 Feb 2013 12:42:17 +0100 (CET)
Date: Tue, 19 Feb 2013 12:42:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219114217.GA8133@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1359983463.7743.23.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 04, Ian Campbell wrote:

> On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > +++ b/tools/libxl/libxl.h
> > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> >  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, uint32_t domid, int fd,
> > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> >                           int flags, /* LIBXL_SUSPEND_* */
> >                           const libxl_asyncop_how *ao_how)
> >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > +#ifdef LIBXL_API_VERSION
> > +#if LIBXL_API_VERSION == 0x040200
> > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> 
> int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                          int flags, /* LIBXL_SUSPEND_* */
>                          int max_iters, int max_factor,
>                          const libxl_asyncop_how *ao_how)
>                          LIBXL_EXTERNAL_CALLERS_ONLY;
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION == 0x040200
> #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
>             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> #endif /* LIBXL_API_VERSION == 0x040200 */
> #endif /* defined(LIBXL_API_VERSION) */
> 
> Should work?
> 
> Not sure if
> #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION == 0x040200
> works in CPP.
> 
> Maybe we should
> #ifndef LIBXL_API_VERSION
> #define LIBXL_API_VERSION LIBXL_API_VERSION_LATEST
> #endif
> ?

Here is another attempt to make use of LIBXL_API_VERSION. Two versions
just for testing. I would use the static inline variant because we code
in C, not cpp.


...
/* API compatibility. */
#ifdef LIBXL_API_VERSION
#if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300
#error Unknown LIBXL_API_VERSION
#endif
#endif

typedef struct {
    int xlflags; /* LIBXL_SUSPEND_* */
    int max_iters;
    int max_factor;
} libxl_save_properties;

int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
                         const libxl_save_properties *props,
                         const libxl_asyncop_how *ao_how)
                         LIBXL_EXTERNAL_CALLERS_ONLY;
#ifdef LIBXL_API_VERSION
#if LIBXL_API_VERSION == 0x040200
#define libxl_domain_suspend(__ctx, __domid, __fd, __flags, __ao_how) \
({ \
    libxl_save_properties __props = { .xlflags = (__flags) }; \
    int __ret = libxl_domain_suspend((__ctx), (__domid), (__fd), &__props, (__ao_how)); \
    __ret; \
})
#elif LIBXL_API_VERSION == 0x040300
static inline int libxl_domain_suspend_0x040300(libxl_ctx *ctx, uint32_t domid, int fd,
                          int flags, const libxl_asyncop_how *ao_how)
{
    libxl_save_properties props = { .xlflags = flags };
    return libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
}
#define libxl_domain_suspend libxl_domain_suspend_0x040300
#endif
#endif


/* cat > t.c
 * gcc -Wall -o t t.c --save-temps -g
 * -I tools/libxc -I tools/libxl
 * -Ltools/libxc -L tools/libxl -lxenlight
 * -Wl,-rpath,$PWD/tools/libxc,-rpath,$PWD/tools/libxl
 */
#define LIBXL_API_VERSION  0x040300

#include "tools/libxl/libxl.h"

int main(void)
{
	int ret;
#if LIBXL_API_VERSION == 0x040200
	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
#elif LIBXL_API_VERSION == 0x040300
	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
#else
	ret = libxl_domain_suspend(NULL, 0, 0, NULL, NULL);
#endif
	return ret;
}


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 11:48:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 11: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 1U7lgW-00009l-Kp; Tue, 19 Feb 2013 11:48:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7lgV-00009e-1A
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 11:48:31 +0000
Received: from [85.158.139.83:20555] by server-16.bemta-5.messagelabs.com id
	F9/3A-14948-E8663215; Tue, 19 Feb 2013 11:48:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361274453!24037106!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7837 invoked from network); 19 Feb 2013 11:47:35 -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;
	19 Feb 2013 11:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7737199"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 11:47:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 06:47:33 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U7lfY-0006JF-Vl;
	Tue, 19 Feb 2013 11:47:32 +0000
Message-ID: <51236654.3050709@citrix.com>
Date: Tue, 19 Feb 2013 11:47:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
In-Reply-To: <512353E502000078000BF521@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTkvMDIvMTMgMDk6MjgsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDE4LjAyLjEzIGF0
IDE5OjExLCBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiB3cm90ZToK
Pj4gSGVsbG8sCj4+Cj4+IE91ciB0ZXN0aW5nIGhhcyBkaXNjb3ZlcmVkIGEgY3Jhc2ggKHBhZ2Vm
YXVsdCBhdCAweDAwMDAwMDAwMDAwMDAwMDgpCj4+IHdoaWNoIEkgaGF2ZSB0cmFja2VkIGRvd24g
dG8gYmFkIF9fcnVucV9yZW1vdmUoKSBpbiBjc2NoZWRfdmNwdV9zbGVlcCgpCj4+IGluIHNjaGVk
X2NyZWRpdC5jIChiZWNhdXNlIGEgc3RhdGljIGZ1bmN0aW9uIG9mIHRoZSBzYW1lIG5hbWUgYWxz
bwo+PiBleGlzdHMgaW4gc2NoZWRfY3JlZGl0Mi5jLCB3aGljaCBjb25mdXNlZCBtYXR0ZXJzIHRv
IHN0YXJ0IHdpdGgpCj4+Cj4+IFRoZSB0ZXN0IGNhc2Ugd2FzIGEgbG9vcCBvZiBsb2NhbGhvc3Qg
bWlncmF0ZSBvZiBhIDF2Y3B1IEhWTSB3aW44Cj4+IGRvbWFpbi4gIFRoZSB0ZXN0IGNhc2UgaXRz
ZWxmIGhhcyBwYXNzZWQgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCBvbiB0aGUKPj4gc2FtZSBYZW4g
Y29kZWJhc2UgKFhlbi00LjEuMyksIGluZGljYXRpbmcgdGhhdCBpdCBpcyB2ZXJ5IHJhcmUuICBU
aGVyZQo+PiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYW55IHJlbGV2YW50IGNoYW5nZXMgYmV0d2Vl
biB0aGUgdmVyc2lvbiBvZiBYZW4gaW4KPj4gdGhlIHRlc3QgYW5kIHhlbi00LjEtdGVzdGluZy4K
Pj4KPj4gVGhlIGZhaWx1cmUgaXRzZWxmIGlzIGJlY2F1c2Ugb2YgYSBYRU5fRE9NQ1RMX3NjaGVk
dWxlcl9vcCAodHJhY2UgYmVsb3cpCj4+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBWQ1BVIG9m
IHRoZSBtaWdyYXRpbmcgZG9tYWluLgo+Pgo+PiAoWEVOKSBYZW4gY2FsbCB0cmFjZToKPj4gKFhF
TikgICAgICAgWzxmZmZmODJjNDgwMTE2YTE0Pl0gY3NjaGVkX3ZjcHVfc2xlZXArMHg0NC8weDcw
Cj4+IChYRU4pICAgICAgMFs8ZmZmZjgyYzQ4MDEyMDExNz5dIHZjcHVfc2xlZXBfbm9zeW5jKzB4
ZTcvMHgzYjAKPj4gKFhFTikgICAgIDEyWzxmZmZmODJjNDgwMTIwM2U5Pl0gdmNwdV9zbGVlcF9z
eW5jKzB4OS8weDUwCj4+IChYRU4pICAgICAxNFs8ZmZmZjgyYzQ4MDExZmQ0Yz5dIHNjaGVkX2Fk
anVzdCsweGFjLzB4MjMwCj4+IChYRU4pICAgICAyNFs8ZmZmZjgyYzQ4MDEwMmJjMT5dIGRvX2Rv
bWN0bCsweDczMS8weDExMzAKPj4gKFhFTikgICAgIDY0WzxmZmZmODJjNDgwMjAxM2M0Pl0gY29t
cGF0X2h5cGVyY2FsbCsweDc0LzB4ODAKPj4KPj4gVGhlIHJlbGV2YW50IHBhcnQgb2YgY3NjaGVk
X3ZjcHVfc2xlZXAoKSBpcwo+Pgo+PiAgICAgZWxzZSBpZiAoIF9fdmNwdV9vbl9ydW5xKHN2Yykg
KQo+PiAgICAgICAgIF9fcnVucV9yZW1vdmUoc3ZjKTsKPj4KPj4gd2hpY2ggZGlzYXNzZW1ibGVz
IHRvCj4+Cj4+IGZmZmY4MmM0ODAxMTZhMDE6ICAgICAgIDQ5IDhiIDEwICAgICAgICAgICAgICAg
IG1vdiAgICAoJXI4KSwlcmR4Cj4+IGZmZmY4MmM0ODAxMTZhMDQ6ICAgICAgIDRjIDM5IGMyICAg
ICAgICAgICAgICAgIGNtcCAgICAlcjgsJXJkeAo+PiBmZmZmODJjNDgwMTE2YTA3OiAgICAgICA3
NSAwNyAgICAgICAgICAgICAgICAgICBqbmUgICAgZmZmZjgyYzQ4MDExNmExMAo+PiA8Y3NjaGVk
X3ZjcHVfc2xlZXArMHg0MD4KPj4gZmZmZjgyYzQ4MDExNmEwOTogICAgICAgZjMgYzMgICAgICAg
ICAgICAgICAgICAgcmVweiByZXRxCj4+IGZmZmY4MmM0ODAxMTZhMGI6ICAgICAgIDBmIDFmIDQ0
IDAwIDAwICAgICAgICAgIG5vcGwgICAweDAoJXJheCwlcmF4LDEpCj4+IGZmZmY4MmM0ODAxMTZh
MTA6ICAgICAgIDQ5IDhiIDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAweDgoJXI4KSwlcmF4Cj4+
IGZmZmY4MmM0ODAxMTZhMTQ6ICAgICAgIDQ4IDg5IDQyIDA4ICAgICAgICAgICAgIG1vdiAgICAl
cmF4LDB4OCglcmR4KSAjCj4+IDwtIFBhZ2VmYXVsdCBoZXJlCj4+IGZmZmY4MmM0ODAxMTZhMTg6
ICAgICAgIDQ4IDg5IDEwICAgICAgICAgICAgICAgIG1vdiAgICAlcmR4LCglcmF4KQo+PiBmZmZm
ODJjNDgwMTE2YTFiOiAgICAgICA0ZCA4OSA0MCAwOCAgICAgICAgICAgICBtb3YgICAgJXI4LDB4
OCglcjgpCj4+IGZmZmY4MmM0ODAxMTZhMWY6ICAgICAgIDRkIDg5IDAwICAgICAgICAgICAgICAg
IG1vdiAgICAlcjgsKCVyOCkKPj4KPj4gVGhlIHJlbGV2YW50IGNyYXNoIHJlZ2lzdGVycyBmcm9t
IHRoZSBwYWdlZmF1bHQgYXJlOgo+PiByYXg6IDAwMDAwMDAwMDAwMDAwMDAKPj4gcmR4OiAwMDAw
MDAwMDAwMDAwMDAwCj4+ICByODogZmZmZjgzMDgwYzg5ZWQ5MAo+Pgo+PiBJZiBJIGFtIHJlYWRp
bmcgdGhlIGNvZGUgY29ycmVjdGx5LCB0aGlzIG1lYW5zIHRoYXQgcnVucS0+bmV4dCBpcyBOVUxM
LAo+PiBzbyB3ZSBmYWlsIGxpc3RfZW1wdHkoKSBhbmQgZXJyb25lb3VzbHkgcGFzcyBfX3ZjcHVf
b25fcnVucSgpLiAgV2UgdGhlbgo+PiBmYWlsIHdpdGggYSBmYXVsdCB3aGVuIHRyeWluZyB0byB1
cGRhdGUgcnVucS0+cHJldiwgd2hpY2ggaXMgYWxzbyBOVUxMLgo+Pgo+PiBUaGUgb25seSBwbGFj
ZSBJIGNhbiBzcG90IGluIHRoZSBjb2RlIHdoZXJlIHRoZSBydW5xLT57bmV4dCxwcmV2fSBjb3Vs
ZAo+PiBjb25jZWl2YWJseSBiZSBOVUxMIGlzIGluIGNzY2hlZF9hbGxvY192ZGF0YSgpIGJldHdl
ZW4gdGhlIG1lbXNldCgpIGFuZAo+PiBJTklUX0xJU1RfSEVBRCgpLiAgVGhpcyBpcyBsb2dpY2Fs
bHkgc2Vuc2libGUgaW4gY29tYmluYXRpb24gd2l0aCB0aGUKPj4gbG9jYWxob3N0IG1pZ3JhdGUg
bG9vcCwgYW5kIEkgY2FudCBpbW1lZGlhdGVseSBzZWUgYW55dGhpbmcgdG8gcHJldmVudAo+PiB0
aGlzIHJhY2UgaGFwcGVuaW5nLgo+IEJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVk
X2FsbG9jX3ZkYXRhKCkgZG9lc24ndCBzdG9yZQo+IHN2YyBpbnRvIHZjLT5zY2hlZF9wcml2OyB0
aGF0J3MgYmVpbmcgZG9uZSBieSB0aGUgZ2VuZXJpYwo+IHNjaGVkdWxlciBjb2RlIG9uY2UgdGhl
IGFjdG9yIHJldHVybnMuCgpEJ29oIHllcyAtIEkgb3Zlcmxvb2tlZCB0aGF0LgoKPgo+IFNvIEkn
ZCByYXRoZXIgc3VzcGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwgd2hpY2ggaXMgZWFz
aWx5Cj4gcG9zc2libGUgd2hlbiByYWNpbmcgd2l0aCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyBv
cHBvc2VkIHRvCj4gc2NoZWR1bGVfY3B1X3N3aXRjaCgpLCB3aGVyZSB0aGUgbmV3IHBvaW50ZXIg
Z2V0cyBzdG9yZWQKPiBfYmVmb3JlXyBkZS1hbGxvY2F0aW5nIHRoZSBvbGQgb25lKS4KCj4KPiBI
b3dldmVyLCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyB3ZWxsIGFzIHNjaGVkdWxlX2NwdV9zd2l0
Y2goKSkKPiBnZXQgY2FsbGVkIG9ubHkgZnJvbSBDUFUgcG9vbHMgY29kZSwgYW5kIEkgd291bGQg
Z3Vlc3MgQ1BVIHBvb2xzCj4gYXJlbid0IGludm9sdmVkIGhlcmUsIGFuZCB5b3UgZG9uJ3QgaW4g
cGFyYWxsZWwgc29mdCBvZmZsaW5lL29ubGluZQo+IHBDUFUtcyAoYXMgSSdtIHN1cmUgeW91IG90
aGVyd2lzZSB3b3VsZCBoYXZlIG1lbnRpb25lZCBpdCkuCj4KPiBCdXQgd2FpdCAtIGxpYnhsX19k
b21haW5fbWFrZSgpIF91bmNvbmRpdGlvbmFsbHlfIGNhbGxzCj4geGNfY3B1cG9vbF9tb3ZlZG9t
YWluKCksIGFzIGRvZXMgWGVuZERvbWFpbkluZm8ncwo+IF9jb25zdHJ1Y3REb21haW4oKS4gVGhl
IHJlYXNvbiBmb3IgdGhpcyBlc2NhcGVzIG1lIC0gSsO8cmdlbj8gWWV0Cj4gSSdkIGV4cGVjdCB0
aGUgcG9vbCBJRCBtYXRjaGluZyBjaGVjayB0byBzaG9ydCBjdXQgdGhlIHJlc3VsdGluZwo+IHN5
c2N0bCwgaS5lLiBzY2hlZF9tb3ZlX2RvbWFpbigpIG91Z2h0IHRvIG5vdCBiZSByZWFjaGVkIGFu
eXdheQo+ICh3b3J0aCB2ZXJpZnlpbmcgb2YgY291cnNlKS4KPgo+IFRoZSByYWNlIHRoZXJlIG5l
dmVydGhlbGVzcyBvdWdodCB0byBiZSBmaXhlZC4KPgo+IEphbgoKT3VyIHRvb2xzdGFjayBob29r
cyBkaXJlY3RseSBpbnRvIGxpYnhjIGFuZCBpcyBjb21wbGV0ZWx5IGlnbm9yYW50IG9mCmNwdXBv
b2xzLiAgTG9va2luZyBhdCB0aGUgY3Jhc2ggbW9yZSBjbG9zZWx5LCBpdCBtaWdodCBiZSBhIHJh
Y2UgZWxzZXdoZXJlCgpBbm90aGVyIGRvbTAgdmNwdSBpcyBpbiBhbiBIVk1PUF90cmFja19kaXJ0
eV92cmFtIGh5cGVyY2FsbCwgYW5kIHRoZQphc3NvY2lhdGVkIFhlbiBzdGFjayB0cmFjZSBpcwoK
W2ZmZmY4MmM0ODAxNzc3YjJdIHRpbWVfY2FsaWJyYXRpb25fc3RkX3JlbmRlenZvdXMrMHhiMi8w
eGMwCiBmZmZmODJjNDgwMTcyZDEyICBfX3NtcF9jYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDYy
LzB4YjAKIGZmZmY4MmM0ODAxNzMzOWUgIHNtcF9jYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDRl
LzB4OTAKIGZmZmY4MmM0ODAxNGE2NWEgIGNhbGxfZnVuY3Rpb25faW50ZXJydXB0KzB4MmEvMHgz
MAogZmZmZjgyYzQ4MDEyMjNiMiAgX3NwaW5fbG9jaysweDEyLzB4MjAKIGZmZmY4MmM0ODAxNzM0
YWIgIGZsdXNoX2FyZWFfbWFzaysweGNiLzB4MWMwCiBmZmZmODJjNDgwMWM4NjJhICBwYWdpbmdf
bG9nX2RpcnR5X3JhbmdlKzB4M2EvMHg3ODAKIGZmZmY4MmM0ODAxMjFlYTggIGNwdW1hc2tfcmFp
c2Vfc29mdGlycSsweDc4LzB4ODAKIGZmZmY4MmM0ODAxMTdlZDMgIGNzY2hlZF92Y3B1X3dha2Ur
MHgxOTMvMHg0MjAKIGZmZmY4MmM0ODAxNGE1ZmEgIGV2ZW50X2NoZWNrX2ludGVycnVwdCsweDJh
LzB4MzAKIGZmZmY4MmM0ODAxZjIxYzcgIGhhcF90cmFja19kaXJ0eV92cmFtKzB4MTM3LzB4MWMw
CiBmZmZmODJjNDgwMWFkM2ZkICBkb19odm1fb3ArMHgxNmRkLzB4MWY1MAogZmZmZjgyYzQ4MDEw
NjI1MSAgZXZ0Y2huX3NlbmQrMHhhMS8weDE2MAogZmZmZjgyYzQ4MDEwNmQzNiAgZG9fZXZlbnRf
Y2hhbm5lbF9vcCsweDg3Ni8weGZkMAogZmZmZjgyYzQ4MDFmOTAyNyAgY29tcGF0X3VwZGF0ZV9k
ZXNjcmlwdG9yKzB4MjcvMHgzMAogZmZmZjgyYzQ4MDEzNTRmOCAgY29tcGF0X211bHRpY2FsbCsw
eDE5OC8weDM4MAogZmZmZjgyYzQ4MDE0YTVmYSAgZXZlbnRfY2hlY2tfaW50ZXJydXB0KzB4MmEv
MHgzMAogZmZmZjgyYzQ4MDIwMTNjNCAgY29tcGF0X2h5cGVyY2FsbCsweDc0LzB4ODAKCnRoZSBo
YXBfdHJhY2tfZGlydHlfdnJhbSgpIGFuZCBwYWdpbmdfbG9nX2RpcnR5X3JhbmdlKCkgYXJlIHBh
cnQgb2YgdGhlCnNhbWUgbG9naWNhbCBjYWxsIHRyYWNlLCBidXQgaXQgYXBwZWFycyB0aGF0IHdl
IGhhdmUgdGFrZW4gYW4KZXZlbnRfY2hlY2tfaW50ZXJydXB0KCkgaW4gdGhlIG1pZGRsZSBhbmQg
Y2FsbGVkIHNjaGVkdWxlKCkgb2ZmIHRoZQpib3R0b20gb2YgaXQsIGNhbGxpbmcgY3NjaGVkX3Zj
cHVfd2FrZSgpLgoKSSBhbSBjdXJyZW50bHkgdHJ5aW5nIHRvIHJlYXNvbiBhcyB0byB3aGV0aGVy
IGl0IGlzIHBvc3NpYmxlIGZvciBhIHJhY2UKYmV0d2VlbiBjc2NoZWRfdmNwdV97c2xlZXAsd2Fr
ZX0oKSBjb3VsZCByZXN1bHQgaW4gdGhlIHNlZW4gY3Jhc2gsIGJ1dAppdCBjZXJ0YWlubHkgbG9v
a3MgbGlrZSBhIHNtb2tpbmcgZ3VuLgoKfkFuZHJldwoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 19 11:48:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 11: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 1U7lgW-00009l-Kp; Tue, 19 Feb 2013 11:48:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7lgV-00009e-1A
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 11:48:31 +0000
Received: from [85.158.139.83:20555] by server-16.bemta-5.messagelabs.com id
	F9/3A-14948-E8663215; Tue, 19 Feb 2013 11:48:30 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361274453!24037106!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7837 invoked from network); 19 Feb 2013 11:47:35 -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;
	19 Feb 2013 11:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7737199"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 11:47:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 06:47:33 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U7lfY-0006JF-Vl;
	Tue, 19 Feb 2013 11:47:32 +0000
Message-ID: <51236654.3050709@citrix.com>
Date: Tue, 19 Feb 2013 11:47:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
In-Reply-To: <512353E502000078000BF521@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMTkvMDIvMTMgMDk6MjgsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDE4LjAyLjEzIGF0
IDE5OjExLCBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiB3cm90ZToK
Pj4gSGVsbG8sCj4+Cj4+IE91ciB0ZXN0aW5nIGhhcyBkaXNjb3ZlcmVkIGEgY3Jhc2ggKHBhZ2Vm
YXVsdCBhdCAweDAwMDAwMDAwMDAwMDAwMDgpCj4+IHdoaWNoIEkgaGF2ZSB0cmFja2VkIGRvd24g
dG8gYmFkIF9fcnVucV9yZW1vdmUoKSBpbiBjc2NoZWRfdmNwdV9zbGVlcCgpCj4+IGluIHNjaGVk
X2NyZWRpdC5jIChiZWNhdXNlIGEgc3RhdGljIGZ1bmN0aW9uIG9mIHRoZSBzYW1lIG5hbWUgYWxz
bwo+PiBleGlzdHMgaW4gc2NoZWRfY3JlZGl0Mi5jLCB3aGljaCBjb25mdXNlZCBtYXR0ZXJzIHRv
IHN0YXJ0IHdpdGgpCj4+Cj4+IFRoZSB0ZXN0IGNhc2Ugd2FzIGEgbG9vcCBvZiBsb2NhbGhvc3Qg
bWlncmF0ZSBvZiBhIDF2Y3B1IEhWTSB3aW44Cj4+IGRvbWFpbi4gIFRoZSB0ZXN0IGNhc2UgaXRz
ZWxmIGhhcyBwYXNzZWQgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCBvbiB0aGUKPj4gc2FtZSBYZW4g
Y29kZWJhc2UgKFhlbi00LjEuMyksIGluZGljYXRpbmcgdGhhdCBpdCBpcyB2ZXJ5IHJhcmUuICBU
aGVyZQo+PiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYW55IHJlbGV2YW50IGNoYW5nZXMgYmV0d2Vl
biB0aGUgdmVyc2lvbiBvZiBYZW4gaW4KPj4gdGhlIHRlc3QgYW5kIHhlbi00LjEtdGVzdGluZy4K
Pj4KPj4gVGhlIGZhaWx1cmUgaXRzZWxmIGlzIGJlY2F1c2Ugb2YgYSBYRU5fRE9NQ1RMX3NjaGVk
dWxlcl9vcCAodHJhY2UgYmVsb3cpCj4+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBWQ1BVIG9m
IHRoZSBtaWdyYXRpbmcgZG9tYWluLgo+Pgo+PiAoWEVOKSBYZW4gY2FsbCB0cmFjZToKPj4gKFhF
TikgICAgICAgWzxmZmZmODJjNDgwMTE2YTE0Pl0gY3NjaGVkX3ZjcHVfc2xlZXArMHg0NC8weDcw
Cj4+IChYRU4pICAgICAgMFs8ZmZmZjgyYzQ4MDEyMDExNz5dIHZjcHVfc2xlZXBfbm9zeW5jKzB4
ZTcvMHgzYjAKPj4gKFhFTikgICAgIDEyWzxmZmZmODJjNDgwMTIwM2U5Pl0gdmNwdV9zbGVlcF9z
eW5jKzB4OS8weDUwCj4+IChYRU4pICAgICAxNFs8ZmZmZjgyYzQ4MDExZmQ0Yz5dIHNjaGVkX2Fk
anVzdCsweGFjLzB4MjMwCj4+IChYRU4pICAgICAyNFs8ZmZmZjgyYzQ4MDEwMmJjMT5dIGRvX2Rv
bWN0bCsweDczMS8weDExMzAKPj4gKFhFTikgICAgIDY0WzxmZmZmODJjNDgwMjAxM2M0Pl0gY29t
cGF0X2h5cGVyY2FsbCsweDc0LzB4ODAKPj4KPj4gVGhlIHJlbGV2YW50IHBhcnQgb2YgY3NjaGVk
X3ZjcHVfc2xlZXAoKSBpcwo+Pgo+PiAgICAgZWxzZSBpZiAoIF9fdmNwdV9vbl9ydW5xKHN2Yykg
KQo+PiAgICAgICAgIF9fcnVucV9yZW1vdmUoc3ZjKTsKPj4KPj4gd2hpY2ggZGlzYXNzZW1ibGVz
IHRvCj4+Cj4+IGZmZmY4MmM0ODAxMTZhMDE6ICAgICAgIDQ5IDhiIDEwICAgICAgICAgICAgICAg
IG1vdiAgICAoJXI4KSwlcmR4Cj4+IGZmZmY4MmM0ODAxMTZhMDQ6ICAgICAgIDRjIDM5IGMyICAg
ICAgICAgICAgICAgIGNtcCAgICAlcjgsJXJkeAo+PiBmZmZmODJjNDgwMTE2YTA3OiAgICAgICA3
NSAwNyAgICAgICAgICAgICAgICAgICBqbmUgICAgZmZmZjgyYzQ4MDExNmExMAo+PiA8Y3NjaGVk
X3ZjcHVfc2xlZXArMHg0MD4KPj4gZmZmZjgyYzQ4MDExNmEwOTogICAgICAgZjMgYzMgICAgICAg
ICAgICAgICAgICAgcmVweiByZXRxCj4+IGZmZmY4MmM0ODAxMTZhMGI6ICAgICAgIDBmIDFmIDQ0
IDAwIDAwICAgICAgICAgIG5vcGwgICAweDAoJXJheCwlcmF4LDEpCj4+IGZmZmY4MmM0ODAxMTZh
MTA6ICAgICAgIDQ5IDhiIDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAweDgoJXI4KSwlcmF4Cj4+
IGZmZmY4MmM0ODAxMTZhMTQ6ICAgICAgIDQ4IDg5IDQyIDA4ICAgICAgICAgICAgIG1vdiAgICAl
cmF4LDB4OCglcmR4KSAjCj4+IDwtIFBhZ2VmYXVsdCBoZXJlCj4+IGZmZmY4MmM0ODAxMTZhMTg6
ICAgICAgIDQ4IDg5IDEwICAgICAgICAgICAgICAgIG1vdiAgICAlcmR4LCglcmF4KQo+PiBmZmZm
ODJjNDgwMTE2YTFiOiAgICAgICA0ZCA4OSA0MCAwOCAgICAgICAgICAgICBtb3YgICAgJXI4LDB4
OCglcjgpCj4+IGZmZmY4MmM0ODAxMTZhMWY6ICAgICAgIDRkIDg5IDAwICAgICAgICAgICAgICAg
IG1vdiAgICAlcjgsKCVyOCkKPj4KPj4gVGhlIHJlbGV2YW50IGNyYXNoIHJlZ2lzdGVycyBmcm9t
IHRoZSBwYWdlZmF1bHQgYXJlOgo+PiByYXg6IDAwMDAwMDAwMDAwMDAwMDAKPj4gcmR4OiAwMDAw
MDAwMDAwMDAwMDAwCj4+ICByODogZmZmZjgzMDgwYzg5ZWQ5MAo+Pgo+PiBJZiBJIGFtIHJlYWRp
bmcgdGhlIGNvZGUgY29ycmVjdGx5LCB0aGlzIG1lYW5zIHRoYXQgcnVucS0+bmV4dCBpcyBOVUxM
LAo+PiBzbyB3ZSBmYWlsIGxpc3RfZW1wdHkoKSBhbmQgZXJyb25lb3VzbHkgcGFzcyBfX3ZjcHVf
b25fcnVucSgpLiAgV2UgdGhlbgo+PiBmYWlsIHdpdGggYSBmYXVsdCB3aGVuIHRyeWluZyB0byB1
cGRhdGUgcnVucS0+cHJldiwgd2hpY2ggaXMgYWxzbyBOVUxMLgo+Pgo+PiBUaGUgb25seSBwbGFj
ZSBJIGNhbiBzcG90IGluIHRoZSBjb2RlIHdoZXJlIHRoZSBydW5xLT57bmV4dCxwcmV2fSBjb3Vs
ZAo+PiBjb25jZWl2YWJseSBiZSBOVUxMIGlzIGluIGNzY2hlZF9hbGxvY192ZGF0YSgpIGJldHdl
ZW4gdGhlIG1lbXNldCgpIGFuZAo+PiBJTklUX0xJU1RfSEVBRCgpLiAgVGhpcyBpcyBsb2dpY2Fs
bHkgc2Vuc2libGUgaW4gY29tYmluYXRpb24gd2l0aCB0aGUKPj4gbG9jYWxob3N0IG1pZ3JhdGUg
bG9vcCwgYW5kIEkgY2FudCBpbW1lZGlhdGVseSBzZWUgYW55dGhpbmcgdG8gcHJldmVudAo+PiB0
aGlzIHJhY2UgaGFwcGVuaW5nLgo+IEJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVk
X2FsbG9jX3ZkYXRhKCkgZG9lc24ndCBzdG9yZQo+IHN2YyBpbnRvIHZjLT5zY2hlZF9wcml2OyB0
aGF0J3MgYmVpbmcgZG9uZSBieSB0aGUgZ2VuZXJpYwo+IHNjaGVkdWxlciBjb2RlIG9uY2UgdGhl
IGFjdG9yIHJldHVybnMuCgpEJ29oIHllcyAtIEkgb3Zlcmxvb2tlZCB0aGF0LgoKPgo+IFNvIEkn
ZCByYXRoZXIgc3VzcGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwgd2hpY2ggaXMgZWFz
aWx5Cj4gcG9zc2libGUgd2hlbiByYWNpbmcgd2l0aCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyBv
cHBvc2VkIHRvCj4gc2NoZWR1bGVfY3B1X3N3aXRjaCgpLCB3aGVyZSB0aGUgbmV3IHBvaW50ZXIg
Z2V0cyBzdG9yZWQKPiBfYmVmb3JlXyBkZS1hbGxvY2F0aW5nIHRoZSBvbGQgb25lKS4KCj4KPiBI
b3dldmVyLCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyB3ZWxsIGFzIHNjaGVkdWxlX2NwdV9zd2l0
Y2goKSkKPiBnZXQgY2FsbGVkIG9ubHkgZnJvbSBDUFUgcG9vbHMgY29kZSwgYW5kIEkgd291bGQg
Z3Vlc3MgQ1BVIHBvb2xzCj4gYXJlbid0IGludm9sdmVkIGhlcmUsIGFuZCB5b3UgZG9uJ3QgaW4g
cGFyYWxsZWwgc29mdCBvZmZsaW5lL29ubGluZQo+IHBDUFUtcyAoYXMgSSdtIHN1cmUgeW91IG90
aGVyd2lzZSB3b3VsZCBoYXZlIG1lbnRpb25lZCBpdCkuCj4KPiBCdXQgd2FpdCAtIGxpYnhsX19k
b21haW5fbWFrZSgpIF91bmNvbmRpdGlvbmFsbHlfIGNhbGxzCj4geGNfY3B1cG9vbF9tb3ZlZG9t
YWluKCksIGFzIGRvZXMgWGVuZERvbWFpbkluZm8ncwo+IF9jb25zdHJ1Y3REb21haW4oKS4gVGhl
IHJlYXNvbiBmb3IgdGhpcyBlc2NhcGVzIG1lIC0gSsO8cmdlbj8gWWV0Cj4gSSdkIGV4cGVjdCB0
aGUgcG9vbCBJRCBtYXRjaGluZyBjaGVjayB0byBzaG9ydCBjdXQgdGhlIHJlc3VsdGluZwo+IHN5
c2N0bCwgaS5lLiBzY2hlZF9tb3ZlX2RvbWFpbigpIG91Z2h0IHRvIG5vdCBiZSByZWFjaGVkIGFu
eXdheQo+ICh3b3J0aCB2ZXJpZnlpbmcgb2YgY291cnNlKS4KPgo+IFRoZSByYWNlIHRoZXJlIG5l
dmVydGhlbGVzcyBvdWdodCB0byBiZSBmaXhlZC4KPgo+IEphbgoKT3VyIHRvb2xzdGFjayBob29r
cyBkaXJlY3RseSBpbnRvIGxpYnhjIGFuZCBpcyBjb21wbGV0ZWx5IGlnbm9yYW50IG9mCmNwdXBv
b2xzLiAgTG9va2luZyBhdCB0aGUgY3Jhc2ggbW9yZSBjbG9zZWx5LCBpdCBtaWdodCBiZSBhIHJh
Y2UgZWxzZXdoZXJlCgpBbm90aGVyIGRvbTAgdmNwdSBpcyBpbiBhbiBIVk1PUF90cmFja19kaXJ0
eV92cmFtIGh5cGVyY2FsbCwgYW5kIHRoZQphc3NvY2lhdGVkIFhlbiBzdGFjayB0cmFjZSBpcwoK
W2ZmZmY4MmM0ODAxNzc3YjJdIHRpbWVfY2FsaWJyYXRpb25fc3RkX3JlbmRlenZvdXMrMHhiMi8w
eGMwCiBmZmZmODJjNDgwMTcyZDEyICBfX3NtcF9jYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDYy
LzB4YjAKIGZmZmY4MmM0ODAxNzMzOWUgIHNtcF9jYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDRl
LzB4OTAKIGZmZmY4MmM0ODAxNGE2NWEgIGNhbGxfZnVuY3Rpb25faW50ZXJydXB0KzB4MmEvMHgz
MAogZmZmZjgyYzQ4MDEyMjNiMiAgX3NwaW5fbG9jaysweDEyLzB4MjAKIGZmZmY4MmM0ODAxNzM0
YWIgIGZsdXNoX2FyZWFfbWFzaysweGNiLzB4MWMwCiBmZmZmODJjNDgwMWM4NjJhICBwYWdpbmdf
bG9nX2RpcnR5X3JhbmdlKzB4M2EvMHg3ODAKIGZmZmY4MmM0ODAxMjFlYTggIGNwdW1hc2tfcmFp
c2Vfc29mdGlycSsweDc4LzB4ODAKIGZmZmY4MmM0ODAxMTdlZDMgIGNzY2hlZF92Y3B1X3dha2Ur
MHgxOTMvMHg0MjAKIGZmZmY4MmM0ODAxNGE1ZmEgIGV2ZW50X2NoZWNrX2ludGVycnVwdCsweDJh
LzB4MzAKIGZmZmY4MmM0ODAxZjIxYzcgIGhhcF90cmFja19kaXJ0eV92cmFtKzB4MTM3LzB4MWMw
CiBmZmZmODJjNDgwMWFkM2ZkICBkb19odm1fb3ArMHgxNmRkLzB4MWY1MAogZmZmZjgyYzQ4MDEw
NjI1MSAgZXZ0Y2huX3NlbmQrMHhhMS8weDE2MAogZmZmZjgyYzQ4MDEwNmQzNiAgZG9fZXZlbnRf
Y2hhbm5lbF9vcCsweDg3Ni8weGZkMAogZmZmZjgyYzQ4MDFmOTAyNyAgY29tcGF0X3VwZGF0ZV9k
ZXNjcmlwdG9yKzB4MjcvMHgzMAogZmZmZjgyYzQ4MDEzNTRmOCAgY29tcGF0X211bHRpY2FsbCsw
eDE5OC8weDM4MAogZmZmZjgyYzQ4MDE0YTVmYSAgZXZlbnRfY2hlY2tfaW50ZXJydXB0KzB4MmEv
MHgzMAogZmZmZjgyYzQ4MDIwMTNjNCAgY29tcGF0X2h5cGVyY2FsbCsweDc0LzB4ODAKCnRoZSBo
YXBfdHJhY2tfZGlydHlfdnJhbSgpIGFuZCBwYWdpbmdfbG9nX2RpcnR5X3JhbmdlKCkgYXJlIHBh
cnQgb2YgdGhlCnNhbWUgbG9naWNhbCBjYWxsIHRyYWNlLCBidXQgaXQgYXBwZWFycyB0aGF0IHdl
IGhhdmUgdGFrZW4gYW4KZXZlbnRfY2hlY2tfaW50ZXJydXB0KCkgaW4gdGhlIG1pZGRsZSBhbmQg
Y2FsbGVkIHNjaGVkdWxlKCkgb2ZmIHRoZQpib3R0b20gb2YgaXQsIGNhbGxpbmcgY3NjaGVkX3Zj
cHVfd2FrZSgpLgoKSSBhbSBjdXJyZW50bHkgdHJ5aW5nIHRvIHJlYXNvbiBhcyB0byB3aGV0aGVy
IGl0IGlzIHBvc3NpYmxlIGZvciBhIHJhY2UKYmV0d2VlbiBjc2NoZWRfdmNwdV97c2xlZXAsd2Fr
ZX0oKSBjb3VsZCByZXN1bHQgaW4gdGhlIHNlZW4gY3Jhc2gsIGJ1dAppdCBjZXJ0YWlubHkgbG9v
a3MgbGlrZSBhIHNtb2tpbmcgZ3VuLgoKfkFuZHJldwoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 19 11:48:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 11: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 1U7lge-0000AG-29; Tue, 19 Feb 2013 11:48: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 1U7lgc-0000A2-IX
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 11:48:38 +0000
Received: from [85.158.139.83:16318] by server-6.bemta-5.messagelabs.com id
	E9/F7-01489-59663215; Tue, 19 Feb 2013 11:48:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361274511!27909215!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20183 invoked from network); 19 Feb 2013 11:48:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 11:48:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1603893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 11:48: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.297.1;
	Tue, 19 Feb 2013 11:48:31 +0000
Message-ID: <1361274510.1051.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 19 Feb 2013 11:48:30 +0000
In-Reply-To: <20130219114217.GA8133@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130219114217.GA8133@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 11:42 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > > +++ b/tools/libxl/libxl.h
> > > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> > >  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, uint32_t domid, int fd,
> > > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> > >                           int flags, /* LIBXL_SUSPEND_* */
> > >                           const libxl_asyncop_how *ao_how)
> > >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > > +#ifdef LIBXL_API_VERSION
> > > +#if LIBXL_API_VERSION == 0x040200
> > > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> > 
> > int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> >                          int flags, /* LIBXL_SUSPEND_* */
> >                          int max_iters, int max_factor,
> >                          const libxl_asyncop_how *ao_how)
> >                          LIBXL_EXTERNAL_CALLERS_ONLY;
> > #ifdef LIBXL_API_VERSION
> > #if LIBXL_API_VERSION == 0x040200
> > #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
> >             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> > #endif /* LIBXL_API_VERSION == 0x040200 */
> > #endif /* defined(LIBXL_API_VERSION) */
> > 
> > Should work?
> > 
> > Not sure if
> > #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION == 0x040200
> > works in CPP.
> > 
> > Maybe we should
> > #ifndef LIBXL_API_VERSION
> > #define LIBXL_API_VERSION LIBXL_API_VERSION_LATEST
> > #endif
> > ?
> 
> Here is another attempt to make use of LIBXL_API_VERSION. Two versions
> just for testing. I would use the static inline variant because we code
> in C, not cpp.
> 
> 
> ...
> /* API compatibility. */
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300
> #error Unknown LIBXL_API_VERSION
> #endif
> #endif
> 
> typedef struct {
>     int xlflags; /* LIBXL_SUSPEND_* */

Why is this called "xlflags"? xl isn't the only user of this interface.

>     int max_iters;
>     int max_factor;
> } libxl_save_properties;

s/save/suspend/ to match the function it is passed to? Perhaps
libxl_domain_suspend_properties?

> int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                          const libxl_save_properties *props,
>                          const libxl_asyncop_how *ao_how)
>                          LIBXL_EXTERNAL_CALLERS_ONLY;
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION == 0x040200
> #define libxl_domain_suspend(__ctx, __domid, __fd, __flags, __ao_how) \
> ({ \
>     libxl_save_properties __props = { .xlflags = (__flags) }; \
>     int __ret = libxl_domain_suspend((__ctx), (__domid), (__fd), &__props, (__ao_how)); \
>     __ret; \
> })
> #elif LIBXL_API_VERSION == 0x040300
> static inline int libxl_domain_suspend_0x040300(libxl_ctx *ctx, uint32_t domid, int fd,
>                           int flags, const libxl_asyncop_how *ao_how)
> {
>     libxl_save_properties props = { .xlflags = flags };
>     return libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
> }
> #define libxl_domain_suspend libxl_domain_suspend_0x040300

I don't understand the need for this alternative, you are defining
version 0x040300 in this patch and in the absence of LIBXL_API_VERSION
this should therefore be the expected interface I think. We haven't
released Xen 0x040300 yet.

> #endif
> #endif
> 
> 
> /* cat > t.c
>  * gcc -Wall -o t t.c --save-temps -g
>  * -I tools/libxc -I tools/libxl
>  * -Ltools/libxc -L tools/libxl -lxenlight
>  * -Wl,-rpath,$PWD/tools/libxc,-rpath,$PWD/tools/libxl
>  */
> #define LIBXL_API_VERSION  0x040300
> 
> #include "tools/libxl/libxl.h"
> 
> int main(void)
> {
> 	int ret;
> #if LIBXL_API_VERSION == 0x040200
> 	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
> #elif LIBXL_API_VERSION == 0x040300
> 	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
> #else
> 	ret = libxl_domain_suspend(NULL, 0, 0, NULL, NULL);


> #endif
> 	return ret;
> }
> 
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 11:48:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 11: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 1U7lge-0000AG-29; Tue, 19 Feb 2013 11:48: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 1U7lgc-0000A2-IX
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 11:48:38 +0000
Received: from [85.158.139.83:16318] by server-6.bemta-5.messagelabs.com id
	E9/F7-01489-59663215; Tue, 19 Feb 2013 11:48:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361274511!27909215!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20183 invoked from network); 19 Feb 2013 11:48:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 11:48:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1603893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 11:48: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.297.1;
	Tue, 19 Feb 2013 11:48:31 +0000
Message-ID: <1361274510.1051.99.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 19 Feb 2013 11:48:30 +0000
In-Reply-To: <20130219114217.GA8133@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130219114217.GA8133@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 11:42 +0000, Olaf Hering wrote:
> On Mon, Feb 04, Ian Campbell wrote:
> 
> > On Fri, 2013-02-01 at 19:34 +0000, Olaf Hering wrote:
> > > +++ b/tools/libxl/libxl.h
> > > @@ -500,12 +500,25 @@ int libxl_domain_create_restore(libxl_ct
> > >  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, uint32_t domid, int fd,
> > > +int libxl_domain_suspend_0x040200(libxl_ctx *ctx, uint32_t domid, int fd,
> > >                           int flags, /* LIBXL_SUSPEND_* */
> > >                           const libxl_asyncop_how *ao_how)
> > >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > > +#ifdef LIBXL_API_VERSION
> > > +#if LIBXL_API_VERSION == 0x040200
> > > +#define libxl_domain_suspend libxl_domain_suspend_0x040200
> > 
> > int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> >                          int flags, /* LIBXL_SUSPEND_* */
> >                          int max_iters, int max_factor,
> >                          const libxl_asyncop_how *ao_how)
> >                          LIBXL_EXTERNAL_CALLERS_ONLY;
> > #ifdef LIBXL_API_VERSION
> > #if LIBXL_API_VERSION == 0x040200
> > #define libxl_domain_suspend(ctx, domid, fd, flags, ao_how) \
> >             libxl_domain_suspend(ctx, domid, fd, flags, 0, 0, ao_how) 
> > #endif /* LIBXL_API_VERSION == 0x040200 */
> > #endif /* defined(LIBXL_API_VERSION) */
> > 
> > Should work?
> > 
> > Not sure if
> > #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION == 0x040200
> > works in CPP.
> > 
> > Maybe we should
> > #ifndef LIBXL_API_VERSION
> > #define LIBXL_API_VERSION LIBXL_API_VERSION_LATEST
> > #endif
> > ?
> 
> Here is another attempt to make use of LIBXL_API_VERSION. Two versions
> just for testing. I would use the static inline variant because we code
> in C, not cpp.
> 
> 
> ...
> /* API compatibility. */
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300
> #error Unknown LIBXL_API_VERSION
> #endif
> #endif
> 
> typedef struct {
>     int xlflags; /* LIBXL_SUSPEND_* */

Why is this called "xlflags"? xl isn't the only user of this interface.

>     int max_iters;
>     int max_factor;
> } libxl_save_properties;

s/save/suspend/ to match the function it is passed to? Perhaps
libxl_domain_suspend_properties?

> int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
>                          const libxl_save_properties *props,
>                          const libxl_asyncop_how *ao_how)
>                          LIBXL_EXTERNAL_CALLERS_ONLY;
> #ifdef LIBXL_API_VERSION
> #if LIBXL_API_VERSION == 0x040200
> #define libxl_domain_suspend(__ctx, __domid, __fd, __flags, __ao_how) \
> ({ \
>     libxl_save_properties __props = { .xlflags = (__flags) }; \
>     int __ret = libxl_domain_suspend((__ctx), (__domid), (__fd), &__props, (__ao_how)); \
>     __ret; \
> })
> #elif LIBXL_API_VERSION == 0x040300
> static inline int libxl_domain_suspend_0x040300(libxl_ctx *ctx, uint32_t domid, int fd,
>                           int flags, const libxl_asyncop_how *ao_how)
> {
>     libxl_save_properties props = { .xlflags = flags };
>     return libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
> }
> #define libxl_domain_suspend libxl_domain_suspend_0x040300

I don't understand the need for this alternative, you are defining
version 0x040300 in this patch and in the absence of LIBXL_API_VERSION
this should therefore be the expected interface I think. We haven't
released Xen 0x040300 yet.

> #endif
> #endif
> 
> 
> /* cat > t.c
>  * gcc -Wall -o t t.c --save-temps -g
>  * -I tools/libxc -I tools/libxl
>  * -Ltools/libxc -L tools/libxl -lxenlight
>  * -Wl,-rpath,$PWD/tools/libxc,-rpath,$PWD/tools/libxl
>  */
> #define LIBXL_API_VERSION  0x040300
> 
> #include "tools/libxl/libxl.h"
> 
> int main(void)
> {
> 	int ret;
> #if LIBXL_API_VERSION == 0x040200
> 	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
> #elif LIBXL_API_VERSION == 0x040300
> 	ret = libxl_domain_suspend(NULL, 0, 0, 0, NULL);
> #else
> 	ret = libxl_domain_suspend(NULL, 0, 0, NULL, NULL);


> #endif
> 	return ret;
> }
> 
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 12:10:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 12:10: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 1U7m1J-0000ql-OJ; Tue, 19 Feb 2013 12:10:01 +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 1U7m1I-0000qd-Fp
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 12:10:00 +0000
Received: from [85.158.139.83:26742] by server-5.bemta-5.messagelabs.com id
	CA/CF-11945-79B63215; Tue, 19 Feb 2013 12:09:59 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361275796!27237884!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9178 invoked from network); 19 Feb 2013 12:09:58 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Feb 2013 12:09:58 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7m12-0005hi-W2; Tue, 19 Feb 2013 23:09:45 +1100
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 id
	14.01.0438.000; Tue, 19 Feb 2013 23:09:44 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcA==
Date: Tue, 19 Feb 2013 12:09:42 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19646.007
x-tm-as-result: No--26.150000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 8 doesn't actually shut down when you tell it to... It terminates all
> sessions apart from 0 (where services live) and then hibernates, so
> 'shutdown' is actually a lot more complex and error prone than it was before.
> 

I've gotten it all working now, but the restore from hibernate (which appears to use qemu) is slow. The hibernate on a 1GB machine takes seconds but the restore takes over a minute.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 12:10:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 12:10: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 1U7m1J-0000ql-OJ; Tue, 19 Feb 2013 12:10:01 +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 1U7m1I-0000qd-Fp
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 12:10:00 +0000
Received: from [85.158.139.83:26742] by server-5.bemta-5.messagelabs.com id
	CA/CF-11945-79B63215; Tue, 19 Feb 2013 12:09:59 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361275796!27237884!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9178 invoked from network); 19 Feb 2013 12:09:58 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Feb 2013 12:09:58 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U7m12-0005hi-W2; Tue, 19 Feb 2013 23:09:45 +1100
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 id
	14.01.0438.000; Tue, 19 Feb 2013 23:09:44 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcA==
Date: Tue, 19 Feb 2013 12:09:42 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19646.007
x-tm-as-result: No--26.150000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 8 doesn't actually shut down when you tell it to... It terminates all
> sessions apart from 0 (where services live) and then hibernates, so
> 'shutdown' is actually a lot more complex and error prone than it was before.
> 

I've gotten it all working now, but the restore from hibernate (which appears to use qemu) is slow. The hibernate on a 1GB machine takes seconds but the restore takes over a minute.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:16: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 1U7n3b-0001eQ-JN; Tue, 19 Feb 2013 13:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3a-0001e7-2e
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:26 +0000
Received: from [85.158.138.51:55227] by server-2.bemta-3.messagelabs.com id
	18/A6-25961-92B73215; Tue, 19 Feb 2013 13:16:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361279784!19297795!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7118 invoked from network); 19 Feb 2013 13:16:24 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:16:24 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id B0E77C561A2;
	Tue, 19 Feb 2013 13:16:23 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:54 +0000
Message-Id: <1361279760-8024-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 05/11] libxl_qmp: Introduces helpers to create
	an argument 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>
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

Those functions will be used to create a "list" of parameters that
contain more than just strings. This list is converted by qmp_send to
a string to be sent to QEMU.

Those functions will be used in the next two patches, so right now
there are not compiled.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 6f7847729f0f42614de516d15257ede7243f995f
: Parent  74dee58cfc0d2d6594f388db3b4d2ce91d1bb204

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9e86c35..827f1b7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -624,6 +624,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(gc, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(gc, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(gc, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_STRING);
+    obj->u.string = libxl__strdup(gc, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_BOOL);
+    obj->u.b = b;
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:16: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 1U7n3b-0001eQ-JN; Tue, 19 Feb 2013 13:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3a-0001e7-2e
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:26 +0000
Received: from [85.158.138.51:55227] by server-2.bemta-3.messagelabs.com id
	18/A6-25961-92B73215; Tue, 19 Feb 2013 13:16:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361279784!19297795!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7118 invoked from network); 19 Feb 2013 13:16:24 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:16:24 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id B0E77C561A2;
	Tue, 19 Feb 2013 13:16:23 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:54 +0000
Message-Id: <1361279760-8024-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 05/11] libxl_qmp: Introduces helpers to create
	an argument 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>
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

Those functions will be used to create a "list" of parameters that
contain more than just strings. This list is converted by qmp_send to
a string to be sent to QEMU.

Those functions will be used in the next two patches, so right now
there are not compiled.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 6f7847729f0f42614de516d15257ede7243f995f
: Parent  74dee58cfc0d2d6594f388db3b4d2ce91d1bb204

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9e86c35..827f1b7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -624,6 +624,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(gc, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(gc, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(gc, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_STRING);
+    obj->u.string = libxl__strdup(gc, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_BOOL);
+    obj->u.b = b;
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3b-0001eZ-VW; Tue, 19 Feb 2013 13:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3a-0001eA-F3
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:26 +0000
Received: from [85.158.137.99:57419] by server-9.bemta-3.messagelabs.com id
	65/45-09484-92B73215; Tue, 19 Feb 2013 13:16:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361279778!12277451!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31486 invoked from network); 19 Feb 2013 13:16:18 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:16:18 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 86735C56198;
	Tue, 19 Feb 2013 13:16:16 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:50 +0000
Message-Id: <1361279760-8024-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 01/11] libxl_json: Export json_object related
	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>
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

Export libxl__json_object_alloc and libxl__json_object_append_to to
use them in a later patch.

Backported from xen-unstable patch:
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693129 -3600
: Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
: Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   14 ++++++++++++--
 tools/libxl/libxl_json.c     |   32 ++++++++++++++++----------------
 2 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a135cd7..2959527 100644
*** a/tools/libxl/libxl_internal.h
--- b/tools/libxl/libxl_internal.h
***************
*** 1512,1517 ****
--- 1512,1526 ----
          return -1;
  }
  
+ /*
+  * NOGC can be used with those json_object functions, but the
+  * libxl__json_object* will need to be freed with libxl__json_object_free.
+  */
+ _hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt,
+                                                      libxl__json_node_type type);
+ _hidden int libxl__json_object_append_to(libxl__gc *gc_opt,
+                                          libxl__json_object *obj,
+                                          libxl__json_object *dst);
  _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                    int i);
  _hidden
***************
*** 1520,1528 ****
  _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                            const libxl__json_object *o,
                                            libxl__json_node_type expected_type);
! _hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
  
! _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
  
    /* Based on /local/domain/$domid/dm-version xenstore key
     * default is qemu xen traditional */
--- 1529,1538 ----
  _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                            const libxl__json_object *o,
                                            libxl__json_node_type expected_type);
! _hidden void libxl__json_object_free(libxl__gc *gc_opt,
!                                      libxl__json_object *obj);
  
! _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s);
  
    /* Based on /local/domain/$domid/dm-version xenstore key
     * default is qemu xen traditional */
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index caa8312..0b0cf2f 100644
*** a/tools/libxl/libxl_json.c
--- b/tools/libxl/libxl_json.c
***************
*** 205,211 ****
   * libxl__json_object helper functions
   */
  
! static libxl__json_object *json_object_alloc(libxl__gc *gc,
                                               libxl__json_node_type type)
  {
      libxl__json_object *obj;
--- 205,211 ----
   * libxl__json_object helper functions
   */
  
! libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                               libxl__json_node_type type)
  {
      libxl__json_object *obj;
***************
*** 236,242 ****
      return obj;
  }
  
! static int json_object_append_to(libxl__gc *gc,
                                   libxl__json_object *obj,
                                   libxl__json_object *dst)
  {
--- 236,242 ----
      return obj;
  }
  
! int libxl__json_object_append_to(libxl__gc *gc,
                                   libxl__json_object *obj,
                                   libxl__json_object *dst)
  {
***************
*** 393,402 ****
  
      DEBUG_GEN(ctx, null);
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
          return 0;
  
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 393,402 ----
  
      DEBUG_GEN(ctx, null);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
          return 0;
  
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 411,421 ****
  
      DEBUG_GEN_VALUE(ctx, bool, boolean);
  
!     if ((obj = json_object_alloc(ctx->gc,
                                   boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
          return 0;
  
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 411,421 ----
  
      DEBUG_GEN_VALUE(ctx, bool, boolean);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc,
                                   boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
          return 0;
  
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 448,454 ****
              goto error;
          }
  
!         if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
              return 0;
          obj->u.d = d;
      } else {
--- 448,454 ----
              goto error;
          }
  
!         if ((obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
              return 0;
          obj->u.d = d;
      } else {
***************
*** 458,464 ****
              goto error;
          }
  
!         if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
              return 0;
          obj->u.i = i;
      }
--- 458,464 ----
              goto error;
          }
  
!         if ((obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
              return 0;
          obj->u.i = i;
      }
***************
*** 466,472 ****
  
  error:
      /* If the conversion fail, we just store the original string. */
!     if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
          return 0;
  
      t = malloc(len + 1);
--- 466,472 ----
  
  error:
      /* If the conversion fail, we just store the original string. */
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
          return 0;
  
      t = malloc(len + 1);
***************
*** 481,487 ****
      obj->u.string = t;
  
  out:
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 481,487 ----
      obj->u.string = t;
  
  out:
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 508,520 ****
      strncpy(t, (const char *) str, len);
      t[len] = 0;
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
          free(t);
          return 0;
      }
      obj->u.string = t;
  
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 508,520 ----
      strncpy(t, (const char *) str, len);
      t[len] = 0;
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
          free(t);
          return 0;
      }
      obj->u.string = t;
  
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 573,583 ****
  
      DEBUG_GEN(ctx, map_open);
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
--- 573,583 ----
  
      DEBUG_GEN(ctx, map_open);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
***************
*** 615,625 ****
  
      DEBUG_GEN(ctx, array_open);
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
- - 
--- 615,625 ----
  
      DEBUG_GEN(ctx, array_open);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3b-0001eZ-VW; Tue, 19 Feb 2013 13:16:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3a-0001eA-F3
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:26 +0000
Received: from [85.158.137.99:57419] by server-9.bemta-3.messagelabs.com id
	65/45-09484-92B73215; Tue, 19 Feb 2013 13:16:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361279778!12277451!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31486 invoked from network); 19 Feb 2013 13:16:18 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:16:18 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 86735C56198;
	Tue, 19 Feb 2013 13:16:16 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:50 +0000
Message-Id: <1361279760-8024-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 01/11] libxl_json: Export json_object related
	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>
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

Export libxl__json_object_alloc and libxl__json_object_append_to to
use them in a later patch.

Backported from xen-unstable patch:
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693129 -3600
: Node ID c9b80c7f8db1a5d26906a2298c481bf7e87fda94
: Parent  93e3e6a33e0a1ec9f92fc575334caa35e6dbc757

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   14 ++++++++++++--
 tools/libxl/libxl_json.c     |   32 ++++++++++++++++----------------
 2 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a135cd7..2959527 100644
*** a/tools/libxl/libxl_internal.h
--- b/tools/libxl/libxl_internal.h
***************
*** 1512,1517 ****
--- 1512,1526 ----
          return -1;
  }
  
+ /*
+  * NOGC can be used with those json_object functions, but the
+  * libxl__json_object* will need to be freed with libxl__json_object_free.
+  */
+ _hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt,
+                                                      libxl__json_node_type type);
+ _hidden int libxl__json_object_append_to(libxl__gc *gc_opt,
+                                          libxl__json_object *obj,
+                                          libxl__json_object *dst);
  _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                    int i);
  _hidden
***************
*** 1520,1528 ****
  _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                            const libxl__json_object *o,
                                            libxl__json_node_type expected_type);
! _hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
  
! _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
  
    /* Based on /local/domain/$domid/dm-version xenstore key
     * default is qemu xen traditional */
--- 1529,1538 ----
  _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                            const libxl__json_object *o,
                                            libxl__json_node_type expected_type);
! _hidden void libxl__json_object_free(libxl__gc *gc_opt,
!                                      libxl__json_object *obj);
  
! _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s);
  
    /* Based on /local/domain/$domid/dm-version xenstore key
     * default is qemu xen traditional */
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index caa8312..0b0cf2f 100644
*** a/tools/libxl/libxl_json.c
--- b/tools/libxl/libxl_json.c
***************
*** 205,211 ****
   * libxl__json_object helper functions
   */
  
! static libxl__json_object *json_object_alloc(libxl__gc *gc,
                                               libxl__json_node_type type)
  {
      libxl__json_object *obj;
--- 205,211 ----
   * libxl__json_object helper functions
   */
  
! libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                               libxl__json_node_type type)
  {
      libxl__json_object *obj;
***************
*** 236,242 ****
      return obj;
  }
  
! static int json_object_append_to(libxl__gc *gc,
                                   libxl__json_object *obj,
                                   libxl__json_object *dst)
  {
--- 236,242 ----
      return obj;
  }
  
! int libxl__json_object_append_to(libxl__gc *gc,
                                   libxl__json_object *obj,
                                   libxl__json_object *dst)
  {
***************
*** 393,402 ****
  
      DEBUG_GEN(ctx, null);
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
          return 0;
  
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 393,402 ----
  
      DEBUG_GEN(ctx, null);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
          return 0;
  
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 411,421 ****
  
      DEBUG_GEN_VALUE(ctx, bool, boolean);
  
!     if ((obj = json_object_alloc(ctx->gc,
                                   boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
          return 0;
  
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 411,421 ----
  
      DEBUG_GEN_VALUE(ctx, bool, boolean);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc,
                                   boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
          return 0;
  
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 448,454 ****
              goto error;
          }
  
!         if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
              return 0;
          obj->u.d = d;
      } else {
--- 448,454 ----
              goto error;
          }
  
!         if ((obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
              return 0;
          obj->u.d = d;
      } else {
***************
*** 458,464 ****
              goto error;
          }
  
!         if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
              return 0;
          obj->u.i = i;
      }
--- 458,464 ----
              goto error;
          }
  
!         if ((obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
              return 0;
          obj->u.i = i;
      }
***************
*** 466,472 ****
  
  error:
      /* If the conversion fail, we just store the original string. */
!     if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
          return 0;
  
      t = malloc(len + 1);
--- 466,472 ----
  
  error:
      /* If the conversion fail, we just store the original string. */
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
          return 0;
  
      t = malloc(len + 1);
***************
*** 481,487 ****
      obj->u.string = t;
  
  out:
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 481,487 ----
      obj->u.string = t;
  
  out:
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 508,520 ****
      strncpy(t, (const char *) str, len);
      t[len] = 0;
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
          free(t);
          return 0;
      }
      obj->u.string = t;
  
!     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
--- 508,520 ----
      strncpy(t, (const char *) str, len);
      t[len] = 0;
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
          free(t);
          return 0;
      }
      obj->u.string = t;
  
!     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
          libxl__json_object_free(ctx->gc, obj);
          return 0;
      }
***************
*** 573,583 ****
  
      DEBUG_GEN(ctx, map_open);
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
--- 573,583 ----
  
      DEBUG_GEN(ctx, map_open);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
***************
*** 615,625 ****
  
      DEBUG_GEN(ctx, array_open);
  
!     if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
- - 
--- 615,625 ----
  
      DEBUG_GEN(ctx, array_open);
  
!     if ((obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
          return 0;
  
      if (ctx->current) {
!         if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
              libxl__json_object_free(ctx->gc, obj);
              return 0;
          }
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3g-0001fG-C8; Tue, 19 Feb 2013 13:16:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3f-0001f4-JG
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:31 +0000
Received: from [85.158.138.51:61826] by server-12.bemta-3.messagelabs.com id
	74/A4-05889-E2B73215; Tue, 19 Feb 2013 13:16:30 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361279789!19480791!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2205 invoked from network); 19 Feb 2013 13:16:30 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:16:30 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 9316FC561A6;
	Tue, 19 Feb 2013 13:16:28 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:58 +0000
Message-Id: <1361279760-8024-10-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 09/11] libxl_dom: Call the right switch
	logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen right now is synchronous, not like the one to
qemu-xen-traditional.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 08fac5c2bf3dcbc493ce45091383f6ce1938f369
: Parent  d4aec9eff7e6d15c2805957af620c82555553b3e

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_dom.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3g-0001fG-C8; Tue, 19 Feb 2013 13:16:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3f-0001f4-JG
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:31 +0000
Received: from [85.158.138.51:61826] by server-12.bemta-3.messagelabs.com id
	74/A4-05889-E2B73215; Tue, 19 Feb 2013 13:16:30 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361279789!19480791!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2205 invoked from network); 19 Feb 2013 13:16:30 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:16:30 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 9316FC561A6;
	Tue, 19 Feb 2013 13:16:28 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:58 +0000
Message-Id: <1361279760-8024-10-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 09/11] libxl_dom: Call the right switch
	logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen right now is synchronous, not like the one to
qemu-xen-traditional.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 08fac5c2bf3dcbc493ce45091383f6ce1938f369
: Parent  d4aec9eff7e6d15c2805957af620c82555553b3e

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_dom.c |   45 ++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3T-0001di-QF; Tue, 19 Feb 2013 13:16:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3S-0001dd-CF
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:18 +0000
Received: from [85.158.139.83:22061] by server-3.bemta-5.messagelabs.com id
	A2/9A-07037-12B73215; Tue, 19 Feb 2013 13:16:17 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361279776!27968908!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28790 invoked from network); 19 Feb 2013 13:16:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:16:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id A9A20C56196;
	Tue, 19 Feb 2013 13:16:04 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:49 +0000
Message-Id: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM on
	qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch series consists of 2	parts:
* 11 patches to	libxl
* 5 patches to QEMU

The 11 patches to libxl are unchanged since version 3 of the patch,
but have Acked-By lines reintroduced.

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

I would	suggest these patches should be included in 4.2.2.

You can find these on Github at:
 https://github.com/abligh/xen-4.2-live-migrate/commits/PATCHv4

Or on the PATCHv4 branch of this repository:
 https://github.com/abligh/xen-4.2-live-migrate.git

Alex Bligh (11):
  libxl_json: Export json_object related function.
  libxl_json: Remove JSON_ERROR from enum.
  libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL.
  libxl_json: Introduce libxl__json_object_to_yajl_gen.
  libxl_qmp: Introduces helpers to create an argument list.
  libxl_qmp: Use qmp_parameters_* functions for param list of a QMP
    command.
  libxl_qmp: Simplify run of single QMP commands.
  libxl_qmp: Introduce libxl__qmp_set_global_dirty_log.
  libxl_dom: Call the right switch logdirty for the right DM.
  libxl: libxl__qmp_save: Add filename as JSON parameter to
    xen-save-devices-state
  libxl: Allow migration with qemu-xen.

 tools/libxl/libxl.c          |   17 ----
 tools/libxl/libxl_dom.c      |   45 +++++++++-
 tools/libxl/libxl_internal.h |   35 ++++++-
 tools/libxl/libxl_json.c     |   94 +++++++++++++++----
 tools/libxl/libxl_qmp.c      |  209 +++++++++++++++++++++---------------------
 5 files changed, 253 insertions(+), 147 deletions(-)

All this patch series:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3T-0001di-QF; Tue, 19 Feb 2013 13:16:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3S-0001dd-CF
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:18 +0000
Received: from [85.158.139.83:22061] by server-3.bemta-5.messagelabs.com id
	A2/9A-07037-12B73215; Tue, 19 Feb 2013 13:16:17 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361279776!27968908!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28790 invoked from network); 19 Feb 2013 13:16:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:16:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id A9A20C56196;
	Tue, 19 Feb 2013 13:16:04 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:49 +0000
Message-Id: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM on
	qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch series consists of 2	parts:
* 11 patches to	libxl
* 5 patches to QEMU

The 11 patches to libxl are unchanged since version 3 of the patch,
but have Acked-By lines reintroduced.

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

I would	suggest these patches should be included in 4.2.2.

You can find these on Github at:
 https://github.com/abligh/xen-4.2-live-migrate/commits/PATCHv4

Or on the PATCHv4 branch of this repository:
 https://github.com/abligh/xen-4.2-live-migrate.git

Alex Bligh (11):
  libxl_json: Export json_object related function.
  libxl_json: Remove JSON_ERROR from enum.
  libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL.
  libxl_json: Introduce libxl__json_object_to_yajl_gen.
  libxl_qmp: Introduces helpers to create an argument list.
  libxl_qmp: Use qmp_parameters_* functions for param list of a QMP
    command.
  libxl_qmp: Simplify run of single QMP commands.
  libxl_qmp: Introduce libxl__qmp_set_global_dirty_log.
  libxl_dom: Call the right switch logdirty for the right DM.
  libxl: libxl__qmp_save: Add filename as JSON parameter to
    xen-save-devices-state
  libxl: Allow migration with qemu-xen.

 tools/libxl/libxl.c          |   17 ----
 tools/libxl/libxl_dom.c      |   45 +++++++++-
 tools/libxl/libxl_internal.h |   35 ++++++-
 tools/libxl/libxl_json.c     |   94 +++++++++++++++----
 tools/libxl/libxl_qmp.c      |  209 +++++++++++++++++++++---------------------
 5 files changed, 253 insertions(+), 147 deletions(-)

All this patch series:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3j-0001ga-Bf; Tue, 19 Feb 2013 13:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3h-0001fU-9k
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:33 +0000
Received: from [85.158.143.99:21113] by server-1.bemta-4.messagelabs.com id
	AE/81-08839-03B73215; Tue, 19 Feb 2013 13:16:32 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361279780!27255730!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32641 invoked from network); 19 Feb 2013 13:16:20 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	19 Feb 2013 13:16:20 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id B5407C5619A;
	Tue, 19 Feb 2013 13:16:18 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:51 +0000
Message-Id: <1361279760-8024-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 02/11] libxl_json: Remove JSON_ERROR from enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 value from libxl__json_node_type is never used.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693130 -3600
: Node ID 4a6d5d8cba4fc44f9bbda201188885868604b8e8
: Parent  c9b80c7f8db1a5d26906a2298c481bf7e87fda94

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2959527..5b285d4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1428,7 +1428,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
-    JSON_ERROR,
     JSON_NULL,
     JSON_TRUE,
     JSON_FALSE,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3j-0001ga-Bf; Tue, 19 Feb 2013 13:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3h-0001fU-9k
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:33 +0000
Received: from [85.158.143.99:21113] by server-1.bemta-4.messagelabs.com id
	AE/81-08839-03B73215; Tue, 19 Feb 2013 13:16:32 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361279780!27255730!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32641 invoked from network); 19 Feb 2013 13:16:20 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-216.messagelabs.com with SMTP;
	19 Feb 2013 13:16:20 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id B5407C5619A;
	Tue, 19 Feb 2013 13:16:18 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:51 +0000
Message-Id: <1361279760-8024-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 02/11] libxl_json: Remove JSON_ERROR from enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 value from libxl__json_node_type is never used.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693130 -3600
: Node ID 4a6d5d8cba4fc44f9bbda201188885868604b8e8
: Parent  c9b80c7f8db1a5d26906a2298c481bf7e87fda94

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2959527..5b285d4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1428,7 +1428,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
-    JSON_ERROR,
     JSON_NULL,
     JSON_TRUE,
     JSON_FALSE,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:16: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 1U7n3i-0001gK-VC; Tue, 19 Feb 2013 13:16:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3h-0001fL-5U
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:33 +0000
Received: from [85.158.138.51:58126] by server-8.bemta-3.messagelabs.com id
	7D/5D-25687-03B73215; Tue, 19 Feb 2013 13:16:32 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361279789!19480791!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2318 invoked from network); 19 Feb 2013 13:16:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:16:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1D0ACC561A8;
	Tue, 19 Feb 2013 13:16:30 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:59 +0000
Message-Id: <1361279760-8024-11-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 10/11] libxl: libxl__qmp_save: Add filename as
	JSON parameter to xen-save-devices-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>
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

 Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel <xen-devel@lists.xen.org>,
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
    Alex Bligh <alex@alex.org.uk>


Signed-off-by: Alex Bligh <alex@alex.org.uk>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl_qmp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ac10f20..b4cc247 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -871,6 +871,7 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__json_object *args = NULL;
 
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     return qmp_run_command(gc, domid, "xen-save-devices-state", args,
                            NULL, NULL);
 }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:16: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 1U7n3i-0001gK-VC; Tue, 19 Feb 2013 13:16:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3h-0001fL-5U
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:33 +0000
Received: from [85.158.138.51:58126] by server-8.bemta-3.messagelabs.com id
	7D/5D-25687-03B73215; Tue, 19 Feb 2013 13:16:32 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361279789!19480791!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2318 invoked from network); 19 Feb 2013 13:16:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:16:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1D0ACC561A8;
	Tue, 19 Feb 2013 13:16:30 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:59 +0000
Message-Id: <1361279760-8024-11-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 10/11] libxl: libxl__qmp_save: Add filename as
	JSON parameter to xen-save-devices-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>
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

 Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel <xen-devel@lists.xen.org>,
    Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
    Alex Bligh <alex@alex.org.uk>


Signed-off-by: Alex Bligh <alex@alex.org.uk>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxl_qmp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ac10f20..b4cc247 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -871,6 +871,7 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__json_object *args = NULL;
 
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     return qmp_run_command(gc, domid, "xen-save-devices-state", args,
                            NULL, NULL);
 }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3Z-0001e1-6Y; Tue, 19 Feb 2013 13:16:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3Y-0001dt-86
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:24 +0000
Received: from [85.158.139.211:48750] by server-15.bemta-5.messagelabs.com id
	B6/7F-18914-72B73215; Tue, 19 Feb 2013 13:16:23 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361279782!18229918!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23271 invoked from network); 19 Feb 2013 13:16:22 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 13:16:22 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 7FFF7C5619B;
	Tue, 19 Feb 2013 13:16:20 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:52 +0000
Message-Id: <1361279760-8024-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 03/11] libxl_json: Replace JSON_TRUE/FALSE by
	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Those two JSON_TRUE and JSON_FALSE were types of node. But it's better
to have a unique JSON_BOOL type.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693131 -3600
: Node ID 3f71aab0e2774ded0c5a03436c364fb031ba9aa0
: Parent  4a6d5d8cba4fc44f9bbda201188885868604b8e8

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   15 +++++++++++++--
 tools/libxl/libxl_json.c     |    3 +--
 tools/libxl/libxl_qmp.c      |    3 ++-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5b285d4..7dbd8af 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1429,8 +1429,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
     JSON_NULL,
-    JSON_TRUE,
-    JSON_FALSE,
+    JSON_BOOL,
     JSON_INTEGER,
     JSON_DOUBLE,
     /* number is store in string, it's too big to be a long long or a double */
@@ -1444,6 +1443,7 @@ typedef enum {
 typedef struct libxl__json_object {
     libxl__json_node_type type;
     union {
+        bool b;
         long long i;
         double d;
         char *string;
@@ -1462,6 +1462,10 @@ typedef struct {
 
 typedef struct libxl__yajl_ctx libxl__yajl_ctx;
 
+static inline bool libxl__json_object_is_bool(const libxl__json_object *o)
+{
+    return o != NULL && o->type == JSON_BOOL;
+}
 static inline bool libxl__json_object_is_string(const libxl__json_object *o)
 {
     return o != NULL && o->type == JSON_STRING;
@@ -1479,6 +1483,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o)
     return o != NULL && o->type == JSON_ARRAY;
 }
 
+static inline bool libxl__json_object_get_bool(const libxl__json_object *o)
+{
+    if (libxl__json_object_is_bool(o))
+        return o->u.b;
+    else
+        return false;
+}
 static inline
 const char *libxl__json_object_get_string(const libxl__json_object *o)
 {
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0b0cf2f..98db465 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -411,8 +411,7 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = libxl__json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL)) == NULL)
         return 0;
 
     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e33b130..9e86c35 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
         goto out;
     }
 
-    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+    obj = libxl__json_map_get("enabled", o, JSON_BOOL);
+    if (!obj || !libxl__json_object_get_bool(obj)) {
         rc = 0;
         goto out;
     }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3Z-0001e1-6Y; Tue, 19 Feb 2013 13:16:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3Y-0001dt-86
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:24 +0000
Received: from [85.158.139.211:48750] by server-15.bemta-5.messagelabs.com id
	B6/7F-18914-72B73215; Tue, 19 Feb 2013 13:16:23 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361279782!18229918!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23271 invoked from network); 19 Feb 2013 13:16:22 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 13:16:22 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 7FFF7C5619B;
	Tue, 19 Feb 2013 13:16:20 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:52 +0000
Message-Id: <1361279760-8024-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 03/11] libxl_json: Replace JSON_TRUE/FALSE by
	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Those two JSON_TRUE and JSON_FALSE were types of node. But it's better
to have a unique JSON_BOOL type.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693131 -3600
: Node ID 3f71aab0e2774ded0c5a03436c364fb031ba9aa0
: Parent  4a6d5d8cba4fc44f9bbda201188885868604b8e8

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |   15 +++++++++++++--
 tools/libxl/libxl_json.c     |    3 +--
 tools/libxl/libxl_qmp.c      |    3 ++-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5b285d4..7dbd8af 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1429,8 +1429,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
     JSON_NULL,
-    JSON_TRUE,
-    JSON_FALSE,
+    JSON_BOOL,
     JSON_INTEGER,
     JSON_DOUBLE,
     /* number is store in string, it's too big to be a long long or a double */
@@ -1444,6 +1443,7 @@ typedef enum {
 typedef struct libxl__json_object {
     libxl__json_node_type type;
     union {
+        bool b;
         long long i;
         double d;
         char *string;
@@ -1462,6 +1462,10 @@ typedef struct {
 
 typedef struct libxl__yajl_ctx libxl__yajl_ctx;
 
+static inline bool libxl__json_object_is_bool(const libxl__json_object *o)
+{
+    return o != NULL && o->type == JSON_BOOL;
+}
 static inline bool libxl__json_object_is_string(const libxl__json_object *o)
 {
     return o != NULL && o->type == JSON_STRING;
@@ -1479,6 +1483,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o)
     return o != NULL && o->type == JSON_ARRAY;
 }
 
+static inline bool libxl__json_object_get_bool(const libxl__json_object *o)
+{
+    if (libxl__json_object_is_bool(o))
+        return o->u.b;
+    else
+        return false;
+}
 static inline
 const char *libxl__json_object_get_string(const libxl__json_object *o)
 {
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0b0cf2f..98db465 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -411,8 +411,7 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = libxl__json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
+    if ((obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL)) == NULL)
         return 0;
 
     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e33b130..9e86c35 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
         goto out;
     }
 
-    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+    obj = libxl__json_map_get("enabled", o, JSON_BOOL);
+    if (!obj || !libxl__json_object_get_bool(obj)) {
         rc = 0;
         goto out;
     }
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3v-0001k4-QJ; Tue, 19 Feb 2013 13:16:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3u-0001jT-E4
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:46 +0000
Received: from [85.158.137.99:26565] by server-12.bemta-3.messagelabs.com id
	22/25-05889-D3B73215; Tue, 19 Feb 2013 13:16:45 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361279804!17037311!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21004 invoked from network); 19 Feb 2013 13:16:44 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:16:44 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 77A4AC561A0;
	Tue, 19 Feb 2013 13:16:22 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:53 +0000
Message-Id: <1361279760-8024-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 04/11] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function converts a libxl__json_object to yajl by calling every
yajl_gen_* function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing
yajl_gen tree.

This function is used in a later patch.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 74dee58cfc0d2d6594f388db3b4d2ce91d1bb204
: Parent  3f71aab0e2774ded0c5a03436c364fb031ba9aa0

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    3 ++
 tools/libxl/libxl_json.c     |   61 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7dbd8af..b00ff61 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1539,6 +1539,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 _hidden void libxl__json_object_free(libxl__gc *gc_opt,
                                      libxl__json_object *obj);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 98db465..72b52e8 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -381,6 +381,67 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int idx = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_BOOL:
+        return yajl_gen_bool(hand, obj->u.b);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ANY:
+        /* JSON_ANY is not a valid value for obj->type. */
+        ;
+    }
+    abort();
+}
+
 
 /*
  * JSON callbacks
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:16:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n3v-0001k4-QJ; Tue, 19 Feb 2013 13:16:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n3u-0001jT-E4
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:46 +0000
Received: from [85.158.137.99:26565] by server-12.bemta-3.messagelabs.com id
	22/25-05889-D3B73215; Tue, 19 Feb 2013 13:16:45 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361279804!17037311!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21004 invoked from network); 19 Feb 2013 13:16:44 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:16:44 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 77A4AC561A0;
	Tue, 19 Feb 2013 13:16:22 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:53 +0000
Message-Id: <1361279760-8024-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 04/11] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function converts a libxl__json_object to yajl by calling every
yajl_gen_* function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing
yajl_gen tree.

This function is used in a later patch.

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693132 -3600
: Node ID 74dee58cfc0d2d6594f388db3b4d2ce91d1bb204
: Parent  3f71aab0e2774ded0c5a03436c364fb031ba9aa0

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    3 ++
 tools/libxl/libxl_json.c     |   61 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7dbd8af..b00ff61 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1539,6 +1539,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 _hidden void libxl__json_object_free(libxl__gc *gc_opt,
                                      libxl__json_object *obj);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 98db465..72b52e8 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -381,6 +381,67 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int idx = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_BOOL:
+        return yajl_gen_bool(hand, obj->u.b);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ANY:
+        /* JSON_ANY is not a valid value for obj->type. */
+        ;
+    }
+    abort();
+}
+
 
 /*
  * JSON callbacks
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n45-0001pf-9U; Tue, 19 Feb 2013 13:16:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n43-0001o6-0p
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:55 +0000
Received: from [85.158.139.83:24320] by server-2.bemta-5.messagelabs.com id
	D3/73-16911-64B73215; Tue, 19 Feb 2013 13:16:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361279805!27942608!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28978 invoked from network); 19 Feb 2013 13:16:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:16:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id BE1B8C561A3;
	Tue, 19 Feb 2013 13:16:24 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:55 +0000
Message-Id: <1361279760-8024-7-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 06/11] libxl_qmp: Use qmp_parameters_*
	functions for param list of a QMP 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>
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

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693133 -3600
: Node ID be5d014f91dfbd67afacc3385c265243794a246f
: Parent  6f7847729f0f42614de516d15257ede7243f995f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   89 ++++++++++++++++-------------------------------
 1 files changed, 30 insertions(+), 59 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 827f1b7..605e8f3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -503,7 +503,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -527,7 +527,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -561,7 +561,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -589,7 +589,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -624,7 +624,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  */
@@ -659,6 +658,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,11 +669,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -801,8 +801,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -815,31 +814,22 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -847,24 +837,18 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -882,56 +866,43 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     if (!args) {
         rc = ERROR_NOMEM;
-        goto out2;
+        goto out;
     }
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
 
-out2:
-    flexarray_free(parameters);
 out:
     libxl__qmp_close(qmp);
     return rc;
+
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n45-0001pf-9U; Tue, 19 Feb 2013 13:16:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n43-0001o6-0p
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:55 +0000
Received: from [85.158.139.83:24320] by server-2.bemta-5.messagelabs.com id
	D3/73-16911-64B73215; Tue, 19 Feb 2013 13:16:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361279805!27942608!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28978 invoked from network); 19 Feb 2013 13:16:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-3.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:16:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id BE1B8C561A3;
	Tue, 19 Feb 2013 13:16:24 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:55 +0000
Message-Id: <1361279760-8024-7-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 06/11] libxl_qmp: Use qmp_parameters_*
	functions for param list of a QMP 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>
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

Backported from xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693133 -3600
: Node ID be5d014f91dfbd67afacc3385c265243794a246f
: Parent  6f7847729f0f42614de516d15257ede7243f995f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   89 ++++++++++++++++-------------------------------
 1 files changed, 30 insertions(+), 59 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 827f1b7..605e8f3 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -503,7 +503,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -527,7 +527,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -561,7 +561,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -589,7 +589,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -624,7 +624,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  */
@@ -659,6 +658,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,11 +669,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -801,8 +801,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -815,31 +814,22 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -847,24 +837,18 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -882,56 +866,43 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
     if (!args) {
         rc = ERROR_NOMEM;
-        goto out2;
+        goto out;
     }
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
 
-out2:
-    flexarray_free(parameters);
 out:
     libxl__qmp_close(qmp);
     return rc;
+
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n45-0001q7-OD; Tue, 19 Feb 2013 13:16:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n43-0001oI-IT
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:55 +0000
Received: from [85.158.139.83:62997] by server-11.bemta-5.messagelabs.com id
	40/A0-19159-64B73215; Tue, 19 Feb 2013 13:16:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361279808!27968970!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30291 invoked from network); 19 Feb 2013 13:16:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:16:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 0A6F1C561A5;
	Tue, 19 Feb 2013 13:16:26 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:57 +0000
Message-Id: <1361279760-8024-9-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 08/11] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function will enable or disable the global dirty log on QEMU,
used during a migration.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693135 -3600
: Node ID d4aec9eff7e6d15c2805957af620c82555553b3e
: Parent  f3890916496445c97d6778d6c986b0270ff707f2

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_qmp.c      |   12 ++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b00ff61..f658562 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1400,6 +1400,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* 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 b09bf13..ac10f20 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -658,7 +658,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,7 +668,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                           NULL, NULL);
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n45-0001q7-OD; Tue, 19 Feb 2013 13:16:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n43-0001oI-IT
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:55 +0000
Received: from [85.158.139.83:62997] by server-11.bemta-5.messagelabs.com id
	40/A0-19159-64B73215; Tue, 19 Feb 2013 13:16:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361279808!27968970!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30291 invoked from network); 19 Feb 2013 13:16:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:16:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 0A6F1C561A5;
	Tue, 19 Feb 2013 13:16:26 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:57 +0000
Message-Id: <1361279760-8024-9-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 08/11] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 function will enable or disable the global dirty log on QEMU,
used during a migration.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693135 -3600
: Node ID d4aec9eff7e6d15c2805957af620c82555553b3e
: Parent  f3890916496445c97d6778d6c986b0270ff707f2

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_internal.h |    2 ++
 tools/libxl/libxl_qmp.c      |   12 ++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b00ff61..f658562 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1400,6 +1400,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* 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 b09bf13..ac10f20 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -658,7 +658,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -669,7 +668,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                           NULL, NULL);
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n48-0001rS-57; Tue, 19 Feb 2013 13:17:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n46-0001qd-SA
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:58 +0000
Received: from [193.109.254.147:24478] by server-10.bemta-14.messagelabs.com
	id 87/15-12679-A4B73215; Tue, 19 Feb 2013 13:16:58 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361279794!8795698!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27599 invoked from network); 19 Feb 2013 13:16:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-27.messagelabs.com with SMTP;
	19 Feb 2013 13:16:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 50724C561A9;
	Tue, 19 Feb 2013 13:16:33 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:16:00 +0000
Message-Id: <1361279760-8024-12-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 11/11] libxl: Allow migration with 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>
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

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 0995890022391682a2499a202c3c8608e1d3780a
: Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl.c |   17 -----------------
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4b4c5b0..9b14364 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -768,23 +768,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
         goto out_err;
     }
 
-    if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
-        switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            /* No problem */
-            break;
-        case -1:
-            rc = ERROR_FAIL;
-            goto out_err;
-        default: abort();
-        }
-    }
-
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n48-0001rS-57; Tue, 19 Feb 2013 13:17:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n46-0001qd-SA
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:16:58 +0000
Received: from [193.109.254.147:24478] by server-10.bemta-14.messagelabs.com
	id 87/15-12679-A4B73215; Tue, 19 Feb 2013 13:16:58 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361279794!8795698!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27599 invoked from network); 19 Feb 2013 13:16:34 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-27.messagelabs.com with SMTP;
	19 Feb 2013 13:16:34 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 50724C561A9;
	Tue, 19 Feb 2013 13:16:33 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:16:00 +0000
Message-Id: <1361279760-8024-12-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 11/11] libxl: Allow migration with 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>
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

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693136 -3600
: Node ID 0995890022391682a2499a202c3c8608e1d3780a
: Parent  08fac5c2bf3dcbc493ce45091383f6ce1938f369

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl.c |   17 -----------------
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4b4c5b0..9b14364 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -768,23 +768,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
         goto out_err;
     }
 
-    if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
-        switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            /* No problem */
-            break;
-        case -1:
-            rc = ERROR_FAIL;
-            goto out_err;
-        default: abort();
-        }
-    }
-
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7n4i-0002Br-Sp; Tue, 19 Feb 2013 13:17:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4g-0002AF-Q0
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:35 +0000
Received: from [85.158.137.99:16482] by server-10.bemta-3.messagelabs.com id
	79/F4-10609-96B73215; Tue, 19 Feb 2013 13:17:29 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361279807!17027760!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3934 invoked from network); 19 Feb 2013 13:16:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:16:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 02965C561A4;
	Tue, 19 Feb 2013 13:16:25 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:56 +0000
Message-Id: <1361279760-8024-8-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 07/11] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 new function connects to QEMU, sends the command and disconnects.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693134 -3600
: Node ID f3890916496445c97d6778d6c986b0270ff707f2
: Parent  be5d014f91dfbd67afacc3385c265243794a246f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   77 +++++++++++++---------------------------------
 1 files changed, 22 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 605e8f3..b09bf13 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -798,6 +798,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -836,21 +853,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "id", id);
-
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
 }
 
 int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
@@ -865,27 +871,10 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
-
-out:
-    libxl__qmp_close(qmp);
-    return rc;
 
+    return qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                           NULL, NULL);
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
@@ -908,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7n4i-0002Br-Sp; Tue, 19 Feb 2013 13:17:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4g-0002AF-Q0
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:35 +0000
Received: from [85.158.137.99:16482] by server-10.bemta-3.messagelabs.com id
	79/F4-10609-96B73215; Tue, 19 Feb 2013 13:17:29 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361279807!17027760!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3934 invoked from network); 19 Feb 2013 13:16:47 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:16:47 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 02965C561A4;
	Tue, 19 Feb 2013 13:16:25 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:15:56 +0000
Message-Id: <1361279760-8024-8-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 07/11] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 new function connects to QEMU, sends the command and disconnects.

Backport of xen-unstable patch:
: HG changeset patch
: User Anthony PERARD <anthony.perard@citrix.com>
: Date 1349693134 -3600
: Node ID f3890916496445c97d6778d6c986b0270ff707f2
: Parent  be5d014f91dfbd67afacc3385c265243794a246f

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 tools/libxl/libxl_qmp.c |   77 +++++++++++++---------------------------------
 1 files changed, 22 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 605e8f3..b09bf13 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -798,6 +798,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -836,21 +853,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "id", id);
-
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
 }
 
 int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
@@ -865,27 +871,10 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
-
-out:
-    libxl__qmp_close(qmp);
-    return rc;
 
+    return qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                           NULL, NULL);
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
@@ -908,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4t-0002IL-9P; Tue, 19 Feb 2013 13:17:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4r-0002H3-RD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:45 +0000
Received: from [85.158.138.51:9045] by server-3.bemta-3.messagelabs.com id
	B5/03-31070-47B73215; Tue, 19 Feb 2013 13:17:40 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361279859!28162116!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19136 invoked from network); 19 Feb 2013 13:17:39 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:17:39 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 0C0CEC56198;
	Tue, 19 Feb 2013 13:17:38 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:25 +0000
Message-Id: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 0/5] QEMU: Enabling live-migrate on HVM on
	qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch series consists of 2	parts:
* 11 patches to	libxl
* 5 patches to QEMU

The 11 patches to libxl are unchanged since version 3 of the patch,
but have Acked-By lines reintroduced.

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

I would	suggest these patches should be included in 4.2.2.

You can find these on Github at:
 https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate

Or on the master branch of this repository:
 https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate.git

Alex Bligh (5):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occur.

 exec.c           |   49 +++++++++++++++++++++----------------------------
 hw/xen.h         |    1 +
 memory.c         |    4 ++++
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
 xen-stub.c       |    9 +++++++++
 7 files changed, 117 insertions(+), 30 deletions(-)

-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4t-0002IL-9P; Tue, 19 Feb 2013 13:17:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4r-0002H3-RD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:45 +0000
Received: from [85.158.138.51:9045] by server-3.bemta-3.messagelabs.com id
	B5/03-31070-47B73215; Tue, 19 Feb 2013 13:17:40 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361279859!28162116!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19136 invoked from network); 19 Feb 2013 13:17:39 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:17:39 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 0C0CEC56198;
	Tue, 19 Feb 2013 13:17:38 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:25 +0000
Message-Id: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 0/5] QEMU: Enabling live-migrate on HVM on
	qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch series consists of 2	parts:
* 11 patches to	libxl
* 5 patches to QEMU

The 11 patches to libxl are unchanged since version 3 of the patch,
but have Acked-By lines reintroduced.

The 5 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

I would	suggest these patches should be included in 4.2.2.

You can find these on Github at:
 https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate

Or on the master branch of this repository:
 https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate.git

Alex Bligh (5):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occur.

 exec.c           |   49 +++++++++++++++++++++----------------------------
 hw/xen.h         |    1 +
 memory.c         |    4 ++++
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
 xen-stub.c       |    9 +++++++++
 7 files changed, 117 insertions(+), 30 deletions(-)

-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4v-0002KB-Ma; Tue, 19 Feb 2013 13:17:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4u-0002Ii-8E
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:48 +0000
Received: from [85.158.137.99:22387] by server-10.bemta-3.messagelabs.com id
	DF/C5-10609-B7B73215; Tue, 19 Feb 2013 13:17:47 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361279865!12277787!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6299 invoked from network); 19 Feb 2013 13:17:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:17:45 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 2E350C561AC;
	Tue, 19 Feb 2013 13:17:45 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:30 +0000
Message-Id: <1361279850-8246-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 xen-all.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 121289d..dbd759c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
@@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
         while (map != 0) {
             j = ffsl(map) - 1;
             map &= ~(1ul << j);
-            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
+            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
+            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
+            cpu_physical_memory_set_dirty(todirty);
         };
     }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4v-0002KB-Ma; Tue, 19 Feb 2013 13:17:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4u-0002Ii-8E
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:48 +0000
Received: from [85.158.137.99:22387] by server-10.bemta-3.messagelabs.com id
	DF/C5-10609-B7B73215; Tue, 19 Feb 2013 13:17:47 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361279865!12277787!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6299 invoked from network); 19 Feb 2013 13:17:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 13:17:45 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 2E350C561AC;
	Tue, 19 Feb 2013 13:17:45 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:30 +0000
Message-Id: <1361279850-8246-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 xen-all.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 121289d..dbd759c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
@@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
         while (map != 0) {
             j = ffsl(map) - 1;
             map &= ~(1ul << j);
-            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
+            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
+            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
+            cpu_physical_memory_set_dirty(todirty);
         };
     }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4x-0002LM-53; Tue, 19 Feb 2013 13:17:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4v-0002JO-A3
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:49 +0000
Received: from [85.158.138.51:10331] by server-5.bemta-3.messagelabs.com id
	B7/11-04457-97B73215; Tue, 19 Feb 2013 13:17:45 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361279865!28250605!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10062 invoked from network); 19 Feb 2013 13:17:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:17:45 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 5F080C561AB;
	Tue, 19 Feb 2013 13:17:44 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:29 +0000
Message-Id: <1361279850-8246-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 4/5] exec, memory: Call to xen_modified_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>
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 patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c   |    4 ++++
 memory.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 511777b..401f9bc 100644
--- a/exec.c
+++ b/exec.c
@@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
            0xff, size >> TARGET_PAGE_BITS);
 
+    if (xen_enabled())
+        xen_modified_memory(new_block->offset, size);
+
     if (kvm_enabled())
         kvm_setup_guest_memory(new_block->host, size);
 
@@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 7c20a07..6e0c596 100644
--- a/memory.c
+++ b/memory.c
@@ -16,6 +16,7 @@
 #include "ioport.h"
 #include "bitops.h"
 #include "kvm.h"
+#include "hw/xen.h"
 #include <assert.h>
 
 unsigned memory_region_transaction_depth = 0;
@@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
 {
     assert(mr->terminates);
+    if (xen_enabled())
+        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
+                            TARGET_PAGE_SIZE);
     return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4x-0002LM-53; Tue, 19 Feb 2013 13:17:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4v-0002JO-A3
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:49 +0000
Received: from [85.158.138.51:10331] by server-5.bemta-3.messagelabs.com id
	B7/11-04457-97B73215; Tue, 19 Feb 2013 13:17:45 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361279865!28250605!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10062 invoked from network); 19 Feb 2013 13:17:45 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 13:17:45 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 5F080C561AB;
	Tue, 19 Feb 2013 13:17:44 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:29 +0000
Message-Id: <1361279850-8246-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 4/5] exec, memory: Call to xen_modified_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>
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 patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c   |    4 ++++
 memory.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 511777b..401f9bc 100644
--- a/exec.c
+++ b/exec.c
@@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
            0xff, size >> TARGET_PAGE_BITS);
 
+    if (xen_enabled())
+        xen_modified_memory(new_block->offset, size);
+
     if (kvm_enabled())
         kvm_setup_guest_memory(new_block->host, size);
 
@@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 7c20a07..6e0c596 100644
--- a/memory.c
+++ b/memory.c
@@ -16,6 +16,7 @@
 #include "ioport.h"
 #include "bitops.h"
 #include "kvm.h"
+#include "hw/xen.h"
 #include <assert.h>
 
 unsigned memory_region_transaction_depth = 0;
@@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
 {
     assert(mr->terminates);
+    if (xen_enabled())
+        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
+                            TARGET_PAGE_SIZE);
     return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4x-0002Lo-IS; Tue, 19 Feb 2013 13:17:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4v-0002Jw-VM
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:50 +0000
Received: from [85.158.139.83:34140] by server-1.bemta-5.messagelabs.com id
	30/D4-29263-D7B73215; Tue, 19 Feb 2013 13:17:49 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361279868!27925365!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6018 invoked from network); 19 Feb 2013 13:17:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:17:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E5690C5619C;
	Tue, 19 Feb 2013 13:17:40 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:27 +0000
Message-Id: <1361279850-8246-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 2/5] xen: Introduce xen_modified_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>
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 function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 hw/xen.h   |    1 +
 xen-all.c  |   21 +++++++++++++++++++++
 xen-stub.c |    4 ++++
 3 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index 2162111..359a275 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -45,6 +45,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/xen-all.c b/xen-all.c
index 6b4e511..121289d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1135,3 +1135,24 @@ void destroy_hvm_domain(bool reboot)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(cpu_physical_memory_get_dirty_tracking())) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 25317ec..7b54477 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -48,3 +48,7 @@ int xen_init(void)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:17: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 1U7n4x-0002Lo-IS; Tue, 19 Feb 2013 13:17:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4v-0002Jw-VM
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:50 +0000
Received: from [85.158.139.83:34140] by server-1.bemta-5.messagelabs.com id
	30/D4-29263-D7B73215; Tue, 19 Feb 2013 13:17:49 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361279868!27925365!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6018 invoked from network); 19 Feb 2013 13:17:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:17:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E5690C5619C;
	Tue, 19 Feb 2013 13:17:40 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:27 +0000
Message-Id: <1361279850-8246-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 2/5] xen: Introduce xen_modified_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>
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 function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 hw/xen.h   |    1 +
 xen-all.c  |   21 +++++++++++++++++++++
 xen-stub.c |    4 ++++
 3 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index 2162111..359a275 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -45,6 +45,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/xen-all.c b/xen-all.c
index 6b4e511..121289d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1135,3 +1135,24 @@ void destroy_hvm_domain(bool reboot)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(cpu_physical_memory_get_dirty_tracking())) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 25317ec..7b54477 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -48,3 +48,7 @@ int xen_init(void)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n50-0002Of-1v; Tue, 19 Feb 2013 13:17:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4z-0002Mv-16
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:53 +0000
Received: from [85.158.139.83:9360] by server-16.bemta-5.messagelabs.com id
	2D/7F-14948-08B73215; Tue, 19 Feb 2013 13:17:52 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361279865!28208719!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15841 invoked from network); 19 Feb 2013 13:17:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:17:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id D9456C561AA;
	Tue, 19 Feb 2013 13:17:42 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:28 +0000
Message-Id: <1361279850-8246-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 3/5] exec: Introduce helper to set dirty 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>
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 new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |   45 +++++++++++++++++----------------------------
 1 files changed, 17 insertions(+), 28 deletions(-)

diff --git a/exec.c b/exec.c
index 6c206ff..511777b 100644
--- a/exec.c
+++ b/exec.c
@@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -4081,6 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
+	    invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -4211,13 +4218,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -4561,13 +4562,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4639,13 +4634,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:17:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n50-0002Of-1v; Tue, 19 Feb 2013 13:17:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n4z-0002Mv-16
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:17:53 +0000
Received: from [85.158.139.83:9360] by server-16.bemta-5.messagelabs.com id
	2D/7F-14948-08B73215; Tue, 19 Feb 2013 13:17:52 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361279865!28208719!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15841 invoked from network); 19 Feb 2013 13:17:48 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 13:17:48 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id D9456C561AA;
	Tue, 19 Feb 2013 13:17:42 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:28 +0000
Message-Id: <1361279850-8246-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 3/5] exec: Introduce helper to set dirty 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>
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 new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |   45 +++++++++++++++++----------------------------
 1 files changed, 17 insertions(+), 28 deletions(-)

diff --git a/exec.c b/exec.c
index 6c206ff..511777b 100644
--- a/exec.c
+++ b/exec.c
@@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -4081,6 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
+	    invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -4211,13 +4218,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -4561,13 +4562,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4639,13 +4634,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n5b-0002sB-HN; Tue, 19 Feb 2013 13:18:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n5Z-0002qp-O1
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:18:29 +0000
Received: from [193.109.254.147:61256] by server-5.bemta-14.messagelabs.com id
	C7/9E-21539-5AB73215; Tue, 19 Feb 2013 13:18:29 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361279860!8893837!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1735 invoked from network); 19 Feb 2013 13:17:40 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-27.messagelabs.com with SMTP;
	19 Feb 2013 13:17:40 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id F1813C5619A;
	Tue, 19 Feb 2013 13:17:39 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:26 +0000
Message-Id: <1361279850-8246-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 1/5] QMP,
	Introduce xen-set-global-dirty-log 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>
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 command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |    6 ++++++
 xen-stub.c       |    5 +++++
 4 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index a669e98..bb0d7c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -905,3 +905,16 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.3
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index bf1df49..0de68df 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -472,6 +472,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/xen-all.c b/xen-all.c
index 3256509..6b4e511 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -12,6 +12,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -524,6 +525,11 @@ static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
     .log_stop = xen_log_stop,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    cpu_physical_memory_set_dirty_tracking(!!enable);
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..25317ec 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:18:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13: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 1U7n5b-0002sB-HN; Tue, 19 Feb 2013 13:18:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7n5Z-0002qp-O1
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:18:29 +0000
Received: from [193.109.254.147:61256] by server-5.bemta-14.messagelabs.com id
	C7/9E-21539-5AB73215; Tue, 19 Feb 2013 13:18:29 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361279860!8893837!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1735 invoked from network); 19 Feb 2013 13:17:40 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-27.messagelabs.com with SMTP;
	19 Feb 2013 13:17:40 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id F1813C5619A;
	Tue, 19 Feb 2013 13:17:39 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 13:17:26 +0000
Message-Id: <1361279850-8246-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv4 1/5] QMP,
	Introduce xen-set-global-dirty-log 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>
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 command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |    6 ++++++
 xen-stub.c       |    5 +++++
 4 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index a669e98..bb0d7c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -905,3 +905,16 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.3
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index bf1df49..0de68df 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -472,6 +472,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/xen-all.c b/xen-all.c
index 3256509..6b4e511 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -12,6 +12,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -524,6 +525,11 @@ static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
     .log_stop = xen_log_stop,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    cpu_physical_memory_set_dirty_tracking(!!enable);
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..25317ec 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:29:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:29: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 1U7nFv-0004Gu-0O; Tue, 19 Feb 2013 13:29: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 1U7nFt-0004Gp-Ny
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:29:09 +0000
Received: from [85.158.137.99:52416] by server-4.bemta-3.messagelabs.com id
	94/5F-17521-02E73215; Tue, 19 Feb 2013 13:29:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361280544!14672898!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17016 invoked from network); 19 Feb 2013 13:29:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:29:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1607923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 13:29: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.297.1; Tue, 19 Feb 2013 13:29:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7nFn-0002b4-LL; Tue, 19 Feb 2013 13:29:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7nFn-0004mT-DQ;
	Tue, 19 Feb 2013 13:29:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.32285.167144.873527@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 13:29:01 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@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] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[PATCHv4 00/11] libxl: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - libxl patchset"):
> This patch series consists of 2	parts:
> * 11 patches to	libxl
> * 5 patches to QEMU
> 
> The 11 patches to libxl are unchanged since version 3 of the patch,
> but have Acked-By lines reintroduced.

Thanks for this!  You've made this very convenient.

Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
object.

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 Feb 19 13:29:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:29: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 1U7nFv-0004Gu-0O; Tue, 19 Feb 2013 13:29: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 1U7nFt-0004Gp-Ny
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:29:09 +0000
Received: from [85.158.137.99:52416] by server-4.bemta-3.messagelabs.com id
	94/5F-17521-02E73215; Tue, 19 Feb 2013 13:29:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361280544!14672898!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17016 invoked from network); 19 Feb 2013 13:29:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:29:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1607923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 13:29: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.297.1; Tue, 19 Feb 2013 13:29:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7nFn-0002b4-LL; Tue, 19 Feb 2013 13:29:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7nFn-0004mT-DQ;
	Tue, 19 Feb 2013 13:29:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.32285.167144.873527@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 13:29:01 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@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] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("[PATCHv4 00/11] libxl: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - libxl patchset"):
> This patch series consists of 2	parts:
> * 11 patches to	libxl
> * 5 patches to QEMU
> 
> The 11 patches to libxl are unchanged since version 3 of the patch,
> but have Acked-By lines reintroduced.

Thanks for this!  You've made this very convenient.

Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
object.

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 Feb 19 13:36:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7nMe-0004U9-Sr; Tue, 19 Feb 2013 13:36:08 +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 1U7nMd-0004U1-3d
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:36:07 +0000
Received: from [85.158.138.51:52352] by server-16.bemta-3.messagelabs.com id
	A7/4D-02727-6CF73215; Tue, 19 Feb 2013 13:36:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361280962!24150328!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28138 invoked from network); 19 Feb 2013 13:36:03 -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; 19 Feb 2013 13:36:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 13:36:02 +0000
Message-Id: <51238E0A02000078000BF6BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 13:36:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
	<20771.32285.167144.873527@mariner.uk.xensource.com>
In-Reply-To: <20771.32285.167144.873527@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:29, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Alex Bligh writes ("[PATCHv4 00/11] libxl: Enabling live-migrate on HVM on 
> qemu-xen device model in 4.2 - libxl patchset"):
>> This patch series consists of 2	parts:
>> * 11 patches to	libxl
>> * 5 patches to QEMU
>> 
>> The 11 patches to libxl are unchanged since version 3 of the patch,
>> but have Acked-By lines reintroduced.
> 
> Thanks for this!  You've made this very convenient.
> 
> Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
> object.

Fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:36:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7nMe-0004U9-Sr; Tue, 19 Feb 2013 13:36:08 +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 1U7nMd-0004U1-3d
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:36:07 +0000
Received: from [85.158.138.51:52352] by server-16.bemta-3.messagelabs.com id
	A7/4D-02727-6CF73215; Tue, 19 Feb 2013 13:36:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361280962!24150328!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28138 invoked from network); 19 Feb 2013 13:36:03 -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; 19 Feb 2013 13:36:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 13:36:02 +0000
Message-Id: <51238E0A02000078000BF6BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 13:36:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
	<20771.32285.167144.873527@mariner.uk.xensource.com>
In-Reply-To: <20771.32285.167144.873527@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:29, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Alex Bligh writes ("[PATCHv4 00/11] libxl: Enabling live-migrate on HVM on 
> qemu-xen device model in 4.2 - libxl patchset"):
>> This patch series consists of 2	parts:
>> * 11 patches to	libxl
>> * 5 patches to QEMU
>> 
>> The 11 patches to libxl are unchanged since version 3 of the patch,
>> but have Acked-By lines reintroduced.
> 
> Thanks for this!  You've made this very convenient.
> 
> Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
> object.

Fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:41:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:41: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 1U7nRo-0004dk-KY; Tue, 19 Feb 2013 13:41:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7nRl-0004de-Tk
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:41:26 +0000
Received: from [85.158.137.99:43497] by server-10.bemta-3.messagelabs.com id
	CB/38-10609-10183215; Tue, 19 Feb 2013 13:41:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361281279!12282177!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17061 invoked from network); 19 Feb 2013 13:41:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:41:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7754129"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 13:41:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 08:41:18 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7nRe-00082d-3i;
	Tue, 19 Feb 2013 13:41:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 13:41:17 +0000
Message-ID: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.8.1.2
MIME-Version: 1.0
Cc: samuel.thibault@ens-lyon.org, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH] mini-os: implement poll(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

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..aae02df 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,71 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    if (_timeout != -1) {
+        /* Timeout in poll is in millisecond. */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
+        timeo = &_timeo;
+    }
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        /* map POLL* into readfds and writefds */
+        /* POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        _pfd[i].revents = 0;
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (FD_ISSET(fd, &efds)) {
+             /* anything bad happens we set POLLERR, ignoring PULLHUP
+              * POLLNVAL */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    return ret;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1449,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:41:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:41: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 1U7nRo-0004dk-KY; Tue, 19 Feb 2013 13:41:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7nRl-0004de-Tk
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 13:41:26 +0000
Received: from [85.158.137.99:43497] by server-10.bemta-3.messagelabs.com id
	CB/38-10609-10183215; Tue, 19 Feb 2013 13:41:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361281279!12282177!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17061 invoked from network); 19 Feb 2013 13:41:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:41:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7754129"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 13:41:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 08:41:18 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7nRe-00082d-3i;
	Tue, 19 Feb 2013 13:41:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 13:41:17 +0000
Message-ID: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.8.1.2
MIME-Version: 1.0
Cc: samuel.thibault@ens-lyon.org, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH] mini-os: implement poll(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

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..aae02df 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,71 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    if (_timeout != -1) {
+        /* Timeout in poll is in millisecond. */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
+        timeo = &_timeo;
+    }
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        /* map POLL* into readfds and writefds */
+        /* POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        _pfd[i].revents = 0;
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (FD_ISSET(fd, &efds)) {
+             /* anything bad happens we set POLLERR, ignoring PULLHUP
+              * POLLNVAL */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    return ret;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1449,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:47:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:47: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 1U7nXs-00055L-3J; Tue, 19 Feb 2013 13:47: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 1U7nXq-00055E-NG
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 13:47:42 +0000
Received: from [193.109.254.147:56418] by server-14.bemta-14.messagelabs.com
	id 3E/45-02031-D7283215; Tue, 19 Feb 2013 13:47:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361281637!6497012!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 770 invoked from network); 19 Feb 2013 13:47:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:47:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1608754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 13:47: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.297.1;
	Tue, 19 Feb 2013 13:47:17 +0000
Message-ID: <1361281636.1051.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 19 Feb 2013 13:47:16 +0000
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()). 

A few people have made this mistake already, perhaps this helps make it
more obvious what is going on...

8<--------------------------------

>From 7b93077e2cda5881b594d9c7e733e617df87d7c0 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 19 Feb 2013 10:46:12 +0000
Subject: [PATCH] xen/netback: refactor xenvif_carrier_on from xenvif_connect

Several people have been confused by the vif reference count taken by
xenvif_connect() being dropped in xenvif_carrier_off(). Factor out bringing
the carrier up (and the associated reference grab) to try and make the
relationship more obvious.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netback/interface.c |   49 +++++++++++++++++++---------------
 1 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index d984141..059d726 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -307,6 +307,32 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
+static void xenvif_carrier_on(struct xenvif *vif)
+{
+	xenvif_get(vif);
+
+	rtnl_lock();
+	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
+		dev_set_mtu(vif->dev, ETH_DATA_LEN);
+	netdev_update_features(vif->dev);
+	netif_carrier_on(vif->dev);
+	if (netif_running(vif->dev))
+		xenvif_up(vif);
+	rtnl_unlock();
+}
+
+void xenvif_carrier_off(struct xenvif *vif)
+{
+	struct net_device *dev = vif->dev;
+
+	rtnl_lock();
+	netif_carrier_off(dev); /* discard queued packets */
+	if (netif_running(dev))
+		xenvif_down(vif);
+	rtnl_unlock();
+	xenvif_put(vif);
+}
+
 int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn)
 {
@@ -328,16 +354,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
-
-	rtnl_lock();
-	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
-		dev_set_mtu(vif->dev, ETH_DATA_LEN);
-	netdev_update_features(vif->dev);
-	netif_carrier_on(vif->dev);
-	if (netif_running(vif->dev))
-		xenvif_up(vif);
-	rtnl_unlock();
+	xenvif_carrier_on(vif);
 
 	return 0;
 err_unmap:
@@ -346,18 +363,6 @@ err:
 	return err;
 }
 
-void xenvif_carrier_off(struct xenvif *vif)
-{
-	struct net_device *dev = vif->dev;
-
-	rtnl_lock();
-	netif_carrier_off(dev); /* discard queued packets */
-	if (netif_running(dev))
-		xenvif_down(vif);
-	rtnl_unlock();
-	xenvif_put(vif);
-}
-
 void xenvif_disconnect(struct xenvif *vif)
 {
 	if (netif_carrier_ok(vif->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 Tue Feb 19 13:47:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:47: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 1U7nXs-00055L-3J; Tue, 19 Feb 2013 13:47: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 1U7nXq-00055E-NG
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 13:47:42 +0000
Received: from [193.109.254.147:56418] by server-14.bemta-14.messagelabs.com
	id 3E/45-02031-D7283215; Tue, 19 Feb 2013 13:47:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361281637!6497012!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 770 invoked from network); 19 Feb 2013 13:47:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:47:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1608754"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 13:47: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.297.1;
	Tue, 19 Feb 2013 13:47:17 +0000
Message-ID: <1361281636.1051.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 19 Feb 2013 13:47:16 +0000
In-Reply-To: <51233FF502000078000BF4AE@nat28.tlf.novell.com>
References: <1361219360-29176-1-git-send-email-drjones@redhat.com>
	<20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> The core of
> it is that the put here parallels the one in netbk_tx_err(), and
> the one in xenvif_carrier_off() matches the get from
> xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()). 

A few people have made this mistake already, perhaps this helps make it
more obvious what is going on...

8<--------------------------------

>From 7b93077e2cda5881b594d9c7e733e617df87d7c0 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 19 Feb 2013 10:46:12 +0000
Subject: [PATCH] xen/netback: refactor xenvif_carrier_on from xenvif_connect

Several people have been confused by the vif reference count taken by
xenvif_connect() being dropped in xenvif_carrier_off(). Factor out bringing
the carrier up (and the associated reference grab) to try and make the
relationship more obvious.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netback/interface.c |   49 +++++++++++++++++++---------------
 1 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index d984141..059d726 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -307,6 +307,32 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
+static void xenvif_carrier_on(struct xenvif *vif)
+{
+	xenvif_get(vif);
+
+	rtnl_lock();
+	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
+		dev_set_mtu(vif->dev, ETH_DATA_LEN);
+	netdev_update_features(vif->dev);
+	netif_carrier_on(vif->dev);
+	if (netif_running(vif->dev))
+		xenvif_up(vif);
+	rtnl_unlock();
+}
+
+void xenvif_carrier_off(struct xenvif *vif)
+{
+	struct net_device *dev = vif->dev;
+
+	rtnl_lock();
+	netif_carrier_off(dev); /* discard queued packets */
+	if (netif_running(dev))
+		xenvif_down(vif);
+	rtnl_unlock();
+	xenvif_put(vif);
+}
+
 int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn)
 {
@@ -328,16 +354,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
-
-	rtnl_lock();
-	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
-		dev_set_mtu(vif->dev, ETH_DATA_LEN);
-	netdev_update_features(vif->dev);
-	netif_carrier_on(vif->dev);
-	if (netif_running(vif->dev))
-		xenvif_up(vif);
-	rtnl_unlock();
+	xenvif_carrier_on(vif);
 
 	return 0;
 err_unmap:
@@ -346,18 +363,6 @@ err:
 	return err;
 }
 
-void xenvif_carrier_off(struct xenvif *vif)
-{
-	struct net_device *dev = vif->dev;
-
-	rtnl_lock();
-	netif_carrier_off(dev); /* discard queued packets */
-	if (netif_running(dev))
-		xenvif_down(vif);
-	rtnl_unlock();
-	xenvif_put(vif);
-}
-
 void xenvif_disconnect(struct xenvif *vif)
 {
 	if (netif_carrier_ok(vif->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 Tue Feb 19 13:55:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:55: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 1U7ner-0005MX-56; Tue, 19 Feb 2013 13:54:57 +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 1U7nep-0005MO-6A
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 13:54:55 +0000
Received: from [85.158.137.99:4020] by server-9.bemta-3.messagelabs.com id
	B9/C6-09484-E2483215; Tue, 19 Feb 2013 13:54:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361282093!17050374!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20355 invoked from network); 19 Feb 2013 13:54:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:54:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1609099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 13:54: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.297.1;
	Tue, 19 Feb 2013 13:54:53 +0000
Message-ID: <1361282091.1051.101.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Tue, 19 Feb 2013 13:54:51 +0000
In-Reply-To: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
References: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] question regarding 2.6.18 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 13:51 +0000, Andrew Jones wrote:
> Hi Ian,
> 
> I believe there's a problem with the 2.6.18 reference tree backport of
> 48856286b64e: "xen/netback: shutdown the ring if it contains garbage",
> which is c/s 1219. While the version in Linus' tree should be fine,
> as xen_netbk_tx_action runs in a kthread, the 2.6.18 version needs
> something different. In 2.6.18 net_tx_action is a tasklet, thus calling
> xenvif_carrier_off from it is problematic due to needing the rtnl
> mutex. A proposal I have that I haven't tried yet is for
> netbk_fatal_tx_err to schedule xenvif_carrier_off in a workqueue. This
> is a bit ugly though since the main point of xenvif_carrier_off is to
> queue linkwatch work. I'm wondering if you or anyone else have other
> suggestions.

Jan was looking into something of this nature, not sure wht the status
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 Tue Feb 19 13:55:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:55: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 1U7ner-0005MX-56; Tue, 19 Feb 2013 13:54:57 +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 1U7nep-0005MO-6A
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 13:54:55 +0000
Received: from [85.158.137.99:4020] by server-9.bemta-3.messagelabs.com id
	B9/C6-09484-E2483215; Tue, 19 Feb 2013 13:54:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361282093!17050374!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20355 invoked from network); 19 Feb 2013 13:54:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:54:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1609099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 13:54: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.297.1;
	Tue, 19 Feb 2013 13:54:53 +0000
Message-ID: <1361282091.1051.101.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Tue, 19 Feb 2013 13:54:51 +0000
In-Reply-To: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
References: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] question regarding 2.6.18 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 13:51 +0000, Andrew Jones wrote:
> Hi Ian,
> 
> I believe there's a problem with the 2.6.18 reference tree backport of
> 48856286b64e: "xen/netback: shutdown the ring if it contains garbage",
> which is c/s 1219. While the version in Linus' tree should be fine,
> as xen_netbk_tx_action runs in a kthread, the 2.6.18 version needs
> something different. In 2.6.18 net_tx_action is a tasklet, thus calling
> xenvif_carrier_off from it is problematic due to needing the rtnl
> mutex. A proposal I have that I haven't tried yet is for
> netbk_fatal_tx_err to schedule xenvif_carrier_off in a workqueue. This
> is a bit ugly though since the main point of xenvif_carrier_off is to
> queue linkwatch work. I'm wondering if you or anyone else have other
> suggestions.

Jan was looking into something of this nature, not sure wht the status
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 Tue Feb 19 13:59:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:59: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 1U7njB-0005W6-R0; Tue, 19 Feb 2013 13:59: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 1U7njB-0005W1-50
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 13:59:25 +0000
Received: from [85.158.143.99:27034] by server-3.bemta-4.messagelabs.com id
	07/5F-08920-C3583215; Tue, 19 Feb 2013 13:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361282362!22899817!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9382 invoked from network); 19 Feb 2013 13:59:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7757429"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 13:59:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 08:59:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7nj7-0008KW-5n;
	Tue, 19 Feb 2013 13:59:21 +0000
Date: Tue, 19 Feb 2013 13:59:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	linux-arm-kernel@lists.infradead.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ioremap can't be used to map ring pages on ARM because it uses device
memory caching attributes (MT_DEVICE*).

Introduce a Xen specific abstraction to map ring pages, called
xen_remap, that is defined as ioremap on x86 (no behavioral changes).
On ARM it explicitly calls __arm_ioremap with the right caching
attributes: MT_MEMORY.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index c6b9096..30cdacb 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,6 +1,7 @@
 #ifndef _ASM_ARM_XEN_PAGE_H
 #define _ASM_ARM_XEN_PAGE_H
 
+#include <asm/mach/map.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
 
@@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	return __set_phys_to_machine(pfn, mfn);
 }
+
+#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6aef9fb 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
 void make_lowmem_page_readonly(void *vaddr);
 void make_lowmem_page_readwrite(void *vaddr);
 
+#define xen_remap(cookie, size) ioremap((cookie), (size));
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 19843ec..682210d7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
 	if (r < 0 || v == 0)
 		goto err;
 	mfn = v;
-	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
 	if (info->intf == NULL)
 		goto err;
 	info->vtermno = HVC_COOKIE;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7038de5..1c2a1e5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,7 +1146,7 @@ int gnttab_resume(void)
 		return gnttab_map(0, nr_grant_frames - 1);
 
 	if (gnttab_shared.addr == NULL) {
-		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
 						PAGE_SIZE * max_nr_gframes);
 		if (gnttab_shared.addr == NULL) {
 			printk(KERN_WARNING
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 038b71d..3325884 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -769,7 +769,7 @@ static int __init xenbus_init(void)
 			goto out_error;
 		xen_store_mfn = (unsigned long)v;
 		xen_store_interface =
-			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
 		break;
 	default:
 		pr_warn("Xenstore state unknown\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 13:59:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 13:59: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 1U7njB-0005W6-R0; Tue, 19 Feb 2013 13:59: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 1U7njB-0005W1-50
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 13:59:25 +0000
Received: from [85.158.143.99:27034] by server-3.bemta-4.messagelabs.com id
	07/5F-08920-C3583215; Tue, 19 Feb 2013 13:59:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361282362!22899817!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9382 invoked from network); 19 Feb 2013 13:59:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 13:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7757429"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 13:59:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 08:59:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7nj7-0008KW-5n;
	Tue, 19 Feb 2013 13:59:21 +0000
Date: Tue, 19 Feb 2013 13:59:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	linux-arm-kernel@lists.infradead.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ioremap can't be used to map ring pages on ARM because it uses device
memory caching attributes (MT_DEVICE*).

Introduce a Xen specific abstraction to map ring pages, called
xen_remap, that is defined as ioremap on x86 (no behavioral changes).
On ARM it explicitly calls __arm_ioremap with the right caching
attributes: MT_MEMORY.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index c6b9096..30cdacb 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,6 +1,7 @@
 #ifndef _ASM_ARM_XEN_PAGE_H
 #define _ASM_ARM_XEN_PAGE_H
 
+#include <asm/mach/map.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
 
@@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	return __set_phys_to_machine(pfn, mfn);
 }
+
+#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6aef9fb 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
 void make_lowmem_page_readonly(void *vaddr);
 void make_lowmem_page_readwrite(void *vaddr);
 
+#define xen_remap(cookie, size) ioremap((cookie), (size));
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 19843ec..682210d7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
 	if (r < 0 || v == 0)
 		goto err;
 	mfn = v;
-	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
 	if (info->intf == NULL)
 		goto err;
 	info->vtermno = HVC_COOKIE;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7038de5..1c2a1e5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,7 +1146,7 @@ int gnttab_resume(void)
 		return gnttab_map(0, nr_grant_frames - 1);
 
 	if (gnttab_shared.addr == NULL) {
-		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
 						PAGE_SIZE * max_nr_gframes);
 		if (gnttab_shared.addr == NULL) {
 			printk(KERN_WARNING
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 038b71d..3325884 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -769,7 +769,7 @@ static int __init xenbus_init(void)
 			goto out_error;
 		xen_store_mfn = (unsigned long)v;
 		xen_store_interface =
-			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
 		break;
 	default:
 		pr_warn("Xenstore state unknown\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:06:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7nq0-0005o6-Vy; Tue, 19 Feb 2013 14:06:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7npz-0005o1-2E
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:06:27 +0000
Received: from [85.158.138.51:3733] by server-11.bemta-3.messagelabs.com id
	D4/C7-10249-2E683215; Tue, 19 Feb 2013 14:06:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361282784!28171094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22600 invoked from network); 19 Feb 2013 14:06:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:06:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1609663"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 14:06:24 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 19 Feb 2013
	14:06:24 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 14:06:23 +0000
Thread-Topic: [Xen-devel] [PATCH] mini-os: implement poll(2)
Thread-Index: Ac4OqkzJkzzTn7GqSoWUDtsRZiOYuw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361281277-5637-1-git-send-email-wei.liu2@citrix.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: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> It is just a wrapper around select(2).
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  extras/mini-os/include/posix/poll.h |    1 +
>  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
>  2 files changed, 90 insertions(+), 1 deletion(-)
>  create mode 100644 extras/mini-os/include/posix/poll.h
> 
> diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> new file mode 100644
> index 0000000..06fb41a
> --- /dev/null
> +++ b/extras/mini-os/include/posix/poll.h
> @@ -0,0 +1 @@
> +#include <sys/poll.h>
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 3cc3340..aae02df 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -31,6 +31,7 @@
>  #include <tpm_tis.h>
>  #include <xenbus.h>
>  #include <xenstore.h>
> +#include <poll.h>
>  
>  #include <sys/types.h>
>  #include <sys/unistd.h>
> @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
>  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
>  #endif
>  
> +#ifdef LIBC_DEBUG
> +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> +{
> +    int i, comma, fd;
> +
> +    printk("[");
> +    comma = 0;
> +    for (i = 0; i < nfds; i++) {
> +        fd = pfd[i].fd;
> +        if (comma)
> +            printk(", ");
> +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> +            pfd[i].events);
> +            comma = 1;
> +    }
> +    printk("]");
> +
> +    printk(", %d, %d", nfds, timeout);
> +}
> +#else
> +#define dump_pollfds(pfds, nfds, timeout)
> +#endif
> +
>  /* Just poll without blocking */
>  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
>  {
> @@ -983,6 +1007,71 @@ out:
>      return ret;
>  }
>  
> +/* Wrap around select */
> +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> +{
> +    int ret;
> +    int i, fd;
> +    struct timeval _timeo, *timeo = NULL;
> +    fd_set rfds, wfds, efds;
> +    int max_fd = -1;
> +
> +    DEBUG("poll(");
> +    dump_pollfds(_pfd, _nfds, _timeout);
> +    DEBUG(")\n");
> +
> +    if (_timeout != -1) {

should be _timeout >= 0, any negative value will cause an infinite wait.

> +        /* Timeout in poll is in millisecond. */
> +        _timeo.tv_sec  = _timeout / 1000;
> +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;

why not _timeout % 1000? gcc can also optimize and detect you have a
division and a module and use only a single instruction in x86.

> +        timeo = &_timeo;
> +    }
> +
> +    FD_ZERO(&rfds);
> +    FD_ZERO(&wfds);
> +    FD_ZERO(&efds);
> +
> +    for (i = 0; i < _nfds; i++) {
> +        fd = _pfd[i].fd;

I think you should check if fd is < 0 and return EINVAL (not sure about
the error code). Well.. probably you should check fd in range 0..1023.

> +        /* map POLL* into readfds and writefds */
> +        /* POLLIN  -> readfds
> +         * POLLOUT -> writefds
> +         * POLL*   -> none
> +         */
> +        if (_pfd[i].events & POLLIN)
> +            FD_SET(fd, &rfds);
> +        if (_pfd[i].events & POLLOUT)
> +            FD_SET(fd, &wfds);
> +        /* always set exceptfds */
> +        FD_SET(fd, &efds);
> +        _pfd[i].revents = 0;
> +        if (fd > max_fd)
> +            max_fd = fd;
> +    }
> +
> +    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
> +
> +    for (i = 0; i < _nfds; i++) {
> +        fd = _pfd[i].fd;
> +        if (FD_ISSET(fd, &efds)) {
> +             /* anything bad happens we set POLLERR, ignoring PULLHUP
> +              * POLLNVAL */
> +            _pfd[i].revents |= POLLERR;
> +            continue;
> +        }
> +        if (FD_ISSET(fd, &rfds))
> +            _pfd[i].revents |= POLLIN;
> +        if (FD_ISSET(fd, &wfds))
> +            _pfd[i].revents |= POLLOUT;
> +    }
> +
> +    DEBUG("poll(");
> +    dump_pollfds(_pfd, _nfds, _timeout);
> +    DEBUG(")\n");
> +

you probably want to save and restore errno or are we sure dump_pollfds
cannot overwrite errno ?

> +    return ret;
> +}
> +
>  #ifdef HAVE_LWIP
>  int socket(int domain, int type, int protocol)
>  {
> @@ -1360,7 +1449,6 @@ unsupported_function(int, tcgetattr, 0);
>  unsupported_function(int, grantpt, -1);
>  unsupported_function(int, unlockpt, -1);
>  unsupported_function(char *, ptsname, NULL);
> -unsupported_function(int, poll, -1);
>  
>  /* net/if.h */
>  unsupported_function_log(unsigned int, if_nametoindex, -1);

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:06:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7nq0-0005o6-Vy; Tue, 19 Feb 2013 14:06:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7npz-0005o1-2E
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:06:27 +0000
Received: from [85.158.138.51:3733] by server-11.bemta-3.messagelabs.com id
	D4/C7-10249-2E683215; Tue, 19 Feb 2013 14:06:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361282784!28171094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22600 invoked from network); 19 Feb 2013 14:06:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:06:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1609663"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 14:06:24 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 19 Feb 2013
	14:06:24 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 14:06:23 +0000
Thread-Topic: [Xen-devel] [PATCH] mini-os: implement poll(2)
Thread-Index: Ac4OqkzJkzzTn7GqSoWUDtsRZiOYuw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361281277-5637-1-git-send-email-wei.liu2@citrix.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: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> It is just a wrapper around select(2).
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  extras/mini-os/include/posix/poll.h |    1 +
>  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
>  2 files changed, 90 insertions(+), 1 deletion(-)
>  create mode 100644 extras/mini-os/include/posix/poll.h
> 
> diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> new file mode 100644
> index 0000000..06fb41a
> --- /dev/null
> +++ b/extras/mini-os/include/posix/poll.h
> @@ -0,0 +1 @@
> +#include <sys/poll.h>
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 3cc3340..aae02df 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -31,6 +31,7 @@
>  #include <tpm_tis.h>
>  #include <xenbus.h>
>  #include <xenstore.h>
> +#include <poll.h>
>  
>  #include <sys/types.h>
>  #include <sys/unistd.h>
> @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
>  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
>  #endif
>  
> +#ifdef LIBC_DEBUG
> +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> +{
> +    int i, comma, fd;
> +
> +    printk("[");
> +    comma = 0;
> +    for (i = 0; i < nfds; i++) {
> +        fd = pfd[i].fd;
> +        if (comma)
> +            printk(", ");
> +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> +            pfd[i].events);
> +            comma = 1;
> +    }
> +    printk("]");
> +
> +    printk(", %d, %d", nfds, timeout);
> +}
> +#else
> +#define dump_pollfds(pfds, nfds, timeout)
> +#endif
> +
>  /* Just poll without blocking */
>  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
>  {
> @@ -983,6 +1007,71 @@ out:
>      return ret;
>  }
>  
> +/* Wrap around select */
> +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> +{
> +    int ret;
> +    int i, fd;
> +    struct timeval _timeo, *timeo = NULL;
> +    fd_set rfds, wfds, efds;
> +    int max_fd = -1;
> +
> +    DEBUG("poll(");
> +    dump_pollfds(_pfd, _nfds, _timeout);
> +    DEBUG(")\n");
> +
> +    if (_timeout != -1) {

should be _timeout >= 0, any negative value will cause an infinite wait.

> +        /* Timeout in poll is in millisecond. */
> +        _timeo.tv_sec  = _timeout / 1000;
> +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;

why not _timeout % 1000? gcc can also optimize and detect you have a
division and a module and use only a single instruction in x86.

> +        timeo = &_timeo;
> +    }
> +
> +    FD_ZERO(&rfds);
> +    FD_ZERO(&wfds);
> +    FD_ZERO(&efds);
> +
> +    for (i = 0; i < _nfds; i++) {
> +        fd = _pfd[i].fd;

I think you should check if fd is < 0 and return EINVAL (not sure about
the error code). Well.. probably you should check fd in range 0..1023.

> +        /* map POLL* into readfds and writefds */
> +        /* POLLIN  -> readfds
> +         * POLLOUT -> writefds
> +         * POLL*   -> none
> +         */
> +        if (_pfd[i].events & POLLIN)
> +            FD_SET(fd, &rfds);
> +        if (_pfd[i].events & POLLOUT)
> +            FD_SET(fd, &wfds);
> +        /* always set exceptfds */
> +        FD_SET(fd, &efds);
> +        _pfd[i].revents = 0;
> +        if (fd > max_fd)
> +            max_fd = fd;
> +    }
> +
> +    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
> +
> +    for (i = 0; i < _nfds; i++) {
> +        fd = _pfd[i].fd;
> +        if (FD_ISSET(fd, &efds)) {
> +             /* anything bad happens we set POLLERR, ignoring PULLHUP
> +              * POLLNVAL */
> +            _pfd[i].revents |= POLLERR;
> +            continue;
> +        }
> +        if (FD_ISSET(fd, &rfds))
> +            _pfd[i].revents |= POLLIN;
> +        if (FD_ISSET(fd, &wfds))
> +            _pfd[i].revents |= POLLOUT;
> +    }
> +
> +    DEBUG("poll(");
> +    dump_pollfds(_pfd, _nfds, _timeout);
> +    DEBUG(")\n");
> +

you probably want to save and restore errno or are we sure dump_pollfds
cannot overwrite errno ?

> +    return ret;
> +}
> +
>  #ifdef HAVE_LWIP
>  int socket(int domain, int type, int protocol)
>  {
> @@ -1360,7 +1449,6 @@ unsupported_function(int, tcgetattr, 0);
>  unsupported_function(int, grantpt, -1);
>  unsupported_function(int, unlockpt, -1);
>  unsupported_function(char *, ptsname, NULL);
> -unsupported_function(int, poll, -1);
>  
>  /* net/if.h */
>  unsupported_function_log(unsigned int, if_nametoindex, -1);

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:13:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:13: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 1U7nwT-000613-15; Tue, 19 Feb 2013 14:13:09 +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 1U7nwR-00060v-A1
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:13:07 +0000
Received: from [85.158.139.211:24815] by server-8.bemta-5.messagelabs.com id
	B1/F2-19075-27883215; Tue, 19 Feb 2013 14:13:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361283141!18197131!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzQ1Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzQ1Mzc=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5443 invoked from network); 19 Feb 2013 14:12:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 14:12:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (jorabe mo14) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d07f2ap1JD9cFJ ;
	Tue, 19 Feb 2013 15:12:20 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 17E301884C; Tue, 19 Feb 2013 15:12:19 +0100 (CET)
Date: Tue, 19 Feb 2013 15:12:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219141219.GA31344@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130219114217.GA8133@aepfle.de>
	<1361274510.1051.99.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361274510.1051.99.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, Ian Campbell wrote:

> > typedef struct {
> >     int xlflags; /* LIBXL_SUSPEND_* */
> 
> Why is this called "xlflags"? xl isn't the only user of this interface.

To make it clear that libxl is the consumer, not libxc. But I think the
comment above makes it clear that libxl flags are expected. I will
rename it to 'flags'.

> >     int max_iters;
> >     int max_factor;
> > } libxl_save_properties;
> 
> s/save/suspend/ to match the function it is passed to? Perhaps
> libxl_domain_suspend_properties?

Will rename it to libxl_domain_suspend_properties.

> > int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> >                          const libxl_save_properties *props,
> >                          const libxl_asyncop_how *ao_how)
> >                          LIBXL_EXTERNAL_CALLERS_ONLY;
> > #ifdef LIBXL_API_VERSION
> > #if LIBXL_API_VERSION == 0x040200
> > #define libxl_domain_suspend(__ctx, __domid, __fd, __flags, __ao_how) \
> > ({ \
> >     libxl_save_properties __props = { .xlflags = (__flags) }; \
> >     int __ret = libxl_domain_suspend((__ctx), (__domid), (__fd), &__props, (__ao_how)); \
> >     __ret; \
> > })
> > #elif LIBXL_API_VERSION == 0x040300
> > static inline int libxl_domain_suspend_0x040300(libxl_ctx *ctx, uint32_t domid, int fd,
> >                           int flags, const libxl_asyncop_how *ao_how)
> > {
> >     libxl_save_properties props = { .xlflags = flags };
> >     return libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
> > }
> > #define libxl_domain_suspend libxl_domain_suspend_0x040300
> 
> I don't understand the need for this alternative, you are defining
> version 0x040300 in this patch and in the absence of LIBXL_API_VERSION
> this should therefore be the expected interface I think. We haven't
> released Xen 0x040300 yet.

Sorry, I was in a hurry and did not explain the stuff above properly
before sending the mail: 

Both versions of a backwards compatible libxl_domain_suspend interface
work, they are here just for reference.
I like the static inline variant because its C and it does not depend on
the '({ ... })' syntax, which is a gcc feature AFAIK.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:13:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:13: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 1U7nwT-000613-15; Tue, 19 Feb 2013 14:13:09 +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 1U7nwR-00060v-A1
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:13:07 +0000
Received: from [85.158.139.211:24815] by server-8.bemta-5.messagelabs.com id
	B1/F2-19075-27883215; Tue, 19 Feb 2013 14:13:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361283141!18197131!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzQ1Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1NzQ1Mzc=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5443 invoked from network); 19 Feb 2013 14:12:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-206.messagelabs.com with SMTP;
	19 Feb 2013 14:12:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (jorabe mo14) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d07f2ap1JD9cFJ ;
	Tue, 19 Feb 2013 15:12:20 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 17E301884C; Tue, 19 Feb 2013 15:12:19 +0100 (CET)
Date: Tue, 19 Feb 2013 15:12:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219141219.GA31344@aepfle.de>
References: <577b051fca174be9f7b3.1359394360@probook.site>
	<785c8f34e1f802106e53.1359747275@probook.site>
	<1359983463.7743.23.camel@zakaz.uk.xensource.com>
	<20130219114217.GA8133@aepfle.de>
	<1361274510.1051.99.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361274510.1051.99.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v4] tools: set migration constraints from
 cmdline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, Ian Campbell wrote:

> > typedef struct {
> >     int xlflags; /* LIBXL_SUSPEND_* */
> 
> Why is this called "xlflags"? xl isn't the only user of this interface.

To make it clear that libxl is the consumer, not libxc. But I think the
comment above makes it clear that libxl flags are expected. I will
rename it to 'flags'.

> >     int max_iters;
> >     int max_factor;
> > } libxl_save_properties;
> 
> s/save/suspend/ to match the function it is passed to? Perhaps
> libxl_domain_suspend_properties?

Will rename it to libxl_domain_suspend_properties.

> > int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
> >                          const libxl_save_properties *props,
> >                          const libxl_asyncop_how *ao_how)
> >                          LIBXL_EXTERNAL_CALLERS_ONLY;
> > #ifdef LIBXL_API_VERSION
> > #if LIBXL_API_VERSION == 0x040200
> > #define libxl_domain_suspend(__ctx, __domid, __fd, __flags, __ao_how) \
> > ({ \
> >     libxl_save_properties __props = { .xlflags = (__flags) }; \
> >     int __ret = libxl_domain_suspend((__ctx), (__domid), (__fd), &__props, (__ao_how)); \
> >     __ret; \
> > })
> > #elif LIBXL_API_VERSION == 0x040300
> > static inline int libxl_domain_suspend_0x040300(libxl_ctx *ctx, uint32_t domid, int fd,
> >                           int flags, const libxl_asyncop_how *ao_how)
> > {
> >     libxl_save_properties props = { .xlflags = flags };
> >     return libxl_domain_suspend(ctx, domid, fd, &props, ao_how);
> > }
> > #define libxl_domain_suspend libxl_domain_suspend_0x040300
> 
> I don't understand the need for this alternative, you are defining
> version 0x040300 in this patch and in the absence of LIBXL_API_VERSION
> this should therefore be the expected interface I think. We haven't
> released Xen 0x040300 yet.

Sorry, I was in a hurry and did not explain the stuff above properly
before sending the mail: 

Both versions of a backwards compatible libxl_domain_suspend interface
work, they are here just for reference.
I like the static inline variant because its C and it does not depend on
the '({ ... })' syntax, which is a gcc feature AFAIK.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:28:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:28: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 1U7oAs-0006H5-IG; Tue, 19 Feb 2013 14:28:02 +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 1U7oAr-0006H0-0N
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:28:01 +0000
Received: from [85.158.143.35:53207] by server-3.bemta-4.messagelabs.com id
	B6/CD-08920-0FB83215; Tue, 19 Feb 2013 14:28:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1361283773!10121386!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30565 invoked from network); 19 Feb 2013 14:22:55 -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;
	19 Feb 2013 14:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8168230"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:22:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:22:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7o5s-0000GI-7X;
	Tue, 19 Feb 2013 14:22:52 +0000
Message-ID: <1361283772.2937.3.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 14:22:52 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 14:06 +0000, Frediano Ziglio wrote:
> On Tue, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> > It is just a wrapper around select(2).
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  extras/mini-os/include/posix/poll.h |    1 +
> >  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
> >  2 files changed, 90 insertions(+), 1 deletion(-)
> >  create mode 100644 extras/mini-os/include/posix/poll.h
> > 
> > diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> > new file mode 100644
> > index 0000000..06fb41a
> > --- /dev/null
> > +++ b/extras/mini-os/include/posix/poll.h
> > @@ -0,0 +1 @@
> > +#include <sys/poll.h>
> > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > index 3cc3340..aae02df 100644
> > --- a/extras/mini-os/lib/sys.c
> > +++ b/extras/mini-os/lib/sys.c
> > @@ -31,6 +31,7 @@
> >  #include <tpm_tis.h>
> >  #include <xenbus.h>
> >  #include <xenstore.h>
> > +#include <poll.h>
> >  
> >  #include <sys/types.h>
> >  #include <sys/unistd.h>
> > @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> >  #endif
> >  
> > +#ifdef LIBC_DEBUG
> > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > +{
> > +    int i, comma, fd;
> > +
> > +    printk("[");
> > +    comma = 0;
> > +    for (i = 0; i < nfds; i++) {
> > +        fd = pfd[i].fd;
> > +        if (comma)
> > +            printk(", ");
> > +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > +            pfd[i].events);
> > +            comma = 1;
> > +    }
> > +    printk("]");
> > +
> > +    printk(", %d, %d", nfds, timeout);
> > +}
> > +#else
> > +#define dump_pollfds(pfds, nfds, timeout)
> > +#endif
> > +
> >  /* Just poll without blocking */
> >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> >  {
> > @@ -983,6 +1007,71 @@ out:
> >      return ret;
> >  }
> >  
> > +/* Wrap around select */
> > +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> > +{
> > +    int ret;
> > +    int i, fd;
> > +    struct timeval _timeo, *timeo = NULL;
> > +    fd_set rfds, wfds, efds;
> > +    int max_fd = -1;
> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(_pfd, _nfds, _timeout);
> > +    DEBUG(")\n");
> > +
> > +    if (_timeout != -1) {
> 
> should be _timeout >= 0, any negative value will cause an infinite wait.
> 

Right, I was too obsessed with xenstore code which used -1 to represent
infinity loop.

> > +        /* Timeout in poll is in millisecond. */
> > +        _timeo.tv_sec  = _timeout / 1000;
> > +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
> 
> why not _timeout % 1000? gcc can also optimize and detect you have a
> division and a module and use only a single instruction in x86.
> 

Done.

> > +        timeo = &_timeo;
> > +    }
> > +
> > +    FD_ZERO(&rfds);
> > +    FD_ZERO(&wfds);
> > +    FD_ZERO(&efds);
> > +
> > +    for (i = 0; i < _nfds; i++) {
> > +        fd = _pfd[i].fd;
> 
> I think you should check if fd is < 0 and return EINVAL (not sure about
> the error code). Well.. probably you should check fd in range 0..1023.
> 

Unfortunately this is not specified in the standard. I guess we can just
ignore print a warning and ignore this fd?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html#tag_16_423

> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(_pfd, _nfds, _timeout);
> > +    DEBUG(")\n");
> > +
> 
> you probably want to save and restore errno or are we sure dump_pollfds
> cannot overwrite errno ?
> 

Done.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:28:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:28: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 1U7oAs-0006H5-IG; Tue, 19 Feb 2013 14:28:02 +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 1U7oAr-0006H0-0N
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:28:01 +0000
Received: from [85.158.143.35:53207] by server-3.bemta-4.messagelabs.com id
	B6/CD-08920-0FB83215; Tue, 19 Feb 2013 14:28:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1361283773!10121386!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30565 invoked from network); 19 Feb 2013 14:22:55 -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;
	19 Feb 2013 14:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8168230"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:22:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:22:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7o5s-0000GI-7X;
	Tue, 19 Feb 2013 14:22:52 +0000
Message-ID: <1361283772.2937.3.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 14:22:52 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 14:06 +0000, Frediano Ziglio wrote:
> On Tue, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> > It is just a wrapper around select(2).
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  extras/mini-os/include/posix/poll.h |    1 +
> >  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
> >  2 files changed, 90 insertions(+), 1 deletion(-)
> >  create mode 100644 extras/mini-os/include/posix/poll.h
> > 
> > diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> > new file mode 100644
> > index 0000000..06fb41a
> > --- /dev/null
> > +++ b/extras/mini-os/include/posix/poll.h
> > @@ -0,0 +1 @@
> > +#include <sys/poll.h>
> > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > index 3cc3340..aae02df 100644
> > --- a/extras/mini-os/lib/sys.c
> > +++ b/extras/mini-os/lib/sys.c
> > @@ -31,6 +31,7 @@
> >  #include <tpm_tis.h>
> >  #include <xenbus.h>
> >  #include <xenstore.h>
> > +#include <poll.h>
> >  
> >  #include <sys/types.h>
> >  #include <sys/unistd.h>
> > @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> >  #endif
> >  
> > +#ifdef LIBC_DEBUG
> > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > +{
> > +    int i, comma, fd;
> > +
> > +    printk("[");
> > +    comma = 0;
> > +    for (i = 0; i < nfds; i++) {
> > +        fd = pfd[i].fd;
> > +        if (comma)
> > +            printk(", ");
> > +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > +            pfd[i].events);
> > +            comma = 1;
> > +    }
> > +    printk("]");
> > +
> > +    printk(", %d, %d", nfds, timeout);
> > +}
> > +#else
> > +#define dump_pollfds(pfds, nfds, timeout)
> > +#endif
> > +
> >  /* Just poll without blocking */
> >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> >  {
> > @@ -983,6 +1007,71 @@ out:
> >      return ret;
> >  }
> >  
> > +/* Wrap around select */
> > +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> > +{
> > +    int ret;
> > +    int i, fd;
> > +    struct timeval _timeo, *timeo = NULL;
> > +    fd_set rfds, wfds, efds;
> > +    int max_fd = -1;
> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(_pfd, _nfds, _timeout);
> > +    DEBUG(")\n");
> > +
> > +    if (_timeout != -1) {
> 
> should be _timeout >= 0, any negative value will cause an infinite wait.
> 

Right, I was too obsessed with xenstore code which used -1 to represent
infinity loop.

> > +        /* Timeout in poll is in millisecond. */
> > +        _timeo.tv_sec  = _timeout / 1000;
> > +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
> 
> why not _timeout % 1000? gcc can also optimize and detect you have a
> division and a module and use only a single instruction in x86.
> 

Done.

> > +        timeo = &_timeo;
> > +    }
> > +
> > +    FD_ZERO(&rfds);
> > +    FD_ZERO(&wfds);
> > +    FD_ZERO(&efds);
> > +
> > +    for (i = 0; i < _nfds; i++) {
> > +        fd = _pfd[i].fd;
> 
> I think you should check if fd is < 0 and return EINVAL (not sure about
> the error code). Well.. probably you should check fd in range 0..1023.
> 

Unfortunately this is not specified in the standard. I guess we can just
ignore print a warning and ignore this fd?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html#tag_16_423

> > +
> > +    DEBUG("poll(");
> > +    dump_pollfds(_pfd, _nfds, _timeout);
> > +    DEBUG(")\n");
> > +
> 
> you probably want to save and restore errno or are we sure dump_pollfds
> cannot overwrite errno ?
> 

Done.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:30:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7oDO-0006Mj-4P; Tue, 19 Feb 2013 14:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1U7oDM-0006Mc-LE
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:30:36 +0000
Received: from [85.158.143.35:7491] by server-2.bemta-4.messagelabs.com id
	11/12-12656-B8C83215; Tue, 19 Feb 2013 14:30:35 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1361281871!5202816!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18551 invoked from network); 19 Feb 2013 13:51:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	19 Feb 2013 13:51:12 -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 r1JDp9x0031722
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 08:51:09 -0500
Received: from hawk.usersys.redhat.com (dhcp-1-196.brq.redhat.com
	[10.34.1.196])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r1JDp8SO006837; Tue, 19 Feb 2013 08:51:08 -0500
Date: Tue, 19 Feb 2013 14:51:05 +0100
From: Andrew Jones <drjones@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] question regarding 2.6.18 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

I believe there's a problem with the 2.6.18 reference tree backport of
48856286b64e: "xen/netback: shutdown the ring if it contains garbage",
which is c/s 1219. While the version in Linus' tree should be fine,
as xen_netbk_tx_action runs in a kthread, the 2.6.18 version needs
something different. In 2.6.18 net_tx_action is a tasklet, thus calling
xenvif_carrier_off from it is problematic due to needing the rtnl
mutex. A proposal I have that I haven't tried yet is for
netbk_fatal_tx_err to schedule xenvif_carrier_off in a workqueue. This
is a bit ugly though since the main point of xenvif_carrier_off is to
queue linkwatch work. I'm wondering if you or anyone else have other
suggestions.

Thanks,
Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:30:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7oDO-0006Mj-4P; Tue, 19 Feb 2013 14:30:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1U7oDM-0006Mc-LE
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:30:36 +0000
Received: from [85.158.143.35:7491] by server-2.bemta-4.messagelabs.com id
	11/12-12656-B8C83215; Tue, 19 Feb 2013 14:30:35 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1361281871!5202816!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTM5MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18551 invoked from network); 19 Feb 2013 13:51:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	19 Feb 2013 13:51:12 -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 r1JDp9x0031722
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 08:51:09 -0500
Received: from hawk.usersys.redhat.com (dhcp-1-196.brq.redhat.com
	[10.34.1.196])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r1JDp8SO006837; Tue, 19 Feb 2013 08:51:08 -0500
Date: Tue, 19 Feb 2013 14:51:05 +0100
From: Andrew Jones <drjones@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] question regarding 2.6.18 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

I believe there's a problem with the 2.6.18 reference tree backport of
48856286b64e: "xen/netback: shutdown the ring if it contains garbage",
which is c/s 1219. While the version in Linus' tree should be fine,
as xen_netbk_tx_action runs in a kthread, the 2.6.18 version needs
something different. In 2.6.18 net_tx_action is a tasklet, thus calling
xenvif_carrier_off from it is problematic due to needing the rtnl
mutex. A proposal I have that I haven't tried yet is for
netbk_fatal_tx_err to schedule xenvif_carrier_off in a workqueue. This
is a bit ugly though since the main point of xenvif_carrier_off is to
queue linkwatch work. I'm wondering if you or anyone else have other
suggestions.

Thanks,
Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:33:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7oFS-0006VZ-LV; Tue, 19 Feb 2013 14:32:46 +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 1U7oFQ-0006VL-G2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:32:44 +0000
Received: from [193.109.254.147:20631] by server-10.bemta-14.messagelabs.com
	id 13/6C-12679-B0D83215; Tue, 19 Feb 2013 14:32:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361284357!8807157!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMyMjkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3825 invoked from network); 19 Feb 2013 14:32:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:32:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEWZSu013037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:32:35 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
	r1JEWYfN001979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:32:35 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
	r1JEWYb5004448; Tue, 19 Feb 2013 08:32:34 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:32:34 -0800
Date: Tue, 19 Feb 2013 09:32:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219143225.GA7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
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] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

I thought we had discussed doing this check in the user of
this as well?

> ---
>  drivers/xen/evtchn.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index b1f60a0..b2db77e 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
>  				       u->name, (void *)(unsigned long)port);
>  	if (rc >= 0)
>  		rc = evtchn_make_refcounted(port);
> +	else {
> +		/* bind failed, should close the port now */
> +		struct evtchn_close close;
> +		close.port = port;
> +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> +			BUG();
> +		set_port_user(port, NULL);
> +	}
>  
>  	return rc;
>  }
> @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
>  {
>  	int irq = irq_from_evtchn(port);
>  
> +	BUG_ON(irq < 0);
> +
>  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
>  
>  	set_port_user(port, NULL);
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:33:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7oFS-0006VZ-LV; Tue, 19 Feb 2013 14:32:46 +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 1U7oFQ-0006VL-G2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:32:44 +0000
Received: from [193.109.254.147:20631] by server-10.bemta-14.messagelabs.com
	id 13/6C-12679-B0D83215; Tue, 19 Feb 2013 14:32:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361284357!8807157!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMyMjkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3825 invoked from network); 19 Feb 2013 14:32:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:32:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEWZSu013037
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:32:35 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
	r1JEWYfN001979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:32:35 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
	r1JEWYb5004448; Tue, 19 Feb 2013 08:32:34 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:32:34 -0800
Date: Tue, 19 Feb 2013 09:32:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219143225.GA7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
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] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

I thought we had discussed doing this check in the user of
this as well?

> ---
>  drivers/xen/evtchn.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index b1f60a0..b2db77e 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
>  				       u->name, (void *)(unsigned long)port);
>  	if (rc >= 0)
>  		rc = evtchn_make_refcounted(port);
> +	else {
> +		/* bind failed, should close the port now */
> +		struct evtchn_close close;
> +		close.port = port;
> +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> +			BUG();
> +		set_port_user(port, NULL);
> +	}
>  
>  	return rc;
>  }
> @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
>  {
>  	int irq = irq_from_evtchn(port);
>  
> +	BUG_ON(irq < 0);
> +
>  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
>  
>  	set_port_user(port, NULL);
> -- 
> 1.7.10.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:39:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7oLW-0006sB-61; Tue, 19 Feb 2013 14:39: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 1U7oLU-0006s3-M4
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:39:00 +0000
Received: from [85.158.137.99:17518] by server-6.bemta-3.messagelabs.com id
	7D/35-29959-38E83215; Tue, 19 Feb 2013 14:38:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361284738!17048675!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9910 invoked from network); 19 Feb 2013 14:38:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 14:38:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 14:38:58 +0000
Message-Id: <51239CCA02000078000BF729@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 14:39:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Andrew Jones" <drjones@redhat.com>
References: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
	<1361282091.1051.101.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361282091.1051.101.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] question regarding 2.6.18 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:54, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-02-19 at 13:51 +0000, Andrew Jones wrote:
>> Hi Ian,
>> 
>> I believe there's a problem with the 2.6.18 reference tree backport of
>> 48856286b64e: "xen/netback: shutdown the ring if it contains garbage",
>> which is c/s 1219. While the version in Linus' tree should be fine,
>> as xen_netbk_tx_action runs in a kthread, the 2.6.18 version needs
>> something different. In 2.6.18 net_tx_action is a tasklet, thus calling
>> xenvif_carrier_off from it is problematic due to needing the rtnl
>> mutex. A proposal I have that I haven't tried yet is for
>> netbk_fatal_tx_err to schedule xenvif_carrier_off in a workqueue. This
>> is a bit ugly though since the main point of xenvif_carrier_off is to
>> queue linkwatch work. I'm wondering if you or anyone else have other
>> suggestions.
> 
> Jan was looking into something of this nature, not sure wht the status
> is though.

http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/ff0befcaac09

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:39:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7oLW-0006sB-61; Tue, 19 Feb 2013 14:39: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 1U7oLU-0006s3-M4
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:39:00 +0000
Received: from [85.158.137.99:17518] by server-6.bemta-3.messagelabs.com id
	7D/35-29959-38E83215; Tue, 19 Feb 2013 14:38:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361284738!17048675!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9910 invoked from network); 19 Feb 2013 14:38:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 14:38:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 19 Feb 2013 14:38:58 +0000
Message-Id: <51239CCA02000078000BF729@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 19 Feb 2013 14:39:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Andrew Jones" <drjones@redhat.com>
References: <20130219145105.6274e9ea@hawk.usersys.redhat.com>
	<1361282091.1051.101.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361282091.1051.101.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] question regarding 2.6.18 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:54, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-02-19 at 13:51 +0000, Andrew Jones wrote:
>> Hi Ian,
>> 
>> I believe there's a problem with the 2.6.18 reference tree backport of
>> 48856286b64e: "xen/netback: shutdown the ring if it contains garbage",
>> which is c/s 1219. While the version in Linus' tree should be fine,
>> as xen_netbk_tx_action runs in a kthread, the 2.6.18 version needs
>> something different. In 2.6.18 net_tx_action is a tasklet, thus calling
>> xenvif_carrier_off from it is problematic due to needing the rtnl
>> mutex. A proposal I have that I haven't tried yet is for
>> netbk_fatal_tx_err to schedule xenvif_carrier_off in a workqueue. This
>> is a bit ugly though since the main point of xenvif_carrier_off is to
>> queue linkwatch work. I'm wondering if you or anyone else have other
>> suggestions.
> 
> Jan was looking into something of this nature, not sure wht the status
> is though.

http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/ff0befcaac09

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:44:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7oQE-00077O-U3; Tue, 19 Feb 2013 14:43:54 +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 1U7oQD-00077H-VW
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:43:54 +0000
Received: from [193.109.254.147:65434] by server-11.bemta-14.messagelabs.com
	id 0F/E2-30685-9AF83215; Tue, 19 Feb 2013 14:43:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361284996!8579789!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDM1MTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25475 invoked from network); 19 Feb 2013 14:43:17 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:43:17 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEh4vY024046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:43:04 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
	r1JEh39S025229
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:43:03 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
	r1JEh2WY014084; Tue, 19 Feb 2013 08:43:03 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:43:01 -0800
Date: Tue, 19 Feb 2013 09:42:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130219144253.GE7026@konrad-lan.dumpdata.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> ioremap can't be used to map ring pages on ARM because it uses device
> memory caching attributes (MT_DEVICE*).
> 
> Introduce a Xen specific abstraction to map ring pages, called
> xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> On ARM it explicitly calls __arm_ioremap with the right caching
> attributes: MT_MEMORY.

Do you want to push this to Linus yourself or should I just include it
in my 'for-39' tree?

Do you have other patches for 3.9?
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index c6b9096..30cdacb 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -1,6 +1,7 @@
>  #ifndef _ASM_ARM_XEN_PAGE_H
>  #define _ASM_ARM_XEN_PAGE_H
>  
> +#include <asm/mach/map.h>
>  #include <asm/page.h>
>  #include <asm/pgtable.h>
>  
> @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>  	return __set_phys_to_machine(pfn, mfn);
>  }
> +
> +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6aef9fb 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
>  void make_lowmem_page_readonly(void *vaddr);
>  void make_lowmem_page_readwrite(void *vaddr);
>  
> +#define xen_remap(cookie, size) ioremap((cookie), (size));
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 19843ec..682210d7 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
>  	if (r < 0 || v == 0)
>  		goto err;
>  	mfn = v;
> -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
>  	if (info->intf == NULL)
>  		goto err;
>  	info->vtermno = HVC_COOKIE;
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 7038de5..1c2a1e5 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
>  		return gnttab_map(0, nr_grant_frames - 1);
>  
>  	if (gnttab_shared.addr == NULL) {
> -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
>  						PAGE_SIZE * max_nr_gframes);
>  		if (gnttab_shared.addr == NULL) {
>  			printk(KERN_WARNING
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 038b71d..3325884 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
>  			goto out_error;
>  		xen_store_mfn = (unsigned long)v;
>  		xen_store_interface =
> -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
>  		break;
>  	default:
>  		pr_warn("Xenstore state unknown\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:44:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7oQE-00077O-U3; Tue, 19 Feb 2013 14:43:54 +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 1U7oQD-00077H-VW
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:43:54 +0000
Received: from [193.109.254.147:65434] by server-11.bemta-14.messagelabs.com
	id 0F/E2-30685-9AF83215; Tue, 19 Feb 2013 14:43:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361284996!8579789!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDM1MTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25475 invoked from network); 19 Feb 2013 14:43:17 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:43:17 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEh4vY024046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:43:04 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
	r1JEh39S025229
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:43:03 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
	r1JEh2WY014084; Tue, 19 Feb 2013 08:43:03 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:43:01 -0800
Date: Tue, 19 Feb 2013 09:42:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130219144253.GE7026@konrad-lan.dumpdata.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> ioremap can't be used to map ring pages on ARM because it uses device
> memory caching attributes (MT_DEVICE*).
> 
> Introduce a Xen specific abstraction to map ring pages, called
> xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> On ARM it explicitly calls __arm_ioremap with the right caching
> attributes: MT_MEMORY.

Do you want to push this to Linus yourself or should I just include it
in my 'for-39' tree?

Do you have other patches for 3.9?
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index c6b9096..30cdacb 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -1,6 +1,7 @@
>  #ifndef _ASM_ARM_XEN_PAGE_H
>  #define _ASM_ARM_XEN_PAGE_H
>  
> +#include <asm/mach/map.h>
>  #include <asm/page.h>
>  #include <asm/pgtable.h>
>  
> @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>  	return __set_phys_to_machine(pfn, mfn);
>  }
> +
> +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6aef9fb 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
>  void make_lowmem_page_readonly(void *vaddr);
>  void make_lowmem_page_readwrite(void *vaddr);
>  
> +#define xen_remap(cookie, size) ioremap((cookie), (size));
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 19843ec..682210d7 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
>  	if (r < 0 || v == 0)
>  		goto err;
>  	mfn = v;
> -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
>  	if (info->intf == NULL)
>  		goto err;
>  	info->vtermno = HVC_COOKIE;
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 7038de5..1c2a1e5 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
>  		return gnttab_map(0, nr_grant_frames - 1);
>  
>  	if (gnttab_shared.addr == NULL) {
> -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
>  						PAGE_SIZE * max_nr_gframes);
>  		if (gnttab_shared.addr == NULL) {
>  			printk(KERN_WARNING
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 038b71d..3325884 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
>  			goto out_error;
>  		xen_store_mfn = (unsigned long)v;
>  		xen_store_interface =
> -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
>  		break;
>  	default:
>  		pr_warn("Xenstore state unknown\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:45:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:45: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 1U7oRF-0007BW-Cp; Tue, 19 Feb 2013 14:44:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7oRE-0007BH-8N
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:44:56 +0000
Received: from [85.158.137.99:28292] by server-8.bemta-3.messagelabs.com id
	88/4E-25687-6EF83215; Tue, 19 Feb 2013 14:44:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361285094!11684936!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18328 invoked from network); 19 Feb 2013 14:44:54 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 14:44:54 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 3D59CC56196;
	Tue, 19 Feb 2013 14:44:40 +0000 (GMT)
Date: Tue, 19 Feb 2013 14:44:39 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <C18D9DBDB1700B2EECEB6DD8@nimrod.local>
In-Reply-To: <20771.32285.167144.873527@mariner.uk.xensource.com>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
	<20771.32285.167144.873527@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@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] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

--On 19 February 2013 13:29:01 +0000 Ian Jackson 
<Ian.Jackson@eu.citrix.com> wrote:

>> The 11 patches to libxl are unchanged since version 3 of the patch,
>> but have Acked-By lines reintroduced.
>
> Thanks for this!  You've made this very convenient.

No problem.

> Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
> object.

Note you will (obviously) need to change the commit ref for qemu once
the qemu patches are applied.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:45:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:45: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 1U7oRF-0007BW-Cp; Tue, 19 Feb 2013 14:44:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7oRE-0007BH-8N
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:44:56 +0000
Received: from [85.158.137.99:28292] by server-8.bemta-3.messagelabs.com id
	88/4E-25687-6EF83215; Tue, 19 Feb 2013 14:44:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361285094!11684936!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18328 invoked from network); 19 Feb 2013 14:44:54 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 14:44:54 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 3D59CC56196;
	Tue, 19 Feb 2013 14:44:40 +0000 (GMT)
Date: Tue, 19 Feb 2013 14:44:39 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <C18D9DBDB1700B2EECEB6DD8@nimrod.local>
In-Reply-To: <20771.32285.167144.873527@mariner.uk.xensource.com>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
	<20771.32285.167144.873527@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@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] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

--On 19 February 2013 13:29:01 +0000 Ian Jackson 
<Ian.Jackson@eu.citrix.com> wrote:

>> The 11 patches to libxl are unchanged since version 3 of the patch,
>> but have Acked-By lines reintroduced.
>
> Thanks for this!  You've made this very convenient.

No problem.

> Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
> object.

Note you will (obviously) need to change the commit ref for qemu once
the qemu patches are applied.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:49:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:49: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 1U7oV5-0007SA-89; Tue, 19 Feb 2013 14:48: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 1U7oV4-0007S3-Gw
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:48:54 +0000
Received: from [193.109.254.147:36880] by server-3.bemta-14.messagelabs.com id
	7F/F3-22141-5D093215; Tue, 19 Feb 2013 14:48:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361285333!8991753!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30704 invoked from network); 19 Feb 2013 14:48:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1612303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 14:48: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.297.1;
	Tue, 19 Feb 2013 14:48:48 +0000
Message-ID: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 14:48:47 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH V2] xen: event channel arrays are xen_ulong_t
 and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two patches (one for Xen, one for Linux) switch Xen event
channels from unsigned long to xen_ulong_t.

On arm, this enables us to have the same interface on arm32 and arm64
because xen_ulong_t is a 64-bit type on ARM.

On x86 there is no change because xen_ulong_t is unsigned long on x86.

Since this is an ABI change on ARM I hope we can get this in for the 3.9
merge window. I have deferred the other changes which I previously
posted along side this since they are not so critical.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:49:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:49: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 1U7oV5-0007SA-89; Tue, 19 Feb 2013 14:48: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 1U7oV4-0007S3-Gw
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:48:54 +0000
Received: from [193.109.254.147:36880] by server-3.bemta-14.messagelabs.com id
	7F/F3-22141-5D093215; Tue, 19 Feb 2013 14:48:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361285333!8991753!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30704 invoked from network); 19 Feb 2013 14:48:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1612303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 14:48: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.297.1;
	Tue, 19 Feb 2013 14:48:48 +0000
Message-ID: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 14:48:47 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH V2] xen: event channel arrays are xen_ulong_t
 and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two patches (one for Xen, one for Linux) switch Xen event
channels from unsigned long to xen_ulong_t.

On arm, this enables us to have the same interface on arm32 and arm64
because xen_ulong_t is a 64-bit type on ARM.

On x86 there is no change because xen_ulong_t is unsigned long on x86.

Since this is an ABI change on ARM I hope we can get this in for the 3.9
merge window. I have deferred the other changes which I previously
posted along side this since they are not so critical.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:49:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:49: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 1U7oVY-0007Ur-MR; Tue, 19 Feb 2013 14:49: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 1U7oVW-0007Ua-NR
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:49:23 +0000
Received: from [85.158.139.211:56018] by server-2.bemta-5.messagelabs.com id
	E1/40-16911-1F093215; Tue, 19 Feb 2013 14:49:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361285359!14261717!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12925 invoked from network); 19 Feb 2013 14:49:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7771408"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:49:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:49:18 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7oVR-0000fc-WD;
	Tue, 19 Feb 2013 14:49:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 14:49:17 +0000
Message-ID: <1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
---
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 ++++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  103 ++++++++++++++++++++-----------------
 include/xen/interface/xen.h       |    8 ++--
 4 files changed, 84 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..9bb5f50 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ read_evtchn_pending_sel\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..5618ca0 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +302,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +383,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +397,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +411,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +419,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1197,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1213,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1222,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1284,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = find_first_bit(BM(&words), sizeof(words));
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1349,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1359,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1371,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1384,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1494,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1543,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 19 14:49:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:49: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 1U7oVY-0007Ur-MR; Tue, 19 Feb 2013 14:49: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 1U7oVW-0007Ua-NR
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:49:23 +0000
Received: from [85.158.139.211:56018] by server-2.bemta-5.messagelabs.com id
	E1/40-16911-1F093215; Tue, 19 Feb 2013 14:49:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361285359!14261717!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12925 invoked from network); 19 Feb 2013 14:49:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7771408"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:49:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:49:18 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7oVR-0000fc-WD;
	Tue, 19 Feb 2013 14:49:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 14:49:17 +0000
Message-ID: <1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
---
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 ++++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  103 ++++++++++++++++++++-----------------
 include/xen/interface/xen.h       |    8 ++--
 4 files changed, 84 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..9bb5f50 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ read_evtchn_pending_sel\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..5618ca0 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +302,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +383,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +397,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +411,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +419,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1197,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1213,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1222,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1284,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = find_first_bit(BM(&words), sizeof(words));
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1349,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1359,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1371,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1384,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1494,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1543,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 19 14:49:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:49: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 1U7oVh-0007W1-3V; Tue, 19 Feb 2013 14:49: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 1U7oVf-0007Vm-Mm
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:49:31 +0000
Received: from [85.158.137.99:52955] by server-5.bemta-3.messagelabs.com id
	2C/45-04457-6F093215; Tue, 19 Feb 2013 14:49:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361285364!17045910!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5690 invoked from network); 19 Feb 2013 14:49:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8175496"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:49:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:49:23 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7oVX-0000ff-Dv;
	Tue, 19 Feb 2013 14:49:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 14:49:22 +0000
Message-ID: <1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH XEN] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
---
 tools/include/xen-foreign/mkheader.py |    6 ++++++
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..57681fa 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,13 +21,18 @@ inttypes["arm"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
+header["arm"] = """
+#define __arm___ARM32 1
+""";
 
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -42,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:49:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:49: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 1U7oVh-0007W1-3V; Tue, 19 Feb 2013 14:49: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 1U7oVf-0007Vm-Mm
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:49:31 +0000
Received: from [85.158.137.99:52955] by server-5.bemta-3.messagelabs.com id
	2C/45-04457-6F093215; Tue, 19 Feb 2013 14:49:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361285364!17045910!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5690 invoked from network); 19 Feb 2013 14:49:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8175496"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:49:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:49:23 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7oVX-0000ff-Dv;
	Tue, 19 Feb 2013 14:49:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 14:49:22 +0000
Message-ID: <1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH XEN] xen: event channel arrays are xen_ulong_t
	and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
---
 tools/include/xen-foreign/mkheader.py |    6 ++++++
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..57681fa 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,13 +21,18 @@ inttypes["arm"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
+header["arm"] = """
+#define __arm___ARM32 1
+""";
 
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -42,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:50:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:50: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 1U7oWN-0007eD-Hy; Tue, 19 Feb 2013 14:50:15 +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 1U7oWM-0007dn-89
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:50:14 +0000
Received: from [85.158.138.51:44903] by server-9.bemta-3.messagelabs.com id
	5E/9B-09484-52193215; Tue, 19 Feb 2013 14:50:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361285395!28267226!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16916 invoked from network); 19 Feb 2013 14:49:57 -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;
	19 Feb 2013 14:49:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7771203"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:48:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:48:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7oUi-0000eq-67;
	Tue, 19 Feb 2013 14:48:32 +0000
Date: Tue, 19 Feb 2013 14:48:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130219144253.GE7026@konrad-lan.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
	<20130219144253.GE7026@konrad-lan.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > ioremap can't be used to map ring pages on ARM because it uses device
> > memory caching attributes (MT_DEVICE*).
> > 
> > Introduce a Xen specific abstraction to map ring pages, called
> > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > On ARM it explicitly calls __arm_ioremap with the right caching
> > attributes: MT_MEMORY.
> 
> Do you want to push this to Linus yourself or should I just include it
> in my 'for-39' tree?
> 
> Do you have other patches for 3.9?

Ian has two patches ("linux: public interface changes for arm"), it
would be great if they could go in 3.9.
Given the small number of patches (three all together), it is probably
easier to go via your tree, if you are OK with that.



> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > index c6b9096..30cdacb 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -1,6 +1,7 @@
> >  #ifndef _ASM_ARM_XEN_PAGE_H
> >  #define _ASM_ARM_XEN_PAGE_H
> >  
> > +#include <asm/mach/map.h>
> >  #include <asm/page.h>
> >  #include <asm/pgtable.h>
> >  
> > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  {
> >  	return __set_phys_to_machine(pfn, mfn);
> >  }
> > +
> > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index 472b9b7..6aef9fb 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> >  void make_lowmem_page_readonly(void *vaddr);
> >  void make_lowmem_page_readwrite(void *vaddr);
> >  
> > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 19843ec..682210d7 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> >  	if (r < 0 || v == 0)
> >  		goto err;
> >  	mfn = v;
> > -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> >  	if (info->intf == NULL)
> >  		goto err;
> >  	info->vtermno = HVC_COOKIE;
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index 7038de5..1c2a1e5 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> >  		return gnttab_map(0, nr_grant_frames - 1);
> >  
> >  	if (gnttab_shared.addr == NULL) {
> > -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> >  						PAGE_SIZE * max_nr_gframes);
> >  		if (gnttab_shared.addr == NULL) {
> >  			printk(KERN_WARNING
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > index 038b71d..3325884 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> >  			goto out_error;
> >  		xen_store_mfn = (unsigned long)v;
> >  		xen_store_interface =
> > -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> >  		break;
> >  	default:
> >  		pr_warn("Xenstore state unknown\n");
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:50:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:50: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 1U7oWN-0007eD-Hy; Tue, 19 Feb 2013 14:50:15 +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 1U7oWM-0007dn-89
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:50:14 +0000
Received: from [85.158.138.51:44903] by server-9.bemta-3.messagelabs.com id
	5E/9B-09484-52193215; Tue, 19 Feb 2013 14:50:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361285395!28267226!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16916 invoked from network); 19 Feb 2013 14:49:57 -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;
	19 Feb 2013 14:49:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="7771203"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:48:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:48:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7oUi-0000eq-67;
	Tue, 19 Feb 2013 14:48:32 +0000
Date: Tue, 19 Feb 2013 14:48:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130219144253.GE7026@konrad-lan.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
	<20130219144253.GE7026@konrad-lan.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > ioremap can't be used to map ring pages on ARM because it uses device
> > memory caching attributes (MT_DEVICE*).
> > 
> > Introduce a Xen specific abstraction to map ring pages, called
> > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > On ARM it explicitly calls __arm_ioremap with the right caching
> > attributes: MT_MEMORY.
> 
> Do you want to push this to Linus yourself or should I just include it
> in my 'for-39' tree?
> 
> Do you have other patches for 3.9?

Ian has two patches ("linux: public interface changes for arm"), it
would be great if they could go in 3.9.
Given the small number of patches (three all together), it is probably
easier to go via your tree, if you are OK with that.



> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > index c6b9096..30cdacb 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -1,6 +1,7 @@
> >  #ifndef _ASM_ARM_XEN_PAGE_H
> >  #define _ASM_ARM_XEN_PAGE_H
> >  
> > +#include <asm/mach/map.h>
> >  #include <asm/page.h>
> >  #include <asm/pgtable.h>
> >  
> > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  {
> >  	return __set_phys_to_machine(pfn, mfn);
> >  }
> > +
> > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > index 472b9b7..6aef9fb 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> >  void make_lowmem_page_readonly(void *vaddr);
> >  void make_lowmem_page_readwrite(void *vaddr);
> >  
> > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 19843ec..682210d7 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> >  	if (r < 0 || v == 0)
> >  		goto err;
> >  	mfn = v;
> > -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> >  	if (info->intf == NULL)
> >  		goto err;
> >  	info->vtermno = HVC_COOKIE;
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index 7038de5..1c2a1e5 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> >  		return gnttab_map(0, nr_grant_frames - 1);
> >  
> >  	if (gnttab_shared.addr == NULL) {
> > -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> >  						PAGE_SIZE * max_nr_gframes);
> >  		if (gnttab_shared.addr == NULL) {
> >  			printk(KERN_WARNING
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > index 038b71d..3325884 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> >  			goto out_error;
> >  		xen_store_mfn = (unsigned long)v;
> >  		xen_store_interface =
> > -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> >  		break;
> >  	default:
> >  		pr_warn("Xenstore state unknown\n");
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:50:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:50: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 1U7oWT-0007fq-6o; Tue, 19 Feb 2013 14:50:21 +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 1U7oWR-0007f4-4L
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:50:19 +0000
Received: from [85.158.137.99:6796] by server-12.bemta-3.messagelabs.com id
	D2/08-05889-A2193215; Tue, 19 Feb 2013 14:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361285416!13907083!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10684 invoked from network); 19 Feb 2013 14:50:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:50:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1612414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 14:50: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.297.1;
	Tue, 19 Feb 2013 14:50:16 +0000
Message-ID: <1361285414.1051.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 14:50:14 +0000
In-Reply-To: <alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
	<20130219144253.GE7026@konrad-lan.dumpdata.com>
	<alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:48 +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > > ioremap can't be used to map ring pages on ARM because it uses device
> > > memory caching attributes (MT_DEVICE*).
> > > 
> > > Introduce a Xen specific abstraction to map ring pages, called
> > > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > > On ARM it explicitly calls __arm_ioremap with the right caching
> > > attributes: MT_MEMORY.
> > 
> > Do you want to push this to Linus yourself or should I just include it
> > in my 'for-39' tree?
> > 
> > Do you have other patches for 3.9?
> 
> Ian has two patches ("linux: public interface changes for arm"), it
> would be great if they could go in 3.9.

My two are one for Xen and one for Linux, so just one as far as the
merge window is concerned, I just reposted them 10s ago..

> Given the small number of patches (three all together), it is probably
> easier to go via your tree, if you are OK with that.
> 
> 
> 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > > index c6b9096..30cdacb 100644
> > > --- a/arch/arm/include/asm/xen/page.h
> > > +++ b/arch/arm/include/asm/xen/page.h
> > > @@ -1,6 +1,7 @@
> > >  #ifndef _ASM_ARM_XEN_PAGE_H
> > >  #define _ASM_ARM_XEN_PAGE_H
> > >  
> > > +#include <asm/mach/map.h>
> > >  #include <asm/page.h>
> > >  #include <asm/pgtable.h>
> > >  
> > > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> > >  {
> > >  	return __set_phys_to_machine(pfn, mfn);
> > >  }
> > > +
> > > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > > +
> > >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > > index 472b9b7..6aef9fb 100644
> > > --- a/arch/x86/include/asm/xen/page.h
> > > +++ b/arch/x86/include/asm/xen/page.h
> > > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> > >  void make_lowmem_page_readonly(void *vaddr);
> > >  void make_lowmem_page_readwrite(void *vaddr);
> > >  
> > > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > > +
> > >  #endif /* _ASM_X86_XEN_PAGE_H */
> > > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > > index 19843ec..682210d7 100644
> > > --- a/drivers/tty/hvc/hvc_xen.c
> > > +++ b/drivers/tty/hvc/hvc_xen.c
> > > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> > >  	if (r < 0 || v == 0)
> > >  		goto err;
> > >  	mfn = v;
> > > -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  	if (info->intf == NULL)
> > >  		goto err;
> > >  	info->vtermno = HVC_COOKIE;
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 7038de5..1c2a1e5 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> > >  		return gnttab_map(0, nr_grant_frames - 1);
> > >  
> > >  	if (gnttab_shared.addr == NULL) {
> > > -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > > +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> > >  						PAGE_SIZE * max_nr_gframes);
> > >  		if (gnttab_shared.addr == NULL) {
> > >  			printk(KERN_WARNING
> > > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > > index 038b71d..3325884 100644
> > > --- a/drivers/xen/xenbus/xenbus_probe.c
> > > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> > >  			goto out_error;
> > >  		xen_store_mfn = (unsigned long)v;
> > >  		xen_store_interface =
> > > -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  		break;
> > >  	default:
> > >  		pr_warn("Xenstore state unknown\n");
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:50:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:50: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 1U7oWT-0007fq-6o; Tue, 19 Feb 2013 14:50:21 +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 1U7oWR-0007f4-4L
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:50:19 +0000
Received: from [85.158.137.99:6796] by server-12.bemta-3.messagelabs.com id
	D2/08-05889-A2193215; Tue, 19 Feb 2013 14:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361285416!13907083!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10684 invoked from network); 19 Feb 2013 14:50:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:50:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="1612414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 14:50: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.297.1;
	Tue, 19 Feb 2013 14:50:16 +0000
Message-ID: <1361285414.1051.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 14:50:14 +0000
In-Reply-To: <alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
	<20130219144253.GE7026@konrad-lan.dumpdata.com>
	<alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:48 +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > > ioremap can't be used to map ring pages on ARM because it uses device
> > > memory caching attributes (MT_DEVICE*).
> > > 
> > > Introduce a Xen specific abstraction to map ring pages, called
> > > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > > On ARM it explicitly calls __arm_ioremap with the right caching
> > > attributes: MT_MEMORY.
> > 
> > Do you want to push this to Linus yourself or should I just include it
> > in my 'for-39' tree?
> > 
> > Do you have other patches for 3.9?
> 
> Ian has two patches ("linux: public interface changes for arm"), it
> would be great if they could go in 3.9.

My two are one for Xen and one for Linux, so just one as far as the
merge window is concerned, I just reposted them 10s ago..

> Given the small number of patches (three all together), it is probably
> easier to go via your tree, if you are OK with that.
> 
> 
> 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > > index c6b9096..30cdacb 100644
> > > --- a/arch/arm/include/asm/xen/page.h
> > > +++ b/arch/arm/include/asm/xen/page.h
> > > @@ -1,6 +1,7 @@
> > >  #ifndef _ASM_ARM_XEN_PAGE_H
> > >  #define _ASM_ARM_XEN_PAGE_H
> > >  
> > > +#include <asm/mach/map.h>
> > >  #include <asm/page.h>
> > >  #include <asm/pgtable.h>
> > >  
> > > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> > >  {
> > >  	return __set_phys_to_machine(pfn, mfn);
> > >  }
> > > +
> > > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > > +
> > >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > > index 472b9b7..6aef9fb 100644
> > > --- a/arch/x86/include/asm/xen/page.h
> > > +++ b/arch/x86/include/asm/xen/page.h
> > > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> > >  void make_lowmem_page_readonly(void *vaddr);
> > >  void make_lowmem_page_readwrite(void *vaddr);
> > >  
> > > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > > +
> > >  #endif /* _ASM_X86_XEN_PAGE_H */
> > > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > > index 19843ec..682210d7 100644
> > > --- a/drivers/tty/hvc/hvc_xen.c
> > > +++ b/drivers/tty/hvc/hvc_xen.c
> > > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> > >  	if (r < 0 || v == 0)
> > >  		goto err;
> > >  	mfn = v;
> > > -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  	if (info->intf == NULL)
> > >  		goto err;
> > >  	info->vtermno = HVC_COOKIE;
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 7038de5..1c2a1e5 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> > >  		return gnttab_map(0, nr_grant_frames - 1);
> > >  
> > >  	if (gnttab_shared.addr == NULL) {
> > > -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > > +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> > >  						PAGE_SIZE * max_nr_gframes);
> > >  		if (gnttab_shared.addr == NULL) {
> > >  			printk(KERN_WARNING
> > > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > > index 038b71d..3325884 100644
> > > --- a/drivers/xen/xenbus/xenbus_probe.c
> > > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> > >  			goto out_error;
> > >  		xen_store_mfn = (unsigned long)v;
> > >  		xen_store_interface =
> > > -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  		break;
> > >  	default:
> > >  		pr_warn("Xenstore state unknown\n");
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:50:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:50: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 1U7oWU-0007gL-KF; Tue, 19 Feb 2013 14:50:22 +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 1U7oWS-0007f4-Fr
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:50:20 +0000
Received: from [85.158.137.99:57869] by server-12.bemta-3.messagelabs.com id
	87/18-05889-C2193215; Tue, 19 Feb 2013 14:50:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361285418!12256665!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMyMjkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27193 invoked from network); 19 Feb 2013 14:50:19 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:50:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEo9I8005274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:50:10 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
	r1JEo95r010609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:50:09 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1JEo9BA001807; Tue, 19 Feb 2013 08:50:09 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:50:08 -0800
Date: Tue, 19 Feb 2013 09:50:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130219145003.GG7026@konrad-lan.dumpdata.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
	<20130219144253.GE7026@konrad-lan.dumpdata.com>
	<alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 02:48:30PM +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > > ioremap can't be used to map ring pages on ARM because it uses device
> > > memory caching attributes (MT_DEVICE*).
> > > 
> > > Introduce a Xen specific abstraction to map ring pages, called
> > > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > > On ARM it explicitly calls __arm_ioremap with the right caching
> > > attributes: MT_MEMORY.
> > 
> > Do you want to push this to Linus yourself or should I just include it
> > in my 'for-39' tree?
> > 
> > Do you have other patches for 3.9?
> 
> Ian has two patches ("linux: public interface changes for arm"), it
> would be great if they could go in 3.9.
> Given the small number of patches (three all together), it is probably
> easier to go via your tree, if you are OK with that.

Sure. Can you Ack them please?
> 
> 
> 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > > index c6b9096..30cdacb 100644
> > > --- a/arch/arm/include/asm/xen/page.h
> > > +++ b/arch/arm/include/asm/xen/page.h
> > > @@ -1,6 +1,7 @@
> > >  #ifndef _ASM_ARM_XEN_PAGE_H
> > >  #define _ASM_ARM_XEN_PAGE_H
> > >  
> > > +#include <asm/mach/map.h>
> > >  #include <asm/page.h>
> > >  #include <asm/pgtable.h>
> > >  
> > > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> > >  {
> > >  	return __set_phys_to_machine(pfn, mfn);
> > >  }
> > > +
> > > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > > +
> > >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > > index 472b9b7..6aef9fb 100644
> > > --- a/arch/x86/include/asm/xen/page.h
> > > +++ b/arch/x86/include/asm/xen/page.h
> > > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> > >  void make_lowmem_page_readonly(void *vaddr);
> > >  void make_lowmem_page_readwrite(void *vaddr);
> > >  
> > > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > > +
> > >  #endif /* _ASM_X86_XEN_PAGE_H */
> > > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > > index 19843ec..682210d7 100644
> > > --- a/drivers/tty/hvc/hvc_xen.c
> > > +++ b/drivers/tty/hvc/hvc_xen.c
> > > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> > >  	if (r < 0 || v == 0)
> > >  		goto err;
> > >  	mfn = v;
> > > -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  	if (info->intf == NULL)
> > >  		goto err;
> > >  	info->vtermno = HVC_COOKIE;
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 7038de5..1c2a1e5 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> > >  		return gnttab_map(0, nr_grant_frames - 1);
> > >  
> > >  	if (gnttab_shared.addr == NULL) {
> > > -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > > +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> > >  						PAGE_SIZE * max_nr_gframes);
> > >  		if (gnttab_shared.addr == NULL) {
> > >  			printk(KERN_WARNING
> > > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > > index 038b71d..3325884 100644
> > > --- a/drivers/xen/xenbus/xenbus_probe.c
> > > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> > >  			goto out_error;
> > >  		xen_store_mfn = (unsigned long)v;
> > >  		xen_store_interface =
> > > -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  		break;
> > >  	default:
> > >  		pr_warn("Xenstore state unknown\n");
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:50:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:50: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 1U7oWU-0007gL-KF; Tue, 19 Feb 2013 14:50:22 +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 1U7oWS-0007f4-Fr
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 14:50:20 +0000
Received: from [85.158.137.99:57869] by server-12.bemta-3.messagelabs.com id
	87/18-05889-C2193215; Tue, 19 Feb 2013 14:50:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361285418!12256665!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMyMjkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27193 invoked from network); 19 Feb 2013 14:50:19 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:50:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEo9I8005274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:50:10 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
	r1JEo95r010609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:50:09 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1JEo9BA001807; Tue, 19 Feb 2013 08:50:09 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:50:08 -0800
Date: Tue, 19 Feb 2013 09:50:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130219145003.GG7026@konrad-lan.dumpdata.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
	<20130219144253.GE7026@konrad-lan.dumpdata.com>
	<alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302191445160.4654@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 02:48:30PM +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > > ioremap can't be used to map ring pages on ARM because it uses device
> > > memory caching attributes (MT_DEVICE*).
> > > 
> > > Introduce a Xen specific abstraction to map ring pages, called
> > > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > > On ARM it explicitly calls __arm_ioremap with the right caching
> > > attributes: MT_MEMORY.
> > 
> > Do you want to push this to Linus yourself or should I just include it
> > in my 'for-39' tree?
> > 
> > Do you have other patches for 3.9?
> 
> Ian has two patches ("linux: public interface changes for arm"), it
> would be great if they could go in 3.9.
> Given the small number of patches (three all together), it is probably
> easier to go via your tree, if you are OK with that.

Sure. Can you Ack them please?
> 
> 
> 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> > > index c6b9096..30cdacb 100644
> > > --- a/arch/arm/include/asm/xen/page.h
> > > +++ b/arch/arm/include/asm/xen/page.h
> > > @@ -1,6 +1,7 @@
> > >  #ifndef _ASM_ARM_XEN_PAGE_H
> > >  #define _ASM_ARM_XEN_PAGE_H
> > >  
> > > +#include <asm/mach/map.h>
> > >  #include <asm/page.h>
> > >  #include <asm/pgtable.h>
> > >  
> > > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> > >  {
> > >  	return __set_phys_to_machine(pfn, mfn);
> > >  }
> > > +
> > > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > > +
> > >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> > > index 472b9b7..6aef9fb 100644
> > > --- a/arch/x86/include/asm/xen/page.h
> > > +++ b/arch/x86/include/asm/xen/page.h
> > > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> > >  void make_lowmem_page_readonly(void *vaddr);
> > >  void make_lowmem_page_readwrite(void *vaddr);
> > >  
> > > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > > +
> > >  #endif /* _ASM_X86_XEN_PAGE_H */
> > > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > > index 19843ec..682210d7 100644
> > > --- a/drivers/tty/hvc/hvc_xen.c
> > > +++ b/drivers/tty/hvc/hvc_xen.c
> > > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> > >  	if (r < 0 || v == 0)
> > >  		goto err;
> > >  	mfn = v;
> > > -	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +	info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  	if (info->intf == NULL)
> > >  		goto err;
> > >  	info->vtermno = HVC_COOKIE;
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 7038de5..1c2a1e5 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> > >  		return gnttab_map(0, nr_grant_frames - 1);
> > >  
> > >  	if (gnttab_shared.addr == NULL) {
> > > -		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > > +		gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> > >  						PAGE_SIZE * max_nr_gframes);
> > >  		if (gnttab_shared.addr == NULL) {
> > >  			printk(KERN_WARNING
> > > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > > index 038b71d..3325884 100644
> > > --- a/drivers/xen/xenbus/xenbus_probe.c
> > > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> > >  			goto out_error;
> > >  		xen_store_mfn = (unsigned long)v;
> > >  		xen_store_interface =
> > > -			ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > > +			xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > >  		break;
> > >  	default:
> > >  		pr_warn("Xenstore state unknown\n");
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:53:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:53: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 1U7oZR-0008Hd-Bp; Tue, 19 Feb 2013 14:53:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7oZQ-0008HH-DG
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:53:24 +0000
Received: from [85.158.138.51:42780] by server-14.bemta-3.messagelabs.com id
	B2/29-23533-8D193215; Tue, 19 Feb 2013 14:53:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361285574!28229996!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16624 invoked from network); 19 Feb 2013 14:52:56 -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;
	19 Feb 2013 14:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8175836"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:50:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:50:54 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7oX0-0000go-N6;
	Tue, 19 Feb 2013 14:50:54 +0000
Message-ID: <1361285454.2937.9.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 19 Feb 2013 14:50:54 +0000
In-Reply-To: <20130219143225.GA7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
	<20130219143225.GA7026@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:32 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> I thought we had discussed doing this check in the user of
> this as well?
> 

User of this? I presume you mean the binding path? The patch also does
this. The first patch issues close hypercall in the unbind path, but
this patch issues hypercall in the bind path, and adds BUG_ON in the
unbind path.

As for port == 0, this cannot happend, so I remove the port == 0 case.


Wei.

> > ---
> >  drivers/xen/evtchn.c |   10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> > index b1f60a0..b2db77e 100644
> > --- a/drivers/xen/evtchn.c
> > +++ b/drivers/xen/evtchn.c
> > @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
> >  				       u->name, (void *)(unsigned long)port);
> >  	if (rc >= 0)
> >  		rc = evtchn_make_refcounted(port);
> > +	else {
> > +		/* bind failed, should close the port now */
> > +		struct evtchn_close close;
> > +		close.port = port;
> > +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> > +			BUG();
> > +		set_port_user(port, NULL);
> > +	}
> >  
> >  	return rc;
> >  }
> > @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
> >  {
> >  	int irq = irq_from_evtchn(port);
> >  
> > +	BUG_ON(irq < 0);
> > +
> >  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> >  
> >  	set_port_user(port, NULL);
> > -- 
> > 1.7.10.4
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:53:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:53: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 1U7oZR-0008Hd-Bp; Tue, 19 Feb 2013 14:53:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7oZQ-0008HH-DG
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:53:24 +0000
Received: from [85.158.138.51:42780] by server-14.bemta-3.messagelabs.com id
	B2/29-23533-8D193215; Tue, 19 Feb 2013 14:53:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361285574!28229996!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16624 invoked from network); 19 Feb 2013 14:52:56 -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;
	19 Feb 2013 14:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8175836"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:50:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:50:54 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7oX0-0000go-N6;
	Tue, 19 Feb 2013 14:50:54 +0000
Message-ID: <1361285454.2937.9.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 19 Feb 2013 14:50:54 +0000
In-Reply-To: <20130219143225.GA7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
	<20130219143225.GA7026@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:32 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> I thought we had discussed doing this check in the user of
> this as well?
> 

User of this? I presume you mean the binding path? The patch also does
this. The first patch issues close hypercall in the unbind path, but
this patch issues hypercall in the bind path, and adds BUG_ON in the
unbind path.

As for port == 0, this cannot happend, so I remove the port == 0 case.


Wei.

> > ---
> >  drivers/xen/evtchn.c |   10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> > index b1f60a0..b2db77e 100644
> > --- a/drivers/xen/evtchn.c
> > +++ b/drivers/xen/evtchn.c
> > @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
> >  				       u->name, (void *)(unsigned long)port);
> >  	if (rc >= 0)
> >  		rc = evtchn_make_refcounted(port);
> > +	else {
> > +		/* bind failed, should close the port now */
> > +		struct evtchn_close close;
> > +		close.port = port;
> > +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> > +			BUG();
> > +		set_port_user(port, NULL);
> > +	}
> >  
> >  	return rc;
> >  }
> > @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
> >  {
> >  	int irq = irq_from_evtchn(port);
> >  
> > +	BUG_ON(irq < 0);
> > +
> >  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> >  
> >  	set_port_user(port, NULL);
> > -- 
> > 1.7.10.4
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:56:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:56: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 1U7obu-00005d-0D; Tue, 19 Feb 2013 14:55:58 +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 1U7obs-00005X-B7
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:55:56 +0000
Received: from [193.109.254.147:24126] by server-13.bemta-14.messagelabs.com
	id 2A/52-30639-B7293215; Tue, 19 Feb 2013 14:55:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361285192!8809284!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23449 invoked from network); 19 Feb 2013 14:46:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8174747"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:46:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:46:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7oSl-0000d3-CI;
	Tue, 19 Feb 2013 14:46:31 +0000
Message-ID: <1361285191.2937.6.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 19 Feb 2013 14:46:31 +0000
In-Reply-To: <20130219143225.GA7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
	<20130219143225.GA7026@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:32 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> I thought we had discussed doing this check in the user of
> this as well?
> 

Hah? I remember Jan's comment on the port == 0 case and your suggestion
to add BUG_ON() in the unbind path. Did I miss anything?


Wei.

> > ---
> >  drivers/xen/evtchn.c |   10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> > index b1f60a0..b2db77e 100644
> > --- a/drivers/xen/evtchn.c
> > +++ b/drivers/xen/evtchn.c
> > @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
> >  				       u->name, (void *)(unsigned long)port);
> >  	if (rc >= 0)
> >  		rc = evtchn_make_refcounted(port);
> > +	else {
> > +		/* bind failed, should close the port now */
> > +		struct evtchn_close close;
> > +		close.port = port;
> > +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> > +			BUG();
> > +		set_port_user(port, NULL);
> > +	}
> >  
> >  	return rc;
> >  }
> > @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
> >  {
> >  	int irq = irq_from_evtchn(port);
> >  
> > +	BUG_ON(irq < 0);
> > +
> >  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> >  
> >  	set_port_user(port, NULL);
> > -- 
> > 1.7.10.4
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:56:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14:56: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 1U7obu-00005d-0D; Tue, 19 Feb 2013 14:55:58 +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 1U7obs-00005X-B7
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:55:56 +0000
Received: from [193.109.254.147:24126] by server-13.bemta-14.messagelabs.com
	id 2A/52-30639-B7293215; Tue, 19 Feb 2013 14:55:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361285192!8809284!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23449 invoked from network); 19 Feb 2013 14:46:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 14:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; 
   d="scan'208";a="8174747"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 14:46:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 09:46:31 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7oSl-0000d3-CI;
	Tue, 19 Feb 2013 14:46:31 +0000
Message-ID: <1361285191.2937.6.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 19 Feb 2013 14:46:31 +0000
In-Reply-To: <20130219143225.GA7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
	<20130219143225.GA7026@konrad-lan.dumpdata.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:32 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> I thought we had discussed doing this check in the user of
> this as well?
> 

Hah? I remember Jan's comment on the port == 0 case and your suggestion
to add BUG_ON() in the unbind path. Did I miss anything?


Wei.

> > ---
> >  drivers/xen/evtchn.c |   10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> > index b1f60a0..b2db77e 100644
> > --- a/drivers/xen/evtchn.c
> > +++ b/drivers/xen/evtchn.c
> > @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
> >  				       u->name, (void *)(unsigned long)port);
> >  	if (rc >= 0)
> >  		rc = evtchn_make_refcounted(port);
> > +	else {
> > +		/* bind failed, should close the port now */
> > +		struct evtchn_close close;
> > +		close.port = port;
> > +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> > +			BUG();
> > +		set_port_user(port, NULL);
> > +	}
> >  
> >  	return rc;
> >  }
> > @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
> >  {
> >  	int irq = irq_from_evtchn(port);
> >  
> > +	BUG_ON(irq < 0);
> > +
> >  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> >  
> >  	set_port_user(port, NULL);
> > -- 
> > 1.7.10.4
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:56:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7ocR-00008b-E0; Tue, 19 Feb 2013 14:56:31 +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 1U7ocP-00008P-Se
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:56:30 +0000
Received: from [193.109.254.147:28287] by server-5.bemta-14.messagelabs.com id
	DB/CC-21539-D9293215; Tue, 19 Feb 2013 14:56:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361285725!3290247!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDM1MTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1820 invoked from network); 19 Feb 2013 14:55:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:55:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEsN6M006902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:54:23 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
	r1JEsM10017399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:54:22 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1JEsMrX006760; Tue, 19 Feb 2013 08:54:22 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:54:21 -0800
Date: Tue, 19 Feb 2013 09:54:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219145416.GH7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
	<20130219143225.GA7026@konrad-lan.dumpdata.com>
	<1361285191.2937.6.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361285191.2937.6.camel@zion.uk.xensource.com>
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" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 02:46:31PM +0000, Wei Liu wrote:
> On Tue, 2013-02-19 at 14:32 +0000, Konrad Rzeszutek Wilk wrote:
> > On Mon, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > I thought we had discussed doing this check in the user of
> > this as well?
> > 
> 
> Hah? I remember Jan's comment on the port == 0 case and your suggestion
> to add BUG_ON() in the unbind path. Did I miss anything?

This patch by itself is fine. I thought that we had chatted of adding
a check in evtchn_bind_to_user to check the return value and so
something about it. But the more I think about this - it makes less
sense than doing it here.

So this patch is good - putting it on my 3.9 list.
> 
> 
> Wei.
> 
> > > ---
> > >  drivers/xen/evtchn.c |   10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> > > index b1f60a0..b2db77e 100644
> > > --- a/drivers/xen/evtchn.c
> > > +++ b/drivers/xen/evtchn.c
> > > @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
> > >  				       u->name, (void *)(unsigned long)port);
> > >  	if (rc >= 0)
> > >  		rc = evtchn_make_refcounted(port);
> > > +	else {
> > > +		/* bind failed, should close the port now */
> > > +		struct evtchn_close close;
> > > +		close.port = port;
> > > +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> > > +			BUG();
> > > +		set_port_user(port, NULL);
> > > +	}
> > >  
> > >  	return rc;
> > >  }
> > > @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
> > >  {
> > >  	int irq = irq_from_evtchn(port);
> > >  
> > > +	BUG_ON(irq < 0);
> > > +
> > >  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> > >  
> > >  	set_port_user(port, NULL);
> > > -- 
> > > 1.7.10.4
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 14:56:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 14: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 1U7ocR-00008b-E0; Tue, 19 Feb 2013 14:56:31 +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 1U7ocP-00008P-Se
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 14:56:30 +0000
Received: from [193.109.254.147:28287] by server-5.bemta-14.messagelabs.com id
	DB/CC-21539-D9293215; Tue, 19 Feb 2013 14:56:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361285725!3290247!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDM1MTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1820 invoked from network); 19 Feb 2013 14:55:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 14:55:27 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JEsN6M006902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 14:54:23 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
	r1JEsM10017399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 14:54:22 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1JEsMrX006760; Tue, 19 Feb 2013 08:54:22 -0600
Received: from konrad-lan.dumpdata.com (/208.54.36.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 06:54:21 -0800
Date: Tue, 19 Feb 2013 09:54:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219145416.GH7026@konrad-lan.dumpdata.com>
References: <1361199479-26059-1-git-send-email-wei.liu2@citrix.com>
	<1361199479-26059-2-git-send-email-wei.liu2@citrix.com>
	<20130219143225.GA7026@konrad-lan.dumpdata.com>
	<1361285191.2937.6.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361285191.2937.6.camel@zion.uk.xensource.com>
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" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: close evtchn port if binding to
	irq fails
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 02:46:31PM +0000, Wei Liu wrote:
> On Tue, 2013-02-19 at 14:32 +0000, Konrad Rzeszutek Wilk wrote:
> > On Mon, Feb 18, 2013 at 02:57:58PM +0000, Wei Liu wrote:
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > I thought we had discussed doing this check in the user of
> > this as well?
> > 
> 
> Hah? I remember Jan's comment on the port == 0 case and your suggestion
> to add BUG_ON() in the unbind path. Did I miss anything?

This patch by itself is fine. I thought that we had chatted of adding
a check in evtchn_bind_to_user to check the return value and so
something about it. But the more I think about this - it makes less
sense than doing it here.

So this patch is good - putting it on my 3.9 list.
> 
> 
> Wei.
> 
> > > ---
> > >  drivers/xen/evtchn.c |   10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> > > index b1f60a0..b2db77e 100644
> > > --- a/drivers/xen/evtchn.c
> > > +++ b/drivers/xen/evtchn.c
> > > @@ -269,6 +269,14 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
> > >  				       u->name, (void *)(unsigned long)port);
> > >  	if (rc >= 0)
> > >  		rc = evtchn_make_refcounted(port);
> > > +	else {
> > > +		/* bind failed, should close the port now */
> > > +		struct evtchn_close close;
> > > +		close.port = port;
> > > +		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
> > > +			BUG();
> > > +		set_port_user(port, NULL);
> > > +	}
> > >  
> > >  	return rc;
> > >  }
> > > @@ -277,6 +285,8 @@ static void evtchn_unbind_from_user(struct per_user_data *u, int port)
> > >  {
> > >  	int irq = irq_from_evtchn(port);
> > >  
> > > +	BUG_ON(irq < 0);
> > > +
> > >  	unbind_from_irqhandler(irq, (void *)(unsigned long)port);
> > >  
> > >  	set_port_user(port, NULL);
> > > -- 
> > > 1.7.10.4
> > > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:18:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:18: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 1U7owx-0001VK-9c; Tue, 19 Feb 2013 15:17:43 +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 1U7owv-0001VF-VJ
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:17:42 +0000
Received: from [193.109.254.147:58729] by server-16.bemta-14.messagelabs.com
	id 46/45-25906-59793215; Tue, 19 Feb 2013 15:17:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361287050!8975387!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 639 invoked from network); 19 Feb 2013 15:17:31 -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;
	19 Feb 2013 15:17:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8185067"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 15:17:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 10:17:29 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7owj-00015c-88;
	Tue, 19 Feb 2013 15:17:29 +0000
Message-ID: <1361287049.2937.11.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 15:17:29 +0000
In-Reply-To: <1361283772.2937.3.camel@zion.uk.xensource.com>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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

New version of the patch. Address Frediano's comments, also correct the
calculation of return value.

Wei.

----8<----
>From 4b7dffa7b61ff840a359f7124c76198b7aeed135 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 12:15:03 +0000
Subject: [PATCH] mini-os: implement poll(2)

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  101 ++++++++++++++++++++++++++++++++++-
 2 files changed, 101 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..d85aa38 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,82 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+    int saved_errno;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    if (_timeout >= 0) {
+        /* Timeout in poll is in millisecond. */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    }
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (fd < 0 || fd > 1023) {
+            DEBUG("trying to poll fd %d which is not between [0,1023]\n", fd);
+            continue;
+        }  
+        /* map POLL* into readfds and writefds */
+        /* POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        _pfd[i].revents = 0;
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* don't care about the return value, but we do need errno */
+    select(max_fd+1, &rfds, &wfds, &efds, timeo);
+
+    ret = 0;
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            ret++;
+        if (FD_ISSET(fd, &efds)) {
+             /* anything bad happens we set POLLERR, ignoring PULLHUP
+              * POLLNVAL */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    saved_errno = errno;
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+    errno = saved_errno;
+
+    return ret;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1460,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:18:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:18: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 1U7owx-0001VK-9c; Tue, 19 Feb 2013 15:17:43 +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 1U7owv-0001VF-VJ
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:17:42 +0000
Received: from [193.109.254.147:58729] by server-16.bemta-14.messagelabs.com
	id 46/45-25906-59793215; Tue, 19 Feb 2013 15:17:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361287050!8975387!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 639 invoked from network); 19 Feb 2013 15:17:31 -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;
	19 Feb 2013 15:17:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8185067"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 15:17:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 10:17:29 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7owj-00015c-88;
	Tue, 19 Feb 2013 15:17:29 +0000
Message-ID: <1361287049.2937.11.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 15:17:29 +0000
In-Reply-To: <1361283772.2937.3.camel@zion.uk.xensource.com>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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

New version of the patch. Address Frediano's comments, also correct the
calculation of return value.

Wei.

----8<----
>From 4b7dffa7b61ff840a359f7124c76198b7aeed135 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 12:15:03 +0000
Subject: [PATCH] mini-os: implement poll(2)

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  101 ++++++++++++++++++++++++++++++++++-
 2 files changed, 101 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..d85aa38 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,82 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+    int saved_errno;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    if (_timeout >= 0) {
+        /* Timeout in poll is in millisecond. */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    }
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (fd < 0 || fd > 1023) {
+            DEBUG("trying to poll fd %d which is not between [0,1023]\n", fd);
+            continue;
+        }  
+        /* map POLL* into readfds and writefds */
+        /* POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        _pfd[i].revents = 0;
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* don't care about the return value, but we do need errno */
+    select(max_fd+1, &rfds, &wfds, &efds, timeo);
+
+    ret = 0;
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            ret++;
+        if (FD_ISSET(fd, &efds)) {
+             /* anything bad happens we set POLLERR, ignoring PULLHUP
+              * POLLNVAL */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    saved_errno = errno;
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+    errno = saved_errno;
+
+    return ret;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1460,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:18:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:18: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 1U7oxP-0001YH-Sf; Tue, 19 Feb 2013 15:18:11 +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 1U7oxP-0001Y7-4F
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 15:18:11 +0000
Received: from [85.158.139.211:23879] by server-12.bemta-5.messagelabs.com id
	1D/23-20195-2B793215; Tue, 19 Feb 2013 15:18:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361287089!14268060!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23328 invoked from network); 19 Feb 2013 15:18:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:18:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1613906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 15: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.297.1; Tue, 19 Feb 2013 15:18:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7oxN-0003K2-4y;
	Tue, 19 Feb 2013 15:18:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7oxM-0004bP-HE;
	Tue, 19 Feb 2013 15:18:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16209-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 15:18:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16209: tolerable trouble:
	broken/fail/pass - 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 16209 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16209/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-qemut-winxpsp3  3 host-install(3)    broken pass in 16207
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 16207
 test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail in 16207 pass in 16209

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16171

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 16207 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 16207 never pass

version targeted for testing:
 xen                  620e5d3aa7cd
baseline version:
 xen                  788f4551580d

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Eddie Dong <eddie.dong@intel.com>
  Fabio Fantoni <fabio.fantoni@heliman.it>
  Frediano Ziglio <frediano.ziglio@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Lalith Suresh <suresh.lalith@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Ross Philipson <ross.philipson@citrix.com>
  Shakeel Butt <shakeel.butt@gmail.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=620e5d3aa7cd
+ . 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 620e5d3aa7cd
+ branch=xen-unstable
+ revision=620e5d3aa7cd
+ . 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/hg/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 620e5d3aa7cd 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 47 changesets with 108 changes to 82 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:18:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:18: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 1U7oxP-0001YH-Sf; Tue, 19 Feb 2013 15:18:11 +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 1U7oxP-0001Y7-4F
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 15:18:11 +0000
Received: from [85.158.139.211:23879] by server-12.bemta-5.messagelabs.com id
	1D/23-20195-2B793215; Tue, 19 Feb 2013 15:18:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361287089!14268060!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23328 invoked from network); 19 Feb 2013 15:18:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:18:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1613906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 15: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.297.1; Tue, 19 Feb 2013 15:18:09 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7oxN-0003K2-4y;
	Tue, 19 Feb 2013 15:18:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7oxM-0004bP-HE;
	Tue, 19 Feb 2013 15:18:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16209-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 15:18:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16209: tolerable trouble:
	broken/fail/pass - 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 16209 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16209/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-qemut-winxpsp3  3 host-install(3)    broken pass in 16207
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 16207
 test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail in 16207 pass in 16209

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16171
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16171

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 16207 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 16207 never pass

version targeted for testing:
 xen                  620e5d3aa7cd
baseline version:
 xen                  788f4551580d

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Eddie Dong <eddie.dong@intel.com>
  Fabio Fantoni <fabio.fantoni@heliman.it>
  Frediano Ziglio <frediano.ziglio@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Jun Nakajima <jun.nakajima@intel.com>
  Keir Fraser <keir@xen.org>
  Lalith Suresh <suresh.lalith@gmail.com>
  Olaf Hering <olaf@aepfle.de>
  Ross Philipson <ross.philipson@citrix.com>
  Shakeel Butt <shakeel.butt@gmail.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          broken  
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=620e5d3aa7cd
+ . 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 620e5d3aa7cd
+ branch=xen-unstable
+ revision=620e5d3aa7cd
+ . 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/hg/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 620e5d3aa7cd 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 47 changesets with 108 changes to 82 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:22:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:22: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 1U7p1O-0001tR-30; Tue, 19 Feb 2013 15:22:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7p1L-0001rw-R2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:22:16 +0000
Received: from [85.158.137.99:17283] by server-2.bemta-3.messagelabs.com id
	54/AB-25961-7A893215; Tue, 19 Feb 2013 15:22:15 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361287334!17052722!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16167 invoked from network); 19 Feb 2013 15:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1614106"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 15:21:14 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 19 Feb 2013
	15:21:14 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 15:21:12 +0000
Thread-Topic: [Xen-devel] [PATCH] mini-os: implement poll(2)
Thread-Index: Ac4OtMDNB8ju930nTXOkgU8FdRVM/A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
In-Reply-To: <1361283772.2937.3.camel@zion.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: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 14:22 +0000, Wei Liu wrote:
> On Tue, 2013-02-19 at 14:06 +0000, Frediano Ziglio wrote:
> > On Tue, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> > > It is just a wrapper around select(2).
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  extras/mini-os/include/posix/poll.h |    1 +
> > >  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
> > >  2 files changed, 90 insertions(+), 1 deletion(-)
> > >  create mode 100644 extras/mini-os/include/posix/poll.h
> > > 
> > > diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> > > new file mode 100644
> > > index 0000000..06fb41a
> > > --- /dev/null
> > > +++ b/extras/mini-os/include/posix/poll.h
> > > @@ -0,0 +1 @@
> > > +#include <sys/poll.h>
> > > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > > index 3cc3340..aae02df 100644
> > > --- a/extras/mini-os/lib/sys.c
> > > +++ b/extras/mini-os/lib/sys.c
> > > @@ -31,6 +31,7 @@
> > >  #include <tpm_tis.h>
> > >  #include <xenbus.h>
> > >  #include <xenstore.h>
> > > +#include <poll.h>
> > >  
> > >  #include <sys/types.h>
> > >  #include <sys/unistd.h>
> > > @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> > >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> > >  #endif
> > >  
> > > +#ifdef LIBC_DEBUG
> > > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > > +{
> > > +    int i, comma, fd;
> > > +
> > > +    printk("[");
> > > +    comma = 0;
> > > +    for (i = 0; i < nfds; i++) {
> > > +        fd = pfd[i].fd;
> > > +        if (comma)
> > > +            printk(", ");
> > > +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > > +            pfd[i].events);
> > > +            comma = 1;
> > > +    }
> > > +    printk("]");
> > > +
> > > +    printk(", %d, %d", nfds, timeout);
> > > +}
> > > +#else
> > > +#define dump_pollfds(pfds, nfds, timeout)
> > > +#endif
> > > +
> > >  /* Just poll without blocking */
> > >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> > >  {
> > > @@ -983,6 +1007,71 @@ out:
> > >      return ret;
> > >  }
> > >  
> > > +/* Wrap around select */
> > > +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> > > +{
> > > +    int ret;
> > > +    int i, fd;
> > > +    struct timeval _timeo, *timeo = NULL;
> > > +    fd_set rfds, wfds, efds;
> > > +    int max_fd = -1;
> > > +
> > > +    DEBUG("poll(");
> > > +    dump_pollfds(_pfd, _nfds, _timeout);
> > > +    DEBUG(")\n");
> > > +
> > > +    if (_timeout != -1) {
> > 
> > should be _timeout >= 0, any negative value will cause an infinite wait.
> > 
> 
> Right, I was too obsessed with xenstore code which used -1 to represent
> infinity loop.
> 
> > > +        /* Timeout in poll is in millisecond. */
> > > +        _timeo.tv_sec  = _timeout / 1000;
> > > +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
> > 
> > why not _timeout % 1000? gcc can also optimize and detect you have a
> > division and a module and use only a single instruction in x86.
> > 
> 
> Done.
> 
> > > +        timeo = &_timeo;
> > > +    }
> > > +
> > > +    FD_ZERO(&rfds);
> > > +    FD_ZERO(&wfds);
> > > +    FD_ZERO(&efds);
> > > +
> > > +    for (i = 0; i < _nfds; i++) {
> > > +        fd = _pfd[i].fd;
> > 
> > I think you should check if fd is < 0 and return EINVAL (not sure about
> > the error code). Well.. probably you should check fd in range 0..1023.
> > 
> 
> Unfortunately this is not specified in the standard. I guess we can just
> ignore print a warning and ignore this fd?
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html#tag_16_423
> 

Yes, it speaks only of STREAM (I don't know what's in this context).

I tried what happen on Linux. For values < 0 if just ignore the record.
Oh... from page you send

"If the value of fd is less than 0, events shall be ignored, and revents
shall be set to 0 in that entry on return from poll()."

For values that are not open if return POLLNVAL in revents.

Perhaps should be something like

    ret = 0;
    for (i = 0; i < _nfds; i++) {
        fd = _pfd[i].fd;
        _pfd[i].revents = 0;
        if (fd < 0) continue;
        if (fd >= 1024) {
            _pfd[i].revents = POLLNVAL;
            ++ret;
            continue;
        }
        /* map POLL* into readfds and writefds */
        /* POLLIN  -> readfds
         * POLLOUT -> writefds
         * POLL*   -> none
         */
        if (_pfd[i].events & POLLIN)
            FD_SET(fd, &rfds);
        if (_pfd[i].events & POLLOUT)
            FD_SET(fd, &wfds);
        /* always set exceptfds */
        FD_SET(fd, &efds);
        if (fd > max_fd)
            max_fd = fd;
    }
    if (ret) return ret;

> > > +
> > > +    DEBUG("poll(");
> > > +    dump_pollfds(_pfd, _nfds, _timeout);
> > > +    DEBUG(")\n");
> > > +
> > 
> > you probably want to save and restore errno or are we sure dump_pollfds
> > cannot overwrite errno ?
> > 
> 
> Done.
> 
> 
> Wei.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:22:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:22: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 1U7p1O-0001tR-30; Tue, 19 Feb 2013 15:22:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7p1L-0001rw-R2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:22:16 +0000
Received: from [85.158.137.99:17283] by server-2.bemta-3.messagelabs.com id
	54/AB-25961-7A893215; Tue, 19 Feb 2013 15:22:15 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361287334!17052722!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16167 invoked from network); 19 Feb 2013 15:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1614106"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 15:21:14 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 19 Feb 2013
	15:21:14 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 15:21:12 +0000
Thread-Topic: [Xen-devel] [PATCH] mini-os: implement poll(2)
Thread-Index: Ac4OtMDNB8ju930nTXOkgU8FdRVM/A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
In-Reply-To: <1361283772.2937.3.camel@zion.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: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 14:22 +0000, Wei Liu wrote:
> On Tue, 2013-02-19 at 14:06 +0000, Frediano Ziglio wrote:
> > On Tue, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> > > It is just a wrapper around select(2).
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  extras/mini-os/include/posix/poll.h |    1 +
> > >  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
> > >  2 files changed, 90 insertions(+), 1 deletion(-)
> > >  create mode 100644 extras/mini-os/include/posix/poll.h
> > > 
> > > diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> > > new file mode 100644
> > > index 0000000..06fb41a
> > > --- /dev/null
> > > +++ b/extras/mini-os/include/posix/poll.h
> > > @@ -0,0 +1 @@
> > > +#include <sys/poll.h>
> > > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > > index 3cc3340..aae02df 100644
> > > --- a/extras/mini-os/lib/sys.c
> > > +++ b/extras/mini-os/lib/sys.c
> > > @@ -31,6 +31,7 @@
> > >  #include <tpm_tis.h>
> > >  #include <xenbus.h>
> > >  #include <xenstore.h>
> > > +#include <poll.h>
> > >  
> > >  #include <sys/types.h>
> > >  #include <sys/unistd.h>
> > > @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> > >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> > >  #endif
> > >  
> > > +#ifdef LIBC_DEBUG
> > > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > > +{
> > > +    int i, comma, fd;
> > > +
> > > +    printk("[");
> > > +    comma = 0;
> > > +    for (i = 0; i < nfds; i++) {
> > > +        fd = pfd[i].fd;
> > > +        if (comma)
> > > +            printk(", ");
> > > +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > > +            pfd[i].events);
> > > +            comma = 1;
> > > +    }
> > > +    printk("]");
> > > +
> > > +    printk(", %d, %d", nfds, timeout);
> > > +}
> > > +#else
> > > +#define dump_pollfds(pfds, nfds, timeout)
> > > +#endif
> > > +
> > >  /* Just poll without blocking */
> > >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> > >  {
> > > @@ -983,6 +1007,71 @@ out:
> > >      return ret;
> > >  }
> > >  
> > > +/* Wrap around select */
> > > +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> > > +{
> > > +    int ret;
> > > +    int i, fd;
> > > +    struct timeval _timeo, *timeo = NULL;
> > > +    fd_set rfds, wfds, efds;
> > > +    int max_fd = -1;
> > > +
> > > +    DEBUG("poll(");
> > > +    dump_pollfds(_pfd, _nfds, _timeout);
> > > +    DEBUG(")\n");
> > > +
> > > +    if (_timeout != -1) {
> > 
> > should be _timeout >= 0, any negative value will cause an infinite wait.
> > 
> 
> Right, I was too obsessed with xenstore code which used -1 to represent
> infinity loop.
> 
> > > +        /* Timeout in poll is in millisecond. */
> > > +        _timeo.tv_sec  = _timeout / 1000;
> > > +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
> > 
> > why not _timeout % 1000? gcc can also optimize and detect you have a
> > division and a module and use only a single instruction in x86.
> > 
> 
> Done.
> 
> > > +        timeo = &_timeo;
> > > +    }
> > > +
> > > +    FD_ZERO(&rfds);
> > > +    FD_ZERO(&wfds);
> > > +    FD_ZERO(&efds);
> > > +
> > > +    for (i = 0; i < _nfds; i++) {
> > > +        fd = _pfd[i].fd;
> > 
> > I think you should check if fd is < 0 and return EINVAL (not sure about
> > the error code). Well.. probably you should check fd in range 0..1023.
> > 
> 
> Unfortunately this is not specified in the standard. I guess we can just
> ignore print a warning and ignore this fd?
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html#tag_16_423
> 

Yes, it speaks only of STREAM (I don't know what's in this context).

I tried what happen on Linux. For values < 0 if just ignore the record.
Oh... from page you send

"If the value of fd is less than 0, events shall be ignored, and revents
shall be set to 0 in that entry on return from poll()."

For values that are not open if return POLLNVAL in revents.

Perhaps should be something like

    ret = 0;
    for (i = 0; i < _nfds; i++) {
        fd = _pfd[i].fd;
        _pfd[i].revents = 0;
        if (fd < 0) continue;
        if (fd >= 1024) {
            _pfd[i].revents = POLLNVAL;
            ++ret;
            continue;
        }
        /* map POLL* into readfds and writefds */
        /* POLLIN  -> readfds
         * POLLOUT -> writefds
         * POLL*   -> none
         */
        if (_pfd[i].events & POLLIN)
            FD_SET(fd, &rfds);
        if (_pfd[i].events & POLLOUT)
            FD_SET(fd, &wfds);
        /* always set exceptfds */
        FD_SET(fd, &efds);
        if (fd > max_fd)
            max_fd = fd;
    }
    if (ret) return ret;

> > > +
> > > +    DEBUG("poll(");
> > > +    dump_pollfds(_pfd, _nfds, _timeout);
> > > +    DEBUG(")\n");
> > > +
> > 
> > you probably want to save and restore errno or are we sure dump_pollfds
> > cannot overwrite errno ?
> > 
> 
> Done.
> 
> 
> Wei.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:25:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:25: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 1U7p4Y-0003GI-9n; Tue, 19 Feb 2013 15:25: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 1U7p4X-0003GC-Ke
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:25:33 +0000
Received: from [85.158.139.83:8376] by server-12.bemta-5.messagelabs.com id
	D2/55-20195-C6993215; Tue, 19 Feb 2013 15:25:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361287530!24006529!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15054 invoked from network); 19 Feb 2013 15:25:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7782479"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 15:25:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 10:25:29 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7p4T-0001CI-3H;
	Tue, 19 Feb 2013 15:25:29 +0000
Message-ID: <1361287529.2937.13.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 15:25:29 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 15:21 +0000, Frediano Ziglio wrote:
> On Tue, 2013-02-19 at 14:22 +0000, Wei Liu wrote:
> > On Tue, 2013-02-19 at 14:06 +0000, Frediano Ziglio wrote:
> > > On Tue, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> > > > It is just a wrapper around select(2).
> > > > 
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > ---
> > > >  extras/mini-os/include/posix/poll.h |    1 +
> > > >  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
> > > >  2 files changed, 90 insertions(+), 1 deletion(-)
> > > >  create mode 100644 extras/mini-os/include/posix/poll.h
> > > > 
> > > > diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> > > > new file mode 100644
> > > > index 0000000..06fb41a
> > > > --- /dev/null
> > > > +++ b/extras/mini-os/include/posix/poll.h
> > > > @@ -0,0 +1 @@
> > > > +#include <sys/poll.h>
> > > > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > > > index 3cc3340..aae02df 100644
> > > > --- a/extras/mini-os/lib/sys.c
> > > > +++ b/extras/mini-os/lib/sys.c
> > > > @@ -31,6 +31,7 @@
> > > >  #include <tpm_tis.h>
> > > >  #include <xenbus.h>
> > > >  #include <xenstore.h>
> > > > +#include <poll.h>
> > > >  
> > > >  #include <sys/types.h>
> > > >  #include <sys/unistd.h>
> > > > @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> > > >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> > > >  #endif
> > > >  
> > > > +#ifdef LIBC_DEBUG
> > > > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > > > +{
> > > > +    int i, comma, fd;
> > > > +
> > > > +    printk("[");
> > > > +    comma = 0;
> > > > +    for (i = 0; i < nfds; i++) {
> > > > +        fd = pfd[i].fd;
> > > > +        if (comma)
> > > > +            printk(", ");
> > > > +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > > > +            pfd[i].events);
> > > > +            comma = 1;
> > > > +    }
> > > > +    printk("]");
> > > > +
> > > > +    printk(", %d, %d", nfds, timeout);
> > > > +}
> > > > +#else
> > > > +#define dump_pollfds(pfds, nfds, timeout)
> > > > +#endif
> > > > +
> > > >  /* Just poll without blocking */
> > > >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> > > >  {
> > > > @@ -983,6 +1007,71 @@ out:
> > > >      return ret;
> > > >  }
> > > >  
> > > > +/* Wrap around select */
> > > > +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> > > > +{
> > > > +    int ret;
> > > > +    int i, fd;
> > > > +    struct timeval _timeo, *timeo = NULL;
> > > > +    fd_set rfds, wfds, efds;
> > > > +    int max_fd = -1;
> > > > +
> > > > +    DEBUG("poll(");
> > > > +    dump_pollfds(_pfd, _nfds, _timeout);
> > > > +    DEBUG(")\n");
> > > > +
> > > > +    if (_timeout != -1) {
> > > 
> > > should be _timeout >= 0, any negative value will cause an infinite wait.
> > > 
> > 
> > Right, I was too obsessed with xenstore code which used -1 to represent
> > infinity loop.
> > 
> > > > +        /* Timeout in poll is in millisecond. */
> > > > +        _timeo.tv_sec  = _timeout / 1000;
> > > > +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
> > > 
> > > why not _timeout % 1000? gcc can also optimize and detect you have a
> > > division and a module and use only a single instruction in x86.
> > > 
> > 
> > Done.
> > 
> > > > +        timeo = &_timeo;
> > > > +    }
> > > > +
> > > > +    FD_ZERO(&rfds);
> > > > +    FD_ZERO(&wfds);
> > > > +    FD_ZERO(&efds);
> > > > +
> > > > +    for (i = 0; i < _nfds; i++) {
> > > > +        fd = _pfd[i].fd;
> > > 
> > > I think you should check if fd is < 0 and return EINVAL (not sure about
> > > the error code). Well.. probably you should check fd in range 0..1023.
> > > 
> > 
> > Unfortunately this is not specified in the standard. I guess we can just
> > ignore print a warning and ignore this fd?
> > 
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html#tag_16_423
> > 
> 
> Yes, it speaks only of STREAM (I don't know what's in this context).
> 
> I tried what happen on Linux. For values < 0 if just ignore the record.
> Oh... from page you send
> 
> "If the value of fd is less than 0, events shall be ignored, and revents
> shall be set to 0 in that entry on return from poll()."
> 

Ah, so it is in the description, good.

> For values that are not open if return POLLNVAL in revents.
> 
> Perhaps should be something like
> 
>     ret = 0;
>     for (i = 0; i < _nfds; i++) {
>         fd = _pfd[i].fd;
>         _pfd[i].revents = 0;
>         if (fd < 0) continue;
>         if (fd >= 1024) {
>             _pfd[i].revents = POLLNVAL;
>             ++ret;
>             continue;
>         

I would go for fd >= NOFILE here (NOFILE is the internal limit of
Mini-OS file abstraction).


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:25:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:25: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 1U7p4Y-0003GI-9n; Tue, 19 Feb 2013 15:25: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 1U7p4X-0003GC-Ke
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:25:33 +0000
Received: from [85.158.139.83:8376] by server-12.bemta-5.messagelabs.com id
	D2/55-20195-C6993215; Tue, 19 Feb 2013 15:25:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361287530!24006529!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15054 invoked from network); 19 Feb 2013 15:25:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7782479"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 15:25:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 10:25:29 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7p4T-0001CI-3H;
	Tue, 19 Feb 2013 15:25:29 +0000
Message-ID: <1361287529.2937.13.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 15:25:29 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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, 2013-02-19 at 15:21 +0000, Frediano Ziglio wrote:
> On Tue, 2013-02-19 at 14:22 +0000, Wei Liu wrote:
> > On Tue, 2013-02-19 at 14:06 +0000, Frediano Ziglio wrote:
> > > On Tue, 2013-02-19 at 13:41 +0000, Wei Liu wrote:
> > > > It is just a wrapper around select(2).
> > > > 
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > ---
> > > >  extras/mini-os/include/posix/poll.h |    1 +
> > > >  extras/mini-os/lib/sys.c            |   90 ++++++++++++++++++++++++++++++++++-
> > > >  2 files changed, 90 insertions(+), 1 deletion(-)
> > > >  create mode 100644 extras/mini-os/include/posix/poll.h
> > > > 
> > > > diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
> > > > new file mode 100644
> > > > index 0000000..06fb41a
> > > > --- /dev/null
> > > > +++ b/extras/mini-os/include/posix/poll.h
> > > > @@ -0,0 +1 @@
> > > > +#include <sys/poll.h>
> > > > diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> > > > index 3cc3340..aae02df 100644
> > > > --- a/extras/mini-os/lib/sys.c
> > > > +++ b/extras/mini-os/lib/sys.c
> > > > @@ -31,6 +31,7 @@
> > > >  #include <tpm_tis.h>
> > > >  #include <xenbus.h>
> > > >  #include <xenstore.h>
> > > > +#include <poll.h>
> > > >  
> > > >  #include <sys/types.h>
> > > >  #include <sys/unistd.h>
> > > > @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
> > > >  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
> > > >  #endif
> > > >  
> > > > +#ifdef LIBC_DEBUG
> > > > +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> > > > +{
> > > > +    int i, comma, fd;
> > > > +
> > > > +    printk("[");
> > > > +    comma = 0;
> > > > +    for (i = 0; i < nfds; i++) {
> > > > +        fd = pfd[i].fd;
> > > > +        if (comma)
> > > > +            printk(", ");
> > > > +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> > > > +            pfd[i].events);
> > > > +            comma = 1;
> > > > +    }
> > > > +    printk("]");
> > > > +
> > > > +    printk(", %d, %d", nfds, timeout);
> > > > +}
> > > > +#else
> > > > +#define dump_pollfds(pfds, nfds, timeout)
> > > > +#endif
> > > > +
> > > >  /* Just poll without blocking */
> > > >  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
> > > >  {
> > > > @@ -983,6 +1007,71 @@ out:
> > > >      return ret;
> > > >  }
> > > >  
> > > > +/* Wrap around select */
> > > > +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> > > > +{
> > > > +    int ret;
> > > > +    int i, fd;
> > > > +    struct timeval _timeo, *timeo = NULL;
> > > > +    fd_set rfds, wfds, efds;
> > > > +    int max_fd = -1;
> > > > +
> > > > +    DEBUG("poll(");
> > > > +    dump_pollfds(_pfd, _nfds, _timeout);
> > > > +    DEBUG(")\n");
> > > > +
> > > > +    if (_timeout != -1) {
> > > 
> > > should be _timeout >= 0, any negative value will cause an infinite wait.
> > > 
> > 
> > Right, I was too obsessed with xenstore code which used -1 to represent
> > infinity loop.
> > 
> > > > +        /* Timeout in poll is in millisecond. */
> > > > +        _timeo.tv_sec  = _timeout / 1000;
> > > > +        _timeo.tv_usec = (_timeout - _timeo.tv_sec * 1000) * 1000;
> > > 
> > > why not _timeout % 1000? gcc can also optimize and detect you have a
> > > division and a module and use only a single instruction in x86.
> > > 
> > 
> > Done.
> > 
> > > > +        timeo = &_timeo;
> > > > +    }
> > > > +
> > > > +    FD_ZERO(&rfds);
> > > > +    FD_ZERO(&wfds);
> > > > +    FD_ZERO(&efds);
> > > > +
> > > > +    for (i = 0; i < _nfds; i++) {
> > > > +        fd = _pfd[i].fd;
> > > 
> > > I think you should check if fd is < 0 and return EINVAL (not sure about
> > > the error code). Well.. probably you should check fd in range 0..1023.
> > > 
> > 
> > Unfortunately this is not specified in the standard. I guess we can just
> > ignore print a warning and ignore this fd?
> > 
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html#tag_16_423
> > 
> 
> Yes, it speaks only of STREAM (I don't know what's in this context).
> 
> I tried what happen on Linux. For values < 0 if just ignore the record.
> Oh... from page you send
> 
> "If the value of fd is less than 0, events shall be ignored, and revents
> shall be set to 0 in that entry on return from poll()."
> 

Ah, so it is in the description, good.

> For values that are not open if return POLLNVAL in revents.
> 
> Perhaps should be something like
> 
>     ret = 0;
>     for (i = 0; i < _nfds; i++) {
>         fd = _pfd[i].fd;
>         _pfd[i].revents = 0;
>         if (fd < 0) continue;
>         if (fd >= 1024) {
>             _pfd[i].revents = POLLNVAL;
>             ++ret;
>             continue;
>         

I would go for fd >= NOFILE here (NOFILE is the internal limit of
Mini-OS file abstraction).


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:53:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:53: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 1U7pVi-0004K1-2s; Tue, 19 Feb 2013 15:53:38 +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 1U7pVf-0004Jw-Ql
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:53:36 +0000
Received: from [85.158.138.51:26988] by server-10.bemta-3.messagelabs.com id
	A4/EA-10609-1EF93215; Tue, 19 Feb 2013 15:53:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361289168!26467781!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20239 invoked from network); 19 Feb 2013 15:52:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:52:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1616043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 15:52: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.297.1; Tue, 19 Feb 2013 15:52:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7pUt-0003Ws-NO; Tue, 19 Feb 2013 15:52:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7pUt-0007tA-Gt;
	Tue, 19 Feb 2013 15:52:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.40911.330522.568472@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 15:52:47 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <C18D9DBDB1700B2EECEB6DD8@nimrod.local>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
	<20771.32285.167144.873527@mariner.uk.xensource.com>
	<C18D9DBDB1700B2EECEB6DD8@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@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] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("Re: [PATCHv4 00/11] libxl: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - libxl patchset"):
> --On 19 February 2013 13:29:01 +0000 Ian Jackson 
> <Ian.Jackson@eu.citrix.com> wrote:
> >> The 11 patches to libxl are unchanged since version 3 of the patch,
> >> but have Acked-By lines reintroduced.
> >
> > Thanks for this!  You've made this very convenient.
> 
> No problem.
> 
> > Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
> > object.

Now done.

> Note you will (obviously) need to change the commit ref for qemu once
> the qemu patches are applied.

Yes, this is a routine part of our process for updating the qemu
trees.  I think Stefano will be looking at your qemu-upstream-4.2
patches soon.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:53:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15:53: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 1U7pVi-0004K1-2s; Tue, 19 Feb 2013 15:53:38 +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 1U7pVf-0004Jw-Ql
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:53:36 +0000
Received: from [85.158.138.51:26988] by server-10.bemta-3.messagelabs.com id
	A4/EA-10609-1EF93215; Tue, 19 Feb 2013 15:53:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361289168!26467781!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20239 invoked from network); 19 Feb 2013 15:52:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 15:52:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1616043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 15:52: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.297.1; Tue, 19 Feb 2013 15:52:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7pUt-0003Ws-NO; Tue, 19 Feb 2013 15:52:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7pUt-0007tA-Gt;
	Tue, 19 Feb 2013 15:52:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.40911.330522.568472@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 15:52:47 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <C18D9DBDB1700B2EECEB6DD8@nimrod.local>
References: <1361279760-8024-1-git-send-email-alex@alex.org.uk>
	<20771.32285.167144.873527@mariner.uk.xensource.com>
	<C18D9DBDB1700B2EECEB6DD8@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@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] [PATCHv4 00/11] libxl: Enabling live-migrate on HVM
 on qemu-xen device model in 4.2 - libxl patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("Re: [PATCHv4 00/11] libxl: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - libxl patchset"):
> --On 19 February 2013 13:29:01 +0000 Ian Jackson 
> <Ian.Jackson@eu.citrix.com> wrote:
> >> The 11 patches to libxl are unchanged since version 3 of the patch,
> >> but have Acked-By lines reintroduced.
> >
> > Thanks for this!  You've made this very convenient.
> 
> No problem.
> 
> > Jan, I intend to shovel this lot into 4.2 this afternoon, unless you
> > object.

Now done.

> Note you will (obviously) need to change the commit ref for qemu once
> the qemu patches are applied.

Yes, this is a routine part of our process for updating the qemu
trees.  I think Stefano will be looking at your qemu-upstream-4.2
patches soon.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:54:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15: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 1U7pWN-0004Mm-Nk; Tue, 19 Feb 2013 15:54:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7pWM-0004Me-JZ
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:54:18 +0000
Received: from [85.158.138.51:28614] by server-11.bemta-3.messagelabs.com id
	C3/01-10249-920A3215; Tue, 19 Feb 2013 15:54:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361289254!9544958!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26046 invoked from network); 19 Feb 2013 15:54:16 -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;
	19 Feb 2013 15:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8195461"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 15:54:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 10:54:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7pWH-0001gR-Ic;
	Tue, 19 Feb 2013 15:54:13 +0000
Message-ID: <1361289253.2937.17.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 15:54:13 +0000
In-Reply-To: <1361287529.2937.13.camel@zion.uk.xensource.com>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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

V3 of the patch.

Validate fds before passing it to select. Deal with invalid fds
according to spec.

If fd < 0, revents = 0; if fd >= NOFILE, revents = POLLNVAL.


Wei.

---8<---
>From ad953f1e35ecee08b37215ebc9d6196edd744128 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 12:15:03 +0000
Subject: [PATCH] mini-os: implement poll(2)

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  109 ++++++++++++++++++++++++++++++++++-
 2 files changed, 109 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..46b3933 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,90 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int n;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+    int saved_errno;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    if (_timeout >= 0) {
+        /* Timeout in poll is in millisecond. */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    }
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        _pfd[i].revents = 0;
+
+        /* ignore invalid fds */
+        if (fd < 0 || fd >= NOFILE)
+            continue;
+
+        /* map POLL* into readfds and writefds */
+        /* POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* don't care about the return value, but we do need errno */
+    select(max_fd+1, &rfds, &wfds, &efds, timeo);
+
+    n = 0;
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (fd < 0) continue; /* revents = 0 */
+        /* according to spec, we should set revents = POLLNVAL if fd is invalid */
+        if (fd >= NOFILE) {
+            n++;
+            _pfd[i].revents |= POLLNVAL;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            n++;
+        if (FD_ISSET(fd, &efds)) {
+            /* anything bad happens we set POLLERR, ignoring PULLHUP
+             * POLLNVAL */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    saved_errno = errno;
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+    errno = saved_errno;
+
+    return n;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1468,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 15:54:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 15: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 1U7pWN-0004Mm-Nk; Tue, 19 Feb 2013 15:54:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U7pWM-0004Me-JZ
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 15:54:18 +0000
Received: from [85.158.138.51:28614] by server-11.bemta-3.messagelabs.com id
	C3/01-10249-920A3215; Tue, 19 Feb 2013 15:54:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361289254!9544958!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26046 invoked from network); 19 Feb 2013 15:54:16 -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;
	19 Feb 2013 15:54:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8195461"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 15:54:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 10:54:13 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7pWH-0001gR-Ic;
	Tue, 19 Feb 2013 15:54:13 +0000
Message-ID: <1361289253.2937.17.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 15:54:13 +0000
In-Reply-To: <1361287529.2937.13.camel@zion.uk.xensource.com>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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

V3 of the patch.

Validate fds before passing it to select. Deal with invalid fds
according to spec.

If fd < 0, revents = 0; if fd >= NOFILE, revents = POLLNVAL.


Wei.

---8<---
>From ad953f1e35ecee08b37215ebc9d6196edd744128 Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 12:15:03 +0000
Subject: [PATCH] mini-os: implement poll(2)

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  109 ++++++++++++++++++++++++++++++++++-
 2 files changed, 109 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..46b3933 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,90 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int n;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+    int saved_errno;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    if (_timeout >= 0) {
+        /* Timeout in poll is in millisecond. */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    }
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        _pfd[i].revents = 0;
+
+        /* ignore invalid fds */
+        if (fd < 0 || fd >= NOFILE)
+            continue;
+
+        /* map POLL* into readfds and writefds */
+        /* POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* don't care about the return value, but we do need errno */
+    select(max_fd+1, &rfds, &wfds, &efds, timeo);
+
+    n = 0;
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        if (fd < 0) continue; /* revents = 0 */
+        /* according to spec, we should set revents = POLLNVAL if fd is invalid */
+        if (fd >= NOFILE) {
+            n++;
+            _pfd[i].revents |= POLLNVAL;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            n++;
+        if (FD_ISSET(fd, &efds)) {
+            /* anything bad happens we set POLLERR, ignoring PULLHUP
+             * POLLNVAL */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    saved_errno = errno;
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+    errno = saved_errno;
+
+    return n;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1468,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 16:05:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 16:05: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 1U7pgV-00058Q-7D; Tue, 19 Feb 2013 16:04:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>) id 1U7pgT-00058J-IO
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:04:45 +0000
Received: from [85.158.139.211:36240] by server-7.bemta-5.messagelabs.com id
	EA/98-11121-C92A3215; Tue, 19 Feb 2013 16:04:44 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361289883!14276335!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22335 invoked from network); 19 Feb 2013 16:04:43 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 16:04:43 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U7pgP-00074l-TL; Tue, 19 Feb 2013 17:04:41 +0100
Message-ID: <5123A296.2040607@hosteurope.de>
Date: Tue, 19 Feb 2013 17:04:38 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de> <511D000C.9030908@citrix.com>
	<511E40D8.5070603@hosteurope.de> <5121DA78.2000708@citrix.com>
In-Reply-To: <5121DA78.2000708@citrix.com>
X-Enigmail-Version: 1.5
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2485206185665278502=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============2485206185665278502==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2DMAFQGKILGPPJPXPIRKA"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2DMAFQGKILGPPJPXPIRKA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Roger,
hi all,

On 18.02.2013 08:38, Roger Pau Monn=C3=A9 wrote:
>> The mac address still is not parsed if digits are not padded with
>> leading zero, like "mac=3Dde:ad:a:1e:42:3" - the rest of the line is
>> ignored without any error.
>>
>> However, I was not able to apply patches V2 after that, they do not se=
em
>> to work together with the first patch series.
>=20
> Hello Ulf,
>=20
> Version v2 should be applied without v1, they are not additional
> patches, it's a revision of the same patches (trying to apply both will=

> lead to errors). To simplify it I've pushed the patches to my git repo,=

> so you can fetch them easily:
>=20
> $ git clone -b vif_route_v2 git://xenbits.xen.org/people/royger/xen.git=

>=20

Many thanks, building that tree definitely works. (Still could not get
xen 4.3 running, but that is not the issue here). I have tested the
utils with Xen 4.2.1 and parsing of domu configs with netdev=3D and
gatewaydev=3D parameter works perfectly. Domu does start up and is reache=
able.
I wonder if you could backport these changes to 4.2?

One caveat: the mac address and therfore the rest of the domu config
still is not parsed if not padded with leading zeros, as mentioned before=
=2E

Best regards,
Ulf


------enig2DMAFQGKILGPPJPXPIRKA
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEjopkACgkQhHSVerqjg04bLACfdZEpPCX+QEulbpZeOnczw6QA
3esAn1JW5ng/+LaLQ2ERfgIZyqJSBxVP
=Ef9A
-----END PGP SIGNATURE-----

------enig2DMAFQGKILGPPJPXPIRKA--


--===============2485206185665278502==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2485206185665278502==--


From xen-devel-bounces@lists.xen.org Tue Feb 19 16:05:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 16:05: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 1U7pgV-00058Q-7D; Tue, 19 Feb 2013 16:04:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ulf.kreutzberg@hosteurope.de>) id 1U7pgT-00058J-IO
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:04:45 +0000
Received: from [85.158.139.211:36240] by server-7.bemta-5.messagelabs.com id
	EA/98-11121-C92A3215; Tue, 19 Feb 2013 16:04:44 +0000
X-Env-Sender: ulf.kreutzberg@hosteurope.de
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361289883!14276335!1
X-Originating-IP: [92.51.170.72]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22335 invoked from network); 19 Feb 2013 16:04:43 -0000
Received: from server01.mc0.hosteurope.de (HELO server01.mc0.hosteurope.de)
	(92.51.170.72)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 16:04:43 -0000
Received: from uk.bk.hosteurope.de ([10.20.3.20]); authenticated
	by mailout.hosteurope.de (server01.mc0.hosteurope.de) running
	EXperimental Internet Mailer with esmtpsa (TLSv1:AES256-SHA:256)
	id 1U7pgP-00074l-TL; Tue, 19 Feb 2013 17:04:41 +0100
Message-ID: <5123A296.2040607@hosteurope.de>
Date: Tue, 19 Feb 2013 17:04:38 +0100
From: Ulf Kreutzberg <ulf.kreutzberg@hosteurope.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
References: <1360173877-12696-1-git-send-email-roger.pau@citrix.com>
	<1360173877-12696-3-git-send-email-roger.pau@citrix.com>
	<511CFE2F.2050002@hosteurope.de> <511D000C.9030908@citrix.com>
	<511E40D8.5070603@hosteurope.de> <5121DA78.2000708@citrix.com>
In-Reply-To: <5121DA78.2000708@citrix.com>
X-Enigmail-Version: 1.5
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 v2 2/4] xl: allow specifying a default
	gatewaydev in xl.conf
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2485206185665278502=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============2485206185665278502==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="----enig2DMAFQGKILGPPJPXPIRKA"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2DMAFQGKILGPPJPXPIRKA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Roger,
hi all,

On 18.02.2013 08:38, Roger Pau Monn=C3=A9 wrote:
>> The mac address still is not parsed if digits are not padded with
>> leading zero, like "mac=3Dde:ad:a:1e:42:3" - the rest of the line is
>> ignored without any error.
>>
>> However, I was not able to apply patches V2 after that, they do not se=
em
>> to work together with the first patch series.
>=20
> Hello Ulf,
>=20
> Version v2 should be applied without v1, they are not additional
> patches, it's a revision of the same patches (trying to apply both will=

> lead to errors). To simplify it I've pushed the patches to my git repo,=

> so you can fetch them easily:
>=20
> $ git clone -b vif_route_v2 git://xenbits.xen.org/people/royger/xen.git=

>=20

Many thanks, building that tree definitely works. (Still could not get
xen 4.3 running, but that is not the issue here). I have tested the
utils with Xen 4.2.1 and parsing of domu configs with netdev=3D and
gatewaydev=3D parameter works perfectly. Domu does start up and is reache=
able.
I wonder if you could backport these changes to 4.2?

One caveat: the mac address and therfore the rest of the domu config
still is not parsed if not padded with leading zeros, as mentioned before=
=2E

Best regards,
Ulf


------enig2DMAFQGKILGPPJPXPIRKA
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 Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEjopkACgkQhHSVerqjg04bLACfdZEpPCX+QEulbpZeOnczw6QA
3esAn1JW5ng/+LaLQ2ERfgIZyqJSBxVP
=Ef9A
-----END PGP SIGNATURE-----

------enig2DMAFQGKILGPPJPXPIRKA--


--===============2485206185665278502==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2485206185665278502==--


From xen-devel-bounces@lists.xen.org Tue Feb 19 16:33:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 16:33: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 1U7q7u-0005TB-3P; Tue, 19 Feb 2013 16:33:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7q7s-0005T6-R8
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:33:04 +0000
Received: from [85.158.138.51:9442] by server-12.bemta-3.messagelabs.com id
	91/4C-05889-B39A3215; Tue, 19 Feb 2013 16:32:59 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361291578!28231879!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31851 invoked from network); 19 Feb 2013 16:32:58 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 16:32:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355094000"; 
   d="scan'208";a="3581086"
Received: from unknown (HELO type.ipv6) ([193.50.110.245])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	19 Feb 2013 17:32:58 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7q7l-0006e3-Pz; Tue, 19 Feb 2013 17:32:57 +0100
Date: Tue, 19 Feb 2013 17:32:57 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219163257.GR6098@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361289253.2937.17.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Liu, le Tue 19 Feb 2013 15:54:13 +0000, a =E9crit :
> if fd >=3D NOFILE, revents =3D POLLNVAL.

"invalid" is also "not opened". You should additionally test that
files[i].type !=3D FTYPE_NONE.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 16:33:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 16:33: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 1U7q7u-0005TB-3P; Tue, 19 Feb 2013 16:33:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7q7s-0005T6-R8
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:33:04 +0000
Received: from [85.158.138.51:9442] by server-12.bemta-3.messagelabs.com id
	91/4C-05889-B39A3215; Tue, 19 Feb 2013 16:32:59 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361291578!28231879!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31851 invoked from network); 19 Feb 2013 16:32:58 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 16:32:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355094000"; 
   d="scan'208";a="3581086"
Received: from unknown (HELO type.ipv6) ([193.50.110.245])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	19 Feb 2013 17:32:58 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7q7l-0006e3-Pz; Tue, 19 Feb 2013 17:32:57 +0100
Date: Tue, 19 Feb 2013 17:32:57 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219163257.GR6098@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361289253.2937.17.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Liu, le Tue 19 Feb 2013 15:54:13 +0000, a =E9crit :
> if fd >=3D NOFILE, revents =3D POLLNVAL.

"invalid" is also "not opened". You should additionally test that
files[i].type !=3D FTYPE_NONE.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 16:41:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7qFX-0005cT-1p; Tue, 19 Feb 2013 16:40:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7qFV-0005cO-Ml
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:40:57 +0000
Received: from [85.158.139.83:64800] by server-10.bemta-5.messagelabs.com id
	8E/17-04697-91BA3215; Tue, 19 Feb 2013 16:40:57 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1361292055!27874949!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32448 invoked from network); 19 Feb 2013 16:40:56 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 16:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355094000"; 
   d="scan'208";a="3582408"
Received: from unknown (HELO type.ipv6) ([193.50.110.245])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	19 Feb 2013 17:39:55 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7qEV-0006nP-HB; Tue, 19 Feb 2013 17:39:55 +0100
Date: Tue, 19 Feb 2013 17:39:55 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219163955.GS6098@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361289253.2937.17.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also, checking for files[i].type should be done on entry to the
function, not after having waited for some time (and perhaps opened some
file descriptor, etc.). I.e.:

Wei Liu, le Tue 19 Feb 2013 15:54:13 +0000, a =E9crit :
> +        /* ignore invalid fds */
> +        if (fd < 0 || fd >=3D NOFILE)
> +            continue;

record POLLNVAL as soon as here, and ignore that fd later on.

> +    /* don't care about the return value, but we do need errno */
> +    select(max_fd+1, &rfds, &wfds, &efds, timeo);

Mmm. I don't think we don't care about the return value: if select
returns -1 with EINTR, poll has to do the same. That's however probably
the only case we have to take care of.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 16:41:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 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 1U7qFX-0005cT-1p; Tue, 19 Feb 2013 16:40:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7qFV-0005cO-Ml
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:40:57 +0000
Received: from [85.158.139.83:64800] by server-10.bemta-5.messagelabs.com id
	8E/17-04697-91BA3215; Tue, 19 Feb 2013 16:40:57 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1361292055!27874949!1
X-Originating-IP: [192.134.164.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32448 invoked from network); 19 Feb 2013 16:40:56 -0000
Received: from mail2-relais-roc.national.inria.fr (HELO
	mail2-relais-roc.national.inria.fr) (192.134.164.83)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 16:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355094000"; 
   d="scan'208";a="3582408"
Received: from unknown (HELO type.ipv6) ([193.50.110.245])
	by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	19 Feb 2013 17:39:55 +0100
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7qEV-0006nP-HB; Tue, 19 Feb 2013 17:39:55 +0100
Date: Tue, 19 Feb 2013 17:39:55 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219163955.GS6098@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361289253.2937.17.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also, checking for files[i].type should be done on entry to the
function, not after having waited for some time (and perhaps opened some
file descriptor, etc.). I.e.:

Wei Liu, le Tue 19 Feb 2013 15:54:13 +0000, a =E9crit :
> +        /* ignore invalid fds */
> +        if (fd < 0 || fd >=3D NOFILE)
> +            continue;

record POLLNVAL as soon as here, and ignore that fd later on.

> +    /* don't care about the return value, but we do need errno */
> +    select(max_fd+1, &rfds, &wfds, &efds, timeo);

Mmm. I don't think we don't care about the return value: if select
returns -1 with EINTR, poll has to do the same. That's however probably
the only case we have to take care of.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 16:42:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 16:42: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 1U7qGt-0005jD-Hb; Tue, 19 Feb 2013 16:42: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 1U7qGr-0005j4-VM
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:42:22 +0000
Received: from [85.158.143.99:65233] by server-3.bemta-4.messagelabs.com id
	51/E9-08920-D6BA3215; Tue, 19 Feb 2013 16:42:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361292139!27600076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4282 invoked from network); 19 Feb 2013 16:42:20 -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;
	19 Feb 2013 16:42:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8210039"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 16:42:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 11:42:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7qGn-0002OH-VB;
	Tue, 19 Feb 2013 16:42:17 +0000
Date: Tue, 19 Feb 2013 16:42:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302191642060.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>  xen/include/public/xen.h              |    8 ++++----
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..57681fa 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
>  };
> +header["arm"] = """
> +#define __arm___ARM32 1
> +""";
>  
>  # x86_32
>  inttypes["x86_32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint32_t",
> +    "xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>      "unsigned long" : "__align8__ uint64_t",
>      "long"          : "__align8__ uint64_t",
>      "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>      /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>       */
>      uint8_t evtchn_upcall_pending;
>      uint8_t evtchn_upcall_mask;
> -    unsigned long evtchn_pending_sel;
> +    xen_ulong_t evtchn_pending_sel;
>      struct arch_vcpu_info arch;
>      struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>       * per-vcpu selector word to be set. Each bit in the selector covers a
>       * 'C long' in the PENDING bitfield array.
>       */
> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>      /*
>       * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 16:42:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 16:42: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 1U7qGt-0005jD-Hb; Tue, 19 Feb 2013 16:42: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 1U7qGr-0005j4-VM
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 16:42:22 +0000
Received: from [85.158.143.99:65233] by server-3.bemta-4.messagelabs.com id
	51/E9-08920-D6BA3215; Tue, 19 Feb 2013 16:42:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361292139!27600076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4282 invoked from network); 19 Feb 2013 16:42:20 -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;
	19 Feb 2013 16:42:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8210039"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 16:42:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 11:42:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7qGn-0002OH-VB;
	Tue, 19 Feb 2013 16:42:17 +0000
Date: Tue, 19 Feb 2013 16:42:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302191642060.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>  xen/include/public/xen.h              |    8 ++++----
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..57681fa 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
>  };
> +header["arm"] = """
> +#define __arm___ARM32 1
> +""";
>  
>  # x86_32
>  inttypes["x86_32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint32_t",
> +    "xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>      "unsigned long" : "__align8__ uint64_t",
>      "long"          : "__align8__ uint64_t",
>      "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>      /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>       */
>      uint8_t evtchn_upcall_pending;
>      uint8_t evtchn_upcall_mask;
> -    unsigned long evtchn_pending_sel;
> +    xen_ulong_t evtchn_pending_sel;
>      struct arch_vcpu_info arch;
>      struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>       * per-vcpu selector word to be set. Each bit in the selector covers a
>       * 'C long' in the PENDING bitfield array.
>       */
> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>      /*
>       * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:01:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qYu-000635-9c; Tue, 19 Feb 2013 17:01: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 1U7qYt-00062h-6e
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:00:59 +0000
Received: from [85.158.139.211:29700] by server-14.bemta-5.messagelabs.com id
	DA/E4-06967-ACFA3215; Tue, 19 Feb 2013 17:00:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361293256!17826735!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 602 invoked from network); 19 Feb 2013 17:00:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:00:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1618812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:00: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.297.1; Tue, 19 Feb 2013 17:00:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7qYq-0003yC-5i; Tue, 19 Feb 2013 17:00:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7qYp-0007yY-W4;
	Tue, 19 Feb 2013 17:00:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.44996.774464.387396@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 17:00:52 +0000
To: Darren Shepherd <darren.s.shepherd@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.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] why are qemu-img and vhd-util created
	files	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Darren Shepherd writes ("[Xen-devel] why are qemu-img and vhd-util created files incompatible?"):
> I was wondering if someone can shed some light on why vhd files
> created with qemu-img don't really work right with vhd-util and
> consequentially blktap in general.  To validate the incompatiblity its
> simple enough to do
> 
> qemu-img create -f vpc test.vhd 40g
> vhd-util snapshot -n child.vhd -p test.vhd
...
> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
> you the same 22 error.
> 
> I was going to start researching this with the eventual goal of
> changing qemu-img, but I thought I'd ask the experts first.

I'm afraid there aren't many experts here on the vhd code in the
xen-unstable tree.  It's possible that the qemu-img built from
qemu-xen-traditional "qemu-img-xen" might be more compatible.

Please do let us know what you discover.

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 Feb 19 17:01:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qYu-000635-9c; Tue, 19 Feb 2013 17:01: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 1U7qYt-00062h-6e
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:00:59 +0000
Received: from [85.158.139.211:29700] by server-14.bemta-5.messagelabs.com id
	DA/E4-06967-ACFA3215; Tue, 19 Feb 2013 17:00:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361293256!17826735!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 602 invoked from network); 19 Feb 2013 17:00:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:00:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1618812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:00: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.297.1; Tue, 19 Feb 2013 17:00:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7qYq-0003yC-5i; Tue, 19 Feb 2013 17:00:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7qYp-0007yY-W4;
	Tue, 19 Feb 2013 17:00:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.44996.774464.387396@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 17:00:52 +0000
To: Darren Shepherd <darren.s.shepherd@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.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] why are qemu-img and vhd-util created
	files	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Darren Shepherd writes ("[Xen-devel] why are qemu-img and vhd-util created files incompatible?"):
> I was wondering if someone can shed some light on why vhd files
> created with qemu-img don't really work right with vhd-util and
> consequentially blktap in general.  To validate the incompatiblity its
> simple enough to do
> 
> qemu-img create -f vpc test.vhd 40g
> vhd-util snapshot -n child.vhd -p test.vhd
...
> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
> you the same 22 error.
> 
> I was going to start researching this with the eventual goal of
> changing qemu-img, but I thought I'd ask the experts first.

I'm afraid there aren't many experts here on the vhd code in the
xen-unstable tree.  It's possible that the qemu-img built from
qemu-xen-traditional "qemu-img-xen" might be more compatible.

Please do let us know what you discover.

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 Feb 19 17:12:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:12: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 1U7qjS-0006Fm-JG; Tue, 19 Feb 2013 17:11:54 +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 1U7qjR-0006Ff-6e
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:11:53 +0000
Received: from [85.158.139.83:9387] by server-12.bemta-5.messagelabs.com id
	06/D6-20195-852B3215; Tue, 19 Feb 2013 17:11:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361293910!27982106!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 19 Feb 2013 17:11:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:11:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8220652"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:11:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:11:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7qjN-0002sL-5U;
	Tue, 19 Feb 2013 17:11:49 +0000
Date: Tue, 19 Feb 2013 17:11:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> ---
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 ++++++++
>  arch/x86/include/asm/xen/events.h |    3 +
>  drivers/xen/events.c              |  103 ++++++++++++++++++++-----------------
>  include/xen/interface/xen.h       |    8 ++--
>  4 files changed, 84 insertions(+), 52 deletions(-)

You might have to rebase this patch: it doesn't apply on Linux 3.8.


> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..9bb5f50 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>         return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
> 
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +       xen_ulong_t oldval;
> +       unsigned int tmp;
> +
> +       wmb();
> +       asm volatile("@ read_evtchn_pending_sel\n"
                           ^ do we need this?


> +               "1:     ldrexd  %0, %H0, [%3]\n"
> +               "       strexd  %1, %2, %H2, [%3]\n"
> +               "       teq     %1, #0\n"
> +               "       bne     1b"
> +               : "=&r" (oldval), "=&r" (tmp)
> +               : "r" (val), "r" (ptr)
> +               : "memory", "cc");
> +       return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */

[...]

> @@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
>         unsigned count;
> 
>         do {
> -               unsigned long pending_words;
> +               xen_ulong_t pending_words;
> 
>                 vcpu_info->evtchn_upcall_pending = 0;
> 
>                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
>                         goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -               /* Clear master flag /before/ clearing selector flag. */
> -               wmb();
> -#endif

Even though I understand that moving wmb() into xchg_xen_ulong gets rid
of an ugly ifndef, I am not sure whether it is a good thing from the
code readability point of view. I'll let Konrad decide on this one.


> -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
>                 start_word_idx = __this_cpu_read(current_word_idx);
>                 start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
>                 word_idx = start_word_idx;
> 
>                 for (i = 0; pending_words != 0; i++) {
> -                       unsigned long pending_bits;
> -                       unsigned long words;
> +                       xen_ulong_t pending_bits;
> +                       xen_ulong_t words;
> 
>                         words = MASK_LSBS(pending_words, word_idx);
> 
> @@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
>                                 bit_idx = 0;
>                                 continue;
>                         }
> -                       word_idx = __ffs(words);
> +                       word_idx = find_first_bit(BM(&words), sizeof(words));
> 
>                         pending_bits = active_evtchns(cpu, s, word_idx);
>                         bit_idx = 0; /* usually scan entire word from start */

is that because find_first_bit can actually cope with a bit number >=
32 and __ffs can't?
In that case it is worth adding a comment somewhere in this file,
reminding people to only use bit operations that can handle size >
unsigned long


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:12:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:12: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 1U7qjS-0006Fm-JG; Tue, 19 Feb 2013 17:11:54 +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 1U7qjR-0006Ff-6e
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:11:53 +0000
Received: from [85.158.139.83:9387] by server-12.bemta-5.messagelabs.com id
	06/D6-20195-852B3215; Tue, 19 Feb 2013 17:11:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361293910!27982106!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12344 invoked from network); 19 Feb 2013 17:11:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:11:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8220652"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:11:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:11:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7qjN-0002sL-5U;
	Tue, 19 Feb 2013 17:11:49 +0000
Date: Tue, 19 Feb 2013 17:11:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> ---
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 ++++++++
>  arch/x86/include/asm/xen/events.h |    3 +
>  drivers/xen/events.c              |  103 ++++++++++++++++++++-----------------
>  include/xen/interface/xen.h       |    8 ++--
>  4 files changed, 84 insertions(+), 52 deletions(-)

You might have to rebase this patch: it doesn't apply on Linux 3.8.


> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..9bb5f50 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>         return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
> 
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +       xen_ulong_t oldval;
> +       unsigned int tmp;
> +
> +       wmb();
> +       asm volatile("@ read_evtchn_pending_sel\n"
                           ^ do we need this?


> +               "1:     ldrexd  %0, %H0, [%3]\n"
> +               "       strexd  %1, %2, %H2, [%3]\n"
> +               "       teq     %1, #0\n"
> +               "       bne     1b"
> +               : "=&r" (oldval), "=&r" (tmp)
> +               : "r" (val), "r" (ptr)
> +               : "memory", "cc");
> +       return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */

[...]

> @@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
>         unsigned count;
> 
>         do {
> -               unsigned long pending_words;
> +               xen_ulong_t pending_words;
> 
>                 vcpu_info->evtchn_upcall_pending = 0;
> 
>                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
>                         goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -               /* Clear master flag /before/ clearing selector flag. */
> -               wmb();
> -#endif

Even though I understand that moving wmb() into xchg_xen_ulong gets rid
of an ugly ifndef, I am not sure whether it is a good thing from the
code readability point of view. I'll let Konrad decide on this one.


> -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
>                 start_word_idx = __this_cpu_read(current_word_idx);
>                 start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
>                 word_idx = start_word_idx;
> 
>                 for (i = 0; pending_words != 0; i++) {
> -                       unsigned long pending_bits;
> -                       unsigned long words;
> +                       xen_ulong_t pending_bits;
> +                       xen_ulong_t words;
> 
>                         words = MASK_LSBS(pending_words, word_idx);
> 
> @@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
>                                 bit_idx = 0;
>                                 continue;
>                         }
> -                       word_idx = __ffs(words);
> +                       word_idx = find_first_bit(BM(&words), sizeof(words));
> 
>                         pending_bits = active_evtchns(cpu, s, word_idx);
>                         bit_idx = 0; /* usually scan entire word from start */

is that because find_first_bit can actually cope with a bit number >=
32 and __ffs can't?
In that case it is worth adding a comment somewhere in this file,
reminding people to only use bit operations that can handle size >
unsigned long


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:19:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:19: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 1U7qqO-0006S4-MK; Tue, 19 Feb 2013 17:19:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U7qqN-0006Rz-G5
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:19:03 +0000
Received: from [85.158.143.99:32194] by server-3.bemta-4.messagelabs.com id
	43/50-08920-604B3215; Tue, 19 Feb 2013 17:19:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361294309!27606684!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13412 invoked from network); 19 Feb 2013 17:18:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:18:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:17: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.297.1;
	Tue, 19 Feb 2013 17:17:30 +0000
Message-ID: <1361294248.1051.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 17:17:28 +0000
In-Reply-To: <alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 17:11 +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: xen-devel@lists.xen.org
> > ---
> > Changes since V1
> >   use find_first_set not __ffs
> >   fix some more unsigned long -> xen_ulong_t
> >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> > ---
> >  arch/arm/include/asm/xen/events.h |   22 ++++++++
> >  arch/x86/include/asm/xen/events.h |    3 +
> >  drivers/xen/events.c              |  103 ++++++++++++++++++++-----------------
> >  include/xen/interface/xen.h       |    8 ++--
> >  4 files changed, 84 insertions(+), 52 deletions(-)
> 
> You might have to rebase this patch: it doesn't apply on Linux 3.8.

Will do.

> 
> 
> > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..9bb5f50 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >         return raw_irqs_disabled_flags(regs->ARM_cpsr);
> >  }
> > 
> > +/*
> > + * We cannot use xchg because it does not support 8-byte
> > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > + * platforms which Xen can run on support those instructions.
> > + */
> > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > +{
> > +       xen_ulong_t oldval;
> > +       unsigned int tmp;
> > +
> > +       wmb();
> > +       asm volatile("@ read_evtchn_pending_sel\n"
>                            ^ do we need this?

It means that the .s files (if you create them) and such are a bit more
readable, it's not that uncommon in the ARM inline assembly.

> > +               "1:     ldrexd  %0, %H0, [%3]\n"
> > +               "       strexd  %1, %2, %H2, [%3]\n"
> > +               "       teq     %1, #0\n"
> > +               "       bne     1b"
> > +               : "=&r" (oldval), "=&r" (tmp)
> > +               : "r" (val), "r" (ptr)
> > +               : "memory", "cc");
> > +       return oldval;
> > +}
> > +
> >  #endif /* _ASM_ARM_XEN_EVENTS_H */
> 
> [...]
> 
> > @@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
> >         unsigned count;
> > 
> >         do {
> > -               unsigned long pending_words;
> > +               xen_ulong_t pending_words;
> > 
> >                 vcpu_info->evtchn_upcall_pending = 0;
> > 
> >                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
> >                         goto out;
> > 
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > -               /* Clear master flag /before/ clearing selector flag. */
> > -               wmb();
> > -#endif
> 
> Even though I understand that moving wmb() into xchg_xen_ulong gets rid
> of an ugly ifndef, I am not sure whether it is a good thing from the
> code readability point of view. I'll let Konrad decide on this one.

I actually see this the other way -- this barrier is logically part of
the exchange operation, implicitly on x86 and explicitly on ARM. I will
add a comment here though, which I think is best of both.

> 
> 
> > -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> > 
> >                 start_word_idx = __this_cpu_read(current_word_idx);
> >                 start_bit_idx = __this_cpu_read(current_bit_idx);
> > @@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
> >                 word_idx = start_word_idx;
> > 
> >                 for (i = 0; pending_words != 0; i++) {
> > -                       unsigned long pending_bits;
> > -                       unsigned long words;
> > +                       xen_ulong_t pending_bits;
> > +                       xen_ulong_t words;
> > 
> >                         words = MASK_LSBS(pending_words, word_idx);
> > 
> > @@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
> >                                 bit_idx = 0;
> >                                 continue;
> >                         }
> > -                       word_idx = __ffs(words);
> > +                       word_idx = find_first_bit(BM(&words), sizeof(words));
> > 
> >                         pending_bits = active_evtchns(cpu, s, word_idx);
> >                         bit_idx = 0; /* usually scan entire word from start */
> 
> is that because find_first_bit can actually cope with a bit number >=
> 32 and __ffs can't?

Yes.

> In that case it is worth adding a comment somewhere in this file,
> reminding people to only use bit operations that can handle size >
> unsigned long

Will do.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:19:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:19: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 1U7qqO-0006S4-MK; Tue, 19 Feb 2013 17:19:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1U7qqN-0006Rz-G5
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:19:03 +0000
Received: from [85.158.143.99:32194] by server-3.bemta-4.messagelabs.com id
	43/50-08920-604B3215; Tue, 19 Feb 2013 17:19:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361294309!27606684!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13412 invoked from network); 19 Feb 2013 17:18:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:18:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:17: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.297.1;
	Tue, 19 Feb 2013 17:17:30 +0000
Message-ID: <1361294248.1051.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 19 Feb 2013 17:17:28 +0000
In-Reply-To: <alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 17:11 +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: xen-devel@lists.xen.org
> > ---
> > Changes since V1
> >   use find_first_set not __ffs
> >   fix some more unsigned long -> xen_ulong_t
> >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> > ---
> >  arch/arm/include/asm/xen/events.h |   22 ++++++++
> >  arch/x86/include/asm/xen/events.h |    3 +
> >  drivers/xen/events.c              |  103 ++++++++++++++++++++-----------------
> >  include/xen/interface/xen.h       |    8 ++--
> >  4 files changed, 84 insertions(+), 52 deletions(-)
> 
> You might have to rebase this patch: it doesn't apply on Linux 3.8.

Will do.

> 
> 
> > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..9bb5f50 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >         return raw_irqs_disabled_flags(regs->ARM_cpsr);
> >  }
> > 
> > +/*
> > + * We cannot use xchg because it does not support 8-byte
> > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > + * platforms which Xen can run on support those instructions.
> > + */
> > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > +{
> > +       xen_ulong_t oldval;
> > +       unsigned int tmp;
> > +
> > +       wmb();
> > +       asm volatile("@ read_evtchn_pending_sel\n"
>                            ^ do we need this?

It means that the .s files (if you create them) and such are a bit more
readable, it's not that uncommon in the ARM inline assembly.

> > +               "1:     ldrexd  %0, %H0, [%3]\n"
> > +               "       strexd  %1, %2, %H2, [%3]\n"
> > +               "       teq     %1, #0\n"
> > +               "       bne     1b"
> > +               : "=&r" (oldval), "=&r" (tmp)
> > +               : "r" (val), "r" (ptr)
> > +               : "memory", "cc");
> > +       return oldval;
> > +}
> > +
> >  #endif /* _ASM_ARM_XEN_EVENTS_H */
> 
> [...]
> 
> > @@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
> >         unsigned count;
> > 
> >         do {
> > -               unsigned long pending_words;
> > +               xen_ulong_t pending_words;
> > 
> >                 vcpu_info->evtchn_upcall_pending = 0;
> > 
> >                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
> >                         goto out;
> > 
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > -               /* Clear master flag /before/ clearing selector flag. */
> > -               wmb();
> > -#endif
> 
> Even though I understand that moving wmb() into xchg_xen_ulong gets rid
> of an ugly ifndef, I am not sure whether it is a good thing from the
> code readability point of view. I'll let Konrad decide on this one.

I actually see this the other way -- this barrier is logically part of
the exchange operation, implicitly on x86 and explicitly on ARM. I will
add a comment here though, which I think is best of both.

> 
> 
> > -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> > 
> >                 start_word_idx = __this_cpu_read(current_word_idx);
> >                 start_bit_idx = __this_cpu_read(current_bit_idx);
> > @@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
> >                 word_idx = start_word_idx;
> > 
> >                 for (i = 0; pending_words != 0; i++) {
> > -                       unsigned long pending_bits;
> > -                       unsigned long words;
> > +                       xen_ulong_t pending_bits;
> > +                       xen_ulong_t words;
> > 
> >                         words = MASK_LSBS(pending_words, word_idx);
> > 
> > @@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
> >                                 bit_idx = 0;
> >                                 continue;
> >                         }
> > -                       word_idx = __ffs(words);
> > +                       word_idx = find_first_bit(BM(&words), sizeof(words));
> > 
> >                         pending_bits = active_evtchns(cpu, s, word_idx);
> >                         bit_idx = 0; /* usually scan entire word from start */
> 
> is that because find_first_bit can actually cope with a bit number >=
> 32 and __ffs can't?

Yes.

> In that case it is worth adding a comment somewhere in this file,
> reminding people to only use bit operations that can handle size >
> unsigned long

Will do.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:21:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qsw-0006aI-Av; Tue, 19 Feb 2013 17:21: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 1U7qsu-0006aA-Sq
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 17:21:41 +0000
Received: from [85.158.137.99:46914] by server-15.bemta-3.messagelabs.com id
	E6/F7-25405-3A4B3215; Tue, 19 Feb 2013 17:21:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361294498!14719158!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25304 invoked from network); 19 Feb 2013 17:21:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:21:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:21: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.297.1; Tue, 19 Feb 2013 17:21:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7qsr-00047P-Jt; Tue, 19 Feb 2013 17:21:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7qsr-00080S-D8;
	Tue, 19 Feb 2013 17:21:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.46241.302261.811458@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 17:21:37 +0000
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361183625-3640-1-git-send-email-fantonifabio@tiscali.it>
References: <1361183625-3640-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhou Peng <zpengxen@gmail.com>, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v10] tools/libxl: Add qxl vga interface
	support	for upstream 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

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH v10] tools/libxl: Add qxl vga interface support for upstream qemu"):
> Changes from v8:
> - vga=qxl instead of qxl=1 to use it.
> - Show an error and exit if vga="qxl" without qemu upstream.
> - Other small improvements.

This looks plausible to me.  I'd like an ack from Stefano.

Also this patch has some more of the formatting problems I mentioned
before and which Ian C has expanded on:

> +        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->device_model_version ==
> +               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                    b_info->video_memkb = (128 * 1024);
> +                }else if (b_info->video_memkb < (128 * 1024)) {

                    ^ extra space neeeded

Also it would be better for the 128MB figure to occur only once in the
source code, perhaps with a const or a #define.

> +                    LOG(ERROR,
> +                    "128 Mib videoram is the minimum for qxl default");

                           ^ should be indented to here; you can
                             use "a" "b" style string concatenation if
                             that's convenient to split the string
                             across multiple lines

> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            /*QXL have 2 ram regions, ram and vram*/
                 ^ spaces here and                   ^ here
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), "-global",
> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), NULL);

This needs indentation to the right level, in each case to where the
relevant parens open.  Also you will probably find GCSPRINTF a helpful
macro which will make this a lot shorter.

> +            }else if (!strcmp(buf, "qxl")) {

                ^ space

> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_QXL;

                       ^ indentation needs to be to here

I appreciate that these will seem like nits, and that there are
existing places where the indentation and formatting is wrong, but
they are things that the reader's eye trips over and we are trying to
fix them, not introduce more of them.

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 Feb 19 17:21:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qsw-0006aI-Av; Tue, 19 Feb 2013 17:21: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 1U7qsu-0006aA-Sq
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 17:21:41 +0000
Received: from [85.158.137.99:46914] by server-15.bemta-3.messagelabs.com id
	E6/F7-25405-3A4B3215; Tue, 19 Feb 2013 17:21:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361294498!14719158!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25304 invoked from network); 19 Feb 2013 17:21:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:21:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:21: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.297.1; Tue, 19 Feb 2013 17:21:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7qsr-00047P-Jt; Tue, 19 Feb 2013 17:21:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7qsr-00080S-D8;
	Tue, 19 Feb 2013 17:21:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.46241.302261.811458@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 17:21:37 +0000
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361183625-3640-1-git-send-email-fantonifabio@tiscali.it>
References: <1361183625-3640-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhou Peng <zpengxen@gmail.com>, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v10] tools/libxl: Add qxl vga interface
	support	for upstream 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

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH v10] tools/libxl: Add qxl vga interface support for upstream qemu"):
> Changes from v8:
> - vga=qxl instead of qxl=1 to use it.
> - Show an error and exit if vga="qxl" without qemu upstream.
> - Other small improvements.

This looks plausible to me.  I'd like an ack from Stefano.

Also this patch has some more of the formatting problems I mentioned
before and which Ian C has expanded on:

> +        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            if (b_info->device_model_version ==
> +               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                    b_info->video_memkb = (128 * 1024);
> +                }else if (b_info->video_memkb < (128 * 1024)) {

                    ^ extra space neeeded

Also it would be better for the 128MB figure to occur only once in the
source code, perhaps with a const or a #define.

> +                    LOG(ERROR,
> +                    "128 Mib videoram is the minimum for qxl default");

                           ^ should be indented to here; you can
                             use "a" "b" style string concatenation if
                             that's convenient to split the string
                             across multiple lines

> +        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> +            /*QXL have 2 ram regions, ram and vram*/
                 ^ spaces here and                   ^ here
> +            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> +            if (b_info->video_memkb) {
> +                flexarray_vappend(dm_args, "-global",
> +                libxl__sprintf(gc, "qxl-vga.vram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), "-global",
> +                libxl__sprintf(gc, "qxl-vga.ram_size_mb=%lu",
> +                (b_info->video_memkb/2/1024)), NULL);

This needs indentation to the right level, in each case to where the
relevant parens open.  Also you will probably find GCSPRINTF a helpful
macro which will make this a lot shorter.

> +            }else if (!strcmp(buf, "qxl")) {

                ^ space

> +                b_info->u.hvm.vga.kind
> +                = LIBXL_VGA_INTERFACE_TYPE_QXL;

                       ^ indentation needs to be to here

I appreciate that these will seem like nits, and that there are
existing places where the indentation and formatting is wrong, but
they are things that the reader's eye trips over and we are trying to
fix them, not introduce more of them.

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 Feb 19 17:22:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:22: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 1U7qtf-0006dz-PO; Tue, 19 Feb 2013 17:22:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7qte-0006dj-2u
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:22:26 +0000
Received: from [85.158.139.83:52680] by server-8.bemta-5.messagelabs.com id
	23/8C-19075-1D4B3215; Tue, 19 Feb 2013 17:22:25 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361294544!16703154!1
X-Originating-IP: [46.33.159.39]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14776 invoked from network); 19 Feb 2013 17:22:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:22:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619782"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:22:25 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 19 Feb 2013
	17:22:24 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>
Date: Tue, 19 Feb 2013 17:22:23 +0000
Thread-Topic: [Xen-devel] [PATCH] mini-os: implement poll(2)
Thread-Index: Ac4Oxa5YXA0qC0s7SzuNeq8bEIbXLQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163955.GS6098@type.bordeaux.inria.fr>
In-Reply-To: <20130219163955.GS6098@type.bordeaux.inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEzLTAyLTE5IGF0IDE3OjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gQWxzbywgY2hlY2tpbmcgZm9yIGZpbGVzW2ldLnR5cGUgc2hvdWxkIGJlIGRvbmUgb24gZW50
cnkgdG8gdGhlCj4gZnVuY3Rpb24sIG5vdCBhZnRlciBoYXZpbmcgd2FpdGVkIGZvciBzb21lIHRp
bWUgKGFuZCBwZXJoYXBzIG9wZW5lZCBzb21lCj4gZmlsZSBkZXNjcmlwdG9yLCBldGMuKS4gSS5l
LjoKPiAKPiBXZWkgTGl1LCBsZSBUdWUgMTkgRmViIDIwMTMgMTU6NTQ6MTMgKzAwMDAsIGEgw6lj
cml0IDoKPiA+ICsgICAgICAgIC8qIGlnbm9yZSBpbnZhbGlkIGZkcyAqLwo+ID4gKyAgICAgICAg
aWYgKGZkIDwgMCB8fCBmZCA+PSBOT0ZJTEUpCj4gPiArICAgICAgICAgICAgY29udGludWU7Cj4g
Cj4gcmVjb3JkIFBPTExOVkFMIGFzIHNvb24gYXMgaGVyZSwgYW5kIGlnbm9yZSB0aGF0IGZkIGxh
dGVyIG9uLgo+IAoKSWYgeW91IGRldGVjdCB0aGUgaGFuZGxlIGlzIGludmFsaWQgeW91IHNob3Vs
ZCBub3Qgd2FpdCBpbiBzZWxlY3Qgb3Igc2V0CnRoZSB0aW1lb3V0IHRvIDAuIHBvbGwgc2hvdWxk
IHJldHVybiBhcyBzb29uIGF0IGl0IHJlY2VpdmUgYW4gZXZlbnQuIEluCnRoaXMgY2FzZSBnZXR0
aW5nIFBPTExOVkFMIGlzIGFuIGV2ZW50LiBJIGRvbid0IGtub3cgaWYgeW91IGhhdmUgdG8gdGVz
dAphbGwgaGFuZGxlcyBpbiB0aGlzIGNhc2Ugb3IganVzdCByZXR1cm4gdGhlIG51bWJlciBvZiBm
ZHMgdGhhdCBnb3Qgc2V0CnRvIFBPTExOVkFMLgoKPiA+ICsgICAgLyogZG9uJ3QgY2FyZSBhYm91
dCB0aGUgcmV0dXJuIHZhbHVlLCBidXQgd2UgZG8gbmVlZCBlcnJubyAqLwo+ID4gKyAgICBzZWxl
Y3QobWF4X2ZkKzEsICZyZmRzLCAmd2ZkcywgJmVmZHMsIHRpbWVvKTsKPiAKPiBNbW0uIEkgZG9u
J3QgdGhpbmsgd2UgZG9uJ3QgY2FyZSBhYm91dCB0aGUgcmV0dXJuIHZhbHVlOiBpZiBzZWxlY3QK
PiByZXR1cm5zIC0xIHdpdGggRUlOVFIsIHBvbGwgaGFzIHRvIGRvIHRoZSBzYW1lLiBUaGF0J3Mg
aG93ZXZlciBwcm9iYWJseQo+IHRoZSBvbmx5IGNhc2Ugd2UgaGF2ZSB0byB0YWtlIGNhcmUgb2Yu
Cj4gCgppZiB5b3UgZ2V0IGFuIGVycm9yIHlvdSBjYW4ndCBjb25zaWRlciB2YWxpZCB0aGUgc2V0
cywgZnJvbSBMaW51eCBtYW4KcGFnZSAoc2VsZWN0KDIpKToKCiJPbiBlcnJvciwgLTEgaXMgcmV0
dXJuZWQsIGFuZCBlcnJubyBpcyAgc2V0ICBhcHByb3ByaWF0ZWx5OyB0aGUgc2V0cwphbmQgdGlt
ZW91dCBiZWNvbWUgdW5kZWZpbmVkLCBzbyBkbyBub3QgcmVseSBvbiB0aGVpciBjb250ZW50cyBh
ZnRlciBhbgplcnJvci4iCgo+IFNhbXVlbAoKRnJlZGlhbm8KCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:22:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:22: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 1U7qtf-0006dz-PO; Tue, 19 Feb 2013 17:22:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U7qte-0006dj-2u
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:22:26 +0000
Received: from [85.158.139.83:52680] by server-8.bemta-5.messagelabs.com id
	23/8C-19075-1D4B3215; Tue, 19 Feb 2013 17:22:25 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361294544!16703154!1
X-Originating-IP: [46.33.159.39]
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14776 invoked from network); 19 Feb 2013 17:22:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:22:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619782"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:22:25 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 19 Feb 2013
	17:22:24 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>
Date: Tue, 19 Feb 2013 17:22:23 +0000
Thread-Topic: [Xen-devel] [PATCH] mini-os: implement poll(2)
Thread-Index: Ac4Oxa5YXA0qC0s7SzuNeq8bEIbXLQ==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163955.GS6098@type.bordeaux.inria.fr>
In-Reply-To: <20130219163955.GS6098@type.bordeaux.inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEzLTAyLTE5IGF0IDE3OjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gQWxzbywgY2hlY2tpbmcgZm9yIGZpbGVzW2ldLnR5cGUgc2hvdWxkIGJlIGRvbmUgb24gZW50
cnkgdG8gdGhlCj4gZnVuY3Rpb24sIG5vdCBhZnRlciBoYXZpbmcgd2FpdGVkIGZvciBzb21lIHRp
bWUgKGFuZCBwZXJoYXBzIG9wZW5lZCBzb21lCj4gZmlsZSBkZXNjcmlwdG9yLCBldGMuKS4gSS5l
LjoKPiAKPiBXZWkgTGl1LCBsZSBUdWUgMTkgRmViIDIwMTMgMTU6NTQ6MTMgKzAwMDAsIGEgw6lj
cml0IDoKPiA+ICsgICAgICAgIC8qIGlnbm9yZSBpbnZhbGlkIGZkcyAqLwo+ID4gKyAgICAgICAg
aWYgKGZkIDwgMCB8fCBmZCA+PSBOT0ZJTEUpCj4gPiArICAgICAgICAgICAgY29udGludWU7Cj4g
Cj4gcmVjb3JkIFBPTExOVkFMIGFzIHNvb24gYXMgaGVyZSwgYW5kIGlnbm9yZSB0aGF0IGZkIGxh
dGVyIG9uLgo+IAoKSWYgeW91IGRldGVjdCB0aGUgaGFuZGxlIGlzIGludmFsaWQgeW91IHNob3Vs
ZCBub3Qgd2FpdCBpbiBzZWxlY3Qgb3Igc2V0CnRoZSB0aW1lb3V0IHRvIDAuIHBvbGwgc2hvdWxk
IHJldHVybiBhcyBzb29uIGF0IGl0IHJlY2VpdmUgYW4gZXZlbnQuIEluCnRoaXMgY2FzZSBnZXR0
aW5nIFBPTExOVkFMIGlzIGFuIGV2ZW50LiBJIGRvbid0IGtub3cgaWYgeW91IGhhdmUgdG8gdGVz
dAphbGwgaGFuZGxlcyBpbiB0aGlzIGNhc2Ugb3IganVzdCByZXR1cm4gdGhlIG51bWJlciBvZiBm
ZHMgdGhhdCBnb3Qgc2V0CnRvIFBPTExOVkFMLgoKPiA+ICsgICAgLyogZG9uJ3QgY2FyZSBhYm91
dCB0aGUgcmV0dXJuIHZhbHVlLCBidXQgd2UgZG8gbmVlZCBlcnJubyAqLwo+ID4gKyAgICBzZWxl
Y3QobWF4X2ZkKzEsICZyZmRzLCAmd2ZkcywgJmVmZHMsIHRpbWVvKTsKPiAKPiBNbW0uIEkgZG9u
J3QgdGhpbmsgd2UgZG9uJ3QgY2FyZSBhYm91dCB0aGUgcmV0dXJuIHZhbHVlOiBpZiBzZWxlY3QK
PiByZXR1cm5zIC0xIHdpdGggRUlOVFIsIHBvbGwgaGFzIHRvIGRvIHRoZSBzYW1lLiBUaGF0J3Mg
aG93ZXZlciBwcm9iYWJseQo+IHRoZSBvbmx5IGNhc2Ugd2UgaGF2ZSB0byB0YWtlIGNhcmUgb2Yu
Cj4gCgppZiB5b3UgZ2V0IGFuIGVycm9yIHlvdSBjYW4ndCBjb25zaWRlciB2YWxpZCB0aGUgc2V0
cywgZnJvbSBMaW51eCBtYW4KcGFnZSAoc2VsZWN0KDIpKToKCiJPbiBlcnJvciwgLTEgaXMgcmV0
dXJuZWQsIGFuZCBlcnJubyBpcyAgc2V0ICBhcHByb3ByaWF0ZWx5OyB0aGUgc2V0cwphbmQgdGlt
ZW91dCBiZWNvbWUgdW5kZWZpbmVkLCBzbyBkbyBub3QgcmVseSBvbiB0aGVpciBjb250ZW50cyBh
ZnRlciBhbgplcnJvci4iCgo+IFNhbXVlbAoKRnJlZGlhbm8KCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:27:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qxy-0006tU-JZ; Tue, 19 Feb 2013 17:26:54 +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 1U7qxw-0006tO-KY
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:26:52 +0000
Received: from [85.158.137.99:10385] by server-11.bemta-3.messagelabs.com id
	3C/A3-10249-BD5B3215; Tue, 19 Feb 2013 17:26:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361294810!17089754!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26325 invoked from network); 19 Feb 2013 17:26:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 17:26:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U7qxp-0000UK-PF; Tue, 19 Feb 2013 17:26:45 +0000
Date: Tue, 19 Feb 2013 17:26:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219172645.GA97631@ocelot.phlegethon.org>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
	<1361294248.1051.136.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361294248.1051.136.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:17 +0000 on 19 Feb (1361294248), Ian Campbell wrote:
> On Tue, 2013-02-19 at 17:11 +0000, Stefano Stabellini wrote:
> > On Tue, 19 Feb 2013, Ian Campbell wrote:
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > +{
> > > +       xen_ulong_t oldval;
> > > +       unsigned int tmp;
> > > +
> > > +       wmb();
> > > +       asm volatile("@ read_evtchn_pending_sel\n"
> >                            ^ do we need this?
> 
> It means that the .s files (if you create them) and such are a bit more
> readable, it's not that uncommon in the ARM inline assembly.

+1.  s/read_evtchn_pending_sel/xchg_xen_ulong/ though.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:27:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qxy-0006tU-JZ; Tue, 19 Feb 2013 17:26:54 +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 1U7qxw-0006tO-KY
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:26:52 +0000
Received: from [85.158.137.99:10385] by server-11.bemta-3.messagelabs.com id
	3C/A3-10249-BD5B3215; Tue, 19 Feb 2013 17:26:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361294810!17089754!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26325 invoked from network); 19 Feb 2013 17:26:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 17:26:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U7qxp-0000UK-PF; Tue, 19 Feb 2013 17:26:45 +0000
Date: Tue, 19 Feb 2013 17:26:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130219172645.GA97631@ocelot.phlegethon.org>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
	<1361294248.1051.136.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361294248.1051.136.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:17 +0000 on 19 Feb (1361294248), Ian Campbell wrote:
> On Tue, 2013-02-19 at 17:11 +0000, Stefano Stabellini wrote:
> > On Tue, 19 Feb 2013, Ian Campbell wrote:
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > +{
> > > +       xen_ulong_t oldval;
> > > +       unsigned int tmp;
> > > +
> > > +       wmb();
> > > +       asm volatile("@ read_evtchn_pending_sel\n"
> >                            ^ do we need this?
> 
> It means that the .s files (if you create them) and such are a bit more
> readable, it's not that uncommon in the ARM inline assembly.

+1.  s/read_evtchn_pending_sel/xchg_xen_ulong/ though.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:27:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qyM-0006vW-3R; Tue, 19 Feb 2013 17:27:18 +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 1U7qyK-0006vF-BF
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:27:17 +0000
Received: from [85.158.137.99:48562] by server-7.bemta-3.messagelabs.com id
	B9/A6-10367-3F5B3215; Tue, 19 Feb 2013 17:27:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361294832!17085186!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4084 invoked from network); 19 Feb 2013 17:27:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:27:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7818419"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:27:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:27:11 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7qyF-0003BL-Ae;
	Tue, 19 Feb 2013 17:27:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 17:27:11 +0000
Message-ID: <1361294831-28552-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX v3] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since V2
  Add comments about the correct bitops to use, and on the ordering/barrier
  requirements on xchg_xen_ulong.
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 +++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
 include/xen/interface/xen.h       |    8 +-
 4 files changed, 94 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..9bb5f50 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ read_evtchn_pending_sel\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..b8d84f5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g test_bit and
+ * friends but not __ffs).
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be /before/ clearing selector
+		 * flag. xchg_xen_ulong must contain an appropriate
+		 * barrier.
+		 */
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = find_first_bit(BM(&words), sizeof(words));
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 19 17:27:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7qyM-0006vW-3R; Tue, 19 Feb 2013 17:27:18 +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 1U7qyK-0006vF-BF
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:27:17 +0000
Received: from [85.158.137.99:48562] by server-7.bemta-3.messagelabs.com id
	B9/A6-10367-3F5B3215; Tue, 19 Feb 2013 17:27:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361294832!17085186!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4084 invoked from network); 19 Feb 2013 17:27:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:27:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7818419"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:27:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:27:11 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7qyF-0003BL-Ae;
	Tue, 19 Feb 2013 17:27:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 17:27:11 +0000
Message-ID: <1361294831-28552-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX v3] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since V2
  Add comments about the correct bitops to use, and on the ordering/barrier
  requirements on xchg_xen_ulong.
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 +++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
 include/xen/interface/xen.h       |    8 +-
 4 files changed, 94 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..9bb5f50 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ read_evtchn_pending_sel\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..b8d84f5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g test_bit and
+ * friends but not __ffs).
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be /before/ clearing selector
+		 * flag. xchg_xen_ulong must contain an appropriate
+		 * barrier.
+		 */
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = find_first_bit(BM(&words), sizeof(words));
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 19 17:28:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:28: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 1U7qzR-00074A-OQ; Tue, 19 Feb 2013 17:28: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 1U7qzQ-00073z-Gy
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:28:24 +0000
Received: from [85.158.143.99:59699] by server-3.bemta-4.messagelabs.com id
	7A/28-08920-736B3215; Tue, 19 Feb 2013 17:28:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361294903!28255415!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16191 invoked from network); 19 Feb 2013 17:28:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:28:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:28: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.297.1;
	Tue, 19 Feb 2013 17:28:23 +0000
Message-ID: <1361294901.1051.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 19 Feb 2013 17:28:21 +0000
In-Reply-To: <20130219172645.GA97631@ocelot.phlegethon.org>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
	<1361294248.1051.136.camel@zakaz.uk.xensource.com>
	<20130219172645.GA97631@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 17:26 +0000, Tim Deegan wrote:
> At 17:17 +0000 on 19 Feb (1361294248), Ian Campbell wrote:
> > On Tue, 2013-02-19 at 17:11 +0000, Stefano Stabellini wrote:
> > > On Tue, 19 Feb 2013, Ian Campbell wrote:
> > > > +/*
> > > > + * We cannot use xchg because it does not support 8-byte
> > > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > > + * platforms which Xen can run on support those instructions.
> > > > + */
> > > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > > +{
> > > > +       xen_ulong_t oldval;
> > > > +       unsigned int tmp;
> > > > +
> > > > +       wmb();
> > > > +       asm volatile("@ read_evtchn_pending_sel\n"
> > >                            ^ do we need this?
> > 
> > It means that the .s files (if you create them) and such are a bit more
> > readable, it's not that uncommon in the ARM inline assembly.
> 
> +1.  s/read_evtchn_pending_sel/xchg_xen_ulong/ though.

Damn, yes. I just sent v3 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 Feb 19 17:28:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:28: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 1U7qzR-00074A-OQ; Tue, 19 Feb 2013 17:28: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 1U7qzQ-00073z-Gy
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:28:24 +0000
Received: from [85.158.143.99:59699] by server-3.bemta-4.messagelabs.com id
	7A/28-08920-736B3215; Tue, 19 Feb 2013 17:28:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361294903!28255415!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16191 invoked from network); 19 Feb 2013 17:28:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:28:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1619905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:28: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.297.1;
	Tue, 19 Feb 2013 17:28:23 +0000
Message-ID: <1361294901.1051.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 19 Feb 2013 17:28:21 +0000
In-Reply-To: <20130219172645.GA97631@ocelot.phlegethon.org>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285357-26696-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191642230.4654@kaball.uk.xensource.com>
	<1361294248.1051.136.camel@zakaz.uk.xensource.com>
	<20130219172645.GA97631@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 17:26 +0000, Tim Deegan wrote:
> At 17:17 +0000 on 19 Feb (1361294248), Ian Campbell wrote:
> > On Tue, 2013-02-19 at 17:11 +0000, Stefano Stabellini wrote:
> > > On Tue, 19 Feb 2013, Ian Campbell wrote:
> > > > +/*
> > > > + * We cannot use xchg because it does not support 8-byte
> > > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > > + * platforms which Xen can run on support those instructions.
> > > > + */
> > > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > > +{
> > > > +       xen_ulong_t oldval;
> > > > +       unsigned int tmp;
> > > > +
> > > > +       wmb();
> > > > +       asm volatile("@ read_evtchn_pending_sel\n"
> > >                            ^ do we need this?
> > 
> > It means that the .s files (if you create them) and such are a bit more
> > readable, it's not that uncommon in the ARM inline assembly.
> 
> +1.  s/read_evtchn_pending_sel/xchg_xen_ulong/ though.

Damn, yes. I just sent v3 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 Feb 19 17:30:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7r1I-0007EW-9A; Tue, 19 Feb 2013 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.Campbell@citrix.com>) id 1U7r1F-0007EJ-V7
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:30:18 +0000
Received: from [85.158.143.99:4354] by server-3.bemta-4.messagelabs.com id
	3F/C9-08920-8A6B3215; Tue, 19 Feb 2013 17:30:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361295012!22120764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9798 invoked from network); 19 Feb 2013 17:30:14 -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;
	19 Feb 2013 17:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7818939"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:29:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:29:11 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7r0B-0003DI-88;
	Tue, 19 Feb 2013 17:29:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 17:29:11 +0000
Message-ID: <1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since V3
  s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
  Add comments about the correct bitops to use, and on the ordering/barrier
  requirements on xchg_xen_ulong.
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 +++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
 include/xen/interface/xen.h       |    8 +-
 4 files changed, 94 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ xchg_xen_ulong\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..b8d84f5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g test_bit and
+ * friends but not __ffs).
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be /before/ clearing selector
+		 * flag. xchg_xen_ulong must contain an appropriate
+		 * barrier.
+		 */
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = find_first_bit(BM(&words), sizeof(words));
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 19 17:30:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17: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 1U7r1I-0007EW-9A; Tue, 19 Feb 2013 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.Campbell@citrix.com>) id 1U7r1F-0007EJ-V7
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:30:18 +0000
Received: from [85.158.143.99:4354] by server-3.bemta-4.messagelabs.com id
	3F/C9-08920-8A6B3215; Tue, 19 Feb 2013 17:30:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361295012!22120764!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9798 invoked from network); 19 Feb 2013 17:30:14 -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;
	19 Feb 2013 17:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7818939"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:29:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:29:11 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U7r0B-0003DI-88;
	Tue, 19 Feb 2013 17:29:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 19 Feb 2013 17:29:11 +0000
Message-ID: <1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since V3
  s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
  Add comments about the correct bitops to use, and on the ordering/barrier
  requirements on xchg_xen_ulong.
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 +++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
 include/xen/interface/xen.h       |    8 +-
 4 files changed, 94 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ xchg_xen_ulong\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..b8d84f5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
 };
 
 /*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
  * Packed IRQ information:
  * type - enum xen_irq_type
  * event channel - irq->event channel mapping
@@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g test_bit and
+ * friends but not __ffs).
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be /before/ clearing selector
+		 * flag. xchg_xen_ulong must contain an appropriate
+		 * barrier.
+		 */
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = find_first_bit(BM(&words), sizeof(words));
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 19 17:43:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:43: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 1U7rDu-0007Za-KD; Tue, 19 Feb 2013 17:43: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 1U7rDt-0007ZV-30
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:43:21 +0000
Received: from [85.158.137.99:46998] by server-11.bemta-3.messagelabs.com id
	4E/CC-10249-8B9B3215; Tue, 19 Feb 2013 17:43:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361295797!12017455!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12216 invoked from network); 19 Feb 2013 17:43:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8229147"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:42:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:42:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rDR-0003T5-1z;
	Tue, 19 Feb 2013 17:42:53 +0000
Date: Tue, 19 Feb 2013 17:42:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279850-8246-4-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-4-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv4 3/5] exec: Introduce helper to set dirty
	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 Tue, 19 Feb 2013, Alex Bligh wrote:
> This new helper/hook is used in the next patch to add an extra call in a single
> place.
> 
> Backport of 51d7a9eb2b64e787c90bea1027308087eac22065
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>
> ---
>  exec.c |   45 +++++++++++++++++----------------------------
>  1 files changed, 17 insertions(+), 28 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 6c206ff..511777b 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
>  }
>  
>  #else
> +
> +static void invalidate_and_set_dirty(target_phys_addr_t addr,
> +                                     target_phys_addr_t length)
> +{
> +    if (!cpu_physical_memory_is_dirty(addr)) {
> +        /* invalidate code */
> +        tb_invalidate_phys_page_range(addr, addr + length, 0);
> +        /* set dirty bit */
> +        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
> +    }
> +}
> +
>  void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>                              int len, int is_write)
>  {
> @@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>                  /* RAM case */
>                  ptr = qemu_get_ram_ptr(addr1);
>                  memcpy(ptr, buf, l);
> -                if (!cpu_physical_memory_is_dirty(addr1)) {
> -                    /* invalidate code */
> -                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
> -                    /* set dirty bit */
> -                    cpu_physical_memory_set_dirty_flags(
> -                        addr1, (0xff & ~CODE_DIRTY_FLAG));
> -                }
> +                invalidate_and_set_dirty(addr1, l);
>                  qemu_put_ram_ptr(ptr);
>              }
>          } else {
> @@ -4081,6 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
>              /* ROM/RAM case */
>              ptr = qemu_get_ram_ptr(addr1);
>              memcpy(ptr, buf, l);
> +	    invalidate_and_set_dirty(addr1, l);
>              qemu_put_ram_ptr(ptr);
>          }
>          len -= l;

In QEMU the code style is spaces for indentation.
Moreover the right way of doing the backport here would be firstly to
backport 0b57e287, then 51d7a9eb2b64e787c90bea1027308087eac22065 should
just apply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:43:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:43: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 1U7rDu-0007Za-KD; Tue, 19 Feb 2013 17:43: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 1U7rDt-0007ZV-30
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:43:21 +0000
Received: from [85.158.137.99:46998] by server-11.bemta-3.messagelabs.com id
	4E/CC-10249-8B9B3215; Tue, 19 Feb 2013 17:43:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361295797!12017455!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12216 invoked from network); 19 Feb 2013 17:43:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8229147"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 17:42:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 12:42:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rDR-0003T5-1z;
	Tue, 19 Feb 2013 17:42:53 +0000
Date: Tue, 19 Feb 2013 17:42:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279850-8246-4-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-4-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv4 3/5] exec: Introduce helper to set dirty
	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 Tue, 19 Feb 2013, Alex Bligh wrote:
> This new helper/hook is used in the next patch to add an extra call in a single
> place.
> 
> Backport of 51d7a9eb2b64e787c90bea1027308087eac22065
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>
> ---
>  exec.c |   45 +++++++++++++++++----------------------------
>  1 files changed, 17 insertions(+), 28 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 6c206ff..511777b 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
>  }
>  
>  #else
> +
> +static void invalidate_and_set_dirty(target_phys_addr_t addr,
> +                                     target_phys_addr_t length)
> +{
> +    if (!cpu_physical_memory_is_dirty(addr)) {
> +        /* invalidate code */
> +        tb_invalidate_phys_page_range(addr, addr + length, 0);
> +        /* set dirty bit */
> +        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
> +    }
> +}
> +
>  void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>                              int len, int is_write)
>  {
> @@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>                  /* RAM case */
>                  ptr = qemu_get_ram_ptr(addr1);
>                  memcpy(ptr, buf, l);
> -                if (!cpu_physical_memory_is_dirty(addr1)) {
> -                    /* invalidate code */
> -                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
> -                    /* set dirty bit */
> -                    cpu_physical_memory_set_dirty_flags(
> -                        addr1, (0xff & ~CODE_DIRTY_FLAG));
> -                }
> +                invalidate_and_set_dirty(addr1, l);
>                  qemu_put_ram_ptr(ptr);
>              }
>          } else {
> @@ -4081,6 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
>              /* ROM/RAM case */
>              ptr = qemu_get_ram_ptr(addr1);
>              memcpy(ptr, buf, l);
> +	    invalidate_and_set_dirty(addr1, l);
>              qemu_put_ram_ptr(ptr);
>          }
>          len -= l;

In QEMU the code style is spaces for indentation.
Moreover the right way of doing the backport here would be firstly to
backport 0b57e287, then 51d7a9eb2b64e787c90bea1027308087eac22065 should
just apply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 17:58:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:58: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 1U7rSe-0007p3-5z; Tue, 19 Feb 2013 17:58:36 +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 1U7rSd-0007oy-5v
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:58:35 +0000
Received: from [85.158.137.99:51489] by server-10.bemta-3.messagelabs.com id
	17/5C-10609-A4DB3215; Tue, 19 Feb 2013 17:58:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361296713!14724234!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24269 invoked from network); 19 Feb 2013 17:58:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:58:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1621103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:58: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.297.1; Tue, 19 Feb 2013 17:58:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7rSb-0004N5-FM; Tue, 19 Feb 2013 17:58:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7rSb-00083x-Bq;
	Tue, 19 Feb 2013 17:58:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.48457.150475.736921@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 17:58:33 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b096442271cf6a0d1251.1361218171@probook.site>
References: <b096442271cf6a0d1251.1361218171@probook.site>
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] tools/libxc: perpare xc_domain_save
	for	upcoming changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: perpare xc_domain_save for upcoming changes"):
> tools/libxc: perpare xc_domain_save for upcoming changes
> 
> An upcoming patch will pass min_remaining to xc_domain_save.
> Because such a will be an API change, take the opportunity to change the
> API so that it will be easier to pass more options in the future.

I'm not sure why changing the large number of arguments to
xc_domain_save to a struct is an improvement, even given that you are
proposing to add one.  Can you explain further ?

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 Feb 19 17:58:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 17:58: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 1U7rSe-0007p3-5z; Tue, 19 Feb 2013 17:58:36 +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 1U7rSd-0007oy-5v
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 17:58:35 +0000
Received: from [85.158.137.99:51489] by server-10.bemta-3.messagelabs.com id
	17/5C-10609-A4DB3215; Tue, 19 Feb 2013 17:58:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361296713!14724234!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24269 invoked from network); 19 Feb 2013 17:58:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 17:58:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1621103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 17:58: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.297.1; Tue, 19 Feb 2013 17:58:33 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7rSb-0004N5-FM; Tue, 19 Feb 2013 17:58:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7rSb-00083x-Bq;
	Tue, 19 Feb 2013 17:58:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.48457.150475.736921@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 17:58:33 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b096442271cf6a0d1251.1361218171@probook.site>
References: <b096442271cf6a0d1251.1361218171@probook.site>
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] tools/libxc: perpare xc_domain_save
	for	upcoming changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: perpare xc_domain_save for upcoming changes"):
> tools/libxc: perpare xc_domain_save for upcoming changes
> 
> An upcoming patch will pass min_remaining to xc_domain_save.
> Because such a will be an API change, take the opportunity to change the
> API so that it will be easier to pass more options in the future.

I'm not sure why changing the large number of arguments to
xc_domain_save to a struct is an improvement, even given that you are
proposing to add one.  Can you explain further ?

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 Feb 19 18:03:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:03: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 1U7rX9-00084B-Uc; Tue, 19 Feb 2013 18:03:15 +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 1U7rX8-000845-1g
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:03:14 +0000
Received: from [193.109.254.147:60863] by server-5.bemta-14.messagelabs.com id
	18/86-21539-16EB3215; Tue, 19 Feb 2013 18:03:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361296987!2141721!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31605 invoked from network); 19 Feb 2013 18:03:09 -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;
	19 Feb 2013 18:03:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8234446"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:03:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:03:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rX0-0003lw-U1;
	Tue, 19 Feb 2013 18:03:06 +0000
Date: Tue, 19 Feb 2013 18:03:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279850-8246-5-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_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

On Tue, 19 Feb 2013, Alex Bligh wrote:
> This patch add some calls to xen_modified_memory to notify Xen about dirtybits
> during migration.
> 
> Backport of e226939de5814527a21396903b08c3d0ed989558
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>
>
>  exec.c   |    4 ++++
>  memory.c |    4 ++++
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 511777b..401f9bc 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
>      memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
>             0xff, size >> TARGET_PAGE_BITS);
>  
> +    if (xen_enabled())
> +        xen_modified_memory(new_block->offset, size);
> +

e226939de5814527a21396903b08c3d0ed989558 adds two calls to
xen_modified_memory, one in cpu_physical_memory_set_dirty_range, the
other in invalidate_and_set_dirty.

Where does this one come from?

If something is missing you need to backport that patch too, rather than
trying to adapt this patch.
In this case I believe you need to backport
1720aeee72888f80b974c33b6eb39922a0bea992.


>      if (kvm_enabled())
>          kvm_setup_guest_memory(new_block->host, size);
>  
> @@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
>          /* set dirty bit */
>          cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
>      }
> +    xen_modified_memory(addr, length);
>  }
>  
>  void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> diff --git a/memory.c b/memory.c
> index 7c20a07..6e0c596 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -16,6 +16,7 @@
>  #include "ioport.h"
>  #include "bitops.h"
>  #include "kvm.h"
> +#include "hw/xen.h"
>  #include <assert.h>
>  
>  unsigned memory_region_transaction_depth = 0;
> @@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
>  void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
>  {
>      assert(mr->terminates);
> +    if (xen_enabled())
> +        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
> +                            TARGET_PAGE_SIZE);
>      return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
>  }
>  
> -- 
> 1.7.4.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:03:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:03: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 1U7rX9-00084B-Uc; Tue, 19 Feb 2013 18:03:15 +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 1U7rX8-000845-1g
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:03:14 +0000
Received: from [193.109.254.147:60863] by server-5.bemta-14.messagelabs.com id
	18/86-21539-16EB3215; Tue, 19 Feb 2013 18:03:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361296987!2141721!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31605 invoked from network); 19 Feb 2013 18:03:09 -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;
	19 Feb 2013 18:03:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8234446"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:03:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:03:07 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rX0-0003lw-U1;
	Tue, 19 Feb 2013 18:03:06 +0000
Date: Tue, 19 Feb 2013 18:03:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279850-8246-5-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_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

On Tue, 19 Feb 2013, Alex Bligh wrote:
> This patch add some calls to xen_modified_memory to notify Xen about dirtybits
> during migration.
> 
> Backport of e226939de5814527a21396903b08c3d0ed989558
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>
>
>  exec.c   |    4 ++++
>  memory.c |    4 ++++
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 511777b..401f9bc 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
>      memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
>             0xff, size >> TARGET_PAGE_BITS);
>  
> +    if (xen_enabled())
> +        xen_modified_memory(new_block->offset, size);
> +

e226939de5814527a21396903b08c3d0ed989558 adds two calls to
xen_modified_memory, one in cpu_physical_memory_set_dirty_range, the
other in invalidate_and_set_dirty.

Where does this one come from?

If something is missing you need to backport that patch too, rather than
trying to adapt this patch.
In this case I believe you need to backport
1720aeee72888f80b974c33b6eb39922a0bea992.


>      if (kvm_enabled())
>          kvm_setup_guest_memory(new_block->host, size);
>  
> @@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
>          /* set dirty bit */
>          cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
>      }
> +    xen_modified_memory(addr, length);
>  }
>  
>  void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> diff --git a/memory.c b/memory.c
> index 7c20a07..6e0c596 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -16,6 +16,7 @@
>  #include "ioport.h"
>  #include "bitops.h"
>  #include "kvm.h"
> +#include "hw/xen.h"
>  #include <assert.h>
>  
>  unsigned memory_region_transaction_depth = 0;
> @@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
>  void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
>  {
>      assert(mr->terminates);
> +    if (xen_enabled())
> +        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
> +                            TARGET_PAGE_SIZE);
>      return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
>  }
>  
> -- 
> 1.7.4.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:06:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:06: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 1U7rZj-0008D0-MB; Tue, 19 Feb 2013 18:05:55 +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 1U7rZi-0008Cq-CS
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:05:54 +0000
Received: from [85.158.139.211:30195] by server-9.bemta-5.messagelabs.com id
	05/18-24440-10FB3215; Tue, 19 Feb 2013 18:05:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361297150!18273583!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23862 invoked from network); 19 Feb 2013 18:05:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:05:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8235391"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:05:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:05:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rZd-0003oZ-8B;
	Tue, 19 Feb 2013 18:05:49 +0000
Date: Tue, 19 Feb 2013 18:05:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279850-8246-6-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-6-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Alex Bligh wrote:
> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
> video ram. This case happens during migration.
> 
> Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>
> ---
>  xen-all.c |   20 ++++++++++++++++++--
>  1 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 121289d..dbd759c 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>      rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
>                                   start_addr >> TARGET_PAGE_BITS, npages,
>                                   bitmap);
> -    if (rc) {
> +    if (rc < 0) {
> +        if (rc != -ENODATA) {
> +            ram_addr_t addr, end;
> +
> +            xen_modified_memory(start_addr, size);
> +            
> +            end = TARGET_PAGE_ALIGN(start_addr + size);
> +            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
> +                cpu_physical_memory_set_dirty(addr);
> +            }
> +
> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> +                    ", 0x" TARGET_FMT_plx "): %s\n",
> +                    start_addr, start_addr + size, strerror(-rc));
> +        }
>          return rc;
>      }

8aba7dc02d5660df7e7d8651304b3079908358be only adds a simple call to
xen_modified_memory if rc != ENODATA.
Where does the rest of the code you are adding comes from?


> @@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>          while (map != 0) {
>              j = ffsl(map) - 1;
>              map &= ~(1ul << j);
> -            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
> +            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
> +            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
> +            cpu_physical_memory_set_dirty(todirty);
>          };
>      }

where does this chuck come from?
Wouldn't it make more sense to add a call to xen_modified_memory from
cpu_physical_memory_set_dirty?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:06:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:06: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 1U7rZj-0008D0-MB; Tue, 19 Feb 2013 18:05:55 +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 1U7rZi-0008Cq-CS
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:05:54 +0000
Received: from [85.158.139.211:30195] by server-9.bemta-5.messagelabs.com id
	05/18-24440-10FB3215; Tue, 19 Feb 2013 18:05:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361297150!18273583!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23862 invoked from network); 19 Feb 2013 18:05:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:05:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8235391"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:05:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:05:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rZd-0003oZ-8B;
	Tue, 19 Feb 2013 18:05:49 +0000
Date: Tue, 19 Feb 2013 18:05:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361279850-8246-6-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-6-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Alex Bligh wrote:
> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
> video ram. This case happens during migration.
> 
> Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
> 
> Signed-off-by: Alex Bligh <alex@alex.org.uk>
> ---
>  xen-all.c |   20 ++++++++++++++++++--
>  1 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 121289d..dbd759c 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>      rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
>                                   start_addr >> TARGET_PAGE_BITS, npages,
>                                   bitmap);
> -    if (rc) {
> +    if (rc < 0) {
> +        if (rc != -ENODATA) {
> +            ram_addr_t addr, end;
> +
> +            xen_modified_memory(start_addr, size);
> +            
> +            end = TARGET_PAGE_ALIGN(start_addr + size);
> +            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
> +                cpu_physical_memory_set_dirty(addr);
> +            }
> +
> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> +                    ", 0x" TARGET_FMT_plx "): %s\n",
> +                    start_addr, start_addr + size, strerror(-rc));
> +        }
>          return rc;
>      }

8aba7dc02d5660df7e7d8651304b3079908358be only adds a simple call to
xen_modified_memory if rc != ENODATA.
Where does the rest of the code you are adding comes from?


> @@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>          while (map != 0) {
>              j = ffsl(map) - 1;
>              map &= ~(1ul << j);
> -            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
> +            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
> +            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
> +            cpu_physical_memory_set_dirty(todirty);
>          };
>      }

where does this chuck come from?
Wouldn't it make more sense to add a call to xen_modified_memory from
cpu_physical_memory_set_dirty?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:06:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7ra4-0008Ev-37; Tue, 19 Feb 2013 18:06:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U7ra3-0008Ej-2E
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 18:06:15 +0000
Received: from [85.158.137.99:27285] by server-9.bemta-3.messagelabs.com id
	58/F7-09484-61FB3215; Tue, 19 Feb 2013 18:06:14 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361297171!16194655!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16856 invoked from network); 19 Feb 2013 18:06:12 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-11.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 18:06:12 -0000
Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 650AC58142F;
	Tue, 19 Feb 2013 10:06:14 -0800 (PST)
Date: Tue, 19 Feb 2013 13:06:07 -0500 (EST)
Message-Id: <20130219.130607.100487415380997622.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1361264324.1051.61.camel@zakaz.uk.xensource.com>
References: <20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
	<1361264324.1051.61.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(shards.monkeyblade.net [0.0.0.0]);
	Tue, 19 Feb 2013 10:06:15 -0800 (PST)
Cc: netdev@vger.kernel.org, drjones@redhat.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Date: Tue, 19 Feb 2013 08:58:44 +0000

> On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
>> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
>> > From: Andrew Jones <drjones@redhat.com>
>> > Date: Mon, 18 Feb 2013 21:29:20 +0100
>> > 
>> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> >> have one reference to the vif at this time, then the xenvif_put
>> >> in netbk_fatal_tx_err is one too many.
>> >> 
>> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
>> > 
>> > Applied.
>> 
>> But this is wrong from all we can tell,
> 
> Yes, please can this be reverted.

Done and I've annotated the revert commit message with as much
information as possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:06:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7ra4-0008Ev-37; Tue, 19 Feb 2013 18:06:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1U7ra3-0008Ej-2E
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 18:06:15 +0000
Received: from [85.158.137.99:27285] by server-9.bemta-3.messagelabs.com id
	58/F7-09484-61FB3215; Tue, 19 Feb 2013 18:06:14 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361297171!16194655!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16856 invoked from network); 19 Feb 2013 18:06:12 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-11.tower-217.messagelabs.com with SMTP;
	19 Feb 2013 18:06:12 -0000
Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205])
	(Authenticated sender: davem-davemloft)
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 650AC58142F;
	Tue, 19 Feb 2013 10:06:14 -0800 (PST)
Date: Tue, 19 Feb 2013 13:06:07 -0500 (EST)
Message-Id: <20130219.130607.100487415380997622.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1361264324.1051.61.camel@zakaz.uk.xensource.com>
References: <20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
	<1361264324.1051.61.camel@zakaz.uk.xensource.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
	(shards.monkeyblade.net [0.0.0.0]);
	Tue, 19 Feb 2013 10:06:15 -0800 (PST)
Cc: netdev@vger.kernel.org, drjones@redhat.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Date: Tue, 19 Feb 2013 08:58:44 +0000

> On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
>> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
>> > From: Andrew Jones <drjones@redhat.com>
>> > Date: Mon, 18 Feb 2013 21:29:20 +0100
>> > 
>> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> >> have one reference to the vif at this time, then the xenvif_put
>> >> in netbk_fatal_tx_err is one too many.
>> >> 
>> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
>> > 
>> > Applied.
>> 
>> But this is wrong from all we can tell,
> 
> Yes, please can this be reverted.

Done and I've annotated the revert commit message with as much
information as possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:09:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:09: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 1U7rce-0008Ry-Rb; Tue, 19 Feb 2013 18:08:56 +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 1U7rcd-0008Rb-JD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:08:55 +0000
Received: from [85.158.139.211:59784] by server-5.bemta-5.messagelabs.com id
	6E/BB-11945-6BFB3215; Tue, 19 Feb 2013 18:08:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361297332!18298215!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28328 invoked from network); 19 Feb 2013 18:08:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:08:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8236287"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:08:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:08:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7rcZ-0003rR-Si;
	Tue, 19 Feb 2013 18:08:51 +0000
Message-ID: <1361297331.2937.30.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 18:08:51 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163955.GS6098@type.bordeaux.inria.fr>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEzLTAyLTE5IGF0IDE3OjIyICswMDAwLCBGcmVkaWFubyBaaWdsaW8gd3JvdGU6
Cj4gT24gVHVlLCAyMDEzLTAyLTE5IGF0IDE3OjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3Jv
dGU6Cj4gPiBBbHNvLCBjaGVja2luZyBmb3IgZmlsZXNbaV0udHlwZSBzaG91bGQgYmUgZG9uZSBv
biBlbnRyeSB0byB0aGUKPiA+IGZ1bmN0aW9uLCBub3QgYWZ0ZXIgaGF2aW5nIHdhaXRlZCBmb3Ig
c29tZSB0aW1lIChhbmQgcGVyaGFwcyBvcGVuZWQgc29tZQo+ID4gZmlsZSBkZXNjcmlwdG9yLCBl
dGMuKS4gSS5lLjoKPiA+IAo+ID4gV2VpIExpdSwgbGUgVHVlIDE5IEZlYiAyMDEzIDE1OjU0OjEz
ICswMDAwLCBhIMOpY3JpdCA6Cj4gPiA+ICsgICAgICAgIC8qIGlnbm9yZSBpbnZhbGlkIGZkcyAq
Lwo+ID4gPiArICAgICAgICBpZiAoZmQgPCAwIHx8IGZkID49IE5PRklMRSkKPiA+ID4gKyAgICAg
ICAgICAgIGNvbnRpbnVlOwo+ID4gCj4gPiByZWNvcmQgUE9MTE5WQUwgYXMgc29vbiBhcyBoZXJl
LCBhbmQgaWdub3JlIHRoYXQgZmQgbGF0ZXIgb24uCj4gPiAKPiAKPiBJZiB5b3UgZGV0ZWN0IHRo
ZSBoYW5kbGUgaXMgaW52YWxpZCB5b3Ugc2hvdWxkIG5vdCB3YWl0IGluIHNlbGVjdCBvciBzZXQK
PiB0aGUgdGltZW91dCB0byAwLiBwb2xsIHNob3VsZCByZXR1cm4gYXMgc29vbiBhdCBpdCByZWNl
aXZlIGFuIGV2ZW50LiBJbgo+IHRoaXMgY2FzZSBnZXR0aW5nIFBPTExOVkFMIGlzIGFuIGV2ZW50
LiBJIGRvbid0IGtub3cgaWYgeW91IGhhdmUgdG8gdGVzdAo+IGFsbCBoYW5kbGVzIGluIHRoaXMg
Y2FzZSBvciBqdXN0IHJldHVybiB0aGUgbnVtYmVyIG9mIGZkcyB0aGF0IGdvdCBzZXQKPiB0byBQ
T0xMTlZBTC4KPiAKCkluIExpbnV4J3MgZG9fcG9sbCgpIGltcGxlbWVudGF0aW9uLCB0aGUgd2hv
bGUgcG9sbCBhcnJheSBpcyBzY2FubmVkLApldmVuIGlmIHNvbWUgZmRzIGluIHRoZSBtaWRkbGUg
b2YgdGhlIGxvb3AgYXJlIG5vdCB2YWxpZC4KCldlaS4KCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:09:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:09: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 1U7rce-0008Ry-Rb; Tue, 19 Feb 2013 18:08:56 +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 1U7rcd-0008Rb-JD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:08:55 +0000
Received: from [85.158.139.211:59784] by server-5.bemta-5.messagelabs.com id
	6E/BB-11945-6BFB3215; Tue, 19 Feb 2013 18:08:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361297332!18298215!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28328 invoked from network); 19 Feb 2013 18:08:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:08:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="8236287"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:08:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:08:52 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7rcZ-0003rR-Si;
	Tue, 19 Feb 2013 18:08:51 +0000
Message-ID: <1361297331.2937.30.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Tue, 19 Feb 2013 18:08:51 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163955.GS6098@type.bordeaux.inria.fr>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEzLTAyLTE5IGF0IDE3OjIyICswMDAwLCBGcmVkaWFubyBaaWdsaW8gd3JvdGU6
Cj4gT24gVHVlLCAyMDEzLTAyLTE5IGF0IDE3OjM5ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3Jv
dGU6Cj4gPiBBbHNvLCBjaGVja2luZyBmb3IgZmlsZXNbaV0udHlwZSBzaG91bGQgYmUgZG9uZSBv
biBlbnRyeSB0byB0aGUKPiA+IGZ1bmN0aW9uLCBub3QgYWZ0ZXIgaGF2aW5nIHdhaXRlZCBmb3Ig
c29tZSB0aW1lIChhbmQgcGVyaGFwcyBvcGVuZWQgc29tZQo+ID4gZmlsZSBkZXNjcmlwdG9yLCBl
dGMuKS4gSS5lLjoKPiA+IAo+ID4gV2VpIExpdSwgbGUgVHVlIDE5IEZlYiAyMDEzIDE1OjU0OjEz
ICswMDAwLCBhIMOpY3JpdCA6Cj4gPiA+ICsgICAgICAgIC8qIGlnbm9yZSBpbnZhbGlkIGZkcyAq
Lwo+ID4gPiArICAgICAgICBpZiAoZmQgPCAwIHx8IGZkID49IE5PRklMRSkKPiA+ID4gKyAgICAg
ICAgICAgIGNvbnRpbnVlOwo+ID4gCj4gPiByZWNvcmQgUE9MTE5WQUwgYXMgc29vbiBhcyBoZXJl
LCBhbmQgaWdub3JlIHRoYXQgZmQgbGF0ZXIgb24uCj4gPiAKPiAKPiBJZiB5b3UgZGV0ZWN0IHRo
ZSBoYW5kbGUgaXMgaW52YWxpZCB5b3Ugc2hvdWxkIG5vdCB3YWl0IGluIHNlbGVjdCBvciBzZXQK
PiB0aGUgdGltZW91dCB0byAwLiBwb2xsIHNob3VsZCByZXR1cm4gYXMgc29vbiBhdCBpdCByZWNl
aXZlIGFuIGV2ZW50LiBJbgo+IHRoaXMgY2FzZSBnZXR0aW5nIFBPTExOVkFMIGlzIGFuIGV2ZW50
LiBJIGRvbid0IGtub3cgaWYgeW91IGhhdmUgdG8gdGVzdAo+IGFsbCBoYW5kbGVzIGluIHRoaXMg
Y2FzZSBvciBqdXN0IHJldHVybiB0aGUgbnVtYmVyIG9mIGZkcyB0aGF0IGdvdCBzZXQKPiB0byBQ
T0xMTlZBTC4KPiAKCkluIExpbnV4J3MgZG9fcG9sbCgpIGltcGxlbWVudGF0aW9uLCB0aGUgd2hv
bGUgcG9sbCBhcnJheSBpcyBzY2FubmVkLApldmVuIGlmIHNvbWUgZmRzIGluIHRoZSBtaWRkbGUg
b2YgdGhlIGxvb3AgYXJlIG5vdCB2YWxpZC4KCldlaS4KCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:13:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:13: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 1U7rgN-0000K1-Hy; Tue, 19 Feb 2013 18:12:47 +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 1U7rgM-0000Jr-1t
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:12:46 +0000
Received: from [85.158.138.51:35191] by server-15.bemta-3.messagelabs.com id
	DB/97-25405-890C3215; Tue, 19 Feb 2013 18:12:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361297558!26487834!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18766 invoked from network); 19 Feb 2013 18:12:40 -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;
	19 Feb 2013 18:12:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7830505"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:12:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:12:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rgD-0003uu-E3;
	Tue, 19 Feb 2013 18:12:37 +0000
Date: Tue, 19 Feb 2013 18:12:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...

still doesn't apply to 3.8


>         do {
> -               unsigned long pending_words;
> +               xen_ulong_t pending_words;
> 
>                 vcpu_info->evtchn_upcall_pending = 0;
> 
>                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
>                         goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -               /* Clear master flag /before/ clearing selector flag. */
> -               wmb();
> -#endif
> -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +               /*
> +                * Master flag must be /before/ clearing selector
> +                * flag. xchg_xen_ulong must contain an appropriate
> +                * barrier.
> +                */

Master flag must be *cleared* ...

> +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
>                 start_word_idx = __this_cpu_read(current_word_idx);
>                 start_bit_idx = __this_cpu_read(current_bit_idx);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:13:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:13: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 1U7rgN-0000K1-Hy; Tue, 19 Feb 2013 18:12:47 +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 1U7rgM-0000Jr-1t
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:12:46 +0000
Received: from [85.158.138.51:35191] by server-15.bemta-3.messagelabs.com id
	DB/97-25405-890C3215; Tue, 19 Feb 2013 18:12:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361297558!26487834!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMyMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18766 invoked from network); 19 Feb 2013 18:12:40 -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;
	19 Feb 2013 18:12:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="7830505"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:12:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:12:37 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U7rgD-0003uu-E3;
	Tue, 19 Feb 2013 18:12:37 +0000
Date: Tue, 19 Feb 2013 18:12:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...

still doesn't apply to 3.8


>         do {
> -               unsigned long pending_words;
> +               xen_ulong_t pending_words;
> 
>                 vcpu_info->evtchn_upcall_pending = 0;
> 
>                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
>                         goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -               /* Clear master flag /before/ clearing selector flag. */
> -               wmb();
> -#endif
> -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +               /*
> +                * Master flag must be /before/ clearing selector
> +                * flag. xchg_xen_ulong must contain an appropriate
> +                * barrier.
> +                */

Master flag must be *cleared* ...

> +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
>                 start_word_idx = __this_cpu_read(current_word_idx);
>                 start_bit_idx = __this_cpu_read(current_bit_idx);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:22:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:22: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 1U7rpO-0000YH-Kb; Tue, 19 Feb 2013 18: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.Jackson@eu.citrix.com>) id 1U7rpJ-0000YC-Rp
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:22:05 +0000
Received: from [193.109.254.147:26329] by server-6.bemta-14.messagelabs.com id
	3A/E7-12010-9C2C3215; Tue, 19 Feb 2013 18:22:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361298119!8604483!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31332 invoked from network); 19 Feb 2013 18:21:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1621880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 18:22: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.297.1; Tue, 19 Feb 2013 18:21:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7rpH-0004UE-1N; Tue, 19 Feb 2013 18:21:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7rpG-00085f-UI;
	Tue, 19 Feb 2013 18:21:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.49862.534182.856929@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 18:21:58 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0f9c7503650fa1b1103b.1360862057@probook.site>
References: <0f9c7503650fa1b1103b.1360862057@probook.site>
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] tools/xend: Only add cpuid and cpuid_check
	to	sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xend: Only add cpuid and cpuid_check to sexpr once"):
> tools/xend: Only add cpuid and cpuid_check to sexpr once
> 
> When converting a XendConfig object to sexpr, cpuid and cpuid_check
> were being emitted twice in the resulting sexpr.  The first conversion
> writes incorrect sexpr, causing parsing of the sexpr to fail when xend
> is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
> are read and parsed.
> 
> This patch skips the first conversion, and uses only the custom
> cpuid{_check} conversion methods called later.  It is not pretty, but
> is the least invasive fix in this complex code.

We do intend to fix bugs in xend, but I'm worried that this change
might break something.  I don't know the code at all so forgive me if
I'm asking stupid questions, but why does the first conversion emit an
invalid sexpr ?

>              for name, typ in XENAPI_CFG_TYPES.items():
>                  if name in self and self[name] not in (None, []):
> +                    # Skip cpuid and cpuid_check.  Custom conversion
> +                    # methods for these are called below.
> +                    if name in ("cpuid", "cpuid_check"):
> +                        continue

I do agree that this looks plausible because as your comment says, the
cpuid and cpuid_check values are converted explicitly later.

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 Feb 19 18:22:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:22: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 1U7rpO-0000YH-Kb; Tue, 19 Feb 2013 18: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.Jackson@eu.citrix.com>) id 1U7rpJ-0000YC-Rp
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:22:05 +0000
Received: from [193.109.254.147:26329] by server-6.bemta-14.messagelabs.com id
	3A/E7-12010-9C2C3215; Tue, 19 Feb 2013 18:22:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361298119!8604483!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31332 invoked from network); 19 Feb 2013 18:21:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1621880"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 18:22: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.297.1; Tue, 19 Feb 2013 18:21:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7rpH-0004UE-1N; Tue, 19 Feb 2013 18:21:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7rpG-00085f-UI;
	Tue, 19 Feb 2013 18:21:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.49862.534182.856929@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 18:21:58 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0f9c7503650fa1b1103b.1360862057@probook.site>
References: <0f9c7503650fa1b1103b.1360862057@probook.site>
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] tools/xend: Only add cpuid and cpuid_check
	to	sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xend: Only add cpuid and cpuid_check to sexpr once"):
> tools/xend: Only add cpuid and cpuid_check to sexpr once
> 
> When converting a XendConfig object to sexpr, cpuid and cpuid_check
> were being emitted twice in the resulting sexpr.  The first conversion
> writes incorrect sexpr, causing parsing of the sexpr to fail when xend
> is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
> are read and parsed.
> 
> This patch skips the first conversion, and uses only the custom
> cpuid{_check} conversion methods called later.  It is not pretty, but
> is the least invasive fix in this complex code.

We do intend to fix bugs in xend, but I'm worried that this change
might break something.  I don't know the code at all so forgive me if
I'm asking stupid questions, but why does the first conversion emit an
invalid sexpr ?

>              for name, typ in XENAPI_CFG_TYPES.items():
>                  if name in self and self[name] not in (None, []):
> +                    # Skip cpuid and cpuid_check.  Custom conversion
> +                    # methods for these are called below.
> +                    if name in ("cpuid", "cpuid_check"):
> +                        continue

I do agree that this looks plausible because as your comment says, the
cpuid and cpuid_check values are converted explicitly later.

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 Feb 19 18:26:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:26: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 1U7rtM-0000iX-Gi; Tue, 19 Feb 2013 18:26: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 1U7rtK-0000iJ-Hb
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 18:26:10 +0000
Received: from [85.158.143.35:62041] by server-1.bemta-4.messagelabs.com id
	AF/13-08839-1C3C3215; Tue, 19 Feb 2013 18:26:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1361298368!3916082!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13680 invoked from network); 19 Feb 2013 18:26:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1622094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 18:26: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.297.1; Tue, 19 Feb 2013 18:26:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7rtH-0004Vr-QH; Tue, 19 Feb 2013 18:26:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7rtH-00086D-Lb;
	Tue, 19 Feb 2013 18:26:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.50106.583404.696259@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 18:26:02 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361020829.18663.9.camel@dagon.hellion.org.uk>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
	<511F7E25.7040307@heliman.it>
	<1361020829.18663.9.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface support for upstream qemu"):
> On Sat, 2013-02-16 at 12:40 +0000, Fabio Fantoni wrote:
> > I do not see this patch in the staging branch, there are problems of 
> > code style?
> 
> I think I just managed to miss actually applying this one in among all
> the other stuff I applied on Friday. I'll take another look next week.

I see this has an ack from Stefano, but I have made some comments on
the coding style so I think we want a resend with those changes.

Fabio, would you please transfer the ack from Stefano's email into
your resend ?

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 Feb 19 18:26:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:26: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 1U7rtM-0000iX-Gi; Tue, 19 Feb 2013 18:26: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 1U7rtK-0000iJ-Hb
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 18:26:10 +0000
Received: from [85.158.143.35:62041] by server-1.bemta-4.messagelabs.com id
	AF/13-08839-1C3C3215; Tue, 19 Feb 2013 18:26:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1361298368!3916082!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13680 invoked from network); 19 Feb 2013 18:26:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; 
   d="scan'208";a="1622094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 18:26: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.297.1; Tue, 19 Feb 2013 18:26:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7rtH-0004Vr-QH; Tue, 19 Feb 2013 18:26:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7rtH-00086D-Lb;
	Tue, 19 Feb 2013 18:26:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.50106.583404.696259@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 18:26:02 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361020829.18663.9.camel@dagon.hellion.org.uk>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
	<511F7E25.7040307@heliman.it>
	<1361020829.18663.9.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface
 support for upstream 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface support for upstream qemu"):
> On Sat, 2013-02-16 at 12:40 +0000, Fabio Fantoni wrote:
> > I do not see this patch in the staging branch, there are problems of 
> > code style?
> 
> I think I just managed to miss actually applying this one in among all
> the other stuff I applied on Friday. I'll take another look next week.

I see this has an ack from Stefano, but I have made some comments on
the coding style so I think we want a resend with those changes.

Fabio, would you please transfer the ack from Stefano's email into
your resend ?

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 Feb 19 18:37:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:37: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 1U7s3m-0000yn-PL; Tue, 19 Feb 2013 18:36:58 +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 1U7s3l-0000yi-OG
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:36:58 +0000
Received: from [85.158.143.99:37029] by server-2.bemta-4.messagelabs.com id
	AA/F0-12656-846C3215; Tue, 19 Feb 2013 18:36:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361299015!27615433!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13322 invoked from network); 19 Feb 2013 18:36:56 -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;
	19 Feb 2013 18:36:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; 
   d="scan'208";a="8243379"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:36:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:36:54 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7s36-00066k-NL;
	Tue, 19 Feb 2013 18:36:16 +0000
Message-ID: <1361298976.2937.35.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue, 19 Feb 2013 18:36:16 +0000
In-Reply-To: <20130219163257.GR6098@type.bordeaux.inria.fr>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163257.GR6098@type.bordeaux.inria.fr>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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

V4 of the patch

In this version I try to mimic Linux's do_poll behavior. The pollfd
array is always scanned, even if some fds in the middle of the loops are
invalid. In this case we need to do no-blocking select regardless of
timeout, because we already receive events.

I tried to document the behavior as much as possible, please see
comments in code.


Wei.

----8<---
>From 39789af96d9e5a6d4f3d8a9e86546b62918c30df Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 12:15:03 +0000
Subject: [PATCH] mini-os: implement poll(2)

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  117 ++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..10a04eb 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,98 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int n, ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    n = 0;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        _pfd[i].revents = 0;
+
+        /* fd < 0, revents = 0, which is already set */
+        if (fd < 0) continue;
+
+        /* fd is invalid, revents = POLLNVAL, increment counter */
+        if (fd >= NOFILE || files[fd].type == FTYPE_NONE) {
+            n++;
+            _pfd[i].revents |= POLLNVAL;
+            continue;
+        }
+
+        /* normal case, map POLL* into readfds and writefds:
+         * POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* should never sleep when we already have events */
+    if (n) {
+        _timeo.tv_sec  = 0;
+        _timeo.tv_usec = 0;
+        timeo = &_timeo;
+    } else if (_timeout >= 0) {
+        /* normal case, construct _timeout, might sleep */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    } else {
+        /* _timeout < 0, block forever */
+        timeo = NULL;
+    }
+
+
+    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
+    /* error in select, just return, errno is set by select() */
+    if (ret < 0)
+        return ret;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+
+        /* the revents has already been set for all error case */
+        if (fd < 0 || fd >= NOFILE || files[fd].type == FTYPE_NONE)
+            continue;
+
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            n++;
+        if (FD_ISSET(fd, &efds)) {
+            /* anything bad happens we set POLLERR */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    return n;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1476,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:37:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:37: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 1U7s3m-0000yn-PL; Tue, 19 Feb 2013 18:36:58 +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 1U7s3l-0000yi-OG
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:36:58 +0000
Received: from [85.158.143.99:37029] by server-2.bemta-4.messagelabs.com id
	AA/F0-12656-846C3215; Tue, 19 Feb 2013 18:36:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361299015!27615433!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxOTk2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13322 invoked from network); 19 Feb 2013 18:36:56 -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;
	19 Feb 2013 18:36:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; 
   d="scan'208";a="8243379"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	19 Feb 2013 18:36:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 19 Feb 2013 13:36:54 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U7s36-00066k-NL;
	Tue, 19 Feb 2013 18:36:16 +0000
Message-ID: <1361298976.2937.35.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue, 19 Feb 2013 18:36:16 +0000
In-Reply-To: <20130219163257.GR6098@type.bordeaux.inria.fr>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163257.GR6098@type.bordeaux.inria.fr>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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

V4 of the patch

In this version I try to mimic Linux's do_poll behavior. The pollfd
array is always scanned, even if some fds in the middle of the loops are
invalid. In this case we need to do no-blocking select regardless of
timeout, because we already receive events.

I tried to document the behavior as much as possible, please see
comments in code.


Wei.

----8<---
>From 39789af96d9e5a6d4f3d8a9e86546b62918c30df Mon Sep 17 00:00:00 2001
From: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 19 Feb 2013 12:15:03 +0000
Subject: [PATCH] mini-os: implement poll(2)

It is just a wrapper around select(2).

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  117 ++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..10a04eb 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,98 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int n, ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    n = 0;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        _pfd[i].revents = 0;
+
+        /* fd < 0, revents = 0, which is already set */
+        if (fd < 0) continue;
+
+        /* fd is invalid, revents = POLLNVAL, increment counter */
+        if (fd >= NOFILE || files[fd].type == FTYPE_NONE) {
+            n++;
+            _pfd[i].revents |= POLLNVAL;
+            continue;
+        }
+
+        /* normal case, map POLL* into readfds and writefds:
+         * POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* should never sleep when we already have events */
+    if (n) {
+        _timeo.tv_sec  = 0;
+        _timeo.tv_usec = 0;
+        timeo = &_timeo;
+    } else if (_timeout >= 0) {
+        /* normal case, construct _timeout, might sleep */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    } else {
+        /* _timeout < 0, block forever */
+        timeo = NULL;
+    }
+
+
+    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
+    /* error in select, just return, errno is set by select() */
+    if (ret < 0)
+        return ret;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+
+        /* the revents has already been set for all error case */
+        if (fd < 0 || fd >= NOFILE || files[fd].type == FTYPE_NONE)
+            continue;
+
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            n++;
+        if (FD_ISSET(fd, &efds)) {
+            /* anything bad happens we set POLLERR */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    return n;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1476,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:39:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:39: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 1U7s5p-00015c-GI; Tue, 19 Feb 2013 18:39: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 1U7s5n-00015X-LL
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 18:39:03 +0000
Received: from [85.158.143.35:56406] by server-1.bemta-4.messagelabs.com id
	C2/9A-08839-6C6C3215; Tue, 19 Feb 2013 18:39:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1361299142!4695456!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17053 invoked from network); 19 Feb 2013 18:39:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:39:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; 
   d="scan'208";a="1622659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 18:39: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.297.1; Tue, 19 Feb 2013 18:39:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7s5m-0004et-36; Tue, 19 Feb 2013 18:39:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7s5l-000878-VP;
	Tue, 19 Feb 2013 18:39:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.50885.702521.722255@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 18:39:01 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <511E46FD.3010605@citrix.com>
References: <511E46FD.3010605@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>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] FIFO-based event channel ABI design (draft B)"):
> Event State Machine
> -------------------
> 
> Event channels are bound to a port in the domain using the existing
> ABI.
> 
> A bound event may be in one of three main states.
> 
> State    Abbrev.  PML Bits  Meaning
> -----    -------  --------  -------
> BOUND    B        000       The event is bound but not pending.
> PENDING  P        100       The event has been raised and not yet
> acknowledged.
> LINKED   L        101       The event is on an event queue.
> 
> Additionally, events may be UNMASKED or MASKED (M).
> 
> ![\label{events_sm}Event State Machine](event-sm.pdf)

This high-level state machine description doesn't capture the
transient states which exist when Xen and/or the guest need to update
multiple words at once.

In order to check that this protocol is correct, I think you should
draw a state diagram which includes these transient states, and verify
that the edges all operate as intended.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:39:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:39: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 1U7s5p-00015c-GI; Tue, 19 Feb 2013 18:39: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 1U7s5n-00015X-LL
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 18:39:03 +0000
Received: from [85.158.143.35:56406] by server-1.bemta-4.messagelabs.com id
	C2/9A-08839-6C6C3215; Tue, 19 Feb 2013 18:39:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1361299142!4695456!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNTM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17053 invoked from network); 19 Feb 2013 18:39:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 18:39:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; 
   d="scan'208";a="1622659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 18:39: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.297.1; Tue, 19 Feb 2013 18:39:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U7s5m-0004et-36; Tue, 19 Feb 2013 18:39:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U7s5l-000878-VP;
	Tue, 19 Feb 2013 18:39:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20771.50885.702521.722255@mariner.uk.xensource.com>
Date: Tue, 19 Feb 2013 18:39:01 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <511E46FD.3010605@citrix.com>
References: <511E46FD.3010605@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>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] FIFO-based event channel ABI design (draft B)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] FIFO-based event channel ABI design (draft B)"):
> Event State Machine
> -------------------
> 
> Event channels are bound to a port in the domain using the existing
> ABI.
> 
> A bound event may be in one of three main states.
> 
> State    Abbrev.  PML Bits  Meaning
> -----    -------  --------  -------
> BOUND    B        000       The event is bound but not pending.
> PENDING  P        100       The event has been raised and not yet
> acknowledged.
> LINKED   L        101       The event is on an event queue.
> 
> Additionally, events may be UNMASKED or MASKED (M).
> 
> ![\label{events_sm}Event State Machine](event-sm.pdf)

This high-level state machine description doesn't capture the
transient states which exist when Xen and/or the guest need to update
multiple words at once.

In order to check that this protocol is correct, I think you should
draw a state diagram which includes these transient states, and verify
that the edges all operate as intended.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:44:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7sAV-0001Ki-7w; Tue, 19 Feb 2013 18:43:55 +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 1U7sAT-0001Kc-5n
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:43:53 +0000
Received: from [85.158.139.211:35876] by server-7.bemta-5.messagelabs.com id
	A3/DA-11121-8E7C3215; Tue, 19 Feb 2013 18:43:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361299429!18231039!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMyMjkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21141 invoked from network); 19 Feb 2013 18:43:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 18:43:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JIhd4O028729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 18:43:40 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
	r1JIhdHW001616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 18:43:39 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
	r1JIhdAg026683; Tue, 19 Feb 2013 12:43:39 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 10:43:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6E02B1C03AF; Tue, 19 Feb 2013 13:43:37 -0500 (EST)
Date: Tue, 19 Feb 2013 13:43:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130219184337.GB18831@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 06:12:35PM +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: xen-devel@lists.xen.org
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > Changes since V3
> >   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > Changes since V2
> >   Add comments about the correct bitops to use, and on the ordering/barrier
> >   requirements on xchg_xen_ulong.
> > Changes since V1
> >   use find_first_set not __ffs
> >   fix some more unsigned long -> xen_ulong_t
> >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> 
> still doesn't apply to 3.8

Weird. It applied to my tree (stable/for-linus-3.9) without fuss.
> 
> 
> >         do {
> > -               unsigned long pending_words;
> > +               xen_ulong_t pending_words;
> > 
> >                 vcpu_info->evtchn_upcall_pending = 0;
> > 
> >                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
> >                         goto out;
> > 
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > -               /* Clear master flag /before/ clearing selector flag. */
> > -               wmb();
> > -#endif
> > -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > +               /*
> > +                * Master flag must be /before/ clearing selector
> > +                * flag. xchg_xen_ulong must contain an appropriate
> > +                * barrier.
> > +                */
> 
> Master flag must be *cleared* ...
> 
> > +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> > 
> >                 start_word_idx = __this_cpu_read(current_word_idx);
> >                 start_bit_idx = __this_cpu_read(current_bit_idx);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:44:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7sAV-0001Ki-7w; Tue, 19 Feb 2013 18:43:55 +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 1U7sAT-0001Kc-5n
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:43:53 +0000
Received: from [85.158.139.211:35876] by server-7.bemta-5.messagelabs.com id
	A3/DA-11121-8E7C3215; Tue, 19 Feb 2013 18:43:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361299429!18231039!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMyMjkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21141 invoked from network); 19 Feb 2013 18:43:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 18:43:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1JIhd4O028729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 19 Feb 2013 18:43:40 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
	r1JIhdHW001616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 19 Feb 2013 18:43:39 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
	r1JIhdAg026683; Tue, 19 Feb 2013 12:43:39 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 10:43:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6E02B1C03AF; Tue, 19 Feb 2013 13:43:37 -0500 (EST)
Date: Tue, 19 Feb 2013 13:43:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130219184337.GB18831@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 06:12:35PM +0000, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: xen-devel@lists.xen.org
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > Changes since V3
> >   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > Changes since V2
> >   Add comments about the correct bitops to use, and on the ordering/barrier
> >   requirements on xchg_xen_ulong.
> > Changes since V1
> >   use find_first_set not __ffs
> >   fix some more unsigned long -> xen_ulong_t
> >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> 
> still doesn't apply to 3.8

Weird. It applied to my tree (stable/for-linus-3.9) without fuss.
> 
> 
> >         do {
> > -               unsigned long pending_words;
> > +               xen_ulong_t pending_words;
> > 
> >                 vcpu_info->evtchn_upcall_pending = 0;
> > 
> >                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
> >                         goto out;
> > 
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > -               /* Clear master flag /before/ clearing selector flag. */
> > -               wmb();
> > -#endif
> > -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > +               /*
> > +                * Master flag must be /before/ clearing selector
> > +                * flag. xchg_xen_ulong must contain an appropriate
> > +                * barrier.
> > +                */
> 
> Master flag must be *cleared* ...
> 
> > +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> > 
> >                 start_word_idx = __this_cpu_read(current_word_idx);
> >                 start_bit_idx = __this_cpu_read(current_bit_idx);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:47:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:47: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 1U7sDL-0001Rj-RI; Tue, 19 Feb 2013 18:46:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7sDK-0001Rb-CT
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:46:50 +0000
Received: from [85.158.143.99:56780] by server-1.bemta-4.messagelabs.com id
	25/BE-08839-998C3215; Tue, 19 Feb 2013 18:46:49 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361299577!28263774!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23398 invoked from network); 19 Feb 2013 18:46:48 -0000
Received: from unknown (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 18:46:48 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 86C548407F;
	Tue, 19 Feb 2013 19:44:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id IDQ5HTyEsysp; Tue, 19 Feb 2013 19:44:16 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 2E9C48407B;
	Tue, 19 Feb 2013 19:44:16 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7sAo-00026j-KB; Tue, 19 Feb 2013 19:44:14 +0100
Date: Tue, 19 Feb 2013 19:44:14 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Message-ID: <20130219184414.GA5828@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163955.GS6098@type.bordeaux.inria.fr>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Frediano Ziglio, le Tue 19 Feb 2013 17:22:23 +0000, a =E9crit :
> On Tue, 2013-02-19 at 17:39 +0100, Samuel Thibault wrote:
> > Also, checking for files[i].type should be done on entry to the
> > function, not after having waited for some time (and perhaps opened some
> > file descriptor, etc.). I.e.:
> > =

> > Wei Liu, le Tue 19 Feb 2013 15:54:13 +0000, a =E9crit :
> > > +        /* ignore invalid fds */
> > > +        if (fd < 0 || fd >=3D NOFILE)
> > > +            continue;
> > =

> > record POLLNVAL as soon as here, and ignore that fd later on.
> > =

> =

> If you detect the handle is invalid you should not wait in select or set
> the timeout to 0. poll should return as soon at it receive an event. In
> this case getting POLLNVAL is an event. I don't know if you have to test
> all handles in this case or just return the number of fds that got set
> to POLLNVAL.

I believe you have to test all handles.

> > > +    /* don't care about the return value, but we do need errno */
> > > +    select(max_fd+1, &rfds, &wfds, &efds, timeo);
> > =

> > Mmm. I don't think we don't care about the return value: if select
> > returns -1 with EINTR, poll has to do the same. That's however probably
> > the only case we have to take care of.
> =

> if you get an error you can't consider valid the sets, from Linux man
> page (select(2)):
> =

> "On error, -1 is returned, and errno is  set  appropriately; the sets
> and timeout become undefined, so do not rely on their contents after an
> error."

Yes, sure, but we know what our select() does :)

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:47:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18:47: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 1U7sDL-0001Rj-RI; Tue, 19 Feb 2013 18:46:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7sDK-0001Rb-CT
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:46:50 +0000
Received: from [85.158.143.99:56780] by server-1.bemta-4.messagelabs.com id
	25/BE-08839-998C3215; Tue, 19 Feb 2013 18:46:49 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361299577!28263774!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23398 invoked from network); 19 Feb 2013 18:46:48 -0000
Received: from unknown (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 18:46:48 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 86C548407F;
	Tue, 19 Feb 2013 19:44:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id IDQ5HTyEsysp; Tue, 19 Feb 2013 19:44:16 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 2E9C48407B;
	Tue, 19 Feb 2013 19:44:16 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7sAo-00026j-KB; Tue, 19 Feb 2013 19:44:14 +0100
Date: Tue, 19 Feb 2013 19:44:14 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Message-ID: <20130219184414.GA5828@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163955.GS6098@type.bordeaux.inria.fr>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458399@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Frediano Ziglio, le Tue 19 Feb 2013 17:22:23 +0000, a =E9crit :
> On Tue, 2013-02-19 at 17:39 +0100, Samuel Thibault wrote:
> > Also, checking for files[i].type should be done on entry to the
> > function, not after having waited for some time (and perhaps opened some
> > file descriptor, etc.). I.e.:
> > =

> > Wei Liu, le Tue 19 Feb 2013 15:54:13 +0000, a =E9crit :
> > > +        /* ignore invalid fds */
> > > +        if (fd < 0 || fd >=3D NOFILE)
> > > +            continue;
> > =

> > record POLLNVAL as soon as here, and ignore that fd later on.
> > =

> =

> If you detect the handle is invalid you should not wait in select or set
> the timeout to 0. poll should return as soon at it receive an event. In
> this case getting POLLNVAL is an event. I don't know if you have to test
> all handles in this case or just return the number of fds that got set
> to POLLNVAL.

I believe you have to test all handles.

> > > +    /* don't care about the return value, but we do need errno */
> > > +    select(max_fd+1, &rfds, &wfds, &efds, timeo);
> > =

> > Mmm. I don't think we don't care about the return value: if select
> > returns -1 with EINTR, poll has to do the same. That's however probably
> > the only case we have to take care of.
> =

> if you get an error you can't consider valid the sets, from Linux man
> page (select(2)):
> =

> "On error, -1 is returned, and errno is  set  appropriately; the sets
> and timeout become undefined, so do not rely on their contents after an
> error."

Yes, sure, but we know what our select() does :)

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:48:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7sEh-0001XK-Bm; Tue, 19 Feb 2013 18:48:15 +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 1U7sEg-0001XB-9N
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:48:14 +0000
Received: from [85.158.138.51:24259] by server-6.bemta-3.messagelabs.com id
	D7/37-29959-DE8C3215; Tue, 19 Feb 2013 18:48:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361299692!26491107!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDY1NzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDY1NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16532 invoked from network); 19 Feb 2013 18:48:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 18:48:12 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (jored mo38) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j00ce2p1JHn9CB ;
	Tue, 19 Feb 2013 19:47:13 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 5CFF91884C; Tue, 19 Feb 2013 19:47:12 +0100 (CET)
Date: Tue, 19 Feb 2013 19:47:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130219184712.GB21783@aepfle.de>
References: <0f9c7503650fa1b1103b.1360862057@probook.site>
	<20771.49862.534182.856929@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20771.49862.534182.856929@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xend: Only add cpuid and cpuid_check
 to sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/xend: Only add cpuid and cpuid_check to sexpr once"):
> > tools/xend: Only add cpuid and cpuid_check to sexpr once
> > 
> > When converting a XendConfig object to sexpr, cpuid and cpuid_check
> > were being emitted twice in the resulting sexpr.  The first conversion
> > writes incorrect sexpr, causing parsing of the sexpr to fail when xend
> > is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
> > are read and parsed.
> > 
> > This patch skips the first conversion, and uses only the custom
> > cpuid{_check} conversion methods called later.  It is not pretty, but
> > is the least invasive fix in this complex code.
> 
> We do intend to fix bugs in xend, but I'm worried that this change
> might break something.  I don't know the code at all so forgive me if
> I'm asking stupid questions, but why does the first conversion emit an
> invalid sexpr ?

The result of having cpuid= in the domU.cfg and doing a rcxend restart is
that the sxp string is not properly converted into a list and dict(?),
instead the string is partly passed as is. xend will reject the sxp and
the domU disappears until its readded with xm new.

This change has been used almost a year now in production, no errors
were reported.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:48:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7sEh-0001XK-Bm; Tue, 19 Feb 2013 18:48:15 +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 1U7sEg-0001XB-9N
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:48:14 +0000
Received: from [85.158.138.51:24259] by server-6.bemta-3.messagelabs.com id
	D7/37-29959-DE8C3215; Tue, 19 Feb 2013 18:48:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361299692!26491107!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDY1NzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDY1NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16532 invoked from network); 19 Feb 2013 18:48:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 18:48:12 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (jored mo38) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j00ce2p1JHn9CB ;
	Tue, 19 Feb 2013 19:47:13 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 5CFF91884C; Tue, 19 Feb 2013 19:47:12 +0100 (CET)
Date: Tue, 19 Feb 2013 19:47:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130219184712.GB21783@aepfle.de>
References: <0f9c7503650fa1b1103b.1360862057@probook.site>
	<20771.49862.534182.856929@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20771.49862.534182.856929@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xend: Only add cpuid and cpuid_check
 to sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/xend: Only add cpuid and cpuid_check to sexpr once"):
> > tools/xend: Only add cpuid and cpuid_check to sexpr once
> > 
> > When converting a XendConfig object to sexpr, cpuid and cpuid_check
> > were being emitted twice in the resulting sexpr.  The first conversion
> > writes incorrect sexpr, causing parsing of the sexpr to fail when xend
> > is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
> > are read and parsed.
> > 
> > This patch skips the first conversion, and uses only the custom
> > cpuid{_check} conversion methods called later.  It is not pretty, but
> > is the least invasive fix in this complex code.
> 
> We do intend to fix bugs in xend, but I'm worried that this change
> might break something.  I don't know the code at all so forgive me if
> I'm asking stupid questions, but why does the first conversion emit an
> invalid sexpr ?

The result of having cpuid= in the domU.cfg and doing a rcxend restart is
that the sxp string is not properly converted into a list and dict(?),
instead the string is partly passed as is. xend will reject the sxp and
the domU disappears until its readded with xm new.

This change has been used almost a year now in production, no errors
were reported.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7sKW-0001oi-5Z; Tue, 19 Feb 2013 18:54:16 +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 1U7sKU-0001od-9m
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:54:14 +0000
Received: from [193.109.254.147:31424] by server-4.bemta-14.messagelabs.com id
	67/68-20719-55AC3215; Tue, 19 Feb 2013 18:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361300051!6534090!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24858 invoked from network); 19 Feb 2013 18:54:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-27.messagelabs.com with SMTP;
	19 Feb 2013 18:54:12 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (jorabe mo40) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L008b5p1JIDqnr ;
	Tue, 19 Feb 2013 19:54:11 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id E24061884C; Tue, 19 Feb 2013 19:54:10 +0100 (CET)
Date: Tue, 19 Feb 2013 19:54:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130219185410.GC21783@aepfle.de>
References: <b096442271cf6a0d1251.1361218171@probook.site>
	<20771.48457.150475.736921@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20771.48457.150475.736921@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/libxc: perpare xc_domain_save for
 upcoming changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/libxc: perpare xc_domain_save for upcoming changes"):
> > tools/libxc: perpare xc_domain_save for upcoming changes
> > 
> > An upcoming patch will pass min_remaining to xc_domain_save.
> > Because such a will be an API change, take the opportunity to change the
> > API so that it will be easier to pass more options in the future.
> 
> I'm not sure why changing the large number of arguments to
> xc_domain_save to a struct is an improvement, even given that you are
> proposing to add one.  Can you explain further ?

If new parameters will be passed into xc_domain_save it will change the
API every time. If instead such parameters are stuffed into a struct the
API will not change for callers, if the new struct member is really
optional.

I'm fine with adding yet another parameter to xc_domain_save, given that
there are appearently no external callers. libvirt uses libxl.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 18:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 18: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 1U7sKW-0001oi-5Z; Tue, 19 Feb 2013 18:54:16 +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 1U7sKU-0001od-9m
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 18:54:14 +0000
Received: from [193.109.254.147:31424] by server-4.bemta-14.messagelabs.com id
	67/68-20719-55AC3215; Tue, 19 Feb 2013 18:54:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361300051!6534090!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTI5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24858 invoked from network); 19 Feb 2013 18:54:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-27.messagelabs.com with SMTP;
	19 Feb 2013 18:54:12 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDcwfYOOLE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-078-250.pools.arcor-ip.net [84.57.78.250])
	by smtp.strato.de (jorabe mo40) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L008b5p1JIDqnr ;
	Tue, 19 Feb 2013 19:54:11 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id E24061884C; Tue, 19 Feb 2013 19:54:10 +0100 (CET)
Date: Tue, 19 Feb 2013 19:54:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130219185410.GC21783@aepfle.de>
References: <b096442271cf6a0d1251.1361218171@probook.site>
	<20771.48457.150475.736921@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20771.48457.150475.736921@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/libxc: perpare xc_domain_save for
 upcoming changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/libxc: perpare xc_domain_save for upcoming changes"):
> > tools/libxc: perpare xc_domain_save for upcoming changes
> > 
> > An upcoming patch will pass min_remaining to xc_domain_save.
> > Because such a will be an API change, take the opportunity to change the
> > API so that it will be easier to pass more options in the future.
> 
> I'm not sure why changing the large number of arguments to
> xc_domain_save to a struct is an improvement, even given that you are
> proposing to add one.  Can you explain further ?

If new parameters will be passed into xc_domain_save it will change the
API every time. If instead such parameters are stuffed into a struct the
API will not change for callers, if the new struct member is really
optional.

I'm fine with adding yet another parameter to xc_domain_save, given that
there are appearently no external callers. libvirt uses libxl.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 19:38:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 19: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 1U7t0v-0002Fw-Re; Tue, 19 Feb 2013 19:38:05 +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 1U7t0u-0002Fr-56
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 19:38:04 +0000
Received: from [85.158.137.99:16334] by server-14.bemta-3.messagelabs.com id
	94/1D-23533-B94D3215; Tue, 19 Feb 2013 19:38:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361302682!13924072!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Njg3NjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29960 invoked from network); 19 Feb 2013 19:38:02 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 19:38:02 -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 0DE9F2A78;
	Tue, 19 Feb 2013 21:38:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BBEC3F4017; Tue, 19 Feb 2013 21:38:00 +0200 (EET)
Date: Tue, 19 Feb 2013 21:38:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130219193800.GE8912@reaktio.net>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<20674.5586.142286.869968@mariner.uk.xensource.com>
	<1354897843.31710.93.camel@zakaz.uk.xensource.com>
	<20674.6749.646806.53950@mariner.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FEDB689@SHSMSX102.ccr.corp.intel.com>
	<20130109070926.GD8912@reaktio.net>
	<20130124134441.GM8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130124134441.GM8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio	and
 cpu_ioreq_move / Xen on Xen nested virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Jan 24, 2013 at 03:44:41PM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> IanJ: I can't see this patch in qemu-xen-unstable .. =

> Does the the patch still need something to be fixed before it can be appl=
ied? =

>

Ping again? I wonder if I've gotten into some blacklist already for nagging=
 about this.. =


This is a required patch for making Xen-on-Xen Nested virt working on Intel=
..

thanks,

-- Pasi
 =

> =

> On Wed, Jan 09, 2013 at 09:09:26AM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Tue, Jan 08, 2013 at 01:49:06AM +0000, Xu, Dongxiao wrote:
> > > > =

> > > > > -----Original Message-----
> > > > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > > > > Sent: Saturday, December 08, 2012 12:34 AM
> > > > > To: Ian Campbell
> > > > > Cc: Stefano Stabellini; Xu, Dongxiao; xen-devel@lists.xensource.c=
om;
> > > > > qemu-devel@nongnu.org
> > > > > Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq=
_pio and
> > > > > cpu_ioreq_move
> > > > >
> > > > > Ian Campbell writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simpl=
ify
> > > > > cpu_ioreq_pio	and cpu_ioreq_move"):
> > > > > > On Fri, 2012-12-07 at 16:14 +0000, Ian Jackson wrote:
> > > > > > > +    target_phys_addr_t offset =3D (target_phys_addr_t)req->s=
ize * i;
> > > > > > > +    if (req->df) addr -=3D offset;
> > > > > > > +    else addr -=3D offset;
> > > > > >
> > > > > > One of these -=3D should be a +=3D I presume?
> > > > >
> > > > > Uh, yes.
> > > > >
> > > > > > [...]
> > > > > > > +                write_phys_req_item((target_phys_addr_t)
> > > > req->data,
> > > > > req, i, &tmp);
> > > > > >
> > > > > > This seems to be the only one with this cast, why?
> > > > >
> > > > > This is a mistake.
> > > > >
> > > > > > write_phys_req_item takes a target_phys_addr_t so this will hap=
pen
> > > > > > regardless I think.
> > > > >
> > > > > Indeed.
> > > > >
> > > > > Ian.
> > > > =

> > > > Tested this v2 patch on my system, and it works.
> > > =

> > > Are we planning to check this patch into qemu-traditional? Since it i=
s a critical patch to boot Xen on Xen.
> > > =

> > =

> > We should definitely get Xen-on-Xen working.. =

> > =

> > =

> > -- Pasi
> > =

> > > Thanks,
> > > Dongxiao
> > > =

> > > > =

> > > > Thanks,
> > > > Dongxiao
> > > > =

> > > > =

> > > > >
> > > > > commit fd3865f8e0d867a203b4ddcb22eefa827cfaca0a
> > > > > Author: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > > Date:   Fri Dec 7 16:02:04 2012 +0000
> > > > >
> > > > >     cpu_ioreq_pio, cpu_ioreq_move: introduce read_phys_req_item,
> > > > > write_phys_req_item
> > > > >
> > > > >     The current code compare i (int) with req->count (uint32_t) i=
n a for
> > > > >     loop, risking an infinite loop if req->count is >INT_MAX.  It=
 also
> > > > >     does the multiplication of req->size in a too-small type, lea=
ding to
> > > > >     integer overflows.
> > > > >
> > > > >     Turn read_physical and write_physical into two different help=
er
> > > > >     functions, read_phys_req_item and write_phys_req_item, that t=
ake
> > > > care
> > > > >     of adding or subtracting offset depending on sign.
> > > > >
> > > > >     This removes the formulaic multiplication to a single place w=
here the
> > > > >     integer overflows can be dealt with by casting to wide-enough=
 unsigned
> > > > >     types.
> > > > >
> > > > >     Reported-By: Dongxiao Xu <dongxiao.xu@intel.com>
> > > > >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citr=
ix.com>
> > > > >     Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > >
> > > > >     --
> > > > >     v2: Fix sign when !!req->df.  Remove a useless cast.
> > > > >
> > > > > diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
> > > > > index c6d049c..63a938b 100644
> > > > > --- a/i386-dm/helper2.c
> > > > > +++ b/i386-dm/helper2.c
> > > > > @@ -339,21 +339,40 @@ static void do_outp(CPUState *env, unsigned=
 long
> > > > > addr,
> > > > >      }
> > > > >  }
> > > > >
> > > > > -static inline void read_physical(uint64_t addr, unsigned long si=
ze, void *val)
> > > > > +/*
> > > > > + * Helper functions which read/write an object from/to physical =
guest
> > > > > + * memory, as part of the implementation of an ioreq.
> > > > > + *
> > > > > + * Equivalent to
> > > > > + *   cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->si=
ze * i,
> > > > > + *                          val, req->size, 0/1)
> > > > > + * except without the integer overflow problems.
> > > > > + */
> > > > > +static void rw_phys_req_item(target_phys_addr_t addr,
> > > > > +                             ioreq_t *req, uint32_t i, void *val=
, int
> > > > rw)
> > > > >  {
> > > > > -    return cpu_physical_memory_rw((target_phys_addr_t)addr, val,=
 size,
> > > > 0);
> > > > > +    /* Do everything unsigned so overflow just results in a trun=
cated result
> > > > > +     * and accesses to undesired parts of guest memory, which is=
 up
> > > > > +     * to the guest */
> > > > > +    target_phys_addr_t offset =3D (target_phys_addr_t)req->size =
* i;
> > > > > +    if (req->df) addr -=3D offset;
> > > > > +    else addr +=3D offset;
> > > > > +    cpu_physical_memory_rw(addr, val, req->size, rw);
> > > > >  }
> > > > > -
> > > > > -static inline void write_physical(uint64_t addr, unsigned long s=
ize, void *val)
> > > > > +static inline void read_phys_req_item(target_phys_addr_t addr,
> > > > > +                                      ioreq_t *req, uint32_t i, =
void
> > > > > *val)
> > > > >  {
> > > > > -    return cpu_physical_memory_rw((target_phys_addr_t)addr, val,=
 size,
> > > > 1);
> > > > > +    rw_phys_req_item(addr, req, i, val, 0);
> > > > > +}
> > > > > +static inline void write_phys_req_item(target_phys_addr_t addr,
> > > > > +                                       ioreq_t *req, uint32_t i,
> > > > void
> > > > > *val)
> > > > > +{
> > > > > +    rw_phys_req_item(addr, req, i, val, 1);
> > > > >  }
> > > > >
> > > > >  static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
> > > > >  {
> > > > > -    int i, sign;
> > > > > -
> > > > > -    sign =3D req->df ? -1 : 1;
> > > > > +    uint32_t i;
> > > > >
> > > > >      if (req->dir =3D=3D IOREQ_READ) {
> > > > >          if (!req->data_is_ptr) {
> > > > > @@ -363,9 +382,7 @@ static void cpu_ioreq_pio(CPUState *env, iore=
q_t
> > > > *req)
> > > > >
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > >                  tmp =3D do_inp(env, req->addr, req->size);
> > > > > -                write_physical((target_phys_addr_t) req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                write_phys_req_item(req->data, req, i, &tmp);
> > > > >              }
> > > > >          }
> > > > >      } else if (req->dir =3D=3D IOREQ_WRITE) {
> > > > > @@ -375,9 +392,7 @@ static void cpu_ioreq_pio(CPUState *env, iore=
q_t
> > > > *req)
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > >                  unsigned long tmp =3D 0;
> > > > >
> > > > > -                read_physical((target_phys_addr_t) req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                read_phys_req_item(req->data, req, i, &tmp);
> > > > >                  do_outp(env, req->addr, req->size, tmp);
> > > > >              }
> > > > >          }
> > > > > @@ -386,22 +401,16 @@ static void cpu_ioreq_pio(CPUState *env, io=
req_t
> > > > > *req)
> > > > >
> > > > >  static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
> > > > >  {
> > > > > -    int i, sign;
> > > > > -
> > > > > -    sign =3D req->df ? -1 : 1;
> > > > > +    uint32_t i;
> > > > >
> > > > >      if (!req->data_is_ptr) {
> > > > >          if (req->dir =3D=3D IOREQ_READ) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                read_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &req->data);
> > > > > +                read_phys_req_item(req->addr, req, i, &req->data=
);
> > > > >              }
> > > > >          } else if (req->dir =3D=3D IOREQ_WRITE) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                write_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &req->data);
> > > > > +                write_phys_req_item(req->addr, req, i, &req->dat=
a);
> > > > >              }
> > > > >          }
> > > > >      } else {
> > > > > @@ -409,21 +418,13 @@ static void cpu_ioreq_move(CPUState *env,
> > > > ioreq_t
> > > > > *req)
> > > > >
> > > > >          if (req->dir =3D=3D IOREQ_READ) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                read_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > -                write_physical((target_phys_addr_t )req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                read_phys_req_item(req->addr, req, i, &tmp);
> > > > > +                write_phys_req_item(req->data, req, i, &tmp);
> > > > >              }
> > > > >          } else if (req->dir =3D=3D IOREQ_WRITE) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                read_physical((target_phys_addr_t) req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > -                write_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                read_phys_req_item(req->data, req, i, &tmp);
> > > > > +                write_phys_req_item(req->addr, req, i, &tmp);
> > > > >              }
> > > > >          }
> > > > >      }
> > > =

> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@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 Feb 19 19:38:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 19: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 1U7t0v-0002Fw-Re; Tue, 19 Feb 2013 19:38:05 +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 1U7t0u-0002Fr-56
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 19:38:04 +0000
Received: from [85.158.137.99:16334] by server-14.bemta-3.messagelabs.com id
	94/1D-23533-B94D3215; Tue, 19 Feb 2013 19:38:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361302682!13924072!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Njg3NjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29960 invoked from network); 19 Feb 2013 19:38:02 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 19:38:02 -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 0DE9F2A78;
	Tue, 19 Feb 2013 21:38:00 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BBEC3F4017; Tue, 19 Feb 2013 21:38:00 +0200 (EET)
Date: Tue, 19 Feb 2013 21:38:00 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130219193800.GE8912@reaktio.net>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<20674.5586.142286.869968@mariner.uk.xensource.com>
	<1354897843.31710.93.camel@zakaz.uk.xensource.com>
	<20674.6749.646806.53950@mariner.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FEDB689@SHSMSX102.ccr.corp.intel.com>
	<20130109070926.GD8912@reaktio.net>
	<20130124134441.GM8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130124134441.GM8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio	and
 cpu_ioreq_move / Xen on Xen nested virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Jan 24, 2013 at 03:44:41PM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> IanJ: I can't see this patch in qemu-xen-unstable .. =

> Does the the patch still need something to be fixed before it can be appl=
ied? =

>

Ping again? I wonder if I've gotten into some blacklist already for nagging=
 about this.. =


This is a required patch for making Xen-on-Xen Nested virt working on Intel=
..

thanks,

-- Pasi
 =

> =

> On Wed, Jan 09, 2013 at 09:09:26AM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Tue, Jan 08, 2013 at 01:49:06AM +0000, Xu, Dongxiao wrote:
> > > > =

> > > > > -----Original Message-----
> > > > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > > > > Sent: Saturday, December 08, 2012 12:34 AM
> > > > > To: Ian Campbell
> > > > > Cc: Stefano Stabellini; Xu, Dongxiao; xen-devel@lists.xensource.c=
om;
> > > > > qemu-devel@nongnu.org
> > > > > Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq=
_pio and
> > > > > cpu_ioreq_move
> > > > >
> > > > > Ian Campbell writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simpl=
ify
> > > > > cpu_ioreq_pio	and cpu_ioreq_move"):
> > > > > > On Fri, 2012-12-07 at 16:14 +0000, Ian Jackson wrote:
> > > > > > > +    target_phys_addr_t offset =3D (target_phys_addr_t)req->s=
ize * i;
> > > > > > > +    if (req->df) addr -=3D offset;
> > > > > > > +    else addr -=3D offset;
> > > > > >
> > > > > > One of these -=3D should be a +=3D I presume?
> > > > >
> > > > > Uh, yes.
> > > > >
> > > > > > [...]
> > > > > > > +                write_phys_req_item((target_phys_addr_t)
> > > > req->data,
> > > > > req, i, &tmp);
> > > > > >
> > > > > > This seems to be the only one with this cast, why?
> > > > >
> > > > > This is a mistake.
> > > > >
> > > > > > write_phys_req_item takes a target_phys_addr_t so this will hap=
pen
> > > > > > regardless I think.
> > > > >
> > > > > Indeed.
> > > > >
> > > > > Ian.
> > > > =

> > > > Tested this v2 patch on my system, and it works.
> > > =

> > > Are we planning to check this patch into qemu-traditional? Since it i=
s a critical patch to boot Xen on Xen.
> > > =

> > =

> > We should definitely get Xen-on-Xen working.. =

> > =

> > =

> > -- Pasi
> > =

> > > Thanks,
> > > Dongxiao
> > > =

> > > > =

> > > > Thanks,
> > > > Dongxiao
> > > > =

> > > > =

> > > > >
> > > > > commit fd3865f8e0d867a203b4ddcb22eefa827cfaca0a
> > > > > Author: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > > Date:   Fri Dec 7 16:02:04 2012 +0000
> > > > >
> > > > >     cpu_ioreq_pio, cpu_ioreq_move: introduce read_phys_req_item,
> > > > > write_phys_req_item
> > > > >
> > > > >     The current code compare i (int) with req->count (uint32_t) i=
n a for
> > > > >     loop, risking an infinite loop if req->count is >INT_MAX.  It=
 also
> > > > >     does the multiplication of req->size in a too-small type, lea=
ding to
> > > > >     integer overflows.
> > > > >
> > > > >     Turn read_physical and write_physical into two different help=
er
> > > > >     functions, read_phys_req_item and write_phys_req_item, that t=
ake
> > > > care
> > > > >     of adding or subtracting offset depending on sign.
> > > > >
> > > > >     This removes the formulaic multiplication to a single place w=
here the
> > > > >     integer overflows can be dealt with by casting to wide-enough=
 unsigned
> > > > >     types.
> > > > >
> > > > >     Reported-By: Dongxiao Xu <dongxiao.xu@intel.com>
> > > > >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citr=
ix.com>
> > > > >     Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > >
> > > > >     --
> > > > >     v2: Fix sign when !!req->df.  Remove a useless cast.
> > > > >
> > > > > diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
> > > > > index c6d049c..63a938b 100644
> > > > > --- a/i386-dm/helper2.c
> > > > > +++ b/i386-dm/helper2.c
> > > > > @@ -339,21 +339,40 @@ static void do_outp(CPUState *env, unsigned=
 long
> > > > > addr,
> > > > >      }
> > > > >  }
> > > > >
> > > > > -static inline void read_physical(uint64_t addr, unsigned long si=
ze, void *val)
> > > > > +/*
> > > > > + * Helper functions which read/write an object from/to physical =
guest
> > > > > + * memory, as part of the implementation of an ioreq.
> > > > > + *
> > > > > + * Equivalent to
> > > > > + *   cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->si=
ze * i,
> > > > > + *                          val, req->size, 0/1)
> > > > > + * except without the integer overflow problems.
> > > > > + */
> > > > > +static void rw_phys_req_item(target_phys_addr_t addr,
> > > > > +                             ioreq_t *req, uint32_t i, void *val=
, int
> > > > rw)
> > > > >  {
> > > > > -    return cpu_physical_memory_rw((target_phys_addr_t)addr, val,=
 size,
> > > > 0);
> > > > > +    /* Do everything unsigned so overflow just results in a trun=
cated result
> > > > > +     * and accesses to undesired parts of guest memory, which is=
 up
> > > > > +     * to the guest */
> > > > > +    target_phys_addr_t offset =3D (target_phys_addr_t)req->size =
* i;
> > > > > +    if (req->df) addr -=3D offset;
> > > > > +    else addr +=3D offset;
> > > > > +    cpu_physical_memory_rw(addr, val, req->size, rw);
> > > > >  }
> > > > > -
> > > > > -static inline void write_physical(uint64_t addr, unsigned long s=
ize, void *val)
> > > > > +static inline void read_phys_req_item(target_phys_addr_t addr,
> > > > > +                                      ioreq_t *req, uint32_t i, =
void
> > > > > *val)
> > > > >  {
> > > > > -    return cpu_physical_memory_rw((target_phys_addr_t)addr, val,=
 size,
> > > > 1);
> > > > > +    rw_phys_req_item(addr, req, i, val, 0);
> > > > > +}
> > > > > +static inline void write_phys_req_item(target_phys_addr_t addr,
> > > > > +                                       ioreq_t *req, uint32_t i,
> > > > void
> > > > > *val)
> > > > > +{
> > > > > +    rw_phys_req_item(addr, req, i, val, 1);
> > > > >  }
> > > > >
> > > > >  static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
> > > > >  {
> > > > > -    int i, sign;
> > > > > -
> > > > > -    sign =3D req->df ? -1 : 1;
> > > > > +    uint32_t i;
> > > > >
> > > > >      if (req->dir =3D=3D IOREQ_READ) {
> > > > >          if (!req->data_is_ptr) {
> > > > > @@ -363,9 +382,7 @@ static void cpu_ioreq_pio(CPUState *env, iore=
q_t
> > > > *req)
> > > > >
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > >                  tmp =3D do_inp(env, req->addr, req->size);
> > > > > -                write_physical((target_phys_addr_t) req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                write_phys_req_item(req->data, req, i, &tmp);
> > > > >              }
> > > > >          }
> > > > >      } else if (req->dir =3D=3D IOREQ_WRITE) {
> > > > > @@ -375,9 +392,7 @@ static void cpu_ioreq_pio(CPUState *env, iore=
q_t
> > > > *req)
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > >                  unsigned long tmp =3D 0;
> > > > >
> > > > > -                read_physical((target_phys_addr_t) req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                read_phys_req_item(req->data, req, i, &tmp);
> > > > >                  do_outp(env, req->addr, req->size, tmp);
> > > > >              }
> > > > >          }
> > > > > @@ -386,22 +401,16 @@ static void cpu_ioreq_pio(CPUState *env, io=
req_t
> > > > > *req)
> > > > >
> > > > >  static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
> > > > >  {
> > > > > -    int i, sign;
> > > > > -
> > > > > -    sign =3D req->df ? -1 : 1;
> > > > > +    uint32_t i;
> > > > >
> > > > >      if (!req->data_is_ptr) {
> > > > >          if (req->dir =3D=3D IOREQ_READ) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                read_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &req->data);
> > > > > +                read_phys_req_item(req->addr, req, i, &req->data=
);
> > > > >              }
> > > > >          } else if (req->dir =3D=3D IOREQ_WRITE) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                write_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &req->data);
> > > > > +                write_phys_req_item(req->addr, req, i, &req->dat=
a);
> > > > >              }
> > > > >          }
> > > > >      } else {
> > > > > @@ -409,21 +418,13 @@ static void cpu_ioreq_move(CPUState *env,
> > > > ioreq_t
> > > > > *req)
> > > > >
> > > > >          if (req->dir =3D=3D IOREQ_READ) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                read_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > -                write_physical((target_phys_addr_t )req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                read_phys_req_item(req->addr, req, i, &tmp);
> > > > > +                write_phys_req_item(req->data, req, i, &tmp);
> > > > >              }
> > > > >          } else if (req->dir =3D=3D IOREQ_WRITE) {
> > > > >              for (i =3D 0; i < req->count; i++) {
> > > > > -                read_physical((target_phys_addr_t) req->data
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > -                write_physical(req->addr
> > > > > -                  + (sign * i * req->size),
> > > > > -                  req->size, &tmp);
> > > > > +                read_phys_req_item(req->data, req, i, &tmp);
> > > > > +                write_phys_req_item(req->addr, req, i, &tmp);
> > > > >              }
> > > > >          }
> > > > >      }
> > > =

> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@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 Feb 19 20:26:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 20: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 1U7tlm-0002lv-1D; Tue, 19 Feb 2013 20:26:30 +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 1U7tlk-0002ln-N8; Tue, 19 Feb 2013 20:26:28 +0000
Received: from [85.158.143.35:58052] by server-3.bemta-4.messagelabs.com id
	F8/77-08920-3FFD3215; Tue, 19 Feb 2013 20:26:27 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1361305582!15616319!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Njg3NjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10966 invoked from network); 19 Feb 2013 20:26:23 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 20:26:23 -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 4EA4D104D;
	Tue, 19 Feb 2013 22:26:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0DBDDF4017; Tue, 19 Feb 2013 22:26:22 +0200 (EET)
Date: Tue, 19 Feb 2013 22:26:21 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20130219202621.GF8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users@lists.xen.org
Subject: [Xen-devel] Xen SR-IOV 10 Gbit/sec NIC Virtual Function PCI
 passthru tutorial on EL5 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

Hello,

I wrote a tutorial about doing Xen SR-IOV Virtual Function (VF) PCI passthru
with Intel 10 Gbit/sec ixgbe NICs with RHEL5/CentOS5 Xen dom0.

The tutorial shows how to use the SR-IOV VFs on the following VMs:

- RHEL5/CentOS5 PV domU.
- RHEL5/CentOS5 HVM guest.
- RHEL6/CentOS6 HVM guest.

http://wiki.xen.org/wiki/RHEL5_CentOS5_Xen_Intel_SR-IOV_NIC_Virtual_Function_VF_PCI_Passthru_Tutorial

I'm planning to create another tutorial in the future using more recent dom0 distro, 
most probably CentOS 6 Xen dom0. Hopefully this is useful for people :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 20:26:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 20: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 1U7tlm-0002lv-1D; Tue, 19 Feb 2013 20:26:30 +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 1U7tlk-0002ln-N8; Tue, 19 Feb 2013 20:26:28 +0000
Received: from [85.158.143.35:58052] by server-3.bemta-4.messagelabs.com id
	F8/77-08920-3FFD3215; Tue, 19 Feb 2013 20:26:27 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1361305582!15616319!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Njg3NjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10966 invoked from network); 19 Feb 2013 20:26:23 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Feb 2013 20:26:23 -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 4EA4D104D;
	Tue, 19 Feb 2013 22:26:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0DBDDF4017; Tue, 19 Feb 2013 22:26:22 +0200 (EET)
Date: Tue, 19 Feb 2013 22:26:21 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20130219202621.GF8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users@lists.xen.org
Subject: [Xen-devel] Xen SR-IOV 10 Gbit/sec NIC Virtual Function PCI
 passthru tutorial on EL5 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

Hello,

I wrote a tutorial about doing Xen SR-IOV Virtual Function (VF) PCI passthru
with Intel 10 Gbit/sec ixgbe NICs with RHEL5/CentOS5 Xen dom0.

The tutorial shows how to use the SR-IOV VFs on the following VMs:

- RHEL5/CentOS5 PV domU.
- RHEL5/CentOS5 HVM guest.
- RHEL6/CentOS6 HVM guest.

http://wiki.xen.org/wiki/RHEL5_CentOS5_Xen_Intel_SR-IOV_NIC_Virtual_Function_VF_PCI_Passthru_Tutorial

I'm planning to create another tutorial in the future using more recent dom0 distro, 
most probably CentOS 6 Xen dom0. Hopefully this is useful for people :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:38:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21:38: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 1U7usf-0003fP-CU; Tue, 19 Feb 2013 21:37:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7usd-0003fK-H1
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:37:39 +0000
Received: from [85.158.139.83:16529] by server-5.bemta-5.messagelabs.com id
	93/25-11945-2A0F3215; Tue, 19 Feb 2013 21:37:38 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361309858!20650221!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7992 invoked from network); 19 Feb 2013 21:37:38 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 21:37:38 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 9CF1FC56195;
	Tue, 19 Feb 2013 21:31:10 +0000 (GMT)
Date: Tue, 19 Feb 2013 21:31:09 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <89387166AE5D93F6D14D4CB3@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-6-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 19 February 2013 18:05:46 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 19 Feb 2013, Alex Bligh wrote:
>> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on
>> all the video ram. This case happens during migration.

This was the patch I had most difficulty with, frankly because I had
little idea what it was doing. Education welcome!

>>
>> Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
>>
>> Signed-off-by: Alex Bligh <alex@alex.org.uk>
>> ---
>>  xen-all.c |   20 ++++++++++++++++++--
>>  1 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen-all.c b/xen-all.c
>> index 121289d..dbd759c 100644
>> --- a/xen-all.c
>> +++ b/xen-all.c
>> @@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>>      rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
>>                                   start_addr >> TARGET_PAGE_BITS, npages,
>>                                   bitmap);
>> -    if (rc) {
>> +    if (rc < 0) {
>> +        if (rc != -ENODATA) {
>> +            ram_addr_t addr, end;
>> +
>> +            xen_modified_memory(start_addr, size);
>> +
>> +            end = TARGET_PAGE_ALIGN(start_addr + size);
>> +            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr
>> += TARGET_PAGE_SIZE) { +
>> cpu_physical_memory_set_dirty(addr);
>> +            }
>> +
>> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
>> +                    ", 0x" TARGET_FMT_plx "): %s\n",
>> +                    start_addr, start_addr + size, strerror(-rc));
>> +        }
>>          return rc;
>>      }
>
> 8aba7dc02d5660df7e7d8651304b3079908358be only adds a simple call to
> xen_modified_memory if rc != ENODATA.
> Where does the rest of the code you are adding comes from?

Applying the patch unchanged is not easy as there are a pile of
conflicting items. I was taking a conservative approach partly
as I didn't fully understand what types of addresses could be
safely used where. My approach was to make this function as similar
as possible to xen 4.3 immediately after the patch, which is here:

http://git.qemu.org/?p=qemu.git;a=blob;f=xen-all.c;h=e6308be23adb7198c144883eb886fb6edb5fe09f;hb=8aba7dc02d5660df7e7d8651304b3079908358be

There were some oddnesses there, such as:

 508     if (rc < 0) {
 509         if (rc != -ENODATA) {
 510             memory_region_set_dirty(framebuffer, 0, size);
 511             DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
 512                     ", 0x" TARGET_FMT_plx "): %s\n",
 513                     start_addr, start_addr + size, strerror(-rc));
 514         }
 515         return;
 516     }

What is the point of the outer check on rc?

I think you are asking why I didn't just call memory_region_set_dirty.
memory_region_set_dirty in 4.2 (as opposed to 4.3) takes:
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr);
and the 3 parameter version is unavailable, so what I did was (I hope)
the equivalent of what the 3 parameter version would have done, going
through each page.

I could have modified memory_region_set_dirty to cope with multiple pages
but that seemed like a more intrusive change.

>> @@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>>          while (map != 0) {
>>              j = ffsl(map) - 1;
>>              map &= ~(1ul << j);
>> -            cpu_physical_memory_set_dirty(vram_offset + (i * width + j)
>> * TARGET_PAGE_SIZE); +            target_phys_addr_t todirty =
>> vram_offset + (i * width + j) * TARGET_PAGE_SIZE; +
>> xen_modified_memory(todirty, TARGET_PAGE_SIZE);
>> +            cpu_physical_memory_set_dirty(todirty);
>>          };
>>      }
>
> where does this chuck come from?
> Wouldn't it make more sense to add a call to xen_modified_memory from
> cpu_physical_memory_set_dirty?

Again, I was trying to emulate what the 3 parameter
memory_region_set_dirty() does. I believe cpu_physical_memory_set_dirty has
other callers, and was unsure whether adding a call to xen_modified_memory
would be safe in there.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:38:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21:38: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 1U7usf-0003fP-CU; Tue, 19 Feb 2013 21:37:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7usd-0003fK-H1
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:37:39 +0000
Received: from [85.158.139.83:16529] by server-5.bemta-5.messagelabs.com id
	93/25-11945-2A0F3215; Tue, 19 Feb 2013 21:37:38 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361309858!20650221!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7992 invoked from network); 19 Feb 2013 21:37:38 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 21:37:38 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 9CF1FC56195;
	Tue, 19 Feb 2013 21:31:10 +0000 (GMT)
Date: Tue, 19 Feb 2013 21:31:09 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <89387166AE5D93F6D14D4CB3@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-6-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 19 February 2013 18:05:46 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 19 Feb 2013, Alex Bligh wrote:
>> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on
>> all the video ram. This case happens during migration.

This was the patch I had most difficulty with, frankly because I had
little idea what it was doing. Education welcome!

>>
>> Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
>>
>> Signed-off-by: Alex Bligh <alex@alex.org.uk>
>> ---
>>  xen-all.c |   20 ++++++++++++++++++--
>>  1 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen-all.c b/xen-all.c
>> index 121289d..dbd759c 100644
>> --- a/xen-all.c
>> +++ b/xen-all.c
>> @@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>>      rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
>>                                   start_addr >> TARGET_PAGE_BITS, npages,
>>                                   bitmap);
>> -    if (rc) {
>> +    if (rc < 0) {
>> +        if (rc != -ENODATA) {
>> +            ram_addr_t addr, end;
>> +
>> +            xen_modified_memory(start_addr, size);
>> +
>> +            end = TARGET_PAGE_ALIGN(start_addr + size);
>> +            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr
>> += TARGET_PAGE_SIZE) { +
>> cpu_physical_memory_set_dirty(addr);
>> +            }
>> +
>> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
>> +                    ", 0x" TARGET_FMT_plx "): %s\n",
>> +                    start_addr, start_addr + size, strerror(-rc));
>> +        }
>>          return rc;
>>      }
>
> 8aba7dc02d5660df7e7d8651304b3079908358be only adds a simple call to
> xen_modified_memory if rc != ENODATA.
> Where does the rest of the code you are adding comes from?

Applying the patch unchanged is not easy as there are a pile of
conflicting items. I was taking a conservative approach partly
as I didn't fully understand what types of addresses could be
safely used where. My approach was to make this function as similar
as possible to xen 4.3 immediately after the patch, which is here:

http://git.qemu.org/?p=qemu.git;a=blob;f=xen-all.c;h=e6308be23adb7198c144883eb886fb6edb5fe09f;hb=8aba7dc02d5660df7e7d8651304b3079908358be

There were some oddnesses there, such as:

 508     if (rc < 0) {
 509         if (rc != -ENODATA) {
 510             memory_region_set_dirty(framebuffer, 0, size);
 511             DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
 512                     ", 0x" TARGET_FMT_plx "): %s\n",
 513                     start_addr, start_addr + size, strerror(-rc));
 514         }
 515         return;
 516     }

What is the point of the outer check on rc?

I think you are asking why I didn't just call memory_region_set_dirty.
memory_region_set_dirty in 4.2 (as opposed to 4.3) takes:
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr);
and the 3 parameter version is unavailable, so what I did was (I hope)
the equivalent of what the 3 parameter version would have done, going
through each page.

I could have modified memory_region_set_dirty to cope with multiple pages
but that seemed like a more intrusive change.

>> @@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
>>          while (map != 0) {
>>              j = ffsl(map) - 1;
>>              map &= ~(1ul << j);
>> -            cpu_physical_memory_set_dirty(vram_offset + (i * width + j)
>> * TARGET_PAGE_SIZE); +            target_phys_addr_t todirty =
>> vram_offset + (i * width + j) * TARGET_PAGE_SIZE; +
>> xen_modified_memory(todirty, TARGET_PAGE_SIZE);
>> +            cpu_physical_memory_set_dirty(todirty);
>>          };
>>      }
>
> where does this chuck come from?
> Wouldn't it make more sense to add a call to xen_modified_memory from
> cpu_physical_memory_set_dirty?

Again, I was trying to emulate what the 3 parameter
memory_region_set_dirty() does. I believe cpu_physical_memory_set_dirty has
other callers, and was unsure whether adding a call to xen_modified_memory
would be safe in there.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:43:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21:43: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 1U7uxr-0003qN-Br; Tue, 19 Feb 2013 21:43:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7uxo-0003qF-UD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:43:01 +0000
Received: from [85.158.138.51:50379] by server-14.bemta-3.messagelabs.com id
	FA/C0-23533-4E1F3215; Tue, 19 Feb 2013 21:43:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361310151!24214705!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16641 invoked from network); 19 Feb 2013 21:42:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 21:42:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id ACB6DC56196;
	Tue, 19 Feb 2013 21:42:18 +0000 (GMT)
Date: Tue, 19 Feb 2013 21:42:17 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <9B86FF34BF4E25473587D0B5@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-4-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 3/5] exec: Introduce helper to set
 dirty	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 19 February 2013 17:42:50 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> In QEMU the code style is spaces for indentation.

OK no idea how that happened - sorry. I'm using qemu's published emacs
c mode (or thought I was).

> Moreover the right way of doing the backport here would be firstly to
> backport 0b57e287, then 51d7a9eb2b64e787c90bea1027308087eac22065 should
> just apply.

I just backported the 5 patches you pointed me at, and any code changes
they required.

So the change I posted brings in invalidate_and_set_dirty, pretty much
per the original patch. Is the issue here I combined it with the other
patch you mentioned? Guidance welcome.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:43:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21:43: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 1U7uxr-0003qN-Br; Tue, 19 Feb 2013 21:43:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7uxo-0003qF-UD
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:43:01 +0000
Received: from [85.158.138.51:50379] by server-14.bemta-3.messagelabs.com id
	FA/C0-23533-4E1F3215; Tue, 19 Feb 2013 21:43:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361310151!24214705!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16641 invoked from network); 19 Feb 2013 21:42:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-174.messagelabs.com with SMTP;
	19 Feb 2013 21:42:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id ACB6DC56196;
	Tue, 19 Feb 2013 21:42:18 +0000 (GMT)
Date: Tue, 19 Feb 2013 21:42:17 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <9B86FF34BF4E25473587D0B5@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-4-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 3/5] exec: Introduce helper to set
 dirty	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 19 February 2013 17:42:50 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> In QEMU the code style is spaces for indentation.

OK no idea how that happened - sorry. I'm using qemu's published emacs
c mode (or thought I was).

> Moreover the right way of doing the backport here would be firstly to
> backport 0b57e287, then 51d7a9eb2b64e787c90bea1027308087eac22065 should
> just apply.

I just backported the 5 patches you pointed me at, and any code changes
they required.

So the change I posted brings in invalidate_and_set_dirty, pretty much
per the original patch. Is the issue here I combined it with the other
patch you mentioned? Guidance welcome.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:48:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21:48: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 1U7v2X-0003zN-3O; Tue, 19 Feb 2013 21:47:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7v2V-0003zG-P2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:47:51 +0000
Received: from [85.158.139.83:46865] by server-9.bemta-5.messagelabs.com id
	52/36-24440-603F3215; Tue, 19 Feb 2013 21:47:50 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361310470!25281855!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13992 invoked from network); 19 Feb 2013 21:47:50 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-4.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 21:47:50 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E2469C56196;
	Tue, 19 Feb 2013 21:47:38 +0000 (GMT)
Date: Tue, 19 Feb 2013 21:47:37 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <8C4820ECA744AD74C30515BF@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 19 February 2013 18:03:04 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> e226939de5814527a21396903b08c3d0ed989558 adds two calls to
> xen_modified_memory, one in cpu_physical_memory_set_dirty_range, the
> other in invalidate_and_set_dirty.
>
> Where does this one come from?
>
> If something is missing you need to backport that patch too, rather than
> trying to adapt this patch.
> In this case I believe you need to backport
> 1720aeee72888f80b974c33b6eb39922a0bea992.

Again, I was trying to make the fewest changes possible, being aware I
have little understanding of the code. Some assistance would be appreciated
here particularly as the substitute patch you mention would appear to have
have wider implications.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:48:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21:48: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 1U7v2X-0003zN-3O; Tue, 19 Feb 2013 21:47:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U7v2V-0003zG-P2
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:47:51 +0000
Received: from [85.158.139.83:46865] by server-9.bemta-5.messagelabs.com id
	52/36-24440-603F3215; Tue, 19 Feb 2013 21:47:50 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361310470!25281855!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13992 invoked from network); 19 Feb 2013 21:47:50 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-4.tower-182.messagelabs.com with SMTP;
	19 Feb 2013 21:47:50 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id E2469C56196;
	Tue, 19 Feb 2013 21:47:38 +0000 (GMT)
Date: Tue, 19 Feb 2013 21:47:37 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <8C4820ECA744AD74C30515BF@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 19 February 2013 18:03:04 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> e226939de5814527a21396903b08c3d0ed989558 adds two calls to
> xen_modified_memory, one in cpu_physical_memory_set_dirty_range, the
> other in invalidate_and_set_dirty.
>
> Where does this one come from?
>
> If something is missing you need to backport that patch too, rather than
> trying to adapt this patch.
> In this case I believe you need to backport
> 1720aeee72888f80b974c33b6eb39922a0bea992.

Again, I was trying to make the fewest changes possible, being aware I
have little understanding of the code. Some assistance would be appreciated
here particularly as the substitute patch you mention would appear to have
have wider implications.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:49:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21: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 1U7v43-000458-KA; Tue, 19 Feb 2013 21:49:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7v42-000453-HQ
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:49:26 +0000
Received: from [85.158.143.35:46437] by server-2.bemta-4.messagelabs.com id
	4A/DD-12656-563F3215; Tue, 19 Feb 2013 21:49:25 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1361310543!3930492!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9067 invoked from network); 19 Feb 2013 21:49:04 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 21:49:04 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 2A9AB8407F;
	Tue, 19 Feb 2013 22:48:57 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id VkywzncMJ2vt; Tue, 19 Feb 2013 22:48:54 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 8E45384081;
	Tue, 19 Feb 2013 22:48:45 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7v3M-000797-9l; Tue, 19 Feb 2013 22:48:44 +0100
Date: Tue, 19 Feb 2013 22:48:44 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219214844.GM5828@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163257.GR6098@type.bordeaux.inria.fr>
	<1361298976.2937.35.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361298976.2937.35.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Liu, le Tue 19 Feb 2013 18:36:16 +0000, a =E9crit :
> V4 of the patch
> =

> In this version I try to mimic Linux's do_poll behavior. The pollfd
> array is always scanned, even if some fds in the middle of the loops are
> invalid. In this case we need to do no-blocking select regardless of
> timeout, because we already receive events.
> =

> I tried to document the behavior as much as possible, please see
> comments in code.
> =

> =

> Wei.
> =

> ----8<---
> From 39789af96d9e5a6d4f3d8a9e86546b62918c30df Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Tue, 19 Feb 2013 12:15:03 +0000
> Subject: [PATCH] mini-os: implement poll(2)
> =

> It is just a wrapper around select(2).
> =

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  extras/mini-os/include/posix/poll.h |    1 +
>  extras/mini-os/lib/sys.c            |  117 +++++++++++++++++++++++++++++=
+++++-
>  2 files changed, 117 insertions(+), 1 deletion(-)
>  create mode 100644 extras/mini-os/include/posix/poll.h
> =

> diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include=
/posix/poll.h
> new file mode 100644
> index 0000000..06fb41a
> --- /dev/null
> +++ b/extras/mini-os/include/posix/poll.h
> @@ -0,0 +1 @@
> +#include <sys/poll.h>
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 3cc3340..10a04eb 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -31,6 +31,7 @@
>  #include <tpm_tis.h>
>  #include <xenbus.h>
>  #include <xenstore.h>
> +#include <poll.h>
>  =

>  #include <sys/types.h>
>  #include <sys/unistd.h>
> @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_s=
et *writefds, fd_set *except
>  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
>  #endif
>  =

> +#ifdef LIBC_DEBUG
> +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> +{
> +    int i, comma, fd;
> +
> +    printk("[");
> +    comma =3D 0;
> +    for (i =3D 0; i < nfds; i++) {
> +        fd =3D pfd[i].fd;
> +        if (comma)
> +            printk(", ");
> +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> +            pfd[i].events);
> +            comma =3D 1;
> +    }
> +    printk("]");
> +
> +    printk(", %d, %d", nfds, timeout);
> +}
> +#else
> +#define dump_pollfds(pfds, nfds, timeout)
> +#endif
> +
>  /* Just poll without blocking */
>  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_s=
et *exceptfds)
>  {
> @@ -983,6 +1007,98 @@ out:
>      return ret;
>  }
>  =

> +/* Wrap around select */
> +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> +{
> +    int n, ret;
> +    int i, fd;
> +    struct timeval _timeo, *timeo =3D NULL;
> +    fd_set rfds, wfds, efds;
> +    int max_fd =3D -1;
> +
> +    DEBUG("poll(");
> +    dump_pollfds(_pfd, _nfds, _timeout);
> +    DEBUG(")\n");
> +
> +    FD_ZERO(&rfds);
> +    FD_ZERO(&wfds);
> +    FD_ZERO(&efds);
> +
> +    n =3D 0;
> +
> +    for (i =3D 0; i < _nfds; i++) {
> +        fd =3D _pfd[i].fd;
> +        _pfd[i].revents =3D 0;
> +
> +        /* fd < 0, revents =3D 0, which is already set */
> +        if (fd < 0) continue;
> +
> +        /* fd is invalid, revents =3D POLLNVAL, increment counter */
> +        if (fd >=3D NOFILE || files[fd].type =3D=3D FTYPE_NONE) {
> +            n++;
> +            _pfd[i].revents |=3D POLLNVAL;
> +            continue;
> +        }
> +
> +        /* normal case, map POLL* into readfds and writefds:
> +         * POLLIN  -> readfds
> +         * POLLOUT -> writefds
> +         * POLL*   -> none
> +         */
> +        if (_pfd[i].events & POLLIN)
> +            FD_SET(fd, &rfds);
> +        if (_pfd[i].events & POLLOUT)
> +            FD_SET(fd, &wfds);
> +        /* always set exceptfds */
> +        FD_SET(fd, &efds);
> +        if (fd > max_fd)
> +            max_fd =3D fd;
> +    }
> +
> +    /* should never sleep when we already have events */
> +    if (n) {
> +        _timeo.tv_sec  =3D 0;
> +        _timeo.tv_usec =3D 0;
> +        timeo =3D &_timeo;
> +    } else if (_timeout >=3D 0) {
> +        /* normal case, construct _timeout, might sleep */
> +        _timeo.tv_sec  =3D _timeout / 1000;
> +        _timeo.tv_usec =3D (_timeout % 1000) * 1000;
> +        timeo =3D &_timeo;
> +    } else {
> +        /* _timeout < 0, block forever */
> +        timeo =3D NULL;
> +    }
> +
> +
> +    ret =3D select(max_fd+1, &rfds, &wfds, &efds, timeo);
> +    /* error in select, just return, errno is set by select() */
> +    if (ret < 0)
> +        return ret;
> +
> +    for (i =3D 0; i < _nfds; i++) {
> +        fd =3D _pfd[i].fd;
> +
> +        /* the revents has already been set for all error case */
> +        if (fd < 0 || fd >=3D NOFILE || files[fd].type =3D=3D FTYPE_NONE)
> +            continue;
> +
> +        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &=
efds))
> +            n++;
> +        if (FD_ISSET(fd, &efds)) {
> +            /* anything bad happens we set POLLERR */
> +            _pfd[i].revents |=3D POLLERR;
> +            continue;
> +        }
> +        if (FD_ISSET(fd, &rfds))
> +            _pfd[i].revents |=3D POLLIN;
> +        if (FD_ISSET(fd, &wfds))
> +            _pfd[i].revents |=3D POLLOUT;
> +    }
> +
> +    return n;
> +}
> +
>  #ifdef HAVE_LWIP
>  int socket(int domain, int type, int protocol)
>  {
> @@ -1360,7 +1476,6 @@ unsupported_function(int, tcgetattr, 0);
>  unsupported_function(int, grantpt, -1);
>  unsupported_function(int, unlockpt, -1);
>  unsupported_function(char *, ptsname, NULL);
> -unsupported_function(int, poll, -1);
>  =

>  /* net/if.h */
>  unsupported_function_log(unsigned int, if_nametoindex, -1);
> -- =

> 1.7.10.4
> =

> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


-- =

Samuel
<s> on se croirait en cool : Some browsers close comments on the first ">" =
character, so to hide script content from such browsers, you can transpose =
operands for relational and shift operators (e.g., use "y < x" rather than =
"x > y") or use scripting language-dependent escapes for ">".
 -+- #ens-mim -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 21:49:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 21: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 1U7v43-000458-KA; Tue, 19 Feb 2013 21:49:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1U7v42-000453-HQ
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 21:49:26 +0000
Received: from [85.158.143.35:46437] by server-2.bemta-4.messagelabs.com id
	4A/DD-12656-563F3215; Tue, 19 Feb 2013 21:49:25 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1361310543!3930492!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9067 invoked from network); 19 Feb 2013 21:49:04 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Feb 2013 21:49:04 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 2A9AB8407F;
	Tue, 19 Feb 2013 22:48:57 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id VkywzncMJ2vt; Tue, 19 Feb 2013 22:48:54 +0100 (CET)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 8E45384081;
	Tue, 19 Feb 2013 22:48:45 +0100 (CET)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1U7v3M-000797-9l; Tue, 19 Feb 2013 22:48:44 +0100
Date: Tue, 19 Feb 2013 22:48:44 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20130219214844.GM5828@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1361281277-5637-1-git-send-email-wei.liu2@citrix.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458396@LONPMAILBOX01.citrite.net>
	<1361283772.2937.3.camel@zion.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458397@LONPMAILBOX01.citrite.net>
	<1361287529.2937.13.camel@zion.uk.xensource.com>
	<1361289253.2937.17.camel@zion.uk.xensource.com>
	<20130219163257.GR6098@type.bordeaux.inria.fr>
	<1361298976.2937.35.camel@zion.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361298976.2937.35.camel@zion.uk.xensource.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mini-os: implement poll(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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Liu, le Tue 19 Feb 2013 18:36:16 +0000, a =E9crit :
> V4 of the patch
> =

> In this version I try to mimic Linux's do_poll behavior. The pollfd
> array is always scanned, even if some fds in the middle of the loops are
> invalid. In this case we need to do no-blocking select regardless of
> timeout, because we already receive events.
> =

> I tried to document the behavior as much as possible, please see
> comments in code.
> =

> =

> Wei.
> =

> ----8<---
> From 39789af96d9e5a6d4f3d8a9e86546b62918c30df Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Tue, 19 Feb 2013 12:15:03 +0000
> Subject: [PATCH] mini-os: implement poll(2)
> =

> It is just a wrapper around select(2).
> =

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  extras/mini-os/include/posix/poll.h |    1 +
>  extras/mini-os/lib/sys.c            |  117 +++++++++++++++++++++++++++++=
+++++-
>  2 files changed, 117 insertions(+), 1 deletion(-)
>  create mode 100644 extras/mini-os/include/posix/poll.h
> =

> diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include=
/posix/poll.h
> new file mode 100644
> index 0000000..06fb41a
> --- /dev/null
> +++ b/extras/mini-os/include/posix/poll.h
> @@ -0,0 +1 @@
> +#include <sys/poll.h>
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 3cc3340..10a04eb 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -31,6 +31,7 @@
>  #include <tpm_tis.h>
>  #include <xenbus.h>
>  #include <xenstore.h>
> +#include <poll.h>
>  =

>  #include <sys/types.h>
>  #include <sys/unistd.h>
> @@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_s=
et *writefds, fd_set *except
>  #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
>  #endif
>  =

> +#ifdef LIBC_DEBUG
> +static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
> +{
> +    int i, comma, fd;
> +
> +    printk("[");
> +    comma =3D 0;
> +    for (i =3D 0; i < nfds; i++) {
> +        fd =3D pfd[i].fd;
> +        if (comma)
> +            printk(", ");
> +        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
> +            pfd[i].events);
> +            comma =3D 1;
> +    }
> +    printk("]");
> +
> +    printk(", %d, %d", nfds, timeout);
> +}
> +#else
> +#define dump_pollfds(pfds, nfds, timeout)
> +#endif
> +
>  /* Just poll without blocking */
>  static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_s=
et *exceptfds)
>  {
> @@ -983,6 +1007,98 @@ out:
>      return ret;
>  }
>  =

> +/* Wrap around select */
> +int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
> +{
> +    int n, ret;
> +    int i, fd;
> +    struct timeval _timeo, *timeo =3D NULL;
> +    fd_set rfds, wfds, efds;
> +    int max_fd =3D -1;
> +
> +    DEBUG("poll(");
> +    dump_pollfds(_pfd, _nfds, _timeout);
> +    DEBUG(")\n");
> +
> +    FD_ZERO(&rfds);
> +    FD_ZERO(&wfds);
> +    FD_ZERO(&efds);
> +
> +    n =3D 0;
> +
> +    for (i =3D 0; i < _nfds; i++) {
> +        fd =3D _pfd[i].fd;
> +        _pfd[i].revents =3D 0;
> +
> +        /* fd < 0, revents =3D 0, which is already set */
> +        if (fd < 0) continue;
> +
> +        /* fd is invalid, revents =3D POLLNVAL, increment counter */
> +        if (fd >=3D NOFILE || files[fd].type =3D=3D FTYPE_NONE) {
> +            n++;
> +            _pfd[i].revents |=3D POLLNVAL;
> +            continue;
> +        }
> +
> +        /* normal case, map POLL* into readfds and writefds:
> +         * POLLIN  -> readfds
> +         * POLLOUT -> writefds
> +         * POLL*   -> none
> +         */
> +        if (_pfd[i].events & POLLIN)
> +            FD_SET(fd, &rfds);
> +        if (_pfd[i].events & POLLOUT)
> +            FD_SET(fd, &wfds);
> +        /* always set exceptfds */
> +        FD_SET(fd, &efds);
> +        if (fd > max_fd)
> +            max_fd =3D fd;
> +    }
> +
> +    /* should never sleep when we already have events */
> +    if (n) {
> +        _timeo.tv_sec  =3D 0;
> +        _timeo.tv_usec =3D 0;
> +        timeo =3D &_timeo;
> +    } else if (_timeout >=3D 0) {
> +        /* normal case, construct _timeout, might sleep */
> +        _timeo.tv_sec  =3D _timeout / 1000;
> +        _timeo.tv_usec =3D (_timeout % 1000) * 1000;
> +        timeo =3D &_timeo;
> +    } else {
> +        /* _timeout < 0, block forever */
> +        timeo =3D NULL;
> +    }
> +
> +
> +    ret =3D select(max_fd+1, &rfds, &wfds, &efds, timeo);
> +    /* error in select, just return, errno is set by select() */
> +    if (ret < 0)
> +        return ret;
> +
> +    for (i =3D 0; i < _nfds; i++) {
> +        fd =3D _pfd[i].fd;
> +
> +        /* the revents has already been set for all error case */
> +        if (fd < 0 || fd >=3D NOFILE || files[fd].type =3D=3D FTYPE_NONE)
> +            continue;
> +
> +        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &=
efds))
> +            n++;
> +        if (FD_ISSET(fd, &efds)) {
> +            /* anything bad happens we set POLLERR */
> +            _pfd[i].revents |=3D POLLERR;
> +            continue;
> +        }
> +        if (FD_ISSET(fd, &rfds))
> +            _pfd[i].revents |=3D POLLIN;
> +        if (FD_ISSET(fd, &wfds))
> +            _pfd[i].revents |=3D POLLOUT;
> +    }
> +
> +    return n;
> +}
> +
>  #ifdef HAVE_LWIP
>  int socket(int domain, int type, int protocol)
>  {
> @@ -1360,7 +1476,6 @@ unsupported_function(int, tcgetattr, 0);
>  unsupported_function(int, grantpt, -1);
>  unsupported_function(int, unlockpt, -1);
>  unsupported_function(char *, ptsname, NULL);
> -unsupported_function(int, poll, -1);
>  =

>  /* net/if.h */
>  unsupported_function_log(unsigned int, if_nametoindex, -1);
> -- =

> 1.7.10.4
> =

> =

> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


-- =

Samuel
<s> on se croirait en cool : Some browsers close comments on the first ">" =
character, so to hide script content from such browsers, you can transpose =
operands for relational and shift operators (e.g., use "y < x" rather than =
"x > y") or use scripting language-dependent escapes for ">".
 -+- #ens-mim -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 23:09:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 23: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 1U7wJU-0004uN-71; Tue, 19 Feb 2013 23:09:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1U7wJT-0004uI-B6
	for Xen-devel@lists.xen.org; Tue, 19 Feb 2013 23:09:27 +0000
Received: from [85.158.143.35:10406] by server-1.bemta-4.messagelabs.com id
	30/46-08839-62604215; Tue, 19 Feb 2013 23:09:26 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1361315365!10132574!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10211 invoked from network); 19 Feb 2013 23:09:25 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 23:09:25 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so5496905wie.14
	for <Xen-devel@lists.xen.org>; Tue, 19 Feb 2013 15:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=1lBvXo+iw1CWms1dIKk8oXB8sgVYSEcLTcb8lm5xjYs=;
	b=ovINSvsc9cNdrI6HedlYD3Qx6kYrZZhKFqergGHnTyEZzPE9Ig20C6wio0RxnFnIG6
	8i5L/thmRb/pOuAkZBT3UjdxfJOR0R/qRrfluONfXfOMRjnJbcrQ2hz8yV0zj70+Nx+1
	K+6tzIiF4P2ts1bME6xI/ntbjAbrZnxhsJYVzxXzsMHPyWcbLBSaO5iSfPaErgMvAoMe
	kjAcpIUlpz7taSwtFUm+eQ8UTJYmRmryb8dyZ4tLSpk0jpd2kh1UB8CUBObwBgN20DyP
	5njJ5HRZbGTo21aUDDSKQBFX+ZsmCX9PUmsv2lUC4ePEPJga3lYXVXGs7k8emNEzS4kd
	qcNw==
MIME-Version: 1.0
X-Received: by 10.180.80.35 with SMTP id o3mr30989629wix.9.1361315363148; Tue,
	19 Feb 2013 15:09:23 -0800 (PST)
Received: by 10.216.98.67 with HTTP; Tue, 19 Feb 2013 15:09:23 -0800 (PST)
Date: Tue, 19 Feb 2013 15:09:23 -0800
Message-ID: <CAJJWZcwuPAEXQ+ou56F6jhV778R7GQmdm7C721h8avXAGJmv4A@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] What is do_ni_hypercall() for
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2715370454467031495=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2715370454467031495==
Content-Type: multipart/alternative; boundary=f46d044287f2a5d45604d61beec3

--f46d044287f2a5d45604d61beec3
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,
I traced pv hypercalls and found that the vector "do_ni_hypercall" is
invoked a lot. But this hypercall function does nothing (from the source
code). So I am very confused what is do_ni_hypercall for? Why do guests
invoke it ?
Thanks a lot,
-- 
Xinxin

--f46d044287f2a5d45604d61beec3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everyone,<div>I traced pv hypercalls and found that the vector &quot;do_=
ni_hypercall&quot; is invoked a lot. But this hypercall function does nothi=
ng (from the source code). So I am very confused what is do_ni_hypercall fo=
r? Why do guests invoke it ?<br clear=3D"all">
<div>Thanks a lot,</div>-- <br>Xinxin

</div>

--f46d044287f2a5d45604d61beec3--


--===============2715370454467031495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2715370454467031495==--


From xen-devel-bounces@lists.xen.org Tue Feb 19 23:09:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 23: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 1U7wJU-0004uN-71; Tue, 19 Feb 2013 23:09:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1U7wJT-0004uI-B6
	for Xen-devel@lists.xen.org; Tue, 19 Feb 2013 23:09:27 +0000
Received: from [85.158.143.35:10406] by server-1.bemta-4.messagelabs.com id
	30/46-08839-62604215; Tue, 19 Feb 2013 23:09:26 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1361315365!10132574!1
X-Originating-IP: [209.85.212.175]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10211 invoked from network); 19 Feb 2013 23:09:25 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 23:09:25 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so5496905wie.14
	for <Xen-devel@lists.xen.org>; Tue, 19 Feb 2013 15:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=1lBvXo+iw1CWms1dIKk8oXB8sgVYSEcLTcb8lm5xjYs=;
	b=ovINSvsc9cNdrI6HedlYD3Qx6kYrZZhKFqergGHnTyEZzPE9Ig20C6wio0RxnFnIG6
	8i5L/thmRb/pOuAkZBT3UjdxfJOR0R/qRrfluONfXfOMRjnJbcrQ2hz8yV0zj70+Nx+1
	K+6tzIiF4P2ts1bME6xI/ntbjAbrZnxhsJYVzxXzsMHPyWcbLBSaO5iSfPaErgMvAoMe
	kjAcpIUlpz7taSwtFUm+eQ8UTJYmRmryb8dyZ4tLSpk0jpd2kh1UB8CUBObwBgN20DyP
	5njJ5HRZbGTo21aUDDSKQBFX+ZsmCX9PUmsv2lUC4ePEPJga3lYXVXGs7k8emNEzS4kd
	qcNw==
MIME-Version: 1.0
X-Received: by 10.180.80.35 with SMTP id o3mr30989629wix.9.1361315363148; Tue,
	19 Feb 2013 15:09:23 -0800 (PST)
Received: by 10.216.98.67 with HTTP; Tue, 19 Feb 2013 15:09:23 -0800 (PST)
Date: Tue, 19 Feb 2013 15:09:23 -0800
Message-ID: <CAJJWZcwuPAEXQ+ou56F6jhV778R7GQmdm7C721h8avXAGJmv4A@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] What is do_ni_hypercall() for
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2715370454467031495=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2715370454467031495==
Content-Type: multipart/alternative; boundary=f46d044287f2a5d45604d61beec3

--f46d044287f2a5d45604d61beec3
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,
I traced pv hypercalls and found that the vector "do_ni_hypercall" is
invoked a lot. But this hypercall function does nothing (from the source
code). So I am very confused what is do_ni_hypercall for? Why do guests
invoke it ?
Thanks a lot,
-- 
Xinxin

--f46d044287f2a5d45604d61beec3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everyone,<div>I traced pv hypercalls and found that the vector &quot;do_=
ni_hypercall&quot; is invoked a lot. But this hypercall function does nothi=
ng (from the source code). So I am very confused what is do_ni_hypercall fo=
r? Why do guests invoke it ?<br clear=3D"all">
<div>Thanks a lot,</div>-- <br>Xinxin

</div>

--f46d044287f2a5d45604d61beec3--


--===============2715370454467031495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2715370454467031495==--


From xen-devel-bounces@lists.xen.org Tue Feb 19 23:41:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 23:41: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 1U7wnn-0005J2-3G; Tue, 19 Feb 2013 23:40:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alifchits@gmail.com>) id 1U7wnl-0005Iw-F0
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 23:40:45 +0000
Received: from [85.158.143.99:17603] by server-2.bemta-4.messagelabs.com id
	CE/BA-12656-C7D04215; Tue, 19 Feb 2013 23:40:44 +0000
X-Env-Sender: alifchits@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361317243!24900956!1
X-Originating-IP: [74.125.83.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22140 invoked from network); 19 Feb 2013 23:40:43 -0000
Received: from mail-ee0-f42.google.com (HELO mail-ee0-f42.google.com)
	(74.125.83.42)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 23:40:43 -0000
Received: by mail-ee0-f42.google.com with SMTP id b47so3689518eek.15
	for <xen-devel@lists.xen.org>; Tue, 19 Feb 2013 15:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=6mBNYA5FiSNc49RXdTC7m/DekHt5ZnCnUz3SS3IzUN4=;
	b=uUTeU3X4jv6a3LBdd7ZV3pO3fBpmmQ9QtjgX63CLvCF6zp9bgPrGeVGm6DmRhowwr0
	u+YXp4aaipV+rs9XNA0Iv42N5SwYZn9JKRzXtn1t9Y1eWzVNlpDmj8ZfntVDxcmJkPL6
	V98B+m/eYSssrGZutrBOZeDYI1FgVZPgl61m3scR5/3swfv6HozXwr8hzxIS/45Omg3w
	26YKLkJ1EKZnqVdXmdgd2n2k7iHTrgug6JjU9n2sOy22IMDVPYGzFU+/VKizxqeoY6W8
	9MDWj551U5/aQKobUYLrZtLPbXMfOjBPbMGUGxqcTzmykB9E566BtgORgNoug4p+q5Dv
	5V8A==
X-Received: by 10.14.218.71 with SMTP id j47mr61834496eep.28.1361317243148;
	Tue, 19 Feb 2013 15:40:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.190.71 with HTTP; Tue, 19 Feb 2013 15:40:12 -0800 (PST)
In-Reply-To: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
From: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Tue, 19 Feb 2013 23:40:12 +0000
X-Google-Sender-Auth: fNR_9ROSF7B_EUTJ06ut0Y9vWCw
Message-ID: <CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
To: Darren Shepherd <darren.s.shepherd@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 17, 2013 at 2:30 PM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> I was wondering if someone can shed some light on why vhd files
> created with qemu-img don't really work right with vhd-util and
> consequentially blktap in general.  To validate the incompatiblity its
> simple enough to do
>
> qemu-img create -f vpc test.vhd 40g
> vhd-util snapshot -n child.vhd -p test.vhd
>
> Which will show the below and then the headers don't display the BATMAP summary:
>
> primary footer invalid: creation time in future

This is due to a bug in the blktap2 code which uses local time instead
of UTC (which is mandated by the VHD specs). I fixed it recently in
the Citrix fork of blktap
(https://github.com/xen-org/blktap/commit/a79ac2c05f97c2384bbf981419f329f184dc646a),
but unfortunately these two forks aren't really kept in sync.

> test.vhd appears invalid; dumping metadata
> Failed to open test.vhd: -22
>
> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
> you the same 22 error.
>
> I was going to start researching this with the eventual goal of
> changing qemu-img, but I thought I'd ask the experts first.
>
> Thanks,
> Darren
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 19 23:41:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 23:41: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 1U7wnn-0005J2-3G; Tue, 19 Feb 2013 23:40:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alifchits@gmail.com>) id 1U7wnl-0005Iw-F0
	for xen-devel@lists.xen.org; Tue, 19 Feb 2013 23:40:45 +0000
Received: from [85.158.143.99:17603] by server-2.bemta-4.messagelabs.com id
	CE/BA-12656-C7D04215; Tue, 19 Feb 2013 23:40:44 +0000
X-Env-Sender: alifchits@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361317243!24900956!1
X-Originating-IP: [74.125.83.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22140 invoked from network); 19 Feb 2013 23:40:43 -0000
Received: from mail-ee0-f42.google.com (HELO mail-ee0-f42.google.com)
	(74.125.83.42)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 23:40:43 -0000
Received: by mail-ee0-f42.google.com with SMTP id b47so3689518eek.15
	for <xen-devel@lists.xen.org>; Tue, 19 Feb 2013 15:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=6mBNYA5FiSNc49RXdTC7m/DekHt5ZnCnUz3SS3IzUN4=;
	b=uUTeU3X4jv6a3LBdd7ZV3pO3fBpmmQ9QtjgX63CLvCF6zp9bgPrGeVGm6DmRhowwr0
	u+YXp4aaipV+rs9XNA0Iv42N5SwYZn9JKRzXtn1t9Y1eWzVNlpDmj8ZfntVDxcmJkPL6
	V98B+m/eYSssrGZutrBOZeDYI1FgVZPgl61m3scR5/3swfv6HozXwr8hzxIS/45Omg3w
	26YKLkJ1EKZnqVdXmdgd2n2k7iHTrgug6JjU9n2sOy22IMDVPYGzFU+/VKizxqeoY6W8
	9MDWj551U5/aQKobUYLrZtLPbXMfOjBPbMGUGxqcTzmykB9E566BtgORgNoug4p+q5Dv
	5V8A==
X-Received: by 10.14.218.71 with SMTP id j47mr61834496eep.28.1361317243148;
	Tue, 19 Feb 2013 15:40:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.190.71 with HTTP; Tue, 19 Feb 2013 15:40:12 -0800 (PST)
In-Reply-To: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
From: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Tue, 19 Feb 2013 23:40:12 +0000
X-Google-Sender-Auth: fNR_9ROSF7B_EUTJ06ut0Y9vWCw
Message-ID: <CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
To: Darren Shepherd <darren.s.shepherd@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 17, 2013 at 2:30 PM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> I was wondering if someone can shed some light on why vhd files
> created with qemu-img don't really work right with vhd-util and
> consequentially blktap in general.  To validate the incompatiblity its
> simple enough to do
>
> qemu-img create -f vpc test.vhd 40g
> vhd-util snapshot -n child.vhd -p test.vhd
>
> Which will show the below and then the headers don't display the BATMAP summary:
>
> primary footer invalid: creation time in future

This is due to a bug in the blktap2 code which uses local time instead
of UTC (which is mandated by the VHD specs). I fixed it recently in
the Citrix fork of blktap
(https://github.com/xen-org/blktap/commit/a79ac2c05f97c2384bbf981419f329f184dc646a),
but unfortunately these two forks aren't really kept in sync.

> test.vhd appears invalid; dumping metadata
> Failed to open test.vhd: -22
>
> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
> you the same 22 error.
>
> I was going to start researching this with the eventual goal of
> changing qemu-img, but I thought I'd ask the experts first.
>
> Thanks,
> Darren
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 19 23:44:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 23: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 1U7wqj-0005UH-UB; Tue, 19 Feb 2013 23:43:49 +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 1U7wqi-0005UA-Vd
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 23:43:49 +0000
Received: from [85.158.138.51:25107] by server-1.bemta-3.messagelabs.com id
	70/5E-08955-43E04215; Tue, 19 Feb 2013 23:43:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361317427!28289531!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6232 invoked from network); 19 Feb 2013 23:43:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 23:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; 
   d="scan'208";a="1631211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 23:43: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.297.1; Tue, 19 Feb 2013 23:43:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7wqg-0006Mc-Pi;
	Tue, 19 Feb 2013 23:43:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7wqg-0000Vu-KG;
	Tue, 19 Feb 2013 23:43:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16213-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 23:43:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16213: 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 16213 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16213/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore     fail REGR. vs. 15418
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore   fail REGR. vs. 15418

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 linux                fe34c843d97c4fa082fe66dc3a65e7bd5603c70c
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 fe34c843d97c4fa082fe66dc3a65e7bd5603c70c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 17 10:46:34 2013 -0800

    Linux 3.0.65

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 19 23:44:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 19 Feb 2013 23: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 1U7wqj-0005UH-UB; Tue, 19 Feb 2013 23:43:49 +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 1U7wqi-0005UA-Vd
	for xen-devel@lists.xensource.com; Tue, 19 Feb 2013 23:43:49 +0000
Received: from [85.158.138.51:25107] by server-1.bemta-3.messagelabs.com id
	70/5E-08955-43E04215; Tue, 19 Feb 2013 23:43:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361317427!28289531!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6232 invoked from network); 19 Feb 2013 23:43:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Feb 2013 23:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; 
   d="scan'208";a="1631211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Feb 2013 23:43: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.297.1; Tue, 19 Feb 2013 23:43:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U7wqg-0006Mc-Pi;
	Tue, 19 Feb 2013 23:43:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U7wqg-0000Vu-KG;
	Tue, 19 Feb 2013 23:43:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16213-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 19 Feb 2013 23:43:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16213: 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 16213 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16213/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore     fail REGR. vs. 15418
 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore   fail REGR. vs. 15418

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 linux                fe34c843d97c4fa082fe66dc3a65e7bd5603c70c
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 fe34c843d97c4fa082fe66dc3a65e7bd5603c70c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 17 10:46:34 2013 -0800

    Linux 3.0.65

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 00:06:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 00:06: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 1U7xCH-0006Ek-WC; Wed, 20 Feb 2013 00:06:06 +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 1U7xCG-0006Ef-Gf
	for Xen-devel@lists.xensource.com; Wed, 20 Feb 2013 00:06:04 +0000
Received: from [193.109.254.147:14039] by server-7.bemta-14.messagelabs.com id
	81/50-13581-B6314215; Wed, 20 Feb 2013 00:06:03 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361318738!8542446!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMzNzU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8530 invoked from network); 20 Feb 2013 00:05:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 00:05:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1K05auu012109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 00:05:37 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
	r1K05ZFc021060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 00:05:36 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
	r1K05ZIZ007964; Tue, 19 Feb 2013 18:05:35 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 16:05:35 -0800
Date: Tue, 19 Feb 2013 16:05:34 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130219160534.062dba2f@mantra.us.oracle.com>
In-Reply-To: <20130124163122.GJ20551@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 Thu, 24 Jan 2013 16:31:22 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > +
> > +        case EXIT_REASON_CPUID:              /* 10 */
> > +        {
> > +            if ( guest_kernel_mode(vp, regs) ) {
> > +                pv_cpuid(regs);
> > +
> > +                /* Because we are setting CR4.OSFXSR to 0, we need
> > to disable
> > +                 * this because, during boot, user process
> > "init" (which doesn't
> > +                 * do cpuid), will do 'pxor xmm0,xmm0' and cause
> > #UD. For now 
> > +                 * disable this. HVM doesn't allow setting of
> > CR4.OSFXSR.
> > +                 * fixme: this and also look at CR4.OSXSAVE */
> > +
> > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> 
> Shouldn't this be gated on which leaf the guest asked for?

Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't work. 
The user process "init" running nash is executing pxor %xmm0, %xmm0 and
taking #UD. Strangely, it works with EAX==0, meaning if I clear the bit
for EAX==0, changing the intel string "ineI".  This user process doesn't
do cpuid, so it must be affected by it some other way.

Pretty hard to debug since it's in nash user code from ramdisk and I am 
not able to set breakpoint or put printf's easily to figure why clearing
bit for EAX==0 makes it work, or what's going on for PV and HVM guest.
CR0.EM is 0, so UD is coming from CR4.OSFXSR==0. Reading the SDMs to
learn OSFXSR stuff better....

Will continue investigating.

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 Feb 20 00:06:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 00:06: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 1U7xCH-0006Ek-WC; Wed, 20 Feb 2013 00:06:06 +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 1U7xCG-0006Ef-Gf
	for Xen-devel@lists.xensource.com; Wed, 20 Feb 2013 00:06:04 +0000
Received: from [193.109.254.147:14039] by server-7.bemta-14.messagelabs.com id
	81/50-13581-B6314215; Wed, 20 Feb 2013 00:06:03 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361318738!8542446!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMzNzU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8530 invoked from network); 20 Feb 2013 00:05:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 00:05:41 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1K05auu012109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 00:05:37 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
	r1K05ZFc021060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 00:05:36 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
	r1K05ZIZ007964; Tue, 19 Feb 2013 18:05:35 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 16:05:35 -0800
Date: Tue, 19 Feb 2013 16:05:34 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130219160534.062dba2f@mantra.us.oracle.com>
In-Reply-To: <20130124163122.GJ20551@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@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: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 Thu, 24 Jan 2013 16:31:22 +0000
Tim Deegan <tim@xen.org> wrote:

> At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > +
> > +        case EXIT_REASON_CPUID:              /* 10 */
> > +        {
> > +            if ( guest_kernel_mode(vp, regs) ) {
> > +                pv_cpuid(regs);
> > +
> > +                /* Because we are setting CR4.OSFXSR to 0, we need
> > to disable
> > +                 * this because, during boot, user process
> > "init" (which doesn't
> > +                 * do cpuid), will do 'pxor xmm0,xmm0' and cause
> > #UD. For now 
> > +                 * disable this. HVM doesn't allow setting of
> > CR4.OSFXSR.
> > +                 * fixme: this and also look at CR4.OSXSAVE */
> > +
> > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> 
> Shouldn't this be gated on which leaf the guest asked for?

Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't work. 
The user process "init" running nash is executing pxor %xmm0, %xmm0 and
taking #UD. Strangely, it works with EAX==0, meaning if I clear the bit
for EAX==0, changing the intel string "ineI".  This user process doesn't
do cpuid, so it must be affected by it some other way.

Pretty hard to debug since it's in nash user code from ramdisk and I am 
not able to set breakpoint or put printf's easily to figure why clearing
bit for EAX==0 makes it work, or what's going on for PV and HVM guest.
CR0.EM is 0, so UD is coming from CR4.OSFXSR==0. Reading the SDMs to
learn OSFXSR stuff better....

Will continue investigating.

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 Feb 20 01:18:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 01: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 1U7yJR-0002Bn-Jv; Wed, 20 Feb 2013 01:17:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7yJQ-0002Bi-1m
	for Xen-devel@lists.xen.org; Wed, 20 Feb 2013 01:17:32 +0000
Received: from [193.109.254.147:3789] by server-4.bemta-14.messagelabs.com id
	40/03-20719-B2424215; Wed, 20 Feb 2013 01:17:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361323050!9023168!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5193 invoked from network); 20 Feb 2013 01:17:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 01:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; 
   d="scan'208";a="1632643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 01:17:30 +0000
Received: from [10.30.249.68] (10.30.249.68) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Wed, 20 Feb 2013 01:17:29 +0000
Message-ID: <51242427.2070605@citrix.com>
Date: Wed, 20 Feb 2013 01:17:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Xinxin Jin <xinxinjin89@gmail.com>
References: <CAJJWZcwuPAEXQ+ou56F6jhV778R7GQmdm7C721h8avXAGJmv4A@mail.gmail.com>
In-Reply-To: <CAJJWZcwuPAEXQ+ou56F6jhV778R7GQmdm7C721h8avXAGJmv4A@mail.gmail.com>
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] What is do_ni_hypercall() for
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 23:09, Xinxin Jin wrote:
> Hi everyone,
> I traced pv hypercalls and found that the vector "do_ni_hypercall" is
> invoked a lot. But this hypercall function does nothing (from the
> source code). So I am very confused what is do_ni_hypercall for? Why
> do guests invoke it ?
> Thanks a lot,
> -- 
> Xinxin

As expected.  It is the "Not Implemented" hypercall.  This means that
your PV guest is erroneously asking for hypercalls which are in the
permitted range (0-63) but not implemented by the hypervisor.

See xen/arch/x86/x86_64/entry.S:hypercall_table

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 01:18:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 01: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 1U7yJR-0002Bn-Jv; Wed, 20 Feb 2013 01:17:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U7yJQ-0002Bi-1m
	for Xen-devel@lists.xen.org; Wed, 20 Feb 2013 01:17:32 +0000
Received: from [193.109.254.147:3789] by server-4.bemta-14.messagelabs.com id
	40/03-20719-B2424215; Wed, 20 Feb 2013 01:17:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361323050!9023168!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5193 invoked from network); 20 Feb 2013 01:17:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 01:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; 
   d="scan'208";a="1632643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 01:17:30 +0000
Received: from [10.30.249.68] (10.30.249.68) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Wed, 20 Feb 2013 01:17:29 +0000
Message-ID: <51242427.2070605@citrix.com>
Date: Wed, 20 Feb 2013 01:17:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Xinxin Jin <xinxinjin89@gmail.com>
References: <CAJJWZcwuPAEXQ+ou56F6jhV778R7GQmdm7C721h8avXAGJmv4A@mail.gmail.com>
In-Reply-To: <CAJJWZcwuPAEXQ+ou56F6jhV778R7GQmdm7C721h8avXAGJmv4A@mail.gmail.com>
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] What is do_ni_hypercall() for
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 23:09, Xinxin Jin wrote:
> Hi everyone,
> I traced pv hypercalls and found that the vector "do_ni_hypercall" is
> invoked a lot. But this hypercall function does nothing (from the
> source code). So I am very confused what is do_ni_hypercall for? Why
> do guests invoke it ?
> Thanks a lot,
> -- 
> Xinxin

As expected.  It is the "Not Implemented" hypercall.  This means that
your PV guest is erroneously asking for hypercalls which are in the
permitted range (0-63) but not implemented by the hypervisor.

See xen/arch/x86/x86_64/entry.S:hypercall_table

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 02:08:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 02: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 1U7z62-000332-Ta; Wed, 20 Feb 2013 02:07: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 1U7z61-00032v-9y
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 02:07:45 +0000
Received: from [85.158.143.35:8790] by server-1.bemta-4.messagelabs.com id
	0B/26-08839-0FF24215; Wed, 20 Feb 2013 02:07:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1361326062!4634329!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQ5Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11071 invoked from network); 20 Feb 2013 02:07:43 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 02:07:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1K27U2u017860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 02:07: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
	r1K27TMQ010297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 02:07:30 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
	r1K27TGp007909; Tue, 19 Feb 2013 20:07:29 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 18:07:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 61D2A1C03AF; Tue, 19 Feb 2013 21:07:27 -0500 (EST)
Date: Tue, 19 Feb 2013 21:07:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130220020727.GA25329@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361294951-28633-1-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: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 05:29:11PM +0000, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.

Hehe. You didn't test this, did you :-)

It hangs bootup on X86.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++++++
>  arch/x86/include/asm/xen/events.h |    3 +
>  drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
>  include/xen/interface/xen.h       |    8 +-
>  4 files changed, 94 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
>  
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +	xen_ulong_t oldval;
> +	unsigned int tmp;
> +
> +	wmb();
> +	asm volatile("@ xchg_xen_ulong\n"
> +		"1:     ldrexd  %0, %H0, [%3]\n"
> +		"       strexd  %1, %2, %H2, [%3]\n"
> +		"       teq     %1, #0\n"
> +		"       bne     1b"
> +		: "=&r" (oldval), "=&r" (tmp)
> +		: "r" (val), "r" (ptr)
> +		: "memory", "cc");
> +	return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index cc146d5..ca842f2 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->flags);
>  }
>  
> +/* No need for a barrier -- XCHG is a barrier on x86. */
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 0be4df3..b8d84f5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -80,6 +80,12 @@ enum xen_irq_type {
>  };
>  
>  /*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +
> +/*
>   * Packed IRQ information:
>   * type - enum xen_irq_type
>   * event channel - irq->event channel mapping
> @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +/*
> + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> + * careful to only use bitops which allow for this (e.g test_bit and
> + * friends but not __ffs).
> + */
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>  		      cpu_evtchn_mask);
>  
>  /* Xen will never allocate port zero for any purpose. */
> @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
>  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
>  
> -static inline unsigned long active_evtchns(unsigned int cpu,
> -					   struct shared_info *sh,
> -					   unsigned int idx)
> +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> +					 struct shared_info *sh,
> +					 unsigned int idx)
>  {
>  	return sh->evtchn_pending[idx] &
>  		per_cpu(cpu_evtchn_mask, cpu)[idx] &
> @@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>  	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
>  #endif
>  
> -	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> +	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> +	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
>  
>  	info_for_irq(irq)->cpu = cpu;
>  }
> @@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
>  static inline void clear_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_clear_bit(port, &s->evtchn_pending[0]);
> +	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline void set_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_pending[0]);
> +	sync_set_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline int test_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_bit(port, &s->evtchn_pending[0]);
> +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  
> @@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  static void mask_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_mask[0]);
> +	sync_set_bit(port, BM(&s->evtchn_mask[0]));
>  }
>  
>  static void unmask_evtchn(int port)
> @@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
>  	if (unlikely((cpu != cpu_from_evtchn(port))))
>  		do_hypercall = 1;
>  	else
> -		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> +		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  
>  	if (unlikely(evtchn_pending && xen_hvm_domain()))
>  		do_hypercall = 1;
> @@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
>  	} else {
>  		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>  
> -		sync_clear_bit(port, &s->evtchn_mask[0]);
> +		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
>  
>  		/*
>  		 * The following is basically the equivalent of
> @@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
>  		 * the interrupt edge' if the channel is masked.
>  		 */
>  		if (evtchn_pending &&
> -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> -					   &vcpu_info->evtchn_pending_sel))
> +		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> +					   BM(&vcpu_info->evtchn_pending_sel)))
>  			vcpu_info->evtchn_upcall_pending = 1;
>  	}
>  
> @@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
>  	struct shared_info *sh = HYPERVISOR_shared_info;
>  	int cpu = smp_processor_id();
> -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
>  	int i;
>  	unsigned long flags;
>  	static DEFINE_SPINLOCK(debug_lock);
> @@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		pending = (get_irq_regs() && i == cpu)
>  			? xen_irqs_disabled(get_irq_regs())
>  			: v->evtchn_upcall_mask;
> -		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> +		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
>  		       pending, v->evtchn_upcall_pending,
>  		       (int)(sizeof(v->evtchn_pending_sel)*2),
>  		       v->evtchn_pending_sel);
> @@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  
>  	printk("\npending:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)sizeof(sh->evtchn_pending[0])*2,
>  		       sh->evtchn_pending[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  	printk("\nglobal mask:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s",
> +		printk("%0*"PRI_xen_ulong"%s",
>  		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nglobally unmasked:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nlocal cpu%d mask:\n   ", cpu);
> -	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> +	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> +		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
>  		       cpu_evtchn[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nlocally unmasked:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> -		unsigned long pending = sh->evtchn_pending[i]
> +		xen_ulong_t pending = sh->evtchn_pending[i]
>  			& ~sh->evtchn_mask[i]
>  			& cpu_evtchn[i];
> -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       pending, i % 8 == 0 ? "\n   " : " ");
>  	}
>  
>  	printk("\npending list:\n");
>  	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -		if (sync_test_bit(i, sh->evtchn_pending)) {
> -			int word_idx = i / BITS_PER_LONG;
> +		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> +			int word_idx = i / BITS_PER_EVTCHN_WORD;
>  			printk("  %d: event %d -> irq %d%s%s%s\n",
>  			       cpu_from_evtchn(i), i,
>  			       evtchn_to_irq[i],
> -			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
>  					     ? "" : " l2-clear",
> -			       !sync_test_bit(i, sh->evtchn_mask)
> +			       !sync_test_bit(i, BM(sh->evtchn_mask))
>  					     ? "" : " globally-masked",
> -			       sync_test_bit(i, cpu_evtchn)
> +			       sync_test_bit(i, BM(cpu_evtchn))
>  					     ? "" : " locally-masked");
>  		}
>  	}
> @@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>  /*
>   * Mask out the i least significant bits of w
>   */
> -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
>  
>  /*
>   * Search the CPUs pending events bitmasks.  For each one found, map
> @@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
>  	unsigned count;
>  
>  	do {
> -		unsigned long pending_words;
> +		xen_ulong_t pending_words;
>  
>  		vcpu_info->evtchn_upcall_pending = 0;
>  
>  		if (__this_cpu_inc_return(xed_nesting_count) - 1)
>  			goto out;
>  
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -		/* Clear master flag /before/ clearing selector flag. */
> -		wmb();
> -#endif
> -		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +		/*
> +		 * Master flag must be /before/ clearing selector
> +		 * flag. xchg_xen_ulong must contain an appropriate
> +		 * barrier.
> +		 */
> +		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
>  
>  		start_word_idx = __this_cpu_read(current_word_idx);
>  		start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
>  		word_idx = start_word_idx;
>  
>  		for (i = 0; pending_words != 0; i++) {
> -			unsigned long pending_bits;
> -			unsigned long words;
> +			xen_ulong_t pending_bits;
> +			xen_ulong_t words;
>  
>  			words = MASK_LSBS(pending_words, word_idx);
>  
> @@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
>  				bit_idx = 0;
>  				continue;
>  			}
> -			word_idx = __ffs(words);
> +			word_idx = find_first_bit(BM(&words), sizeof(words));
>  
>  			pending_bits = active_evtchns(cpu, s, word_idx);
>  			bit_idx = 0; /* usually scan entire word from start */
> @@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
>  			}
>  
>  			do {
> -				unsigned long bits;
> +				xen_ulong_t bits;
>  				int port, irq;
>  				struct irq_desc *desc;
>  
> @@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
>  				if (bits == 0)
>  					break;
>  
> -				bit_idx = __ffs(bits);
> +				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
>  
>  				/* Process port. */
> -				port = (word_idx * BITS_PER_LONG) + bit_idx;
> +				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
>  				irq = evtchn_to_irq[port];
>  
>  				if (irq != -1) {
> @@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
>  						generic_handle_irq_desc(irq, desc);
>  				}
>  
> -				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
>  
>  				/* Next caller starts at last processed + 1 */
>  				__this_cpu_write(current_word_idx,
>  						 bit_idx ? word_idx :
> -						 (word_idx+1) % BITS_PER_LONG);
> +						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
>  				__this_cpu_write(current_bit_idx, bit_idx);
>  			} while (bit_idx != 0);
>  
> @@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
>  			if ((word_idx != start_word_idx) || (i != 0))
>  				pending_words &= ~(1UL << word_idx);
>  
> -			word_idx = (word_idx + 1) % BITS_PER_LONG;
> +			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
>  		}
>  
>  		BUG_ON(!irqs_disabled());
> @@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
>  	if (!VALID_EVTCHN(evtchn))
>  		return 1;
>  
> -	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> -	sync_set_bit(evtchn, s->evtchn_pending);
> +	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> +	sync_set_bit(evtchn, BM(s->evtchn_pending));
>  	if (!masked)
>  		unmask_evtchn(evtchn);
>  
> @@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
>  	if (VALID_EVTCHN(evtchn)) {
>  		int masked;
>  
> -		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> -		sync_set_bit(evtchn, sh->evtchn_pending);
> +		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> +		sync_set_bit(evtchn, BM(sh->evtchn_pending));
>  		if (!masked)
>  			unmask_evtchn(evtchn);
>  		ret = 1;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 5d6c272..a9075df 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>  	/*
> @@ -341,7 +341,7 @@ struct vcpu_info {
>  	 */
>  	uint8_t evtchn_upcall_pending;
>  	uint8_t evtchn_upcall_mask;
> -	unsigned long evtchn_pending_sel;
> +	xen_ulong_t evtchn_pending_sel;
>  	struct arch_vcpu_info arch;
>  	struct pvclock_vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -384,8 +384,8 @@ struct shared_info {
>  	 * per-vcpu selector word to be set. Each bit in the selector covers a
>  	 * 'C long' in the PENDING bitfield array.
>  	 */
> -	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>  	/*
>  	 * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.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 Feb 20 02:08:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 02: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 1U7z62-000332-Ta; Wed, 20 Feb 2013 02:07: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 1U7z61-00032v-9y
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 02:07:45 +0000
Received: from [85.158.143.35:8790] by server-1.bemta-4.messagelabs.com id
	0B/26-08839-0FF24215; Wed, 20 Feb 2013 02:07:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1361326062!4634329!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQ5Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11071 invoked from network); 20 Feb 2013 02:07:43 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 02:07:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1K27U2u017860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 02:07: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
	r1K27TMQ010297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 02:07:30 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
	r1K27TGp007909; Tue, 19 Feb 2013 20:07:29 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 18:07:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 61D2A1C03AF; Tue, 19 Feb 2013 21:07:27 -0500 (EST)
Date: Tue, 19 Feb 2013 21:07:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130220020727.GA25329@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361294951-28633-1-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: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 05:29:11PM +0000, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.

Hehe. You didn't test this, did you :-)

It hangs bootup on X86.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++++++
>  arch/x86/include/asm/xen/events.h |    3 +
>  drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
>  include/xen/interface/xen.h       |    8 +-
>  4 files changed, 94 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
>  
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +	xen_ulong_t oldval;
> +	unsigned int tmp;
> +
> +	wmb();
> +	asm volatile("@ xchg_xen_ulong\n"
> +		"1:     ldrexd  %0, %H0, [%3]\n"
> +		"       strexd  %1, %2, %H2, [%3]\n"
> +		"       teq     %1, #0\n"
> +		"       bne     1b"
> +		: "=&r" (oldval), "=&r" (tmp)
> +		: "r" (val), "r" (ptr)
> +		: "memory", "cc");
> +	return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index cc146d5..ca842f2 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>  	return raw_irqs_disabled_flags(regs->flags);
>  }
>  
> +/* No need for a barrier -- XCHG is a barrier on x86. */
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 0be4df3..b8d84f5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -80,6 +80,12 @@ enum xen_irq_type {
>  };
>  
>  /*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +
> +/*
>   * Packed IRQ information:
>   * type - enum xen_irq_type
>   * event channel - irq->event channel mapping
> @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +/*
> + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> + * careful to only use bitops which allow for this (e.g test_bit and
> + * friends but not __ffs).
> + */
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>  		      cpu_evtchn_mask);
>  
>  /* Xen will never allocate port zero for any purpose. */
> @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
>  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
>  
> -static inline unsigned long active_evtchns(unsigned int cpu,
> -					   struct shared_info *sh,
> -					   unsigned int idx)
> +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> +					 struct shared_info *sh,
> +					 unsigned int idx)
>  {
>  	return sh->evtchn_pending[idx] &
>  		per_cpu(cpu_evtchn_mask, cpu)[idx] &
> @@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>  	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
>  #endif
>  
> -	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> +	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> +	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
>  
>  	info_for_irq(irq)->cpu = cpu;
>  }
> @@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
>  static inline void clear_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_clear_bit(port, &s->evtchn_pending[0]);
> +	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline void set_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_pending[0]);
> +	sync_set_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  static inline int test_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	return sync_test_bit(port, &s->evtchn_pending[0]);
> +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  }
>  
>  
> @@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  static void mask_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> -	sync_set_bit(port, &s->evtchn_mask[0]);
> +	sync_set_bit(port, BM(&s->evtchn_mask[0]));
>  }
>  
>  static void unmask_evtchn(int port)
> @@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
>  	if (unlikely((cpu != cpu_from_evtchn(port))))
>  		do_hypercall = 1;
>  	else
> -		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> +		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  
>  	if (unlikely(evtchn_pending && xen_hvm_domain()))
>  		do_hypercall = 1;
> @@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
>  	} else {
>  		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>  
> -		sync_clear_bit(port, &s->evtchn_mask[0]);
> +		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
>  
>  		/*
>  		 * The following is basically the equivalent of
> @@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
>  		 * the interrupt edge' if the channel is masked.
>  		 */
>  		if (evtchn_pending &&
> -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> -					   &vcpu_info->evtchn_pending_sel))
> +		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> +					   BM(&vcpu_info->evtchn_pending_sel)))
>  			vcpu_info->evtchn_upcall_pending = 1;
>  	}
>  
> @@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
>  	struct shared_info *sh = HYPERVISOR_shared_info;
>  	int cpu = smp_processor_id();
> -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
>  	int i;
>  	unsigned long flags;
>  	static DEFINE_SPINLOCK(debug_lock);
> @@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  		pending = (get_irq_regs() && i == cpu)
>  			? xen_irqs_disabled(get_irq_regs())
>  			: v->evtchn_upcall_mask;
> -		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> +		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
>  		       pending, v->evtchn_upcall_pending,
>  		       (int)(sizeof(v->evtchn_pending_sel)*2),
>  		       v->evtchn_pending_sel);
> @@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  
>  	printk("\npending:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)sizeof(sh->evtchn_pending[0])*2,
>  		       sh->evtchn_pending[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  	printk("\nglobal mask:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s",
> +		printk("%0*"PRI_xen_ulong"%s",
>  		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nglobally unmasked:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nlocal cpu%d mask:\n   ", cpu);
> -	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> -		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> +	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> +		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
>  		       cpu_evtchn[i],
>  		       i % 8 == 0 ? "\n   " : " ");
>  
>  	printk("\nlocally unmasked:\n   ");
>  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> -		unsigned long pending = sh->evtchn_pending[i]
> +		xen_ulong_t pending = sh->evtchn_pending[i]
>  			& ~sh->evtchn_mask[i]
>  			& cpu_evtchn[i];
> -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +		printk("%0*"PRI_xen_ulong"%s",
> +		       (int)(sizeof(sh->evtchn_mask[0])*2),
>  		       pending, i % 8 == 0 ? "\n   " : " ");
>  	}
>  
>  	printk("\npending list:\n");
>  	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -		if (sync_test_bit(i, sh->evtchn_pending)) {
> -			int word_idx = i / BITS_PER_LONG;
> +		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> +			int word_idx = i / BITS_PER_EVTCHN_WORD;
>  			printk("  %d: event %d -> irq %d%s%s%s\n",
>  			       cpu_from_evtchn(i), i,
>  			       evtchn_to_irq[i],
> -			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
>  					     ? "" : " l2-clear",
> -			       !sync_test_bit(i, sh->evtchn_mask)
> +			       !sync_test_bit(i, BM(sh->evtchn_mask))
>  					     ? "" : " globally-masked",
> -			       sync_test_bit(i, cpu_evtchn)
> +			       sync_test_bit(i, BM(cpu_evtchn))
>  					     ? "" : " locally-masked");
>  		}
>  	}
> @@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>  /*
>   * Mask out the i least significant bits of w
>   */
> -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
>  
>  /*
>   * Search the CPUs pending events bitmasks.  For each one found, map
> @@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
>  	unsigned count;
>  
>  	do {
> -		unsigned long pending_words;
> +		xen_ulong_t pending_words;
>  
>  		vcpu_info->evtchn_upcall_pending = 0;
>  
>  		if (__this_cpu_inc_return(xed_nesting_count) - 1)
>  			goto out;
>  
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -		/* Clear master flag /before/ clearing selector flag. */
> -		wmb();
> -#endif
> -		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +		/*
> +		 * Master flag must be /before/ clearing selector
> +		 * flag. xchg_xen_ulong must contain an appropriate
> +		 * barrier.
> +		 */
> +		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
>  
>  		start_word_idx = __this_cpu_read(current_word_idx);
>  		start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
>  		word_idx = start_word_idx;
>  
>  		for (i = 0; pending_words != 0; i++) {
> -			unsigned long pending_bits;
> -			unsigned long words;
> +			xen_ulong_t pending_bits;
> +			xen_ulong_t words;
>  
>  			words = MASK_LSBS(pending_words, word_idx);
>  
> @@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
>  				bit_idx = 0;
>  				continue;
>  			}
> -			word_idx = __ffs(words);
> +			word_idx = find_first_bit(BM(&words), sizeof(words));
>  
>  			pending_bits = active_evtchns(cpu, s, word_idx);
>  			bit_idx = 0; /* usually scan entire word from start */
> @@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
>  			}
>  
>  			do {
> -				unsigned long bits;
> +				xen_ulong_t bits;
>  				int port, irq;
>  				struct irq_desc *desc;
>  
> @@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
>  				if (bits == 0)
>  					break;
>  
> -				bit_idx = __ffs(bits);
> +				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
>  
>  				/* Process port. */
> -				port = (word_idx * BITS_PER_LONG) + bit_idx;
> +				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
>  				irq = evtchn_to_irq[port];
>  
>  				if (irq != -1) {
> @@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
>  						generic_handle_irq_desc(irq, desc);
>  				}
>  
> -				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
>  
>  				/* Next caller starts at last processed + 1 */
>  				__this_cpu_write(current_word_idx,
>  						 bit_idx ? word_idx :
> -						 (word_idx+1) % BITS_PER_LONG);
> +						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
>  				__this_cpu_write(current_bit_idx, bit_idx);
>  			} while (bit_idx != 0);
>  
> @@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
>  			if ((word_idx != start_word_idx) || (i != 0))
>  				pending_words &= ~(1UL << word_idx);
>  
> -			word_idx = (word_idx + 1) % BITS_PER_LONG;
> +			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
>  		}
>  
>  		BUG_ON(!irqs_disabled());
> @@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
>  	if (!VALID_EVTCHN(evtchn))
>  		return 1;
>  
> -	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> -	sync_set_bit(evtchn, s->evtchn_pending);
> +	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> +	sync_set_bit(evtchn, BM(s->evtchn_pending));
>  	if (!masked)
>  		unmask_evtchn(evtchn);
>  
> @@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
>  	if (VALID_EVTCHN(evtchn)) {
>  		int masked;
>  
> -		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> -		sync_set_bit(evtchn, sh->evtchn_pending);
> +		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> +		sync_set_bit(evtchn, BM(sh->evtchn_pending));
>  		if (!masked)
>  			unmask_evtchn(evtchn);
>  		ret = 1;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 5d6c272..a9075df 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>  	/*
> @@ -341,7 +341,7 @@ struct vcpu_info {
>  	 */
>  	uint8_t evtchn_upcall_pending;
>  	uint8_t evtchn_upcall_mask;
> -	unsigned long evtchn_pending_sel;
> +	xen_ulong_t evtchn_pending_sel;
>  	struct arch_vcpu_info arch;
>  	struct pvclock_vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -384,8 +384,8 @@ struct shared_info {
>  	 * per-vcpu selector word to be set. Each bit in the selector covers a
>  	 * 'C long' in the PENDING bitfield array.
>  	 */
> -	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>  	/*
>  	 * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.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 Feb 20 02:11:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 02:11: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 1U7z8o-0003AU-No; Wed, 20 Feb 2013 02:10:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U7z8m-0003AN-6s
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 02:10:36 +0000
Received: from [85.158.139.211:7908] by server-16.bemta-5.messagelabs.com id
	7E/6A-14948-B9034215; Wed, 20 Feb 2013 02:10:35 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361326221!18263153!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDE0NzAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27120 invoked from network); 20 Feb 2013 02:10:21 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-14.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 02:10:21 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 1523BC4
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 13:10:16 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361326216; bh=qDitA3s4pBmYbJy4lKuwDGj9gccuV3g+UOm1PCPbKB8=;
	h=Date:From:To:Subject;
	b=vntIpVP5FFYzFVlYgti38uD5jXC/O8Zj4teA++vs+ZKCyNKVG9tbl/7Y3J1oKb35u
	zd2s/cSzIoS+FWvZlAFXkpA1xfLSuDptLUjC346FFPmGLgVYNYGxj44Zj/UKkguIbj
	kx30iY6nG6RqUgMZCAlKyvvOzo6/WQzKZxjzzSlM=
Message-ID: <51243089.8020307@crc.id.au>
Date: Wed, 20 Feb 2013 13:10:17 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============6982867781443144015=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6982867781443144015==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080908050302020200070204"

This is a cryptographically signed message in MIME format.

--------------ms080908050302020200070204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi guys,

Firstly, please CC me in to any replies as I'm not a subscriber these day=
s.

I've been trying to debug a problem with Xen 4.2.1 where I am unable to=20
achieve more than ~50Mb/sec sustained sequential write to a disk. The=20
DomU is configured as such:

name            =3D "zeus.vm"
memory          =3D 1024
vcpus           =3D 2
cpus            =3D "1-3"
disk            =3D [ 'phy:/dev/RAID1/zeus.vm,xvda,w',=20
'phy:/dev/vg_raid6/fileshare,xvdb,w' ]
vif             =3D [ "mac=3D02:16:36:35:35:09, bridge=3Dbr203,=20
vifname=3Dvm.zeus.203", "mac=3D10:16:36:35:35:09, bridge=3Dbr10,=20
vifname=3Dvm.zeus.10" ]
bootloader      =3D "pygrub"

on_poweroff     =3D 'destroy'
on_reboot       =3D 'restart'
on_crash        =3D 'restart'

I have tested the underlying LVM config by mounting=20
/dev/vg_raid6/fileshare from within the Dom0 and running bonnie++ as a=20
benchmark:

Version  1.96       ------Sequential Output------ --Sequential Input-=20
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20
/sec %CP
xenhost.lan.crc. 2G   667  96 186976  21 80430  14   956  95 290591  26=20
373.7   8
Latency             26416us     212ms     168ms   35494us   35989us 83759=
us
Version  1.96       ------Sequential Create------ --------Random=20
Create--------
xenhost.lan.crc.id. -Create-- --Read--- -Delete-- -Create-- --Read---=20
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=20
/sec %CP
                  16 14901  32 +++++ +++ 19672  39 15307  34 +++++ +++=20
18158  37
Latency             17838us     141us     298us     365us     133us 296us=


~186Mb/sec write, ~290Mb/sec read. Awesome.

I then started a single DomU which gets passed /dev/vg_raid6/fileshare=20
through as xvdb. It is then mounted in /mnt/fileshare/. I then ran=20
bonnie++ again in the DomU:

Version  1.96       ------Sequential Output------ --Sequential Input-=20
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20
/sec %CP
zeus.crc.id.au   2G   658  96 50618   8 42398  10  1138  99 267568  30=20
494.9  11
Latency             22959us     226ms     311ms   14617us   41816us 72814=
us
Version  1.96       ------Sequential Create------ --------Random=20
Create--------
zeus.crc.id.au      -Create-- --Read--- -Delete-- -Create-- --Read---=20
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=20
/sec %CP
                  16 21749  59 +++++ +++ 31089  73 23283  64 +++++ +++=20
31114  75
Latency             18989us     164us     928us     480us      26us  87us=


~50Mb/sec write, ~267Mb/sec read. Not so awesome.

/dev/vg_raid6/fileshare exists as an LV on /dev/md2:

# lvdisplay vg_raid6/fileshare
   --- Logical volume ---
   LV Path                /dev/vg_raid6/fileshare
   LV Name                fileshare
   VG Name                vg_raid6
   LV UUID                cwC0yK-Xr56-WB5v-10bw-3AZT-pYj0-piWett
   LV Write Access        read/write
   LV Creation host, time xenhost.lan.crc.id.au, 2013-02-18 20:59:40 +110=
0
   LV Status              available
   # open                 1
   LV Size                2.50 TiB
   Current LE             655360
   Segments               1
   Allocation             inherit
   Read ahead sectors     auto
   - currently set to     1024
   Block device           253:5


md2 : active raid6 sdd[4] sdc[0] sde[1] sdf[5]
       3907026688 blocks super 1.2 level 6, 128k chunk, algorithm 2=20
[4/4] [UUUU]

Heres a quick output of 'xm info' - although its full VM load is running =

now:
# xm info
host                   : xenhost.lan.crc.id.au
release                : 3.7.9-1.el6xen.x86_64
version                : #1 SMP Mon Feb 18 14:46:35 EST 2013
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 3303
hw_caps                :=20
bfebfbff:28100800:00000000:00003f40:179ae3bf:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8116
free_memory            : 1346
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32=20
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=3D1024M cpufreq=3Dxen dom0_max_vcpus=3D=
1=20
dom0_vcpus_pin
cc_compiler            : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
cc_compile_by          : mockbuild
cc_compile_domain      : crc.id.au
cc_compile_date        : Sat Feb 16 19:16:38 EST 2013
xend_config_format     : 4

In a nutshell, does anyone know *why* I am only able to get ~50Mb/sec=20
sequential writes to the DomU? It certainly isn't a problem getting=20
normal speeds to the LV while mounted in the Dom0.

All OS are Scientific Linux 6.3. The Dom0 runs packages from my=20
kernel-xen repo (http://au1.mirror.crc.id.au/repo/el6/x86_64/). The DomU =

is completely stock packages.

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms080908050302020200070204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAwMjEwMTdaMCMGCSqGSIb3DQEJBDEWBBS+6iFaXEipT3Hj2AzMVjyp6ZLu
jTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEATNVeiL5uMMyei1IPr1FjZ5v7
l23PCqiA6BsN9eK9gYIwVre9NZA6vDkBga6pz3cMxMJcGu4XFb1PWmq4o9gc+0wWItaCFjID
g93/8n0LO6+wMIc1GedGh6wO2DzG6xgGnVIwoBDYJVHQ/biZ+CZ8tqQ9hHqA8qf2Y3f0rR8r
5oRqOaXkBMBBKI59+g2geiA924eX7lhn73WHYJteLxvxcpPkk7SQLlPz+Ay4w76wMQv8lHaG
jLnhdUCNmOe7/iwAlg4DE7Er+ZkzKz59oZNM4nkOfurqJEXXg+sDiysLBBwshf3rCGOAGfdf
CnQ0WB9M6JCJDgHjYKGnOOu9CGQbdwAAAAAAAA==
--------------ms080908050302020200070204--


--===============6982867781443144015==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6982867781443144015==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 02:11:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 02:11: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 1U7z8o-0003AU-No; Wed, 20 Feb 2013 02:10:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U7z8m-0003AN-6s
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 02:10:36 +0000
Received: from [85.158.139.211:7908] by server-16.bemta-5.messagelabs.com id
	7E/6A-14948-B9034215; Wed, 20 Feb 2013 02:10:35 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361326221!18263153!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDE0NzAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27120 invoked from network); 20 Feb 2013 02:10:21 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-14.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 02:10:21 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 1523BC4
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 13:10:16 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361326216; bh=qDitA3s4pBmYbJy4lKuwDGj9gccuV3g+UOm1PCPbKB8=;
	h=Date:From:To:Subject;
	b=vntIpVP5FFYzFVlYgti38uD5jXC/O8Zj4teA++vs+ZKCyNKVG9tbl/7Y3J1oKb35u
	zd2s/cSzIoS+FWvZlAFXkpA1xfLSuDptLUjC346FFPmGLgVYNYGxj44Zj/UKkguIbj
	kx30iY6nG6RqUgMZCAlKyvvOzo6/WQzKZxjzzSlM=
Message-ID: <51243089.8020307@crc.id.au>
Date: Wed, 20 Feb 2013 13:10:17 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============6982867781443144015=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6982867781443144015==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080908050302020200070204"

This is a cryptographically signed message in MIME format.

--------------ms080908050302020200070204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi guys,

Firstly, please CC me in to any replies as I'm not a subscriber these day=
s.

I've been trying to debug a problem with Xen 4.2.1 where I am unable to=20
achieve more than ~50Mb/sec sustained sequential write to a disk. The=20
DomU is configured as such:

name            =3D "zeus.vm"
memory          =3D 1024
vcpus           =3D 2
cpus            =3D "1-3"
disk            =3D [ 'phy:/dev/RAID1/zeus.vm,xvda,w',=20
'phy:/dev/vg_raid6/fileshare,xvdb,w' ]
vif             =3D [ "mac=3D02:16:36:35:35:09, bridge=3Dbr203,=20
vifname=3Dvm.zeus.203", "mac=3D10:16:36:35:35:09, bridge=3Dbr10,=20
vifname=3Dvm.zeus.10" ]
bootloader      =3D "pygrub"

on_poweroff     =3D 'destroy'
on_reboot       =3D 'restart'
on_crash        =3D 'restart'

I have tested the underlying LVM config by mounting=20
/dev/vg_raid6/fileshare from within the Dom0 and running bonnie++ as a=20
benchmark:

Version  1.96       ------Sequential Output------ --Sequential Input-=20
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20
/sec %CP
xenhost.lan.crc. 2G   667  96 186976  21 80430  14   956  95 290591  26=20
373.7   8
Latency             26416us     212ms     168ms   35494us   35989us 83759=
us
Version  1.96       ------Sequential Create------ --------Random=20
Create--------
xenhost.lan.crc.id. -Create-- --Read--- -Delete-- -Create-- --Read---=20
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=20
/sec %CP
                  16 14901  32 +++++ +++ 19672  39 15307  34 +++++ +++=20
18158  37
Latency             17838us     141us     298us     365us     133us 296us=


~186Mb/sec write, ~290Mb/sec read. Awesome.

I then started a single DomU which gets passed /dev/vg_raid6/fileshare=20
through as xvdb. It is then mounted in /mnt/fileshare/. I then ran=20
bonnie++ again in the DomU:

Version  1.96       ------Sequential Output------ --Sequential Input-=20
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20
/sec %CP
zeus.crc.id.au   2G   658  96 50618   8 42398  10  1138  99 267568  30=20
494.9  11
Latency             22959us     226ms     311ms   14617us   41816us 72814=
us
Version  1.96       ------Sequential Create------ --------Random=20
Create--------
zeus.crc.id.au      -Create-- --Read--- -Delete-- -Create-- --Read---=20
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=20
/sec %CP
                  16 21749  59 +++++ +++ 31089  73 23283  64 +++++ +++=20
31114  75
Latency             18989us     164us     928us     480us      26us  87us=


~50Mb/sec write, ~267Mb/sec read. Not so awesome.

/dev/vg_raid6/fileshare exists as an LV on /dev/md2:

# lvdisplay vg_raid6/fileshare
   --- Logical volume ---
   LV Path                /dev/vg_raid6/fileshare
   LV Name                fileshare
   VG Name                vg_raid6
   LV UUID                cwC0yK-Xr56-WB5v-10bw-3AZT-pYj0-piWett
   LV Write Access        read/write
   LV Creation host, time xenhost.lan.crc.id.au, 2013-02-18 20:59:40 +110=
0
   LV Status              available
   # open                 1
   LV Size                2.50 TiB
   Current LE             655360
   Segments               1
   Allocation             inherit
   Read ahead sectors     auto
   - currently set to     1024
   Block device           253:5


md2 : active raid6 sdd[4] sdc[0] sde[1] sdf[5]
       3907026688 blocks super 1.2 level 6, 128k chunk, algorithm 2=20
[4/4] [UUUU]

Heres a quick output of 'xm info' - although its full VM load is running =

now:
# xm info
host                   : xenhost.lan.crc.id.au
release                : 3.7.9-1.el6xen.x86_64
version                : #1 SMP Mon Feb 18 14:46:35 EST 2013
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 3303
hw_caps                :=20
bfebfbff:28100800:00000000:00003f40:179ae3bf:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8116
free_memory            : 1346
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32=20
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=3D1024M cpufreq=3Dxen dom0_max_vcpus=3D=
1=20
dom0_vcpus_pin
cc_compiler            : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
cc_compile_by          : mockbuild
cc_compile_domain      : crc.id.au
cc_compile_date        : Sat Feb 16 19:16:38 EST 2013
xend_config_format     : 4

In a nutshell, does anyone know *why* I am only able to get ~50Mb/sec=20
sequential writes to the DomU? It certainly isn't a problem getting=20
normal speeds to the LV while mounted in the Dom0.

All OS are Scientific Linux 6.3. The Dom0 runs packages from my=20
kernel-xen repo (http://au1.mirror.crc.id.au/repo/el6/x86_64/). The DomU =

is completely stock packages.

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms080908050302020200070204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAwMjEwMTdaMCMGCSqGSIb3DQEJBDEWBBS+6iFaXEipT3Hj2AzMVjyp6ZLu
jTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEATNVeiL5uMMyei1IPr1FjZ5v7
l23PCqiA6BsN9eK9gYIwVre9NZA6vDkBga6pz3cMxMJcGu4XFb1PWmq4o9gc+0wWItaCFjID
g93/8n0LO6+wMIc1GedGh6wO2DzG6xgGnVIwoBDYJVHQ/biZ+CZ8tqQ9hHqA8qf2Y3f0rR8r
5oRqOaXkBMBBKI59+g2geiA924eX7lhn73WHYJteLxvxcpPkk7SQLlPz+Ay4w76wMQv8lHaG
jLnhdUCNmOe7/iwAlg4DE7Er+ZkzKz59oZNM4nkOfurqJEXXg+sDiysLBBwshf3rCGOAGfdf
CnQ0WB9M6JCJDgHjYKGnOOu9CGQbdwAAAAAAAA==
--------------ms080908050302020200070204--


--===============6982867781443144015==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6982867781443144015==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 03:10:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U804G-0003lq-FE; Wed, 20 Feb 2013 03:10: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 1U804F-0003ll-K2
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 03:09:59 +0000
Received: from [193.109.254.147:26189] by server-6.bemta-14.messagelabs.com id
	8E/95-12010-68E34215; Wed, 20 Feb 2013 03:09:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361329795!3848312!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMzNzU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2470 invoked from network); 20 Feb 2013 03:09:56 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 03:09:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1K39k1S028383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 03:09:47 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
	r1K39jg6006646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 03:09:46 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
	r1K39jZo006651; Tue, 19 Feb 2013 21:09:45 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 19:09:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9370E1C03AF; Tue, 19 Feb 2013 22:09:43 -0500 (EST)
Date: Tue, 19 Feb 2013 22:09:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130220030943.GA28092@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
	<20130220020727.GA25329@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130220020727.GA25329@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 09:07:27PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 05:29:11PM +0000, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> 
> Hehe. You didn't test this, did you :-)
> 
> It hangs bootup on X86.

Ah wait. The version that hangs was the first posted - I hadn't
tested this one yet. I will wait until later on Wednesday to do that.


> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: xen-devel@lists.xen.org
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > Changes since V3
> >   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > Changes since V2
> >   Add comments about the correct bitops to use, and on the ordering/barrier
> >   requirements on xchg_xen_ulong.
> > Changes since V1
> >   use find_first_set not __ffs
> >   fix some more unsigned long -> xen_ulong_t
> >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> > ---
> >  arch/arm/include/asm/xen/events.h |   22 +++++++
> >  arch/x86/include/asm/xen/events.h |    3 +
> >  drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
> >  include/xen/interface/xen.h       |    8 +-
> >  4 files changed, 94 insertions(+), 52 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..5c27696 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
> >  }
> >  
> > +/*
> > + * We cannot use xchg because it does not support 8-byte
> > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > + * platforms which Xen can run on support those instructions.
> > + */
> > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > +{
> > +	xen_ulong_t oldval;
> > +	unsigned int tmp;
> > +
> > +	wmb();
> > +	asm volatile("@ xchg_xen_ulong\n"
> > +		"1:     ldrexd  %0, %H0, [%3]\n"
> > +		"       strexd  %1, %2, %H2, [%3]\n"
> > +		"       teq     %1, #0\n"
> > +		"       bne     1b"
> > +		: "=&r" (oldval), "=&r" (tmp)
> > +		: "r" (val), "r" (ptr)
> > +		: "memory", "cc");
> > +	return oldval;
> > +}
> > +
> >  #endif /* _ASM_ARM_XEN_EVENTS_H */
> > diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> > index cc146d5..ca842f2 100644
> > --- a/arch/x86/include/asm/xen/events.h
> > +++ b/arch/x86/include/asm/xen/events.h
> > @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >  	return raw_irqs_disabled_flags(regs->flags);
> >  }
> >  
> > +/* No need for a barrier -- XCHG is a barrier on x86. */
> > +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> > +
> >  #endif /* _ASM_X86_XEN_EVENTS_H */
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 0be4df3..b8d84f5 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -80,6 +80,12 @@ enum xen_irq_type {
> >  };
> >  
> >  /*
> > + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> > + * array. Primarily to avoid long lines (hence the terse name).
> > + */
> > +#define BM(x) (unsigned long *)(x)
> > +
> > +/*
> >   * Packed IRQ information:
> >   * type - enum xen_irq_type
> >   * event channel - irq->event channel mapping
> > @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
> >  #endif
> >  static bool (*pirq_needs_eoi)(unsigned irq);
> >  
> > -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > +/*
> > + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> > + * careful to only use bitops which allow for this (e.g test_bit and
> > + * friends but not __ffs).
> > + */
> > +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> > +
> > +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
> >  		      cpu_evtchn_mask);
> >  
> >  /* Xen will never allocate port zero for any purpose. */
> > @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> >  }
> >  
> > -static inline unsigned long active_evtchns(unsigned int cpu,
> > -					   struct shared_info *sh,
> > -					   unsigned int idx)
> > +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> > +					 struct shared_info *sh,
> > +					 unsigned int idx)
> >  {
> >  	return sh->evtchn_pending[idx] &
> >  		per_cpu(cpu_evtchn_mask, cpu)[idx] &
> > @@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> >  	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
> >  #endif
> >  
> > -	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> > -	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> > +	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> > +	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
> >  
> >  	info_for_irq(irq)->cpu = cpu;
> >  }
> > @@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
> >  static inline void clear_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	sync_clear_bit(port, &s->evtchn_pending[0]);
> > +	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> >  static inline void set_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	sync_set_bit(port, &s->evtchn_pending[0]);
> > +	sync_set_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> >  static inline int test_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	return sync_test_bit(port, &s->evtchn_pending[0]);
> > +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> >  
> > @@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
> >  static void mask_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	sync_set_bit(port, &s->evtchn_mask[0]);
> > +	sync_set_bit(port, BM(&s->evtchn_mask[0]));
> >  }
> >  
> >  static void unmask_evtchn(int port)
> > @@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
> >  	if (unlikely((cpu != cpu_from_evtchn(port))))
> >  		do_hypercall = 1;
> >  	else
> > -		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> > +		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
> >  
> >  	if (unlikely(evtchn_pending && xen_hvm_domain()))
> >  		do_hypercall = 1;
> > @@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
> >  	} else {
> >  		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> >  
> > -		sync_clear_bit(port, &s->evtchn_mask[0]);
> > +		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> >  
> >  		/*
> >  		 * The following is basically the equivalent of
> > @@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
> >  		 * the interrupt edge' if the channel is masked.
> >  		 */
> >  		if (evtchn_pending &&
> > -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> > -					   &vcpu_info->evtchn_pending_sel))
> > +		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> > +					   BM(&vcpu_info->evtchn_pending_sel)))
> >  			vcpu_info->evtchn_upcall_pending = 1;
> >  	}
> >  
> > @@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> >  {
> >  	struct shared_info *sh = HYPERVISOR_shared_info;
> >  	int cpu = smp_processor_id();
> > -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > +	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> >  	int i;
> >  	unsigned long flags;
> >  	static DEFINE_SPINLOCK(debug_lock);
> > @@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> >  		pending = (get_irq_regs() && i == cpu)
> >  			? xen_irqs_disabled(get_irq_regs())
> >  			: v->evtchn_upcall_mask;
> > -		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> > +		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
> >  		       pending, v->evtchn_upcall_pending,
> >  		       (int)(sizeof(v->evtchn_pending_sel)*2),
> >  		       v->evtchn_pending_sel);
> > @@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> >  
> >  	printk("\npending:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> > -		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> > +		printk("%0*"PRI_xen_ulong"%s",
> > +		       (int)sizeof(sh->evtchn_pending[0])*2,
> >  		       sh->evtchn_pending[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  	printk("\nglobal mask:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > -		printk("%0*lx%s",
> > +		printk("%0*"PRI_xen_ulong"%s",
> >  		       (int)(sizeof(sh->evtchn_mask[0])*2),
> >  		       sh->evtchn_mask[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  
> >  	printk("\nglobally unmasked:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > +		printk("%0*"PRI_xen_ulong"%s",
> > +		       (int)(sizeof(sh->evtchn_mask[0])*2),
> >  		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  
> >  	printk("\nlocal cpu%d mask:\n   ", cpu);
> > -	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> > -		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> > +	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> > +		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
> >  		       cpu_evtchn[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  
> >  	printk("\nlocally unmasked:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> > -		unsigned long pending = sh->evtchn_pending[i]
> > +		xen_ulong_t pending = sh->evtchn_pending[i]
> >  			& ~sh->evtchn_mask[i]
> >  			& cpu_evtchn[i];
> > -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > +		printk("%0*"PRI_xen_ulong"%s",
> > +		       (int)(sizeof(sh->evtchn_mask[0])*2),
> >  		       pending, i % 8 == 0 ? "\n   " : " ");
> >  	}
> >  
> >  	printk("\npending list:\n");
> >  	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> > -		if (sync_test_bit(i, sh->evtchn_pending)) {
> > -			int word_idx = i / BITS_PER_LONG;
> > +		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> > +			int word_idx = i / BITS_PER_EVTCHN_WORD;
> >  			printk("  %d: event %d -> irq %d%s%s%s\n",
> >  			       cpu_from_evtchn(i), i,
> >  			       evtchn_to_irq[i],
> > -			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
> >  					     ? "" : " l2-clear",
> > -			       !sync_test_bit(i, sh->evtchn_mask)
> > +			       !sync_test_bit(i, BM(sh->evtchn_mask))
> >  					     ? "" : " globally-masked",
> > -			       sync_test_bit(i, cpu_evtchn)
> > +			       sync_test_bit(i, BM(cpu_evtchn))
> >  					     ? "" : " locally-masked");
> >  		}
> >  	}
> > @@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
> >  /*
> >   * Mask out the i least significant bits of w
> >   */
> > -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> > +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
> >  
> >  /*
> >   * Search the CPUs pending events bitmasks.  For each one found, map
> > @@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
> >  	unsigned count;
> >  
> >  	do {
> > -		unsigned long pending_words;
> > +		xen_ulong_t pending_words;
> >  
> >  		vcpu_info->evtchn_upcall_pending = 0;
> >  
> >  		if (__this_cpu_inc_return(xed_nesting_count) - 1)
> >  			goto out;
> >  
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > -		/* Clear master flag /before/ clearing selector flag. */
> > -		wmb();
> > -#endif
> > -		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > +		/*
> > +		 * Master flag must be /before/ clearing selector
> > +		 * flag. xchg_xen_ulong must contain an appropriate
> > +		 * barrier.
> > +		 */
> > +		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> >  
> >  		start_word_idx = __this_cpu_read(current_word_idx);
> >  		start_bit_idx = __this_cpu_read(current_bit_idx);
> > @@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
> >  		word_idx = start_word_idx;
> >  
> >  		for (i = 0; pending_words != 0; i++) {
> > -			unsigned long pending_bits;
> > -			unsigned long words;
> > +			xen_ulong_t pending_bits;
> > +			xen_ulong_t words;
> >  
> >  			words = MASK_LSBS(pending_words, word_idx);
> >  
> > @@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
> >  				bit_idx = 0;
> >  				continue;
> >  			}
> > -			word_idx = __ffs(words);
> > +			word_idx = find_first_bit(BM(&words), sizeof(words));
> >  
> >  			pending_bits = active_evtchns(cpu, s, word_idx);
> >  			bit_idx = 0; /* usually scan entire word from start */
> > @@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
> >  			}
> >  
> >  			do {
> > -				unsigned long bits;
> > +				xen_ulong_t bits;
> >  				int port, irq;
> >  				struct irq_desc *desc;
> >  
> > @@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
> >  				if (bits == 0)
> >  					break;
> >  
> > -				bit_idx = __ffs(bits);
> > +				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
> >  
> >  				/* Process port. */
> > -				port = (word_idx * BITS_PER_LONG) + bit_idx;
> > +				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
> >  				irq = evtchn_to_irq[port];
> >  
> >  				if (irq != -1) {
> > @@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
> >  						generic_handle_irq_desc(irq, desc);
> >  				}
> >  
> > -				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> > +				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
> >  
> >  				/* Next caller starts at last processed + 1 */
> >  				__this_cpu_write(current_word_idx,
> >  						 bit_idx ? word_idx :
> > -						 (word_idx+1) % BITS_PER_LONG);
> > +						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
> >  				__this_cpu_write(current_bit_idx, bit_idx);
> >  			} while (bit_idx != 0);
> >  
> > @@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
> >  			if ((word_idx != start_word_idx) || (i != 0))
> >  				pending_words &= ~(1UL << word_idx);
> >  
> > -			word_idx = (word_idx + 1) % BITS_PER_LONG;
> > +			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
> >  		}
> >  
> >  		BUG_ON(!irqs_disabled());
> > @@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
> >  	if (!VALID_EVTCHN(evtchn))
> >  		return 1;
> >  
> > -	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> > -	sync_set_bit(evtchn, s->evtchn_pending);
> > +	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> > +	sync_set_bit(evtchn, BM(s->evtchn_pending));
> >  	if (!masked)
> >  		unmask_evtchn(evtchn);
> >  
> > @@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
> >  	if (VALID_EVTCHN(evtchn)) {
> >  		int masked;
> >  
> > -		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> > -		sync_set_bit(evtchn, sh->evtchn_pending);
> > +		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> > +		sync_set_bit(evtchn, BM(sh->evtchn_pending));
> >  		if (!masked)
> >  			unmask_evtchn(evtchn);
> >  		ret = 1;
> > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > index 5d6c272..a9075df 100644
> > --- a/include/xen/interface/xen.h
> > +++ b/include/xen/interface/xen.h
> > @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> >   * Event channel endpoints per domain:
> >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> >   */
> > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
> >  
> >  struct vcpu_time_info {
> >  	/*
> > @@ -341,7 +341,7 @@ struct vcpu_info {
> >  	 */
> >  	uint8_t evtchn_upcall_pending;
> >  	uint8_t evtchn_upcall_mask;
> > -	unsigned long evtchn_pending_sel;
> > +	xen_ulong_t evtchn_pending_sel;
> >  	struct arch_vcpu_info arch;
> >  	struct pvclock_vcpu_time_info time;
> >  }; /* 64 bytes (x86) */
> > @@ -384,8 +384,8 @@ struct shared_info {
> >  	 * per-vcpu selector word to be set. Each bit in the selector covers a
> >  	 * 'C long' in the PENDING bitfield array.
> >  	 */
> > -	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> > -	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> > +	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> > +	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
> >  
> >  	/*
> >  	 * Wallclock time: updated only by control software. Guests should base
> > -- 
> > 1.7.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 Feb 20 03:10:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U804G-0003lq-FE; Wed, 20 Feb 2013 03:10: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 1U804F-0003ll-K2
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 03:09:59 +0000
Received: from [193.109.254.147:26189] by server-6.bemta-14.messagelabs.com id
	8E/95-12010-68E34215; Wed, 20 Feb 2013 03:09:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361329795!3848312!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjMzNzU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2470 invoked from network); 20 Feb 2013 03:09:56 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 03:09:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1K39k1S028383
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 03:09:47 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
	r1K39jg6006646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 03:09:46 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
	r1K39jZo006651; Tue, 19 Feb 2013 21:09:45 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 19 Feb 2013 19:09:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9370E1C03AF; Tue, 19 Feb 2013 22:09:43 -0500 (EST)
Date: Tue, 19 Feb 2013 22:09:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130220030943.GA28092@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
	<20130220020727.GA25329@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130220020727.GA25329@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 19, 2013 at 09:07:27PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 05:29:11PM +0000, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> > 
> > This is an ABI change on ARM. X86 does not change.
> 
> Hehe. You didn't test this, did you :-)
> 
> It hangs bootup on X86.

Ah wait. The version that hangs was the first posted - I hadn't
tested this one yet. I will wait until later on Wednesday to do that.


> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Beulich <JBeulich@suse.com>
> > Cc: Keir (Xen.org) <keir@xen.org>
> > Cc: Tim Deegan <tim@xen.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: xen-devel@lists.xen.org
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > Changes since V3
> >   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > Changes since V2
> >   Add comments about the correct bitops to use, and on the ordering/barrier
> >   requirements on xchg_xen_ulong.
> > Changes since V1
> >   use find_first_set not __ffs
> >   fix some more unsigned long -> xen_ulong_t
> >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> > ---
> >  arch/arm/include/asm/xen/events.h |   22 +++++++
> >  arch/x86/include/asm/xen/events.h |    3 +
> >  drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
> >  include/xen/interface/xen.h       |    8 +-
> >  4 files changed, 94 insertions(+), 52 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..5c27696 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >  	return raw_irqs_disabled_flags(regs->ARM_cpsr);
> >  }
> >  
> > +/*
> > + * We cannot use xchg because it does not support 8-byte
> > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > + * platforms which Xen can run on support those instructions.
> > + */
> > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > +{
> > +	xen_ulong_t oldval;
> > +	unsigned int tmp;
> > +
> > +	wmb();
> > +	asm volatile("@ xchg_xen_ulong\n"
> > +		"1:     ldrexd  %0, %H0, [%3]\n"
> > +		"       strexd  %1, %2, %H2, [%3]\n"
> > +		"       teq     %1, #0\n"
> > +		"       bne     1b"
> > +		: "=&r" (oldval), "=&r" (tmp)
> > +		: "r" (val), "r" (ptr)
> > +		: "memory", "cc");
> > +	return oldval;
> > +}
> > +
> >  #endif /* _ASM_ARM_XEN_EVENTS_H */
> > diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> > index cc146d5..ca842f2 100644
> > --- a/arch/x86/include/asm/xen/events.h
> > +++ b/arch/x86/include/asm/xen/events.h
> > @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> >  	return raw_irqs_disabled_flags(regs->flags);
> >  }
> >  
> > +/* No need for a barrier -- XCHG is a barrier on x86. */
> > +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> > +
> >  #endif /* _ASM_X86_XEN_EVENTS_H */
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 0be4df3..b8d84f5 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -80,6 +80,12 @@ enum xen_irq_type {
> >  };
> >  
> >  /*
> > + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> > + * array. Primarily to avoid long lines (hence the terse name).
> > + */
> > +#define BM(x) (unsigned long *)(x)
> > +
> > +/*
> >   * Packed IRQ information:
> >   * type - enum xen_irq_type
> >   * event channel - irq->event channel mapping
> > @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
> >  #endif
> >  static bool (*pirq_needs_eoi)(unsigned irq);
> >  
> > -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > +/*
> > + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> > + * careful to only use bitops which allow for this (e.g test_bit and
> > + * friends but not __ffs).
> > + */
> > +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> > +
> > +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
> >  		      cpu_evtchn_mask);
> >  
> >  /* Xen will never allocate port zero for any purpose. */
> > @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> >  }
> >  
> > -static inline unsigned long active_evtchns(unsigned int cpu,
> > -					   struct shared_info *sh,
> > -					   unsigned int idx)
> > +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> > +					 struct shared_info *sh,
> > +					 unsigned int idx)
> >  {
> >  	return sh->evtchn_pending[idx] &
> >  		per_cpu(cpu_evtchn_mask, cpu)[idx] &
> > @@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> >  	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
> >  #endif
> >  
> > -	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> > -	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> > +	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> > +	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
> >  
> >  	info_for_irq(irq)->cpu = cpu;
> >  }
> > @@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
> >  static inline void clear_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	sync_clear_bit(port, &s->evtchn_pending[0]);
> > +	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> >  static inline void set_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	sync_set_bit(port, &s->evtchn_pending[0]);
> > +	sync_set_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> >  static inline int test_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	return sync_test_bit(port, &s->evtchn_pending[0]);
> > +	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
> >  }
> >  
> >  
> > @@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
> >  static void mask_evtchn(int port)
> >  {
> >  	struct shared_info *s = HYPERVISOR_shared_info;
> > -	sync_set_bit(port, &s->evtchn_mask[0]);
> > +	sync_set_bit(port, BM(&s->evtchn_mask[0]));
> >  }
> >  
> >  static void unmask_evtchn(int port)
> > @@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
> >  	if (unlikely((cpu != cpu_from_evtchn(port))))
> >  		do_hypercall = 1;
> >  	else
> > -		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> > +		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
> >  
> >  	if (unlikely(evtchn_pending && xen_hvm_domain()))
> >  		do_hypercall = 1;
> > @@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
> >  	} else {
> >  		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> >  
> > -		sync_clear_bit(port, &s->evtchn_mask[0]);
> > +		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> >  
> >  		/*
> >  		 * The following is basically the equivalent of
> > @@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
> >  		 * the interrupt edge' if the channel is masked.
> >  		 */
> >  		if (evtchn_pending &&
> > -		    !sync_test_and_set_bit(port / BITS_PER_LONG,
> > -					   &vcpu_info->evtchn_pending_sel))
> > +		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> > +					   BM(&vcpu_info->evtchn_pending_sel)))
> >  			vcpu_info->evtchn_upcall_pending = 1;
> >  	}
> >  
> > @@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> >  {
> >  	struct shared_info *sh = HYPERVISOR_shared_info;
> >  	int cpu = smp_processor_id();
> > -	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > +	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> >  	int i;
> >  	unsigned long flags;
> >  	static DEFINE_SPINLOCK(debug_lock);
> > @@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> >  		pending = (get_irq_regs() && i == cpu)
> >  			? xen_irqs_disabled(get_irq_regs())
> >  			: v->evtchn_upcall_mask;
> > -		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> > +		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
> >  		       pending, v->evtchn_upcall_pending,
> >  		       (int)(sizeof(v->evtchn_pending_sel)*2),
> >  		       v->evtchn_pending_sel);
> > @@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> >  
> >  	printk("\npending:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> > -		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> > +		printk("%0*"PRI_xen_ulong"%s",
> > +		       (int)sizeof(sh->evtchn_pending[0])*2,
> >  		       sh->evtchn_pending[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  	printk("\nglobal mask:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > -		printk("%0*lx%s",
> > +		printk("%0*"PRI_xen_ulong"%s",
> >  		       (int)(sizeof(sh->evtchn_mask[0])*2),
> >  		       sh->evtchn_mask[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  
> >  	printk("\nglobally unmasked:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > +		printk("%0*"PRI_xen_ulong"%s",
> > +		       (int)(sizeof(sh->evtchn_mask[0])*2),
> >  		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  
> >  	printk("\nlocal cpu%d mask:\n   ", cpu);
> > -	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> > -		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> > +	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> > +		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
> >  		       cpu_evtchn[i],
> >  		       i % 8 == 0 ? "\n   " : " ");
> >  
> >  	printk("\nlocally unmasked:\n   ");
> >  	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> > -		unsigned long pending = sh->evtchn_pending[i]
> > +		xen_ulong_t pending = sh->evtchn_pending[i]
> >  			& ~sh->evtchn_mask[i]
> >  			& cpu_evtchn[i];
> > -		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > +		printk("%0*"PRI_xen_ulong"%s",
> > +		       (int)(sizeof(sh->evtchn_mask[0])*2),
> >  		       pending, i % 8 == 0 ? "\n   " : " ");
> >  	}
> >  
> >  	printk("\npending list:\n");
> >  	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> > -		if (sync_test_bit(i, sh->evtchn_pending)) {
> > -			int word_idx = i / BITS_PER_LONG;
> > +		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> > +			int word_idx = i / BITS_PER_EVTCHN_WORD;
> >  			printk("  %d: event %d -> irq %d%s%s%s\n",
> >  			       cpu_from_evtchn(i), i,
> >  			       evtchn_to_irq[i],
> > -			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > +			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
> >  					     ? "" : " l2-clear",
> > -			       !sync_test_bit(i, sh->evtchn_mask)
> > +			       !sync_test_bit(i, BM(sh->evtchn_mask))
> >  					     ? "" : " globally-masked",
> > -			       sync_test_bit(i, cpu_evtchn)
> > +			       sync_test_bit(i, BM(cpu_evtchn))
> >  					     ? "" : " locally-masked");
> >  		}
> >  	}
> > @@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
> >  /*
> >   * Mask out the i least significant bits of w
> >   */
> > -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> > +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
> >  
> >  /*
> >   * Search the CPUs pending events bitmasks.  For each one found, map
> > @@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
> >  	unsigned count;
> >  
> >  	do {
> > -		unsigned long pending_words;
> > +		xen_ulong_t pending_words;
> >  
> >  		vcpu_info->evtchn_upcall_pending = 0;
> >  
> >  		if (__this_cpu_inc_return(xed_nesting_count) - 1)
> >  			goto out;
> >  
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > -		/* Clear master flag /before/ clearing selector flag. */
> > -		wmb();
> > -#endif
> > -		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > +		/*
> > +		 * Master flag must be /before/ clearing selector
> > +		 * flag. xchg_xen_ulong must contain an appropriate
> > +		 * barrier.
> > +		 */
> > +		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> >  
> >  		start_word_idx = __this_cpu_read(current_word_idx);
> >  		start_bit_idx = __this_cpu_read(current_bit_idx);
> > @@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
> >  		word_idx = start_word_idx;
> >  
> >  		for (i = 0; pending_words != 0; i++) {
> > -			unsigned long pending_bits;
> > -			unsigned long words;
> > +			xen_ulong_t pending_bits;
> > +			xen_ulong_t words;
> >  
> >  			words = MASK_LSBS(pending_words, word_idx);
> >  
> > @@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
> >  				bit_idx = 0;
> >  				continue;
> >  			}
> > -			word_idx = __ffs(words);
> > +			word_idx = find_first_bit(BM(&words), sizeof(words));
> >  
> >  			pending_bits = active_evtchns(cpu, s, word_idx);
> >  			bit_idx = 0; /* usually scan entire word from start */
> > @@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
> >  			}
> >  
> >  			do {
> > -				unsigned long bits;
> > +				xen_ulong_t bits;
> >  				int port, irq;
> >  				struct irq_desc *desc;
> >  
> > @@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
> >  				if (bits == 0)
> >  					break;
> >  
> > -				bit_idx = __ffs(bits);
> > +				bit_idx = find_first_bit(BM(&bits), sizeof(bits));
> >  
> >  				/* Process port. */
> > -				port = (word_idx * BITS_PER_LONG) + bit_idx;
> > +				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
> >  				irq = evtchn_to_irq[port];
> >  
> >  				if (irq != -1) {
> > @@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
> >  						generic_handle_irq_desc(irq, desc);
> >  				}
> >  
> > -				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> > +				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
> >  
> >  				/* Next caller starts at last processed + 1 */
> >  				__this_cpu_write(current_word_idx,
> >  						 bit_idx ? word_idx :
> > -						 (word_idx+1) % BITS_PER_LONG);
> > +						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
> >  				__this_cpu_write(current_bit_idx, bit_idx);
> >  			} while (bit_idx != 0);
> >  
> > @@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
> >  			if ((word_idx != start_word_idx) || (i != 0))
> >  				pending_words &= ~(1UL << word_idx);
> >  
> > -			word_idx = (word_idx + 1) % BITS_PER_LONG;
> > +			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
> >  		}
> >  
> >  		BUG_ON(!irqs_disabled());
> > @@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
> >  	if (!VALID_EVTCHN(evtchn))
> >  		return 1;
> >  
> > -	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> > -	sync_set_bit(evtchn, s->evtchn_pending);
> > +	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> > +	sync_set_bit(evtchn, BM(s->evtchn_pending));
> >  	if (!masked)
> >  		unmask_evtchn(evtchn);
> >  
> > @@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
> >  	if (VALID_EVTCHN(evtchn)) {
> >  		int masked;
> >  
> > -		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> > -		sync_set_bit(evtchn, sh->evtchn_pending);
> > +		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> > +		sync_set_bit(evtchn, BM(sh->evtchn_pending));
> >  		if (!masked)
> >  			unmask_evtchn(evtchn);
> >  		ret = 1;
> > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > index 5d6c272..a9075df 100644
> > --- a/include/xen/interface/xen.h
> > +++ b/include/xen/interface/xen.h
> > @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> >   * Event channel endpoints per domain:
> >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> >   */
> > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
> >  
> >  struct vcpu_time_info {
> >  	/*
> > @@ -341,7 +341,7 @@ struct vcpu_info {
> >  	 */
> >  	uint8_t evtchn_upcall_pending;
> >  	uint8_t evtchn_upcall_mask;
> > -	unsigned long evtchn_pending_sel;
> > +	xen_ulong_t evtchn_pending_sel;
> >  	struct arch_vcpu_info arch;
> >  	struct pvclock_vcpu_time_info time;
> >  }; /* 64 bytes (x86) */
> > @@ -384,8 +384,8 @@ struct shared_info {
> >  	 * per-vcpu selector word to be set. Each bit in the selector covers a
> >  	 * 'C long' in the PENDING bitfield array.
> >  	 */
> > -	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> > -	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> > +	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> > +	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
> >  
> >  	/*
> >  	 * Wallclock time: updated only by control software. Guests should base
> > -- 
> > 1.7.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 Feb 20 05:08:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 05:08: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 1U81ui-0004vA-2m; Wed, 20 Feb 2013 05:08: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 1U81ug-0004v5-5p
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 05:08:14 +0000
Received: from [85.158.137.99:55254] by server-14.bemta-3.messagelabs.com id
	59/C3-23533-D3A54215; Wed, 20 Feb 2013 05:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361336892!16244402!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15907 invoked from network); 20 Feb 2013 05:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 05:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1635522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 05: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.297.1; Wed, 20 Feb 2013 05:08:12 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U81ud-00083S-J3;
	Wed, 20 Feb 2013 05:08:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U81ud-0002Pi-DB;
	Wed, 20 Feb 2013 05:08:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16214-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Feb 2013 05:08:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16214: 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 16214 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16214/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16209
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16209
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16209

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  66f563be41d9
baseline version:
 xen                  620e5d3aa7cd

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=66f563be41d9
+ . 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 66f563be41d9
+ branch=xen-unstable
+ revision=66f563be41d9
+ . 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/hg/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 66f563be41d9 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 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 05:08:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 05:08: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 1U81ui-0004vA-2m; Wed, 20 Feb 2013 05:08: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 1U81ug-0004v5-5p
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 05:08:14 +0000
Received: from [85.158.137.99:55254] by server-14.bemta-3.messagelabs.com id
	59/C3-23533-D3A54215; Wed, 20 Feb 2013 05:08:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361336892!16244402!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15907 invoked from network); 20 Feb 2013 05:08:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 05:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1635522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 05: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.297.1; Wed, 20 Feb 2013 05:08:12 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U81ud-00083S-J3;
	Wed, 20 Feb 2013 05:08:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U81ud-0002Pi-DB;
	Wed, 20 Feb 2013 05:08:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16214-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Feb 2013 05:08:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16214: 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 16214 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16214/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16209
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16209
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16209

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  66f563be41d9
baseline version:
 xen                  620e5d3aa7cd

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@oracle.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=66f563be41d9
+ . 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 66f563be41d9
+ branch=xen-unstable
+ revision=66f563be41d9
+ . 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/hg/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 66f563be41d9 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 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 07:42:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 07:42: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 1U84Js-0006IK-9p; Wed, 20 Feb 2013 07:42:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1U84Jr-0006IF-77
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 07:42:23 +0000
Received: from [193.109.254.147:39934] by server-2.bemta-14.messagelabs.com id
	AC/28-16277-E5E74215; Wed, 20 Feb 2013 07:42:22 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361346137!8987025!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDIxMDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1495 invoked from network); 20 Feb 2013 07:42:19 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 07:42:19 -0000
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id EC6A23EE0BC
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id D2EC045DE59
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id B053145DE54
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 72AEA1DB804F
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from g01jpexchyt10.g01.fujitsu.local
	(g01jpexchyt10.g01.fujitsu.local [10.128.194.49])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1C48C1DB804C
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from [10.33.110.145] (10.33.110.145) by
	g01jpexchyt10.g01.fujitsu.local (10.128.194.49) with Microsoft SMTP
	Server (TLS) id 14.2.309.2; Wed, 20 Feb 2013 16:42:14 +0900
Message-ID: <51247E56.4060904@jp.fujitsu.com>
Date: Wed, 20 Feb 2013 16:42:14 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
	<511A42E902000078000BDB5E@nat28.tlf.novell.com>
	<511C7FB7.90907@jp.fujitsu.com>
	<511E742A02000078000BEDAE@nat28.tlf.novell.com>
In-Reply-To: <511E742A02000078000BEDAE@nat28.tlf.novell.com>
X-Originating-IP: [10.33.110.145]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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 02/16/2013 01:45 AM, Jan Beulich wrote:
>>>> On 14.02.13 at 07:09, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>> @@ -244,21 +245,13 @@ static int handle_pmt_io(
>> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
>> {
>>      PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>> -    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>>      int rc;
>>
>>      spin_lock(&s->lock);
>>
>> -    /* Update the counter to the guest's current time.  We always save
>> -     * with the domain paused, so the saved time should be after the
>> -     * last_gtime, but just in case, make sure we only go forwards */
>
> So you lose this property of guaranteeing no backward move.

Exactly.
But the backward move is impossible except delay_for_missed_ticks mode.
Since the monotonicity of hvm_get_guest_time() is guaranteed for other modes.
About the problem of delay_for_missed_ticks mode, I slightly mentioned
in the previous mail.

The backward move can be happend as the following:
1) pt_freeze_time     ... real-time:100 guest-time:100   last_gtime:90
2) pmt_timer_callback ... real-time:110 guest-time:110   last_gtime:110
3) pt_thaw_time       ... real-time:120 guest-time:100   last_gtime:110
4) pmt_update_time    ... real-time:125 guest-time:105 < last_gtime:110

So, it can be happend not only in pmtimer_save() but also
in handle_pmt_io().

Maybe pmt_udpate_time() should check the backward move.


>
>> -    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>> -    if ( x < 1UL<<31 )
>> -        s->pm.tmr_val += x;
>> -    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>> -        s->pm.pm1a_sts |= TMR_STS;
>>      /* No point in setting the SCI here because we'll already have saved the
>>       * IRQ and *PIC state; we'll fix it up when we restore the domain */
>> +    pmt_update_time(s, 0);
>
> And using this function you also have the new side effect of
> s->last_gtime being updated.
>
> Perhaps the new parameter should be renamed (to, say,
> "saving"), and then allow suppressing all these behavioral
> changes.


The new side effect is also a bug fix, I think.
Since updating s->pm.tmr_val and s->last_gtime should be
done at the same time. Updating only s->pm.tmr_val is wrong.
Or else, when the vm is resumed on the same machine (migration failure,
check-pointing, etc), the PM-timer value is double counted.


>
> Also, in delay_for_missed_ticks mode you now use a slightly
> different time for updating s->pm - did you double check that
> this is not going to be a problem? Or else, the flag above could
> similarly be used to circumvent this, or hvm_get_guest_time()
> could be made return the frozen time (I suppose, but didn't
> verify - as it appears to be an assumption already before your
> patch -, that pt_freeze_time() runs before pmtimer_save()).

Modifying hvm_get_guest_time() is my thought, too.
But I don't like the idea because the delay_for_missed_ticks mode
is unusual. I wonder who uses it.

Let me think it over.

Thanks,
Kouya


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 07:42:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 07:42: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 1U84Js-0006IK-9p; Wed, 20 Feb 2013 07:42:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kouya@jp.fujitsu.com>) id 1U84Jr-0006IF-77
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 07:42:23 +0000
Received: from [193.109.254.147:39934] by server-2.bemta-14.messagelabs.com id
	AC/28-16277-E5E74215; Wed, 20 Feb 2013 07:42:22 +0000
X-Env-Sender: kouya@jp.fujitsu.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361346137!8987025!1
X-Originating-IP: [192.51.44.35]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjUxLjQ0LjM1ID0+IDIxMDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1495 invoked from network); 20 Feb 2013 07:42:19 -0000
Received: from fgwmail5.fujitsu.co.jp (HELO fgwmail5.fujitsu.co.jp)
	(192.51.44.35)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 07:42:19 -0000
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71])
	by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id EC6A23EE0BC
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id D2EC045DE59
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id B053145DE54
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 72AEA1DB804F
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from g01jpexchyt10.g01.fujitsu.local
	(g01jpexchyt10.g01.fujitsu.local [10.128.194.49])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1C48C1DB804C
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 16:42:15 +0900 (JST)
Received: from [10.33.110.145] (10.33.110.145) by
	g01jpexchyt10.g01.fujitsu.local (10.128.194.49) with Microsoft SMTP
	Server (TLS) id 14.2.309.2; Wed, 20 Feb 2013 16:42:14 +0900
Message-ID: <51247E56.4060904@jp.fujitsu.com>
Date: Wed, 20 Feb 2013 16:42:14 +0900
From: Kouya Shimura <kouya@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5110A2DD.1080603@jp.fujitsu.com>
	<511A42E902000078000BDB5E@nat28.tlf.novell.com>
	<511C7FB7.90907@jp.fujitsu.com>
	<511E742A02000078000BEDAE@nat28.tlf.novell.com>
In-Reply-To: <511E742A02000078000BEDAE@nat28.tlf.novell.com>
X-Originating-IP: [10.33.110.145]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/hvm: fix corrupt ACPI PM-Timer during
 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 02/16/2013 01:45 AM, Jan Beulich wrote:
>>>> On 14.02.13 at 07:09, Kouya Shimura <kouya@jp.fujitsu.com> wrote:
>> @@ -244,21 +245,13 @@ static int handle_pmt_io(
>> static int pmtimer_save(struct domain *d, hvm_domain_context_t *h)
>> {
>>      PMTState *s = &d->arch.hvm_domain.pl_time.vpmt;
>> -    uint32_t x, msb = s->pm.tmr_val & TMR_VAL_MSB;
>>      int rc;
>>
>>      spin_lock(&s->lock);
>>
>> -    /* Update the counter to the guest's current time.  We always save
>> -     * with the domain paused, so the saved time should be after the
>> -     * last_gtime, but just in case, make sure we only go forwards */
>
> So you lose this property of guaranteeing no backward move.

Exactly.
But the backward move is impossible except delay_for_missed_ticks mode.
Since the monotonicity of hvm_get_guest_time() is guaranteed for other modes.
About the problem of delay_for_missed_ticks mode, I slightly mentioned
in the previous mail.

The backward move can be happend as the following:
1) pt_freeze_time     ... real-time:100 guest-time:100   last_gtime:90
2) pmt_timer_callback ... real-time:110 guest-time:110   last_gtime:110
3) pt_thaw_time       ... real-time:120 guest-time:100   last_gtime:110
4) pmt_update_time    ... real-time:125 guest-time:105 < last_gtime:110

So, it can be happend not only in pmtimer_save() but also
in handle_pmt_io().

Maybe pmt_udpate_time() should check the backward move.


>
>> -    x = ((s->vcpu->arch.hvm_vcpu.guest_time - s->last_gtime) * s->scale) >> 32;
>> -    if ( x < 1UL<<31 )
>> -        s->pm.tmr_val += x;
>> -    if ( (s->pm.tmr_val & TMR_VAL_MSB) != msb )
>> -        s->pm.pm1a_sts |= TMR_STS;
>>      /* No point in setting the SCI here because we'll already have saved the
>>       * IRQ and *PIC state; we'll fix it up when we restore the domain */
>> +    pmt_update_time(s, 0);
>
> And using this function you also have the new side effect of
> s->last_gtime being updated.
>
> Perhaps the new parameter should be renamed (to, say,
> "saving"), and then allow suppressing all these behavioral
> changes.


The new side effect is also a bug fix, I think.
Since updating s->pm.tmr_val and s->last_gtime should be
done at the same time. Updating only s->pm.tmr_val is wrong.
Or else, when the vm is resumed on the same machine (migration failure,
check-pointing, etc), the PM-timer value is double counted.


>
> Also, in delay_for_missed_ticks mode you now use a slightly
> different time for updating s->pm - did you double check that
> this is not going to be a problem? Or else, the flag above could
> similarly be used to circumvent this, or hvm_get_guest_time()
> could be made return the frozen time (I suppose, but didn't
> verify - as it appears to be an assumption already before your
> patch -, that pt_freeze_time() runs before pmtimer_save()).

Modifying hvm_get_guest_time() is my thought, too.
But I don't like the idea because the delay_for_missed_ticks mode
is unusual. I wonder who uses it.

Let me think it over.

Thanks,
Kouya


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 08:28:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 08:28: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 1U852F-00077I-Bs; Wed, 20 Feb 2013 08:28: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 1U852D-00077D-AX
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 08:28:13 +0000
Received: from [193.109.254.147:48086] by server-4.bemta-14.messagelabs.com id
	6B/05-20719-C1984215; Wed, 20 Feb 2013 08:28:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361348883!9073973!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTExNjggKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21921 invoked from network); 20 Feb 2013 08:28:03 -0000
Received: from unknown (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 08:28:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1639913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 08:25:50 +0000
Received: from Roger-2.local (10.150.17.232) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Wed, 20 Feb 2013 08:25:48 +0000
Message-ID: <512488AC.1020702@citrix.com>
Date: Wed, 20 Feb 2013 09:26:20 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Steven Haigh <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au>
In-Reply-To: <51243089.8020307@crc.id.au>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20/02/13 03:10, Steven Haigh wrote:
> Hi guys,
> 
> Firstly, please CC me in to any replies as I'm not a subscriber these days.
> 
> I've been trying to debug a problem with Xen 4.2.1 where I am unable to 
> achieve more than ~50Mb/sec sustained sequential write to a disk. The 
> DomU is configured as such:

Since you mention 4.2.1 explicitly, is this a performance regression
from previous versions? (4.2.0 or the 4.1 branch)

> name            = "zeus.vm"
> memory          = 1024
> vcpus           = 2
> cpus            = "1-3"
> disk            = [ 'phy:/dev/RAID1/zeus.vm,xvda,w', 
> 'phy:/dev/vg_raid6/fileshare,xvdb,w' ]
> vif             = [ "mac=02:16:36:35:35:09, bridge=br203, 
> vifname=vm.zeus.203", "mac=10:16:36:35:35:09, bridge=br10, 
> vifname=vm.zeus.10" ]
> bootloader      = "pygrub"
> 
> on_poweroff     = 'destroy'
> on_reboot       = 'restart'
> on_crash        = 'restart'
> 
> I have tested the underlying LVM config by mounting 
> /dev/vg_raid6/fileshare from within the Dom0 and running bonnie++ as a 
> benchmark:
> 
> Version  1.96       ------Sequential Output------ --Sequential Input- 
> --Random-
> Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
> /sec %CP
> xenhost.lan.crc. 2G   667  96 186976  21 80430  14   956  95 290591  26 
> 373.7   8
> Latency             26416us     212ms     168ms   35494us   35989us 83759us
> Version  1.96       ------Sequential Create------ --------Random 
> Create--------
> xenhost.lan.crc.id. -Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
>                files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
> /sec %CP
>                   16 14901  32 +++++ +++ 19672  39 15307  34 +++++ +++ 
> 18158  37
> Latency             17838us     141us     298us     365us     133us 296us
> 
> ~186Mb/sec write, ~290Mb/sec read. Awesome.
> 
> I then started a single DomU which gets passed /dev/vg_raid6/fileshare 
> through as xvdb. It is then mounted in /mnt/fileshare/. I then ran 
> bonnie++ again in the DomU:
> 
> Version  1.96       ------Sequential Output------ --Sequential Input- 
> --Random-
> Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
> /sec %CP
> zeus.crc.id.au   2G   658  96 50618   8 42398  10  1138  99 267568  30 
> 494.9  11
> Latency             22959us     226ms     311ms   14617us   41816us 72814us
> Version  1.96       ------Sequential Create------ --------Random 
> Create--------
> zeus.crc.id.au      -Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
>                files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
> /sec %CP
>                   16 21749  59 +++++ +++ 31089  73 23283  64 +++++ +++ 
> 31114  75
> Latency             18989us     164us     928us     480us      26us  87us
> 
> ~50Mb/sec write, ~267Mb/sec read. Not so awesome.

We are currently working on improving the speed of pv block drivers, I
will look into this difference between the read/write speed, but I would
guess this is due to the size of the request/ring.

> 
> /dev/vg_raid6/fileshare exists as an LV on /dev/md2:
> 
> # lvdisplay vg_raid6/fileshare
>    --- Logical volume ---
>    LV Path                /dev/vg_raid6/fileshare
>    LV Name                fileshare
>    VG Name                vg_raid6
>    LV UUID                cwC0yK-Xr56-WB5v-10bw-3AZT-pYj0-piWett
>    LV Write Access        read/write
>    LV Creation host, time xenhost.lan.crc.id.au, 2013-02-18 20:59:40 +1100
>    LV Status              available
>    # open                 1
>    LV Size                2.50 TiB
>    Current LE             655360
>    Segments               1
>    Allocation             inherit
>    Read ahead sectors     auto
>    - currently set to     1024
>    Block device           253:5
> 
> 
> md2 : active raid6 sdd[4] sdc[0] sde[1] sdf[5]
>        3907026688 blocks super 1.2 level 6, 128k chunk, algorithm 2 
> [4/4] [UUUU]
> 
> Heres a quick output of 'xm info' - although its full VM load is running 
> now:
> # xm info
> host                   : xenhost.lan.crc.id.au
> release                : 3.7.9-1.el6xen.x86_64
> version                : #1 SMP Mon Feb 18 14:46:35 EST 2013
> machine                : x86_64
> nr_cpus                : 4
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 1
> cpu_mhz                : 3303
> hw_caps                : 
> bfebfbff:28100800:00000000:00003f40:179ae3bf:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 8116
> free_memory            : 1346
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 2
> 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        : dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 
> dom0_vcpus_pin
> cc_compiler            : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
> cc_compile_by          : mockbuild
> cc_compile_domain      : crc.id.au
> cc_compile_date        : Sat Feb 16 19:16:38 EST 2013
> xend_config_format     : 4
> 
> In a nutshell, does anyone know *why* I am only able to get ~50Mb/sec 
> sequential writes to the DomU? It certainly isn't a problem getting 
> normal speeds to the LV while mounted in the Dom0.
> 
> All OS are Scientific Linux 6.3. The Dom0 runs packages from my 
> kernel-xen repo (http://au1.mirror.crc.id.au/repo/el6/x86_64/). The DomU 
> is completely stock packages.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 08:28:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 08:28: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 1U852F-00077I-Bs; Wed, 20 Feb 2013 08:28: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 1U852D-00077D-AX
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 08:28:13 +0000
Received: from [193.109.254.147:48086] by server-4.bemta-14.messagelabs.com id
	6B/05-20719-C1984215; Wed, 20 Feb 2013 08:28:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361348883!9073973!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyNjcx\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNTExNjggKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21921 invoked from network); 20 Feb 2013 08:28:03 -0000
Received: from unknown (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 08:28:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1639913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 08:25:50 +0000
Received: from Roger-2.local (10.150.17.232) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Wed, 20 Feb 2013 08:25:48 +0000
Message-ID: <512488AC.1020702@citrix.com>
Date: Wed, 20 Feb 2013 09:26:20 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Steven Haigh <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au>
In-Reply-To: <51243089.8020307@crc.id.au>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20/02/13 03:10, Steven Haigh wrote:
> Hi guys,
> 
> Firstly, please CC me in to any replies as I'm not a subscriber these days.
> 
> I've been trying to debug a problem with Xen 4.2.1 where I am unable to 
> achieve more than ~50Mb/sec sustained sequential write to a disk. The 
> DomU is configured as such:

Since you mention 4.2.1 explicitly, is this a performance regression
from previous versions? (4.2.0 or the 4.1 branch)

> name            = "zeus.vm"
> memory          = 1024
> vcpus           = 2
> cpus            = "1-3"
> disk            = [ 'phy:/dev/RAID1/zeus.vm,xvda,w', 
> 'phy:/dev/vg_raid6/fileshare,xvdb,w' ]
> vif             = [ "mac=02:16:36:35:35:09, bridge=br203, 
> vifname=vm.zeus.203", "mac=10:16:36:35:35:09, bridge=br10, 
> vifname=vm.zeus.10" ]
> bootloader      = "pygrub"
> 
> on_poweroff     = 'destroy'
> on_reboot       = 'restart'
> on_crash        = 'restart'
> 
> I have tested the underlying LVM config by mounting 
> /dev/vg_raid6/fileshare from within the Dom0 and running bonnie++ as a 
> benchmark:
> 
> Version  1.96       ------Sequential Output------ --Sequential Input- 
> --Random-
> Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
> /sec %CP
> xenhost.lan.crc. 2G   667  96 186976  21 80430  14   956  95 290591  26 
> 373.7   8
> Latency             26416us     212ms     168ms   35494us   35989us 83759us
> Version  1.96       ------Sequential Create------ --------Random 
> Create--------
> xenhost.lan.crc.id. -Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
>                files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
> /sec %CP
>                   16 14901  32 +++++ +++ 19672  39 15307  34 +++++ +++ 
> 18158  37
> Latency             17838us     141us     298us     365us     133us 296us
> 
> ~186Mb/sec write, ~290Mb/sec read. Awesome.
> 
> I then started a single DomU which gets passed /dev/vg_raid6/fileshare 
> through as xvdb. It is then mounted in /mnt/fileshare/. I then ran 
> bonnie++ again in the DomU:
> 
> Version  1.96       ------Sequential Output------ --Sequential Input- 
> --Random-
> Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
> /sec %CP
> zeus.crc.id.au   2G   658  96 50618   8 42398  10  1138  99 267568  30 
> 494.9  11
> Latency             22959us     226ms     311ms   14617us   41816us 72814us
> Version  1.96       ------Sequential Create------ --------Random 
> Create--------
> zeus.crc.id.au      -Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
>                files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
> /sec %CP
>                   16 21749  59 +++++ +++ 31089  73 23283  64 +++++ +++ 
> 31114  75
> Latency             18989us     164us     928us     480us      26us  87us
> 
> ~50Mb/sec write, ~267Mb/sec read. Not so awesome.

We are currently working on improving the speed of pv block drivers, I
will look into this difference between the read/write speed, but I would
guess this is due to the size of the request/ring.

> 
> /dev/vg_raid6/fileshare exists as an LV on /dev/md2:
> 
> # lvdisplay vg_raid6/fileshare
>    --- Logical volume ---
>    LV Path                /dev/vg_raid6/fileshare
>    LV Name                fileshare
>    VG Name                vg_raid6
>    LV UUID                cwC0yK-Xr56-WB5v-10bw-3AZT-pYj0-piWett
>    LV Write Access        read/write
>    LV Creation host, time xenhost.lan.crc.id.au, 2013-02-18 20:59:40 +1100
>    LV Status              available
>    # open                 1
>    LV Size                2.50 TiB
>    Current LE             655360
>    Segments               1
>    Allocation             inherit
>    Read ahead sectors     auto
>    - currently set to     1024
>    Block device           253:5
> 
> 
> md2 : active raid6 sdd[4] sdc[0] sde[1] sdf[5]
>        3907026688 blocks super 1.2 level 6, 128k chunk, algorithm 2 
> [4/4] [UUUU]
> 
> Heres a quick output of 'xm info' - although its full VM load is running 
> now:
> # xm info
> host                   : xenhost.lan.crc.id.au
> release                : 3.7.9-1.el6xen.x86_64
> version                : #1 SMP Mon Feb 18 14:46:35 EST 2013
> machine                : x86_64
> nr_cpus                : 4
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 1
> cpu_mhz                : 3303
> hw_caps                : 
> bfebfbff:28100800:00000000:00003f40:179ae3bf:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 8116
> free_memory            : 1346
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 2
> 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        : dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 
> dom0_vcpus_pin
> cc_compiler            : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
> cc_compile_by          : mockbuild
> cc_compile_domain      : crc.id.au
> cc_compile_date        : Sat Feb 16 19:16:38 EST 2013
> xend_config_format     : 4
> 
> In a nutshell, does anyone know *why* I am only able to get ~50Mb/sec 
> sequential writes to the DomU? It certainly isn't a problem getting 
> normal speeds to the LV while mounted in the Dom0.
> 
> All OS are Scientific Linux 6.3. The Dom0 runs packages from my 
> kernel-xen repo (http://au1.mirror.crc.id.au/repo/el6/x86_64/). The DomU 
> is completely stock packages.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 08:38:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 08: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 1U85BY-0007Jh-Ib; Wed, 20 Feb 2013 08:37:52 +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 1U85BW-0007Jc-Sr
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 08:37:51 +0000
Received: from [85.158.137.99:51101] by server-1.bemta-3.messagelabs.com id
	30/1F-08955-95B84215; Wed, 20 Feb 2013 08:37:45 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361349444!12407553!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27852 invoked from network); 20 Feb 2013 08:37:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 08:37:24 -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 r1K8bGMC005529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 03:37:16 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-43.ams2.redhat.com
	[10.36.116.43])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1K8bDMs007564; Wed, 20 Feb 2013 03:37:13 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id A9F2741BEE; Wed, 20 Feb 2013 09:37:12 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed, 20 Feb 2013 09:37:12 +0100
Message-Id: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mark.cave-ayland@ilande.co.uk, agraf@suse.de,
	qemu-stable@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2] vga: fix byteswapping.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

In case host and guest endianness differ the vga code first creates
a shared surface (using qemu_create_displaysurface_from), then goes
patch the surface format to indicate that the bytes must be swapped.

The switch to pixman broke that hack as the format patching isn't
propagated into the pixman image, so ui code using the pixman image
directly (such as vnc) uses the wrong format.

Fix that by adding a byteswap parameter to
qemu_create_displaysurface_from, so we'll use the correct format
when creating the surface (and the pixman image) and don't have
to patch the format afterwards.

[ v2: unbreak xen build ]

Cc: qemu-stable@nongnu.org
Cc: mark.cave-ayland@ilande.co.uk
Cc: agraf@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/qxl-render.c      |    3 ++-
 hw/vga.c             |   18 ++++++++----------
 hw/vmware_vga.c      |    2 +-
 hw/xenfb.c           |    3 ++-
 include/ui/console.h |    3 ++-
 ui/console.c         |    9 +++++++--
 6 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/hw/qxl-render.c b/hw/qxl-render.c
index 88e63f8..455fb91 100644
--- a/hw/qxl-render.c
+++ b/hw/qxl-render.c
@@ -118,7 +118,8 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice *qxl)
                  qxl->guest_primary.surface.height,
                  qxl->guest_primary.bits_pp,
                  qxl->guest_primary.abs_stride,
-                 qxl->guest_primary.data);
+                 qxl->guest_primary.data,
+                 false);
         } else {
             qemu_resize_displaysurface(vga->ds,
                     qxl->guest_primary.surface.width,
diff --git a/hw/vga.c b/hw/vga.c
index e2ba7f2..1caf23d 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1643,6 +1643,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
     uint8_t *d;
     uint32_t v, addr1, addr;
     vga_draw_line_func *vga_draw_line;
+#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
+    static const bool byteswap = false;
+#else
+    static const bool byteswap = true;
+#endif
 
     full_update |= update_basic_params(s);
 
@@ -1685,18 +1690,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
         disp_width != s->last_width ||
         height != s->last_height ||
         s->last_depth != depth) {
-#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
-        if (depth == 16 || depth == 32) {
-#else
-        if (depth == 32) {
-#endif
+        if (depth == 32 || (depth == 16 && !byteswap)) {
             qemu_free_displaysurface(s->ds);
             s->ds->surface = qemu_create_displaysurface_from(disp_width, height, depth,
                     s->line_offset,
-                    s->vram_ptr + (s->start_addr * 4));
-#if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
-            s->ds->surface->pf = qemu_different_endianness_pixelformat(depth);
-#endif
+                    s->vram_ptr + (s->start_addr * 4), byteswap);
             dpy_gfx_resize(s->ds);
         } else {
             qemu_console_resize(s->ds, disp_width, height);
@@ -1715,7 +1713,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
         s->ds->surface = qemu_create_displaysurface_from(disp_width,
                 height, depth,
                 s->line_offset,
-                s->vram_ptr + (s->start_addr * 4));
+                s->vram_ptr + (s->start_addr * 4), byteswap);
         dpy_gfx_setdata(s->ds);
     }
 
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index cd15ee4..8fc201b 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1074,7 +1074,7 @@ static void vmsvga_screen_dump(void *opaque, const char *filename, bool cswitch,
                                  ds_get_height(s->vga.ds),
                                  32,
                                  ds_get_linesize(s->vga.ds),
-                                 s->vga.vram_ptr);
+                                 s->vga.vram_ptr, false);
         ppm_save(filename, ds, errp);
         g_free(ds);
     }
diff --git a/hw/xenfb.c b/hw/xenfb.c
index 903efd3..7f1f6b4 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -756,7 +756,8 @@ static void xenfb_update(void *opaque)
             qemu_free_displaysurface(xenfb->c.ds);
             xenfb->c.ds->surface = qemu_create_displaysurface_from
                 (xenfb->width, xenfb->height, xenfb->depth,
-                 xenfb->row_stride, xenfb->pixels + xenfb->offset);
+                 xenfb->row_stride, xenfb->pixels + xenfb->offset,
+                 false);
             break;
         default:
             /* we must convert stuff */
diff --git a/include/ui/console.h b/include/ui/console.h
index fc23baa..18012f1 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -184,7 +184,8 @@ struct DisplayState {
 void register_displaystate(DisplayState *ds);
 DisplayState *get_displaystate(void);
 DisplaySurface* qemu_create_displaysurface_from(int width, int height, int bpp,
-                                                int linesize, uint8_t *data);
+                                                int linesize, uint8_t *data,
+                                                bool byteswap);
 PixelFormat qemu_different_endianness_pixelformat(int bpp);
 PixelFormat qemu_default_pixelformat(int bpp);
 
diff --git a/ui/console.c b/ui/console.c
index 0a68836..25e06a5 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1339,11 +1339,16 @@ DisplaySurface *qemu_resize_displaysurface(DisplayState *ds,
 }
 
 DisplaySurface *qemu_create_displaysurface_from(int width, int height, int bpp,
-                                                int linesize, uint8_t *data)
+                                                int linesize, uint8_t *data,
+                                                bool byteswap)
 {
     DisplaySurface *surface = g_new0(DisplaySurface, 1);
 
-    surface->pf = qemu_default_pixelformat(bpp);
+    if (byteswap) {
+        surface->pf = qemu_different_endianness_pixelformat(bpp);
+    } else {
+        surface->pf = qemu_default_pixelformat(bpp);
+    }
 
     surface->format = qemu_pixman_get_format(&surface->pf);
     assert(surface->format != 0);
-- 
1.7.9.7


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 08:38:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 08: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 1U85BY-0007Jh-Ib; Wed, 20 Feb 2013 08:37:52 +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 1U85BW-0007Jc-Sr
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 08:37:51 +0000
Received: from [85.158.137.99:51101] by server-1.bemta-3.messagelabs.com id
	30/1F-08955-95B84215; Wed, 20 Feb 2013 08:37:45 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361349444!12407553!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27852 invoked from network); 20 Feb 2013 08:37:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 08:37:24 -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 r1K8bGMC005529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 03:37:16 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-43.ams2.redhat.com
	[10.36.116.43])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1K8bDMs007564; Wed, 20 Feb 2013 03:37:13 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id A9F2741BEE; Wed, 20 Feb 2013 09:37:12 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Wed, 20 Feb 2013 09:37:12 +0100
Message-Id: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mark.cave-ayland@ilande.co.uk, agraf@suse.de,
	qemu-stable@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2] vga: fix byteswapping.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

In case host and guest endianness differ the vga code first creates
a shared surface (using qemu_create_displaysurface_from), then goes
patch the surface format to indicate that the bytes must be swapped.

The switch to pixman broke that hack as the format patching isn't
propagated into the pixman image, so ui code using the pixman image
directly (such as vnc) uses the wrong format.

Fix that by adding a byteswap parameter to
qemu_create_displaysurface_from, so we'll use the correct format
when creating the surface (and the pixman image) and don't have
to patch the format afterwards.

[ v2: unbreak xen build ]

Cc: qemu-stable@nongnu.org
Cc: mark.cave-ayland@ilande.co.uk
Cc: agraf@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/qxl-render.c      |    3 ++-
 hw/vga.c             |   18 ++++++++----------
 hw/vmware_vga.c      |    2 +-
 hw/xenfb.c           |    3 ++-
 include/ui/console.h |    3 ++-
 ui/console.c         |    9 +++++++--
 6 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/hw/qxl-render.c b/hw/qxl-render.c
index 88e63f8..455fb91 100644
--- a/hw/qxl-render.c
+++ b/hw/qxl-render.c
@@ -118,7 +118,8 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice *qxl)
                  qxl->guest_primary.surface.height,
                  qxl->guest_primary.bits_pp,
                  qxl->guest_primary.abs_stride,
-                 qxl->guest_primary.data);
+                 qxl->guest_primary.data,
+                 false);
         } else {
             qemu_resize_displaysurface(vga->ds,
                     qxl->guest_primary.surface.width,
diff --git a/hw/vga.c b/hw/vga.c
index e2ba7f2..1caf23d 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1643,6 +1643,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
     uint8_t *d;
     uint32_t v, addr1, addr;
     vga_draw_line_func *vga_draw_line;
+#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
+    static const bool byteswap = false;
+#else
+    static const bool byteswap = true;
+#endif
 
     full_update |= update_basic_params(s);
 
@@ -1685,18 +1690,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
         disp_width != s->last_width ||
         height != s->last_height ||
         s->last_depth != depth) {
-#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
-        if (depth == 16 || depth == 32) {
-#else
-        if (depth == 32) {
-#endif
+        if (depth == 32 || (depth == 16 && !byteswap)) {
             qemu_free_displaysurface(s->ds);
             s->ds->surface = qemu_create_displaysurface_from(disp_width, height, depth,
                     s->line_offset,
-                    s->vram_ptr + (s->start_addr * 4));
-#if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
-            s->ds->surface->pf = qemu_different_endianness_pixelformat(depth);
-#endif
+                    s->vram_ptr + (s->start_addr * 4), byteswap);
             dpy_gfx_resize(s->ds);
         } else {
             qemu_console_resize(s->ds, disp_width, height);
@@ -1715,7 +1713,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
         s->ds->surface = qemu_create_displaysurface_from(disp_width,
                 height, depth,
                 s->line_offset,
-                s->vram_ptr + (s->start_addr * 4));
+                s->vram_ptr + (s->start_addr * 4), byteswap);
         dpy_gfx_setdata(s->ds);
     }
 
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index cd15ee4..8fc201b 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1074,7 +1074,7 @@ static void vmsvga_screen_dump(void *opaque, const char *filename, bool cswitch,
                                  ds_get_height(s->vga.ds),
                                  32,
                                  ds_get_linesize(s->vga.ds),
-                                 s->vga.vram_ptr);
+                                 s->vga.vram_ptr, false);
         ppm_save(filename, ds, errp);
         g_free(ds);
     }
diff --git a/hw/xenfb.c b/hw/xenfb.c
index 903efd3..7f1f6b4 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -756,7 +756,8 @@ static void xenfb_update(void *opaque)
             qemu_free_displaysurface(xenfb->c.ds);
             xenfb->c.ds->surface = qemu_create_displaysurface_from
                 (xenfb->width, xenfb->height, xenfb->depth,
-                 xenfb->row_stride, xenfb->pixels + xenfb->offset);
+                 xenfb->row_stride, xenfb->pixels + xenfb->offset,
+                 false);
             break;
         default:
             /* we must convert stuff */
diff --git a/include/ui/console.h b/include/ui/console.h
index fc23baa..18012f1 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -184,7 +184,8 @@ struct DisplayState {
 void register_displaystate(DisplayState *ds);
 DisplayState *get_displaystate(void);
 DisplaySurface* qemu_create_displaysurface_from(int width, int height, int bpp,
-                                                int linesize, uint8_t *data);
+                                                int linesize, uint8_t *data,
+                                                bool byteswap);
 PixelFormat qemu_different_endianness_pixelformat(int bpp);
 PixelFormat qemu_default_pixelformat(int bpp);
 
diff --git a/ui/console.c b/ui/console.c
index 0a68836..25e06a5 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1339,11 +1339,16 @@ DisplaySurface *qemu_resize_displaysurface(DisplayState *ds,
 }
 
 DisplaySurface *qemu_create_displaysurface_from(int width, int height, int bpp,
-                                                int linesize, uint8_t *data)
+                                                int linesize, uint8_t *data,
+                                                bool byteswap)
 {
     DisplaySurface *surface = g_new0(DisplaySurface, 1);
 
-    surface->pf = qemu_default_pixelformat(bpp);
+    if (byteswap) {
+        surface->pf = qemu_different_endianness_pixelformat(bpp);
+    } else {
+        surface->pf = qemu_default_pixelformat(bpp);
+    }
 
     surface->format = qemu_pixman_get_format(&surface->pf);
     assert(surface->format != 0);
-- 
1.7.9.7


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 08:50:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 08: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 1U85NQ-0007Xl-32; Wed, 20 Feb 2013 08:50:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U85NO-0007Xd-1Q
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 08:50:06 +0000
Received: from [193.109.254.147:45156] by server-4.bemta-14.messagelabs.com id
	72/3A-20719-D3E84215; Wed, 20 Feb 2013 08:50:05 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361350184!8994608!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNTI3NzUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2147 invoked from network); 20 Feb 2013 08:49:45 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-2.tower-27.messagelabs.com with SMTP;
	20 Feb 2013 08:49:45 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 98C6CC4;
	Wed, 20 Feb 2013 19:49:37 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361350177; bh=5oN81jBPKYdEJVrj8JNwu9wwhlIXSsG+mUnS/9qe/LM=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=SywzewFvm/0CIkMm9RrCdM1+7SsS9Jq37pviywI8Y2PVsnFJf12IXe8MZ8uap2yCJ
	QDYkq/HdRY3HAU6VZe0Gfi/z3JaQQOLUln+jOoRyNLnCCPmbTgJ8QwqzO/jtBOcNL+
	usxFJkZPNYSw48RXSHTqFRhp2hvdNEXBZ2BwhDV0=
Message-ID: <51248E23.7060408@crc.id.au>
Date: Wed, 20 Feb 2013 19:49:39 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
In-Reply-To: <512488AC.1020702@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============1720385402080561010=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1720385402080561010==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000701050702070300030605"

This is a cryptographically signed message in MIME format.

--------------ms000701050702070300030605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 20/02/2013 7:26 PM, Roger Pau Monn=E9 wrote:
> On 20/02/13 03:10, Steven Haigh wrote:
>> Hi guys,
>>
>> Firstly, please CC me in to any replies as I'm not a subscriber these =
days.
>>
>> I've been trying to debug a problem with Xen 4.2.1 where I am unable t=
o
>> achieve more than ~50Mb/sec sustained sequential write to a disk. The
>> DomU is configured as such:
>
> Since you mention 4.2.1 explicitly, is this a performance regression
> from previous versions? (4.2.0 or the 4.1 branch)

This is actually a very good question. I've reinstalled my older=20
packages of Xen 4.1.3 back on the system. Rebooting into the new=20
hypervisor, then starting the single DomU again. Ran bonnie++ again on=20
the DomU:

Version  1.96       ------Sequential Output------ --Sequential Input-=20
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20
/sec %CP
zeus.crc.id.au   2G   658  97 54893   9 40845  10  1056  97 280453  33=20
561.2  13
Latency             27145us     426ms     257ms   31900us   24701us=20
222ms
Version  1.96       ------Sequential Create------ --------Random=20
Create--------
zeus.crc.id.au      -Create-- --Read--- -Delete-- -Create-- --Read---=20
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=20
/sec %CP
                  16 19281  52 +++++ +++ +++++ +++ 24435  66 +++++ +++=20
+++++ +++
Latency             22860us     182us     706us   14803us      28us=20
300us


Still around 50Mb/sec - so this doesn't seem to be a regression, but=20
something else?


>> ~50Mb/sec write, ~267Mb/sec read. Not so awesome.
>
> We are currently working on improving the speed of pv block drivers, I
> will look into this difference between the read/write speed, but I woul=
d
> guess this is due to the size of the request/ring.

I would assume this would be in the DomU kernel?

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms000701050702070300030605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAwODQ5MzlaMCMGCSqGSIb3DQEJBDEWBBSMg7GocBZkMUQG8AKe5EQ7+esZ
4zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEAducqWJKotBRrDOBLi6wEnTFA
+Wt43GdhHzFMeHSLC7su8RJyfN5zWimA0ZwRogMExHIOHRcIFZB65LCQl3gzpnRQlfo1Bk7m
VLm8WjQj/nLWrLg48gJoN3RzzcyuQPsbuJfXZQob2UMCsjPQzpP8HlbuFGGZVNKhDz53mPEc
TQ6WkhXkiGLgVdhjoI0JsoFHMQj+n3zN3Lwb1O4opWuNnqly57rYI1wKpyBgIxKejrBJWaz3
q3Ck7p48ZJySvVGfu5IW+5wwmfAZOoePdYtIDES9yDRmPZh/rxChFh5NHELmWvSirYr01RBl
ewiu8BPdau92V/GCje3aOZf/xDeo4wAAAAAAAA==
--------------ms000701050702070300030605--


--===============1720385402080561010==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1720385402080561010==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 08:50:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 08: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 1U85NQ-0007Xl-32; Wed, 20 Feb 2013 08:50:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U85NO-0007Xd-1Q
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 08:50:06 +0000
Received: from [193.109.254.147:45156] by server-4.bemta-14.messagelabs.com id
	72/3A-20719-D3E84215; Wed, 20 Feb 2013 08:50:05 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361350184!8994608!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_8,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNTI3NzUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2147 invoked from network); 20 Feb 2013 08:49:45 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-2.tower-27.messagelabs.com with SMTP;
	20 Feb 2013 08:49:45 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 98C6CC4;
	Wed, 20 Feb 2013 19:49:37 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361350177; bh=5oN81jBPKYdEJVrj8JNwu9wwhlIXSsG+mUnS/9qe/LM=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=SywzewFvm/0CIkMm9RrCdM1+7SsS9Jq37pviywI8Y2PVsnFJf12IXe8MZ8uap2yCJ
	QDYkq/HdRY3HAU6VZe0Gfi/z3JaQQOLUln+jOoRyNLnCCPmbTgJ8QwqzO/jtBOcNL+
	usxFJkZPNYSw48RXSHTqFRhp2hvdNEXBZ2BwhDV0=
Message-ID: <51248E23.7060408@crc.id.au>
Date: Wed, 20 Feb 2013 19:49:39 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
In-Reply-To: <512488AC.1020702@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============1720385402080561010=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1720385402080561010==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000701050702070300030605"

This is a cryptographically signed message in MIME format.

--------------ms000701050702070300030605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 20/02/2013 7:26 PM, Roger Pau Monn=E9 wrote:
> On 20/02/13 03:10, Steven Haigh wrote:
>> Hi guys,
>>
>> Firstly, please CC me in to any replies as I'm not a subscriber these =
days.
>>
>> I've been trying to debug a problem with Xen 4.2.1 where I am unable t=
o
>> achieve more than ~50Mb/sec sustained sequential write to a disk. The
>> DomU is configured as such:
>
> Since you mention 4.2.1 explicitly, is this a performance regression
> from previous versions? (4.2.0 or the 4.1 branch)

This is actually a very good question. I've reinstalled my older=20
packages of Xen 4.1.3 back on the system. Rebooting into the new=20
hypervisor, then starting the single DomU again. Ran bonnie++ again on=20
the DomU:

Version  1.96       ------Sequential Output------ --Sequential Input-=20
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20
/sec %CP
zeus.crc.id.au   2G   658  97 54893   9 40845  10  1056  97 280453  33=20
561.2  13
Latency             27145us     426ms     257ms   31900us   24701us=20
222ms
Version  1.96       ------Sequential Create------ --------Random=20
Create--------
zeus.crc.id.au      -Create-- --Read--- -Delete-- -Create-- --Read---=20
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=20
/sec %CP
                  16 19281  52 +++++ +++ +++++ +++ 24435  66 +++++ +++=20
+++++ +++
Latency             22860us     182us     706us   14803us      28us=20
300us


Still around 50Mb/sec - so this doesn't seem to be a regression, but=20
something else?


>> ~50Mb/sec write, ~267Mb/sec read. Not so awesome.
>
> We are currently working on improving the speed of pv block drivers, I
> will look into this difference between the read/write speed, but I woul=
d
> guess this is due to the size of the request/ring.

I would assume this would be in the DomU kernel?

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms000701050702070300030605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAwODQ5MzlaMCMGCSqGSIb3DQEJBDEWBBSMg7GocBZkMUQG8AKe5EQ7+esZ
4zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEAducqWJKotBRrDOBLi6wEnTFA
+Wt43GdhHzFMeHSLC7su8RJyfN5zWimA0ZwRogMExHIOHRcIFZB65LCQl3gzpnRQlfo1Bk7m
VLm8WjQj/nLWrLg48gJoN3RzzcyuQPsbuJfXZQob2UMCsjPQzpP8HlbuFGGZVNKhDz53mPEc
TQ6WkhXkiGLgVdhjoI0JsoFHMQj+n3zN3Lwb1O4opWuNnqly57rYI1wKpyBgIxKejrBJWaz3
q3Ck7p48ZJySvVGfu5IW+5wwmfAZOoePdYtIDES9yDRmPZh/rxChFh5NHELmWvSirYr01RBl
ewiu8BPdau92V/GCje3aOZf/xDeo4wAAAAAAAA==
--------------ms000701050702070300030605--


--===============1720385402080561010==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1720385402080561010==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 09:14:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09: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 1U85kO-0007uZ-JT; Wed, 20 Feb 2013 09:13: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 1U85kM-0007uU-T7
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 09:13:51 +0000
Received: from [85.158.137.99:11952] by server-5.bemta-3.messagelabs.com id
	9E/DD-04457-9C394215; Wed, 20 Feb 2013 09:13:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361351622!11800382!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15875 invoked from network); 20 Feb 2013 09:13:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 09:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1641849"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 09:13: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.297.1;
	Wed, 20 Feb 2013 09:13:42 +0000
Message-ID: <1361351620.1051.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 20 Feb 2013 09:13:40 +0000
In-Reply-To: <20130220030943.GA28092@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
	<20130220020727.GA25329@phenom.dumpdata.com>
	<20130220030943.GA28092@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 03:09 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 09:07:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 05:29:11PM +0000, Ian Campbell wrote:
> > > On ARM we want these to be the same size on 32- and 64-bit.
> > >
> > > This is an ABI change on ARM. X86 does not change.
> >
> > Hehe. You didn't test this, did you :-)
> >
> > It hangs bootup on X86.
> 
> Ah wait. The version that hangs was the first posted - I hadn't
> tested this one yet. I will wait until later on Wednesday to do that.

I don't know what I tested yesterday but it surely wasn't this patch
because it hangs for me too this morning :-/

Sorry about this, will investigate...

Ian.

> 
> 
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Jan Beulich <JBeulich@suse.com>
> > > Cc: Keir (Xen.org) <keir@xen.org>
> > > Cc: Tim Deegan <tim@xen.org>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Cc: xen-devel@lists.xen.org
> > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > > Changes since V3
> > >   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > > Changes since V2
> > >   Add comments about the correct bitops to use, and on the ordering/barrier
> > >   requirements on xchg_xen_ulong.
> > > Changes since V1
> > >   use find_first_set not __ffs
> > >   fix some more unsigned long -> xen_ulong_t
> > >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> > > ---
> > >  arch/arm/include/asm/xen/events.h |   22 +++++++
> > >  arch/x86/include/asm/xen/events.h |    3 +
> > >  drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
> > >  include/xen/interface/xen.h       |    8 +-
> > >  4 files changed, 94 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > > index 94b4e90..5c27696 100644
> > > --- a/arch/arm/include/asm/xen/events.h
> > > +++ b/arch/arm/include/asm/xen/events.h
> > > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> > >     return raw_irqs_disabled_flags(regs->ARM_cpsr);
> > >  }
> > >
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > +{
> > > +   xen_ulong_t oldval;
> > > +   unsigned int tmp;
> > > +
> > > +   wmb();
> > > +   asm volatile("@ xchg_xen_ulong\n"
> > > +           "1:     ldrexd  %0, %H0, [%3]\n"
> > > +           "       strexd  %1, %2, %H2, [%3]\n"
> > > +           "       teq     %1, #0\n"
> > > +           "       bne     1b"
> > > +           : "=&r" (oldval), "=&r" (tmp)
> > > +           : "r" (val), "r" (ptr)
> > > +           : "memory", "cc");
> > > +   return oldval;
> > > +}
> > > +
> > >  #endif /* _ASM_ARM_XEN_EVENTS_H */
> > > diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> > > index cc146d5..ca842f2 100644
> > > --- a/arch/x86/include/asm/xen/events.h
> > > +++ b/arch/x86/include/asm/xen/events.h
> > > @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> > >     return raw_irqs_disabled_flags(regs->flags);
> > >  }
> > >
> > > +/* No need for a barrier -- XCHG is a barrier on x86. */
> > > +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> > > +
> > >  #endif /* _ASM_X86_XEN_EVENTS_H */
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 0be4df3..b8d84f5 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -80,6 +80,12 @@ enum xen_irq_type {
> > >  };
> > >
> > >  /*
> > > + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> > > + * array. Primarily to avoid long lines (hence the terse name).
> > > + */
> > > +#define BM(x) (unsigned long *)(x)
> > > +
> > > +/*
> > >   * Packed IRQ information:
> > >   * type - enum xen_irq_type
> > >   * event channel - irq->event channel mapping
> > > @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
> > >  #endif
> > >  static bool (*pirq_needs_eoi)(unsigned irq);
> > >
> > > -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > > +/*
> > > + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> > > + * careful to only use bitops which allow for this (e.g test_bit and
> > > + * friends but not __ffs).
> > > + */
> > > +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> > > +
> > > +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
> > >                   cpu_evtchn_mask);
> > >
> > >  /* Xen will never allocate port zero for any purpose. */
> > > @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> > >     return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > >  }
> > >
> > > -static inline unsigned long active_evtchns(unsigned int cpu,
> > > -                                      struct shared_info *sh,
> > > -                                      unsigned int idx)
> > > +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> > > +                                    struct shared_info *sh,
> > > +                                    unsigned int idx)
> > >  {
> > >     return sh->evtchn_pending[idx] &
> > >             per_cpu(cpu_evtchn_mask, cpu)[idx] &
> > > @@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> > >     cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
> > >  #endif
> > >
> > > -   clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> > > -   set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> > > +   clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> > > +   set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
> > >
> > >     info_for_irq(irq)->cpu = cpu;
> > >  }
> > > @@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
> > >  static inline void clear_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   sync_clear_bit(port, &s->evtchn_pending[0]);
> > > +   sync_clear_bit(port, BM(&s->evtchn_pending[0]));
> > >  }
> > >
> > >  static inline void set_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   sync_set_bit(port, &s->evtchn_pending[0]);
> > > +   sync_set_bit(port, BM(&s->evtchn_pending[0]));
> > >  }
> > >
> > >  static inline int test_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   return sync_test_bit(port, &s->evtchn_pending[0]);
> > > +   return sync_test_bit(port, BM(&s->evtchn_pending[0]));
> > >  }
> > >
> > >
> > > @@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
> > >  static void mask_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   sync_set_bit(port, &s->evtchn_mask[0]);
> > > +   sync_set_bit(port, BM(&s->evtchn_mask[0]));
> > >  }
> > >
> > >  static void unmask_evtchn(int port)
> > > @@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
> > >     if (unlikely((cpu != cpu_from_evtchn(port))))
> > >             do_hypercall = 1;
> > >     else
> > > -           evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> > > +           evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
> > >
> > >     if (unlikely(evtchn_pending && xen_hvm_domain()))
> > >             do_hypercall = 1;
> > > @@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
> > >     } else {
> > >             struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> > >
> > > -           sync_clear_bit(port, &s->evtchn_mask[0]);
> > > +           sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> > >
> > >             /*
> > >              * The following is basically the equivalent of
> > > @@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
> > >              * the interrupt edge' if the channel is masked.
> > >              */
> > >             if (evtchn_pending &&
> > > -               !sync_test_and_set_bit(port / BITS_PER_LONG,
> > > -                                      &vcpu_info->evtchn_pending_sel))
> > > +               !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> > > +                                      BM(&vcpu_info->evtchn_pending_sel)))
> > >                     vcpu_info->evtchn_upcall_pending = 1;
> > >     }
> > >
> > > @@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> > >  {
> > >     struct shared_info *sh = HYPERVISOR_shared_info;
> > >     int cpu = smp_processor_id();
> > > -   unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > > +   xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > >     int i;
> > >     unsigned long flags;
> > >     static DEFINE_SPINLOCK(debug_lock);
> > > @@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> > >             pending = (get_irq_regs() && i == cpu)
> > >                     ? xen_irqs_disabled(get_irq_regs())
> > >                     : v->evtchn_upcall_mask;
> > > -           printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> > > +           printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
> > >                    pending, v->evtchn_upcall_pending,
> > >                    (int)(sizeof(v->evtchn_pending_sel)*2),
> > >                    v->evtchn_pending_sel);
> > > @@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> > >
> > >     printk("\npending:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> > > -           printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > > +                  (int)sizeof(sh->evtchn_pending[0])*2,
> > >                    sh->evtchn_pending[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >     printk("\nglobal mask:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > > -           printk("%0*lx%s",
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > >                    (int)(sizeof(sh->evtchn_mask[0])*2),
> > >                    sh->evtchn_mask[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >
> > >     printk("\nglobally unmasked:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > > -           printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > > +                  (int)(sizeof(sh->evtchn_mask[0])*2),
> > >                    sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >
> > >     printk("\nlocal cpu%d mask:\n   ", cpu);
> > > -   for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> > > -           printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> > > +   for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> > > +           printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
> > >                    cpu_evtchn[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >
> > >     printk("\nlocally unmasked:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> > > -           unsigned long pending = sh->evtchn_pending[i]
> > > +           xen_ulong_t pending = sh->evtchn_pending[i]
> > >                     & ~sh->evtchn_mask[i]
> > >                     & cpu_evtchn[i];
> > > -           printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > > +                  (int)(sizeof(sh->evtchn_mask[0])*2),
> > >                    pending, i % 8 == 0 ? "\n   " : " ");
> > >     }
> > >
> > >     printk("\npending list:\n");
> > >     for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> > > -           if (sync_test_bit(i, sh->evtchn_pending)) {
> > > -                   int word_idx = i / BITS_PER_LONG;
> > > +           if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> > > +                   int word_idx = i / BITS_PER_EVTCHN_WORD;
> > >                     printk("  %d: event %d -> irq %d%s%s%s\n",
> > >                            cpu_from_evtchn(i), i,
> > >                            evtchn_to_irq[i],
> > > -                          sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > > +                          sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
> > >                                          ? "" : " l2-clear",
> > > -                          !sync_test_bit(i, sh->evtchn_mask)
> > > +                          !sync_test_bit(i, BM(sh->evtchn_mask))
> > >                                          ? "" : " globally-masked",
> > > -                          sync_test_bit(i, cpu_evtchn)
> > > +                          sync_test_bit(i, BM(cpu_evtchn))
> > >                                          ? "" : " locally-masked");
> > >             }
> > >     }
> > > @@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
> > >  /*
> > >   * Mask out the i least significant bits of w
> > >   */
> > > -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> > > +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
> > >
> > >  /*
> > >   * Search the CPUs pending events bitmasks.  For each one found, map
> > > @@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
> > >     unsigned count;
> > >
> > >     do {
> > > -           unsigned long pending_words;
> > > +           xen_ulong_t pending_words;
> > >
> > >             vcpu_info->evtchn_upcall_pending = 0;
> > >
> > >             if (__this_cpu_inc_return(xed_nesting_count) - 1)
> > >                     goto out;
> > >
> > > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > > -           /* Clear master flag /before/ clearing selector flag. */
> > > -           wmb();
> > > -#endif
> > > -           pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > > +           /*
> > > +            * Master flag must be /before/ clearing selector
> > > +            * flag. xchg_xen_ulong must contain an appropriate
> > > +            * barrier.
> > > +            */
> > > +           pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> > >
> > >             start_word_idx = __this_cpu_read(current_word_idx);
> > >             start_bit_idx = __this_cpu_read(current_bit_idx);
> > > @@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
> > >             word_idx = start_word_idx;
> > >
> > >             for (i = 0; pending_words != 0; i++) {
> > > -                   unsigned long pending_bits;
> > > -                   unsigned long words;
> > > +                   xen_ulong_t pending_bits;
> > > +                   xen_ulong_t words;
> > >
> > >                     words = MASK_LSBS(pending_words, word_idx);
> > >
> > > @@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
> > >                             bit_idx = 0;
> > >                             continue;
> > >                     }
> > > -                   word_idx = __ffs(words);
> > > +                   word_idx = find_first_bit(BM(&words), sizeof(words));
> > >
> > >                     pending_bits = active_evtchns(cpu, s, word_idx);
> > >                     bit_idx = 0; /* usually scan entire word from start */
> > > @@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
> > >                     }
> > >
> > >                     do {
> > > -                           unsigned long bits;
> > > +                           xen_ulong_t bits;
> > >                             int port, irq;
> > >                             struct irq_desc *desc;
> > >
> > > @@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
> > >                             if (bits == 0)
> > >                                     break;
> > >
> > > -                           bit_idx = __ffs(bits);
> > > +                           bit_idx = find_first_bit(BM(&bits), sizeof(bits));
> > >
> > >                             /* Process port. */
> > > -                           port = (word_idx * BITS_PER_LONG) + bit_idx;
> > > +                           port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
> > >                             irq = evtchn_to_irq[port];
> > >
> > >                             if (irq != -1) {
> > > @@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
> > >                                             generic_handle_irq_desc(irq, desc);
> > >                             }
> > >
> > > -                           bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> > > +                           bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
> > >
> > >                             /* Next caller starts at last processed + 1 */
> > >                             __this_cpu_write(current_word_idx,
> > >                                              bit_idx ? word_idx :
> > > -                                            (word_idx+1) % BITS_PER_LONG);
> > > +                                            (word_idx+1) % BITS_PER_EVTCHN_WORD);
> > >                             __this_cpu_write(current_bit_idx, bit_idx);
> > >                     } while (bit_idx != 0);
> > >
> > > @@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
> > >                     if ((word_idx != start_word_idx) || (i != 0))
> > >                             pending_words &= ~(1UL << word_idx);
> > >
> > > -                   word_idx = (word_idx + 1) % BITS_PER_LONG;
> > > +                   word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
> > >             }
> > >
> > >             BUG_ON(!irqs_disabled());
> > > @@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
> > >     if (!VALID_EVTCHN(evtchn))
> > >             return 1;
> > >
> > > -   masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> > > -   sync_set_bit(evtchn, s->evtchn_pending);
> > > +   masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> > > +   sync_set_bit(evtchn, BM(s->evtchn_pending));
> > >     if (!masked)
> > >             unmask_evtchn(evtchn);
> > >
> > > @@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
> > >     if (VALID_EVTCHN(evtchn)) {
> > >             int masked;
> > >
> > > -           masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> > > -           sync_set_bit(evtchn, sh->evtchn_pending);
> > > +           masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> > > +           sync_set_bit(evtchn, BM(sh->evtchn_pending));
> > >             if (!masked)
> > >                     unmask_evtchn(evtchn);
> > >             ret = 1;
> > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > > index 5d6c272..a9075df 100644
> > > --- a/include/xen/interface/xen.h
> > > +++ b/include/xen/interface/xen.h
> > > @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> > >   * Event channel endpoints per domain:
> > >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> > >   */
> > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > > +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
> > >
> > >  struct vcpu_time_info {
> > >     /*
> > > @@ -341,7 +341,7 @@ struct vcpu_info {
> > >      */
> > >     uint8_t evtchn_upcall_pending;
> > >     uint8_t evtchn_upcall_mask;
> > > -   unsigned long evtchn_pending_sel;
> > > +   xen_ulong_t evtchn_pending_sel;
> > >     struct arch_vcpu_info arch;
> > >     struct pvclock_vcpu_time_info time;
> > >  }; /* 64 bytes (x86) */
> > > @@ -384,8 +384,8 @@ struct shared_info {
> > >      * per-vcpu selector word to be set. Each bit in the selector covers a
> > >      * 'C long' in the PENDING bitfield array.
> > >      */
> > > -   unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> > > -   unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> > > +   xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> > > +   xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
> > >
> > >     /*
> > >      * Wallclock time: updated only by control software. Guests should base
> > > --
> > > 1.7.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 Feb 20 09:14:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09: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 1U85kO-0007uZ-JT; Wed, 20 Feb 2013 09:13: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 1U85kM-0007uU-T7
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 09:13:51 +0000
Received: from [85.158.137.99:11952] by server-5.bemta-3.messagelabs.com id
	9E/DD-04457-9C394215; Wed, 20 Feb 2013 09:13:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361351622!11800382!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15875 invoked from network); 20 Feb 2013 09:13:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 09:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1641849"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 09:13: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.297.1;
	Wed, 20 Feb 2013 09:13:42 +0000
Message-ID: <1361351620.1051.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 20 Feb 2013 09:13:40 +0000
In-Reply-To: <20130220030943.GA28092@phenom.dumpdata.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361294951-28633-1-git-send-email-ian.campbell@citrix.com>
	<20130220020727.GA25329@phenom.dumpdata.com>
	<20130220030943.GA28092@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v4] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 03:09 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 09:07:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 05:29:11PM +0000, Ian Campbell wrote:
> > > On ARM we want these to be the same size on 32- and 64-bit.
> > >
> > > This is an ABI change on ARM. X86 does not change.
> >
> > Hehe. You didn't test this, did you :-)
> >
> > It hangs bootup on X86.
> 
> Ah wait. The version that hangs was the first posted - I hadn't
> tested this one yet. I will wait until later on Wednesday to do that.

I don't know what I tested yesterday but it surely wasn't this patch
because it hangs for me too this morning :-/

Sorry about this, will investigate...

Ian.

> 
> 
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Jan Beulich <JBeulich@suse.com>
> > > Cc: Keir (Xen.org) <keir@xen.org>
> > > Cc: Tim Deegan <tim@xen.org>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Cc: xen-devel@lists.xen.org
> > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > > Changes since V3
> > >   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > > Changes since V2
> > >   Add comments about the correct bitops to use, and on the ordering/barrier
> > >   requirements on xchg_xen_ulong.
> > > Changes since V1
> > >   use find_first_set not __ffs
> > >   fix some more unsigned long -> xen_ulong_t
> > >   use more generic xchg_xen_ulong instead of ...read_evtchn...
> > > ---
> > >  arch/arm/include/asm/xen/events.h |   22 +++++++
> > >  arch/x86/include/asm/xen/events.h |    3 +
> > >  drivers/xen/events.c              |  113 +++++++++++++++++++++----------------
> > >  include/xen/interface/xen.h       |    8 +-
> > >  4 files changed, 94 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > > index 94b4e90..5c27696 100644
> > > --- a/arch/arm/include/asm/xen/events.h
> > > +++ b/arch/arm/include/asm/xen/events.h
> > > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> > >     return raw_irqs_disabled_flags(regs->ARM_cpsr);
> > >  }
> > >
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > +{
> > > +   xen_ulong_t oldval;
> > > +   unsigned int tmp;
> > > +
> > > +   wmb();
> > > +   asm volatile("@ xchg_xen_ulong\n"
> > > +           "1:     ldrexd  %0, %H0, [%3]\n"
> > > +           "       strexd  %1, %2, %H2, [%3]\n"
> > > +           "       teq     %1, #0\n"
> > > +           "       bne     1b"
> > > +           : "=&r" (oldval), "=&r" (tmp)
> > > +           : "r" (val), "r" (ptr)
> > > +           : "memory", "cc");
> > > +   return oldval;
> > > +}
> > > +
> > >  #endif /* _ASM_ARM_XEN_EVENTS_H */
> > > diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> > > index cc146d5..ca842f2 100644
> > > --- a/arch/x86/include/asm/xen/events.h
> > > +++ b/arch/x86/include/asm/xen/events.h
> > > @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> > >     return raw_irqs_disabled_flags(regs->flags);
> > >  }
> > >
> > > +/* No need for a barrier -- XCHG is a barrier on x86. */
> > > +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> > > +
> > >  #endif /* _ASM_X86_XEN_EVENTS_H */
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 0be4df3..b8d84f5 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -80,6 +80,12 @@ enum xen_irq_type {
> > >  };
> > >
> > >  /*
> > > + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> > > + * array. Primarily to avoid long lines (hence the terse name).
> > > + */
> > > +#define BM(x) (unsigned long *)(x)
> > > +
> > > +/*
> > >   * Packed IRQ information:
> > >   * type - enum xen_irq_type
> > >   * event channel - irq->event channel mapping
> > > @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
> > >  #endif
> > >  static bool (*pirq_needs_eoi)(unsigned irq);
> > >
> > > -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > > +/*
> > > + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> > > + * careful to only use bitops which allow for this (e.g test_bit and
> > > + * friends but not __ffs).
> > > + */
> > > +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> > > +
> > > +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
> > >                   cpu_evtchn_mask);
> > >
> > >  /* Xen will never allocate port zero for any purpose. */
> > > @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> > >     return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > >  }
> > >
> > > -static inline unsigned long active_evtchns(unsigned int cpu,
> > > -                                      struct shared_info *sh,
> > > -                                      unsigned int idx)
> > > +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> > > +                                    struct shared_info *sh,
> > > +                                    unsigned int idx)
> > >  {
> > >     return sh->evtchn_pending[idx] &
> > >             per_cpu(cpu_evtchn_mask, cpu)[idx] &
> > > @@ -312,8 +325,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
> > >     cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
> > >  #endif
> > >
> > > -   clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> > > -   set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> > > +   clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> > > +   set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
> > >
> > >     info_for_irq(irq)->cpu = cpu;
> > >  }
> > > @@ -339,19 +352,19 @@ static void init_evtchn_cpu_bindings(void)
> > >  static inline void clear_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   sync_clear_bit(port, &s->evtchn_pending[0]);
> > > +   sync_clear_bit(port, BM(&s->evtchn_pending[0]));
> > >  }
> > >
> > >  static inline void set_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   sync_set_bit(port, &s->evtchn_pending[0]);
> > > +   sync_set_bit(port, BM(&s->evtchn_pending[0]));
> > >  }
> > >
> > >  static inline int test_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   return sync_test_bit(port, &s->evtchn_pending[0]);
> > > +   return sync_test_bit(port, BM(&s->evtchn_pending[0]));
> > >  }
> > >
> > >
> > > @@ -375,7 +388,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
> > >  static void mask_evtchn(int port)
> > >  {
> > >     struct shared_info *s = HYPERVISOR_shared_info;
> > > -   sync_set_bit(port, &s->evtchn_mask[0]);
> > > +   sync_set_bit(port, BM(&s->evtchn_mask[0]));
> > >  }
> > >
> > >  static void unmask_evtchn(int port)
> > > @@ -389,7 +402,7 @@ static void unmask_evtchn(int port)
> > >     if (unlikely((cpu != cpu_from_evtchn(port))))
> > >             do_hypercall = 1;
> > >     else
> > > -           evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> > > +           evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
> > >
> > >     if (unlikely(evtchn_pending && xen_hvm_domain()))
> > >             do_hypercall = 1;
> > > @@ -403,7 +416,7 @@ static void unmask_evtchn(int port)
> > >     } else {
> > >             struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> > >
> > > -           sync_clear_bit(port, &s->evtchn_mask[0]);
> > > +           sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> > >
> > >             /*
> > >              * The following is basically the equivalent of
> > > @@ -411,8 +424,8 @@ static void unmask_evtchn(int port)
> > >              * the interrupt edge' if the channel is masked.
> > >              */
> > >             if (evtchn_pending &&
> > > -               !sync_test_and_set_bit(port / BITS_PER_LONG,
> > > -                                      &vcpu_info->evtchn_pending_sel))
> > > +               !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> > > +                                      BM(&vcpu_info->evtchn_pending_sel)))
> > >                     vcpu_info->evtchn_upcall_pending = 1;
> > >     }
> > >
> > > @@ -1189,7 +1202,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> > >  {
> > >     struct shared_info *sh = HYPERVISOR_shared_info;
> > >     int cpu = smp_processor_id();
> > > -   unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > > +   xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> > >     int i;
> > >     unsigned long flags;
> > >     static DEFINE_SPINLOCK(debug_lock);
> > > @@ -1205,7 +1218,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> > >             pending = (get_irq_regs() && i == cpu)
> > >                     ? xen_irqs_disabled(get_irq_regs())
> > >                     : v->evtchn_upcall_mask;
> > > -           printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> > > +           printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
> > >                    pending, v->evtchn_upcall_pending,
> > >                    (int)(sizeof(v->evtchn_pending_sel)*2),
> > >                    v->evtchn_pending_sel);
> > > @@ -1214,49 +1227,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> > >
> > >     printk("\npending:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> > > -           printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > > +                  (int)sizeof(sh->evtchn_pending[0])*2,
> > >                    sh->evtchn_pending[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >     printk("\nglobal mask:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > > -           printk("%0*lx%s",
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > >                    (int)(sizeof(sh->evtchn_mask[0])*2),
> > >                    sh->evtchn_mask[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >
> > >     printk("\nglobally unmasked:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> > > -           printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > > +                  (int)(sizeof(sh->evtchn_mask[0])*2),
> > >                    sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >
> > >     printk("\nlocal cpu%d mask:\n   ", cpu);
> > > -   for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> > > -           printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> > > +   for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> > > +           printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
> > >                    cpu_evtchn[i],
> > >                    i % 8 == 0 ? "\n   " : " ");
> > >
> > >     printk("\nlocally unmasked:\n   ");
> > >     for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> > > -           unsigned long pending = sh->evtchn_pending[i]
> > > +           xen_ulong_t pending = sh->evtchn_pending[i]
> > >                     & ~sh->evtchn_mask[i]
> > >                     & cpu_evtchn[i];
> > > -           printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> > > +           printk("%0*"PRI_xen_ulong"%s",
> > > +                  (int)(sizeof(sh->evtchn_mask[0])*2),
> > >                    pending, i % 8 == 0 ? "\n   " : " ");
> > >     }
> > >
> > >     printk("\npending list:\n");
> > >     for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> > > -           if (sync_test_bit(i, sh->evtchn_pending)) {
> > > -                   int word_idx = i / BITS_PER_LONG;
> > > +           if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> > > +                   int word_idx = i / BITS_PER_EVTCHN_WORD;
> > >                     printk("  %d: event %d -> irq %d%s%s%s\n",
> > >                            cpu_from_evtchn(i), i,
> > >                            evtchn_to_irq[i],
> > > -                          sync_test_bit(word_idx, &v->evtchn_pending_sel)
> > > +                          sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
> > >                                          ? "" : " l2-clear",
> > > -                          !sync_test_bit(i, sh->evtchn_mask)
> > > +                          !sync_test_bit(i, BM(sh->evtchn_mask))
> > >                                          ? "" : " globally-masked",
> > > -                          sync_test_bit(i, cpu_evtchn)
> > > +                          sync_test_bit(i, BM(cpu_evtchn))
> > >                                          ? "" : " locally-masked");
> > >             }
> > >     }
> > > @@ -1273,7 +1289,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
> > >  /*
> > >   * Mask out the i least significant bits of w
> > >   */
> > > -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> > > +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
> > >
> > >  /*
> > >   * Search the CPUs pending events bitmasks.  For each one found, map
> > > @@ -1295,18 +1311,19 @@ static void __xen_evtchn_do_upcall(void)
> > >     unsigned count;
> > >
> > >     do {
> > > -           unsigned long pending_words;
> > > +           xen_ulong_t pending_words;
> > >
> > >             vcpu_info->evtchn_upcall_pending = 0;
> > >
> > >             if (__this_cpu_inc_return(xed_nesting_count) - 1)
> > >                     goto out;
> > >
> > > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > > -           /* Clear master flag /before/ clearing selector flag. */
> > > -           wmb();
> > > -#endif
> > > -           pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > > +           /*
> > > +            * Master flag must be /before/ clearing selector
> > > +            * flag. xchg_xen_ulong must contain an appropriate
> > > +            * barrier.
> > > +            */
> > > +           pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> > >
> > >             start_word_idx = __this_cpu_read(current_word_idx);
> > >             start_bit_idx = __this_cpu_read(current_bit_idx);
> > > @@ -1314,8 +1331,8 @@ static void __xen_evtchn_do_upcall(void)
> > >             word_idx = start_word_idx;
> > >
> > >             for (i = 0; pending_words != 0; i++) {
> > > -                   unsigned long pending_bits;
> > > -                   unsigned long words;
> > > +                   xen_ulong_t pending_bits;
> > > +                   xen_ulong_t words;
> > >
> > >                     words = MASK_LSBS(pending_words, word_idx);
> > >
> > > @@ -1327,7 +1344,7 @@ static void __xen_evtchn_do_upcall(void)
> > >                             bit_idx = 0;
> > >                             continue;
> > >                     }
> > > -                   word_idx = __ffs(words);
> > > +                   word_idx = find_first_bit(BM(&words), sizeof(words));
> > >
> > >                     pending_bits = active_evtchns(cpu, s, word_idx);
> > >                     bit_idx = 0; /* usually scan entire word from start */
> > > @@ -1342,7 +1359,7 @@ static void __xen_evtchn_do_upcall(void)
> > >                     }
> > >
> > >                     do {
> > > -                           unsigned long bits;
> > > +                           xen_ulong_t bits;
> > >                             int port, irq;
> > >                             struct irq_desc *desc;
> > >
> > > @@ -1352,10 +1369,10 @@ static void __xen_evtchn_do_upcall(void)
> > >                             if (bits == 0)
> > >                                     break;
> > >
> > > -                           bit_idx = __ffs(bits);
> > > +                           bit_idx = find_first_bit(BM(&bits), sizeof(bits));
> > >
> > >                             /* Process port. */
> > > -                           port = (word_idx * BITS_PER_LONG) + bit_idx;
> > > +                           port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
> > >                             irq = evtchn_to_irq[port];
> > >
> > >                             if (irq != -1) {
> > > @@ -1364,12 +1381,12 @@ static void __xen_evtchn_do_upcall(void)
> > >                                             generic_handle_irq_desc(irq, desc);
> > >                             }
> > >
> > > -                           bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> > > +                           bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
> > >
> > >                             /* Next caller starts at last processed + 1 */
> > >                             __this_cpu_write(current_word_idx,
> > >                                              bit_idx ? word_idx :
> > > -                                            (word_idx+1) % BITS_PER_LONG);
> > > +                                            (word_idx+1) % BITS_PER_EVTCHN_WORD);
> > >                             __this_cpu_write(current_bit_idx, bit_idx);
> > >                     } while (bit_idx != 0);
> > >
> > > @@ -1377,7 +1394,7 @@ static void __xen_evtchn_do_upcall(void)
> > >                     if ((word_idx != start_word_idx) || (i != 0))
> > >                             pending_words &= ~(1UL << word_idx);
> > >
> > > -                   word_idx = (word_idx + 1) % BITS_PER_LONG;
> > > +                   word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
> > >             }
> > >
> > >             BUG_ON(!irqs_disabled());
> > > @@ -1487,8 +1504,8 @@ int resend_irq_on_evtchn(unsigned int irq)
> > >     if (!VALID_EVTCHN(evtchn))
> > >             return 1;
> > >
> > > -   masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> > > -   sync_set_bit(evtchn, s->evtchn_pending);
> > > +   masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> > > +   sync_set_bit(evtchn, BM(s->evtchn_pending));
> > >     if (!masked)
> > >             unmask_evtchn(evtchn);
> > >
> > > @@ -1536,8 +1553,8 @@ static int retrigger_dynirq(struct irq_data *data)
> > >     if (VALID_EVTCHN(evtchn)) {
> > >             int masked;
> > >
> > > -           masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> > > -           sync_set_bit(evtchn, sh->evtchn_pending);
> > > +           masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> > > +           sync_set_bit(evtchn, BM(sh->evtchn_pending));
> > >             if (!masked)
> > >                     unmask_evtchn(evtchn);
> > >             ret = 1;
> > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > > index 5d6c272..a9075df 100644
> > > --- a/include/xen/interface/xen.h
> > > +++ b/include/xen/interface/xen.h
> > > @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
> > >   * Event channel endpoints per domain:
> > >   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
> > >   */
> > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> > > +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
> > >
> > >  struct vcpu_time_info {
> > >     /*
> > > @@ -341,7 +341,7 @@ struct vcpu_info {
> > >      */
> > >     uint8_t evtchn_upcall_pending;
> > >     uint8_t evtchn_upcall_mask;
> > > -   unsigned long evtchn_pending_sel;
> > > +   xen_ulong_t evtchn_pending_sel;
> > >     struct arch_vcpu_info arch;
> > >     struct pvclock_vcpu_time_info time;
> > >  }; /* 64 bytes (x86) */
> > > @@ -384,8 +384,8 @@ struct shared_info {
> > >      * per-vcpu selector word to be set. Each bit in the selector covers a
> > >      * 'C long' in the PENDING bitfield array.
> > >      */
> > > -   unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> > > -   unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> > > +   xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> > > +   xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
> > >
> > >     /*
> > >      * Wallclock time: updated only by control software. Guests should base
> > > --
> > > 1.7.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 Feb 20 09:24:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09: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 1U85u7-0008Ka-Fy; Wed, 20 Feb 2013 09:23:55 +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 1U85u6-0008KS-5o
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 09:23:54 +0000
Received: from [85.158.138.51:10715] by server-6.bemta-3.messagelabs.com id
	0E/30-29959-92694215; Wed, 20 Feb 2013 09:23:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361352231!28342281!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12626 invoked from network); 20 Feb 2013 09:23:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 09:23:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1642247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 09:23: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.297.1;
	Wed, 20 Feb 2013 09:23:50 +0000
Message-ID: <1361352229.1051.144.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Wed, 20 Feb 2013 09:23:49 +0000
In-Reply-To: <20130219.130607.100487415380997622.davem@davemloft.net>
References: <20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
	<1361264324.1051.61.camel@zakaz.uk.xensource.com>
	<20130219.130607.100487415380997622.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 18:06 +0000, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@citrix.com>
> Date: Tue, 19 Feb 2013 08:58:44 +0000
> 
> > On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> >> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> >> > From: Andrew Jones <drjones@redhat.com>
> >> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> >> > 
> >> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> >> have one reference to the vif at this time, then the xenvif_put
> >> >> in netbk_fatal_tx_err is one too many.
> >> >> 
> >> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> >> > 
> >> > Applied.
> >> 
> >> But this is wrong from all we can tell,
> > 
> > Yes, please can this be reverted.
> 
> Done and I've annotated the revert commit message with as much
> information as possible.

Thanks, 629821d9b looks good to me.

May be worth considering the patch in
<1361281636.1051.100.camel@zakaz.uk.xensource.com> if we get many more
of these queries...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 09:24:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09: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 1U85u7-0008Ka-Fy; Wed, 20 Feb 2013 09:23:55 +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 1U85u6-0008KS-5o
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 09:23:54 +0000
Received: from [85.158.138.51:10715] by server-6.bemta-3.messagelabs.com id
	0E/30-29959-92694215; Wed, 20 Feb 2013 09:23:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361352231!28342281!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12626 invoked from network); 20 Feb 2013 09:23:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 09:23:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1642247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 09:23: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.297.1;
	Wed, 20 Feb 2013 09:23:50 +0000
Message-ID: <1361352229.1051.144.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Miller <davem@davemloft.net>
Date: Wed, 20 Feb 2013 09:23:49 +0000
In-Reply-To: <20130219.130607.100487415380997622.davem@davemloft.net>
References: <20130219.005356.2288460992654639558.davem@davemloft.net>
	<51233FF502000078000BF4AE@nat28.tlf.novell.com>
	<1361264324.1051.61.camel@zakaz.uk.xensource.com>
	<20130219.130607.100487415380997622.davem@davemloft.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"drjones@redhat.com" <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 18:06 +0000, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@citrix.com>
> Date: Tue, 19 Feb 2013 08:58:44 +0000
> 
> > On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
> >> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
> >> > From: Andrew Jones <drjones@redhat.com>
> >> > Date: Mon, 18 Feb 2013 21:29:20 +0100
> >> > 
> >> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> >> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> >> >> have one reference to the vif at this time, then the xenvif_put
> >> >> in netbk_fatal_tx_err is one too many.
> >> >> 
> >> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
> >> > 
> >> > Applied.
> >> 
> >> But this is wrong from all we can tell,
> > 
> > Yes, please can this be reverted.
> 
> Done and I've annotated the revert commit message with as much
> information as possible.

Thanks, 629821d9b looks good to me.

May be worth considering the patch in
<1361281636.1051.100.camel@zakaz.uk.xensource.com> if we get many more
of these queries...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 09:50:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09:50: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 1U86JO-0000HW-2R; Wed, 20 Feb 2013 09:50:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U86JL-0000HR-NK
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 09:50:00 +0000
Received: from [85.158.138.51:16515] by server-1.bemta-3.messagelabs.com id
	FD/9D-08955-64C94215; Wed, 20 Feb 2013 09:49:58 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361353747!28328472!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjI3ODIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26158 invoked from network); 20 Feb 2013 09:49:08 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-11.tower-174.messagelabs.com with SMTP;
	20 Feb 2013 09:49:08 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 4386B14C;
	Wed, 20 Feb 2013 20:49:03 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361353743; bh=ndLWWoZx5UdVzVzFAQjFTXmP+ksqhcHn+WzORJTzbms=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=botrdNMAeQ+UGFR3/BD9Mr/uTMM0DXQPhUQ8vdZdejxD2IiCredfnv2296gfsCgsm
	5y5HPK9Rb7+0i/6EumMmV+6Q7HOHa57Ck8cj7//d2XxAyAJrLdIDmQeEWvO2xZLqxn
	FvdYnvN5bAubHqZzw0r4dtmZLOWeaivU2f6XjFtY=
Message-ID: <51249C11.3050800@crc.id.au>
Date: Wed, 20 Feb 2013 20:49:05 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au>
In-Reply-To: <51248E23.7060408@crc.id.au>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============6385227960301240997=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6385227960301240997==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030608020007040901010909"

This is a cryptographically signed message in MIME format.

--------------ms030608020007040901010909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 20/02/2013 7:49 PM, Steven Haigh wrote:
> On 20/02/2013 7:26 PM, Roger Pau Monn=E9 wrote:
>> On 20/02/13 03:10, Steven Haigh wrote:
>>> Hi guys,
>>>
>>> Firstly, please CC me in to any replies as I'm not a subscriber these=

>>> days.
>>>
>>> I've been trying to debug a problem with Xen 4.2.1 where I am unable =
to
>>> achieve more than ~50Mb/sec sustained sequential write to a disk. The=

>>> DomU is configured as such:
>>
>> Since you mention 4.2.1 explicitly, is this a performance regression
>> from previous versions? (4.2.0 or the 4.1 branch)
>
> This is actually a very good question. I've reinstalled my older
> packages of Xen 4.1.3 back on the system. Rebooting into the new
> hypervisor, then starting the single DomU again. Ran bonnie++ again on
> the DomU:
>
> Still around 50Mb/sec - so this doesn't seem to be a regression, but
> something else?

I've actually done a bit of thinking about this... A recent thread on=20
linux-raid kernel mailing list about Xen and DomU throughput made me=20
revisit my setup. I know I used to be able to saturate GigE both ways=20
(send and receive) to the samba share served by this DomU. This would=20
mean I'd get at least 90-100Mbyte/sec. What exact config and kernel/xen=20
versions this was as this point in time I cannot say.

As such, I had a bit of a play and recreated my RAID6 with 64Kb chunk=20
size. This seemed to make rebuild/resync speeds way worse - so I=20
reverted to 128Kb chunk size.

The benchmarks I am getting from the Dom0 is about what I'd expect - but =

I wouldn't expect to lose 130Mb/sec write speed to the phy:/ pass=20
through of the LV.

 From my known config where I could saturate the GigE connection, I have =

changed from kernel 2.6.32 (Jeremy's git repo) to the latest vanilla=20
kernels - currently 3.7.9.

My build of Xen 4.2.1 also has all of the recent security advisories=20
patched as well. Although it is interesting to note that downgrading to=20
Xen 4.1.2 made no difference to write speeds.

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms030608020007040901010909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAwOTQ5MDVaMCMGCSqGSIb3DQEJBDEWBBRY5aUDYP5JZwnms46L6UYBX9ag
bzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEAkyWGa+nJjVpYxm0/F5qg9kTR
MYmhRmhn0rkw4NGwjZX6/mVT1TSt/WyjyfXEwSnWikP0c7W8K4JBkw6Zq9o4n9MtyXeOy54g
fR/J6gX/53VafET8GjXg0TO5jqTyiiA7BBKhGshOf/DZ285zuDqB1jE6H+BahH9m8HAWWHs2
GMS+4aSByMGWcnkqFYkXjydtJN+g1nsSORDCJwxy61OLngJqFQpcbSnPtWmreQ+e5bZnxM2V
ETq/5xBVse1A7W1xMiXqDJjDteavg42IEL0qieFK0G02Fboj9xrJsMG7qaFx1WxeqcrODKIo
uPkVTeQaEl9Xlzk6lme5KBgytC+kFAAAAAAAAA==
--------------ms030608020007040901010909--


--===============6385227960301240997==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6385227960301240997==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 09:50:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09:50: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 1U86JO-0000HW-2R; Wed, 20 Feb 2013 09:50:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U86JL-0000HR-NK
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 09:50:00 +0000
Received: from [85.158.138.51:16515] by server-1.bemta-3.messagelabs.com id
	FD/9D-08955-64C94215; Wed, 20 Feb 2013 09:49:58 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361353747!28328472!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNjI3ODIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26158 invoked from network); 20 Feb 2013 09:49:08 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-11.tower-174.messagelabs.com with SMTP;
	20 Feb 2013 09:49:08 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 4386B14C;
	Wed, 20 Feb 2013 20:49:03 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361353743; bh=ndLWWoZx5UdVzVzFAQjFTXmP+ksqhcHn+WzORJTzbms=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=botrdNMAeQ+UGFR3/BD9Mr/uTMM0DXQPhUQ8vdZdejxD2IiCredfnv2296gfsCgsm
	5y5HPK9Rb7+0i/6EumMmV+6Q7HOHa57Ck8cj7//d2XxAyAJrLdIDmQeEWvO2xZLqxn
	FvdYnvN5bAubHqZzw0r4dtmZLOWeaivU2f6XjFtY=
Message-ID: <51249C11.3050800@crc.id.au>
Date: Wed, 20 Feb 2013 20:49:05 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au>
In-Reply-To: <51248E23.7060408@crc.id.au>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============6385227960301240997=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6385227960301240997==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030608020007040901010909"

This is a cryptographically signed message in MIME format.

--------------ms030608020007040901010909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 20/02/2013 7:49 PM, Steven Haigh wrote:
> On 20/02/2013 7:26 PM, Roger Pau Monn=E9 wrote:
>> On 20/02/13 03:10, Steven Haigh wrote:
>>> Hi guys,
>>>
>>> Firstly, please CC me in to any replies as I'm not a subscriber these=

>>> days.
>>>
>>> I've been trying to debug a problem with Xen 4.2.1 where I am unable =
to
>>> achieve more than ~50Mb/sec sustained sequential write to a disk. The=

>>> DomU is configured as such:
>>
>> Since you mention 4.2.1 explicitly, is this a performance regression
>> from previous versions? (4.2.0 or the 4.1 branch)
>
> This is actually a very good question. I've reinstalled my older
> packages of Xen 4.1.3 back on the system. Rebooting into the new
> hypervisor, then starting the single DomU again. Ran bonnie++ again on
> the DomU:
>
> Still around 50Mb/sec - so this doesn't seem to be a regression, but
> something else?

I've actually done a bit of thinking about this... A recent thread on=20
linux-raid kernel mailing list about Xen and DomU throughput made me=20
revisit my setup. I know I used to be able to saturate GigE both ways=20
(send and receive) to the samba share served by this DomU. This would=20
mean I'd get at least 90-100Mbyte/sec. What exact config and kernel/xen=20
versions this was as this point in time I cannot say.

As such, I had a bit of a play and recreated my RAID6 with 64Kb chunk=20
size. This seemed to make rebuild/resync speeds way worse - so I=20
reverted to 128Kb chunk size.

The benchmarks I am getting from the Dom0 is about what I'd expect - but =

I wouldn't expect to lose 130Mb/sec write speed to the phy:/ pass=20
through of the LV.

 From my known config where I could saturate the GigE connection, I have =

changed from kernel 2.6.32 (Jeremy's git repo) to the latest vanilla=20
kernels - currently 3.7.9.

My build of Xen 4.2.1 also has all of the recent security advisories=20
patched as well. Although it is interesting to note that downgrading to=20
Xen 4.1.2 made no difference to write speeds.

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms030608020007040901010909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAwOTQ5MDVaMCMGCSqGSIb3DQEJBDEWBBRY5aUDYP5JZwnms46L6UYBX9ag
bzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEAkyWGa+nJjVpYxm0/F5qg9kTR
MYmhRmhn0rkw4NGwjZX6/mVT1TSt/WyjyfXEwSnWikP0c7W8K4JBkw6Zq9o4n9MtyXeOy54g
fR/J6gX/53VafET8GjXg0TO5jqTyiiA7BBKhGshOf/DZ285zuDqB1jE6H+BahH9m8HAWWHs2
GMS+4aSByMGWcnkqFYkXjydtJN+g1nsSORDCJwxy61OLngJqFQpcbSnPtWmreQ+e5bZnxM2V
ETq/5xBVse1A7W1xMiXqDJjDteavg42IEL0qieFK0G02Fboj9xrJsMG7qaFx1WxeqcrODKIo
uPkVTeQaEl9Xlzk6lme5KBgytC+kFAAAAAAAAA==
--------------ms030608020007040901010909--


--===============6385227960301240997==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6385227960301240997==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 09:58:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09:58: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 1U86R3-0000UC-4j; Wed, 20 Feb 2013 09:57:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U86R1-0000U7-NO
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 09:57:55 +0000
Received: from [85.158.138.51:31398] by server-15.bemta-3.messagelabs.com id
	E1/4B-25405-22E94215; Wed, 20 Feb 2013 09:57:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361354256!28399897!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19706 invoked from network); 20 Feb 2013 09:57:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 09:57:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1643645"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 09:57:29 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 20 Feb 2013
	09:57:29 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 09:57:38 +0000
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcIABbPsQ
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
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] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: James Harper [mailto:james.harper@bendigoit.com.au]
> Sent: 19 February 2013 12:10
> To: Paul Durrant; Andreas Kinzler; xen-devel@lists.xensource.com
> Subject: RE: State of GPLPV and Windows 8
> 
> >
> > Windows 8 doesn't actually shut down when you tell it to... It terminates all
> > sessions apart from 0 (where services live) and then hibernates, so
> > 'shutdown' is actually a lot more complex and error prone than it was
> before.
> >
> 
> I've gotten it all working now, but the restore from hibernate (which appears
> to use qemu) is slow. The hibernate on a 1GB machine takes seconds but the
> restore takes over a minute.
> 

Yes, I've noticed Windows 8 seemingly taking a lot longer to load/restore than previous versions but never dug into it. I'm assuming it's going to be some suboptimal int13 handing, or maybe Windows 8 is bypassing the f/w and driving the IDE device itself?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 09:58:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09:58: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 1U86R3-0000UC-4j; Wed, 20 Feb 2013 09:57:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U86R1-0000U7-NO
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 09:57:55 +0000
Received: from [85.158.138.51:31398] by server-15.bemta-3.messagelabs.com id
	E1/4B-25405-22E94215; Wed, 20 Feb 2013 09:57:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361354256!28399897!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19706 invoked from network); 20 Feb 2013 09:57:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 09:57:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1643645"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 09:57:29 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 20 Feb 2013
	09:57:29 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 09:57:38 +0000
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcIABbPsQ
Message-ID: <291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
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] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: James Harper [mailto:james.harper@bendigoit.com.au]
> Sent: 19 February 2013 12:10
> To: Paul Durrant; Andreas Kinzler; xen-devel@lists.xensource.com
> Subject: RE: State of GPLPV and Windows 8
> 
> >
> > Windows 8 doesn't actually shut down when you tell it to... It terminates all
> > sessions apart from 0 (where services live) and then hibernates, so
> > 'shutdown' is actually a lot more complex and error prone than it was
> before.
> >
> 
> I've gotten it all working now, but the restore from hibernate (which appears
> to use qemu) is slow. The hibernate on a 1GB machine takes seconds but the
> restore takes over a minute.
> 

Yes, I've noticed Windows 8 seemingly taking a lot longer to load/restore than previous versions but never dug into it. I'm assuming it's going to be some suboptimal int13 handing, or maybe Windows 8 is bypassing the f/w and driving the IDE device itself?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 09:59:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09:59: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 1U86Rl-0000WR-J1; Wed, 20 Feb 2013 09:58: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 1U86Rk-0000WG-D2
	for Xen-devel@lists.xensource.com; Wed, 20 Feb 2013 09:58:40 +0000
Received: from [193.109.254.147:13947] by server-3.bemta-14.messagelabs.com id
	C6/4B-22141-F4E94215; Wed, 20 Feb 2013 09:58:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361354309!1778589!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10473 invoked from network); 20 Feb 2013 09:58:30 -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; 20 Feb 2013 09:58:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U86RY-0003Ap-RW; Wed, 20 Feb 2013 09:58:28 +0000
Date: Wed, 20 Feb 2013 09:58:28 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130220095828.GA12083@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130219160534.062dba2f@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] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> On Thu, 24 Jan 2013 16:31:22 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > +
> > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > +        {
> > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > +                pv_cpuid(regs);
> > > +
> > > +                /* Because we are setting CR4.OSFXSR to 0, we need
> > > to disable
> > > +                 * this because, during boot, user process
> > > "init" (which doesn't
> > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and cause
> > > #UD. For now 
> > > +                 * disable this. HVM doesn't allow setting of
> > > CR4.OSFXSR.
> > > +                 * fixme: this and also look at CR4.OSXSAVE */
> > > +
> > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > 
> > Shouldn't this be gated on which leaf the guest asked for?
> 
> Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't work. 
> The user process "init" running nash is executing pxor %xmm0, %xmm0 and
> taking #UD. Strangely, it works with EAX==0, meaning if I clear the bit
> for EAX==0, changing the intel string "ineI".  This user process doesn't
> do cpuid, so it must be affected by it some other way.
> 
> Pretty hard to debug since it's in nash user code from ramdisk and I am 
> not able to set breakpoint or put printf's easily to figure why clearing
> bit for EAX==0 makes it work, or what's going on for PV and HVM guest.
> CR0.EM is 0, so UD is coming from CR4.OSFXSR==0. Reading the SDMs to
> learn OSFXSR stuff better....

Perhaps you need to clear the FXSR feature bit in leaf 0x80000001:EDX as
well?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 09:59:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 09:59: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 1U86Rl-0000WR-J1; Wed, 20 Feb 2013 09:58: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 1U86Rk-0000WG-D2
	for Xen-devel@lists.xensource.com; Wed, 20 Feb 2013 09:58:40 +0000
Received: from [193.109.254.147:13947] by server-3.bemta-14.messagelabs.com id
	C6/4B-22141-F4E94215; Wed, 20 Feb 2013 09:58:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361354309!1778589!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10473 invoked from network); 20 Feb 2013 09:58:30 -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; 20 Feb 2013 09:58:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U86RY-0003Ap-RW; Wed, 20 Feb 2013 09:58:28 +0000
Date: Wed, 20 Feb 2013 09:58:28 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130220095828.GA12083@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130219160534.062dba2f@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] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> On Thu, 24 Jan 2013 16:31:22 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > +
> > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > +        {
> > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > +                pv_cpuid(regs);
> > > +
> > > +                /* Because we are setting CR4.OSFXSR to 0, we need
> > > to disable
> > > +                 * this because, during boot, user process
> > > "init" (which doesn't
> > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and cause
> > > #UD. For now 
> > > +                 * disable this. HVM doesn't allow setting of
> > > CR4.OSFXSR.
> > > +                 * fixme: this and also look at CR4.OSXSAVE */
> > > +
> > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > 
> > Shouldn't this be gated on which leaf the guest asked for?
> 
> Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't work. 
> The user process "init" running nash is executing pxor %xmm0, %xmm0 and
> taking #UD. Strangely, it works with EAX==0, meaning if I clear the bit
> for EAX==0, changing the intel string "ineI".  This user process doesn't
> do cpuid, so it must be affected by it some other way.
> 
> Pretty hard to debug since it's in nash user code from ramdisk and I am 
> not able to set breakpoint or put printf's easily to figure why clearing
> bit for EAX==0 makes it work, or what's going on for PV and HVM guest.
> CR0.EM is 0, so UD is coming from CR4.OSFXSR==0. Reading the SDMs to
> learn OSFXSR stuff better....

Perhaps you need to clear the FXSR feature bit in leaf 0x80000001:EDX as
well?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 10:12:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U86eH-0000wW-Tv; Wed, 20 Feb 2013 10:11:37 +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 1U86eG-0000wR-Nn
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 10:11:36 +0000
Received: from [85.158.138.51:38823] by server-4.bemta-3.messagelabs.com id
	8D/9A-17521-751A4215; Wed, 20 Feb 2013 10:11:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361355095!28333851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11706 invoked from network); 20 Feb 2013 10:11:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2013 10:11:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Feb 2013 10:11:34 +0000
Message-Id: <5124AF9F02000078000BFA35@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 20 Feb 2013 10:12:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steven Haigh" <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
In-Reply-To: <51249C11.3050800@crc.id.au>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, roger.pau@citrix.com
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
> My build of Xen 4.2.1 also has all of the recent security advisories 
> patched as well. Although it is interesting to note that downgrading to 
> Xen 4.1.2 made no difference to write speeds.

Not surprising at all, considering that the hypervisor is only a passive
library for all PV I/O purposes. You're likely hunting for a kernel side
regression (and hence the mentioning of the hypervisor version as
the main factor in the subject is probably misleading).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 10:12:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U86eH-0000wW-Tv; Wed, 20 Feb 2013 10:11:37 +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 1U86eG-0000wR-Nn
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 10:11:36 +0000
Received: from [85.158.138.51:38823] by server-4.bemta-3.messagelabs.com id
	8D/9A-17521-751A4215; Wed, 20 Feb 2013 10:11:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361355095!28333851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11706 invoked from network); 20 Feb 2013 10:11:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2013 10:11:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 20 Feb 2013 10:11:34 +0000
Message-Id: <5124AF9F02000078000BFA35@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 20 Feb 2013 10:12:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Steven Haigh" <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
In-Reply-To: <51249C11.3050800@crc.id.au>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, roger.pau@citrix.com
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
> My build of Xen 4.2.1 also has all of the recent security advisories 
> patched as well. Although it is interesting to note that downgrading to 
> Xen 4.1.2 made no difference to write speeds.

Not surprising at all, considering that the hypervisor is only a passive
library for all PV I/O purposes. You're likely hunting for a kernel side
regression (and hence the mentioning of the hypervisor version as
the main factor in the subject is probably misleading).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 10:26:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 10:26: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 1U86sa-00019U-BJ; Wed, 20 Feb 2013 10:26:24 +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 1U86sZ-00019P-2n
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 10:26:23 +0000
Received: from [85.158.139.211:25754] by server-15.bemta-5.messagelabs.com id
	21/73-18914-EC4A4215; Wed, 20 Feb 2013 10:26:22 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361355947!18392355!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24435 invoked from network); 20 Feb 2013 10:25:50 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-4.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 10:25:50 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U86ri-0003Kp-80; Wed, 20 Feb 2013 21:25:30 +1100
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 id
	14.01.0438.000; Wed, 20 Feb 2013 21:25:29 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcIABbPsQgAAGzVA=
Date: Wed, 20 Feb 2013 10:25:28 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3568763C@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [203.193.205.129]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19648.006
x-tm-as-result: No--44.291000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 8 doesn't actually shut down when you tell it to... It terminates
> > > all
> > > sessions apart from 0 (where services live) and then hibernates, so
> > > 'shutdown' is actually a lot more complex and error prone than it was
> > > before.
> > >
> >
> > I've gotten it all working now, but the restore from hibernate (which
> > appears
> > to use qemu) is slow. The hibernate on a 1GB machine takes seconds but
> > the restore takes over a minute.
> >
> 
> Yes, I've noticed Windows 8 seemingly taking a lot longer to load/restore
> than previous versions but never dug into it. I'm assuming it's going to be
> some suboptimal int13 handing, or maybe Windows 8 is bypassing the f/w
> and driving the IDE device itself?
> 

Direct IDE seems a bit risky... it's all black box stuff though so anything goes :)

I've been doing a bit more reading and it seems that win8 is able to involve the storport drive in the restore process too, I think. From http://msdn.microsoft.com/en-us/library/windows/hardware/ff563901%28v=vs.85%29.aspx

DumpMode
A value indicating the use of the miniport during dump mode. This member is included starting with Windows 8. It can have one of the following values.
DUMP_MODE_CRASH - The miniport in dump mode is used for a crashdump.
DUMP_MODE_HIBER - The miniport in dump mode is used for a hibernation.
DUMP_MODE_MARK_MEMORY - The miniport in dump mode is used for marking required memory.
DUMP_MODE_RESUME - The miniport in dump mode is used for a resume from hibernation.

In order to play with that I'd need to download the win8 DDK (the visual studio based one) which I'm not real keen on doing just yet...

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 10:26:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 10:26: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 1U86sa-00019U-BJ; Wed, 20 Feb 2013 10:26:24 +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 1U86sZ-00019P-2n
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 10:26:23 +0000
Received: from [85.158.139.211:25754] by server-15.bemta-5.messagelabs.com id
	21/73-18914-EC4A4215; Wed, 20 Feb 2013 10:26:22 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361355947!18392355!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24435 invoked from network); 20 Feb 2013 10:25:50 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-4.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 10:25:50 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U86ri-0003Kp-80; Wed, 20 Feb 2013 21:25:30 +1100
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 id
	14.01.0438.000; Wed, 20 Feb 2013 21:25:29 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcIABbPsQgAAGzVA=
Date: Wed, 20 Feb 2013 10:25:28 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3568763C@BITCOM1.int.sbss.com.au>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [203.193.205.129]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19648.006
x-tm-as-result: No--44.291000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 8 doesn't actually shut down when you tell it to... It terminates
> > > all
> > > sessions apart from 0 (where services live) and then hibernates, so
> > > 'shutdown' is actually a lot more complex and error prone than it was
> > > before.
> > >
> >
> > I've gotten it all working now, but the restore from hibernate (which
> > appears
> > to use qemu) is slow. The hibernate on a 1GB machine takes seconds but
> > the restore takes over a minute.
> >
> 
> Yes, I've noticed Windows 8 seemingly taking a lot longer to load/restore
> than previous versions but never dug into it. I'm assuming it's going to be
> some suboptimal int13 handing, or maybe Windows 8 is bypassing the f/w
> and driving the IDE device itself?
> 

Direct IDE seems a bit risky... it's all black box stuff though so anything goes :)

I've been doing a bit more reading and it seems that win8 is able to involve the storport drive in the restore process too, I think. From http://msdn.microsoft.com/en-us/library/windows/hardware/ff563901%28v=vs.85%29.aspx

DumpMode
A value indicating the use of the miniport during dump mode. This member is included starting with Windows 8. It can have one of the following values.
DUMP_MODE_CRASH - The miniport in dump mode is used for a crashdump.
DUMP_MODE_HIBER - The miniport in dump mode is used for a hibernation.
DUMP_MODE_MARK_MEMORY - The miniport in dump mode is used for marking required memory.
DUMP_MODE_RESUME - The miniport in dump mode is used for a resume from hibernation.

In order to play with that I'd need to download the win8 DDK (the visual studio based one) which I'm not real keen on doing just yet...

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 10:58:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 10:58: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 1U87My-0001it-P5; Wed, 20 Feb 2013 10:57:48 +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 1U87Mw-0001im-EU
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 10:57:46 +0000
Received: from [85.158.139.211:50553] by server-2.bemta-5.messagelabs.com id
	F1/89-16911-92CA4215; Wed, 20 Feb 2013 10:57:45 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361357864!18375612!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24506 invoked from network); 20 Feb 2013 10:57:44 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 10:57:44 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id F3196400360;
	Wed, 20 Feb 2013 11:57:43 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id XVQdGS10jkEP; Wed, 20 Feb 2013 11:57:43 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id C3B2840031A;
	Wed, 20 Feb 2013 11:57:42 +0100 (CET)
Message-ID: <5124AC22.4010206@tiscali.it>
Date: Wed, 20 Feb 2013 11:57:38 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: fantonifabio@tiscali.it
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it>
In-Reply-To: <511CCB2F.20608@tiscali.it>
Cc: James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============1730268517154979382=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1730268517154979382==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060201040109050500080100"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060201040109050500080100
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 14/02/2013 12:31, Fabio Fantoni ha scritto:
> Il 14/02/2013 12:16, James Harper ha scritto:
>>> Il 13/02/2013 23:26, James Harper ha scritto:
>>>>> I have tried to build gplpv from source with makedist.bat but it=20
>>>>> gave me
>>>>> some errors about files not found.
>>>>> I saw that latest commits were big. Is there something incomplete a=
nd
>>>>> must I wait other commits before build it?
>>>> It's possible I missed a commit but I can't see any missing files.
>>>>
>>>> Can you post the output of makedist?
>>>>
>>>> But yes the latest commits involve a pretty major change and I haven=
't
>>> tested save/restore yet so that is probably more broken than before.
>>>
>>> I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at r=
ev
>>> 1020.
>>> I launched makedist.bat but it gives same errors on each arch build, =

>>> see
>>> below the output:
>>>
>> Ok so it can't find the cat files... I'll need the whole output of=20
>> makedist.bat (or at least from the start of the wlh amd64 build) to=20
>> find out - there must have been a previous error causing a failure to =

>> generate the cat files.
>>
>> James
>>
>
> I added as attachment the build log for this, can be sufficent? If you =

> need other test/data tell me and I'll post them.
>

Retried now with rev 1029 and gave the same errors.

>>> ...
>>> 1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c=

>>> 1>Linking Executable -
>>> waitnopendinginstallevents\waitnopendinginstallevents\obj
>>> fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
>>> BUILD: Finish time: Thu Feb 14 11:53:50 2013
>>> BUILD: Done
>>>
>>>       75 files compiled
>>>       2 libraries built
>>>       8 executables built
>>> Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> installer.wxs
>>> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system
>>> cannot find
>>> the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system
>>> cannot find
>>> the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>>> C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system
>>> cannot find
>>> the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
>>> C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
>>> C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
>>> C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
>>> C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>>> SignTool Error: File not found: /t
>>>
>>>>> I would like to see if new build fix network not working after=20
>>>>> restore
>>>>> on windows domUs using upstream qemu.
>>>>> Dom0 is wheezy with xen-unstable from source.
>>>>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found=

>>>>> error on xen for now, probably is problem of gplpv with qemu=20
>>>>> upstream.
>>>>> Linux hvm domUs seem not have that problem, tested with quantal
>>> (ubuntu
>>>>> 12.10) and network works also after restore.
>>>>> If you need more details and tests tell me and I'll post it.
>>>>>
>>>>> Another problem present on both traditional/upstream qemu with
>>>>> older/new xen and  older/new gplpv is domU's time not correctly
>>> updated
>>>>> after restore (it remains the time at the save operation), this is =

>>>>> a big
>>>>> problem with windows domUs (DC and client) in a windows domain
>>> where
>>>>> the time source is DC by default.
>>>> I noticed that recently. I can't think how it could be a GPLPV bug=20
>>>> though.
>>> What can we try to narrow down the problem?
>>>
>>>> James
>>>>
>>



--------------ms060201040109050500080100
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMDEwNTczOFowIwYJKoZIhvcNAQkEMRYEFOAC+usP/bF0trPbTxkMT6Bk
7/nDMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAYY2cxjySFufiEd2VxZnTAzXo
WI7nu8/Hvttd6CL9MMAj7crQR5sSKjyjOlisu6KU2xyAASyVdBiTVgQSJANNmvGBLY0GN1mD
9C+PwK4gzLGuHf21heay4Z0RM+5PX1+oTtomuq/GSGvoAT9EOYAqjfgxRx4Mthv9Z4wIIbFm
JmNEq8Ja3ZRq0PwvJIiPYSQH0OIFf1yofuhVKbCf9M7AABmbOC4KoFyaaZMBGi6eMcP9g/9c
ZSNCNxkMtwTes6bi2PhgaIGzk4tEGQU6FUSicVPUH1mftcBxW/wUFx0MEusx9mxKnA2f8dMT
ymCggUOx2tuPmPTIW7DCYG+jofPw1gAAAAAAAA==
--------------ms060201040109050500080100--


--===============1730268517154979382==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1730268517154979382==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 10:58:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 10:58: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 1U87My-0001it-P5; Wed, 20 Feb 2013 10:57:48 +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 1U87Mw-0001im-EU
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 10:57:46 +0000
Received: from [85.158.139.211:50553] by server-2.bemta-5.messagelabs.com id
	F1/89-16911-92CA4215; Wed, 20 Feb 2013 10:57:45 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361357864!18375612!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24506 invoked from network); 20 Feb 2013 10:57:44 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 10:57:44 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id F3196400360;
	Wed, 20 Feb 2013 11:57:43 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id XVQdGS10jkEP; Wed, 20 Feb 2013 11:57:43 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id C3B2840031A;
	Wed, 20 Feb 2013 11:57:42 +0100 (CET)
Message-ID: <5124AC22.4010206@tiscali.it>
Date: Wed, 20 Feb 2013 11:57:38 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: fantonifabio@tiscali.it
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it>
In-Reply-To: <511CCB2F.20608@tiscali.it>
Cc: James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============1730268517154979382=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1730268517154979382==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060201040109050500080100"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060201040109050500080100
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 14/02/2013 12:31, Fabio Fantoni ha scritto:
> Il 14/02/2013 12:16, James Harper ha scritto:
>>> Il 13/02/2013 23:26, James Harper ha scritto:
>>>>> I have tried to build gplpv from source with makedist.bat but it=20
>>>>> gave me
>>>>> some errors about files not found.
>>>>> I saw that latest commits were big. Is there something incomplete a=
nd
>>>>> must I wait other commits before build it?
>>>> It's possible I missed a commit but I can't see any missing files.
>>>>
>>>> Can you post the output of makedist?
>>>>
>>>> But yes the latest commits involve a pretty major change and I haven=
't
>>> tested save/restore yet so that is probably more broken than before.
>>>
>>> I have installed WDK 7600.1 and wix3, I have downloaded gplpv hg at r=
ev
>>> 1020.
>>> I launched makedist.bat but it gives same errors on each arch build, =

>>> see
>>> below the output:
>>>
>> Ok so it can't find the cat files... I'll need the whole output of=20
>> makedist.bat (or at least from the start of the wlh amd64 build) to=20
>> find out - there must have been a previous error causing a failure to =

>> generate the cat files.
>>
>> James
>>
>
> I added as attachment the build log for this, can be sufficent? If you =

> need other test/data tell me and I'll post them.
>

Retried now with rev 1029 and gave the same errors.

>>> ...
>>> 1>Compiling - waitnopendinginstallevents\waitnopendinginstallevents.c=

>>> 1>Linking Executable -
>>> waitnopendinginstallevents\waitnopendinginstallevents\obj
>>> fre_wlh_amd64\amd64\waitnopendinginstallevents.exe
>>> BUILD: Finish time: Thu Feb 14 11:53:50 2013
>>> BUILD: Done
>>>
>>>       75 files compiled
>>>       2 libraries built
>>>       8 executables built
>>> Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> installer.wxs
>>> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> C:\hg\win-pvdrivers\installer.wxs(75) : error LGHT0103 : The system
>>> cannot find
>>> the file 'xenpci\objfre_wlh_AMD64\amd64\xenpci.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(78) : error LGHT0103 : The system
>>> cannot find
>>> the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>>> C:\hg\win-pvdrivers\installer.wxs(95) : error LGHT0103 : The system
>>> cannot find
>>> the file 'xenvbd_storport\objfre_wlh_AMD64\amd64\xenvbd.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(105) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(106) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.inf'.
>>> C:\hg\win-pvdrivers\installer.wxs(107) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenscsi\objfre_wlh_AMD64\amd64\xenscsi.sys'.
>>> C:\hg\win-pvdrivers\installer.wxs(114) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xennet\objfre_wlh_AMD64\amd64\xennet.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(123) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.cat'.
>>> C:\hg\win-pvdrivers\installer.wxs(124) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.inf'.
>>> C:\hg\win-pvdrivers\installer.wxs(125) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenusb\objfre_wlh_AMD64\amd64\xenusb.sys'.
>>> C:\hg\win-pvdrivers\installer.wxs(127) : error LGHT0103 : The system
>>> cannot find
>>>    the file 'xenpci\objfre_wlh_AMD64\amd64\WdfCoInstaller01009.dll'.
>>> SignTool Error: File not found: /t
>>>
>>>>> I would like to see if new build fix network not working after=20
>>>>> restore
>>>>> on windows domUs using upstream qemu.
>>>>> Dom0 is wheezy with xen-unstable from source.
>>>>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found=

>>>>> error on xen for now, probably is problem of gplpv with qemu=20
>>>>> upstream.
>>>>> Linux hvm domUs seem not have that problem, tested with quantal
>>> (ubuntu
>>>>> 12.10) and network works also after restore.
>>>>> If you need more details and tests tell me and I'll post it.
>>>>>
>>>>> Another problem present on both traditional/upstream qemu with
>>>>> older/new xen and  older/new gplpv is domU's time not correctly
>>> updated
>>>>> after restore (it remains the time at the save operation), this is =

>>>>> a big
>>>>> problem with windows domUs (DC and client) in a windows domain
>>> where
>>>>> the time source is DC by default.
>>>> I noticed that recently. I can't think how it could be a GPLPV bug=20
>>>> though.
>>> What can we try to narrow down the problem?
>>>
>>>> James
>>>>
>>



--------------ms060201040109050500080100
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMDEwNTczOFowIwYJKoZIhvcNAQkEMRYEFOAC+usP/bF0trPbTxkMT6Bk
7/nDMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAYY2cxjySFufiEd2VxZnTAzXo
WI7nu8/Hvttd6CL9MMAj7crQR5sSKjyjOlisu6KU2xyAASyVdBiTVgQSJANNmvGBLY0GN1mD
9C+PwK4gzLGuHf21heay4Z0RM+5PX1+oTtomuq/GSGvoAT9EOYAqjfgxRx4Mthv9Z4wIIbFm
JmNEq8Ja3ZRq0PwvJIiPYSQH0OIFf1yofuhVKbCf9M7AABmbOC4KoFyaaZMBGi6eMcP9g/9c
ZSNCNxkMtwTes6bi2PhgaIGzk4tEGQU6FUSicVPUH1mftcBxW/wUFx0MEusx9mxKnA2f8dMT
ymCggUOx2tuPmPTIW7DCYG+jofPw1gAAAAAAAA==
--------------ms060201040109050500080100--


--===============1730268517154979382==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1730268517154979382==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 11:02:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:02: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 1U87RL-0001yW-Hu; Wed, 20 Feb 2013 11:02: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 1U87RK-0001yP-De
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:02:18 +0000
Received: from [193.109.254.147:22640] by server-12.bemta-14.messagelabs.com
	id 6D/1F-32582-93DA4215; Wed, 20 Feb 2013 11:02:17 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361357991!3390297!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDQ5NTc=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25784 invoked from network); 20 Feb 2013 10:59:52 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-6.tower-27.messagelabs.com with SMTP;
	20 Feb 2013 10:59:52 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id BB63D14C3DB;
	Wed, 20 Feb 2013 11:59:50 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Wed, 20 Feb 2013 11:59:11 +0100
Message-Id: <1361357951-5290-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v11] tools/libxl: Add qxl vga interface support
	for upstream 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="qxl"

Changes from v10:
- Some coding style fixes

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
---
 docs/man/xl.cfg.pod.5       |   10 +++++++++-
 tools/libxl/libxl_create.c  |   19 +++++++++++++++++--
 tools/libxl/libxl_dm.c      |   18 +++++++++++++++---
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |   11 +++++------
 5 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9c5def4..25523c9 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1003,6 +1003,9 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
+For B<qxl> vga, the default is both default and minimal 128MB.
+If B<videoram> is set less than 128MB, an error will be triggered.
+
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -1014,9 +1017,14 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus).
+Selects the emulated video card (stdvga|cirrus|qxl).
 The default is cirrus.
 
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.
+
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa81f88..efeebf2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -198,14 +198,29 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
 
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->device_model_version ==
+               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                    b_info->video_memkb = (128 * 1024);
+                } else if (b_info->video_memkb < (128 * 1024)) {
+                    LOG(ERROR,
+                        "128 Mib videoram is the minimum for qxl default");
+                    return ERROR_INVAL;
+                }
+            } else {
+                LOG(ERROR,"qemu upstream required for qxl vga");
+                return ERROR_INVAL;
+            }
+        }
+
         if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
             b_info->device_model_version ==
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
                 if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
                     b_info->video_memkb = 16 * 1024;
                 else if (b_info->video_memkb < (16 * 1024) ){
-                    LOG(ERROR,
-                    "videoram must be at least 16 mb with stdvga");
+                    LOG(ERROR, "videoram must be at least 16 mb with stdvga");
                     return ERROR_INVAL;
                 }
         } else if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2c99bd..c4ca11e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -435,9 +437,19 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
             if (b_info->video_memkb) {
                 flexarray_vappend(dm_args, "-global",
-                libxl__sprintf(gc, "vga.vram_size_mb=%d",
-                libxl__sizekb_to_mb(b_info->video_memkb)),
-                NULL);
+                    GCSPRINTF("vga.vram_size_mb=%d",
+                    libxl__sizekb_to_mb(b_info->video_memkb)), NULL);
+            }
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            /* QXL have 2 ram regions, ram and vram */
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                    GCSPRINTF("qxl-vga.vram_size_mb=%lu",
+                    (b_info->video_memkb/2/1024)), "-global",
+                    GCSPRINTF("qxl-vga.ram_size_mb=%lu",
+                    (b_info->video_memkb/2/1024)), NULL);
             }
             break;
         }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 89a8030..5b080ed 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..a98705e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1476,14 +1476,13 @@ skip_vfb:
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
             if (!strcmp(buf, "stdvga")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_STD;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
             } else if (!strcmp(buf, "cirrus")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            } else if (!strcmp(buf, "qxl")) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
-                fprintf(stderr,
-                "Unknown vga \"%s\" specified\n", buf);
+                fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
                 exit(1);
             }
         } else if (!xlu_cfg_get_long(config, "stdvga", &l, 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 Wed Feb 20 11:02:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:02: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 1U87RL-0001yW-Hu; Wed, 20 Feb 2013 11:02: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 1U87RK-0001yP-De
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:02:18 +0000
Received: from [193.109.254.147:22640] by server-12.bemta-14.messagelabs.com
	id 6D/1F-32582-93DA4215; Wed, 20 Feb 2013 11:02:17 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361357991!3390297!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDQ5NTc=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25784 invoked from network); 20 Feb 2013 10:59:52 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-6.tower-27.messagelabs.com with SMTP;
	20 Feb 2013 10:59:52 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id BB63D14C3DB;
	Wed, 20 Feb 2013 11:59:50 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Wed, 20 Feb 2013 11:59:11 +0100
Message-Id: <1361357951-5290-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Zhou Peng <zpengxen@gmail.com>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v11] tools/libxl: Add qxl vga interface support
	for upstream 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Usage:
  vga="qxl"

Changes from v10:
- Some coding style fixes

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
---
 docs/man/xl.cfg.pod.5       |   10 +++++++++-
 tools/libxl/libxl_create.c  |   19 +++++++++++++++++--
 tools/libxl/libxl_dm.c      |   18 +++++++++++++++---
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |   11 +++++------
 5 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 9c5def4..25523c9 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1003,6 +1003,9 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
+For B<qxl> vga, the default is both default and minimal 128MB.
+If B<videoram> is set less than 128MB, an error will be triggered.
+
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -1014,9 +1017,14 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus).
+Selects the emulated video card (stdvga|cirrus|qxl).
 The default is cirrus.
 
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.
+
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa81f88..efeebf2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -198,14 +198,29 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
 
+        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            if (b_info->device_model_version ==
+               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                    b_info->video_memkb = (128 * 1024);
+                } else if (b_info->video_memkb < (128 * 1024)) {
+                    LOG(ERROR,
+                        "128 Mib videoram is the minimum for qxl default");
+                    return ERROR_INVAL;
+                }
+            } else {
+                LOG(ERROR,"qemu upstream required for qxl vga");
+                return ERROR_INVAL;
+            }
+        }
+
         if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
             b_info->device_model_version ==
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
                 if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
                     b_info->video_memkb = 16 * 1024;
                 else if (b_info->video_memkb < (16 * 1024) ){
-                    LOG(ERROR,
-                    "videoram must be at least 16 mb with stdvga");
+                    LOG(ERROR, "videoram must be at least 16 mb with stdvga");
                     return ERROR_INVAL;
                 }
         } else if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a2c99bd..c4ca11e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -435,9 +437,19 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
             if (b_info->video_memkb) {
                 flexarray_vappend(dm_args, "-global",
-                libxl__sprintf(gc, "vga.vram_size_mb=%d",
-                libxl__sizekb_to_mb(b_info->video_memkb)),
-                NULL);
+                    GCSPRINTF("vga.vram_size_mb=%d",
+                    libxl__sizekb_to_mb(b_info->video_memkb)), NULL);
+            }
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            /* QXL have 2 ram regions, ram and vram */
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
+            if (b_info->video_memkb) {
+                flexarray_vappend(dm_args, "-global",
+                    GCSPRINTF("qxl-vga.vram_size_mb=%lu",
+                    (b_info->video_memkb/2/1024)), "-global",
+                    GCSPRINTF("qxl-vga.ram_size_mb=%lu",
+                    (b_info->video_memkb/2/1024)), NULL);
             }
             break;
         }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 89a8030..5b080ed 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,6 +130,7 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..a98705e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1476,14 +1476,13 @@ skip_vfb:
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_string (config, "vga", &buf, 0)) {
             if (!strcmp(buf, "stdvga")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_STD;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
             } else if (!strcmp(buf, "cirrus")) {
-                b_info->u.hvm.vga.kind
-                = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            } else if (!strcmp(buf, "qxl")) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
-                fprintf(stderr,
-                "Unknown vga \"%s\" specified\n", buf);
+                fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
                 exit(1);
             }
         } else if (!xlu_cfg_get_long(config, "stdvga", &l, 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 Wed Feb 20 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11: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 1U87Sr-00024W-3D; Wed, 20 Feb 2013 11:03:53 +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 1U87Sp-00024M-F0
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:03:51 +0000
Received: from [85.158.138.51:18020] by server-3.bemta-3.messagelabs.com id
	92/11-31070-69DA4215; Wed, 20 Feb 2013 11:03:50 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361358226!19627855!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4817 invoked from network); 20 Feb 2013 11:03:49 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 11:03:49 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U87SZ-0001eT-BX; Wed, 20 Feb 2013 22:03:37 +1100
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 id
	14.01.0438.000; Wed, 20 Feb 2013 22:03:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTAgAAecoCAALiu8P//TGeAgAlkZACAALm24A==
Date: Wed, 20 Feb 2013 11:03:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
In-Reply-To: <5124AC22.4010206@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [203.193.205.129]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19648.006
x-tm-as-result: No--39.172200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV 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

> > I added as attachment the build log for this, can be sufficent? If you
> > need other test/data tell me and I'll post them.
> >
> 
> Retried now with rev 1029 and gave the same errors.
> 

I also need the output of the build that gets printed to the console. Go into command prompt and set the buffer length to 9999 or whatever the limit is then do the makedist then copy the lot into an email. Do a cls first to clear the buffer.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:04:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11: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 1U87Sr-00024W-3D; Wed, 20 Feb 2013 11:03:53 +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 1U87Sp-00024M-F0
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:03:51 +0000
Received: from [85.158.138.51:18020] by server-3.bemta-3.messagelabs.com id
	92/11-31070-69DA4215; Wed, 20 Feb 2013 11:03:50 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361358226!19627855!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4817 invoked from network); 20 Feb 2013 11:03:49 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 11:03:49 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U87SZ-0001eT-BX; Wed, 20 Feb 2013 22:03:37 +1100
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 id
	14.01.0438.000; Wed, 20 Feb 2013 22:03:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTAgAAecoCAALiu8P//TGeAgAlkZACAALm24A==
Date: Wed, 20 Feb 2013 11:03:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
In-Reply-To: <5124AC22.4010206@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [203.193.205.129]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19648.006
x-tm-as-result: No--39.172200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV 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

> > I added as attachment the build log for this, can be sufficent? If you
> > need other test/data tell me and I'll post them.
> >
> 
> Retried now with rev 1029 and gave the same errors.
> 

I also need the output of the build that gets printed to the console. Go into command prompt and set the buffer length to 9999 or whatever the limit is then do the makedist then copy the lot into an email. Do a cls first to clear the buffer.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:05:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U87UX-0002Cy-K9; Wed, 20 Feb 2013 11:05:37 +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 1U87UV-0002Ce-PN
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:05:36 +0000
Received: from [85.158.139.211:18161] by server-7.bemta-5.messagelabs.com id
	E4/7F-11121-FFDA4215; Wed, 20 Feb 2013 11:05:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361358315!18436697!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32317 invoked from network); 20 Feb 2013 11:05:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:05:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7977149"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:05:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:05:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U87U9-0005z9-Vd;
	Wed, 20 Feb 2013 11:05:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:05:09 +0000
Message-ID: <1361358309-32191-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
References: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Poll() can support more file descriptors than select(). We've done this for
xenconsoled, now do this for cxenstored as well.

The code is taken from xenconsoled and modified to adapt to cxenstored.

Updated:
* reopen pipe if polling on reopen_log_pipe fails.
* exit if polling on some critical fds fails.
* clean up POLL*.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/xenstore/xenstored_core.c |  171 ++++++++++++++++++++++++++-------------
 tools/xenstore/xenstored_core.h |    2 +
 2 files changed, 116 insertions(+), 57 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index bd44645..839e51d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,7 +19,7 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/select.h>
+#include <poll.h>
 #ifndef NO_SOCKETS
 #include <sys/socket.h>
 #include <sys/un.h>
@@ -55,6 +55,12 @@
 #include "hashtable.h"
 
 extern xc_evtchn *xce_handle; /* in xenstored_domain.c */
+static struct pollfd *xce_pollfd;
+static struct pollfd *fds;
+static unsigned int current_array_size;
+static unsigned int nr_fds;
+
+#define ROUNDUP(_x, _w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
 static bool verbose = false;
 LIST_HEAD(connections);
@@ -62,6 +68,7 @@ static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
+static struct pollfd *reopen_log_pipe0_pollfd;
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx = NULL;
 
@@ -199,7 +206,7 @@ void trace_destroy(const void *data, const char *type)
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
- * the select() in the main loop.
+ * the poll() in the main loop.
  */
 static void trigger_reopen_log(int signal __attribute__((unused)))
 {
@@ -279,15 +286,12 @@ static int destroy_conn(void *_conn)
 
 	/* Flush outgoing if possible, but don't block. */
 	if (!conn->domain) {
-		fd_set set;
-		struct timeval none;
-
-		FD_ZERO(&set);
-		FD_SET(conn->fd, &set);
-		none.tv_sec = none.tv_usec = 0;
+		struct pollfd pfd;
+		pfd.fd = conn->fd;
+		pfd.events = POLLOUT;
 
 		while (!list_empty(&conn->out_list)
-		       && select(conn->fd+1, NULL, &set, NULL, &none) == 1)
+		       && poll(&pfd, 1, 0) == 1)
 			if (!write_messages(conn))
 				break;
 		close(conn->fd);
@@ -300,52 +304,74 @@ static int destroy_conn(void *_conn)
 }
 
 
-static void set_fd(int fd, fd_set *set, int *max)
+static struct pollfd *set_fd(int fd, short events)
 {
-	if (fd < 0)
-		return;
-	FD_SET(fd, set);
-	if (fd > *max)
-		*max = fd;
-}
+	struct pollfd *ret;
+	if (current_array_size < nr_fds + 1) {
+		struct pollfd *new_fds = NULL;
+		unsigned long newsize;
+
+		/* Round up to 2^8 boundary, in practice this just
+		 * make newsize larger than current_array_size.
+		 */
+		newsize = ROUNDUP(nr_fds + 1, 8);
 
+		new_fds = realloc(fds, sizeof(struct pollfd)*newsize);
+		if (!new_fds)
+			goto fail;
+		fds = new_fds;
 
-static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
-			  struct timeval **ptimeout)
+		memset(&fds[0] + current_array_size, 0,
+		       sizeof(struct pollfd ) * (newsize-current_array_size));
+		current_array_size = newsize;
+	}
+
+	fds[nr_fds].fd = fd;
+	fds[nr_fds].events = events;
+	ret = &fds[nr_fds];
+	nr_fds++;
+
+	return ret;
+fail:
+	syslog(LOG_ERR, "realloc failed, ignoring fd %d\n", fd);
+	return NULL;
+}
+
+static void initialize_fds(int sock, struct pollfd **p_sock_pollfd,
+			   int ro_sock, struct pollfd **p_ro_sock_pollfd,
+			   int *ptimeout)
 {
-	static struct timeval zero_timeout = { 0 };
 	struct connection *conn;
-	int max = -1;
 
-	*ptimeout = NULL;
+	memset(fds, 0, sizeof(struct pollfd) * current_array_size);
+	nr_fds = 0;
 
-	FD_ZERO(inset);
-	FD_ZERO(outset);
+	*ptimeout = -1;
 
 	if (sock != -1)
-		set_fd(sock, inset, &max);
+		*p_sock_pollfd = set_fd(sock, POLLIN|POLLPRI);
 	if (ro_sock != -1)
-		set_fd(ro_sock, inset, &max);
+		*p_ro_sock_pollfd = set_fd(ro_sock, POLLIN|POLLPRI);
 	if (reopen_log_pipe[0] != -1)
-		set_fd(reopen_log_pipe[0], inset, &max);
+		reopen_log_pipe0_pollfd =
+			set_fd(reopen_log_pipe[0], POLLIN|POLLPRI);
 
 	if (xce_handle != NULL)
-		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
+		xce_pollfd = set_fd(xc_evtchn_fd(xce_handle), POLLIN|POLLPRI);
 
 	list_for_each_entry(conn, &connections, list) {
 		if (conn->domain) {
 			if (domain_can_read(conn) ||
 			    (domain_can_write(conn) &&
 			     !list_empty(&conn->out_list)))
-				*ptimeout = &zero_timeout;
+				*ptimeout = 0;
 		} else {
-			set_fd(conn->fd, inset, &max);
+			short events = POLLIN|POLLPRI;
 			if (!list_empty(&conn->out_list))
-				FD_SET(conn->fd, outset);
+				events |= POLLOUT;
+			conn->pollfd = set_fd(conn->fd, events);
 		}
 	}
-
-	return max;
 }
 
 /* Is child a subnode of parent, or equal? */
@@ -1770,14 +1796,13 @@ int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock, *ro_sock, max;
-	fd_set inset, outset;
+	int opt, *sock, *ro_sock;
+	struct pollfd *sock_pollfd = NULL, *ro_sock_pollfd = NULL;
 	bool dofork = true;
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
-	int evtchn_fd = -1;
-	struct timeval *timeout;
+	int timeout;
 
 	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
 				  NULL)) != -1) {
@@ -1880,11 +1905,9 @@ int main(int argc, char *argv[])
 
 	signal(SIGHUP, trigger_reopen_log);
 
-	if (xce_handle != NULL)
-		evtchn_fd = xc_evtchn_fd(xce_handle);
-
 	/* Get ready to listen to the tools. */
-	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
+	initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+		       &timeout);
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -1893,27 +1916,55 @@ int main(int argc, char *argv[])
 	for (;;) {
 		struct connection *conn, *next;
 
-		if (select(max+1, &inset, &outset, NULL, timeout) < 0) {
+		if (poll(fds, nr_fds, timeout) < 0) {
 			if (errno == EINTR)
 				continue;
-			barf_perror("Select failed");
+			barf_perror("Poll failed");
 		}
 
-		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
-			char c;
-			if (read(reopen_log_pipe[0], &c, 1) != 1)
-				barf_perror("read failed");
-			reopen_log();
+		if (reopen_log_pipe0_pollfd) {
+			if (reopen_log_pipe0_pollfd->revents & ~POLLIN) {
+				close(reopen_log_pipe[0]);
+				close(reopen_log_pipe[1]);
+				init_pipe(reopen_log_pipe);
+			} else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
+				char c;
+				if (read(reopen_log_pipe[0], &c, 1) != 1)
+					barf_perror("read failed");
+				reopen_log();
+			}
+			reopen_log_pipe0_pollfd = NULL;
 		}
 
-		if (*sock != -1 && FD_ISSET(*sock, &inset))
-			accept_connection(*sock, true);
+		if (sock_pollfd) {
+			if (sock_pollfd->revents & ~POLLIN) {
+				barf_perror("sock poll failed");
+				break;
+			} else if (sock_pollfd->revents & POLLIN) {
+				accept_connection(*sock, true);
+				sock_pollfd = NULL;
+			}
+		}
 
-		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
-			accept_connection(*ro_sock, false);
+		if (ro_sock_pollfd) {
+			if (ro_sock_pollfd->revents & ~POLLIN) {
+				barf_perror("ro sock poll failed");
+				break;
+			} else if (ro_sock_pollfd->revents & POLLIN) {
+				accept_connection(*ro_sock, false);
+				ro_sock_pollfd = NULL;
+			}
+		}
 
-		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-			handle_event();
+		if (xce_pollfd) {
+			if (xce_pollfd->revents & ~POLLIN) {
+				barf_perror("xce_handle poll failed");
+				break;
+			} else if (xce_pollfd->revents & POLLIN) {
+				handle_event();
+				xce_pollfd = NULL;
+			}
+		}
 
 		next = list_entry(connections.next, typeof(*conn), list);
 		if (&next->list != &connections)
@@ -1939,21 +1990,27 @@ int main(int argc, char *argv[])
 				if (talloc_free(conn) == 0)
 					continue;
 			} else {
-				if (FD_ISSET(conn->fd, &inset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLIN))
 					handle_input(conn);
 				if (talloc_free(conn) == 0)
 					continue;
 
 				talloc_increase_ref_count(conn);
-				if (FD_ISSET(conn->fd, &outset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLOUT))
 					handle_output(conn);
 				if (talloc_free(conn) == 0)
 					continue;
+
+				conn->pollfd = NULL;
 			}
 		}
 
-		max = initialize_set(&inset, &outset, *sock, *ro_sock,
-				     &timeout);
+		initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+			       &timeout);
 	}
 }
 
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 492ca0d..f330a87 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -60,6 +60,8 @@ struct connection
 
 	/* The file descriptor we came in on. */
 	int fd;
+	/* The pollfd corresponding to fd. */
+	struct pollfd *pollfd;
 
 	/* Who am I? 0 for socket connections. */
 	unsigned int id;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:05:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U87UX-0002Cy-K9; Wed, 20 Feb 2013 11:05:37 +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 1U87UV-0002Ce-PN
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:05:36 +0000
Received: from [85.158.139.211:18161] by server-7.bemta-5.messagelabs.com id
	E4/7F-11121-FFDA4215; Wed, 20 Feb 2013 11:05:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361358315!18436697!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32317 invoked from network); 20 Feb 2013 11:05:19 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:05:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7977149"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:05:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:05:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U87U9-0005z9-Vd;
	Wed, 20 Feb 2013 11:05:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:05:09 +0000
Message-ID: <1361358309-32191-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
References: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] Switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Poll() can support more file descriptors than select(). We've done this for
xenconsoled, now do this for cxenstored as well.

The code is taken from xenconsoled and modified to adapt to cxenstored.

Updated:
* reopen pipe if polling on reopen_log_pipe fails.
* exit if polling on some critical fds fails.
* clean up POLL*.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/xenstore/xenstored_core.c |  171 ++++++++++++++++++++++++++-------------
 tools/xenstore/xenstored_core.h |    2 +
 2 files changed, 116 insertions(+), 57 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index bd44645..839e51d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,7 +19,7 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/select.h>
+#include <poll.h>
 #ifndef NO_SOCKETS
 #include <sys/socket.h>
 #include <sys/un.h>
@@ -55,6 +55,12 @@
 #include "hashtable.h"
 
 extern xc_evtchn *xce_handle; /* in xenstored_domain.c */
+static struct pollfd *xce_pollfd;
+static struct pollfd *fds;
+static unsigned int current_array_size;
+static unsigned int nr_fds;
+
+#define ROUNDUP(_x, _w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
 static bool verbose = false;
 LIST_HEAD(connections);
@@ -62,6 +68,7 @@ static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
+static struct pollfd *reopen_log_pipe0_pollfd;
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx = NULL;
 
@@ -199,7 +206,7 @@ void trace_destroy(const void *data, const char *type)
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
- * the select() in the main loop.
+ * the poll() in the main loop.
  */
 static void trigger_reopen_log(int signal __attribute__((unused)))
 {
@@ -279,15 +286,12 @@ static int destroy_conn(void *_conn)
 
 	/* Flush outgoing if possible, but don't block. */
 	if (!conn->domain) {
-		fd_set set;
-		struct timeval none;
-
-		FD_ZERO(&set);
-		FD_SET(conn->fd, &set);
-		none.tv_sec = none.tv_usec = 0;
+		struct pollfd pfd;
+		pfd.fd = conn->fd;
+		pfd.events = POLLOUT;
 
 		while (!list_empty(&conn->out_list)
-		       && select(conn->fd+1, NULL, &set, NULL, &none) == 1)
+		       && poll(&pfd, 1, 0) == 1)
 			if (!write_messages(conn))
 				break;
 		close(conn->fd);
@@ -300,52 +304,74 @@ static int destroy_conn(void *_conn)
 }
 
 
-static void set_fd(int fd, fd_set *set, int *max)
+static struct pollfd *set_fd(int fd, short events)
 {
-	if (fd < 0)
-		return;
-	FD_SET(fd, set);
-	if (fd > *max)
-		*max = fd;
-}
+	struct pollfd *ret;
+	if (current_array_size < nr_fds + 1) {
+		struct pollfd *new_fds = NULL;
+		unsigned long newsize;
+
+		/* Round up to 2^8 boundary, in practice this just
+		 * make newsize larger than current_array_size.
+		 */
+		newsize = ROUNDUP(nr_fds + 1, 8);
 
+		new_fds = realloc(fds, sizeof(struct pollfd)*newsize);
+		if (!new_fds)
+			goto fail;
+		fds = new_fds;
 
-static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
-			  struct timeval **ptimeout)
+		memset(&fds[0] + current_array_size, 0,
+		       sizeof(struct pollfd ) * (newsize-current_array_size));
+		current_array_size = newsize;
+	}
+
+	fds[nr_fds].fd = fd;
+	fds[nr_fds].events = events;
+	ret = &fds[nr_fds];
+	nr_fds++;
+
+	return ret;
+fail:
+	syslog(LOG_ERR, "realloc failed, ignoring fd %d\n", fd);
+	return NULL;
+}
+
+static void initialize_fds(int sock, struct pollfd **p_sock_pollfd,
+			   int ro_sock, struct pollfd **p_ro_sock_pollfd,
+			   int *ptimeout)
 {
-	static struct timeval zero_timeout = { 0 };
 	struct connection *conn;
-	int max = -1;
 
-	*ptimeout = NULL;
+	memset(fds, 0, sizeof(struct pollfd) * current_array_size);
+	nr_fds = 0;
 
-	FD_ZERO(inset);
-	FD_ZERO(outset);
+	*ptimeout = -1;
 
 	if (sock != -1)
-		set_fd(sock, inset, &max);
+		*p_sock_pollfd = set_fd(sock, POLLIN|POLLPRI);
 	if (ro_sock != -1)
-		set_fd(ro_sock, inset, &max);
+		*p_ro_sock_pollfd = set_fd(ro_sock, POLLIN|POLLPRI);
 	if (reopen_log_pipe[0] != -1)
-		set_fd(reopen_log_pipe[0], inset, &max);
+		reopen_log_pipe0_pollfd =
+			set_fd(reopen_log_pipe[0], POLLIN|POLLPRI);
 
 	if (xce_handle != NULL)
-		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
+		xce_pollfd = set_fd(xc_evtchn_fd(xce_handle), POLLIN|POLLPRI);
 
 	list_for_each_entry(conn, &connections, list) {
 		if (conn->domain) {
 			if (domain_can_read(conn) ||
 			    (domain_can_write(conn) &&
 			     !list_empty(&conn->out_list)))
-				*ptimeout = &zero_timeout;
+				*ptimeout = 0;
 		} else {
-			set_fd(conn->fd, inset, &max);
+			short events = POLLIN|POLLPRI;
 			if (!list_empty(&conn->out_list))
-				FD_SET(conn->fd, outset);
+				events |= POLLOUT;
+			conn->pollfd = set_fd(conn->fd, events);
 		}
 	}
-
-	return max;
 }
 
 /* Is child a subnode of parent, or equal? */
@@ -1770,14 +1796,13 @@ int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock, *ro_sock, max;
-	fd_set inset, outset;
+	int opt, *sock, *ro_sock;
+	struct pollfd *sock_pollfd = NULL, *ro_sock_pollfd = NULL;
 	bool dofork = true;
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
-	int evtchn_fd = -1;
-	struct timeval *timeout;
+	int timeout;
 
 	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
 				  NULL)) != -1) {
@@ -1880,11 +1905,9 @@ int main(int argc, char *argv[])
 
 	signal(SIGHUP, trigger_reopen_log);
 
-	if (xce_handle != NULL)
-		evtchn_fd = xc_evtchn_fd(xce_handle);
-
 	/* Get ready to listen to the tools. */
-	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
+	initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+		       &timeout);
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -1893,27 +1916,55 @@ int main(int argc, char *argv[])
 	for (;;) {
 		struct connection *conn, *next;
 
-		if (select(max+1, &inset, &outset, NULL, timeout) < 0) {
+		if (poll(fds, nr_fds, timeout) < 0) {
 			if (errno == EINTR)
 				continue;
-			barf_perror("Select failed");
+			barf_perror("Poll failed");
 		}
 
-		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
-			char c;
-			if (read(reopen_log_pipe[0], &c, 1) != 1)
-				barf_perror("read failed");
-			reopen_log();
+		if (reopen_log_pipe0_pollfd) {
+			if (reopen_log_pipe0_pollfd->revents & ~POLLIN) {
+				close(reopen_log_pipe[0]);
+				close(reopen_log_pipe[1]);
+				init_pipe(reopen_log_pipe);
+			} else if (reopen_log_pipe0_pollfd->revents & POLLIN) {
+				char c;
+				if (read(reopen_log_pipe[0], &c, 1) != 1)
+					barf_perror("read failed");
+				reopen_log();
+			}
+			reopen_log_pipe0_pollfd = NULL;
 		}
 
-		if (*sock != -1 && FD_ISSET(*sock, &inset))
-			accept_connection(*sock, true);
+		if (sock_pollfd) {
+			if (sock_pollfd->revents & ~POLLIN) {
+				barf_perror("sock poll failed");
+				break;
+			} else if (sock_pollfd->revents & POLLIN) {
+				accept_connection(*sock, true);
+				sock_pollfd = NULL;
+			}
+		}
 
-		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
-			accept_connection(*ro_sock, false);
+		if (ro_sock_pollfd) {
+			if (ro_sock_pollfd->revents & ~POLLIN) {
+				barf_perror("ro sock poll failed");
+				break;
+			} else if (ro_sock_pollfd->revents & POLLIN) {
+				accept_connection(*ro_sock, false);
+				ro_sock_pollfd = NULL;
+			}
+		}
 
-		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-			handle_event();
+		if (xce_pollfd) {
+			if (xce_pollfd->revents & ~POLLIN) {
+				barf_perror("xce_handle poll failed");
+				break;
+			} else if (xce_pollfd->revents & POLLIN) {
+				handle_event();
+				xce_pollfd = NULL;
+			}
+		}
 
 		next = list_entry(connections.next, typeof(*conn), list);
 		if (&next->list != &connections)
@@ -1939,21 +1990,27 @@ int main(int argc, char *argv[])
 				if (talloc_free(conn) == 0)
 					continue;
 			} else {
-				if (FD_ISSET(conn->fd, &inset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLIN))
 					handle_input(conn);
 				if (talloc_free(conn) == 0)
 					continue;
 
 				talloc_increase_ref_count(conn);
-				if (FD_ISSET(conn->fd, &outset))
+				if (conn->pollfd &&
+				    !(conn->pollfd->revents & ~(POLLIN|POLLOUT)) &&
+				    (conn->pollfd->revents & POLLOUT))
 					handle_output(conn);
 				if (talloc_free(conn) == 0)
 					continue;
+
+				conn->pollfd = NULL;
 			}
 		}
 
-		max = initialize_set(&inset, &outset, *sock, *ro_sock,
-				     &timeout);
+		initialize_fds(*sock, &sock_pollfd, *ro_sock, &ro_sock_pollfd,
+			       &timeout);
 	}
 }
 
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 492ca0d..f330a87 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -60,6 +60,8 @@ struct connection
 
 	/* The file descriptor we came in on. */
 	int fd;
+	/* The pollfd corresponding to fd. */
+	struct pollfd *pollfd;
 
 	/* Who am I? 0 for socket connections. */
 	unsigned int id;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:06:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:06: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 1U87Uo-0002Eu-98; Wed, 20 Feb 2013 11:05:54 +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 1U87Um-0002Eg-QD
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:05:52 +0000
Received: from [85.158.139.211:13791] by server-14.bemta-5.messagelabs.com id
	BD/C2-06967-F0EA4215; Wed, 20 Feb 2013 11:05:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361358315!18436697!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32021 invoked from network); 20 Feb 2013 11:05:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:05:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7977146"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:05:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:05:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U87U9-0005z9-TB	for xen-devel@lists.xen.org;
	Wed, 20 Feb 2013 11:05:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:05:07 +0000
Message-ID: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/2] switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 contains:
* poll(2) implementation for mini-os
* switch to poll() in cxenstored's IO loop

The second patch alone breaks xenstore-stubdom build because mini-os does not
have poll(2) originally.

I've tested this patch series with simple xenstore-stubdom setup. The
xenstore-stubdom can send / receive events without any problems.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:06:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:06: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 1U87Uo-0002Eu-98; Wed, 20 Feb 2013 11:05:54 +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 1U87Um-0002Eg-QD
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:05:52 +0000
Received: from [85.158.139.211:13791] by server-14.bemta-5.messagelabs.com id
	BD/C2-06967-F0EA4215; Wed, 20 Feb 2013 11:05:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361358315!18436697!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32021 invoked from network); 20 Feb 2013 11:05:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:05:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7977146"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:05:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:05:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U87U9-0005z9-TB	for xen-devel@lists.xen.org;
	Wed, 20 Feb 2013 11:05:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:05:07 +0000
Message-ID: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/2] switch to poll() in cxenstored's IO loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 contains:
* poll(2) implementation for mini-os
* switch to poll() in cxenstored's IO loop

The second patch alone breaks xenstore-stubdom build because mini-os does not
have poll(2) originally.

I've tested this patch series with simple xenstore-stubdom setup. The
xenstore-stubdom can send / receive events without any problems.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:06:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:06: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 1U87VH-0002Jm-NO; Wed, 20 Feb 2013 11:06:23 +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 1U87VF-0002JO-TS
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:06:22 +0000
Received: from [85.158.139.211:47303] by server-16.bemta-5.messagelabs.com id
	41/DD-14948-D2EA4215; Wed, 20 Feb 2013 11:06:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361358315!18436697!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32485 invoked from network); 20 Feb 2013 11:05:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7977151"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:05:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:05:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U87U9-0005z9-V3;
	Wed, 20 Feb 2013 11:05:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:05:08 +0000
Message-ID: <1361358309-32191-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
References: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] mini-os: implement poll(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

It is just a wrapper around select(2). This implementation mimics Linux's
do_poll.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  117 ++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..cfbdc90 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,98 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int n, ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    n = 0;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        _pfd[i].revents = 0;
+
+        /* fd < 0, revents = 0, which is already set */
+        if (fd < 0) continue;
+
+        /* fd is invalid, revents = POLLNVAL, increment counter */
+        if (fd >= NOFILE || files[fd].type == FTYPE_NONE) {
+            n++;
+            _pfd[i].revents |= POLLNVAL;
+            continue;
+        }
+
+        /* normal case, map POLL* into readfds and writefds:
+         * POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* should never sleep when we already have events */
+    if (n) {
+        _timeo.tv_sec  = 0;
+        _timeo.tv_usec = 0;
+        timeo = &_timeo;
+    } else if (_timeout >= 0) {
+        /* normal case, construct _timeout, might sleep */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    } else {
+        /* _timeout < 0, block forever */
+        timeo = NULL;
+    }
+
+
+    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
+    /* error in select, just return, errno is set by select() */
+    if (ret < 0)
+        return ret;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+
+        /* the revents has already been set for all error case */
+        if (fd < 0 || fd >= NOFILE || files[fd].type == FTYPE_NONE)
+            continue;
+
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            n++;
+        if (FD_ISSET(fd, &efds)) {
+            /* anything bad happens we set POLLERR */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    return n;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1476,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:06:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:06: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 1U87VH-0002Jm-NO; Wed, 20 Feb 2013 11:06:23 +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 1U87VF-0002JO-TS
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:06:22 +0000
Received: from [85.158.139.211:47303] by server-16.bemta-5.messagelabs.com id
	41/DD-14948-D2EA4215; Wed, 20 Feb 2013 11:06:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361358315!18436697!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32485 invoked from network); 20 Feb 2013 11:05:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7977151"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:05:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:05:14 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U87U9-0005z9-V3;
	Wed, 20 Feb 2013 11:05:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:05:08 +0000
Message-ID: <1361358309-32191-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
References: <1361358309-32191-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] mini-os: implement poll(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

It is just a wrapper around select(2). This implementation mimics Linux's
do_poll.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
 extras/mini-os/include/posix/poll.h |    1 +
 extras/mini-os/lib/sys.c            |  117 ++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 extras/mini-os/include/posix/poll.h

diff --git a/extras/mini-os/include/posix/poll.h b/extras/mini-os/include/posix/poll.h
new file mode 100644
index 0000000..06fb41a
--- /dev/null
+++ b/extras/mini-os/include/posix/poll.h
@@ -0,0 +1 @@
+#include <sys/poll.h>
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 3cc3340..cfbdc90 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -31,6 +31,7 @@
 #include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
+#include <poll.h>
 
 #include <sys/types.h>
 #include <sys/unistd.h>
@@ -678,6 +679,29 @@ static void dump_set(int nfds, fd_set *readfds, fd_set *writefds, fd_set *except
 #define dump_set(nfds, readfds, writefds, exceptfds, timeout)
 #endif
 
+#ifdef LIBC_DEBUG
+static void dump_pollfds(struct pollfd *pfd, int nfds, int timeout)
+{
+    int i, comma, fd;
+
+    printk("[");
+    comma = 0;
+    for (i = 0; i < nfds; i++) {
+        fd = pfd[i].fd;
+        if (comma)
+            printk(", ");
+        printk("%d(%c)/%02x", fd, file_types[files[fd].type],
+            pfd[i].events);
+            comma = 1;
+    }
+    printk("]");
+
+    printk(", %d, %d", nfds, timeout);
+}
+#else
+#define dump_pollfds(pfds, nfds, timeout)
+#endif
+
 /* Just poll without blocking */
 static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds)
 {
@@ -983,6 +1007,98 @@ out:
     return ret;
 }
 
+/* Wrap around select */
+int poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout)
+{
+    int n, ret;
+    int i, fd;
+    struct timeval _timeo, *timeo = NULL;
+    fd_set rfds, wfds, efds;
+    int max_fd = -1;
+
+    DEBUG("poll(");
+    dump_pollfds(_pfd, _nfds, _timeout);
+    DEBUG(")\n");
+
+    FD_ZERO(&rfds);
+    FD_ZERO(&wfds);
+    FD_ZERO(&efds);
+
+    n = 0;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+        _pfd[i].revents = 0;
+
+        /* fd < 0, revents = 0, which is already set */
+        if (fd < 0) continue;
+
+        /* fd is invalid, revents = POLLNVAL, increment counter */
+        if (fd >= NOFILE || files[fd].type == FTYPE_NONE) {
+            n++;
+            _pfd[i].revents |= POLLNVAL;
+            continue;
+        }
+
+        /* normal case, map POLL* into readfds and writefds:
+         * POLLIN  -> readfds
+         * POLLOUT -> writefds
+         * POLL*   -> none
+         */
+        if (_pfd[i].events & POLLIN)
+            FD_SET(fd, &rfds);
+        if (_pfd[i].events & POLLOUT)
+            FD_SET(fd, &wfds);
+        /* always set exceptfds */
+        FD_SET(fd, &efds);
+        if (fd > max_fd)
+            max_fd = fd;
+    }
+
+    /* should never sleep when we already have events */
+    if (n) {
+        _timeo.tv_sec  = 0;
+        _timeo.tv_usec = 0;
+        timeo = &_timeo;
+    } else if (_timeout >= 0) {
+        /* normal case, construct _timeout, might sleep */
+        _timeo.tv_sec  = _timeout / 1000;
+        _timeo.tv_usec = (_timeout % 1000) * 1000;
+        timeo = &_timeo;
+    } else {
+        /* _timeout < 0, block forever */
+        timeo = NULL;
+    }
+
+
+    ret = select(max_fd+1, &rfds, &wfds, &efds, timeo);
+    /* error in select, just return, errno is set by select() */
+    if (ret < 0)
+        return ret;
+
+    for (i = 0; i < _nfds; i++) {
+        fd = _pfd[i].fd;
+
+        /* the revents has already been set for all error case */
+        if (fd < 0 || fd >= NOFILE || files[fd].type == FTYPE_NONE)
+            continue;
+
+        if (FD_ISSET(fd, &rfds) || FD_ISSET(fd, &wfds) || FD_ISSET(fd, &efds))
+            n++;
+        if (FD_ISSET(fd, &efds)) {
+            /* anything bad happens we set POLLERR */
+            _pfd[i].revents |= POLLERR;
+            continue;
+        }
+        if (FD_ISSET(fd, &rfds))
+            _pfd[i].revents |= POLLIN;
+        if (FD_ISSET(fd, &wfds))
+            _pfd[i].revents |= POLLOUT;
+    }
+
+    return n;
+}
+
 #ifdef HAVE_LWIP
 int socket(int domain, int type, int protocol)
 {
@@ -1360,7 +1476,6 @@ unsupported_function(int, tcgetattr, 0);
 unsupported_function(int, grantpt, -1);
 unsupported_function(int, unlockpt, -1);
 unsupported_function(char *, ptsname, NULL);
-unsupported_function(int, poll, -1);
 
 /* net/if.h */
 unsupported_function_log(unsigned int, if_nametoindex, -1);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:09:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U87Y5-0002fF-B1; Wed, 20 Feb 2013 11:09:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U87Y2-0002f4-PU
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:09:15 +0000
Received: from [85.158.138.51:27798] by server-9.bemta-3.messagelabs.com id
	A9/CA-09484-5DEA4215; Wed, 20 Feb 2013 11:09:09 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361358539!28400499!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDUxNTAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24249 invoked from network); 20 Feb 2013 11:09:00 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-9.tower-174.messagelabs.com with SMTP;
	20 Feb 2013 11:09:00 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 1DD1BC4;
	Wed, 20 Feb 2013 22:08:57 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361358537; bh=I7z3O2EOmJ0l2F/zs34Hg8LYOK85u2eCGOg46gQzpH4=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=gZsZYnq7Ec+h5Zh4dOhSWBo8FubSMEPedZpwYH1BMjePonRBXKipo18nhl0Sg1Jet
	x53IY3gOiGhYTlkpcRjVGxCCoLnB5Ct4jnipDYC1fD6i7Vpd4ihCtGjX+/KbEx03L0
	/P3XP2/nuz5CIG5AQi3ia0zZzVTh342ATtRD6bHw=
Message-ID: <5124AECA.4060503@crc.id.au>
Date: Wed, 20 Feb 2013 22:08:58 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
	<5124AE19.2000802@citrix.com>
In-Reply-To: <5124AE19.2000802@citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============3422737923696360922=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3422737923696360922==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030606080507020301020208"

This is a cryptographically signed message in MIME format.

--------------ms030606080507020301020208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 20/02/2013 10:06 PM, Andrew Cooper wrote:
> On 20/02/13 10:12, Jan Beulich wrote:
>>>>> On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
>>> My build of Xen 4.2.1 also has all of the recent security advisories
>>> patched as well. Although it is interesting to note that downgrading =
to
>>> Xen 4.1.2 made no difference to write speeds.
>> Not surprising at all, considering that the hypervisor is only a passi=
ve
>> library for all PV I/O purposes. You're likely hunting for a kernel si=
de
>> regression (and hence the mentioning of the hypervisor version as
>> the main factor in the subject is probably misleading).
>>
>> Jan
>
> Further to this, do try to verify if your disk driver has changed
> recently to use >0 order page allocations for DMA.  If it has, then
> speed will be much slower as there will now be the swiotlb cpu-copy
> overhead.

Any hints on how to do this? ;)

The kernel modules in use for my SATA drives are ahci and sata_mv. There =

are 6 drives in total on the system.

sda + sdb =3D RAID1
sd[c-f] =3D RAID6

sda, sdb, sdc and sdd are on the onboard SATA controller (ahci)
sde, sdf are on the sata_mv 4x PCIe controller.

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299



--------------ms030606080507020301020208
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAxMTA4NThaMCMGCSqGSIb3DQEJBDEWBBQNdDjn0kUKpA2uwuxhuizDTEWa
TDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEATZuGoVLExsJVT/MQ6d5BaUz5
cY1WhXosx9JymfSmwjTsxEk3cLfRkP9nsXMKkJQGbjAMwwr/YzpZCAXE049nZfUzqB2STWuW
5lrRXWPgqG9DMtqWC9m3Rb7RMeaSRuhmIyTBYjxcDcteQ5lK+bdU07eLLv1ATcWw2j5w3wxO
gKC92LAd0sgHSS1prXegIRi8kS5/XEcX/ZIc93NvTAuCbBnkRLPxHYsBFJpCoNlDG+d8EJ3Q
Pjc1LOwWvwNYAzC4cNngkdCRNCBW+ItgdLdgdop3R1RGmjbQRc0eaowky+hzejH7X8EfsTvg
gUtjGakJDvhnhuPpala8U7bLn/zMoAAAAAAAAA==
--------------ms030606080507020301020208--


--===============3422737923696360922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3422737923696360922==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 11:09:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U87Y5-0002fF-B1; Wed, 20 Feb 2013 11:09:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1U87Y2-0002f4-PU
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:09:15 +0000
Received: from [85.158.138.51:27798] by server-9.bemta-3.messagelabs.com id
	A9/CA-09484-5DEA4215; Wed, 20 Feb 2013 11:09:09 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361358539!28400499!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDUxNTAgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24249 invoked from network); 20 Feb 2013 11:09:00 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-9.tower-174.messagelabs.com with SMTP;
	20 Feb 2013 11:09:00 -0000
Received: from [10.1.1.118] (WOPR.lan.crc.id.au [10.1.1.118])
	by mail.crc.id.au (Postfix) with ESMTPSA id 1DD1BC4;
	Wed, 20 Feb 2013 22:08:57 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1361358537; bh=I7z3O2EOmJ0l2F/zs34Hg8LYOK85u2eCGOg46gQzpH4=;
	h=Date:From:To:CC:Subject:References:In-Reply-To;
	b=gZsZYnq7Ec+h5Zh4dOhSWBo8FubSMEPedZpwYH1BMjePonRBXKipo18nhl0Sg1Jet
	x53IY3gOiGhYTlkpcRjVGxCCoLnB5Ct4jnipDYC1fD6i7Vpd4ihCtGjX+/KbEx03L0
	/P3XP2/nuz5CIG5AQi3ia0zZzVTh342ATtRD6bHw=
Message-ID: <5124AECA.4060503@crc.id.au>
Date: Wed, 20 Feb 2013 22:08:58 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
	<5124AE19.2000802@citrix.com>
In-Reply-To: <5124AE19.2000802@citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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: multipart/mixed; boundary="===============3422737923696360922=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3422737923696360922==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030606080507020301020208"

This is a cryptographically signed message in MIME format.

--------------ms030606080507020301020208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 20/02/2013 10:06 PM, Andrew Cooper wrote:
> On 20/02/13 10:12, Jan Beulich wrote:
>>>>> On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
>>> My build of Xen 4.2.1 also has all of the recent security advisories
>>> patched as well. Although it is interesting to note that downgrading =
to
>>> Xen 4.1.2 made no difference to write speeds.
>> Not surprising at all, considering that the hypervisor is only a passi=
ve
>> library for all PV I/O purposes. You're likely hunting for a kernel si=
de
>> regression (and hence the mentioning of the hypervisor version as
>> the main factor in the subject is probably misleading).
>>
>> Jan
>
> Further to this, do try to verify if your disk driver has changed
> recently to use >0 order page allocations for DMA.  If it has, then
> speed will be much slower as there will now be the swiotlb cpu-copy
> overhead.

Any hints on how to do this? ;)

The kernel modules in use for my SATA drives are ahci and sata_mv. There =

are 6 drives in total on the system.

sda + sdb =3D RAID1
sd[c-f] =3D RAID6

sda, sdb, sdc and sdd are on the onboard SATA controller (ahci)
sde, sdf are on the sata_mv 4x PCIe controller.

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299



--------------ms030606080507020301020208
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGgAwIBAgIDBdMXMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTI5MTIyMTM0
WhcNMTQwMTMwMjIzNjE4WjBXMRkwFwYDVQQNExA0MzM5TjFVWjZFS2ZBa0Y2MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqz7eWA7Oi1ES6IIWwtRNtOa6cSj6GSio
72D26TkCPm/vYamqS/9pluIyMO2TbGjMyveGxWZB9bDt+MnuI6yJ3spD6br5TUXQSqsgp1/g
NXicgNmUHESd/A7+POEdYKMyTtXjVEqmR8R6uPtD78MBhIKQVZdBYGFuRBhrjoFMOnWARmXD
47FG6eLH8jyeBi+RGEYEpBgTe1gFcoU1dCrjBqxAj47ALNgcHP4ffNX47DLvyhW2pMMaOYUh
ga/UyQuPOpZcMAJdVI7dTIkbdipboEEE5pTdoIRI+F+XDLzO8bNkGLa1xLTWrbP048xxw3SL
Aw/DmLYqQ+oC8vabAAqBIwIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR/FxImYCufSdz0pG5w
A8VPzNyaujAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBu
ZXR3aXpAY3JjLmlkLmF1MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow
LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG
AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U
aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh
bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh
bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl
IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j
bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq
hkiG9w0BAQUFAAOCAQEAwsdSJioQIH5mEXlMBkQBZN9qrqCvDn4e92NKIX2LMPhVH01o0weH
MEgkFMOBypbcPrwnZD51IL+ZfPmuDrcFJR9SPk4W95p3wLakMUBmvDPJ3IC+pa97+fU/GYsh
q4dth+VlAIWJarpPV5ee6hAXGQEZvC2jyy5ukcjlr/oQxegb4hufgkLhKjqaq5UDs2be5q1N
CBewezVmAbb/VDNVogP1xacnHn4rhllskMfGAda2DPCCaSMaJ3LcC5JRyfMkpKe5UxpVmVeM
vGP8hYGI9DlFjwpqRCmIvD/Wl6oWWJc0HaLl6k+U3dngqEHhunzh3H6b/3lWOmEKQuI3Piy+
oDGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwXT
FzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMzAyMjAxMTA4NThaMCMGCSqGSIb3DQEJBDEWBBQNdDjn0kUKpA2uwuxhuizDTEWa
TDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQIDBdMXMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMF0xcwDQYJKoZIhvcNAQEBBQAEggEATZuGoVLExsJVT/MQ6d5BaUz5
cY1WhXosx9JymfSmwjTsxEk3cLfRkP9nsXMKkJQGbjAMwwr/YzpZCAXE049nZfUzqB2STWuW
5lrRXWPgqG9DMtqWC9m3Rb7RMeaSRuhmIyTBYjxcDcteQ5lK+bdU07eLLv1ATcWw2j5w3wxO
gKC92LAd0sgHSS1prXegIRi8kS5/XEcX/ZIc93NvTAuCbBnkRLPxHYsBFJpCoNlDG+d8EJ3Q
Pjc1LOwWvwNYAzC4cNngkdCRNCBW+ItgdLdgdop3R1RGmjbQRc0eaowky+hzejH7X8EfsTvg
gUtjGakJDvhnhuPpala8U7bLn/zMoAAAAAAAAA==
--------------ms030606080507020301020208--


--===============3422737923696360922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3422737923696360922==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 11:14:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:14: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 1U87ci-0002vh-30; Wed, 20 Feb 2013 11:14:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U87ch-0002vb-FL
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:14:03 +0000
Received: from [85.158.137.99:13371] by server-15.bemta-3.messagelabs.com id
	1D/8C-25405-9FFA4215; Wed, 20 Feb 2013 11:14:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361358362!17190294!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21664 invoked from network); 20 Feb 2013 11:06:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="8391550"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:06:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:06:01 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U87Uv-000602-Ie;
	Wed, 20 Feb 2013 11:06:01 +0000
Message-ID: <5124AE19.2000802@citrix.com>
Date: Wed, 20 Feb 2013 11:06:01 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Steven Haigh <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
In-Reply-To: <5124AF9F02000078000BFA35@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20/02/13 10:12, Jan Beulich wrote:
>>>> On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
>> My build of Xen 4.2.1 also has all of the recent security advisories 
>> patched as well. Although it is interesting to note that downgrading to 
>> Xen 4.1.2 made no difference to write speeds.
> Not surprising at all, considering that the hypervisor is only a passive
> library for all PV I/O purposes. You're likely hunting for a kernel side
> regression (and hence the mentioning of the hypervisor version as
> the main factor in the subject is probably misleading).
>
> Jan

Further to this, do try to verify if your disk driver has changed
recently to use >0 order page allocations for DMA.  If it has, then
speed will be much slower as there will now be the swiotlb cpu-copy
overhead.

~Andrew

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 20 11:14:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:14: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 1U87ci-0002vh-30; Wed, 20 Feb 2013 11:14:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U87ch-0002vb-FL
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:14:03 +0000
Received: from [85.158.137.99:13371] by server-15.bemta-3.messagelabs.com id
	1D/8C-25405-9FFA4215; Wed, 20 Feb 2013 11:14:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361358362!17190294!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21664 invoked from network); 20 Feb 2013 11:06:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="8391550"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:06:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:06:01 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U87Uv-000602-Ie;
	Wed, 20 Feb 2013 11:06:01 +0000
Message-ID: <5124AE19.2000802@citrix.com>
Date: Wed, 20 Feb 2013 11:06:01 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Steven Haigh <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
In-Reply-To: <5124AF9F02000078000BFA35@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20/02/13 10:12, Jan Beulich wrote:
>>>> On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
>> My build of Xen 4.2.1 also has all of the recent security advisories 
>> patched as well. Although it is interesting to note that downgrading to 
>> Xen 4.1.2 made no difference to write speeds.
> Not surprising at all, considering that the hypervisor is only a passive
> library for all PV I/O purposes. You're likely hunting for a kernel side
> regression (and hence the mentioning of the hypervisor version as
> the main factor in the subject is probably misleading).
>
> Jan

Further to this, do try to verify if your disk driver has changed
recently to use >0 order page allocations for DMA.  If it has, then
speed will be much slower as there will now be the swiotlb cpu-copy
overhead.

~Andrew

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 20 11:16:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11: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 1U87f6-00032h-M9; Wed, 20 Feb 2013 11:16:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U87f4-00032a-Tb
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:16:31 +0000
Received: from [193.109.254.147:4539] by server-11.bemta-14.messagelabs.com id
	1A/B0-30685-E80B4215; Wed, 20 Feb 2013 11:16:30 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361358986!2220822!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26540 invoked from network); 20 Feb 2013 11:16:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1647743"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 11:15:27 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 20 Feb 2013
	11:15:27 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 11:15:35 +0000
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcIABbPsQgAAGzVCAAA5dQA==
Message-ID: <291EDFCB1E9E224A99088639C4762022013F459CD3C5@LONPMAILBOX01.citrite.net>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B3568763C@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3568763C@BITCOM1.int.sbss.com.au>
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] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-----
> 
> Direct IDE seems a bit risky... it's all black box stuff though so anything goes :)
> 

True. IIRC Microsoft removed all their int10 code from Win8 though... was just wondering if they did the same thing with int13. 

> I've been doing a bit more reading and it seems that win8 is able to involve
> the storport drive in the restore process too, I think. From
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff563901%28v=vs.85%29.aspx
> 
> DumpMode
> A value indicating the use of the miniport during dump mode. This member is
> included starting with Windows 8. It can have one of the following values.
> DUMP_MODE_CRASH - The miniport in dump mode is used for a crashdump.
> DUMP_MODE_HIBER - The miniport in dump mode is used for a hibernation.
> DUMP_MODE_MARK_MEMORY - The miniport in dump mode is used for
> marking required memory.
> DUMP_MODE_RESUME - The miniport in dump mode is used for a resume
> from hibernation.
> 

Interesting. I'll have a read too.

> In order to play with that I'd need to download the win8 DDK (the visual
> studio based one) which I'm not real keen on doing just yet...
> 

I sympathize. I've been through the pain. I wouldn't want to do it again.

Cheers,

    Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:16:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11: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 1U87f6-00032h-M9; Wed, 20 Feb 2013 11:16:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1U87f4-00032a-Tb
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:16:31 +0000
Received: from [193.109.254.147:4539] by server-11.bemta-14.messagelabs.com id
	1A/B0-30685-E80B4215; Wed, 20 Feb 2013 11:16:30 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361358986!2220822!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26540 invoked from network); 20 Feb 2013 11:16:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1647743"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 11:15:27 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 20 Feb 2013
	11:15:27 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>, Andreas Kinzler
	<ml-xen-devel@hfp.de>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 11:15:35 +0000
Thread-Topic: State of GPLPV and Windows 8
Thread-Index: AQHOCSZSzlrsJnkBsUi8pqNJrFJLgJh2yvUQgACo/GCACa2CcIABbPsQgAAGzVCAAA5dQA==
Message-ID: <291EDFCB1E9E224A99088639C4762022013F459CD3C5@LONPMAILBOX01.citrite.net>
References: <511A45D0.4030806@hfp.de>
	<6035A0D088A63A46850C3988ED045A4B3566D4A1@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F45755AE6@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B356826A6@BITCOM1.int.sbss.com.au>
	<291EDFCB1E9E224A99088639C4762022013F457560C9@LONPMAILBOX01.citrite.net>
	<6035A0D088A63A46850C3988ED045A4B3568763C@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3568763C@BITCOM1.int.sbss.com.au>
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] State of GPLPV and Windows 8
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-----
> 
> Direct IDE seems a bit risky... it's all black box stuff though so anything goes :)
> 

True. IIRC Microsoft removed all their int10 code from Win8 though... was just wondering if they did the same thing with int13. 

> I've been doing a bit more reading and it seems that win8 is able to involve
> the storport drive in the restore process too, I think. From
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff563901%28v=vs.85%29.aspx
> 
> DumpMode
> A value indicating the use of the miniport during dump mode. This member is
> included starting with Windows 8. It can have one of the following values.
> DUMP_MODE_CRASH - The miniport in dump mode is used for a crashdump.
> DUMP_MODE_HIBER - The miniport in dump mode is used for a hibernation.
> DUMP_MODE_MARK_MEMORY - The miniport in dump mode is used for
> marking required memory.
> DUMP_MODE_RESUME - The miniport in dump mode is used for a resume
> from hibernation.
> 

Interesting. I'll have a read too.

> In order to play with that I'd need to download the win8 DDK (the visual
> studio based one) which I'm not real keen on doing just yet...
> 

I sympathize. I've been through the pain. I wouldn't want to do it again.

Cheers,

    Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:18:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:18: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 1U87gU-00039H-7W; Wed, 20 Feb 2013 11:17:58 +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 1U87gS-000395-Q9
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:17:56 +0000
Received: from [85.158.137.99:33475] by server-16.bemta-3.messagelabs.com id
	7C/11-02727-4E0B4215; Wed, 20 Feb 2013 11:17:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361359074!16305038!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11800 invoked from network); 20 Feb 2013 11:17:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1647848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 11:17: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.297.1;
	Wed, 20 Feb 2013 11:17:54 +0000
Message-ID: <1361359073.23294.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 11:17:53 +0000
In-Reply-To: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 13:59 +0000, Stefano Stabellini wrote:
> ioremap can't be used to map ring pages on ARM because it uses device
> memory caching attributes (MT_DEVICE*).
> 
> Introduce a Xen specific abstraction to map ring pages, called
> xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> On ARM it explicitly calls __arm_ioremap with the right caching
> attributes: MT_MEMORY.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

If you were respinning for any reason I might suggest
s/xen_remap/xen_map_shared/ or something of that nature.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:18:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:18: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 1U87gU-00039H-7W; Wed, 20 Feb 2013 11:17:58 +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 1U87gS-000395-Q9
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:17:56 +0000
Received: from [85.158.137.99:33475] by server-16.bemta-3.messagelabs.com id
	7C/11-02727-4E0B4215; Wed, 20 Feb 2013 11:17:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361359074!16305038!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11800 invoked from network); 20 Feb 2013 11:17:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 11:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="1647848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 11:17: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.297.1;
	Wed, 20 Feb 2013 11:17:54 +0000
Message-ID: <1361359073.23294.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 11:17:53 +0000
In-Reply-To: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1302191332340.4654@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: introduce xen_remap,
	use it instead of ioremap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 13:59 +0000, Stefano Stabellini wrote:
> ioremap can't be used to map ring pages on ARM because it uses device
> memory caching attributes (MT_DEVICE*).
> 
> Introduce a Xen specific abstraction to map ring pages, called
> xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> On ARM it explicitly calls __arm_ioremap with the right caching
> attributes: MT_MEMORY.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

If you were respinning for any reason I might suggest
s/xen_remap/xen_map_shared/ or something of that nature.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:23:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:23: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 1U87lw-0003Sc-H8; Wed, 20 Feb 2013 11:23:36 +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 1U87lu-0003SV-Dv
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:23:35 +0000
Received: from [85.158.139.83:31398] by server-11.bemta-5.messagelabs.com id
	3B/63-19159-532B4215; Wed, 20 Feb 2013 11:23:33 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361359412!20865420!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19336 invoked from network); 20 Feb 2013 11:23:32 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2013 11:23:32 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 077B94001FB;
	Wed, 20 Feb 2013 12:23:32 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id XBKxf848QWed; Wed, 20 Feb 2013 12:23:31 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id A0B4540010D;
	Wed, 20 Feb 2013 12:23:29 +0100 (CET)
Message-ID: <5124B22E.8060001@tiscali.it>
Date: Wed, 20 Feb 2013 12:23:26 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============3293686369349480672=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============3293686369349480672==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030400000108080603080105"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030400000108080603080105
Content-Type: multipart/mixed;
 boundary="------------000304010201070109050100"

This is a multi-part message in MIME format.
--------------000304010201070109050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 20/02/2013 12:03, James Harper ha scritto:
>>> I added as attachment the build log for this, can be sufficent? If yo=
u
>>> need other test/data tell me and I'll post them.
>>>
>> Retried now with rev 1029 and gave the same errors.
>>
> I also need the output of the build that gets printed to the console. G=
o into command prompt and set the buffer length to 9999 or whatever the l=
imit is then do the makedist then copy the lot into an email. Do a cls fi=
rst to clear the buffer.
>
> James
>
Done and added as attachment

--------------000304010201070109050100
Content-Type: application/x-zip-compressed;
 name="gplpvlog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gplpvlog.zip"

UEsDBBQAAAAIAGthVEK+6zT2tRIAAN/SAAAWAAAAYnVpbGRjaGtfd2xoX2FtZDY0LmxvZ+0d
a3PiNvB7Z/ofPP3SZwx201yPTjolQFJaIBngen3Q8RhbgBtjU9vk0V/flWQsY2MsGXwlqW/u
jL3aXUkrabVarXRX77q9dkPqPOlLy7GcuWQ0Jou5KpmWh4zA9Z6lwENImrmeNLNs5EuBKxnu
cgXv8scfubrhSZbzoNuWqQdI8lw3aOhL8+LcWNxLNX0duIaNdOfvNVqjjz9Svr9aW7aJs5kj
B3lAYlK2wCTMefKEnJVhSV/E/2DST52lfo9k9ISkmuPa7tyVSOH7o5vLUeCuZOnMohDtrjka
XeJHXRrc9rqDny8ViXzeDnq/wXu/+XOn3R1qw06vOe7+0tHGt9pVc4Rhl5/ivDaMG9Kd5xrI
96HI2+X7+COVszIPU1PzDd9auV6QrJX6AWulZtcqXVCMDu28epZogmw5TxmoE3f6F7S29mgv
NNL0E/qMCGcg0ZAZlV2cGYVk8YjwZ6RACpEvZmXpgSUTmB/oyxUgSGezwgWUznSp2W9fnEtn
pvSFdPYg1WVFkeGBsxjRHObF2f/xC/J8y3X+lHwYVPAiPVrBQmp71gPyIO2yrtbUOvxVvv6K
5azsqLCyVWFRISbreS8p8tt4dQV7NeiHl9Grw4KC/KLWFJZd0Ubkk6eDgpNWeQ7i0gkgaL4x
UWQ8czMvNp752RftClR6VJpx6RFIZsYR/kxQJ3Dx3CcrNlqEuRYVUYvYFjjHzwbu6NkxPt9k
bVtTe2b68sXE94wJ7p420sBM0cA20R4tx3Qffe0eeQ6yC46kTUqNCBGzNO8nby7qULSLr7/9
Rq5PppYzwYxwC8gmmiUHnxIOvkMHnEBdcY9OC21bux1HQfNXLlcpQ5mwCMRr25DGzeFNZ3zX
HP8oWb4kyzX4C81SI8pjaUM/rhlSrfXEWrNLOye8yPifPAH7dek6E8sx7LWJdsEmq/XUtgyS
xIoHqRjEM3EAWqsxeW857fbPW10I85joK+tABOiZByI8mrPJ/RIeYALsxzRghpdqv1v0X1t7
3x1cnOMXojY0eKP6Q4K31u2g3R13bwfaj81BG3rLzaUC4MFYe3cHb/S1OxiNL+vwDpy+Vi+V
On7XBmPlVw0+woTBmFBqBEejgPpT/WKT/ktnGH4zrG4Hg94AiBSGAnud5kCDwmh9eAGeOKXd
+aVH2Levbmg2Gu2xzdaP3UFH0y6pMAD32uVp78nieYU8Q7dtGRCkJEz3l0RPZ0j5ynJCNnhB
RR6GLf0gPjyySmfYsuevyBBp+j5aTrGyaOwuplqwmFQ+eSVQvu9bhuf67iyQPht+LrVqrS+/
lG5XgbW0/sFKguoy5EnhBCIpkHVd/rr+Rn0rq/U3ZCn6dHFOJ4vVs2fNF8Cq9bnEGLfITK7j
aUeWpKZtSwTLlzzkI+8BmdjUOF5B1AMLYti4m33CI8faJ5gA0Fv4N9Jt4QfhtkufYfgePYeT
07qOgDn1HUbNVWlHQgLVBo2/kdrRBgkWrUJEy10EqdYf5yPHNS2leqfx0BlkwRJvZCVq5EgP
b4By9FKDv0BOJkSmpcPko0kL+PG2JZ4euAkUXskfjETFyySJC5sxg4V4TJRhrSgRm9/oF5vi
yDeb5jbfbKoDVvvzZJyVDM6DMUlN5KOk82HomHj31IpTtqdXQpuJraSxGW82IRPULHDWRA2c
MtMwXTiNs4+rUGrZ0zlhycjUGJm6hyzK7W7YaTXHHQ1g2vW7QQs32SjKtD9qaYPb27tx1Fjt
dlcD0YwALRRPPdYL2j1WikG7c/XuhnyctandPXjXv+oMN9wN+vO70Xg0FrqnBWchwKZEWE7a
z53hoNOjlQiTV99COkfpb57J75kx9QMP9AGFvv8VU6fr9h53/H11pGidH/0z44yi4tlkuwIh
wA4LMDwLX67D31FYhTeASKtCAbdm+Iv1S1h0NVX0mx5ASVE3bOhvhqDaP/fb11q/+dPtcFMd
bTQe4qFYV7ZQuoMdKPVQswdgS5mWHVbl0Ty/qH/N3lVclUguFL5wl2ile/rSD6efHBU5edQ9
7KiXF8BrIzeVyU2e6FgOOll0a+CYnzvI1GbgxJeNjMQl2H6ukUo2dD8FM3cBoWQeWiInICk4
K9vyA81ENgrQNmyOAk13wNmCEsgOetwGrNyVtlr7i20obCR4zwREthTCPBgA82FfKXTyJN+4
o0zXsxnyKI8kdFNSKEOQSIryYKBYRn6y7n6q4gwKZvg9+4wYgzvHuA95MMB2MhEOlhIDRaUI
O8QoHDh4nITjRo2Pmx5LV77P7jWhxWny2IGhJZoeTUyhp0fR5VtIyh+DKscYVLfGoBobg2p8
DCbGnSo+7uSNa9iIXrWZ6cY/V9uf6Al7FwkEPQTGwiGvcycIpvYGb7qmo2uJlrD1Fqc20YNl
IBhqAfJmuoFiFKm0ON0C1hs+eIS2CqZD9qF5t5XHdL7ygEvYgzYVxL0jW23Q9JTeoAyYWBgS
UyQRNK1JaFJClWxxXW247tItLGUzrja0rClCpJTCYWCmcSg1bTaavqV+GIRkxT7j1LSlE4nr
kDiljigNbWCGktZNyTRWV9qHkuk40w3UT8k2o7Mx9LSUmfNRposQptniddjHkwltS/ExCKtU
slczHKYPGSwu/p19X9Apgysl1WDxJNXcddBgzkeKGC2rCEb3BpRUp3GuvP32q3OwieDx9Rv8
eAuPi2/g8aaOHzj12zf4AQmqqnx1rtQJDB6qEj2+/kbC9hh2a4LjWV/bAcllqRsLy0F00x3K
FhjzYzqOgMVuv03Pmno6RAf0dUefx5wkb7d8JIc6aYq4iLOqkjXBEYdd+VlRbVlyZqBUS87B
LD+LaBIoIZ/tGaWMtt8xHZVaEVCNZbLfzIpl5kG0dAkZkPm1vJYm7EuSP+FdsmDwswy5MGOj
PNnvNIbKGGcso5JammVQWnP75Wo8/wOoO2ZUlsa8nOYldmiJssfsSy36xqwuLYN4r1e/Ty1F
BTckEyY6l8+CpmKrnXMzM7KK1YJW8aE7hiUsLgjb97+S3601BoFsrzMIiKw16BsgN0IhwiuB
cclxa9NcKCBPEB/7IIRpVgVoqGeBn4y6FPjxiRNBTFyw+ObHp04DfvwMh4EQAyjgYQziHgFh
wphDQEyucTVFCKmm8pAe4PABm6oCEXZEA8EcKgEWBM0JkaInskjvgfrDuYMSLiOeXpVwAFgY
Ujq4xaD6Jhys18sPDMsNM4WSbgW0EXGElSo1pn5XzfLrkxvoloqp9wxSrjNbOq+/hW270a8j
7W542+qMRuDSbg5h53HcaY3fDTuXn3zyCdljhl8pxKTBbzgljEb1n32cTNJ/G407fa1127+D
ol71OhrUodO/6v2mDZp9wi6aZuT3dIKWR89+gJZY3NBrpzYK8+rlMevxc6NFj+gjpz8kkvSa
BwGXbrHgepgUX0NEmkhAWrRzHO0aS6kt4x3bwft2gOP7u5l7urgKRw6f5Gjo3IiRAxFywyRz
EXB0pBz1R+xRPuogB4X4Kgd5/oxWje2XPLb/P6HRctRhjfSCMBw05H2IfHftGSgdWXohK/LF
2/q3cv3wpaHAWhkH7wpp4zCK94SCZ5WD5X3YBlUUvCskx/82ipejgPnBqVyRulxIMByPhASj
cSs2djsClgWj7o31PDiiUz0g0nJn7OS+QMjCEY2CIYg7QwzzIwu3YwdzYwb3xwlGYYC7w/5Y
uB8LsUuFyIlHRtHYJ6HRM3mh4UxQtTD0h34UjI8Q9buCeZuIY+B1wzr3u4MTupsdZN0mzoMS
4xNq/Q5Y6w1wJNx0LvFDikPHnV/Hl3KAngIKHnXI2Gh0B93xVyaFwcBoDDvX7KPbIh/lOHkx
20Fr2Ol3BuNmrzG4pTAPNih0H9GPwW27c9181xv3ulcU8v5X+mui6Xoee8V9s2E8fDWzntar
r1ZwB4ROUx+ouBsw01KA6ydBu7sVnrsm0NAbD7EbYAcd236uzdYOCRNY6ebSAm4UujKn+FYK
aBo/lPS42fq5UX86r8Ofr+pPCvyEBSdHUOm7v576ZDnTcPQAwF9dyBu0KYijQeg2EOhP3nPj
+omeYe3gL5JQqMMDIZ+PnPn3hGk8JJDPli+en4ymFqHBPvlCdKuCdNQ3L0ZK/fNiNMRHLy5G
cIOL0VBfvRhNhr9emAkU9nAmcb99IeKY715c3kn/Pb9SuiLb9bcPUG3bffwZu+35iZ3A9e89
xxajWuiCBI9LCwBcNOFqlxLiNe/kvTnrmV5x4piG5GISEw7Ycr4+Q2Jkj+YSbhkQoxkG9gPi
q2NEI8v4L/vW10/afVzM8bUXuSyArDY2sAgtpjQbUn/U7Uky3JuwdM01XOwAC2P6trlnySRX
J2CrFFbNa8f8Dlsgge6F20zOfZjeG7duvpN006Sv+KamYIEoBl4wwlYK/kA4wYK50n2giTAZ
guqHBTlgGKiypiprqrKmKmvKqqypXJrKmqqsKS6DqLKmSrOmhHY8mINKzKFH0XZ4qkQ3UCKX
lVrcyDpsx0TdaWSpu40sdYeRpcaNLJUZWWXGJaaMLDVuZKlJI4uFMjIjS91rZKlJI0tNG1kq
X7dOGFnqTiNLTRpZaqaRpcaMLDVlSanZZpe6MbJu/JgKIQmHDQHMoRCxhw4ghlT+RtgxqfAT
byYVMaqFLkhAJxUxmqRKV0FJZk3OVF2GqWLZbJokoqJtcKor1kqZVsq0UqYixJUy/Q+V6Q29
CJhECrs0rOMaLl/3F6A458k0JY2uZKJzx04f9ebmMmOn2c3NXBWDi1lh/Vx+sPsBIe6smFVA
OF+sqMDtzFXQ6EsOGuVo6NyAswMRcoNDcxHiAeGvIiYUGuRFxYRGMZlC9TiBmEwoYBWTWcVk
VjGZhWIyYfT8f2Iyj2s1UnP01dqOtHoZHWMbqTIgX7wBSRvyxZqPBQ4fxbuv8d+fiREKGcf2
pkD7nd7/IxBdRC9QC3bVfMYF70qGranstzWVHbYmAYsNkvy707muaudC4rqqnQspPnDysZO3
v2df8X7AHe2Ct7KL3bNe4EL1gpemK3G7VInbpUrGdeXp2eLod6jvvxQ9uv187+3m5/FryvOu
IbeSt4+H6b3t9GtTYKRNsi4fp82VdV3yB76y/NBrygE/OU8ZEgZvwQpe9YQ3X8RWAvzBHMCo
Cuao9h9f4P4j/xDAHAoRe+gA4mr/8QPuP0KTVMEclTKtlGmlTCtlemxlmojOEHR/MBtWZNUQ
99py2LEUMdeKrc59cSve6twXVbzpw125J8E4z33l99vkICBcxBkwx/+hHKpTLyd66kVsIki4
JU7VTK60daWtK21dnEOlrV+Ftv6godMOOu2IaQflB0oboPoN15lZ89ONkmZlPHaINEjoVYa5
QL0y1F6YWgW28Ae2nLW1m7ve3S8aiGN0cYpxLg56BfHRpFeKXjGI40VSWmIiGJosHhFzmGf5
ZIJVhPZXsah5utxGzCwUhreB/sM4mNyy5YeQcMW3cCFVwSiHBKNofSjwfx6L0r4bNe+iZJ7/
tj8RofIhYlJye/3kJYaWsFqFcSVxwGkfTHHQaZ5HcVB1DKU6hnLgMZRtO/p/eTLFQa/tQAq2
2o3oVQue4l/e1pdrmfFPqpDC0ywUdvgN4/kzGsPAXoTEVqnAYqLaJ60876HnfYm8OWrIHi4B
FXiOR/7b0COvRj73wNdhcKGwds+OvrQM7JlPeuShT/quveMqzfN68i7NpW45reF4hDed1iuS
wt25GYaYY1w3H0BPfK2KOX3pHYN8VDBzh1RL/wE+eGj2uZdZTaudvUq/VPql0i/H1C/q9zG7
iHwyw6jAhlTckMrd2fEX6wDcmg4YWae7tRMrZFhBZhoKW4PYQ5nmm++mPJo/4FB9G/oDuOvw
HzpM8wuX7+fkcoZyIVUe08pj+kE8pvnd/kW6TGPVCn2mMchRTuLl70inA5c595uqc3filnJ1
VKTsoyJ8HR4TitB4SJwGUkVpwF4tROYVIwODthAdNV+qAy9bSw9BMtPyeY7IwDMVa8d7Iz9t
rVP1r1SzRjVrVLNGNWtUs4YA2QeYNQSvxT5kfcKxqouh7Ng3FPE7VRuH4hNP5dg/Ccc+R++O
obxu1z4nmY9AhlAxMaqV++iBxTqLqGJiPVU7ulJnlTqr1FmlznjUmeC+5959zkfdChx3hRwT
gJbjg76x0QOCCp7u4bzsMgu62vGWZy7PieB5mAN2QA/1iIQ7oEWr9B9GSQuXNT9KmSsomgup
inc+JN6Z7I8KhzsfO7Y5uT9aLOK55Bhn4VHwIuOes2sZhjNnIxy+mSou4myKHa6MA+aTaiNW
fCnwSl3q6aXAPld7eimgxpcCanIpoO5ZCqjppYC6eylAUgp39mwKMc/yZqEg5oClCwU+quRC
gYeG5WTM5su5F8spu+Kn6pmo1FGljip1xCfRF6eOhLaJ/gVQSwMEFAAAAAgAZmFUQjeoLfCg
EAAAZ54AABQAAABidWlsZGNoa193bGhfeDg2LmxvZ+0d2XKjRvA9VfkHKi+51lgab7xeVTkV
WZIdZXW4JO2RRCkKwcgmRkAA2XK+Pj0HDAhkBh1Z2avUBpie7p6zD7pH+OJ9u9OsKa2FPrMc
y7lRjNr49gYppuVjI3T9RyX0MVamrq9MLRsHSugqhjvz4Fn9+qvqzxdzyzYJ3Q12sK+H2OR4
lsNZjRfY8QxL+SH5HyH91pnpd1jFC6wcO67t3rgK7U13eHU+DF1PVY4sBtGu68PhOblUlF6/
0+69O68qtNjvdX6H5279XavZHmiDVqc+an9oaaO+dlEfEtj5t6StiHFNufZdAwcBH6ro39df
IcnB3E9MLTACy3P9cHlU6H8cFVo9qmxHySTAwnmPChuuajmL9ASM3cnfxu2d9mDfaouz07F1
ApcYeQrtcQaMc8wg21Yup5hqSrtSpTNLGFp6aKkUFoT6zAME5WhaqmvKka4AWDkylR+Uozul
qr5Vju6VilqtqnAhvIeM9U05vn9+wH5guc5fSgDCAA/KgxXeKk3fusc+1J1X0DGqwL/qyauo
NXmhoFMGIkambK+lI9lRsg2yi4dSi7fetkiuYnr5ULx8a3Jebx1l9YGD91sNQP9gkQuFFxZY
Yi6FGmCck5woJJcBr1pD+kt0LbmBJOS/DOd1N1AJSSmeuZICIsFwvWFVf25QB4A0913PHT46
xvdRu7Y1sadmoJ6OA98Yk41oYw18CQ0cCO3Bckz3IdDusO9ge02VF9Uc08kjLM278ZvTCnTt
9OTsJ7UynljOmDAiM6+aeLosZlUuZsWila8Z1xgrWaLspKWN0XZ0iPzgCvUG9IlMQfnR1pRR
fXDVGl3XR78qVqCo6jH8g2U5ZnrIVn4pzzR3Lxu26gcelaqZrRwH+hQH+FY5NuCfO50qx42F
2DBtSgJ3lfyvjsGNnbnO2HIMe27iPNjYm09sy6BVoq9QS0CFngTgNGrjj5bTbL5L7VDCYKx7
1oYIsPE3RHgwp+O7GVzAY3oa0wAX5fiPmQIX6FVT+3R2qp1X4YkMFB7gaThqao16pwOPjX6v
2R61+z3t13qvCdvxiuL2Rtr7a3hij+3ecHRegeeP7d4JOq9WyLPWG1U/aVDgFb0RpdQojsYA
lUXlNKr/0BrwssBqtwjoDYDgP85e67TqPQ06o3XhAXiSmmbrQ4eyb15csWY0JhL1xq/tXkvT
ztl0QM3ldf+8AjSXbuGyj0PP1/BsboO/oEK9kgHqwYwIQtcyfDdwp6Hy3eB75QQdTaxQaRw3
fvxR6XuhNbP+JfLI1Ab2Fa6rlepPKizOSeUNequiyhv6anZWgdaZZvYefevmFng2vldECw1q
53Si41VFqdu2QrECxQeB8e+xqVJRt8kIv9mOcB5/Q1gCwwa7d0fs/l5jT1wg+aMa3cXDMfyD
vXfMAdvpFWFWKHdbQgL52xKSwV7ghOTxEhkRLwgB5MWsEDLMSBCjkpBFWhbySMuxTEYAIZes
lJVNjifkU8CyMkp1dz0I8GxCbGNtpbSskmRSx2VZFC74WFfLNKmN5DpmcT1oNeqjlgb12uX7
XoPM3jDm1B02tF6/fz2K563ZbGswwiGg8VFW4lky2O0Po/Zg3Oq+Fh5xgM3v3hl7uHrk9xnD
ODImQejDXDDwx0/8/pqj/cvut27o6aFxy0qtX4Mj44hjDKKHS34f8ibfsHvf5HeL3x+PIgQx
09q71qDX6rDZ4+B33eal1q3/1h9Ew9aGowHZWZVqCqXdy0GpvGU4D+br08qJeEa81fDRw6Zl
875cFojf+EH3ScBKZTOgjnUybTp1YzXdtm4cbGpTiF2pxorKmW7brpGpNvQgAzPzgNARH8+w
E9Ia0pRtBaFmYhuHOA27waGmO/C+gZeQHfyQBniup3nz4DYN/WeO/UcKgqc55m0IAOEjShl0
eqVlsq8m8+kU+4zHMjTqKfQhXKqK2xCgREPB8tiDzMAFFCT9ThRjxvBiZNxxHgKQrqaTQ2ZJ
gOJekI2weheApmG+Z7EFj93KHdhotJGNRpGNLhwEMb+Im18UGVv+SBnlObwE/oQjTKqzzjAF
yzjEgCdjVreCBGZ1S0hJJ7kYm1pqlLLUKGmpUdpSo9WWGqUsNVqy1GjJUqNlS41SlhqttNQo
x1KjFZb6CSOMIiMsChdsGE8aYRQb4Qiz2REses3WxfsrWjhqshfd3vvuBfS0yoFZQ4UKTDla
MuXoKVPOqskGT5tyDrD53TtjD1eP/D4jGClTjqgJ59X/srsw4Sg24RxjED1c8vuQN8W3ft/k
96j8eJRGuDQLxXHMMLNWXSxo1pqfExko9gWQhC+AEr4ASvgCKOULoJK+AOCrUQzfiB+1qekm
i166iBckCkgh+B5WxKGPN04YTuwIbzJnLsAMzyAtlqQ28b1lYPAHQuxPdQMnKDJ1SbpbUO8B
BIKSMLoh+PtLqo3JjQc7ifSRjDEaIDF5T/g2ol44NwyY9W4IWzFZMVbW3WFVS/5Oit6L6PMc
IFETGX8GybhAMUuxQgJTuEUMlvSLGCFfSFErmkp4SQw3WmlRSa8MkPGZBDjrNDF+bPGX8UQH
BCzZC7azGEbKnxKQ7EResdQEc0NMrKrUuK/cmanwLSCTctIpi8uis2m3TAwvy12gC+q018bo
l/e/QBTTkR0ZDw2QfrKYKDghyrE7D2siwEgVW+ydUIT2FSigVu119e3Zq9eg1OFy8oZc3sLl
9Ce4vKmQC6k9e0MuUIFQVSHvXiR6CCFkfW6HlNlMN24tB9csUKJbi2ICPfE3szGhjjXxdUjB
d3VHv0m4l29T3uUW4j7bGccK35tFwXbcDlN4u2wJlOQu2Zs75h+r7203kjYEW1/sHBOyuyGA
1toZ78is7awBqjq3zZ3awR0tLeW9izmnjHc5H+S69ekQTsGO5jvXY9m6MIlWdrG0gvtu1jfY
oSoLdq3HhCO3G847WE/q9e1qvgnv3XU68ml3wz25u9HPuW+HcYV4PaTA/HeCXM+5OEjAqogr
LRM5jV1ZtKYru2l4dH13n1J//ETvKa+fQlKeP4MARo3PDjxSWPEELSWH5c8jlkEmL/DlCLyy
BOx9XJKGvYpLIrN3cUlk9iYqiczeryWR89+gSywa9GsD6uT7cTmqhI4oMYtJJRJrHaXhY6ZG
bCa+0ryovgArpwAKHC2Tp8ML+h7cAVVF2gWVuYtj5EghZ6T4+cpen4Aq0YmpTqf47FThkVno
aerMF50LPqidHiXPG1nxeArPgiU7SneGb9B+HdnK68pbCMQPPw2160G/0RoOIdxbH0Cgf9Rq
jN4PWufffPMNrDJcFY7HTocROD9iGTwGpJrW/z4ctbpao9+9ho5edFoajKDVvej8rvXqXcos
NgnqR2ZM1eFjEOIZmWzYrRMb87Y6Rcw68txY12P6OBwOlbT+2IcTie4a55PBer2MA1XrnKeK
Ez5xskfJZHpysjxPZXiS2Z3VmR1oe8uHAJPr/TxPA5Izfmq8LUkIdotiDgrxRYr50+bsIN0v
RLq/kCO+arxvjewrHBcc+jzAgTv3DZw9+nKqVtXTt5UztbLpy1x14/Y3y4vw40LyKv55nRtK
jmbfDhAl+/ZyThLt6dmgRE61ZFAIDHo6JSoVIoKmQEoOZ5K+6DNJSQkvdzhpv44ZwTj4kZyo
kDVc7Sj1qts0BrDDTP5xtwVOdw3iAVetc3JRktBR69PoXA3xImTgYYvuwVq71x69MhkMNmBt
0LoUhXaDFjaKrBLqXmPQ6rZ6o3qn1uszmA9hfz3ArNDrN1uX9fedUad9wSAfP7G7iSfzm8Qj
WbWacf9qai3m3ivP1EOd1d6zWa2dqrxRN8iApnOHJsQ93YQvHtR+otDol2Os4JkT8okDmNiA
z9Oo3nhXqyxeV+C/V5VFFW68P/SnkpzHfBLQd4qao4cAfnWqRmgTGGWN0kUQ2A3+Y+1ywX5r
2SKlX85oVXkVDFQSkWcRYCtH4GPZFpZi25JUrKo0AYlxlyfy1iFise4SdCzeXYKAxbxLELD4
cgkCFvsuQZAf/y65sNDHDTkk4+DlKROx8JKzm4yHx5T55oH4smOgZ7QXNDndv4fB2u7DOxII
l6Z1Qje48x27FNGtXg7/YWZBWYqEvztSOvICOf5oTjumvzZtQtlJ8RDzAi4LUdGlqB7MGfys
vRTJILTvsdz4IhJVhX+iqM8X2l1yfpPvOuSn6ZkTisR5WPbAS/hJDCfripd6cRU++fquy6Yv
qHmuC8p3XVCO64KSrgsSrssWksIZ1wUlXRe07LqIPLJwXdCTrgtadl1Q1nVBua4LSrouaNl1
QStdF5RwXVDGP0GrnRkUuS5XQcp1oVUb7F1CXp7Sx+tS8hSnlIjnqHRp2killyK61cvhM5Ve
imRZpSJQVMUmsVQT0TJQIulsKHyR5XlkQ+MPIlWlBgZfIwEHaPfp6w2S1qKbhxSvTO5H9gtC
hyTQy0gCRet9SPGuEnOmPV6ssLPh5S19GuMg8S9I4tmSPk95XyP7K4a8F0lgnoSVV8LPMAkL
o9nbJCz07ZCE/R+SsM87GboHRzUOydjo24qy5otryk2TuKAhvoQk7jbMx2abPP4+n+wCiy/w
PfG9vazxqD5tPKo5xoOCS3hOxV+8k/rAnhSS1Af2pJCS3lQx9kv+Zt//8Tm+yNBUU4YmT9FX
8xT9fn/Ubwsf87OKPubHAZemrFSOV33mj63rqg8CPYePA6bGzj8VtwTLOQgnPXHJ6EdxKo7h
PZWIK04JSoQdC/tBmBSnBA+nmb7I00zJlGDh+Sbp00xl5YiwKEktYnAbkR/OfOzbmY9SCcq1
ddamIZ7DMYYXeYxB0t4S8vKUPl6X8nCMYffHGPgyUCKZbL+Dt/TnnHaU5of+FZ7GIH/hx3Cd
qXWzvwcxRB/jNEGm5om413aTnzCpLzLt+fRfETokOtdJdB41tavrzvUHDaZleLqPeU8HP/cD
DnRzGs8hCyiU1V4lAEW3Pnfu75Cx22LGTutC5z97wqx5Paxfi+rqhmm0TRNn6yXAhIQ829yX
GALPfyUBnz+tyxOahXaJe3TPJGkHg9i3bB106eWk6Q6Jt8+feEu7uIdcXJyLK5S58TNJpxEH
24gftXCRLPmpkmuZySLTVDwJF3HKyXjJmVlRTSjTCS/ZgMDh528vJG7sLAwa72ClGfZvcE31
STNs8iSjyyiOH4eBDnsf8yE8OvrMMkiUeTm6DJsrcO1keJlgcZbpiPNMt5zGYAR/sdkP5x6t
kdulorpU2Fc370GET1CpoCf7ybQcEdhb/hvz4B6eZUieyPIk9AktCoVSGLQMbuch+KcOaJf9
jVomOhmHLbNVBV5uQrE+ixhHYmR7FeRI9OsQ5ThEOQ5RjkSUQ05EnkWYIzEGHudIQGI7I3zT
XHdUcj4S9VmHVFrVHzzSg0e6Bx5pUGKzv1ifVI4qwDB3ulfubIHnPvie707lPpHwoFuh43rY
MQFoOQHoABvfY+jv/rq7q/uc/yf+Yp+4kP6Z//iv3MA+m4dcrpvFbq6ULyyFVOAwZ09zF4fe
WFX24LRMCoJb7IOjfnDUP4+jXk5Sn4XfvnpI3I1fjXD4Duvhlwvyv1y4Cgp/uSBhMwiVNIGP
SxJAVSkCCKGWp/HXoIEoZHki5pF8sb+y2OzLlqDugnV+FrHZ1yhLGpjV6Nm4yLru/iFMcgiT
7EGYpOSuXY3+coIoxvRmduPH7fwHUEsDBBQAAAAIAGNhVEK4MeHU/RIAADHbAAAXAAAAYnVp
bGRjaGtfd25ldF9hbWQ2NC5sb2ftXety6jYQ/t+ZvoOnf3o7MdhJc3ropFMCJKUFkgFO0wsd
j2MLcGNsaptc+vRdSbblC8SSgZSk7pwa67LSSpY+rXZXyvnHbq/dkDqP+sJyLGcmGY3JfKZK
puUhI3C9JynwEJKmridNLRv5UuBKhrtYwrv86SeubniS5dzrtmXqAZI81w0a+sI8PTHmd1JN
XwWuYSPd+XuFVujTT5Tvz1eWbeJqZshBHpCYtFgoJKx58oicpWFJXyX/w6SfOwv9DsnoEUk1
x7XdmSsR5vujy7NR4C5l6ciiMdp1czQ6w4+6NLjqdQc/nykSCV4Ner/Be7/5c6fdHWrDTq85
7v7S0cZX2nlzhOPOPsd1RQU3pGvPNZDvA8tp/j79ROVszP2tqfmGby1dL8i2Sn3BVqmbW5Vn
NN0J2mCsjZvDy85Y+6UzHHWvBtKoM5bGV9LNqH4MRQvkVb6H8bN8kmg3ypbzmO7YiXv7Fwwe
7cFBgUaG0oQ+Y4IpVBgWQrmOC8m3Y1NpYb64NIV8OVyopQeWDGzm4kg+P9AXSyCSjqbla5SO
dKnZb5+eSEem9JV0dC/VZUWR4QH1puoQ7pps0XeSIn9I1oBbMaIVzLZowR+/IM+3XOdPyQeY
gBfpwQrmUtuz7pEHaWd1tabW4Z9y/C7RuLhq8YaVq1FokgLcvY5JGjLKD6jQrwcNqMCfKIqI
5KVgQetJggWJ2Tjew2RexIGPwjl71qFLduYLs/gcqLB5J15s2XknCp/83ZduKS+4CZRfrsnK
9y0iF+G6vxi4oyfH+DJiwrZu7anpy6cT3zMmePDbSAMRSwO5SnuwHNN98LU75DnILjlPo5Qa
6VhcpHk3eX9aB9ZOj7/9Rq5Pbi1nggvCX0U20TQ7tZVwam87nQXair9XvtPSa8Nu0Ji/cYUI
DDzhLhBvbUOiKHXdHP8oWb4kyzX4B5+lJoZnIjgJc25hw0ypGVKt9chGSZcOeniR8f/yBGT6
hetMLMewVyZaFzdZrm5tyyBJrNmQiqO4lnPI12pMbiyn3f45NTZxIRN9aW2ZAYb8lhkezOnk
bgEPkJqez2mAnCDVfrfo/23tpjs4PcEvBJk0eKMQJcFb62rQ7o7h22g/NgdtGIaXZwpEw6f7
eA1v9LU7GI3P6vAOJR2rZ0odv8PnVX7VIBAmDMaEUiN5NBpRf6x/U1dpOoyBMMxydTs46rR+
LBFmaGSv0xxowIzWhxcoE6e0O7/0SPHt80tajUYHWrP1Y3fQ0bQz2hmQ98Ll+uCT+dMSeYZu
2zLkkLJxur8gy96Gbj63nLAYvM0kD8OWfhCfeBvZM2zZ85dkljR9Hy1uMQ411vOpluST9hAH
C33L8FzfnQbSF8MvpVat9fXX0tUysBbWPxiAKE4iTwoXJ0mBuuvycf29+kFW6+/JFv3x9IRi
6vLJs2ZzKKr1pcQKbpE1UMdLmixJTduWSC5f8pCPvHtkklXasPEH/oyL/9pnmALyt+BL7rIJ
MURBuVu2B4oKf/OghuOfATucnAc8Es0LejhvIa7tKBPg244yJYGwODeAIc4U4yAOMCwMQySA
3zcgIk6KUDEKMWAkYQaOUZgBJMswGFPy9UBJUhhYsrg8YOLoTYiJ00LMZIHzsBmbsTNKbfcY
2aDdOf94SQJHbSq3DD72z4E7hUZiDrSfO8NBp0dLjSu/HnZazXFHg5K1i4+DFu7SUVxwf9TS
BldX1+O4M9vtbiQnhE2vx10XjurfjcaDMdc9LTgKI+zwd/ktfbl8omwZt37gwbymsTfwbZUI
O3aH0RHAdH70j4wjqIKATcjI8Ch8uaAJ/XEYHoUsWzT+oxalXJk0hoFLAh6urCgcRlz24oga
/IOhXksX3N1dQ0McNblABTPOAxhcmcjY+LnfvtD6zZ+uhvEAUYrpKZYw+u4gQf9BnD5ZvzYa
DzEw1Dn4iAGI8ZEvp44ZyoJUAKu8adnhQHowT8i8VxLwFYZIgOVS39P3ubtAS93TF374AQu6
e/Kge1jPLs+h3GehUI60X0b8qk1NNxlcpoPoEe9wSQy6D4y5Q15nThDc2lG+25VPXhdoAcr9
JLWJ7i0DaZYTIG+qGyhBkUtL0s1hyfVh35ZiTIfqwwGfquN2tgTIwDzS5jO4VzJwr2TgXsnC
vZKCe2Uj3Ctr4T7q2zA9D/3KM9CvJKFfSUC/8iz0KwWgrWRAW3kOtGky5j8N2mGEDb8RaCsh
aCsJ0KaxN7/CbwTeGZS9HEYvF+HvKCzzPfzGWMpg87KXTl+zbCl8U51nFrOJq6QmLpueSmZ6
KuLTU57ouL90ogXSwMo1c5CpTT0EM2BD4gJ2DK6RSzZ0PxdnrosERjy0QA6dx7gq2/IDmIE2
ClA6boYXBQd0WyiT2UEP6Yilu9SWK3+ejgWrXAgBxD4X1sEicDkslMtOniSMB9TtajpFHi0j
GxtxCjwEmaS4DhaVqMjPtt3PNZzFwubtjgXjgkHnaNyFZbCIdDLpHNxLLCrmAg+EzaMApz4z
DFg6Gwc0Mj8QMCwxnI9z5UcGTcoMjRT9MqJfN1ZYStRPNCY3WuIi2eLCcrIRRONSQ4jF4OJp
OeGSxJLy1ORJc9NViybmhheLzo8vSk7XrWw+1lYWl+TCz/VntEyyVNaRYVUbl8+USliWZRxO
jtQ4zNhKj1XWkHzpLDujTg9lSp9dpFnGqOGCKhjMu1QDgVequaugwZSYNGMsCpMc3UuA8E7j
RPnw7bsTWLXgcfwePz7A4/QbeLyv4wdO/fY9fkCCqirvTpQ6iYOHqsSP428kvGZhNSYosPWV
HZBaFroxtxzUCJWMdmDMdqomgjIiJc1a+Sav+uhZt54OvhN93dFnCYXHh5S+Y1vVRhkl9KZG
blzoiObuBeqigLnv2gBo912F+QJ1xEvBPipKLyx7GQBrlqX9NgUwcq/lR0vmXishgL2PGsi6
u8fPTcrf1zcghe+7b/BzL13DBJE99v9aSWkvE47VtK/PzWrY3zf39wx//ktgHxM191f6nr4x
kU/32f+4/P0yH0nh+6shOfrV73MKNkGLZUas59NC02Qs6vOaO5koXVJi3ta4uYctCSn25lfy
m9qZkJj07oREkR0KfYPMjbAX4ZXE8XVkyrIu5k0pSoC1EeJEyzJEVMkgQEeVCgIERK8g2Gmw
ARcgoCoDAYINCgSxEoDHLUtIqgnEKRM7YsHeTcIWoaTI5SE9wE4DNgUGofIIIsHSKkE28OAT
o4UxiPG6B4CI6wdc3sfJBFXC7mih++zgCkfVI+e0Xq/YTa3QpRY4TbnXkf4IG7XX0wnrWlbc
nkK3u5c5nQAjzzNIe49s6aT+AYzvo19H2vXwqtUZjcAc0RyCVWfcaY0/Djtnn332GTELwq9E
c4aF45TQodR/8nEySf9tNO70tdZV/xq64LzX0aBvOv3z3m/aoNknxcXLmXxDZQF59OQHaIE/
I8yHWxuFdfWKCuvxl0ZZj+mjnsH8kPSaB26lbsnTArD6vgX/OBH3uNjBI3bukHKeHWu8Op4z
DiYNg88YBSVpx96cPF+60MVgywyFXpuFGbCzphwPSKyv3ek0B6h9k9OcY7GsZvdrnt3/I19t
OR6xRn7zGU4b8j5EvrvyDJT3Vj2VFfn0Q/1bub79NlRgZ459icUAOXYqVrZu53YGqkN2aubp
SObdnHJJfiGnYh4Oi31zuRyHuTJxOQ5zZar8hd+ov3AJTwJhbSNIWhmTP7fy0bnDuCjs1sz8
j3N+x1l/48jLOPwNw5e9dPqFKTbLJ1xOsjz+r5tcXnfr2Ar5Y3HbkHA4CuTXpG5kytZtop7Y
o7dErd8Bqb0BqorLzhl+SMnYcefX8ZkcoMeARo86ZHo0uoPu+J1J42BuNIadCxbotkhgP2pl
XOygNez0O4Nxs9cYXNE4D+wiuo9oYHDV7lw0P/bGve45jbn5lf6a6HY1S7ziz94w7t9NrcfV
8t0S7uvQaeo97e4GrPs0wvWzUeuPlOL1a4LHaqSTdgOsBmRG8Np05RCHhaVuLiwojsYuzVt8
hQh8Gz/s6nGz9XOj/nhSh//e1R8V+Ak5J2du6bu/uvXJvqbh6AFEvwMWVJp0C/3RwHQxIQwo
76lx8UgP7XZwiCSUwxug5NTLMyWiOJGHRGpKWQAE6GhyKSJsCShHuCxLSC0CgrTUKiBIRCwD
JToTNO+CRNRCIEi0wUogXgrwu4NSktaCctQJi0GJXs9aDQRg6px4D1zdQ9Nt9+FnbCwQoHYC
17/zHFuQbK6LUjwsLIiJieLVN0cU74QpId4PT27Mac/0yhMnYFOQbScA8cnXp0iQ7sFcwG0L
gkTDwAY2BYlkGf97sOdhWF89anfJrk7uzMi1CWQrEsUJ1uaj+WppxkQJ9G1I/VG3J8mQd+Ga
K7grAza79C26YsskN09gARJ2wivH/A4LNIHuhZYx5y5M741bl99JumnSV3xJVzBHNAfeg4Lt
BwcQTrBg5XXvaSIsrbCIwCYbchioEs4q4awSzirhjJuwEs4q4awSzsrIV5VwdnjCmZBVhikv
BVV5NN8aLaawlYepM8tLbduaVdZJbep6qU1dI7WpSalNZVLbPj01c1KbmpTa1KzUxpw7mdSm
Piu1qVmpTc1LbSrnAM1IbepaqU3NSm3qRqlNTUhtak40UzfLcWoktV36CfghCVvOAlxEOWoP
bUMNyQIfYs26JEAdrUuCZHNdlIKuS4JE2VVBBZDduMpTvA2TBSuKPo0oWRql6fc71C10BcYV
GFdgLEpdgfErBeNLeu008dV2qevLBfwhAX8OwDvLpin57MrG7Nze6zu9tnuf3uuUUeGbrnk6
AS71BW3B/o8mbHEggbEp6r6/S1/dN+2Sz3nHdeW0+5qddnm+dKG335YZCp1zCzMkXfLfhE8u
fBEun9yD94mFhhy4TyxwWPnEVj6xr8Qn9uCcTWH6/H+cTXcsO1IB9s1KkLR5m0ZGOlclRr56
MZJ+yNcrRJY4ApYcv8Z/f0JK6MAEljpFPmAoc+70LzNs29xQ5hRpRu2z6Nr3DXe3KxskTuV5
iVNZI3GSaMF5Unw9Of9d7AqPKLmTTIm5w3FRO8yf1OXpm69If+Za8//0yu8XvuY7kk6VpHSq
rJNOlXXS6UFeFi50SbhVcEl4GL4wRaYanvTP/LWCTX+I4DVePJ7qj/Aa6lRcySu+sH1IcEPA
77ICJVUuK5WV9FVaSQP+WYCLKEftoW2oKyvpy1tJ4dNsbyWtXFYqMK7AuALjCowPAIwzPiiC
ShgmRQttXJLqYw5JmmYslqOrA3vc0F0d2AuhO38qr/AIH+eBPY6Rm50HpJgSJTAjxNZFVAeU
DvmAkuBSwlsRWxPympVDldMrsK/AvgL77YqowP7/DvYv6qDuoMP2Swf+Cl3MDVg5DNeZWrPD
9S9nPIp614vkFdgmYlt9jrdCQ/1ufd2hljfpqQTt2tSTYXLlm8Tvm3TU1i6ve9e/aNAdo28O
0VXJQW/B0Z0MS+OAnXGKceo/9MQpZq7YiYXLw4YrU+UOs407jNYHhv9zb5j29ah5zZKVcj4y
e/aKKR72k9fo3MKaFXq2JCJe91kgB73uI0AOOtCTPw6qDvxUB362PfCTFnb/l2eAHPTmjv5g
0dqIX7XgMRnyUiHXMpNBCknhuaGoJMGtPrMI8y/aLAve7WeMwSKag4RHZdz66pr9ylYAsQvk
zVBD9jALtMcLbAjfhjYENbYSBL4O0w2FzXty9IVlYFtC1oYAg9R37TWXvp7Us7e+LnTLaQ3H
I2wnWy1JCv9oZ1kEFfm6eQ/YcawKKo7pBZjCZAv/HlZ3DXJCVx5jVotU65A9RStYYdl7HTNW
UNa9lQm0grUK1ipYewOwpn6fEARpkEmCJUx+Gcmx0Hzmz1cBaC8cyH249rMEk2JGMSFVCZOU
+bYjNHmNuySvxqU6byS+blQu7nt3cecc85hSiMhDJYggWZgINpnl6LySdADW5QgpTFfO+vk1
VZTOtHwu/3545vz7+W5t52Vl7fJ+qDuWauWpVp5q5alWHr4hVa08r2flETISYCtxfq/FYSrO
7E4P2H+Io13/oQMRB3fFfj9czkFcmSoPosqD6EU8iDjG/at0IUq0K/QhSsWk/fx3e+KXp0sT
edZYeIXWguqwr/hWojJ+HIbxg2d8J/JU5o/dmD/gK+hL0VNSS/fBAz3GVJAsIxMnvuahqmQq
HK1wtMLRCkfNQmT7D3H0UvCw6YNuBY67RI4JkZbjA5jZ6B5B2w/3AOpmnp8zwoud8BQyUGMt
TSFvHEqbnWlotjUBhBqa0m36D33+xZkt9rnncvHnylR572/jvU/0N8LO+7v21M/qb8r57+/Z
Y198GrxKL/7NzQyd8zdn2P4i5BJ9vJlkjbpnm0WlcmES37W8VUNyftfynIE5v2tRk7sWNbtr
UZ/Ztaj5XYu6ftdCUsoP980kgpbUaE8jaOGjexphsrV7GrXEnoa3QmM6W8w8YT7ZJqMAVA9V
d1OhYIWCFQpy92mFghwoKPQ3rP8FUEsDBBQAAAAIAFxhVEKLyk2xAxEAAO2jAAAVAAAAYnVp
bGRjaGtfd25ldF94ODYubG9n7R1pc6s28Htn+h+YfukZYittmnomnTq2k7r1kbH9+nq4w2CQ
ExoMFHDi9Nd3dYDA4IB89Dkpb/JAWu2u7t3VakOu3nV77YbSWekLy7GcO8VoTO/vkGJaPjZC
139WQh9jZe76ytyycaCErmK4Cw/S6scf1b+/Wlq2SejusIN9PcQmx7Mczmq6wo5nWMoXyX+E
9FNnoT9gFa+wcuq4tnvnKrQ1/fHN5Th0PVU5sRhEu22Ox5fkUVMGw1538PNlXaHZ4aD3G6T7
zZ877e5IG3V6zUn3l442GWpXzTGBXX5K6ooYN5Rb3zVwEPCuivZ9/BEq2ZnHmakFRmB5rh+u
9wr9h71Cm3uVbWh6ELTBRJs0RzedifZLZzTuDgfKuDNRJkPl/bh2BqwlcOvfw4LwnhU2jKrl
rNIDO3Vnfxn3D9qTg0NtdXE+tc7gEWPPKYc6HWjCyNJDS6WwINQXHiAoJ3M5jsqJrgBYOTGV
L5STB6WufqecPCo1tV5X4UGYjxnvO0nGf/yC/cBynT+VAHYHJJQnK7xX2r71iH0ou6yhU1SD
n/rZV1F15XcJnS/Yc2S+jnq7JBsKi4UvAFYQL4DsGswf3phsTlhlVwJKrYQtWSeXRHotoHgt
bMt660VReouVlUwOPm6BBO3bWrZESyu7CstMkqSQkWGdXFolxIwU6+2WVmJDAuPkqFHI5moh
v8U+LMFRcvuV4bjd0NS/b1HjhdT32cAdPzvG51HFtjWz52agnk8D35iSpWtjDewgDYwf7cly
TPcp0B6w72B7S+kclZzS4SMszYfpt+c1aNr52cU3am06s5wpYUTGXjXxfH1j1vnGLN6M+UJ8
i76SOcoOWlpx7kfqlO9coaSBNpEhkO9tQ2Hy6LY5+VGxAkVVT+EHpuVUWmRL4CoLWzkN9DkO
8L1yasCPO58rp62VWDJdugHgrZL/6hSM8IXrTC3HsJcmzoNNveXMtgxaJIYASgmo2O4BpFZj
+t5y2u2fU4uUcJjqnrUjAqz9HRGezPn0YQEPMPBexjTAoDr9faHAA1rV1n69ONcu65AiHYUE
pMaTttZq9nqQbA0H7e4Epkn7sTlow4q8obgwi+9uIcWS3cF4clmD9Pvu4Axd1mskDTNd/1WD
DC8YTCilRnE0Bqitat/UECuH5cDzAqvbIaDz2pkC/zh7rddpDjRojNaHBPAkJe3OLz3Kvn11
w6rR2Jprtn7sDjqadsmGA0qub4eXNaC5dovnfRp6voYXSxusDBUQlAxQDxZMNdvKD/I7LL9S
w1b9wKN7oRkEeDEj0qaxse6+Zfhu4M5D5bPR58oZOplZodI6bX35pTL0Qmth/UPkARNb2Fe4
rlDq36iwMs5q36LvVFT7lh5rL2rQCKiY9afE+LCmMl3iPfvW3T20ovW5ItrUoupdJ1pJVZSm
bSsUK1B82OD+IzZVKpxsMiGf7GkETz8hPIFji737E/Z+p7EUlyA8qUZvkTiFH9grpxywp2YR
boWCYk9IIDD2hGSwA7MQFTxHesQzQmLwbFZqMMxIckQ5ITxoXgiQKC+EiEAYTBh5vjChJUKg
CFhWqBDwJqlCyrhcEZkr3o3N8oWURjImZnE76rSak44G5dr1u0GLDMw45tQft7TBcHg7iYek
3e5GypF3oBYPgMFevxuNJ+Ne97XwhANs/vYuWOLmmb8XDOPEmAWhD2uWgd//yt9fc7R/2Pve
DT09NO5ZrvNjcGKccIxRlLjm7zGv8lv2Hpr8bfH380mEIEZa+7kzGnR6bPQ4+Od++1rrN38a
jqJua+PJiCyaWj2F0h3koNS+YzhP5tcwpyKNeK3hs4dNy+ZtuS7YWdMn3Se+P5WNgDrVybDp
1KrWdNu6c7CpzcENqBobChe6bbtGptjQgwzMzANCQ3y8wE5IS0hVthWEmoltHOI07A6Ei+7A
GQqvITv4KQ3wXE/zlsF9Gvr3EvvPFASpJeZ1CADhI3IZdPqkebKuZsv5HPuMxzo0aim0IVwr
iusQoERFwXrfg0zHBRTU5IPIxozhpGY8cB4CkC6mg0NGSYDiVpCFsHkVgLY8iAbeRZ+iSJ8W
a3CiKhFXlShSjDxJOeVZ0wT+gpVNirOWNgWXsrYBsYwK3AsSqMA9ISUt8GJsqlVRSquipFZF
aa2KNmtVlNKqaE2rojWtita1KkppVbRRq6IcrYrytSp6QauiSKuKzBXrxotaFcVaNcJs9wSL
Qbtz9e6GZk7a7CA9eNe/gpbWOTCreVCBbkZruhm9pJtZMVnhad3MATZ/excscfPM3wuCkdLN
iOpkXvwPewudjGKdzDFGUeKav8e8Kr70hyZ/R/nnkzTCtVm8H6cMNaunxYxm9fMl2QTF2h2V
0O4ood1RQrujlHZHktod8NXoPsOIk9rcdJNZL53FK+KrpBD8CFPi0OSdE4YzO8KbLZlSX+AF
3BkmqU38aBkYNHyI/blu4ARFpixJdw8SPgBPUxJGVwQ/baTqmN15sJRIG0kfow4SJbbZWmHl
GXOFMRDDIpCE/RJDswYMK1qzYFJcvYhrnkkjSiJ1ziAZoyZmKWZIYApDh8GSlg4j5BMpSmlV
IpulJk9OzKaeFWasIAHOmkGMnE3+Op5owLpRxKjYymIYaQtJQMRA8qry1yCnuWFXKcxMMbGq
qin/MM8nzaw4zxorOrOhhpQVJiCiq2k7jHFcX/8CkQ3HpsYz2uw+Yacn0gHmjQX7RDl1l2FD
uDapxIsNF4rQvQHJ1Gl8Xf/u4quvQdzD4+xb8vgOHuffwOPbGnmQ0otvyQMKEKor5JhFvJbg
vNaXdkiZLXTj3nJwwwLpuj+XETDgjpg1Y7RnzXwdIhf6uqPfJWzP71Km5x4cOHvqyAZDm3nf
Dl0RE4YHrQok5kH5m4euIJbue68lrSj2P+M5OuaAnQC5djjmkeY7XA1UvO6dPVWch5pfyvwg
4045H3RIyHP/IyKsh0ONea5ts/9dJao5yPwK9gea5OCQci04uFATdt+BWB9iUqmZeLAxJ8wP
2OzIDD4Q++QqR99nTo4AzDeqc23nEg4EVkas6VK3irE1i7a0Znd1n25v8lPq97/Sd8ryp5CU
9c8ggNHgwwNJCisxQmv30hKhm1LY5NgvSeFJU7ATe1kidlovi82O52Wx2QG2LDY7hZfFzj9+
y8weNG0X8uRBWpIscYaWGcukUImFjdLyMRMrNtvM5ZlR+QE6TgEciHOTIMQrejTugfAiNYOw
PERAPlJIxBaPDx0MCagWxW/1esWRXIWxxtDSVAQaHQzeqYMG5ef1rLg/hZFp/1lQvm/Q/p7Y
yte17+A6YPzrWLsdDVud8Rh8zs0RXDdMOq3Ju1Hn8pNPPoHVA0+F4XHWBM4XU/AckGJa/tt4
0ulrrWH/FgbgqtfRYGQ6/aveb9qg2afMYtWjvmfqWR0/ByFekEmEfTCzMa+rV8SsV54ba3pM
H40LaQ8tP/Uh7tKV2ECgHd9GrNg2oWLxdVN81aRk7ply7pheul9K3i1tvleCuqsAx60CHNV4
4RJjdo8CAETWmxQApX/Lo5IEb0MSFE74jju+EKFwxxci0I0er0sje/nBtwhNj3DgLn0DZ8Nw
ztW6ev5d7UKt7XoNgnauf9eDK43blZhkHsB7jEFMiYs6WT8DCOj0RVs5rwNURsZChE9JDOSH
jKMqbFxxOFKpWKlSSKVipUohVSFSVYjUsYVIFW616SuJeoKO8AihKJNVn93oqle3qZfhgOED
p/0OGNkN8DjcdC7JQ0lCJ51fJ5dqiFchA487dBE2uoPu5CuTwWAFNkada5HptmhmJ18uoR60
Rp1+ZzBp9hqDIYP5cKmgB5hlBsN257r5rjfpda8Y5P2v7G3i2fIukSSz1jAev5pbq6X3lWfq
oc5KH9moNs5VXqkbZEDzpUMv4D3dhK9TNL6h0Oj35FjGM2fkcxQwsAEfp0mz9XOjtvq6Bv++
qq3q8OLtob8aynksZwE9QzQcPQTwV7B0ECuaQS8bhC4mhNXgPzeuV+x3Szsk98MFLdpCRwNZ
GWe3cOJJUvi4dB1rDvWyZKxMnoI41reg8raiYg52GULmZJehYI52GQrm0ZahYA53GYp8p7vs
DEMzd2WRdL5vQZpwwMuOcdIJH5Pm/8Y1MTOnhAEjvqI34sNH6LDtPv1MvO/liZ3QDR58x5aj
utclCZ4WFgBimlgPZmhi/xGlI06k6Xtz3jP9rWkTElCuzU4IlgwR3HJkT+YCfrtfjmYU2tBG
ORpVJT9P9j3L6suV9pAc4+RxhPyOfipgUq4q0FxLz+Q0aP28J2N1MaTswU/uMCxOgNtbQrsd
elGuJYTyLSGUYwmhpCWEhCW0h1vtjCWEkpYQWreExEW4sITQi5YQWreEUNYSQrmWEEpaQmjd
EkIbLSGUsIRQxtxBm20jFFlCN0HKEqJFu6xeQr8FqY+3JuUXs+V2bI5OKE8c6QQ5qntdkoDp
BDmadZmMQMyV0KxylUTTIUklhGTpy1/4ps7ruPxlDZX+ElKZQYDPxoCtdvib/R3u80UzZW+/
qwutUhdaZb4tVV1ovaELLZjwt3ShdZwXSjDIr/FCKb7WkejOB7/WgcZV1zrVtU51rXP4ax3Y
am/0Wmev1iIzWN+szci6l7sI0iiV4fiGDEc2pa/UbNwiNFL0+SgCp/gHFEvPCbcyD/P1w127
wq3M0p0RXyt84duEWRuz/rKNWc+xMSlYZu0Xfx2w1McISyGV+hhhKaTkfijGrr5vuNv3DSN7
tJ60R+t59mg9zx497q8k7uHriFbR1xE54NosvS2nmz6cyCZ20weZXsPnFlOd5x/fW4PlhIaW
H7mkDVt8XcjwXrwsrMKm/qdhU8nLwsJAqtJhU4+y65fwkCUXJ5jd6KtwkqMMJ5G5uixZiVSk
Rplbl0LRS7hUkRpbCN8qUmO3SI2yq5fQb0Hq461Jq0iN/yxSA6Zjx0iN4iAFB+/pL5sdKDrB
wdK/lP9il8nfYTJcZ27dHW9cimjjfv3mMJZv0mNe8NepKh/5Nj7yk7Z2c9u7/UWDYRl/c4wu
cwe/+hALujoN2cCzI3OTQyfegH8cWn50jnFoxxvyiFc+7g/v405L9crtHbu9izfd9JV4rolO
MeKkFq6SOT+Vcy0zmWWyivu7I05x/F3GOH3toXeiJ8cVdSfa9cED7qowuT2GyWl9aPwHj5Jr
346bt6K4vmPs3IeJlhNb5PUGyok+8GC5JIBKYCHAc9zdJUdClBPStLe7tEyvHN1vxNHtrAzq
a2G5BfbvcEP1STVs8Eq6w1Hs8A4DHdY15l14dvSFZRC3+Lo7HFZX4NpJfzjBiljWki7yhW45
rdEE/gq5Hy49WlJymYpyOS+1bj7CBj1Dco5W9ovwslSL4BGUqgaIMIhnUTtfuqgDdEEq6w2O
HdVyZGtO5ITxWOhgDe6XIfgjHDB+jtfDmmikrPNFmM4J2zjL9rUbx4muHJd1nGhYZR5X5nFl
HifN45J75FXYx4lOcAM5BUnIYiZMcq3ksgOSQMjayeXlOzeU8/8eXGU+V+bzhzSfC1dvAqEy
oHc1oGHwdU8y4sNzn3zPd+dyVGljfV0ClnBss7JsNFypS74qArmKQJaMQL4JCiOQy6xVQlae
wseyFFAmRwGuui2I/G2I4Pi5BRUzlN58xHQpmi0/gOeYVrBljPPhvln3okPmSbdCx/WwYwLQ
cgKQxzZ+xND/4/XPbG6znLuGu2cKub52b41kzz6Y80ayncUemFJumlJIlS+n8uUcoy9Hcsu8
CtfO5j5xT89mhFwvz5ZDtRk/6wPaWolUd6eV8+cInD+yy3YzfuUa4jTG/G5x58s2MmW6/wtQ
SwMEFAAAAAgAWWFUQpk0Cm2nEQAAUJQAABQAAABidWlsZGNoa193eHBfeDg2LmxvZ+0da3Pi
NvB7Z/ofPPelr8Ng5y6XYyadEnBSegQywDVpS8djbJG4MbZrm4T013f1sGVjwBaPXpLSSY21
2tVztVrtrnVnn9udVl3S5sbUdm33VjLro7tbVbLsAJmRFzxJUYCQNPECaWI7KJQiTzK9qQ/v
8tdfeYYZSLb7YDi2ZURICjwvqs9Pjs27e6lqzCLPdJDh/j1DM/T1V8qPZzPbsXAlt8hFARBY
tFAogtU7miPXN23p+/R/mPQbd2rcIxnNkVR1Pce79STS9MvBxekg8nxZqtgUol81BoNT/KhJ
3V6n3f10qkgk2et2foP3y8YnrdXu632t0xi2f9X0YU8/awww7PQbXFdccF26CjwThSE0Odu+
r79SS3bmYWzpoRnavhdEi71S/8Neqat7lW9oFl3vDvVho3+hDfVftf6g3etKA20oDXvSdbt7
cwUjJoYM/OM/SXQgZdudZ4d25I3/AvbRH+e+Dpw0so/gkSBPoGmsANrmpIB8L5aWlFBNSFMU
Mme4QNuIbJnAwsiY+oAgVSZCTZMqhgRgqWJJ30uVe0mRP0qVB6kmK4oMD9zyfH1qpr7NepKt
mNeIezOghd+K9eSPX1EQ2p77pxSCFIAX6dGO7qRWYD+gAPJOa2pVrcGfcvQ21b+ktg37sWm1
5Zaii573CnSR6MKLlwIlTi8FAlk+3gnyRJAjiwvMM2KeNcQK3IwjlB+bZIvC1X3b9QZPrvld
XK9jj52JFcrHozAwR3gKHKTDbqfDFqc/2q7lPYb6PQpc5Gy4C8U5VTJ4uEjrfvThuAZNOz46
eS/XRmPbHeGC8MjLFposMpjCGKyYqZZvVhv0FU9RftCyUmM3q6d85wpXDLQJD4F4b+sSXVdX
jeHPkh1KslyFP5iWquBuJrpcp45UDY0JCtGdVDXhz5tMpGpzzpmmTZYA/Mr4f3kEytbUc0e2
azozCy2DjfzZ2LFNksUHAXIxqFDsA06zPrq23VbrU4ZLcQEjw7e3RADm3xLh0ZqM7qfwgA11
PaYJOlb196kED2hVS785OdZPFXjDHYUXeBsMW3qz0enAa7PXbbWHME36z41uC1jyguDCLH6+
gjf62u4Ohqc1eIc5PFJPlRp+h5lWbnRIsIzukFDqBEengNq89r6m0HxgB5bmWG0Ng45rRxL8
x4rXO1qjq0Nj9Et4gTJxTkv7tUOKb51d0Gp0ynON5s/trqbrp3Q4IOf8qndaA5pzr3DaR5Ef
6Gg6c2C3lCFfygGNcErUoRXjfQYyDBeGjwDkYTrST+IrcWnbTEcOQp8smEYYoukYC6X6iiaq
GzWRjkxB7Ze2GXihN4mkb/vfSUdqZWxHUrPa/OEHqedH9tT+B8sjKjZRILG9SlKg8pp8VPug
fpTV2gdyeDqpQflUyPpPgX17B2U2v5OSGqCUAFQkA+9xsiQ1HEciWKEUgLAIHpCFldM9tEjZ
qkXqj6aD+e1N4bBW32BswG3iXybn2CspaJlow/A1Ig9n58UeAZcRfRivULrtCAmk3I6Q0uKw
GBtEIsxxPEu7WZ90KrmAZSmchRMKn2Uub1kyL3Njissh/f2swxsgx5KY5XN+SctlliXHv4yR
uLBmaS6wE8wq/MEAVTlFd5jUtZtxYkXntwVcTVmmYvvHBoSLG00xLfDfjpAo2y3wyKptjmHi
IaOIbNdLcjgTKWuYKGEZXsjZBX1fvWvi3HjnTMrg3LWUmVod3jTOWTFvtrSzzxcsl3PVCkYg
RJUWVZG7ny/PYKYZEBPrn7R+V+vQpidlcn7go3XV15qNoaZDl/Tzz90mHp4BqznPCozsctDU
u73eFV56K2cnWXOtVjtWbFntNZUsqHi+YlwmgH8364/mnRHoUSVG4vPxuwOwtfOiJPPCKPwT
+nLxxH6nFTpS5jiMAlicFHz9DmjLDErSe1bcPwBf11OKdudFvhGZdzSl/RxWTNY9E36y3WYF
9yssx2GAc5rmPRpgAO/Z7zZLT1kRPQsDeE9p9vUNy8Xocc9JTxj8qZIqL9f2c6twhxwBXdJL
xgifLlvn+mXjl14/GSOF1dvP4rS7KZyPDOd8ZTH6YNjHa7kWFzdYLC2PWmNb4KP1LpFwv3/g
MBXeFTKAFBY9+ciynQqD2mwkCgTq6NEIsHFcvsN0fGDl2GZmJq/6xPLSST+bRHNsByMQ9AAz
4ZLXWzeKxk6MN56F5HWKpmB/T1Nb6ME2kW67EQomholSFLm8NN0d6G0hnOfTMMIIbPPK1DG+
9YHFcBvj4aS/y+RRuYksmkAlO4F84rITJj5R8sjAC8YgliMdnBS3LrL0SYBgdFZkTg3H8cxc
tmmEOZi1DAgNCdAUuXSOcVWOHUYwOw6KUBZ2iyLdcME6ihaQXfSYBfier/uz8C4LBbcKYw/i
YGF1cAAuh6dy6ORJ0liijGeTCQpoGYvQuKXQhmghK6mDg1IVhYt9D3Md51A4493zZFIw2CLN
e1YGB2SzyeDgUeIg2grGxKu5AC/jeA1jzDUswfM5T+SBVgJdyhU0a4EtOHBxeHhOPCYUkuOM
LJh2nsIyvMEhuCzWfS63eHa+BPLMUPgxRY5/ODjPQIt5vCFpEZlDSzcozVaUlMlSnpsfxAvq
GqDHYwvJ9KwQS96MzRjycDrNlkmaz0HMmLwVTHbzXI6cZVOKzuQ7z6d9XNfclfuAkKUGd0mq
wuFGqnqzqM6Nn2TPT049BKF9AVJbq79TPp68fQd6EDyOPuDHR3gcv4fHhxp+4NyTD/gBGaqq
SFg9wVZNMG8bMycihU0N8852Ud2G5uzMWAT0sb1m5VaIM3N7Yd6e0rHHgQEu70vDNW5T5pOP
GevJtjaTTQzWy3q+anOj9rw910OF4j5rAkG6z+KtPZefiPxdV5LdPHY+2Uu2of11AeTj3sqO
t8a9VUCk9a5LJ9vsnqaWlL2PMScF73M88HPnw8GViz2N91IFaOeLideyj6nlpe9nfsM9irJw
33KMa4j7KXkP80kUzX2NNy57f42Otef9lJ7mbvXHpUaSJINbSSgwr6wLuSUX9PFiqxzNwgp6
GX8mV5A3VHe3c1qqP25+iCDU1zfkN3OWIJDMeYJCAKPORgdeCax4gBZc4eVD5USQ8QFbjMAX
JaAn55I09MhcEpkek0si01NYSWR6CC6JvPz4KzBp0K4tqNPHRzGqlBwRGMW0oCFUVKoEiIoa
hy7f0mUReQE7oQQoEExXng74CovbDogpXC+I1X1Ea6sSjgpjsZTdHgbV4hixTqc4Wqxs3HZi
5iFjwTq114jtZT0r7k9h9Fu6oXsOWwtM0uOKI72rfQTX5OBmoF/1e01tMACbfqMPvruh1hx+
7munb968Af6Bp0TxWNkYziJ9w6cQZ5P83wZD7VJv9i6vYAjOOpoOY6NdnnV+07uNS1JYstnI
13QrlwdPYYSmeBphHYwdxOrqFBXWKV8abXpCHw8Mbg/JrwYQ3eltEOUM++LrCEzbJC4t8Z0n
bnIp5/te4vde58pNu3FXu26h7h0HU6bn+2VGVeJYSTlhS2wM3eEyB1H7Kpf5+o3ysLpfyer+
n4RKywnfmvnDIVs45L2PQm8WmCgfWHosK/Lxx9qJXNv+mFj6vIzDeMuL4iSeV9m6h9v5fZ5f
PHESvVt+NL9kGG+6ba8nnhdW4ppwWpEw2nTQ7GKkbInA2HQc7LrQ1XxU6oqA07UxnzzMc/Nw
zVQ4Zib6Uiyqcn0E5WKoZGE45PIISAZwxGMZSfY/K4MPkyDD+OWc/Q7i2L84hJD92rngwDgc
sPxKG5UK4hMN3uNBe9lgPfEgPcBPdFtTwmma2ChQQsgmC1pvNs6hlIXWvV++RbVjJ7LhEEvF
HmMSqpcaKPB1sFpcaKf4IaWhQ+1meCpHaB5R8EAj66Pe7raHby0Kg8VR72vnPNFuksRW9l9M
3W32tUutO2x06t0ehQXgwDBCRBPdXks7b3zuDDvtMwq5vqG/FhrPblOvmKPq5sPbiT2f+W99
uLPAoLkPdFTrxzKr1AtzoMnMJa5937DgroT6ewKNv+ajCd8a48sRYGBDNk7DRvNTvTZ/V4P/
3tbmCvyw9pBPWOk7CaoArBNQ7MNoNq4v/24Ub48jYJwRxnmvqDLUxRoxG4fkgFN3jQjKfQvY
rNVjGKY6rjipGdgpeKqfz+lHtBpO/XRCssRZHahKGNi5HVGMIEBla1gw4ZekolnCBNiUL07k
b0JETfoCdNSsL0BATfsCBNSMLkBATfwCBMvN/IITC23csoS0uV+cMmXyFxzdtNk/oVwvESjt
GfHT9x6gs473+Anb+0vTupEX3geuI0R0Z4jhP05tSCckyTacI0kOsoQOn2ZH19akYwUb06aE
nVCT3Qj0MSzjhagerSncVyBE0o8caKAQiSzjv0fnjiaN2Vy/T49v5kAF8Z2Z8E6hmmCDm/kW
IRE6qXMFSkC3pDh5TUro0J+oVOrmKtW2h+tlKpW6XKVSl6hUalqlUrlKtQOXek6lUtMqlbqo
UnEvPFep1LUqlbqoUql5lUpdqlKpaZVKXVSp1JUqlZpSqdSc2qNuq2Spq5UsNVapLsKMSkWy
tmB+TC5OGaBNKZmHuZRAWLLVlKaNtxohojtDDJ9uNUIki6JeBQFavFULVRFPgxgRF75l/ddw
sQyoPM/ee02bKeiOVgpHAC4P2n9IwhaBCNC+nXvV6VC+Sqcb55RVy5BjHFxwr8QFx6f0f+OJ
S3OxKRzQs61va1tlt/SZAHvvys7zM76LJ/Gdle3Ll/ac0Za9Hr/ZBvfgHLxsBy/bM/Oy0VUp
5mM7VdZcs/FyPHOs78xBl4XtOB4NNO5XqRqvv0H1oAxvogxXWvrFVefqVx2GZfD+OerGLnrp
MaeEOc0vH5IlEAuA1dbCKWD66nO8qTG5A7CwE9U3/A4/fvMev2lvhaKqrFdUlSWKKgGXYe3i
C+eAe3eEVOp+u1JI+Uvw+EV329xtt/6WutzFdOXvosvdL7fq/rh198UtXAjHL34TufBNWbxo
j9+rt0znVFbdl7cgzcVvhlOK777L3/vGAE5yzVtyvRu/1i1/nRu/vm3xtjZ+BxvD6Mcv5+x3
wKqy4+vO2G+cfqpkEc6twjU3egn3e7G9xExe9WieTgWZlGdb6SSVVOyOqLgkIVsG92+W1urT
5tpiHyfFO3g4Dx7OZ+HhPJ+X8nCKsD8uQpCa2/q3In/N/k7R8BgIrdmYNsUSQk3+L/ytAq5T
/C+pmJ47sW+fr9+Ut1HYaZpsj4JbHD735Gp/4bZ63pFnZajnzfrSVvqDtXyH1nK40P5U8KLv
PRjLW1eDxhXPVrY0oX8ZozlfIWIW82dk++ZdYIbvNCAlqIM5TfKjS5LmZxdBWc6PK+XGk2fj
rS97Uim7KxyOKa/kmOLOTeKtoKkpCm5RXQ5wNXTwSh5m1OS4EoUGLA7EuvDkwr9AauJDzeJZ
BJgr9Jz0YQRjxUXW0ueTqWG7zf4Q/q25IJr5JKccl/JsoWOBYT3AGj9ShZRS+k2AINE0fIBN
WQe8ObkArUhTB2ROKBhwmCjmQlQpXXvpBcZi5nYuqooNVTQrb0wpY7Bn4qnwdBDezSJwTbgg
dJ/v8SDVyMO3hP/TbwnTZqH9f10YB74XfktYYu1iqtIEARIkgCwhAjgpi9MEG9CAZidORNW/
V/11WBmSzb7Oci07+fxJxOa0xy+qBEw5Avo+tt3kt4YXbrxJ9eRZWW9S7TqYbw7mm4P5JmW+
KbdEXoT9JtUHZsDJQAq/T3o07Mj1fORaALTdENRxBz0g2Mme7zdLq9ss+JmCwAEQ712F1b/w
GCyxjn2xuCyxZhbHRZUKwyqFdIiw2mGEFdnohAOsdh1NtbjRbRlj9WWiqsRWzIuItFrdJRZA
tRph21u3BEdzNXrei7HpHnO4seuVWNlSXg1lmVejpC1OTaxt3KuhLHo1lDVeDSXv1VCWezVI
zmZcuxpdyJIUez2EDB7U6yFItMTroYh7PcrVZU5up7eBYAN3djFOwdEonZ+XYqWtPAdn7MEZ
+wycsaEAsx/csZu6Y2HQDV8sXtL3HgM/8CZCRBkZ+C9QSwMEFAAAAAgAgWFUQl/ZAizeEQAA
5M8AABYAAABidWlsZGZyZV93bGhfYW1kNjQubG9n7R1rc+I28Htn+h88/dLXxYAvzfXopFMC
JKUHJANc79rS8RhbEDfGprZJSH99Vw9bNoZYAtwjqTtXbEm7q/e+tHIu3ne6rbrSXhlz27Xd
mWLWx7czTbFsH5mh5z8qoY+QMvV8ZWo7KFBCTzG9+QLe1c8/8wzTV2z33nBsywiR4nteWDfm
1tnp1EdKxViGnukgw/17iZbo889qP14sbcfC1cyQi3xAsShZIMJqHq+QuzBt5Zvkfxj1S3du
3CEVrYCw6znezFNI43vDq/Nh6C1U5cSmOfpNYzg8xz9VpX/d7fTfndcUkrzud3+D917jXbvV
GeiDdrcx6vza1kfX+kVjiPPOv8R1RYTryo3vmSgIoMnp9n3+mSbYmfuJpQdmYC88P1zvlfYf
9krb3qtsQzE4zPPiUaEFqu2utoCOvclfMNv6g3Ork6kf098YcQojyojRsUsSoznbaMTwU9Kg
GhlfTMo2QlsFupk8AheExnwBSMrJdOdGKyeG0ui1zk6VE0v5Rjm5V6pqrabCD1SbqkK2K+uU
75Sa+jZZAe7DkNKf7d7+P35FfmB77p9KADsZXpQHO7xVWr59j3woO69qFa0K/2qvXyW6Ftcs
3a3dKpTaRsCQnsc2Yg0VZ3kuCo+a5blIiCdAv8WWJxCT3rvCxNM7THRriZPfbaVHTJCOZnL0
SM7WimP46SaGt86NZGk+NVacGUhT3XWImkS3wDV+1feGj675dVS1Y0+cqRWoZ+PAN8d4eTpI
BzVFB91Ef7Bdy3sI9Dvku8jZcSdFJRUyiJikdTd+c1aFpp29/v47tTqe2O4YE8IzoFpour75
amzz7bvhJPqKV3R20NLM+zD8UrxzuTwS2oSHQL63dWXUGFy1RzeN0c+KHSiqWoF/MC0Vsg+a
9fEH22213qWn7cJ22QrFCiv5MR3lJ/nqty1801H9YIGb0LNN3wu8aah8NfhaaVaa336rXC9C
e27/g4eAzhTyFbY9lNp3KjT0dfWN9lbVqm+Ior06O6VbYfHo27NbINX8WuGEm4RPGXhTqYrS
cByFQAWKjwLk3yOLMtK5A3u6YiqV5oqv7A5tL7yo+H91DLr83HPHtms6SwttyhsvlhPHNkkR
HysoxVkiOgKAbZ4XTGNsLOw9AWCX7gnwYE3Hd3P4AUXsaUgTlA+l8ju0qKV/6PTPTvELYZ86
vFE+qsBb87rf6ow6133950a/Bbvm6rwG2f2R/v4G3uhrpz8cnVfhHSi91s5rVfyu90e1jzok
WEF/RDB1AqPTjOqqehaV/9oesDSH6rRx1hvIIo2hmd12o69DY/QevBCarYsrqB6/tH/t0lp0
unEbzZ87/baun9NxAJhLT2Sqx7ePC+SbhuOoAKCs5xnBnGx7B9P74mDbr/IFpgo0m/TZG9Hn
e52+xcueJdToyV8q8A/mt8IyDtY0TC93eR8ICJb5gYBMqrnGixwn+EJnKZLA71uWOy6KlnyU
4quepPnKJ+l49UcZfAfQVHYXUDi+E3heZjfQ7G3bAZexnUAT23dD1JVW++L9VdyvVqujQwuG
MAisFdW4FyZ9/G7WH8xbw9fDE5bhsOfie/py9UieJ+YkCH1YbjT3w0f2PE2n2z8HJ+YJwxxE
L5fsOWS039Dn9SpgBd2ogI+H/q496Le7tL8s+12vdan3Gr9cD6J+6cPRAE9ttZYC6fQ3gFTf
UpgQNr9lO6xxD9bpWfU1f9dYGy5zFv/4wfCxd0q9JfDq2MADZBDFUgfn08xFlg7bD6nmlsI5
8B/PzBSbRpDJszZlQkN8NEduSEpwVY4dhLqFHBSidN4MhbrhgkGB1oBd9JDOWHgLfbEMbtO5
4CzzH0kWcZuxOngGpsNTGXDyS9J4BU2W0ynyKY313Kil0IZwrSiug2clKgrW+x5kOs5zQS+9
48mYMJgs5h2jwTPSxWRw8CjxrLgVeCFsXwVEA2oEAZpPsF5c3yyKtB01RioD85RB7XDKoLan
MsgkrkjzsTDVmDDVuOhkCUJtk5aI85/QHnFxVoMk2YJaJICKCMmDAIGQPBBQUrPMhyZyV0vK
XS0hd1mKJOB9u9zVUnJXW5O72prc1dblrpaSu9pWuattkLvaZrmrPSF3taTc1Z6UuxqXuxFo
qwt42ZKTFjVe++97F9C8GsvMijrtKelNi/EqTUtvluHAM5LeGpPeWkp6a0Rqs+dHeMZSm2EM
opdL9hwymniVUqnNCrrpgktLZNOwbZuV5XzkszL8HK/UfA1AE9AAtJQGoCU0AC2hAWiSGgDA
q5Hj2Yxf9anlJZOLdBKtsHOP5KD70Lx1yevMDcOJE8FNllTwz9EcTr6S2Ba6t00EWkCI/Klh
ogRGpiyJdwvMOACHTKphBlTPzIZUHZPZApYNbiPuY9RBLOi2azS0PKPSUAJ8WDgQ13Hi3KyS
Q4vWtJwU1UVEdZPaw0sikR/h8qlgQBldiGdzZYhi02mj5SnNiOeQqngyiU1neq1wyZAzmhLF
oRPMQbJq03oZ7ytdQ+vluNIoN8iM7ZbFxsCzo8zbuBmHOwZVausmNbI4zdu8tmgpTFJRi8Cy
65iD8jlY1+E4Ll/rHDAaGklHHu6MUgGtQql4y7DOHYIUMNY3CETnCjhVu35ae/v9q1Pg8PDz
+g3+eQs/Z9/Bz5sq/sGl37/BP1CgabVXp7UqyYMfrRb/vP5OwXwdu9fAGWwsnZDUMjfMW9tF
9CAc2haas0M6G4HEZm9j1574BpzY9wzXmCXUyrcprXJf1+IubtstXdlqxhHvUfFVURZacGXA
aQuuwSq+ilgyFFBPWswUMfcbZFShHQEOWCT5SFQWWQdhxgVUQIRucTNNyBc0/oR2wQODf4sY
F66BFDf2GzWkIvYZr6igmeYVFDbdQbEcL/gP2B1XJgsjXsz0EnWzwLHH5AtteqRSF1YBX/WS
TtI1bVzIR0FLsYIu6GCNFWBtRwV4X3dqAXYEIfvhI3mmzAmSkzYpSBYxK+gbANfZIMIryRMa
x9RhrVS4nyQ89kFI4yx2wKGeBXE06lIQhydOBLnhAuNcHJ46DcThtzgMpAhAA/cjkHQZSCMm
nAhy45ryInBO5SMjxGcrDmUFMuQIBwJxqQAUxKxJoaIVsce7wP5w7cBviwhn1xQcf8UiOvvX
OKsaRWN1u/lxWblRntDSVDwZGQ7WqUJD2jf1LL8/uXFmvKEsosE3SbtOHOW0+hYOBIYfh/rN
4LrZHg7Bhd0YwInDqN0cvR+0z7/44gty1AJPhUHS2DNcwqY9eAxwMSn/bThq9/Tmde8GmnrR
bevQh3bvovub3m/0CLlYzKgfqCxWh49BiOZ4uGHVThzE6urmEeuKU6NNj/FjJz8UkvKKD/GO
ntRiB1n4AuKfxOKe2KFSfNTEczJnTBvOl7aeLeGmlQF4OwbgqfFCxC7lg25qYBgvclNL3B0p
d/cx7m6BCdxzF+cC5O7iXACyeeN1ZmZPMNiiJ+8DFHhL30TZMJkztaaeva1+r1b3P8uQtm1l
zVrgJmsnQqJWrnvHrNy9B2lfe1dikHCUlNSq3Ro734mOHAyHqKAFHmhVem2QAXVQR6/a5/hH
SeaO2h9H52qIViHNHrabmPfVO/3O6JVF865vRvVB+5InOk2SKMZVgMn2m4N2r90fNbr1/jXN
88GjZQSIJvrXrfZl43131O1c0JwPH+nTQpPlLPGKAzTq5v2rqb1aLl4t4CKvQUvv6XDXYSnR
DC9Yz9q8MDAfG8M8R34GL8RmHj+vqEyXLjlXWhjW3AZqNHdhTfDVYpiagI30qNF8V6+uTqvw
36vqqgYP1nByj4i+B8tJQIRk3TVCyH51pkZgExiOOsGLcmA9+Y/1yxW9iNTGKVKw074GRDFP
C7cSpXF8JFFPyqMjjkZLd8HBnp2d8BY74lEPjxwq9fLI4RBPj/wwgjNFDod6fORwtnh9pIlA
Y/cnkvT+7ISc8ADJj/e6F0icKV2Q853re+i24z28w84fcWQ39II733XksG4NSYSHuQ0ZQjjM
gKKI2Iwaf7CmXcvfHTnBIYWIJAYH4gYCY4rk0B6sOVwVlcMZhM49EutjjKOq+B9PG8uVfpcc
5qQeTm58EsMnyovBEkyzrvSGna6iwuXXuWct4XYu+P/oW/SxDIvcf8VxnOAcXLrWD1gDCQ2f
OSvdO1beHTWvflAMy6Kv+HMb4S2iENhwAIccTiBcYIOs9O5pIQhDYP3gdwQIEx1R8Hmp1pVq
XanWlWpdqdZp+fWUal2p1uVrZqVaV5haF1+Vk/Jhfdo7cwINzL96JnQvTghI6F6cEFB5Ha68
DrfDdTiB/TB+JjfcoCvsNliUwJzsin5IjIQ6QKSYpIeeH2PIDRkF23CeIevw5wcbu5uG+9mk
2kbTUNtsGmobTEMtaRpq3DQsMjgwYxpqSdNQWzcNeTwhNw21J01Dbd001LKmoSYmjNdMQ22j
aaitm4baVtNQS5iGWsb+07Ybi1pkGl4FCcWHFOy3BTCFnZB9tAcylIpPwgZVWBw5UoXlsG4N
SQSqCsvhrCuiGqh220wKquSxUrlqoimJsegcPBeHX8lMS2ZaMtOSmeY27dMw04wOW/vxEj5A
HtwC45xl9NutZcLRygf9cnCR0cr8y8FCHYMvkYKLr/jw8j2Cynkzy2hNiWhNsc8Rl9GaRxut
CRP4sqI1n3sgIkyIWCDigXkUZX4vllPR7m0Z1TRQya6Oll3RCXq2zGqHGyTJZWkeUcRMfAYl
xb6O4AwKGlieQZVnUOUZlNB+eN5nUPtqgvvG9u2lCVKun68HHkwg7NtbJhAkesG/if/kF/Cz
4qD2tDiobRAHJFtOocj/Br3QJ++FgIQ+eS8ElFQy8qHLr+jLfkWfio5sSVZ01DaJjv/kW/w7
fYPfznyDP11waUnsnfG2D/TTCdj2Ud/n8Fn/VPfZR97X8iTdADzaQU44i0c7AKEy2qE8oHuG
B3TiWwBT2AnZR3sglwd0/+EBHUxJGe1QMtOSmZbMtGSmh2ama9EOkg4MrsPKWAnJsycBPZYC
5mqx5XVOYcZbXuekjDd7ZzP3gqfgdc78dbu+CQgVeQL8+HJfCuVltiO9zCYnCNbcEseqJpfc
uuTWJbfenULJrV8Itz5YuHF+VC6w/6MOx4X25UZNm8D6Tc+d2rPjDZjmbTx0yB6M0IsM1oN+
bWF7rLQMzxMPzztp6Vc33ZtfdRiO4dl/Ga3nohcQUwydeH5fgMWRJCLzcHwhJFJnpribGSab
31UWpCIyQJ82OgXa9aLCUspAk08RaJIWAC8j9gR2hnTQyXGFj2C5YsaverhKpvxUyrOtZJKy
FBZ0wigdc1h4Lmv+hBHhuW3LD7wWivMWAipDuPcK4dZ70OKDR3C3boaNG15c2y2uu+hI7tx1
/CyCuHkvWCB3IoOIpJhZ7h9elz9iHAIb7GunkhKKZxlYJ+/kfqGxIHPkz1Bd9XEL6IDnxIh8
z5zfWhwFEgYGbBvEevfoGnPbxE7w9RgRWJOB5ySDRDAU86en40bmhu02B6MhPt9ZLkiJ8OLm
EHKBG4Z1DxzgtSYXr0C/0imGBdKUYc2De0iI4DwVgMF7eqyHaCV/KflLyV+eK3+5kjvdSViK
uackwe0yBGelC0bS8R6TJBopqdthN2CWSL4fkJvXR20/5/fpExrQ+Y3Lt3uFjGMhoNKCLi3o
HS3o/IX8LEzoRDeYDZ3KSbA9uuf3N6QFBi4BssGUlmHepS1d6rrPVNcVWN0JkJeu7QqhBQjG
0FhIXmpYeA8+GMnTGCsxrKXpXrKzkp2V7Ow5szNJR8E+up1QLF72ypZg8FF5V0ue+5XR/3tG
/6cuyZKCnRY8RpTB8ZE8DpTK4sDR6E5o/m5o4DrbCY/anv/rWwv7/rky17IDkVsGyT9VJ/sn
xp50Kj8Yduh6C+RakGm7ATBrB90j6M7x+pi3t5k7Ro7VRCiFZCkkSyFZCslSSEqgFS4k9/0j
d/jsMlc4PX2UecRHl9Jd+oQnmdJtzT+OFDqzFAIqDzbLg80dDzal1/WzOOfc3it27PkUQPpW
9V78m7vMdh7u7RgbDkv3kBbl2am8JVEeNhzFYYP8Yt+O8bKOIszpbD7zEzVt7/ixOjZKdlSy
o5IdiY3os2NHUoeV/wJQSwMEFAAAAAgAe2FUQhgqeOiVEAAAAJwAABQAAABidWlsZGZyZV93
bGhfeDg2LmxvZ+0daXPaRvR7Z/ofNPnSKxYgpz6YcaYYsEvD4QGSuC0djZAWrFpIqiRs3F/f
t4e0EhLWiiPBLh1X0u6+t/e+m83lx1a7UZWaC21m2qY9lfTq6G6qSIbpIT1wvCcp8BCSJo4n
TUwL+VLgSLozc+Fb/vabyvvLuWkZGG+KbORpATIYnGmzqkYLZLu6Kf0Y/w+jfmfPtHskowWS
SrZjOVNHIr3pDK4vBoHjytKRSXPUm9pgcIEfZanba7e6Hy4qEkn2uu3f4btT+9BstPpqv9mu
DVufmuqwp17WBjjv4jvcVlhxVbrxHB35Phsq79+33yiCg3kYG6qv+6breMHyqJQvOCpl9ajS
HcWTAAvnPkl0uLJpL5ITMHLGf088pD5ad+ri7GRkHsMjAp6QCipkPnA9phaYMsnzA23mAoB0
NClUoXSkSZAtHRnSj9LRvVSRz6WjB6ksVyoyPGB8rMN0JFGH02PLaojBhD0f0E5Oi/Xwz0/I
803H/kvy4TDAh/RoBndSwzMfkAdlF2WlpJThr3L8Nuy3+KEgQ4Ajhoew16cj3lG8LOltoCS2
wXrLFN8PSxshWr41a15vHUXpgY32mwxA/2CRcw8TLLDAXBYkAwVqXr3+/PiuWfO660+njE5h
fMpITnarEfCk4EnJr7DgARGocL15qbyvEwEAN/d91xk82foPYbuWObYmhi+fjHxPH+GNaCEV
ZAkVBAj10bQN59FX75FnI2tNkheWlMjk4SqN+9HpSRm6dnJ89rNcHo1Ne4QrwjMvG2iyfMwq
7JjlH61syrjGWPESpSctyYy2Q0PEB5dLN6BPeAqKj7YqDWv96+bwpjb8VTJ9SZZL8AfLUiL7
f2ZJJV+bIB/dSSUd/pzJRCrVF3xpW2SjwlvG/8sjEDhnjj0ybd2aGygrb+TOx5apkyLeVSjF
Wbk8H2Dq1dFn0240PiT2Eq5gpLnmhgCwRTcEeDQmo/sZPEBKeh5SB2Gi9MdMggf0qqHenp2o
FxX4wgOFD/gaDBtqvdZuw2e91220hq1eV/211m3AxrkmsN2h+vEGvuhnqzsYXpTh+3Ore6xc
VMr4W+0OK7cqJFhBd0gwVQKj0ozyonwSln9q9lmaQ7WaOOsUsuA/Vr3abta6KnRG7cAHqbNx
eQ3N44/mpzZtRaV7t1b/tdVtquoFnQ0oubrpEdgrJ3fVR4HrqWg2t4Cxy1AupTI1f0Y5pyX9
UvwYZLapW7Lnu+Qc1HwfzcaYIlRXNK3QpvNHQmvFfe2Yuuf4ziSQvu//IB0rR2MzkOql+k8/
ST03MGfmv/iQU1qEPIkxAKnyswz76Lh8qpzLSvmU6HtnZaifknv3yTOnd1Bn/QeJt1An3FfD
jEOWpJplSQTKlzw4294DMmRCPyy8Gm+2M3+lN7hKqLBO350hfX9U6RejHexTDt/8owR/cExK
LGM7vcKV5ZKILQEBqRAEUnayGXKpDzS84Y7hZIul8ByzBKdeLJmmYBQypGJhihMykubELExz
gsYBusMQPU3YKBwnbjwvReBo9ioKh8sYcaOJ1QQOl4ZELhxWo3n58ToaY6PRUqE3A5gQ1qNy
NCKdvv7Qq4/6neapwRHLsNjbPaMf10/sPaMQR/rYDzzYKzT78y17v0umr/+l7zsncLVAv6Op
5q/+kX7EIPrhxxV7D2C7hCQil86Fp/+PU4zFqUBv4bOPpyNSwqkAB27J9J0WHnD+M0IFXzv1
Q7Pfbbbp2mCstLwRQn/oNK7UTu23Xj9cDnUw7OPdWSYCu4hYAnCiFIO11+pmtFc+L1DRo/Hu
pHycjwAUhiMop4IIyntxMYdWHzy5yDCto3xcID2MN+QMdPSoedjUKd/RSjmxUeLERkkSG+VZ
YiOPNHxENKJFqZplTm1kqLCgSNZXFM40y3L0VLGu+ak8IysTRuOhGbIDUoKbskw/UA1koQAl
86YoUDUb9GW0BGyjx2SG67iqO/fvkrn/zJH3RLLga45YGzwD18NTKXDyJGlMQ8bzyQR5tI7l
3LCn0IdgqShqg2fFGvKXx+6nBs5zQeS658moYtDL9XtWB89IFpPJwbPEs6Je0D3CuY6yxHWU
Ja6jLHMdJcF1lGe4zurNhvHSPEnJ5knKMzxJifMk5VmepMR4ksJ5UojWaEMd6ZKjBlVdux87
l9DVCs3MIrPPcTZajIed5Gwsw2Jv94x+XD+x9wxDJDibQjgae98ysH/pm3M0JeJoDKIfflyx
94A1acI75E0K50285MrI5QAjCpnmJnyJ0oT/AtN7MR4kwjYijhAn9knKXJzoyqGZXY8+1Ynh
xJNuMokW2NJHctADLIVNPqd2EIytEG48p2RyhmbguYpjG+jB1BHQzAB5E01HMYxUWRzvDsRT
H2w18TyyE5g2kGhjPHU9qIWRgnCA+Lyupv+0PMUAaAV8WjgQ5whRbpol0KIlnpCo1Q1rzWIS
YQnnEiEuXwoGlOIcPJuzDopNl42WJ/gIz+FNsYXlRbSmpYw5GxRdSVqY4jE8O81kKDrdL8tw
uDPLefFe+Km5XbXZOHh6lq+pa4EqYgaSZSKmrtyaCfMrAON0nKtFad77kK/xfi5vbg7GsZLs
LsRLHwAOzOcmPSqmgeM+UnsmyMxSyZkHVW4cJBQvEqYJQOsaKFOz+q5yfvb2HZB7eByf4sc5
PE5+hsdpGT9w6dkpfkCBolQkTMKxPRHMv9rcCkhlM02/M21UNYG6bs2eA/jZppe2OfY0cJ93
NFubxpTr84RuvQXzynbGsUKioIaxHbdDKeEuWwJqucvqjR3XH9H1bTeS5BBbX+wM3rK7IQDl
2lndIXPbWQOEdG67dsIgd7S0pO5dzDmpeJfzgZ9bnw4uIexovjPFl60fJt7KLpaW176b9fV3
SMr8XdMxLsTtpuYdrCeR+nY137ju3XU6lGt3U3t8dyvvU+ohZGaL/ZkCcr6RgBZhiVnEVxhJ
rMqaEutm7h3l/fpSPcH+fEveCeGe5CQEfJoDEFU2O/BJ8vInaMktLB4yWAQYq/XFENyiCFRN
F8ShyrkgMFXOBYGpKisITDVxQeBsdbvAokG/NsCOq9DFsGIKdIFZjBORiLhIdQ9RMmLR4ytc
F6EXwMwkAIHoL3E8tCDqbhtIFW4XKOMuIr0VCYcxsRDIbg9nlcOgpnY7P7wpN6oVepoIyyJz
wQa102jvrJHljyc3XCsV7e3ppF9HlvSufA6W9cHtQL3p9+rNwQDMvbU+mPGHzfrwY7958ebN
G1hleEoMjgZw4Xy26P6Tj4tJ+e+DYbOj1nudG+joZbupwgiancv272q31iGVRSxB/kx5pjx4
8gM0w5MNu3VsIdZWO6+ytnhttOsRfmQOh0JSXvIgaNAR3+fAtF5FAFWxwCnmookcNzwn5bHJ
8Nas9tRA3YdgvnWC+eRoP2LBcYvHGgjGqzzWor8MOJzv/T7f8XV8mQedHN9ou+lpJwHb+OS7
j3xn7ukoHY93Ilfkk/PymVze1F2gbNz+psofCWgVX2Me2cp144JqMZC4pO9HSEmGpjLdOq3Q
FK9ZRFjcoWen1GkCta6C4HjdvMAPKZ47bN4OL+QALQKaPWjWMZmqtrqt4VuD5vVuhtV+84on
WnWS2EgFx9jder/ZaXaHtXa126N5HpiBNB/RRLfXaF7VPraH7dYlzfl8S98GGs+nsU8cRVDV
H95OzMXcfesaWqDR0gc6q9UTmTXq+KmsydwmDhJXM+DXq9WfSW742wKacI0x/rkqTKzP5mlY
q3+olhfvyvDf2/KiAi/WH/KzF1bHfOwTZlS1tQCy357IIdgYRlkleGEO7AbvqXq1oL+baeLU
L2ekqPhOBSwBEwXXxIoheEi0hSUjiCAWLSqMgI0hxZHcdZCoUaQAHjWMFECgxpECCNQQUQCB
GkkKIGQbSgouLPRxwxriBpPimDGjScHZjRtOIsxsto3FkRHgU9xL4qzoPcBgLefxA7aYCOPa
gePfe7ZVCOlOKwb/ODMhLYTCdA6ChxWP0Wdj0ja8tXFjxE6oDj4v4NfGJLoQ1qMxg58oFkLp
B9YDEhtfiCLL8MeT2nyh3sfnNy6u4p8ZpiNWdvOri02FLhZfLy52ld5EAfY8nH7jMPqseHmS
XUjsz48EB8l+S0BCQetCQKAKbCna/AsFGR/CiF9gGHH87BSLJ96vyGAYB4uiDRNAfsVM9Vu9
UGM9U32u62HpQo1l1bbAelKYtI5bSMeOlF1lfWV3UxaVpewq2cqukqHsKnFlV+HK7hb8zSll
V4kru8qysstd1FzZVZ5VdpVlZVdJK7tKprKrxJVdZVnZVVYqu0pM2VVSGq2yWv1VQmX32k8o
u6Rog72L0YtjemhdTOY9FRIKM5QAYdxQCSiEdKcVg6dKQCGUZSFcAdE2X4kq1ES4DARJ1NEK
V3aAZrn3blbaze06WV+1N0bgnp6DN+YFeGNgHQ/emK15Y9jNIuJz/ILu+RAYDb/L45mbO9JG
hkr+b/Uzf5RfaDfn33QhdFmHEJD4jR4VESPD4f6M9e/PoEQ4XZI2MlSyjAxf9haO7dy+QZo0
0/doJEuuDPGzMxK6AkPk1gp+IUX8ronkxRDF73yoJIwMOM0S24+voYLiq5Xr6PCy9kAS4iDc
vQDhji7VyxTt1oioi+9OfU8jY2j/npEEX5C7iY5lH51NtGevx9UUOwwCNz8dHFMHx9SXcUzR
c1bMLfUarrnhY2c+raW8jODGAsK2sAcIKhHxAC31RHgJ4wJvfm9YRQdv1MEbtQVv1NVCyBtV
ZPfiKgpic2VnI/T/q29qRYDa2rixLSFUx1Z8Y4dw8f9luHicZuUGkIce9Nxw8Vy2zXk/QS+O
6aF1Mf+vYbQrw1iLUQmRJsJlIEgi8U822u+wJ+hfbiAA/hdXdMeemNP9jQLgfYzsNqmSF2a0
2WYkAyzzq7R4P/8P6hxs3OvYuI8a6vVN++aTCtMyOPmSJm8bvfQwBrLp9JjBVYgIfTVrK+/W
1za1Hkye2zR5qh3o/dYtno2bQe2GF1c2tIN+Jcsn3/PFzJ57ZMDkQ2DWy1jGPsZQ2egVhE7Z
aO8ipmx0CJQ6BEptM1AqKfv9P2KnbPSiQ6awyKlHn2qwiKe8RMoxjXiS0h4WbxXWlOFvEmOc
vBhjJl1Nosr4wc/0SvxM9kInmj1NzZA3RVXZw83QyRP0RimRvynwNdj7iA3hyYZ/Gl/HFt5l
bxRsLt+x4u4oDMWqTHqoZppp1/tD+Gd6vWDukhKxXcqLCzmGNOMBjvCxUsjzQe9WEEMCDkqR
Zv4DfIugPGM7jdGTWNKLkpyi5BoQ/bt5ABKoDdRmfy2IsU5GJsR00QuzIUZ2CLGRfDVDRKxf
B0vEwRKxD5aIyvslMelLGCdi5+DFWidiY2DmiUQOzGz+TetY7BScklh5WvAUJuEHyfMgee6B
5OkX2OyvVvYUw/IRzJ3mFvsFvOs8eq7nTMR+Af+omYHtuMg2INO0faABFnpA0N/9FWNX9zkj
pjXfCEKL0sGjIubdw4Wdhwis7UdgCexUjCWM4KGCCFBUCAFU6OI43ho4oIwXR6LS7SF2bK0r
EIHI+usFm4ldW0iMELmE/YXbJIoN7KuZKIp1M9/OIGSMEAI6WCwOFosvEztR7Ay8CGvF6iEx
48VqgExn2XoztRo8bdNYlyMcTBwHE8cemDgK7trV4K/HAKJPprOpF7XzH1BLAwQUAAAACAB3
YVRCEsX1hrwSAAA22AAAFwAAAGJ1aWxkZnJlX3duZXRfYW1kNjQubG9n7R1rc+I28Htn+h88
/dLXxYCT5np0clMCJKUHJBO43rWl43FsAW6MTW2TR399V5Jt2RjHkoEruVHn6tjS7uq1Wq12
V+L8fa/faSrdR2Nhu7Y7U8zmZD7TFMv2kRl6/pMS+ggpU89XpraDAiX0FNNbLOFd/fILzzB9
xXbvDce2jBApvueFTWNhnZ5MfaTUjFXomQ4y3H9WaIW+/KLx9nxlOxYuZoZc5AOKRckCkajk
ySNyl6atfJf+D6N+7S6MO6SiRyDseo438xRS+cHo8mwUektVObJpin7dGo3O8KOuDK/6veG7
s4ZCPq+G/d/hfdB61+30bvSbbr817v3W1cdX+nlrhNPOvsZlxYSbyrXvmSgIoMrZ+n35hcbZ
mPtbSw/MwF56frjeKu0TtkorblW+otlO0Idjfdy6ueyO9d+6N6Pe1VAZdcfK+Er5MKofA2kB
2MZb4J/lk0K7UbXdx2zHTrzbv4F59AcXhTphpQl9JghTKDAiQmudEMm3o5BagjklVWqQkcNE
bSO0VZIWhMZiCQDK0VS4isqRobQGndMT5chSvlOO7pSG+kY5ulfqaqOhwgOXMKIFzMSp//kb
8gPbc/9SApil8KI82OFc6fj2PfIh76yu1bQ6/Gscv2IlahvaqWXaWb0X1xvMWso/7UmRIHNw
kQc9/9MVhS5MBnKL7qs6onw966LDFj0u+jQSJxYW+aHkHCdBYSFIvXgSZUQeEEi3gqQUk08Q
pmmZs0Ulq7KqgPDha8+z3ZW0VJxstQY23raJXoSL/GbojZ5c89u4bMe+daZWoJ5OAt+cYOZ3
kA4qlg56lf5gu5b3EOh3yHeRU1HwxTk10o2YpHU3eX1ah6qdHv/4g1qf3NruBBPCY6BaaLo+
tRvR1C6fzpvlY4W24mHKd1p2OdyN3OJvXKmsgjrhLhBvbVOhUuq6Nf5FsQNFVWvwD4alJirP
+GFhhi0cmCA1U6m1HxmX9CjTw4uK/1cnoNMvPHdiu6azstCmtMlydevYJslizYZcnMSlwQBc
uzn5YLudzrsMb2IiE2NpbwkALL8lwIM1ndwt4AHa2vOQJqgoSu0PqFFH/9Abnp7gFyKMdHij
UkmBt/bVsNMbw7jov7SGHWDBy7MGJMOwvb+GN/raG47GZ3V4B0rH2lmjjt9haBsfdfiIMoZj
gqkTGJ0m1B/rP9Q1mg/jH30zqF4XJ53WjxVSGZrY77aGOlRGH8ALodk5v4Ti8Uv3tz4tRac8
1mr/0ht2df2M9gPAXHhcYz2ZPy2RbxqOowKEsp5mBAvCnK0gQItbPP2bm2DI0lowCue2GxWF
d6HkYTrKz+LzsrAJpqP6wRLqWbEOtIdKyTfeDmzT9wJvGirf3HyrtGvt779XrpahvbD/xbKH
ikjkK9G6pDSg7Lp6XH+tvVG1+muyO388PaFr0PLJt2dzINX+VmGE22R9N/BqpipKy3EUAhUo
PgqQf48svBzvriLaVhUB6epgTvtqd4NZ+wqTBaJt+ncwpn/f6/QtEYnRhxr/ZS81+AdTvxYl
7K5umGCp6NsREIjAHQGZ1EqQCED8wYRg9EU+8HuBKAROiceaa9LQYYwFKMVng8pkKUlnQ6ol
Q5oWsvSbCdoIK7/0McThmJb5zAKJgTfLaYyYXz4JAhPhDJR3WSX4eZEPJHgYZidAwDCcQHFT
8+tQOYH06lwOTfhTy/JnssTFOYxZixc9gF1n5WGne/7+EjKK+Drhx06nF2tm0dDWKaNlmTjH
vHk+jfjkD7P5YM4NXw+PogSsRmf5OMpY/ohzGOPS5MsnSC3m0BwrEqwj8zYIfRBulMaHjwQy
z3RR9kkK7LkBZwNCEbq/BEfmEWQ8MxxRK26OopcLAM+Nid7pJ0QvRxmIqHNe079XjwHJPerQ
HcPw/eAcmt6gibji+rvuzbDbp5WJKPYh+7nxzZZRQKXzbtC50AetX69uYhL6aHyD+afeyID0
hhtA6ngOML4IQW+ybCfqPMYlcYJDwR6sEyobKIOwRC2q7EWJMJg8GD52FKhzIBKzU4ZBNMYB
6sTAyQbZRevgJZi5yNJBiCHVLMhcgOrnmbls0whyadamRKimjxbIDUkOLsqxg1C3kINClE2b
YTnqgvEDrQG76CGbsPSW+nIVzLOp4NXwn0gS8W9EZbAETId95cDJk3zjfrtdTafIpzTWU+Oa
Qh3CtaykDJaUKihYb3uQazhLBS38jn0mhMFCY95FNFhCNpt0Du4llpTUAhgiEQVshjfeFnMG
QMYzXEtmOJvHf+AFKZm6yXRkGRcW17oZ6QX5achkU376neFZVz55Nc7Jm521bHKyOamJz0k1
dhWYyas+tbz05zL7iR6x8Y+koPvQnLvkdeaG4a0Tw92u6GRboAW4BdPYFrq3TQQzL0T+1DBR
CiOXl8abg+IfgMUnUzEDio/05UwZt7OlD1QihoobiBmpWIrQ/JwYoQRYtzAgJleS1LxgoVlr
kiVDdRlT3SRqWE48zWJcNhQRUE7+sGQmgGhaLIFYXaKBZLmkKPZJsSlsPNIskzxpQk46seS8
eKL06OCvw7EKsLR0LShnUYis5GIprCOjogp5MGORVek+Li3okm9aLVbtAloZOchSWKOykpBS
XOd0Bhg3XNDEgeuu1GD/oNS8VdhkNkQKmOwsCETvEmRPt3nSePPjqxPQS+Bx/Bo/3sDj9Ad4
vK7jB8798TV+QIamNV6dNOokDR5aI3kc/6BgQY6tiGA/NlZOSEpZGObcdhH1+0PdQnO2UzMM
0IjtMBuFRN6C0rdvfQNCFwaGa8xS5oo3GWvFtuaSKjbgwkYWrYbEevYJyqICc9+lgWDddxHW
JygjWQr2UVB2YdkLA2xYlvbbFJCRe6Ufr497LYQI7H2UQNbaPQ43ob+vMSDE9903+LmXrmGK
yB77f6OmtJcJx0ra13CzEvY35sGexV/wKWQfUzX3R31PY0z00332P6a/38rHWvj+Skhzv/Y2
t0sV9BquqfV89guajVV9XpcjU6Uraszb+fW0t3vYkhCyHz6Sv5mdCUnJ7k5IEtmh0DcAbka9
CK8kja8jM95tsfhNUQRsoxBHWlZBorYHATxqYxBAIIYGwU6DLbkAAjUiCCAUGBDEKEAdt6SQ
NhOIY6Z2xIK9mxZbBJNKLh8ZIXb5O1QwCNEjEgmWVgXAIIBODBd4EMvrPghEXD7I5X0cDNAU
HA0WRa8Or3BSPY4N6/fLo8RKQ4ShppnoNtIfUaP2ejhgU8vK21Ma9Zau6P7C1cAU5pukvUeO
clJ/Ax640ceRfn1z1e6ORmBHb92AM3DcbY/f33TPvvrqK+KUhb8KhYyI45yInYKnAGeT/N9H
4+5Ab18NrqELzvtdHfqmOzjv/64PWwNCLlnO1A9UF1BHT0GIFngYYT7cOigqq19GrM9PjVY9
wY97BteH5Nd8iOr0xGYRLLqfQWQaX0Ra5NdNvL4sJefV3eDRfcaLqygyNrJqbKSacCJWhXc6
rUEUfZbTWuTIiJzfhzi/eUZwy3lcClA6j0sByPRNGG2DeyVie/J+gwJv5ZsoHxt6qjbU0zf1
H9X6to4Wbevyt922CuzkcfyvGEdEgcCVHIHCxgIQnGseO27bgXuHq3lQYcLZivRit4zhEFV7
j56/2qALK1IT1O7L7hl+KOnUcffj+EwN0WNIk0fdNhbEzd6wN35l0bSr63HzpnvBPnpt8rEf
EwkmO2zfdAfd4bjVbw6vaJoPNj4jQPRjeNXpXrTe98f93jlN+fCR/rXQ7WqWesVRK03z/tXU
flwtXy3h6LdBc+9pdzdh7tEEL1hP2nw6CQvVCWa52L7ihXhLyxw6tenKJc63pWEtbCBHU5fW
LT6NDmMTRF09brXfNeuPJ3X471X9sQF/opqT41v0PVjdBmTNbrpGCMmvoAoazbqF/mhivAQR
GMp/al480vNfXfxFMqpNPsDktDGxDbE4ko9ESspYswTwaHYlJGzVqoa4rIpIrVuCuNTCJYhE
rFwVOhOsSIJI1NoliFRg8RKnAvXdAZW05asadsr6VaHX1y1gAmLqnHjCru6h6Y738A4bvgSw
3dAL7nzXEUSbG6IYDwsbUhKkRMnIISWbPIqIt3qTD9a0b/nVkVNiU7DabgghF4ExRYJ4D9YC
Du4KIt2EDlRTEElV8b8HZx59G6tH/S7d1entAjmBS/ZncZpgaQGar5ZWgpSSvk1lMOr1FRVg
F561gkPWoGHRt/i2FoscYsbBsqB+rVzrJ6zQhIYfWXnduyi/P25f/qQYlkVf8X0v4RxRCLwp
Ajsm/kA4w4aV17unmbC0wiICmh1AmCh1rkdMGa59FR/p2XiEp+jsTemZnE0nb0iy8Aau/OQJ
15EZLiD+czWa8GmY7AEYdsTlmVMtosdW1o6lZE+jiJ5C2XjeROB8iVZ+xGfDEZJMjthJEa38
BJBZeFojOaFRdsoiH1y/y/B5ngkxeSER8dCWKHo8/pBbSLmFlFtIuYXkRpRbSLmFlFvIKrtA
uYU8xC3kJb00joR6QOScoKuDuSAEFUYKt8EXIew6YU6J6orcdk4IbaMip21W5LQNipyWVuQ0
psjtM1wyp8hpaUVOW1fkWIQlU+S0ZxU5bV2R0/KKnMbJs2uKnLZRkdPWFTmtUJHTUoqcltPW
tGLVTosVucsgJZFIxpazAJOohu2jbbAhW2AgNixVAtjxUiWINjdEMehSJYi0vlBoIHcLF34q
gqNswYLioRFFY4Kb7WAP1/YnhbEUxlIYi2FLYfxChfEGLfoCLtMP5iB4Z+t5jcI87nhxuKv3
ZcSLQ0WrxIvzdALcYgvWgv0fBtjiCACrplgQvIyW5Y6W5by1WkbLHmy0LIzgZxYt+9KjVWFE
uKJVDyYMNIk0EGvIAUQaQA1lpIGMNJCRBpwT4mVHGuxYq6Oq5Wer29HmFXFCFkoqeAer4NEB
ernqXYVTj6zZB3F6SuhUEdYHRQbw8H7EIPntAJFmsF8HeP63APL3wpffBL/xvnfBeVJ+Gz/X
5f9cQFyX/3MBpedOOfSOfk8g/esA678KwPEDAOmL/p+7yT9/ZX/BNfzPX3nfyNyAXnrrObvC
nOmN+Zy83tjYpDeW3lH//K3zySXz7Fr5/EXx7Cb49AXvuSvco7+jiKad3M0eZfSzGReWyOSZ
FF23Tkeg6J7nnV3Snr2dnV3Cvt3d6wC/vtqYCk7OpFW8iAo7UARVc/6YDqAkYzqkG/FFuhFD
/lmASVTD9tE22NKN+OndiDA027sRZUyHFMZSGEthLIXxAQjjtZgOQTMK06KFNippwy6HJk0B
y/VoeciNW3TLQ26R6M6fZCs99sZ5yI2Dc9fnASFTgQJzD2xNQh7qOeRDPYJLCW9BbE3IW1YO
VU+Xwl4KeynstyMhhb0U9pdigdvbBHW76LBjuV202xBuE1YZ03On9uxw47dZHf/P4G3o+c8y
wAfaVSSKo2wZ0sMf0nPU0S+v+9e/6dAdox8+ZYSPiz6HyG2o+UuP3HbRCwrYFjKl4XbmZDJH
W6MoIK4u+n9DwV0kI8BlBPjWEeDZVeDzCAp30YuPBceLi5m86uFj+svPfHm2lf6kQiUKJI8p
HXCkZbl4/h/DLMsrVx6hyBU+yQUkYx23inXUB1DjnYc6dq5HrWuW3agWALnvkMdyRp68hMhF
1owobDGVQJalRF5W/Il8bIfk7zIGgvfua35XEQVUOl2lHT62wy+QP0NN1cdVoD1eYp//MbLP
a4kFPgwMmDkoat6TayxsE9vp1+3zwJWB52y4hPSkvn4L6cKw3fbNeIR9UKslyeFnbwYiaCQ3
rHsQA8eaoFGWXsgojLYI7mGJ1QESuvIYV7XMbA3gGVzBAqveM7hmdGbdK92LUqxJsSbF2mch
1gR9aanNcakvKZivQjDSurAtPFxnUqqSot4kZhoQ1oOx5TRfgVLT6cHaFzga8T8aGDhqV24X
4DIecAFJC4O0MFS0MHBw8oswMaTaEdkYMikp6UpnvbCAZYYGgZ5LwWwwNQhJbGlrkEr5S1XK
efg7BSPV8t2o5TAKxlI0Mm7pPfhgEZgKoq1tAlKjKY0bUo5KOSrlqJSjPGjbGVO20Wf5IjXz
BxV5I9PkTR/iglceLt/74XJOnseYQkg+qoAE2cJI4DWvhudXxAPzZDVEuvOWx+TzS5IonmUH
XCfr4Zk7Wc/3G2O8VclfawJ5h6ryy5VHrjxy5ZErDx9LyZXn5aw8JY7jB8MOXW+JXAsSbTcA
ge+gewS9cLh+5OI6b7iyRszTLOT4wJ7l0iq9XEezeJv+R7+zeGXLncdcHmYuIOmGlm7oim5o
ccZ+EV7p4mZFTurnALI3Dez2irIK/V2MssG1vc2SIT3d4ts16aE5DA9NBXYvRpH+m3SB5nS2
mPnC9VzbJhT39qEaraQUlFJQSkHuPpVSkEMKCrmV/wNQSwMEFAAAAAgAc2FUQg8Ln/cBEQAA
hqEAABUAAABidWlsZGZyZV93bmV0X3g4Ni5sb2ftHf13okbw977X/4HXX/p1QSV3uZzvpa9G
TWrPaJ56Tdrax0NYDQ0CBUxM//rOfsCCYGBR70xq31XY2ZnZD3ZnZmcGcv6p023VpfZSm5u2
ac8kvT6+mymSYXpIDxzvSQo8hKSp40lT00K+FDiS7sxduJe//qr20/nCtAxMN0M28rQAGQzP
tBmr8RLZrm5KP8T/w6Tf2nPtHsloiaSK7VjOzJFIb66Gl2fDwHFl6cikEPW6MRye4Z+q1Ot3
O72PZzWJFPu97u9wf9X42G51Buqg3W2MOr+11VFfPW8MMezsW9xWyLguXXuOjnyfDZX37+uv
lIKDeZgYqq/7put4weqolM84KmX9qNIdTaKrvZE6agwu2yP1t/Zg2On3pGF7JI360s2wegwT
JoCr/AQLwn2SaIOyaS/XdGHsTP6eekh9tFGgLk9PxuYx/ERkU2iWsaJPJM6KQjI5sLqIQ408
M8zI1AJThg5mw/xAm7tAJB1NS3ZYOtIkAEtHhvSDdPQgVeVaTYYf6EaCvdggklzvpZr8Ic4c
931Iec/K9vvP35Dnm479l+TDJocb6dEM7qSWZz4gD+rOqkpFqcK/2vGb2KCidgUHVK45oe0I
kuplbEfW0eKiEyZ1r0Wnjb6obIH5LLLkE7IFcOKsCGQNhwh7WkaOFOxcfMcX3epFWZfbe2kx
uirTxCYvPcK0UBHkWHZgTWK84Pa+6znDJ1v/PmzYMifW1PDlk7Hv6WO8zC2kgh2kgvGjPpq2
4Tz66j3ybGSV3JFhTYVMH2Zp3I/fn1ShayfHp+/k6nhi2mPMCM+9bKDp6iausU286cYVGCte
helJS6qA7cjd4oPLlbXQJzwF4qOtS1QeXTdGv0imL8lyBf7BY6mISi4RXGluSRVfmyIf3UkV
Hf4506lUaS75kumQDQBXGf8vj8EInzv22LR1a2GgLNjYXUwsUydVfAqgFoPyNTggNevjG9Nu
tT4mFinmMNZcc0MEWPsbIjwa0/H9HH7ARHoeUwfToPLHXIIf6FVLvT09Uc9qcIcHCjdwNxy1
1Gaj24XbZr/X6ozgMam/NHotWJGXBBee4qdruKO3nd5wdFaF+5tO71g5q1XxPTzp2q0KBVbR
GxFKleCoFFBdVt9VFVoPy4GVOVanjUEn1WMJ/mPs1W670VOhM+oV3BCerfNLaB7ftH/r0lZU
uuQazV86vbaqntHZgJqL6z7BvXDyH/s4cD0VzRcWGCQyIEgpoObPyZpt+D6aT7BUqGciUZ1r
ST+L78LsnumW7PkutE3ZFhgLpcAduTJ1z/GdaSB9N/heOlaOJmYgNSvNH3+U+m5gzs1/sQCh
cg55ElMuUu2dDEvpuPpe+SAr1ffkHHxaBf5UlbhPnjm7A57N7yXeQpPoZg0rJVmSGpYlESxf
8mB/ew/IwIbDDnqkbNQjkJYWXiLfbOlxVb7BPIFjk16vRvT6SaV3TKSxWzm88psK/IPNW2GA
LXULc8uVXFtCAgm2JSSdHhm47GIlPCJW4CKMFdNijGKGoiwscWlGylyihWUu1ThCb0TJs6Ub
qeESjsPSUg6D14k5XMckHC2sl3K4NpR04bBa7fNPl9EYW61OqH5Zj6rRiHR6+UOvP+p3mqcG
Rwxgsat7Sm8un9h1TjGO9IkfeLAIKfjmll3fJsuX/9LrnRO4WqDf0VL7F/9IP2IYg/Dmgl2H
rOn3sLHDrZkv8sJd11/6mI5vv/7TUYxhuPv47Ksf24Neu0tnl2HIrPrjVetCvWr82h+EM6gO
RwO8oKrkkJJlfSRIO70M0uoHivNovD2hZtAzVgxHVUj/01YNQwmeXGSYFhvsRc4eHj9qHnZ7
yneYaSG7CBCLyIZCSNBFeazhJaSRM4yqWebMRoYKrSJZX1M51yzL0VPVuuanYEYWEJr30BzZ
AanBTVmmH6gGslCAkrAZDFyz4byJVpBt9JgEuI6rugv/Lgn9Z4G8JwKCuwVibXAA5sNLKXTy
S8p4j00W0ynyKI9VaNhT6EOwUhW1wUGxhvzVsfupgXMoGDv3vBgxhnOxfs94cECymkwOniUO
inqRv1pASWwJKW4052MTvaOs6J31C5bgcq2kJLWSsl4rKQmtpKxoJWVFKymrWklJaCVlrVZS
MrSSkq2VlGe0khLXSsqzWkmJaSWFa6WQrNUFHumaoxY9Gvc+XZ1DV2sUmCWmn9NttBo/lKRu
YwCLXd1TenP5xK5zjJHQbQrRaex6y9D+pVeu05RIpzGMQXhzwa5D1iSWj5GSosopWXNh5Avi
MUVNayf+jNLa5wwv+mI6LU93KUndxZVTQgsp4lpIDp3nenSrTg0nXnSTRbTEzkACQQ/wLGxy
O7ODYGKFeJMF1QRzNIewXpzaQA+mjkAtBMibajqKUaTq4nR3cIbwwRkUh5GlwOzvRBuTmesB
Fybt2ACJzl6v4mh9SsdRBnxaOBJXehE0rfVo1YraS3B1Q65ZejCs4YowpOWPgiGllCMHc+1I
YaF65H1hD5LXkqZ4kVJT3PBJ80rySwEp1cnBad1J+dGHv4rHO8Bh8V7QlUUxEmqVQ9ITeUmD
H/SsayBZJofjtSsz4cIFZFyO6+aoTDvLB7OGV0J1cwinXl3rHIdrdA6j01FgZIl9Qk1XPADq
MAWzVqo4i6DOvY9E4kX2LkHoXIJkatff1j6cvnkL8h5+jt/jnw/wc/IOft5X8Q+uPX2Pf6BC
UWoSluHYsQj+ZW1hBYTZXNPvTBvVTZCu2/PYAINsB0zXnHgaJBdcabY2i3k3PiScG5s6Wco4
gDMHss5Gpx6yXTdEheFOmwKJuVP+xq4biKT71ltJKortP/EMHbPDQYBc2x3zUM3trgUiXrfO
nijLXT1fwnwn804473RK8O/2Z4RbD7ua80zbZvu7ijezk+fL2e/oIfu7lGv+zoUat/t2xHoX
D5WYiTubc8x8h90OLd4dsY+vcuWn1MkRgNlGdabtXMCBQOuwNV0omhhZs0pJa3azAJ3yU3mT
n1Df3JJrwvInkIT1TyGAUWfTA7cEVmCGVmLHAnmCQtj42C9I4QpT0IN8USJ6Wi+KTc/rRbHp
AbYoNj2FF8XOPmiLPD3o2ibk8cO1IFnsDC0yl3GhEgkbqekhKlYsupmLMyPyA3ScBDiQiiZA
iJbkaNwF4YVbBmG5i5x5RcJJVSzds9fHoGqYYtXt5idb5aaAQk8TSWJkMtigdpo3nzWy/PHk
Jo/FO7rTrC9PJ+M9sqS31Q/g3x/eDtXrQb/ZHg7B59wYQDBh1G6OPg3aZ9988w2sHviVKB5j
jeEs29N/8nE1qf99OGpfqc3+1TVMwHm3rcLMtK/Ou7+rvcYVYRapHvmGqmd5+OQHaI4fIuyD
iYVYW908Zt3i3GjXI/pwXnB/SH3Fg9RIp0xWO6jJV5HXJZbPxUJGUSCJQ1IRpIzo0frIEfDe
cpJh7oPMDZZviJCbTJiLgHMI5Wi9YZftFjcwiNBXuYFzNOBh3+75vv2/JAfL0YLU08c7tiXI
/QD5zsLTUTox80SuyScfqqdydfODHslvFZCePNF1465vGnGJjuKip3AQf8kwVLEzOTQGI9/P
hNpkjzphiEKziHW8w7BX5aoNyqUOlvJl+wz/SHHoqH07OpMDtAwoeNhuYula7/Q6ozcGhfWv
R/VB+4IXOk1S2MgHgal7zUH7qt0bNbr1Xp/CPHCGaT6ihV6/1b5ofOqOup1zCrm5pVcDTRaz
2C3OsajrD2+m5nLhvnENLdBo7QOd1fqJzBp1/BRourBJ4MjVDHjxuf6OQMNXMGjBNSb4TWeY
WJ/N06jR/FivLt9W4b831WUNLqw/5K0jxmMx8YnurNtaAOA3sL4UWjWBUdYxXUQIq8F7ql8s
6WtLbVz6+ZRUldg9QFbEScMPn4IUHircxoojqCgZrROnwA6hElRuKSrqGBIhpM4hEQrqIBKh
oJ4YEQrqKBKhyHYWiT5h6OamLOJOoxKkMceR6BzHnUcRafbLfNisGmMGlPicRHL6DzBgy3n8
iL1GxYntwPHvPdsSo7rTBAke5yYAIprIaErRROYVocM21vjGmHYNrzRtTAKK9dkOIAsAC24x
skdjDi+OitEMAgv6KEYjy/jfo3VHi9piqd7H5zhufuPXPxOJPmJNgeZauAal4e8MCJiRlW+i
dwb4KwLsVl6XoJ+buJ+VrE/AYh6C/GTl4nn3yjYyqQshpRKoDynShxTpradI526e8QvJeoaB
sAzhsADSr1hkgX4RYUsfyygXWciNlIQdLRNZWDlYizx8ipQ+YYv5GPhRu/zBdrMTtZJ5sFWy
D7ZKxsFWiR9sFX6w3UJwPXWwVeIHW2X1YMvj8fxgqzx7sFVWD7ZK+mCrZB5slfjBVlk92Cpr
D7ZK7GCrpE6vyvqjrhIebC/9xMGWVG2yejF9CVIPlSZl8eFiBliGiV+cODTxxajuNEECauKL
0aya2ApYrQUOSmKNhI9DkIrbvNuNyLzqkGqRrwcdQjP7HZrJfZC556ANEXJDMLkIKyHVvQhf
4MiLwCTv8SdGog96CAyHf7TjuU90pF/1z391P/N1fbEFnf+ZjEJf5SiEVOirHIWQDp/u2PDT
HVQQp2vSHoBalgfg834AZIsf/jCjL3lEX/BI1lwYAptnXOhbHqLf7OAf5dj06xu1hAcAl8NC
0dxC+GYeRBP2PrOQdvOL5grSLrxa85YOL3MXJFEONu4LsHHpo3qhFm6JLCQ+5v1NRnpuh+nW
vibkRCGxwoP50gEx2rVXFA7b+OtDh+DZIXi2g+AZ3WiCobPX8JkhPngWd1uBZaR0ihw6Ckee
gEuByNMhpfJ/mVIZjzzlJlmGkafclMr8dcdXL6EvQeqh0qSvPbmsEE0quUso8lSwkfBxCFLx
yFNueD7/REox8gUlxTsE6AXF5CFAnx2gv1gWCtALrV/MQ5ScO2Q2o3/t4XrRrFrIyC1NG1sZ
Yn3+POkCXPwWSRHb2p9RKucZzs0Ms5FgQtg2cx2g8VfpDM75O0IH928Z9+9RS7287l7/psK0
DN99Tm+wjV58ogN0ez8THWz0GvIbbLR/aQ02OmQziGcz5IR88Z/y0x17as72N97L+3hIzngu
OWNFo/w/8jVs9LLTNLAi06NbNVjGS16i5JhGvEiFKcvxCDkJp0Ng7ZXaZy89IMlHsl/RSN6v
Lx6KPIQEtxkSVK+g91uPCLauh41rXl3bJE5Y+ykmYb5koJDvAcEo4R7F+/gYWLAvDiBzzeV3
hk+74EzwekyadGcXFtoHX/Yr8WXbS514cWhpjrwZqsseboZOXkGPtxL5tANfg3WN2BCebG1u
6tjzverxhtXlO1bc5Y2xQpbVuBd8rpl2czCCv0TtBQuX1BRcprxezPWsGQ+wQY8VMZ8n/WKF
KNXcfwCtqQIiTOIx7meeOxjQOanoG1mR91eMLObPzT39+XeLANwlNpgz+3v8i3USi1ZuDG9m
7cbYvnRzNzaU/bJ3Yx07GLwHg/ezGrxfzsKNrfqXa+LGBsFs3AQkJolBPISg/L8qgM3fotMU
Q0gbwMXl+MECPljAe2AB567TGMLBBt7UBobJ11zBTAjXefRcz5mKUYnY24+aGdiOi2wDgKbt
g+Sx0AOCUe6v+b2+z5tY3+u5vnRjXHBkX8w2F+xnvoFdyAovhHQw1Q+m+ucx1QU3wYuw3NeP
iRny6xEyX1MpEGuldemk60KJMYeXUg4vpWz/pZQiaxWTFafwkCgF1IlRQHCuBJFXhgj8pyWo
qLlxeKVmg+8lg9T1S76Es7tPHK+I/JLacT1+2n9T+iRwcOcc3Dl74M4RXbbr8Q/OHkajT2fz
mSfayYQk+w9QSwMEFAAAAAgAbmFUQup/2+rFEAAAP5IAABQAAABidWlsZGZyZV93eHBfeDg2
LmxvZ+0daXPaRvR7Z/ofdvqlVyxgnTgOM+4UA3ZpODxAEreloxHSglULSZWEjfvr+/YQKyEO
LUdjp3RctPv2vb33XfukXH5oNGtlVJ8ZE9u13TEyy4O7MUaWHRAz8oInFAWEoJEXoJHtkBBF
HjK9iQ9p7euvPMMMkO0+GI5tGRFBgedF5dn52SggqGBMI890iOH+PSVT8vVXpZ8up7Zj0UbG
xCUBEFi8UqhCtDuYEdc3bfRD8j9K+q07Me6JRmZQses53thDrOut3vVFL/J8DZ3YHKLfVHq9
C/pTRO1Os9F+f1FCLNtpN3+DdKvyvl5rdPVuvVnpNz7W9X5Hv6z0KOziW9pWXHEZ3QSeScIQ
upzu39df4ZyDeRhaemiGtu8F0eKo8H84Krx6VNmOpidBb/f1fqV7Xe/rH+vdXqPTRr16H/U7
6FOjfXsDdasgl36C/eM/IT6Rmu3O0lM78IZ/wfbRH2e+DjtpYJ/Czxx5BK2JCnif5xVkR7G0
pjnViHWlxNaMVmgbka0xWBgZEx8Q0MlIqWvoxEAARicW+gGd3KOS9g6dPKCiVipp8AM9X9pe
jzc3Vmvrj48kCG3P/ROFcE4hgR7t6A7VAvuBBFB2UcQFXIS/0umrRA9So9tu3pLDXBjffCxb
1rzdoPLyFZdEz5qvuET14MVniRMnjwKDLJ1vUbTFCdhc4eqtIbe5WoXb7ogqE1G0ue/aXu/J
Nb+P23XsoTOyQu1sEAbmgC6BQ3SQdjqIOP3Rdi3vMdTvSeASZ8vdEpcU2OTRKq37wduzInTt
7PT8jVYcDG13QCuiM69ZZLS4wUpig+26qRTGSk9vdtLSPGk/8iv/4DbKLOgTnQL10ZYRP1c3
lf4vyA6RphXgD5aloHgClUQfcN+JgwqhMSIhuUMFE/680QgVqjO5aRrsCMBTo/9rA1C2Jp47
sF3TmVpkGWzgT4eObbIiOQlQSkEbhQrgVMuDT7Zbq71P7VJawcDw7R0RYPPviPBojQb3E/gB
gboe0wQdq/D7BMEP9Kqm356f6RclSNGBQgJSvX5Nr1aaTUhWO+1aow/LpP9SaddgS14zXFjF
DzeQ4slGu9e/KEIa1vAUX5SKNA0rXbrVISMK2n1GqTMcnQOKs+KbYomXw3YQeYnVqFPQWfEU
wX+ier1Zr7R16IzeggSrs3Z5Dc3TRP1jk7ei8y1Xqf7SaNd1/YLPBpRc3XQY7pW3cdUHkR/o
ZDJ1QFhqUI4yQCOcMFmwYrovgYXRyqgFwH5MB/2sfhCX9s10tCD02XmphCGZDClPKq/oIt6q
i3xm1rROx96yzcALvVGEvut+j07xydCOULVQ/fFH1PEje2L/Q9kR55okQEJUoRI0XtROi2/x
Ow0X3zLb6bwI9XPB5D8F9vgO6qx+j+YtQC0BaEgGFXEaQhXHQQwrRAHwiuCBWBrjdA5d3W/2
M8+Fb2iVUGGVP1t9/vyg85TgRSKpxU+ZKMAfHLuCAOynV7SyjSxnT0jAevaEZHKjSTIdkaMj
EhnJe0Q2y384ZsyD4pxkQywvWVGcl+xIIrT7c/IsW+IlkjVJWJY9UfAq/kTLBGvimdXsiZbG
LCoeVq1++eF6PsZarRHLTdGjIo5HZPLH72b50bwzAj06EQBHPP1znrh+Es8Jxzgxh2EUwB7k
4E+34vk6nb/+hz/vvMg3IvOO5+q/hCfmicDoxokr8eyJpt/yZ2cWisTTSVwi505/X++2600+
NwL8vlW70luVXzvdeNx6r9+l26BYSqE02ktQiu84zqP1GlZJprFoNXryiWU7oi9XG87K4NEI
qPtH40PXBgadN4Op3Dp4d8YusXQ4qkQzVxRODMfxzEyxaYQZmLUMCB0JyIS4ESuhTTl2GOkW
cUhE0rAxiXTDBbOSLCC75DEN8D1f96fhXRoK/qjgiYGYZ0q0IQG0HpnLoLNflqcbazgdjUjA
61iExj2FPkQLRfM2JCjRULg49jAzcAkF6Xgvs/OKwYgz70UdEpAuZpNDZ0mC5r2gG2H1LgDB
ewD5iHeSjziWjxuFPBV9WIg+HAs6kWQVLdOzKXyN/k2Lszo4A+fRwwEvj0jbCxKItD0hJXXz
zdhMSuKUlMRJKYnTUhKvlpI4JSXxgpTEC1ISL0pJnJKSeKWUxEukJF4uJfEaKYmTUhKvlZI4
ISWxlJIxWa0JdWRLTmrcyG5/aF1CV0sCmBU8eJ2s5cV0x6ZlrQA44umf88T1k3hOKEZK1mIm
Y8XzVqD9w59SxuK5jBUY3ThxJZ490STd07GMxVzGpkuurI0HbMAxs2JXLlFW3F7QXb1ZWOMc
whonhDVOCGucEtZYUVgDvhb7hc15Uh9ZXjLrp7NkRr2xDEIeYClclhy7UTR0YrzhlMvoCZnA
LVCS2iIPtklAYEckGBkmSVBkypJ0d8CwQ/AqJWFsJwhrINXGcOzDVqJ9pGOMB0hl0hrlQ5ZL
7YMDs+oHrVZO1hwrq4/wogWFJEXvx/TLNBRZEktnDsnoKPMq5QpJTKm3cFhSceGEYiFlKWtK
ZrPU9FcQ86XnhRmlRoKzWg0n54u/iCc7sKjjcCq+szhGSuGRkOxEXnMPP1csLKJpTFyv3Jkp
XzAg03xSa5rneWflYFbUlVKqJERSL+51iSN1LQnj05FjZOlzouSYoQNFBdBJUMGbRmXp6mRc
ca6sMITGNXCvevl16d35q9cgFODn9C39eQc/Z2/g522R/tDS87f0BwowLiHK5qkPE5zZxtSJ
WGUTw7yzXVK2oTt78w0B/XL3TNMeBgZcV7cM1xgntM13KWVzDy6Y/YxjhWbNnXEHbodzy0O2
BBz2kNVbB65/zvv33Uhaiux9sZfIn8MNAVjeweqOZeLBGmB8d9+1M4F6oKVldR9izlnFh5wP
+rv36ZAaxYHme6m6s/fDJFs5xNLK2g+zvuEBWVl4aD4mtcDD1HyA9WQq46Hmm9Z9uE7Huu9h
ak/ubvxTxoSkwKx2rXR1uKBEb3Y28CKqVee5c5xrtXhLrXZXx+n2mj+j/nTLnikDgEFSRgCH
AEZZzA4kGWzzBC1cV+ePlVNBpo4ANQJflYDb9TlpuEmfE5mb8DmRuY2bE5nb6TmRl1viCosG
/dqBOml7q1ElLGyFWUwyGkbFuUpAOKtx+PHNXRfjFyDwEKBAvFt+OjJjJnET2BRtF7jnIQKq
MaKBWyLcsd2hoGIcxtVsbg7o2hgCCT1NBaKxuRCDOmhQ9bKRbR7PxgC1/zCoOjDZiE8c9Lr4
Dnz/vdueftPtVOu9HjikK124aOjXq/0P3frFN998A/sHfhHHE3VTuNhO4VNIi1n5b71+vaVX
O60bmILLZl2Huam3Lpu/6e1Ki1U2FzbaJy6xtd5TGJEJXUY4B0OHiLaamypr5q+Nd31OH08M
7Q8rLwQQgOnlP0EgDr+IkDG1UDFxiTS/WpKQzJ3Skvuk1XdJUPcxfHGb8EVtvh+p2rrHYw2s
6Is81nnfLzie7+d9vpPr+DIPOju+8+1mZq8oxMZn6S4JvWlgkmx4zJlW0s7eFc+14u6XFYr2
rZJpC8wkfceTy9B174Whu/Pc7Gry5p4bGjacf5+ujB9uxJcKhsNU2gPeURVadeD8ZVBvr+sX
9Aclof36bf9Ci8gs4uBevUpZXrnRbvRfWRzWuemXu/UrmWlUWWYnRwGlble79Va93a80y+0O
hwXg0DJCwjPtTq1+VfnQ7Dcblxzy6ZY/LTKcjhNJGjNRNh9ejezZ1H/lw/unBi994LNaPtNE
o16YAY2mLrvq8Q0L3nstv2HQ+M0MnvGtIX3RFSY2FPPUr1Tfl4uz10X471VxVoKH6A97HYmn
2SUbYJ2DIAij6bC8/B0gygkHsG8GFOdNCWvQlujEdBgyyVh2jQjqfQXYotdDmKYybXjeMmyn
4Kl8NeMvRNVp7udzVqR+mIEqhydGGpxqBAHJ28KCrycnFS9SJqA+H3Uifxsi7vtRoOP+HwUC
7gNSIOD+FgUC7gtSIFjuD1JcWOjjjjUk/ULqlAnfkOLsJv1Dc8r1HIHTXrJ7m84DDNbxHt9T
x1BuWjfywvvAdZSI7gw1/MeJDfk5yVyYZkjmBhCjo1bQ4JM1alrB1rQJZqfUZTeCK37K45Wo
Hq0JvHuqRNKNHOigEomm0b9H545njelMv0/Ob1J3pu+PpoJ3lFoCATf1LUbyQoK4kyrXc4vm
TvbtywnrPgZqHwO1Dx+onTw7ahHbzyv2GsYh4pTjDPDiXJcY8AEAUGcOfzmzw5WM7KbyBUZu
C1t6HxQ2B8fJuiGUjHXpj9jeWt9V3i2z1vFyax0vsdZx0lrH0lrfw7V+xlrHSWsdL1rrMhJA
Wut4rbWOF611nLXW8VJrHSetdbxoreOV1jpOWOs4Y1HjXe13vNp+x7G1fh2mrHVWtMPmp+Tq
lAHZllLccufSNZdYMblpYytGiejOUMPnVowSyaIVgUE332wFKjURL4MakdTr93shDIvOBcAX
e3/Eh7dq9STG8RLpBVwi8aV6mVdIW9wVyyG/tDsneq+Sd+nErUqe4CCXPO+YIOjfS/i4zMYl
kZ+PWfOxmKzXpbTe61Ja4nVhYIVzvvlzLbm+DpMLKdfXYXIhJc/+ZuzjB2d2/OAMF2XZkqyH
prTMQ/PffrZmj5+rsbOfq0mXXFl5z9lg1Yds+EqteqP+JXz+JjV28TGUBZhiiOY+Y7lAhHyR
uvj6D4Iete9ttO+Tmn5907z5qMO09N78l8q4S156IBfbdOYLDlaCAazRpl/I9Z9Lnt2tn0uO
l33Hy759Xval2fT/4/7PJS/62o9KB3Oe1KNZMhekcp5tJbOc94g7Qw7b6qMu9NIgt7Ke9ORu
vjXjeKvuzI4Rrv/jCNfkndnhY15zR7iqbn9ahSK1vAbYifwYB/jc4gAVbvDyNZG4jNsYC0L/
CQ/Tc0f2+PkGgsg+MpElJZ5iUIiCiKOWTKZ1pTcu9mHN7CqohDWTayCfzaMuu/W53elHt/Y+
3dp6C3q/d6927aZXuZHFpR193Z/Juy33vJpr+xk5qeUQhIc6CUjw6WDGs9IY2dXa2DB5sphK
rrShkZepH62ML8TKcGcmuxbguQkJxqSsBbQZPnk5bRE8tzai0ICTQMQQnlz4lytNapMsmhKw
uULPWXx/jlW5+ALdxLDdarcP/0ZZEE19VpJvl8piJa3esB7gQJ9iJZ2Sv3+kSDQJH0Cm6oA3
Yx/f2qRoA3KSUKmt7d6vWXgfJeUiWfXtro06dXg3jcBF70Idz1epTnRSUY1WuBCQvHuz440X
ZZ1Dea4UBL9WkitUxc/OhdKNhYI02PVi4hinfYzTVj9IlCo3QUAUCaBIiQBsdnWaYAsaUDLV
iTjTP0aYx3JUjcqyw+1C0vO8W5qvDwlZ/hLcMQmh86z8MYl+HR0yR4fM/8Mhk9j0L9YjkxiD
cMmkIBvD1x8NO3I9n7gWAG03BK3WIQ8EBMLzDWlf3Wf1CMktDIfVza+wI5StFGlB5dypifKs
/yu3xQMG1UsJ0lJbg88WuKXWzc2BU7nitHIhgZQ9OjqPjs7P6egMFZja0dW5rasTJt3w1UIJ
fO8x8ANvpESUMMSOsZ17i+1k6rtyaOf6OM6s+r5jdOdniudUE64vIsZz9ZBE6OY6BCV9VqqY
283mavSsArqt5nz8VMoX4oJP6Cl4mZ6S01Ev9BSc1FPwop6C1+gpOKun4OV6CivZbteuRldy
M8dajJI3lGsxikRLtBisrsXka8scjSfjQLGDKdXiX1BLAwQUAAAACADOYVRCWYGMGyoHAADO
PgAADQAAAGdwbHB2LmxvZy50eHTtW1tv2jAYfY+U/+C3tg9jQDvWoWlS112lXaRdtD0gRSEx
JKtjZ7ZD4d/vcxJIICQkOMA2tQ9twfY5n4+dz5ej3LJwwf2pJ9H57QX66DucCTaR6JbxkHFb
+ox20A0hKK4kEMcC8xl2O6ZhGrfDkTftj3wqpE0I5p37uTh/+uQCDRHmnHH04e27b91e9xK+
+OZhJBZC4gA5NqVMoolPXSQ9DP8QjM7mmJpG6PgjNv414di6p1haNx9fDa5GduDCb6gAxR3H
lmedMu7rA3H/cCe37P2SC2C7zzouIaWBXOuIMBu7lnCEDwMgq9SAepVqXOuo0SAIaCWBEjBL
Q+l19xbENKiKoyKGuFwpUUE/ODS9TycV9E8PTV8pfu9Kgx4YK9hVcbX0/UsN8kiMK8hV8Q5y
nZ7XIK8c9b7OnK9BXjnmfZ0pt2cq/OpP6TfGCHqtaIfojUKMOVhE3SF6LE3j5ff3H14NYX0J
QlVqA/kHn95BFY7m14NVha/S5hJJP8BD9AO76A0eo34X9frDXm94NYD/e5eryq/nduBTn06R
E4uBXJ9jRzK+QJJjrMDj7gkkGXISaoi39yJt/zLyiauaTzHFsOoBX1LdpyliuvpkwKbRb9Y6
n1AzmMZBxDDQUsFoRENxMYhsXFTz80/s64I6F8tGxB+TiSs6g5HgzkhAFYItgLBAXOseJhG7
F9Yd5hQT5JpGLrLd2NvEvRECB+O4+iOUVBj5l9eDkQy5hYOIQNc6tghU8DFyWrVBnCN7LCS3
HbXLsWwCsxe71oSbBsYdB2JY4WYhrHYhbdMGtmkQwpz2kB1b7OiFNXFZe3wuELaH5lOH4wBT
Cc+pFugEEgDxhbRcTLDEuyQJdSVZ8U0hcdoUnlYsFWIrmBTf7+oAnqvU0FIfQhZaYSS8luB+
R5gvSjuAZ9LxqB4VMEQ4Heo2kKoEn1Ipx6QNlliXloCiyik+jjSfUQ6l42gywbwVlTO41fMS
RrBNKO1DgAOmq1VGqsa3NawWRlE0yFQunvkOhkQJh6+J7WgOhNjIWZoZJN18xFsy5uJOp1M5
Jw/SGWh41waO9hyBvbJzV3NUPbhnEQuquQ+IGdsKXC0AaiXYFXpoQ/5OmmpmxZi3jeepOA0V
2mqL/MEfc5sv1kDHPk32mcuv4O+OB3E8DTnM3DJ9Sh6GYhQZ7toJjHgWnIzioNIiFVO2aY8P
UAoIBKhxXMkChCd92bbWQWXVUl0Dsog7WBQ2xnwlQrHmBnhKBk0U+DKQ13PsRNIeE9xEEDjT
rvGWsymyRlJsPWwVoy1jzD6XxT+DsXRVDxoOUnLvVnOIll0pCJ81Ka+4e0yTWNYj25wLO2qX
zoJiVNnn2roWgavD2Qaa3XeaRnrj2WAywZG7+fPowP28w+jEn9YcZ2BJybbIn6HlgDcybAHG
2S5fGdw24fJseI4r+Sw53xGRxXfWYD5M2roaCy+SsGjQgNFM5Gp8uEOC2sWEn4PKw5aGW1wZ
totdDr1N7jVqUHuO60pxb/uSshBTtTAtbxRncAoX68oUI9yUaFtcadG2ZF1OXBFT2dTcF0/F
bBqbUVc0SCZzKuwbuIEUXtmV5ZP++pXlK0axuhRA8PP0KrmiW15NusnXfUTinYEPJeMIslLy
9TXCy55mBZlzd/7lAv1IdkFodU2LfgYkGXn1YYa58GGyX3a6nSdXvWedrmloGYFrd8/1glGj
dohQDutJ5qbFUf3IHG9jL/KZTufrrbOxD3kM8y/HfGzjL0d9bNMvR31kwy/HfFyzL0d8XKMv
R3xcky9HfFyDr2ZuqWPu/bj58un9p7dDNB9coU+QqWcYOatV3hf0TCIRhSqZQLpG34X6WqX3
1dLHBVB9vrn9gmDv4kvoG48ojXcrhGPbXVQ7iLFRWc9DfHLZiocIC/I+DtlNJNkjh2A7ZlTX
tgnDmWlwxuQw9lpheM7QeX+A2ATBUMT05+ICFryAwXp3YRrv6QwMJDfZQcay3ds8hiRsmgCu
wzX2Gw9jet7GZ4GIL8PeFirs4p7HZYy+2I8YuDTd1n/TJk2Mem8RYu7Ag/zgkj64pE5di67e
LfWDS/rgkmZI+kZDzgY9jt0aafY7s/1qPDFtmq5rLmlrqDCAx3JcW3B1/jKX9B/3NY/lRtYb
r7ZNRO3U1MwDTb1AzZVlzf+s5VjGW768ZdnUYUwA4t8PJmNRk718Rn2bcD0C04CK+ziFxZNQ
A99qm9W4W/6C1bjTnWxmIW4SKPwmVmNf22osH5ueltuYw00rmQbU+kcMx51Ooq4fCf6gjiWZ
VzerkbhkdVzHeiruYSmCZanvJ27YkzpmYl6orApMc2V6NfcAc3BpaZM8Vs+X/OstxZwIbbiK
/WG39+Aq/heu4qledCRe3Zd7juctNnzNsV178YSvFhLvlG8WEu+ELxYS73TvFRLvdK8VEu90
bxUS73QvFdZPO3Vsx2W4L/4AUEsBAj8AFAAAAAgAa2FUQr7rNPa1EgAA39IAABYAJAAAAAAA
AAAgAAAAAAAAAGJ1aWxkY2hrX3dsaF9hbWQ2NC5sb2cKACAAAAAAAAEAGAAAu6gCWw/OAeDC
00JYD84B4MLTQlgPzgFQSwECPwAUAAAACABmYVRCN6gt8KAQAABnngAAFAAkAAAAAAAAACAA
AADpEgAAYnVpbGRjaGtfd2xoX3g4Ni5sb2cKACAAAAAAAAEAGAAA5b/9Wg/OAUBZAD5YD84B
QFkAPlgPzgFQSwECPwAUAAAACABjYVRCuDHh1P0SAAAx2wAAFwAkAAAAAAAAACAAAAC7IwAA
YnVpbGRjaGtfd25ldF9hbWQ2NC5sb2cKACAAAAAAAAEAGACgG5P5Wg/OAaCtujhYD84BoK26
OFgPzgFQSwECPwAUAAAACABcYVRCi8pNsQMRAADtowAAFQAkAAAAAAAAACAAAADtNgAAYnVp
bGRjaGtfd25ldF94ODYubG9nCgAgAAAAAAABABgAgMkK9FoPzgFg3Eg0WA/OAWDcSDRYD84B
UEsBAj8AFAAAAAgAWWFUQpk0Cm2nEQAAUJQAABQAJAAAAAAAAAAgAAAAI0gAAGJ1aWxkY2hr
X3d4cF94ODYubG9nCgAgAAAAAAABABgAQAOs71oPzgFgaQswWA/OAWBpCzBYD84BUEsBAj8A
FAAAAAgAgWFUQl/ZAizeEQAA5M8AABYAJAAAAAAAAAAgAAAA/FkAAGJ1aWxkZnJlX3dsaF9h
bWQ2NC5sb2cKACAAAAAAAAEAGADg2lMbWw/OAcAk8VtYD84BwCTxW1gPzgFQSwECPwAUAAAA
CAB7YVRCGCp46JUQAAAAnAAAFAAkAAAAAAAAACAAAAAObAAAYnVpbGRmcmVfd2xoX3g4Ni5s
b2cKACAAAAAAAAEAGAAgIS0WWw/OAQCiKVdYD84BAKIpV1gPzgFQSwECPwAUAAAACAB3YVRC
EsX1hrwSAAA22AAAFwAkAAAAAAAAACAAAADVfAAAYnVpbGRmcmVfd25ldF9hbWQ2NC5sb2cK
ACAAAAAAAAEAGACgB60RWw/OAQBplVFYD84BAGmVUVgPzgFQSwECPwAUAAAACABzYVRCDwuf
9wERAACGoQAAFQAkAAAAAAAAACAAAADGjwAAYnVpbGRmcmVfd25ldF94ODYubG9nCgAgAAAA
AAABABgAwDSSDFsPzgHgbqVMWA/OAeBupUxYD84BUEsBAj8AFAAAAAgAbmFUQup/2+rFEAAA
P5IAABQAJAAAAAAAAAAgAAAA+qAAAGJ1aWxkZnJlX3d4cF94ODYubG9nCgAgAAAAAAABABgA
YKUOB1sPzgHgjalHWA/OAeCNqUdYD84BUEsBAj8AFAAAAAgAzmFUQlmBjBsqBwAAzj4AAA0A
JAAAAAAAAAAgAAAA8bEAAGdwbHB2LmxvZy50eHQKACAAAAAAAAEAGABgTs1xWw/OAcDeWl1b
D84BwN5aXVsPzgFQSwUGAAAAAAsACwBnBAAARrkAAAAA
--------------000304010201070109050100--

--------------ms030400000108080603080105
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMDExMjMyNlowIwYJKoZIhvcNAQkEMRYEFDerXRF8XDxmPY2TVgMuA6+5
QH+/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEARlcHZW5dW6hy8tj2lZjEopuI
v3qRuiLjrvEGnTJIN8+Lvz7fJBp9RHiaTwP8t0yCUpX6tgzzIxyf3n/yodLQ6WM6eU+X+1vD
rrNXoglJ5Qz6hg7TESttW1V4HcEugfqtLheM5E6bPEhygYfi6wrxnfyY2Is7Ly3zKHEL1vOt
WtQlwD1AfEaRm5gJ3pryXlR/2OopLFlAaYr7va8GzGHJmQDw263YoX5mNuCwkld1X2Nrh4Ex
PQ9i6ldbh7n+yXERRtVs4dkbFJf2T0webgZ8jdcxjhP7AiAWpUPdLn8NpDSb3hT/MCgW1tY2
9A80HfsEtFtInKZW9jGhWDk/Fn+IZQAAAAAAAA==
--------------ms030400000108080603080105--


--===============3293686369349480672==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3293686369349480672==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 11:23:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:23: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 1U87lw-0003Sc-H8; Wed, 20 Feb 2013 11:23:36 +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 1U87lu-0003SV-Dv
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 11:23:35 +0000
Received: from [85.158.139.83:31398] by server-11.bemta-5.messagelabs.com id
	3B/63-19159-532B4215; Wed, 20 Feb 2013 11:23:33 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361359412!20865420!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19336 invoked from network); 20 Feb 2013 11:23:32 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2013 11:23:32 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 077B94001FB;
	Wed, 20 Feb 2013 12:23:32 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id XBKxf848QWed; Wed, 20 Feb 2013 12:23:31 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id A0B4540010D;
	Wed, 20 Feb 2013 12:23:29 +0100 (CET)
Message-ID: <5124B22E.8060001@tiscali.it>
Date: Wed, 20 Feb 2013 12:23:26 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============3293686369349480672=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============3293686369349480672==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030400000108080603080105"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030400000108080603080105
Content-Type: multipart/mixed;
 boundary="------------000304010201070109050100"

This is a multi-part message in MIME format.
--------------000304010201070109050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 20/02/2013 12:03, James Harper ha scritto:
>>> I added as attachment the build log for this, can be sufficent? If yo=
u
>>> need other test/data tell me and I'll post them.
>>>
>> Retried now with rev 1029 and gave the same errors.
>>
> I also need the output of the build that gets printed to the console. G=
o into command prompt and set the buffer length to 9999 or whatever the l=
imit is then do the makedist then copy the lot into an email. Do a cls fi=
rst to clear the buffer.
>
> James
>
Done and added as attachment

--------------000304010201070109050100
Content-Type: application/x-zip-compressed;
 name="gplpvlog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gplpvlog.zip"

UEsDBBQAAAAIAGthVEK+6zT2tRIAAN/SAAAWAAAAYnVpbGRjaGtfd2xoX2FtZDY0LmxvZ+0d
a3PiNvB7Z/ofPP3SZwx201yPTjolQFJaIBngen3Q8RhbgBtjU9vk0V/flWQsY2MsGXwlqW/u
jL3aXUkrabVarXRX77q9dkPqPOlLy7GcuWQ0Jou5KpmWh4zA9Z6lwENImrmeNLNs5EuBKxnu
cgXv8scfubrhSZbzoNuWqQdI8lw3aOhL8+LcWNxLNX0duIaNdOfvNVqjjz9Svr9aW7aJs5kj
B3lAYlK2wCTMefKEnJVhSV/E/2DST52lfo9k9ISkmuPa7tyVSOH7o5vLUeCuZOnMohDtrjka
XeJHXRrc9rqDny8ViXzeDnq/wXu/+XOn3R1qw06vOe7+0tHGt9pVc4Rhl5/ivDaMG9Kd5xrI
96HI2+X7+COVszIPU1PzDd9auV6QrJX6AWulZtcqXVCMDu28epZogmw5TxmoE3f6F7S29mgv
NNL0E/qMCGcg0ZAZlV2cGYVk8YjwZ6RACpEvZmXpgSUTmB/oyxUgSGezwgWUznSp2W9fnEtn
pvSFdPYg1WVFkeGBsxjRHObF2f/xC/J8y3X+lHwYVPAiPVrBQmp71gPyIO2yrtbUOvxVvv6K
5azsqLCyVWFRISbreS8p8tt4dQV7NeiHl9Grw4KC/KLWFJZd0Ubkk6eDgpNWeQ7i0gkgaL4x
UWQ8czMvNp752RftClR6VJpx6RFIZsYR/kxQJ3Dx3CcrNlqEuRYVUYvYFjjHzwbu6NkxPt9k
bVtTe2b68sXE94wJ7p420sBM0cA20R4tx3Qffe0eeQ6yC46kTUqNCBGzNO8nby7qULSLr7/9
Rq5PppYzwYxwC8gmmiUHnxIOvkMHnEBdcY9OC21bux1HQfNXLlcpQ5mwCMRr25DGzeFNZ3zX
HP8oWb4kyzX4C81SI8pjaUM/rhlSrfXEWrNLOye8yPifPAH7dek6E8sx7LWJdsEmq/XUtgyS
xIoHqRjEM3EAWqsxeW857fbPW10I85joK+tABOiZByI8mrPJ/RIeYALsxzRghpdqv1v0X1t7
3x1cnOMXojY0eKP6Q4K31u2g3R13bwfaj81BG3rLzaUC4MFYe3cHb/S1OxiNL+vwDpy+Vi+V
On7XBmPlVw0+woTBmFBqBEejgPpT/WKT/ktnGH4zrG4Hg94AiBSGAnud5kCDwmh9eAGeOKXd
+aVH2Levbmg2Gu2xzdaP3UFH0y6pMAD32uVp78nieYU8Q7dtGRCkJEz3l0RPZ0j5ynJCNnhB
RR6GLf0gPjyySmfYsuevyBBp+j5aTrGyaOwuplqwmFQ+eSVQvu9bhuf67iyQPht+LrVqrS+/
lG5XgbW0/sFKguoy5EnhBCIpkHVd/rr+Rn0rq/U3ZCn6dHFOJ4vVs2fNF8Cq9bnEGLfITK7j
aUeWpKZtSwTLlzzkI+8BmdjUOF5B1AMLYti4m33CI8faJ5gA0Fv4N9Jt4QfhtkufYfgePYeT
07qOgDn1HUbNVWlHQgLVBo2/kdrRBgkWrUJEy10EqdYf5yPHNS2leqfx0BlkwRJvZCVq5EgP
b4By9FKDv0BOJkSmpcPko0kL+PG2JZ4euAkUXskfjETFyySJC5sxg4V4TJRhrSgRm9/oF5vi
yDeb5jbfbKoDVvvzZJyVDM6DMUlN5KOk82HomHj31IpTtqdXQpuJraSxGW82IRPULHDWRA2c
MtMwXTiNs4+rUGrZ0zlhycjUGJm6hyzK7W7YaTXHHQ1g2vW7QQs32SjKtD9qaYPb27tx1Fjt
dlcD0YwALRRPPdYL2j1WikG7c/XuhnyctandPXjXv+oMN9wN+vO70Xg0FrqnBWchwKZEWE7a
z53hoNOjlQiTV99COkfpb57J75kx9QMP9AGFvv8VU6fr9h53/H11pGidH/0z44yi4tlkuwIh
wA4LMDwLX67D31FYhTeASKtCAbdm+Iv1S1h0NVX0mx5ASVE3bOhvhqDaP/fb11q/+dPtcFMd
bTQe4qFYV7ZQuoMdKPVQswdgS5mWHVbl0Ty/qH/N3lVclUguFL5wl2ile/rSD6efHBU5edQ9
7KiXF8BrIzeVyU2e6FgOOll0a+CYnzvI1GbgxJeNjMQl2H6ukUo2dD8FM3cBoWQeWiInICk4
K9vyA81ENgrQNmyOAk13wNmCEsgOetwGrNyVtlr7i20obCR4zwREthTCPBgA82FfKXTyJN+4
o0zXsxnyKI8kdFNSKEOQSIryYKBYRn6y7n6q4gwKZvg9+4wYgzvHuA95MMB2MhEOlhIDRaUI
O8QoHDh4nITjRo2Pmx5LV77P7jWhxWny2IGhJZoeTUyhp0fR5VtIyh+DKscYVLfGoBobg2p8
DCbGnSo+7uSNa9iIXrWZ6cY/V9uf6Al7FwkEPQTGwiGvcycIpvYGb7qmo2uJlrD1Fqc20YNl
IBhqAfJmuoFiFKm0ON0C1hs+eIS2CqZD9qF5t5XHdL7ygEvYgzYVxL0jW23Q9JTeoAyYWBgS
UyQRNK1JaFJClWxxXW247tItLGUzrja0rClCpJTCYWCmcSg1bTaavqV+GIRkxT7j1LSlE4nr
kDiljigNbWCGktZNyTRWV9qHkuk40w3UT8k2o7Mx9LSUmfNRposQptniddjHkwltS/ExCKtU
slczHKYPGSwu/p19X9Apgysl1WDxJNXcddBgzkeKGC2rCEb3BpRUp3GuvP32q3OwieDx9Rv8
eAuPi2/g8aaOHzj12zf4AQmqqnx1rtQJDB6qEj2+/kbC9hh2a4LjWV/bAcllqRsLy0F00x3K
FhjzYzqOgMVuv03Pmno6RAf0dUefx5wkb7d8JIc6aYq4iLOqkjXBEYdd+VlRbVlyZqBUS87B
LD+LaBIoIZ/tGaWMtt8xHZVaEVCNZbLfzIpl5kG0dAkZkPm1vJYm7EuSP+FdsmDwswy5MGOj
PNnvNIbKGGcso5JammVQWnP75Wo8/wOoO2ZUlsa8nOYldmiJssfsSy36xqwuLYN4r1e/Ty1F
BTckEyY6l8+CpmKrnXMzM7KK1YJW8aE7hiUsLgjb97+S3601BoFsrzMIiKw16BsgN0IhwiuB
cclxa9NcKCBPEB/7IIRpVgVoqGeBn4y6FPjxiRNBTFyw+ObHp04DfvwMh4EQAyjgYQziHgFh
wphDQEyucTVFCKmm8pAe4PABm6oCEXZEA8EcKgEWBM0JkaInskjvgfrDuYMSLiOeXpVwAFgY
Ujq4xaD6Jhys18sPDMsNM4WSbgW0EXGElSo1pn5XzfLrkxvoloqp9wxSrjNbOq+/hW270a8j
7W542+qMRuDSbg5h53HcaY3fDTuXn3zyCdljhl8pxKTBbzgljEb1n32cTNJ/G407fa1127+D
ol71OhrUodO/6v2mDZp9wi6aZuT3dIKWR89+gJZY3NBrpzYK8+rlMevxc6NFj+gjpz8kkvSa
BwGXbrHgepgUX0NEmkhAWrRzHO0aS6kt4x3bwft2gOP7u5l7urgKRw6f5Gjo3IiRAxFywyRz
EXB0pBz1R+xRPuogB4X4Kgd5/oxWje2XPLb/P6HRctRhjfSCMBw05H2IfHftGSgdWXohK/LF
2/q3cv3wpaHAWhkH7wpp4zCK94SCZ5WD5X3YBlUUvCskx/82ipejgPnBqVyRulxIMByPhASj
cSs2djsClgWj7o31PDiiUz0g0nJn7OS+QMjCEY2CIYg7QwzzIwu3YwdzYwb3xwlGYYC7w/5Y
uB8LsUuFyIlHRtHYJ6HRM3mh4UxQtTD0h34UjI8Q9buCeZuIY+B1wzr3u4MTupsdZN0mzoMS
4xNq/Q5Y6w1wJNx0LvFDikPHnV/Hl3KAngIKHnXI2Gh0B93xVyaFwcBoDDvX7KPbIh/lOHkx
20Fr2Ol3BuNmrzG4pTAPNih0H9GPwW27c9181xv3ulcU8v5X+mui6Xoee8V9s2E8fDWzntar
r1ZwB4ROUx+ouBsw01KA6ydBu7sVnrsm0NAbD7EbYAcd236uzdYOCRNY6ebSAm4UujKn+FYK
aBo/lPS42fq5UX86r8Ofr+pPCvyEBSdHUOm7v576ZDnTcPQAwF9dyBu0KYijQeg2EOhP3nPj
+omeYe3gL5JQqMMDIZ+PnPn3hGk8JJDPli+en4ymFqHBPvlCdKuCdNQ3L0ZK/fNiNMRHLy5G
cIOL0VBfvRhNhr9emAkU9nAmcb99IeKY715c3kn/Pb9SuiLb9bcPUG3bffwZu+35iZ3A9e89
xxajWuiCBI9LCwBcNOFqlxLiNe/kvTnrmV5x4piG5GISEw7Ycr4+Q2Jkj+YSbhkQoxkG9gPi
q2NEI8v4L/vW10/afVzM8bUXuSyArDY2sAgtpjQbUn/U7Uky3JuwdM01XOwAC2P6trlnySRX
J2CrFFbNa8f8Dlsgge6F20zOfZjeG7duvpN006Sv+KamYIEoBl4wwlYK/kA4wYK50n2giTAZ
guqHBTlgGKiypiprqrKmKmvKqqypXJrKmqqsKS6DqLKmSrOmhHY8mINKzKFH0XZ4qkQ3UCKX
lVrcyDpsx0TdaWSpu40sdYeRpcaNLJUZWWXGJaaMLDVuZKlJI4uFMjIjS91rZKlJI0tNG1kq
X7dOGFnqTiNLTRpZaqaRpcaMLDVlSanZZpe6MbJu/JgKIQmHDQHMoRCxhw4ghlT+RtgxqfAT
byYVMaqFLkhAJxUxmqRKV0FJZk3OVF2GqWLZbJokoqJtcKor1kqZVsq0UqYixJUy/Q+V6Q29
CJhECrs0rOMaLl/3F6A458k0JY2uZKJzx04f9ebmMmOn2c3NXBWDi1lh/Vx+sPsBIe6smFVA
OF+sqMDtzFXQ6EsOGuVo6NyAswMRcoNDcxHiAeGvIiYUGuRFxYRGMZlC9TiBmEwoYBWTWcVk
VjGZhWIyYfT8f2Iyj2s1UnP01dqOtHoZHWMbqTIgX7wBSRvyxZqPBQ4fxbuv8d+fiREKGcf2
pkD7nd7/IxBdRC9QC3bVfMYF70qGranstzWVHbYmAYsNkvy707muaudC4rqqnQspPnDysZO3
v2df8X7AHe2Ct7KL3bNe4EL1gpemK3G7VInbpUrGdeXp2eLod6jvvxQ9uv187+3m5/FryvOu
IbeSt4+H6b3t9GtTYKRNsi4fp82VdV3yB76y/NBrygE/OU8ZEgZvwQpe9YQ3X8RWAvzBHMCo
Cuao9h9f4P4j/xDAHAoRe+gA4mr/8QPuP0KTVMEclTKtlGmlTCtlemxlmojOEHR/MBtWZNUQ
99py2LEUMdeKrc59cSve6twXVbzpw125J8E4z33l99vkICBcxBkwx/+hHKpTLyd66kVsIki4
JU7VTK60daWtK21dnEOlrV+Ftv6godMOOu2IaQflB0oboPoN15lZ89ONkmZlPHaINEjoVYa5
QL0y1F6YWgW28Ae2nLW1m7ve3S8aiGN0cYpxLg56BfHRpFeKXjGI40VSWmIiGJosHhFzmGf5
ZIJVhPZXsah5utxGzCwUhreB/sM4mNyy5YeQcMW3cCFVwSiHBKNofSjwfx6L0r4bNe+iZJ7/
tj8RofIhYlJye/3kJYaWsFqFcSVxwGkfTHHQaZ5HcVB1DKU6hnLgMZRtO/p/eTLFQa/tQAq2
2o3oVQue4l/e1pdrmfFPqpDC0ywUdvgN4/kzGsPAXoTEVqnAYqLaJ60876HnfYm8OWrIHi4B
FXiOR/7b0COvRj73wNdhcKGwds+OvrQM7JlPeuShT/quveMqzfN68i7NpW45reF4hDed1iuS
wt25GYaYY1w3H0BPfK2KOX3pHYN8VDBzh1RL/wE+eGj2uZdZTaudvUq/VPql0i/H1C/q9zG7
iHwyw6jAhlTckMrd2fEX6wDcmg4YWae7tRMrZFhBZhoKW4PYQ5nmm++mPJo/4FB9G/oDuOvw
HzpM8wuX7+fkcoZyIVUe08pj+kE8pvnd/kW6TGPVCn2mMchRTuLl70inA5c595uqc3filnJ1
VKTsoyJ8HR4TitB4SJwGUkVpwF4tROYVIwODthAdNV+qAy9bSw9BMtPyeY7IwDMVa8d7Iz9t
rVP1r1SzRjVrVLNGNWtUs4YA2QeYNQSvxT5kfcKxqouh7Ng3FPE7VRuH4hNP5dg/Ccc+R++O
obxu1z4nmY9AhlAxMaqV++iBxTqLqGJiPVU7ulJnlTqr1FmlznjUmeC+5959zkfdChx3hRwT
gJbjg76x0QOCCp7u4bzsMgu62vGWZy7PieB5mAN2QA/1iIQ7oEWr9B9GSQuXNT9KmSsomgup
inc+JN6Z7I8KhzsfO7Y5uT9aLOK55Bhn4VHwIuOes2sZhjNnIxy+mSou4myKHa6MA+aTaiNW
fCnwSl3q6aXAPld7eimgxpcCanIpoO5ZCqjppYC6eylAUgp39mwKMc/yZqEg5oClCwU+quRC
gYeG5WTM5su5F8spu+Kn6pmo1FGljip1xCfRF6eOhLaJ/gVQSwMEFAAAAAgAZmFUQjeoLfCg
EAAAZ54AABQAAABidWlsZGNoa193bGhfeDg2LmxvZ+0d2XKjRvA9VfkHKi+51lgab7xeVTkV
WZIdZXW4JO2RRCkKwcgmRkAA2XK+Pj0HDAhkBh1Z2avUBpie7p6zD7pH+OJ9u9OsKa2FPrMc
y7lRjNr49gYppuVjI3T9RyX0MVamrq9MLRsHSugqhjvz4Fn9+qvqzxdzyzYJ3Q12sK+H2OR4
lsNZjRfY8QxL+SH5HyH91pnpd1jFC6wcO67t3rgK7U13eHU+DF1PVY4sBtGu68PhOblUlF6/
0+69O68qtNjvdX6H5279XavZHmiDVqc+an9oaaO+dlEfEtj5t6StiHFNufZdAwcBH6ro39df
IcnB3E9MLTACy3P9cHlU6H8cFVo9qmxHySTAwnmPChuuajmL9ASM3cnfxu2d9mDfaouz07F1
ApcYeQrtcQaMc8wg21Yup5hqSrtSpTNLGFp6aKkUFoT6zAME5WhaqmvKka4AWDkylR+Uozul
qr5Vju6VilqtqnAhvIeM9U05vn9+wH5guc5fSgDCAA/KgxXeKk3fusc+1J1X0DGqwL/qyauo
NXmhoFMGIkambK+lI9lRsg2yi4dSi7fetkiuYnr5ULx8a3Jebx1l9YGD91sNQP9gkQuFFxZY
Yi6FGmCck5woJJcBr1pD+kt0LbmBJOS/DOd1N1AJSSmeuZICIsFwvWFVf25QB4A0913PHT46
xvdRu7Y1sadmoJ6OA98Yk41oYw18CQ0cCO3Bckz3IdDusO9ge02VF9Uc08kjLM278ZvTCnTt
9OTsJ7UynljOmDAiM6+aeLosZlUuZsWila8Z1xgrWaLspKWN0XZ0iPzgCvUG9IlMQfnR1pRR
fXDVGl3XR78qVqCo6jH8g2U5ZnrIVn4pzzR3Lxu26gcelaqZrRwH+hQH+FY5NuCfO50qx42F
2DBtSgJ3lfyvjsGNnbnO2HIMe27iPNjYm09sy6BVoq9QS0CFngTgNGrjj5bTbL5L7VDCYKx7
1oYIsPE3RHgwp+O7GVzAY3oa0wAX5fiPmQIX6FVT+3R2qp1X4YkMFB7gaThqao16pwOPjX6v
2R61+z3t13qvCdvxiuL2Rtr7a3hij+3ecHRegeeP7d4JOq9WyLPWG1U/aVDgFb0RpdQojsYA
lUXlNKr/0BrwssBqtwjoDYDgP85e67TqPQ06o3XhAXiSmmbrQ4eyb15csWY0JhL1xq/tXkvT
ztl0QM3ldf+8AjSXbuGyj0PP1/BsboO/oEK9kgHqwYwIQtcyfDdwp6Hy3eB75QQdTaxQaRw3
fvxR6XuhNbP+JfLI1Ab2Fa6rlepPKizOSeUNequiyhv6anZWgdaZZvYefevmFng2vldECw1q
53Si41VFqdu2QrECxQeB8e+xqVJRt8kIv9mOcB5/Q1gCwwa7d0fs/l5jT1wg+aMa3cXDMfyD
vXfMAdvpFWFWKHdbQgL52xKSwV7ghOTxEhkRLwgB5MWsEDLMSBCjkpBFWhbySMuxTEYAIZes
lJVNjifkU8CyMkp1dz0I8GxCbGNtpbSskmRSx2VZFC74WFfLNKmN5DpmcT1oNeqjlgb12uX7
XoPM3jDm1B02tF6/fz2K563ZbGswwiGg8VFW4lky2O0Po/Zg3Oq+Fh5xgM3v3hl7uHrk9xnD
ODImQejDXDDwx0/8/pqj/cvut27o6aFxy0qtX4Mj44hjDKKHS34f8ibfsHvf5HeL3x+PIgQx
09q71qDX6rDZ4+B33eal1q3/1h9Ew9aGowHZWZVqCqXdy0GpvGU4D+br08qJeEa81fDRw6Zl
875cFojf+EH3ScBKZTOgjnUybTp1YzXdtm4cbGpTiF2pxorKmW7brpGpNvQgAzPzgNARH8+w
E9Ia0pRtBaFmYhuHOA27waGmO/C+gZeQHfyQBniup3nz4DYN/WeO/UcKgqc55m0IAOEjShl0
eqVlsq8m8+kU+4zHMjTqKfQhXKqK2xCgREPB8tiDzMAFFCT9ThRjxvBiZNxxHgKQrqaTQ2ZJ
gOJekI2weheApmG+Z7EFj93KHdhotJGNRpGNLhwEMb+Im18UGVv+SBnlObwE/oQjTKqzzjAF
yzjEgCdjVreCBGZ1S0hJJ7kYm1pqlLLUKGmpUdpSo9WWGqUsNVqy1GjJUqNlS41SlhqttNQo
x1KjFZb6CSOMIiMsChdsGE8aYRQb4Qiz2REses3WxfsrWjhqshfd3vvuBfS0yoFZQ4UKTDla
MuXoKVPOqskGT5tyDrD53TtjD1eP/D4jGClTjqgJ59X/srsw4Sg24RxjED1c8vuQN8W3ft/k
96j8eJRGuDQLxXHMMLNWXSxo1pqfExko9gWQhC+AEr4ASvgCKOULoJK+AOCrUQzfiB+1qekm
i166iBckCkgh+B5WxKGPN04YTuwIbzJnLsAMzyAtlqQ28b1lYPAHQuxPdQMnKDJ1SbpbUO8B
BIKSMLoh+PtLqo3JjQc7ifSRjDEaIDF5T/g2ol44NwyY9W4IWzFZMVbW3WFVS/5Oit6L6PMc
IFETGX8GybhAMUuxQgJTuEUMlvSLGCFfSFErmkp4SQw3WmlRSa8MkPGZBDjrNDF+bPGX8UQH
BCzZC7azGEbKnxKQ7EResdQEc0NMrKrUuK/cmanwLSCTctIpi8uis2m3TAwvy12gC+q018bo
l/e/QBTTkR0ZDw2QfrKYKDghyrE7D2siwEgVW+ydUIT2FSigVu119e3Zq9eg1OFy8oZc3sLl
9Ce4vKmQC6k9e0MuUIFQVSHvXiR6CCFkfW6HlNlMN24tB9csUKJbi2ICPfE3szGhjjXxdUjB
d3VHv0m4l29T3uUW4j7bGccK35tFwXbcDlN4u2wJlOQu2Zs75h+r7203kjYEW1/sHBOyuyGA
1toZ78is7awBqjq3zZ3awR0tLeW9izmnjHc5H+S69ekQTsGO5jvXY9m6MIlWdrG0gvtu1jfY
oSoLdq3HhCO3G847WE/q9e1qvgnv3XU68ml3wz25u9HPuW+HcYV4PaTA/HeCXM+5OEjAqogr
LRM5jV1ZtKYru2l4dH13n1J//ETvKa+fQlKeP4MARo3PDjxSWPEELSWH5c8jlkEmL/DlCLyy
BOx9XJKGvYpLIrN3cUlk9iYqiczeryWR89+gSywa9GsD6uT7cTmqhI4oMYtJJRJrHaXhY6ZG
bCa+0ryovgArpwAKHC2Tp8ML+h7cAVVF2gWVuYtj5EghZ6T4+cpen4Aq0YmpTqf47FThkVno
aerMF50LPqidHiXPG1nxeArPgiU7SneGb9B+HdnK68pbCMQPPw2160G/0RoOIdxbH0Cgf9Rq
jN4PWufffPMNrDJcFY7HTocROD9iGTwGpJrW/z4ctbpao9+9ho5edFoajKDVvej8rvXqXcos
NgnqR2ZM1eFjEOIZmWzYrRMb87Y6Rcw68txY12P6OBwOlbT+2IcTie4a55PBer2MA1XrnKeK
Ez5xskfJZHpysjxPZXiS2Z3VmR1oe8uHAJPr/TxPA5Izfmq8LUkIdotiDgrxRYr50+bsIN0v
RLq/kCO+arxvjewrHBcc+jzAgTv3DZw9+nKqVtXTt5UztbLpy1x14/Y3y4vw40LyKv55nRtK
jmbfDhAl+/ZyThLt6dmgRE61ZFAIDHo6JSoVIoKmQEoOZ5K+6DNJSQkvdzhpv44ZwTj4kZyo
kDVc7Sj1qts0BrDDTP5xtwVOdw3iAVetc3JRktBR69PoXA3xImTgYYvuwVq71x69MhkMNmBt
0LoUhXaDFjaKrBLqXmPQ6rZ6o3qn1uszmA9hfz3ArNDrN1uX9fedUad9wSAfP7G7iSfzm8Qj
WbWacf9qai3m3ivP1EOd1d6zWa2dqrxRN8iApnOHJsQ93YQvHtR+otDol2Os4JkT8okDmNiA
z9Oo3nhXqyxeV+C/V5VFFW68P/SnkpzHfBLQd4qao4cAfnWqRmgTGGWN0kUQ2A3+Y+1ywX5r
2SKlX85oVXkVDFQSkWcRYCtH4GPZFpZi25JUrKo0AYlxlyfy1iFise4SdCzeXYKAxbxLELD4
cgkCFvsuQZAf/y65sNDHDTkk4+DlKROx8JKzm4yHx5T55oH4smOgZ7QXNDndv4fB2u7DOxII
l6Z1Qje48x27FNGtXg7/YWZBWYqEvztSOvICOf5oTjumvzZtQtlJ8RDzAi4LUdGlqB7MGfys
vRTJILTvsdz4IhJVhX+iqM8X2l1yfpPvOuSn6ZkTisR5WPbAS/hJDCfripd6cRU++fquy6Yv
qHmuC8p3XVCO64KSrgsSrssWksIZ1wUlXRe07LqIPLJwXdCTrgtadl1Q1nVBua4LSrouaNl1
QStdF5RwXVDGP0GrnRkUuS5XQcp1oVUb7F1CXp7Sx+tS8hSnlIjnqHRp2killyK61cvhM5Ve
imRZpSJQVMUmsVQT0TJQIulsKHyR5XlkQ+MPIlWlBgZfIwEHaPfp6w2S1qKbhxSvTO5H9gtC
hyTQy0gCRet9SPGuEnOmPV6ssLPh5S19GuMg8S9I4tmSPk95XyP7K4a8F0lgnoSVV8LPMAkL
o9nbJCz07ZCE/R+SsM87GboHRzUOydjo24qy5otryk2TuKAhvoQk7jbMx2abPP4+n+wCiy/w
PfG9vazxqD5tPKo5xoOCS3hOxV+8k/rAnhSS1Af2pJCS3lQx9kv+Zt//8Tm+yNBUU4YmT9FX
8xT9fn/Ubwsf87OKPubHAZemrFSOV33mj63rqg8CPYePA6bGzj8VtwTLOQgnPXHJ6EdxKo7h
PZWIK04JSoQdC/tBmBSnBA+nmb7I00zJlGDh+Sbp00xl5YiwKEktYnAbkR/OfOzbmY9SCcq1
ddamIZ7DMYYXeYxB0t4S8vKUPl6X8nCMYffHGPgyUCKZbL+Dt/TnnHaU5of+FZ7GIH/hx3Cd
qXWzvwcxRB/jNEGm5om413aTnzCpLzLt+fRfETokOtdJdB41tavrzvUHDaZleLqPeU8HP/cD
DnRzGs8hCyiU1V4lAEW3Pnfu75Cx22LGTutC5z97wqx5Paxfi+rqhmm0TRNn6yXAhIQ829yX
GALPfyUBnz+tyxOahXaJe3TPJGkHg9i3bB106eWk6Q6Jt8+feEu7uIdcXJyLK5S58TNJpxEH
24gftXCRLPmpkmuZySLTVDwJF3HKyXjJmVlRTSjTCS/ZgMDh528vJG7sLAwa72ClGfZvcE31
STNs8iSjyyiOH4eBDnsf8yE8OvrMMkiUeTm6DJsrcO1keJlgcZbpiPNMt5zGYAR/sdkP5x6t
kdulorpU2Fc370GET1CpoCf7ybQcEdhb/hvz4B6eZUieyPIk9AktCoVSGLQMbuch+KcOaJf9
jVomOhmHLbNVBV5uQrE+ixhHYmR7FeRI9OsQ5ThEOQ5RjkSUQ05EnkWYIzEGHudIQGI7I3zT
XHdUcj4S9VmHVFrVHzzSg0e6Bx5pUGKzv1ifVI4qwDB3ulfubIHnPvie707lPpHwoFuh43rY
MQFoOQHoABvfY+jv/rq7q/uc/yf+Yp+4kP6Z//iv3MA+m4dcrpvFbq6ULyyFVOAwZ09zF4fe
WFX24LRMCoJb7IOjfnDUP4+jXk5Sn4XfvnpI3I1fjXD4Duvhlwvyv1y4Cgp/uSBhMwiVNIGP
SxJAVSkCCKGWp/HXoIEoZHki5pF8sb+y2OzLlqDugnV+FrHZ1yhLGpjV6Nm4yLru/iFMcgiT
7EGYpOSuXY3+coIoxvRmduPH7fwHUEsDBBQAAAAIAGNhVEK4MeHU/RIAADHbAAAXAAAAYnVp
bGRjaGtfd25ldF9hbWQ2NC5sb2ftXety6jYQ/t+ZvoOnf3o7MdhJc3ropFMCJKUFkgFO0wsd
j2MLcGNsaptc+vRdSbblC8SSgZSk7pwa67LSSpY+rXZXyvnHbq/dkDqP+sJyLGcmGY3JfKZK
puUhI3C9JynwEJKmridNLRv5UuBKhrtYwrv86SeubniS5dzrtmXqAZI81w0a+sI8PTHmd1JN
XwWuYSPd+XuFVujTT5Tvz1eWbeJqZshBHpCYtFgoJKx58oicpWFJXyX/w6SfOwv9DsnoEUk1
x7XdmSsR5vujy7NR4C5l6ciiMdp1czQ6w4+6NLjqdQc/nykSCV4Ner/Be7/5c6fdHWrDTq85
7v7S0cZX2nlzhOPOPsd1RQU3pGvPNZDvA8tp/j79ROVszP2tqfmGby1dL8i2Sn3BVqmbW5Vn
NN0J2mCsjZvDy85Y+6UzHHWvBtKoM5bGV9LNqH4MRQvkVb6H8bN8kmg3ypbzmO7YiXv7Fwwe
7cFBgUaG0oQ+Y4IpVBgWQrmOC8m3Y1NpYb64NIV8OVyopQeWDGzm4kg+P9AXSyCSjqbla5SO
dKnZb5+eSEem9JV0dC/VZUWR4QH1puoQ7pps0XeSIn9I1oBbMaIVzLZowR+/IM+3XOdPyQeY
gBfpwQrmUtuz7pEHaWd1tabW4Z9y/C7RuLhq8YaVq1FokgLcvY5JGjLKD6jQrwcNqMCfKIqI
5KVgQetJggWJ2Tjew2RexIGPwjl71qFLduYLs/gcqLB5J15s2XknCp/83ZduKS+4CZRfrsnK
9y0iF+G6vxi4oyfH+DJiwrZu7anpy6cT3zMmePDbSAMRSwO5SnuwHNN98LU75DnILjlPo5Qa
6VhcpHk3eX9aB9ZOj7/9Rq5Pbi1nggvCX0U20TQ7tZVwam87nQXair9XvtPSa8Nu0Ji/cYUI
DDzhLhBvbUOiKHXdHP8oWb4kyzX4B5+lJoZnIjgJc25hw0ypGVKt9chGSZcOeniR8f/yBGT6
hetMLMewVyZaFzdZrm5tyyBJrNmQiqO4lnPI12pMbiyn3f45NTZxIRN9aW2ZAYb8lhkezOnk
bgEPkJqez2mAnCDVfrfo/23tpjs4PcEvBJk0eKMQJcFb62rQ7o7h22g/NgdtGIaXZwpEw6f7
eA1v9LU7GI3P6vAOJR2rZ0odv8PnVX7VIBAmDMaEUiN5NBpRf6x/U1dpOoyBMMxydTs46rR+
LBFmaGSv0xxowIzWhxcoE6e0O7/0SPHt80tajUYHWrP1Y3fQ0bQz2hmQ98Ll+uCT+dMSeYZu
2zLkkLJxur8gy96Gbj63nLAYvM0kD8OWfhCfeBvZM2zZ85dkljR9Hy1uMQ411vOpluST9hAH
C33L8FzfnQbSF8MvpVat9fXX0tUysBbWPxiAKE4iTwoXJ0mBuuvycf29+kFW6+/JFv3x9IRi
6vLJs2ZzKKr1pcQKbpE1UMdLmixJTduWSC5f8pCPvHtkklXasPEH/oyL/9pnmALyt+BL7rIJ
MURBuVu2B4oKf/OghuOfATucnAc8Es0LejhvIa7tKBPg244yJYGwODeAIc4U4yAOMCwMQySA
3zcgIk6KUDEKMWAkYQaOUZgBJMswGFPy9UBJUhhYsrg8YOLoTYiJ00LMZIHzsBmbsTNKbfcY
2aDdOf94SQJHbSq3DD72z4E7hUZiDrSfO8NBp0dLjSu/HnZazXFHg5K1i4+DFu7SUVxwf9TS
BldX1+O4M9vtbiQnhE2vx10XjurfjcaDMdc9LTgKI+zwd/ktfbl8omwZt37gwbymsTfwbZUI
O3aH0RHAdH70j4wjqIKATcjI8Ch8uaAJ/XEYHoUsWzT+oxalXJk0hoFLAh6urCgcRlz24oga
/IOhXksX3N1dQ0McNblABTPOAxhcmcjY+LnfvtD6zZ+uhvEAUYrpKZYw+u4gQf9BnD5ZvzYa
DzEw1Dn4iAGI8ZEvp44ZyoJUAKu8adnhQHowT8i8VxLwFYZIgOVS39P3ubtAS93TF374AQu6
e/Kge1jPLs+h3GehUI60X0b8qk1NNxlcpoPoEe9wSQy6D4y5Q15nThDc2lG+25VPXhdoAcr9
JLWJ7i0DaZYTIG+qGyhBkUtL0s1hyfVh35ZiTIfqwwGfquN2tgTIwDzS5jO4VzJwr2TgXsnC
vZKCe2Uj3Ctr4T7q2zA9D/3KM9CvJKFfSUC/8iz0KwWgrWRAW3kOtGky5j8N2mGEDb8RaCsh
aCsJ0KaxN7/CbwTeGZS9HEYvF+HvKCzzPfzGWMpg87KXTl+zbCl8U51nFrOJq6QmLpueSmZ6
KuLTU57ouL90ogXSwMo1c5CpTT0EM2BD4gJ2DK6RSzZ0PxdnrosERjy0QA6dx7gq2/IDmIE2
ClA6boYXBQd0WyiT2UEP6Yilu9SWK3+ejgWrXAgBxD4X1sEicDkslMtOniSMB9TtajpFHi0j
GxtxCjwEmaS4DhaVqMjPtt3PNZzFwubtjgXjgkHnaNyFZbCIdDLpHNxLLCrmAg+EzaMApz4z
DFg6Gwc0Mj8QMCwxnI9z5UcGTcoMjRT9MqJfN1ZYStRPNCY3WuIi2eLCcrIRRONSQ4jF4OJp
OeGSxJLy1ORJc9NViybmhheLzo8vSk7XrWw+1lYWl+TCz/VntEyyVNaRYVUbl8+USliWZRxO
jtQ4zNhKj1XWkHzpLDujTg9lSp9dpFnGqOGCKhjMu1QDgVequaugwZSYNGMsCpMc3UuA8E7j
RPnw7bsTWLXgcfwePz7A4/QbeLyv4wdO/fY9fkCCqirvTpQ6iYOHqsSP428kvGZhNSYosPWV
HZBaFroxtxzUCJWMdmDMdqomgjIiJc1a+Sav+uhZt54OvhN93dFnCYXHh5S+Y1vVRhkl9KZG
blzoiObuBeqigLnv2gBo912F+QJ1xEvBPipKLyx7GQBrlqX9NgUwcq/lR0vmXishgL2PGsi6
u8fPTcrf1zcghe+7b/BzL13DBJE99v9aSWkvE47VtK/PzWrY3zf39wx//ktgHxM191f6nr4x
kU/32f+4/P0yH0nh+6shOfrV73MKNkGLZUas59NC02Qs6vOaO5koXVJi3ta4uYctCSn25lfy
m9qZkJj07oREkR0KfYPMjbAX4ZXE8XVkyrIu5k0pSoC1EeJEyzJEVMkgQEeVCgIERK8g2Gmw
ARcgoCoDAYINCgSxEoDHLUtIqgnEKRM7YsHeTcIWoaTI5SE9wE4DNgUGofIIIsHSKkE28OAT
o4UxiPG6B4CI6wdc3sfJBFXC7mih++zgCkfVI+e0Xq/YTa3QpRY4TbnXkf4IG7XX0wnrWlbc
nkK3u5c5nQAjzzNIe49s6aT+AYzvo19H2vXwqtUZjcAc0RyCVWfcaY0/Djtnn332GTELwq9E
c4aF45TQodR/8nEySf9tNO70tdZV/xq64LzX0aBvOv3z3m/aoNknxcXLmXxDZQF59OQHaIE/
I8yHWxuFdfWKCuvxl0ZZj+mjnsH8kPSaB26lbsnTArD6vgX/OBH3uNjBI3bukHKeHWu8Op4z
DiYNg88YBSVpx96cPF+60MVgywyFXpuFGbCzphwPSKyv3ek0B6h9k9OcY7GsZvdrnt3/I19t
OR6xRn7zGU4b8j5EvrvyDJT3Vj2VFfn0Q/1bub79NlRgZ459icUAOXYqVrZu53YGqkN2aubp
SObdnHJJfiGnYh4Oi31zuRyHuTJxOQ5zZar8hd+ov3AJTwJhbSNIWhmTP7fy0bnDuCjs1sz8
j3N+x1l/48jLOPwNw5e9dPqFKTbLJ1xOsjz+r5tcXnfr2Ar5Y3HbkHA4CuTXpG5kytZtop7Y
o7dErd8Bqb0BqorLzhl+SMnYcefX8ZkcoMeARo86ZHo0uoPu+J1J42BuNIadCxbotkhgP2pl
XOygNez0O4Nxs9cYXNE4D+wiuo9oYHDV7lw0P/bGve45jbn5lf6a6HY1S7ziz94w7t9NrcfV
8t0S7uvQaeo97e4GrPs0wvWzUeuPlOL1a4LHaqSTdgOsBmRG8Np05RCHhaVuLiwojsYuzVt8
hQh8Gz/s6nGz9XOj/nhSh//e1R8V+Ak5J2du6bu/uvXJvqbh6AFEvwMWVJp0C/3RwHQxIQwo
76lx8UgP7XZwiCSUwxug5NTLMyWiOJGHRGpKWQAE6GhyKSJsCShHuCxLSC0CgrTUKiBIRCwD
JToTNO+CRNRCIEi0wUogXgrwu4NSktaCctQJi0GJXs9aDQRg6px4D1zdQ9Nt9+FnbCwQoHYC
17/zHFuQbK6LUjwsLIiJieLVN0cU74QpId4PT27Mac/0yhMnYFOQbScA8cnXp0iQ7sFcwG0L
gkTDwAY2BYlkGf97sOdhWF89anfJrk7uzMi1CWQrEsUJ1uaj+WppxkQJ9G1I/VG3J8mQd+Ga
K7grAza79C26YsskN09gARJ2wivH/A4LNIHuhZYx5y5M741bl99JumnSV3xJVzBHNAfeg4Lt
BwcQTrBg5XXvaSIsrbCIwCYbchioEs4q4awSzirhjJuwEs4q4awSzsrIV5VwdnjCmZBVhikv
BVV5NN8aLaawlYepM8tLbduaVdZJbep6qU1dI7WpSalNZVLbPj01c1KbmpTa1KzUxpw7mdSm
Piu1qVmpTc1LbSrnAM1IbepaqU3NSm3qRqlNTUhtak40UzfLcWoktV36CfghCVvOAlxEOWoP
bUMNyQIfYs26JEAdrUuCZHNdlIKuS4JE2VVBBZDduMpTvA2TBSuKPo0oWRql6fc71C10BcYV
GFdgLEpdgfErBeNLeu008dV2qevLBfwhAX8OwDvLpin57MrG7Nze6zu9tnuf3uuUUeGbrnk6
AS71BW3B/o8mbHEggbEp6r6/S1/dN+2Sz3nHdeW0+5qddnm+dKG335YZCp1zCzMkXfLfhE8u
fBEun9yD94mFhhy4TyxwWPnEVj6xr8Qn9uCcTWH6/H+cTXcsO1IB9s1KkLR5m0ZGOlclRr56
MZJ+yNcrRJY4ApYcv8Z/f0JK6MAEljpFPmAoc+70LzNs29xQ5hRpRu2z6Nr3DXe3KxskTuV5
iVNZI3GSaMF5Unw9Of9d7AqPKLmTTIm5w3FRO8yf1OXpm69If+Za8//0yu8XvuY7kk6VpHSq
rJNOlXXS6UFeFi50SbhVcEl4GL4wRaYanvTP/LWCTX+I4DVePJ7qj/Aa6lRcySu+sH1IcEPA
77ICJVUuK5WV9FVaSQP+WYCLKEftoW2oKyvpy1tJ4dNsbyWtXFYqMK7AuALjCowPAIwzPiiC
ShgmRQttXJLqYw5JmmYslqOrA3vc0F0d2AuhO38qr/AIH+eBPY6Rm50HpJgSJTAjxNZFVAeU
DvmAkuBSwlsRWxPympVDldMrsK/AvgL77YqowP7/DvYv6qDuoMP2Swf+Cl3MDVg5DNeZWrPD
9S9nPIp614vkFdgmYlt9jrdCQ/1ufd2hljfpqQTt2tSTYXLlm8Tvm3TU1i6ve9e/aNAdo28O
0VXJQW/B0Z0MS+OAnXGKceo/9MQpZq7YiYXLw4YrU+UOs407jNYHhv9zb5j29ah5zZKVcj4y
e/aKKR72k9fo3MKaFXq2JCJe91kgB73uI0AOOtCTPw6qDvxUB362PfCTFnb/l2eAHPTmjv5g
0dqIX7XgMRnyUiHXMpNBCknhuaGoJMGtPrMI8y/aLAve7WeMwSKag4RHZdz66pr9ylYAsQvk
zVBD9jALtMcLbAjfhjYENbYSBL4O0w2FzXty9IVlYFtC1oYAg9R37TWXvp7Us7e+LnTLaQ3H
I2wnWy1JCv9oZ1kEFfm6eQ/YcawKKo7pBZjCZAv/HlZ3DXJCVx5jVotU65A9RStYYdl7HTNW
UNa9lQm0grUK1ipYewOwpn6fEARpkEmCJUx+Gcmx0Hzmz1cBaC8cyH249rMEk2JGMSFVCZOU
+bYjNHmNuySvxqU6byS+blQu7nt3cecc85hSiMhDJYggWZgINpnl6LySdADW5QgpTFfO+vk1
VZTOtHwu/3545vz7+W5t52Vl7fJ+qDuWauWpVp5q5alWHr4hVa08r2flETISYCtxfq/FYSrO
7E4P2H+Io13/oQMRB3fFfj9czkFcmSoPosqD6EU8iDjG/at0IUq0K/QhSsWk/fx3e+KXp0sT
edZYeIXWguqwr/hWojJ+HIbxg2d8J/JU5o/dmD/gK+hL0VNSS/fBAz3GVJAsIxMnvuahqmQq
HK1wtMLRCkfNQmT7D3H0UvCw6YNuBY67RI4JkZbjA5jZ6B5B2w/3AOpmnp8zwoud8BQyUGMt
TSFvHEqbnWlotjUBhBqa0m36D33+xZkt9rnncvHnylR572/jvU/0N8LO+7v21M/qb8r57+/Z
Y198GrxKL/7NzQyd8zdn2P4i5BJ9vJlkjbpnm0WlcmES37W8VUNyftfynIE5v2tRk7sWNbtr
UZ/Ztaj5XYu6ftdCUsoP980kgpbUaE8jaOGjexphsrV7GrXEnoa3QmM6W8w8YT7ZJqMAVA9V
d1OhYIWCFQpy92mFghwoKPQ3rP8FUEsDBBQAAAAIAFxhVEKLyk2xAxEAAO2jAAAVAAAAYnVp
bGRjaGtfd25ldF94ODYubG9n7R1pc6s28Htn+h+YfukZYittmnomnTq2k7r1kbH9+nq4w2CQ
ExoMFHDi9Nd3dYDA4IB89Dkpb/JAWu2u7t3VakOu3nV77YbSWekLy7GcO8VoTO/vkGJaPjZC
139WQh9jZe76ytyycaCErmK4Cw/S6scf1b+/Wlq2SejusIN9PcQmx7Mczmq6wo5nWMoXyX+E
9FNnoT9gFa+wcuq4tnvnKrQ1/fHN5Th0PVU5sRhEu22Ox5fkUVMGw1538PNlXaHZ4aD3G6T7
zZ877e5IG3V6zUn3l442GWpXzTGBXX5K6ooYN5Rb3zVwEPCuivZ9/BEq2ZnHmakFRmB5rh+u
9wr9h71Cm3uVbWh6ELTBRJs0RzedifZLZzTuDgfKuDNRJkPl/bh2BqwlcOvfw4LwnhU2jKrl
rNIDO3Vnfxn3D9qTg0NtdXE+tc7gEWPPKYc6HWjCyNJDS6WwINQXHiAoJ3M5jsqJrgBYOTGV
L5STB6WufqecPCo1tV5X4UGYjxnvO0nGf/yC/cBynT+VAHYHJJQnK7xX2r71iH0ou6yhU1SD
n/rZV1F15XcJnS/Yc2S+jnq7JBsKi4UvAFYQL4DsGswf3phsTlhlVwJKrYQtWSeXRHotoHgt
bMt660VReouVlUwOPm6BBO3bWrZESyu7CstMkqSQkWGdXFolxIwU6+2WVmJDAuPkqFHI5moh
v8U+LMFRcvuV4bjd0NS/b1HjhdT32cAdPzvG51HFtjWz52agnk8D35iSpWtjDewgDYwf7cly
TPcp0B6w72B7S+kclZzS4SMszYfpt+c1aNr52cU3am06s5wpYUTGXjXxfH1j1vnGLN6M+UJ8
i76SOcoOWlpx7kfqlO9coaSBNpEhkO9tQ2Hy6LY5+VGxAkVVT+EHpuVUWmRL4CoLWzkN9DkO
8L1yasCPO58rp62VWDJdugHgrZL/6hSM8IXrTC3HsJcmzoNNveXMtgxaJIYASgmo2O4BpFZj
+t5y2u2fU4uUcJjqnrUjAqz9HRGezPn0YQEPMPBexjTAoDr9faHAA1rV1n69ONcu65AiHYUE
pMaTttZq9nqQbA0H7e4Epkn7sTlow4q8obgwi+9uIcWS3cF4clmD9Pvu4Axd1mskDTNd/1WD
DC8YTCilRnE0Bqitat/UECuH5cDzAqvbIaDz2pkC/zh7rddpDjRojNaHBPAkJe3OLz3Kvn11
w6rR2Jprtn7sDjqadsmGA0qub4eXNaC5dovnfRp6voYXSxusDBUQlAxQDxZMNdvKD/I7LL9S
w1b9wKN7oRkEeDEj0qaxse6+Zfhu4M5D5bPR58oZOplZodI6bX35pTL0Qmth/UPkARNb2Fe4
rlDq36iwMs5q36LvVFT7lh5rL2rQCKiY9afE+LCmMl3iPfvW3T20ovW5ItrUoupdJ1pJVZSm
bSsUK1B82OD+IzZVKpxsMiGf7GkETz8hPIFji737E/Z+p7EUlyA8qUZvkTiFH9grpxywp2YR
boWCYk9IIDD2hGSwA7MQFTxHesQzQmLwbFZqMMxIckQ5ITxoXgiQKC+EiEAYTBh5vjChJUKg
CFhWqBDwJqlCyrhcEZkr3o3N8oWURjImZnE76rSak44G5dr1u0GLDMw45tQft7TBcHg7iYek
3e5GypF3oBYPgMFevxuNJ+Ne97XwhANs/vYuWOLmmb8XDOPEmAWhD2uWgd//yt9fc7R/2Pve
DT09NO5ZrvNjcGKccIxRlLjm7zGv8lv2Hpr8bfH380mEIEZa+7kzGnR6bPQ4+Od++1rrN38a
jqJua+PJiCyaWj2F0h3koNS+YzhP5tcwpyKNeK3hs4dNy+ZtuS7YWdMn3Se+P5WNgDrVybDp
1KrWdNu6c7CpzcENqBobChe6bbtGptjQgwzMzANCQ3y8wE5IS0hVthWEmoltHOI07A6Ei+7A
GQqvITv4KQ3wXE/zlsF9Gvr3EvvPFASpJeZ1CADhI3IZdPqkebKuZsv5HPuMxzo0aim0IVwr
iusQoERFwXrfg0zHBRTU5IPIxozhpGY8cB4CkC6mg0NGSYDiVpCFsHkVgLY8iAbeRZ+iSJ8W
a3CiKhFXlShSjDxJOeVZ0wT+gpVNirOWNgWXsrYBsYwK3AsSqMA9ISUt8GJsqlVRSquipFZF
aa2KNmtVlNKqaE2rojWtita1KkppVbRRq6IcrYrytSp6QauiSKuKzBXrxotaFcVaNcJs9wSL
Qbtz9e6GZk7a7CA9eNe/gpbWOTCreVCBbkZruhm9pJtZMVnhad3MATZ/excscfPM3wuCkdLN
iOpkXvwPewudjGKdzDFGUeKav8e8Kr70hyZ/R/nnkzTCtVm8H6cMNaunxYxm9fMl2QTF2h2V
0O4ood1RQrujlHZHktod8NXoPsOIk9rcdJNZL53FK+KrpBD8CFPi0OSdE4YzO8KbLZlSX+AF
3BkmqU38aBkYNHyI/blu4ARFpixJdw8SPgBPUxJGVwQ/baTqmN15sJRIG0kfow4SJbbZWmHl
GXOFMRDDIpCE/RJDswYMK1qzYFJcvYhrnkkjSiJ1ziAZoyZmKWZIYApDh8GSlg4j5BMpSmlV
IpulJk9OzKaeFWasIAHOmkGMnE3+Op5owLpRxKjYymIYaQtJQMRA8qry1yCnuWFXKcxMMbGq
qin/MM8nzaw4zxorOrOhhpQVJiCiq2k7jHFcX/8CkQ3HpsYz2uw+Yacn0gHmjQX7RDl1l2FD
uDapxIsNF4rQvQHJ1Gl8Xf/u4quvQdzD4+xb8vgOHuffwOPbGnmQ0otvyQMKEKor5JhFvJbg
vNaXdkiZLXTj3nJwwwLpuj+XETDgjpg1Y7RnzXwdIhf6uqPfJWzP71Km5x4cOHvqyAZDm3nf
Dl0RE4YHrQok5kH5m4euIJbue68lrSj2P+M5OuaAnQC5djjmkeY7XA1UvO6dPVWch5pfyvwg
4045H3RIyHP/IyKsh0ONea5ts/9dJao5yPwK9gea5OCQci04uFATdt+BWB9iUqmZeLAxJ8wP
2OzIDD4Q++QqR99nTo4AzDeqc23nEg4EVkas6VK3irE1i7a0Znd1n25v8lPq97/Sd8ryp5CU
9c8ggNHgwwNJCisxQmv30hKhm1LY5NgvSeFJU7ATe1kidlovi82O52Wx2QG2LDY7hZfFzj9+
y8weNG0X8uRBWpIscYaWGcukUImFjdLyMRMrNtvM5ZlR+QE6TgEciHOTIMQrejTugfAiNYOw
PERAPlJIxBaPDx0MCagWxW/1esWRXIWxxtDSVAQaHQzeqYMG5ef1rLg/hZFp/1lQvm/Q/p7Y
yte17+A6YPzrWLsdDVud8Rh8zs0RXDdMOq3Ju1Hn8pNPPoHVA0+F4XHWBM4XU/AckGJa/tt4
0ulrrWH/FgbgqtfRYGQ6/aveb9qg2afMYtWjvmfqWR0/ByFekEmEfTCzMa+rV8SsV54ba3pM
H40LaQ8tP/Uh7tKV2ECgHd9GrNg2oWLxdVN81aRk7ply7pheul9K3i1tvleCuqsAx60CHNV4
4RJjdo8CAETWmxQApX/Lo5IEb0MSFE74jju+EKFwxxci0I0er0sje/nBtwhNj3DgLn0DZ8Nw
ztW6ev5d7UKt7XoNgnauf9eDK43blZhkHsB7jEFMiYs6WT8DCOj0RVs5rwNURsZChE9JDOSH
jKMqbFxxOFKpWKlSSKVipUohVSFSVYjUsYVIFW616SuJeoKO8AihKJNVn93oqle3qZfhgOED
p/0OGNkN8DjcdC7JQ0lCJ51fJ5dqiFchA487dBE2uoPu5CuTwWAFNkada5HptmhmJ18uoR60
Rp1+ZzBp9hqDIYP5cKmgB5hlBsN257r5rjfpda8Y5P2v7G3i2fIukSSz1jAev5pbq6X3lWfq
oc5KH9moNs5VXqkbZEDzpUMv4D3dhK9TNL6h0Oj35FjGM2fkcxQwsAEfp0mz9XOjtvq6Bv++
qq3q8OLtob8aynksZwE9QzQcPQTwV7B0ECuaQS8bhC4mhNXgPzeuV+x3Szsk98MFLdpCRwNZ
GWe3cOJJUvi4dB1rDvWyZKxMnoI41reg8raiYg52GULmZJehYI52GQrm0ZahYA53GYp8p7vs
DEMzd2WRdL5vQZpwwMuOcdIJH5Pm/8Y1MTOnhAEjvqI34sNH6LDtPv1MvO/liZ3QDR58x5aj
utclCZ4WFgBimlgPZmhi/xGlI06k6Xtz3jP9rWkTElCuzU4IlgwR3HJkT+YCfrtfjmYU2tBG
ORpVJT9P9j3L6suV9pAc4+RxhPyOfipgUq4q0FxLz+Q0aP28J2N1MaTswU/uMCxOgNtbQrsd
elGuJYTyLSGUYwmhpCWEhCW0h1vtjCWEkpYQWreExEW4sITQi5YQWreEUNYSQrmWEEpaQmjd
EkIbLSGUsIRQxtxBm20jFFlCN0HKEqJFu6xeQr8FqY+3JuUXs+V2bI5OKE8c6QQ5qntdkoDp
BDmadZmMQMyV0KxylUTTIUklhGTpy1/4ps7ruPxlDZX+ElKZQYDPxoCtdvib/R3u80UzZW+/
qwutUhdaZb4tVV1ovaELLZjwt3ShdZwXSjDIr/FCKb7WkejOB7/WgcZV1zrVtU51rXP4ax3Y
am/0Wmev1iIzWN+szci6l7sI0iiV4fiGDEc2pa/UbNwiNFL0+SgCp/gHFEvPCbcyD/P1w127
wq3M0p0RXyt84duEWRuz/rKNWc+xMSlYZu0Xfx2w1McISyGV+hhhKaTkfijGrr5vuNv3DSN7
tJ60R+t59mg9zx497q8k7uHriFbR1xE54NosvS2nmz6cyCZ20weZXsPnFlOd5x/fW4PlhIaW
H7mkDVt8XcjwXrwsrMKm/qdhU8nLwsJAqtJhU4+y65fwkCUXJ5jd6KtwkqMMJ5G5uixZiVSk
Rplbl0LRS7hUkRpbCN8qUmO3SI2yq5fQb0Hq461Jq0iN/yxSA6Zjx0iN4iAFB+/pL5sdKDrB
wdK/lP9il8nfYTJcZ27dHW9cimjjfv3mMJZv0mNe8NepKh/5Nj7yk7Z2c9u7/UWDYRl/c4wu
cwe/+hALujoN2cCzI3OTQyfegH8cWn50jnFoxxvyiFc+7g/v405L9crtHbu9izfd9JV4rolO
MeKkFq6SOT+Vcy0zmWWyivu7I05x/F3GOH3toXeiJ8cVdSfa9cED7qowuT2GyWl9aPwHj5Jr
346bt6K4vmPs3IeJlhNb5PUGyok+8GC5JIBKYCHAc9zdJUdClBPStLe7tEyvHN1vxNHtrAzq
a2G5BfbvcEP1STVs8Eq6w1Hs8A4DHdY15l14dvSFZRC3+Lo7HFZX4NpJfzjBiljWki7yhW45
rdEE/gq5Hy49WlJymYpyOS+1bj7CBj1Dco5W9ovwslSL4BGUqgaIMIhnUTtfuqgDdEEq6w2O
HdVyZGtO5ITxWOhgDe6XIfgjHDB+jtfDmmikrPNFmM4J2zjL9rUbx4muHJd1nGhYZR5X5nFl
HifN45J75FXYx4lOcAM5BUnIYiZMcq3ksgOSQMjayeXlOzeU8/8eXGU+V+bzhzSfC1dvAqEy
oHc1oGHwdU8y4sNzn3zPd+dyVGljfV0ClnBss7JsNFypS74qArmKQJaMQL4JCiOQy6xVQlae
wseyFFAmRwGuui2I/G2I4Pi5BRUzlN58xHQpmi0/gOeYVrBljPPhvln3okPmSbdCx/WwYwLQ
cgKQxzZ+xND/4/XPbG6znLuGu2cKub52b41kzz6Y80ayncUemFJumlJIlS+n8uUcoy9Hcsu8
CtfO5j5xT89mhFwvz5ZDtRk/6wPaWolUd6eV8+cInD+yy3YzfuUa4jTG/G5x58s2MmW6/wtQ
SwMEFAAAAAgAWWFUQpk0Cm2nEQAAUJQAABQAAABidWlsZGNoa193eHBfeDg2LmxvZ+0da3Pi
NvB7Z/ofPPelr8Ng5y6XYyadEnBSegQywDVpS8djbJG4MbZrm4T013f1sGVjwBaPXpLSSY21
2tVztVrtrnVnn9udVl3S5sbUdm33VjLro7tbVbLsAJmRFzxJUYCQNPECaWI7KJQiTzK9qQ/v
8tdfeYYZSLb7YDi2ZURICjwvqs9Pjs27e6lqzCLPdJDh/j1DM/T1V8qPZzPbsXAlt8hFARBY
tFAogtU7miPXN23p+/R/mPQbd2rcIxnNkVR1Pce79STS9MvBxekg8nxZqtgUol81BoNT/KhJ
3V6n3f10qkgk2et2foP3y8YnrdXu632t0xi2f9X0YU8/awww7PQbXFdccF26CjwThSE0Odu+
r79SS3bmYWzpoRnavhdEi71S/8Neqat7lW9oFl3vDvVho3+hDfVftf6g3etKA20oDXvSdbt7
cwUjJoYM/OM/SXQgZdudZ4d25I3/AvbRH+e+Dpw0so/gkSBPoGmsANrmpIB8L5aWlFBNSFMU
Mme4QNuIbJnAwsiY+oAgVSZCTZMqhgRgqWJJ30uVe0mRP0qVB6kmK4oMD9zyfH1qpr7NepKt
mNeIezOghd+K9eSPX1EQ2p77pxSCFIAX6dGO7qRWYD+gAPJOa2pVrcGfcvQ21b+ktg37sWm1
5Zaii573CnSR6MKLlwIlTi8FAlk+3gnyRJAjiwvMM2KeNcQK3IwjlB+bZIvC1X3b9QZPrvld
XK9jj52JFcrHozAwR3gKHKTDbqfDFqc/2q7lPYb6PQpc5Gy4C8U5VTJ4uEjrfvThuAZNOz46
eS/XRmPbHeGC8MjLFposMpjCGKyYqZZvVhv0FU9RftCyUmM3q6d85wpXDLQJD4F4b+sSXVdX
jeHPkh1KslyFP5iWquBuJrpcp45UDY0JCtGdVDXhz5tMpGpzzpmmTZYA/Mr4f3kEytbUc0e2
azozCy2DjfzZ2LFNksUHAXIxqFDsA06zPrq23VbrU4ZLcQEjw7e3RADm3xLh0ZqM7qfwgA11
PaYJOlb196kED2hVS785OdZPFXjDHYUXeBsMW3qz0enAa7PXbbWHME36z41uC1jyguDCLH6+
gjf62u4Ohqc1eIc5PFJPlRp+h5lWbnRIsIzukFDqBEengNq89r6m0HxgB5bmWG0Ng45rRxL8
x4rXO1qjq0Nj9Et4gTJxTkv7tUOKb51d0Gp0ynON5s/trqbrp3Q4IOf8qndaA5pzr3DaR5Ef
6Gg6c2C3lCFfygGNcErUoRXjfQYyDBeGjwDkYTrST+IrcWnbTEcOQp8smEYYoukYC6X6iiaq
GzWRjkxB7Ze2GXihN4mkb/vfSUdqZWxHUrPa/OEHqedH9tT+B8sjKjZRILG9SlKg8pp8VPug
fpTV2gdyeDqpQflUyPpPgX17B2U2v5OSGqCUAFQkA+9xsiQ1HEciWKEUgLAIHpCFldM9tEjZ
qkXqj6aD+e1N4bBW32BswG3iXybn2CspaJlow/A1Ig9n58UeAZcRfRivULrtCAmk3I6Q0uKw
GBtEIsxxPEu7WZ90KrmAZSmchRMKn2Uub1kyL3Njissh/f2swxsgx5KY5XN+SctlliXHv4yR
uLBmaS6wE8wq/MEAVTlFd5jUtZtxYkXntwVcTVmmYvvHBoSLG00xLfDfjpAo2y3wyKptjmHi
IaOIbNdLcjgTKWuYKGEZXsjZBX1fvWvi3HjnTMrg3LWUmVod3jTOWTFvtrSzzxcsl3PVCkYg
RJUWVZG7ny/PYKYZEBPrn7R+V+vQpidlcn7go3XV15qNoaZDl/Tzz90mHp4BqznPCozsctDU
u73eFV56K2cnWXOtVjtWbFntNZUsqHi+YlwmgH8364/mnRHoUSVG4vPxuwOwtfOiJPPCKPwT
+nLxxH6nFTpS5jiMAlicFHz9DmjLDErSe1bcPwBf11OKdudFvhGZdzSl/RxWTNY9E36y3WYF
9yssx2GAc5rmPRpgAO/Z7zZLT1kRPQsDeE9p9vUNy8Xocc9JTxj8qZIqL9f2c6twhxwBXdJL
xgifLlvn+mXjl14/GSOF1dvP4rS7KZyPDOd8ZTH6YNjHa7kWFzdYLC2PWmNb4KP1LpFwv3/g
MBXeFTKAFBY9+ciynQqD2mwkCgTq6NEIsHFcvsN0fGDl2GZmJq/6xPLSST+bRHNsByMQ9AAz
4ZLXWzeKxk6MN56F5HWKpmB/T1Nb6ME2kW67EQomholSFLm8NN0d6G0hnOfTMMIIbPPK1DG+
9YHFcBvj4aS/y+RRuYksmkAlO4F84rITJj5R8sjAC8YgliMdnBS3LrL0SYBgdFZkTg3H8cxc
tmmEOZi1DAgNCdAUuXSOcVWOHUYwOw6KUBZ2iyLdcME6ihaQXfSYBfier/uz8C4LBbcKYw/i
YGF1cAAuh6dy6ORJ0liijGeTCQpoGYvQuKXQhmghK6mDg1IVhYt9D3Md51A4493zZFIw2CLN
e1YGB2SzyeDgUeIg2grGxKu5AC/jeA1jzDUswfM5T+SBVgJdyhU0a4EtOHBxeHhOPCYUkuOM
LJh2nsIyvMEhuCzWfS63eHa+BPLMUPgxRY5/ODjPQIt5vCFpEZlDSzcozVaUlMlSnpsfxAvq
GqDHYwvJ9KwQS96MzRjycDrNlkmaz0HMmLwVTHbzXI6cZVOKzuQ7z6d9XNfclfuAkKUGd0mq
wuFGqnqzqM6Nn2TPT049BKF9AVJbq79TPp68fQd6EDyOPuDHR3gcv4fHhxp+4NyTD/gBGaqq
SFg9wVZNMG8bMycihU0N8852Ud2G5uzMWAT0sb1m5VaIM3N7Yd6e0rHHgQEu70vDNW5T5pOP
GevJtjaTTQzWy3q+anOj9rw910OF4j5rAkG6z+KtPZefiPxdV5LdPHY+2Uu2of11AeTj3sqO
t8a9VUCk9a5LJ9vsnqaWlL2PMScF73M88HPnw8GViz2N91IFaOeLideyj6nlpe9nfsM9irJw
33KMa4j7KXkP80kUzX2NNy57f42Otef9lJ7mbvXHpUaSJINbSSgwr6wLuSUX9PFiqxzNwgp6
GX8mV5A3VHe3c1qqP25+iCDU1zfkN3OWIJDMeYJCAKPORgdeCax4gBZc4eVD5USQ8QFbjMAX
JaAn55I09MhcEpkek0si01NYSWR6CC6JvPz4KzBp0K4tqNPHRzGqlBwRGMW0oCFUVKoEiIoa
hy7f0mUReQE7oQQoEExXng74CovbDogpXC+I1X1Ea6sSjgpjsZTdHgbV4hixTqc4Wqxs3HZi
5iFjwTq114jtZT0r7k9h9Fu6oXsOWwtM0uOKI72rfQTX5OBmoF/1e01tMACbfqMPvruh1hx+
7munb968Af6Bp0TxWNkYziJ9w6cQZ5P83wZD7VJv9i6vYAjOOpoOY6NdnnV+07uNS1JYstnI
13QrlwdPYYSmeBphHYwdxOrqFBXWKV8abXpCHw8Mbg/JrwYQ3eltEOUM++LrCEzbJC4t8Z0n
bnIp5/te4vde58pNu3FXu26h7h0HU6bn+2VGVeJYSTlhS2wM3eEyB1H7Kpf5+o3ysLpfyer+
n4RKywnfmvnDIVs45L2PQm8WmCgfWHosK/Lxx9qJXNv+mFj6vIzDeMuL4iSeV9m6h9v5fZ5f
PHESvVt+NL9kGG+6ba8nnhdW4ppwWpEw2nTQ7GKkbInA2HQc7LrQ1XxU6oqA07UxnzzMc/Nw
zVQ4Zib6Uiyqcn0E5WKoZGE45PIISAZwxGMZSfY/K4MPkyDD+OWc/Q7i2L84hJD92rngwDgc
sPxKG5UK4hMN3uNBe9lgPfEgPcBPdFtTwmma2ChQQsgmC1pvNs6hlIXWvV++RbVjJ7LhEEvF
HmMSqpcaKPB1sFpcaKf4IaWhQ+1meCpHaB5R8EAj66Pe7raHby0Kg8VR72vnPNFuksRW9l9M
3W32tUutO2x06t0ehQXgwDBCRBPdXks7b3zuDDvtMwq5vqG/FhrPblOvmKPq5sPbiT2f+W99
uLPAoLkPdFTrxzKr1AtzoMnMJa5937DgroT6ewKNv+ajCd8a48sRYGBDNk7DRvNTvTZ/V4P/
3tbmCvyw9pBPWOk7CaoArBNQ7MNoNq4v/24Ub48jYJwRxnmvqDLUxRoxG4fkgFN3jQjKfQvY
rNVjGKY6rjipGdgpeKqfz+lHtBpO/XRCssRZHahKGNi5HVGMIEBla1gw4ZekolnCBNiUL07k
b0JETfoCdNSsL0BATfsCBNSMLkBATfwCBMvN/IITC23csoS0uV+cMmXyFxzdtNk/oVwvESjt
GfHT9x6gs473+Anb+0vTupEX3geuI0R0Z4jhP05tSCckyTacI0kOsoQOn2ZH19akYwUb06aE
nVCT3Qj0MSzjhagerSncVyBE0o8caKAQiSzjv0fnjiaN2Vy/T49v5kAF8Z2Z8E6hmmCDm/kW
IRE6qXMFSkC3pDh5TUro0J+oVOrmKtW2h+tlKpW6XKVSl6hUalqlUrlKtQOXek6lUtMqlbqo
UnEvPFep1LUqlbqoUql5lUpdqlKpaZVKXVSp1JUqlZpSqdSc2qNuq2Spq5UsNVapLsKMSkWy
tmB+TC5OGaBNKZmHuZRAWLLVlKaNtxohojtDDJ9uNUIki6JeBQFavFULVRFPgxgRF75l/ddw
sQyoPM/ee02bKeiOVgpHAC4P2n9IwhaBCNC+nXvV6VC+Sqcb55RVy5BjHFxwr8QFx6f0f+OJ
S3OxKRzQs61va1tlt/SZAHvvys7zM76LJ/Gdle3Ll/ac0Za9Hr/ZBvfgHLxsBy/bM/Oy0VUp
5mM7VdZcs/FyPHOs78xBl4XtOB4NNO5XqRqvv0H1oAxvogxXWvrFVefqVx2GZfD+OerGLnrp
MaeEOc0vH5IlEAuA1dbCKWD66nO8qTG5A7CwE9U3/A4/fvMev2lvhaKqrFdUlSWKKgGXYe3i
C+eAe3eEVOp+u1JI+Uvw+EV329xtt/6WutzFdOXvosvdL7fq/rh198UtXAjHL34TufBNWbxo
j9+rt0znVFbdl7cgzcVvhlOK777L3/vGAE5yzVtyvRu/1i1/nRu/vm3xtjZ+BxvD6Mcv5+x3
wKqy4+vO2G+cfqpkEc6twjU3egn3e7G9xExe9WieTgWZlGdb6SSVVOyOqLgkIVsG92+W1urT
5tpiHyfFO3g4Dx7OZ+HhPJ+X8nCKsD8uQpCa2/q3In/N/k7R8BgIrdmYNsUSQk3+L/ytAq5T
/C+pmJ47sW+fr9+Ut1HYaZpsj4JbHD735Gp/4bZ63pFnZajnzfrSVvqDtXyH1nK40P5U8KLv
PRjLW1eDxhXPVrY0oX8ZozlfIWIW82dk++ZdYIbvNCAlqIM5TfKjS5LmZxdBWc6PK+XGk2fj
rS97Uim7KxyOKa/kmOLOTeKtoKkpCm5RXQ5wNXTwSh5m1OS4EoUGLA7EuvDkwr9AauJDzeJZ
BJgr9Jz0YQRjxUXW0ueTqWG7zf4Q/q25IJr5JKccl/JsoWOBYT3AGj9ShZRS+k2AINE0fIBN
WQe8ObkArUhTB2ROKBhwmCjmQlQpXXvpBcZi5nYuqooNVTQrb0wpY7Bn4qnwdBDezSJwTbgg
dJ/v8SDVyMO3hP/TbwnTZqH9f10YB74XfktYYu1iqtIEARIkgCwhAjgpi9MEG9CAZidORNW/
V/11WBmSzb7Oci07+fxJxOa0xy+qBEw5Avo+tt3kt4YXbrxJ9eRZWW9S7TqYbw7mm4P5JmW+
KbdEXoT9JtUHZsDJQAq/T3o07Mj1fORaALTdENRxBz0g2Mme7zdLq9ss+JmCwAEQ712F1b/w
GCyxjn2xuCyxZhbHRZUKwyqFdIiw2mGEFdnohAOsdh1NtbjRbRlj9WWiqsRWzIuItFrdJRZA
tRph21u3BEdzNXrei7HpHnO4seuVWNlSXg1lmVejpC1OTaxt3KuhLHo1lDVeDSXv1VCWezVI
zmZcuxpdyJIUez2EDB7U6yFItMTroYh7PcrVZU5up7eBYAN3djFOwdEonZ+XYqWtPAdn7MEZ
+wycsaEAsx/csZu6Y2HQDV8sXtL3HgM/8CZCRBkZ+C9QSwMEFAAAAAgAgWFUQl/ZAizeEQAA
5M8AABYAAABidWlsZGZyZV93bGhfYW1kNjQubG9n7R1rc+I28Htn+h88/dLXxYAvzfXopFMC
JKUHJANc79rS8RhbEDfGprZJSH99Vw9bNoZYAtwjqTtXbEm7q/e+tHIu3ne6rbrSXhlz27Xd
mWLWx7czTbFsH5mh5z8qoY+QMvV8ZWo7KFBCTzG9+QLe1c8/8wzTV2z33nBsywiR4nteWDfm
1tnp1EdKxViGnukgw/17iZbo889qP14sbcfC1cyQi3xAsShZIMJqHq+QuzBt5Zvkfxj1S3du
3CEVrYCw6znezFNI43vDq/Nh6C1U5cSmOfpNYzg8xz9VpX/d7fTfndcUkrzud3+D917jXbvV
GeiDdrcx6vza1kfX+kVjiPPOv8R1RYTryo3vmSgIoMnp9n3+mSbYmfuJpQdmYC88P1zvlfYf
9krb3qtsQzE4zPPiUaEFqu2utoCOvclfMNv6g3Ork6kf098YcQojyojRsUsSoznbaMTwU9Kg
GhlfTMo2QlsFupk8AheExnwBSMrJdOdGKyeG0ui1zk6VE0v5Rjm5V6pqrabCD1SbqkK2K+uU
75Sa+jZZAe7DkNKf7d7+P35FfmB77p9KADsZXpQHO7xVWr59j3woO69qFa0K/2qvXyW6Ftcs
3a3dKpTaRsCQnsc2Yg0VZ3kuCo+a5blIiCdAv8WWJxCT3rvCxNM7THRriZPfbaVHTJCOZnL0
SM7WimP46SaGt86NZGk+NVacGUhT3XWImkS3wDV+1feGj675dVS1Y0+cqRWoZ+PAN8d4eTpI
BzVFB91Ef7Bdy3sI9Dvku8jZcSdFJRUyiJikdTd+c1aFpp29/v47tTqe2O4YE8IzoFpour75
amzz7bvhJPqKV3R20NLM+zD8UrxzuTwS2oSHQL63dWXUGFy1RzeN0c+KHSiqWoF/MC0Vsg+a
9fEH22213qWn7cJ22QrFCiv5MR3lJ/nqty1801H9YIGb0LNN3wu8aah8NfhaaVaa336rXC9C
e27/g4eAzhTyFbY9lNp3KjT0dfWN9lbVqm+Ior06O6VbYfHo27NbINX8WuGEm4RPGXhTqYrS
cByFQAWKjwLk3yOLMtK5A3u6YiqV5oqv7A5tL7yo+H91DLr83HPHtms6SwttyhsvlhPHNkkR
HysoxVkiOgKAbZ4XTGNsLOw9AWCX7gnwYE3Hd3P4AUXsaUgTlA+l8ju0qKV/6PTPTvELYZ86
vFE+qsBb87rf6ow6133950a/Bbvm6rwG2f2R/v4G3uhrpz8cnVfhHSi91s5rVfyu90e1jzok
WEF/RDB1AqPTjOqqehaV/9oesDSH6rRx1hvIIo2hmd12o69DY/QevBCarYsrqB6/tH/t0lp0
unEbzZ87/baun9NxAJhLT2Sqx7ePC+SbhuOoAKCs5xnBnGx7B9P74mDbr/IFpgo0m/TZG9Hn
e52+xcueJdToyV8q8A/mt8IyDtY0TC93eR8ICJb5gYBMqrnGixwn+EJnKZLA71uWOy6KlnyU
4quepPnKJ+l49UcZfAfQVHYXUDi+E3heZjfQ7G3bAZexnUAT23dD1JVW++L9VdyvVqujQwuG
MAisFdW4FyZ9/G7WH8xbw9fDE5bhsOfie/py9UieJ+YkCH1YbjT3w0f2PE2n2z8HJ+YJwxxE
L5fsOWS039Dn9SpgBd2ogI+H/q496Le7tL8s+12vdan3Gr9cD6J+6cPRAE9ttZYC6fQ3gFTf
UpgQNr9lO6xxD9bpWfU1f9dYGy5zFv/4wfCxd0q9JfDq2MADZBDFUgfn08xFlg7bD6nmlsI5
8B/PzBSbRpDJszZlQkN8NEduSEpwVY4dhLqFHBSidN4MhbrhgkGB1oBd9JDOWHgLfbEMbtO5
4CzzH0kWcZuxOngGpsNTGXDyS9J4BU2W0ynyKY313Kil0IZwrSiug2clKgrW+x5kOs5zQS+9
48mYMJgs5h2jwTPSxWRw8CjxrLgVeCFsXwVEA2oEAZpPsF5c3yyKtB01RioD85RB7XDKoLan
MsgkrkjzsTDVmDDVuOhkCUJtk5aI85/QHnFxVoMk2YJaJICKCMmDAIGQPBBQUrPMhyZyV0vK
XS0hd1mKJOB9u9zVUnJXW5O72prc1dblrpaSu9pWuattkLvaZrmrPSF3taTc1Z6UuxqXuxFo
qwt42ZKTFjVe++97F9C8GsvMijrtKelNi/EqTUtvluHAM5LeGpPeWkp6a0Rqs+dHeMZSm2EM
opdL9hwymniVUqnNCrrpgktLZNOwbZuV5XzkszL8HK/UfA1AE9AAtJQGoCU0AC2hAWiSGgDA
q5Hj2Yxf9anlJZOLdBKtsHOP5KD70Lx1yevMDcOJE8FNllTwz9EcTr6S2Ba6t00EWkCI/Klh
ogRGpiyJdwvMOACHTKphBlTPzIZUHZPZApYNbiPuY9RBLOi2azS0PKPSUAJ8WDgQ13Hi3KyS
Q4vWtJwU1UVEdZPaw0sikR/h8qlgQBldiGdzZYhi02mj5SnNiOeQqngyiU1neq1wyZAzmhLF
oRPMQbJq03oZ7ytdQ+vluNIoN8iM7ZbFxsCzo8zbuBmHOwZVausmNbI4zdu8tmgpTFJRi8Cy
65iD8jlY1+E4Ll/rHDAaGklHHu6MUgGtQql4y7DOHYIUMNY3CETnCjhVu35ae/v9q1Pg8PDz
+g3+eQs/Z9/Bz5sq/sGl37/BP1CgabVXp7UqyYMfrRb/vP5OwXwdu9fAGWwsnZDUMjfMW9tF
9CAc2haas0M6G4HEZm9j1574BpzY9wzXmCXUyrcprXJf1+IubtstXdlqxhHvUfFVURZacGXA
aQuuwSq+ilgyFFBPWswUMfcbZFShHQEOWCT5SFQWWQdhxgVUQIRucTNNyBc0/oR2wQODf4sY
F66BFDf2GzWkIvYZr6igmeYVFDbdQbEcL/gP2B1XJgsjXsz0EnWzwLHH5AtteqRSF1YBX/WS
TtI1bVzIR0FLsYIu6GCNFWBtRwV4X3dqAXYEIfvhI3mmzAmSkzYpSBYxK+gbANfZIMIryRMa
x9RhrVS4nyQ89kFI4yx2wKGeBXE06lIQhydOBLnhAuNcHJ46DcThtzgMpAhAA/cjkHQZSCMm
nAhy45ryInBO5SMjxGcrDmUFMuQIBwJxqQAUxKxJoaIVsce7wP5w7cBviwhn1xQcf8UiOvvX
OKsaRWN1u/lxWblRntDSVDwZGQ7WqUJD2jf1LL8/uXFmvKEsosE3SbtOHOW0+hYOBIYfh/rN
4LrZHg7Bhd0YwInDqN0cvR+0z7/44gty1AJPhUHS2DNcwqY9eAxwMSn/bThq9/Tmde8GmnrR
bevQh3bvovub3m/0CLlYzKgfqCxWh49BiOZ4uGHVThzE6urmEeuKU6NNj/FjJz8UkvKKD/GO
ntRiB1n4AuKfxOKe2KFSfNTEczJnTBvOl7aeLeGmlQF4OwbgqfFCxC7lg25qYBgvclNL3B0p
d/cx7m6BCdxzF+cC5O7iXACyeeN1ZmZPMNiiJ+8DFHhL30TZMJkztaaeva1+r1b3P8uQtm1l
zVrgJmsnQqJWrnvHrNy9B2lfe1dikHCUlNSq3Ro734mOHAyHqKAFHmhVem2QAXVQR6/a5/hH
SeaO2h9H52qIViHNHrabmPfVO/3O6JVF865vRvVB+5InOk2SKMZVgMn2m4N2r90fNbr1/jXN
88GjZQSIJvrXrfZl43131O1c0JwPH+nTQpPlLPGKAzTq5v2rqb1aLl4t4CKvQUvv6XDXYSnR
DC9Yz9q8MDAfG8M8R34GL8RmHj+vqEyXLjlXWhjW3AZqNHdhTfDVYpiagI30qNF8V6+uTqvw
36vqqgYP1nByj4i+B8tJQIRk3TVCyH51pkZgExiOOsGLcmA9+Y/1yxW9iNTGKVKw074GRDFP
C7cSpXF8JFFPyqMjjkZLd8HBnp2d8BY74lEPjxwq9fLI4RBPj/wwgjNFDod6fORwtnh9pIlA
Y/cnkvT+7ISc8ADJj/e6F0icKV2Q853re+i24z28w84fcWQ39II733XksG4NSYSHuQ0ZQjjM
gKKI2Iwaf7CmXcvfHTnBIYWIJAYH4gYCY4rk0B6sOVwVlcMZhM49EutjjKOq+B9PG8uVfpcc
5qQeTm58EsMnyovBEkyzrvSGna6iwuXXuWct4XYu+P/oW/SxDIvcf8VxnOAcXLrWD1gDCQ2f
OSvdO1beHTWvflAMy6Kv+HMb4S2iENhwAIccTiBcYIOs9O5pIQhDYP3gdwQIEx1R8Hmp1pVq
XanWlWpdqdZp+fWUal2p1uVrZqVaV5haF1+Vk/Jhfdo7cwINzL96JnQvTghI6F6cEFB5Ha68
DrfDdTiB/TB+JjfcoCvsNliUwJzsin5IjIQ6QKSYpIeeH2PIDRkF23CeIevw5wcbu5uG+9mk
2kbTUNtsGmobTEMtaRpq3DQsMjgwYxpqSdNQWzcNeTwhNw21J01Dbd001LKmoSYmjNdMQ22j
aaitm4baVtNQS5iGWsb+07Ybi1pkGl4FCcWHFOy3BTCFnZB9tAcylIpPwgZVWBw5UoXlsG4N
SQSqCsvhrCuiGqh220wKquSxUrlqoimJsegcPBeHX8lMS2ZaMtOSmeY27dMw04wOW/vxEj5A
HtwC45xl9NutZcLRygf9cnCR0cr8y8FCHYMvkYKLr/jw8j2Cynkzy2hNiWhNsc8Rl9GaRxut
CRP4sqI1n3sgIkyIWCDigXkUZX4vllPR7m0Z1TRQya6Oll3RCXq2zGqHGyTJZWkeUcRMfAYl
xb6O4AwKGlieQZVnUOUZlNB+eN5nUPtqgvvG9u2lCVKun68HHkwg7NtbJhAkesG/if/kF/Cz
4qD2tDiobRAHJFtOocj/Br3QJ++FgIQ+eS8ElFQy8qHLr+jLfkWfio5sSVZ01DaJjv/kW/w7
fYPfznyDP11waUnsnfG2D/TTCdj2Ud/n8Fn/VPfZR97X8iTdADzaQU44i0c7AKEy2qE8oHuG
B3TiWwBT2AnZR3sglwd0/+EBHUxJGe1QMtOSmZbMtGSmh2ama9EOkg4MrsPKWAnJsycBPZYC
5mqx5XVOYcZbXuekjDd7ZzP3gqfgdc78dbu+CQgVeQL8+HJfCuVltiO9zCYnCNbcEseqJpfc
uuTWJbfenULJrV8Itz5YuHF+VC6w/6MOx4X25UZNm8D6Tc+d2rPjDZjmbTx0yB6M0IsM1oN+
bWF7rLQMzxMPzztp6Vc33ZtfdRiO4dl/Ga3nohcQUwydeH5fgMWRJCLzcHwhJFJnpribGSab
31UWpCIyQJ82OgXa9aLCUspAk08RaJIWAC8j9gR2hnTQyXGFj2C5YsaverhKpvxUyrOtZJKy
FBZ0wigdc1h4Lmv+hBHhuW3LD7wWivMWAipDuPcK4dZ70OKDR3C3boaNG15c2y2uu+hI7tx1
/CyCuHkvWCB3IoOIpJhZ7h9elz9iHAIb7GunkhKKZxlYJ+/kfqGxIHPkz1Bd9XEL6IDnxIh8
z5zfWhwFEgYGbBvEevfoGnPbxE7w9RgRWJOB5ySDRDAU86en40bmhu02B6MhPt9ZLkiJ8OLm
EHKBG4Z1DxzgtSYXr0C/0imGBdKUYc2De0iI4DwVgMF7eqyHaCV/KflLyV+eK3+5kjvdSViK
uackwe0yBGelC0bS8R6TJBopqdthN2CWSL4fkJvXR20/5/fpExrQ+Y3Lt3uFjGMhoNKCLi3o
HS3o/IX8LEzoRDeYDZ3KSbA9uuf3N6QFBi4BssGUlmHepS1d6rrPVNcVWN0JkJeu7QqhBQjG
0FhIXmpYeA8+GMnTGCsxrKXpXrKzkp2V7Ow5szNJR8E+up1QLF72ypZg8FF5V0ue+5XR/3tG
/6cuyZKCnRY8RpTB8ZE8DpTK4sDR6E5o/m5o4DrbCY/anv/rWwv7/rky17IDkVsGyT9VJ/sn
xp50Kj8Yduh6C+RakGm7ATBrB90j6M7x+pi3t5k7Ro7VRCiFZCkkSyFZCslSSEqgFS4k9/0j
d/jsMlc4PX2UecRHl9Jd+oQnmdJtzT+OFDqzFAIqDzbLg80dDzal1/WzOOfc3it27PkUQPpW
9V78m7vMdh7u7RgbDkv3kBbl2am8JVEeNhzFYYP8Yt+O8bKOIszpbD7zEzVt7/ixOjZKdlSy
o5IdiY3os2NHUoeV/wJQSwMEFAAAAAgAe2FUQhgqeOiVEAAAAJwAABQAAABidWlsZGZyZV93
bGhfeDg2LmxvZ+0daXPaRvR7Z/ofNPnSKxYgpz6YcaYYsEvD4QGSuC0djZAWrFpIqiRs3F/f
t4e0EhLWiiPBLh1X0u6+t/e+m83lx1a7UZWaC21m2qY9lfTq6G6qSIbpIT1wvCcp8BCSJo4n
TUwL+VLgSLozc+Fb/vabyvvLuWkZGG+KbORpATIYnGmzqkYLZLu6Kf0Y/w+jfmfPtHskowWS
SrZjOVNHIr3pDK4vBoHjytKRSXPUm9pgcIEfZanba7e6Hy4qEkn2uu3f4btT+9BstPpqv9mu
DVufmuqwp17WBjjv4jvcVlhxVbrxHB35Phsq79+33yiCg3kYG6qv+6breMHyqJQvOCpl9ajS
HcWTAAvnPkl0uLJpL5ITMHLGf088pD5ad+ri7GRkHsMjAp6QCipkPnA9phaYMsnzA23mAoB0
NClUoXSkSZAtHRnSj9LRvVSRz6WjB6ksVyoyPGB8rMN0JFGH02PLaojBhD0f0E5Oi/Xwz0/I
803H/kvy4TDAh/RoBndSwzMfkAdlF2WlpJThr3L8Nuy3+KEgQ4Ajhoew16cj3lG8LOltoCS2
wXrLFN8PSxshWr41a15vHUXpgY32mwxA/2CRcw8TLLDAXBYkAwVqXr3+/PiuWfO660+njE5h
fMpITnarEfCk4EnJr7DgARGocL15qbyvEwEAN/d91xk82foPYbuWObYmhi+fjHxPH+GNaCEV
ZAkVBAj10bQN59FX75FnI2tNkheWlMjk4SqN+9HpSRm6dnJ89rNcHo1Ne4QrwjMvG2iyfMwq
7JjlH61syrjGWPESpSctyYy2Q0PEB5dLN6BPeAqKj7YqDWv96+bwpjb8VTJ9SZZL8AfLUiL7
f2ZJJV+bIB/dSSUd/pzJRCrVF3xpW2SjwlvG/8sjEDhnjj0ybd2aGygrb+TOx5apkyLeVSjF
Wbk8H2Dq1dFn0240PiT2Eq5gpLnmhgCwRTcEeDQmo/sZPEBKeh5SB2Gi9MdMggf0qqHenp2o
FxX4wgOFD/gaDBtqvdZuw2e91220hq1eV/211m3AxrkmsN2h+vEGvuhnqzsYXpTh+3Ore6xc
VMr4W+0OK7cqJFhBd0gwVQKj0ozyonwSln9q9lmaQ7WaOOsUsuA/Vr3abta6KnRG7cAHqbNx
eQ3N44/mpzZtRaV7t1b/tdVtquoFnQ0oubrpEdgrJ3fVR4HrqWg2t4Cxy1AupTI1f0Y5pyX9
UvwYZLapW7Lnu+Qc1HwfzcaYIlRXNK3QpvNHQmvFfe2Yuuf4ziSQvu//IB0rR2MzkOql+k8/
ST03MGfmv/iQU1qEPIkxAKnyswz76Lh8qpzLSvmU6HtnZaifknv3yTOnd1Bn/QeJt1An3FfD
jEOWpJplSQTKlzw4294DMmRCPyy8Gm+2M3+lN7hKqLBO350hfX9U6RejHexTDt/8owR/cExK
LGM7vcKV5ZKILQEBqRAEUnayGXKpDzS84Y7hZIul8ByzBKdeLJmmYBQypGJhihMykubELExz
gsYBusMQPU3YKBwnbjwvReBo9ioKh8sYcaOJ1QQOl4ZELhxWo3n58ToaY6PRUqE3A5gQ1qNy
NCKdvv7Qq4/6neapwRHLsNjbPaMf10/sPaMQR/rYDzzYKzT78y17v0umr/+l7zsncLVAv6Op
5q/+kX7EIPrhxxV7D2C7hCQil86Fp/+PU4zFqUBv4bOPpyNSwqkAB27J9J0WHnD+M0IFXzv1
Q7Pfbbbp2mCstLwRQn/oNK7UTu23Xj9cDnUw7OPdWSYCu4hYAnCiFIO11+pmtFc+L1DRo/Hu
pHycjwAUhiMop4IIyntxMYdWHzy5yDCto3xcID2MN+QMdPSoedjUKd/RSjmxUeLERkkSG+VZ
YiOPNHxENKJFqZplTm1kqLCgSNZXFM40y3L0VLGu+ak8IysTRuOhGbIDUoKbskw/UA1koQAl
86YoUDUb9GW0BGyjx2SG67iqO/fvkrn/zJH3RLLga45YGzwD18NTKXDyJGlMQ8bzyQR5tI7l
3LCn0IdgqShqg2fFGvKXx+6nBs5zQeS658moYtDL9XtWB89IFpPJwbPEs6Je0D3CuY6yxHWU
Ja6jLHMdJcF1lGe4zurNhvHSPEnJ5knKMzxJifMk5VmepMR4ksJ5UojWaEMd6ZKjBlVdux87
l9DVCs3MIrPPcTZajIed5Gwsw2Jv94x+XD+x9wxDJDibQjgae98ysH/pm3M0JeJoDKIfflyx
94A1acI75E0K50285MrI5QAjCpnmJnyJ0oT/AtN7MR4kwjYijhAn9knKXJzoyqGZXY8+1Ynh
xJNuMokW2NJHctADLIVNPqd2EIytEG48p2RyhmbguYpjG+jB1BHQzAB5E01HMYxUWRzvDsRT
H2w18TyyE5g2kGhjPHU9qIWRgnCA+Lyupv+0PMUAaAV8WjgQ5whRbpol0KIlnpCo1Q1rzWIS
YQnnEiEuXwoGlOIcPJuzDopNl42WJ/gIz+FNsYXlRbSmpYw5GxRdSVqY4jE8O81kKDrdL8tw
uDPLefFe+Km5XbXZOHh6lq+pa4EqYgaSZSKmrtyaCfMrAON0nKtFad77kK/xfi5vbg7GsZLs
LsRLHwAOzOcmPSqmgeM+UnsmyMxSyZkHVW4cJBQvEqYJQOsaKFOz+q5yfvb2HZB7eByf4sc5
PE5+hsdpGT9w6dkpfkCBolQkTMKxPRHMv9rcCkhlM02/M21UNYG6bs2eA/jZppe2OfY0cJ93
NFubxpTr84RuvQXzynbGsUKioIaxHbdDKeEuWwJqucvqjR3XH9H1bTeS5BBbX+wM3rK7IQDl
2lndIXPbWQOEdG67dsIgd7S0pO5dzDmpeJfzgZ9bnw4uIexovjPFl60fJt7KLpaW176b9fV3
SMr8XdMxLsTtpuYdrCeR+nY137ju3XU6lGt3U3t8dyvvU+ohZGaL/ZkCcr6RgBZhiVnEVxhJ
rMqaEutm7h3l/fpSPcH+fEveCeGe5CQEfJoDEFU2O/BJ8vInaMktLB4yWAQYq/XFENyiCFRN
F8ShyrkgMFXOBYGpKisITDVxQeBsdbvAokG/NsCOq9DFsGIKdIFZjBORiLhIdQ9RMmLR4ytc
F6EXwMwkAIHoL3E8tCDqbhtIFW4XKOMuIr0VCYcxsRDIbg9nlcOgpnY7P7wpN6oVepoIyyJz
wQa102jvrJHljyc3XCsV7e3ppF9HlvSufA6W9cHtQL3p9+rNwQDMvbU+mPGHzfrwY7958ebN
G1hleEoMjgZw4Xy26P6Tj4tJ+e+DYbOj1nudG+joZbupwgiancv272q31iGVRSxB/kx5pjx4
8gM0w5MNu3VsIdZWO6+ytnhttOsRfmQOh0JSXvIgaNAR3+fAtF5FAFWxwCnmookcNzwn5bHJ
8Nas9tRA3YdgvnWC+eRoP2LBcYvHGgjGqzzWor8MOJzv/T7f8XV8mQedHN9ou+lpJwHb+OS7
j3xn7ukoHY93Ilfkk/PymVze1F2gbNz+psofCWgVX2Me2cp144JqMZC4pO9HSEmGpjLdOq3Q
FK9ZRFjcoWen1GkCta6C4HjdvMAPKZ47bN4OL+QALQKaPWjWMZmqtrqt4VuD5vVuhtV+84on
WnWS2EgFx9jder/ZaXaHtXa126N5HpiBNB/RRLfXaF7VPraH7dYlzfl8S98GGs+nsU8cRVDV
H95OzMXcfesaWqDR0gc6q9UTmTXq+KmsydwmDhJXM+DXq9WfSW742wKacI0x/rkqTKzP5mlY
q3+olhfvyvDf2/KiAi/WH/KzF1bHfOwTZlS1tQCy357IIdgYRlkleGEO7AbvqXq1oL+baeLU
L2ekqPhOBSwBEwXXxIoheEi0hSUjiCAWLSqMgI0hxZHcdZCoUaQAHjWMFECgxpECCNQQUQCB
GkkKIGQbSgouLPRxwxriBpPimDGjScHZjRtOIsxsto3FkRHgU9xL4qzoPcBgLefxA7aYCOPa
gePfe7ZVCOlOKwb/ODMhLYTCdA6ChxWP0Wdj0ja8tXFjxE6oDj4v4NfGJLoQ1qMxg58oFkLp
B9YDEhtfiCLL8MeT2nyh3sfnNy6u4p8ZpiNWdvOri02FLhZfLy52ld5EAfY8nH7jMPqseHmS
XUjsz48EB8l+S0BCQetCQKAKbCna/AsFGR/CiF9gGHH87BSLJ96vyGAYB4uiDRNAfsVM9Vu9
UGM9U32u62HpQo1l1bbAelKYtI5bSMeOlF1lfWV3UxaVpewq2cqukqHsKnFlV+HK7hb8zSll
V4kru8qysstd1FzZVZ5VdpVlZVdJK7tKprKrxJVdZVnZVVYqu0pM2VVSGq2yWv1VQmX32k8o
u6Rog72L0YtjemhdTOY9FRIKM5QAYdxQCSiEdKcVg6dKQCGUZSFcAdE2X4kq1ES4DARJ1NEK
V3aAZrn3blbaze06WV+1N0bgnp6DN+YFeGNgHQ/emK15Y9jNIuJz/ILu+RAYDb/L45mbO9JG
hkr+b/Uzf5RfaDfn33QhdFmHEJD4jR4VESPD4f6M9e/PoEQ4XZI2MlSyjAxf9haO7dy+QZo0
0/doJEuuDPGzMxK6AkPk1gp+IUX8ronkxRDF73yoJIwMOM0S24+voYLiq5Xr6PCy9kAS4iDc
vQDhji7VyxTt1oioi+9OfU8jY2j/npEEX5C7iY5lH51NtGevx9UUOwwCNz8dHFMHx9SXcUzR
c1bMLfUarrnhY2c+raW8jODGAsK2sAcIKhHxAC31RHgJ4wJvfm9YRQdv1MEbtQVv1NVCyBtV
ZPfiKgpic2VnI/T/q29qRYDa2rixLSFUx1Z8Y4dw8f9luHicZuUGkIce9Nxw8Vy2zXk/QS+O
6aF1Mf+vYbQrw1iLUQmRJsJlIEgi8U822u+wJ+hfbiAA/hdXdMeemNP9jQLgfYzsNqmSF2a0
2WYkAyzzq7R4P/8P6hxs3OvYuI8a6vVN++aTCtMyOPmSJm8bvfQwBrLp9JjBVYgIfTVrK+/W
1za1Hkye2zR5qh3o/dYtno2bQe2GF1c2tIN+Jcsn3/PFzJ57ZMDkQ2DWy1jGPsZQ2egVhE7Z
aO8ipmx0CJQ6BEptM1AqKfv9P2KnbPSiQ6awyKlHn2qwiKe8RMoxjXiS0h4WbxXWlOFvEmOc
vBhjJl1Nosr4wc/0SvxM9kInmj1NzZA3RVXZw83QyRP0RimRvynwNdj7iA3hyYZ/Gl/HFt5l
bxRsLt+x4u4oDMWqTHqoZppp1/tD+Gd6vWDukhKxXcqLCzmGNOMBjvCxUsjzQe9WEEMCDkqR
Zv4DfIugPGM7jdGTWNKLkpyi5BoQ/bt5ABKoDdRmfy2IsU5GJsR00QuzIUZ2CLGRfDVDRKxf
B0vEwRKxD5aIyvslMelLGCdi5+DFWidiY2DmiUQOzGz+TetY7BScklh5WvAUJuEHyfMgee6B
5OkX2OyvVvYUw/IRzJ3mFvsFvOs8eq7nTMR+Af+omYHtuMg2INO0faABFnpA0N/9FWNX9zkj
pjXfCEKL0sGjIubdw4Wdhwis7UdgCexUjCWM4KGCCFBUCAFU6OI43ho4oIwXR6LS7SF2bK0r
EIHI+usFm4ldW0iMELmE/YXbJIoN7KuZKIp1M9/OIGSMEAI6WCwOFosvEztR7Ay8CGvF6iEx
48VqgExn2XoztRo8bdNYlyMcTBwHE8cemDgK7trV4K/HAKJPprOpF7XzH1BLAwQUAAAACAB3
YVRCEsX1hrwSAAA22AAAFwAAAGJ1aWxkZnJlX3duZXRfYW1kNjQubG9n7R1rc+I28Htn+h88
/dLXxYCT5np0clMCJKUHJBO43rWl43FsAW6MTW2TR399V5Jt2RjHkoEruVHn6tjS7uq1Wq12
V+L8fa/faSrdR2Nhu7Y7U8zmZD7TFMv2kRl6/pMS+ggpU89XpraDAiX0FNNbLOFd/fILzzB9
xXbvDce2jBApvueFTWNhnZ5MfaTUjFXomQ4y3H9WaIW+/KLx9nxlOxYuZoZc5AOKRckCkajk
ySNyl6atfJf+D6N+7S6MO6SiRyDseo438xRS+cHo8mwUektVObJpin7dGo3O8KOuDK/6veG7
s4ZCPq+G/d/hfdB61+30bvSbbr817v3W1cdX+nlrhNPOvsZlxYSbyrXvmSgIoMrZ+n35hcbZ
mPtbSw/MwF56frjeKu0TtkorblW+otlO0Idjfdy6ueyO9d+6N6Pe1VAZdcfK+Er5MKofA2kB
2MZb4J/lk0K7UbXdx2zHTrzbv4F59AcXhTphpQl9JghTKDAiQmudEMm3o5BagjklVWqQkcNE
bSO0VZIWhMZiCQDK0VS4isqRobQGndMT5chSvlOO7pSG+kY5ulfqaqOhwgOXMKIFzMSp//kb
8gPbc/9SApil8KI82OFc6fj2PfIh76yu1bQ6/Gscv2IlahvaqWXaWb0X1xvMWso/7UmRIHNw
kQc9/9MVhS5MBnKL7qs6onw966LDFj0u+jQSJxYW+aHkHCdBYSFIvXgSZUQeEEi3gqQUk08Q
pmmZs0Ulq7KqgPDha8+z3ZW0VJxstQY23raJXoSL/GbojZ5c89u4bMe+daZWoJ5OAt+cYOZ3
kA4qlg56lf5gu5b3EOh3yHeRU1HwxTk10o2YpHU3eX1ah6qdHv/4g1qf3NruBBPCY6BaaLo+
tRvR1C6fzpvlY4W24mHKd1p2OdyN3OJvXKmsgjrhLhBvbVOhUuq6Nf5FsQNFVWvwD4alJirP
+GFhhi0cmCA1U6m1HxmX9CjTw4uK/1cnoNMvPHdiu6azstCmtMlydevYJslizYZcnMSlwQBc
uzn5YLudzrsMb2IiE2NpbwkALL8lwIM1ndwt4AHa2vOQJqgoSu0PqFFH/9Abnp7gFyKMdHij
UkmBt/bVsNMbw7jov7SGHWDBy7MGJMOwvb+GN/raG47GZ3V4B0rH2lmjjt9haBsfdfiIMoZj
gqkTGJ0m1B/rP9Q1mg/jH30zqF4XJ53WjxVSGZrY77aGOlRGH8ALodk5v4Ti8Uv3tz4tRac8
1mr/0ht2df2M9gPAXHhcYz2ZPy2RbxqOowKEsp5mBAvCnK0gQItbPP2bm2DI0lowCue2GxWF
d6HkYTrKz+LzsrAJpqP6wRLqWbEOtIdKyTfeDmzT9wJvGirf3HyrtGvt779XrpahvbD/xbKH
ikjkK9G6pDSg7Lp6XH+tvVG1+muyO388PaFr0PLJt2dzINX+VmGE22R9N/BqpipKy3EUAhUo
PgqQf48svBzvriLaVhUB6epgTvtqd4NZ+wqTBaJt+ncwpn/f6/QtEYnRhxr/ZS81+AdTvxYl
7K5umGCp6NsREIjAHQGZ1EqQCED8wYRg9EU+8HuBKAROiceaa9LQYYwFKMVng8pkKUlnQ6ol
Q5oWsvSbCdoIK7/0McThmJb5zAKJgTfLaYyYXz4JAhPhDJR3WSX4eZEPJHgYZidAwDCcQHFT
8+tQOYH06lwOTfhTy/JnssTFOYxZixc9gF1n5WGne/7+EjKK+Drhx06nF2tm0dDWKaNlmTjH
vHk+jfjkD7P5YM4NXw+PogSsRmf5OMpY/ohzGOPS5MsnSC3m0BwrEqwj8zYIfRBulMaHjwQy
z3RR9kkK7LkBZwNCEbq/BEfmEWQ8MxxRK26OopcLAM+Nid7pJ0QvRxmIqHNe079XjwHJPerQ
HcPw/eAcmt6gibji+rvuzbDbp5WJKPYh+7nxzZZRQKXzbtC50AetX69uYhL6aHyD+afeyID0
hhtA6ngOML4IQW+ybCfqPMYlcYJDwR6sEyobKIOwRC2q7EWJMJg8GD52FKhzIBKzU4ZBNMYB
6sTAyQbZRevgJZi5yNJBiCHVLMhcgOrnmbls0whyadamRKimjxbIDUkOLsqxg1C3kINClE2b
YTnqgvEDrQG76CGbsPSW+nIVzLOp4NXwn0gS8W9EZbAETId95cDJk3zjfrtdTafIpzTWU+Oa
Qh3CtaykDJaUKihYb3uQazhLBS38jn0mhMFCY95FNFhCNpt0Du4llpTUAhgiEQVshjfeFnMG
QMYzXEtmOJvHf+AFKZm6yXRkGRcW17oZ6QX5achkU376neFZVz55Nc7Jm521bHKyOamJz0k1
dhWYyas+tbz05zL7iR6x8Y+koPvQnLvkdeaG4a0Tw92u6GRboAW4BdPYFrq3TQQzL0T+1DBR
CiOXl8abg+IfgMUnUzEDio/05UwZt7OlD1QihoobiBmpWIrQ/JwYoQRYtzAgJleS1LxgoVlr
kiVDdRlT3SRqWE48zWJcNhQRUE7+sGQmgGhaLIFYXaKBZLmkKPZJsSlsPNIskzxpQk46seS8
eKL06OCvw7EKsLR0LShnUYis5GIprCOjogp5MGORVek+Li3okm9aLVbtAloZOchSWKOykpBS
XOd0Bhg3XNDEgeuu1GD/oNS8VdhkNkQKmOwsCETvEmRPt3nSePPjqxPQS+Bx/Bo/3sDj9Ad4
vK7jB8798TV+QIamNV6dNOokDR5aI3kc/6BgQY6tiGA/NlZOSEpZGObcdhH1+0PdQnO2UzMM
0IjtMBuFRN6C0rdvfQNCFwaGa8xS5oo3GWvFtuaSKjbgwkYWrYbEevYJyqICc9+lgWDddxHW
JygjWQr2UVB2YdkLA2xYlvbbFJCRe6Ufr497LYQI7H2UQNbaPQ43ob+vMSDE9903+LmXrmGK
yB77f6OmtJcJx0ra13CzEvY35sGexV/wKWQfUzX3R31PY0z00332P6a/38rHWvj+Skhzv/Y2
t0sV9BquqfV89guajVV9XpcjU6Uraszb+fW0t3vYkhCyHz6Sv5mdCUnJ7k5IEtmh0DcAbka9
CK8kja8jM95tsfhNUQRsoxBHWlZBorYHATxqYxBAIIYGwU6DLbkAAjUiCCAUGBDEKEAdt6SQ
NhOIY6Z2xIK9mxZbBJNKLh8ZIXb5O1QwCNEjEgmWVgXAIIBODBd4EMvrPghEXD7I5X0cDNAU
HA0WRa8Or3BSPY4N6/fLo8RKQ4ShppnoNtIfUaP2ejhgU8vK21Ma9Zau6P7C1cAU5pukvUeO
clJ/Ax640ceRfn1z1e6ORmBHb92AM3DcbY/f33TPvvrqK+KUhb8KhYyI45yInYKnAGeT/N9H
4+5Ab18NrqELzvtdHfqmOzjv/64PWwNCLlnO1A9UF1BHT0GIFngYYT7cOigqq19GrM9PjVY9
wY97BteH5Nd8iOr0xGYRLLqfQWQaX0Ra5NdNvL4sJefV3eDRfcaLqygyNrJqbKSacCJWhXc6
rUEUfZbTWuTIiJzfhzi/eUZwy3lcClA6j0sByPRNGG2DeyVie/J+gwJv5ZsoHxt6qjbU0zf1
H9X6to4Wbevyt922CuzkcfyvGEdEgcCVHIHCxgIQnGseO27bgXuHq3lQYcLZivRit4zhEFV7
j56/2qALK1IT1O7L7hl+KOnUcffj+EwN0WNIk0fdNhbEzd6wN35l0bSr63HzpnvBPnpt8rEf
EwkmO2zfdAfd4bjVbw6vaJoPNj4jQPRjeNXpXrTe98f93jlN+fCR/rXQ7WqWesVRK03z/tXU
flwtXy3h6LdBc+9pdzdh7tEEL1hP2nw6CQvVCWa52L7ihXhLyxw6tenKJc63pWEtbCBHU5fW
LT6NDmMTRF09brXfNeuPJ3X471X9sQF/opqT41v0PVjdBmTNbrpGCMmvoAoazbqF/mhivAQR
GMp/al480vNfXfxFMqpNPsDktDGxDbE4ko9ESspYswTwaHYlJGzVqoa4rIpIrVuCuNTCJYhE
rFwVOhOsSIJI1NoliFRg8RKnAvXdAZW05asadsr6VaHX1y1gAmLqnHjCru6h6Y738A4bvgSw
3dAL7nzXEUSbG6IYDwsbUhKkRMnIISWbPIqIt3qTD9a0b/nVkVNiU7DabgghF4ExRYJ4D9YC
Du4KIt2EDlRTEElV8b8HZx59G6tH/S7d1entAjmBS/ZncZpgaQGar5ZWgpSSvk1lMOr1FRVg
F561gkPWoGHRt/i2FoscYsbBsqB+rVzrJ6zQhIYfWXnduyi/P25f/qQYlkVf8X0v4RxRCLwp
Ajsm/kA4w4aV17unmbC0wiICmh1AmCh1rkdMGa59FR/p2XiEp+jsTemZnE0nb0iy8Aau/OQJ
15EZLiD+czWa8GmY7AEYdsTlmVMtosdW1o6lZE+jiJ5C2XjeROB8iVZ+xGfDEZJMjthJEa38
BJBZeFojOaFRdsoiH1y/y/B5ngkxeSER8dCWKHo8/pBbSLmFlFtIuYXkRpRbSLmFlFvIKrtA
uYU8xC3kJb00joR6QOScoKuDuSAEFUYKt8EXIew6YU6J6orcdk4IbaMip21W5LQNipyWVuQ0
psjtM1wyp8hpaUVOW1fkWIQlU+S0ZxU5bV2R0/KKnMbJs2uKnLZRkdPWFTmtUJHTUoqcltPW
tGLVTosVucsgJZFIxpazAJOohu2jbbAhW2AgNixVAtjxUiWINjdEMehSJYi0vlBoIHcLF34q
gqNswYLioRFFY4Kb7WAP1/YnhbEUxlIYi2FLYfxChfEGLfoCLtMP5iB4Z+t5jcI87nhxuKv3
ZcSLQ0WrxIvzdALcYgvWgv0fBtjiCACrplgQvIyW5Y6W5by1WkbLHmy0LIzgZxYt+9KjVWFE
uKJVDyYMNIk0EGvIAUQaQA1lpIGMNJCRBpwT4mVHGuxYq6Oq5Wer29HmFXFCFkoqeAer4NEB
ernqXYVTj6zZB3F6SuhUEdYHRQbw8H7EIPntAJFmsF8HeP63APL3wpffBL/xvnfBeVJ+Gz/X
5f9cQFyX/3MBpedOOfSOfk8g/esA678KwPEDAOmL/p+7yT9/ZX/BNfzPX3nfyNyAXnrrObvC
nOmN+Zy83tjYpDeW3lH//K3zySXz7Fr5/EXx7Cb49AXvuSvco7+jiKad3M0eZfSzGReWyOSZ
FF23Tkeg6J7nnV3Snr2dnV3Cvt3d6wC/vtqYCk7OpFW8iAo7UARVc/6YDqAkYzqkG/FFuhFD
/lmASVTD9tE22NKN+OndiDA027sRZUyHFMZSGEthLIXxAQjjtZgOQTMK06KFNippwy6HJk0B
y/VoeciNW3TLQ26R6M6fZCs99sZ5yI2Dc9fnASFTgQJzD2xNQh7qOeRDPYJLCW9BbE3IW1YO
VU+Xwl4KeynstyMhhb0U9pdigdvbBHW76LBjuV202xBuE1YZ03On9uxw47dZHf/P4G3o+c8y
wAfaVSSKo2wZ0sMf0nPU0S+v+9e/6dAdox8+ZYSPiz6HyG2o+UuP3HbRCwrYFjKl4XbmZDJH
W6MoIK4u+n9DwV0kI8BlBPjWEeDZVeDzCAp30YuPBceLi5m86uFj+svPfHm2lf6kQiUKJI8p
HXCkZbl4/h/DLMsrVx6hyBU+yQUkYx23inXUB1DjnYc6dq5HrWuW3agWALnvkMdyRp68hMhF
1owobDGVQJalRF5W/Il8bIfk7zIGgvfua35XEQVUOl2lHT62wy+QP0NN1cdVoD1eYp//MbLP
a4kFPgwMmDkoat6TayxsE9vp1+3zwJWB52y4hPSkvn4L6cKw3fbNeIR9UKslyeFnbwYiaCQ3
rHsQA8eaoFGWXsgojLYI7mGJ1QESuvIYV7XMbA3gGVzBAqveM7hmdGbdK92LUqxJsSbF2mch
1gR9aanNcakvKZivQjDSurAtPFxnUqqSot4kZhoQ1oOx5TRfgVLT6cHaFzga8T8aGDhqV24X
4DIecAFJC4O0MFS0MHBw8oswMaTaEdkYMikp6UpnvbCAZYYGgZ5LwWwwNQhJbGlrkEr5S1XK
efg7BSPV8t2o5TAKxlI0Mm7pPfhgEZgKoq1tAlKjKY0bUo5KOSrlqJSjPGjbGVO20Wf5IjXz
BxV5I9PkTR/iglceLt/74XJOnseYQkg+qoAE2cJI4DWvhudXxAPzZDVEuvOWx+TzS5IonmUH
XCfr4Zk7Wc/3G2O8VclfawJ5h6ryy5VHrjxy5ZErDx9LyZXn5aw8JY7jB8MOXW+JXAsSbTcA
ge+gewS9cLh+5OI6b7iyRszTLOT4wJ7l0iq9XEezeJv+R7+zeGXLncdcHmYuIOmGlm7oim5o
ccZ+EV7p4mZFTurnALI3Dez2irIK/V2MssG1vc2SIT3d4ts16aE5DA9NBXYvRpH+m3SB5nS2
mPnC9VzbJhT39qEaraQUlFJQSkHuPpVSkEMKCrmV/wNQSwMEFAAAAAgAc2FUQg8Ln/cBEQAA
hqEAABUAAABidWlsZGZyZV93bmV0X3g4Ni5sb2ftHf13okbw977X/4HXX/p1QSV3uZzvpa9G
TWrPaJ56Tdrax0NYDQ0CBUxM//rOfsCCYGBR70xq31XY2ZnZD3ZnZmcGcv6p023VpfZSm5u2
ac8kvT6+mymSYXpIDxzvSQo8hKSp40lT00K+FDiS7sxduJe//qr20/nCtAxMN0M28rQAGQzP
tBmr8RLZrm5KP8T/w6Tf2nPtHsloiaSK7VjOzJFIb66Gl2fDwHFl6cikEPW6MRye4Z+q1Ot3
O72PZzWJFPu97u9wf9X42G51Buqg3W2MOr+11VFfPW8MMezsW9xWyLguXXuOjnyfDZX37+uv
lIKDeZgYqq/7put4weqolM84KmX9qNIdTaKrvZE6agwu2yP1t/Zg2On3pGF7JI360s2wegwT
JoCr/AQLwn2SaIOyaS/XdGHsTP6eekh9tFGgLk9PxuYx/ERkU2iWsaJPJM6KQjI5sLqIQ408
M8zI1AJThg5mw/xAm7tAJB1NS3ZYOtIkAEtHhvSDdPQgVeVaTYYf6EaCvdggklzvpZr8Ic4c
931Iec/K9vvP35Dnm479l+TDJocb6dEM7qSWZz4gD+rOqkpFqcK/2vGb2KCidgUHVK45oe0I
kuplbEfW0eKiEyZ1r0Wnjb6obIH5LLLkE7IFcOKsCGQNhwh7WkaOFOxcfMcX3epFWZfbe2kx
uirTxCYvPcK0UBHkWHZgTWK84Pa+6znDJ1v/PmzYMifW1PDlk7Hv6WO8zC2kgh2kgvGjPpq2
4Tz66j3ybGSV3JFhTYVMH2Zp3I/fn1ShayfHp+/k6nhi2mPMCM+9bKDp6iausU286cYVGCte
helJS6qA7cjd4oPLlbXQJzwF4qOtS1QeXTdGv0imL8lyBf7BY6mISi4RXGluSRVfmyIf3UkV
Hf4506lUaS75kumQDQBXGf8vj8EInzv22LR1a2GgLNjYXUwsUydVfAqgFoPyNTggNevjG9Nu
tT4mFinmMNZcc0MEWPsbIjwa0/H9HH7ARHoeUwfToPLHXIIf6FVLvT09Uc9qcIcHCjdwNxy1
1Gaj24XbZr/X6ozgMam/NHotWJGXBBee4qdruKO3nd5wdFaF+5tO71g5q1XxPTzp2q0KBVbR
GxFKleCoFFBdVt9VFVoPy4GVOVanjUEn1WMJ/mPs1W670VOhM+oV3BCerfNLaB7ftH/r0lZU
uuQazV86vbaqntHZgJqL6z7BvXDyH/s4cD0VzRcWGCQyIEgpoObPyZpt+D6aT7BUqGciUZ1r
ST+L78LsnumW7PkutE3ZFhgLpcAduTJ1z/GdaSB9N/heOlaOJmYgNSvNH3+U+m5gzs1/sQCh
cg55ElMuUu2dDEvpuPpe+SAr1ffkHHxaBf5UlbhPnjm7A57N7yXeQpPoZg0rJVmSGpYlESxf
8mB/ew/IwIbDDnqkbNQjkJYWXiLfbOlxVb7BPIFjk16vRvT6SaV3TKSxWzm88psK/IPNW2GA
LXULc8uVXFtCAgm2JSSdHhm47GIlPCJW4CKMFdNijGKGoiwscWlGylyihWUu1ThCb0TJs6Ub
qeESjsPSUg6D14k5XMckHC2sl3K4NpR04bBa7fNPl9EYW61OqH5Zj6rRiHR6+UOvP+p3mqcG
Rwxgsat7Sm8un9h1TjGO9IkfeLAIKfjmll3fJsuX/9LrnRO4WqDf0VL7F/9IP2IYg/Dmgl2H
rOn3sLHDrZkv8sJd11/6mI5vv/7TUYxhuPv47Ksf24Neu0tnl2HIrPrjVetCvWr82h+EM6gO
RwO8oKrkkJJlfSRIO70M0uoHivNovD2hZtAzVgxHVUj/01YNQwmeXGSYFhvsRc4eHj9qHnZ7
yneYaSG7CBCLyIZCSNBFeazhJaSRM4yqWebMRoYKrSJZX1M51yzL0VPVuuanYEYWEJr30BzZ
AanBTVmmH6gGslCAkrAZDFyz4byJVpBt9JgEuI6rugv/Lgn9Z4G8JwKCuwVibXAA5sNLKXTy
S8p4j00W0ynyKI9VaNhT6EOwUhW1wUGxhvzVsfupgXMoGDv3vBgxhnOxfs94cECymkwOniUO
inqRv1pASWwJKW4052MTvaOs6J31C5bgcq2kJLWSsl4rKQmtpKxoJWVFKymrWklJaCVlrVZS
MrSSkq2VlGe0khLXSsqzWkmJaSWFa6WQrNUFHumaoxY9Gvc+XZ1DV2sUmCWmn9NttBo/lKRu
YwCLXd1TenP5xK5zjJHQbQrRaex6y9D+pVeu05RIpzGMQXhzwa5D1iSWj5GSosopWXNh5Avi
MUVNayf+jNLa5wwv+mI6LU93KUndxZVTQgsp4lpIDp3nenSrTg0nXnSTRbTEzkACQQ/wLGxy
O7ODYGKFeJMF1QRzNIewXpzaQA+mjkAtBMibajqKUaTq4nR3cIbwwRkUh5GlwOzvRBuTmesB
Fybt2ACJzl6v4mh9SsdRBnxaOBJXehE0rfVo1YraS3B1Q65ZejCs4YowpOWPgiGllCMHc+1I
YaF65H1hD5LXkqZ4kVJT3PBJ80rySwEp1cnBad1J+dGHv4rHO8Bh8V7QlUUxEmqVQ9ITeUmD
H/SsayBZJofjtSsz4cIFZFyO6+aoTDvLB7OGV0J1cwinXl3rHIdrdA6j01FgZIl9Qk1XPADq
MAWzVqo4i6DOvY9E4kX2LkHoXIJkatff1j6cvnkL8h5+jt/jnw/wc/IOft5X8Q+uPX2Pf6BC
UWoSluHYsQj+ZW1hBYTZXNPvTBvVTZCu2/PYAINsB0zXnHgaJBdcabY2i3k3PiScG5s6Wco4
gDMHss5Gpx6yXTdEheFOmwKJuVP+xq4biKT71ltJKortP/EMHbPDQYBc2x3zUM3trgUiXrfO
nijLXT1fwnwn804473RK8O/2Z4RbD7ua80zbZvu7ijezk+fL2e/oIfu7lGv+zoUat/t2xHoX
D5WYiTubc8x8h90OLd4dsY+vcuWn1MkRgNlGdabtXMCBQOuwNV0omhhZs0pJa3azAJ3yU3mT
n1Df3JJrwvInkIT1TyGAUWfTA7cEVmCGVmLHAnmCQtj42C9I4QpT0IN8USJ6Wi+KTc/rRbHp
AbYoNj2FF8XOPmiLPD3o2ibk8cO1IFnsDC0yl3GhEgkbqekhKlYsupmLMyPyA3ScBDiQiiZA
iJbkaNwF4YVbBmG5i5x5RcJJVSzds9fHoGqYYtXt5idb5aaAQk8TSWJkMtigdpo3nzWy/PHk
Jo/FO7rTrC9PJ+M9sqS31Q/g3x/eDtXrQb/ZHg7B59wYQDBh1G6OPg3aZ9988w2sHviVKB5j
jeEs29N/8nE1qf99OGpfqc3+1TVMwHm3rcLMtK/Ou7+rvcYVYRapHvmGqmd5+OQHaI4fIuyD
iYVYW908Zt3i3GjXI/pwXnB/SH3Fg9RIp0xWO6jJV5HXJZbPxUJGUSCJQ1IRpIzo0frIEfDe
cpJh7oPMDZZviJCbTJiLgHMI5Wi9YZftFjcwiNBXuYFzNOBh3+75vv2/JAfL0YLU08c7tiXI
/QD5zsLTUTox80SuyScfqqdydfODHslvFZCePNF1465vGnGJjuKip3AQf8kwVLEzOTQGI9/P
hNpkjzphiEKziHW8w7BX5aoNyqUOlvJl+wz/SHHoqH07OpMDtAwoeNhuYula7/Q6ozcGhfWv
R/VB+4IXOk1S2MgHgal7zUH7qt0bNbr1Xp/CPHCGaT6ihV6/1b5ofOqOup1zCrm5pVcDTRaz
2C3OsajrD2+m5nLhvnENLdBo7QOd1fqJzBp1/BRourBJ4MjVDHjxuf6OQMNXMGjBNSb4TWeY
WJ/N06jR/FivLt9W4b831WUNLqw/5K0jxmMx8YnurNtaAOA3sL4UWjWBUdYxXUQIq8F7ql8s
6WtLbVz6+ZRUldg9QFbEScMPn4IUHircxoojqCgZrROnwA6hElRuKSrqGBIhpM4hEQrqIBKh
oJ4YEQrqKBKhyHYWiT5h6OamLOJOoxKkMceR6BzHnUcRafbLfNisGmMGlPicRHL6DzBgy3n8
iL1GxYntwPHvPdsSo7rTBAke5yYAIprIaErRROYVocM21vjGmHYNrzRtTAKK9dkOIAsAC24x
skdjDi+OitEMAgv6KEYjy/jfo3VHi9piqd7H5zhufuPXPxOJPmJNgeZauAal4e8MCJiRlW+i
dwb4KwLsVl6XoJ+buJ+VrE/AYh6C/GTl4nn3yjYyqQshpRKoDynShxTpradI526e8QvJeoaB
sAzhsADSr1hkgX4RYUsfyygXWciNlIQdLRNZWDlYizx8ipQ+YYv5GPhRu/zBdrMTtZJ5sFWy
D7ZKxsFWiR9sFX6w3UJwPXWwVeIHW2X1YMvj8fxgqzx7sFVWD7ZK+mCrZB5slfjBVlk92Cpr
D7ZK7GCrpE6vyvqjrhIebC/9xMGWVG2yejF9CVIPlSZl8eFiBliGiV+cODTxxajuNEECauKL
0aya2ApYrQUOSmKNhI9DkIrbvNuNyLzqkGqRrwcdQjP7HZrJfZC556ANEXJDMLkIKyHVvQhf
4MiLwCTv8SdGog96CAyHf7TjuU90pF/1z391P/N1fbEFnf+ZjEJf5SiEVOirHIWQDp/u2PDT
HVQQp2vSHoBalgfg834AZIsf/jCjL3lEX/BI1lwYAptnXOhbHqLf7OAf5dj06xu1hAcAl8NC
0dxC+GYeRBP2PrOQdvOL5grSLrxa85YOL3MXJFEONu4LsHHpo3qhFm6JLCQ+5v1NRnpuh+nW
vibkRCGxwoP50gEx2rVXFA7b+OtDh+DZIXi2g+AZ3WiCobPX8JkhPngWd1uBZaR0ihw6Ckee
gEuByNMhpfJ/mVIZjzzlJlmGkafclMr8dcdXL6EvQeqh0qSvPbmsEE0quUso8lSwkfBxCFLx
yFNueD7/REox8gUlxTsE6AXF5CFAnx2gv1gWCtALrV/MQ5ScO2Q2o3/t4XrRrFrIyC1NG1sZ
Yn3+POkCXPwWSRHb2p9RKucZzs0Ms5FgQtg2cx2g8VfpDM75O0IH928Z9+9RS7287l7/psK0
DN99Tm+wjV58ogN0ez8THWz0GvIbbLR/aQ02OmQziGcz5IR88Z/y0x17as72N97L+3hIzngu
OWNFo/w/8jVs9LLTNLAi06NbNVjGS16i5JhGvEiFKcvxCDkJp0Ng7ZXaZy89IMlHsl/RSN6v
Lx6KPIQEtxkSVK+g91uPCLauh41rXl3bJE5Y+ykmYb5koJDvAcEo4R7F+/gYWLAvDiBzzeV3
hk+74EzwekyadGcXFtoHX/Yr8WXbS514cWhpjrwZqsseboZOXkGPtxL5tANfg3WN2BCebG1u
6tjzverxhtXlO1bc5Y2xQpbVuBd8rpl2czCCv0TtBQuX1BRcprxezPWsGQ+wQY8VMZ8n/WKF
KNXcfwCtqQIiTOIx7meeOxjQOanoG1mR91eMLObPzT39+XeLANwlNpgz+3v8i3USi1ZuDG9m
7cbYvnRzNzaU/bJ3Yx07GLwHg/ezGrxfzsKNrfqXa+LGBsFs3AQkJolBPISg/L8qgM3fotMU
Q0gbwMXl+MECPljAe2AB567TGMLBBt7UBobJ11zBTAjXefRcz5mKUYnY24+aGdiOi2wDgKbt
g+Sx0AOCUe6v+b2+z5tY3+u5vnRjXHBkX8w2F+xnvoFdyAovhHQw1Q+m+ucx1QU3wYuw3NeP
iRny6xEyX1MpEGuldemk60KJMYeXUg4vpWz/pZQiaxWTFafwkCgF1IlRQHCuBJFXhgj8pyWo
qLlxeKVmg+8lg9T1S76Es7tPHK+I/JLacT1+2n9T+iRwcOcc3Dl74M4RXbbr8Q/OHkajT2fz
mSfayYQk+w9QSwMEFAAAAAgAbmFUQup/2+rFEAAAP5IAABQAAABidWlsZGZyZV93eHBfeDg2
LmxvZ+0daXPaRvR7Z/ofdvqlVyxgnTgOM+4UA3ZpODxAEreloxHSglULSZWEjfvr+/YQKyEO
LUdjp3RctPv2vb33XfukXH5oNGtlVJ8ZE9u13TEyy4O7MUaWHRAz8oInFAWEoJEXoJHtkBBF
HjK9iQ9p7euvPMMMkO0+GI5tGRFBgedF5dn52SggqGBMI890iOH+PSVT8vVXpZ8up7Zj0UbG
xCUBEFi8UqhCtDuYEdc3bfRD8j9K+q07Me6JRmZQses53thDrOut3vVFL/J8DZ3YHKLfVHq9
C/pTRO1Os9F+f1FCLNtpN3+DdKvyvl5rdPVuvVnpNz7W9X5Hv6z0KOziW9pWXHEZ3QSeScIQ
upzu39df4ZyDeRhaemiGtu8F0eKo8H84Krx6VNmOpidBb/f1fqV7Xe/rH+vdXqPTRr16H/U7
6FOjfXsDdasgl36C/eM/IT6Rmu3O0lM78IZ/wfbRH2e+DjtpYJ/Czxx5BK2JCnif5xVkR7G0
pjnViHWlxNaMVmgbka0xWBgZEx8Q0MlIqWvoxEAARicW+gGd3KOS9g6dPKCiVipp8AM9X9pe
jzc3Vmvrj48kCG3P/ROFcE4hgR7t6A7VAvuBBFB2UcQFXIS/0umrRA9So9tu3pLDXBjffCxb
1rzdoPLyFZdEz5qvuET14MVniRMnjwKDLJ1vUbTFCdhc4eqtIbe5WoXb7ogqE1G0ue/aXu/J
Nb+P23XsoTOyQu1sEAbmgC6BQ3SQdjqIOP3Rdi3vMdTvSeASZ8vdEpcU2OTRKq37wduzInTt
7PT8jVYcDG13QCuiM69ZZLS4wUpig+26qRTGSk9vdtLSPGk/8iv/4DbKLOgTnQL10ZYRP1c3
lf4vyA6RphXgD5aloHgClUQfcN+JgwqhMSIhuUMFE/680QgVqjO5aRrsCMBTo/9rA1C2Jp47
sF3TmVpkGWzgT4eObbIiOQlQSkEbhQrgVMuDT7Zbq71P7VJawcDw7R0RYPPviPBojQb3E/gB
gboe0wQdq/D7BMEP9Kqm356f6RclSNGBQgJSvX5Nr1aaTUhWO+1aow/LpP9SaddgS14zXFjF
DzeQ4slGu9e/KEIa1vAUX5SKNA0rXbrVISMK2n1GqTMcnQOKs+KbYomXw3YQeYnVqFPQWfEU
wX+ier1Zr7R16IzeggSrs3Z5Dc3TRP1jk7ei8y1Xqf7SaNd1/YLPBpRc3XQY7pW3cdUHkR/o
ZDJ1QFhqUI4yQCOcMFmwYrovgYXRyqgFwH5MB/2sfhCX9s10tCD02XmphCGZDClPKq/oIt6q
i3xm1rROx96yzcALvVGEvut+j07xydCOULVQ/fFH1PEje2L/Q9kR55okQEJUoRI0XtROi2/x
Ow0X3zLb6bwI9XPB5D8F9vgO6qx+j+YtQC0BaEgGFXEaQhXHQQwrRAHwiuCBWBrjdA5d3W/2
M8+Fb2iVUGGVP1t9/vyg85TgRSKpxU+ZKMAfHLuCAOynV7SyjSxnT0jAevaEZHKjSTIdkaMj
EhnJe0Q2y384ZsyD4pxkQywvWVGcl+xIIrT7c/IsW+IlkjVJWJY9UfAq/kTLBGvimdXsiZbG
LCoeVq1++eF6PsZarRHLTdGjIo5HZPLH72b50bwzAj06EQBHPP1znrh+Es8Jxzgxh2EUwB7k
4E+34vk6nb/+hz/vvMg3IvOO5+q/hCfmicDoxokr8eyJpt/yZ2cWisTTSVwi505/X++2600+
NwL8vlW70luVXzvdeNx6r9+l26BYSqE02ktQiu84zqP1GlZJprFoNXryiWU7oi9XG87K4NEI
qPtH40PXBgadN4Op3Dp4d8YusXQ4qkQzVxRODMfxzEyxaYQZmLUMCB0JyIS4ESuhTTl2GOkW
cUhE0rAxiXTDBbOSLCC75DEN8D1f96fhXRoK/qjgiYGYZ0q0IQG0HpnLoLNflqcbazgdjUjA
61iExj2FPkQLRfM2JCjRULg49jAzcAkF6Xgvs/OKwYgz70UdEpAuZpNDZ0mC5r2gG2H1LgDB
ewD5iHeSjziWjxuFPBV9WIg+HAs6kWQVLdOzKXyN/k2Lszo4A+fRwwEvj0jbCxKItD0hJXXz
zdhMSuKUlMRJKYnTUhKvlpI4JSXxgpTEC1ISL0pJnJKSeKWUxEukJF4uJfEaKYmTUhKvlZI4
ISWxlJIxWa0JdWRLTmrcyG5/aF1CV0sCmBU8eJ2s5cV0x6ZlrQA44umf88T1k3hOKEZK1mIm
Y8XzVqD9w59SxuK5jBUY3ThxJZ490STd07GMxVzGpkuurI0HbMAxs2JXLlFW3F7QXb1ZWOMc
whonhDVOCGucEtZYUVgDvhb7hc15Uh9ZXjLrp7NkRr2xDEIeYClclhy7UTR0YrzhlMvoCZnA
LVCS2iIPtklAYEckGBkmSVBkypJ0d8CwQ/AqJWFsJwhrINXGcOzDVqJ9pGOMB0hl0hrlQ5ZL
7YMDs+oHrVZO1hwrq4/wogWFJEXvx/TLNBRZEktnDsnoKPMq5QpJTKm3cFhSceGEYiFlKWtK
ZrPU9FcQ86XnhRmlRoKzWg0n54u/iCc7sKjjcCq+szhGSuGRkOxEXnMPP1csLKJpTFyv3Jkp
XzAg03xSa5rneWflYFbUlVKqJERSL+51iSN1LQnj05FjZOlzouSYoQNFBdBJUMGbRmXp6mRc
ca6sMITGNXCvevl16d35q9cgFODn9C39eQc/Z2/g522R/tDS87f0BwowLiHK5qkPE5zZxtSJ
WGUTw7yzXVK2oTt78w0B/XL3TNMeBgZcV7cM1xgntM13KWVzDy6Y/YxjhWbNnXEHbodzy0O2
BBz2kNVbB65/zvv33Uhaiux9sZfIn8MNAVjeweqOZeLBGmB8d9+1M4F6oKVldR9izlnFh5wP
+rv36ZAaxYHme6m6s/fDJFs5xNLK2g+zvuEBWVl4aD4mtcDD1HyA9WQq46Hmm9Z9uE7Huu9h
ak/ubvxTxoSkwKx2rXR1uKBEb3Y28CKqVee5c5xrtXhLrXZXx+n2mj+j/nTLnikDgEFSRgCH
AEZZzA4kGWzzBC1cV+ePlVNBpo4ANQJflYDb9TlpuEmfE5mb8DmRuY2bE5nb6TmRl1viCosG
/dqBOml7q1ElLGyFWUwyGkbFuUpAOKtx+PHNXRfjFyDwEKBAvFt+OjJjJnET2BRtF7jnIQKq
MaKBWyLcsd2hoGIcxtVsbg7o2hgCCT1NBaKxuRCDOmhQ9bKRbR7PxgC1/zCoOjDZiE8c9Lr4
Dnz/vdueftPtVOu9HjikK124aOjXq/0P3frFN998A/sHfhHHE3VTuNhO4VNIi1n5b71+vaVX
O60bmILLZl2Huam3Lpu/6e1Ki1U2FzbaJy6xtd5TGJEJXUY4B0OHiLaamypr5q+Nd31OH08M
7Q8rLwQQgOnlP0EgDr+IkDG1UDFxiTS/WpKQzJ3Skvuk1XdJUPcxfHGb8EVtvh+p2rrHYw2s
6Is81nnfLzie7+d9vpPr+DIPOju+8+1mZq8oxMZn6S4JvWlgkmx4zJlW0s7eFc+14u6XFYr2
rZJpC8wkfceTy9B174Whu/Pc7Gry5p4bGjacf5+ujB9uxJcKhsNU2gPeURVadeD8ZVBvr+sX
9Aclof36bf9Ci8gs4uBevUpZXrnRbvRfWRzWuemXu/UrmWlUWWYnRwGlble79Va93a80y+0O
hwXg0DJCwjPtTq1+VfnQ7Dcblxzy6ZY/LTKcjhNJGjNRNh9ejezZ1H/lw/unBi994LNaPtNE
o16YAY2mLrvq8Q0L3nstv2HQ+M0MnvGtIX3RFSY2FPPUr1Tfl4uz10X471VxVoKH6A97HYmn
2SUbYJ2DIAij6bC8/B0gygkHsG8GFOdNCWvQlujEdBgyyVh2jQjqfQXYotdDmKYybXjeMmyn
4Kl8NeMvRNVp7udzVqR+mIEqhydGGpxqBAHJ28KCrycnFS9SJqA+H3Uifxsi7vtRoOP+HwUC
7gNSIOD+FgUC7gtSIFjuD1JcWOjjjjUk/ULqlAnfkOLsJv1Dc8r1HIHTXrJ7m84DDNbxHt9T
x1BuWjfywvvAdZSI7gw1/MeJDfk5yVyYZkjmBhCjo1bQ4JM1alrB1rQJZqfUZTeCK37K45Wo
Hq0JvHuqRNKNHOigEomm0b9H545njelMv0/Ob1J3pu+PpoJ3lFoCATf1LUbyQoK4kyrXc4vm
TvbtywnrPgZqHwO1Dx+onTw7ahHbzyv2GsYh4pTjDPDiXJcY8AEAUGcOfzmzw5WM7KbyBUZu
C1t6HxQ2B8fJuiGUjHXpj9jeWt9V3i2z1vFyax0vsdZx0lrH0lrfw7V+xlrHSWsdL1rrMhJA
Wut4rbWOF611nLXW8VJrHSetdbxoreOV1jpOWOs4Y1HjXe13vNp+x7G1fh2mrHVWtMPmp+Tq
lAHZllLccufSNZdYMblpYytGiejOUMPnVowSyaIVgUE332wFKjURL4MakdTr93shDIvOBcAX
e3/Eh7dq9STG8RLpBVwi8aV6mVdIW9wVyyG/tDsneq+Sd+nErUqe4CCXPO+YIOjfS/i4zMYl
kZ+PWfOxmKzXpbTe61Ja4nVhYIVzvvlzLbm+DpMLKdfXYXIhJc/+ZuzjB2d2/OAMF2XZkqyH
prTMQ/PffrZmj5+rsbOfq0mXXFl5z9lg1Yds+EqteqP+JXz+JjV28TGUBZhiiOY+Y7lAhHyR
uvj6D4Iete9ttO+Tmn5907z5qMO09N78l8q4S156IBfbdOYLDlaCAazRpl/I9Z9Lnt2tn0uO
l33Hy759Xval2fT/4/7PJS/62o9KB3Oe1KNZMhekcp5tJbOc94g7Qw7b6qMu9NIgt7Ke9ORu
vjXjeKvuzI4Rrv/jCNfkndnhY15zR7iqbn9ahSK1vAbYifwYB/jc4gAVbvDyNZG4jNsYC0L/
CQ/Tc0f2+PkGgsg+MpElJZ5iUIiCiKOWTKZ1pTcu9mHN7CqohDWTayCfzaMuu/W53elHt/Y+
3dp6C3q/d6927aZXuZHFpR193Z/Juy33vJpr+xk5qeUQhIc6CUjw6WDGs9IY2dXa2DB5sphK
rrShkZepH62ML8TKcGcmuxbguQkJxqSsBbQZPnk5bRE8tzai0ICTQMQQnlz4lytNapMsmhKw
uULPWXx/jlW5+ALdxLDdarcP/0ZZEE19VpJvl8piJa3esB7gQJ9iJZ2Sv3+kSDQJH0Cm6oA3
Yx/f2qRoA3KSUKmt7d6vWXgfJeUiWfXtro06dXg3jcBF70Idz1epTnRSUY1WuBCQvHuz440X
ZZ1Dea4UBL9WkitUxc/OhdKNhYI02PVi4hinfYzTVj9IlCo3QUAUCaBIiQBsdnWaYAsaUDLV
iTjTP0aYx3JUjcqyw+1C0vO8W5qvDwlZ/hLcMQmh86z8MYl+HR0yR4fM/8Mhk9j0L9YjkxiD
cMmkIBvD1x8NO3I9n7gWAG03BK3WIQ8EBMLzDWlf3Wf1CMktDIfVza+wI5StFGlB5dypifKs
/yu3xQMG1UsJ0lJbg88WuKXWzc2BU7nitHIhgZQ9OjqPjs7P6egMFZja0dW5rasTJt3w1UIJ
fO8x8ANvpESUMMSOsZ17i+1k6rtyaOf6OM6s+r5jdOdniudUE64vIsZz9ZBE6OY6BCV9VqqY
283mavSsArqt5nz8VMoX4oJP6Cl4mZ6S01Ev9BSc1FPwop6C1+gpOKun4OV6CivZbteuRldy
M8dajJI3lGsxikRLtBisrsXka8scjSfjQLGDKdXiX1BLAwQUAAAACADOYVRCWYGMGyoHAADO
PgAADQAAAGdwbHB2LmxvZy50eHTtW1tv2jAYfY+U/+C3tg9jQDvWoWlS112lXaRdtD0gRSEx
JKtjZ7ZD4d/vcxJIICQkOMA2tQ9twfY5n4+dz5ej3LJwwf2pJ9H57QX66DucCTaR6JbxkHFb
+ox20A0hKK4kEMcC8xl2O6ZhGrfDkTftj3wqpE0I5p37uTh/+uQCDRHmnHH04e27b91e9xK+
+OZhJBZC4gA5NqVMoolPXSQ9DP8QjM7mmJpG6PgjNv414di6p1haNx9fDa5GduDCb6gAxR3H
lmedMu7rA3H/cCe37P2SC2C7zzouIaWBXOuIMBu7lnCEDwMgq9SAepVqXOuo0SAIaCWBEjBL
Q+l19xbENKiKoyKGuFwpUUE/ODS9TycV9E8PTV8pfu9Kgx4YK9hVcbX0/UsN8kiMK8hV8Q5y
nZ7XIK8c9b7OnK9BXjnmfZ0pt2cq/OpP6TfGCHqtaIfojUKMOVhE3SF6LE3j5ff3H14NYX0J
QlVqA/kHn95BFY7m14NVha/S5hJJP8BD9AO76A0eo34X9frDXm94NYD/e5eryq/nduBTn06R
E4uBXJ9jRzK+QJJjrMDj7gkkGXISaoi39yJt/zLyiauaTzHFsOoBX1LdpyliuvpkwKbRb9Y6
n1AzmMZBxDDQUsFoRENxMYhsXFTz80/s64I6F8tGxB+TiSs6g5HgzkhAFYItgLBAXOseJhG7
F9Yd5hQT5JpGLrLd2NvEvRECB+O4+iOUVBj5l9eDkQy5hYOIQNc6tghU8DFyWrVBnCN7LCS3
HbXLsWwCsxe71oSbBsYdB2JY4WYhrHYhbdMGtmkQwpz2kB1b7OiFNXFZe3wuELaH5lOH4wBT
Cc+pFugEEgDxhbRcTLDEuyQJdSVZ8U0hcdoUnlYsFWIrmBTf7+oAnqvU0FIfQhZaYSS8luB+
R5gvSjuAZ9LxqB4VMEQ4Heo2kKoEn1Ipx6QNlliXloCiyik+jjSfUQ6l42gywbwVlTO41fMS
RrBNKO1DgAOmq1VGqsa3NawWRlE0yFQunvkOhkQJh6+J7WgOhNjIWZoZJN18xFsy5uJOp1M5
Jw/SGWh41waO9hyBvbJzV3NUPbhnEQuquQ+IGdsKXC0AaiXYFXpoQ/5OmmpmxZi3jeepOA0V
2mqL/MEfc5sv1kDHPk32mcuv4O+OB3E8DTnM3DJ9Sh6GYhQZ7toJjHgWnIzioNIiFVO2aY8P
UAoIBKhxXMkChCd92bbWQWXVUl0Dsog7WBQ2xnwlQrHmBnhKBk0U+DKQ13PsRNIeE9xEEDjT
rvGWsymyRlJsPWwVoy1jzD6XxT+DsXRVDxoOUnLvVnOIll0pCJ81Ka+4e0yTWNYj25wLO2qX
zoJiVNnn2roWgavD2Qaa3XeaRnrj2WAywZG7+fPowP28w+jEn9YcZ2BJybbIn6HlgDcybAHG
2S5fGdw24fJseI4r+Sw53xGRxXfWYD5M2roaCy+SsGjQgNFM5Gp8uEOC2sWEn4PKw5aGW1wZ
totdDr1N7jVqUHuO60pxb/uSshBTtTAtbxRncAoX68oUI9yUaFtcadG2ZF1OXBFT2dTcF0/F
bBqbUVc0SCZzKuwbuIEUXtmV5ZP++pXlK0axuhRA8PP0KrmiW15NusnXfUTinYEPJeMIslLy
9TXCy55mBZlzd/7lAv1IdkFodU2LfgYkGXn1YYa58GGyX3a6nSdXvWedrmloGYFrd8/1glGj
dohQDutJ5qbFUf3IHG9jL/KZTufrrbOxD3kM8y/HfGzjL0d9bNMvR31kwy/HfFyzL0d8XKMv
R3xcky9HfFyDr2ZuqWPu/bj58un9p7dDNB9coU+QqWcYOatV3hf0TCIRhSqZQLpG34X6WqX3
1dLHBVB9vrn9gmDv4kvoG48ojXcrhGPbXVQ7iLFRWc9DfHLZiocIC/I+DtlNJNkjh2A7ZlTX
tgnDmWlwxuQw9lpheM7QeX+A2ATBUMT05+ICFryAwXp3YRrv6QwMJDfZQcay3ds8hiRsmgCu
wzX2Gw9jet7GZ4GIL8PeFirs4p7HZYy+2I8YuDTd1n/TJk2Mem8RYu7Ag/zgkj64pE5di67e
LfWDS/rgkmZI+kZDzgY9jt0aafY7s/1qPDFtmq5rLmlrqDCAx3JcW3B1/jKX9B/3NY/lRtYb
r7ZNRO3U1MwDTb1AzZVlzf+s5VjGW768ZdnUYUwA4t8PJmNRk718Rn2bcD0C04CK+ziFxZNQ
A99qm9W4W/6C1bjTnWxmIW4SKPwmVmNf22osH5ueltuYw00rmQbU+kcMx51Ooq4fCf6gjiWZ
VzerkbhkdVzHeiruYSmCZanvJ27YkzpmYl6orApMc2V6NfcAc3BpaZM8Vs+X/OstxZwIbbiK
/WG39+Aq/heu4qledCRe3Zd7juctNnzNsV178YSvFhLvlG8WEu+ELxYS73TvFRLvdK8VEu90
bxUS73QvFdZPO3Vsx2W4L/4AUEsBAj8AFAAAAAgAa2FUQr7rNPa1EgAA39IAABYAJAAAAAAA
AAAgAAAAAAAAAGJ1aWxkY2hrX3dsaF9hbWQ2NC5sb2cKACAAAAAAAAEAGAAAu6gCWw/OAeDC
00JYD84B4MLTQlgPzgFQSwECPwAUAAAACABmYVRCN6gt8KAQAABnngAAFAAkAAAAAAAAACAA
AADpEgAAYnVpbGRjaGtfd2xoX3g4Ni5sb2cKACAAAAAAAAEAGAAA5b/9Wg/OAUBZAD5YD84B
QFkAPlgPzgFQSwECPwAUAAAACABjYVRCuDHh1P0SAAAx2wAAFwAkAAAAAAAAACAAAAC7IwAA
YnVpbGRjaGtfd25ldF9hbWQ2NC5sb2cKACAAAAAAAAEAGACgG5P5Wg/OAaCtujhYD84BoK26
OFgPzgFQSwECPwAUAAAACABcYVRCi8pNsQMRAADtowAAFQAkAAAAAAAAACAAAADtNgAAYnVp
bGRjaGtfd25ldF94ODYubG9nCgAgAAAAAAABABgAgMkK9FoPzgFg3Eg0WA/OAWDcSDRYD84B
UEsBAj8AFAAAAAgAWWFUQpk0Cm2nEQAAUJQAABQAJAAAAAAAAAAgAAAAI0gAAGJ1aWxkY2hr
X3d4cF94ODYubG9nCgAgAAAAAAABABgAQAOs71oPzgFgaQswWA/OAWBpCzBYD84BUEsBAj8A
FAAAAAgAgWFUQl/ZAizeEQAA5M8AABYAJAAAAAAAAAAgAAAA/FkAAGJ1aWxkZnJlX3dsaF9h
bWQ2NC5sb2cKACAAAAAAAAEAGADg2lMbWw/OAcAk8VtYD84BwCTxW1gPzgFQSwECPwAUAAAA
CAB7YVRCGCp46JUQAAAAnAAAFAAkAAAAAAAAACAAAAAObAAAYnVpbGRmcmVfd2xoX3g4Ni5s
b2cKACAAAAAAAAEAGAAgIS0WWw/OAQCiKVdYD84BAKIpV1gPzgFQSwECPwAUAAAACAB3YVRC
EsX1hrwSAAA22AAAFwAkAAAAAAAAACAAAADVfAAAYnVpbGRmcmVfd25ldF9hbWQ2NC5sb2cK
ACAAAAAAAAEAGACgB60RWw/OAQBplVFYD84BAGmVUVgPzgFQSwECPwAUAAAACABzYVRCDwuf
9wERAACGoQAAFQAkAAAAAAAAACAAAADGjwAAYnVpbGRmcmVfd25ldF94ODYubG9nCgAgAAAA
AAABABgAwDSSDFsPzgHgbqVMWA/OAeBupUxYD84BUEsBAj8AFAAAAAgAbmFUQup/2+rFEAAA
P5IAABQAJAAAAAAAAAAgAAAA+qAAAGJ1aWxkZnJlX3d4cF94ODYubG9nCgAgAAAAAAABABgA
YKUOB1sPzgHgjalHWA/OAeCNqUdYD84BUEsBAj8AFAAAAAgAzmFUQlmBjBsqBwAAzj4AAA0A
JAAAAAAAAAAgAAAA8bEAAGdwbHB2LmxvZy50eHQKACAAAAAAAAEAGABgTs1xWw/OAcDeWl1b
D84BwN5aXVsPzgFQSwUGAAAAAAsACwBnBAAARrkAAAAA
--------------000304010201070109050100--

--------------ms030400000108080603080105
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMDExMjMyNlowIwYJKoZIhvcNAQkEMRYEFDerXRF8XDxmPY2TVgMuA6+5
QH+/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEARlcHZW5dW6hy8tj2lZjEopuI
v3qRuiLjrvEGnTJIN8+Lvz7fJBp9RHiaTwP8t0yCUpX6tgzzIxyf3n/yodLQ6WM6eU+X+1vD
rrNXoglJ5Qz6hg7TESttW1V4HcEugfqtLheM5E6bPEhygYfi6wrxnfyY2Is7Ly3zKHEL1vOt
WtQlwD1AfEaRm5gJ3pryXlR/2OopLFlAaYr7va8GzGHJmQDw263YoX5mNuCwkld1X2Nrh4Ex
PQ9i6ldbh7n+yXERRtVs4dkbFJf2T0webgZ8jdcxjhP7AiAWpUPdLn8NpDSb3hT/MCgW1tY2
9A80HfsEtFtInKZW9jGhWDk/Fn+IZQAAAAAAAA==
--------------ms030400000108080603080105--


--===============3293686369349480672==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3293686369349480672==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 11:48:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:48: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 1U889o-0003mp-8B; Wed, 20 Feb 2013 11:48: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 1U889m-0003mk-KD
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:48:15 +0000
Received: from [85.158.138.51:4930] by server-14.bemta-3.messagelabs.com id
	9F/2A-23533-DF7B4215; Wed, 20 Feb 2013 11:48:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361360888!26595748!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8718 invoked from network); 20 Feb 2013 11:48:10 -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;
	20 Feb 2013 11:48:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7982214"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:48:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:48:07 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U889f-0006eJ-2i;
	Wed, 20 Feb 2013 11:48:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:48:06 +0000
Message-ID: <1361360886-2956-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX v5] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since V4
  Rebase onto v3.8
  Fix wording of comment
  Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
  sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
Changes since V3
  s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
  Add comments about the correct bitops to use, and on the ordering/barrier
  requirements on xchg_xen_ulong.
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 +++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  115 +++++++++++++++++++++---------------
 include/xen/interface/xen.h       |    8 +-
 4 files changed, 96 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ xchg_xen_ulong\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 74d77df..dfd62b5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g
+ * test_bit/find_first_bit and friends but not __ffs) and to pass
+ * BITS_PER_EVTCHN_WORD as the bitmask length.
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+/* Find the first set bit in a evtchn mask */
+#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +354,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +390,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +404,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +418,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +426,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1204,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1220,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1229,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1291,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1313,19 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be cleared /before/ clearing
+		 * selector flag. xchg_xen_ulong must contain an
+		 * appropriate barrier.
+		 */
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1333,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1346,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = EVTCHN_FIRST_BIT(words);
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1361,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1371,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = EVTCHN_FIRST_BIT(bits);
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1383,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1396,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1506,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1555,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 20 11:48:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:48: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 1U889o-0003mp-8B; Wed, 20 Feb 2013 11:48: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 1U889m-0003mk-KD
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:48:15 +0000
Received: from [85.158.138.51:4930] by server-14.bemta-3.messagelabs.com id
	9F/2A-23533-DF7B4215; Wed, 20 Feb 2013 11:48:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361360888!26595748!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8718 invoked from network); 20 Feb 2013 11:48:10 -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;
	20 Feb 2013 11:48:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; 
   d="scan'208";a="7982214"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 11:48:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 06:48:07 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U889f-0006eJ-2i;
	Wed, 20 Feb 2013 11:48:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 20 Feb 2013 11:48:06 +0000
Message-ID: <1361360886-2956-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>, linux-kernel@vger.kernel.org,
	Jan Beulich <JBeulich@suse.com>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH LINUX v5] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Changes since V4
  Rebase onto v3.8
  Fix wording of comment
  Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
  sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
Changes since V3
  s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
  Add comments about the correct bitops to use, and on the ordering/barrier
  requirements on xchg_xen_ulong.
Changes since V1
  use find_first_set not __ffs
  fix some more unsigned long -> xen_ulong_t
  use more generic xchg_xen_ulong instead of ...read_evtchn...
---
 arch/arm/include/asm/xen/events.h |   22 +++++++
 arch/x86/include/asm/xen/events.h |    3 +
 drivers/xen/events.c              |  115 +++++++++++++++++++++---------------
 include/xen/interface/xen.h       |    8 +-
 4 files changed, 96 insertions(+), 52 deletions(-)

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+	xen_ulong_t oldval;
+	unsigned int tmp;
+
+	wmb();
+	asm volatile("@ xchg_xen_ulong\n"
+		"1:     ldrexd  %0, %H0, [%3]\n"
+		"       strexd  %1, %2, %H2, [%3]\n"
+		"       teq     %1, #0\n"
+		"       bne     1b"
+		: "=&r" (oldval), "=&r" (tmp)
+		: "r" (val), "r" (ptr)
+		: "memory", "cc");
+	return oldval;
+}
+
 #endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->flags);
 }
 
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
 #endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 74d77df..dfd62b5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
 #endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g
+ * test_bit/find_first_bit and friends but not __ffs) and to pass
+ * BITS_PER_EVTCHN_WORD as the bitmask length.
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+/* Find the first set bit in a evtchn mask */
+#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
 		      cpu_evtchn_mask);
 
 /* Xen will never allocate port zero for any purpose. */
@@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
-static inline unsigned long active_evtchns(unsigned int cpu,
-					   struct shared_info *sh,
-					   unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +354,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +390,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +404,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +418,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +426,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1204,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1220,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1229,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1291,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1313,19 @@ static void __xen_evtchn_do_upcall(void)
 	unsigned count;
 
 	do {
-		unsigned long pending_words;
+		xen_ulong_t pending_words;
 
 		vcpu_info->evtchn_upcall_pending = 0;
 
 		if (__this_cpu_inc_return(xed_nesting_count) - 1)
 			goto out;
 
-#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
-		/* Clear master flag /before/ clearing selector flag. */
-		wmb();
-#endif
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be cleared /before/ clearing
+		 * selector flag. xchg_xen_ulong must contain an
+		 * appropriate barrier.
+		 */
+		pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
 
 		start_word_idx = __this_cpu_read(current_word_idx);
 		start_bit_idx = __this_cpu_read(current_bit_idx);
@@ -1314,8 +1333,8 @@ static void __xen_evtchn_do_upcall(void)
 		word_idx = start_word_idx;
 
 		for (i = 0; pending_words != 0; i++) {
-			unsigned long pending_bits;
-			unsigned long words;
+			xen_ulong_t pending_bits;
+			xen_ulong_t words;
 
 			words = MASK_LSBS(pending_words, word_idx);
 
@@ -1327,7 +1346,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = EVTCHN_FIRST_BIT(words);
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1361,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1371,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = EVTCHN_FIRST_BIT(bits);
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1383,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1396,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1506,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1555,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 5d6c272..a9075df 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
 	/*
@@ -341,7 +341,7 @@ struct vcpu_info {
 	 */
 	uint8_t evtchn_upcall_pending;
 	uint8_t evtchn_upcall_mask;
-	unsigned long evtchn_pending_sel;
+	xen_ulong_t evtchn_pending_sel;
 	struct arch_vcpu_info arch;
 	struct pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,8 @@ struct shared_info {
 	 * per-vcpu selector word to be set. Each bit in the selector covers a
 	 * 'C long' in the PENDING bitfield array.
 	 */
-	unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-	unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+	xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+	xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
 	/*
 	 * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 20 11:58:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:58: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 1U88JJ-0003zw-5j; Wed, 20 Feb 2013 11:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U88JI-0003zi-Dw
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:58:04 +0000
Received: from [85.158.143.99:2689] by server-2.bemta-4.messagelabs.com id
	1F/26-12656-B4AB4215; Wed, 20 Feb 2013 11:58:03 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361361482!18569606!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12390 invoked from network); 20 Feb 2013 11:58:02 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-8.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 11:58:02 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U88J6-0001b9-RS; Wed, 20 Feb 2013 11:57:52 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U88J0-0006yT-0g; Wed, 20 Feb 2013 11:57:52 +0000
Message-ID: <1361361460.23294.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 20 Feb 2013 11:57:40 +0000
In-Reply-To: <1361271060.13482.184.camel@i7.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
 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 Tue, 2013-02-19 at 10:51 +0000, David Woodhouse wrote:
> On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote:
> > I expect there will be some rough edges like the NV variable thing -- I
> > have a feeling these will have a lot in common with qemu/KVM, since they
> > would tend to interact with the "platform" (provided by qemu-dm under
> > Xen) rather than processor or memory virt etc.
> 
> Well, it's mostly just storing text strings describing which device/path
> to boot from. So hopefully if the flash storage itself is OK for Xen,
> the rest should just work.

Ack.

> > For the most part the I reckon the Xen specific things will be resync
> > with a recent upstream and fixup the Xen build system integration, stuff
> > like that. 
> 
> Current upstream OVMF works, AFAICT. Although as I said, I haven't even
> tried booting an OS.
> 
> One thing I obviously *also* haven't tested, therefore, is *rebooting*.,
> We've discovered a KVM bug on older CPUs without 'unrestricted guest'
> mode, where after a reset it actually runs code from 0xffff0 and not
> 0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the
> OVMF startup code that we *should* be running, that's kind of a problem.
> 
> If you have a similar bug, please go and fix it so I never have to
> know :)

I've not heard of such a thing, but I've been half following the thread
and it sounds a bit, shall we say, subtle ;-)

Under Xen when qemu gets a reset event (via I/O writes or whatever) it
ends up with the toolstack actually destroying and recreating the
domain, so I think the issue you are thinking of doesn't come up.

> > We'd like to see PV I/O drivers at some point but that's a separate
> > project in its own right I think.
> 
> If you have an option ROM for them, that might not be a high priority. I
> think OVMF can thunk into INT 13h for disk access.

We don't have an option ROM, but that might be an interesting way to
approach things, although there are issues with teardown before the OS
comes along which endbootservices solves nicely for us.

> > > And on the subject of the NV storage... does -pflash work on qemu-xen,
> > > as long as we're not actually running *code* from the device and we're
> > > only using it for data storage?
> > 
> > I'm not sure, I've CC'd Anthony & Stefano. Assuming the Xen machine type
> > in Qemu wires it up then I don't know why it shouldn't work and if we
> > don't wire it up I don't see why we couldn't.
> 
> Qemu does but not in KVM mode, because it can't *execute* from a region
> and also catch writes to properly emulate flash. But for a flash device
> that we *don't* execute from, because it's only used for NV storage and
> not the firmware itself, that restriction isn't important. So I'll need
> to fix that.

Maybe it would be useful to emulate a dumb NV RAM region, as opposed to
a full flash emulation?

> > Hvmloader might need to be tweaked to setup the e820 correctly and
> > perhaps the some table or other would need to refer to it also?
> 
> Right. Haven't quite worked out how it would be 'found' by the firmware
> yet. I was going to suggest making the address available via fw_cfg...
> but you don't implement that.

There's a little protocol between HVMloader and SeaBIOS which
passes the tables across, see src/xen.c struct xen_seabios_info. Perhaps
HVMloader+OVMF should be (or is?) using the same (or similar). Either
way it should be extensible to cover this new info. The other option is
an HVM_PARAM, which is Xen specific, but pretty simple.

Ian.
-- 
Ian Campbell
Current Noise: Old Man's Child - The Flames Of Deceit

Did I SELL OUT yet??


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 11:58:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 11:58: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 1U88JJ-0003zw-5j; Wed, 20 Feb 2013 11:58:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U88JI-0003zi-Dw
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 11:58:04 +0000
Received: from [85.158.143.99:2689] by server-2.bemta-4.messagelabs.com id
	1F/26-12656-B4AB4215; Wed, 20 Feb 2013 11:58:03 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361361482!18569606!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12390 invoked from network); 20 Feb 2013 11:58:02 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-8.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 11:58:02 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U88J6-0001b9-RS; Wed, 20 Feb 2013 11:57:52 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U88J0-0006yT-0g; Wed, 20 Feb 2013 11:57:52 +0000
Message-ID: <1361361460.23294.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 20 Feb 2013 11:57:40 +0000
In-Reply-To: <1361271060.13482.184.camel@i7.infradead.org>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360580068.7383.37.camel@shinybook.infradead.org>
	<1360586609.20449.14.camel@zakaz.uk.xensource.com>
	<1360603691.7383.64.camel@shinybook.infradead.org>
	<1360665298.20449.149.camel@zakaz.uk.xensource.com>
	<1360753525.10581.43.camel@shinybook.infradead.org>
	<1360755013.20449.227.camel@zakaz.uk.xensource.com>
	<1360755110.10581.48.camel@shinybook.infradead.org>
	<1360755437.10581.50.camel@shinybook.infradead.org>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform
 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 Tue, 2013-02-19 at 10:51 +0000, David Woodhouse wrote:
> On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote:
> > I expect there will be some rough edges like the NV variable thing -- I
> > have a feeling these will have a lot in common with qemu/KVM, since they
> > would tend to interact with the "platform" (provided by qemu-dm under
> > Xen) rather than processor or memory virt etc.
> 
> Well, it's mostly just storing text strings describing which device/path
> to boot from. So hopefully if the flash storage itself is OK for Xen,
> the rest should just work.

Ack.

> > For the most part the I reckon the Xen specific things will be resync
> > with a recent upstream and fixup the Xen build system integration, stuff
> > like that. 
> 
> Current upstream OVMF works, AFAICT. Although as I said, I haven't even
> tried booting an OS.
> 
> One thing I obviously *also* haven't tested, therefore, is *rebooting*.,
> We've discovered a KVM bug on older CPUs without 'unrestricted guest'
> mode, where after a reset it actually runs code from 0xffff0 and not
> 0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the
> OVMF startup code that we *should* be running, that's kind of a problem.
> 
> If you have a similar bug, please go and fix it so I never have to
> know :)

I've not heard of such a thing, but I've been half following the thread
and it sounds a bit, shall we say, subtle ;-)

Under Xen when qemu gets a reset event (via I/O writes or whatever) it
ends up with the toolstack actually destroying and recreating the
domain, so I think the issue you are thinking of doesn't come up.

> > We'd like to see PV I/O drivers at some point but that's a separate
> > project in its own right I think.
> 
> If you have an option ROM for them, that might not be a high priority. I
> think OVMF can thunk into INT 13h for disk access.

We don't have an option ROM, but that might be an interesting way to
approach things, although there are issues with teardown before the OS
comes along which endbootservices solves nicely for us.

> > > And on the subject of the NV storage... does -pflash work on qemu-xen,
> > > as long as we're not actually running *code* from the device and we're
> > > only using it for data storage?
> > 
> > I'm not sure, I've CC'd Anthony & Stefano. Assuming the Xen machine type
> > in Qemu wires it up then I don't know why it shouldn't work and if we
> > don't wire it up I don't see why we couldn't.
> 
> Qemu does but not in KVM mode, because it can't *execute* from a region
> and also catch writes to properly emulate flash. But for a flash device
> that we *don't* execute from, because it's only used for NV storage and
> not the firmware itself, that restriction isn't important. So I'll need
> to fix that.

Maybe it would be useful to emulate a dumb NV RAM region, as opposed to
a full flash emulation?

> > Hvmloader might need to be tweaked to setup the e820 correctly and
> > perhaps the some table or other would need to refer to it also?
> 
> Right. Haven't quite worked out how it would be 'found' by the firmware
> yet. I was going to suggest making the address available via fw_cfg...
> but you don't implement that.

There's a little protocol between HVMloader and SeaBIOS which
passes the tables across, see src/xen.c struct xen_seabios_info. Perhaps
HVMloader+OVMF should be (or is?) using the same (or similar). Either
way it should be extensible to cover this new info. The other option is
an HVM_PARAM, which is Xen specific, but pretty simple.

Ian.
-- 
Ian Campbell
Current Noise: Old Man's Child - The Flames Of Deceit

Did I SELL OUT yet??


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:02:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:02: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 1U88N7-0004RS-Jr; Wed, 20 Feb 2013 12:02: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 1U88N6-0004RL-J0
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 12:02:00 +0000
Received: from [85.158.143.99:44897] by server-3.bemta-4.messagelabs.com id
	FE/1C-02186-73BB4215; Wed, 20 Feb 2013 12:01:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361361631!23095892!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3870 invoked from network); 20 Feb 2013 12:00:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:00:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="7983437"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:00:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:00:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88Ld-0006qa-Ol;
	Wed, 20 Feb 2013 12:00:29 +0000
Date: Wed, 20 Feb 2013 12:00:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Gerd Hoffmann <kraxel@redhat.com>
In-Reply-To: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
Message-ID: <alpine.DEB.2.02.1302201200150.4654@kaball.uk.xensource.com>
References: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-stable@nongnu.org" <qemu-stable@nongnu.org>,
	"mark.cave-ayland@ilande.co.uk" <mark.cave-ayland@ilande.co.uk>,
	"agraf@suse.de" <agraf@suse.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v2] vga: fix byteswapping.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 20 Feb 2013, Gerd Hoffmann wrote:
> In case host and guest endianness differ the vga code first creates
> a shared surface (using qemu_create_displaysurface_from), then goes
> patch the surface format to indicate that the bytes must be swapped.
> 
> The switch to pixman broke that hack as the format patching isn't
> propagated into the pixman image, so ui code using the pixman image
> directly (such as vnc) uses the wrong format.
> 
> Fix that by adding a byteswap parameter to
> qemu_create_displaysurface_from, so we'll use the correct format
> when creating the surface (and the pixman image) and don't have
> to patch the format afterwards.
> 
> [ v2: unbreak xen build ]
> 
> Cc: qemu-stable@nongnu.org
> Cc: mark.cave-ayland@ilande.co.uk
> Cc: agraf@suse.de
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

the patch looks good to me


>  hw/qxl-render.c      |    3 ++-
>  hw/vga.c             |   18 ++++++++----------
>  hw/vmware_vga.c      |    2 +-
>  hw/xenfb.c           |    3 ++-
>  include/ui/console.h |    3 ++-
>  ui/console.c         |    9 +++++++--
>  6 files changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/hw/qxl-render.c b/hw/qxl-render.c
> index 88e63f8..455fb91 100644
> --- a/hw/qxl-render.c
> +++ b/hw/qxl-render.c
> @@ -118,7 +118,8 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice *qxl)
>                   qxl->guest_primary.surface.height,
>                   qxl->guest_primary.bits_pp,
>                   qxl->guest_primary.abs_stride,
> -                 qxl->guest_primary.data);
> +                 qxl->guest_primary.data,
> +                 false);
>          } else {
>              qemu_resize_displaysurface(vga->ds,
>                      qxl->guest_primary.surface.width,
> diff --git a/hw/vga.c b/hw/vga.c
> index e2ba7f2..1caf23d 100644
> --- a/hw/vga.c
> +++ b/hw/vga.c
> @@ -1643,6 +1643,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
>      uint8_t *d;
>      uint32_t v, addr1, addr;
>      vga_draw_line_func *vga_draw_line;
> +#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
> +    static const bool byteswap = false;
> +#else
> +    static const bool byteswap = true;
> +#endif
>  
>      full_update |= update_basic_params(s);
>  
> @@ -1685,18 +1690,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
>          disp_width != s->last_width ||
>          height != s->last_height ||
>          s->last_depth != depth) {
> -#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
> -        if (depth == 16 || depth == 32) {
> -#else
> -        if (depth == 32) {
> -#endif
> +        if (depth == 32 || (depth == 16 && !byteswap)) {
>              qemu_free_displaysurface(s->ds);
>              s->ds->surface = qemu_create_displaysurface_from(disp_width, height, depth,
>                      s->line_offset,
> -                    s->vram_ptr + (s->start_addr * 4));
> -#if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
> -            s->ds->surface->pf = qemu_different_endianness_pixelformat(depth);
> -#endif
> +                    s->vram_ptr + (s->start_addr * 4), byteswap);
>              dpy_gfx_resize(s->ds);
>          } else {
>              qemu_console_resize(s->ds, disp_width, height);
> @@ -1715,7 +1713,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
>          s->ds->surface = qemu_create_displaysurface_from(disp_width,
>                  height, depth,
>                  s->line_offset,
> -                s->vram_ptr + (s->start_addr * 4));
> +                s->vram_ptr + (s->start_addr * 4), byteswap);
>          dpy_gfx_setdata(s->ds);
>      }
>  
> diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
> index cd15ee4..8fc201b 100644
> --- a/hw/vmware_vga.c
> +++ b/hw/vmware_vga.c
> @@ -1074,7 +1074,7 @@ static void vmsvga_screen_dump(void *opaque, const char *filename, bool cswitch,
>                                   ds_get_height(s->vga.ds),
>                                   32,
>                                   ds_get_linesize(s->vga.ds),
> -                                 s->vga.vram_ptr);
> +                                 s->vga.vram_ptr, false);
>          ppm_save(filename, ds, errp);
>          g_free(ds);
>      }
> diff --git a/hw/xenfb.c b/hw/xenfb.c
> index 903efd3..7f1f6b4 100644
> --- a/hw/xenfb.c
> +++ b/hw/xenfb.c
> @@ -756,7 +756,8 @@ static void xenfb_update(void *opaque)
>              qemu_free_displaysurface(xenfb->c.ds);
>              xenfb->c.ds->surface = qemu_create_displaysurface_from
>                  (xenfb->width, xenfb->height, xenfb->depth,
> -                 xenfb->row_stride, xenfb->pixels + xenfb->offset);
> +                 xenfb->row_stride, xenfb->pixels + xenfb->offset,
> +                 false);
>              break;
>          default:
>              /* we must convert stuff */
> diff --git a/include/ui/console.h b/include/ui/console.h
> index fc23baa..18012f1 100644
> --- a/include/ui/console.h
> +++ b/include/ui/console.h
> @@ -184,7 +184,8 @@ struct DisplayState {
>  void register_displaystate(DisplayState *ds);
>  DisplayState *get_displaystate(void);
>  DisplaySurface* qemu_create_displaysurface_from(int width, int height, int bpp,
> -                                                int linesize, uint8_t *data);
> +                                                int linesize, uint8_t *data,
> +                                                bool byteswap);
>  PixelFormat qemu_different_endianness_pixelformat(int bpp);
>  PixelFormat qemu_default_pixelformat(int bpp);
>  
> diff --git a/ui/console.c b/ui/console.c
> index 0a68836..25e06a5 100644
> --- a/ui/console.c
> +++ b/ui/console.c
> @@ -1339,11 +1339,16 @@ DisplaySurface *qemu_resize_displaysurface(DisplayState *ds,
>  }
>  
>  DisplaySurface *qemu_create_displaysurface_from(int width, int height, int bpp,
> -                                                int linesize, uint8_t *data)
> +                                                int linesize, uint8_t *data,
> +                                                bool byteswap)
>  {
>      DisplaySurface *surface = g_new0(DisplaySurface, 1);
>  
> -    surface->pf = qemu_default_pixelformat(bpp);
> +    if (byteswap) {
> +        surface->pf = qemu_different_endianness_pixelformat(bpp);
> +    } else {
> +        surface->pf = qemu_default_pixelformat(bpp);
> +    }
>  
>      surface->format = qemu_pixman_get_format(&surface->pf);
>      assert(surface->format != 0);
> -- 
> 1.7.9.7
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:02:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:02: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 1U88N7-0004RS-Jr; Wed, 20 Feb 2013 12:02: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 1U88N6-0004RL-J0
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 12:02:00 +0000
Received: from [85.158.143.99:44897] by server-3.bemta-4.messagelabs.com id
	FE/1C-02186-73BB4215; Wed, 20 Feb 2013 12:01:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361361631!23095892!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3870 invoked from network); 20 Feb 2013 12:00:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:00:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="7983437"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:00:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:00:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88Ld-0006qa-Ol;
	Wed, 20 Feb 2013 12:00:29 +0000
Date: Wed, 20 Feb 2013 12:00:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Gerd Hoffmann <kraxel@redhat.com>
In-Reply-To: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
Message-ID: <alpine.DEB.2.02.1302201200150.4654@kaball.uk.xensource.com>
References: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-stable@nongnu.org" <qemu-stable@nongnu.org>,
	"mark.cave-ayland@ilande.co.uk" <mark.cave-ayland@ilande.co.uk>,
	"agraf@suse.de" <agraf@suse.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v2] vga: fix byteswapping.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 20 Feb 2013, Gerd Hoffmann wrote:
> In case host and guest endianness differ the vga code first creates
> a shared surface (using qemu_create_displaysurface_from), then goes
> patch the surface format to indicate that the bytes must be swapped.
> 
> The switch to pixman broke that hack as the format patching isn't
> propagated into the pixman image, so ui code using the pixman image
> directly (such as vnc) uses the wrong format.
> 
> Fix that by adding a byteswap parameter to
> qemu_create_displaysurface_from, so we'll use the correct format
> when creating the surface (and the pixman image) and don't have
> to patch the format afterwards.
> 
> [ v2: unbreak xen build ]
> 
> Cc: qemu-stable@nongnu.org
> Cc: mark.cave-ayland@ilande.co.uk
> Cc: agraf@suse.de
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

the patch looks good to me


>  hw/qxl-render.c      |    3 ++-
>  hw/vga.c             |   18 ++++++++----------
>  hw/vmware_vga.c      |    2 +-
>  hw/xenfb.c           |    3 ++-
>  include/ui/console.h |    3 ++-
>  ui/console.c         |    9 +++++++--
>  6 files changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/hw/qxl-render.c b/hw/qxl-render.c
> index 88e63f8..455fb91 100644
> --- a/hw/qxl-render.c
> +++ b/hw/qxl-render.c
> @@ -118,7 +118,8 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice *qxl)
>                   qxl->guest_primary.surface.height,
>                   qxl->guest_primary.bits_pp,
>                   qxl->guest_primary.abs_stride,
> -                 qxl->guest_primary.data);
> +                 qxl->guest_primary.data,
> +                 false);
>          } else {
>              qemu_resize_displaysurface(vga->ds,
>                      qxl->guest_primary.surface.width,
> diff --git a/hw/vga.c b/hw/vga.c
> index e2ba7f2..1caf23d 100644
> --- a/hw/vga.c
> +++ b/hw/vga.c
> @@ -1643,6 +1643,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
>      uint8_t *d;
>      uint32_t v, addr1, addr;
>      vga_draw_line_func *vga_draw_line;
> +#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
> +    static const bool byteswap = false;
> +#else
> +    static const bool byteswap = true;
> +#endif
>  
>      full_update |= update_basic_params(s);
>  
> @@ -1685,18 +1690,11 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
>          disp_width != s->last_width ||
>          height != s->last_height ||
>          s->last_depth != depth) {
> -#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
> -        if (depth == 16 || depth == 32) {
> -#else
> -        if (depth == 32) {
> -#endif
> +        if (depth == 32 || (depth == 16 && !byteswap)) {
>              qemu_free_displaysurface(s->ds);
>              s->ds->surface = qemu_create_displaysurface_from(disp_width, height, depth,
>                      s->line_offset,
> -                    s->vram_ptr + (s->start_addr * 4));
> -#if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
> -            s->ds->surface->pf = qemu_different_endianness_pixelformat(depth);
> -#endif
> +                    s->vram_ptr + (s->start_addr * 4), byteswap);
>              dpy_gfx_resize(s->ds);
>          } else {
>              qemu_console_resize(s->ds, disp_width, height);
> @@ -1715,7 +1713,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update)
>          s->ds->surface = qemu_create_displaysurface_from(disp_width,
>                  height, depth,
>                  s->line_offset,
> -                s->vram_ptr + (s->start_addr * 4));
> +                s->vram_ptr + (s->start_addr * 4), byteswap);
>          dpy_gfx_setdata(s->ds);
>      }
>  
> diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
> index cd15ee4..8fc201b 100644
> --- a/hw/vmware_vga.c
> +++ b/hw/vmware_vga.c
> @@ -1074,7 +1074,7 @@ static void vmsvga_screen_dump(void *opaque, const char *filename, bool cswitch,
>                                   ds_get_height(s->vga.ds),
>                                   32,
>                                   ds_get_linesize(s->vga.ds),
> -                                 s->vga.vram_ptr);
> +                                 s->vga.vram_ptr, false);
>          ppm_save(filename, ds, errp);
>          g_free(ds);
>      }
> diff --git a/hw/xenfb.c b/hw/xenfb.c
> index 903efd3..7f1f6b4 100644
> --- a/hw/xenfb.c
> +++ b/hw/xenfb.c
> @@ -756,7 +756,8 @@ static void xenfb_update(void *opaque)
>              qemu_free_displaysurface(xenfb->c.ds);
>              xenfb->c.ds->surface = qemu_create_displaysurface_from
>                  (xenfb->width, xenfb->height, xenfb->depth,
> -                 xenfb->row_stride, xenfb->pixels + xenfb->offset);
> +                 xenfb->row_stride, xenfb->pixels + xenfb->offset,
> +                 false);
>              break;
>          default:
>              /* we must convert stuff */
> diff --git a/include/ui/console.h b/include/ui/console.h
> index fc23baa..18012f1 100644
> --- a/include/ui/console.h
> +++ b/include/ui/console.h
> @@ -184,7 +184,8 @@ struct DisplayState {
>  void register_displaystate(DisplayState *ds);
>  DisplayState *get_displaystate(void);
>  DisplaySurface* qemu_create_displaysurface_from(int width, int height, int bpp,
> -                                                int linesize, uint8_t *data);
> +                                                int linesize, uint8_t *data,
> +                                                bool byteswap);
>  PixelFormat qemu_different_endianness_pixelformat(int bpp);
>  PixelFormat qemu_default_pixelformat(int bpp);
>  
> diff --git a/ui/console.c b/ui/console.c
> index 0a68836..25e06a5 100644
> --- a/ui/console.c
> +++ b/ui/console.c
> @@ -1339,11 +1339,16 @@ DisplaySurface *qemu_resize_displaysurface(DisplayState *ds,
>  }
>  
>  DisplaySurface *qemu_create_displaysurface_from(int width, int height, int bpp,
> -                                                int linesize, uint8_t *data)
> +                                                int linesize, uint8_t *data,
> +                                                bool byteswap)
>  {
>      DisplaySurface *surface = g_new0(DisplaySurface, 1);
>  
> -    surface->pf = qemu_default_pixelformat(bpp);
> +    if (byteswap) {
> +        surface->pf = qemu_different_endianness_pixelformat(bpp);
> +    } else {
> +        surface->pf = qemu_default_pixelformat(bpp);
> +    }
>  
>      surface->format = qemu_pixman_get_format(&surface->pf);
>      assert(surface->format != 0);
> -- 
> 1.7.9.7
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:05:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12: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 1U88Q0-0004ne-0z; Wed, 20 Feb 2013 12:05:00 +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 1U88Px-0004nP-N1
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 12:04:57 +0000
Received: from [85.158.138.51:13798] by server-15.bemta-3.messagelabs.com id
	46/B1-25405-4EBB4215; Wed, 20 Feb 2013 12:04:52 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361361888!19462195!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23091 invoked from network); 20 Feb 2013 12:04:51 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 12:04:51 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U88Pm-0001yx-Bp; Wed, 20 Feb 2013 23:04:46 +1100
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 id
	14.01.0438.000; Wed, 20 Feb 2013 23:04:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTAgAAecoCAALiu8P//TGeAgAlkZACAALm24P//TYAAgADD2MA=
Date: Wed, 20 Feb 2013 12:04:45 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35687A0D@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
	<5124B22E.8060001@tiscali.it>
In-Reply-To: <5124B22E.8060001@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [203.193.205.129]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19648.007
x-tm-as-result: No--43.044500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV 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

Looks like you still don't have the certificate file sorted out. Did I send you an email about that?

James

> -----Original Message-----
> From: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
> Sent: Wednesday, 20 February 2013 10:23 PM
> To: James Harper
> Cc: xen-devel
> Subject: Re: GPLPV questions
> 
> Il 20/02/2013 12:03, James Harper ha scritto:
> >>> I added as attachment the build log for this, can be sufficent? If you
> >>> need other test/data tell me and I'll post them.
> >>>
> >> Retried now with rev 1029 and gave the same errors.
> >>
> > I also need the output of the build that gets printed to the console. Go into
> command prompt and set the buffer length to 9999 or whatever the limit is
> then do the makedist then copy the lot into an email. Do a cls first to clear the
> buffer.
> >
> > James
> >
> Done and added as attachment

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:05:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12: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 1U88Q0-0004ne-0z; Wed, 20 Feb 2013 12:05:00 +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 1U88Px-0004nP-N1
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 12:04:57 +0000
Received: from [85.158.138.51:13798] by server-15.bemta-3.messagelabs.com id
	46/B1-25405-4EBB4215; Wed, 20 Feb 2013 12:04:52 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361361888!19462195!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23091 invoked from network); 20 Feb 2013 12:04:51 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 12:04:51 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1U88Pm-0001yx-Bp; Wed, 20 Feb 2013 23:04:46 +1100
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 id
	14.01.0438.000; Wed, 20 Feb 2013 23:04:46 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Thread-Topic: GPLPV questions
Thread-Index: AQHOCfU/WCe8ChQNwESDOg8oJ7NYkZh4XfTAgAAecoCAALiu8P//TGeAgAlkZACAALm24P//TYAAgADD2MA=
Date: Wed, 20 Feb 2013 12:04:45 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B35687A0D@BITCOM1.int.sbss.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
	<5124B22E.8060001@tiscali.it>
In-Reply-To: <5124B22E.8060001@tiscali.it>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [203.193.205.129]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19648.007
x-tm-as-result: No--43.044500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV 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

Looks like you still don't have the certificate file sorted out. Did I send you an email about that?

James

> -----Original Message-----
> From: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
> Sent: Wednesday, 20 February 2013 10:23 PM
> To: James Harper
> Cc: xen-devel
> Subject: Re: GPLPV questions
> 
> Il 20/02/2013 12:03, James Harper ha scritto:
> >>> I added as attachment the build log for this, can be sufficent? If you
> >>> need other test/data tell me and I'll post them.
> >>>
> >> Retried now with rev 1029 and gave the same errors.
> >>
> > I also need the output of the build that gets printed to the console. Go into
> command prompt and set the buffer length to 9999 or whatever the limit is
> then do the makedist then copy the lot into an email. Do a cls first to clear the
> buffer.
> >
> > James
> >
> Done and added as attachment

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:06:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12: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 1U88RO-0004x0-KY; Wed, 20 Feb 2013 12:06:26 +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 1U88RM-0004wo-Vd
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:06:25 +0000
Received: from [85.158.137.99:5400] by server-12.bemta-3.messagelabs.com id
	BE/BA-05889-04CB4215; Wed, 20 Feb 2013 12:06:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361361981!11834329!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18206 invoked from network); 20 Feb 2013 12:06:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:06:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="7984438"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:06:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:06:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88RI-0006v2-W4;
	Wed, 20 Feb 2013 12:06:20 +0000
Date: Wed, 20 Feb 2013 12:06:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <9B86FF34BF4E25473587D0B5@nimrod.local>
Message-ID: <alpine.DEB.2.02.1302201203200.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-4-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
	<9B86FF34BF4E25473587D0B5@nimrod.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 3/5] exec: Introduce helper to set dirty
 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 Tue, 19 Feb 2013, Alex Bligh wrote:
> Stefano,
> 
> --On 19 February 2013 17:42:50 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > In QEMU the code style is spaces for indentation.
> 
> OK no idea how that happened - sorry. I'm using qemu's published emacs
> c mode (or thought I was).
> 
> > Moreover the right way of doing the backport here would be firstly to
> > backport 0b57e287, then 51d7a9eb2b64e787c90bea1027308087eac22065 should
> > just apply.
> 
> I just backported the 5 patches you pointed me at, and any code changes
> they required.
> 
> So the change I posted brings in invalidate_and_set_dirty, pretty much
> per the original patch. Is the issue here I combined it with the other
> patch you mentioned? Guidance welcome.

In general is preferable to backport a patch as-is.

If the patch in question depends on another patch, which is small and
can also be easily backported, like in this case, the best course of
action is to backport them both as separate patches.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:06:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12: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 1U88RO-0004x0-KY; Wed, 20 Feb 2013 12:06:26 +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 1U88RM-0004wo-Vd
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:06:25 +0000
Received: from [85.158.137.99:5400] by server-12.bemta-3.messagelabs.com id
	BE/BA-05889-04CB4215; Wed, 20 Feb 2013 12:06:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361361981!11834329!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18206 invoked from network); 20 Feb 2013 12:06:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:06:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="7984438"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:06:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:06:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88RI-0006v2-W4;
	Wed, 20 Feb 2013 12:06:20 +0000
Date: Wed, 20 Feb 2013 12:06:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <9B86FF34BF4E25473587D0B5@nimrod.local>
Message-ID: <alpine.DEB.2.02.1302201203200.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-4-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191741310.4654@kaball.uk.xensource.com>
	<9B86FF34BF4E25473587D0B5@nimrod.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 3/5] exec: Introduce helper to set dirty
 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 Tue, 19 Feb 2013, Alex Bligh wrote:
> Stefano,
> 
> --On 19 February 2013 17:42:50 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > In QEMU the code style is spaces for indentation.
> 
> OK no idea how that happened - sorry. I'm using qemu's published emacs
> c mode (or thought I was).
> 
> > Moreover the right way of doing the backport here would be firstly to
> > backport 0b57e287, then 51d7a9eb2b64e787c90bea1027308087eac22065 should
> > just apply.
> 
> I just backported the 5 patches you pointed me at, and any code changes
> they required.
> 
> So the change I posted brings in invalidate_and_set_dirty, pretty much
> per the original patch. Is the issue here I combined it with the other
> patch you mentioned? Guidance welcome.

In general is preferable to backport a patch as-is.

If the patch in question depends on another patch, which is small and
can also be easily backported, like in this case, the best course of
action is to backport them both as separate patches.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:21:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:21: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 1U88fQ-0005h2-VM; Wed, 20 Feb 2013 12:20: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 1U88fP-0005gv-3T
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 12:20:55 +0000
Received: from [85.158.139.83:14252] by server-12.bemta-5.messagelabs.com id
	3D/67-20195-6AFB4215; Wed, 20 Feb 2013 12:20:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361362853!28102132!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26845 invoked from network); 20 Feb 2013 12:20:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:20:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="1650494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 12:20: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.297.1; Wed, 20 Feb 2013 12:20:53 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U88fN-0001ue-4D;
	Wed, 20 Feb 2013 12:20:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U88fN-0003oy-1C;
	Wed, 20 Feb 2013 12:20:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16215-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Feb 2013 12:20:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16215: 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 16215 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16215/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16214
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16214
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16214

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  66f563be41d9
baseline version:
 xen                  66f563be41d9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 20 12:21:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:21: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 1U88fQ-0005h2-VM; Wed, 20 Feb 2013 12:20: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 1U88fP-0005gv-3T
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 12:20:55 +0000
Received: from [85.158.139.83:14252] by server-12.bemta-5.messagelabs.com id
	3D/67-20195-6AFB4215; Wed, 20 Feb 2013 12:20:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361362853!28102132!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26845 invoked from network); 20 Feb 2013 12:20:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:20:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="1650494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 12:20: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.297.1; Wed, 20 Feb 2013 12:20:53 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U88fN-0001ue-4D;
	Wed, 20 Feb 2013 12:20:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U88fN-0003oy-1C;
	Wed, 20 Feb 2013 12:20:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16215-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 20 Feb 2013 12:20:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16215: 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 16215 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16215/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16214
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16214
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16214

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  66f563be41d9
baseline version:
 xen                  66f563be41d9

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 20 12:21:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:21: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 1U88g2-0005jh-D8; Wed, 20 Feb 2013 12:21:34 +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 1U88g0-0005jQ-7i
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:21:32 +0000
Received: from [85.158.143.99:12027] by server-2.bemta-4.messagelabs.com id
	16/B3-12656-BCFB4215; Wed, 20 Feb 2013 12:21:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361362888!24996362!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22170 invoked from network); 20 Feb 2013 12:21:30 -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;
	20 Feb 2013 12:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="8404121"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:21:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:21:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88fv-00077s-Ks;
	Wed, 20 Feb 2013 12:21:27 +0000
Date: Wed, 20 Feb 2013 12:21:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <89387166AE5D93F6D14D4CB3@nimrod.local>
Message-ID: <alpine.DEB.2.02.1302201211410.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-6-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
	<89387166AE5D93F6D14D4CB3@nimrod.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Alex Bligh wrote:
> Stefano,
> 
> --On 19 February 2013 18:05:46 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Tue, 19 Feb 2013, Alex Bligh wrote:
> >> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on
> >> all the video ram. This case happens during migration.
> 
> This was the patch I had most difficulty with, frankly because I had
> little idea what it was doing. Education welcome!
> 
> >>
> >> Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
> >>
> >> Signed-off-by: Alex Bligh <alex@alex.org.uk>
> >> ---
> >>  xen-all.c |   20 ++++++++++++++++++--
> >>  1 files changed, 18 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/xen-all.c b/xen-all.c
> >> index 121289d..dbd759c 100644
> >> --- a/xen-all.c
> >> +++ b/xen-all.c
> >> @@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
> >>      rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
> >>                                   start_addr >> TARGET_PAGE_BITS, npages,
> >>                                   bitmap);
> >> -    if (rc) {
> >> +    if (rc < 0) {
> >> +        if (rc != -ENODATA) {
> >> +            ram_addr_t addr, end;
> >> +
> >> +            xen_modified_memory(start_addr, size);
> >> +
> >> +            end = TARGET_PAGE_ALIGN(start_addr + size);
> >> +            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr
> >> += TARGET_PAGE_SIZE) { +
> >> cpu_physical_memory_set_dirty(addr);
> >> +            }
> >> +
> >> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> >> +                    ", 0x" TARGET_FMT_plx "): %s\n",
> >> +                    start_addr, start_addr + size, strerror(-rc));
> >> +        }
> >>          return rc;
> >>      }
> >
> > 8aba7dc02d5660df7e7d8651304b3079908358be only adds a simple call to
> > xen_modified_memory if rc != ENODATA.
> > Where does the rest of the code you are adding comes from?
> 
> Applying the patch unchanged is not easy as there are a pile of
> conflicting items. I was taking a conservative approach partly
> as I didn't fully understand what types of addresses could be
> safely used where. My approach was to make this function as similar
> as possible to xen 4.3 immediately after the patch, which is here:
> 
> http://git.qemu.org/?p=qemu.git;a=blob;f=xen-all.c;h=e6308be23adb7198c144883eb886fb6edb5fe09f;hb=8aba7dc02d5660df7e7d8651304b3079908358be
> 
> There were some oddnesses there, such as:
> 
>  508     if (rc < 0) {
>  509         if (rc != -ENODATA) {
>  510             memory_region_set_dirty(framebuffer, 0, size);
>  511             DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
>  512                     ", 0x" TARGET_FMT_plx "): %s\n",
>  513                     start_addr, start_addr + size, strerror(-rc));
>  514         }
>  515         return;
>  516     }
> 
> What is the point of the outer check on rc?

Yeah, the code could be more readable. The point would be only to act on
errors.


> I think you are asking why I didn't just call memory_region_set_dirty.
> memory_region_set_dirty in 4.2 (as opposed to 4.3) takes:
>  void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr);
> and the 3 parameter version is unavailable, so what I did was (I hope)
> the equivalent of what the 3 parameter version would have done, going
> through each page.
> 
> I could have modified memory_region_set_dirty to cope with multiple pages
> but that seemed like a more intrusive change.

I think that the best thing to do in this case is just to add a call to
xen_modified_memory if (rc != -ENODATA).


> >> @@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
> >>          while (map != 0) {
> >>              j = ffsl(map) - 1;
> >>              map &= ~(1ul << j);
> >> -            cpu_physical_memory_set_dirty(vram_offset + (i * width + j)
> >> * TARGET_PAGE_SIZE); +            target_phys_addr_t todirty =
> >> vram_offset + (i * width + j) * TARGET_PAGE_SIZE; +
> >> xen_modified_memory(todirty, TARGET_PAGE_SIZE);
> >> +            cpu_physical_memory_set_dirty(todirty);
> >>          };
> >>      }
> >
> > where does this chuck come from?
> > Wouldn't it make more sense to add a call to xen_modified_memory from
> > cpu_physical_memory_set_dirty?
> 
> Again, I was trying to emulate what the 3 parameter
> memory_region_set_dirty() does. I believe cpu_physical_memory_set_dirty has
> other callers, and was unsure whether adding a call to xen_modified_memory
> would be safe in there.
 
Considering that this change wasn't part of the original patch, it needs
to go into a different patch. Probably patch 4/5 would be a better fit,
given that this change is needed because
cpu_physical_memory_set_dirty_range doesn't exist.

Finally I think that adding a call to xen_modified_memory from
cpu_physical_memory_set_dirty would simplify things. The size would be
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 Feb 20 12:21:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:21: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 1U88g2-0005jh-D8; Wed, 20 Feb 2013 12:21:34 +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 1U88g0-0005jQ-7i
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:21:32 +0000
Received: from [85.158.143.99:12027] by server-2.bemta-4.messagelabs.com id
	16/B3-12656-BCFB4215; Wed, 20 Feb 2013 12:21:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361362888!24996362!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22170 invoked from network); 20 Feb 2013 12:21:30 -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;
	20 Feb 2013 12:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="8404121"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:21:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:21:27 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88fv-00077s-Ks;
	Wed, 20 Feb 2013 12:21:27 +0000
Date: Wed, 20 Feb 2013 12:21:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <89387166AE5D93F6D14D4CB3@nimrod.local>
Message-ID: <alpine.DEB.2.02.1302201211410.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-6-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191757350.4654@kaball.uk.xensource.com>
	<89387166AE5D93F6D14D4CB3@nimrod.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 19 Feb 2013, Alex Bligh wrote:
> Stefano,
> 
> --On 19 February 2013 18:05:46 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Tue, 19 Feb 2013, Alex Bligh wrote:
> >> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on
> >> all the video ram. This case happens during migration.
> 
> This was the patch I had most difficulty with, frankly because I had
> little idea what it was doing. Education welcome!
> 
> >>
> >> Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
> >>
> >> Signed-off-by: Alex Bligh <alex@alex.org.uk>
> >> ---
> >>  xen-all.c |   20 ++++++++++++++++++--
> >>  1 files changed, 18 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/xen-all.c b/xen-all.c
> >> index 121289d..dbd759c 100644
> >> --- a/xen-all.c
> >> +++ b/xen-all.c
> >> @@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
> >>      rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
> >>                                   start_addr >> TARGET_PAGE_BITS, npages,
> >>                                   bitmap);
> >> -    if (rc) {
> >> +    if (rc < 0) {
> >> +        if (rc != -ENODATA) {
> >> +            ram_addr_t addr, end;
> >> +
> >> +            xen_modified_memory(start_addr, size);
> >> +
> >> +            end = TARGET_PAGE_ALIGN(start_addr + size);
> >> +            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr
> >> += TARGET_PAGE_SIZE) { +
> >> cpu_physical_memory_set_dirty(addr);
> >> +            }
> >> +
> >> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> >> +                    ", 0x" TARGET_FMT_plx "): %s\n",
> >> +                    start_addr, start_addr + size, strerror(-rc));
> >> +        }
> >>          return rc;
> >>      }
> >
> > 8aba7dc02d5660df7e7d8651304b3079908358be only adds a simple call to
> > xen_modified_memory if rc != ENODATA.
> > Where does the rest of the code you are adding comes from?
> 
> Applying the patch unchanged is not easy as there are a pile of
> conflicting items. I was taking a conservative approach partly
> as I didn't fully understand what types of addresses could be
> safely used where. My approach was to make this function as similar
> as possible to xen 4.3 immediately after the patch, which is here:
> 
> http://git.qemu.org/?p=qemu.git;a=blob;f=xen-all.c;h=e6308be23adb7198c144883eb886fb6edb5fe09f;hb=8aba7dc02d5660df7e7d8651304b3079908358be
> 
> There were some oddnesses there, such as:
> 
>  508     if (rc < 0) {
>  509         if (rc != -ENODATA) {
>  510             memory_region_set_dirty(framebuffer, 0, size);
>  511             DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
>  512                     ", 0x" TARGET_FMT_plx "): %s\n",
>  513                     start_addr, start_addr + size, strerror(-rc));
>  514         }
>  515         return;
>  516     }
> 
> What is the point of the outer check on rc?

Yeah, the code could be more readable. The point would be only to act on
errors.


> I think you are asking why I didn't just call memory_region_set_dirty.
> memory_region_set_dirty in 4.2 (as opposed to 4.3) takes:
>  void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr);
> and the 3 parameter version is unavailable, so what I did was (I hope)
> the equivalent of what the 3 parameter version would have done, going
> through each page.
> 
> I could have modified memory_region_set_dirty to cope with multiple pages
> but that seemed like a more intrusive change.

I think that the best thing to do in this case is just to add a call to
xen_modified_memory if (rc != -ENODATA).


> >> @@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
> >>          while (map != 0) {
> >>              j = ffsl(map) - 1;
> >>              map &= ~(1ul << j);
> >> -            cpu_physical_memory_set_dirty(vram_offset + (i * width + j)
> >> * TARGET_PAGE_SIZE); +            target_phys_addr_t todirty =
> >> vram_offset + (i * width + j) * TARGET_PAGE_SIZE; +
> >> xen_modified_memory(todirty, TARGET_PAGE_SIZE);
> >> +            cpu_physical_memory_set_dirty(todirty);
> >>          };
> >>      }
> >
> > where does this chuck come from?
> > Wouldn't it make more sense to add a call to xen_modified_memory from
> > cpu_physical_memory_set_dirty?
> 
> Again, I was trying to emulate what the 3 parameter
> memory_region_set_dirty() does. I believe cpu_physical_memory_set_dirty has
> other callers, and was unsure whether adding a call to xen_modified_memory
> would be safe in there.
 
Considering that this change wasn't part of the original patch, it needs
to go into a different patch. Probably patch 4/5 would be a better fit,
given that this change is needed because
cpu_physical_memory_set_dirty_range doesn't exist.

Finally I think that adding a call to xen_modified_memory from
cpu_physical_memory_set_dirty would simplify things. The size would be
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 Feb 20 12:31:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:31: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 1U88pO-0006Bf-O0; Wed, 20 Feb 2013 12:31:14 +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 1U88pN-0006BW-QE
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:31:14 +0000
Received: from [85.158.139.83:60420] by server-2.bemta-5.messagelabs.com id
	2A/87-16911-012C4215; Wed, 20 Feb 2013 12:31:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361363449!16826543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29448 invoked from network); 20 Feb 2013 12:30:51 -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;
	20 Feb 2013 12:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="7989880"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:30:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:30:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88oy-0007HV-BI;
	Wed, 20 Feb 2013 12:30:48 +0000
Date: Wed, 20 Feb 2013 12:30:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <8C4820ECA744AD74C30515BF@nimrod.local>
Message-ID: <alpine.DEB.2.02.1302201223500.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
	<8C4820ECA744AD74C30515BF@nimrod.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_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

On Tue, 19 Feb 2013, Alex Bligh wrote:
> --On 19 February 2013 18:03:04 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > e226939de5814527a21396903b08c3d0ed989558 adds two calls to
> > xen_modified_memory, one in cpu_physical_memory_set_dirty_range, the
> > other in invalidate_and_set_dirty.
> >
> > Where does this one come from?
> >
> > If something is missing you need to backport that patch too, rather than
> > trying to adapt this patch.
> > In this case I believe you need to backport
> > 1720aeee72888f80b974c33b6eb39922a0bea992.
> 
> Again, I was trying to make the fewest changes possible, being aware I
> have little understanding of the code. Some assistance would be appreciated
> here particularly as the substitute patch you mention would appear to have
> have wider implications.

OK. Keep the patch as you wrote it and add a comment in the description
saying why you needed to make the additional changes that are not part
of e226939de5814527a21396903b08c3d0ed989558.

Also add a call to xen_modified_memory from
cpu_physical_memory_set_dirty, if I am not mistaken that should solve
the problem with the dirty vram.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:31:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:31: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 1U88pO-0006Bf-O0; Wed, 20 Feb 2013 12:31:14 +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 1U88pN-0006BW-QE
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:31:14 +0000
Received: from [85.158.139.83:60420] by server-2.bemta-5.messagelabs.com id
	2A/87-16911-012C4215; Wed, 20 Feb 2013 12:31:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361363449!16826543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29448 invoked from network); 20 Feb 2013 12:30:51 -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;
	20 Feb 2013 12:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="7989880"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:30:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:30:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U88oy-0007HV-BI;
	Wed, 20 Feb 2013 12:30:48 +0000
Date: Wed, 20 Feb 2013 12:30:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <8C4820ECA744AD74C30515BF@nimrod.local>
Message-ID: <alpine.DEB.2.02.1302201223500.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
	<8C4820ECA744AD74C30515BF@nimrod.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_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

On Tue, 19 Feb 2013, Alex Bligh wrote:
> --On 19 February 2013 18:03:04 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > e226939de5814527a21396903b08c3d0ed989558 adds two calls to
> > xen_modified_memory, one in cpu_physical_memory_set_dirty_range, the
> > other in invalidate_and_set_dirty.
> >
> > Where does this one come from?
> >
> > If something is missing you need to backport that patch too, rather than
> > trying to adapt this patch.
> > In this case I believe you need to backport
> > 1720aeee72888f80b974c33b6eb39922a0bea992.
> 
> Again, I was trying to make the fewest changes possible, being aware I
> have little understanding of the code. Some assistance would be appreciated
> here particularly as the substitute patch you mention would appear to have
> have wider implications.

OK. Keep the patch as you wrote it and add a comment in the description
saying why you needed to make the additional changes that are not part
of e226939de5814527a21396903b08c3d0ed989558.

Also add a call to xen_modified_memory from
cpu_physical_memory_set_dirty, if I am not mistaken that should solve
the problem with the dirty vram.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:48: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 1U895l-0006a3-O6; Wed, 20 Feb 2013 12:48:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U895k-0006Zv-2r
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:48:08 +0000
Received: from [85.158.137.99:32250] by server-14.bemta-3.messagelabs.com id
	2E/7D-23533-706C4215; Wed, 20 Feb 2013 12:48:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361364485!16326538!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9128 invoked from network); 20 Feb 2013 12:48:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="8407361"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:48:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:48:04 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U895f-0007XM-T8;
	Wed, 20 Feb 2013 12:48:03 +0000
Message-ID: <5124C603.6000902@citrix.com>
Date: Wed, 20 Feb 2013 12:48:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Steven Haigh <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
	<5124AE19.2000802@citrix.com> <5124AECA.4060503@crc.id.au>
In-Reply-To: <5124AECA.4060503@crc.id.au>
X-Enigmail-Version: 1.4
Cc: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20/02/13 11:08, Steven Haigh wrote:
> On 20/02/2013 10:06 PM, Andrew Cooper wrote:
>> On 20/02/13 10:12, Jan Beulich wrote:
>>>>>> On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
>>>> My build of Xen 4.2.1 also has all of the recent security advisories
>>>> patched as well. Although it is interesting to note that
>>>> downgrading to
>>>> Xen 4.1.2 made no difference to write speeds.
>>> Not surprising at all, considering that the hypervisor is only a
>>> passive
>>> library for all PV I/O purposes. You're likely hunting for a kernel
>>> side
>>> regression (and hence the mentioning of the hypervisor version as
>>> the main factor in the subject is probably misleading).
>>>
>>> Jan
>>
>> Further to this, do try to verify if your disk driver has changed
>> recently to use >0 order page allocations for DMA.  If it has, then
>> speed will be much slower as there will now be the swiotlb cpu-copy
>> overhead.
>
> Any hints on how to do this? ;)
>
> The kernel modules in use for my SATA drives are ahci and sata_mv.
> There are 6 drives in total on the system.
>
> sda + sdb = RAID1
> sd[c-f] = RAID6
>
> sda, sdb, sdc and sdd are on the onboard SATA controller (ahci)
> sde, sdf are on the sata_mv 4x PCIe controller.
>

Sadly that is a hard question to answer, and is driver specific.  I cant
suggest an easy way other than digging into the source.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 12:48:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 12:48: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 1U895l-0006a3-O6; Wed, 20 Feb 2013 12:48:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U895k-0006Zv-2r
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 12:48:08 +0000
Received: from [85.158.137.99:32250] by server-14.bemta-3.messagelabs.com id
	2E/7D-23533-706C4215; Wed, 20 Feb 2013 12:48:07 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361364485!16326538!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9128 invoked from network); 20 Feb 2013 12:48:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 12:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,701,1355097600"; 
   d="scan'208";a="8407361"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 12:48:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 07:48:04 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U895f-0007XM-T8;
	Wed, 20 Feb 2013 12:48:03 +0000
Message-ID: <5124C603.6000902@citrix.com>
Date: Wed, 20 Feb 2013 12:48:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Steven Haigh <netwiz@crc.id.au>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
	<5124AE19.2000802@citrix.com> <5124AECA.4060503@crc.id.au>
In-Reply-To: <5124AECA.4060503@crc.id.au>
X-Enigmail-Version: 1.4
Cc: Roger Pau Monne <roger.pau@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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 20/02/13 11:08, Steven Haigh wrote:
> On 20/02/2013 10:06 PM, Andrew Cooper wrote:
>> On 20/02/13 10:12, Jan Beulich wrote:
>>>>>> On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
>>>> My build of Xen 4.2.1 also has all of the recent security advisories
>>>> patched as well. Although it is interesting to note that
>>>> downgrading to
>>>> Xen 4.1.2 made no difference to write speeds.
>>> Not surprising at all, considering that the hypervisor is only a
>>> passive
>>> library for all PV I/O purposes. You're likely hunting for a kernel
>>> side
>>> regression (and hence the mentioning of the hypervisor version as
>>> the main factor in the subject is probably misleading).
>>>
>>> Jan
>>
>> Further to this, do try to verify if your disk driver has changed
>> recently to use >0 order page allocations for DMA.  If it has, then
>> speed will be much slower as there will now be the swiotlb cpu-copy
>> overhead.
>
> Any hints on how to do this? ;)
>
> The kernel modules in use for my SATA drives are ahci and sata_mv.
> There are 6 drives in total on the system.
>
> sda + sdb = RAID1
> sd[c-f] = RAID6
>
> sda, sdb, sdc and sdd are on the onboard SATA controller (ahci)
> sde, sdf are on the sata_mv 4x PCIe controller.
>

Sadly that is a hard question to answer, and is driver specific.  I cant
suggest an easy way other than digging into the source.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 13:15:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 13:15: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 1U89Vg-0006zg-4Z; Wed, 20 Feb 2013 13:14:56 +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 1U89Ve-0006zb-34
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 13:14:54 +0000
Received: from [85.158.138.51:18671] by server-10.bemta-3.messagelabs.com id
	22/64-10609-D4CC4215; Wed, 20 Feb 2013 13:14:53 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361366091!20341863!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13653 invoked from network); 20 Feb 2013 13:14:51 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 13:14:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 02FE340031A;
	Wed, 20 Feb 2013 14:14:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id kZyXPVSsae2H; Wed, 20 Feb 2013 14:14:50 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 8220F4001FB;
	Wed, 20 Feb 2013 14:14:48 +0100 (CET)
Message-ID: <5124CC44.3090903@tiscali.it>
Date: Wed, 20 Feb 2013 14:14:44 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
	<5124B22E.8060001@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35687A0D@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35687A0D@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============5851219563104011861=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============5851219563104011861==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020308090803060301040708"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020308090803060301040708
Content-Type: multipart/mixed;
 boundary="------------000106010903030404080303"

This is a multi-part message in MIME format.
--------------000106010903030404080303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 20/02/2013 13:04, James Harper ha scritto:
> Looks like you still don't have the certificate file sorted out. Did I =
send you an email about that?
>
> James

I didn't found detailed instructions about certificate, so I tried with=20
a selfsigned one.
Some things are different but there are always errors, see new attachment=
=2E

>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
>> Sent: Wednesday, 20 February 2013 10:23 PM
>> To: James Harper
>> Cc: xen-devel
>> Subject: Re: GPLPV questions
>>
>> Il 20/02/2013 12:03, James Harper ha scritto:
>>>>> I added as attachment the build log for this, can be sufficent? If =
you
>>>>> need other test/data tell me and I'll post them.
>>>>>
>>>> Retried now with rev 1029 and gave the same errors.
>>>>
>>> I also need the output of the build that gets printed to the console.=
 Go into
>> command prompt and set the buffer length to 9999 or whatever the limit=
 is
>> then do the makedist then copy the lot into an email. Do a cls first t=
o clear the
>> buffer.
>>> James
>>>
>> Done and added as attachment
>


--------------000106010903030404080303
Content-Type: application/x-zip-compressed;
 name="gplpvlog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gplpvlog.zip"

UEsDBBQAAAAIADBwVEJ68y92PRIAAN/SAAAWAAAAYnVpbGRjaGtfd2xoX2FtZDY0LmxvZ+0d
a3OiVvR7Z/ofmH7pM6hsmu3aSadGTWqrJqNun3YYhKvSIFjAxPTX99wHXBAN96p0TcrOrnDP
Pee+OW/Yq/edbquutNfGwnZtd6aY9fF8pimW7SMz9PwnJfQRUqaer0xtBwVK6Cmmt1jCvfrx
R55h+ortPhiObRkhUnzPC+vGwro4N+f3SsVYhZ7pIMP9e4VW6OOPat9drWzHwt3MkIt8ILFo
s9AI63m8Ru7StJUvkn8w6afuwrhHKlojpeJ6jjfzFDL43vDmchh6S1U5sylEv2sMh5f4p6r0
b7ud/k+XNYUUb/vd3+C+1/ip3eoM9EG72xh1fm7ro1v9qjHEsMtPcV9Rw3XlzvdMFAQw5PT4
Pv5IE5zMw8TSAzOwl54fbs5K+w9npe2eVXagGB32efmk0ArVdtc7UMfe5C/Ybf3Rmetk68f0
NyacksZqZG1wm7YR2iqBBaGxWAKCcjbdu3HlzFAavdbFuXJmKV8oZw9KVa3V1Kqq4S6GtIfZ
/s3/8TPyA9tz/1QCeCDgRnm0w7nS8u0H5EPdZVWraFX4W3vzFe+5xlaPHpbk6lHIro5j/Knk
AYNH9WUcMDZQvETZM1FLnQnZJds8CvdKTX2XPhG1+ERIN77vQRDbRBeFJ83yXCTEE2B3xZ6r
fXiCcOP78QTx5vc9CnT16GomV49AdnYc408lHxqhNtNrJfC0iLW67xI1iW6Be/ys7w2fXPPz
qGvHnjhTK1AvxoFvjvHxdJAOaooOuon+aLuW9xjo98h3kbPnkxTVVMgi4iat+/HbiyqM7+LN
N1+r1fHEdse4IbwDqoWmmw9fjT18hz5wEnPFJzq7aGnudhypID65XEkAY8JLID/bujJqDG7a
o7vG6AfFDhRVrcBf2JYKYR4LB85xxVQqzTXfzQ49nHCj4n/qGPTXheeObdd0VhbaBhsvVxPH
NkkVHx7UYpCI4AC0Zn38i+22Wj+ljhBuY2ws7QMR4GQeiPBoTcf3C/gBGfk8pglqhVL53ab/
Wvovnf7FOb4hbEOHO8o/FLhr3vZbnVHntq//0Oi34LTcXNYA3B/p7+/gjt52+sPRZRXuoaU3
2mWtiu/1/qj2qw4FVtEfEUqd4OgUUF1XL6L6n9sDVuZYnTYGvQUQGQwFdtuNvg6D0XtwA23i
mlb75y5pvnV1Q7vR6YltNH/o9Nu6fkkXA3CvPZH9Hs+flsg3DcdRAUHZhBnBgpzPRhCgxQQ/
qfVtOISX79iJK9tlXWGji/yYjvK9/CO0awamo/rBEoa55xDo+jzfOp5gzzZ9L/CmofLZ4HOl
WWl++aVyuwzthf0PZhKUlyFfYQJEqUHXVfVN9a32TtWqb4kpur44p8Ji+eTbszk01fxc4Q03
iSQ3sNhRFaXhOArBChQfBch/QJZKuI+Dd/eTo61g5RPcKrTZpNfeiF7f6/Qu5kSsoEZXflOB
v/DIVRjgaEPD7eVynCMhAec5EpJJzYSY5+AC5zusRAr4fgf3wVURB4pKnAmRMmdEUZkzI47Q
H0XkWaZE8Thj4rAMc6LgXdwJ1zH+xAtXbBq7+VRMdjdoNxujtg4w/fp9v4kXYxhT94ZNvX97
ezeKl6HV6ugw4CGgsUFX40mb9PK7WX8054avh2cM4LDr8ht6c/NErmfmJAh9OJ0U+suv7Mp2
p/1DcGaeMYpBdHPNrkPW5lt6vbXY1Wb13aier57+U3vQb3fpijDwT73Wtd5r/Hg7iKalD0cD
fBCqtRRKp78FpfqO4oTAlC3bYWN8tM4vqm/4vcbGMPcWaGn4xiJgz33OozN+NHzsYlPnBF8d
G3i9DKId6+BBm7nI0qfgbVPNHZULkBOemak2jSADs7YBYSA+WiA3JDW4K8cOQt1CDgpRGjZD
oW64YBWhDWQXPaYBS2+pL1fBPA0Fj5//REDE98f64ADcDi9l0MkvKeMDNVlNp8inbWxCo5HC
GMKNqrgPDkp0FGzOPchMnENBZN/zYtww2F3mPWuDA9LVZHHwKnFQPAp8EHafApDFx5OW2kHS
UoukpYiwx4JQY4JQ42KPFUhr25RuDH9GGcfVWYWcgAWVckAVEXBHQQIBdySkpKKej01kppaU
mVpCZrISKcD9bpmppWSmtiEztQ2ZqW3KTC0lM7WdMlPbIjO17TJTe0ZmapHM5IUrOo1nZGZU
2+pysn6rffX+hhTOWtT87b/vXcHoNAbMyh0tR/JqG5JXe07y0mp8qNOSlwEcuEaSV2OSV0tJ
Xo1JXC2WuAxzEN1cs+uQtcUO863Frqx8003XX1sijxh7yLNymO9TVv5e4nOdL701AemtpaS3
lpDeWkJ6axvSW5OU3oCvRq5hM77Vp5aXLC7TRbTG3kUCQQ+hOXfJ7cwNw4kT4U1WVGgv0AJC
b0lqCz3YJgIJHiJ/apgoQZGpS9LNgZUH4BFKDcyA7pnBkOpjMlvCKcJjxHOMJoiF1DPaCK/n
6ggFZvUR3CxfrBgrq6DQqg0NJUW/jOi3qSy8JhLXFJJRWuIm+Q5xTK7IUFhKk+EQ3Dxth+0r
r8pSk1+KTbeeVma0HA7OqjmbdXwA9EBs1idHEWTWk541XptdSO5fVKmtynUi2sTOMxoj8y1I
q0x80Flqjs6pNzQqDqNzpA1mjr6kXwVPTKmAlqFUvFVY5z5GihjrHwSjcwO8qF0/r7375qtz
YOHw8+Yt/nkHPxdfw8/bKv7Btd+8xT9QoWm1r85rVQKDH60W/7z5WsGmE/Zegn/ZWDkh6WVh
mHPbRTS2DmMLzdkxfT/QxHb3TNee+AYkAfQM15gl1Mx3KS3zCL6Yo01llzpN/HLFd0WZYsGd
AS8tuAer+C5iXl9AP2nBUcTeb5E6hU4EOGCRzUfysMg+CIcuoAMiUovbadJ8QetP2i54YfBv
EevC9Yvi1n6r/lPEc8Y7KmineQeFbXdQLMcL/gN2xxXLwhovZnuJDlrg2uPmCx16pFIX1kHy
1GvfbbVEcUXGFJUMSG7o7kI+C1qL1XnBYGasLmt7qsuHOmMLsDpIs7/8Sq4p44NA0gYIAREj
hN4Bcp0tItwSmNA6poLmUgl5kvjY2yBNs9yDhroQxMmox0Acn/gM5JYLbGtxfOoMEMffYflL
NQADPKyBpLEvTZhgQXLrmmRThJByKh8ZIY7MOJQVyDRHOBAIVwWwIGlOihStifXeBfaHewfu
XEQ+vabgBDCWUtq/xaBqlA7W7eYnhuWmmcJIUwltZDnYpArNqd82s/z55Ca6RQONU559k4zr
zFHOq+8gnjD8dajfDW6b7eEQXNqNAcQoRu3m6P2gffnJJ5+QQA1cFYZJk99wDdv24CnA1aT+
t+Go3dObt707GOpVt63DHNq9q+5ver/RI83FYkb9hUpudfgUhGiBlxtO7cRBrK9uXmNd8dbo
0GP62OkPlaS+4kPCpSd12EEWvoZENJk8tDhSFUeplEyIakt46rnQVDIstTMkhadQZk3umTWp
xgcWq7FHffiBsbzKh1/i7ZySC7xkLiCw0Qc+7bkIuU97LgJ5yOPzaGbjJ+zhIPcDFHgr30TZ
pJ0LtaZevKt+o1YPj6RI28qyZjJwnY14lKjV7N4zq/ngRTrUfpZYJJzhLHVqd6Y6d6KAh+EQ
lbbAcFql1wZZUQf19qZ9iX+UJHTU/nV0qYZoHVLwsE2YQb3T74y+sigMuEF90L7mhU6TFIpx
PeBm+81Bu9fujxrdev+WwnzwpxkBooX+bat93XjfHXU7VxTyy6/0aqHJapa4xQkgdfPhq6m9
Xi2/WsKbyQatfaDLXYejRAFesAnafjAwHxvDPkd+Cy/EZiOPllSmK5dEtZaGtbChNQpdWhP8
rjRsTcBWetRo/lSvrs+r8Oer6roGFzZw8mIUvQ9Wk4AI07prhAD+6kKN0CawHHVCF0HgPPlP
9es1fbOqjUukYq/nGgjFPDfc6pSm8ZFEPykPkTgZrd2HBnuK9qJb7klHPUZypNRrJEdDPEfy
ywjOGTka6kGSo9nhRZJuBAZ7eCNJb9JexAmPkvx6b3qVxJnSFYku3T7AtB3v8SfsTBIndkMv
uPddR45qbkgSPC5sAAjRMEOLEmJza/yLNe1a/v7ECQ4p1EhicSBrITCmSI7s0VrAu69yNIPQ
eUBic4xpVBX/5WVjtdbvk8uc1MPJK6zEQIpgMVqCadaV3rDTVVR4m3fhWSt43Rj8ifQu+vqH
RV7oxXmi4Gxcuda3WAMJDZ85P917Vt8dNW++VQzLorf4+yHhHFEMbDiAgw8XEK6wQVZ6D7QS
hCGwfvBjAoaJSm2q1KZKbarUpuxSm8qlKbWpUpsSUohKbaowbeqUX9wT8GF92Df4BAaY/yKc
0Ft6QkhCb+kJIZUv55Uv5xX+cp7A0zN+oe/bwdTYu2lRATPkG/pdNZJ4AXlrGHQN37IM5mCj
ztJ1kr5/HiCRW16KtiVSIhtK4CGT/a3fQ+XHNutX2279alusXy1p/Wrc+i0yjTFj/WpJ61fb
tH555iO3frVnrV9t0/rVstavJqZvbFi/2lbrV9u0frWd1q+WsH61jImr7baHtcj6vQkSuh2p
OOwRwC3sReyjA4ihVnwTtmj74sSRti9HNTckCai2L0ezqWtroL3uspqoHstq5bqJtiSmontw
qq7EkpmWzLRkpjLEJTP9gMz0JqPDPqPf1sRyp+m3bo/0yeH9cqdzc8GTAxVNCocPs4Kn8uRT
wukwj50Q/qpzQsW+zlzmhL74nFDY6DIn9IPlhOJ0R6kNYemOBeS3Uyb5ajkand6OVU0jlWzt
xbM1upEvlqnt8d5L8viaLz7pm+2fZMr3AWG/Q3k+C/tJ8XL+Betnv1edDfvVng/71baE/QhY
VvrnfzNa6BPVQkhCn6gWQiq/Yy35Heso7FdLhv1q28J+tW1hv5P8GrbUV7DtnK9gs/K1JfX0
jF/iR7LjsB8u08Kpfxk5V158+PQKOrxXlVxRfie5TMU4wVQM+qRJJ2K8xs8l8+XgWRwctuen
nnA0RWbFk74FgQwNipibnyHlY+EDlxPf4mkl0JBQWkn5UoVwJLR8qYJGQrNvTuS+ZrElEkoq
DnsEcAt7EfvoAOL/cxL57hRuyUioYDfRlhCqMm1DglmVaRsHpm1crwXSNiQVDdyKfAM8BHBo
C//nJI5d77/sT5w4H0KNHDGNJLWtp5pkVzvxJMBS9RWWJqXqW6q+pepbqr6l6luqvhJ6Z6n6
ClOVqq8g89zIhd4jPXpXnUiGsYtO+2vTML7cDHATpIHpuVN7drrJ33yMx04rhBV6lQmFMK8d
nJDVlimE4imEZy395q5797MOyzG8OMWMQhe9gvxomMRJZAZKxe5wZmCGS43zU6P36oEskkDi
9emmwrjoND8x4qLyyyJlOks6neWE0ncl82rSAut/mWrjotf2sRMsHs34Vg/XyZKfKnm2lSxS
zshybKKWEjnhovLrA6aD544tP+taKMlbCKnM3z4kf1vvwYA/ePp2627YuOPVtf2SugtO4849
9S8yg5vPimVxJwBErMQcbs//qR27J4VXkGNgp8JGIp2Ebl/m0Mn75l9pIHGB/Bmqqz4eAV3w
nADjN8xnr8UhxDAw4LFBbHZPrrGwTey73wwwwpkMPGfLN4zPq5sfMV4YttscjIY4hr5akhrh
w80x5KJ+hvUAHOCNJhfsoh93FaMCWcyoFsEDFERonove8ZmWiQolfyn5S8lfjstfpD5OmRO6
CearEDyjLthUpxu7SQwyodv58rod9oNm28x3hiZt4hNy6cTWt/CcPqD5nT+4fKtZyLQWQirt
79L+/k/s7/xj/yIN8MS0mAWegiSYJuUY0qyam+HiC5lA2WKIy7D+0hIvNeUXqikLnO4EymvX
lYXIAgRraCwl82mX3qMPJvY0pkosa2n4l+ysZGclO3vJ7OyYboZHww5db4lcC4C2GwC/cdAD
ggmertdh95gls6+4KiuUW0Brt3ySQTCHq/wPPuSZffmGx4FveOR+k17swGNCGRofydNArSwN
xJH3IvP3IwM/41501NT+X7+ZkpWdkmSWHYi8SQK/mZeoRf8bP7pbp2siSIg27FDPFZf5/vVS
TpVyqpRTpZwq5ZQw2X8gpzYMwBMOfErLng8YB5Uea34wUyjiKYRUhkXLsOh/EhaVfgpeZJR0
9yxZ0PQ5hGfeOpdV07kHau/l302xJdR6gFFQRl7lrYIyVHESoQr5w76b4nUFMszpbDHzEz3t
nvjpukVKdlSyo5Idiazoi2NHUqHOfwFQSwMEFAAAAAgAAHBUQkwLfxSCEAAAZ54AABQAAABi
dWlsZGNoa193bGhfeDg2LmxvZ+1de3OiVhT/vzP9Dkz/6WtD9GabzTqTTo2a1K6PjJombe0w
CNeEBoECJqafvuc+4IJguBjtmtSdXeCee859cR+/85A9u2p3mjWltdBnlmM5t4pRG9/dIsW0
fGyErv+khD7GytT1lall40AJXcVwZx48q19+Uf3xbG7ZJpG7xQ729RCbnM9yeFHjBXY8w1K+
S/4hol87M/0eq3iBlUPHtd1bV6Gt6Q4vToeh66nKgcUo2mV9ODwll4rS63favU+nVYUm+73O
b/DcrX9qNdsDbdDq1EftX1vaqK+d1YeEdvo1qSsquKZc+q6Bg4B3VbTvyy+QZGceJqYWGIHl
uX643Cv0H/YKre5VtqFkEODFeU8K665qOYv0AIzdyV/G3b32aN9pi5PjsXUEl5h5CvXxAljJ
cQHZunJLiqWmtClVOrKkQEsPLZXSglCfecCgHExLNU050BUgKwem8p1ycK9U1Y/KwYNSUatV
taIiaHlufUNW3W25uv74FfuB5Tp/KgEsEHhQHq3wTmn61gP2Ie+0gg5RBf5Wj94lWpDq3Xrj
luzmUv/ivqxZ8nqdkl39tCWwl5CW7PQ2kGyo/H7g4N3eBqB9YvGyNF+8giN3hvAsvmYLVz8M
nMRcy1uNy+ujVNNKLguJAtddDSU2tRIDtrp/Ygtbs+R1O9qgAIDU+03PHT45xrdRA2xrYk/N
QD0eB74xJhPRxhpgCQ0AhPZoOab7GGj32HewveZOEOUc0uEkRZr34w/HFWjf8dHJD2plPLGc
MSmIvAvVxNPlZVbly6x4aeVvGGv0lczF7KClD57N7CHynSvcN6BNZAjK97amjOqDi9bosj76
WbECRVUP4S+8lkO2jdjKT+ULzZ3Lhq36gUdK7VqG7wbuNFS+GXyrHKGDiRUqjcPG998rfS+0
ZtY/pHPsHWBf4RNfqf6gwsw5qnxAH1VU+UBx7kkFymfT3Hvyrds7KLPxrSJqaNDVpZMFoypK
3bYVyhUoPg6w/4BNuvKhm4fn7leb6enhV6RIKLDB7t0Ru19p0VObsPFHNbpHD+wNWI5xyAmb
aRUvrFEbX1tOs/kpvQ6hurHuWRtigmW+ISaDo+HDpnZzcqydVnmK9ChODEdNrVHvdHiy0e81
26N2v6f9XO81YYFdxJy9kXZ1mUy1e8PRaYWnr9u9I3RarURprTeq3miEIBh6o1hco/waI1YW
leMk36+tAaeludstQv4Qkxm106r3NGis1oWHuIJm69eOSJxdiJo1th3UGz+3ey1NO2XDx3PP
L/unlbiIy0GrUR+1NMjXzq96DTIww7ik7rCh9fr9y1E8JM1mW4PGD4GNd6ASD4DBbr8btUfj
Tve18IATbH73TtjDxRO/zxjHgTEJQh+mLCNf3/D7e872D7vfuaGnh8YdS7V+Dg6MA84xiB7O
+X3Iq/zA7n2T3y1+fzqIGMRIa59ag16rw0aPkz91m+dat/5LfxB1WxuOBmTSVKoplnYvh6Xy
kfE8mu+PK0fiGfFawycPm5bN23JesLLGj7pPFHuVjYA61smw6fS413TbunWwqU1Bx1eNFZkz
3bZdI5Nt6EGGZuYRoSE+nmEnpDmkKtsKQs3ENg5xmnaLQ013AMDgJWYHP6YJnutp3jy4S1P/
nmP/iZLgaY55HYJAyhGpDDu90jSZV5P5dIp9VsYyNWoptCFcyorrEKRERcFy34NMxwUV0MK9
SMYFA6Q07nkZgpDOpoNDRkmQ4laQibB6FpDc56YBBeszONwCfQrn3R0sYfjrTqfKYWMh4Fmb
HtDk7CH/1DEYjWauQ2alPTdxHm3szSe2ZdAscTJBLiEV6uiFR8wLGeBoeSHDozkd38/gAvaJ
whMKNpmZAhdLHFPxEaUkzqcVZ5M4l5TkoZQ8kFKHkTiI8g+h5QMo5/BR4M+KswdyopMnOnVW
nzjRaaMQ+FT42seh52t4Nrd1WAuQr2SIejCLp7TYuvg8rgcBnk0IKq+tkEQMsBY3JMKiaAtY
FL0Ii6IIixZ2gsBMxGEmikAlf6QF5a1bQn9mPZPs7JqmZJl1DXwy8HEjTLCEN8SUXOvF3BSR
ohQiRUlEitKIFK1GpCiFSNESIkVLiBQtI1KUQqRoJSJFOYgU5SNS9AwiRREiFYkz1o1nESmK
EWnE2eyIInrN1tnVBU0cNJl23LvqnkFLESdmURsqwLVoCdei53AtyyYTPI1rOcHmd++EPVw8
8fuMcKRwLaJ4lmf/w+4Cz6IYz3KOQfRwzu9DXhWf+n2T36P000Ga4dwsXI5jxpmFuOKFZqHt
KVkDxcAYSQBjlADGKAGMUQoYo5LAGPjVyMhvxI/a1HSTSS+dxAtiY6MU/ABvxKGPt04YTuyI
bzJneHiGZ+BLS0qb+MEyMIDjEPtT3cAJiUxeUu4OtvcArEdJGp0QXE9P1TG59WAmkTaSPjIq
Q3jLqD2mZmE7y8rgdlKiGKeIKQvkoxyB5BklA+VTRXpRkWlsz2gpcC8opGxRiHhDgiNbCL0y
IfYSWWYG/wtyVgFg4uzFL/OJ/gpashVBZkz5rBG52cG8YO4IhiJMrKpqyirL00KHYAVHczDO
E21LahSMedUsFexCeknhELSoo6JbmQKf65BC2s7MnwAdlEN3HtaELZFuRzGmoAztC9g2WrX3
1Y8n797DVgyXow/k8hEuxz/A5UOFXEjuyQdygQyECEa+viGqC1iL9bkd0sJmunFnObhmwda3
MYMlyOdbLDvWxNfB297VHf02AQo/pjDhBqySm+nHCvWRQfAt18MU0W3WBPvhNos3t1x+vHNv
upL0GbDxl51zemyvC7B7ba3s6ETbWgV0X9106fQo3NKrpWVvY8xpwdscD3Ld+HAILLCl8c4F
KhtfTKKWbbxaUfp23m+wxa0s2PY+JsDddkrewvukkHBb403K3l6jI2y7ndKTsxv9mNHzGDGr
6IkMoelRYi6cRrlwuljfZ1kEX8sYQWN8i9bEty+1dK6vA1Dp6xt6T6kClJJSBxgFOGp8dOCR
0ooHaMlcLR97WIaZKOTlBLyyAky1lpRhmrUkM9OjJZmZVinJzBRgSeZ8BbjES4N2vUA6uQWU
k0rsESVGMbmJxFuR0vAx20Zstnyly6L7BRx9CrBAaJm8HF5Q5bgDWxWpF/bRbYSRI4XESPH4
yl6fkCpRxFSnUxw7VRhJCi1NxXzRseCd2mooeV7PivtTGAuWCSX3DdquA1t5X/kINvXhzVC7
HPQbreEQLLf1AdjsR63G6GrQOv3qq6/gLcNV4XwsOozQ+UsPngKSTfN/G45aXa3R715CQ886
LQ160OqedX7TevUuLSw+EtRrdsKqw6cgxDMy2DBbJzbmdXWKCuvIl8aaHsvHlm3IpPmHPkQk
uvLzHA6tt+HZXcexG7tsYneNkvHV5PhpnvPRJP0zq30zUPc+GmGdaAQ1nrcEYG5w+cPG8iaX
v+yvL/b7wNvYB5Lv+3VuCHSZx9PSyLoo+AKhzwMcuHPfwNkolmO1qh5/rJyolZc7K2KNtaSy
ChtK2n8jpbpCVbmumXZkTtdtCuG26J057LZgb6wBnLtonZKLkqSOWjejUzXEi5CRhy0662vt
Xnv0zmQ0mPa1QetcJNoNmniRYkyke41Bq9vqjeqdWq/PaD6YcvQAs0Sv32yd1686o077jFGu
b9jdxJP5beKRuOlrxsO7qbWYe+88Uw91lvvARrV2rPJK3SBDms4d6uTwdBN+sFr7gVKjUESW
8MwJ+YUqDGzAx2lUb3yqVRbvK/DnXWVRhRtvD/2lCy9jPgno1l9z9BDI747ViG0CvaxRuYgC
s8F/qp0v2E9lWiT10wnNKj9TQUrCcCD0o3ICPpatYck0ISnFskoLEBNFeSFvHSFmqighx8wV
JQSYyaKEADMPlBBgposSAvnmi5IvFtr4whKSZozykglTRsnRTZozYsn8w48c6mOQZ7Jn1OHQ
f4DO2u7jJ2LHkJZ1Qje49x27lNCdXo7/cWZBWkqEI3wqR2D++Nqcdkx/bdnEZidVhhgX8E2T
LbqU1KM5g18llhIZhPYDlutfJKKq8Fck9flCu0+ObxL0kV8WZqNOQB96MVB6qdWbhijLg9HX
Fauc7M2uBS0n2/Z2opf38cj7eORdi0dOrrRygcm7FWIM/eDhuFECjhk5R8FGP6GxnqOg0PGx
9AmNZRW+xPtkPFldvtRBFyv1aH2l/qUHWp5Sj/KVepSj1KOkUo+EUr8Bb3dGqUdJpR4tK/XC
QS6UevSsUo+WlXqUVepRrlKPkko9Wlbq0UqlHiWUepTR3NFqNR9FSv1FkFLqadYL5i4RLy/p
43Ulue9WCvzmKDvSspGyU0roTi/Hz5SdUiLLygYCCF+sLJaqInoNVEjWzQtfIwENeuedvKyZ
m3Xxvmkfj8SndvY+njfk44H3vffxbNLHQ0wX8mP8ij75I9Eb8VmfZz7ikzVdVJ83XVRzTBeU
XGo2F39IR+q7PVJMUt/tkWLaf9znZR/3iUwX1aTpoppnuqjmmS52+xNBG/g0kFX0aSBOODfl
V9r4NXw2KDZdkDRPbD4WiMHPN4sWWffy5kCaYw8Z3xBkZK/0dQLGNaIEk7PY2FHnGGvf23CN
sb7somOMteztuMX2H/XZO9FevxONrcpyLrS38G0f0Xfuf1ui5QScloDw0t4qKKTYW7UPQf1f
hqAmvVWFQamRt6owBLVw2om5S8XLS/p4Xcn/a2jeytC4Mt4quSqi10CFCl3yhRoqYyje6Bjf
3ilfbpvbO+XznfLnCymnfJnZS4ooKS2sMy8S/7+66FfEI68tm5gSUmVsJESgOFbLwbsdogXt
KwxaIP/Vj+E6U+t2dyMWRBs3G64A4/MmDdDP/89He5PzOibng6Z2cdm5/FWDYRke76IF2sGv
PVaBTk4jtuRmVn+pMIHy5ueXKtS00YXvY4ftzrsXaRFbwqXmwmczg4tmfW4b+N4WvUFbtNaF
xn92U3Tzcli/FNnVFxqoN22SjoOhCne+zxkD5eB96NM+9GmDoU9pPLiPhoqjoQrX3GsJgiJo
1IgftXCRTPmplGuZySTbqXgEVVSSrPNOYIlynrsd8sGJLnAHXJJAx0QMaY6dWm4gRDaRTJuo
ZXWHvX36jdinnYVBbSYsNcP+La6pPqmGDZ6kFRvFduow0GFWY96FJ0efWQaxZi9bsWFyBa6d
NGMTLl5k2rI90y2nMRjB/+Tsh3OP5sjNUpFdyqCsmw+wOI9QKYsp+wSHnBDAECY0Cx7gWUYk
a5mV+2lVcDcPQZt3YFvdXTNlopFkkxMnhTBpZDlfmYkgVsjlevLZNPJEu/Yq+V4l/3+p5HJA
M7FEXi3STPSBQ80UhWzDAqLngk3JwUjkZ+Gm9L6+x5t7vLkDeDMoMdnfMuKUkAowjJ3ulfts
gOc++p7vTuNAgiW7QCHcfdSt0HE97JhAtJwAtgUbP2Dowu6i39Vtzv9//2JMXCj/yiFyuY59
NsRcrpnFsFcKG0sx7QH0HkDvIoAut2JeBZ5e3SUOr1cz5P6uotgZwLKyUcYykRT7X1Hsf0Wx
+V9RSMxUIiUt4OOSApBVSgD8KOVl/DVkQIcuL8QQyf73H2t9Ghm22WC9H4zIfc54abte72Bb
zZ41lawL9/eWk73lZAcsJyVn7Wr2t2NXMaa3s1s/rudfUEsDBBQAAAAIAG5vVEIe/a7GJxMA
ADHbAAAXAAAAYnVpbGRjaGtfd25ldF9hbWQ2NC5sb2ftXXtz4jYQ/78z/Q6e/tPXxQElTXt0
kikBktLyyADX64OOx7EFuDE2tU0e/fRdSbZlY4glAylJfXOHrcfqrd3V7s+6yw/tTrOmtB71
ueVYzlQxauPZFCmm5WEjcL0nJfAwViaup0wsG/tK4CqGO1/Au/rpJ65ueIrl3Ou2ZeoBVjzX
DWr63Dw7NWZ3yrG+DFzDxrrz9xIv8aefVC8ul5Ztkmqm2MEekJisWCgkrHn8iJ2FYSlfJf8Q
0s+duX6HVfyIlWPHtd2pq9DGd4fX58PAXajKkcVitJv6cHhOfipKr99p934+ryo02O91foP3
bv3nVrM90AatTn3U/qWljfraZX1I4s4/J3VFBdeUG881sO9Dk9Pt+/QTJNiZ+1tT8w3fWrhe
sNor9IK9Qpt7lW1oOrvWG2mj+uC6NdJ+aQ2G7X5PGbZGyqivfBxWTmDAJPKiC1g/iyeFVaha
zuOGJozd279gFWkPDg40uqbG7DemnEDNYWlsUpKlsZhNhYTJcSFVOnOkLEsPLJXG+YE+X0AG
5WgiXahypCv1bvPsVDkyla+Uozulqr5Xju6VilqtqhUVkRqGrIKpfOl//II933KdPxUfdim8
KA9WMFOannWPPUg7r6BjVIG/1ZN3vEaU6af4lqQzA/yAzMxB781kQ6HLqWksvtLS85meSBRP
5BblF5tRuY0nNtMOPmw2Be2DjudyEVgCgmMvy+skmIVkS9KrTIBdyJZfbJUlWDaUnRxsGrO5
5phgso75rO5O6UKlN6VgscVGqXrRoHoRqfKLnjt8cowvo7pt69aemL56NvY9Y0wWtI01ULE0
0Ku0B8sx3Qdfu8Oeg+2CzDVKOabDSIo078bfnlWgfWcn332jVsa3ljMmBZE5UE08Wd2u1XC7
5m/R9Ty4QF/JNGUHLS0Od8OLxDuXy3+gTWQI5HtbUxhfuamPflQsX1HVY/gL03Iszcgl8ipz
GzbIsaEcNx75KmmzRQ8vKvmnjkGnn7vO2HIMe2nidXHjxfLWtgyaxLsNqSRKSIOBfI3a+KPl
NJs/p9YmKWSsL6wtM8CS3zLDgzkZ383hB7S153MaoAYpx79b7F9T+9junZ2SF8qQNHhjnEmB
t0a/12yPYG60H+u9JizD6/MqRMPUfbiBN/ba7g1H5xV4h5JO0Hm1Qt5hequ/ahAIE3ojSqnR
PBqLqDxWvqkglg5rIAzzXO0WiTqrnCi0MSyy06r3NGiM1oUXKJOkNFu/dGjxzctrVo3GFlq9
8WO719K0czYYkPfKFZrw8expgT1Dt20Vciircbo/p7JzwzBfWk5YDDlm0h/DVn6Q33gbm2fY
qucv6C6p+z6e3xI+VFvfTlSwnWyEcptQvehahuf67iRQvhh8qTSOG19/rfQXgTW3/iEMiPFJ
7CmhcFKqUHdFPal8i96rqPItPaI/np0yQbR48qzpDIpqfKnwghtUU9CJSFMVpW7bCs3lKx72
sXePTZVyNptM8Ge7G+fjz0ixUGiDPbsj9vygsbeYHYUBNXryl2P4C9vuOIzYXdtIgblsZ0eZ
gP3sKBNwH5IpZjwkwJlPGKIB8r6BBZGkiA1FIc6JaJhzoyjMORLP0Bsx8vWciaZw7sTjshyK
RG9iUSQtZFI8cBl2YzOzgo27u52FttxZtP03g1ajPmpp0Djt6kOvQWZlGHejO2xovX7/ZhTP
R7PZjmR7OHqVePQN9vjdqD0YM93TgqMwwg6fi+/Yy/UTfR4Zt37gQadZ7Mdfw2e4TFo/+kfG
UUgxiF6uwucwLPNb9uyb4dMK0ztROp9G7efWoNfqsKkJo3/uNq+0bv2n/iDqljYcDciKrFRT
Wdq9NVkq71meALizadlhGx/MU1g+/B2FbZi5c7zQPX3uhxwoZw+PH3SPWEHVGc2vjnUyXjo9
BGhg5Jw62NQmYBBVjQ2JcxAYrpFJNnQ/E2eui4SGeHiOnYCmkKpsyw80E9s4wOm4KeFkDhwA
8UpmBz+kIxbuQlss/Vk6Foyy3hONoubZsA4eQcrhoUx2+kvDZEHdLicT7LEyVmOjlkIbgpWk
uA4elajIX+27n+k4jwXZfceDccFwwDTuwjJ4RDqZDg4ZJR4VtwJ2fSQRhSQ6EXYoFHYoKdpQ
LNo2LyqWK6t7k/hndHKSnNXLabSobg55RUTcTjKBiNtRpqS+np+bSk2UlJooITXDEA3A+2ap
iVJSE61ITbQiNdGq1EQpqYk2Sk20Rmqi9VITPSM1USQ1eeCSdeMZqRmlNjucrNdsXX64poGj
Jjte9z50L6F1KIzMMnyUI/LQishDz4k8lkxWdVrkhRE2PCORh0KRh1IiD4WiDsWiLsw5iF6u
wucwLCtczH0zfIbh6046/coU2mMhE8hKQD5RWcl3ThZ2vtxEAnITpeQmSshNlJCbaEVuIkm5
CfnVyFdhxK/axHSTwUU6iB+JCZPG4PvAmDn0deoEwa0d5btdMnE5x3PwSyapTXxvGRhkZ4C9
iW7gBEUmLUk3Ax3NB5NTqmE6VB8eGlJ13E4XHpQSioSog4Sfb9YDsulU5rMC+LDwTFwziGOz
qgFLWtENUqUuolLXKQs8JRKULCajLsRF8hniObkKweKSOgQjDCeSp/KqEhoFyxvNNE+kvywi
o1/w6KyCwcpjk7+ajzeAxyVbwVYWy5HWPXgMH8iwqo1rMGUSVtlhNqmqxGHerLSywjuSLZ1n
59RpXYbRr650njHquKQJhrRdOQY9Qzl2l0GNGzFZxlgDoTna18CLWrXT6vvv3p0CD4efk2/J
z3v4OfsGfr6tkB+S+t235AcSEKq+O61WaBz8oGr8c/KNQg4txIwJBmx9aQe0lrluzCwH10Ij
ox0Y052aiaCMyE60lklkrTcd69bTATvR1R19mjhZvk8dLHdgqtldJzcppdRy9wJ1MYa579qA
se67CvMF6ohFwT4qSguWvSyANWJpv10BHrnX8iORuddKKMPeRw1U1u5xumn5+5oDWvi+x4b8
7mVouCKyx/FfqyntZcPxmvY13byG/c25v2f2578E7+Oq5v5K39McU/10n+NPyt9v4yMtfH81
JFc/usicUiU9litqvZg9gyUTVV/U3clV6YIa83YuGHSxhyMJLfbjr/SZOpnQmPTphEbREwp7
g8y1cBThlcaJDWTKsy4HIJUlIDYKeaJFESJmZJCgYzYGCQJqaJAcNDiASxAwI4IEwQYDglwJ
0MYtS0iaCeQpEydiydFNsi1KyTiXh/WAeGdtxhikyqMcCUSrAtkAwSdHC2uQ8OsOMERSP/Dl
fXyZgBQCRwshsb0+iapE4LROJx+mlouDhpam4HV0PMJO7fXrhHU9y+9PLuwu2dC94uU8g/b3
yFZOK+/BqzH8dajdDPqN1nAIdvX6ADwlo1Zj9GHQOv/ss8+ouwieCssZFk5SQtit/+STZJr+
23DU6mqNfvcGhuCy09JgbFrdy85vWq/epcXF4kz9yHQBdfjkB3hOphH2w62Nw7o6eYV1xEtj
TY/po5Eh7aHpxx7ASt2C4HaQvm8BHycDj4s9Z7HXTMm4zNa4y55zlSXdZM+4yBRlx2hOkZnO
9QhvmSEXtZmbgYA11XhBEnvtTrc5sNo3uc0FhGW5u1/z7v4fYbXVeMUa2cNnuG3o+wD77tIz
cBYWeKZW1bP3le/UyrbH0OrW9W/nOJKyDBAss5xACEHNhRyL0sYHYLwrHkBhW4RzR5p5UAjR
dEPakZtHt6nqvkdP4nG3BRKtBmr8deuc/CjJ2FHr19G5GuDHgEUPW5R11dq99uidyeKAd9UG
rSseaDdoYD8mF1JsrzFodVu9Ub1T6/VZnAc2Q93HLNDrN1tX9Q+dUad9yWI+/sqeJr5dThOv
BBVTM+7fTazH5eLdAr5l11nqPRvuGuw9FuH6q1HrP7ciXHdMllxkr3EDckTmDqLjydKhzryF
bs4tKI7FLsxb8nk9zI0fDvWo3vi5Vnk8rcCfd5XHKjzCltPv0di7v7z1qcyvOXoA0e+gCYgl
3cJ41AhdTAgLynuqXT2yD9paJEQTim0+oBS0WfEDtjyRh2VqSlnHJOhYciEiYiUrRrgoSsis
ZZK0zGImSUStZgUGE6xSkkTMeiZJtMGCJl8KtHcHpSQtacWoE9a0AqO+alGTYFOX1LPWv4eu
2+7Dz8SQJkHtBK5/5zm2JNlMl6V4mFsQExPFSkaGKNYSGSHRFccfzUnH9IoTJ9imZLOdACAc
vj7BknQP5hy+RJYkGgQ2NFOSSFXJ3wd7Fob15aN2lxzq5HmCflJMD3pRnGRtPp4tFyYj4jB7
OWUzF2+/V0S9SAvzgelCqHmhTEKoeaFMLwKWr14kJG5N6Q7bHUWF4Zu75hJuCgCtmr1FVw6Z
9Et8AsAGlXvpmN8TJTbQvdBT4NyF6Z1R4/p7RTdN9kouLQpmmOUg8w22cBLAJMECbcu9h0Sm
YIPiANo85DBwCeb/v4P5Rbb3+JXi86FvIZY9CpQH0PIAWh5AywOoMGF5AC0PoOUBtMgZsjyA
Ht4BtHpxze7Fo8ATwPGRqCu4FdWfwcFjmk6TdKJw54akcsnyrfFySDtluLujuJK3nXsDrVXy
0HolD61R8lBSyUNcydsnsDOj5KGkkodWlTyOBeVKHnpWyUOrSh7KKnlIcD2vKHlorZKHVpU8
tFHJQwklD2U0ObRZ7UORknftJ7gVTdhyF5AiilF7eBtqSJaYiDViTII6EmOSZDNdloKJMUmi
VSGCgCdvVAoYew6TJSuKpkaWjDN1fro9XAtTyYxLZlwyYznqkhm/UmZ8ndGin9Gwq2Lo9Z3e
Sl4MvZ6Lxk82VBSWDxf1ggXg4EH5rJn7g+TvFqv7piH5gjeBl6Dd1wzaFZnpXE/ylhlywbm5
GVYg+f89JlYKq0owsXIzEmJi9/CFEeO/b5apse5tGtZ0rpKzvXrOxiby9fK1Al8lJNevccA3
gQtyOn7b9zN3e2fXCIl/Zu2Q5Oz6odHS0jH/fm2h67yFMgld5y2UqbzzW/zO72oS8FRNAp6q
6wBP1XWAp4O8sFvqom4r56LuMHxlym2f8Wu8yDsGPJFwGDiAL8GknIhE65SRlqBzHtgHTjHG
V6Yb/z3Cl7XvbeF7y6uzS7TtAaJt2VaTx9q+xRu0+XhwoC6PK3hzL3H4SMp7cQwKlCSKQdlB
w4VMAyyTQONZRpGmlx7b0mP7Qh7bq0cBj63sPiDFFCiBG9m2LuL/4L+VhnUCJrQ4cWKZSDb7
5TzI3BVcfmkiwUXLL01CLpr9nCT325M1uBeasKUaRIooRu3hbaj/D1h6MaIMkl2Wa4lWFE2N
LFmK2R08CDElng+1maXMKGVGKTNkqUuZ8SplRmlmEGZ2pZmhNDOUZgZRS8H/ysyA1nzTKQtC
35QmguN28GHfqg7ty8XZGyBMDNeZWNPDhdjzNsqCy8Xz7ha5CSP/JjGb0K9N3DlMLlGa4ijN
o6Z2fdO5+UWD4Rh+c4igTQe/BRQ6XZayDlWCx8nwH2kwziuCHDk4H99+MPDVgwE9xTha4bXy
H0Jo8xuXj1QVAsYKZSoxr9tgXrUuNPg/h7w2b4b1G55cLQaEZeijaCcJsaRc3CBH0m7CCsYI
21wwIQPgioIKn2n1CoZXABMY76S+KZNZoGQhICFkinDF+ZkzOELey8zGvjKFedJYGIEogFxO
gBQFccyZa01XYGJZ/sJhY1lew3Fkab6ziirbwIfkAdIScEmKpebzAbi0F4ZQVi+StUtDKtP6
9P8SZengN3eVKdHejfhVCx6TIS8Vci0zGWTcPFzGUUnkPS5qe5ilAPviWYh9YQWoKHPICFGK
pa9Uwn3wVn2lc+xNcU31SBPYiOf4UL8L3Qoo9pIGvg7bDYfde3L0uWUQ98KqDxVWpe/aay59
Pa2s3vo61y2nMRgNCU5guaAp4subZ5F0a+rmPfCOEyTpkWMXYEqTzf17UHQ0yAlDeRI19Tlr
O2RP0Ep7Dove67iCUuHDW0JASrZWsrWSrb0JtiZ5rWtCb8z1jfmzZQDWWweUyMN1jiUaKefx
ktJ7iak4W2GuvRhdJDTzQ77+QKBT/6HdVqB1+eZWIZusUKbScFsabp9e4s4CgXX/Ku8rSPQr
vLQgFZPgm4xnbG+mEBnJRJ41hgop/r+7T0EFEAfZrz9F3ZqlQaU8ebzWk4fINkzkKc8euzl7
wCzoC1nI+MJ98MDsMZEkWznpJGbzUC04Ja5dmI+WuPZtce25F54L6g6EUorIwwWIIFmaCDxU
xei8gnRwTC9GyPTU/wUmX4woljCydKblC4Ho4TcDohf7/5NEm1J+0l+Ms5cacqkhlxqyHNku
NOTIaHKoyvGqr6LUl2W4aqkvl/pyMC715VJffiX68iYv9K7/p6QH3Qocd4EdEyItxwfZYeN7
DAN6uE7rzW1+GR/25vpzXdoH68KW79N/6NGWb2y+W1rIdy2UqXRwlw7uF3Fwy2+DV+nv3tzN
0P29OcP2ru8CY7yZZI1jfBuhUjqg5Q+CpXntMMxrBZb7ZpLS+Jas0JhM51NPup0rB5DNo324
FrKSC5ZcsOSCgmNackEBLij1fcC/UEsDBBQAAAAIAGNvVEI0zK485RAAAO2jAAAVAAAAYnVp
bGRjaGtfd25ldF94ODYubG9n7V3rcptGFP7fmb4D0z+9xVhaJ46jGXcqS7KrRhePpNRpqw6D
YGVTI6CAbLlP37MXWBDIsLq0sqtMAuzZc/bGXr799ohcfGp3mjWltdBnlmM5t4pRG9/dIsW0
fGyErv+khD7GytT1lall40AJXcVwZx48q19+Uf3hYm7ZJrG7xQ729RCbXM9yeFLjBXY8w1K+
S/4hpl87M/0eq3iBlWPHtd1bV6Gl6Q6vzoeh66nKkcUk2nV9ODwnl4rS63favY/nVYUG+73O
r/DcrX9sNdsDbdDq1EftX1raqK9d1IdEdv41yStKuKZc+66Bg4BXVZTvyy9Qyco8TEwtMALL
c/1wuVboX6wVWl2rbEHTjaD1RtqoPrhqjbRfWoNhu99Thq2RMuorN8PKCSQtoVv9ATqE96Sw
ZlQtZ5Fu2LE7+dO4u9ceHRxqi7PTsXUCl1h7SlOo0oYmCVl6aKlUFoT6zAMF5Wgql6JypCsg
Vo5M5Tvl6F6pqh+UowelolarakVFUD1eZNZGcZGzrZabE1eKyj5kxbyVLOPvv2A/sFznDyWA
gQYPyqMV3ilN33rAPsSdV9AxqsDf6smbZMmzTYVSTbVmTZJtttRYcQ3XTXq9qpadW2hRYKYi
RdnrSSZZ0PKzjYP3e5KB8snOF+V1o4HK8kkOVCpZ0fVi7Wn+gKkWDn94S2V69vLYkyuc5JAr
k+K6I01i/pVpn9U1FNPmukmvW9UGBS8k42967vDJMb6NSmBbE3tqBurpOPCNMenmNtYAB2kA
frRHyzHdx0C7x76D7TXnmSjmmDYoSdK8H78/rUD5Tk/O3qmV8cRyxiQh8jZUE0+XB3GVD+Li
gZs/Ha1RV9Ids42WXu22M0OVr1zhrARlIk0gX9uawuaj6/roJ8UKFFU9hr/wWo5lZ67yumQ+
spUf5QubP0gMW/UDjyTbtQzfDdxpqHwz+FY5QUcTK1Qax43vv1f6XmjNrL9Jq7GXi32Fjyil
+k6FLnlSeY8+qKjynoL/swqkz8aP9+Rbt3eQZuNbReTQoONWJyNRVZS6bStUK1B8HGD/AZt0
UoF6Hl+6X22pqsdfkTQhxQa7d0fs/kmLntpEjT+q0T16YO/WcoxjLthSsXhqjdr4xnKazY/p
IQ75jXXP2pISzCBbUjL8kCk1tc9np9p5lYdIjeLAcNTUGvVOhwcb/V6zPYIOrf1U7zVh7F7F
mtDnP10nQ+3ecHRe4eGbdu8EnVcrURiGSPWzRgRCoTeKzTWqrzFhZVF5V0FCD8YUl6W12y0i
Pq2cJPPUOq16T4PCal14iDNotn7piMDFlchZY+O43vip3Wtp2jlrPh57ed0/r8RJXA9ajfqo
pUG8dvmp1yANM4xT6g4bWq/fvx7FTdJstqMJgVegEjeAwW6/GbVH4073tfCIC2x+987Yw9UT
v8+YxpExCUIf+iwT33zm97dc7W92v3NDTw+NOxZq/RQcGUdcYxA9XPL7kGf5nt37Jr9b/P50
FCmIltY+tga9Voe1Hhd/7DYvtW795/4gqrY2HA1Ip6lUUyrtXo5K5QPTeTTfwjsVz4jnGj55
2LRsXpbLgpE1ftR9wneorAXUsU6aTadIQtNt69bBpjYF6kM1VkTOdNt2jUy0oQcZmZknhIL4
eIadkMaQrGwrCDUT2zjEadktTC66A+AILyk7+DEt8FxP8+bBXVr61xz7T1QET3PM8xACko4I
ZdTplYZJv5rMp1PsszSWpVFJoQzhUlSchxAlMgqW6x5kKi6kAETuRTBOGPCqcc/TEIJ0NG0c
0kpCFJeCdITVvYDEPtcN6F5gBstboE9hxbuDIQx/3elUOW4sBPJr0yWaLD7knzoGLm3mOqRX
2nMT58nG3nxiWwaNEksTxBJRMedQuMZsqABry4YKj+Z0fD+DC/A0hUsUzDIzBS6WWKfiNUpJ
LFArFiexMCnJVSm5IqVWI7ES5a9CyytQzuqjwJ8Viw/EREtPtOysXnKi5UYhCKr4vY9Dz9fw
bG7rMBpAQckI9WAWd2oxefGeXA8CPJsQyF9bYYkYai1REgFIU5NilNkOYCraCKaiCKYW140g
UMQRKIrwJn+kKeWNaCJ/ZqST6Oxop+JSIx4UyyDLrSjB4N6SUnIWKNamYBWlwCpKglWUBqto
NVhFKbCKlsAqWgKraBmsohRYRSvBKsoBqygfrKJnwCqKwKoIXLBqPAtWUQxWI81mRyTRa7Yu
Pl3RwFGT7cl7n7oXUFLEhVlAhwogL1qCvOg5yMuiSQ9PQ14usPndO2MPV0/8PiMaKciLKNTl
0X+zu4C6KIa6XGMQPVzy+5Bnxbt+3+T3KPx0lFa4NIvH45ipZuGveKNZ2HtOBkExaEYlQDNK
gGaUAM0oBZqRJGgGfTU6zzDiR21qusmglw7iBeH2qAQ/wCtx6OOtE4YTO9KbzBlWnuEZHD8m
rU38YBkYgHOI/alu4IRFJi5pdwczfACkVVJGewTfxKfymNx60JVIGUkdmTRGf1nwzqKW0Hsk
zML3KEbgdy7JAniSvWhUoSYQPZMlIX3KyousBMYXwWwK5CoSEG+L6WSQvxBnof9yHMmbpcze
+nJ8sjBBph0zWwGWFOs1TOWKnaAwmGBiVVVTVC8PJ3cPcViUjfUkFpXaSwiJUOa9U0SJnYWQ
sXo9V0SFlIaxpLDYK8fuPKwJypFOHzEKoArtKxjmrdrb6oezN29h7oTLyXty+QCX03dweV8h
FxJ79p5cIAIhAndvPpNtCJDK+twOaWIz3bizHFyzYKraHv8ICeQTkB1r4uvgUdDVHf02AeQ+
pHDcFkjGLVVkxWaQweldZ8T2lTvNCgD4TtM3d51BPAtvPZf0hL79N56zNuywEjBr7S7xaMXa
XQ50Ft168nS929X7pYnvpN1pyjttEnLdfouI1X5XbZ6LRbY/qkQ2O3m/IvkdveRgl/NasPNJ
TYC4HSW9i5dK0eDO2pwkvsNiR8B2R8knezn6YeVWTyD0FZFLm71ImN3tiQix3aPCXIyOcjF6
iV0/iyOovRRJGqNmtCZq3pTzXH9rQa1vPtN7aodBJaldBpOARo03DzxSWYkWWiK0JfwtpbTJ
blvSwpO2YFvrskZs11xWm22My2qzMVVWm217y2rnD2aZtwdF28Q8OSFImiWmDJm2TE4q8aSm
NHzMphWbDebyidH5A9ZSBXTAz03CEC/oFrwDkxfJGSblXTjkI4V4bHFf0l6fiCqR/1anU+zJ
Veg1CyVNeaDRxuCV2qlTfl7NiutT6Jn2rznl+wat75GtvK18AA5/+HmoXQ/6jdZwCERxfQBn
BKNWY/Rp0Dr/6quvoPfAVWF6PGki550peApINI3/dThqdbVGv3sNDXDRaWnQMq3uRedXrVfv
0sTipUe9YTBAHT4FIZ6RlwjjYGJjnlenKLFO+dRY0WP7qF1IeWj8sQ9+l67EAILV8XUcMq9z
xhyfEcXnQ0rmcCjnYOi5Q6HkgdDqwyDI++AZsZZnhBp3XCPLvfKhQ58HOHDnvoGzR+qnalU9
/VA5Uyubs7AxbJZFzDDXpKnpcvgZMstlndsRSajbdN3YIfF83G3BvFmDNeSqdU4uSlI6an0e
nashXoRMPGzRkVFr99qjNyaTwdCoDVqXItBu0MBG6JxY9xqDVrfVG9U7tV6fyXzYjuoBZoFe
v9m6rH/qjDrtCya5+czuJp7MbxOP5MiwZjy8mVqLuffGM/VQZ7EPrFVrpyrP1A0youncodSt
p5vwe8PaOyqNXKZYwDMn5AeG0LABb6dRvfGxVlm8rcCfN5VFFW68PNTZn6cxnwR0Wag5egji
NzA0EIuaQC1rxC42hN7gP9UuF+zXAi0S+vGMRq3RV8GszPZFwDJJCx+XzmNpi1TWjMXJW5Ct
0hpW3lpWbMskY8i2TTIWbOskY8H2KDIWbAslY5G/jZJ9w1DMTZNIbqfWME1sqWTbOLmtik3z
f0NDkMCYJMCMLyiX2n+ACtvu40eynypv7IRucO87tpzVnS5p8DizQBDbxOt8xiZGBNSOwILx
jTntmP7atokZUK7MTgjncGTiljN7NGfwey05m0FoQxnlbFSV/H2071hQny+0+2QbpxAjnLWn
jtrlsoKVa+6Z3AZtceMFW8VXufEq/ePhww7sdezACl/4hjutQoXCnVahAt1gxf2SnBZsvMHa
lLCn7tcSjcz9sF+Ix3Vhdf5L1+vCwhV7MJdyry6lVMq9upTSwav64FW9b17VhUNt/EIcpaEi
3Kk4CgDCLHeusdWvm6x3rlF4ThMVdJ1zjSWqUOblM6UsZyi3MsbkIVqfPNx0BcwjD1E+eYhy
yEOUJA+RIA+3cLSfIQ9RkjxEy+Sh8AYQ5CF6ljxEy+QhypKHKJc8REnyEC2Th2gleYgS5CHK
MIRoNZ2IIvLwKkiRhzRqk95L7Ncw9fHapvx0utwmN4dGKW8c0ShyVne6pAGjUeRslmkMBMxA
CTJKLpPodUhaCV5huwe6r5pXKPP9oAOv8Ip4BXjhr4lX2IODW8IrSDTyC/rgUJnqiI8KPfMJ
oSyvUH2eV6jm8ApULNehiz/jU+qrQaWUSn01qJTS4dNCm31aKOIVqkleoZrHK1TzeIX9/kDR
Fj5MZBV9mIgLLk2JoTZ+CV8tinkFEo4CZf0l4SODcA68996SrJhy/o9bPoZjRXi1oJlVL3cU
pFUOyPkVIWf2Sl8obl7DNVLUeX8P8Fj5XsnxHavMXh7esaK9oqO7w+eTDgd9L/+gjw1LyWO+
1/AVJVF5fka4JMtxqJfZypQ+JYNUSpySHVzs/5cu9slTskKn++iUrNDFvrjfid5L7dcw9fHa
pq/d2biUTcbZV+qUrGQm0euQtBKnZGX8KRy8324UDt6u90Tx1p5pFK8NTO/gPyG5Mhz8J/L9
Jy4XpfwnpPovSUPWXDBbm9m/dm8K2R+WwI9S1rZN9Ay5Mv873hy78suAHF4lxVzwP1cdSOV1
SOWjpnZ13bn+RYNmGb7bR47ZwS/eKYP2zuLzNPK/yRmuM7Vu9/cwTZRxD31MHPwaXEscvH8e
JQ4+OJIcHEm26UiSXngOviWxb0nxoHspLiVk2TPiRy1cJEN+KuRaZjLI5irujxKlJO26QRaH
zLL10g9FRU3260RUlOs/Pw49HEtu8VhS60Lh//NTyeb1sH4toqsbnlX+N6eTYohIHk3u0SGj
qAM/YUwK6GwtJvscVrlkS4h4YpomlEvP6Qc2+ZWwyc7CoNQRC82wf4trqk+yYY1XknNGMasc
Bjr0a8yr8OToM8sg3PMy5wy9K3DtJOlMtKIkK0keeqZbTmMwgv+O3A/nHo0p2U1FvBz5q5sP
MEBPkBzryD6bJGs1Cx5gUdVAERrxhJSziJAFdWEq+5O1mH+VM1tiVBNAMxF0rTKuzcHdPAQu
wwEwtL9cTKKQcti4+sMSzo7hcjbll46XE1XZL8CcKNgBMR8Q8wExJxFzyTHyIiBzohIcMyck
dG0q/h8jCHYu2yYJhSx6Lj/FH+DzAT7vAXwu7KcJhQOA3hRAQ+PrnqQjg+c++p7vTuWs0mB9
ea4rQYKzuKzDWakDwYMP8sEHefs+yGX6KjErb+FjWQuIk7MAqm4NI38dI9h7r2HFtlgHD+oN
PpfsmFawps/17r5w/CwB86hboeN62DFBaDkBzMc2fsBQ//3lY1aXWY6e4VxMYaovnZqRrNl/
xtRIlrOYbinFyZRSOhA3B+JmH4kbySHzInic1XXitM5qhdyz0DWbarV+lu1ZexE5kD8H8mcP
yB/Zbrta/0ANcRtjeju79WULmYLu/wBQSwMEFAAAAAgATW9UQhEoWi8KEQAAUJQAABQAAABi
dWlsZGNoa193eHBfeDg2LmxvZ+0d2XLiRvA9VfkH1b7kWgsY73q9VDkVDLJDFoMLcNZJSKmE
NNiKhaRIwsb5+vQc0kgILA1H1nZIOWiO7p67e/qQ9vSq3WnVFW1uTG3Xdm8Usz66vUGKZQfY
jLzgUYkCjJWJFygT28GhEnmK6U19SKtff+UZZqDY7r3h2JYRYSXwvKg+Pz4yb++UijGLPNPB
hvv3DM/w11/Vfjyd2Y5FGrnBLg4AwWJEgQRvdzTHrm/ayvfp/wjqN+7UuMMqnmOl4nqOd+Mp
tOsXg/OTQeT5qnJgsxL9sjEYnJCfqtLtddrdTyc1hWZ73c5vkL5ofNJa7b7e1zqNYftXTR/2
9NPGgJSdfEPaignXlcvAM3EYQpez/fv6K1RyMPdjSw/N0Pa9IFocFfoPR4VWjyrf0ewk6N2h
Pmz0z7Wh/qvWH7R7XWWgDZVhT/nc7l5fAm05YNg//qPCmlRtd76iEyNv/BfsI/1h7uuwpUb2
IfwkWBPoI6fEliRNiZUsJZAAT2hXanTNCB3biGyVloWRMfUBQDmYrNc15cBQoFg5sJTvlYN7
parWampVRaTL+RZrmRalhpBt6E6pqR/T7ZHRDBjpmzVH8sevOAhtz/1TCYEdQEJ5sKNbpRXY
9ziAupMqqqAq/NUO36aGmTQrN5z1Wit7FF38vE8g9G/9swTI6RNAS5auLq9a4wQUE0zvxxIb
sQTB9XZE7ccmFVGkuW+73uDRNb+L23XssTOxQvVoFAbmiCyBg3WQdjqIOP3Bdi3vIdTvcOBi
Z00pFNdU6OQRktbd6MNRFfp3dHj8Xq2OxrY7IoTIzKsWnixusBrfYMWbarmwWmOsZInyk5Y9
vts5PeUHV3hioE+SJ6b2o/zU1BVG8rIx/FmxQ0VVK/AHa1iRlpPK1FEqoTHBIb5VKib8eZOJ
UmnOxaZp0yMAT5X8r47gsjX13JHtms7MwsvKRv5s7NgmrRLjglpSVMh/AaZZH3223VbrU2aX
EgIjw7c3BIDNvyHAgzUZ3U3hB8Tb05Am3LEqv08V+IFetfTr4yP9pAYpMlBIQGowbOnNRqcD
yWav22oPYZn0nxvdFmzJcwoLq3h1CSmWbHcHw5MqpGEND9FJrUrSsNK1ax0yvKI7pJg6hdFZ
QXVefV+tsXrYDjwvoNoaKTqqHirwHyevd7RGV4fO6BeQAJqkpqX92qHkW6fnrBmd7blG8+d2
V9P1EzYdUHN22TupAs6ZV7jso8gPdDydOSAtVahXcoVGOKWXkxXzfQo8jBAjKgD9MR3lJ/nD
tbRvpqMGoU8PTCMM8XRMmFJ9RRfRWl1kM/NE62TsF7YZeKE3iZRv+98ph+hgbEdKs9L84Qel
50f21P6H8CPGNnGgcFml1KDxqnpY/YA+qqj6gSpPx1WgzyST/xjYN7dAs/mdkrQAVAK4kBlE
xqmK0nAchUKFSgDMIrjHlkq5l0NW98125rnyhpAEgk32vBiy55XOUpwZ8aQaP0WiAn9w7iq8
YDu9ghXdwcSjDSe+kAtuCQi44ZaATKbHCT7Ic2SOeUawQ57Ns0QGGbPFOCc4I80L7hjnBYcU
AN1hgp7nlKxGcEtRlueYpHgVyyR1nGmKzCkfxmrmSWpjBpqQuOxrzcZQ06FeP7vqNsnEDBJK
F4Om3u31LofJlLRa7Vjy8wFUUTwBJnv8btYfzFsj0KMDXuDwp3/MEueP/DllEAfmOIwC2O6s
+PM1f77jYP+w560X+UZk3rKc9nN4YB5wiH6cOOPPAW/yA3v2LP60+fPxIAYQM61/0vpdrcNm
jxd/umid6ReNX3r9eNj6YNgnm6Zay4C0u0tAqh8ZzIP1DtZUpBFvNXr0sWU7vC9nBSdr9GAE
xH6lwgygmE0W8nrOAdWRQSbZoBqGDsasGxdb+gQMX6q5onJqOI5n5qpNI8yVWcsKodsBnmI3
ojWkKccOI93CDo5wtuwGR7rhgs6OF4Bd/JAt8D1f92fhbbYUzG/BIy2ihjjehiggdEQuB05/
aZ7swvFsMsEBo7FYGvcU+hAtVCVtiKJUQ+Hi2MPcwEUp3AXuRDYhDDqrecdpiIJsNZ0cMkui
KOkFbBsuClEs+HhSZc/8xZvsndUbh2Ctvq7T6vyVnRaXubYDXBlxsxUgEDdbAkpf5YuhqQRD
GQmG0hIMZSUYWi3BUEaCoQUJhhYkGFqUYCgjwdBKCYaWSDC0XIKhJyQYiiWYyJyyYTwpwVAi
wWLIVkeQ6La006tzmjloMZW8e3VxCj1FvDDP5VGBHEQLchA9JQdZNdngWTnICxz+9I9Z4vyR
P6cEIiMHEZV/vPof9hTyDyXyj0P048QZfw54U3zr9yz+jPOPB1mAM6vwOI4YZF4kigXNi8IT
cgaKBSkqIUhRSpCilCBFGUGKpAWposb2WTNJ6hPLS2f9bBbPiWGZluB7WBGXJm/cKBo7Mdx4
xiTiFE/BxZTGtvC9bWIQjxEOJoaJUxi5ujTeLdzZQzBZpcvohuCaRqaN8Y0fABXO9eMBEnb+
hKgX9ULWs8K8sCdkxWQlUHnpz6oWxH8G34/xl90HRE0sC1lJ7kaQkBQrJCDFLYGVpa8JDJEv
pKilTYlsHpv8cmS29Kwyd4UQxfk7BENni78IJzogytK9CHPzyfeaqM1P5DlzHzDd0sKqSkX/
yp2ZMTQDMMmn7yhJnnVWDGYFrcwVRpSIoWYvMYzi4v4XgGw6Sowse06kjD5koEoFbjBKxZtF
dWEapVwxudpQgPY5cC+t/q728fjtO5AJ8HP4gfx8hJ+j9/DzoUp+SO3xB/IDFQjVFKL1EAMp
WMqNmRNRYlPDvLVdXLehO1uzOwH+ctNPxx4HBvjCLwzXuEkZHD5m7A1bMO9sZxwrLqXM0Lfj
dhi33GVLwGF3Sd7aMf2E92+7kawU2fpiL5E/uxsCsLyd0Y5l4s4aoHx329SpQN3R0lLau5hz
SniX80F+tz4d4kaxo/leet3Z+mESrexiaQX13axvuENWFu6aj4lb4G4o72A96ZVxV/NNaO+u
0/GFeDfU07sb/ZhTIUlh/nYt5ZZcuEQXGxtYFblVl/FnJrdatOatdjPfGfpx/Zs/xf58TZ8Z
BYCWZJQAVgIQdT47kKRlxRO04AovH7MmA0wMAXIIviwC0+tL4jCVviQwU+FLAjMdtyQw08pL
Ai/XxCUWDfq1AXZaz5bDSmnYErOYZjQUi3GVADNW47DjW5oW5Rcg8BQAgWC68nh4TlXiDrAp
0i5wz11EayOFRIXxWMpujxRV4xixTqc4Wqxs3HZisaFzwQe104jtZSMrHk9h9Nt/FbEN5qDA
pCM+cJR31Y/gKhhcD/TLfq+pDQZgkG70wRUx1JrDq7528ubNG9g/8KswOE6blPPtFD6GpJrW
/zYYahd6s3dxCVNw2tF0mBvt4rTzm95tXFBiibBRPzOJrQ4ewwhPyTLCORg7mLfVKSLWKU+N
dT3BjyeG9IfWVwKI7vTKnyAQh68jHm2dcLTEE5V4oZScC2qJ++kp11Pa7bTa5QRt72Mo14mh
VJN9S663Wzz+wLJe5fEv+0rFng+8Dj6QXu+XyRDoMU+2pZl3efADQtN9HHqzwMT5iMsjtaYe
faweq9XNnR+S+rKUqgxMJ+szKqU4u3dccd54bjZVoUvPDQlxLr9PV8Y6t2MnheHQK/IOfV6V
Cw0kRB2uy+faCflR0qVD7Xp4okZ4HrHigUbPfr3dbQ/fWqwMDn+9r52JTLtJMxsZHgh2t9nX
LrTusNGpd3usLAADmRFilun2WtpZ46oz7LRPWcnna/a08Hh2k0qSGIy6ef92Ys9n/lsfXpY1
WO09m9X6kcob9cJc0WTmUteRb1jwkm79PS2NXyNhGd8ak7dyYWJDPk/DRvNTvTp/V4X/3lbn
NXjw/tB3p1iaOu0A6hgERhjNxvXlLywRTjiCfTMiMO9rSIW2eCdm45BK0LprRED3LUDzXo9h
muqk4aRl2E7BY/1szt7e0kjup2NaJX+YAauEZUcosHIIAS7bwoLtqCQWq5JGIDYkeSR/HSRm
S5LAY/YkCQRmU5JAYPYbCQRmW5JAWG5fklxY6OOGFNJ2JnnMlK1JcnbT9qYE82mOwHBPqR+o
dw+DdbyHT8TQVBrXjbzwLnAdKaRbQw7+YWpDPkFJhGkOJVGUKB7RlkafrUnHCtbGTTE7qS67
EYQMEB4vhfVgTeFFWSmUfuRAB6VQVJX8PTi3LGvM5vpden7Td2fysmsmGEiqJRBwM9+iKM/x
vaDkTYPyV67Km7UizbcSS57u2+sJKt+Hie/DxJ9bmHj6pMnFiz+vyG8YB4+SjjNS2qjQ1CWm
hsHkVXYpxVbo7utrtpvKhmWaLVqu2aIlmi1Ka7ZIaLZbcKnnNFuU1mzRomYrvPBCs0VParZo
UbNFec0WLdVsUVqzRYuaLVqp2aKUZoty2ifaVNdFq3VdFGu252FGs6VVG2x+gi6PGeB1MbmH
udS9bMmNvzRufOOXQro15ODZjV8KZfHGjeAeW6wxSTURL4McUvoOXCvlv4YPy4DmuXu//Abe
eNFNad/10hnYxYee1ht6oeNe/kNP23TBw8SzeX+1njg2vFVnVkDs3XGvyB3HlvRlOuPW8M6L
Ib807x3xUJVdOu6f2m4QArDfV8n6nv6c3p7ZrcPsDlr6+WXn8lcdpmXw/jnyPhe/9AgEujnN
l/C9rUJ+Jb6otfz7WSs/I/LEBiDV+U1AiyWEYPH3okp9nqoUUKnPU5UCSgvGYuhdffFq8/CP
zDezNg4Hea1f3IoN0bW0Ibq2zBBdW2aIft7f7Uq+1yVlQCWXpUJez29J638IzC76EBgvOLPK
spvRyk+E0XVY9T2UZ/5hMYBfvHyb1CazUPZCXJUufnYeShfvHZN7x+QWHZPZC/zeV5n4KgvP
3EtxURL1wUySejRP54JMzrOtdJZxKu7fjCmRdEJqra/hEI9PaTmZNsgWuzwZ3CqH5z6U938c
ypt2eO4+uLd0KK/s9ickJLGFNX8j9H3A43MLeJRwv5ZrYiGaMCUjCh2r5N9ZMT13Yt88X6+q
6KO0S1UISEmRRxTUXPNSr5psQzXaVHBx1ajUQL6YjU9060sb+HZlaPu/fFo+begC6tD5L27n
al0OGpeiurah9Wsr36eXNkuJEyJnk3pG1iUxBG5aEgWJbiJ0F0lmLfSTchMmqolwy6omZdn+
Xi95JXqJOzepg5rlpji4wXU1IM2wySupvaBEP4lCA3Y/5kN4dOFfIDWJFrOofMDmCj1n8dVC
SnLx3cKpYbvN/hD+rbkgmvm0ptwuFdVSeoBh3cMhPkRSt1D2apYk0jS8B6mrA9ycfues6GoO
wGlEqbbWe/Uodbne2jfRCKsqNlSxqrz1pIzrZB8nvo8Tf4Zx4iW2OsEqjRBgSQSokkIAY6k8
TrAGDqio8kjstrSPcI8ZuxyWZYfrhcSXeQ+0XB9kYuDD21kE8RkurPjztdWkOiltrHly9A+G
Hbmej10LCm03BPnl4HsMS/98Y+JX91k+Tr7sBYMYrvJr8cItV6mRPCvTVapfe9vV3na1t12l
bFfljsiLMF6lxsCtV6kSyVeHCX8uFA9PsOuXEIMlN7AvFpcl183iuKhSYVilgPYRVluMsKLM
XDrAatvRVIvMfMMYqy8TVSV3Yl5EpNXqIfEAqtUAm3opCkRjuj7vpyh9y+eWQCkhJbq63sKv
Bs8PZF1xuHfA7B0wz8ABE0oc4r0LZl0XDEy64csFRfneQ+AH3kQKKWWP27tOXrrrJMVY0DLG
UtLBwhkLSjMWtMhY0BOMBeUZC1rOWGjNeuJwNbiUeyBmO1JWbMZ2JJGWsB0kz3bKtWVObqY3
gWQHM7zgX1BLAwQUAAAACABucFRCS2sYzd0RAADkzwAAFgAAAGJ1aWxkZnJlX3dsaF9hbWQ2
NC5sb2ftHf1z6kTwd2f8HzL+4tdrCmnt8+HUkQKtKNAOoO+pOJmQHDQ2JJiElvrXu/eRXEKg
uQvggxrnSe72dve+d/f2NunVL+1Os6a0lsbMdm13qpi10f1UUyzbR2bo+c9K6COkTDxfmdgO
CpTQU0xvNoe0+uknnmH6iu0+Go5tGSFSfM8La8bMujif+Eg5NRahZzrIcP9eoAX69JPq91cL
27FwNVPkIh9ILMoWmLCaR0vkzk1b+Sr5Hyb93J0ZD0hFS2Dseo439RTS+O7g5nIQenNVObEp
RL+rDwaX+Kei9G477d7Pl1WFZG97nd8g3a3/3Gq2+3q/1akP27+29OGtflUfYNjl57iuiHFN
ufM9EwUBNDndvk8/0QQ78zi29MAM7Lnnh6u90v7DXmmbe5VtKB4EmOf5s0K7q9ruMj0AI2/8
F0yy/uTc62TGR/Q3xp8QHlUyJJiVbYS2SmBBaMzmgKCcTGR5KieGUu82L86VE0v5Sjl5UKrq
O+XkUamo1apaUTVcwYDyn0oz/+NX5Ae25/6pBLD4IaE82eG90vTtR+RD2WVFO9Uq8K969oZX
qLGRokMYj1R2UDe1ICaciG8Rwhf2J+Z70Hsl2VA8VtkVoaVWROGxSy+N9JrQ4jVRnH3RxSE2
ny46bOEA7YPJzl3pMNFiw8m3DWWeZEYgm3iw0gICRq6B6eUkIGIk2RddThL7R2gQpbeNGNdi
3at+3yC2Ba7xi543eHbNL6OqHXvsTKxAvRgFvjnCy9NBOpgpOtgm+pPtWt5ToD8g30VOQYEY
lZySQcQsrYfR24sKtO/i7Ntv1MpobLsjzAjPgGqhyermq7LNl7/h1svNAn3Fs5QdtLTq241k
Ee9crjSBNuEhkO9tTRnW+zet4V19+KNiB4qqnsI/mJZTsvEbtdF72202f05P25XtshWKDVby
YzrKD/LVb1r4pqP6wZxsxZkDW+nUVE4bS76g2hQNEir+Xx2BCT3z3JHtms7CQutgo/li7Ngm
KeJNhFIMEjFsAG39cGAeI2Nub4kAm2NLhCdrMnqYwQ/YcC9jmmDkKKe/Q4ua+vt27+IcJ4jU
0iFFxZcCqcZtr9ketm97+o/1XhMW681lFcC9of7LHaRost0bDC8rkAZOZ9pltYLTem9Y/aBD
hhX0hoRSJzg6BVSWlYuo/NdWn+U5VruFQW8BRBpDgZ1WvadDY/QuJAjP5tUNVI8TrV87tBad
7pd648d2r6Xrl3QcAOfaE5nq0f3zHPmm4TgqICirMCOYkaVZDwI0G2M5UVuPU/2+a5u+F3iT
UPmi/6XSOG18/bVyOw/tmf0P3sFU0CBfYdJdqX6jwlSdVd5q71St8pacE5cX51SSz599e3oP
rBpfKpxxg6hIA+sEVVHqjqMQrEDxUYD8R2SpRDQ4uPOf7WyLnn6GuQLPBn12h/T5i05T8R5l
GTV68sQp/IPFeMoAO2sa5pe7F3eEBHtyR0gmPSTGOxJn+K5kOZLB6Q17ExdF+zPK8S1K8nyb
kny8VSMA3640l92yFI9vWw7LbF0K3rR3cRnbtjSzeetGXWm2rn65ifvVbLZ1aMEABoG1ohL3
wqSP383ak3lv+Hp4wgAOe86/pYmbZ/I8McdB6MNyo9D3H9jzPJ1v/RicmCeMsh8lrtlzwHi/
pc/bZcAKOlEBHw/951a/1+rQ/jLwz93mtd6t/3Tbj/qlD4Z9PLWVagql3VuDUnlHcUKQQpbt
sMY9WecXlTOe1lgbrnMW/+jJ8LEHS70n+OrIwANkEONTBwfV1EWWDtsPqeaGwhkIQs/MFJtG
kIFZ64DQEB/NkBuSElyVYwehbiEHhSgNm6JQN1w4MKAVZBc9pQFzb67PF8F9GgoONf+ZgIhr
jdXBAZgPz2XQyS/J4xU0XkwmyKc8VqFRS6EN4UpRXAcHJSoKVvseZDrOoaCTHng2ZgzHGvOB
8eCAdDEZHDxKHBS3Ai+EzasAdGJBi5Eq43xjcGfaVNtKm2qRNhVpPlaUGlOUGleLLEO4rTNX
MfwFMxYXZ01ZAhY0ZwFVRAHuBAkU4I6QkiZuPjbRqVpSp2oJncpyJAPpzTpVS+lUbUWnais6
VVvVqVpKp2obdaq2Rqdq63Wq9oJO1ZI6VXtRp2pcp0aozQ7QZUtOmvTw2vulewXN0xgwq8a0
lzQzLcarNK2ZGcCBZ6SZNaaZtZRm1ohGZs8P8Iw1MqPoR4lr9hwwnniVUo3MCjrpgmtLZNOw
bZvV03zks/r5Eq/UfO2uCWh3LaXdtYR21xLaXZPU7oCvRm57M07qE8tLZufpLFpixxyBoMfQ
vHdJcuqG4diJ8MYLqtRnaAY3X0lqCz3aJgINHyJ/YpgoQZEpS9LdgzAOwCGTapgB1bMjQaqO
8XQOywa3Efcx6iBWYi9YK7ycmysUmLVXMFs+WDFW1oChRSsWTIp+HtGvM2l4SaTOKSRj1MQs
+QxxTG7oUFjS0qGEbCJ5KamKZ7PU+JcR06mnhRkriIOzZhAlp5O/iscbwGHJVgSZ8aRrjZdm
B5K791R6GuU2E2WxcY3GyLxZaZOKdyRLzdE59YrFxWG0j5RhZulLuuZwx5RTsBOUU28R1riL
jyLGFgTBaN+A7GnVzqvvvn1zDjIbfs7e4p938HPxDfy8reAfXPrtW/wDBZpWfXNerRAY/GjV
+OfsGwVLauy5A/eusXBCUsvMMO9tF9GrbWhbaE536T4EFthkzDpgOvbYN+AOvmu4xjRhKL5L
2Yk78LbsrCubzG3imNp/VVQo7rkykKV7rsHafxWxrN9DPWnFsY+5X6N19toRkID7ZB/pw33W
QST0HiogKnV/M03Y72n8Ce89Dwz+3ce4cPtif2O/1v7Zxz7jFe1ppnkFe5vuYL8SL/gPxB03
LPfGfD/TS2zQPY49Zr/Xpkcm9d4qSK567fu1J9G4gB9FpZ2kK7a7kI+ClmJzXtDBGpvLWkFz
eVt36h5OHYTt+w/kmTp8EEj6AEJA5BBCU4BcY4MISQITGsfUrbFUsKQkPvY2SNPMC9BQF4I4
GXUgiOMTn4HccMHZWhyfOgPE8Tec/KUYQAO3Y5A87EsTJkSQ3LgmxRQhpJLKR0aI71YcKgpk
2BEJBMpVASyIWZMiRUtyeu+A+MO1g3TeRzi7puD4KxbR2bvFoEoUjdXp5Mdl5QbrQktT8WRk
OFin9hrSvq5n+f3JjTPLhLT7JmnXiaOcV97BhcDgw0C/6982WoMBuLDrfbhxGLYaw1/6rcvP
PvuMXLXAU2GYNPYMl7BpD54DXEzKfxsMW129cdu9g6ZedVo69KHVver8pvfqXcIuVjPqe6q5
1cFzEKIZHm5YtWMHsbo6ecw64txo02P62MkPhaT81Id4R09qsYMufAWBWGIBWOxSKb5q4pDM
HdOa+6WNd0u4aWUkYMFIQDVeiGbWZco2A0n3UeAtfBNlb9ov1Kp68a7yrVrZ3nkqbR7LWsYg
ZVZc0KKGsvvADOWdSj6Qqq9S8km8EFKKwEMUgQITuKWoy0XIFXW5CETCxesMH8C3lnDbnncl
JByOkpKaEBYulRXk7eiCwnCICbrH66/TbgvEWw3M0ZvWJf5RktBh68PwUg3RMqTgQauBt3Wt
3WsP31gUdns3rPVb1zzTbpDMflwFmG2v0W91W71hvVPr3VKYD/4vI0A007tttq7rv3SGnfYV
hbz/QJ8WGi+miSQO0KiZj28m9nIxfzOHF3kNWvpIh7sGS4kCvGAVtH5h4C06gnmO/AxeiI95
/HbjdLJwyS3U3LBmNnCj0Lk1xq8Ww9QEbKSH9cbPtcryvAL/vaksq/BgDSfvEdF0sBgHRP7X
XCME8JsLNUIbw3DUCF0EgfXkP9eul/RFpBbOkYJCShkIxTwt/JQoTeMjiXpSHh1xMlpahAZ7
dgrRzQvSUQ+PHCn18sjREE+P/DCCM0WOhnp85Gg2eH2kmUBjt2eS9P4UIk54gOTHe9ULJC6U
rsht0O0jdNvxnn7Gzh9xYjf0ggffdeSo7g1JgqeZDQAhGnaAooT4GDV6b006ll+cOCEhhZgk
BgeiDAJjguTInqwZvCoqR9MPnUck1seYRlXxP543Fkv9ITnMSROTvPFJbPoIFqMlhGZN6Q7a
HUWFl19nnrWAt3PB/0dT0ccyLPL+K47jBOfgwrW+wxZIaPjMWek+sPLOsHHznWJYFk3iz22E
94hiYJsYHHI4g3CBDbrSe6SFoAxB9IPfETBMdNjB5wJW4ceNQhdoYH4wt1CkuRCSUKS5EFIZ
YF4GmBcIMBfYD6MjiRmHrrD46ihTnjzLk2d58ixPnnZ58sylKU+e5clT6PBYnjz3ePK8oR8S
I6EOECkm6aHnd5ByBh5FW3MZKevw57eSxe2ubc+k6+wubb3dpa2xu7Sk3aVxu2ufwYEZu0tL
2l3aqt3F4wm53aW9aHdpq3aXlrW7NLGVvmJ3aWvtLm3V7tI22l1awu7SMsaVttkS0yK76yZI
SBVSsN0WwBwKEftoC2IoFZ+ENXpGnDjSM3JU94YkAdUzcjSrUl4DublJX1MJykrlqommJKai
c3AsDr9SmJbCtBSmpTDNbdrHEaZrbNhr+AB5cA+Cc7paVt1YJhytDB9mPY5o5fhTyVWhjsGX
SOH8vP/w8i2Cynkzy0BEiUBEsU8Jl4GIBxuICBNYBiIeUiAiTIhYIOKOZRQVfq9WUtHubRjV
NFIprg5WXNEJOlphVeANEt7r43uRBEs3ifk7im9SCsjoAwgLggaWYUFlWFAZFiS0H15TWNAW
snJbzcBkpYTE59+7f/Hr9llJWX1ZUlbXSEoCljMo8r8vL/Q5eyEkoc/ZCyEljYx87PIL+bJf
yKdSNVuSlarVdVL1P/nOfqHv69uZ7+unC64tib0z2vTxfToBmz7qewyf7E91n33APQUr+EEi
fDshp7fEox2AkVC0g5R9z5stszCS7gaBplPE3IaXN4vlzeJh3SyK713MoRCxj7YgLm8W/8Ob
RZiSIwrTKN81EBam5bsGVJhmXyjIfftA8F2DfCNg1aIgXOQZcPf/thzKSOsDjbSWE+4rZv2h
SuvS9BWW1qXpW5q+pen7cU3fdFBdaW3KyK/S2iytzdLaPHul1uaNTEhxfuQtmKgHHXIL7QN9
UDxq2gTRb3ruxJ4ebsA0b+OuQ/Zg9F5lsB70a4PYY6VleJ54eN5JU7+569z9qsNwDC7+y2g9
F72CmGLoxLFH3blIIJT4cENIoPkHGTsC7XpVQSNlGMjHCANJi+fXERkCO0M6JOSwgjuw1Dfj
pB4ukzk/lfNsK5mlIoWFhBCY/B+nwuI7YzyOjjViOrcLHzFYOrdt+THJQiHQQkhldPNW0c16
F1q88+Dm5t2gfseLq8VCnvcd5Jy7jo8ivpn3gsU4JwBE6cXiWFqk8jg14RHjGPjAvhKiJiGg
y/g0eSf3K72kmyF/imqqj1tABzzn8u5b5vzW4uu5MDBg2yDWu2fXmNkmdoKvXt7Bmgw8J3l7
h7GYPz19oTczbLfRHw7w/fRiTkqEFzfHkLtRM6xHkABnmtxFEv0EnhgVaFNGNQseISNC89LN
GO9pGQRQypdSvpTyZbfyRfJDM4mzaO4tSXC/CMFZ6cIh6XCvSRKNxP3jp2tpWw8fn7NMj/b8
nN+Hj3iAzm9c/rlX6HAshFSeoMsTdMETdP5CPoojdKIb7AydgiQkK93z0sKVH6TFBy6BsuYo
LSOsy7N0aeseqa0rsLoTKK/d2hUiCxCMoTGXjDade08+HJInMVViWMujeynOSnFWirNjFmcr
jgLJ0CBuvwnd19PSNe/oCwYYMYMt7c0oo/8LS78y+n/L6P/U20ukoNBmwIQyND6Sp4FSWRq4
Gi1E5hcjA+9cITp69vxfv7Ww7d8Cci07EHnLIPl3oGT/fg+drUO1mUutUWqNUmuUWqPUGhJk
/4HWuJF8h+vJsEPXmyPXAqDtBiC/HfSIoIeHe1m5uc2S7nR8V5nL82ivLqW79BFvMqXbmn8d
KXRnKYRUXmyWF5sFLzal1/VR3HNu7hW79nwJIf1W9W7/SKn8cG+mWHNZuoW2KO9O5Q9O5WXD
QVw2yC/2zRSv6yrCnExnUz9R0+aOH6ofpxRHpTgqxZHYiB6dOJKKav4XUEsDBBQAAAAIAGRw
VEL5qEOvbRAAAACcAAAUAAAAYnVpbGRmcmVfd2xoX3g4Ni5sb2ftHWtzozbwe2f6H5j70tcF
28o1D8+kU8d2Uvf8yNi+S9q6w2CQHRoMFHDi9Nd39QCBwQH8aJ2cb3IgrXZXD6Td1WrBl59a
7UZVai7UmWEZ1lTSqqP7KZJ0w8Wab7vPku9iLE1sV5oYJvYk35Y0e+ZAWv76q8pPl3PD1And
FFvYVX2sczzD4qxGC2w5miF9H/1HSL+xZuoDlvECSyXLNu2pLdHWdAbXFwPfdmTpyGAQ5aY2
GFyQS1nq9tqt7seLikSzvW77N0h3ah+bjVZf6TfbtWHrc1MZ9pTL2oDALr4hdQWMq9KNa2vY
83hXRfu+/grl7MzjWFc8zTMc2/WXe4X+w16h1b1KNpQMAjw451li3ZUNaxEfgJE9/mviYuXJ
vFcWZycj4xguIfKEMqjQ8SB8DNU3ZArzfHXmAIJ0NCnEUDpSJQBLR7r0vXT0IFXkc+noUSrL
lYpclhHhPWCsp8X4/vEZu55hW39KHkxhSEhPhn8vNVzjEbtQdlFGJVSGv8rxe1Eb4sPDxi0c
nuRIplYfUk0Ip+Q4odg4rcc5PmBipPIvQ1oZLGpS2V6vx2hDYfDCibDmwK07I/KNqoX3WwxA
+2DIM6c3DHeOsSwoBgpwXp7eyaXJ+hJtO4WkMw6RJ1FJsmbT1p1ABQRBdj9eGKCwf8UYrtet
yk91agCQ6r7t2oNnS/suqNc0xuZE9+STkedqIzIRTayALaGAAaE8GZZuP3nKA3YtbK4pgIKS
Eh08wlJ/GJ2elKF9J8dnP8rl0diwRoQRGXlZx5PlZVbhyyx7aaXLqTX6Sh5RctDiam07MiR/
5zLlBrSJDEHx3lalYa1/3Rze1Ia/SIYnyXIJ/uCxlOj8n5lSyVMn2MP3UkmDP3sykUr1hXi0
LTpR4S6T//IIDM6ZbY0MSzPnOk6DjZz52DQ0WiSaCqUElGk9AE69Oro1rEbjY2wuEQYj1TE2
RIApuiHCkz4ZPczgAlbSy5gaqPbS7zMJLtCqhnJ3dqJcVCBFOgoJSA2GDaVea7chWe91G61h
q9dVfql1GzBxrilud6h8uoEUS7a6g+FFGdK3re4xuqiUSVrpDit3CmR4QXdIKRWKozBAeVE+
Cco/N/s8L7BaTQI6BRD84+yVdrPWVaAxSgcSlGfj8hqqJ4nm5zarRWFzt1b/pdVtKsoFGw0o
ubrpUdwrO/Opj3zHVfBsboJil6FcSgBVb8Y0pyn9XHwZpNapmbLrOXQd1DwPz8ZEIlRXVt0x
NNf27Ikvfdv/TjpGR2PDl+ql+g8/SD3HN2bGP2TNMtGCXYnLc6nyowzT4rh8is5lVD6l27ez
MjSCSW/n2TWm98Cz/p0kaqhTXagSPSBLUs00JYrlSS4sVfcR60R9scHIHlvWTyo/TPI03m1n
/ErvCEtgWGf3zpDdPyksxWUHT8rBXSRK8AfLpMQB22kVYZYpIraEBKJiS0ga2xUKIcFzpEc8
I2QFzyblBcMMZEaQE2KD5oXoCPJCfAiE7jAgT4oRhidEiYAlxAkDr5InpIyLEpZZLU5IaSBS
gm41mpefrsM+NhotBVozgAHhLSqHPdLY7Xet+qTdq67iH3GAye/OGUtcP/P7jGEcaWPPd2EO
MvDtHb9/iOev/2H3e9t3VF+7Z7nmL96RdsQx+kHiit8HvOpTdu8tPJ54PgpKxNgpH5v9brPN
xoaDP3YaV0qn9muvH/RbGQz7ZBqUKzGUVjcFpXzOcJ70DyflY5FGvFb/2cG6YfK2XGWsldGT
6hKXlcy6Lo9UMm4qNWQV1TSmFtYVWKpY1lYUzlTTtLVEsaZ6CZieBoSGuHiGLZ+WkKpMw/MV
HZvYx3HYFPuKasGOAy8hW/gpDnBsR3Hm3n0c+vccu88UBKk55nUIAOEjcgl0eqV5MrHG88kE
u4zHMjRoKbTBXyoK6xCgSEXect+9RMcFFLTeg8iGjGFrpD1wHgIQL6aDQ0ZJgMJWkImwehaA
+tqBQkUbKlSuHzNVKlF9iKs+FCg6nqSM0uxiAn/BXibFSZuZgvPYzYCXR6VtBQlU2paQorZ0
NjbVkiimJVFUS6K4lkSrtSSKaUm0pCXRkpZEy1oSxbQkWqklUYqWROlaEr2gJVFUS6IXtSSK
aEkktGRA1mgDj2TJUYNtXbufOpfQVMSBScWDXtK1rJjM2Liu5QCT350zlrh+5vcZwYjpWkR1
LL/fcbR/2F3oWBTqWI7RDxJX/D7gVZI5HehYxHRsvORKz1xgI4aZVLviESXV7QWZ1dnKGuVQ
1iiirFFEWaOYskYFlTXgy4HDXguTykS3o1knnsUL4qijEPwIj8Kiyanl+2MzwBvPmY6e4Rmc
XEWpdfxoaBgUto/diarhCEWiLEp3DwLbA19NFEZnAt8NxOoYTx2YSqSNpI9BB4lOesH4EOXC
+mDApPlB2IrBCrGS9ggrWjJIBHBZMcc4OwHnqInCIAkbJSQUT0hgCruFwWKGi4AI9hHThTFm
D3qpcM6JE4YMo2EzQqAkrZrlMtEAAYu2gk0ThhEzcgQkOZhsCjKUa3Z6wAwLHcuyHHOi8nzU
MArzpG2M4YqJzHGF3RSFMGrRh5eohVklYGQUVneC8F1eJmzTQzrB3JZgVkgle+5XhQ+QCrbQ
3qAIrWsQQM3qh8r52fsPINXhcnxKLudwOfkRLqdlciGlZ6fkAgUIVSQiqYnbELy86tz0KbOZ
qt0bFq4aIES35rYBeu7PWLIg28bYVeGUvKNa6jRiMJ7H7MVN3S7reGHT+rFqi8T8Xzuuhwm8
XdYEQnKX7PUd8w/F97YriSuCrT/sFJWyuy6ASNsZ70Ct7awCKk+3zZ3qxB09Wsp7F2NOGe9y
PMh168MhDIQdjXeqxbL1xSRq2cWjFdx383y9HYoyb9dyTFh5u+G8g+dJTcFdjTfhvbtGBzbt
brhHZzf6KXV3GBaI7SEFppvTqZZztpOAFRFTOs/JXGjKojVN2U0dnuub+5T69o7eY1Y/hcQs
fwYBjCofHUhSWPYALR0L5w8+LIJMNvDFCJyiBGw/npOGbbVzIrM9dk5ktvXMicy2zTmR07fE
BR4atGsD6ujGtxhVREYUGMWoEAmljlR3MRMjJlu+uXlReQFaTgIUiP7KT4cXdB/cBlFF6gWR
uYtIbySRMCYeAtntEVA5CGpqt7PDmzJjTKGlsbAsOha8UzuN9k7rWXZ/MsO1EtHerkbbdWRK
H8rn4Fkf3A2Um36v3hwMwN1b64Mbf9isDz/1mxfv3r2DpwxXieOxAC4C5w/de/ZIMS3/bTBs
dpR6r3MDDb1sNxXoQbNz2f5N6dY6lFmoEuRbpkzlwbPn4xkZbJitYxPzutpZzNr5ubGmh/Sh
OxwKaXnJhaBBO/88B6X1JgKoigVO8SOa8OBGQBInNimnNatPaoD3IZhvnWA+OZyPxHDc4rIG
gfEml3XeNwMO63u/13f0Ob7OhU6XbzjdtOTpAZ/4NN3Hnj13NZwMPjmRK/LJeflMLm9+jhDu
MAtuLkFQxI9Wcm01oarUU5NW4OlWTWpy7fDgpNRpgsyrgvl13bwgFykKHTbvhheyjxc+Aw+a
dbLYq61ua/heZ7DezbDab16JTKtOMxttZAl1t95vdprdYa1d7fYYzAUvi+phlun2Gs2r2qf2
sN26ZJDbO3bX8Xg+jSTJWXxVe3w/MRZz572jq77KSh/ZqFZPZF6p7SVAk7lFzx8cVYd3QKs/
UmgQoc8yjj4mL33CwHp8nIa1+sdqefGhDP/elxcVuPH20JdHOI/52KMivWqpPoDfn8gB2hh6
WaV0AQRmg/tcvVqwt0+aJPfzGS0qPlOBKsdGX+xnihG4OG8NS66EnFSsqDABcSkUJ3LWIWKu
hQJ0zL1QgIC5GAoQsO18AQLmaihAkO5uKPhgoY0bcoi6HYpTRlwPBUc36n4IKdOVH1HqI6Bn
tJf0LKD3CJ017aePxO+Qm9bybe/BtcxCRPdqMfynmQH5XCTccqd0xHwf3eqTtu6uTRsRdrl4
iHGBY2MiogtRPekzeNGvEEnfNx9xvv4FJLIMfyKrzhfKQ3R8o0YfeVkvGRAC+5yNDaVNvdT0
PZf8xih/4eWVhBhHe7NvscbRtr2doONDGPEhjHj3YcTRtVMsnni/IoOhHzyKNsiA4sjnqt/q
5y3Wc9VnHj0EDd2+q/5N+/RyfKzh4NN7BT49eI4Hn942fXrEVM0/xsJUXfYGFlAkDCfpFixk
M4f+QbS+f3BT2zjNP4jS/YMoxT+Iov5BJPyDWwh0SfgHUdQ/iJb9gyI2RvgH0Yv+QbTsH0RJ
/yBK9Q+iqH8QLfsH0Ur/IIr4B1HCCYhWewxR4B+89mL+QVq0wdwl5MUpXbwuJQ/byLWPTvGb
5KYN/CaFiO7VYvjMb1KIZNlvgcAbkO13KlRF8Bgo0T5+QyP8JEZ+kS0+e/HCRy6S+/HKy/vx
Ssp+nIILqezsD03k+q5FLqRc37XIhXT4+MWGH79glmayJLkfr6Ttx//bT2hs8dMZRvLTGfGS
Kz3/2hm9hs9qhPtxkg8yeUPn4CNscMqx94FzrJlbj69hbN/sjpx1L21ixzEO2/JXsC1nj+p1
bsrXiKiLzk5tTw+cWPvexnET68s+Hjaxlr2do6bD920OB1P7eDDF1lmxY6m38Jkb0Xd+prUE
SwnLLLCDyO2IBSbZjthDoOYXGagZdcRmhm4GjtjMQM3MaSfmLiUvTunidSm/1AC2lQFkRRyx
+aoIHgMlynN+b+H9PraH9mUemmVuiRlCtrxmeIdjs2LS+nBsln5sdrXIdWxWZPYSFgWphTto
I/Iv9RBtRfDx2rSRKZGLx1YO8bYZ7QQC+U36Vl/+6ZaDN3Udb+pRQ7m+ad98VmBYBif/pXPV
wq891IlOuuwjH/IjTZptTYzp/p73iDbuYeSWhV8K2HolsQwW3rsQBgsfIhcOkQvbjFyIa5Mv
I5jBwq86hoEoMS1MKv4imnNjOdvQo1kme3gARMApPLJLKJZXfl4nOrJXh3WiWf/3Sd3hxGyb
J2ZKB1q/9QOzxs2gdiOKKxseo/1PB2dizhc7Nduj8y/RBX74FQVQeSrEcYpzNd9AiGJCGfer
5hXQB6fqG3GqWguNul9YbobdKa7KLqmGDV5O1ysKnau+p8KsxrwLzxb8Ur5GXLDLrleYXJ5t
Rn2vBIuzjLtjZ6ph1ftD+NVe1587tCTfLBXFhbygqv4Ii/MYFXLzsY9E5CMCnciIZt4jpPOQ
vHAUFRplOeJMvfu5D7t2C8yK/fU6RBoZ2o3Jooy9vzBOX8dPmUV6tleWZKRdB1PyYEp+GaZk
ZNK/Wlsy0gduTMYgXEaKHXuqRZlzPCLlSZsyt/A+GJUHo3IPjEqvwGR/s2ZlPioPw9ipTrFX
Th37yXVce0KJMi3WJ9XwLdvBlg5Aw/JABpj4EUN799eAXd3m9N+GC63cTPpX7i0t1rH/zeYt
1sxswzWXdZsL6WACH0zg/8YELrYGXoVFvLpL3EBejZD63kH2YR8rSoav5gljOLxlcHjLYPtv
GeSYqYQqN4GLCxJAUSECOOsoTuOuQQOewuJEzMY4vB+x1gd2Qcx6671Qke+juEviej3Ftho9
6elY14A/OD4Ojo89cHwUnLWr0d+OW0SbTGdTN6znX1BLAwQUAAAACABScFRCaP3lBE4SAAA2
2AAAFwAAAGJ1aWxkZnJlX3duZXRfYW1kNjQubG9n7R1rc+I28Htn+h88/dLXxQEnzfXopFMC
JKUHJANc79rS8Ti2IG6MTW2TkP76rh5GNuYhGUhJqpucba129bK0L63wxYdmq17RGjNr7Pqu
P9LsyuBuZGiOGyI7DsInLQ4R0oZBqA1dD0VaHGh2MJ7As/75Z4Flh5rrP1ie61gx0sIgiCvW
2Dk7HYZIO7amcWB7yPL/nqIp+vyz8o8XU9dzcDUj5KMQSBxaLBTCah7MkD+xXe2b9D9M+qU/
tu6RjmZQsB94wSjQSOPbvavzXhxMdO3IpRDzptrrneNLSetct5qd9+dljSSvO63f4Lldfd+o
N7tmt9Gq9pu/Nsz+tXlR7WHY+Ze4rqTginYTBjaKImhytn2ff2YIdubh1jEjO3InQRgv9sp4
xl4Zq3uVb2gW3ez0zX61e9Xom782ur3mdUfrNfpa/1r72CudwIBJ4Bo/wvyZPGm0Qt31Zyua
MAhu/4JZZD76KDbJnBrQ65xySEork0HHhbpW7OoEFsXWeAII2tGweOnakaVV2/WzU+3I0b7R
jh60kl4u6yXdwHX0aBWjLcr/41cURm7g/6lFsNbgQXt04zutHroPKIS885JxbJTgr3zyhldd
ZgNI52F6AClkZc1zgqHk5AU28DImL2soHqP8tChnpoX0mC3OhnutrL9LTwrZJZNMIPmWFJs3
mxceDJ/g1BVn5VDGQbNyaF8RLiI+VMW4iET5xWaDDMtOOA4drvTMIZDVrZwTDCWXpFih64aW
ry/5YouOaI3oRbjKrzpB78m3v07q9txbb+hE+tkgCu0BnoIeMkHFMkGvMh9d3wkeI/MehT7y
Cq6WJOeYDCMu0rkfvD0rQfvOTr7/Ti8Nbl1/gAvC70B30HBxgZXZAtt2UUn0Fa+A/KBlGeJu
pI545zZKGmgTHgL53lY0ushuqv2fNTfSdP0Y/uC1HMstRzkxo9Uqg4+uX6+/z06HC9dnMx8r
8eRie9pP8t1auaJsTw+jCeGkYw8W6bGtHddmfKY2KRo86Pi/PgC7Yhz4A9e3vamDlsEGk+mt
59oki7cRcjFISI4C3vIBwYUMrIm7JQIsuy0RHp3h4H4MF9Av1mPaoJNpx79Di+rmx2bn7BQ/
EIZowhPljBo81a479WYf5ob5c7VTh2VwdV4GMEydDzfwRB+bnV7/vATPUNKJcV4u4WeYXuVP
JiRYRqdPKE2CY1JAaVb6rmTQfJiDLM2xmg0MOiudaKQxFNhqVDsmNMZswwMps35xBdXjh8av
LVqLSed5tfZzs9MwzXM6DoBzGQi968Hd0wSFtuV5OmBoizArGpPJWY0iNL7FLKiyAqfgIqKt
27g+yj+2XTsMomAYa191v9Zqx7Vvv9WuJ7E7dv/BvIeySBRqTC5pZai7pJ+U3hrvdKP0lljn
s7NTKoMmT6E7uoOial9rvOAaUSgsLM10Tat6nkawIi1EEQofkKMTpubhwf1id0zg+AtcLBRa
o/d2n94/mPRpzgVYQk/u/OEY/mC2HzPA7tqGC9y42neEBKt+R0g2tW/max4n+LpnKZLAzytW
P85KOECS4kyApDkjSNKcGXCETp+SL2cKJIczBg7LMwcMXsUdcB5jDDSxmjkkXak3Lj5czftV
rzcT8chaUZr3wqa33+3Ko31nhWZ8xAAeu0++pw9XT+R+ZN9GcQjzjUI/fmL302y68XN0ZB8x
ym7ycMnuPVb2W3q/nkUso5Vk8PEw3ze6nUaL9peB37frl2a7+st1N+mX2et38astlTMozc4S
lNI7ihMDm3NcjzXu0TmF98CfDdaGyw2Tf/BohdhzqN8RfH1g4QGyiOJsgmNw5CPHhPWHdHtF
5hg4bWDnsm0rysGcZUBoSIjGyI9JDq7Kc6PYdJCHYpSFjTAL8MHAQgvIPnrMAibBxJxMo7ss
FByZ4RMBEZcmq4MDcDk8lUMnV5LGM+h2OhyikJaxCE1aCm2IF7LmdXBQqqJose9RruMcCkLv
nifnBYNRZt+zMjggm00GB48SB81bgSfC6lkAAnV3Es/YSuIZicQTkthYmBlMmBlcdLEEKW6Z
0orha5RZnJ1XaAlYVKkFXBEhtRMkEFI7Qkorupuxidwz0nLPSMk9liIJeF4t94yM3DMW5J6x
IPeMRblnZOSesVLuGUvknrFc7hlr5J6RlnvGWrlncLmXoNZbQJfPOapT47jzoX0BzTMYMC9q
jHXSk2bjaZqVngzgwT2RngaTnkZGehpEarL7J7jPpSaj6CYPl+zeY2XiWUqlJstoZTMuHaFV
wxZuXpjyoc8L0XM8VTeLYENABBsZEWykRLCREsGGpAgGfD1xFtvzR3PoBOnkJJtEM+xtJBD0
ENt3Pnkc+XF86yV4t1MqecdoDNuCaWoHPbg2AjEco3Bo2ShFkctL090BP47A45NpmAXVM8U9
U8ftaALzBrcR9zHpIJY0a1QKns91CgrMKxW4WD5Yc6y8lkGzFtSMDP0koV+md/CcROZSSE7z
mBfJ3xDH5NoIhWXUEQ7BxdNy2HvlWXlqcqWAnHpCC6EzgqPkdZXFPN6/RW2FlkinCcVIqy4M
sjh4lCiZghmnq05txrRiM0/zYVgxZRku13vSEN6HRc2H92Bdien+5qa+pI8Od0w7Bk1BOw6m
cYX7ECniXIcgGM0r4D2Nymn53fdvToFpw+XkLb68g8vZd3B5W8IXnPv9W3yBDMMovzktlwgM
LkZ5fjn5TsOsGnvwwH9sTb2Y1DK27DvXR3TfH9oW26Od+hGhjOWOkpZ7G1oQodC2fGuUUhbf
ZXTFHXhFdteXVVoxcVA9Q12UL+67NuCn+67CeYY65hx/HxVl5cdeJsAS6bPfrgCf3Gv5iWTc
ayWEWe+jBiJe9/i6Sfn7egek8H2PDb7uZWi47rHH8V+qEO1lwfGa9vW6eQ37e+fRntlf9By8
j6ub+yt9T++Y6Kb7HH9c/n4bn2ji+6shPfuNH5caqTgjZ6VK7houqPVi/guajVV90S3HuSpt
FFSlt3W37sEkIcV+/ETuGcuEQLLWCQERC4U+AXKFjSI8EpjYQGZ2luUi+GQJsDdCnmhShIg6
GSToqFNBgoA4ECQHDaxrCQLqG5AgWOERkCsB2rhlCWmvgDxliiNJjm6abRFKyrlCZMV4J8aj
jEGqPMKRQOZqgAYBdHK0aEYs/RYwRFw/MOx9HAwwNBwNxmJIO9cYVEpiw1qtzVFiG+NKoaWZ
6DYyHqxTez0csKxnm/uzMeot3dC9hquFNunvkaedlt7BtkTvU8+86V7XGr0e+NGrXdj36Ddq
/Q/dxvkXX3xBNnzgrlFMVjjOYdMpeopwNsn/rddvtM3adfsGhuCi1TBhbBrti9ZvZqfaJsXN
xZn+kSoJeu8pitEYv0ZYD7ceYnW1NhXWEi+NNn1On4wMbg/JPw4hqjOQW0UgdF9BVJhYNBjb
25rveHFIbqtryTbXmi0uTVNxiUXjEvX5TLTzjlu2HMhzF0XBNLRRfs//TC/rZ+9K3+ul7V24
0qq4tBYOjGbBFS6slPv3y/3bzcT/aHlEdOzRxX3cbgDjrIAYuWqc44uWhvYbn/rneoxmMQX3
GjXMOCrNTrP/xqGw65t+pdu45IlmjST2o/LjYju1bqPd6PSrrUrnmsJCMGatCNFE57reuKx+
aPVbzQsK+fiJ3h10Ox2lHvEubMV+eDN0Z9PJmwkcZbRo7gMd7gpMRQoIokXQ8mh7zAQG+E0n
9kIQExVtbqgeD6c+8TJPLGfsQnEUOnFu8elKeDcRG+p+tfa+UpqdluDfm9KsDDfWcnIcgT5H
09uIiJaKb8UAfgNNMGjWLYxHBdPNCWFChU+Vyxk9z9DAKZJRbM4DpaDNxBU8eaIQydSUsc4k
6Gh2ISJspRUjnBQlpNaaJC212CSJiNVWYDDBKpIkotabJNEKC06+FGjvDkpJW3LFqFPWXIFR
X7ToJNjUBXH5Xj9A173g8T025CSo/TiI7kPfkyS7s2QpHscuQOZEc9meI5orLZQQqy6Dj86w
5YTFiVNsU7LZfgx7i5E1RJJ0j84YDqJJEnVjD5opSaTr+O/Ru2Npazoz79NDnVZvyYkyYk8k
MMnaInQ3nThzohT3rWjtXrOl6YA7DpwpHBoENwB9Sn59wCGH8nDwF/gIpr7zA1ZoYitkXgv/
nuW3+rWrHzTLcegj/v2C+A5RDKzEg12OEwhnuCB5gweaCaIVhAi4HwDDxjGcOzVNwZx+laap
zBF4ZaMeoo0q8ga3tEU3Imy0RTciEBN0PtFsZVsp20rZVsq2EiZUtpWyrZRtVcQ8UrbVIdpW
V/Q3esieXkCOpG3tkt82FETCJY/P1MtpqOxw/WEfNRTpyH975lCkhZuP7gmdKxRCEjpXKISk
jhOq44QFjhOKLIjBCzkhCH1hp+loomDQIrZsJAeI4i3ZMpVm8/O9U6O4fb8tX19m3xvL7Xtj
iX1vpO17g9v3+wyXzNn3Rtq+Nxbtex5hye17Y619byza90bevjcEVZkF+95Yat8bi/a9sdK+
N1L2vZEz4o3VFr+R2PdXUUpRJRlbrgJcRDHqEG1DDdkSL2KJBSNBnVgwkmR3liwFtWAkiRbt
BwPU8ZX2INXMWbZkRcmrkSXj+jzn2Ie7V6KYsWLGihnLUStm/EKZcc65Uv7xEn5MP7oDxjvK
OV5W5gnHi+/097j3GS/Of49bqGPwy7TgGN5/gP8WYf28mbKB7eK4KtJAONJA8GeyVaTBwUYa
wBt8ZZEGL92zDm9EyLO+27M6UDXlq6+WWdHurRrWLJbiWAfLsegLern8qsAxHt7tgzjNczBb
elLHijCnlZlJCZ/lG4dyfPoANg6hhWrjUG0cqo1DwQXxkjcOD/YjBkLMln+mYO1HCfLMsrye
WZaXMEsCllQrNn8WQOgrBEJIQl8hEEJKqxqbsdWHDWQ/bEAZaz4nz1jLyxjrs3weodBnEdzc
ZxGyGZeOzOIZrPpoAn0Dq37n+SV8aiHTf/bD+xnY7mI6YjFXm0BMB5SkYjrUNuKL3EaMxVcB
LqIYdYi2oVbbiM+/jQivZvttRBXToZixYsaKGStmfADMeCGmQ9LZy7VoKUMlvQ8moElTxM16
tDr7LMy61dlnxrrzB5w3noYWPPssMHMX1wEppkAJfDd16yLUWc9DPuspKUpEK+IyIe9ZOVQ9
XTF7xewVs9+uCMXsFbOXCureHN8M9Rx0YDO0b11sumwE89rhsEHK2IE/dEeHG8LO2ygb6L3L
qEh4K68yHhL6tYoVs2wVASkeAXlUN69uWje/mjAcve+eMyDSR68hchtafhCBjVIuJhxPKPQi
WCCh5D4wLj7HCgWq2FkU0LabBiwKSLgP/2G85ObGbQ5LFIqCFEJSAY5bBTiabWjxzuMb6ze9
6g3PLheLetx3nOPmifwiQhx5N1iYIwcceqgjDPdhxjhCY15XcKMKV/wvwhWzqu7riGCE5SAf
unhYQYhYg7bnj2Y8S6fCTCpwnXSSMhUWukhgRT+eiR2P4nKIo2BjfWGjVUb1VdGK8o731xog
M0bhCFX0EDeBjviGwJnvmUPemIfGxJEF6wux7j351ti1sWN+MXAGZmUUeOnIGYyV+PhL6WCa
seX6tW6/hzedphOSIz69OYpkLIvlPACzODEkwzDoD/NKk42jBxDIJmDCUJ4kTV3npwb0FK10
uMjcLS1JtxBmwof3cPcTU0xdcTnF5RSXU1zOkeNyVzv8EaTobhqDV9YHrfFwd49SjSQclCvC
crtJUmowdtnm69/os8XN45r5AftwBTr1HzpxBVq32fcq5KAVQlJeXOXFLejFFZjJL8KNm+oH
8+NmICnOR1f99n4HkZFL4SzxPEhxcOV6UEr5S1XKReZ3Ckep5btRy+EtWBPZEzWT4DEEB8FQ
kmzBCEi9zUP1dSg+qvio4qOKjzobOdt/yEd3fzJRIBozfxhRNPqMKalrfD7q0IoM41WHVrY9
tJI5XE4yiq0HTClFFKICRJAtTQR7NcXowoJ04DosRkgt7//FgRsxoqLfsfQdNxI6IZP+lOmz
fHqSvulDVfmV5FGSR0keJXnEppSSPC9J8lxJbi0/Wm7sBxPkOwB0/QhkgIceEAzM4e40r27z
8+w0r65/48bzwW40y/fpP9x3lm/s5s1joR1mISS1Da22oQtuQ8tP7BexK726W2yTeh3Cul8h
kOTh3BFYfLxXkyzZ2t5GZKidbnlzTe3QHMYOTYHpvppE7d+kK7SHo/EolG4nNxM2MNxDdVop
Lqi4oOKCwmOquKAAF5SK0f8XUEsDBBQAAAAIAEZwVEKIZa8J/RAAAIahAAAVAAAAYnVpbGRm
cmVfd25ldF94ODYubG9n7R1rc9pG8Htn+h80/dJXLMO5dRxm3CkG7NJg8ABp0paORkiHrVpI
qiRs3F/fvYd0EhKRTkCCXTouutvb3Xvf7u2ulIt33V67oXSW+txyLOdWMRqTu1ukmJaPjdD1
n5TQx1iZub4ys2wcKKGrGO7cg7T65Rf1ny4Wlm0SulvsYF8PscnxLIezmiyx4xmW8l3yP0L6
tTPX77GKl1g5dlzbvXUV2prr0dX5KHQ9VTmyGES7aY5G5+SnpvQHvW7/7XldodlBv/c7pK+b
bzvt7lAbdnrNcfe3jjYeaBfNEYGdf03qihg3lBvfNXAQ8K6K9n35BSrZmYepqQVGYHmuH672
Cn3CXqH1vco2ND0IWn+sjZvDq85Y+60zHHUHfWXUGSvjgfJ+VDsB1hK49Z9gQXhPChtG1XKW
6YGduNO/Zz7WHh0casuz04l1Aj8x9gxq4xxYk2MO2U7ks4rJZrQxdTpnhKOlh5ZKYUGozz1A
UI5mco1TjnQFwMqRqXynHN0rdfWNcvSg1NR6Xa2piDAfMd63koz//A37geU6fykBbDRIKI9W
eKe0fesB+1B2XkPHqAZ/9ZNXojq02j+JTUhHErY0Gcm93o3JhkKXU9NXcWUk5zE9gSiewKqs
q85kuVlz8H4fMg7+NGdLdDJkl0mZSUodMoCTZEUh6zlAvsLZItO45OIscbpIsa66OFe7uroP
5QZPcvuV4VitY/WfWlR5IfV903dHT47xbVSxbU3tmRmop5PANyZkmdtYAz1IA+VHe7Qc030M
tHvsO9iueHxGJcd0+AhL837y+rQG7Ts9OftRrU2mljMhjMjYqyaerW7iOt/ExRs3/5St0Fcy
R9lBS0u77ZxQ5TtXeCpBm8gQyPe2obDz6KY5/kWxAkVVj+EPpuV4t6ecrfws39j8TWLYqh94
dMPObeU40Gc4wHfKsQF/7mymHLeWYiV2KQk8VfK/OgHdfu46E8sx7IWJ82ATbzG1LYMWicZC
KQEV60CA1GpM3ltOu/02tfYJh4nuWRsiwJbaEOHRnE3u5/ADyt7HMQ1QpI7/mCvwA61qax/O
TrXzOqRIRyEBqdG4rbWavR4kW4N+uzuG2dd+afbbsNCvKC4sjnc3kGLJbn80Pq9B+n23f4LO
6zWShgVU/6BBhhf0x5RSozgaA9SWtR9riJXDKuN5gdXtENBp7USB/zh7rddp9jVojHYNCcqz
fXEF1ZNE57ceq0VjK7nZ+qXb72jaORsNKLm8GVDcS7d42ieh52t4vrBBz1EBQckA9WBO12wz
CPB8Sg6bxhqk+k/XluG7gTsLlW+G3yon6GhqhUrruPX998rAC6259S85DtiphX2Fiwql/qMK
M3hSe43eqKj2mt5qz2rQRCYYvCffur0Dnq1vFVFDi0panYgYVVGatq1QrEDxYVv5D9gkspHt
4BLDwDYnPZtsMnJfbWnXH39FeALHFntej9nzncZSfKfzpBo9ReIY/mBNH3PAlppFuBVu6C0h
wcbeEpLB7stiS/Mc6RHPiJ3Ns9ndzTCjHR7lxCanebHRaT7e7BFAbHiSy9/0tERsfAHLbn4C
Xrf7SRnf+CyzfvOT0ugAiLrV7ly8u4r72G53I2HHW1SLe2Swxx9G49G4030tPOIAmz+9M5a4
euLPOcM4MqZB6MMiZOD3H/jzh3T+6l/2vHNDTw+NO5br/BIcGUccYxglLvlzxKt+zZ6DZcAT
T0dRiRg77W1n2O/02Nhw8Nvr9qV23fx1MIz6rY3GQ7IMavUUSrefg1J7w3AezR9glkQa8VrD
Jw+bls3bclmwVyaPuk+MeSrrujrRybjpVE3WdNu6dbCpwV7FqrGmcK7btmtkig09yMDMPCA0
xMdz7IS0hFRlW0GomdjGIU7DbuG40B240uAVZAc/pgGe62neIrhLQ/9ZYP+JgiC1wLwOASB8
RC6DTn9pniys6WI2wz7jsQqNWgptCFeK4joEKFFRsNr3INNxAQXBdy+yMWO4ehn3nIcApIvp
4JBREqC4FWQhrF8FIMF2IFPRhjKVS8hiqUqEH+LCD0Wijicppzw9lsA/ot+S4qyOS8Gl9FxA
LCPUtoIEQm1LSEndtxibykmUkpMoKSdRWk6i9XISpeQkWpGTaEVOolU5iVJyEq2VkyhHTqJ8
OYk+IidRUk6ij8pJlJCTSMjJiKzdAx7ZkqM2uxr3311fQFMRB2ZFD/qYtGXFZMmmpS0H2Pzp
nbHE1RN/zglGStoiKmX58wNH+5c9hZRFsZTlGMMoccmfI14lWdORlEVMyqZLLs3iHTZhqFnJ
K+YoK3HPybIulteohLxGCXmNEvIapeQ1kpTXgK9GfgIjTmoz001mvXQWL4kxkELwA8yFQ5O3
ThhO7QhvumBieo7n4NZLUpv4wTIwyOwQ+zPdwAmKTFmS7g7O7ACMQUkYXQr8RpCqY3rrwVoi
bSR9jDpIxNJ6/YOVZxQQxkAMi0ASGkkMzaokKQZexGBFRxHAVVktSiIBHTEUU8GRMpqLAAvV
hVGzaWPlKT1GQGhVIpukZjO9UrjgxBm9htGwCRYoWSVntUw0QMCSrWAri2GkdB4ByQ7kFXN+
MN3CxKpKBfbalZky4QIyyScVpzjPGis6uoZXSq8SENHVtGbFOK6uf4EohiPbM37ZJu1kdlFQ
LJRjdxE2hJGRHmyxxkERuldwAHUaP9TfnL36AY51+Dl5TX7ewM/pj/DzukZ+SOnZa/IDBQjV
FXJUE0MfmJH1hR1SZnPduLMc3LDgEN2exREYRCbH3GMga7LpWVNfh+CCa93RbxPa5JuUMrmp
WaaKATi3h+suUMyUteuK2GG406rgxNwpf3PXFcSn+9ZrSQuG7c94jozZYSfgXNsd80jM7a4G
erxunT0VlruaX8p8J+NOOe90SMjv9kdEaA+7GvNcfWb7u0pUs5P5Fex3NMnBLs+1YOeHmtD7
dsR6F5NK1cSdjTlhvsNmR2rwjtgnVzn6KXNzBGD+dSFXqS5hQGBlRM0u5bsTam5FbXZTg2j1
uwClfv+BPlNXAgpJXQsYBDAafHggSWElRmjFySsREimFTa79khSeNAW7yJclYvf3stjsvl4W
m11gy2KzW3hZ7PyLtszsQdM2IU9epCXJEpdMmbFMHirxYaO0fMyOFZtt5vLM6PkBMk4BHAhF
kyCEJUYO0R4cXqRmOCx3ETOPFBJUxcM9+wMCqkUhVr1ecbBVYbwutDQVJEYHg3dqp3HzeT0r
7k9h8FiyobKRXOVxYc35Bu3vka38UHsD9v3Rh5F2Mxy0OqMR2JybQ3AmjDut8bth5/yrr76C
1QO/CsPjrAmcR3sGTwEppuW/j8ada601uL6BAbjodTQYmc71Re93rd+8psxi0aO+Z+JZHT0F
IZ6TSYR9MLUxr6tXxKxXnhtrekwfjQtpDy0/9iE00q0Shw1i8kUEYMkFXnGXUexIEpCMBynH
e7TecwS8txwNWDiRhV7QDREKo/4KEUiwnxqvN2LT3OIGhiP0RW7gAgl42Ld7vm//L1G8arwg
c2Jh+Jag6SEO3IVv4GwgzKlaV0/f1M7U2qYXvfrG9W/mNuHRrBKntwhrFVdx2Vs4HH9p/1S5
OzlUBjXvYwDT6jR2IxeFblPteIdur+PrDgiXBmjKV51z8qMkoePOh/G5GuJlyMCjToucro1u
vzt+ZTLY4GbcGHYuRabbopmNbBCEut8adq47/XGz1+gPGMwHY5geYJbpD9qdy+a73rjXvWCQ
9x/Y08TTxW0iSWIsGsbDq5m1XHivPFMPdVb6wEa1carySt0gA5otHOo48nQTXnxu/Eih0bsS
LOOZU/KmMwxswMdp3Gy9bdSWP9Tgv1e1ZR0evD30rSPOYzENqOxsOHoI4FewvhArmkIvG4Qu
JoTV4D81LpfstaUOyf18Rosq7B4gK2OkEZdPSQofl65jxRBUloyVyVMQg1AFKq8SFTMMyRAy
45AMBTMQyVAwS4wMBTMUyVDkG4tkZxiauSmLpNGoAmnCcCQ7xknjUUya/zIfUasmhAEjvqCe
nMEDdNh2H98Sq1F5Yid0g3vfseWo7nRJgse5BYCYJlaaMjSxekXpiI41eW/OeqZfmTZxAsq1
2QkhCoAc3HJkj+YcXhyVoxmGNrRRjkZVyd+jfcey+mKp3SfHOKl+k9c/UxFAclWB5Fp4JqMR
4dMSatznjKMubFxxOHKpWOlSSKVipUshHUKkDyHSuw+RLtw8k2cS9Qwd4RHCUQZOv3Keha1+
2aSaZ6HQUxI1tMoXeVYu1jKTz5CyN2y5O764ale/2G52o0a5F1uUf7FFORdblLzYInGx3YJz
PXOxRcmLLVq92Ap/vLjYoo9ebNHqxRZlL7Yo92KLkhdbtHqxRWsvtihxsUWZ2ytaf9VF0cX2
KkhdbGnRJquX0Fcg9XFlUu4fLqeA5aj45YkjFV+O6k6XJGAqvhzNqoqNQGstcVGSqySaDkkq
ofNu1yPzol2qZb4edHDN7LdrpnAiC+9BGyIUumAKEVZcqp/f88G/xCMxyNzzsY8fJYk/MSLR
HfEZkY98NCRrAah/3AJQz7EAULDcgi7+cEep74SUQir1nZBSSIePiWz4MRF2EGdLshaAep4F
4NN+kmSLnyKxsp8iKRtmB5+PA8P63gfZsWamu3tpSpwIk+fw8ZXYrEHyUUYurnDLsYJs3F+s
esu6l7tg0igHHfcZ6Lhsqp6phlshCkn0eS+CkXgwUOk5AYV4XwNyYpdY6c58bocYa9oLcocd
vi90cJ7to/OMbTRJ19lL+MyQ6Dz3u63AckI6ZfTz0p4n4FLC83QIqfxfhlQmPU+FQZaR56kw
pLJ43YnVS+krkPq4MulLDy4rRZMJ7pLyPJWsJJoOSSrheSoTo+Dg/Q5NgPYVRhkUX6wZRvF5
z/AOcQaSp/0hziA/zuByWSrOQGr9Eh6y5MKutBn9S486kA0OhsDiyrSJlSHX5k8T9SCkiFxA
2DZjHaA1L9IYXPDvCB3Mv1XMv0dt7eqmd/ObBsMy+vFTWoMd/OwDHeiqMwrdeORfKjNcZ2bd
7q8PT7Tx88dtyPjSeIxH8bJ6XqEdDt6/iA4HHwI5DoEcWw3kSEuflxXbkQ6DKN5GzyX6gQg9
I05q4TKZ81M51zKTWXb68NCJiFPsk8wIoufukBQ92S9vpGjXZ3dFHlyC23QJatfQ+q17BNs3
o+aNKK5v6Cf8TJ5Bsegl3YJ75OATfeDevSSAnqniSM6x/pYcCVFOSNOG39Kn9MHq+0Ksvs7S
oGYblptj/xY3VJ9UwwavpG0YxdbfMNBhXWPehSdHn1sGsRGv2oZhdQWunTQOE6yIZS1pL57r
ltMajuGfnvbDhUdLSi5TUS5npNXNB9igJ0jOOsg+USFLNQ8eQExqgAiDeELaWWQ4BXRBKvsK
VmwnlSNbsXwKdbDYPBLcLUKwLzigzuyvfSTRSFkDhVCGE9pulu1zV3cTXdkvfTfRsIPCe1B4
/ycKb2LVP1+NN9EJrvKmIInTlR0PuXpv2QFJIGQ13/In9kH1Pai+e6D6Fq7TBMJB+d1U+YXB
1z3JYAHPffQ9353JUa0o2tl/QaVQ337UrdBxPeyYALScAM4jGz9g6Pv+qt/r2yynjXPtu5Dr
c1fGJXv22XRzyXYWK9iltPBSSAdV/aCqfxpVXXITPAvNfX2fuCK/HiH3NZUS/lNWlo1WLhUd
cngp5fBSyvZfSimzVglZeQofy1JAmRwF+I8qEPlViMAmWoGKqRuHV2o2+F4ynLpBxZdwdveJ
45Ujv6J0XI+ftepUvgkcjDwHI88eGHlkl+16/IMJiNMYs9v5rS/byNRJ9h9QSwMEFAAAAAgA
OnBUQjFfwn/nEAAAP5IAABQAAABidWlsZGZyZV93eHBfeDg2LmxvZ+0daXPaRvR7Z/ofNP3S
KxawThybGXeKAbs0HB4gidvS0QhpwaqFpErCxv31fXtIKyGwtByJndBx0R7vvb3ftU/KxftW
u1FVmgt9ZjmWM1WM6uh2ihTT8rERuv6jEvoYKxPXVyaWjQMldBXDnXmQVr/9xtUNX7Gce922
TD3Eiu+6YXVxejLxsVLS56Fr2Fh3/p3jOf72m8ovF3PLNkkjU+xgHxBMRhRI8HZHC+x4hqX8
lPyPoH7vzPQ7rOIFEHZc2526Cu16Z3B1PghdT1WOLFaiXdcGg3PyU1a6vXar++68otBsr9v+
A9Kd2rtmo9XX+s12bdj60NSGPe2iNiBl59+TtiLCVeXadw0cBNDldP++/QYVHMz92NQCI7A8
1w+XR4U+4ajQ+lFlO5qeBK071Ia1/lVzqH1o9getXlcZNIfKsKd8bHVvroG2HDDsH+9RYU2q
lrNY04mRO/4H9pH2sPA02FIj6xh+YqwJpVShU04IWnpoqbQsCPWZBwDK0WQzysqRrkCxcmQq
PylH90pZrVTUsopgVnjf2SZI9p2VrCLMq6IuD1jvpht27a8P2A8s1/lbCeB4QkJ5sMJbpeFb
99iHuvMyKqEy/FWOX0X9Lr5ZHfy89yj0jyxCdtkrqWWXWpT0at8pFfVsadHjNZOju/FSbXSW
YGqS+5GVrOoir9rgCOUTXH9yxMaXI7jZJFZ+qVMRRZr7oesOHh3jx6hd2xrbEzNQT0aBb4zI
BrOxBtJOAxGnPViO6T4E2h32HWxvKIWimhKdPELSvBu9PSlD/06OT9+o5dHYckaEEJl51cST
5eNT4ccn/8isFlYbjJUsUXbS0jt+N7yh+OBy+QH0iUyB/GirCjtX17Xhb4oVKKpagj9YlpLk
CZSUk8rMVkqBPsEBvlVKBvy5k4lSqi/EpmnRIwBPlfyvjkDZmrnOyHIMe27iVWUjbz62LYNW
iUmAWlKUy7IApl4dfbScRuNdapcSAiPds7YEgM2/JcCDORndzeAHWPPTkAboWKU/Zwr8QK8a
2s3piXZegRQZKCQgNRg2tHqt3YZkvddttIawTNpvtW4DtuQVhYVVfH8NKZZsdQfD8zKkYQ2P
0XmlTNKw0pUbDTK8ojukmBqF0VhBeVF+U66wetgOPC+gWk1SdFI+VuA/Tl5rN2tdDTqjdSBB
aTYurqB5kmh+aLNWNLblavXfWt2mpp2z2YCay+sehb10c1d9FHq+hmdzG1QBFeqVTKEezKhc
XTPdF8DCCDFiAdAfw1Z+lT+IK/tm2KofePS81IIAz8aEJ1XXdBFt1EU2M0+0TsbesQzfDdxJ
qPzQ/1E5RkdjK1TqpfrPPys9L7Rm1n+EHTGuiX2FiyqlAo2X1ePyW3SmovJbajudloE+E0ze
o29Nb4Fm/UclbgGo+KD/6UTEqYpSs22FQgWKD7zCv8emSjmdTVb3u93Mc+k7QhII1tmzM2TP
9xpLcV7Ek2r0FIkS/MGxK/GC3fSKEMtlOTsCAtazIyCDGU2C6fAcGRHPCN7Ds1n+wyAjHhTl
BBuiecGKorxgRwKgO4zRs2yJ1QjWJMqy7IkUr+NPcPr2cEjQlockZpYks55hktqIaUYT3Whe
vL+KZ73RaEWSnM9RGUVzbLDHn0b1wbjVfS084gU2f3qnLHH1yJ8zBnFkjIPQhzlhxR9v+PN1
On/1H3veuqGnh8YtyzV/C46MIw7RjxKX/DngTb9lz94i4InHo6hGrKb2rtnvNttsbnjxu07j
UuvUfu/1o3Frg2GfbMxyJQXS6q4AKZ8xmAfzNewbkUa81fDRw6Zl875c5pze0YPuE4eUyoau
jnQybzo1AjTwN00dbGrAPLBqrKmc6bbtGplqQw8yZeaqQuiIj2fYCWkNacq2glAzsY1DnC6b
4lDTHTDj8RKwgx/SBZ7rad48uE2XgofMf6RF1FfG2xAFhI7IZcDpL82TjTWeTybYZzSWS6Oe
Qh/Cpaq4DVGUaChYHnuQGbgoBXl9J7IxYTArjTtOQxSkq+nkkFkSRXEvyEZYvwuAcUTyMVfI
E9GHuOhDkaDjSZU9s3o2KX9C/ybVWR2cFhfRwwGuiEjbCRCItB0BJXXzfGgqJVFKSqKklERp
KYnWS0mUkpJoSUqiJSmJlqUkSklJtFZKohVSEq2WkugpKZmUSehJmYQSMgkJmRShNdpAI1tz
1GBGdvd95wK6inhhls2jpyQbqyY7Ni3ZeIHNn94pS1w98ueMQKQkG6ISjT9vONh/7CkkGool
GofoR4lL/hzwJsmejiQaYhItXXNp5h6wEYPMCjmxRFnhdk52db5oRAVEI0qIRpQQjSglGpGk
aAR4NfI6GnFSm5huMuuls3hBfM20BN/DUjg0OXXCcGxHcOM5k4gzPINboCS2ie8tA4N4DLE/
0Q2cwMjUJfFuQVcLwKuULKM7gVsDqTbGUw+2EukjGWM0QCIBnhD1ol7IelaYFfaErJisGCor
/VnVkvhP4XsR/ip9QNREsjDCFUvBgTJKgigWWgIroxI/1Re+kKKWNiWyWWzyy5HZ0rPKjAoh
irM6BENni78MJzogypK9CDLzyfeaqM1O5BW7v2A2hYlVlYrrtTsz5QsGYJJP6ihxXnQ2raWI
4WWpC3CBnVZiGP7y/heAbDrWjUzK/0LGo5RA9VBK7jysCo8mZX6xTkIBWlfApJrV15Wz01ev
gffDz/Fb8nMGPydv4OdtmfyQ2tO35AcqEKoohJsTVyX4rPW5HVJiM924tRxctaA7O3MBAX7k
A1rJKbLumbY19nW4ru7ojj5NGJpnKTtzBy6Y3QxwjR7LnHF7bodxy322BBx2n+TNPdOPef+u
G0lLkZ0v9gr5s78hAMvbG+1IAO6tAcp3d02dCtQ9LS2lvY85p4T3OR/kd+fTITSKPc33SnVn
54dJtLKPpRXU97O+wR5ZWbBvPia0wP1Q3sN6UpVxX/NNaO+v05FCvB/qyd2NfsmYkKQwq11L
XR0uadf5zgZWRdTtIneOQt3dUKvd7s4E/bK5SUCxP97QZ8oyoCUp64CVAESVzw4kaVn+BC1d
VxePxJIBJo4AOQRPFoGZ+wVxmElfEJiZ8AWBmUVbEJhZ5QWBV1viEosG/doCO2lny2El7EuJ
WUwyGorFuIqPGaux2fEtTIvyCxB4CoBAvFtxPNhXhKu2gU2RdoF77iOgGikkcIsHc3Z7pKgc
hXG12/kBXUVDq2OPDZ0LPqi9BlWvGln+eHID1D5hULVv0BEf2crr8hn4/gc3A+2636s3BwNw
SNf6cNEwbNaH7/vN8++++w72D/wqDI7TJuU81Dh4DEg1rf9jMGx2tHqvcw1TcNFuajA3zc5F
+w+tW+tQYrGwUT8yia0OHoMQz8gywjkY25i31c4j1i5OjXU9xo8mhvSH1pd8CMB0NwizBrn4
RcSOycWM8duk+I5JlGQul1ZcLK2/VALaO45jTK7jywxoJGGKarzdiC9zh8cXWOgXeXyfFoCH
U/vMT+1XEn2sxvvRyBpz/EDQdB8H7tw3cDYy7kStqCdn5VO1vL1ZV9i+JaGxxVmsiJHdeoTb
XscUHiGx4CWNd2Cj6eutQqa8c0fm5jmGRsbxUcVXemWgVHbdW9GFiW5TdX2P92+lThOkXRVU
96vmOflRkqXD5s3wXA3xImTFg2ad8Ptqq9savjJZWe96WO03L0WmVaeZrZwgBLtb7zc7ze6w
1q52e6zMB2edHmCW6fYazcva+/aw3bpgJR9v2NPE4/k0kSTxIFXj/tXEWsy9Vx68W6uz2ns2
q1U4QgpfETYrbpCsokWTuUOvszzdhHd7q29oafT2Cct45pi8zAsTHPD5Gtbq76rlxesy/Peq
vKjAg/eLvnLF0vQiEaBOQRoG4XxcXf2eExEHI9hNIwLzpoJUaIt3Yj4OqFZQdfQQ6L4CaN7r
MUxXlTQctwzbyn+sXi7YS19Nkvv1lFbJH2fAKuBtEka1HIKPi7aw7M9aF1tYjJrwdRVsXvi7
5JG8TZCY30sCj/m+JBAS/q/cQM0i9JgrSqIDzE0mgbDGVSZHAfq4JYWMy2x1IGvxaVv2psVE
pcw4qeZSLjiC+TRDYrgX9Gqsdw+TZrsP74jvrTCuE7rBne/YUki3uhz8w8yCfIwSazoZlFhJ
pXhEUx19NCdt098YN8FrKY382F5QxYuOywkh1ILIIbnZMGfwDrAUSj+0YRRSKKpK/h7sW5bV
5wvtLrkIyVNB3uNNRVftfqpAUs89syDdQhHbhYAOgdqHQO39B2onRYBcxPbzir2GcfA45SgD
x7vQJQZ8AABk9v4vZ7a4khHdlL7A2Mo2z90cDCZrpEs5MoS1vrlFu61RvsqiRastWrTCokVJ
ixYJi3YH1/oZixYlLVq0bNGKSABh0aInLVqUsWizlixaacmipCWLli1ZtNaSRQlLFmWsTbSt
bYvW27YosmSvgpQlS6u22PwEXR7Tx5ticm2+kPqyQsUujBup2FJIt7ocPFOxpVCWtVcEOmG+
iSLVRLQMckhCVdztjRIsOhMAX+S9kpBv61ZPQBxumZ75LZNYqq/msim5O40iwTM7+8jbZgpn
bswM9O9FXSyRq7OiO5BfnElG9zz/L9HkDlx8a+apL8tknd85ftx1fkoJppD/bZdCn5IpBFTo
UzKFgJKMIh/6a/06zc6+BcPkXrYm686prHLnfNovyuzwSzJW9ksy6ZpLs+g5G637xgxbqXWv
37+EL9Okxs6/U7JUttsQTRCRX6Qu/vQHQQ/a9yba91FDu7puX3/QYFoGbz6lMu7glx6fCSN4
2YFc6w6UYb+gGCUHy4QmfZJvOEGXvpxvOB0u+57BZV+aTX8d938OftHXfkQ6GHFSCxfJnJ/K
uZaZzDLew+8MI0pSTgdxY1ZY/056cvNvzRjcU3dmhyjQZxIF+qmjP5N3ZvuPBy0c/Sm7/QkJ
SWxxDbAV+iFIbV9BasW6nIk/k7nBK9bEUtxWLCIKhIaQf9HDcJ2JNX2+cSGij9JBIbF8lJR4
xLDJtC71csoujJtt5RY3bgoN5LP5zEW3PrfD/OC43qXjWutA73fut25cD2rXorqypTf7M/mv
xZ6Xc14/Ize0GAL3QScLCOsVxkicF9aIJDsWBkixCRTVRHqlbY+ijP1geHwhhoezMOhNAcvN
sD/FVdUnzbDJK2ieoNgACQMdTgPmQ3h04B+zNIiZsmxdwOYKXHv5dTNKcvl9s5luOfX+EP7Z
Mj+ce7Sm2C4V1VKKvm7ew6E+RlJqJnvBRhJpFtyDXNUAbkG/x5WnewNwElGqrc1e9VjSnrPf
7spVooPbeQguegcY2/PVohOdlFSjJRg10Zuz7b1wxTkxkmelOSf6dVCdD6rz16E6Jzb9i9Wd
E2PgynOqROoKVqjG+VcdrCrrji9yiXt4d+Xw7sozfHelwFYnWIURfCyJAFVSCOCWlcfxN8AB
w1seiSkjh7duIkNCDsu0gs1e0yn2nneRPiSMGSnFXYiRgnI2UZ/1sRQ2Ag5OloOT5Rk4WQKJ
zX5ws2zqZoFJ1z25m03PffA9351IISV4YO4rSg+6FTquhx0TCi0nAH5j43sMQ3y+ry2t77Pk
qz4SZgZx7OQ2/8KjP+UG9tkiQuW6mR+RWSgAtBDQIbZzl7Gd1AskHdr5dBxn1gu0ZXTnZ4rn
lDsDLyLGc/2QeOjmeoBtXUaSs7kePGsJbCo1Du6mL8TdlDAM0CrDoKBTihsGKGkYoGXDAD1h
GKCsYYBWGwa0ZrNdux5cyqUSmQ1Slj8zGySRVpgNSN5sKNaWMZnOpr5kB1O6/P9QSwMEFAAA
AAgAqXBUQshyua7sBQAAoSYAAA0AAABncGxwdi5sb2cudHh07Vlbj9JAFH4n4T+cNzXRpoUu
rE3UIBfFa7Ksrg8kpJcpjJYZMtNy8dd7plMoLJYtrqiJEOO2c/nOme87Z2Y6U3v+8lP/XceB
Np/OaETZGFwWwDvKvqln3xlOxrXhkrC5F4xkzMWMixgCKoiPL6tqxToGIKRRTMR299rzvJ8g
kifCJxKewC2LGYAhfLRY3CW3sWsR++2YKjawi38Hagq6Hml3Sfwkdr2IFKLn79z7GgoyWkST
kTsNGvYw/R+bVSupG3IllSP72Ic9KsDNGlUrupVCP0I4RnYELxcxPp+tfM5COs77FkunrWTG
bou8V7+nZW5sy65xGGUUL4v0K0IsYHfbJuq3JIftCrRblkU5SeKAL9iUs5zGw/CcBvsEbeFs
Y95Fkc+n2KqIpmLcIqLyJhjmBtFM7QPf9qMALqtV0VyWz4VLY8ZnhAVYSJmM3Sgic8JimdN7
m7viPgfgijj7VTxFQbXyExIO9NEEZ7T0KKNyAjGdEgduSAA94kHNBMt2zLpTa+KzVd+07nCG
XasVwF/TBpw2ME39lBQS6OIaRNQTrqBY4yU4r+jiSyDrweYVnc7b0XXr6lX3evRx8OyGsnev
q5VRaqt11X79rPW+07Az453+1bMtvbFKD1U1GPRffVAInykOc/SlYT8eEDEnomaal/iKLdrO
EOHR3rDZME3DatQvLwxzKEiAXYaLIBxqwJsgbPN+xpYwLdN8agRRhPEIPRyjyn/qxrRa+UCi
yIWAyJgy9ztFXh6r4EykN/y5lyBnxKch9d1qJWHA+JRgbKUUAsen7UB72INnqgYxO/i0qXn0
AjonGMv1hEDIo4gv0pQgIk79jAnGpARJIrROAkcL2ZcywTCJuQMTEtGpywwa71R5q/2q7nKG
g5AOPg5w9G9cBqYFpulcPMV/GGS2qRsOXrcsmLhy4oB90anVLzutTuvCbnZ73eZl8+XLy/ZF
7SWWWD37qd2u2z2rpgJSBSa0AhXr6Z8YFXEjGCBrBOMj8XE9kWESRSuQdMxIoGaBNOqRnukM
R6fUm/m0QL2hrtVzCqqfTD3cr/AwSwG5bWCABhSgtd1u4QqGziED5nYxEYILXWiU/VUryoLr
4UQUryDGEaQpGJGYGMq5rsZEM1m23qxt50VtF6OCj2FMGBGuYmsbo61nxVKMYJycI+iICEJW
ThVBkP0sxMzz2zjLk8qz2Xv7kqq99gGd5tWKF5wy18+C/IIg+iPllLL8G3NuWU684Dz5/nIw
nXIePguSCcJIoQ669u8k8x/O57tZOKfxcVFzzt17qIC8XHMeQRrijv4UZDzGUSdMC6Dm0CIF
dPVxH0LmERKgXIc9gICjHeUwWeL37n+xu/09kh2TNUdKdpbg0NHPUNeeMmcOLWyhq07nbi9r
kJ0J6oWr/6Gnh4LFEKOaguPgZm48QUNpQSDoHHff0ONi6x1VBA9fqhU6pgi3mdkfp1N7iI1p
jI3W1mAm8ExSYDPE2HEBX0KYJuivpyqqlbUX6Uhdf5JZ1E6teIIaz4nCm9MAhwf9MC+VZObi
kpwGZUCEhIUKI4SgYUgEHoLmYP43d0xk6mleG7lsnKjyx4DuIpKKCpQvJlMJqiWZU59gvKkY
H3N12KkGxLJDvtWOwxLvSTAL3LVXOZdd3Sr3pFoZkzUJm7TZ9ItWilRdj/cKsUsZFuwJafxk
v3JO0XIpep4j7yFAyf3d+sKz1GfaMXPmkVu9f+LjoCwZ54/9+0TRMWl9ZBS9p77gkocxPLx6
BHgxgxeZEjbXLvBlGum7R/Uyx7VIhULdMI0L23pqIEAbb4kFHU8QoP0Icri2GpsOHQNauHSm
jaS6H8fLrWxBp2s7xmIpyzmjLh9P4UoW0zsePbTMi0fgaL7g3avX13gNVccCDONsPcUllKWz
NDqr1lB9dv1AXVGW3dU+MAqtN05sHTctB6w3T2wdUYqt1+r3sF5qpTxg2z6p7YOs1+4TcXfb
VpyfPzodGM+i2XyU3rira/Zlwx7hXbSFs0nNmEpaero9che1Vv35D1BLAQI/ABQAAAAIADBw
VEJ68y92PRIAAN/SAAAWACQAAAAAAAAAIAAAAAAAAABidWlsZGNoa193bGhfYW1kNjQubG9n
CgAgAAAAAAABABgAIOLeZmoPzgEghcdiag/OASCFx2JqD84BUEsBAj8AFAAAAAgAAHBUQkwL
fxSCEAAAZ54AABQAJAAAAAAAAAAgAAAAcRIAAGJ1aWxkY2hrX3dsaF94ODYubG9nCgAgAAAA
AAABABgAIHl+MGoPzgEgU8Ysag/OASBTxixqD84BUEsBAj8AFAAAAAgAbm9UQh79rsYnEwAA
MdsAABcAJAAAAAAAAAAgAAAAJSMAAGJ1aWxkY2hrX3duZXRfYW1kNjQubG9nCgAgAAAAAAAB
ABgAAAjnHGoPzgEAq88Yag/OAQCrzxhqD84BUEsBAj8AFAAAAAgAY29UQjTMrjzlEAAA7aMA
ABUAJAAAAAAAAAAgAAAAgTYAAGJ1aWxkY2hrX3duZXRfeDg2LmxvZwoAIAAAAAAAAQAYACD0
bhBqD84BwDVVDGoPzgHANVUMag/OAVBLAQI/ABQAAAAIAE1vVEIRKFovChEAAFCUAAAUACQA
AAAAAAAAIAAAAJlHAABidWlsZGNoa193eHBfeDg2LmxvZwoAIAAAAAAAAQAYAGDipPdpD84B
AHEQ9GkPzgEAcRD0aQ/OAVBLAQI/ABQAAAAIAG5wVEJLaxjN3REAAOTPAAAWACQAAAAAAAAA
IAAAANVYAABidWlsZGZyZV93bGhfYW1kNjQubG9nCgAgAAAAAAABABgAgJy6rGoPzgEAjk2o
ag/OAQCOTahqD84BUEsBAj8AFAAAAAgAZHBUQvmoQ69tEAAAAJwAABQAJAAAAAAAAAAgAAAA
5moAAGJ1aWxkZnJlX3dsaF94ODYubG9nCgAgAAAAAAABABgAoFz2n2oPzgEAbPSbag/OAQBs
9JtqD84BUEsBAj8AFAAAAAgAUnBUQmj95QROEgAANtgAABcAJAAAAAAAAAAgAAAAhXsAAGJ1
aWxkZnJlX3duZXRfYW1kNjQubG9nCgAgAAAAAAABABgAAJ20jGoPzgHg2SOIag/OAeDZI4hq
D84BUEsBAj8AFAAAAAgARnBUQohlrwn9EAAAhqEAABUAJAAAAAAAAAAgAAAACI4AAGJ1aWxk
ZnJlX3duZXRfeDg2LmxvZwoAIAAAAAAAAQAYAEDGs35qD84BAELHemoPzgEAQsd6ag/OAVBL
AQI/ABQAAAAIADpwVEIxX8J/5xAAAD+SAAAUACQAAAAAAAAAIAAAADifAABidWlsZGZyZV93
eHBfeDg2LmxvZwoAIAAAAAAAAQAYAADgMHNqD84BwDoLb2oPzgHAOgtvag/OAVBLAQI/ABQA
AAAIAKlwVELIcrmu7AUAAKEmAAANACQAAAAAAAAAIAAAAFGwAABncGxwdi5sb2cudHh0CgAg
AAAAAAABABgAoG/+7WoPzgHA3lpdWw/OAcDeWl1bD84BUEsFBgAAAAALAAsAZwQAAGi2AAAA
AA==
--------------000106010903030404080303--

--------------ms020308090803060301040708
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMDEzMTQ0NFowIwYJKoZIhvcNAQkEMRYEFHa6tpeNDEtV6J8AnG6AzRtp
aX2aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAN1cUMMEwfc/Qd51iIH5Zs6AB
7T54CMpDYNHI5ByuECObAJ62Pw4aMUM6tnikne3f+NkhreFO1gPoxc+0Xw/1u3yom3rMj++d
Gxf1yKAyEta+853MG9om86GNwfC8DTQINwW4rAdAPrcEOY/3eoQFJ0KcpG3x22SvX4j2aqW/
FnHIS/b+KwK2iNhPhJu73w/QJiAF5mnebJJ20uSBlqUhyI5GA2BMt2/bmwNzGc4SCvHs7QAH
lQ0Jc107++XJYyBl4LYZ+GYMtpqZ1GDfuiOUogBIWowpES+2YJOeChGkijAbK/ge5lA98rNt
bMXacMxA7V9ZVY5FmFB7ZTWCJMk7cgAAAAAAAA==
--------------ms020308090803060301040708--


--===============5851219563104011861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5851219563104011861==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 13:15:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 13:15: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 1U89Vg-0006zg-4Z; Wed, 20 Feb 2013 13:14:56 +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 1U89Ve-0006zb-34
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 13:14:54 +0000
Received: from [85.158.138.51:18671] by server-10.bemta-3.messagelabs.com id
	22/64-10609-D4CC4215; Wed, 20 Feb 2013 13:14:53 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361366091!20341863!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13653 invoked from network); 20 Feb 2013 13:14:51 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 13:14:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 02FE340031A;
	Wed, 20 Feb 2013 14:14:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id kZyXPVSsae2H; Wed, 20 Feb 2013 14:14:50 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 8220F4001FB;
	Wed, 20 Feb 2013 14:14:48 +0100 (CET)
Message-ID: <5124CC44.3090903@tiscali.it>
Date: Wed, 20 Feb 2013 14:14:44 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
	<511CC6EB.8050809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35676741@BITCOM1.int.sbss.com.au>
	<511CCB2F.20608@tiscali.it> <5124AC22.4010206@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B3568777D@BITCOM1.int.sbss.com.au>
	<5124B22E.8060001@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35687A0D@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35687A0D@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============5851219563104011861=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============5851219563104011861==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020308090803060301040708"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020308090803060301040708
Content-Type: multipart/mixed;
 boundary="------------000106010903030404080303"

This is a multi-part message in MIME format.
--------------000106010903030404080303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 20/02/2013 13:04, James Harper ha scritto:
> Looks like you still don't have the certificate file sorted out. Did I =
send you an email about that?
>
> James

I didn't found detailed instructions about certificate, so I tried with=20
a selfsigned one.
Some things are different but there are always errors, see new attachment=
=2E

>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fantonifabio@tiscali.it]
>> Sent: Wednesday, 20 February 2013 10:23 PM
>> To: James Harper
>> Cc: xen-devel
>> Subject: Re: GPLPV questions
>>
>> Il 20/02/2013 12:03, James Harper ha scritto:
>>>>> I added as attachment the build log for this, can be sufficent? If =
you
>>>>> need other test/data tell me and I'll post them.
>>>>>
>>>> Retried now with rev 1029 and gave the same errors.
>>>>
>>> I also need the output of the build that gets printed to the console.=
 Go into
>> command prompt and set the buffer length to 9999 or whatever the limit=
 is
>> then do the makedist then copy the lot into an email. Do a cls first t=
o clear the
>> buffer.
>>> James
>>>
>> Done and added as attachment
>


--------------000106010903030404080303
Content-Type: application/x-zip-compressed;
 name="gplpvlog.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="gplpvlog.zip"

UEsDBBQAAAAIADBwVEJ68y92PRIAAN/SAAAWAAAAYnVpbGRjaGtfd2xoX2FtZDY0LmxvZ+0d
a3OiVvR7Z/ofmH7pM6hsmu3aSadGTWqrJqNun3YYhKvSIFjAxPTX99wHXBAN96p0TcrOrnDP
Pee+OW/Yq/edbquutNfGwnZtd6aY9fF8pimW7SMz9PwnJfQRUqaer0xtBwVK6Cmmt1jCvfrx
R55h+ortPhiObRkhUnzPC+vGwro4N+f3SsVYhZ7pIMP9e4VW6OOPat9drWzHwt3MkIt8ILFo
s9AI63m8Ru7StJUvkn8w6afuwrhHKlojpeJ6jjfzFDL43vDmchh6S1U5sylEv2sMh5f4p6r0
b7ud/k+XNYUUb/vd3+C+1/ip3eoM9EG72xh1fm7ro1v9qjHEsMtPcV9Rw3XlzvdMFAQw5PT4
Pv5IE5zMw8TSAzOwl54fbs5K+w9npe2eVXagGB32efmk0ArVdtc7UMfe5C/Ybf3Rmetk68f0
NyacksZqZG1wm7YR2iqBBaGxWAKCcjbdu3HlzFAavdbFuXJmKV8oZw9KVa3V1Kqq4S6GtIfZ
/s3/8TPyA9tz/1QCeCDgRnm0w7nS8u0H5EPdZVWraFX4W3vzFe+5xlaPHpbk6lHIro5j/Knk
AYNH9WUcMDZQvETZM1FLnQnZJds8CvdKTX2XPhG1+ERIN77vQRDbRBeFJ83yXCTEE2B3xZ6r
fXiCcOP78QTx5vc9CnT16GomV49AdnYc408lHxqhNtNrJfC0iLW67xI1iW6Be/ys7w2fXPPz
qGvHnjhTK1AvxoFvjvHxdJAOaooOuon+aLuW9xjo98h3kbPnkxTVVMgi4iat+/HbiyqM7+LN
N1+r1fHEdse4IbwDqoWmmw9fjT18hz5wEnPFJzq7aGnudhypID65XEkAY8JLID/bujJqDG7a
o7vG6AfFDhRVrcBf2JYKYR4LB85xxVQqzTXfzQ49nHCj4n/qGPTXheeObdd0VhbaBhsvVxPH
NkkVHx7UYpCI4AC0Zn38i+22Wj+ljhBuY2ws7QMR4GQeiPBoTcf3C/gBGfk8pglqhVL53ab/
Wvovnf7FOb4hbEOHO8o/FLhr3vZbnVHntq//0Oi34LTcXNYA3B/p7+/gjt52+sPRZRXuoaU3
2mWtiu/1/qj2qw4FVtEfEUqd4OgUUF1XL6L6n9sDVuZYnTYGvQUQGQwFdtuNvg6D0XtwA23i
mlb75y5pvnV1Q7vR6YltNH/o9Nu6fkkXA3CvPZH9Hs+flsg3DcdRAUHZhBnBgpzPRhCgxQQ/
qfVtOISX79iJK9tlXWGji/yYjvK9/CO0awamo/rBEoa55xDo+jzfOp5gzzZ9L/CmofLZ4HOl
WWl++aVyuwzthf0PZhKUlyFfYQJEqUHXVfVN9a32TtWqb4kpur44p8Ji+eTbszk01fxc4Q03
iSQ3sNhRFaXhOArBChQfBch/QJZKuI+Dd/eTo61g5RPcKrTZpNfeiF7f6/Qu5kSsoEZXflOB
v/DIVRjgaEPD7eVynCMhAec5EpJJzYSY5+AC5zusRAr4fgf3wVURB4pKnAmRMmdEUZkzI47Q
H0XkWaZE8Thj4rAMc6LgXdwJ1zH+xAtXbBq7+VRMdjdoNxujtg4w/fp9v4kXYxhT94ZNvX97
ezeKl6HV6ugw4CGgsUFX40mb9PK7WX8054avh2cM4LDr8ht6c/NErmfmJAh9OJ0U+suv7Mp2
p/1DcGaeMYpBdHPNrkPW5lt6vbXY1Wb13aier57+U3vQb3fpijDwT73Wtd5r/Hg7iKalD0cD
fBCqtRRKp78FpfqO4oTAlC3bYWN8tM4vqm/4vcbGMPcWaGn4xiJgz33OozN+NHzsYlPnBF8d
G3i9DKId6+BBm7nI0qfgbVPNHZULkBOemak2jSADs7YBYSA+WiA3JDW4K8cOQt1CDgpRGjZD
oW64YBWhDWQXPaYBS2+pL1fBPA0Fj5//REDE98f64ADcDi9l0MkvKeMDNVlNp8inbWxCo5HC
GMKNqrgPDkp0FGzOPchMnENBZN/zYtww2F3mPWuDA9LVZHHwKnFQPAp8EHafApDFx5OW2kHS
UoukpYiwx4JQY4JQ42KPFUhr25RuDH9GGcfVWYWcgAWVckAVEXBHQQIBdySkpKKej01kppaU
mVpCZrISKcD9bpmppWSmtiEztQ2ZqW3KTC0lM7WdMlPbIjO17TJTe0ZmapHM5IUrOo1nZGZU
2+pysn6rffX+hhTOWtT87b/vXcHoNAbMyh0tR/JqG5JXe07y0mp8qNOSlwEcuEaSV2OSV0tJ
Xo1JXC2WuAxzEN1cs+uQtcUO863Frqx8003XX1sijxh7yLNymO9TVv5e4nOdL701AemtpaS3
lpDeWkJ6axvSW5OU3oCvRq5hM77Vp5aXLC7TRbTG3kUCQQ+hOXfJ7cwNw4kT4U1WVGgv0AJC
b0lqCz3YJgIJHiJ/apgoQZGpS9LNgZUH4BFKDcyA7pnBkOpjMlvCKcJjxHOMJoiF1DPaCK/n
6ggFZvUR3CxfrBgrq6DQqg0NJUW/jOi3qSy8JhLXFJJRWuIm+Q5xTK7IUFhKk+EQ3Dxth+0r
r8pSk1+KTbeeVma0HA7OqjmbdXwA9EBs1idHEWTWk541XptdSO5fVKmtynUi2sTOMxoj8y1I
q0x80Flqjs6pNzQqDqNzpA1mjr6kXwVPTKmAlqFUvFVY5z5GihjrHwSjcwO8qF0/r7375qtz
YOHw8+Yt/nkHPxdfw8/bKv7Btd+8xT9QoWm1r85rVQKDH60W/7z5WsGmE/Zegn/ZWDkh6WVh
mHPbRTS2DmMLzdkxfT/QxHb3TNee+AYkAfQM15gl1Mx3KS3zCL6Yo01llzpN/HLFd0WZYsGd
AS8tuAer+C5iXl9AP2nBUcTeb5E6hU4EOGCRzUfysMg+CIcuoAMiUovbadJ8QetP2i54YfBv
EevC9Yvi1n6r/lPEc8Y7KmineQeFbXdQLMcL/gN2xxXLwhovZnuJDlrg2uPmCx16pFIX1kHy
1GvfbbVEcUXGFJUMSG7o7kI+C1qL1XnBYGasLmt7qsuHOmMLsDpIs7/8Sq4p44NA0gYIAREj
hN4Bcp0tItwSmNA6poLmUgl5kvjY2yBNs9yDhroQxMmox0Acn/gM5JYLbGtxfOoMEMffYflL
NQADPKyBpLEvTZhgQXLrmmRThJByKh8ZIY7MOJQVyDRHOBAIVwWwIGlOihStifXeBfaHewfu
XEQ+vabgBDCWUtq/xaBqlA7W7eYnhuWmmcJIUwltZDnYpArNqd82s/z55Ca6RQONU559k4zr
zFHOq+8gnjD8dajfDW6b7eEQXNqNAcQoRu3m6P2gffnJJ5+QQA1cFYZJk99wDdv24CnA1aT+
t+Go3dObt707GOpVt63DHNq9q+5ver/RI83FYkb9hUpudfgUhGiBlxtO7cRBrK9uXmNd8dbo
0GP62OkPlaS+4kPCpSd12EEWvoZENJk8tDhSFUeplEyIakt46rnQVDIstTMkhadQZk3umTWp
xgcWq7FHffiBsbzKh1/i7ZySC7xkLiCw0Qc+7bkIuU97LgJ5yOPzaGbjJ+zhIPcDFHgr30TZ
pJ0LtaZevKt+o1YPj6RI28qyZjJwnY14lKjV7N4zq/ngRTrUfpZYJJzhLHVqd6Y6d6KAh+EQ
lbbAcFql1wZZUQf19qZ9iX+UJHTU/nV0qYZoHVLwsE2YQb3T74y+sigMuEF90L7mhU6TFIpx
PeBm+81Bu9fujxrdev+WwnzwpxkBooX+bat93XjfHXU7VxTyy6/0aqHJapa4xQkgdfPhq6m9
Xi2/WsKbyQatfaDLXYejRAFesAnafjAwHxvDPkd+Cy/EZiOPllSmK5dEtZaGtbChNQpdWhP8
rjRsTcBWetRo/lSvrs+r8Oer6roGFzZw8mIUvQ9Wk4AI07prhAD+6kKN0CawHHVCF0HgPPlP
9es1fbOqjUukYq/nGgjFPDfc6pSm8ZFEPykPkTgZrd2HBnuK9qJb7klHPUZypNRrJEdDPEfy
ywjOGTka6kGSo9nhRZJuBAZ7eCNJb9JexAmPkvx6b3qVxJnSFYku3T7AtB3v8SfsTBIndkMv
uPddR45qbkgSPC5sAAjRMEOLEmJza/yLNe1a/v7ECQ4p1EhicSBrITCmSI7s0VrAu69yNIPQ
eUBic4xpVBX/5WVjtdbvk8uc1MPJK6zEQIpgMVqCadaV3rDTVVR4m3fhWSt43Rj8ifQu+vqH
RV7oxXmi4Gxcuda3WAMJDZ85P917Vt8dNW++VQzLorf4+yHhHFEMbDiAgw8XEK6wQVZ6D7QS
hCGwfvBjAoaJSm2q1KZKbarUpuxSm8qlKbWpUpsSUohKbaowbeqUX9wT8GF92Df4BAaY/yKc
0Ft6QkhCb+kJIZUv55Uv5xX+cp7A0zN+oe/bwdTYu2lRATPkG/pdNZJ4AXlrGHQN37IM5mCj
ztJ1kr5/HiCRW16KtiVSIhtK4CGT/a3fQ+XHNutX2279alusXy1p/Wrc+i0yjTFj/WpJ61fb
tH555iO3frVnrV9t0/rVstavJqZvbFi/2lbrV9u0frWd1q+WsH61jImr7baHtcj6vQkSuh2p
OOwRwC3sReyjA4ihVnwTtmj74sSRti9HNTckCai2L0ezqWtroL3uspqoHstq5bqJtiSmontw
qq7EkpmWzLRkpjLEJTP9gMz0JqPDPqPf1sRyp+m3bo/0yeH9cqdzc8GTAxVNCocPs4Kn8uRT
wukwj50Q/qpzQsW+zlzmhL74nFDY6DIn9IPlhOJ0R6kNYemOBeS3Uyb5ajkand6OVU0jlWzt
xbM1upEvlqnt8d5L8viaLz7pm+2fZMr3AWG/Q3k+C/tJ8XL+Betnv1edDfvVng/71baE/QhY
VvrnfzNa6BPVQkhCn6gWQiq/Yy35Heso7FdLhv1q28J+tW1hv5P8GrbUV7DtnK9gs/K1JfX0
jF/iR7LjsB8u08Kpfxk5V158+PQKOrxXlVxRfie5TMU4wVQM+qRJJ2K8xs8l8+XgWRwctuen
nnA0RWbFk74FgQwNipibnyHlY+EDlxPf4mkl0JBQWkn5UoVwJLR8qYJGQrNvTuS+ZrElEkoq
DnsEcAt7EfvoAOL/cxL57hRuyUioYDfRlhCqMm1DglmVaRsHpm1crwXSNiQVDdyKfAM8BHBo
C//nJI5d77/sT5w4H0KNHDGNJLWtp5pkVzvxJMBS9RWWJqXqW6q+pepbqr6l6luqvhJ6Z6n6
ClOVqq8g89zIhd4jPXpXnUiGsYtO+2vTML7cDHATpIHpuVN7drrJ33yMx04rhBV6lQmFMK8d
nJDVlimE4imEZy395q5797MOyzG8OMWMQhe9gvxomMRJZAZKxe5wZmCGS43zU6P36oEskkDi
9emmwrjoND8x4qLyyyJlOks6neWE0ncl82rSAut/mWrjotf2sRMsHs34Vg/XyZKfKnm2lSxS
zshybKKWEjnhovLrA6aD544tP+taKMlbCKnM3z4kf1vvwYA/ePp2627YuOPVtf2SugtO4849
9S8yg5vPimVxJwBErMQcbs//qR27J4VXkGNgp8JGIp2Ebl/m0Mn75l9pIHGB/Bmqqz4eAV3w
nADjN8xnr8UhxDAw4LFBbHZPrrGwTey73wwwwpkMPGfLN4zPq5sfMV4YttscjIY4hr5akhrh
w80x5KJ+hvUAHOCNJhfsoh93FaMCWcyoFsEDFERonove8ZmWiQolfyn5S8lfjstfpD5OmRO6
CearEDyjLthUpxu7SQwyodv58rod9oNm28x3hiZt4hNy6cTWt/CcPqD5nT+4fKtZyLQWQirt
79L+/k/s7/xj/yIN8MS0mAWegiSYJuUY0qyam+HiC5lA2WKIy7D+0hIvNeUXqikLnO4EymvX
lYXIAgRraCwl82mX3qMPJvY0pkosa2n4l+ysZGclO3vJ7OyYboZHww5db4lcC4C2GwC/cdAD
ggmertdh95gls6+4KiuUW0Brt3ySQTCHq/wPPuSZffmGx4FveOR+k17swGNCGRofydNArSwN
xJH3IvP3IwM/41501NT+X7+ZkpWdkmSWHYi8SQK/mZeoRf8bP7pbp2siSIg27FDPFZf5/vVS
TpVyqpRTpZwq5ZQw2X8gpzYMwBMOfErLng8YB5Uea34wUyjiKYRUhkXLsOh/EhaVfgpeZJR0
9yxZ0PQ5hGfeOpdV07kHau/l302xJdR6gFFQRl7lrYIyVHESoQr5w76b4nUFMszpbDHzEz3t
nvjpukVKdlSyo5Idiazoi2NHUqHOfwFQSwMEFAAAAAgAAHBUQkwLfxSCEAAAZ54AABQAAABi
dWlsZGNoa193bGhfeDg2LmxvZ+1de3OiVhT/vzP9Dkz/6WtD9GabzTqTTo2a1K6PjJombe0w
CNeEBoECJqafvuc+4IJguBjtmtSdXeCee859cR+/85A9u2p3mjWltdBnlmM5t4pRG9/dIsW0
fGyErv+khD7GytT1lall40AJXcVwZx48q19+Uf3xbG7ZJpG7xQ729RCbnM9yeFHjBXY8w1K+
S/4hol87M/0eq3iBlUPHtd1bV6Gt6Q4vToeh66nKgcUo2mV9ODwll4rS63favU+nVYUm+73O
b/DcrX9qNdsDbdDq1EftX1vaqK+d1YeEdvo1qSsquKZc+q6Bg4B3VbTvyy+QZGceJqYWGIHl
uX643Cv0H/YKre5VtqFkEODFeU8K665qOYv0AIzdyV/G3b32aN9pi5PjsXUEl5h5CvXxAljJ
cQHZunJLiqWmtClVOrKkQEsPLZXSglCfecCgHExLNU050BUgKwem8p1ycK9U1Y/KwYNSUatV
taIiaHlufUNW3W25uv74FfuB5Tp/KgEsEHhQHq3wTmn61gP2Ie+0gg5RBf5Wj94lWpDq3Xrj
luzmUv/ivqxZ8nqdkl39tCWwl5CW7PQ2kGyo/H7g4N3eBqB9YvGyNF+8giN3hvAsvmYLVz8M
nMRcy1uNy+ujVNNKLguJAtddDSU2tRIDtrp/Ygtbs+R1O9qgAIDU+03PHT45xrdRA2xrYk/N
QD0eB74xJhPRxhpgCQ0AhPZoOab7GGj32HewveZOEOUc0uEkRZr34w/HFWjf8dHJD2plPLGc
MSmIvAvVxNPlZVbly6x4aeVvGGv0lczF7KClD57N7CHynSvcN6BNZAjK97amjOqDi9bosj76
WbECRVUP4S+8lkO2jdjKT+ULzZ3Lhq36gUdK7VqG7wbuNFS+GXyrHKGDiRUqjcPG998rfS+0
ZtY/pHPsHWBf4RNfqf6gwsw5qnxAH1VU+UBx7kkFymfT3Hvyrds7KLPxrSJqaNDVpZMFoypK
3bYVyhUoPg6w/4BNuvKhm4fn7leb6enhV6RIKLDB7t0Ru19p0VObsPFHNbpHD+wNWI5xyAmb
aRUvrFEbX1tOs/kpvQ6hurHuWRtigmW+ISaDo+HDpnZzcqydVnmK9ChODEdNrVHvdHiy0e81
26N2v6f9XO81YYFdxJy9kXZ1mUy1e8PRaYWnr9u9I3RarURprTeq3miEIBh6o1hco/waI1YW
leMk36+tAaeludstQv4Qkxm106r3NGis1oWHuIJm69eOSJxdiJo1th3UGz+3ey1NO2XDx3PP
L/unlbiIy0GrUR+1NMjXzq96DTIww7ik7rCh9fr9y1E8JM1mW4PGD4GNd6ASD4DBbr8btUfj
Tve18IATbH73TtjDxRO/zxjHgTEJQh+mLCNf3/D7e872D7vfuaGnh8YdS7V+Dg6MA84xiB7O
+X3Iq/zA7n2T3y1+fzqIGMRIa59ag16rw0aPkz91m+dat/5LfxB1WxuOBmTSVKoplnYvh6Xy
kfE8mu+PK0fiGfFawycPm5bN23JesLLGj7pPFHuVjYA61smw6fS413TbunWwqU1Bx1eNFZkz
3bZdI5Nt6EGGZuYRoSE+nmEnpDmkKtsKQs3ENg5xmnaLQ013AMDgJWYHP6YJnutp3jy4S1P/
nmP/iZLgaY55HYJAyhGpDDu90jSZV5P5dIp9VsYyNWoptCFcyorrEKRERcFy34NMxwUV0MK9
SMYFA6Q07nkZgpDOpoNDRkmQ4laQibB6FpDc56YBBeszONwCfQrn3R0sYfjrTqfKYWMh4Fmb
HtDk7CH/1DEYjWauQ2alPTdxHm3szSe2ZdAscTJBLiEV6uiFR8wLGeBoeSHDozkd38/gAvaJ
whMKNpmZAhdLHFPxEaUkzqcVZ5M4l5TkoZQ8kFKHkTiI8g+h5QMo5/BR4M+KswdyopMnOnVW
nzjRaaMQ+FT42seh52t4Nrd1WAuQr2SIejCLp7TYuvg8rgcBnk0IKq+tkEQMsBY3JMKiaAtY
FL0Ii6IIixZ2gsBMxGEmikAlf6QF5a1bQn9mPZPs7JqmZJl1DXwy8HEjTLCEN8SUXOvF3BSR
ohQiRUlEitKIFK1GpCiFSNESIkVLiBQtI1KUQqRoJSJFOYgU5SNS9AwiRREiFYkz1o1nESmK
EWnE2eyIInrN1tnVBU0cNJl23LvqnkFLESdmURsqwLVoCdei53AtyyYTPI1rOcHmd++EPVw8
8fuMcKRwLaJ4lmf/w+4Cz6IYz3KOQfRwzu9DXhWf+n2T36P000Ga4dwsXI5jxpmFuOKFZqHt
KVkDxcAYSQBjlADGKAGMUQoYo5LAGPjVyMhvxI/a1HSTSS+dxAtiY6MU/ABvxKGPt04YTuyI
bzJneHiGZ+BLS0qb+MEyMIDjEPtT3cAJiUxeUu4OtvcArEdJGp0QXE9P1TG59WAmkTaSPjIq
Q3jLqD2mZmE7y8rgdlKiGKeIKQvkoxyB5BklA+VTRXpRkWlsz2gpcC8opGxRiHhDgiNbCL0y
IfYSWWYG/wtyVgFg4uzFL/OJ/gpashVBZkz5rBG52cG8YO4IhiJMrKpqyirL00KHYAVHczDO
E21LahSMedUsFexCeknhELSoo6JbmQKf65BC2s7MnwAdlEN3HtaELZFuRzGmoAztC9g2WrX3
1Y8n797DVgyXow/k8hEuxz/A5UOFXEjuyQdygQyECEa+viGqC1iL9bkd0sJmunFnObhmwda3
MYMlyOdbLDvWxNfB297VHf02AQo/pjDhBqySm+nHCvWRQfAt18MU0W3WBPvhNos3t1x+vHNv
upL0GbDxl51zemyvC7B7ba3s6ETbWgV0X9106fQo3NKrpWVvY8xpwdscD3Ld+HAILLCl8c4F
KhtfTKKWbbxaUfp23m+wxa0s2PY+JsDddkrewvukkHBb403K3l6jI2y7ndKTsxv9mNHzGDGr
6IkMoelRYi6cRrlwuljfZ1kEX8sYQWN8i9bEty+1dK6vA1Dp6xt6T6kClJJSBxgFOGp8dOCR
0ooHaMlcLR97WIaZKOTlBLyyAky1lpRhmrUkM9OjJZmZVinJzBRgSeZ8BbjES4N2vUA6uQWU
k0rsESVGMbmJxFuR0vAx20Zstnyly6L7BRx9CrBAaJm8HF5Q5bgDWxWpF/bRbYSRI4XESPH4
yl6fkCpRxFSnUxw7VRhJCi1NxXzRseCd2mooeV7PivtTGAuWCSX3DdquA1t5X/kINvXhzVC7
HPQbreEQLLf1AdjsR63G6GrQOv3qq6/gLcNV4XwsOozQ+UsPngKSTfN/G45aXa3R715CQ886
LQ160OqedX7TevUuLSw+EtRrdsKqw6cgxDMy2DBbJzbmdXWKCuvIl8aaHsvHlm3IpPmHPkQk
uvLzHA6tt+HZXcexG7tsYneNkvHV5PhpnvPRJP0zq30zUPc+GmGdaAQ1nrcEYG5w+cPG8iaX
v+yvL/b7wNvYB5Lv+3VuCHSZx9PSyLoo+AKhzwMcuHPfwNkolmO1qh5/rJyolZc7K2KNtaSy
ChtK2n8jpbpCVbmumXZkTtdtCuG26J057LZgb6wBnLtonZKLkqSOWjejUzXEi5CRhy0662vt
Xnv0zmQ0mPa1QetcJNoNmniRYkyke41Bq9vqjeqdWq/PaD6YcvQAs0Sv32yd1686o077jFGu
b9jdxJP5beKRuOlrxsO7qbWYe+88Uw91lvvARrV2rPJK3SBDms4d6uTwdBN+sFr7gVKjUESW
8MwJ+YUqDGzAx2lUb3yqVRbvK/DnXWVRhRtvD/2lCy9jPgno1l9z9BDI747ViG0CvaxRuYgC
s8F/qp0v2E9lWiT10wnNKj9TQUrCcCD0o3ICPpatYck0ISnFskoLEBNFeSFvHSFmqighx8wV
JQSYyaKEADMPlBBgposSAvnmi5IvFtr4whKSZozykglTRsnRTZozYsn8w48c6mOQZ7Jn1OHQ
f4DO2u7jJ2LHkJZ1Qje49x27lNCdXo7/cWZBWkqEI3wqR2D++Nqcdkx/bdnEZidVhhgX8E2T
LbqU1KM5g18llhIZhPYDlutfJKKq8Fck9flCu0+ObxL0kV8WZqNOQB96MVB6qdWbhijLg9HX
Fauc7M2uBS0n2/Z2opf38cj7eORdi0dOrrRygcm7FWIM/eDhuFECjhk5R8FGP6GxnqOg0PGx
9AmNZRW+xPtkPFldvtRBFyv1aH2l/qUHWp5Sj/KVepSj1KOkUo+EUr8Bb3dGqUdJpR4tK/XC
QS6UevSsUo+WlXqUVepRrlKPkko9Wlbq0UqlHiWUepTR3NFqNR9FSv1FkFLqadYL5i4RLy/p
43Ulue9WCvzmKDvSspGyU0roTi/Hz5SdUiLLygYCCF+sLJaqInoNVEjWzQtfIwENeuedvKyZ
m3Xxvmkfj8SndvY+njfk44H3vffxbNLHQ0wX8mP8ij75I9Eb8VmfZz7ikzVdVJ83XVRzTBeU
XGo2F39IR+q7PVJMUt/tkWLaf9znZR/3iUwX1aTpoppnuqjmmS52+xNBG/g0kFX0aSBOODfl
V9r4NXw2KDZdkDRPbD4WiMHPN4sWWffy5kCaYw8Z3xBkZK/0dQLGNaIEk7PY2FHnGGvf23CN
sb7somOMteztuMX2H/XZO9FevxONrcpyLrS38G0f0Xfuf1ui5QScloDw0t4qKKTYW7UPQf1f
hqAmvVWFQamRt6owBLVw2om5S8XLS/p4Xcn/a2jeytC4Mt4quSqi10CFCl3yhRoqYyje6Bjf
3ilfbpvbO+XznfLnCymnfJnZS4ooKS2sMy8S/7+66FfEI68tm5gSUmVsJESgOFbLwbsdogXt
KwxaIP/Vj+E6U+t2dyMWRBs3G64A4/MmDdDP/89He5PzOibng6Z2cdm5/FWDYRke76IF2sGv
PVaBTk4jtuRmVn+pMIHy5ueXKtS00YXvY4ftzrsXaRFbwqXmwmczg4tmfW4b+N4WvUFbtNaF
xn92U3Tzcli/FNnVFxqoN22SjoOhCne+zxkD5eB96NM+9GmDoU9pPLiPhoqjoQrX3GsJgiJo
1IgftXCRTPmplGuZySTbqXgEVVSSrPNOYIlynrsd8sGJLnAHXJJAx0QMaY6dWm4gRDaRTJuo
ZXWHvX36jdinnYVBbSYsNcP+La6pPqmGDZ6kFRvFduow0GFWY96FJ0efWQaxZi9bsWFyBa6d
NGMTLl5k2rI90y2nMRjB/+Tsh3OP5sjNUpFdyqCsmw+wOI9QKYsp+wSHnBDAECY0Cx7gWUYk
a5mV+2lVcDcPQZt3YFvdXTNlopFkkxMnhTBpZDlfmYkgVsjlevLZNPJEu/Yq+V4l/3+p5HJA
M7FEXi3STPSBQ80UhWzDAqLngk3JwUjkZ+Gm9L6+x5t7vLkDeDMoMdnfMuKUkAowjJ3ulfts
gOc++p7vTuNAgiW7QCHcfdSt0HE97JhAtJwAtgUbP2Dowu6i39Vtzv9//2JMXCj/yiFyuY59
NsRcrpnFsFcKG0sx7QH0HkDvIoAut2JeBZ5e3SUOr1cz5P6uotgZwLKyUcYykRT7X1Hsf0Wx
+V9RSMxUIiUt4OOSApBVSgD8KOVl/DVkQIcuL8QQyf73H2t9Ghm22WC9H4zIfc54abte72Bb
zZ41lawL9/eWk73lZAcsJyVn7Wr2t2NXMaa3s1s/rudfUEsDBBQAAAAIAG5vVEIe/a7GJxMA
ADHbAAAXAAAAYnVpbGRjaGtfd25ldF9hbWQ2NC5sb2ftXXtz4jYQ/78z/Q6e/tPXxQElTXt0
kikBktLyyADX64OOx7EFuDE2tU0e/fRdSbZlY4glAylJfXOHrcfqrd3V7s+6yw/tTrOmtB71
ueVYzlQxauPZFCmm5WEjcL0nJfAwViaup0wsG/tK4CqGO1/Au/rpJ65ueIrl3Ou2ZeoBVjzX
DWr63Dw7NWZ3yrG+DFzDxrrz9xIv8aefVC8ul5Ztkmqm2MEekJisWCgkrHn8iJ2FYSlfJf8Q
0s+duX6HVfyIlWPHtd2pq9DGd4fX58PAXajKkcVitJv6cHhOfipKr99p934+ryo02O91foP3
bv3nVrM90AatTn3U/qWljfraZX1I4s4/J3VFBdeUG881sO9Dk9Pt+/QTJNiZ+1tT8w3fWrhe
sNor9IK9Qpt7lW1oOrvWG2mj+uC6NdJ+aQ2G7X5PGbZGyqivfBxWTmDAJPKiC1g/iyeFVaha
zuOGJozd279gFWkPDg40uqbG7DemnEDNYWlsUpKlsZhNhYTJcSFVOnOkLEsPLJXG+YE+X0AG
5WgiXahypCv1bvPsVDkyla+Uozulqr5Xju6VilqtqhUVkRqGrIKpfOl//II933KdPxUfdim8
KA9WMFOannWPPUg7r6BjVIG/1ZN3vEaU6af4lqQzA/yAzMxB781kQ6HLqWksvtLS85meSBRP
5BblF5tRuY0nNtMOPmw2Be2DjudyEVgCgmMvy+skmIVkS9KrTIBdyJZfbJUlWDaUnRxsGrO5
5phgso75rO5O6UKlN6VgscVGqXrRoHoRqfKLnjt8cowvo7pt69aemL56NvY9Y0wWtI01ULE0
0Ku0B8sx3Qdfu8Oeg+2CzDVKOabDSIo078bfnlWgfWcn332jVsa3ljMmBZE5UE08Wd2u1XC7
5m/R9Ty4QF/JNGUHLS0Od8OLxDuXy3+gTWQI5HtbUxhfuamPflQsX1HVY/gL03Iszcgl8ipz
GzbIsaEcNx75KmmzRQ8vKvmnjkGnn7vO2HIMe2nidXHjxfLWtgyaxLsNqSRKSIOBfI3a+KPl
NJs/p9YmKWSsL6wtM8CS3zLDgzkZ383hB7S153MaoAYpx79b7F9T+9junZ2SF8qQNHhjnEmB
t0a/12yPYG60H+u9JizD6/MqRMPUfbiBN/ba7g1H5xV4h5JO0Hm1Qt5hequ/ahAIE3ojSqnR
PBqLqDxWvqkglg5rIAzzXO0WiTqrnCi0MSyy06r3NGiM1oUXKJOkNFu/dGjxzctrVo3GFlq9
8WO719K0czYYkPfKFZrw8expgT1Dt20Vciircbo/p7JzwzBfWk5YDDlm0h/DVn6Q33gbm2fY
qucv6C6p+z6e3xI+VFvfTlSwnWyEcptQvehahuf67iRQvhh8qTSOG19/rfQXgTW3/iEMiPFJ
7CmhcFKqUHdFPal8i96rqPItPaI/np0yQbR48qzpDIpqfKnwghtUU9CJSFMVpW7bCs3lKx72
sXePTZVyNptM8Ge7G+fjz0ixUGiDPbsj9vygsbeYHYUBNXryl2P4C9vuOIzYXdtIgblsZ0eZ
gP3sKBNwH5IpZjwkwJlPGKIB8r6BBZGkiA1FIc6JaJhzoyjMORLP0Bsx8vWciaZw7sTjshyK
RG9iUSQtZFI8cBl2YzOzgo27u52FttxZtP03g1ajPmpp0Djt6kOvQWZlGHejO2xovX7/ZhTP
R7PZjmR7OHqVePQN9vjdqD0YM93TgqMwwg6fi+/Yy/UTfR4Zt37gQadZ7Mdfw2e4TFo/+kfG
UUgxiF6uwucwLPNb9uyb4dMK0ztROp9G7efWoNfqsKkJo3/uNq+0bv2n/iDqljYcDciKrFRT
Wdq9NVkq71meALizadlhGx/MU1g+/B2FbZi5c7zQPX3uhxwoZw+PH3SPWEHVGc2vjnUyXjo9
BGhg5Jw62NQmYBBVjQ2JcxAYrpFJNnQ/E2eui4SGeHiOnYCmkKpsyw80E9s4wOm4KeFkDhwA
8UpmBz+kIxbuQlss/Vk6Foyy3hONoubZsA4eQcrhoUx2+kvDZEHdLicT7LEyVmOjlkIbgpWk
uA4elajIX+27n+k4jwXZfceDccFwwDTuwjJ4RDqZDg4ZJR4VtwJ2fSQRhSQ6EXYoFHYoKdpQ
LNo2LyqWK6t7k/hndHKSnNXLabSobg55RUTcTjKBiNtRpqS+np+bSk2UlJooITXDEA3A+2ap
iVJSE61ITbQiNdGq1EQpqYk2Sk20Rmqi9VITPSM1USQ1eeCSdeMZqRmlNjucrNdsXX64poGj
Jjte9z50L6F1KIzMMnyUI/LQishDz4k8lkxWdVrkhRE2PCORh0KRh1IiD4WiDsWiLsw5iF6u
wucwLCtczH0zfIbh6046/coU2mMhE8hKQD5RWcl3ThZ2vtxEAnITpeQmSshNlJCbaEVuIkm5
CfnVyFdhxK/axHSTwUU6iB+JCZPG4PvAmDn0deoEwa0d5btdMnE5x3PwSyapTXxvGRhkZ4C9
iW7gBEUmLUk3Ax3NB5NTqmE6VB8eGlJ13E4XHpQSioSog4Sfb9YDsulU5rMC+LDwTFwziGOz
qgFLWtENUqUuolLXKQs8JRKULCajLsRF8hniObkKweKSOgQjDCeSp/KqEhoFyxvNNE+kvywi
o1/w6KyCwcpjk7+ajzeAxyVbwVYWy5HWPXgMH8iwqo1rMGUSVtlhNqmqxGHerLSywjuSLZ1n
59RpXYbRr650njHquKQJhrRdOQY9Qzl2l0GNGzFZxlgDoTna18CLWrXT6vvv3p0CD4efk2/J
z3v4OfsGfr6tkB+S+t235AcSEKq+O61WaBz8oGr8c/KNQg4txIwJBmx9aQe0lrluzCwH10Ij
ox0Y052aiaCMyE60lklkrTcd69bTATvR1R19mjhZvk8dLHdgqtldJzcppdRy9wJ1MYa579qA
se67CvMF6ohFwT4qSguWvSyANWJpv10BHrnX8iORuddKKMPeRw1U1u5xumn5+5oDWvi+x4b8
7mVouCKyx/FfqyntZcPxmvY13byG/c25v2f2578E7+Oq5v5K39McU/10n+NPyt9v4yMtfH81
JFc/usicUiU9litqvZg9gyUTVV/U3clV6YIa83YuGHSxhyMJLfbjr/SZOpnQmPTphEbREwp7
g8y1cBThlcaJDWTKsy4HIJUlIDYKeaJFESJmZJCgYzYGCQJqaJAcNDiASxAwI4IEwQYDglwJ
0MYtS0iaCeQpEydiydFNsi1KyTiXh/WAeGdtxhikyqMcCUSrAtkAwSdHC2uQ8OsOMERSP/Dl
fXyZgBQCRwshsb0+iapE4LROJx+mlouDhpam4HV0PMJO7fXrhHU9y+9PLuwu2dC94uU8g/b3
yFZOK+/BqzH8dajdDPqN1nAIdvX6ADwlo1Zj9GHQOv/ss8+ouwieCssZFk5SQtit/+STZJr+
23DU6mqNfvcGhuCy09JgbFrdy85vWq/epcXF4kz9yHQBdfjkB3hOphH2w62Nw7o6eYV1xEtj
TY/po5Eh7aHpxx7ASt2C4HaQvm8BHycDj4s9Z7HXTMm4zNa4y55zlSXdZM+4yBRlx2hOkZnO
9QhvmSEXtZmbgYA11XhBEnvtTrc5sNo3uc0FhGW5u1/z7v4fYbXVeMUa2cNnuG3o+wD77tIz
cBYWeKZW1bP3le/UyrbH0OrW9W/nOJKyDBAss5xACEHNhRyL0sYHYLwrHkBhW4RzR5p5UAjR
dEPakZtHt6nqvkdP4nG3BRKtBmr8deuc/CjJ2FHr19G5GuDHgEUPW5R11dq99uidyeKAd9UG
rSseaDdoYD8mF1JsrzFodVu9Ub1T6/VZnAc2Q93HLNDrN1tX9Q+dUad9yWI+/sqeJr5dThOv
BBVTM+7fTazH5eLdAr5l11nqPRvuGuw9FuH6q1HrP7ciXHdMllxkr3EDckTmDqLjydKhzryF
bs4tKI7FLsxb8nk9zI0fDvWo3vi5Vnk8rcCfd5XHKjzCltPv0di7v7z1qcyvOXoA0e+gCYgl
3cJ41AhdTAgLynuqXT2yD9paJEQTim0+oBS0WfEDtjyRh2VqSlnHJOhYciEiYiUrRrgoSsis
ZZK0zGImSUStZgUGE6xSkkTMeiZJtMGCJl8KtHcHpSQtacWoE9a0AqO+alGTYFOX1LPWv4eu
2+7Dz8SQJkHtBK5/5zm2JNlMl6V4mFsQExPFSkaGKNYSGSHRFccfzUnH9IoTJ9imZLOdACAc
vj7BknQP5hy+RJYkGgQ2NFOSSFXJ3wd7Fob15aN2lxzq5HmCflJMD3pRnGRtPp4tFyYj4jB7
OWUzF2+/V0S9SAvzgelCqHmhTEKoeaFMLwKWr14kJG5N6Q7bHUWF4Zu75hJuCgCtmr1FVw6Z
9Et8AsAGlXvpmN8TJTbQvdBT4NyF6Z1R4/p7RTdN9kouLQpmmOUg8w22cBLAJMECbcu9h0Sm
YIPiANo85DBwCeb/v4P5Rbb3+JXi86FvIZY9CpQH0PIAWh5AywOoMGF5AC0PoOUBtMgZsjyA
Ht4BtHpxze7Fo8ATwPGRqCu4FdWfwcFjmk6TdKJw54akcsnyrfFySDtluLujuJK3nXsDrVXy
0HolD61R8lBSyUNcydsnsDOj5KGkkodWlTyOBeVKHnpWyUOrSh7KKnlIcD2vKHlorZKHVpU8
tFHJQwklD2U0ObRZ7UORknftJ7gVTdhyF5AiilF7eBtqSJaYiDViTII6EmOSZDNdloKJMUmi
VSGCgCdvVAoYew6TJSuKpkaWjDN1fro9XAtTyYxLZlwyYznqkhm/UmZ8ndGin9Gwq2Lo9Z3e
Sl4MvZ6Lxk82VBSWDxf1ggXg4EH5rJn7g+TvFqv7piH5gjeBl6Dd1wzaFZnpXE/ylhlywbm5
GVYg+f89JlYKq0owsXIzEmJi9/CFEeO/b5apse5tGtZ0rpKzvXrOxiby9fK1Al8lJNevccA3
gQtyOn7b9zN3e2fXCIl/Zu2Q5Oz6odHS0jH/fm2h67yFMgld5y2UqbzzW/zO72oS8FRNAp6q
6wBP1XWAp4O8sFvqom4r56LuMHxlym2f8Wu8yDsGPJFwGDiAL8GknIhE65SRlqBzHtgHTjHG
V6Yb/z3Cl7XvbeF7y6uzS7TtAaJt2VaTx9q+xRu0+XhwoC6PK3hzL3H4SMp7cQwKlCSKQdlB
w4VMAyyTQONZRpGmlx7b0mP7Qh7bq0cBj63sPiDFFCiBG9m2LuL/4L+VhnUCJrQ4cWKZSDb7
5TzI3BVcfmkiwUXLL01CLpr9nCT325M1uBeasKUaRIooRu3hbaj/D1h6MaIMkl2Wa4lWFE2N
LFmK2R08CDElng+1maXMKGVGKTNkqUuZ8SplRmlmEGZ2pZmhNDOUZgZRS8H/ysyA1nzTKQtC
35QmguN28GHfqg7ty8XZGyBMDNeZWNPDhdjzNsqCy8Xz7ha5CSP/JjGb0K9N3DlMLlGa4ijN
o6Z2fdO5+UWD4Rh+c4igTQe/BRQ6XZayDlWCx8nwH2kwziuCHDk4H99+MPDVgwE9xTha4bXy
H0Jo8xuXj1QVAsYKZSoxr9tgXrUuNPg/h7w2b4b1G55cLQaEZeijaCcJsaRc3CBH0m7CCsYI
21wwIQPgioIKn2n1CoZXABMY76S+KZNZoGQhICFkinDF+ZkzOELey8zGvjKFedJYGIEogFxO
gBQFccyZa01XYGJZ/sJhY1lew3Fkab6ziirbwIfkAdIScEmKpebzAbi0F4ZQVi+StUtDKtP6
9P8SZengN3eVKdHejfhVCx6TIS8Vci0zGWTcPFzGUUnkPS5qe5ilAPviWYh9YQWoKHPICFGK
pa9Uwn3wVn2lc+xNcU31SBPYiOf4UL8L3Qoo9pIGvg7bDYfde3L0uWUQ98KqDxVWpe/aay59
Pa2s3vo61y2nMRgNCU5guaAp4subZ5F0a+rmPfCOEyTpkWMXYEqTzf17UHQ0yAlDeRI19Tlr
O2RP0Ep7Dove67iCUuHDW0JASrZWsrWSrb0JtiZ5rWtCb8z1jfmzZQDWWweUyMN1jiUaKefx
ktJ7iak4W2GuvRhdJDTzQ77+QKBT/6HdVqB1+eZWIZusUKbScFsabp9e4s4CgXX/Ku8rSPQr
vLQgFZPgm4xnbG+mEBnJRJ41hgop/r+7T0EFEAfZrz9F3ZqlQaU8ebzWk4fINkzkKc8euzl7
wCzoC1nI+MJ98MDsMZEkWznpJGbzUC04Ja5dmI+WuPZtce25F54L6g6EUorIwwWIIFmaCDxU
xei8gnRwTC9GyPTU/wUmX4woljCydKblC4Ho4TcDohf7/5NEm1J+0l+Ms5cacqkhlxqyHNku
NOTIaHKoyvGqr6LUl2W4aqkvl/pyMC715VJffiX68iYv9K7/p6QH3Qocd4EdEyItxwfZYeN7
DAN6uE7rzW1+GR/25vpzXdoH68KW79N/6NGWb2y+W1rIdy2UqXRwlw7uF3Fwy2+DV+nv3tzN
0P29OcP2ru8CY7yZZI1jfBuhUjqg5Q+CpXntMMxrBZb7ZpLS+Jas0JhM51NPup0rB5DNo324
FrKSC5ZcsOSCgmNackEBLij1fcC/UEsDBBQAAAAIAGNvVEI0zK485RAAAO2jAAAVAAAAYnVp
bGRjaGtfd25ldF94ODYubG9n7V3rcptGFP7fmb4D0z+9xVhaJ46jGXcqS7KrRhePpNRpqw6D
YGVTI6CAbLlP37MXWBDIsLq0sqtMAuzZc/bGXr799ohcfGp3mjWltdBnlmM5t4pRG9/dIsW0
fGyErv+khD7GytT1lall40AJXcVwZx48q19+Uf3hYm7ZJrG7xQ729RCbXM9yeFLjBXY8w1K+
S/4hpl87M/0eq3iBlWPHtd1bV6Gl6Q6vzoeh66nKkcUk2nV9ODwnl4rS63favY/nVYUG+73O
r/DcrX9sNdsDbdDq1EftX1raqK9d1IdEdv41yStKuKZc+66Bg4BXVZTvyy9Qyco8TEwtMALL
c/1wuVboX6wVWl2rbEHTjaD1RtqoPrhqjbRfWoNhu99Thq2RMuorN8PKCSQtoVv9ATqE96Sw
ZlQtZ5Fu2LE7+dO4u9ceHRxqi7PTsXUCl1h7SlOo0oYmCVl6aKlUFoT6zAMF5Wgql6JypCsg
Vo5M5Tvl6F6pqh+UowelolarakVFUD1eZNZGcZGzrZabE1eKyj5kxbyVLOPvv2A/sFznDyWA
gQYPyqMV3ilN33rAPsSdV9AxqsDf6smbZMmzTYVSTbVmTZJtttRYcQ3XTXq9qpadW2hRYKYi
RdnrSSZZ0PKzjYP3e5KB8snOF+V1o4HK8kkOVCpZ0fVi7Wn+gKkWDn94S2V69vLYkyuc5JAr
k+K6I01i/pVpn9U1FNPmukmvW9UGBS8k42967vDJMb6NSmBbE3tqBurpOPCNMenmNtYAB2kA
frRHyzHdx0C7x76D7TXnmSjmmDYoSdK8H78/rUD5Tk/O3qmV8cRyxiQh8jZUE0+XB3GVD+Li
gZs/Ha1RV9Ids42WXu22M0OVr1zhrARlIk0gX9uawuaj6/roJ8UKFFU9hr/wWo5lZ67yumQ+
spUf5QubP0gMW/UDjyTbtQzfDdxpqHwz+FY5QUcTK1Qax43vv1f6XmjNrL9Jq7GXi32Fjyil
+k6FLnlSeY8+qKjynoL/swqkz8aP9+Rbt3eQZuNbReTQoONWJyNRVZS6bStUK1B8HGD/AZt0
UoF6Hl+6X22pqsdfkTQhxQa7d0fs/kmLntpEjT+q0T16YO/WcoxjLthSsXhqjdr4xnKazY/p
IQ75jXXP2pISzCBbUjL8kCk1tc9np9p5lYdIjeLAcNTUGvVOhwcb/V6zPYIOrf1U7zVh7F7F
mtDnP10nQ+3ecHRe4eGbdu8EnVcrURiGSPWzRgRCoTeKzTWqrzFhZVF5V0FCD8YUl6W12y0i
Pq2cJPPUOq16T4PCal14iDNotn7piMDFlchZY+O43vip3Wtp2jlrPh57ed0/r8RJXA9ajfqo
pUG8dvmp1yANM4xT6g4bWq/fvx7FTdJstqMJgVegEjeAwW6/GbVH4073tfCIC2x+987Yw9UT
v8+YxpExCUIf+iwT33zm97dc7W92v3NDTw+NOxZq/RQcGUdcYxA9XPL7kGf5nt37Jr9b/P50
FCmIltY+tga9Voe1Hhd/7DYvtW795/4gqrY2HA1Ip6lUUyrtXo5K5QPTeTTfwjsVz4jnGj55
2LRsXpbLgpE1ftR9wneorAXUsU6aTadIQtNt69bBpjYF6kM1VkTOdNt2jUy0oQcZmZknhIL4
eIadkMaQrGwrCDUT2zjEadktTC66A+AILyk7+DEt8FxP8+bBXVr61xz7T1QET3PM8xACko4I
ZdTplYZJv5rMp1PsszSWpVFJoQzhUlSchxAlMgqW6x5kKi6kAETuRTBOGPCqcc/TEIJ0NG0c
0kpCFJeCdITVvYDEPtcN6F5gBstboE9hxbuDIQx/3elUOW4sBPJr0yWaLD7knzoGLm3mOqRX
2nMT58nG3nxiWwaNEksTxBJRMedQuMZsqABry4YKj+Z0fD+DC/A0hUsUzDIzBS6WWKfiNUpJ
LFArFiexMCnJVSm5IqVWI7ES5a9CyytQzuqjwJ8Viw/EREtPtOysXnKi5UYhCKr4vY9Dz9fw
bG7rMBpAQckI9WAWd2oxefGeXA8CPJsQyF9bYYkYai1REgFIU5NilNkOYCraCKaiCKYW140g
UMQRKIrwJn+kKeWNaCJ/ZqST6Oxop+JSIx4UyyDLrSjB4N6SUnIWKNamYBWlwCpKglWUBqto
NVhFKbCKlsAqWgKraBmsohRYRSvBKsoBqygfrKJnwCqKwKoIXLBqPAtWUQxWI81mRyTRa7Yu
Pl3RwFGT7cl7n7oXUFLEhVlAhwogL1qCvOg5yMuiSQ9PQ14usPndO2MPV0/8PiMaKciLKNTl
0X+zu4C6KIa6XGMQPVzy+5Bnxbt+3+T3KPx0lFa4NIvH45ipZuGveKNZ2HtOBkExaEYlQDNK
gGaUAM0oBZqRJGgGfTU6zzDiR21qusmglw7iBeH2qAQ/wCtx6OOtE4YTO9KbzBlWnuEZHD8m
rU38YBkYgHOI/alu4IRFJi5pdwczfACkVVJGewTfxKfymNx60JVIGUkdmTRGf1nwzqKW0Hsk
zML3KEbgdy7JAniSvWhUoSYQPZMlIX3KyousBMYXwWwK5CoSEG+L6WSQvxBnof9yHMmbpcze
+nJ8sjBBph0zWwGWFOs1TOWKnaAwmGBiVVVTVC8PJ3cPcViUjfUkFpXaSwiJUOa9U0SJnYWQ
sXo9V0SFlIaxpLDYK8fuPKwJypFOHzEKoArtKxjmrdrb6oezN29h7oTLyXty+QCX03dweV8h
FxJ79p5cIAIhAndvPpNtCJDK+twOaWIz3bizHFyzYKraHv8ICeQTkB1r4uvgUdDVHf02AeQ+
pHDcFkjGLVVkxWaQweldZ8T2lTvNCgD4TtM3d51BPAtvPZf0hL79N56zNuywEjBr7S7xaMXa
XQ50Ft168nS929X7pYnvpN1pyjttEnLdfouI1X5XbZ6LRbY/qkQ2O3m/IvkdveRgl/NasPNJ
TYC4HSW9i5dK0eDO2pwkvsNiR8B2R8knezn6YeVWTyD0FZFLm71ImN3tiQix3aPCXIyOcjF6
iV0/iyOovRRJGqNmtCZq3pTzXH9rQa1vPtN7aodBJaldBpOARo03DzxSWYkWWiK0JfwtpbTJ
blvSwpO2YFvrskZs11xWm22My2qzMVVWm217y2rnD2aZtwdF28Q8OSFImiWmDJm2TE4q8aSm
NHzMphWbDebyidH5A9ZSBXTAz03CEC/oFrwDkxfJGSblXTjkI4V4bHFf0l6fiCqR/1anU+zJ
Veg1CyVNeaDRxuCV2qlTfl7NiutT6Jn2rznl+wat75GtvK18AA5/+HmoXQ/6jdZwCERxfQBn
BKNWY/Rp0Dr/6quvoPfAVWF6PGki550peApINI3/dThqdbVGv3sNDXDRaWnQMq3uRedXrVfv
0sTipUe9YTBAHT4FIZ6RlwjjYGJjnlenKLFO+dRY0WP7qF1IeWj8sQ9+l67EAILV8XUcMq9z
xhyfEcXnQ0rmcCjnYOi5Q6HkgdDqwyDI++AZsZZnhBp3XCPLvfKhQ58HOHDnvoGzR+qnalU9
/VA5Uyubs7AxbJZFzDDXpKnpcvgZMstlndsRSajbdN3YIfF83G3BvFmDNeSqdU4uSlI6an0e
nashXoRMPGzRkVFr99qjNyaTwdCoDVqXItBu0MBG6JxY9xqDVrfVG9U7tV6fyXzYjuoBZoFe
v9m6rH/qjDrtCya5+czuJp7MbxOP5MiwZjy8mVqLuffGM/VQZ7EPrFVrpyrP1A0youncodSt
p5vwe8PaOyqNXKZYwDMn5AeG0LABb6dRvfGxVlm8rcCfN5VFFW68PNTZn6cxnwR0Wag5egji
NzA0EIuaQC1rxC42hN7gP9UuF+zXAi0S+vGMRq3RV8GszPZFwDJJCx+XzmNpi1TWjMXJW5Ct
0hpW3lpWbMskY8i2TTIWbOskY8H2KDIWbAslY5G/jZJ9w1DMTZNIbqfWME1sqWTbOLmtik3z
f0NDkMCYJMCMLyiX2n+ACtvu40eynypv7IRucO87tpzVnS5p8DizQBDbxOt8xiZGBNSOwILx
jTntmP7atokZUK7MTgjncGTiljN7NGfwey05m0FoQxnlbFSV/H2071hQny+0+2QbpxAjnLWn
jtrlsoKVa+6Z3AZtceMFW8VXufEq/ePhww7sdezACl/4hjutQoXCnVahAt1gxf2SnBZsvMHa
lLCn7tcSjcz9sF+Ix3Vhdf5L1+vCwhV7MJdyry6lVMq9upTSwav64FW9b17VhUNt/EIcpaEi
3Kk4CgDCLHeusdWvm6x3rlF4ThMVdJ1zjSWqUOblM6UsZyi3MsbkIVqfPNx0BcwjD1E+eYhy
yEOUJA+RIA+3cLSfIQ9RkjxEy+Sh8AYQ5CF6ljxEy+QhypKHKJc8REnyEC2Th2gleYgS5CHK
MIRoNZ2IIvLwKkiRhzRqk95L7Ncw9fHapvx0utwmN4dGKW8c0ShyVne6pAGjUeRslmkMBMxA
CTJKLpPodUhaCV5huwe6r5pXKPP9oAOv8Ip4BXjhr4lX2IODW8IrSDTyC/rgUJnqiI8KPfMJ
oSyvUH2eV6jm8ApULNehiz/jU+qrQaWUSn01qJTS4dNCm31aKOIVqkleoZrHK1TzeIX9/kDR
Fj5MZBV9mIgLLk2JoTZ+CV8tinkFEo4CZf0l4SODcA68996SrJhy/o9bPoZjRXi1oJlVL3cU
pFUOyPkVIWf2Sl8obl7DNVLUeX8P8Fj5XsnxHavMXh7esaK9oqO7w+eTDgd9L/+gjw1LyWO+
1/AVJVF5fka4JMtxqJfZypQ+JYNUSpySHVzs/5cu9slTskKn++iUrNDFvrjfid5L7dcw9fHa
pq/d2biUTcbZV+qUrGQm0euQtBKnZGX8KRy8324UDt6u90Tx1p5pFK8NTO/gPyG5Mhz8J/L9
Jy4XpfwnpPovSUPWXDBbm9m/dm8K2R+WwI9S1rZN9Ay5Mv873hy78suAHF4lxVzwP1cdSOV1
SOWjpnZ13bn+RYNmGb7bR47ZwS/eKYP2zuLzNPK/yRmuM7Vu9/cwTZRxD31MHPwaXEscvH8e
JQ4+OJIcHEm26UiSXngOviWxb0nxoHspLiVk2TPiRy1cJEN+KuRaZjLI5irujxKlJO26QRaH
zLL10g9FRU3260RUlOs/Pw49HEtu8VhS60Lh//NTyeb1sH4toqsbnlX+N6eTYohIHk3u0SGj
qAM/YUwK6GwtJvscVrlkS4h4YpomlEvP6Qc2+ZWwyc7CoNQRC82wf4trqk+yYY1XknNGMasc
Bjr0a8yr8OToM8sg3PMy5wy9K3DtJOlMtKIkK0keeqZbTmMwgv+O3A/nHo0p2U1FvBz5q5sP
MEBPkBzryD6bJGs1Cx5gUdVAERrxhJSziJAFdWEq+5O1mH+VM1tiVBNAMxF0rTKuzcHdPAQu
wwEwtL9cTKKQcti4+sMSzo7hcjbll46XE1XZL8CcKNgBMR8Q8wExJxFzyTHyIiBzohIcMyck
dG0q/h8jCHYu2yYJhSx6Lj/FH+DzAT7vAXwu7KcJhQOA3hRAQ+PrnqQjg+c++p7vTuWs0mB9
ea4rQYKzuKzDWakDwYMP8sEHefs+yGX6KjErb+FjWQuIk7MAqm4NI38dI9h7r2HFtlgHD+oN
PpfsmFawps/17r5w/CwB86hboeN62DFBaDkBzMc2fsBQ//3lY1aXWY6e4VxMYaovnZqRrNl/
xtRIlrOYbinFyZRSOhA3B+JmH4kbySHzInic1XXitM5qhdyz0DWbarV+lu1ZexE5kD8H8mcP
yB/Zbrta/0ANcRtjeju79WULmYLu/wBQSwMEFAAAAAgATW9UQhEoWi8KEQAAUJQAABQAAABi
dWlsZGNoa193eHBfeDg2LmxvZ+0d2XLiRvA9VfkH1b7kWgsY73q9VDkVDLJDFoMLcNZJSKmE
NNiKhaRIwsb5+vQc0kgILA1H1nZIOWiO7p67e/qQ9vSq3WnVFW1uTG3Xdm8Usz66vUGKZQfY
jLzgUYkCjJWJFygT28GhEnmK6U19SKtff+UZZqDY7r3h2JYRYSXwvKg+Pz4yb++UijGLPNPB
hvv3DM/w11/Vfjyd2Y5FGrnBLg4AwWJEgQRvdzTHrm/ayvfp/wjqN+7UuMMqnmOl4nqOd+Mp
tOsXg/OTQeT5qnJgsxL9sjEYnJCfqtLtddrdTyc1hWZ73c5vkL5ofNJa7b7e1zqNYftXTR/2
9NPGgJSdfEPaignXlcvAM3EYQpez/fv6K1RyMPdjSw/N0Pa9IFocFfoPR4VWjyrf0ewk6N2h
Pmz0z7Wh/qvWH7R7XWWgDZVhT/nc7l5fAm05YNg//qPCmlRtd76iEyNv/BfsI/1h7uuwpUb2
IfwkWBPoI6fEliRNiZUsJZAAT2hXanTNCB3biGyVloWRMfUBQDmYrNc15cBQoFg5sJTvlYN7
parWampVRaTL+RZrmRalhpBt6E6pqR/T7ZHRDBjpmzVH8sevOAhtz/1TCYEdQEJ5sKNbpRXY
9ziAupMqqqAq/NUO36aGmTQrN5z1Wit7FF38vE8g9G/9swTI6RNAS5auLq9a4wQUE0zvxxIb
sQTB9XZE7ccmFVGkuW+73uDRNb+L23XssTOxQvVoFAbmiCyBg3WQdjqIOP3Bdi3vIdTvcOBi
Z00pFNdU6OQRktbd6MNRFfp3dHj8Xq2OxrY7IoTIzKsWnixusBrfYMWbarmwWmOsZInyk5Y9
vts5PeUHV3hioE+SJ6b2o/zU1BVG8rIx/FmxQ0VVK/AHa1iRlpPK1FEqoTHBIb5VKib8eZOJ
UmnOxaZp0yMAT5X8r47gsjX13JHtms7MwsvKRv5s7NgmrRLjglpSVMh/AaZZH3223VbrU2aX
EgIjw7c3BIDNvyHAgzUZ3U3hB8Tb05Am3LEqv08V+IFetfTr4yP9pAYpMlBIQGowbOnNRqcD
yWav22oPYZn0nxvdFmzJcwoLq3h1CSmWbHcHw5MqpGEND9FJrUrSsNK1ax0yvKI7pJg6hdFZ
QXVefV+tsXrYDjwvoNoaKTqqHirwHyevd7RGV4fO6BeQAJqkpqX92qHkW6fnrBmd7blG8+d2
V9P1EzYdUHN22TupAs6ZV7jso8gPdDydOSAtVahXcoVGOKWXkxXzfQo8jBAjKgD9MR3lJ/nD
tbRvpqMGoU8PTCMM8XRMmFJ9RRfRWl1kM/NE62TsF7YZeKE3iZRv+98ph+hgbEdKs9L84Qel
50f21P6H8CPGNnGgcFml1KDxqnpY/YA+qqj6gSpPx1WgzyST/xjYN7dAs/mdkrQAVAK4kBlE
xqmK0nAchUKFSgDMIrjHlkq5l0NW98125rnyhpAEgk32vBiy55XOUpwZ8aQaP0WiAn9w7iq8
YDu9ghXdwcSjDSe+kAtuCQi44ZaATKbHCT7Ic2SOeUawQ57Ns0QGGbPFOCc4I80L7hjnBYcU
AN1hgp7nlKxGcEtRlueYpHgVyyR1nGmKzCkfxmrmSWpjBpqQuOxrzcZQ06FeP7vqNsnEDBJK
F4Om3u31LofJlLRa7Vjy8wFUUTwBJnv8btYfzFsj0KMDXuDwp3/MEueP/DllEAfmOIwC2O6s
+PM1f77jYP+w560X+UZk3rKc9nN4YB5wiH6cOOPPAW/yA3v2LP60+fPxIAYQM61/0vpdrcNm
jxd/umid6ReNX3r9eNj6YNgnm6Zay4C0u0tAqh8ZzIP1DtZUpBFvNXr0sWU7vC9nBSdr9GAE
xH6lwgygmE0W8nrOAdWRQSbZoBqGDsasGxdb+gQMX6q5onJqOI5n5qpNI8yVWcsKodsBnmI3
ojWkKccOI93CDo5wtuwGR7rhgs6OF4Bd/JAt8D1f92fhbbYUzG/BIy2ihjjehiggdEQuB05/
aZ7swvFsMsEBo7FYGvcU+hAtVCVtiKJUQ+Hi2MPcwEUp3AXuRDYhDDqrecdpiIJsNZ0cMkui
KOkFbBsuClEs+HhSZc/8xZvsndUbh2Ctvq7T6vyVnRaXubYDXBlxsxUgEDdbAkpf5YuhqQRD
GQmG0hIMZSUYWi3BUEaCoQUJhhYkGFqUYCgjwdBKCYaWSDC0XIKhJyQYiiWYyJyyYTwpwVAi
wWLIVkeQ6La006tzmjloMZW8e3VxCj1FvDDP5VGBHEQLchA9JQdZNdngWTnICxz+9I9Z4vyR
P6cEIiMHEZV/vPof9hTyDyXyj0P048QZfw54U3zr9yz+jPOPB1mAM6vwOI4YZF4kigXNi8IT
cgaKBSkqIUhRSpCilCBFGUGKpAWposb2WTNJ6hPLS2f9bBbPiWGZluB7WBGXJm/cKBo7Mdx4
xiTiFE/BxZTGtvC9bWIQjxEOJoaJUxi5ujTeLdzZQzBZpcvohuCaRqaN8Y0fABXO9eMBEnb+
hKgX9ULWs8K8sCdkxWQlUHnpz6oWxH8G34/xl90HRE0sC1lJ7kaQkBQrJCDFLYGVpa8JDJEv
pKilTYlsHpv8cmS29Kwyd4UQxfk7BENni78IJzogytK9CHPzyfeaqM1P5DlzHzDd0sKqSkX/
yp2ZMTQDMMmn7yhJnnVWDGYFrcwVRpSIoWYvMYzi4v4XgGw6Sowse06kjD5koEoFbjBKxZtF
dWEapVwxudpQgPY5cC+t/q728fjtO5AJ8HP4gfx8hJ+j9/DzoUp+SO3xB/IDFQjVFKL1EAMp
WMqNmRNRYlPDvLVdXLehO1uzOwH+ctNPxx4HBvjCLwzXuEkZHD5m7A1bMO9sZxwrLqXM0Lfj
dhi33GVLwGF3Sd7aMf2E92+7kawU2fpiL5E/uxsCsLyd0Y5l4s4aoHx329SpQN3R0lLau5hz
SniX80F+tz4d4kaxo/leet3Z+mESrexiaQX13axvuENWFu6aj4lb4G4o72A96ZVxV/NNaO+u
0/GFeDfU07sb/ZhTIUlh/nYt5ZZcuEQXGxtYFblVl/FnJrdatOatdjPfGfpx/Zs/xf58TZ8Z
BYCWZJQAVgIQdT47kKRlxRO04AovH7MmA0wMAXIIviwC0+tL4jCVviQwU+FLAjMdtyQw08pL
Ai/XxCUWDfq1AXZaz5bDSmnYErOYZjQUi3GVADNW47DjW5oW5Rcg8BQAgWC68nh4TlXiDrAp
0i5wz11EayOFRIXxWMpujxRV4xixTqc4Wqxs3HZisaFzwQe104jtZSMrHk9h9Nt/FbEN5qDA
pCM+cJR31Y/gKhhcD/TLfq+pDQZgkG70wRUx1JrDq7528ubNG9g/8KswOE6blPPtFD6GpJrW
/zYYahd6s3dxCVNw2tF0mBvt4rTzm95tXFBiibBRPzOJrQ4ewwhPyTLCORg7mLfVKSLWKU+N
dT3BjyeG9IfWVwKI7vTKnyAQh68jHm2dcLTEE5V4oZScC2qJ++kp11Pa7bTa5QRt72Mo14mh
VJN9S663Wzz+wLJe5fEv+0rFng+8Dj6QXu+XyRDoMU+2pZl3efADQtN9HHqzwMT5iMsjtaYe
faweq9XNnR+S+rKUqgxMJ+szKqU4u3dccd54bjZVoUvPDQlxLr9PV8Y6t2MnheHQK/IOfV6V
Cw0kRB2uy+faCflR0qVD7Xp4okZ4HrHigUbPfr3dbQ/fWqwMDn+9r52JTLtJMxsZHgh2t9nX
LrTusNGpd3usLAADmRFilun2WtpZ46oz7LRPWcnna/a08Hh2k0qSGIy6ef92Ys9n/lsfXpY1
WO09m9X6kcob9cJc0WTmUteRb1jwkm79PS2NXyNhGd8ak7dyYWJDPk/DRvNTvTp/V4X/3lbn
NXjw/tB3p1iaOu0A6hgERhjNxvXlLywRTjiCfTMiMO9rSIW2eCdm45BK0LprRED3LUDzXo9h
muqk4aRl2E7BY/1szt7e0kjup2NaJX+YAauEZUcosHIIAS7bwoLtqCQWq5JGIDYkeSR/HSRm
S5LAY/YkCQRmU5JAYPYbCQRmW5JAWG5fklxY6OOGFNJ2JnnMlK1JcnbT9qYE82mOwHBPqR+o
dw+DdbyHT8TQVBrXjbzwLnAdKaRbQw7+YWpDPkFJhGkOJVGUKB7RlkafrUnHCtbGTTE7qS67
EYQMEB4vhfVgTeFFWSmUfuRAB6VQVJX8PTi3LGvM5vpden7Td2fysmsmGEiqJRBwM9+iKM/x
vaDkTYPyV67Km7UizbcSS57u2+sJKt+Hie/DxJ9bmHj6pMnFiz+vyG8YB4+SjjNS2qjQ1CWm
hsHkVXYpxVbo7utrtpvKhmWaLVqu2aIlmi1Ka7ZIaLZbcKnnNFuU1mzRomYrvPBCs0VParZo
UbNFec0WLdVsUVqzRYuaLVqp2aKUZoty2ifaVNdFq3VdFGu252FGs6VVG2x+gi6PGeB1MbmH
udS9bMmNvzRufOOXQro15ODZjV8KZfHGjeAeW6wxSTURL4McUvoOXCvlv4YPy4DmuXu//Abe
eNFNad/10hnYxYee1ht6oeNe/kNP23TBw8SzeX+1njg2vFVnVkDs3XGvyB3HlvRlOuPW8M6L
Ib807x3xUJVdOu6f2m4QArDfV8n6nv6c3p7ZrcPsDlr6+WXn8lcdpmXw/jnyPhe/9AgEujnN
l/C9rUJ+Jb6otfz7WSs/I/LEBiDV+U1AiyWEYPH3okp9nqoUUKnPU5UCSgvGYuhdffFq8/CP
zDezNg4Hea1f3IoN0bW0Ibq2zBBdW2aIft7f7Uq+1yVlQCWXpUJez29J638IzC76EBgvOLPK
spvRyk+E0XVY9T2UZ/5hMYBfvHyb1CazUPZCXJUufnYeShfvHZN7x+QWHZPZC/zeV5n4KgvP
3EtxURL1wUySejRP54JMzrOtdJZxKu7fjCmRdEJqra/hEI9PaTmZNsgWuzwZ3CqH5z6U938c
ypt2eO4+uLd0KK/s9ickJLGFNX8j9H3A43MLeJRwv5ZrYiGaMCUjCh2r5N9ZMT13Yt88X6+q
6KO0S1UISEmRRxTUXPNSr5psQzXaVHBx1ajUQL6YjU9060sb+HZlaPu/fFo+begC6tD5L27n
al0OGpeiurah9Wsr36eXNkuJEyJnk3pG1iUxBG5aEgWJbiJ0F0lmLfSTchMmqolwy6omZdn+
Xi95JXqJOzepg5rlpji4wXU1IM2wySupvaBEP4lCA3Y/5kN4dOFfIDWJFrOofMDmCj1n8dVC
SnLx3cKpYbvN/hD+rbkgmvm0ptwuFdVSeoBh3cMhPkRSt1D2apYk0jS8B6mrA9ycfues6GoO
wGlEqbbWe/Uodbne2jfRCKsqNlSxqrz1pIzrZB8nvo8Tf4Zx4iW2OsEqjRBgSQSokkIAY6k8
TrAGDqio8kjstrSPcI8ZuxyWZYfrhcSXeQ+0XB9kYuDD21kE8RkurPjztdWkOiltrHly9A+G
Hbmej10LCm03BPnl4HsMS/98Y+JX91k+Tr7sBYMYrvJr8cItV6mRPCvTVapfe9vV3na1t12l
bFfljsiLMF6lxsCtV6kSyVeHCX8uFA9PsOuXEIMlN7AvFpcl183iuKhSYVilgPYRVluMsKLM
XDrAatvRVIvMfMMYqy8TVSV3Yl5EpNXqIfEAqtUAm3opCkRjuj7vpyh9y+eWQCkhJbq63sKv
Bs8PZF1xuHfA7B0wz8ABE0oc4r0LZl0XDEy64csFRfneQ+AH3kQKKWWP27tOXrrrJMVY0DLG
UtLBwhkLSjMWtMhY0BOMBeUZC1rOWGjNeuJwNbiUeyBmO1JWbMZ2JJGWsB0kz3bKtWVObqY3
gWQHM7zgX1BLAwQUAAAACABucFRCS2sYzd0RAADkzwAAFgAAAGJ1aWxkZnJlX3dsaF9hbWQ2
NC5sb2ftHf1z6kTwd2f8HzL+4tdrCmnt8+HUkQKtKNAOoO+pOJmQHDQ2JJiElvrXu/eRXEKg
uQvggxrnSe72dve+d/f2NunVL+1Os6a0lsbMdm13qpi10f1UUyzbR2bo+c9K6COkTDxfmdgO
CpTQU0xvNoe0+uknnmH6iu0+Go5tGSFSfM8La8bMujif+Eg5NRahZzrIcP9eoAX69JPq91cL
27FwNVPkIh9ILMoWmLCaR0vkzk1b+Sr5Hyb93J0ZD0hFS2Dseo439RTS+O7g5nIQenNVObEp
RL+rDwaX+Kei9G477d7Pl1WFZG97nd8g3a3/3Gq2+3q/1akP27+29OGtflUfYNjl57iuiHFN
ufM9EwUBNDndvk8/0QQ78zi29MAM7Lnnh6u90v7DXmmbe5VtKB4EmOf5s0K7q9ruMj0AI2/8
F0yy/uTc62TGR/Q3xp8QHlUyJJiVbYS2SmBBaMzmgKCcTGR5KieGUu82L86VE0v5Sjl5UKrq
O+XkUamo1apaUTVcwYDyn0oz/+NX5Ae25/6pBLD4IaE82eG90vTtR+RD2WVFO9Uq8K969oZX
qLGRokMYj1R2UDe1ICaciG8Rwhf2J+Z70Hsl2VA8VtkVoaVWROGxSy+N9JrQ4jVRnH3RxSE2
ny46bOEA7YPJzl3pMNFiw8m3DWWeZEYgm3iw0gICRq6B6eUkIGIk2RddThL7R2gQpbeNGNdi
3at+3yC2Ba7xi543eHbNL6OqHXvsTKxAvRgFvjnCy9NBOpgpOtgm+pPtWt5ToD8g30VOQYEY
lZySQcQsrYfR24sKtO/i7Ntv1MpobLsjzAjPgGqhyermq7LNl7/h1svNAn3Fs5QdtLTq241k
Ee9crjSBNuEhkO9tTRnW+zet4V19+KNiB4qqnsI/mJZTsvEbtdF72202f05P25XtshWKDVby
YzrKD/LVb1r4pqP6wZxsxZkDW+nUVE4bS76g2hQNEir+Xx2BCT3z3JHtms7CQutgo/li7Ngm
KeJNhFIMEjFsAG39cGAeI2Nub4kAm2NLhCdrMnqYwQ/YcC9jmmDkKKe/Q4ua+vt27+IcJ4jU
0iFFxZcCqcZtr9ketm97+o/1XhMW681lFcC9of7LHaRost0bDC8rkAZOZ9pltYLTem9Y/aBD
hhX0hoRSJzg6BVSWlYuo/NdWn+U5VruFQW8BRBpDgZ1WvadDY/QuJAjP5tUNVI8TrV87tBad
7pd648d2r6Xrl3QcAOfaE5nq0f3zHPmm4TgqICirMCOYkaVZDwI0G2M5UVuPU/2+a5u+F3iT
UPmi/6XSOG18/bVyOw/tmf0P3sFU0CBfYdJdqX6jwlSdVd5q71St8pacE5cX51SSz599e3oP
rBpfKpxxg6hIA+sEVVHqjqMQrEDxUYD8R2SpRDQ4uPOf7WyLnn6GuQLPBn12h/T5i05T8R5l
GTV68sQp/IPFeMoAO2sa5pe7F3eEBHtyR0gmPSTGOxJn+K5kOZLB6Q17ExdF+zPK8S1K8nyb
kny8VSMA3640l92yFI9vWw7LbF0K3rR3cRnbtjSzeetGXWm2rn65ifvVbLZ1aMEABoG1ohL3
wqSP383ak3lv+Hp4wgAOe86/pYmbZ/I8McdB6MNyo9D3H9jzPJ1v/RicmCeMsh8lrtlzwHi/
pc/bZcAKOlEBHw/951a/1+rQ/jLwz93mtd6t/3Tbj/qlD4Z9PLWVagql3VuDUnlHcUKQQpbt
sMY9WecXlTOe1lgbrnMW/+jJ8LEHS70n+OrIwANkEONTBwfV1EWWDtsPqeaGwhkIQs/MFJtG
kIFZ64DQEB/NkBuSElyVYwehbiEHhSgNm6JQN1w4MKAVZBc9pQFzb67PF8F9GgoONf+ZgIhr
jdXBAZgPz2XQyS/J4xU0XkwmyKc8VqFRS6EN4UpRXAcHJSoKVvseZDrOoaCTHng2ZgzHGvOB
8eCAdDEZHDxKHBS3Ai+EzasAdGJBi5Eq43xjcGfaVNtKm2qRNhVpPlaUGlOUGleLLEO4rTNX
MfwFMxYXZ01ZAhY0ZwFVRAHuBAkU4I6QkiZuPjbRqVpSp2oJncpyJAPpzTpVS+lUbUWnais6
VVvVqVpKp2obdaq2Rqdq63Wq9oJO1ZI6VXtRp2pcp0aozQ7QZUtOmvTw2vulewXN0xgwq8a0
lzQzLcarNK2ZGcCBZ6SZNaaZtZRm1ohGZs8P8Iw1MqPoR4lr9hwwnniVUo3MCjrpgmtLZNOw
bZvV03zks/r5Eq/UfO2uCWh3LaXdtYR21xLaXZPU7oCvRm57M07qE8tLZufpLFpixxyBoMfQ
vHdJcuqG4diJ8MYLqtRnaAY3X0lqCz3aJgINHyJ/YpgoQZEpS9LdgzAOwCGTapgB1bMjQaqO
8XQOywa3Efcx6iBWYi9YK7ycmysUmLVXMFs+WDFW1oChRSsWTIp+HtGvM2l4SaTOKSRj1MQs
+QxxTG7oUFjS0qGEbCJ5KamKZ7PU+JcR06mnhRkriIOzZhAlp5O/iscbwGHJVgSZ8aRrjZdm
B5K791R6GuU2E2WxcY3GyLxZaZOKdyRLzdE59YrFxWG0j5RhZulLuuZwx5RTsBOUU28R1riL
jyLGFgTBaN+A7GnVzqvvvn1zDjIbfs7e4p938HPxDfy8reAfXPrtW/wDBZpWfXNerRAY/GjV
+OfsGwVLauy5A/eusXBCUsvMMO9tF9GrbWhbaE536T4EFthkzDpgOvbYN+AOvmu4xjRhKL5L
2Yk78LbsrCubzG3imNp/VVQo7rkykKV7rsHafxWxrN9DPWnFsY+5X6N19toRkID7ZB/pw33W
QST0HiogKnV/M03Y72n8Ce89Dwz+3ce4cPtif2O/1v7Zxz7jFe1ppnkFe5vuYL8SL/gPxB03
LPfGfD/TS2zQPY49Zr/Xpkcm9d4qSK567fu1J9G4gB9FpZ2kK7a7kI+ClmJzXtDBGpvLWkFz
eVt36h5OHYTt+w/kmTp8EEj6AEJA5BBCU4BcY4MISQITGsfUrbFUsKQkPvY2SNPMC9BQF4I4
GXUgiOMTn4HccMHZWhyfOgPE8Tec/KUYQAO3Y5A87EsTJkSQ3LgmxRQhpJLKR0aI71YcKgpk
2BEJBMpVASyIWZMiRUtyeu+A+MO1g3TeRzi7puD4KxbR2bvFoEoUjdXp5Mdl5QbrQktT8WRk
OFin9hrSvq5n+f3JjTPLhLT7JmnXiaOcV97BhcDgw0C/6982WoMBuLDrfbhxGLYaw1/6rcvP
PvuMXLXAU2GYNPYMl7BpD54DXEzKfxsMW129cdu9g6ZedVo69KHVver8pvfqXcIuVjPqe6q5
1cFzEKIZHm5YtWMHsbo6ecw64txo02P62MkPhaT81Id4R09qsYMufAWBWGIBWOxSKb5q4pDM
HdOa+6WNd0u4aWUkYMFIQDVeiGbWZco2A0n3UeAtfBNlb9ov1Kp68a7yrVrZ3nkqbR7LWsYg
ZVZc0KKGsvvADOWdSj6Qqq9S8km8EFKKwEMUgQITuKWoy0XIFXW5CETCxesMH8C3lnDbnncl
JByOkpKaEBYulRXk7eiCwnCICbrH66/TbgvEWw3M0ZvWJf5RktBh68PwUg3RMqTgQauBt3Wt
3WsP31gUdns3rPVb1zzTbpDMflwFmG2v0W91W71hvVPr3VKYD/4vI0A007tttq7rv3SGnfYV
hbz/QJ8WGi+miSQO0KiZj28m9nIxfzOHF3kNWvpIh7sGS4kCvGAVtH5h4C06gnmO/AxeiI95
/HbjdLJwyS3U3LBmNnCj0Lk1xq8Ww9QEbKSH9cbPtcryvAL/vaksq/BgDSfvEdF0sBgHRP7X
XCME8JsLNUIbw3DUCF0EgfXkP9eul/RFpBbOkYJCShkIxTwt/JQoTeMjiXpSHh1xMlpahAZ7
dgrRzQvSUQ+PHCn18sjREE+P/DCCM0WOhnp85Gg2eH2kmUBjt2eS9P4UIk54gOTHe9ULJC6U
rsht0O0jdNvxnn7Gzh9xYjf0ggffdeSo7g1JgqeZDQAhGnaAooT4GDV6b006ll+cOCEhhZgk
BgeiDAJjguTInqwZvCoqR9MPnUck1seYRlXxP543Fkv9ITnMSROTvPFJbPoIFqMlhGZN6Q7a
HUWFl19nnrWAt3PB/0dT0ccyLPL+K47jBOfgwrW+wxZIaPjMWek+sPLOsHHznWJYFk3iz22E
94hiYJsYHHI4g3CBDbrSe6SFoAxB9IPfETBMdNjB5wJW4ceNQhdoYH4wt1CkuRCSUKS5EFIZ
YF4GmBcIMBfYD6MjiRmHrrD46ihTnjzLk2d58ixPnnZ58sylKU+e5clT6PBYnjz3ePK8oR8S
I6EOECkm6aHnd5ByBh5FW3MZKevw57eSxe2ubc+k6+wubb3dpa2xu7Sk3aVxu2ufwYEZu0tL
2l3aqt3F4wm53aW9aHdpq3aXlrW7NLGVvmJ3aWvtLm3V7tI22l1awu7SMsaVttkS0yK76yZI
SBVSsN0WwBwKEftoC2IoFZ+ENXpGnDjSM3JU94YkAdUzcjSrUl4DublJX1MJykrlqommJKai
c3AsDr9SmJbCtBSmpTDNbdrHEaZrbNhr+AB5cA+Cc7paVt1YJhytDB9mPY5o5fhTyVWhjsGX
SOH8vP/w8i2Cynkzy0BEiUBEsU8Jl4GIBxuICBNYBiIeUiAiTIhYIOKOZRQVfq9WUtHubRjV
NFIprg5WXNEJOlphVeANEt7r43uRBEs3ifk7im9SCsjoAwgLggaWYUFlWFAZFiS0H15TWNAW
snJbzcBkpYTE59+7f/Hr9llJWX1ZUlbXSEoCljMo8r8vL/Q5eyEkoc/ZCyEljYx87PIL+bJf
yKdSNVuSlarVdVL1P/nOfqHv69uZ7+unC64tib0z2vTxfToBmz7qewyf7E91n33APQUr+EEi
fDshp7fEox2AkVC0g5R9z5stszCS7gaBplPE3IaXN4vlzeJh3SyK713MoRCxj7YgLm8W/8Ob
RZiSIwrTKN81EBam5bsGVJhmXyjIfftA8F2DfCNg1aIgXOQZcPf/thzKSOsDjbSWE+4rZv2h
SuvS9BWW1qXpW5q+pen7cU3fdFBdaW3KyK/S2iytzdLaPHul1uaNTEhxfuQtmKgHHXIL7QN9
UDxq2gTRb3ruxJ4ebsA0b+OuQ/Zg9F5lsB70a4PYY6VleJ54eN5JU7+569z9qsNwDC7+y2g9
F72CmGLoxLFH3blIIJT4cENIoPkHGTsC7XpVQSNlGMjHCANJi+fXERkCO0M6JOSwgjuw1Dfj
pB4ukzk/lfNsK5mlIoWFhBCY/B+nwuI7YzyOjjViOrcLHzFYOrdt+THJQiHQQkhldPNW0c16
F1q88+Dm5t2gfseLq8VCnvcd5Jy7jo8ivpn3gsU4JwBE6cXiWFqk8jg14RHjGPjAvhKiJiGg
y/g0eSf3K72kmyF/imqqj1tABzzn8u5b5vzW4uu5MDBg2yDWu2fXmNkmdoKvXt7Bmgw8J3l7
h7GYPz19oTczbLfRHw7w/fRiTkqEFzfHkLtRM6xHkABnmtxFEv0EnhgVaFNGNQseISNC89LN
GO9pGQRQypdSvpTyZbfyRfJDM4mzaO4tSXC/CMFZ6cIh6XCvSRKNxP3jp2tpWw8fn7NMj/b8
nN+Hj3iAzm9c/rlX6HAshFSeoMsTdMETdP5CPoojdKIb7AydgiQkK93z0sKVH6TFBy6BsuYo
LSOsy7N0aeseqa0rsLoTKK/d2hUiCxCMoTGXjDade08+HJInMVViWMujeynOSnFWirNjFmcr
jgLJ0CBuvwnd19PSNe/oCwYYMYMt7c0oo/8LS78y+n/L6P/U20ukoNBmwIQyND6Sp4FSWRq4
Gi1E5hcjA+9cITp69vxfv7Ww7d8Cci07EHnLIPl3oGT/fg+drUO1mUutUWqNUmuUWqPUGhJk
/4HWuJF8h+vJsEPXmyPXAqDtBiC/HfSIoIeHe1m5uc2S7nR8V5nL82ivLqW79BFvMqXbmn8d
KXRnKYRUXmyWF5sFLzal1/VR3HNu7hW79nwJIf1W9W7/SKn8cG+mWHNZuoW2KO9O5Q9O5WXD
QVw2yC/2zRSv6yrCnExnUz9R0+aOH6ofpxRHpTgqxZHYiB6dOJKKav4XUEsDBBQAAAAIAGRw
VEL5qEOvbRAAAACcAAAUAAAAYnVpbGRmcmVfd2xoX3g4Ni5sb2ftHWtzozbwe2f6H5j70tcF
28o1D8+kU8d2Uvf8yNi+S9q6w2CQHRoMFHDi9Nd39QCBwQH8aJ2cb3IgrXZXD6Td1WrBl59a
7UZVai7UmWEZ1lTSqqP7KZJ0w8Wab7vPku9iLE1sV5oYJvYk35Y0e+ZAWv76q8pPl3PD1And
FFvYVX2sczzD4qxGC2w5miF9H/1HSL+xZuoDlvECSyXLNu2pLdHWdAbXFwPfdmTpyGAQ5aY2
GFyQS1nq9tqt7seLikSzvW77N0h3ah+bjVZf6TfbtWHrc1MZ9pTL2oDALr4hdQWMq9KNa2vY
83hXRfu+/grl7MzjWFc8zTMc2/WXe4X+w16h1b1KNpQMAjw451li3ZUNaxEfgJE9/mviYuXJ
vFcWZycj4xguIfKEMqjQ8SB8DNU3ZArzfHXmAIJ0NCnEUDpSJQBLR7r0vXT0IFXkc+noUSrL
lYpclhHhPWCsp8X4/vEZu55hW39KHkxhSEhPhn8vNVzjEbtQdlFGJVSGv8rxe1Eb4sPDxi0c
nuRIplYfUk0Ip+Q4odg4rcc5PmBipPIvQ1oZLGpS2V6vx2hDYfDCibDmwK07I/KNqoX3WwxA
+2DIM6c3DHeOsSwoBgpwXp7eyaXJ+hJtO4WkMw6RJ1FJsmbT1p1ABQRBdj9eGKCwf8UYrtet
yk91agCQ6r7t2oNnS/suqNc0xuZE9+STkedqIzIRTayALaGAAaE8GZZuP3nKA3YtbK4pgIKS
Eh08wlJ/GJ2elKF9J8dnP8rl0diwRoQRGXlZx5PlZVbhyyx7aaXLqTX6Sh5RctDiam07MiR/
5zLlBrSJDEHx3lalYa1/3Rze1Ia/SIYnyXIJ/uCxlOj8n5lSyVMn2MP3UkmDP3sykUr1hXi0
LTpR4S6T//IIDM6ZbY0MSzPnOk6DjZz52DQ0WiSaCqUElGk9AE69Oro1rEbjY2wuEQYj1TE2
RIApuiHCkz4ZPczgAlbSy5gaqPbS7zMJLtCqhnJ3dqJcVCBFOgoJSA2GDaVea7chWe91G61h
q9dVfql1GzBxrilud6h8uoEUS7a6g+FFGdK3re4xuqiUSVrpDit3CmR4QXdIKRWKozBAeVE+
Cco/N/s8L7BaTQI6BRD84+yVdrPWVaAxSgcSlGfj8hqqJ4nm5zarRWFzt1b/pdVtKsoFGw0o
ubrpUdwrO/Opj3zHVfBsboJil6FcSgBVb8Y0pyn9XHwZpNapmbLrOXQd1DwPz8ZEIlRXVt0x
NNf27Ikvfdv/TjpGR2PDl+ql+g8/SD3HN2bGP2TNMtGCXYnLc6nyowzT4rh8is5lVD6l27ez
MjSCSW/n2TWm98Cz/p0kaqhTXagSPSBLUs00JYrlSS4sVfcR60R9scHIHlvWTyo/TPI03m1n
/ErvCEtgWGf3zpDdPyksxWUHT8rBXSRK8AfLpMQB22kVYZYpIraEBKJiS0ga2xUKIcFzpEc8
I2QFzyblBcMMZEaQE2KD5oXoCPJCfAiE7jAgT4oRhidEiYAlxAkDr5InpIyLEpZZLU5IaSBS
gm41mpefrsM+NhotBVozgAHhLSqHPdLY7Xet+qTdq67iH3GAye/OGUtcP/P7jGEcaWPPd2EO
MvDtHb9/iOev/2H3e9t3VF+7Z7nmL96RdsQx+kHiit8HvOpTdu8tPJ54PgpKxNgpH5v9brPN
xoaDP3YaV0qn9muvH/RbGQz7ZBqUKzGUVjcFpXzOcJ70DyflY5FGvFb/2cG6YfK2XGWsldGT
6hKXlcy6Lo9UMm4qNWQV1TSmFtYVWKpY1lYUzlTTtLVEsaZ6CZieBoSGuHiGLZ+WkKpMw/MV
HZvYx3HYFPuKasGOAy8hW/gpDnBsR3Hm3n0c+vccu88UBKk55nUIAOEjcgl0eqV5MrHG88kE
u4zHMjRoKbTBXyoK6xCgSEXect+9RMcFFLTeg8iGjGFrpD1wHgIQL6aDQ0ZJgMJWkImwehaA
+tqBQkUbKlSuHzNVKlF9iKs+FCg6nqSM0uxiAn/BXibFSZuZgvPYzYCXR6VtBQlU2paQorZ0
NjbVkiimJVFUS6K4lkSrtSSKaUm0pCXRkpZEy1oSxbQkWqklUYqWROlaEr2gJVFUS6IXtSSK
aEkktGRA1mgDj2TJUYNtXbufOpfQVMSBScWDXtK1rJjM2Liu5QCT350zlrh+5vcZwYjpWkR1
LL/fcbR/2F3oWBTqWI7RDxJX/D7gVZI5HehYxHRsvORKz1xgI4aZVLviESXV7QWZ1dnKGuVQ
1iiirFFEWaOYskYFlTXgy4HDXguTykS3o1knnsUL4qijEPwIj8Kiyanl+2MzwBvPmY6e4Rmc
XEWpdfxoaBgUto/diarhCEWiLEp3DwLbA19NFEZnAt8NxOoYTx2YSqSNpI9BB4lOesH4EOXC
+mDApPlB2IrBCrGS9ggrWjJIBHBZMcc4OwHnqInCIAkbJSQUT0hgCruFwWKGi4AI9hHThTFm
D3qpcM6JE4YMo2EzQqAkrZrlMtEAAYu2gk0ThhEzcgQkOZhsCjKUa3Z6wAwLHcuyHHOi8nzU
MArzpG2M4YqJzHGF3RSFMGrRh5eohVklYGQUVneC8F1eJmzTQzrB3JZgVkgle+5XhQ+QCrbQ
3qAIrWsQQM3qh8r52fsPINXhcnxKLudwOfkRLqdlciGlZ6fkAgUIVSQiqYnbELy86tz0KbOZ
qt0bFq4aIES35rYBeu7PWLIg28bYVeGUvKNa6jRiMJ7H7MVN3S7reGHT+rFqi8T8Xzuuhwm8
XdYEQnKX7PUd8w/F97YriSuCrT/sFJWyuy6ASNsZ70Ct7awCKk+3zZ3qxB09Wsp7F2NOGe9y
PMh168MhDIQdjXeqxbL1xSRq2cWjFdx383y9HYoyb9dyTFh5u+G8g+dJTcFdjTfhvbtGBzbt
brhHZzf6KXV3GBaI7SEFppvTqZZztpOAFRFTOs/JXGjKojVN2U0dnuub+5T69o7eY1Y/hcQs
fwYBjCofHUhSWPYALR0L5w8+LIJMNvDFCJyiBGw/npOGbbVzIrM9dk5ktvXMicy2zTmR07fE
BR4atGsD6ujGtxhVREYUGMWoEAmljlR3MRMjJlu+uXlReQFaTgIUiP7KT4cXdB/cBlFF6gWR
uYtIbySRMCYeAtntEVA5CGpqt7PDmzJjTKGlsbAsOha8UzuN9k7rWXZ/MsO1EtHerkbbdWRK
H8rn4Fkf3A2Um36v3hwMwN1b64Mbf9isDz/1mxfv3r2DpwxXieOxAC4C5w/de/ZIMS3/bTBs
dpR6r3MDDb1sNxXoQbNz2f5N6dY6lFmoEuRbpkzlwbPn4xkZbJitYxPzutpZzNr5ubGmh/Sh
OxwKaXnJhaBBO/88B6X1JgKoigVO8SOa8OBGQBInNimnNatPaoD3IZhvnWA+OZyPxHDc4rIG
gfEml3XeNwMO63u/13f0Ob7OhU6XbzjdtOTpAZ/4NN3Hnj13NZwMPjmRK/LJeflMLm9+jhDu
MAtuLkFQxI9Wcm01oarUU5NW4OlWTWpy7fDgpNRpgsyrgvl13bwgFykKHTbvhheyjxc+Aw+a
dbLYq61ua/heZ7DezbDab16JTKtOMxttZAl1t95vdprdYa1d7fYYzAUvi+phlun2Gs2r2qf2
sN26ZJDbO3bX8Xg+jSTJWXxVe3w/MRZz572jq77KSh/ZqFZPZF6p7SVAk7lFzx8cVYd3QKs/
UmgQoc8yjj4mL33CwHp8nIa1+sdqefGhDP/elxcVuPH20JdHOI/52KMivWqpPoDfn8gB2hh6
WaV0AQRmg/tcvVqwt0+aJPfzGS0qPlOBKsdGX+xnihG4OG8NS66EnFSsqDABcSkUJ3LWIWKu
hQJ0zL1QgIC5GAoQsO18AQLmaihAkO5uKPhgoY0bcoi6HYpTRlwPBUc36n4IKdOVH1HqI6Bn
tJf0LKD3CJ017aePxO+Qm9bybe/BtcxCRPdqMfynmQH5XCTccqd0xHwf3eqTtu6uTRsRdrl4
iHGBY2MiogtRPekzeNGvEEnfNx9xvv4FJLIMfyKrzhfKQ3R8o0YfeVkvGRAC+5yNDaVNvdT0
PZf8xih/4eWVhBhHe7NvscbRtr2doONDGPEhjHj3YcTRtVMsnni/IoOhHzyKNsiA4sjnqt/q
5y3Wc9VnHj0EDd2+q/5N+/RyfKzh4NN7BT49eI4Hn942fXrEVM0/xsJUXfYGFlAkDCfpFixk
M4f+QbS+f3BT2zjNP4jS/YMoxT+Iov5BJPyDWwh0SfgHUdQ/iJb9gyI2RvgH0Yv+QbTsH0RJ
/yBK9Q+iqH8QLfsH0Ur/IIr4B1HCCYhWewxR4B+89mL+QVq0wdwl5MUpXbwuJQ/byLWPTvGb
5KYN/CaFiO7VYvjMb1KIZNlvgcAbkO13KlRF8Bgo0T5+QyP8JEZ+kS0+e/HCRy6S+/HKy/vx
Ssp+nIILqezsD03k+q5FLqRc37XIhXT4+MWGH79glmayJLkfr6Ttx//bT2hs8dMZRvLTGfGS
Kz3/2hm9hs9qhPtxkg8yeUPn4CNscMqx94FzrJlbj69hbN/sjpx1L21ixzEO2/JXsC1nj+p1
bsrXiKiLzk5tTw+cWPvexnET68s+Hjaxlr2do6bD920OB1P7eDDF1lmxY6m38Jkb0Xd+prUE
SwnLLLCDyO2IBSbZjthDoOYXGagZdcRmhm4GjtjMQM3MaSfmLiUvTunidSm/1AC2lQFkRRyx
+aoIHgMlynN+b+H9PraH9mUemmVuiRlCtrxmeIdjs2LS+nBsln5sdrXIdWxWZPYSFgWphTto
I/Iv9RBtRfDx2rSRKZGLx1YO8bYZ7QQC+U36Vl/+6ZaDN3Udb+pRQ7m+ad98VmBYBif/pXPV
wq891IlOuuwjH/IjTZptTYzp/p73iDbuYeSWhV8K2HolsQwW3rsQBgsfIhcOkQvbjFyIa5Mv
I5jBwq86hoEoMS1MKv4imnNjOdvQo1kme3gARMApPLJLKJZXfl4nOrJXh3WiWf/3Sd3hxGyb
J2ZKB1q/9QOzxs2gdiOKKxseo/1PB2dizhc7Nduj8y/RBX74FQVQeSrEcYpzNd9AiGJCGfer
5hXQB6fqG3GqWguNul9YbobdKa7KLqmGDV5O1ysKnau+p8KsxrwLzxb8Ur5GXLDLrleYXJ5t
Rn2vBIuzjLtjZ6ph1ftD+NVe1587tCTfLBXFhbygqv4Ii/MYFXLzsY9E5CMCnciIZt4jpPOQ
vHAUFRplOeJMvfu5D7t2C8yK/fU6RBoZ2o3Jooy9vzBOX8dPmUV6tleWZKRdB1PyYEp+GaZk
ZNK/Wlsy0gduTMYgXEaKHXuqRZlzPCLlSZsyt/A+GJUHo3IPjEqvwGR/s2ZlPioPw9ipTrFX
Th37yXVce0KJMi3WJ9XwLdvBlg5Aw/JABpj4EUN799eAXd3m9N+GC63cTPpX7i0t1rH/zeYt
1sxswzWXdZsL6WACH0zg/8YELrYGXoVFvLpL3EBejZD63kH2YR8rSoav5gljOLxlcHjLYPtv
GeSYqYQqN4GLCxJAUSECOOsoTuOuQQOewuJEzMY4vB+x1gd2Qcx6671Qke+juEviej3Ftho9
6elY14A/OD4Ojo89cHwUnLWr0d+OW0SbTGdTN6znX1BLAwQUAAAACABScFRCaP3lBE4SAAA2
2AAAFwAAAGJ1aWxkZnJlX3duZXRfYW1kNjQubG9n7R1rc+I28Htn+h88/dLXxQEnzfXopFMC
JKUHJANc79rS8Ti2IG6MTW2TkP76rh5GNuYhGUhJqpucba129bK0L63wxYdmq17RGjNr7Pqu
P9LsyuBuZGiOGyI7DsInLQ4R0oZBqA1dD0VaHGh2MJ7As/75Z4Flh5rrP1ie61gx0sIgiCvW
2Dk7HYZIO7amcWB7yPL/nqIp+vyz8o8XU9dzcDUj5KMQSBxaLBTCah7MkD+xXe2b9D9M+qU/
tu6RjmZQsB94wSjQSOPbvavzXhxMdO3IpRDzptrrneNLSetct5qd9+dljSSvO63f4Lldfd+o
N7tmt9Gq9pu/Nsz+tXlR7WHY+Ze4rqTginYTBjaKImhytn2ff2YIdubh1jEjO3InQRgv9sp4
xl4Zq3uVb2gW3ez0zX61e9Xom782ur3mdUfrNfpa/1r72CudwIBJ4Bo/wvyZPGm0Qt31Zyua
MAhu/4JZZD76KDbJnBrQ65xySEork0HHhbpW7OoEFsXWeAII2tGweOnakaVV2/WzU+3I0b7R
jh60kl4u6yXdwHX0aBWjLcr/41cURm7g/6lFsNbgQXt04zutHroPKIS885JxbJTgr3zyhldd
ZgNI52F6AClkZc1zgqHk5AU28DImL2soHqP8tChnpoX0mC3OhnutrL9LTwrZJZNMIPmWFJs3
mxceDJ/g1BVn5VDGQbNyaF8RLiI+VMW4iET5xWaDDMtOOA4drvTMIZDVrZwTDCWXpFih64aW
ry/5YouOaI3oRbjKrzpB78m3v07q9txbb+hE+tkgCu0BnoIeMkHFMkGvMh9d3wkeI/MehT7y
Cq6WJOeYDCMu0rkfvD0rQfvOTr7/Ti8Nbl1/gAvC70B30HBxgZXZAtt2UUn0Fa+A/KBlGeJu
pI545zZKGmgTHgL53lY0ushuqv2fNTfSdP0Y/uC1HMstRzkxo9Uqg4+uX6+/z06HC9dnMx8r
8eRie9pP8t1auaJsTw+jCeGkYw8W6bGtHddmfKY2KRo86Pi/PgC7Yhz4A9e3vamDlsEGk+mt
59oki7cRcjFISI4C3vIBwYUMrIm7JQIsuy0RHp3h4H4MF9Av1mPaoJNpx79Di+rmx2bn7BQ/
EIZowhPljBo81a479WYf5ob5c7VTh2VwdV4GMEydDzfwRB+bnV7/vATPUNKJcV4u4WeYXuVP
JiRYRqdPKE2CY1JAaVb6rmTQfJiDLM2xmg0MOiudaKQxFNhqVDsmNMZswwMps35xBdXjh8av
LVqLSed5tfZzs9MwzXM6DoBzGQi968Hd0wSFtuV5OmBoizArGpPJWY0iNL7FLKiyAqfgIqKt
27g+yj+2XTsMomAYa191v9Zqx7Vvv9WuJ7E7dv/BvIeySBRqTC5pZai7pJ+U3hrvdKP0lljn
s7NTKoMmT6E7uoOial9rvOAaUSgsLM10Tat6nkawIi1EEQofkKMTpubhwf1id0zg+AtcLBRa
o/d2n94/mPRpzgVYQk/u/OEY/mC2HzPA7tqGC9y42neEBKt+R0g2tW/max4n+LpnKZLAzytW
P85KOECS4kyApDkjSNKcGXCETp+SL2cKJIczBg7LMwcMXsUdcB5jDDSxmjkkXak3Lj5czftV
rzcT8chaUZr3wqa33+3Ko31nhWZ8xAAeu0++pw9XT+R+ZN9GcQjzjUI/fmL302y68XN0ZB8x
ym7ycMnuPVb2W3q/nkUso5Vk8PEw3ze6nUaL9peB37frl2a7+st1N+mX2et38astlTMozc4S
lNI7ihMDm3NcjzXu0TmF98CfDdaGyw2Tf/BohdhzqN8RfH1g4QGyiOJsgmNw5CPHhPWHdHtF
5hg4bWDnsm0rysGcZUBoSIjGyI9JDq7Kc6PYdJCHYpSFjTAL8MHAQgvIPnrMAibBxJxMo7ss
FByZ4RMBEZcmq4MDcDk8lUMnV5LGM+h2OhyikJaxCE1aCm2IF7LmdXBQqqJose9RruMcCkLv
nifnBYNRZt+zMjggm00GB48SB81bgSfC6lkAAnV3Es/YSuIZicQTkthYmBlMmBlcdLEEKW6Z
0orha5RZnJ1XaAlYVKkFXBEhtRMkEFI7Qkorupuxidwz0nLPSMk9liIJeF4t94yM3DMW5J6x
IPeMRblnZOSesVLuGUvknrFc7hlr5J6RlnvGWrlncLmXoNZbQJfPOapT47jzoX0BzTMYMC9q
jHXSk2bjaZqVngzgwT2RngaTnkZGehpEarL7J7jPpSaj6CYPl+zeY2XiWUqlJstoZTMuHaFV
wxZuXpjyoc8L0XM8VTeLYENABBsZEWykRLCREsGGpAgGfD1xFtvzR3PoBOnkJJtEM+xtJBD0
ENt3Pnkc+XF86yV4t1MqecdoDNuCaWoHPbg2AjEco3Bo2ShFkctL090BP47A45NpmAXVM8U9
U8ftaALzBrcR9zHpIJY0a1QKns91CgrMKxW4WD5Yc6y8lkGzFtSMDP0koV+md/CcROZSSE7z
mBfJ3xDH5NoIhWXUEQ7BxdNy2HvlWXlqcqWAnHpCC6EzgqPkdZXFPN6/RW2FlkinCcVIqy4M
sjh4lCiZghmnq05txrRiM0/zYVgxZRku13vSEN6HRc2H92Bdien+5qa+pI8Od0w7Bk1BOw6m
cYX7ECniXIcgGM0r4D2Nymn53fdvToFpw+XkLb68g8vZd3B5W8IXnPv9W3yBDMMovzktlwgM
LkZ5fjn5TsOsGnvwwH9sTb2Y1DK27DvXR3TfH9oW26Od+hGhjOWOkpZ7G1oQodC2fGuUUhbf
ZXTFHXhFdteXVVoxcVA9Q12UL+67NuCn+67CeYY65hx/HxVl5cdeJsAS6bPfrgCf3Gv5iWTc
ayWEWe+jBiJe9/i6Sfn7egek8H2PDb7uZWi47rHH8V+qEO1lwfGa9vW6eQ37e+fRntlf9By8
j6ub+yt9T++Y6Kb7HH9c/n4bn2ji+6shPfuNH5caqTgjZ6VK7houqPVi/guajVV90S3HuSpt
FFSlt3W37sEkIcV+/ETuGcuEQLLWCQERC4U+AXKFjSI8EpjYQGZ2luUi+GQJsDdCnmhShIg6
GSToqFNBgoA4ECQHDaxrCQLqG5AgWOERkCsB2rhlCWmvgDxliiNJjm6abRFKyrlCZMV4J8aj
jEGqPMKRQOZqgAYBdHK0aEYs/RYwRFw/MOx9HAwwNBwNxmJIO9cYVEpiw1qtzVFiG+NKoaWZ
6DYyHqxTez0csKxnm/uzMeot3dC9hquFNunvkaedlt7BtkTvU8+86V7XGr0e+NGrXdj36Ddq
/Q/dxvkXX3xBNnzgrlFMVjjOYdMpeopwNsn/rddvtM3adfsGhuCi1TBhbBrti9ZvZqfaJsXN
xZn+kSoJeu8pitEYv0ZYD7ceYnW1NhXWEi+NNn1On4wMbg/JPw4hqjOQW0UgdF9BVJhYNBjb
25rveHFIbqtryTbXmi0uTVNxiUXjEvX5TLTzjlu2HMhzF0XBNLRRfs//TC/rZ+9K3+ul7V24
0qq4tBYOjGbBFS6slPv3y/3bzcT/aHlEdOzRxX3cbgDjrIAYuWqc44uWhvYbn/rneoxmMQX3
GjXMOCrNTrP/xqGw65t+pdu45IlmjST2o/LjYju1bqPd6PSrrUrnmsJCMGatCNFE57reuKx+
aPVbzQsK+fiJ3h10Ox2lHvEubMV+eDN0Z9PJmwkcZbRo7gMd7gpMRQoIokXQ8mh7zAQG+E0n
9kIQExVtbqgeD6c+8TJPLGfsQnEUOnFu8elKeDcRG+p+tfa+UpqdluDfm9KsDDfWcnIcgT5H
09uIiJaKb8UAfgNNMGjWLYxHBdPNCWFChU+Vyxk9z9DAKZJRbM4DpaDNxBU8eaIQydSUsc4k
6Gh2ISJspRUjnBQlpNaaJC212CSJiNVWYDDBKpIkotabJNEKC06+FGjvDkpJW3LFqFPWXIFR
X7ToJNjUBXH5Xj9A173g8T025CSo/TiI7kPfkyS7s2QpHscuQOZEc9meI5orLZQQqy6Dj86w
5YTFiVNsU7LZfgx7i5E1RJJ0j84YDqJJEnVjD5opSaTr+O/Ru2Npazoz79NDnVZvyYkyYk8k
MMnaInQ3nThzohT3rWjtXrOl6YA7DpwpHBoENwB9Sn59wCGH8nDwF/gIpr7zA1ZoYitkXgv/
nuW3+rWrHzTLcegj/v2C+A5RDKzEg12OEwhnuCB5gweaCaIVhAi4HwDDxjGcOzVNwZx+laap
zBF4ZaMeoo0q8ga3tEU3Imy0RTciEBN0PtFsZVsp20rZVsq2EiZUtpWyrZRtVcQ8UrbVIdpW
V/Q3esieXkCOpG3tkt82FETCJY/P1MtpqOxw/WEfNRTpyH975lCkhZuP7gmdKxRCEjpXKISk
jhOq44QFjhOKLIjBCzkhCH1hp+loomDQIrZsJAeI4i3ZMpVm8/O9U6O4fb8tX19m3xvL7Xtj
iX1vpO17g9v3+wyXzNn3Rtq+Nxbtex5hye17Y619byza90bevjcEVZkF+95Yat8bi/a9sdK+
N1L2vZEz4o3VFr+R2PdXUUpRJRlbrgJcRDHqEG1DDdkSL2KJBSNBnVgwkmR3liwFtWAkiRbt
BwPU8ZX2INXMWbZkRcmrkSXj+jzn2Ie7V6KYsWLGihnLUStm/EKZcc65Uv7xEn5MP7oDxjvK
OV5W5gnHi+/097j3GS/Of49bqGPwy7TgGN5/gP8WYf28mbKB7eK4KtJAONJA8GeyVaTBwUYa
wBt8ZZEGL92zDm9EyLO+27M6UDXlq6+WWdHurRrWLJbiWAfLsegLern8qsAxHt7tgzjNczBb
elLHijCnlZlJCZ/lG4dyfPoANg6hhWrjUG0cqo1DwQXxkjcOD/YjBkLMln+mYO1HCfLMsrye
WZaXMEsCllQrNn8WQOgrBEJIQl8hEEJKqxqbsdWHDWQ/bEAZaz4nz1jLyxjrs3weodBnEdzc
ZxGyGZeOzOIZrPpoAn0Dq37n+SV8aiHTf/bD+xnY7mI6YjFXm0BMB5SkYjrUNuKL3EaMxVcB
LqIYdYi2oVbbiM+/jQivZvttRBXToZixYsaKGStmfADMeCGmQ9LZy7VoKUMlvQ8moElTxM16
tDr7LMy61dlnxrrzB5w3noYWPPssMHMX1wEppkAJfDd16yLUWc9DPuspKUpEK+IyIe9ZOVQ9
XTF7xewVs9+uCMXsFbOXCureHN8M9Rx0YDO0b11sumwE89rhsEHK2IE/dEeHG8LO2ygb6L3L
qEh4K68yHhL6tYoVs2wVASkeAXlUN69uWje/mjAcve+eMyDSR68hchtafhCBjVIuJhxPKPQi
WCCh5D4wLj7HCgWq2FkU0LabBiwKSLgP/2G85ObGbQ5LFIqCFEJSAY5bBTiabWjxzuMb6ze9
6g3PLheLetx3nOPmifwiQhx5N1iYIwcceqgjDPdhxjhCY15XcKMKV/wvwhWzqu7riGCE5SAf
unhYQYhYg7bnj2Y8S6fCTCpwnXSSMhUWukhgRT+eiR2P4nKIo2BjfWGjVUb1VdGK8o731xog
M0bhCFX0EDeBjviGwJnvmUPemIfGxJEF6wux7j351ti1sWN+MXAGZmUUeOnIGYyV+PhL6WCa
seX6tW6/hzedphOSIz69OYpkLIvlPACzODEkwzDoD/NKk42jBxDIJmDCUJ4kTV3npwb0FK10
uMjcLS1JtxBmwof3cPcTU0xdcTnF5RSXU1zOkeNyVzv8EaTobhqDV9YHrfFwd49SjSQclCvC
crtJUmowdtnm69/os8XN45r5AftwBTr1HzpxBVq32fcq5KAVQlJeXOXFLejFFZjJL8KNm+oH
8+NmICnOR1f99n4HkZFL4SzxPEhxcOV6UEr5S1XKReZ3Ckep5btRy+EtWBPZEzWT4DEEB8FQ
kmzBCEi9zUP1dSg+qvio4qOKjzobOdt/yEd3fzJRIBozfxhRNPqMKalrfD7q0IoM41WHVrY9
tJI5XE4yiq0HTClFFKICRJAtTQR7NcXowoJ04DosRkgt7//FgRsxoqLfsfQdNxI6IZP+lOmz
fHqSvulDVfmV5FGSR0keJXnEppSSPC9J8lxJbi0/Wm7sBxPkOwB0/QhkgIceEAzM4e40r27z
8+w0r65/48bzwW40y/fpP9x3lm/s5s1joR1mISS1Da22oQtuQ8tP7BexK726W2yTeh3Cul8h
kOTh3BFYfLxXkyzZ2t5GZKidbnlzTe3QHMYOTYHpvppE7d+kK7SHo/EolG4nNxM2MNxDdVop
Lqi4oOKCwmOquKAAF5SK0f8XUEsDBBQAAAAIAEZwVEKIZa8J/RAAAIahAAAVAAAAYnVpbGRm
cmVfd25ldF94ODYubG9n7R1rc9pG8Htn+h80/dJXLMO5dRxm3CkG7NJg8ABp0paORkiHrVpI
qiRs3F/fvYd0EhKRTkCCXTouutvb3Xvf7u2ulIt33V67oXSW+txyLOdWMRqTu1ukmJaPjdD1
n5TQx1iZub4ys2wcKKGrGO7cg7T65Rf1ny4Wlm0SulvsYF8PscnxLIezmiyx4xmW8l3yP0L6
tTPX77GKl1g5dlzbvXUV2prr0dX5KHQ9VTmyGES7aY5G5+SnpvQHvW7/7XldodlBv/c7pK+b
bzvt7lAbdnrNcfe3jjYeaBfNEYGdf03qihg3lBvfNXAQ8K6K9n35BSrZmYepqQVGYHmuH672
Cn3CXqH1vco2ND0IWn+sjZvDq85Y+60zHHUHfWXUGSvjgfJ+VDsB1hK49Z9gQXhPChtG1XKW
6YGduNO/Zz7WHh0casuz04l1Aj8x9gxq4xxYk2MO2U7ks4rJZrQxdTpnhKOlh5ZKYUGozz1A
UI5mco1TjnQFwMqRqXynHN0rdfWNcvSg1NR6Xa2piDAfMd63koz//A37geU6fykBbDRIKI9W
eKe0fesB+1B2XkPHqAZ/9ZNXojq02j+JTUhHErY0Gcm93o3JhkKXU9NXcWUk5zE9gSiewKqs
q85kuVlz8H4fMg7+NGdLdDJkl0mZSUodMoCTZEUh6zlAvsLZItO45OIscbpIsa66OFe7uroP
5QZPcvuV4VitY/WfWlR5IfV903dHT47xbVSxbU3tmRmop5PANyZkmdtYAz1IA+VHe7Qc030M
tHvsO9iueHxGJcd0+AhL837y+rQG7Ts9OftRrU2mljMhjMjYqyaerW7iOt/ExRs3/5St0Fcy
R9lBS0u77ZxQ5TtXeCpBm8gQyPe2obDz6KY5/kWxAkVVj+EPpuV4t6ecrfws39j8TWLYqh94
dMPObeU40Gc4wHfKsQF/7mymHLeWYiV2KQk8VfK/OgHdfu46E8sx7IWJ82ATbzG1LYMWicZC
KQEV60CA1GpM3ltOu/02tfYJh4nuWRsiwJbaEOHRnE3u5/ADyt7HMQ1QpI7/mCvwA61qax/O
TrXzOqRIRyEBqdG4rbWavR4kW4N+uzuG2dd+afbbsNCvKC4sjnc3kGLJbn80Pq9B+n23f4LO
6zWShgVU/6BBhhf0x5RSozgaA9SWtR9riJXDKuN5gdXtENBp7USB/zh7rddp9jVojHYNCcqz
fXEF1ZNE57ceq0VjK7nZ+qXb72jaORsNKLm8GVDcS7d42ieh52t4vrBBz1EBQckA9WBO12wz
CPB8Sg6bxhqk+k/XluG7gTsLlW+G3yon6GhqhUrruPX998rAC6259S85DtiphX2Fiwql/qMK
M3hSe43eqKj2mt5qz2rQRCYYvCffur0Dnq1vFVFDi0panYgYVVGatq1QrEDxYVv5D9gkspHt
4BLDwDYnPZtsMnJfbWnXH39FeALHFntej9nzncZSfKfzpBo9ReIY/mBNH3PAlppFuBVu6C0h
wcbeEpLB7stiS/Mc6RHPiJ3Ns9ndzTCjHR7lxCanebHRaT7e7BFAbHiSy9/0tERsfAHLbn4C
Xrf7SRnf+CyzfvOT0ugAiLrV7ly8u4r72G53I2HHW1SLe2Swxx9G49G4030tPOIAmz+9M5a4
euLPOcM4MqZB6MMiZOD3H/jzh3T+6l/2vHNDTw+NO5br/BIcGUccYxglLvlzxKt+zZ6DZcAT
T0dRiRg77W1n2O/02Nhw8Nvr9qV23fx1MIz6rY3GQ7IMavUUSrefg1J7w3AezR9glkQa8VrD
Jw+bls3bclmwVyaPuk+MeSrrujrRybjpVE3WdNu6dbCpwV7FqrGmcK7btmtkig09yMDMPCA0
xMdz7IS0hFRlW0GomdjGIU7DbuG40B240uAVZAc/pgGe62neIrhLQ/9ZYP+JgiC1wLwOASB8
RC6DTn9pniys6WI2wz7jsQqNWgptCFeK4joEKFFRsNr3INNxAQXBdy+yMWO4ehn3nIcApIvp
4JBREqC4FWQhrF8FIMF2IFPRhjKVS8hiqUqEH+LCD0Wijicppzw9lsA/ot+S4qyOS8Gl9FxA
LCPUtoIEQm1LSEndtxibykmUkpMoKSdRWk6i9XISpeQkWpGTaEVOolU5iVJyEq2VkyhHTqJ8
OYk+IidRUk6ij8pJlJCTSMjJiKzdAx7ZkqM2uxr3311fQFMRB2ZFD/qYtGXFZMmmpS0H2Pzp
nbHE1RN/zglGStoiKmX58wNH+5c9hZRFsZTlGMMoccmfI14lWdORlEVMyqZLLs3iHTZhqFnJ
K+YoK3HPybIulteohLxGCXmNEvIapeQ1kpTXgK9GfgIjTmoz001mvXQWL4kxkELwA8yFQ5O3
ThhO7QhvumBieo7n4NZLUpv4wTIwyOwQ+zPdwAmKTFmS7g7O7ACMQUkYXQr8RpCqY3rrwVoi
bSR9jDpIxNJ6/YOVZxQQxkAMi0ASGkkMzaokKQZexGBFRxHAVVktSiIBHTEUU8GRMpqLAAvV
hVGzaWPlKT1GQGhVIpukZjO9UrjgxBm9htGwCRYoWSVntUw0QMCSrWAri2GkdB4ByQ7kFXN+
MN3CxKpKBfbalZky4QIyyScVpzjPGis6uoZXSq8SENHVtGbFOK6uf4EohiPbM37ZJu1kdlFQ
LJRjdxE2hJGRHmyxxkERuldwAHUaP9TfnL36AY51+Dl5TX7ewM/pj/DzukZ+SOnZa/IDBQjV
FXJUE0MfmJH1hR1SZnPduLMc3LDgEN2exREYRCbH3GMga7LpWVNfh+CCa93RbxPa5JuUMrmp
WaaKATi3h+suUMyUteuK2GG406rgxNwpf3PXFcSn+9ZrSQuG7c94jozZYSfgXNsd80jM7a4G
erxunT0VlruaX8p8J+NOOe90SMjv9kdEaA+7GvNcfWb7u0pUs5P5Fex3NMnBLs+1YOeHmtD7
dsR6F5NK1cSdjTlhvsNmR2rwjtgnVzn6KXNzBGD+dSFXqS5hQGBlRM0u5bsTam5FbXZTg2j1
uwClfv+BPlNXAgpJXQsYBDAafHggSWElRmjFySsREimFTa79khSeNAW7yJclYvf3stjsvl4W
m11gy2KzW3hZ7PyLtszsQdM2IU9epCXJEpdMmbFMHirxYaO0fMyOFZtt5vLM6PkBMk4BHAhF
kyCEJUYO0R4cXqRmOCx3ETOPFBJUxcM9+wMCqkUhVr1ecbBVYbwutDQVJEYHg3dqp3HzeT0r
7k9h8FiyobKRXOVxYc35Bu3vka38UHsD9v3Rh5F2Mxy0OqMR2JybQ3AmjDut8bth5/yrr76C
1QO/CsPjrAmcR3sGTwEppuW/j8ada601uL6BAbjodTQYmc71Re93rd+8psxi0aO+Z+JZHT0F
IZ6TSYR9MLUxr6tXxKxXnhtrekwfjQtpDy0/9iE00q0Shw1i8kUEYMkFXnGXUexIEpCMBynH
e7TecwS8txwNWDiRhV7QDREKo/4KEUiwnxqvN2LT3OIGhiP0RW7gAgl42Ld7vm//L1G8arwg
c2Jh+Jag6SEO3IVv4GwgzKlaV0/f1M7U2qYXvfrG9W/mNuHRrBKntwhrFVdx2Vs4HH9p/1S5
OzlUBjXvYwDT6jR2IxeFblPteIdur+PrDgiXBmjKV51z8qMkoePOh/G5GuJlyMCjToucro1u
vzt+ZTLY4GbcGHYuRabbopmNbBCEut8adq47/XGz1+gPGMwHY5geYJbpD9qdy+a73rjXvWCQ
9x/Y08TTxW0iSWIsGsbDq5m1XHivPFMPdVb6wEa1carySt0gA5otHOo48nQTXnxu/Eih0bsS
LOOZU/KmMwxswMdp3Gy9bdSWP9Tgv1e1ZR0evD30rSPOYzENqOxsOHoI4FewvhArmkIvG4Qu
JoTV4D81LpfstaUOyf18Rosq7B4gK2OkEZdPSQofl65jxRBUloyVyVMQg1AFKq8SFTMMyRAy
45AMBTMQyVAwS4wMBTMUyVDkG4tkZxiauSmLpNGoAmnCcCQ7xknjUUya/zIfUasmhAEjvqCe
nMEDdNh2H98Sq1F5Yid0g3vfseWo7nRJgse5BYCYJlaaMjSxekXpiI41eW/OeqZfmTZxAsq1
2QkhCoAc3HJkj+YcXhyVoxmGNrRRjkZVyd+jfcey+mKp3SfHOKl+k9c/UxFAclWB5Fp4JqMR
4dMSatznjKMubFxxOHKpWOlSSKVipUshHUKkDyHSuw+RLtw8k2cS9Qwd4RHCUQZOv3Keha1+
2aSaZ6HQUxI1tMoXeVYu1jKTz5CyN2y5O764ale/2G52o0a5F1uUf7FFORdblLzYInGx3YJz
PXOxRcmLLVq92Ap/vLjYoo9ebNHqxRZlL7Yo92KLkhdbtHqxRWsvtihxsUWZ2ytaf9VF0cX2
KkhdbGnRJquX0Fcg9XFlUu4fLqeA5aj45YkjFV+O6k6XJGAqvhzNqoqNQGstcVGSqySaDkkq
ofNu1yPzol2qZb4edHDN7LdrpnAiC+9BGyIUumAKEVZcqp/f88G/xCMxyNzzsY8fJYk/MSLR
HfEZkY98NCRrAah/3AJQz7EAULDcgi7+cEep74SUQir1nZBSSIePiWz4MRF2EGdLshaAep4F
4NN+kmSLnyKxsp8iKRtmB5+PA8P63gfZsWamu3tpSpwIk+fw8ZXYrEHyUUYurnDLsYJs3F+s
esu6l7tg0igHHfcZ6Lhsqp6phlshCkn0eS+CkXgwUOk5AYV4XwNyYpdY6c58bocYa9oLcocd
vi90cJ7to/OMbTRJ19lL+MyQ6Dz3u63AckI6ZfTz0p4n4FLC83QIqfxfhlQmPU+FQZaR56kw
pLJ43YnVS+krkPq4MulLDy4rRZMJ7pLyPJWsJJoOSSrheSoTo+Dg/Q5NgPYVRhkUX6wZRvF5
z/AOcQaSp/0hziA/zuByWSrOQGr9Eh6y5MKutBn9S486kA0OhsDiyrSJlSHX5k8T9SCkiFxA
2DZjHaA1L9IYXPDvCB3Mv1XMv0dt7eqmd/ObBsMy+vFTWoMd/OwDHeiqMwrdeORfKjNcZ2bd
7q8PT7Tx88dtyPjSeIxH8bJ6XqEdDt6/iA4HHwI5DoEcWw3kSEuflxXbkQ6DKN5GzyX6gQg9
I05q4TKZ81M51zKTWXb68NCJiFPsk8wIoufukBQ92S9vpGjXZ3dFHlyC23QJatfQ+q17BNs3
o+aNKK5v6Cf8TJ5Bsegl3YJ75OATfeDevSSAnqniSM6x/pYcCVFOSNOG39Kn9MHq+0Ksvs7S
oGYblptj/xY3VJ9UwwavpG0YxdbfMNBhXWPehSdHn1sGsRGv2oZhdQWunTQOE6yIZS1pL57r
ltMajuGfnvbDhUdLSi5TUS5npNXNB9igJ0jOOsg+USFLNQ8eQExqgAiDeELaWWQ4BXRBKvsK
VmwnlSNbsXwKdbDYPBLcLUKwLzigzuyvfSTRSFkDhVCGE9pulu1zV3cTXdkvfTfRsIPCe1B4
/ycKb2LVP1+NN9EJrvKmIInTlR0PuXpv2QFJIGQ13/In9kH1Pai+e6D6Fq7TBMJB+d1U+YXB
1z3JYAHPffQ9353JUa0o2tl/QaVQ337UrdBxPeyYALScAM4jGz9g6Pv+qt/r2yynjXPtu5Dr
c1fGJXv22XRzyXYWK9iltPBSSAdV/aCqfxpVXXITPAvNfX2fuCK/HiH3NZUS/lNWlo1WLhUd
cngp5fBSyvZfSimzVglZeQofy1JAmRwF+I8qEPlViMAmWoGKqRuHV2o2+F4ynLpBxZdwdveJ
45Ujv6J0XI+ftepUvgkcjDwHI88eGHlkl+16/IMJiNMYs9v5rS/byNRJ9h9QSwMEFAAAAAgA
OnBUQjFfwn/nEAAAP5IAABQAAABidWlsZGZyZV93eHBfeDg2LmxvZ+0daXPaRvR7Z/ofNP3S
KxawThybGXeKAbs0HB4gidvS0QhpwaqFpErCxv31fXtIKyGwtByJndBx0R7vvb3ftU/KxftW
u1FVmgt9ZjmWM1WM6uh2ihTT8rERuv6jEvoYKxPXVyaWjQMldBXDnXmQVr/9xtUNX7Gce922
TD3Eiu+6YXVxejLxsVLS56Fr2Fh3/p3jOf72m8ovF3PLNkkjU+xgHxBMRhRI8HZHC+x4hqX8
lPyPoH7vzPQ7rOIFEHZc2526Cu16Z3B1PghdT1WOLFaiXdcGg3PyU1a6vXar++68otBsr9v+
A9Kd2rtmo9XX+s12bdj60NSGPe2iNiBl59+TtiLCVeXadw0cBNDldP++/QYVHMz92NQCI7A8
1w+XR4U+4ajQ+lFlO5qeBK071Ia1/lVzqH1o9getXlcZNIfKsKd8bHVvroG2HDDsH+9RYU2q
lrNY04mRO/4H9pH2sPA02FIj6xh+YqwJpVShU04IWnpoqbQsCPWZBwDK0WQzysqRrkCxcmQq
PylH90pZrVTUsopgVnjf2SZI9p2VrCLMq6IuD1jvpht27a8P2A8s1/lbCeB4QkJ5sMJbpeFb
99iHuvMyKqEy/FWOX0X9Lr5ZHfy89yj0jyxCdtkrqWWXWpT0at8pFfVsadHjNZOju/FSbXSW
YGqS+5GVrOoir9rgCOUTXH9yxMaXI7jZJFZ+qVMRRZr7oesOHh3jx6hd2xrbEzNQT0aBb4zI
BrOxBtJOAxGnPViO6T4E2h32HWxvKIWimhKdPELSvBu9PSlD/06OT9+o5dHYckaEEJl51cST
5eNT4ccn/8isFlYbjJUsUXbS0jt+N7yh+OBy+QH0iUyB/GirCjtX17Xhb4oVKKpagj9YlpLk
CZSUk8rMVkqBPsEBvlVKBvy5k4lSqi/EpmnRIwBPlfyvjkDZmrnOyHIMe27iVWUjbz62LYNW
iUmAWlKUy7IApl4dfbScRuNdapcSAiPds7YEgM2/JcCDORndzeAHWPPTkAboWKU/Zwr8QK8a
2s3piXZegRQZKCQgNRg2tHqt3YZkvddttIawTNpvtW4DtuQVhYVVfH8NKZZsdQfD8zKkYQ2P
0XmlTNKw0pUbDTK8ojukmBqF0VhBeVF+U66wetgOPC+gWk1SdFI+VuA/Tl5rN2tdDTqjdSBB
aTYurqB5kmh+aLNWNLblavXfWt2mpp2z2YCay+sehb10c1d9FHq+hmdzG1QBFeqVTKEezKhc
XTPdF8DCCDFiAdAfw1Z+lT+IK/tm2KofePS81IIAz8aEJ1XXdBFt1EU2M0+0TsbesQzfDdxJ
qPzQ/1E5RkdjK1TqpfrPPys9L7Rm1n+EHTGuiX2FiyqlAo2X1ePyW3SmovJbajudloE+E0ze
o29Nb4Fm/UclbgGo+KD/6UTEqYpSs22FQgWKD7zCv8emSjmdTVb3u93Mc+k7QhII1tmzM2TP
9xpLcV7Ek2r0FIkS/MGxK/GC3fSKEMtlOTsCAtazIyCDGU2C6fAcGRHPCN7Ds1n+wyAjHhTl
BBuiecGKorxgRwKgO4zRs2yJ1QjWJMqy7IkUr+NPcPr2cEjQlockZpYks55hktqIaUYT3Whe
vL+KZ73RaEWSnM9RGUVzbLDHn0b1wbjVfS084gU2f3qnLHH1yJ8zBnFkjIPQhzlhxR9v+PN1
On/1H3veuqGnh8YtyzV/C46MIw7RjxKX/DngTb9lz94i4InHo6hGrKb2rtnvNttsbnjxu07j
UuvUfu/1o3Frg2GfbMxyJQXS6q4AKZ8xmAfzNewbkUa81fDRw6Zl875c5pze0YPuE4eUyoau
jnQybzo1AjTwN00dbGrAPLBqrKmc6bbtGplqQw8yZeaqQuiIj2fYCWkNacq2glAzsY1DnC6b
4lDTHTDj8RKwgx/SBZ7rad48uE2XgofMf6RF1FfG2xAFhI7IZcDpL82TjTWeTybYZzSWS6Oe
Qh/Cpaq4DVGUaChYHnuQGbgoBXl9J7IxYTArjTtOQxSkq+nkkFkSRXEvyEZYvwuAcUTyMVfI
E9GHuOhDkaDjSZU9s3o2KX9C/ybVWR2cFhfRwwGuiEjbCRCItB0BJXXzfGgqJVFKSqKklERp
KYnWS0mUkpJoSUqiJSmJlqUkSklJtFZKohVSEq2WkugpKZmUSehJmYQSMgkJmRShNdpAI1tz
1GBGdvd95wK6inhhls2jpyQbqyY7Ni3ZeIHNn94pS1w98ueMQKQkG6ISjT9vONh/7CkkGool
GofoR4lL/hzwJsmejiQaYhItXXNp5h6wEYPMCjmxRFnhdk52db5oRAVEI0qIRpQQjSglGpGk
aAR4NfI6GnFSm5huMuuls3hBfM20BN/DUjg0OXXCcGxHcOM5k4gzPINboCS2ie8tA4N4DLE/
0Q2cwMjUJfFuQVcLwKuULKM7gVsDqTbGUw+2EukjGWM0QCIBnhD1ol7IelaYFfaErJisGCor
/VnVkvhP4XsR/ip9QNREsjDCFUvBgTJKgigWWgIroxI/1Re+kKKWNiWyWWzyy5HZ0rPKjAoh
irM6BENni78MJzogypK9CDLzyfeaqM1O5BW7v2A2hYlVlYrrtTsz5QsGYJJP6ihxXnQ2raWI
4WWpC3CBnVZiGP7y/heAbDrWjUzK/0LGo5RA9VBK7jysCo8mZX6xTkIBWlfApJrV15Wz01ev
gffDz/Fb8nMGPydv4OdtmfyQ2tO35AcqEKoohJsTVyX4rPW5HVJiM924tRxctaA7O3MBAX7k
A1rJKbLumbY19nW4ru7ojj5NGJpnKTtzBy6Y3QxwjR7LnHF7bodxy322BBx2n+TNPdOPef+u
G0lLkZ0v9gr5s78hAMvbG+1IAO6tAcp3d02dCtQ9LS2lvY85p4T3OR/kd+fTITSKPc33SnVn
54dJtLKPpRXU97O+wR5ZWbBvPia0wP1Q3sN6UpVxX/NNaO+v05FCvB/qyd2NfsmYkKQwq11L
XR0uadf5zgZWRdTtIneOQt3dUKvd7s4E/bK5SUCxP97QZ8oyoCUp64CVAESVzw4kaVn+BC1d
VxePxJIBJo4AOQRPFoGZ+wVxmElfEJiZ8AWBmUVbEJhZ5QWBV1viEosG/doCO2lny2El7EuJ
WUwyGorFuIqPGaux2fEtTIvyCxB4CoBAvFtxPNhXhKu2gU2RdoF77iOgGikkcIsHc3Z7pKgc
hXG12/kBXUVDq2OPDZ0LPqi9BlWvGln+eHID1D5hULVv0BEf2crr8hn4/gc3A+2636s3BwNw
SNf6cNEwbNaH7/vN8++++w72D/wqDI7TJuU81Dh4DEg1rf9jMGx2tHqvcw1TcNFuajA3zc5F
+w+tW+tQYrGwUT8yia0OHoMQz8gywjkY25i31c4j1i5OjXU9xo8mhvSH1pd8CMB0NwizBrn4
RcSOycWM8duk+I5JlGQul1ZcLK2/VALaO45jTK7jywxoJGGKarzdiC9zh8cXWOgXeXyfFoCH
U/vMT+1XEn2sxvvRyBpz/EDQdB8H7tw3cDYy7kStqCdn5VO1vL1ZV9i+JaGxxVmsiJHdeoTb
XscUHiGx4CWNd2Cj6eutQqa8c0fm5jmGRsbxUcVXemWgVHbdW9GFiW5TdX2P92+lThOkXRVU
96vmOflRkqXD5s3wXA3xImTFg2ad8Ptqq9savjJZWe96WO03L0WmVaeZrZwgBLtb7zc7ze6w
1q52e6zMB2edHmCW6fYazcva+/aw3bpgJR9v2NPE4/k0kSTxIFXj/tXEWsy9Vx68W6uz2ns2
q1U4QgpfETYrbpCsokWTuUOvszzdhHd7q29oafT2Cct45pi8zAsTHPD5Gtbq76rlxesy/Peq
vKjAg/eLvnLF0vQiEaBOQRoG4XxcXf2eExEHI9hNIwLzpoJUaIt3Yj4OqFZQdfQQ6L4CaN7r
MUxXlTQctwzbyn+sXi7YS19Nkvv1lFbJH2fAKuBtEka1HIKPi7aw7M9aF1tYjJrwdRVsXvi7
5JG8TZCY30sCj/m+JBAS/q/cQM0i9JgrSqIDzE0mgbDGVSZHAfq4JYWMy2x1IGvxaVv2psVE
pcw4qeZSLjiC+TRDYrgX9Gqsdw+TZrsP74jvrTCuE7rBne/YUki3uhz8w8yCfIwSazoZlFhJ
pXhEUx19NCdt098YN8FrKY382F5QxYuOywkh1ILIIbnZMGfwDrAUSj+0YRRSKKpK/h7sW5bV
5wvtLrkIyVNB3uNNRVftfqpAUs89syDdQhHbhYAOgdqHQO39B2onRYBcxPbzir2GcfA45SgD
x7vQJQZ8AABk9v4vZ7a4khHdlL7A2Mo2z90cDCZrpEs5MoS1vrlFu61RvsqiRastWrTCokVJ
ixYJi3YH1/oZixYlLVq0bNGKSABh0aInLVqUsWizlixaacmipCWLli1ZtNaSRQlLFmWsTbSt
bYvW27YosmSvgpQlS6u22PwEXR7Tx5ticm2+kPqyQsUujBup2FJIt7ocPFOxpVCWtVcEOmG+
iSLVRLQMckhCVdztjRIsOhMAX+S9kpBv61ZPQBxumZ75LZNYqq/msim5O40iwTM7+8jbZgpn
bswM9O9FXSyRq7OiO5BfnElG9zz/L9HkDlx8a+apL8tknd85ftx1fkoJppD/bZdCn5IpBFTo
UzKFgJKMIh/6a/06zc6+BcPkXrYm686prHLnfNovyuzwSzJW9ksy6ZpLs+g5G637xgxbqXWv
37+EL9Okxs6/U7JUttsQTRCRX6Qu/vQHQQ/a9yba91FDu7puX3/QYFoGbz6lMu7glx6fCSN4
2YFc6w6UYb+gGCUHy4QmfZJvOEGXvpxvOB0u+57BZV+aTX8d938OftHXfkQ6GHFSCxfJnJ/K
uZaZzDLew+8MI0pSTgdxY1ZY/056cvNvzRjcU3dmhyjQZxIF+qmjP5N3ZvuPBy0c/Sm7/QkJ
SWxxDbAV+iFIbV9BasW6nIk/k7nBK9bEUtxWLCIKhIaQf9HDcJ2JNX2+cSGij9JBIbF8lJR4
xLDJtC71csoujJtt5RY3bgoN5LP5zEW3PrfD/OC43qXjWutA73fut25cD2rXorqypTf7M/mv
xZ6Xc14/Ize0GAL3QScLCOsVxkicF9aIJDsWBkixCRTVRHqlbY+ijP1geHwhhoezMOhNAcvN
sD/FVdUnzbDJK2ieoNgACQMdTgPmQ3h04B+zNIiZsmxdwOYKXHv5dTNKcvl9s5luOfX+EP7Z
Mj+ce7Sm2C4V1VKKvm7ew6E+RlJqJnvBRhJpFtyDXNUAbkG/x5WnewNwElGqrc1e9VjSnrPf
7spVooPbeQguegcY2/PVohOdlFSjJRg10Zuz7b1wxTkxkmelOSf6dVCdD6rz16E6Jzb9i9Wd
E2PgynOqROoKVqjG+VcdrCrrji9yiXt4d+Xw7sozfHelwFYnWIURfCyJAFVSCOCWlcfxN8AB
w1seiSkjh7duIkNCDsu0gs1e0yn2nneRPiSMGSnFXYiRgnI2UZ/1sRQ2Ag5OloOT5Rk4WQKJ
zX5ws2zqZoFJ1z25m03PffA9351IISV4YO4rSg+6FTquhx0TCi0nAH5j43sMQ3y+ry2t77Pk
qz4SZgZx7OQ2/8KjP+UG9tkiQuW6mR+RWSgAtBDQIbZzl7Gd1AskHdr5dBxn1gu0ZXTnZ4rn
lDsDLyLGc/2QeOjmeoBtXUaSs7kePGsJbCo1Du6mL8TdlDAM0CrDoKBTihsGKGkYoGXDAD1h
GKCsYYBWGwa0ZrNdux5cyqUSmQ1Slj8zGySRVpgNSN5sKNaWMZnOpr5kB1O6/P9QSwMEFAAA
AAgAqXBUQshyua7sBQAAoSYAAA0AAABncGxwdi5sb2cudHh07Vlbj9JAFH4n4T+cNzXRpoUu
rE3UIBfFa7Ksrg8kpJcpjJYZMtNy8dd7plMoLJYtrqiJEOO2c/nOme87Z2Y6U3v+8lP/XceB
Np/OaETZGFwWwDvKvqln3xlOxrXhkrC5F4xkzMWMixgCKoiPL6tqxToGIKRRTMR299rzvJ8g
kifCJxKewC2LGYAhfLRY3CW3sWsR++2YKjawi38Hagq6Hml3Sfwkdr2IFKLn79z7GgoyWkST
kTsNGvYw/R+bVSupG3IllSP72Ic9KsDNGlUrupVCP0I4RnYELxcxPp+tfM5COs77FkunrWTG
bou8V7+nZW5sy65xGGUUL4v0K0IsYHfbJuq3JIftCrRblkU5SeKAL9iUs5zGw/CcBvsEbeFs
Y95Fkc+n2KqIpmLcIqLyJhjmBtFM7QPf9qMALqtV0VyWz4VLY8ZnhAVYSJmM3Sgic8JimdN7
m7viPgfgijj7VTxFQbXyExIO9NEEZ7T0KKNyAjGdEgduSAA94kHNBMt2zLpTa+KzVd+07nCG
XasVwF/TBpw2ME39lBQS6OIaRNQTrqBY4yU4r+jiSyDrweYVnc7b0XXr6lX3evRx8OyGsnev
q5VRaqt11X79rPW+07Az453+1bMtvbFKD1U1GPRffVAInykOc/SlYT8eEDEnomaal/iKLdrO
EOHR3rDZME3DatQvLwxzKEiAXYaLIBxqwJsgbPN+xpYwLdN8agRRhPEIPRyjyn/qxrRa+UCi
yIWAyJgy9ztFXh6r4EykN/y5lyBnxKch9d1qJWHA+JRgbKUUAsen7UB72INnqgYxO/i0qXn0
AjonGMv1hEDIo4gv0pQgIk79jAnGpARJIrROAkcL2ZcywTCJuQMTEtGpywwa71R5q/2q7nKG
g5AOPg5w9G9cBqYFpulcPMV/GGS2qRsOXrcsmLhy4oB90anVLzutTuvCbnZ73eZl8+XLy/ZF
7SWWWD37qd2u2z2rpgJSBSa0AhXr6Z8YFXEjGCBrBOMj8XE9kWESRSuQdMxIoGaBNOqRnukM
R6fUm/m0QL2hrtVzCqqfTD3cr/AwSwG5bWCABhSgtd1u4QqGziED5nYxEYILXWiU/VUryoLr
4UQUryDGEaQpGJGYGMq5rsZEM1m23qxt50VtF6OCj2FMGBGuYmsbo61nxVKMYJycI+iICEJW
ThVBkP0sxMzz2zjLk8qz2Xv7kqq99gGd5tWKF5wy18+C/IIg+iPllLL8G3NuWU684Dz5/nIw
nXIePguSCcJIoQ669u8k8x/O57tZOKfxcVFzzt17qIC8XHMeQRrijv4UZDzGUSdMC6Dm0CIF
dPVxH0LmERKgXIc9gICjHeUwWeL37n+xu/09kh2TNUdKdpbg0NHPUNeeMmcOLWyhq07nbi9r
kJ0J6oWr/6Gnh4LFEKOaguPgZm48QUNpQSDoHHff0ONi6x1VBA9fqhU6pgi3mdkfp1N7iI1p
jI3W1mAm8ExSYDPE2HEBX0KYJuivpyqqlbUX6Uhdf5JZ1E6teIIaz4nCm9MAhwf9MC+VZObi
kpwGZUCEhIUKI4SgYUgEHoLmYP43d0xk6mleG7lsnKjyx4DuIpKKCpQvJlMJqiWZU59gvKkY
H3N12KkGxLJDvtWOwxLvSTAL3LVXOZdd3Sr3pFoZkzUJm7TZ9ItWilRdj/cKsUsZFuwJafxk
v3JO0XIpep4j7yFAyf3d+sKz1GfaMXPmkVu9f+LjoCwZ54/9+0TRMWl9ZBS9p77gkocxPLx6
BHgxgxeZEjbXLvBlGum7R/Uyx7VIhULdMI0L23pqIEAbb4kFHU8QoP0Icri2GpsOHQNauHSm
jaS6H8fLrWxBp2s7xmIpyzmjLh9P4UoW0zsePbTMi0fgaL7g3avX13gNVccCDONsPcUllKWz
NDqr1lB9dv1AXVGW3dU+MAqtN05sHTctB6w3T2wdUYqt1+r3sF5qpTxg2z6p7YOs1+4TcXfb
VpyfPzodGM+i2XyU3rira/Zlwx7hXbSFs0nNmEpaero9che1Vv35D1BLAQI/ABQAAAAIADBw
VEJ68y92PRIAAN/SAAAWACQAAAAAAAAAIAAAAAAAAABidWlsZGNoa193bGhfYW1kNjQubG9n
CgAgAAAAAAABABgAIOLeZmoPzgEghcdiag/OASCFx2JqD84BUEsBAj8AFAAAAAgAAHBUQkwL
fxSCEAAAZ54AABQAJAAAAAAAAAAgAAAAcRIAAGJ1aWxkY2hrX3dsaF94ODYubG9nCgAgAAAA
AAABABgAIHl+MGoPzgEgU8Ysag/OASBTxixqD84BUEsBAj8AFAAAAAgAbm9UQh79rsYnEwAA
MdsAABcAJAAAAAAAAAAgAAAAJSMAAGJ1aWxkY2hrX3duZXRfYW1kNjQubG9nCgAgAAAAAAAB
ABgAAAjnHGoPzgEAq88Yag/OAQCrzxhqD84BUEsBAj8AFAAAAAgAY29UQjTMrjzlEAAA7aMA
ABUAJAAAAAAAAAAgAAAAgTYAAGJ1aWxkY2hrX3duZXRfeDg2LmxvZwoAIAAAAAAAAQAYACD0
bhBqD84BwDVVDGoPzgHANVUMag/OAVBLAQI/ABQAAAAIAE1vVEIRKFovChEAAFCUAAAUACQA
AAAAAAAAIAAAAJlHAABidWlsZGNoa193eHBfeDg2LmxvZwoAIAAAAAAAAQAYAGDipPdpD84B
AHEQ9GkPzgEAcRD0aQ/OAVBLAQI/ABQAAAAIAG5wVEJLaxjN3REAAOTPAAAWACQAAAAAAAAA
IAAAANVYAABidWlsZGZyZV93bGhfYW1kNjQubG9nCgAgAAAAAAABABgAgJy6rGoPzgEAjk2o
ag/OAQCOTahqD84BUEsBAj8AFAAAAAgAZHBUQvmoQ69tEAAAAJwAABQAJAAAAAAAAAAgAAAA
5moAAGJ1aWxkZnJlX3dsaF94ODYubG9nCgAgAAAAAAABABgAoFz2n2oPzgEAbPSbag/OAQBs
9JtqD84BUEsBAj8AFAAAAAgAUnBUQmj95QROEgAANtgAABcAJAAAAAAAAAAgAAAAhXsAAGJ1
aWxkZnJlX3duZXRfYW1kNjQubG9nCgAgAAAAAAABABgAAJ20jGoPzgHg2SOIag/OAeDZI4hq
D84BUEsBAj8AFAAAAAgARnBUQohlrwn9EAAAhqEAABUAJAAAAAAAAAAgAAAACI4AAGJ1aWxk
ZnJlX3duZXRfeDg2LmxvZwoAIAAAAAAAAQAYAEDGs35qD84BAELHemoPzgEAQsd6ag/OAVBL
AQI/ABQAAAAIADpwVEIxX8J/5xAAAD+SAAAUACQAAAAAAAAAIAAAADifAABidWlsZGZyZV93
eHBfeDg2LmxvZwoAIAAAAAAAAQAYAADgMHNqD84BwDoLb2oPzgHAOgtvag/OAVBLAQI/ABQA
AAAIAKlwVELIcrmu7AUAAKEmAAANACQAAAAAAAAAIAAAAFGwAABncGxwdi5sb2cudHh0CgAg
AAAAAAABABgAoG/+7WoPzgHA3lpdWw/OAcDeWl1bD84BUEsFBgAAAAALAAsAZwQAAGi2AAAA
AA==
--------------000106010903030404080303--

--------------ms020308090803060301040708
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMDEzMTQ0NFowIwYJKoZIhvcNAQkEMRYEFHa6tpeNDEtV6J8AnG6AzRtp
aX2aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAN1cUMMEwfc/Qd51iIH5Zs6AB
7T54CMpDYNHI5ByuECObAJ62Pw4aMUM6tnikne3f+NkhreFO1gPoxc+0Xw/1u3yom3rMj++d
Gxf1yKAyEta+853MG9om86GNwfC8DTQINwW4rAdAPrcEOY/3eoQFJ0KcpG3x22SvX4j2aqW/
FnHIS/b+KwK2iNhPhJu73w/QJiAF5mnebJJ20uSBlqUhyI5GA2BMt2/bmwNzGc4SCvHs7QAH
lQ0Jc107++XJYyBl4LYZ+GYMtpqZ1GDfuiOUogBIWowpES+2YJOeChGkijAbK/ge5lA98rNt
bMXacMxA7V9ZVY5FmFB7ZTWCJMk7cgAAAAAAAA==
--------------ms020308090803060301040708--


--===============5851219563104011861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5851219563104011861==--


From xen-devel-bounces@lists.xen.org Wed Feb 20 13:19:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 13: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 1U89ZT-00077y-0X; Wed, 20 Feb 2013 13:18:51 +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 1U89ZR-00077p-Mz
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 13:18:49 +0000
Received: from [85.158.139.83:10144] by server-14.bemta-5.messagelabs.com id
	0A/C5-06967-83DC4215; Wed, 20 Feb 2013 13:18:48 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361366327!28097503!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NjkzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30258 invoked from network); 20 Feb 2013 13:18:48 -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; 20 Feb 2013 13:18:48 -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 52D5D1378;
	Wed, 20 Feb 2013 15:18:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2DAC2F4017; Wed, 20 Feb 2013 15:18:46 +0200 (EET)
Date: Wed, 20 Feb 2013 15:18:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20130220131846.GJ8912@reaktio.net>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
	<5124AE19.2000802@citrix.com> <5124AECA.4060503@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5124AECA.4060503@crc.id.au>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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, Feb 20, 2013 at 10:08:58PM +1100, Steven Haigh wrote:
> On 20/02/2013 10:06 PM, Andrew Cooper wrote:
> >On 20/02/13 10:12, Jan Beulich wrote:
> >>>>>On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
> >>>My build of Xen 4.2.1 also has all of the recent security advisories
> >>>patched as well. Although it is interesting to note that downgrading to
> >>>Xen 4.1.2 made no difference to write speeds.
> >>Not surprising at all, considering that the hypervisor is only a passive
> >>library for all PV I/O purposes. You're likely hunting for a kernel side
> >>regression (and hence the mentioning of the hypervisor version as
> >>the main factor in the subject is probably misleading).
> >>
> >>Jan
> >
> >Further to this, do try to verify if your disk driver has changed
> >recently to use >0 order page allocations for DMA.  If it has, then
> >speed will be much slower as there will now be the swiotlb cpu-copy
> >overhead.
> 
> Any hints on how to do this? ;)
> 
> The kernel modules in use for my SATA drives are ahci and sata_mv.
> There are 6 drives in total on the system.
> 
> sda + sdb = RAID1
> sd[c-f] = RAID6
> 
> sda, sdb, sdc and sdd are on the onboard SATA controller (ahci)
> sde, sdf are on the sata_mv 4x PCIe controller.
> 

Can you try using only the disks on the ahci controller?

sata_mv is known to be buggy and problematic.. 
I'm not sure if that's the case here, but if you're able to easily 
try using only ahci, it's worth a shot. 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 13:19:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 13: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 1U89ZT-00077y-0X; Wed, 20 Feb 2013 13:18:51 +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 1U89ZR-00077p-Mz
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 13:18:49 +0000
Received: from [85.158.139.83:10144] by server-14.bemta-5.messagelabs.com id
	0A/C5-06967-83DC4215; Wed, 20 Feb 2013 13:18:48 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361366327!28097503!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NjkzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30258 invoked from network); 20 Feb 2013 13:18:48 -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; 20 Feb 2013 13:18:48 -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 52D5D1378;
	Wed, 20 Feb 2013 15:18:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2DAC2F4017; Wed, 20 Feb 2013 15:18:46 +0200 (EET)
Date: Wed, 20 Feb 2013 15:18:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20130220131846.GJ8912@reaktio.net>
References: <51243089.8020307@crc.id.au> <512488AC.1020702@citrix.com>
	<51248E23.7060408@crc.id.au> <51249C11.3050800@crc.id.au>
	<5124AF9F02000078000BFA35@nat28.tlf.novell.com>
	<5124AE19.2000802@citrix.com> <5124AECA.4060503@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5124AECA.4060503@crc.id.au>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] 4.2.1: Poor write performance for 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, Feb 20, 2013 at 10:08:58PM +1100, Steven Haigh wrote:
> On 20/02/2013 10:06 PM, Andrew Cooper wrote:
> >On 20/02/13 10:12, Jan Beulich wrote:
> >>>>>On 20.02.13 at 10:49, Steven Haigh <netwiz@crc.id.au> wrote:
> >>>My build of Xen 4.2.1 also has all of the recent security advisories
> >>>patched as well. Although it is interesting to note that downgrading to
> >>>Xen 4.1.2 made no difference to write speeds.
> >>Not surprising at all, considering that the hypervisor is only a passive
> >>library for all PV I/O purposes. You're likely hunting for a kernel side
> >>regression (and hence the mentioning of the hypervisor version as
> >>the main factor in the subject is probably misleading).
> >>
> >>Jan
> >
> >Further to this, do try to verify if your disk driver has changed
> >recently to use >0 order page allocations for DMA.  If it has, then
> >speed will be much slower as there will now be the swiotlb cpu-copy
> >overhead.
> 
> Any hints on how to do this? ;)
> 
> The kernel modules in use for my SATA drives are ahci and sata_mv.
> There are 6 drives in total on the system.
> 
> sda + sdb = RAID1
> sd[c-f] = RAID6
> 
> sda, sdb, sdc and sdd are on the onboard SATA controller (ahci)
> sde, sdf are on the sata_mv 4x PCIe controller.
> 

Can you try using only the disks on the ahci controller?

sata_mv is known to be buggy and problematic.. 
I'm not sure if that's the case here, but if you're able to easily 
try using only ahci, it's worth a shot. 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 14:59:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 14:59: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 1U8B7u-0000Hy-TG; Wed, 20 Feb 2013 14:58:30 +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 1U8B7s-0000Ht-S8
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 14:58:29 +0000
Received: from [85.158.137.99:17510] by server-3.bemta-3.messagelabs.com id
	65/91-31070-394E4215; Wed, 20 Feb 2013 14:58:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361372305!14886956!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDg2Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDg2Mjk=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4935 invoked from network); 20 Feb 2013 14:58:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 14:58:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r7UwYaXFg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-042.pools.arcor-ip.net [84.57.90.42])
	by smtp.strato.de (josoe mo27) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k0499dp1KDvR4z
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 15:58:24 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id CCE861884C; Wed, 20 Feb 2013 15:58:23 +0100 (CET)
Date: Wed, 20 Feb 2013 15:58:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130220145823.GA18129@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: [Xen-devel] crash in nvmx_vcpu_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


while doing "while xm migrate --live domU localhost;do sleep 1;done" I
just got the crash shown below. And it can be reproduced.

The guest has 2 vcpus and 512mb, it runs pvops 3.7.9


(XEN) ----[ Xen-4.3.26579-20130219.172714  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    14
(XEN) RIP:    e008:[<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
(XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff830084309000   rcx: 0000000000000060
(XEN) rdx: 0000000000000000   rsi: 0000000000000003   rdi: fffffffffffffff8
(XEN) rbp: ffff8300843096e0   rsp: ffff83036ff37e40   r8:  0000000000000001
(XEN) r9:  0000000000000001   r10: ffff83066e349800   r11: ffff82c4c01dd0e0
(XEN) r12: ffff830084309000   r13: ffff83036d371000   r14: ffff83036d371e90
(XEN) r15: ffff82c4c02cf800   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000008c065000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83036ff37e40:
(XEN)    ffff830084309000 ffff830084309000 ffff830084309000 0000000000000008
(XEN)    0000000000000001 ffff82c4c01b5ce9 ffff830084309000 ffff82c4c0104e84
(XEN)    0000000000000000 ffff83036ff4a1a0 0000000000000001 ffff82c4c02cf800
(XEN)    ffff82c4c02d7800 ffff82c4c012c639 000000000000000e ffffffffffffffff
(XEN)    ffff83036ff30000 ffff82c4c0124777 ffff82c4c0124777 ffff83036ff30000
(XEN)    000000000000000e ffff82c4c02f2800 ffff83008c201000 0000000000000000
(XEN)    ffff83036ff4a060 ffff82c4c015c295 ffff83008c216000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 00007fc343205d98
(XEN)    0000000000000000 00007fc342f1764a 0000000000000000 0000000000100000
(XEN)    0000000001fb1500 00007fc33ee93010 0000000000000000 0000000000000000
(XEN)    0000000000000000 00007fc340ee1a90 000000fa00000000 00007fc342f17bc9
(XEN)    000000000000e033 0000000000000202 00007fff25f3ede8 000000000000e02b
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    000000000000000e ffff83008c216000 0000003eafc41c00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
(XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40
(XEN)    [<ffff82c4c0104e84>] complete_domain_destroy+0x54/0x180
(XEN)    [<ffff82c4c012c639>] rcu_process_callbacks+0xb9/0x230
(XEN)    [<ffff82c4c0124777>] __do_softirq+0x67/0xa0
(XEN)    [<ffff82c4c0124777>] __do_softirq+0x67/0xa0
(XEN)    [<ffff82c4c015c295>] idle_loop+0x25/0x50
(XEN)
(XEN) Pagetable walk from 0000000000000000:
(XEN)  L4[0x000] = 000000036fff2063 ffffffffffffffff
(XEN)  L3[0x000] = 000000036fff1063 ffffffffffffffff
(XEN)  L2[0x000] = 000000036fff0063 ffffffffffffffff
(XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 14:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000000
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.



Normal dom0 bootlog is like this:

  Booting 'Xen -- SUSE Linux Enterprise Server 11 SP2 - 3.0.58-0.6.2'

root (hd0,5)
 Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen.gz console=com1 com1=57600 loglvl=all guest_loglvl=all
   [Multiboot-elf, <0x100000:0x1ace98:0x5d168>, shtab=0x30a078, entry=0x100000]
module /boot/vmlinuz-3.0.58-0.6.2-xen quiet sysrq=yes panic=9 console=ttyS0,576
00 resume=/dev/disk/by-id/ata-ST9500530NS_9SP1KKAS-part2 splash=silent showopts
 log_buf_len=64M
   [Multiboot-module @ 0x30b000, 0xb8fc80 bytes]
module /boot/initrd-3.0.58-0.6.2-xen
   [Multiboot-module @ 0xe9b000, 0x1112400 bytes]

 __  __
 \ \/ /___ _ __
  \  // _ \ '_ \
  /  \  __/ | | |
 /_/\_\___|_| |_|

  _  _    _____  ____   __  ____ _____ ___    ____   ___  _ _____  ___ ____  _
 | || |  |___ / |___ \ / /_| ___|___  / _ \  |___ \ / _ \/ |___ / / _ \___ \/ |
 | || |_   |_ \   __) | '_ \___ \  / / (_) |__ __) | | | | | |_ \| | | |__) | |
 |__   _| ___) | / __/| (_) |__) |/ / \__, |__/ __/| |_| | |___) | |_| / __/| |
    |_|(_)____(_)_____|\___/____//_/    /_/  |_____|\___/|_|____/ \___/_____|_|

   ___   _ _____ ____ _____ _ _  _
  / _ \ / |___  |___ \___  / | || |
 | (_) || |  / /  __) | / /| | || |_
  \__, || | / /  / __/ / / | |__   _|
    /_(_)_|/_/  |_____/_/  |_|  |_|

(XEN) Xen version 4.3.26579-20130219.172714 (abuild@) (gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]) debug=n Tue Feb 19 17:31:26 UTC 2013
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: console=com1 com1=57600 loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b000 (usable)
(XEN)  000000000009b000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000008c21c000 (usable)
(XEN)  000000008c21c000 - 000000008c2ef000 (ACPI NVS)
(XEN)  000000008c2ef000 - 000000008c3df000 (ACPI data)
(XEN)  000000008c3df000 - 000000008d7df000 (ACPI NVS)
(XEN)  000000008d7df000 - 000000008f302000 (ACPI data)
(XEN)  000000008f302000 - 000000008f34f000 (reserved)
(XEN)  000000008f34f000 - 000000008f3d4000 (ACPI data)
(XEN)  000000008f3d4000 - 000000008f3de000 (ACPI NVS)
(XEN)  000000008f3de000 - 000000008f3e2000 (ACPI data)
(XEN)  000000008f3e2000 - 000000008f4cf000 (ACPI NVS)
(XEN)  000000008f4cf000 - 000000008f500000 (ACPI data)
(XEN)  000000008f500000 - 0000000090000000 (reserved)
(XEN)  00000000a0000000 - 00000000b0000000 (reserved)
(XEN)  00000000fc000000 - 00000000fd000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000670000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 8F4FD120, 00A4 (r1 INTEL  S5520UT         0       1000013)
(XEN) ACPI: FACP 8F4FB000, 00F4 (r4 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: DSDT 8F4F4000, 65E9 (r2 INTEL  S5520UT         3 MSFT  100000D)
(XEN) ACPI: FACS 8F3E2000, 0040
(XEN) ACPI: APIC 8F4F3000, 01A8 (r2 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: MCFG 8F4F2000, 003C (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: HPET 8F4F1000, 0038 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SLIT 8F4F0000, 0030 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SRAT 8F4EF000, 0430 (r2 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SPCR 8F4EE000, 0050 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: WDDT 8F4ED000, 0040 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: SSDT 8F4D2000, 1AFC4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 8F4D1000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: TCPA 8F4D0000, 0032 (r0                        0             0)
(XEN) ACPI: HEST 8F4CF000, 00A8 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: BERT 8F3E1000, 0030 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: ERST 8F3E0000, 0230 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: EINJ 8F3DF000, 0130 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: DMAR 8F3DE000, 01A8 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) System RAM: 24513MB (25102044kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-90000000
(XEN) SRAT: Node 0 PXM 0 100000000-370000000
(XEN) SRAT: Node 1 PXM 1 370000000-670000000
(XEN) NUMA: Allocated memnodemap from 66e359000 - 66e35a000
(XEN) NUMA: Using 16 for the hash shift.
(XEN) Domain heap initialised DMA width 31 bits
(XEN) found SMP MP-table at 000fdb60
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[8f3e200c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a401 base: 0xfed00000
(XEN) Xen ERST support is initialized.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 24 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2926.411 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control 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.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(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, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0x87c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000065e000000->000000065f000000 (6150689 pages to be allocated)
(XEN)  Init. ramdisk: 000000066eeed000->000000066ffff400
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80002000->ffffffff8087c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: ffffea0000000000->ffffea0002efd9a0
(XEN)  Start info:    ffffffff8087c000->ffffffff8087c4b4
(XEN)  Page tables:   ffffffff8087d000->ffffffff80886000
(XEN)  Boot stack:    ffffffff80886000->ffffffff80887000
(XEN)  TOTAL:         ffffffff80000000->ffffffff80c00000
(XEN)  ENTRY ADDRESS: ffffffff80002000
(XEN) Dom0 has maximum 24 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 264kB init memory.
[    0.227741] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000c4000-0x000cbfff] conflicts with Video ROM [mem 0x000c0000-0x000c7fff]
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add:00:10.1
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:00:13.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.2
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:01:00.1
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:02.0
(XEN) PCI add device 0000:06:04.0
(XEN) PCI add device 0000:09:00.0
(XEN) PCI add device 0000:0a:02.0
(XEN) PCI add device 0000:0a:04.0
(XEN) PCI add device 0000:0f:00.0
(XEN) PCI add device 0000:10:00.0
(XEN) PCI add device 0000:fe:00.0
(XEN) PCI add device 0000:fe:00.1
(XEN) PCI add device 0000:fe:02.0
(XEN) PCI add device 0000:fe:02.1
(XEN) PCI add device 0000:fe:02.2
(XEN) PCI add device 0000:fe:02.3
(XEN) PCI add device 0000:fe:02.4
(XEN) PCI add device 0000:fe:02.5
(XEN) PCI add device 0000:fe:03.0
(XEN) PCI add device 0000:fe:03.1
(XEN) PCI add device 0000:fe:03.2
(XEN) PCI add device 0000:fe:03.4
(XEN) PCI add device 0000:fe:04.0
(XEN) PCI add device 0000:fe:04.1
(XEN) PCI add device 0000:fe:04.2
(XEN) PCI add device 0000:fe:04.3
(XEN) PCI add device 0000:fe:05.0
(XEN) PCI add device 0000:fe:05.1
(XEN) PCI add device 0000:fe:05.2
(XEN) PCI add device 0000:fe:05.3
(XEN) PCI add device 0000:fe:06.0
(XEN) PCI add device 0000:fe:06.1
(XEN) PCI add device 0000:fe:06.2
(XEN) PCI add device 0000:fe:06.3
(XEN) PCI add device 0000:ff:00.0
(XEN) PCI add device 0000:ff:00.1
(XEN) PCI add device 0000:ff:02.0
(XEN) PCI add device 0000:ff:02.1
(XEN) PCI add device 0000:ff:02.2
(XEN) PCI add device 0000:ff:02.3
(XEN) PCI add device 0000:ff:02.4
(XEN) PCI add device 0000:ff:02.5
(XEN) PCI add device 0000:ff:03.0
(XEN) PCI add device 0000:ff:03.1
(XEN) PCI add device 0000:ff:03.2
(XEN) PCI add device 0000:ff:03.4
(XEN) PCI add device 0000:ff:04.0
(XEN) PCI add device 0000:ff:04.1
(XEN) PCI add device 0000:ff:04.2
(XEN) PCI add device 0000:ff:04.3
(XEN) PCI add device 0000:ff:05.0
(XEN) PCI add device 0000:ff:05.1
(XEN) PCI add device 0000:ff:05.2
(XEN) PCI add device 0000:ff:05.3
(XEN) PCI add device 0000:ff:06.0
(XEN) PCI add device 0000:ff:06.1
(XEN) PCI add device 0000:ff:06.2
(XEN) PCI add device 0000:ff:06.3
[    1.411175] i8042: No controller found

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 14:59:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 14:59: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 1U8B7u-0000Hy-TG; Wed, 20 Feb 2013 14:58:30 +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 1U8B7s-0000Ht-S8
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 14:58:29 +0000
Received: from [85.158.137.99:17510] by server-3.bemta-3.messagelabs.com id
	65/91-31070-394E4215; Wed, 20 Feb 2013 14:58:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361372305!14886956!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDg2Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NDg2Mjk=\n,BODY_RANDOM_LONG,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4935 invoked from network); 20 Feb 2013 14:58:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 14:58:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r7UwYaXFg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-042.pools.arcor-ip.net [84.57.90.42])
	by smtp.strato.de (josoe mo27) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k0499dp1KDvR4z
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 15:58:24 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id CCE861884C; Wed, 20 Feb 2013 15:58:23 +0100 (CET)
Date: Wed, 20 Feb 2013 15:58:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130220145823.GA18129@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: [Xen-devel] crash in nvmx_vcpu_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


while doing "while xm migrate --live domU localhost;do sleep 1;done" I
just got the crash shown below. And it can be reproduced.

The guest has 2 vcpus and 512mb, it runs pvops 3.7.9


(XEN) ----[ Xen-4.3.26579-20130219.172714  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    14
(XEN) RIP:    e008:[<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
(XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff830084309000   rcx: 0000000000000060
(XEN) rdx: 0000000000000000   rsi: 0000000000000003   rdi: fffffffffffffff8
(XEN) rbp: ffff8300843096e0   rsp: ffff83036ff37e40   r8:  0000000000000001
(XEN) r9:  0000000000000001   r10: ffff83066e349800   r11: ffff82c4c01dd0e0
(XEN) r12: ffff830084309000   r13: ffff83036d371000   r14: ffff83036d371e90
(XEN) r15: ffff82c4c02cf800   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000008c065000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff83036ff37e40:
(XEN)    ffff830084309000 ffff830084309000 ffff830084309000 0000000000000008
(XEN)    0000000000000001 ffff82c4c01b5ce9 ffff830084309000 ffff82c4c0104e84
(XEN)    0000000000000000 ffff83036ff4a1a0 0000000000000001 ffff82c4c02cf800
(XEN)    ffff82c4c02d7800 ffff82c4c012c639 000000000000000e ffffffffffffffff
(XEN)    ffff83036ff30000 ffff82c4c0124777 ffff82c4c0124777 ffff83036ff30000
(XEN)    000000000000000e ffff82c4c02f2800 ffff83008c201000 0000000000000000
(XEN)    ffff83036ff4a060 ffff82c4c015c295 ffff83008c216000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 00007fc343205d98
(XEN)    0000000000000000 00007fc342f1764a 0000000000000000 0000000000100000
(XEN)    0000000001fb1500 00007fc33ee93010 0000000000000000 0000000000000000
(XEN)    0000000000000000 00007fc340ee1a90 000000fa00000000 00007fc342f17bc9
(XEN)    000000000000e033 0000000000000202 00007fff25f3ede8 000000000000e02b
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    000000000000000e ffff83008c216000 0000003eafc41c00 0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
(XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40
(XEN)    [<ffff82c4c0104e84>] complete_domain_destroy+0x54/0x180
(XEN)    [<ffff82c4c012c639>] rcu_process_callbacks+0xb9/0x230
(XEN)    [<ffff82c4c0124777>] __do_softirq+0x67/0xa0
(XEN)    [<ffff82c4c0124777>] __do_softirq+0x67/0xa0
(XEN)    [<ffff82c4c015c295>] idle_loop+0x25/0x50
(XEN)
(XEN) Pagetable walk from 0000000000000000:
(XEN)  L4[0x000] = 000000036fff2063 ffffffffffffffff
(XEN)  L3[0x000] = 000000036fff1063 ffffffffffffffff
(XEN)  L2[0x000] = 000000036fff0063 ffffffffffffffff
(XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 14:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000000
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.



Normal dom0 bootlog is like this:

  Booting 'Xen -- SUSE Linux Enterprise Server 11 SP2 - 3.0.58-0.6.2'

root (hd0,5)
 Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen.gz console=com1 com1=57600 loglvl=all guest_loglvl=all
   [Multiboot-elf, <0x100000:0x1ace98:0x5d168>, shtab=0x30a078, entry=0x100000]
module /boot/vmlinuz-3.0.58-0.6.2-xen quiet sysrq=yes panic=9 console=ttyS0,576
00 resume=/dev/disk/by-id/ata-ST9500530NS_9SP1KKAS-part2 splash=silent showopts
 log_buf_len=64M
   [Multiboot-module @ 0x30b000, 0xb8fc80 bytes]
module /boot/initrd-3.0.58-0.6.2-xen
   [Multiboot-module @ 0xe9b000, 0x1112400 bytes]

 __  __
 \ \/ /___ _ __
  \  // _ \ '_ \
  /  \  __/ | | |
 /_/\_\___|_| |_|

  _  _    _____  ____   __  ____ _____ ___    ____   ___  _ _____  ___ ____  _
 | || |  |___ / |___ \ / /_| ___|___  / _ \  |___ \ / _ \/ |___ / / _ \___ \/ |
 | || |_   |_ \   __) | '_ \___ \  / / (_) |__ __) | | | | | |_ \| | | |__) | |
 |__   _| ___) | / __/| (_) |__) |/ / \__, |__/ __/| |_| | |___) | |_| / __/| |
    |_|(_)____(_)_____|\___/____//_/    /_/  |_____|\___/|_|____/ \___/_____|_|

   ___   _ _____ ____ _____ _ _  _
  / _ \ / |___  |___ \___  / | || |
 | (_) || |  / /  __) | / /| | || |_
  \__, || | / /  / __/ / / | |__   _|
    /_(_)_|/_/  |_____/_/  |_|  |_|

(XEN) Xen version 4.3.26579-20130219.172714 (abuild@) (gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]) debug=n Tue Feb 19 17:31:26 UTC 2013
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: console=com1 com1=57600 loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b000 (usable)
(XEN)  000000000009b000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000008c21c000 (usable)
(XEN)  000000008c21c000 - 000000008c2ef000 (ACPI NVS)
(XEN)  000000008c2ef000 - 000000008c3df000 (ACPI data)
(XEN)  000000008c3df000 - 000000008d7df000 (ACPI NVS)
(XEN)  000000008d7df000 - 000000008f302000 (ACPI data)
(XEN)  000000008f302000 - 000000008f34f000 (reserved)
(XEN)  000000008f34f000 - 000000008f3d4000 (ACPI data)
(XEN)  000000008f3d4000 - 000000008f3de000 (ACPI NVS)
(XEN)  000000008f3de000 - 000000008f3e2000 (ACPI data)
(XEN)  000000008f3e2000 - 000000008f4cf000 (ACPI NVS)
(XEN)  000000008f4cf000 - 000000008f500000 (ACPI data)
(XEN)  000000008f500000 - 0000000090000000 (reserved)
(XEN)  00000000a0000000 - 00000000b0000000 (reserved)
(XEN)  00000000fc000000 - 00000000fd000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000670000000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
(XEN) ACPI: XSDT 8F4FD120, 00A4 (r1 INTEL  S5520UT         0       1000013)
(XEN) ACPI: FACP 8F4FB000, 00F4 (r4 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: DSDT 8F4F4000, 65E9 (r2 INTEL  S5520UT         3 MSFT  100000D)
(XEN) ACPI: FACS 8F3E2000, 0040
(XEN) ACPI: APIC 8F4F3000, 01A8 (r2 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: MCFG 8F4F2000, 003C (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: HPET 8F4F1000, 0038 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SLIT 8F4F0000, 0030 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SRAT 8F4EF000, 0430 (r2 INTEL  S5520UT         1 MSFT  100000D)
(XEN) ACPI: SPCR 8F4EE000, 0050 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: WDDT 8F4ED000, 0040 (r1 INTEL  S5520UT         0 MSFT  100000D)
(XEN) ACPI: SSDT 8F4D2000, 1AFC4 (r2  INTEL SSDT  PM     4000 INTL 20061109)
(XEN) ACPI: SSDT 8F4D1000, 01D8 (r2  INTEL IPMI         4000 INTL 20061109)
(XEN) ACPI: TCPA 8F4D0000, 0032 (r0                        0             0)
(XEN) ACPI: HEST 8F4CF000, 00A8 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: BERT 8F3E1000, 0030 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: ERST 8F3E0000, 0230 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: EINJ 8F3DF000, 0130 (r1 INTEL  S5520UT         1 INTL        1)
(XEN) ACPI: DMAR 8F3DE000, 01A8 (r1 INTEL  S5520UT         1 MSFT  100000D)
(XEN) System RAM: 24513MB (25102044kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-90000000
(XEN) SRAT: Node 0 PXM 0 100000000-370000000
(XEN) SRAT: Node 1 PXM 1 370000000-670000000
(XEN) NUMA: Allocated memnodemap from 66e359000 - 66e35a000
(XEN) NUMA: Using 16 for the hash shift.
(XEN) Domain heap initialised DMA width 31 bits
(XEN) found SMP MP-table at 000fdb60
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[8f3e200c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x08] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x09] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0a] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0b] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0c] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0d] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0e] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x0f] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x10] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x11] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x12] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x13] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x14] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x15] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x16] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x17] high level lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec90000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec90000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a401 base: 0xfed00000
(XEN) Xen ERST support is initialized.
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 24 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2926.411 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base a0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at a0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control 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.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x2c
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(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, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0x87c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000065e000000->000000065f000000 (6150689 pages to be allocated)
(XEN)  Init. ramdisk: 000000066eeed000->000000066ffff400
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80002000->ffffffff8087c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: ffffea0000000000->ffffea0002efd9a0
(XEN)  Start info:    ffffffff8087c000->ffffffff8087c4b4
(XEN)  Page tables:   ffffffff8087d000->ffffffff80886000
(XEN)  Boot stack:    ffffffff80886000->ffffffff80887000
(XEN)  TOTAL:         ffffffff80000000->ffffffff80c00000
(XEN)  ENTRY ADDRESS: ffffffff80002000
(XEN) Dom0 has maximum 24 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 264kB init memory.
[    0.227741] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000c4000-0x000cbfff] conflicts with Video ROM [mem 0x000c0000-0x000c7fff]
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add:00:10.1
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:00:13.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.2
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1c.5
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:01:00.1
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:02.0
(XEN) PCI add device 0000:06:04.0
(XEN) PCI add device 0000:09:00.0
(XEN) PCI add device 0000:0a:02.0
(XEN) PCI add device 0000:0a:04.0
(XEN) PCI add device 0000:0f:00.0
(XEN) PCI add device 0000:10:00.0
(XEN) PCI add device 0000:fe:00.0
(XEN) PCI add device 0000:fe:00.1
(XEN) PCI add device 0000:fe:02.0
(XEN) PCI add device 0000:fe:02.1
(XEN) PCI add device 0000:fe:02.2
(XEN) PCI add device 0000:fe:02.3
(XEN) PCI add device 0000:fe:02.4
(XEN) PCI add device 0000:fe:02.5
(XEN) PCI add device 0000:fe:03.0
(XEN) PCI add device 0000:fe:03.1
(XEN) PCI add device 0000:fe:03.2
(XEN) PCI add device 0000:fe:03.4
(XEN) PCI add device 0000:fe:04.0
(XEN) PCI add device 0000:fe:04.1
(XEN) PCI add device 0000:fe:04.2
(XEN) PCI add device 0000:fe:04.3
(XEN) PCI add device 0000:fe:05.0
(XEN) PCI add device 0000:fe:05.1
(XEN) PCI add device 0000:fe:05.2
(XEN) PCI add device 0000:fe:05.3
(XEN) PCI add device 0000:fe:06.0
(XEN) PCI add device 0000:fe:06.1
(XEN) PCI add device 0000:fe:06.2
(XEN) PCI add device 0000:fe:06.3
(XEN) PCI add device 0000:ff:00.0
(XEN) PCI add device 0000:ff:00.1
(XEN) PCI add device 0000:ff:02.0
(XEN) PCI add device 0000:ff:02.1
(XEN) PCI add device 0000:ff:02.2
(XEN) PCI add device 0000:ff:02.3
(XEN) PCI add device 0000:ff:02.4
(XEN) PCI add device 0000:ff:02.5
(XEN) PCI add device 0000:ff:03.0
(XEN) PCI add device 0000:ff:03.1
(XEN) PCI add device 0000:ff:03.2
(XEN) PCI add device 0000:ff:03.4
(XEN) PCI add device 0000:ff:04.0
(XEN) PCI add device 0000:ff:04.1
(XEN) PCI add device 0000:ff:04.2
(XEN) PCI add device 0000:ff:04.3
(XEN) PCI add device 0000:ff:05.0
(XEN) PCI add device 0000:ff:05.1
(XEN) PCI add device 0000:ff:05.2
(XEN) PCI add device 0000:ff:05.3
(XEN) PCI add device 0000:ff:06.0
(XEN) PCI add device 0000:ff:06.1
(XEN) PCI add device 0000:ff:06.2
(XEN) PCI add device 0000:ff:06.3
[    1.411175] i8042: No controller found

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 15:28:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:28: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 1U8BaU-0000qS-0v; Wed, 20 Feb 2013 15:28:02 +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 1U8BaS-0000qN-0L
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 15:28:00 +0000
Received: from [85.158.139.211:22004] by server-15.bemta-5.messagelabs.com id
	4E/F0-18914-F7BE4215; Wed, 20 Feb 2013 15:27:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361374077!14446403!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25762 invoked from network); 20 Feb 2013 15:27:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:27:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1659169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 15:27: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.297.1; Wed, 20 Feb 2013 15:27:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8BaP-0002yL-4k; Wed, 20 Feb 2013 15:27:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8BaO-0000Xx-Tu;
	Wed, 20 Feb 2013 15:27:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20772.60284.798388.635292@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 15:27:56 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Everything looks good and we intend to go ahead with the switch to
git, tomorrow.

We got a recent test push so the difference between master and staging
isn't too big.  I'd appreciate it if committers would avoid throwing
big or scary patches in until we get a post-switch push.

I have just shut down the push gate for the xen-* trees.

Thanks,
Ian.


Recap:

As previously agreed, we will be moving the main Xen trees to git.
The existing .hg trees will continue to exist, but as hg mirrors of
the git history.  Committers will push to the git repo.

The new git tree will be this one:
  http://xenbits.xen.org/gitweb/?p=xen.git
  git://xenbits.xen.org/xen.git
For committers it will be accessible via
  xenbits.xen.org:/home/xen/git/xen.git

It has a branch corresponding to each xen*.hg tree:
  master                xen-unstable.hg
  stable-4.0            xen-4.0-testing.hg
  stable-4.1            xen-4.1-testing.hg
  stable-4.2            xen-4.2-testing.hg
  staging               staging/xen-unstable.hg
  staging-4.0           staging/xen-4.0-testing.hg
  staging-4.1           staging/xen-4.1-testing.hg
  staging-4.2           staging/xen-4.2-testing.hg

Committers please note that if you have commits (patch queues) in hg
at this point, they will need to be transferred into git somehow to be
committed and pushed.  After the switch it will not be possible to
accept changes from hg, because we won't have bidirectional mirroring.

If at the point we make the change there are changes in staging that
have not propagated to the corresponding stable or master tree, this
situation will be preserved.  However, revision history will be broken
(by the difference in revision ids), which will slightly weaken the
autotester's push gate.  I therefore recommend that we avoid making
this change if we have a big or scary backlog in any staging tree.

People posting and approving patches, including maintainers, are not
directly affected.

The process will be as follows:
  1. Autotester push gate shut down
  2. Announcement and coordination with committers
  3. hg trees made read-only (other than by forthcoming git->hg mirror)
  4. hg->git mirroring process stopped
  5. git tree made writeable by committers.
  6. git->hg mirror outputs checked for sanity
  7. git->hg mirror enabled, pointing at old hg trees
  8. Autotester push gate told to use git and restarted

If any committer needs help getting git to work please feel free to
ask.  git has many advantages but its user interface has received very
mixed reviews.  We appreciate that you might need handholding.  So if
you get confused, or into trouble, do consult.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 15:28:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:28: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 1U8BaU-0000qS-0v; Wed, 20 Feb 2013 15:28:02 +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 1U8BaS-0000qN-0L
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 15:28:00 +0000
Received: from [85.158.139.211:22004] by server-15.bemta-5.messagelabs.com id
	4E/F0-18914-F7BE4215; Wed, 20 Feb 2013 15:27:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361374077!14446403!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25762 invoked from network); 20 Feb 2013 15:27:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:27:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1659169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 15:27: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.297.1; Wed, 20 Feb 2013 15:27:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8BaP-0002yL-4k; Wed, 20 Feb 2013 15:27:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8BaO-0000Xx-Tu;
	Wed, 20 Feb 2013 15:27:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20772.60284.798388.635292@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 15:27:56 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Everything looks good and we intend to go ahead with the switch to
git, tomorrow.

We got a recent test push so the difference between master and staging
isn't too big.  I'd appreciate it if committers would avoid throwing
big or scary patches in until we get a post-switch push.

I have just shut down the push gate for the xen-* trees.

Thanks,
Ian.


Recap:

As previously agreed, we will be moving the main Xen trees to git.
The existing .hg trees will continue to exist, but as hg mirrors of
the git history.  Committers will push to the git repo.

The new git tree will be this one:
  http://xenbits.xen.org/gitweb/?p=xen.git
  git://xenbits.xen.org/xen.git
For committers it will be accessible via
  xenbits.xen.org:/home/xen/git/xen.git

It has a branch corresponding to each xen*.hg tree:
  master                xen-unstable.hg
  stable-4.0            xen-4.0-testing.hg
  stable-4.1            xen-4.1-testing.hg
  stable-4.2            xen-4.2-testing.hg
  staging               staging/xen-unstable.hg
  staging-4.0           staging/xen-4.0-testing.hg
  staging-4.1           staging/xen-4.1-testing.hg
  staging-4.2           staging/xen-4.2-testing.hg

Committers please note that if you have commits (patch queues) in hg
at this point, they will need to be transferred into git somehow to be
committed and pushed.  After the switch it will not be possible to
accept changes from hg, because we won't have bidirectional mirroring.

If at the point we make the change there are changes in staging that
have not propagated to the corresponding stable or master tree, this
situation will be preserved.  However, revision history will be broken
(by the difference in revision ids), which will slightly weaken the
autotester's push gate.  I therefore recommend that we avoid making
this change if we have a big or scary backlog in any staging tree.

People posting and approving patches, including maintainers, are not
directly affected.

The process will be as follows:
  1. Autotester push gate shut down
  2. Announcement and coordination with committers
  3. hg trees made read-only (other than by forthcoming git->hg mirror)
  4. hg->git mirroring process stopped
  5. git tree made writeable by committers.
  6. git->hg mirror outputs checked for sanity
  7. git->hg mirror enabled, pointing at old hg trees
  8. Autotester push gate told to use git and restarted

If any committer needs help getting git to work please feel free to
ask.  git has many advantages but its user interface has received very
mixed reviews.  We appreciate that you might need handholding.  So if
you get confused, or into trouble, do consult.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 15:44:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:44: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 1U8Bq2-0001Q0-D6; Wed, 20 Feb 2013 15:44: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 1U8Bq1-0001Pt-Ea
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:44:05 +0000
Received: from [85.158.143.99:19291] by server-1.bemta-4.messagelabs.com id
	35/22-06203-44FE4215; Wed, 20 Feb 2013 15:44:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361374935!25040006!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7211 invoked from network); 20 Feb 2013 15:42:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:42:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1659888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 15:42: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.297.1; Wed, 20 Feb 2013 15:42:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8BoF-00032f-At; Wed, 20 Feb 2013 15:42:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8BoF-0000aE-73;
	Wed, 20 Feb 2013 15:42:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20772.61143.99596.172092@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 15:42:15 +0000
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20130219193800.GE8912@reaktio.net>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<20674.5586.142286.869968@mariner.uk.xensource.com>
	<1354897843.31710.93.camel@zakaz.uk.xensource.com>
	<20674.6749.646806.53950@mariner.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FEDB689@SHSMSX102.ccr.corp.intel.com>
	<20130109070926.GD8912@reaktio.net>
	<20130124134441.GM8912@reaktio.net>
	<20130219193800.GE8912@reaktio.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio	and
 cpu_ioreq_move / Xen on Xen nested virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify=
 cpu_ioreq_pio	and cpu_ioreq_move / Xen on Xen nested virt"):
> Ping again? I wonder if I've gotten into some blacklist already for naggi=
ng about this.. =

> =

> This is a required patch for making Xen-on-Xen Nested virt working on Int=
el..

Sorry about that, I have applied 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 Feb 20 15:44:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:44: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 1U8Bq2-0001Q0-D6; Wed, 20 Feb 2013 15:44: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 1U8Bq1-0001Pt-Ea
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:44:05 +0000
Received: from [85.158.143.99:19291] by server-1.bemta-4.messagelabs.com id
	35/22-06203-44FE4215; Wed, 20 Feb 2013 15:44:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361374935!25040006!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7211 invoked from network); 20 Feb 2013 15:42:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:42:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1659888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 15:42: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.297.1; Wed, 20 Feb 2013 15:42:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8BoF-00032f-At; Wed, 20 Feb 2013 15:42:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8BoF-0000aE-73;
	Wed, 20 Feb 2013 15:42:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20772.61143.99596.172092@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 15:42:15 +0000
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20130219193800.GE8912@reaktio.net>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<20674.5586.142286.869968@mariner.uk.xensource.com>
	<1354897843.31710.93.camel@zakaz.uk.xensource.com>
	<20674.6749.646806.53950@mariner.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FEDB689@SHSMSX102.ccr.corp.intel.com>
	<20130109070926.GD8912@reaktio.net>
	<20130124134441.GM8912@reaktio.net>
	<20130219193800.GE8912@reaktio.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio	and
 cpu_ioreq_move / Xen on Xen nested virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify=
 cpu_ioreq_pio	and cpu_ioreq_move / Xen on Xen nested virt"):
> Ping again? I wonder if I've gotten into some blacklist already for naggi=
ng about this.. =

> =

> This is a required patch for making Xen-on-Xen Nested virt working on Int=
el..

Sorry about that, I have applied 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 Feb 20 15:47:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15: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 1U8Bt3-0001ar-61; Wed, 20 Feb 2013 15:47: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 1U8Bt1-0001ah-Cn
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:47:11 +0000
Received: from [85.158.139.83:20651] by server-9.bemta-5.messagelabs.com id
	E0/B7-24440-EFFE4215; Wed, 20 Feb 2013 15:47:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361375214!20787873!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7405 invoked from network); 20 Feb 2013 15:46:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1660084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 15:46: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.297.1; Wed, 20 Feb 2013 15:46:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8Bsk-00035V-22; Wed, 20 Feb 2013 15:46:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8Bsj-0000bT-UG;
	Wed, 20 Feb 2013 15:46:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20772.61421.718769.995665@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 15:46:53 +0000
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361357951-5290-1-git-send-email-fantonifabio@tiscali.it>,
	<20771.50106.583404.696259@mariner.uk.xensource.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
	<511F7E25.7040307@heliman.it>
	<1361020829.18663.9.camel@dagon.hellion.org.uk>
	<20771.50106.583404.696259@mariner.uk.xensource.com>
	<1361357951-5290-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhou Peng <zpengxen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v11] tools/libxl: Add qxl vga interface
 support for upstream qemu [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

fantonifabio@tiscali.it writes ("[PATCH v11] tools/libxl: Add qxl vga interface support for upstream qemu"):
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="qxl"

Applied, thanks.

Ian Jackson writes ("Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface support for upstream qemu"):
> Fabio, would you please transfer the ack from Stefano's email into
> your resend ?

You didn't do this but I added it myself.

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 Feb 20 15:47:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15: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 1U8Bt3-0001ar-61; Wed, 20 Feb 2013 15:47: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 1U8Bt1-0001ah-Cn
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:47:11 +0000
Received: from [85.158.139.83:20651] by server-9.bemta-5.messagelabs.com id
	E0/B7-24440-EFFE4215; Wed, 20 Feb 2013 15:47:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361375214!20787873!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7405 invoked from network); 20 Feb 2013 15:46:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1660084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 15:46: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.297.1; Wed, 20 Feb 2013 15:46:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8Bsk-00035V-22; Wed, 20 Feb 2013 15:46:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8Bsj-0000bT-UG;
	Wed, 20 Feb 2013 15:46:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20772.61421.718769.995665@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 15:46:53 +0000
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361357951-5290-1-git-send-email-fantonifabio@tiscali.it>,
	<20771.50106.583404.696259@mariner.uk.xensource.com>
References: <1360580318-5021-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151226530.8231@kaball.uk.xensource.com>
	<1360935977.31407.66.camel@zakaz.uk.xensource.com>
	<511F7E25.7040307@heliman.it>
	<1361020829.18663.9.camel@dagon.hellion.org.uk>
	<20771.50106.583404.696259@mariner.uk.xensource.com>
	<1361357951-5290-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Zhou Peng <zpengxen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v11] tools/libxl: Add qxl vga interface
 support for upstream qemu [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

fantonifabio@tiscali.it writes ("[PATCH v11] tools/libxl: Add qxl vga interface support for upstream qemu"):
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Usage:
>   vga="qxl"

Applied, thanks.

Ian Jackson writes ("Re: [Xen-devel] [PATCH v9] tools/libxl: Add qxl vga interface support for upstream qemu"):
> Fabio, would you please transfer the ack from Stefano's email into
> your resend ?

You didn't do this but I added it myself.

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 Feb 20 15:52:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:52: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 1U8By6-0001o2-0x; Wed, 20 Feb 2013 15:52:26 +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 1U8By4-0001nv-OU
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:52:24 +0000
Received: from [193.109.254.147:20764] by server-16.bemta-14.messagelabs.com
	id D5/F2-25906-831F4215; Wed, 20 Feb 2013 15:52:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361375533!9136379!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26725 invoked from network); 20 Feb 2013 15:52:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:52:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8452064"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 15:52:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 10:52:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8Bxr-0001uK-Sf;
	Wed, 20 Feb 2013 15:52:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 15:52:07 +0000
Message-ID: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2] xen/arm: phys_timer 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

Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.

Do not let the user set CNTx_CTL_PENDING directly.

Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.

Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.


Changes in v2:
- do not let the user set CNTx_CTL_PENDING directly;
- set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c        |    8 ++++++--
 xen/include/asm-arm/domain.h |    4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index f4326f8..13b8267 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
 {
     struct vtimer *t = data;
     t->ctl |= CNTx_CTL_PENDING;
-    t->ctl &= ~CNTx_CTL_MASK;
-    vgic_vcpu_inject_irq(t->v, 30, 1);
+    if ( !(t->ctl & CNTx_CTL_MASK) )
+        vgic_vcpu_inject_irq(t->v, 30, 1);
 }
 
 static void virt_timer_expired(void *data)
@@ -117,6 +117,9 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         }
         else
         {
+            *r &= ~CNTx_CTL_PENDING;
+            if ( *r & CNTx_CTL_ENABLE )
+                *r |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;
             v->arch.phys_timer.ctl = *r;
 
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
@@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
             v->arch.phys_timer.cval = now + ticks_to_ns(*r);
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
             {
+                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
             }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index fecf43b..5c4c0ca 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -79,8 +79,8 @@ struct vtimer {
         int irq;
         struct timer timer;
         uint32_t ctl;
-        s_time_t offset;
-        s_time_t cval;
+        uint64_t offset;
+        uint64_t cval;
 };
 
 struct arch_vcpu
-- 
1.7.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 Feb 20 15:52:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:52: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 1U8By6-0001o2-0x; Wed, 20 Feb 2013 15:52:26 +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 1U8By4-0001nv-OU
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:52:24 +0000
Received: from [193.109.254.147:20764] by server-16.bemta-14.messagelabs.com
	id D5/F2-25906-831F4215; Wed, 20 Feb 2013 15:52:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361375533!9136379!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26725 invoked from network); 20 Feb 2013 15:52:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:52:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8452064"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 15:52:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 10:52:12 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8Bxr-0001uK-Sf;
	Wed, 20 Feb 2013 15:52:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 15:52:07 +0000
Message-ID: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2] xen/arm: phys_timer 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

Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.

Do not let the user set CNTx_CTL_PENDING directly.

Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.

Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.


Changes in v2:
- do not let the user set CNTx_CTL_PENDING directly;
- set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c        |    8 ++++++--
 xen/include/asm-arm/domain.h |    4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index f4326f8..13b8267 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
 {
     struct vtimer *t = data;
     t->ctl |= CNTx_CTL_PENDING;
-    t->ctl &= ~CNTx_CTL_MASK;
-    vgic_vcpu_inject_irq(t->v, 30, 1);
+    if ( !(t->ctl & CNTx_CTL_MASK) )
+        vgic_vcpu_inject_irq(t->v, 30, 1);
 }
 
 static void virt_timer_expired(void *data)
@@ -117,6 +117,9 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         }
         else
         {
+            *r &= ~CNTx_CTL_PENDING;
+            if ( *r & CNTx_CTL_ENABLE )
+                *r |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;
             v->arch.phys_timer.ctl = *r;
 
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
@@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
             v->arch.phys_timer.cval = now + ticks_to_ns(*r);
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
             {
+                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
             }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index fecf43b..5c4c0ca 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -79,8 +79,8 @@ struct vtimer {
         int irq;
         struct timer timer;
         uint32_t ctl;
-        s_time_t offset;
-        s_time_t cval;
+        uint64_t offset;
+        uint64_t cval;
 };
 
 struct arch_vcpu
-- 
1.7.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 Feb 20 15:53:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:53: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 1U8ByP-0001p8-E5; Wed, 20 Feb 2013 15:52:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darren.s.shepherd@gmail.com>) id 1U8ByN-0001on-Ud
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 15:52:44 +0000
Received: from [85.158.139.211:30808] by server-2.bemta-5.messagelabs.com id
	1A/18-16911-B41F4215; Wed, 20 Feb 2013 15:52:43 +0000
X-Env-Sender: darren.s.shepherd@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361375559!18481069!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6481 invoked from network); 20 Feb 2013 15:52:40 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:52:40 -0000
Received: by mail-la0-f43.google.com with SMTP id ek20so7900659lab.30
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 07:52:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=D3OBUbMBtlMqPDyn3SOB7bPuSoRT/rspB4RAb3/+UJA=;
	b=pEdbvCXb4lXZheyP2u1pERTWJ87Q277Z7aE7uwPpL7Kz0W3cWyZoiodUms9iyLv6t0
	MKb5owyXO0yB+SbZnOTzoShYf7mbGNQsJVQKDr/n1z7T83cCbVo9Z6mWfS81eimQxykU
	7QmKqDfPj8jqJVGQmj0bYolhOJm5+yyC6FhHlUNmJoG/Tn2N9X/Y0hVmMBUTxjV6MazM
	Lt9QnuInQ+uwJHgsQNybiWyldCvOMzOlqAZWVmqVLJD1pb5SL7vIYnOH8ctm6+RWnMaY
	Sbr8/KtEst8WcxFtJ5NAYpRKpvIpTyudlz1i4nDOtV+xSkRmv4IxPEUHNDYe0oYnjy6N
	9Yjw==
MIME-Version: 1.0
X-Received: by 10.152.148.133 with SMTP id ts5mr18319115lab.2.1361375559440;
	Wed, 20 Feb 2013 07:52:39 -0800 (PST)
Received: by 10.112.118.42 with HTTP; Wed, 20 Feb 2013 07:52:39 -0800 (PST)
In-Reply-To: <CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
	<CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
Date: Wed, 20 Feb 2013 08:52:39 -0700
Message-ID: <CAMCEDC2McwtebTf48-DCpXKHeN7CgZ-L93hH7NNEPDs_UTLDfg@mail.gmail.com>
From: Darren Shepherd <darren.s.shepherd@gmail.com>
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, I'll try out that patch.  I'm using the CentOS 6 bundle of Xen
which pulls in a lot of the newer blktap code.  Do you know if that is
the only thing that prevents snapshots from working?  I have seen
people work around the time issue with just using the faketime
preload, but I think there is something beyond the timestamp that is
incompatible.

Thanks,
Darren

On Tue, Feb 19, 2013 at 4:40 PM, Andrei Lifchits
<andrei.lifchits@citrix.com> wrote:
> On Sun, Feb 17, 2013 at 2:30 PM, Darren Shepherd
> <darren.s.shepherd@gmail.com> wrote:
>> I was wondering if someone can shed some light on why vhd files
>> created with qemu-img don't really work right with vhd-util and
>> consequentially blktap in general.  To validate the incompatiblity its
>> simple enough to do
>>
>> qemu-img create -f vpc test.vhd 40g
>> vhd-util snapshot -n child.vhd -p test.vhd
>>
>> Which will show the below and then the headers don't display the BATMAP summary:
>>
>> primary footer invalid: creation time in future
>
> This is due to a bug in the blktap2 code which uses local time instead
> of UTC (which is mandated by the VHD specs). I fixed it recently in
> the Citrix fork of blktap
> (https://github.com/xen-org/blktap/commit/a79ac2c05f97c2384bbf981419f329f184dc646a),
> but unfortunately these two forks aren't really kept in sync.
>
>> test.vhd appears invalid; dumping metadata
>> Failed to open test.vhd: -22
>>
>> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
>> you the same 22 error.
>>
>> I was going to start researching this with the eventual goal of
>> changing qemu-img, but I thought I'd ask the experts first.
>>
>> Thanks,
>> Darren
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 20 15:53:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:53: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 1U8ByP-0001p8-E5; Wed, 20 Feb 2013 15:52:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darren.s.shepherd@gmail.com>) id 1U8ByN-0001on-Ud
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 15:52:44 +0000
Received: from [85.158.139.211:30808] by server-2.bemta-5.messagelabs.com id
	1A/18-16911-B41F4215; Wed, 20 Feb 2013 15:52:43 +0000
X-Env-Sender: darren.s.shepherd@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361375559!18481069!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6481 invoked from network); 20 Feb 2013 15:52:40 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 15:52:40 -0000
Received: by mail-la0-f43.google.com with SMTP id ek20so7900659lab.30
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 07:52:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=D3OBUbMBtlMqPDyn3SOB7bPuSoRT/rspB4RAb3/+UJA=;
	b=pEdbvCXb4lXZheyP2u1pERTWJ87Q277Z7aE7uwPpL7Kz0W3cWyZoiodUms9iyLv6t0
	MKb5owyXO0yB+SbZnOTzoShYf7mbGNQsJVQKDr/n1z7T83cCbVo9Z6mWfS81eimQxykU
	7QmKqDfPj8jqJVGQmj0bYolhOJm5+yyC6FhHlUNmJoG/Tn2N9X/Y0hVmMBUTxjV6MazM
	Lt9QnuInQ+uwJHgsQNybiWyldCvOMzOlqAZWVmqVLJD1pb5SL7vIYnOH8ctm6+RWnMaY
	Sbr8/KtEst8WcxFtJ5NAYpRKpvIpTyudlz1i4nDOtV+xSkRmv4IxPEUHNDYe0oYnjy6N
	9Yjw==
MIME-Version: 1.0
X-Received: by 10.152.148.133 with SMTP id ts5mr18319115lab.2.1361375559440;
	Wed, 20 Feb 2013 07:52:39 -0800 (PST)
Received: by 10.112.118.42 with HTTP; Wed, 20 Feb 2013 07:52:39 -0800 (PST)
In-Reply-To: <CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
	<CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
Date: Wed, 20 Feb 2013 08:52:39 -0700
Message-ID: <CAMCEDC2McwtebTf48-DCpXKHeN7CgZ-L93hH7NNEPDs_UTLDfg@mail.gmail.com>
From: Darren Shepherd <darren.s.shepherd@gmail.com>
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, I'll try out that patch.  I'm using the CentOS 6 bundle of Xen
which pulls in a lot of the newer blktap code.  Do you know if that is
the only thing that prevents snapshots from working?  I have seen
people work around the time issue with just using the faketime
preload, but I think there is something beyond the timestamp that is
incompatible.

Thanks,
Darren

On Tue, Feb 19, 2013 at 4:40 PM, Andrei Lifchits
<andrei.lifchits@citrix.com> wrote:
> On Sun, Feb 17, 2013 at 2:30 PM, Darren Shepherd
> <darren.s.shepherd@gmail.com> wrote:
>> I was wondering if someone can shed some light on why vhd files
>> created with qemu-img don't really work right with vhd-util and
>> consequentially blktap in general.  To validate the incompatiblity its
>> simple enough to do
>>
>> qemu-img create -f vpc test.vhd 40g
>> vhd-util snapshot -n child.vhd -p test.vhd
>>
>> Which will show the below and then the headers don't display the BATMAP summary:
>>
>> primary footer invalid: creation time in future
>
> This is due to a bug in the blktap2 code which uses local time instead
> of UTC (which is mandated by the VHD specs). I fixed it recently in
> the Citrix fork of blktap
> (https://github.com/xen-org/blktap/commit/a79ac2c05f97c2384bbf981419f329f184dc646a),
> but unfortunately these two forks aren't really kept in sync.
>
>> test.vhd appears invalid; dumping metadata
>> Failed to open test.vhd: -22
>>
>> Additionally "vhd-util snapshot -n child.vhd -p test.vhd" will give
>> you the same 22 error.
>>
>> I was going to start researching this with the eventual goal of
>> changing qemu-img, but I thought I'd ask the experts first.
>>
>> Thanks,
>> Darren
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Feb 20 15:54:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:54: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 1U8BzW-0001zQ-T9; Wed, 20 Feb 2013 15:53:54 +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 1U8BzV-0001zE-56
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:53:53 +0000
Received: from [193.109.254.147:36095] by server-3.bemta-14.messagelabs.com id
	DE/B3-22141-091F4215; Wed, 20 Feb 2013 15:53:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361375623!6184477!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NjkzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15135 invoked from network); 20 Feb 2013 15:53:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 15:53:44 -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 A2196131D;
	Wed, 20 Feb 2013 17:53:42 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 4B06CF4017; Wed, 20 Feb 2013 17:53:42 +0200 (EET)
Date: Wed, 20 Feb 2013 17:53:42 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130220155342.GK8912@reaktio.net>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<20674.5586.142286.869968@mariner.uk.xensource.com>
	<1354897843.31710.93.camel@zakaz.uk.xensource.com>
	<20674.6749.646806.53950@mariner.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FEDB689@SHSMSX102.ccr.corp.intel.com>
	<20130109070926.GD8912@reaktio.net>
	<20130124134441.GM8912@reaktio.net>
	<20130219193800.GE8912@reaktio.net>
	<20772.61143.99596.172092@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20772.61143.99596.172092@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio	and
 cpu_ioreq_move / Xen on Xen nested virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 20, 2013 at 03:42:15PM +0000, Ian Jackson wrote:
> Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simpli=
fy cpu_ioreq_pio	and cpu_ioreq_move / Xen on Xen nested virt"):
> > Ping again? I wonder if I've gotten into some blacklist already for nag=
ging about this.. =

> > =

> > This is a required patch for making Xen-on-Xen Nested virt working on I=
ntel..
> =

> Sorry about that, I have applied it.
>

Thanks!

-- Pasi
 =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 15:54:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 15:54: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 1U8BzW-0001zQ-T9; Wed, 20 Feb 2013 15:53:54 +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 1U8BzV-0001zE-56
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 15:53:53 +0000
Received: from [193.109.254.147:36095] by server-3.bemta-14.messagelabs.com id
	DE/B3-22141-091F4215; Wed, 20 Feb 2013 15:53:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361375623!6184477!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NjkzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15135 invoked from network); 20 Feb 2013 15:53:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 15:53:44 -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 A2196131D;
	Wed, 20 Feb 2013 17:53:42 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 4B06CF4017; Wed, 20 Feb 2013 17:53:42 +0200 (EET)
Date: Wed, 20 Feb 2013 17:53:42 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130220155342.GK8912@reaktio.net>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<20674.5586.142286.869968@mariner.uk.xensource.com>
	<1354897843.31710.93.camel@zakaz.uk.xensource.com>
	<20674.6749.646806.53950@mariner.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FEDB689@SHSMSX102.ccr.corp.intel.com>
	<20130109070926.GD8912@reaktio.net>
	<20130124134441.GM8912@reaktio.net>
	<20130219193800.GE8912@reaktio.net>
	<20772.61143.99596.172092@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20772.61143.99596.172092@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Xu, Dongxiao" <dongxiao.xu@intel.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio	and
 cpu_ioreq_move / Xen on Xen nested virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 20, 2013 at 03:42:15PM +0000, Ian Jackson wrote:
> Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simpli=
fy cpu_ioreq_pio	and cpu_ioreq_move / Xen on Xen nested virt"):
> > Ping again? I wonder if I've gotten into some blacklist already for nag=
ging about this.. =

> > =

> > This is a required patch for making Xen-on-Xen Nested virt working on I=
ntel..
> =

> Sorry about that, I have applied it.
>

Thanks!

-- Pasi
 =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:04:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16: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 1U8C9v-0002mn-5N; Wed, 20 Feb 2013 16:04: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 1U8C9t-0002mi-Pk
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 16:04:37 +0000
Received: from [193.109.254.147:31012] by server-9.bemta-14.messagelabs.com id
	ED/40-30867-514F4215; Wed, 20 Feb 2013 16:04:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361376145!9138078!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7410 invoked from network); 20 Feb 2013 16:02:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 16:02:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1660904"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 16:02: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.297.1;
	Wed, 20 Feb 2013 16:02:25 +0000
Message-ID: <1361376144.26546.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 16:02:24 +0000
In-Reply-To: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v2] xen/arm: phys_timer 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

Worth mentioning for the peanut gallery that we have a new copy of the
ARM ARM which has none of the previous ambiguities!

On Wed, 2013-02-20 at 15:52 +0000, Stefano Stabellini wrote:
> Do not unmask the emulated phys_timer when the related Xen timer
> expires.
> Do not inject the phys_timer interrupt if it is masked.
> 
> Do not let the user set CNTx_CTL_PENDING directly.
> 
> Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> phys_timer is disabled or the compare value is changed.
> 
> Define offset and cval as uint64_t given that they can't be negative and
> they are used as uint64_t arguments.
> 
> 
> Changes in v2:
> - do not let the user set CNTx_CTL_PENDING directly;
> - set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> phys_timer is disabled or the compare value is changed.

I don't see the clear on disable in the patch?

WRT "when the compare value is changed", should it depend on what it is
changed to? IOW if it is in the past should the timer appear to have
fired already?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/vtimer.c        |    8 ++++++--
>  xen/include/asm-arm/domain.h |    4 ++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index f4326f8..13b8267 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
>  {
>      struct vtimer *t = data;
>      t->ctl |= CNTx_CTL_PENDING;
> -    t->ctl &= ~CNTx_CTL_MASK;
> -    vgic_vcpu_inject_irq(t->v, 30, 1);
> +    if ( !(t->ctl & CNTx_CTL_MASK) )
> +        vgic_vcpu_inject_irq(t->v, 30, 1);
>  }
>  
>  static void virt_timer_expired(void *data)
> @@ -117,6 +117,9 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>          }
>          else
>          {
> +            *r &= ~CNTx_CTL_PENDING;
> +            if ( *r & CNTx_CTL_ENABLE )
> +                *r |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;

This will end up changing whichever register the guest used for the
write, which isn't part of the expected behaviour.

>              v->arch.phys_timer.ctl = *r;
>  
>              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> @@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>              v->arch.phys_timer.cval = now + ticks_to_ns(*r);
>              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
>              {
> +                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
>                  set_timer(&v->arch.phys_timer.timer,
>                            v->arch.phys_timer.cval + v->arch.phys_timer.offset);
>              }
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index fecf43b..5c4c0ca 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -79,8 +79,8 @@ struct vtimer {
>          int irq;
>          struct timer timer;
>          uint32_t ctl;
> -        s_time_t offset;
> -        s_time_t cval;
> +        uint64_t offset;
> +        uint64_t cval;
>  };
>  
>  struct arch_vcpu



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:04:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16: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 1U8C9v-0002mn-5N; Wed, 20 Feb 2013 16:04: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 1U8C9t-0002mi-Pk
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 16:04:37 +0000
Received: from [193.109.254.147:31012] by server-9.bemta-14.messagelabs.com id
	ED/40-30867-514F4215; Wed, 20 Feb 2013 16:04:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361376145!9138078!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7410 invoked from network); 20 Feb 2013 16:02:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 16:02:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1660904"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 16:02: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.297.1;
	Wed, 20 Feb 2013 16:02:25 +0000
Message-ID: <1361376144.26546.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 16:02:24 +0000
In-Reply-To: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 v2] xen/arm: phys_timer 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

Worth mentioning for the peanut gallery that we have a new copy of the
ARM ARM which has none of the previous ambiguities!

On Wed, 2013-02-20 at 15:52 +0000, Stefano Stabellini wrote:
> Do not unmask the emulated phys_timer when the related Xen timer
> expires.
> Do not inject the phys_timer interrupt if it is masked.
> 
> Do not let the user set CNTx_CTL_PENDING directly.
> 
> Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> phys_timer is disabled or the compare value is changed.
> 
> Define offset and cval as uint64_t given that they can't be negative and
> they are used as uint64_t arguments.
> 
> 
> Changes in v2:
> - do not let the user set CNTx_CTL_PENDING directly;
> - set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> phys_timer is disabled or the compare value is changed.

I don't see the clear on disable in the patch?

WRT "when the compare value is changed", should it depend on what it is
changed to? IOW if it is in the past should the timer appear to have
fired already?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/arm/vtimer.c        |    8 ++++++--
>  xen/include/asm-arm/domain.h |    4 ++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index f4326f8..13b8267 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
>  {
>      struct vtimer *t = data;
>      t->ctl |= CNTx_CTL_PENDING;
> -    t->ctl &= ~CNTx_CTL_MASK;
> -    vgic_vcpu_inject_irq(t->v, 30, 1);
> +    if ( !(t->ctl & CNTx_CTL_MASK) )
> +        vgic_vcpu_inject_irq(t->v, 30, 1);
>  }
>  
>  static void virt_timer_expired(void *data)
> @@ -117,6 +117,9 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>          }
>          else
>          {
> +            *r &= ~CNTx_CTL_PENDING;
> +            if ( *r & CNTx_CTL_ENABLE )
> +                *r |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;

This will end up changing whichever register the guest used for the
write, which isn't part of the expected behaviour.

>              v->arch.phys_timer.ctl = *r;
>  
>              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> @@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>              v->arch.phys_timer.cval = now + ticks_to_ns(*r);
>              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
>              {
> +                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
>                  set_timer(&v->arch.phys_timer.timer,
>                            v->arch.phys_timer.cval + v->arch.phys_timer.offset);
>              }
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index fecf43b..5c4c0ca 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -79,8 +79,8 @@ struct vtimer {
>          int irq;
>          struct timer timer;
>          uint32_t ctl;
> -        s_time_t offset;
> -        s_time_t cval;
> +        uint64_t offset;
> +        uint64_t cval;
>  };
>  
>  struct arch_vcpu



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:48:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16: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 1U8Cpo-0003In-TH; Wed, 20 Feb 2013 16:47:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrei.Lifchits@citrix.com>) id 1U8Cpo-0003Ii-17
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 16:47:56 +0000
Received: from [193.109.254.147:31740] by server-15.bemta-14.messagelabs.com
	id FF/86-24599-B3EF4215; Wed, 20 Feb 2013 16:47:55 +0000
X-Env-Sender: Andrei.Lifchits@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361378873!8928065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13202 invoked from network); 20 Feb 2013 16:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 16:47:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8470723"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 16:47:53 +0000
Received: from st28.blah (10.80.228.28) by smtprelay.citrix.com (10.13.107.78)
	with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 11:47:52 -0500
MIME-Version: 1.0
X-Mercurial-Node: 8f69a0bcab522d7dae5a700e5257156e9fdfd738
Message-ID: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 20 Feb 2013 16:47:51 +0000
From: Andrei Lifchits <andrei.lifchits@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH] build: Fix distclean when repo location changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
breaks distclean because make attempts to clean inside those first and fails to
find Makefile (which is also a symlink).

diff -r 66f563be41d9 -r 8f69a0bcab52 stubdom/Makefile
--- a/stubdom/Makefile	Tue Feb 19 10:49:53 2013 +0100
+++ b/stubdom/Makefile	Wed Feb 20 16:36:40 2013 +0000
@@ -501,7 +501,7 @@ clean:
 	$(MAKE) -C vtpmmgr clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
-	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
+	[ ! -e libxc-$(XEN_TARGET_ARCH)/Makefile ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
 	-[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:48:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16: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 1U8Cpo-0003In-TH; Wed, 20 Feb 2013 16:47:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrei.Lifchits@citrix.com>) id 1U8Cpo-0003Ii-17
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 16:47:56 +0000
Received: from [193.109.254.147:31740] by server-15.bemta-14.messagelabs.com
	id FF/86-24599-B3EF4215; Wed, 20 Feb 2013 16:47:55 +0000
X-Env-Sender: Andrei.Lifchits@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361378873!8928065!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13202 invoked from network); 20 Feb 2013 16:47:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 16:47:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8470723"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 16:47:53 +0000
Received: from st28.blah (10.80.228.28) by smtprelay.citrix.com (10.13.107.78)
	with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 11:47:52 -0500
MIME-Version: 1.0
X-Mercurial-Node: 8f69a0bcab522d7dae5a700e5257156e9fdfd738
Message-ID: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 20 Feb 2013 16:47:51 +0000
From: Andrei Lifchits <andrei.lifchits@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: andrei.lifchits@citrix.com
Subject: [Xen-devel] [PATCH] build: Fix distclean when repo location changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
breaks distclean because make attempts to clean inside those first and fails to
find Makefile (which is also a symlink).

diff -r 66f563be41d9 -r 8f69a0bcab52 stubdom/Makefile
--- a/stubdom/Makefile	Tue Feb 19 10:49:53 2013 +0100
+++ b/stubdom/Makefile	Wed Feb 20 16:36:40 2013 +0000
@@ -501,7 +501,7 @@ clean:
 	$(MAKE) -C vtpmmgr clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
-	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
+	[ ! -e libxc-$(XEN_TARGET_ARCH)/Makefile ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
 	-[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:56:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16:56: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 1U8Cy3-0003Wm-0Y; Wed, 20 Feb 2013 16:56:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1U8CvE-0003VV-0N
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 16:53:32 +0000
Received: from [85.158.138.51:9287] by server-9.bemta-3.messagelabs.com id
	9E/85-09484-B8FF4215; Wed, 20 Feb 2013 16:53:31 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361379209!26654890!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17630 invoked from network); 20 Feb 2013 16:53:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	20 Feb 2013 16:53: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 r1KGr8OZ016237
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 11:53:08 -0500
Received: from lacos-laptop.usersys.redhat.com (vpn1-6-181.ams2.redhat.com
	[10.36.6.181])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1KGr5OM026309; Wed, 20 Feb 2013 11:53:06 -0500
Message-ID: <5124FFED.3000106@redhat.com>
Date: Wed, 20 Feb 2013 17:55:09 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361361460.23294.22.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 20 Feb 2013 16:56:25 +0000
Cc: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	David Woodhouse <dwmw2@infradead.org>, Bei Guan <gbtju85@gmail.com>
Subject: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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

Regarding the ACPI tables, OVMF takes them from Xen. It scans 0x000EA020
to 0x000FFFFF for the RSDP and goes from there. See
OvmfPkg/AcpiPlatformDxe/Xen.c.

I'm not sure about the e820 table. In hvmloader's build_e820_table()
[tools/firmware/hvmloader/e820.c], a range starting at RESERVED_MEMBASE
is added to the table:

    /*
     * Explicitly reserve space for special pages.
     * This space starts at RESERVED_MEMBASE an extends to cover various
     * fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
     *
     * If igd_opregion_pgbase we need to split the RESERVED region in two.
     */

I gather this range is found non-specially by SeaBIOS [src/xen.c] in
xen_ramsize_preinit(), following the xen_seabios_info struct you
mentioned, placed at 0x00001000.

However in OVMF the RESERVED_MEMBASE range is not parsed from this
Xen-exported table, it is added manually in InitializeXen()
[OvmfPkg/PlatformPei/Xen.c]:

  //
  // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
  // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
  //
  AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);

"MemDetect.c" in the same directory might be relevant as well
(GetSystemMemorySizeBelow4gb(), GetSystemMemorySizeAbove4gb(); they work
from the CMOS).

... I gather this is about the placement of the flash memory, yes? If a
static address could work for the flash, I think in OVMF we should
update
- MemMapInitialization() [OvmfPkg/PlatformPei/Platform.c]
- OvmfPkg/AcpiTables/Dsdt.asl

But I could be completely missing the topic here...

Thanks,
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:56:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16:56: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 1U8Cy3-0003Wm-0Y; Wed, 20 Feb 2013 16:56:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1U8CvE-0003VV-0N
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 16:53:32 +0000
Received: from [85.158.138.51:9287] by server-9.bemta-3.messagelabs.com id
	9E/85-09484-B8FF4215; Wed, 20 Feb 2013 16:53:31 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361379209!26654890!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQyNDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17630 invoked from network); 20 Feb 2013 16:53:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	20 Feb 2013 16:53: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 r1KGr8OZ016237
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 11:53:08 -0500
Received: from lacos-laptop.usersys.redhat.com (vpn1-6-181.ams2.redhat.com
	[10.36.6.181])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1KGr5OM026309; Wed, 20 Feb 2013 11:53:06 -0500
Message-ID: <5124FFED.3000106@redhat.com>
Date: Wed, 20 Feb 2013 17:55:09 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361361460.23294.22.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 20 Feb 2013 16:56:25 +0000
Cc: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	David Woodhouse <dwmw2@infradead.org>, Bei Guan <gbtju85@gmail.com>
Subject: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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

Regarding the ACPI tables, OVMF takes them from Xen. It scans 0x000EA020
to 0x000FFFFF for the RSDP and goes from there. See
OvmfPkg/AcpiPlatformDxe/Xen.c.

I'm not sure about the e820 table. In hvmloader's build_e820_table()
[tools/firmware/hvmloader/e820.c], a range starting at RESERVED_MEMBASE
is added to the table:

    /*
     * Explicitly reserve space for special pages.
     * This space starts at RESERVED_MEMBASE an extends to cover various
     * fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
     *
     * If igd_opregion_pgbase we need to split the RESERVED region in two.
     */

I gather this range is found non-specially by SeaBIOS [src/xen.c] in
xen_ramsize_preinit(), following the xen_seabios_info struct you
mentioned, placed at 0x00001000.

However in OVMF the RESERVED_MEMBASE range is not parsed from this
Xen-exported table, it is added manually in InitializeXen()
[OvmfPkg/PlatformPei/Xen.c]:

  //
  // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
  // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
  //
  AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);

"MemDetect.c" in the same directory might be relevant as well
(GetSystemMemorySizeBelow4gb(), GetSystemMemorySizeAbove4gb(); they work
from the CMOS).

... I gather this is about the placement of the flash memory, yes? If a
static address could work for the flash, I think in OVMF we should
update
- MemMapInitialization() [OvmfPkg/PlatformPei/Platform.c]
- OvmfPkg/AcpiTables/Dsdt.asl

But I could be completely missing the topic here...

Thanks,
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:57:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16:57: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 1U8CyN-0003Xv-Is; Wed, 20 Feb 2013 16:56:47 +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 1U8CyM-0003Xq-Q7
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 16:56:47 +0000
Received: from [85.158.139.83:56895] by server-10.bemta-5.messagelabs.com id
	49/FF-04697-E4005215; Wed, 20 Feb 2013 16:56:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361379403!28422447!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16710 invoked from network); 20 Feb 2013 16:56:45 -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;
	20 Feb 2013 16:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8053562"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 16:56:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 11:56:42 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8CyI-0002uO-NW;
	Wed, 20 Feb 2013 16:56:42 +0000
Date: Wed, 20 Feb 2013 16:56:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361376144.26546.13.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302201653430.22997@kaball.uk.xensource.com>
References: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1361376144.26546.13.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/arm: phys_timer 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

On Wed, 20 Feb 2013, Ian Campbell wrote:
> Worth mentioning for the peanut gallery that we have a new copy of the
> ARM ARM which has none of the previous ambiguities!
> 
> On Wed, 2013-02-20 at 15:52 +0000, Stefano Stabellini wrote:
> > Do not unmask the emulated phys_timer when the related Xen timer
> > expires.
> > Do not inject the phys_timer interrupt if it is masked.
> > 
> > Do not let the user set CNTx_CTL_PENDING directly.
> > 
> > Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> > phys_timer is disabled or the compare value is changed.
> > 
> > Define offset and cval as uint64_t given that they can't be negative and
> > they are used as uint64_t arguments.
> > 
> > 
> > Changes in v2:
> > - do not let the user set CNTx_CTL_PENDING directly;
> > - set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> > phys_timer is disabled or the compare value is changed.
> 
> I don't see the clear on disable in the patch?

I'll mark below where I am doing the bit clear


> WRT "when the compare value is changed", should it depend on what it is
> changed to? IOW if it is in the past should the timer appear to have
> fired already?

No, because if it is set in the past the internal hypervisor timer will
fire off immediately, and we set again the pending bit in the timer handler.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/vtimer.c        |    8 ++++++--
> >  xen/include/asm-arm/domain.h |    4 ++--
> >  2 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > index f4326f8..13b8267 100644
> > --- a/xen/arch/arm/vtimer.c
> > +++ b/xen/arch/arm/vtimer.c
> > @@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
> >  {
> >      struct vtimer *t = data;
> >      t->ctl |= CNTx_CTL_PENDING;
> > -    t->ctl &= ~CNTx_CTL_MASK;
> > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> >  }
> >  
> >  static void virt_timer_expired(void *data)
> > @@ -117,6 +117,9 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >          }
> >          else
> >          {
> > +            *r &= ~CNTx_CTL_PENDING;
                        ^ clear

> > +            if ( *r & CNTx_CTL_ENABLE )
> > +                *r |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;
> 
> This will end up changing whichever register the guest used for the
> write, which isn't part of the expected behaviour.

I'll need to make a local copy of that register


> >              v->arch.phys_timer.ctl = *r;
> >  
> >              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > @@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >              v->arch.phys_timer.cval = now + ticks_to_ns(*r);
> >              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> >              {
> > +                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
                                                ^ clear

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 16:57:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 16:57: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 1U8CyN-0003Xv-Is; Wed, 20 Feb 2013 16:56:47 +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 1U8CyM-0003Xq-Q7
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 16:56:47 +0000
Received: from [85.158.139.83:56895] by server-10.bemta-5.messagelabs.com id
	49/FF-04697-E4005215; Wed, 20 Feb 2013 16:56:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361379403!28422447!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16710 invoked from network); 20 Feb 2013 16:56:45 -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;
	20 Feb 2013 16:56:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8053562"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 16:56:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 11:56:42 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8CyI-0002uO-NW;
	Wed, 20 Feb 2013 16:56:42 +0000
Date: Wed, 20 Feb 2013 16:56:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361376144.26546.13.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302201653430.22997@kaball.uk.xensource.com>
References: <1361375527-20573-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1361376144.26546.13.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/arm: phys_timer 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

On Wed, 20 Feb 2013, Ian Campbell wrote:
> Worth mentioning for the peanut gallery that we have a new copy of the
> ARM ARM which has none of the previous ambiguities!
> 
> On Wed, 2013-02-20 at 15:52 +0000, Stefano Stabellini wrote:
> > Do not unmask the emulated phys_timer when the related Xen timer
> > expires.
> > Do not inject the phys_timer interrupt if it is masked.
> > 
> > Do not let the user set CNTx_CTL_PENDING directly.
> > 
> > Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> > phys_timer is disabled or the compare value is changed.
> > 
> > Define offset and cval as uint64_t given that they can't be negative and
> > they are used as uint64_t arguments.
> > 
> > 
> > Changes in v2:
> > - do not let the user set CNTx_CTL_PENDING directly;
> > - set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
> > phys_timer is disabled or the compare value is changed.
> 
> I don't see the clear on disable in the patch?

I'll mark below where I am doing the bit clear


> WRT "when the compare value is changed", should it depend on what it is
> changed to? IOW if it is in the past should the timer appear to have
> fired already?

No, because if it is set in the past the internal hypervisor timer will
fire off immediately, and we set again the pending bit in the timer handler.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  xen/arch/arm/vtimer.c        |    8 ++++++--
> >  xen/include/asm-arm/domain.h |    4 ++--
> >  2 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > index f4326f8..13b8267 100644
> > --- a/xen/arch/arm/vtimer.c
> > +++ b/xen/arch/arm/vtimer.c
> > @@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
> >  {
> >      struct vtimer *t = data;
> >      t->ctl |= CNTx_CTL_PENDING;
> > -    t->ctl &= ~CNTx_CTL_MASK;
> > -    vgic_vcpu_inject_irq(t->v, 30, 1);
> > +    if ( !(t->ctl & CNTx_CTL_MASK) )
> > +        vgic_vcpu_inject_irq(t->v, 30, 1);
> >  }
> >  
> >  static void virt_timer_expired(void *data)
> > @@ -117,6 +117,9 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >          }
> >          else
> >          {
> > +            *r &= ~CNTx_CTL_PENDING;
                        ^ clear

> > +            if ( *r & CNTx_CTL_ENABLE )
> > +                *r |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;
> 
> This will end up changing whichever register the guest used for the
> write, which isn't part of the expected behaviour.

I'll need to make a local copy of that register


> >              v->arch.phys_timer.ctl = *r;
> >  
> >              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> > @@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >              v->arch.phys_timer.cval = now + ticks_to_ns(*r);
> >              if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
> >              {
> > +                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
                                                ^ clear

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 17:00:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17: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 1U8D1R-0003ld-6I; Wed, 20 Feb 2013 16:59: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 1U8D1Q-0003lR-2P
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 16:59:56 +0000
Received: from [85.158.139.211:47906] by server-5.bemta-5.messagelabs.com id
	BE/1D-11945-B0105215; Wed, 20 Feb 2013 16:59:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361379594!18493015!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13381 invoked from network); 20 Feb 2013 16:59:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 16:59:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1664081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 16:59: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.297.1; Wed, 20 Feb 2013 16:59:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8D1O-0003SI-GZ; Wed, 20 Feb 2013 16:59:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8D1O-0000ji-8N;
	Wed, 20 Feb 2013 16:59:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20773.266.135606.992324@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 16:59:54 +0000
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458385@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458385@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] trivial: Do not ignore dsdl.asl 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

Frediano Ziglio writes ("[Xen-devel] [PATCH] trivial: Do not ignore dsdl.asl file"):
> dsdl.asl file is not autogenerated while all other dsdl_*.asl files are.
> .hgignore is correct.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-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 Wed Feb 20 17:00:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17: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 1U8D1R-0003ld-6I; Wed, 20 Feb 2013 16:59: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 1U8D1Q-0003lR-2P
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 16:59:56 +0000
Received: from [85.158.139.211:47906] by server-5.bemta-5.messagelabs.com id
	BE/1D-11945-B0105215; Wed, 20 Feb 2013 16:59:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361379594!18493015!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13381 invoked from network); 20 Feb 2013 16:59:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 16:59:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1664081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 16:59: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.297.1; Wed, 20 Feb 2013 16:59:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8D1O-0003SI-GZ; Wed, 20 Feb 2013 16:59:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8D1O-0000ji-8N;
	Wed, 20 Feb 2013 16:59:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20773.266.135606.992324@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 16:59:54 +0000
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458385@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458385@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] trivial: Do not ignore dsdl.asl 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

Frediano Ziglio writes ("[Xen-devel] [PATCH] trivial: Do not ignore dsdl.asl file"):
> dsdl.asl file is not autogenerated while all other dsdl_*.asl files are.
> .hgignore is correct.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-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 Wed Feb 20 17:02:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17: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 1U8D3T-0003zh-Oe; Wed, 20 Feb 2013 17:02: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 1U8D3R-0003zQ-Mz
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:02:02 +0000
Received: from [85.158.138.51:57600] by server-5.bemta-3.messagelabs.com id
	40/B2-04457-48105215; Wed, 20 Feb 2013 17:01:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361379683!19697685!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11625 invoked from network); 20 Feb 2013 17:01:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 17:01:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1664172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 17:01: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.297.1;
	Wed, 20 Feb 2013 17:01:23 +0000
Message-ID: <1361379682.26546.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Wed, 20 Feb 2013 17:01:22 +0000
In-Reply-To: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] build: Fix distclean when repo location
 changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 16:47 +0000, Andrei Lifchits wrote:
> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
> breaks distclean because make attempts to clean inside those first and fails to
> find Makefile (which is also a symlink).

Would it be possible to arrange for the symlinks to be relative in the
first place?

> 
> diff -r 66f563be41d9 -r 8f69a0bcab52 stubdom/Makefile
> --- a/stubdom/Makefile	Tue Feb 19 10:49:53 2013 +0100
> +++ b/stubdom/Makefile	Wed Feb 20 16:36:40 2013 +0000
> @@ -501,7 +501,7 @@ clean:
>  	$(MAKE) -C vtpmmgr clean
>  	rm -fr grub-$(XEN_TARGET_ARCH)
>  	rm -f $(STUBDOMPATH)
> -	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
> +	[ ! -e libxc-$(XEN_TARGET_ARCH)/Makefile ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
>  	-[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
>  	-[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 20 17:02:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17: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 1U8D3T-0003zh-Oe; Wed, 20 Feb 2013 17:02: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 1U8D3R-0003zQ-Mz
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:02:02 +0000
Received: from [85.158.138.51:57600] by server-5.bemta-3.messagelabs.com id
	40/B2-04457-48105215; Wed, 20 Feb 2013 17:01:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361379683!19697685!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11625 invoked from network); 20 Feb 2013 17:01:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 17:01:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1664172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 17:01: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.297.1;
	Wed, 20 Feb 2013 17:01:23 +0000
Message-ID: <1361379682.26546.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Wed, 20 Feb 2013 17:01:22 +0000
In-Reply-To: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] build: Fix distclean when repo location
 changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 16:47 +0000, Andrei Lifchits wrote:
> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
> breaks distclean because make attempts to clean inside those first and fails to
> find Makefile (which is also a symlink).

Would it be possible to arrange for the symlinks to be relative in the
first place?

> 
> diff -r 66f563be41d9 -r 8f69a0bcab52 stubdom/Makefile
> --- a/stubdom/Makefile	Tue Feb 19 10:49:53 2013 +0100
> +++ b/stubdom/Makefile	Wed Feb 20 16:36:40 2013 +0000
> @@ -501,7 +501,7 @@ clean:
>  	$(MAKE) -C vtpmmgr clean
>  	rm -fr grub-$(XEN_TARGET_ARCH)
>  	rm -f $(STUBDOMPATH)
> -	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
> +	[ ! -e libxc-$(XEN_TARGET_ARCH)/Makefile ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
>  	-[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
>  	-[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 20 17:07:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17: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 1U8D8I-0004E4-KS; Wed, 20 Feb 2013 17:07: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 1U8D8G-0004Dw-9j
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:07:00 +0000
Received: from [85.158.138.51:30341] by server-8.bemta-3.messagelabs.com id
	D1/E3-25687-3B205215; Wed, 20 Feb 2013 17:06:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361380018!24364207!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6312 invoked from network); 20 Feb 2013 17:06:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 17:06:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1664621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 17:06: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.297.1; Wed, 20 Feb 2013 17:06:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8D8D-0003UJ-C8; Wed, 20 Feb 2013 17:06:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8D8D-0000kW-6p;
	Wed, 20 Feb 2013 17:06:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20773.689.102778.808549@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 17:06:57 +0000
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
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] build: Fix distclean when repo location
	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Andrei Lifchits writes ("[Xen-devel] [PATCH] build: Fix distclean when repo location changes"):
> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
> breaks distclean because make attempts to clean inside those first and fails to
> find Makefile (which is also a symlink).

TBH I'm inclined to say "don't do that then".  mving the tree about is
likely to break things and I don't think we support it.

But your patch is harmless so I'm content to apply it - except that
it's missing a s-o-b.

Ie we need your confirmation that the Developer's Certificate of
Origin applies.  See http://wiki.xen.org/wiki/SubmittingXenPatches

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 Feb 20 17:07:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17: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 1U8D8I-0004E4-KS; Wed, 20 Feb 2013 17:07: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 1U8D8G-0004Dw-9j
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:07:00 +0000
Received: from [85.158.138.51:30341] by server-8.bemta-3.messagelabs.com id
	D1/E3-25687-3B205215; Wed, 20 Feb 2013 17:06:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361380018!24364207!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIyODQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6312 invoked from network); 20 Feb 2013 17:06:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 17:06:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="1664621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Feb 2013 17:06: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.297.1; Wed, 20 Feb 2013 17:06:57 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8D8D-0003UJ-C8; Wed, 20 Feb 2013 17:06:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8D8D-0000kW-6p;
	Wed, 20 Feb 2013 17:06:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20773.689.102778.808549@mariner.uk.xensource.com>
Date: Wed, 20 Feb 2013 17:06:57 +0000
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
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] build: Fix distclean when repo location
	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Andrei Lifchits writes ("[Xen-devel] [PATCH] build: Fix distclean when repo location changes"):
> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
> breaks distclean because make attempts to clean inside those first and fails to
> find Makefile (which is also a symlink).

TBH I'm inclined to say "don't do that then".  mving the tree about is
likely to break things and I don't think we support it.

But your patch is harmless so I'm content to apply it - except that
it's missing a s-o-b.

Ie we need your confirmation that the Developer's Certificate of
Origin applies.  See http://wiki.xen.org/wiki/SubmittingXenPatches

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 Feb 20 17:18:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U8DIw-0004On-QM; Wed, 20 Feb 2013 17:18:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U8DIu-0004Oi-Cu
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:18:00 +0000
Received: from [85.158.143.99:17431] by server-1.bemta-4.messagelabs.com id
	EB/D1-06203-74505215; Wed, 20 Feb 2013 17:17:59 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361380678!16966353!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4879 invoked from network); 20 Feb 2013 17:17:59 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 17:17:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID;
	bh=kq8GXjZGsCOMbYPhn2/C/jop0bMpuRhSVZbFP91u+Ts=; 
	b=Eyx2EUC/SaaJPeGtRtI9UcutH/B34Vgwob5yTnbWvwkXvuTVolPUOe5nMLH4nV98L+BcFAIFa/Qntj7W3KzAWj+vX9+rtve45KpaMorLUll5buJuJiIaMXIgY4dbiI7PtkCSNFgrV/bDkCVCK5tL2690WDTmBq61XrzK+3KzsYs=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U8DIr-0004BO-Uo
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:17:58 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id PzvwNjxrKNNr for <xen-devel@lists.xen.org>;
	Wed, 20 Feb 2013 18:17:52 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U8DIm-0004AO-Lh
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:17:52 +0100
Message-ID: <51250539.2040705@crysys.hu>
Date: Wed, 20 Feb 2013 18:17:45 +0100
From: =?ISO-8859-1?Q?G=E1bor_P=C9K?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Subject: [Xen-devel] Deferred/Asynchronous queued invalidation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 am wondering if Xen implements deferred/asynchronous queued
invalidation in order to flush the stale entries from IOTLB.
I know that the synchronous version is implemented in

xen\drivers\passthrough\vtd\qinval.c ,


int invalidate_sync(struct iommu *iommu)
{
    int ret = -1;
    struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);

    if ( qi_ctrl->qinval_maddr != 0 )
    {
        ret = queue_invalidate_wait(iommu, 0, 1, 1);
        return ret;
    }
    return 0;

}


but I could not find anything in the source code about the
deferred/asynchronous version.


Thank you!
-gabor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 17:18:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U8DIw-0004On-QM; Wed, 20 Feb 2013 17:18:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U8DIu-0004Oi-Cu
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:18:00 +0000
Received: from [85.158.143.99:17431] by server-1.bemta-4.messagelabs.com id
	EB/D1-06203-74505215; Wed, 20 Feb 2013 17:17:59 +0000
X-Env-Sender: pek@crysys.hu
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361380678!16966353!1
X-Originating-IP: [152.66.249.135]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4879 invoked from network); 20 Feb 2013 17:17:59 -0000
Received: from shamir.crysys.hit.bme.hu (HELO shamir.crysys.hit.bme.hu)
	(152.66.249.135)
	by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 17:17:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu;
	s=shamir; 
	h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID;
	bh=kq8GXjZGsCOMbYPhn2/C/jop0bMpuRhSVZbFP91u+Ts=; 
	b=Eyx2EUC/SaaJPeGtRtI9UcutH/B34Vgwob5yTnbWvwkXvuTVolPUOe5nMLH4nV98L+BcFAIFa/Qntj7W3KzAWj+vX9+rtve45KpaMorLUll5buJuJiIaMXIgY4dbiI7PtkCSNFgrV/bDkCVCK5tL2690WDTmBq61XrzK+3KzsYs=;
Received: from ip10-105-55.crysys.hit.bme.hu
	([10.105.1.55] helo=localhost ident=amavis)
	by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U8DIr-0004BO-Uo
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:17:58 +0100
X-Virus-Scanned: by amavis-dc
Received: from shamir.crysys.hit.bme.hu ([10.105.1.254])
	by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023)
	with ESMTP id PzvwNjxrKNNr for <xen-devel@lists.xen.org>;
	Wed, 20 Feb 2013 18:17:52 +0100 (CET)
Received: from [10.105.0.95] by shamir.crysys.hit.bme.hu with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <pek@crysys.hu>) id 1U8DIm-0004AO-Lh
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:17:52 +0100
Message-ID: <51250539.2040705@crysys.hu>
Date: Wed, 20 Feb 2013 18:17:45 +0100
From: =?ISO-8859-1?Q?G=E1bor_P=C9K?= <pek@crysys.hu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Subject: [Xen-devel] Deferred/Asynchronous queued invalidation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 am wondering if Xen implements deferred/asynchronous queued
invalidation in order to flush the stale entries from IOTLB.
I know that the synchronous version is implemented in

xen\drivers\passthrough\vtd\qinval.c ,


int invalidate_sync(struct iommu *iommu)
{
    int ret = -1;
    struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);

    if ( qi_ctrl->qinval_maddr != 0 )
    {
        ret = queue_invalidate_wait(iommu, 0, 1, 1);
        return ret;
    }
    return 0;

}


but I could not find anything in the source code about the
deferred/asynchronous version.


Thank you!
-gabor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 17:19:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17:19: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 1U8DJc-0004Qr-7a; Wed, 20 Feb 2013 17:18:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U8DJa-0004Qk-RS
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:18:43 +0000
Received: from [85.158.138.51:56886] by server-13.bemta-3.messagelabs.com id
	E4/6D-20653-27505215; Wed, 20 Feb 2013 17:18:42 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361380721!20389465!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23382 invoked from network); 20 Feb 2013 17:18:41 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 17:18:41 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U8DJO-0004bD-To; Wed, 20 Feb 2013 17:18:30 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U8DJI-0008OZ-KK; Wed, 20 Feb 2013 17:18:30 +0000
Message-ID: <1361380698.26546.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: Laszlo Ersek <lersek@redhat.com>
Date: Wed, 20 Feb 2013 17:18:18 +0000
In-Reply-To: <5124FFED.3000106@redhat.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
	<5124FFED.3000106@redhat.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	David Woodhouse <dwmw2@infradead.org>, Bei Guan <gbtju85@gmail.com>
Subject: Re: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
> However in OVMF the RESERVED_MEMBASE range is not parsed from this
> Xen-exported table, it is added manually in InitializeXen()
> [OvmfPkg/PlatformPei/Xen.c]:
> 
>   //
>   // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
>   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>   //
>   AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);

ICK, it would be far preferable for OVMF to do what SeaBIOS does and
actually "communicate" with hvmloader IMHO.

Ian.

-- 
Ian Campbell
Current Noise: Machine Head - Blistering

Whatever doesn't succeed in two months and a half in California will
never succeed.
		-- Rev. Henry Durant, founder of the University of California


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 17:19:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 17:19: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 1U8DJc-0004Qr-7a; Wed, 20 Feb 2013 17:18:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U8DJa-0004Qk-RS
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 17:18:43 +0000
Received: from [85.158.138.51:56886] by server-13.bemta-3.messagelabs.com id
	E4/6D-20653-27505215; Wed, 20 Feb 2013 17:18:42 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361380721!20389465!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23382 invoked from network); 20 Feb 2013 17:18:41 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	20 Feb 2013 17:18:41 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U8DJO-0004bD-To; Wed, 20 Feb 2013 17:18:30 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U8DJI-0008OZ-KK; Wed, 20 Feb 2013 17:18:30 +0000
Message-ID: <1361380698.26546.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: Laszlo Ersek <lersek@redhat.com>
Date: Wed, 20 Feb 2013 17:18:18 +0000
In-Reply-To: <5124FFED.3000106@redhat.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360755602.20449.228.camel@zakaz.uk.xensource.com>
	<1360756091.10581.53.camel@shinybook.infradead.org>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
	<5124FFED.3000106@redhat.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	David Woodhouse <dwmw2@infradead.org>, Bei Guan <gbtju85@gmail.com>
Subject: Re: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
> However in OVMF the RESERVED_MEMBASE range is not parsed from this
> Xen-exported table, it is added manually in InitializeXen()
> [OvmfPkg/PlatformPei/Xen.c]:
> 
>   //
>   // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
>   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>   //
>   AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);

ICK, it would be far preferable for OVMF to do what SeaBIOS does and
actually "communicate" with hvmloader IMHO.

Ian.

-- 
Ian Campbell
Current Noise: Machine Head - Blistering

Whatever doesn't succeed in two months and a half in California will
never succeed.
		-- Rev. Henry Durant, founder of the University of California


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18:07: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 1U8E4Q-0005HN-Oj; Wed, 20 Feb 2013 18:07:06 +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 1U8E4O-0005H6-PG
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:04 +0000
Received: from [85.158.143.99:50998] by server-3.bemta-4.messagelabs.com id
	08/19-02186-8C015215; Wed, 20 Feb 2013 18:07:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361383622!18637778!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28915 invoked from network); 20 Feb 2013 18:07:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495001"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-92;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: a380b2169803defccefea0d2ade6a7ff7ab21dd2
Message-ID: <a380b2169803defccefe.1361383531@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1 of 5] common/sysctl: Introduce hypercall to
 query the console ring size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 66f563be41d9 -r a380b2169803 xen/common/sysctl.c
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -357,6 +357,9 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xe
     }
     break;
 
+    case XEN_SYSCTL_consoleringsize:
+        ret = console_ring_size(&op->u.consoleringsize);
+        break;
 
     default:
         ret = arch_do_sysctl(op, u_sysctl);
diff -r 66f563be41d9 -r a380b2169803 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -226,6 +226,12 @@ long read_console_ring(struct xen_sysctl
     return 0;
 }
 
+long console_ring_size(struct xen_sysctl_consoleringsize * op)
+{
+    op->size = conring_size;
+    return 0;
+}
+
 
 /*
  * *******************************************************
diff -r 66f563be41d9 -r a380b2169803 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,14 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_consoleringsize */
+/* Get the size of the hypervisor console ring. */
+struct xen_sysctl_consoleringsize {
+    uint64_t size; /* Written by Xen. */
+};
+typedef struct xen_sysctl_consoleringsize xen_sysctl_consoleringsize_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_consoleringsize_t);
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +624,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_consoleringsize               20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +645,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_consoleringsize   consoleringsize;
         uint8_t                             pad[128];
     } u;
 };
diff -r 66f563be41d9 -r a380b2169803 xen/include/xen/console.h
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -12,6 +12,8 @@
 
 struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
+struct xen_sysctl_consoleringsize;
+long console_ring_size(struct xen_sysctl_consoleringsize *op);
 
 void console_init_preirq(void);
 void console_init_postirq(void);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18:07: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 1U8E4Q-0005HN-Oj; Wed, 20 Feb 2013 18:07:06 +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 1U8E4O-0005H6-PG
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:04 +0000
Received: from [85.158.143.99:50998] by server-3.bemta-4.messagelabs.com id
	08/19-02186-8C015215; Wed, 20 Feb 2013 18:07:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361383622!18637778!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28915 invoked from network); 20 Feb 2013 18:07:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495001"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-92;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: a380b2169803defccefea0d2ade6a7ff7ab21dd2
Message-ID: <a380b2169803defccefe.1361383531@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:31 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1 of 5] common/sysctl: Introduce hypercall to
 query the console ring size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 66f563be41d9 -r a380b2169803 xen/common/sysctl.c
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -357,6 +357,9 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xe
     }
     break;
 
+    case XEN_SYSCTL_consoleringsize:
+        ret = console_ring_size(&op->u.consoleringsize);
+        break;
 
     default:
         ret = arch_do_sysctl(op, u_sysctl);
diff -r 66f563be41d9 -r a380b2169803 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -226,6 +226,12 @@ long read_console_ring(struct xen_sysctl
     return 0;
 }
 
+long console_ring_size(struct xen_sysctl_consoleringsize * op)
+{
+    op->size = conring_size;
+    return 0;
+}
+
 
 /*
  * *******************************************************
diff -r 66f563be41d9 -r a380b2169803 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,14 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_consoleringsize */
+/* Get the size of the hypervisor console ring. */
+struct xen_sysctl_consoleringsize {
+    uint64_t size; /* Written by Xen. */
+};
+typedef struct xen_sysctl_consoleringsize xen_sysctl_consoleringsize_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_consoleringsize_t);
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +624,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_consoleringsize               20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +645,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_consoleringsize   consoleringsize;
         uint8_t                             pad[128];
     } u;
 };
diff -r 66f563be41d9 -r a380b2169803 xen/include/xen/console.h
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -12,6 +12,8 @@
 
 struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
+struct xen_sysctl_consoleringsize;
+long console_ring_size(struct xen_sysctl_consoleringsize *op);
 
 void console_init_preirq(void);
 void console_init_postirq(void);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18:07: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 1U8E4R-0005Hi-AY; Wed, 20 Feb 2013 18:07:07 +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 1U8E4Q-0005HM-Gl
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:06 +0000
Received: from [85.158.143.99:54701] by server-1.bemta-4.messagelabs.com id
	75/81-06203-9C015215; Wed, 20 Feb 2013 18:07:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361383622!18637778!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28951 invoked from network); 20 Feb 2013 18:07:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495004"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-9w;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6b8c513cff4f95b4a39facc5d5b3dbdf828dac13
Message-ID: <6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3 of 5] tools/libxc: Implement of
	xc_readconsolering_buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Functions identically to xc_readconsolering(), but uses a user-provided
xc_hypercall_buffer_t to save using a bounce buffer.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 40d1bab1b996 -r 6b8c513cff4f tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -100,6 +100,37 @@ int xc_readconsolering(xc_interface *xch
     return ret;
 }
 
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex)
+{
+    int ret;
+    unsigned int nr_chars = *pnr_chars;
+    DECLARE_SYSCTL;
+    DECLARE_HYPERCALL_BUFFER_ARGUMENT(buffer);
+
+    sysctl.cmd = XEN_SYSCTL_readconsole;
+    set_xen_guest_handle(sysctl.u.readconsole.buffer, buffer);
+    sysctl.u.readconsole.count = nr_chars;
+    sysctl.u.readconsole.clear = clear;
+    sysctl.u.readconsole.incremental = 0;
+    if ( pindex )
+    {
+        sysctl.u.readconsole.index = *pindex;
+        sysctl.u.readconsole.incremental = incremental;
+    }
+
+    if ( (ret = do_sysctl(xch, &sysctl)) == 0 )
+    {
+        *pnr_chars = sysctl.u.readconsole.count;
+        if ( pindex )
+            *pindex = sysctl.u.readconsole.index;
+    }
+
+    return ret;
+}
+
 int xc_consoleringsize(xc_interface *xch, uint64_t * psize)
 {
     int ret = -1;
diff -r 40d1bab1b996 -r 6b8c513cff4f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,10 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex);
 int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18:07: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 1U8E4R-0005Hi-AY; Wed, 20 Feb 2013 18:07:07 +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 1U8E4Q-0005HM-Gl
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:06 +0000
Received: from [85.158.143.99:54701] by server-1.bemta-4.messagelabs.com id
	75/81-06203-9C015215; Wed, 20 Feb 2013 18:07:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361383622!18637778!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28951 invoked from network); 20 Feb 2013 18:07:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495004"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-9w;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: 6b8c513cff4f95b4a39facc5d5b3dbdf828dac13
Message-ID: <6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:33 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 3 of 5] tools/libxc: Implement of
	xc_readconsolering_buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Functions identically to xc_readconsolering(), but uses a user-provided
xc_hypercall_buffer_t to save using a bounce buffer.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 40d1bab1b996 -r 6b8c513cff4f tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -100,6 +100,37 @@ int xc_readconsolering(xc_interface *xch
     return ret;
 }
 
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex)
+{
+    int ret;
+    unsigned int nr_chars = *pnr_chars;
+    DECLARE_SYSCTL;
+    DECLARE_HYPERCALL_BUFFER_ARGUMENT(buffer);
+
+    sysctl.cmd = XEN_SYSCTL_readconsole;
+    set_xen_guest_handle(sysctl.u.readconsole.buffer, buffer);
+    sysctl.u.readconsole.count = nr_chars;
+    sysctl.u.readconsole.clear = clear;
+    sysctl.u.readconsole.incremental = 0;
+    if ( pindex )
+    {
+        sysctl.u.readconsole.index = *pindex;
+        sysctl.u.readconsole.incremental = incremental;
+    }
+
+    if ( (ret = do_sysctl(xch, &sysctl)) == 0 )
+    {
+        *pnr_chars = sysctl.u.readconsole.count;
+        if ( pindex )
+            *pindex = sysctl.u.readconsole.index;
+    }
+
+    return ret;
+}
+
 int xc_consoleringsize(xc_interface *xch, uint64_t * psize)
 {
     int ret = -1;
diff -r 40d1bab1b996 -r 6b8c513cff4f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,10 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex);
 int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18: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 1U8E4O-0005HB-Bq; Wed, 20 Feb 2013 18:07:04 +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 1U8E4M-0005H6-0L
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:02 +0000
Received: from [85.158.143.99:54451] by server-3.bemta-4.messagelabs.com id
	A0/19-02186-5C015215; Wed, 20 Feb 2013 18:07:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361383619!28444293!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30165 invoked from network); 20 Feb 2013 18:07:00 -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;
	20 Feb 2013 18:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8074969"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-Ai;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4ba606ff8cf93c0a470a450455c93fe49b4ce6b3
Message-ID: <4ba606ff8cf93c0a470a.1361383535@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 5 of 5] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large.  Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a73d0c5a5b24 -r 4ba606ff8cf9 tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -51,21 +51,22 @@
 	i1 = (uint32_t) Int64_val(Field(input, 0)); \
 	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
 
-#define ERROR_STRLEN 1024
 void failwith_xc(xc_interface *xch)
 {
-	static char error_str[ERROR_STRLEN];
+	char error_str[256];
 	if (xch) {
 		const xc_error *error = xc_get_last_error(xch);
 		if (error->code == XC_ERROR_NONE)
-                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
+                	snprintf(error_str, sizeof(error_str),
+				 "%d: %s", errno, strerror(errno));
 		else
-			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
-				 error->code,
+			snprintf(error_str, sizeof(error_str),
+				 "%d: %s: %s", error->code,
 				 xc_error_code_to_desc(error->code),
 				 error->message);
 	} else {
-		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
+		snprintf(error_str, sizeof(error_str),
+			 "Unable to open XC interface");
 	}
 	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18: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 1U8E4O-0005HB-Bq; Wed, 20 Feb 2013 18:07:04 +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 1U8E4M-0005H6-0L
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:02 +0000
Received: from [85.158.143.99:54451] by server-3.bemta-4.messagelabs.com id
	A0/19-02186-5C015215; Wed, 20 Feb 2013 18:07:01 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361383619!28444293!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30165 invoked from network); 20 Feb 2013 18:07:00 -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;
	20 Feb 2013 18:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8074969"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-Ai;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: 4ba606ff8cf93c0a470a450455c93fe49b4ce6b3
Message-ID: <4ba606ff8cf93c0a470a.1361383535@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:35 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 5 of 5] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large.  Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a73d0c5a5b24 -r 4ba606ff8cf9 tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -51,21 +51,22 @@
 	i1 = (uint32_t) Int64_val(Field(input, 0)); \
 	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
 
-#define ERROR_STRLEN 1024
 void failwith_xc(xc_interface *xch)
 {
-	static char error_str[ERROR_STRLEN];
+	char error_str[256];
 	if (xch) {
 		const xc_error *error = xc_get_last_error(xch);
 		if (error->code == XC_ERROR_NONE)
-                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
+                	snprintf(error_str, sizeof(error_str),
+				 "%d: %s", errno, strerror(errno));
 		else
-			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
-				 error->code,
+			snprintf(error_str, sizeof(error_str),
+				 "%d: %s: %s", error->code,
 				 xc_error_code_to_desc(error->code),
 				 error->message);
 	} else {
-		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
+		snprintf(error_str, sizeof(error_str),
+			 "Unable to open XC interface");
 	}
 	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:07:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18: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 1U8E4l-0005Jm-Os; Wed, 20 Feb 2013 18:07:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8E4k-0005Jd-6t
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:26 +0000
Received: from [85.158.138.51:3659] by server-12.bemta-3.messagelabs.com id
	57/6C-05889-DD015215; Wed, 20 Feb 2013 18:07:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361383619!24372271!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26695 invoked from network); 20 Feb 2013 18:07:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8494999"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-8Y;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 0 of 5] tools: console ring 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

Hello,

The following set of patches came about when trying to fix the 32K limitation
with stub_xc_readconsolering() in the ocaml bindings.

Patch 1 is a hypervisor patch adding a new SYSCTL hypercall to query the size
of the console ring, which is fixed but otherwise inaccessible after boot.

Patches 2 thru 5 are tools patches:
 * Patch 2 adds a libxc function to use the new SYSCTL hypercall.
 * Patch 3 implements an alternative xc_readconsolering() to prevent bounce
   buffering.
 * Patch 4 uses the preceding patches to fix the implementation of
   stub_xc_readconsolering() in the ocaml bindings.
 * Patch 5 is a misc threading fix in the ocaml bindings, discovered when
   trying to fix the console functionality.

This patch set has been compile-tested on unstable, and functionally tested
via backport to 4.2 (which was only one whitespace fuzz issue and no code
change).

Signed-off-by: Andrew Cooper <andrew.cooper3@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 Feb 20 18:07:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18: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 1U8E4l-0005Jm-Os; Wed, 20 Feb 2013 18:07:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8E4k-0005Jd-6t
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:07:26 +0000
Received: from [85.158.138.51:3659] by server-12.bemta-3.messagelabs.com id
	57/6C-05889-DD015215; Wed, 20 Feb 2013 18:07:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361383619!24372271!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26695 invoked from network); 20 Feb 2013 18:07:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8494999"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-8Y;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 0 of 5] tools: console ring 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

Hello,

The following set of patches came about when trying to fix the 32K limitation
with stub_xc_readconsolering() in the ocaml bindings.

Patch 1 is a hypervisor patch adding a new SYSCTL hypercall to query the size
of the console ring, which is fixed but otherwise inaccessible after boot.

Patches 2 thru 5 are tools patches:
 * Patch 2 adds a libxc function to use the new SYSCTL hypercall.
 * Patch 3 implements an alternative xc_readconsolering() to prevent bounce
   buffering.
 * Patch 4 uses the preceding patches to fix the implementation of
   stub_xc_readconsolering() in the ocaml bindings.
 * Patch 5 is a misc threading fix in the ocaml bindings, discovered when
   trying to fix the console functionality.

This patch set has been compile-tested on unstable, and functionally tested
via backport to 4.2 (which was only one whitespace fuzz issue and no code
change).

Signed-off-by: Andrew Cooper <andrew.cooper3@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 Feb 20 18:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18:08: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 1U8E5K-0005Rw-77; Wed, 20 Feb 2013 18:08:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8E5I-0005RP-J8
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:08:00 +0000
Received: from [85.158.138.51:25687] by server-14.bemta-3.messagelabs.com id
	58/FB-23533-FF015215; Wed, 20 Feb 2013 18:07:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361383619!24372271!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27034 invoked from network); 20 Feb 2013 18:07:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495000"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-9Z;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: 40d1bab1b9963907452e3c777fb8f9d761568839
Message-ID: <40d1bab1b9963907452e.1361383532@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2 of 5] tools/libxc: Helper function for
 XEN_SYSCTL_consoleringsize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a380b2169803 -r 40d1bab1b996 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -100,6 +100,26 @@ int xc_readconsolering(xc_interface *xch
     return ret;
 }
 
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize)
+{
+    int ret = -1;
+    DECLARE_SYSCTL;
+
+    if ( ! psize )
+    {
+        errno = EFAULT;
+        return ret;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_consoleringsize;
+    ret = do_sysctl(xch, &sysctl);
+
+    if ( ! ret )
+        *psize = sysctl.u.consoleringsize.size;
+
+    return ret;
+}
+
 int xc_send_debug_keys(xc_interface *xch, char *keys)
 {
     int ret, len = strlen(keys);
diff -r a380b2169803 -r 40d1bab1b996 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,7 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:08:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18:08: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 1U8E5K-0005Rw-77; Wed, 20 Feb 2013 18:08:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8E5I-0005RP-J8
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:08:00 +0000
Received: from [85.158.138.51:25687] by server-14.bemta-3.messagelabs.com id
	58/FB-23533-FF015215; Wed, 20 Feb 2013 18:07:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361383619!24372271!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27034 invoked from network); 20 Feb 2013 18:07:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495000"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-9Z;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: 40d1bab1b9963907452e3c777fb8f9d761568839
Message-ID: <40d1bab1b9963907452e.1361383532@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2 of 5] tools/libxc: Helper function for
 XEN_SYSCTL_consoleringsize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a380b2169803 -r 40d1bab1b996 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -100,6 +100,26 @@ int xc_readconsolering(xc_interface *xch
     return ret;
 }
 
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize)
+{
+    int ret = -1;
+    DECLARE_SYSCTL;
+
+    if ( ! psize )
+    {
+        errno = EFAULT;
+        return ret;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_consoleringsize;
+    ret = do_sysctl(xch, &sysctl);
+
+    if ( ! ret )
+        *psize = sysctl.u.consoleringsize.size;
+
+    return ret;
+}
+
 int xc_send_debug_keys(xc_interface *xch, char *keys)
 {
     int ret, len = strlen(keys);
diff -r a380b2169803 -r 40d1bab1b996 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,7 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:08:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U8E5K-0005S8-K9; Wed, 20 Feb 2013 18:08:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8E5I-0005RR-Ir
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:08:00 +0000
Received: from [85.158.138.51:25696] by server-4.bemta-3.messagelabs.com id
	EB/32-17521-FF015215; Wed, 20 Feb 2013 18:07:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361383619!24372271!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27240 invoked from network); 20 Feb 2013 18:07:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495002"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-AJ;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: a73d0c5a5b24cdc1cfe7fdacdd77022c474d47e2
Message-ID: <a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:34 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 4 of 5] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two problems with this function:
  * The caml_{enter,leave}_blocking_section() calls mean that two threads can
    compete for use of the static ring[] buffer.
  * It fails to retrieve the entire buffer if the hypervisor has used 32K or
    more of its console ring.

Rewrite the function using the new xc_consoleringsize() and
xc_readconsolering_buffer() functions to efficiently grab the entire console
ring.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 6b8c513cff4f -r a73d0c5a5b24 tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -523,27 +523,61 @@ CAMLprim value stub_xc_evtchn_reset(valu
 	CAMLreturn(Val_unit);
 }
 
-
-#define RING_SIZE 32768
-static char ring[RING_SIZE];
-
+/* Maximum size of console ring we are prepared to read, 16MB */
+#define MAX_CONSOLE_RING_SIZE (1U << 24)
 CAMLprim value stub_xc_readconsolering(value xch)
 {
-	unsigned int size = RING_SIZE - 1;
-	char *ring_ptr = ring;
-	int retval;
+	uint64_t conring_size;
+	DECLARE_HYPERCALL_BUFFER(char, ring);
+	unsigned int nr_chars;
+	int r;
 
 	CAMLparam1(xch);
+	CAMLlocal1(conring);
+
+	r = xc_consoleringsize(_H(xch), &conring_size);
+
+	if ( r )
+	{
+		failwith_xc(_H(xch));
+		CAMLreturn(Val_unit);
+	}
+
+	/* Round conring_size up to the next page, for NULL terminator and
+	   slop from a race with printk() in the hypervisor. */
+	conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
+	nr_chars = conring_size-1;
+
+	if ( conring_size > MAX_CONSOLE_RING_SIZE )
+	{
+		caml_failwith("Console ring too large");
+		CAMLreturn(Val_unit);
+	}
+
+	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
+
+	if ( ! ring )
+	{
+		failwith_xc(_H(xch));
+		CAMLreturn(Val_unit);
+	}
 
 	caml_enter_blocking_section();
-	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
+	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
+				      &nr_chars, 0, 0, NULL);
 	caml_leave_blocking_section();
 
-	if (retval)
+	if ( r )
+	{
 		failwith_xc(_H(xch));
+		xc_hypercall_buffer_free(_H(xch), ring);
+		CAMLreturn(Val_unit);
+	}
 
-	ring[size] = '\0';
-	CAMLreturn(caml_copy_string(ring));
+	ring[nr_chars] = '\0';
+	conring = caml_copy_string(ring);
+	xc_hypercall_buffer_free(_H(xch), ring);
+	CAMLreturn(conring);
 }
 
 CAMLprim value stub_xc_send_debug_keys(value xch, value keys)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:08:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 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 1U8E5K-0005S8-K9; Wed, 20 Feb 2013 18:08:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8E5I-0005RR-Ir
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 18:08:00 +0000
Received: from [85.158.138.51:25696] by server-4.bemta-3.messagelabs.com id
	EB/32-17521-FF015215; Wed, 20 Feb 2013 18:07:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361383619!24372271!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAwMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27240 invoked from network); 20 Feb 2013 18:07:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:07:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8495002"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:06:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:06:58 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8E4I-00049s-AJ;
	Wed, 20 Feb 2013 18:06:58 +0000
MIME-Version: 1.0
X-Mercurial-Node: a73d0c5a5b24cdc1cfe7fdacdd77022c474d47e2
Message-ID: <a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Wed, 20 Feb 2013 18:05:34 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 4 of 5] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two problems with this function:
  * The caml_{enter,leave}_blocking_section() calls mean that two threads can
    compete for use of the static ring[] buffer.
  * It fails to retrieve the entire buffer if the hypervisor has used 32K or
    more of its console ring.

Rewrite the function using the new xc_consoleringsize() and
xc_readconsolering_buffer() functions to efficiently grab the entire console
ring.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 6b8c513cff4f -r a73d0c5a5b24 tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -523,27 +523,61 @@ CAMLprim value stub_xc_evtchn_reset(valu
 	CAMLreturn(Val_unit);
 }
 
-
-#define RING_SIZE 32768
-static char ring[RING_SIZE];
-
+/* Maximum size of console ring we are prepared to read, 16MB */
+#define MAX_CONSOLE_RING_SIZE (1U << 24)
 CAMLprim value stub_xc_readconsolering(value xch)
 {
-	unsigned int size = RING_SIZE - 1;
-	char *ring_ptr = ring;
-	int retval;
+	uint64_t conring_size;
+	DECLARE_HYPERCALL_BUFFER(char, ring);
+	unsigned int nr_chars;
+	int r;
 
 	CAMLparam1(xch);
+	CAMLlocal1(conring);
+
+	r = xc_consoleringsize(_H(xch), &conring_size);
+
+	if ( r )
+	{
+		failwith_xc(_H(xch));
+		CAMLreturn(Val_unit);
+	}
+
+	/* Round conring_size up to the next page, for NULL terminator and
+	   slop from a race with printk() in the hypervisor. */
+	conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
+	nr_chars = conring_size-1;
+
+	if ( conring_size > MAX_CONSOLE_RING_SIZE )
+	{
+		caml_failwith("Console ring too large");
+		CAMLreturn(Val_unit);
+	}
+
+	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
+
+	if ( ! ring )
+	{
+		failwith_xc(_H(xch));
+		CAMLreturn(Val_unit);
+	}
 
 	caml_enter_blocking_section();
-	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
+	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
+				      &nr_chars, 0, 0, NULL);
 	caml_leave_blocking_section();
 
-	if (retval)
+	if ( r )
+	{
 		failwith_xc(_H(xch));
+		xc_hypercall_buffer_free(_H(xch), ring);
+		CAMLreturn(Val_unit);
+	}
 
-	ring[size] = '\0';
-	CAMLreturn(caml_copy_string(ring));
+	ring[nr_chars] = '\0';
+	conring = caml_copy_string(ring);
+	xc_hypercall_buffer_free(_H(xch), ring);
+	CAMLreturn(conring);
 }
 
 CAMLprim value stub_xc_send_debug_keys(value xch, value keys)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 18:17:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18: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 1U8EDq-0006Eh-MA; Wed, 20 Feb 2013 18:16: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 1U8EDp-0006Ec-CD
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 18:16:49 +0000
Received: from [85.158.139.211:50441] by server-11.bemta-5.messagelabs.com id
	42/12-19159-01315215; Wed, 20 Feb 2013 18:16:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361384202!18460231!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2819 invoked from network); 20 Feb 2013 18:16:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8077870"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:16:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:16:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8EDh-0004K1-8l;
	Wed, 20 Feb 2013 18:16:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 18:16:37 +0000
Message-ID: <1361384197-27455-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3] xen/arm: phys_timer 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

Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.

Do not let the user set CNTx_CTL_PENDING directly.

Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.

Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.


Changes in v3:
- do not modify the guest's register.

Changes in v2:
- do not let the user set CNTx_CTL_PENDING directly;
- set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c        |   10 +++++++---
 xen/include/asm-arm/domain.h |    4 ++--
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index f4326f8..7341e06 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
 {
     struct vtimer *t = data;
     t->ctl |= CNTx_CTL_PENDING;
-    t->ctl &= ~CNTx_CTL_MASK;
-    vgic_vcpu_inject_irq(t->v, 30, 1);
+    if ( !(t->ctl & CNTx_CTL_MASK) )
+        vgic_vcpu_inject_irq(t->v, 30, 1);
 }
 
 static void virt_timer_expired(void *data)
@@ -117,7 +117,10 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         }
         else
         {
-            v->arch.phys_timer.ctl = *r;
+            uint32_t ctl = *r & ~CNTx_CTL_PENDING;
+            if ( ctl & CNTx_CTL_ENABLE )
+                ctl |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;
+            v->arch.phys_timer.ctl = ctl;
 
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
             {
@@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
             v->arch.phys_timer.cval = now + ticks_to_ns(*r);
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
             {
+                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
             }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index fecf43b..5c4c0ca 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -79,8 +79,8 @@ struct vtimer {
         int irq;
         struct timer timer;
         uint32_t ctl;
-        s_time_t offset;
-        s_time_t cval;
+        uint64_t offset;
+        uint64_t cval;
 };
 
 struct arch_vcpu
-- 
1.7.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 Feb 20 18:17:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 18: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 1U8EDq-0006Eh-MA; Wed, 20 Feb 2013 18:16: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 1U8EDp-0006Ec-CD
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 18:16:49 +0000
Received: from [85.158.139.211:50441] by server-11.bemta-5.messagelabs.com id
	42/12-19159-01315215; Wed, 20 Feb 2013 18:16:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361384202!18460231!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2819 invoked from network); 20 Feb 2013 18:16:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 18:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; 
   d="scan'208";a="8077870"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 18:16:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 13:16:41 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8EDh-0004K1-8l;
	Wed, 20 Feb 2013 18:16:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 20 Feb 2013 18:16:37 +0000
Message-ID: <1361384197-27455-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3] xen/arm: phys_timer 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

Do not unmask the emulated phys_timer when the related Xen timer
expires.
Do not inject the phys_timer interrupt if it is masked.

Do not let the user set CNTx_CTL_PENDING directly.

Set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.

Define offset and cval as uint64_t given that they can't be negative and
they are used as uint64_t arguments.


Changes in v3:
- do not modify the guest's register.

Changes in v2:
- do not let the user set CNTx_CTL_PENDING directly;
- set CNTx_CTL_PENDING when the phys_timer expires and clear it when the
phys_timer is disabled or the compare value is changed.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/arm/vtimer.c        |   10 +++++++---
 xen/include/asm-arm/domain.h |    4 ++--
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index f4326f8..7341e06 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -33,8 +33,8 @@ static void phys_timer_expired(void *data)
 {
     struct vtimer *t = data;
     t->ctl |= CNTx_CTL_PENDING;
-    t->ctl &= ~CNTx_CTL_MASK;
-    vgic_vcpu_inject_irq(t->v, 30, 1);
+    if ( !(t->ctl & CNTx_CTL_MASK) )
+        vgic_vcpu_inject_irq(t->v, 30, 1);
 }
 
 static void virt_timer_expired(void *data)
@@ -117,7 +117,10 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
         }
         else
         {
-            v->arch.phys_timer.ctl = *r;
+            uint32_t ctl = *r & ~CNTx_CTL_PENDING;
+            if ( ctl & CNTx_CTL_ENABLE )
+                ctl |= v->arch.phys_timer.ctl & CNTx_CTL_PENDING;
+            v->arch.phys_timer.ctl = ctl;
 
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
             {
@@ -141,6 +144,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
             v->arch.phys_timer.cval = now + ticks_to_ns(*r);
             if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
             {
+                v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
                 set_timer(&v->arch.phys_timer.timer,
                           v->arch.phys_timer.cval + v->arch.phys_timer.offset);
             }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index fecf43b..5c4c0ca 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -79,8 +79,8 @@ struct vtimer {
         int irq;
         struct timer timer;
         uint32_t ctl;
-        s_time_t offset;
-        s_time_t cval;
+        uint64_t offset;
+        uint64_t cval;
 };
 
 struct arch_vcpu
-- 
1.7.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 Feb 20 20:36:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GOO-0007un-SH; Wed, 20 Feb 2013 20:35:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GON-0007ug-PO
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:35:51 +0000
Received: from [85.158.139.211:12292] by server-14.bemta-5.messagelabs.com id
	73/64-06967-7A335215; Wed, 20 Feb 2013 20:35:51 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361392550!18413521!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30602 invoked from network); 20 Feb 2013 20:35:50 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 20:35:50 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1E640C5618C;
	Wed, 20 Feb 2013 20:35:38 +0000 (GMT)
Date: Wed, 20 Feb 2013 20:35:36 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <E951E8DE28E9D9BF98957952@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302201223500.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
	<8C4820ECA744AD74C30515BF@nimrod.local>
	<alpine.DEB.2.02.1302201223500.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 20 February 2013 12:30:45 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> Also add a call to xen_modified_memory from
> cpu_physical_memory_set_dirty, if I am not mistaken that should solve
> the problem with the dirty vram.

I think I now recall why I did not do this.

Firstly, cpu_physical_memory_set_dirty is inline, and I'd have to check
(presumably) xen_enabled() then call a non-inline function. This seemed
a bit much to satisfy only the needs of the VRAM check as (as far as I
could tell - I may well be wrong) xen_modifed_memory was being called
appropriately by all the other callers anyway.

Secondly, if I do need to modify this one, it seemed odd that I'd need
not need to modify cpu_physical_set_dirty_flags.

It seemed cleaner just to fix up the VRAM stuff.

What do you think? I'll send another patch series with everything else
in.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:36:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GOO-0007un-SH; Wed, 20 Feb 2013 20:35:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GON-0007ug-PO
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:35:51 +0000
Received: from [85.158.139.211:12292] by server-14.bemta-5.messagelabs.com id
	73/64-06967-7A335215; Wed, 20 Feb 2013 20:35:51 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361392550!18413521!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30602 invoked from network); 20 Feb 2013 20:35:50 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 20:35:50 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1E640C5618C;
	Wed, 20 Feb 2013 20:35:38 +0000 (GMT)
Date: Wed, 20 Feb 2013 20:35:36 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <E951E8DE28E9D9BF98957952@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302201223500.4654@kaball.uk.xensource.com>
References: <1361279850-8246-1-git-send-email-alex@alex.org.uk>
	<1361279850-8246-5-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302191748010.4654@kaball.uk.xensource.com>
	<8C4820ECA744AD74C30515BF@nimrod.local>
	<alpine.DEB.2.02.1302201223500.4654@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv4 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 20 February 2013 12:30:45 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> Also add a call to xen_modified_memory from
> cpu_physical_memory_set_dirty, if I am not mistaken that should solve
> the problem with the dirty vram.

I think I now recall why I did not do this.

Firstly, cpu_physical_memory_set_dirty is inline, and I'd have to check
(presumably) xen_enabled() then call a non-inline function. This seemed
a bit much to satisfy only the needs of the VRAM check as (as far as I
could tell - I may well be wrong) xen_modifed_memory was being called
appropriately by all the other callers anyway.

Secondly, if I do need to modify this one, it seemed odd that I'd need
not need to modify cpu_physical_set_dirty_flags.

It seemed cleaner just to fix up the VRAM stuff.

What do you think? I'll send another patch series with everything else
in.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:50:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20:50: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 1U8GcB-0008AN-9o; Wed, 20 Feb 2013 20:50: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 1U8Gc9-0008AI-IA
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 20:50:05 +0000
Received: from [85.158.138.51:31464] by server-15.bemta-3.messagelabs.com id
	A4/32-25405-CF635215; Wed, 20 Feb 2013 20:50:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361393402!9756070!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM1NDg4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25965 invoked from network); 20 Feb 2013 20:50:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2013 20:50:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1KKniij003699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 20:49:45 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
	r1KKnhjW009694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 20:49:44 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
	r1KKngB7014169; Wed, 20 Feb 2013 14:49:42 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Feb 2013 12:49:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CB7CC1C3935; Wed, 20 Feb 2013 15:49:41 -0500 (EST)
Date: Wed, 20 Feb 2013 15:49:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Message-ID: <20130220204941.GC4526@phenom.dumpdata.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
	<DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
	<4696812.SKkpQQd9iW@vostro.rjw.lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4696812.SKkpQQd9iW@vostro.rjw.lan>
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>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > Date:   Wed Feb 13 14:36:47 2013 +0100
> > > 
> > >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > > 
> > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > > acpi_scan_lock (new in my tree as well).
> > 
> > Yes, we noticed that and only need minor updates at xen side, will send out
> > 2 xen patches later accordingly, for cleanup and adding lock.
> 
> Thanks, but those new changes will only make sense after merging the Xen tree
> with the PM tree.  Why don't we queue them up for merging later after both
> the Xen and PM trees have been pulled from?

OK, I've created a branch (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
that has your branch and my branch - along with the fix from Stephan and then
the three updates from Jinsong. Jinsong, please check that I've got all the
right patches. I will rebase it once Linus has merged both of the Xen and PM trees.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:50:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20:50: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 1U8GcB-0008AN-9o; Wed, 20 Feb 2013 20:50: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 1U8Gc9-0008AI-IA
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 20:50:05 +0000
Received: from [85.158.138.51:31464] by server-15.bemta-3.messagelabs.com id
	A4/32-25405-CF635215; Wed, 20 Feb 2013 20:50:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361393402!9756070!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM1NDg4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25965 invoked from network); 20 Feb 2013 20:50:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Feb 2013 20:50:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1KKniij003699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 20:49:45 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
	r1KKnhjW009694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 20:49:44 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
	r1KKngB7014169; Wed, 20 Feb 2013 14:49:42 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Feb 2013 12:49:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CB7CC1C3935; Wed, 20 Feb 2013 15:49:41 -0500 (EST)
Date: Wed, 20 Feb 2013 15:49:41 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Message-ID: <20130220204941.GC4526@phenom.dumpdata.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
	<DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
	<4696812.SKkpQQd9iW@vostro.rjw.lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4696812.SKkpQQd9iW@vostro.rjw.lan>
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>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > Date:   Wed Feb 13 14:36:47 2013 +0100
> > > 
> > >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > > 
> > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > > acpi_scan_lock (new in my tree as well).
> > 
> > Yes, we noticed that and only need minor updates at xen side, will send out
> > 2 xen patches later accordingly, for cleanup and adding lock.
> 
> Thanks, but those new changes will only make sense after merging the Xen tree
> with the PM tree.  Why don't we queue them up for merging later after both
> the Xen and PM trees have been pulled from?

OK, I've created a branch (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
that has your branch and my branch - along with the fix from Stephan and then
the three updates from Jinsong. Jinsong, please check that I've got all the
right patches. I will rebase it once Linus has merged both of the Xen and PM trees.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiH-0008RH-AJ; Wed, 20 Feb 2013 20:56:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiG-0008Qq-8i
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:24 +0000
Received: from [85.158.137.99:43441] by server-9.bemta-3.messagelabs.com id
	28/D7-09484-47835215; Wed, 20 Feb 2013 20:56:20 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361393776!17296476!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15845 invoked from network); 20 Feb 2013 20:56:16 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 20:56:16 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 9A2F7C56196;
	Wed, 20 Feb 2013 20:56:05 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:55 +0000
Message-Id: <1361393761-957-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
	qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch series consists of 2	parts:
* 11 patches to	libxl
* 6 patches to QEMU

The 11 patches to libxl are unchanged and I am not resending
them this time.

The 6 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

I would	suggest these patches should be included in 4.2.2.

I have made minor changes per Stefano Stabellini's requests and
these patches are compile-tested only and sent for comment. The
changes are:
* TB invalidation patch backported
* Patch 3 (now 4) now applies cleanly, so no need to break whitespace
* Comment added to patch 4 (now 5)
* Comment added to patch 5 (now 6)

I did not redo the VRAM patch (patch 5, now patch 6) for the reasons
set out separately, but added a comment to explain the problem instead.

Alex Bligh (6):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  cpu_physical_memory_write_rom() needs to do TB invalidates
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occurs.

 exec.c           |   49 +++++++++++++++++++++----------------------------
 hw/xen.h         |    1 +
 memory.c         |    4 ++++
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
 xen-stub.c       |    9 +++++++++
 7 files changed, 117 insertions(+), 30 deletions(-)

-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiH-0008RH-AJ; Wed, 20 Feb 2013 20:56:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiG-0008Qq-8i
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:24 +0000
Received: from [85.158.137.99:43441] by server-9.bemta-3.messagelabs.com id
	28/D7-09484-47835215; Wed, 20 Feb 2013 20:56:20 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361393776!17296476!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15845 invoked from network); 20 Feb 2013 20:56:16 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 20:56:16 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 9A2F7C56196;
	Wed, 20 Feb 2013 20:56:05 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:55 +0000
Message-Id: <1361393761-957-1-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
	qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 patch series consists of 2	parts:
* 11 patches to	libxl
* 6 patches to QEMU

The 11 patches to libxl are unchanged and I am not resending
them this time.

The 6 patches to QEMU are unchanged since version 2 of the patch.

These patches enable live-migrate on HVM using the upstream qemu-xen
device model under Xen 4.2. Currently this is unimplemented. In	the
main they are backports of patches in xen-unstable, thought the
QEMU side in particular needed some fiddling.

I would	suggest these patches should be included in 4.2.2.

I have made minor changes per Stefano Stabellini's requests and
these patches are compile-tested only and sent for comment. The
changes are:
* TB invalidation patch backported
* Patch 3 (now 4) now applies cleanly, so no need to break whitespace
* Comment added to patch 4 (now 5)
* Comment added to patch 5 (now 6)

I did not redo the VRAM patch (patch 5, now patch 6) for the reasons
set out separately, but added a comment to explain the problem instead.

Alex Bligh (6):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  cpu_physical_memory_write_rom() needs to do TB invalidates
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occurs.

 exec.c           |   49 +++++++++++++++++++++----------------------------
 hw/xen.h         |    1 +
 memory.c         |    4 ++++
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
 xen-stub.c       |    9 +++++++++
 7 files changed, 117 insertions(+), 30 deletions(-)

-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiC-0008Q3-Mm; Wed, 20 Feb 2013 20:56:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiA-0008Pc-Ut
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:19 +0000
Received: from [85.158.139.83:53886] by server-15.bemta-5.messagelabs.com id
	08/10-18914-27835215; Wed, 20 Feb 2013 20:56:18 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361393777!27641852!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9627 invoked from network); 20 Feb 2013 20:56:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-182.messagelabs.com with SMTP;
	20 Feb 2013 20:56:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C7291C5619B;
	Wed, 20 Feb 2013 20:56:16 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:58 +0000
Message-Id: <1361393761-957-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 3/6] cpu_physical_memory_write_rom() needs to
	do TB invalidates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.

However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
doesn't invalidate any cached TBs which might be affected by the region
written.

This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh).  When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.

This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().

Backport of original commit 0b57e287138728f72d88b06e69b970c5d745c44a

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 6c206ff..2a35944 100644
--- a/exec.c
+++ b/exec.c
@@ -4081,6 +4081,13 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
+            if (!cpu_physical_memory_is_dirty(addr1)) {
+                /* invalidate code */
+                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+                /* set dirty bit */
+                cpu_physical_memory_set_dirty_flags(
+                    addr1, (0xff & ~CODE_DIRTY_FLAG));
+            }
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiC-0008Q3-Mm; Wed, 20 Feb 2013 20:56:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiA-0008Pc-Ut
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:19 +0000
Received: from [85.158.139.83:53886] by server-15.bemta-5.messagelabs.com id
	08/10-18914-27835215; Wed, 20 Feb 2013 20:56:18 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361393777!27641852!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9627 invoked from network); 20 Feb 2013 20:56:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-182.messagelabs.com with SMTP;
	20 Feb 2013 20:56:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C7291C5619B;
	Wed, 20 Feb 2013 20:56:16 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:58 +0000
Message-Id: <1361393761-957-4-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 3/6] cpu_physical_memory_write_rom() needs to
	do TB invalidates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.

However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
doesn't invalidate any cached TBs which might be affected by the region
written.

This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh).  When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.

This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().

Backport of original commit 0b57e287138728f72d88b06e69b970c5d745c44a

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 6c206ff..2a35944 100644
--- a/exec.c
+++ b/exec.c
@@ -4081,6 +4081,13 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
+            if (!cpu_physical_memory_is_dirty(addr1)) {
+                /* invalidate code */
+                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
+                /* set dirty bit */
+                cpu_physical_memory_set_dirty_flags(
+                    addr1, (0xff & ~CODE_DIRTY_FLAG));
+            }
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiD-0008QA-3p; Wed, 20 Feb 2013 20:56:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiB-0008Ph-7Q
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:19 +0000
Received: from [85.158.139.83:61973] by server-13.bemta-5.messagelabs.com id
	4B/6C-06769-27835215; Wed, 20 Feb 2013 20:56:18 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361393777!28212669!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24651 invoked from network); 20 Feb 2013 20:56:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	20 Feb 2013 20:56:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 92D80C561A0;
	Wed, 20 Feb 2013 20:56:17 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:56:00 +0000
Message-Id: <1361393761-957-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 5/6] exec, memory: Call to xen_modified_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>
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 patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Note a call to xen_modify_memory has been added to qemu_ram_alloc_from_ptr
as the upstream version does:
  cpu_physical_memory_set_dirty_range(new_block->offset, size, 0xff);
and this function does not exist in 4.2.

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c   |    4 ++++
 memory.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 07a6f68..fec1b05 100644
--- a/exec.c
+++ b/exec.c
@@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
            0xff, size >> TARGET_PAGE_BITS);
 
+    if (xen_enabled())
+        xen_modified_memory(new_block->offset, size);
+
     if (kvm_enabled())
         kvm_setup_guest_memory(new_block->host, size);
 
@@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 7c20a07..6e0c596 100644
--- a/memory.c
+++ b/memory.c
@@ -16,6 +16,7 @@
 #include "ioport.h"
 #include "bitops.h"
 #include "kvm.h"
+#include "hw/xen.h"
 #include <assert.h>
 
 unsigned memory_region_transaction_depth = 0;
@@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
 {
     assert(mr->terminates);
+    if (xen_enabled())
+        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
+                            TARGET_PAGE_SIZE);
     return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiD-0008QA-3p; Wed, 20 Feb 2013 20:56:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiB-0008Ph-7Q
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:19 +0000
Received: from [85.158.139.83:61973] by server-13.bemta-5.messagelabs.com id
	4B/6C-06769-27835215; Wed, 20 Feb 2013 20:56:18 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361393777!28212669!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24651 invoked from network); 20 Feb 2013 20:56:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-5.tower-182.messagelabs.com with SMTP;
	20 Feb 2013 20:56:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 92D80C561A0;
	Wed, 20 Feb 2013 20:56:17 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:56:00 +0000
Message-Id: <1361393761-957-6-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 5/6] exec, memory: Call to xen_modified_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>
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 patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Note a call to xen_modify_memory has been added to qemu_ram_alloc_from_ptr
as the upstream version does:
  cpu_physical_memory_set_dirty_range(new_block->offset, size, 0xff);
and this function does not exist in 4.2.

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c   |    4 ++++
 memory.c |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/exec.c b/exec.c
index 07a6f68..fec1b05 100644
--- a/exec.c
+++ b/exec.c
@@ -2988,6 +2988,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const char *name,
     memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
            0xff, size >> TARGET_PAGE_BITS);
 
+    if (xen_enabled())
+        xen_modified_memory(new_block->offset, size);
+
     if (kvm_enabled())
         kvm_setup_guest_memory(new_block->host, size);
 
@@ -3961,6 +3964,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 7c20a07..6e0c596 100644
--- a/memory.c
+++ b/memory.c
@@ -16,6 +16,7 @@
 #include "ioport.h"
 #include "bitops.h"
 #include "kvm.h"
+#include "hw/xen.h"
 #include <assert.h>
 
 unsigned memory_region_transaction_depth = 0;
@@ -1065,6 +1066,9 @@ bool memory_region_get_dirty(MemoryRegion *mr, target_phys_addr_t addr,
 void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr)
 {
     assert(mr->terminates);
+    if (xen_enabled())
+        xen_modified_memory((mr->ram_addr + addr) & TARGET_PAGE_MASK,
+                            TARGET_PAGE_SIZE);
     return cpu_physical_memory_set_dirty(mr->ram_addr + addr);
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiE-0008Qf-Sl; Wed, 20 Feb 2013 20:56:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiE-0008QL-6x
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:22 +0000
Received: from [85.158.137.99:45435] by server-11.bemta-3.messagelabs.com id
	71/56-10249-37835215; Wed, 20 Feb 2013 20:56:19 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361393778!14021771!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 20 Feb 2013 20:56:18 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 20:56:18 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id F35D1C561A2;
	Wed, 20 Feb 2013 20:56:17 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:56:01 +0000
Message-Id: <1361393761-957-7-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 6/6] xen: Set the vram dirty when an error
	occurs.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

This backport is less clean that it might be because there is no
memory_region_set_dirty that copes with more than one page in 4.2,
and the case where the call to xc_hvm_track_dirty_vram is
successful also needs to ensure xen_modified_memory is
called (which would on unstable have been done within
memory_region_set_dirty).

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 xen-all.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 121289d..dbd759c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
@@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
         while (map != 0) {
             j = ffsl(map) - 1;
             map &= ~(1ul << j);
-            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
+            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
+            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
+            cpu_physical_memory_set_dirty(todirty);
         };
     }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiE-0008Qf-Sl; Wed, 20 Feb 2013 20:56:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiE-0008QL-6x
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:22 +0000
Received: from [85.158.137.99:45435] by server-11.bemta-3.messagelabs.com id
	71/56-10249-37835215; Wed, 20 Feb 2013 20:56:19 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361393778!14021771!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 20 Feb 2013 20:56:18 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 20:56:18 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id F35D1C561A2;
	Wed, 20 Feb 2013 20:56:17 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:56:01 +0000
Message-Id: <1361393761-957-7-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 6/6] xen: Set the vram dirty when an error
	occurs.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

This backport is less clean that it might be because there is no
memory_region_set_dirty that copes with more than one page in 4.2,
and the case where the call to xc_hvm_track_dirty_vram is
successful also needs to ensure xen_modified_memory is
called (which would on unstable have been done within
memory_region_set_dirty).

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 xen-all.c |   20 ++++++++++++++++++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 121289d..dbd759c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
@@ -479,7 +493,9 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
         while (map != 0) {
             j = ffsl(map) - 1;
             map &= ~(1ul << j);
-            cpu_physical_memory_set_dirty(vram_offset + (i * width + j) * TARGET_PAGE_SIZE);
+            target_phys_addr_t todirty = vram_offset + (i * width + j) * TARGET_PAGE_SIZE;
+            xen_modified_memory(todirty, TARGET_PAGE_SIZE);
+            cpu_physical_memory_set_dirty(todirty);
         };
     }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiI-0008RY-OI; Wed, 20 Feb 2013 20:56:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiG-0008Qz-UD
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:25 +0000
Received: from [85.158.137.99:45531] by server-13.bemta-3.messagelabs.com id
	E5/70-20653-57835215; Wed, 20 Feb 2013 20:56:21 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361393776!17172522!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5689 invoked from network); 20 Feb 2013 20:56:16 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 20:56:16 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 07640C56198;
	Wed, 20 Feb 2013 20:56:15 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:56 +0000
Message-Id: <1361393761-957-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 1/6] QMP,
	Introduce xen-set-global-dirty-log 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>
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 command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |    6 ++++++
 xen-stub.c       |    5 +++++
 4 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index a669e98..bb0d7c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -905,3 +905,16 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.3
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index bf1df49..0de68df 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -472,6 +472,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/xen-all.c b/xen-all.c
index 3256509..6b4e511 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -12,6 +12,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -524,6 +525,11 @@ static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
     .log_stop = xen_log_stop,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    cpu_physical_memory_set_dirty_tracking(!!enable);
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..25317ec 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiI-0008RY-OI; Wed, 20 Feb 2013 20:56:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiG-0008Qz-UD
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:25 +0000
Received: from [85.158.137.99:45531] by server-13.bemta-3.messagelabs.com id
	E5/70-20653-57835215; Wed, 20 Feb 2013 20:56:21 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361393776!17172522!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOMQ
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5689 invoked from network); 20 Feb 2013 20:56:16 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-217.messagelabs.com with SMTP;
	20 Feb 2013 20:56:16 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 07640C56198;
	Wed, 20 Feb 2013 20:56:15 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:56 +0000
Message-Id: <1361393761-957-2-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 1/6] QMP,
	Introduce xen-set-global-dirty-log 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>
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 command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 qapi-schema.json |   13 +++++++++++++
 qmp-commands.hx  |   24 ++++++++++++++++++++++++
 xen-all.c        |    6 ++++++
 xen-stub.c       |    5 +++++
 4 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index a669e98..bb0d7c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -905,3 +905,16 @@
 # Since: 1.1
 ##
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
+
+##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.3
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index bf1df49..0de68df 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -472,6 +472,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/xen-all.c b/xen-all.c
index 3256509..6b4e511 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -12,6 +12,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -524,6 +525,11 @@ static CPUPhysMemoryClient xen_cpu_phys_memory_client = {
     .log_stop = xen_log_stop,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    cpu_physical_memory_set_dirty_tracking(!!enable);
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..25317ec 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
 
 #include "qemu-common.h"
 #include "hw/xen.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -43,3 +44,7 @@ int xen_init(void)
 {
     return -ENOSYS;
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiC-0008Pw-At; Wed, 20 Feb 2013 20:56:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiA-0008Pb-Dy
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:18 +0000
Received: from [85.158.139.211:40530] by server-4.bemta-5.messagelabs.com id
	30/24-29496-17835215; Wed, 20 Feb 2013 20:56:17 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361393776!18034497!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26886 invoked from network); 20 Feb 2013 20:56:16 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 20:56:16 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 69602C5619A;
	Wed, 20 Feb 2013 20:56:16 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:57 +0000
Message-Id: <1361393761-957-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 2/6] xen: Introduce xen_modified_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>
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 function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 hw/xen.h   |    1 +
 xen-all.c  |   21 +++++++++++++++++++++
 xen-stub.c |    4 ++++
 3 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index 2162111..359a275 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -45,6 +45,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/xen-all.c b/xen-all.c
index 6b4e511..121289d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1135,3 +1135,24 @@ void destroy_hvm_domain(bool reboot)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(cpu_physical_memory_get_dirty_tracking())) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 25317ec..7b54477 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -48,3 +48,7 @@ int xen_init(void)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiD-0008QH-Fo; Wed, 20 Feb 2013 20:56:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiB-0008Pn-RY
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:20 +0000
Received: from [85.158.139.83:53923] by server-2.bemta-5.messagelabs.com id
	F0/DC-16911-37835215; Wed, 20 Feb 2013 20:56:19 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361393777!27641852!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9651 invoked from network); 20 Feb 2013 20:56:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-182.messagelabs.com with SMTP;
	20 Feb 2013 20:56:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 31DC5C5619C;
	Wed, 20 Feb 2013 20:56:17 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:59 +0000
Message-Id: <1361393761-957-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 4/6] exec: Introduce helper to set dirty 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>
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 new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |   52 +++++++++++++++++-----------------------------------
 1 files changed, 17 insertions(+), 35 deletions(-)

diff --git a/exec.c b/exec.c
index 2a35944..07a6f68 100644
--- a/exec.c
+++ b/exec.c
@@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -4081,13 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
-            if (!cpu_physical_memory_is_dirty(addr1)) {
-                /* invalidate code */
-                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                /* set dirty bit */
-                cpu_physical_memory_set_dirty_flags(
-                    addr1, (0xff & ~CODE_DIRTY_FLAG));
-            }
+            invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -4218,13 +4218,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -4568,13 +4562,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4646,13 +4634,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiD-0008QH-Fo; Wed, 20 Feb 2013 20:56:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiB-0008Pn-RY
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:20 +0000
Received: from [85.158.139.83:53923] by server-2.bemta-5.messagelabs.com id
	F0/DC-16911-37835215; Wed, 20 Feb 2013 20:56:19 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361393777!27641852!2
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9651 invoked from network); 20 Feb 2013 20:56:17 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-182.messagelabs.com with SMTP;
	20 Feb 2013 20:56:17 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 31DC5C5619C;
	Wed, 20 Feb 2013 20:56:17 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:59 +0000
Message-Id: <1361393761-957-5-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 4/6] exec: Introduce helper to set dirty 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>
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 new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 exec.c |   52 +++++++++++++++++-----------------------------------
 1 files changed, 17 insertions(+), 35 deletions(-)

diff --git a/exec.c b/exec.c
index 2a35944..07a6f68 100644
--- a/exec.c
+++ b/exec.c
@@ -3951,6 +3951,18 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -4003,13 +4015,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -4081,13 +4087,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
-            if (!cpu_physical_memory_is_dirty(addr1)) {
-                /* invalidate code */
-                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                /* set dirty bit */
-                cpu_physical_memory_set_dirty_flags(
-                    addr1, (0xff & ~CODE_DIRTY_FLAG));
-            }
+            invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -4218,13 +4218,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -4568,13 +4562,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4646,13 +4634,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 20:56:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 20: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 1U8GiC-0008Pw-At; Wed, 20 Feb 2013 20:56:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8GiA-0008Pb-Dy
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 20:56:18 +0000
Received: from [85.158.139.211:40530] by server-4.bemta-5.messagelabs.com id
	30/24-29496-17835215; Wed, 20 Feb 2013 20:56:17 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361393776!18034497!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26886 invoked from network); 20 Feb 2013 20:56:16 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 20:56:16 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 69602C5619A;
	Wed, 20 Feb 2013 20:56:16 +0000 (GMT)
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 20 Feb 2013 20:55:57 +0000
Message-Id: <1361393761-957-3-git-send-email-alex@alex.org.uk>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] [PATCHv5 2/6] xen: Introduce xen_modified_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>
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 function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Alex Bligh <alex@alex.org.uk>
---
 hw/xen.h   |    1 +
 xen-all.c  |   21 +++++++++++++++++++++
 xen-stub.c |    4 ++++
 3 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/xen.h b/hw/xen.h
index 2162111..359a275 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -45,6 +45,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 
 #if defined(NEED_CPU_H) && !defined(CONFIG_USER_ONLY)
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 #if defined(CONFIG_XEN) && CONFIG_XEN_CTRL_INTERFACE_VERSION < 400
diff --git a/xen-all.c b/xen-all.c
index 6b4e511..121289d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1135,3 +1135,24 @@ void destroy_hvm_domain(bool reboot)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(cpu_physical_memory_get_dirty_tracking())) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 25317ec..7b54477 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -48,3 +48,7 @@ int xen_init(void)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 21:18:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 21:18: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 1U8H38-0001EH-TW; Wed, 20 Feb 2013 21:17:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1U8H37-0001EC-9A
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 21:17:57 +0000
Received: from [85.158.139.211:6104] by server-10.bemta-5.messagelabs.com id
	F5/47-04697-48D35215; Wed, 20 Feb 2013 21:17:56 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361395075!18520725!1
X-Originating-IP: [212.160.235.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26590 invoked from network); 20 Feb 2013 21:17:56 -0000
Received: from hydra.sisk.pl (HELO hydra.sisk.pl) (212.160.235.94)
	by server-16.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 21:17:56 -0000
Received: from vostro.rjw.lan (afbb109.neoplus.adsl.tpnet.pl [95.49.27.109])
	by hydra.sisk.pl (Postfix) with ESMTPSA id CF1F9E3F1E;
	Wed, 20 Feb 2013 22:17:33 +0100 (CET)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 20 Feb 2013 22:24:33 +0100
Message-ID: <1408464.udoD1aPUGq@vostro.rjw.lan>
User-Agent: KMail/4.9.5 (Linux/3.8.0; KDE/4.9.5; x86_64; ; )
In-Reply-To: <20130220204941.GC4526@phenom.dumpdata.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<4696812.SKkpQQd9iW@vostro.rjw.lan>
	<20130220204941.GC4526@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wednesday, February 20, 2013 03:49:41 PM Konrad Rzeszutek Wilk wrote:
> > > > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > Date:   Wed Feb 13 14:36:47 2013 +0100
> > > > 
> > > >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > > > 
> > > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > > > acpi_scan_lock (new in my tree as well).
> > > 
> > > Yes, we noticed that and only need minor updates at xen side, will send out
> > > 2 xen patches later accordingly, for cleanup and adding lock.
> > 
> > Thanks, but those new changes will only make sense after merging the Xen tree
> > with the PM tree.  Why don't we queue them up for merging later after both
> > the Xen and PM trees have been pulled from?
> 
> OK, I've created a branch (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
> that has your branch and my branch - along with the fix from Stephan and then
> the three updates from Jinsong. Jinsong, please check that I've got all the
> right patches. I will rebase it once Linus has merged both of the Xen and PM trees.

Thanks, this looks good.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 21:18:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 21:18: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 1U8H38-0001EH-TW; Wed, 20 Feb 2013 21:17:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1U8H37-0001EC-9A
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 21:17:57 +0000
Received: from [85.158.139.211:6104] by server-10.bemta-5.messagelabs.com id
	F5/47-04697-48D35215; Wed, 20 Feb 2013 21:17:56 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361395075!18520725!1
X-Originating-IP: [212.160.235.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26590 invoked from network); 20 Feb 2013 21:17:56 -0000
Received: from hydra.sisk.pl (HELO hydra.sisk.pl) (212.160.235.94)
	by server-16.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 21:17:56 -0000
Received: from vostro.rjw.lan (afbb109.neoplus.adsl.tpnet.pl [95.49.27.109])
	by hydra.sisk.pl (Postfix) with ESMTPSA id CF1F9E3F1E;
	Wed, 20 Feb 2013 22:17:33 +0100 (CET)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 20 Feb 2013 22:24:33 +0100
Message-ID: <1408464.udoD1aPUGq@vostro.rjw.lan>
User-Agent: KMail/4.9.5 (Linux/3.8.0; KDE/4.9.5; x86_64; ; )
In-Reply-To: <20130220204941.GC4526@phenom.dumpdata.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<4696812.SKkpQQd9iW@vostro.rjw.lan>
	<20130220204941.GC4526@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wednesday, February 20, 2013 03:49:41 PM Konrad Rzeszutek Wilk wrote:
> > > > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > Date:   Wed Feb 13 14:36:47 2013 +0100
> > > > 
> > > >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > > > 
> > > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > > > acpi_scan_lock (new in my tree as well).
> > > 
> > > Yes, we noticed that and only need minor updates at xen side, will send out
> > > 2 xen patches later accordingly, for cleanup and adding lock.
> > 
> > Thanks, but those new changes will only make sense after merging the Xen tree
> > with the PM tree.  Why don't we queue them up for merging later after both
> > the Xen and PM trees have been pulled from?
> 
> OK, I've created a branch (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
> that has your branch and my branch - along with the fix from Stephan and then
> the three updates from Jinsong. Jinsong, please check that I've got all the
> right patches. I will rebase it once Linus has merged both of the Xen and PM trees.

Thanks, this looks good.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 21:29:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 21:29: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 1U8HDc-0001Uj-9Y; Wed, 20 Feb 2013 21:28:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alifchits@gmail.com>) id 1U8HDa-0001Ue-S7
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 21:28:47 +0000
Received: from [85.158.137.99:58757] by server-7.bemta-3.messagelabs.com id
	34/AC-10367-E0045215; Wed, 20 Feb 2013 21:28:46 +0000
X-Env-Sender: alifchits@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361395725!11926003!1
X-Originating-IP: [209.85.215.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16534 invoked from network); 20 Feb 2013 21:28:45 -0000
Received: from mail-ea0-f182.google.com (HELO mail-ea0-f182.google.com)
	(209.85.215.182)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 21:28:45 -0000
Received: by mail-ea0-f182.google.com with SMTP id a12so3743913eaa.13
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 13:28:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=P9FN4kfREWtXu1qKs4GCIq8tkMIjSfEBXQkCdkqf0aU=;
	b=dyecCIp+z5GYlNbvlsdVpieqvMnBGaXqxkvJT/caesiDL2QxQ8PVaINM+mTq1UTJte
	E1YOF1fpHSAirhXLFZyFa10y654WLYxDIVCVKS8gbTKfq+289/cYZRBvApsW36zOi5ie
	inBCY9ntbgT1tNDMUe+fYDCNHO7bn6iWQXOayU1mLVBTnTgzs0A/dqmJHAfBjWcfF689
	fzS5ePOOW4H67+z97L2AIXPgAbQWjpZM7nl0uy/yrvFYBFeuC+dtiEs1+/JeZNdFdX+6
	/mhVypGJjk8idVDGBIBLsoSNE3BpPpRmB85cC4b5i3dz5TrpG3JLgUIETbo642SWjbTN
	wzfA==
X-Received: by 10.14.209.131 with SMTP id s3mr72826120eeo.26.1361395725048;
	Wed, 20 Feb 2013 13:28:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.190.71 with HTTP; Wed, 20 Feb 2013 13:28:14 -0800 (PST)
In-Reply-To: <CAMCEDC2McwtebTf48-DCpXKHeN7CgZ-L93hH7NNEPDs_UTLDfg@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
	<CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
	<CAMCEDC2McwtebTf48-DCpXKHeN7CgZ-L93hH7NNEPDs_UTLDfg@mail.gmail.com>
From: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Wed, 20 Feb 2013 21:28:14 +0000
X-Google-Sender-Auth: 6fDgISZRzcoBLXtjfi4HHeBz29s
Message-ID: <CA+YWh9ZFcX13NbhfuLczNhH5vWQbMRVMoHAD_3-gt1xRPyEWgQ@mail.gmail.com>
To: Darren Shepherd <darren.s.shepherd@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 20, 2013 at 3:52 PM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> Thanks, I'll try out that patch.  I'm using the CentOS 6 bundle of Xen
> which pulls in a lot of the newer blktap code.  Do you know if that is
> the only thing that prevents snapshots from working?

I don't, sorry: I've never really used OSS Xen until now.

> people work around the time issue with just using the faketime
> preload, but I think there is something beyond the timestamp that is
> incompatible.

If you tell me how to reproduce those other problems I can certainly
have a look.

Cheers,
Andrei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 21:29:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 21:29: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 1U8HDc-0001Uj-9Y; Wed, 20 Feb 2013 21:28:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alifchits@gmail.com>) id 1U8HDa-0001Ue-S7
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 21:28:47 +0000
Received: from [85.158.137.99:58757] by server-7.bemta-3.messagelabs.com id
	34/AC-10367-E0045215; Wed, 20 Feb 2013 21:28:46 +0000
X-Env-Sender: alifchits@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361395725!11926003!1
X-Originating-IP: [209.85.215.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16534 invoked from network); 20 Feb 2013 21:28:45 -0000
Received: from mail-ea0-f182.google.com (HELO mail-ea0-f182.google.com)
	(209.85.215.182)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 21:28:45 -0000
Received: by mail-ea0-f182.google.com with SMTP id a12so3743913eaa.13
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 13:28:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=P9FN4kfREWtXu1qKs4GCIq8tkMIjSfEBXQkCdkqf0aU=;
	b=dyecCIp+z5GYlNbvlsdVpieqvMnBGaXqxkvJT/caesiDL2QxQ8PVaINM+mTq1UTJte
	E1YOF1fpHSAirhXLFZyFa10y654WLYxDIVCVKS8gbTKfq+289/cYZRBvApsW36zOi5ie
	inBCY9ntbgT1tNDMUe+fYDCNHO7bn6iWQXOayU1mLVBTnTgzs0A/dqmJHAfBjWcfF689
	fzS5ePOOW4H67+z97L2AIXPgAbQWjpZM7nl0uy/yrvFYBFeuC+dtiEs1+/JeZNdFdX+6
	/mhVypGJjk8idVDGBIBLsoSNE3BpPpRmB85cC4b5i3dz5TrpG3JLgUIETbo642SWjbTN
	wzfA==
X-Received: by 10.14.209.131 with SMTP id s3mr72826120eeo.26.1361395725048;
	Wed, 20 Feb 2013 13:28:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.190.71 with HTTP; Wed, 20 Feb 2013 13:28:14 -0800 (PST)
In-Reply-To: <CAMCEDC2McwtebTf48-DCpXKHeN7CgZ-L93hH7NNEPDs_UTLDfg@mail.gmail.com>
References: <CAMCEDC1XRixMdoW1BUwPzepX+0kPad_q5=ZRt6ptKPSqP7j=yQ@mail.gmail.com>
	<CA+YWh9bRxcKQM17dtjCFPeSycDNJ9GXf3_dpC8aQf4e+S-iWGQ@mail.gmail.com>
	<CAMCEDC2McwtebTf48-DCpXKHeN7CgZ-L93hH7NNEPDs_UTLDfg@mail.gmail.com>
From: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Wed, 20 Feb 2013 21:28:14 +0000
X-Google-Sender-Auth: 6fDgISZRzcoBLXtjfi4HHeBz29s
Message-ID: <CA+YWh9ZFcX13NbhfuLczNhH5vWQbMRVMoHAD_3-gt1xRPyEWgQ@mail.gmail.com>
To: Darren Shepherd <darren.s.shepherd@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] why are qemu-img and vhd-util created files
	incompatible?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 20, 2013 at 3:52 PM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> Thanks, I'll try out that patch.  I'm using the CentOS 6 bundle of Xen
> which pulls in a lot of the newer blktap code.  Do you know if that is
> the only thing that prevents snapshots from working?

I don't, sorry: I've never really used OSS Xen until now.

> people work around the time issue with just using the faketime
> preload, but I think there is something beyond the timestamp that is
> incompatible.

If you tell me how to reproduce those other problems I can certainly
have a look.

Cheers,
Andrei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 21:31:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 21:31: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 1U8HGN-0001gc-SY; Wed, 20 Feb 2013 21:31:39 +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 1U8HGM-0001gW-9c
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 21:31:38 +0000
Received: from [193.109.254.147:28608] by server-4.bemta-14.messagelabs.com id
	88/F9-20719-9B045215; Wed, 20 Feb 2013 21:31:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361395893!9077047!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDgyMjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32387 invoked from network); 20 Feb 2013 21:31:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 21:31:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1KLVSfO010904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 21:31:29 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
	r1KLVR8e011248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 21:31:27 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1KLVPWt028566; Wed, 20 Feb 2013 15:31:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Feb 2013 13:31:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8A8671C3935; Wed, 20 Feb 2013 16:31:24 -0500 (EST)
Date: Wed, 20 Feb 2013 16:31:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130220213124.GA5292@phenom.dumpdata.com>
References: <20121218143109.GA24471@phenom.dumpdata.com>
	<50F9718A.4040202@citrix.com>
	<20130118182028.GB11351@phenom.dumpdata.com>
	<50FA9545.9090406@citrix.com>
	<20130122194640.GB10733@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130122194640.GB10733@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Felipe Franciosi <felipe.franciosi@citrix.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"matthew@wil.cx" <matthew@wil.cx>
Subject: Re: [Xen-devel] RFC v1: Xen block protocol overhaul - problem
 statement (with pictures!)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

PiA+ID4gV2hpY2ggaGFzIGEgbmljZSBwb3dlciBvZiB0d28gcmluZyB0byBpdC4gKEFoIHRoZSBw
dW5zISkKPiA+ID4gCj4gPiA+IEkgbGlrZSB0aGUgaWRlYSBvZiBwdXR0aW5nIHRoZSByZXF1ZXN0
IG9uIGEgZGlldCAtIGJ1dCB0b28gbXVjaAo+ID4gPiBjb3VsZCBjYXVzZSB1cyB0byBtaXNzIHRo
ZSBvcHBvcnR1bml0eSB0byBpbnNlcnQgb3RoZXIgZmxhZ3Mgb24gaXQuCj4gPiA+IElmIEkgcmVj
YWxsIGNvcnJlY3RseSwgdGhlIERJRi9ESVggb25seSBuZWVkIDggYnl0ZXMgb2YgZGF0YS4KPiA+
ID4gSWYgd2UgbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0Ogo+ID4gPiAgICAgICAgIEkvTyByZXF1
ZXN0ID0gb25lIHJpbmcgZW50cnkKPiA+IAo+ID4gU28gd2Ugb25seSBuZWVkIHRvIHJlc2VydmUg
OGJ5dGVzIGZvciBlYWNoIERJRi9JRFgsIGV2ZW4gaWYgdGhlIHJlcXVlc3QKPiA+IGNvbnRhaW5z
IGEgdmFyaWFibGUgbnVtYmVyIG9mIGRhdGE/IChJIG1lYW4sIGJsb2NrIHJlcXVlc3RzIGNhbiBh
dCBhCj4gPiBtaW5pbXVtIGNvbnRhaW4gNDA5NmJ5dGVzLCBvciBtdWNoIG1vcmUpCj4gCj4gSSBu
ZWVkIHRvIGRvdWJsZSBjaGVjayB3aXRoIE1hcnRpbiAoQ0MtZWQgaGVyZSkuIEJ1dCBteSByZWNv
bGxlY3Rpb24KPiBpcyB0aGF0IGl0IGlzIGp1c3QgYXR0YWNoZWQgdGhlIHRoZSAnYmlvJy4gU28g
aWYgdGhlIEJJTyBpcyA0SyBvciAxTUIgLQo+IGl0IHdvdWxkIG9ubHkgaGF2ZSBvbmUgRElGL0RJ
WCBkYXRhIHR5cGUuCgpBbmQgdGhhdCBpcyBzZW1pLWNvcnJlY3QuIElmIHRoZSB1c2VyIGRpZCBh
IGhvcnJpYmxlIGpvYiAoc2F5IHVzaW5nCmRkKSB0aGUgcGFnZXMgYXJlIGNoYWluZWQgdG9nZXRo
ZXIgLSBhbmQgd2UgZW5kIHVwIHdpdGggYSBsaW5rIGxpc3QKb2YgYmlvJ3MuIFRoZSBsYXN0IGJp
byB3b3VsZCBwb2ludCB0byBhIHBhZ2UgZmlsbGVkIHdpdGggJ3NlY3RvcidzIHdvcnRoCm9mIGRh
dGEgaGFzIGEgY2hlY2tzdW0uIEVhY2ggY2hlY2tzdW0gb2NjdXBpZXMgOCBieXRlcy4gU28gaWYg
dGhlCnRvdGFsICdiaW8nIGxlbmd0aCBpcyBzYXkgMU1CLCB0aGlzIGxhc3QgcGFnZSBpcyBmaWxs
ZWQgd2l0aCAyNTYgb2YKY2hlY2tzdW1zIC0gc28gMjA0OCBieXRlcyBvZiBkYXRhLgoKPiAKPiBI
bW0sIGJ1dCB0aGVuIHdlIG9wZXJhdGUgb24gdGhlICdzdHJ1Y3QgcmVxdWVzdCcgc28gdGhhdCBt
aWdodCBub3QKPiBiZSB0aGUgY2FzZS4uCj4gPiAKPiA+ID4gYW5kIHRoZSAgIm9uZSByaW5nIGVu
dHJ5IiBjYW4gdXNlIHRoZSB0aGUgJzQnIGdyYW50cyBpZiB3ZSBqdXN0IGhhdmUgYQo+ID4gPiAx
NktCIEkvTyByZXF1ZXN0LCBidXQgaWYgaXQgaXMgbW9yZSB0aGFuIHRoYXQgLSB3ZSB1c2UgdGhl
IGluZGlyZWN0IHBhZ2UKPiA+IAo+ID4gV2VsbCwgb24gbXkgcHVycG9zZSBJJ3ZlIGxpbWl0ZWQg
dGhlIG51bWJlciBvZiBzZWdtZW50cyBvZiBhICJydyIKPiA+IHJlcXVlc3RzIHRvIDIsIHNvIGl0
J3Mgb25seSA4SywgYW55dGhpbmcgYmlnZ2VyIGhhcyB0byB1c2UgaW5kaXJlY3QKPiA+IGRlc2Ny
aXB0b3JzLCB3aGljaCBjYW4gZml0IDRNIG9mIGRhdGEgKGJlY2F1c2UgSSdtIHBhc3NpbmcgNCBn
cmFudAo+ID4gZnJhbWVzIGZ1bGwgb2YgImJsa2lmX3JlcXVlc3RfaW5kaXJlY3RfZW50cnkiIGVu
dHJpZXMpLgo+IAo+IDxub2RzPgo+ID4gCj4gPiA+IGFuZCBjYW4gc3R1ZmYgMU1CIG9mIGRhdGEg
aW4gdGhlcmUuCj4gPiA+IFRoZSBleHRyYSAzMi1ieXRlcyBvZiBzcGFjZSBmb3Igc3VjaCB0aGlu
Z3MgYXMgJ0RJRi9ESVgnLiBUaGlzIGFsc28KPiA+ID4gbWVhbnMgd2UgY291bGQgdW5pZnkgdGhl
ICdzdHJ1Y3QgcmVxdWVzdCcgd2l0aCB0aGUgJ2Rpc2NhcmQnIG9wZXJhdGlvbgo+ID4gPiBhbmQg
aXQgY291bGQgdXRpbGl6ZSB0aGUgMzItYnl0ZXMgb2YgZXh0cmEgdW51c2VkIHBheWxvYWQgZGF0
YS4KPiA+ID4gCj4gPiA+Pj4KPiA+ID4+Pgo+ID4gPj4+IFRoZSDigJhvcGVyYXRpb27igJkgd291
bGQgYmUgQkxLSUZfT1BfSU5ESVJFQ1QuIFRoZSByZWFkL3dyaXRlL2Rpc2NhcmQsCj4gPiA+Pj4g
ZXRjIG9wZXJhdGlvbiB3b3VsZCBub3cgYmUgaW4gaW5kaXJlY3Qub3AuIFRoZSBpbmRpcmVjdC5n
cmVmIHBvaW50cyB0bwo+ID4gPj4+IGEgcGFnZSB0aGF0IGlzIGZpbGxlZCB3aXRoOgo+ID4gPj4+
Cj4gPiA+Pj4KPiA+ID4+PiBzdHJ1Y3QgYmxraWZfcmVxdWVzdF9pbmRpcmVjdF9lbnRyeSB7Cj4g
PiA+Pj4gICAgICAgICBibGtpZl9zZWN0b3JfdCBzZWN0b3JfbnVtYmVyOwo+ID4gPj4+ICAgICAg
ICAgc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudCBzZWc7Cj4gPiA+Pj4gfSBfX2F0dHJpYnV0
ZV9fKChfX3BhY2tlZF9fKSk7Cj4gPiA+Pj4gLy8xNiBieXRlcywgc28gd2UgY2FuIGZpdCBpbiBh
IHBhZ2UgMjU2IG9mIHRoZXNlIHN0cnVjdHVyZXMuCj4gPiA+Pj4KPiA+ID4+Pgo+ID4gPj4+IFRo
aXMgbWVhbnMgdGhhdCB3aXRoIHRoZSBleGlzdGluZyAzNiBzbG90cyBpbiB0aGUgcmluZyAoc2lu
Z2xlIHBhZ2UpCj4gPiA+Pj4gd2UgY2FuIGNvdmVyOiAzMiBzbG90cyAqIGVhY2ggYmxraWZfcmVx
dWVzdF9pbmRpcmVjdCBjb3ZlcnM6IDI1NiAqIDQwOTYKPiA+ID4+PiB+PSAzMk0uIElmIHdlIGRv
buKAmXQgd2FudCB0byB1c2UgaW5kaXJlY3QgZGVzY3JpcHRvciB3ZSBjYW4gc3RpbGwgdXNlCj4g
PiA+Pj4gdXAgdG8gNCBwYWdlcyBvZiB0aGUgcmVxdWVzdCAoYXMgaXQgaGFzIGVub3VnaCBzcGFj
ZSB0byBjb250YWluIGZvdXIKPiA+ID4+PiBzZWdtZW50cyBhbmQgdGhlIHN0cnVjdHVyZSB3aWxs
IHN0aWxsIGJlIGNhY2hlLWFsaWduZWQpLgo+ID4gPj4+CgoKTWFydGluIGFza2VkIG1lIHdoeSB3
ZSBldmVuIGRvIHRoaXMgdmlhIHRoZXNlIGVudHJpZXMuIE1lYW5pbmcgd2h5CmhhdmUgdGhpcyB0
dXBsZSBvZiBpbmZvcm1hdGlvbiBmb3IgZWFjaCBwYWdlOiA8bGJhLCBmaXJzdF9zZWN0LCBsYXN0
X3NlY3QsIGdyZWY+LgpUaGUgbGJhIG9uIHRoZSBuZXh0IHN1YnNlcXVlbnQgaW5kaXJlY3QgZW50
cnkgaXMgZ29pbmcgdG8gYmUgaW5jcmVtZW50ZWQgYnkKb25lLiBUaGUgZmlyc3Rfc2VjdCBhbmQg
bGFzdF9zZWN0IHRvby4uLiBTbyB3aHkgbm90IGp1c3QgZG86CgpzdHJ1Y3QgYmxraWZfcmVxdWVz
dF9pbmRpcmVjdCB7CiAgICAgICAgdWludDhfdCAgICAgICAgb3BlcmF0aW9uOwogICAgICAgIGJs
a2lmX3ZkZXZfdCAgIGhhbmRsZTsgICAgICAgLyogb25seSBmb3IgcmVhZC93cml0ZSByZXF1ZXN0
cyAgICAgICAgICovCiNpZmRlZiBDT05GSUdfWDg2XzY0CiAgICAgICAgdWludDMyX3QgICAgICAg
X3BhZDE7ICAgICAgICAvKiBvZmZzZXRvZihibGtpZl9yZXF1ZXN0LHUucncuaWQpID09IDggKi8K
I2VuZGlmCiAgICAgICAgdWludDY0X3QgICAgICAgaWQ7ICAgICAgICAgICAvKiBwcml2YXRlIGd1
ZXN0IHZhbHVlLCBlY2hvZWQgaW4gcmVzcCAgKi8KICAgICAgICBibGtpZl9zZWN0b3JfdCBzZWN0
b3JfbnVtYmVyOy8qIHN0YXJ0IHNlY3RvciBpZHggb24gZGlzayAoci93IG9ubHkpICAqLwoKCWdy
YW50X3JlZl90CWluZGlyZWN0X2Rlc2M7Cgl1aW50MTZfdAlucl9lbGVtczsKfQoKQW5kIHRoZSAn
aW5kaXJlY3RfZGVzYycgd291bGQgcG9pbnQgdG8gYSBwYWdlIHRoYXQgbG9va3MgcXVpdGUgY2xv
c2UgdG8Kd2hhdCB0aGUgc2NhdHRlcmxpc3QgbG9va3MgbGlrZToKCglzdHJ1Y3QgaW5kaXJlY3Rf
Y2hhaW4gewoJCXVpbnQxNl90CW9wX2ZsYWc7CS8vKkNhbiBEX05FWFQsIERfU1RBUlQsIERfRU5E
ID8KCQl1aW50MTZfdAluZXh0OwoJCXVpbnQxNl90CW9mZnNldDsKCQl1aW50MTZfdAlsZW5ndGg7
CgkJdWludDMyX3QJZ3JlZjsKCQl1aW50MzJfdAlfcGFkOwkJLy8gTmVlZCB0aGlzIGluIGNhc2Ug
d2UgZXZlciB3YW50IHRvCgkJCQkJCS8vIG1ha2UgZ3JlZiArIF9wYWQgYmUgYSBwaHlzaWNhbCBh
ZGRyLgoJfQoKQW5kIHRoZSBwYWdlIGl0c2VsZiB3b3VsZCBiZToKCXN0cnVjdCBpbmRpcmVjdF9j
aGFpblsyNTZdOwoKdGhlICduZXh0JyB3b3VsZCBqdXN0IGNvbnRhaW4gdGhlIGluZGV4IGluc2lk
ZSBpbiBpbmRpcmVjdF9jaGFpbiBwYWdlIC0gc28gZnJvbQowLT4yNTYuICBUaGUgb2Zmc2V0IGFu
ZCBsZW5ndGggd291bGQgcmVmZXJlbmNlIHdoZXJlaW4gdGhlIHBhZ2UgdGhlIGRhdGEgaXMKY29u
dGFpbmVkLgoKVGhpcyB3YXkgdGhlICdsYmEnIGluZm9ybWF0aW9uIGlzIHBhcnQgb2YgdGhlICdi
bGtpZl9yZXF1ZXN0X2luZGlyZWN0JyBhbmQgdGhlCnBheWxvYWQgaW5mbyBpcyBhbGwgaW4gdGhl
IGluZGlyZWN0IGRlc2NyaXB0b3JzLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 20 21:31:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 21:31: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 1U8HGN-0001gc-SY; Wed, 20 Feb 2013 21:31:39 +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 1U8HGM-0001gW-9c
	for xen-devel@lists.xensource.com; Wed, 20 Feb 2013 21:31:38 +0000
Received: from [193.109.254.147:28608] by server-4.bemta-14.messagelabs.com id
	88/F9-20719-9B045215; Wed, 20 Feb 2013 21:31:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361395893!9077047!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDgyMjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32387 invoked from network); 20 Feb 2013 21:31:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Feb 2013 21:31:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1KLVSfO010904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 21:31:29 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
	r1KLVR8e011248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 20 Feb 2013 21:31:27 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1KLVPWt028566; Wed, 20 Feb 2013 15:31:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Feb 2013 13:31:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8A8671C3935; Wed, 20 Feb 2013 16:31:24 -0500 (EST)
Date: Wed, 20 Feb 2013 16:31:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130220213124.GA5292@phenom.dumpdata.com>
References: <20121218143109.GA24471@phenom.dumpdata.com>
	<50F9718A.4040202@citrix.com>
	<20130118182028.GB11351@phenom.dumpdata.com>
	<50FA9545.9090406@citrix.com>
	<20130122194640.GB10733@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130122194640.GB10733@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Felipe Franciosi <felipe.franciosi@citrix.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"matthew@wil.cx" <matthew@wil.cx>
Subject: Re: [Xen-devel] RFC v1: Xen block protocol overhaul - problem
 statement (with pictures!)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

PiA+ID4gV2hpY2ggaGFzIGEgbmljZSBwb3dlciBvZiB0d28gcmluZyB0byBpdC4gKEFoIHRoZSBw
dW5zISkKPiA+ID4gCj4gPiA+IEkgbGlrZSB0aGUgaWRlYSBvZiBwdXR0aW5nIHRoZSByZXF1ZXN0
IG9uIGEgZGlldCAtIGJ1dCB0b28gbXVjaAo+ID4gPiBjb3VsZCBjYXVzZSB1cyB0byBtaXNzIHRo
ZSBvcHBvcnR1bml0eSB0byBpbnNlcnQgb3RoZXIgZmxhZ3Mgb24gaXQuCj4gPiA+IElmIEkgcmVj
YWxsIGNvcnJlY3RseSwgdGhlIERJRi9ESVggb25seSBuZWVkIDggYnl0ZXMgb2YgZGF0YS4KPiA+
ID4gSWYgd2UgbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0Ogo+ID4gPiAgICAgICAgIEkvTyByZXF1
ZXN0ID0gb25lIHJpbmcgZW50cnkKPiA+IAo+ID4gU28gd2Ugb25seSBuZWVkIHRvIHJlc2VydmUg
OGJ5dGVzIGZvciBlYWNoIERJRi9JRFgsIGV2ZW4gaWYgdGhlIHJlcXVlc3QKPiA+IGNvbnRhaW5z
IGEgdmFyaWFibGUgbnVtYmVyIG9mIGRhdGE/IChJIG1lYW4sIGJsb2NrIHJlcXVlc3RzIGNhbiBh
dCBhCj4gPiBtaW5pbXVtIGNvbnRhaW4gNDA5NmJ5dGVzLCBvciBtdWNoIG1vcmUpCj4gCj4gSSBu
ZWVkIHRvIGRvdWJsZSBjaGVjayB3aXRoIE1hcnRpbiAoQ0MtZWQgaGVyZSkuIEJ1dCBteSByZWNv
bGxlY3Rpb24KPiBpcyB0aGF0IGl0IGlzIGp1c3QgYXR0YWNoZWQgdGhlIHRoZSAnYmlvJy4gU28g
aWYgdGhlIEJJTyBpcyA0SyBvciAxTUIgLQo+IGl0IHdvdWxkIG9ubHkgaGF2ZSBvbmUgRElGL0RJ
WCBkYXRhIHR5cGUuCgpBbmQgdGhhdCBpcyBzZW1pLWNvcnJlY3QuIElmIHRoZSB1c2VyIGRpZCBh
IGhvcnJpYmxlIGpvYiAoc2F5IHVzaW5nCmRkKSB0aGUgcGFnZXMgYXJlIGNoYWluZWQgdG9nZXRo
ZXIgLSBhbmQgd2UgZW5kIHVwIHdpdGggYSBsaW5rIGxpc3QKb2YgYmlvJ3MuIFRoZSBsYXN0IGJp
byB3b3VsZCBwb2ludCB0byBhIHBhZ2UgZmlsbGVkIHdpdGggJ3NlY3RvcidzIHdvcnRoCm9mIGRh
dGEgaGFzIGEgY2hlY2tzdW0uIEVhY2ggY2hlY2tzdW0gb2NjdXBpZXMgOCBieXRlcy4gU28gaWYg
dGhlCnRvdGFsICdiaW8nIGxlbmd0aCBpcyBzYXkgMU1CLCB0aGlzIGxhc3QgcGFnZSBpcyBmaWxs
ZWQgd2l0aCAyNTYgb2YKY2hlY2tzdW1zIC0gc28gMjA0OCBieXRlcyBvZiBkYXRhLgoKPiAKPiBI
bW0sIGJ1dCB0aGVuIHdlIG9wZXJhdGUgb24gdGhlICdzdHJ1Y3QgcmVxdWVzdCcgc28gdGhhdCBt
aWdodCBub3QKPiBiZSB0aGUgY2FzZS4uCj4gPiAKPiA+ID4gYW5kIHRoZSAgIm9uZSByaW5nIGVu
dHJ5IiBjYW4gdXNlIHRoZSB0aGUgJzQnIGdyYW50cyBpZiB3ZSBqdXN0IGhhdmUgYQo+ID4gPiAx
NktCIEkvTyByZXF1ZXN0LCBidXQgaWYgaXQgaXMgbW9yZSB0aGFuIHRoYXQgLSB3ZSB1c2UgdGhl
IGluZGlyZWN0IHBhZ2UKPiA+IAo+ID4gV2VsbCwgb24gbXkgcHVycG9zZSBJJ3ZlIGxpbWl0ZWQg
dGhlIG51bWJlciBvZiBzZWdtZW50cyBvZiBhICJydyIKPiA+IHJlcXVlc3RzIHRvIDIsIHNvIGl0
J3Mgb25seSA4SywgYW55dGhpbmcgYmlnZ2VyIGhhcyB0byB1c2UgaW5kaXJlY3QKPiA+IGRlc2Ny
aXB0b3JzLCB3aGljaCBjYW4gZml0IDRNIG9mIGRhdGEgKGJlY2F1c2UgSSdtIHBhc3NpbmcgNCBn
cmFudAo+ID4gZnJhbWVzIGZ1bGwgb2YgImJsa2lmX3JlcXVlc3RfaW5kaXJlY3RfZW50cnkiIGVu
dHJpZXMpLgo+IAo+IDxub2RzPgo+ID4gCj4gPiA+IGFuZCBjYW4gc3R1ZmYgMU1CIG9mIGRhdGEg
aW4gdGhlcmUuCj4gPiA+IFRoZSBleHRyYSAzMi1ieXRlcyBvZiBzcGFjZSBmb3Igc3VjaCB0aGlu
Z3MgYXMgJ0RJRi9ESVgnLiBUaGlzIGFsc28KPiA+ID4gbWVhbnMgd2UgY291bGQgdW5pZnkgdGhl
ICdzdHJ1Y3QgcmVxdWVzdCcgd2l0aCB0aGUgJ2Rpc2NhcmQnIG9wZXJhdGlvbgo+ID4gPiBhbmQg
aXQgY291bGQgdXRpbGl6ZSB0aGUgMzItYnl0ZXMgb2YgZXh0cmEgdW51c2VkIHBheWxvYWQgZGF0
YS4KPiA+ID4gCj4gPiA+Pj4KPiA+ID4+Pgo+ID4gPj4+IFRoZSDigJhvcGVyYXRpb27igJkgd291
bGQgYmUgQkxLSUZfT1BfSU5ESVJFQ1QuIFRoZSByZWFkL3dyaXRlL2Rpc2NhcmQsCj4gPiA+Pj4g
ZXRjIG9wZXJhdGlvbiB3b3VsZCBub3cgYmUgaW4gaW5kaXJlY3Qub3AuIFRoZSBpbmRpcmVjdC5n
cmVmIHBvaW50cyB0bwo+ID4gPj4+IGEgcGFnZSB0aGF0IGlzIGZpbGxlZCB3aXRoOgo+ID4gPj4+
Cj4gPiA+Pj4KPiA+ID4+PiBzdHJ1Y3QgYmxraWZfcmVxdWVzdF9pbmRpcmVjdF9lbnRyeSB7Cj4g
PiA+Pj4gICAgICAgICBibGtpZl9zZWN0b3JfdCBzZWN0b3JfbnVtYmVyOwo+ID4gPj4+ICAgICAg
ICAgc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudCBzZWc7Cj4gPiA+Pj4gfSBfX2F0dHJpYnV0
ZV9fKChfX3BhY2tlZF9fKSk7Cj4gPiA+Pj4gLy8xNiBieXRlcywgc28gd2UgY2FuIGZpdCBpbiBh
IHBhZ2UgMjU2IG9mIHRoZXNlIHN0cnVjdHVyZXMuCj4gPiA+Pj4KPiA+ID4+Pgo+ID4gPj4+IFRo
aXMgbWVhbnMgdGhhdCB3aXRoIHRoZSBleGlzdGluZyAzNiBzbG90cyBpbiB0aGUgcmluZyAoc2lu
Z2xlIHBhZ2UpCj4gPiA+Pj4gd2UgY2FuIGNvdmVyOiAzMiBzbG90cyAqIGVhY2ggYmxraWZfcmVx
dWVzdF9pbmRpcmVjdCBjb3ZlcnM6IDI1NiAqIDQwOTYKPiA+ID4+PiB+PSAzMk0uIElmIHdlIGRv
buKAmXQgd2FudCB0byB1c2UgaW5kaXJlY3QgZGVzY3JpcHRvciB3ZSBjYW4gc3RpbGwgdXNlCj4g
PiA+Pj4gdXAgdG8gNCBwYWdlcyBvZiB0aGUgcmVxdWVzdCAoYXMgaXQgaGFzIGVub3VnaCBzcGFj
ZSB0byBjb250YWluIGZvdXIKPiA+ID4+PiBzZWdtZW50cyBhbmQgdGhlIHN0cnVjdHVyZSB3aWxs
IHN0aWxsIGJlIGNhY2hlLWFsaWduZWQpLgo+ID4gPj4+CgoKTWFydGluIGFza2VkIG1lIHdoeSB3
ZSBldmVuIGRvIHRoaXMgdmlhIHRoZXNlIGVudHJpZXMuIE1lYW5pbmcgd2h5CmhhdmUgdGhpcyB0
dXBsZSBvZiBpbmZvcm1hdGlvbiBmb3IgZWFjaCBwYWdlOiA8bGJhLCBmaXJzdF9zZWN0LCBsYXN0
X3NlY3QsIGdyZWY+LgpUaGUgbGJhIG9uIHRoZSBuZXh0IHN1YnNlcXVlbnQgaW5kaXJlY3QgZW50
cnkgaXMgZ29pbmcgdG8gYmUgaW5jcmVtZW50ZWQgYnkKb25lLiBUaGUgZmlyc3Rfc2VjdCBhbmQg
bGFzdF9zZWN0IHRvby4uLiBTbyB3aHkgbm90IGp1c3QgZG86CgpzdHJ1Y3QgYmxraWZfcmVxdWVz
dF9pbmRpcmVjdCB7CiAgICAgICAgdWludDhfdCAgICAgICAgb3BlcmF0aW9uOwogICAgICAgIGJs
a2lmX3ZkZXZfdCAgIGhhbmRsZTsgICAgICAgLyogb25seSBmb3IgcmVhZC93cml0ZSByZXF1ZXN0
cyAgICAgICAgICovCiNpZmRlZiBDT05GSUdfWDg2XzY0CiAgICAgICAgdWludDMyX3QgICAgICAg
X3BhZDE7ICAgICAgICAvKiBvZmZzZXRvZihibGtpZl9yZXF1ZXN0LHUucncuaWQpID09IDggKi8K
I2VuZGlmCiAgICAgICAgdWludDY0X3QgICAgICAgaWQ7ICAgICAgICAgICAvKiBwcml2YXRlIGd1
ZXN0IHZhbHVlLCBlY2hvZWQgaW4gcmVzcCAgKi8KICAgICAgICBibGtpZl9zZWN0b3JfdCBzZWN0
b3JfbnVtYmVyOy8qIHN0YXJ0IHNlY3RvciBpZHggb24gZGlzayAoci93IG9ubHkpICAqLwoKCWdy
YW50X3JlZl90CWluZGlyZWN0X2Rlc2M7Cgl1aW50MTZfdAlucl9lbGVtczsKfQoKQW5kIHRoZSAn
aW5kaXJlY3RfZGVzYycgd291bGQgcG9pbnQgdG8gYSBwYWdlIHRoYXQgbG9va3MgcXVpdGUgY2xv
c2UgdG8Kd2hhdCB0aGUgc2NhdHRlcmxpc3QgbG9va3MgbGlrZToKCglzdHJ1Y3QgaW5kaXJlY3Rf
Y2hhaW4gewoJCXVpbnQxNl90CW9wX2ZsYWc7CS8vKkNhbiBEX05FWFQsIERfU1RBUlQsIERfRU5E
ID8KCQl1aW50MTZfdAluZXh0OwoJCXVpbnQxNl90CW9mZnNldDsKCQl1aW50MTZfdAlsZW5ndGg7
CgkJdWludDMyX3QJZ3JlZjsKCQl1aW50MzJfdAlfcGFkOwkJLy8gTmVlZCB0aGlzIGluIGNhc2Ug
d2UgZXZlciB3YW50IHRvCgkJCQkJCS8vIG1ha2UgZ3JlZiArIF9wYWQgYmUgYSBwaHlzaWNhbCBh
ZGRyLgoJfQoKQW5kIHRoZSBwYWdlIGl0c2VsZiB3b3VsZCBiZToKCXN0cnVjdCBpbmRpcmVjdF9j
aGFpblsyNTZdOwoKdGhlICduZXh0JyB3b3VsZCBqdXN0IGNvbnRhaW4gdGhlIGluZGV4IGluc2lk
ZSBpbiBpbmRpcmVjdF9jaGFpbiBwYWdlIC0gc28gZnJvbQowLT4yNTYuICBUaGUgb2Zmc2V0IGFu
ZCBsZW5ndGggd291bGQgcmVmZXJlbmNlIHdoZXJlaW4gdGhlIHBhZ2UgdGhlIGRhdGEgaXMKY29u
dGFpbmVkLgoKVGhpcyB3YXkgdGhlICdsYmEnIGluZm9ybWF0aW9uIGlzIHBhcnQgb2YgdGhlICdi
bGtpZl9yZXF1ZXN0X2luZGlyZWN0JyBhbmQgdGhlCnBheWxvYWQgaW5mbyBpcyBhbGwgaW4gdGhl
IGluZGlyZWN0IGRlc2NyaXB0b3JzLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 20 22:46:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 22:46: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 1U8IQ3-0002e4-N6; Wed, 20 Feb 2013 22:45:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8IQ1-0002dz-SC
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 22:45:41 +0000
Received: from [85.158.139.211:40778] by server-4.bemta-5.messagelabs.com id
	96/2E-29496-51255215; Wed, 20 Feb 2013 22:45:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361400333!14499543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22105 invoked from network); 20 Feb 2013 22:45:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 22:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,705,1355097600"; 
   d="scan'208";a="8154006"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 22:45:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 17:45:33 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8IPs-0000I3-Q7	for
	xen-devel@lists.xen.org; Wed, 20 Feb 2013 22:45:32 +0000
Message-ID: <5125520C.30500@citrix.com>
Date: Wed, 20 Feb 2013 22:45:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4
Subject: [Xen-devel] Introducing the Xen Crashdump Analyser
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

About a year ago, I started writing a tool to analyse /proc/vmcore in
the case of Xen crash (given a kdump environment) and provide a report. 
The plan has always been to try and upstream it, and the main barrier
has been a lack of time on my part.

It was first released in XenServer 6.1 and has subsequently been
backported to some older versions, but I hereby formally present it to
the Xen community for comment.

Please read http://xenbits.xen.org/people/andrewcoop/ which contains
links to the source and instructions for use, as well as an example
report from a bug I am currently investigating (Scheduler race condition).

I would appreciate any feedback/queries/questions/suggestions.

Thanks,

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 22:46:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 22:46: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 1U8IQ3-0002e4-N6; Wed, 20 Feb 2013 22:45:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8IQ1-0002dz-SC
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 22:45:41 +0000
Received: from [85.158.139.211:40778] by server-4.bemta-5.messagelabs.com id
	96/2E-29496-51255215; Wed, 20 Feb 2013 22:45:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361400333!14499543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM2MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22105 invoked from network); 20 Feb 2013 22:45:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Feb 2013 22:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,705,1355097600"; 
   d="scan'208";a="8154006"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	20 Feb 2013 22:45:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 20 Feb 2013 17:45:33 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8IPs-0000I3-Q7	for
	xen-devel@lists.xen.org; Wed, 20 Feb 2013 22:45:32 +0000
Message-ID: <5125520C.30500@citrix.com>
Date: Wed, 20 Feb 2013 22:45:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Xen-devel List <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4
Subject: [Xen-devel] Introducing the Xen Crashdump Analyser
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

About a year ago, I started writing a tool to analyse /proc/vmcore in
the case of Xen crash (given a kdump environment) and provide a report. 
The plan has always been to try and upstream it, and the main barrier
has been a lack of time on my part.

It was first released in XenServer 6.1 and has subsequently been
backported to some older versions, but I hereby formally present it to
the Xen community for comment.

Please read http://xenbits.xen.org/people/andrewcoop/ which contains
links to the source and instructions for use, as well as an example
report from a bug I am currently investigating (Scheduler race condition).

I would appreciate any feedback/queries/questions/suggestions.

Thanks,

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 22:49:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 22:49: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 1U8IT9-0002kS-AR; Wed, 20 Feb 2013 22:48:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1U8IT8-0002kM-MS
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 22:48:54 +0000
Received: from [85.158.139.211:54090] by server-5.bemta-5.messagelabs.com id
	13/32-11945-5D255215; Wed, 20 Feb 2013 22:48:53 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361400532!18541526!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQ0NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21386 invoked from network); 20 Feb 2013 22:48:53 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 22:48:53 -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 r1KMmY2W005675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 17:48:34 -0500
Received: from lacos-laptop.usersys.redhat.com (vpn1-6-181.ams2.redhat.com
	[10.36.6.181])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r1KMmVbs003477; Wed, 20 Feb 2013 17:48:32 -0500
Message-ID: <5125533B.4060502@redhat.com>
Date: Wed, 20 Feb 2013 23:50:35 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
	<5124FFED.3000106@redhat.com>
	<1361380698.26546.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361380698.26546.21.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	Andrei Warkentin <andrey.warkentin@gmail.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>, Attilio Rao <attilio.rao@citrix.com>,
	David Woodhouse <dwmw2@infradead.org>, Bei Guan <gbtju85@gmail.com>
Subject: Re: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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 02/20/13 18:18, Ian Campbell wrote:
> On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
>> However in OVMF the RESERVED_MEMBASE range is not parsed from this
>> Xen-exported table, it is added manually in InitializeXen()
>> [OvmfPkg/PlatformPei/Xen.c]:
>>
>>   //
>>   // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
>>   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>>   //
>>   AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);
> 
> ICK, it would be far preferable for OVMF to do what SeaBIOS does and
> actually "communicate" with hvmloader IMHO.

The table with "XenHVMSeaBIOS" signature is not created for OVMF I
think; comparing the "bios_config" structure of function pointers
between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the
ovmf_config.bios_info_setup field is NULL.

However there seem to be at least two "info" tables. Referring back,
"seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS
only, but "hvm_info" just below the end of conventional memory (at
HVM_INFO_PADDR, 0x9F800) looks guest firmware independent.

I guess the quoted range would be available from
"hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment
in XenConnect() saying

  /* TBD: Locate hvm_info and reserve it away. */
  mXenInfo.HvmInfo = NULL;

Is the generic approach "see if you can find all what you need in
hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.)

Thanks
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 20 22:49:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 20 Feb 2013 22:49: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 1U8IT9-0002kS-AR; Wed, 20 Feb 2013 22:48:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1U8IT8-0002kM-MS
	for xen-devel@lists.xen.org; Wed, 20 Feb 2013 22:48:54 +0000
Received: from [85.158.139.211:54090] by server-5.bemta-5.messagelabs.com id
	13/32-11945-5D255215; Wed, 20 Feb 2013 22:48:53 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361400532!18541526!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQ0NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21386 invoked from network); 20 Feb 2013 22:48:53 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-206.messagelabs.com with SMTP;
	20 Feb 2013 22:48:53 -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 r1KMmY2W005675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 20 Feb 2013 17:48:34 -0500
Received: from lacos-laptop.usersys.redhat.com (vpn1-6-181.ams2.redhat.com
	[10.36.6.181])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r1KMmVbs003477; Wed, 20 Feb 2013 17:48:32 -0500
Message-ID: <5125533B.4060502@redhat.com>
Date: Wed, 20 Feb 2013 23:50:35 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
	<5124FFED.3000106@redhat.com>
	<1361380698.26546.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361380698.26546.21.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	Andrei Warkentin <andrey.warkentin@gmail.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	xen-devel <xen-devel@lists.xen.org>, Attilio Rao <attilio.rao@citrix.com>,
	David Woodhouse <dwmw2@infradead.org>, Bei Guan <gbtju85@gmail.com>
Subject: Re: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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 02/20/13 18:18, Ian Campbell wrote:
> On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
>> However in OVMF the RESERVED_MEMBASE range is not parsed from this
>> Xen-exported table, it is added manually in InitializeXen()
>> [OvmfPkg/PlatformPei/Xen.c]:
>>
>>   //
>>   // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
>>   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
>>   //
>>   AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);
> 
> ICK, it would be far preferable for OVMF to do what SeaBIOS does and
> actually "communicate" with hvmloader IMHO.

The table with "XenHVMSeaBIOS" signature is not created for OVMF I
think; comparing the "bios_config" structure of function pointers
between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the
ovmf_config.bios_info_setup field is NULL.

However there seem to be at least two "info" tables. Referring back,
"seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS
only, but "hvm_info" just below the end of conventional memory (at
HVM_INFO_PADDR, 0x9F800) looks guest firmware independent.

I guess the quoted range would be available from
"hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment
in XenConnect() saying

  /* TBD: Locate hvm_info and reserve it away. */
  mXenInfo.HvmInfo = NULL;

Is the generic approach "see if you can find all what you need in
hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.)

Thanks
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 02:32:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 02:32: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 1U8LwS-0001bp-Ol; Thu, 21 Feb 2013 02:31:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luokain@gmail.com>) id 1U8LwQ-0001bk-D1
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 02:31:22 +0000
Received: from [85.158.139.83:43691] by server-15.bemta-5.messagelabs.com id
	EB/3A-18914-9F685215; Thu, 21 Feb 2013 02:31:21 +0000
X-Env-Sender: luokain@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361413879!20851060!1
X-Originating-IP: [209.85.219.67]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28419 invoked from network); 21 Feb 2013 02:31:20 -0000
Received: from mail-oa0-f67.google.com (HELO mail-oa0-f67.google.com)
	(209.85.219.67)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 02:31:20 -0000
Received: by mail-oa0-f67.google.com with SMTP id o6so2229196oag.10
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 18:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=PFJHSkQVKQSg2FKdXDMqi2kJqNDhsPO4qX1AWhXSTvY=;
	b=ezvTiHOIMMpySXD9wleELkQeaWPSR+1nYGXxfrl2EFviifw6mcW0n/thONQijCcptO
	C2qkioqApOKHEM/RanMA/watt/n+NivSD6XFS5Va9mQYWNUvBtFmyKSQEoziZvDg9iLH
	/VpjG0rrnMytBLF1Z0UFYsDMqlTYpgHSuq5azCgacJxXRVm8XsdFw+oaf3nqMyq9q1qo
	SBIyWLFaNVjlL0UESfE/SFjVQAZBbgJAiaYGcSL31W9sS6zyUXey8Lm+dsCNAHJaPJ2q
	ga92kPSxHOvjfv5BLoUyhtQh1RbDuV27g64sps4kB6T53Ko47kUnYmyCYWnoFoMlGmHZ
	pm5Q==
MIME-Version: 1.0
X-Received: by 10.182.157.104 with SMTP id wl8mr4884666obb.79.1361413805515;
	Wed, 20 Feb 2013 18:30:05 -0800 (PST)
Received: by 10.76.91.132 with HTTP; Wed, 20 Feb 2013 18:30:05 -0800 (PST)
Date: Thu, 21 Feb 2013 10:30:05 +0800
Message-ID: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
From: Kai Luo <luokain@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Question about PoD and Transcendent Memory for 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: multipart/mixed; boundary="===============1745703628302293189=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1745703628302293189==
Content-Type: multipart/alternative; boundary=f46d044281a045255104d632da78

--f46d044281a045255104d632da78
Content-Type: text/plain; charset=ISO-8859-1

Hi:
      I am working at the source code of Xen 4.1.3 and have two questions
that confused me.
      I remembered a mail of XCP-mail-list which said when a hvm is
created,xen allocate all memory it requests,which can guarantee the
stability and Qos or something.However,when I come into the part of memory
source code,I tind the existance of PoD,which can adjust memory
dynamically,so I want to make sure whether the mechanism of memory
management between XCP and Xen is differrent,Xen can adjust the memory size
of HVM dynamically instead of a fixed memory size,am I right?
      I know the Transcendent Memory is a better techniche of memory
reuse,is it used in xen for HVM now?
      Thank you for your answering!
Jeap

--f46d044281a045255104d632da78
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi:<div>=A0 =A0 =A0 I am working at the source code of Xen 4.1.3 and have t=
wo questions that confused me.</div><div>=A0 =A0 =A0 I remembered a mail of=
 XCP-mail-list which said when a hvm is created,xen allocate all memory it =
requests,which can guarantee the stability and Qos or something.However,whe=
n I come into the part of memory source code,I tind the existance of PoD,wh=
ich can adjust memory dynamically,so I want to make sure whether the mechan=
ism of memory management between XCP and Xen is differrent,Xen can adjust t=
he memory size of HVM dynamically instead of a fixed memory size,am I right=
?</div>
<div>=A0 =A0 =A0 I know the Transcendent Memory is a better techniche of me=
mory reuse,is it used in xen for HVM now?</div><div>=A0 =A0 =A0 Thank you f=
or your answering!</div><div>Jeap</div><div><br></div><div><br></div>

--f46d044281a045255104d632da78--


--===============1745703628302293189==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1745703628302293189==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 02:32:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 02:32: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 1U8LwS-0001bp-Ol; Thu, 21 Feb 2013 02:31:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luokain@gmail.com>) id 1U8LwQ-0001bk-D1
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 02:31:22 +0000
Received: from [85.158.139.83:43691] by server-15.bemta-5.messagelabs.com id
	EB/3A-18914-9F685215; Thu, 21 Feb 2013 02:31:21 +0000
X-Env-Sender: luokain@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361413879!20851060!1
X-Originating-IP: [209.85.219.67]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28419 invoked from network); 21 Feb 2013 02:31:20 -0000
Received: from mail-oa0-f67.google.com (HELO mail-oa0-f67.google.com)
	(209.85.219.67)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 02:31:20 -0000
Received: by mail-oa0-f67.google.com with SMTP id o6so2229196oag.10
	for <xen-devel@lists.xen.org>; Wed, 20 Feb 2013 18:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=PFJHSkQVKQSg2FKdXDMqi2kJqNDhsPO4qX1AWhXSTvY=;
	b=ezvTiHOIMMpySXD9wleELkQeaWPSR+1nYGXxfrl2EFviifw6mcW0n/thONQijCcptO
	C2qkioqApOKHEM/RanMA/watt/n+NivSD6XFS5Va9mQYWNUvBtFmyKSQEoziZvDg9iLH
	/VpjG0rrnMytBLF1Z0UFYsDMqlTYpgHSuq5azCgacJxXRVm8XsdFw+oaf3nqMyq9q1qo
	SBIyWLFaNVjlL0UESfE/SFjVQAZBbgJAiaYGcSL31W9sS6zyUXey8Lm+dsCNAHJaPJ2q
	ga92kPSxHOvjfv5BLoUyhtQh1RbDuV27g64sps4kB6T53Ko47kUnYmyCYWnoFoMlGmHZ
	pm5Q==
MIME-Version: 1.0
X-Received: by 10.182.157.104 with SMTP id wl8mr4884666obb.79.1361413805515;
	Wed, 20 Feb 2013 18:30:05 -0800 (PST)
Received: by 10.76.91.132 with HTTP; Wed, 20 Feb 2013 18:30:05 -0800 (PST)
Date: Thu, 21 Feb 2013 10:30:05 +0800
Message-ID: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
From: Kai Luo <luokain@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Question about PoD and Transcendent Memory for 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: multipart/mixed; boundary="===============1745703628302293189=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1745703628302293189==
Content-Type: multipart/alternative; boundary=f46d044281a045255104d632da78

--f46d044281a045255104d632da78
Content-Type: text/plain; charset=ISO-8859-1

Hi:
      I am working at the source code of Xen 4.1.3 and have two questions
that confused me.
      I remembered a mail of XCP-mail-list which said when a hvm is
created,xen allocate all memory it requests,which can guarantee the
stability and Qos or something.However,when I come into the part of memory
source code,I tind the existance of PoD,which can adjust memory
dynamically,so I want to make sure whether the mechanism of memory
management between XCP and Xen is differrent,Xen can adjust the memory size
of HVM dynamically instead of a fixed memory size,am I right?
      I know the Transcendent Memory is a better techniche of memory
reuse,is it used in xen for HVM now?
      Thank you for your answering!
Jeap

--f46d044281a045255104d632da78
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi:<div>=A0 =A0 =A0 I am working at the source code of Xen 4.1.3 and have t=
wo questions that confused me.</div><div>=A0 =A0 =A0 I remembered a mail of=
 XCP-mail-list which said when a hvm is created,xen allocate all memory it =
requests,which can guarantee the stability and Qos or something.However,whe=
n I come into the part of memory source code,I tind the existance of PoD,wh=
ich can adjust memory dynamically,so I want to make sure whether the mechan=
ism of memory management between XCP and Xen is differrent,Xen can adjust t=
he memory size of HVM dynamically instead of a fixed memory size,am I right=
?</div>
<div>=A0 =A0 =A0 I know the Transcendent Memory is a better techniche of me=
mory reuse,is it used in xen for HVM now?</div><div>=A0 =A0 =A0 Thank you f=
or your answering!</div><div>Jeap</div><div><br></div><div><br></div>

--f46d044281a045255104d632da78--


--===============1745703628302293189==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1745703628302293189==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 03:06:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 03: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 1U8MTV-0002JW-Hx; Thu, 21 Feb 2013 03:05:33 +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 1U8MTU-0002JP-2r
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 03:05:32 +0000
Received: from [85.158.138.51:10839] by server-10.bemta-3.messagelabs.com id
	E3/32-10609-6FE85215; Thu, 21 Feb 2013 03:05:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361415924!19749309!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM2OTE5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26509 invoked from network); 21 Feb 2013 03:05:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 03:05:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1L35Ljn007976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 03:05:22 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
	r1L35Kt4018288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 03:05:21 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
	r1L35KbB004977; Wed, 20 Feb 2013 21:05:20 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Feb 2013 19:05:20 -0800
Date: Wed, 20 Feb 2013 19:05:19 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130220190519.5fb537b1@mantra.us.oracle.com>
In-Reply-To: <20130220095828.GA12083@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 Wed, 20 Feb 2013 09:58:28 +0000
Tim Deegan <tim@xen.org> wrote:

> At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > On Thu, 24 Jan 2013 16:31:22 +0000
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > +
> > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > +        {
> > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > +                pv_cpuid(regs);
> > > > +
> > > > +                /* Because we are setting CR4.OSFXSR to 0, we
> > > > need to disable
> > > > +                 * this because, during boot, user process
> > > > "init" (which doesn't
> > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > cause #UD. For now 
> > > > +                 * disable this. HVM doesn't allow setting of
> > > > CR4.OSFXSR.
> > > > +                 * fixme: this and also look at CR4.OSXSAVE */
> > > > +
> > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > 
> > > Shouldn't this be gated on which leaf the guest asked for?
> > 
> > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > work. The user process "init" running nash is executing pxor %xmm0,
> > %xmm0 and taking #UD. Strangely, it works with EAX==0, meaning if I
> > clear the bit for EAX==0, changing the intel string "ineI".  This
> > user process doesn't do cpuid, so it must be affected by it some
> > other way.
> > 
> > Pretty hard to debug since it's in nash user code from ramdisk and
> > I am not able to set breakpoint or put printf's easily to figure
> > why clearing bit for EAX==0 makes it work, or what's going on for
> > PV and HVM guest. CR0.EM is 0, so UD is coming from CR4.OSFXSR==0.
> > Reading the SDMs to learn OSFXSR stuff better....
> 
> Perhaps you need to clear the FXSR feature bit in leaf 0x80000001:EDX
> as well?

That appears to be AMD only.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 03:06:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 03: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 1U8MTV-0002JW-Hx; Thu, 21 Feb 2013 03:05:33 +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 1U8MTU-0002JP-2r
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 03:05:32 +0000
Received: from [85.158.138.51:10839] by server-10.bemta-3.messagelabs.com id
	E3/32-10609-6FE85215; Thu, 21 Feb 2013 03:05:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361415924!19749309!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM2OTE5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26509 invoked from network); 21 Feb 2013 03:05:25 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 03:05:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1L35Ljn007976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 03:05:22 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
	r1L35Kt4018288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 03:05:21 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
	r1L35KbB004977; Wed, 20 Feb 2013 21:05:20 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 20 Feb 2013 19:05:20 -0800
Date: Wed, 20 Feb 2013 19:05:19 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130220190519.5fb537b1@mantra.us.oracle.com>
In-Reply-To: <20130220095828.GA12083@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 Wed, 20 Feb 2013 09:58:28 +0000
Tim Deegan <tim@xen.org> wrote:

> At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > On Thu, 24 Jan 2013 16:31:22 +0000
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > +
> > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > +        {
> > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > +                pv_cpuid(regs);
> > > > +
> > > > +                /* Because we are setting CR4.OSFXSR to 0, we
> > > > need to disable
> > > > +                 * this because, during boot, user process
> > > > "init" (which doesn't
> > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > cause #UD. For now 
> > > > +                 * disable this. HVM doesn't allow setting of
> > > > CR4.OSFXSR.
> > > > +                 * fixme: this and also look at CR4.OSXSAVE */
> > > > +
> > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > 
> > > Shouldn't this be gated on which leaf the guest asked for?
> > 
> > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > work. The user process "init" running nash is executing pxor %xmm0,
> > %xmm0 and taking #UD. Strangely, it works with EAX==0, meaning if I
> > clear the bit for EAX==0, changing the intel string "ineI".  This
> > user process doesn't do cpuid, so it must be affected by it some
> > other way.
> > 
> > Pretty hard to debug since it's in nash user code from ramdisk and
> > I am not able to set breakpoint or put printf's easily to figure
> > why clearing bit for EAX==0 makes it work, or what's going on for
> > PV and HVM guest. CR0.EM is 0, so UD is coming from CR4.OSFXSR==0.
> > Reading the SDMs to learn OSFXSR stuff better....
> 
> Perhaps you need to clear the FXSR feature bit in leaf 0x80000001:EDX
> as well?

That appears to be AMD only.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 06:41:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 06:41: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 1U8Ppf-00056x-T8; Thu, 21 Feb 2013 06:40:39 +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 1U8Ppd-00056s-Ls
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 06:40:37 +0000
Received: from [193.109.254.147:63006] by server-9.bemta-14.messagelabs.com id
	9F/BA-30867-461C5215; Thu, 21 Feb 2013 06:40:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361428834!6253294!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUzNDM0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24561 invoked from network); 21 Feb 2013 06:40:35 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-27.messagelabs.com with SMTP;
	21 Feb 2013 06:40:35 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 20 Feb 2013 22:40:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,706,1355126400"; d="scan'208";a="259662024"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2013 22:40:33 -0800
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Feb 2013 22:40:32 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Feb 2013 22:40:32 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 21 Feb 2013 14:40:31 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Rafael J. Wysocki"
	<rjw@sisk.pl>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHOD6vNTyBHFMmDoE2LH83uWllZQ5iD3SCA
Date: Thu, 21 Feb 2013 06:40:29 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923354024BB@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
	<DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
	<4696812.SKkpQQd9iW@vostro.rjw.lan>
	<20130220204941.GC4526@phenom.dumpdata.com>
In-Reply-To: <20130220204941.GC4526@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>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:
>>>> commit 3757b94802fb65d8f696597a74053cf21738da0b
>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> Date:   Wed Feb 13 14:36:47 2013 +0100
>>>> 
>>>>     ACPI / hotplug: Fix concurrency issues and memory leaks
>>>> 
>>>> after which acpi_bus_scan() and acpi_bus_trim() have to be run
>>>> under acpi_scan_lock (new in my tree as well).
>>> 
>>> Yes, we noticed that and only need minor updates at xen side, will
>>> send out 2 xen patches later accordingly, for cleanup and adding
>>> lock. 
>> 
>> Thanks, but those new changes will only make sense after merging the
>> Xen tree with the PM tree.  Why don't we queue them up for merging
>> later after both the Xen and PM trees have been pulled from?
> 
> OK, I've created a branch
> (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
> that has your branch and my branch - along with the fix from Stephan
> and then  
> the three updates from Jinsong. Jinsong, please check that I've got
> all the 
> right patches. I will rebase it once Linus has merged both of the Xen
> and PM trees. 

Check done, it's OK.

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 Feb 21 06:41:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 06:41: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 1U8Ppf-00056x-T8; Thu, 21 Feb 2013 06:40:39 +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 1U8Ppd-00056s-Ls
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 06:40:37 +0000
Received: from [193.109.254.147:63006] by server-9.bemta-14.messagelabs.com id
	9F/BA-30867-461C5215; Thu, 21 Feb 2013 06:40:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361428834!6253294!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjUzNDM0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24561 invoked from network); 21 Feb 2013 06:40:35 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-27.messagelabs.com with SMTP;
	21 Feb 2013 06:40:35 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 20 Feb 2013 22:40:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,706,1355126400"; d="scan'208";a="259662024"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 20 Feb 2013 22:40:33 -0800
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Feb 2013 22:40:32 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 20 Feb 2013 22:40:32 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 21 Feb 2013 14:40:31 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "Rafael J. Wysocki"
	<rjw@sisk.pl>
Thread-Topic: linux-next: build failure after merge of the xen-two tree
Thread-Index: AQHOD6vNTyBHFMmDoE2LH83uWllZQ5iD3SCA
Date: Thu, 21 Feb 2013 06:40:29 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923354024BB@SHSMSX101.ccr.corp.intel.com>
References: <20130215154551.d11e9d376d30d32b9673e6cc@canb.auug.org.au>
	<11850955.SHqxVBsJqI@vostro.rjw.lan>
	<DE8DF0795D48FD4CA783C40EC82923353FCCAC@SHSMSX101.ccr.corp.intel.com>
	<4696812.SKkpQQd9iW@vostro.rjw.lan>
	<20130220204941.GC4526@phenom.dumpdata.com>
In-Reply-To: <20130220204941.GC4526@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>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] linux-next: build failure after merge of the
	xen-two tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:
>>>> commit 3757b94802fb65d8f696597a74053cf21738da0b
>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> Date:   Wed Feb 13 14:36:47 2013 +0100
>>>> 
>>>>     ACPI / hotplug: Fix concurrency issues and memory leaks
>>>> 
>>>> after which acpi_bus_scan() and acpi_bus_trim() have to be run
>>>> under acpi_scan_lock (new in my tree as well).
>>> 
>>> Yes, we noticed that and only need minor updates at xen side, will
>>> send out 2 xen patches later accordingly, for cleanup and adding
>>> lock. 
>> 
>> Thanks, but those new changes will only make sense after merging the
>> Xen tree with the PM tree.  Why don't we queue them up for merging
>> later after both the Xen and PM trees have been pulled from?
> 
> OK, I've created a branch
> (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
> that has your branch and my branch - along with the fix from Stephan
> and then  
> the three updates from Jinsong. Jinsong, please check that I've got
> all the 
> right patches. I will rebase it once Linus has merged both of the Xen
> and PM trees. 

Check done, it's OK.

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 Feb 21 08:14:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 08:14: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 1U8RI0-0006jq-Ss; Thu, 21 Feb 2013 08:14:00 +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 1U8RHz-0006jl-NS
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 08:13:59 +0000
Received: from [85.158.137.99:16746] by server-14.bemta-3.messagelabs.com id
	CA/9A-23533-247D5215; Thu, 21 Feb 2013 08:13:54 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361434432!12603787!1
X-Originating-IP: [209.85.214.178]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2861 invoked from network); 21 Feb 2013 08:13:53 -0000
Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com)
	(209.85.214.178)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 08:13:53 -0000
Received: by mail-ob0-f178.google.com with SMTP id wd20so8364791obb.23
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 00:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=FxMiAJz84vv4E7Ak8DlptMd4JX/HcAnBP7Gag5mqpo0=;
	b=dgZsHAhujToPOwISh5PBRU2z7W78N+37uZmM2Rk4HL4pxRoG13Zd+zGA2zBeeNPicD
	q5NBFg7+s1O28M6tHkdwP1rVkBT+TpM0DA+H70qu/scZIh3oPYp+gEIhEIiRwMxUyLBK
	Amr67CEduvUQ6YWRnsuZznMqCxM1EGU9MaIn02R9mi4joYd6ykzEZXTNTthi1X75jzSO
	6S/4N8pT/i5D0uvBq3ba9eK7nCivwzYJuxvrsCYd/NLX0D81GWjjDwtlNkLAii9Jbwpi
	G4ace0sJzrIvCDsR9xKGxfNSEkh32pwuBsWG7urvD5l6Yq9vNWwy4KqaGKsuebTufrrU
	WnZA==
MIME-Version: 1.0
X-Received: by 10.60.170.44 with SMTP id aj12mr10243972oec.42.1361434431670;
	Thu, 21 Feb 2013 00:13:51 -0800 (PST)
Received: by 10.60.102.139 with HTTP; Thu, 21 Feb 2013 00:13:51 -0800 (PST)
Date: Thu, 21 Feb 2013 08:13:51 +0000
Message-ID: <CAOqnZH4St12Kyxgmaj-ghw0ayyPWc5gh+7mCTekjS0z5C1bYWQ@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-devel@lists.xen.org, russell.pavlicek@xen.org
Subject: [Xen-devel] Planning Xen Test Days for 4.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: multipart/mixed; boundary="===============5649992130564628602=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5649992130564628602==
Content-Type: multipart/alternative; boundary=bcaec54d475caf48a304d637a766

--bcaec54d475caf48a304d637a766
Content-Type: text/plain; charset=ISO-8859-1

Good morning,
as we are approaching the Xen 4.3 freeze, I think it is time to start
thinking about Test Days for Xen 4.3. The question we need to answer is
a) How many test days do we think make sense during the release cycle
b) What cadence? Every other week, every 3, ...
c) At which point do we start?
c) Are there any areas we want to point users to : in other words, we need
a good document early pointing people to the new features we would like to
see tested (and how this is done). The roadmap is a good start. Maybe we
can start working on this in the next 2 docs days (the next one is on
Monday).
d) Who from the developer community would want to take the lead working
with me or Russell on this
Best Regards
Lars

--bcaec54d475caf48a304d637a766
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good morning,<div>as we are approaching the Xen 4.3 freeze, I think it is t=
ime to start thinking about Test Days for Xen 4.3. The question we need to =
answer is</div><div>a) How many test days do we think make sense during the=
 release cycle</div>
<div>b) What cadence? Every other week, every 3, ...</div><div>c) At which =
point do we start?</div><div>c) Are there any areas we want to point users =
to : in other words, we need a good document early pointing people to the n=
ew features we would like to see tested (and how this is done). The roadmap=
 is a good start. Maybe we can start working on this in the next 2 docs day=
s (the next one is on Monday).</div>
<div>d) Who from the developer community would want to take the lead workin=
g with me or Russell on this=A0</div><div>Best Regards</div><div>Lars</div>

--bcaec54d475caf48a304d637a766--


--===============5649992130564628602==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5649992130564628602==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 08:14:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 08:14: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 1U8RI0-0006jq-Ss; Thu, 21 Feb 2013 08:14:00 +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 1U8RHz-0006jl-NS
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 08:13:59 +0000
Received: from [85.158.137.99:16746] by server-14.bemta-3.messagelabs.com id
	CA/9A-23533-247D5215; Thu, 21 Feb 2013 08:13:54 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361434432!12603787!1
X-Originating-IP: [209.85.214.178]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2861 invoked from network); 21 Feb 2013 08:13:53 -0000
Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com)
	(209.85.214.178)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 08:13:53 -0000
Received: by mail-ob0-f178.google.com with SMTP id wd20so8364791obb.23
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 00:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=FxMiAJz84vv4E7Ak8DlptMd4JX/HcAnBP7Gag5mqpo0=;
	b=dgZsHAhujToPOwISh5PBRU2z7W78N+37uZmM2Rk4HL4pxRoG13Zd+zGA2zBeeNPicD
	q5NBFg7+s1O28M6tHkdwP1rVkBT+TpM0DA+H70qu/scZIh3oPYp+gEIhEIiRwMxUyLBK
	Amr67CEduvUQ6YWRnsuZznMqCxM1EGU9MaIn02R9mi4joYd6ykzEZXTNTthi1X75jzSO
	6S/4N8pT/i5D0uvBq3ba9eK7nCivwzYJuxvrsCYd/NLX0D81GWjjDwtlNkLAii9Jbwpi
	G4ace0sJzrIvCDsR9xKGxfNSEkh32pwuBsWG7urvD5l6Yq9vNWwy4KqaGKsuebTufrrU
	WnZA==
MIME-Version: 1.0
X-Received: by 10.60.170.44 with SMTP id aj12mr10243972oec.42.1361434431670;
	Thu, 21 Feb 2013 00:13:51 -0800 (PST)
Received: by 10.60.102.139 with HTTP; Thu, 21 Feb 2013 00:13:51 -0800 (PST)
Date: Thu, 21 Feb 2013 08:13:51 +0000
Message-ID: <CAOqnZH4St12Kyxgmaj-ghw0ayyPWc5gh+7mCTekjS0z5C1bYWQ@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-devel@lists.xen.org, russell.pavlicek@xen.org
Subject: [Xen-devel] Planning Xen Test Days for 4.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: multipart/mixed; boundary="===============5649992130564628602=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5649992130564628602==
Content-Type: multipart/alternative; boundary=bcaec54d475caf48a304d637a766

--bcaec54d475caf48a304d637a766
Content-Type: text/plain; charset=ISO-8859-1

Good morning,
as we are approaching the Xen 4.3 freeze, I think it is time to start
thinking about Test Days for Xen 4.3. The question we need to answer is
a) How many test days do we think make sense during the release cycle
b) What cadence? Every other week, every 3, ...
c) At which point do we start?
c) Are there any areas we want to point users to : in other words, we need
a good document early pointing people to the new features we would like to
see tested (and how this is done). The roadmap is a good start. Maybe we
can start working on this in the next 2 docs days (the next one is on
Monday).
d) Who from the developer community would want to take the lead working
with me or Russell on this
Best Regards
Lars

--bcaec54d475caf48a304d637a766
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good morning,<div>as we are approaching the Xen 4.3 freeze, I think it is t=
ime to start thinking about Test Days for Xen 4.3. The question we need to =
answer is</div><div>a) How many test days do we think make sense during the=
 release cycle</div>
<div>b) What cadence? Every other week, every 3, ...</div><div>c) At which =
point do we start?</div><div>c) Are there any areas we want to point users =
to : in other words, we need a good document early pointing people to the n=
ew features we would like to see tested (and how this is done). The roadmap=
 is a good start. Maybe we can start working on this in the next 2 docs day=
s (the next one is on Monday).</div>
<div>d) Who from the developer community would want to take the lead workin=
g with me or Russell on this=A0</div><div>Best Regards</div><div>Lars</div>

--bcaec54d475caf48a304d637a766--


--===============5649992130564628602==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5649992130564628602==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 08:49:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 08:49: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 1U8RpN-0007TH-V8; Thu, 21 Feb 2013 08:48: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 1U8RpM-0007TC-Ln
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 08:48:28 +0000
Received: from [85.158.138.51:10211] by server-10.bemta-3.messagelabs.com id
	56/2E-10609-B5FD5215; Thu, 21 Feb 2013 08:48:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361436506!28466792!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22125 invoked from network); 21 Feb 2013 08:48:27 -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; 21 Feb 2013 08:48:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8RpK-0006HQ-2j; Thu, 21 Feb 2013 08:48:26 +0000
Date: Thu, 21 Feb 2013 08:48:26 +0000
From: Tim Deegan <tim@xen.org>
To: Kai Luo <luokain@gmail.com>
Message-ID: <20130221084826.GA24051@ocelot.phlegethon.org>
References: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Question about PoD and Transcendent Memory for 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

At 10:30 +0800 on 21 Feb (1361442605), Kai Luo wrote:
> Hi:
>       I am working at the source code of Xen 4.1.3 and have two questions
> that confused me.
>       I remembered a mail of XCP-mail-list which said when a hvm is
> created,xen allocate all memory it requests,which can guarantee the
> stability and Qos or something.However,when I come into the part of memory
> source code,I tind the existance of PoD,which can adjust memory
> dynamically,so I want to make sure whether the mechanism of memory
> management between XCP and Xen is differrent,Xen can adjust the memory size
> of HVM dynamically instead of a fixed memory size,am I right?

If the OS running in the HVM VM is Xen-aware and has a balloon driver,
then it can adjust its memory size dynamically, yes.

The PoD feature is a stop-gap to allow the OS to boot and start its
balloon driver, if it's booting with less than its full memory
allocation.  It's not enough by itself: the guest needs to have a
balloon driver as well.

>       I know the Transcendent Memory is a better techniche of memory
> reuse,is it used in xen for HVM now?

I believe so, though again you need OS support in the VM.

Also you should note that using tmem is not recommended in production
environments, pending a security audit:

http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html

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 Feb 21 08:49:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 08:49: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 1U8RpN-0007TH-V8; Thu, 21 Feb 2013 08:48: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 1U8RpM-0007TC-Ln
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 08:48:28 +0000
Received: from [85.158.138.51:10211] by server-10.bemta-3.messagelabs.com id
	56/2E-10609-B5FD5215; Thu, 21 Feb 2013 08:48:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361436506!28466792!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22125 invoked from network); 21 Feb 2013 08:48:27 -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; 21 Feb 2013 08:48:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8RpK-0006HQ-2j; Thu, 21 Feb 2013 08:48:26 +0000
Date: Thu, 21 Feb 2013 08:48:26 +0000
From: Tim Deegan <tim@xen.org>
To: Kai Luo <luokain@gmail.com>
Message-ID: <20130221084826.GA24051@ocelot.phlegethon.org>
References: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Question about PoD and Transcendent Memory for 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

At 10:30 +0800 on 21 Feb (1361442605), Kai Luo wrote:
> Hi:
>       I am working at the source code of Xen 4.1.3 and have two questions
> that confused me.
>       I remembered a mail of XCP-mail-list which said when a hvm is
> created,xen allocate all memory it requests,which can guarantee the
> stability and Qos or something.However,when I come into the part of memory
> source code,I tind the existance of PoD,which can adjust memory
> dynamically,so I want to make sure whether the mechanism of memory
> management between XCP and Xen is differrent,Xen can adjust the memory size
> of HVM dynamically instead of a fixed memory size,am I right?

If the OS running in the HVM VM is Xen-aware and has a balloon driver,
then it can adjust its memory size dynamically, yes.

The PoD feature is a stop-gap to allow the OS to boot and start its
balloon driver, if it's booting with less than its full memory
allocation.  It's not enough by itself: the guest needs to have a
balloon driver as well.

>       I know the Transcendent Memory is a better techniche of memory
> reuse,is it used in xen for HVM now?

I believe so, though again you need OS support in the VM.

Also you should note that using tmem is not recommended in production
environments, pending a security audit:

http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html

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 Feb 21 09:03:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09: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 1U8S3X-0007oa-DP; Thu, 21 Feb 2013 09:03:07 +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 1U8S3W-0007oV-RS
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 09:03:06 +0000
Received: from [85.158.139.211:25754] by server-12.bemta-5.messagelabs.com id
	47/93-20195-AC2E5215; Thu, 21 Feb 2013 09:03:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361437329!18482267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32521 invoked from network); 21 Feb 2013 09:02:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 09:02:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8S2L-0006Jb-LQ; Thu, 21 Feb 2013 09:01:53 +0000
Date: Thu, 21 Feb 2013 09:01:53 +0000
From: Tim Deegan <tim@xen.org>
To: zhang zhi <zhangzhi2022@hotmail.com>
Message-ID: <20130221090153.GC24051@ocelot.phlegethon.org>
References: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen 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

Hi,

At 23:59 +0800 on 15 Feb (1360972763), zhang zhi wrote:
>          In the context of multi-core mode, core 1 is in root-mode, meaning
> that it's running VMM. And core 2 is in non-root mode, meaning that it's
> running guest OS in kernel level. If core 1 wants core2 to execute a
> pre-defined program located in kernel-mode, say a syscall or a virtual
> external interrupt handler(the program is completed via syscall or another
> kernel module). Considering that core1 is in vmm mode, and core2 is not
> supposed to vm-exit, so I can't use the method of event-delivery. What kind
> of thing should core 1 do ? 

If you need the VM on core 2 to act immediately (and it's currently
doing something other than waiting for core 1 to send it a message) then
you'll need to send it some sort of interrupt.  There's no way of doing
that in Xen without core 2 vm-exiting, because all interrupts are
handled in Xen.

In theory you could implement something like ELI for Xen.  That could be
interesting, not least as a piece of repeated research, but it's quite a
serious undertaking.
(http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)

Of course, if you don't need an immediate answer, any shared-memory
protocol will do.  You just need to arrange for the VM to check for
messages periodically.

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 Feb 21 09:03:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09: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 1U8S3X-0007oa-DP; Thu, 21 Feb 2013 09:03:07 +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 1U8S3W-0007oV-RS
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 09:03:06 +0000
Received: from [85.158.139.211:25754] by server-12.bemta-5.messagelabs.com id
	47/93-20195-AC2E5215; Thu, 21 Feb 2013 09:03:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361437329!18482267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32521 invoked from network); 21 Feb 2013 09:02:13 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 09:02:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8S2L-0006Jb-LQ; Thu, 21 Feb 2013 09:01:53 +0000
Date: Thu, 21 Feb 2013 09:01:53 +0000
From: Tim Deegan <tim@xen.org>
To: zhang zhi <zhangzhi2022@hotmail.com>
Message-ID: <20130221090153.GC24051@ocelot.phlegethon.org>
References: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen 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

Hi,

At 23:59 +0800 on 15 Feb (1360972763), zhang zhi wrote:
>          In the context of multi-core mode, core 1 is in root-mode, meaning
> that it's running VMM. And core 2 is in non-root mode, meaning that it's
> running guest OS in kernel level. If core 1 wants core2 to execute a
> pre-defined program located in kernel-mode, say a syscall or a virtual
> external interrupt handler(the program is completed via syscall or another
> kernel module). Considering that core1 is in vmm mode, and core2 is not
> supposed to vm-exit, so I can't use the method of event-delivery. What kind
> of thing should core 1 do ? 

If you need the VM on core 2 to act immediately (and it's currently
doing something other than waiting for core 1 to send it a message) then
you'll need to send it some sort of interrupt.  There's no way of doing
that in Xen without core 2 vm-exiting, because all interrupts are
handled in Xen.

In theory you could implement something like ELI for Xen.  That could be
interesting, not least as a piece of repeated research, but it's quite a
serious undertaking.
(http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)

Of course, if you don't need an immediate answer, any shared-memory
protocol will do.  You just need to arrange for the VM to check for
messages periodically.

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 Feb 21 09:10:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09:10: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 1U8SAH-0007yY-9U; Thu, 21 Feb 2013 09:10:05 +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 1U8SAG-0007yS-6F
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 09:10:04 +0000
Received: from [85.158.139.211:44992] by server-1.bemta-5.messagelabs.com id
	95/D6-29263-B64E5215; Thu, 21 Feb 2013 09:10:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361437801!18483385!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1110 invoked from network); 21 Feb 2013 09:10:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 09:10:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8SAD-0006Kr-4D; Thu, 21 Feb 2013 09:10:01 +0000
Date: Thu, 21 Feb 2013 09:10:01 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130221091001.GD24051@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@ocelot.phlegethon.org>
	<20130220190519.5fb537b1@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130220190519.5fb537b1@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] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 19:05 -0800 on 20 Feb (1361387119), Mukesh Rathor wrote:
> On Wed, 20 Feb 2013 09:58:28 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > > On Thu, 24 Jan 2013 16:31:22 +0000
> > > Tim Deegan <tim@xen.org> wrote:
> > > 
> > > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > > +
> > > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > > +        {
> > > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > > +                pv_cpuid(regs);
> > > > > +
> > > > > +                /* Because we are setting CR4.OSFXSR to 0, we
> > > > > need to disable
> > > > > +                 * this because, during boot, user process
> > > > > "init" (which doesn't
> > > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > > cause #UD. For now 
> > > > > +                 * disable this. HVM doesn't allow setting of
> > > > > CR4.OSFXSR.
> > > > > +                 * fixme: this and also look at CR4.OSXSAVE */
> > > > > +
> > > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > > 
> > > > Shouldn't this be gated on which leaf the guest asked for?
> > > 
> > > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > > work. The user process "init" running nash is executing pxor %xmm0,
> > > %xmm0 and taking #UD. Strangely, it works with EAX==0, meaning if I
> > > clear the bit for EAX==0, changing the intel string "ineI".  This
> > > user process doesn't do cpuid, so it must be affected by it some
> > > other way.
> > > 
> > > Pretty hard to debug since it's in nash user code from ramdisk and
> > > I am not able to set breakpoint or put printf's easily to figure
> > > why clearing bit for EAX==0 makes it work, or what's going on for
> > > PV and HVM guest. CR0.EM is 0, so UD is coming from CR4.OSFXSR==0.
> > > Reading the SDMs to learn OSFXSR stuff better....
> > 
> > Perhaps you need to clear the FXSR feature bit in leaf 0x80000001:EDX
> > as well?
> 
> That appears to be AMD only.

It still needs to be handled. :)   You are testing this stuff on AMD as
well, right?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 09:10:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09:10: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 1U8SAH-0007yY-9U; Thu, 21 Feb 2013 09:10:05 +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 1U8SAG-0007yS-6F
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 09:10:04 +0000
Received: from [85.158.139.211:44992] by server-1.bemta-5.messagelabs.com id
	95/D6-29263-B64E5215; Thu, 21 Feb 2013 09:10:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361437801!18483385!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1110 invoked from network); 21 Feb 2013 09:10:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 09:10:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8SAD-0006Kr-4D; Thu, 21 Feb 2013 09:10:01 +0000
Date: Thu, 21 Feb 2013 09:10:01 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130221091001.GD24051@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@ocelot.phlegethon.org>
	<20130220190519.5fb537b1@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130220190519.5fb537b1@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] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 19:05 -0800 on 20 Feb (1361387119), Mukesh Rathor wrote:
> On Wed, 20 Feb 2013 09:58:28 +0000
> Tim Deegan <tim@xen.org> wrote:
> 
> > At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > > On Thu, 24 Jan 2013 16:31:22 +0000
> > > Tim Deegan <tim@xen.org> wrote:
> > > 
> > > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > > +
> > > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > > +        {
> > > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > > +                pv_cpuid(regs);
> > > > > +
> > > > > +                /* Because we are setting CR4.OSFXSR to 0, we
> > > > > need to disable
> > > > > +                 * this because, during boot, user process
> > > > > "init" (which doesn't
> > > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > > cause #UD. For now 
> > > > > +                 * disable this. HVM doesn't allow setting of
> > > > > CR4.OSFXSR.
> > > > > +                 * fixme: this and also look at CR4.OSXSAVE */
> > > > > +
> > > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > > 
> > > > Shouldn't this be gated on which leaf the guest asked for?
> > > 
> > > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > > work. The user process "init" running nash is executing pxor %xmm0,
> > > %xmm0 and taking #UD. Strangely, it works with EAX==0, meaning if I
> > > clear the bit for EAX==0, changing the intel string "ineI".  This
> > > user process doesn't do cpuid, so it must be affected by it some
> > > other way.
> > > 
> > > Pretty hard to debug since it's in nash user code from ramdisk and
> > > I am not able to set breakpoint or put printf's easily to figure
> > > why clearing bit for EAX==0 makes it work, or what's going on for
> > > PV and HVM guest. CR0.EM is 0, so UD is coming from CR4.OSFXSR==0.
> > > Reading the SDMs to learn OSFXSR stuff better....
> > 
> > Perhaps you need to clear the FXSR feature bit in leaf 0x80000001:EDX
> > as well?
> 
> That appears to be AMD only.

It still needs to be handled. :)   You are testing this stuff on AMD as
well, right?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 09:25:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09: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 1U8SOY-0008Sk-Jh; Thu, 21 Feb 2013 09:24:50 +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 1U8SOY-0008Sf-4v
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 09:24:50 +0000
Received: from [85.158.139.83:15384] by server-11.bemta-5.messagelabs.com id
	F7/CA-19159-1E7E5215; Thu, 21 Feb 2013 09:24:49 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361438685!25520989!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzEzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21706 invoked from network); 21 Feb 2013 09:24:46 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 09:24:46 -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 D152121A5;
	Thu, 21 Feb 2013 11:24:34 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A743E241C6; Thu, 21 Feb 2013 11:24:34 +0200 (EET)
Date: Thu, 21 Feb 2013 11:24:34 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20130221092434.GQ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Linux 3.4 dom0 kernel error loading xen-acpi-processor:
 Input/output 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

Hello,

Does anyone know why loading xen-acpi-processor driver fails like this?:

# modprobe xen-acpi-processor
FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error

Using "modprobe -v" doesn't provide any more information about the problem.
Also there's nothing in dom0 kernel dmesg.

Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
Xen 4.2.1.

Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
with some additional Xen patches backported from later upstream kernels. 
Any tips how to troubleshoot this? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 09:25:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09: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 1U8SOY-0008Sk-Jh; Thu, 21 Feb 2013 09:24:50 +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 1U8SOY-0008Sf-4v
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 09:24:50 +0000
Received: from [85.158.139.83:15384] by server-11.bemta-5.messagelabs.com id
	F7/CA-19159-1E7E5215; Thu, 21 Feb 2013 09:24:49 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361438685!25520989!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzEzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21706 invoked from network); 21 Feb 2013 09:24:46 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 09:24:46 -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 D152121A5;
	Thu, 21 Feb 2013 11:24:34 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A743E241C6; Thu, 21 Feb 2013 11:24:34 +0200 (EET)
Date: Thu, 21 Feb 2013 11:24:34 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20130221092434.GQ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Linux 3.4 dom0 kernel error loading xen-acpi-processor:
 Input/output 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

Hello,

Does anyone know why loading xen-acpi-processor driver fails like this?:

# modprobe xen-acpi-processor
FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error

Using "modprobe -v" doesn't provide any more information about the problem.
Also there's nothing in dom0 kernel dmesg.

Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
Xen 4.2.1.

Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
with some additional Xen patches backported from later upstream kernels. 
Any tips how to troubleshoot this? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 09:42:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09: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 1U8Seo-0000TW-GK; Thu, 21 Feb 2013 09:41:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U8Sem-0000TP-Hv
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 09:41:36 +0000
Received: from [85.158.139.211:9219] by server-16.bemta-5.messagelabs.com id
	7C/FC-14948-FCBE5215; Thu, 21 Feb 2013 09:41:35 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361439694!18552526!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14287 invoked from network); 21 Feb 2013 09:41:35 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Feb 2013 09:41:35 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U8Sea-0000FN-Hy; Thu, 21 Feb 2013 09:41:24 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U8SeX-0007IQ-Gg; Thu, 21 Feb 2013 09:41:24 +0000
Message-ID: <1361439675.26546.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: Laszlo Ersek <lersek@redhat.com>
Date: Thu, 21 Feb 2013 09:41:15 +0000
In-Reply-To: <5125533B.4060502@redhat.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
	<5124FFED.3000106@redhat.com>
	<1361380698.26546.21.camel@zakaz.uk.xensource.com>
	<5125533B.4060502@redhat.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: "seabios@seabios.org" <seabios@seabios.org>,
	Andrei Warkentin <andrey.warkentin@gmail.com>,
	"edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>, David Woodhouse <dwmw2@infradead.org>,
	Bei Guan <gbtju85@gmail.com>
Subject: Re: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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

(dropping Attilio he has left Citrix).

On Wed, 2013-02-20 at 23:50 +0100, Laszlo Ersek wrote:
> On 02/20/13 18:18, Ian Campbell wrote:
> > On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
> >> However in OVMF the RESERVED_MEMBASE range is not parsed from this
> >> Xen-exported table, it is added manually in InitializeXen()
> >> [OvmfPkg/PlatformPei/Xen.c]:
> >>
> >>   //
> >>   // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> >>   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
> >>   //
> >>   AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);
> > 
> > ICK, it would be far preferable for OVMF to do what SeaBIOS does and
> > actually "communicate" with hvmloader IMHO.
> 
> The table with "XenHVMSeaBIOS" signature is not created for OVMF I
> think; comparing the "bios_config" structure of function pointers
> between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the
> ovmf_config.bios_info_setup field is NULL.

Yes. I think this should be changed then to provide a proper way for
hvmloader to communicate to OVMF. It would seem sensible to follow a
similar mechanism to SeaBIOS, or if possible just reuse the exact same
thing (perhaps with a different signature).

> However there seem to be at least two "info" tables. Referring back,
> "seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS
> only, but "hvm_info" just below the end of conventional memory (at
> HVM_INFO_PADDR, 0x9F800) looks guest firmware independent.

hvm_info is used by the toolstack to pass parameters to hvmloader itself
when it starts, it is not intended to pass options from hvmloader to the
bios. It is not a stable ABI struct (since hvmloader and the toolstack
are a matched pair it doesn't have to be) and we hope to eventually get
rid of it. Possibly hvmloader should scrub it before calling the BIOS to
discourage its use.

> 
> I guess the quoted range would be available from
> "hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment
> in XenConnect() saying
> 
>   /* TBD: Locate hvm_info and reserve it away. */
>   mXenInfo.HvmInfo = NULL;

Oh dear.

> Is the generic approach "see if you can find all what you need in
> hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.)

As I hope is clear from the above, Nope ;-)

Ian.
-- 
Ian Campbell

"Everyone is entitled to an *informed* opinion."
		-- Harlan Ellison


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 09:42:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 09: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 1U8Seo-0000TW-GK; Thu, 21 Feb 2013 09:41:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1U8Sem-0000TP-Hv
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 09:41:36 +0000
Received: from [85.158.139.211:9219] by server-16.bemta-5.messagelabs.com id
	7C/FC-14948-FCBE5215; Thu, 21 Feb 2013 09:41:35 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361439694!18552526!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14287 invoked from network); 21 Feb 2013 09:41:35 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Feb 2013 09:41:35 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>)
	id 1U8Sea-0000FN-Hy; Thu, 21 Feb 2013 09:41:24 +0000
Received: from firewall.ctxuk.citrix.com ([46.33.159.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1U8SeX-0007IQ-Gg; Thu, 21 Feb 2013 09:41:24 +0000
Message-ID: <1361439675.26546.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: Laszlo Ersek <lersek@redhat.com>
Date: Thu, 21 Feb 2013 09:41:15 +0000
In-Reply-To: <5125533B.4060502@redhat.com>
References: <cover.1360434963.git.kevin@koconnor.net>
	<1360757100.20449.233.camel@zakaz.uk.xensource.com>
	<1360757682.10581.62.camel@shinybook.infradead.org>
	<1360760200.20449.237.camel@zakaz.uk.xensource.com>
	<1360771718.10581.69.camel@shinybook.infradead.org>
	<1360841263.20449.342.camel@zakaz.uk.xensource.com>
	<1360844986.10581.227.camel@shinybook.infradead.org>
	<1360846438.20449.365.camel@zakaz.uk.xensource.com>
	<1360847129.10581.235.camel@shinybook.infradead.org>
	<1360849951.10581.239.camel@shinybook.infradead.org>
	<1360850923.20449.390.camel@zakaz.uk.xensource.com>
	<1360851838.10581.248.camel@shinybook.infradead.org>
	<1360860396.20449.471.camel@zakaz.uk.xensource.com>
	<1360930184.6534.16.camel@i7.infradead.org>
	<1361269257.1051.91.camel@zakaz.uk.xensource.com>
	<1361271060.13482.184.camel@i7.infradead.org>
	<1361361460.23294.22.camel@zakaz.uk.xensource.com>
	<5124FFED.3000106@redhat.com>
	<1361380698.26546.21.camel@zakaz.uk.xensource.com>
	<5125533B.4060502@redhat.com>
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 46.33.159.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: "seabios@seabios.org" <seabios@seabios.org>,
	Andrei Warkentin <andrey.warkentin@gmail.com>,
	"edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>, David Woodhouse <dwmw2@infradead.org>,
	Bei Guan <gbtju85@gmail.com>
Subject: Re: [Xen-devel] placement of emulated flash [was: seabios Improved
 multi-platform 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

(dropping Attilio he has left Citrix).

On Wed, 2013-02-20 at 23:50 +0100, Laszlo Ersek wrote:
> On 02/20/13 18:18, Ian Campbell wrote:
> > On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:
> >> However in OVMF the RESERVED_MEMBASE range is not parsed from this
> >> Xen-exported table, it is added manually in InitializeXen()
> >> [OvmfPkg/PlatformPei/Xen.c]:
> >>
> >>   //
> >>   // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000).
> >>   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
> >>   //
> >>   AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);
> > 
> > ICK, it would be far preferable for OVMF to do what SeaBIOS does and
> > actually "communicate" with hvmloader IMHO.
> 
> The table with "XenHVMSeaBIOS" signature is not created for OVMF I
> think; comparing the "bios_config" structure of function pointers
> between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the
> ovmf_config.bios_info_setup field is NULL.

Yes. I think this should be changed then to provide a proper way for
hvmloader to communicate to OVMF. It would seem sensible to follow a
similar mechanism to SeaBIOS, or if possible just reuse the exact same
thing (perhaps with a different signature).

> However there seem to be at least two "info" tables. Referring back,
> "seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS
> only, but "hvm_info" just below the end of conventional memory (at
> HVM_INFO_PADDR, 0x9F800) looks guest firmware independent.

hvm_info is used by the toolstack to pass parameters to hvmloader itself
when it starts, it is not intended to pass options from hvmloader to the
bios. It is not a stable ABI struct (since hvmloader and the toolstack
are a matched pair it doesn't have to be) and we hope to eventually get
rid of it. Possibly hvmloader should scrub it before calling the BIOS to
discourage its use.

> 
> I guess the quoted range would be available from
> "hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment
> in XenConnect() saying
> 
>   /* TBD: Locate hvm_info and reserve it away. */
>   mXenInfo.HvmInfo = NULL;

Oh dear.

> Is the generic approach "see if you can find all what you need in
> hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.)

As I hope is clear from the above, Nope ;-)

Ian.
-- 
Ian Campbell

"Everyone is entitled to an *informed* opinion."
		-- Harlan Ellison


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 10:01:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 10: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 1U8Sxr-0000oo-Aj; Thu, 21 Feb 2013 10:01:19 +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 1U8Sxp-0000oj-8r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:01:17 +0000
Received: from [85.158.138.51:58568] by server-8.bemta-3.messagelabs.com id
	73/90-25687-C60F5215; Thu, 21 Feb 2013 10:01:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361440868!20489911!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5847 invoked from network); 21 Feb 2013 10:01:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 10:01:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="1721670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 10:01: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.297.1;
	Thu, 21 Feb 2013 10:01:08 +0000
Message-ID: <1361440867.26546.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 21 Feb 2013 10:01:07 +0000
In-Reply-To: <6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] tools/libxc: Implement of
 xc_readconsolering_buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
> Functions identically to xc_readconsolering(), but uses a user-provided
> xc_hypercall_buffer_t to save using a bounce buffer.

Can we now trivially reimplement xc_readconsolering in terms of this
function?

Should just be a case of replacing all the code between bounce_pre and
bounce_post with a call
	xc_readconsolering_buffer(xch, HYPERCALL_BUFFER_AS_ARG(buffer),
                                  pnr_chars, clear, incremental, pindex);
?

We should probably also deprecate the old one and at least have a vague
idea that we might eventually switch all the callers over (you don't
need to here though, unless you are super keen).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 10:01:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 10: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 1U8Sxr-0000oo-Aj; Thu, 21 Feb 2013 10:01:19 +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 1U8Sxp-0000oj-8r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:01:17 +0000
Received: from [85.158.138.51:58568] by server-8.bemta-3.messagelabs.com id
	73/90-25687-C60F5215; Thu, 21 Feb 2013 10:01:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361440868!20489911!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5847 invoked from network); 21 Feb 2013 10:01:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 10:01:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="1721670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 10:01: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.297.1;
	Thu, 21 Feb 2013 10:01:08 +0000
Message-ID: <1361440867.26546.44.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 21 Feb 2013 10:01:07 +0000
In-Reply-To: <6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] tools/libxc: Implement of
 xc_readconsolering_buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
> Functions identically to xc_readconsolering(), but uses a user-provided
> xc_hypercall_buffer_t to save using a bounce buffer.

Can we now trivially reimplement xc_readconsolering in terms of this
function?

Should just be a case of replacing all the code between bounce_pre and
bounce_post with a call
	xc_readconsolering_buffer(xch, HYPERCALL_BUFFER_AS_ARG(buffer),
                                  pnr_chars, clear, incremental, pindex);
?

We should probably also deprecate the old one and at least have a vague
idea that we might eventually switch all the callers over (you don't
need to here though, unless you are super keen).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 10:15:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 10: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 1U8TAv-00019Q-Rc; Thu, 21 Feb 2013 10:14: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 1U8TAv-00019J-1B
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:14:49 +0000
Received: from [85.158.138.51:41879] by server-13.bemta-3.messagelabs.com id
	F1/01-20653-793F5215; Thu, 21 Feb 2013 10:14:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361441669!28525351!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30195 invoked from network); 21 Feb 2013 10:14:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 10:14:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="1722668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 10:14: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.297.1;
	Thu, 21 Feb 2013 10:14:29 +0000
Message-ID: <1361441667.26546.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 21 Feb 2013 10:14:27 +0000
In-Reply-To: <a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
> There are two problems with this function:
>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>     compete for use of the static ring[] buffer.
>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>     more of its console ring.
> 
> Rewrite the function using the new xc_consoleringsize() and
> xc_readconsolering_buffer() functions to efficiently grab the entire console
> ring.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 6b8c513cff4f -r a73d0c5a5b24 tools/ocaml/libs/xc/xenctrl_stubs.c
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -523,27 +523,61 @@ CAMLprim value stub_xc_evtchn_reset(valu
>  	CAMLreturn(Val_unit);
>  }
>  
> -
> -#define RING_SIZE 32768
> -static char ring[RING_SIZE];
> -
> +/* Maximum size of console ring we are prepared to read, 16MB */
> +#define MAX_CONSOLE_RING_SIZE (1U << 24)

A bit arbitrary, why not just let it handle whatever the hypervisor
throws at it. If there is to be a limit it probably belongs on the
hypervisor side, but in the meantime someone who passes consring=1G can
keep all the pieces ;-)

>  CAMLprim value stub_xc_readconsolering(value xch)
>  {
> -	unsigned int size = RING_SIZE - 1;
> -	char *ring_ptr = ring;
> -	int retval;
> +	uint64_t conring_size;
> +	DECLARE_HYPERCALL_BUFFER(char, ring);
> +	unsigned int nr_chars;
> +	int r;
>  
>  	CAMLparam1(xch);
> +	CAMLlocal1(conring);
> +
> +	r = xc_consoleringsize(_H(xch), &conring_size);

static int consoleringsize and only call this once the first time?

> +
> +	if ( r )
> +	{
> +		failwith_xc(_H(xch));
> +		CAMLreturn(Val_unit);
> +	}
> +
> +	/* Round conring_size up to the next page, for NULL terminator and
> +	   slop from a race with printk() in the hypervisor. */
> +	conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
> +	nr_chars = conring_size-1;
> +
> +	if ( conring_size > MAX_CONSOLE_RING_SIZE )
> +	{
> +		caml_failwith("Console ring too large");
> +		CAMLreturn(Val_unit);
> +	}
> +
> +	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
> +
> +	if ( ! ring )
> +	{
> +		failwith_xc(_H(xch));
> +		CAMLreturn(Val_unit);
> +	}
>  
>  	caml_enter_blocking_section();
> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
> +	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
> +				      &nr_chars, 0, 0, NULL);
>  	caml_leave_blocking_section();
>  
> -	if (retval)
> +	if ( r )
> +	{
>  		failwith_xc(_H(xch));

Doesn't this (due to caml_raise...) end up exiting synchronously via a
longjmp back to the runtime? i.e. it leaks the buffer which is only
free'd after.

It's a good idea to cc xen-api@ with ocaml changes, for this sort of
reason...


> +		xc_hypercall_buffer_free(_H(xch), ring);
> +		CAMLreturn(Val_unit);

I think CAMLnoreturn here.

> +	}
>  
> -	ring[size] = '\0';
> -	CAMLreturn(caml_copy_string(ring));
> +	ring[nr_chars] = '\0';
> +	conring = caml_copy_string(ring);
> +	xc_hypercall_buffer_free(_H(xch), ring);
> +	CAMLreturn(conring);
>  }
>  
>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 10:15:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 10: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 1U8TAv-00019Q-Rc; Thu, 21 Feb 2013 10:14: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 1U8TAv-00019J-1B
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:14:49 +0000
Received: from [85.158.138.51:41879] by server-13.bemta-3.messagelabs.com id
	F1/01-20653-793F5215; Thu, 21 Feb 2013 10:14:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361441669!28525351!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30195 invoked from network); 21 Feb 2013 10:14:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 10:14:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="1722668"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 10:14: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.297.1;
	Thu, 21 Feb 2013 10:14:29 +0000
Message-ID: <1361441667.26546.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu, 21 Feb 2013 10:14:27 +0000
In-Reply-To: <a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
> There are two problems with this function:
>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>     compete for use of the static ring[] buffer.
>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>     more of its console ring.
> 
> Rewrite the function using the new xc_consoleringsize() and
> xc_readconsolering_buffer() functions to efficiently grab the entire console
> ring.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 6b8c513cff4f -r a73d0c5a5b24 tools/ocaml/libs/xc/xenctrl_stubs.c
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -523,27 +523,61 @@ CAMLprim value stub_xc_evtchn_reset(valu
>  	CAMLreturn(Val_unit);
>  }
>  
> -
> -#define RING_SIZE 32768
> -static char ring[RING_SIZE];
> -
> +/* Maximum size of console ring we are prepared to read, 16MB */
> +#define MAX_CONSOLE_RING_SIZE (1U << 24)

A bit arbitrary, why not just let it handle whatever the hypervisor
throws at it. If there is to be a limit it probably belongs on the
hypervisor side, but in the meantime someone who passes consring=1G can
keep all the pieces ;-)

>  CAMLprim value stub_xc_readconsolering(value xch)
>  {
> -	unsigned int size = RING_SIZE - 1;
> -	char *ring_ptr = ring;
> -	int retval;
> +	uint64_t conring_size;
> +	DECLARE_HYPERCALL_BUFFER(char, ring);
> +	unsigned int nr_chars;
> +	int r;
>  
>  	CAMLparam1(xch);
> +	CAMLlocal1(conring);
> +
> +	r = xc_consoleringsize(_H(xch), &conring_size);

static int consoleringsize and only call this once the first time?

> +
> +	if ( r )
> +	{
> +		failwith_xc(_H(xch));
> +		CAMLreturn(Val_unit);
> +	}
> +
> +	/* Round conring_size up to the next page, for NULL terminator and
> +	   slop from a race with printk() in the hypervisor. */
> +	conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
> +	nr_chars = conring_size-1;
> +
> +	if ( conring_size > MAX_CONSOLE_RING_SIZE )
> +	{
> +		caml_failwith("Console ring too large");
> +		CAMLreturn(Val_unit);
> +	}
> +
> +	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
> +
> +	if ( ! ring )
> +	{
> +		failwith_xc(_H(xch));
> +		CAMLreturn(Val_unit);
> +	}
>  
>  	caml_enter_blocking_section();
> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
> +	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
> +				      &nr_chars, 0, 0, NULL);
>  	caml_leave_blocking_section();
>  
> -	if (retval)
> +	if ( r )
> +	{
>  		failwith_xc(_H(xch));

Doesn't this (due to caml_raise...) end up exiting synchronously via a
longjmp back to the runtime? i.e. it leaks the buffer which is only
free'd after.

It's a good idea to cc xen-api@ with ocaml changes, for this sort of
reason...


> +		xc_hypercall_buffer_free(_H(xch), ring);
> +		CAMLreturn(Val_unit);

I think CAMLnoreturn here.

> +	}
>  
> -	ring[size] = '\0';
> -	CAMLreturn(caml_copy_string(ring));
> +	ring[nr_chars] = '\0';
> +	conring = caml_copy_string(ring);
> +	xc_hypercall_buffer_free(_H(xch), ring);
> +	CAMLreturn(conring);
>  }
>  
>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 10:50:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 10:50: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 1U8Til-0001Za-Px; Thu, 21 Feb 2013 10:49:47 +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 1U8Tik-0001ZV-FQ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:49:46 +0000
Received: from [85.158.138.51:58462] by server-8.bemta-3.messagelabs.com id
	47/A2-25687-9CBF5215; Thu, 21 Feb 2013 10:49:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361443784!28495200!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16436 invoked from network); 21 Feb 2013 10:49:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 10:49:44 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (jored mo4) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h00249p1LA0b93
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 11:49:44 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 097621884C; Thu, 21 Feb 2013 11:49:43 +0100 (CET)
Date: Thu, 21 Feb 2013 11:49:43 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130221104943.GA22260@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130220145823.GA18129@aepfle.de>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 Wed, Feb 20, Olaf Hering wrote:

> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
> (XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40

For some reason nestedhvm_vcpu_destroy is not in the backtrace. And its
not clear why nestedhvm_vcpu_destroy calls into nvmx_vcpu_destroy
anyway. nestedhvm is not in the config file.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 10:50:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 10:50: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 1U8Til-0001Za-Px; Thu, 21 Feb 2013 10:49:47 +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 1U8Tik-0001ZV-FQ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:49:46 +0000
Received: from [85.158.138.51:58462] by server-8.bemta-3.messagelabs.com id
	47/A2-25687-9CBF5215; Thu, 21 Feb 2013 10:49:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361443784!28495200!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16436 invoked from network); 21 Feb 2013 10:49:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 10:49:44 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (jored mo4) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h00249p1LA0b93
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 11:49:44 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 097621884C; Thu, 21 Feb 2013 11:49:43 +0100 (CET)
Date: Thu, 21 Feb 2013 11:49:43 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130221104943.GA22260@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130220145823.GA18129@aepfle.de>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 Wed, Feb 20, Olaf Hering wrote:

> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
> (XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40

For some reason nestedhvm_vcpu_destroy is not in the backtrace. And its
not clear why nestedhvm_vcpu_destroy calls into nvmx_vcpu_destroy
anyway. nestedhvm is not in the config file.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:00:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8Tsb-0001nl-U2; Thu, 21 Feb 2013 10:59: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 1U8TsZ-0001ng-OB
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:59:55 +0000
Received: from [85.158.139.83:27797] by server-9.bemta-5.messagelabs.com id
	0E/7A-24440-B2EF5215; Thu, 21 Feb 2013 10:59:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361444393!24002813!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23465 invoked from network); 21 Feb 2013 10:59:54 -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;
	21 Feb 2013 10:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="8697245"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 10:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 05:59:52 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8TsV-0002yc-WE;
	Thu, 21 Feb 2013 10:59:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 10:59:51 +0000
Message-ID: <1361444391-23892-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix build on 32-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

YWFiNGQxYjI2NmNlICJsaWJ4bDogQWRkIHF4bCB2Z2EgaW50ZXJmYWNlIHN1cHBvcnQgZm9yIHVw
c3RyZWFtIHFlbXUiCmludHJvZHVjZWQ6CglsaWJ4bF9kbS5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4
bF9fYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV34oCZOgoJbGlieGxfZG0uYzo0NDk6IGVycm9y
OiBmb3JtYXQg4oCYJWx14oCZIGV4cGVjdHMgdHlwZSDigJhsb25nIHVuc2lnbmVkIGludOKAmSwg
YnV0IGFyZ3VtZW50IDMgaGFzIHR5cGUg4oCYbG9uZyBsb25nIHVuc2lnbmVkIGludOKAmQoJbGli
eGxfZG0uYzo0NTE6IGVycm9yOiBmb3JtYXQg4oCYJWx14oCZIGV4cGVjdHMgdHlwZSDigJhsb25n
IHVuc2lnbmVkIGludOKAmSwgYnV0IGFyZ3VtZW50IDMgaGFzIHR5cGUg4oCYbG9uZyBsb25nIHVu
c2lnbmVkIGludOKAmQoKb24gYXJtMzIgYW5kIHg4Nl8zMi4KClVzZSB0aGUgaW50dHlwZXMuaCBQ
UklkNjQgbWFjcm8uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPgotLS0KIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMgfCAgICA0ICsrLS0KIDEgZmls
ZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh
L3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCmluZGV4IGM0
Y2ExMWUuLmE4YTM2ZDcgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKKysrIGIv
dG9vbHMvbGlieGwvbGlieGxfZG0uYwpAQCAtNDQ2LDkgKzQ0Niw5IEBAIHN0YXRpYyBjaGFyICoq
IGxpYnhsX19idWlsZF9kZXZpY2VfbW9kZWxfYXJnc19uZXcobGlieGxfX2djICpnYywKICAgICAg
ICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRtX2FyZ3MsICItdmdhIiwgInF4bCIsIE5VTEwpOwog
ICAgICAgICAgICAgaWYgKGJfaW5mby0+dmlkZW9fbWVta2IpIHsKICAgICAgICAgICAgICAgICBm
bGV4YXJyYXlfdmFwcGVuZChkbV9hcmdzLCAiLWdsb2JhbCIsCi0gICAgICAgICAgICAgICAgICAg
IEdDU1BSSU5URigicXhsLXZnYS52cmFtX3NpemVfbWI9JWx1IiwKKyAgICAgICAgICAgICAgICAg
ICAgR0NTUFJJTlRGKCJxeGwtdmdhLnZyYW1fc2l6ZV9tYj0lIlBSSXU2NCwKICAgICAgICAgICAg
ICAgICAgICAgKGJfaW5mby0+dmlkZW9fbWVta2IvMi8xMDI0KSksICItZ2xvYmFsIiwKLSAgICAg
ICAgICAgICAgICAgICAgR0NTUFJJTlRGKCJxeGwtdmdhLnJhbV9zaXplX21iPSVsdSIsCisgICAg
ICAgICAgICAgICAgICAgIEdDU1BSSU5URigicXhsLXZnYS5yYW1fc2l6ZV9tYj0lIlBSSXU2NCwK
ICAgICAgICAgICAgICAgICAgICAgKGJfaW5mby0+dmlkZW9fbWVta2IvMi8xMDI0KSksIE5VTEwp
OwogICAgICAgICAgICAgfQogICAgICAgICAgICAgYnJlYWs7Ci0tIAoxLjcuOS4xCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:00:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8Tsb-0001nl-U2; Thu, 21 Feb 2013 10:59: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 1U8TsZ-0001ng-OB
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 10:59:55 +0000
Received: from [85.158.139.83:27797] by server-9.bemta-5.messagelabs.com id
	0E/7A-24440-B2EF5215; Thu, 21 Feb 2013 10:59:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361444393!24002813!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23465 invoked from network); 21 Feb 2013 10:59:54 -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;
	21 Feb 2013 10:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="8697245"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 10:59:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 05:59:52 -0500
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8TsV-0002yc-WE;
	Thu, 21 Feb 2013 10:59:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 10:59:51 +0000
Message-ID: <1361444391-23892-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix build on 32-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

YWFiNGQxYjI2NmNlICJsaWJ4bDogQWRkIHF4bCB2Z2EgaW50ZXJmYWNlIHN1cHBvcnQgZm9yIHVw
c3RyZWFtIHFlbXUiCmludHJvZHVjZWQ6CglsaWJ4bF9kbS5jOiBJbiBmdW5jdGlvbiDigJhsaWJ4
bF9fYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV34oCZOgoJbGlieGxfZG0uYzo0NDk6IGVycm9y
OiBmb3JtYXQg4oCYJWx14oCZIGV4cGVjdHMgdHlwZSDigJhsb25nIHVuc2lnbmVkIGludOKAmSwg
YnV0IGFyZ3VtZW50IDMgaGFzIHR5cGUg4oCYbG9uZyBsb25nIHVuc2lnbmVkIGludOKAmQoJbGli
eGxfZG0uYzo0NTE6IGVycm9yOiBmb3JtYXQg4oCYJWx14oCZIGV4cGVjdHMgdHlwZSDigJhsb25n
IHVuc2lnbmVkIGludOKAmSwgYnV0IGFyZ3VtZW50IDMgaGFzIHR5cGUg4oCYbG9uZyBsb25nIHVu
c2lnbmVkIGludOKAmQoKb24gYXJtMzIgYW5kIHg4Nl8zMi4KClVzZSB0aGUgaW50dHlwZXMuaCBQ
UklkNjQgbWFjcm8uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPgotLS0KIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMgfCAgICA0ICsrLS0KIDEgZmls
ZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh
L3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCmluZGV4IGM0
Y2ExMWUuLmE4YTM2ZDcgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKKysrIGIv
dG9vbHMvbGlieGwvbGlieGxfZG0uYwpAQCAtNDQ2LDkgKzQ0Niw5IEBAIHN0YXRpYyBjaGFyICoq
IGxpYnhsX19idWlsZF9kZXZpY2VfbW9kZWxfYXJnc19uZXcobGlieGxfX2djICpnYywKICAgICAg
ICAgICAgIGZsZXhhcnJheV92YXBwZW5kKGRtX2FyZ3MsICItdmdhIiwgInF4bCIsIE5VTEwpOwog
ICAgICAgICAgICAgaWYgKGJfaW5mby0+dmlkZW9fbWVta2IpIHsKICAgICAgICAgICAgICAgICBm
bGV4YXJyYXlfdmFwcGVuZChkbV9hcmdzLCAiLWdsb2JhbCIsCi0gICAgICAgICAgICAgICAgICAg
IEdDU1BSSU5URigicXhsLXZnYS52cmFtX3NpemVfbWI9JWx1IiwKKyAgICAgICAgICAgICAgICAg
ICAgR0NTUFJJTlRGKCJxeGwtdmdhLnZyYW1fc2l6ZV9tYj0lIlBSSXU2NCwKICAgICAgICAgICAg
ICAgICAgICAgKGJfaW5mby0+dmlkZW9fbWVta2IvMi8xMDI0KSksICItZ2xvYmFsIiwKLSAgICAg
ICAgICAgICAgICAgICAgR0NTUFJJTlRGKCJxeGwtdmdhLnJhbV9zaXplX21iPSVsdSIsCisgICAg
ICAgICAgICAgICAgICAgIEdDU1BSSU5URigicXhsLXZnYS5yYW1fc2l6ZV9tYj0lIlBSSXU2NCwK
ICAgICAgICAgICAgICAgICAgICAgKGJfaW5mby0+dmlkZW9fbWVta2IvMi8xMDI0KSksIE5VTEwp
OwogICAgICAgICAgICAgfQogICAgICAgICAgICAgYnJlYWs7Ci0tIAoxLjcuOS4xCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:01:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8Tu5-0001u1-E0; Thu, 21 Feb 2013 11:01: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 1U8Tu3-0001tt-R7
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:01:28 +0000
Received: from [85.158.138.51:52082] by server-9.bemta-3.messagelabs.com id
	BC/C7-09484-28EF5215; Thu, 21 Feb 2013 11:01:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361444481!22184336!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1713 invoked from network); 21 Feb 2013 11:01:21 -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; 21 Feb 2013 11:01:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Ttv-0006ZN-Oq; Thu, 21 Feb 2013 11:01:19 +0000
Date: Thu, 21 Feb 2013 11:01:19 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221110119.GE24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <20130220145823.GA18129@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

(Cc'ing the vmx maintainers)

At 15:58 +0100 on 20 Feb (1361375903), Olaf Hering wrote:
> while doing "while xm migrate --live domU localhost;do sleep 1;done" I
> just got the crash shown below. And it can be reproduced.
> 
> The guest has 2 vcpus and 512mb, it runs pvops 3.7.9

Anything interesting printed before the crash?  My best guess by code
inspection is that nvmx->launched_list never got initialized, because of
some failure in vcpu init.

Also, if you have the xen-syms for this image, can you extract a
file/line-number for the crashing %rip (ffff82c4c01dd197)?
I'd expect it to be vvmx.c:150 or thereabouts.

And thirdly, can you try the attached patch?

Cheers

Tim.

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 4f3f94d..951c310 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -147,10 +147,13 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx = NULL;
     }
 
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+    if ( nvmx->launched_list->next )
     {
-        list_del(&item->node);
-        xfree(item);
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
     }
 
     if ( v->arch.hvm_vmx.vmread_bitmap )

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--J/dobhs11T7y2rNN--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:01:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8Tu5-0001u1-E0; Thu, 21 Feb 2013 11:01: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 1U8Tu3-0001tt-R7
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:01:28 +0000
Received: from [85.158.138.51:52082] by server-9.bemta-3.messagelabs.com id
	BC/C7-09484-28EF5215; Thu, 21 Feb 2013 11:01:22 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361444481!22184336!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1713 invoked from network); 21 Feb 2013 11:01:21 -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; 21 Feb 2013 11:01:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Ttv-0006ZN-Oq; Thu, 21 Feb 2013 11:01:19 +0000
Date: Thu, 21 Feb 2013 11:01:19 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221110119.GE24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <20130220145823.GA18129@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

(Cc'ing the vmx maintainers)

At 15:58 +0100 on 20 Feb (1361375903), Olaf Hering wrote:
> while doing "while xm migrate --live domU localhost;do sleep 1;done" I
> just got the crash shown below. And it can be reproduced.
> 
> The guest has 2 vcpus and 512mb, it runs pvops 3.7.9

Anything interesting printed before the crash?  My best guess by code
inspection is that nvmx->launched_list never got initialized, because of
some failure in vcpu init.

Also, if you have the xen-syms for this image, can you extract a
file/line-number for the crashing %rip (ffff82c4c01dd197)?
I'd expect it to be vvmx.c:150 or thereabouts.

And thirdly, can you try the attached patch?

Cheers

Tim.

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 4f3f94d..951c310 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -147,10 +147,13 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx = NULL;
     }
 
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+    if ( nvmx->launched_list->next )
     {
-        list_del(&item->node);
-        xfree(item);
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
     }
 
     if ( v->arch.hvm_vmx.vmread_bitmap )

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--J/dobhs11T7y2rNN--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:03:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8TvK-00022e-Tn; Thu, 21 Feb 2013 11:02: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 1U8TvJ-00022R-AA
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:02:45 +0000
Received: from [85.158.137.99:64866] by server-4.bemta-3.messagelabs.com id
	CF/4A-17521-4DEF5215; Thu, 21 Feb 2013 11:02:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361444562!15033495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 643 invoked from network); 21 Feb 2013 11:02:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:02:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:02:42 +0000
Message-Id: <51260D1D02000078000BFD33@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:03:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
	<20130221104943.GA22260@aepfle.de>
In-Reply-To: <20130221104943.GA22260@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 21.02.13 at 11:49, Olaf Hering <olaf@aepfle.de> wrote:
> On Wed, Feb 20, Olaf Hering wrote:
> 
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
>> (XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40
> 
> For some reason nestedhvm_vcpu_destroy is not in the backtrace.

Tail call optimization?

> And its
> not clear why nestedhvm_vcpu_destroy calls into nvmx_vcpu_destroy
> anyway. nestedhvm is not in the config file.

nHVM can be turned on and off on a domain, so cleanup is needed
unconditionally. This was also the reason why 26507:4f53ddbee940
had to revert 26503:69398345c10e.

Is this perhaps dying on the uninitialized list head? If so, I'm about
to submit a patch that ought to deal with that (albeit its original
purpose is another one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:03:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8TvK-00022e-Tn; Thu, 21 Feb 2013 11:02: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 1U8TvJ-00022R-AA
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:02:45 +0000
Received: from [85.158.137.99:64866] by server-4.bemta-3.messagelabs.com id
	CF/4A-17521-4DEF5215; Thu, 21 Feb 2013 11:02:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361444562!15033495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 643 invoked from network); 21 Feb 2013 11:02:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:02:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:02:42 +0000
Message-Id: <51260D1D02000078000BFD33@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:03:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
	<20130221104943.GA22260@aepfle.de>
In-Reply-To: <20130221104943.GA22260@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 21.02.13 at 11:49, Olaf Hering <olaf@aepfle.de> wrote:
> On Wed, Feb 20, Olaf Hering wrote:
> 
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
>> (XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40
> 
> For some reason nestedhvm_vcpu_destroy is not in the backtrace.

Tail call optimization?

> And its
> not clear why nestedhvm_vcpu_destroy calls into nvmx_vcpu_destroy
> anyway. nestedhvm is not in the config file.

nHVM can be turned on and off on a domain, so cleanup is needed
unconditionally. This was also the reason why 26507:4f53ddbee940
had to revert 26503:69398345c10e.

Is this perhaps dying on the uninitialized list head? If so, I'm about
to submit a patch that ought to deal with that (albeit its original
purpose is another one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:09:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U15-0002Ks-O4; Thu, 21 Feb 2013 11:08:43 +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 1U8U13-0002Kn-K5
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:08:41 +0000
Received: from [85.158.139.211:38994] by server-12.bemta-5.messagelabs.com id
	E3/10-20195-63006215; Thu, 21 Feb 2013 11:08:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361444915!18574160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11157 invoked from network); 21 Feb 2013 11:08:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:08:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8U0w-0006ad-P2; Thu, 21 Feb 2013 11:08:34 +0000
Date: Thu, 21 Feb 2013 11:08:34 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221110834.GF24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
	<20130221104943.GA22260@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221104943.GA22260@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 11:49 +0100 on 21 Feb (1361447383), Olaf Hering wrote:
> On Wed, Feb 20, Olaf Hering wrote:
> 
> > (XEN) Xen call trace:
> > (XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
> > (XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40
> 
> For some reason nestedhvm_vcpu_destroy is not in the backtrace.

On non-debug builds, nestedhvm_vcpu_destroy gets compiled using a tail
call (i.e. it jumps to the arch-specific function and lets that return
directly to the caller).

> And its not clear why nestedhvm_vcpu_destroy calls into
> nvmx_vcpu_destroy anyway. nestedhvm is not in the config file.

Intriguing.  I wonder what sets the hvm-param then.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:09:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U15-0002Ks-O4; Thu, 21 Feb 2013 11:08:43 +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 1U8U13-0002Kn-K5
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:08:41 +0000
Received: from [85.158.139.211:38994] by server-12.bemta-5.messagelabs.com id
	E3/10-20195-63006215; Thu, 21 Feb 2013 11:08:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361444915!18574160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11157 invoked from network); 21 Feb 2013 11:08:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:08:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8U0w-0006ad-P2; Thu, 21 Feb 2013 11:08:34 +0000
Date: Thu, 21 Feb 2013 11:08:34 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221110834.GF24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
	<20130221104943.GA22260@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221104943.GA22260@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 11:49 +0100 on 21 Feb (1361447383), Olaf Hering wrote:
> On Wed, Feb 20, Olaf Hering wrote:
> 
> > (XEN) Xen call trace:
> > (XEN)    [<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150
> > (XEN)    [<ffff82c4c01b5ce9>] hvm_vcpu_destroy+0x9/0x40
> 
> For some reason nestedhvm_vcpu_destroy is not in the backtrace.

On non-debug builds, nestedhvm_vcpu_destroy gets compiled using a tail
call (i.e. it jumps to the arch-specific function and lets that return
directly to the caller).

> And its not clear why nestedhvm_vcpu_destroy calls into
> nvmx_vcpu_destroy anyway. nestedhvm is not in the config file.

Intriguing.  I wonder what sets the hvm-param then.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:12:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U4f-0002WQ-DM; Thu, 21 Feb 2013 11:12:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8U4e-0002WJ-K2
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:12:24 +0000
Received: from [85.158.137.99:62314] by server-11.bemta-3.messagelabs.com id
	18/0A-10249-71106215; Thu, 21 Feb 2013 11:12:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361445125!17357982!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27521 invoked from network); 21 Feb 2013 11:12:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:12:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="8699387"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 11:12:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 06:12:04 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8U4J-0003Ah-W5;
	Thu, 21 Feb 2013 11:12:03 +0000
Message-ID: <51260103.9060509@citrix.com>
Date: Thu, 21 Feb 2013 11:12:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
	<1361441667.26546.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361441667.26546.50.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] tools/ocaml: libxc bindings: Fix
	stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 10:14, Ian Campbell wrote:
> On Wed, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
>> There are two problems with this function:
>>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>>     compete for use of the static ring[] buffer.
>>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>>     more of its console ring.
>>
>> Rewrite the function using the new xc_consoleringsize() and
>> xc_readconsolering_buffer() functions to efficiently grab the entire console
>> ring.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 6b8c513cff4f -r a73d0c5a5b24 tools/ocaml/libs/xc/xenctrl_stubs.c
>> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
>> @@ -523,27 +523,61 @@ CAMLprim value stub_xc_evtchn_reset(valu
>>  	CAMLreturn(Val_unit);
>>  }
>>  
>> -
>> -#define RING_SIZE 32768
>> -static char ring[RING_SIZE];
>> -
>> +/* Maximum size of console ring we are prepared to read, 16MB */
>> +#define MAX_CONSOLE_RING_SIZE (1U << 24)
> A bit arbitrary, why not just let it handle whatever the hypervisor
> throws at it. If there is to be a limit it probably belongs on the
> hypervisor side, but in the meantime someone who passes consring=1G can
> keep all the pieces ;-)
>
>>  CAMLprim value stub_xc_readconsolering(value xch)
>>  {
>> -	unsigned int size = RING_SIZE - 1;
>> -	char *ring_ptr = ring;
>> -	int retval;
>> +	uint64_t conring_size;
>> +	DECLARE_HYPERCALL_BUFFER(char, ring);
>> +	unsigned int nr_chars;
>> +	int r;
>>  
>>  	CAMLparam1(xch);
>> +	CAMLlocal1(conring);
>> +
>> +	r = xc_consoleringsize(_H(xch), &conring_size);
> static int consoleringsize and only call this once the first time?

One of the point of this patch was to remove the static buffer for
thread safety reasons.  Having said that, even if you do race on this
static variable, it should be filled in with the same value, so is
probably safe?

>
>> +
>> +	if ( r )
>> +	{
>> +		failwith_xc(_H(xch));
>> +		CAMLreturn(Val_unit);
>> +	}
>> +
>> +	/* Round conring_size up to the next page, for NULL terminator and
>> +	   slop from a race with printk() in the hypervisor. */
>> +	conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
>> +	nr_chars = conring_size-1;
>> +
>> +	if ( conring_size > MAX_CONSOLE_RING_SIZE )
>> +	{
>> +		caml_failwith("Console ring too large");
>> +		CAMLreturn(Val_unit);
>> +	}
>> +
>> +	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
>> +
>> +	if ( ! ring )
>> +	{
>> +		failwith_xc(_H(xch));
>> +		CAMLreturn(Val_unit);
>> +	}
>>  
>>  	caml_enter_blocking_section();
>> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
>> +	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
>> +				      &nr_chars, 0, 0, NULL);
>>  	caml_leave_blocking_section();
>>  
>> -	if (retval)
>> +	if ( r )
>> +	{
>>  		failwith_xc(_H(xch));
> Doesn't this (due to caml_raise...) end up exiting synchronously via a
> longjmp back to the runtime? i.e. it leaks the buffer which is only
> free'd after.
>
> It's a good idea to cc xen-api@ with ocaml changes, for this sort of
> reason...

I will double check that.  If so, then I have some memory leaks to fix
up in other bits of Ocaml/C bindings, which I was using as an example
here...

I will cc xen-api@ for the next submission of this series.

>
>> +		xc_hypercall_buffer_free(_H(xch), ring);
>> +		CAMLreturn(Val_unit);
> I think CAMLnoreturn here.

Ok.

~Andrew

>
>> +	}
>>  
>> -	ring[size] = '\0';
>> -	CAMLreturn(caml_copy_string(ring));
>> +	ring[nr_chars] = '\0';
>> +	conring = caml_copy_string(ring);
>> +	xc_hypercall_buffer_free(_H(xch), ring);
>> +	CAMLreturn(conring);
>>  }
>>  
>>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:12:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U4f-0002WQ-DM; Thu, 21 Feb 2013 11:12:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8U4e-0002WJ-K2
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:12:24 +0000
Received: from [85.158.137.99:62314] by server-11.bemta-3.messagelabs.com id
	18/0A-10249-71106215; Thu, 21 Feb 2013 11:12:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361445125!17357982!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27521 invoked from network); 21 Feb 2013 11:12:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:12:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="8699387"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 11:12:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 06:12:04 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8U4J-0003Ah-W5;
	Thu, 21 Feb 2013 11:12:03 +0000
Message-ID: <51260103.9060509@citrix.com>
Date: Thu, 21 Feb 2013 11:12:03 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<a73d0c5a5b24cdc1cfe7.1361383534@andrewcoop.uk.xensource.com>
	<1361441667.26546.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361441667.26546.50.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 4 of 5] tools/ocaml: libxc bindings: Fix
	stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 10:14, Ian Campbell wrote:
> On Wed, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
>> There are two problems with this function:
>>   * The caml_{enter,leave}_blocking_section() calls mean that two threads can
>>     compete for use of the static ring[] buffer.
>>   * It fails to retrieve the entire buffer if the hypervisor has used 32K or
>>     more of its console ring.
>>
>> Rewrite the function using the new xc_consoleringsize() and
>> xc_readconsolering_buffer() functions to efficiently grab the entire console
>> ring.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 6b8c513cff4f -r a73d0c5a5b24 tools/ocaml/libs/xc/xenctrl_stubs.c
>> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
>> @@ -523,27 +523,61 @@ CAMLprim value stub_xc_evtchn_reset(valu
>>  	CAMLreturn(Val_unit);
>>  }
>>  
>> -
>> -#define RING_SIZE 32768
>> -static char ring[RING_SIZE];
>> -
>> +/* Maximum size of console ring we are prepared to read, 16MB */
>> +#define MAX_CONSOLE_RING_SIZE (1U << 24)
> A bit arbitrary, why not just let it handle whatever the hypervisor
> throws at it. If there is to be a limit it probably belongs on the
> hypervisor side, but in the meantime someone who passes consring=1G can
> keep all the pieces ;-)
>
>>  CAMLprim value stub_xc_readconsolering(value xch)
>>  {
>> -	unsigned int size = RING_SIZE - 1;
>> -	char *ring_ptr = ring;
>> -	int retval;
>> +	uint64_t conring_size;
>> +	DECLARE_HYPERCALL_BUFFER(char, ring);
>> +	unsigned int nr_chars;
>> +	int r;
>>  
>>  	CAMLparam1(xch);
>> +	CAMLlocal1(conring);
>> +
>> +	r = xc_consoleringsize(_H(xch), &conring_size);
> static int consoleringsize and only call this once the first time?

One of the point of this patch was to remove the static buffer for
thread safety reasons.  Having said that, even if you do race on this
static variable, it should be filled in with the same value, so is
probably safe?

>
>> +
>> +	if ( r )
>> +	{
>> +		failwith_xc(_H(xch));
>> +		CAMLreturn(Val_unit);
>> +	}
>> +
>> +	/* Round conring_size up to the next page, for NULL terminator and
>> +	   slop from a race with printk() in the hypervisor. */
>> +	conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
>> +	nr_chars = conring_size-1;
>> +
>> +	if ( conring_size > MAX_CONSOLE_RING_SIZE )
>> +	{
>> +		caml_failwith("Console ring too large");
>> +		CAMLreturn(Val_unit);
>> +	}
>> +
>> +	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
>> +
>> +	if ( ! ring )
>> +	{
>> +		failwith_xc(_H(xch));
>> +		CAMLreturn(Val_unit);
>> +	}
>>  
>>  	caml_enter_blocking_section();
>> -	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
>> +	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
>> +				      &nr_chars, 0, 0, NULL);
>>  	caml_leave_blocking_section();
>>  
>> -	if (retval)
>> +	if ( r )
>> +	{
>>  		failwith_xc(_H(xch));
> Doesn't this (due to caml_raise...) end up exiting synchronously via a
> longjmp back to the runtime? i.e. it leaks the buffer which is only
> free'd after.
>
> It's a good idea to cc xen-api@ with ocaml changes, for this sort of
> reason...

I will double check that.  If so, then I have some memory leaks to fix
up in other bits of Ocaml/C bindings, which I was using as an example
here...

I will cc xen-api@ for the next submission of this series.

>
>> +		xc_hypercall_buffer_free(_H(xch), ring);
>> +		CAMLreturn(Val_unit);
> I think CAMLnoreturn here.

Ok.

~Andrew

>
>> +	}
>>  
>> -	ring[size] = '\0';
>> -	CAMLreturn(caml_copy_string(ring));
>> +	ring[nr_chars] = '\0';
>> +	conring = caml_copy_string(ring);
>> +	xc_hypercall_buffer_free(_H(xch), ring);
>> +	CAMLreturn(conring);
>>  }
>>  
>>  CAMLprim value stub_xc_send_debug_keys(value xch, value keys)
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:13:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U4y-0002YE-RZ; Thu, 21 Feb 2013 11:12:44 +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 1U8U4x-0002Y4-HG
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:12:43 +0000
Received: from [193.109.254.147:13508] by server-9.bemta-14.messagelabs.com id
	11/74-30867-A2106215; Thu, 21 Feb 2013 11:12:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361445004!6085094!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28927 invoked from network); 21 Feb 2013 11:10:05 -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; 21 Feb 2013 11:10:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8U2K-0006bB-I8; Thu, 21 Feb 2013 11:10:00 +0000
Date: Thu, 21 Feb 2013 11:10:00 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221111000.GG24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
	<20130221110119.GE24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="eAbsdosE1cNLO4uF"
Content-Disposition: inline
In-Reply-To: <20130221110119.GE24051@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 11:01 +0000 on 21 Feb (1361444479), Tim Deegan wrote:
> (Cc'ing the vmx maintainers)
> 
> At 15:58 +0100 on 20 Feb (1361375903), Olaf Hering wrote:
> > while doing "while xm migrate --live domU localhost;do sleep 1;done" I
> > just got the crash shown below. And it can be reproduced.
> > 
> > The guest has 2 vcpus and 512mb, it runs pvops 3.7.9
> 
> Anything interesting printed before the crash?  My best guess by code
> inspection is that nvmx->launched_list never got initialized, because of
> some failure in vcpu init.
> 
> Also, if you have the xen-syms for this image, can you extract a
> file/line-number for the crashing %rip (ffff82c4c01dd197)?
> I'd expect it to be vvmx.c:150 or thereabouts.
> 
> And thirdly, can you try the attached patch?

Oops - not sure what I tested before , but that one doesn't even
compile!  Try this instead.

Tim.

--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 4f3f94d..5d00ff7 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -147,10 +147,13 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx = NULL;
     }
 
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+    if ( nvmx->launched_list.next )
     {
-        list_del(&item->node);
-        xfree(item);
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
     }
 
     if ( v->arch.hvm_vmx.vmread_bitmap )

--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--eAbsdosE1cNLO4uF--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:13:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U4y-0002YE-RZ; Thu, 21 Feb 2013 11:12:44 +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 1U8U4x-0002Y4-HG
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:12:43 +0000
Received: from [193.109.254.147:13508] by server-9.bemta-14.messagelabs.com id
	11/74-30867-A2106215; Thu, 21 Feb 2013 11:12:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361445004!6085094!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28927 invoked from network); 21 Feb 2013 11:10:05 -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; 21 Feb 2013 11:10:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8U2K-0006bB-I8; Thu, 21 Feb 2013 11:10:00 +0000
Date: Thu, 21 Feb 2013 11:10:00 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221111000.GG24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
	<20130221110119.GE24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="eAbsdosE1cNLO4uF"
Content-Disposition: inline
In-Reply-To: <20130221110119.GE24051@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

At 11:01 +0000 on 21 Feb (1361444479), Tim Deegan wrote:
> (Cc'ing the vmx maintainers)
> 
> At 15:58 +0100 on 20 Feb (1361375903), Olaf Hering wrote:
> > while doing "while xm migrate --live domU localhost;do sleep 1;done" I
> > just got the crash shown below. And it can be reproduced.
> > 
> > The guest has 2 vcpus and 512mb, it runs pvops 3.7.9
> 
> Anything interesting printed before the crash?  My best guess by code
> inspection is that nvmx->launched_list never got initialized, because of
> some failure in vcpu init.
> 
> Also, if you have the xen-syms for this image, can you extract a
> file/line-number for the crashing %rip (ffff82c4c01dd197)?
> I'd expect it to be vvmx.c:150 or thereabouts.
> 
> And thirdly, can you try the attached patch?

Oops - not sure what I tested before , but that one doesn't even
compile!  Try this instead.

Tim.

--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=x

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 4f3f94d..5d00ff7 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -147,10 +147,13 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx = NULL;
     }
 
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+    if ( nvmx->launched_list.next )
     {
-        list_del(&item->node);
-        xfree(item);
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
     }
 
     if ( v->arch.hvm_vmx.vmread_bitmap )

--eAbsdosE1cNLO4uF
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--eAbsdosE1cNLO4uF--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:16:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U81-0002nn-NT; Thu, 21 Feb 2013 11:15:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8U7z-0002nh-Ov
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:15:51 +0000
Received: from [193.109.254.147:39406] by server-8.bemta-14.messagelabs.com id
	BB/35-17325-6E106215; Thu, 21 Feb 2013 11:15:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361444828!8481807!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24209 invoked from network); 21 Feb 2013 11:07:09 -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;
	21 Feb 2013 11:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="8698611"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 11:07:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 06:07:07 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8TzX-00035J-1i;
	Thu, 21 Feb 2013 11:07:07 +0000
Message-ID: <5125FFDA.2070008@citrix.com>
Date: Thu, 21 Feb 2013 11:07:06 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
	<1361440867.26546.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361440867.26546.44.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] tools/libxc: Implement of
	xc_readconsolering_buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 10:01, Ian Campbell wrote:
> On Wed, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
>> Functions identically to xc_readconsolering(), but uses a user-provided
>> xc_hypercall_buffer_t to save using a bounce buffer.
> Can we now trivially reimplement xc_readconsolering in terms of this
> function?
>
> Should just be a case of replacing all the code between bounce_pre and
> bounce_post with a call
> 	xc_readconsolering_buffer(xch, HYPERCALL_BUFFER_AS_ARG(buffer),
>                                   pnr_chars, clear, incremental, pindex);
> ?

Ok

>
> We should probably also deprecate the old one and at least have a vague
> idea that we might eventually switch all the callers over (you don't
> need to here though, unless you are super keen).
>
> Ian.
>

Depending on the quantity of callers, I may or may not due to time.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:16:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8U81-0002nn-NT; Thu, 21 Feb 2013 11:15:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8U7z-0002nh-Ov
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:15:51 +0000
Received: from [193.109.254.147:39406] by server-8.bemta-14.messagelabs.com id
	BB/35-17325-6E106215; Thu, 21 Feb 2013 11:15:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361444828!8481807!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24209 invoked from network); 21 Feb 2013 11:07:09 -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;
	21 Feb 2013 11:07:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="8698611"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 11:07:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 06:07:07 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8TzX-00035J-1i;
	Thu, 21 Feb 2013 11:07:07 +0000
Message-ID: <5125FFDA.2070008@citrix.com>
Date: Thu, 21 Feb 2013 11:07:06 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <patchbomb.1361383530@andrewcoop.uk.xensource.com>
	<6b8c513cff4f95b4a39f.1361383533@andrewcoop.uk.xensource.com>
	<1361440867.26546.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361440867.26546.44.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 5] tools/libxc: Implement of
	xc_readconsolering_buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 10:01, Ian Campbell wrote:
> On Wed, 2013-02-20 at 18:05 +0000, Andrew Cooper wrote:
>> Functions identically to xc_readconsolering(), but uses a user-provided
>> xc_hypercall_buffer_t to save using a bounce buffer.
> Can we now trivially reimplement xc_readconsolering in terms of this
> function?
>
> Should just be a case of replacing all the code between bounce_pre and
> bounce_post with a call
> 	xc_readconsolering_buffer(xch, HYPERCALL_BUFFER_AS_ARG(buffer),
>                                   pnr_chars, clear, incremental, pindex);
> ?

Ok

>
> We should probably also deprecate the old one and at least have a vague
> idea that we might eventually switch all the callers over (you don't
> need to here though, unless you are super keen).
>
> Ian.
>

Depending on the quantity of callers, I may or may not due to time.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:17:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:17: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 1U8U9G-0002tP-8E; Thu, 21 Feb 2013 11:17: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 1U8U9E-0002tC-Oz
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:17:08 +0000
Received: from [85.158.138.51:35739] by server-13.bemta-3.messagelabs.com id
	23/59-20653-52206215; Thu, 21 Feb 2013 11:16:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361445410!26776955!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8826 invoked from network); 21 Feb 2013 11:16:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="1726455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:16: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.297.1; Thu, 21 Feb 2013 11:16:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8U8v-0001FC-Rk; Thu, 21 Feb 2013 11:16:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8U8v-0001U4-Iw;
	Thu, 21 Feb 2013 11:16:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.545.470486.189832@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 11:16:49 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("Moving xen*.hg to git"):
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped

This is now done.  Please don't try any longer to push to the hg
trees.

We'll let you know again when the git trees are open for business.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:17:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:17: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 1U8U9G-0002tP-8E; Thu, 21 Feb 2013 11:17: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 1U8U9E-0002tC-Oz
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:17:08 +0000
Received: from [85.158.138.51:35739] by server-13.bemta-3.messagelabs.com id
	23/59-20653-52206215; Thu, 21 Feb 2013 11:16:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361445410!26776955!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8826 invoked from network); 21 Feb 2013 11:16:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:16:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,708,1355097600"; 
   d="scan'208";a="1726455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:16: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.297.1; Thu, 21 Feb 2013 11:16:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8U8v-0001FC-Rk; Thu, 21 Feb 2013 11:16:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8U8v-0001U4-Iw;
	Thu, 21 Feb 2013 11:16:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.545.470486.189832@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 11:16:49 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("Moving xen*.hg to git"):
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped

This is now done.  Please don't try any longer to push to the hg
trees.

We'll let you know again when the git trees are open for business.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:25:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8UHI-0003BZ-81; Thu, 21 Feb 2013 11:25:28 +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 1U8UHG-0003BU-Sw
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:25:27 +0000
Received: from [85.158.139.83:60424] by server-11.bemta-5.messagelabs.com id
	20/9E-19159-62406215; Thu, 21 Feb 2013 11:25:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361445924!16999703!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27606 invoked from network); 21 Feb 2013 11:25:25 -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; 21 Feb 2013 11:25:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:25:24 +0000
Message-Id: <5126126F02000078000BFD83@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:26:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part54642E4F.2__="
Cc: Tim Deegan <tim@xen.org>, Olaf Hering <olaf@aepfle.de>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>
Subject: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after failure to
 set up all vCPU-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>
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.

--=__Part54642E4F.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise we may leak memory when setting up nHVM fails half way.

This implies that the individual destroy functions will have to remain
capable (in the VMX case they first need to be made so, following
26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
that the corresponding init function was never run on.

Once at it, also clean up some inefficiencies in the corresponding
parameter validation code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
                     rc =3D -EPERM;
                     break;
                 }
+                if ( !a.value )
+                    break;
                 if ( a.value > 1 )
                     rc =3D -EINVAL;
-                if ( !is_hvm_domain(d) )
-                    rc =3D -EINVAL;
                 /* Remove the check below once we have
                  * shadow-on-shadow.
                  */
-                if ( cpu_has_svm && !paging_mode_hap(d) && a.value )
+                if ( cpu_has_svm && !paging_mode_hap(d) )
                     rc =3D -EINVAL;
                 /* Set up NHVM state for any vcpus that are already up */
                 if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
+                {
                     for_each_vcpu(d, v)
                         if ( rc =3D=3D 0 )
                             rc =3D nestedhvm_vcpu_initialise(v);
+                    if ( rc )
+                        for_each_vcpu(d, v)
+                            nestedhvm_vcpu_destroy(v);
+                }
                 break;
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc =3D -EINVAL;
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu *v
 void
 nestedhvm_vcpu_destroy(struct vcpu *v)
 {
-    if ( nestedhvm_enabled(v->domain) && hvm_funcs.nhvm_vcpu_destroy )
+    if ( hvm_funcs.nhvm_vcpu_destroy )
         hvm_funcs.nhvm_vcpu_destroy(v);
 }
=20
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     if ( !nvcpu->nv_n2vmcx )
     {
         gdprintk(XENLOG_ERR, "nest: allocation for shadow vmcs failed\n");=

-	goto out;
+	return -ENOMEM;
     }
=20
     /* non-root VMREAD/VMWRITE bitmap. */
@@ -75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmread_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmread bitmap =
failed\n");
-            goto out1;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmread_bitmap =3D vmread_bitmap;
=20
@@ -83,7 +83,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmwrite_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap =
failed\n");
-            goto out2;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;
=20
@@ -118,12 +118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     nvmx->msrbitmap =3D NULL;
     INIT_LIST_HEAD(&nvmx->launched_list);
     return 0;
-out2:
-    free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
-out1:
-    free_xenheap_page(nvcpu->nv_n2vmcx);
-out:
-    return -ENOMEM;
 }
 =20
 void nvmx_vcpu_destroy(struct vcpu *v)
@@ -147,16 +141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx =3D NULL;
     }
=20
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
-    {
-        list_del(&item->node);
-        xfree(item);
-    }
+    /* Must also cope with nvmx_vcpu_initialise() not having got called. =
*/
+    if ( nvmx->launched_list.next )
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
=20
     if ( v->arch.hvm_vmx.vmread_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
+        v->arch.hvm_vmx.vmread_bitmap =3D NULL;
+    }
     if ( v->arch.hvm_vmx.vmwrite_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmwrite_bitmap);
+        v->arch.hvm_vmx.vmwrite_bitmap =3D NULL;
+    }
 }
 =20
 void nvmx_domain_relinquish_resources(struct domain *d)



--=__Part54642E4F.2__=
Content-Type: text/plain; name="x86-nhvm-enable-failure.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-nhvm-enable-failure.patch"

x86/nhvm: properly clean up after failure to set up all vCPU-s=0A=0AOtherwi=
se we may leak memory when setting up nHVM fails half way.=0A=0AThis =
implies that the individual destroy functions will have to remain=0Acapable=
 (in the VMX case they first need to be made so, following=0A26486:7648ef65=
7fe7 and 26489:83a3fa9c8434) of being called for a vCPU=0Athat the =
corresponding init function was never run on.=0A=0AOnce at it, also clean =
up some inefficiencies in the corresponding=0Aparameter validation =
code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av2: nVMX =
fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.=0A=0A--- =
a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c=0A@@ -3916,20 =
+3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE=0A                    =
 rc =3D -EPERM;=0A                     break;=0A                 }=0A+     =
           if ( !a.value )=0A+                    break;=0A                =
 if ( a.value > 1 )=0A                     rc =3D -EINVAL;=0A-             =
   if ( !is_hvm_domain(d) )=0A-                    rc =3D -EINVAL;=0A      =
           /* Remove the check below once we have=0A                  * =
shadow-on-shadow.=0A                  */=0A-                if ( cpu_has_sv=
m && !paging_mode_hap(d) && a.value )=0A+                if ( cpu_has_svm =
&& !paging_mode_hap(d) )=0A                     rc =3D -EINVAL;=0A         =
        /* Set up NHVM state for any vcpus that are already up */=0A       =
          if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )=0A+       =
         {=0A                     for_each_vcpu(d, v)=0A                   =
      if ( rc =3D=3D 0 )=0A                             rc =3D nestedhvm_vc=
pu_initialise(v);=0A+                    if ( rc )=0A+                     =
   for_each_vcpu(d, v)=0A+                            nestedhvm_vcpu_destro=
y(v);=0A+                }=0A                 break;=0A             case =
HVM_PARAM_BUFIOREQ_EVTCHN:=0A                 rc =3D -EINVAL;=0A--- =
a/xen/arch/x86/hvm/nestedhvm.c=0A+++ b/xen/arch/x86/hvm/nestedhvm.c=0A@@ =
-87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu *v=0A void=0A =
nestedhvm_vcpu_destroy(struct vcpu *v)=0A {=0A-    if ( nestedhvm_enabled(v=
->domain) && hvm_funcs.nhvm_vcpu_destroy )=0A+    if ( hvm_funcs.nhvm_vcpu_=
destroy )=0A         hvm_funcs.nhvm_vcpu_destroy(v);=0A }=0A =0A--- =
a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ =
-62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     if ( =
!nvcpu->nv_n2vmcx )=0A     {=0A         gdprintk(XENLOG_ERR, "nest: =
allocation for shadow vmcs failed\n");=0A-	goto out;=0A+	return =
-ENOMEM;=0A     }=0A =0A     /* non-root VMREAD/VMWRITE bitmap. */=0A@@ =
-75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A         if ( =
!vmread_bitmap )=0A         {=0A             gdprintk(XENLOG_ERR, "nest: =
allocation for vmread bitmap failed\n");=0A-            goto out1;=0A+     =
       return -ENOMEM;=0A         }=0A         v->arch.hvm_vmx.vmread_bitma=
p =3D vmread_bitmap;=0A =0A@@ -83,7 +83,7 @@ int nvmx_vcpu_initialise(struc=
t vcpu *v)=0A         if ( !vmwrite_bitmap )=0A         {=0A             =
gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap failed\n");=0A-  =
          goto out2;=0A+            return -ENOMEM;=0A         }=0A        =
 v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;=0A =0A@@ -118,12 =
+118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     nvmx->msrbitmap =
=3D NULL;=0A     INIT_LIST_HEAD(&nvmx->launched_list);=0A     return =
0;=0A-out2:=0A-    free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);=0A-out=
1:=0A-    free_xenheap_page(nvcpu->nv_n2vmcx);=0A-out:=0A-    return =
-ENOMEM;=0A }=0A  =0A void nvmx_vcpu_destroy(struct vcpu *v)=0A@@ -147,16 =
+141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)=0A         nvcpu->nv_n2vm=
cx =3D NULL;=0A     }=0A =0A-    list_for_each_entry_safe(item, n, =
&nvmx->launched_list, node)=0A-    {=0A-        list_del(&item->node);=0A- =
       xfree(item);=0A-    }=0A+    /* Must also cope with nvmx_vcpu_initia=
lise() not having got called. */=0A+    if ( nvmx->launched_list.next =
)=0A+        list_for_each_entry_safe(item, n, &nvmx->launched_list, =
node)=0A+        {=0A+            list_del(&item->node);=0A+            =
xfree(item);=0A+        }=0A =0A     if ( v->arch.hvm_vmx.vmread_bitmap =
)=0A+    {=0A         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);=0A+=
        v->arch.hvm_vmx.vmread_bitmap =3D NULL;=0A+    }=0A     if ( =
v->arch.hvm_vmx.vmwrite_bitmap )=0A+    {=0A         free_domheap_page(v->a=
rch.hvm_vmx.vmwrite_bitmap);=0A+        v->arch.hvm_vmx.vmwrite_bitmap =3D =
NULL;=0A+    }=0A }=0A  =0A void nvmx_domain_relinquish_resources(struct =
domain *d)=0A
--=__Part54642E4F.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part54642E4F.2__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:25:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8UHI-0003BZ-81; Thu, 21 Feb 2013 11:25:28 +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 1U8UHG-0003BU-Sw
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:25:27 +0000
Received: from [85.158.139.83:60424] by server-11.bemta-5.messagelabs.com id
	20/9E-19159-62406215; Thu, 21 Feb 2013 11:25:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361445924!16999703!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27606 invoked from network); 21 Feb 2013 11:25:25 -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; 21 Feb 2013 11:25:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:25:24 +0000
Message-Id: <5126126F02000078000BFD83@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:26:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part54642E4F.2__="
Cc: Tim Deegan <tim@xen.org>, Olaf Hering <olaf@aepfle.de>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>
Subject: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after failure to
 set up all vCPU-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>
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.

--=__Part54642E4F.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise we may leak memory when setting up nHVM fails half way.

This implies that the individual destroy functions will have to remain
capable (in the VMX case they first need to be made so, following
26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
that the corresponding init function was never run on.

Once at it, also clean up some inefficiencies in the corresponding
parameter validation code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
                     rc =3D -EPERM;
                     break;
                 }
+                if ( !a.value )
+                    break;
                 if ( a.value > 1 )
                     rc =3D -EINVAL;
-                if ( !is_hvm_domain(d) )
-                    rc =3D -EINVAL;
                 /* Remove the check below once we have
                  * shadow-on-shadow.
                  */
-                if ( cpu_has_svm && !paging_mode_hap(d) && a.value )
+                if ( cpu_has_svm && !paging_mode_hap(d) )
                     rc =3D -EINVAL;
                 /* Set up NHVM state for any vcpus that are already up */
                 if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
+                {
                     for_each_vcpu(d, v)
                         if ( rc =3D=3D 0 )
                             rc =3D nestedhvm_vcpu_initialise(v);
+                    if ( rc )
+                        for_each_vcpu(d, v)
+                            nestedhvm_vcpu_destroy(v);
+                }
                 break;
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc =3D -EINVAL;
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu *v
 void
 nestedhvm_vcpu_destroy(struct vcpu *v)
 {
-    if ( nestedhvm_enabled(v->domain) && hvm_funcs.nhvm_vcpu_destroy )
+    if ( hvm_funcs.nhvm_vcpu_destroy )
         hvm_funcs.nhvm_vcpu_destroy(v);
 }
=20
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     if ( !nvcpu->nv_n2vmcx )
     {
         gdprintk(XENLOG_ERR, "nest: allocation for shadow vmcs failed\n");=

-	goto out;
+	return -ENOMEM;
     }
=20
     /* non-root VMREAD/VMWRITE bitmap. */
@@ -75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmread_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmread bitmap =
failed\n");
-            goto out1;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmread_bitmap =3D vmread_bitmap;
=20
@@ -83,7 +83,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmwrite_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap =
failed\n");
-            goto out2;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;
=20
@@ -118,12 +118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     nvmx->msrbitmap =3D NULL;
     INIT_LIST_HEAD(&nvmx->launched_list);
     return 0;
-out2:
-    free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
-out1:
-    free_xenheap_page(nvcpu->nv_n2vmcx);
-out:
-    return -ENOMEM;
 }
 =20
 void nvmx_vcpu_destroy(struct vcpu *v)
@@ -147,16 +141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx =3D NULL;
     }
=20
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
-    {
-        list_del(&item->node);
-        xfree(item);
-    }
+    /* Must also cope with nvmx_vcpu_initialise() not having got called. =
*/
+    if ( nvmx->launched_list.next )
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
=20
     if ( v->arch.hvm_vmx.vmread_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
+        v->arch.hvm_vmx.vmread_bitmap =3D NULL;
+    }
     if ( v->arch.hvm_vmx.vmwrite_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmwrite_bitmap);
+        v->arch.hvm_vmx.vmwrite_bitmap =3D NULL;
+    }
 }
 =20
 void nvmx_domain_relinquish_resources(struct domain *d)



--=__Part54642E4F.2__=
Content-Type: text/plain; name="x86-nhvm-enable-failure.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-nhvm-enable-failure.patch"

x86/nhvm: properly clean up after failure to set up all vCPU-s=0A=0AOtherwi=
se we may leak memory when setting up nHVM fails half way.=0A=0AThis =
implies that the individual destroy functions will have to remain=0Acapable=
 (in the VMX case they first need to be made so, following=0A26486:7648ef65=
7fe7 and 26489:83a3fa9c8434) of being called for a vCPU=0Athat the =
corresponding init function was never run on.=0A=0AOnce at it, also clean =
up some inefficiencies in the corresponding=0Aparameter validation =
code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av2: nVMX =
fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.=0A=0A--- =
a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c=0A@@ -3916,20 =
+3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE=0A                    =
 rc =3D -EPERM;=0A                     break;=0A                 }=0A+     =
           if ( !a.value )=0A+                    break;=0A                =
 if ( a.value > 1 )=0A                     rc =3D -EINVAL;=0A-             =
   if ( !is_hvm_domain(d) )=0A-                    rc =3D -EINVAL;=0A      =
           /* Remove the check below once we have=0A                  * =
shadow-on-shadow.=0A                  */=0A-                if ( cpu_has_sv=
m && !paging_mode_hap(d) && a.value )=0A+                if ( cpu_has_svm =
&& !paging_mode_hap(d) )=0A                     rc =3D -EINVAL;=0A         =
        /* Set up NHVM state for any vcpus that are already up */=0A       =
          if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )=0A+       =
         {=0A                     for_each_vcpu(d, v)=0A                   =
      if ( rc =3D=3D 0 )=0A                             rc =3D nestedhvm_vc=
pu_initialise(v);=0A+                    if ( rc )=0A+                     =
   for_each_vcpu(d, v)=0A+                            nestedhvm_vcpu_destro=
y(v);=0A+                }=0A                 break;=0A             case =
HVM_PARAM_BUFIOREQ_EVTCHN:=0A                 rc =3D -EINVAL;=0A--- =
a/xen/arch/x86/hvm/nestedhvm.c=0A+++ b/xen/arch/x86/hvm/nestedhvm.c=0A@@ =
-87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu *v=0A void=0A =
nestedhvm_vcpu_destroy(struct vcpu *v)=0A {=0A-    if ( nestedhvm_enabled(v=
->domain) && hvm_funcs.nhvm_vcpu_destroy )=0A+    if ( hvm_funcs.nhvm_vcpu_=
destroy )=0A         hvm_funcs.nhvm_vcpu_destroy(v);=0A }=0A =0A--- =
a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ =
-62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     if ( =
!nvcpu->nv_n2vmcx )=0A     {=0A         gdprintk(XENLOG_ERR, "nest: =
allocation for shadow vmcs failed\n");=0A-	goto out;=0A+	return =
-ENOMEM;=0A     }=0A =0A     /* non-root VMREAD/VMWRITE bitmap. */=0A@@ =
-75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A         if ( =
!vmread_bitmap )=0A         {=0A             gdprintk(XENLOG_ERR, "nest: =
allocation for vmread bitmap failed\n");=0A-            goto out1;=0A+     =
       return -ENOMEM;=0A         }=0A         v->arch.hvm_vmx.vmread_bitma=
p =3D vmread_bitmap;=0A =0A@@ -83,7 +83,7 @@ int nvmx_vcpu_initialise(struc=
t vcpu *v)=0A         if ( !vmwrite_bitmap )=0A         {=0A             =
gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap failed\n");=0A-  =
          goto out2;=0A+            return -ENOMEM;=0A         }=0A        =
 v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;=0A =0A@@ -118,12 =
+118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     nvmx->msrbitmap =
=3D NULL;=0A     INIT_LIST_HEAD(&nvmx->launched_list);=0A     return =
0;=0A-out2:=0A-    free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);=0A-out=
1:=0A-    free_xenheap_page(nvcpu->nv_n2vmcx);=0A-out:=0A-    return =
-ENOMEM;=0A }=0A  =0A void nvmx_vcpu_destroy(struct vcpu *v)=0A@@ -147,16 =
+141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)=0A         nvcpu->nv_n2vm=
cx =3D NULL;=0A     }=0A =0A-    list_for_each_entry_safe(item, n, =
&nvmx->launched_list, node)=0A-    {=0A-        list_del(&item->node);=0A- =
       xfree(item);=0A-    }=0A+    /* Must also cope with nvmx_vcpu_initia=
lise() not having got called. */=0A+    if ( nvmx->launched_list.next =
)=0A+        list_for_each_entry_safe(item, n, &nvmx->launched_list, =
node)=0A+        {=0A+            list_del(&item->node);=0A+            =
xfree(item);=0A+        }=0A =0A     if ( v->arch.hvm_vmx.vmread_bitmap =
)=0A+    {=0A         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);=0A+=
        v->arch.hvm_vmx.vmread_bitmap =3D NULL;=0A+    }=0A     if ( =
v->arch.hvm_vmx.vmwrite_bitmap )=0A+    {=0A         free_domheap_page(v->a=
rch.hvm_vmx.vmwrite_bitmap);=0A+        v->arch.hvm_vmx.vmwrite_bitmap =3D =
NULL;=0A+    }=0A }=0A  =0A void nvmx_domain_relinquish_resources(struct =
domain *d)=0A
--=__Part54642E4F.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part54642E4F.2__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:28:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8UKB-0003Lh-Ss; Thu, 21 Feb 2013 11:28:27 +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 1U8UKA-0003LZ-1x
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:28:26 +0000
Received: from [85.158.138.51:9826] by server-6.bemta-3.messagelabs.com id
	04/7D-29959-5D406215; Thu, 21 Feb 2013 11:28:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361446098!9857273!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23189 invoked from network); 21 Feb 2013 11:28:19 -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; 21 Feb 2013 11:28:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:28:18 +0000
Message-Id: <5126131B02000078000BFD8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:29:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
	<20130221104943.GA22260@aepfle.de>
	<51260D1D02000078000BFD33@nat28.tlf.novell.com>
In-Reply-To: <51260D1D02000078000BFD33@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 21.02.13 at 12:03, "Jan Beulich" <JBeulich@suse.com> wrote:
>> On Wed, Feb 20, Olaf Hering wrote:
>> And its
>> not clear why nestedhvm_vcpu_destroy calls into nvmx_vcpu_destroy
>> anyway. nestedhvm is not in the config file.
> 
> nHVM can be turned on and off on a domain, so cleanup is needed
> unconditionally. This was also the reason why 26507:4f53ddbee940
> had to revert 26503:69398345c10e.

Sorry, I was wrong with that for what's already committed, as I
looked at the code with the patch just sent already in place.
Something must be setting the flag for you, unless your code
base is from the small window between the commit of that patch's
v1 and its revert.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:28:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8UKB-0003Lh-Ss; Thu, 21 Feb 2013 11:28:27 +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 1U8UKA-0003LZ-1x
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:28:26 +0000
Received: from [85.158.138.51:9826] by server-6.bemta-3.messagelabs.com id
	04/7D-29959-5D406215; Thu, 21 Feb 2013 11:28:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361446098!9857273!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23189 invoked from network); 21 Feb 2013 11:28:19 -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; 21 Feb 2013 11:28:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:28:18 +0000
Message-Id: <5126131B02000078000BFD8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:29:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
	<20130221104943.GA22260@aepfle.de>
	<51260D1D02000078000BFD33@nat28.tlf.novell.com>
In-Reply-To: <51260D1D02000078000BFD33@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 21.02.13 at 12:03, "Jan Beulich" <JBeulich@suse.com> wrote:
>> On Wed, Feb 20, Olaf Hering wrote:
>> And its
>> not clear why nestedhvm_vcpu_destroy calls into nvmx_vcpu_destroy
>> anyway. nestedhvm is not in the config file.
> 
> nHVM can be turned on and off on a domain, so cleanup is needed
> unconditionally. This was also the reason why 26507:4f53ddbee940
> had to revert 26503:69398345c10e.

Sorry, I was wrong with that for what's already committed, as I
looked at the code with the patch just sent already in place.
Something must be setting the flag for you, unless your code
base is from the small window between the commit of that patch's
v1 and its revert.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:31: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 1U8UNC-0003Zv-Ji; Thu, 21 Feb 2013 11:31:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alifchits@gmail.com>) id 1U8UNB-0003Zn-32
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:31:33 +0000
Received: from [85.158.139.83:59461] by server-8.bemta-5.messagelabs.com id
	FD/08-19075-49506215; Thu, 21 Feb 2013 11:31:32 +0000
X-Env-Sender: alifchits@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361446287!28263062!1
X-Originating-IP: [74.125.83.46]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1222 invoked from network); 21 Feb 2013 11:31:27 -0000
Received: from mail-ee0-f46.google.com (HELO mail-ee0-f46.google.com)
	(74.125.83.46)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:31:27 -0000
Received: by mail-ee0-f46.google.com with SMTP id e49so4622118eek.5
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 03:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=xFgM4wRVeWQhDjAOgASrAbrDxxou+VrnjunKVG7+Vs4=;
	b=FyIMr/S+SkhRDzlEvYV4HjIOWPlJEThCw7iWxS3ZwPEno3DqZdOk25/gDFpi8oYFpk
	0xg94P2Psmm14gbC0fQ91Cf5Wj18dbDxm28t0V37iSbp650XXQW0Sw/Ak8ic7dd4+Qa2
	qx5UKfEVXbNX+pkFO1zOoxFZuXiLSUmphHAOQIK26oVT2YdTqiDSqDz2dlXnA5btG4fp
	gVfdkijf2JdDyY/MoZyanhB1MefIv4dAo1rzBsb/xsZ0YOGZ+8LPV0fuce9Bb7M/z/jC
	9178MXIglLFLRVXnE6C/sYMDZ431/gboeJCym/Ylp12KW41aDDgoUepbE44CEPjklIv2
	NBhg==
X-Received: by 10.14.219.7 with SMTP id l7mr56144064eep.12.1361446286809; Thu,
	21 Feb 2013 03:31:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.190.71 with HTTP; Thu, 21 Feb 2013 03:30:56 -0800 (PST)
In-Reply-To: <1361379682.26546.18.camel@zakaz.uk.xensource.com>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
	<1361379682.26546.18.camel@zakaz.uk.xensource.com>
From: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Thu, 21 Feb 2013 11:30:56 +0000
X-Google-Sender-Auth: krLvSCtz-ImT_zXHaaYUKL2dpXM
Message-ID: <CA+YWh9bx3w6OKDSug+yiHvZ1+JWRco5wpo4UM_T16LXC-8aeZg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] build: Fix distclean when repo location
	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 20, 2013 at 5:01 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-20 at 16:47 +0000, Andrei Lifchits wrote:
>> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
>> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
>> breaks distclean because make attempts to clean inside those first and fails to
>> find Makefile (which is also a symlink).

Signed-off-by: Andrei Lifchits <andrei.lifchits@citrix.com>

> Would it be possible to arrange for the symlinks to be relative in the
> first place?

Good idea, I'll look into it when I have time (there are a lot of
those symlinks in various places).

>>
>> diff -r 66f563be41d9 -r 8f69a0bcab52 stubdom/Makefile
>> --- a/stubdom/Makefile        Tue Feb 19 10:49:53 2013 +0100
>> +++ b/stubdom/Makefile        Wed Feb 20 16:36:40 2013 +0000
>> @@ -501,7 +501,7 @@ clean:
>>       $(MAKE) -C vtpmmgr clean
>>       rm -fr grub-$(XEN_TARGET_ARCH)
>>       rm -f $(STUBDOMPATH)
>> -     [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
>> +     [ ! -e libxc-$(XEN_TARGET_ARCH)/Makefile ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
>>       -[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
>>       -[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Feb 21 11:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:31: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 1U8UNC-0003Zv-Ji; Thu, 21 Feb 2013 11:31:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alifchits@gmail.com>) id 1U8UNB-0003Zn-32
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:31:33 +0000
Received: from [85.158.139.83:59461] by server-8.bemta-5.messagelabs.com id
	FD/08-19075-49506215; Thu, 21 Feb 2013 11:31:32 +0000
X-Env-Sender: alifchits@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361446287!28263062!1
X-Originating-IP: [74.125.83.46]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1222 invoked from network); 21 Feb 2013 11:31:27 -0000
Received: from mail-ee0-f46.google.com (HELO mail-ee0-f46.google.com)
	(74.125.83.46)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:31:27 -0000
Received: by mail-ee0-f46.google.com with SMTP id e49so4622118eek.5
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 03:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=xFgM4wRVeWQhDjAOgASrAbrDxxou+VrnjunKVG7+Vs4=;
	b=FyIMr/S+SkhRDzlEvYV4HjIOWPlJEThCw7iWxS3ZwPEno3DqZdOk25/gDFpi8oYFpk
	0xg94P2Psmm14gbC0fQ91Cf5Wj18dbDxm28t0V37iSbp650XXQW0Sw/Ak8ic7dd4+Qa2
	qx5UKfEVXbNX+pkFO1zOoxFZuXiLSUmphHAOQIK26oVT2YdTqiDSqDz2dlXnA5btG4fp
	gVfdkijf2JdDyY/MoZyanhB1MefIv4dAo1rzBsb/xsZ0YOGZ+8LPV0fuce9Bb7M/z/jC
	9178MXIglLFLRVXnE6C/sYMDZ431/gboeJCym/Ylp12KW41aDDgoUepbE44CEPjklIv2
	NBhg==
X-Received: by 10.14.219.7 with SMTP id l7mr56144064eep.12.1361446286809; Thu,
	21 Feb 2013 03:31:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.190.71 with HTTP; Thu, 21 Feb 2013 03:30:56 -0800 (PST)
In-Reply-To: <1361379682.26546.18.camel@zakaz.uk.xensource.com>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
	<1361379682.26546.18.camel@zakaz.uk.xensource.com>
From: Andrei Lifchits <andrei.lifchits@citrix.com>
Date: Thu, 21 Feb 2013 11:30:56 +0000
X-Google-Sender-Auth: krLvSCtz-ImT_zXHaaYUKL2dpXM
Message-ID: <CA+YWh9bx3w6OKDSug+yiHvZ1+JWRco5wpo4UM_T16LXC-8aeZg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] build: Fix distclean when repo location
	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 20, 2013 at 5:01 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-20 at 16:47 +0000, Andrei Lifchits wrote:
>> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
>> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
>> breaks distclean because make attempts to clean inside those first and fails to
>> find Makefile (which is also a symlink).

Signed-off-by: Andrei Lifchits <andrei.lifchits@citrix.com>

> Would it be possible to arrange for the symlinks to be relative in the
> first place?

Good idea, I'll look into it when I have time (there are a lot of
those symlinks in various places).

>>
>> diff -r 66f563be41d9 -r 8f69a0bcab52 stubdom/Makefile
>> --- a/stubdom/Makefile        Tue Feb 19 10:49:53 2013 +0100
>> +++ b/stubdom/Makefile        Wed Feb 20 16:36:40 2013 +0000
>> @@ -501,7 +501,7 @@ clean:
>>       $(MAKE) -C vtpmmgr clean
>>       rm -fr grub-$(XEN_TARGET_ARCH)
>>       rm -f $(STUBDOMPATH)
>> -     [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
>> +     [ ! -e libxc-$(XEN_TARGET_ARCH)/Makefile ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean
>>       -[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
>>       -[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Feb 21 11:41:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:41: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 1U8UWv-0003r9-PS; Thu, 21 Feb 2013 11:41:37 +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 1U8UWt-0003r4-Uu
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:41:36 +0000
Received: from [85.158.139.83:29683] by server-4.bemta-5.messagelabs.com id
	CB/47-29496-FE706215; Thu, 21 Feb 2013 11:41:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361446893!24012049!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17067 invoked from network); 21 Feb 2013 11:41:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:41:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:41:33 +0000
Message-Id: <5126163702000078000BFDA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:42:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part20105A37.0__="
Subject: [Xen-devel] [PATCH] x86: rework hypercall argument translation area
	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>
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.

--=__Part20105A37.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than using an order-1 Xen heap allocation, use (currently 2)
individual domain heap pages to populate space in the per-domain
mapping area.

Also fix an off-by-one mistake in is_compat_arg_xlat_range().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -642,6 +642,14 @@ void arch_domain_destroy(struct domain *
             free_domheap_page(d->arch.perdomain_l2_pg[i]);
     free_domheap_page(d->arch.perdomain_l3_pg);
=20
+    if ( d->arch.arg_xlat_l1_pg )
+    {
+        for ( i =3D 0; i < PFN_UP(MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT); =
++i )
+            if ( d->arch.arg_xlat_l1_pg[i] )
+                free_domheap_page(d->arch.arg_xlat_l1_pg[i]);
+        xfree(d->arch.arg_xlat_l1_pg);
+    }
+
     free_xenheap_page(d->shared_info);
     cleanup_domain_irq_mapping(d);
 }
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -6,8 +6,8 @@
  * Copyright 2002 Andi Kleen <ak@suse.de>
  */
=20
-#include <xen/config.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <asm/uaccess.h>
=20
 unsigned long __copy_to_user_ll(void __user *to, const void *from, =
unsigned n)
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -832,27 +832,93 @@ void __init zap_low_mappings(void)
                      __PAGE_HYPERVISOR);
 }
=20
-void *compat_arg_xlat_virt_base(void)
-{
-    return current->arch.compat_arg_xlat;
-}
-
 int setup_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
+    struct domain *d =3D v->domain;
+    struct page_info *pg;
+    unsigned int idx, i;
+    l1_pgentry_t *l1tab;
+
+    if ( !d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] )
+    {
+        l3_pgentry_t *l3tab;
+
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        clear_domain_page(page_to_mfn(pg));
+        d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] =3D pg;
+
+        l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+        l3tab[l3_table_offset(ARG_XLAT_VIRT_START)] =3D
+            l3e_from_page(pg, __PAGE_HYPERVISOR);
+        unmap_domain_page(l3tab);
+    }
+
+    BUILD_BUG_ON((MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT) >
+                 (PERDOMAIN_SLOT_MBYTES << 20));
+
+    if ( !d->arch.arg_xlat_l1_pg )
+        d->arch.arg_xlat_l1_pg =3D xzalloc_array(struct page_info *,
+                                               PFN_UP(MAX_VIRT_CPUS <<
+                                                      ARG_XLAT_VA_SHIFT));=

+    if ( !d->arch.arg_xlat_l1_pg )
+        return -ENOMEM;
+
+    idx =3D l2_table_offset(ARG_XLAT_START(v));
+    if ( !d->arch.arg_xlat_l1_pg[idx] )
+    {
+        l2_pgentry_t *l2tab;
+
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        clear_domain_page(page_to_mfn(pg));
+        d->arch.arg_xlat_l1_pg[idx] =3D pg;
+
+        l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[ARG_XLAT_SLOT]=
);
+        l2tab[idx] =3D l2e_from_page(pg, __PAGE_HYPERVISOR);
+        unmap_domain_page(l2tab);
+    }
=20
-    v->arch.compat_arg_xlat =3D alloc_xenheap_pages(order,
-                                                  MEMF_node(vcpu_to_node(v=
)));
+    l1tab =3D __map_domain_page(d->arch.arg_xlat_l1_pg[idx]);
+    idx =3D l1_table_offset(ARG_XLAT_START(v));
+    BUILD_BUG_ON(COMPAT_ARG_XLAT_SIZE > (1UL << ARG_XLAT_VA_SHIFT));
+    for ( i =3D 0; i < PFN_UP(COMPAT_ARG_XLAT_SIZE); ++i )
+    {
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        l1tab[idx + i] =3D l1e_from_page(pg, __PAGE_HYPERVISOR);
+    }
+    unmap_domain_page(l1tab);
=20
-    return v->arch.compat_arg_xlat ? 0 : -ENOMEM;
+    return 0;
 }
=20
 void free_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
+    struct domain *d =3D v->domain;
+    unsigned long start =3D ARG_XLAT_START(v);
+    unsigned long va =3D start + COMPAT_ARG_XLAT_SIZE - 1;
+    l1_pgentry_t *l1tab =3D
+        __map_domain_page(d->arch.arg_xlat_l1_pg[l2_table_offset(start)]);=

+
+    do {
+        l1_pgentry_t l1e =3D l1tab[l1_table_offset(va)];
+
+        if ( l1e_get_flags(l1e) & _PAGE_PRESENT )
+        {
+            struct page_info *pg =3D l1e_get_page(l1e);
+
+            l1tab[l1_table_offset(va)] =3D l1e_empty();
+            flush_tlb_one_mask(d->domain_dirty_cpumask, va);
+            free_domheap_page(pg);
+        }
+        va -=3D PAGE_SIZE;
+    } while ( va >=3D start );
=20
-    free_xenheap_pages(v->arch.compat_arg_xlat, order);
-    v->arch.compat_arg_xlat =3D NULL;
+    unmap_domain_page(l1tab);
 }
=20
 void cleanup_frame_table(struct mem_hotadd_info *info)
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]
 /* Slot 260: per-domain mappings (including map cache). */
 #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
 #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER=
))
-#define PERDOMAIN_SLOTS         2
+#define PERDOMAIN_SLOTS         3
 #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
                                  (PERDOMAIN_SLOT_MBYTES << 20))
 /* Slot 261: machine-to-phys conversion table (256GB). */
@@ -304,6 +304,14 @@ extern unsigned long xen_phys_start;
 #define LDT_VIRT_START(v)    \
     (GDT_VIRT_START(v) + (64*1024))
=20
+/* Argument translation area. The 2nd to last per-domain-mapping =
sub-area. */
+#define ARG_XLAT_SLOT            (PERDOMAIN_SLOTS - 2)
+/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 =
pages): */
+#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)
+#define ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(ARG_XLAT_SLOT)
+#define ARG_XLAT_START(v)        \
+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
+
 /* map_domain_page() map cache. The last per-domain-mapping sub-area. */
 #define MAPCACHE_VCPU_ENTRIES    (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEV=
ELS)
 #define MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)
@@ -313,7 +321,7 @@ extern unsigned long xen_phys_start;
                                   MAPCACHE_ENTRIES * PAGE_SIZE)
=20
 #define PDPT_L1_ENTRIES       \
-    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)
+    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 2) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)
 #define PDPT_L2_ENTRIES       \
     ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)
=20
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -244,6 +244,7 @@ struct arch_domain
     void **perdomain_pts;
     struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];
     struct page_info *perdomain_l3_pg;
+    struct page_info **arg_xlat_l1_pg;
=20
     unsigned int hv_compat_vstart;
=20
@@ -448,9 +449,6 @@ struct arch_vcpu
=20
     /* A secondary copy of the vcpu time info. */
     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
-
-    void *compat_arg_xlat;
-
 } __cacheline_aligned;
=20
 /* Shorthands to improve code legibility. */
--- a/xen/include/asm-x86/x86_64/uaccess.h
+++ b/xen/include/asm-x86/x86_64/uaccess.h
@@ -1,16 +1,15 @@
 #ifndef __X86_64_UACCESS_H
 #define __X86_64_UACCESS_H
=20
-#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()
+#define COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))
 #define COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)
 struct vcpu;
-void *compat_arg_xlat_virt_base(void);
 int setup_compat_arg_xlat(struct vcpu *v);
 void free_compat_arg_xlat(struct vcpu *v);
 #define is_compat_arg_xlat_range(addr, size) ({                           =
    \
     unsigned long __off;                                                  =
    \
     __off =3D (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_=
BASE; \
-    (__off <=3D COMPAT_ARG_XLAT_SIZE) &&                                  =
      \
+    (__off < COMPAT_ARG_XLAT_SIZE) &&                                     =
    \
     ((__off + (unsigned long)(size)) <=3D COMPAT_ARG_XLAT_SIZE);          =
      \
 })
=20



--=__Part20105A37.0__=
Content-Type: text/plain; name="x86-map-arg-xlat-area.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-arg-xlat-area.patch"

x86: rework hypercall argument translation area setup=0A=0ARather than =
using an order-1 Xen heap allocation, use (currently 2)=0Aindividual =
domain heap pages to populate space in the per-domain=0Amapping area.=0A=0A=
Also fix an off-by-one mistake in is_compat_arg_xlat_range().=0A=0ASigned-o=
ff-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domain.c=0A+=
++ b/xen/arch/x86/domain.c=0A@@ -642,6 +642,14 @@ void arch_domain_destroy(=
struct domain *=0A             free_domheap_page(d->arch.perdomain_l2_pg[i]=
);=0A     free_domheap_page(d->arch.perdomain_l3_pg);=0A =0A+    if ( =
d->arch.arg_xlat_l1_pg )=0A+    {=0A+        for ( i =3D 0; i < PFN_UP(MAX_=
VIRT_CPUS << ARG_XLAT_VA_SHIFT); ++i )=0A+            if ( d->arch.arg_xlat=
_l1_pg[i] )=0A+                free_domheap_page(d->arch.arg_xlat_l1_pg[i])=
;=0A+        xfree(d->arch.arg_xlat_l1_pg);=0A+    }=0A+=0A     free_xenhea=
p_page(d->shared_info);=0A     cleanup_domain_irq_mapping(d);=0A }=0A--- =
a/xen/arch/x86/usercopy.c=0A+++ b/xen/arch/x86/usercopy.c=0A@@ -6,8 +6,8 =
@@=0A  * Copyright 2002 Andi Kleen <ak@suse.de>=0A  */=0A =0A-#include =
<xen/config.h>=0A #include <xen/lib.h>=0A+#include <xen/sched.h>=0A =
#include <asm/uaccess.h>=0A =0A unsigned long __copy_to_user_ll(void =
__user *to, const void *from, unsigned n)=0A--- a/xen/arch/x86/x86_64/mm.c=
=0A+++ b/xen/arch/x86/x86_64/mm.c=0A@@ -832,27 +832,93 @@ void __init =
zap_low_mappings(void)=0A                      __PAGE_HYPERVISOR);=0A }=0A =
=0A-void *compat_arg_xlat_virt_base(void)=0A-{=0A-    return current->arch.=
compat_arg_xlat;=0A-}=0A-=0A int setup_compat_arg_xlat(struct vcpu *v)=0A =
{=0A-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=
=0A+    struct domain *d =3D v->domain;=0A+    struct page_info *pg;=0A+   =
 unsigned int idx, i;=0A+    l1_pgentry_t *l1tab;=0A+=0A+    if ( =
!d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] )=0A+    {=0A+        l3_pgentry_t =
*l3tab;=0A+=0A+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_=
node(d)));=0A+        if ( !pg )=0A+            return -ENOMEM;=0A+        =
clear_domain_page(page_to_mfn(pg));=0A+        d->arch.perdomain_l2_pg[ARG_=
XLAT_SLOT] =3D pg;=0A+=0A+        l3tab =3D __map_domain_page(d->arch.perdo=
main_l3_pg);=0A+        l3tab[l3_table_offset(ARG_XLAT_VIRT_START)] =
=3D=0A+            l3e_from_page(pg, __PAGE_HYPERVISOR);=0A+        =
unmap_domain_page(l3tab);=0A+    }=0A+=0A+    BUILD_BUG_ON((MAX_VIRT_CPUS =
<< ARG_XLAT_VA_SHIFT) >=0A+                 (PERDOMAIN_SLOT_MBYTES << =
20));=0A+=0A+    if ( !d->arch.arg_xlat_l1_pg )=0A+        d->arch.arg_xlat=
_l1_pg =3D xzalloc_array(struct page_info *,=0A+                           =
                    PFN_UP(MAX_VIRT_CPUS <<=0A+                            =
                          ARG_XLAT_VA_SHIFT));=0A+    if ( !d->arch.arg_xla=
t_l1_pg )=0A+        return -ENOMEM;=0A+=0A+    idx =3D l2_table_offset(ARG=
_XLAT_START(v));=0A+    if ( !d->arch.arg_xlat_l1_pg[idx] )=0A+    {=0A+   =
     l2_pgentry_t *l2tab;=0A+=0A+        pg =3D alloc_domheap_page(NULL, =
MEMF_node(domain_to_node(d)));=0A+        if ( !pg )=0A+            return =
-ENOMEM;=0A+        clear_domain_page(page_to_mfn(pg));=0A+        =
d->arch.arg_xlat_l1_pg[idx] =3D pg;=0A+=0A+        l2tab =3D __map_domain_p=
age(d->arch.perdomain_l2_pg[ARG_XLAT_SLOT]);=0A+        l2tab[idx] =3D =
l2e_from_page(pg, __PAGE_HYPERVISOR);=0A+        unmap_domain_page(l2tab);=
=0A+    }=0A =0A-    v->arch.compat_arg_xlat =3D alloc_xenheap_pages(order,=
=0A-                                                  MEMF_node(vcpu_to_nod=
e(v)));=0A+    l1tab =3D __map_domain_page(d->arch.arg_xlat_l1_pg[idx]);=0A=
+    idx =3D l1_table_offset(ARG_XLAT_START(v));=0A+    BUILD_BUG_ON(COMPAT=
_ARG_XLAT_SIZE > (1UL << ARG_XLAT_VA_SHIFT));=0A+    for ( i =3D 0; i < =
PFN_UP(COMPAT_ARG_XLAT_SIZE); ++i )=0A+    {=0A+        pg =3D alloc_domhea=
p_page(NULL, MEMF_node(domain_to_node(d)));=0A+        if ( !pg )=0A+      =
      return -ENOMEM;=0A+        l1tab[idx + i] =3D l1e_from_page(pg, =
__PAGE_HYPERVISOR);=0A+    }=0A+    unmap_domain_page(l1tab);=0A =0A-    =
return v->arch.compat_arg_xlat ? 0 : -ENOMEM;=0A+    return 0;=0A }=0A =0A =
void free_compat_arg_xlat(struct vcpu *v)=0A {=0A-    unsigned int order =
=3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=0A+    struct domain *d =
=3D v->domain;=0A+    unsigned long start =3D ARG_XLAT_START(v);=0A+    =
unsigned long va =3D start + COMPAT_ARG_XLAT_SIZE - 1;=0A+    l1_pgentry_t =
*l1tab =3D=0A+        __map_domain_page(d->arch.arg_xlat_l1_pg[l2_table_off=
set(start)]);=0A+=0A+    do {=0A+        l1_pgentry_t l1e =3D l1tab[l1_tabl=
e_offset(va)];=0A+=0A+        if ( l1e_get_flags(l1e) & _PAGE_PRESENT =
)=0A+        {=0A+            struct page_info *pg =3D l1e_get_page(l1e);=
=0A+=0A+            l1tab[l1_table_offset(va)] =3D l1e_empty();=0A+        =
    flush_tlb_one_mask(d->domain_dirty_cpumask, va);=0A+            =
free_domheap_page(pg);=0A+        }=0A+        va -=3D PAGE_SIZE;=0A+    } =
while ( va >=3D start );=0A =0A-    free_xenheap_pages(v->arch.compat_arg_x=
lat, order);=0A-    v->arch.compat_arg_xlat =3D NULL;=0A+    unmap_domain_p=
age(l1tab);=0A }=0A =0A void cleanup_frame_table(struct mem_hotadd_info =
*info)=0A--- a/xen/include/asm-x86/config.h=0A+++ b/xen/include/asm-x86/con=
fig.h=0A@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]=0A /* =
Slot 260: per-domain mappings (including map cache). */=0A #define =
PERDOMAIN_VIRT_START    (PML4_ADDR(260))=0A #define PERDOMAIN_SLOT_MBYTES  =
 (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))=0A-#define PERDOMAIN_SLOTS   =
      2=0A+#define PERDOMAIN_SLOTS         3=0A #define PERDOMAIN_VIRT_SLOT=
(s)  (PERDOMAIN_VIRT_START + (s) * \=0A                                  =
(PERDOMAIN_SLOT_MBYTES << 20))=0A /* Slot 261: machine-to-phys conversion =
table (256GB). */=0A@@ -304,6 +304,14 @@ extern unsigned long xen_phys_star=
t;=0A #define LDT_VIRT_START(v)    \=0A     (GDT_VIRT_START(v) + (64*1024))=
=0A =0A+/* Argument translation area. The 2nd to last per-domain-mapping =
sub-area. */=0A+#define ARG_XLAT_SLOT            (PERDOMAIN_SLOTS - =
2)=0A+/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 =
pages): */=0A+#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)=0A+#define =
ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(ARG_XLAT_SLOT)=0A+#define =
ARG_XLAT_START(v)        \=0A+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << =
ARG_XLAT_VA_SHIFT))=0A+=0A /* map_domain_page() map cache. The last =
per-domain-mapping sub-area. */=0A #define MAPCACHE_VCPU_ENTRIES    =
(CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS)=0A #define MAPCACHE_ENTRIES  =
       (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)=0A@@ -313,7 +321,7 @@ =
extern unsigned long xen_phys_start;=0A                                   =
MAPCACHE_ENTRIES * PAGE_SIZE)=0A =0A #define PDPT_L1_ENTRIES       \=0A-   =
 ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)=0A+    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 2) - PERDOMAIN_V=
IRT_START) >> PAGE_SHIFT)=0A #define PDPT_L2_ENTRIES       \=0A     =
((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)=0A =
=0A--- a/xen/include/asm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=
=0A@@ -244,6 +244,7 @@ struct arch_domain=0A     void **perdomain_pts;=0A  =
   struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];=0A     struct =
page_info *perdomain_l3_pg;=0A+    struct page_info **arg_xlat_l1_pg;=0A =
=0A     unsigned int hv_compat_vstart;=0A =0A@@ -448,9 +449,6 @@ struct =
arch_vcpu=0A =0A     /* A secondary copy of the vcpu time info. */=0A     =
XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;=0A-=0A-    void =
*compat_arg_xlat;=0A-=0A } __cacheline_aligned;=0A =0A /* Shorthands to =
improve code legibility. */=0A--- a/xen/include/asm-x86/x86_64/uaccess.h=0A=
+++ b/xen/include/asm-x86/x86_64/uaccess.h=0A@@ -1,16 +1,15 @@=0A #ifndef =
__X86_64_UACCESS_H=0A #define __X86_64_UACCESS_H=0A =0A-#define COMPAT_ARG_=
XLAT_VIRT_BASE compat_arg_xlat_virt_base()=0A+#define COMPAT_ARG_XLAT_VIRT_=
BASE ((void *)ARG_XLAT_START(current))=0A #define COMPAT_ARG_XLAT_SIZE     =
 (2*PAGE_SIZE)=0A struct vcpu;=0A-void *compat_arg_xlat_virt_base(void);=0A=
 int setup_compat_arg_xlat(struct vcpu *v);=0A void free_compat_arg_xlat(st=
ruct vcpu *v);=0A #define is_compat_arg_xlat_range(addr, size) ({          =
                     \=0A     unsigned long __off;                         =
                             \=0A     __off =3D (unsigned long)(addr) - =
(unsigned long)COMPAT_ARG_XLAT_VIRT_BASE; \=0A-    (__off <=3D COMPAT_ARG_X=
LAT_SIZE) &&                                        \=0A+    (__off < =
COMPAT_ARG_XLAT_SIZE) &&                                         \=0A     =
((__off + (unsigned long)(size)) <=3D COMPAT_ARG_XLAT_SIZE);               =
 \=0A })=0A =0A
--=__Part20105A37.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

--=__Part20105A37.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:41:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:41: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 1U8UWv-0003r9-PS; Thu, 21 Feb 2013 11:41:37 +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 1U8UWt-0003r4-Uu
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:41:36 +0000
Received: from [85.158.139.83:29683] by server-4.bemta-5.messagelabs.com id
	CB/47-29496-FE706215; Thu, 21 Feb 2013 11:41:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361446893!24012049!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17067 invoked from network); 21 Feb 2013 11:41:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:41:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 11:41:33 +0000
Message-Id: <5126163702000078000BFDA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 11:42:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part20105A37.0__="
Subject: [Xen-devel] [PATCH] x86: rework hypercall argument translation area
	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>
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.

--=__Part20105A37.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than using an order-1 Xen heap allocation, use (currently 2)
individual domain heap pages to populate space in the per-domain
mapping area.

Also fix an off-by-one mistake in is_compat_arg_xlat_range().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -642,6 +642,14 @@ void arch_domain_destroy(struct domain *
             free_domheap_page(d->arch.perdomain_l2_pg[i]);
     free_domheap_page(d->arch.perdomain_l3_pg);
=20
+    if ( d->arch.arg_xlat_l1_pg )
+    {
+        for ( i =3D 0; i < PFN_UP(MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT); =
++i )
+            if ( d->arch.arg_xlat_l1_pg[i] )
+                free_domheap_page(d->arch.arg_xlat_l1_pg[i]);
+        xfree(d->arch.arg_xlat_l1_pg);
+    }
+
     free_xenheap_page(d->shared_info);
     cleanup_domain_irq_mapping(d);
 }
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -6,8 +6,8 @@
  * Copyright 2002 Andi Kleen <ak@suse.de>
  */
=20
-#include <xen/config.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <asm/uaccess.h>
=20
 unsigned long __copy_to_user_ll(void __user *to, const void *from, =
unsigned n)
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -832,27 +832,93 @@ void __init zap_low_mappings(void)
                      __PAGE_HYPERVISOR);
 }
=20
-void *compat_arg_xlat_virt_base(void)
-{
-    return current->arch.compat_arg_xlat;
-}
-
 int setup_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
+    struct domain *d =3D v->domain;
+    struct page_info *pg;
+    unsigned int idx, i;
+    l1_pgentry_t *l1tab;
+
+    if ( !d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] )
+    {
+        l3_pgentry_t *l3tab;
+
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        clear_domain_page(page_to_mfn(pg));
+        d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] =3D pg;
+
+        l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+        l3tab[l3_table_offset(ARG_XLAT_VIRT_START)] =3D
+            l3e_from_page(pg, __PAGE_HYPERVISOR);
+        unmap_domain_page(l3tab);
+    }
+
+    BUILD_BUG_ON((MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT) >
+                 (PERDOMAIN_SLOT_MBYTES << 20));
+
+    if ( !d->arch.arg_xlat_l1_pg )
+        d->arch.arg_xlat_l1_pg =3D xzalloc_array(struct page_info *,
+                                               PFN_UP(MAX_VIRT_CPUS <<
+                                                      ARG_XLAT_VA_SHIFT));=

+    if ( !d->arch.arg_xlat_l1_pg )
+        return -ENOMEM;
+
+    idx =3D l2_table_offset(ARG_XLAT_START(v));
+    if ( !d->arch.arg_xlat_l1_pg[idx] )
+    {
+        l2_pgentry_t *l2tab;
+
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        clear_domain_page(page_to_mfn(pg));
+        d->arch.arg_xlat_l1_pg[idx] =3D pg;
+
+        l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[ARG_XLAT_SLOT]=
);
+        l2tab[idx] =3D l2e_from_page(pg, __PAGE_HYPERVISOR);
+        unmap_domain_page(l2tab);
+    }
=20
-    v->arch.compat_arg_xlat =3D alloc_xenheap_pages(order,
-                                                  MEMF_node(vcpu_to_node(v=
)));
+    l1tab =3D __map_domain_page(d->arch.arg_xlat_l1_pg[idx]);
+    idx =3D l1_table_offset(ARG_XLAT_START(v));
+    BUILD_BUG_ON(COMPAT_ARG_XLAT_SIZE > (1UL << ARG_XLAT_VA_SHIFT));
+    for ( i =3D 0; i < PFN_UP(COMPAT_ARG_XLAT_SIZE); ++i )
+    {
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        l1tab[idx + i] =3D l1e_from_page(pg, __PAGE_HYPERVISOR);
+    }
+    unmap_domain_page(l1tab);
=20
-    return v->arch.compat_arg_xlat ? 0 : -ENOMEM;
+    return 0;
 }
=20
 void free_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
+    struct domain *d =3D v->domain;
+    unsigned long start =3D ARG_XLAT_START(v);
+    unsigned long va =3D start + COMPAT_ARG_XLAT_SIZE - 1;
+    l1_pgentry_t *l1tab =3D
+        __map_domain_page(d->arch.arg_xlat_l1_pg[l2_table_offset(start)]);=

+
+    do {
+        l1_pgentry_t l1e =3D l1tab[l1_table_offset(va)];
+
+        if ( l1e_get_flags(l1e) & _PAGE_PRESENT )
+        {
+            struct page_info *pg =3D l1e_get_page(l1e);
+
+            l1tab[l1_table_offset(va)] =3D l1e_empty();
+            flush_tlb_one_mask(d->domain_dirty_cpumask, va);
+            free_domheap_page(pg);
+        }
+        va -=3D PAGE_SIZE;
+    } while ( va >=3D start );
=20
-    free_xenheap_pages(v->arch.compat_arg_xlat, order);
-    v->arch.compat_arg_xlat =3D NULL;
+    unmap_domain_page(l1tab);
 }
=20
 void cleanup_frame_table(struct mem_hotadd_info *info)
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]
 /* Slot 260: per-domain mappings (including map cache). */
 #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
 #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER=
))
-#define PERDOMAIN_SLOTS         2
+#define PERDOMAIN_SLOTS         3
 #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
                                  (PERDOMAIN_SLOT_MBYTES << 20))
 /* Slot 261: machine-to-phys conversion table (256GB). */
@@ -304,6 +304,14 @@ extern unsigned long xen_phys_start;
 #define LDT_VIRT_START(v)    \
     (GDT_VIRT_START(v) + (64*1024))
=20
+/* Argument translation area. The 2nd to last per-domain-mapping =
sub-area. */
+#define ARG_XLAT_SLOT            (PERDOMAIN_SLOTS - 2)
+/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 =
pages): */
+#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)
+#define ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(ARG_XLAT_SLOT)
+#define ARG_XLAT_START(v)        \
+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
+
 /* map_domain_page() map cache. The last per-domain-mapping sub-area. */
 #define MAPCACHE_VCPU_ENTRIES    (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEV=
ELS)
 #define MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)
@@ -313,7 +321,7 @@ extern unsigned long xen_phys_start;
                                   MAPCACHE_ENTRIES * PAGE_SIZE)
=20
 #define PDPT_L1_ENTRIES       \
-    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)
+    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 2) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)
 #define PDPT_L2_ENTRIES       \
     ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)
=20
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -244,6 +244,7 @@ struct arch_domain
     void **perdomain_pts;
     struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];
     struct page_info *perdomain_l3_pg;
+    struct page_info **arg_xlat_l1_pg;
=20
     unsigned int hv_compat_vstart;
=20
@@ -448,9 +449,6 @@ struct arch_vcpu
=20
     /* A secondary copy of the vcpu time info. */
     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
-
-    void *compat_arg_xlat;
-
 } __cacheline_aligned;
=20
 /* Shorthands to improve code legibility. */
--- a/xen/include/asm-x86/x86_64/uaccess.h
+++ b/xen/include/asm-x86/x86_64/uaccess.h
@@ -1,16 +1,15 @@
 #ifndef __X86_64_UACCESS_H
 #define __X86_64_UACCESS_H
=20
-#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()
+#define COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))
 #define COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)
 struct vcpu;
-void *compat_arg_xlat_virt_base(void);
 int setup_compat_arg_xlat(struct vcpu *v);
 void free_compat_arg_xlat(struct vcpu *v);
 #define is_compat_arg_xlat_range(addr, size) ({                           =
    \
     unsigned long __off;                                                  =
    \
     __off =3D (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_=
BASE; \
-    (__off <=3D COMPAT_ARG_XLAT_SIZE) &&                                  =
      \
+    (__off < COMPAT_ARG_XLAT_SIZE) &&                                     =
    \
     ((__off + (unsigned long)(size)) <=3D COMPAT_ARG_XLAT_SIZE);          =
      \
 })
=20



--=__Part20105A37.0__=
Content-Type: text/plain; name="x86-map-arg-xlat-area.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-arg-xlat-area.patch"

x86: rework hypercall argument translation area setup=0A=0ARather than =
using an order-1 Xen heap allocation, use (currently 2)=0Aindividual =
domain heap pages to populate space in the per-domain=0Amapping area.=0A=0A=
Also fix an off-by-one mistake in is_compat_arg_xlat_range().=0A=0ASigned-o=
ff-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domain.c=0A+=
++ b/xen/arch/x86/domain.c=0A@@ -642,6 +642,14 @@ void arch_domain_destroy(=
struct domain *=0A             free_domheap_page(d->arch.perdomain_l2_pg[i]=
);=0A     free_domheap_page(d->arch.perdomain_l3_pg);=0A =0A+    if ( =
d->arch.arg_xlat_l1_pg )=0A+    {=0A+        for ( i =3D 0; i < PFN_UP(MAX_=
VIRT_CPUS << ARG_XLAT_VA_SHIFT); ++i )=0A+            if ( d->arch.arg_xlat=
_l1_pg[i] )=0A+                free_domheap_page(d->arch.arg_xlat_l1_pg[i])=
;=0A+        xfree(d->arch.arg_xlat_l1_pg);=0A+    }=0A+=0A     free_xenhea=
p_page(d->shared_info);=0A     cleanup_domain_irq_mapping(d);=0A }=0A--- =
a/xen/arch/x86/usercopy.c=0A+++ b/xen/arch/x86/usercopy.c=0A@@ -6,8 +6,8 =
@@=0A  * Copyright 2002 Andi Kleen <ak@suse.de>=0A  */=0A =0A-#include =
<xen/config.h>=0A #include <xen/lib.h>=0A+#include <xen/sched.h>=0A =
#include <asm/uaccess.h>=0A =0A unsigned long __copy_to_user_ll(void =
__user *to, const void *from, unsigned n)=0A--- a/xen/arch/x86/x86_64/mm.c=
=0A+++ b/xen/arch/x86/x86_64/mm.c=0A@@ -832,27 +832,93 @@ void __init =
zap_low_mappings(void)=0A                      __PAGE_HYPERVISOR);=0A }=0A =
=0A-void *compat_arg_xlat_virt_base(void)=0A-{=0A-    return current->arch.=
compat_arg_xlat;=0A-}=0A-=0A int setup_compat_arg_xlat(struct vcpu *v)=0A =
{=0A-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=
=0A+    struct domain *d =3D v->domain;=0A+    struct page_info *pg;=0A+   =
 unsigned int idx, i;=0A+    l1_pgentry_t *l1tab;=0A+=0A+    if ( =
!d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] )=0A+    {=0A+        l3_pgentry_t =
*l3tab;=0A+=0A+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_=
node(d)));=0A+        if ( !pg )=0A+            return -ENOMEM;=0A+        =
clear_domain_page(page_to_mfn(pg));=0A+        d->arch.perdomain_l2_pg[ARG_=
XLAT_SLOT] =3D pg;=0A+=0A+        l3tab =3D __map_domain_page(d->arch.perdo=
main_l3_pg);=0A+        l3tab[l3_table_offset(ARG_XLAT_VIRT_START)] =
=3D=0A+            l3e_from_page(pg, __PAGE_HYPERVISOR);=0A+        =
unmap_domain_page(l3tab);=0A+    }=0A+=0A+    BUILD_BUG_ON((MAX_VIRT_CPUS =
<< ARG_XLAT_VA_SHIFT) >=0A+                 (PERDOMAIN_SLOT_MBYTES << =
20));=0A+=0A+    if ( !d->arch.arg_xlat_l1_pg )=0A+        d->arch.arg_xlat=
_l1_pg =3D xzalloc_array(struct page_info *,=0A+                           =
                    PFN_UP(MAX_VIRT_CPUS <<=0A+                            =
                          ARG_XLAT_VA_SHIFT));=0A+    if ( !d->arch.arg_xla=
t_l1_pg )=0A+        return -ENOMEM;=0A+=0A+    idx =3D l2_table_offset(ARG=
_XLAT_START(v));=0A+    if ( !d->arch.arg_xlat_l1_pg[idx] )=0A+    {=0A+   =
     l2_pgentry_t *l2tab;=0A+=0A+        pg =3D alloc_domheap_page(NULL, =
MEMF_node(domain_to_node(d)));=0A+        if ( !pg )=0A+            return =
-ENOMEM;=0A+        clear_domain_page(page_to_mfn(pg));=0A+        =
d->arch.arg_xlat_l1_pg[idx] =3D pg;=0A+=0A+        l2tab =3D __map_domain_p=
age(d->arch.perdomain_l2_pg[ARG_XLAT_SLOT]);=0A+        l2tab[idx] =3D =
l2e_from_page(pg, __PAGE_HYPERVISOR);=0A+        unmap_domain_page(l2tab);=
=0A+    }=0A =0A-    v->arch.compat_arg_xlat =3D alloc_xenheap_pages(order,=
=0A-                                                  MEMF_node(vcpu_to_nod=
e(v)));=0A+    l1tab =3D __map_domain_page(d->arch.arg_xlat_l1_pg[idx]);=0A=
+    idx =3D l1_table_offset(ARG_XLAT_START(v));=0A+    BUILD_BUG_ON(COMPAT=
_ARG_XLAT_SIZE > (1UL << ARG_XLAT_VA_SHIFT));=0A+    for ( i =3D 0; i < =
PFN_UP(COMPAT_ARG_XLAT_SIZE); ++i )=0A+    {=0A+        pg =3D alloc_domhea=
p_page(NULL, MEMF_node(domain_to_node(d)));=0A+        if ( !pg )=0A+      =
      return -ENOMEM;=0A+        l1tab[idx + i] =3D l1e_from_page(pg, =
__PAGE_HYPERVISOR);=0A+    }=0A+    unmap_domain_page(l1tab);=0A =0A-    =
return v->arch.compat_arg_xlat ? 0 : -ENOMEM;=0A+    return 0;=0A }=0A =0A =
void free_compat_arg_xlat(struct vcpu *v)=0A {=0A-    unsigned int order =
=3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=0A+    struct domain *d =
=3D v->domain;=0A+    unsigned long start =3D ARG_XLAT_START(v);=0A+    =
unsigned long va =3D start + COMPAT_ARG_XLAT_SIZE - 1;=0A+    l1_pgentry_t =
*l1tab =3D=0A+        __map_domain_page(d->arch.arg_xlat_l1_pg[l2_table_off=
set(start)]);=0A+=0A+    do {=0A+        l1_pgentry_t l1e =3D l1tab[l1_tabl=
e_offset(va)];=0A+=0A+        if ( l1e_get_flags(l1e) & _PAGE_PRESENT =
)=0A+        {=0A+            struct page_info *pg =3D l1e_get_page(l1e);=
=0A+=0A+            l1tab[l1_table_offset(va)] =3D l1e_empty();=0A+        =
    flush_tlb_one_mask(d->domain_dirty_cpumask, va);=0A+            =
free_domheap_page(pg);=0A+        }=0A+        va -=3D PAGE_SIZE;=0A+    } =
while ( va >=3D start );=0A =0A-    free_xenheap_pages(v->arch.compat_arg_x=
lat, order);=0A-    v->arch.compat_arg_xlat =3D NULL;=0A+    unmap_domain_p=
age(l1tab);=0A }=0A =0A void cleanup_frame_table(struct mem_hotadd_info =
*info)=0A--- a/xen/include/asm-x86/config.h=0A+++ b/xen/include/asm-x86/con=
fig.h=0A@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]=0A /* =
Slot 260: per-domain mappings (including map cache). */=0A #define =
PERDOMAIN_VIRT_START    (PML4_ADDR(260))=0A #define PERDOMAIN_SLOT_MBYTES  =
 (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))=0A-#define PERDOMAIN_SLOTS   =
      2=0A+#define PERDOMAIN_SLOTS         3=0A #define PERDOMAIN_VIRT_SLOT=
(s)  (PERDOMAIN_VIRT_START + (s) * \=0A                                  =
(PERDOMAIN_SLOT_MBYTES << 20))=0A /* Slot 261: machine-to-phys conversion =
table (256GB). */=0A@@ -304,6 +304,14 @@ extern unsigned long xen_phys_star=
t;=0A #define LDT_VIRT_START(v)    \=0A     (GDT_VIRT_START(v) + (64*1024))=
=0A =0A+/* Argument translation area. The 2nd to last per-domain-mapping =
sub-area. */=0A+#define ARG_XLAT_SLOT            (PERDOMAIN_SLOTS - =
2)=0A+/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 =
pages): */=0A+#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)=0A+#define =
ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(ARG_XLAT_SLOT)=0A+#define =
ARG_XLAT_START(v)        \=0A+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << =
ARG_XLAT_VA_SHIFT))=0A+=0A /* map_domain_page() map cache. The last =
per-domain-mapping sub-area. */=0A #define MAPCACHE_VCPU_ENTRIES    =
(CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS)=0A #define MAPCACHE_ENTRIES  =
       (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)=0A@@ -313,7 +321,7 @@ =
extern unsigned long xen_phys_start;=0A                                   =
MAPCACHE_ENTRIES * PAGE_SIZE)=0A =0A #define PDPT_L1_ENTRIES       \=0A-   =
 ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)=0A+    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 2) - PERDOMAIN_V=
IRT_START) >> PAGE_SHIFT)=0A #define PDPT_L2_ENTRIES       \=0A     =
((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)=0A =
=0A--- a/xen/include/asm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=
=0A@@ -244,6 +244,7 @@ struct arch_domain=0A     void **perdomain_pts;=0A  =
   struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];=0A     struct =
page_info *perdomain_l3_pg;=0A+    struct page_info **arg_xlat_l1_pg;=0A =
=0A     unsigned int hv_compat_vstart;=0A =0A@@ -448,9 +449,6 @@ struct =
arch_vcpu=0A =0A     /* A secondary copy of the vcpu time info. */=0A     =
XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;=0A-=0A-    void =
*compat_arg_xlat;=0A-=0A } __cacheline_aligned;=0A =0A /* Shorthands to =
improve code legibility. */=0A--- a/xen/include/asm-x86/x86_64/uaccess.h=0A=
+++ b/xen/include/asm-x86/x86_64/uaccess.h=0A@@ -1,16 +1,15 @@=0A #ifndef =
__X86_64_UACCESS_H=0A #define __X86_64_UACCESS_H=0A =0A-#define COMPAT_ARG_=
XLAT_VIRT_BASE compat_arg_xlat_virt_base()=0A+#define COMPAT_ARG_XLAT_VIRT_=
BASE ((void *)ARG_XLAT_START(current))=0A #define COMPAT_ARG_XLAT_SIZE     =
 (2*PAGE_SIZE)=0A struct vcpu;=0A-void *compat_arg_xlat_virt_base(void);=0A=
 int setup_compat_arg_xlat(struct vcpu *v);=0A void free_compat_arg_xlat(st=
ruct vcpu *v);=0A #define is_compat_arg_xlat_range(addr, size) ({          =
                     \=0A     unsigned long __off;                         =
                             \=0A     __off =3D (unsigned long)(addr) - =
(unsigned long)COMPAT_ARG_XLAT_VIRT_BASE; \=0A-    (__off <=3D COMPAT_ARG_X=
LAT_SIZE) &&                                        \=0A+    (__off < =
COMPAT_ARG_XLAT_SIZE) &&                                         \=0A     =
((__off + (unsigned long)(size)) <=3D COMPAT_ARG_XLAT_SIZE);               =
 \=0A })=0A =0A
--=__Part20105A37.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

--=__Part20105A37.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 11:44:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:44: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 1U8UZT-0003yy-KI; Thu, 21 Feb 2013 11:44:15 +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 1U8UZS-0003yo-IC
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:44:14 +0000
Received: from [85.158.139.211:45898] by server-8.bemta-5.messagelabs.com id
	9B/50-19075-D8806215; Thu, 21 Feb 2013 11:44:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361447052!18581753!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22610 invoked from network); 21 Feb 2013 11:44:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:44:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8UZN-0006hN-KQ; Thu, 21 Feb 2013 11:44:09 +0000
Date: Thu, 21 Feb 2013 11:44:09 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221114409.GH24051@ocelot.phlegethon.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5126126F02000078000BFD83@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
	failure to set up all vCPU-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

At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
> Otherwise we may leak memory when setting up nHVM fails half way.
> 
> This implies that the individual destroy functions will have to remain
> capable (in the VMX case they first need to be made so, following
> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> that the corresponding init function was never run on.
> 
> Once at it, also clean up some inefficiencies in the corresponding
> parameter validation code.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
>                      rc = -EPERM;
>                      break;
>                  }
> +                if ( !a.value )
> +                    break;

Surely setting from 1 to 0 should either disable nested-hvm entirely
(including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
fresh state every time (& leak the old state).

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:44:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:44: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 1U8UZT-0003yy-KI; Thu, 21 Feb 2013 11:44:15 +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 1U8UZS-0003yo-IC
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:44:14 +0000
Received: from [85.158.139.211:45898] by server-8.bemta-5.messagelabs.com id
	9B/50-19075-D8806215; Thu, 21 Feb 2013 11:44:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361447052!18581753!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22610 invoked from network); 21 Feb 2013 11:44:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 11:44:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8UZN-0006hN-KQ; Thu, 21 Feb 2013 11:44:09 +0000
Date: Thu, 21 Feb 2013 11:44:09 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221114409.GH24051@ocelot.phlegethon.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5126126F02000078000BFD83@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
	failure to set up all vCPU-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

At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
> Otherwise we may leak memory when setting up nHVM fails half way.
> 
> This implies that the individual destroy functions will have to remain
> capable (in the VMX case they first need to be made so, following
> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> that the corresponding init function was never run on.
> 
> Once at it, also clean up some inefficiencies in the corresponding
> parameter validation code.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
>                      rc = -EPERM;
>                      break;
>                  }
> +                if ( !a.value )
> +                    break;

Surely setting from 1 to 0 should either disable nested-hvm entirely
(including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
fresh state every time (& leak the old state).

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:46:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8Uba-00046L-7s; Thu, 21 Feb 2013 11: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.Jackson@eu.citrix.com>) id 1U8UbZ-00046C-3y
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:46:25 +0000
Received: from [193.109.254.147:25338] by server-11.bemta-14.messagelabs.com
	id F4/8D-30685-01906215; Thu, 21 Feb 2013 11:46:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361447176!9023288!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3477 invoked from network); 21 Feb 2013 11:46:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:46:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1727981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:46: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.297.1; Thu, 21 Feb 2013 11:46:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8UbQ-0001OR-8V; Thu, 21 Feb 2013 11:46:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8UbQ-0001bv-2u;
	Thu, 21 Feb 2013 11:46:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.2311.974537.641742@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 11:46:15 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>,
	<20774.545.470486.189832@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<20774.545.470486.189832@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Moving xen*.hg to git [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 Jackson writes ("Moving xen*.hg to git"):
> The process will be as follows:
>   1. Autotester push gate shut down
>   2. Announcement and coordination with committers
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped
>   5. git tree made writeable by committers.

These have all been done.  Committers may now push to the staging
branches.

You should
  git clone xenbits.xen.org:/home/xen/git/xen.git xen.git
and then
  git checkout staging

There is a safety catch which will reject attempts to push to
non-staging branches (and also reject bare ref tags).

>   6. git->hg mirror outputs checked for sanity
>   7. git->hg mirror enabled, pointing at old hg trees
>   8. Autotester push gate told to use git and restarted

We are working on these.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:46:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8Uba-00046L-7s; Thu, 21 Feb 2013 11: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.Jackson@eu.citrix.com>) id 1U8UbZ-00046C-3y
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:46:25 +0000
Received: from [193.109.254.147:25338] by server-11.bemta-14.messagelabs.com
	id F4/8D-30685-01906215; Thu, 21 Feb 2013 11:46:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361447176!9023288!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3477 invoked from network); 21 Feb 2013 11:46:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:46:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1727981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:46: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.297.1; Thu, 21 Feb 2013 11:46:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8UbQ-0001OR-8V; Thu, 21 Feb 2013 11:46:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8UbQ-0001bv-2u;
	Thu, 21 Feb 2013 11:46:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.2311.974537.641742@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 11:46:15 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>,
	<20774.545.470486.189832@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<20774.545.470486.189832@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Moving xen*.hg to git [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 Jackson writes ("Moving xen*.hg to git"):
> The process will be as follows:
>   1. Autotester push gate shut down
>   2. Announcement and coordination with committers
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped
>   5. git tree made writeable by committers.

These have all been done.  Committers may now push to the staging
branches.

You should
  git clone xenbits.xen.org:/home/xen/git/xen.git xen.git
and then
  git checkout staging

There is a safety catch which will reject attempts to push to
non-staging branches (and also reject bare ref tags).

>   6. git->hg mirror outputs checked for sanity
>   7. git->hg mirror enabled, pointing at old hg trees
>   8. Autotester push gate told to use git and restarted

We are working on these.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:46:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:46: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 1U8Ubh-00047G-MZ; Thu, 21 Feb 2013 11:46: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 1U8Ubf-00046u-Uw
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:46:32 +0000
Received: from [85.158.137.99:28324] by server-5.bemta-3.messagelabs.com id
	D3/9E-04457-71906215; Thu, 21 Feb 2013 11:46:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361447190!17401487!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17425 invoked from network); 21 Feb 2013 11:46:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:46:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1727988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:46: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.297.1; Thu, 21 Feb 2013 11:46:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8Ubd-0001OX-Ke; Thu, 21 Feb 2013 11:46:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8Ubd-0001bz-G7;
	Thu, 21 Feb 2013 11:46:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.2325.377978.550548@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 11:46:29 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361444391-23892-1-git-send-email-ian.campbell@citrix.com>
References: <1361444391-23892-1-git-send-email-ian.campbell@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] libxl: fix build on 32-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SWFuIENhbXBiZWxsIHdyaXRlcyAoIltQQVRDSF0gbGlieGw6IGZpeCBidWlsZCBvbiAzMi1iaXQi
KToKPiBhYWI0ZDFiMjY2Y2UgImxpYnhsOiBBZGQgcXhsIHZnYSBpbnRlcmZhY2Ugc3VwcG9ydCBm
b3IgdXBzdHJlYW0gcWVtdSIKPiBpbnRyb2R1Y2VkOgo+IAlsaWJ4bF9kbS5jOiBJbiBmdW5jdGlv
biDigJhsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV34oCZOgo+IAlsaWJ4bF9kbS5j
OjQ0OTogZXJyb3I6IGZvcm1hdCDigJglbHXigJkgZXhwZWN0cyB0eXBlIOKAmGxvbmcgdW5zaWdu
ZWQgaW504oCZLCBidXQgYXJndW1lbnQgMyBoYXMgdHlwZSDigJhsb25nIGxvbmcgdW5zaWduZWQg
aW504oCZCj4gCWxpYnhsX2RtLmM6NDUxOiBlcnJvcjogZm9ybWF0IOKAmCVsdeKAmSBleHBlY3Rz
IHR5cGUg4oCYbG9uZyB1bnNpZ25lZCBpbnTigJksIGJ1dCBhcmd1bWVudCAzIGhhcyB0eXBlIOKA
mGxvbmcgbG9uZyB1bnNpZ25lZCBpbnTigJkKPiAKPiBvbiBhcm0zMiBhbmQgeDg2XzMyLgo+IAo+
IFVzZSB0aGUgaW50dHlwZXMuaCBQUklkNjQgbWFjcm8uCj4gCj4gU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCkFwcGxpZWQsIHRoYW5rcy4KCklh
bi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:46:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:46: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 1U8Ubh-00047G-MZ; Thu, 21 Feb 2013 11:46: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 1U8Ubf-00046u-Uw
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:46:32 +0000
Received: from [85.158.137.99:28324] by server-5.bemta-3.messagelabs.com id
	D3/9E-04457-71906215; Thu, 21 Feb 2013 11:46:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361447190!17401487!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17425 invoked from network); 21 Feb 2013 11:46:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:46:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1727988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:46: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.297.1; Thu, 21 Feb 2013 11:46:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8Ubd-0001OX-Ke; Thu, 21 Feb 2013 11:46:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8Ubd-0001bz-G7;
	Thu, 21 Feb 2013 11:46:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.2325.377978.550548@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 11:46:29 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361444391-23892-1-git-send-email-ian.campbell@citrix.com>
References: <1361444391-23892-1-git-send-email-ian.campbell@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] libxl: fix build on 32-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SWFuIENhbXBiZWxsIHdyaXRlcyAoIltQQVRDSF0gbGlieGw6IGZpeCBidWlsZCBvbiAzMi1iaXQi
KToKPiBhYWI0ZDFiMjY2Y2UgImxpYnhsOiBBZGQgcXhsIHZnYSBpbnRlcmZhY2Ugc3VwcG9ydCBm
b3IgdXBzdHJlYW0gcWVtdSIKPiBpbnRyb2R1Y2VkOgo+IAlsaWJ4bF9kbS5jOiBJbiBmdW5jdGlv
biDigJhsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsX2FyZ3NfbmV34oCZOgo+IAlsaWJ4bF9kbS5j
OjQ0OTogZXJyb3I6IGZvcm1hdCDigJglbHXigJkgZXhwZWN0cyB0eXBlIOKAmGxvbmcgdW5zaWdu
ZWQgaW504oCZLCBidXQgYXJndW1lbnQgMyBoYXMgdHlwZSDigJhsb25nIGxvbmcgdW5zaWduZWQg
aW504oCZCj4gCWxpYnhsX2RtLmM6NDUxOiBlcnJvcjogZm9ybWF0IOKAmCVsdeKAmSBleHBlY3Rz
IHR5cGUg4oCYbG9uZyB1bnNpZ25lZCBpbnTigJksIGJ1dCBhcmd1bWVudCAzIGhhcyB0eXBlIOKA
mGxvbmcgbG9uZyB1bnNpZ25lZCBpbnTigJkKPiAKPiBvbiBhcm0zMiBhbmQgeDg2XzMyLgo+IAo+
IFVzZSB0aGUgaW50dHlwZXMuaCBQUklkNjQgbWFjcm8uCj4gCj4gU2lnbmVkLW9mZi1ieTogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KCkFwcGxpZWQsIHRoYW5rcy4KCklh
bi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:53:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:53: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 1U8UiQ-0004V6-LF; Thu, 21 Feb 2013 11:53: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 1U8UiP-0004V1-Q4
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:53:29 +0000
Received: from [85.158.138.51:22922] by server-5.bemta-3.messagelabs.com id
	FD/89-04457-4BA06215; Thu, 21 Feb 2013 11:53:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361447603!28455725!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28463 invoked from network); 21 Feb 2013 11:53:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:53:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1728234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11: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.297.1;
	Thu, 21 Feb 2013 11:53:23 +0000
Message-ID: <1361447602.26546.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 21 Feb 2013 11:53:22 +0000
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
> As previously agreed, we will be moving the main Xen trees to git.

Are we going to continue with the "Committed-by:" tag? git already
tracks this bit of metadata separately from the author so it seems a bit
redundant. It might be useful for folks using the mirror but in reality
I expect it will mostly be the committers who need to look this up, and
they will be using git...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:53:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11:53: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 1U8UiQ-0004V6-LF; Thu, 21 Feb 2013 11:53: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 1U8UiP-0004V1-Q4
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:53:29 +0000
Received: from [85.158.138.51:22922] by server-5.bemta-3.messagelabs.com id
	FD/89-04457-4BA06215; Thu, 21 Feb 2013 11:53:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361447603!28455725!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28463 invoked from network); 21 Feb 2013 11:53:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:53:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1728234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11: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.297.1;
	Thu, 21 Feb 2013 11:53:23 +0000
Message-ID: <1361447602.26546.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 21 Feb 2013 11:53:22 +0000
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
> As previously agreed, we will be moving the main Xen trees to git.

Are we going to continue with the "Committed-by:" tag? git already
tracks this bit of metadata separately from the author so it seems a bit
redundant. It might be useful for folks using the mirror but in reality
I expect it will mostly be the committers who need to look this up, and
they will be using git...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8UjB-0004Yo-4i; Thu, 21 Feb 2013 11:54: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 1U8Uj9-0004Yd-6F
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:54:15 +0000
Received: from [193.109.254.147:49494] by server-16.bemta-14.messagelabs.com
	id 2A/F6-25906-6EA06215; Thu, 21 Feb 2013 11:54:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361447592!1925253!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 21 Feb 2013 11:53:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:53:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1728225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:53: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.297.1;
	Thu, 21 Feb 2013 11:53:12 +0000
Message-ID: <1361447591.26546.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 21 Feb 2013 11:53:11 +0000
In-Reply-To: <20774.2311.974537.641742@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<20774.545.470486.189832@mariner.uk.xensource.com>
	<20774.2311.974537.641742@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git [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, 2013-02-21 at 11:46 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Moving xen*.hg to git"):
> > The process will be as follows:
> >   1. Autotester push gate shut down
> >   2. Announcement and coordination with committers
> >   3. hg trees made read-only (other than by forthcoming git->hg mirror)
> >   4. hg->git mirroring process stopped
> >   5. git tree made writeable by committers.
> 
> These have all been done.  Committers may now push to the staging
> branches.
> 
> You should
>   git clone xenbits.xen.org:/home/xen/git/xen.git xen.git
> and then
>   git checkout staging
> 
> There is a safety catch which will reject attempts to push to
> non-staging branches (and also reject bare ref tags).
> 
> >   6. git->hg mirror outputs checked for sanity
> >   7. git->hg mirror enabled, pointing at old hg trees
> >   8. Autotester push gate told to use git and restarted
> 
> We are working on these.

Is the commit mailer bot thing on your list?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 11:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 11: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 1U8UjB-0004Yo-4i; Thu, 21 Feb 2013 11:54: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 1U8Uj9-0004Yd-6F
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 11:54:15 +0000
Received: from [193.109.254.147:49494] by server-16.bemta-14.messagelabs.com
	id 2A/F6-25906-6EA06215; Thu, 21 Feb 2013 11:54:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361447592!1925253!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16998 invoked from network); 21 Feb 2013 11:53:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 11:53:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1728225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 11:53: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.297.1;
	Thu, 21 Feb 2013 11:53:12 +0000
Message-ID: <1361447591.26546.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 21 Feb 2013 11:53:11 +0000
In-Reply-To: <20774.2311.974537.641742@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<20774.545.470486.189832@mariner.uk.xensource.com>
	<20774.2311.974537.641742@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git [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, 2013-02-21 at 11:46 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Moving xen*.hg to git"):
> > The process will be as follows:
> >   1. Autotester push gate shut down
> >   2. Announcement and coordination with committers
> >   3. hg trees made read-only (other than by forthcoming git->hg mirror)
> >   4. hg->git mirroring process stopped
> >   5. git tree made writeable by committers.
> 
> These have all been done.  Committers may now push to the staging
> branches.
> 
> You should
>   git clone xenbits.xen.org:/home/xen/git/xen.git xen.git
> and then
>   git checkout staging
> 
> There is a safety catch which will reject attempts to push to
> non-staging branches (and also reject bare ref tags).
> 
> >   6. git->hg mirror outputs checked for sanity
> >   7. git->hg mirror enabled, pointing at old hg trees
> >   8. Autotester push gate told to use git and restarted
> 
> We are working on these.

Is the commit mailer bot thing on your list?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:09:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:09: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 1U8UxN-000584-LA; Thu, 21 Feb 2013 12:08: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 1U8UxL-00057x-Ev
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:08:55 +0000
Received: from [193.109.254.147:60571] by server-4.bemta-14.messagelabs.com id
	B4/3A-20719-65E06215; Thu, 21 Feb 2013 12:08:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361448532!9153882!1
X-Originating-IP: [74.125.82.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10193 invoked from network); 21 Feb 2013 12:08:53 -0000
Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com)
	(74.125.82.174)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:08:53 -0000
Received: by mail-we0-f174.google.com with SMTP id r6so7513510wey.19
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 04:08:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aBQmWAX9O7XgzXRjqV0IO+ni9aaTa5Qk1/K0+Yil8is=;
	b=KSjYzp2YFboscfGEAZApesyeORS9mUGHW9d9SuDKTkxnPCYJ/22CHaBvBd4C5uMqbA
	v2QApRbE3WNBYwucIxwK5928N3Syi8s1gVFVJQ1f4YyrwW7OG2VwoYmRKlcBc3wF9rSm
	hEOYoG2MjvRMLcu3I5ANHZMbOMuwNP1206fFeN5qYt7WXAiSfZnfMno2wjqa80irz0RC
	gB+Jr5ZrAjalTIkNS+Td/+3+81DU4Im3zWKFWh7WgJ5hT+povCfPed5sA10TSjol1Jvi
	cv/5nl98Qx7r0zHGQZDxekUkZbV+mR6wwo7WWQFut3uU3O10u8a4YXUq4wWyGK5E/enz
	4epQ==
X-Received: by 10.180.98.98 with SMTP id eh2mr41080843wib.7.1361448531985;
	Thu, 21 Feb 2013 04:08:51 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id n10sm39712482wia.0.2013.02.21.04.08.49
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 04:08:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 12:08:46 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD4BBECE.5C34E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: rework hypercall argument translation
	area setup
Thread-Index: Ac4QLDL3Pm4uVhVtY0mDkpwWrmZ3jg==
In-Reply-To: <5126163702000078000BFDA4@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/02/2013 11:42, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than using an order-1 Xen heap allocation, use (currently 2)
> individual domain heap pages to populate space in the per-domain
> mapping area.
> 
> Also fix an off-by-one mistake in is_compat_arg_xlat_range().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Well, fine in principle. This manual setup/teardown of l2/l1 pagetables in
the perdomain area is getting a bit tiresome though isn't it? Isn't there
some setup helper that could be abstracted out for all users, and perhaps
even some automated teardown-and-freeing on domain destroy? I just sighed
when I saw more skanky pagetable manipulation for what is a conceptually
simple change.

 -- Keir

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -642,6 +642,14 @@ void arch_domain_destroy(struct domain *
>              free_domheap_page(d->arch.perdomain_l2_pg[i]);
>      free_domheap_page(d->arch.perdomain_l3_pg);
>  
> +    if ( d->arch.arg_xlat_l1_pg )
> +    {
> +        for ( i = 0; i < PFN_UP(MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT); ++i )
> +            if ( d->arch.arg_xlat_l1_pg[i] )
> +                free_domheap_page(d->arch.arg_xlat_l1_pg[i]);
> +        xfree(d->arch.arg_xlat_l1_pg);
> +    }
> +
>      free_xenheap_page(d->shared_info);
>      cleanup_domain_irq_mapping(d);
>  }
> --- a/xen/arch/x86/usercopy.c
> +++ b/xen/arch/x86/usercopy.c
> @@ -6,8 +6,8 @@
>   * Copyright 2002 Andi Kleen <ak@suse.de>
>   */
>  
> -#include <xen/config.h>
>  #include <xen/lib.h>
> +#include <xen/sched.h>
>  #include <asm/uaccess.h>
>  
>  unsigned long __copy_to_user_ll(void __user *to, const void *from, unsigned
> n)
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -832,27 +832,93 @@ void __init zap_low_mappings(void)
>                       __PAGE_HYPERVISOR);
>  }
>  
> -void *compat_arg_xlat_virt_base(void)
> -{
> -    return current->arch.compat_arg_xlat;
> -}
> -
>  int setup_compat_arg_xlat(struct vcpu *v)
>  {
> -    unsigned int order = get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
> +    struct domain *d = v->domain;
> +    struct page_info *pg;
> +    unsigned int idx, i;
> +    l1_pgentry_t *l1tab;
> +
> +    if ( !d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] )
> +    {
> +        l3_pgentry_t *l3tab;
> +
> +        pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> +        if ( !pg )
> +            return -ENOMEM;
> +        clear_domain_page(page_to_mfn(pg));
> +        d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] = pg;
> +
> +        l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
> +        l3tab[l3_table_offset(ARG_XLAT_VIRT_START)] =
> +            l3e_from_page(pg, __PAGE_HYPERVISOR);
> +        unmap_domain_page(l3tab);
> +    }
> +
> +    BUILD_BUG_ON((MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT) >
> +                 (PERDOMAIN_SLOT_MBYTES << 20));
> +
> +    if ( !d->arch.arg_xlat_l1_pg )
> +        d->arch.arg_xlat_l1_pg = xzalloc_array(struct page_info *,
> +                                               PFN_UP(MAX_VIRT_CPUS <<
> +                                                      ARG_XLAT_VA_SHIFT));
> +    if ( !d->arch.arg_xlat_l1_pg )
> +        return -ENOMEM;
> +
> +    idx = l2_table_offset(ARG_XLAT_START(v));
> +    if ( !d->arch.arg_xlat_l1_pg[idx] )
> +    {
> +        l2_pgentry_t *l2tab;
> +
> +        pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> +        if ( !pg )
> +            return -ENOMEM;
> +        clear_domain_page(page_to_mfn(pg));
> +        d->arch.arg_xlat_l1_pg[idx] = pg;
> +
> +        l2tab = __map_domain_page(d->arch.perdomain_l2_pg[ARG_XLAT_SLOT]);
> +        l2tab[idx] = l2e_from_page(pg, __PAGE_HYPERVISOR);
> +        unmap_domain_page(l2tab);
> +    }
>  
> -    v->arch.compat_arg_xlat = alloc_xenheap_pages(order,
> -                
> MEMF_node(vcpu_to_node(v)));
> +    l1tab = __map_domain_page(d->arch.arg_xlat_l1_pg[idx]);
> +    idx = l1_table_offset(ARG_XLAT_START(v));
> +    BUILD_BUG_ON(COMPAT_ARG_XLAT_SIZE > (1UL << ARG_XLAT_VA_SHIFT));
> +    for ( i = 0; i < PFN_UP(COMPAT_ARG_XLAT_SIZE); ++i )
> +    {
> +        pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> +        if ( !pg )
> +            return -ENOMEM;
> +        l1tab[idx + i] = l1e_from_page(pg, __PAGE_HYPERVISOR);
> +    }
> +    unmap_domain_page(l1tab);
>  
> -    return v->arch.compat_arg_xlat ? 0 : -ENOMEM;
> +    return 0;
>  }
>  
>  void free_compat_arg_xlat(struct vcpu *v)
>  {
> -    unsigned int order = get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
> +    struct domain *d = v->domain;
> +    unsigned long start = ARG_XLAT_START(v);
> +    unsigned long va = start + COMPAT_ARG_XLAT_SIZE - 1;
> +    l1_pgentry_t *l1tab =
> +        __map_domain_page(d->arch.arg_xlat_l1_pg[l2_table_offset(start)]);
> +
> +    do {
> +        l1_pgentry_t l1e = l1tab[l1_table_offset(va)];
> +
> +        if ( l1e_get_flags(l1e) & _PAGE_PRESENT )
> +        {
> +            struct page_info *pg = l1e_get_page(l1e);
> +
> +            l1tab[l1_table_offset(va)] = l1e_empty();
> +            flush_tlb_one_mask(d->domain_dirty_cpumask, va);
> +            free_domheap_page(pg);
> +        }
> +        va -= PAGE_SIZE;
> +    } while ( va >= start );
>  
> -    free_xenheap_pages(v->arch.compat_arg_xlat, order);
> -    v->arch.compat_arg_xlat = NULL;
> +    unmap_domain_page(l1tab);
>  }
>  
>  void cleanup_frame_table(struct mem_hotadd_info *info)
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]
>  /* Slot 260: per-domain mappings (including map cache). */
>  #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
>  #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))
> -#define PERDOMAIN_SLOTS         2
> +#define PERDOMAIN_SLOTS         3
>  #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
>                                   (PERDOMAIN_SLOT_MBYTES << 20))
>  /* Slot 261: machine-to-phys conversion table (256GB). */
> @@ -304,6 +304,14 @@ extern unsigned long xen_phys_start;
>  #define LDT_VIRT_START(v)    \
>      (GDT_VIRT_START(v) + (64*1024))
>  
> +/* Argument translation area. The 2nd to last per-domain-mapping sub-area. */
> +#define ARG_XLAT_SLOT            (PERDOMAIN_SLOTS - 2)
> +/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 pages): */
> +#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)
> +#define ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(ARG_XLAT_SLOT)
> +#define ARG_XLAT_START(v)        \
> +    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
> +
>  /* map_domain_page() map cache. The last per-domain-mapping sub-area. */
>  #define MAPCACHE_VCPU_ENTRIES    (CONFIG_PAGING_LEVELS *
> CONFIG_PAGING_LEVELS)
>  #define MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)
> @@ -313,7 +321,7 @@ extern unsigned long xen_phys_start;
>                                    MAPCACHE_ENTRIES * PAGE_SIZE)
>  
>  #define PDPT_L1_ENTRIES       \
> -    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >>
> PAGE_SHIFT)
> +    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 2) - PERDOMAIN_VIRT_START) >>
> PAGE_SHIFT)
>  #define PDPT_L2_ENTRIES       \
>      ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)
>  
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -244,6 +244,7 @@ struct arch_domain
>      void **perdomain_pts;
>      struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];
>      struct page_info *perdomain_l3_pg;
> +    struct page_info **arg_xlat_l1_pg;
>  
>      unsigned int hv_compat_vstart;
>  
> @@ -448,9 +449,6 @@ struct arch_vcpu
>  
>      /* A secondary copy of the vcpu time info. */
>      XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
> -
> -    void *compat_arg_xlat;
> -
>  } __cacheline_aligned;
>  
>  /* Shorthands to improve code legibility. */
> --- a/xen/include/asm-x86/x86_64/uaccess.h
> +++ b/xen/include/asm-x86/x86_64/uaccess.h
> @@ -1,16 +1,15 @@
>  #ifndef __X86_64_UACCESS_H
>  #define __X86_64_UACCESS_H
>  
> -#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()
> +#define COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))
>  #define COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)
>  struct vcpu;
> -void *compat_arg_xlat_virt_base(void);
>  int setup_compat_arg_xlat(struct vcpu *v);
>  void free_compat_arg_xlat(struct vcpu *v);
>  #define is_compat_arg_xlat_range(addr, size) ({
> \
>      unsigned long __off;
> \
>      __off = (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_BASE;
> \
> -    (__off <= COMPAT_ARG_XLAT_SIZE) &&
> \
> +    (__off < COMPAT_ARG_XLAT_SIZE) &&
> \
>      ((__off + (unsigned long)(size)) <= COMPAT_ARG_XLAT_SIZE);
> \
>  })
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 21 12:09:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:09: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 1U8UxN-000584-LA; Thu, 21 Feb 2013 12:08: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 1U8UxL-00057x-Ev
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:08:55 +0000
Received: from [193.109.254.147:60571] by server-4.bemta-14.messagelabs.com id
	B4/3A-20719-65E06215; Thu, 21 Feb 2013 12:08:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361448532!9153882!1
X-Originating-IP: [74.125.82.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10193 invoked from network); 21 Feb 2013 12:08:53 -0000
Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com)
	(74.125.82.174)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:08:53 -0000
Received: by mail-we0-f174.google.com with SMTP id r6so7513510wey.19
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 04:08:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aBQmWAX9O7XgzXRjqV0IO+ni9aaTa5Qk1/K0+Yil8is=;
	b=KSjYzp2YFboscfGEAZApesyeORS9mUGHW9d9SuDKTkxnPCYJ/22CHaBvBd4C5uMqbA
	v2QApRbE3WNBYwucIxwK5928N3Syi8s1gVFVJQ1f4YyrwW7OG2VwoYmRKlcBc3wF9rSm
	hEOYoG2MjvRMLcu3I5ANHZMbOMuwNP1206fFeN5qYt7WXAiSfZnfMno2wjqa80irz0RC
	gB+Jr5ZrAjalTIkNS+Td/+3+81DU4Im3zWKFWh7WgJ5hT+povCfPed5sA10TSjol1Jvi
	cv/5nl98Qx7r0zHGQZDxekUkZbV+mR6wwo7WWQFut3uU3O10u8a4YXUq4wWyGK5E/enz
	4epQ==
X-Received: by 10.180.98.98 with SMTP id eh2mr41080843wib.7.1361448531985;
	Thu, 21 Feb 2013 04:08:51 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id n10sm39712482wia.0.2013.02.21.04.08.49
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 04:08:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 12:08:46 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD4BBECE.5C34E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: rework hypercall argument translation
	area setup
Thread-Index: Ac4QLDL3Pm4uVhVtY0mDkpwWrmZ3jg==
In-Reply-To: <5126163702000078000BFDA4@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/02/2013 11:42, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than using an order-1 Xen heap allocation, use (currently 2)
> individual domain heap pages to populate space in the per-domain
> mapping area.
> 
> Also fix an off-by-one mistake in is_compat_arg_xlat_range().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Well, fine in principle. This manual setup/teardown of l2/l1 pagetables in
the perdomain area is getting a bit tiresome though isn't it? Isn't there
some setup helper that could be abstracted out for all users, and perhaps
even some automated teardown-and-freeing on domain destroy? I just sighed
when I saw more skanky pagetable manipulation for what is a conceptually
simple change.

 -- Keir

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -642,6 +642,14 @@ void arch_domain_destroy(struct domain *
>              free_domheap_page(d->arch.perdomain_l2_pg[i]);
>      free_domheap_page(d->arch.perdomain_l3_pg);
>  
> +    if ( d->arch.arg_xlat_l1_pg )
> +    {
> +        for ( i = 0; i < PFN_UP(MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT); ++i )
> +            if ( d->arch.arg_xlat_l1_pg[i] )
> +                free_domheap_page(d->arch.arg_xlat_l1_pg[i]);
> +        xfree(d->arch.arg_xlat_l1_pg);
> +    }
> +
>      free_xenheap_page(d->shared_info);
>      cleanup_domain_irq_mapping(d);
>  }
> --- a/xen/arch/x86/usercopy.c
> +++ b/xen/arch/x86/usercopy.c
> @@ -6,8 +6,8 @@
>   * Copyright 2002 Andi Kleen <ak@suse.de>
>   */
>  
> -#include <xen/config.h>
>  #include <xen/lib.h>
> +#include <xen/sched.h>
>  #include <asm/uaccess.h>
>  
>  unsigned long __copy_to_user_ll(void __user *to, const void *from, unsigned
> n)
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -832,27 +832,93 @@ void __init zap_low_mappings(void)
>                       __PAGE_HYPERVISOR);
>  }
>  
> -void *compat_arg_xlat_virt_base(void)
> -{
> -    return current->arch.compat_arg_xlat;
> -}
> -
>  int setup_compat_arg_xlat(struct vcpu *v)
>  {
> -    unsigned int order = get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
> +    struct domain *d = v->domain;
> +    struct page_info *pg;
> +    unsigned int idx, i;
> +    l1_pgentry_t *l1tab;
> +
> +    if ( !d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] )
> +    {
> +        l3_pgentry_t *l3tab;
> +
> +        pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> +        if ( !pg )
> +            return -ENOMEM;
> +        clear_domain_page(page_to_mfn(pg));
> +        d->arch.perdomain_l2_pg[ARG_XLAT_SLOT] = pg;
> +
> +        l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
> +        l3tab[l3_table_offset(ARG_XLAT_VIRT_START)] =
> +            l3e_from_page(pg, __PAGE_HYPERVISOR);
> +        unmap_domain_page(l3tab);
> +    }
> +
> +    BUILD_BUG_ON((MAX_VIRT_CPUS << ARG_XLAT_VA_SHIFT) >
> +                 (PERDOMAIN_SLOT_MBYTES << 20));
> +
> +    if ( !d->arch.arg_xlat_l1_pg )
> +        d->arch.arg_xlat_l1_pg = xzalloc_array(struct page_info *,
> +                                               PFN_UP(MAX_VIRT_CPUS <<
> +                                                      ARG_XLAT_VA_SHIFT));
> +    if ( !d->arch.arg_xlat_l1_pg )
> +        return -ENOMEM;
> +
> +    idx = l2_table_offset(ARG_XLAT_START(v));
> +    if ( !d->arch.arg_xlat_l1_pg[idx] )
> +    {
> +        l2_pgentry_t *l2tab;
> +
> +        pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> +        if ( !pg )
> +            return -ENOMEM;
> +        clear_domain_page(page_to_mfn(pg));
> +        d->arch.arg_xlat_l1_pg[idx] = pg;
> +
> +        l2tab = __map_domain_page(d->arch.perdomain_l2_pg[ARG_XLAT_SLOT]);
> +        l2tab[idx] = l2e_from_page(pg, __PAGE_HYPERVISOR);
> +        unmap_domain_page(l2tab);
> +    }
>  
> -    v->arch.compat_arg_xlat = alloc_xenheap_pages(order,
> -                
> MEMF_node(vcpu_to_node(v)));
> +    l1tab = __map_domain_page(d->arch.arg_xlat_l1_pg[idx]);
> +    idx = l1_table_offset(ARG_XLAT_START(v));
> +    BUILD_BUG_ON(COMPAT_ARG_XLAT_SIZE > (1UL << ARG_XLAT_VA_SHIFT));
> +    for ( i = 0; i < PFN_UP(COMPAT_ARG_XLAT_SIZE); ++i )
> +    {
> +        pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
> +        if ( !pg )
> +            return -ENOMEM;
> +        l1tab[idx + i] = l1e_from_page(pg, __PAGE_HYPERVISOR);
> +    }
> +    unmap_domain_page(l1tab);
>  
> -    return v->arch.compat_arg_xlat ? 0 : -ENOMEM;
> +    return 0;
>  }
>  
>  void free_compat_arg_xlat(struct vcpu *v)
>  {
> -    unsigned int order = get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
> +    struct domain *d = v->domain;
> +    unsigned long start = ARG_XLAT_START(v);
> +    unsigned long va = start + COMPAT_ARG_XLAT_SIZE - 1;
> +    l1_pgentry_t *l1tab =
> +        __map_domain_page(d->arch.arg_xlat_l1_pg[l2_table_offset(start)]);
> +
> +    do {
> +        l1_pgentry_t l1e = l1tab[l1_table_offset(va)];
> +
> +        if ( l1e_get_flags(l1e) & _PAGE_PRESENT )
> +        {
> +            struct page_info *pg = l1e_get_page(l1e);
> +
> +            l1tab[l1_table_offset(va)] = l1e_empty();
> +            flush_tlb_one_mask(d->domain_dirty_cpumask, va);
> +            free_domheap_page(pg);
> +        }
> +        va -= PAGE_SIZE;
> +    } while ( va >= start );
>  
> -    free_xenheap_pages(v->arch.compat_arg_xlat, order);
> -    v->arch.compat_arg_xlat = NULL;
> +    unmap_domain_page(l1tab);
>  }
>  
>  void cleanup_frame_table(struct mem_hotadd_info *info)
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]
>  /* Slot 260: per-domain mappings (including map cache). */
>  #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
>  #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))
> -#define PERDOMAIN_SLOTS         2
> +#define PERDOMAIN_SLOTS         3
>  #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
>                                   (PERDOMAIN_SLOT_MBYTES << 20))
>  /* Slot 261: machine-to-phys conversion table (256GB). */
> @@ -304,6 +304,14 @@ extern unsigned long xen_phys_start;
>  #define LDT_VIRT_START(v)    \
>      (GDT_VIRT_START(v) + (64*1024))
>  
> +/* Argument translation area. The 2nd to last per-domain-mapping sub-area. */
> +#define ARG_XLAT_SLOT            (PERDOMAIN_SLOTS - 2)
> +/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 pages): */
> +#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)
> +#define ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(ARG_XLAT_SLOT)
> +#define ARG_XLAT_START(v)        \
> +    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
> +
>  /* map_domain_page() map cache. The last per-domain-mapping sub-area. */
>  #define MAPCACHE_VCPU_ENTRIES    (CONFIG_PAGING_LEVELS *
> CONFIG_PAGING_LEVELS)
>  #define MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)
> @@ -313,7 +321,7 @@ extern unsigned long xen_phys_start;
>                                    MAPCACHE_ENTRIES * PAGE_SIZE)
>  
>  #define PDPT_L1_ENTRIES       \
> -    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >>
> PAGE_SHIFT)
> +    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 2) - PERDOMAIN_VIRT_START) >>
> PAGE_SHIFT)
>  #define PDPT_L2_ENTRIES       \
>      ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)
>  
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -244,6 +244,7 @@ struct arch_domain
>      void **perdomain_pts;
>      struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];
>      struct page_info *perdomain_l3_pg;
> +    struct page_info **arg_xlat_l1_pg;
>  
>      unsigned int hv_compat_vstart;
>  
> @@ -448,9 +449,6 @@ struct arch_vcpu
>  
>      /* A secondary copy of the vcpu time info. */
>      XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
> -
> -    void *compat_arg_xlat;
> -
>  } __cacheline_aligned;
>  
>  /* Shorthands to improve code legibility. */
> --- a/xen/include/asm-x86/x86_64/uaccess.h
> +++ b/xen/include/asm-x86/x86_64/uaccess.h
> @@ -1,16 +1,15 @@
>  #ifndef __X86_64_UACCESS_H
>  #define __X86_64_UACCESS_H
>  
> -#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()
> +#define COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))
>  #define COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)
>  struct vcpu;
> -void *compat_arg_xlat_virt_base(void);
>  int setup_compat_arg_xlat(struct vcpu *v);
>  void free_compat_arg_xlat(struct vcpu *v);
>  #define is_compat_arg_xlat_range(addr, size) ({
> \
>      unsigned long __off;
> \
>      __off = (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_BASE;
> \
> -    (__off <= COMPAT_ARG_XLAT_SIZE) &&
> \
> +    (__off < COMPAT_ARG_XLAT_SIZE) &&
> \
>      ((__off + (unsigned long)(size)) <= COMPAT_ARG_XLAT_SIZE);
> \
>  })
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 21 12:19:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8V6l-0005Mb-RX; Thu, 21 Feb 2013 12:18: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 1U8V6k-0005MW-CJ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:18:38 +0000
Received: from [85.158.143.99:61454] by server-1.bemta-4.messagelabs.com id
	90/56-06203-D9016215; Thu, 21 Feb 2013 12:18:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361449117!28038961!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8517 invoked from network); 21 Feb 2013 12:18:37 -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; 21 Feb 2013 12:18:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:18:36 +0000
Message-Id: <51261EE702000078000BFE06@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:19:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
	<20130221114409.GH24051@ocelot.phlegethon.org>
In-Reply-To: <20130221114409.GH24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
 failure to set up all vCPU-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 21.02.13 at 12:44, Tim Deegan <tim@xen.org> wrote:
> At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
>> Otherwise we may leak memory when setting up nHVM fails half way.
>> 
>> This implies that the individual destroy functions will have to remain
>> capable (in the VMX case they first need to be made so, following
>> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
>> that the corresponding init function was never run on.
>> 
>> Once at it, also clean up some inefficiencies in the corresponding
>> parameter validation code.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
>> 
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
>>                      rc = -EPERM;
>>                      break;
>>                  }
>> +                if ( !a.value )
>> +                    break;
> 
> Surely setting from 1 to 0 should either disable nested-hvm entirely
> (including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
> alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
> fresh state every time (& leak the old state).

No, that's precisely not the case with this patch (but was before
in case of failure on other than the first vCPU).

Of course we can _change_ to the model of fully disabling nHVM
in that case, but honestly I don't see the point, and the code is
simpler without doing so.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:19:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8V6l-0005Mb-RX; Thu, 21 Feb 2013 12:18: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 1U8V6k-0005MW-CJ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:18:38 +0000
Received: from [85.158.143.99:61454] by server-1.bemta-4.messagelabs.com id
	90/56-06203-D9016215; Thu, 21 Feb 2013 12:18:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361449117!28038961!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8517 invoked from network); 21 Feb 2013 12:18:37 -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; 21 Feb 2013 12:18:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:18:36 +0000
Message-Id: <51261EE702000078000BFE06@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:19:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
	<20130221114409.GH24051@ocelot.phlegethon.org>
In-Reply-To: <20130221114409.GH24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
 failure to set up all vCPU-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 21.02.13 at 12:44, Tim Deegan <tim@xen.org> wrote:
> At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
>> Otherwise we may leak memory when setting up nHVM fails half way.
>> 
>> This implies that the individual destroy functions will have to remain
>> capable (in the VMX case they first need to be made so, following
>> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
>> that the corresponding init function was never run on.
>> 
>> Once at it, also clean up some inefficiencies in the corresponding
>> parameter validation code.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
>> 
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
>>                      rc = -EPERM;
>>                      break;
>>                  }
>> +                if ( !a.value )
>> +                    break;
> 
> Surely setting from 1 to 0 should either disable nested-hvm entirely
> (including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
> alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
> fresh state every time (& leak the old state).

No, that's precisely not the case with this patch (but was before
in case of failure on other than the first vCPU).

Of course we can _change_ to the model of fully disabling nHVM
in that case, but honestly I don't see the point, and the code is
simpler without doing so.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:21:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8V8m-0005Sd-C8; Thu, 21 Feb 2013 12:20:44 +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 1U8V8l-0005SX-5r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:20:43 +0000
Received: from [193.109.254.147:18017] by server-14.bemta-14.messagelabs.com
	id B3/98-02031-A1116215; Thu, 21 Feb 2013 12:20:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361448957!8529277!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19711 invoked from network); 21 Feb 2013 12:15:57 -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; 21 Feb 2013 12:15:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:15:56 +0000
Message-Id: <51261E4602000078000BFDEF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:16:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<1361447602.26546.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361447602.26546.54.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:53, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
>> As previously agreed, we will be moving the main Xen trees to git.
> 
> Are we going to continue with the "Committed-by:" tag? git already
> tracks this bit of metadata separately from the author so it seems a bit
> redundant. It might be useful for folks using the mirror but in reality
> I expect it will mostly be the committers who need to look this up, and
> they will be using git...

+1 for no longer adding this tag.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:21:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8V8m-0005Sd-C8; Thu, 21 Feb 2013 12:20:44 +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 1U8V8l-0005SX-5r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:20:43 +0000
Received: from [193.109.254.147:18017] by server-14.bemta-14.messagelabs.com
	id B3/98-02031-A1116215; Thu, 21 Feb 2013 12:20:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361448957!8529277!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19711 invoked from network); 21 Feb 2013 12:15:57 -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; 21 Feb 2013 12:15:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:15:56 +0000
Message-Id: <51261E4602000078000BFDEF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:16:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<1361447602.26546.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361447602.26546.54.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:53, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
>> As previously agreed, we will be moving the main Xen trees to git.
> 
> Are we going to continue with the "Committed-by:" tag? git already
> tracks this bit of metadata separately from the author so it seems a bit
> redundant. It might be useful for folks using the mirror but in reality
> I expect it will mostly be the committers who need to look this up, and
> they will be using git...

+1 for no longer adding this tag.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:24:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VCX-0005iI-0t; Thu, 21 Feb 2013 12:24:37 +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 1U8VCU-0005i8-ON
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:24:34 +0000
Received: from [85.158.137.99:37890] by server-16.bemta-3.messagelabs.com id
	77/D8-02727-DF116215; Thu, 21 Feb 2013 12:24:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361449468!12253338!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22716 invoked from network); 21 Feb 2013 12:24:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:24:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8VCI-0006pT-HB; Thu, 21 Feb 2013 12:24:22 +0000
Date: Thu, 21 Feb 2013 12:24:22 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221122422.GI24051@ocelot.phlegethon.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
	<20130221114409.GH24051@ocelot.phlegethon.org>
	<51261EE702000078000BFE06@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51261EE702000078000BFE06@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
	failure to set up all vCPU-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

At 12:19 +0000 on 21 Feb (1361449175), Jan Beulich wrote:
> >>> On 21.02.13 at 12:44, Tim Deegan <tim@xen.org> wrote:
> > At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
> >> Otherwise we may leak memory when setting up nHVM fails half way.
> >> 
> >> This implies that the individual destroy functions will have to remain
> >> capable (in the VMX case they first need to be made so, following
> >> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> >> that the corresponding init function was never run on.
> >> 
> >> Once at it, also clean up some inefficiencies in the corresponding
> >> parameter validation code.
> >> 
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
> >> 
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
> >>                      rc = -EPERM;
> >>                      break;
> >>                  }
> >> +                if ( !a.value )
> >> +                    break;
> > 
> > Surely setting from 1 to 0 should either disable nested-hvm entirely
> > (including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
> > alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
> > fresh state every time (& leak the old state).
> 
> No, that's precisely not the case with this patch (but was before
> in case of failure on other than the first vCPU).
> 
> Of course we can _change_ to the model of fully disabling nHVM
> in that case, but honestly I don't see the point, and the code is
> simpler without doing so.

Agreed, but AFAICT after this patch when the value is set to 1 and then
0 and then 1 again, it will call nestedhvm_vcpu_initialise() again, and
certainly the nvmx version of that doesn't DTRT on an
already-initialised vcpu.  What am I missing here?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:24:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VCX-0005iI-0t; Thu, 21 Feb 2013 12:24:37 +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 1U8VCU-0005i8-ON
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:24:34 +0000
Received: from [85.158.137.99:37890] by server-16.bemta-3.messagelabs.com id
	77/D8-02727-DF116215; Thu, 21 Feb 2013 12:24:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361449468!12253338!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22716 invoked from network); 21 Feb 2013 12:24:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:24:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8VCI-0006pT-HB; Thu, 21 Feb 2013 12:24:22 +0000
Date: Thu, 21 Feb 2013 12:24:22 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221122422.GI24051@ocelot.phlegethon.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
	<20130221114409.GH24051@ocelot.phlegethon.org>
	<51261EE702000078000BFE06@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51261EE702000078000BFE06@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
	failure to set up all vCPU-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

At 12:19 +0000 on 21 Feb (1361449175), Jan Beulich wrote:
> >>> On 21.02.13 at 12:44, Tim Deegan <tim@xen.org> wrote:
> > At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
> >> Otherwise we may leak memory when setting up nHVM fails half way.
> >> 
> >> This implies that the individual destroy functions will have to remain
> >> capable (in the VMX case they first need to be made so, following
> >> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> >> that the corresponding init function was never run on.
> >> 
> >> Once at it, also clean up some inefficiencies in the corresponding
> >> parameter validation code.
> >> 
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
> >> 
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
> >>                      rc = -EPERM;
> >>                      break;
> >>                  }
> >> +                if ( !a.value )
> >> +                    break;
> > 
> > Surely setting from 1 to 0 should either disable nested-hvm entirely
> > (including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
> > alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
> > fresh state every time (& leak the old state).
> 
> No, that's precisely not the case with this patch (but was before
> in case of failure on other than the first vCPU).
> 
> Of course we can _change_ to the model of fully disabling nHVM
> in that case, but honestly I don't see the point, and the code is
> simpler without doing so.

Agreed, but AFAICT after this patch when the value is set to 1 and then
0 and then 1 again, it will call nestedhvm_vcpu_initialise() again, and
certainly the nvmx version of that doesn't DTRT on an
already-initialised vcpu.  What am I missing here?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:25:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:25: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 1U8VCz-0005kR-E4; Thu, 21 Feb 2013 12:25:05 +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 1U8VCy-0005kG-IY
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:25:04 +0000
Received: from [85.158.139.83:31943] by server-5.bemta-5.messagelabs.com id
	E1/F7-11945-F1216215; Thu, 21 Feb 2013 12:25:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361449502!17011269!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14919 invoked from network); 21 Feb 2013 12:25:03 -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; 21 Feb 2013 12:25:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:25:02 +0000
Message-Id: <5126206902000078000BFE26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:26:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5126163702000078000BFDA4@nat28.tlf.novell.com>
	<CD4BBECE.5C34E%keir@xen.org>
In-Reply-To: <CD4BBECE.5C34E%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.02.13 at 13:08, Keir Fraser <keir@xen.org> wrote:
> On 21/02/2013 11:42, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Rather than using an order-1 Xen heap allocation, use (currently 2)
>> individual domain heap pages to populate space in the per-domain
>> mapping area.
>> 
>> Also fix an off-by-one mistake in is_compat_arg_xlat_range().
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Well, fine in principle. This manual setup/teardown of l2/l1 pagetables in
> the perdomain area is getting a bit tiresome though isn't it? Isn't there
> some setup helper that could be abstracted out for all users, and perhaps
> even some automated teardown-and-freeing on domain destroy? I just sighed
> when I saw more skanky pagetable manipulation for what is a conceptually
> simple change.

I tried to spot pieces worth folding into helper functions, but
didn't really find anything worthwhile (the purposes of the
mappings are just too different). Perhaps we could have a
map_pages_to_guest(), taking care of all intermediate page
table levels? I can't see much else, and the main problem is that
of tracking pages used for page tables here anyway.

Are we concerned about the performance of guest GDT/LDT page
(un)mappings?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:25:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:25: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 1U8VCz-0005kR-E4; Thu, 21 Feb 2013 12:25:05 +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 1U8VCy-0005kG-IY
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:25:04 +0000
Received: from [85.158.139.83:31943] by server-5.bemta-5.messagelabs.com id
	E1/F7-11945-F1216215; Thu, 21 Feb 2013 12:25:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361449502!17011269!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14919 invoked from network); 21 Feb 2013 12:25:03 -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; 21 Feb 2013 12:25:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:25:02 +0000
Message-Id: <5126206902000078000BFE26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:26:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5126163702000078000BFDA4@nat28.tlf.novell.com>
	<CD4BBECE.5C34E%keir@xen.org>
In-Reply-To: <CD4BBECE.5C34E%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.02.13 at 13:08, Keir Fraser <keir@xen.org> wrote:
> On 21/02/2013 11:42, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Rather than using an order-1 Xen heap allocation, use (currently 2)
>> individual domain heap pages to populate space in the per-domain
>> mapping area.
>> 
>> Also fix an off-by-one mistake in is_compat_arg_xlat_range().
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Well, fine in principle. This manual setup/teardown of l2/l1 pagetables in
> the perdomain area is getting a bit tiresome though isn't it? Isn't there
> some setup helper that could be abstracted out for all users, and perhaps
> even some automated teardown-and-freeing on domain destroy? I just sighed
> when I saw more skanky pagetable manipulation for what is a conceptually
> simple change.

I tried to spot pieces worth folding into helper functions, but
didn't really find anything worthwhile (the purposes of the
mappings are just too different). Perhaps we could have a
map_pages_to_guest(), taking care of all intermediate page
table levels? I can't see much else, and the main problem is that
of tracking pages used for page tables here anyway.

Are we concerned about the performance of guest GDT/LDT page
(un)mappings?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:29:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:29: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 1U8VHI-00061C-5L; Thu, 21 Feb 2013 12:29:32 +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 1U8VHH-000617-8X
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:29:31 +0000
Received: from [85.158.139.83:53394] by server-16.bemta-5.messagelabs.com id
	8D/2F-14948-A2316215; Thu, 21 Feb 2013 12:29:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361449766!28292828!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM4ODM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15189 invoked from network); 21 Feb 2013 12:29:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 12:29:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LCTFrL016177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 12:29:16 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
	r1LCTEcr016495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 12:29:15 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
	r1LCTFsf032004; Thu, 21 Feb 2013 06:29:15 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 04:29:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8AF261C3935; Thu, 21 Feb 2013 07:29:13 -0500 (EST)
Date: Thu, 21 Feb 2013 07:29:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20130221122913.GC6647@phenom.dumpdata.com>
References: <20130221092434.GQ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221092434.GQ8912@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> Does anyone know why loading xen-acpi-processor driver fails like this?:
> =

> # modprobe xen-acpi-processor
> FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.cent=
os.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> =

> Using "modprobe -v" doesn't provide any more information about the proble=
m.
> Also there's nothing in dom0 kernel dmesg.
> =

> Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> Xen 4.2.1.
> =

> Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable ver=
sion) =

> with some additional Xen patches backported from later upstream kernels. =

> Any tips how to troubleshoot this? =


Rebuild the module and add this
diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proces=
sor.c
index 316df65..5d824a2 100644
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -16,6 +16,7 @@
  * more details.
  *
  */
+#define DEBUG 1
 =

 #include <linux/cpumask.h>
 #include <linux/cpufreq.h>


That should help in figuring it out.

> =

> -- Pasi
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:29:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:29: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 1U8VHI-00061C-5L; Thu, 21 Feb 2013 12:29:32 +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 1U8VHH-000617-8X
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:29:31 +0000
Received: from [85.158.139.83:53394] by server-16.bemta-5.messagelabs.com id
	8D/2F-14948-A2316215; Thu, 21 Feb 2013 12:29:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361449766!28292828!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM4ODM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15189 invoked from network); 21 Feb 2013 12:29:28 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 12:29:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LCTFrL016177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 12:29:16 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
	r1LCTEcr016495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 12:29:15 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
	r1LCTFsf032004; Thu, 21 Feb 2013 06:29:15 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 04:29:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8AF261C3935; Thu, 21 Feb 2013 07:29:13 -0500 (EST)
Date: Thu, 21 Feb 2013 07:29:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20130221122913.GC6647@phenom.dumpdata.com>
References: <20130221092434.GQ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221092434.GQ8912@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> Does anyone know why loading xen-acpi-processor driver fails like this?:
> =

> # modprobe xen-acpi-processor
> FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.cent=
os.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> =

> Using "modprobe -v" doesn't provide any more information about the proble=
m.
> Also there's nothing in dom0 kernel dmesg.
> =

> Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> Xen 4.2.1.
> =

> Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable ver=
sion) =

> with some additional Xen patches backported from later upstream kernels. =

> Any tips how to troubleshoot this? =


Rebuild the module and add this
diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proces=
sor.c
index 316df65..5d824a2 100644
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -16,6 +16,7 @@
  * more details.
  *
  */
+#define DEBUG 1
 =

 #include <linux/cpumask.h>
 #include <linux/cpufreq.h>


That should help in figuring it out.

> =

> -- Pasi
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:31:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:31: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 1U8VJD-0006GC-TS; Thu, 21 Feb 2013 12:31:31 +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 1U8VJB-0006FX-RM
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:31:30 +0000
Received: from [85.158.137.99:24871] by server-8.bemta-3.messagelabs.com id
	C5/17-25687-1A316215; Thu, 21 Feb 2013 12:31:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361449886!12031964!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13684 invoked from network); 21 Feb 2013 12:31:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:31:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:31:26 +0000
Message-Id: <512621E602000078000BFE3C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:32:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
	<20130221114409.GH24051@ocelot.phlegethon.org>
	<51261EE702000078000BFE06@nat28.tlf.novell.com>
	<20130221122422.GI24051@ocelot.phlegethon.org>
In-Reply-To: <20130221122422.GI24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
 failure to set up all vCPU-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 21.02.13 at 13:24, Tim Deegan <tim@xen.org> wrote:
> At 12:19 +0000 on 21 Feb (1361449175), Jan Beulich wrote:
>> >>> On 21.02.13 at 12:44, Tim Deegan <tim@xen.org> wrote:
>> > At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
>> >> Otherwise we may leak memory when setting up nHVM fails half way.
>> >> 
>> >> This implies that the individual destroy functions will have to remain
>> >> capable (in the VMX case they first need to be made so, following
>> >> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
>> >> that the corresponding init function was never run on.
>> >> 
>> >> Once at it, also clean up some inefficiencies in the corresponding
>> >> parameter validation code.
>> >> 
>> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> >> ---
>> >> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
>> >> 
>> >> --- a/xen/arch/x86/hvm/hvm.c
>> >> +++ b/xen/arch/x86/hvm/hvm.c
>> >> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
>> >>                      rc = -EPERM;
>> >>                      break;
>> >>                  }
>> >> +                if ( !a.value )
>> >> +                    break;
>> > 
>> > Surely setting from 1 to 0 should either disable nested-hvm entirely
>> > (including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
>> > alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
>> > fresh state every time (& leak the old state).
>> 
>> No, that's precisely not the case with this patch (but was before
>> in case of failure on other than the first vCPU).
>> 
>> Of course we can _change_ to the model of fully disabling nHVM
>> in that case, but honestly I don't see the point, and the code is
>> simpler without doing so.
> 
> Agreed, but AFAICT after this patch when the value is set to 1 and then
> 0 and then 1 again, it will call nestedhvm_vcpu_initialise() again, and
> certainly the nvmx version of that doesn't DTRT on an
> already-initialised vcpu.  What am I missing here?

Oh, yes, right you are. And similarly for SVM. Let me adjust that,
and post a v3 eventually.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:31:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:31: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 1U8VJD-0006GC-TS; Thu, 21 Feb 2013 12:31:31 +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 1U8VJB-0006FX-RM
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:31:30 +0000
Received: from [85.158.137.99:24871] by server-8.bemta-3.messagelabs.com id
	C5/17-25687-1A316215; Thu, 21 Feb 2013 12:31:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361449886!12031964!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13684 invoked from network); 21 Feb 2013 12:31:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:31:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:31:26 +0000
Message-Id: <512621E602000078000BFE3C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:32:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <5126126F02000078000BFD83@nat28.tlf.novell.com>
	<20130221114409.GH24051@ocelot.phlegethon.org>
	<51261EE702000078000BFE06@nat28.tlf.novell.com>
	<20130221122422.GI24051@ocelot.phlegethon.org>
In-Reply-To: <20130221122422.GI24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] x86/nhvm: properly clean up after
 failure to set up all vCPU-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 21.02.13 at 13:24, Tim Deegan <tim@xen.org> wrote:
> At 12:19 +0000 on 21 Feb (1361449175), Jan Beulich wrote:
>> >>> On 21.02.13 at 12:44, Tim Deegan <tim@xen.org> wrote:
>> > At 11:26 +0000 on 21 Feb (1361445983), Jan Beulich wrote:
>> >> Otherwise we may leak memory when setting up nHVM fails half way.
>> >> 
>> >> This implies that the individual destroy functions will have to remain
>> >> capable (in the VMX case they first need to be made so, following
>> >> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
>> >> that the corresponding init function was never run on.
>> >> 
>> >> Once at it, also clean up some inefficiencies in the corresponding
>> >> parameter validation code.
>> >> 
>> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> >> ---
>> >> v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.
>> >> 
>> >> --- a/xen/arch/x86/hvm/hvm.c
>> >> +++ b/xen/arch/x86/hvm/hvm.c
>> >> @@ -3916,20 +3916,25 @@ long do_hvm_op(unsigned long op, XEN_GUE
>> >>                      rc = -EPERM;
>> >>                      break;
>> >>                  }
>> >> +                if ( !a.value )
>> >> +                    break;
>> > 
>> > Surely setting from 1 to 0 should either disable nested-hvm entirely
>> > (including calling nestedhvm_vcpu_destroy()) or fail.  Otherwise I think
>> > alternating 1 and 0 will cause nestedhvm_vcpu_initialise() to allocate
>> > fresh state every time (& leak the old state).
>> 
>> No, that's precisely not the case with this patch (but was before
>> in case of failure on other than the first vCPU).
>> 
>> Of course we can _change_ to the model of fully disabling nHVM
>> in that case, but honestly I don't see the point, and the code is
>> simpler without doing so.
> 
> Agreed, but AFAICT after this patch when the value is set to 1 and then
> 0 and then 1 again, it will call nestedhvm_vcpu_initialise() again, and
> certainly the nvmx version of that doesn't DTRT on an
> already-initialised vcpu.  What am I missing here?

Oh, yes, right you are. And similarly for SVM. Let me adjust that,
and post a v3 eventually.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:43:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VUE-0006VH-69; Thu, 21 Feb 2013 12:42:54 +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 1U8VUC-0006VC-Dx
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:42:52 +0000
Received: from [85.158.139.83:57859] by server-16.bemta-5.messagelabs.com id
	4F/CF-14948-B4616215; Thu, 21 Feb 2013 12:42:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361450569!27604983!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25647 invoked from network); 21 Feb 2013 12:42:50 -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;
	21 Feb 2013 12:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="8283366"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 12:42:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 07:42:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8VU7-0004hC-Lv;
	Thu, 21 Feb 2013 12:42:47 +0000
Date: Thu, 21 Feb 2013 12:42:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 applied this series

On Wed, 20 Feb 2013, Alex Bligh wrote:
> This patch series consists of 2	parts:
> * 11 patches to	libxl
> * 6 patches to QEMU
> 
> The 11 patches to libxl are unchanged and I am not resending
> them this time.
> 
> The 6 patches to QEMU are unchanged since version 2 of the patch.
> 
> These patches enable live-migrate on HVM using the upstream qemu-xen
> device model under Xen 4.2. Currently this is unimplemented. In	the
> main they are backports of patches in xen-unstable, thought the
> QEMU side in particular needed some fiddling.
> 
> I would	suggest these patches should be included in 4.2.2.
> 
> I have made minor changes per Stefano Stabellini's requests and
> these patches are compile-tested only and sent for comment. The
> changes are:
> * TB invalidation patch backported
> * Patch 3 (now 4) now applies cleanly, so no need to break whitespace
> * Comment added to patch 4 (now 5)
> * Comment added to patch 5 (now 6)
> 
> I did not redo the VRAM patch (patch 5, now patch 6) for the reasons
> set out separately, but added a comment to explain the problem instead.
> 
> Alex Bligh (6):
>   QMP, Introduce xen-set-global-dirty-log command.
>   xen: Introduce xen_modified_memory.
>   cpu_physical_memory_write_rom() needs to do TB invalidates
>   exec: Introduce helper to set dirty flags.
>   exec, memory: Call to xen_modified_memory.
>   xen: Set the vram dirty when an error occurs.
> 
>  exec.c           |   49 +++++++++++++++++++++----------------------------
>  hw/xen.h         |    1 +
>  memory.c         |    4 ++++
>  qapi-schema.json |   13 +++++++++++++
>  qmp-commands.hx  |   24 ++++++++++++++++++++++++
>  xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
>  xen-stub.c       |    9 +++++++++
>  7 files changed, 117 insertions(+), 30 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:43:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VUE-0006VH-69; Thu, 21 Feb 2013 12:42:54 +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 1U8VUC-0006VC-Dx
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:42:52 +0000
Received: from [85.158.139.83:57859] by server-16.bemta-5.messagelabs.com id
	4F/CF-14948-B4616215; Thu, 21 Feb 2013 12:42:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361450569!27604983!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25647 invoked from network); 21 Feb 2013 12:42:50 -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;
	21 Feb 2013 12:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="8283366"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 12:42:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 07:42:48 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8VU7-0004hC-Lv;
	Thu, 21 Feb 2013 12:42:47 +0000
Date: Thu, 21 Feb 2013 12:42:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <1361393761-957-1-git-send-email-alex@alex.org.uk>
Message-ID: <alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.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] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 applied this series

On Wed, 20 Feb 2013, Alex Bligh wrote:
> This patch series consists of 2	parts:
> * 11 patches to	libxl
> * 6 patches to QEMU
> 
> The 11 patches to libxl are unchanged and I am not resending
> them this time.
> 
> The 6 patches to QEMU are unchanged since version 2 of the patch.
> 
> These patches enable live-migrate on HVM using the upstream qemu-xen
> device model under Xen 4.2. Currently this is unimplemented. In	the
> main they are backports of patches in xen-unstable, thought the
> QEMU side in particular needed some fiddling.
> 
> I would	suggest these patches should be included in 4.2.2.
> 
> I have made minor changes per Stefano Stabellini's requests and
> these patches are compile-tested only and sent for comment. The
> changes are:
> * TB invalidation patch backported
> * Patch 3 (now 4) now applies cleanly, so no need to break whitespace
> * Comment added to patch 4 (now 5)
> * Comment added to patch 5 (now 6)
> 
> I did not redo the VRAM patch (patch 5, now patch 6) for the reasons
> set out separately, but added a comment to explain the problem instead.
> 
> Alex Bligh (6):
>   QMP, Introduce xen-set-global-dirty-log command.
>   xen: Introduce xen_modified_memory.
>   cpu_physical_memory_write_rom() needs to do TB invalidates
>   exec: Introduce helper to set dirty flags.
>   exec, memory: Call to xen_modified_memory.
>   xen: Set the vram dirty when an error occurs.
> 
>  exec.c           |   49 +++++++++++++++++++++----------------------------
>  hw/xen.h         |    1 +
>  memory.c         |    4 ++++
>  qapi-schema.json |   13 +++++++++++++
>  qmp-commands.hx  |   24 ++++++++++++++++++++++++
>  xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
>  xen-stub.c       |    9 +++++++++
>  7 files changed, 117 insertions(+), 30 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:45:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:45: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 1U8VWr-0006ds-Oe; Thu, 21 Feb 2013 12:45:37 +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 1U8VWp-0006dj-P1
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:45:36 +0000
Received: from [85.158.137.99:28212] by server-8.bemta-3.messagelabs.com id
	A3/3D-25687-1D616215; Thu, 21 Feb 2013 12:45:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361450573!17285715!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzEzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1457 invoked from network); 21 Feb 2013 12:42:53 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 12:42:53 -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 190EC173D;
	Thu, 21 Feb 2013 14:42:53 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EF18B241C6; Thu, 21 Feb 2013 14:42:52 +0200 (EET)
Date: Thu, 21 Feb 2013 14:42:52 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130221124252.GR8912@reaktio.net>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221122913.GC6647@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > =

> > # modprobe xen-acpi-processor
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.ce=
ntos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output err=
or
> > =

> > Using "modprobe -v" doesn't provide any more information about the prob=
lem.
> > Also there's nothing in dom0 kernel dmesg.
> > =

> > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > Xen 4.2.1.
> > =

> > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable v=
ersion) =

> > with some additional Xen patches backported from later upstream kernels=
. =

> > Any tips how to troubleshoot this? =

> =

> Rebuild the module and add this
> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proc=
essor.c
> index 316df65..5d824a2 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -16,6 +16,7 @@
>   * more details.
>   *
>   */
> +#define DEBUG 1
>  =

>  #include <linux/cpumask.h>
>  #include <linux/cpufreq.h>
> =

> =

> That should help in figuring it out.
> =


Ok, I'll do that.

Thanks!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:45:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:45: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 1U8VWr-0006ds-Oe; Thu, 21 Feb 2013 12:45:37 +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 1U8VWp-0006dj-P1
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:45:36 +0000
Received: from [85.158.137.99:28212] by server-8.bemta-3.messagelabs.com id
	A3/3D-25687-1D616215; Thu, 21 Feb 2013 12:45:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361450573!17285715!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzEzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1457 invoked from network); 21 Feb 2013 12:42:53 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 12:42:53 -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 190EC173D;
	Thu, 21 Feb 2013 14:42:53 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EF18B241C6; Thu, 21 Feb 2013 14:42:52 +0200 (EET)
Date: Thu, 21 Feb 2013 14:42:52 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130221124252.GR8912@reaktio.net>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221122913.GC6647@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > =

> > # modprobe xen-acpi-processor
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.ce=
ntos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output err=
or
> > =

> > Using "modprobe -v" doesn't provide any more information about the prob=
lem.
> > Also there's nothing in dom0 kernel dmesg.
> > =

> > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > Xen 4.2.1.
> > =

> > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable v=
ersion) =

> > with some additional Xen patches backported from later upstream kernels=
. =

> > Any tips how to troubleshoot this? =

> =

> Rebuild the module and add this
> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proc=
essor.c
> index 316df65..5d824a2 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -16,6 +16,7 @@
>   * more details.
>   *
>   */
> +#define DEBUG 1
>  =

>  #include <linux/cpumask.h>
>  #include <linux/cpufreq.h>
> =

> =

> That should help in figuring it out.
> =


Ok, I'll do that.

Thanks!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:48:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VZU-0006on-Iy; Thu, 21 Feb 2013 12:48:20 +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 1U8VZS-0006oW-TO
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:48:19 +0000
Received: from [85.158.137.99:20735] by server-7.bemta-3.messagelabs.com id
	67/B0-10367-19716215; Thu, 21 Feb 2013 12:48:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361450896!17414753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25429 invoked from network); 21 Feb 2013 12:48:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:48:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:48:16 +0000
Message-Id: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:49:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/6] ACPI v5 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 first three of these are cloned from Linux counterparts, and the
last one adjusts behavior we would have needed for v4 already.

1: ACPI 5.0: Basic support for FADT version 5
2: ACPI 5.0: Implement hardware-reduced option
3: ACPICA: Update for larger ACPI 5 FADT size
4: ACPI: support v5 (reduced HW) sleep interface
5: x86: honor ACPI indicating absence of CMOS RTC
6: honor ACPI v4 FADT flags

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:48:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VZU-0006on-Iy; Thu, 21 Feb 2013 12:48:20 +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 1U8VZS-0006oW-TO
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:48:19 +0000
Received: from [85.158.137.99:20735] by server-7.bemta-3.messagelabs.com id
	67/B0-10367-19716215; Thu, 21 Feb 2013 12:48:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361450896!17414753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25429 invoked from network); 21 Feb 2013 12:48:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:48:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:48:16 +0000
Message-Id: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:49:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/6] ACPI v5 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 first three of these are cloned from Linux counterparts, and the
last one adjusts behavior we would have needed for v4 already.

1: ACPI 5.0: Basic support for FADT version 5
2: ACPI 5.0: Implement hardware-reduced option
3: ACPICA: Update for larger ACPI 5 FADT size
4: ACPI: support v5 (reduced HW) sleep interface
5: x86: honor ACPI indicating absence of CMOS RTC
6: honor ACPI v4 FADT flags

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:54:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:54: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 1U8VfV-0007WJ-Dk; Thu, 21 Feb 2013 12:54: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 1U8VfU-0007W6-Kk
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:54:32 +0000
Received: from [85.158.137.99:34345] by server-16.bemta-3.messagelabs.com id
	28/3D-02727-60916215; Thu, 21 Feb 2013 12:54:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361451268!17380822!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18495 invoked from network); 21 Feb 2013 12:54:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:54:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1730940"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 12:54: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.297.1; Thu, 21 Feb 2013 12:54:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8VfQ-0001jp-9l; Thu, 21 Feb 2013 12:54:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8VfQ-0001iW-5Z;
	Thu, 21 Feb 2013 12:54:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.6404.74733.504322@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 12:54:28 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361447591.26546.53.camel@zakaz.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<20774.545.470486.189832@mariner.uk.xensource.com>
	<20774.2311.974537.641742@mariner.uk.xensource.com>
	<1361447591.26546.53.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>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git [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-devel] Moving xen*.hg to git [and 1 more messages]"):
> On Thu, 2013-02-21 at 11:46 +0000, Ian Jackson wrote:
> > We are working on these.
> 
> Is the commit mailer bot thing on your list?

Yes, but it's not critical in that it will keep working by virtue of
the mirror.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:54:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:54: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 1U8VfV-0007WJ-Dk; Thu, 21 Feb 2013 12:54: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 1U8VfU-0007W6-Kk
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:54:32 +0000
Received: from [85.158.137.99:34345] by server-16.bemta-3.messagelabs.com id
	28/3D-02727-60916215; Thu, 21 Feb 2013 12:54:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361451268!17380822!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18495 invoked from network); 21 Feb 2013 12:54:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:54:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1730940"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 12:54: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.297.1; Thu, 21 Feb 2013 12:54:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8VfQ-0001jp-9l; Thu, 21 Feb 2013 12:54:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8VfQ-0001iW-5Z;
	Thu, 21 Feb 2013 12:54:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.6404.74733.504322@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 12:54:28 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361447591.26546.53.camel@zakaz.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<20774.545.470486.189832@mariner.uk.xensource.com>
	<20774.2311.974537.641742@mariner.uk.xensource.com>
	<1361447591.26546.53.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>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git [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-devel] Moving xen*.hg to git [and 1 more messages]"):
> On Thu, 2013-02-21 at 11:46 +0000, Ian Jackson wrote:
> > We are working on these.
> 
> Is the commit mailer bot thing on your list?

Yes, but it's not critical in that it will keep working by virtue of
the mirror.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:55:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8Vfm-0007YI-QI; Thu, 21 Feb 2013 12:54: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 1U8Vfl-0007Y2-KZ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:54:49 +0000
Received: from [85.158.139.211:58925] by server-3.bemta-5.messagelabs.com id
	EB/6B-07037-81916215; Thu, 21 Feb 2013 12:54:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1361451288!18587653!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13246 invoked from network); 21 Feb 2013 12:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1730952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 12:54: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.297.1; Thu, 21 Feb 2013 12:54:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8Vfj-0001k0-GB; Thu, 21 Feb 2013 12:54:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8Vfj-0001ia-9r;
	Thu, 21 Feb 2013 12:54:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.6423.210434.56998@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 12:54:47 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361447602.26546.54.camel@zakaz.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<1361447602.26546.54.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>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Moving xen*.hg to git"):
> On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
> > As previously agreed, we will be moving the main Xen trees to git.
> 
> Are we going to continue with the "Committed-by:" tag? git already
> tracks this bit of metadata separately from the author so it seems a bit
> redundant. It might be useful for folks using the mirror but in reality
> I expect it will mostly be the committers who need to look this up, and
> they will be using git...

I wasn't going to.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:55:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8Vfm-0007YI-QI; Thu, 21 Feb 2013 12:54: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 1U8Vfl-0007Y2-KZ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:54:49 +0000
Received: from [85.158.139.211:58925] by server-3.bemta-5.messagelabs.com id
	EB/6B-07037-81916215; Thu, 21 Feb 2013 12:54:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1361451288!18587653!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13246 invoked from network); 21 Feb 2013 12:54:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:54:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1730952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 12:54: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.297.1; Thu, 21 Feb 2013 12:54:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8Vfj-0001k0-GB; Thu, 21 Feb 2013 12:54:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8Vfj-0001ia-9r;
	Thu, 21 Feb 2013 12:54:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20774.6423.210434.56998@mariner.uk.xensource.com>
Date: Thu, 21 Feb 2013 12:54:47 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361447602.26546.54.camel@zakaz.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<1361447602.26546.54.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>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Moving xen*.hg to git"):
> On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
> > As previously agreed, we will be moving the main Xen trees to git.
> 
> Are we going to continue with the "Committed-by:" tag? git already
> tracks this bit of metadata separately from the author so it seems a bit
> redundant. It might be useful for folks using the mirror but in reality
> I expect it will mostly be the committers who need to look this up, and
> they will be using git...

I wasn't going to.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:57:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8ViJ-0007ns-CR; Thu, 21 Feb 2013 12:57:27 +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 1U8ViH-0007ne-MP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:57:25 +0000
Received: from [85.158.139.211:43125] by server-13.bemta-5.messagelabs.com id
	A0/19-06769-5B916215; Thu, 21 Feb 2013 12:57:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361451444!17076029!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30220 invoked from network); 21 Feb 2013 12:57:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:57:24 -0000
Received: by mail-wg0-f51.google.com with SMTP id 8so7172266wgl.18
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 04:57:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YfVOrLYfRfM1enqMWjzJ2Wf5W2EsqLwE9C0hijFF2Tg=;
	b=vjslEG14qCPwf42tEiRDj79Lr3B4FY+0NmWOi0ENyImsyUoB5eh8WCm6/F+VKyGFea
	jreVYV15JZyiDsV+qyh+36ISsU42wEPiFh+rCUo/OUqwPRxj9Gxcj1jNTEJA6mDcubad
	NVl2uZ6BBCxGkYSP+cqex6D9D1TAgGHeIKKxLHR5c/stW11KPaPsh8F+WxEIr4EOPoyR
	YG8rTU5HUAL0DBIhYYKmJt88WiGIxNgsMSrjeeHLpX1zhlfdGt38+upEFAx/pBF1MFEZ
	GdJui/TcE05KcKxb3fOyiU3AI2OVtg/Ng4bodhEfqg1okTpZMgoGRiTrSXSswbpRMzyz
	PyOQ==
X-Received: by 10.194.81.40 with SMTP id w8mr29576655wjx.14.1361451443819;
	Thu, 21 Feb 2013 04:57:23 -0800 (PST)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id n2sm36805580wiy.6.2013.02.21.04.57.21
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 04:57:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 12:57:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CD4BCA2D.4C5CD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: rework hypercall argument translation
	area setup
Thread-Index: Ac4QMvoOCtm57zQCk0u1UfNYkkRWpg==
In-Reply-To: <5126206902000078000BFE26@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/02/2013 12:26, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Well, fine in principle. This manual setup/teardown of l2/l1 pagetables in
>> the perdomain area is getting a bit tiresome though isn't it? Isn't there
>> some setup helper that could be abstracted out for all users, and perhaps
>> even some automated teardown-and-freeing on domain destroy? I just sighed
>> when I saw more skanky pagetable manipulation for what is a conceptually
>> simple change.
> 
> I tried to spot pieces worth folding into helper functions, but
> didn't really find anything worthwhile (the purposes of the
> mappings are just too different). Perhaps we could have a
> map_pages_to_guest(), taking care of all intermediate page
> table levels? I can't see much else, and the main problem is that
> of tracking pages used for page tables here anyway.

Well, possibly even that might be an improvement.

> Are we concerned about the performance of guest GDT/LDT page
> (un)mappings?

LDT must often change on guest process context switch? So I would think yes
we do.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:57:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8ViJ-0007ns-CR; Thu, 21 Feb 2013 12:57:27 +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 1U8ViH-0007ne-MP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:57:25 +0000
Received: from [85.158.139.211:43125] by server-13.bemta-5.messagelabs.com id
	A0/19-06769-5B916215; Thu, 21 Feb 2013 12:57:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361451444!17076029!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30220 invoked from network); 21 Feb 2013 12:57:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 12:57:24 -0000
Received: by mail-wg0-f51.google.com with SMTP id 8so7172266wgl.18
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 04:57:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YfVOrLYfRfM1enqMWjzJ2Wf5W2EsqLwE9C0hijFF2Tg=;
	b=vjslEG14qCPwf42tEiRDj79Lr3B4FY+0NmWOi0ENyImsyUoB5eh8WCm6/F+VKyGFea
	jreVYV15JZyiDsV+qyh+36ISsU42wEPiFh+rCUo/OUqwPRxj9Gxcj1jNTEJA6mDcubad
	NVl2uZ6BBCxGkYSP+cqex6D9D1TAgGHeIKKxLHR5c/stW11KPaPsh8F+WxEIr4EOPoyR
	YG8rTU5HUAL0DBIhYYKmJt88WiGIxNgsMSrjeeHLpX1zhlfdGt38+upEFAx/pBF1MFEZ
	GdJui/TcE05KcKxb3fOyiU3AI2OVtg/Ng4bodhEfqg1okTpZMgoGRiTrSXSswbpRMzyz
	PyOQ==
X-Received: by 10.194.81.40 with SMTP id w8mr29576655wjx.14.1361451443819;
	Thu, 21 Feb 2013 04:57:23 -0800 (PST)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id n2sm36805580wiy.6.2013.02.21.04.57.21
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 04:57:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 12:57:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CD4BCA2D.4C5CD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: rework hypercall argument translation
	area setup
Thread-Index: Ac4QMvoOCtm57zQCk0u1UfNYkkRWpg==
In-Reply-To: <5126206902000078000BFE26@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/02/2013 12:26, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Well, fine in principle. This manual setup/teardown of l2/l1 pagetables in
>> the perdomain area is getting a bit tiresome though isn't it? Isn't there
>> some setup helper that could be abstracted out for all users, and perhaps
>> even some automated teardown-and-freeing on domain destroy? I just sighed
>> when I saw more skanky pagetable manipulation for what is a conceptually
>> simple change.
> 
> I tried to spot pieces worth folding into helper functions, but
> didn't really find anything worthwhile (the purposes of the
> mappings are just too different). Perhaps we could have a
> map_pages_to_guest(), taking care of all intermediate page
> table levels? I can't see much else, and the main problem is that
> of tracking pages used for page tables here anyway.

Well, possibly even that might be an improvement.

> Are we concerned about the performance of guest GDT/LDT page
> (un)mappings?

LDT must often change on guest process context switch? So I would think yes
we do.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:58:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:58: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 1U8Vig-0007r2-Q1; Thu, 21 Feb 2013 12:57:50 +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 1U8Vif-0007qu-OU
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:57:49 +0000
Received: from [85.158.137.99:29788] by server-16.bemta-3.messagelabs.com id
	5D/83-02727-EB916215; Thu, 21 Feb 2013 12:57:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361451453!12665595!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9049 invoked from network); 21 Feb 2013 12:57:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:57:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:57:33 +0000
Message-Id: <5126280802000078000BFE7F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:58:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 1/6] ACPI 5.0: Basic support for FADT version 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

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/tables/tbfadt.c
+++ b/xen/drivers/acpi/tables/tbfadt.c
@@ -222,12 +222,13 @@ void __init acpi_tb_create_local_fadt(st
 
 	/*
 	 * Check if the FADT is larger than the largest table that we expect
-	 * (the ACPI 2.0/3.0 version). If so, truncate the table, and issue
+	 * (the ACPI 5.0 version). If so, truncate the table, and issue
 	 * a warning.
 	 */
 	if (length > sizeof(struct acpi_table_fadt)) {
 		ACPI_WARNING((AE_INFO,
-			      "FADT (revision %u) is longer than ACPI 2.0 version, truncating length 0x%X to 0x%zX",
+			      "FADT (revision %u) is longer than ACPI 5.0 version,"
+			      " truncating length %u to %zu",
 			      table->revision, (unsigned)length,
 			      sizeof(struct acpi_table_fadt)));
 	}
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -255,6 +255,8 @@ struct acpi_table_fadt {
 	struct acpi_generic_address xpm_timer_block;	/* 64-bit Extended Power Mgt Timer Ctrl Reg Blk address */
 	struct acpi_generic_address xgpe0_block;	/* 64-bit Extended General Purpose Event 0 Reg Blk address */
 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended General Purpose Event 1 Reg Blk address */
+	struct acpi_generic_address sleep_control;	/* 64-bit Sleep Control register */
+	struct acpi_generic_address sleep_status;	/* 64-bit Sleep Status register */
 };
 
 /* Masks for FADT Boot Architecture Flags (boot_flags) */
@@ -264,6 +266,7 @@ struct acpi_table_fadt {
 #define ACPI_FADT_NO_VGA            (1<<2)	/* 02: [V4] It is not safe to probe for VGA hardware */
 #define ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message Signaled Interrupts (MSI) must not be enabled */
 #define ACPI_FADT_NO_ASPM           (1<<4)	/* 04: [V4] PCIe ASPM control must not be enabled */
+#define ACPI_FADT_NO_CMOS_RTC       (1<<5)	/* 05: [V5] No CMOS real-time clock present */
 
 #define FADT2_REVISION_ID               3
 
@@ -289,6 +292,8 @@ struct acpi_table_fadt {
 #define ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is compatible with remote power on (ACPI 3.0) */
 #define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* 18: [V4] All local APICs must use cluster model (ACPI 3.0) */
 #define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All local x_aPICs must use physical dest mode (ACPI 3.0) */
+#define ACPI_FADT_HW_REDUCED        (1<<20)	/* 20: [V5] ACPI hardware is not implemented (ACPI 5.0) */
+#define ACPI_FADT_LOW_POWER_S0      (1<<21)	/* 21: [V5] S0 power savings are equal or better than S3 (ACPI 5.0) */
 
 /* Values for preferred_profile (Preferred Power Management Profiles) */
 
@@ -299,14 +304,16 @@ enum acpi_prefered_pm_profiles {
 	PM_WORKSTATION = 3,
 	PM_ENTERPRISE_SERVER = 4,
 	PM_SOHO_SERVER = 5,
-	PM_APPLIANCE_PC = 6
+	PM_APPLIANCE_PC = 6,
+	PM_PERFORMANCE_SERVER = 7,
+	PM_TABLET = 8
 };
 
 /* Reset to default packing */
 
 #pragma pack()
 
-#define ACPI_FADT_OFFSET(f)             (u8) ACPI_OFFSET (struct acpi_table_fadt, f)
+#define ACPI_FADT_OFFSET(f)             (u16) ACPI_OFFSET (struct acpi_table_fadt, f)
 
 /*
  * Get the remaining ACPI tables
@@ -324,12 +331,15 @@ enum acpi_prefered_pm_profiles {
  * FADT is the bottom line as to what the version really is.
  *
  * For reference, the values below are as follows:
- *     FADT V1  size: 0x74
- *     FADT V2  size: 0x84
- *     FADT V3+ size: 0xF4
+ *     FADT V1  size: 0x074
+ *     FADT V2  size: 0x084
+ *     FADT V3  size: 0x0F4
+ *     FADT V4  size: 0x0F4
+ *     FADT V5  size: 0x10C
  */
 #define ACPI_FADT_V1_SIZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)
 #define ACPI_FADT_V2_SIZE       (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
-#define ACPI_FADT_V3_SIZE       (u32) (sizeof (struct acpi_table_fadt))
+#define ACPI_FADT_V3_SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))
+#define ACPI_FADT_V5_SIZE       (u32) (sizeof (struct acpi_table_fadt))
 
 #endif				/* __ACTBL_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:58:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:58: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 1U8Vig-0007r2-Q1; Thu, 21 Feb 2013 12:57:50 +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 1U8Vif-0007qu-OU
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:57:49 +0000
Received: from [85.158.137.99:29788] by server-16.bemta-3.messagelabs.com id
	5D/83-02727-EB916215; Thu, 21 Feb 2013 12:57:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361451453!12665595!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9049 invoked from network); 21 Feb 2013 12:57:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:57:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:57:33 +0000
Message-Id: <5126280802000078000BFE7F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:58:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 1/6] ACPI 5.0: Basic support for FADT version 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

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/tables/tbfadt.c
+++ b/xen/drivers/acpi/tables/tbfadt.c
@@ -222,12 +222,13 @@ void __init acpi_tb_create_local_fadt(st
 
 	/*
 	 * Check if the FADT is larger than the largest table that we expect
-	 * (the ACPI 2.0/3.0 version). If so, truncate the table, and issue
+	 * (the ACPI 5.0 version). If so, truncate the table, and issue
 	 * a warning.
 	 */
 	if (length > sizeof(struct acpi_table_fadt)) {
 		ACPI_WARNING((AE_INFO,
-			      "FADT (revision %u) is longer than ACPI 2.0 version, truncating length 0x%X to 0x%zX",
+			      "FADT (revision %u) is longer than ACPI 5.0 version,"
+			      " truncating length %u to %zu",
 			      table->revision, (unsigned)length,
 			      sizeof(struct acpi_table_fadt)));
 	}
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -255,6 +255,8 @@ struct acpi_table_fadt {
 	struct acpi_generic_address xpm_timer_block;	/* 64-bit Extended Power Mgt Timer Ctrl Reg Blk address */
 	struct acpi_generic_address xgpe0_block;	/* 64-bit Extended General Purpose Event 0 Reg Blk address */
 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended General Purpose Event 1 Reg Blk address */
+	struct acpi_generic_address sleep_control;	/* 64-bit Sleep Control register */
+	struct acpi_generic_address sleep_status;	/* 64-bit Sleep Status register */
 };
 
 /* Masks for FADT Boot Architecture Flags (boot_flags) */
@@ -264,6 +266,7 @@ struct acpi_table_fadt {
 #define ACPI_FADT_NO_VGA            (1<<2)	/* 02: [V4] It is not safe to probe for VGA hardware */
 #define ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message Signaled Interrupts (MSI) must not be enabled */
 #define ACPI_FADT_NO_ASPM           (1<<4)	/* 04: [V4] PCIe ASPM control must not be enabled */
+#define ACPI_FADT_NO_CMOS_RTC       (1<<5)	/* 05: [V5] No CMOS real-time clock present */
 
 #define FADT2_REVISION_ID               3
 
@@ -289,6 +292,8 @@ struct acpi_table_fadt {
 #define ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is compatible with remote power on (ACPI 3.0) */
 #define ACPI_FADT_APIC_CLUSTER      (1<<18)	/* 18: [V4] All local APICs must use cluster model (ACPI 3.0) */
 #define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All local x_aPICs must use physical dest mode (ACPI 3.0) */
+#define ACPI_FADT_HW_REDUCED        (1<<20)	/* 20: [V5] ACPI hardware is not implemented (ACPI 5.0) */
+#define ACPI_FADT_LOW_POWER_S0      (1<<21)	/* 21: [V5] S0 power savings are equal or better than S3 (ACPI 5.0) */
 
 /* Values for preferred_profile (Preferred Power Management Profiles) */
 
@@ -299,14 +304,16 @@ enum acpi_prefered_pm_profiles {
 	PM_WORKSTATION = 3,
 	PM_ENTERPRISE_SERVER = 4,
 	PM_SOHO_SERVER = 5,
-	PM_APPLIANCE_PC = 6
+	PM_APPLIANCE_PC = 6,
+	PM_PERFORMANCE_SERVER = 7,
+	PM_TABLET = 8
 };
 
 /* Reset to default packing */
 
 #pragma pack()
 
-#define ACPI_FADT_OFFSET(f)             (u8) ACPI_OFFSET (struct acpi_table_fadt, f)
+#define ACPI_FADT_OFFSET(f)             (u16) ACPI_OFFSET (struct acpi_table_fadt, f)
 
 /*
  * Get the remaining ACPI tables
@@ -324,12 +331,15 @@ enum acpi_prefered_pm_profiles {
  * FADT is the bottom line as to what the version really is.
  *
  * For reference, the values below are as follows:
- *     FADT V1  size: 0x74
- *     FADT V2  size: 0x84
- *     FADT V3+ size: 0xF4
+ *     FADT V1  size: 0x074
+ *     FADT V2  size: 0x084
+ *     FADT V3  size: 0x0F4
+ *     FADT V4  size: 0x0F4
+ *     FADT V5  size: 0x10C
  */
 #define ACPI_FADT_V1_SIZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)
 #define ACPI_FADT_V2_SIZE       (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
-#define ACPI_FADT_V3_SIZE       (u32) (sizeof (struct acpi_table_fadt))
+#define ACPI_FADT_V3_SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))
+#define ACPI_FADT_V5_SIZE       (u32) (sizeof (struct acpi_table_fadt))
 
 #endif				/* __ACTBL_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 12:58:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VjH-0007xl-FP; Thu, 21 Feb 2013 12:58:27 +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 1U8VjF-0007xJ-Ic
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:58:25 +0000
Received: from [193.109.254.147:40651] by server-12.bemta-14.messagelabs.com
	id 92/D6-32582-0F916215; Thu, 21 Feb 2013 12:58:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361451499!9161084!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13519 invoked from network); 21 Feb 2013 12:58:20 -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; 21 Feb 2013 12:58:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:58:19 +0000
Message-Id: <5126283502000078000BFE83@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:59:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part30004A35.0__="
Subject: [Xen-devel] [PATCH 2/6] ACPI 5.0: Implement hardware-reduced 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>
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.

--=__Part30004A35.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

If HW-reduced flag is set in the FADT, do not attempt to access
or initialize any ACPI hardware, including SCI and global lock.
No FACS will be present.

Signed-off-by: Bob Moore <robert.moore@intel.com>

Also adjust acpi_fadt_parse_sleep_info().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -328,6 +328,9 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	struct acpi_table_facs *facs =3D NULL;
 	uint64_t facs_pa;
=20
+	if (fadt->flags & ACPI_FADT_HW_REDUCED)
+		goto bad;
+
 	acpi_fadt_copy_address(pm1a_cnt, pm1a_control, pm1_control);
 	acpi_fadt_copy_address(pm1b_cnt, pm1b_control, pm1_control);
 	acpi_fadt_copy_address(pm1a_evt, pm1a_event, pm1_event);
@@ -351,6 +354,8 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 		       fadt->facs, facs_pa);
 		facs_pa =3D (uint64_t)fadt->facs;
 	}
+	if (!facs_pa)
+		goto bad;
=20
 	facs =3D (struct acpi_table_facs *)
 		__acpi_map_table(facs_pa, sizeof(struct acpi_table_facs));
--- a/xen/include/acpi/acglobal.h
+++ b/xen/include/acpi/acglobal.h
@@ -78,6 +78,13 @@ ACPI_EXTERN struct acpi_table_fadt acpi_
 ACPI_EXTERN struct acpi_generic_address acpi_gbl_xpm1a_enable;
 ACPI_EXTERN struct acpi_generic_address acpi_gbl_xpm1b_enable;
=20
+/*
+ * ACPI 5.0 introduces the concept of a "reduced hardware platform", =
meaning
+ * that the ACPI hardware is no longer required. A flag in the FADT =
indicates
+ * a reduced HW machine, and that flag is duplicated here for convenience.=

+ */
+ACPI_EXTERN u8 acpi_gbl_reduced_hardware;
+
 /*************************************************************************=
****
  *
  * Miscellaneous globals
--- a/xen/drivers/acpi/tables/tbfadt.c
+++ b/xen/drivers/acpi/tables/tbfadt.c
@@ -197,8 +197,13 @@ void __init acpi_tb_parse_fadt(acpi_nati
 	acpi_tb_install_table((acpi_physical_address) acpi_gbl_FADT.Xdsdt,
 			      flags, ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);=

=20
-	acpi_tb_install_table((acpi_physical_address) acpi_gbl_FADT.Xfacs,
-			      flags, ACPI_SIG_FACS, ACPI_TABLE_INDEX_FACS);=

+	/* If Hardware Reduced flag is set, there is no FACS */
+
+	if (!acpi_gbl_reduced_hardware) {
+		acpi_tb_install_table((acpi_physical_address) acpi_gbl_FADT=
.
+				      Xfacs, flags, ACPI_SIG_FACS,
+				      ACPI_TABLE_INDEX_FACS);
+	}
 }
=20
 /*************************************************************************=
******
@@ -242,6 +247,13 @@ void __init acpi_tb_create_local_fadt(st
 	ACPI_MEMCPY(&acpi_gbl_FADT, table,
 		    ACPI_MIN(length, sizeof(struct acpi_table_fadt)));
=20
+	/* Take a copy of the Hardware Reduced flag */
+
+	acpi_gbl_reduced_hardware =3D FALSE;
+	if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
+		acpi_gbl_reduced_hardware =3D TRUE;
+	}
+
 	/*
 	 * 1) Convert the local copy of the FADT to the common internal =
format
 	 * 2) Validate some of the important values within the FADT
@@ -401,6 +413,12 @@ static void __init acpi_tb_validate_fadt
 	u8 length;
 	acpi_native_uint i;
=20
+	/* If Hardware Reduced flag is set, we are all done */
+
+	if (acpi_gbl_reduced_hardware) {
+		return;
+	}
+
 	/* Examine all of the 64-bit extended address fields (X fields) */
=20
 	for (i =3D 0; i < ACPI_FADT_INFO_ENTRIES; i++) {




--=__Part30004A35.0__=
Content-Type: text/plain; name="ACPI-v5-reduced-HW.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-reduced-HW.patch"

ACPI 5.0: Implement hardware-reduced option=0A=0AIf HW-reduced flag is set =
in the FADT, do not attempt to access=0Aor initialize any ACPI hardware, =
including SCI and global lock.=0ANo FACS will be present.=0A=0ASigned-off-b=
y: Bob Moore <robert.moore@intel.com>=0A=0AAlso adjust acpi_fadt_parse_slee=
p_info().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/acpi/boot.c=0A+++ b/xen/arch/x86/acpi/boot.c=0A@@ -328,6 =
+328,9 @@ acpi_fadt_parse_sleep_info(struct acpi_t=0A 	struct acpi_table_f=
acs *facs =3D NULL;=0A 	uint64_t facs_pa;=0A =0A+	if (fadt->flags & =
ACPI_FADT_HW_REDUCED)=0A+		goto bad;=0A+=0A 	acpi_fadt_c=
opy_address(pm1a_cnt, pm1a_control, pm1_control);=0A 	acpi_fadt_copy_addr=
ess(pm1b_cnt, pm1b_control, pm1_control);=0A 	acpi_fadt_copy_address(pm1a=
_evt, pm1a_event, pm1_event);=0A@@ -351,6 +354,8 @@ acpi_fadt_parse_sleep_i=
nfo(struct acpi_t=0A 		       fadt->facs, facs_pa);=0A 		=
facs_pa =3D (uint64_t)fadt->facs;=0A 	}=0A+	if (!facs_pa)=0A+		=
goto bad;=0A =0A 	facs =3D (struct acpi_table_facs *)=0A 		=
__acpi_map_table(facs_pa, sizeof(struct acpi_table_facs));=0A--- a/xen/incl=
ude/acpi/acglobal.h=0A+++ b/xen/include/acpi/acglobal.h=0A@@ -78,6 +78,13 =
@@ ACPI_EXTERN struct acpi_table_fadt acpi_=0A ACPI_EXTERN struct =
acpi_generic_address acpi_gbl_xpm1a_enable;=0A ACPI_EXTERN struct =
acpi_generic_address acpi_gbl_xpm1b_enable;=0A =0A+/*=0A+ * ACPI 5.0 =
introduces the concept of a "reduced hardware platform", meaning=0A+ * =
that the ACPI hardware is no longer required. A flag in the FADT =
indicates=0A+ * a reduced HW machine, and that flag is duplicated here for =
convenience.=0A+ */=0A+ACPI_EXTERN u8 acpi_gbl_reduced_hardware;=0A+=0A =
/**************************************************************************=
***=0A  *=0A  * Miscellaneous globals=0A--- a/xen/drivers/acpi/tables/tbfad=
t.c=0A+++ b/xen/drivers/acpi/tables/tbfadt.c=0A@@ -197,8 +197,13 @@ void =
__init acpi_tb_parse_fadt(acpi_nati=0A 	acpi_tb_install_table((acpi_physica=
l_address) acpi_gbl_FADT.Xdsdt,=0A 			      flags, =
ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);=0A =0A-	acpi_tb_install_table((acpi=
_physical_address) acpi_gbl_FADT.Xfacs,=0A-			      =
flags, ACPI_SIG_FACS, ACPI_TABLE_INDEX_FACS);=0A+	/* If Hardware =
Reduced flag is set, there is no FACS */=0A+=0A+	if (!acpi_gbl_reduc=
ed_hardware) {=0A+		acpi_tb_install_table((acpi_physical_addres=
s) acpi_gbl_FADT.=0A+				      Xfacs, flags, =
ACPI_SIG_FACS,=0A+				      ACPI_TABLE_INDEX_FACS=
);=0A+	}=0A }=0A =0A /****************************************************=
***************************=0A@@ -242,6 +247,13 @@ void __init acpi_tb_crea=
te_local_fadt(st=0A 	ACPI_MEMCPY(&acpi_gbl_FADT, table,=0A 		   =
 ACPI_MIN(length, sizeof(struct acpi_table_fadt)));=0A =0A+	/* Take a =
copy of the Hardware Reduced flag */=0A+=0A+	acpi_gbl_reduced_hardware =
=3D FALSE;=0A+	if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {=0A+		=
acpi_gbl_reduced_hardware =3D TRUE;=0A+	}=0A+=0A 	/*=0A 	 * 1) =
Convert the local copy of the FADT to the common internal format=0A 	 * =
2) Validate some of the important values within the FADT=0A@@ -401,6 =
+413,12 @@ static void __init acpi_tb_validate_fadt=0A 	u8 length;=0A 	=
acpi_native_uint i;=0A =0A+	/* If Hardware Reduced flag is set, we are =
all done */=0A+=0A+	if (acpi_gbl_reduced_hardware) {=0A+		=
return;=0A+	}=0A+=0A 	/* Examine all of the 64-bit extended =
address fields (X fields) */=0A =0A 	for (i =3D 0; i < ACPI_FADT_INFO_EN=
TRIES; i++) {=0A
--=__Part30004A35.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

--=__Part30004A35.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 12:58:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12: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 1U8VjH-0007xl-FP; Thu, 21 Feb 2013 12:58:27 +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 1U8VjF-0007xJ-Ic
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:58:25 +0000
Received: from [193.109.254.147:40651] by server-12.bemta-14.messagelabs.com
	id 92/D6-32582-0F916215; Thu, 21 Feb 2013 12:58:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361451499!9161084!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13519 invoked from network); 21 Feb 2013 12:58:20 -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; 21 Feb 2013 12:58:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:58:19 +0000
Message-Id: <5126283502000078000BFE83@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:59:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part30004A35.0__="
Subject: [Xen-devel] [PATCH 2/6] ACPI 5.0: Implement hardware-reduced 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>
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.

--=__Part30004A35.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

If HW-reduced flag is set in the FADT, do not attempt to access
or initialize any ACPI hardware, including SCI and global lock.
No FACS will be present.

Signed-off-by: Bob Moore <robert.moore@intel.com>

Also adjust acpi_fadt_parse_sleep_info().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -328,6 +328,9 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	struct acpi_table_facs *facs =3D NULL;
 	uint64_t facs_pa;
=20
+	if (fadt->flags & ACPI_FADT_HW_REDUCED)
+		goto bad;
+
 	acpi_fadt_copy_address(pm1a_cnt, pm1a_control, pm1_control);
 	acpi_fadt_copy_address(pm1b_cnt, pm1b_control, pm1_control);
 	acpi_fadt_copy_address(pm1a_evt, pm1a_event, pm1_event);
@@ -351,6 +354,8 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 		       fadt->facs, facs_pa);
 		facs_pa =3D (uint64_t)fadt->facs;
 	}
+	if (!facs_pa)
+		goto bad;
=20
 	facs =3D (struct acpi_table_facs *)
 		__acpi_map_table(facs_pa, sizeof(struct acpi_table_facs));
--- a/xen/include/acpi/acglobal.h
+++ b/xen/include/acpi/acglobal.h
@@ -78,6 +78,13 @@ ACPI_EXTERN struct acpi_table_fadt acpi_
 ACPI_EXTERN struct acpi_generic_address acpi_gbl_xpm1a_enable;
 ACPI_EXTERN struct acpi_generic_address acpi_gbl_xpm1b_enable;
=20
+/*
+ * ACPI 5.0 introduces the concept of a "reduced hardware platform", =
meaning
+ * that the ACPI hardware is no longer required. A flag in the FADT =
indicates
+ * a reduced HW machine, and that flag is duplicated here for convenience.=

+ */
+ACPI_EXTERN u8 acpi_gbl_reduced_hardware;
+
 /*************************************************************************=
****
  *
  * Miscellaneous globals
--- a/xen/drivers/acpi/tables/tbfadt.c
+++ b/xen/drivers/acpi/tables/tbfadt.c
@@ -197,8 +197,13 @@ void __init acpi_tb_parse_fadt(acpi_nati
 	acpi_tb_install_table((acpi_physical_address) acpi_gbl_FADT.Xdsdt,
 			      flags, ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);=

=20
-	acpi_tb_install_table((acpi_physical_address) acpi_gbl_FADT.Xfacs,
-			      flags, ACPI_SIG_FACS, ACPI_TABLE_INDEX_FACS);=

+	/* If Hardware Reduced flag is set, there is no FACS */
+
+	if (!acpi_gbl_reduced_hardware) {
+		acpi_tb_install_table((acpi_physical_address) acpi_gbl_FADT=
.
+				      Xfacs, flags, ACPI_SIG_FACS,
+				      ACPI_TABLE_INDEX_FACS);
+	}
 }
=20
 /*************************************************************************=
******
@@ -242,6 +247,13 @@ void __init acpi_tb_create_local_fadt(st
 	ACPI_MEMCPY(&acpi_gbl_FADT, table,
 		    ACPI_MIN(length, sizeof(struct acpi_table_fadt)));
=20
+	/* Take a copy of the Hardware Reduced flag */
+
+	acpi_gbl_reduced_hardware =3D FALSE;
+	if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
+		acpi_gbl_reduced_hardware =3D TRUE;
+	}
+
 	/*
 	 * 1) Convert the local copy of the FADT to the common internal =
format
 	 * 2) Validate some of the important values within the FADT
@@ -401,6 +413,12 @@ static void __init acpi_tb_validate_fadt
 	u8 length;
 	acpi_native_uint i;
=20
+	/* If Hardware Reduced flag is set, we are all done */
+
+	if (acpi_gbl_reduced_hardware) {
+		return;
+	}
+
 	/* Examine all of the 64-bit extended address fields (X fields) */
=20
 	for (i =3D 0; i < ACPI_FADT_INFO_ENTRIES; i++) {




--=__Part30004A35.0__=
Content-Type: text/plain; name="ACPI-v5-reduced-HW.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-reduced-HW.patch"

ACPI 5.0: Implement hardware-reduced option=0A=0AIf HW-reduced flag is set =
in the FADT, do not attempt to access=0Aor initialize any ACPI hardware, =
including SCI and global lock.=0ANo FACS will be present.=0A=0ASigned-off-b=
y: Bob Moore <robert.moore@intel.com>=0A=0AAlso adjust acpi_fadt_parse_slee=
p_info().=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/acpi/boot.c=0A+++ b/xen/arch/x86/acpi/boot.c=0A@@ -328,6 =
+328,9 @@ acpi_fadt_parse_sleep_info(struct acpi_t=0A 	struct acpi_table_f=
acs *facs =3D NULL;=0A 	uint64_t facs_pa;=0A =0A+	if (fadt->flags & =
ACPI_FADT_HW_REDUCED)=0A+		goto bad;=0A+=0A 	acpi_fadt_c=
opy_address(pm1a_cnt, pm1a_control, pm1_control);=0A 	acpi_fadt_copy_addr=
ess(pm1b_cnt, pm1b_control, pm1_control);=0A 	acpi_fadt_copy_address(pm1a=
_evt, pm1a_event, pm1_event);=0A@@ -351,6 +354,8 @@ acpi_fadt_parse_sleep_i=
nfo(struct acpi_t=0A 		       fadt->facs, facs_pa);=0A 		=
facs_pa =3D (uint64_t)fadt->facs;=0A 	}=0A+	if (!facs_pa)=0A+		=
goto bad;=0A =0A 	facs =3D (struct acpi_table_facs *)=0A 		=
__acpi_map_table(facs_pa, sizeof(struct acpi_table_facs));=0A--- a/xen/incl=
ude/acpi/acglobal.h=0A+++ b/xen/include/acpi/acglobal.h=0A@@ -78,6 +78,13 =
@@ ACPI_EXTERN struct acpi_table_fadt acpi_=0A ACPI_EXTERN struct =
acpi_generic_address acpi_gbl_xpm1a_enable;=0A ACPI_EXTERN struct =
acpi_generic_address acpi_gbl_xpm1b_enable;=0A =0A+/*=0A+ * ACPI 5.0 =
introduces the concept of a "reduced hardware platform", meaning=0A+ * =
that the ACPI hardware is no longer required. A flag in the FADT =
indicates=0A+ * a reduced HW machine, and that flag is duplicated here for =
convenience.=0A+ */=0A+ACPI_EXTERN u8 acpi_gbl_reduced_hardware;=0A+=0A =
/**************************************************************************=
***=0A  *=0A  * Miscellaneous globals=0A--- a/xen/drivers/acpi/tables/tbfad=
t.c=0A+++ b/xen/drivers/acpi/tables/tbfadt.c=0A@@ -197,8 +197,13 @@ void =
__init acpi_tb_parse_fadt(acpi_nati=0A 	acpi_tb_install_table((acpi_physica=
l_address) acpi_gbl_FADT.Xdsdt,=0A 			      flags, =
ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);=0A =0A-	acpi_tb_install_table((acpi=
_physical_address) acpi_gbl_FADT.Xfacs,=0A-			      =
flags, ACPI_SIG_FACS, ACPI_TABLE_INDEX_FACS);=0A+	/* If Hardware =
Reduced flag is set, there is no FACS */=0A+=0A+	if (!acpi_gbl_reduc=
ed_hardware) {=0A+		acpi_tb_install_table((acpi_physical_addres=
s) acpi_gbl_FADT.=0A+				      Xfacs, flags, =
ACPI_SIG_FACS,=0A+				      ACPI_TABLE_INDEX_FACS=
);=0A+	}=0A }=0A =0A /****************************************************=
***************************=0A@@ -242,6 +247,13 @@ void __init acpi_tb_crea=
te_local_fadt(st=0A 	ACPI_MEMCPY(&acpi_gbl_FADT, table,=0A 		   =
 ACPI_MIN(length, sizeof(struct acpi_table_fadt)));=0A =0A+	/* Take a =
copy of the Hardware Reduced flag */=0A+=0A+	acpi_gbl_reduced_hardware =
=3D FALSE;=0A+	if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {=0A+		=
acpi_gbl_reduced_hardware =3D TRUE;=0A+	}=0A+=0A 	/*=0A 	 * 1) =
Convert the local copy of the FADT to the common internal format=0A 	 * =
2) Validate some of the important values within the FADT=0A@@ -401,6 =
+413,12 @@ static void __init acpi_tb_validate_fadt=0A 	u8 length;=0A 	=
acpi_native_uint i;=0A =0A+	/* If Hardware Reduced flag is set, we are =
all done */=0A+=0A+	if (acpi_gbl_reduced_hardware) {=0A+		=
return;=0A+	}=0A+=0A 	/* Examine all of the 64-bit extended =
address fields (X fields) */=0A =0A 	for (i =3D 0; i < ACPI_FADT_INFO_EN=
TRIES; i++) {=0A
--=__Part30004A35.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

--=__Part30004A35.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 12:59:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:59: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 1U8Vjy-00086u-UF; Thu, 21 Feb 2013 12:59:10 +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 1U8Vjx-00086T-3v
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:59:09 +0000
Received: from [193.109.254.147:43792] by server-1.bemta-14.messagelabs.com id
	FB/CF-29874-C1A16215; Thu, 21 Feb 2013 12:59:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361451537!3548533!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10553 invoked from network); 21 Feb 2013 12:58:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:58:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:58:57 +0000
Message-Id: <5126285B02000078000BFE87@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:59:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5E6E245B.0__="
Subject: [Xen-devel] [PATCH 3/6] ACPICA: Update for larger ACPI 5 FADT size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part5E6E245B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

FADT is now larger than 256 bytes, so all FADT offsets must be
changed from 8 bits to 16 bits.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/tables/tbfadt.c
+++ b/xen/drivers/acpi/tables/tbfadt.c
@@ -62,13 +62,14 @@ static void acpi_tb_validate_fadt(void);
=20
 typedef struct acpi_fadt_info {
 	char *name;
-	u8 target;
-	u8 source;
-	u8 length;
+	u16 target;
+	u16 source;
+	u16 length;
 	u8 type;
=20
 } acpi_fadt_info;
=20
+#define ACPI_FADT_OPTIONAL          0
 #define ACPI_FADT_REQUIRED          1
 #define ACPI_FADT_SEPARATE_LENGTH   2
=20
@@ -79,7 +80,7 @@ static struct acpi_fadt_info __initdata=20
=20
 	{"Pm1bEventBlock", ACPI_FADT_OFFSET(xpm1b_event_block),
 	 ACPI_FADT_OFFSET(pm1b_event_block),
-	 ACPI_FADT_OFFSET(pm1_event_length), 0},
+	 ACPI_FADT_OFFSET(pm1_event_length), ACPI_FADT_OPTIONAL},
=20
 	{"Pm1aControlBlock", ACPI_FADT_OFFSET(xpm1a_control_block),
 	 ACPI_FADT_OFFSET(pm1a_control_block),
@@ -87,7 +88,7 @@ static struct acpi_fadt_info __initdata=20
=20
 	{"Pm1bControlBlock", ACPI_FADT_OFFSET(xpm1b_control_block),
 	 ACPI_FADT_OFFSET(pm1b_control_block),
-	 ACPI_FADT_OFFSET(pm1_control_length), 0},
+	 ACPI_FADT_OFFSET(pm1_control_length), ACPI_FADT_OPTIONAL},
=20
 	{"Pm2ControlBlock", ACPI_FADT_OFFSET(xpm2_control_block),
 	 ACPI_FADT_OFFSET(pm2_control_block),




--=__Part5E6E245B.0__=
Content-Type: text/plain; name="ACPI-v5-FADT-offsets.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-FADT-offsets.patch"

ACPICA: Update for larger ACPI 5 FADT size=0A=0AFADT is now larger than =
256 bytes, so all FADT offsets must be=0Achanged from 8 bits to 16 =
bits.=0A=0ASigned-off-by: Bob Moore <robert.moore@intel.com>=0ASigned-off-b=
y: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/acpi/tables/tbfad=
t.c=0A+++ b/xen/drivers/acpi/tables/tbfadt.c=0A@@ -62,13 +62,14 @@ static =
void acpi_tb_validate_fadt(void);=0A =0A typedef struct acpi_fadt_info =
{=0A 	char *name;=0A-	u8 target;=0A-	u8 source;=0A-	u8 length;=0A+	=
u16 target;=0A+	u16 source;=0A+	u16 length;=0A 	u8 type;=0A =0A } =
acpi_fadt_info;=0A =0A+#define ACPI_FADT_OPTIONAL          0=0A #define =
ACPI_FADT_REQUIRED          1=0A #define ACPI_FADT_SEPARATE_LENGTH   2=0A =
=0A@@ -79,7 +80,7 @@ static struct acpi_fadt_info __initdata =0A =0A 	=
{"Pm1bEventBlock", ACPI_FADT_OFFSET(xpm1b_event_block),=0A 	 ACPI_FADT_=
OFFSET(pm1b_event_block),=0A-	 ACPI_FADT_OFFSET(pm1_event_length), =
0},=0A+	 ACPI_FADT_OFFSET(pm1_event_length), ACPI_FADT_OPTIONAL},=0A =0A 	=
{"Pm1aControlBlock", ACPI_FADT_OFFSET(xpm1a_control_block),=0A 	 ACPI_FADT_=
OFFSET(pm1a_control_block),=0A@@ -87,7 +88,7 @@ static struct acpi_fadt_inf=
o __initdata =0A =0A 	{"Pm1bControlBlock", ACPI_FADT_OFFSET(xpm1b_control=
_block),=0A 	 ACPI_FADT_OFFSET(pm1b_control_block),=0A-	 ACPI_FADT_=
OFFSET(pm1_control_length), 0},=0A+	 ACPI_FADT_OFFSET(pm1_control_lengt=
h), ACPI_FADT_OPTIONAL},=0A =0A 	{"Pm2ControlBlock", ACPI_FADT_OFFSE=
T(xpm2_control_block),=0A 	 ACPI_FADT_OFFSET(pm2_control_block),=0A
--=__Part5E6E245B.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

--=__Part5E6E245B.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 12:59:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 12:59: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 1U8Vjy-00086u-UF; Thu, 21 Feb 2013 12:59:10 +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 1U8Vjx-00086T-3v
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 12:59:09 +0000
Received: from [193.109.254.147:43792] by server-1.bemta-14.messagelabs.com id
	FB/CF-29874-C1A16215; Thu, 21 Feb 2013 12:59:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361451537!3548533!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10553 invoked from network); 21 Feb 2013 12:58:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:58:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:58:57 +0000
Message-Id: <5126285B02000078000BFE87@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 12:59:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5E6E245B.0__="
Subject: [Xen-devel] [PATCH 3/6] ACPICA: Update for larger ACPI 5 FADT size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part5E6E245B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

FADT is now larger than 256 bytes, so all FADT offsets must be
changed from 8 bits to 16 bits.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/tables/tbfadt.c
+++ b/xen/drivers/acpi/tables/tbfadt.c
@@ -62,13 +62,14 @@ static void acpi_tb_validate_fadt(void);
=20
 typedef struct acpi_fadt_info {
 	char *name;
-	u8 target;
-	u8 source;
-	u8 length;
+	u16 target;
+	u16 source;
+	u16 length;
 	u8 type;
=20
 } acpi_fadt_info;
=20
+#define ACPI_FADT_OPTIONAL          0
 #define ACPI_FADT_REQUIRED          1
 #define ACPI_FADT_SEPARATE_LENGTH   2
=20
@@ -79,7 +80,7 @@ static struct acpi_fadt_info __initdata=20
=20
 	{"Pm1bEventBlock", ACPI_FADT_OFFSET(xpm1b_event_block),
 	 ACPI_FADT_OFFSET(pm1b_event_block),
-	 ACPI_FADT_OFFSET(pm1_event_length), 0},
+	 ACPI_FADT_OFFSET(pm1_event_length), ACPI_FADT_OPTIONAL},
=20
 	{"Pm1aControlBlock", ACPI_FADT_OFFSET(xpm1a_control_block),
 	 ACPI_FADT_OFFSET(pm1a_control_block),
@@ -87,7 +88,7 @@ static struct acpi_fadt_info __initdata=20
=20
 	{"Pm1bControlBlock", ACPI_FADT_OFFSET(xpm1b_control_block),
 	 ACPI_FADT_OFFSET(pm1b_control_block),
-	 ACPI_FADT_OFFSET(pm1_control_length), 0},
+	 ACPI_FADT_OFFSET(pm1_control_length), ACPI_FADT_OPTIONAL},
=20
 	{"Pm2ControlBlock", ACPI_FADT_OFFSET(xpm2_control_block),
 	 ACPI_FADT_OFFSET(pm2_control_block),




--=__Part5E6E245B.0__=
Content-Type: text/plain; name="ACPI-v5-FADT-offsets.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-FADT-offsets.patch"

ACPICA: Update for larger ACPI 5 FADT size=0A=0AFADT is now larger than =
256 bytes, so all FADT offsets must be=0Achanged from 8 bits to 16 =
bits.=0A=0ASigned-off-by: Bob Moore <robert.moore@intel.com>=0ASigned-off-b=
y: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/acpi/tables/tbfad=
t.c=0A+++ b/xen/drivers/acpi/tables/tbfadt.c=0A@@ -62,13 +62,14 @@ static =
void acpi_tb_validate_fadt(void);=0A =0A typedef struct acpi_fadt_info =
{=0A 	char *name;=0A-	u8 target;=0A-	u8 source;=0A-	u8 length;=0A+	=
u16 target;=0A+	u16 source;=0A+	u16 length;=0A 	u8 type;=0A =0A } =
acpi_fadt_info;=0A =0A+#define ACPI_FADT_OPTIONAL          0=0A #define =
ACPI_FADT_REQUIRED          1=0A #define ACPI_FADT_SEPARATE_LENGTH   2=0A =
=0A@@ -79,7 +80,7 @@ static struct acpi_fadt_info __initdata =0A =0A 	=
{"Pm1bEventBlock", ACPI_FADT_OFFSET(xpm1b_event_block),=0A 	 ACPI_FADT_=
OFFSET(pm1b_event_block),=0A-	 ACPI_FADT_OFFSET(pm1_event_length), =
0},=0A+	 ACPI_FADT_OFFSET(pm1_event_length), ACPI_FADT_OPTIONAL},=0A =0A 	=
{"Pm1aControlBlock", ACPI_FADT_OFFSET(xpm1a_control_block),=0A 	 ACPI_FADT_=
OFFSET(pm1a_control_block),=0A@@ -87,7 +88,7 @@ static struct acpi_fadt_inf=
o __initdata =0A =0A 	{"Pm1bControlBlock", ACPI_FADT_OFFSET(xpm1b_control=
_block),=0A 	 ACPI_FADT_OFFSET(pm1b_control_block),=0A-	 ACPI_FADT_=
OFFSET(pm1_control_length), 0},=0A+	 ACPI_FADT_OFFSET(pm1_control_lengt=
h), ACPI_FADT_OPTIONAL},=0A =0A 	{"Pm2ControlBlock", ACPI_FADT_OFFSE=
T(xpm2_control_block),=0A 	 ACPI_FADT_OFFSET(pm2_control_block),=0A
--=__Part5E6E245B.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

--=__Part5E6E245B.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:00:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8VlH-0008OI-EJ; Thu, 21 Feb 2013 13:00:31 +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 1U8VlF-0008O2-R3
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:00:30 +0000
Received: from [193.109.254.147:61698] by server-1.bemta-14.messagelabs.com id
	59/71-29874-D6A16215; Thu, 21 Feb 2013 13:00:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361451623!8697126!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16774 invoked from network); 21 Feb 2013 13:00:24 -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; 21 Feb 2013 13:00:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:00:23 +0000
Message-Id: <512628B202000078000BFE8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:01:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB787CDB2.0__="
Subject: [Xen-devel] [PATCH 5/6] x86: honor ACPI indicating absence of CMOS
	RTC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartB787CDB2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On such systems we can boot through EFI only.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -754,6 +754,9 @@ static unsigned long get_cmos_time(void)
             return res;
     }
=20
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) )
+        panic("System without CMOS RTC must be booted from EFI\n");
+
     spin_lock_irqsave(&rtc_lock, flags);
=20
     /* read RTC exactly on falling edge of update flag */




--=__PartB787CDB2.0__=
Content-Type: text/plain; name="ACPI-v5-no-CMOS-RTC.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-no-CMOS-RTC.patch"

x86: honor ACPI indicating absence of CMOS RTC=0A=0AOn such systems we can =
boot through EFI only.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/time.c=0A+++ b/xen/arch/x86/time.c=0A@@ -754,6 =
+754,9 @@ static unsigned long get_cmos_time(void)=0A             return =
res;=0A     }=0A =0A+    if ( unlikely(acpi_gbl_FADT.boot_flags & =
ACPI_FADT_NO_CMOS_RTC) )=0A+        panic("System without CMOS RTC must be =
booted from EFI\n");=0A+=0A     spin_lock_irqsave(&rtc_lock, flags);=0A =
=0A     /* read RTC exactly on falling edge of update flag */=0A
--=__PartB787CDB2.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

--=__PartB787CDB2.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:00:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8VlH-0008OI-EJ; Thu, 21 Feb 2013 13:00:31 +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 1U8VlF-0008O2-R3
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:00:30 +0000
Received: from [193.109.254.147:61698] by server-1.bemta-14.messagelabs.com id
	59/71-29874-D6A16215; Thu, 21 Feb 2013 13:00:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361451623!8697126!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16774 invoked from network); 21 Feb 2013 13:00:24 -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; 21 Feb 2013 13:00:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:00:23 +0000
Message-Id: <512628B202000078000BFE8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:01:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB787CDB2.0__="
Subject: [Xen-devel] [PATCH 5/6] x86: honor ACPI indicating absence of CMOS
	RTC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartB787CDB2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On such systems we can boot through EFI only.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -754,6 +754,9 @@ static unsigned long get_cmos_time(void)
             return res;
     }
=20
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) )
+        panic("System without CMOS RTC must be booted from EFI\n");
+
     spin_lock_irqsave(&rtc_lock, flags);
=20
     /* read RTC exactly on falling edge of update flag */




--=__PartB787CDB2.0__=
Content-Type: text/plain; name="ACPI-v5-no-CMOS-RTC.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-no-CMOS-RTC.patch"

x86: honor ACPI indicating absence of CMOS RTC=0A=0AOn such systems we can =
boot through EFI only.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/time.c=0A+++ b/xen/arch/x86/time.c=0A@@ -754,6 =
+754,9 @@ static unsigned long get_cmos_time(void)=0A             return =
res;=0A     }=0A =0A+    if ( unlikely(acpi_gbl_FADT.boot_flags & =
ACPI_FADT_NO_CMOS_RTC) )=0A+        panic("System without CMOS RTC must be =
booted from EFI\n");=0A+=0A     spin_lock_irqsave(&rtc_lock, flags);=0A =
=0A     /* read RTC exactly on falling edge of update flag */=0A
--=__PartB787CDB2.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

--=__PartB787CDB2.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:01:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:01: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 1U8Vle-0008SP-S7; Thu, 21 Feb 2013 13:00:54 +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 1U8Vld-0008S4-K2
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 13:00:53 +0000
Received: from [85.158.137.99:35405] by server-5.bemta-3.messagelabs.com id
	86/F4-04457-48A16215; Thu, 21 Feb 2013 13:00:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361451616!17382176!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTAxNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21337 invoked from network); 21 Feb 2013 13:00:17 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 13:00:17 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LD0EOa026680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:00:15 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
	r1LD0EWk010657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:00:14 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1LD0EOX017080
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 07:00:14 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 05:00:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 653271C3935; Thu, 21 Feb 2013 08:00:13 -0500 (EST)
Date: Thu, 21 Feb 2013 08:00:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130221130013.GA7240@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] Regression with Xen 4.1.5 (cs 23459 compared to cs
	23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
and I kept on getting:
xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed (rc=-3): Internal error

Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
bisection but any thoughts off which one I ought to try out first?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:01:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:01: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 1U8Vle-0008SP-S7; Thu, 21 Feb 2013 13:00:54 +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 1U8Vld-0008S4-K2
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 13:00:53 +0000
Received: from [85.158.137.99:35405] by server-5.bemta-3.messagelabs.com id
	86/F4-04457-48A16215; Thu, 21 Feb 2013 13:00:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361451616!17382176!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTAxNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21337 invoked from network); 21 Feb 2013 13:00:17 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 13:00:17 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LD0EOa026680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:00:15 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
	r1LD0EWk010657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:00:14 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1LD0EOX017080
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 07:00:14 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 05:00:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 653271C3935; Thu, 21 Feb 2013 08:00:13 -0500 (EST)
Date: Thu, 21 Feb 2013 08:00:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130221130013.GA7240@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] Regression with Xen 4.1.5 (cs 23459 compared to cs
	23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
and I kept on getting:
xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed (rc=-3): Internal error

Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
bisection but any thoughts off which one I ought to try out first?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:01:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:01: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 1U8Vmb-0000Ir-Bs; Thu, 21 Feb 2013 13:01: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 1U8VmZ-0000IP-E5
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:01:51 +0000
Received: from [193.109.254.147:17466] by server-11.bemta-14.messagelabs.com
	id 13/19-30685-EBA16215; Thu, 21 Feb 2013 13:01:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361451656!9034350!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14751 invoked from network); 21 Feb 2013 13:00:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 13:00:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:00:56 +0000
Message-Id: <512628D202000078000BFE93@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:01:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD7E7ADD2.0__="
Subject: [Xen-devel] [PATCH 6/6] honor ACPI v4 FADT 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>
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.

--=__PartD7E7ADD2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- force use of physical APIC mode if indicated so (as we don't support
  xAPIC cluster mode, the respective flag is taken to force physical
  mode too)
- don't use MSI if indicated so (implies no IOMMU)

Both can be overridden on the command line, for the MSI case this at
once adds a new command line option allowing to turn off PCI MSI (IOMMU
and HPET are unaffected by this).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -639,6 +639,13 @@ limit is ignored by Xen.
=20
 Specify if the MMConfig space should be enabled.
=20
+### msi
+> `=3D <boolean>`
+
+> Default: `true`
+
+Force Xen to (not) use PCI-MSI, even if ACPI FADT says otherwise.
+
 ### mwait-idle
 > `=3D <boolean>`
=20
--- a/xen/arch/x86/genapic/bigsmp.c
+++ b/xen/arch/x86/genapic/bigsmp.c
@@ -40,7 +40,14 @@ static struct dmi_system_id __initdata b
=20
 static __init int probe_bigsmp(void)
 {=20
-	if (!def_to_bigsmp)
+	/*
+	 * We don't implement cluster mode, so force use of
+	 * physical mode in both cases.
+	 */
+	if (acpi_gbl_FADT.flags &
+	    (ACPI_FADT_APIC_CLUSTER | ACPI_FADT_APIC_PHYSICAL))
+		def_to_bigsmp =3D 1;
+	else if (!def_to_bigsmp)
 		dmi_check_system(bigsmp_dmi_table);
 	return def_to_bigsmp;
 }=20
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -30,9 +30,6 @@
 #include <xen/smp.h>
 #include <asm/mach-default/mach_mpparse.h>
=20
-static bool_t __initdata x2apic_phys; /* By default we use logical =
cluster mode. */
-boolean_param("x2apic_phys", x2apic_phys);
-
 static DEFINE_PER_CPU_READ_MOSTLY(u32, cpu_2_logical_apicid);
 static DEFINE_PER_CPU_READ_MOSTLY(cpumask_t *, cluster_cpus);
 static cpumask_t *cluster_cpus_spare;
@@ -223,8 +220,14 @@ static struct notifier_block x2apic_cpu_
    .notifier_call =3D update_clusterinfo
 };
=20
+static s8 __initdata x2apic_phys =3D -1; /* By default we use logical =
cluster mode. */
+boolean_param("x2apic_phys", x2apic_phys);
+
 const struct genapic *__init apic_x2apic_probe(void)
 {
+    if ( x2apic_phys < 0 )
+        x2apic_phys =3D !!(acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL);=

+
     if ( x2apic_phys )
         return &apic_x2apic_phys;
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -381,6 +381,9 @@ static void __init hpet_fsb_cap_lookup(v
     u32 id;
     unsigned int i, num_chs;
=20
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+        return;
+
     id =3D hpet_read32(HPET_ID);
=20
     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -32,6 +32,9 @@
 #include <xen/iommu.h>
 #include <xsm/xsm.h>
=20
+static s8 __read_mostly use_msi =3D -1;
+boolean_param("msi", use_msi);
+
 /* bitmap indicate which fixed map is free */
 static DEFINE_SPINLOCK(msix_fixmap_lock);
 static DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
@@ -994,6 +997,9 @@ int pci_prepare_msix(u16 seg, u8 bus, u8
     unsigned int pos =3D pci_find_cap_offset(seg, bus, slot, func,
                                            PCI_CAP_ID_MSIX);
=20
+    if ( !use_msi )
+        return 0;
+
     if ( !pos )
         return -ENODEV;
=20
@@ -1029,6 +1035,9 @@ int pci_enable_msi(struct msi_info *msi,
 {
     ASSERT(spin_is_locked(&pcidevs_lock));
=20
+    if ( !use_msi )
+        return -EPERM;
+
     return  msi->table_base ? __pci_enable_msix(msi, desc) :
         __pci_enable_msi(msi, desc);
 }
@@ -1074,7 +1083,10 @@ int pci_restore_msi_state(struct pci_dev
=20
     ASSERT(spin_is_locked(&pcidevs_lock));
=20
-    if (!pdev)
+    if ( !use_msi )
+        return -EOPNOTSUPP;
+
+    if ( !pdev )
         return -EINVAL;
=20
     ret =3D xsm_resource_setup_pci(XSM_PRIV, (pdev->seg << 16) | =
(pdev->bus << 8) | pdev->devfn);
@@ -1133,7 +1145,7 @@ unsigned int pci_msix_get_table_len(stru
     func =3D PCI_FUNC(pdev->devfn);
=20
     pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
-    if ( !pos )
+    if ( !pos || !use_msi )
         return 0;
=20
     control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos=
));
@@ -1170,6 +1182,11 @@ static struct notifier_block msi_cpu_nfb
=20
 void __init early_msi_init(void)
 {
+    if ( use_msi < 0 )
+        use_msi =3D !(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI);
+    if ( !use_msi )
+        return;
+
     register_cpu_notifier(&msi_cpu_nfb);
     if ( msi_cpu_callback(&msi_cpu_nfb, CPU_UP_PREPARE, NULL) &
          NOTIFY_STOP_MASK )
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -1094,5 +1094,8 @@ int __init amd_iommu_get_ivrs_dev_entrie
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
 {
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+        return -EPERM;
+
     return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);
 }
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2115,6 +2115,12 @@ int __init intel_vtd_setup(void)
         goto error;
     }
=20
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+    {
+        ret =3D -EPERM;
+        goto error;
+    }
+
     platform_quirks_init();
=20
     /* We enable the following features only if they are supported by all =
VT-d



--=__PartD7E7ADD2.0__=
Content-Type: text/plain; name="ACPI-v4-flags.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v4-flags.patch"

honor ACPI v4 FADT flags=0A=0A- force use of physical APIC mode if =
indicated so (as we don't support=0A  xAPIC cluster mode, the respective =
flag is taken to force physical=0A  mode too)=0A- don't use MSI if =
indicated so (implies no IOMMU)=0A=0ABoth can be overridden on the command =
line, for the MSI case this at=0Aonce adds a new command line option =
allowing to turn off PCI MSI (IOMMU=0Aand HPET are unaffected by =
this).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/docs/misc/xen-command-line.markdown=0A+++ b/docs/misc/xen-command-line.ma=
rkdown=0A@@ -639,6 +639,13 @@ limit is ignored by Xen.=0A =0A Specify if =
the MMConfig space should be enabled.=0A =0A+### msi=0A+> `=3D <boolean>`=
=0A+=0A+> Default: `true`=0A+=0A+Force Xen to (not) use PCI-MSI, even if =
ACPI FADT says otherwise.=0A+=0A ### mwait-idle=0A > `=3D <boolean>`=0A =
=0A--- a/xen/arch/x86/genapic/bigsmp.c=0A+++ b/xen/arch/x86/genapic/bigsmp.=
c=0A@@ -40,7 +40,14 @@ static struct dmi_system_id __initdata b=0A =0A =
static __init int probe_bigsmp(void)=0A { =0A-	if (!def_to_bigsmp)=0A+	=
/*=0A+	 * We don't implement cluster mode, so force use of=0A+	 * =
physical mode in both cases.=0A+	 */=0A+	if (acpi_gbl_FADT.flags =
&=0A+	    (ACPI_FADT_APIC_CLUSTER | ACPI_FADT_APIC_PHYSICAL))=0A+		=
def_to_bigsmp =3D 1;=0A+	else if (!def_to_bigsmp)=0A 		=
dmi_check_system(bigsmp_dmi_table);=0A 	return def_to_bigsmp;=0A } =0A--- =
a/xen/arch/x86/genapic/x2apic.c=0A+++ b/xen/arch/x86/genapic/x2apic.c=0A@@ =
-30,9 +30,6 @@=0A #include <xen/smp.h>=0A #include <asm/mach-default/mach_m=
pparse.h>=0A =0A-static bool_t __initdata x2apic_phys; /* By default we =
use logical cluster mode. */=0A-boolean_param("x2apic_phys", x2apic_phys);=
=0A-=0A static DEFINE_PER_CPU_READ_MOSTLY(u32, cpu_2_logical_apicid);=0A =
static DEFINE_PER_CPU_READ_MOSTLY(cpumask_t *, cluster_cpus);=0A static =
cpumask_t *cluster_cpus_spare;=0A@@ -223,8 +220,14 @@ static struct =
notifier_block x2apic_cpu_=0A    .notifier_call =3D update_clusterinfo=0A =
};=0A =0A+static s8 __initdata x2apic_phys =3D -1; /* By default we use =
logical cluster mode. */=0A+boolean_param("x2apic_phys", x2apic_phys);=0A+=
=0A const struct genapic *__init apic_x2apic_probe(void)=0A {=0A+    if ( =
x2apic_phys < 0 )=0A+        x2apic_phys =3D !!(acpi_gbl_FADT.flags & =
ACPI_FADT_APIC_PHYSICAL);=0A+=0A     if ( x2apic_phys )=0A         return =
&apic_x2apic_phys;=0A =0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpe=
t.c=0A@@ -381,6 +381,9 @@ static void __init hpet_fsb_cap_lookup(v=0A     =
u32 id;=0A     unsigned int i, num_chs;=0A =0A+    if ( unlikely(acpi_gbl_F=
ADT.boot_flags & ACPI_FADT_NO_MSI) )=0A+        return;=0A+=0A     id =3D =
hpet_read32(HPET_ID);=0A =0A     num_chs =3D ((id & HPET_ID_NUMBER) >> =
HPET_ID_NUMBER_SHIFT);=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.=
c=0A@@ -32,6 +32,9 @@=0A #include <xen/iommu.h>=0A #include <xsm/xsm.h>=0A =
=0A+static s8 __read_mostly use_msi =3D -1;=0A+boolean_param("msi", =
use_msi);=0A+=0A /* bitmap indicate which fixed map is free */=0A static =
DEFINE_SPINLOCK(msix_fixmap_lock);=0A static DECLARE_BITMAP(msix_fixmap_pag=
es, FIX_MSIX_MAX_PAGES);=0A@@ -994,6 +997,9 @@ int pci_prepare_msix(u16 =
seg, u8 bus, u8=0A     unsigned int pos =3D pci_find_cap_offset(seg, bus, =
slot, func,=0A                                            PCI_CAP_ID_MSIX);=
=0A =0A+    if ( !use_msi )=0A+        return 0;=0A+=0A     if ( !pos )=0A =
        return -ENODEV;=0A =0A@@ -1029,6 +1035,9 @@ int pci_enable_msi(stru=
ct msi_info *msi,=0A {=0A     ASSERT(spin_is_locked(&pcidevs_lock));=0A =
=0A+    if ( !use_msi )=0A+        return -EPERM;=0A+=0A     return  =
msi->table_base ? __pci_enable_msix(msi, desc) :=0A         __pci_enable_ms=
i(msi, desc);=0A }=0A@@ -1074,7 +1083,10 @@ int pci_restore_msi_state(struc=
t pci_dev=0A =0A     ASSERT(spin_is_locked(&pcidevs_lock));=0A =0A-    if =
(!pdev)=0A+    if ( !use_msi )=0A+        return -EOPNOTSUPP;=0A+=0A+    =
if ( !pdev )=0A         return -EINVAL;=0A =0A     ret =3D xsm_resource_set=
up_pci(XSM_PRIV, (pdev->seg << 16) | (pdev->bus << 8) | pdev->devfn);=0A@@ =
-1133,7 +1145,7 @@ unsigned int pci_msix_get_table_len(stru=0A     func =
=3D PCI_FUNC(pdev->devfn);=0A =0A     pos =3D pci_find_cap_offset(seg, =
bus, slot, func, PCI_CAP_ID_MSIX);=0A-    if ( !pos )=0A+    if ( !pos || =
!use_msi )=0A         return 0;=0A =0A     control =3D pci_conf_read16(seg,=
 bus, slot, func, msix_control_reg(pos));=0A@@ -1170,6 +1182,11 @@ static =
struct notifier_block msi_cpu_nfb=0A =0A void __init early_msi_init(void)=
=0A {=0A+    if ( use_msi < 0 )=0A+        use_msi =3D !(acpi_gbl_FADT.boot=
_flags & ACPI_FADT_NO_MSI);=0A+    if ( !use_msi )=0A+        return;=0A+=
=0A     register_cpu_notifier(&msi_cpu_nfb);=0A     if ( msi_cpu_callback(&=
msi_cpu_nfb, CPU_UP_PREPARE, NULL) &=0A          NOTIFY_STOP_MASK )=0A--- =
a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+++ b/xen/drivers/passthrough/=
amd/iommu_acpi.c=0A@@ -1094,5 +1094,8 @@ int __init amd_iommu_get_ivrs_dev_=
entrie=0A =0A int __init amd_iommu_update_ivrs_mapping_acpi(void)=0A {=0A+ =
   if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )=0A+        =
return -EPERM;=0A+=0A     return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs=
_table);=0A }=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drive=
rs/passthrough/vtd/iommu.c=0A@@ -2115,6 +2115,12 @@ int __init intel_vtd_se=
tup(void)=0A         goto error;=0A     }=0A =0A+    if ( unlikely(acpi_gbl=
_FADT.boot_flags & ACPI_FADT_NO_MSI) )=0A+    {=0A+        ret =3D =
-EPERM;=0A+        goto error;=0A+    }=0A+=0A     platform_quirks_init();=
=0A =0A     /* We enable the following features only if they are supported =
by all VT-d=0A
--=__PartD7E7ADD2.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

--=__PartD7E7ADD2.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:01:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:01: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 1U8Vmb-0000Ir-Bs; Thu, 21 Feb 2013 13:01: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 1U8VmZ-0000IP-E5
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:01:51 +0000
Received: from [193.109.254.147:17466] by server-11.bemta-14.messagelabs.com
	id 13/19-30685-EBA16215; Thu, 21 Feb 2013 13:01:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361451656!9034350!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14751 invoked from network); 21 Feb 2013 13:00:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 13:00:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:00:56 +0000
Message-Id: <512628D202000078000BFE93@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:01:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD7E7ADD2.0__="
Subject: [Xen-devel] [PATCH 6/6] honor ACPI v4 FADT 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>
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.

--=__PartD7E7ADD2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- force use of physical APIC mode if indicated so (as we don't support
  xAPIC cluster mode, the respective flag is taken to force physical
  mode too)
- don't use MSI if indicated so (implies no IOMMU)

Both can be overridden on the command line, for the MSI case this at
once adds a new command line option allowing to turn off PCI MSI (IOMMU
and HPET are unaffected by this).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -639,6 +639,13 @@ limit is ignored by Xen.
=20
 Specify if the MMConfig space should be enabled.
=20
+### msi
+> `=3D <boolean>`
+
+> Default: `true`
+
+Force Xen to (not) use PCI-MSI, even if ACPI FADT says otherwise.
+
 ### mwait-idle
 > `=3D <boolean>`
=20
--- a/xen/arch/x86/genapic/bigsmp.c
+++ b/xen/arch/x86/genapic/bigsmp.c
@@ -40,7 +40,14 @@ static struct dmi_system_id __initdata b
=20
 static __init int probe_bigsmp(void)
 {=20
-	if (!def_to_bigsmp)
+	/*
+	 * We don't implement cluster mode, so force use of
+	 * physical mode in both cases.
+	 */
+	if (acpi_gbl_FADT.flags &
+	    (ACPI_FADT_APIC_CLUSTER | ACPI_FADT_APIC_PHYSICAL))
+		def_to_bigsmp =3D 1;
+	else if (!def_to_bigsmp)
 		dmi_check_system(bigsmp_dmi_table);
 	return def_to_bigsmp;
 }=20
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -30,9 +30,6 @@
 #include <xen/smp.h>
 #include <asm/mach-default/mach_mpparse.h>
=20
-static bool_t __initdata x2apic_phys; /* By default we use logical =
cluster mode. */
-boolean_param("x2apic_phys", x2apic_phys);
-
 static DEFINE_PER_CPU_READ_MOSTLY(u32, cpu_2_logical_apicid);
 static DEFINE_PER_CPU_READ_MOSTLY(cpumask_t *, cluster_cpus);
 static cpumask_t *cluster_cpus_spare;
@@ -223,8 +220,14 @@ static struct notifier_block x2apic_cpu_
    .notifier_call =3D update_clusterinfo
 };
=20
+static s8 __initdata x2apic_phys =3D -1; /* By default we use logical =
cluster mode. */
+boolean_param("x2apic_phys", x2apic_phys);
+
 const struct genapic *__init apic_x2apic_probe(void)
 {
+    if ( x2apic_phys < 0 )
+        x2apic_phys =3D !!(acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL);=

+
     if ( x2apic_phys )
         return &apic_x2apic_phys;
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -381,6 +381,9 @@ static void __init hpet_fsb_cap_lookup(v
     u32 id;
     unsigned int i, num_chs;
=20
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+        return;
+
     id =3D hpet_read32(HPET_ID);
=20
     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -32,6 +32,9 @@
 #include <xen/iommu.h>
 #include <xsm/xsm.h>
=20
+static s8 __read_mostly use_msi =3D -1;
+boolean_param("msi", use_msi);
+
 /* bitmap indicate which fixed map is free */
 static DEFINE_SPINLOCK(msix_fixmap_lock);
 static DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
@@ -994,6 +997,9 @@ int pci_prepare_msix(u16 seg, u8 bus, u8
     unsigned int pos =3D pci_find_cap_offset(seg, bus, slot, func,
                                            PCI_CAP_ID_MSIX);
=20
+    if ( !use_msi )
+        return 0;
+
     if ( !pos )
         return -ENODEV;
=20
@@ -1029,6 +1035,9 @@ int pci_enable_msi(struct msi_info *msi,
 {
     ASSERT(spin_is_locked(&pcidevs_lock));
=20
+    if ( !use_msi )
+        return -EPERM;
+
     return  msi->table_base ? __pci_enable_msix(msi, desc) :
         __pci_enable_msi(msi, desc);
 }
@@ -1074,7 +1083,10 @@ int pci_restore_msi_state(struct pci_dev
=20
     ASSERT(spin_is_locked(&pcidevs_lock));
=20
-    if (!pdev)
+    if ( !use_msi )
+        return -EOPNOTSUPP;
+
+    if ( !pdev )
         return -EINVAL;
=20
     ret =3D xsm_resource_setup_pci(XSM_PRIV, (pdev->seg << 16) | =
(pdev->bus << 8) | pdev->devfn);
@@ -1133,7 +1145,7 @@ unsigned int pci_msix_get_table_len(stru
     func =3D PCI_FUNC(pdev->devfn);
=20
     pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
-    if ( !pos )
+    if ( !pos || !use_msi )
         return 0;
=20
     control =3D pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos=
));
@@ -1170,6 +1182,11 @@ static struct notifier_block msi_cpu_nfb
=20
 void __init early_msi_init(void)
 {
+    if ( use_msi < 0 )
+        use_msi =3D !(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI);
+    if ( !use_msi )
+        return;
+
     register_cpu_notifier(&msi_cpu_nfb);
     if ( msi_cpu_callback(&msi_cpu_nfb, CPU_UP_PREPARE, NULL) &
          NOTIFY_STOP_MASK )
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -1094,5 +1094,8 @@ int __init amd_iommu_get_ivrs_dev_entrie
=20
 int __init amd_iommu_update_ivrs_mapping_acpi(void)
 {
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+        return -EPERM;
+
     return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs_table);
 }
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2115,6 +2115,12 @@ int __init intel_vtd_setup(void)
         goto error;
     }
=20
+    if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+    {
+        ret =3D -EPERM;
+        goto error;
+    }
+
     platform_quirks_init();
=20
     /* We enable the following features only if they are supported by all =
VT-d



--=__PartD7E7ADD2.0__=
Content-Type: text/plain; name="ACPI-v4-flags.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v4-flags.patch"

honor ACPI v4 FADT flags=0A=0A- force use of physical APIC mode if =
indicated so (as we don't support=0A  xAPIC cluster mode, the respective =
flag is taken to force physical=0A  mode too)=0A- don't use MSI if =
indicated so (implies no IOMMU)=0A=0ABoth can be overridden on the command =
line, for the MSI case this at=0Aonce adds a new command line option =
allowing to turn off PCI MSI (IOMMU=0Aand HPET are unaffected by =
this).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/docs/misc/xen-command-line.markdown=0A+++ b/docs/misc/xen-command-line.ma=
rkdown=0A@@ -639,6 +639,13 @@ limit is ignored by Xen.=0A =0A Specify if =
the MMConfig space should be enabled.=0A =0A+### msi=0A+> `=3D <boolean>`=
=0A+=0A+> Default: `true`=0A+=0A+Force Xen to (not) use PCI-MSI, even if =
ACPI FADT says otherwise.=0A+=0A ### mwait-idle=0A > `=3D <boolean>`=0A =
=0A--- a/xen/arch/x86/genapic/bigsmp.c=0A+++ b/xen/arch/x86/genapic/bigsmp.=
c=0A@@ -40,7 +40,14 @@ static struct dmi_system_id __initdata b=0A =0A =
static __init int probe_bigsmp(void)=0A { =0A-	if (!def_to_bigsmp)=0A+	=
/*=0A+	 * We don't implement cluster mode, so force use of=0A+	 * =
physical mode in both cases.=0A+	 */=0A+	if (acpi_gbl_FADT.flags =
&=0A+	    (ACPI_FADT_APIC_CLUSTER | ACPI_FADT_APIC_PHYSICAL))=0A+		=
def_to_bigsmp =3D 1;=0A+	else if (!def_to_bigsmp)=0A 		=
dmi_check_system(bigsmp_dmi_table);=0A 	return def_to_bigsmp;=0A } =0A--- =
a/xen/arch/x86/genapic/x2apic.c=0A+++ b/xen/arch/x86/genapic/x2apic.c=0A@@ =
-30,9 +30,6 @@=0A #include <xen/smp.h>=0A #include <asm/mach-default/mach_m=
pparse.h>=0A =0A-static bool_t __initdata x2apic_phys; /* By default we =
use logical cluster mode. */=0A-boolean_param("x2apic_phys", x2apic_phys);=
=0A-=0A static DEFINE_PER_CPU_READ_MOSTLY(u32, cpu_2_logical_apicid);=0A =
static DEFINE_PER_CPU_READ_MOSTLY(cpumask_t *, cluster_cpus);=0A static =
cpumask_t *cluster_cpus_spare;=0A@@ -223,8 +220,14 @@ static struct =
notifier_block x2apic_cpu_=0A    .notifier_call =3D update_clusterinfo=0A =
};=0A =0A+static s8 __initdata x2apic_phys =3D -1; /* By default we use =
logical cluster mode. */=0A+boolean_param("x2apic_phys", x2apic_phys);=0A+=
=0A const struct genapic *__init apic_x2apic_probe(void)=0A {=0A+    if ( =
x2apic_phys < 0 )=0A+        x2apic_phys =3D !!(acpi_gbl_FADT.flags & =
ACPI_FADT_APIC_PHYSICAL);=0A+=0A     if ( x2apic_phys )=0A         return =
&apic_x2apic_phys;=0A =0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpe=
t.c=0A@@ -381,6 +381,9 @@ static void __init hpet_fsb_cap_lookup(v=0A     =
u32 id;=0A     unsigned int i, num_chs;=0A =0A+    if ( unlikely(acpi_gbl_F=
ADT.boot_flags & ACPI_FADT_NO_MSI) )=0A+        return;=0A+=0A     id =3D =
hpet_read32(HPET_ID);=0A =0A     num_chs =3D ((id & HPET_ID_NUMBER) >> =
HPET_ID_NUMBER_SHIFT);=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.=
c=0A@@ -32,6 +32,9 @@=0A #include <xen/iommu.h>=0A #include <xsm/xsm.h>=0A =
=0A+static s8 __read_mostly use_msi =3D -1;=0A+boolean_param("msi", =
use_msi);=0A+=0A /* bitmap indicate which fixed map is free */=0A static =
DEFINE_SPINLOCK(msix_fixmap_lock);=0A static DECLARE_BITMAP(msix_fixmap_pag=
es, FIX_MSIX_MAX_PAGES);=0A@@ -994,6 +997,9 @@ int pci_prepare_msix(u16 =
seg, u8 bus, u8=0A     unsigned int pos =3D pci_find_cap_offset(seg, bus, =
slot, func,=0A                                            PCI_CAP_ID_MSIX);=
=0A =0A+    if ( !use_msi )=0A+        return 0;=0A+=0A     if ( !pos )=0A =
        return -ENODEV;=0A =0A@@ -1029,6 +1035,9 @@ int pci_enable_msi(stru=
ct msi_info *msi,=0A {=0A     ASSERT(spin_is_locked(&pcidevs_lock));=0A =
=0A+    if ( !use_msi )=0A+        return -EPERM;=0A+=0A     return  =
msi->table_base ? __pci_enable_msix(msi, desc) :=0A         __pci_enable_ms=
i(msi, desc);=0A }=0A@@ -1074,7 +1083,10 @@ int pci_restore_msi_state(struc=
t pci_dev=0A =0A     ASSERT(spin_is_locked(&pcidevs_lock));=0A =0A-    if =
(!pdev)=0A+    if ( !use_msi )=0A+        return -EOPNOTSUPP;=0A+=0A+    =
if ( !pdev )=0A         return -EINVAL;=0A =0A     ret =3D xsm_resource_set=
up_pci(XSM_PRIV, (pdev->seg << 16) | (pdev->bus << 8) | pdev->devfn);=0A@@ =
-1133,7 +1145,7 @@ unsigned int pci_msix_get_table_len(stru=0A     func =
=3D PCI_FUNC(pdev->devfn);=0A =0A     pos =3D pci_find_cap_offset(seg, =
bus, slot, func, PCI_CAP_ID_MSIX);=0A-    if ( !pos )=0A+    if ( !pos || =
!use_msi )=0A         return 0;=0A =0A     control =3D pci_conf_read16(seg,=
 bus, slot, func, msix_control_reg(pos));=0A@@ -1170,6 +1182,11 @@ static =
struct notifier_block msi_cpu_nfb=0A =0A void __init early_msi_init(void)=
=0A {=0A+    if ( use_msi < 0 )=0A+        use_msi =3D !(acpi_gbl_FADT.boot=
_flags & ACPI_FADT_NO_MSI);=0A+    if ( !use_msi )=0A+        return;=0A+=
=0A     register_cpu_notifier(&msi_cpu_nfb);=0A     if ( msi_cpu_callback(&=
msi_cpu_nfb, CPU_UP_PREPARE, NULL) &=0A          NOTIFY_STOP_MASK )=0A--- =
a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+++ b/xen/drivers/passthrough/=
amd/iommu_acpi.c=0A@@ -1094,5 +1094,8 @@ int __init amd_iommu_get_ivrs_dev_=
entrie=0A =0A int __init amd_iommu_update_ivrs_mapping_acpi(void)=0A {=0A+ =
   if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )=0A+        =
return -EPERM;=0A+=0A     return acpi_table_parse(ACPI_SIG_IVRS, parse_ivrs=
_table);=0A }=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drive=
rs/passthrough/vtd/iommu.c=0A@@ -2115,6 +2115,12 @@ int __init intel_vtd_se=
tup(void)=0A         goto error;=0A     }=0A =0A+    if ( unlikely(acpi_gbl=
_FADT.boot_flags & ACPI_FADT_NO_MSI) )=0A+    {=0A+        ret =3D =
-EPERM;=0A+        goto error;=0A+    }=0A+=0A     platform_quirks_init();=
=0A =0A     /* We enable the following features only if they are supported =
by all VT-d=0A
--=__PartD7E7ADD2.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

--=__PartD7E7ADD2.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:04: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 1U8VpP-0000fX-8G; Thu, 21 Feb 2013 13:04:47 +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 1U8VpO-0000fQ-ET
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:04:46 +0000
Received: from [85.158.143.99:45186] by server-2.bemta-4.messagelabs.com id
	2C/7C-12656-D6B16215; Thu, 21 Feb 2013 13:04:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361451869!23297391!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16411 invoked from network); 21 Feb 2013 13:04:30 -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; 21 Feb 2013 13:04:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:04:29 +0000
Message-Id: <512629A702000078000BFEBF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:05:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5126206902000078000BFE26@nat28.tlf.novell.com>
	<CD4BCA2D.4C5CD%keir.xen@gmail.com>
In-Reply-To: <CD4BCA2D.4C5CD%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.02.13 at 13:57, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/02/2013 12:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>> Are we concerned about the performance of guest GDT/LDT page
>> (un)mappings?
> 
> LDT must often change on guest process context switch? So I would think yes
> we do.

Linux doesn't normally use an LDT (i.e. only exotic processes
would have one of non-zero size).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:04:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:04: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 1U8VpP-0000fX-8G; Thu, 21 Feb 2013 13:04:47 +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 1U8VpO-0000fQ-ET
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:04:46 +0000
Received: from [85.158.143.99:45186] by server-2.bemta-4.messagelabs.com id
	2C/7C-12656-D6B16215; Thu, 21 Feb 2013 13:04:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361451869!23297391!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16411 invoked from network); 21 Feb 2013 13:04:30 -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; 21 Feb 2013 13:04:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:04:29 +0000
Message-Id: <512629A702000078000BFEBF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:05:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5126206902000078000BFE26@nat28.tlf.novell.com>
	<CD4BCA2D.4C5CD%keir.xen@gmail.com>
In-Reply-To: <CD4BCA2D.4C5CD%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.02.13 at 13:57, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/02/2013 12:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>> Are we concerned about the performance of guest GDT/LDT page
>> (un)mappings?
> 
> LDT must often change on guest process context switch? So I would think yes
> we do.

Linux doesn't normally use an LDT (i.e. only exotic processes
would have one of non-zero size).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:05:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vpo-0000i7-4w; Thu, 21 Feb 2013 13:05:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangzhi2022@hotmail.com>) id 1U8Vpj-0000he-Qy
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:05:11 +0000
Received: from [85.158.139.83:30246] by server-1.bemta-5.messagelabs.com id
	4F/56-29263-38B16215; Thu, 21 Feb 2013 13:05:07 +0000
X-Env-Sender: zhangzhi2022@hotmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361451904!28282500!1
X-Originating-IP: [65.55.116.48]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG,
	FORGED_HOTMAIL_RCVD,HTML_50_60,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1614 invoked from network); 21 Feb 2013 13:05:04 -0000
Received: from blu0-omc1-s37.blu0.hotmail.com (HELO
	blu0-omc1-s37.blu0.hotmail.com) (65.55.116.48)
	by server-2.tower-182.messagelabs.com with SMTP;
	21 Feb 2013 13:05:04 -0000
Received: from BLU170-W72 ([65.55.116.9]) by blu0-omc1-s37.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 21 Feb 2013 05:05:04 -0800
X-EIP: [2kUhkfb53bQoD+9o5BbJFdvZ1PqK6IYn]
X-Originating-Email: [zhangzhi2022@hotmail.com]
Message-ID: <BLU170-W72336C727BBCD750EB3A13CCF70@phx.gbl>
From: =?gb2312?B?1cXWxw==?= <zhangzhi2022@hotmail.com>
To: Tim Deegan <tim@xen.org>, <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 13:05:04 +0000
Importance: Normal
In-Reply-To: <20130221090153.GC24051@ocelot.phlegethon.org>
References: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>,
	<20130221090153.GC24051@ocelot.phlegethon.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Feb 2013 13:05:04.0090 (UTC)
	FILETIME=[1076FBA0:01CE1034]
Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen 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: multipart/mixed; boundary="===============2682350373056606736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2682350373056606736==
Content-Type: multipart/alternative;
	boundary="_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_"

--_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit



 

> Date: Thu, 21 Feb 2013 09:01:53 +0000
> From: tim@xen.org
> To: zhangzhi2022@hotmail.com
> CC: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen hypervisor
> 
> Hi,
> 
> At 23:59 +0800 on 15 Feb (1360972763), henry wrote:
> > In the context of multi-core mode, core 1 is in root-mode, meaning
> > that it's running VMM. And core 2 is in non-root mode, meaning that it's
> > running guest OS in kernel level. If core 1 wants core2 to execute a
> > pre-defined program located in kernel-mode, say a syscall or a virtual
> > external interrupt handler(the program is completed via syscall or another
> > kernel module). Considering that core1 is in vmm mode, and core2 is not
> > supposed to vm-exit, so I can't use the method of event-delivery. What kind
> > of thing should core 1 do ? 
> 
> If you need the VM on core 2 to act immediately (and it's currently
> doing something other than waiting for core 1 to send it a message) then
> you'll need to send it some sort of interrupt. There's no way of doing
> that in Xen without core 2 vm-exiting, because all interrupts are
> handled in Xen.
> 
> In theory you could implement something like ELI for Xen. That could be
> interesting, not least as a piece of repeated research, but it's quite a
> serious undertaking.
> (http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)
> 
I've read about ELI already, which is quite interesting and a software implementation of ipi withou vmexits. Recently, according to kvm mailing list, Intel announced a new feature, called posted interrupts, that enables a VMM running on core0 to inject virtual interrupts to a guest running on core1 without vmexits.  The feature is described in details in the latest Intel-x86 software developer manual.
BTW, they also have published another paper which describes how they used exitless virtual interrupt injection to improve para-virtual I/O performance
(http://researcher.watson.ibm.com/researcher/files/il-ABELG/elvis-systor12.pdf)
In a nutshell, I'm still considering the implementation of ipi based on the new intel feature, compared to software method. 
 
> Of course, if you don't need an immediate answer, any shared-memory
> protocol will do. You just need to arrange for the VM to check for
> messages periodically.
> 
yes, you are right, but I need an immediate response anyway. At first, polling mechanism is considered but then given up because of the performance cost. 

> Cheers,
> 
> Tim.

Best regards,
henry 		 	   		  
--_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<BR>&nbsp;<BR>
<DIV id=SkyDrivePlaceholder></DIV>
<DIV>&gt; Date: Thu, 21 Feb 2013 09:01:53 +0000<BR>&gt; From: tim@xen.org<BR>&gt; To: zhangzhi2022@hotmail.com<BR>&gt; CC: xen-devel@lists.xen.org<BR>&gt; Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen hypervisor<BR>&gt; <BR>&gt; Hi,<BR>&gt; <BR>&gt; At 23:59 +0800 on 15 Feb (1360972763), henry wrote:<BR>&gt; &gt; In the context of multi-core mode, core 1 is in root-mode, meaning<BR>&gt; &gt; that it's running VMM. And core 2 is in non-root mode, meaning that it's<BR>&gt; &gt; running guest OS in kernel level. If core 1 wants core2 to execute a<BR>&gt; &gt; pre-defined program located in kernel-mode, say a syscall or a virtual<BR>&gt; &gt; external interrupt handler(the program is completed via syscall or another<BR>&gt; &gt; kernel module). Considering that core1 is in vmm mode, and core2 is not<BR>&gt; &gt; supposed to vm-exit, so I can't use the method of event-delivery. What kind<BR>&gt; &gt; of thing should core 1 do ? <BR>&gt; <BR>&gt; If you need the VM on core 2 to act immediately (and it's currently<BR>&gt; doing something other than waiting for core 1 to send it a message) then<BR>&gt; you'll need to send it some sort of interrupt. There's no way of doing<BR>&gt; that in Xen without core 2 vm-exiting, because all interrupts are<BR>&gt; handled in Xen.<BR>&gt; <BR>&gt; In theory you could implement something like ELI for Xen. That could be<BR>&gt; interesting, not least as a piece of repeated research, but it's quite a<BR>&gt; serious undertaking.<BR>&gt; (http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)<BR>&gt; </DIV>
<DIV>I've read about ELI already,&nbsp;which is quite interesting and a software implementation of ipi withou vmexits. Recently, according to&nbsp;<FONT size=3 face=Calibri>kvm mailing list,<FONT size=2 face=΢ÈíÑźÚ>&nbsp;</FONT></FONT><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US>Intel announced a new feature, called posted interrupts, that enables a VMM running on core0 to inject virtual interrupts to a guest running on core1 without vmexits.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>The feature is described in details in the latest Intel-x86 software developer manual.</SPAN></DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US>BTW, they also have published another paper <SPAN lang=EN-US>which describes how&nbsp;they used exitless virtual interrupt injection to improve para-virtual I/O performance<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN>
<P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><SPAN lang=EN-US>(<A href="http://researcher.watson.ibm.com/researcher/files/il-ABELG/elvis-systor12.pdf"><FONT color=#0000ff>http://researcher.watson.ibm.com/researcher/files/il-ABELG/elvis-systor12.pdf</FONT></A>)<o:p></o:p></SPAN></P></SPAN></DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US>In&nbsp;a nutshell, I'm still considering the implementation of ipi based on the new intel feature, compared to software method. </SPAN></DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US></SPAN>&nbsp;</DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US></SPAN>&gt; Of course, if you don't need an immediate answer, any shared-memory<BR>&gt; protocol will do. You just need to arrange for the VM to check for<BR>&gt; messages periodically.<BR>&gt; </DIV>
<DIV>yes, you are right, but I need an immediate response anyway. At first, polling mechanism is considered but then given up because of the performance cost. </DIV>
<DIV><BR>&gt; Cheers,<BR>&gt; <BR>&gt; Tim.<BR></DIV>
<DIV>Best regards,</DIV>
<DIV>henry</DIV> 		 	   		  </div></body>
</html>
--_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_--


--===============2682350373056606736==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2682350373056606736==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:05:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vpo-0000i7-4w; Thu, 21 Feb 2013 13:05:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhangzhi2022@hotmail.com>) id 1U8Vpj-0000he-Qy
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:05:11 +0000
Received: from [85.158.139.83:30246] by server-1.bemta-5.messagelabs.com id
	4F/56-29263-38B16215; Thu, 21 Feb 2013 13:05:07 +0000
X-Env-Sender: zhangzhi2022@hotmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361451904!28282500!1
X-Originating-IP: [65.55.116.48]
X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG,
	FORGED_HOTMAIL_RCVD,HTML_50_60,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1614 invoked from network); 21 Feb 2013 13:05:04 -0000
Received: from blu0-omc1-s37.blu0.hotmail.com (HELO
	blu0-omc1-s37.blu0.hotmail.com) (65.55.116.48)
	by server-2.tower-182.messagelabs.com with SMTP;
	21 Feb 2013 13:05:04 -0000
Received: from BLU170-W72 ([65.55.116.9]) by blu0-omc1-s37.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 21 Feb 2013 05:05:04 -0800
X-EIP: [2kUhkfb53bQoD+9o5BbJFdvZ1PqK6IYn]
X-Originating-Email: [zhangzhi2022@hotmail.com]
Message-ID: <BLU170-W72336C727BBCD750EB3A13CCF70@phx.gbl>
From: =?gb2312?B?1cXWxw==?= <zhangzhi2022@hotmail.com>
To: Tim Deegan <tim@xen.org>, <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 13:05:04 +0000
Importance: Normal
In-Reply-To: <20130221090153.GC24051@ocelot.phlegethon.org>
References: <BLU170-DS346646A5548B8071C45A04CC0E0@phx.gbl>,
	<20130221090153.GC24051@ocelot.phlegethon.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Feb 2013 13:05:04.0090 (UTC)
	FILETIME=[1076FBA0:01CE1034]
Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen 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: multipart/mixed; boundary="===============2682350373056606736=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2682350373056606736==
Content-Type: multipart/alternative;
	boundary="_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_"

--_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit



 

> Date: Thu, 21 Feb 2013 09:01:53 +0000
> From: tim@xen.org
> To: zhangzhi2022@hotmail.com
> CC: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen hypervisor
> 
> Hi,
> 
> At 23:59 +0800 on 15 Feb (1360972763), henry wrote:
> > In the context of multi-core mode, core 1 is in root-mode, meaning
> > that it's running VMM. And core 2 is in non-root mode, meaning that it's
> > running guest OS in kernel level. If core 1 wants core2 to execute a
> > pre-defined program located in kernel-mode, say a syscall or a virtual
> > external interrupt handler(the program is completed via syscall or another
> > kernel module). Considering that core1 is in vmm mode, and core2 is not
> > supposed to vm-exit, so I can't use the method of event-delivery. What kind
> > of thing should core 1 do ? 
> 
> If you need the VM on core 2 to act immediately (and it's currently
> doing something other than waiting for core 1 to send it a message) then
> you'll need to send it some sort of interrupt. There's no way of doing
> that in Xen without core 2 vm-exiting, because all interrupts are
> handled in Xen.
> 
> In theory you could implement something like ELI for Xen. That could be
> interesting, not least as a piece of repeated research, but it's quite a
> serious undertaking.
> (http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)
> 
I've read about ELI already, which is quite interesting and a software implementation of ipi withou vmexits. Recently, according to kvm mailing list, Intel announced a new feature, called posted interrupts, that enables a VMM running on core0 to inject virtual interrupts to a guest running on core1 without vmexits.  The feature is described in details in the latest Intel-x86 software developer manual.
BTW, they also have published another paper which describes how they used exitless virtual interrupt injection to improve para-virtual I/O performance
(http://researcher.watson.ibm.com/researcher/files/il-ABELG/elvis-systor12.pdf)
In a nutshell, I'm still considering the implementation of ipi based on the new intel feature, compared to software method. 
 
> Of course, if you don't need an immediate answer, any shared-memory
> protocol will do. You just need to arrange for the VM to check for
> messages periodically.
> 
yes, you are right, but I need an immediate response anyway. At first, polling mechanism is considered but then given up because of the performance cost. 

> Cheers,
> 
> Tim.

Best regards,
henry 		 	   		  
--_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<BR>&nbsp;<BR>
<DIV id=SkyDrivePlaceholder></DIV>
<DIV>&gt; Date: Thu, 21 Feb 2013 09:01:53 +0000<BR>&gt; From: tim@xen.org<BR>&gt; To: zhangzhi2022@hotmail.com<BR>&gt; CC: xen-devel@lists.xen.org<BR>&gt; Subject: Re: [Xen-devel] ipi(inter-processor interrupt) about xen hypervisor<BR>&gt; <BR>&gt; Hi,<BR>&gt; <BR>&gt; At 23:59 +0800 on 15 Feb (1360972763), henry wrote:<BR>&gt; &gt; In the context of multi-core mode, core 1 is in root-mode, meaning<BR>&gt; &gt; that it's running VMM. And core 2 is in non-root mode, meaning that it's<BR>&gt; &gt; running guest OS in kernel level. If core 1 wants core2 to execute a<BR>&gt; &gt; pre-defined program located in kernel-mode, say a syscall or a virtual<BR>&gt; &gt; external interrupt handler(the program is completed via syscall or another<BR>&gt; &gt; kernel module). Considering that core1 is in vmm mode, and core2 is not<BR>&gt; &gt; supposed to vm-exit, so I can't use the method of event-delivery. What kind<BR>&gt; &gt; of thing should core 1 do ? <BR>&gt; <BR>&gt; If you need the VM on core 2 to act immediately (and it's currently<BR>&gt; doing something other than waiting for core 1 to send it a message) then<BR>&gt; you'll need to send it some sort of interrupt. There's no way of doing<BR>&gt; that in Xen without core 2 vm-exiting, because all interrupts are<BR>&gt; handled in Xen.<BR>&gt; <BR>&gt; In theory you could implement something like ELI for Xen. That could be<BR>&gt; interesting, not least as a piece of repeated research, but it's quite a<BR>&gt; serious undertaking.<BR>&gt; (http://researcher.watson.ibm.com/researcher/files/il-ABELG/eli_asplos12.pdf)<BR>&gt; </DIV>
<DIV>I've read about ELI already,&nbsp;which is quite interesting and a software implementation of ipi withou vmexits. Recently, according to&nbsp;<FONT size=3 face=Calibri>kvm mailing list,<FONT size=2 face=΢ÈíÑźÚ>&nbsp;</FONT></FONT><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US>Intel announced a new feature, called posted interrupts, that enables a VMM running on core0 to inject virtual interrupts to a guest running on core1 without vmexits.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>The feature is described in details in the latest Intel-x86 software developer manual.</SPAN></DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US>BTW, they also have published another paper <SPAN lang=EN-US>which describes how&nbsp;they used exitless virtual interrupt injection to improve para-virtual I/O performance<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN>
<P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><SPAN lang=EN-US>(<A href="http://researcher.watson.ibm.com/researcher/files/il-ABELG/elvis-systor12.pdf"><FONT color=#0000ff>http://researcher.watson.ibm.com/researcher/files/il-ABELG/elvis-systor12.pdf</FONT></A>)<o:p></o:p></SPAN></P></SPAN></DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US>In&nbsp;a nutshell, I'm still considering the implementation of ipi based on the new intel feature, compared to software method. </SPAN></DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US></SPAN>&nbsp;</DIV>
<DIV><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 11.0pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: ËÎÌå; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA" lang=EN-US></SPAN>&gt; Of course, if you don't need an immediate answer, any shared-memory<BR>&gt; protocol will do. You just need to arrange for the VM to check for<BR>&gt; messages periodically.<BR>&gt; </DIV>
<DIV>yes, you are right, but I need an immediate response anyway. At first, polling mechanism is considered but then given up because of the performance cost. </DIV>
<DIV><BR>&gt; Cheers,<BR>&gt; <BR>&gt; Tim.<BR></DIV>
<DIV>Best regards,</DIV>
<DIV>henry</DIV> 		 	   		  </div></body>
</html>
--_7fe9d0b3-63aa-4e8d-a9e1-0793f438c257_--


--===============2682350373056606736==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2682350373056606736==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:05:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vpn-0000hd-NV; Thu, 21 Feb 2013 13:05:11 +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 1U8Vpe-0000hP-LP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:05:02 +0000
Received: from [193.109.254.147:47982] by server-14.bemta-14.messagelabs.com
	id 72/45-02031-D7B16215; Thu, 21 Feb 2013 13:05:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361451730!4044631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8749 invoked from network); 21 Feb 2013 13:02:11 -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; 21 Feb 2013 13:02:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:02:10 +0000
Message-Id: <5126291D02000078000BFEBC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:03:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
	<5126280802000078000BFE7F@nat28.tlf.novell.com>
In-Reply-To: <5126280802000078000BFE7F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1929631D.0__="
Subject: Re: [Xen-devel] [PATCH 1/6] ACPI 5.0: Basic support for FADT
 version 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>
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.

--=__Part1929631D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 21.02.13 at 13:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> Signed-off-by: Bob Moore <robert.moore@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Patch now also attached, if needed by anyone.

Jan


--=__Part1929631D.0__=
Content-Type: text/plain; name="ACPI-v5-FADT.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-FADT.patch"

ACPI 5.0: Basic support for FADT version 5=0A=0ASigned-off-by: Bob Moore =
<robert.moore@intel.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/drivers/acpi/tables/tbfadt.c=0A+++ b/xen/drivers/acpi/table=
s/tbfadt.c=0A@@ -222,12 +222,13 @@ void __init acpi_tb_create_local_fadt(st=
=0A =0A 	/*=0A 	 * Check if the FADT is larger than the largest =
table that we expect=0A-	 * (the ACPI 2.0/3.0 version). If so, =
truncate the table, and issue=0A+	 * (the ACPI 5.0 version). If so, =
truncate the table, and issue=0A 	 * a warning.=0A 	 */=0A 	if =
(length > sizeof(struct acpi_table_fadt)) {=0A 		ACPI_WARNING((AE_IN=
FO,=0A-			      "FADT (revision %u) is longer than ACPI 2.0 =
version, truncating length 0x%X to 0x%zX",=0A+			      =
"FADT (revision %u) is longer than ACPI 5.0 version,"=0A+			=
      " truncating length %u to %zu",=0A 			      =
table->revision, (unsigned)length,=0A 			      sizeof(struct=
 acpi_table_fadt)));=0A 	}=0A--- a/xen/include/acpi/actbl.h=0A+++ =
b/xen/include/acpi/actbl.h=0A@@ -255,6 +255,8 @@ struct acpi_table_fadt =
{=0A 	struct acpi_generic_address xpm_timer_block;	/* 64-bit Extended =
Power Mgt Timer Ctrl Reg Blk address */=0A 	struct acpi_generic_address=
 xgpe0_block;	/* 64-bit Extended General Purpose Event 0 Reg Blk address =
*/=0A 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended =
General Purpose Event 1 Reg Blk address */=0A+	struct acpi_generic_address=
 sleep_control;	/* 64-bit Sleep Control register */=0A+	struct acpi_generic=
_address sleep_status;	/* 64-bit Sleep Status register */=0A };=0A =0A /* =
Masks for FADT Boot Architecture Flags (boot_flags) */=0A@@ -264,6 +266,7 =
@@ struct acpi_table_fadt {=0A #define ACPI_FADT_NO_VGA            (1<<2)	=
/* 02: [V4] It is not safe to probe for VGA hardware */=0A #define =
ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message Signaled =
Interrupts (MSI) must not be enabled */=0A #define ACPI_FADT_NO_ASPM       =
    (1<<4)	/* 04: [V4] PCIe ASPM control must not be enabled =
*/=0A+#define ACPI_FADT_NO_CMOS_RTC       (1<<5)	/* 05: [V5] No =
CMOS real-time clock present */=0A =0A #define FADT2_REVISION_ID           =
    3=0A =0A@@ -289,6 +292,8 @@ struct acpi_table_fadt {=0A #define =
ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is compatible =
with remote power on (ACPI 3.0) */=0A #define ACPI_FADT_APIC_CLUSTER      =
(1<<18)	/* 18: [V4] All local APICs must use cluster model (ACPI 3.0) =
*/=0A #define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All =
local x_aPICs must use physical dest mode (ACPI 3.0) */=0A+#define =
ACPI_FADT_HW_REDUCED        (1<<20)	/* 20: [V5] ACPI hardware is not =
implemented (ACPI 5.0) */=0A+#define ACPI_FADT_LOW_POWER_S0      (1<<21)	=
/* 21: [V5] S0 power savings are equal or better than S3 (ACPI 5.0) */=0A =
=0A /* Values for preferred_profile (Preferred Power Management Profiles) =
*/=0A =0A@@ -299,14 +304,16 @@ enum acpi_prefered_pm_profiles {=0A 	=
PM_WORKSTATION =3D 3,=0A 	PM_ENTERPRISE_SERVER =3D 4,=0A 	PM_SOHO_SER=
VER =3D 5,=0A-	PM_APPLIANCE_PC =3D 6=0A+	PM_APPLIANCE_PC =3D 6,=0A+	=
PM_PERFORMANCE_SERVER =3D 7,=0A+	PM_TABLET =3D 8=0A };=0A =0A /* =
Reset to default packing */=0A =0A #pragma pack()=0A =0A-#define ACPI_FADT_=
OFFSET(f)             (u8) ACPI_OFFSET (struct acpi_table_fadt, f)=0A+#defi=
ne ACPI_FADT_OFFSET(f)             (u16) ACPI_OFFSET (struct acpi_table_fad=
t, f)=0A =0A /*=0A  * Get the remaining ACPI tables=0A@@ -324,12 +331,15 =
@@ enum acpi_prefered_pm_profiles {=0A  * FADT is the bottom line as to =
what the version really is.=0A  *=0A  * For reference, the values below =
are as follows:=0A- *     FADT V1  size: 0x74=0A- *     FADT V2  size: =
0x84=0A- *     FADT V3+ size: 0xF4=0A+ *     FADT V1  size: 0x074=0A+ *    =
 FADT V2  size: 0x084=0A+ *     FADT V3  size: 0x0F4=0A+ *     FADT V4  =
size: 0x0F4=0A+ *     FADT V5  size: 0x10C=0A  */=0A #define ACPI_FADT_V1_S=
IZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)=0A #define ACPI_FADT_V2_SIZE=
       (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)=0A-#define ACPI_FADT_V3_=
SIZE       (u32) (sizeof (struct acpi_table_fadt))=0A+#define ACPI_FADT_V3_=
SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))=0A+#define ACPI_FADT_V5=
_SIZE       (u32) (sizeof (struct acpi_table_fadt))=0A =0A #endif		=
		/* __ACTBL_H__ */=0A
--=__Part1929631D.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

--=__Part1929631D.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:05:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vpn-0000hd-NV; Thu, 21 Feb 2013 13:05:11 +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 1U8Vpe-0000hP-LP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:05:02 +0000
Received: from [193.109.254.147:47982] by server-14.bemta-14.messagelabs.com
	id 72/45-02031-D7B16215; Thu, 21 Feb 2013 13:05:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361451730!4044631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8749 invoked from network); 21 Feb 2013 13:02:11 -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; 21 Feb 2013 13:02:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:02:10 +0000
Message-Id: <5126291D02000078000BFEBC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:03:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
	<5126280802000078000BFE7F@nat28.tlf.novell.com>
In-Reply-To: <5126280802000078000BFE7F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1929631D.0__="
Subject: Re: [Xen-devel] [PATCH 1/6] ACPI 5.0: Basic support for FADT
 version 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>
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.

--=__Part1929631D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 21.02.13 at 13:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> Signed-off-by: Bob Moore <robert.moore@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Patch now also attached, if needed by anyone.

Jan


--=__Part1929631D.0__=
Content-Type: text/plain; name="ACPI-v5-FADT.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-FADT.patch"

ACPI 5.0: Basic support for FADT version 5=0A=0ASigned-off-by: Bob Moore =
<robert.moore@intel.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/drivers/acpi/tables/tbfadt.c=0A+++ b/xen/drivers/acpi/table=
s/tbfadt.c=0A@@ -222,12 +222,13 @@ void __init acpi_tb_create_local_fadt(st=
=0A =0A 	/*=0A 	 * Check if the FADT is larger than the largest =
table that we expect=0A-	 * (the ACPI 2.0/3.0 version). If so, =
truncate the table, and issue=0A+	 * (the ACPI 5.0 version). If so, =
truncate the table, and issue=0A 	 * a warning.=0A 	 */=0A 	if =
(length > sizeof(struct acpi_table_fadt)) {=0A 		ACPI_WARNING((AE_IN=
FO,=0A-			      "FADT (revision %u) is longer than ACPI 2.0 =
version, truncating length 0x%X to 0x%zX",=0A+			      =
"FADT (revision %u) is longer than ACPI 5.0 version,"=0A+			=
      " truncating length %u to %zu",=0A 			      =
table->revision, (unsigned)length,=0A 			      sizeof(struct=
 acpi_table_fadt)));=0A 	}=0A--- a/xen/include/acpi/actbl.h=0A+++ =
b/xen/include/acpi/actbl.h=0A@@ -255,6 +255,8 @@ struct acpi_table_fadt =
{=0A 	struct acpi_generic_address xpm_timer_block;	/* 64-bit Extended =
Power Mgt Timer Ctrl Reg Blk address */=0A 	struct acpi_generic_address=
 xgpe0_block;	/* 64-bit Extended General Purpose Event 0 Reg Blk address =
*/=0A 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended =
General Purpose Event 1 Reg Blk address */=0A+	struct acpi_generic_address=
 sleep_control;	/* 64-bit Sleep Control register */=0A+	struct acpi_generic=
_address sleep_status;	/* 64-bit Sleep Status register */=0A };=0A =0A /* =
Masks for FADT Boot Architecture Flags (boot_flags) */=0A@@ -264,6 +266,7 =
@@ struct acpi_table_fadt {=0A #define ACPI_FADT_NO_VGA            (1<<2)	=
/* 02: [V4] It is not safe to probe for VGA hardware */=0A #define =
ACPI_FADT_NO_MSI            (1<<3)	/* 03: [V4] Message Signaled =
Interrupts (MSI) must not be enabled */=0A #define ACPI_FADT_NO_ASPM       =
    (1<<4)	/* 04: [V4] PCIe ASPM control must not be enabled =
*/=0A+#define ACPI_FADT_NO_CMOS_RTC       (1<<5)	/* 05: [V5] No =
CMOS real-time clock present */=0A =0A #define FADT2_REVISION_ID           =
    3=0A =0A@@ -289,6 +292,8 @@ struct acpi_table_fadt {=0A #define =
ACPI_FADT_REMOTE_POWER_ON   (1<<17)	/* 17: [V4] System is compatible =
with remote power on (ACPI 3.0) */=0A #define ACPI_FADT_APIC_CLUSTER      =
(1<<18)	/* 18: [V4] All local APICs must use cluster model (ACPI 3.0) =
*/=0A #define ACPI_FADT_APIC_PHYSICAL     (1<<19)	/* 19: [V4] All =
local x_aPICs must use physical dest mode (ACPI 3.0) */=0A+#define =
ACPI_FADT_HW_REDUCED        (1<<20)	/* 20: [V5] ACPI hardware is not =
implemented (ACPI 5.0) */=0A+#define ACPI_FADT_LOW_POWER_S0      (1<<21)	=
/* 21: [V5] S0 power savings are equal or better than S3 (ACPI 5.0) */=0A =
=0A /* Values for preferred_profile (Preferred Power Management Profiles) =
*/=0A =0A@@ -299,14 +304,16 @@ enum acpi_prefered_pm_profiles {=0A 	=
PM_WORKSTATION =3D 3,=0A 	PM_ENTERPRISE_SERVER =3D 4,=0A 	PM_SOHO_SER=
VER =3D 5,=0A-	PM_APPLIANCE_PC =3D 6=0A+	PM_APPLIANCE_PC =3D 6,=0A+	=
PM_PERFORMANCE_SERVER =3D 7,=0A+	PM_TABLET =3D 8=0A };=0A =0A /* =
Reset to default packing */=0A =0A #pragma pack()=0A =0A-#define ACPI_FADT_=
OFFSET(f)             (u8) ACPI_OFFSET (struct acpi_table_fadt, f)=0A+#defi=
ne ACPI_FADT_OFFSET(f)             (u16) ACPI_OFFSET (struct acpi_table_fad=
t, f)=0A =0A /*=0A  * Get the remaining ACPI tables=0A@@ -324,12 +331,15 =
@@ enum acpi_prefered_pm_profiles {=0A  * FADT is the bottom line as to =
what the version really is.=0A  *=0A  * For reference, the values below =
are as follows:=0A- *     FADT V1  size: 0x74=0A- *     FADT V2  size: =
0x84=0A- *     FADT V3+ size: 0xF4=0A+ *     FADT V1  size: 0x074=0A+ *    =
 FADT V2  size: 0x084=0A+ *     FADT V3  size: 0x0F4=0A+ *     FADT V4  =
size: 0x0F4=0A+ *     FADT V5  size: 0x10C=0A  */=0A #define ACPI_FADT_V1_S=
IZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)=0A #define ACPI_FADT_V2_SIZE=
       (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)=0A-#define ACPI_FADT_V3_=
SIZE       (u32) (sizeof (struct acpi_table_fadt))=0A+#define ACPI_FADT_V3_=
SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))=0A+#define ACPI_FADT_V5=
_SIZE       (u32) (sizeof (struct acpi_table_fadt))=0A =0A #endif		=
		/* __ACTBL_H__ */=0A
--=__Part1929631D.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

--=__Part1929631D.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:06:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vqy-0000uC-Ln; Thu, 21 Feb 2013 13:06: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 1U8Vqx-0000tt-F7
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 13:06:23 +0000
Received: from [85.158.143.99:3192] by server-3.bemta-4.messagelabs.com id
	A5/CE-02186-ECB16215; Thu, 21 Feb 2013 13:06:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361451981!18775580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20313 invoked from network); 21 Feb 2013 13:06:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:06:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1731519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 13:06: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.297.1;
	Thu, 21 Feb 2013 13:06:21 +0000
Message-ID: <1361451979.26546.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 21 Feb 2013 13:06:19 +0000
In-Reply-To: <20130221130013.GA7240@phenom.dumpdata.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 13:00 +0000, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
> and I kept on getting:
> xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed (rc=-3): Internal error
> 
> Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> bisection but any thoughts off which one I ought to try out first?

Tools changesets in that range are:
        $ hg log -r  23431:23459 tools/
        changeset:   23452:47c7b8531923
        user:        Ian Jackson <ian.jackson@eu.citrix.com>
        date:        Thu Feb 07 14:26:29 2013 +0000
        summary:     tools/ocaml: oxenstored: Be more paranoid about ring reading
        
        changeset:   23453:130446135528
        user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
        date:        Thu Feb 07 14:26:37 2013 +0000
        summary:     oxenstored: Enforce a maximum message size of 4096 bytes
        
        changeset:   23457:8792a805cc9a
        user:        Ian Campbell <ian.campbell@citrix.com>
        date:        Fri Feb 15 11:50:45 2013 +0000
        summary:     tools/ocaml: oxenstored: correctly handle a full ring.

None of which look even vaguely plausible to me. There's some XZ fixes
on the hypervisor side, but this is a guest and GZIP so that seem
unlikely too.

A gzip internal error seems like it should come from zlib and not
something on the Xen side. Was the guest image completely unchanged in
your two tests? Any chance the rebuild picked up a different zlib?

Ian.
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:06:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vqy-0000uC-Ln; Thu, 21 Feb 2013 13:06: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 1U8Vqx-0000tt-F7
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 13:06:23 +0000
Received: from [85.158.143.99:3192] by server-3.bemta-4.messagelabs.com id
	A5/CE-02186-ECB16215; Thu, 21 Feb 2013 13:06:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361451981!18775580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20313 invoked from network); 21 Feb 2013 13:06:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:06:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="1731519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 13:06: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.297.1;
	Thu, 21 Feb 2013 13:06:21 +0000
Message-ID: <1361451979.26546.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 21 Feb 2013 13:06:19 +0000
In-Reply-To: <20130221130013.GA7240@phenom.dumpdata.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 13:00 +0000, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
> and I kept on getting:
> xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed (rc=-3): Internal error
> 
> Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> bisection but any thoughts off which one I ought to try out first?

Tools changesets in that range are:
        $ hg log -r  23431:23459 tools/
        changeset:   23452:47c7b8531923
        user:        Ian Jackson <ian.jackson@eu.citrix.com>
        date:        Thu Feb 07 14:26:29 2013 +0000
        summary:     tools/ocaml: oxenstored: Be more paranoid about ring reading
        
        changeset:   23453:130446135528
        user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
        date:        Thu Feb 07 14:26:37 2013 +0000
        summary:     oxenstored: Enforce a maximum message size of 4096 bytes
        
        changeset:   23457:8792a805cc9a
        user:        Ian Campbell <ian.campbell@citrix.com>
        date:        Fri Feb 15 11:50:45 2013 +0000
        summary:     tools/ocaml: oxenstored: correctly handle a full ring.

None of which look even vaguely plausible to me. There's some XZ fixes
on the hypervisor side, but this is a guest and GZIP so that seem
unlikely too.

A gzip internal error seems like it should come from zlib and not
something on the Xen side. Was the guest image completely unchanged in
your two tests? Any chance the rebuild picked up a different zlib?

Ian.
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:06:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8VrC-0000xU-37; Thu, 21 Feb 2013 13:06: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 1U8VrA-0000x7-Bs
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 13:06:36 +0000
Received: from [85.158.137.99:53072] by server-13.bemta-3.messagelabs.com id
	BB/46-20653-BDB16215; Thu, 21 Feb 2013 13:06:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361451913!17418962!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTAxNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11074 invoked from network); 21 Feb 2013 13:05:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 13:05:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LD5CAv032614
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:05:12 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
	r1LD5BaC008635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:05:12 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
	r1LD5B3h011592
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 07:05:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 05:05:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D4731C3935; Thu, 21 Feb 2013 08:05:10 -0500 (EST)
Date: Thu, 21 Feb 2013 08:05:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130221130510.GB7240@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] Linux v3.9-rc0, three different bootup 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

Heya,

I am hitting _three_ different regressions on v3.9-rc0. I was
wondering if anybody is willing to help me out in narrowing down
the faulty git commits.

The first one is when booting PV guests:

[    0.831091] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
[    0.831107] IP: [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
[    0.831122] PGD 0 
[    0.831130] Oops: 0000 [#1] SMP 
[    0.831142] Modules linked in:
[    0.831150] CPU 0 
[    0.831156] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-03229-ge1f5dd0 #1  
[    0.831166] RIP: e030:[<ffffffff8138978a>]  [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
[    0.831178] RSP: e02b:ffff88003d369e88  EFLAGS: 00010246
[    0.831185] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000000
[    0.831193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81329ae0
[    0.831200] RBP: ffff88003d369ea8 R08: 0000000000000000 R09: 0000000000000000
[    0.831208] R10: 0000000000007ff0 R11: 0000000000000002 R12: 0000000000000000
[    0.831215] R13: ffffffff81329ae0 R14: 0000000000000000 R15: 0000000000000000
[    0.831227] FS:  0000000000000000(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
[    0.831236] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.831242] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000000660
[    0.831251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.831258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    0.831266] Process swapper/0 (pid: 1, threadinfo ffff88003d368000, task ffff88003d362800)
[    0.831274] Stack:
[    0.831280]  0000000000000030 0000000000000000 ffffffff81ae960e ffffffff81b402e8
[    0.831298]  ffff88003d369eb8 ffffffff81329b3b ffff88003d369ec8 ffffffff81ae9620
[    0.831316]  ffff88003d369ef8 ffffffff8100203d 0000000000000030 0000000000000007
[    0.831336] Call Trace:
[    0.831347]  [<ffffffff81ae960e>] ? pcie_portdrv_init+0x7a/0x7a
[    0.831359]  [<ffffffff81329b3b>] aer_acpi_firmware_first+0x1b/0x30
[    0.831370]  [<ffffffff81ae9620>] aer_service_init+0x12/0x2b
[    0.831380]  [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
[    0.831391]  [<ffffffff81abd82c>] kernel_init_freeable+0x157/0x1e6
[    0.831401]  [<ffffffff81abd8bb>] ? kernel_init_freeable+0x1e6/0x1e6
[    0.831412]  [<ffffffff81647e90>] ? rest_init+0xa0/0xa0
[    0.831422]  [<ffffffff81647e99>] kernel_init+0x9/0xf0
[    0.831432]  [<ffffffff816669fc>] ret_from_fork+0x7c/0xb0
[    0.831442]  [<ffffffff81647e90>] ? rest_init+0xa0/0xa0
[    0.831448] Code: 90 55 80 3d 00 3f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 4

The second when booting PVHVM guests:

[   28.249000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
[   28.249000] Modules linked in:
[   28.249000] CPU 0 
[   28.249000] Pid: 8, comm: migration/0 Not tainted 3.8.0upstream-03229-ge1f5dd0 #1 Xen HVM domU
[   28.249000] RIP: 0010:[<ffffffff81105bdb>]  [<ffffffff81105bdb>] stop_machine_cpu_stop+0x7b/0xf0
[   28.249000] RSP: 0000:ffff88003aa49d38  EFLAGS: 00000293
[   28.249000] RAX: 0000000000000001 RBX: ffffffff810bff77 RCX: 0000000000000000
[   28.249000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff88003aa33de8
[   28.249000] RBP: ffff88003aa49d68 R08: 0000000000000000 R09: 0000000000000001
[   28.249000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff88003aa48000
[   28.249000] R13: 0000000000000000 R14: ffffffff810c96d5 R15: ffff88003aa49cb8
[   28.249000] FS:  0000000000000000(0000) GS:ffff88003ae00000(0000) knlGS:0000000000000000
[   28.249000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.249000] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000006f0
[   28.249000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   28.249000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   28.249000] Process migration/0 (pid: 8, threadinfo ffff88003aa48000, task ffff88003aa2c000)
[   28.249000] Stack:
[   28.249000]  ffff88003aa49d98 ffff88003aa33d58 ffff88003aa48000 ffffffff81105b60
[   28.249000]  ffff88003aa33de8 ffff88003ae0e5e0 ffff88003aa49e48 ffffffff811058b3
[   28.249000]  ffff88003aa49da8 ffff88003aa49fd8 ffff88003ae0e5e8 ffff88003aa48000
[   28.249000] Call Trace:
[   28.249000]  [<ffffffff81105b60>] ? stop_one_cpu_nowait+0x30/0x30
[   28.249000]  [<ffffffff811058b3>] cpu_stopper_thread+0xb3/0x160
[   28.249000]  [<ffffffff8165d65e>] ? __schedule+0x3be/0x7d0
[   28.249000]  [<ffffffff8107f079>] ? default_spin_lock_flags+0x9/0x10
[   28.249000]  [<ffffffff810bebd7>] smpboot_thread_fn+0x157/0x1e0
[   28.249000]  [<ffffffff810bea80>] ? smpboot_create_threads+0x80/0x80
[   28.249000]  [<ffffffff810b5f06>] kthread+0xc6/0xd0
[   28.249000]  [<ffffffff810b5e40>] ? kthread_freezable_should_stop+0x80/0x80
[   28.249000]  [<ffffffff816669fc>] ret_from_fork+0x7c/0xb0
[   28.249000]  [<ffffffff810b5e40>] ? kthread_freezable_should_stop+0x80/0x80
[   28.249000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 


And the third when booting dom0 and with xen-acpi-processor it ends
up with -22 right after:

[   14.712473] xen-acpi-processor: Max ACPI ID: 8



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:06:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8VrC-0000xU-37; Thu, 21 Feb 2013 13:06: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 1U8VrA-0000x7-Bs
	for xen-devel@lists.xensource.com; Thu, 21 Feb 2013 13:06:36 +0000
Received: from [85.158.137.99:53072] by server-13.bemta-3.messagelabs.com id
	BB/46-20653-BDB16215; Thu, 21 Feb 2013 13:06:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361451913!17418962!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTAxNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11074 invoked from network); 21 Feb 2013 13:05:14 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 13:05:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LD5CAv032614
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:05:12 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
	r1LD5BaC008635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 13:05:12 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
	r1LD5B3h011592
	for <xen-devel@lists.xensource.com>; Thu, 21 Feb 2013 07:05:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 05:05:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D4731C3935; Thu, 21 Feb 2013 08:05:10 -0500 (EST)
Date: Thu, 21 Feb 2013 08:05:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130221130510.GB7240@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] Linux v3.9-rc0, three different bootup 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

Heya,

I am hitting _three_ different regressions on v3.9-rc0. I was
wondering if anybody is willing to help me out in narrowing down
the faulty git commits.

The first one is when booting PV guests:

[    0.831091] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
[    0.831107] IP: [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
[    0.831122] PGD 0 
[    0.831130] Oops: 0000 [#1] SMP 
[    0.831142] Modules linked in:
[    0.831150] CPU 0 
[    0.831156] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-03229-ge1f5dd0 #1  
[    0.831166] RIP: e030:[<ffffffff8138978a>]  [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
[    0.831178] RSP: e02b:ffff88003d369e88  EFLAGS: 00010246
[    0.831185] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000000
[    0.831193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81329ae0
[    0.831200] RBP: ffff88003d369ea8 R08: 0000000000000000 R09: 0000000000000000
[    0.831208] R10: 0000000000007ff0 R11: 0000000000000002 R12: 0000000000000000
[    0.831215] R13: ffffffff81329ae0 R14: 0000000000000000 R15: 0000000000000000
[    0.831227] FS:  0000000000000000(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
[    0.831236] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.831242] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000000660
[    0.831251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.831258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    0.831266] Process swapper/0 (pid: 1, threadinfo ffff88003d368000, task ffff88003d362800)
[    0.831274] Stack:
[    0.831280]  0000000000000030 0000000000000000 ffffffff81ae960e ffffffff81b402e8
[    0.831298]  ffff88003d369eb8 ffffffff81329b3b ffff88003d369ec8 ffffffff81ae9620
[    0.831316]  ffff88003d369ef8 ffffffff8100203d 0000000000000030 0000000000000007
[    0.831336] Call Trace:
[    0.831347]  [<ffffffff81ae960e>] ? pcie_portdrv_init+0x7a/0x7a
[    0.831359]  [<ffffffff81329b3b>] aer_acpi_firmware_first+0x1b/0x30
[    0.831370]  [<ffffffff81ae9620>] aer_service_init+0x12/0x2b
[    0.831380]  [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
[    0.831391]  [<ffffffff81abd82c>] kernel_init_freeable+0x157/0x1e6
[    0.831401]  [<ffffffff81abd8bb>] ? kernel_init_freeable+0x1e6/0x1e6
[    0.831412]  [<ffffffff81647e90>] ? rest_init+0xa0/0xa0
[    0.831422]  [<ffffffff81647e99>] kernel_init+0x9/0xf0
[    0.831432]  [<ffffffff816669fc>] ret_from_fork+0x7c/0xb0
[    0.831442]  [<ffffffff81647e90>] ? rest_init+0xa0/0xa0
[    0.831448] Code: 90 55 80 3d 00 3f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 4

The second when booting PVHVM guests:

[   28.249000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
[   28.249000] Modules linked in:
[   28.249000] CPU 0 
[   28.249000] Pid: 8, comm: migration/0 Not tainted 3.8.0upstream-03229-ge1f5dd0 #1 Xen HVM domU
[   28.249000] RIP: 0010:[<ffffffff81105bdb>]  [<ffffffff81105bdb>] stop_machine_cpu_stop+0x7b/0xf0
[   28.249000] RSP: 0000:ffff88003aa49d38  EFLAGS: 00000293
[   28.249000] RAX: 0000000000000001 RBX: ffffffff810bff77 RCX: 0000000000000000
[   28.249000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff88003aa33de8
[   28.249000] RBP: ffff88003aa49d68 R08: 0000000000000000 R09: 0000000000000001
[   28.249000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff88003aa48000
[   28.249000] R13: 0000000000000000 R14: ffffffff810c96d5 R15: ffff88003aa49cb8
[   28.249000] FS:  0000000000000000(0000) GS:ffff88003ae00000(0000) knlGS:0000000000000000
[   28.249000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.249000] CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000006f0
[   28.249000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   28.249000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   28.249000] Process migration/0 (pid: 8, threadinfo ffff88003aa48000, task ffff88003aa2c000)
[   28.249000] Stack:
[   28.249000]  ffff88003aa49d98 ffff88003aa33d58 ffff88003aa48000 ffffffff81105b60
[   28.249000]  ffff88003aa33de8 ffff88003ae0e5e0 ffff88003aa49e48 ffffffff811058b3
[   28.249000]  ffff88003aa49da8 ffff88003aa49fd8 ffff88003ae0e5e8 ffff88003aa48000
[   28.249000] Call Trace:
[   28.249000]  [<ffffffff81105b60>] ? stop_one_cpu_nowait+0x30/0x30
[   28.249000]  [<ffffffff811058b3>] cpu_stopper_thread+0xb3/0x160
[   28.249000]  [<ffffffff8165d65e>] ? __schedule+0x3be/0x7d0
[   28.249000]  [<ffffffff8107f079>] ? default_spin_lock_flags+0x9/0x10
[   28.249000]  [<ffffffff810bebd7>] smpboot_thread_fn+0x157/0x1e0
[   28.249000]  [<ffffffff810bea80>] ? smpboot_create_threads+0x80/0x80
[   28.249000]  [<ffffffff810b5f06>] kthread+0xc6/0xd0
[   28.249000]  [<ffffffff810b5e40>] ? kthread_freezable_should_stop+0x80/0x80
[   28.249000]  [<ffffffff816669fc>] ret_from_fork+0x7c/0xb0
[   28.249000]  [<ffffffff810b5e40>] ? kthread_freezable_should_stop+0x80/0x80
[   28.249000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 


And the third when booting dom0 and with xen-acpi-processor it ends
up with -22 right after:

[   14.712473] xen-acpi-processor: Max ACPI ID: 8



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:11:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vvw-0001SV-25; Thu, 21 Feb 2013 13:11: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 1U8Vvv-0001SM-52
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:11:31 +0000
Received: from [193.109.254.147:60284] by server-14.bemta-14.messagelabs.com
	id 8C/AE-02031-20D16215; Thu, 21 Feb 2013 13:11:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361451586!8829840!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28887 invoked from network); 21 Feb 2013 12:59:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:59:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:59:46 +0000
Message-Id: <5126288C02000078000BFE8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:00:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6959136C.0__="
Subject: [Xen-devel] [PATCH 4/6] ACPI: support v5 (reduced HW) sleep
	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

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.

--=__Part6959136C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Note that this also fixes a broken input check in acpi_enter_sleep()
(previously validating the sleep->pm1[ab]_cnt_val relationship based
on acpi_sinfo.pm1b_cnt_val, which however gets set only subsequently).

Also adjust a few minor issues with the pre-v5 handling in
acpi_fadt_parse_sleep_info().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
A question is whether, rather than passing the raw values read from
_Sx to XENPF_enter_acpi_sleep, we should again have Dom0 pass the
values ready to be written into the registers - that would make things
consistent with the legacy case, but add further dependency of the
hypervisor on Dom0 behavior where it's not really needed. I think that
it was a mistake for the original variant to have Dom0 pass massaged
values to the hypervisor.

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -310,14 +310,15 @@ static int __init acpi_invalidate_bgrt(s
=20
 #ifdef CONFIG_ACPI_SLEEP
 #define acpi_fadt_copy_address(dst, src, len) do {			\
-	if (fadt->header.revision >=3D FADT2_REVISION_ID)			=
\
+	if (fadt->header.revision >=3D FADT2_REVISION_ID &&		\
+	    fadt->header.length >=3D ACPI_FADT_V2_SIZE)			\
 		acpi_sinfo.dst##_blk =3D fadt->x##src##_block;		\
 	if (!acpi_sinfo.dst##_blk.address) {				\
 		acpi_sinfo.dst##_blk.address      =3D fadt->src##_block;	=
\
 		acpi_sinfo.dst##_blk.space_id     =3D ACPI_ADR_SPACE_SYSTEM=
_IO; \
 		acpi_sinfo.dst##_blk.bit_width    =3D fadt->len##_length =
<< 3; \
 		acpi_sinfo.dst##_blk.bit_offset   =3D 0;			=
\
-		acpi_sinfo.dst##_blk.access_width =3D 0;			=
\
+		acpi_sinfo.dst##_blk.access_width =3D fadt->len##_length;	=
\
 	} \
 } while (0)
=20
@@ -328,6 +329,41 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	struct acpi_table_facs *facs =3D NULL;
 	uint64_t facs_pa;
=20
+	if (fadt->header.revision >=3D 5 &&
+	    fadt->header.length >=3D ACPI_FADT_V5_SIZE) {
+		acpi_sinfo.sleep_control =3D fadt->sleep_control;
+		acpi_sinfo.sleep_status =3D fadt->sleep_status;
+
+		printk(KERN_INFO PREFIX
+		       "v5 SLEEP INFO: control[%d:%"PRIx64"],"
+		       " status[%d:%"PRIx64"]\n",
+		       acpi_sinfo.sleep_control.space_id,
+		       acpi_sinfo.sleep_control.address,
+		       acpi_sinfo.sleep_status.space_id,
+		       acpi_sinfo.sleep_status.address);
+
+		if ((fadt->sleep_control.address &&
+		     (fadt->sleep_control.bit_offset ||
+		      fadt->sleep_control.bit_width !=3D
+		      fadt->sleep_control.access_width * 8)) ||
+		    (fadt->sleep_status.address &&
+		     (fadt->sleep_status.bit_offset ||
+		      fadt->sleep_status.bit_width !=3D
+		      fadt->sleep_status.access_width * 8))) {
+			printk(KERN_WARNING PREFIX
+			       "Invalid sleep control/status register =
data:"
+			       " %#x:%#x:%#x %#x:%#x:%#x\n",
+			       fadt->sleep_control.bit_offset,
+			       fadt->sleep_control.bit_width,
+			       fadt->sleep_control.access_width,
+			       fadt->sleep_status.bit_offset,
+			       fadt->sleep_status.bit_width,
+			       fadt->sleep_status.access_width);
+			fadt->sleep_control.address =3D 0;
+			fadt->sleep_status.address =3D 0;
+		}
+	}
+
 	if (fadt->flags & ACPI_FADT_HW_REDUCED)
 		goto bad;
=20
@@ -337,7 +373,7 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	acpi_fadt_copy_address(pm1b_evt, pm1b_event, pm1_event);
=20
 	printk(KERN_INFO PREFIX
-	       "ACPI SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "
+	       "SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "
 	       "pm1x_evt[%"PRIx64",%"PRIx64"]\n",
 	       acpi_sinfo.pm1a_cnt_blk.address,
 	       acpi_sinfo.pm1b_cnt_blk.address,
@@ -384,11 +420,14 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	acpi_sinfo.vector_width =3D 32;
=20
 	printk(KERN_INFO PREFIX
-	       "                 wakeup_vec[%"PRIx64"], vec_size[%x]\n",
+	       "            wakeup_vec[%"PRIx64"], vec_size[%x]\n",
 	       acpi_sinfo.wakeup_vector, acpi_sinfo.vector_width);
 	return;
 bad:
-	memset(&acpi_sinfo, 0, sizeof(acpi_sinfo));
+	memset(&acpi_sinfo, 0,
+	       offsetof(struct acpi_sleep_info, sleep_control));
+	memset(&acpi_sinfo.sleep_status + 1, 0,
+	       (long)(&acpi_sinfo + 1) - (long)(&acpi_sinfo.sleep_status + =
1));
 }
 #endif
=20
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -239,23 +239,47 @@ static long enter_state_helper(void *dat
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )
+    {
+        if ( !acpi_sinfo.sleep_control.address ||
+             !acpi_sinfo.sleep_status.address )
+            return -EPERM;
+
+        if ( sleep->flags & ~XENPF_ACPI_SLEEP_EXTENDED )
+            return -EINVAL;
+
+        if ( sleep->val_a > ACPI_SLEEP_TYPE_MAX ||
+             (sleep->val_b !=3D ACPI_SLEEP_TYPE_INVALID &&
+              sleep->val_b > ACPI_SLEEP_TYPE_MAX) )
+            return -ERANGE;
+
+        acpi_sinfo.sleep_type_a =3D sleep->val_a;
+        acpi_sinfo.sleep_type_b =3D sleep->val_b;
+
+        acpi_sinfo.sleep_extended =3D 1;
+    }
+
+    else if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
=20
     /* Sanity check */
-    if ( acpi_sinfo.pm1b_cnt_val &&
-         ((sleep->pm1a_cnt_val ^ sleep->pm1b_cnt_val) &
-          ACPI_BITMASK_SLEEP_ENABLE) )
+    else if ( sleep->val_b &&
+              ((sleep->val_a ^ sleep->val_b) & ACPI_BITMASK_SLEEP_ENABLE) =
)
     {
         gdprintk(XENLOG_ERR, "Mismatched pm1a/pm1b setting.");
         return -EINVAL;
     }
=20
-    if ( sleep->flags )
+    else if ( sleep->flags )
         return -EINVAL;
=20
-    acpi_sinfo.pm1a_cnt_val =3D sleep->pm1a_cnt_val;
-    acpi_sinfo.pm1b_cnt_val =3D sleep->pm1b_cnt_val;
+    else
+    {
+        acpi_sinfo.pm1a_cnt_val =3D sleep->val_a;
+        acpi_sinfo.pm1b_cnt_val =3D sleep->val_b;
+        acpi_sinfo.sleep_extended =3D 0;
+    }
+
     acpi_sinfo.sleep_state =3D sleep->sleep_state;
=20
     return continue_hypercall_on_cpu(0, enter_state_helper, &acpi_sinfo);
@@ -266,6 +290,13 @@ static int acpi_get_wake_status(void)
     uint32_t val;
     acpi_status status;
=20
+    if ( acpi_sinfo.sleep_extended )
+    {
+        status =3D acpi_hw_register_read(ACPI_REGISTER_SLEEP_STATUS, =
&val);
+
+        return ACPI_FAILURE(status) ? 0 : val & ACPI_X_WAKE_STATUS;
+    }
+
     /* Wake status is the 15th bit of PM1 status register. (ACPI spec =
3.0) */
     status =3D acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &val);
     if ( ACPI_FAILURE(status) )
@@ -335,19 +366,33 @@ acpi_status acpi_enter_sleep_state(u8 sl
=20
     ACPI_FLUSH_CPU_CACHE();
=20
-    status =3D acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL,=20
-                                    acpi_sinfo.pm1a_cnt_val);
-    if ( ACPI_FAILURE(status) )
-        return_ACPI_STATUS(AE_ERROR);
-
-    if ( acpi_sinfo.pm1b_cnt_blk.address )
+    if ( acpi_sinfo.sleep_extended )
     {
-        status =3D acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL,=20
-                                        acpi_sinfo.pm1b_cnt_val);
-        if ( ACPI_FAILURE(status) )
-            return_ACPI_STATUS(AE_ERROR);
+        /*
+         * Set the SLP_TYP and SLP_EN bits.
+         *
+         * Note: We only use the first value returned by the \_Sx method
+         * (acpi_sinfo.sleep_type_a) - As per ACPI specification.
+         */
+        u8 sleep_type_value =3D
+            ((acpi_sinfo.sleep_type_a << ACPI_X_SLEEP_TYPE_POSITION) &
+             ACPI_X_SLEEP_TYPE_MASK) | ACPI_X_SLEEP_ENABLE;
+
+        status =3D acpi_hw_register_write(ACPI_REGISTER_SLEEP_CONTROL,
+                                        sleep_type_value);
+    }
+    else
+    {
+        status =3D acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL,
+                                        acpi_sinfo.pm1a_cnt_val);
+        if ( !ACPI_FAILURE(status) && acpi_sinfo.pm1b_cnt_blk.address )
+            status =3D acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL,
+                                            acpi_sinfo.pm1b_cnt_val);
     }
=20
+    if ( ACPI_FAILURE(status) )
+        return_ACPI_STATUS(AE_ERROR);
+
     /* Wait until we enter sleep state, and spin until we wake */
     while ( !acpi_get_wake_status() )
         continue;
--- a/xen/drivers/acpi/hwregs.c
+++ b/xen/drivers/acpi/hwregs.c
@@ -365,6 +365,14 @@ acpi_hw_register_read(u32 register_id, u
 		    acpi_os_read_port(acpi_gbl_FADT.smi_command, &value1, =
8);
 		break;
=20
+	case ACPI_REGISTER_SLEEP_STATUS:
+
+		status =3D
+		    acpi_hw_low_level_read(acpi_gbl_FADT.sleep_status.bit_w=
idth,
+					   &value1,
+					   &acpi_gbl_FADT.sleep_status);
+		break;
+
 	default:
 		ACPI_DEBUG_PRINT((AE_INFO, "Unknown Register ID: %X", =
register_id));
 		status =3D AE_BAD_PARAMETER;
@@ -525,6 +533,14 @@ acpi_status acpi_hw_register_write(u32 r
 		    acpi_os_write_port(acpi_gbl_FADT.smi_command, value, =
8);
 		break;
=20
+	case ACPI_REGISTER_SLEEP_CONTROL:
+
+		status =3D
+		    acpi_hw_low_level_write(acpi_gbl_FADT.sleep_control.bit=
_width,
+					    value,
+					    &acpi_gbl_FADT.sleep_control);
+		break;
+
 	default:
 		status =3D AE_BAD_PARAMETER;
 		break;
--- a/xen/include/acpi/aclocal.h
+++ b/xen/include/acpi/aclocal.h
@@ -128,6 +128,8 @@ struct acpi_bit_register_info {
 #define ACPI_REGISTER_PM_TIMER                  0x07
 #define ACPI_REGISTER_PROCESSOR_BLOCK           0x08
 #define ACPI_REGISTER_SMI_COMMAND_BLOCK         0x09
+#define ACPI_REGISTER_SLEEP_CONTROL             0x0a
+#define ACPI_REGISTER_SLEEP_STATUS              0x0b
=20
 /* Masks used to access the bit_registers */
=20
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -309,6 +309,13 @@ enum acpi_prefered_pm_profiles {
 	PM_TABLET =3D 8
 };
=20
+/* Values for sleep_status and sleep_control registers (V5 FADT) */
+
+#define ACPI_X_WAKE_STATUS          0x80
+#define ACPI_X_SLEEP_TYPE_MASK      0x1C
+#define ACPI_X_SLEEP_TYPE_POSITION  0x02
+#define ACPI_X_SLEEP_ENABLE         0x20
+
 /* Reset to default packing */
=20
 #pragma pack()
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -126,11 +126,20 @@ struct acpi_sleep_info {
     struct acpi_generic_address pm1b_cnt_blk;
     struct acpi_generic_address pm1a_evt_blk;
     struct acpi_generic_address pm1b_evt_blk;
-    uint16_t pm1a_cnt_val;
-    uint16_t pm1b_cnt_val;
+    struct acpi_generic_address sleep_control;
+    struct acpi_generic_address sleep_status;
+    union {
+        uint16_t pm1a_cnt_val;
+        uint8_t sleep_type_a;
+    };
+    union {
+        uint16_t pm1b_cnt_val;
+        uint8_t sleep_type_b;
+    };
     uint32_t sleep_state;
     uint64_t wakeup_vector;
     uint32_t vector_width;
+    bool_t sleep_extended;
 };
=20
 #endif /* CONFIG_ACPI_SLEEP */
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -290,10 +290,16 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_firmware_i
 #define XENPF_enter_acpi_sleep    51
 struct xenpf_enter_acpi_sleep {
     /* IN variables */
+#if __XEN_INTERFACE_VERSION__ < 0x00040300
     uint16_t pm1a_cnt_val;      /* PM1a control value. */
     uint16_t pm1b_cnt_val;      /* PM1b control value. */
+#else
+    uint16_t val_a;             /* PM1a control / sleep type A. */
+    uint16_t val_b;             /* PM1b control / sleep type B. */
+#endif
     uint32_t sleep_state;       /* Which state to enter (Sn). */
-    uint32_t flags;             /* Must be zero. */
+#define XENPF_ACPI_SLEEP_EXTENDED 0x00000001
+    uint32_t flags;             /* XENPF_ACPI_SLEEP_*. */
 };
 typedef struct xenpf_enter_acpi_sleep xenpf_enter_acpi_sleep_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_enter_acpi_sleep_t);



--=__Part6959136C.0__=
Content-Type: text/plain; name="ACPI-v5-sleep.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-sleep.patch"

ACPI: support v5 (reduced HW) sleep interface=0A=0ANote that this also =
fixes a broken input check in acpi_enter_sleep()=0A(previously validating =
the sleep->pm1[ab]_cnt_val relationship based=0Aon acpi_sinfo.pm1b_cnt_val,=
 which however gets set only subsequently).=0A=0AAlso adjust a few minor =
issues with the pre-v5 handling in=0Aacpi_fadt_parse_sleep_info().=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AA question is whether, =
rather than passing the raw values read from=0A_Sx to XENPF_enter_acpi_slee=
p, we should again have Dom0 pass the=0Avalues ready to be written into =
the registers - that would make things=0Aconsistent with the legacy case, =
but add further dependency of the=0Ahypervisor on Dom0 behavior where it's =
not really needed. I think that=0Ait was a mistake for the original =
variant to have Dom0 pass massaged=0Avalues to the hypervisor.=0A=0A--- =
a/xen/arch/x86/acpi/boot.c=0A+++ b/xen/arch/x86/acpi/boot.c=0A@@ -310,14 =
+310,15 @@ static int __init acpi_invalidate_bgrt(s=0A =0A #ifdef =
CONFIG_ACPI_SLEEP=0A #define acpi_fadt_copy_address(dst, src, len) do {		=
	\=0A-	if (fadt->header.revision >=3D FADT2_REVISION_ID)		=
	\=0A+	if (fadt->header.revision >=3D FADT2_REVISION_ID &&		=
\=0A+	    fadt->header.length >=3D ACPI_FADT_V2_SIZE)			=
\=0A 		acpi_sinfo.dst##_blk =3D fadt->x##src##_block;		=
\=0A 	if (!acpi_sinfo.dst##_blk.address) {				=
\=0A 		acpi_sinfo.dst##_blk.address      =3D fadt->src##_block;	=
\=0A 		acpi_sinfo.dst##_blk.space_id     =3D ACPI_ADR_SPACE_SYSTEM=
_IO; \=0A 		acpi_sinfo.dst##_blk.bit_width    =3D fadt->len##_l=
ength << 3; \=0A 		acpi_sinfo.dst##_blk.bit_offset   =3D 0;	=
		\=0A-		acpi_sinfo.dst##_blk.access_width =3D 0;	=
		\=0A+		acpi_sinfo.dst##_blk.access_width =3D =
fadt->len##_length;	\=0A 	} \=0A } while (0)=0A =0A@@ -328,6 +329,41 =
@@ acpi_fadt_parse_sleep_info(struct acpi_t=0A 	struct acpi_table_facs =
*facs =3D NULL;=0A 	uint64_t facs_pa;=0A =0A+	if (fadt->header.re=
vision >=3D 5 &&=0A+	    fadt->header.length >=3D ACPI_FADT_V5_SIZE) =
{=0A+		acpi_sinfo.sleep_control =3D fadt->sleep_control;=0A+		=
acpi_sinfo.sleep_status =3D fadt->sleep_status;=0A+=0A+		printk(KERN=
_INFO PREFIX=0A+		       "v5 SLEEP INFO: control[%d:%"PRIx64"=
],"=0A+		       " status[%d:%"PRIx64"]\n",=0A+		       =
acpi_sinfo.sleep_control.space_id,=0A+		       acpi_sinfo.sleep_con=
trol.address,=0A+		       acpi_sinfo.sleep_status.space_id,=0A=
+		       acpi_sinfo.sleep_status.address);=0A+=0A+		=
if ((fadt->sleep_control.address &&=0A+		     (fadt->sleep_control.b=
it_offset ||=0A+		      fadt->sleep_control.bit_width =
!=3D=0A+		      fadt->sleep_control.access_width * 8)) =
||=0A+		    (fadt->sleep_status.address &&=0A+		     =
(fadt->sleep_status.bit_offset ||=0A+		      fadt->sleep_status.bi=
t_width !=3D=0A+		      fadt->sleep_status.access_width * =
8))) {=0A+			printk(KERN_WARNING PREFIX=0A+			=
       "Invalid sleep control/status register data:"=0A+			=
       " %#x:%#x:%#x %#x:%#x:%#x\n",=0A+			       =
fadt->sleep_control.bit_offset,=0A+			       fadt->sleep_=
control.bit_width,=0A+			       fadt->sleep_control.access_w=
idth,=0A+			       fadt->sleep_status.bit_offset,=0A+	=
		       fadt->sleep_status.bit_width,=0A+			=
       fadt->sleep_status.access_width);=0A+			fadt->sleep=
_control.address =3D 0;=0A+			fadt->sleep_status.address =
=3D 0;=0A+		}=0A+	}=0A+=0A 	if (fadt->flags & =
ACPI_FADT_HW_REDUCED)=0A 		goto bad;=0A =0A@@ -337,7 +373,7 =
@@ acpi_fadt_parse_sleep_info(struct acpi_t=0A 	acpi_fadt_copy_address(pm1b=
_evt, pm1b_event, pm1_event);=0A =0A 	printk(KERN_INFO PREFIX=0A-	   =
    "ACPI SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "=0A+	       =
"SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "=0A 	       "pm1x_evt[%"=
PRIx64",%"PRIx64"]\n",=0A 	       acpi_sinfo.pm1a_cnt_blk.address,=0A =
	       acpi_sinfo.pm1b_cnt_blk.address,=0A@@ -384,11 +420,14 @@ =
acpi_fadt_parse_sleep_info(struct acpi_t=0A 	acpi_sinfo.vector_width =
=3D 32;=0A =0A 	printk(KERN_INFO PREFIX=0A-	       "                 =
wakeup_vec[%"PRIx64"], vec_size[%x]\n",=0A+	       "            =
wakeup_vec[%"PRIx64"], vec_size[%x]\n",=0A 	       acpi_sinfo.wakeup_ve=
ctor, acpi_sinfo.vector_width);=0A 	return;=0A bad:=0A-	memset(&acp=
i_sinfo, 0, sizeof(acpi_sinfo));=0A+	memset(&acpi_sinfo, 0,=0A+	   =
    offsetof(struct acpi_sleep_info, sleep_control));=0A+	memset(&acp=
i_sinfo.sleep_status + 1, 0,=0A+	       (long)(&acpi_sinfo + 1) - =
(long)(&acpi_sinfo.sleep_status + 1));=0A }=0A #endif=0A =0A--- a/xen/arch/=
x86/acpi/power.c=0A+++ b/xen/arch/x86/acpi/power.c=0A@@ -239,23 +239,47 @@ =
static long enter_state_helper(void *dat=0A  */=0A int acpi_enter_sleep(str=
uct xenpf_enter_acpi_sleep *sleep)=0A {=0A-    if ( !acpi_sinfo.pm1a_cnt_bl=
k.address )=0A+    if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )=0A+    =
{=0A+        if ( !acpi_sinfo.sleep_control.address ||=0A+             =
!acpi_sinfo.sleep_status.address )=0A+            return -EPERM;=0A+=0A+   =
     if ( sleep->flags & ~XENPF_ACPI_SLEEP_EXTENDED )=0A+            =
return -EINVAL;=0A+=0A+        if ( sleep->val_a > ACPI_SLEEP_TYPE_MAX =
||=0A+             (sleep->val_b !=3D ACPI_SLEEP_TYPE_INVALID &&=0A+       =
       sleep->val_b > ACPI_SLEEP_TYPE_MAX) )=0A+            return =
-ERANGE;=0A+=0A+        acpi_sinfo.sleep_type_a =3D sleep->val_a;=0A+      =
  acpi_sinfo.sleep_type_b =3D sleep->val_b;=0A+=0A+        acpi_sinfo.sleep=
_extended =3D 1;=0A+    }=0A+=0A+    else if ( !acpi_sinfo.pm1a_cnt_blk.add=
ress )=0A         return -EPERM;=0A =0A     /* Sanity check */=0A-    if ( =
acpi_sinfo.pm1b_cnt_val &&=0A-         ((sleep->pm1a_cnt_val ^ sleep->pm1b_=
cnt_val) &=0A-          ACPI_BITMASK_SLEEP_ENABLE) )=0A+    else if ( =
sleep->val_b &&=0A+              ((sleep->val_a ^ sleep->val_b) & =
ACPI_BITMASK_SLEEP_ENABLE) )=0A     {=0A         gdprintk(XENLOG_ERR, =
"Mismatched pm1a/pm1b setting.");=0A         return -EINVAL;=0A     }=0A =
=0A-    if ( sleep->flags )=0A+    else if ( sleep->flags )=0A         =
return -EINVAL;=0A =0A-    acpi_sinfo.pm1a_cnt_val =3D sleep->pm1a_cnt_val;=
=0A-    acpi_sinfo.pm1b_cnt_val =3D sleep->pm1b_cnt_val;=0A+    else=0A+   =
 {=0A+        acpi_sinfo.pm1a_cnt_val =3D sleep->val_a;=0A+        =
acpi_sinfo.pm1b_cnt_val =3D sleep->val_b;=0A+        acpi_sinfo.sleep_exten=
ded =3D 0;=0A+    }=0A+=0A     acpi_sinfo.sleep_state =3D sleep->sleep_stat=
e;=0A =0A     return continue_hypercall_on_cpu(0, enter_state_helper, =
&acpi_sinfo);=0A@@ -266,6 +290,13 @@ static int acpi_get_wake_status(void)=
=0A     uint32_t val;=0A     acpi_status status;=0A =0A+    if ( acpi_sinfo=
.sleep_extended )=0A+    {=0A+        status =3D acpi_hw_register_read(ACPI=
_REGISTER_SLEEP_STATUS, &val);=0A+=0A+        return ACPI_FAILURE(status) =
? 0 : val & ACPI_X_WAKE_STATUS;=0A+    }=0A+=0A     /* Wake status is the =
15th bit of PM1 status register. (ACPI spec 3.0) */=0A     status =3D =
acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &val);=0A     if ( =
ACPI_FAILURE(status) )=0A@@ -335,19 +366,33 @@ acpi_status acpi_enter_sleep=
_state(u8 sl=0A =0A     ACPI_FLUSH_CPU_CACHE();=0A =0A-    status =3D =
acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL, =0A-                    =
                acpi_sinfo.pm1a_cnt_val);=0A-    if ( ACPI_FAILURE(status) =
)=0A-        return_ACPI_STATUS(AE_ERROR);=0A-=0A-    if ( acpi_sinfo.pm1b_=
cnt_blk.address )=0A+    if ( acpi_sinfo.sleep_extended )=0A     {=0A-     =
   status =3D acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL, =0A-      =
                                  acpi_sinfo.pm1b_cnt_val);=0A-        if =
( ACPI_FAILURE(status) )=0A-            return_ACPI_STATUS(AE_ERROR);=0A+  =
      /*=0A+         * Set the SLP_TYP and SLP_EN bits.=0A+         *=0A+  =
       * Note: We only use the first value returned by the \_Sx method=0A+ =
        * (acpi_sinfo.sleep_type_a) - As per ACPI specification.=0A+       =
  */=0A+        u8 sleep_type_value =3D=0A+            ((acpi_sinfo.sleep_t=
ype_a << ACPI_X_SLEEP_TYPE_POSITION) &=0A+             ACPI_X_SLEEP_TYPE_MA=
SK) | ACPI_X_SLEEP_ENABLE;=0A+=0A+        status =3D acpi_hw_register_write=
(ACPI_REGISTER_SLEEP_CONTROL,=0A+                                        =
sleep_type_value);=0A+    }=0A+    else=0A+    {=0A+        status =3D =
acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL,=0A+                     =
                   acpi_sinfo.pm1a_cnt_val);=0A+        if ( !ACPI_FAILURE(=
status) && acpi_sinfo.pm1b_cnt_blk.address )=0A+            status =3D =
acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL,=0A+                     =
                       acpi_sinfo.pm1b_cnt_val);=0A     }=0A =0A+    if ( =
ACPI_FAILURE(status) )=0A+        return_ACPI_STATUS(AE_ERROR);=0A+=0A     =
/* Wait until we enter sleep state, and spin until we wake */=0A     while =
( !acpi_get_wake_status() )=0A         continue;=0A--- a/xen/drivers/acpi/h=
wregs.c=0A+++ b/xen/drivers/acpi/hwregs.c=0A@@ -365,6 +365,14 @@ acpi_hw_re=
gister_read(u32 register_id, u=0A 		    acpi_os_read_port(acpi_=
gbl_FADT.smi_command, &value1, 8);=0A 		break;=0A =0A+	case =
ACPI_REGISTER_SLEEP_STATUS:=0A+=0A+		status =3D=0A+		   =
 acpi_hw_low_level_read(acpi_gbl_FADT.sleep_status.bit_width,=0A+		=
			   &value1,=0A+					   =
&acpi_gbl_FADT.sleep_status);=0A+		break;=0A+=0A 	default:=0A=
 		ACPI_DEBUG_PRINT((AE_INFO, "Unknown Register ID: %X", =
register_id));=0A 		status =3D AE_BAD_PARAMETER;=0A@@ -525,6 =
+533,14 @@ acpi_status acpi_hw_register_write(u32 r=0A 		    =
acpi_os_write_port(acpi_gbl_FADT.smi_command, value, 8);=0A 		=
break;=0A =0A+	case ACPI_REGISTER_SLEEP_CONTROL:=0A+=0A+		=
status =3D=0A+		    acpi_hw_low_level_write(acpi_gbl_FADT.sleep_con=
trol.bit_width,=0A+					    value,=0A+		=
			    &acpi_gbl_FADT.sleep_control);=0A+		=
break;=0A+=0A 	default:=0A 		status =3D AE_BAD_PARAMETER;=0A 	=
	break;=0A--- a/xen/include/acpi/aclocal.h=0A+++ b/xen/include/acpi/=
aclocal.h=0A@@ -128,6 +128,8 @@ struct acpi_bit_register_info {=0A #define =
ACPI_REGISTER_PM_TIMER                  0x07=0A #define ACPI_REGISTER_PROCE=
SSOR_BLOCK           0x08=0A #define ACPI_REGISTER_SMI_COMMAND_BLOCK       =
  0x09=0A+#define ACPI_REGISTER_SLEEP_CONTROL             0x0a=0A+#define =
ACPI_REGISTER_SLEEP_STATUS              0x0b=0A =0A /* Masks used to =
access the bit_registers */=0A =0A--- a/xen/include/acpi/actbl.h=0A+++ =
b/xen/include/acpi/actbl.h=0A@@ -309,6 +309,13 @@ enum acpi_prefered_pm_pro=
files {=0A 	PM_TABLET =3D 8=0A };=0A =0A+/* Values for sleep_status =
and sleep_control registers (V5 FADT) */=0A+=0A+#define ACPI_X_WAKE_STATUS =
         0x80=0A+#define ACPI_X_SLEEP_TYPE_MASK      0x1C=0A+#define =
ACPI_X_SLEEP_TYPE_POSITION  0x02=0A+#define ACPI_X_SLEEP_ENABLE         =
0x20=0A+=0A /* Reset to default packing */=0A =0A #pragma pack()=0A--- =
a/xen/include/asm-x86/acpi.h=0A+++ b/xen/include/asm-x86/acpi.h=0A@@ =
-126,11 +126,20 @@ struct acpi_sleep_info {=0A     struct acpi_generic_addr=
ess pm1b_cnt_blk;=0A     struct acpi_generic_address pm1a_evt_blk;=0A     =
struct acpi_generic_address pm1b_evt_blk;=0A-    uint16_t pm1a_cnt_val;=0A-=
    uint16_t pm1b_cnt_val;=0A+    struct acpi_generic_address sleep_control=
;=0A+    struct acpi_generic_address sleep_status;=0A+    union {=0A+      =
  uint16_t pm1a_cnt_val;=0A+        uint8_t sleep_type_a;=0A+    };=0A+    =
union {=0A+        uint16_t pm1b_cnt_val;=0A+        uint8_t sleep_type_b;=
=0A+    };=0A     uint32_t sleep_state;=0A     uint64_t wakeup_vector;=0A  =
   uint32_t vector_width;=0A+    bool_t sleep_extended;=0A };=0A =0A =
#endif /* CONFIG_ACPI_SLEEP */=0A--- a/xen/include/public/platform.h=0A+++ =
b/xen/include/public/platform.h=0A@@ -290,10 +290,16 @@ DEFINE_XEN_GUEST_HA=
NDLE(xenpf_firmware_i=0A #define XENPF_enter_acpi_sleep    51=0A struct =
xenpf_enter_acpi_sleep {=0A     /* IN variables */=0A+#if __XEN_INTERFACE_V=
ERSION__ < 0x00040300=0A     uint16_t pm1a_cnt_val;      /* PM1a control =
value. */=0A     uint16_t pm1b_cnt_val;      /* PM1b control value. =
*/=0A+#else=0A+    uint16_t val_a;             /* PM1a control / sleep =
type A. */=0A+    uint16_t val_b;             /* PM1b control / sleep type =
B. */=0A+#endif=0A     uint32_t sleep_state;       /* Which state to enter =
(Sn). */=0A-    uint32_t flags;             /* Must be zero. */=0A+#define =
XENPF_ACPI_SLEEP_EXTENDED 0x00000001=0A+    uint32_t flags;             /* =
XENPF_ACPI_SLEEP_*. */=0A };=0A typedef struct xenpf_enter_acpi_sleep =
xenpf_enter_acpi_sleep_t;=0A DEFINE_XEN_GUEST_HANDLE(xenpf_enter_acpi_sleep=
_t);=0A
--=__Part6959136C.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

--=__Part6959136C.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:11:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vvw-0001SV-25; Thu, 21 Feb 2013 13:11: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 1U8Vvv-0001SM-52
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:11:31 +0000
Received: from [193.109.254.147:60284] by server-14.bemta-14.messagelabs.com
	id 8C/AE-02031-20D16215; Thu, 21 Feb 2013 13:11:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361451586!8829840!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28887 invoked from network); 21 Feb 2013 12:59:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 12:59:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 12:59:46 +0000
Message-Id: <5126288C02000078000BFE8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:00:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6959136C.0__="
Subject: [Xen-devel] [PATCH 4/6] ACPI: support v5 (reduced HW) sleep
	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

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.

--=__Part6959136C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Note that this also fixes a broken input check in acpi_enter_sleep()
(previously validating the sleep->pm1[ab]_cnt_val relationship based
on acpi_sinfo.pm1b_cnt_val, which however gets set only subsequently).

Also adjust a few minor issues with the pre-v5 handling in
acpi_fadt_parse_sleep_info().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
A question is whether, rather than passing the raw values read from
_Sx to XENPF_enter_acpi_sleep, we should again have Dom0 pass the
values ready to be written into the registers - that would make things
consistent with the legacy case, but add further dependency of the
hypervisor on Dom0 behavior where it's not really needed. I think that
it was a mistake for the original variant to have Dom0 pass massaged
values to the hypervisor.

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -310,14 +310,15 @@ static int __init acpi_invalidate_bgrt(s
=20
 #ifdef CONFIG_ACPI_SLEEP
 #define acpi_fadt_copy_address(dst, src, len) do {			\
-	if (fadt->header.revision >=3D FADT2_REVISION_ID)			=
\
+	if (fadt->header.revision >=3D FADT2_REVISION_ID &&		\
+	    fadt->header.length >=3D ACPI_FADT_V2_SIZE)			\
 		acpi_sinfo.dst##_blk =3D fadt->x##src##_block;		\
 	if (!acpi_sinfo.dst##_blk.address) {				\
 		acpi_sinfo.dst##_blk.address      =3D fadt->src##_block;	=
\
 		acpi_sinfo.dst##_blk.space_id     =3D ACPI_ADR_SPACE_SYSTEM=
_IO; \
 		acpi_sinfo.dst##_blk.bit_width    =3D fadt->len##_length =
<< 3; \
 		acpi_sinfo.dst##_blk.bit_offset   =3D 0;			=
\
-		acpi_sinfo.dst##_blk.access_width =3D 0;			=
\
+		acpi_sinfo.dst##_blk.access_width =3D fadt->len##_length;	=
\
 	} \
 } while (0)
=20
@@ -328,6 +329,41 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	struct acpi_table_facs *facs =3D NULL;
 	uint64_t facs_pa;
=20
+	if (fadt->header.revision >=3D 5 &&
+	    fadt->header.length >=3D ACPI_FADT_V5_SIZE) {
+		acpi_sinfo.sleep_control =3D fadt->sleep_control;
+		acpi_sinfo.sleep_status =3D fadt->sleep_status;
+
+		printk(KERN_INFO PREFIX
+		       "v5 SLEEP INFO: control[%d:%"PRIx64"],"
+		       " status[%d:%"PRIx64"]\n",
+		       acpi_sinfo.sleep_control.space_id,
+		       acpi_sinfo.sleep_control.address,
+		       acpi_sinfo.sleep_status.space_id,
+		       acpi_sinfo.sleep_status.address);
+
+		if ((fadt->sleep_control.address &&
+		     (fadt->sleep_control.bit_offset ||
+		      fadt->sleep_control.bit_width !=3D
+		      fadt->sleep_control.access_width * 8)) ||
+		    (fadt->sleep_status.address &&
+		     (fadt->sleep_status.bit_offset ||
+		      fadt->sleep_status.bit_width !=3D
+		      fadt->sleep_status.access_width * 8))) {
+			printk(KERN_WARNING PREFIX
+			       "Invalid sleep control/status register =
data:"
+			       " %#x:%#x:%#x %#x:%#x:%#x\n",
+			       fadt->sleep_control.bit_offset,
+			       fadt->sleep_control.bit_width,
+			       fadt->sleep_control.access_width,
+			       fadt->sleep_status.bit_offset,
+			       fadt->sleep_status.bit_width,
+			       fadt->sleep_status.access_width);
+			fadt->sleep_control.address =3D 0;
+			fadt->sleep_status.address =3D 0;
+		}
+	}
+
 	if (fadt->flags & ACPI_FADT_HW_REDUCED)
 		goto bad;
=20
@@ -337,7 +373,7 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	acpi_fadt_copy_address(pm1b_evt, pm1b_event, pm1_event);
=20
 	printk(KERN_INFO PREFIX
-	       "ACPI SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "
+	       "SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "
 	       "pm1x_evt[%"PRIx64",%"PRIx64"]\n",
 	       acpi_sinfo.pm1a_cnt_blk.address,
 	       acpi_sinfo.pm1b_cnt_blk.address,
@@ -384,11 +420,14 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	acpi_sinfo.vector_width =3D 32;
=20
 	printk(KERN_INFO PREFIX
-	       "                 wakeup_vec[%"PRIx64"], vec_size[%x]\n",
+	       "            wakeup_vec[%"PRIx64"], vec_size[%x]\n",
 	       acpi_sinfo.wakeup_vector, acpi_sinfo.vector_width);
 	return;
 bad:
-	memset(&acpi_sinfo, 0, sizeof(acpi_sinfo));
+	memset(&acpi_sinfo, 0,
+	       offsetof(struct acpi_sleep_info, sleep_control));
+	memset(&acpi_sinfo.sleep_status + 1, 0,
+	       (long)(&acpi_sinfo + 1) - (long)(&acpi_sinfo.sleep_status + =
1));
 }
 #endif
=20
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -239,23 +239,47 @@ static long enter_state_helper(void *dat
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )
+    {
+        if ( !acpi_sinfo.sleep_control.address ||
+             !acpi_sinfo.sleep_status.address )
+            return -EPERM;
+
+        if ( sleep->flags & ~XENPF_ACPI_SLEEP_EXTENDED )
+            return -EINVAL;
+
+        if ( sleep->val_a > ACPI_SLEEP_TYPE_MAX ||
+             (sleep->val_b !=3D ACPI_SLEEP_TYPE_INVALID &&
+              sleep->val_b > ACPI_SLEEP_TYPE_MAX) )
+            return -ERANGE;
+
+        acpi_sinfo.sleep_type_a =3D sleep->val_a;
+        acpi_sinfo.sleep_type_b =3D sleep->val_b;
+
+        acpi_sinfo.sleep_extended =3D 1;
+    }
+
+    else if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
=20
     /* Sanity check */
-    if ( acpi_sinfo.pm1b_cnt_val &&
-         ((sleep->pm1a_cnt_val ^ sleep->pm1b_cnt_val) &
-          ACPI_BITMASK_SLEEP_ENABLE) )
+    else if ( sleep->val_b &&
+              ((sleep->val_a ^ sleep->val_b) & ACPI_BITMASK_SLEEP_ENABLE) =
)
     {
         gdprintk(XENLOG_ERR, "Mismatched pm1a/pm1b setting.");
         return -EINVAL;
     }
=20
-    if ( sleep->flags )
+    else if ( sleep->flags )
         return -EINVAL;
=20
-    acpi_sinfo.pm1a_cnt_val =3D sleep->pm1a_cnt_val;
-    acpi_sinfo.pm1b_cnt_val =3D sleep->pm1b_cnt_val;
+    else
+    {
+        acpi_sinfo.pm1a_cnt_val =3D sleep->val_a;
+        acpi_sinfo.pm1b_cnt_val =3D sleep->val_b;
+        acpi_sinfo.sleep_extended =3D 0;
+    }
+
     acpi_sinfo.sleep_state =3D sleep->sleep_state;
=20
     return continue_hypercall_on_cpu(0, enter_state_helper, &acpi_sinfo);
@@ -266,6 +290,13 @@ static int acpi_get_wake_status(void)
     uint32_t val;
     acpi_status status;
=20
+    if ( acpi_sinfo.sleep_extended )
+    {
+        status =3D acpi_hw_register_read(ACPI_REGISTER_SLEEP_STATUS, =
&val);
+
+        return ACPI_FAILURE(status) ? 0 : val & ACPI_X_WAKE_STATUS;
+    }
+
     /* Wake status is the 15th bit of PM1 status register. (ACPI spec =
3.0) */
     status =3D acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &val);
     if ( ACPI_FAILURE(status) )
@@ -335,19 +366,33 @@ acpi_status acpi_enter_sleep_state(u8 sl
=20
     ACPI_FLUSH_CPU_CACHE();
=20
-    status =3D acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL,=20
-                                    acpi_sinfo.pm1a_cnt_val);
-    if ( ACPI_FAILURE(status) )
-        return_ACPI_STATUS(AE_ERROR);
-
-    if ( acpi_sinfo.pm1b_cnt_blk.address )
+    if ( acpi_sinfo.sleep_extended )
     {
-        status =3D acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL,=20
-                                        acpi_sinfo.pm1b_cnt_val);
-        if ( ACPI_FAILURE(status) )
-            return_ACPI_STATUS(AE_ERROR);
+        /*
+         * Set the SLP_TYP and SLP_EN bits.
+         *
+         * Note: We only use the first value returned by the \_Sx method
+         * (acpi_sinfo.sleep_type_a) - As per ACPI specification.
+         */
+        u8 sleep_type_value =3D
+            ((acpi_sinfo.sleep_type_a << ACPI_X_SLEEP_TYPE_POSITION) &
+             ACPI_X_SLEEP_TYPE_MASK) | ACPI_X_SLEEP_ENABLE;
+
+        status =3D acpi_hw_register_write(ACPI_REGISTER_SLEEP_CONTROL,
+                                        sleep_type_value);
+    }
+    else
+    {
+        status =3D acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL,
+                                        acpi_sinfo.pm1a_cnt_val);
+        if ( !ACPI_FAILURE(status) && acpi_sinfo.pm1b_cnt_blk.address )
+            status =3D acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL,
+                                            acpi_sinfo.pm1b_cnt_val);
     }
=20
+    if ( ACPI_FAILURE(status) )
+        return_ACPI_STATUS(AE_ERROR);
+
     /* Wait until we enter sleep state, and spin until we wake */
     while ( !acpi_get_wake_status() )
         continue;
--- a/xen/drivers/acpi/hwregs.c
+++ b/xen/drivers/acpi/hwregs.c
@@ -365,6 +365,14 @@ acpi_hw_register_read(u32 register_id, u
 		    acpi_os_read_port(acpi_gbl_FADT.smi_command, &value1, =
8);
 		break;
=20
+	case ACPI_REGISTER_SLEEP_STATUS:
+
+		status =3D
+		    acpi_hw_low_level_read(acpi_gbl_FADT.sleep_status.bit_w=
idth,
+					   &value1,
+					   &acpi_gbl_FADT.sleep_status);
+		break;
+
 	default:
 		ACPI_DEBUG_PRINT((AE_INFO, "Unknown Register ID: %X", =
register_id));
 		status =3D AE_BAD_PARAMETER;
@@ -525,6 +533,14 @@ acpi_status acpi_hw_register_write(u32 r
 		    acpi_os_write_port(acpi_gbl_FADT.smi_command, value, =
8);
 		break;
=20
+	case ACPI_REGISTER_SLEEP_CONTROL:
+
+		status =3D
+		    acpi_hw_low_level_write(acpi_gbl_FADT.sleep_control.bit=
_width,
+					    value,
+					    &acpi_gbl_FADT.sleep_control);
+		break;
+
 	default:
 		status =3D AE_BAD_PARAMETER;
 		break;
--- a/xen/include/acpi/aclocal.h
+++ b/xen/include/acpi/aclocal.h
@@ -128,6 +128,8 @@ struct acpi_bit_register_info {
 #define ACPI_REGISTER_PM_TIMER                  0x07
 #define ACPI_REGISTER_PROCESSOR_BLOCK           0x08
 #define ACPI_REGISTER_SMI_COMMAND_BLOCK         0x09
+#define ACPI_REGISTER_SLEEP_CONTROL             0x0a
+#define ACPI_REGISTER_SLEEP_STATUS              0x0b
=20
 /* Masks used to access the bit_registers */
=20
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -309,6 +309,13 @@ enum acpi_prefered_pm_profiles {
 	PM_TABLET =3D 8
 };
=20
+/* Values for sleep_status and sleep_control registers (V5 FADT) */
+
+#define ACPI_X_WAKE_STATUS          0x80
+#define ACPI_X_SLEEP_TYPE_MASK      0x1C
+#define ACPI_X_SLEEP_TYPE_POSITION  0x02
+#define ACPI_X_SLEEP_ENABLE         0x20
+
 /* Reset to default packing */
=20
 #pragma pack()
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -126,11 +126,20 @@ struct acpi_sleep_info {
     struct acpi_generic_address pm1b_cnt_blk;
     struct acpi_generic_address pm1a_evt_blk;
     struct acpi_generic_address pm1b_evt_blk;
-    uint16_t pm1a_cnt_val;
-    uint16_t pm1b_cnt_val;
+    struct acpi_generic_address sleep_control;
+    struct acpi_generic_address sleep_status;
+    union {
+        uint16_t pm1a_cnt_val;
+        uint8_t sleep_type_a;
+    };
+    union {
+        uint16_t pm1b_cnt_val;
+        uint8_t sleep_type_b;
+    };
     uint32_t sleep_state;
     uint64_t wakeup_vector;
     uint32_t vector_width;
+    bool_t sleep_extended;
 };
=20
 #endif /* CONFIG_ACPI_SLEEP */
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -290,10 +290,16 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_firmware_i
 #define XENPF_enter_acpi_sleep    51
 struct xenpf_enter_acpi_sleep {
     /* IN variables */
+#if __XEN_INTERFACE_VERSION__ < 0x00040300
     uint16_t pm1a_cnt_val;      /* PM1a control value. */
     uint16_t pm1b_cnt_val;      /* PM1b control value. */
+#else
+    uint16_t val_a;             /* PM1a control / sleep type A. */
+    uint16_t val_b;             /* PM1b control / sleep type B. */
+#endif
     uint32_t sleep_state;       /* Which state to enter (Sn). */
-    uint32_t flags;             /* Must be zero. */
+#define XENPF_ACPI_SLEEP_EXTENDED 0x00000001
+    uint32_t flags;             /* XENPF_ACPI_SLEEP_*. */
 };
 typedef struct xenpf_enter_acpi_sleep xenpf_enter_acpi_sleep_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_enter_acpi_sleep_t);



--=__Part6959136C.0__=
Content-Type: text/plain; name="ACPI-v5-sleep.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-v5-sleep.patch"

ACPI: support v5 (reduced HW) sleep interface=0A=0ANote that this also =
fixes a broken input check in acpi_enter_sleep()=0A(previously validating =
the sleep->pm1[ab]_cnt_val relationship based=0Aon acpi_sinfo.pm1b_cnt_val,=
 which however gets set only subsequently).=0A=0AAlso adjust a few minor =
issues with the pre-v5 handling in=0Aacpi_fadt_parse_sleep_info().=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AA question is whether, =
rather than passing the raw values read from=0A_Sx to XENPF_enter_acpi_slee=
p, we should again have Dom0 pass the=0Avalues ready to be written into =
the registers - that would make things=0Aconsistent with the legacy case, =
but add further dependency of the=0Ahypervisor on Dom0 behavior where it's =
not really needed. I think that=0Ait was a mistake for the original =
variant to have Dom0 pass massaged=0Avalues to the hypervisor.=0A=0A--- =
a/xen/arch/x86/acpi/boot.c=0A+++ b/xen/arch/x86/acpi/boot.c=0A@@ -310,14 =
+310,15 @@ static int __init acpi_invalidate_bgrt(s=0A =0A #ifdef =
CONFIG_ACPI_SLEEP=0A #define acpi_fadt_copy_address(dst, src, len) do {		=
	\=0A-	if (fadt->header.revision >=3D FADT2_REVISION_ID)		=
	\=0A+	if (fadt->header.revision >=3D FADT2_REVISION_ID &&		=
\=0A+	    fadt->header.length >=3D ACPI_FADT_V2_SIZE)			=
\=0A 		acpi_sinfo.dst##_blk =3D fadt->x##src##_block;		=
\=0A 	if (!acpi_sinfo.dst##_blk.address) {				=
\=0A 		acpi_sinfo.dst##_blk.address      =3D fadt->src##_block;	=
\=0A 		acpi_sinfo.dst##_blk.space_id     =3D ACPI_ADR_SPACE_SYSTEM=
_IO; \=0A 		acpi_sinfo.dst##_blk.bit_width    =3D fadt->len##_l=
ength << 3; \=0A 		acpi_sinfo.dst##_blk.bit_offset   =3D 0;	=
		\=0A-		acpi_sinfo.dst##_blk.access_width =3D 0;	=
		\=0A+		acpi_sinfo.dst##_blk.access_width =3D =
fadt->len##_length;	\=0A 	} \=0A } while (0)=0A =0A@@ -328,6 +329,41 =
@@ acpi_fadt_parse_sleep_info(struct acpi_t=0A 	struct acpi_table_facs =
*facs =3D NULL;=0A 	uint64_t facs_pa;=0A =0A+	if (fadt->header.re=
vision >=3D 5 &&=0A+	    fadt->header.length >=3D ACPI_FADT_V5_SIZE) =
{=0A+		acpi_sinfo.sleep_control =3D fadt->sleep_control;=0A+		=
acpi_sinfo.sleep_status =3D fadt->sleep_status;=0A+=0A+		printk(KERN=
_INFO PREFIX=0A+		       "v5 SLEEP INFO: control[%d:%"PRIx64"=
],"=0A+		       " status[%d:%"PRIx64"]\n",=0A+		       =
acpi_sinfo.sleep_control.space_id,=0A+		       acpi_sinfo.sleep_con=
trol.address,=0A+		       acpi_sinfo.sleep_status.space_id,=0A=
+		       acpi_sinfo.sleep_status.address);=0A+=0A+		=
if ((fadt->sleep_control.address &&=0A+		     (fadt->sleep_control.b=
it_offset ||=0A+		      fadt->sleep_control.bit_width =
!=3D=0A+		      fadt->sleep_control.access_width * 8)) =
||=0A+		    (fadt->sleep_status.address &&=0A+		     =
(fadt->sleep_status.bit_offset ||=0A+		      fadt->sleep_status.bi=
t_width !=3D=0A+		      fadt->sleep_status.access_width * =
8))) {=0A+			printk(KERN_WARNING PREFIX=0A+			=
       "Invalid sleep control/status register data:"=0A+			=
       " %#x:%#x:%#x %#x:%#x:%#x\n",=0A+			       =
fadt->sleep_control.bit_offset,=0A+			       fadt->sleep_=
control.bit_width,=0A+			       fadt->sleep_control.access_w=
idth,=0A+			       fadt->sleep_status.bit_offset,=0A+	=
		       fadt->sleep_status.bit_width,=0A+			=
       fadt->sleep_status.access_width);=0A+			fadt->sleep=
_control.address =3D 0;=0A+			fadt->sleep_status.address =
=3D 0;=0A+		}=0A+	}=0A+=0A 	if (fadt->flags & =
ACPI_FADT_HW_REDUCED)=0A 		goto bad;=0A =0A@@ -337,7 +373,7 =
@@ acpi_fadt_parse_sleep_info(struct acpi_t=0A 	acpi_fadt_copy_address(pm1b=
_evt, pm1b_event, pm1_event);=0A =0A 	printk(KERN_INFO PREFIX=0A-	   =
    "ACPI SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "=0A+	       =
"SLEEP INFO: pm1x_cnt[%"PRIx64",%"PRIx64"], "=0A 	       "pm1x_evt[%"=
PRIx64",%"PRIx64"]\n",=0A 	       acpi_sinfo.pm1a_cnt_blk.address,=0A =
	       acpi_sinfo.pm1b_cnt_blk.address,=0A@@ -384,11 +420,14 @@ =
acpi_fadt_parse_sleep_info(struct acpi_t=0A 	acpi_sinfo.vector_width =
=3D 32;=0A =0A 	printk(KERN_INFO PREFIX=0A-	       "                 =
wakeup_vec[%"PRIx64"], vec_size[%x]\n",=0A+	       "            =
wakeup_vec[%"PRIx64"], vec_size[%x]\n",=0A 	       acpi_sinfo.wakeup_ve=
ctor, acpi_sinfo.vector_width);=0A 	return;=0A bad:=0A-	memset(&acp=
i_sinfo, 0, sizeof(acpi_sinfo));=0A+	memset(&acpi_sinfo, 0,=0A+	   =
    offsetof(struct acpi_sleep_info, sleep_control));=0A+	memset(&acp=
i_sinfo.sleep_status + 1, 0,=0A+	       (long)(&acpi_sinfo + 1) - =
(long)(&acpi_sinfo.sleep_status + 1));=0A }=0A #endif=0A =0A--- a/xen/arch/=
x86/acpi/power.c=0A+++ b/xen/arch/x86/acpi/power.c=0A@@ -239,23 +239,47 @@ =
static long enter_state_helper(void *dat=0A  */=0A int acpi_enter_sleep(str=
uct xenpf_enter_acpi_sleep *sleep)=0A {=0A-    if ( !acpi_sinfo.pm1a_cnt_bl=
k.address )=0A+    if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )=0A+    =
{=0A+        if ( !acpi_sinfo.sleep_control.address ||=0A+             =
!acpi_sinfo.sleep_status.address )=0A+            return -EPERM;=0A+=0A+   =
     if ( sleep->flags & ~XENPF_ACPI_SLEEP_EXTENDED )=0A+            =
return -EINVAL;=0A+=0A+        if ( sleep->val_a > ACPI_SLEEP_TYPE_MAX =
||=0A+             (sleep->val_b !=3D ACPI_SLEEP_TYPE_INVALID &&=0A+       =
       sleep->val_b > ACPI_SLEEP_TYPE_MAX) )=0A+            return =
-ERANGE;=0A+=0A+        acpi_sinfo.sleep_type_a =3D sleep->val_a;=0A+      =
  acpi_sinfo.sleep_type_b =3D sleep->val_b;=0A+=0A+        acpi_sinfo.sleep=
_extended =3D 1;=0A+    }=0A+=0A+    else if ( !acpi_sinfo.pm1a_cnt_blk.add=
ress )=0A         return -EPERM;=0A =0A     /* Sanity check */=0A-    if ( =
acpi_sinfo.pm1b_cnt_val &&=0A-         ((sleep->pm1a_cnt_val ^ sleep->pm1b_=
cnt_val) &=0A-          ACPI_BITMASK_SLEEP_ENABLE) )=0A+    else if ( =
sleep->val_b &&=0A+              ((sleep->val_a ^ sleep->val_b) & =
ACPI_BITMASK_SLEEP_ENABLE) )=0A     {=0A         gdprintk(XENLOG_ERR, =
"Mismatched pm1a/pm1b setting.");=0A         return -EINVAL;=0A     }=0A =
=0A-    if ( sleep->flags )=0A+    else if ( sleep->flags )=0A         =
return -EINVAL;=0A =0A-    acpi_sinfo.pm1a_cnt_val =3D sleep->pm1a_cnt_val;=
=0A-    acpi_sinfo.pm1b_cnt_val =3D sleep->pm1b_cnt_val;=0A+    else=0A+   =
 {=0A+        acpi_sinfo.pm1a_cnt_val =3D sleep->val_a;=0A+        =
acpi_sinfo.pm1b_cnt_val =3D sleep->val_b;=0A+        acpi_sinfo.sleep_exten=
ded =3D 0;=0A+    }=0A+=0A     acpi_sinfo.sleep_state =3D sleep->sleep_stat=
e;=0A =0A     return continue_hypercall_on_cpu(0, enter_state_helper, =
&acpi_sinfo);=0A@@ -266,6 +290,13 @@ static int acpi_get_wake_status(void)=
=0A     uint32_t val;=0A     acpi_status status;=0A =0A+    if ( acpi_sinfo=
.sleep_extended )=0A+    {=0A+        status =3D acpi_hw_register_read(ACPI=
_REGISTER_SLEEP_STATUS, &val);=0A+=0A+        return ACPI_FAILURE(status) =
? 0 : val & ACPI_X_WAKE_STATUS;=0A+    }=0A+=0A     /* Wake status is the =
15th bit of PM1 status register. (ACPI spec 3.0) */=0A     status =3D =
acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &val);=0A     if ( =
ACPI_FAILURE(status) )=0A@@ -335,19 +366,33 @@ acpi_status acpi_enter_sleep=
_state(u8 sl=0A =0A     ACPI_FLUSH_CPU_CACHE();=0A =0A-    status =3D =
acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL, =0A-                    =
                acpi_sinfo.pm1a_cnt_val);=0A-    if ( ACPI_FAILURE(status) =
)=0A-        return_ACPI_STATUS(AE_ERROR);=0A-=0A-    if ( acpi_sinfo.pm1b_=
cnt_blk.address )=0A+    if ( acpi_sinfo.sleep_extended )=0A     {=0A-     =
   status =3D acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL, =0A-      =
                                  acpi_sinfo.pm1b_cnt_val);=0A-        if =
( ACPI_FAILURE(status) )=0A-            return_ACPI_STATUS(AE_ERROR);=0A+  =
      /*=0A+         * Set the SLP_TYP and SLP_EN bits.=0A+         *=0A+  =
       * Note: We only use the first value returned by the \_Sx method=0A+ =
        * (acpi_sinfo.sleep_type_a) - As per ACPI specification.=0A+       =
  */=0A+        u8 sleep_type_value =3D=0A+            ((acpi_sinfo.sleep_t=
ype_a << ACPI_X_SLEEP_TYPE_POSITION) &=0A+             ACPI_X_SLEEP_TYPE_MA=
SK) | ACPI_X_SLEEP_ENABLE;=0A+=0A+        status =3D acpi_hw_register_write=
(ACPI_REGISTER_SLEEP_CONTROL,=0A+                                        =
sleep_type_value);=0A+    }=0A+    else=0A+    {=0A+        status =3D =
acpi_hw_register_write(ACPI_REGISTER_PM1A_CONTROL,=0A+                     =
                   acpi_sinfo.pm1a_cnt_val);=0A+        if ( !ACPI_FAILURE(=
status) && acpi_sinfo.pm1b_cnt_blk.address )=0A+            status =3D =
acpi_hw_register_write(ACPI_REGISTER_PM1B_CONTROL,=0A+                     =
                       acpi_sinfo.pm1b_cnt_val);=0A     }=0A =0A+    if ( =
ACPI_FAILURE(status) )=0A+        return_ACPI_STATUS(AE_ERROR);=0A+=0A     =
/* Wait until we enter sleep state, and spin until we wake */=0A     while =
( !acpi_get_wake_status() )=0A         continue;=0A--- a/xen/drivers/acpi/h=
wregs.c=0A+++ b/xen/drivers/acpi/hwregs.c=0A@@ -365,6 +365,14 @@ acpi_hw_re=
gister_read(u32 register_id, u=0A 		    acpi_os_read_port(acpi_=
gbl_FADT.smi_command, &value1, 8);=0A 		break;=0A =0A+	case =
ACPI_REGISTER_SLEEP_STATUS:=0A+=0A+		status =3D=0A+		   =
 acpi_hw_low_level_read(acpi_gbl_FADT.sleep_status.bit_width,=0A+		=
			   &value1,=0A+					   =
&acpi_gbl_FADT.sleep_status);=0A+		break;=0A+=0A 	default:=0A=
 		ACPI_DEBUG_PRINT((AE_INFO, "Unknown Register ID: %X", =
register_id));=0A 		status =3D AE_BAD_PARAMETER;=0A@@ -525,6 =
+533,14 @@ acpi_status acpi_hw_register_write(u32 r=0A 		    =
acpi_os_write_port(acpi_gbl_FADT.smi_command, value, 8);=0A 		=
break;=0A =0A+	case ACPI_REGISTER_SLEEP_CONTROL:=0A+=0A+		=
status =3D=0A+		    acpi_hw_low_level_write(acpi_gbl_FADT.sleep_con=
trol.bit_width,=0A+					    value,=0A+		=
			    &acpi_gbl_FADT.sleep_control);=0A+		=
break;=0A+=0A 	default:=0A 		status =3D AE_BAD_PARAMETER;=0A 	=
	break;=0A--- a/xen/include/acpi/aclocal.h=0A+++ b/xen/include/acpi/=
aclocal.h=0A@@ -128,6 +128,8 @@ struct acpi_bit_register_info {=0A #define =
ACPI_REGISTER_PM_TIMER                  0x07=0A #define ACPI_REGISTER_PROCE=
SSOR_BLOCK           0x08=0A #define ACPI_REGISTER_SMI_COMMAND_BLOCK       =
  0x09=0A+#define ACPI_REGISTER_SLEEP_CONTROL             0x0a=0A+#define =
ACPI_REGISTER_SLEEP_STATUS              0x0b=0A =0A /* Masks used to =
access the bit_registers */=0A =0A--- a/xen/include/acpi/actbl.h=0A+++ =
b/xen/include/acpi/actbl.h=0A@@ -309,6 +309,13 @@ enum acpi_prefered_pm_pro=
files {=0A 	PM_TABLET =3D 8=0A };=0A =0A+/* Values for sleep_status =
and sleep_control registers (V5 FADT) */=0A+=0A+#define ACPI_X_WAKE_STATUS =
         0x80=0A+#define ACPI_X_SLEEP_TYPE_MASK      0x1C=0A+#define =
ACPI_X_SLEEP_TYPE_POSITION  0x02=0A+#define ACPI_X_SLEEP_ENABLE         =
0x20=0A+=0A /* Reset to default packing */=0A =0A #pragma pack()=0A--- =
a/xen/include/asm-x86/acpi.h=0A+++ b/xen/include/asm-x86/acpi.h=0A@@ =
-126,11 +126,20 @@ struct acpi_sleep_info {=0A     struct acpi_generic_addr=
ess pm1b_cnt_blk;=0A     struct acpi_generic_address pm1a_evt_blk;=0A     =
struct acpi_generic_address pm1b_evt_blk;=0A-    uint16_t pm1a_cnt_val;=0A-=
    uint16_t pm1b_cnt_val;=0A+    struct acpi_generic_address sleep_control=
;=0A+    struct acpi_generic_address sleep_status;=0A+    union {=0A+      =
  uint16_t pm1a_cnt_val;=0A+        uint8_t sleep_type_a;=0A+    };=0A+    =
union {=0A+        uint16_t pm1b_cnt_val;=0A+        uint8_t sleep_type_b;=
=0A+    };=0A     uint32_t sleep_state;=0A     uint64_t wakeup_vector;=0A  =
   uint32_t vector_width;=0A+    bool_t sleep_extended;=0A };=0A =0A =
#endif /* CONFIG_ACPI_SLEEP */=0A--- a/xen/include/public/platform.h=0A+++ =
b/xen/include/public/platform.h=0A@@ -290,10 +290,16 @@ DEFINE_XEN_GUEST_HA=
NDLE(xenpf_firmware_i=0A #define XENPF_enter_acpi_sleep    51=0A struct =
xenpf_enter_acpi_sleep {=0A     /* IN variables */=0A+#if __XEN_INTERFACE_V=
ERSION__ < 0x00040300=0A     uint16_t pm1a_cnt_val;      /* PM1a control =
value. */=0A     uint16_t pm1b_cnt_val;      /* PM1b control value. =
*/=0A+#else=0A+    uint16_t val_a;             /* PM1a control / sleep =
type A. */=0A+    uint16_t val_b;             /* PM1b control / sleep type =
B. */=0A+#endif=0A     uint32_t sleep_state;       /* Which state to enter =
(Sn). */=0A-    uint32_t flags;             /* Must be zero. */=0A+#define =
XENPF_ACPI_SLEEP_EXTENDED 0x00000001=0A+    uint32_t flags;             /* =
XENPF_ACPI_SLEEP_*. */=0A };=0A typedef struct xenpf_enter_acpi_sleep =
xenpf_enter_acpi_sleep_t;=0A DEFINE_XEN_GUEST_HANDLE(xenpf_enter_acpi_sleep=
_t);=0A
--=__Part6959136C.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

--=__Part6959136C.0__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:11:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 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 1U8Vw4-0001TZ-F6; Thu, 21 Feb 2013 13:11:40 +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 1U8Vw3-0001T6-LW
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:11:39 +0000
Received: from [85.158.143.99:3632] by server-2.bemta-4.messagelabs.com id
	10/94-12656-A0D16215; Thu, 21 Feb 2013 13:11:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361452298!25201588!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19691 invoked from network); 21 Feb 2013 13:11:38 -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; 21 Feb 2013 13:11:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:11:37 +0000
Message-Id: <51262B5202000078000BFF10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:12:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
In-Reply-To: <20130221130013.GA7240@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:00, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 
> 23459:9f12bdd6b7f0
> and I kept on getting:
> xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed 
> (rc=-3): Internal error
> 
> Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> bisection but any thoughts off which one I ought to try out first?

Apart from a couple of QEMU_TAG updates and the oxenstored
security fixes I don't see any tools changes since 4.1.4 at all, so
a tools side regression seems rather unlikely. And the hypervisor
side changes also don't look like they could cause this sort of a
failure.

You didn't happen to have some stale (from another version's
build) shared libraries left installed?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:11:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 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 1U8Vw4-0001TZ-F6; Thu, 21 Feb 2013 13:11:40 +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 1U8Vw3-0001T6-LW
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:11:39 +0000
Received: from [85.158.143.99:3632] by server-2.bemta-4.messagelabs.com id
	10/94-12656-A0D16215; Thu, 21 Feb 2013 13:11:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361452298!25201588!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19691 invoked from network); 21 Feb 2013 13:11:38 -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; 21 Feb 2013 13:11:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:11:37 +0000
Message-Id: <51262B5202000078000BFF10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:12:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
In-Reply-To: <20130221130013.GA7240@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:00, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 
> 23459:9f12bdd6b7f0
> and I kept on getting:
> xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed 
> (rc=-3): Internal error
> 
> Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> bisection but any thoughts off which one I ought to try out first?

Apart from a couple of QEMU_TAG updates and the oxenstored
security fixes I don't see any tools changes since 4.1.4 at all, so
a tools side regression seems rather unlikely. And the hypervisor
side changes also don't look like they could cause this sort of a
failure.

You didn't happen to have some stale (from another version's
build) shared libraries left installed?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:12:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vwq-0001az-Ue; Thu, 21 Feb 2013 13:12:28 +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 1U8Vwp-0001aa-9s
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:12:27 +0000
Received: from [85.158.137.99:33406] by server-15.bemta-3.messagelabs.com id
	51/7D-25405-A3D16215; Thu, 21 Feb 2013 13:12:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361452340!17420658!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 21 Feb 2013 13:12:20 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:12:20 -0000
Received: by mail-wg0-f52.google.com with SMTP id 12so7180964wgh.31
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 05:12:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VP3rzuS6Lz64RHK2dcq0ex/HzG4l5VOdZTnz3Vuy6gE=;
	b=G10h1Qa+gz0CyQohTDbSlLDEkwZmm7WiyM6zmqfDIW+kf8DsKUcZtdhDMCo1fi2z2K
	KgHuaJU90tUZrvTbw6iOpopzoEIfprhCor4dVYPnaq/KMSJ8DeIGedwDcIsN0ciNVrrg
	EkdMsh8uR5/5Alq91B3s0LQYfN0vK6xQyBymYyJHZl8D9yNzj6mPs1w2EhWlD7tZHw/L
	12tOhXic+s8G85EN5WV+GmKA+i+nNAsKHlGeYGIUpeUWjvcu+IATek9zYwOMeolMPNRv
	4JoBX28eTOBdw7Fao1fEjz8HsBs/MkxKJA86ae6MyJU+q8rDthjP4OYNxdjt+KPVQP+B
	Qq1Q==
X-Received: by 10.194.122.131 with SMTP id ls3mr41249778wjb.55.1361452340417; 
	Thu, 21 Feb 2013 05:12:20 -0800 (PST)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id ex15sm36887188wid.5.2013.02.21.05.12.19
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 05:12:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 13:12:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CD4BCDB1.4C5E9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: rework hypercall argument translation
	area setup
Thread-Index: Ac4QNRJ/CrBhmzn9lUuzfWKejcz09w==
In-Reply-To: <512629A702000078000BFEBF@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/02/2013 13:05, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 21.02.13 at 13:57, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 21/02/2013 12:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> Are we concerned about the performance of guest GDT/LDT page
>>> (un)mappings?
>> 
>> LDT must often change on guest process context switch? So I would think yes
>> we do.
> 
> Linux doesn't normally use an LDT (i.e. only exotic processes
> would have one of non-zero size).

That being the case, we probably don't care so much.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:12:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vwq-0001az-Ue; Thu, 21 Feb 2013 13:12:28 +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 1U8Vwp-0001aa-9s
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:12:27 +0000
Received: from [85.158.137.99:33406] by server-15.bemta-3.messagelabs.com id
	51/7D-25405-A3D16215; Thu, 21 Feb 2013 13:12:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361452340!17420658!1
X-Originating-IP: [74.125.82.52]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 21 Feb 2013 13:12:20 -0000
Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com)
	(74.125.82.52)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:12:20 -0000
Received: by mail-wg0-f52.google.com with SMTP id 12so7180964wgh.31
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 05:12:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VP3rzuS6Lz64RHK2dcq0ex/HzG4l5VOdZTnz3Vuy6gE=;
	b=G10h1Qa+gz0CyQohTDbSlLDEkwZmm7WiyM6zmqfDIW+kf8DsKUcZtdhDMCo1fi2z2K
	KgHuaJU90tUZrvTbw6iOpopzoEIfprhCor4dVYPnaq/KMSJ8DeIGedwDcIsN0ciNVrrg
	EkdMsh8uR5/5Alq91B3s0LQYfN0vK6xQyBymYyJHZl8D9yNzj6mPs1w2EhWlD7tZHw/L
	12tOhXic+s8G85EN5WV+GmKA+i+nNAsKHlGeYGIUpeUWjvcu+IATek9zYwOMeolMPNRv
	4JoBX28eTOBdw7Fao1fEjz8HsBs/MkxKJA86ae6MyJU+q8rDthjP4OYNxdjt+KPVQP+B
	Qq1Q==
X-Received: by 10.194.122.131 with SMTP id ls3mr41249778wjb.55.1361452340417; 
	Thu, 21 Feb 2013 05:12:20 -0800 (PST)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id ex15sm36887188wid.5.2013.02.21.05.12.19
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 05:12:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 13:12:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CD4BCDB1.4C5E9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: rework hypercall argument translation
	area setup
Thread-Index: Ac4QNRJ/CrBhmzn9lUuzfWKejcz09w==
In-Reply-To: <512629A702000078000BFEBF@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: rework hypercall argument translation
 area 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/02/2013 13:05, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 21.02.13 at 13:57, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 21/02/2013 12:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> Are we concerned about the performance of guest GDT/LDT page
>>> (un)mappings?
>> 
>> LDT must often change on guest process context switch? So I would think yes
>> we do.
> 
> Linux doesn't normally use an LDT (i.e. only exotic processes
> would have one of non-zero size).

That being the case, we probably don't care so much.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:14:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vyj-0001pw-LV; Thu, 21 Feb 2013 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 <keir.xen@gmail.com>) id 1U8Vyi-0001pm-3g
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:14:24 +0000
Received: from [193.109.254.147:51397] by server-15.bemta-14.messagelabs.com
	id 7B/CB-24599-FAD16215; Thu, 21 Feb 2013 13:14:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361452353!8831502!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10819 invoked from network); 21 Feb 2013 13:12:34 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:12:34 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so516272wgh.3
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 05:12:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/FY/3/SqQy/mb6RBFbGUPaxudDt2GGPHUmfgdG/O/lY=;
	b=wfJcDzQpx0cBPkfklctN3VVYYYtocxWsRSq7ZdqJibpnkPlH2s7HZZaMpqFT0XodZt
	lbcZhTTRkTmyPhfzjEpUoxh9tR/48VXj5wCFCs3vVpOAFHDTXjqXjwP9wqRB1Kb2R8SY
	bWVRMFRFybAqx6qSNigjGXM1VJbwdHe9TIq9Ovjt92QlhsNyEDJhul9A1vyMUv8Ysh2E
	qXtsai1nBoz06XVNWSTEmdThdoPeQzd9EZVA7O9cJtLm/3jDNRMiQ/Fg+OsV6cttqTO3
	C1T7B0/7l2AKXUPRW1Jd4K4LmWdYJ8G/SmC/sourLcPEi7TplFKcFuI5fRJLnb0mQq/p
	ZxBw==
X-Received: by 10.194.86.38 with SMTP id m6mr41441275wjz.13.1361452353482;
	Thu, 21 Feb 2013 05:12:33 -0800 (PST)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id fx5sm40070689wib.11.2013.02.21.05.12.31
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 05:12:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 13:12:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD4BCDBA.4C5E9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/6] ACPI v5 adjustments
Thread-Index: Ac4QNRfdF7kYamU0VUy6mQpvITe8eA==
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/6] ACPI v5 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

On 21/02/2013 12:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> The first three of these are cloned from Linux counterparts, and the
> last one adjusts behavior we would have needed for v4 already.
> 
> 1: ACPI 5.0: Basic support for FADT version 5
> 2: ACPI 5.0: Implement hardware-reduced option
> 3: ACPICA: Update for larger ACPI 5 FADT size
> 4: ACPI: support v5 (reduced HW) sleep interface
> 5: x86: honor ACPI indicating absence of CMOS RTC
> 6: honor ACPI v4 FADT flags
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks alright to me.

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 21 13:14:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8Vyj-0001pw-LV; Thu, 21 Feb 2013 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 <keir.xen@gmail.com>) id 1U8Vyi-0001pm-3g
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:14:24 +0000
Received: from [193.109.254.147:51397] by server-15.bemta-14.messagelabs.com
	id 7B/CB-24599-FAD16215; Thu, 21 Feb 2013 13:14:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361452353!8831502!1
X-Originating-IP: [74.125.82.42]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10819 invoked from network); 21 Feb 2013 13:12:34 -0000
Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com)
	(74.125.82.42)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:12:34 -0000
Received: by mail-wg0-f42.google.com with SMTP id 12so516272wgh.3
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 05:12:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/FY/3/SqQy/mb6RBFbGUPaxudDt2GGPHUmfgdG/O/lY=;
	b=wfJcDzQpx0cBPkfklctN3VVYYYtocxWsRSq7ZdqJibpnkPlH2s7HZZaMpqFT0XodZt
	lbcZhTTRkTmyPhfzjEpUoxh9tR/48VXj5wCFCs3vVpOAFHDTXjqXjwP9wqRB1Kb2R8SY
	bWVRMFRFybAqx6qSNigjGXM1VJbwdHe9TIq9Ovjt92QlhsNyEDJhul9A1vyMUv8Ysh2E
	qXtsai1nBoz06XVNWSTEmdThdoPeQzd9EZVA7O9cJtLm/3jDNRMiQ/Fg+OsV6cttqTO3
	C1T7B0/7l2AKXUPRW1Jd4K4LmWdYJ8G/SmC/sourLcPEi7TplFKcFuI5fRJLnb0mQq/p
	ZxBw==
X-Received: by 10.194.86.38 with SMTP id m6mr41441275wjz.13.1361452353482;
	Thu, 21 Feb 2013 05:12:33 -0800 (PST)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [46.33.159.2])
	by mx.google.com with ESMTPS id fx5sm40070689wib.11.2013.02.21.05.12.31
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 05:12:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 13:12:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD4BCDBA.4C5E9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/6] ACPI v5 adjustments
Thread-Index: Ac4QNRfdF7kYamU0VUy6mQpvITe8eA==
In-Reply-To: <512625DA02000078000BFE5D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/6] ACPI v5 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

On 21/02/2013 12:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> The first three of these are cloned from Linux counterparts, and the
> last one adjusts behavior we would have needed for v4 already.
> 
> 1: ACPI 5.0: Basic support for FADT version 5
> 2: ACPI 5.0: Implement hardware-reduced option
> 3: ACPICA: Update for larger ACPI 5 FADT size
> 4: ACPI: support v5 (reduced HW) sleep interface
> 5: x86: honor ACPI indicating absence of CMOS RTC
> 6: honor ACPI v4 FADT flags
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks alright to me.

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 21 13:19:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:19: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 1U8W3V-00028i-E9; Thu, 21 Feb 2013 13:19:21 +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 1U8W3T-00028b-Fe
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:19:19 +0000
Received: from [193.109.254.147:58817] by server-11.bemta-14.messagelabs.com
	id E0/42-30685-6DE16215; Thu, 21 Feb 2013 13:19:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361452729!8501773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22734 invoked from network); 21 Feb 2013 13:18:50 -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; 21 Feb 2013 13:18:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:18:49 +0000
Message-Id: <51262D0302000078000BFF2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:19:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130221130510.GB7240@phenom.dumpdata.com>
In-Reply-To: <20130221130510.GB7240@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Linux v3.9-rc0, three different bootup 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 21.02.13 at 14:05, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The first one is when booting PV guests:
> 
> [    0.831091] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
> [    0.831107] IP: [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
> [    0.831122] PGD 0 
> [    0.831130] Oops: 0000 [#1] SMP 
> [    0.831142] Modules linked in:
> [    0.831150] CPU 0 
> [    0.831156] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-03229-ge1f5dd0 #1  
> [    0.831166] RIP: e030:[<ffffffff8138978a>]  [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
> [    0.831178] RSP: e02b:ffff88003d369e88  EFLAGS: 00010246
> [    0.831185] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000000
> [    0.831193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81329ae0
> [    0.831200] RBP: ffff88003d369ea8 R08: 0000000000000000 R09: 0000000000000000
> [    0.831208] R10: 0000000000007ff0 R11: 0000000000000002 R12: 0000000000000000
> [    0.831215] R13: ffffffff81329ae0 R14: 0000000000000000 R15: 0000000000000000
> [    0.831227] FS:  0000000000000000(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> [    0.831236] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    0.831242] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000000660
> [    0.831251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    0.831258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [    0.831266] Process swapper/0 (pid: 1, threadinfo ffff88003d368000, task ffff88003d362800)
> [    0.831274] Stack:
> [    0.831280]  0000000000000030 0000000000000000 ffffffff81ae960e ffffffff81b402e8
> [    0.831298]  ffff88003d369eb8 ffffffff81329b3b ffff88003d369ec8 ffffffff81ae9620
> [    0.831316]  ffff88003d369ef8 ffffffff8100203d 0000000000000030 0000000000000007
> [    0.831336] Call Trace:
> [    0.831347]  [<ffffffff81ae960e>] ? pcie_portdrv_init+0x7a/0x7a
> [    0.831359]  [<ffffffff81329b3b>] aer_acpi_firmware_first+0x1b/0x30
> [    0.831370]  [<ffffffff81ae9620>] aer_service_init+0x12/0x2b

The bug here quite obviously is that with no ACPI you shouldn't
even get to that point. Yet apei_hest_parse() blindly uses
hest_tab - that ought to regress on real hardware too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:19:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:19: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 1U8W3V-00028i-E9; Thu, 21 Feb 2013 13:19:21 +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 1U8W3T-00028b-Fe
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:19:19 +0000
Received: from [193.109.254.147:58817] by server-11.bemta-14.messagelabs.com
	id E0/42-30685-6DE16215; Thu, 21 Feb 2013 13:19:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361452729!8501773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22734 invoked from network); 21 Feb 2013 13:18:50 -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; 21 Feb 2013 13:18:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:18:49 +0000
Message-Id: <51262D0302000078000BFF2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:19:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20130221130510.GB7240@phenom.dumpdata.com>
In-Reply-To: <20130221130510.GB7240@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Linux v3.9-rc0, three different bootup 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 21.02.13 at 14:05, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The first one is when booting PV guests:
> 
> [    0.831091] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
> [    0.831107] IP: [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
> [    0.831122] PGD 0 
> [    0.831130] Oops: 0000 [#1] SMP 
> [    0.831142] Modules linked in:
> [    0.831150] CPU 0 
> [    0.831156] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-03229-ge1f5dd0 #1  
> [    0.831166] RIP: e030:[<ffffffff8138978a>]  [<ffffffff8138978a>] apei_hest_parse+0x2a/0x140
> [    0.831178] RSP: e02b:ffff88003d369e88  EFLAGS: 00010246
> [    0.831185] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000000
> [    0.831193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81329ae0
> [    0.831200] RBP: ffff88003d369ea8 R08: 0000000000000000 R09: 0000000000000000
> [    0.831208] R10: 0000000000007ff0 R11: 0000000000000002 R12: 0000000000000000
> [    0.831215] R13: ffffffff81329ae0 R14: 0000000000000000 R15: 0000000000000000
> [    0.831227] FS:  0000000000000000(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> [    0.831236] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    0.831242] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000000660
> [    0.831251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    0.831258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [    0.831266] Process swapper/0 (pid: 1, threadinfo ffff88003d368000, task ffff88003d362800)
> [    0.831274] Stack:
> [    0.831280]  0000000000000030 0000000000000000 ffffffff81ae960e ffffffff81b402e8
> [    0.831298]  ffff88003d369eb8 ffffffff81329b3b ffff88003d369ec8 ffffffff81ae9620
> [    0.831316]  ffff88003d369ef8 ffffffff8100203d 0000000000000030 0000000000000007
> [    0.831336] Call Trace:
> [    0.831347]  [<ffffffff81ae960e>] ? pcie_portdrv_init+0x7a/0x7a
> [    0.831359]  [<ffffffff81329b3b>] aer_acpi_firmware_first+0x1b/0x30
> [    0.831370]  [<ffffffff81ae9620>] aer_service_init+0x12/0x2b

The bug here quite obviously is that with no ACPI you shouldn't
even get to that point. Yet apei_hest_parse() blindly uses
hest_tab - that ought to regress on real hardware too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:23:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:23: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 1U8W7g-0002Ma-45; Thu, 21 Feb 2013 13:23:40 +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 1U8W7e-0002MT-2r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:23:38 +0000
Received: from [193.109.254.147:39114] by server-7.bemta-14.messagelabs.com id
	9D/8F-13581-9DF16215; Thu, 21 Feb 2013 13:23:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361452905!2381323!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7406 invoked from network); 21 Feb 2013 13:21:45 -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; 21 Feb 2013 13:21:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:21:44 +0000
Message-Id: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:22:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB383C9B3.2__="
Cc: Tim Deegan <tim@xen.org>, Olaf Hering <olaf@aepfle.de>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>
Subject: [Xen-devel] [PATCH v3] x86/nhvm: properly clean up after failure to
 set up all vCPU-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>
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.

--=__PartB383C9B3.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise we may leak memory when setting up nHVM fails half way.

This implies that the individual destroy functions will have to remain
capable (in the VMX case they first need to be made so, following
26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
that the corresponding init function was never run on.

Once at it, also remove a redundant check from the corresponding
parameter validation code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Make sure we fully tear down nHVM when the parameter gets set to 0.
v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3918,18 +3918,20 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 }
                 if ( a.value > 1 )
                     rc =3D -EINVAL;
-                if ( !is_hvm_domain(d) )
-                    rc =3D -EINVAL;
                 /* Remove the check below once we have
                  * shadow-on-shadow.
                  */
                 if ( cpu_has_svm && !paging_mode_hap(d) && a.value )
                     rc =3D -EINVAL;
                 /* Set up NHVM state for any vcpus that are already up */
-                if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
+                if ( a.value &&
+                     !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
                     for_each_vcpu(d, v)
                         if ( rc =3D=3D 0 )
                             rc =3D nestedhvm_vcpu_initialise(v);
+                if ( !a.value || rc )
+                    for_each_vcpu(d, v)
+                        nestedhvm_vcpu_destroy(v);
                 break;
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc =3D -EINVAL;
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu *v
 void
 nestedhvm_vcpu_destroy(struct vcpu *v)
 {
-    if ( nestedhvm_enabled(v->domain) && hvm_funcs.nhvm_vcpu_destroy )
+    if ( hvm_funcs.nhvm_vcpu_destroy )
         hvm_funcs.nhvm_vcpu_destroy(v);
 }
=20
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     if ( !nvcpu->nv_n2vmcx )
     {
         gdprintk(XENLOG_ERR, "nest: allocation for shadow vmcs failed\n");=

-	goto out;
+        return -ENOMEM;
     }
=20
     /* non-root VMREAD/VMWRITE bitmap. */
@@ -75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmread_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmread bitmap =
failed\n");
-            goto out1;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmread_bitmap =3D vmread_bitmap;
=20
@@ -83,7 +83,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmwrite_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap =
failed\n");
-            goto out2;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;
=20
@@ -118,12 +118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     nvmx->msrbitmap =3D NULL;
     INIT_LIST_HEAD(&nvmx->launched_list);
     return 0;
-out2:
-    free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
-out1:
-    free_xenheap_page(nvcpu->nv_n2vmcx);
-out:
-    return -ENOMEM;
 }
 =20
 void nvmx_vcpu_destroy(struct vcpu *v)
@@ -147,16 +141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx =3D NULL;
     }
=20
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
-    {
-        list_del(&item->node);
-        xfree(item);
-    }
+    /* Must also cope with nvmx_vcpu_initialise() not having got called. =
*/
+    if ( nvmx->launched_list.next )
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
=20
     if ( v->arch.hvm_vmx.vmread_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
+        v->arch.hvm_vmx.vmread_bitmap =3D NULL;
+    }
     if ( v->arch.hvm_vmx.vmwrite_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmwrite_bitmap);
+        v->arch.hvm_vmx.vmwrite_bitmap =3D NULL;
+    }
 }
 =20
 void nvmx_domain_relinquish_resources(struct domain *d)



--=__PartB383C9B3.2__=
Content-Type: text/plain; name="x86-nhvm-enable-failure.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-nhvm-enable-failure.patch"

x86/nhvm: properly clean up after failure to set up all vCPU-s=0A=0AOtherwi=
se we may leak memory when setting up nHVM fails half way.=0A=0AThis =
implies that the individual destroy functions will have to remain=0Acapable=
 (in the VMX case they first need to be made so, following=0A26486:7648ef65=
7fe7 and 26489:83a3fa9c8434) of being called for a vCPU=0Athat the =
corresponding init function was never run on.=0A=0AOnce at it, also remove =
a redundant check from the corresponding=0Aparameter validation code.=0A=0A=
Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av3: Make sure we =
fully tear down nHVM when the parameter gets set to 0.=0Av2: nVMX fixes =
required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.=0A=0A--- a/xen/arch/=
x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c=0A@@ -3918,18 +3918,20 @@ =
long do_hvm_op(unsigned long op, XEN_GUE=0A                 }=0A           =
      if ( a.value > 1 )=0A                     rc =3D -EINVAL;=0A-        =
        if ( !is_hvm_domain(d) )=0A-                    rc =3D -EINVAL;=0A =
                /* Remove the check below once we have=0A                  =
* shadow-on-shadow.=0A                  */=0A                 if ( =
cpu_has_svm && !paging_mode_hap(d) && a.value )=0A                     rc =
=3D -EINVAL;=0A                 /* Set up NHVM state for any vcpus that =
are already up */=0A-                if ( !d->arch.hvm_domain.params[HVM_PA=
RAM_NESTEDHVM] )=0A+                if ( a.value &&=0A+                    =
 !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )=0A                     =
for_each_vcpu(d, v)=0A                         if ( rc =3D=3D 0 )=0A       =
                      rc =3D nestedhvm_vcpu_initialise(v);=0A+             =
   if ( !a.value || rc )=0A+                    for_each_vcpu(d, v)=0A+    =
                    nestedhvm_vcpu_destroy(v);=0A                 =
break;=0A             case HVM_PARAM_BUFIOREQ_EVTCHN:=0A                 =
rc =3D -EINVAL;=0A--- a/xen/arch/x86/hvm/nestedhvm.c=0A+++ b/xen/arch/x86/h=
vm/nestedhvm.c=0A@@ -87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu =
*v=0A void=0A nestedhvm_vcpu_destroy(struct vcpu *v)=0A {=0A-    if ( =
nestedhvm_enabled(v->domain) && hvm_funcs.nhvm_vcpu_destroy )=0A+    if ( =
hvm_funcs.nhvm_vcpu_destroy )=0A         hvm_funcs.nhvm_vcpu_destroy(v);=0A=
 }=0A =0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvm=
x.c=0A@@ -62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     if =
( !nvcpu->nv_n2vmcx )=0A     {=0A         gdprintk(XENLOG_ERR, "nest: =
allocation for shadow vmcs failed\n");=0A-	goto out;=0A+        =
return -ENOMEM;=0A     }=0A =0A     /* non-root VMREAD/VMWRITE bitmap. =
*/=0A@@ -75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A         =
if ( !vmread_bitmap )=0A         {=0A             gdprintk(XENLOG_ERR, =
"nest: allocation for vmread bitmap failed\n");=0A-            goto =
out1;=0A+            return -ENOMEM;=0A         }=0A         v->arch.hvm_vm=
x.vmread_bitmap =3D vmread_bitmap;=0A =0A@@ -83,7 +83,7 @@ int nvmx_vcpu_in=
itialise(struct vcpu *v)=0A         if ( !vmwrite_bitmap )=0A         {=0A =
            gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap =
failed\n");=0A-            goto out2;=0A+            return -ENOMEM;=0A    =
     }=0A         v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;=0A =
=0A@@ -118,12 +118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     =
nvmx->msrbitmap =3D NULL;=0A     INIT_LIST_HEAD(&nvmx->launched_list);=0A  =
   return 0;=0A-out2:=0A-    free_domheap_page(v->arch.hvm_vmx.vmread_bitma=
p);=0A-out1:=0A-    free_xenheap_page(nvcpu->nv_n2vmcx);=0A-out:=0A-    =
return -ENOMEM;=0A }=0A  =0A void nvmx_vcpu_destroy(struct vcpu *v)=0A@@ =
-147,16 +141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)=0A         =
nvcpu->nv_n2vmcx =3D NULL;=0A     }=0A =0A-    list_for_each_entry_safe(ite=
m, n, &nvmx->launched_list, node)=0A-    {=0A-        list_del(&item->node)=
;=0A-        xfree(item);=0A-    }=0A+    /* Must also cope with nvmx_vcpu_=
initialise() not having got called. */=0A+    if ( nvmx->launched_list.next=
 )=0A+        list_for_each_entry_safe(item, n, &nvmx->launched_list, =
node)=0A+        {=0A+            list_del(&item->node);=0A+            =
xfree(item);=0A+        }=0A =0A     if ( v->arch.hvm_vmx.vmread_bitmap =
)=0A+    {=0A         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);=0A+=
        v->arch.hvm_vmx.vmread_bitmap =3D NULL;=0A+    }=0A     if ( =
v->arch.hvm_vmx.vmwrite_bitmap )=0A+    {=0A         free_domheap_page(v->a=
rch.hvm_vmx.vmwrite_bitmap);=0A+        v->arch.hvm_vmx.vmwrite_bitmap =3D =
NULL;=0A+    }=0A }=0A  =0A void nvmx_domain_relinquish_resources(struct =
domain *d)=0A
--=__PartB383C9B3.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB383C9B3.2__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:23:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13:23: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 1U8W7g-0002Ma-45; Thu, 21 Feb 2013 13:23:40 +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 1U8W7e-0002MT-2r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:23:38 +0000
Received: from [193.109.254.147:39114] by server-7.bemta-14.messagelabs.com id
	9D/8F-13581-9DF16215; Thu, 21 Feb 2013 13:23:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361452905!2381323!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7406 invoked from network); 21 Feb 2013 13:21:45 -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; 21 Feb 2013 13:21:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 13:21:44 +0000
Message-Id: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 13:22:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB383C9B3.2__="
Cc: Tim Deegan <tim@xen.org>, Olaf Hering <olaf@aepfle.de>,
	Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>
Subject: [Xen-devel] [PATCH v3] x86/nhvm: properly clean up after failure to
 set up all vCPU-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>
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.

--=__PartB383C9B3.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise we may leak memory when setting up nHVM fails half way.

This implies that the individual destroy functions will have to remain
capable (in the VMX case they first need to be made so, following
26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
that the corresponding init function was never run on.

Once at it, also remove a redundant check from the corresponding
parameter validation code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Make sure we fully tear down nHVM when the parameter gets set to 0.
v2: nVMX fixes required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3918,18 +3918,20 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 }
                 if ( a.value > 1 )
                     rc =3D -EINVAL;
-                if ( !is_hvm_domain(d) )
-                    rc =3D -EINVAL;
                 /* Remove the check below once we have
                  * shadow-on-shadow.
                  */
                 if ( cpu_has_svm && !paging_mode_hap(d) && a.value )
                     rc =3D -EINVAL;
                 /* Set up NHVM state for any vcpus that are already up */
-                if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
+                if ( a.value &&
+                     !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
                     for_each_vcpu(d, v)
                         if ( rc =3D=3D 0 )
                             rc =3D nestedhvm_vcpu_initialise(v);
+                if ( !a.value || rc )
+                    for_each_vcpu(d, v)
+                        nestedhvm_vcpu_destroy(v);
                 break;
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc =3D -EINVAL;
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu *v
 void
 nestedhvm_vcpu_destroy(struct vcpu *v)
 {
-    if ( nestedhvm_enabled(v->domain) && hvm_funcs.nhvm_vcpu_destroy )
+    if ( hvm_funcs.nhvm_vcpu_destroy )
         hvm_funcs.nhvm_vcpu_destroy(v);
 }
=20
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     if ( !nvcpu->nv_n2vmcx )
     {
         gdprintk(XENLOG_ERR, "nest: allocation for shadow vmcs failed\n");=

-	goto out;
+        return -ENOMEM;
     }
=20
     /* non-root VMREAD/VMWRITE bitmap. */
@@ -75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmread_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmread bitmap =
failed\n");
-            goto out1;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmread_bitmap =3D vmread_bitmap;
=20
@@ -83,7 +83,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)
         if ( !vmwrite_bitmap )
         {
             gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap =
failed\n");
-            goto out2;
+            return -ENOMEM;
         }
         v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;
=20
@@ -118,12 +118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     nvmx->msrbitmap =3D NULL;
     INIT_LIST_HEAD(&nvmx->launched_list);
     return 0;
-out2:
-    free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
-out1:
-    free_xenheap_page(nvcpu->nv_n2vmcx);
-out:
-    return -ENOMEM;
 }
 =20
 void nvmx_vcpu_destroy(struct vcpu *v)
@@ -147,16 +141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)
         nvcpu->nv_n2vmcx =3D NULL;
     }
=20
-    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
-    {
-        list_del(&item->node);
-        xfree(item);
-    }
+    /* Must also cope with nvmx_vcpu_initialise() not having got called. =
*/
+    if ( nvmx->launched_list.next )
+        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
+        {
+            list_del(&item->node);
+            xfree(item);
+        }
=20
     if ( v->arch.hvm_vmx.vmread_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);
+        v->arch.hvm_vmx.vmread_bitmap =3D NULL;
+    }
     if ( v->arch.hvm_vmx.vmwrite_bitmap )
+    {
         free_domheap_page(v->arch.hvm_vmx.vmwrite_bitmap);
+        v->arch.hvm_vmx.vmwrite_bitmap =3D NULL;
+    }
 }
 =20
 void nvmx_domain_relinquish_resources(struct domain *d)



--=__PartB383C9B3.2__=
Content-Type: text/plain; name="x86-nhvm-enable-failure.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-nhvm-enable-failure.patch"

x86/nhvm: properly clean up after failure to set up all vCPU-s=0A=0AOtherwi=
se we may leak memory when setting up nHVM fails half way.=0A=0AThis =
implies that the individual destroy functions will have to remain=0Acapable=
 (in the VMX case they first need to be made so, following=0A26486:7648ef65=
7fe7 and 26489:83a3fa9c8434) of being called for a vCPU=0Athat the =
corresponding init function was never run on.=0A=0AOnce at it, also remove =
a redundant check from the corresponding=0Aparameter validation code.=0A=0A=
Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av3: Make sure we =
fully tear down nHVM when the parameter gets set to 0.=0Av2: nVMX fixes =
required by 26486:7648ef657fe7 and 26489:83a3fa9c8434.=0A=0A--- a/xen/arch/=
x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c=0A@@ -3918,18 +3918,20 @@ =
long do_hvm_op(unsigned long op, XEN_GUE=0A                 }=0A           =
      if ( a.value > 1 )=0A                     rc =3D -EINVAL;=0A-        =
        if ( !is_hvm_domain(d) )=0A-                    rc =3D -EINVAL;=0A =
                /* Remove the check below once we have=0A                  =
* shadow-on-shadow.=0A                  */=0A                 if ( =
cpu_has_svm && !paging_mode_hap(d) && a.value )=0A                     rc =
=3D -EINVAL;=0A                 /* Set up NHVM state for any vcpus that =
are already up */=0A-                if ( !d->arch.hvm_domain.params[HVM_PA=
RAM_NESTEDHVM] )=0A+                if ( a.value &&=0A+                    =
 !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )=0A                     =
for_each_vcpu(d, v)=0A                         if ( rc =3D=3D 0 )=0A       =
                      rc =3D nestedhvm_vcpu_initialise(v);=0A+             =
   if ( !a.value || rc )=0A+                    for_each_vcpu(d, v)=0A+    =
                    nestedhvm_vcpu_destroy(v);=0A                 =
break;=0A             case HVM_PARAM_BUFIOREQ_EVTCHN:=0A                 =
rc =3D -EINVAL;=0A--- a/xen/arch/x86/hvm/nestedhvm.c=0A+++ b/xen/arch/x86/h=
vm/nestedhvm.c=0A@@ -87,7 +87,7 @@ nestedhvm_vcpu_initialise(struct vcpu =
*v=0A void=0A nestedhvm_vcpu_destroy(struct vcpu *v)=0A {=0A-    if ( =
nestedhvm_enabled(v->domain) && hvm_funcs.nhvm_vcpu_destroy )=0A+    if ( =
hvm_funcs.nhvm_vcpu_destroy )=0A         hvm_funcs.nhvm_vcpu_destroy(v);=0A=
 }=0A =0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvm=
x.c=0A@@ -62,7 +62,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     if =
( !nvcpu->nv_n2vmcx )=0A     {=0A         gdprintk(XENLOG_ERR, "nest: =
allocation for shadow vmcs failed\n");=0A-	goto out;=0A+        =
return -ENOMEM;=0A     }=0A =0A     /* non-root VMREAD/VMWRITE bitmap. =
*/=0A@@ -75,7 +75,7 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A         =
if ( !vmread_bitmap )=0A         {=0A             gdprintk(XENLOG_ERR, =
"nest: allocation for vmread bitmap failed\n");=0A-            goto =
out1;=0A+            return -ENOMEM;=0A         }=0A         v->arch.hvm_vm=
x.vmread_bitmap =3D vmread_bitmap;=0A =0A@@ -83,7 +83,7 @@ int nvmx_vcpu_in=
itialise(struct vcpu *v)=0A         if ( !vmwrite_bitmap )=0A         {=0A =
            gdprintk(XENLOG_ERR, "nest: allocation for vmwrite bitmap =
failed\n");=0A-            goto out2;=0A+            return -ENOMEM;=0A    =
     }=0A         v->arch.hvm_vmx.vmwrite_bitmap =3D vmwrite_bitmap;=0A =
=0A@@ -118,12 +118,6 @@ int nvmx_vcpu_initialise(struct vcpu *v)=0A     =
nvmx->msrbitmap =3D NULL;=0A     INIT_LIST_HEAD(&nvmx->launched_list);=0A  =
   return 0;=0A-out2:=0A-    free_domheap_page(v->arch.hvm_vmx.vmread_bitma=
p);=0A-out1:=0A-    free_xenheap_page(nvcpu->nv_n2vmcx);=0A-out:=0A-    =
return -ENOMEM;=0A }=0A  =0A void nvmx_vcpu_destroy(struct vcpu *v)=0A@@ =
-147,16 +141,24 @@ void nvmx_vcpu_destroy(struct vcpu *v)=0A         =
nvcpu->nv_n2vmcx =3D NULL;=0A     }=0A =0A-    list_for_each_entry_safe(ite=
m, n, &nvmx->launched_list, node)=0A-    {=0A-        list_del(&item->node)=
;=0A-        xfree(item);=0A-    }=0A+    /* Must also cope with nvmx_vcpu_=
initialise() not having got called. */=0A+    if ( nvmx->launched_list.next=
 )=0A+        list_for_each_entry_safe(item, n, &nvmx->launched_list, =
node)=0A+        {=0A+            list_del(&item->node);=0A+            =
xfree(item);=0A+        }=0A =0A     if ( v->arch.hvm_vmx.vmread_bitmap =
)=0A+    {=0A         free_domheap_page(v->arch.hvm_vmx.vmread_bitmap);=0A+=
        v->arch.hvm_vmx.vmread_bitmap =3D NULL;=0A+    }=0A     if ( =
v->arch.hvm_vmx.vmwrite_bitmap )=0A+    {=0A         free_domheap_page(v->a=
rch.hvm_vmx.vmwrite_bitmap);=0A+        v->arch.hvm_vmx.vmwrite_bitmap =3D =
NULL;=0A+    }=0A }=0A  =0A void nvmx_domain_relinquish_resources(struct =
domain *d)=0A
--=__PartB383C9B3.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB383C9B3.2__=--


From xen-devel-bounces@lists.xen.org Thu Feb 21 13:54:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8WbY-00030M-Dg; Thu, 21 Feb 2013 13:54: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 1U8WbW-00030H-Ge
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:54:30 +0000
Received: from [85.158.139.211:25210] by server-15.bemta-5.messagelabs.com id
	EA/0C-18914-51726215; Thu, 21 Feb 2013 13:54:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361454867!18606885!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 21 Feb 2013 13:54:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:54:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="8299384"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 13:54:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 08:54:26 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1U8WbS-0005mj-0x;
	Thu, 21 Feb 2013 13:54:26 +0000
Message-ID: <51262710.5030703@eu.citrix.com>
Date: Thu, 21 Feb 2013 13:54:24 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
In-Reply-To: <1361207601.31175.6.camel@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/18/2013 05:13 PM, Dario Faggioli wrote:
> On Fri, 2013-02-01 at 12:01 +0100, Dario Faggioli wrote:
>> Hello Everyone,
>>
>> V3 of the NUMA aware scheduling series. It is nothing more than v2 with all
>> the review comments I got, addressed... Or so I think. :-)
>>
> Ping?

Sorry Dario -- this is my first priority as soon as I clear the stuff 
off my desk that has accumulated while I was away in Oman. :-)

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 13:54:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 13: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 1U8WbY-00030M-Dg; Thu, 21 Feb 2013 13:54: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 1U8WbW-00030H-Ge
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 13:54:30 +0000
Received: from [85.158.139.211:25210] by server-15.bemta-5.messagelabs.com id
	EA/0C-18914-51726215; Thu, 21 Feb 2013 13:54:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361454867!18606885!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 21 Feb 2013 13:54:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 13:54:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="8299384"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 13:54:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 08:54:26 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1U8WbS-0005mj-0x;
	Thu, 21 Feb 2013 13:54:26 +0000
Message-ID: <51262710.5030703@eu.citrix.com>
Date: Thu, 21 Feb 2013 13:54:24 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dario Faggioli <dario.faggioli@citrix.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
In-Reply-To: <1361207601.31175.6.camel@Solace>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/18/2013 05:13 PM, Dario Faggioli wrote:
> On Fri, 2013-02-01 at 12:01 +0100, Dario Faggioli wrote:
>> Hello Everyone,
>>
>> V3 of the NUMA aware scheduling series. It is nothing more than v2 with all
>> the review comments I got, addressed... Or so I think. :-)
>>
> Ping?

Sorry Dario -- this is my first priority as soon as I clear the stuff 
off my desk that has accumulated while I was away in Oman. :-)

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:09:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8Wpx-0003PL-SQ; Thu, 21 Feb 2013 14:09:25 +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 1U8Wpv-0003PG-Pv
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:09:23 +0000
Received: from [85.158.138.51:5153] by server-9.bemta-3.messagelabs.com id
	6E/96-09484-E8A26215; Thu, 21 Feb 2013 14:09:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361455757!20545566!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1747 invoked from network); 21 Feb 2013 14:09:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:09:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Wpl-00075u-6P; Thu, 21 Feb 2013 14:09:13 +0000
Date: Thu, 21 Feb 2013 14:09:13 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221140913.GJ24051@ocelot.phlegethon.org>
References: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] x86/nhvm: properly clean up after
	failure to set up all vCPU-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

At 13:22 +0000 on 21 Feb (1361452963), Jan Beulich wrote:
> Otherwise we may leak memory when setting up nHVM fails half way.
> 
> This implies that the individual destroy functions will have to remain
> capable (in the VMX case they first need to be made so, following
> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> that the corresponding init function was never run on.
> 
> Once at it, also remove a redundant check from the corresponding
> parameter validation code.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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 Thu Feb 21 14:09:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8Wpx-0003PL-SQ; Thu, 21 Feb 2013 14:09:25 +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 1U8Wpv-0003PG-Pv
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:09:23 +0000
Received: from [85.158.138.51:5153] by server-9.bemta-3.messagelabs.com id
	6E/96-09484-E8A26215; Thu, 21 Feb 2013 14:09:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361455757!20545566!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1747 invoked from network); 21 Feb 2013 14:09:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:09:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Wpl-00075u-6P; Thu, 21 Feb 2013 14:09:13 +0000
Date: Thu, 21 Feb 2013 14:09:13 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221140913.GJ24051@ocelot.phlegethon.org>
References: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] x86/nhvm: properly clean up after
	failure to set up all vCPU-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

At 13:22 +0000 on 21 Feb (1361452963), Jan Beulich wrote:
> Otherwise we may leak memory when setting up nHVM fails half way.
> 
> This implies that the individual destroy functions will have to remain
> capable (in the VMX case they first need to be made so, following
> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> that the corresponding init function was never run on.
> 
> Once at it, also remove a redundant check from the corresponding
> parameter validation code.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

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 Thu Feb 21 14:19:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8Wzb-0003jZ-W8; Thu, 21 Feb 2013 14:19:23 +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 1U8Wzb-0003jU-Dq
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:19:23 +0000
Received: from [85.158.138.51:11305] by server-1.bemta-3.messagelabs.com id
	B1/39-08955-AEC26215; Thu, 21 Feb 2013 14:19:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361456361!28541183!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27399 invoked from network); 21 Feb 2013 14:19:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 14:19:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (jorabe mo50) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z00a84p1LDlqKL ;
	Thu, 21 Feb 2013 15:19:20 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id BEC161884C; Thu, 21 Feb 2013 15:19:19 +0100 (CET)
Date: Thu, 21 Feb 2013 15:19:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130221141919.GA20093@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
	<20130221110119.GE24051@ocelot.phlegethon.org>
	<20130221111000.GG24051@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221111000.GG24051@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 Thu, Feb 21, Tim Deegan wrote:

> At 11:01 +0000 on 21 Feb (1361444479), Tim Deegan wrote:
> > (Cc'ing the vmx maintainers)
> > 
> > At 15:58 +0100 on 20 Feb (1361375903), Olaf Hering wrote:
> > > while doing "while xm migrate --live domU localhost;do sleep 1;done" I
> > > just got the crash shown below. And it can be reproduced.
> > > 
> > > The guest has 2 vcpus and 512mb, it runs pvops 3.7.9
> > 
> > Anything interesting printed before the crash?  My best guess by code
> > inspection is that nvmx->launched_list never got initialized, because of
> > some failure in vcpu init.
> > 
> > Also, if you have the xen-syms for this image, can you extract a
> > file/line-number for the crashing %rip (ffff82c4c01dd197)?
> > I'd expect it to be vvmx.c:150 or thereabouts.
> > 
> > And thirdly, can you try the attached patch?
> 
> Oops - not sure what I tested before , but that one doesn't even
> compile!  Try this instead.

This patch fixes the crash for me. Thanks.

Olaf

> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 4f3f94d..5d00ff7 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -147,10 +147,13 @@ void nvmx_vcpu_destroy(struct vcpu *v)
>          nvcpu->nv_n2vmcx = NULL;
>      }
>  
> -    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
> +    if ( nvmx->launched_list.next )
>      {
> -        list_del(&item->node);
> -        xfree(item);
> +        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
> +        {
> +            list_del(&item->node);
> +            xfree(item);
> +        }
>      }
>  
>      if ( v->arch.hvm_vmx.vmread_bitmap )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:19:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8Wzb-0003jZ-W8; Thu, 21 Feb 2013 14:19:23 +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 1U8Wzb-0003jU-Dq
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:19:23 +0000
Received: from [85.158.138.51:11305] by server-1.bemta-3.messagelabs.com id
	B1/39-08955-AEC26215; Thu, 21 Feb 2013 14:19:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361456361!28541183!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27399 invoked from network); 21 Feb 2013 14:19:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 14:19:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (jorabe mo50) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z00a84p1LDlqKL ;
	Thu, 21 Feb 2013 15:19:20 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id BEC161884C; Thu, 21 Feb 2013 15:19:19 +0100 (CET)
Date: Thu, 21 Feb 2013 15:19:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130221141919.GA20093@aepfle.de>
References: <20130220145823.GA18129@aepfle.de>
	<20130221110119.GE24051@ocelot.phlegethon.org>
	<20130221111000.GG24051@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221111000.GG24051@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 Thu, Feb 21, Tim Deegan wrote:

> At 11:01 +0000 on 21 Feb (1361444479), Tim Deegan wrote:
> > (Cc'ing the vmx maintainers)
> > 
> > At 15:58 +0100 on 20 Feb (1361375903), Olaf Hering wrote:
> > > while doing "while xm migrate --live domU localhost;do sleep 1;done" I
> > > just got the crash shown below. And it can be reproduced.
> > > 
> > > The guest has 2 vcpus and 512mb, it runs pvops 3.7.9
> > 
> > Anything interesting printed before the crash?  My best guess by code
> > inspection is that nvmx->launched_list never got initialized, because of
> > some failure in vcpu init.
> > 
> > Also, if you have the xen-syms for this image, can you extract a
> > file/line-number for the crashing %rip (ffff82c4c01dd197)?
> > I'd expect it to be vvmx.c:150 or thereabouts.
> > 
> > And thirdly, can you try the attached patch?
> 
> Oops - not sure what I tested before , but that one doesn't even
> compile!  Try this instead.

This patch fixes the crash for me. Thanks.

Olaf

> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 4f3f94d..5d00ff7 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -147,10 +147,13 @@ void nvmx_vcpu_destroy(struct vcpu *v)
>          nvcpu->nv_n2vmcx = NULL;
>      }
>  
> -    list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
> +    if ( nvmx->launched_list.next )
>      {
> -        list_del(&item->node);
> -        xfree(item);
> +        list_for_each_entry_safe(item, n, &nvmx->launched_list, node)
> +        {
> +            list_del(&item->node);
> +            xfree(item);
> +        }
>      }
>  
>      if ( v->arch.hvm_vmx.vmread_bitmap )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:21:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:21: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 1U8X1Z-0003pk-N3; Thu, 21 Feb 2013 14:21:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tdeegan@xensource.com>) id 1U8X1Y-0003pa-4C
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:21:24 +0000
Received: from [85.158.143.99:10854] by server-3.bemta-4.messagelabs.com id
	2A/07-02186-36D26215; Thu, 21 Feb 2013 14:21:23 +0000
X-Env-Sender: tdeegan@xensource.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361456480!27942897!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14499 invoked from network); 21 Feb 2013 14:21:22 -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;
	21 Feb 2013 14:21:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="8307565"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 14:21:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 09:21:18 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tdeegan@xensource.com>)	id 1U8X1R-0006ME-VY;
	Thu, 21 Feb 2013 14:21:17 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tdeegan@whitby.uk.xensource.com>)	id 1U8X1R-0004IO-Jr;
	Thu, 21 Feb 2013 14:21:17 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 14:21:09 +0000
Message-ID: <1361456469-16406-1-git-send-email-tim@xen.org>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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

The reworking of p2m lookups to use get_gfn()/put_gfn() left the
shadow code not taking the p2m lock, even in cases where the p2m would
be updated (i.e. PoD).

In many cases, shadow code doesn't need the exclusion that
get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
updates, but this is taking things too far, and can lead to crashes in
the PoD code.

Now that most shadow-code p2m lookups are done with explicitly
unlocked accessors, or with the get_page_from_gfn() accessor, which is
often lock-free, we can just turn this locking on.

The remaining locked lookups are in sh_page_fault() (in a path that's
almost always already serializing on the paging lock), and in
emulate_map_dest() (which can probably be updated to use
get_page_from_gfn()).  They're not addressed here but may be in a
follow-up patch.

Signed-off-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm/p2m.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index de1dd82..2db73c9 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -218,8 +218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
         return _mfn(gfn);
     }
 
-    /* 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);
 
@@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
 
 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;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:21:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:21: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 1U8X1Z-0003pk-N3; Thu, 21 Feb 2013 14:21:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tdeegan@xensource.com>) id 1U8X1Y-0003pa-4C
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:21:24 +0000
Received: from [85.158.143.99:10854] by server-3.bemta-4.messagelabs.com id
	2A/07-02186-36D26215; Thu, 21 Feb 2013 14:21:23 +0000
X-Env-Sender: tdeegan@xensource.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361456480!27942897!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14499 invoked from network); 21 Feb 2013 14:21:22 -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;
	21 Feb 2013 14:21:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; 
   d="scan'208";a="8307565"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 14:21:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 09:21:18 -0500
Received: from whitby.uk.xensource.com ([10.80.2.60])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<tdeegan@xensource.com>)	id 1U8X1R-0006ME-VY;
	Thu, 21 Feb 2013 14:21:17 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tdeegan@whitby.uk.xensource.com>)	id 1U8X1R-0004IO-Jr;
	Thu, 21 Feb 2013 14:21:17 +0000
From: Tim Deegan <tim@xen.org>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 14:21:09 +0000
Message-ID: <1361456469-16406-1-git-send-email-tim@xen.org>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>
Subject: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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

The reworking of p2m lookups to use get_gfn()/put_gfn() left the
shadow code not taking the p2m lock, even in cases where the p2m would
be updated (i.e. PoD).

In many cases, shadow code doesn't need the exclusion that
get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
updates, but this is taking things too far, and can lead to crashes in
the PoD code.

Now that most shadow-code p2m lookups are done with explicitly
unlocked accessors, or with the get_page_from_gfn() accessor, which is
often lock-free, we can just turn this locking on.

The remaining locked lookups are in sh_page_fault() (in a path that's
almost always already serializing on the paging lock), and in
emulate_map_dest() (which can probably be updated to use
get_page_from_gfn()).  They're not addressed here but may be in a
follow-up patch.

Signed-off-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm/p2m.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index de1dd82..2db73c9 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -218,8 +218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
         return _mfn(gfn);
     }
 
-    /* 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);
 
@@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
 
 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;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:23:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:23: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 1U8X32-0003x1-6a; Thu, 21 Feb 2013 14:22:56 +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 1U8X30-0003wm-7P
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:22:54 +0000
Received: from [85.158.139.211:33977] by server-5.bemta-5.messagelabs.com id
	C3/3B-11945-DBD26215; Thu, 21 Feb 2013 14:22:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361456572!18174178!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32658 invoked from network); 21 Feb 2013 14:22:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:22:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8X2x-00078o-Cm; Thu, 21 Feb 2013 14:22:51 +0000
Date: Thu, 21 Feb 2013 14:22:51 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221142251.GK24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
	<20130221110119.GE24051@ocelot.phlegethon.org>
	<20130221111000.GG24051@ocelot.phlegethon.org>
	<20130221141919.GA20093@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221141919.GA20093@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 15:19 +0100 on 21 Feb (1361459959), Olaf Hering wrote:
> This patch fixes the crash for me. Thanks.

Great - in that case it will be fixed by Jan's more comprehensive patch
when that goes in.

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 Feb 21 14:23:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:23: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 1U8X32-0003x1-6a; Thu, 21 Feb 2013 14:22:56 +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 1U8X30-0003wm-7P
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:22:54 +0000
Received: from [85.158.139.211:33977] by server-5.bemta-5.messagelabs.com id
	C3/3B-11945-DBD26215; Thu, 21 Feb 2013 14:22:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361456572!18174178!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32658 invoked from network); 21 Feb 2013 14:22:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:22:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8X2x-00078o-Cm; Thu, 21 Feb 2013 14:22:51 +0000
Date: Thu, 21 Feb 2013 14:22:51 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20130221142251.GK24051@ocelot.phlegethon.org>
References: <20130220145823.GA18129@aepfle.de>
	<20130221110119.GE24051@ocelot.phlegethon.org>
	<20130221111000.GG24051@ocelot.phlegethon.org>
	<20130221141919.GA20093@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221141919.GA20093@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] crash in nvmx_vcpu_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 15:19 +0100 on 21 Feb (1361459959), Olaf Hering wrote:
> This patch fixes the crash for me. Thanks.

Great - in that case it will be fixed by Jan's more comprehensive patch
when that goes in.

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 Feb 21 14:24:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:24: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 1U8X3u-00042y-DX; Thu, 21 Feb 2013 14:23:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U8X3s-00042E-6w; Thu, 21 Feb 2013 14:23:48 +0000
Received: from [85.158.139.211:17022] by server-3.bemta-5.messagelabs.com id
	9E/AD-07037-3FD26215; Thu, 21 Feb 2013 14:23:47 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361456621!18549606!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30770 invoked from network); 21 Feb 2013 14:23:42 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-14.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Feb 2013 14:23:42 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U8X3c-000207-Ah; Thu, 21 Feb 2013 14:23:32 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U8X3b-0007ni-Cw; Thu, 21 Feb 2013 14:23:31 +0000
Date: Thu, 21 Feb 2013 14:23:31 +0000
Message-Id: <E1U8X3b-0007ni-Cw@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 36 (CVE-2013-0153) - interrupt
 remap entries shared and old ones not cleared on AMD IOMMUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2013-0153 / XSA-36
			      version 4

  interrupt remap entries shared and old ones not cleared on AMD IOMMUs

UPDATES IN VERSION 4
====================

Updated patches, to deal with a boot time crash resulting from the earlier
changes on systems with firmware broken in a way not previously accounted
for.

ISSUE DESCRIPTION
=================

To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system.  This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.

Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.

In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.

IMPACT
======

A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.

VULNERABLE SYSTEMS
==================

Xen versions 3.3 onwards are vulnerable.  Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.

Only systems using AMD-Vi for PCI passthrough are vulnerable.

Any domain which is given access to a PCI device can take advantage of
this vulnerability.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted
guests.

In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor.  This option is not fully functional on earlier
hypervisors.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore.  This should be dealt with by a BIOS
update, if available.  Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.

xsa36-unstable.patch              Xen unstable
xsa36-4.2.patch                   Xen 4.2.x
xsa36-4.1.patch                   Xen 4.1.x

$ sha256sum xsa36*.patch
4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0efc6f4  xsa36-4.1.patch
dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc21204067c4eb8964  xsa36-4.2.patch
7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c440e2992a7b5cfe41  xsa36-unstable.patch
$

Incremental patches on top of what was provided in version 3 can also be
taken from the respective mercurial trees:

http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739
http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOencxa9R3TGTn
20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltzcnd
6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/
PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A
zRNADG36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP
ICpJJFf0w7oW6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=
=vmpB
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa36-4.1.patch"
Content-Disposition: attachment; filename="xsa36-4.1.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgpBTUQg
SU9NTVU6IGFsc28gc3BvdCBtaXNzaW5nIElPLUFQSUMgZW50cmllcyBpbiBJ
VlJTIHRhYmxlCgpBcGFydCBmcm9tIGRlYWxpbmcgZHVwbGljYXRlIGNvbmZs
aWN0aW5nIGVudHJpZXMsIHdlIGFsc28gaGF2ZSB0bwpoYW5kbGUgZmlybXdh
cmUgb21pdHRpbmcgSU8tQVBJQyBlbnRyaWVzIGluIElWUlMgYWx0b2dldGhl
ci4gTm90IGRvaW5nCnNvIGhhcyByZXN1bHRlZCBpbiBjL3MgMjY1MTc6NjAx
MTM5ZTJiMGRiIHRvIGNyYXNoIHN1Y2ggc3lzdGVtcyBkdXJpbmcKYm9vdCAo
d2hlcmVhcyB3aXRoIHRoZSBjaGFuZ2UgaGVyZSB0aGUgSU9NTVUgZ2V0cyBk
aXNhYmxlZCBqdXN0IGFzIGlzCmJlaW5nIGRvbmUgaW4gdGhlIG90aGVyIGNh
c2VzLCBpLmUuIHVubGVzcyBnbG9iYWwgdGFibGVzIGFyZSBiZWluZwp1c2Vk
KS4KCkRlYnVnZ2luZyB0aGlzIGlzc3VlIGhhcyBhbHNvIHBvaW50ZWQgb3V0
IHRoYXQgdGhlIGRlYnVnIGxvZyBvdXRwdXQgaXMKcHJldHR5IHVnbHkgdG8g
bG9vayBhdCAtIGNvbnNvbGlkYXRlIHRoZSBvdXRwdXQsIGFuZCBhZGQgb25l
IGV4dHJhCml0ZW0gZm9yIHRoZSBJVkhEIHNwZWNpYWwgZW50cmllcywgc28g
dGhhdCBmdXR1cmUgaXNzdWVzIGFyZSBlYXNpZXIKdG8gYW5hbHl6ZS4KClNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
VGVzdGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5i
b29tLml0PgoKLS0tIGEveGVuL2FyY2gveDg2L2lycS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9pcnEuYwpAQCAtMTY3Nyw5ICsxNjc3LDYgQEAgaW50IG1hcF9k
b21haW5fcGlycSgKICAgICAgICAgZC0+YXJjaC5waXJxX2lycVtwaXJxXSA9
IGlycTsKICAgICAgICAgZC0+YXJjaC5pcnFfcGlycVtpcnFdID0gcGlycTsK
ICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZGVzYy0+bG9jaywg
ZmxhZ3MpOwotCi0gICAgICAgIGlmICggb3B0X2lycV92ZWN0b3JfbWFwID09
IE9QVF9JUlFfVkVDVE9SX01BUF9QRVJERVYgKQotICAgICAgICAgICAgcHJp
bnRrKFhFTkxPR19JTkZPICJQZXItZGV2aWNlIHZlY3RvciBtYXBzIGZvciBH
U0lzIG5vdCBpbXBsZW1lbnRlZCB5ZXQuXG4iKTsKICAgICB9CiAKIGRvbmU6
Ci0tLSBhL3hlbi9kcml2ZXJzL2FjcGkvdGFibGVzLmMKKysrIGIveGVuL2Ry
aXZlcnMvYWNwaS90YWJsZXMuYwpAQCAtMjY3LDcgKzI2Nyw3IEBAIGFjcGlf
dGFibGVfcGFyc2VfbWFkdChlbnVtIGFjcGlfbWFkdF90eXAKICAqIEBoYW5k
bGVyOiBoYW5kbGVyIHRvIHJ1bgogICoKICAqIFNjYW4gdGhlIEFDUEkgU3lz
dGVtIERlc2NyaXB0b3IgVGFibGUgKFNURCkgZm9yIGEgdGFibGUgbWF0Y2hp
bmcgQGlkLAotICogcnVuIEBoYW5kbGVyIG9uIGl0LiAgUmV0dXJuIDAgaWYg
dGFibGUgZm91bmQsIHJldHVybiBvbiBpZiBub3QuCisgKiBydW4gQGhhbmRs
ZXIgb24gaXQuCiAgKi8KIGludCBhY3BpX3RhYmxlX3BhcnNlKGNoYXIgKmlk
LCBhY3BpX3RhYmxlX2hhbmRsZXIgaGFuZGxlcikKIHsKQEAgLTI4Miw4ICsy
ODIsNyBAQCBpbnQgYWNwaV90YWJsZV9wYXJzZShjaGFyICppZCwgYWNwaV90
YWJsCiAJCWFjcGlfZ2V0X3RhYmxlKGlkLCAwLCAmdGFibGUpOwogCiAJaWYg
KHRhYmxlKSB7Ci0JCWhhbmRsZXIodGFibGUpOwotCQlyZXR1cm4gMDsKKwkJ
cmV0dXJuIGhhbmRsZXIodGFibGUpOwogCX0gZWxzZQogCQlyZXR1cm4gMTsK
IH0KLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2Fj
cGkuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVf
YWNwaS5jCkBAIC0yMSw2ICsyMSw3IEBACiAjaW5jbHVkZSA8eGVuL2NvbmZp
Zy5oPgogI2luY2x1ZGUgPHhlbi9lcnJuby5oPgogI2luY2x1ZGUgPGFzbS9h
cGljZGVmLmg+CisjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4KICNpbmNsdWRl
IDxhc20vYW1kLWlvbW11Lmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9zdm0vYW1k
LWlvbW11LXByb3RvLmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9zdm0vYW1kLWlv
bW11LWFjcGkuaD4KQEAgLTI5LDcgKzMwLDYgQEAgZXh0ZXJuIHVuc2lnbmVk
IGxvbmcgYW1kX2lvbW11X3BhZ2VfZW50cgogZXh0ZXJuIHVuc2lnbmVkIHNo
b3J0IGl2cnNfYmRmX2VudHJpZXM7CiBleHRlcm4gc3RydWN0IGl2cnNfbWFw
cGluZ3MgKml2cnNfbWFwcGluZ3M7CiBleHRlcm4gdW5zaWduZWQgc2hvcnQg
bGFzdF9iZGY7Ci1leHRlcm4gaW50IGlvYXBpY19iZGZbTUFYX0lPX0FQSUNT
XTsKIGV4dGVybiB2b2lkICpzaGFyZWRfaW50cmVtYXBfdGFibGU7CiAKIHN0
YXRpYyB2b2lkIGFkZF9pdnJzX21hcHBpbmdfZW50cnkoCkBAIC02MzYsNiAr
NjM2LDcgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZpY2Vf
c3BlYwogICAgIHUxNiBoZWFkZXJfbGVuZ3RoLCB1MTYgYmxvY2tfbGVuZ3Ro
LCBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkKIHsKICAgICB1MTYgZGV2X2xl
bmd0aCwgYmRmOworICAgIGludCBhcGljOwogCiAgICAgZGV2X2xlbmd0aCA9
IHNpemVvZihzdHJ1Y3QgYWNwaV9pdmhkX2RldmljZV9zcGVjaWFsKTsKICAg
ICBpZiAoIGhlYWRlcl9sZW5ndGggPCAoYmxvY2tfbGVuZ3RoICsgZGV2X2xl
bmd0aCkgKQpAQCAtNjUyLDkgKzY1Myw1OCBAQCBzdGF0aWMgdTE2IF9faW5p
dCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAgfQogCiAgICAgYWRkX2l2
cnNfbWFwcGluZ19lbnRyeShiZGYsIGJkZiwgaXZoZF9kZXZpY2UtPmhlYWRl
ci5mbGFncywgaW9tbXUpOwotICAgIC8qIHNldCBkZXZpY2UgaWQgb2YgaW9h
cGljICovCi0gICAgaW9hcGljX2JkZltpdmhkX2RldmljZS0+c3BlY2lhbC5o
YW5kbGVdID0gYmRmOwotICAgIHJldHVybiBkZXZfbGVuZ3RoOworCisgICAg
aWYgKCBpdmhkX2RldmljZS0+c3BlY2lhbC52YXJpZXR5ICE9IDEgLyogQUNQ
SV9JVkhEX0lPQVBJQyAqLyApCisgICAgeworICAgICAgICBpZiAoIGl2aGRf
ZGV2aWNlLT5zcGVjaWFsLnZhcmlldHkgIT0gMiAvKiBBQ1BJX0lWSERfSFBF
VCAqLyApCisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiVW5yZWNv
Z25pemVkIElWSEQgc3BlY2lhbCB2YXJpZXR5ICUjeFxuIiwKKyAgICAgICAg
ICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lhbC52YXJpZXR5KTsKKyAg
ICAgICAgcmV0dXJuIGRldl9sZW5ndGg7CisgICAgfQorCisgICAgLyoKKyAg
ICAgKiBTb21lIEJJT1NlcyBoYXZlIElPQVBJQyBicm9rZW4gZW50cmllcyBz
byB3ZSBjaGVjayBmb3IgSVZSUworICAgICAqIGNvbnNpc3RlbmN5IGhlcmUg
LS0tIHdoZXRoZXIgZW50cnkncyBJT0FQSUMgSUQgaXMgdmFsaWQgYW5kCisg
ICAgICogd2hldGhlciB0aGVyZSBhcmUgY29uZmxpY3RpbmcvZHVwbGljYXRl
ZCBlbnRyaWVzLgorICAgICAqLworICAgIGZvciAoIGFwaWMgPSAwOyBhcGlj
IDwgbnJfaW9hcGljczsgYXBpYysrICkKKyAgICB7CisgICAgICAgIGlmICgg
SU9fQVBJQ19JRChhcGljKSAhPSBpdmhkX2RldmljZS0+c3BlY2lhbC5oYW5k
bGUgKQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgaWYgKCBp
b2FwaWNfYmRmW2l2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZV0ucGluX3Nl
dHVwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCBpb2FwaWNfYmRm
W2l2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZV0uYmRmID09IGJkZiApCisg
ICAgICAgICAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJJVkhEIFdhcm5pbmc6
IER1cGxpY2F0ZSBJTy1BUElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lhbC5o
YW5kbGUpOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBD
b25mbGljdGluZyBJTy1BUElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAg
ICAgICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lhbC5oYW5kbGUpOwor
ICAgICAgICAgICAgICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRyZW1h
cCApCisgICAgICAgICAgICAgICAgICAgIHJldHVybiAwOworICAgICAgICAg
ICAgfQorICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgeworICAg
ICAgICAgICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMgKi8KKyAgICAg
ICAgICAgIGlvYXBpY19iZGZbaXZoZF9kZXZpY2UtPnNwZWNpYWwuaGFuZGxl
XS5iZGYgPSBiZGY7CisKKyAgICAgICAgICAgIGlvYXBpY19iZGZbaXZoZF9k
ZXZpY2UtPnNwZWNpYWwuaGFuZGxlXS5waW5fc2V0dXAgPSB4emFsbG9jX2Fy
cmF5KAorICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9f
TE9OR1MobnJfaW9hcGljX3JlZ2lzdGVyc1thcGljXSkpOworICAgICAgICAg
ICAgaWYgKCBucl9pb2FwaWNfcmVnaXN0ZXJzW2FwaWNdICYmCisgICAgICAg
ICAgICAgICAgICFpb2FwaWNfYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9z
ZXR1cCApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgcHJpbnRr
KFhFTkxPR19FUlIgIklWSEQgRXJyb3I6IE91dCBvZiBtZW1vcnlcbiIpOwor
ICAgICAgICAgICAgICAgIHJldHVybiAwOworICAgICAgICAgICAgfQorICAg
ICAgICB9CisgICAgICAgIHJldHVybiBkZXZfbGVuZ3RoOworICAgIH0KKwor
ICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBJbnZhbGlkIElP
LUFQSUMgJSN4XG4iLAorICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lh
bC5oYW5kbGUpOworICAgIHJldHVybiAwOwogfQogCiBzdGF0aWMgaW50IF9f
aW5pdCBwYXJzZV9pdmhkX2Jsb2NrKHN0cnVjdCBhY3BpX2l2aGRfYmxvY2tf
aGVhZGVyICppdmhkX2Jsb2NrKQpAQCAtODE3LDYgKzg2Nyw3IEBAIHN0YXRp
YyBpbnQgX19pbml0IHBhcnNlX2l2cnNfdGFibGUoc3RydWMKIHsKICAgICBz
dHJ1Y3QgYWNwaV9pdnJzX2Jsb2NrX2hlYWRlciAqaXZyc19ibG9jazsKICAg
ICB1bnNpZ25lZCBsb25nIGxlbmd0aDsKKyAgICB1bnNpZ25lZCBpbnQgYXBp
YzsKICAgICBpbnQgZXJyb3IgPSAwOwogICAgIHN0cnVjdCBhY3BpX3RhYmxl
X2hlYWRlciAqdGFibGUgPSAoc3RydWN0IGFjcGlfdGFibGVfaGVhZGVyICop
X3RhYmxlOwogCkBAIC04NTEsNiArOTAyLDI5IEBAIHN0YXRpYyBpbnQgX19p
bml0IHBhcnNlX2l2cnNfdGFibGUoc3RydWMKICAgICAgICAgbGVuZ3RoICs9
IGl2cnNfYmxvY2stPmxlbmd0aDsKICAgICB9CiAKKyAgICAvKiBFYWNoIElP
LUFQSUMgbXVzdCBoYXZlIGJlZW4gbWVudGlvbmVkIGluIHRoZSB0YWJsZS4g
Ki8KKyAgICBmb3IgKCBhcGljID0gMDsgIWVycm9yICYmIGFwaWMgPCBucl9p
b2FwaWNzOyArK2FwaWMgKQorICAgIHsKKyAgICAgICAgaWYgKCAhbnJfaW9h
cGljX3JlZ2lzdGVyc1thcGljXSB8fAorICAgICAgICAgICAgIGlvYXBpY19i
ZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3NldHVwICkKKyAgICAgICAgICAg
IGNvbnRpbnVlOworCisgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhE
IEVycm9yOiBubyBpbmZvcm1hdGlvbiBmb3IgSU8tQVBJQyAlI3hcbiIsCisg
ICAgICAgICAgICAgICBJT19BUElDX0lEKGFwaWMpKTsKKyAgICAgICAgaWYg
KCBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgICAgIGVy
cm9yID0gLUVOWElPOworICAgICAgICBlbHNlCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlvYXBpY19iZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3NldHVw
ID0geHphbGxvY19hcnJheSgKKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBs
b25nLCBCSVRTX1RPX0xPTkdTKG5yX2lvYXBpY19yZWdpc3RlcnNbYXBpY10p
KTsKKyAgICAgICAgICAgIGlmICggIWlvYXBpY19iZGZbSU9fQVBJQ19JRChh
cGljKV0ucGluX3NldHVwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogT3V0IG9mIG1l
bW9yeVxuIik7CisgICAgICAgICAgICAgICAgZXJyb3IgPSAtRU5PTUVNOwor
ICAgICAgICAgICAgfQorICAgICAgICB9CisgICAgfQorCiAgICAgcmV0dXJu
IGVycm9yOwogfQogCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9pbml0LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv
YW1kL2lvbW11X2luaXQuYwpAQCAtODk3LDEyICs4OTcsNDUgQEAgc3RhdGlj
IGludCBfX2luaXQgYW1kX2lvbW11X3NldHVwX2RldmljZQogICAgIHJldHVy
biAwOwogfQogCisvKiBDaGVjayB3aGV0aGVyIFNQNTEwMCBTQVRBIENvbWJp
bmVkIG1vZGUgaXMgb24gKi8KK3N0YXRpYyBib29sX3QgX19pbml0IGFtZF9z
cDUxMDBfZXJyYXR1bTI4KHZvaWQpCit7CisgICAgdTMyIGJ1cywgaWQ7Cisg
ICAgdTE2IHZlbmRvcl9pZCwgZGV2X2lkOworICAgIHU4IGJ5dGU7CisKKyAg
ICBmb3IgKGJ1cyA9IDA7IGJ1cyA8IDI1NjsgYnVzKyspCisgICAgeworICAg
ICAgICBpZCA9IHBjaV9jb25mX3JlYWQzMihidXMsIDB4MTQsIDAsIFBDSV9W
RU5ET1JfSUQpOworCisgICAgICAgIHZlbmRvcl9pZCA9IGlkICYgMHhmZmZm
OworICAgICAgICBkZXZfaWQgPSAoaWQgPj4gMTYpICYgMHhmZmZmOworCisg
ICAgICAgIC8qIFNQNTEwMCBTTUJ1cyBtb2R1bGUgc2V0cyBDb21iaW5lZCBt
b2RlIG9uICovCisgICAgICAgIGlmICh2ZW5kb3JfaWQgIT0gMHgxMDAyIHx8
IGRldl9pZCAhPSAweDQzODUpCisgICAgICAgICAgICBjb250aW51ZTsKKwor
ICAgICAgICBieXRlID0gcGNpX2NvbmZfcmVhZDgoYnVzLCAweDE0LCAwLCAw
eGFkKTsKKyAgICAgICAgaWYgKCAoYnl0ZSA+PiAzKSAmIDEgKQorICAgICAg
ICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIkFNRC1W
aTogU1A1MTAwIGVycmF0dW0gMjggZGV0ZWN0ZWQsIGRpc2FibGluZyBJT01N
VS5cbiIKKyAgICAgICAgICAgICAgICAgICAiSWYgcG9zc2libGUsIGRpc2Fi
bGUgU0FUQSBDb21iaW5lZCBtb2RlIGluIEJJT1Mgb3IgY29udGFjdCB5b3Vy
IHZlbmRvciBmb3IgQklPUyB1cGRhdGUuXG4iKTsKKyAgICAgICAgICAgIHJl
dHVybiAxOworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9
CisKIGludCBfX2luaXQgYW1kX2lvbW11X2luaXQodm9pZCkKIHsKICAgICBz
dHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIAogICAgIEJVR19PTiggIWlvbW11
X2ZvdW5kKCkgKTsKIAorICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRy
ZW1hcCAmJiBhbWRfc3A1MTAwX2VycmF0dW0yOCgpICkKKyAgICAgICAgZ290
byBlcnJvcl9vdXQ7CisKICAgICBpcnFfdG9faW9tbXUgPSB4bWFsbG9jX2Fy
cmF5KHN0cnVjdCBhbWRfaW9tbXUgKiwgbnJfaXJxcyk7CiAgICAgaWYgKCBp
cnFfdG9faW9tbXUgPT0gTlVMTCApCiAgICAgICAgIGdvdG8gZXJyb3Jfb3V0
OwotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW50
ci5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9p
bnRyLmMKQEAgLTI3LDcgKzI3LDcgQEAKICNkZWZpbmUgSU5UUkVNQVBfTEVO
R1RIIDB4QgogI2RlZmluZSBJTlRSRU1BUF9FTlRSSUVTICgxIDw8IElOVFJF
TUFQX0xFTkdUSCkKIAotaW50IGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsK
K3N0cnVjdCBpb2FwaWNfYmRmIGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsK
IGV4dGVybiBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19tYXBwaW5nczsK
IGV4dGVybiB1bnNpZ25lZCBzaG9ydCBpdnJzX2JkZl9lbnRyaWVzOwogdm9p
ZCAqc2hhcmVkX2ludHJlbWFwX3RhYmxlOwpAQCAtMTE3LDEyICsxMTcsMTIg
QEAgdm9pZCBpbnZhbGlkYXRlX2ludGVycnVwdF90YWJsZShzdHJ1Y3QgYQog
c3RhdGljIHZvaWQgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGlj
KAogICAgIGludCBiZGYsCiAgICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXUs
Ci0gICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKmlvYXBpY19ydGUp
CisgICAgY29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSwK
KyAgICBjb25zdCBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqb2xkX3J0
ZSkKIHsKICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwogICAgIHUzMiogZW50
cnk7CiAgICAgdTggZGVsaXZlcnlfbW9kZSwgZGVzdCwgdmVjdG9yLCBkZXN0
X21vZGU7Ci0gICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSA9
IGlvYXBpY19ydGU7CiAgICAgaW50IHJlcV9pZDsKICAgICBzcGlubG9ja190
ICpsb2NrOwogICAgIGludCBvZmZzZXQ7CkBAIC0xMzgsNiArMTM4LDE0IEBA
IHN0YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2kKICAg
ICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrLCBmbGFncyk7CiAKICAgICBvZmZz
ZXQgPSBnZXRfaW50cmVtYXBfb2Zmc2V0KHZlY3RvciwgZGVsaXZlcnlfbW9k
ZSk7CisgICAgaWYgKCBvbGRfcnRlICkKKyAgICB7CisgICAgICAgIGludCBv
bGRfb2Zmc2V0ID0gZ2V0X2ludHJlbWFwX29mZnNldChvbGRfcnRlLT52ZWN0
b3IsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBvbGRfcnRlLT5kZWxpdmVyeV9tb2RlKTsKKworICAgICAgICBpZiAo
IG9mZnNldCAhPSBvbGRfb2Zmc2V0ICkKKyAgICAgICAgICAgIGZyZWVfaW50
cmVtYXBfZW50cnkoYmRmLCBvbGRfb2Zmc2V0KTsKKyAgICB9CiAgICAgZW50
cnkgPSAodTMyKilnZXRfaW50cmVtYXBfZW50cnkocmVxX2lkLCBvZmZzZXQp
OwogICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeShlbnRyeSwgdmVjdG9yLCBk
ZWxpdmVyeV9tb2RlLCBkZXN0X21vZGUsIGRlc3QpOwogCkBAIC0xNzYsNyAr
MTg0LDcgQEAgaW50IF9faW5pdCBhbWRfaW9tbXVfc2V0dXBfaW9hcGljX3Jl
bWFwcAogICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCiAgICAgICAgICAg
ICAvKiBnZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyBkZXZpY2VzICovCi0gICAg
ICAgICAgICBiZGYgPSBpb2FwaWNfYmRmW0lPX0FQSUNfSUQoYXBpYyldOwor
ICAgICAgICAgICAgYmRmID0gaW9hcGljX2JkZltJT19BUElDX0lEKGFwaWMp
XS5iZGY7CiAgICAgICAgICAgICBpb21tdSA9IGZpbmRfaW9tbXVfZm9yX2Rl
dmljZShiZGYpOwogICAgICAgICAgICAgaWYgKCAhaW9tbXUgKQogICAgICAg
ICAgICAgewpAQCAtMjA3LDYgKzIxNSw3IEBAIGludCBfX2luaXQgYW1kX2lv
bW11X3NldHVwX2lvYXBpY19yZW1hcHAKICAgICAgICAgICAgICAgICBmbHVz
aF9jb21tYW5kX2J1ZmZlcihpb21tdSk7CiAgICAgICAgICAgICAgICAgc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsKICAg
ICAgICAgICAgIH0KKyAgICAgICAgICAgIHNldF9iaXQocGluLCBpb2FwaWNf
YmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCk7CiAgICAgICAgIH0K
ICAgICB9CiAgICAgcmV0dXJuIDA7CkBAIC0yMTgsNiArMjI3LDcgQEAgdm9p
ZCBhbWRfaW9tbXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAgICAgc3RydWN0IElP
X0FQSUNfcm91dGVfZW50cnkgb2xkX3J0ZSA9IHsgMCB9OwogICAgIHN0cnVj
dCBJT19BUElDX3JvdXRlX2VudHJ5IG5ld19ydGUgPSB7IDAgfTsKICAgICB1
bnNpZ25lZCBpbnQgcnRlX2xvID0gKHJlZyAmIDEpID8gcmVnIC0gMSA6IHJl
ZzsKKyAgICB1bnNpZ25lZCBpbnQgcGluID0gKHJlZyAtIDB4MTApIC8gMjsK
ICAgICBpbnQgc2F2ZWRfbWFzaywgYmRmOwogICAgIHN0cnVjdCBhbWRfaW9t
bXUgKmlvbW11OwogCkBAIC0yMjgsNyArMjM4LDcgQEAgdm9pZCBhbWRfaW9t
bXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAgICAgfQogCiAgICAgLyogZ2V0IGRl
dmljZSBpZCBvZiBpb2FwaWMgZGV2aWNlcyAqLwotICAgIGJkZiA9IGlvYXBp
Y19iZGZbSU9fQVBJQ19JRChhcGljKV07CisgICAgYmRmID0gaW9hcGljX2Jk
ZltJT19BUElDX0lEKGFwaWMpXS5iZGY7CiAgICAgaW9tbXUgPSBmaW5kX2lv
bW11X2Zvcl9kZXZpY2UoYmRmKTsKICAgICBpZiAoICFpb21tdSApCiAgICAg
ewpAQCAtMjU0LDYgKzI2NCwxNCBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNf
dXBkYXRlX2lyZSgKICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRlKSArIDEp
ID0gdmFsdWU7CiAgICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1hc2sgJiYK
KyAgICAgICAgICF0ZXN0X2JpdChwaW4sIGlvYXBpY19iZGZbSU9fQVBJQ19J
RChhcGljKV0ucGluX3NldHVwKSApCisgICAgeworICAgICAgICBBU1NFUlQo
c2F2ZWRfbWFzayk7CisgICAgICAgIF9faW9fYXBpY193cml0ZShhcGljLCBy
ZWcsIHZhbHVlKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAgIC8q
IG1hc2sgdGhlIGludGVycnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGludHJl
bWFwIHRhYmxlICovCiAgICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAgewpA
QCAtMjYyLDcgKzI4MCwxMSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBk
YXRlX2lyZSgKICAgICB9CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0IHJl
bWFwcGluZyBlbnRyeSAqLwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9m
cm9tX2lvYXBpYyhiZGYsIGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBkYXRl
X2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGljKAorICAgICAgICBiZGYsIGlv
bW11LCAmbmV3X3J0ZSwKKyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChwaW4s
CisgICAgICAgICAgICAgICAgICAgICAgICAgaW9hcGljX2JkZltJT19BUElD
X0lEKGFwaWMpXS5waW5fc2V0dXApID8gJm9sZF9ydGUKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgOiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQgd3JpdGUgYWNj
ZXNzIHRvIElPLUFQSUMgUlRFICovCiAgICAgX19pb19hcGljX3dyaXRlKGFw
aWMsIHJlZywgdmFsdWUpOwpAQCAtMzczLDYgKzM5NSwxMiBAQCB2b2lkIGFt
ZF9pb21tdV9tc2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAgIHJldHVybjsK
ICAgICB9CiAKKyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9pbmRleCA+PSAw
ICkKKyAgICAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21z
Zyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIE5VTEwpOworCisgICAgaWYgKCAh
bXNnICkKKyAgICAgICAgcmV0dXJuOworCiAgICAgdXBkYXRlX2ludHJlbWFw
X2VudHJ5X2Zyb21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIG1z
Zyk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3Bj
aV9hbWRfaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h
bWQvcGNpX2FtZF9pb21tdS5jCkBAIC0xOTUsNiArMTk1LDggQEAgaW50IF9f
aW5pdCBhbWRfaW92X2RldGVjdCh2b2lkKQogICAgIHsKICAgICAgICAgcHJp
bnRrKCJBTUQtVmk6IE5vdCBvdmVycmlkaW5nIGlycV92ZWN0b3JfbWFwIHNl
dHRpbmdcbiIpOwogICAgIH0KKyAgICBpZiAoICFhbWRfaW9tbXVfcGVyZGV2
X2ludHJlbWFwICkKKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJB
TUQtVmk6IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUgaXMg
bm90IHJlY29tbWVuZGVkIChzZWUgWFNBLTM2KSFcbiIpOwogICAgIHJldHVy
biBzY2FuX3BjaV9kZXZpY2VzKCk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9pb21tdS5jCkBAIC00OSw3ICs0OSw3IEBAIGJvb2xfdCBfX3JlYWRf
bW9zdGx5IGlvbW11X3FpbnZhbCA9IDE7CiBib29sX3QgX19yZWFkX21vc3Rs
eSBpb21tdV9pbnRyZW1hcCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBp
b21tdV9oYXBfcHRfc2hhcmU7CiBib29sX3QgX19yZWFkX21vc3RseSBhbWRf
aW9tbXVfZGVidWc7Ci1ib29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVf
cGVyZGV2X2ludHJlbWFwOworYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lv
bW11X3BlcmRldl9pbnRyZW1hcCA9IDE7CiAKIHN0YXRpYyB2b2lkIF9faW5p
dCBwYXJzZV9pb21tdV9wYXJhbShjaGFyICpzKQogewpAQCAtNzgsNiArNzgs
OCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcGFyc2VfaW9tbXVfcGFyYW0oY2hh
CiAgICAgICAgICAgICBhbWRfaW9tbXVfZGVidWcgPSAxOwogICAgICAgICBl
bHNlIGlmICggIXN0cmNtcChzLCAiYW1kLWlvbW11LXBlcmRldi1pbnRyZW1h
cCIpICkKICAgICAgICAgICAgIGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAg
PSAxOworICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzLCAiYW1kLWlvbW11
LWdsb2JhbC1pbnRyZW1hcCIpICkKKyAgICAgICAgICAgIGFtZF9pb21tdV9w
ZXJkZXZfaW50cmVtYXAgPSAwOwogICAgICAgICBlbHNlIGlmICggIXN0cmNt
cChzLCAiZG9tMC1wYXNzdGhyb3VnaCIpICkKICAgICAgICAgICAgIGlvbW11
X3Bhc3N0aHJvdWdoID0gMTsKICAgICAgICAgZWxzZSBpZiAoICFzdHJjbXAo
cywgImRvbTAtc3RyaWN0IikgKQotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2
L2h2bS9zdm0vYW1kLWlvbW11LXByb3RvLmgKKysrIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oCkBAIC04OCw2ICs4
OCwxMSBAQCB2b2lkIGFtZF9pb21tdV9yZWFkX21zaV9mcm9tX2lyZSgKIHVu
c2lnbmVkIGludCBhbWRfaW9tbXVfcmVhZF9pb2FwaWNfZnJvbV9pcmUoCiAg
ICAgdW5zaWduZWQgaW50IGFwaWMsIHVuc2lnbmVkIGludCByZWcpOwogCitl
eHRlcm4gc3RydWN0IGlvYXBpY19iZGYgeworICAgIHUxNiBiZGY7CisgICAg
dW5zaWduZWQgbG9uZyAqcGluX3NldHVwOworfSBpb2FwaWNfYmRmW107CisK
IC8qIHBvd2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAqLwogdm9pZCBhbWRfaW9t
bXVfcmVzdW1lKHZvaWQpOwogdm9pZCBhbWRfaW9tbXVfc3VzcGVuZCh2b2lk
KTsK

--=separator
Content-Type: application/octet-stream; name="xsa36-4.2.patch"
Content-Disposition: attachment; filename="xsa36-4.2.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgpBTUQg
SU9NTVU6IGFsc28gc3BvdCBtaXNzaW5nIElPLUFQSUMgZW50cmllcyBpbiBJ
VlJTIHRhYmxlCgpBcGFydCBmcm9tIGRlYWxpbmcgZHVwbGljYXRlIGNvbmZs
aWN0aW5nIGVudHJpZXMsIHdlIGFsc28gaGF2ZSB0bwpoYW5kbGUgZmlybXdh
cmUgb21pdHRpbmcgSU8tQVBJQyBlbnRyaWVzIGluIElWUlMgYWx0b2dldGhl
ci4gTm90IGRvaW5nCnNvIGhhcyByZXN1bHRlZCBpbiBjL3MgMjY1MTc6NjAx
MTM5ZTJiMGRiIHRvIGNyYXNoIHN1Y2ggc3lzdGVtcyBkdXJpbmcKYm9vdCAo
d2hlcmVhcyB3aXRoIHRoZSBjaGFuZ2UgaGVyZSB0aGUgSU9NTVUgZ2V0cyBk
aXNhYmxlZCBqdXN0IGFzIGlzCmJlaW5nIGRvbmUgaW4gdGhlIG90aGVyIGNh
c2VzLCBpLmUuIHVubGVzcyBnbG9iYWwgdGFibGVzIGFyZSBiZWluZwp1c2Vk
KS4KCkRlYnVnZ2luZyB0aGlzIGlzc3VlIGhhcyBhbHNvIHBvaW50ZWQgb3V0
IHRoYXQgdGhlIGRlYnVnIGxvZyBvdXRwdXQgaXMKcHJldHR5IHVnbHkgdG8g
bG9vayBhdCAtIGNvbnNvbGlkYXRlIHRoZSBvdXRwdXQsIGFuZCBhZGQgb25l
IGV4dHJhCml0ZW0gZm9yIHRoZSBJVkhEIHNwZWNpYWwgZW50cmllcywgc28g
dGhhdCBmdXR1cmUgaXNzdWVzIGFyZSBlYXNpZXIKdG8gYW5hbHl6ZS4KClNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
VGVzdGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5i
b29tLml0PgoKLS0tIGEveGVuL2FyY2gveDg2L2lycS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9pcnEuYwpAQCAtMTk0Miw5ICsxOTQyLDYgQEAgaW50IG1hcF9k
b21haW5fcGlycSgKICAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJmRlc2Mt
PmxvY2ssIGZsYWdzKTsKICAgICAgICAgc2V0X2RvbWFpbl9pcnFfcGlycShk
LCBpcnEsIGluZm8pOwogICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3Jl
KCZkZXNjLT5sb2NrLCBmbGFncyk7Ci0KLSAgICAgICAgaWYgKCBvcHRfaXJx
X3ZlY3Rvcl9tYXAgPT0gT1BUX0lSUV9WRUNUT1JfTUFQX1BFUkRFViApCi0g
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0lORk8gIlBlci1kZXZpY2UgdmVj
dG9yIG1hcHMgZm9yIEdTSXMgbm90IGltcGxlbWVudGVkIHlldC5cbiIpOwog
ICAgIH0KIAogZG9uZToKLS0tIGEveGVuL2RyaXZlcnMvYWNwaS90YWJsZXMu
YworKysgYi94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCkBAIC0yNjcsNyAr
MjY3LDcgQEAgYWNwaV90YWJsZV9wYXJzZV9tYWR0KGVudW0gYWNwaV9tYWR0
X3R5cAogICogQGhhbmRsZXI6IGhhbmRsZXIgdG8gcnVuCiAgKgogICogU2Nh
biB0aGUgQUNQSSBTeXN0ZW0gRGVzY3JpcHRvciBUYWJsZSAoU1REKSBmb3Ig
YSB0YWJsZSBtYXRjaGluZyBAaWQsCi0gKiBydW4gQGhhbmRsZXIgb24gaXQu
ICBSZXR1cm4gMCBpZiB0YWJsZSBmb3VuZCwgcmV0dXJuIG9uIGlmIG5vdC4K
KyAqIHJ1biBAaGFuZGxlciBvbiBpdC4KICAqLwogaW50IF9faW5pdCBhY3Bp
X3RhYmxlX3BhcnNlKGNoYXIgKmlkLCBhY3BpX3RhYmxlX2hhbmRsZXIgaGFu
ZGxlcikKIHsKQEAgLTI4Miw4ICsyODIsNyBAQCBpbnQgX19pbml0IGFjcGlf
dGFibGVfcGFyc2UoY2hhciAqaWQsIGFjCiAJCWFjcGlfZ2V0X3RhYmxlKGlk
LCAwLCAmdGFibGUpOwogCiAJaWYgKHRhYmxlKSB7Ci0JCWhhbmRsZXIodGFi
bGUpOwotCQlyZXR1cm4gMDsKKwkJcmV0dXJuIGhhbmRsZXIodGFibGUpOwog
CX0gZWxzZQogCQlyZXR1cm4gMTsKIH0KLS0tIGEveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYworKysgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jCkBAIC0yMiw2ICsyMiw3IEBA
CiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CiAjaW5jbHVkZSA8eGVuL2FjcGku
aD4KICNpbmNsdWRlIDxhc20vYXBpY2RlZi5oPgorI2luY2x1ZGUgPGFzbS9p
b19hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2FtZC1pb21tdS5oPgogI2luY2x1
ZGUgPGFzbS9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oPgogCkBAIC02MzUs
NiArNjM2LDcgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZp
Y2Vfc3BlYwogICAgIHUxNiBoZWFkZXJfbGVuZ3RoLCB1MTYgYmxvY2tfbGVu
Z3RoLCBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkKIHsKICAgICB1MTYgZGV2
X2xlbmd0aCwgYmRmOworICAgIGludCBhcGljOwogCiAgICAgZGV2X2xlbmd0
aCA9IHNpemVvZigqc3BlY2lhbCk7CiAgICAgaWYgKCBoZWFkZXJfbGVuZ3Ro
IDwgKGJsb2NrX2xlbmd0aCArIGRldl9sZW5ndGgpICkKQEAgLTY1MSwxMCAr
NjUzLDU5IEBAIHN0YXRpYyB1MTYgX19pbml0IHBhcnNlX2l2aGRfZGV2aWNl
X3NwZWMKICAgICB9CiAKICAgICBhZGRfaXZyc19tYXBwaW5nX2VudHJ5KGJk
ZiwgYmRmLCBzcGVjaWFsLT5oZWFkZXIuZGF0YV9zZXR0aW5nLCBpb21tdSk7
Ci0gICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMgKi8KLSAgICBpb2Fw
aWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLmJkZiA9IGJkZjsKLSAgICBpb2Fw
aWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLnNlZyA9IHNlZzsKLSAgICByZXR1
cm4gZGV2X2xlbmd0aDsKKworICAgIGlmICggc3BlY2lhbC0+dmFyaWV0eSAh
PSBBQ1BJX0lWSERfSU9BUElDICkKKyAgICB7CisgICAgICAgIGlmICggc3Bl
Y2lhbC0+dmFyaWV0eSAhPSBBQ1BJX0lWSERfSFBFVCApCisgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAiVW5yZWNvZ25pemVkIElWSEQgc3BlY2lh
bCB2YXJpZXR5ICUjeFxuIiwKKyAgICAgICAgICAgICAgICAgICBzcGVjaWFs
LT52YXJpZXR5KTsKKyAgICAgICAgcmV0dXJuIGRldl9sZW5ndGg7CisgICAg
fQorCisgICAgLyoKKyAgICAgKiBTb21lIEJJT1NlcyBoYXZlIElPQVBJQyBi
cm9rZW4gZW50cmllcyBzbyB3ZSBjaGVjayBmb3IgSVZSUworICAgICAqIGNv
bnNpc3RlbmN5IGhlcmUgLS0tIHdoZXRoZXIgZW50cnkncyBJT0FQSUMgSUQg
aXMgdmFsaWQgYW5kCisgICAgICogd2hldGhlciB0aGVyZSBhcmUgY29uZmxp
Y3RpbmcvZHVwbGljYXRlZCBlbnRyaWVzLgorICAgICAqLworICAgIGZvciAo
IGFwaWMgPSAwOyBhcGljIDwgbnJfaW9hcGljczsgYXBpYysrICkKKyAgICB7
CisgICAgICAgIGlmICggSU9fQVBJQ19JRChhcGljKSAhPSBzcGVjaWFsLT5o
YW5kbGUgKQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgaWYg
KCBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLnBpbl9zZXR1cCApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggaW9hcGljX3NiZGZbc3BlY2lh
bC0+aGFuZGxlXS5iZGYgPT0gYmRmICYmCisgICAgICAgICAgICAgICAgIGlv
YXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0uc2VnID09IHNlZyApCisgICAg
ICAgICAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJJVkhEIFdhcm5pbmc6IER1
cGxpY2F0ZSBJTy1BUElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzcGVjaWFsLT5oYW5kbGUpOworICAgICAg
ICAgICAgZWxzZQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBDb25mbGljdGluZyBJTy1B
UElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgICBz
cGVjaWFsLT5oYW5kbGUpOworICAgICAgICAgICAgICAgIGlmICggYW1kX2lv
bW11X3BlcmRldl9pbnRyZW1hcCApCisgICAgICAgICAgICAgICAgICAgIHJl
dHVybiAwOworICAgICAgICAgICAgfQorICAgICAgICB9CisgICAgICAgIGVs
c2UKKyAgICAgICAgeworICAgICAgICAgICAgLyogc2V0IGRldmljZSBpZCBv
ZiBpb2FwaWMgKi8KKyAgICAgICAgICAgIGlvYXBpY19zYmRmW3NwZWNpYWwt
PmhhbmRsZV0uYmRmID0gYmRmOworICAgICAgICAgICAgaW9hcGljX3NiZGZb
c3BlY2lhbC0+aGFuZGxlXS5zZWcgPSBzZWc7CisKKyAgICAgICAgICAgIGlv
YXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0ucGluX3NldHVwID0geHphbGxv
Y19hcnJheSgKKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nLCBCSVRT
X1RPX0xPTkdTKG5yX2lvYXBpY19lbnRyaWVzW2FwaWNdKSk7CisgICAgICAg
ICAgICBpZiAoIG5yX2lvYXBpY19lbnRyaWVzW2FwaWNdICYmCisgICAgICAg
ICAgICAgICAgICFpb2FwaWNfc2JkZltJT19BUElDX0lEKGFwaWMpXS5waW5f
c2V0dXAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIHByaW50
ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBPdXQgb2YgbWVtb3J5XG4iKTsK
KyAgICAgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgICAgIH0KKyAg
ICAgICAgfQorICAgICAgICByZXR1cm4gZGV2X2xlbmd0aDsKKyAgICB9CisK
KyAgICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogSW52YWxpZCBJ
Ty1BUElDICUjeFxuIiwgc3BlY2lhbC0+aGFuZGxlKTsKKyAgICByZXR1cm4g
MDsKIH0KIAogc3RhdGljIGludCBfX2luaXQgcGFyc2VfaXZoZF9ibG9jayhj
b25zdCBzdHJ1Y3QgYWNwaV9pdnJzX2hhcmR3YXJlICppdmhkX2Jsb2NrKQpA
QCAtODE4LDYgKzg2OSw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2l2
cnNfdGFibGUoc3RydWMKIHsKICAgICBjb25zdCBzdHJ1Y3QgYWNwaV9pdnJz
X2hlYWRlciAqaXZyc19ibG9jazsKICAgICB1bnNpZ25lZCBsb25nIGxlbmd0
aDsKKyAgICB1bnNpZ25lZCBpbnQgYXBpYzsKICAgICBpbnQgZXJyb3IgPSAw
OwogCiAgICAgQlVHX09OKCF0YWJsZSk7CkBAIC04NTAsNiArOTAyLDI5IEBA
IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2l2cnNfdGFibGUoc3RydWMKICAg
ICAgICAgbGVuZ3RoICs9IGl2cnNfYmxvY2stPmxlbmd0aDsKICAgICB9CiAK
KyAgICAvKiBFYWNoIElPLUFQSUMgbXVzdCBoYXZlIGJlZW4gbWVudGlvbmVk
IGluIHRoZSB0YWJsZS4gKi8KKyAgICBmb3IgKCBhcGljID0gMDsgIWVycm9y
ICYmIGFwaWMgPCBucl9pb2FwaWNzOyArK2FwaWMgKQorICAgIHsKKyAgICAg
ICAgaWYgKCAhbnJfaW9hcGljX2VudHJpZXNbYXBpY10gfHwKKyAgICAgICAg
ICAgICBpb2FwaWNfc2JkZltJT19BUElDX0lEKGFwaWMpXS5waW5fc2V0dXAg
KQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlIgIklWSEQgRXJyb3I6IG5vIGluZm9ybWF0aW9uIGZvciBJTy1B
UElDICUjeFxuIiwKKyAgICAgICAgICAgICAgIElPX0FQSUNfSUQoYXBpYykp
OworICAgICAgICBpZiAoIGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAgKQor
ICAgICAgICAgICAgZXJyb3IgPSAtRU5YSU87CisgICAgICAgIGVsc2UKKyAg
ICAgICAgeworICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChh
cGljKV0ucGluX3NldHVwID0geHphbGxvY19hcnJheSgKKyAgICAgICAgICAg
ICAgICB1bnNpZ25lZCBsb25nLCBCSVRTX1RPX0xPTkdTKG5yX2lvYXBpY19l
bnRyaWVzW2FwaWNdKSk7CisgICAgICAgICAgICBpZiAoICFpb2FwaWNfc2Jk
ZltJT19BUElDX0lEKGFwaWMpXS5waW5fc2V0dXAgKQorICAgICAgICAgICAg
eworICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVy
cm9yOiBPdXQgb2YgbWVtb3J5XG4iKTsKKyAgICAgICAgICAgICAgICBlcnJv
ciA9IC1FTk9NRU07CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICB9
CisKICAgICByZXR1cm4gZXJyb3I7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvYW1kL2lvbW11X2luaXQuYworKysgYi94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCkBAIC0xMTI2LDEyICsx
MTI2LDQ1IEBAIHN0YXRpYyBpbnQgX19pbml0IGFtZF9pb21tdV9zZXR1cF9k
ZXZpY2UKICAgICByZXR1cm4gMDsKIH0KIAorLyogQ2hlY2sgd2hldGhlciBT
UDUxMDAgU0FUQSBDb21iaW5lZCBtb2RlIGlzIG9uICovCitzdGF0aWMgYm9v
bF90IF9faW5pdCBhbWRfc3A1MTAwX2VycmF0dW0yOCh2b2lkKQoreworICAg
IHUzMiBidXMsIGlkOworICAgIHUxNiB2ZW5kb3JfaWQsIGRldl9pZDsKKyAg
ICB1OCBieXRlOworCisgICAgZm9yIChidXMgPSAwOyBidXMgPCAyNTY7IGJ1
cysrKQorICAgIHsKKyAgICAgICAgaWQgPSBwY2lfY29uZl9yZWFkMzIoMCwg
YnVzLCAweDE0LCAwLCBQQ0lfVkVORE9SX0lEKTsKKworICAgICAgICB2ZW5k
b3JfaWQgPSBpZCAmIDB4ZmZmZjsKKyAgICAgICAgZGV2X2lkID0gKGlkID4+
IDE2KSAmIDB4ZmZmZjsKKworICAgICAgICAvKiBTUDUxMDAgU01CdXMgbW9k
dWxlIHNldHMgQ29tYmluZWQgbW9kZSBvbiAqLworICAgICAgICBpZiAodmVu
ZG9yX2lkICE9IDB4MTAwMiB8fCBkZXZfaWQgIT0gMHg0Mzg1KQorICAgICAg
ICAgICAgY29udGludWU7CisKKyAgICAgICAgYnl0ZSA9IHBjaV9jb25mX3Jl
YWQ4KDAsIGJ1cywgMHgxNCwgMCwgMHhhZCk7CisgICAgICAgIGlmICggKGJ5
dGUgPj4gMykgJiAxICkKKyAgICAgICAgeworICAgICAgICAgICAgcHJpbnRr
KFhFTkxPR19XQVJOSU5HICJBTUQtVmk6IFNQNTEwMCBlcnJhdHVtIDI4IGRl
dGVjdGVkLCBkaXNhYmxpbmcgSU9NTVUuXG4iCisgICAgICAgICAgICAgICAg
ICAgIklmIHBvc3NpYmxlLCBkaXNhYmxlIFNBVEEgQ29tYmluZWQgbW9kZSBp
biBCSU9TIG9yIGNvbnRhY3QgeW91ciB2ZW5kb3IgZm9yIEJJT1MgdXBkYXRl
LlxuIik7CisgICAgICAgICAgICByZXR1cm4gMTsKKyAgICAgICAgfQorICAg
IH0KKworICAgIHJldHVybiAwOworfQorCiBpbnQgX19pbml0IGFtZF9pb21t
dV9pbml0KHZvaWQpCiB7CiAgICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXU7
CiAKICAgICBCVUdfT04oICFpb21tdV9mb3VuZCgpICk7CiAKKyAgICBpZiAo
IGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAgJiYgYW1kX3NwNTEwMF9lcnJh
dHVtMjgoKSApCisgICAgICAgIGdvdG8gZXJyb3Jfb3V0OworCiAgICAgaXZy
c19iZGZfZW50cmllcyA9IGFtZF9pb21tdV9nZXRfaXZyc19kZXZfZW50cmll
cygpOwogCiAgICAgaWYgKCAhaXZyc19iZGZfZW50cmllcyApCi0tLSBhL3hl
bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbnRyLmMKKysrIGIv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2ludHIuYwpAQCAt
OTksMTIgKzk5LDEyIEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9l
bnRyeSh1MzIqIGUKIHN0YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRy
eV9mcm9tX2lvYXBpYygKICAgICBpbnQgYmRmLAogICAgIHN0cnVjdCBhbWRf
aW9tbXUgKmlvbW11LAotICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5
ICppb2FwaWNfcnRlKQorICAgIGNvbnN0IHN0cnVjdCBJT19BUElDX3JvdXRl
X2VudHJ5ICpydGUsCisgICAgY29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVf
ZW50cnkgKm9sZF9ydGUpCiB7CiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsK
ICAgICB1MzIqIGVudHJ5OwogICAgIHU4IGRlbGl2ZXJ5X21vZGUsIGRlc3Qs
IHZlY3RvciwgZGVzdF9tb2RlOwotICAgIHN0cnVjdCBJT19BUElDX3JvdXRl
X2VudHJ5ICpydGUgPSBpb2FwaWNfcnRlOwogICAgIGludCByZXFfaWQ7CiAg
ICAgc3BpbmxvY2tfdCAqbG9jazsKICAgICBpbnQgb2Zmc2V0OwpAQCAtMTIw
LDYgKzEyMCwxNCBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50
cnlfZnJvbV9pCiAgICAgc3Bpbl9sb2NrX2lycXNhdmUobG9jaywgZmxhZ3Mp
OwogCiAgICAgb2Zmc2V0ID0gZ2V0X2ludHJlbWFwX29mZnNldCh2ZWN0b3Is
IGRlbGl2ZXJ5X21vZGUpOworICAgIGlmICggb2xkX3J0ZSApCisgICAgewor
ICAgICAgICBpbnQgb2xkX29mZnNldCA9IGdldF9pbnRyZW1hcF9vZmZzZXQo
b2xkX3J0ZS0+dmVjdG9yLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgb2xkX3J0ZS0+ZGVsaXZlcnlfbW9kZSk7CisK
KyAgICAgICAgaWYgKCBvZmZzZXQgIT0gb2xkX29mZnNldCApCisgICAgICAg
ICAgICBmcmVlX2ludHJlbWFwX2VudHJ5KGlvbW11LT5zZWcsIGJkZiwgb2xk
X29mZnNldCk7CisgICAgfQogICAgIGVudHJ5ID0gKHUzMiopZ2V0X2ludHJl
bWFwX2VudHJ5KGlvbW11LT5zZWcsIHJlcV9pZCwgb2Zmc2V0KTsKICAgICB1
cGRhdGVfaW50cmVtYXBfZW50cnkoZW50cnksIHZlY3RvciwgZGVsaXZlcnlf
bW9kZSwgZGVzdF9tb2RlLCBkZXN0KTsKIApAQCAtMTg4LDYgKzE5Niw3IEBA
IGludCBfX2luaXQgYW1kX2lvbW11X3NldHVwX2lvYXBpY19yZW1hcHAKICAg
ICAgICAgICAgICAgICBhbWRfaW9tbXVfZmx1c2hfaW50cmVtYXAoaW9tbXUs
IHJlcV9pZCk7CiAgICAgICAgICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVz
dG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsKICAgICAgICAgICAgIH0KKyAg
ICAgICAgICAgIHNldF9iaXQocGluLCBpb2FwaWNfc2JkZltJT19BUElDX0lE
KGFwaWMpXS5waW5fc2V0dXApOwogICAgICAgICB9CiAgICAgfQogICAgIHJl
dHVybiAwOwpAQCAtMTk5LDYgKzIwOCw3IEBAIHZvaWQgYW1kX2lvbW11X2lv
YXBpY191cGRhdGVfaXJlKAogICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2Vu
dHJ5IG9sZF9ydGUgPSB7IDAgfTsKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0
ZV9lbnRyeSBuZXdfcnRlID0geyAwIH07CiAgICAgdW5zaWduZWQgaW50IHJ0
ZV9sbyA9IChyZWcgJiAxKSA/IHJlZyAtIDEgOiByZWc7CisgICAgdW5zaWdu
ZWQgaW50IHBpbiA9IChyZWcgLSAweDEwKSAvIDI7CiAgICAgaW50IHNhdmVk
X21hc2ssIHNlZywgYmRmOwogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11
OwogCkBAIC0yMzYsNiArMjQ2LDE0IEBAIHZvaWQgYW1kX2lvbW11X2lvYXBp
Y191cGRhdGVfaXJlKAogICAgICAgICAqKCgodTMyICopJm5ld19ydGUpICsg
MSkgPSB2YWx1ZTsKICAgICB9CiAKKyAgICBpZiAoIG5ld19ydGUubWFzayAm
JgorICAgICAgICAgIXRlc3RfYml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJ
Q19JRChhcGljKV0ucGluX3NldHVwKSApCisgICAgeworICAgICAgICBBU1NF
UlQoc2F2ZWRfbWFzayk7CisgICAgICAgIF9faW9fYXBpY193cml0ZShhcGlj
LCByZWcsIHZhbHVlKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAg
IC8qIG1hc2sgdGhlIGludGVycnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGlu
dHJlbWFwIHRhYmxlICovCiAgICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAg
ewpAQCAtMjQ0LDcgKzI2MiwxMSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNf
dXBkYXRlX2lyZSgKICAgICB9CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0
IHJlbWFwcGluZyBlbnRyeSAqLwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRy
eV9mcm9tX2lvYXBpYyhiZGYsIGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBk
YXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGljKAorICAgICAgICBiZGYs
IGlvbW11LCAmbmV3X3J0ZSwKKyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChw
aW4sCisgICAgICAgICAgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9f
QVBJQ19JRChhcGljKV0ucGluX3NldHVwKSA/ICZvbGRfcnRlCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA6IE5VTEwpOwogCiAgICAgLyogRm9yd2FyZCB3cml0
ZSBhY2Nlc3MgdG8gSU8tQVBJQyBSVEUgKi8KICAgICBfX2lvX2FwaWNfd3Jp
dGUoYXBpYywgcmVnLCB2YWx1ZSk7CkBAIC0zNTQsNiArMzc2LDEyIEBAIHZv
aWQgYW1kX2lvbW11X21zaV9tc2dfdXBkYXRlX2lyZSgKICAgICAgICAgcmV0
dXJuOwogICAgIH0KIAorICAgIGlmICggbXNpX2Rlc2MtPnJlbWFwX2luZGV4
ID49IDAgKQorICAgICAgICB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9t
c2lfbXNnKGlvbW11LCBwZGV2LCBtc2lfZGVzYywgTlVMTCk7CisKKyAgICBp
ZiAoICFtc2cgKQorICAgICAgICByZXR1cm47CisKICAgICB1cGRhdGVfaW50
cmVtYXBfZW50cnlfZnJvbV9tc2lfbXNnKGlvbW11LCBwZGV2LCBtc2lfZGVz
YywgbXNnKTsKIH0KIAotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h
bWQvcGNpX2FtZF9pb21tdS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL2FtZC9wY2lfYW1kX2lvbW11LmMKQEAgLTIwNSw2ICsyMDUsOCBAQCBp
bnQgX19pbml0IGFtZF9pb3ZfZGV0ZWN0KHZvaWQpCiAgICAgewogICAgICAg
ICBwcmludGsoIkFNRC1WaTogTm90IG92ZXJyaWRpbmcgaXJxX3ZlY3Rvcl9t
YXAgc2V0dGluZ1xuIik7CiAgICAgfQorICAgIGlmICggIWFtZF9pb21tdV9w
ZXJkZXZfaW50cmVtYXAgKQorICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5J
TkcgIkFNRC1WaTogVXNpbmcgZ2xvYmFsIGludGVycnVwdCByZW1hcCB0YWJs
ZSBpcyBub3QgcmVjb21tZW5kZWQgKHNlZSBYU0EtMzYpIVxuIik7CiAgICAg
cmV0dXJuIHNjYW5fcGNpX2RldmljZXMoKTsKIH0KIAotLS0gYS94ZW4vZHJp
dmVycy9wYXNzdGhyb3VnaC9pb21tdS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bh
c3N0aHJvdWdoL2lvbW11LmMKQEAgLTUyLDcgKzUyLDcgQEAgYm9vbF90IF9f
cmVhZF9tb3N0bHkgaW9tbXVfcWludmFsID0gMTsKIGJvb2xfdCBfX3JlYWRf
bW9zdGx5IGlvbW11X2ludHJlbWFwID0gMTsKIGJvb2xfdCBfX3JlYWRfbW9z
dGx5IGlvbW11X2hhcF9wdF9zaGFyZSA9IDE7CiBib29sX3QgX19yZWFkX21v
c3RseSBpb21tdV9kZWJ1ZzsKLWJvb2xfdCBfX3JlYWRfbW9zdGx5IGFtZF9p
b21tdV9wZXJkZXZfaW50cmVtYXA7Citib29sX3QgX19yZWFkX21vc3RseSBh
bWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwID0gMTsKIAogREVGSU5FX1BFUl9D
UFUoYm9vbF90LCBpb21tdV9kb250X2ZsdXNoX2lvdGxiKTsKIAotLS0gYS94
ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9zdm0vYW1kLWlvbW11LXByb3RvLmgK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL2FtZC1pb21tdS1w
cm90by5oCkBAIC0xMDAsNiArMTAwLDcgQEAgdm9pZCBhbWRfaW9tbXVfcmVh
ZF9tc2lfZnJvbV9pcmUoCiAKIGV4dGVybiBzdHJ1Y3QgaW9hcGljX3NiZGYg
ewogICAgIHUxNiBiZGYsIHNlZzsKKyAgICB1bnNpZ25lZCBsb25nICpwaW5f
c2V0dXA7CiB9IGlvYXBpY19zYmRmW01BWF9JT19BUElDU107CiBleHRlcm4g
dm9pZCAqc2hhcmVkX2ludHJlbWFwX3RhYmxlOwogCg==

--=separator
Content-Type: application/octet-stream; name="xsa36-unstable.patch"
Content-Disposition: attachment; filename="xsa36-unstable.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgpBTUQg
SU9NTVU6IGFsc28gc3BvdCBtaXNzaW5nIElPLUFQSUMgZW50cmllcyBpbiBJ
VlJTIHRhYmxlCgpBcGFydCBmcm9tIGRlYWxpbmcgZHVwbGljYXRlIGNvbmZs
aWN0aW5nIGVudHJpZXMsIHdlIGFsc28gaGF2ZSB0bwpoYW5kbGUgZmlybXdh
cmUgb21pdHRpbmcgSU8tQVBJQyBlbnRyaWVzIGluIElWUlMgYWx0b2dldGhl
ci4gTm90IGRvaW5nCnNvIGhhcyByZXN1bHRlZCBpbiBjL3MgMjY1MTc6NjAx
MTM5ZTJiMGRiIHRvIGNyYXNoIHN1Y2ggc3lzdGVtcyBkdXJpbmcKYm9vdCAo
d2hlcmVhcyB3aXRoIHRoZSBjaGFuZ2UgaGVyZSB0aGUgSU9NTVUgZ2V0cyBk
aXNhYmxlZCBqdXN0IGFzIGlzCmJlaW5nIGRvbmUgaW4gdGhlIG90aGVyIGNh
c2VzLCBpLmUuIHVubGVzcyBnbG9iYWwgdGFibGVzIGFyZSBiZWluZwp1c2Vk
KS4KCkRlYnVnZ2luZyB0aGlzIGlzc3VlIGhhcyBhbHNvIHBvaW50ZWQgb3V0
IHRoYXQgdGhlIGRlYnVnIGxvZyBvdXRwdXQgaXMKcHJldHR5IHVnbHkgdG8g
bG9vayBhdCAtIGNvbnNvbGlkYXRlIHRoZSBvdXRwdXQsIGFuZCBhZGQgb25l
IGV4dHJhCml0ZW0gZm9yIHRoZSBJVkhEIHNwZWNpYWwgZW50cmllcywgc28g
dGhhdCBmdXR1cmUgaXNzdWVzIGFyZSBlYXNpZXIKdG8gYW5hbHl6ZS4KClNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
VGVzdGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5i
b29tLml0PgoKLS0tIGEveGVuL2FyY2gveDg2L2lycS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9pcnEuYwpAQCAtMTk0Myw5ICsxOTQzLDYgQEAgaW50IG1hcF9k
b21haW5fcGlycSgKICAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJmRlc2Mt
PmxvY2ssIGZsYWdzKTsKICAgICAgICAgc2V0X2RvbWFpbl9pcnFfcGlycShk
LCBpcnEsIGluZm8pOwogICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3Jl
KCZkZXNjLT5sb2NrLCBmbGFncyk7Ci0KLSAgICAgICAgaWYgKCBvcHRfaXJx
X3ZlY3Rvcl9tYXAgPT0gT1BUX0lSUV9WRUNUT1JfTUFQX1BFUkRFViApCi0g
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0lORk8gIlBlci1kZXZpY2UgdmVj
dG9yIG1hcHMgZm9yIEdTSXMgbm90IGltcGxlbWVudGVkIHlldC5cbiIpOwog
ICAgIH0KIAogZG9uZToKLS0tIGEveGVuL2RyaXZlcnMvYWNwaS90YWJsZXMu
YworKysgYi94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCkBAIC0yNjUsNyAr
MjY1LDcgQEAgYWNwaV90YWJsZV9wYXJzZV9tYWR0KGVudW0gYWNwaV9tYWR0
X3R5cAogICogQGhhbmRsZXI6IGhhbmRsZXIgdG8gcnVuCiAgKgogICogU2Nh
biB0aGUgQUNQSSBTeXN0ZW0gRGVzY3JpcHRvciBUYWJsZSAoU1REKSBmb3Ig
YSB0YWJsZSBtYXRjaGluZyBAaWQsCi0gKiBydW4gQGhhbmRsZXIgb24gaXQu
ICBSZXR1cm4gMCBpZiB0YWJsZSBmb3VuZCwgcmV0dXJuIG9uIGlmIG5vdC4K
KyAqIHJ1biBAaGFuZGxlciBvbiBpdC4KICAqLwogaW50IF9faW5pdCBhY3Bp
X3RhYmxlX3BhcnNlKGNoYXIgKmlkLCBhY3BpX3RhYmxlX2hhbmRsZXIgaGFu
ZGxlcikKIHsKQEAgLTI4MCw4ICsyODAsNyBAQCBpbnQgX19pbml0IGFjcGlf
dGFibGVfcGFyc2UoY2hhciAqaWQsIGFjCiAJCWFjcGlfZ2V0X3RhYmxlKGlk
LCAwLCAmdGFibGUpOwogCiAJaWYgKHRhYmxlKSB7Ci0JCWhhbmRsZXIodGFi
bGUpOwotCQlyZXR1cm4gMDsKKwkJcmV0dXJuIGhhbmRsZXIodGFibGUpOwog
CX0gZWxzZQogCQlyZXR1cm4gMTsKIH0KLS0tIGEveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYworKysgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jCkBAIC0yMiw2ICsyMiw3IEBA
CiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CiAjaW5jbHVkZSA8eGVuL2FjcGku
aD4KICNpbmNsdWRlIDxhc20vYXBpY2RlZi5oPgorI2luY2x1ZGUgPGFzbS9p
b19hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2FtZC1pb21tdS5oPgogI2luY2x1
ZGUgPGFzbS9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oPgogCkBAIC02Mzcs
NiArNjM4LDcgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZp
Y2Vfc3BlYwogICAgIHUxNiBoZWFkZXJfbGVuZ3RoLCB1MTYgYmxvY2tfbGVu
Z3RoLCBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkKIHsKICAgICB1MTYgZGV2
X2xlbmd0aCwgYmRmOworICAgIGludCBhcGljOwogCiAgICAgZGV2X2xlbmd0
aCA9IHNpemVvZigqc3BlY2lhbCk7CiAgICAgaWYgKCBoZWFkZXJfbGVuZ3Ro
IDwgKGJsb2NrX2xlbmd0aCArIGRldl9sZW5ndGgpICkKQEAgLTY1Nyw5ICs2
NTksNTMgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZpY2Vf
c3BlYwogICAgIHN3aXRjaCAoIHNwZWNpYWwtPnZhcmlldHkgKQogICAgIHsK
ICAgICBjYXNlIEFDUElfSVZIRF9JT0FQSUM6Ci0gICAgLyogc2V0IGRldmlj
ZSBpZCBvZiBpb2FwaWMgKi8KLSAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lh
bC0+aGFuZGxlXS5iZGYgPSBiZGY7Ci0gICAgICAgIGlvYXBpY19zYmRmW3Nw
ZWNpYWwtPmhhbmRsZV0uc2VnID0gc2VnOworICAgICAgICAvKgorICAgICAg
ICAgKiBTb21lIEJJT1NlcyBoYXZlIElPQVBJQyBicm9rZW4gZW50cmllcyBz
byB3ZSBjaGVjayBmb3IgSVZSUworICAgICAgICAgKiBjb25zaXN0ZW5jeSBo
ZXJlIC0tLSB3aGV0aGVyIGVudHJ5J3MgSU9BUElDIElEIGlzIHZhbGlkIGFu
ZAorICAgICAgICAgKiB3aGV0aGVyIHRoZXJlIGFyZSBjb25mbGljdGluZy9k
dXBsaWNhdGVkIGVudHJpZXMuCisgICAgICAgICAqLworICAgICAgICBmb3Ig
KCBhcGljID0gMDsgYXBpYyA8IG5yX2lvYXBpY3M7IGFwaWMrKyApCisgICAg
ICAgIHsKKyAgICAgICAgICAgIGlmICggSU9fQVBJQ19JRChhcGljKSAhPSBz
cGVjaWFsLT5oYW5kbGUgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVlOwor
CisgICAgICAgICAgICBpZiAoIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRs
ZV0ucGluX3NldHVwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAg
ICBpZiAoIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0uYmRmID09IGJk
ZiAmJgorICAgICAgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lh
bC0+aGFuZGxlXS5zZWcgPT0gc2VnICkKKyAgICAgICAgICAgICAgICAgICAg
QU1EX0lPTU1VX0RFQlVHKCJJVkhEIFdhcm5pbmc6IER1cGxpY2F0ZSBJTy1B
UElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3BlY2lhbC0+aGFuZGxlKTsKKyAgICAgICAgICAgICAg
ICBlbHNlCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogQ29uZmxpY3Rpbmcg
SU8tQVBJQyAlI3ggZW50cmllc1xuIiwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHNwZWNpYWwtPmhhbmRsZSk7CisgICAgICAgICAgICAgICAgICAg
IGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCApCisgICAgICAgICAg
ICAgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgICAgICAgICB9Cisg
ICAgICAgICAgICB9CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICB7
CisgICAgICAgICAgICAgICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMg
Ki8KKyAgICAgICAgICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5k
bGVdLmJkZiA9IGJkZjsKKyAgICAgICAgICAgICAgICBpb2FwaWNfc2JkZltz
cGVjaWFsLT5oYW5kbGVdLnNlZyA9IHNlZzsKKworICAgICAgICAgICAgICAg
IGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0ucGluX3NldHVwID0geHph
bGxvY19hcnJheSgKKyAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9u
ZywgQklUU19UT19MT05HUyhucl9pb2FwaWNfZW50cmllc1thcGljXSkpOwor
ICAgICAgICAgICAgICAgIGlmICggbnJfaW9hcGljX2VudHJpZXNbYXBpY10g
JiYKKyAgICAgICAgICAgICAgICAgICAgICFpb2FwaWNfc2JkZltJT19BUElD
X0lEKGFwaWMpXS5waW5fc2V0dXAgKQorICAgICAgICAgICAgICAgIHsKKyAg
ICAgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIklWSEQgRXJy
b3I6IE91dCBvZiBtZW1vcnlcbiIpOworICAgICAgICAgICAgICAgICAgICBy
ZXR1cm4gMDsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICB9Cisg
ICAgICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgICAgICBpZiAoIGFw
aWMgPT0gbnJfaW9hcGljcyApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBJbnZhbGlkIElPLUFQSUMg
JSN4XG4iLAorICAgICAgICAgICAgICAgICAgIHNwZWNpYWwtPmhhbmRsZSk7
CisgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgfQogICAgICAgICBi
cmVhazsKICAgICBjYXNlIEFDUElfSVZIRF9IUEVUOgogICAgICAgICAvKiBz
ZXQgZGV2aWNlIGlkIG9mIGhwZXQgKi8KQEAgLTg0NCw2ICs4OTAsNyBAQCBz
dGF0aWMgaW50IF9faW5pdCBwYXJzZV9pdnJzX3RhYmxlKHN0cnVjCiB7CiAg
ICAgY29uc3Qgc3RydWN0IGFjcGlfaXZyc19oZWFkZXIgKml2cnNfYmxvY2s7
CiAgICAgdW5zaWduZWQgbG9uZyBsZW5ndGg7CisgICAgdW5zaWduZWQgaW50
IGFwaWM7CiAgICAgaW50IGVycm9yID0gMDsKIAogICAgIEJVR19PTighdGFi
bGUpOwpAQCAtODc2LDYgKzkyMywyOSBAQCBzdGF0aWMgaW50IF9faW5pdCBw
YXJzZV9pdnJzX3RhYmxlKHN0cnVjCiAgICAgICAgIGxlbmd0aCArPSBpdnJz
X2Jsb2NrLT5sZW5ndGg7CiAgICAgfQogCisgICAgLyogRWFjaCBJTy1BUElD
IG11c3QgaGF2ZSBiZWVuIG1lbnRpb25lZCBpbiB0aGUgdGFibGUuICovCisg
ICAgZm9yICggYXBpYyA9IDA7ICFlcnJvciAmJiBhcGljIDwgbnJfaW9hcGlj
czsgKythcGljICkKKyAgICB7CisgICAgICAgIGlmICggIW5yX2lvYXBpY19l
bnRyaWVzW2FwaWNdIHx8CisgICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9f
QVBJQ19JRChhcGljKV0ucGluX3NldHVwICkKKyAgICAgICAgICAgIGNvbnRp
bnVlOworCisgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9y
OiBubyBpbmZvcm1hdGlvbiBmb3IgSU8tQVBJQyAlI3hcbiIsCisgICAgICAg
ICAgICAgICBJT19BUElDX0lEKGFwaWMpKTsKKyAgICAgICAgaWYgKCBhbWRf
aW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgICAgIGVycm9yID0g
LUVOWElPOworICAgICAgICBlbHNlCisgICAgICAgIHsKKyAgICAgICAgICAg
IGlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCA9IHh6
YWxsb2NfYXJyYXkoCisgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZywg
QklUU19UT19MT05HUyhucl9pb2FwaWNfZW50cmllc1thcGljXSkpOworICAg
ICAgICAgICAgaWYgKCAhaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0u
cGluX3NldHVwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBw
cmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogT3V0IG9mIG1lbW9yeVxu
Iik7CisgICAgICAgICAgICAgICAgZXJyb3IgPSAtRU5PTUVNOworICAgICAg
ICAgICAgfQorICAgICAgICB9CisgICAgfQorCiAgICAgcmV0dXJuIGVycm9y
OwogfQogCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9pbml0LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lv
bW11X2luaXQuYwpAQCAtMTEyMCwxMiArMTEyMCw0NSBAQCBzdGF0aWMgaW50
IF9faW5pdCBhbWRfaW9tbXVfc2V0dXBfZGV2aWNlCiAgICAgcmV0dXJuIDA7
CiB9CiAKKy8qIENoZWNrIHdoZXRoZXIgU1A1MTAwIFNBVEEgQ29tYmluZWQg
bW9kZSBpcyBvbiAqLworc3RhdGljIGJvb2xfdCBfX2luaXQgYW1kX3NwNTEw
MF9lcnJhdHVtMjgodm9pZCkKK3sKKyAgICB1MzIgYnVzLCBpZDsKKyAgICB1
MTYgdmVuZG9yX2lkLCBkZXZfaWQ7CisgICAgdTggYnl0ZTsKKworICAgIGZv
ciAoYnVzID0gMDsgYnVzIDwgMjU2OyBidXMrKykKKyAgICB7CisgICAgICAg
IGlkID0gcGNpX2NvbmZfcmVhZDMyKDAsIGJ1cywgMHgxNCwgMCwgUENJX1ZF
TkRPUl9JRCk7CisKKyAgICAgICAgdmVuZG9yX2lkID0gaWQgJiAweGZmZmY7
CisgICAgICAgIGRldl9pZCA9IChpZCA+PiAxNikgJiAweGZmZmY7CisKKyAg
ICAgICAgLyogU1A1MTAwIFNNQnVzIG1vZHVsZSBzZXRzIENvbWJpbmVkIG1v
ZGUgb24gKi8KKyAgICAgICAgaWYgKHZlbmRvcl9pZCAhPSAweDEwMDIgfHwg
ZGV2X2lkICE9IDB4NDM4NSkKKyAgICAgICAgICAgIGNvbnRpbnVlOworCisg
ICAgICAgIGJ5dGUgPSBwY2lfY29uZl9yZWFkOCgwLCBidXMsIDB4MTQsIDAs
IDB4YWQpOworICAgICAgICBpZiAoIChieXRlID4+IDMpICYgMSApCisgICAg
ICAgIHsKKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiQU1E
LVZpOiBTUDUxMDAgZXJyYXR1bSAyOCBkZXRlY3RlZCwgZGlzYWJsaW5nIElP
TU1VLlxuIgorICAgICAgICAgICAgICAgICAgICJJZiBwb3NzaWJsZSwgZGlz
YWJsZSBTQVRBIENvbWJpbmVkIG1vZGUgaW4gQklPUyBvciBjb250YWN0IHlv
dXIgdmVuZG9yIGZvciBCSU9TIHVwZGF0ZS5cbiIpOworICAgICAgICAgICAg
cmV0dXJuIDE7CisgICAgICAgIH0KKyAgICB9CisKKyAgICByZXR1cm4gMDsK
K30KKwogaW50IF9faW5pdCBhbWRfaW9tbXVfaW5pdCh2b2lkKQogewogICAg
IHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11OwogCiAgICAgQlVHX09OKCAhaW9t
bXVfZm91bmQoKSApOwogCisgICAgaWYgKCBhbWRfaW9tbXVfcGVyZGV2X2lu
dHJlbWFwICYmIGFtZF9zcDUxMDBfZXJyYXR1bTI4KCkgKQorICAgICAgICBn
b3RvIGVycm9yX291dDsKKwogICAgIGl2cnNfYmRmX2VudHJpZXMgPSBhbWRf
aW9tbXVfZ2V0X2l2cnNfZGV2X2VudHJpZXMoKTsKIAogICAgIGlmICggIWl2
cnNfYmRmX2VudHJpZXMgKQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3Vn
aC9hbWQvaW9tbXVfaW50ci5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL2FtZC9pb21tdV9pbnRyLmMKQEAgLTEwMCwxMiArMTAwLDEyIEBAIHN0
YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeSh1MzIqIGUKIHN0YXRp
YyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lvYXBpYygKICAg
ICBpbnQgYmRmLAogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11LAotICAg
IHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICppb2FwaWNfcnRlKQorICAg
IGNvbnN0IHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICpydGUsCisgICAg
Y29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKm9sZF9ydGUpCiB7
CiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsKICAgICB1MzIqIGVudHJ5Owog
ICAgIHU4IGRlbGl2ZXJ5X21vZGUsIGRlc3QsIHZlY3RvciwgZGVzdF9tb2Rl
OwotICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICpydGUgPSBpb2Fw
aWNfcnRlOwogICAgIGludCByZXFfaWQ7CiAgICAgc3BpbmxvY2tfdCAqbG9j
azsKICAgICBpbnQgb2Zmc2V0OwpAQCAtMTIxLDYgKzEyMSwxNCBAQCBzdGF0
aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9pCiAgICAgc3Bp
bl9sb2NrX2lycXNhdmUobG9jaywgZmxhZ3MpOwogCiAgICAgb2Zmc2V0ID0g
Z2V0X2ludHJlbWFwX29mZnNldCh2ZWN0b3IsIGRlbGl2ZXJ5X21vZGUpOwor
ICAgIGlmICggb2xkX3J0ZSApCisgICAgeworICAgICAgICBpbnQgb2xkX29m
ZnNldCA9IGdldF9pbnRyZW1hcF9vZmZzZXQob2xkX3J0ZS0+dmVjdG9yLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
b2xkX3J0ZS0+ZGVsaXZlcnlfbW9kZSk7CisKKyAgICAgICAgaWYgKCBvZmZz
ZXQgIT0gb2xkX29mZnNldCApCisgICAgICAgICAgICBmcmVlX2ludHJlbWFw
X2VudHJ5KGlvbW11LT5zZWcsIGJkZiwgb2xkX29mZnNldCk7CisgICAgfQog
ICAgIGVudHJ5ID0gKHUzMiopZ2V0X2ludHJlbWFwX2VudHJ5KGlvbW11LT5z
ZWcsIHJlcV9pZCwgb2Zmc2V0KTsKICAgICB1cGRhdGVfaW50cmVtYXBfZW50
cnkoZW50cnksIHZlY3RvciwgZGVsaXZlcnlfbW9kZSwgZGVzdF9tb2RlLCBk
ZXN0KTsKIApAQCAtMTg5LDYgKzE5Nyw3IEBAIGludCBfX2luaXQgYW1kX2lv
bW11X3NldHVwX2lvYXBpY19yZW1hcHAKICAgICAgICAgICAgICAgICBhbWRf
aW9tbXVfZmx1c2hfaW50cmVtYXAoaW9tbXUsIHJlcV9pZCk7CiAgICAgICAg
ICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ss
IGZsYWdzKTsKICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIHNldF9iaXQo
cGluLCBpb2FwaWNfc2JkZltJT19BUElDX0lEKGFwaWMpXS5waW5fc2V0dXAp
OwogICAgICAgICB9CiAgICAgfQogICAgIHJldHVybiAwOwpAQCAtMjAwLDYg
KzIwOSw3IEBAIHZvaWQgYW1kX2lvbW11X2lvYXBpY191cGRhdGVfaXJlKAog
ICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5IG9sZF9ydGUgPSB7IDAg
fTsKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSBuZXdfcnRlID0g
eyAwIH07CiAgICAgdW5zaWduZWQgaW50IHJ0ZV9sbyA9IChyZWcgJiAxKSA/
IHJlZyAtIDEgOiByZWc7CisgICAgdW5zaWduZWQgaW50IHBpbiA9IChyZWcg
LSAweDEwKSAvIDI7CiAgICAgaW50IHNhdmVkX21hc2ssIHNlZywgYmRmOwog
ICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11OwogCkBAIC0yMzcsNiArMjQ3
LDE0IEBAIHZvaWQgYW1kX2lvbW11X2lvYXBpY191cGRhdGVfaXJlKAogICAg
ICAgICAqKCgodTMyICopJm5ld19ydGUpICsgMSkgPSB2YWx1ZTsKICAgICB9
CiAKKyAgICBpZiAoIG5ld19ydGUubWFzayAmJgorICAgICAgICAgIXRlc3Rf
Yml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3Nl
dHVwKSApCisgICAgeworICAgICAgICBBU1NFUlQoc2F2ZWRfbWFzayk7Cisg
ICAgICAgIF9faW9fYXBpY193cml0ZShhcGljLCByZWcsIHZhbHVlKTsKKyAg
ICAgICAgcmV0dXJuOworICAgIH0KKwogICAgIC8qIG1hc2sgdGhlIGludGVy
cnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGludHJlbWFwIHRhYmxlICovCiAg
ICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAgewpAQCAtMjQ1LDcgKzI2Mywx
MSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2lyZSgKICAgICB9
CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0IHJlbWFwcGluZyBlbnRyeSAq
LwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lvYXBpYyhiZGYs
IGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5
X2Zyb21faW9hcGljKAorICAgICAgICBiZGYsIGlvbW11LCAmbmV3X3J0ZSwK
KyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChwaW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0ucGlu
X3NldHVwKSA/ICZvbGRfcnRlCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IE5V
TEwpOwogCiAgICAgLyogRm9yd2FyZCB3cml0ZSBhY2Nlc3MgdG8gSU8tQVBJ
QyBSVEUgKi8KICAgICBfX2lvX2FwaWNfd3JpdGUoYXBpYywgcmVnLCB2YWx1
ZSk7CkBAIC0zNTYsNiArMzc4LDEyIEBAIHZvaWQgYW1kX2lvbW11X21zaV9t
c2dfdXBkYXRlX2lyZSgKICAgICAgICAgcmV0dXJuOwogICAgIH0KIAorICAg
IGlmICggbXNpX2Rlc2MtPnJlbWFwX2luZGV4ID49IDAgKQorICAgICAgICB1
cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9tc2lfbXNnKGlvbW11LCBiZGYs
IG1zaV9kZXNjLCBOVUxMKTsKKworICAgIGlmICggIW1zZyApCisgICAgICAg
IHJldHVybjsKKwogICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX21z
aV9tc2coaW9tbXUsIGJkZiwgbXNpX2Rlc2MsIG1zZyk7CiB9CiAKLS0tIGEv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRfaW9tbXUuYwor
KysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvcGNpX2FtZF9pb21t
dS5jCkBAIC0yMDgsNiArMjA4LDggQEAgaW50IF9faW5pdCBhbWRfaW92X2Rl
dGVjdCh2b2lkKQogICAgIHsKICAgICAgICAgcHJpbnRrKCJBTUQtVmk6IE5v
dCBvdmVycmlkaW5nIGlycV92ZWN0b3JfbWFwIHNldHRpbmdcbiIpOwogICAg
IH0KKyAgICBpZiAoICFhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAg
ICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJBTUQtVmk6IFVzaW5nIGds
b2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUgaXMgbm90IHJlY29tbWVuZGVk
IChzZWUgWFNBLTM2KSFcbiIpOwogICAgIHJldHVybiBzY2FuX3BjaV9kZXZp
Y2VzKCk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9t
bXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9pb21tdS5jCkBA
IC01Myw3ICs1Myw3IEBAIGJvb2xfdCBfX3JlYWRfbW9zdGx5IGlvbW11X3Fp
bnZhbCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21tdV9pbnRyZW1h
cCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21tdV9oYXBfcHRfc2hh
cmUgPSAxOwogYm9vbF90IF9fcmVhZF9tb3N0bHkgaW9tbXVfZGVidWc7Ci1i
b29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFw
OworYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lvbW11X3BlcmRldl9pbnRy
ZW1hcCA9IDE7CiAKIERFRklORV9QRVJfQ1BVKGJvb2xfdCwgaW9tbXVfZG9u
dF9mbHVzaF9pb3RsYik7CiAKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9o
dm0vc3ZtL2FtZC1pb21tdS1wcm90by5oCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS14ODYvaHZtL3N2bS9hbWQtaW9tbXUtcHJvdG8uaApAQCAtMTAxLDYgKzEw
MSw3IEBAIGludCBhbWRfc2V0dXBfaHBldF9tc2koc3RydWN0IG1zaV9kZXNj
ICoKIAogZXh0ZXJuIHN0cnVjdCBpb2FwaWNfc2JkZiB7CiAgICAgdTE2IGJk
Ziwgc2VnOworICAgIHVuc2lnbmVkIGxvbmcgKnBpbl9zZXR1cDsKIH0gaW9h
cGljX3NiZGZbTUFYX0lPX0FQSUNTXTsKIGV4dGVybiB2b2lkICpzaGFyZWRf
aW50cmVtYXBfdGFibGU7CiAK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Feb 21 14:24:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:24: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 1U8X3u-00042y-DX; Thu, 21 Feb 2013 14:23:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U8X3s-00042E-6w; Thu, 21 Feb 2013 14:23:48 +0000
Received: from [85.158.139.211:17022] by server-3.bemta-5.messagelabs.com id
	9E/AD-07037-3FD26215; Thu, 21 Feb 2013 14:23:47 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361456621!18549606!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30770 invoked from network); 21 Feb 2013 14:23:42 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-14.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Feb 2013 14:23:42 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U8X3c-000207-Ah; Thu, 21 Feb 2013 14:23:32 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1U8X3b-0007ni-Cw; Thu, 21 Feb 2013 14:23:31 +0000
Date: Thu, 21 Feb 2013 14:23:31 +0000
Message-Id: <E1U8X3b-0007ni-Cw@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 36 (CVE-2013-0153) - interrupt
 remap entries shared and old ones not cleared on AMD IOMMUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2013-0153 / XSA-36
			      version 4

  interrupt remap entries shared and old ones not cleared on AMD IOMMUs

UPDATES IN VERSION 4
====================

Updated patches, to deal with a boot time crash resulting from the earlier
changes on systems with firmware broken in a way not previously accounted
for.

ISSUE DESCRIPTION
=================

To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system.  This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.

Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.

In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.

IMPACT
======

A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.

VULNERABLE SYSTEMS
==================

Xen versions 3.3 onwards are vulnerable.  Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.

Only systems using AMD-Vi for PCI passthrough are vulnerable.

Any domain which is given access to a PCI device can take advantage of
this vulnerability.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted
guests.

In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor.  This option is not fully functional on earlier
hypervisors.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore.  This should be dealt with by a BIOS
update, if available.  Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.

xsa36-unstable.patch              Xen unstable
xsa36-4.2.patch                   Xen 4.2.x
xsa36-4.1.patch                   Xen 4.1.x

$ sha256sum xsa36*.patch
4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0efc6f4  xsa36-4.1.patch
dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc21204067c4eb8964  xsa36-4.2.patch
7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c440e2992a7b5cfe41  xsa36-unstable.patch
$

Incremental patches on top of what was provided in version 3 can also be
taken from the respective mercurial trees:

http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739
http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOencxa9R3TGTn
20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltzcnd
6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/
PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A
zRNADG36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP
ICpJJFf0w7oW6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=
=vmpB
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa36-4.1.patch"
Content-Disposition: attachment; filename="xsa36-4.1.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgpBTUQg
SU9NTVU6IGFsc28gc3BvdCBtaXNzaW5nIElPLUFQSUMgZW50cmllcyBpbiBJ
VlJTIHRhYmxlCgpBcGFydCBmcm9tIGRlYWxpbmcgZHVwbGljYXRlIGNvbmZs
aWN0aW5nIGVudHJpZXMsIHdlIGFsc28gaGF2ZSB0bwpoYW5kbGUgZmlybXdh
cmUgb21pdHRpbmcgSU8tQVBJQyBlbnRyaWVzIGluIElWUlMgYWx0b2dldGhl
ci4gTm90IGRvaW5nCnNvIGhhcyByZXN1bHRlZCBpbiBjL3MgMjY1MTc6NjAx
MTM5ZTJiMGRiIHRvIGNyYXNoIHN1Y2ggc3lzdGVtcyBkdXJpbmcKYm9vdCAo
d2hlcmVhcyB3aXRoIHRoZSBjaGFuZ2UgaGVyZSB0aGUgSU9NTVUgZ2V0cyBk
aXNhYmxlZCBqdXN0IGFzIGlzCmJlaW5nIGRvbmUgaW4gdGhlIG90aGVyIGNh
c2VzLCBpLmUuIHVubGVzcyBnbG9iYWwgdGFibGVzIGFyZSBiZWluZwp1c2Vk
KS4KCkRlYnVnZ2luZyB0aGlzIGlzc3VlIGhhcyBhbHNvIHBvaW50ZWQgb3V0
IHRoYXQgdGhlIGRlYnVnIGxvZyBvdXRwdXQgaXMKcHJldHR5IHVnbHkgdG8g
bG9vayBhdCAtIGNvbnNvbGlkYXRlIHRoZSBvdXRwdXQsIGFuZCBhZGQgb25l
IGV4dHJhCml0ZW0gZm9yIHRoZSBJVkhEIHNwZWNpYWwgZW50cmllcywgc28g
dGhhdCBmdXR1cmUgaXNzdWVzIGFyZSBlYXNpZXIKdG8gYW5hbHl6ZS4KClNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
VGVzdGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5i
b29tLml0PgoKLS0tIGEveGVuL2FyY2gveDg2L2lycS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9pcnEuYwpAQCAtMTY3Nyw5ICsxNjc3LDYgQEAgaW50IG1hcF9k
b21haW5fcGlycSgKICAgICAgICAgZC0+YXJjaC5waXJxX2lycVtwaXJxXSA9
IGlycTsKICAgICAgICAgZC0+YXJjaC5pcnFfcGlycVtpcnFdID0gcGlycTsK
ICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZGVzYy0+bG9jaywg
ZmxhZ3MpOwotCi0gICAgICAgIGlmICggb3B0X2lycV92ZWN0b3JfbWFwID09
IE9QVF9JUlFfVkVDVE9SX01BUF9QRVJERVYgKQotICAgICAgICAgICAgcHJp
bnRrKFhFTkxPR19JTkZPICJQZXItZGV2aWNlIHZlY3RvciBtYXBzIGZvciBH
U0lzIG5vdCBpbXBsZW1lbnRlZCB5ZXQuXG4iKTsKICAgICB9CiAKIGRvbmU6
Ci0tLSBhL3hlbi9kcml2ZXJzL2FjcGkvdGFibGVzLmMKKysrIGIveGVuL2Ry
aXZlcnMvYWNwaS90YWJsZXMuYwpAQCAtMjY3LDcgKzI2Nyw3IEBAIGFjcGlf
dGFibGVfcGFyc2VfbWFkdChlbnVtIGFjcGlfbWFkdF90eXAKICAqIEBoYW5k
bGVyOiBoYW5kbGVyIHRvIHJ1bgogICoKICAqIFNjYW4gdGhlIEFDUEkgU3lz
dGVtIERlc2NyaXB0b3IgVGFibGUgKFNURCkgZm9yIGEgdGFibGUgbWF0Y2hp
bmcgQGlkLAotICogcnVuIEBoYW5kbGVyIG9uIGl0LiAgUmV0dXJuIDAgaWYg
dGFibGUgZm91bmQsIHJldHVybiBvbiBpZiBub3QuCisgKiBydW4gQGhhbmRs
ZXIgb24gaXQuCiAgKi8KIGludCBhY3BpX3RhYmxlX3BhcnNlKGNoYXIgKmlk
LCBhY3BpX3RhYmxlX2hhbmRsZXIgaGFuZGxlcikKIHsKQEAgLTI4Miw4ICsy
ODIsNyBAQCBpbnQgYWNwaV90YWJsZV9wYXJzZShjaGFyICppZCwgYWNwaV90
YWJsCiAJCWFjcGlfZ2V0X3RhYmxlKGlkLCAwLCAmdGFibGUpOwogCiAJaWYg
KHRhYmxlKSB7Ci0JCWhhbmRsZXIodGFibGUpOwotCQlyZXR1cm4gMDsKKwkJ
cmV0dXJuIGhhbmRsZXIodGFibGUpOwogCX0gZWxzZQogCQlyZXR1cm4gMTsK
IH0KLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2Fj
cGkuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVf
YWNwaS5jCkBAIC0yMSw2ICsyMSw3IEBACiAjaW5jbHVkZSA8eGVuL2NvbmZp
Zy5oPgogI2luY2x1ZGUgPHhlbi9lcnJuby5oPgogI2luY2x1ZGUgPGFzbS9h
cGljZGVmLmg+CisjaW5jbHVkZSA8YXNtL2lvX2FwaWMuaD4KICNpbmNsdWRl
IDxhc20vYW1kLWlvbW11Lmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9zdm0vYW1k
LWlvbW11LXByb3RvLmg+CiAjaW5jbHVkZSA8YXNtL2h2bS9zdm0vYW1kLWlv
bW11LWFjcGkuaD4KQEAgLTI5LDcgKzMwLDYgQEAgZXh0ZXJuIHVuc2lnbmVk
IGxvbmcgYW1kX2lvbW11X3BhZ2VfZW50cgogZXh0ZXJuIHVuc2lnbmVkIHNo
b3J0IGl2cnNfYmRmX2VudHJpZXM7CiBleHRlcm4gc3RydWN0IGl2cnNfbWFw
cGluZ3MgKml2cnNfbWFwcGluZ3M7CiBleHRlcm4gdW5zaWduZWQgc2hvcnQg
bGFzdF9iZGY7Ci1leHRlcm4gaW50IGlvYXBpY19iZGZbTUFYX0lPX0FQSUNT
XTsKIGV4dGVybiB2b2lkICpzaGFyZWRfaW50cmVtYXBfdGFibGU7CiAKIHN0
YXRpYyB2b2lkIGFkZF9pdnJzX21hcHBpbmdfZW50cnkoCkBAIC02MzYsNiAr
NjM2LDcgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZpY2Vf
c3BlYwogICAgIHUxNiBoZWFkZXJfbGVuZ3RoLCB1MTYgYmxvY2tfbGVuZ3Ro
LCBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkKIHsKICAgICB1MTYgZGV2X2xl
bmd0aCwgYmRmOworICAgIGludCBhcGljOwogCiAgICAgZGV2X2xlbmd0aCA9
IHNpemVvZihzdHJ1Y3QgYWNwaV9pdmhkX2RldmljZV9zcGVjaWFsKTsKICAg
ICBpZiAoIGhlYWRlcl9sZW5ndGggPCAoYmxvY2tfbGVuZ3RoICsgZGV2X2xl
bmd0aCkgKQpAQCAtNjUyLDkgKzY1Myw1OCBAQCBzdGF0aWMgdTE2IF9faW5p
dCBwYXJzZV9pdmhkX2RldmljZV9zcGVjCiAgICAgfQogCiAgICAgYWRkX2l2
cnNfbWFwcGluZ19lbnRyeShiZGYsIGJkZiwgaXZoZF9kZXZpY2UtPmhlYWRl
ci5mbGFncywgaW9tbXUpOwotICAgIC8qIHNldCBkZXZpY2UgaWQgb2YgaW9h
cGljICovCi0gICAgaW9hcGljX2JkZltpdmhkX2RldmljZS0+c3BlY2lhbC5o
YW5kbGVdID0gYmRmOwotICAgIHJldHVybiBkZXZfbGVuZ3RoOworCisgICAg
aWYgKCBpdmhkX2RldmljZS0+c3BlY2lhbC52YXJpZXR5ICE9IDEgLyogQUNQ
SV9JVkhEX0lPQVBJQyAqLyApCisgICAgeworICAgICAgICBpZiAoIGl2aGRf
ZGV2aWNlLT5zcGVjaWFsLnZhcmlldHkgIT0gMiAvKiBBQ1BJX0lWSERfSFBF
VCAqLyApCisgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiVW5yZWNv
Z25pemVkIElWSEQgc3BlY2lhbCB2YXJpZXR5ICUjeFxuIiwKKyAgICAgICAg
ICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lhbC52YXJpZXR5KTsKKyAg
ICAgICAgcmV0dXJuIGRldl9sZW5ndGg7CisgICAgfQorCisgICAgLyoKKyAg
ICAgKiBTb21lIEJJT1NlcyBoYXZlIElPQVBJQyBicm9rZW4gZW50cmllcyBz
byB3ZSBjaGVjayBmb3IgSVZSUworICAgICAqIGNvbnNpc3RlbmN5IGhlcmUg
LS0tIHdoZXRoZXIgZW50cnkncyBJT0FQSUMgSUQgaXMgdmFsaWQgYW5kCisg
ICAgICogd2hldGhlciB0aGVyZSBhcmUgY29uZmxpY3RpbmcvZHVwbGljYXRl
ZCBlbnRyaWVzLgorICAgICAqLworICAgIGZvciAoIGFwaWMgPSAwOyBhcGlj
IDwgbnJfaW9hcGljczsgYXBpYysrICkKKyAgICB7CisgICAgICAgIGlmICgg
SU9fQVBJQ19JRChhcGljKSAhPSBpdmhkX2RldmljZS0+c3BlY2lhbC5oYW5k
bGUgKQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgaWYgKCBp
b2FwaWNfYmRmW2l2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZV0ucGluX3Nl
dHVwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCBpb2FwaWNfYmRm
W2l2aGRfZGV2aWNlLT5zcGVjaWFsLmhhbmRsZV0uYmRmID09IGJkZiApCisg
ICAgICAgICAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJJVkhEIFdhcm5pbmc6
IER1cGxpY2F0ZSBJTy1BUElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lhbC5o
YW5kbGUpOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBD
b25mbGljdGluZyBJTy1BUElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAg
ICAgICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lhbC5oYW5kbGUpOwor
ICAgICAgICAgICAgICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRyZW1h
cCApCisgICAgICAgICAgICAgICAgICAgIHJldHVybiAwOworICAgICAgICAg
ICAgfQorICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgeworICAg
ICAgICAgICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMgKi8KKyAgICAg
ICAgICAgIGlvYXBpY19iZGZbaXZoZF9kZXZpY2UtPnNwZWNpYWwuaGFuZGxl
XS5iZGYgPSBiZGY7CisKKyAgICAgICAgICAgIGlvYXBpY19iZGZbaXZoZF9k
ZXZpY2UtPnNwZWNpYWwuaGFuZGxlXS5waW5fc2V0dXAgPSB4emFsbG9jX2Fy
cmF5KAorICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcsIEJJVFNfVE9f
TE9OR1MobnJfaW9hcGljX3JlZ2lzdGVyc1thcGljXSkpOworICAgICAgICAg
ICAgaWYgKCBucl9pb2FwaWNfcmVnaXN0ZXJzW2FwaWNdICYmCisgICAgICAg
ICAgICAgICAgICFpb2FwaWNfYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9z
ZXR1cCApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgcHJpbnRr
KFhFTkxPR19FUlIgIklWSEQgRXJyb3I6IE91dCBvZiBtZW1vcnlcbiIpOwor
ICAgICAgICAgICAgICAgIHJldHVybiAwOworICAgICAgICAgICAgfQorICAg
ICAgICB9CisgICAgICAgIHJldHVybiBkZXZfbGVuZ3RoOworICAgIH0KKwor
ICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBJbnZhbGlkIElP
LUFQSUMgJSN4XG4iLAorICAgICAgICAgICBpdmhkX2RldmljZS0+c3BlY2lh
bC5oYW5kbGUpOworICAgIHJldHVybiAwOwogfQogCiBzdGF0aWMgaW50IF9f
aW5pdCBwYXJzZV9pdmhkX2Jsb2NrKHN0cnVjdCBhY3BpX2l2aGRfYmxvY2tf
aGVhZGVyICppdmhkX2Jsb2NrKQpAQCAtODE3LDYgKzg2Nyw3IEBAIHN0YXRp
YyBpbnQgX19pbml0IHBhcnNlX2l2cnNfdGFibGUoc3RydWMKIHsKICAgICBz
dHJ1Y3QgYWNwaV9pdnJzX2Jsb2NrX2hlYWRlciAqaXZyc19ibG9jazsKICAg
ICB1bnNpZ25lZCBsb25nIGxlbmd0aDsKKyAgICB1bnNpZ25lZCBpbnQgYXBp
YzsKICAgICBpbnQgZXJyb3IgPSAwOwogICAgIHN0cnVjdCBhY3BpX3RhYmxl
X2hlYWRlciAqdGFibGUgPSAoc3RydWN0IGFjcGlfdGFibGVfaGVhZGVyICop
X3RhYmxlOwogCkBAIC04NTEsNiArOTAyLDI5IEBAIHN0YXRpYyBpbnQgX19p
bml0IHBhcnNlX2l2cnNfdGFibGUoc3RydWMKICAgICAgICAgbGVuZ3RoICs9
IGl2cnNfYmxvY2stPmxlbmd0aDsKICAgICB9CiAKKyAgICAvKiBFYWNoIElP
LUFQSUMgbXVzdCBoYXZlIGJlZW4gbWVudGlvbmVkIGluIHRoZSB0YWJsZS4g
Ki8KKyAgICBmb3IgKCBhcGljID0gMDsgIWVycm9yICYmIGFwaWMgPCBucl9p
b2FwaWNzOyArK2FwaWMgKQorICAgIHsKKyAgICAgICAgaWYgKCAhbnJfaW9h
cGljX3JlZ2lzdGVyc1thcGljXSB8fAorICAgICAgICAgICAgIGlvYXBpY19i
ZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3NldHVwICkKKyAgICAgICAgICAg
IGNvbnRpbnVlOworCisgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhE
IEVycm9yOiBubyBpbmZvcm1hdGlvbiBmb3IgSU8tQVBJQyAlI3hcbiIsCisg
ICAgICAgICAgICAgICBJT19BUElDX0lEKGFwaWMpKTsKKyAgICAgICAgaWYg
KCBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgICAgIGVy
cm9yID0gLUVOWElPOworICAgICAgICBlbHNlCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlvYXBpY19iZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3NldHVw
ID0geHphbGxvY19hcnJheSgKKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBs
b25nLCBCSVRTX1RPX0xPTkdTKG5yX2lvYXBpY19yZWdpc3RlcnNbYXBpY10p
KTsKKyAgICAgICAgICAgIGlmICggIWlvYXBpY19iZGZbSU9fQVBJQ19JRChh
cGljKV0ucGluX3NldHVwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogT3V0IG9mIG1l
bW9yeVxuIik7CisgICAgICAgICAgICAgICAgZXJyb3IgPSAtRU5PTUVNOwor
ICAgICAgICAgICAgfQorICAgICAgICB9CisgICAgfQorCiAgICAgcmV0dXJu
IGVycm9yOwogfQogCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9pbml0LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gv
YW1kL2lvbW11X2luaXQuYwpAQCAtODk3LDEyICs4OTcsNDUgQEAgc3RhdGlj
IGludCBfX2luaXQgYW1kX2lvbW11X3NldHVwX2RldmljZQogICAgIHJldHVy
biAwOwogfQogCisvKiBDaGVjayB3aGV0aGVyIFNQNTEwMCBTQVRBIENvbWJp
bmVkIG1vZGUgaXMgb24gKi8KK3N0YXRpYyBib29sX3QgX19pbml0IGFtZF9z
cDUxMDBfZXJyYXR1bTI4KHZvaWQpCit7CisgICAgdTMyIGJ1cywgaWQ7Cisg
ICAgdTE2IHZlbmRvcl9pZCwgZGV2X2lkOworICAgIHU4IGJ5dGU7CisKKyAg
ICBmb3IgKGJ1cyA9IDA7IGJ1cyA8IDI1NjsgYnVzKyspCisgICAgeworICAg
ICAgICBpZCA9IHBjaV9jb25mX3JlYWQzMihidXMsIDB4MTQsIDAsIFBDSV9W
RU5ET1JfSUQpOworCisgICAgICAgIHZlbmRvcl9pZCA9IGlkICYgMHhmZmZm
OworICAgICAgICBkZXZfaWQgPSAoaWQgPj4gMTYpICYgMHhmZmZmOworCisg
ICAgICAgIC8qIFNQNTEwMCBTTUJ1cyBtb2R1bGUgc2V0cyBDb21iaW5lZCBt
b2RlIG9uICovCisgICAgICAgIGlmICh2ZW5kb3JfaWQgIT0gMHgxMDAyIHx8
IGRldl9pZCAhPSAweDQzODUpCisgICAgICAgICAgICBjb250aW51ZTsKKwor
ICAgICAgICBieXRlID0gcGNpX2NvbmZfcmVhZDgoYnVzLCAweDE0LCAwLCAw
eGFkKTsKKyAgICAgICAgaWYgKCAoYnl0ZSA+PiAzKSAmIDEgKQorICAgICAg
ICB7CisgICAgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIkFNRC1W
aTogU1A1MTAwIGVycmF0dW0gMjggZGV0ZWN0ZWQsIGRpc2FibGluZyBJT01N
VS5cbiIKKyAgICAgICAgICAgICAgICAgICAiSWYgcG9zc2libGUsIGRpc2Fi
bGUgU0FUQSBDb21iaW5lZCBtb2RlIGluIEJJT1Mgb3IgY29udGFjdCB5b3Vy
IHZlbmRvciBmb3IgQklPUyB1cGRhdGUuXG4iKTsKKyAgICAgICAgICAgIHJl
dHVybiAxOworICAgICAgICB9CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9
CisKIGludCBfX2luaXQgYW1kX2lvbW11X2luaXQodm9pZCkKIHsKICAgICBz
dHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIAogICAgIEJVR19PTiggIWlvbW11
X2ZvdW5kKCkgKTsKIAorICAgIGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRy
ZW1hcCAmJiBhbWRfc3A1MTAwX2VycmF0dW0yOCgpICkKKyAgICAgICAgZ290
byBlcnJvcl9vdXQ7CisKICAgICBpcnFfdG9faW9tbXUgPSB4bWFsbG9jX2Fy
cmF5KHN0cnVjdCBhbWRfaW9tbXUgKiwgbnJfaXJxcyk7CiAgICAgaWYgKCBp
cnFfdG9faW9tbXUgPT0gTlVMTCApCiAgICAgICAgIGdvdG8gZXJyb3Jfb3V0
OwotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW50
ci5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9p
bnRyLmMKQEAgLTI3LDcgKzI3LDcgQEAKICNkZWZpbmUgSU5UUkVNQVBfTEVO
R1RIIDB4QgogI2RlZmluZSBJTlRSRU1BUF9FTlRSSUVTICgxIDw8IElOVFJF
TUFQX0xFTkdUSCkKIAotaW50IGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsK
K3N0cnVjdCBpb2FwaWNfYmRmIGlvYXBpY19iZGZbTUFYX0lPX0FQSUNTXTsK
IGV4dGVybiBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19tYXBwaW5nczsK
IGV4dGVybiB1bnNpZ25lZCBzaG9ydCBpdnJzX2JkZl9lbnRyaWVzOwogdm9p
ZCAqc2hhcmVkX2ludHJlbWFwX3RhYmxlOwpAQCAtMTE3LDEyICsxMTcsMTIg
QEAgdm9pZCBpbnZhbGlkYXRlX2ludGVycnVwdF90YWJsZShzdHJ1Y3QgYQog
c3RhdGljIHZvaWQgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGlj
KAogICAgIGludCBiZGYsCiAgICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXUs
Ci0gICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKmlvYXBpY19ydGUp
CisgICAgY29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSwK
KyAgICBjb25zdCBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSAqb2xkX3J0
ZSkKIHsKICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwogICAgIHUzMiogZW50
cnk7CiAgICAgdTggZGVsaXZlcnlfbW9kZSwgZGVzdCwgdmVjdG9yLCBkZXN0
X21vZGU7Ci0gICAgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKnJ0ZSA9
IGlvYXBpY19ydGU7CiAgICAgaW50IHJlcV9pZDsKICAgICBzcGlubG9ja190
ICpsb2NrOwogICAgIGludCBvZmZzZXQ7CkBAIC0xMzgsNiArMTM4LDE0IEBA
IHN0YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2kKICAg
ICBzcGluX2xvY2tfaXJxc2F2ZShsb2NrLCBmbGFncyk7CiAKICAgICBvZmZz
ZXQgPSBnZXRfaW50cmVtYXBfb2Zmc2V0KHZlY3RvciwgZGVsaXZlcnlfbW9k
ZSk7CisgICAgaWYgKCBvbGRfcnRlICkKKyAgICB7CisgICAgICAgIGludCBv
bGRfb2Zmc2V0ID0gZ2V0X2ludHJlbWFwX29mZnNldChvbGRfcnRlLT52ZWN0
b3IsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBvbGRfcnRlLT5kZWxpdmVyeV9tb2RlKTsKKworICAgICAgICBpZiAo
IG9mZnNldCAhPSBvbGRfb2Zmc2V0ICkKKyAgICAgICAgICAgIGZyZWVfaW50
cmVtYXBfZW50cnkoYmRmLCBvbGRfb2Zmc2V0KTsKKyAgICB9CiAgICAgZW50
cnkgPSAodTMyKilnZXRfaW50cmVtYXBfZW50cnkocmVxX2lkLCBvZmZzZXQp
OwogICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeShlbnRyeSwgdmVjdG9yLCBk
ZWxpdmVyeV9tb2RlLCBkZXN0X21vZGUsIGRlc3QpOwogCkBAIC0xNzYsNyAr
MTg0LDcgQEAgaW50IF9faW5pdCBhbWRfaW9tbXVfc2V0dXBfaW9hcGljX3Jl
bWFwcAogICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCiAgICAgICAgICAg
ICAvKiBnZXQgZGV2aWNlIGlkIG9mIGlvYXBpYyBkZXZpY2VzICovCi0gICAg
ICAgICAgICBiZGYgPSBpb2FwaWNfYmRmW0lPX0FQSUNfSUQoYXBpYyldOwor
ICAgICAgICAgICAgYmRmID0gaW9hcGljX2JkZltJT19BUElDX0lEKGFwaWMp
XS5iZGY7CiAgICAgICAgICAgICBpb21tdSA9IGZpbmRfaW9tbXVfZm9yX2Rl
dmljZShiZGYpOwogICAgICAgICAgICAgaWYgKCAhaW9tbXUgKQogICAgICAg
ICAgICAgewpAQCAtMjA3LDYgKzIxNSw3IEBAIGludCBfX2luaXQgYW1kX2lv
bW11X3NldHVwX2lvYXBpY19yZW1hcHAKICAgICAgICAgICAgICAgICBmbHVz
aF9jb21tYW5kX2J1ZmZlcihpb21tdSk7CiAgICAgICAgICAgICAgICAgc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsKICAg
ICAgICAgICAgIH0KKyAgICAgICAgICAgIHNldF9iaXQocGluLCBpb2FwaWNf
YmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCk7CiAgICAgICAgIH0K
ICAgICB9CiAgICAgcmV0dXJuIDA7CkBAIC0yMTgsNiArMjI3LDcgQEAgdm9p
ZCBhbWRfaW9tbXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAgICAgc3RydWN0IElP
X0FQSUNfcm91dGVfZW50cnkgb2xkX3J0ZSA9IHsgMCB9OwogICAgIHN0cnVj
dCBJT19BUElDX3JvdXRlX2VudHJ5IG5ld19ydGUgPSB7IDAgfTsKICAgICB1
bnNpZ25lZCBpbnQgcnRlX2xvID0gKHJlZyAmIDEpID8gcmVnIC0gMSA6IHJl
ZzsKKyAgICB1bnNpZ25lZCBpbnQgcGluID0gKHJlZyAtIDB4MTApIC8gMjsK
ICAgICBpbnQgc2F2ZWRfbWFzaywgYmRmOwogICAgIHN0cnVjdCBhbWRfaW9t
bXUgKmlvbW11OwogCkBAIC0yMjgsNyArMjM4LDcgQEAgdm9pZCBhbWRfaW9t
bXVfaW9hcGljX3VwZGF0ZV9pcmUoCiAgICAgfQogCiAgICAgLyogZ2V0IGRl
dmljZSBpZCBvZiBpb2FwaWMgZGV2aWNlcyAqLwotICAgIGJkZiA9IGlvYXBp
Y19iZGZbSU9fQVBJQ19JRChhcGljKV07CisgICAgYmRmID0gaW9hcGljX2Jk
ZltJT19BUElDX0lEKGFwaWMpXS5iZGY7CiAgICAgaW9tbXUgPSBmaW5kX2lv
bW11X2Zvcl9kZXZpY2UoYmRmKTsKICAgICBpZiAoICFpb21tdSApCiAgICAg
ewpAQCAtMjU0LDYgKzI2NCwxNCBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNf
dXBkYXRlX2lyZSgKICAgICAgICAgKigoKHUzMiAqKSZuZXdfcnRlKSArIDEp
ID0gdmFsdWU7CiAgICAgfQogCisgICAgaWYgKCBuZXdfcnRlLm1hc2sgJiYK
KyAgICAgICAgICF0ZXN0X2JpdChwaW4sIGlvYXBpY19iZGZbSU9fQVBJQ19J
RChhcGljKV0ucGluX3NldHVwKSApCisgICAgeworICAgICAgICBBU1NFUlQo
c2F2ZWRfbWFzayk7CisgICAgICAgIF9faW9fYXBpY193cml0ZShhcGljLCBy
ZWcsIHZhbHVlKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAgIC8q
IG1hc2sgdGhlIGludGVycnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGludHJl
bWFwIHRhYmxlICovCiAgICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAgewpA
QCAtMjYyLDcgKzI4MCwxMSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBk
YXRlX2lyZSgKICAgICB9CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0IHJl
bWFwcGluZyBlbnRyeSAqLwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9m
cm9tX2lvYXBpYyhiZGYsIGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBkYXRl
X2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGljKAorICAgICAgICBiZGYsIGlv
bW11LCAmbmV3X3J0ZSwKKyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChwaW4s
CisgICAgICAgICAgICAgICAgICAgICAgICAgaW9hcGljX2JkZltJT19BUElD
X0lEKGFwaWMpXS5waW5fc2V0dXApID8gJm9sZF9ydGUKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgOiBOVUxMKTsKIAogICAgIC8qIEZvcndhcmQgd3JpdGUgYWNj
ZXNzIHRvIElPLUFQSUMgUlRFICovCiAgICAgX19pb19hcGljX3dyaXRlKGFw
aWMsIHJlZywgdmFsdWUpOwpAQCAtMzczLDYgKzM5NSwxMiBAQCB2b2lkIGFt
ZF9pb21tdV9tc2lfbXNnX3VwZGF0ZV9pcmUoCiAgICAgICAgIHJldHVybjsK
ICAgICB9CiAKKyAgICBpZiAoIG1zaV9kZXNjLT5yZW1hcF9pbmRleCA+PSAw
ICkKKyAgICAgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5X2Zyb21fbXNpX21z
Zyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIE5VTEwpOworCisgICAgaWYgKCAh
bXNnICkKKyAgICAgICAgcmV0dXJuOworCiAgICAgdXBkYXRlX2ludHJlbWFw
X2VudHJ5X2Zyb21fbXNpX21zZyhpb21tdSwgcGRldiwgbXNpX2Rlc2MsIG1z
Zyk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3Bj
aV9hbWRfaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h
bWQvcGNpX2FtZF9pb21tdS5jCkBAIC0xOTUsNiArMTk1LDggQEAgaW50IF9f
aW5pdCBhbWRfaW92X2RldGVjdCh2b2lkKQogICAgIHsKICAgICAgICAgcHJp
bnRrKCJBTUQtVmk6IE5vdCBvdmVycmlkaW5nIGlycV92ZWN0b3JfbWFwIHNl
dHRpbmdcbiIpOwogICAgIH0KKyAgICBpZiAoICFhbWRfaW9tbXVfcGVyZGV2
X2ludHJlbWFwICkKKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJB
TUQtVmk6IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUgaXMg
bm90IHJlY29tbWVuZGVkIChzZWUgWFNBLTM2KSFcbiIpOwogICAgIHJldHVy
biBzY2FuX3BjaV9kZXZpY2VzKCk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvaW9tbXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9pb21tdS5jCkBAIC00OSw3ICs0OSw3IEBAIGJvb2xfdCBfX3JlYWRf
bW9zdGx5IGlvbW11X3FpbnZhbCA9IDE7CiBib29sX3QgX19yZWFkX21vc3Rs
eSBpb21tdV9pbnRyZW1hcCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBp
b21tdV9oYXBfcHRfc2hhcmU7CiBib29sX3QgX19yZWFkX21vc3RseSBhbWRf
aW9tbXVfZGVidWc7Ci1ib29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVf
cGVyZGV2X2ludHJlbWFwOworYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lv
bW11X3BlcmRldl9pbnRyZW1hcCA9IDE7CiAKIHN0YXRpYyB2b2lkIF9faW5p
dCBwYXJzZV9pb21tdV9wYXJhbShjaGFyICpzKQogewpAQCAtNzgsNiArNzgs
OCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcGFyc2VfaW9tbXVfcGFyYW0oY2hh
CiAgICAgICAgICAgICBhbWRfaW9tbXVfZGVidWcgPSAxOwogICAgICAgICBl
bHNlIGlmICggIXN0cmNtcChzLCAiYW1kLWlvbW11LXBlcmRldi1pbnRyZW1h
cCIpICkKICAgICAgICAgICAgIGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAg
PSAxOworICAgICAgICBlbHNlIGlmICggIXN0cmNtcChzLCAiYW1kLWlvbW11
LWdsb2JhbC1pbnRyZW1hcCIpICkKKyAgICAgICAgICAgIGFtZF9pb21tdV9w
ZXJkZXZfaW50cmVtYXAgPSAwOwogICAgICAgICBlbHNlIGlmICggIXN0cmNt
cChzLCAiZG9tMC1wYXNzdGhyb3VnaCIpICkKICAgICAgICAgICAgIGlvbW11
X3Bhc3N0aHJvdWdoID0gMTsKICAgICAgICAgZWxzZSBpZiAoICFzdHJjbXAo
cywgImRvbTAtc3RyaWN0IikgKQotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2
L2h2bS9zdm0vYW1kLWlvbW11LXByb3RvLmgKKysrIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oCkBAIC04OCw2ICs4
OCwxMSBAQCB2b2lkIGFtZF9pb21tdV9yZWFkX21zaV9mcm9tX2lyZSgKIHVu
c2lnbmVkIGludCBhbWRfaW9tbXVfcmVhZF9pb2FwaWNfZnJvbV9pcmUoCiAg
ICAgdW5zaWduZWQgaW50IGFwaWMsIHVuc2lnbmVkIGludCByZWcpOwogCitl
eHRlcm4gc3RydWN0IGlvYXBpY19iZGYgeworICAgIHUxNiBiZGY7CisgICAg
dW5zaWduZWQgbG9uZyAqcGluX3NldHVwOworfSBpb2FwaWNfYmRmW107CisK
IC8qIHBvd2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAqLwogdm9pZCBhbWRfaW9t
bXVfcmVzdW1lKHZvaWQpOwogdm9pZCBhbWRfaW9tbXVfc3VzcGVuZCh2b2lk
KTsK

--=separator
Content-Type: application/octet-stream; name="xsa36-4.2.patch"
Content-Disposition: attachment; filename="xsa36-4.2.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgpBTUQg
SU9NTVU6IGFsc28gc3BvdCBtaXNzaW5nIElPLUFQSUMgZW50cmllcyBpbiBJ
VlJTIHRhYmxlCgpBcGFydCBmcm9tIGRlYWxpbmcgZHVwbGljYXRlIGNvbmZs
aWN0aW5nIGVudHJpZXMsIHdlIGFsc28gaGF2ZSB0bwpoYW5kbGUgZmlybXdh
cmUgb21pdHRpbmcgSU8tQVBJQyBlbnRyaWVzIGluIElWUlMgYWx0b2dldGhl
ci4gTm90IGRvaW5nCnNvIGhhcyByZXN1bHRlZCBpbiBjL3MgMjY1MTc6NjAx
MTM5ZTJiMGRiIHRvIGNyYXNoIHN1Y2ggc3lzdGVtcyBkdXJpbmcKYm9vdCAo
d2hlcmVhcyB3aXRoIHRoZSBjaGFuZ2UgaGVyZSB0aGUgSU9NTVUgZ2V0cyBk
aXNhYmxlZCBqdXN0IGFzIGlzCmJlaW5nIGRvbmUgaW4gdGhlIG90aGVyIGNh
c2VzLCBpLmUuIHVubGVzcyBnbG9iYWwgdGFibGVzIGFyZSBiZWluZwp1c2Vk
KS4KCkRlYnVnZ2luZyB0aGlzIGlzc3VlIGhhcyBhbHNvIHBvaW50ZWQgb3V0
IHRoYXQgdGhlIGRlYnVnIGxvZyBvdXRwdXQgaXMKcHJldHR5IHVnbHkgdG8g
bG9vayBhdCAtIGNvbnNvbGlkYXRlIHRoZSBvdXRwdXQsIGFuZCBhZGQgb25l
IGV4dHJhCml0ZW0gZm9yIHRoZSBJVkhEIHNwZWNpYWwgZW50cmllcywgc28g
dGhhdCBmdXR1cmUgaXNzdWVzIGFyZSBlYXNpZXIKdG8gYW5hbHl6ZS4KClNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
VGVzdGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5i
b29tLml0PgoKLS0tIGEveGVuL2FyY2gveDg2L2lycS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9pcnEuYwpAQCAtMTk0Miw5ICsxOTQyLDYgQEAgaW50IG1hcF9k
b21haW5fcGlycSgKICAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJmRlc2Mt
PmxvY2ssIGZsYWdzKTsKICAgICAgICAgc2V0X2RvbWFpbl9pcnFfcGlycShk
LCBpcnEsIGluZm8pOwogICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3Jl
KCZkZXNjLT5sb2NrLCBmbGFncyk7Ci0KLSAgICAgICAgaWYgKCBvcHRfaXJx
X3ZlY3Rvcl9tYXAgPT0gT1BUX0lSUV9WRUNUT1JfTUFQX1BFUkRFViApCi0g
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0lORk8gIlBlci1kZXZpY2UgdmVj
dG9yIG1hcHMgZm9yIEdTSXMgbm90IGltcGxlbWVudGVkIHlldC5cbiIpOwog
ICAgIH0KIAogZG9uZToKLS0tIGEveGVuL2RyaXZlcnMvYWNwaS90YWJsZXMu
YworKysgYi94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCkBAIC0yNjcsNyAr
MjY3LDcgQEAgYWNwaV90YWJsZV9wYXJzZV9tYWR0KGVudW0gYWNwaV9tYWR0
X3R5cAogICogQGhhbmRsZXI6IGhhbmRsZXIgdG8gcnVuCiAgKgogICogU2Nh
biB0aGUgQUNQSSBTeXN0ZW0gRGVzY3JpcHRvciBUYWJsZSAoU1REKSBmb3Ig
YSB0YWJsZSBtYXRjaGluZyBAaWQsCi0gKiBydW4gQGhhbmRsZXIgb24gaXQu
ICBSZXR1cm4gMCBpZiB0YWJsZSBmb3VuZCwgcmV0dXJuIG9uIGlmIG5vdC4K
KyAqIHJ1biBAaGFuZGxlciBvbiBpdC4KICAqLwogaW50IF9faW5pdCBhY3Bp
X3RhYmxlX3BhcnNlKGNoYXIgKmlkLCBhY3BpX3RhYmxlX2hhbmRsZXIgaGFu
ZGxlcikKIHsKQEAgLTI4Miw4ICsyODIsNyBAQCBpbnQgX19pbml0IGFjcGlf
dGFibGVfcGFyc2UoY2hhciAqaWQsIGFjCiAJCWFjcGlfZ2V0X3RhYmxlKGlk
LCAwLCAmdGFibGUpOwogCiAJaWYgKHRhYmxlKSB7Ci0JCWhhbmRsZXIodGFi
bGUpOwotCQlyZXR1cm4gMDsKKwkJcmV0dXJuIGhhbmRsZXIodGFibGUpOwog
CX0gZWxzZQogCQlyZXR1cm4gMTsKIH0KLS0tIGEveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYworKysgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jCkBAIC0yMiw2ICsyMiw3IEBA
CiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CiAjaW5jbHVkZSA8eGVuL2FjcGku
aD4KICNpbmNsdWRlIDxhc20vYXBpY2RlZi5oPgorI2luY2x1ZGUgPGFzbS9p
b19hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2FtZC1pb21tdS5oPgogI2luY2x1
ZGUgPGFzbS9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oPgogCkBAIC02MzUs
NiArNjM2LDcgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZp
Y2Vfc3BlYwogICAgIHUxNiBoZWFkZXJfbGVuZ3RoLCB1MTYgYmxvY2tfbGVu
Z3RoLCBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkKIHsKICAgICB1MTYgZGV2
X2xlbmd0aCwgYmRmOworICAgIGludCBhcGljOwogCiAgICAgZGV2X2xlbmd0
aCA9IHNpemVvZigqc3BlY2lhbCk7CiAgICAgaWYgKCBoZWFkZXJfbGVuZ3Ro
IDwgKGJsb2NrX2xlbmd0aCArIGRldl9sZW5ndGgpICkKQEAgLTY1MSwxMCAr
NjUzLDU5IEBAIHN0YXRpYyB1MTYgX19pbml0IHBhcnNlX2l2aGRfZGV2aWNl
X3NwZWMKICAgICB9CiAKICAgICBhZGRfaXZyc19tYXBwaW5nX2VudHJ5KGJk
ZiwgYmRmLCBzcGVjaWFsLT5oZWFkZXIuZGF0YV9zZXR0aW5nLCBpb21tdSk7
Ci0gICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMgKi8KLSAgICBpb2Fw
aWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLmJkZiA9IGJkZjsKLSAgICBpb2Fw
aWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLnNlZyA9IHNlZzsKLSAgICByZXR1
cm4gZGV2X2xlbmd0aDsKKworICAgIGlmICggc3BlY2lhbC0+dmFyaWV0eSAh
PSBBQ1BJX0lWSERfSU9BUElDICkKKyAgICB7CisgICAgICAgIGlmICggc3Bl
Y2lhbC0+dmFyaWV0eSAhPSBBQ1BJX0lWSERfSFBFVCApCisgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAiVW5yZWNvZ25pemVkIElWSEQgc3BlY2lh
bCB2YXJpZXR5ICUjeFxuIiwKKyAgICAgICAgICAgICAgICAgICBzcGVjaWFs
LT52YXJpZXR5KTsKKyAgICAgICAgcmV0dXJuIGRldl9sZW5ndGg7CisgICAg
fQorCisgICAgLyoKKyAgICAgKiBTb21lIEJJT1NlcyBoYXZlIElPQVBJQyBi
cm9rZW4gZW50cmllcyBzbyB3ZSBjaGVjayBmb3IgSVZSUworICAgICAqIGNv
bnNpc3RlbmN5IGhlcmUgLS0tIHdoZXRoZXIgZW50cnkncyBJT0FQSUMgSUQg
aXMgdmFsaWQgYW5kCisgICAgICogd2hldGhlciB0aGVyZSBhcmUgY29uZmxp
Y3RpbmcvZHVwbGljYXRlZCBlbnRyaWVzLgorICAgICAqLworICAgIGZvciAo
IGFwaWMgPSAwOyBhcGljIDwgbnJfaW9hcGljczsgYXBpYysrICkKKyAgICB7
CisgICAgICAgIGlmICggSU9fQVBJQ19JRChhcGljKSAhPSBzcGVjaWFsLT5o
YW5kbGUgKQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgaWYg
KCBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5kbGVdLnBpbl9zZXR1cCApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggaW9hcGljX3NiZGZbc3BlY2lh
bC0+aGFuZGxlXS5iZGYgPT0gYmRmICYmCisgICAgICAgICAgICAgICAgIGlv
YXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0uc2VnID09IHNlZyApCisgICAg
ICAgICAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJJVkhEIFdhcm5pbmc6IER1
cGxpY2F0ZSBJTy1BUElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzcGVjaWFsLT5oYW5kbGUpOworICAgICAg
ICAgICAgZWxzZQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBDb25mbGljdGluZyBJTy1B
UElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgICBz
cGVjaWFsLT5oYW5kbGUpOworICAgICAgICAgICAgICAgIGlmICggYW1kX2lv
bW11X3BlcmRldl9pbnRyZW1hcCApCisgICAgICAgICAgICAgICAgICAgIHJl
dHVybiAwOworICAgICAgICAgICAgfQorICAgICAgICB9CisgICAgICAgIGVs
c2UKKyAgICAgICAgeworICAgICAgICAgICAgLyogc2V0IGRldmljZSBpZCBv
ZiBpb2FwaWMgKi8KKyAgICAgICAgICAgIGlvYXBpY19zYmRmW3NwZWNpYWwt
PmhhbmRsZV0uYmRmID0gYmRmOworICAgICAgICAgICAgaW9hcGljX3NiZGZb
c3BlY2lhbC0+aGFuZGxlXS5zZWcgPSBzZWc7CisKKyAgICAgICAgICAgIGlv
YXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0ucGluX3NldHVwID0geHphbGxv
Y19hcnJheSgKKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nLCBCSVRT
X1RPX0xPTkdTKG5yX2lvYXBpY19lbnRyaWVzW2FwaWNdKSk7CisgICAgICAg
ICAgICBpZiAoIG5yX2lvYXBpY19lbnRyaWVzW2FwaWNdICYmCisgICAgICAg
ICAgICAgICAgICFpb2FwaWNfc2JkZltJT19BUElDX0lEKGFwaWMpXS5waW5f
c2V0dXAgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIHByaW50
ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBPdXQgb2YgbWVtb3J5XG4iKTsK
KyAgICAgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgICAgIH0KKyAg
ICAgICAgfQorICAgICAgICByZXR1cm4gZGV2X2xlbmd0aDsKKyAgICB9CisK
KyAgICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogSW52YWxpZCBJ
Ty1BUElDICUjeFxuIiwgc3BlY2lhbC0+aGFuZGxlKTsKKyAgICByZXR1cm4g
MDsKIH0KIAogc3RhdGljIGludCBfX2luaXQgcGFyc2VfaXZoZF9ibG9jayhj
b25zdCBzdHJ1Y3QgYWNwaV9pdnJzX2hhcmR3YXJlICppdmhkX2Jsb2NrKQpA
QCAtODE4LDYgKzg2OSw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2l2
cnNfdGFibGUoc3RydWMKIHsKICAgICBjb25zdCBzdHJ1Y3QgYWNwaV9pdnJz
X2hlYWRlciAqaXZyc19ibG9jazsKICAgICB1bnNpZ25lZCBsb25nIGxlbmd0
aDsKKyAgICB1bnNpZ25lZCBpbnQgYXBpYzsKICAgICBpbnQgZXJyb3IgPSAw
OwogCiAgICAgQlVHX09OKCF0YWJsZSk7CkBAIC04NTAsNiArOTAyLDI5IEBA
IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2l2cnNfdGFibGUoc3RydWMKICAg
ICAgICAgbGVuZ3RoICs9IGl2cnNfYmxvY2stPmxlbmd0aDsKICAgICB9CiAK
KyAgICAvKiBFYWNoIElPLUFQSUMgbXVzdCBoYXZlIGJlZW4gbWVudGlvbmVk
IGluIHRoZSB0YWJsZS4gKi8KKyAgICBmb3IgKCBhcGljID0gMDsgIWVycm9y
ICYmIGFwaWMgPCBucl9pb2FwaWNzOyArK2FwaWMgKQorICAgIHsKKyAgICAg
ICAgaWYgKCAhbnJfaW9hcGljX2VudHJpZXNbYXBpY10gfHwKKyAgICAgICAg
ICAgICBpb2FwaWNfc2JkZltJT19BUElDX0lEKGFwaWMpXS5waW5fc2V0dXAg
KQorICAgICAgICAgICAgY29udGludWU7CisKKyAgICAgICAgcHJpbnRrKFhF
TkxPR19FUlIgIklWSEQgRXJyb3I6IG5vIGluZm9ybWF0aW9uIGZvciBJTy1B
UElDICUjeFxuIiwKKyAgICAgICAgICAgICAgIElPX0FQSUNfSUQoYXBpYykp
OworICAgICAgICBpZiAoIGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAgKQor
ICAgICAgICAgICAgZXJyb3IgPSAtRU5YSU87CisgICAgICAgIGVsc2UKKyAg
ICAgICAgeworICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChh
cGljKV0ucGluX3NldHVwID0geHphbGxvY19hcnJheSgKKyAgICAgICAgICAg
ICAgICB1bnNpZ25lZCBsb25nLCBCSVRTX1RPX0xPTkdTKG5yX2lvYXBpY19l
bnRyaWVzW2FwaWNdKSk7CisgICAgICAgICAgICBpZiAoICFpb2FwaWNfc2Jk
ZltJT19BUElDX0lEKGFwaWMpXS5waW5fc2V0dXAgKQorICAgICAgICAgICAg
eworICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVy
cm9yOiBPdXQgb2YgbWVtb3J5XG4iKTsKKyAgICAgICAgICAgICAgICBlcnJv
ciA9IC1FTk9NRU07CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICB9
CisKICAgICByZXR1cm4gZXJyb3I7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvYW1kL2lvbW11X2luaXQuYworKysgYi94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCkBAIC0xMTI2LDEyICsx
MTI2LDQ1IEBAIHN0YXRpYyBpbnQgX19pbml0IGFtZF9pb21tdV9zZXR1cF9k
ZXZpY2UKICAgICByZXR1cm4gMDsKIH0KIAorLyogQ2hlY2sgd2hldGhlciBT
UDUxMDAgU0FUQSBDb21iaW5lZCBtb2RlIGlzIG9uICovCitzdGF0aWMgYm9v
bF90IF9faW5pdCBhbWRfc3A1MTAwX2VycmF0dW0yOCh2b2lkKQoreworICAg
IHUzMiBidXMsIGlkOworICAgIHUxNiB2ZW5kb3JfaWQsIGRldl9pZDsKKyAg
ICB1OCBieXRlOworCisgICAgZm9yIChidXMgPSAwOyBidXMgPCAyNTY7IGJ1
cysrKQorICAgIHsKKyAgICAgICAgaWQgPSBwY2lfY29uZl9yZWFkMzIoMCwg
YnVzLCAweDE0LCAwLCBQQ0lfVkVORE9SX0lEKTsKKworICAgICAgICB2ZW5k
b3JfaWQgPSBpZCAmIDB4ZmZmZjsKKyAgICAgICAgZGV2X2lkID0gKGlkID4+
IDE2KSAmIDB4ZmZmZjsKKworICAgICAgICAvKiBTUDUxMDAgU01CdXMgbW9k
dWxlIHNldHMgQ29tYmluZWQgbW9kZSBvbiAqLworICAgICAgICBpZiAodmVu
ZG9yX2lkICE9IDB4MTAwMiB8fCBkZXZfaWQgIT0gMHg0Mzg1KQorICAgICAg
ICAgICAgY29udGludWU7CisKKyAgICAgICAgYnl0ZSA9IHBjaV9jb25mX3Jl
YWQ4KDAsIGJ1cywgMHgxNCwgMCwgMHhhZCk7CisgICAgICAgIGlmICggKGJ5
dGUgPj4gMykgJiAxICkKKyAgICAgICAgeworICAgICAgICAgICAgcHJpbnRr
KFhFTkxPR19XQVJOSU5HICJBTUQtVmk6IFNQNTEwMCBlcnJhdHVtIDI4IGRl
dGVjdGVkLCBkaXNhYmxpbmcgSU9NTVUuXG4iCisgICAgICAgICAgICAgICAg
ICAgIklmIHBvc3NpYmxlLCBkaXNhYmxlIFNBVEEgQ29tYmluZWQgbW9kZSBp
biBCSU9TIG9yIGNvbnRhY3QgeW91ciB2ZW5kb3IgZm9yIEJJT1MgdXBkYXRl
LlxuIik7CisgICAgICAgICAgICByZXR1cm4gMTsKKyAgICAgICAgfQorICAg
IH0KKworICAgIHJldHVybiAwOworfQorCiBpbnQgX19pbml0IGFtZF9pb21t
dV9pbml0KHZvaWQpCiB7CiAgICAgc3RydWN0IGFtZF9pb21tdSAqaW9tbXU7
CiAKICAgICBCVUdfT04oICFpb21tdV9mb3VuZCgpICk7CiAKKyAgICBpZiAo
IGFtZF9pb21tdV9wZXJkZXZfaW50cmVtYXAgJiYgYW1kX3NwNTEwMF9lcnJh
dHVtMjgoKSApCisgICAgICAgIGdvdG8gZXJyb3Jfb3V0OworCiAgICAgaXZy
c19iZGZfZW50cmllcyA9IGFtZF9pb21tdV9nZXRfaXZyc19kZXZfZW50cmll
cygpOwogCiAgICAgaWYgKCAhaXZyc19iZGZfZW50cmllcyApCi0tLSBhL3hl
bi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbnRyLmMKKysrIGIv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11X2ludHIuYwpAQCAt
OTksMTIgKzk5LDEyIEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9l
bnRyeSh1MzIqIGUKIHN0YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRy
eV9mcm9tX2lvYXBpYygKICAgICBpbnQgYmRmLAogICAgIHN0cnVjdCBhbWRf
aW9tbXUgKmlvbW11LAotICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5
ICppb2FwaWNfcnRlKQorICAgIGNvbnN0IHN0cnVjdCBJT19BUElDX3JvdXRl
X2VudHJ5ICpydGUsCisgICAgY29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVf
ZW50cnkgKm9sZF9ydGUpCiB7CiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsK
ICAgICB1MzIqIGVudHJ5OwogICAgIHU4IGRlbGl2ZXJ5X21vZGUsIGRlc3Qs
IHZlY3RvciwgZGVzdF9tb2RlOwotICAgIHN0cnVjdCBJT19BUElDX3JvdXRl
X2VudHJ5ICpydGUgPSBpb2FwaWNfcnRlOwogICAgIGludCByZXFfaWQ7CiAg
ICAgc3BpbmxvY2tfdCAqbG9jazsKICAgICBpbnQgb2Zmc2V0OwpAQCAtMTIw
LDYgKzEyMCwxNCBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50
cnlfZnJvbV9pCiAgICAgc3Bpbl9sb2NrX2lycXNhdmUobG9jaywgZmxhZ3Mp
OwogCiAgICAgb2Zmc2V0ID0gZ2V0X2ludHJlbWFwX29mZnNldCh2ZWN0b3Is
IGRlbGl2ZXJ5X21vZGUpOworICAgIGlmICggb2xkX3J0ZSApCisgICAgewor
ICAgICAgICBpbnQgb2xkX29mZnNldCA9IGdldF9pbnRyZW1hcF9vZmZzZXQo
b2xkX3J0ZS0+dmVjdG9yLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgb2xkX3J0ZS0+ZGVsaXZlcnlfbW9kZSk7CisK
KyAgICAgICAgaWYgKCBvZmZzZXQgIT0gb2xkX29mZnNldCApCisgICAgICAg
ICAgICBmcmVlX2ludHJlbWFwX2VudHJ5KGlvbW11LT5zZWcsIGJkZiwgb2xk
X29mZnNldCk7CisgICAgfQogICAgIGVudHJ5ID0gKHUzMiopZ2V0X2ludHJl
bWFwX2VudHJ5KGlvbW11LT5zZWcsIHJlcV9pZCwgb2Zmc2V0KTsKICAgICB1
cGRhdGVfaW50cmVtYXBfZW50cnkoZW50cnksIHZlY3RvciwgZGVsaXZlcnlf
bW9kZSwgZGVzdF9tb2RlLCBkZXN0KTsKIApAQCAtMTg4LDYgKzE5Niw3IEBA
IGludCBfX2luaXQgYW1kX2lvbW11X3NldHVwX2lvYXBpY19yZW1hcHAKICAg
ICAgICAgICAgICAgICBhbWRfaW9tbXVfZmx1c2hfaW50cmVtYXAoaW9tbXUs
IHJlcV9pZCk7CiAgICAgICAgICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVz
dG9yZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsKICAgICAgICAgICAgIH0KKyAg
ICAgICAgICAgIHNldF9iaXQocGluLCBpb2FwaWNfc2JkZltJT19BUElDX0lE
KGFwaWMpXS5waW5fc2V0dXApOwogICAgICAgICB9CiAgICAgfQogICAgIHJl
dHVybiAwOwpAQCAtMTk5LDYgKzIwOCw3IEBAIHZvaWQgYW1kX2lvbW11X2lv
YXBpY191cGRhdGVfaXJlKAogICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2Vu
dHJ5IG9sZF9ydGUgPSB7IDAgfTsKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0
ZV9lbnRyeSBuZXdfcnRlID0geyAwIH07CiAgICAgdW5zaWduZWQgaW50IHJ0
ZV9sbyA9IChyZWcgJiAxKSA/IHJlZyAtIDEgOiByZWc7CisgICAgdW5zaWdu
ZWQgaW50IHBpbiA9IChyZWcgLSAweDEwKSAvIDI7CiAgICAgaW50IHNhdmVk
X21hc2ssIHNlZywgYmRmOwogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11
OwogCkBAIC0yMzYsNiArMjQ2LDE0IEBAIHZvaWQgYW1kX2lvbW11X2lvYXBp
Y191cGRhdGVfaXJlKAogICAgICAgICAqKCgodTMyICopJm5ld19ydGUpICsg
MSkgPSB2YWx1ZTsKICAgICB9CiAKKyAgICBpZiAoIG5ld19ydGUubWFzayAm
JgorICAgICAgICAgIXRlc3RfYml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJ
Q19JRChhcGljKV0ucGluX3NldHVwKSApCisgICAgeworICAgICAgICBBU1NF
UlQoc2F2ZWRfbWFzayk7CisgICAgICAgIF9faW9fYXBpY193cml0ZShhcGlj
LCByZWcsIHZhbHVlKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAg
IC8qIG1hc2sgdGhlIGludGVycnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGlu
dHJlbWFwIHRhYmxlICovCiAgICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAg
ewpAQCAtMjQ0LDcgKzI2MiwxMSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNf
dXBkYXRlX2lyZSgKICAgICB9CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0
IHJlbWFwcGluZyBlbnRyeSAqLwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRy
eV9mcm9tX2lvYXBpYyhiZGYsIGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBk
YXRlX2ludHJlbWFwX2VudHJ5X2Zyb21faW9hcGljKAorICAgICAgICBiZGYs
IGlvbW11LCAmbmV3X3J0ZSwKKyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChw
aW4sCisgICAgICAgICAgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9f
QVBJQ19JRChhcGljKV0ucGluX3NldHVwKSA/ICZvbGRfcnRlCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA6IE5VTEwpOwogCiAgICAgLyogRm9yd2FyZCB3cml0
ZSBhY2Nlc3MgdG8gSU8tQVBJQyBSVEUgKi8KICAgICBfX2lvX2FwaWNfd3Jp
dGUoYXBpYywgcmVnLCB2YWx1ZSk7CkBAIC0zNTQsNiArMzc2LDEyIEBAIHZv
aWQgYW1kX2lvbW11X21zaV9tc2dfdXBkYXRlX2lyZSgKICAgICAgICAgcmV0
dXJuOwogICAgIH0KIAorICAgIGlmICggbXNpX2Rlc2MtPnJlbWFwX2luZGV4
ID49IDAgKQorICAgICAgICB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9t
c2lfbXNnKGlvbW11LCBwZGV2LCBtc2lfZGVzYywgTlVMTCk7CisKKyAgICBp
ZiAoICFtc2cgKQorICAgICAgICByZXR1cm47CisKICAgICB1cGRhdGVfaW50
cmVtYXBfZW50cnlfZnJvbV9tc2lfbXNnKGlvbW11LCBwZGV2LCBtc2lfZGVz
YywgbXNnKTsKIH0KIAotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9h
bWQvcGNpX2FtZF9pb21tdS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL2FtZC9wY2lfYW1kX2lvbW11LmMKQEAgLTIwNSw2ICsyMDUsOCBAQCBp
bnQgX19pbml0IGFtZF9pb3ZfZGV0ZWN0KHZvaWQpCiAgICAgewogICAgICAg
ICBwcmludGsoIkFNRC1WaTogTm90IG92ZXJyaWRpbmcgaXJxX3ZlY3Rvcl9t
YXAgc2V0dGluZ1xuIik7CiAgICAgfQorICAgIGlmICggIWFtZF9pb21tdV9w
ZXJkZXZfaW50cmVtYXAgKQorICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5J
TkcgIkFNRC1WaTogVXNpbmcgZ2xvYmFsIGludGVycnVwdCByZW1hcCB0YWJs
ZSBpcyBub3QgcmVjb21tZW5kZWQgKHNlZSBYU0EtMzYpIVxuIik7CiAgICAg
cmV0dXJuIHNjYW5fcGNpX2RldmljZXMoKTsKIH0KIAotLS0gYS94ZW4vZHJp
dmVycy9wYXNzdGhyb3VnaC9pb21tdS5jCisrKyBiL3hlbi9kcml2ZXJzL3Bh
c3N0aHJvdWdoL2lvbW11LmMKQEAgLTUyLDcgKzUyLDcgQEAgYm9vbF90IF9f
cmVhZF9tb3N0bHkgaW9tbXVfcWludmFsID0gMTsKIGJvb2xfdCBfX3JlYWRf
bW9zdGx5IGlvbW11X2ludHJlbWFwID0gMTsKIGJvb2xfdCBfX3JlYWRfbW9z
dGx5IGlvbW11X2hhcF9wdF9zaGFyZSA9IDE7CiBib29sX3QgX19yZWFkX21v
c3RseSBpb21tdV9kZWJ1ZzsKLWJvb2xfdCBfX3JlYWRfbW9zdGx5IGFtZF9p
b21tdV9wZXJkZXZfaW50cmVtYXA7Citib29sX3QgX19yZWFkX21vc3RseSBh
bWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwID0gMTsKIAogREVGSU5FX1BFUl9D
UFUoYm9vbF90LCBpb21tdV9kb250X2ZsdXNoX2lvdGxiKTsKIAotLS0gYS94
ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9zdm0vYW1kLWlvbW11LXByb3RvLmgK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vc3ZtL2FtZC1pb21tdS1w
cm90by5oCkBAIC0xMDAsNiArMTAwLDcgQEAgdm9pZCBhbWRfaW9tbXVfcmVh
ZF9tc2lfZnJvbV9pcmUoCiAKIGV4dGVybiBzdHJ1Y3QgaW9hcGljX3NiZGYg
ewogICAgIHUxNiBiZGYsIHNlZzsKKyAgICB1bnNpZ25lZCBsb25nICpwaW5f
c2V0dXA7CiB9IGlvYXBpY19zYmRmW01BWF9JT19BUElDU107CiBleHRlcm4g
dm9pZCAqc2hhcmVkX2ludHJlbWFwX3RhYmxlOwogCg==

--=separator
Content-Type: application/octet-stream; name="xsa36-unstable.patch"
Content-Disposition: attachment; filename="xsa36-unstable.patch"
Content-Transfer-Encoding: base64

QUNQSTogYWNwaV90YWJsZV9wYXJzZSgpIHNob3VsZCByZXR1cm4gaGFuZGxl
cidzIGVycm9yIGNvZGUKCkN1cnJlbnRseSwgdGhlIGVycm9yIGNvZGUgcmV0
dXJuZWQgYnkgYWNwaV90YWJsZV9wYXJzZSgpJ3MgaGFuZGxlcgppcyBpZ25v
cmVkLiBUaGlzIHBhdGNoIHdpbGwgcHJvcGFnYXRlIGhhbmRsZXIncyByZXR1
cm4gdmFsdWUgdG8KYWNwaV90YWJsZV9wYXJzZSgpJ3MgY2FsbGVyLgoKQU1E
LElPTU1VOiBDbGVhbiB1cCBvbGQgZW50cmllcyBpbiByZW1hcHBpbmcgdGFi
bGVzIHdoZW4gY3JlYXRpbmcgbmV3CmludGVycnVwdCBtYXBwaW5nLgoKV2hl
biBjaGFuZ2luZyB0aGUgYWZmaW5pdHkgb2YgYW4gSVJRIGFzc29jaWF0ZWQg
d2l0aCBhIHBhc3NlZAp0aHJvdWdoIFBDSSBkZXZpY2UsIGNsZWFyIHByZXZp
b3VzIG1hcHBpbmcuCgpJbiBhZGRpdGlvbiwgYmVjYXVzZSBzb21lIEJJT1Nl
cyBtYXkgaW5jb3JyZWN0bHkgcHJvZ3JhbSBJVlJTCmVudHJpZXMgZm9yIElP
QVBJQyB0cnkgdG8gY2hlY2sgZm9yIGVudHJ5J3MgY29uc2lzdGVuY3kuIFNw
ZWNpZmljYWxseSwKaWYgY29uZmxpY3RpbmcgZW50cmllcyBhcmUgZm91bmQg
ZGlzYWJsZSBJT01NVSBpZiBwZXItZGV2aWNlCnJlbWFwcGluZyB0YWJsZSBp
cyB1c2VkLiBJZiBlbnRyaWVzIHJlZmVyIHRvIGJvZ3VzIElPQVBJQyBJRHMK
ZGlzYWJsZSBJT01NVSB1bmNvbmRpdGlvbmFsbHkKCkFNRCxJT01NVTogRGlz
YWJsZSBJT01NVSBpZiBTQVRBIENvbWJpbmVkIG1vZGUgaXMgb24KCkFNRCdz
IFNQNTEwMCBjaGlwc2V0IGNhbiBiZSBwbGFjZWQgaW50byBTQVRBIENvbWJp
bmVkIG1vZGUKdGhhdCBtYXkgY2F1c2UgcHJldmVudCBkb20wIGZyb20gYm9v
dGluZyB3aGVuIElPTU1VIGlzCmVuYWJsZWQgYW5kIHBlci1kZXZpY2UgaW50
ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBpcyB1c2VkLgpXaGlsZSBTUDUxMDAg
ZXJyYXR1bSAyOCByZXF1aXJlcyBCSU9TZXMgdG8gZGlzYWJsZSB0aGlzIG1v
ZGUsCnNvbWUgbWF5IHN0aWxsIHVzZSBpdC4KClRoaXMgcGF0Y2ggY2hlY2tz
IHdoZXRoZXIgdGhpcyBtb2RlIGlzIG9uIGFuZCwgaWYgcGVyLWRldmljZQp0
YWJsZSBpcyBpbiB1c2UsIGRpc2FibGVzIElPTU1VLgoKQU1ELElPTU1VOiBN
YWtlIHBlci1kZXZpY2UgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBkZWZh
dWx0CgpVc2luZyBnbG9iYWwgaW50ZXJydXB0IHJlbWFwcGluZyB0YWJsZSBt
YXkgYmUgaW5zZWN1cmUsIGFzCmRlc2NyaWJlZCBieSBYU0EtMzYuIFRoaXMg
cGF0Y2ggbWFrZXMgcGVyLWRldmljZSBtb2RlIGRlZmF1bHQuCgpUaGlzIGlz
IFhTQS0zNiAvIENWRS0yMDEzLTAxNTMuCgpTaWduZWQtb2ZmLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClNpZ25lZC1vZmYtYnk6IEJv
cmlzIE9zdHJvdnNreSA8Ym9yaXMub3N0cm92c2t5QGFtZC5jb20+CgpBTUQg
SU9NTVU6IGFsc28gc3BvdCBtaXNzaW5nIElPLUFQSUMgZW50cmllcyBpbiBJ
VlJTIHRhYmxlCgpBcGFydCBmcm9tIGRlYWxpbmcgZHVwbGljYXRlIGNvbmZs
aWN0aW5nIGVudHJpZXMsIHdlIGFsc28gaGF2ZSB0bwpoYW5kbGUgZmlybXdh
cmUgb21pdHRpbmcgSU8tQVBJQyBlbnRyaWVzIGluIElWUlMgYWx0b2dldGhl
ci4gTm90IGRvaW5nCnNvIGhhcyByZXN1bHRlZCBpbiBjL3MgMjY1MTc6NjAx
MTM5ZTJiMGRiIHRvIGNyYXNoIHN1Y2ggc3lzdGVtcyBkdXJpbmcKYm9vdCAo
d2hlcmVhcyB3aXRoIHRoZSBjaGFuZ2UgaGVyZSB0aGUgSU9NTVUgZ2V0cyBk
aXNhYmxlZCBqdXN0IGFzIGlzCmJlaW5nIGRvbmUgaW4gdGhlIG90aGVyIGNh
c2VzLCBpLmUuIHVubGVzcyBnbG9iYWwgdGFibGVzIGFyZSBiZWluZwp1c2Vk
KS4KCkRlYnVnZ2luZyB0aGlzIGlzc3VlIGhhcyBhbHNvIHBvaW50ZWQgb3V0
IHRoYXQgdGhlIGRlYnVnIGxvZyBvdXRwdXQgaXMKcHJldHR5IHVnbHkgdG8g
bG9vayBhdCAtIGNvbnNvbGlkYXRlIHRoZSBvdXRwdXQsIGFuZCBhZGQgb25l
IGV4dHJhCml0ZW0gZm9yIHRoZSBJVkhEIHNwZWNpYWwgZW50cmllcywgc28g
dGhhdCBmdXR1cmUgaXNzdWVzIGFyZSBlYXNpZXIKdG8gYW5hbHl6ZS4KClNp
Z25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4K
VGVzdGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5i
b29tLml0PgoKLS0tIGEveGVuL2FyY2gveDg2L2lycS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9pcnEuYwpAQCAtMTk0Myw5ICsxOTQzLDYgQEAgaW50IG1hcF9k
b21haW5fcGlycSgKICAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJmRlc2Mt
PmxvY2ssIGZsYWdzKTsKICAgICAgICAgc2V0X2RvbWFpbl9pcnFfcGlycShk
LCBpcnEsIGluZm8pOwogICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3Jl
KCZkZXNjLT5sb2NrLCBmbGFncyk7Ci0KLSAgICAgICAgaWYgKCBvcHRfaXJx
X3ZlY3Rvcl9tYXAgPT0gT1BUX0lSUV9WRUNUT1JfTUFQX1BFUkRFViApCi0g
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0lORk8gIlBlci1kZXZpY2UgdmVj
dG9yIG1hcHMgZm9yIEdTSXMgbm90IGltcGxlbWVudGVkIHlldC5cbiIpOwog
ICAgIH0KIAogZG9uZToKLS0tIGEveGVuL2RyaXZlcnMvYWNwaS90YWJsZXMu
YworKysgYi94ZW4vZHJpdmVycy9hY3BpL3RhYmxlcy5jCkBAIC0yNjUsNyAr
MjY1LDcgQEAgYWNwaV90YWJsZV9wYXJzZV9tYWR0KGVudW0gYWNwaV9tYWR0
X3R5cAogICogQGhhbmRsZXI6IGhhbmRsZXIgdG8gcnVuCiAgKgogICogU2Nh
biB0aGUgQUNQSSBTeXN0ZW0gRGVzY3JpcHRvciBUYWJsZSAoU1REKSBmb3Ig
YSB0YWJsZSBtYXRjaGluZyBAaWQsCi0gKiBydW4gQGhhbmRsZXIgb24gaXQu
ICBSZXR1cm4gMCBpZiB0YWJsZSBmb3VuZCwgcmV0dXJuIG9uIGlmIG5vdC4K
KyAqIHJ1biBAaGFuZGxlciBvbiBpdC4KICAqLwogaW50IF9faW5pdCBhY3Bp
X3RhYmxlX3BhcnNlKGNoYXIgKmlkLCBhY3BpX3RhYmxlX2hhbmRsZXIgaGFu
ZGxlcikKIHsKQEAgLTI4MCw4ICsyODAsNyBAQCBpbnQgX19pbml0IGFjcGlf
dGFibGVfcGFyc2UoY2hhciAqaWQsIGFjCiAJCWFjcGlfZ2V0X3RhYmxlKGlk
LCAwLCAmdGFibGUpOwogCiAJaWYgKHRhYmxlKSB7Ci0JCWhhbmRsZXIodGFi
bGUpOwotCQlyZXR1cm4gMDsKKwkJcmV0dXJuIGhhbmRsZXIodGFibGUpOwog
CX0gZWxzZQogCQlyZXR1cm4gMTsKIH0KLS0tIGEveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvYW1kL2lvbW11X2FjcGkuYworKysgYi94ZW4vZHJpdmVycy9w
YXNzdGhyb3VnaC9hbWQvaW9tbXVfYWNwaS5jCkBAIC0yMiw2ICsyMiw3IEBA
CiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+CiAjaW5jbHVkZSA8eGVuL2FjcGku
aD4KICNpbmNsdWRlIDxhc20vYXBpY2RlZi5oPgorI2luY2x1ZGUgPGFzbS9p
b19hcGljLmg+CiAjaW5jbHVkZSA8YXNtL2FtZC1pb21tdS5oPgogI2luY2x1
ZGUgPGFzbS9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oPgogCkBAIC02Mzcs
NiArNjM4LDcgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZp
Y2Vfc3BlYwogICAgIHUxNiBoZWFkZXJfbGVuZ3RoLCB1MTYgYmxvY2tfbGVu
Z3RoLCBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkKIHsKICAgICB1MTYgZGV2
X2xlbmd0aCwgYmRmOworICAgIGludCBhcGljOwogCiAgICAgZGV2X2xlbmd0
aCA9IHNpemVvZigqc3BlY2lhbCk7CiAgICAgaWYgKCBoZWFkZXJfbGVuZ3Ro
IDwgKGJsb2NrX2xlbmd0aCArIGRldl9sZW5ndGgpICkKQEAgLTY1Nyw5ICs2
NTksNTMgQEAgc3RhdGljIHUxNiBfX2luaXQgcGFyc2VfaXZoZF9kZXZpY2Vf
c3BlYwogICAgIHN3aXRjaCAoIHNwZWNpYWwtPnZhcmlldHkgKQogICAgIHsK
ICAgICBjYXNlIEFDUElfSVZIRF9JT0FQSUM6Ci0gICAgLyogc2V0IGRldmlj
ZSBpZCBvZiBpb2FwaWMgKi8KLSAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lh
bC0+aGFuZGxlXS5iZGYgPSBiZGY7Ci0gICAgICAgIGlvYXBpY19zYmRmW3Nw
ZWNpYWwtPmhhbmRsZV0uc2VnID0gc2VnOworICAgICAgICAvKgorICAgICAg
ICAgKiBTb21lIEJJT1NlcyBoYXZlIElPQVBJQyBicm9rZW4gZW50cmllcyBz
byB3ZSBjaGVjayBmb3IgSVZSUworICAgICAgICAgKiBjb25zaXN0ZW5jeSBo
ZXJlIC0tLSB3aGV0aGVyIGVudHJ5J3MgSU9BUElDIElEIGlzIHZhbGlkIGFu
ZAorICAgICAgICAgKiB3aGV0aGVyIHRoZXJlIGFyZSBjb25mbGljdGluZy9k
dXBsaWNhdGVkIGVudHJpZXMuCisgICAgICAgICAqLworICAgICAgICBmb3Ig
KCBhcGljID0gMDsgYXBpYyA8IG5yX2lvYXBpY3M7IGFwaWMrKyApCisgICAg
ICAgIHsKKyAgICAgICAgICAgIGlmICggSU9fQVBJQ19JRChhcGljKSAhPSBz
cGVjaWFsLT5oYW5kbGUgKQorICAgICAgICAgICAgICAgIGNvbnRpbnVlOwor
CisgICAgICAgICAgICBpZiAoIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRs
ZV0ucGluX3NldHVwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAg
ICBpZiAoIGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0uYmRmID09IGJk
ZiAmJgorICAgICAgICAgICAgICAgICAgICAgaW9hcGljX3NiZGZbc3BlY2lh
bC0+aGFuZGxlXS5zZWcgPT0gc2VnICkKKyAgICAgICAgICAgICAgICAgICAg
QU1EX0lPTU1VX0RFQlVHKCJJVkhEIFdhcm5pbmc6IER1cGxpY2F0ZSBJTy1B
UElDICUjeCBlbnRyaWVzXG4iLAorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3BlY2lhbC0+aGFuZGxlKTsKKyAgICAgICAgICAgICAg
ICBlbHNlCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICBwcmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogQ29uZmxpY3Rpbmcg
SU8tQVBJQyAlI3ggZW50cmllc1xuIiwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHNwZWNpYWwtPmhhbmRsZSk7CisgICAgICAgICAgICAgICAgICAg
IGlmICggYW1kX2lvbW11X3BlcmRldl9pbnRyZW1hcCApCisgICAgICAgICAg
ICAgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgICAgICAgICB9Cisg
ICAgICAgICAgICB9CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICB7
CisgICAgICAgICAgICAgICAgLyogc2V0IGRldmljZSBpZCBvZiBpb2FwaWMg
Ki8KKyAgICAgICAgICAgICAgICBpb2FwaWNfc2JkZltzcGVjaWFsLT5oYW5k
bGVdLmJkZiA9IGJkZjsKKyAgICAgICAgICAgICAgICBpb2FwaWNfc2JkZltz
cGVjaWFsLT5oYW5kbGVdLnNlZyA9IHNlZzsKKworICAgICAgICAgICAgICAg
IGlvYXBpY19zYmRmW3NwZWNpYWwtPmhhbmRsZV0ucGluX3NldHVwID0geHph
bGxvY19hcnJheSgKKyAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9u
ZywgQklUU19UT19MT05HUyhucl9pb2FwaWNfZW50cmllc1thcGljXSkpOwor
ICAgICAgICAgICAgICAgIGlmICggbnJfaW9hcGljX2VudHJpZXNbYXBpY10g
JiYKKyAgICAgICAgICAgICAgICAgICAgICFpb2FwaWNfc2JkZltJT19BUElD
X0lEKGFwaWMpXS5waW5fc2V0dXAgKQorICAgICAgICAgICAgICAgIHsKKyAg
ICAgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIklWSEQgRXJy
b3I6IE91dCBvZiBtZW1vcnlcbiIpOworICAgICAgICAgICAgICAgICAgICBy
ZXR1cm4gMDsKKyAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICB9Cisg
ICAgICAgICAgICBicmVhazsKKyAgICAgICAgfQorICAgICAgICBpZiAoIGFw
aWMgPT0gbnJfaW9hcGljcyApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9yOiBJbnZhbGlkIElPLUFQSUMg
JSN4XG4iLAorICAgICAgICAgICAgICAgICAgIHNwZWNpYWwtPmhhbmRsZSk7
CisgICAgICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgfQogICAgICAgICBi
cmVhazsKICAgICBjYXNlIEFDUElfSVZIRF9IUEVUOgogICAgICAgICAvKiBz
ZXQgZGV2aWNlIGlkIG9mIGhwZXQgKi8KQEAgLTg0NCw2ICs4OTAsNyBAQCBz
dGF0aWMgaW50IF9faW5pdCBwYXJzZV9pdnJzX3RhYmxlKHN0cnVjCiB7CiAg
ICAgY29uc3Qgc3RydWN0IGFjcGlfaXZyc19oZWFkZXIgKml2cnNfYmxvY2s7
CiAgICAgdW5zaWduZWQgbG9uZyBsZW5ndGg7CisgICAgdW5zaWduZWQgaW50
IGFwaWM7CiAgICAgaW50IGVycm9yID0gMDsKIAogICAgIEJVR19PTighdGFi
bGUpOwpAQCAtODc2LDYgKzkyMywyOSBAQCBzdGF0aWMgaW50IF9faW5pdCBw
YXJzZV9pdnJzX3RhYmxlKHN0cnVjCiAgICAgICAgIGxlbmd0aCArPSBpdnJz
X2Jsb2NrLT5sZW5ndGg7CiAgICAgfQogCisgICAgLyogRWFjaCBJTy1BUElD
IG11c3QgaGF2ZSBiZWVuIG1lbnRpb25lZCBpbiB0aGUgdGFibGUuICovCisg
ICAgZm9yICggYXBpYyA9IDA7ICFlcnJvciAmJiBhcGljIDwgbnJfaW9hcGlj
czsgKythcGljICkKKyAgICB7CisgICAgICAgIGlmICggIW5yX2lvYXBpY19l
bnRyaWVzW2FwaWNdIHx8CisgICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9f
QVBJQ19JRChhcGljKV0ucGluX3NldHVwICkKKyAgICAgICAgICAgIGNvbnRp
bnVlOworCisgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJJVkhEIEVycm9y
OiBubyBpbmZvcm1hdGlvbiBmb3IgSU8tQVBJQyAlI3hcbiIsCisgICAgICAg
ICAgICAgICBJT19BUElDX0lEKGFwaWMpKTsKKyAgICAgICAgaWYgKCBhbWRf
aW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAgICAgICAgICAgIGVycm9yID0g
LUVOWElPOworICAgICAgICBlbHNlCisgICAgICAgIHsKKyAgICAgICAgICAg
IGlvYXBpY19zYmRmW0lPX0FQSUNfSUQoYXBpYyldLnBpbl9zZXR1cCA9IHh6
YWxsb2NfYXJyYXkoCisgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZywg
QklUU19UT19MT05HUyhucl9pb2FwaWNfZW50cmllc1thcGljXSkpOworICAg
ICAgICAgICAgaWYgKCAhaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0u
cGluX3NldHVwICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBw
cmludGsoWEVOTE9HX0VSUiAiSVZIRCBFcnJvcjogT3V0IG9mIG1lbW9yeVxu
Iik7CisgICAgICAgICAgICAgICAgZXJyb3IgPSAtRU5PTUVNOworICAgICAg
ICAgICAgfQorICAgICAgICB9CisgICAgfQorCiAgICAgcmV0dXJuIGVycm9y
OwogfQogCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9pbml0LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lv
bW11X2luaXQuYwpAQCAtMTEyMCwxMiArMTEyMCw0NSBAQCBzdGF0aWMgaW50
IF9faW5pdCBhbWRfaW9tbXVfc2V0dXBfZGV2aWNlCiAgICAgcmV0dXJuIDA7
CiB9CiAKKy8qIENoZWNrIHdoZXRoZXIgU1A1MTAwIFNBVEEgQ29tYmluZWQg
bW9kZSBpcyBvbiAqLworc3RhdGljIGJvb2xfdCBfX2luaXQgYW1kX3NwNTEw
MF9lcnJhdHVtMjgodm9pZCkKK3sKKyAgICB1MzIgYnVzLCBpZDsKKyAgICB1
MTYgdmVuZG9yX2lkLCBkZXZfaWQ7CisgICAgdTggYnl0ZTsKKworICAgIGZv
ciAoYnVzID0gMDsgYnVzIDwgMjU2OyBidXMrKykKKyAgICB7CisgICAgICAg
IGlkID0gcGNpX2NvbmZfcmVhZDMyKDAsIGJ1cywgMHgxNCwgMCwgUENJX1ZF
TkRPUl9JRCk7CisKKyAgICAgICAgdmVuZG9yX2lkID0gaWQgJiAweGZmZmY7
CisgICAgICAgIGRldl9pZCA9IChpZCA+PiAxNikgJiAweGZmZmY7CisKKyAg
ICAgICAgLyogU1A1MTAwIFNNQnVzIG1vZHVsZSBzZXRzIENvbWJpbmVkIG1v
ZGUgb24gKi8KKyAgICAgICAgaWYgKHZlbmRvcl9pZCAhPSAweDEwMDIgfHwg
ZGV2X2lkICE9IDB4NDM4NSkKKyAgICAgICAgICAgIGNvbnRpbnVlOworCisg
ICAgICAgIGJ5dGUgPSBwY2lfY29uZl9yZWFkOCgwLCBidXMsIDB4MTQsIDAs
IDB4YWQpOworICAgICAgICBpZiAoIChieXRlID4+IDMpICYgMSApCisgICAg
ICAgIHsKKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiQU1E
LVZpOiBTUDUxMDAgZXJyYXR1bSAyOCBkZXRlY3RlZCwgZGlzYWJsaW5nIElP
TU1VLlxuIgorICAgICAgICAgICAgICAgICAgICJJZiBwb3NzaWJsZSwgZGlz
YWJsZSBTQVRBIENvbWJpbmVkIG1vZGUgaW4gQklPUyBvciBjb250YWN0IHlv
dXIgdmVuZG9yIGZvciBCSU9TIHVwZGF0ZS5cbiIpOworICAgICAgICAgICAg
cmV0dXJuIDE7CisgICAgICAgIH0KKyAgICB9CisKKyAgICByZXR1cm4gMDsK
K30KKwogaW50IF9faW5pdCBhbWRfaW9tbXVfaW5pdCh2b2lkKQogewogICAg
IHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11OwogCiAgICAgQlVHX09OKCAhaW9t
bXVfZm91bmQoKSApOwogCisgICAgaWYgKCBhbWRfaW9tbXVfcGVyZGV2X2lu
dHJlbWFwICYmIGFtZF9zcDUxMDBfZXJyYXR1bTI4KCkgKQorICAgICAgICBn
b3RvIGVycm9yX291dDsKKwogICAgIGl2cnNfYmRmX2VudHJpZXMgPSBhbWRf
aW9tbXVfZ2V0X2l2cnNfZGV2X2VudHJpZXMoKTsKIAogICAgIGlmICggIWl2
cnNfYmRmX2VudHJpZXMgKQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3Vn
aC9hbWQvaW9tbXVfaW50ci5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL2FtZC9pb21tdV9pbnRyLmMKQEAgLTEwMCwxMiArMTAwLDEyIEBAIHN0
YXRpYyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeSh1MzIqIGUKIHN0YXRp
YyB2b2lkIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lvYXBpYygKICAg
ICBpbnQgYmRmLAogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11LAotICAg
IHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICppb2FwaWNfcnRlKQorICAg
IGNvbnN0IHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICpydGUsCisgICAg
Y29uc3Qgc3RydWN0IElPX0FQSUNfcm91dGVfZW50cnkgKm9sZF9ydGUpCiB7
CiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsKICAgICB1MzIqIGVudHJ5Owog
ICAgIHU4IGRlbGl2ZXJ5X21vZGUsIGRlc3QsIHZlY3RvciwgZGVzdF9tb2Rl
OwotICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5ICpydGUgPSBpb2Fw
aWNfcnRlOwogICAgIGludCByZXFfaWQ7CiAgICAgc3BpbmxvY2tfdCAqbG9j
azsKICAgICBpbnQgb2Zmc2V0OwpAQCAtMTIxLDYgKzEyMSwxNCBAQCBzdGF0
aWMgdm9pZCB1cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9pCiAgICAgc3Bp
bl9sb2NrX2lycXNhdmUobG9jaywgZmxhZ3MpOwogCiAgICAgb2Zmc2V0ID0g
Z2V0X2ludHJlbWFwX29mZnNldCh2ZWN0b3IsIGRlbGl2ZXJ5X21vZGUpOwor
ICAgIGlmICggb2xkX3J0ZSApCisgICAgeworICAgICAgICBpbnQgb2xkX29m
ZnNldCA9IGdldF9pbnRyZW1hcF9vZmZzZXQob2xkX3J0ZS0+dmVjdG9yLAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
b2xkX3J0ZS0+ZGVsaXZlcnlfbW9kZSk7CisKKyAgICAgICAgaWYgKCBvZmZz
ZXQgIT0gb2xkX29mZnNldCApCisgICAgICAgICAgICBmcmVlX2ludHJlbWFw
X2VudHJ5KGlvbW11LT5zZWcsIGJkZiwgb2xkX29mZnNldCk7CisgICAgfQog
ICAgIGVudHJ5ID0gKHUzMiopZ2V0X2ludHJlbWFwX2VudHJ5KGlvbW11LT5z
ZWcsIHJlcV9pZCwgb2Zmc2V0KTsKICAgICB1cGRhdGVfaW50cmVtYXBfZW50
cnkoZW50cnksIHZlY3RvciwgZGVsaXZlcnlfbW9kZSwgZGVzdF9tb2RlLCBk
ZXN0KTsKIApAQCAtMTg5LDYgKzE5Nyw3IEBAIGludCBfX2luaXQgYW1kX2lv
bW11X3NldHVwX2lvYXBpY19yZW1hcHAKICAgICAgICAgICAgICAgICBhbWRf
aW9tbXVfZmx1c2hfaW50cmVtYXAoaW9tbXUsIHJlcV9pZCk7CiAgICAgICAg
ICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUtPmxvY2ss
IGZsYWdzKTsKICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIHNldF9iaXQo
cGluLCBpb2FwaWNfc2JkZltJT19BUElDX0lEKGFwaWMpXS5waW5fc2V0dXAp
OwogICAgICAgICB9CiAgICAgfQogICAgIHJldHVybiAwOwpAQCAtMjAwLDYg
KzIwOSw3IEBAIHZvaWQgYW1kX2lvbW11X2lvYXBpY191cGRhdGVfaXJlKAog
ICAgIHN0cnVjdCBJT19BUElDX3JvdXRlX2VudHJ5IG9sZF9ydGUgPSB7IDAg
fTsKICAgICBzdHJ1Y3QgSU9fQVBJQ19yb3V0ZV9lbnRyeSBuZXdfcnRlID0g
eyAwIH07CiAgICAgdW5zaWduZWQgaW50IHJ0ZV9sbyA9IChyZWcgJiAxKSA/
IHJlZyAtIDEgOiByZWc7CisgICAgdW5zaWduZWQgaW50IHBpbiA9IChyZWcg
LSAweDEwKSAvIDI7CiAgICAgaW50IHNhdmVkX21hc2ssIHNlZywgYmRmOwog
ICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11OwogCkBAIC0yMzcsNiArMjQ3
LDE0IEBAIHZvaWQgYW1kX2lvbW11X2lvYXBpY191cGRhdGVfaXJlKAogICAg
ICAgICAqKCgodTMyICopJm5ld19ydGUpICsgMSkgPSB2YWx1ZTsKICAgICB9
CiAKKyAgICBpZiAoIG5ld19ydGUubWFzayAmJgorICAgICAgICAgIXRlc3Rf
Yml0KHBpbiwgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0ucGluX3Nl
dHVwKSApCisgICAgeworICAgICAgICBBU1NFUlQoc2F2ZWRfbWFzayk7Cisg
ICAgICAgIF9faW9fYXBpY193cml0ZShhcGljLCByZWcsIHZhbHVlKTsKKyAg
ICAgICAgcmV0dXJuOworICAgIH0KKwogICAgIC8qIG1hc2sgdGhlIGludGVy
cnVwdCB3aGlsZSB3ZSBjaGFuZ2UgdGhlIGludHJlbWFwIHRhYmxlICovCiAg
ICAgaWYgKCAhc2F2ZWRfbWFzayApCiAgICAgewpAQCAtMjQ1LDcgKzI2Mywx
MSBAQCB2b2lkIGFtZF9pb21tdV9pb2FwaWNfdXBkYXRlX2lyZSgKICAgICB9
CiAKICAgICAvKiBVcGRhdGUgaW50ZXJydXB0IHJlbWFwcGluZyBlbnRyeSAq
LwotICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX2lvYXBpYyhiZGYs
IGlvbW11LCAmbmV3X3J0ZSk7CisgICAgdXBkYXRlX2ludHJlbWFwX2VudHJ5
X2Zyb21faW9hcGljKAorICAgICAgICBiZGYsIGlvbW11LCAmbmV3X3J0ZSwK
KyAgICAgICAgdGVzdF9hbmRfc2V0X2JpdChwaW4sCisgICAgICAgICAgICAg
ICAgICAgICAgICAgaW9hcGljX3NiZGZbSU9fQVBJQ19JRChhcGljKV0ucGlu
X3NldHVwKSA/ICZvbGRfcnRlCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IE5V
TEwpOwogCiAgICAgLyogRm9yd2FyZCB3cml0ZSBhY2Nlc3MgdG8gSU8tQVBJ
QyBSVEUgKi8KICAgICBfX2lvX2FwaWNfd3JpdGUoYXBpYywgcmVnLCB2YWx1
ZSk7CkBAIC0zNTYsNiArMzc4LDEyIEBAIHZvaWQgYW1kX2lvbW11X21zaV9t
c2dfdXBkYXRlX2lyZSgKICAgICAgICAgcmV0dXJuOwogICAgIH0KIAorICAg
IGlmICggbXNpX2Rlc2MtPnJlbWFwX2luZGV4ID49IDAgKQorICAgICAgICB1
cGRhdGVfaW50cmVtYXBfZW50cnlfZnJvbV9tc2lfbXNnKGlvbW11LCBiZGYs
IG1zaV9kZXNjLCBOVUxMKTsKKworICAgIGlmICggIW1zZyApCisgICAgICAg
IHJldHVybjsKKwogICAgIHVwZGF0ZV9pbnRyZW1hcF9lbnRyeV9mcm9tX21z
aV9tc2coaW9tbXUsIGJkZiwgbXNpX2Rlc2MsIG1zZyk7CiB9CiAKLS0tIGEv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRfaW9tbXUuYwor
KysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvcGNpX2FtZF9pb21t
dS5jCkBAIC0yMDgsNiArMjA4LDggQEAgaW50IF9faW5pdCBhbWRfaW92X2Rl
dGVjdCh2b2lkKQogICAgIHsKICAgICAgICAgcHJpbnRrKCJBTUQtVmk6IE5v
dCBvdmVycmlkaW5nIGlycV92ZWN0b3JfbWFwIHNldHRpbmdcbiIpOwogICAg
IH0KKyAgICBpZiAoICFhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFwICkKKyAg
ICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJBTUQtVmk6IFVzaW5nIGds
b2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUgaXMgbm90IHJlY29tbWVuZGVk
IChzZWUgWFNBLTM2KSFcbiIpOwogICAgIHJldHVybiBzY2FuX3BjaV9kZXZp
Y2VzKCk7CiB9CiAKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvaW9t
bXUuYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9pb21tdS5jCkBA
IC01Myw3ICs1Myw3IEBAIGJvb2xfdCBfX3JlYWRfbW9zdGx5IGlvbW11X3Fp
bnZhbCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21tdV9pbnRyZW1h
cCA9IDE7CiBib29sX3QgX19yZWFkX21vc3RseSBpb21tdV9oYXBfcHRfc2hh
cmUgPSAxOwogYm9vbF90IF9fcmVhZF9tb3N0bHkgaW9tbXVfZGVidWc7Ci1i
b29sX3QgX19yZWFkX21vc3RseSBhbWRfaW9tbXVfcGVyZGV2X2ludHJlbWFw
OworYm9vbF90IF9fcmVhZF9tb3N0bHkgYW1kX2lvbW11X3BlcmRldl9pbnRy
ZW1hcCA9IDE7CiAKIERFRklORV9QRVJfQ1BVKGJvb2xfdCwgaW9tbXVfZG9u
dF9mbHVzaF9pb3RsYik7CiAKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9o
dm0vc3ZtL2FtZC1pb21tdS1wcm90by5oCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS14ODYvaHZtL3N2bS9hbWQtaW9tbXUtcHJvdG8uaApAQCAtMTAxLDYgKzEw
MSw3IEBAIGludCBhbWRfc2V0dXBfaHBldF9tc2koc3RydWN0IG1zaV9kZXNj
ICoKIAogZXh0ZXJuIHN0cnVjdCBpb2FwaWNfc2JkZiB7CiAgICAgdTE2IGJk
Ziwgc2VnOworICAgIHVuc2lnbmVkIGxvbmcgKnBpbl9zZXR1cDsKIH0gaW9h
cGljX3NiZGZbTUFYX0lPX0FQSUNTXTsKIGV4dGVybiB2b2lkICpzaGFyZWRf
aW50cmVtYXBfdGFibGU7CiAK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Thu Feb 21 14:28:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8X82-0004mU-G9; Thu, 21 Feb 2013 14:28:06 +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 1U8X80-0004mC-AZ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:28:04 +0000
Received: from [85.158.139.83:38512] by server-13.bemta-5.messagelabs.com id
	BB/E6-06769-3FE26215; Thu, 21 Feb 2013 14:28:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361456882!28300612!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26283 invoked from network); 21 Feb 2013 14:28:02 -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; 21 Feb 2013 14:28:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 14:28:01 +0000
Message-Id: <51263D3C02000078000BFFB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 14:29:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1361456469-16406-1-git-send-email-tim@xen.org>
In-Reply-To: <1361456469-16406-1-git-send-email-tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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

>>> On 21.02.13 at 15:21, Tim Deegan <tim@xen.org> wrote:
> The reworking of p2m lookups to use get_gfn()/put_gfn() left the
> shadow code not taking the p2m lock, even in cases where the p2m would
> be updated (i.e. PoD).
> 
> In many cases, shadow code doesn't need the exclusion that
> get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
> updates, but this is taking things too far, and can lead to crashes in
> the PoD code.
> 
> Now that most shadow-code p2m lookups are done with explicitly
> unlocked accessors, or with the get_page_from_gfn() accessor, which is
> often lock-free, we can just turn this locking on.
> 
> The remaining locked lookups are in sh_page_fault() (in a path that's
> almost always already serializing on the paging lock), and in
> emulate_map_dest() (which can probably be updated to use
> get_page_from_gfn()).  They're not addressed here but may be in a
> follow-up patch.

I assume once coming out of stage testing, this also needs to be
put into 4.2?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:28:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8X82-0004mU-G9; Thu, 21 Feb 2013 14:28:06 +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 1U8X80-0004mC-AZ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:28:04 +0000
Received: from [85.158.139.83:38512] by server-13.bemta-5.messagelabs.com id
	BB/E6-06769-3FE26215; Thu, 21 Feb 2013 14:28:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361456882!28300612!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26283 invoked from network); 21 Feb 2013 14:28:02 -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; 21 Feb 2013 14:28:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 14:28:01 +0000
Message-Id: <51263D3C02000078000BFFB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 14:29:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <1361456469-16406-1-git-send-email-tim@xen.org>
In-Reply-To: <1361456469-16406-1-git-send-email-tim@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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

>>> On 21.02.13 at 15:21, Tim Deegan <tim@xen.org> wrote:
> The reworking of p2m lookups to use get_gfn()/put_gfn() left the
> shadow code not taking the p2m lock, even in cases where the p2m would
> be updated (i.e. PoD).
> 
> In many cases, shadow code doesn't need the exclusion that
> get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
> updates, but this is taking things too far, and can lead to crashes in
> the PoD code.
> 
> Now that most shadow-code p2m lookups are done with explicitly
> unlocked accessors, or with the get_page_from_gfn() accessor, which is
> often lock-free, we can just turn this locking on.
> 
> The remaining locked lookups are in sh_page_fault() (in a path that's
> almost always already serializing on the paging lock), and in
> emulate_map_dest() (which can probably be updated to use
> get_page_from_gfn()).  They're not addressed here but may be in a
> follow-up patch.

I assume once coming out of stage testing, this also needs to be
put into 4.2?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:33:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XCs-0005Gg-8c; Thu, 21 Feb 2013 14:33:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1U8XCq-0005GV-LT
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:33:04 +0000
Received: from [85.158.139.83:39804] by server-10.bemta-5.messagelabs.com id
	F8/8B-04697-F1036215; Thu, 21 Feb 2013 14:33:03 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361457174!24356673!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDY5MzQgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1840 invoked from network); 21 Feb 2013 14:32:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 14:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; d="asc'?scan'208";a="1736412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 14:32: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.297.1;
	Thu, 21 Feb 2013 14:32:49 +0000
Message-ID: <1361457167.21412.16.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 15:32:47 +0100
In-Reply-To: <51262710.5030703@eu.citrix.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
	<51262710.5030703@eu.citrix.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>, Dan
	Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9170259956389776086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9170259956389776086==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-3SwkCPLeHlR+hQcaBXGv"

--=-3SwkCPLeHlR+hQcaBXGv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-21 at 13:54 +0000, George Dunlap wrote:
> On 02/18/2013 05:13 PM, Dario Faggioli wrote:
> > On Fri, 2013-02-01 at 12:01 +0100, Dario Faggioli wrote:
> >> Hello Everyone,
> >>
> >> V3 of the NUMA aware scheduling series. It is nothing more than v2 wit=
h all
> >> the review comments I got, addressed... Or so I think. :-)
> >>
> > Ping?
>=20
> Sorry Dario -- this is my first priority as soon as I clear the stuff=20
> off my desk that has accumulated while I was away in Oman. :-)
>=20
No need to be sorry, I perfectly understand, and am not in a hurry. The=20
'ping' wasn't meant at "having the review right away", it was more about
"having it at some point".

Take the time it takes. :-)

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-3SwkCPLeHlR+hQcaBXGv
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)

iEYEABECAAYFAlEmMA8ACgkQk4XaBE3IOsRg/QCfYoVpbdfujMhw6e6dwGI94KPv
GggAnjybrHDrsyCzmgTuLxRkcH+hwb9Q
=nSyP
-----END PGP SIGNATURE-----

--=-3SwkCPLeHlR+hQcaBXGv--


--===============9170259956389776086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9170259956389776086==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 14:33:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XCs-0005Gg-8c; Thu, 21 Feb 2013 14:33:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1U8XCq-0005GV-LT
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:33:04 +0000
Received: from [85.158.139.83:39804] by server-10.bemta-5.messagelabs.com id
	F8/8B-04697-F1036215; Thu, 21 Feb 2013 14:33:03 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361457174!24356673!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDY5MzQgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1840 invoked from network); 21 Feb 2013 14:32:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 14:32:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,709,1355097600"; d="asc'?scan'208";a="1736412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 14:32: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.297.1;
	Thu, 21 Feb 2013 14:32:49 +0000
Message-ID: <1361457167.21412.16.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 15:32:47 +0100
In-Reply-To: <51262710.5030703@eu.citrix.com>
References: <patchbomb.1359716470@Solace> <1361207601.31175.6.camel@Solace>
	<51262710.5030703@eu.citrix.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>, Dan
	Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 00 of 11 v3] NUMA aware credit scheduling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9170259956389776086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9170259956389776086==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-3SwkCPLeHlR+hQcaBXGv"

--=-3SwkCPLeHlR+hQcaBXGv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2013-02-21 at 13:54 +0000, George Dunlap wrote:
> On 02/18/2013 05:13 PM, Dario Faggioli wrote:
> > On Fri, 2013-02-01 at 12:01 +0100, Dario Faggioli wrote:
> >> Hello Everyone,
> >>
> >> V3 of the NUMA aware scheduling series. It is nothing more than v2 wit=
h all
> >> the review comments I got, addressed... Or so I think. :-)
> >>
> > Ping?
>=20
> Sorry Dario -- this is my first priority as soon as I clear the stuff=20
> off my desk that has accumulated while I was away in Oman. :-)
>=20
No need to be sorry, I perfectly understand, and am not in a hurry. The=20
'ping' wasn't meant at "having the review right away", it was more about
"having it at some point".

Take the time it takes. :-)

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-3SwkCPLeHlR+hQcaBXGv
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)

iEYEABECAAYFAlEmMA8ACgkQk4XaBE3IOsRg/QCfYoVpbdfujMhw6e6dwGI94KPv
GggAnjybrHDrsyCzmgTuLxRkcH+hwb9Q
=nSyP
-----END PGP SIGNATURE-----

--=-3SwkCPLeHlR+hQcaBXGv--


--===============9170259956389776086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9170259956389776086==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 14:33:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:33: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 1U8XD0-0005IB-MB; Thu, 21 Feb 2013 14:33:14 +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 1U8XCy-0005Hn-RK
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:33:12 +0000
Received: from [85.158.138.51:27126] by server-10.bemta-3.messagelabs.com id
	AC/C9-10609-32036215; Thu, 21 Feb 2013 14:33:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361457181!22229049!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16687 invoked from network); 21 Feb 2013 14:33:05 -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; 21 Feb 2013 14:33:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XCn-0007BV-9d; Thu, 21 Feb 2013 14:33:01 +0000
Date: Thu, 21 Feb 2013 14:33:01 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221143301.GL24051@ocelot.phlegethon.org>
References: <1361456469-16406-1-git-send-email-tim@xen.org>
	<51263D3C02000078000BFFB5@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51263D3C02000078000BFFB5@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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 14:29 +0000 on 21 Feb (1361456940), Jan Beulich wrote:
> >>> On 21.02.13 at 15:21, Tim Deegan <tim@xen.org> wrote:
> > The reworking of p2m lookups to use get_gfn()/put_gfn() left the
> > shadow code not taking the p2m lock, even in cases where the p2m would
> > be updated (i.e. PoD).
> > 
> > In many cases, shadow code doesn't need the exclusion that
> > get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
> > updates, but this is taking things too far, and can lead to crashes in
> > the PoD code.
> > 
> > Now that most shadow-code p2m lookups are done with explicitly
> > unlocked accessors, or with the get_page_from_gfn() accessor, which is
> > often lock-free, we can just turn this locking on.
> > 
> > The remaining locked lookups are in sh_page_fault() (in a path that's
> > almost always already serializing on the paging lock), and in
> > emulate_map_dest() (which can probably be updated to use
> > get_page_from_gfn()).  They're not addressed here but may be in a
> > follow-up patch.
> 
> I assume once coming out of stage testing, this also needs to be
> put into 4.2?

Yes, sorry I forgot to mention it.  Definitely a candidate for 4.2

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:33:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:33: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 1U8XD0-0005IB-MB; Thu, 21 Feb 2013 14:33:14 +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 1U8XCy-0005Hn-RK
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:33:12 +0000
Received: from [85.158.138.51:27126] by server-10.bemta-3.messagelabs.com id
	AC/C9-10609-32036215; Thu, 21 Feb 2013 14:33:07 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361457181!22229049!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16687 invoked from network); 21 Feb 2013 14:33:05 -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; 21 Feb 2013 14:33:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XCn-0007BV-9d; Thu, 21 Feb 2013 14:33:01 +0000
Date: Thu, 21 Feb 2013 14:33:01 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221143301.GL24051@ocelot.phlegethon.org>
References: <1361456469-16406-1-git-send-email-tim@xen.org>
	<51263D3C02000078000BFFB5@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51263D3C02000078000BFFB5@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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 14:29 +0000 on 21 Feb (1361456940), Jan Beulich wrote:
> >>> On 21.02.13 at 15:21, Tim Deegan <tim@xen.org> wrote:
> > The reworking of p2m lookups to use get_gfn()/put_gfn() left the
> > shadow code not taking the p2m lock, even in cases where the p2m would
> > be updated (i.e. PoD).
> > 
> > In many cases, shadow code doesn't need the exclusion that
> > get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
> > updates, but this is taking things too far, and can lead to crashes in
> > the PoD code.
> > 
> > Now that most shadow-code p2m lookups are done with explicitly
> > unlocked accessors, or with the get_page_from_gfn() accessor, which is
> > often lock-free, we can just turn this locking on.
> > 
> > The remaining locked lookups are in sh_page_fault() (in a path that's
> > almost always already serializing on the paging lock), and in
> > emulate_map_dest() (which can probably be updated to use
> > get_page_from_gfn()).  They're not addressed here but may be in a
> > follow-up patch.
> 
> I assume once coming out of stage testing, this also needs to be
> put into 4.2?

Yes, sorry I forgot to mention it.  Definitely a candidate for 4.2

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:43:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:43: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 1U8XMO-00068Q-Qj; Thu, 21 Feb 2013 14:42:56 +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 1U8XMN-00068C-1g
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:42:55 +0000
Received: from [85.158.139.83:13507] by server-2.bemta-5.messagelabs.com id
	E6/18-16911-E6236215; Thu, 21 Feb 2013 14:42:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361457773!20962196!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11989 invoked from network); 21 Feb 2013 14:42:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-182.messagelabs.com with SMTP;
	21 Feb 2013 14:42:53 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (josoe mo34) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04acap1LDhFnj ;
	Thu, 21 Feb 2013 15:42:47 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 4445D1884C; Thu, 21 Feb 2013 15:42:47 +0100 (CET)
Date: Thu, 21 Feb 2013 15:42:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221144247.GA23819@aepfle.de>
References: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Tim Deegan <tim@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] x86/nhvm: properly clean up after
 failure to set up all vCPU-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 Thu, Feb 21, Jan Beulich wrote:

> Otherwise we may leak memory when setting up nHVM fails half way.
> 
> This implies that the individual destroy functions will have to remain
> capable (in the VMX case they first need to be made so, following
> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> that the corresponding init function was never run on.
> 
> Once at it, also remove a redundant check from the corresponding
> parameter validation code.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Tested-by: Olaf Hering <olaf@aepfle.de>


This one fixes the crash as well. Thanks.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:43:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:43: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 1U8XMO-00068Q-Qj; Thu, 21 Feb 2013 14:42:56 +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 1U8XMN-00068C-1g
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:42:55 +0000
Received: from [85.158.139.83:13507] by server-2.bemta-5.messagelabs.com id
	E6/18-16911-E6236215; Thu, 21 Feb 2013 14:42:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361457773!20962196!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTQ0NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11989 invoked from network); 21 Feb 2013 14:42:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-182.messagelabs.com with SMTP;
	21 Feb 2013 14:42:53 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (josoe mo34) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04acap1LDhFnj ;
	Thu, 21 Feb 2013 15:42:47 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 4445D1884C; Thu, 21 Feb 2013 15:42:47 +0100 (CET)
Date: Thu, 21 Feb 2013 15:42:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221144247.GA23819@aepfle.de>
References: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51262DB302000078000BFF3D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Tim Deegan <tim@xen.org>, Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v3] x86/nhvm: properly clean up after
 failure to set up all vCPU-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 Thu, Feb 21, Jan Beulich wrote:

> Otherwise we may leak memory when setting up nHVM fails half way.
> 
> This implies that the individual destroy functions will have to remain
> capable (in the VMX case they first need to be made so, following
> 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU
> that the corresponding init function was never run on.
> 
> Once at it, also remove a redundant check from the corresponding
> parameter validation code.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Tested-by: Olaf Hering <olaf@aepfle.de>


This one fixes the crash as well. Thanks.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:48:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XS1-0006Xe-QX; Thu, 21 Feb 2013 14:48:45 +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 1U8XS0-0006XT-E0
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:48:44 +0000
Received: from [85.158.138.51:39312] by server-4.bemta-3.messagelabs.com id
	B0/F6-17521-BC336215; Thu, 21 Feb 2013 14:48:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361458122!24528779!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTA3NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTA3NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9851 invoked from network); 21 Feb 2013 14:48:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 14:48:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (joses mo18) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 5017b6p1LDxC3G
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 15:48:42 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 92E581884C; Thu, 21 Feb 2013 15:48:41 +0100 (CET)
Date: Thu, 21 Feb 2013 15:48:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130221144841.GB23819@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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


While doing "while xm migrate --live domU localhost;do sleep 2;done" I
see many errors from get_page:

...
(XEN) HVM56 restore: TSC_ADJUST 0
(XEN) HVM56 restore: TSC_ADJUST 1
(XEN) mm.c:1982:d0 Error pfn 41a863: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41be1c: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41a862: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41b90f: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41b49a: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41b48d: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) irq.c:375: Dom56 callback via changed to Direct Vector 0xf3
(XEN) HVM56 save: CPU
...

The pfn number and the amount of pfn differs during iterations, but in the end
only these two variants appear:

# xm dmesg | grep -w mm | cut -d : -f 4- | sort | uniq -c | sort
     22  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
     46  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001


It does not seem to cause issues other than the log output.
Does it indiciate a real bug?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:48:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XS1-0006Xe-QX; Thu, 21 Feb 2013 14:48:45 +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 1U8XS0-0006XT-E0
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:48:44 +0000
Received: from [85.158.138.51:39312] by server-4.bemta-3.messagelabs.com id
	B0/F6-17521-BC336215; Thu, 21 Feb 2013 14:48:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361458122!24528779!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTA3NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTA3NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9851 invoked from network); 21 Feb 2013 14:48:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 14:48:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (joses mo18) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 5017b6p1LDxC3G
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 15:48:42 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 92E581884C; Thu, 21 Feb 2013 15:48:41 +0100 (CET)
Date: Thu, 21 Feb 2013 15:48:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20130221144841.GB23819@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Subject: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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


While doing "while xm migrate --live domU localhost;do sleep 2;done" I
see many errors from get_page:

...
(XEN) HVM56 restore: TSC_ADJUST 0
(XEN) HVM56 restore: TSC_ADJUST 1
(XEN) mm.c:1982:d0 Error pfn 41a863: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41be1c: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41a862: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41b90f: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41b49a: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1982:d0 Error pfn 41b48d: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) irq.c:375: Dom56 callback via changed to Direct Vector 0xf3
(XEN) HVM56 save: CPU
...

The pfn number and the amount of pfn differs during iterations, but in the end
only these two variants appear:

# xm dmesg | grep -w mm | cut -d : -f 4- | sort | uniq -c | sort
     22  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
     46  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001


It does not seem to cause issues other than the log output.
Does it indiciate a real bug?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:55:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XXr-0006qR-IC; Thu, 21 Feb 2013 14:54: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 1U8XXp-0006q6-Es
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:54:45 +0000
Received: from [193.109.254.147:28672] by server-15.bemta-14.messagelabs.com
	id FA/17-24599-43536215; Thu, 21 Feb 2013 14:54:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361458482!1954369!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15867 invoked from network); 21 Feb 2013 14:54:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:54:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 14:54:42 +0000
Message-Id: <5126437D02000078000C0006@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 14:55:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir\(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> If any committer needs help getting git to work please feel free to
> ask.  git has many advantages but its user interface has received very
> mixed reviews.  We appreciate that you might need handholding.  So if
> you get confused, or into trouble, do consult.

So one thing I found very handy with hg was that there was a
single line history with easy to look at changeset numbers. Is there
any way to achieve the same with git? I'm asking particularly in the
context of backporting: In order to pick changes from unstable (now
master), so far I simply scanned the history, tracking (on a sheet of
paper) at which c/s I last left off.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:55:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XXr-0006qR-IC; Thu, 21 Feb 2013 14:54: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 1U8XXp-0006q6-Es
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:54:45 +0000
Received: from [193.109.254.147:28672] by server-15.bemta-14.messagelabs.com
	id FA/17-24599-43536215; Thu, 21 Feb 2013 14:54:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361458482!1954369!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15867 invoked from network); 21 Feb 2013 14:54:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:54:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 14:54:42 +0000
Message-Id: <5126437D02000078000C0006@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 14:55:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir\(Xen.org\)" <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> If any committer needs help getting git to work please feel free to
> ask.  git has many advantages but its user interface has received very
> mixed reviews.  We appreciate that you might need handholding.  So if
> you get confused, or into trouble, do consult.

So one thing I found very handy with hg was that there was a
single line history with easy to look at changeset numbers. Is there
any way to achieve the same with git? I'm asking particularly in the
context of backporting: In order to pick changes from unstable (now
master), so far I simply scanned the history, tracking (on a sheet of
paper) at which c/s I last left off.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 14:57:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8Xa1-00074I-AT; Thu, 21 Feb 2013 14:57: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 1U8Xa0-000748-Ap
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:57:00 +0000
Received: from [193.109.254.147:40466] by server-1.bemta-14.messagelabs.com id
	25/26-29874-BB536215; Thu, 21 Feb 2013 14:56:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361458579!9179264!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 463 invoked from network); 21 Feb 2013 14:56:20 -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; 21 Feb 2013 14:56:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XUT-0007FE-SB; Thu, 21 Feb 2013 14:51:17 +0000
Date: Thu, 21 Feb 2013 14:51:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221145117.GM24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 04/46] arm: avoid inline asm for dsb, isb,
	wfi and sev.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860438), Ian Campbell wrote:
> "dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
> synonymous) on arm32 but we have a macro so lets use it.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Stefano's acked this one too.  But for good measure,
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 Thu Feb 21 14:57:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8Xa1-00074I-AT; Thu, 21 Feb 2013 14:57: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 1U8Xa0-000748-Ap
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:57:00 +0000
Received: from [193.109.254.147:40466] by server-1.bemta-14.messagelabs.com id
	25/26-29874-BB536215; Thu, 21 Feb 2013 14:56:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361458579!9179264!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 463 invoked from network); 21 Feb 2013 14:56:20 -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; 21 Feb 2013 14:56:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XUT-0007FE-SB; Thu, 21 Feb 2013 14:51:17 +0000
Date: Thu, 21 Feb 2013 14:51:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221145117.GM24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 04/46] arm: avoid inline asm for dsb, isb,
	wfi and sev.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860438), Ian Campbell wrote:
> "dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
> synonymous) on arm32 but we have a macro so lets use it.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Stefano's acked this one too.  But for good measure,
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 Thu Feb 21 14:57:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:57: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 1U8XaO-00077H-O1; Thu, 21 Feb 2013 14:57:24 +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 1U8XaN-000772-Ns
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:57:23 +0000
Received: from [85.158.137.99:19888] by server-15.bemta-3.messagelabs.com id
	FC/1A-25405-EC536215; Thu, 21 Feb 2013 14:57:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361458637!12376145!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8457 invoked from network); 21 Feb 2013 14:57:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:57:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XaH-0007Go-7m; Thu, 21 Feb 2013 14:57:17 +0000
Date: Thu, 21 Feb 2013 14:57:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221145717.GO24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-8-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-8-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 08/46] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860442), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 14:57:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14:57: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 1U8XaO-00077H-O1; Thu, 21 Feb 2013 14:57:24 +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 1U8XaN-000772-Ns
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:57:23 +0000
Received: from [85.158.137.99:19888] by server-15.bemta-3.messagelabs.com id
	FC/1A-25405-EC536215; Thu, 21 Feb 2013 14:57:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361458637!12376145!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8457 invoked from network); 21 Feb 2013 14:57:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:57:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XaH-0007Go-7m; Thu, 21 Feb 2013 14:57:17 +0000
Date: Thu, 21 Feb 2013 14:57:17 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221145717.GO24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-8-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-8-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 08/46] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860442), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 14:58:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XbB-0007F7-6Y; Thu, 21 Feb 2013 14:58:13 +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 1U8Xb9-0007El-8I
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:58:11 +0000
Received: from [85.158.137.99:29084] by server-15.bemta-3.messagelabs.com id
	C0/6C-25405-20636215; Thu, 21 Feb 2013 14:58:10 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361458686!17256445!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=2.6 required=7.0 tests=BODY_DONG,HTML_30_40,
	HTML_MESSAGE,MIME_QP_LONG_LINE,SUBJ_HAS_SPACES
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22831 invoked from network); 21 Feb 2013 14:58:07 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 14:58:07 -0000
Received: by mail-ie0-f171.google.com with SMTP id 10so11372245ied.16
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 06:58:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:message-id:references:to:x-mailer:x-gm-message-state;
	bh=eR9E9bFohtNZ1nLA6gV1UwZeJ93iuCP7lf8OOnU4ktM=;
	b=IS9hkGhKNDnUIA1/xAZ49I+IJHtpyDT4DnvWLpAzubKo7lvq5XdiKwcdNF+/s9ABzR
	QUVQNSuC7V65gcVJgC56CkFIbuiXSwMkQ7ar87qjEI96A8jRSSQM2M/IEzdar8T7iZix
	bs/nh3mlQi6nX74nDPEIr3JVztffXpSIJrRWUZ/en8kxLKAaNPod867QQBlu0nX8PbS1
	Tc4maNH4qatxpr65S80cYA2zFVrnnvI2FC2TsPVSGoY4fvNItbyBo/GTCcW+AD19pgkr
	8TD+sZu9q3V9hPFRKmMik0UddJLnUhCa5D46s4+8hQKfZwlpzUuXfs1FIihBSu1DKqzJ
	1bTA==
X-Received: by 10.50.36.229 with SMTP id t5mr13062676igj.18.1361458685736;
	Thu, 21 Feb 2013 06:58:05 -0800 (PST)
Received: from [192.168.15.1] ([206.223.182.18])
	by mx.google.com with ESMTPS id ee5sm10227551igc.0.2013.02.21.06.58.02
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 06:58:03 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 09:58:09 -0500
Message-Id: <A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmG5bGa/eE2FRw5RUYcl//QQ8nSTjGO1CaXuoMBfPR1AkFuevGAZfaXDMRg852UbBp69rHE
Cc: Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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: multipart/mixed; boundary="===============3980674410948419927=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3980674410948419927==
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD"


--Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> The reworking of p2m lookups to use get_gfn()/put_gfn() left the
> shadow code not taking the p2m lock, even in cases where the p2m would
> be updated (i.e. PoD).
>=20
> In many cases, shadow code doesn't need the exclusion that
> get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
> updates, but this is taking things too far, and can lead to crashes in
> the PoD code.
>=20
> Now that most shadow-code p2m lookups are done with explicitly
> unlocked accessors, or with the get_page_from_gfn() accessor, which is
> often lock-free, we can just turn this locking on.
For the record: this includes the page table walking that both the =
emulate mapping callback and page fault handler need to do.
>=20
> The remaining locked lookups are in sh_page_fault() (in a path that's
> almost always already serializing on the paging lock), and in
> emulate_map_dest() (which can probably be updated to use
> get_page_from_gfn()).
That is absolutely the case. Here is a rough patch:
diff -r 7324955b35ad xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4861,6 +4861,7 @@ static mfn_t emulate_gva_to_mfn(struct v
                                 struct sh_emulate_ctxt *sh_ctxt)
 {
     unsigned long gfn;
+    struct page_info *page;
     mfn_t mfn;
     p2m_type_t p2mt;
     uint32_t pfec =3D PFEC_page_present | PFEC_write_access;
@@ -4878,22 +4879,30 @@ static mfn_t emulate_gva_to_mfn(struct v
=20
     /* Translate the GFN to an MFN */
     ASSERT(!paging_locked_by_me(v->domain));
-    mfn =3D get_gfn(v->domain, _gfn(gfn), &p2mt);
-       =20
+    page =3D get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
+
+    /* Sanity checking */
+    if ( page =3D=3D NULL )
+    {
+        return _mfn(BAD_GFN_TO_MFN);
+    }
     if ( p2m_is_readonly(p2mt) )
     {
-        put_gfn(v->domain, gfn);
+        put_page(page);
         return _mfn(READONLY_GFN);
     }
     if ( !p2m_is_ram(p2mt) )
     {
-        put_gfn(v->domain, gfn);
+        put_page(page);
         return _mfn(BAD_GFN_TO_MFN);
     }
-
+    mfn =3D page_to_mfn(page);
     ASSERT(mfn_valid(mfn));
+
     v->arch.paging.last_write_was_pt =3D !!sh_mfn_is_a_page_table(mfn);
-    put_gfn(v->domain, gfn);
+    /* Note shadow cannot page out or unshare this mfn, so the map =
won't
+     * disappear. Otherwise, caller must hold onto page until done. */
+    put_page(page);
     return mfn;
 }
=20


>  They're not addressed here but may be in a
> follow-up patch.
>=20

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
or Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>? see =
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html

Thanks
Andres
> Signed-off-by: Tim Deegan <tim@xen.org>
> ---
> xen/arch/x86/mm/p2m.c |    6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>=20
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index de1dd82..2db73c9 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -218,8 +218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain =
*p2m, unsigned long gfn,
>         return _mfn(gfn);
>     }
>=20
> -    /* 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);
>=20
> @@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain =
*p2m, unsigned long gfn,
>=20
> void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
> {
> -    if ( !p2m || !paging_mode_translate(p2m->domain)=20
> -              || !hap_enabled(p2m->domain) )
> +    if ( !p2m || !paging_mode_translate(p2m->domain) )
>         /* Nothing to do in this case */
>         return;
>=20
> --=20
> 1.7.10.4
>=20
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 2
> Date: Thu, 21 Feb 2013 14:22:51 +0000
> From: Tim Deegan <tim@xen.org>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima
> 	<jun.nakajima@intel.com>,	xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] crash in nvmx_vcpu_destroy
> Message-ID: <20130221142251.GK24051@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=3Diso-8859-1
>=20
> At 15:19 +0100 on 21 Feb (1361459959), Olaf Hering wrote:
>> This patch fixes the crash for me. Thanks.
>=20
> Great - in that case it will be fixed by Jan's more comprehensive =
patch
> when that goes in.
>=20
> Cheers,
>=20
> Tim.
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Thu, 21 Feb 2013 14:23:31 +0000
> From: Xen.org security team <security@xen.org>
> To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
> 	xen-users@lists.xen.org, oss-security@lists.openwall.com
> Cc: "Xen.org security team" <security@xen.org>
> Subject: [Xen-devel] Xen Security Advisory 36 (CVE-2013-0153) -
> 	interrupt remap entries shared and old ones not cleared on AMD =
IOMMUs
> Message-ID: <E1U8X3b-0007ni-Cw@xenbits.xen.org>
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> 	     Xen Security Advisory CVE-2013-0153 / XSA-36
> 			      version 4
>=20
>  interrupt remap entries shared and old ones not cleared on AMD IOMMUs
>=20
> UPDATES IN VERSION 4
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Updated patches, to deal with a boot time crash resulting from the =
earlier
> changes on systems with firmware broken in a way not previously =
accounted
> for.
>=20
> ISSUE DESCRIPTION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> To avoid an erratum in early hardware, the Xen AMD IOMMU code by
> default chooses to use a single interrupt remapping table for the
> whole system.  This sharing implies that any guest with a passed
> through PCI device that is bus mastering capable can inject interrupts
> into other guests, including domain 0.
>=20
> Furthermore, regardless of whether a shared interrupt remapping table
> is in use, old entries are not always cleared, providing opportunities
> (which accumulate over time) for guests to inject interrupts into
> other guests, again including domain 0.
>=20
> In a typical Xen system many devices are owned by domain 0 or driver
> domains, leaving them vulnerable to such an attack. Such a DoS is
> likely to have an impact on other guests running in the system.
>=20
> IMPACT
> =3D=3D=3D=3D=3D=3D
>=20
> A malicious domain which is given access to a physical PCI device can
> mount a denial of service attack affecting the whole system.
>=20
> VULNERABLE SYSTEMS
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Xen versions 3.3 onwards are vulnerable.  Earlier Xen versions do not
> implement interrupt remapping, and hence do not support secure AMD-Vi
> PCI passthrough in any case.
>=20
> Only systems using AMD-Vi for PCI passthrough are vulnerable.
>=20
> Any domain which is given access to a PCI device can take advantage of
> this vulnerability.
>=20
> MITIGATION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This issue can be avoided by not assigning PCI devices to untrusted
> guests.
>=20
> In Xen versions 4.1.3 and above the sharing of the interrupt remapping
> table (and hence the more severe part of this problem) can be avoided
> by passing "iommu=3Damd-iommu-perdev-intremap" as a command line =
option
> to the hypervisor.  This option is not fully functional on earlier
> hypervisors.
>=20
> RESOLUTION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Applying the appropriate attached patch resolves this issue.
>=20
> Note that on certain systems (SP5100 chipsets with erratum 28 present,
> or such with broken IVRS ACPI table) these patches will result in the
> IOMMU not being enabled anymore.  This should be dealt with by a BIOS
> update, if available.  Alternatively the check can be overridden by
> specifying "iommu=3Dno-amd-iommu-perdev-intremap" on the Xen command
> line ("iommu=3Damd-iommu-global-intremap" on 4.1.x), at the price of
> re-opening the security hole addressed by these patches.
>=20
> xsa36-unstable.patch              Xen unstable
> xsa36-4.2.patch                   Xen 4.2.x
> xsa36-4.1.patch                   Xen 4.1.x
>=20
> $ sha256sum xsa36*.patch
> 4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0efc6f4  =
xsa36-4.1.patch
> dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc21204067c4eb8964  =
xsa36-4.2.patch
> 7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c440e2992a7b5cfe41  =
xsa36-unstable.patch
> $
>=20
> Incremental patches on top of what was provided in version 3 can also =
be
> taken from the respective mercurial trees:
>=20
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739
> http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6
> http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>=20
> iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOencxa9R3TGTn
> 20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltzcnd
> 6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/
> PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A
> zRNADG36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP
> ICpJJFf0w7oW6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=3D
> =3DvmpB
> -----END PGP SIGNATURE-----
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xsa36-4.1.patch
> Type: application/octet-stream
> Size: 14403 bytes
> Desc: not available
> URL: =
<http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3643=
c/attachment.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xsa36-4.2.patch
> Type: application/octet-stream
> Size: 12586 bytes
> Desc: not available
> URL: =
<http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3643=
c/attachment-0001.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xsa36-unstable.patch
> Type: application/octet-stream
> Size: 12528 bytes
> Desc: not available
> URL: =
<http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3643=
c/attachment-0002.obj>
>=20
> ------------------------------
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20
>=20
> End of Xen-devel Digest, Vol 96, Issue 309
> ******************************************


--Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite">The reworking of p2m lookups to use =
get_gfn()/put_gfn() left the<br>shadow code not taking the p2m lock, =
even in cases where the p2m would<br>be updated (i.e. PoD).<br><br>In =
many cases, shadow code doesn't need the exclusion =
that<br>get_gfn()/put_gfn() provides, as it has its own interlocks =
against p2m<br>updates, but this is taking things too far, and can lead =
to crashes in<br>the PoD code.<br><br>Now that most shadow-code p2m =
lookups are done with explicitly<br>unlocked accessors, or with the =
get_page_from_gfn() accessor, which is<br>often lock-free, we can just =
turn this locking on.<br></blockquote>For the record: this includes the =
page table walking that both the emulate mapping callback and page fault =
handler need to do.<br><blockquote type=3D"cite"><br>The remaining =
locked lookups are in sh_page_fault() (in a path that's<br>almost always =
already serializing on the paging lock), and in<br>emulate_map_dest() =
(which can probably be updated to =
use<br>get_page_from_gfn()).</blockquote>That is absolutely the case. =
Here is a rough patch:</div><div><div>diff -r 7324955b35ad =
xen/arch/x86/mm/shadow/multi.c</div><div>--- =
a/xen/arch/x86/mm/shadow/multi.c</div><div>+++ =
b/xen/arch/x86/mm/shadow/multi.c</div><div>@@ -4861,6 +4861,7 @@ static =
mfn_t emulate_gva_to_mfn(struct v</div><div>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp;struct sh_emulate_ctxt =
*sh_ctxt)</div><div>&nbsp;{</div><div>&nbsp; &nbsp; &nbsp;unsigned long =
gfn;</div><div>+ &nbsp; &nbsp;struct page_info *page;</div><div>&nbsp; =
&nbsp; &nbsp;mfn_t mfn;</div><div>&nbsp; &nbsp; &nbsp;p2m_type_t =
p2mt;</div><div>&nbsp; &nbsp; &nbsp;uint32_t pfec =3D PFEC_page_present =
| PFEC_write_access;</div><div>@@ -4878,22 +4879,30 @@ static mfn_t =
emulate_gva_to_mfn(struct v</div><div>&nbsp;</div><div>&nbsp; &nbsp; =
&nbsp;/* Translate the GFN to an MFN */</div><div>&nbsp; &nbsp; =
&nbsp;ASSERT(!paging_locked_by_me(v-&gt;domain));</div><div>- &nbsp; =
&nbsp;mfn =3D get_gfn(v-&gt;domain, _gfn(gfn), &amp;p2mt);</div><div>- =
&nbsp; &nbsp; &nbsp; &nbsp;</div><div>+ &nbsp; &nbsp;page =3D =
get_page_from_gfn(v-&gt;domain, gfn, &amp;p2mt, =
P2M_ALLOC);</div><div>+</div><div>+ &nbsp; &nbsp;/* Sanity checking =
*/</div><div>+ &nbsp; &nbsp;if ( page =3D=3D NULL )</div><div>+ &nbsp; =
&nbsp;{</div><div>+ &nbsp; &nbsp; &nbsp; &nbsp;return =
_mfn(BAD_GFN_TO_MFN);</div><div>+ &nbsp; &nbsp;}</div><div>&nbsp; &nbsp; =
&nbsp;if ( p2m_is_readonly(p2mt) )</div><div>&nbsp; &nbsp; =
&nbsp;{</div><div>- &nbsp; &nbsp; &nbsp; &nbsp;put_gfn(v-&gt;domain, =
gfn);</div><div>+ &nbsp; &nbsp; &nbsp; =
&nbsp;put_page(page);</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return =
_mfn(READONLY_GFN);</div><div>&nbsp; &nbsp; &nbsp;}</div><div>&nbsp; =
&nbsp; &nbsp;if ( !p2m_is_ram(p2mt) )</div><div>&nbsp; &nbsp; =
&nbsp;{</div><div>- &nbsp; &nbsp; &nbsp; &nbsp;put_gfn(v-&gt;domain, =
gfn);</div><div>+ &nbsp; &nbsp; &nbsp; =
&nbsp;put_page(page);</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return =
_mfn(BAD_GFN_TO_MFN);</div><div>&nbsp; &nbsp; =
&nbsp;}</div><div>-</div><div>+ &nbsp; &nbsp;mfn =3D =
page_to_mfn(page);</div><div>&nbsp; &nbsp; =
&nbsp;ASSERT(mfn_valid(mfn));</div><div>+</div><div>&nbsp; &nbsp; =
&nbsp;v-&gt;arch.paging.last_write_was_pt =3D =
!!sh_mfn_is_a_page_table(mfn);</div><div>- &nbsp; =
&nbsp;put_gfn(v-&gt;domain, gfn);</div><div>+ &nbsp; &nbsp;/* Note =
shadow cannot page out or unshare this mfn, so the map won't</div><div>+ =
&nbsp; &nbsp; * disappear. Otherwise, caller must hold onto page until =
done. */</div><div>+ &nbsp; &nbsp;put_page(page);</div><div>&nbsp; =
&nbsp; &nbsp;return =
mfn;</div><div>&nbsp;}</div><div>&nbsp;</div><div><br></div></div><div><br=
><blockquote type=3D"cite"> &nbsp;They're not addressed here but may be =
in a<br>follow-up patch.<br><br></blockquote><div><br></div>Acked-by: =
Andres Lagar-Cavilla &lt;<a =
href=3D"mailto:andres@lagarcavilla.org">andres@lagarcavilla.org</a>&gt;</d=
iv><div>or Signed-off-by: Andres Lagar-Cavilla &lt;<a =
href=3D"mailto:andres@lagarcavilla.org">andres@lagarcavilla.org</a>&gt;? =
see&nbsp;<a =
href=3D"http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html=
">http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html</a></=
div><div><br></div><div>Thanks</div><div>Andres<br><blockquote =
type=3D"cite">Signed-off-by: Tim Deegan &lt;<a =
href=3D"mailto:tim@xen.org">tim@xen.org</a>&gt;<br>---<br> =
xen/arch/x86/mm/p2m.c | &nbsp;&nbsp;&nbsp;6 ++----<br> 1 file changed, 2 =
insertions(+), 4 deletions(-)<br><br>diff --git a/xen/arch/x86/mm/p2m.c =
b/xen/arch/x86/mm/p2m.c<br>index de1dd82..2db73c9 100644<br>--- =
a/xen/arch/x86/mm/p2m.c<br>+++ b/xen/arch/x86/mm/p2m.c<br>@@ -218,8 =
+218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned =
long gfn,<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return =
_mfn(gfn);<br> &nbsp;&nbsp;&nbsp;&nbsp;}<br><br>- &nbsp;&nbsp;&nbsp;/* =
For now only perform locking on hap domains */<br>- &nbsp;&nbsp;&nbsp;if =
( locked &amp;&amp; (hap_enabled(p2m-&gt;domain)) )<br>+ =
&nbsp;&nbsp;&nbsp;if ( locked )<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* Grab the lock here, =
don't release until put_gfn */<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;gfn_lock(p2m, gfn, =
0);<br><br>@@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct =
p2m_domain *p2m, unsigned long gfn,<br><br> void __put_gfn(struct =
p2m_domain *p2m, unsigned long gfn)<br> {<br>- &nbsp;&nbsp;&nbsp;if ( =
!p2m || !paging_mode_translate(p2m-&gt;domain) <br>- =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;|| !hap_enabled(p2m-&gt;domain) )<br>+ &nbsp;&nbsp;&nbsp;if ( !p2m =
|| !paging_mode_translate(p2m-&gt;domain) )<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* Nothing to do in this =
case */<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return;<br><br>-- =
<br>1.7.10.4<br><br><br><br><br>------------------------------<br><br>Mess=
age: 2<br>Date: Thu, 21 Feb 2013 14:22:51 +0000<br>From: Tim Deegan =
&lt;<a href=3D"mailto:tim@xen.org">tim@xen.org</a>&gt;<br>To: Olaf =
Hering &lt;<a href=3D"mailto:olaf@aepfle.de">olaf@aepfle.de</a>&gt;<br>Cc:=
 Eddie Dong &lt;<a =
href=3D"mailto:eddie.dong@intel.com">eddie.dong@intel.com</a>&gt;, Jun =
Nakajima<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>&lt;<a =
href=3D"mailto:jun.nakajima@intel.com">jun.nakajima@intel.com</a>&gt;,<spa=
n class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><a =
href=3D"mailto:xen-devel@lists.xen.org">xen-devel@lists.xen.org</a><br>Sub=
ject: Re: [Xen-devel] crash in nvmx_vcpu_destroy<br>Message-ID: =
&lt;20130221142251.GK24051@ocelot.phlegethon.org&gt;<br>Content-Type: =
text/plain; charset=3Diso-8859-1<br><br>At 15:19 +0100 on 21 Feb =
(1361459959), Olaf Hering wrote:<br><blockquote type=3D"cite">This patch =
fixes the crash for me. Thanks.<br></blockquote><br>Great - in that case =
it will be fixed by Jan's more comprehensive patch<br>when that goes =
in.<br><br>Cheers,<br><br>Tim.<br><br><br><br>----------------------------=
--<br><br>Message: 3<br>Date: Thu, 21 Feb 2013 14:23:31 +0000<br>From: =
Xen.org security team &lt;security@xen.org&gt;<br>To: =
xen-announce@lists.xen.org, xen-devel@lists.xen.org,<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>xen-users@lists.xen.org, oss-security@lists.openwall.com<br>Cc: =
"Xen.org security team" &lt;security@xen.org&gt;<br>Subject: [Xen-devel] =
Xen Security Advisory 36 (CVE-2013-0153) -<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>interrupt =
remap entries shared and old ones not cleared on AMD =
IOMMUs<br>Message-ID: =
&lt;E1U8X3b-0007ni-Cw@xenbits.xen.org&gt;<br>Content-Type: text/plain; =
charset=3D"utf-8"<br><br>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: =
SHA1<br><br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span> &nbsp;&nbsp;&nbsp;&nbsp;Xen Security Advisory CVE-2013-0153 / =
XSA-36<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;version 4<br><br> &nbsp;interrupt =
remap entries shared and old ones not cleared on AMD =
IOMMUs<br><br>UPDATES IN VERSION =
4<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>U=
pdated patches, to deal with a boot time crash resulting from the =
earlier<br>changes on systems with firmware broken in a way not =
previously accounted<br>for.<br><br>ISSUE =
DESCRIPTION<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>=
To avoid an erratum in early hardware, the Xen AMD IOMMU code =
by<br>default chooses to use a single interrupt remapping table for =
the<br>whole system. &nbsp;This sharing implies that any guest with a =
passed<br>through PCI device that is bus mastering capable can inject =
interrupts<br>into other guests, including domain 0.<br><br>Furthermore, =
regardless of whether a shared interrupt remapping table<br>is in use, =
old entries are not always cleared, providing opportunities<br>(which =
accumulate over time) for guests to inject interrupts into<br>other =
guests, again including domain 0.<br><br>In a typical Xen system many =
devices are owned by domain 0 or driver<br>domains, leaving them =
vulnerable to such an attack. Such a DoS is<br>likely to have an impact =
on other guests running in the system.<br><br>IMPACT<br>=3D=3D=3D=3D=3D=3D=
<br><br>A malicious domain which is given access to a physical PCI =
device can<br>mount a denial of service attack affecting the whole =
system.<br><br>VULNERABLE SYSTEMS<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<br><br>Xen versions 3.3 onwards are vulnerable. =
&nbsp;Earlier Xen versions do not<br>implement interrupt remapping, and =
hence do not support secure AMD-Vi<br>PCI passthrough in any =
case.<br><br>Only systems using AMD-Vi for PCI passthrough are =
vulnerable.<br><br>Any domain which is given access to a PCI device can =
take advantage of<br>this =
vulnerability.<br><br>MITIGATION<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>=
This issue can be avoided by not assigning PCI devices to =
untrusted<br>guests.<br><br>In Xen versions 4.1.3 and above the sharing =
of the interrupt remapping<br>table (and hence the more severe part of =
this problem) can be avoided<br>by passing =
"iommu=3Damd-iommu-perdev-intremap" as a command line option<br>to the =
hypervisor. &nbsp;This option is not fully functional on =
earlier<br>hypervisors.<br><br>RESOLUTION<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
<br><br>Applying the appropriate attached patch resolves this =
issue.<br><br>Note that on certain systems (SP5100 chipsets with erratum =
28 present,<br>or such with broken IVRS ACPI table) these patches will =
result in the<br>IOMMU not being enabled anymore. &nbsp;This should be =
dealt with by a BIOS<br>update, if available. &nbsp;Alternatively the =
check can be overridden by<br>specifying =
"iommu=3Dno-amd-iommu-perdev-intremap" on the Xen command<br>line =
("iommu=3Damd-iommu-global-intremap" on 4.1.x), at the price =
of<br>re-opening the security hole addressed by these =
patches.<br><br>xsa36-unstable.patch =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;Xen unstable<br>xsa36-4.2.patch =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen 4.2.x<br>xsa36-4.1.patch =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen 4.1.x<br><br>$ sha256sum =
xsa36*.patch<br>4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0=
efc6f4 =
&nbsp;xsa36-4.1.patch<br>dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc2=
1204067c4eb8964 =
&nbsp;xsa36-4.2.patch<br>7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c44=
0e2992a7b5cfe41 &nbsp;xsa36-unstable.patch<br>$<br><br>Incremental =
patches on top of what was provided in version 3 can also be<br>taken =
from the respective mercurial =
trees:<br><br>http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739<b=
r>http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6<br=
>http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77<br>=
-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.10 =
(GNU/Linux)<br><br>iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOenc=
xa9R3TGTn<br>20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltz=
cnd<br>6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/<br=
>PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A<br>zRNAD=
G36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP<br>ICpJJFf0w7o=
W6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=3D<br>=3DvmpB<br>----=
-END PGP SIGNATURE-----<br>-------------- next part --------------<br>A =
non-text attachment was scrubbed...<br>Name: xsa36-4.1.patch<br>Type: =
application/octet-stream<br>Size: 14403 bytes<br>Desc: not =
available<br>URL: =
&lt;http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3=
643c/attachment.obj&gt;<br>-------------- next part --------------<br>A =
non-text attachment was scrubbed...<br>Name: xsa36-4.2.patch<br>Type: =
application/octet-stream<br>Size: 12586 bytes<br>Desc: not =
available<br>URL: =
&lt;http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3=
643c/attachment-0001.obj&gt;<br>-------------- next part =
--------------<br>A non-text attachment was scrubbed...<br>Name: =
xsa36-unstable.patch<br>Type: application/octet-stream<br>Size: 12528 =
bytes<br>Desc: not available<br>URL: =
&lt;http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3=
643c/attachment-0002.obj&gt;<br><br>------------------------------<br><br>=
_______________________________________________<br>Xen-devel mailing =
list<br>Xen-devel@lists.xen.org<br>http://lists.xen.org/xen-devel<br><br><=
br>End of Xen-devel Digest, Vol 96, Issue =
309<br>******************************************<br></blockquote></div><b=
r></body></html>=

--Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD--


--===============3980674410948419927==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3980674410948419927==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 14:58:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 14: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 1U8XbB-0007F7-6Y; Thu, 21 Feb 2013 14:58:13 +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 1U8Xb9-0007El-8I
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:58:11 +0000
Received: from [85.158.137.99:29084] by server-15.bemta-3.messagelabs.com id
	C0/6C-25405-20636215; Thu, 21 Feb 2013 14:58:10 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361458686!17256445!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=2.6 required=7.0 tests=BODY_DONG,HTML_30_40,
	HTML_MESSAGE,MIME_QP_LONG_LINE,SUBJ_HAS_SPACES
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22831 invoked from network); 21 Feb 2013 14:58:07 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 14:58:07 -0000
Received: by mail-ie0-f171.google.com with SMTP id 10so11372245ied.16
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 06:58:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:message-id:references:to:x-mailer:x-gm-message-state;
	bh=eR9E9bFohtNZ1nLA6gV1UwZeJ93iuCP7lf8OOnU4ktM=;
	b=IS9hkGhKNDnUIA1/xAZ49I+IJHtpyDT4DnvWLpAzubKo7lvq5XdiKwcdNF+/s9ABzR
	QUVQNSuC7V65gcVJgC56CkFIbuiXSwMkQ7ar87qjEI96A8jRSSQM2M/IEzdar8T7iZix
	bs/nh3mlQi6nX74nDPEIr3JVztffXpSIJrRWUZ/en8kxLKAaNPod867QQBlu0nX8PbS1
	Tc4maNH4qatxpr65S80cYA2zFVrnnvI2FC2TsPVSGoY4fvNItbyBo/GTCcW+AD19pgkr
	8TD+sZu9q3V9hPFRKmMik0UddJLnUhCa5D46s4+8hQKfZwlpzUuXfs1FIihBSu1DKqzJ
	1bTA==
X-Received: by 10.50.36.229 with SMTP id t5mr13062676igj.18.1361458685736;
	Thu, 21 Feb 2013 06:58:05 -0800 (PST)
Received: from [192.168.15.1] ([206.223.182.18])
	by mx.google.com with ESMTPS id ee5sm10227551igc.0.2013.02.21.06.58.02
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 06:58:03 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 09:58:09 -0500
Message-Id: <A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmG5bGa/eE2FRw5RUYcl//QQ8nSTjGO1CaXuoMBfPR1AkFuevGAZfaXDMRg852UbBp69rHE
Cc: Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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: multipart/mixed; boundary="===============3980674410948419927=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3980674410948419927==
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD"


--Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> The reworking of p2m lookups to use get_gfn()/put_gfn() left the
> shadow code not taking the p2m lock, even in cases where the p2m would
> be updated (i.e. PoD).
>=20
> In many cases, shadow code doesn't need the exclusion that
> get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
> updates, but this is taking things too far, and can lead to crashes in
> the PoD code.
>=20
> Now that most shadow-code p2m lookups are done with explicitly
> unlocked accessors, or with the get_page_from_gfn() accessor, which is
> often lock-free, we can just turn this locking on.
For the record: this includes the page table walking that both the =
emulate mapping callback and page fault handler need to do.
>=20
> The remaining locked lookups are in sh_page_fault() (in a path that's
> almost always already serializing on the paging lock), and in
> emulate_map_dest() (which can probably be updated to use
> get_page_from_gfn()).
That is absolutely the case. Here is a rough patch:
diff -r 7324955b35ad xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4861,6 +4861,7 @@ static mfn_t emulate_gva_to_mfn(struct v
                                 struct sh_emulate_ctxt *sh_ctxt)
 {
     unsigned long gfn;
+    struct page_info *page;
     mfn_t mfn;
     p2m_type_t p2mt;
     uint32_t pfec =3D PFEC_page_present | PFEC_write_access;
@@ -4878,22 +4879,30 @@ static mfn_t emulate_gva_to_mfn(struct v
=20
     /* Translate the GFN to an MFN */
     ASSERT(!paging_locked_by_me(v->domain));
-    mfn =3D get_gfn(v->domain, _gfn(gfn), &p2mt);
-       =20
+    page =3D get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
+
+    /* Sanity checking */
+    if ( page =3D=3D NULL )
+    {
+        return _mfn(BAD_GFN_TO_MFN);
+    }
     if ( p2m_is_readonly(p2mt) )
     {
-        put_gfn(v->domain, gfn);
+        put_page(page);
         return _mfn(READONLY_GFN);
     }
     if ( !p2m_is_ram(p2mt) )
     {
-        put_gfn(v->domain, gfn);
+        put_page(page);
         return _mfn(BAD_GFN_TO_MFN);
     }
-
+    mfn =3D page_to_mfn(page);
     ASSERT(mfn_valid(mfn));
+
     v->arch.paging.last_write_was_pt =3D !!sh_mfn_is_a_page_table(mfn);
-    put_gfn(v->domain, gfn);
+    /* Note shadow cannot page out or unshare this mfn, so the map =
won't
+     * disappear. Otherwise, caller must hold onto page until done. */
+    put_page(page);
     return mfn;
 }
=20


>  They're not addressed here but may be in a
> follow-up patch.
>=20

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
or Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>? see =
http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html

Thanks
Andres
> Signed-off-by: Tim Deegan <tim@xen.org>
> ---
> xen/arch/x86/mm/p2m.c |    6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>=20
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index de1dd82..2db73c9 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -218,8 +218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain =
*p2m, unsigned long gfn,
>         return _mfn(gfn);
>     }
>=20
> -    /* 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);
>=20
> @@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain =
*p2m, unsigned long gfn,
>=20
> void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
> {
> -    if ( !p2m || !paging_mode_translate(p2m->domain)=20
> -              || !hap_enabled(p2m->domain) )
> +    if ( !p2m || !paging_mode_translate(p2m->domain) )
>         /* Nothing to do in this case */
>         return;
>=20
> --=20
> 1.7.10.4
>=20
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 2
> Date: Thu, 21 Feb 2013 14:22:51 +0000
> From: Tim Deegan <tim@xen.org>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: Eddie Dong <eddie.dong@intel.com>, Jun Nakajima
> 	<jun.nakajima@intel.com>,	xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] crash in nvmx_vcpu_destroy
> Message-ID: <20130221142251.GK24051@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=3Diso-8859-1
>=20
> At 15:19 +0100 on 21 Feb (1361459959), Olaf Hering wrote:
>> This patch fixes the crash for me. Thanks.
>=20
> Great - in that case it will be fixed by Jan's more comprehensive =
patch
> when that goes in.
>=20
> Cheers,
>=20
> Tim.
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Thu, 21 Feb 2013 14:23:31 +0000
> From: Xen.org security team <security@xen.org>
> To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
> 	xen-users@lists.xen.org, oss-security@lists.openwall.com
> Cc: "Xen.org security team" <security@xen.org>
> Subject: [Xen-devel] Xen Security Advisory 36 (CVE-2013-0153) -
> 	interrupt remap entries shared and old ones not cleared on AMD =
IOMMUs
> Message-ID: <E1U8X3b-0007ni-Cw@xenbits.xen.org>
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> 	     Xen Security Advisory CVE-2013-0153 / XSA-36
> 			      version 4
>=20
>  interrupt remap entries shared and old ones not cleared on AMD IOMMUs
>=20
> UPDATES IN VERSION 4
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Updated patches, to deal with a boot time crash resulting from the =
earlier
> changes on systems with firmware broken in a way not previously =
accounted
> for.
>=20
> ISSUE DESCRIPTION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> To avoid an erratum in early hardware, the Xen AMD IOMMU code by
> default chooses to use a single interrupt remapping table for the
> whole system.  This sharing implies that any guest with a passed
> through PCI device that is bus mastering capable can inject interrupts
> into other guests, including domain 0.
>=20
> Furthermore, regardless of whether a shared interrupt remapping table
> is in use, old entries are not always cleared, providing opportunities
> (which accumulate over time) for guests to inject interrupts into
> other guests, again including domain 0.
>=20
> In a typical Xen system many devices are owned by domain 0 or driver
> domains, leaving them vulnerable to such an attack. Such a DoS is
> likely to have an impact on other guests running in the system.
>=20
> IMPACT
> =3D=3D=3D=3D=3D=3D
>=20
> A malicious domain which is given access to a physical PCI device can
> mount a denial of service attack affecting the whole system.
>=20
> VULNERABLE SYSTEMS
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Xen versions 3.3 onwards are vulnerable.  Earlier Xen versions do not
> implement interrupt remapping, and hence do not support secure AMD-Vi
> PCI passthrough in any case.
>=20
> Only systems using AMD-Vi for PCI passthrough are vulnerable.
>=20
> Any domain which is given access to a PCI device can take advantage of
> this vulnerability.
>=20
> MITIGATION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This issue can be avoided by not assigning PCI devices to untrusted
> guests.
>=20
> In Xen versions 4.1.3 and above the sharing of the interrupt remapping
> table (and hence the more severe part of this problem) can be avoided
> by passing "iommu=3Damd-iommu-perdev-intremap" as a command line =
option
> to the hypervisor.  This option is not fully functional on earlier
> hypervisors.
>=20
> RESOLUTION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Applying the appropriate attached patch resolves this issue.
>=20
> Note that on certain systems (SP5100 chipsets with erratum 28 present,
> or such with broken IVRS ACPI table) these patches will result in the
> IOMMU not being enabled anymore.  This should be dealt with by a BIOS
> update, if available.  Alternatively the check can be overridden by
> specifying "iommu=3Dno-amd-iommu-perdev-intremap" on the Xen command
> line ("iommu=3Damd-iommu-global-intremap" on 4.1.x), at the price of
> re-opening the security hole addressed by these patches.
>=20
> xsa36-unstable.patch              Xen unstable
> xsa36-4.2.patch                   Xen 4.2.x
> xsa36-4.1.patch                   Xen 4.1.x
>=20
> $ sha256sum xsa36*.patch
> 4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0efc6f4  =
xsa36-4.1.patch
> dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc21204067c4eb8964  =
xsa36-4.2.patch
> 7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c440e2992a7b5cfe41  =
xsa36-unstable.patch
> $
>=20
> Incremental patches on top of what was provided in version 3 can also =
be
> taken from the respective mercurial trees:
>=20
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739
> http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6
> http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>=20
> iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOencxa9R3TGTn
> 20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltzcnd
> 6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/
> PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A
> zRNADG36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP
> ICpJJFf0w7oW6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=3D
> =3DvmpB
> -----END PGP SIGNATURE-----
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xsa36-4.1.patch
> Type: application/octet-stream
> Size: 14403 bytes
> Desc: not available
> URL: =
<http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3643=
c/attachment.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xsa36-4.2.patch
> Type: application/octet-stream
> Size: 12586 bytes
> Desc: not available
> URL: =
<http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3643=
c/attachment-0001.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xsa36-unstable.patch
> Type: application/octet-stream
> Size: 12528 bytes
> Desc: not available
> URL: =
<http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3643=
c/attachment-0002.obj>
>=20
> ------------------------------
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20
>=20
> End of Xen-devel Digest, Vol 96, Issue 309
> ******************************************


--Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite">The reworking of p2m lookups to use =
get_gfn()/put_gfn() left the<br>shadow code not taking the p2m lock, =
even in cases where the p2m would<br>be updated (i.e. PoD).<br><br>In =
many cases, shadow code doesn't need the exclusion =
that<br>get_gfn()/put_gfn() provides, as it has its own interlocks =
against p2m<br>updates, but this is taking things too far, and can lead =
to crashes in<br>the PoD code.<br><br>Now that most shadow-code p2m =
lookups are done with explicitly<br>unlocked accessors, or with the =
get_page_from_gfn() accessor, which is<br>often lock-free, we can just =
turn this locking on.<br></blockquote>For the record: this includes the =
page table walking that both the emulate mapping callback and page fault =
handler need to do.<br><blockquote type=3D"cite"><br>The remaining =
locked lookups are in sh_page_fault() (in a path that's<br>almost always =
already serializing on the paging lock), and in<br>emulate_map_dest() =
(which can probably be updated to =
use<br>get_page_from_gfn()).</blockquote>That is absolutely the case. =
Here is a rough patch:</div><div><div>diff -r 7324955b35ad =
xen/arch/x86/mm/shadow/multi.c</div><div>--- =
a/xen/arch/x86/mm/shadow/multi.c</div><div>+++ =
b/xen/arch/x86/mm/shadow/multi.c</div><div>@@ -4861,6 +4861,7 @@ static =
mfn_t emulate_gva_to_mfn(struct v</div><div>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp;struct sh_emulate_ctxt =
*sh_ctxt)</div><div>&nbsp;{</div><div>&nbsp; &nbsp; &nbsp;unsigned long =
gfn;</div><div>+ &nbsp; &nbsp;struct page_info *page;</div><div>&nbsp; =
&nbsp; &nbsp;mfn_t mfn;</div><div>&nbsp; &nbsp; &nbsp;p2m_type_t =
p2mt;</div><div>&nbsp; &nbsp; &nbsp;uint32_t pfec =3D PFEC_page_present =
| PFEC_write_access;</div><div>@@ -4878,22 +4879,30 @@ static mfn_t =
emulate_gva_to_mfn(struct v</div><div>&nbsp;</div><div>&nbsp; &nbsp; =
&nbsp;/* Translate the GFN to an MFN */</div><div>&nbsp; &nbsp; =
&nbsp;ASSERT(!paging_locked_by_me(v-&gt;domain));</div><div>- &nbsp; =
&nbsp;mfn =3D get_gfn(v-&gt;domain, _gfn(gfn), &amp;p2mt);</div><div>- =
&nbsp; &nbsp; &nbsp; &nbsp;</div><div>+ &nbsp; &nbsp;page =3D =
get_page_from_gfn(v-&gt;domain, gfn, &amp;p2mt, =
P2M_ALLOC);</div><div>+</div><div>+ &nbsp; &nbsp;/* Sanity checking =
*/</div><div>+ &nbsp; &nbsp;if ( page =3D=3D NULL )</div><div>+ &nbsp; =
&nbsp;{</div><div>+ &nbsp; &nbsp; &nbsp; &nbsp;return =
_mfn(BAD_GFN_TO_MFN);</div><div>+ &nbsp; &nbsp;}</div><div>&nbsp; &nbsp; =
&nbsp;if ( p2m_is_readonly(p2mt) )</div><div>&nbsp; &nbsp; =
&nbsp;{</div><div>- &nbsp; &nbsp; &nbsp; &nbsp;put_gfn(v-&gt;domain, =
gfn);</div><div>+ &nbsp; &nbsp; &nbsp; =
&nbsp;put_page(page);</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return =
_mfn(READONLY_GFN);</div><div>&nbsp; &nbsp; &nbsp;}</div><div>&nbsp; =
&nbsp; &nbsp;if ( !p2m_is_ram(p2mt) )</div><div>&nbsp; &nbsp; =
&nbsp;{</div><div>- &nbsp; &nbsp; &nbsp; &nbsp;put_gfn(v-&gt;domain, =
gfn);</div><div>+ &nbsp; &nbsp; &nbsp; =
&nbsp;put_page(page);</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return =
_mfn(BAD_GFN_TO_MFN);</div><div>&nbsp; &nbsp; =
&nbsp;}</div><div>-</div><div>+ &nbsp; &nbsp;mfn =3D =
page_to_mfn(page);</div><div>&nbsp; &nbsp; =
&nbsp;ASSERT(mfn_valid(mfn));</div><div>+</div><div>&nbsp; &nbsp; =
&nbsp;v-&gt;arch.paging.last_write_was_pt =3D =
!!sh_mfn_is_a_page_table(mfn);</div><div>- &nbsp; =
&nbsp;put_gfn(v-&gt;domain, gfn);</div><div>+ &nbsp; &nbsp;/* Note =
shadow cannot page out or unshare this mfn, so the map won't</div><div>+ =
&nbsp; &nbsp; * disappear. Otherwise, caller must hold onto page until =
done. */</div><div>+ &nbsp; &nbsp;put_page(page);</div><div>&nbsp; =
&nbsp; &nbsp;return =
mfn;</div><div>&nbsp;}</div><div>&nbsp;</div><div><br></div></div><div><br=
><blockquote type=3D"cite"> &nbsp;They're not addressed here but may be =
in a<br>follow-up patch.<br><br></blockquote><div><br></div>Acked-by: =
Andres Lagar-Cavilla &lt;<a =
href=3D"mailto:andres@lagarcavilla.org">andres@lagarcavilla.org</a>&gt;</d=
iv><div>or Signed-off-by: Andres Lagar-Cavilla &lt;<a =
href=3D"mailto:andres@lagarcavilla.org">andres@lagarcavilla.org</a>&gt;? =
see&nbsp;<a =
href=3D"http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html=
">http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html</a></=
div><div><br></div><div>Thanks</div><div>Andres<br><blockquote =
type=3D"cite">Signed-off-by: Tim Deegan &lt;<a =
href=3D"mailto:tim@xen.org">tim@xen.org</a>&gt;<br>---<br> =
xen/arch/x86/mm/p2m.c | &nbsp;&nbsp;&nbsp;6 ++----<br> 1 file changed, 2 =
insertions(+), 4 deletions(-)<br><br>diff --git a/xen/arch/x86/mm/p2m.c =
b/xen/arch/x86/mm/p2m.c<br>index de1dd82..2db73c9 100644<br>--- =
a/xen/arch/x86/mm/p2m.c<br>+++ b/xen/arch/x86/mm/p2m.c<br>@@ -218,8 =
+218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned =
long gfn,<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return =
_mfn(gfn);<br> &nbsp;&nbsp;&nbsp;&nbsp;}<br><br>- &nbsp;&nbsp;&nbsp;/* =
For now only perform locking on hap domains */<br>- &nbsp;&nbsp;&nbsp;if =
( locked &amp;&amp; (hap_enabled(p2m-&gt;domain)) )<br>+ =
&nbsp;&nbsp;&nbsp;if ( locked )<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* Grab the lock here, =
don't release until put_gfn */<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;gfn_lock(p2m, gfn, =
0);<br><br>@@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct =
p2m_domain *p2m, unsigned long gfn,<br><br> void __put_gfn(struct =
p2m_domain *p2m, unsigned long gfn)<br> {<br>- &nbsp;&nbsp;&nbsp;if ( =
!p2m || !paging_mode_translate(p2m-&gt;domain) <br>- =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;|| !hap_enabled(p2m-&gt;domain) )<br>+ &nbsp;&nbsp;&nbsp;if ( !p2m =
|| !paging_mode_translate(p2m-&gt;domain) )<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* Nothing to do in this =
case */<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return;<br><br>-- =
<br>1.7.10.4<br><br><br><br><br>------------------------------<br><br>Mess=
age: 2<br>Date: Thu, 21 Feb 2013 14:22:51 +0000<br>From: Tim Deegan =
&lt;<a href=3D"mailto:tim@xen.org">tim@xen.org</a>&gt;<br>To: Olaf =
Hering &lt;<a href=3D"mailto:olaf@aepfle.de">olaf@aepfle.de</a>&gt;<br>Cc:=
 Eddie Dong &lt;<a =
href=3D"mailto:eddie.dong@intel.com">eddie.dong@intel.com</a>&gt;, Jun =
Nakajima<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>&lt;<a =
href=3D"mailto:jun.nakajima@intel.com">jun.nakajima@intel.com</a>&gt;,<spa=
n class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><a =
href=3D"mailto:xen-devel@lists.xen.org">xen-devel@lists.xen.org</a><br>Sub=
ject: Re: [Xen-devel] crash in nvmx_vcpu_destroy<br>Message-ID: =
&lt;20130221142251.GK24051@ocelot.phlegethon.org&gt;<br>Content-Type: =
text/plain; charset=3Diso-8859-1<br><br>At 15:19 +0100 on 21 Feb =
(1361459959), Olaf Hering wrote:<br><blockquote type=3D"cite">This patch =
fixes the crash for me. Thanks.<br></blockquote><br>Great - in that case =
it will be fixed by Jan's more comprehensive patch<br>when that goes =
in.<br><br>Cheers,<br><br>Tim.<br><br><br><br>----------------------------=
--<br><br>Message: 3<br>Date: Thu, 21 Feb 2013 14:23:31 +0000<br>From: =
Xen.org security team &lt;security@xen.org&gt;<br>To: =
xen-announce@lists.xen.org, xen-devel@lists.xen.org,<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>xen-users@lists.xen.org, oss-security@lists.openwall.com<br>Cc: =
"Xen.org security team" &lt;security@xen.org&gt;<br>Subject: [Xen-devel] =
Xen Security Advisory 36 (CVE-2013-0153) -<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>interrupt =
remap entries shared and old ones not cleared on AMD =
IOMMUs<br>Message-ID: =
&lt;E1U8X3b-0007ni-Cw@xenbits.xen.org&gt;<br>Content-Type: text/plain; =
charset=3D"utf-8"<br><br>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: =
SHA1<br><br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span> &nbsp;&nbsp;&nbsp;&nbsp;Xen Security Advisory CVE-2013-0153 / =
XSA-36<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;version 4<br><br> &nbsp;interrupt =
remap entries shared and old ones not cleared on AMD =
IOMMUs<br><br>UPDATES IN VERSION =
4<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>U=
pdated patches, to deal with a boot time crash resulting from the =
earlier<br>changes on systems with firmware broken in a way not =
previously accounted<br>for.<br><br>ISSUE =
DESCRIPTION<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>=
To avoid an erratum in early hardware, the Xen AMD IOMMU code =
by<br>default chooses to use a single interrupt remapping table for =
the<br>whole system. &nbsp;This sharing implies that any guest with a =
passed<br>through PCI device that is bus mastering capable can inject =
interrupts<br>into other guests, including domain 0.<br><br>Furthermore, =
regardless of whether a shared interrupt remapping table<br>is in use, =
old entries are not always cleared, providing opportunities<br>(which =
accumulate over time) for guests to inject interrupts into<br>other =
guests, again including domain 0.<br><br>In a typical Xen system many =
devices are owned by domain 0 or driver<br>domains, leaving them =
vulnerable to such an attack. Such a DoS is<br>likely to have an impact =
on other guests running in the system.<br><br>IMPACT<br>=3D=3D=3D=3D=3D=3D=
<br><br>A malicious domain which is given access to a physical PCI =
device can<br>mount a denial of service attack affecting the whole =
system.<br><br>VULNERABLE SYSTEMS<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<br><br>Xen versions 3.3 onwards are vulnerable. =
&nbsp;Earlier Xen versions do not<br>implement interrupt remapping, and =
hence do not support secure AMD-Vi<br>PCI passthrough in any =
case.<br><br>Only systems using AMD-Vi for PCI passthrough are =
vulnerable.<br><br>Any domain which is given access to a PCI device can =
take advantage of<br>this =
vulnerability.<br><br>MITIGATION<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>=
This issue can be avoided by not assigning PCI devices to =
untrusted<br>guests.<br><br>In Xen versions 4.1.3 and above the sharing =
of the interrupt remapping<br>table (and hence the more severe part of =
this problem) can be avoided<br>by passing =
"iommu=3Damd-iommu-perdev-intremap" as a command line option<br>to the =
hypervisor. &nbsp;This option is not fully functional on =
earlier<br>hypervisors.<br><br>RESOLUTION<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
<br><br>Applying the appropriate attached patch resolves this =
issue.<br><br>Note that on certain systems (SP5100 chipsets with erratum =
28 present,<br>or such with broken IVRS ACPI table) these patches will =
result in the<br>IOMMU not being enabled anymore. &nbsp;This should be =
dealt with by a BIOS<br>update, if available. &nbsp;Alternatively the =
check can be overridden by<br>specifying =
"iommu=3Dno-amd-iommu-perdev-intremap" on the Xen command<br>line =
("iommu=3Damd-iommu-global-intremap" on 4.1.x), at the price =
of<br>re-opening the security hole addressed by these =
patches.<br><br>xsa36-unstable.patch =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;Xen unstable<br>xsa36-4.2.patch =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen 4.2.x<br>xsa36-4.1.patch =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen 4.1.x<br><br>$ sha256sum =
xsa36*.patch<br>4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0=
efc6f4 =
&nbsp;xsa36-4.1.patch<br>dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc2=
1204067c4eb8964 =
&nbsp;xsa36-4.2.patch<br>7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c44=
0e2992a7b5cfe41 &nbsp;xsa36-unstable.patch<br>$<br><br>Incremental =
patches on top of what was provided in version 3 can also be<br>taken =
from the respective mercurial =
trees:<br><br>http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739<b=
r>http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6<br=
>http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77<br>=
-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.10 =
(GNU/Linux)<br><br>iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOenc=
xa9R3TGTn<br>20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltz=
cnd<br>6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/<br=
>PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A<br>zRNAD=
G36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP<br>ICpJJFf0w7o=
W6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=3D<br>=3DvmpB<br>----=
-END PGP SIGNATURE-----<br>-------------- next part --------------<br>A =
non-text attachment was scrubbed...<br>Name: xsa36-4.1.patch<br>Type: =
application/octet-stream<br>Size: 14403 bytes<br>Desc: not =
available<br>URL: =
&lt;http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3=
643c/attachment.obj&gt;<br>-------------- next part --------------<br>A =
non-text attachment was scrubbed...<br>Name: xsa36-4.2.patch<br>Type: =
application/octet-stream<br>Size: 12586 bytes<br>Desc: not =
available<br>URL: =
&lt;http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3=
643c/attachment-0001.obj&gt;<br>-------------- next part =
--------------<br>A non-text attachment was scrubbed...<br>Name: =
xsa36-unstable.patch<br>Type: application/octet-stream<br>Size: 12528 =
bytes<br>Desc: not available<br>URL: =
&lt;http://lists.xen.org/archives/html/xen-devel/attachments/20130221/02b3=
643c/attachment-0002.obj&gt;<br><br>------------------------------<br><br>=
_______________________________________________<br>Xen-devel mailing =
list<br>Xen-devel@lists.xen.org<br>http://lists.xen.org/xen-devel<br><br><=
br>End of Xen-devel Digest, Vol 96, Issue =
309<br>******************************************<br></blockquote></div><b=
r></body></html>=

--Apple-Mail=_BF5E0027-2DD3-4650-A214-33A3706218FD--


--===============3980674410948419927==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3980674410948419927==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 15:00:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:00: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 1U8Xcp-0007Um-UX; Thu, 21 Feb 2013 14:59: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 1U8Xco-0007Ua-Pp
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:59:54 +0000
Received: from [85.158.143.99:63566] by server-3.bemta-4.messagelabs.com id
	7B/43-02186-A6636215; Thu, 21 Feb 2013 14:59:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361458589!27950517!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21371 invoked from network); 21 Feb 2013 14:56:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:56:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XZU-0007GN-Vh; Thu, 21 Feb 2013 14:56:28 +0000
Date: Thu, 21 Feb 2013 14:56:28 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221145628.GN24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 05/46] xen: arm64: initial build + config
	changes, start of day 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

At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> +2:      PRINT("- Started in Hyp mode -\r\n")
> +
> +hyp:

I though we were going to use "EL3" instead of "Hyp".

> +        /* Non-boot CPUs need to move on to the relocated pagetables */
> +        //mov   x0, #0

This line should go. 

> +/*
> + * xen/arch/arm/arm64/mode_switch.S
> + *
> + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> +        bootwrapper.

Still missing a *.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:00:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:00: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 1U8Xcp-0007Um-UX; Thu, 21 Feb 2013 14:59: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 1U8Xco-0007Ua-Pp
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 14:59:54 +0000
Received: from [85.158.143.99:63566] by server-3.bemta-4.messagelabs.com id
	7B/43-02186-A6636215; Thu, 21 Feb 2013 14:59:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361458589!27950517!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21371 invoked from network); 21 Feb 2013 14:56:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 14:56:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XZU-0007GN-Vh; Thu, 21 Feb 2013 14:56:28 +0000
Date: Thu, 21 Feb 2013 14:56:28 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221145628.GN24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 05/46] xen: arm64: initial build + config
	changes, start of day 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

At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> +2:      PRINT("- Started in Hyp mode -\r\n")
> +
> +hyp:

I though we were going to use "EL3" instead of "Hyp".

> +        /* Non-boot CPUs need to move on to the relocated pagetables */
> +        //mov   x0, #0

This line should go. 

> +/*
> + * xen/arch/arm/arm64/mode_switch.S
> + *
> + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> +        bootwrapper.

Still missing a *.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:00:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:00: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 1U8Xd1-0007Yd-Bb; Thu, 21 Feb 2013 15:00: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 1U8Xd0-0007YB-4Z
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:00:06 +0000
Received: from [85.158.137.99:5627] by server-9.bemta-3.messagelabs.com id
	F6/96-09484-57636215; Thu, 21 Feb 2013 15:00:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361458801!14269889!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3534 invoked from network); 21 Feb 2013 15:00:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:00:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xcv-0007Hx-7q; Thu, 21 Feb 2013 15:00:01 +0000
Date: Thu, 21 Feb 2013 15:00:01 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150001.GP24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-10-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 10/46] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860444), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:00:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:00: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 1U8Xd1-0007Yd-Bb; Thu, 21 Feb 2013 15:00: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 1U8Xd0-0007YB-4Z
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:00:06 +0000
Received: from [85.158.137.99:5627] by server-9.bemta-3.messagelabs.com id
	F6/96-09484-57636215; Thu, 21 Feb 2013 15:00:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361458801!14269889!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3534 invoked from network); 21 Feb 2013 15:00:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:00:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xcv-0007Hx-7q; Thu, 21 Feb 2013 15:00:01 +0000
Date: Thu, 21 Feb 2013 15:00:01 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150001.GP24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-10-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 10/46] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860444), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:02:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Xf1-00081r-TX; Thu, 21 Feb 2013 15:02:11 +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 1U8Xez-00081d-RW
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:02:09 +0000
Received: from [85.158.138.51:29619] by server-16.bemta-3.messagelabs.com id
	F4/62-02727-8E636215; Thu, 21 Feb 2013 15:02:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361458918!22235149!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16507 invoked from network); 21 Feb 2013 15:01:58 -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; 21 Feb 2013 15:01:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xen-0007KL-Fq; Thu, 21 Feb 2013 15:01:57 +0000
Date: Thu, 21 Feb 2013 15:01:57 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150157.GQ24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 14/46] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860448), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

Were we also talking about having smb_ barriers equivalent to the normas
ones, like on x86?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:02:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Xf1-00081r-TX; Thu, 21 Feb 2013 15:02:11 +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 1U8Xez-00081d-RW
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:02:09 +0000
Received: from [85.158.138.51:29619] by server-16.bemta-3.messagelabs.com id
	F4/62-02727-8E636215; Thu, 21 Feb 2013 15:02:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361458918!22235149!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16507 invoked from network); 21 Feb 2013 15:01:58 -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; 21 Feb 2013 15:01:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xen-0007KL-Fq; Thu, 21 Feb 2013 15:01:57 +0000
Date: Thu, 21 Feb 2013 15:01:57 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150157.GQ24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 14/46] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860448), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

Were we also talking about having smb_ barriers equivalent to the normas
ones, like on x86?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:04:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:04: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 1U8Xgz-0008Fy-Fo; Thu, 21 Feb 2013 15:04: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 1U8Xgy-0008Fj-GH
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:04:12 +0000
Received: from [85.158.139.211:14700] by server-12.bemta-5.messagelabs.com id
	73/83-20195-B6736215; Thu, 21 Feb 2013 15:04:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361459050!18594303!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32353 invoked from network); 21 Feb 2013 15:04:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:04:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xgv-0007La-Rs; Thu, 21 Feb 2013 15:04:09 +0000
Date: Thu, 21 Feb 2013 15:04:09 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150409.GR24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-19-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-19-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 19/46] xen: arm64: changes to
	setup_pagetables and mm.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:47 +0000 on 14 Feb (1360860453), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:04:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:04: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 1U8Xgz-0008Fy-Fo; Thu, 21 Feb 2013 15:04: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 1U8Xgy-0008Fj-GH
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:04:12 +0000
Received: from [85.158.139.211:14700] by server-12.bemta-5.messagelabs.com id
	73/83-20195-B6736215; Thu, 21 Feb 2013 15:04:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361459050!18594303!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32353 invoked from network); 21 Feb 2013 15:04:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:04:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xgv-0007La-Rs; Thu, 21 Feb 2013 15:04:09 +0000
Date: Thu, 21 Feb 2013 15:04:09 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150409.GR24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-19-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-19-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 19/46] xen: arm64: changes to
	setup_pagetables and mm.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:47 +0000 on 14 Feb (1360860453), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:07:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:07: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 1U8Xja-0008UL-54; Thu, 21 Feb 2013 15:06:54 +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 1U8XjY-0008TO-GZ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:06:52 +0000
Received: from [85.158.137.99:11813] by server-11.bemta-3.messagelabs.com id
	FE/DC-10249-B0836215; Thu, 21 Feb 2013 15:06:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361459159!17258265!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 21 Feb 2013 15:06:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:06:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xif-0007MC-Io; Thu, 21 Feb 2013 15:05:57 +0000
Date: Thu, 21 Feb 2013 15:05:57 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150557.GS24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-25-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-25-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 25/46] xen: arm64: add guest type to
	domain field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860459), Ian Campbell wrote:
> Currently 32 bit PV is the only option.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:07:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:07: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 1U8Xja-0008UL-54; Thu, 21 Feb 2013 15:06:54 +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 1U8XjY-0008TO-GZ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:06:52 +0000
Received: from [85.158.137.99:11813] by server-11.bemta-3.messagelabs.com id
	FE/DC-10249-B0836215; Thu, 21 Feb 2013 15:06:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361459159!17258265!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 21 Feb 2013 15:06:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:06:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xif-0007MC-Io; Thu, 21 Feb 2013 15:05:57 +0000
Date: Thu, 21 Feb 2013 15:05:57 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221150557.GS24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-25-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-25-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 25/46] xen: arm64: add guest type to
	domain field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860459), Ian Campbell wrote:
> Currently 32 bit PV is the only option.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:10:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:10: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 1U8Xn3-0000Ez-Qg; Thu, 21 Feb 2013 15:10: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 1U8Xn2-0000Er-5o
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:10:28 +0000
Received: from [193.109.254.147:40362] by server-6.bemta-14.messagelabs.com id
	90/8F-12010-3E836215; Thu, 21 Feb 2013 15:10:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361459424!8717284!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22358 invoked from network); 21 Feb 2013 15:10:25 -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; 21 Feb 2013 15:10:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xmx-0007N5-I9; Thu, 21 Feb 2013 15:10:23 +0000
Date: Thu, 21 Feb 2013 15:10:23 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151023.GT24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
>     restoring state.

You don't seem to have addressed my other comments on v1:

> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,5 +1,7 @@
>  subdir-y += lib
>  
> +obj-y += entry.o
>  obj-y += mode_switch.o
>  
> +obj-y += traps.o
>  obj-y += domain.o

Alphabetical order, please. 

> +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))

This is now replicated in three places.  Maybe it should live in, say,
xen/bitops.h?

> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -238,7 +238,7 @@ union hsr {
>  #endif
>  
>  #ifndef __ASSEMBLY__
> -extern uint32_t hyp_traps_vector[8];
> +extern uint32_t hyp_traps_vector;

Keep the array type?  uint8_t[] would do, or define up something the
right size. 

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 Feb 21 15:10:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:10: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 1U8Xn3-0000Ez-Qg; Thu, 21 Feb 2013 15:10: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 1U8Xn2-0000Er-5o
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:10:28 +0000
Received: from [193.109.254.147:40362] by server-6.bemta-14.messagelabs.com id
	90/8F-12010-3E836215; Thu, 21 Feb 2013 15:10:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361459424!8717284!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22358 invoked from network); 21 Feb 2013 15:10:25 -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; 21 Feb 2013 15:10:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xmx-0007N5-I9; Thu, 21 Feb 2013 15:10:23 +0000
Date: Thu, 21 Feb 2013 15:10:23 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151023.GT24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
>     restoring state.

You don't seem to have addressed my other comments on v1:

> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,5 +1,7 @@
>  subdir-y += lib
>  
> +obj-y += entry.o
>  obj-y += mode_switch.o
>  
> +obj-y += traps.o
>  obj-y += domain.o

Alphabetical order, please. 

> +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))

This is now replicated in three places.  Maybe it should live in, say,
xen/bitops.h?

> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -238,7 +238,7 @@ union hsr {
>  #endif
>  
>  #ifndef __ASSEMBLY__
> -extern uint32_t hyp_traps_vector[8];
> +extern uint32_t hyp_traps_vector;

Keep the array type?  uint8_t[] would do, or define up something the
right size. 

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 Feb 21 15:12:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:12: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 1U8XoR-0000Qg-0E; Thu, 21 Feb 2013 15:11:55 +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 1U8XoP-0000QP-R1
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:11:53 +0000
Received: from [85.158.138.51:10929] by server-7.bemta-3.messagelabs.com id
	DD/00-10367-83936215; Thu, 21 Feb 2013 15:11:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361459511!22236794!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25033 invoked from network); 21 Feb 2013 15:11:51 -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; 21 Feb 2013 15:11:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XoN-0007Ne-13; Thu, 21 Feb 2013 15:11:51 +0000
Date: Thu, 21 Feb 2013 15:11:50 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151150.GU24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-31-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-31-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 31/46] xen: arm: show_registers() support
	for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860465), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:12:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:12: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 1U8XoR-0000Qg-0E; Thu, 21 Feb 2013 15:11:55 +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 1U8XoP-0000QP-R1
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:11:53 +0000
Received: from [85.158.138.51:10929] by server-7.bemta-3.messagelabs.com id
	DD/00-10367-83936215; Thu, 21 Feb 2013 15:11:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361459511!22236794!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25033 invoked from network); 21 Feb 2013 15:11:51 -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; 21 Feb 2013 15:11:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XoN-0007Ne-13; Thu, 21 Feb 2013 15:11:51 +0000
Date: Thu, 21 Feb 2013 15:11:50 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151150.GU24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-31-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-31-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 31/46] xen: arm: show_registers() support
	for 64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860465), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:13:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:13: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 1U8Xpp-0000cT-GX; Thu, 21 Feb 2013 15:13:21 +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 1U8Xpo-0000c6-1A
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:13:20 +0000
Received: from [193.109.254.147:12087] by server-8.bemta-14.messagelabs.com id
	74/F4-17325-F8936215; Thu, 21 Feb 2013 15:13:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361459576!9054982!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25143 invoked from network); 21 Feb 2013 15:12:57 -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; 21 Feb 2013 15:12:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XpQ-0007O6-Cp; Thu, 21 Feb 2013 15:12:56 +0000
Date: Thu, 21 Feb 2013 15:12:56 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151256.GV24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-44-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-44-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 44/46] xen: arm: print arm64 not arm32 in
	xen info when appropriate.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860478), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:13:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:13: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 1U8Xpp-0000cT-GX; Thu, 21 Feb 2013 15:13:21 +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 1U8Xpo-0000c6-1A
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:13:20 +0000
Received: from [193.109.254.147:12087] by server-8.bemta-14.messagelabs.com id
	74/F4-17325-F8936215; Thu, 21 Feb 2013 15:13:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361459576!9054982!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25143 invoked from network); 21 Feb 2013 15:12:57 -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; 21 Feb 2013 15:12:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8XpQ-0007O6-Cp; Thu, 21 Feb 2013 15:12:56 +0000
Date: Thu, 21 Feb 2013 15:12:56 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151256.GV24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-44-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-44-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 44/46] xen: arm: print arm64 not arm32 in
	xen info when appropriate.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860478), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:18:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:18: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 1U8Xv1-00011b-9o; Thu, 21 Feb 2013 15:18: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 1U8Xv0-00011W-JJ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:18:42 +0000
Received: from [85.158.143.99:33949] by server-2.bemta-4.messagelabs.com id
	D1/17-12656-1DA36215; Thu, 21 Feb 2013 15:18:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361459921!25230450!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22348 invoked from network); 21 Feb 2013 15:18:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:18:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xuy-0007P8-SD; Thu, 21 Feb 2013 15:18:40 +0000
Date: Thu, 21 Feb 2013 15:18:40 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151840.GW24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-45-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-45-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 45/46] xen: arm: Fix guest mode for 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860479), Ian Campbell wrote:
> Need to check for the 64-bit EL2 modes, not 32-bit HYP mode.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:18:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:18: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 1U8Xv1-00011b-9o; Thu, 21 Feb 2013 15:18: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 1U8Xv0-00011W-JJ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:18:42 +0000
Received: from [85.158.143.99:33949] by server-2.bemta-4.messagelabs.com id
	D1/17-12656-1DA36215; Thu, 21 Feb 2013 15:18:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361459921!25230450!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22348 invoked from network); 21 Feb 2013 15:18:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:18:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Xuy-0007P8-SD; Thu, 21 Feb 2013 15:18:40 +0000
Date: Thu, 21 Feb 2013 15:18:40 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221151840.GW24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-45-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360860480-9245-45-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: stefano.stabellini@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 45/46] xen: arm: Fix guest mode for 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:47 +0000 on 14 Feb (1360860479), Ian Campbell wrote:
> Need to check for the 64-bit EL2 modes, not 32-bit HYP mode.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:19:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8XvS-000141-ND; Thu, 21 Feb 2013 15:19: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 1U8XvQ-00013n-QR
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:19:09 +0000
Received: from [85.158.138.51:28206] by server-4.bemta-3.messagelabs.com id
	03/5C-17521-CEA36215; Thu, 21 Feb 2013 15:19:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361459947!20560494!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3614 invoked from network); 21 Feb 2013 15:19:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:19:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15: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.297.1;
	Thu, 21 Feb 2013 15:18:48 +0000
Message-ID: <1361459927.26546.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 21 Feb 2013 15:18:47 +0000
In-Reply-To: <5126437D02000078000C0006@nat28.tlf.novell.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > If any committer needs help getting git to work please feel free to
> > ask.  git has many advantages but its user interface has received very
> > mixed reviews.  We appreciate that you might need handholding.  So if
> > you get confused, or into trouble, do consult.
> 
> So one thing I found very handy with hg was that there was a
> single line history with easy to look at changeset numbers. Is there
> any way to achieve the same with git? I'm asking particularly in the
> context of backporting: In order to pick changes from unstable (now
> master), so far I simply scanned the history, tracking (on a sheet of
> paper) at which c/s I last left off.

Something like git log --oneline?

You can also git log --pretty=format:%...

Where there are various available %foo described in the manpage.

git doesn't really have a concept of the shorter sequential numbers
which mercurial has. The closest I can think of is the sort of thing
which git describe outputs.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:19:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8XvS-000141-ND; Thu, 21 Feb 2013 15:19: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 1U8XvQ-00013n-QR
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:19:09 +0000
Received: from [85.158.138.51:28206] by server-4.bemta-3.messagelabs.com id
	03/5C-17521-CEA36215; Thu, 21 Feb 2013 15:19:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361459947!20560494!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3614 invoked from network); 21 Feb 2013 15:19:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:19:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15: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.297.1;
	Thu, 21 Feb 2013 15:18:48 +0000
Message-ID: <1361459927.26546.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 21 Feb 2013 15:18:47 +0000
In-Reply-To: <5126437D02000078000C0006@nat28.tlf.novell.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > If any committer needs help getting git to work please feel free to
> > ask.  git has many advantages but its user interface has received very
> > mixed reviews.  We appreciate that you might need handholding.  So if
> > you get confused, or into trouble, do consult.
> 
> So one thing I found very handy with hg was that there was a
> single line history with easy to look at changeset numbers. Is there
> any way to achieve the same with git? I'm asking particularly in the
> context of backporting: In order to pick changes from unstable (now
> master), so far I simply scanned the history, tracking (on a sheet of
> paper) at which c/s I last left off.

Something like git log --oneline?

You can also git log --pretty=format:%...

Where there are various available %foo described in the manpage.

git doesn't really have a concept of the shorter sequential numbers
which mercurial has. The closest I can think of is the sort of thing
which git describe outputs.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:25:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Y1e-0001UR-Hw; Thu, 21 Feb 2013 15:25: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 1U8Y1d-0001UL-17
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:25:33 +0000
Received: from [85.158.138.51:30852] by server-14.bemta-3.messagelabs.com id
	D3/C9-23533-76C36215; Thu, 21 Feb 2013 15:25:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361460326!19691609!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14694 invoked from network); 21 Feb 2013 15:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:25: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.297.1;
	Thu, 21 Feb 2013 15:25:26 +0000
Message-ID: <1361460324.26546.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 15:25:24 +0000
In-Reply-To: <20130221151023.GT24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> >     restoring state.
> 
> You don't seem to have addressed my other comments on v1:

I've got them in v3, I noted that I hadn't addresses you comment on this
patch in the #0/46.

> > --- a/xen/arch/arm/arm64/Makefile
> > +++ b/xen/arch/arm/arm64/Makefile
> > @@ -1,5 +1,7 @@
> >  subdir-y += lib
> >  
> > +obj-y += entry.o
> >  obj-y += mode_switch.o
> >  
> > +obj-y += traps.o
> >  obj-y += domain.o
> 
> Alphabetical order, please.

I kept this the same order as arm32/Makefile on purpose.

> > +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> > +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> > +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> > +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> > +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
> 
> This is now replicated in three places.  Maybe it should live in, say,
> xen/bitops.h?
[...]
> Keep the array type?  uint8_t[] would do, or define up something the
> right size. 

I've got both of these in my tree already for v3.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:25:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Y1e-0001UR-Hw; Thu, 21 Feb 2013 15:25: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 1U8Y1d-0001UL-17
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:25:33 +0000
Received: from [85.158.138.51:30852] by server-14.bemta-3.messagelabs.com id
	D3/C9-23533-76C36215; Thu, 21 Feb 2013 15:25:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361460326!19691609!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14694 invoked from network); 21 Feb 2013 15:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:25: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.297.1;
	Thu, 21 Feb 2013 15:25:26 +0000
Message-ID: <1361460324.26546.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 15:25:24 +0000
In-Reply-To: <20130221151023.GT24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> >     restoring state.
> 
> You don't seem to have addressed my other comments on v1:

I've got them in v3, I noted that I hadn't addresses you comment on this
patch in the #0/46.

> > --- a/xen/arch/arm/arm64/Makefile
> > +++ b/xen/arch/arm/arm64/Makefile
> > @@ -1,5 +1,7 @@
> >  subdir-y += lib
> >  
> > +obj-y += entry.o
> >  obj-y += mode_switch.o
> >  
> > +obj-y += traps.o
> >  obj-y += domain.o
> 
> Alphabetical order, please.

I kept this the same order as arm32/Makefile on purpose.

> > +#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
> > +#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
> > +#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
> > +#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
> > +#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
> 
> This is now replicated in three places.  Maybe it should live in, say,
> xen/bitops.h?
[...]
> Keep the array type?  uint8_t[] would do, or define up something the
> right size. 

I've got both of these in my tree already for v3.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:25:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Y1m-0001Ve-34; Thu, 21 Feb 2013 15:25: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 1U8Y1l-0001VU-FF
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:25:41 +0000
Received: from [85.158.138.51:31625] by server-15.bemta-3.messagelabs.com id
	87/0E-25405-07C36215; Thu, 21 Feb 2013 15:25:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361460334!20561918!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1304 invoked from network); 21 Feb 2013 15:25:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:25:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Y1e-0007QY-9t; Thu, 21 Feb 2013 15:25:34 +0000
Date: Thu, 21 Feb 2013 15:25:34 +0000
From: Tim Deegan <tim@xen.org>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Message-ID: <20130221152534.GX24051@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L5j5tSCeLO5FhQywDOgBoMA=ugY6wwj_Ov6YnJxDLri+w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF6-1L5j5tSCeLO5FhQywDOgBoMA=ugY6wwj_Ov6YnJxDLri+w@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
	order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 15:47 +0100 on 18 Feb (1361202472), Sylvain Munaut wrote:
> > In the meantime, perhaps you could try the attached (untested) patch.
> > If my guess is right, it ought to stop the crashes but you might find
> > the VM's performance suffers.
> 
> The patch seems to have fixed this issue.

Excellent, thanks.  I've just applied it to xen-unstable.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:25:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Y1m-0001Ve-34; Thu, 21 Feb 2013 15:25: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 1U8Y1l-0001VU-FF
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:25:41 +0000
Received: from [85.158.138.51:31625] by server-15.bemta-3.messagelabs.com id
	87/0E-25405-07C36215; Thu, 21 Feb 2013 15:25:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361460334!20561918!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1304 invoked from network); 21 Feb 2013 15:25:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:25:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Y1e-0007QY-9t; Thu, 21 Feb 2013 15:25:34 +0000
Date: Thu, 21 Feb 2013 15:25:34 +0000
From: Tim Deegan <tim@xen.org>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Message-ID: <20130221152534.GX24051@ocelot.phlegethon.org>
References: <CAF6-1L4VbTG7ZN2mrL7ofEjMLT0hgE1unJSm1j65PBteJdmA+Q@mail.gmail.com>
	<20130218113541.GA77310@ocelot.phlegethon.org>
	<CAF6-1L5j5tSCeLO5FhQywDOgBoMA=ugY6wwj_Ov6YnJxDLri+w@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF6-1L5j5tSCeLO5FhQywDOgBoMA=ugY6wwj_Ov6YnJxDLri+w@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking
	order violation - Dom0 reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 15:47 +0100 on 18 Feb (1361202472), Sylvain Munaut wrote:
> > In the meantime, perhaps you could try the attached (untested) patch.
> > If my guess is right, it ought to stop the crashes but you might find
> > the VM's performance suffers.
> 
> The patch seems to have fixed this issue.

Excellent, thanks.  I've just applied it to xen-unstable.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:26:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:26: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 1U8Y2G-0001aG-Gw; Thu, 21 Feb 2013 15:26: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 1U8Y2E-0001Zx-PE
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:26:10 +0000
Received: from [85.158.139.211:12883] by server-14.bemta-5.messagelabs.com id
	A2/79-06967-29C36215; Thu, 21 Feb 2013 15:26:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361460369!18562409!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2973 invoked from network); 21 Feb 2013 15:26:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:26: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.297.1;
	Thu, 21 Feb 2013 15:26:09 +0000
Message-ID: <1361460367.26546.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 15:26:07 +0000
In-Reply-To: <20130221145628.GN24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
	<20130221145628.GN24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 05/46] xen: arm64: initial build + config
 changes, start of day 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 Thu, 2013-02-21 at 14:56 +0000, Tim Deegan wrote:
> At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> > +2:      PRINT("- Started in Hyp mode -\r\n")
> > +
> > +hyp:
> 
> I though we were going to use "EL3" instead of "Hyp".

Sorry, looks like I missed a few comments when I went through this one.

> 
> > +        /* Non-boot CPUs need to move on to the relocated pagetables */
> > +        //mov   x0, #0
> 
> This line should go. 
> 
> > +/*
> > + * xen/arch/arm/arm64/mode_switch.S
> > + *
> > + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> > +        bootwrapper.
> 
> Still missing a *.
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:26:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:26: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 1U8Y2G-0001aG-Gw; Thu, 21 Feb 2013 15:26: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 1U8Y2E-0001Zx-PE
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:26:10 +0000
Received: from [85.158.139.211:12883] by server-14.bemta-5.messagelabs.com id
	A2/79-06967-29C36215; Thu, 21 Feb 2013 15:26:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361460369!18562409!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2973 invoked from network); 21 Feb 2013 15:26:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:26: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.297.1;
	Thu, 21 Feb 2013 15:26:09 +0000
Message-ID: <1361460367.26546.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 15:26:07 +0000
In-Reply-To: <20130221145628.GN24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
	<20130221145628.GN24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 05/46] xen: arm64: initial build + config
 changes, start of day 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 Thu, 2013-02-21 at 14:56 +0000, Tim Deegan wrote:
> At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> > +2:      PRINT("- Started in Hyp mode -\r\n")
> > +
> > +hyp:
> 
> I though we were going to use "EL3" instead of "Hyp".

Sorry, looks like I missed a few comments when I went through this one.

> 
> > +        /* Non-boot CPUs need to move on to the relocated pagetables */
> > +        //mov   x0, #0
> 
> This line should go. 
> 
> > +/*
> > + * xen/arch/arm/arm64/mode_switch.S
> > + *
> > + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> > +        bootwrapper.
> 
> Still missing a *.
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:27:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Y3l-0001oe-0m; Thu, 21 Feb 2013 15:27:45 +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 1U8Y3j-0001oM-Ji
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:27:43 +0000
Received: from [85.158.139.83:34135] by server-3.bemta-5.messagelabs.com id
	7D/14-07037-EEC36215; Thu, 21 Feb 2013 15:27:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361460462!28331768!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9614 invoked from network); 21 Feb 2013 15:27:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:27: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.297.1;
	Thu, 21 Feb 2013 15:27:42 +0000
Message-ID: <1361460460.26546.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 15:27:40 +0000
In-Reply-To: <20130221150157.GQ24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
	<20130221150157.GQ24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 14/46] xen: arm64: barriers and wait for
 interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 15:01 +0000, Tim Deegan wrote:
> At 16:47 +0000 on 14 Feb (1360860448), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 
> Were we also talking about having smb_ barriers equivalent to the normas
> ones, like on x86?

Yes, I think in a F2F conversation which is why I forgot.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:27:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8Y3l-0001oe-0m; Thu, 21 Feb 2013 15:27:45 +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 1U8Y3j-0001oM-Ji
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:27:43 +0000
Received: from [85.158.139.83:34135] by server-3.bemta-5.messagelabs.com id
	7D/14-07037-EEC36215; Thu, 21 Feb 2013 15:27:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361460462!28331768!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9614 invoked from network); 21 Feb 2013 15:27:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1739684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:27: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.297.1;
	Thu, 21 Feb 2013 15:27:42 +0000
Message-ID: <1361460460.26546.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 15:27:40 +0000
In-Reply-To: <20130221150157.GQ24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
	<20130221150157.GQ24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 14/46] xen: arm64: barriers and wait for
 interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 15:01 +0000, Tim Deegan wrote:
> At 16:47 +0000 on 14 Feb (1360860448), Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 
> Were we also talking about having smb_ barriers equivalent to the normas
> ones, like on x86?

Yes, I think in a F2F conversation which is why I forgot.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:37:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YCd-0002O3-26; Thu, 21 Feb 2013 15:36: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 1U8YCc-0002Ny-5D
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:36:54 +0000
Received: from [85.158.143.99:15701] by server-3.bemta-4.messagelabs.com id
	16/AD-02186-51F36215; Thu, 21 Feb 2013 15:36:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361461012!23327769!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11632 invoked from network); 21 Feb 2013 15:36:52 -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; 21 Feb 2013 15:36:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YCY-0007So-QN; Thu, 21 Feb 2013 15:36:50 +0000
Date: Thu, 21 Feb 2013 15:36:50 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221153650.GY24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361460324.26546.62.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > >     restoring state.
> > 
> > You don't seem to have addressed my other comments on v1:
> 
> I've got them in v3, I noted that I hadn't addresses you comment on this
> patch in the #0/46.

So you did; I did read the 0/46, but for some reason all that stuck in
my head was the WFE stuff. 

AFAICS you just need to re-roll this and #25, and get a tools-person to
ack #20.  So for v3, can you just send those, and avoid another 46-patch
mailbomb? :)

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 Feb 21 15:37:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YCd-0002O3-26; Thu, 21 Feb 2013 15:36: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 1U8YCc-0002Ny-5D
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:36:54 +0000
Received: from [85.158.143.99:15701] by server-3.bemta-4.messagelabs.com id
	16/AD-02186-51F36215; Thu, 21 Feb 2013 15:36:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361461012!23327769!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11632 invoked from network); 21 Feb 2013 15:36:52 -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; 21 Feb 2013 15:36:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YCY-0007So-QN; Thu, 21 Feb 2013 15:36:50 +0000
Date: Thu, 21 Feb 2013 15:36:50 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221153650.GY24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361460324.26546.62.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > >     restoring state.
> > 
> > You don't seem to have addressed my other comments on v1:
> 
> I've got them in v3, I noted that I hadn't addresses you comment on this
> patch in the #0/46.

So you did; I did read the 0/46, but for some reason all that stuck in
my head was the WFE stuff. 

AFAICS you just need to re-roll this and #25, and get a tools-person to
ack #20.  So for v3, can you just send those, and avoid another 46-patch
mailbomb? :)

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 Feb 21 15:47:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMT-0002gn-CA; Thu, 21 Feb 2013 15:47:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMR-0002gS-DA; Thu, 21 Feb 2013 15:47:03 +0000
Received: from [85.158.139.211:29704] by server-13.bemta-5.messagelabs.com id
	0E/2C-06769-67146215; Thu, 21 Feb 2013 15:47:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31666 invoked from network); 21 Feb 2013 15:46:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332490"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-VN;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1306e69a7018d075d7351eb4b7a1eeb782293830
Message-ID: <1306e69a7018d075d735.1361461584@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 5 v2] common/sysctl: Introduce hypercall to
 query the console ring size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 66f563be41d9 -r 1306e69a7018 xen/common/sysctl.c
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -357,6 +357,9 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xe
     }
     break;
 
+    case XEN_SYSCTL_consoleringsize:
+        ret = console_ring_size(&op->u.consoleringsize);
+        break;
 
     default:
         ret = arch_do_sysctl(op, u_sysctl);
diff -r 66f563be41d9 -r 1306e69a7018 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -226,6 +226,12 @@ long read_console_ring(struct xen_sysctl
     return 0;
 }
 
+long console_ring_size(struct xen_sysctl_consoleringsize * op)
+{
+    op->size = conring_size;
+    return 0;
+}
+
 
 /*
  * *******************************************************
diff -r 66f563be41d9 -r 1306e69a7018 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,14 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_consoleringsize */
+/* Get the size of the hypervisor console ring. */
+struct xen_sysctl_consoleringsize {
+    uint64_t size; /* Written by Xen. */
+};
+typedef struct xen_sysctl_consoleringsize xen_sysctl_consoleringsize_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_consoleringsize_t);
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +624,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_consoleringsize               20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +645,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_consoleringsize   consoleringsize;
         uint8_t                             pad[128];
     } u;
 };
diff -r 66f563be41d9 -r 1306e69a7018 xen/include/xen/console.h
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -12,6 +12,8 @@
 
 struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
+struct xen_sysctl_consoleringsize;
+long console_ring_size(struct xen_sysctl_consoleringsize *op);
 
 void console_init_preirq(void);
 void console_init_postirq(void);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMT-0002gn-CA; Thu, 21 Feb 2013 15:47:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMR-0002gS-DA; Thu, 21 Feb 2013 15:47:03 +0000
Received: from [85.158.139.211:29704] by server-13.bemta-5.messagelabs.com id
	0E/2C-06769-67146215; Thu, 21 Feb 2013 15:47:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31666 invoked from network); 21 Feb 2013 15:46:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332490"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-VN;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1306e69a7018d075d7351eb4b7a1eeb782293830
Message-ID: <1306e69a7018d075d735.1361461584@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:24 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 5 v2] common/sysctl: Introduce hypercall to
 query the console ring size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 66f563be41d9 -r 1306e69a7018 xen/common/sysctl.c
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -357,6 +357,9 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xe
     }
     break;
 
+    case XEN_SYSCTL_consoleringsize:
+        ret = console_ring_size(&op->u.consoleringsize);
+        break;
 
     default:
         ret = arch_do_sysctl(op, u_sysctl);
diff -r 66f563be41d9 -r 1306e69a7018 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -226,6 +226,12 @@ long read_console_ring(struct xen_sysctl
     return 0;
 }
 
+long console_ring_size(struct xen_sysctl_consoleringsize * op)
+{
+    op->size = conring_size;
+    return 0;
+}
+
 
 /*
  * *******************************************************
diff -r 66f563be41d9 -r 1306e69a7018 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,14 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_consoleringsize */
+/* Get the size of the hypervisor console ring. */
+struct xen_sysctl_consoleringsize {
+    uint64_t size; /* Written by Xen. */
+};
+typedef struct xen_sysctl_consoleringsize xen_sysctl_consoleringsize_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_consoleringsize_t);
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +624,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_consoleringsize               20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +645,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_consoleringsize   consoleringsize;
         uint8_t                             pad[128];
     } u;
 };
diff -r 66f563be41d9 -r 1306e69a7018 xen/include/xen/console.h
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -12,6 +12,8 @@
 
 struct xen_sysctl_readconsole;
 long read_console_ring(struct xen_sysctl_readconsole *op);
+struct xen_sysctl_consoleringsize;
+long console_ring_size(struct xen_sysctl_consoleringsize *op);
 
 void console_init_preirq(void);
 void console_init_postirq(void);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMT-0002h1-T3; Thu, 21 Feb 2013 15:47:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMR-0002gT-Qa; Thu, 21 Feb 2013 15:47:04 +0000
Received: from [85.158.139.211:29727] by server-11.bemta-5.messagelabs.com id
	6B/EC-19159-67146215; Thu, 21 Feb 2013 15:47:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31301 invoked from network); 21 Feb 2013 15:46:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332488"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-Uv;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 5 v2] Tools: Console ring 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

Hello,

The following set of patches came about when trying to fix the 32K limitation
with stub_xc_readconsolering() in the ocaml bindings.

Patch 1 is a hypervisor patch adding a new SYSCTL hypercall to query the size
of the console ring, which is fixed but otherwise inaccessible after boot.

Patches 2 thru 5 are tools patches:
 * Patch 2 adds a libxc function to use the new SYSCTL hypercall.
 * Patch 3 implements an alternative xc_readconsolering() to prevent bounce
   buffering.
 * Patch 4 uses the preceding patches to fix the implementation of
   stub_xc_readconsolering() in the ocaml bindings.
 * Patch 5 is a misc threading fix in the ocaml bindings, discovered when
   trying to fix the console functionality.

CC'd is xen-api@lists.xen.org as well, for comment on the ocaml patches.

This patch set has been compile-tested on unstable, and functionally tested
via backport to 4.2 (which was only one whitespace fuzz issue and no code
change).

Signed-off-by: Andrew Cooper <andrew.cooper3@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 Feb 21 15:47:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMT-0002h1-T3; Thu, 21 Feb 2013 15:47:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMR-0002gT-Qa; Thu, 21 Feb 2013 15:47:04 +0000
Received: from [85.158.139.211:29727] by server-11.bemta-5.messagelabs.com id
	6B/EC-19159-67146215; Thu, 21 Feb 2013 15:47:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31301 invoked from network); 21 Feb 2013 15:46:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332488"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-Uv;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
Message-ID: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:23 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 5 v2] Tools: Console ring 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

Hello,

The following set of patches came about when trying to fix the 32K limitation
with stub_xc_readconsolering() in the ocaml bindings.

Patch 1 is a hypervisor patch adding a new SYSCTL hypercall to query the size
of the console ring, which is fixed but otherwise inaccessible after boot.

Patches 2 thru 5 are tools patches:
 * Patch 2 adds a libxc function to use the new SYSCTL hypercall.
 * Patch 3 implements an alternative xc_readconsolering() to prevent bounce
   buffering.
 * Patch 4 uses the preceding patches to fix the implementation of
   stub_xc_readconsolering() in the ocaml bindings.
 * Patch 5 is a misc threading fix in the ocaml bindings, discovered when
   trying to fix the console functionality.

CC'd is xen-api@lists.xen.org as well, for comment on the ocaml patches.

This patch set has been compile-tested on unstable, and functionally tested
via backport to 4.2 (which was only one whitespace fuzz issue and no code
change).

Signed-off-by: Andrew Cooper <andrew.cooper3@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 Feb 21 15:47:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMb-0002hi-9x; Thu, 21 Feb 2013 15:47: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 1U8YMa-0002hU-1r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:47:12 +0000
Received: from [193.109.254.147:25154] by server-12.bemta-14.messagelabs.com
	id C2/27-32582-F7146215; Thu, 21 Feb 2013 15:47:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361461630!8722986!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11199 invoked from network); 21 Feb 2013 15:47:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:47:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1740560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:47: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.297.1;
	Thu, 21 Feb 2013 15:47:10 +0000
Message-ID: <1361461628.26546.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Huang <w1.huang@samsung.com>
Date: Thu, 21 Feb 2013 15:47:08 +0000
In-Reply-To: <002d01ce1049$9d5455d0$d7fd0170$@samsung.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
	<1361459927.26546.59.camel@zakaz.uk.xensource.com>
	<002d01ce1049$9d5455d0$d7fd0170$@samsung.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 no idea how, and you forgot to cc the list. I've added it back.

On Thu, 2013-02-21 at 15:39 +0000, Wei Huang wrote:
> Could you make http download available for xen.git (and others)? I can find
> it through http://xenbits.xen.org/git-http, which is annoying.
> 
> Thanks,
> -Wei
> 
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Thursday, February 21, 2013 9:19 AM
> To: Jan Beulich
> Cc: Anthony Perard; Tim (Xen.org); Keir (Xen.org); Ian Jackson;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Moving xen*.hg to git
> 
> On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> > >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > > If any committer needs help getting git to work please feel free to 
> > > ask.  git has many advantages but its user interface has received 
> > > very mixed reviews.  We appreciate that you might need handholding.  
> > > So if you get confused, or into trouble, do consult.
> > 
> > So one thing I found very handy with hg was that there was a single 
> > line history with easy to look at changeset numbers. Is there any way 
> > to achieve the same with git? I'm asking particularly in the context 
> > of backporting: In order to pick changes from unstable (now master), 
> > so far I simply scanned the history, tracking (on a sheet of
> > paper) at which c/s I last left off.
> 
> Something like git log --oneline?
> 
> You can also git log --pretty=format:%...
> 
> Where there are various available %foo described in the manpage.
> 
> git doesn't really have a concept of the shorter sequential numbers which
> mercurial has. The closest I can think of is the sort of thing which git
> describe outputs.
> 
> 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 Feb 21 15:47:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMb-0002hi-9x; Thu, 21 Feb 2013 15:47: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 1U8YMa-0002hU-1r
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:47:12 +0000
Received: from [193.109.254.147:25154] by server-12.bemta-14.messagelabs.com
	id C2/27-32582-F7146215; Thu, 21 Feb 2013 15:47:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361461630!8722986!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11199 invoked from network); 21 Feb 2013 15:47:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:47:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1740560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:47: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.297.1;
	Thu, 21 Feb 2013 15:47:10 +0000
Message-ID: <1361461628.26546.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Huang <w1.huang@samsung.com>
Date: Thu, 21 Feb 2013 15:47:08 +0000
In-Reply-To: <002d01ce1049$9d5455d0$d7fd0170$@samsung.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
	<1361459927.26546.59.camel@zakaz.uk.xensource.com>
	<002d01ce1049$9d5455d0$d7fd0170$@samsung.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 no idea how, and you forgot to cc the list. I've added it back.

On Thu, 2013-02-21 at 15:39 +0000, Wei Huang wrote:
> Could you make http download available for xen.git (and others)? I can find
> it through http://xenbits.xen.org/git-http, which is annoying.
> 
> Thanks,
> -Wei
> 
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Thursday, February 21, 2013 9:19 AM
> To: Jan Beulich
> Cc: Anthony Perard; Tim (Xen.org); Keir (Xen.org); Ian Jackson;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Moving xen*.hg to git
> 
> On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> > >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > > If any committer needs help getting git to work please feel free to 
> > > ask.  git has many advantages but its user interface has received 
> > > very mixed reviews.  We appreciate that you might need handholding.  
> > > So if you get confused, or into trouble, do consult.
> > 
> > So one thing I found very handy with hg was that there was a single 
> > line history with easy to look at changeset numbers. Is there any way 
> > to achieve the same with git? I'm asking particularly in the context 
> > of backporting: In order to pick changes from unstable (now master), 
> > so far I simply scanned the history, tracking (on a sheet of
> > paper) at which c/s I last left off.
> 
> Something like git log --oneline?
> 
> You can also git log --pretty=format:%...
> 
> Where there are various available %foo described in the manpage.
> 
> git doesn't really have a concept of the shorter sequential numbers which
> mercurial has. The closest I can think of is the sort of thing which git
> describe outputs.
> 
> 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 Feb 21 15:47:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:47: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 1U8YMj-0002jt-V2; Thu, 21 Feb 2013 15:47:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMh-0002jA-O6; Thu, 21 Feb 2013 15:47:19 +0000
Received: from [85.158.139.211:53658] by server-15.bemta-5.messagelabs.com id
	BC/29-18914-68146215; Thu, 21 Feb 2013 15:47:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 21 Feb 2013 15:46:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332489"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-Vh;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1ffce9bf90f5a1526146e15e6335065c34fc5aed
Message-ID: <1ffce9bf90f5a1526146.1361461585@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 5 v2] tools/libxc: Helper function for
 XEN_SYSCTL_consoleringsize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1306e69a7018 -r 1ffce9bf90f5 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -100,6 +100,26 @@ int xc_readconsolering(xc_interface *xch
     return ret;
 }
 
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize)
+{
+    int ret = -1;
+    DECLARE_SYSCTL;
+
+    if ( ! psize )
+    {
+        errno = EFAULT;
+        return ret;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_consoleringsize;
+    ret = do_sysctl(xch, &sysctl);
+
+    if ( ! ret )
+        *psize = sysctl.u.consoleringsize.size;
+
+    return ret;
+}
+
 int xc_send_debug_keys(xc_interface *xch, char *keys)
 {
     int ret, len = strlen(keys);
diff -r 1306e69a7018 -r 1ffce9bf90f5 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,7 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:47: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 1U8YMj-0002jt-V2; Thu, 21 Feb 2013 15:47:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMh-0002jA-O6; Thu, 21 Feb 2013 15:47:19 +0000
Received: from [85.158.139.211:53658] by server-15.bemta-5.messagelabs.com id
	BC/29-18914-68146215; Thu, 21 Feb 2013 15:47:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 21 Feb 2013 15:46:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332489"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-Vh;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1ffce9bf90f5a1526146e15e6335065c34fc5aed
Message-ID: <1ffce9bf90f5a1526146.1361461585@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:25 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 5 v2] tools/libxc: Helper function for
 XEN_SYSCTL_consoleringsize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1306e69a7018 -r 1ffce9bf90f5 tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -100,6 +100,26 @@ int xc_readconsolering(xc_interface *xch
     return ret;
 }
 
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize)
+{
+    int ret = -1;
+    DECLARE_SYSCTL;
+
+    if ( ! psize )
+    {
+        errno = EFAULT;
+        return ret;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_consoleringsize;
+    ret = do_sysctl(xch, &sysctl);
+
+    if ( ! ret )
+        *psize = sysctl.u.consoleringsize.size;
+
+    return ret;
+}
+
 int xc_send_debug_keys(xc_interface *xch, char *keys)
 {
     int ret, len = strlen(keys);
diff -r 1306e69a7018 -r 1ffce9bf90f5 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,7 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMo-0002lg-IK; Thu, 21 Feb 2013 15:47:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMn-0002kt-1w; Thu, 21 Feb 2013 15:47:25 +0000
Received: from [85.158.139.211:54155] by server-11.bemta-5.messagelabs.com id
	9C/AD-19159-C8146215; Thu, 21 Feb 2013 15:47:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31895 invoked from network); 21 Feb 2013 15:46:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332492"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-W2;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1e6c7f7cec6f25c45940991c871bd96b8b41590d
Message-ID: <1e6c7f7cec6f25c45940.1361461586@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:26 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 5 v2] tools/libxc: Implement
	xc_readconsolering_buffer()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Functions identically to xc_readconsolering(), but uses a user-provided
xc_hypercall_buffer_t to save using a bounce buffer.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * Reduce xc_readconsolering() to use xc_readconsolering_buffer()

diff -r 1ffce9bf90f5 -r 1e6c7f7cec6f tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -70,13 +70,29 @@ int xc_readconsolering(xc_interface *xch
                        int clear, int incremental, uint32_t *pindex)
 {
     int ret;
-    unsigned int nr_chars = *pnr_chars;
-    DECLARE_SYSCTL;
-    DECLARE_HYPERCALL_BOUNCE(buffer, nr_chars, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    DECLARE_HYPERCALL_BOUNCE(buffer, *pnr_chars, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
 
     if ( xc_hypercall_bounce_pre(xch, buffer) )
         return -1;
 
+    ret = xc_readconsolering_buffer(xch, HYPERCALL_BUFFER(buffer),
+                                    pnr_chars, clear, incremental, pindex);
+
+    xc_hypercall_bounce_post(xch, buffer);
+
+    return ret;
+}
+
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex)
+{
+    int ret;
+    unsigned int nr_chars = *pnr_chars;
+    DECLARE_SYSCTL;
+    DECLARE_HYPERCALL_BUFFER_ARGUMENT(buffer);
+
     sysctl.cmd = XEN_SYSCTL_readconsole;
     set_xen_guest_handle(sysctl.u.readconsole.buffer, buffer);
     sysctl.u.readconsole.count = nr_chars;
@@ -95,8 +111,6 @@ int xc_readconsolering(xc_interface *xch
             *pindex = sysctl.u.readconsole.index;
     }
 
-    xc_hypercall_bounce_post(xch, buffer);
-
     return ret;
 }
 
diff -r 1ffce9bf90f5 -r 1e6c7f7cec6f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,10 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex);
 int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YMo-0002lg-IK; Thu, 21 Feb 2013 15:47:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMn-0002kt-1w; Thu, 21 Feb 2013 15:47:25 +0000
Received: from [85.158.139.211:54155] by server-11.bemta-5.messagelabs.com id
	9C/AD-19159-C8146215; Thu, 21 Feb 2013 15:47:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361461611!18602887!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31895 invoked from network); 21 Feb 2013 15:46:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:46:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332492"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YMD-0007lc-W2;
	Thu, 21 Feb 2013 15:46:49 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1e6c7f7cec6f25c45940991c871bd96b8b41590d
Message-ID: <1e6c7f7cec6f25c45940.1361461586@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:26 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 5 v2] tools/libxc: Implement
	xc_readconsolering_buffer()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Functions identically to xc_readconsolering(), but uses a user-provided
xc_hypercall_buffer_t to save using a bounce buffer.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * Reduce xc_readconsolering() to use xc_readconsolering_buffer()

diff -r 1ffce9bf90f5 -r 1e6c7f7cec6f tools/libxc/xc_misc.c
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -70,13 +70,29 @@ int xc_readconsolering(xc_interface *xch
                        int clear, int incremental, uint32_t *pindex)
 {
     int ret;
-    unsigned int nr_chars = *pnr_chars;
-    DECLARE_SYSCTL;
-    DECLARE_HYPERCALL_BOUNCE(buffer, nr_chars, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+    DECLARE_HYPERCALL_BOUNCE(buffer, *pnr_chars, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
 
     if ( xc_hypercall_bounce_pre(xch, buffer) )
         return -1;
 
+    ret = xc_readconsolering_buffer(xch, HYPERCALL_BUFFER(buffer),
+                                    pnr_chars, clear, incremental, pindex);
+
+    xc_hypercall_bounce_post(xch, buffer);
+
+    return ret;
+}
+
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex)
+{
+    int ret;
+    unsigned int nr_chars = *pnr_chars;
+    DECLARE_SYSCTL;
+    DECLARE_HYPERCALL_BUFFER_ARGUMENT(buffer);
+
     sysctl.cmd = XEN_SYSCTL_readconsole;
     set_xen_guest_handle(sysctl.u.readconsole.buffer, buffer);
     sysctl.u.readconsole.count = nr_chars;
@@ -95,8 +111,6 @@ int xc_readconsolering(xc_interface *xch
             *pindex = sysctl.u.readconsole.index;
     }
 
-    xc_hypercall_bounce_post(xch, buffer);
-
     return ret;
 }
 
diff -r 1ffce9bf90f5 -r 1e6c7f7cec6f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -998,6 +998,10 @@ int xc_readconsolering(xc_interface *xch
                        char *buffer,
                        unsigned int *pnr_chars,
                        int clear, int incremental, uint32_t *pindex);
+int xc_readconsolering_buffer(xc_interface *xch,
+                              xc_hypercall_buffer_t *buffer,
+                              unsigned int *pnr_chars,
+                              int clear, int incremental, uint32_t *pindex);
 int xc_consoleringsize(xc_interface *xch, uint64_t * psize);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:47: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 1U8YMq-0002mo-Am; Thu, 21 Feb 2013 15:47:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMo-0002lR-Nr; Thu, 21 Feb 2013 15:47:26 +0000
Received: from [85.158.139.83:30438] by server-1.bemta-5.messagelabs.com id
	83/C1-29263-D8146215; Thu, 21 Feb 2013 15:47:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361461611!28317431!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22030 invoked from network); 21 Feb 2013 15:46:52 -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;
	21 Feb 2013 15:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8763841"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YME-0007lc-0U;
	Thu, 21 Feb 2013 15:46:50 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3300e9cad49da2c0015200d54c500035351ce079
Message-ID: <3300e9cad49da2c00152.1361461588@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 5 v2] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large.  Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * Mark as Noreturn, due to unconditional use of caml_raise_with_string()

diff -r 1774a72fde4a -r 3300e9cad49d tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -51,21 +51,22 @@
 	i1 = (uint32_t) Int64_val(Field(input, 0)); \
 	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
 
-#define ERROR_STRLEN 1024
-void failwith_xc(xc_interface *xch)
+static void Noreturn failwith_xc(xc_interface *xch)
 {
-	static char error_str[ERROR_STRLEN];
+	char error_str[256];
 	if (xch) {
 		const xc_error *error = xc_get_last_error(xch);
 		if (error->code == XC_ERROR_NONE)
-                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
+                	snprintf(error_str, sizeof(error_str),
+				 "%d: %s", errno, strerror(errno));
 		else
-			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
-				 error->code,
+			snprintf(error_str, sizeof(error_str),
+				 "%d: %s: %s", error->code,
 				 xc_error_code_to_desc(error->code),
 				 error->message);
 	} else {
-		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
+		snprintf(error_str, sizeof(error_str),
+			 "Unable to open XC interface");
 	}
 	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:47:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:47: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 1U8YMq-0002mo-Am; Thu, 21 Feb 2013 15:47:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YMo-0002lR-Nr; Thu, 21 Feb 2013 15:47:26 +0000
Received: from [85.158.139.83:30438] by server-1.bemta-5.messagelabs.com id
	83/C1-29263-D8146215; Thu, 21 Feb 2013 15:47:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361461611!28317431!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22030 invoked from network); 21 Feb 2013 15:46:52 -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;
	21 Feb 2013 15:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8763841"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YME-0007lc-0U;
	Thu, 21 Feb 2013 15:46:50 +0000
MIME-Version: 1.0
X-Mercurial-Node: 3300e9cad49da2c0015200d54c500035351ce079
Message-ID: <3300e9cad49da2c00152.1361461588@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 5 v2] tools/ocaml: libxc bindings: Fix
	failwith_xc()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large.  Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * Mark as Noreturn, due to unconditional use of caml_raise_with_string()

diff -r 1774a72fde4a -r 3300e9cad49d tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -51,21 +51,22 @@
 	i1 = (uint32_t) Int64_val(Field(input, 0)); \
 	i2 = ((Field(input, 1) == Val_none) ? 0xffffffff : (uint32_t) Int64_val(Field(Field(input, 1), 0)));
 
-#define ERROR_STRLEN 1024
-void failwith_xc(xc_interface *xch)
+static void Noreturn failwith_xc(xc_interface *xch)
 {
-	static char error_str[ERROR_STRLEN];
+	char error_str[256];
 	if (xch) {
 		const xc_error *error = xc_get_last_error(xch);
 		if (error->code == XC_ERROR_NONE)
-                	snprintf(error_str, ERROR_STRLEN, "%d: %s", errno, strerror(errno));
+                	snprintf(error_str, sizeof(error_str),
+				 "%d: %s", errno, strerror(errno));
 		else
-			snprintf(error_str, ERROR_STRLEN, "%d: %s: %s",
-				 error->code,
+			snprintf(error_str, sizeof(error_str),
+				 "%d: %s: %s", error->code,
 				 xc_error_code_to_desc(error->code),
 				 error->message);
 	} else {
-		snprintf(error_str, ERROR_STRLEN, "Unable to open XC interface");
+		snprintf(error_str, sizeof(error_str),
+			 "Unable to open XC interface");
 	}
 	caml_raise_with_string(*caml_named_value("xc.error"), error_str);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:48:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:48: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 1U8YO5-0003Jf-2Q; Thu, 21 Feb 2013 15:48:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YO3-0003IW-D2; Thu, 21 Feb 2013 15:48:43 +0000
Received: from [85.158.139.83:36882] by server-2.bemta-5.messagelabs.com id
	C7/74-16911-AD146215; Thu, 21 Feb 2013 15:48:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361461613!28592922!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26506 invoked from network); 21 Feb 2013 15:46:55 -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;
	21 Feb 2013 15:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332491"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YME-0007lc-08;
	Thu, 21 Feb 2013 15:46:50 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1774a72fde4a51d162ea1c8ad45c9b91d9c86c2c
Message-ID: <1774a72fde4a51d162ea.1361461587@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 5 v2] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two problems with this function:
  * The caml_{enter,leave}_blocking_section() calls mean that two threads can
    compete for use of the static ring[] buffer.
  * It fails to retrieve the entire buffer if the hypervisor has used 32K or
    more of its console ring.

Rewrite the function using the new xc_consoleringsize() and
xc_readconsolering_buffer() functions to efficiently grab the entire console
ring.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * Convert conring_size to being static to avoid needless hypercalls
 * Fix memory due to ordering of failwith_xc() and xc_hypercall_buffer_free()
 * Remove useless CAMLreturns()

diff -r 1e6c7f7cec6f -r 1774a72fde4a tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -523,27 +523,50 @@ CAMLprim value stub_xc_evtchn_reset(valu
 	CAMLreturn(Val_unit);
 }
 
-
-#define RING_SIZE 32768
-static char ring[RING_SIZE];
-
 CAMLprim value stub_xc_readconsolering(value xch)
 {
-	unsigned int size = RING_SIZE - 1;
-	char *ring_ptr = ring;
-	int retval;
+	static int have_conring_size = 0;
+	static uint64_t conring_size;
+
+	unsigned int nr_chars;
+	DECLARE_HYPERCALL_BUFFER(char, ring);
+	int r;
 
 	CAMLparam1(xch);
+	CAMLlocal1(conring);
+
+	if ( ! have_conring_size )
+	{
+		if ( xc_consoleringsize(_H(xch), &conring_size) )
+			failwith_xc(_H(xch));
+
+		/* Round conring_size up to the next page, for NULL terminator
+		   and slop from a race with printk() in the hypervisor. */
+		conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
+		have_conring_size = 0;
+	}
+
+	nr_chars = conring_size-1;
+	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
+
+	if ( ! ring )
+		caml_raise_out_of_memory();
 
 	caml_enter_blocking_section();
-	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
+	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
+				      &nr_chars, 0, 0, NULL);
 	caml_leave_blocking_section();
 
-	if (retval)
+	if ( r )
+	{
+		xc_hypercall_buffer_free(_H(xch), ring);
 		failwith_xc(_H(xch));
+	}
 
-	ring[size] = '\0';
-	CAMLreturn(caml_copy_string(ring));
+	ring[nr_chars] = '\0';
+	conring = caml_copy_string(ring);
+	xc_hypercall_buffer_free(_H(xch), ring);
+	CAMLreturn(conring);
 }
 
 CAMLprim value stub_xc_send_debug_keys(value xch, value keys)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:48:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:48: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 1U8YO5-0003Jf-2Q; Thu, 21 Feb 2013 15:48:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>)
	id 1U8YO3-0003IW-D2; Thu, 21 Feb 2013 15:48:43 +0000
Received: from [85.158.139.83:36882] by server-2.bemta-5.messagelabs.com id
	C7/74-16911-AD146215; Thu, 21 Feb 2013 15:48:42 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361461613!28592922!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26506 invoked from network); 21 Feb 2013 15:46:55 -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;
	21 Feb 2013 15:46:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8332491"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:46:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:46:50 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8YME-0007lc-08;
	Thu, 21 Feb 2013 15:46:50 +0000
MIME-Version: 1.0
X-Mercurial-Node: 1774a72fde4a51d162ea1c8ad45c9b91d9c86c2c
Message-ID: <1774a72fde4a51d162ea.1361461587@andrewcoop.uk.xensource.com>
In-Reply-To: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
References: <patchbomb.1361461583@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Thu, 21 Feb 2013 15:46:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-api@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 5 v2] tools/ocaml: libxc bindings: Fix
 stub_xc_readconsolering()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 two problems with this function:
  * The caml_{enter,leave}_blocking_section() calls mean that two threads can
    compete for use of the static ring[] buffer.
  * It fails to retrieve the entire buffer if the hypervisor has used 32K or
    more of its console ring.

Rewrite the function using the new xc_consoleringsize() and
xc_readconsolering_buffer() functions to efficiently grab the entire console
ring.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

--
Changes since v1:
 * Convert conring_size to being static to avoid needless hypercalls
 * Fix memory due to ordering of failwith_xc() and xc_hypercall_buffer_free()
 * Remove useless CAMLreturns()

diff -r 1e6c7f7cec6f -r 1774a72fde4a tools/ocaml/libs/xc/xenctrl_stubs.c
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -523,27 +523,50 @@ CAMLprim value stub_xc_evtchn_reset(valu
 	CAMLreturn(Val_unit);
 }
 
-
-#define RING_SIZE 32768
-static char ring[RING_SIZE];
-
 CAMLprim value stub_xc_readconsolering(value xch)
 {
-	unsigned int size = RING_SIZE - 1;
-	char *ring_ptr = ring;
-	int retval;
+	static int have_conring_size = 0;
+	static uint64_t conring_size;
+
+	unsigned int nr_chars;
+	DECLARE_HYPERCALL_BUFFER(char, ring);
+	int r;
 
 	CAMLparam1(xch);
+	CAMLlocal1(conring);
+
+	if ( ! have_conring_size )
+	{
+		if ( xc_consoleringsize(_H(xch), &conring_size) )
+			failwith_xc(_H(xch));
+
+		/* Round conring_size up to the next page, for NULL terminator
+		   and slop from a race with printk() in the hypervisor. */
+		conring_size = (conring_size + XC_PAGE_SIZE) & XC_PAGE_MASK;
+		have_conring_size = 0;
+	}
+
+	nr_chars = conring_size-1;
+	ring = xc_hypercall_buffer_alloc(_H(xch), ring, conring_size);
+
+	if ( ! ring )
+		caml_raise_out_of_memory();
 
 	caml_enter_blocking_section();
-	retval = xc_readconsolering(_H(xch), ring_ptr, &size, 0, 0, NULL);
+	r = xc_readconsolering_buffer(_H(xch), HYPERCALL_BUFFER(ring),
+				      &nr_chars, 0, 0, NULL);
 	caml_leave_blocking_section();
 
-	if (retval)
+	if ( r )
+	{
+		xc_hypercall_buffer_free(_H(xch), ring);
 		failwith_xc(_H(xch));
+	}
 
-	ring[size] = '\0';
-	CAMLreturn(caml_copy_string(ring));
+	ring[nr_chars] = '\0';
+	conring = caml_copy_string(ring);
+	xc_hypercall_buffer_free(_H(xch), ring);
+	CAMLreturn(conring);
 }
 
 CAMLprim value stub_xc_send_debug_keys(value xch, value keys)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:49:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:49: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 1U8YOO-0003Ql-HG; Thu, 21 Feb 2013 15:49:04 +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 1U8YOM-0003Pw-NV
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:49:02 +0000
Received: from [193.109.254.147:47810] by server-9.bemta-14.messagelabs.com id
	B7/F3-30867-DE146215; Thu, 21 Feb 2013 15:49:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361461739!8723275!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17842 invoked from network); 21 Feb 2013 15:49:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8764399"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:48:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:48:58 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8YOI-0007o5-Mv;
	Thu, 21 Feb 2013 15:48:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 15:48:58 +0000
Message-ID: <1361461738-11215-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: tim@xen.org, keir@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	jbeulich@suse.com
Subject: [Xen-devel] [PATCH] xen: consolidate implementations of LOG() 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

arm64 is going to add another one shortly, so take control now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
Cc: jbeulich@suse.com
Cc: tim@xen.org
---
 xen/arch/arm/arm32/asm-offsets.c  |    8 +-------
 xen/arch/x86/x86_64/asm-offsets.c |    8 +-------
 xen/include/xen/bitops.h          |    7 +++++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index cc1a72a..6d00c86 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -18,13 +19,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
    OFFSET(UREGS_sp, struct cpu_user_regs, sp);
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index b6d1919..6dc832c 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/perfc.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <compat/xen.h>
 #include <asm/fixmap.h>
 #include <asm/hardirq.h>
@@ -20,13 +21,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
     OFFSET(UREGS_r15, struct cpu_user_regs, r15);
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 190d96b..c6a78b6 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -175,4 +175,11 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
     return (word >> shift) | (word << (32 - shift));
 }
 
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
 #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 Feb 21 15:49:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:49: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 1U8YOO-0003Ql-HG; Thu, 21 Feb 2013 15:49:04 +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 1U8YOM-0003Pw-NV
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:49:02 +0000
Received: from [193.109.254.147:47810] by server-9.bemta-14.messagelabs.com id
	B7/F3-30867-DE146215; Thu, 21 Feb 2013 15:49:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361461739!8723275!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17842 invoked from network); 21 Feb 2013 15:49:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8764399"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 15:48:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 10:48:58 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8YOI-0007o5-Mv;
	Thu, 21 Feb 2013 15:48:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 15:48:58 +0000
Message-ID: <1361461738-11215-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: tim@xen.org, keir@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	jbeulich@suse.com
Subject: [Xen-devel] [PATCH] xen: consolidate implementations of LOG() 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

arm64 is going to add another one shortly, so take control now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
Cc: jbeulich@suse.com
Cc: tim@xen.org
---
 xen/arch/arm/arm32/asm-offsets.c  |    8 +-------
 xen/arch/x86/x86_64/asm-offsets.c |    8 +-------
 xen/include/xen/bitops.h          |    7 +++++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index cc1a72a..6d00c86 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -18,13 +19,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
    OFFSET(UREGS_sp, struct cpu_user_regs, sp);
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index b6d1919..6dc832c 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/perfc.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <compat/xen.h>
 #include <asm/fixmap.h>
 #include <asm/hardirq.h>
@@ -20,13 +21,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
     OFFSET(UREGS_r15, struct cpu_user_regs, r15);
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 190d96b..c6a78b6 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -175,4 +175,11 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
     return (word >> shift) | (word << (32 - shift));
 }
 
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
 #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 Feb 21 15:50:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:50: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 1U8YPt-0003wj-1h; Thu, 21 Feb 2013 15:50:37 +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 1U8YPq-0003wG-HM
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:50:34 +0000
Received: from [85.158.139.83:8801] by server-9.bemta-5.messagelabs.com id
	40/D6-24440-94246215; Thu, 21 Feb 2013 15:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361461799!25599892!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29108 invoked from network); 21 Feb 2013 15:49:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1740705"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:49: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.297.1;
	Thu, 21 Feb 2013 15:49:43 +0000
Message-ID: <1361461781.26546.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Feb 2013 15:49:41 +0000
In-Reply-To: <1361460324.26546.62.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 15:25 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > >     restoring state.
> > 
> > You don't seem to have addressed my other comments on v1:
> 
> I've got them in v3, I noted that I hadn't addresses you comment on this
> patch in the #0/46.

Here is v3. Needs "xen: consolidate implementations of LOG() macro"
which I've just posted.

Ian.

8<--------------------------------------------------

>From 6978a03e10316ff997c91ccd6f88be110dfcffec Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 21 Jan 2013 17:33:31 +0000
Subject: [PATCH] xen: arm: arm64 trap handling.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: use bitops.h provided LOG() macro
    use simple bl instead of preloading lr and b
    remove an incorrectly placed and inaccurate comment
    declare hyp_traps_vector as an array, avoiding & on uses
v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
    restoring state.
---
 xen/arch/arm/arm64/Makefile      |    2 +
 xen/arch/arm/arm64/asm-offsets.c |   58 +++++++++
 xen/arch/arm/arm64/entry.S       |  254 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/traps.c       |   56 +++++++++
 xen/arch/arm/smpboot.c           |    2 +-
 xen/arch/arm/traps.c             |   17 ++-
 xen/include/asm-arm/cpregs.h     |    1 +
 xen/include/asm-arm/processor.h  |    2 +-
 8 files changed, 386 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/arm/arm64/asm-offsets.c
 create mode 100644 xen/arch/arm/arm64/entry.S
 create mode 100644 xen/arch/arm/arm64/traps.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 815f305..be41f43 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,5 +1,7 @@
 subdir-y += lib
 
+obj-y += entry.o
 obj-y += mode_switch.o
 
+obj-y += traps.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
new file mode 100644
index 0000000..7949e3e
--- /dev/null
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -0,0 +1,58 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/bitops.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_LR, struct cpu_user_regs, lr);
+
+   OFFSET(UREGS_SP, struct cpu_user_regs, sp);
+   OFFSET(UREGS_PC, struct cpu_user_regs, pc);
+   OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
+
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_el0, struct cpu_user_regs, sp_el0);
+   OFFSET(UREGS_SP_el1, struct cpu_user_regs, sp_el1);
+   OFFSET(UREGS_ELR_el1, struct cpu_user_regs, elr_el1);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
new file mode 100644
index 0000000..e35b6ea
--- /dev/null
+++ b/xen/arch/arm/arm64/entry.S
@@ -0,0 +1,254 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+/*
+ * Register aliases.
+ */
+lr      .req    x30             // link register
+
+/*
+ * Stack pushing/popping (register pairs only). Equivalent to store decrement
+ * before, load increment after.
+ */
+        .macro  push, xreg1, xreg2
+        stp     \xreg1, \xreg2, [sp, #-16]!
+        .endm
+
+        .macro  pop, xreg1, xreg2
+        ldp     \xreg1, \xreg2, [sp], #16
+        .endm
+
+/*
+ * Save/restore guest mode specific state, outer stack frame
+ */
+        .macro  entry_guest, compat
+
+        add     x21, sp, #UREGS_SPSR_el1
+        mrs     x23, SPSR_EL1
+        str     x23, [x21]
+
+        .if \compat == 0 /* Aarch64 mode */
+
+        add     x21, sp, #UREGS_SP_el0
+        mrs     x22, SP_el0
+        str     x22, [x21]
+
+        add     x21, sp, #UREGS_ELR_el1
+        mrs     x22, SP_el1
+        mrs     x23, ELR_el1
+        stp     x22, x23, [x21]
+
+        .else             /* Aarch32 mode */
+
+        add     x21, sp, #UREGS_SPSR_fiq
+        mrs     x22, spsr_fiq
+        mrs     x23, spsr_irq
+        stp     w22, w23, [x21]
+
+        add     x21, sp, #UREGS_SPSR_und
+        mrs     x22, spsr_und
+        mrs     x23, spsr_abt
+        stp     w22, w23, [x21]
+
+        .endif
+
+        .endm
+
+/*
+ * Save state on entry to hypervisor
+ */
+        .macro  entry, hyp, compat
+        sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_SP)
+        push    x28, x29
+        push    x26, x27
+        push    x24, x25
+        push    x22, x23
+        push    x20, x21
+        push    x18, x19
+        push    x16, x17
+        push    x14, x15
+        push    x12, x13
+        push    x10, x11
+        push    x8, x9
+        push    x6, x7
+        push    x4, x5
+        push    x2, x3
+        push    x0, x1
+
+        .if \hyp == 1        /* Hypervisor mode */
+
+        add     x21, sp, #(UREGS_X0 - UREGS_SP)
+
+        .else                /* Guest mode */
+
+        entry_guest \compat
+        mov     x21, ~0 /* sp only valid for hyp frame XXX */
+
+        .endif
+
+        stp     lr, x21, [sp, #UREGS_LR]
+
+        mrs     x22, elr_el2
+        mrs     x23, spsr_el2
+        stp     x22, x23, [sp, #UREGS_PC]
+
+        .endm
+
+/*
+ * Bad Abort numbers
+ *-----------------
+ */
+#define BAD_SYNC        0
+#define BAD_IRQ         1
+#define BAD_FIQ         2
+#define BAD_ERROR       3
+
+        .macro  invalid, reason
+        mov     x0, sp
+        mov     x1, #\reason
+        b       do_bad_mode
+        .endm
+
+hyp_sync_invalid:
+        entry   hyp=1
+        invalid BAD_SYNC
+
+hyp_irq_invalid:
+        entry   hyp=1
+        invalid BAD_IRQ
+
+hyp_fiq_invalid:
+        entry   hyp=1
+        invalid BAD_FIQ
+
+hyp_error_invalid:
+        entry   hyp=1
+        invalid BAD_ERROR
+
+/* Traps taken in Current EL with SP_ELx */
+hyp_sync:
+        entry   hyp=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_hypervisor
+
+hyp_irq:
+        entry   hyp=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_hypervisor
+
+guest_sync:
+        entry   hyp=0, compat=0
+        invalid BAD_SYNC /* No AArch64 guest support yet */
+
+guest_irq:
+        entry   hyp=0, compat=0
+        invalid BAD_IRQ /* No AArch64 guest support yet */
+
+guest_fiq_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_FIQ
+
+guest_error_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_ERROR
+
+guest_sync_compat:
+        entry   hyp=0, compat=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_guest
+
+guest_irq_compat:
+        entry   hyp=0, compat=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_guest
+
+guest_fiq_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_FIQ
+
+guest_error_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_ERROR
+
+ENTRY(return_to_new_vcpu)
+        ldr     x21, [sp, #UREGS_CPSR]
+        and     x21, x21, #PSR_MODE_MASK
+        /* Returning to EL2? */
+        cmp     x21, #PSR_MODE_EL2t
+        ccmp    x21, #PSR_MODE_EL2h, #0x4, ne
+        b.eq    return_to_hypervisor /* Yes */
+        /* Fall thru */
+ENTRY(return_to_guest)
+        bl      leave_hypervisor_tail /* Disables interrupts on return */
+        /* Fall thru */
+ENTRY(return_to_hypervisor)
+        msr     daifset, #2 /* Mask interrupts */
+
+        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
+
+        pop     x0, x1
+        pop     x2, x3
+        pop     x4, x5
+        pop     x6, x7
+        pop     x8, x9
+
+        msr     elr_el2, x21                    // set up the return data
+        msr     spsr_el2, x22
+
+        pop     x10, x11
+        pop     x12, x13
+        pop     x14, x15
+        pop     x16, x17
+        pop     x18, x19
+        pop     x20, x21
+        pop     x22, x23
+        pop     x24, x25
+        pop     x26, x27
+        pop     x28, x29
+
+        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
+        eret
+
+/*
+ * Exception vectors.
+ */
+        .macro  ventry  label
+        .align  7
+        b       \label
+        .endm
+
+        .align  11
+ENTRY(hyp_traps_vector)
+        ventry  hyp_sync_invalid                // Synchronous EL2t
+        ventry  hyp_irq_invalid                 // IRQ EL2t
+        ventry  hyp_fiq_invalid                 // FIQ EL2t
+        ventry  hyp_error_invalid               // Error EL2t
+
+        ventry  hyp_sync                        // Synchronous EL2h
+        ventry  hyp_irq                         // IRQ EL2h
+        ventry  hyp_fiq_invalid                 // FIQ EL2h
+        ventry  hyp_error_invalid               // Error EL2h
+
+        ventry  guest_sync                      // Synchronous 64-bit EL0/EL1
+        ventry  guest_irq                       // IRQ 64-bit EL0/EL1
+        ventry  guest_fiq_invalid               // FIQ 64-bit EL0/EL1
+        ventry  guest_error_invalid             // Error 64-bit EL0/EL1
+
+        ventry  guest_sync_compat               // Synchronous 32-bit EL0/EL1
+        ventry  guest_irq_compat                // IRQ 32-bit EL0/EL1
+        ventry  guest_fiq_invalid_compat        // FIQ 32-bit EL0/EL1
+        ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
new file mode 100644
index 0000000..02ef992
--- /dev/null
+++ b/xen/arch/arm/arm64/traps.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/traps.c
+ *
+ * ARM AArch64 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <asm/system.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
+{
+    panic("Unhandled serror trap\n");
+}
+
+static const char *handler[]= {
+        "Synchronous Abort",
+        "IRQ",
+        "FIQ",
+        "Error"
+};
+
+asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
+{
+    uint64_t esr = READ_SYSREG64(ESR_EL2);
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
+           handler[reason], esr);
+
+    local_irq_disable();
+    panic("bad mode");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d8eb5d3..866ed62 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index cb8a8d2..d6bdaa7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -628,7 +628,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
-void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
     uint32_t ttbr0 = READ_CP32(TTBR0);
@@ -636,7 +636,7 @@ void dump_guest_s1_walk(struct domain *d, uint32_t addr)
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
-    printk("dom%d VA 0x%08"PRIx32"\n", d->domain_id, addr);
+    printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
     printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
@@ -692,7 +692,11 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     mmio_info_t info;
 
     info.dabt = dabt;
+#ifdef CONFIG_ARM_32
     info.gva = READ_CP32(HDFAR);
+#else
+    info.gva = READ_SYSREG64(FAR_EL2);
+#endif
 
     if (dabt.s1ptw)
         goto bad_data_abort;
@@ -713,7 +717,7 @@ bad_data_abort:
 
     /* XXX inject a suitable fault into the guest */
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32"\n",
+           "    gva=%"PRIvaddr"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
            info.gva);
@@ -736,13 +740,17 @@ bad_data_abort:
 
 asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
 {
-    union hsr hsr = { .bits = READ_CP32(HSR) };
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
 
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_32(regs, hsr);
         break;
     case HSR_EC_CP15_64:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_64(regs, hsr);
         break;
     case HSR_EC_HVC:
@@ -754,6 +762,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
     default:
+ bad_trap:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
         do_unexpected_trap("Hypervisor", regs);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 36da12e..75b6287 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -228,6 +228,7 @@
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
 #define CSSELR_EL1              CSSELR
+#define ESR_EL2                 HSR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index bd473a8..6ab466a 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -238,7 +238,7 @@ union hsr {
 #endif
 
 #ifndef __ASSEMBLY__
-extern uint32_t hyp_traps_vector[8];
+extern uint32_t hyp_traps_vector[];
 
 void panic_PAR(uint64_t par);
 
-- 
1.7.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 Feb 21 15:50:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:50: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 1U8YPt-0003wj-1h; Thu, 21 Feb 2013 15:50:37 +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 1U8YPq-0003wG-HM
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:50:34 +0000
Received: from [85.158.139.83:8801] by server-9.bemta-5.messagelabs.com id
	40/D6-24440-94246215; Thu, 21 Feb 2013 15:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361461799!25599892!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29108 invoked from network); 21 Feb 2013 15:49:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1740705"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:49: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.297.1;
	Thu, 21 Feb 2013 15:49:43 +0000
Message-ID: <1361461781.26546.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Feb 2013 15:49:41 +0000
In-Reply-To: <1361460324.26546.62.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 15:25 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > >     restoring state.
> > 
> > You don't seem to have addressed my other comments on v1:
> 
> I've got them in v3, I noted that I hadn't addresses you comment on this
> patch in the #0/46.

Here is v3. Needs "xen: consolidate implementations of LOG() macro"
which I've just posted.

Ian.

8<--------------------------------------------------

>From 6978a03e10316ff997c91ccd6f88be110dfcffec Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 21 Jan 2013 17:33:31 +0000
Subject: [PATCH] xen: arm: arm64 trap handling.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: use bitops.h provided LOG() macro
    use simple bl instead of preloading lr and b
    remove an incorrectly placed and inaccurate comment
    declare hyp_traps_vector as an array, avoiding & on uses
v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
    restoring state.
---
 xen/arch/arm/arm64/Makefile      |    2 +
 xen/arch/arm/arm64/asm-offsets.c |   58 +++++++++
 xen/arch/arm/arm64/entry.S       |  254 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/traps.c       |   56 +++++++++
 xen/arch/arm/smpboot.c           |    2 +-
 xen/arch/arm/traps.c             |   17 ++-
 xen/include/asm-arm/cpregs.h     |    1 +
 xen/include/asm-arm/processor.h  |    2 +-
 8 files changed, 386 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/arm/arm64/asm-offsets.c
 create mode 100644 xen/arch/arm/arm64/entry.S
 create mode 100644 xen/arch/arm/arm64/traps.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 815f305..be41f43 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,5 +1,7 @@
 subdir-y += lib
 
+obj-y += entry.o
 obj-y += mode_switch.o
 
+obj-y += traps.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
new file mode 100644
index 0000000..7949e3e
--- /dev/null
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -0,0 +1,58 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/bitops.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_LR, struct cpu_user_regs, lr);
+
+   OFFSET(UREGS_SP, struct cpu_user_regs, sp);
+   OFFSET(UREGS_PC, struct cpu_user_regs, pc);
+   OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
+
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_el0, struct cpu_user_regs, sp_el0);
+   OFFSET(UREGS_SP_el1, struct cpu_user_regs, sp_el1);
+   OFFSET(UREGS_ELR_el1, struct cpu_user_regs, elr_el1);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
new file mode 100644
index 0000000..e35b6ea
--- /dev/null
+++ b/xen/arch/arm/arm64/entry.S
@@ -0,0 +1,254 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+/*
+ * Register aliases.
+ */
+lr      .req    x30             // link register
+
+/*
+ * Stack pushing/popping (register pairs only). Equivalent to store decrement
+ * before, load increment after.
+ */
+        .macro  push, xreg1, xreg2
+        stp     \xreg1, \xreg2, [sp, #-16]!
+        .endm
+
+        .macro  pop, xreg1, xreg2
+        ldp     \xreg1, \xreg2, [sp], #16
+        .endm
+
+/*
+ * Save/restore guest mode specific state, outer stack frame
+ */
+        .macro  entry_guest, compat
+
+        add     x21, sp, #UREGS_SPSR_el1
+        mrs     x23, SPSR_EL1
+        str     x23, [x21]
+
+        .if \compat == 0 /* Aarch64 mode */
+
+        add     x21, sp, #UREGS_SP_el0
+        mrs     x22, SP_el0
+        str     x22, [x21]
+
+        add     x21, sp, #UREGS_ELR_el1
+        mrs     x22, SP_el1
+        mrs     x23, ELR_el1
+        stp     x22, x23, [x21]
+
+        .else             /* Aarch32 mode */
+
+        add     x21, sp, #UREGS_SPSR_fiq
+        mrs     x22, spsr_fiq
+        mrs     x23, spsr_irq
+        stp     w22, w23, [x21]
+
+        add     x21, sp, #UREGS_SPSR_und
+        mrs     x22, spsr_und
+        mrs     x23, spsr_abt
+        stp     w22, w23, [x21]
+
+        .endif
+
+        .endm
+
+/*
+ * Save state on entry to hypervisor
+ */
+        .macro  entry, hyp, compat
+        sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_SP)
+        push    x28, x29
+        push    x26, x27
+        push    x24, x25
+        push    x22, x23
+        push    x20, x21
+        push    x18, x19
+        push    x16, x17
+        push    x14, x15
+        push    x12, x13
+        push    x10, x11
+        push    x8, x9
+        push    x6, x7
+        push    x4, x5
+        push    x2, x3
+        push    x0, x1
+
+        .if \hyp == 1        /* Hypervisor mode */
+
+        add     x21, sp, #(UREGS_X0 - UREGS_SP)
+
+        .else                /* Guest mode */
+
+        entry_guest \compat
+        mov     x21, ~0 /* sp only valid for hyp frame XXX */
+
+        .endif
+
+        stp     lr, x21, [sp, #UREGS_LR]
+
+        mrs     x22, elr_el2
+        mrs     x23, spsr_el2
+        stp     x22, x23, [sp, #UREGS_PC]
+
+        .endm
+
+/*
+ * Bad Abort numbers
+ *-----------------
+ */
+#define BAD_SYNC        0
+#define BAD_IRQ         1
+#define BAD_FIQ         2
+#define BAD_ERROR       3
+
+        .macro  invalid, reason
+        mov     x0, sp
+        mov     x1, #\reason
+        b       do_bad_mode
+        .endm
+
+hyp_sync_invalid:
+        entry   hyp=1
+        invalid BAD_SYNC
+
+hyp_irq_invalid:
+        entry   hyp=1
+        invalid BAD_IRQ
+
+hyp_fiq_invalid:
+        entry   hyp=1
+        invalid BAD_FIQ
+
+hyp_error_invalid:
+        entry   hyp=1
+        invalid BAD_ERROR
+
+/* Traps taken in Current EL with SP_ELx */
+hyp_sync:
+        entry   hyp=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_hypervisor
+
+hyp_irq:
+        entry   hyp=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_hypervisor
+
+guest_sync:
+        entry   hyp=0, compat=0
+        invalid BAD_SYNC /* No AArch64 guest support yet */
+
+guest_irq:
+        entry   hyp=0, compat=0
+        invalid BAD_IRQ /* No AArch64 guest support yet */
+
+guest_fiq_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_FIQ
+
+guest_error_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_ERROR
+
+guest_sync_compat:
+        entry   hyp=0, compat=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_guest
+
+guest_irq_compat:
+        entry   hyp=0, compat=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_guest
+
+guest_fiq_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_FIQ
+
+guest_error_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_ERROR
+
+ENTRY(return_to_new_vcpu)
+        ldr     x21, [sp, #UREGS_CPSR]
+        and     x21, x21, #PSR_MODE_MASK
+        /* Returning to EL2? */
+        cmp     x21, #PSR_MODE_EL2t
+        ccmp    x21, #PSR_MODE_EL2h, #0x4, ne
+        b.eq    return_to_hypervisor /* Yes */
+        /* Fall thru */
+ENTRY(return_to_guest)
+        bl      leave_hypervisor_tail /* Disables interrupts on return */
+        /* Fall thru */
+ENTRY(return_to_hypervisor)
+        msr     daifset, #2 /* Mask interrupts */
+
+        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
+
+        pop     x0, x1
+        pop     x2, x3
+        pop     x4, x5
+        pop     x6, x7
+        pop     x8, x9
+
+        msr     elr_el2, x21                    // set up the return data
+        msr     spsr_el2, x22
+
+        pop     x10, x11
+        pop     x12, x13
+        pop     x14, x15
+        pop     x16, x17
+        pop     x18, x19
+        pop     x20, x21
+        pop     x22, x23
+        pop     x24, x25
+        pop     x26, x27
+        pop     x28, x29
+
+        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
+        eret
+
+/*
+ * Exception vectors.
+ */
+        .macro  ventry  label
+        .align  7
+        b       \label
+        .endm
+
+        .align  11
+ENTRY(hyp_traps_vector)
+        ventry  hyp_sync_invalid                // Synchronous EL2t
+        ventry  hyp_irq_invalid                 // IRQ EL2t
+        ventry  hyp_fiq_invalid                 // FIQ EL2t
+        ventry  hyp_error_invalid               // Error EL2t
+
+        ventry  hyp_sync                        // Synchronous EL2h
+        ventry  hyp_irq                         // IRQ EL2h
+        ventry  hyp_fiq_invalid                 // FIQ EL2h
+        ventry  hyp_error_invalid               // Error EL2h
+
+        ventry  guest_sync                      // Synchronous 64-bit EL0/EL1
+        ventry  guest_irq                       // IRQ 64-bit EL0/EL1
+        ventry  guest_fiq_invalid               // FIQ 64-bit EL0/EL1
+        ventry  guest_error_invalid             // Error 64-bit EL0/EL1
+
+        ventry  guest_sync_compat               // Synchronous 32-bit EL0/EL1
+        ventry  guest_irq_compat                // IRQ 32-bit EL0/EL1
+        ventry  guest_fiq_invalid_compat        // FIQ 32-bit EL0/EL1
+        ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
new file mode 100644
index 0000000..02ef992
--- /dev/null
+++ b/xen/arch/arm/arm64/traps.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/traps.c
+ *
+ * ARM AArch64 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <asm/system.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
+{
+    panic("Unhandled serror trap\n");
+}
+
+static const char *handler[]= {
+        "Synchronous Abort",
+        "IRQ",
+        "FIQ",
+        "Error"
+};
+
+asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
+{
+    uint64_t esr = READ_SYSREG64(ESR_EL2);
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
+           handler[reason], esr);
+
+    local_irq_disable();
+    panic("bad mode");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d8eb5d3..866ed62 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index cb8a8d2..d6bdaa7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -628,7 +628,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
-void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
     uint32_t ttbr0 = READ_CP32(TTBR0);
@@ -636,7 +636,7 @@ void dump_guest_s1_walk(struct domain *d, uint32_t addr)
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
-    printk("dom%d VA 0x%08"PRIx32"\n", d->domain_id, addr);
+    printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
     printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
@@ -692,7 +692,11 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     mmio_info_t info;
 
     info.dabt = dabt;
+#ifdef CONFIG_ARM_32
     info.gva = READ_CP32(HDFAR);
+#else
+    info.gva = READ_SYSREG64(FAR_EL2);
+#endif
 
     if (dabt.s1ptw)
         goto bad_data_abort;
@@ -713,7 +717,7 @@ bad_data_abort:
 
     /* XXX inject a suitable fault into the guest */
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32"\n",
+           "    gva=%"PRIvaddr"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
            info.gva);
@@ -736,13 +740,17 @@ bad_data_abort:
 
 asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
 {
-    union hsr hsr = { .bits = READ_CP32(HSR) };
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
 
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_32(regs, hsr);
         break;
     case HSR_EC_CP15_64:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_64(regs, hsr);
         break;
     case HSR_EC_HVC:
@@ -754,6 +762,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
     default:
+ bad_trap:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
         do_unexpected_trap("Hypervisor", regs);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 36da12e..75b6287 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -228,6 +228,7 @@
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
 #define CSSELR_EL1              CSSELR
+#define ESR_EL2                 HSR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index bd473a8..6ab466a 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -238,7 +238,7 @@ union hsr {
 #endif
 
 #ifndef __ASSEMBLY__
-extern uint32_t hyp_traps_vector[8];
+extern uint32_t hyp_traps_vector[];
 
 void panic_PAR(uint64_t par);
 
-- 
1.7.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 Feb 21 15:51:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 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 1U8YQl-0004AY-Ma; Thu, 21 Feb 2013 15:51:31 +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 1U8YQk-0004AD-Bk
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:51:30 +0000
Received: from [85.158.137.99:39119] by server-9.bemta-3.messagelabs.com id
	31/D7-09484-18246215; Thu, 21 Feb 2013 15:51:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361461838!14174120!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31822 invoked from network); 21 Feb 2013 15:50:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:50:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 15:50:38 +0000
Message-Id: <5126509802000078000C0074@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 15:51:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
	<1361459927.26546.59.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361459927.26546.59.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:18, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
>> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> > If any committer needs help getting git to work please feel free to
>> > ask.  git has many advantages but its user interface has received very
>> > mixed reviews.  We appreciate that you might need handholding.  So if
>> > you get confused, or into trouble, do consult.
>> 
>> So one thing I found very handy with hg was that there was a
>> single line history with easy to look at changeset numbers. Is there
>> any way to achieve the same with git? I'm asking particularly in the
>> context of backporting: In order to pick changes from unstable (now
>> master), so far I simply scanned the history, tracking (on a sheet of
>> paper) at which c/s I last left off.
> 
> Something like git log --oneline?
> 
> You can also git log --pretty=format:%...

The question is whether these, just like the web interface, sort
by commit time rather than commit order.

And ideally it would be doable both locally and from the web
interface, yet I don't see the web interface having any way to
control how it sorts its output.

> Where there are various available %foo described in the manpage.
> 
> git doesn't really have a concept of the shorter sequential numbers
> which mercurial has. The closest I can think of is the sort of thing
> which git describe outputs.

Again, it depends how the number produced here gets calculated,
i.e. whether it remains stable over the lifetime of a tree regardless
of what commits get pulled (and merges get done).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:51:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 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 1U8YQl-0004AY-Ma; Thu, 21 Feb 2013 15:51:31 +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 1U8YQk-0004AD-Bk
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:51:30 +0000
Received: from [85.158.137.99:39119] by server-9.bemta-3.messagelabs.com id
	31/D7-09484-18246215; Thu, 21 Feb 2013 15:51:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361461838!14174120!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31822 invoked from network); 21 Feb 2013 15:50:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:50:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 15:50:38 +0000
Message-Id: <5126509802000078000C0074@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 15:51:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
	<1361459927.26546.59.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361459927.26546.59.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:18, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
>> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> > If any committer needs help getting git to work please feel free to
>> > ask.  git has many advantages but its user interface has received very
>> > mixed reviews.  We appreciate that you might need handholding.  So if
>> > you get confused, or into trouble, do consult.
>> 
>> So one thing I found very handy with hg was that there was a
>> single line history with easy to look at changeset numbers. Is there
>> any way to achieve the same with git? I'm asking particularly in the
>> context of backporting: In order to pick changes from unstable (now
>> master), so far I simply scanned the history, tracking (on a sheet of
>> paper) at which c/s I last left off.
> 
> Something like git log --oneline?
> 
> You can also git log --pretty=format:%...

The question is whether these, just like the web interface, sort
by commit time rather than commit order.

And ideally it would be doable both locally and from the web
interface, yet I don't see the web interface having any way to
control how it sorts its output.

> Where there are various available %foo described in the manpage.
> 
> git doesn't really have a concept of the shorter sequential numbers
> which mercurial has. The closest I can think of is the sort of thing
> which git describe outputs.

Again, it depends how the number produced here gets calculated,
i.e. whether it remains stable over the lifetime of a tree regardless
of what commits get pulled (and merges get done).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 15:52:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YRi-0004PK-5R; Thu, 21 Feb 2013 15:52: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 1U8YRg-0004Oi-JV
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:52:28 +0000
Received: from [85.158.139.83:11406] by server-9.bemta-5.messagelabs.com id
	C0/BB-24440-BB246215; Thu, 21 Feb 2013 15:52:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1361461945!28226977!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24817 invoked from network); 21 Feb 2013 15:52:26 -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; 21 Feb 2013 15:52:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YRd-0007WU-1I; Thu, 21 Feb 2013 15:52:25 +0000
Date: Thu, 21 Feb 2013 15:52:24 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221155224.GA24051@ocelot.phlegethon.org>
References: <1361461738-11215-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361461738-11215-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: consolidate implementations of LOG()
	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

At 15:48 +0000 on 21 Feb (1361461738), Ian Campbell wrote:
> arm64 is going to add another one shortly, so take control now.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: keir@xen.org
> Cc: jbeulich@suse.com
> Cc: tim@xen.org

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 Thu Feb 21 15:52:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15: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 1U8YRi-0004PK-5R; Thu, 21 Feb 2013 15:52: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 1U8YRg-0004Oi-JV
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:52:28 +0000
Received: from [85.158.139.83:11406] by server-9.bemta-5.messagelabs.com id
	C0/BB-24440-BB246215; Thu, 21 Feb 2013 15:52:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1361461945!28226977!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24817 invoked from network); 21 Feb 2013 15:52:26 -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; 21 Feb 2013 15:52:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YRd-0007WU-1I; Thu, 21 Feb 2013 15:52:25 +0000
Date: Thu, 21 Feb 2013 15:52:24 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20130221155224.GA24051@ocelot.phlegethon.org>
References: <1361461738-11215-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361461738-11215-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: consolidate implementations of LOG()
	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

At 15:48 +0000 on 21 Feb (1361461738), Ian Campbell wrote:
> arm64 is going to add another one shortly, so take control now.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: keir@xen.org
> Cc: jbeulich@suse.com
> Cc: tim@xen.org

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 Thu Feb 21 15:53:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:53: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 1U8YSh-0004aL-Lu; Thu, 21 Feb 2013 15:53:31 +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 1U8YSg-0004a2-73
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:53:30 +0000
Received: from [85.158.143.99:13964] by server-3.bemta-4.messagelabs.com id
	02/7E-02186-9F246215; Thu, 21 Feb 2013 15:53:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361462003!27961086!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15276 invoked from network); 21 Feb 2013 15:53:24 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:53:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YSS-0007Wt-23; Thu, 21 Feb 2013 15:53:16 +0000
Date: Thu, 21 Feb 2013 15:53:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221155316.GB24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<1361461781.26546.71.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361461781.26546.71.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 15:49 +0000 on 21 Feb (1361461781), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:25 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > >     restoring state.
> > > 
> > > You don't seem to have addressed my other comments on v1:
> > 
> > I've got them in v3, I noted that I hadn't addresses you comment on this
> > patch in the #0/46.
> 
> Here is v3. Needs "xen: consolidate implementations of LOG() macro"
> which I've just posted.
> 
> Ian.
> 
> 8<--------------------------------------------------
> 
> From 6978a03e10316ff997c91ccd6f88be110dfcffec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 21 Jan 2013 17:33:31 +0000
> Subject: [PATCH] xen: arm: arm64 trap handling.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:53:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:53: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 1U8YSh-0004aL-Lu; Thu, 21 Feb 2013 15:53:31 +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 1U8YSg-0004a2-73
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:53:30 +0000
Received: from [85.158.143.99:13964] by server-3.bemta-4.messagelabs.com id
	02/7E-02186-9F246215; Thu, 21 Feb 2013 15:53:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361462003!27961086!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15276 invoked from network); 21 Feb 2013 15:53:24 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 15:53:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YSS-0007Wt-23; Thu, 21 Feb 2013 15:53:16 +0000
Date: Thu, 21 Feb 2013 15:53:16 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221155316.GB24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<1361461781.26546.71.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361461781.26546.71.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 15:49 +0000 on 21 Feb (1361461781), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:25 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > >     restoring state.
> > > 
> > > You don't seem to have addressed my other comments on v1:
> > 
> > I've got them in v3, I noted that I hadn't addresses you comment on this
> > patch in the #0/46.
> 
> Here is v3. Needs "xen: consolidate implementations of LOG() macro"
> which I've just posted.
> 
> Ian.
> 
> 8<--------------------------------------------------
> 
> From 6978a03e10316ff997c91ccd6f88be110dfcffec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 21 Jan 2013 17:33:31 +0000
> Subject: [PATCH] xen: arm: arm64 trap handling.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 15:59:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:59: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 1U8YYN-00056u-ME; Thu, 21 Feb 2013 15:59: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 1U8YYM-00056n-QD
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:59:23 +0000
Received: from [85.158.137.99:4435] by server-13.bemta-3.messagelabs.com id
	27/B1-20653-95446215; Thu, 21 Feb 2013 15:59:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361462320!17443728!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8307 invoked from network); 21 Feb 2013 15:58:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:58: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.297.1;
	Thu, 21 Feb 2013 15:58:41 +0000
Message-ID: <1361462319.26546.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Feb 2013 15:58:39 +0000
In-Reply-To: <1361460460.26546.64.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
	<20130221150157.GQ24051@ocelot.phlegethon.org>
	<1361460460.26546.64.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 14/46] xen: arm64: barriers and wait for
 interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 15:27 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:01 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860448), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Acked-by: Tim Deegan <tim@xen.org>
> > 
> > Were we also talking about having smb_ barriers equivalent to the normas
> > ones, like on x86?
> 
> Yes, I think in a F2F conversation which is why I forgot.

FYI it ended up like this. I retained your Ack, hope that's ok.

8<--------------------------------

>From 117f08d439bca2798db71b9971429e32424ad092 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 13 Dec 2012 13:18:07 +0000
Subject: [PATCH] xen: arm64: barriers and wait for interrupts/events

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: - smp barriers are the same as up (which are conservative)
    - add dmb

---
 xen/include/asm-arm/arm32/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   20 ++++++++------------
 3 files changed, 66 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/system.h
 create mode 100644 xen/include/asm-arm/arm64/system.h

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
new file mode 100644
index 0000000..91098a0
--- /dev/null
+++ b/xen/include/asm-arm/arm32/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_ARM32_SYSTEM_H
+#define __ASM_ARM32_SYSTEM_H
+
+#define sev() __asm__ __volatile__ ("sev" : : : "memory")
+#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
+#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
new file mode 100644
index 0000000..b3ea4a3
--- /dev/null
+++ b/xen/include/asm-arm/arm64/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm64 */
+#ifndef __ASM_ARM64_SYSTEM_H
+#define __ASM_ARM64_SYSTEM_H
+
+#define sev()           asm volatile("sev" : : : "memory")
+#define wfe()           asm volatile("wfe" : : : "memory")
+#define wfi()           asm volatile("wfi" : : : "memory")
+
+#define isb()           asm volatile("isb" : : : "memory")
+#define dsb()           asm volatile("dsb sy" : : : "memory")
+#define dmb()           asm volatile("dmb sy" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 216ef1f..8b4c97a 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -11,18 +11,6 @@
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
 
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
-
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           mb()
-
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
-
 /*
  * This is used to ensure the compiler did actually allocate the register we
  * asked it for some inline assembly sequences.  Apparently we can't trust
@@ -33,6 +21,14 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/system.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/system.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 extern void __bad_xchg(volatile void *, int);
 
 static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 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 Thu Feb 21 15:59:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 15:59: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 1U8YYN-00056u-ME; Thu, 21 Feb 2013 15:59: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 1U8YYM-00056n-QD
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 15:59:23 +0000
Received: from [85.158.137.99:4435] by server-13.bemta-3.messagelabs.com id
	27/B1-20653-95446215; Thu, 21 Feb 2013 15:59:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361462320!17443728!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8307 invoked from network); 21 Feb 2013 15:58:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 15:58:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 15:58: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.297.1;
	Thu, 21 Feb 2013 15:58:41 +0000
Message-ID: <1361462319.26546.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Feb 2013 15:58:39 +0000
In-Reply-To: <1361460460.26546.64.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-14-git-send-email-ian.campbell@citrix.com>
	<20130221150157.GQ24051@ocelot.phlegethon.org>
	<1361460460.26546.64.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 14/46] xen: arm64: barriers and wait for
 interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 15:27 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:01 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860448), Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Acked-by: Tim Deegan <tim@xen.org>
> > 
> > Were we also talking about having smb_ barriers equivalent to the normas
> > ones, like on x86?
> 
> Yes, I think in a F2F conversation which is why I forgot.

FYI it ended up like this. I retained your Ack, hope that's ok.

8<--------------------------------

>From 117f08d439bca2798db71b9971429e32424ad092 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 13 Dec 2012 13:18:07 +0000
Subject: [PATCH] xen: arm64: barriers and wait for interrupts/events

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: - smp barriers are the same as up (which are conservative)
    - add dmb

---
 xen/include/asm-arm/arm32/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   20 ++++++++------------
 3 files changed, 66 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/system.h
 create mode 100644 xen/include/asm-arm/arm64/system.h

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
new file mode 100644
index 0000000..91098a0
--- /dev/null
+++ b/xen/include/asm-arm/arm32/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_ARM32_SYSTEM_H
+#define __ASM_ARM32_SYSTEM_H
+
+#define sev() __asm__ __volatile__ ("sev" : : : "memory")
+#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
+#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
new file mode 100644
index 0000000..b3ea4a3
--- /dev/null
+++ b/xen/include/asm-arm/arm64/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm64 */
+#ifndef __ASM_ARM64_SYSTEM_H
+#define __ASM_ARM64_SYSTEM_H
+
+#define sev()           asm volatile("sev" : : : "memory")
+#define wfe()           asm volatile("wfe" : : : "memory")
+#define wfi()           asm volatile("wfi" : : : "memory")
+
+#define isb()           asm volatile("isb" : : : "memory")
+#define dsb()           asm volatile("dsb sy" : : : "memory")
+#define dmb()           asm volatile("dmb sy" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        dmb()
+#define smp_rmb()       dmb()
+#define smp_wmb()       dmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 216ef1f..8b4c97a 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -11,18 +11,6 @@
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
 
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
-
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           mb()
-
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
-
 /*
  * This is used to ensure the compiler did actually allocate the register we
  * asked it for some inline assembly sequences.  Apparently we can't trust
@@ -33,6 +21,14 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/system.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/system.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 extern void __bad_xchg(volatile void *, int);
 
 static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 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 Thu Feb 21 16:01:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:01: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 1U8YaP-0005hl-Kp; Thu, 21 Feb 2013 16:01: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 1U8YaO-0005hL-Aa
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:01:28 +0000
Received: from [85.158.138.51:10916] by server-9.bemta-3.messagelabs.com id
	8C/2C-09484-8D446215; Thu, 21 Feb 2013 16:01:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361462487!28644170!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8492 invoked from network); 21 Feb 2013 16:01:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:01:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:01: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.297.1;
	Thu, 21 Feb 2013 16:01:27 +0000
Message-ID: <1361462485.26546.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 16:01:25 +0000
In-Reply-To: <1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>
> but:
>         This is mostly a matter of coding taste, so I'd like Stefano's
>         ack/nack here as well.


Stefano, any strong opinion?

> ---
> ---
>  xen/arch/arm/domain_build.c |    2 +-
>  xen/arch/arm/smpboot.c      |    2 +-
>  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
>  xen/arch/arm/vgic.c         |   18 ++++++++--------
>  xen/arch/arm/vpl011.c       |    6 ++--
>  xen/arch/arm/vtimer.c       |    6 ++--
>  xen/include/asm-arm/regs.h  |    2 +-
>  xen/include/asm-arm/types.h |    4 +++
>  8 files changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..30d014a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> 
>  static void dtb_load(struct kernel_info *kinfo)
>  {
> -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> 
>      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
>      xfree(kinfo->fdt);
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 86379b7..d8eb5d3 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
>      set_processor_id(cpuid);
> 
>      /* Setup Hyp vector base */
> -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> 
>      mmu_init_secondary_cpu();
>      enable_vfp();
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index eaf1f52..0299b33 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -68,7 +68,7 @@ static void print_xen_info(void)
>             debug_build() ? 'y' : 'n', print_tainted(taint_str));
>  }
> 
> -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
>  {
>      BUG_ON( !guest_mode(regs) );
> 
> @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> 
>      switch ( reg ) {
>      case 0 ... 7: /* Unbanked registers */
> -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
>          return &regs->r0 + reg;
>      case 8 ... 12: /* Register banked in FIQ mode */
> -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
>          if ( fiq_mode(regs) )
>              return &regs->r8_fiq + reg - 8;
>          else
>              return &regs->r8 + reg - 8;
>      case 13 ... 14: /* Banked SP + LR registers */
> -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
>          switch ( regs->cpsr & PSR_MODE_MASK )
>          {
>          case PSR_MODE_USR:
> @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
>      printk("GUEST STACK GOES HERE\n");
>  }
> 
> -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> 
>  static void show_trace(struct cpu_user_regs *regs)
>  {
> -    uint32_t *frame, next, addr, low, high;
> +    register_t *frame, next, addr, low, high;
> 
>      printk("Xen call trace:\n   ");
> 
> @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
>      print_symbol(" %s\n   ", regs->pc);
> 
>      /* Bounds for range of valid frame pointer. */
> -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
>      high = (low & ~(STACK_SIZE - 1)) +
>          (STACK_SIZE - sizeof(struct cpu_info));
> 
> @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
>              break;
>          {
>              /* Ordinary stack frame. */
> -            frame = (uint32_t *)next;
> +            frame = (register_t *)next;
>              next  = frame[-1];
>              addr  = frame[0];
>          }
> @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
>          printk("[<%p>]", _p(addr));
>          print_symbol(" %s\n   ", addr);
> 
> -        low = (uint32_t)&frame[1];
> +        low = (register_t)&frame[1];
>      }
> 
>      printk("\n");
> @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> 
>  void show_stack(struct cpu_user_regs *regs)
>  {
> -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
>      int i;
> 
>      if ( guest_mode(regs) )
> @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> 
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  {
> -    uint32_t reg, *r;
> +    register_t *r;
> +    uint32_t reg;
>      uint32_t domid = current->domain->domain_id;
>      switch ( code ) {
>      case 0xe0 ... 0xef:
>          reg = code - 0xe0;
>          r = select_user_reg(regs, reg);
> -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
>                 domid, reg, *r, regs->pc);
>          break;
>      case 0xfd:
> -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
>          break;
>      case 0xfe:
> -        printk("%c", (char)(regs->r0 & 0xff));
> +        r = select_user_reg(regs, 0);
> +        printk("%c", (char)(*r & 0xff));
>          break;
>      case 0xff:
>          printk("DOM%d: DEBUG\n", domid);
> @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>                         union hsr hsr)
>  {
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> 
>      if ( !cp32.ccvalid ) {
>          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
>                 cp32.read ? "mrc" : "mcr",
>                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
>          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
>                 cp64.read ? "mrrc" : "mcrr",
>                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
>          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 39b9775..57147d5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> 
>      case GICD_ISPENDR ... GICD_ISPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
>          return 0;
> 
>      case GICD_ICPENDR ... GICD_ICPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
>          return 0;
> 
> @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> 
>      case GICD_SGIR:
>          if ( dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
>                 *r, gicd_reg - GICD_ICFGR);
>          return 0;
> 
>      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
>          return 0;
> 
>      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
>          return 0;
> 
> @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>          goto write_ignore;
> 
>      default:
> -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          return 0;
>      }
> 
>  bad_width:
> -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
>             dabt.size, dabt.reg, *r, offset);
>      domain_crash_synchronous();
>      return 0;
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 7dcee90..db5094e 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
> 
>      switch ( offset )
> @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
> 
>      switch ( offset )
> @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>          /* Silently ignore */
>          return 1;
>      default:
> -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          domain_crash_synchronous();
>      }
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 85201b5..291b87e 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
>      s_time_t now;
> 
>      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp64 cp64 = hsr.cp64;
> -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
>      uint64_t ticks;
>      s_time_t now;
> 
> diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> index 7486944..a723f92 100644
> --- a/xen/include/asm-arm/regs.h
> +++ b/xen/include/asm-arm/regs.h
> @@ -34,7 +34,7 @@
>   * Returns a pointer to the given register value in regs, taking the
>   * processor mode (CPSR) into account.
>   */
> -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> 
>  #endif /* __ARM_REGS_H__ */
>  /*
> diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> index d3e16d8..9ca32f1 100644
> --- a/xen/include/asm-arm/types.h
> +++ b/xen/include/asm-arm/types.h
> @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0ULL)
>  #define PRIpaddr "016llx"
> +typedef u32 register_t;
> +#define PRIregister "x"
>  #elif defined (CONFIG_ARM_64)
>  typedef signed long s64;
>  typedef unsigned long u64;
> @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0UL)
>  #define PRIpaddr "016lx"
> +typedef u64 register_t;
> +#define PRIregister "lx"
>  #endif
> 
>  typedef unsigned long size_t;
> --
> 1.7.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 Feb 21 16:01:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:01: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 1U8YaP-0005hl-Kp; Thu, 21 Feb 2013 16:01: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 1U8YaO-0005hL-Aa
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:01:28 +0000
Received: from [85.158.138.51:10916] by server-9.bemta-3.messagelabs.com id
	8C/2C-09484-8D446215; Thu, 21 Feb 2013 16:01:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361462487!28644170!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8492 invoked from network); 21 Feb 2013 16:01:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:01:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:01: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.297.1;
	Thu, 21 Feb 2013 16:01:27 +0000
Message-ID: <1361462485.26546.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 16:01:25 +0000
In-Reply-To: <1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Tim Deegan <tim@xen.org>
> but:
>         This is mostly a matter of coding taste, so I'd like Stefano's
>         ack/nack here as well.


Stefano, any strong opinion?

> ---
> ---
>  xen/arch/arm/domain_build.c |    2 +-
>  xen/arch/arm/smpboot.c      |    2 +-
>  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
>  xen/arch/arm/vgic.c         |   18 ++++++++--------
>  xen/arch/arm/vpl011.c       |    6 ++--
>  xen/arch/arm/vtimer.c       |    6 ++--
>  xen/include/asm-arm/regs.h  |    2 +-
>  xen/include/asm-arm/types.h |    4 +++
>  8 files changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7403f1a..30d014a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> 
>  static void dtb_load(struct kernel_info *kinfo)
>  {
> -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> 
>      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
>      xfree(kinfo->fdt);
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 86379b7..d8eb5d3 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
>      set_processor_id(cpuid);
> 
>      /* Setup Hyp vector base */
> -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> 
>      mmu_init_secondary_cpu();
>      enable_vfp();
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index eaf1f52..0299b33 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -68,7 +68,7 @@ static void print_xen_info(void)
>             debug_build() ? 'y' : 'n', print_tainted(taint_str));
>  }
> 
> -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
>  {
>      BUG_ON( !guest_mode(regs) );
> 
> @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> 
>      switch ( reg ) {
>      case 0 ... 7: /* Unbanked registers */
> -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
>          return &regs->r0 + reg;
>      case 8 ... 12: /* Register banked in FIQ mode */
> -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
>          if ( fiq_mode(regs) )
>              return &regs->r8_fiq + reg - 8;
>          else
>              return &regs->r8 + reg - 8;
>      case 13 ... 14: /* Banked SP + LR registers */
> -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
>          switch ( regs->cpsr & PSR_MODE_MASK )
>          {
>          case PSR_MODE_USR:
> @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
>      printk("GUEST STACK GOES HERE\n");
>  }
> 
> -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> 
>  static void show_trace(struct cpu_user_regs *regs)
>  {
> -    uint32_t *frame, next, addr, low, high;
> +    register_t *frame, next, addr, low, high;
> 
>      printk("Xen call trace:\n   ");
> 
> @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
>      print_symbol(" %s\n   ", regs->pc);
> 
>      /* Bounds for range of valid frame pointer. */
> -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
>      high = (low & ~(STACK_SIZE - 1)) +
>          (STACK_SIZE - sizeof(struct cpu_info));
> 
> @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
>              break;
>          {
>              /* Ordinary stack frame. */
> -            frame = (uint32_t *)next;
> +            frame = (register_t *)next;
>              next  = frame[-1];
>              addr  = frame[0];
>          }
> @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
>          printk("[<%p>]", _p(addr));
>          print_symbol(" %s\n   ", addr);
> 
> -        low = (uint32_t)&frame[1];
> +        low = (register_t)&frame[1];
>      }
> 
>      printk("\n");
> @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> 
>  void show_stack(struct cpu_user_regs *regs)
>  {
> -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
>      int i;
> 
>      if ( guest_mode(regs) )
> @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> 
>  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
>  {
> -    uint32_t reg, *r;
> +    register_t *r;
> +    uint32_t reg;
>      uint32_t domid = current->domain->domain_id;
>      switch ( code ) {
>      case 0xe0 ... 0xef:
>          reg = code - 0xe0;
>          r = select_user_reg(regs, reg);
> -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
>                 domid, reg, *r, regs->pc);
>          break;
>      case 0xfd:
> -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
>          break;
>      case 0xfe:
> -        printk("%c", (char)(regs->r0 & 0xff));
> +        r = select_user_reg(regs, 0);
> +        printk("%c", (char)(*r & 0xff));
>          break;
>      case 0xff:
>          printk("DOM%d: DEBUG\n", domid);
> @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>                         union hsr hsr)
>  {
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> 
>      if ( !cp32.ccvalid ) {
>          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
>                 cp32.read ? "mrc" : "mcr",
>                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
>          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
>          BUG_ON(!vtimer_emulate(regs, hsr));
>          break;
>      default:
> -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
>                 cp64.read ? "mrrc" : "mcrr",
>                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
>          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 39b9775..57147d5 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      struct vgic_irq_rank *rank;
>      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
>      int gicd_reg = REG(offset);
> @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> 
>      case GICD_ISPENDR ... GICD_ISPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
>          return 0;
> 
>      case GICD_ICPENDR ... GICD_ICPENDRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
>          return 0;
> 
> @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> 
>      case GICD_SGIR:
>          if ( dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
>                 *r, gicd_reg - GICD_ICFGR);
>          return 0;
> 
>      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
>          return 0;
> 
>      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
>          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
>                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
>          return 0;
> 
> @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
>          goto write_ignore;
> 
>      default:
> -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          return 0;
>      }
> 
>  bad_width:
> -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
>             dabt.size, dabt.reg, *r, offset);
>      domain_crash_synchronous();
>      return 0;
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 7dcee90..db5094e 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
> 
>      switch ( offset )
> @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>  {
>      struct hsr_dabt dabt = info->dabt;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
> -    uint32_t *r = select_user_reg(regs, dabt.reg);
> +    register_t *r = select_user_reg(regs, dabt.reg);
>      int offset = (int)(info->gpa - UART0_START);
> 
>      switch ( offset )
> @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
>          /* Silently ignore */
>          return 1;
>      default:
> -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
>                 dabt.reg, *r, offset);
>          domain_crash_synchronous();
>      }
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 85201b5..291b87e 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp32 cp32 = hsr.cp32;
> -    uint32_t *r = select_user_reg(regs, cp32.reg);
> +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
>      s_time_t now;
> 
>      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
>  {
>      struct vcpu *v = current;
>      struct hsr_cp64 cp64 = hsr.cp64;
> -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
>      uint64_t ticks;
>      s_time_t now;
> 
> diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> index 7486944..a723f92 100644
> --- a/xen/include/asm-arm/regs.h
> +++ b/xen/include/asm-arm/regs.h
> @@ -34,7 +34,7 @@
>   * Returns a pointer to the given register value in regs, taking the
>   * processor mode (CPSR) into account.
>   */
> -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> 
>  #endif /* __ARM_REGS_H__ */
>  /*
> diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> index d3e16d8..9ca32f1 100644
> --- a/xen/include/asm-arm/types.h
> +++ b/xen/include/asm-arm/types.h
> @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0ULL)
>  #define PRIpaddr "016llx"
> +typedef u32 register_t;
> +#define PRIregister "x"
>  #elif defined (CONFIG_ARM_64)
>  typedef signed long s64;
>  typedef unsigned long u64;
> @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0UL)
>  #define PRIpaddr "016lx"
> +typedef u64 register_t;
> +#define PRIregister "lx"
>  #endif
> 
>  typedef unsigned long size_t;
> --
> 1.7.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 Feb 21 16:01:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:01: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 1U8YaN-0005hT-6g; Thu, 21 Feb 2013 16:01:27 +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 1U8YaL-0005hL-Tt
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:01:26 +0000
Received: from [85.158.138.51:21717] by server-9.bemta-3.messagelabs.com id
	C4/0C-09484-5D446215; Thu, 21 Feb 2013 16:01:25 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361462482!28601476!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24771 invoked from network); 21 Feb 2013 16:01:24 -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;
	21 Feb 2013 16:01:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8770024"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:01:21 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Thu, 21 Feb 2013
	11:01:21 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, Ian Campbell
	<Ian.Campbell@citrix.com>
Date: Thu, 21 Feb 2013 11:01:14 -0500
Thread-Topic: [Xen-devel] xl segfaults on latest staging/xen-unstable
Thread-Index: Ac4OK6EltdgPfSn+Q7OhO21YRR6NiACIK9ZA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320CC33BC@FTLPMAILBOX02.citrite.net>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
	<836217002.20130218235800@eikelenboom.it>
In-Reply-To: <836217002.20130218235800@eikelenboom.it>
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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Sander Eikelenboom
> Sent: Monday, February 18, 2013 5:58 PM
> To: Ian Campbell
> Cc: xen-devel
> Subject: Re: [Xen-devel] xl segfaults on latest staging/xen-unstable
> 
> 
> Monday, February 18, 2013, 11:52:38 AM, you wrote:
> 
> > On Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
> >> Hi All,
> >>
> >> Just tried the latest staging/xen-unstable (on debian squeeze dom0)
> but xl seems to segfaults (at least on domain creation):
> >> Previous pull was working fine and was about 3 or 4 days ago.
> 
> > Do you happen to know the exact revisions?
> 
> > Please can you try running xl under gdb and get a backtrace.
> 
> Hmm sorry for the noise, didn't properly cleanup stale files from the
> reverted "install to /usr/local/" changes.
> That went ok from jan 27th till now .. so it didn't immediately rang a
> bell.
> 
> --
> Sander
> 

Yes I got hit with that recently too. BTW I noticed in the configure script
that ac_default_prefix is set twice, as in:

ac_default_prefix=/usr/local

... a bit later on

ac_default_prefix=/usr

Is that intentional or an artifact?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:01:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:01: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 1U8YaN-0005hT-6g; Thu, 21 Feb 2013 16:01:27 +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 1U8YaL-0005hL-Tt
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:01:26 +0000
Received: from [85.158.138.51:21717] by server-9.bemta-3.messagelabs.com id
	C4/0C-09484-5D446215; Thu, 21 Feb 2013 16:01:25 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361462482!28601476!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24771 invoked from network); 21 Feb 2013 16:01:24 -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;
	21 Feb 2013 16:01:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8770024"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:01:21 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Thu, 21 Feb 2013
	11:01:21 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, Ian Campbell
	<Ian.Campbell@citrix.com>
Date: Thu, 21 Feb 2013 11:01:14 -0500
Thread-Topic: [Xen-devel] xl segfaults on latest staging/xen-unstable
Thread-Index: Ac4OK6EltdgPfSn+Q7OhO21YRR6NiACIK9ZA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A320CC33BC@FTLPMAILBOX02.citrite.net>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
	<836217002.20130218235800@eikelenboom.it>
In-Reply-To: <836217002.20130218235800@eikelenboom.it>
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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Sander Eikelenboom
> Sent: Monday, February 18, 2013 5:58 PM
> To: Ian Campbell
> Cc: xen-devel
> Subject: Re: [Xen-devel] xl segfaults on latest staging/xen-unstable
> 
> 
> Monday, February 18, 2013, 11:52:38 AM, you wrote:
> 
> > On Mon, 2013-02-18 at 10:21 +0000, Sander Eikelenboom wrote:
> >> Hi All,
> >>
> >> Just tried the latest staging/xen-unstable (on debian squeeze dom0)
> but xl seems to segfaults (at least on domain creation):
> >> Previous pull was working fine and was about 3 or 4 days ago.
> 
> > Do you happen to know the exact revisions?
> 
> > Please can you try running xl under gdb and get a backtrace.
> 
> Hmm sorry for the noise, didn't properly cleanup stale files from the
> reverted "install to /usr/local/" changes.
> That went ok from jan 27th till now .. so it didn't immediately rang a
> bell.
> 
> --
> Sander
> 

Yes I got hit with that recently too. BTW I noticed in the configure script
that ac_default_prefix is set twice, as in:

ac_default_prefix=/usr/local

... a bit later on

ac_default_prefix=/usr

Is that intentional or an artifact?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:01:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:01: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 1U8Yak-0005t4-96; Thu, 21 Feb 2013 16:01:50 +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 1U8Yaj-0005rB-EL
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:01:49 +0000
Received: from [85.158.143.99:35099] by server-1.bemta-4.messagelabs.com id
	57/71-06203-CE446215; Thu, 21 Feb 2013 16:01:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361462481!27962773!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25918 invoked from network); 21 Feb 2013 16:01:23 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:01:23 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so665324wgb.0
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 08:01:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=2wPSfPn8sd1RfAKu/skPh/VJ1dnzVHv0b3RTIQyOWgY=;
	b=kb+W7DCZ2LU0YTIUVmN0GP/mlahku76dWB/aYZD4okoe0RrG1eIbkhedUFIn4ilOIr
	iRyqUED5hyY0bBUfeEVQ9+cxBbeeRzzV+bGzPhBKuMgRXdhjWDm1Av6sVbJ/D8Ih8YsD
	P2BiInPLVmzi7gpNde4HRbUeIpXyaFiJXN2jTS8ElhTGfzH84AopTq2jJoVGVqR66cHI
	pbXsXNh6qeUICXi/hWNzpvxT0Yx3/eNDS8BHVdfRyTx6m6i0Xr5nivV/GRZZpflhoX55
	Fz9MRysZteuJaGFnwQX2j2W1OUT3B9Bn1N7f+Gsg/iZbngVN4Hu4oWU9bSgQwriEsOLn
	+Kgw==
X-Received: by 10.194.5.4 with SMTP id o4mr35546518wjo.40.1361462481082;
	Thu, 21 Feb 2013 08:01:21 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id q13sm4279485wie.0.2013.02.21.08.01.16
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 08:01:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 16:01:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Message-ID: <CD4BF54B.4C6E5%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen: consolidate implementations of LOG() macro
Thread-Index: Ac4QTK038vKTiQZ71UOErPJbad0TXg==
In-Reply-To: <20130221155224.GA24051@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: consolidate implementations of LOG()
	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

On 21/02/2013 15:52, "Tim Deegan" <tim@xen.org> wrote:

> At 15:48 +0000 on 21 Feb (1361461738), Ian Campbell wrote:
>> arm64 is going to add another one shortly, so take control now.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: keir@xen.org
>> Cc: jbeulich@suse.com
>> Cc: tim@xen.org
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 

Acked-by: Keir Fraser <keir@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:01:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:01: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 1U8Yak-0005t4-96; Thu, 21 Feb 2013 16:01:50 +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 1U8Yaj-0005rB-EL
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:01:49 +0000
Received: from [85.158.143.99:35099] by server-1.bemta-4.messagelabs.com id
	57/71-06203-CE446215; Thu, 21 Feb 2013 16:01:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361462481!27962773!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25918 invoked from network); 21 Feb 2013 16:01:23 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:01:23 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so665324wgb.0
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 08:01:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=2wPSfPn8sd1RfAKu/skPh/VJ1dnzVHv0b3RTIQyOWgY=;
	b=kb+W7DCZ2LU0YTIUVmN0GP/mlahku76dWB/aYZD4okoe0RrG1eIbkhedUFIn4ilOIr
	iRyqUED5hyY0bBUfeEVQ9+cxBbeeRzzV+bGzPhBKuMgRXdhjWDm1Av6sVbJ/D8Ih8YsD
	P2BiInPLVmzi7gpNde4HRbUeIpXyaFiJXN2jTS8ElhTGfzH84AopTq2jJoVGVqR66cHI
	pbXsXNh6qeUICXi/hWNzpvxT0Yx3/eNDS8BHVdfRyTx6m6i0Xr5nivV/GRZZpflhoX55
	Fz9MRysZteuJaGFnwQX2j2W1OUT3B9Bn1N7f+Gsg/iZbngVN4Hu4oWU9bSgQwriEsOLn
	+Kgw==
X-Received: by 10.194.5.4 with SMTP id o4mr35546518wjo.40.1361462481082;
	Thu, 21 Feb 2013 08:01:21 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id q13sm4279485wie.0.2013.02.21.08.01.16
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 08:01:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 16:01:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Message-ID: <CD4BF54B.4C6E5%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen: consolidate implementations of LOG() macro
Thread-Index: Ac4QTK038vKTiQZ71UOErPJbad0TXg==
In-Reply-To: <20130221155224.GA24051@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: keir@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: consolidate implementations of LOG()
	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

On 21/02/2013 15:52, "Tim Deegan" <tim@xen.org> wrote:

> At 15:48 +0000 on 21 Feb (1361461738), Ian Campbell wrote:
>> arm64 is going to add another one shortly, so take control now.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: keir@xen.org
>> Cc: jbeulich@suse.com
>> Cc: tim@xen.org
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 

Acked-by: Keir Fraser <keir@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:03:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yc6-0006CU-QN; Thu, 21 Feb 2013 16:03:14 +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 1U8Yc5-0006CC-5i
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:03:13 +0000
Received: from [193.109.254.147:23978] by server-11.bemta-14.messagelabs.com
	id CF/FF-30685-04546215; Thu, 21 Feb 2013 16:03:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361462566!1965860!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28966 invoked from network); 21 Feb 2013 16:02:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:02: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.297.1;
	Thu, 21 Feb 2013 16:02:46 +0000
Message-ID: <1361462564.26546.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 16:02:44 +0000
In-Reply-To: <20130221153650.GY24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<20130221153650.GY24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 15:36 +0000, Tim Deegan wrote:
> At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > >     restoring state.
> > > 
> > > You don't seem to have addressed my other comments on v1:
> > 
> > I've got them in v3, I noted that I hadn't addresses you comment on this
> > patch in the #0/46.
> 
> So you did; I did read the 0/46, but for some reason all that stuck in
> my head was the WFE stuff. 
> 
> AFAICS you just need to re-roll this and #25,

I don't think you mean #25? That is "xen: arm64: add guest type to
domain field." which you've acked.

I had an outstanding comment for #14 "xen: arm64: barriers and wait for
interrupts/events" which I've just addressed (and reposted)

> and get a tools-person to ack #20.

Stefano perhaps? ;-)

> So for v3, can you just send those, and avoid another 46-patch
> mailbomb? :)

When I'm applying my own patches I prefer to do it from the list rather
than short cutting them from my own tree, keep me honest/from making
mistakes. How about I include an index of acked/unacked patches in the
zeroeth mail? You ought to be able to just mark it all as read.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:03:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yc6-0006CU-QN; Thu, 21 Feb 2013 16:03:14 +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 1U8Yc5-0006CC-5i
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:03:13 +0000
Received: from [193.109.254.147:23978] by server-11.bemta-14.messagelabs.com
	id CF/FF-30685-04546215; Thu, 21 Feb 2013 16:03:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361462566!1965860!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28966 invoked from network); 21 Feb 2013 16:02:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:02: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.297.1;
	Thu, 21 Feb 2013 16:02:46 +0000
Message-ID: <1361462564.26546.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 16:02:44 +0000
In-Reply-To: <20130221153650.GY24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<20130221153650.GY24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 15:36 +0000, Tim Deegan wrote:
> At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > >     restoring state.
> > > 
> > > You don't seem to have addressed my other comments on v1:
> > 
> > I've got them in v3, I noted that I hadn't addresses you comment on this
> > patch in the #0/46.
> 
> So you did; I did read the 0/46, but for some reason all that stuck in
> my head was the WFE stuff. 
> 
> AFAICS you just need to re-roll this and #25,

I don't think you mean #25? That is "xen: arm64: add guest type to
domain field." which you've acked.

I had an outstanding comment for #14 "xen: arm64: barriers and wait for
interrupts/events" which I've just addressed (and reposted)

> and get a tools-person to ack #20.

Stefano perhaps? ;-)

> So for v3, can you just send those, and avoid another 46-patch
> mailbomb? :)

When I'm applying my own patches I prefer to do it from the list rather
than short cutting them from my own tree, keep me honest/from making
mistakes. How about I include an index of acked/unacked patches in the
zeroeth mail? You ought to be able to just mark it all as read.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 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 1U8YcV-0006Hv-86; Thu, 21 Feb 2013 16:03: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 1U8YcS-0006HI-Ro
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:03:37 +0000
Received: from [85.158.139.211:6039] by server-16.bemta-5.messagelabs.com id
	30/CE-14948-85546215; Thu, 21 Feb 2013 16:03:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361462589!18673145!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19541 invoked from network); 21 Feb 2013 16:03:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:03:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:03: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.297.1;
	Thu, 21 Feb 2013 16:03:09 +0000
Message-ID: <1361462587.26546.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Feb 2013 16:03:07 +0000
In-Reply-To: <1361460367.26546.63.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
	<20130221145628.GN24051@ocelot.phlegethon.org>
	<1361460367.26546.63.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 05/46] xen: arm64: initial build + config
 changes, start of day 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 Thu, 2013-02-21 at 15:26 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 14:56 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> > > +2:      PRINT("- Started in Hyp mode -\r\n")
> > > +
> > > +hyp:
> > 
> > I though we were going to use "EL3" instead of "Hyp".
> 
> Sorry, looks like I missed a few comments when I went through this one.

s/EL3/EL2/g

This is what I have now:

8<-----------------------------------------

>From e4587a06df0d04ccbfd04ec7cc371900fe7dabf4 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 10 Dec 2012 14:19:00 +0000
Subject: [PATCH] xen: arm64: initial build + config changes, start of day code

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: - s/hyp/el2/
    - remove dead code
    - fix comment formatting
v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
      defining in head.S
    - Nuke hard tabs in head.S and mode_switch.S with expand(1)
---
 Config.mk                        |    2 +-
 config/arm64.mk                  |   12 ++
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/Rules.mk            |    6 +
 xen/arch/arm/arm64/Makefile      |    1 +
 xen/arch/arm/arm64/head.S        |  393 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
 xen/arch/arm/xen.lds.S           |    8 +-
 xen/include/asm-arm/page.h       |    1 +
 xen/include/public/arch-arm.h    |   14 ++
 xen/include/public/hvm/save.h    |    2 +-
 xen/include/public/xen.h         |    2 +-
 xen/include/xen/libelf.h         |    2 +-
 13 files changed, 522 insertions(+), 5 deletions(-)
 create mode 100644 config/arm64.mk
 create mode 100644 xen/arch/arm/arm64/Makefile
 create mode 100644 xen/arch/arm/arm64/head.S
 create mode 100644 xen/arch/arm/arm64/mode_switch.S

diff --git a/Config.mk b/Config.mk
index 64541c8..ea64925 100644
--- a/Config.mk
+++ b/Config.mk
@@ -15,7 +15,7 @@ debug_symbols ?= $(debug)
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
-                         -e s/armv7.*/arm32/)
+                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
 
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
diff --git a/config/arm64.mk b/config/arm64.mk
new file mode 100644
index 0000000..b2457eb
--- /dev/null
+++ b/config/arm64.mk
@@ -0,0 +1,12 @@
+CONFIG_ARM := y
+CONFIG_ARM_64 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+CFLAGS += #-marm -march= -mcpu= etc
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+LDFLAGS_DIRECT += -maarch64elf
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f2822f2..7ff67c7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-$(arm64) += arm64
 
 obj-y += early_printk.o
 obj-y += domain.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 5b5768a..29b605d 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -26,6 +26,12 @@ arm32 := y
 arm64 := n
 endif
 
+ifeq ($(TARGET_SUBARCH),arm64)
+CFLAGS += -mcpu=generic
+arm32 := n
+arm64 := y
+endif
+
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
new file mode 100644
index 0000000..dffbeb1
--- /dev/null
+++ b/xen/arch/arm/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
new file mode 100644
index 0000000..b7ab251
--- /dev/null
+++ b/xen/arch/arm/arm64/head.S
@@ -0,0 +1,393 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv8.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * Based on ARMv7-A head.S by
+ * Tim Deegan <tim@xen.org>
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
+#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
+#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
+#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+        adr   x0, 98f ; \
+        bl    puts    ; \
+        b     99f     ; \
+98:     .asciz _s     ; \
+        .align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+        /*.aarch64*/
+
+        /*
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * The requirements are:
+         *   MMU = off, D-cache = off, I-cache = on or off,
+         *   x0 = physical address to the FDT blob.
+         *
+         * This must be the very first address in the loaded image.
+         * It should be linked at XEN_VIRT_START, and loaded at any
+         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+         * or the initial pagetable code below will need adjustment.
+         */
+
+        .global start
+start:
+        /*
+         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
+         */
+        b       real_start           /* branch to kernel start, magic */
+        .long   0                    /* reserved */
+        .quad   0                    /* Image load offset from start of RAM */
+        .quad   0                    /* reserved */
+        .quad   0                    /* reserved */
+
+real_start:
+        msr   DAIFSet, 0xf           /* Disable all interrupts */
+
+        /* Save the bootloader arguments in less-clobberable registers */
+        mov   x21, x0                /* x21 := DTB, physical address  */
+
+        /* Find out where we are */
+        ldr   x0, =start
+        adr   x19, start             /* x19 := paddr (start) */
+        sub   x20, x19, x0           /* x20 := phys-offset */
+
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   x21, =_sdtb
+        add   x21, x21, x20          /* x21 := paddr(DTB) */
+#endif
+
+        /* Are we the boot CPU? */
+        mov   x22, #0                /* x22 := CPU ID */
+        mrs   x0, mpidr_el1
+        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
+        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
+
+        mov   x13, #(0xff << 24)
+        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
+        b.eq  boot_cpu               /* If we're CPU 0, boot now */
+
+        /* Non-boot CPUs wait here to be woken up one at a time. */
+1:      dsb   sy
+        ldr   x0, =smp_up_cpu        /* VA of gate */
+        add   x0, x0, x20            /* PA of gate */
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x22                /* Is it us? */
+        b.eq  2f
+        wfe
+        b     1b
+2:
+
+boot_cpu:
+#ifdef EARLY_UART_ADDRESS
+        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
+        cbnz  x22, 1f
+        bl    init_uart                 /* CPU 0 sets up the UART too */
+1:      PRINT("- CPU ")
+        mov   x0, x22
+        bl    putn
+        PRINT(" booting -\r\n")
+#endif
+
+        PRINT("- Current EL ")
+        mrs   x0, CurrentEL
+        bl    putn
+        PRINT(" -\r\n")
+
+        /* Are we in EL3 */
+        mrs   x0, CurrentEL
+        cmp   x0, #PSR_MODE_EL3t
+        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
+        b.eq  1f /* Yes */
+
+        /* Are we in EL2 */
+        cmp   x0, #PSR_MODE_EL2t
+        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
+        b.eq  2f /* Yes */
+
+        /* Otherwise, it must have been EL0 or EL1 */
+        PRINT("- CPU is not in EL3 or EL2 -\r\n")
+        b     fail
+
+1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
+        ldr   x1, =enter_el2_mode    /* VA of function */
+        add   x1, x1, x20            /* PA of function */
+        adr   x30, el2               /* Set return address for call */
+        br    x1                     /* Call function */
+
+2:      PRINT("- Started in EL2 mode -\r\n")
+
+el2:
+        /* Zero BSS On the boot CPU to avoid nasty surprises */
+        cbnz  x22, skip_bss
+
+        PRINT("- Zero BSS -\r\n")
+        ldr   x0, =__bss_start       /* Load start & end of bss */
+        ldr   x1, =__bss_end
+        add   x0, x0, x20            /* Apply physical offset */
+        add   x1, x1, x20
+
+1:      str   xzr, [x0], #8
+        cmp   x0, x1
+        b.lo  1b
+
+skip_bss:
+
+        PRINT("- Setting up control registers -\r\n")
+
+        /* Set up memory attribute type tables */
+        ldr   x0, =MAIRVAL
+        msr   mair_el2, x0
+
+        /* Set up the HTCR:
+         * PASize -- 4G
+         * Top byte is used
+         * PT walks use Outer-Shareable accesses,
+         * PT walks are write-back, no-write-allocate in both cache levels,
+         * Full 64-bit address space goes through this table. */
+        ldr   x0, =0x80802500
+        msr   tcr_el2, x0
+
+        /* Set up the HSCTLR:
+         * Exceptions in LE ARM,
+         * Low-latency IRQs disabled,
+         * Write-implies-XN disabled (for now),
+         * D-cache disabled (for now),
+         * I-cache enabled,
+         * Alignment checking enabled,
+         * MMU translation disabled (for now). */
+        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
+        msr   SCTLR_EL2, x0
+
+        /* Write Xen's PT's paddr into the HTTBR */
+        ldr   x4, =xen_pgtable
+        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
+        msr   TTBR0_EL2, x4
+
+        /* Non-boot CPUs don't need to rebuild the pagetable */
+        cbnz  x22, pt_ready
+
+        ldr   x1, =xen_first
+        add   x1, x1, x20            /* x1 := paddr (xen_first) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_first */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+
+        mov   x4, x1                 /* Next level into xen_first */
+
+       /* console fixmap */
+#ifdef EARLY_UART_ADDRESS
+        ldr   x1, =xen_fixmap
+        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
+        lsr   x2, x23, #12
+        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
+        mov   x3, #PT_DEV_L3
+        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
+        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
+#endif
+
+        /* Build the baseline idle pagetable's first-level entries */
+        ldr   x1, =xen_second
+        add   x1, x1, x20            /* x1 := paddr (xen_second) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_second */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
+
+        /* Now set up the second-level entries */
+        mov   x3, #PT_MEM
+        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
+        orr   x4, xzr, x19, lsr #18
+        str   x2, [x1, x4]           /* Map Xen there */
+        ldr   x4, =start
+        lsr   x4, x4, #18            /* Slot for vaddr(start) */
+        str   x2, [x1, x4]           /* Map Xen there too */
+
+        /* xen_fixmap pagetable */
+        ldr   x2, =xen_fixmap
+        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
+        mov   x3, #PT_PT
+        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
+
+        lsr   x2, x21, #21
+        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
+        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
+        orr   x2, x2, x3
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the early boot slot */
+
+pt_ready:
+        PRINT("- Turning on paging -\r\n")
+
+        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
+        mrs   x0, SCTLR_EL2
+        orr   x0, x0, #SCTLR_M       /* Enable MMU */
+        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
+        dsb   sy                     /* Flush PTE writes and finish reads */
+        msr   SCTLR_EL2, x0          /* now paging is enabled */
+        isb                          /* Now, flush the icache */
+        br    x1                     /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+        /* Use a virtual address to access the UART. */
+        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+#endif
+
+        PRINT("- Ready -\r\n")
+
+        /* The boot CPU should go straight into C now */
+        cbz   x22, launch
+
+        /* Non-boot CPUs need to move on to the relocated pagetables */
+        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
+        add   x4, x4, x20            /* PA of it */
+        ldr   x4, [x4]               /* Actual value */
+        dsb   sy
+        msr   TTBR0_EL2, x4
+        dsb   sy
+        isb
+        tlbi  alle2
+        dsb   sy                     /* Ensure completion of TLB flush */
+        isb
+
+        /* Non-boot CPUs report that they've got this far */
+        ldr   x0, =ready_cpus
+1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
+        add   x1, x1, #1             /* Atomically { ++                   } */
+        stlxr w2, x1, [x0]           /*            { writeback            } */
+        cbnz  w2, 1b
+        dsb   sy
+        dc    cvac, x0               /* Flush D-Cache */
+        dsb   sy
+
+        /* Here, the non-boot CPUs must wait again -- they're now running on
+         * the boot CPU's pagetables so it's safe for the boot CPU to
+         * overwrite the non-relocated copy of Xen.  Once it's done that,
+         * and brought up the memory allocator, non-boot CPUs can get their
+         * own stacks and enter C. */
+1:      wfe
+        dsb   sy
+        ldr   x0, =smp_up_cpu
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x12                /* Is it us? */
+        b.ne  1b
+
+launch:
+        ldr   x0, =init_stack        /* Find the boot-time stack */
+        ldr   x0, [x0]
+        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
+        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
+        mov   sp, x0
+
+        mov   x0, x20                /* Marshal args: - phys_offset */
+        mov   x1, x21                /*               - FDT */
+        mov   x2, x22                /*               - CPU ID */
+        cbz   x22, start_xen         /* and disappear into the land of C */
+        b     start_secondary        /* (to the appropriate entry point) */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:   PRINT("- Boot failed -\r\n")
+1:      wfe
+        b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+        mov   x1, #0x0
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+        mov   x1, #0x60              /* 8n1 */
+        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
+        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
+        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
+        adr   x0, 1f
+        b     puts
+1:      .asciz "- UART enabled -\r\n"
+        .align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  puts                   /* Wait for the UART to be ready */
+        ldrb  w2, [x0], #1           /* Load next char */
+        cbz   w2, 1f                 /* Exit on nul */
+        str   w2, [x23]              /* -> UARTDR (Data Register) */
+        b     puts
+1:
+        ret
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+        adr   x1, hex
+        mov   x3, #8
+1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  1b                     /* Wait for the UART to be ready */
+        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
+        lsr   x2, x2, #28
+        ldrb  w2, [x1, x2]           /* Convert to a char */
+        strb  w2, [x23]              /* -> UARTDR (Data Register) */
+        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
+        subs  x3, x3, #1
+        b.ne  1b
+        ret
+
+hex:    .ascii "0123456789abcdef"
+        .align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:   mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
new file mode 100644
index 0000000..4c38181
--- /dev/null
+++ b/xen/arch/arm/arm64/mode_switch.S
@@ -0,0 +1,83 @@
+/*
+ * xen/arch/arm/arm64/mode_switch.S
+ *
+ * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
+ *       bootwrapper.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+/* Get up a CPU into EL2.  Clobbers x0-x3.
+ *
+ * Expects x22 == CPU number
+ * Expects x30  == EL2 entry point
+ *
+ * This code is specific to the VE model, and not intended to be used
+ * on production systems.  As such it's a bit hackier than the main
+ * boot code in head.S.  In future it will be replaced by better
+ * integration with the bootloader/firmware so that Xen always starts
+ * at EL2.
+ */
+
+.globl enter_el2_mode
+enter_el2_mode:
+        mov     x0, #0x30                       // RES1
+        orr     x0, x0, #(1 << 0)               // Non-secure EL1
+        orr     x0, x0, #(1 << 8)               // HVC enable
+        orr     x0, x0, #(1 << 10)              // 64-bit EL2
+        msr     scr_el3, x0
+
+        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
+
+        ldr     x0, =0x01800000                 // 24Mhz
+        msr     cntfrq_el0, x0
+
+        /*
+         * Check for the primary CPU to avoid a race on the distributor
+         * registers.
+         */
+        cbnz    x22, 1f
+
+        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
+        mov     w0, #~0                         // Grp1 interrupts
+        str     w0, [x1], #4
+        b.ne    2f                              // Only local interrupts for secondary CPUs
+        str     w0, [x1], #4
+        str     w0, [x1], #4
+
+2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
+        ldr     w0, [x1]
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
+        str     w0, [x1, #4]                    // GICC_PMR
+
+        msr     sctlr_el2, xzr
+
+        /*
+         * Prepare the switch to the EL2_SP1 mode from EL3
+         */
+        msr     elr_el3, x30                    // Return to desired function
+        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+        msr     spsr_el3, x1
+        eret
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..b1f0a78 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -11,7 +11,13 @@
 
 ENTRY(start)
 
-OUTPUT_ARCH(arm)
+#if defined(__arm__)
+#define FORMAT arm
+#elif defined(__aarch64__)
+#define FORMAT aarch64
+#endif
+
+OUTPUT_ARCH(FORMAT)
 
 PHDRS
 {
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 9acd0af..e0a636f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -38,6 +38,7 @@
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
+#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
 
 /*
  * Attribute Indexes.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 8dd9062..dc12524 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -174,6 +174,8 @@ typedef uint64_t xen_callback_t;
 
 /* 0-4: Mode */
 #define PSR_MODE_MASK 0x1f
+
+/* 32 bit modes */
 #define PSR_MODE_USR 0x10
 #define PSR_MODE_FIQ 0x11
 #define PSR_MODE_IRQ 0x12
@@ -184,6 +186,18 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
+/* 64 bit modes */
+#ifdef CONFIG_ARM_64
+#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
+#define PSR_MODE_EL3h 0x0d
+#define PSR_MODE_EL3t 0x0c
+#define PSR_MODE_EL2h 0x09
+#define PSR_MODE_EL2t 0x08
+#define PSR_MODE_EL1h 0x05
+#define PSR_MODE_EL1t 0x04
+#define PSR_MODE_EL0t 0x00
+#endif
+
 #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
 #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
 #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index 5538d8e..cc8b5fd 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "../arch-x86/hvm/save.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined(__aarch64__)
 #include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 846f446..a1927c0 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -31,7 +31,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "arch-x86/xen.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined (__aarch64__)
 #include "arch-arm.h"
 #else
 #error "Unsupported architecture"
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index e8f6508..218bb18 100644
--- 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(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.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 Feb 21 16:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 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 1U8YcV-0006Hv-86; Thu, 21 Feb 2013 16:03: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 1U8YcS-0006HI-Ro
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:03:37 +0000
Received: from [85.158.139.211:6039] by server-16.bemta-5.messagelabs.com id
	30/CE-14948-85546215; Thu, 21 Feb 2013 16:03:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361462589!18673145!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19541 invoked from network); 21 Feb 2013 16:03:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:03:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:03: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.297.1;
	Thu, 21 Feb 2013 16:03:09 +0000
Message-ID: <1361462587.26546.77.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Thu, 21 Feb 2013 16:03:07 +0000
In-Reply-To: <1361460367.26546.63.camel@zakaz.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
	<20130221145628.GN24051@ocelot.phlegethon.org>
	<1361460367.26546.63.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
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] [PATCH V2 05/46] xen: arm64: initial build + config
 changes, start of day 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 Thu, 2013-02-21 at 15:26 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 14:56 +0000, Tim Deegan wrote:
> > At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> > > +2:      PRINT("- Started in Hyp mode -\r\n")
> > > +
> > > +hyp:
> > 
> > I though we were going to use "EL3" instead of "Hyp".
> 
> Sorry, looks like I missed a few comments when I went through this one.

s/EL3/EL2/g

This is what I have now:

8<-----------------------------------------

>From e4587a06df0d04ccbfd04ec7cc371900fe7dabf4 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 10 Dec 2012 14:19:00 +0000
Subject: [PATCH] xen: arm64: initial build + config changes, start of day code

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: - s/hyp/el2/
    - remove dead code
    - fix comment formatting
v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
      defining in head.S
    - Nuke hard tabs in head.S and mode_switch.S with expand(1)
---
 Config.mk                        |    2 +-
 config/arm64.mk                  |   12 ++
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/Rules.mk            |    6 +
 xen/arch/arm/arm64/Makefile      |    1 +
 xen/arch/arm/arm64/head.S        |  393 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
 xen/arch/arm/xen.lds.S           |    8 +-
 xen/include/asm-arm/page.h       |    1 +
 xen/include/public/arch-arm.h    |   14 ++
 xen/include/public/hvm/save.h    |    2 +-
 xen/include/public/xen.h         |    2 +-
 xen/include/xen/libelf.h         |    2 +-
 13 files changed, 522 insertions(+), 5 deletions(-)
 create mode 100644 config/arm64.mk
 create mode 100644 xen/arch/arm/arm64/Makefile
 create mode 100644 xen/arch/arm/arm64/head.S
 create mode 100644 xen/arch/arm/arm64/mode_switch.S

diff --git a/Config.mk b/Config.mk
index 64541c8..ea64925 100644
--- a/Config.mk
+++ b/Config.mk
@@ -15,7 +15,7 @@ debug_symbols ?= $(debug)
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
-                         -e s/armv7.*/arm32/)
+                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
 
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
diff --git a/config/arm64.mk b/config/arm64.mk
new file mode 100644
index 0000000..b2457eb
--- /dev/null
+++ b/config/arm64.mk
@@ -0,0 +1,12 @@
+CONFIG_ARM := y
+CONFIG_ARM_64 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+CFLAGS += #-marm -march= -mcpu= etc
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+LDFLAGS_DIRECT += -maarch64elf
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index f2822f2..7ff67c7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-$(arm64) += arm64
 
 obj-y += early_printk.o
 obj-y += domain.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 5b5768a..29b605d 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -26,6 +26,12 @@ arm32 := y
 arm64 := n
 endif
 
+ifeq ($(TARGET_SUBARCH),arm64)
+CFLAGS += -mcpu=generic
+arm32 := n
+arm64 := y
+endif
+
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
new file mode 100644
index 0000000..dffbeb1
--- /dev/null
+++ b/xen/arch/arm/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
new file mode 100644
index 0000000..b7ab251
--- /dev/null
+++ b/xen/arch/arm/arm64/head.S
@@ -0,0 +1,393 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv8.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * Based on ARMv7-A head.S by
+ * Tim Deegan <tim@xen.org>
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
+#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
+#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
+#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+        adr   x0, 98f ; \
+        bl    puts    ; \
+        b     99f     ; \
+98:     .asciz _s     ; \
+        .align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+        /*.aarch64*/
+
+        /*
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * The requirements are:
+         *   MMU = off, D-cache = off, I-cache = on or off,
+         *   x0 = physical address to the FDT blob.
+         *
+         * This must be the very first address in the loaded image.
+         * It should be linked at XEN_VIRT_START, and loaded at any
+         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+         * or the initial pagetable code below will need adjustment.
+         */
+
+        .global start
+start:
+        /*
+         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
+         */
+        b       real_start           /* branch to kernel start, magic */
+        .long   0                    /* reserved */
+        .quad   0                    /* Image load offset from start of RAM */
+        .quad   0                    /* reserved */
+        .quad   0                    /* reserved */
+
+real_start:
+        msr   DAIFSet, 0xf           /* Disable all interrupts */
+
+        /* Save the bootloader arguments in less-clobberable registers */
+        mov   x21, x0                /* x21 := DTB, physical address  */
+
+        /* Find out where we are */
+        ldr   x0, =start
+        adr   x19, start             /* x19 := paddr (start) */
+        sub   x20, x19, x0           /* x20 := phys-offset */
+
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   x21, =_sdtb
+        add   x21, x21, x20          /* x21 := paddr(DTB) */
+#endif
+
+        /* Are we the boot CPU? */
+        mov   x22, #0                /* x22 := CPU ID */
+        mrs   x0, mpidr_el1
+        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
+        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
+
+        mov   x13, #(0xff << 24)
+        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
+        b.eq  boot_cpu               /* If we're CPU 0, boot now */
+
+        /* Non-boot CPUs wait here to be woken up one at a time. */
+1:      dsb   sy
+        ldr   x0, =smp_up_cpu        /* VA of gate */
+        add   x0, x0, x20            /* PA of gate */
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x22                /* Is it us? */
+        b.eq  2f
+        wfe
+        b     1b
+2:
+
+boot_cpu:
+#ifdef EARLY_UART_ADDRESS
+        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
+        cbnz  x22, 1f
+        bl    init_uart                 /* CPU 0 sets up the UART too */
+1:      PRINT("- CPU ")
+        mov   x0, x22
+        bl    putn
+        PRINT(" booting -\r\n")
+#endif
+
+        PRINT("- Current EL ")
+        mrs   x0, CurrentEL
+        bl    putn
+        PRINT(" -\r\n")
+
+        /* Are we in EL3 */
+        mrs   x0, CurrentEL
+        cmp   x0, #PSR_MODE_EL3t
+        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
+        b.eq  1f /* Yes */
+
+        /* Are we in EL2 */
+        cmp   x0, #PSR_MODE_EL2t
+        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
+        b.eq  2f /* Yes */
+
+        /* Otherwise, it must have been EL0 or EL1 */
+        PRINT("- CPU is not in EL3 or EL2 -\r\n")
+        b     fail
+
+1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
+        ldr   x1, =enter_el2_mode    /* VA of function */
+        add   x1, x1, x20            /* PA of function */
+        adr   x30, el2               /* Set return address for call */
+        br    x1                     /* Call function */
+
+2:      PRINT("- Started in EL2 mode -\r\n")
+
+el2:
+        /* Zero BSS On the boot CPU to avoid nasty surprises */
+        cbnz  x22, skip_bss
+
+        PRINT("- Zero BSS -\r\n")
+        ldr   x0, =__bss_start       /* Load start & end of bss */
+        ldr   x1, =__bss_end
+        add   x0, x0, x20            /* Apply physical offset */
+        add   x1, x1, x20
+
+1:      str   xzr, [x0], #8
+        cmp   x0, x1
+        b.lo  1b
+
+skip_bss:
+
+        PRINT("- Setting up control registers -\r\n")
+
+        /* Set up memory attribute type tables */
+        ldr   x0, =MAIRVAL
+        msr   mair_el2, x0
+
+        /* Set up the HTCR:
+         * PASize -- 4G
+         * Top byte is used
+         * PT walks use Outer-Shareable accesses,
+         * PT walks are write-back, no-write-allocate in both cache levels,
+         * Full 64-bit address space goes through this table. */
+        ldr   x0, =0x80802500
+        msr   tcr_el2, x0
+
+        /* Set up the HSCTLR:
+         * Exceptions in LE ARM,
+         * Low-latency IRQs disabled,
+         * Write-implies-XN disabled (for now),
+         * D-cache disabled (for now),
+         * I-cache enabled,
+         * Alignment checking enabled,
+         * MMU translation disabled (for now). */
+        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
+        msr   SCTLR_EL2, x0
+
+        /* Write Xen's PT's paddr into the HTTBR */
+        ldr   x4, =xen_pgtable
+        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
+        msr   TTBR0_EL2, x4
+
+        /* Non-boot CPUs don't need to rebuild the pagetable */
+        cbnz  x22, pt_ready
+
+        ldr   x1, =xen_first
+        add   x1, x1, x20            /* x1 := paddr (xen_first) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_first */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+
+        mov   x4, x1                 /* Next level into xen_first */
+
+       /* console fixmap */
+#ifdef EARLY_UART_ADDRESS
+        ldr   x1, =xen_fixmap
+        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
+        lsr   x2, x23, #12
+        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
+        mov   x3, #PT_DEV_L3
+        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
+        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
+#endif
+
+        /* Build the baseline idle pagetable's first-level entries */
+        ldr   x1, =xen_second
+        add   x1, x1, x20            /* x1 := paddr (xen_second) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_second */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
+
+        /* Now set up the second-level entries */
+        mov   x3, #PT_MEM
+        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
+        orr   x4, xzr, x19, lsr #18
+        str   x2, [x1, x4]           /* Map Xen there */
+        ldr   x4, =start
+        lsr   x4, x4, #18            /* Slot for vaddr(start) */
+        str   x2, [x1, x4]           /* Map Xen there too */
+
+        /* xen_fixmap pagetable */
+        ldr   x2, =xen_fixmap
+        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
+        mov   x3, #PT_PT
+        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
+
+        lsr   x2, x21, #21
+        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
+        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
+        orr   x2, x2, x3
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the early boot slot */
+
+pt_ready:
+        PRINT("- Turning on paging -\r\n")
+
+        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
+        mrs   x0, SCTLR_EL2
+        orr   x0, x0, #SCTLR_M       /* Enable MMU */
+        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
+        dsb   sy                     /* Flush PTE writes and finish reads */
+        msr   SCTLR_EL2, x0          /* now paging is enabled */
+        isb                          /* Now, flush the icache */
+        br    x1                     /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+        /* Use a virtual address to access the UART. */
+        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+#endif
+
+        PRINT("- Ready -\r\n")
+
+        /* The boot CPU should go straight into C now */
+        cbz   x22, launch
+
+        /* Non-boot CPUs need to move on to the relocated pagetables */
+        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
+        add   x4, x4, x20            /* PA of it */
+        ldr   x4, [x4]               /* Actual value */
+        dsb   sy
+        msr   TTBR0_EL2, x4
+        dsb   sy
+        isb
+        tlbi  alle2
+        dsb   sy                     /* Ensure completion of TLB flush */
+        isb
+
+        /* Non-boot CPUs report that they've got this far */
+        ldr   x0, =ready_cpus
+1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
+        add   x1, x1, #1             /* Atomically { ++                   } */
+        stlxr w2, x1, [x0]           /*            { writeback            } */
+        cbnz  w2, 1b
+        dsb   sy
+        dc    cvac, x0               /* Flush D-Cache */
+        dsb   sy
+
+        /* Here, the non-boot CPUs must wait again -- they're now running on
+         * the boot CPU's pagetables so it's safe for the boot CPU to
+         * overwrite the non-relocated copy of Xen.  Once it's done that,
+         * and brought up the memory allocator, non-boot CPUs can get their
+         * own stacks and enter C. */
+1:      wfe
+        dsb   sy
+        ldr   x0, =smp_up_cpu
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x12                /* Is it us? */
+        b.ne  1b
+
+launch:
+        ldr   x0, =init_stack        /* Find the boot-time stack */
+        ldr   x0, [x0]
+        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
+        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
+        mov   sp, x0
+
+        mov   x0, x20                /* Marshal args: - phys_offset */
+        mov   x1, x21                /*               - FDT */
+        mov   x2, x22                /*               - CPU ID */
+        cbz   x22, start_xen         /* and disappear into the land of C */
+        b     start_secondary        /* (to the appropriate entry point) */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:   PRINT("- Boot failed -\r\n")
+1:      wfe
+        b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+        mov   x1, #0x0
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+        mov   x1, #0x60              /* 8n1 */
+        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
+        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
+        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
+        adr   x0, 1f
+        b     puts
+1:      .asciz "- UART enabled -\r\n"
+        .align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  puts                   /* Wait for the UART to be ready */
+        ldrb  w2, [x0], #1           /* Load next char */
+        cbz   w2, 1f                 /* Exit on nul */
+        str   w2, [x23]              /* -> UARTDR (Data Register) */
+        b     puts
+1:
+        ret
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+        adr   x1, hex
+        mov   x3, #8
+1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  1b                     /* Wait for the UART to be ready */
+        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
+        lsr   x2, x2, #28
+        ldrb  w2, [x1, x2]           /* Convert to a char */
+        strb  w2, [x23]              /* -> UARTDR (Data Register) */
+        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
+        subs  x3, x3, #1
+        b.ne  1b
+        ret
+
+hex:    .ascii "0123456789abcdef"
+        .align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:   mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
new file mode 100644
index 0000000..4c38181
--- /dev/null
+++ b/xen/arch/arm/arm64/mode_switch.S
@@ -0,0 +1,83 @@
+/*
+ * xen/arch/arm/arm64/mode_switch.S
+ *
+ * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
+ *       bootwrapper.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+/* Get up a CPU into EL2.  Clobbers x0-x3.
+ *
+ * Expects x22 == CPU number
+ * Expects x30  == EL2 entry point
+ *
+ * This code is specific to the VE model, and not intended to be used
+ * on production systems.  As such it's a bit hackier than the main
+ * boot code in head.S.  In future it will be replaced by better
+ * integration with the bootloader/firmware so that Xen always starts
+ * at EL2.
+ */
+
+.globl enter_el2_mode
+enter_el2_mode:
+        mov     x0, #0x30                       // RES1
+        orr     x0, x0, #(1 << 0)               // Non-secure EL1
+        orr     x0, x0, #(1 << 8)               // HVC enable
+        orr     x0, x0, #(1 << 10)              // 64-bit EL2
+        msr     scr_el3, x0
+
+        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
+
+        ldr     x0, =0x01800000                 // 24Mhz
+        msr     cntfrq_el0, x0
+
+        /*
+         * Check for the primary CPU to avoid a race on the distributor
+         * registers.
+         */
+        cbnz    x22, 1f
+
+        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
+        mov     w0, #~0                         // Grp1 interrupts
+        str     w0, [x1], #4
+        b.ne    2f                              // Only local interrupts for secondary CPUs
+        str     w0, [x1], #4
+        str     w0, [x1], #4
+
+2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
+        ldr     w0, [x1]
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
+        str     w0, [x1, #4]                    // GICC_PMR
+
+        msr     sctlr_el2, xzr
+
+        /*
+         * Prepare the switch to the EL2_SP1 mode from EL3
+         */
+        msr     elr_el3, x30                    // Return to desired function
+        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+        msr     spsr_el3, x1
+        eret
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..b1f0a78 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -11,7 +11,13 @@
 
 ENTRY(start)
 
-OUTPUT_ARCH(arm)
+#if defined(__arm__)
+#define FORMAT arm
+#elif defined(__aarch64__)
+#define FORMAT aarch64
+#endif
+
+OUTPUT_ARCH(FORMAT)
 
 PHDRS
 {
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 9acd0af..e0a636f 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -38,6 +38,7 @@
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
+#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
 
 /*
  * Attribute Indexes.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 8dd9062..dc12524 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -174,6 +174,8 @@ typedef uint64_t xen_callback_t;
 
 /* 0-4: Mode */
 #define PSR_MODE_MASK 0x1f
+
+/* 32 bit modes */
 #define PSR_MODE_USR 0x10
 #define PSR_MODE_FIQ 0x11
 #define PSR_MODE_IRQ 0x12
@@ -184,6 +186,18 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
+/* 64 bit modes */
+#ifdef CONFIG_ARM_64
+#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
+#define PSR_MODE_EL3h 0x0d
+#define PSR_MODE_EL3t 0x0c
+#define PSR_MODE_EL2h 0x09
+#define PSR_MODE_EL2t 0x08
+#define PSR_MODE_EL1h 0x05
+#define PSR_MODE_EL1t 0x04
+#define PSR_MODE_EL0t 0x00
+#endif
+
 #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
 #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
 #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index 5538d8e..cc8b5fd 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "../arch-x86/hvm/save.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined(__aarch64__)
 #include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 846f446..a1927c0 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -31,7 +31,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "arch-x86/xen.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined (__aarch64__)
 #include "arch-arm.h"
 #else
 #error "Unsupported architecture"
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index e8f6508..218bb18 100644
--- 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(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.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 Feb 21 16:08:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Ygd-0006mV-7F; Thu, 21 Feb 2013 16:07:55 +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 1U8Ygc-0006mJ-Fy
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:07:54 +0000
Received: from [85.158.137.99:16355] by server-11.bemta-3.messagelabs.com id
	41/D6-10249-95646215; Thu, 21 Feb 2013 16:07:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361462866!14285366!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24782 invoked from network); 21 Feb 2013 16:07:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 16:07:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YgT-0007cN-PB; Thu, 21 Feb 2013 16:07:45 +0000
Date: Thu, 21 Feb 2013 16:07:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221160745.GC24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<20130221153650.GY24051@ocelot.phlegethon.org>
	<1361462564.26546.76.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361462564.26546.76.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 16:02 +0000 on 21 Feb (1361462564), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:36 +0000, Tim Deegan wrote:
> > At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> > > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > > ---
> > > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > > >     restoring state.
> > > > 
> > > > You don't seem to have addressed my other comments on v1:
> > > 
> > > I've got them in v3, I noted that I hadn't addresses you comment on this
> > > patch in the #0/46.
> > 
> > So you did; I did read the 0/46, but for some reason all that stuck in
> > my head was the WFE stuff. 
> > 
> > AFAICS you just need to re-roll this and #25,
> 
> I don't think you mean #25? That is "xen: arm64: add guest type to
> domain field." which you've acked.

Sorry, I meant #5.

> When I'm applying my own patches I prefer to do it from the list rather
> than short cutting them from my own tree, keep me honest/from making
> mistakes. How about I include an index of acked/unacked patches in the
> zeroeth mail? You ought to be able to just mark it all as read.

Fair enough -- no need to index them; I just keep all previous versions
of a series around so I can easily find the comments.  But this won't
need a v4, will 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 Feb 21 16:08:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Ygd-0006mV-7F; Thu, 21 Feb 2013 16:07:55 +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 1U8Ygc-0006mJ-Fy
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:07:54 +0000
Received: from [85.158.137.99:16355] by server-11.bemta-3.messagelabs.com id
	41/D6-10249-95646215; Thu, 21 Feb 2013 16:07:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361462866!14285366!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24782 invoked from network); 21 Feb 2013 16:07:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 16:07:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YgT-0007cN-PB; Thu, 21 Feb 2013 16:07:45 +0000
Date: Thu, 21 Feb 2013 16:07:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221160745.GC24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<20130221153650.GY24051@ocelot.phlegethon.org>
	<1361462564.26546.76.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361462564.26546.76.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 27/46] xen: arm: arm64 trap 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

At 16:02 +0000 on 21 Feb (1361462564), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:36 +0000, Tim Deegan wrote:
> > At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> > > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > > ---
> > > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > > >     restoring state.
> > > > 
> > > > You don't seem to have addressed my other comments on v1:
> > > 
> > > I've got them in v3, I noted that I hadn't addresses you comment on this
> > > patch in the #0/46.
> > 
> > So you did; I did read the 0/46, but for some reason all that stuck in
> > my head was the WFE stuff. 
> > 
> > AFAICS you just need to re-roll this and #25,
> 
> I don't think you mean #25? That is "xen: arm64: add guest type to
> domain field." which you've acked.

Sorry, I meant #5.

> When I'm applying my own patches I prefer to do it from the list rather
> than short cutting them from my own tree, keep me honest/from making
> mistakes. How about I include an index of acked/unacked patches in the
> zeroeth mail? You ought to be able to just mark it all as read.

Fair enough -- no need to index them; I just keep all previous versions
of a series around so I can easily find the comments.  But this won't
need a v4, will 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 Feb 21 16:08:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8YhK-0006qP-Le; Thu, 21 Feb 2013 16:08: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 1U8YhJ-0006qD-5T
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:08:37 +0000
Received: from [85.158.137.99:23583] by server-15.bemta-3.messagelabs.com id
	92/AA-25405-F7646215; Thu, 21 Feb 2013 16:08:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361462887!16575191!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5652 invoked from network); 21 Feb 2013 16:08:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:08:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:08: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.297.1;
	Thu, 21 Feb 2013 16:08:07 +0000
Message-ID: <1361462886.26546.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 21 Feb 2013 16:08:06 +0000
In-Reply-To: <5126509802000078000C0074@nat28.tlf.novell.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
	<1361459927.26546.59.camel@zakaz.uk.xensource.com>
	<5126509802000078000C0074@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 15:51 +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 16:18, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> >> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >> > If any committer needs help getting git to work please feel free to
> >> > ask.  git has many advantages but its user interface has received very
> >> > mixed reviews.  We appreciate that you might need handholding.  So if
> >> > you get confused, or into trouble, do consult.
> >> 
> >> So one thing I found very handy with hg was that there was a
> >> single line history with easy to look at changeset numbers. Is there
> >> any way to achieve the same with git? I'm asking particularly in the
> >> context of backporting: In order to pick changes from unstable (now
> >> master), so far I simply scanned the history, tracking (on a sheet of
> >> paper) at which c/s I last left off.
> > 
> > Something like git log --oneline?
> > 
> > You can also git log --pretty=format:%...
> 
> The question is whether these, just like the web interface, sort
> by commit time rather than commit order.

git rev-list mentions --topo-order and --date-order, and git log just
forwards these on. I think --date-order is what you want?

Not sure about the webterface.

> And ideally it would be doable both locally and from the web
> interface, yet I don't see the web interface having any way to
> control how it sorts its output.
> 
> > Where there are various available %foo described in the manpage.
> > 
> > git doesn't really have a concept of the shorter sequential numbers
> > which mercurial has. The closest I can think of is the sort of thing
> > which git describe outputs.
> 
> Again, it depends how the number produced here gets calculated,
> i.e. whether it remains stable over the lifetime of a tree regardless
> of what commits get pulled (and merges get done).

That isn't true of the Mercurial ones either. At least not in general,
perhaps our not-very-branching structure makes it mostly true in
practice.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:08:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8YhK-0006qP-Le; Thu, 21 Feb 2013 16:08: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 1U8YhJ-0006qD-5T
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:08:37 +0000
Received: from [85.158.137.99:23583] by server-15.bemta-3.messagelabs.com id
	92/AA-25405-F7646215; Thu, 21 Feb 2013 16:08:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361462887!16575191!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5652 invoked from network); 21 Feb 2013 16:08:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:08:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:08: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.297.1;
	Thu, 21 Feb 2013 16:08:07 +0000
Message-ID: <1361462886.26546.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 21 Feb 2013 16:08:06 +0000
In-Reply-To: <5126509802000078000C0074@nat28.tlf.novell.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
	<1361459927.26546.59.camel@zakaz.uk.xensource.com>
	<5126509802000078000C0074@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 15:51 +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 16:18, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:
> >> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >> > If any committer needs help getting git to work please feel free to
> >> > ask.  git has many advantages but its user interface has received very
> >> > mixed reviews.  We appreciate that you might need handholding.  So if
> >> > you get confused, or into trouble, do consult.
> >> 
> >> So one thing I found very handy with hg was that there was a
> >> single line history with easy to look at changeset numbers. Is there
> >> any way to achieve the same with git? I'm asking particularly in the
> >> context of backporting: In order to pick changes from unstable (now
> >> master), so far I simply scanned the history, tracking (on a sheet of
> >> paper) at which c/s I last left off.
> > 
> > Something like git log --oneline?
> > 
> > You can also git log --pretty=format:%...
> 
> The question is whether these, just like the web interface, sort
> by commit time rather than commit order.

git rev-list mentions --topo-order and --date-order, and git log just
forwards these on. I think --date-order is what you want?

Not sure about the webterface.

> And ideally it would be doable both locally and from the web
> interface, yet I don't see the web interface having any way to
> control how it sorts its output.
> 
> > Where there are various available %foo described in the manpage.
> > 
> > git doesn't really have a concept of the shorter sequential numbers
> > which mercurial has. The closest I can think of is the sort of thing
> > which git describe outputs.
> 
> Again, it depends how the number produced here gets calculated,
> i.e. whether it remains stable over the lifetime of a tree regardless
> of what commits get pulled (and merges get done).

That isn't true of the Mercurial ones either. At least not in general,
perhaps our not-very-branching structure makes it mostly true in
practice.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:09:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:09: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 1U8Yhu-0006uZ-32; Thu, 21 Feb 2013 16:09:14 +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 1U8Yhs-0006uB-Cz
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:09:12 +0000
Received: from [85.158.139.211:63718] by server-2.bemta-5.messagelabs.com id
	70/5B-16911-7A646215; Thu, 21 Feb 2013 16:09:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361462951!18636564!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5198 invoked from network); 21 Feb 2013 16:09:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:09:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:08: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.297.1;
	Thu, 21 Feb 2013 16:08:53 +0000
Message-ID: <1361462932.26546.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 16:08:52 +0000
In-Reply-To: <20130221160745.GC24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<20130221153650.GY24051@ocelot.phlegethon.org>
	<1361462564.26546.76.camel@zakaz.uk.xensource.com>
	<20130221160745.GC24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 16:07 +0000, Tim Deegan wrote:
> At 16:02 +0000 on 21 Feb (1361462564), Ian Campbell wrote:
> > On Thu, 2013-02-21 at 15:36 +0000, Tim Deegan wrote:
> > > At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> > > > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > > > ---
> > > > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > > > >     restoring state.
> > > > > 
> > > > > You don't seem to have addressed my other comments on v1:
> > > > 
> > > > I've got them in v3, I noted that I hadn't addresses you comment on this
> > > > patch in the #0/46.
> > > 
> > > So you did; I did read the 0/46, but for some reason all that stuck in
> > > my head was the WFE stuff. 
> > > 
> > > AFAICS you just need to re-roll this and #25,
> > 
> > I don't think you mean #25? That is "xen: arm64: add guest type to
> > domain field." which you've acked.
> 
> Sorry, I meant #5.

Ah yes, I've just resent that one.

> > When I'm applying my own patches I prefer to do it from the list rather
> > than short cutting them from my own tree, keep me honest/from making
> > mistakes. How about I include an index of acked/unacked patches in the
> > zeroeth mail? You ought to be able to just mark it all as read.
> 
> Fair enough -- no need to index them; I just keep all previous versions
> of a series around so I can easily find the comments.  But this won't
> need a v4, will it? :)

I hope not!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:09:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:09: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 1U8Yhu-0006uZ-32; Thu, 21 Feb 2013 16:09:14 +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 1U8Yhs-0006uB-Cz
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:09:12 +0000
Received: from [85.158.139.211:63718] by server-2.bemta-5.messagelabs.com id
	70/5B-16911-7A646215; Thu, 21 Feb 2013 16:09:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361462951!18636564!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5198 invoked from network); 21 Feb 2013 16:09:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:09:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1741744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:08: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.297.1;
	Thu, 21 Feb 2013 16:08:53 +0000
Message-ID: <1361462932.26546.81.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 21 Feb 2013 16:08:52 +0000
In-Reply-To: <20130221160745.GC24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-27-git-send-email-ian.campbell@citrix.com>
	<20130221151023.GT24051@ocelot.phlegethon.org>
	<1361460324.26546.62.camel@zakaz.uk.xensource.com>
	<20130221153650.GY24051@ocelot.phlegethon.org>
	<1361462564.26546.76.camel@zakaz.uk.xensource.com>
	<20130221160745.GC24051@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 V2 27/46] xen: arm: arm64 trap 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 Thu, 2013-02-21 at 16:07 +0000, Tim Deegan wrote:
> At 16:02 +0000 on 21 Feb (1361462564), Ian Campbell wrote:
> > On Thu, 2013-02-21 at 15:36 +0000, Tim Deegan wrote:
> > > At 15:25 +0000 on 21 Feb (1361460324), Ian Campbell wrote:
> > > > On Thu, 2013-02-21 at 15:10 +0000, Tim Deegan wrote:
> > > > > At 16:47 +0000 on 14 Feb (1360860461), Ian Campbell wrote:
> > > > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > > > ---
> > > > > > v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
> > > > > >     restoring state.
> > > > > 
> > > > > You don't seem to have addressed my other comments on v1:
> > > > 
> > > > I've got them in v3, I noted that I hadn't addresses you comment on this
> > > > patch in the #0/46.
> > > 
> > > So you did; I did read the 0/46, but for some reason all that stuck in
> > > my head was the WFE stuff. 
> > > 
> > > AFAICS you just need to re-roll this and #25,
> > 
> > I don't think you mean #25? That is "xen: arm64: add guest type to
> > domain field." which you've acked.
> 
> Sorry, I meant #5.

Ah yes, I've just resent that one.

> > When I'm applying my own patches I prefer to do it from the list rather
> > than short cutting them from my own tree, keep me honest/from making
> > mistakes. How about I include an index of acked/unacked patches in the
> > zeroeth mail? You ought to be able to just mark it all as read.
> 
> Fair enough -- no need to index them; I just keep all previous versions
> of a series around so I can easily find the comments.  But this won't
> need a v4, will it? :)

I hope not!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:09:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:09: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 1U8Yi0-0006vo-G5; Thu, 21 Feb 2013 16:09:20 +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 1U8Yhy-0006vB-OW
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:09:19 +0000
Received: from [85.158.137.99:30624] by server-9.bemta-3.messagelabs.com id
	69/3D-09484-E9646215; Thu, 21 Feb 2013 16:09:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361462924!12303287!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 21 Feb 2013 16:08:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 16:08:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YhP-0007dK-Ra; Thu, 21 Feb 2013 16:08:43 +0000
Date: Thu, 21 Feb 2013 16:08:43 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221160843.GD24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
	<20130221145628.GN24051@ocelot.phlegethon.org>
	<1361460367.26546.63.camel@zakaz.uk.xensource.com>
	<1361462587.26546.77.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361462587.26546.77.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 05/46] xen: arm64: initial build + config
	changes, start of day 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

At 16:03 +0000 on 21 Feb (1361462587), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:26 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-21 at 14:56 +0000, Tim Deegan wrote:
> > > At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> > > > +2:      PRINT("- Started in Hyp mode -\r\n")
> > > > +
> > > > +hyp:
> > > 
> > > I though we were going to use "EL3" instead of "Hyp".
> > 
> > Sorry, looks like I missed a few comments when I went through this one.
> 
> s/EL3/EL2/g
> 
> This is what I have now:
> 
> 8<-----------------------------------------
> 
> From e4587a06df0d04ccbfd04ec7cc371900fe7dabf4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 10 Dec 2012 14:19:00 +0000
> Subject: [PATCH] xen: arm64: initial build + config changes, start of day code
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
> v3: - s/hyp/el2/
>     - remove dead code
>     - fix comment formatting
> v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
>       defining in head.S
>     - Nuke hard tabs in head.S and mode_switch.S with expand(1)
> ---
>  Config.mk                        |    2 +-
>  config/arm64.mk                  |   12 ++
>  xen/arch/arm/Makefile            |    1 +
>  xen/arch/arm/Rules.mk            |    6 +
>  xen/arch/arm/arm64/Makefile      |    1 +
>  xen/arch/arm/arm64/head.S        |  393 ++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
>  xen/arch/arm/xen.lds.S           |    8 +-
>  xen/include/asm-arm/page.h       |    1 +
>  xen/include/public/arch-arm.h    |   14 ++
>  xen/include/public/hvm/save.h    |    2 +-
>  xen/include/public/xen.h         |    2 +-
>  xen/include/xen/libelf.h         |    2 +-
>  13 files changed, 522 insertions(+), 5 deletions(-)
>  create mode 100644 config/arm64.mk
>  create mode 100644 xen/arch/arm/arm64/Makefile
>  create mode 100644 xen/arch/arm/arm64/head.S
>  create mode 100644 xen/arch/arm/arm64/mode_switch.S
> 
> diff --git a/Config.mk b/Config.mk
> index 64541c8..ea64925 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -15,7 +15,7 @@ debug_symbols ?= $(debug)
>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
>                           -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
> -                         -e s/armv7.*/arm32/)
> +                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
>  
>  XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
>  XEN_OS              ?= $(shell uname -s)
> diff --git a/config/arm64.mk b/config/arm64.mk
> new file mode 100644
> index 0000000..b2457eb
> --- /dev/null
> +++ b/config/arm64.mk
> @@ -0,0 +1,12 @@
> +CONFIG_ARM := y
> +CONFIG_ARM_64 := y
> +CONFIG_ARM_$(XEN_OS) := y
> +
> +CFLAGS += #-marm -march= -mcpu= etc
> +
> +HAS_PL011 := y
> +
> +# Use only if calling $(LD) directly.
> +LDFLAGS_DIRECT += -maarch64elf
> +
> +CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index f2822f2..7ff67c7 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -1,4 +1,5 @@
>  subdir-$(arm32) += arm32
> +subdir-$(arm64) += arm64
>  
>  obj-y += early_printk.o
>  obj-y += domain.o
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 5b5768a..29b605d 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -26,6 +26,12 @@ arm32 := y
>  arm64 := n
>  endif
>  
> +ifeq ($(TARGET_SUBARCH),arm64)
> +CFLAGS += -mcpu=generic
> +arm32 := n
> +arm64 := y
> +endif
> +
>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> new file mode 100644
> index 0000000..dffbeb1
> --- /dev/null
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -0,0 +1 @@
> +obj-y += mode_switch.o
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> new file mode 100644
> index 0000000..b7ab251
> --- /dev/null
> +++ b/xen/arch/arm/arm64/head.S
> @@ -0,0 +1,393 @@
> +/*
> + * xen/arch/arm/head.S
> + *
> + * Start-of-day code for an ARMv8.
> + *
> + * Ian Campbell <ian.campbell@citrix.com>
> + * Copyright (c) 2012 Citrix Systems.
> + *
> + * Based on ARMv7-A head.S by
> + * Tim Deegan <tim@xen.org>
> + *
> + * 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 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.
> + */
> +
> +#include <asm/config.h>
> +#include <asm/page.h>
> +#include <asm/asm_defns.h>
> +
> +#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
> +#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
> +#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
> +#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
> +
> +/* Macro to print a string to the UART, if there is one.
> + * Clobbers r0-r3. */
> +#ifdef EARLY_UART_ADDRESS
> +#define PRINT(_s)       \
> +        adr   x0, 98f ; \
> +        bl    puts    ; \
> +        b     99f     ; \
> +98:     .asciz _s     ; \
> +        .align 2      ; \
> +99:
> +#else
> +#define PRINT(s)
> +#endif
> +
> +        /*.aarch64*/
> +
> +        /*
> +         * Kernel startup entry point.
> +         * ---------------------------
> +         *
> +         * The requirements are:
> +         *   MMU = off, D-cache = off, I-cache = on or off,
> +         *   x0 = physical address to the FDT blob.
> +         *
> +         * This must be the very first address in the loaded image.
> +         * It should be linked at XEN_VIRT_START, and loaded at any
> +         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
> +         * or the initial pagetable code below will need adjustment.
> +         */
> +
> +        .global start
> +start:
> +        /*
> +         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
> +         */
> +        b       real_start           /* branch to kernel start, magic */
> +        .long   0                    /* reserved */
> +        .quad   0                    /* Image load offset from start of RAM */
> +        .quad   0                    /* reserved */
> +        .quad   0                    /* reserved */
> +
> +real_start:
> +        msr   DAIFSet, 0xf           /* Disable all interrupts */
> +
> +        /* Save the bootloader arguments in less-clobberable registers */
> +        mov   x21, x0                /* x21 := DTB, physical address  */
> +
> +        /* Find out where we are */
> +        ldr   x0, =start
> +        adr   x19, start             /* x19 := paddr (start) */
> +        sub   x20, x19, x0           /* x20 := phys-offset */
> +
> +        /* Using the DTB in the .dtb section? */
> +#ifdef CONFIG_DTB_FILE
> +        ldr   x21, =_sdtb
> +        add   x21, x21, x20          /* x21 := paddr(DTB) */
> +#endif
> +
> +        /* Are we the boot CPU? */
> +        mov   x22, #0                /* x22 := CPU ID */
> +        mrs   x0, mpidr_el1
> +        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
> +        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
> +
> +        mov   x13, #(0xff << 24)
> +        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
> +        b.eq  boot_cpu               /* If we're CPU 0, boot now */
> +
> +        /* Non-boot CPUs wait here to be woken up one at a time. */
> +1:      dsb   sy
> +        ldr   x0, =smp_up_cpu        /* VA of gate */
> +        add   x0, x0, x20            /* PA of gate */
> +        ldr   x1, [x0]               /* Which CPU is being booted? */
> +        cmp   x1, x22                /* Is it us? */
> +        b.eq  2f
> +        wfe
> +        b     1b
> +2:
> +
> +boot_cpu:
> +#ifdef EARLY_UART_ADDRESS
> +        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
> +        cbnz  x22, 1f
> +        bl    init_uart                 /* CPU 0 sets up the UART too */
> +1:      PRINT("- CPU ")
> +        mov   x0, x22
> +        bl    putn
> +        PRINT(" booting -\r\n")
> +#endif
> +
> +        PRINT("- Current EL ")
> +        mrs   x0, CurrentEL
> +        bl    putn
> +        PRINT(" -\r\n")
> +
> +        /* Are we in EL3 */
> +        mrs   x0, CurrentEL
> +        cmp   x0, #PSR_MODE_EL3t
> +        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
> +        b.eq  1f /* Yes */
> +
> +        /* Are we in EL2 */
> +        cmp   x0, #PSR_MODE_EL2t
> +        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
> +        b.eq  2f /* Yes */
> +
> +        /* Otherwise, it must have been EL0 or EL1 */
> +        PRINT("- CPU is not in EL3 or EL2 -\r\n")
> +        b     fail
> +
> +1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
> +        ldr   x1, =enter_el2_mode    /* VA of function */
> +        add   x1, x1, x20            /* PA of function */
> +        adr   x30, el2               /* Set return address for call */
> +        br    x1                     /* Call function */
> +
> +2:      PRINT("- Started in EL2 mode -\r\n")
> +
> +el2:
> +        /* Zero BSS On the boot CPU to avoid nasty surprises */
> +        cbnz  x22, skip_bss
> +
> +        PRINT("- Zero BSS -\r\n")
> +        ldr   x0, =__bss_start       /* Load start & end of bss */
> +        ldr   x1, =__bss_end
> +        add   x0, x0, x20            /* Apply physical offset */
> +        add   x1, x1, x20
> +
> +1:      str   xzr, [x0], #8
> +        cmp   x0, x1
> +        b.lo  1b
> +
> +skip_bss:
> +
> +        PRINT("- Setting up control registers -\r\n")
> +
> +        /* Set up memory attribute type tables */
> +        ldr   x0, =MAIRVAL
> +        msr   mair_el2, x0
> +
> +        /* Set up the HTCR:
> +         * PASize -- 4G
> +         * Top byte is used
> +         * PT walks use Outer-Shareable accesses,
> +         * PT walks are write-back, no-write-allocate in both cache levels,
> +         * Full 64-bit address space goes through this table. */
> +        ldr   x0, =0x80802500
> +        msr   tcr_el2, x0
> +
> +        /* Set up the HSCTLR:
> +         * Exceptions in LE ARM,
> +         * Low-latency IRQs disabled,
> +         * Write-implies-XN disabled (for now),
> +         * D-cache disabled (for now),
> +         * I-cache enabled,
> +         * Alignment checking enabled,
> +         * MMU translation disabled (for now). */
> +        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
> +        msr   SCTLR_EL2, x0
> +
> +        /* Write Xen's PT's paddr into the HTTBR */
> +        ldr   x4, =xen_pgtable
> +        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
> +        msr   TTBR0_EL2, x4
> +
> +        /* Non-boot CPUs don't need to rebuild the pagetable */
> +        cbnz  x22, pt_ready
> +
> +        ldr   x1, =xen_first
> +        add   x1, x1, x20            /* x1 := paddr (xen_first) */
> +        mov   x3, #PT_PT             /* x2 := table map of xen_first */
> +        orr   x2, x1, x3             /* (+ rights for linear PT) */
> +        str   x2, [x4, #0]           /* Map it in slot 0 */
> +
> +        mov   x4, x1                 /* Next level into xen_first */
> +
> +       /* console fixmap */
> +#ifdef EARLY_UART_ADDRESS
> +        ldr   x1, =xen_fixmap
> +        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
> +        lsr   x2, x23, #12
> +        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
> +        mov   x3, #PT_DEV_L3
> +        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
> +        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
> +#endif
> +
> +        /* Build the baseline idle pagetable's first-level entries */
> +        ldr   x1, =xen_second
> +        add   x1, x1, x20            /* x1 := paddr (xen_second) */
> +        mov   x3, #PT_PT             /* x2 := table map of xen_second */
> +        orr   x2, x1, x3             /* (+ rights for linear PT) */
> +        str   x2, [x4, #0]           /* Map it in slot 0 */
> +        add   x2, x2, #0x1000
> +        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
> +        add   x2, x2, #0x1000
> +        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
> +        add   x2, x2, #0x1000
> +        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
> +
> +        /* Now set up the second-level entries */
> +        mov   x3, #PT_MEM
> +        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
> +        orr   x4, xzr, x19, lsr #18
> +        str   x2, [x1, x4]           /* Map Xen there */
> +        ldr   x4, =start
> +        lsr   x4, x4, #18            /* Slot for vaddr(start) */
> +        str   x2, [x1, x4]           /* Map Xen there too */
> +
> +        /* xen_fixmap pagetable */
> +        ldr   x2, =xen_fixmap
> +        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
> +        mov   x3, #PT_PT
> +        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
> +        add   x4, x4, #8
> +        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
> +
> +        lsr   x2, x21, #21
> +        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
> +        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
> +        orr   x2, x2, x3
> +        add   x4, x4, #8
> +        str   x2, [x1, x4]           /* Map it in the early boot slot */
> +
> +pt_ready:
> +        PRINT("- Turning on paging -\r\n")
> +
> +        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
> +        mrs   x0, SCTLR_EL2
> +        orr   x0, x0, #SCTLR_M       /* Enable MMU */
> +        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
> +        dsb   sy                     /* Flush PTE writes and finish reads */
> +        msr   SCTLR_EL2, x0          /* now paging is enabled */
> +        isb                          /* Now, flush the icache */
> +        br    x1                     /* Get a proper vaddr into PC */
> +paging:
> +
> +#ifdef EARLY_UART_ADDRESS
> +        /* Use a virtual address to access the UART. */
> +        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
> +#endif
> +
> +        PRINT("- Ready -\r\n")
> +
> +        /* The boot CPU should go straight into C now */
> +        cbz   x22, launch
> +
> +        /* Non-boot CPUs need to move on to the relocated pagetables */
> +        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
> +        add   x4, x4, x20            /* PA of it */
> +        ldr   x4, [x4]               /* Actual value */
> +        dsb   sy
> +        msr   TTBR0_EL2, x4
> +        dsb   sy
> +        isb
> +        tlbi  alle2
> +        dsb   sy                     /* Ensure completion of TLB flush */
> +        isb
> +
> +        /* Non-boot CPUs report that they've got this far */
> +        ldr   x0, =ready_cpus
> +1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
> +        add   x1, x1, #1             /* Atomically { ++                   } */
> +        stlxr w2, x1, [x0]           /*            { writeback            } */
> +        cbnz  w2, 1b
> +        dsb   sy
> +        dc    cvac, x0               /* Flush D-Cache */
> +        dsb   sy
> +
> +        /* Here, the non-boot CPUs must wait again -- they're now running on
> +         * the boot CPU's pagetables so it's safe for the boot CPU to
> +         * overwrite the non-relocated copy of Xen.  Once it's done that,
> +         * and brought up the memory allocator, non-boot CPUs can get their
> +         * own stacks and enter C. */
> +1:      wfe
> +        dsb   sy
> +        ldr   x0, =smp_up_cpu
> +        ldr   x1, [x0]               /* Which CPU is being booted? */
> +        cmp   x1, x12                /* Is it us? */
> +        b.ne  1b
> +
> +launch:
> +        ldr   x0, =init_stack        /* Find the boot-time stack */
> +        ldr   x0, [x0]
> +        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
> +        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
> +        mov   sp, x0
> +
> +        mov   x0, x20                /* Marshal args: - phys_offset */
> +        mov   x1, x21                /*               - FDT */
> +        mov   x2, x22                /*               - CPU ID */
> +        cbz   x22, start_xen         /* and disappear into the land of C */
> +        b     start_secondary        /* (to the appropriate entry point) */
> +
> +/* Fail-stop
> + * r0: string explaining why */
> +fail:   PRINT("- Boot failed -\r\n")
> +1:      wfe
> +        b     1b
> +
> +#ifdef EARLY_UART_ADDRESS
> +
> +/* Bring up the UART. Specific to the PL011 UART.
> + * Clobbers r0-r2 */
> +init_uart:
> +        mov   x1, #0x0
> +        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
> +        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
> +        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
> +        mov   x1, #0x60              /* 8n1 */
> +        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
> +        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
> +        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
> +        adr   x0, 1f
> +        b     puts
> +1:      .asciz "- UART enabled -\r\n"
> +        .align 4
> +
> +/* Print early debug messages.  Specific to the PL011 UART.
> + * r0: Nul-terminated string to print.
> + * Clobbers r0-r2 */
> +puts:
> +        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
> +        tst   w2, #0x8               /* Check BUSY bit */
> +        b.ne  puts                   /* Wait for the UART to be ready */
> +        ldrb  w2, [x0], #1           /* Load next char */
> +        cbz   w2, 1f                 /* Exit on nul */
> +        str   w2, [x23]              /* -> UARTDR (Data Register) */
> +        b     puts
> +1:
> +        ret
> +
> +/* Print a 32-bit number in hex.  Specific to the PL011 UART.
> + * r0: Number to print.
> + * clobbers r0-r3 */
> +putn:
> +        adr   x1, hex
> +        mov   x3, #8
> +1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
> +        tst   w2, #0x8               /* Check BUSY bit */
> +        b.ne  1b                     /* Wait for the UART to be ready */
> +        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
> +        lsr   x2, x2, #28
> +        ldrb  w2, [x1, x2]           /* Convert to a char */
> +        strb  w2, [x23]              /* -> UARTDR (Data Register) */
> +        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
> +        subs  x3, x3, #1
> +        b.ne  1b
> +        ret
> +
> +hex:    .ascii "0123456789abcdef"
> +        .align 2
> +
> +#else  /* EARLY_UART_ADDRESS */
> +
> +init_uart:
> +.global early_puts
> +early_puts:
> +puts:
> +putn:   mov   pc, lr
> +
> +#endif /* EARLY_UART_ADDRESS */
> diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
> new file mode 100644
> index 0000000..4c38181
> --- /dev/null
> +++ b/xen/arch/arm/arm64/mode_switch.S
> @@ -0,0 +1,83 @@
> +/*
> + * xen/arch/arm/arm64/mode_switch.S
> + *
> + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> + *       bootwrapper.
> + *
> + * Ian Campbell <ian.campbell@citrix.com>
> + * Copyright (c) 2012 Citrix Systems.
> + *
> + * 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 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.
> + */
> +
> +#include <asm/config.h>
> +#include <asm/page.h>
> +#include <asm/asm_defns.h>
> +
> +/* Get up a CPU into EL2.  Clobbers x0-x3.
> + *
> + * Expects x22 == CPU number
> + * Expects x30  == EL2 entry point
> + *
> + * This code is specific to the VE model, and not intended to be used
> + * on production systems.  As such it's a bit hackier than the main
> + * boot code in head.S.  In future it will be replaced by better
> + * integration with the bootloader/firmware so that Xen always starts
> + * at EL2.
> + */
> +
> +.globl enter_el2_mode
> +enter_el2_mode:
> +        mov     x0, #0x30                       // RES1
> +        orr     x0, x0, #(1 << 0)               // Non-secure EL1
> +        orr     x0, x0, #(1 << 8)               // HVC enable
> +        orr     x0, x0, #(1 << 10)              // 64-bit EL2
> +        msr     scr_el3, x0
> +
> +        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
> +
> +        ldr     x0, =0x01800000                 // 24Mhz
> +        msr     cntfrq_el0, x0
> +
> +        /*
> +         * Check for the primary CPU to avoid a race on the distributor
> +         * registers.
> +         */
> +        cbnz    x22, 1f
> +
> +        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
> +        mov     w0, #~0                         // Grp1 interrupts
> +        str     w0, [x1], #4
> +        b.ne    2f                              // Only local interrupts for secondary CPUs
> +        str     w0, [x1], #4
> +        str     w0, [x1], #4
> +
> +2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
> +        ldr     w0, [x1]
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
> +        str     w0, [x1, #4]                    // GICC_PMR
> +
> +        msr     sctlr_el2, xzr
> +
> +        /*
> +         * Prepare the switch to the EL2_SP1 mode from EL3
> +         */
> +        msr     elr_el3, x30                    // Return to desired function
> +        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
> +        msr     spsr_el3, x1
> +        eret
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 410d7db..b1f0a78 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -11,7 +11,13 @@
>  
>  ENTRY(start)
>  
> -OUTPUT_ARCH(arm)
> +#if defined(__arm__)
> +#define FORMAT arm
> +#elif defined(__aarch64__)
> +#define FORMAT aarch64
> +#endif
> +
> +OUTPUT_ARCH(FORMAT)
>  
>  PHDRS
>  {
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 9acd0af..e0a636f 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -38,6 +38,7 @@
>   */
>  #define MAIR0VAL 0xeeaa4400
>  #define MAIR1VAL 0xff000004
> +#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
>  
>  /*
>   * Attribute Indexes.
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 8dd9062..dc12524 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -174,6 +174,8 @@ typedef uint64_t xen_callback_t;
>  
>  /* 0-4: Mode */
>  #define PSR_MODE_MASK 0x1f
> +
> +/* 32 bit modes */
>  #define PSR_MODE_USR 0x10
>  #define PSR_MODE_FIQ 0x11
>  #define PSR_MODE_IRQ 0x12
> @@ -184,6 +186,18 @@ typedef uint64_t xen_callback_t;
>  #define PSR_MODE_UND 0x1b
>  #define PSR_MODE_SYS 0x1f
>  
> +/* 64 bit modes */
> +#ifdef CONFIG_ARM_64
> +#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
> +#define PSR_MODE_EL3h 0x0d
> +#define PSR_MODE_EL3t 0x0c
> +#define PSR_MODE_EL2h 0x09
> +#define PSR_MODE_EL2t 0x08
> +#define PSR_MODE_EL1h 0x05
> +#define PSR_MODE_EL1t 0x04
> +#define PSR_MODE_EL0t 0x00
> +#endif
> +
>  #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
>  #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
>  #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
> diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
> index 5538d8e..cc8b5fd 100644
> --- a/xen/include/public/hvm/save.h
> +++ b/xen/include/public/hvm/save.h
> @@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
>  
>  #if defined(__i386__) || defined(__x86_64__)
>  #include "../arch-x86/hvm/save.h"
> -#elif defined(__arm__)
> +#elif defined(__arm__) || defined(__aarch64__)
>  #include "../arch-arm/hvm/save.h"
>  #else
>  #error "unsupported architecture"
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 846f446..a1927c0 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -31,7 +31,7 @@
>  
>  #if defined(__i386__) || defined(__x86_64__)
>  #include "arch-x86/xen.h"
> -#elif defined(__arm__)
> +#elif defined(__arm__) || defined (__aarch64__)
>  #include "arch-arm.h"
>  #else
>  #error "Unsupported architecture"
> diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
> index e8f6508..218bb18 100644
> --- 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(__arm__)
> +#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
>  #define XEN_ELF_LITTLE_ENDIAN
>  #else
>  #error define architectural endianness
> -- 
> 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 Thu Feb 21 16:09:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:09: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 1U8Yi0-0006vo-G5; Thu, 21 Feb 2013 16:09:20 +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 1U8Yhy-0006vB-OW
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:09:19 +0000
Received: from [85.158.137.99:30624] by server-9.bemta-3.messagelabs.com id
	69/3D-09484-E9646215; Thu, 21 Feb 2013 16:09:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361462924!12303287!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 21 Feb 2013 16:08:45 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 16:08:45 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8YhP-0007dK-Ra; Thu, 21 Feb 2013 16:08:43 +0000
Date: Thu, 21 Feb 2013 16:08:43 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221160843.GD24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-5-git-send-email-ian.campbell@citrix.com>
	<20130221145628.GN24051@ocelot.phlegethon.org>
	<1361460367.26546.63.camel@zakaz.uk.xensource.com>
	<1361462587.26546.77.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361462587.26546.77.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 05/46] xen: arm64: initial build + config
	changes, start of day 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

At 16:03 +0000 on 21 Feb (1361462587), Ian Campbell wrote:
> On Thu, 2013-02-21 at 15:26 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-21 at 14:56 +0000, Tim Deegan wrote:
> > > At 16:47 +0000 on 14 Feb (1360860439), Ian Campbell wrote:
> > > > +2:      PRINT("- Started in Hyp mode -\r\n")
> > > > +
> > > > +hyp:
> > > 
> > > I though we were going to use "EL3" instead of "Hyp".
> > 
> > Sorry, looks like I missed a few comments when I went through this one.
> 
> s/EL3/EL2/g
> 
> This is what I have now:
> 
> 8<-----------------------------------------
> 
> From e4587a06df0d04ccbfd04ec7cc371900fe7dabf4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 10 Dec 2012 14:19:00 +0000
> Subject: [PATCH] xen: arm64: initial build + config changes, start of day code
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
> v3: - s/hyp/el2/
>     - remove dead code
>     - fix comment formatting
> v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
>       defining in head.S
>     - Nuke hard tabs in head.S and mode_switch.S with expand(1)
> ---
>  Config.mk                        |    2 +-
>  config/arm64.mk                  |   12 ++
>  xen/arch/arm/Makefile            |    1 +
>  xen/arch/arm/Rules.mk            |    6 +
>  xen/arch/arm/arm64/Makefile      |    1 +
>  xen/arch/arm/arm64/head.S        |  393 ++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
>  xen/arch/arm/xen.lds.S           |    8 +-
>  xen/include/asm-arm/page.h       |    1 +
>  xen/include/public/arch-arm.h    |   14 ++
>  xen/include/public/hvm/save.h    |    2 +-
>  xen/include/public/xen.h         |    2 +-
>  xen/include/xen/libelf.h         |    2 +-
>  13 files changed, 522 insertions(+), 5 deletions(-)
>  create mode 100644 config/arm64.mk
>  create mode 100644 xen/arch/arm/arm64/Makefile
>  create mode 100644 xen/arch/arm/arm64/head.S
>  create mode 100644 xen/arch/arm/arm64/mode_switch.S
> 
> diff --git a/Config.mk b/Config.mk
> index 64541c8..ea64925 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -15,7 +15,7 @@ debug_symbols ?= $(debug)
>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
>                           -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
> -                         -e s/armv7.*/arm32/)
> +                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
>  
>  XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
>  XEN_OS              ?= $(shell uname -s)
> diff --git a/config/arm64.mk b/config/arm64.mk
> new file mode 100644
> index 0000000..b2457eb
> --- /dev/null
> +++ b/config/arm64.mk
> @@ -0,0 +1,12 @@
> +CONFIG_ARM := y
> +CONFIG_ARM_64 := y
> +CONFIG_ARM_$(XEN_OS) := y
> +
> +CFLAGS += #-marm -march= -mcpu= etc
> +
> +HAS_PL011 := y
> +
> +# Use only if calling $(LD) directly.
> +LDFLAGS_DIRECT += -maarch64elf
> +
> +CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index f2822f2..7ff67c7 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -1,4 +1,5 @@
>  subdir-$(arm32) += arm32
> +subdir-$(arm64) += arm64
>  
>  obj-y += early_printk.o
>  obj-y += domain.o
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 5b5768a..29b605d 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -26,6 +26,12 @@ arm32 := y
>  arm64 := n
>  endif
>  
> +ifeq ($(TARGET_SUBARCH),arm64)
> +CFLAGS += -mcpu=generic
> +arm32 := n
> +arm64 := y
> +endif
> +
>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> new file mode 100644
> index 0000000..dffbeb1
> --- /dev/null
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -0,0 +1 @@
> +obj-y += mode_switch.o
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> new file mode 100644
> index 0000000..b7ab251
> --- /dev/null
> +++ b/xen/arch/arm/arm64/head.S
> @@ -0,0 +1,393 @@
> +/*
> + * xen/arch/arm/head.S
> + *
> + * Start-of-day code for an ARMv8.
> + *
> + * Ian Campbell <ian.campbell@citrix.com>
> + * Copyright (c) 2012 Citrix Systems.
> + *
> + * Based on ARMv7-A head.S by
> + * Tim Deegan <tim@xen.org>
> + *
> + * 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 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.
> + */
> +
> +#include <asm/config.h>
> +#include <asm/page.h>
> +#include <asm/asm_defns.h>
> +
> +#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
> +#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
> +#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
> +#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
> +
> +/* Macro to print a string to the UART, if there is one.
> + * Clobbers r0-r3. */
> +#ifdef EARLY_UART_ADDRESS
> +#define PRINT(_s)       \
> +        adr   x0, 98f ; \
> +        bl    puts    ; \
> +        b     99f     ; \
> +98:     .asciz _s     ; \
> +        .align 2      ; \
> +99:
> +#else
> +#define PRINT(s)
> +#endif
> +
> +        /*.aarch64*/
> +
> +        /*
> +         * Kernel startup entry point.
> +         * ---------------------------
> +         *
> +         * The requirements are:
> +         *   MMU = off, D-cache = off, I-cache = on or off,
> +         *   x0 = physical address to the FDT blob.
> +         *
> +         * This must be the very first address in the loaded image.
> +         * It should be linked at XEN_VIRT_START, and loaded at any
> +         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
> +         * or the initial pagetable code below will need adjustment.
> +         */
> +
> +        .global start
> +start:
> +        /*
> +         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
> +         */
> +        b       real_start           /* branch to kernel start, magic */
> +        .long   0                    /* reserved */
> +        .quad   0                    /* Image load offset from start of RAM */
> +        .quad   0                    /* reserved */
> +        .quad   0                    /* reserved */
> +
> +real_start:
> +        msr   DAIFSet, 0xf           /* Disable all interrupts */
> +
> +        /* Save the bootloader arguments in less-clobberable registers */
> +        mov   x21, x0                /* x21 := DTB, physical address  */
> +
> +        /* Find out where we are */
> +        ldr   x0, =start
> +        adr   x19, start             /* x19 := paddr (start) */
> +        sub   x20, x19, x0           /* x20 := phys-offset */
> +
> +        /* Using the DTB in the .dtb section? */
> +#ifdef CONFIG_DTB_FILE
> +        ldr   x21, =_sdtb
> +        add   x21, x21, x20          /* x21 := paddr(DTB) */
> +#endif
> +
> +        /* Are we the boot CPU? */
> +        mov   x22, #0                /* x22 := CPU ID */
> +        mrs   x0, mpidr_el1
> +        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
> +        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
> +
> +        mov   x13, #(0xff << 24)
> +        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
> +        b.eq  boot_cpu               /* If we're CPU 0, boot now */
> +
> +        /* Non-boot CPUs wait here to be woken up one at a time. */
> +1:      dsb   sy
> +        ldr   x0, =smp_up_cpu        /* VA of gate */
> +        add   x0, x0, x20            /* PA of gate */
> +        ldr   x1, [x0]               /* Which CPU is being booted? */
> +        cmp   x1, x22                /* Is it us? */
> +        b.eq  2f
> +        wfe
> +        b     1b
> +2:
> +
> +boot_cpu:
> +#ifdef EARLY_UART_ADDRESS
> +        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
> +        cbnz  x22, 1f
> +        bl    init_uart                 /* CPU 0 sets up the UART too */
> +1:      PRINT("- CPU ")
> +        mov   x0, x22
> +        bl    putn
> +        PRINT(" booting -\r\n")
> +#endif
> +
> +        PRINT("- Current EL ")
> +        mrs   x0, CurrentEL
> +        bl    putn
> +        PRINT(" -\r\n")
> +
> +        /* Are we in EL3 */
> +        mrs   x0, CurrentEL
> +        cmp   x0, #PSR_MODE_EL3t
> +        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
> +        b.eq  1f /* Yes */
> +
> +        /* Are we in EL2 */
> +        cmp   x0, #PSR_MODE_EL2t
> +        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
> +        b.eq  2f /* Yes */
> +
> +        /* Otherwise, it must have been EL0 or EL1 */
> +        PRINT("- CPU is not in EL3 or EL2 -\r\n")
> +        b     fail
> +
> +1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
> +        ldr   x1, =enter_el2_mode    /* VA of function */
> +        add   x1, x1, x20            /* PA of function */
> +        adr   x30, el2               /* Set return address for call */
> +        br    x1                     /* Call function */
> +
> +2:      PRINT("- Started in EL2 mode -\r\n")
> +
> +el2:
> +        /* Zero BSS On the boot CPU to avoid nasty surprises */
> +        cbnz  x22, skip_bss
> +
> +        PRINT("- Zero BSS -\r\n")
> +        ldr   x0, =__bss_start       /* Load start & end of bss */
> +        ldr   x1, =__bss_end
> +        add   x0, x0, x20            /* Apply physical offset */
> +        add   x1, x1, x20
> +
> +1:      str   xzr, [x0], #8
> +        cmp   x0, x1
> +        b.lo  1b
> +
> +skip_bss:
> +
> +        PRINT("- Setting up control registers -\r\n")
> +
> +        /* Set up memory attribute type tables */
> +        ldr   x0, =MAIRVAL
> +        msr   mair_el2, x0
> +
> +        /* Set up the HTCR:
> +         * PASize -- 4G
> +         * Top byte is used
> +         * PT walks use Outer-Shareable accesses,
> +         * PT walks are write-back, no-write-allocate in both cache levels,
> +         * Full 64-bit address space goes through this table. */
> +        ldr   x0, =0x80802500
> +        msr   tcr_el2, x0
> +
> +        /* Set up the HSCTLR:
> +         * Exceptions in LE ARM,
> +         * Low-latency IRQs disabled,
> +         * Write-implies-XN disabled (for now),
> +         * D-cache disabled (for now),
> +         * I-cache enabled,
> +         * Alignment checking enabled,
> +         * MMU translation disabled (for now). */
> +        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
> +        msr   SCTLR_EL2, x0
> +
> +        /* Write Xen's PT's paddr into the HTTBR */
> +        ldr   x4, =xen_pgtable
> +        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
> +        msr   TTBR0_EL2, x4
> +
> +        /* Non-boot CPUs don't need to rebuild the pagetable */
> +        cbnz  x22, pt_ready
> +
> +        ldr   x1, =xen_first
> +        add   x1, x1, x20            /* x1 := paddr (xen_first) */
> +        mov   x3, #PT_PT             /* x2 := table map of xen_first */
> +        orr   x2, x1, x3             /* (+ rights for linear PT) */
> +        str   x2, [x4, #0]           /* Map it in slot 0 */
> +
> +        mov   x4, x1                 /* Next level into xen_first */
> +
> +       /* console fixmap */
> +#ifdef EARLY_UART_ADDRESS
> +        ldr   x1, =xen_fixmap
> +        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
> +        lsr   x2, x23, #12
> +        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
> +        mov   x3, #PT_DEV_L3
> +        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
> +        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
> +#endif
> +
> +        /* Build the baseline idle pagetable's first-level entries */
> +        ldr   x1, =xen_second
> +        add   x1, x1, x20            /* x1 := paddr (xen_second) */
> +        mov   x3, #PT_PT             /* x2 := table map of xen_second */
> +        orr   x2, x1, x3             /* (+ rights for linear PT) */
> +        str   x2, [x4, #0]           /* Map it in slot 0 */
> +        add   x2, x2, #0x1000
> +        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
> +        add   x2, x2, #0x1000
> +        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
> +        add   x2, x2, #0x1000
> +        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
> +
> +        /* Now set up the second-level entries */
> +        mov   x3, #PT_MEM
> +        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
> +        orr   x4, xzr, x19, lsr #18
> +        str   x2, [x1, x4]           /* Map Xen there */
> +        ldr   x4, =start
> +        lsr   x4, x4, #18            /* Slot for vaddr(start) */
> +        str   x2, [x1, x4]           /* Map Xen there too */
> +
> +        /* xen_fixmap pagetable */
> +        ldr   x2, =xen_fixmap
> +        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
> +        mov   x3, #PT_PT
> +        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
> +        add   x4, x4, #8
> +        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
> +
> +        lsr   x2, x21, #21
> +        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
> +        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
> +        orr   x2, x2, x3
> +        add   x4, x4, #8
> +        str   x2, [x1, x4]           /* Map it in the early boot slot */
> +
> +pt_ready:
> +        PRINT("- Turning on paging -\r\n")
> +
> +        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
> +        mrs   x0, SCTLR_EL2
> +        orr   x0, x0, #SCTLR_M       /* Enable MMU */
> +        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
> +        dsb   sy                     /* Flush PTE writes and finish reads */
> +        msr   SCTLR_EL2, x0          /* now paging is enabled */
> +        isb                          /* Now, flush the icache */
> +        br    x1                     /* Get a proper vaddr into PC */
> +paging:
> +
> +#ifdef EARLY_UART_ADDRESS
> +        /* Use a virtual address to access the UART. */
> +        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
> +#endif
> +
> +        PRINT("- Ready -\r\n")
> +
> +        /* The boot CPU should go straight into C now */
> +        cbz   x22, launch
> +
> +        /* Non-boot CPUs need to move on to the relocated pagetables */
> +        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
> +        add   x4, x4, x20            /* PA of it */
> +        ldr   x4, [x4]               /* Actual value */
> +        dsb   sy
> +        msr   TTBR0_EL2, x4
> +        dsb   sy
> +        isb
> +        tlbi  alle2
> +        dsb   sy                     /* Ensure completion of TLB flush */
> +        isb
> +
> +        /* Non-boot CPUs report that they've got this far */
> +        ldr   x0, =ready_cpus
> +1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
> +        add   x1, x1, #1             /* Atomically { ++                   } */
> +        stlxr w2, x1, [x0]           /*            { writeback            } */
> +        cbnz  w2, 1b
> +        dsb   sy
> +        dc    cvac, x0               /* Flush D-Cache */
> +        dsb   sy
> +
> +        /* Here, the non-boot CPUs must wait again -- they're now running on
> +         * the boot CPU's pagetables so it's safe for the boot CPU to
> +         * overwrite the non-relocated copy of Xen.  Once it's done that,
> +         * and brought up the memory allocator, non-boot CPUs can get their
> +         * own stacks and enter C. */
> +1:      wfe
> +        dsb   sy
> +        ldr   x0, =smp_up_cpu
> +        ldr   x1, [x0]               /* Which CPU is being booted? */
> +        cmp   x1, x12                /* Is it us? */
> +        b.ne  1b
> +
> +launch:
> +        ldr   x0, =init_stack        /* Find the boot-time stack */
> +        ldr   x0, [x0]
> +        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
> +        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
> +        mov   sp, x0
> +
> +        mov   x0, x20                /* Marshal args: - phys_offset */
> +        mov   x1, x21                /*               - FDT */
> +        mov   x2, x22                /*               - CPU ID */
> +        cbz   x22, start_xen         /* and disappear into the land of C */
> +        b     start_secondary        /* (to the appropriate entry point) */
> +
> +/* Fail-stop
> + * r0: string explaining why */
> +fail:   PRINT("- Boot failed -\r\n")
> +1:      wfe
> +        b     1b
> +
> +#ifdef EARLY_UART_ADDRESS
> +
> +/* Bring up the UART. Specific to the PL011 UART.
> + * Clobbers r0-r2 */
> +init_uart:
> +        mov   x1, #0x0
> +        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
> +        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
> +        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
> +        mov   x1, #0x60              /* 8n1 */
> +        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
> +        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
> +        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
> +        adr   x0, 1f
> +        b     puts
> +1:      .asciz "- UART enabled -\r\n"
> +        .align 4
> +
> +/* Print early debug messages.  Specific to the PL011 UART.
> + * r0: Nul-terminated string to print.
> + * Clobbers r0-r2 */
> +puts:
> +        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
> +        tst   w2, #0x8               /* Check BUSY bit */
> +        b.ne  puts                   /* Wait for the UART to be ready */
> +        ldrb  w2, [x0], #1           /* Load next char */
> +        cbz   w2, 1f                 /* Exit on nul */
> +        str   w2, [x23]              /* -> UARTDR (Data Register) */
> +        b     puts
> +1:
> +        ret
> +
> +/* Print a 32-bit number in hex.  Specific to the PL011 UART.
> + * r0: Number to print.
> + * clobbers r0-r3 */
> +putn:
> +        adr   x1, hex
> +        mov   x3, #8
> +1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
> +        tst   w2, #0x8               /* Check BUSY bit */
> +        b.ne  1b                     /* Wait for the UART to be ready */
> +        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
> +        lsr   x2, x2, #28
> +        ldrb  w2, [x1, x2]           /* Convert to a char */
> +        strb  w2, [x23]              /* -> UARTDR (Data Register) */
> +        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
> +        subs  x3, x3, #1
> +        b.ne  1b
> +        ret
> +
> +hex:    .ascii "0123456789abcdef"
> +        .align 2
> +
> +#else  /* EARLY_UART_ADDRESS */
> +
> +init_uart:
> +.global early_puts
> +early_puts:
> +puts:
> +putn:   mov   pc, lr
> +
> +#endif /* EARLY_UART_ADDRESS */
> diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
> new file mode 100644
> index 0000000..4c38181
> --- /dev/null
> +++ b/xen/arch/arm/arm64/mode_switch.S
> @@ -0,0 +1,83 @@
> +/*
> + * xen/arch/arm/arm64/mode_switch.S
> + *
> + * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
> + *       bootwrapper.
> + *
> + * Ian Campbell <ian.campbell@citrix.com>
> + * Copyright (c) 2012 Citrix Systems.
> + *
> + * 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 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.
> + */
> +
> +#include <asm/config.h>
> +#include <asm/page.h>
> +#include <asm/asm_defns.h>
> +
> +/* Get up a CPU into EL2.  Clobbers x0-x3.
> + *
> + * Expects x22 == CPU number
> + * Expects x30  == EL2 entry point
> + *
> + * This code is specific to the VE model, and not intended to be used
> + * on production systems.  As such it's a bit hackier than the main
> + * boot code in head.S.  In future it will be replaced by better
> + * integration with the bootloader/firmware so that Xen always starts
> + * at EL2.
> + */
> +
> +.globl enter_el2_mode
> +enter_el2_mode:
> +        mov     x0, #0x30                       // RES1
> +        orr     x0, x0, #(1 << 0)               // Non-secure EL1
> +        orr     x0, x0, #(1 << 8)               // HVC enable
> +        orr     x0, x0, #(1 << 10)              // 64-bit EL2
> +        msr     scr_el3, x0
> +
> +        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
> +
> +        ldr     x0, =0x01800000                 // 24Mhz
> +        msr     cntfrq_el0, x0
> +
> +        /*
> +         * Check for the primary CPU to avoid a race on the distributor
> +         * registers.
> +         */
> +        cbnz    x22, 1f
> +
> +        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
> +        mov     w0, #~0                         // Grp1 interrupts
> +        str     w0, [x1], #4
> +        b.ne    2f                              // Only local interrupts for secondary CPUs
> +        str     w0, [x1], #4
> +        str     w0, [x1], #4
> +
> +2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
> +        ldr     w0, [x1]
> +        mov     w0, #3                          // EnableGrp0 | EnableGrp1
> +        str     w0, [x1]
> +
> +        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
> +        str     w0, [x1, #4]                    // GICC_PMR
> +
> +        msr     sctlr_el2, xzr
> +
> +        /*
> +         * Prepare the switch to the EL2_SP1 mode from EL3
> +         */
> +        msr     elr_el3, x30                    // Return to desired function
> +        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
> +        msr     spsr_el3, x1
> +        eret
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 410d7db..b1f0a78 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -11,7 +11,13 @@
>  
>  ENTRY(start)
>  
> -OUTPUT_ARCH(arm)
> +#if defined(__arm__)
> +#define FORMAT arm
> +#elif defined(__aarch64__)
> +#define FORMAT aarch64
> +#endif
> +
> +OUTPUT_ARCH(FORMAT)
>  
>  PHDRS
>  {
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 9acd0af..e0a636f 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -38,6 +38,7 @@
>   */
>  #define MAIR0VAL 0xeeaa4400
>  #define MAIR1VAL 0xff000004
> +#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
>  
>  /*
>   * Attribute Indexes.
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 8dd9062..dc12524 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -174,6 +174,8 @@ typedef uint64_t xen_callback_t;
>  
>  /* 0-4: Mode */
>  #define PSR_MODE_MASK 0x1f
> +
> +/* 32 bit modes */
>  #define PSR_MODE_USR 0x10
>  #define PSR_MODE_FIQ 0x11
>  #define PSR_MODE_IRQ 0x12
> @@ -184,6 +186,18 @@ typedef uint64_t xen_callback_t;
>  #define PSR_MODE_UND 0x1b
>  #define PSR_MODE_SYS 0x1f
>  
> +/* 64 bit modes */
> +#ifdef CONFIG_ARM_64
> +#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
> +#define PSR_MODE_EL3h 0x0d
> +#define PSR_MODE_EL3t 0x0c
> +#define PSR_MODE_EL2h 0x09
> +#define PSR_MODE_EL2t 0x08
> +#define PSR_MODE_EL1h 0x05
> +#define PSR_MODE_EL1t 0x04
> +#define PSR_MODE_EL0t 0x00
> +#endif
> +
>  #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
>  #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
>  #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
> diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
> index 5538d8e..cc8b5fd 100644
> --- a/xen/include/public/hvm/save.h
> +++ b/xen/include/public/hvm/save.h
> @@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
>  
>  #if defined(__i386__) || defined(__x86_64__)
>  #include "../arch-x86/hvm/save.h"
> -#elif defined(__arm__)
> +#elif defined(__arm__) || defined(__aarch64__)
>  #include "../arch-arm/hvm/save.h"
>  #else
>  #error "unsupported architecture"
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 846f446..a1927c0 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -31,7 +31,7 @@
>  
>  #if defined(__i386__) || defined(__x86_64__)
>  #include "arch-x86/xen.h"
> -#elif defined(__arm__)
> +#elif defined(__arm__) || defined (__aarch64__)
>  #include "arch-arm.h"
>  #else
>  #error "Unsupported architecture"
> diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
> index e8f6508..218bb18 100644
> --- 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(__arm__)
> +#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
>  #define XEN_ELF_LITTLE_ENDIAN
>  #else
>  #error define architectural endianness
> -- 
> 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 Thu Feb 21 16:16:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yp1-0007fE-2V; Thu, 21 Feb 2013 16:16:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yoz-0007eo-DT
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:33 +0000
Received: from [85.158.137.99:38122] by server-8.bemta-3.messagelabs.com id
	C8/E5-25687-06846215; Thu, 21 Feb 2013 16:16:32 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361463382!14179381!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13411 invoked from network); 21 Feb 2013 16:16:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345378"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-L3;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:44 +0000
Message-ID: <1361463225-21750-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 4/5] gcov: Add small utility to deal with
	test coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  152 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index 96a7a5d..71786ca 100644
--- a/.gitignore
+++ b/.gitignore
@@ -229,6 +229,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index a4466d2..6b432f7 100644
--- a/.hgignore
+++ b/.hgignore
@@ -224,6 +224,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..6645a30
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,152 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, struct xen_sysctl *sys, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+
+    memset(sys, 0, sizeof(*sys));
+    sys->cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys->u.coverage_op;
+    cov->cmd = op;
+    cov->u.raw_info.p = ptr;
+
+    return xc_sysctl(gcov_xch, sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    struct xen_sysctl sys;
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* get total length */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, &sys, NULL) < 0 )
+        err(1, "getting total length");
+    total_len = sys.u.coverage_op.u.total_size;
+    fprintf(stderr, "returned %u bytes\n", (unsigned) total_len);
+
+    /* safe check */
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* allocate */
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, &sys, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    struct xen_sysctl sys;
+
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, &sys, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(exit_code);
+}
+
+int main(int argc, char **argv)
+{
+    int opt;
+
+    while ((opt = getopt(argc, argv, "h")) != -1) {
+        switch (opt) {
+        case 'h':
+            usage(0);
+            break;
+        default:
+            usage(1);
+        }
+    }
+
+    argv += optind;
+    argc -= optind;
+    if (argc <= 0)
+        usage(1);
+
+    gcov_init();
+
+    if ( strcmp(argv[0], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[0], "read") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 0);
+    else if ( strcmp(argv[0], "read-reset") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 1);
+    else
+        usage(1);
+
+    return 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 Thu Feb 21 16:16:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yp1-0007fE-2V; Thu, 21 Feb 2013 16:16:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yoz-0007eo-DT
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:33 +0000
Received: from [85.158.137.99:38122] by server-8.bemta-3.messagelabs.com id
	C8/E5-25687-06846215; Thu, 21 Feb 2013 16:16:32 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361463382!14179381!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13411 invoked from network); 21 Feb 2013 16:16:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345378"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-L3;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:44 +0000
Message-ID: <1361463225-21750-5-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 4/5] gcov: Add small utility to deal with
	test coverage information from 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

Currently the utility can read and reset coverage informations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore          |    1 +
 .hgignore           |    1 +
 tools/misc/Makefile |    8 ++-
 tools/misc/xencov.c |  152 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 160 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xencov.c

diff --git a/.gitignore b/.gitignore
index 96a7a5d..71786ca 100644
--- a/.gitignore
+++ b/.gitignore
@@ -229,6 +229,7 @@ tools/misc/gtraceview
 tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
+tools/misc/xencov
 tools/pygrub/build/*
 tools/python/build/*
 tools/python/xen/util/path.py
diff --git a/.hgignore b/.hgignore
index a4466d2..6b432f7 100644
--- a/.hgignore
+++ b/.hgignore
@@ -224,6 +224,7 @@
 ^tools/misc/gtraceview$
 ^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
+^tools/misc/xencov$
 ^tools/pygrub/build/.*$
 ^tools/python/build/.*$
 ^tools/python/xen/util/path\.py$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..eef9411 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xencov
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +22,8 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview \
+	gtracestat xenlockprof xenwatchdogd xen-ringwatch xencov
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 0000000..6645a30
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,152 @@
+/*
+ * xencov: handle test coverage information from Xen.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include <xenctrl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <errno.h>
+#include <err.h>
+#include <sys/mman.h>
+
+static xc_interface *gcov_xch = NULL;
+
+static void gcov_init(void)
+{
+    gcov_xch = xc_interface_open(NULL, NULL, 0);
+    if ( !gcov_xch )
+        err(1, "opening interface");
+}
+
+int gcov_get_info(int op, struct xen_sysctl *sys, void *ptr)
+{
+    struct xen_sysctl_coverage_op *cov;
+
+    memset(sys, 0, sizeof(*sys));
+    sys->cmd = XEN_SYSCTL_coverage_op;
+
+    cov = &sys->u.coverage_op;
+    cov->cmd = op;
+    cov->u.raw_info.p = ptr;
+
+    return xc_sysctl(gcov_xch, sys);
+}
+
+static void gcov_read(const char *fn, int reset)
+{
+    struct xen_sysctl sys;
+    unsigned page_size = sysconf(_SC_PAGESIZE);
+    uint32_t total_len;
+    uint8_t *p;
+    size_t size;
+    FILE *f;
+    int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
+                     XEN_SYSCTL_COVERAGE_read;
+
+    /* get total length */
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, &sys, NULL) < 0 )
+        err(1, "getting total length");
+    total_len = sys.u.coverage_op.u.total_size;
+    fprintf(stderr, "returned %u bytes\n", (unsigned) total_len);
+
+    /* safe check */
+    if ( total_len > 16u * 1024u * 1024u )
+        errx(1, "coverage size too big %u bytes\n", total_len);
+
+    /* allocate */
+    size = total_len + page_size;
+    size -= (size % page_size);
+    p = mmap(0, size, PROT_WRITE|PROT_READ,
+             MAP_PRIVATE|MAP_ANON|MAP_LOCKED, -1, 0);
+    if ( p == (uint8_t *) -1 )
+        err(1, "mapping memory for coverage");
+
+    /* get data */
+    memset(p, 0, total_len);
+    if ( gcov_get_info(op, &sys, p) < 0 )
+        err(1, "getting coverage information");
+
+    /* write to a file */
+    if ( strcmp(fn, "-") == 0 )
+        f = stdout;
+    else
+        f = fopen(fn, "w");
+    if ( !f )
+        err(1, "opening output file");
+    if ( fwrite(p, 1, total_len, f) != total_len )
+        err(1, "writing coverage to file");
+    if (f != stdout)
+        fclose(f);
+}
+
+static void gcov_reset(void)
+{
+    struct xen_sysctl sys;
+
+    if ( gcov_get_info(XEN_SYSCTL_COVERAGE_reset, &sys, NULL) < 0 )
+        err(1, "resetting coverage information");
+}
+
+static void usage(int exit_code)
+{
+    FILE *out = exit_code ? stderr : stdout;
+
+    fprintf(out, "xencov {reset|read|read-reset} [<filename>]\n"
+        "\treset       reset information\n"
+        "\tread        read information from xen to filename\n"
+        "\tread-reset  read and reset information from xen to filename\n"
+        "\tfilename  optional filename (default output)\n"
+        );
+    exit(exit_code);
+}
+
+int main(int argc, char **argv)
+{
+    int opt;
+
+    while ((opt = getopt(argc, argv, "h")) != -1) {
+        switch (opt) {
+        case 'h':
+            usage(0);
+            break;
+        default:
+            usage(1);
+        }
+    }
+
+    argv += optind;
+    argc -= optind;
+    if (argc <= 0)
+        usage(1);
+
+    gcov_init();
+
+    if ( strcmp(argv[0], "reset") == 0 )
+        gcov_reset();
+    else if ( strcmp(argv[0], "read") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 0);
+    else if ( strcmp(argv[0], "read-reset") == 0 )
+        gcov_read(argc > 1 ? argv[1] : "-", 1);
+    else
+        usage(1);
+
+    return 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 Thu Feb 21 16:16:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yox-0007ed-8v; Thu, 21 Feb 2013 16:16:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yov-0007eV-SR
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:30 +0000
Received: from [85.158.137.99:15344] by server-16.bemta-3.messagelabs.com id
	59/D0-02727-85846215; Thu, 21 Feb 2013 16:16:24 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361463382!12082882!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10068 invoked from network); 21 Feb 2013 16:16:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8777273"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-Gr;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:41 +0000
Message-ID: <1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5a86f90..a21ae41 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -442,6 +442,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 83335ad..a13b681 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1378,6 +1378,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 31e1117..74b34eb 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -127,4 +127,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 21 16:16:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yox-0007ed-8v; Thu, 21 Feb 2013 16:16:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yov-0007eV-SR
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:30 +0000
Received: from [85.158.137.99:15344] by server-16.bemta-3.messagelabs.com id
	59/D0-02727-85846215; Thu, 21 Feb 2013 16:16:24 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361463382!12082882!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10068 invoked from network); 21 Feb 2013 16:16:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8777273"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-Gr;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:41 +0000
Message-ID: <1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 allow modules to set initializer functions.
This is used by Gcc instrumentation code for profiling arcs and test
coverage.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/arch/arm/setup.c   |    2 ++
 xen/arch/arm/xen.lds.S |    7 +++++++
 xen/arch/x86/setup.c   |    2 ++
 xen/arch/x86/xen.lds.S |    7 +++++++
 xen/common/lib.c       |   14 ++++++++++++++
 xen/include/xen/lib.h  |    2 ++
 6 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5a86f90..a21ae41 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -442,6 +442,8 @@ void __init start_xen(unsigned long boot_phys_offset,
        scrub_heap_pages();
     */
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 410d7db..50e0c4b 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -84,6 +84,13 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       . = ALIGN(4);
+       __CTOR_LIST__ = .;
+       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       *(.ctors)
+       LONG(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 83335ad..a13b681 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1378,6 +1378,8 @@ void __init __start_xen(unsigned long mbi_p)
 
     init_trace_bufs();
 
+    init_constructors();
+
     console_endboot();
 
     /* Hide UART from DOM0 if we're using it */
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d324afd..5570389 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -108,6 +108,13 @@ SECTIONS
        __trampoline_seg_start = .;
        *(.trampoline_seg)
        __trampoline_seg_stop = .;
+
+       . = ALIGN(8);
+       __CTOR_LIST__ = .;
+       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       *(.ctors)
+       QUAD(0)
+       __CTOR_END__ = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index 03c8b8b..1344038 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -2,6 +2,7 @@
 #include <xen/ctype.h>
 #include <xen/lib.h>
 #include <xen/types.h>
+#include <xen/init.h>
 #include <asm/byteorder.h>
 
 /* for ctype.h */
@@ -478,6 +479,19 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
+extern const struct
+{
+    unsigned long count;
+    void (*funcs[1])(void);
+} __CTOR_LIST__;
+
+void __init init_constructors(void)
+{
+    unsigned long n;
+    for ( n = 0; n < __CTOR_LIST__.count; ++n )
+        __CTOR_LIST__.funcs[n]();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 31e1117..74b34eb 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -127,4 +127,6 @@ extern void add_taint(unsigned);
 struct cpu_user_regs;
 void dump_execstate(struct cpu_user_regs *);
 
+void init_constructors(void);
+
 #endif /* __LIB_H__ */
-- 
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 Thu Feb 21 16:16:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yp0-0007f3-MC; Thu, 21 Feb 2013 16:16:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yoy-0007em-S6
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:33 +0000
Received: from [85.158.137.99:38027] by server-10.bemta-3.messagelabs.com id
	94/C8-10609-F5846215; Thu, 21 Feb 2013 16:16:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361463382!14179381!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13310 invoked from network); 21 Feb 2013 16:16:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345376"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-Le;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:45 +0000
Message-ID: <1361463225-21750-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 5/5] gcov: Add documentation for coverage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 docs/misc/coverage.markdown |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 docs/misc/coverage.markdown

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
new file mode 100644
index 0000000..74af665
--- /dev/null
+++ b/docs/misc/coverage.markdown
@@ -0,0 +1,39 @@
+# Coverage support for Xen
+
+Coverare support allow you to get coverage information from Xen execution.
+You can see how many times a line is executed.
+
+The compiler have specific options that enable the collection of these
+information. Every basic block in the code will be instructed by the compiler
+to compute these statistics. It should not be used in production as it slow
+down your hypervisor.
+
+## Enable coverage
+
+Test coverage support can be turned on compiling Xen with coverage option set
+to y.
+
+Something like:
+    cd xen
+    make coverage=y
+
+(or change your `Config.mk` file).
+
+## Extract coverage data
+
+The way GCC and other tools deal with coverage information is to use some files
+created during build phase (.gcno) and some files produced by executing the
+*program* (.gcda). The program in this case is Xen but Xen cannot write files
+so the way you can use coverage from Xen is extract coverage data from Xen and
+then split these information into files.
+
+To extract data you use a simple utility called `xencov`. Mainly `xencore`
+allow you to do 3 operations:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+Another utility (**TODO**) is used to split extracted data file into files
+needed by userspace tools.
+
-- 
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 Thu Feb 21 16:16:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Yp0-0007f3-MC; Thu, 21 Feb 2013 16:16:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yoy-0007em-S6
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:33 +0000
Received: from [85.158.137.99:38027] by server-10.bemta-3.messagelabs.com id
	94/C8-10609-F5846215; Thu, 21 Feb 2013 16:16:31 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361463382!14179381!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13310 invoked from network); 21 Feb 2013 16:16:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345376"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-Le;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:45 +0000
Message-ID: <1361463225-21750-6-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 5/5] gcov: Add documentation for coverage
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 docs/misc/coverage.markdown |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 docs/misc/coverage.markdown

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
new file mode 100644
index 0000000..74af665
--- /dev/null
+++ b/docs/misc/coverage.markdown
@@ -0,0 +1,39 @@
+# Coverage support for Xen
+
+Coverare support allow you to get coverage information from Xen execution.
+You can see how many times a line is executed.
+
+The compiler have specific options that enable the collection of these
+information. Every basic block in the code will be instructed by the compiler
+to compute these statistics. It should not be used in production as it slow
+down your hypervisor.
+
+## Enable coverage
+
+Test coverage support can be turned on compiling Xen with coverage option set
+to y.
+
+Something like:
+    cd xen
+    make coverage=y
+
+(or change your `Config.mk` file).
+
+## Extract coverage data
+
+The way GCC and other tools deal with coverage information is to use some files
+created during build phase (.gcno) and some files produced by executing the
+*program* (.gcda). The program in this case is Xen but Xen cannot write files
+so the way you can use coverage from Xen is extract coverage data from Xen and
+then split these information into files.
+
+To extract data you use a simple utility called `xencov`. Mainly `xencore`
+allow you to do 3 operations:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+Another utility (**TODO**) is used to split extracted data file into files
+needed by userspace tools.
+
-- 
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 Thu Feb 21 16:16:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:16: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 1U8Yp9-0007hK-HJ; Thu, 21 Feb 2013 16:16:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yp7-0007gR-QJ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:42 +0000
Received: from [85.158.137.99:50017] by server-13.bemta-3.messagelabs.com id
	F6/18-20653-46846215; Thu, 21 Feb 2013 16:16:36 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361463382!14179381!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13550 invoked from network); 21 Feb 2013 16:16:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345379"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-KG;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:43 +0000
Message-ID: <1361463225-21750-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 3/5] gcov: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  153 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c         |    6 ++
 xen/include/public/gcov.h   |  115 ++++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |    9 +++
 5 files changed, 321 insertions(+)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 4de4b58..01d5b10 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,6 +19,9 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
 
@@ -61,6 +64,156 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    int ret = -EINVAL;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        op->u.total_size = iter.write_offset;
+        ret = 0;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if ( ret || op->cmd != XEN_SYSCTL_COVERAGE_read_and_reset )
+            break;
+
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 20bb864..182cb23 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -357,6 +358,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
     }
     break;
 
+#ifdef TEST_COVERAGE
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+#endif
 
     default:
         ret = arch_do_sysctl(op, u_sysctl);
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..1b29b48
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..84baae4 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        uint32_t total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..27c5c37 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,11 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 21 16:16:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:16: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 1U8Yp9-0007hK-HJ; Thu, 21 Feb 2013 16:16:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8Yp7-0007gR-QJ
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:42 +0000
Received: from [85.158.137.99:50017] by server-13.bemta-3.messagelabs.com id
	F6/18-20653-46846215; Thu, 21 Feb 2013 16:16:36 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361463382!14179381!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13550 invoked from network); 21 Feb 2013 16:16:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345379"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-KG;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:43 +0000
Message-ID: <1361463225-21750-4-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 3/5] gcov: Implement code to read coverage
	informations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Operations are handled by a sysctl specific operation.

Implement 4 operations
- check if coverage is compiled in
- read size of coverage information
- read coverage information
- reset coverage counters

Information are stored in a single blob in a format specific to Xen designed
to make code that generate coverage as small as possible.

This patch add a public header with the structure of blob exported by Xen.
This avoid problems distributing header which is GPL2.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 xen/common/gcov/gcov.c      |  153 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c         |    6 ++
 xen/include/public/gcov.h   |  115 ++++++++++++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 +++++++++++
 xen/include/xen/gcov.h      |    9 +++
 5 files changed, 321 insertions(+)
 create mode 100644 xen/include/public/gcov.h

diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
index 4de4b58..01d5b10 100644
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -19,6 +19,9 @@
 #include <xen/hypercall.h>
 #include <xen/gcov.h>
 #include <xen/errno.h>
+#include <xen/guest_access.h>
+#include <public/xen.h>
+#include <public/gcov.h>
 
 static struct gcov_info *info_list;
 
@@ -61,6 +64,156 @@ void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
     /* Unused. */
 }
 
+static inline int counter_active(const struct gcov_info *info, unsigned int type)
+{
+    return (1 << type) & info->ctr_mask;
+}
+
+typedef struct write_iter_t
+{
+    XEN_GUEST_HANDLE(uint8) ptr;
+    int real;
+    uint32_t write_offset;
+} write_iter_t;
+
+static int write_raw(struct write_iter_t *iter, const void *data,
+                     size_t data_len)
+{
+    if ( iter->real &&
+        copy_to_guest_offset(iter->ptr, iter->write_offset,
+                             (const unsigned char *) data, data_len) )
+        return -EFAULT;
+
+    iter->write_offset += data_len;
+    return 0;
+}
+
+#define chk(v) do { ret=(v); if ( ret ) return ret; } while(0)
+
+static inline int write32(write_iter_t *iter, uint32_t val)
+{
+    return write_raw(iter, &val, sizeof(val));
+}
+
+static int write_string(write_iter_t *iter, const char *s)
+{
+    int ret;
+    size_t len = strlen(s);
+
+    chk(write32(iter, len));
+    return write_raw(iter, s, len);
+}
+
+static inline int next_type(const struct gcov_info *info, int *type)
+{
+    while ( ++*type < XENCOV_COUNTERS && !counter_active(info, *type) )
+        continue;
+    return *type;
+}
+
+static inline void align_iter(write_iter_t *iter)
+{
+    iter->write_offset =
+        (iter->write_offset + sizeof(uint64_t) - 1) & -sizeof(uint64_t);
+}
+
+static int write_gcov(write_iter_t *iter)
+{
+    struct gcov_info *info;
+    int ret;
+
+    /* reset offset */
+    iter->write_offset = 0;
+
+    /* dump all files */
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+        size_t size_fn = sizeof(struct gcov_fn_info);
+
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FILE));
+        chk(write32(iter, info->version));
+        chk(write32(iter, info->stamp));
+        chk(write_string(iter, info->filename));
+
+        /* dump counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+        {
+            align_iter(iter);
+            chk(write32(iter, XENCOV_TAG_COUNTER(type)));
+            chk(write32(iter, ctr->num));
+            chk(write_raw(iter, ctr->values,
+                          ctr->num * sizeof(ctr->values[0])));
+
+            size_fn += sizeof(unsigned);
+        }
+
+        /* dump all functions together */
+        align_iter(iter);
+        chk(write32(iter, XENCOV_TAG_FUNC));
+        chk(write32(iter, info->n_functions));
+        chk(write_raw(iter, info->functions, info->n_functions * size_fn));
+    }
+
+    /* stop tag */
+    align_iter(iter);
+    chk(write32(iter, XENCOV_TAG_END));
+    return 0;
+}
+
+static int reset_counters(void)
+{
+    struct gcov_info *info;
+
+    for ( info = info_list ; info; info = info->next )
+    {
+        const struct gcov_ctr_info *ctr;
+        int type;
+
+        /* reset counters */
+        ctr = info->counts;
+        for ( type = -1; next_type(info, &type) < XENCOV_COUNTERS; ++ctr )
+            memset(ctr->values, 0, ctr->num * sizeof(ctr->values[0]));
+    }
+
+    return 0;
+}
+
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op)
+{
+    int ret = -EINVAL;
+    write_iter_t iter;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_COVERAGE_get_total_size:
+        iter.real = 0;
+
+        write_gcov(&iter);
+        op->u.total_size = iter.write_offset;
+        ret = 0;
+        break;
+
+    case XEN_SYSCTL_COVERAGE_read_and_reset:
+    case XEN_SYSCTL_COVERAGE_read:
+        iter.ptr = op->u.raw_info;
+        iter.real = 1;
+
+        ret = write_gcov(&iter);
+        if ( ret || op->cmd != XEN_SYSCTL_COVERAGE_read_and_reset )
+            break;
+
+        /* fall through */
+    case XEN_SYSCTL_COVERAGE_reset:
+        ret = reset_counters();
+        break;
+    }
+    return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 20bb864..182cb23 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -26,6 +26,7 @@
 #include <xen/nodemask.h>
 #include <xsm/xsm.h>
 #include <xen/pmstat.h>
+#include <xen/gcov.h>
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -357,6 +358,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
     }
     break;
 
+#ifdef TEST_COVERAGE
+    case XEN_SYSCTL_coverage_op:
+        ret = sysctl_coverage_op(&op->u.coverage_op);
+        break;
+#endif
 
     default:
         ret = arch_do_sysctl(op, u_sysctl);
diff --git a/xen/include/public/gcov.h b/xen/include/public/gcov.h
new file mode 100644
index 0000000..1b29b48
--- /dev/null
+++ b/xen/include/public/gcov.h
@@ -0,0 +1,115 @@
+/******************************************************************************
+ * gcov.h
+ *
+ * Coverage structures exported by Xen.
+ * Structure is different from Gcc one.
+ *
+ * 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.
+ *
+ * Copyright (c) 2013, Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_PUBLIC_GCOV_H__
+#define __XEN_PUBLIC_GCOV_H__ __XEN_PUBLIC_GCOV_H__
+
+#define XENCOV_COUNTERS         5
+#define XENCOV_TAG_BASE         0x58544300u
+#define XENCOV_TAG_FILE         (XENCOV_TAG_BASE+0x46u)
+#define XENCOV_TAG_FUNC         (XENCOV_TAG_BASE+0x66u)
+#define XENCOV_TAG_COUNTER(n)   (XENCOV_TAG_BASE+0x30u+((n)&0xfu))
+#define XENCOV_TAG_END          (XENCOV_TAG_BASE+0x2eu)
+#define XENCOV_IS_TAG_COUNTER(n) \
+    ((n) >= XENCOV_TAG_COUNTER(0) && (n) < XENCOV_TAG_COUNTER(XENCOV_COUNTERS))
+#define XENCOV_COUNTER_NUM(n) ((n)-XENCOV_TAG_COUNTER(0))
+
+/*
+ * The main structure for the blob is
+ * BLOB := FILE.. END
+ * FILE := TAG_FILE VERSION STAMP FILENAME COUNTERS FUNCTIONS
+ * FILENAME := LEN characters
+ *   characters are padded to 32 bit
+ * LEN := 32 bit value
+ * COUNTERS := TAG_COUNTER(n) NUM COUNTER..
+ * NUM := 32 bit valie
+ * COUNTER := 64 bit value
+ * FUNCTIONS := TAG_FUNC NUM FUNCTION..
+ * FUNCTION := IDENT CHECKSUM NUM_COUNTERS
+ *
+ * All tagged structures are aligned to 8 bytes
+ */
+
+/**
+ * File information
+ * Prefixed with XENCOV_TAG_FILE and a string with filename
+ * Aligned to 8 bytes
+ */
+struct xencov_file
+{
+    uint32_t tag; /* XENCOV_TAG_FILE */
+    uint32_t version;
+    uint32_t stamp;
+    uint32_t fn_len;
+    char filename[1];
+};
+
+
+/**
+ * Counters information
+ * Prefixed with XENCOV_TAG_COUNTER(n) where n is 0..(XENCOV_COUNTERS-1)
+ * Aligned to 8 bytes
+ */
+struct xencov_counter
+{
+    uint32_t tag; /* XENCOV_TAG_COUNTER(n) */
+    uint32_t num;
+    uint64_t values[1];
+};
+
+/**
+ * Information for each function
+ * Number of counter is equal to the number of counter structures got before
+ */
+struct xencov_function
+{
+    uint32_t ident;
+    uint32_t checksum;
+    uint32_t num_counters[1];
+};
+
+/**
+ * Information for all functions
+ * Aligned to 8 bytes
+ */
+struct xencov_functions
+{
+    uint32_t tag; /* XENCOV_TAG_FUNC */
+    uint32_t num;
+    struct xencov_function xencov_function[1];
+};
+
+/**
+ * Terminator
+ */
+struct xencov_end
+{
+    uint32_t tag; /* XENCOV_TAG_END */
+};
+
+#endif /* __XEN_PUBLIC_GCOV_H__ */
+
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 3225b2a..84baae4 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -596,6 +596,42 @@ struct xen_sysctl_scheduler_op {
 typedef struct xen_sysctl_scheduler_op xen_sysctl_scheduler_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_scheduler_op_t);
 
+/* XEN_SYSCTL_coverage_op */
+/*
+ * Get total size of information, to help allocate
+ * the buffer. The pointer points to a 32 bit value.
+ */
+#define XEN_SYSCTL_COVERAGE_get_total_size 0
+
+/*
+ * Read coverage information in a single run
+ * You must use a tool to split them.
+ */
+#define XEN_SYSCTL_COVERAGE_read           1
+
+/*
+ * Reset all the coverage counters to 0
+ * No parameters.
+ */
+#define XEN_SYSCTL_COVERAGE_reset          2
+
+/*
+ * Like XEN_SYSCTL_COVERAGE_read but reset also
+ * counters to 0 in a single call.
+ */
+#define XEN_SYSCTL_COVERAGE_read_and_reset 3
+
+struct xen_sysctl_coverage_op {
+    uint32_t cmd;        /* XEN_SYSCTL_COVERAGE_* */
+    union {
+        uint32_t total_size; /* OUT */
+        XEN_GUEST_HANDLE_64(uint8)  raw_info;   /* OUT */
+    } u;
+};
+typedef struct xen_sysctl_coverage_op xen_sysctl_coverage_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_coverage_op_t);
+
+
 struct xen_sysctl {
     uint32_t cmd;
 #define XEN_SYSCTL_readconsole                    1
@@ -616,6 +652,7 @@ struct xen_sysctl {
 #define XEN_SYSCTL_numainfo                      17
 #define XEN_SYSCTL_cpupool_op                    18
 #define XEN_SYSCTL_scheduler_op                  19
+#define XEN_SYSCTL_coverage_op                   20
     uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
     union {
         struct xen_sysctl_readconsole       readconsole;
@@ -636,6 +673,7 @@ struct xen_sysctl {
         struct xen_sysctl_lockprof_op       lockprof_op;
         struct xen_sysctl_cpupool_op        cpupool_op;
         struct xen_sysctl_scheduler_op      scheduler_op;
+        struct xen_sysctl_coverage_op       coverage_op;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
index d695919..27c5c37 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/gcov.h
@@ -14,6 +14,8 @@
 #ifndef __XEN_GCOV_H__
 #define __XEN_GCOV_H__ __XEN_GCOV_H__
 
+#include <public/sysctl.h>
+
 /*
  * Profiling data types used for gcc 3.4 and above - these are defined by
  * gcc and need to be kept as close to the original definition as possible to
@@ -81,4 +83,11 @@ struct gcov_info
 };
 
 
+/**
+ * Sysctl operations for coverage
+ */
+#ifdef TEST_COVERAGE
+int sysctl_coverage_op(xen_sysctl_coverage_op_t *op);
+#endif
+
 #endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 21 16:17:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8YpP-0007md-5J; Thu, 21 Feb 2013 16:16:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8YpN-0007lp-W9
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:58 +0000
Received: from [85.158.137.99:15483] by server-9.bemta-3.messagelabs.com id
	AF/CC-09484-A5846215; Thu, 21 Feb 2013 16:16:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361463382!12082882!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10110 invoked from network); 21 Feb 2013 16:16:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8777274"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-GL;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:40 +0000
Message-ID: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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

Updated set of patches for coverage.

Changes:
- remove small outdated note on commit text
- add signature where missing
- rebased

Frediano Ziglio (5):
  gcov: Call constructors during initialization
  gcov: Adding support for coverage information
  gcov: Implement code to read coverage informations
  gcov: Add small utility to deal with test coverage information from
    Xen
  gcov: Add documentation for coverage

 .gitignore                  |    3 +
 .hgignore                   |    3 +
 Config.mk                   |    3 +
 docs/misc/coverage.markdown |   39 ++++++++
 tools/misc/Makefile         |    8 +-
 tools/misc/xencov.c         |  152 +++++++++++++++++++++++++++++
 xen/Rules.mk                |    2 +
 xen/arch/arm/setup.c        |    2 +
 xen/arch/arm/xen.lds.S      |    7 ++
 xen/arch/x86/setup.c        |    2 +
 xen/arch/x86/xen.lds.S      |    7 ++
 xen/common/Makefile         |    2 +
 xen/common/gcov/Makefile    |    2 +
 xen/common/gcov/gcov.c      |  225 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/lib.c            |   14 +++
 xen/common/sysctl.c         |    6 ++
 xen/include/public/gcov.h   |  115 ++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 ++++++++
 xen/include/xen/gcov.h      |   93 ++++++++++++++++++
 xen/include/xen/lib.h       |    2 +
 20 files changed, 723 insertions(+), 2 deletions(-)
 create mode 100644 docs/misc/coverage.markdown
 create mode 100644 tools/misc/xencov.c
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/public/gcov.h
 create mode 100644 xen/include/xen/gcov.h

-- 
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 Thu Feb 21 16:17:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8YpP-0007md-5J; Thu, 21 Feb 2013 16:16:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8YpN-0007lp-W9
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:58 +0000
Received: from [85.158.137.99:15483] by server-9.bemta-3.messagelabs.com id
	AF/CC-09484-A5846215; Thu, 21 Feb 2013 16:16:26 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361463382!12082882!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10110 invoked from network); 21 Feb 2013 16:16:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:16:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8777274"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-GL;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:40 +0000
Message-ID: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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

Updated set of patches for coverage.

Changes:
- remove small outdated note on commit text
- add signature where missing
- rebased

Frediano Ziglio (5):
  gcov: Call constructors during initialization
  gcov: Adding support for coverage information
  gcov: Implement code to read coverage informations
  gcov: Add small utility to deal with test coverage information from
    Xen
  gcov: Add documentation for coverage

 .gitignore                  |    3 +
 .hgignore                   |    3 +
 Config.mk                   |    3 +
 docs/misc/coverage.markdown |   39 ++++++++
 tools/misc/Makefile         |    8 +-
 tools/misc/xencov.c         |  152 +++++++++++++++++++++++++++++
 xen/Rules.mk                |    2 +
 xen/arch/arm/setup.c        |    2 +
 xen/arch/arm/xen.lds.S      |    7 ++
 xen/arch/x86/setup.c        |    2 +
 xen/arch/x86/xen.lds.S      |    7 ++
 xen/common/Makefile         |    2 +
 xen/common/gcov/Makefile    |    2 +
 xen/common/gcov/gcov.c      |  225 +++++++++++++++++++++++++++++++++++++++++++
 xen/common/lib.c            |   14 +++
 xen/common/sysctl.c         |    6 ++
 xen/include/public/gcov.h   |  115 ++++++++++++++++++++++
 xen/include/public/sysctl.h |   38 ++++++++
 xen/include/xen/gcov.h      |   93 ++++++++++++++++++
 xen/include/xen/lib.h       |    2 +
 20 files changed, 723 insertions(+), 2 deletions(-)
 create mode 100644 docs/misc/coverage.markdown
 create mode 100644 tools/misc/xencov.c
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/public/gcov.h
 create mode 100644 xen/include/xen/gcov.h

-- 
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 Thu Feb 21 16:17:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8YpR-0007nO-JX; Thu, 21 Feb 2013 16:17:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8YpP-0007mc-ID
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:59 +0000
Received: from [85.158.139.83:54884] by server-13.bemta-5.messagelabs.com id
	9F/26-06769-A7846215; Thu, 21 Feb 2013 16:16:58 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361463385!21117810!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28463 invoked from network); 21 Feb 2013 16:16:27 -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;
	21 Feb 2013 16:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345377"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-Ia;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:42 +0000
Message-ID: <1361463225-21750-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 2/5] gcov: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 169 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 125a582..96a7a5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 74fd424..a4466d2 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 21274eb..281fc2b 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..4de4b58
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,72 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 21 16:17:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8YpR-0007nO-JX; Thu, 21 Feb 2013 16:17:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8YpP-0007mc-ID
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:16:59 +0000
Received: from [85.158.139.83:54884] by server-13.bemta-5.messagelabs.com id
	9F/26-06769-A7846215; Thu, 21 Feb 2013 16:16:58 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361463385!21117810!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28463 invoked from network); 21 Feb 2013 16:16:27 -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;
	21 Feb 2013 16:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8345377"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:16:21 -0500
Received: from [10.80.3.57] (helo=hamster.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<frediano.ziglio@citrix.com>)	id 1U8Yon-0008EU-Ia;
	Thu, 21 Feb 2013 16:16:21 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:13:42 +0000
Message-ID: <1361463225-21750-3-git-send-email-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v10 2/5] gcov: Adding support for coverage
	information
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 introduce coverage support to Xen.
Currently it allows to compile Xen with coverage support but there is no
way to extract them.

The declarations came from Linux source files (as you can see from file
headers).

The idea is to have some operations mainly
- get coverage information size
- read coverage information
- reset coverage counters

Linux use a file system to export these information. The information will
be a blob to handle with some tools (as usually tools require a bunch of
files but Xen does not handle files at all). I'll pack them to make things
simpler as possible.

These information cannot be put in a specific section (allowing a safe
mapping) as gcc use .rodata, .data, .text and .ctors sections.

I added code to handle constructors used in this case to initialize a
linked list of files.

I used a "coverage" configuration option to mimic the "debug" one.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 .gitignore               |    2 ++
 .hgignore                |    2 ++
 Config.mk                |    3 ++
 xen/Rules.mk             |    2 ++
 xen/common/Makefile      |    2 ++
 xen/common/gcov/Makefile |    2 ++
 xen/common/gcov/gcov.c   |   72 +++++++++++++++++++++++++++++++++++++++
 xen/include/xen/gcov.h   |   84 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 169 insertions(+)
 create mode 100644 xen/common/gcov/Makefile
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/.gitignore b/.gitignore
index 125a582..96a7a5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@
 *.tmp
 *.spot
 *.spit
+*.gcno
+*.gcda
 TAGS
 GTAGS
 GRTAGS
diff --git a/.hgignore b/.hgignore
index 74fd424..a4466d2 100644
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,8 @@
 .*\.rej$
 .*\.spot$
 .*\.spit$
+.*\.gcno$
+.*\.gcda$
 .*/a\.out$
 .*/Modules\.symvers$
 .*/cscope\..*$
diff --git a/Config.mk b/Config.mk
index 21274eb..281fc2b 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,6 +13,9 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 debug_symbols ?= $(debug)
 
+# Test coverage support
+coverage ?= n
+
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
                          -e s/armv7.*/arm32/)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2db449..3f0b262 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -103,6 +103,8 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y)): CFLAGS += -DINIT_SECTIONS_ONLY
 
+$(obj-$(coverage)): CFLAGS += -fprofile-arcs -ftest-coverage -DTEST_COVERAGE
+
 ifeq ($(lto),y)
 # Would like to handle all object files as bitcode, but objects made from
 # pure asm are in a different format and have to be collected separately.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..8a0c506 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,5 +59,7 @@ subdir-$(CONFIG_COMPAT) += compat
 
 subdir-$(x86_64) += hvm
 
+subdir-$(coverage) += gcov
+
 subdir-y += libelf
 subdir-$(HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
new file mode 100644
index 0000000..c9efe6c
--- /dev/null
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,2 @@
+obj-y += gcov.o
+
diff --git a/xen/common/gcov/gcov.c b/xen/common/gcov/gcov.c
new file mode 100644
index 0000000..4de4b58
--- /dev/null
+++ b/xen/common/gcov/gcov.c
@@ -0,0 +1,72 @@
+/*
+ *  This code maintains a list of active profiling data structures.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ *    Based on the gcov-kernel patch by:
+ *       Hubertus Franke <frankeh@us.ibm.com>
+ *       Nigel Hinds <nhinds@us.ibm.com>
+ *       Rajan Ravindran <rajancr@us.ibm.com>
+ *       Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *       Paul Larson
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/hypercall.h>
+#include <xen/gcov.h>
+#include <xen/errno.h>
+
+static struct gcov_info *info_list;
+
+/*
+ * __gcov_init is called by gcc-generated constructor code for each object
+ * file compiled with -fprofile-arcs.
+ *
+ * Although this function is called only during initialization is called from
+ * a .text section which is still present after initialization so not declare
+ * as __init.
+ */
+void __gcov_init(struct gcov_info *info)
+{
+    /* add new profiling data structure to list */
+    info->next = info_list;
+    info_list = info;
+}
+
+/*
+ * These functions may be referenced by gcc-generated profiling code but serve
+ * no function for Xen.
+ */
+void __gcov_flush(void)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_add(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_single(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+void __gcov_merge_delta(gcov_type *counters, unsigned int n_counters)
+{
+    /* Unused. */
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/gcov.h
new file mode 100644
index 0000000..d695919
--- /dev/null
+++ b/xen/include/xen/gcov.h
@@ -0,0 +1,84 @@
+/*
+ *  Profiling infrastructure declarations.
+ *
+ *  This file is based on gcc-internal definitions. Data structures are
+ *  defined to be compatible with gcc counterparts. For a better
+ *  understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *    Copyright IBM Corp. 2009
+ *    Author(s): Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ *
+ *    Uses gcc-internal data definitions.
+ */
+
+#ifndef __XEN_GCOV_H__
+#define __XEN_GCOV_H__ __XEN_GCOV_H__
+
+/*
+ * Profiling data types used for gcc 3.4 and above - these are defined by
+ * gcc and need to be kept as close to the original definition as possible to
+ * remain compatible.
+ */
+
+typedef uint64_t gcov_type;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+    unsigned int ident;
+    unsigned int checksum;
+    unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+    unsigned int num;
+    gcov_type *values;
+    void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked list
+ * @stamp: time stamp
+ * @filename: name of the associated gcov data file
+ * @n_functions: number of instrumented functions
+ * @functions: function data
+ * @ctr_mask: mask specifying which counter types are active
+ * @counts: counter data per counter type
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the next pointer.
+ */
+struct gcov_info
+{
+    unsigned int              version;
+    struct gcov_info          *next;
+    unsigned int              stamp;
+    const char                *filename;
+    unsigned int              n_functions;
+    const struct gcov_fn_info *functions;
+    unsigned int              ctr_mask;
+    struct gcov_ctr_info      counts[0];
+};
+
+
+#endif /* __XEN_GCOV_H__ */
-- 
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 Thu Feb 21 16:24:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:24: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 1U8Ywa-0000RD-IC; Thu, 21 Feb 2013 16:24:24 +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 1U8YwY-0000R7-KC
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:24:23 +0000
Received: from [85.158.137.99:38759] by server-5.bemta-3.messagelabs.com id
	0C/43-04457-53A46215; Thu, 21 Feb 2013 16:24:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361463813!17336493!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20816 invoked from network); 21 Feb 2013 16:23:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:23:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8347899"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:23:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:23:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8Yvk-0008LM-CP;
	Thu, 21 Feb 2013 16:23:32 +0000
Date: Thu, 21 Feb 2013 16:23:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361462485.26546.74.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
	<1361462485.26546.74.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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 V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 21 Feb 2013, Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Acked-by: Tim Deegan <tim@xen.org>
> > but:
> >         This is mostly a matter of coding taste, so I'd like Stefano's
> >         ack/nack here as well.
> 
> Stefano, any strong opinion?

Are there any concrete benefits in introducing register_t compared to
using unsigned long?


> >  xen/arch/arm/domain_build.c |    2 +-
> >  xen/arch/arm/smpboot.c      |    2 +-
> >  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
> >  xen/arch/arm/vgic.c         |   18 ++++++++--------
> >  xen/arch/arm/vpl011.c       |    6 ++--
> >  xen/arch/arm/vtimer.c       |    6 ++--
> >  xen/include/asm-arm/regs.h  |    2 +-
> >  xen/include/asm-arm/types.h |    4 +++
> >  8 files changed, 45 insertions(+), 39 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 7403f1a..30d014a 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> >
> >  static void dtb_load(struct kernel_info *kinfo)
> >  {
> > -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> > +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> >
> >      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
> >      xfree(kinfo->fdt);
> > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > index 86379b7..d8eb5d3 100644
> > --- a/xen/arch/arm/smpboot.c
> > +++ b/xen/arch/arm/smpboot.c
> > @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
> >      set_processor_id(cpuid);
> >
> >      /* Setup Hyp vector base */
> > -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> > +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> >
> >      mmu_init_secondary_cpu();
> >      enable_vfp();
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index eaf1f52..0299b33 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -68,7 +68,7 @@ static void print_xen_info(void)
> >             debug_build() ? 'y' : 'n', print_tainted(taint_str));
> >  }
> >
> > -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> >  {
> >      BUG_ON( !guest_mode(regs) );
> >
> > @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> >
> >      switch ( reg ) {
> >      case 0 ... 7: /* Unbanked registers */
> > -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> > +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
> >          return &regs->r0 + reg;
> >      case 8 ... 12: /* Register banked in FIQ mode */
> > -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> > +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
> >          if ( fiq_mode(regs) )
> >              return &regs->r8_fiq + reg - 8;
> >          else
> >              return &regs->r8 + reg - 8;
> >      case 13 ... 14: /* Banked SP + LR registers */
> > -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> > -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> > -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> > -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> > -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> > +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> > +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> > +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> > +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> > +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
> >          switch ( regs->cpsr & PSR_MODE_MASK )
> >          {
> >          case PSR_MODE_USR:
> > @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
> >      printk("GUEST STACK GOES HERE\n");
> >  }
> >
> > -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> > +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> >
> >  static void show_trace(struct cpu_user_regs *regs)
> >  {
> > -    uint32_t *frame, next, addr, low, high;
> > +    register_t *frame, next, addr, low, high;
> >
> >      printk("Xen call trace:\n   ");
> >
> > @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >      print_symbol(" %s\n   ", regs->pc);
> >
> >      /* Bounds for range of valid frame pointer. */
> > -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> >      high = (low & ~(STACK_SIZE - 1)) +
> >          (STACK_SIZE - sizeof(struct cpu_info));
> >
> > @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >              break;
> >          {
> >              /* Ordinary stack frame. */
> > -            frame = (uint32_t *)next;
> > +            frame = (register_t *)next;
> >              next  = frame[-1];
> >              addr  = frame[0];
> >          }
> > @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >          printk("[<%p>]", _p(addr));
> >          print_symbol(" %s\n   ", addr);
> >
> > -        low = (uint32_t)&frame[1];
> > +        low = (register_t)&frame[1];
> >      }
> >
> >      printk("\n");
> > @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >
> >  void show_stack(struct cpu_user_regs *regs)
> >  {
> > -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> >      int i;
> >
> >      if ( guest_mode(regs) )
> > @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> >
> >  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> >  {
> > -    uint32_t reg, *r;
> > +    register_t *r;
> > +    uint32_t reg;
> >      uint32_t domid = current->domain->domain_id;
> >      switch ( code ) {
> >      case 0xe0 ... 0xef:
> >          reg = code - 0xe0;
> >          r = select_user_reg(regs, reg);
> > -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> > +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> >                 domid, reg, *r, regs->pc);
> >          break;
> >      case 0xfd:
> > -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> > +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
> >          break;
> >      case 0xfe:
> > -        printk("%c", (char)(regs->r0 & 0xff));
> > +        r = select_user_reg(regs, 0);
> > +        printk("%c", (char)(*r & 0xff));
> >          break;
> >      case 0xff:
> >          printk("DOM%d: DEBUG\n", domid);
> > @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> >                         union hsr hsr)
> >  {
> >      struct hsr_cp32 cp32 = hsr.cp32;
> > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> >
> >      if ( !cp32.ccvalid ) {
> >          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> > @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> >          BUG_ON(!vtimer_emulate(regs, hsr));
> >          break;
> >      default:
> > -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> > +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
> >                 cp32.read ? "mrc" : "mcr",
> >                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
> >          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> > @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> >          BUG_ON(!vtimer_emulate(regs, hsr));
> >          break;
> >      default:
> > -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> > +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> >                 cp64.read ? "mrrc" : "mcrr",
> >                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
> >          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 39b9775..57147d5 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      struct vgic_irq_rank *rank;
> >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> >      int gicd_reg = REG(offset);
> > @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      struct vgic_irq_rank *rank;
> >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> >      int gicd_reg = REG(offset);
> > @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >
> >      case GICD_ISPENDR ... GICD_ISPENDRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
> >          return 0;
> >
> >      case GICD_ICPENDR ... GICD_ICPENDRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
> >          return 0;
> >
> > @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >
> >      case GICD_SGIR:
> >          if ( dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> > +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
> >                 *r, gicd_reg - GICD_ICFGR);
> >          return 0;
> >
> >      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
> >          return 0;
> >
> >      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
> >          return 0;
> >
> > @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >          goto write_ignore;
> >
> >      default:
> > -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
> >                 dabt.reg, *r, offset);
> >          return 0;
> >      }
> >
> >  bad_width:
> > -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> > +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> >             dabt.size, dabt.reg, *r, offset);
> >      domain_crash_synchronous();
> >      return 0;
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 7dcee90..db5094e 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      int offset = (int)(info->gpa - UART0_START);
> >
> >      switch ( offset )
> > @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      int offset = (int)(info->gpa - UART0_START);
> >
> >      switch ( offset )
> > @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> >          /* Silently ignore */
> >          return 1;
> >      default:
> > -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
> >                 dabt.reg, *r, offset);
> >          domain_crash_synchronous();
> >      }
> > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > index 85201b5..291b87e 100644
> > --- a/xen/arch/arm/vtimer.c
> > +++ b/xen/arch/arm/vtimer.c
> > @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >  {
> >      struct vcpu *v = current;
> >      struct hsr_cp32 cp32 = hsr.cp32;
> > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
> >      s_time_t now;
> >
> >      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
> >  {
> >      struct vcpu *v = current;
> >      struct hsr_cp64 cp64 = hsr.cp64;
> > -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> > -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> > +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> > +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
> >      uint64_t ticks;
> >      s_time_t now;
> >
> > diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> > index 7486944..a723f92 100644
> > --- a/xen/include/asm-arm/regs.h
> > +++ b/xen/include/asm-arm/regs.h
> > @@ -34,7 +34,7 @@
> >   * Returns a pointer to the given register value in regs, taking the
> >   * processor mode (CPSR) into account.
> >   */
> > -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> >
> >  #endif /* __ARM_REGS_H__ */
> >  /*
> > diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> > index d3e16d8..9ca32f1 100644
> > --- a/xen/include/asm-arm/types.h
> > +++ b/xen/include/asm-arm/types.h
> > @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
> >  typedef u64 paddr_t;
> >  #define INVALID_PADDR (~0ULL)
> >  #define PRIpaddr "016llx"
> > +typedef u32 register_t;
> > +#define PRIregister "x"
> >  #elif defined (CONFIG_ARM_64)
> >  typedef signed long s64;
> >  typedef unsigned long u64;
> > @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
> >  typedef u64 paddr_t;
> >  #define INVALID_PADDR (~0UL)
> >  #define PRIpaddr "016lx"
> > +typedef u64 register_t;
> > +#define PRIregister "lx"
> >  #endif
> >
> >  typedef unsigned long size_t;
> > --
> > 1.7.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 Feb 21 16:24:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:24: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 1U8Ywa-0000RD-IC; Thu, 21 Feb 2013 16:24:24 +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 1U8YwY-0000R7-KC
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:24:23 +0000
Received: from [85.158.137.99:38759] by server-5.bemta-3.messagelabs.com id
	0C/43-04457-53A46215; Thu, 21 Feb 2013 16:24:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361463813!17336493!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20816 invoked from network); 21 Feb 2013 16:23:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:23:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8347899"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:23:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:23:32 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8Yvk-0008LM-CP;
	Thu, 21 Feb 2013 16:23:32 +0000
Date: Thu, 21 Feb 2013 16:23:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361462485.26546.74.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
	<1361462485.26546.74.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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 V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 21 Feb 2013, Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Acked-by: Tim Deegan <tim@xen.org>
> > but:
> >         This is mostly a matter of coding taste, so I'd like Stefano's
> >         ack/nack here as well.
> 
> Stefano, any strong opinion?

Are there any concrete benefits in introducing register_t compared to
using unsigned long?


> >  xen/arch/arm/domain_build.c |    2 +-
> >  xen/arch/arm/smpboot.c      |    2 +-
> >  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
> >  xen/arch/arm/vgic.c         |   18 ++++++++--------
> >  xen/arch/arm/vpl011.c       |    6 ++--
> >  xen/arch/arm/vtimer.c       |    6 ++--
> >  xen/include/asm-arm/regs.h  |    2 +-
> >  xen/include/asm-arm/types.h |    4 +++
> >  8 files changed, 45 insertions(+), 39 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 7403f1a..30d014a 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> >
> >  static void dtb_load(struct kernel_info *kinfo)
> >  {
> > -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> > +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> >
> >      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
> >      xfree(kinfo->fdt);
> > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > index 86379b7..d8eb5d3 100644
> > --- a/xen/arch/arm/smpboot.c
> > +++ b/xen/arch/arm/smpboot.c
> > @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
> >      set_processor_id(cpuid);
> >
> >      /* Setup Hyp vector base */
> > -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> > +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> >
> >      mmu_init_secondary_cpu();
> >      enable_vfp();
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index eaf1f52..0299b33 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -68,7 +68,7 @@ static void print_xen_info(void)
> >             debug_build() ? 'y' : 'n', print_tainted(taint_str));
> >  }
> >
> > -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> >  {
> >      BUG_ON( !guest_mode(regs) );
> >
> > @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> >
> >      switch ( reg ) {
> >      case 0 ... 7: /* Unbanked registers */
> > -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> > +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
> >          return &regs->r0 + reg;
> >      case 8 ... 12: /* Register banked in FIQ mode */
> > -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> > +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
> >          if ( fiq_mode(regs) )
> >              return &regs->r8_fiq + reg - 8;
> >          else
> >              return &regs->r8 + reg - 8;
> >      case 13 ... 14: /* Banked SP + LR registers */
> > -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> > -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> > -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> > -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> > -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> > +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> > +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> > +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> > +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> > +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
> >          switch ( regs->cpsr & PSR_MODE_MASK )
> >          {
> >          case PSR_MODE_USR:
> > @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
> >      printk("GUEST STACK GOES HERE\n");
> >  }
> >
> > -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> > +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> >
> >  static void show_trace(struct cpu_user_regs *regs)
> >  {
> > -    uint32_t *frame, next, addr, low, high;
> > +    register_t *frame, next, addr, low, high;
> >
> >      printk("Xen call trace:\n   ");
> >
> > @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >      print_symbol(" %s\n   ", regs->pc);
> >
> >      /* Bounds for range of valid frame pointer. */
> > -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> >      high = (low & ~(STACK_SIZE - 1)) +
> >          (STACK_SIZE - sizeof(struct cpu_info));
> >
> > @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >              break;
> >          {
> >              /* Ordinary stack frame. */
> > -            frame = (uint32_t *)next;
> > +            frame = (register_t *)next;
> >              next  = frame[-1];
> >              addr  = frame[0];
> >          }
> > @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >          printk("[<%p>]", _p(addr));
> >          print_symbol(" %s\n   ", addr);
> >
> > -        low = (uint32_t)&frame[1];
> > +        low = (register_t)&frame[1];
> >      }
> >
> >      printk("\n");
> > @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> >
> >  void show_stack(struct cpu_user_regs *regs)
> >  {
> > -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> >      int i;
> >
> >      if ( guest_mode(regs) )
> > @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> >
> >  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> >  {
> > -    uint32_t reg, *r;
> > +    register_t *r;
> > +    uint32_t reg;
> >      uint32_t domid = current->domain->domain_id;
> >      switch ( code ) {
> >      case 0xe0 ... 0xef:
> >          reg = code - 0xe0;
> >          r = select_user_reg(regs, reg);
> > -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> > +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> >                 domid, reg, *r, regs->pc);
> >          break;
> >      case 0xfd:
> > -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> > +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
> >          break;
> >      case 0xfe:
> > -        printk("%c", (char)(regs->r0 & 0xff));
> > +        r = select_user_reg(regs, 0);
> > +        printk("%c", (char)(*r & 0xff));
> >          break;
> >      case 0xff:
> >          printk("DOM%d: DEBUG\n", domid);
> > @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> >                         union hsr hsr)
> >  {
> >      struct hsr_cp32 cp32 = hsr.cp32;
> > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> >
> >      if ( !cp32.ccvalid ) {
> >          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> > @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> >          BUG_ON(!vtimer_emulate(regs, hsr));
> >          break;
> >      default:
> > -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> > +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
> >                 cp32.read ? "mrc" : "mcr",
> >                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
> >          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> > @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> >          BUG_ON(!vtimer_emulate(regs, hsr));
> >          break;
> >      default:
> > -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> > +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> >                 cp64.read ? "mrrc" : "mcrr",
> >                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
> >          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 39b9775..57147d5 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      struct vgic_irq_rank *rank;
> >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> >      int gicd_reg = REG(offset);
> > @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      struct vgic_irq_rank *rank;
> >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> >      int gicd_reg = REG(offset);
> > @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >
> >      case GICD_ISPENDR ... GICD_ISPENDRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
> >          return 0;
> >
> >      case GICD_ICPENDR ... GICD_ICPENDRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
> >          return 0;
> >
> > @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >
> >      case GICD_SGIR:
> >          if ( dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> > +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
> >                 *r, gicd_reg - GICD_ICFGR);
> >          return 0;
> >
> >      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
> >          return 0;
> >
> >      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
> >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
> >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
> >          return 0;
> >
> > @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> >          goto write_ignore;
> >
> >      default:
> > -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
> >                 dabt.reg, *r, offset);
> >          return 0;
> >      }
> >
> >  bad_width:
> > -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> > +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> >             dabt.size, dabt.reg, *r, offset);
> >      domain_crash_synchronous();
> >      return 0;
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 7dcee90..db5094e 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      int offset = (int)(info->gpa - UART0_START);
> >
> >      switch ( offset )
> > @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> >  {
> >      struct hsr_dabt dabt = info->dabt;
> >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > +    register_t *r = select_user_reg(regs, dabt.reg);
> >      int offset = (int)(info->gpa - UART0_START);
> >
> >      switch ( offset )
> > @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> >          /* Silently ignore */
> >          return 1;
> >      default:
> > -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
> >                 dabt.reg, *r, offset);
> >          domain_crash_synchronous();
> >      }
> > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > index 85201b5..291b87e 100644
> > --- a/xen/arch/arm/vtimer.c
> > +++ b/xen/arch/arm/vtimer.c
> > @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> >  {
> >      struct vcpu *v = current;
> >      struct hsr_cp32 cp32 = hsr.cp32;
> > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
> >      s_time_t now;
> >
> >      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
> >  {
> >      struct vcpu *v = current;
> >      struct hsr_cp64 cp64 = hsr.cp64;
> > -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> > -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> > +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> > +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
> >      uint64_t ticks;
> >      s_time_t now;
> >
> > diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> > index 7486944..a723f92 100644
> > --- a/xen/include/asm-arm/regs.h
> > +++ b/xen/include/asm-arm/regs.h
> > @@ -34,7 +34,7 @@
> >   * Returns a pointer to the given register value in regs, taking the
> >   * processor mode (CPSR) into account.
> >   */
> > -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> >
> >  #endif /* __ARM_REGS_H__ */
> >  /*
> > diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> > index d3e16d8..9ca32f1 100644
> > --- a/xen/include/asm-arm/types.h
> > +++ b/xen/include/asm-arm/types.h
> > @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
> >  typedef u64 paddr_t;
> >  #define INVALID_PADDR (~0ULL)
> >  #define PRIpaddr "016llx"
> > +typedef u32 register_t;
> > +#define PRIregister "x"
> >  #elif defined (CONFIG_ARM_64)
> >  typedef signed long s64;
> >  typedef unsigned long u64;
> > @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
> >  typedef u64 paddr_t;
> >  #define INVALID_PADDR (~0UL)
> >  #define PRIpaddr "016lx"
> > +typedef u64 register_t;
> > +#define PRIregister "lx"
> >  #endif
> >
> >  typedef unsigned long size_t;
> > --
> > 1.7.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 Feb 21 16:33:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Z5W-00015h-SX; Thu, 21 Feb 2013 16:33: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 1U8Z5V-00015c-KV
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:33:37 +0000
Received: from [85.158.139.83:17700] by server-5.bemta-5.messagelabs.com id
	18/5D-11945-06C46215; Thu, 21 Feb 2013 16:33:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361464414!28373830!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5544 invoked from network); 21 Feb 2013 16:33:35 -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;
	21 Feb 2013 16:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8350880"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:33:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:33:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8Z5N-0008U4-JW;
	Thu, 21 Feb 2013 16:33:29 +0000
Date: Thu, 21 Feb 2013 16:33:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360860480-9245-20-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302211632190.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-20-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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 V2 20/46] xen: arm64: add to foreign struct
	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>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  .gitignore                               |    1 +
>  tools/include/xen-foreign/Makefile       |    5 ++++-
>  tools/include/xen-foreign/mkheader.py    |   19 +++++++++++++++++++
>  tools/include/xen-foreign/reference.size |   20 ++++++++++----------
>  tools/include/xen-foreign/structs.py     |    1 +
>  5 files changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 73c5b77..2242344 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -364,6 +364,7 @@ tools/include/xen-foreign/structs.pyc
>  tools/include/xen-foreign/x86_32.h
>  tools/include/xen-foreign/x86_64.h
>  tools/include/xen-foreign/arm32.h
> +tools/include/xen-foreign/arm64.h
>  
>  .git
>  tools/misc/xen-hptool
> diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
> index 53cc6b4..06b844c 100644
> --- a/tools/include/xen-foreign/Makefile
> +++ b/tools/include/xen-foreign/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  
>  ROOT = $(XEN_ROOT)/xen/include/public
>  
> -architectures := arm32 x86_32 x86_64
> +architectures := arm32 arm64 x86_32 x86_64
>  headers := $(patsubst %, %.h, $(architectures))
>  
>  .PHONY: all clean check-headers
> @@ -25,6 +25,9 @@ check-headers: checker
>  arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
>  	$(PYTHON) $< $* $@ $(filter %.h,$^)
>  
> +arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
> +	$(PYTHON) $< $* $@ $(filter %.h,$^)
> +
>  x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
>  	$(PYTHON) $< $* $@ $(filter %.h,$^)
>  
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index b7c34b1..4858687 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -26,6 +26,22 @@ inttypes["arm32"] = {
>  header["arm32"] = """
>  #define __arm___ARM32 1
>  """;
> +footer["arm32"] = """
> +#undef __DECL_REG
> +"""
> +
> +inttypes["arm64"] = {
> +    "unsigned long" : "__danger_unsigned_long_on_arm64",
> +    "long"          : "__danger_long_on_arm64",
> +    "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
> +};
> +header["arm64"] = """
> +#define __aarch64___ARM64 1
> +""";
> +footer["arm64"] = """
> +#undef __DECL_REG
> +"""
>  
>  # x86_32
>  inttypes["x86_32"] = {
> @@ -59,6 +75,9 @@ header["x86_64"] = """
>  #endif
>  #define __x86_64___X86_64 1
>  """;
> +footer["x86_64"] = """
> +#undef __DECL_REG
> +"""
>  
>  ###########################################################################
>  # main
> diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
> index 0e5529d..7659c64 100644
> --- a/tools/include/xen-foreign/reference.size
> +++ b/tools/include/xen-foreign/reference.size
> @@ -1,13 +1,13 @@
>  
> -structs                   |   arm32  x86_32  x86_64
> +structs                   |   arm32   arm64  x86_32  x86_64
>  
> -start_info                |       -    1112    1168
> -trap_info                 |       -       8      16
> -cpu_user_regs             |     160      68     200
> -vcpu_guest_context        |     180    2800    5168
> -arch_vcpu_info            |       0      24      16
> -vcpu_time_info            |      32      32      32
> -vcpu_info                 |      48      64      64
> -arch_shared_info          |       0     268     280
> -shared_info               |    1088    2584    3368
> +start_info                |       -       -    1112    1168
> +trap_info                 |       -       -       8      16
> +cpu_user_regs             |     160     160      68     200
> +vcpu_guest_context        |     180     180    2800    5168
> +arch_vcpu_info            |       0       0      24      16
> +vcpu_time_info            |      32      32      32      32
> +vcpu_info                 |      48      48      64      64
> +arch_shared_info          |       0       0     268     280
> +shared_info               |    1088    1088    2584    3368
>  
> diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
> index 51a77c0..5aec2c5 100644
> --- a/tools/include/xen-foreign/structs.py
> +++ b/tools/include/xen-foreign/structs.py
> @@ -14,6 +14,7 @@ structs = [ "start_info",
>              "shared_info" ];
>  
>  defines = [ "__arm__",
> +            "__aarch64__",
>              "__i386__",
>              "__x86_64__",
>  
> -- 
> 1.7.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 Feb 21 16:33:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8Z5W-00015h-SX; Thu, 21 Feb 2013 16:33: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 1U8Z5V-00015c-KV
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:33:37 +0000
Received: from [85.158.139.83:17700] by server-5.bemta-5.messagelabs.com id
	18/5D-11945-06C46215; Thu, 21 Feb 2013 16:33:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361464414!28373830!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5544 invoked from network); 21 Feb 2013 16:33:35 -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;
	21 Feb 2013 16:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8350880"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:33:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:33:29 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8Z5N-0008U4-JW;
	Thu, 21 Feb 2013 16:33:29 +0000
Date: Thu, 21 Feb 2013 16:33:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360860480-9245-20-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302211632190.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-20-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
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 V2 20/46] xen: arm64: add to foreign struct
	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>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  .gitignore                               |    1 +
>  tools/include/xen-foreign/Makefile       |    5 ++++-
>  tools/include/xen-foreign/mkheader.py    |   19 +++++++++++++++++++
>  tools/include/xen-foreign/reference.size |   20 ++++++++++----------
>  tools/include/xen-foreign/structs.py     |    1 +
>  5 files changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 73c5b77..2242344 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -364,6 +364,7 @@ tools/include/xen-foreign/structs.pyc
>  tools/include/xen-foreign/x86_32.h
>  tools/include/xen-foreign/x86_64.h
>  tools/include/xen-foreign/arm32.h
> +tools/include/xen-foreign/arm64.h
>  
>  .git
>  tools/misc/xen-hptool
> diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
> index 53cc6b4..06b844c 100644
> --- a/tools/include/xen-foreign/Makefile
> +++ b/tools/include/xen-foreign/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  
>  ROOT = $(XEN_ROOT)/xen/include/public
>  
> -architectures := arm32 x86_32 x86_64
> +architectures := arm32 arm64 x86_32 x86_64
>  headers := $(patsubst %, %.h, $(architectures))
>  
>  .PHONY: all clean check-headers
> @@ -25,6 +25,9 @@ check-headers: checker
>  arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
>  	$(PYTHON) $< $* $@ $(filter %.h,$^)
>  
> +arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h $(ROOT)/xen.h
> +	$(PYTHON) $< $* $@ $(filter %.h,$^)
> +
>  x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
>  	$(PYTHON) $< $* $@ $(filter %.h,$^)
>  
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index b7c34b1..4858687 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -26,6 +26,22 @@ inttypes["arm32"] = {
>  header["arm32"] = """
>  #define __arm___ARM32 1
>  """;
> +footer["arm32"] = """
> +#undef __DECL_REG
> +"""
> +
> +inttypes["arm64"] = {
> +    "unsigned long" : "__danger_unsigned_long_on_arm64",
> +    "long"          : "__danger_long_on_arm64",
> +    "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
> +};
> +header["arm64"] = """
> +#define __aarch64___ARM64 1
> +""";
> +footer["arm64"] = """
> +#undef __DECL_REG
> +"""
>  
>  # x86_32
>  inttypes["x86_32"] = {
> @@ -59,6 +75,9 @@ header["x86_64"] = """
>  #endif
>  #define __x86_64___X86_64 1
>  """;
> +footer["x86_64"] = """
> +#undef __DECL_REG
> +"""
>  
>  ###########################################################################
>  # main
> diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
> index 0e5529d..7659c64 100644
> --- a/tools/include/xen-foreign/reference.size
> +++ b/tools/include/xen-foreign/reference.size
> @@ -1,13 +1,13 @@
>  
> -structs                   |   arm32  x86_32  x86_64
> +structs                   |   arm32   arm64  x86_32  x86_64
>  
> -start_info                |       -    1112    1168
> -trap_info                 |       -       8      16
> -cpu_user_regs             |     160      68     200
> -vcpu_guest_context        |     180    2800    5168
> -arch_vcpu_info            |       0      24      16
> -vcpu_time_info            |      32      32      32
> -vcpu_info                 |      48      64      64
> -arch_shared_info          |       0     268     280
> -shared_info               |    1088    2584    3368
> +start_info                |       -       -    1112    1168
> +trap_info                 |       -       -       8      16
> +cpu_user_regs             |     160     160      68     200
> +vcpu_guest_context        |     180     180    2800    5168
> +arch_vcpu_info            |       0       0      24      16
> +vcpu_time_info            |      32      32      32      32
> +vcpu_info                 |      48      48      64      64
> +arch_shared_info          |       0       0     268     280
> +shared_info               |    1088    1088    2584    3368
>  
> diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
> index 51a77c0..5aec2c5 100644
> --- a/tools/include/xen-foreign/structs.py
> +++ b/tools/include/xen-foreign/structs.py
> @@ -14,6 +14,7 @@ structs = [ "start_info",
>              "shared_info" ];
>  
>  defines = [ "__arm__",
> +            "__aarch64__",
>              "__i386__",
>              "__x86_64__",
>  
> -- 
> 1.7.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 Feb 21 16:41:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8ZD7-0001M5-6U; Thu, 21 Feb 2013 16:41:29 +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 1U8ZD5-0001Lc-SR
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:41:28 +0000
Received: from [85.158.138.51:57851] by server-4.bemta-3.messagelabs.com id
	A3/00-17521-23E46215; Thu, 21 Feb 2013 16:41:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361464881!20577080!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15972 invoked from network); 21 Feb 2013 16:41:21 -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; 21 Feb 2013 16:41:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 16:41:21 +0000
Message-Id: <51265C7B02000078000C0167@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 16:42:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
In-Reply-To: <20130221144841.GB23819@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 21.02.13 at 15:48, Olaf Hering <olaf@aepfle.de> wrote:

> While doing "while xm migrate --live domU localhost;do sleep 2;done" I
> see many errors from get_page:
> 
> ...
> (XEN) HVM56 restore: TSC_ADJUST 0
> (XEN) HVM56 restore: TSC_ADJUST 1
> (XEN) mm.c:1982:d0 Error pfn 41a863: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41be1c: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41a862: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41b90f: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41b49a: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41b48d: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) irq.c:375: Dom56 callback via changed to Direct Vector 0xf3
> (XEN) HVM56 save: CPU
> ...
> 
> The pfn number and the amount of pfn differs during iterations, but in the 
> end
> only these two variants appear:
> 
> # xm dmesg | grep -w mm | cut -d : -f 4- | sort | uniq -c | sort
>      22  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, 
> taf=7400000000000001
>      46  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, 
> taf=0000000000000001
> 
> 
> It does not seem to cause issues other than the log output.
> Does it indiciate a real bug?

I'm afraid it does - a non-zero type count should generally not be
accompanied by a zero general count. That's specifically because
lone put_page_type() calls are pretty rare, and going through all
of them I don't see anyone that could be one being outstanding
in your case.

I'm surprised this doesn't cause an assertion to trigger somewhere.
You are using a debug hypervisor, aren't you?

Of course, if this truly is just a "leaked" type reference, then no
other bad consequences are to be afraid of.

What you could do to get a better understanding of when this
happens is to add a WARN_ON() alongside the printk() (perhaps
such that it triggers only once for each of the two different
cases), and then let us look at the call trace.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:41:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16: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 1U8ZD7-0001M5-6U; Thu, 21 Feb 2013 16:41:29 +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 1U8ZD5-0001Lc-SR
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:41:28 +0000
Received: from [85.158.138.51:57851] by server-4.bemta-3.messagelabs.com id
	A3/00-17521-23E46215; Thu, 21 Feb 2013 16:41:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361464881!20577080!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15972 invoked from network); 21 Feb 2013 16:41:21 -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; 21 Feb 2013 16:41:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 21 Feb 2013 16:41:21 +0000
Message-Id: <51265C7B02000078000C0167@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 21 Feb 2013 16:42:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
In-Reply-To: <20130221144841.GB23819@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 21.02.13 at 15:48, Olaf Hering <olaf@aepfle.de> wrote:

> While doing "while xm migrate --live domU localhost;do sleep 2;done" I
> see many errors from get_page:
> 
> ...
> (XEN) HVM56 restore: TSC_ADJUST 0
> (XEN) HVM56 restore: TSC_ADJUST 1
> (XEN) mm.c:1982:d0 Error pfn 41a863: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41be1c: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41a862: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41b90f: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41b49a: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) mm.c:1982:d0 Error pfn 41b48d: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> (XEN) irq.c:375: Dom56 callback via changed to Direct Vector 0xf3
> (XEN) HVM56 save: CPU
> ...
> 
> The pfn number and the amount of pfn differs during iterations, but in the 
> end
> only these two variants appear:
> 
> # xm dmesg | grep -w mm | cut -d : -f 4- | sort | uniq -c | sort
>      22  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, 
> taf=7400000000000001
>      46  rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, 
> taf=0000000000000001
> 
> 
> It does not seem to cause issues other than the log output.
> Does it indiciate a real bug?

I'm afraid it does - a non-zero type count should generally not be
accompanied by a zero general count. That's specifically because
lone put_page_type() calls are pretty rare, and going through all
of them I don't see anyone that could be one being outstanding
in your case.

I'm surprised this doesn't cause an assertion to trigger somewhere.
You are using a debug hypervisor, aren't you?

Of course, if this truly is just a "leaked" type reference, then no
other bad consequences are to be afraid of.

What you could do to get a better understanding of when this
happens is to add a WARN_ON() alongside the printk() (perhaps
such that it triggers only once for each of the two different
cases), and then let us look at the call trace.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 16:46:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:46: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 1U8ZI1-0001m4-2L; Thu, 21 Feb 2013 16:46:33 +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 1U8ZHz-0001ly-FG
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:46:31 +0000
Received: from [85.158.139.83:57215] by server-1.bemta-5.messagelabs.com id
	7C/DB-29263-66F46215; Thu, 21 Feb 2013 16:46:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361465188!28342886!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27917 invoked from network); 21 Feb 2013 16:46:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:46:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1743561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:46: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.297.1;
	Thu, 21 Feb 2013 16:46:28 +0000
Message-ID: <1361465187.26546.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:46:27 +0000
In-Reply-To: <alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
	<1361462485.26546.74.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 2013-02-21 at 16:23 +0000, Stefano Stabellini wrote:
> On Thu, 21 Feb 2013, Ian Campbell wrote:
> > On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Acked-by: Tim Deegan <tim@xen.org>
> > > but:
> > >         This is mostly a matter of coding taste, so I'd like Stefano's
> > >         ack/nack here as well.
> >
> > Stefano, any strong opinion?
> 
> Are there any concrete benefits in introducing register_t compared to
> using unsigned long?

It decouples us from assuming a compiler where unsigned long is the size
of a register ;-)

In the ARM port we have mostly been trying to define and use fixed size
and/or semantic types (uintXX_t, paddr_t etc) rather than compiler
variant things like int and long.

Ian.
> 
> 
> > >  xen/arch/arm/domain_build.c |    2 +-
> > >  xen/arch/arm/smpboot.c      |    2 +-
> > >  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
> > >  xen/arch/arm/vgic.c         |   18 ++++++++--------
> > >  xen/arch/arm/vpl011.c       |    6 ++--
> > >  xen/arch/arm/vtimer.c       |    6 ++--
> > >  xen/include/asm-arm/regs.h  |    2 +-
> > >  xen/include/asm-arm/types.h |    4 +++
> > >  8 files changed, 45 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 7403f1a..30d014a 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> > >
> > >  static void dtb_load(struct kernel_info *kinfo)
> > >  {
> > > -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> > > +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> > >
> > >      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
> > >      xfree(kinfo->fdt);
> > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > > index 86379b7..d8eb5d3 100644
> > > --- a/xen/arch/arm/smpboot.c
> > > +++ b/xen/arch/arm/smpboot.c
> > > @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
> > >      set_processor_id(cpuid);
> > >
> > >      /* Setup Hyp vector base */
> > > -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> > > +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> > >
> > >      mmu_init_secondary_cpu();
> > >      enable_vfp();
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index eaf1f52..0299b33 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -68,7 +68,7 @@ static void print_xen_info(void)
> > >             debug_build() ? 'y' : 'n', print_tainted(taint_str));
> > >  }
> > >
> > > -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > >  {
> > >      BUG_ON( !guest_mode(regs) );
> > >
> > > @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > >
> > >      switch ( reg ) {
> > >      case 0 ... 7: /* Unbanked registers */
> > > -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> > > +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
> > >          return &regs->r0 + reg;
> > >      case 8 ... 12: /* Register banked in FIQ mode */
> > > -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> > > +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
> > >          if ( fiq_mode(regs) )
> > >              return &regs->r8_fiq + reg - 8;
> > >          else
> > >              return &regs->r8 + reg - 8;
> > >      case 13 ... 14: /* Banked SP + LR registers */
> > > -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> > > -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> > > -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> > > -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> > > -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> > > +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> > > +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> > > +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> > > +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> > > +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
> > >          switch ( regs->cpsr & PSR_MODE_MASK )
> > >          {
> > >          case PSR_MODE_USR:
> > > @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
> > >      printk("GUEST STACK GOES HERE\n");
> > >  }
> > >
> > > -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> > > +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> > >
> > >  static void show_trace(struct cpu_user_regs *regs)
> > >  {
> > > -    uint32_t *frame, next, addr, low, high;
> > > +    register_t *frame, next, addr, low, high;
> > >
> > >      printk("Xen call trace:\n   ");
> > >
> > > @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >      print_symbol(" %s\n   ", regs->pc);
> > >
> > >      /* Bounds for range of valid frame pointer. */
> > > -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > > +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > >      high = (low & ~(STACK_SIZE - 1)) +
> > >          (STACK_SIZE - sizeof(struct cpu_info));
> > >
> > > @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >              break;
> > >          {
> > >              /* Ordinary stack frame. */
> > > -            frame = (uint32_t *)next;
> > > +            frame = (register_t *)next;
> > >              next  = frame[-1];
> > >              addr  = frame[0];
> > >          }
> > > @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >          printk("[<%p>]", _p(addr));
> > >          print_symbol(" %s\n   ", addr);
> > >
> > > -        low = (uint32_t)&frame[1];
> > > +        low = (register_t)&frame[1];
> > >      }
> > >
> > >      printk("\n");
> > > @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >
> > >  void show_stack(struct cpu_user_regs *regs)
> > >  {
> > > -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > > +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > >      int i;
> > >
> > >      if ( guest_mode(regs) )
> > > @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> > >
> > >  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> > >  {
> > > -    uint32_t reg, *r;
> > > +    register_t *r;
> > > +    uint32_t reg;
> > >      uint32_t domid = current->domain->domain_id;
> > >      switch ( code ) {
> > >      case 0xe0 ... 0xef:
> > >          reg = code - 0xe0;
> > >          r = select_user_reg(regs, reg);
> > > -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> > > +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> > >                 domid, reg, *r, regs->pc);
> > >          break;
> > >      case 0xfd:
> > > -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> > > +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
> > >          break;
> > >      case 0xfe:
> > > -        printk("%c", (char)(regs->r0 & 0xff));
> > > +        r = select_user_reg(regs, 0);
> > > +        printk("%c", (char)(*r & 0xff));
> > >          break;
> > >      case 0xff:
> > >          printk("DOM%d: DEBUG\n", domid);
> > > @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > >                         union hsr hsr)
> > >  {
> > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> > >
> > >      if ( !cp32.ccvalid ) {
> > >          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> > > @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > >          break;
> > >      default:
> > > -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> > > +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
> > >                 cp32.read ? "mrc" : "mcr",
> > >                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
> > >          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> > > @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > >          break;
> > >      default:
> > > -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> > > +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> > >                 cp64.read ? "mrrc" : "mcrr",
> > >                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
> > >          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > > index 39b9775..57147d5 100644
> > > --- a/xen/arch/arm/vgic.c
> > > +++ b/xen/arch/arm/vgic.c
> > > @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      struct vgic_irq_rank *rank;
> > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > >      int gicd_reg = REG(offset);
> > > @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      struct vgic_irq_rank *rank;
> > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > >      int gicd_reg = REG(offset);
> > > @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >
> > >      case GICD_ISPENDR ... GICD_ISPENDRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
> > >          return 0;
> > >
> > >      case GICD_ICPENDR ... GICD_ICPENDRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
> > >          return 0;
> > >
> > > @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >
> > >      case GICD_SGIR:
> > >          if ( dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> > > +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
> > >                 *r, gicd_reg - GICD_ICFGR);
> > >          return 0;
> > >
> > >      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
> > >          return 0;
> > >
> > >      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
> > >          return 0;
> > >
> > > @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >          goto write_ignore;
> > >
> > >      default:
> > > -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > >                 dabt.reg, *r, offset);
> > >          return 0;
> > >      }
> > >
> > >  bad_width:
> > > -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> > > +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> > >             dabt.size, dabt.reg, *r, offset);
> > >      domain_crash_synchronous();
> > >      return 0;
> > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > > index 7dcee90..db5094e 100644
> > > --- a/xen/arch/arm/vpl011.c
> > > +++ b/xen/arch/arm/vpl011.c
> > > @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      int offset = (int)(info->gpa - UART0_START);
> > >
> > >      switch ( offset )
> > > @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      int offset = (int)(info->gpa - UART0_START);
> > >
> > >      switch ( offset )
> > > @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >          /* Silently ignore */
> > >          return 1;
> > >      default:
> > > -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > >                 dabt.reg, *r, offset);
> > >          domain_crash_synchronous();
> > >      }
> > > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > > index 85201b5..291b87e 100644
> > > --- a/xen/arch/arm/vtimer.c
> > > +++ b/xen/arch/arm/vtimer.c
> > > @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > >  {
> > >      struct vcpu *v = current;
> > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
> > >      s_time_t now;
> > >
> > >      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > > @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
> > >  {
> > >      struct vcpu *v = current;
> > >      struct hsr_cp64 cp64 = hsr.cp64;
> > > -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> > > -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> > > +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> > > +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
> > >      uint64_t ticks;
> > >      s_time_t now;
> > >
> > > diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> > > index 7486944..a723f92 100644
> > > --- a/xen/include/asm-arm/regs.h
> > > +++ b/xen/include/asm-arm/regs.h
> > > @@ -34,7 +34,7 @@
> > >   * Returns a pointer to the given register value in regs, taking the
> > >   * processor mode (CPSR) into account.
> > >   */
> > > -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > > +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > >
> > >  #endif /* __ARM_REGS_H__ */
> > >  /*
> > > diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> > > index d3e16d8..9ca32f1 100644
> > > --- a/xen/include/asm-arm/types.h
> > > +++ b/xen/include/asm-arm/types.h
> > > @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
> > >  typedef u64 paddr_t;
> > >  #define INVALID_PADDR (~0ULL)
> > >  #define PRIpaddr "016llx"
> > > +typedef u32 register_t;
> > > +#define PRIregister "x"
> > >  #elif defined (CONFIG_ARM_64)
> > >  typedef signed long s64;
> > >  typedef unsigned long u64;
> > > @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
> > >  typedef u64 paddr_t;
> > >  #define INVALID_PADDR (~0UL)
> > >  #define PRIpaddr "016lx"
> > > +typedef u64 register_t;
> > > +#define PRIregister "lx"
> > >  #endif
> > >
> > >  typedef unsigned long size_t;
> > > --
> > > 1.7.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 Feb 21 16:46:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:46: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 1U8ZI1-0001m4-2L; Thu, 21 Feb 2013 16:46:33 +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 1U8ZHz-0001ly-FG
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:46:31 +0000
Received: from [85.158.139.83:57215] by server-1.bemta-5.messagelabs.com id
	7C/DB-29263-66F46215; Thu, 21 Feb 2013 16:46:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361465188!28342886!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27917 invoked from network); 21 Feb 2013 16:46:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:46:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1743561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 16:46: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.297.1;
	Thu, 21 Feb 2013 16:46:28 +0000
Message-ID: <1361465187.26546.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 21 Feb 2013 16:46:27 +0000
In-Reply-To: <alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
	<1361462485.26546.74.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 2013-02-21 at 16:23 +0000, Stefano Stabellini wrote:
> On Thu, 21 Feb 2013, Ian Campbell wrote:
> > On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Acked-by: Tim Deegan <tim@xen.org>
> > > but:
> > >         This is mostly a matter of coding taste, so I'd like Stefano's
> > >         ack/nack here as well.
> >
> > Stefano, any strong opinion?
> 
> Are there any concrete benefits in introducing register_t compared to
> using unsigned long?

It decouples us from assuming a compiler where unsigned long is the size
of a register ;-)

In the ARM port we have mostly been trying to define and use fixed size
and/or semantic types (uintXX_t, paddr_t etc) rather than compiler
variant things like int and long.

Ian.
> 
> 
> > >  xen/arch/arm/domain_build.c |    2 +-
> > >  xen/arch/arm/smpboot.c      |    2 +-
> > >  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
> > >  xen/arch/arm/vgic.c         |   18 ++++++++--------
> > >  xen/arch/arm/vpl011.c       |    6 ++--
> > >  xen/arch/arm/vtimer.c       |    6 ++--
> > >  xen/include/asm-arm/regs.h  |    2 +-
> > >  xen/include/asm-arm/types.h |    4 +++
> > >  8 files changed, 45 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 7403f1a..30d014a 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> > >
> > >  static void dtb_load(struct kernel_info *kinfo)
> > >  {
> > > -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> > > +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> > >
> > >      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
> > >      xfree(kinfo->fdt);
> > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > > index 86379b7..d8eb5d3 100644
> > > --- a/xen/arch/arm/smpboot.c
> > > +++ b/xen/arch/arm/smpboot.c
> > > @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
> > >      set_processor_id(cpuid);
> > >
> > >      /* Setup Hyp vector base */
> > > -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> > > +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> > >
> > >      mmu_init_secondary_cpu();
> > >      enable_vfp();
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index eaf1f52..0299b33 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -68,7 +68,7 @@ static void print_xen_info(void)
> > >             debug_build() ? 'y' : 'n', print_tainted(taint_str));
> > >  }
> > >
> > > -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > >  {
> > >      BUG_ON( !guest_mode(regs) );
> > >
> > > @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > >
> > >      switch ( reg ) {
> > >      case 0 ... 7: /* Unbanked registers */
> > > -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> > > +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
> > >          return &regs->r0 + reg;
> > >      case 8 ... 12: /* Register banked in FIQ mode */
> > > -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> > > +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
> > >          if ( fiq_mode(regs) )
> > >              return &regs->r8_fiq + reg - 8;
> > >          else
> > >              return &regs->r8 + reg - 8;
> > >      case 13 ... 14: /* Banked SP + LR registers */
> > > -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> > > -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> > > -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> > > -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> > > -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> > > +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> > > +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> > > +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> > > +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> > > +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
> > >          switch ( regs->cpsr & PSR_MODE_MASK )
> > >          {
> > >          case PSR_MODE_USR:
> > > @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
> > >      printk("GUEST STACK GOES HERE\n");
> > >  }
> > >
> > > -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> > > +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> > >
> > >  static void show_trace(struct cpu_user_regs *regs)
> > >  {
> > > -    uint32_t *frame, next, addr, low, high;
> > > +    register_t *frame, next, addr, low, high;
> > >
> > >      printk("Xen call trace:\n   ");
> > >
> > > @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >      print_symbol(" %s\n   ", regs->pc);
> > >
> > >      /* Bounds for range of valid frame pointer. */
> > > -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > > +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > >      high = (low & ~(STACK_SIZE - 1)) +
> > >          (STACK_SIZE - sizeof(struct cpu_info));
> > >
> > > @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >              break;
> > >          {
> > >              /* Ordinary stack frame. */
> > > -            frame = (uint32_t *)next;
> > > +            frame = (register_t *)next;
> > >              next  = frame[-1];
> > >              addr  = frame[0];
> > >          }
> > > @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >          printk("[<%p>]", _p(addr));
> > >          print_symbol(" %s\n   ", addr);
> > >
> > > -        low = (uint32_t)&frame[1];
> > > +        low = (register_t)&frame[1];
> > >      }
> > >
> > >      printk("\n");
> > > @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > >
> > >  void show_stack(struct cpu_user_regs *regs)
> > >  {
> > > -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > > +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > >      int i;
> > >
> > >      if ( guest_mode(regs) )
> > > @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> > >
> > >  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> > >  {
> > > -    uint32_t reg, *r;
> > > +    register_t *r;
> > > +    uint32_t reg;
> > >      uint32_t domid = current->domain->domain_id;
> > >      switch ( code ) {
> > >      case 0xe0 ... 0xef:
> > >          reg = code - 0xe0;
> > >          r = select_user_reg(regs, reg);
> > > -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> > > +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> > >                 domid, reg, *r, regs->pc);
> > >          break;
> > >      case 0xfd:
> > > -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> > > +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
> > >          break;
> > >      case 0xfe:
> > > -        printk("%c", (char)(regs->r0 & 0xff));
> > > +        r = select_user_reg(regs, 0);
> > > +        printk("%c", (char)(*r & 0xff));
> > >          break;
> > >      case 0xff:
> > >          printk("DOM%d: DEBUG\n", domid);
> > > @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > >                         union hsr hsr)
> > >  {
> > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> > >
> > >      if ( !cp32.ccvalid ) {
> > >          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> > > @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > >          break;
> > >      default:
> > > -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> > > +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
> > >                 cp32.read ? "mrc" : "mcr",
> > >                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
> > >          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> > > @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > >          break;
> > >      default:
> > > -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> > > +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> > >                 cp64.read ? "mrrc" : "mcrr",
> > >                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
> > >          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > > index 39b9775..57147d5 100644
> > > --- a/xen/arch/arm/vgic.c
> > > +++ b/xen/arch/arm/vgic.c
> > > @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      struct vgic_irq_rank *rank;
> > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > >      int gicd_reg = REG(offset);
> > > @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      struct vgic_irq_rank *rank;
> > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > >      int gicd_reg = REG(offset);
> > > @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >
> > >      case GICD_ISPENDR ... GICD_ISPENDRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
> > >          return 0;
> > >
> > >      case GICD_ICPENDR ... GICD_ICPENDRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
> > >          return 0;
> > >
> > > @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >
> > >      case GICD_SGIR:
> > >          if ( dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> > > +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
> > >                 *r, gicd_reg - GICD_ICFGR);
> > >          return 0;
> > >
> > >      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
> > >          return 0;
> > >
> > >      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
> > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
> > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
> > >          return 0;
> > >
> > > @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >          goto write_ignore;
> > >
> > >      default:
> > > -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > >                 dabt.reg, *r, offset);
> > >          return 0;
> > >      }
> > >
> > >  bad_width:
> > > -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> > > +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> > >             dabt.size, dabt.reg, *r, offset);
> > >      domain_crash_synchronous();
> > >      return 0;
> > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > > index 7dcee90..db5094e 100644
> > > --- a/xen/arch/arm/vpl011.c
> > > +++ b/xen/arch/arm/vpl011.c
> > > @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      int offset = (int)(info->gpa - UART0_START);
> > >
> > >      switch ( offset )
> > > @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >  {
> > >      struct hsr_dabt dabt = info->dabt;
> > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > >      int offset = (int)(info->gpa - UART0_START);
> > >
> > >      switch ( offset )
> > > @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > >          /* Silently ignore */
> > >          return 1;
> > >      default:
> > > -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > >                 dabt.reg, *r, offset);
> > >          domain_crash_synchronous();
> > >      }
> > > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > > index 85201b5..291b87e 100644
> > > --- a/xen/arch/arm/vtimer.c
> > > +++ b/xen/arch/arm/vtimer.c
> > > @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > >  {
> > >      struct vcpu *v = current;
> > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
> > >      s_time_t now;
> > >
> > >      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > > @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
> > >  {
> > >      struct vcpu *v = current;
> > >      struct hsr_cp64 cp64 = hsr.cp64;
> > > -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> > > -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> > > +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> > > +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
> > >      uint64_t ticks;
> > >      s_time_t now;
> > >
> > > diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> > > index 7486944..a723f92 100644
> > > --- a/xen/include/asm-arm/regs.h
> > > +++ b/xen/include/asm-arm/regs.h
> > > @@ -34,7 +34,7 @@
> > >   * Returns a pointer to the given register value in regs, taking the
> > >   * processor mode (CPSR) into account.
> > >   */
> > > -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > > +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > >
> > >  #endif /* __ARM_REGS_H__ */
> > >  /*
> > > diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> > > index d3e16d8..9ca32f1 100644
> > > --- a/xen/include/asm-arm/types.h
> > > +++ b/xen/include/asm-arm/types.h
> > > @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
> > >  typedef u64 paddr_t;
> > >  #define INVALID_PADDR (~0ULL)
> > >  #define PRIpaddr "016llx"
> > > +typedef u32 register_t;
> > > +#define PRIregister "x"
> > >  #elif defined (CONFIG_ARM_64)
> > >  typedef signed long s64;
> > >  typedef unsigned long u64;
> > > @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
> > >  typedef u64 paddr_t;
> > >  #define INVALID_PADDR (~0UL)
> > >  #define PRIpaddr "016lx"
> > > +typedef u64 register_t;
> > > +#define PRIregister "lx"
> > >  #endif
> > >
> > >  typedef unsigned long size_t;
> > > --
> > > 1.7.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 Feb 21 16:50:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:50: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 1U8ZLY-0001xr-2P; Thu, 21 Feb 2013 16:50:12 +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 1U8ZLV-0001xk-Ul
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:50:10 +0000
Received: from [85.158.143.99:64995] by server-1.bemta-4.messagelabs.com id
	AA/9A-06203-14056215; Thu, 21 Feb 2013 16:50:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361465404!17147228!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 21 Feb 2013 16:50:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:50:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8789678"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:50:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:50:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8ZLM-0000Hn-LW;
	Thu, 21 Feb 2013 16:50:00 +0000
Date: Thu, 21 Feb 2013 16:49:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361465187.26546.83.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302211649290.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
	<1361462485.26546.74.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
	<1361465187.26546.83.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 21 Feb 2013, Ian Campbell wrote:
> On Thu, 2013-02-21 at 16:23 +0000, Stefano Stabellini wrote:
> > On Thu, 21 Feb 2013, Ian Campbell wrote:
> > > On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > Acked-by: Tim Deegan <tim@xen.org>
> > > > but:
> > > >         This is mostly a matter of coding taste, so I'd like Stefano's
> > > >         ack/nack here as well.
> > >
> > > Stefano, any strong opinion?
> >
> > Are there any concrete benefits in introducing register_t compared to
> > using unsigned long?
> 
> It decouples us from assuming a compiler where unsigned long is the size
> of a register ;-)
> 
> In the ARM port we have mostly been trying to define and use fixed size
> and/or semantic types (uintXX_t, paddr_t etc) rather than compiler
> variant things like int and long.

OK.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> >
> >
> > > >  xen/arch/arm/domain_build.c |    2 +-
> > > >  xen/arch/arm/smpboot.c      |    2 +-
> > > >  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
> > > >  xen/arch/arm/vgic.c         |   18 ++++++++--------
> > > >  xen/arch/arm/vpl011.c       |    6 ++--
> > > >  xen/arch/arm/vtimer.c       |    6 ++--
> > > >  xen/include/asm-arm/regs.h  |    2 +-
> > > >  xen/include/asm-arm/types.h |    4 +++
> > > >  8 files changed, 45 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index 7403f1a..30d014a 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> > > >
> > > >  static void dtb_load(struct kernel_info *kinfo)
> > > >  {
> > > > -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> > > > +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> > > >
> > > >      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
> > > >      xfree(kinfo->fdt);
> > > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > > > index 86379b7..d8eb5d3 100644
> > > > --- a/xen/arch/arm/smpboot.c
> > > > +++ b/xen/arch/arm/smpboot.c
> > > > @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
> > > >      set_processor_id(cpuid);
> > > >
> > > >      /* Setup Hyp vector base */
> > > > -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> > > > +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> > > >
> > > >      mmu_init_secondary_cpu();
> > > >      enable_vfp();
> > > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > > index eaf1f52..0299b33 100644
> > > > --- a/xen/arch/arm/traps.c
> > > > +++ b/xen/arch/arm/traps.c
> > > > @@ -68,7 +68,7 @@ static void print_xen_info(void)
> > > >             debug_build() ? 'y' : 'n', print_tainted(taint_str));
> > > >  }
> > > >
> > > > -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > > +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > >  {
> > > >      BUG_ON( !guest_mode(regs) );
> > > >
> > > > @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > >
> > > >      switch ( reg ) {
> > > >      case 0 ... 7: /* Unbanked registers */
> > > > -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> > > > +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
> > > >          return &regs->r0 + reg;
> > > >      case 8 ... 12: /* Register banked in FIQ mode */
> > > > -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> > > > +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
> > > >          if ( fiq_mode(regs) )
> > > >              return &regs->r8_fiq + reg - 8;
> > > >          else
> > > >              return &regs->r8 + reg - 8;
> > > >      case 13 ... 14: /* Banked SP + LR registers */
> > > > -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
> > > >          switch ( regs->cpsr & PSR_MODE_MASK )
> > > >          {
> > > >          case PSR_MODE_USR:
> > > > @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
> > > >      printk("GUEST STACK GOES HERE\n");
> > > >  }
> > > >
> > > > -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> > > > +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> > > >
> > > >  static void show_trace(struct cpu_user_regs *regs)
> > > >  {
> > > > -    uint32_t *frame, next, addr, low, high;
> > > > +    register_t *frame, next, addr, low, high;
> > > >
> > > >      printk("Xen call trace:\n   ");
> > > >
> > > > @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >      print_symbol(" %s\n   ", regs->pc);
> > > >
> > > >      /* Bounds for range of valid frame pointer. */
> > > > -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > > > +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > > >      high = (low & ~(STACK_SIZE - 1)) +
> > > >          (STACK_SIZE - sizeof(struct cpu_info));
> > > >
> > > > @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >              break;
> > > >          {
> > > >              /* Ordinary stack frame. */
> > > > -            frame = (uint32_t *)next;
> > > > +            frame = (register_t *)next;
> > > >              next  = frame[-1];
> > > >              addr  = frame[0];
> > > >          }
> > > > @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >          printk("[<%p>]", _p(addr));
> > > >          print_symbol(" %s\n   ", addr);
> > > >
> > > > -        low = (uint32_t)&frame[1];
> > > > +        low = (register_t)&frame[1];
> > > >      }
> > > >
> > > >      printk("\n");
> > > > @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >
> > > >  void show_stack(struct cpu_user_regs *regs)
> > > >  {
> > > > -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > > > +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > > >      int i;
> > > >
> > > >      if ( guest_mode(regs) )
> > > > @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> > > >
> > > >  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> > > >  {
> > > > -    uint32_t reg, *r;
> > > > +    register_t *r;
> > > > +    uint32_t reg;
> > > >      uint32_t domid = current->domain->domain_id;
> > > >      switch ( code ) {
> > > >      case 0xe0 ... 0xef:
> > > >          reg = code - 0xe0;
> > > >          r = select_user_reg(regs, reg);
> > > > -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> > > > +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> > > >                 domid, reg, *r, regs->pc);
> > > >          break;
> > > >      case 0xfd:
> > > > -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> > > > +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
> > > >          break;
> > > >      case 0xfe:
> > > > -        printk("%c", (char)(regs->r0 & 0xff));
> > > > +        r = select_user_reg(regs, 0);
> > > > +        printk("%c", (char)(*r & 0xff));
> > > >          break;
> > > >      case 0xff:
> > > >          printk("DOM%d: DEBUG\n", domid);
> > > > @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > > >                         union hsr hsr)
> > > >  {
> > > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > > +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> > > >
> > > >      if ( !cp32.ccvalid ) {
> > > >          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> > > > @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > > >          break;
> > > >      default:
> > > > -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> > > > +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
> > > >                 cp32.read ? "mrc" : "mcr",
> > > >                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
> > > >          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> > > > @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> > > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > > >          break;
> > > >      default:
> > > > -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> > > > +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> > > >                 cp64.read ? "mrrc" : "mcrr",
> > > >                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
> > > >          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> > > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > > > index 39b9775..57147d5 100644
> > > > --- a/xen/arch/arm/vgic.c
> > > > +++ b/xen/arch/arm/vgic.c
> > > > @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      struct vgic_irq_rank *rank;
> > > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > > >      int gicd_reg = REG(offset);
> > > > @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      struct vgic_irq_rank *rank;
> > > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > > >      int gicd_reg = REG(offset);
> > > > @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >
> > > >      case GICD_ISPENDR ... GICD_ISPENDRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
> > > >          return 0;
> > > >
> > > >      case GICD_ICPENDR ... GICD_ICPENDRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
> > > >          return 0;
> > > >
> > > > @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >
> > > >      case GICD_SGIR:
> > > >          if ( dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> > > > +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
> > > >                 *r, gicd_reg - GICD_ICFGR);
> > > >          return 0;
> > > >
> > > >      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
> > > >          return 0;
> > > >
> > > >      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
> > > >          return 0;
> > > >
> > > > @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >          goto write_ignore;
> > > >
> > > >      default:
> > > > -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > > +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > > >                 dabt.reg, *r, offset);
> > > >          return 0;
> > > >      }
> > > >
> > > >  bad_width:
> > > > -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> > > > +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> > > >             dabt.size, dabt.reg, *r, offset);
> > > >      domain_crash_synchronous();
> > > >      return 0;
> > > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > > > index 7dcee90..db5094e 100644
> > > > --- a/xen/arch/arm/vpl011.c
> > > > +++ b/xen/arch/arm/vpl011.c
> > > > @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      int offset = (int)(info->gpa - UART0_START);
> > > >
> > > >      switch ( offset )
> > > > @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      int offset = (int)(info->gpa - UART0_START);
> > > >
> > > >      switch ( offset )
> > > > @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >          /* Silently ignore */
> > > >          return 1;
> > > >      default:
> > > > -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > > +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > > >                 dabt.reg, *r, offset);
> > > >          domain_crash_synchronous();
> > > >      }
> > > > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > > > index 85201b5..291b87e 100644
> > > > --- a/xen/arch/arm/vtimer.c
> > > > +++ b/xen/arch/arm/vtimer.c
> > > > @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > > >  {
> > > >      struct vcpu *v = current;
> > > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > > +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
> > > >      s_time_t now;
> > > >
> > > >      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > > > @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
> > > >  {
> > > >      struct vcpu *v = current;
> > > >      struct hsr_cp64 cp64 = hsr.cp64;
> > > > -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> > > > -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> > > > +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> > > > +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
> > > >      uint64_t ticks;
> > > >      s_time_t now;
> > > >
> > > > diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> > > > index 7486944..a723f92 100644
> > > > --- a/xen/include/asm-arm/regs.h
> > > > +++ b/xen/include/asm-arm/regs.h
> > > > @@ -34,7 +34,7 @@
> > > >   * Returns a pointer to the given register value in regs, taking the
> > > >   * processor mode (CPSR) into account.
> > > >   */
> > > > -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > > > +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > > >
> > > >  #endif /* __ARM_REGS_H__ */
> > > >  /*
> > > > diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> > > > index d3e16d8..9ca32f1 100644
> > > > --- a/xen/include/asm-arm/types.h
> > > > +++ b/xen/include/asm-arm/types.h
> > > > @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
> > > >  typedef u64 paddr_t;
> > > >  #define INVALID_PADDR (~0ULL)
> > > >  #define PRIpaddr "016llx"
> > > > +typedef u32 register_t;
> > > > +#define PRIregister "x"
> > > >  #elif defined (CONFIG_ARM_64)
> > > >  typedef signed long s64;
> > > >  typedef unsigned long u64;
> > > > @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
> > > >  typedef u64 paddr_t;
> > > >  #define INVALID_PADDR (~0UL)
> > > >  #define PRIpaddr "016lx"
> > > > +typedef u64 register_t;
> > > > +#define PRIregister "lx"
> > > >  #endif
> > > >
> > > >  typedef unsigned long size_t;
> > > > --
> > > > 1.7.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 Feb 21 16:50:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:50: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 1U8ZLY-0001xr-2P; Thu, 21 Feb 2013 16:50:12 +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 1U8ZLV-0001xk-Ul
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:50:10 +0000
Received: from [85.158.143.99:64995] by server-1.bemta-4.messagelabs.com id
	AA/9A-06203-14056215; Thu, 21 Feb 2013 16:50:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361465404!17147228!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 21 Feb 2013 16:50:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 16:50:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8789678"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:50:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:50:00 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8ZLM-0000Hn-LW;
	Thu, 21 Feb 2013 16:50:00 +0000
Date: Thu, 21 Feb 2013 16:49:56 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361465187.26546.83.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302211649290.22997@kaball.uk.xensource.com>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360860480-9245-23-git-send-email-ian.campbell@citrix.com>
	<1361462485.26546.74.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302211621111.22997@kaball.uk.xensource.com>
	<1361465187.26546.83.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V2 23/46] xen: arm: add register_t type,
 native register size for the 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 Thu, 21 Feb 2013, Ian Campbell wrote:
> On Thu, 2013-02-21 at 16:23 +0000, Stefano Stabellini wrote:
> > On Thu, 21 Feb 2013, Ian Campbell wrote:
> > > On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > Acked-by: Tim Deegan <tim@xen.org>
> > > > but:
> > > >         This is mostly a matter of coding taste, so I'd like Stefano's
> > > >         ack/nack here as well.
> > >
> > > Stefano, any strong opinion?
> >
> > Are there any concrete benefits in introducing register_t compared to
> > using unsigned long?
> 
> It decouples us from assuming a compiler where unsigned long is the size
> of a register ;-)
> 
> In the ARM port we have mostly been trying to define and use fixed size
> and/or semantic types (uintXX_t, paddr_t etc) rather than compiler
> variant things like int and long.

OK.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> >
> >
> > > >  xen/arch/arm/domain_build.c |    2 +-
> > > >  xen/arch/arm/smpboot.c      |    2 +-
> > > >  xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
> > > >  xen/arch/arm/vgic.c         |   18 ++++++++--------
> > > >  xen/arch/arm/vpl011.c       |    6 ++--
> > > >  xen/arch/arm/vtimer.c       |    6 ++--
> > > >  xen/include/asm-arm/regs.h  |    2 +-
> > > >  xen/include/asm-arm/types.h |    4 +++
> > > >  8 files changed, 45 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index 7403f1a..30d014a 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> > > >
> > > >  static void dtb_load(struct kernel_info *kinfo)
> > > >  {
> > > > -    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
> > > > +    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
> > > >
> > > >      raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
> > > >      xfree(kinfo->fdt);
> > > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > > > index 86379b7..d8eb5d3 100644
> > > > --- a/xen/arch/arm/smpboot.c
> > > > +++ b/xen/arch/arm/smpboot.c
> > > > @@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
> > > >      set_processor_id(cpuid);
> > > >
> > > >      /* Setup Hyp vector base */
> > > > -    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
> > > > +    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
> > > >
> > > >      mmu_init_secondary_cpu();
> > > >      enable_vfp();
> > > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > > index eaf1f52..0299b33 100644
> > > > --- a/xen/arch/arm/traps.c
> > > > +++ b/xen/arch/arm/traps.c
> > > > @@ -68,7 +68,7 @@ static void print_xen_info(void)
> > > >             debug_build() ? 'y' : 'n', print_tainted(taint_str));
> > > >  }
> > > >
> > > > -uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > > +register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > >  {
> > > >      BUG_ON( !guest_mode(regs) );
> > > >
> > > > @@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
> > > >
> > > >      switch ( reg ) {
> > > >      case 0 ... 7: /* Unbanked registers */
> > > > -        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
> > > > +        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
> > > >          return &regs->r0 + reg;
> > > >      case 8 ... 12: /* Register banked in FIQ mode */
> > > > -        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
> > > > +        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
> > > >          if ( fiq_mode(regs) )
> > > >              return &regs->r8_fiq + reg - 8;
> > > >          else
> > > >              return &regs->r8 + reg - 8;
> > > >      case 13 ... 14: /* Banked SP + LR registers */
> > > > -        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
> > > > -        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
> > > > +        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
> > > >          switch ( regs->cpsr & PSR_MODE_MASK )
> > > >          {
> > > >          case PSR_MODE_USR:
> > > > @@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
> > > >      printk("GUEST STACK GOES HERE\n");
> > > >  }
> > > >
> > > > -#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
> > > > +#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
> > > >
> > > >  static void show_trace(struct cpu_user_regs *regs)
> > > >  {
> > > > -    uint32_t *frame, next, addr, low, high;
> > > > +    register_t *frame, next, addr, low, high;
> > > >
> > > >      printk("Xen call trace:\n   ");
> > > >
> > > > @@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >      print_symbol(" %s\n   ", regs->pc);
> > > >
> > > >      /* Bounds for range of valid frame pointer. */
> > > > -    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > > > +    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
> > > >      high = (low & ~(STACK_SIZE - 1)) +
> > > >          (STACK_SIZE - sizeof(struct cpu_info));
> > > >
> > > > @@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >              break;
> > > >          {
> > > >              /* Ordinary stack frame. */
> > > > -            frame = (uint32_t *)next;
> > > > +            frame = (register_t *)next;
> > > >              next  = frame[-1];
> > > >              addr  = frame[0];
> > > >          }
> > > > @@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >          printk("[<%p>]", _p(addr));
> > > >          print_symbol(" %s\n   ", addr);
> > > >
> > > > -        low = (uint32_t)&frame[1];
> > > > +        low = (register_t)&frame[1];
> > > >      }
> > > >
> > > >      printk("\n");
> > > > @@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
> > > >
> > > >  void show_stack(struct cpu_user_regs *regs)
> > > >  {
> > > > -    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > > > +    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
> > > >      int i;
> > > >
> > > >      if ( guest_mode(regs) )
> > > > @@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
> > > >
> > > >  static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
> > > >  {
> > > > -    uint32_t reg, *r;
> > > > +    register_t *r;
> > > > +    uint32_t reg;
> > > >      uint32_t domid = current->domain->domain_id;
> > > >      switch ( code ) {
> > > >      case 0xe0 ... 0xef:
> > > >          reg = code - 0xe0;
> > > >          r = select_user_reg(regs, reg);
> > > > -        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
> > > > +        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> > > >                 domid, reg, *r, regs->pc);
> > > >          break;
> > > >      case 0xfd:
> > > > -        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
> > > > +        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
> > > >          break;
> > > >      case 0xfe:
> > > > -        printk("%c", (char)(regs->r0 & 0xff));
> > > > +        r = select_user_reg(regs, 0);
> > > > +        printk("%c", (char)(*r & 0xff));
> > > >          break;
> > > >      case 0xff:
> > > >          printk("DOM%d: DEBUG\n", domid);
> > > > @@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > > >                         union hsr hsr)
> > > >  {
> > > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > > +    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
> > > >
> > > >      if ( !cp32.ccvalid ) {
> > > >          dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
> > > > @@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> > > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > > >          break;
> > > >      default:
> > > > -        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
> > > > +        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
> > > >                 cp32.read ? "mrc" : "mcr",
> > > >                 cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
> > > >          panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
> > > > @@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> > > >          BUG_ON(!vtimer_emulate(regs, hsr));
> > > >          break;
> > > >      default:
> > > > -        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
> > > > +        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
> > > >                 cp64.read ? "mrrc" : "mcrr",
> > > >                 cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
> > > >          panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
> > > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > > > index 39b9775..57147d5 100644
> > > > --- a/xen/arch/arm/vgic.c
> > > > +++ b/xen/arch/arm/vgic.c
> > > > @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      struct vgic_irq_rank *rank;
> > > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > > >      int gicd_reg = REG(offset);
> > > > @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      struct vgic_irq_rank *rank;
> > > >      int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
> > > >      int gicd_reg = REG(offset);
> > > > @@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >
> > > >      case GICD_ISPENDR ... GICD_ISPENDRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
> > > >          return 0;
> > > >
> > > >      case GICD_ICPENDR ... GICD_ICPENDRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
> > > >          return 0;
> > > >
> > > > @@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >
> > > >      case GICD_SGIR:
> > > >          if ( dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
> > > > +        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
> > > >                 *r, gicd_reg - GICD_ICFGR);
> > > >          return 0;
> > > >
> > > >      case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
> > > >          return 0;
> > > >
> > > >      case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
> > > >          if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
> > > > -        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
> > > > +        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
> > > >                 dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
> > > >          return 0;
> > > >
> > > > @@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >          goto write_ignore;
> > > >
> > > >      default:
> > > > -        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > > +        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > > >                 dabt.reg, *r, offset);
> > > >          return 0;
> > > >      }
> > > >
> > > >  bad_width:
> > > > -    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
> > > > +    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
> > > >             dabt.size, dabt.reg, *r, offset);
> > > >      domain_crash_synchronous();
> > > >      return 0;
> > > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > > > index 7dcee90..db5094e 100644
> > > > --- a/xen/arch/arm/vpl011.c
> > > > +++ b/xen/arch/arm/vpl011.c
> > > > @@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      int offset = (int)(info->gpa - UART0_START);
> > > >
> > > >      switch ( offset )
> > > > @@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >  {
> > > >      struct hsr_dabt dabt = info->dabt;
> > > >      struct cpu_user_regs *regs = guest_cpu_user_regs();
> > > > -    uint32_t *r = select_user_reg(regs, dabt.reg);
> > > > +    register_t *r = select_user_reg(regs, dabt.reg);
> > > >      int offset = (int)(info->gpa - UART0_START);
> > > >
> > > >      switch ( offset )
> > > > @@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
> > > >          /* Silently ignore */
> > > >          return 1;
> > > >      default:
> > > > -        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
> > > > +        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
> > > >                 dabt.reg, *r, offset);
> > > >          domain_crash_synchronous();
> > > >      }
> > > > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> > > > index 85201b5..291b87e 100644
> > > > --- a/xen/arch/arm/vtimer.c
> > > > +++ b/xen/arch/arm/vtimer.c
> > > > @@ -99,7 +99,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
> > > >  {
> > > >      struct vcpu *v = current;
> > > >      struct hsr_cp32 cp32 = hsr.cp32;
> > > > -    uint32_t *r = select_user_reg(regs, cp32.reg);
> > > > +    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
> > > >      s_time_t now;
> > > >
> > > >      switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > > > @@ -151,8 +151,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
> > > >  {
> > > >      struct vcpu *v = current;
> > > >      struct hsr_cp64 cp64 = hsr.cp64;
> > > > -    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
> > > > -    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
> > > > +    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
> > > > +    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
> > > >      uint64_t ticks;
> > > >      s_time_t now;
> > > >
> > > > diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
> > > > index 7486944..a723f92 100644
> > > > --- a/xen/include/asm-arm/regs.h
> > > > +++ b/xen/include/asm-arm/regs.h
> > > > @@ -34,7 +34,7 @@
> > > >   * Returns a pointer to the given register value in regs, taking the
> > > >   * processor mode (CPSR) into account.
> > > >   */
> > > > -extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > > > +extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
> > > >
> > > >  #endif /* __ARM_REGS_H__ */
> > > >  /*
> > > > diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
> > > > index d3e16d8..9ca32f1 100644
> > > > --- a/xen/include/asm-arm/types.h
> > > > +++ b/xen/include/asm-arm/types.h
> > > > @@ -41,6 +41,8 @@ typedef u32 vaddr_t;
> > > >  typedef u64 paddr_t;
> > > >  #define INVALID_PADDR (~0ULL)
> > > >  #define PRIpaddr "016llx"
> > > > +typedef u32 register_t;
> > > > +#define PRIregister "x"
> > > >  #elif defined (CONFIG_ARM_64)
> > > >  typedef signed long s64;
> > > >  typedef unsigned long u64;
> > > > @@ -49,6 +51,8 @@ typedef u64 vaddr_t;
> > > >  typedef u64 paddr_t;
> > > >  #define INVALID_PADDR (~0UL)
> > > >  #define PRIpaddr "016lx"
> > > > +typedef u64 register_t;
> > > > +#define PRIregister "lx"
> > > >  #endif
> > > >
> > > >  typedef unsigned long size_t;
> > > > --
> > > > 1.7.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 Feb 21 16:57:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:57: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 1U8ZSO-0002NF-2m; Thu, 21 Feb 2013 16:57: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 1U8ZSM-0002NA-I8
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:57:14 +0000
Received: from [85.158.143.99:61850] by server-3.bemta-4.messagelabs.com id
	48/DB-02186-9E156215; Thu, 21 Feb 2013 16:57:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361465831!18823920!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12599 invoked from network); 21 Feb 2013 16:57:12 -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;
	21 Feb 2013 16:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8358663"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:56:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:56:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8ZRo-0000Ov-IX;
	Thu, 21 Feb 2013 16:56:40 +0000
Date: Thu, 21 Feb 2013 16:56:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360857591-24979-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302211654560.22997@kaball.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
	<1360857591-24979-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
 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>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> Also define __arm__ARM32 as required.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
> v2: s/x86_32/arm32/ in the right place
>     s/__arm__ARM32/__arm___ARM32/
>     Update gitignore

It looks OK to me

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  .gitignore                               |    2 +-
>  tools/include/xen-foreign/Makefile       |    4 ++--
>  tools/include/xen-foreign/mkheader.py    |    6 +++++-
>  tools/include/xen-foreign/reference.size |    2 +-
>  4 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 125a582..73c5b77 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -363,7 +363,7 @@ tools/include/xen-foreign/checker.c
>  tools/include/xen-foreign/structs.pyc
>  tools/include/xen-foreign/x86_32.h
>  tools/include/xen-foreign/x86_64.h
> -tools/include/xen-foreign/arm.h
> +tools/include/xen-foreign/arm32.h
>  
>  .git
>  tools/misc/xen-hptool
> diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
> index cfaf790..5bc2d46 100644
> --- a/tools/include/xen-foreign/Makefile
> +++ b/tools/include/xen-foreign/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  
>  ROOT = $(XEN_ROOT)/xen/include/public
>  
> -architectures := arm x86_32 x86_64
> +architectures := arm32 x86_32 x86_64
>  headers := $(patsubst %, %.h, $(architectures))
>  
>  .PHONY: all clean check-headers
> @@ -22,7 +22,7 @@ check-headers: checker
>  	diff -u reference.size tmp.size
>  	rm tmp.size
>  
> -arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
> +arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
>  	$(PYTHON) $< $* $@ $(filter %.h,$^)
>  
>  x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..eee28f3 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -17,11 +17,15 @@ header = {};
>  footer = {};
>  
>  #arm
> -inttypes["arm"] = {
> +inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
>  };
> +header["arm32"] = """
> +#define __arm___ARM32 1
> +""";
> +
>  
>  # x86_32
>  inttypes["x86_32"] = {
> diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
> index a2cbfd6..9f1bfac 100644
> --- a/tools/include/xen-foreign/reference.size
> +++ b/tools/include/xen-foreign/reference.size
> @@ -1,5 +1,5 @@
>  
> -structs                   |     arm  x86_32  x86_64
> +structs                   |   arm32  x86_32  x86_64
>  
>  start_info                |       -    1112    1168
>  trap_info                 |       -       8      16
> -- 
> 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 Thu Feb 21 16:57:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 16:57: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 1U8ZSO-0002NF-2m; Thu, 21 Feb 2013 16:57: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 1U8ZSM-0002NA-I8
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 16:57:14 +0000
Received: from [85.158.143.99:61850] by server-3.bemta-4.messagelabs.com id
	48/DB-02186-9E156215; Thu, 21 Feb 2013 16:57:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361465831!18823920!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12599 invoked from network); 21 Feb 2013 16:57:12 -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;
	21 Feb 2013 16:57:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8358663"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 16:56:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 11:56:40 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8ZRo-0000Ov-IX;
	Thu, 21 Feb 2013 16:56:40 +0000
Date: Thu, 21 Feb 2013 16:56:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1360857591-24979-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302211654560.22997@kaball.uk.xensource.com>
References: <1360857557.20449.436.camel@zakaz.uk.xensource.com>
	<1360857591-24979-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/4] tools: s/arm/arm32/ in foreign header
 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>
Content-Type: text/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, 14 Feb 2013, Ian Campbell wrote:
> Also define __arm__ARM32 as required.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> ---
> v2: s/x86_32/arm32/ in the right place
>     s/__arm__ARM32/__arm___ARM32/
>     Update gitignore

It looks OK to me

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  .gitignore                               |    2 +-
>  tools/include/xen-foreign/Makefile       |    4 ++--
>  tools/include/xen-foreign/mkheader.py    |    6 +++++-
>  tools/include/xen-foreign/reference.size |    2 +-
>  4 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 125a582..73c5b77 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -363,7 +363,7 @@ tools/include/xen-foreign/checker.c
>  tools/include/xen-foreign/structs.pyc
>  tools/include/xen-foreign/x86_32.h
>  tools/include/xen-foreign/x86_64.h
> -tools/include/xen-foreign/arm.h
> +tools/include/xen-foreign/arm32.h
>  
>  .git
>  tools/misc/xen-hptool
> diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
> index cfaf790..5bc2d46 100644
> --- a/tools/include/xen-foreign/Makefile
> +++ b/tools/include/xen-foreign/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  
>  ROOT = $(XEN_ROOT)/xen/include/public
>  
> -architectures := arm x86_32 x86_64
> +architectures := arm32 x86_32 x86_64
>  headers := $(patsubst %, %.h, $(architectures))
>  
>  .PHONY: all clean check-headers
> @@ -22,7 +22,7 @@ check-headers: checker
>  	diff -u reference.size tmp.size
>  	rm tmp.size
>  
> -arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
> +arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
>  	$(PYTHON) $< $* $@ $(filter %.h,$^)
>  
>  x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..eee28f3 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -17,11 +17,15 @@ header = {};
>  footer = {};
>  
>  #arm
> -inttypes["arm"] = {
> +inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
>  };
> +header["arm32"] = """
> +#define __arm___ARM32 1
> +""";
> +
>  
>  # x86_32
>  inttypes["x86_32"] = {
> diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
> index a2cbfd6..9f1bfac 100644
> --- a/tools/include/xen-foreign/reference.size
> +++ b/tools/include/xen-foreign/reference.size
> @@ -1,5 +1,5 @@
>  
> -structs                   |     arm  x86_32  x86_64
> +structs                   |   arm32  x86_32  x86_64
>  
>  start_info                |       -    1112    1168
>  trap_info                 |       -       8      16
> -- 
> 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 Thu Feb 21 17:11:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:11: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 1U8Zfb-0002nN-Er; Thu, 21 Feb 2013 17:10:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U8ZfZ-0002nI-Oj
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:10:53 +0000
Received: from [85.158.137.99:56898] by server-13.bemta-3.messagelabs.com id
	DB/3E-20653-C1556215; Thu, 21 Feb 2013 17:10:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361466629!17281560!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7014 invoked from network); 21 Feb 2013 17:10:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8362806"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:10:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:10:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U8ZfA-0000bo-1x;
	Thu, 21 Feb 2013 17:10:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:10:28 +0000
Message-ID: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.8.1.2
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	jaceksburghardt@gmail.com
Subject: [Xen-devel] [PATCH] tools: disable docs for QEMU 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

Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
disable it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/Makefile b/tools/Makefile
index 2ca43b9..bea1489 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -197,6 +197,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 		--bindir=$(LIBEXEC) \
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
+		--disable-docs \
 		--python=$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) all
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:11:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:11: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 1U8Zfb-0002nN-Er; Thu, 21 Feb 2013 17:10:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1U8ZfZ-0002nI-Oj
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:10:53 +0000
Received: from [85.158.137.99:56898] by server-13.bemta-3.messagelabs.com id
	DB/3E-20653-C1556215; Thu, 21 Feb 2013 17:10:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361466629!17281560!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7014 invoked from network); 21 Feb 2013 17:10:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8362806"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:10:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:10:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U8ZfA-0000bo-1x;
	Thu, 21 Feb 2013 17:10:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:10:28 +0000
Message-ID: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.8.1.2
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.jackson@eu.citrix.com,
	jaceksburghardt@gmail.com
Subject: [Xen-devel] [PATCH] tools: disable docs for QEMU 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

Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
disable it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/Makefile b/tools/Makefile
index 2ca43b9..bea1489 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -197,6 +197,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 		--bindir=$(LIBEXEC) \
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--disable-kvm \
+		--disable-docs \
 		--python=$(PYTHON) \
 		$(IOEMU_CONFIGURE_CROSS); \
 	$(MAKE) all
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:12:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:12: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 1U8Zga-00034Z-HR; Thu, 21 Feb 2013 17:11:56 +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 1U8ZgZ-00034Q-B7
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:11:55 +0000
Received: from [85.158.139.83:64252] by server-15.bemta-5.messagelabs.com id
	62/B6-18914-A5556215; Thu, 21 Feb 2013 17:11:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361466711!24441836!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3105 invoked from network); 21 Feb 2013 17:11:53 -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;
	21 Feb 2013 17:11:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8363122"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:11:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:11:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8ZgT-0000dS-Py;
	Thu, 21 Feb 2013 17:11:49 +0000
Date: Thu, 21 Feb 2013 17:11:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361360886-2956-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302211711340.22997@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361360886-2956-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v5] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 20 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> Changes since V4
>   Rebase onto v3.8
>   Fix wording of comment
>   Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
>   sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++++++
>  arch/x86/include/asm/xen/events.h |    3 +
>  drivers/xen/events.c              |  115 +++++++++++++++++++++---------------
>  include/xen/interface/xen.h       |    8 +-
>  4 files changed, 96 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>         return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
> 
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +       xen_ulong_t oldval;
> +       unsigned int tmp;
> +
> +       wmb();
> +       asm volatile("@ xchg_xen_ulong\n"
> +               "1:     ldrexd  %0, %H0, [%3]\n"
> +               "       strexd  %1, %2, %H2, [%3]\n"
> +               "       teq     %1, #0\n"
> +               "       bne     1b"
> +               : "=&r" (oldval), "=&r" (tmp)
> +               : "r" (val), "r" (ptr)
> +               : "memory", "cc");
> +       return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index cc146d5..ca842f2 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>         return raw_irqs_disabled_flags(regs->flags);
>  }
> 
> +/* No need for a barrier -- XCHG is a barrier on x86. */
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 74d77df..dfd62b5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
> 
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +/*
> + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> + * careful to only use bitops which allow for this (e.g
> + * test_bit/find_first_bit and friends but not __ffs) and to pass
> + * BITS_PER_EVTCHN_WORD as the bitmask length.
> + */
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +/*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +/* Find the first set bit in a evtchn mask */
> +#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>                       cpu_evtchn_mask);
> 
>  /* Xen will never allocate port zero for any purpose. */
> @@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
>         return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
> 
> -static inline unsigned long active_evtchns(unsigned int cpu,
> -                                          struct shared_info *sh,
> -                                          unsigned int idx)
> +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> +                                        struct shared_info *sh,
> +                                        unsigned int idx)
>  {
>         return sh->evtchn_pending[idx] &
>                 per_cpu(cpu_evtchn_mask, cpu)[idx] &
> @@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>         cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
>  #endif
> 
> -       clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -       set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> +       clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> +       set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
> 
>         info_for_irq(irq)->cpu = cpu;
>  }
> @@ -339,19 +354,19 @@ static void init_evtchn_cpu_bindings(void)
>  static inline void clear_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       sync_clear_bit(port, &s->evtchn_pending[0]);
> +       sync_clear_bit(port, BM(&s->evtchn_pending[0]));
>  }
> 
>  static inline void set_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       sync_set_bit(port, &s->evtchn_pending[0]);
> +       sync_set_bit(port, BM(&s->evtchn_pending[0]));
>  }
> 
>  static inline int test_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       return sync_test_bit(port, &s->evtchn_pending[0]);
> +       return sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  }
> 
> 
> @@ -375,7 +390,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  static void mask_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       sync_set_bit(port, &s->evtchn_mask[0]);
> +       sync_set_bit(port, BM(&s->evtchn_mask[0]));
>  }
> 
>  static void unmask_evtchn(int port)
> @@ -389,7 +404,7 @@ static void unmask_evtchn(int port)
>         if (unlikely((cpu != cpu_from_evtchn(port))))
>                 do_hypercall = 1;
>         else
> -               evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> +               evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
> 
>         if (unlikely(evtchn_pending && xen_hvm_domain()))
>                 do_hypercall = 1;
> @@ -403,7 +418,7 @@ static void unmask_evtchn(int port)
>         } else {
>                 struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> 
> -               sync_clear_bit(port, &s->evtchn_mask[0]);
> +               sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> 
>                 /*
>                  * The following is basically the equivalent of
> @@ -411,8 +426,8 @@ static void unmask_evtchn(int port)
>                  * the interrupt edge' if the channel is masked.
>                  */
>                 if (evtchn_pending &&
> -                   !sync_test_and_set_bit(port / BITS_PER_LONG,
> -                                          &vcpu_info->evtchn_pending_sel))
> +                   !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> +                                          BM(&vcpu_info->evtchn_pending_sel)))
>                         vcpu_info->evtchn_upcall_pending = 1;
>         }
> 
> @@ -1189,7 +1204,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
>         struct shared_info *sh = HYPERVISOR_shared_info;
>         int cpu = smp_processor_id();
> -       unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +       xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
>         int i;
>         unsigned long flags;
>         static DEFINE_SPINLOCK(debug_lock);
> @@ -1205,7 +1220,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>                 pending = (get_irq_regs() && i == cpu)
>                         ? xen_irqs_disabled(get_irq_regs())
>                         : v->evtchn_upcall_mask;
> -               printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> +               printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
>                        pending, v->evtchn_upcall_pending,
>                        (int)(sizeof(v->evtchn_pending_sel)*2),
>                        v->evtchn_pending_sel);
> @@ -1214,49 +1229,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> 
>         printk("\npending:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -               printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> +               printk("%0*"PRI_xen_ulong"%s",
> +                      (int)sizeof(sh->evtchn_pending[0])*2,
>                        sh->evtchn_pending[i],
>                        i % 8 == 0 ? "\n   " : " ");
>         printk("\nglobal mask:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -               printk("%0*lx%s",
> +               printk("%0*"PRI_xen_ulong"%s",
>                        (int)(sizeof(sh->evtchn_mask[0])*2),
>                        sh->evtchn_mask[i],
>                        i % 8 == 0 ? "\n   " : " ");
> 
>         printk("\nglobally unmasked:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -               printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +               printk("%0*"PRI_xen_ulong"%s",
> +                      (int)(sizeof(sh->evtchn_mask[0])*2),
>                        sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
>                        i % 8 == 0 ? "\n   " : " ");
> 
>         printk("\nlocal cpu%d mask:\n   ", cpu);
> -       for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> -               printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> +       for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> +               printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
>                        cpu_evtchn[i],
>                        i % 8 == 0 ? "\n   " : " ");
> 
>         printk("\nlocally unmasked:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> -               unsigned long pending = sh->evtchn_pending[i]
> +               xen_ulong_t pending = sh->evtchn_pending[i]
>                         & ~sh->evtchn_mask[i]
>                         & cpu_evtchn[i];
> -               printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +               printk("%0*"PRI_xen_ulong"%s",
> +                      (int)(sizeof(sh->evtchn_mask[0])*2),
>                        pending, i % 8 == 0 ? "\n   " : " ");
>         }
> 
>         printk("\npending list:\n");
>         for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -               if (sync_test_bit(i, sh->evtchn_pending)) {
> -                       int word_idx = i / BITS_PER_LONG;
> +               if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> +                       int word_idx = i / BITS_PER_EVTCHN_WORD;
>                         printk("  %d: event %d -> irq %d%s%s%s\n",
>                                cpu_from_evtchn(i), i,
>                                evtchn_to_irq[i],
> -                              sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +                              sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
>                                              ? "" : " l2-clear",
> -                              !sync_test_bit(i, sh->evtchn_mask)
> +                              !sync_test_bit(i, BM(sh->evtchn_mask))
>                                              ? "" : " globally-masked",
> -                              sync_test_bit(i, cpu_evtchn)
> +                              sync_test_bit(i, BM(cpu_evtchn))
>                                              ? "" : " locally-masked");
>                 }
>         }
> @@ -1273,7 +1291,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>  /*
>   * Mask out the i least significant bits of w
>   */
> -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
> 
>  /*
>   * Search the CPUs pending events bitmasks.  For each one found, map
> @@ -1295,18 +1313,19 @@ static void __xen_evtchn_do_upcall(void)
>         unsigned count;
> 
>         do {
> -               unsigned long pending_words;
> +               xen_ulong_t pending_words;
> 
>                 vcpu_info->evtchn_upcall_pending = 0;
> 
>                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
>                         goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -               /* Clear master flag /before/ clearing selector flag. */
> -               wmb();
> -#endif
> -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +               /*
> +                * Master flag must be cleared /before/ clearing
> +                * selector flag. xchg_xen_ulong must contain an
> +                * appropriate barrier.
> +                */
> +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
>                 start_word_idx = __this_cpu_read(current_word_idx);
>                 start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1333,8 @@ static void __xen_evtchn_do_upcall(void)
>                 word_idx = start_word_idx;
> 
>                 for (i = 0; pending_words != 0; i++) {
> -                       unsigned long pending_bits;
> -                       unsigned long words;
> +                       xen_ulong_t pending_bits;
> +                       xen_ulong_t words;
> 
>                         words = MASK_LSBS(pending_words, word_idx);
> 
> @@ -1327,7 +1346,7 @@ static void __xen_evtchn_do_upcall(void)
>                                 bit_idx = 0;
>                                 continue;
>                         }
> -                       word_idx = __ffs(words);
> +                       word_idx = EVTCHN_FIRST_BIT(words);
> 
>                         pending_bits = active_evtchns(cpu, s, word_idx);
>                         bit_idx = 0; /* usually scan entire word from start */
> @@ -1342,7 +1361,7 @@ static void __xen_evtchn_do_upcall(void)
>                         }
> 
>                         do {
> -                               unsigned long bits;
> +                               xen_ulong_t bits;
>                                 int port, irq;
>                                 struct irq_desc *desc;
> 
> @@ -1352,10 +1371,10 @@ static void __xen_evtchn_do_upcall(void)
>                                 if (bits == 0)
>                                         break;
> 
> -                               bit_idx = __ffs(bits);
> +                               bit_idx = EVTCHN_FIRST_BIT(bits);
> 
>                                 /* Process port. */
> -                               port = (word_idx * BITS_PER_LONG) + bit_idx;
> +                               port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
>                                 irq = evtchn_to_irq[port];
> 
>                                 if (irq != -1) {
> @@ -1364,12 +1383,12 @@ static void __xen_evtchn_do_upcall(void)
>                                                 generic_handle_irq_desc(irq, desc);
>                                 }
> 
> -                               bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +                               bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
> 
>                                 /* Next caller starts at last processed + 1 */
>                                 __this_cpu_write(current_word_idx,
>                                                  bit_idx ? word_idx :
> -                                                (word_idx+1) % BITS_PER_LONG);
> +                                                (word_idx+1) % BITS_PER_EVTCHN_WORD);
>                                 __this_cpu_write(current_bit_idx, bit_idx);
>                         } while (bit_idx != 0);
> 
> @@ -1377,7 +1396,7 @@ static void __xen_evtchn_do_upcall(void)
>                         if ((word_idx != start_word_idx) || (i != 0))
>                                 pending_words &= ~(1UL << word_idx);
> 
> -                       word_idx = (word_idx + 1) % BITS_PER_LONG;
> +                       word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
>                 }
> 
>                 BUG_ON(!irqs_disabled());
> @@ -1487,8 +1506,8 @@ int resend_irq_on_evtchn(unsigned int irq)
>         if (!VALID_EVTCHN(evtchn))
>                 return 1;
> 
> -       masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> -       sync_set_bit(evtchn, s->evtchn_pending);
> +       masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> +       sync_set_bit(evtchn, BM(s->evtchn_pending));
>         if (!masked)
>                 unmask_evtchn(evtchn);
> 
> @@ -1536,8 +1555,8 @@ static int retrigger_dynirq(struct irq_data *data)
>         if (VALID_EVTCHN(evtchn)) {
>                 int masked;
> 
> -               masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> -               sync_set_bit(evtchn, sh->evtchn_pending);
> +               masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> +               sync_set_bit(evtchn, BM(sh->evtchn_pending));
>                 if (!masked)
>                         unmask_evtchn(evtchn);
>                 ret = 1;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 5d6c272..a9075df 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
> 
>  struct vcpu_time_info {
>         /*
> @@ -341,7 +341,7 @@ struct vcpu_info {
>          */
>         uint8_t evtchn_upcall_pending;
>         uint8_t evtchn_upcall_mask;
> -       unsigned long evtchn_pending_sel;
> +       xen_ulong_t evtchn_pending_sel;
>         struct arch_vcpu_info arch;
>         struct pvclock_vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -384,8 +384,8 @@ struct shared_info {
>          * per-vcpu selector word to be set. Each bit in the selector covers a
>          * 'C long' in the PENDING bitfield array.
>          */
> -       unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -       unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +       xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +       xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
> 
>         /*
>          * Wallclock time: updated only by control software. Guests should base
> --
> 1.7.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 Feb 21 17:12:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:12: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 1U8Zga-00034Z-HR; Thu, 21 Feb 2013 17:11:56 +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 1U8ZgZ-00034Q-B7
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:11:55 +0000
Received: from [85.158.139.83:64252] by server-15.bemta-5.messagelabs.com id
	62/B6-18914-A5556215; Thu, 21 Feb 2013 17:11:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361466711!24441836!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3105 invoked from network); 21 Feb 2013 17:11:53 -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;
	21 Feb 2013 17:11:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8363122"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:11:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:11:49 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8ZgT-0000dS-Py;
	Thu, 21 Feb 2013 17:11:49 +0000
Date: Thu, 21 Feb 2013 17:11:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1361360886-2956-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1302211711340.22997@kaball.uk.xensource.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361360886-2956-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH LINUX v5] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 20 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> Changes since V4
>   Rebase onto v3.8
>   Fix wording of comment
>   Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
>   sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++++++
>  arch/x86/include/asm/xen/events.h |    3 +
>  drivers/xen/events.c              |  115 +++++++++++++++++++++---------------
>  include/xen/interface/xen.h       |    8 +-
>  4 files changed, 96 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>         return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
> 
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +       xen_ulong_t oldval;
> +       unsigned int tmp;
> +
> +       wmb();
> +       asm volatile("@ xchg_xen_ulong\n"
> +               "1:     ldrexd  %0, %H0, [%3]\n"
> +               "       strexd  %1, %2, %H2, [%3]\n"
> +               "       teq     %1, #0\n"
> +               "       bne     1b"
> +               : "=&r" (oldval), "=&r" (tmp)
> +               : "r" (val), "r" (ptr)
> +               : "memory", "cc");
> +       return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h b/arch/x86/include/asm/xen/events.h
> index cc146d5..ca842f2 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
>         return raw_irqs_disabled_flags(regs->flags);
>  }
> 
> +/* No need for a barrier -- XCHG is a barrier on x86. */
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 74d77df..dfd62b5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
> 
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +/*
> + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> + * careful to only use bitops which allow for this (e.g
> + * test_bit/find_first_bit and friends but not __ffs) and to pass
> + * BITS_PER_EVTCHN_WORD as the bitmask length.
> + */
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +/*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +/* Find the first set bit in a evtchn mask */
> +#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>                       cpu_evtchn_mask);
> 
>  /* Xen will never allocate port zero for any purpose. */
> @@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
>         return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
> 
> -static inline unsigned long active_evtchns(unsigned int cpu,
> -                                          struct shared_info *sh,
> -                                          unsigned int idx)
> +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> +                                        struct shared_info *sh,
> +                                        unsigned int idx)
>  {
>         return sh->evtchn_pending[idx] &
>                 per_cpu(cpu_evtchn_mask, cpu)[idx] &
> @@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>         cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
>  #endif
> 
> -       clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -       set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
> +       clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
> +       set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
> 
>         info_for_irq(irq)->cpu = cpu;
>  }
> @@ -339,19 +354,19 @@ static void init_evtchn_cpu_bindings(void)
>  static inline void clear_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       sync_clear_bit(port, &s->evtchn_pending[0]);
> +       sync_clear_bit(port, BM(&s->evtchn_pending[0]));
>  }
> 
>  static inline void set_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       sync_set_bit(port, &s->evtchn_pending[0]);
> +       sync_set_bit(port, BM(&s->evtchn_pending[0]));
>  }
> 
>  static inline int test_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       return sync_test_bit(port, &s->evtchn_pending[0]);
> +       return sync_test_bit(port, BM(&s->evtchn_pending[0]));
>  }
> 
> 
> @@ -375,7 +390,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
>  static void mask_evtchn(int port)
>  {
>         struct shared_info *s = HYPERVISOR_shared_info;
> -       sync_set_bit(port, &s->evtchn_mask[0]);
> +       sync_set_bit(port, BM(&s->evtchn_mask[0]));
>  }
> 
>  static void unmask_evtchn(int port)
> @@ -389,7 +404,7 @@ static void unmask_evtchn(int port)
>         if (unlikely((cpu != cpu_from_evtchn(port))))
>                 do_hypercall = 1;
>         else
> -               evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
> +               evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
> 
>         if (unlikely(evtchn_pending && xen_hvm_domain()))
>                 do_hypercall = 1;
> @@ -403,7 +418,7 @@ static void unmask_evtchn(int port)
>         } else {
>                 struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> 
> -               sync_clear_bit(port, &s->evtchn_mask[0]);
> +               sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> 
>                 /*
>                  * The following is basically the equivalent of
> @@ -411,8 +426,8 @@ static void unmask_evtchn(int port)
>                  * the interrupt edge' if the channel is masked.
>                  */
>                 if (evtchn_pending &&
> -                   !sync_test_and_set_bit(port / BITS_PER_LONG,
> -                                          &vcpu_info->evtchn_pending_sel))
> +                   !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
> +                                          BM(&vcpu_info->evtchn_pending_sel)))
>                         vcpu_info->evtchn_upcall_pending = 1;
>         }
> 
> @@ -1189,7 +1204,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>  {
>         struct shared_info *sh = HYPERVISOR_shared_info;
>         int cpu = smp_processor_id();
> -       unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
> +       xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
>         int i;
>         unsigned long flags;
>         static DEFINE_SPINLOCK(debug_lock);
> @@ -1205,7 +1220,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
>                 pending = (get_irq_regs() && i == cpu)
>                         ? xen_irqs_disabled(get_irq_regs())
>                         : v->evtchn_upcall_mask;
> -               printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
> +               printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
>                        pending, v->evtchn_upcall_pending,
>                        (int)(sizeof(v->evtchn_pending_sel)*2),
>                        v->evtchn_pending_sel);
> @@ -1214,49 +1229,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
> 
>         printk("\npending:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
> -               printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
> +               printk("%0*"PRI_xen_ulong"%s",
> +                      (int)sizeof(sh->evtchn_pending[0])*2,
>                        sh->evtchn_pending[i],
>                        i % 8 == 0 ? "\n   " : " ");
>         printk("\nglobal mask:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -               printk("%0*lx%s",
> +               printk("%0*"PRI_xen_ulong"%s",
>                        (int)(sizeof(sh->evtchn_mask[0])*2),
>                        sh->evtchn_mask[i],
>                        i % 8 == 0 ? "\n   " : " ");
> 
>         printk("\nglobally unmasked:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
> -               printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +               printk("%0*"PRI_xen_ulong"%s",
> +                      (int)(sizeof(sh->evtchn_mask[0])*2),
>                        sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
>                        i % 8 == 0 ? "\n   " : " ");
> 
>         printk("\nlocal cpu%d mask:\n   ", cpu);
> -       for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
> -               printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
> +       for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
> +               printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
>                        cpu_evtchn[i],
>                        i % 8 == 0 ? "\n   " : " ");
> 
>         printk("\nlocally unmasked:\n   ");
>         for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
> -               unsigned long pending = sh->evtchn_pending[i]
> +               xen_ulong_t pending = sh->evtchn_pending[i]
>                         & ~sh->evtchn_mask[i]
>                         & cpu_evtchn[i];
> -               printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
> +               printk("%0*"PRI_xen_ulong"%s",
> +                      (int)(sizeof(sh->evtchn_mask[0])*2),
>                        pending, i % 8 == 0 ? "\n   " : " ");
>         }
> 
>         printk("\npending list:\n");
>         for (i = 0; i < NR_EVENT_CHANNELS; i++) {
> -               if (sync_test_bit(i, sh->evtchn_pending)) {
> -                       int word_idx = i / BITS_PER_LONG;
> +               if (sync_test_bit(i, BM(sh->evtchn_pending))) {
> +                       int word_idx = i / BITS_PER_EVTCHN_WORD;
>                         printk("  %d: event %d -> irq %d%s%s%s\n",
>                                cpu_from_evtchn(i), i,
>                                evtchn_to_irq[i],
> -                              sync_test_bit(word_idx, &v->evtchn_pending_sel)
> +                              sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
>                                              ? "" : " l2-clear",
> -                              !sync_test_bit(i, sh->evtchn_mask)
> +                              !sync_test_bit(i, BM(sh->evtchn_mask))
>                                              ? "" : " globally-masked",
> -                              sync_test_bit(i, cpu_evtchn)
> +                              sync_test_bit(i, BM(cpu_evtchn))
>                                              ? "" : " locally-masked");
>                 }
>         }
> @@ -1273,7 +1291,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
>  /*
>   * Mask out the i least significant bits of w
>   */
> -#define MASK_LSBS(w, i) (w & ((~0UL) << i))
> +#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
> 
>  /*
>   * Search the CPUs pending events bitmasks.  For each one found, map
> @@ -1295,18 +1313,19 @@ static void __xen_evtchn_do_upcall(void)
>         unsigned count;
> 
>         do {
> -               unsigned long pending_words;
> +               xen_ulong_t pending_words;
> 
>                 vcpu_info->evtchn_upcall_pending = 0;
> 
>                 if (__this_cpu_inc_return(xed_nesting_count) - 1)
>                         goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -               /* Clear master flag /before/ clearing selector flag. */
> -               wmb();
> -#endif
> -               pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +               /*
> +                * Master flag must be cleared /before/ clearing
> +                * selector flag. xchg_xen_ulong must contain an
> +                * appropriate barrier.
> +                */
> +               pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
>                 start_word_idx = __this_cpu_read(current_word_idx);
>                 start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1333,8 @@ static void __xen_evtchn_do_upcall(void)
>                 word_idx = start_word_idx;
> 
>                 for (i = 0; pending_words != 0; i++) {
> -                       unsigned long pending_bits;
> -                       unsigned long words;
> +                       xen_ulong_t pending_bits;
> +                       xen_ulong_t words;
> 
>                         words = MASK_LSBS(pending_words, word_idx);
> 
> @@ -1327,7 +1346,7 @@ static void __xen_evtchn_do_upcall(void)
>                                 bit_idx = 0;
>                                 continue;
>                         }
> -                       word_idx = __ffs(words);
> +                       word_idx = EVTCHN_FIRST_BIT(words);
> 
>                         pending_bits = active_evtchns(cpu, s, word_idx);
>                         bit_idx = 0; /* usually scan entire word from start */
> @@ -1342,7 +1361,7 @@ static void __xen_evtchn_do_upcall(void)
>                         }
> 
>                         do {
> -                               unsigned long bits;
> +                               xen_ulong_t bits;
>                                 int port, irq;
>                                 struct irq_desc *desc;
> 
> @@ -1352,10 +1371,10 @@ static void __xen_evtchn_do_upcall(void)
>                                 if (bits == 0)
>                                         break;
> 
> -                               bit_idx = __ffs(bits);
> +                               bit_idx = EVTCHN_FIRST_BIT(bits);
> 
>                                 /* Process port. */
> -                               port = (word_idx * BITS_PER_LONG) + bit_idx;
> +                               port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
>                                 irq = evtchn_to_irq[port];
> 
>                                 if (irq != -1) {
> @@ -1364,12 +1383,12 @@ static void __xen_evtchn_do_upcall(void)
>                                                 generic_handle_irq_desc(irq, desc);
>                                 }
> 
> -                               bit_idx = (bit_idx + 1) % BITS_PER_LONG;
> +                               bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
> 
>                                 /* Next caller starts at last processed + 1 */
>                                 __this_cpu_write(current_word_idx,
>                                                  bit_idx ? word_idx :
> -                                                (word_idx+1) % BITS_PER_LONG);
> +                                                (word_idx+1) % BITS_PER_EVTCHN_WORD);
>                                 __this_cpu_write(current_bit_idx, bit_idx);
>                         } while (bit_idx != 0);
> 
> @@ -1377,7 +1396,7 @@ static void __xen_evtchn_do_upcall(void)
>                         if ((word_idx != start_word_idx) || (i != 0))
>                                 pending_words &= ~(1UL << word_idx);
> 
> -                       word_idx = (word_idx + 1) % BITS_PER_LONG;
> +                       word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
>                 }
> 
>                 BUG_ON(!irqs_disabled());
> @@ -1487,8 +1506,8 @@ int resend_irq_on_evtchn(unsigned int irq)
>         if (!VALID_EVTCHN(evtchn))
>                 return 1;
> 
> -       masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
> -       sync_set_bit(evtchn, s->evtchn_pending);
> +       masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
> +       sync_set_bit(evtchn, BM(s->evtchn_pending));
>         if (!masked)
>                 unmask_evtchn(evtchn);
> 
> @@ -1536,8 +1555,8 @@ static int retrigger_dynirq(struct irq_data *data)
>         if (VALID_EVTCHN(evtchn)) {
>                 int masked;
> 
> -               masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
> -               sync_set_bit(evtchn, sh->evtchn_pending);
> +               masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
> +               sync_set_bit(evtchn, BM(sh->evtchn_pending));
>                 if (!masked)
>                         unmask_evtchn(evtchn);
>                 ret = 1;
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 5d6c272..a9075df 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
> 
>  struct vcpu_time_info {
>         /*
> @@ -341,7 +341,7 @@ struct vcpu_info {
>          */
>         uint8_t evtchn_upcall_pending;
>         uint8_t evtchn_upcall_mask;
> -       unsigned long evtchn_pending_sel;
> +       xen_ulong_t evtchn_pending_sel;
>         struct arch_vcpu_info arch;
>         struct pvclock_vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -384,8 +384,8 @@ struct shared_info {
>          * per-vcpu selector word to be set. Each bit in the selector covers a
>          * 'C long' in the PENDING bitfield array.
>          */
> -       unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -       unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +       xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +       xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
> 
>         /*
>          * Wallclock time: updated only by control software. Guests should base
> --
> 1.7.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 Feb 21 17:16:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8Zkd-0003Rs-EL; Thu, 21 Feb 2013 17:16:07 +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 1U8Zkb-0003Ri-Gw
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:16:05 +0000
Received: from [85.158.139.211:41634] by server-5.bemta-5.messagelabs.com id
	B8/A3-11945-45656215; Thu, 21 Feb 2013 17:16:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361466963!18583256!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22745 invoked from network); 21 Feb 2013 17:16:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:16:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1744925"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 17: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.297.1;
	Thu, 21 Feb 2013 17:16:03 +0000
Message-ID: <1361466961.26546.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:16:01 +0000
In-Reply-To: <1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Jan
	Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>

Are you guys (un)happy with this change from the Xen & x86 side?

> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> ---
>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>  xen/include/public/xen.h              |    8 ++++----
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..57681fa 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
>  };
> +header["arm"] = """
> +#define __arm___ARM32 1
> +""";
>  
>  # x86_32
>  inttypes["x86_32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint32_t",
> +    "xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>      "unsigned long" : "__align8__ uint64_t",
>      "long"          : "__align8__ uint64_t",
>      "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>      /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>       */
>      uint8_t evtchn_upcall_pending;
>      uint8_t evtchn_upcall_mask;
> -    unsigned long evtchn_pending_sel;
> +    xen_ulong_t evtchn_pending_sel;
>      struct arch_vcpu_info arch;
>      struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>       * per-vcpu selector word to be set. Each bit in the selector covers a
>       * 'C long' in the PENDING bitfield array.
>       */
> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>      /*
>       * Wallclock time: updated only by control software. Guests should base



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:16:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8Zkd-0003Rs-EL; Thu, 21 Feb 2013 17:16:07 +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 1U8Zkb-0003Ri-Gw
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:16:05 +0000
Received: from [85.158.139.211:41634] by server-5.bemta-5.messagelabs.com id
	B8/A3-11945-45656215; Thu, 21 Feb 2013 17:16:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361466963!18583256!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzMTEx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22745 invoked from network); 21 Feb 2013 17:16:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:16:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="1744925"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Feb 2013 17: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.297.1;
	Thu, 21 Feb 2013 17:16:03 +0000
Message-ID: <1361466961.26546.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:16:01 +0000
In-Reply-To: <1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Jan
	Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>

Are you guys (un)happy with this change from the Xen & x86 side?

> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> ---
>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>  xen/include/public/xen.h              |    8 ++++----
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index d189b07..57681fa 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint64_t",
> +    "xen_ulong_t"   : "uint64_t",
>  };
> +header["arm"] = """
> +#define __arm___ARM32 1
> +""";
>  
>  # x86_32
>  inttypes["x86_32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
>      "xen_pfn_t"     : "uint32_t",
> +    "xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>      "unsigned long" : "__align8__ uint64_t",
>      "long"          : "__align8__ uint64_t",
>      "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>      /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>       */
>      uint8_t evtchn_upcall_pending;
>      uint8_t evtchn_upcall_mask;
> -    unsigned long evtchn_pending_sel;
> +    xen_ulong_t evtchn_pending_sel;
>      struct arch_vcpu_info arch;
>      struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>       * per-vcpu selector word to be set. Each bit in the selector covers a
>       * 'C long' in the PENDING bitfield array.
>       */
> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>      /*
>       * Wallclock time: updated only by control software. Guests should base



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:20:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8ZoC-0003gO-5t; Thu, 21 Feb 2013 17:19: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 1U8ZoB-0003gI-I7
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:19:47 +0000
Received: from [85.158.143.99:54164] by server-3.bemta-4.messagelabs.com id
	F9/CE-02186-23756215; Thu, 21 Feb 2013 17:19:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361467185!28631456!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10824 invoked from network); 21 Feb 2013 17:19:46 -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; 21 Feb 2013 17:19:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Zo9-0007u2-6H; Thu, 21 Feb 2013 17:19:45 +0000
Date: Thu, 21 Feb 2013 17:19:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221171945.GF24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360930007.31407.13.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360930007.31407.13.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: arm: implement cpuinfo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:06 +0000 on 15 Feb (1360930007), Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > You can also run 32-bit on the V8 model (using -C
> > cluster.cpu0.CONFIG64=0) if you comment out the ThumbEE in
> > ctxt_switch_from and ctxt_switch_to (making this dynamic is on my TODO
> > list). 
> 
> 8<-----------------------------------------------
> 
> From e45c4e4f45e72e404052629c619af8810dadd76f Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 15 Feb 2013 10:30:48 +0000
> Subject: [PATCH] xen: arm: implement cpuinfo
> 
> Use to:
> 
>  - Only context switch ThumbEE state if the processor implements it. In
>    particular the ARMv8 FastModels do not.
>  - Detect the generic timer, and therefore call identify_cpu before
>    init_xen_time.
> 
> Also improve the boot time messages a bit.
> 
> I haven't added decoding for all of the CPUID words, it seems like overkill
> for the moment.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 17:20:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8ZoC-0003gO-5t; Thu, 21 Feb 2013 17:19: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 1U8ZoB-0003gI-I7
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:19:47 +0000
Received: from [85.158.143.99:54164] by server-3.bemta-4.messagelabs.com id
	F9/CE-02186-23756215; Thu, 21 Feb 2013 17:19:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361467185!28631456!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10824 invoked from network); 21 Feb 2013 17:19:46 -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; 21 Feb 2013 17:19:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8Zo9-0007u2-6H; Thu, 21 Feb 2013 17:19:45 +0000
Date: Thu, 21 Feb 2013 17:19:45 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130221171945.GF24051@ocelot.phlegethon.org>
References: <1360860465.20449.472.camel@zakaz.uk.xensource.com>
	<1360930007.31407.13.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1360930007.31407.13.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: arm: implement cpuinfo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:06 +0000 on 15 Feb (1360930007), Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:47 +0000, Ian Campbell wrote:
> > You can also run 32-bit on the V8 model (using -C
> > cluster.cpu0.CONFIG64=0) if you comment out the ThumbEE in
> > ctxt_switch_from and ctxt_switch_to (making this dynamic is on my TODO
> > list). 
> 
> 8<-----------------------------------------------
> 
> From e45c4e4f45e72e404052629c619af8810dadd76f Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Fri, 15 Feb 2013 10:30:48 +0000
> Subject: [PATCH] xen: arm: implement cpuinfo
> 
> Use to:
> 
>  - Only context switch ThumbEE state if the processor implements it. In
>    particular the ARMv8 FastModels do not.
>  - Detect the generic timer, and therefore call identify_cpu before
>    init_xen_time.
> 
> Also improve the boot time messages a bit.
> 
> I haven't added decoding for all of the CPUID words, it seems like overkill
> for the moment.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Thu Feb 21 17:31:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:31: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 1U8ZzU-000487-Hu; Thu, 21 Feb 2013 17:31:28 +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 1U8ZzT-000482-Q0
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:31:28 +0000
Received: from [85.158.138.51:65416] by server-1.bemta-3.messagelabs.com id
	94/F9-08955-AE956215; Thu, 21 Feb 2013 17:31:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361467881!28659704!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8088 invoked from network); 21 Feb 2013 17:31:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 17:31:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (joses mo4) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h014abp1LH75Z1 ;
	Thu, 21 Feb 2013 18:31:16 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 49EB11884C; Thu, 21 Feb 2013 18:31:16 +0100 (CET)
Date: Thu, 21 Feb 2013 18:31:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221173115.GA13045@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51265C7B02000078000C0167@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 Thu, Feb 21, Jan Beulich wrote:

> What you could do to get a better understanding of when this
> happens is to add a WARN_ON() alongside the printk() (perhaps
> such that it triggers only once for each of the two different
> cases), and then let us look at the call trace.

It did not happen with xl.

Here is the output while doing xm migrate:


(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) Xen WARN at mm.c:1986
(XEN) ----[ Xen-4.3.26579-20130221.171413  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    20
(XEN) RIP:    e008:[<ffff82c4c0170fb2>] get_page+0xfb/0x151
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 7400000000000001   rbx: 7400000000000001   rcx: 0000000000000000
(XEN) rdx: 7400000000000001   rsi: 000000000000000a   rdi: ffff82c4c0280748
(XEN) rbp: ffff83036d5f7958   rsp: ffff83036d5f7908   r8:  0000000000000014
(XEN) r9:  0000000000000004   r10: 0000000000000004   r11: 0000000000000001
(XEN) r12: 0180000000000000   r13: 0000000000000000   r14: ffff83036ffef000
(XEN) r15: ffff82e0082258a0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000065e78f000   cr2: ffff8805ad260040
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff83036d5f7908:
(XEN)    0000000000000000 0180000000000000 7400000000000001 ffff82c4c01e1726
(XEN)    00000000004112c5 ffff82e0082258a0 ffff83036d5f79fc ffff83036d5f799c
(XEN)    ffff830232aa49e0 ffff830232aa49e0 ffff83036d5f79c8 ffff82c4c01e1d87
(XEN)    ffff830300000000 0000000000000086 000000026d5f7a04 00000000000190c5
(XEN)    ffff830402126000 ffffffff01000086 000000076d5f7bc0 0000000000000000
(XEN)    ffff830402126000 ffff83040225dc60 00000000000190c5 ffff83036d5f7ba0
(XEN)    ffff83036d5f7a28 ffff82c4c01098ae ffff83036d5f7a98 ffff83036d5f7ba0
(XEN)    ffff83036d5f7ab8 00000000000f03f8 000000006d5f7a08 0000000000000000
(XEN)    0000000000000240 ffff83040225dc60 0000000000000000 ffff83036d5f7ba0
(XEN)    ffff83036d5f7ae8 ffff82c4c0109e55 ffff830402296200 0000000000000086
(XEN)    0000018300000009 00000000000000fd ffff83036d5f7bb0 000082e000000000
(XEN)    ffff830402126000 ffff830402203c58 00000000002337b6 ffff830402296200
(XEN)    0000000000000000 ffff830402296200 ffff830402296200 000002406d5f7ba8
(XEN)    ffff830300000000 ffff83036d5f7bb0 000000006d5f7b68 0000000000000000
(XEN)    ffff83036d5ce000 0000000000000000 0000000000000000 ffff830402126000
(XEN)    ffff83036d5f7c28 ffff82c4c010bef0 ffff83036d5f7bc4 ffff83036d5f7bc0
(XEN)    ffff830300000001 0000000000000096 ffff83036d5f7bec ffff82c4c0319820
(XEN)    ffff83036d5f0000 ffff83036d5f0000 ffff83036d5f0000 ffff83036d5f0000
(XEN)    ffff83036d5f0000 ffff83036d5f7bc8 ffff83036d5f0000 0000000000000001
(XEN)    ffffc90010283a40 0000000000000002 ffff83036d5f7bd8 ffff82c4c0125aa4
(XEN) Xen call trace:
(XEN)    [<ffff82c4c0170fb2>] get_page+0xfb/0x151
(XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
(XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
(XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
(XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
(XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
(XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
(XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145
(XEN)
(XEN) mm.c:1983:d0 Error pfn 41144d: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1983:d0 Error pfn 4116b0: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) irq.c:375: Dom2 callback via changed to Direct Vector 0xf3
(XEN) HVM2 save: CPU
...
(XEN) HVM3 restore: VMCE_VCPU 0
(XEN) HVM3 restore: VMCE_VCPU 1
(XEN) HVM3 restore: TSC_ADJUST 0
(XEN) HVM3 restore: TSC_ADJUST 1
(XEN) mm.c:1983:d0 Error pfn 43f7d4: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) Xen WARN at mm.c:1990
(XEN) ----[ Xen-4.3.26579-20130221.171413  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    14
(XEN) RIP:    e008:[<ffff82c4c0170fdc>] get_page+0x125/0x151
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 7400000000000001   rbx: 0000000000000001   rcx: 0000000000000000
(XEN) rdx: 0000000000000001   rsi: 000000000000000a   rdi: ffff82c4c0280748
(XEN) rbp: ffff83036ff2f958   rsp: ffff83036ff2f908   r8:  000000000000000e
(XEN) r9:  0000000000000004   r10: 0000000000000004   r11: 0000000000000001
(XEN) r12: 0180000000000000   r13: 0000000000000000   r14: ffff83036ffef000
(XEN) r15: ffff82e0087efa80   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000230871000   cr2: ffff8805abd77f20
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff83036ff2f908:
(XEN)    0000000000000000 0180000000000000 0000000000000001 ffff82c4c01e1726
(XEN)    000000000043f7d4 ffff82e0087efa80 ffff83036ff2f9fc ffff83036ff2f99c
(XEN)    ffff830231fa8010 ffff830231fa8010 ffff83036ff2f9c8 ffff82c4c01e1d87
(XEN)    ffff830300000000 0000000000000086 00000002900d0604 0000000000019110
(XEN)    ffff83022fb64000 ffffffff01000048 000000076ff2fa18 0000000000000000
(XEN)    ffff83022fb64000 ffff830232319db0 0000000000019110 ffff83036ff2fba0
(XEN)    ffff83036ff2fa28 ffff82c4c01098ae ffff83036ff2fa58 ffff83036ff2fba0
(XEN)    ffff83036ff2fab8 0000000000000004 0000000000000000 0000000000000000
(XEN)    0000000000000247 ffff830232319db0 0000000000000000 ffff83036ff2fba0
(XEN)    ffff83036ff2fae8 ffff82c4c0109e55 ffff83022f019238 0000000000000000
(XEN)    ffff83036ff2fad8 0000000000000004 ffff83036ff2fbb0 000082e000000000
(XEN)    ffff83022fb64000 ffff8302325a0c58 00000000002338d7 ffff83022f019238
(XEN)    0000000000000000 ffff83022f019238 ffff83022f019238 000002476ff2fba8
(XEN)    ffff830300000000 ffff8302325a0c58 000000006d5ce000 0000000000000000
(XEN)    ffff83036d5ce000 0000000000000000 0000000000000000 ffff83022fb64000
(XEN)    ffff83036ff2fc28 ffff82c4c010bef0 ffff83036ff2fbc4 ffff83036ff2fbc0
(XEN)    ffff830300000001 0000000000000096 ffff83036ff2fbec ffff82c4c0319820
(XEN)    ffff83036ff28000 ffff83036ff28000 ffff83036ff28000 ffff83036ff28000
(XEN)    ffff83036ff28000 ffff83036ff2fbc8 ffff83036ff28000 0000000000000001
(XEN)    ffffc90010283a40 0000000000000002 ffff83036ff2fbd8 ffff82c4c0125aa4
(XEN) Xen call trace:
(XEN)    [<ffff82c4c0170fdc>] get_page+0x125/0x151
(XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
(XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
(XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
(XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
(XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
(XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
(XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145
(XEN)
(XEN) mm.c:1983:d0 Error pfn 43e646: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43f86a: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43e683: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43f31b: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43e5f0: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43f3b7: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1983:d0 Error pfn 43f87c: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) irq.c:375: Dom3 callback via changed to Direct Vector 0xf3
...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:31:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:31: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 1U8ZzU-000487-Hu; Thu, 21 Feb 2013 17:31:28 +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 1U8ZzT-000482-Q0
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:31:28 +0000
Received: from [85.158.138.51:65416] by server-1.bemta-3.messagelabs.com id
	94/F9-08955-AE956215; Thu, 21 Feb 2013 17:31:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361467881!28659704!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1Nzg3MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8088 invoked from network); 21 Feb 2013 17:31:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-174.messagelabs.com with SMTP;
	21 Feb 2013 17:31:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/UwZ5vFU8=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-080-242.pools.arcor-ip.net [84.57.80.242])
	by smtp.strato.de (joses mo4) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h014abp1LH75Z1 ;
	Thu, 21 Feb 2013 18:31:16 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 49EB11884C; Thu, 21 Feb 2013 18:31:16 +0100 (CET)
Date: Thu, 21 Feb 2013 18:31:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130221173115.GA13045@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51265C7B02000078000C0167@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 Thu, Feb 21, Jan Beulich wrote:

> What you could do to get a better understanding of when this
> happens is to add a WARN_ON() alongside the printk() (perhaps
> such that it triggers only once for each of the two different
> cases), and then let us look at the call trace.

It did not happen with xl.

Here is the output while doing xm migrate:


(XEN) HVM2 restore: VMCE_VCPU 0
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) Xen WARN at mm.c:1986
(XEN) ----[ Xen-4.3.26579-20130221.171413  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    20
(XEN) RIP:    e008:[<ffff82c4c0170fb2>] get_page+0xfb/0x151
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 7400000000000001   rbx: 7400000000000001   rcx: 0000000000000000
(XEN) rdx: 7400000000000001   rsi: 000000000000000a   rdi: ffff82c4c0280748
(XEN) rbp: ffff83036d5f7958   rsp: ffff83036d5f7908   r8:  0000000000000014
(XEN) r9:  0000000000000004   r10: 0000000000000004   r11: 0000000000000001
(XEN) r12: 0180000000000000   r13: 0000000000000000   r14: ffff83036ffef000
(XEN) r15: ffff82e0082258a0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 000000065e78f000   cr2: ffff8805ad260040
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff83036d5f7908:
(XEN)    0000000000000000 0180000000000000 7400000000000001 ffff82c4c01e1726
(XEN)    00000000004112c5 ffff82e0082258a0 ffff83036d5f79fc ffff83036d5f799c
(XEN)    ffff830232aa49e0 ffff830232aa49e0 ffff83036d5f79c8 ffff82c4c01e1d87
(XEN)    ffff830300000000 0000000000000086 000000026d5f7a04 00000000000190c5
(XEN)    ffff830402126000 ffffffff01000086 000000076d5f7bc0 0000000000000000
(XEN)    ffff830402126000 ffff83040225dc60 00000000000190c5 ffff83036d5f7ba0
(XEN)    ffff83036d5f7a28 ffff82c4c01098ae ffff83036d5f7a98 ffff83036d5f7ba0
(XEN)    ffff83036d5f7ab8 00000000000f03f8 000000006d5f7a08 0000000000000000
(XEN)    0000000000000240 ffff83040225dc60 0000000000000000 ffff83036d5f7ba0
(XEN)    ffff83036d5f7ae8 ffff82c4c0109e55 ffff830402296200 0000000000000086
(XEN)    0000018300000009 00000000000000fd ffff83036d5f7bb0 000082e000000000
(XEN)    ffff830402126000 ffff830402203c58 00000000002337b6 ffff830402296200
(XEN)    0000000000000000 ffff830402296200 ffff830402296200 000002406d5f7ba8
(XEN)    ffff830300000000 ffff83036d5f7bb0 000000006d5f7b68 0000000000000000
(XEN)    ffff83036d5ce000 0000000000000000 0000000000000000 ffff830402126000
(XEN)    ffff83036d5f7c28 ffff82c4c010bef0 ffff83036d5f7bc4 ffff83036d5f7bc0
(XEN)    ffff830300000001 0000000000000096 ffff83036d5f7bec ffff82c4c0319820
(XEN)    ffff83036d5f0000 ffff83036d5f0000 ffff83036d5f0000 ffff83036d5f0000
(XEN)    ffff83036d5f0000 ffff83036d5f7bc8 ffff83036d5f0000 0000000000000001
(XEN)    ffffc90010283a40 0000000000000002 ffff83036d5f7bd8 ffff82c4c0125aa4
(XEN) Xen call trace:
(XEN)    [<ffff82c4c0170fb2>] get_page+0xfb/0x151
(XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
(XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
(XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
(XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
(XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
(XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
(XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145
(XEN)
(XEN) mm.c:1983:d0 Error pfn 41144d: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1983:d0 Error pfn 4116b0: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) irq.c:375: Dom2 callback via changed to Direct Vector 0xf3
(XEN) HVM2 save: CPU
...
(XEN) HVM3 restore: VMCE_VCPU 0
(XEN) HVM3 restore: VMCE_VCPU 1
(XEN) HVM3 restore: TSC_ADJUST 0
(XEN) HVM3 restore: TSC_ADJUST 1
(XEN) mm.c:1983:d0 Error pfn 43f7d4: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) Xen WARN at mm.c:1990
(XEN) ----[ Xen-4.3.26579-20130221.171413  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    14
(XEN) RIP:    e008:[<ffff82c4c0170fdc>] get_page+0x125/0x151
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 7400000000000001   rbx: 0000000000000001   rcx: 0000000000000000
(XEN) rdx: 0000000000000001   rsi: 000000000000000a   rdi: ffff82c4c0280748
(XEN) rbp: ffff83036ff2f958   rsp: ffff83036ff2f908   r8:  000000000000000e
(XEN) r9:  0000000000000004   r10: 0000000000000004   r11: 0000000000000001
(XEN) r12: 0180000000000000   r13: 0000000000000000   r14: ffff83036ffef000
(XEN) r15: ffff82e0087efa80   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000230871000   cr2: ffff8805abd77f20
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff83036ff2f908:
(XEN)    0000000000000000 0180000000000000 0000000000000001 ffff82c4c01e1726
(XEN)    000000000043f7d4 ffff82e0087efa80 ffff83036ff2f9fc ffff83036ff2f99c
(XEN)    ffff830231fa8010 ffff830231fa8010 ffff83036ff2f9c8 ffff82c4c01e1d87
(XEN)    ffff830300000000 0000000000000086 00000002900d0604 0000000000019110
(XEN)    ffff83022fb64000 ffffffff01000048 000000076ff2fa18 0000000000000000
(XEN)    ffff83022fb64000 ffff830232319db0 0000000000019110 ffff83036ff2fba0
(XEN)    ffff83036ff2fa28 ffff82c4c01098ae ffff83036ff2fa58 ffff83036ff2fba0
(XEN)    ffff83036ff2fab8 0000000000000004 0000000000000000 0000000000000000
(XEN)    0000000000000247 ffff830232319db0 0000000000000000 ffff83036ff2fba0
(XEN)    ffff83036ff2fae8 ffff82c4c0109e55 ffff83022f019238 0000000000000000
(XEN)    ffff83036ff2fad8 0000000000000004 ffff83036ff2fbb0 000082e000000000
(XEN)    ffff83022fb64000 ffff8302325a0c58 00000000002338d7 ffff83022f019238
(XEN)    0000000000000000 ffff83022f019238 ffff83022f019238 000002476ff2fba8
(XEN)    ffff830300000000 ffff8302325a0c58 000000006d5ce000 0000000000000000
(XEN)    ffff83036d5ce000 0000000000000000 0000000000000000 ffff83022fb64000
(XEN)    ffff83036ff2fc28 ffff82c4c010bef0 ffff83036ff2fbc4 ffff83036ff2fbc0
(XEN)    ffff830300000001 0000000000000096 ffff83036ff2fbec ffff82c4c0319820
(XEN)    ffff83036ff28000 ffff83036ff28000 ffff83036ff28000 ffff83036ff28000
(XEN)    ffff83036ff28000 ffff83036ff2fbc8 ffff83036ff28000 0000000000000001
(XEN)    ffffc90010283a40 0000000000000002 ffff83036ff2fbd8 ffff82c4c0125aa4
(XEN) Xen call trace:
(XEN)    [<ffff82c4c0170fdc>] get_page+0x125/0x151
(XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
(XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
(XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
(XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
(XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
(XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
(XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145
(XEN)
(XEN) mm.c:1983:d0 Error pfn 43e646: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43f86a: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43e683: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43f31b: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43e5f0: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=0000000000000001
(XEN) mm.c:1983:d0 Error pfn 43f3b7: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) mm.c:1983:d0 Error pfn 43f87c: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
(XEN) irq.c:375: Dom3 callback via changed to Direct Vector 0xf3
...

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:43:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:43: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 1U8aAb-0004u4-RT; Thu, 21 Feb 2013 17:42: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 1U8aAb-0004tx-4M
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:42:57 +0000
Received: from [85.158.139.83:51362] by server-12.bemta-5.messagelabs.com id
	D8/F9-20195-0AC56215; Thu, 21 Feb 2013 17:42:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361468574!25619449!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12156 invoked from network); 21 Feb 2013 17:42:55 -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; 21 Feb 2013 17:42:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8aAY-0007x9-1l; Thu, 21 Feb 2013 17:42:54 +0000
Date: Thu, 21 Feb 2013 17:42:53 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20130221174253.GG24051@ocelot.phlegethon.org>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
	<A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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 09:58 -0500 on 21 Feb (1361440689), Andres Lagar-Cavilla wrote:
> > The remaining locked lookups are in sh_page_fault() (in a path that's
> > almost always already serializing on the paging lock), and in
> > emulate_map_dest() (which can probably be updated to use
> > get_page_from_gfn()).
> That is absolutely the case. Here is a rough patch:

Applied, thanks.  I've taken your S-o-b below to apply to this patch
too; hope that's OK. 

Tim.

> diff -r 7324955b35ad xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -4861,6 +4861,7 @@ static mfn_t emulate_gva_to_mfn(struct v
>                                  struct sh_emulate_ctxt *sh_ctxt)
>  {
>      unsigned long gfn;
> +    struct page_info *page;
>      mfn_t mfn;
>      p2m_type_t p2mt;
>      uint32_t pfec = PFEC_page_present | PFEC_write_access;
> @@ -4878,22 +4879,30 @@ static mfn_t emulate_gva_to_mfn(struct v
>  
>      /* Translate the GFN to an MFN */
>      ASSERT(!paging_locked_by_me(v->domain));
> -    mfn = get_gfn(v->domain, _gfn(gfn), &p2mt);
> -        
> +    page = get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
> +
> +    /* Sanity checking */
> +    if ( page == NULL )
> +    {
> +        return _mfn(BAD_GFN_TO_MFN);
> +    }
>      if ( p2m_is_readonly(p2mt) )
>      {
> -        put_gfn(v->domain, gfn);
> +        put_page(page);
>          return _mfn(READONLY_GFN);
>      }
>      if ( !p2m_is_ram(p2mt) )
>      {
> -        put_gfn(v->domain, gfn);
> +        put_page(page);
>          return _mfn(BAD_GFN_TO_MFN);
>      }
> -
> +    mfn = page_to_mfn(page);
>      ASSERT(mfn_valid(mfn));
> +
>      v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
> -    put_gfn(v->domain, gfn);
> +    /* Note shadow cannot page out or unshare this mfn, so the map won't
> +     * disappear. Otherwise, caller must hold onto page until done. */
> +    put_page(page);
>      return mfn;
>  }
>  
> 
> 
> >  They're not addressed here but may be in a
> > follow-up patch.
> > 
> 
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> or Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>? see http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:43:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:43: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 1U8aAb-0004u4-RT; Thu, 21 Feb 2013 17:42: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 1U8aAb-0004tx-4M
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:42:57 +0000
Received: from [85.158.139.83:51362] by server-12.bemta-5.messagelabs.com id
	D8/F9-20195-0AC56215; Thu, 21 Feb 2013 17:42:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361468574!25619449!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12156 invoked from network); 21 Feb 2013 17:42:55 -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; 21 Feb 2013 17:42:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8aAY-0007x9-1l; Thu, 21 Feb 2013 17:42:54 +0000
Date: Thu, 21 Feb 2013 17:42:53 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20130221174253.GG24051@ocelot.phlegethon.org>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
	<A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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 09:58 -0500 on 21 Feb (1361440689), Andres Lagar-Cavilla wrote:
> > The remaining locked lookups are in sh_page_fault() (in a path that's
> > almost always already serializing on the paging lock), and in
> > emulate_map_dest() (which can probably be updated to use
> > get_page_from_gfn()).
> That is absolutely the case. Here is a rough patch:

Applied, thanks.  I've taken your S-o-b below to apply to this patch
too; hope that's OK. 

Tim.

> diff -r 7324955b35ad xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -4861,6 +4861,7 @@ static mfn_t emulate_gva_to_mfn(struct v
>                                  struct sh_emulate_ctxt *sh_ctxt)
>  {
>      unsigned long gfn;
> +    struct page_info *page;
>      mfn_t mfn;
>      p2m_type_t p2mt;
>      uint32_t pfec = PFEC_page_present | PFEC_write_access;
> @@ -4878,22 +4879,30 @@ static mfn_t emulate_gva_to_mfn(struct v
>  
>      /* Translate the GFN to an MFN */
>      ASSERT(!paging_locked_by_me(v->domain));
> -    mfn = get_gfn(v->domain, _gfn(gfn), &p2mt);
> -        
> +    page = get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
> +
> +    /* Sanity checking */
> +    if ( page == NULL )
> +    {
> +        return _mfn(BAD_GFN_TO_MFN);
> +    }
>      if ( p2m_is_readonly(p2mt) )
>      {
> -        put_gfn(v->domain, gfn);
> +        put_page(page);
>          return _mfn(READONLY_GFN);
>      }
>      if ( !p2m_is_ram(p2mt) )
>      {
> -        put_gfn(v->domain, gfn);
> +        put_page(page);
>          return _mfn(BAD_GFN_TO_MFN);
>      }
> -
> +    mfn = page_to_mfn(page);
>      ASSERT(mfn_valid(mfn));
> +
>      v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
> -    put_gfn(v->domain, gfn);
> +    /* Note shadow cannot page out or unshare this mfn, so the map won't
> +     * disappear. Otherwise, caller must hold onto page until done. */
> +    put_page(page);
>      return mfn;
>  }
>  
> 
> 
> >  They're not addressed here but may be in a
> > follow-up patch.
> > 
> 
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> or Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>? see http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:48:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aFw-000586-Kd; Thu, 21 Feb 2013 17:48:28 +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 1U8aFv-00057v-LI
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:27 +0000
Received: from [193.109.254.147:43529] by server-2.bemta-14.messagelabs.com id
	C5/81-16277-AED56215; Thu, 21 Feb 2013 17:48:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361468904!2317886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23349 invoked from network); 21 Feb 2013 17:48:26 -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;
	21 Feb 2013 17:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8370822"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-I7;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:12 +0000
Message-ID: <1361468894-18655-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] xen: kexec crash image when dom0 crashes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/shutdown.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index b18ef5d..12aa034 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -46,6 +46,9 @@ void dom0_shutdown(u8 reason)
     {
         debugger_trap_immediate();
         printk("Domain 0 crashed: ");
+#ifdef CONFIG_KEXEC
+        kexec_crash();
+#endif
         maybe_reboot();
         break; /* not reached */
     }
-- 
1.7.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 Feb 21 17:48:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aFw-000586-Kd; Thu, 21 Feb 2013 17:48:28 +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 1U8aFv-00057v-LI
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:27 +0000
Received: from [193.109.254.147:43529] by server-2.bemta-14.messagelabs.com id
	C5/81-16277-AED56215; Thu, 21 Feb 2013 17:48:26 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361468904!2317886!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23349 invoked from network); 21 Feb 2013 17:48:26 -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;
	21 Feb 2013 17:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8370822"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-I7;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:12 +0000
Message-ID: <1361468894-18655-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 6/8] xen: kexec crash image when dom0 crashes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/shutdown.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index b18ef5d..12aa034 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -46,6 +46,9 @@ void dom0_shutdown(u8 reason)
     {
         debugger_trap_immediate();
         printk("Domain 0 crashed: ");
+#ifdef CONFIG_KEXEC
+        kexec_crash();
+#endif
         maybe_reboot();
         break; /* not reached */
     }
-- 
1.7.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 Feb 21 17:48:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aFz-00058q-Jx; Thu, 21 Feb 2013 17:48:31 +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 1U8aFy-00058G-3i
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:30 +0000
Received: from [193.109.254.147:38518] by server-13.bemta-14.messagelabs.com
	id 31/C8-30639-DED56215; Thu, 21 Feb 2013 17:48:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361468904!2317886!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23398 invoked from network); 21 Feb 2013 17:48:27 -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;
	21 Feb 2013 17:48:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8370825"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-HB;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:11 +0000
Message-ID: <1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
	load/unload 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>
Content-Type: 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 existing kexec hypercall, the load and unload ops depend on
internals of the Linux kernel (the page list and code page provided by
the kernel).  The code page is used to transition between Xen context
and the image so using kernel code doesn't make sense and will not
work for PVH guests.

Add replacement KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload ops
that no longer require a code page to be provided by the guest -- Xen
now provides the code for calling the image directly.

The new load op looks similar to the Linux kexec_load system call and
allows the guest to provide the image data to be loaded.  The guest
specifies the architecture of the image which may be a 32-bit subarch
of the hypervisor's architecture (i.e., an EM_386 image on an
EM_X86_64 hypervisor).

The toolstack can now load images without kernel involvement.  This is
required for supporting kexec when using a dom0 with an upstream
kernel.

Crash images are copied directly into the crash region on load.
Default images are copied into Xen heap pages and a list of source and
destination machine addresses is created.  This is list is used in
kexec_reloc() to relocate the image to its destination.

The old load and unload sub-ops are still available (as
KEXEC_CMD_load_v1 and KEXEC_CMD_unload_v1) and are implemented on top
of the new infrastructure.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/x86/machine_kexec.c        |  261 ++++++++++++++++++-------
 xen/arch/x86/x86_64/Makefile        |    2 +-
 xen/arch/x86/x86_64/compat_kexec.S  |  187 -----------------
 xen/arch/x86/x86_64/kexec_reloc.S   |  229 +++++++++++++++++++++
 xen/common/kexec.c                  |  377 +++++++++++++++++++++++++++++------
 xen/include/asm-x86/fixmap.h        |    3 -
 xen/include/asm-x86/machine_kexec.h |   14 ++
 xen/include/xen/kexec.h             |   14 +-
 8 files changed, 755 insertions(+), 332 deletions(-)
 delete mode 100644 xen/arch/x86/x86_64/compat_kexec.S
 create mode 100644 xen/arch/x86/x86_64/kexec_reloc.S
 create mode 100644 xen/include/asm-x86/machine_kexec.h

diff --git a/xen/arch/x86/machine_kexec.c b/xen/arch/x86/machine_kexec.c
index 8191ef1..0ec8c56 100644
--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -1,9 +1,18 @@
 /******************************************************************************
  * machine_kexec.c
  *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ *
+ * Portions derived from Linux's arch/x86/kernel/machine_kexec_64.c.
+ *
+ *   Copyright (C) 2002-2005 Eric Biederman  <ebiederm@xmission.com>
+ *
  * Xen port written by:
  * - Simon 'Horms' Horman <horms@verge.net.au>
  * - Magnus Damm <magnus@valinux.co.jp>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
  */
 
 #include <xen/types.h>
@@ -11,63 +20,195 @@
 #include <xen/guest_access.h>
 #include <asm/fixmap.h>
 #include <asm/hpet.h>
+#include <asm/page.h>
+#include <asm/machine_kexec.h>
+
+static void init_level2_page(l2_pgentry_t *l2, unsigned long addr)
+{
+    unsigned long end_addr;
+
+    addr &= PAGE_MASK;
+    end_addr = addr + L2_PAGETABLE_ENTRIES * (1ul << L2_PAGETABLE_SHIFT);
+
+    while ( addr < end_addr )
+    {
+        l2e_write(l2++, l2e_from_paddr(addr, __PAGE_HYPERVISOR | _PAGE_PSE));
 
-typedef void (*relocate_new_kernel_t)(
-                unsigned long indirection_page,
-                unsigned long *page_list,
-                unsigned long start_address,
-                unsigned int preserve_context);
+        addr += 1ul << L2_PAGETABLE_SHIFT;
+    }
+}
 
-int machine_kexec_load(int type, int slot, xen_kexec_image_t *image)
+static int init_level3_page(struct kexec_image *image, l3_pgentry_t *l3,
+                            unsigned long addr, unsigned long last_addr)
 {
-    unsigned long prev_ma = 0;
-    int fix_base = FIX_KEXEC_BASE_0 + (slot * (KEXEC_XEN_NO_PAGES >> 1));
-    int k;
+    unsigned long end_addr;
 
-    /* setup fixmap to point to our pages and record the virtual address
-     * in every odd index in page_list[].
-     */
+    addr &= PAGE_MASK;
+    end_addr = addr + L3_PAGETABLE_ENTRIES * (1ul << L3_PAGETABLE_SHIFT);
+
+    while( (addr < last_addr) && (addr < end_addr) )
+    {
+        struct page_info *l2_page;
+        l2_pgentry_t *l2;
+
+        l2_page = kimage_alloc_control_page(image);
+        if ( !l2_page )
+            return -ENOMEM;
+        l2 = page_to_virt(l2_page);
+
+        init_level2_page(l2, addr);
+        l3e_write(l3++, l3e_from_page(l2_page, __PAGE_HYPERVISOR));
+
+        addr += 1ul << L3_PAGETABLE_SHIFT;
+    }
+
+    return 0;
+}
+
+/*
+ * Build a complete page table to identity map [addr, last_addr).
+ *
+ * Control pages are used so they do not overlap with the image source
+ * or destination.
+ */
+static int init_level4_page(struct kexec_image *image, l4_pgentry_t *l4,
+                            unsigned long addr, unsigned long last_addr)
+{
+    unsigned long end_addr;
+    int result;
+
+    addr &= PAGE_MASK;
+    end_addr = addr + L4_PAGETABLE_ENTRIES * (1ul << L4_PAGETABLE_SHIFT);
+
+    while ( (addr < last_addr) && (addr < end_addr) )
+    {
+        struct page_info *l3_page;
+        l3_pgentry_t *l3;
+
+        l3_page = kimage_alloc_control_page(image);
+        if ( !l3_page )
+            return -ENOMEM;
+        l3 = page_to_virt(l3_page);
+
+        result = init_level3_page(image, l3, addr, last_addr);
+        if (result)
+            return result;
+        l4e_write(l4++, l4e_from_page(l3_page, __PAGE_HYPERVISOR));
+
+        addr += 1ul << L4_PAGETABLE_SHIFT;
+    }
+
+    return 0;
+}
 
-    for ( k = 0; k < KEXEC_XEN_NO_PAGES; k++ )
+/*
+ * Add a mapping for the control code page to the same virtual address
+ * as kexec_reloc.  This allows us to keep running after these page
+ * tables are loaded in kexec_reloc.
+ * 
+ * We don't really need to allocate control pages here as these
+ * entries won't be used while the kexec image is being copied, but it
+ * makes clean-up easier.
+ */
+static int init_transition_pgtable(struct kexec_image *image, l4_pgentry_t *l4)
+{
+    struct page_info *l3_page;
+    struct page_info *l2_page;
+    struct page_info *l1_page;
+    unsigned long vaddr, paddr;
+    l3_pgentry_t *l3;
+    l2_pgentry_t *l2;
+    l1_pgentry_t *l1;
+
+    vaddr = (unsigned long)kexec_reloc;
+    paddr = page_to_maddr(image->control_code_page);
+
+    l4 += l4_table_offset(vaddr);
+    if ( !(l4e_get_flags(*l4) & _PAGE_PRESENT) )
+    {
+        l3_page = kimage_alloc_control_page(image);
+        if ( !l3_page )
+            return -ENOMEM;
+        l4e_write(l4, l4e_from_page(l3_page, __PAGE_HYPERVISOR));
+    }
+
+    l3 = l4e_to_l3e(*l4) + l3_table_offset(vaddr);
+    if ( !(l3e_get_flags(*l3) & _PAGE_PRESENT) )
+    {
+        l2_page = kimage_alloc_control_page(image);
+        if ( !l2_page )
+            return -ENOMEM;
+        l3e_write(l3, l3e_from_page(l2_page, __PAGE_HYPERVISOR));
+    }
+
+    l2 = l3e_to_l2e(*l3) + l2_table_offset(vaddr);
+    if ( !(l2e_get_flags(*l2) & _PAGE_PRESENT) )
+    {
+        l1_page = kimage_alloc_control_page(image);
+        if ( !l1_page )
+            return -ENOMEM;
+        l2e_write(l2, l2e_from_page(l1_page, __PAGE_HYPERVISOR));
+    }
+
+    l1 = l2e_to_l1e(*l2) + l1_table_offset(vaddr);
+    l1e_write(l1, l1e_from_pfn(paddr >> PAGE_SHIFT, __PAGE_HYPERVISOR));
+    return 0;
+}
+
+
+static int build_reloc_page_table(struct kexec_image *image)
+{
+    struct page_info *l4_page;
+    l4_pgentry_t *l4;
+    int result;
+
+    l4_page = kimage_alloc_control_page(image);
+    if ( !l4_page )
+        return -ENOMEM;
+
+    l4 = page_to_virt(l4_page);
+    result = init_level4_page(image, l4, 0, max_page << PAGE_SHIFT);
+    if ( result )
+        return result;
+
+    result = init_transition_pgtable(image, l4);
+    if ( result )
+        return result;
+
+    image->aux_page = l4_page;
+    return 0;
+}
+
+int machine_kexec_load(struct kexec_image *image)
+{
+    void *code_page;
+    int ret;
+
+    switch ( image->arch )
     {
-        if ( (k & 1) == 0 )
-        {
-            /* Even pages: machine address. */
-            prev_ma = image->page_list[k];
-        }
-        else
-        {
-            /* Odd pages: va for previous ma. */
-            if ( is_pv_32on64_domain(dom0) )
-            {
-                /*
-                 * The compatability bounce code sets up a page table
-                 * with a 1-1 mapping of the first 1G of memory so
-                 * VA==PA here.
-                 *
-                 * This Linux purgatory code still sets up separate
-                 * high and low mappings on the control page (entries
-                 * 0 and 1) but it is harmless if they are equal since
-                 * that PT is not live at the time.
-                 */
-                image->page_list[k] = prev_ma;
-            }
-            else
-            {
-                set_fixmap(fix_base + (k >> 1), prev_ma);
-                image->page_list[k] = fix_to_virt(fix_base + (k >> 1));
-            }
-        }
+    case EM_386:
+    case EM_X86_64:
+        break;
+    default:
+        return -EINVAL;
     }
 
+    code_page = page_to_virt(image->control_code_page);
+    memcpy(code_page, kexec_reloc, PAGE_SIZE);
+
+    ret = build_reloc_page_table(image);
+    if ( ret < 0 )
+        return ret;
+
     return 0;
 }
 
-void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image)
+void machine_kexec_unload(struct kexec_image *image)
 {
+    /* no-op. kimage_free() frees all control pages. */
 }
 
-void machine_reboot_kexec(xen_kexec_image_t *image)
+void machine_reboot_kexec(struct kexec_image *image)
 {
     BUG_ON(smp_processor_id() != 0);
     smp_send_stop();
@@ -75,13 +216,10 @@ void machine_reboot_kexec(xen_kexec_image_t *image)
     BUG();
 }
 
-void machine_kexec(xen_kexec_image_t *image)
+void machine_kexec(struct kexec_image *image)
 {
-    struct desc_ptr gdt_desc = {
-        .base = (unsigned long)(boot_cpu_gdt_table - FIRST_RESERVED_GDT_ENTRY),
-        .limit = LAST_RESERVED_GDT_BYTE
-    };
     int i;
+    unsigned long reloc_flags = 0;
 
     /* We are about to permenantly jump out of the Xen context into the kexec
      * purgatory code.  We really dont want to be still servicing interupts.
@@ -109,29 +247,12 @@ void machine_kexec(xen_kexec_image_t *image)
      * not like running with NMIs disabled. */
     enable_nmis();
 
-    /*
-     * compat_machine_kexec() returns to idle pagetables, which requires us
-     * to be running on a static GDT mapping (idle pagetables have no GDT
-     * mappings in their per-domain mapping area).
-     */
-    asm volatile ( "lgdt %0" : : "m" (gdt_desc) );
+    if ( image->arch == EM_386 )
+        reloc_flags |= KEXEC_RELOC_FLAG_COMPAT;
 
-    if ( is_pv_32on64_domain(dom0) )
-    {
-        compat_machine_kexec(image->page_list[1],
-                             image->indirection_page,
-                             image->page_list,
-                             image->start_address);
-    }
-    else
-    {
-        relocate_new_kernel_t rnk;
-
-        rnk = (relocate_new_kernel_t) image->page_list[1];
-        (*rnk)(image->indirection_page, image->page_list,
-               image->start_address,
-               0 /* preserve_context */);
-    }
+    kexec_reloc(page_to_maddr(image->control_code_page), 
+                page_to_maddr(image->aux_page),
+                image->head, image->entry_maddr, reloc_flags);
 }
 
 int machine_kexec_get(xen_kexec_range_t *range)
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index d56e12d..7f8fb3d 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -11,11 +11,11 @@ obj-y += mmconf-fam10h.o
 obj-y += mmconfig_64.o
 obj-y += mmconfig-shared.o
 obj-y += compat.o
-obj-bin-y += compat_kexec.o
 obj-y += domain.o
 obj-y += physdev.o
 obj-y += platform_hypercall.o
 obj-y += cpu_idle.o
 obj-y += cpufreq.o
+obj-bin-y += kexec_reloc.o
 
 obj-$(crash_debug)   += gdbstub.o
diff --git a/xen/arch/x86/x86_64/compat_kexec.S b/xen/arch/x86/x86_64/compat_kexec.S
deleted file mode 100644
index fc92af9..0000000
--- a/xen/arch/x86/x86_64/compat_kexec.S
+++ /dev/null
@@ -1,187 +0,0 @@
-/*
- * Compatibility kexec handler.
- */
-
-/*
- * NOTE: We rely on Xen not relocating itself above the 4G boundary. This is
- * currently true but if it ever changes then compat_pg_table will
- * need to be moved back below 4G at run time.
- */
-
-#include <xen/config.h>
-
-#include <asm/asm_defns.h>
-#include <asm/msr.h>
-#include <asm/page.h>
-
-/* The unrelocated physical address of a symbol. */
-#define SYM_PHYS(sym)          ((sym) - __XEN_VIRT_START)
-
-/* Load physical address of symbol into register and relocate it. */
-#define RELOCATE_SYM(sym,reg)  mov $SYM_PHYS(sym), reg ; \
-                               add xen_phys_start(%rip), reg
-
-/*
- * Relocate a physical address in memory. Size of temporary register
- * determines size of the value to relocate.
- */
-#define RELOCATE_MEM(addr,reg) mov addr(%rip), reg ; \
-                               add xen_phys_start(%rip), reg ; \
-                               mov reg, addr(%rip)
-
-        .text
-
-        .code64
-
-ENTRY(compat_machine_kexec)
-        /* x86/64                        x86/32  */
-        /* %rdi - relocate_new_kernel_t  CALL    */
-        /* %rsi - indirection page       4(%esp) */
-        /* %rdx - page_list              8(%esp) */
-        /* %rcx - start address         12(%esp) */
-        /*        cpu has pae           16(%esp) */
-
-        /* Shim the 64 bit page_list into a 32 bit page_list. */
-        mov $12,%r9
-        lea compat_page_list(%rip), %rbx
-1:      dec %r9
-        movl (%rdx,%r9,8),%eax
-        movl %eax,(%rbx,%r9,4)
-        test %r9,%r9
-        jnz 1b
-
-        RELOCATE_SYM(compat_page_list,%rdx)
-
-        /* Relocate compatibility mode entry point address. */
-        RELOCATE_MEM(compatibility_mode_far,%eax)
-
-        /* Relocate compat_pg_table. */
-        RELOCATE_MEM(compat_pg_table,     %rax)
-        RELOCATE_MEM(compat_pg_table+0x8, %rax)
-        RELOCATE_MEM(compat_pg_table+0x10,%rax)
-        RELOCATE_MEM(compat_pg_table+0x18,%rax)
-
-        /*
-         * Setup an identity mapped region in PML4[0] of idle page
-         * table.
-         */
-        RELOCATE_SYM(l3_identmap,%rax)
-        or  $0x63,%rax
-        mov %rax, idle_pg_table(%rip)
-
-        /* Switch to idle page table. */
-        RELOCATE_SYM(idle_pg_table,%rax)
-        movq %rax, %cr3
-
-        /* Switch to identity mapped compatibility stack. */
-        RELOCATE_SYM(compat_stack,%rax)
-        movq %rax, %rsp
-
-        /* Save xen_phys_start for 32 bit code. */
-        movq xen_phys_start(%rip), %rbx
-
-        /* Jump to low identity mapping in compatibility mode. */
-        ljmp *compatibility_mode_far(%rip)
-        ud2
-
-compatibility_mode_far:
-        .long SYM_PHYS(compatibility_mode)
-        .long __HYPERVISOR_CS32
-
-        /*
-         * We use 5 words of stack for the arguments passed to the kernel. The
-         * kernel only uses 1 word before switching to its own stack. Allocate
-         * 16 words to give "plenty" of room.
-         */
-        .fill 16,4,0
-compat_stack:
-
-        .code32
-
-#undef RELOCATE_SYM
-#undef RELOCATE_MEM
-
-/*
- * Load physical address of symbol into register and relocate it. %rbx
- * contains xen_phys_start(%rip) saved before jump to compatibility
- * mode.
- */
-#define RELOCATE_SYM(sym,reg) mov $SYM_PHYS(sym), reg ; \
-                              add %ebx, reg
-
-compatibility_mode:
-        /* Setup some sane segments. */
-        movl $__HYPERVISOR_DS32, %eax
-        movl %eax, %ds
-        movl %eax, %es
-        movl %eax, %fs
-        movl %eax, %gs
-        movl %eax, %ss
-
-        /* Push arguments onto stack. */
-        pushl $0   /* 20(%esp) - preserve context */
-        pushl $1   /* 16(%esp) - cpu has pae */
-        pushl %ecx /* 12(%esp) - start address */
-        pushl %edx /*  8(%esp) - page list */
-        pushl %esi /*  4(%esp) - indirection page */
-        pushl %edi /*  0(%esp) - CALL */
-
-        /* Disable paging and therefore leave 64 bit mode. */
-        movl %cr0, %eax
-        andl $~X86_CR0_PG, %eax
-        movl %eax, %cr0
-
-        /* Switch to 32 bit page table. */
-        RELOCATE_SYM(compat_pg_table, %eax)
-        movl  %eax, %cr3
-
-        /* Clear MSR_EFER[LME], disabling long mode */
-        movl    $MSR_EFER,%ecx
-        rdmsr
-        btcl    $_EFER_LME,%eax
-        wrmsr
-
-        /* Re-enable paging, but only 32 bit mode now. */
-        movl %cr0, %eax
-        orl $X86_CR0_PG, %eax
-        movl %eax, %cr0
-        jmp 1f
-1:
-
-        popl %eax
-        call *%eax
-        ud2
-
-        .data
-        .align 4
-compat_page_list:
-        .fill 12,4,0
-
-        .align 32,0
-
-        /*
-         * These compat page tables contain an identity mapping of the
-         * first 4G of the physical address space.
-         */
-compat_pg_table:
-        .long SYM_PHYS(compat_pg_table_l2) + 0*PAGE_SIZE + 0x01, 0
-        .long SYM_PHYS(compat_pg_table_l2) + 1*PAGE_SIZE + 0x01, 0
-        .long SYM_PHYS(compat_pg_table_l2) + 2*PAGE_SIZE + 0x01, 0
-        .long SYM_PHYS(compat_pg_table_l2) + 3*PAGE_SIZE + 0x01, 0
-
-        .section .data.page_aligned, "aw", @progbits
-        .align PAGE_SIZE,0
-compat_pg_table_l2:
-        .macro identmap from=0, count=512
-        .if \count-1
-        identmap "(\from+0)","(\count/2)"
-        identmap "(\from+(0x200000*(\count/2)))","(\count/2)"
-        .else
-        .quad 0x00000000000000e3 + \from
-        .endif
-        .endm
-
-        identmap 0x00000000
-        identmap 0x40000000
-        identmap 0x80000000
-        identmap 0xc0000000
diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S
new file mode 100644
index 0000000..e68842c
--- /dev/null
+++ b/xen/arch/x86/x86_64/kexec_reloc.S
@@ -0,0 +1,229 @@
+/*
+ * Relocate a kexec_image to its destination and call it.
+ *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ *
+ * Portions derived from Linux's arch/x86/kernel/relocate_kernel_64.S.
+ * 
+ *   Copyright (C) 2002-2005 Eric Biederman  <ebiederm@xmission.com>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+#include <xen/config.h>
+
+#include <asm/asm_defns.h>
+#include <asm/msr.h>
+#include <asm/page.h>
+#include <asm/machine_kexec.h>
+
+/* The unrelocated physical address of a symbol. */
+#define SYM_PHYS(sym)          ((sym) - __XEN_VIRT_START)
+
+/* Load physical address of symbol into register and relocate it. */
+#define RELOCATE_SYM(sym,reg)  mov $SYM_PHYS(sym), reg ; \
+                               add xen_phys_start(%rip), reg
+
+#define DBG(c) \
+1:      mov     $0x3f8+5, %dx ; \
+        inb     %dx, %al     ; \
+        test    $0x20, %al   ; \
+        je      1b           ; \
+        mov     $0x3f8, %dx  ; \
+        mov     $c, %al      ; \
+        outb    %al, %dx     ;
+
+        .text
+	.align PAGE_SIZE
+        .code64
+
+ENTRY(kexec_reloc)
+        /* %rdi - code_page maddr */
+        /* %rsi - page table maddr */
+        /* %rdx - indirection page maddr */
+        /* %rcx - entry maddr */
+        /* %r8 - flags */
+
+        mov %rdx, %rbx
+
+        DBG('A')
+
+        /* Setup stack. */
+        RELOCATE_SYM(reloc_stack, %rax)
+        mov %rax, %rsp
+
+        DBG('B')
+
+        wbinvd
+        movq %cr4, %rax
+        andq $~(X86_CR4_PGE|X86_CR4_PCE|X86_CR4_MCE), %rax
+        movq %rax, %cr4
+
+        /* Load reloc page table. */
+        movq %rsi, %cr3
+
+        DBG('C')
+
+        /* Jump to identity mapped code. */
+        movq %rdi, %r9
+        addq $(identity_mapped - kexec_reloc), %r9
+
+        DBG('D')
+
+        jmp *%r9
+
+identity_mapped:
+        DBG('E')
+        
+        pushq %rcx
+        pushq %rbx
+        pushq %rsi
+        pushq %rdi
+
+        movq %rbx, %rdi
+        call swap_pages
+
+        popq %rdi
+        popq %rsi
+        popq %rbx
+        popq %rcx
+
+        DBG('F')
+
+        /* Need to switch to 32-bit mode? */
+        testq $KEXEC_RELOC_FLAG_COMPAT, %r8
+        jnz call_32_bit
+
+call_64_bit:
+        DBG('6')
+
+        /* Call the image entry point.  This should never return. */
+        call *%rcx
+        ud2
+
+call_32_bit:
+        DBG('3')
+
+        /* Relocate compatibility mode entry point address. */
+        movl %edi, %eax
+        addl $(compatibility_mode - kexec_reloc), %eax
+        movl %eax, compatibility_mode_far(%rip)
+
+        DBG('I')
+        
+        /* Load compat GDT. */
+        movq %rdi, %rax
+        addq $(compat_mode_gdt - kexec_reloc), %rax
+        movq %rax, (compat_mode_gdt_desc + 2)(%rip)
+        lgdt compat_mode_gdt_desc(%rip)
+
+        DBG('J')
+        
+        /* Enter compatibility mode. */
+        ljmp *compatibility_mode_far(%rip)
+
+swap_pages:
+        /* %rdi - indirection page maddr */
+        movq    %rdi, %rcx
+        xorq    %rdi, %rdi
+        xorq    %rsi, %rsi
+        jmp     1f
+
+0:      /* top, read another word for the indirection page */
+
+        movq    (%rbx), %rcx
+        addq    $8,     %rbx
+1:
+        testq   $0x1,   %rcx  /* is it a destination page? */
+        jz      2f
+        movq    %rcx,   %rdi
+        andq    $0xfffffffffffff000, %rdi
+        jmp     0b
+2:
+        testq   $0x2,   %rcx  /* is it an indirection page? */
+        jz      2f
+        movq    %rcx,   %rbx
+        andq    $0xfffffffffffff000, %rbx
+        jmp     0b
+2:
+        testq   $0x4,   %rcx  /* is it the done indicator? */
+        jz      2f
+        jmp     3f
+2:
+        testq   $0x8,   %rcx  /* is it the source indicator? */
+        jz      0b            /* Ignore it otherwise */
+        movq    %rcx,   %rsi  /* For ever source page do a copy */
+        andq    $0xfffffffffffff000, %rsi
+
+        movq    %rdi, %rdx
+        movq    %rsi, %rax
+
+        movq    %r10, %rdi
+        movq    $512,   %rcx
+        rep movsq
+
+        movq    %rax, %rdi
+        movq    %rdx, %rsi
+        movq    $512,   %rcx
+        rep movsq
+
+        movq    %rdx, %rdi
+        movq    %r10, %rsi
+        movq    $512,   %rcx
+        rep movsq
+
+        lea     PAGE_SIZE(%rax), %rsi
+        jmp     0b
+3:
+        ret
+
+        .code32
+
+compatibility_mode:
+        DBG('K')
+
+        /* Setup some sane segments. */
+        movl $0x0008, %eax
+        movl %eax, %ds
+        movl %eax, %es
+        movl %eax, %fs
+        movl %eax, %gs
+        movl %eax, %ss
+
+        DBG('L')
+        
+        /* Disable paging and therefore leave 64 bit mode. */
+        movl %cr0, %eax
+        andl $~X86_CR0_PG, %eax
+        movl %eax, %cr0
+
+        DBG('M')
+
+        /* Call the image entry point.  This should never return. */
+        call *%ecx
+        ud2
+
+        .align 16
+compatibility_mode_far:
+        .long SYM_PHYS(compatibility_mode)
+        .word 0x0010
+
+        .align 16
+compat_mode_gdt_desc:
+        .word (3*8)-1
+        .quad SYM_PHYS(compat_mode_gdt)
+
+        .align 16
+compat_mode_gdt:
+        .quad 0x0000000000000000     /* null                              */
+        .quad 0x00cf92000000ffff     /* 0x0008 ring 0 data                */
+        .quad 0x00cf9a000000ffff     /* 0x0010 ring 0 code, compatibility */
+
+        /*
+         * 16 words of stack are more than enough.
+         */
+        .fill 16,8,0
+reloc_stack:
+
+        .globl kexec_reloc_size
+        .set kexec_reloc_size, . - kexec_reloc
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2cbb62c..2926274 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -23,6 +23,7 @@
 #include <xen/version.h>
 #include <xen/console.h>
 #include <xen/kexec.h>
+#include <xen/kimage.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
 #include <xen/cpu.h>
@@ -45,7 +46,7 @@ static Elf_Note *xen_crash_note;
 
 static cpumask_t crash_saved_cpus;
 
-static xen_kexec_image_t kexec_image[KEXEC_IMAGE_NR];
+static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];
 
 #define KEXEC_FLAG_DEFAULT_POS   (KEXEC_IMAGE_NR + 0)
 #define KEXEC_FLAG_CRASH_POS     (KEXEC_IMAGE_NR + 1)
@@ -309,14 +310,14 @@ void kexec_crash(void)
     kexec_common_shutdown();
     kexec_crash_save_cpu();
     machine_crash_shutdown();
-    machine_kexec(&kexec_image[KEXEC_IMAGE_CRASH_BASE + pos]);
+    machine_kexec(kexec_image[KEXEC_IMAGE_CRASH_BASE + pos]);
 
     BUG();
 }
 
 static long kexec_reboot(void *_image)
 {
-    xen_kexec_image_t *image = _image;
+    struct kexec_image *image = _image;
 
     kexecing = TRUE;
 
@@ -732,63 +733,245 @@ static void crash_save_vmcoreinfo(void)
 #endif
 }
 
-static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_v1_t *load)
+static void kexec_unload_image(struct kexec_image *image)
+{
+    if ( !image )
+        return;
+
+    machine_kexec_unload(image);
+}
+
+static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    xen_kexec_exec_t exec;
+    struct kexec_image *image;
+    int base, bit, pos, ret = -EINVAL;
+
+    if ( unlikely(copy_from_guest(&exec, uarg, 1)) )
+        return -EFAULT;
+
+    if ( kexec_load_get_bits(exec.type, &base, &bit) )
+        return -EINVAL;
+
+    pos = (test_bit(bit, &kexec_flags) != 0);
+
+    /* Only allow kexec/kdump into loaded images */
+    if ( !test_bit(base + pos, &kexec_flags) )
+        return -ENOENT;
+
+    switch (exec.type)
+    {
+    case KEXEC_TYPE_DEFAULT:
+        image = kexec_image[base + pos];
+        ret = continue_hypercall_on_cpu(0, kexec_reboot, image);
+        break;
+    case KEXEC_TYPE_CRASH:
+        kexec_crash(); /* Does not return */
+        break;
+    }
+
+    return -EINVAL; /* never reached */
+}
+
+static int kexec_swap_images(int type, struct kexec_image *new,
+                             struct kexec_image **old)
 {
-    xen_kexec_image_t *image;
     int base, bit, pos;
-    int ret = 0;
+    int new_slot, old_slot;
+
+    *old = NULL;
+
+    spin_lock(&kexec_lock);
+
+    if ( test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags) )
+    {
+        spin_unlock(&kexec_lock);
+        return -EBUSY;
+    }
 
-    if ( kexec_load_get_bits(load->type, &base, &bit) )
+    if ( kexec_load_get_bits(type, &base, &bit) )
         return -EINVAL;
 
     pos = (test_bit(bit, &kexec_flags) != 0);
+    old_slot = base + pos;
+    new_slot = base + !pos;
 
-    /* Load the user data into an unused image */
-    if ( op == KEXEC_CMD_kexec_load )
+    if ( new )
     {
-        image = &kexec_image[base + !pos];
+        kexec_image[new_slot] = new;
+        set_bit(new_slot, &kexec_flags);
+    }
+    change_bit(bit, &kexec_flags);
 
-        BUG_ON(test_bit((base + !pos), &kexec_flags)); /* must be free */
+    clear_bit(old_slot, &kexec_flags);
+    *old = kexec_image[old_slot];
 
-        memcpy(image, &load->image, sizeof(*image));
+    spin_unlock(&kexec_lock);
 
-        if ( !(ret = machine_kexec_load(load->type, base + !pos, image)) )
-        {
-            /* Set image present bit */
-            set_bit((base + !pos), &kexec_flags);
+    return 0;
+}
 
-            /* Make new image the active one */
-            change_bit(bit, &kexec_flags);
-        }
+static int kexec_load_slot(struct kexec_image *kimage)
+{
+    struct kexec_image *old_kimage;
+    int ret = -ENOMEM;
+
+    ret = machine_kexec_load(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    crash_save_vmcoreinfo();
 
-        crash_save_vmcoreinfo();
+    ret = kexec_swap_images(kimage->type, kimage, &old_kimage);
+    if ( ret < 0 )
+        goto error;
+
+    kexec_unload_image(old_kimage);
+    
+    return 0;
+
+error:
+    kimage_free(kimage);
+    return ret;
+}
+
+static uint16_t kexec_load_v1_arch(void)
+{
+#ifdef CONFIG_X86
+    return is_pv_32on64_domain(dom0) ? EM_386 : EM_X86_64;
+#else
+    return EM_NONE;
+#endif
+}
+
+static int kexec_segments_add_page(unsigned *nr_segments,
+                                   xen_kexec_segment_t *segments,
+                                   unsigned long mfn)
+{
+    unsigned long maddr = mfn << PAGE_SHIFT;
+    int n = *nr_segments;
+
+    /* Need a new segment? */
+    if ( n == 0
+         || segments[n-1].dest_maddr + segments[n-1].dest_size != maddr )
+    {
+        n++;
+        if ( n == KEXEC_SEGMENT_MAX )
+            return -EINVAL;
+        *nr_segments = n;
+
+        set_xen_guest_handle(segments[n-1].buf, NULL);
+        segments[n-1].buf_size = 0;
+        segments[n-1].dest_maddr = maddr;
+        segments[n-1].dest_size = 0;
     }
 
-    /* Unload the old image if present and load successful */
-    if ( ret == 0 && !test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags) )
+    segments[n-1].dest_size += PAGE_SIZE;
+
+    return 0;
+}
+
+static int kexec_segments_from_ind_page(unsigned long mfn,
+                                        unsigned *nr_segments,
+                                        xen_kexec_segment_t *segments)
+{
+    void *page;
+    unsigned long *entry;
+    int ret;
+
+    page = vmap(&mfn, 1);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    /*
+     * Walk the indirection page list, adding destination pages to the
+     * segments.
+     */
+    for ( entry = page; ; entry++ )
     {
-        if ( test_and_clear_bit((base + pos), &kexec_flags) )
+        unsigned long ind;
+
+        ind = (*entry) & 0xf;
+        mfn = (*entry) >> PAGE_SHIFT;
+
+        switch ( ind )
         {
-            image = &kexec_image[base + pos];
-            machine_kexec_unload(load->type, base + pos, image);
+        case IND_DESTINATION:
+            ret = kexec_segments_add_page(nr_segments, segments, mfn);
+            if ( ret < 0 )
+                return ret;
+            break;
+        case IND_INDIRECTION:
+            vunmap(page);
+            page = vmap(&mfn, 1);
+            if ( page == NULL )
+                return -ENOMEM;
+            entry = page;
+            break;
+        case IND_DONE:
+            goto done;
+        case IND_SOURCE:
+            break;
         }
     }
+done:
+    return 0;
+}
+
+static int kexec_do_load_v1(xen_kexec_load_v1_t *load)
+{
+    struct kexec_image *kimage = NULL;
+    xen_kexec_segment_t *segments;
+    uint16_t arch;
+    unsigned nr_segments = 0;
+    int ret;
+
+    arch = kexec_load_v1_arch();
+    if ( arch == EM_NONE )
+        return -ENOSYS;
+
+    segments = xmalloc_array(xen_kexec_segment_t, KEXEC_SEGMENT_MAX);
+    if ( segments == NULL )
+        return -ENOMEM;
+
+    ret = kexec_segments_from_ind_page(load->image.indirection_page >> PAGE_SHIFT,
+                                       &nr_segments, segments);
+    if ( ret < 0 )
+        goto error;
+
+    ret = kimage_alloc(&kimage, load->type, arch, load->image.start_address,
+                       nr_segments, segments);
+    if ( ret < 0 )
+        goto error;
+
+    /* kexec_reloc() uses the same format for the indirection pages so
+       reuse the provided ones. */
+    kimage->head = load->image.indirection_page;
+
+    ret = kexec_load_slot(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    return 0;
 
+error:
+    if ( !kimage )
+        xfree(segments);
+    kimage_free(kimage);
     return ret;
 }
 
-static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+static int kexec_load_v1(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_load_v1_t load;
 
     if ( unlikely(copy_from_guest(&load, uarg, 1)) )
         return -EFAULT;
 
-    return kexec_load_unload_internal(op, &load);
+    return kexec_do_load_v1(&load);
 }
 
-static int kexec_load_unload_compat(unsigned long op,
-                                    XEN_GUEST_HANDLE_PARAM(void) uarg)
+static int kexec_load_v1_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
     compat_kexec_load_v1_t compat_load;
@@ -807,49 +990,113 @@ static int kexec_load_unload_compat(unsigned long op,
     load.type = compat_load.type;
     XLAT_kexec_image(&load.image, &compat_load.image);
 
-    return kexec_load_unload_internal(op, &load);
-#else /* CONFIG_COMPAT */
+    return kexec_do_load_v1(&load);
+#else
     return 0;
-#endif /* CONFIG_COMPAT */
+#endif
 }
 
-static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
+static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
-    xen_kexec_exec_t exec;
-    xen_kexec_image_t *image;
-    int base, bit, pos, ret = -EINVAL;
+    xen_kexec_load_t load;
+    xen_kexec_segment_t *segments;
+    struct kexec_image *kimage = NULL;
+    int ret;
 
-    if ( unlikely(copy_from_guest(&exec, uarg, 1)) )
+    if ( copy_from_guest(&load, uarg, 1) )
         return -EFAULT;
 
-    if ( kexec_load_get_bits(exec.type, &base, &bit) )
+    if ( load.nr_segments >= KEXEC_SEGMENT_MAX )
         return -EINVAL;
 
-    pos = (test_bit(bit, &kexec_flags) != 0);
-
-    /* Only allow kexec/kdump into loaded images */
-    if ( !test_bit(base + pos, &kexec_flags) )
-        return -ENOENT;
+    segments = xmalloc_array(xen_kexec_segment_t, load.nr_segments);
+    if ( segments == NULL )
+        return -ENOMEM;
 
-    switch (exec.type)
+    if ( copy_from_guest(segments, load.segments, load.nr_segments) )
     {
-    case KEXEC_TYPE_DEFAULT:
-        image = &kexec_image[base + pos];
-        ret = continue_hypercall_on_cpu(0, kexec_reboot, image);
-        break;
-    case KEXEC_TYPE_CRASH:
-        kexec_crash(); /* Does not return */
-        break;
+        ret = -EFAULT;
+        goto error;
     }
 
-    return -EINVAL; /* never reached */
+    ret = kimage_alloc(&kimage, load.type, load.arch, load.entry_maddr,
+                       load.nr_segments, segments);
+    if ( ret < 0 )
+        goto error;
+
+    ret = kimage_load_segments(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    ret = kexec_load_slot(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    return 0;
+
+error:
+    if ( ! kimage )
+        xfree(segments);
+    kimage_free(kimage);
+    return ret;
+}
+
+static int kexec_do_unload(xen_kexec_unload_t *unload)
+{
+    struct kexec_image *old_kimage;
+    int ret;
+
+    ret = kexec_swap_images(unload->type, NULL, &old_kimage);
+    if ( ret < 0 )
+        return ret;
+
+    kexec_unload_image(old_kimage);
+
+    return 0;
+}
+
+static int kexec_unload_v1(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    xen_kexec_load_v1_t load;
+    xen_kexec_unload_t unload;
+
+    if ( copy_from_guest(&load, uarg, 1) )
+        return -EFAULT;
+
+    unload.type = load.type;
+    return kexec_do_unload(&unload);
+}
+
+static int kexec_unload_v1_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+#ifdef CONFIG_COMPAT
+    compat_kexec_load_v1_t compat_load;
+    xen_kexec_unload_t unload;
+
+    if ( copy_from_guest(&compat_load, uarg, 1) )
+        return -EFAULT;
+
+    unload.type = compat_load.type;
+    return kexec_do_unload(&unload);
+#else
+    return 0;
+#endif
+}
+
+static int kexec_unload(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    xen_kexec_unload_t unload;
+
+    if ( unlikely(copy_from_guest(&unload, uarg, 1)) )
+        return -EFAULT;
+
+    return kexec_do_unload(&unload);
 }
 
 static int do_kexec_op_internal(unsigned long op,
                                 XEN_GUEST_HANDLE_PARAM(void) uarg,
                                 bool_t compat)
 {
-    unsigned long flags;
     int ret = -EINVAL;
 
     ret = xsm_kexec(XSM_PRIV);
@@ -865,20 +1112,26 @@ static int do_kexec_op_internal(unsigned long op,
                 ret = kexec_get_range(uarg);
         break;
     case KEXEC_CMD_kexec_load_v1:
+        if ( compat )
+            ret = kexec_load_v1_compat(uarg);
+        else
+            ret = kexec_load_v1(uarg);
+        break;
     case KEXEC_CMD_kexec_unload_v1:
-        spin_lock_irqsave(&kexec_lock, flags);
-        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
-        {
-                if (compat)
-                        ret = kexec_load_unload_compat(op, uarg);
-                else
-                        ret = kexec_load_unload(op, uarg);
-        }
-        spin_unlock_irqrestore(&kexec_lock, flags);
+        if ( compat )
+            ret = kexec_unload_v1_compat(uarg);
+        else
+            ret = kexec_unload_v1(uarg);
         break;
     case KEXEC_CMD_kexec:
         ret = kexec_exec(uarg);
         break;
+    case KEXEC_CMD_kexec_load:
+        ret = kexec_load(uarg);
+        break;
+    case KEXEC_CMD_kexec_unload:
+        ret = kexec_unload(uarg);
+        break;
     }
 
     return ret;
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index 2eefcf4..1695228 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -57,9 +57,6 @@ enum fixed_addresses {
     FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
     FIX_HPET_BASE,
     FIX_CYCLONE_TIMER,
-    FIX_KEXEC_BASE_0,
-    FIX_KEXEC_BASE_END = FIX_KEXEC_BASE_0 \
-      + ((KEXEC_XEN_NO_PAGES >> 1) * KEXEC_IMAGE_NR) - 1,
     FIX_IOMMU_REGS_BASE_0,
     FIX_IOMMU_REGS_END = FIX_IOMMU_REGS_BASE_0 + MAX_IOMMUS-1,
     FIX_IOMMU_MMIO_BASE_0,
diff --git a/xen/include/asm-x86/machine_kexec.h b/xen/include/asm-x86/machine_kexec.h
new file mode 100644
index 0000000..ec41099
--- /dev/null
+++ b/xen/include/asm-x86/machine_kexec.h
@@ -0,0 +1,14 @@
+#ifndef __X86_MACHINE_KEXEC_H__
+#define __X86_MACHINE_KEXEC_H__
+
+#define KEXEC_RELOC_FLAG_COMPAT 0x1 /* 32-bit image */
+
+#ifndef __ASSEMBLY__
+
+extern void kexec_reloc(unsigned long reloc_code, unsigned long reloc_pt,
+                        unsigned long ind_maddr, unsigned long entry_maddr,
+                        unsigned long flags);
+
+#endif
+
+#endif /* __X86_MACHINE_KEXEC_H__ */
diff --git a/xen/include/xen/kexec.h b/xen/include/xen/kexec.h
index b3ca8b0..b1177d8 100644
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -6,6 +6,7 @@
 #include <public/kexec.h>
 #include <asm/percpu.h>
 #include <xen/elfcore.h>
+#include <xen/kimage.h>
 
 typedef struct xen_kexec_reserve {
     unsigned long size;
@@ -40,11 +41,11 @@ extern enum low_crashinfo low_crashinfo_mode;
 extern paddr_t crashinfo_maxaddr_bits;
 void kexec_early_calculations(void);
 
-int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
-void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
+int machine_kexec_load(struct kexec_image *image);
+void machine_kexec_unload(struct kexec_image *image);
 void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
-void machine_reboot_kexec(xen_kexec_image_t *image);
-void machine_kexec(xen_kexec_image_t *image);
+void machine_reboot_kexec(struct kexec_image *image);
+void machine_kexec(struct kexec_image *image);
 void kexec_crash(void);
 void kexec_crash_save_cpu(void);
 crash_xen_info_t *kexec_crash_save_info(void);
@@ -52,11 +53,6 @@ void machine_crash_shutdown(void);
 int machine_kexec_get(xen_kexec_range_t *range);
 int machine_kexec_get_xen(xen_kexec_range_t *range);
 
-void compat_machine_kexec(unsigned long rnk,
-                          unsigned long indirection_page,
-                          unsigned long *page_list,
-                          unsigned long start_address);
-
 /* vmcoreinfo stuff */
 #define VMCOREINFO_BYTES           (4096)
 #define VMCOREINFO_NOTE_NAME       "VMCOREINFO_XEN"
-- 
1.7.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 Feb 21 17:48:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aFz-00058q-Jx; Thu, 21 Feb 2013 17:48:31 +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 1U8aFy-00058G-3i
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:30 +0000
Received: from [193.109.254.147:38518] by server-13.bemta-14.messagelabs.com
	id 31/C8-30639-DED56215; Thu, 21 Feb 2013 17:48:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361468904!2317886!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23398 invoked from network); 21 Feb 2013 17:48:27 -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;
	21 Feb 2013 17:48:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8370825"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-HB;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:11 +0000
Message-ID: <1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
	load/unload 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>
Content-Type: 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 existing kexec hypercall, the load and unload ops depend on
internals of the Linux kernel (the page list and code page provided by
the kernel).  The code page is used to transition between Xen context
and the image so using kernel code doesn't make sense and will not
work for PVH guests.

Add replacement KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload ops
that no longer require a code page to be provided by the guest -- Xen
now provides the code for calling the image directly.

The new load op looks similar to the Linux kexec_load system call and
allows the guest to provide the image data to be loaded.  The guest
specifies the architecture of the image which may be a 32-bit subarch
of the hypervisor's architecture (i.e., an EM_386 image on an
EM_X86_64 hypervisor).

The toolstack can now load images without kernel involvement.  This is
required for supporting kexec when using a dom0 with an upstream
kernel.

Crash images are copied directly into the crash region on load.
Default images are copied into Xen heap pages and a list of source and
destination machine addresses is created.  This is list is used in
kexec_reloc() to relocate the image to its destination.

The old load and unload sub-ops are still available (as
KEXEC_CMD_load_v1 and KEXEC_CMD_unload_v1) and are implemented on top
of the new infrastructure.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/x86/machine_kexec.c        |  261 ++++++++++++++++++-------
 xen/arch/x86/x86_64/Makefile        |    2 +-
 xen/arch/x86/x86_64/compat_kexec.S  |  187 -----------------
 xen/arch/x86/x86_64/kexec_reloc.S   |  229 +++++++++++++++++++++
 xen/common/kexec.c                  |  377 +++++++++++++++++++++++++++++------
 xen/include/asm-x86/fixmap.h        |    3 -
 xen/include/asm-x86/machine_kexec.h |   14 ++
 xen/include/xen/kexec.h             |   14 +-
 8 files changed, 755 insertions(+), 332 deletions(-)
 delete mode 100644 xen/arch/x86/x86_64/compat_kexec.S
 create mode 100644 xen/arch/x86/x86_64/kexec_reloc.S
 create mode 100644 xen/include/asm-x86/machine_kexec.h

diff --git a/xen/arch/x86/machine_kexec.c b/xen/arch/x86/machine_kexec.c
index 8191ef1..0ec8c56 100644
--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -1,9 +1,18 @@
 /******************************************************************************
  * machine_kexec.c
  *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ *
+ * Portions derived from Linux's arch/x86/kernel/machine_kexec_64.c.
+ *
+ *   Copyright (C) 2002-2005 Eric Biederman  <ebiederm@xmission.com>
+ *
  * Xen port written by:
  * - Simon 'Horms' Horman <horms@verge.net.au>
  * - Magnus Damm <magnus@valinux.co.jp>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
  */
 
 #include <xen/types.h>
@@ -11,63 +20,195 @@
 #include <xen/guest_access.h>
 #include <asm/fixmap.h>
 #include <asm/hpet.h>
+#include <asm/page.h>
+#include <asm/machine_kexec.h>
+
+static void init_level2_page(l2_pgentry_t *l2, unsigned long addr)
+{
+    unsigned long end_addr;
+
+    addr &= PAGE_MASK;
+    end_addr = addr + L2_PAGETABLE_ENTRIES * (1ul << L2_PAGETABLE_SHIFT);
+
+    while ( addr < end_addr )
+    {
+        l2e_write(l2++, l2e_from_paddr(addr, __PAGE_HYPERVISOR | _PAGE_PSE));
 
-typedef void (*relocate_new_kernel_t)(
-                unsigned long indirection_page,
-                unsigned long *page_list,
-                unsigned long start_address,
-                unsigned int preserve_context);
+        addr += 1ul << L2_PAGETABLE_SHIFT;
+    }
+}
 
-int machine_kexec_load(int type, int slot, xen_kexec_image_t *image)
+static int init_level3_page(struct kexec_image *image, l3_pgentry_t *l3,
+                            unsigned long addr, unsigned long last_addr)
 {
-    unsigned long prev_ma = 0;
-    int fix_base = FIX_KEXEC_BASE_0 + (slot * (KEXEC_XEN_NO_PAGES >> 1));
-    int k;
+    unsigned long end_addr;
 
-    /* setup fixmap to point to our pages and record the virtual address
-     * in every odd index in page_list[].
-     */
+    addr &= PAGE_MASK;
+    end_addr = addr + L3_PAGETABLE_ENTRIES * (1ul << L3_PAGETABLE_SHIFT);
+
+    while( (addr < last_addr) && (addr < end_addr) )
+    {
+        struct page_info *l2_page;
+        l2_pgentry_t *l2;
+
+        l2_page = kimage_alloc_control_page(image);
+        if ( !l2_page )
+            return -ENOMEM;
+        l2 = page_to_virt(l2_page);
+
+        init_level2_page(l2, addr);
+        l3e_write(l3++, l3e_from_page(l2_page, __PAGE_HYPERVISOR));
+
+        addr += 1ul << L3_PAGETABLE_SHIFT;
+    }
+
+    return 0;
+}
+
+/*
+ * Build a complete page table to identity map [addr, last_addr).
+ *
+ * Control pages are used so they do not overlap with the image source
+ * or destination.
+ */
+static int init_level4_page(struct kexec_image *image, l4_pgentry_t *l4,
+                            unsigned long addr, unsigned long last_addr)
+{
+    unsigned long end_addr;
+    int result;
+
+    addr &= PAGE_MASK;
+    end_addr = addr + L4_PAGETABLE_ENTRIES * (1ul << L4_PAGETABLE_SHIFT);
+
+    while ( (addr < last_addr) && (addr < end_addr) )
+    {
+        struct page_info *l3_page;
+        l3_pgentry_t *l3;
+
+        l3_page = kimage_alloc_control_page(image);
+        if ( !l3_page )
+            return -ENOMEM;
+        l3 = page_to_virt(l3_page);
+
+        result = init_level3_page(image, l3, addr, last_addr);
+        if (result)
+            return result;
+        l4e_write(l4++, l4e_from_page(l3_page, __PAGE_HYPERVISOR));
+
+        addr += 1ul << L4_PAGETABLE_SHIFT;
+    }
+
+    return 0;
+}
 
-    for ( k = 0; k < KEXEC_XEN_NO_PAGES; k++ )
+/*
+ * Add a mapping for the control code page to the same virtual address
+ * as kexec_reloc.  This allows us to keep running after these page
+ * tables are loaded in kexec_reloc.
+ * 
+ * We don't really need to allocate control pages here as these
+ * entries won't be used while the kexec image is being copied, but it
+ * makes clean-up easier.
+ */
+static int init_transition_pgtable(struct kexec_image *image, l4_pgentry_t *l4)
+{
+    struct page_info *l3_page;
+    struct page_info *l2_page;
+    struct page_info *l1_page;
+    unsigned long vaddr, paddr;
+    l3_pgentry_t *l3;
+    l2_pgentry_t *l2;
+    l1_pgentry_t *l1;
+
+    vaddr = (unsigned long)kexec_reloc;
+    paddr = page_to_maddr(image->control_code_page);
+
+    l4 += l4_table_offset(vaddr);
+    if ( !(l4e_get_flags(*l4) & _PAGE_PRESENT) )
+    {
+        l3_page = kimage_alloc_control_page(image);
+        if ( !l3_page )
+            return -ENOMEM;
+        l4e_write(l4, l4e_from_page(l3_page, __PAGE_HYPERVISOR));
+    }
+
+    l3 = l4e_to_l3e(*l4) + l3_table_offset(vaddr);
+    if ( !(l3e_get_flags(*l3) & _PAGE_PRESENT) )
+    {
+        l2_page = kimage_alloc_control_page(image);
+        if ( !l2_page )
+            return -ENOMEM;
+        l3e_write(l3, l3e_from_page(l2_page, __PAGE_HYPERVISOR));
+    }
+
+    l2 = l3e_to_l2e(*l3) + l2_table_offset(vaddr);
+    if ( !(l2e_get_flags(*l2) & _PAGE_PRESENT) )
+    {
+        l1_page = kimage_alloc_control_page(image);
+        if ( !l1_page )
+            return -ENOMEM;
+        l2e_write(l2, l2e_from_page(l1_page, __PAGE_HYPERVISOR));
+    }
+
+    l1 = l2e_to_l1e(*l2) + l1_table_offset(vaddr);
+    l1e_write(l1, l1e_from_pfn(paddr >> PAGE_SHIFT, __PAGE_HYPERVISOR));
+    return 0;
+}
+
+
+static int build_reloc_page_table(struct kexec_image *image)
+{
+    struct page_info *l4_page;
+    l4_pgentry_t *l4;
+    int result;
+
+    l4_page = kimage_alloc_control_page(image);
+    if ( !l4_page )
+        return -ENOMEM;
+
+    l4 = page_to_virt(l4_page);
+    result = init_level4_page(image, l4, 0, max_page << PAGE_SHIFT);
+    if ( result )
+        return result;
+
+    result = init_transition_pgtable(image, l4);
+    if ( result )
+        return result;
+
+    image->aux_page = l4_page;
+    return 0;
+}
+
+int machine_kexec_load(struct kexec_image *image)
+{
+    void *code_page;
+    int ret;
+
+    switch ( image->arch )
     {
-        if ( (k & 1) == 0 )
-        {
-            /* Even pages: machine address. */
-            prev_ma = image->page_list[k];
-        }
-        else
-        {
-            /* Odd pages: va for previous ma. */
-            if ( is_pv_32on64_domain(dom0) )
-            {
-                /*
-                 * The compatability bounce code sets up a page table
-                 * with a 1-1 mapping of the first 1G of memory so
-                 * VA==PA here.
-                 *
-                 * This Linux purgatory code still sets up separate
-                 * high and low mappings on the control page (entries
-                 * 0 and 1) but it is harmless if they are equal since
-                 * that PT is not live at the time.
-                 */
-                image->page_list[k] = prev_ma;
-            }
-            else
-            {
-                set_fixmap(fix_base + (k >> 1), prev_ma);
-                image->page_list[k] = fix_to_virt(fix_base + (k >> 1));
-            }
-        }
+    case EM_386:
+    case EM_X86_64:
+        break;
+    default:
+        return -EINVAL;
     }
 
+    code_page = page_to_virt(image->control_code_page);
+    memcpy(code_page, kexec_reloc, PAGE_SIZE);
+
+    ret = build_reloc_page_table(image);
+    if ( ret < 0 )
+        return ret;
+
     return 0;
 }
 
-void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image)
+void machine_kexec_unload(struct kexec_image *image)
 {
+    /* no-op. kimage_free() frees all control pages. */
 }
 
-void machine_reboot_kexec(xen_kexec_image_t *image)
+void machine_reboot_kexec(struct kexec_image *image)
 {
     BUG_ON(smp_processor_id() != 0);
     smp_send_stop();
@@ -75,13 +216,10 @@ void machine_reboot_kexec(xen_kexec_image_t *image)
     BUG();
 }
 
-void machine_kexec(xen_kexec_image_t *image)
+void machine_kexec(struct kexec_image *image)
 {
-    struct desc_ptr gdt_desc = {
-        .base = (unsigned long)(boot_cpu_gdt_table - FIRST_RESERVED_GDT_ENTRY),
-        .limit = LAST_RESERVED_GDT_BYTE
-    };
     int i;
+    unsigned long reloc_flags = 0;
 
     /* We are about to permenantly jump out of the Xen context into the kexec
      * purgatory code.  We really dont want to be still servicing interupts.
@@ -109,29 +247,12 @@ void machine_kexec(xen_kexec_image_t *image)
      * not like running with NMIs disabled. */
     enable_nmis();
 
-    /*
-     * compat_machine_kexec() returns to idle pagetables, which requires us
-     * to be running on a static GDT mapping (idle pagetables have no GDT
-     * mappings in their per-domain mapping area).
-     */
-    asm volatile ( "lgdt %0" : : "m" (gdt_desc) );
+    if ( image->arch == EM_386 )
+        reloc_flags |= KEXEC_RELOC_FLAG_COMPAT;
 
-    if ( is_pv_32on64_domain(dom0) )
-    {
-        compat_machine_kexec(image->page_list[1],
-                             image->indirection_page,
-                             image->page_list,
-                             image->start_address);
-    }
-    else
-    {
-        relocate_new_kernel_t rnk;
-
-        rnk = (relocate_new_kernel_t) image->page_list[1];
-        (*rnk)(image->indirection_page, image->page_list,
-               image->start_address,
-               0 /* preserve_context */);
-    }
+    kexec_reloc(page_to_maddr(image->control_code_page), 
+                page_to_maddr(image->aux_page),
+                image->head, image->entry_maddr, reloc_flags);
 }
 
 int machine_kexec_get(xen_kexec_range_t *range)
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index d56e12d..7f8fb3d 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -11,11 +11,11 @@ obj-y += mmconf-fam10h.o
 obj-y += mmconfig_64.o
 obj-y += mmconfig-shared.o
 obj-y += compat.o
-obj-bin-y += compat_kexec.o
 obj-y += domain.o
 obj-y += physdev.o
 obj-y += platform_hypercall.o
 obj-y += cpu_idle.o
 obj-y += cpufreq.o
+obj-bin-y += kexec_reloc.o
 
 obj-$(crash_debug)   += gdbstub.o
diff --git a/xen/arch/x86/x86_64/compat_kexec.S b/xen/arch/x86/x86_64/compat_kexec.S
deleted file mode 100644
index fc92af9..0000000
--- a/xen/arch/x86/x86_64/compat_kexec.S
+++ /dev/null
@@ -1,187 +0,0 @@
-/*
- * Compatibility kexec handler.
- */
-
-/*
- * NOTE: We rely on Xen not relocating itself above the 4G boundary. This is
- * currently true but if it ever changes then compat_pg_table will
- * need to be moved back below 4G at run time.
- */
-
-#include <xen/config.h>
-
-#include <asm/asm_defns.h>
-#include <asm/msr.h>
-#include <asm/page.h>
-
-/* The unrelocated physical address of a symbol. */
-#define SYM_PHYS(sym)          ((sym) - __XEN_VIRT_START)
-
-/* Load physical address of symbol into register and relocate it. */
-#define RELOCATE_SYM(sym,reg)  mov $SYM_PHYS(sym), reg ; \
-                               add xen_phys_start(%rip), reg
-
-/*
- * Relocate a physical address in memory. Size of temporary register
- * determines size of the value to relocate.
- */
-#define RELOCATE_MEM(addr,reg) mov addr(%rip), reg ; \
-                               add xen_phys_start(%rip), reg ; \
-                               mov reg, addr(%rip)
-
-        .text
-
-        .code64
-
-ENTRY(compat_machine_kexec)
-        /* x86/64                        x86/32  */
-        /* %rdi - relocate_new_kernel_t  CALL    */
-        /* %rsi - indirection page       4(%esp) */
-        /* %rdx - page_list              8(%esp) */
-        /* %rcx - start address         12(%esp) */
-        /*        cpu has pae           16(%esp) */
-
-        /* Shim the 64 bit page_list into a 32 bit page_list. */
-        mov $12,%r9
-        lea compat_page_list(%rip), %rbx
-1:      dec %r9
-        movl (%rdx,%r9,8),%eax
-        movl %eax,(%rbx,%r9,4)
-        test %r9,%r9
-        jnz 1b
-
-        RELOCATE_SYM(compat_page_list,%rdx)
-
-        /* Relocate compatibility mode entry point address. */
-        RELOCATE_MEM(compatibility_mode_far,%eax)
-
-        /* Relocate compat_pg_table. */
-        RELOCATE_MEM(compat_pg_table,     %rax)
-        RELOCATE_MEM(compat_pg_table+0x8, %rax)
-        RELOCATE_MEM(compat_pg_table+0x10,%rax)
-        RELOCATE_MEM(compat_pg_table+0x18,%rax)
-
-        /*
-         * Setup an identity mapped region in PML4[0] of idle page
-         * table.
-         */
-        RELOCATE_SYM(l3_identmap,%rax)
-        or  $0x63,%rax
-        mov %rax, idle_pg_table(%rip)
-
-        /* Switch to idle page table. */
-        RELOCATE_SYM(idle_pg_table,%rax)
-        movq %rax, %cr3
-
-        /* Switch to identity mapped compatibility stack. */
-        RELOCATE_SYM(compat_stack,%rax)
-        movq %rax, %rsp
-
-        /* Save xen_phys_start for 32 bit code. */
-        movq xen_phys_start(%rip), %rbx
-
-        /* Jump to low identity mapping in compatibility mode. */
-        ljmp *compatibility_mode_far(%rip)
-        ud2
-
-compatibility_mode_far:
-        .long SYM_PHYS(compatibility_mode)
-        .long __HYPERVISOR_CS32
-
-        /*
-         * We use 5 words of stack for the arguments passed to the kernel. The
-         * kernel only uses 1 word before switching to its own stack. Allocate
-         * 16 words to give "plenty" of room.
-         */
-        .fill 16,4,0
-compat_stack:
-
-        .code32
-
-#undef RELOCATE_SYM
-#undef RELOCATE_MEM
-
-/*
- * Load physical address of symbol into register and relocate it. %rbx
- * contains xen_phys_start(%rip) saved before jump to compatibility
- * mode.
- */
-#define RELOCATE_SYM(sym,reg) mov $SYM_PHYS(sym), reg ; \
-                              add %ebx, reg
-
-compatibility_mode:
-        /* Setup some sane segments. */
-        movl $__HYPERVISOR_DS32, %eax
-        movl %eax, %ds
-        movl %eax, %es
-        movl %eax, %fs
-        movl %eax, %gs
-        movl %eax, %ss
-
-        /* Push arguments onto stack. */
-        pushl $0   /* 20(%esp) - preserve context */
-        pushl $1   /* 16(%esp) - cpu has pae */
-        pushl %ecx /* 12(%esp) - start address */
-        pushl %edx /*  8(%esp) - page list */
-        pushl %esi /*  4(%esp) - indirection page */
-        pushl %edi /*  0(%esp) - CALL */
-
-        /* Disable paging and therefore leave 64 bit mode. */
-        movl %cr0, %eax
-        andl $~X86_CR0_PG, %eax
-        movl %eax, %cr0
-
-        /* Switch to 32 bit page table. */
-        RELOCATE_SYM(compat_pg_table, %eax)
-        movl  %eax, %cr3
-
-        /* Clear MSR_EFER[LME], disabling long mode */
-        movl    $MSR_EFER,%ecx
-        rdmsr
-        btcl    $_EFER_LME,%eax
-        wrmsr
-
-        /* Re-enable paging, but only 32 bit mode now. */
-        movl %cr0, %eax
-        orl $X86_CR0_PG, %eax
-        movl %eax, %cr0
-        jmp 1f
-1:
-
-        popl %eax
-        call *%eax
-        ud2
-
-        .data
-        .align 4
-compat_page_list:
-        .fill 12,4,0
-
-        .align 32,0
-
-        /*
-         * These compat page tables contain an identity mapping of the
-         * first 4G of the physical address space.
-         */
-compat_pg_table:
-        .long SYM_PHYS(compat_pg_table_l2) + 0*PAGE_SIZE + 0x01, 0
-        .long SYM_PHYS(compat_pg_table_l2) + 1*PAGE_SIZE + 0x01, 0
-        .long SYM_PHYS(compat_pg_table_l2) + 2*PAGE_SIZE + 0x01, 0
-        .long SYM_PHYS(compat_pg_table_l2) + 3*PAGE_SIZE + 0x01, 0
-
-        .section .data.page_aligned, "aw", @progbits
-        .align PAGE_SIZE,0
-compat_pg_table_l2:
-        .macro identmap from=0, count=512
-        .if \count-1
-        identmap "(\from+0)","(\count/2)"
-        identmap "(\from+(0x200000*(\count/2)))","(\count/2)"
-        .else
-        .quad 0x00000000000000e3 + \from
-        .endif
-        .endm
-
-        identmap 0x00000000
-        identmap 0x40000000
-        identmap 0x80000000
-        identmap 0xc0000000
diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S
new file mode 100644
index 0000000..e68842c
--- /dev/null
+++ b/xen/arch/x86/x86_64/kexec_reloc.S
@@ -0,0 +1,229 @@
+/*
+ * Relocate a kexec_image to its destination and call it.
+ *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ *
+ * Portions derived from Linux's arch/x86/kernel/relocate_kernel_64.S.
+ * 
+ *   Copyright (C) 2002-2005 Eric Biederman  <ebiederm@xmission.com>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+#include <xen/config.h>
+
+#include <asm/asm_defns.h>
+#include <asm/msr.h>
+#include <asm/page.h>
+#include <asm/machine_kexec.h>
+
+/* The unrelocated physical address of a symbol. */
+#define SYM_PHYS(sym)          ((sym) - __XEN_VIRT_START)
+
+/* Load physical address of symbol into register and relocate it. */
+#define RELOCATE_SYM(sym,reg)  mov $SYM_PHYS(sym), reg ; \
+                               add xen_phys_start(%rip), reg
+
+#define DBG(c) \
+1:      mov     $0x3f8+5, %dx ; \
+        inb     %dx, %al     ; \
+        test    $0x20, %al   ; \
+        je      1b           ; \
+        mov     $0x3f8, %dx  ; \
+        mov     $c, %al      ; \
+        outb    %al, %dx     ;
+
+        .text
+	.align PAGE_SIZE
+        .code64
+
+ENTRY(kexec_reloc)
+        /* %rdi - code_page maddr */
+        /* %rsi - page table maddr */
+        /* %rdx - indirection page maddr */
+        /* %rcx - entry maddr */
+        /* %r8 - flags */
+
+        mov %rdx, %rbx
+
+        DBG('A')
+
+        /* Setup stack. */
+        RELOCATE_SYM(reloc_stack, %rax)
+        mov %rax, %rsp
+
+        DBG('B')
+
+        wbinvd
+        movq %cr4, %rax
+        andq $~(X86_CR4_PGE|X86_CR4_PCE|X86_CR4_MCE), %rax
+        movq %rax, %cr4
+
+        /* Load reloc page table. */
+        movq %rsi, %cr3
+
+        DBG('C')
+
+        /* Jump to identity mapped code. */
+        movq %rdi, %r9
+        addq $(identity_mapped - kexec_reloc), %r9
+
+        DBG('D')
+
+        jmp *%r9
+
+identity_mapped:
+        DBG('E')
+        
+        pushq %rcx
+        pushq %rbx
+        pushq %rsi
+        pushq %rdi
+
+        movq %rbx, %rdi
+        call swap_pages
+
+        popq %rdi
+        popq %rsi
+        popq %rbx
+        popq %rcx
+
+        DBG('F')
+
+        /* Need to switch to 32-bit mode? */
+        testq $KEXEC_RELOC_FLAG_COMPAT, %r8
+        jnz call_32_bit
+
+call_64_bit:
+        DBG('6')
+
+        /* Call the image entry point.  This should never return. */
+        call *%rcx
+        ud2
+
+call_32_bit:
+        DBG('3')
+
+        /* Relocate compatibility mode entry point address. */
+        movl %edi, %eax
+        addl $(compatibility_mode - kexec_reloc), %eax
+        movl %eax, compatibility_mode_far(%rip)
+
+        DBG('I')
+        
+        /* Load compat GDT. */
+        movq %rdi, %rax
+        addq $(compat_mode_gdt - kexec_reloc), %rax
+        movq %rax, (compat_mode_gdt_desc + 2)(%rip)
+        lgdt compat_mode_gdt_desc(%rip)
+
+        DBG('J')
+        
+        /* Enter compatibility mode. */
+        ljmp *compatibility_mode_far(%rip)
+
+swap_pages:
+        /* %rdi - indirection page maddr */
+        movq    %rdi, %rcx
+        xorq    %rdi, %rdi
+        xorq    %rsi, %rsi
+        jmp     1f
+
+0:      /* top, read another word for the indirection page */
+
+        movq    (%rbx), %rcx
+        addq    $8,     %rbx
+1:
+        testq   $0x1,   %rcx  /* is it a destination page? */
+        jz      2f
+        movq    %rcx,   %rdi
+        andq    $0xfffffffffffff000, %rdi
+        jmp     0b
+2:
+        testq   $0x2,   %rcx  /* is it an indirection page? */
+        jz      2f
+        movq    %rcx,   %rbx
+        andq    $0xfffffffffffff000, %rbx
+        jmp     0b
+2:
+        testq   $0x4,   %rcx  /* is it the done indicator? */
+        jz      2f
+        jmp     3f
+2:
+        testq   $0x8,   %rcx  /* is it the source indicator? */
+        jz      0b            /* Ignore it otherwise */
+        movq    %rcx,   %rsi  /* For ever source page do a copy */
+        andq    $0xfffffffffffff000, %rsi
+
+        movq    %rdi, %rdx
+        movq    %rsi, %rax
+
+        movq    %r10, %rdi
+        movq    $512,   %rcx
+        rep movsq
+
+        movq    %rax, %rdi
+        movq    %rdx, %rsi
+        movq    $512,   %rcx
+        rep movsq
+
+        movq    %rdx, %rdi
+        movq    %r10, %rsi
+        movq    $512,   %rcx
+        rep movsq
+
+        lea     PAGE_SIZE(%rax), %rsi
+        jmp     0b
+3:
+        ret
+
+        .code32
+
+compatibility_mode:
+        DBG('K')
+
+        /* Setup some sane segments. */
+        movl $0x0008, %eax
+        movl %eax, %ds
+        movl %eax, %es
+        movl %eax, %fs
+        movl %eax, %gs
+        movl %eax, %ss
+
+        DBG('L')
+        
+        /* Disable paging and therefore leave 64 bit mode. */
+        movl %cr0, %eax
+        andl $~X86_CR0_PG, %eax
+        movl %eax, %cr0
+
+        DBG('M')
+
+        /* Call the image entry point.  This should never return. */
+        call *%ecx
+        ud2
+
+        .align 16
+compatibility_mode_far:
+        .long SYM_PHYS(compatibility_mode)
+        .word 0x0010
+
+        .align 16
+compat_mode_gdt_desc:
+        .word (3*8)-1
+        .quad SYM_PHYS(compat_mode_gdt)
+
+        .align 16
+compat_mode_gdt:
+        .quad 0x0000000000000000     /* null                              */
+        .quad 0x00cf92000000ffff     /* 0x0008 ring 0 data                */
+        .quad 0x00cf9a000000ffff     /* 0x0010 ring 0 code, compatibility */
+
+        /*
+         * 16 words of stack are more than enough.
+         */
+        .fill 16,8,0
+reloc_stack:
+
+        .globl kexec_reloc_size
+        .set kexec_reloc_size, . - kexec_reloc
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2cbb62c..2926274 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -23,6 +23,7 @@
 #include <xen/version.h>
 #include <xen/console.h>
 #include <xen/kexec.h>
+#include <xen/kimage.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
 #include <xen/cpu.h>
@@ -45,7 +46,7 @@ static Elf_Note *xen_crash_note;
 
 static cpumask_t crash_saved_cpus;
 
-static xen_kexec_image_t kexec_image[KEXEC_IMAGE_NR];
+static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];
 
 #define KEXEC_FLAG_DEFAULT_POS   (KEXEC_IMAGE_NR + 0)
 #define KEXEC_FLAG_CRASH_POS     (KEXEC_IMAGE_NR + 1)
@@ -309,14 +310,14 @@ void kexec_crash(void)
     kexec_common_shutdown();
     kexec_crash_save_cpu();
     machine_crash_shutdown();
-    machine_kexec(&kexec_image[KEXEC_IMAGE_CRASH_BASE + pos]);
+    machine_kexec(kexec_image[KEXEC_IMAGE_CRASH_BASE + pos]);
 
     BUG();
 }
 
 static long kexec_reboot(void *_image)
 {
-    xen_kexec_image_t *image = _image;
+    struct kexec_image *image = _image;
 
     kexecing = TRUE;
 
@@ -732,63 +733,245 @@ static void crash_save_vmcoreinfo(void)
 #endif
 }
 
-static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_v1_t *load)
+static void kexec_unload_image(struct kexec_image *image)
+{
+    if ( !image )
+        return;
+
+    machine_kexec_unload(image);
+}
+
+static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    xen_kexec_exec_t exec;
+    struct kexec_image *image;
+    int base, bit, pos, ret = -EINVAL;
+
+    if ( unlikely(copy_from_guest(&exec, uarg, 1)) )
+        return -EFAULT;
+
+    if ( kexec_load_get_bits(exec.type, &base, &bit) )
+        return -EINVAL;
+
+    pos = (test_bit(bit, &kexec_flags) != 0);
+
+    /* Only allow kexec/kdump into loaded images */
+    if ( !test_bit(base + pos, &kexec_flags) )
+        return -ENOENT;
+
+    switch (exec.type)
+    {
+    case KEXEC_TYPE_DEFAULT:
+        image = kexec_image[base + pos];
+        ret = continue_hypercall_on_cpu(0, kexec_reboot, image);
+        break;
+    case KEXEC_TYPE_CRASH:
+        kexec_crash(); /* Does not return */
+        break;
+    }
+
+    return -EINVAL; /* never reached */
+}
+
+static int kexec_swap_images(int type, struct kexec_image *new,
+                             struct kexec_image **old)
 {
-    xen_kexec_image_t *image;
     int base, bit, pos;
-    int ret = 0;
+    int new_slot, old_slot;
+
+    *old = NULL;
+
+    spin_lock(&kexec_lock);
+
+    if ( test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags) )
+    {
+        spin_unlock(&kexec_lock);
+        return -EBUSY;
+    }
 
-    if ( kexec_load_get_bits(load->type, &base, &bit) )
+    if ( kexec_load_get_bits(type, &base, &bit) )
         return -EINVAL;
 
     pos = (test_bit(bit, &kexec_flags) != 0);
+    old_slot = base + pos;
+    new_slot = base + !pos;
 
-    /* Load the user data into an unused image */
-    if ( op == KEXEC_CMD_kexec_load )
+    if ( new )
     {
-        image = &kexec_image[base + !pos];
+        kexec_image[new_slot] = new;
+        set_bit(new_slot, &kexec_flags);
+    }
+    change_bit(bit, &kexec_flags);
 
-        BUG_ON(test_bit((base + !pos), &kexec_flags)); /* must be free */
+    clear_bit(old_slot, &kexec_flags);
+    *old = kexec_image[old_slot];
 
-        memcpy(image, &load->image, sizeof(*image));
+    spin_unlock(&kexec_lock);
 
-        if ( !(ret = machine_kexec_load(load->type, base + !pos, image)) )
-        {
-            /* Set image present bit */
-            set_bit((base + !pos), &kexec_flags);
+    return 0;
+}
 
-            /* Make new image the active one */
-            change_bit(bit, &kexec_flags);
-        }
+static int kexec_load_slot(struct kexec_image *kimage)
+{
+    struct kexec_image *old_kimage;
+    int ret = -ENOMEM;
+
+    ret = machine_kexec_load(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    crash_save_vmcoreinfo();
 
-        crash_save_vmcoreinfo();
+    ret = kexec_swap_images(kimage->type, kimage, &old_kimage);
+    if ( ret < 0 )
+        goto error;
+
+    kexec_unload_image(old_kimage);
+    
+    return 0;
+
+error:
+    kimage_free(kimage);
+    return ret;
+}
+
+static uint16_t kexec_load_v1_arch(void)
+{
+#ifdef CONFIG_X86
+    return is_pv_32on64_domain(dom0) ? EM_386 : EM_X86_64;
+#else
+    return EM_NONE;
+#endif
+}
+
+static int kexec_segments_add_page(unsigned *nr_segments,
+                                   xen_kexec_segment_t *segments,
+                                   unsigned long mfn)
+{
+    unsigned long maddr = mfn << PAGE_SHIFT;
+    int n = *nr_segments;
+
+    /* Need a new segment? */
+    if ( n == 0
+         || segments[n-1].dest_maddr + segments[n-1].dest_size != maddr )
+    {
+        n++;
+        if ( n == KEXEC_SEGMENT_MAX )
+            return -EINVAL;
+        *nr_segments = n;
+
+        set_xen_guest_handle(segments[n-1].buf, NULL);
+        segments[n-1].buf_size = 0;
+        segments[n-1].dest_maddr = maddr;
+        segments[n-1].dest_size = 0;
     }
 
-    /* Unload the old image if present and load successful */
-    if ( ret == 0 && !test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags) )
+    segments[n-1].dest_size += PAGE_SIZE;
+
+    return 0;
+}
+
+static int kexec_segments_from_ind_page(unsigned long mfn,
+                                        unsigned *nr_segments,
+                                        xen_kexec_segment_t *segments)
+{
+    void *page;
+    unsigned long *entry;
+    int ret;
+
+    page = vmap(&mfn, 1);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    /*
+     * Walk the indirection page list, adding destination pages to the
+     * segments.
+     */
+    for ( entry = page; ; entry++ )
     {
-        if ( test_and_clear_bit((base + pos), &kexec_flags) )
+        unsigned long ind;
+
+        ind = (*entry) & 0xf;
+        mfn = (*entry) >> PAGE_SHIFT;
+
+        switch ( ind )
         {
-            image = &kexec_image[base + pos];
-            machine_kexec_unload(load->type, base + pos, image);
+        case IND_DESTINATION:
+            ret = kexec_segments_add_page(nr_segments, segments, mfn);
+            if ( ret < 0 )
+                return ret;
+            break;
+        case IND_INDIRECTION:
+            vunmap(page);
+            page = vmap(&mfn, 1);
+            if ( page == NULL )
+                return -ENOMEM;
+            entry = page;
+            break;
+        case IND_DONE:
+            goto done;
+        case IND_SOURCE:
+            break;
         }
     }
+done:
+    return 0;
+}
+
+static int kexec_do_load_v1(xen_kexec_load_v1_t *load)
+{
+    struct kexec_image *kimage = NULL;
+    xen_kexec_segment_t *segments;
+    uint16_t arch;
+    unsigned nr_segments = 0;
+    int ret;
+
+    arch = kexec_load_v1_arch();
+    if ( arch == EM_NONE )
+        return -ENOSYS;
+
+    segments = xmalloc_array(xen_kexec_segment_t, KEXEC_SEGMENT_MAX);
+    if ( segments == NULL )
+        return -ENOMEM;
+
+    ret = kexec_segments_from_ind_page(load->image.indirection_page >> PAGE_SHIFT,
+                                       &nr_segments, segments);
+    if ( ret < 0 )
+        goto error;
+
+    ret = kimage_alloc(&kimage, load->type, arch, load->image.start_address,
+                       nr_segments, segments);
+    if ( ret < 0 )
+        goto error;
+
+    /* kexec_reloc() uses the same format for the indirection pages so
+       reuse the provided ones. */
+    kimage->head = load->image.indirection_page;
+
+    ret = kexec_load_slot(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    return 0;
 
+error:
+    if ( !kimage )
+        xfree(segments);
+    kimage_free(kimage);
     return ret;
 }
 
-static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
+static int kexec_load_v1(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_load_v1_t load;
 
     if ( unlikely(copy_from_guest(&load, uarg, 1)) )
         return -EFAULT;
 
-    return kexec_load_unload_internal(op, &load);
+    return kexec_do_load_v1(&load);
 }
 
-static int kexec_load_unload_compat(unsigned long op,
-                                    XEN_GUEST_HANDLE_PARAM(void) uarg)
+static int kexec_load_v1_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
     compat_kexec_load_v1_t compat_load;
@@ -807,49 +990,113 @@ static int kexec_load_unload_compat(unsigned long op,
     load.type = compat_load.type;
     XLAT_kexec_image(&load.image, &compat_load.image);
 
-    return kexec_load_unload_internal(op, &load);
-#else /* CONFIG_COMPAT */
+    return kexec_do_load_v1(&load);
+#else
     return 0;
-#endif /* CONFIG_COMPAT */
+#endif
 }
 
-static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
+static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
-    xen_kexec_exec_t exec;
-    xen_kexec_image_t *image;
-    int base, bit, pos, ret = -EINVAL;
+    xen_kexec_load_t load;
+    xen_kexec_segment_t *segments;
+    struct kexec_image *kimage = NULL;
+    int ret;
 
-    if ( unlikely(copy_from_guest(&exec, uarg, 1)) )
+    if ( copy_from_guest(&load, uarg, 1) )
         return -EFAULT;
 
-    if ( kexec_load_get_bits(exec.type, &base, &bit) )
+    if ( load.nr_segments >= KEXEC_SEGMENT_MAX )
         return -EINVAL;
 
-    pos = (test_bit(bit, &kexec_flags) != 0);
-
-    /* Only allow kexec/kdump into loaded images */
-    if ( !test_bit(base + pos, &kexec_flags) )
-        return -ENOENT;
+    segments = xmalloc_array(xen_kexec_segment_t, load.nr_segments);
+    if ( segments == NULL )
+        return -ENOMEM;
 
-    switch (exec.type)
+    if ( copy_from_guest(segments, load.segments, load.nr_segments) )
     {
-    case KEXEC_TYPE_DEFAULT:
-        image = &kexec_image[base + pos];
-        ret = continue_hypercall_on_cpu(0, kexec_reboot, image);
-        break;
-    case KEXEC_TYPE_CRASH:
-        kexec_crash(); /* Does not return */
-        break;
+        ret = -EFAULT;
+        goto error;
     }
 
-    return -EINVAL; /* never reached */
+    ret = kimage_alloc(&kimage, load.type, load.arch, load.entry_maddr,
+                       load.nr_segments, segments);
+    if ( ret < 0 )
+        goto error;
+
+    ret = kimage_load_segments(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    ret = kexec_load_slot(kimage);
+    if ( ret < 0 )
+        goto error;
+
+    return 0;
+
+error:
+    if ( ! kimage )
+        xfree(segments);
+    kimage_free(kimage);
+    return ret;
+}
+
+static int kexec_do_unload(xen_kexec_unload_t *unload)
+{
+    struct kexec_image *old_kimage;
+    int ret;
+
+    ret = kexec_swap_images(unload->type, NULL, &old_kimage);
+    if ( ret < 0 )
+        return ret;
+
+    kexec_unload_image(old_kimage);
+
+    return 0;
+}
+
+static int kexec_unload_v1(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    xen_kexec_load_v1_t load;
+    xen_kexec_unload_t unload;
+
+    if ( copy_from_guest(&load, uarg, 1) )
+        return -EFAULT;
+
+    unload.type = load.type;
+    return kexec_do_unload(&unload);
+}
+
+static int kexec_unload_v1_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+#ifdef CONFIG_COMPAT
+    compat_kexec_load_v1_t compat_load;
+    xen_kexec_unload_t unload;
+
+    if ( copy_from_guest(&compat_load, uarg, 1) )
+        return -EFAULT;
+
+    unload.type = compat_load.type;
+    return kexec_do_unload(&unload);
+#else
+    return 0;
+#endif
+}
+
+static int kexec_unload(XEN_GUEST_HANDLE_PARAM(void) uarg)
+{
+    xen_kexec_unload_t unload;
+
+    if ( unlikely(copy_from_guest(&unload, uarg, 1)) )
+        return -EFAULT;
+
+    return kexec_do_unload(&unload);
 }
 
 static int do_kexec_op_internal(unsigned long op,
                                 XEN_GUEST_HANDLE_PARAM(void) uarg,
                                 bool_t compat)
 {
-    unsigned long flags;
     int ret = -EINVAL;
 
     ret = xsm_kexec(XSM_PRIV);
@@ -865,20 +1112,26 @@ static int do_kexec_op_internal(unsigned long op,
                 ret = kexec_get_range(uarg);
         break;
     case KEXEC_CMD_kexec_load_v1:
+        if ( compat )
+            ret = kexec_load_v1_compat(uarg);
+        else
+            ret = kexec_load_v1(uarg);
+        break;
     case KEXEC_CMD_kexec_unload_v1:
-        spin_lock_irqsave(&kexec_lock, flags);
-        if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
-        {
-                if (compat)
-                        ret = kexec_load_unload_compat(op, uarg);
-                else
-                        ret = kexec_load_unload(op, uarg);
-        }
-        spin_unlock_irqrestore(&kexec_lock, flags);
+        if ( compat )
+            ret = kexec_unload_v1_compat(uarg);
+        else
+            ret = kexec_unload_v1(uarg);
         break;
     case KEXEC_CMD_kexec:
         ret = kexec_exec(uarg);
         break;
+    case KEXEC_CMD_kexec_load:
+        ret = kexec_load(uarg);
+        break;
+    case KEXEC_CMD_kexec_unload:
+        ret = kexec_unload(uarg);
+        break;
     }
 
     return ret;
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index 2eefcf4..1695228 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -57,9 +57,6 @@ enum fixed_addresses {
     FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
     FIX_HPET_BASE,
     FIX_CYCLONE_TIMER,
-    FIX_KEXEC_BASE_0,
-    FIX_KEXEC_BASE_END = FIX_KEXEC_BASE_0 \
-      + ((KEXEC_XEN_NO_PAGES >> 1) * KEXEC_IMAGE_NR) - 1,
     FIX_IOMMU_REGS_BASE_0,
     FIX_IOMMU_REGS_END = FIX_IOMMU_REGS_BASE_0 + MAX_IOMMUS-1,
     FIX_IOMMU_MMIO_BASE_0,
diff --git a/xen/include/asm-x86/machine_kexec.h b/xen/include/asm-x86/machine_kexec.h
new file mode 100644
index 0000000..ec41099
--- /dev/null
+++ b/xen/include/asm-x86/machine_kexec.h
@@ -0,0 +1,14 @@
+#ifndef __X86_MACHINE_KEXEC_H__
+#define __X86_MACHINE_KEXEC_H__
+
+#define KEXEC_RELOC_FLAG_COMPAT 0x1 /* 32-bit image */
+
+#ifndef __ASSEMBLY__
+
+extern void kexec_reloc(unsigned long reloc_code, unsigned long reloc_pt,
+                        unsigned long ind_maddr, unsigned long entry_maddr,
+                        unsigned long flags);
+
+#endif
+
+#endif /* __X86_MACHINE_KEXEC_H__ */
diff --git a/xen/include/xen/kexec.h b/xen/include/xen/kexec.h
index b3ca8b0..b1177d8 100644
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -6,6 +6,7 @@
 #include <public/kexec.h>
 #include <asm/percpu.h>
 #include <xen/elfcore.h>
+#include <xen/kimage.h>
 
 typedef struct xen_kexec_reserve {
     unsigned long size;
@@ -40,11 +41,11 @@ extern enum low_crashinfo low_crashinfo_mode;
 extern paddr_t crashinfo_maxaddr_bits;
 void kexec_early_calculations(void);
 
-int machine_kexec_load(int type, int slot, xen_kexec_image_t *image);
-void machine_kexec_unload(int type, int slot, xen_kexec_image_t *image);
+int machine_kexec_load(struct kexec_image *image);
+void machine_kexec_unload(struct kexec_image *image);
 void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
-void machine_reboot_kexec(xen_kexec_image_t *image);
-void machine_kexec(xen_kexec_image_t *image);
+void machine_reboot_kexec(struct kexec_image *image);
+void machine_kexec(struct kexec_image *image);
 void kexec_crash(void);
 void kexec_crash_save_cpu(void);
 crash_xen_info_t *kexec_crash_save_info(void);
@@ -52,11 +53,6 @@ void machine_crash_shutdown(void);
 int machine_kexec_get(xen_kexec_range_t *range);
 int machine_kexec_get_xen(xen_kexec_range_t *range);
 
-void compat_machine_kexec(unsigned long rnk,
-                          unsigned long indirection_page,
-                          unsigned long *page_list,
-                          unsigned long start_address);
-
 /* vmcoreinfo stuff */
 #define VMCOREINFO_BYTES           (4096)
 #define VMCOREINFO_NOTE_NAME       "VMCOREINFO_XEN"
-- 
1.7.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 Feb 21 17:48:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aFy-00058H-1U; Thu, 21 Feb 2013 17:48:30 +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 1U8aFw-000581-B8
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:28 +0000
Received: from [193.109.254.147:28859] by server-12.bemta-14.messagelabs.com
	id 92/C8-32582-BED56215; Thu, 21 Feb 2013 17:48:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361468904!2317886!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23378 invoked from network); 21 Feb 2013 17:48:27 -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;
	21 Feb 2013 17:48:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8370823"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Jy;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:13 +0000
Message-ID: <1361468894-18655-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] libxc: add hypercall buffer 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

From: David Vrabel <david.vrabel@citrix.com>

Hypercall buffer arrays are used when a hypercall takes a variable
length array of buffers.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/xc_hcall_buf.c |   73 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h      |   27 ++++++++++++++++
 2 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/tools/libxc/xc_hcall_buf.c b/tools/libxc/xc_hcall_buf.c
index ced9abd..3e01f3f 100644
--- a/tools/libxc/xc_hcall_buf.c
+++ b/tools/libxc/xc_hcall_buf.c
@@ -228,6 +228,79 @@ void xc__hypercall_bounce_post(xc_interface *xch, xc_hypercall_buffer_t *b)
     xc__hypercall_buffer_free(xch, b);
 }
 
+struct xc_hypercall_buffer_array {
+    unsigned max_bufs;
+    xc_hypercall_buffer_t *bufs;
+};
+
+xc_hypercall_buffer_array_t *xc_hypercall_buffer_array_create(xc_interface *xch,
+                                                              unsigned n)
+{
+    xc_hypercall_buffer_array_t *array;
+    xc_hypercall_buffer_t *bufs = NULL;
+
+    array = malloc(sizeof(*array));
+    if ( array == NULL )
+        goto error;
+
+    bufs = calloc(n, sizeof(*bufs));
+    if ( bufs == NULL )
+        goto error;
+
+    array->max_bufs = n;
+    array->bufs     = bufs;
+
+    return array;
+
+error:
+    free(bufs);
+    free(array);
+    return NULL;
+}
+
+void *xc__hypercall_buffer_array_alloc(xc_interface *xch,
+                                       xc_hypercall_buffer_array_t *array,
+                                       unsigned index,
+                                       xc_hypercall_buffer_t *hbuf,
+                                       size_t size)
+{
+    void *buf;
+
+    if ( index >= array->max_bufs || array->bufs[index].hbuf )
+        abort();
+
+    buf = xc__hypercall_buffer_alloc(xch, hbuf, size);
+    if ( buf )
+        array->bufs[index] = *hbuf;
+    return buf;
+}
+
+void *xc__hypercall_buffer_array_get(xc_interface *xch,
+                                     xc_hypercall_buffer_array_t *array,
+                                     unsigned index,
+                                     xc_hypercall_buffer_t *hbuf)
+{
+    if ( index >= array->max_bufs || array->bufs[index].hbuf == NULL )
+        abort();
+
+    *hbuf = array->bufs[index];
+    return array->bufs[index].hbuf;
+}
+
+void xc_hypercall_buffer_array_destroy(xc_interface *xc,
+                                       xc_hypercall_buffer_array_t *array)
+{
+    unsigned i;
+
+    if ( array == NULL )
+        return;
+
+    for (i = 0; i < array->max_bufs; i++ )
+        xc__hypercall_buffer_free(xc, &array->bufs[i]);
+    free(array->bufs);
+    free(array);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 32122fd..c3b2c28 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -317,6 +317,33 @@ void xc__hypercall_buffer_free_pages(xc_interface *xch, xc_hypercall_buffer_t *b
 #define xc_hypercall_buffer_free_pages(_xch, _name, _nr) xc__hypercall_buffer_free_pages(_xch, HYPERCALL_BUFFER(_name), _nr)
 
 /*
+ * Array of hypercall buffers.
+ *
+ * Create an array with xc_hypercall_buffer_array_create() and
+ * populate it by declaring one hypercall buffer in a loop and
+ * allocating the buffer with xc_hypercall_buffer_array_alloc().
+ *
+ * To access a previously allocated buffers, declare a new hypercall
+ * buffer and call xc_hypercall_buffer_array_get().
+ *
+ * Destroy the array with xc_hypercall_buffer_array_destroy() to free
+ * the array and all its alocated hypercall buffers.
+ */
+struct xc_hypercall_buffer_array;
+typedef struct xc_hypercall_buffer_array xc_hypercall_buffer_array_t;
+
+xc_hypercall_buffer_array_t *xc_hypercall_buffer_array_create(xc_interface *xch, unsigned n);
+void *xc__hypercall_buffer_array_alloc(xc_interface *xch, xc_hypercall_buffer_array_t *array,
+                                       unsigned index, xc_hypercall_buffer_t *hbuf, size_t size);
+#define xc_hypercall_buffer_array_alloc(_xch, _array, _index, _name, _size) \
+    xc__hypercall_buffer_array_alloc(_xch, _array, _index, HYPERCALL_BUFFER(_name), _size)
+void *xc__hypercall_buffer_array_get(xc_interface *xch, xc_hypercall_buffer_array_t *array,
+                                     unsigned index, xc_hypercall_buffer_t *hbuf);
+#define xc_hypercall_buffer_array_get(_xch, _array, _index, _name, _size) \
+    xc__hypercall_buffer_array_get(_xch, _array, _index, HYPERCALL_BUFFER(_name))
+void xc_hypercall_buffer_array_destroy(xc_interface *xc, xc_hypercall_buffer_array_t *array);
+
+/*
  * CPUMAP handling
  */
 typedef uint8_t *xc_cpumap_t;
-- 
1.7.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 Feb 21 17:48:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aFy-00058H-1U; Thu, 21 Feb 2013 17:48:30 +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 1U8aFw-000581-B8
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:28 +0000
Received: from [193.109.254.147:28859] by server-12.bemta-14.messagelabs.com
	id 92/C8-32582-BED56215; Thu, 21 Feb 2013 17:48:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361468904!2317886!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23378 invoked from network); 21 Feb 2013 17:48:27 -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;
	21 Feb 2013 17:48:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8370823"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Jy;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:13 +0000
Message-ID: <1361468894-18655-8-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 7/8] libxc: add hypercall buffer 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

From: David Vrabel <david.vrabel@citrix.com>

Hypercall buffer arrays are used when a hypercall takes a variable
length array of buffers.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/xc_hcall_buf.c |   73 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h      |   27 ++++++++++++++++
 2 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/tools/libxc/xc_hcall_buf.c b/tools/libxc/xc_hcall_buf.c
index ced9abd..3e01f3f 100644
--- a/tools/libxc/xc_hcall_buf.c
+++ b/tools/libxc/xc_hcall_buf.c
@@ -228,6 +228,79 @@ void xc__hypercall_bounce_post(xc_interface *xch, xc_hypercall_buffer_t *b)
     xc__hypercall_buffer_free(xch, b);
 }
 
+struct xc_hypercall_buffer_array {
+    unsigned max_bufs;
+    xc_hypercall_buffer_t *bufs;
+};
+
+xc_hypercall_buffer_array_t *xc_hypercall_buffer_array_create(xc_interface *xch,
+                                                              unsigned n)
+{
+    xc_hypercall_buffer_array_t *array;
+    xc_hypercall_buffer_t *bufs = NULL;
+
+    array = malloc(sizeof(*array));
+    if ( array == NULL )
+        goto error;
+
+    bufs = calloc(n, sizeof(*bufs));
+    if ( bufs == NULL )
+        goto error;
+
+    array->max_bufs = n;
+    array->bufs     = bufs;
+
+    return array;
+
+error:
+    free(bufs);
+    free(array);
+    return NULL;
+}
+
+void *xc__hypercall_buffer_array_alloc(xc_interface *xch,
+                                       xc_hypercall_buffer_array_t *array,
+                                       unsigned index,
+                                       xc_hypercall_buffer_t *hbuf,
+                                       size_t size)
+{
+    void *buf;
+
+    if ( index >= array->max_bufs || array->bufs[index].hbuf )
+        abort();
+
+    buf = xc__hypercall_buffer_alloc(xch, hbuf, size);
+    if ( buf )
+        array->bufs[index] = *hbuf;
+    return buf;
+}
+
+void *xc__hypercall_buffer_array_get(xc_interface *xch,
+                                     xc_hypercall_buffer_array_t *array,
+                                     unsigned index,
+                                     xc_hypercall_buffer_t *hbuf)
+{
+    if ( index >= array->max_bufs || array->bufs[index].hbuf == NULL )
+        abort();
+
+    *hbuf = array->bufs[index];
+    return array->bufs[index].hbuf;
+}
+
+void xc_hypercall_buffer_array_destroy(xc_interface *xc,
+                                       xc_hypercall_buffer_array_t *array)
+{
+    unsigned i;
+
+    if ( array == NULL )
+        return;
+
+    for (i = 0; i < array->max_bufs; i++ )
+        xc__hypercall_buffer_free(xc, &array->bufs[i]);
+    free(array->bufs);
+    free(array);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 32122fd..c3b2c28 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -317,6 +317,33 @@ void xc__hypercall_buffer_free_pages(xc_interface *xch, xc_hypercall_buffer_t *b
 #define xc_hypercall_buffer_free_pages(_xch, _name, _nr) xc__hypercall_buffer_free_pages(_xch, HYPERCALL_BUFFER(_name), _nr)
 
 /*
+ * Array of hypercall buffers.
+ *
+ * Create an array with xc_hypercall_buffer_array_create() and
+ * populate it by declaring one hypercall buffer in a loop and
+ * allocating the buffer with xc_hypercall_buffer_array_alloc().
+ *
+ * To access a previously allocated buffers, declare a new hypercall
+ * buffer and call xc_hypercall_buffer_array_get().
+ *
+ * Destroy the array with xc_hypercall_buffer_array_destroy() to free
+ * the array and all its alocated hypercall buffers.
+ */
+struct xc_hypercall_buffer_array;
+typedef struct xc_hypercall_buffer_array xc_hypercall_buffer_array_t;
+
+xc_hypercall_buffer_array_t *xc_hypercall_buffer_array_create(xc_interface *xch, unsigned n);
+void *xc__hypercall_buffer_array_alloc(xc_interface *xch, xc_hypercall_buffer_array_t *array,
+                                       unsigned index, xc_hypercall_buffer_t *hbuf, size_t size);
+#define xc_hypercall_buffer_array_alloc(_xch, _array, _index, _name, _size) \
+    xc__hypercall_buffer_array_alloc(_xch, _array, _index, HYPERCALL_BUFFER(_name), _size)
+void *xc__hypercall_buffer_array_get(xc_interface *xch, xc_hypercall_buffer_array_t *array,
+                                     unsigned index, xc_hypercall_buffer_t *hbuf);
+#define xc_hypercall_buffer_array_get(_xch, _array, _index, _name, _size) \
+    xc__hypercall_buffer_array_get(_xch, _array, _index, HYPERCALL_BUFFER(_name))
+void xc_hypercall_buffer_array_destroy(xc_interface *xc, xc_hypercall_buffer_array_t *array);
+
+/*
  * CPUMAP handling
  */
 typedef uint8_t *xc_cpumap_t;
-- 
1.7.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 Feb 21 17:48:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG5-0005As-KJ; Thu, 21 Feb 2013 17:48:37 +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 1U8aG4-0005AA-7m
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:36 +0000
Received: from [85.158.139.211:43653] by server-5.bemta-5.messagelabs.com id
	F3/F2-11945-3FD56215; Thu, 21 Feb 2013 17:48:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361468913!18669277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16245 invoked from network); 21 Feb 2013 17:48:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803704"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Em;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:09 +0000
Message-ID: <1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] kexec: add public interface for improved
	load/unload sub-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>
Content-Type: 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 replacement KEXEC_CMD_load and KEXEC_CMD_unload sub-ops to the
kexec hypercall.  These new sub-ops allow a priviledged guest to
provide the image data to be loaded into Xen memory or the crash
region instead of guests loading the image data themselves and
providing the relocation code and metadata.

The old interface is provided to guests requesting an interface
version prior to 4.3.

Signed-off: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/kexec.c         |   12 ++++----
 xen/include/public/kexec.h |   66 +++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 68 insertions(+), 10 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 6dd20c6..2cbb62c 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -732,7 +732,7 @@ static void crash_save_vmcoreinfo(void)
 #endif
 }
 
-static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
+static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_v1_t *load)
 {
     xen_kexec_image_t *image;
     int base, bit, pos;
@@ -779,7 +779,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
 
 static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
-    xen_kexec_load_t load;
+    xen_kexec_load_v1_t load;
 
     if ( unlikely(copy_from_guest(&load, uarg, 1)) )
         return -EFAULT;
@@ -791,8 +791,8 @@ static int kexec_load_unload_compat(unsigned long op,
                                     XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
-    compat_kexec_load_t compat_load;
-    xen_kexec_load_t load;
+    compat_kexec_load_v1_t compat_load;
+    xen_kexec_load_v1_t load;
 
     if ( unlikely(copy_from_guest(&compat_load, uarg, 1)) )
         return -EFAULT;
@@ -864,8 +864,8 @@ static int do_kexec_op_internal(unsigned long op,
         else
                 ret = kexec_get_range(uarg);
         break;
-    case KEXEC_CMD_kexec_load:
-    case KEXEC_CMD_kexec_unload:
+    case KEXEC_CMD_kexec_load_v1:
+    case KEXEC_CMD_kexec_unload_v1:
         spin_lock_irqsave(&kexec_lock, flags);
         if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
         {
diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h
index 61a8d7d..5259446 100644
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
  * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
  * image == relocation information for kexec (ignored for unload) [in]
  */
-#define KEXEC_CMD_kexec_load            1
-#define KEXEC_CMD_kexec_unload          2
-typedef struct xen_kexec_load {
+#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
+#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
+typedef struct xen_kexec_load_v1 {
     int type;
     xen_kexec_image_t image;
-} xen_kexec_load_t;
+} xen_kexec_load_v1_t;
 
 #define KEXEC_RANGE_MA_CRASH      0 /* machine address and size of crash area */
 #define KEXEC_RANGE_MA_XEN        1 /* machine address and size of Xen itself */
@@ -152,6 +152,64 @@ typedef struct xen_kexec_range {
     unsigned long start;
 } xen_kexec_range_t;
 
+#if __XEN_INTERFACE_VERSION__ >= 0x00040300
+/*
+ * A contiguous chunk of a kexec image and it's destination machine
+ * address.
+ */
+typedef struct xen_kexec_segment {
+    XEN_GUEST_HANDLE_64(const_void) buf;
+    uint64_t buf_size;
+    uint64_t dest_maddr;
+    uint64_t dest_size;
+} xen_kexec_segment_t;
+DEFINE_XEN_GUEST_HANDLE(xen_kexec_segment_t);
+
+/*
+ * Load a kexec image into memory.
+ *
+ * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
+ * The image is relocated prior to being executed.
+ *
+ * For KEXEC_TYPE_CRASH images, each segment of the image must reside
+ * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
+ * the entry point must be within the image. The caller is responsible
+ * for ensuring that multiple images do not overlap.
+ */
+
+#define KEXEC_CMD_kexec_load 4
+typedef struct xen_kexec_load {
+    uint8_t  type;        /* One of KEXEC_TYPE_* */
+    uint16_t arch;        /* ELF machine type (EM_*). */
+    uint32_t __pad;
+    uint64_t entry_maddr; /* image entry point machine address. */
+    uint32_t nr_segments;
+    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
+} xen_kexec_load_t;
+DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
+
+/*
+ * Unload a kexec image.
+ *
+ * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH.
+ */
+#define KEXEC_CMD_kexec_unload 5
+typedef struct xen_kexec_unload {
+    uint8_t type;
+} xen_kexec_unload_t;
+DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t);
+
+#else /* __XEN_INTERFACE_VERSION__ < 0x00040300 */
+
+#undef KEXEC_CMD_kexec_load
+#undef KEXEC_CMD_kexec_unload
+#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1
+#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1
+
+typedef struct xen_kexec_load_v1_t xen_kexec_load_t;
+
+#endif
+
 #endif /* _XEN_PUBLIC_KEXEC_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 Thu Feb 21 17:48:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG7-0005C3-TC; Thu, 21 Feb 2013 17:48:39 +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 1U8aG5-0005Aq-TP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:38 +0000
Received: from [85.158.139.211:49721] by server-11.bemta-5.messagelabs.com id
	10/FA-19159-5FD56215; Thu, 21 Feb 2013 17:48:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15856 invoked from network); 21 Feb 2013 17:48:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803706"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-KW;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:14 +0000
Message-ID: <1361468894-18655-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] libxc: add API for kexec 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

From: David Vrabel <david.vrabel@citrix.com>

Add xc_kexec_exec(), xc_kexec_get_ranges(), xc_kexec_load(), and
xc_kexec_unload().  The load and unload calls require the v2 load and
unload ops.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/Makefile   |    1 +
 tools/libxc/xc_kexec.c |  140 ++++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h  |   55 +++++++++++++++++++
 3 files changed, 196 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_kexec.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index d44abf9..39badf9 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,6 +31,7 @@ CTRL_SRCS-y       += xc_mem_access.c
 CTRL_SRCS-y       += xc_memshr.c
 CTRL_SRCS-y       += xc_hcall_buf.c
 CTRL_SRCS-y       += xc_foreign_memory.c
+CTRL_SRCS-y       += xc_kexec.c
 CTRL_SRCS-y       += xtl_core.c
 CTRL_SRCS-y       += xtl_logger_stdio.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
diff --git a/tools/libxc/xc_kexec.c b/tools/libxc/xc_kexec.c
new file mode 100644
index 0000000..88d0278
--- /dev/null
+++ b/tools/libxc/xc_kexec.c
@@ -0,0 +1,140 @@
+/******************************************************************************
+ * xc_kexec.c
+ *
+ * API for loading and executing kexec images.
+ *
+ * This library 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 of the License.
+ *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ */
+#include "xc_private.h"
+
+int xc_kexec(xc_interface *xch, int type)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_exec_t, exec);
+    int ret = -1;
+
+    exec = xc_hypercall_buffer_alloc(xch, exec, sizeof(*exec));
+    if ( exec == NULL )
+    {
+        PERROR("Count not alloc bounce buffer for kexec_exec hypercall");
+        goto out;
+    }
+
+    exec->type = type;
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(exec);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, exec);
+
+    return ret;
+}
+
+int xc_kexec_get_range(xc_interface *xch, int range,  int nr,
+                       uint64_t *size, uint64_t *start)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_range_t, get_range);
+    int ret = -1;
+
+    get_range = xc_hypercall_buffer_alloc(xch, get_range, sizeof(*get_range));
+    if ( get_range == NULL )
+    {
+        PERROR("Could not alloc bounce buffer for kexec_get_range hypercall");
+        goto out;
+    }
+
+    get_range->range = range;
+    get_range->nr = nr;
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec_get_range;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(get_range);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+    *size = get_range->size;
+    *start = get_range->start;
+
+out:
+    xc_hypercall_buffer_free(xch, get_range);
+
+    return ret;
+}
+
+int xc_kexec_load(xc_interface *xch, uint8_t type, uint16_t arch,
+                  uint64_t entry_maddr,
+                  uint32_t nr_segments, xen_kexec_segment_t *segments)
+{
+    int ret = -1;
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BOUNCE(segments, sizeof(*segments) * nr_segments,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_load_t, load);
+    
+    if ( xc_hypercall_bounce_pre(xch, segments) )
+    {
+        PERROR("Could not allocate bounce buffer for kexec load hypercall");
+        goto out;
+    }
+    load = xc_hypercall_buffer_alloc(xch, load, sizeof(*load));
+    if ( load == NULL )
+    {
+        PERROR("Could not allocate buffer for kexec load hypercall");
+        goto out;
+    }
+
+    load->type = type;
+    load->arch = arch;
+    load->entry_maddr = entry_maddr;
+    load->nr_segments = nr_segments;
+    set_xen_guest_handle(load->segments, segments);
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec_load;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(load);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, load);
+    xc_hypercall_bounce_post(xch, segments);
+
+    return ret;
+}
+
+int xc_kexec_unload(xc_interface *xch, int type)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_unload_t, unload);
+    int ret = -1;
+
+    unload = xc_hypercall_buffer_alloc(xch, unload, sizeof(*unload));
+    if ( unload == NULL )
+    {
+        PERROR("Count not alloc buffer for kexec unload hypercall");
+        goto out;
+    }
+
+    unload->type = type;
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec_unload;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(unload);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, unload);
+
+    return ret;
+}
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index c3b2c28..d6c4877 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -46,6 +46,7 @@
 #include <xen/hvm/params.h>
 #include <xen/xsm/flask_op.h>
 #include <xen/tmem.h>
+#include <xen/kexec.h>
 
 #include "xentoollog.h"
 
@@ -2263,4 +2264,58 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
 				   unsigned long compbuf_size,
 				   unsigned long *compbuf_pos, char *dest);
 
+/*
+ * Execute an image previously loaded with xc_kexec_load().
+ *
+ * Does not return on success.
+ *
+ * Fails with:
+ *   ENOENT if the specified image has not been loaded.
+ */
+int xc_kexec(xc_interface *xch, int type);
+
+/*
+ * Find the machine address and size of certain memory areas.
+ *
+ *   KEXEC_RANGE_MA_CRASH       crash area
+ *   KEXEC_RANGE_MA_XEN         Xen itself
+ *   KEXEC_RANGE_MA_CPU         CPU note for CPU number 'nr'
+ *   KEXEC_RANGE_MA_XENHEAP     xenheap
+ *   KEXEC_RANGE_MA_EFI_MEMMAP  EFI Memory Map
+ *   KEXEC_RANGE_MA_VMCOREINFO  vmcoreinfo
+ *
+ * Fails with:
+ *   EINVAL if the range or CPU number isn't valid.
+ */
+int xc_kexec_get_range(xc_interface *xch, int range,  int nr,
+                       uint64_t *size, uint64_t *start);
+
+/*
+ * Load a kexec image into memory.
+ *
+ * The image may be of type KEXEC_TYPE_DEFAULT (executed on request)
+ * or KEXEC_TYPE_CRASH (executed on a crash).
+ *
+ * The image architecture may be a 32-bit variant of the hypervisor
+ * architecture (e.g, EM_386 on a x86-64 hypervisor).
+ *
+ * Fails with:
+ *   ENOMEM if there is insufficient memory for the new image.
+ *   EINVAL if the image does not fit into the crash area or the entry
+ *          point isn't within one of segments.
+ *   EBUSY  if another image is being executed.
+ */
+int xc_kexec_load(xc_interface *xch, uint8_t type, uint16_t arch,
+                  uint64_t entry_maddr,
+                  uint32_t nr_segments, xen_kexec_segment_t *segments);
+
+/*
+ * Unload a kexec image.
+ *
+ * This prevents a KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH image from
+ * being executed.  The crash images are not cleared from the crash
+ * region.
+ */
+int xc_kexec_unload(xc_interface *xch, int type);
+
 #endif /* XENCTRL_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 Thu Feb 21 17:48:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG5-0005As-KJ; Thu, 21 Feb 2013 17:48:37 +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 1U8aG4-0005AA-7m
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:36 +0000
Received: from [85.158.139.211:43653] by server-5.bemta-5.messagelabs.com id
	F3/F2-11945-3FD56215; Thu, 21 Feb 2013 17:48:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361468913!18669277!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16245 invoked from network); 21 Feb 2013 17:48:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803704"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Em;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:09 +0000
Message-ID: <1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/8] kexec: add public interface for improved
	load/unload sub-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>
Content-Type: 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 replacement KEXEC_CMD_load and KEXEC_CMD_unload sub-ops to the
kexec hypercall.  These new sub-ops allow a priviledged guest to
provide the image data to be loaded into Xen memory or the crash
region instead of guests loading the image data themselves and
providing the relocation code and metadata.

The old interface is provided to guests requesting an interface
version prior to 4.3.

Signed-off: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/kexec.c         |   12 ++++----
 xen/include/public/kexec.h |   66 +++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 68 insertions(+), 10 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 6dd20c6..2cbb62c 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -732,7 +732,7 @@ static void crash_save_vmcoreinfo(void)
 #endif
 }
 
-static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
+static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_v1_t *load)
 {
     xen_kexec_image_t *image;
     int base, bit, pos;
@@ -779,7 +779,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
 
 static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
-    xen_kexec_load_t load;
+    xen_kexec_load_v1_t load;
 
     if ( unlikely(copy_from_guest(&load, uarg, 1)) )
         return -EFAULT;
@@ -791,8 +791,8 @@ static int kexec_load_unload_compat(unsigned long op,
                                     XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
-    compat_kexec_load_t compat_load;
-    xen_kexec_load_t load;
+    compat_kexec_load_v1_t compat_load;
+    xen_kexec_load_v1_t load;
 
     if ( unlikely(copy_from_guest(&compat_load, uarg, 1)) )
         return -EFAULT;
@@ -864,8 +864,8 @@ static int do_kexec_op_internal(unsigned long op,
         else
                 ret = kexec_get_range(uarg);
         break;
-    case KEXEC_CMD_kexec_load:
-    case KEXEC_CMD_kexec_unload:
+    case KEXEC_CMD_kexec_load_v1:
+    case KEXEC_CMD_kexec_unload_v1:
         spin_lock_irqsave(&kexec_lock, flags);
         if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
         {
diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h
index 61a8d7d..5259446 100644
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
  * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
  * image == relocation information for kexec (ignored for unload) [in]
  */
-#define KEXEC_CMD_kexec_load            1
-#define KEXEC_CMD_kexec_unload          2
-typedef struct xen_kexec_load {
+#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
+#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
+typedef struct xen_kexec_load_v1 {
     int type;
     xen_kexec_image_t image;
-} xen_kexec_load_t;
+} xen_kexec_load_v1_t;
 
 #define KEXEC_RANGE_MA_CRASH      0 /* machine address and size of crash area */
 #define KEXEC_RANGE_MA_XEN        1 /* machine address and size of Xen itself */
@@ -152,6 +152,64 @@ typedef struct xen_kexec_range {
     unsigned long start;
 } xen_kexec_range_t;
 
+#if __XEN_INTERFACE_VERSION__ >= 0x00040300
+/*
+ * A contiguous chunk of a kexec image and it's destination machine
+ * address.
+ */
+typedef struct xen_kexec_segment {
+    XEN_GUEST_HANDLE_64(const_void) buf;
+    uint64_t buf_size;
+    uint64_t dest_maddr;
+    uint64_t dest_size;
+} xen_kexec_segment_t;
+DEFINE_XEN_GUEST_HANDLE(xen_kexec_segment_t);
+
+/*
+ * Load a kexec image into memory.
+ *
+ * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
+ * The image is relocated prior to being executed.
+ *
+ * For KEXEC_TYPE_CRASH images, each segment of the image must reside
+ * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
+ * the entry point must be within the image. The caller is responsible
+ * for ensuring that multiple images do not overlap.
+ */
+
+#define KEXEC_CMD_kexec_load 4
+typedef struct xen_kexec_load {
+    uint8_t  type;        /* One of KEXEC_TYPE_* */
+    uint16_t arch;        /* ELF machine type (EM_*). */
+    uint32_t __pad;
+    uint64_t entry_maddr; /* image entry point machine address. */
+    uint32_t nr_segments;
+    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
+} xen_kexec_load_t;
+DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
+
+/*
+ * Unload a kexec image.
+ *
+ * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH.
+ */
+#define KEXEC_CMD_kexec_unload 5
+typedef struct xen_kexec_unload {
+    uint8_t type;
+} xen_kexec_unload_t;
+DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t);
+
+#else /* __XEN_INTERFACE_VERSION__ < 0x00040300 */
+
+#undef KEXEC_CMD_kexec_load
+#undef KEXEC_CMD_kexec_unload
+#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1
+#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1
+
+typedef struct xen_kexec_load_v1_t xen_kexec_load_t;
+
+#endif
+
 #endif /* _XEN_PUBLIC_KEXEC_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 Thu Feb 21 17:48:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG7-0005C3-TC; Thu, 21 Feb 2013 17:48:39 +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 1U8aG5-0005Aq-TP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:38 +0000
Received: from [85.158.139.211:49721] by server-11.bemta-5.messagelabs.com id
	10/FA-19159-5FD56215; Thu, 21 Feb 2013 17:48:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15856 invoked from network); 21 Feb 2013 17:48:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803706"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-KW;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:14 +0000
Message-ID: <1361468894-18655-9-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 8/8] libxc: add API for kexec 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

From: David Vrabel <david.vrabel@citrix.com>

Add xc_kexec_exec(), xc_kexec_get_ranges(), xc_kexec_load(), and
xc_kexec_unload().  The load and unload calls require the v2 load and
unload ops.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 tools/libxc/Makefile   |    1 +
 tools/libxc/xc_kexec.c |  140 ++++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h  |   55 +++++++++++++++++++
 3 files changed, 196 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_kexec.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index d44abf9..39badf9 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,6 +31,7 @@ CTRL_SRCS-y       += xc_mem_access.c
 CTRL_SRCS-y       += xc_memshr.c
 CTRL_SRCS-y       += xc_hcall_buf.c
 CTRL_SRCS-y       += xc_foreign_memory.c
+CTRL_SRCS-y       += xc_kexec.c
 CTRL_SRCS-y       += xtl_core.c
 CTRL_SRCS-y       += xtl_logger_stdio.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
diff --git a/tools/libxc/xc_kexec.c b/tools/libxc/xc_kexec.c
new file mode 100644
index 0000000..88d0278
--- /dev/null
+++ b/tools/libxc/xc_kexec.c
@@ -0,0 +1,140 @@
+/******************************************************************************
+ * xc_kexec.c
+ *
+ * API for loading and executing kexec images.
+ *
+ * This library 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 of the License.
+ *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ */
+#include "xc_private.h"
+
+int xc_kexec(xc_interface *xch, int type)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_exec_t, exec);
+    int ret = -1;
+
+    exec = xc_hypercall_buffer_alloc(xch, exec, sizeof(*exec));
+    if ( exec == NULL )
+    {
+        PERROR("Count not alloc bounce buffer for kexec_exec hypercall");
+        goto out;
+    }
+
+    exec->type = type;
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(exec);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, exec);
+
+    return ret;
+}
+
+int xc_kexec_get_range(xc_interface *xch, int range,  int nr,
+                       uint64_t *size, uint64_t *start)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_range_t, get_range);
+    int ret = -1;
+
+    get_range = xc_hypercall_buffer_alloc(xch, get_range, sizeof(*get_range));
+    if ( get_range == NULL )
+    {
+        PERROR("Could not alloc bounce buffer for kexec_get_range hypercall");
+        goto out;
+    }
+
+    get_range->range = range;
+    get_range->nr = nr;
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec_get_range;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(get_range);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+    *size = get_range->size;
+    *start = get_range->start;
+
+out:
+    xc_hypercall_buffer_free(xch, get_range);
+
+    return ret;
+}
+
+int xc_kexec_load(xc_interface *xch, uint8_t type, uint16_t arch,
+                  uint64_t entry_maddr,
+                  uint32_t nr_segments, xen_kexec_segment_t *segments)
+{
+    int ret = -1;
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BOUNCE(segments, sizeof(*segments) * nr_segments,
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_load_t, load);
+    
+    if ( xc_hypercall_bounce_pre(xch, segments) )
+    {
+        PERROR("Could not allocate bounce buffer for kexec load hypercall");
+        goto out;
+    }
+    load = xc_hypercall_buffer_alloc(xch, load, sizeof(*load));
+    if ( load == NULL )
+    {
+        PERROR("Could not allocate buffer for kexec load hypercall");
+        goto out;
+    }
+
+    load->type = type;
+    load->arch = arch;
+    load->entry_maddr = entry_maddr;
+    load->nr_segments = nr_segments;
+    set_xen_guest_handle(load->segments, segments);
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec_load;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(load);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, load);
+    xc_hypercall_bounce_post(xch, segments);
+
+    return ret;
+}
+
+int xc_kexec_unload(xc_interface *xch, int type)
+{
+    DECLARE_HYPERCALL;
+    DECLARE_HYPERCALL_BUFFER(xen_kexec_unload_t, unload);
+    int ret = -1;
+
+    unload = xc_hypercall_buffer_alloc(xch, unload, sizeof(*unload));
+    if ( unload == NULL )
+    {
+        PERROR("Count not alloc buffer for kexec unload hypercall");
+        goto out;
+    }
+
+    unload->type = type;
+
+    hypercall.op = __HYPERVISOR_kexec_op;
+    hypercall.arg[0] = KEXEC_CMD_kexec_unload;
+    hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(unload);
+
+    ret = do_xen_hypercall(xch, &hypercall);
+
+out:
+    xc_hypercall_buffer_free(xch, unload);
+
+    return ret;
+}
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index c3b2c28..d6c4877 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -46,6 +46,7 @@
 #include <xen/hvm/params.h>
 #include <xen/xsm/flask_op.h>
 #include <xen/tmem.h>
+#include <xen/kexec.h>
 
 #include "xentoollog.h"
 
@@ -2263,4 +2264,58 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
 				   unsigned long compbuf_size,
 				   unsigned long *compbuf_pos, char *dest);
 
+/*
+ * Execute an image previously loaded with xc_kexec_load().
+ *
+ * Does not return on success.
+ *
+ * Fails with:
+ *   ENOENT if the specified image has not been loaded.
+ */
+int xc_kexec(xc_interface *xch, int type);
+
+/*
+ * Find the machine address and size of certain memory areas.
+ *
+ *   KEXEC_RANGE_MA_CRASH       crash area
+ *   KEXEC_RANGE_MA_XEN         Xen itself
+ *   KEXEC_RANGE_MA_CPU         CPU note for CPU number 'nr'
+ *   KEXEC_RANGE_MA_XENHEAP     xenheap
+ *   KEXEC_RANGE_MA_EFI_MEMMAP  EFI Memory Map
+ *   KEXEC_RANGE_MA_VMCOREINFO  vmcoreinfo
+ *
+ * Fails with:
+ *   EINVAL if the range or CPU number isn't valid.
+ */
+int xc_kexec_get_range(xc_interface *xch, int range,  int nr,
+                       uint64_t *size, uint64_t *start);
+
+/*
+ * Load a kexec image into memory.
+ *
+ * The image may be of type KEXEC_TYPE_DEFAULT (executed on request)
+ * or KEXEC_TYPE_CRASH (executed on a crash).
+ *
+ * The image architecture may be a 32-bit variant of the hypervisor
+ * architecture (e.g, EM_386 on a x86-64 hypervisor).
+ *
+ * Fails with:
+ *   ENOMEM if there is insufficient memory for the new image.
+ *   EINVAL if the image does not fit into the crash area or the entry
+ *          point isn't within one of segments.
+ *   EBUSY  if another image is being executed.
+ */
+int xc_kexec_load(xc_interface *xch, uint8_t type, uint16_t arch,
+                  uint64_t entry_maddr,
+                  uint32_t nr_segments, xen_kexec_segment_t *segments);
+
+/*
+ * Unload a kexec image.
+ *
+ * This prevents a KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH image from
+ * being executed.  The crash images are not cleared from the crash
+ * region.
+ */
+int xc_kexec_unload(xc_interface *xch, int type);
+
 #endif /* XENCTRL_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 Thu Feb 21 17:48:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG6-0005BA-1K; Thu, 21 Feb 2013 17:48:38 +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 1U8aG4-0005AH-FH
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:36 +0000
Received: from [85.158.139.211:56482] by server-1.bemta-5.messagelabs.com id
	27/EC-29263-3FD56215; Thu, 21 Feb 2013 17:48:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15703 invoked from network); 21 Feb 2013 17:48:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803701"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-As;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:06 +0000
Message-ID: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
	with pv-ops 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

The series improves the kexec hypercall by making Xen responsible for
loading and relocating the image.  This allows kexec to be usable by
pv-ops kernels and should allow kexec to be usable from a HVM or PVH
privileged domain.

The first patch is a simple clean-up.

The second patch allows hypercall structures to be ABI compatible
between 32- and 64-bit guests (by reusing stuff present for domctls
and sysctls).  This seems better than having to keep adding compat
handling for new hypercalls etc.

Patch 3 introduces the new ABI.

Patch 4 and 5 nearly completely reimplement the kexec load, unload and
exec sub-ops.  The old load_v1 sub-op is then implemented on top of
the new code.

Patch 6 calls the kexec image when dom0 crashes.  This avoids having
to alter dom0 kernels to do a exec sub-op call on crash -- an existing
SHUTDOWN_crash.

Patches 7 and 8 add the libxc API for the kexec calls.

The required patch series for kexec-tools will be posted shortly.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:48:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG4-0005AJ-6d; Thu, 21 Feb 2013 17:48:36 +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 1U8aG2-00059s-VU
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:35 +0000
Received: from [85.158.139.211:14424] by server-6.bemta-5.messagelabs.com id
	57/C8-01489-2FD56215; Thu, 21 Feb 2013 17:48:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15553 invoked from network); 21 Feb 2013 17:48:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803700"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Ci;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:07 +0000
Message-ID: <1361468894-18655-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] x86: give FIX_EFI_MPF its own fixmap 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

From: David Vrabel <david.vrabel@citrix.com>

FIX_EFI_MPF was the same as FIX_KEXEC_BASE_0 which is going away.  So
add its own entry.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/x86/mpparse.c       |    2 --
 xen/include/asm-x86/fixmap.h |    1 +
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index 97ab5d3..f13ba93 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -538,8 +538,6 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 	}
 }
 
-#define FIX_EFI_MPF FIX_KEXEC_BASE_0
-
 static __init void efi_unmap_mpf(void)
 {
 	if (efi_enabled)
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index d026d78..2eefcf4 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -71,6 +71,7 @@ enum fixed_addresses {
     FIX_APEI_RANGE_BASE,
     FIX_APEI_RANGE_END = FIX_APEI_RANGE_BASE + FIX_APEI_RANGE_MAX -1,
     FIX_IGD_MMIO,
+    FIX_EFI_MPF,
     __end_of_fixed_addresses
 };
 
-- 
1.7.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 Feb 21 17:48:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG4-0005AJ-6d; Thu, 21 Feb 2013 17:48:36 +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 1U8aG2-00059s-VU
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:35 +0000
Received: from [85.158.139.211:14424] by server-6.bemta-5.messagelabs.com id
	57/C8-01489-2FD56215; Thu, 21 Feb 2013 17:48:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15553 invoked from network); 21 Feb 2013 17:48:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803700"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Ci;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:07 +0000
Message-ID: <1361468894-18655-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/8] x86: give FIX_EFI_MPF its own fixmap 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

From: David Vrabel <david.vrabel@citrix.com>

FIX_EFI_MPF was the same as FIX_KEXEC_BASE_0 which is going away.  So
add its own entry.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/x86/mpparse.c       |    2 --
 xen/include/asm-x86/fixmap.h |    1 +
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index 97ab5d3..f13ba93 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -538,8 +538,6 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 	}
 }
 
-#define FIX_EFI_MPF FIX_KEXEC_BASE_0
-
 static __init void efi_unmap_mpf(void)
 {
 	if (efi_enabled)
diff --git a/xen/include/asm-x86/fixmap.h b/xen/include/asm-x86/fixmap.h
index d026d78..2eefcf4 100644
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -71,6 +71,7 @@ enum fixed_addresses {
     FIX_APEI_RANGE_BASE,
     FIX_APEI_RANGE_END = FIX_APEI_RANGE_BASE + FIX_APEI_RANGE_MAX -1,
     FIX_IGD_MMIO,
+    FIX_EFI_MPF,
     __end_of_fixed_addresses
 };
 
-- 
1.7.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 Feb 21 17:48:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG6-0005BA-1K; Thu, 21 Feb 2013 17:48:38 +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 1U8aG4-0005AH-FH
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:36 +0000
Received: from [85.158.139.211:56482] by server-1.bemta-5.messagelabs.com id
	27/EC-29263-3FD56215; Thu, 21 Feb 2013 17:48:35 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15703 invoked from network); 21 Feb 2013 17:48:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803701"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-As;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:06 +0000
Message-ID: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
	with pv-ops 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

The series improves the kexec hypercall by making Xen responsible for
loading and relocating the image.  This allows kexec to be usable by
pv-ops kernels and should allow kexec to be usable from a HVM or PVH
privileged domain.

The first patch is a simple clean-up.

The second patch allows hypercall structures to be ABI compatible
between 32- and 64-bit guests (by reusing stuff present for domctls
and sysctls).  This seems better than having to keep adding compat
handling for new hypercalls etc.

Patch 3 introduces the new ABI.

Patch 4 and 5 nearly completely reimplement the kexec load, unload and
exec sub-ops.  The old load_v1 sub-op is then implemented on top of
the new code.

Patch 6 calls the kexec image when dom0 crashes.  This avoids having
to alter dom0 kernels to do a exec sub-op call on crash -- an existing
SHUTDOWN_crash.

Patches 7 and 8 add the libxc API for the kexec calls.

The required patch series for kexec-tools will be posted shortly.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:48:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG8-0005CJ-9y; Thu, 21 Feb 2013 17:48:40 +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 1U8aG5-0005Ap-Tf
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:38 +0000
Received: from [85.158.139.211:56591] by server-2.bemta-5.messagelabs.com id
	60/00-16911-5FD56215; Thu, 21 Feb 2013 17:48:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361468913!18669277!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16286 invoked from network); 21 Feb 2013 17:48:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803707"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Gb;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:10 +0000
Message-ID: <1361468894-18655-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] kexec: add infrastructure for handling
	kexec images
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the code needed to handle and load kexec images into Xen memory or
into the crash region.  This is needed for the new KEXEC_CMD_load and
KEXEC_CMD_unload hypercall sub-ops.

Much of this code is derived from the Linux kernel.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/Makefile      |    1 +
 xen/common/kimage.c      |  887 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/kimage.h |   64 ++++
 3 files changed, 952 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/kimage.c
 create mode 100644 xen/include/xen/kimage.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..4c04018 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
 obj-$(HAS_KEXEC) += kexec.o
+obj-$(HAS_KEXEC) += kimage.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
new file mode 100644
index 0000000..c5f07c3
--- /dev/null
+++ b/xen/common/kimage.c
@@ -0,0 +1,887 @@
+/*
+ * Kexec Image
+ *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ *
+ * Derived from kernel/kexec.c from Linux:
+ *
+ *   Copyright (C) 2002-2004 Eric Biederman  <ebiederm@xmission.com>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/kernel.h>
+#include <xen/errno.h>
+#include <xen/spinlock.h>
+#include <xen/guest_access.h>
+#include <xen/mm.h>
+#include <xen/kexec.h>
+#include <xen/kimage.h>
+
+#include <asm/page.h>
+
+/*
+ * When kexec transitions to the new kernel there is a one-to-one
+ * mapping between physical and virtual addresses.  On processors
+ * where you can disable the MMU this is trivial, and easy.  For
+ * others it is still a simple predictable page table to setup.
+ *
+ * In that environment kexec copies the new kernel to its final
+ * resting place.  This means I can only support memory whose
+ * physical address can fit in an unsigned long.  In particular
+ * addresses where (pfn << PAGE_SHIFT) > ULONG_MAX cannot be handled.
+ * If the assembly stub has more restrictive requirements
+ * KEXEC_SOURCE_MEMORY_LIMIT and KEXEC_DEST_MEMORY_LIMIT can be
+ * defined more restrictively in <asm/kexec.h>.
+ *
+ * The code for the transition from the current kernel to the
+ * the new kernel is placed in the control_code_buffer, whose size
+ * is given by KEXEC_CONTROL_PAGE_SIZE.  In the best case only a single
+ * page of memory is necessary, but some architectures require more.
+ * Because this memory must be identity mapped in the transition from
+ * virtual to physical addresses it must live in the range
+ * 0 - TASK_SIZE, as only the user space mappings are arbitrarily
+ * modifiable.
+ *
+ * The assembly stub in the control code buffer is passed a linked list
+ * of descriptor pages detailing the source pages of the new kernel,
+ * and the destination addresses of those source pages.  As this data
+ * structure is not used in the context of the current OS, it must
+ * be self-contained.
+ *
+ * The code has been made to work with highmem pages and will use a
+ * destination page in its final resting place (if it happens
+ * to allocate it).  The end product of this is that most of the
+ * physical address space, and most of RAM can be used.
+ *
+ * Future directions include:
+ *  - allocating a page table with the control code buffer identity
+ *    mapped, to simplify machine_kexec and make kexec_on_panic more
+ *    reliable.
+ */
+
+/*
+ * KIMAGE_NO_DEST is an impossible destination address..., for
+ * allocating pages whose destination address we do not care about.
+ */
+#define KIMAGE_NO_DEST (-1UL)
+
+static int kimage_is_destination_range(struct kexec_image *image,
+                                       unsigned long start, unsigned long end);
+static struct page_info *kimage_alloc_page(struct kexec_image *image,
+                                           unsigned long dest);
+
+static struct page_info *kimage_alloc_xen_page(void)
+{
+    void *p;
+
+    p = alloc_xenheap_page();
+    if ( p == NULL )
+        return NULL;
+    return virt_to_page(p);
+}
+
+static void kimage_free_xen_page(struct page_info *page)
+{
+    free_xenheap_page(page_to_virt(page));
+}
+
+static int do_kimage_alloc(struct kexec_image **rimage, unsigned long entry,
+                           unsigned long nr_segments,
+                           xen_kexec_segment_t *segments)
+{
+    struct kexec_image *image;
+    unsigned long i;
+    int result;
+
+    /* Allocate a controlling structure */
+    result = -ENOMEM;
+    image = xzalloc(typeof(*image));
+    if ( !image )
+        goto out;
+
+    image->head = 0;
+    image->entry = &image->head;
+    image->last_entry = &image->head;
+    image->control_page = ~0; /* By default this does not apply */
+    image->entry_maddr = entry;
+    image->type = KEXEC_TYPE_DEFAULT;
+    image->nr_segments = nr_segments;
+    image->segments = segments;
+
+    INIT_PAGE_LIST_HEAD(&image->control_pages);
+    INIT_PAGE_LIST_HEAD(&image->dest_pages);
+    INIT_PAGE_LIST_HEAD(&image->unuseable_pages);
+
+    /*
+     * Verify we have good destination addresses.  The caller is
+     * responsible for making certain we don't attempt to load
+     * the new image into invalid or reserved areas of RAM.  This
+     * just verifies it is an address we can use.
+     *
+     * Since the kernel does everything in page size chunks ensure
+     * the destination addresses are page aligned.  Too many
+     * special cases crop of when we don't do this.  The most
+     * insidious is getting overlapping destination addresses
+     * simply because addresses are changed to page size
+     * granularity.
+     */
+    result = -EADDRNOTAVAIL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+
+        mstart = image->segments[i].dest_maddr;
+        mend   = mstart + image->segments[i].dest_size;
+        if ( (mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK) )
+            goto out;
+        if ( mend >= KEXEC_DESTINATION_MEMORY_LIMIT )
+            goto out;
+    }
+
+    /* Verify our destination addresses do not overlap.
+     * If we alloed overlapping destination addresses
+     * through very weird things can happen with no
+     * easy explanation as one segment stops on another.
+     */
+    result = -EINVAL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+        unsigned long j;
+
+        mstart = image->segments[i].dest_maddr;
+        mend   = mstart + image->segments[i].dest_size;
+        for (j = 0; j < i; j++ )
+        {
+            unsigned long pstart, pend;
+            pstart = image->segments[j].dest_maddr;
+            pend   = pstart + image->segments[j].dest_size;
+            /* Do the segments overlap ? */
+            if ( (mend > pstart) && (mstart < pend) )
+                goto out;
+        }
+    }
+
+    /* Ensure our buffer sizes are strictly less than
+     * our memory sizes.  This should always be the case,
+     * and it is easier to check up front than to be surprised
+     * later on.
+     */
+    result = -EINVAL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        if ( image->segments[i].buf_size > image->segments[i].dest_size )
+            goto out;
+    }
+
+    result = 0;
+out:
+    if ( result == 0 )
+        *rimage = image;
+    else
+        kimage_free(image);
+
+    return result;
+
+}
+
+static int kimage_normal_alloc(struct kexec_image **rimage, unsigned long entry,
+                               unsigned long nr_segments,
+                               xen_kexec_segment_t *segments)
+{
+    int result;
+    struct kexec_image *image;
+    void *code_page;
+
+    /* Allocate and initialize a controlling structure */
+    image = NULL;
+    result = do_kimage_alloc(&image, entry, nr_segments, segments);
+    if ( result )
+        goto out;
+
+    *rimage = image;
+
+    /*
+     * The control code page must still be accessible after the
+     * processor has switched to 32-bit mode.
+     */
+    code_page = alloc_xenheap_pages(0, MEMF_bits(32));
+    if ( code_page == NULL )
+    {
+        result = -ENOMEM;
+        gdprintk(XENLOG_WARNING, "Could not allocate control_code_buffer\n");
+        goto out;
+    }
+    image->control_code_page = virt_to_page(code_page);
+
+    result = 0;
+out:
+    if ( result == 0 )
+        *rimage = image;
+    else
+        xfree(image);
+
+    return result;
+}
+
+static int kimage_crash_alloc(struct kexec_image **rimage, unsigned long entry,
+                              unsigned long nr_segments,
+                              xen_kexec_segment_t *segments)
+{
+    int result;
+    struct kexec_image *image;
+    unsigned long i;
+
+    image = NULL;
+    /* Verify we have a valid entry point */
+    if ( (entry < kexec_crash_area.start)
+         || (entry > kexec_crash_area.start + kexec_crash_area.size))
+    {
+        result = -EADDRNOTAVAIL;
+        goto out;
+    }
+
+    /* Allocate and initialize a controlling structure */
+    result = do_kimage_alloc(&image, entry, nr_segments, segments);
+    if ( result )
+        goto out;
+
+    /* Enable the special crash kernel control page
+     * allocation policy.
+     */
+    image->control_page = kexec_crash_area.start;
+    image->type = KEXEC_TYPE_CRASH;
+
+    /*
+     * Verify we have good destination addresses.  Normally
+     * the caller is responsible for making certain we don't
+     * attempt to load the new image into invalid or reserved
+     * areas of RAM.  But crash kernels are preloaded into a
+     * reserved area of ram.  We must ensure the addresses
+     * are in the reserved area otherwise preloading the
+     * kernel could corrupt things.
+     */
+    result = -EADDRNOTAVAIL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+
+        mstart = image->segments[i].dest_maddr;
+        mend = mstart + image->segments[i].dest_size - 1;
+        /* Ensure we are within the crash kernel limits */
+        if ( (mstart < kexec_crash_area.start )
+             || (mend > kexec_crash_area.start + kexec_crash_area.size))
+            goto out;
+    }
+
+    /*
+     * Find a location for the control code buffer, and add
+     * the vector of segments so that it's pages will also be
+     * counted as destination pages.
+     */
+    result = -ENOMEM;
+    image->control_code_page = kimage_alloc_control_page(image);
+    if ( !image->control_code_page )
+    {
+        gdprintk(XENLOG_WARNING, "Could not allocate control_code_buffer\n");
+        goto out;
+    }
+
+    result = 0;
+out:
+    if ( result == 0 )
+        *rimage = image;
+    else
+        xfree(image);
+
+    return result;
+}
+
+static int kimage_is_destination_range(struct kexec_image *image,
+                                       unsigned long start,
+                                       unsigned long end)
+{
+    unsigned long i;
+
+    for ( i = 0; i < image->nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+
+        mstart = image->segments[i].dest_maddr;
+        mend = mstart + image->segments[i].dest_size;
+        if ( (end > mstart) && (start < mend) )
+            return 1;
+    }
+
+    return 0;
+}
+
+static void kimage_free_page_list(struct page_list_head *list)
+{
+    struct page_info *page, *next;
+
+    page_list_for_each_safe(page, next, list)
+    {
+        printk("delete page %p\n", page);
+        page_list_del(page, list);
+        kimage_free_xen_page(page);
+    }
+}
+
+static struct page_info *kimage_alloc_normal_control_page(struct kexec_image *image)
+{
+    /* Control pages are special, they are the intermediaries
+     * that are needed while we copy the rest of the pages
+     * to their final resting place.  As such they must
+     * not conflict with either the destination addresses
+     * or memory the kernel is already using.
+     *
+     * The only case where we really need more than one of
+     * these are for architectures where we cannot disable
+     * the MMU and must instead generate an identity mapped
+     * page table for all of the memory.
+     *
+     * At worst this runs in O(N) of the image size.
+     */
+    struct page_list_head extra_pages;
+    struct page_info *page = NULL;
+
+    INIT_PAGE_LIST_HEAD(&extra_pages);
+
+    /* Loop while I can allocate a page and the page allocated
+     * is a destination page.
+     */
+    do {
+        unsigned long mfn, emfn, addr, eaddr;
+
+        page = kimage_alloc_xen_page();
+        if ( !page )
+            break;
+        mfn   = page_to_mfn(page);
+        emfn  = mfn + 1;
+        addr  = mfn << PAGE_SHIFT;
+        eaddr = emfn << PAGE_SHIFT;
+        if ( (emfn >= (KEXEC_CONTROL_MEMORY_LIMIT >> PAGE_SHIFT)) ||
+             kimage_is_destination_range(image, addr, eaddr) )
+        {
+            printk("add page %p\n", page);
+            page_list_add(page, &extra_pages);
+            page = NULL;
+        }
+    } while ( !page );
+
+    if ( page )
+    {
+        /* Remember the allocated page... */
+        page_list_add(page, &image->control_pages);
+
+        /* Because the page is already in it's destination
+         * location we will never allocate another page at
+         * that address.  Therefore kimage_alloc_page
+         * will not return it (again) and we don't need
+         * to give it an entry in image->segments[].
+         */
+    }
+    /* Deal with the destination pages I have inadvertently allocated.
+     *
+     * Ideally I would convert multi-page allocations into single
+     * page allocations, and add everything to image->dest_pages.
+     *
+     * For now it is simpler to just free the pages.
+     */
+    kimage_free_page_list(&extra_pages);
+
+    return page;
+}
+
+static struct page_info *kimage_alloc_crash_control_page(struct kexec_image *image)
+{
+    /* Control pages are special, they are the intermediaries
+     * that are needed while we copy the rest of the pages
+     * to their final resting place.  As such they must
+     * not conflict with either the destination addresses
+     * or memory the kernel is already using.
+     *
+     * Control pages are also the only pags we must allocate
+     * when loading a crash kernel.  All of the other pages
+     * are specified by the segments and we just memcpy
+     * into them directly.
+     *
+     * The only case where we really need more than one of
+     * these are for architectures where we cannot disable
+     * the MMU and must instead generate an identity mapped
+     * page table for all of the memory.
+     *
+     * Given the low demand this implements a very simple
+     * allocator that finds the first hole of the appropriate
+     * size in the reserved memory region, and allocates all
+     * of the memory up to and including the hole.
+     */
+    unsigned long hole_start, hole_end, size;
+    struct page_info *page;
+
+    page = NULL;
+    size = PAGE_SIZE;
+    hole_start = (image->control_page + (size - 1)) & ~(size - 1);
+    hole_end   = hole_start + size - 1;
+    while ( hole_end <= kexec_crash_area.start + kexec_crash_area.size )
+    {
+        unsigned long i;
+
+        if ( hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT )
+            break;
+        if ( hole_end > kexec_crash_area.start + kexec_crash_area.size )
+            break;
+        /* See if I overlap any of the segments */
+        for ( i = 0; i < image->nr_segments; i++ )
+        {
+            unsigned long mstart, mend;
+
+            mstart = image->segments[i].dest_maddr;
+            mend   = mstart + image->segments[i].dest_size - 1;
+            if ( (hole_end >= mstart) && (hole_start <= mend) )
+            {
+                /* Advance the hole to the end of the segment */
+                hole_start = (mend + (size - 1)) & ~(size - 1);
+                hole_end   = hole_start + size - 1;
+                break;
+            }
+        }
+        /* If I don't overlap any segments I have found my hole! */
+        if ( i == image->nr_segments )
+        {
+            page = mfn_to_page(hole_start >> PAGE_SHIFT);
+            break;
+        }
+    }
+    if ( page )
+        image->control_page = hole_end;
+
+    return page;
+}
+
+
+struct page_info *kimage_alloc_control_page(struct kexec_image *image)
+{
+    struct page_info *pages = NULL;
+
+    switch ( image->type )
+    {
+    case KEXEC_TYPE_DEFAULT:
+        pages = kimage_alloc_normal_control_page(image);
+        break;
+    case KEXEC_TYPE_CRASH:
+        pages = kimage_alloc_crash_control_page(image);
+        break;
+    }
+
+    if ( pages )
+        clear_page(page_to_virt(pages));
+
+    return pages;
+}
+
+static int kimage_add_entry(struct kexec_image *image, kimage_entry_t entry)
+{
+    if ( *image->entry != 0 )
+        image->entry++;
+
+    if ( image->entry == image->last_entry )
+    {
+        kimage_entry_t *ind_page;
+        struct page_info *page;
+
+        page = kimage_alloc_page(image, KIMAGE_NO_DEST);
+        if ( !page )
+            return -ENOMEM;
+
+        ind_page = page_to_virt(page);
+        *image->entry = page_to_maddr(page) | IND_INDIRECTION;
+        image->entry = ind_page;
+        image->last_entry = ind_page +
+            ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
+    }
+    *image->entry = entry;
+    image->entry++;
+    *image->entry = 0;
+
+    return 0;
+}
+
+static int kimage_set_destination(struct kexec_image *image,
+                                  unsigned long destination)
+{
+    int result;
+
+    destination &= PAGE_MASK;
+    result = kimage_add_entry(image, destination | IND_DESTINATION);
+    if ( result == 0 )
+        image->destination = destination;
+
+    return result;
+}
+
+
+static int kimage_add_page(struct kexec_image *image, unsigned long page)
+{
+    int result;
+
+    page &= PAGE_MASK;
+    result = kimage_add_entry(image, page | IND_SOURCE);
+    if ( result == 0 )
+        image->destination += PAGE_SIZE;
+
+    return result;
+}
+
+
+static void kimage_free_extra_pages(struct kexec_image *image)
+{
+    kimage_free_page_list(&image->dest_pages);
+    kimage_free_page_list(&image->unuseable_pages);
+
+}
+
+static void kimage_terminate(struct kexec_image *image)
+{
+    if ( *image->entry != 0 )
+        image->entry++;
+
+    *image->entry = IND_DONE;
+}
+
+#define for_each_kimage_entry(image, ptr, entry)                      \
+    for ( ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE ); \
+          ptr = (entry & IND_INDIRECTION) ?                           \
+              maddr_to_virt((entry & PAGE_MASK)) : ptr + 1)
+
+static void kimage_free_entry(kimage_entry_t entry)
+{
+    struct page_info *page;
+
+    page = mfn_to_page(entry >> PAGE_SHIFT);
+    kimage_free_xen_page(page);
+}
+
+void kimage_free(struct kexec_image *image)
+{
+    kimage_entry_t *ptr, entry;
+    kimage_entry_t ind = 0;
+
+    if ( !image )
+        return;
+
+    kimage_free_extra_pages(image);
+    for_each_kimage_entry(image, ptr, entry)
+    {
+        if ( entry & IND_INDIRECTION )
+        {
+            /* Free the previous indirection page */
+            if ( ind & IND_INDIRECTION )
+                kimage_free_entry(ind);
+            /* Save this indirection page until we are
+             * done with it.
+             */
+            ind = entry;
+        }
+        else if ( entry & IND_SOURCE )
+            kimage_free_entry(entry);
+    }
+    /* Free the final indirection page */
+    if ( ind & IND_INDIRECTION )
+        kimage_free_entry(ind);
+
+    /* Free the kexec control pages... */
+    kimage_free_page_list(&image->control_pages);
+    xfree(image->segments);
+    xfree(image);
+}
+
+static kimage_entry_t *kimage_dst_used(struct kexec_image *image,
+                                       unsigned long page)
+{
+    kimage_entry_t *ptr, entry;
+    unsigned long destination = 0;
+
+    for_each_kimage_entry(image, ptr, entry)
+    {
+        if ( entry & IND_DESTINATION )
+            destination = entry & PAGE_MASK;
+        else if ( entry & IND_SOURCE )
+        {
+            if ( page == destination )
+                return ptr;
+            destination += PAGE_SIZE;
+        }
+    }
+
+    return NULL;
+}
+
+static struct page_info *kimage_alloc_page(struct kexec_image *image,
+                                      unsigned long destination)
+{
+    /*
+     * Here we implement safeguards to ensure that a source page
+     * is not copied to its destination page before the data on
+     * the destination page is no longer useful.
+     *
+     * To do this we maintain the invariant that a source page is
+     * either its own destination page, or it is not a
+     * destination page at all.
+     *
+     * That is slightly stronger than required, but the proof
+     * that no problems will not occur is trivial, and the
+     * implementation is simply to verify.
+     *
+     * When allocating all pages normally this algorithm will run
+     * in O(N) time, but in the worst case it will run in O(N^2)
+     * time.   If the runtime is a problem the data structures can
+     * be fixed.
+     */
+    struct page_info *page;
+    unsigned long addr;
+
+    /*
+     * Walk through the list of destination pages, and see if I
+     * have a match.
+     */
+    page_list_for_each(page, &image->dest_pages)
+    {
+        addr = page_to_mfn(page) << PAGE_SHIFT;
+        if ( addr == destination )
+        {
+            page_list_del(page, &image->dest_pages);
+            return page;
+        }
+    }
+    page = NULL;
+    for (;;)
+    {
+        kimage_entry_t *old;
+
+        /* Allocate a page, if we run out of memory give up */
+        page = kimage_alloc_xen_page();
+        if ( !page )
+            return NULL;
+        /* If the page cannot be used file it away */
+        if ( page_to_mfn(page) >
+             (KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT) )
+        {
+            page_list_add(page, &image->unuseable_pages);
+            continue;
+        }
+        addr = page_to_mfn(page) << PAGE_SHIFT;
+
+        /* If it is the destination page we want use it */
+        if ( addr == destination )
+            break;
+
+        /* If the page is not a destination page use it */
+        if ( !kimage_is_destination_range(image, addr,
+                                          addr + PAGE_SIZE) )
+            break;
+
+        /*
+         * I know that the page is someones destination page.
+         * See if there is already a source page for this
+         * destination page.  And if so swap the source pages.
+         */
+        old = kimage_dst_used(image, addr);
+        if ( old )
+        {
+            /* If so move it */
+            unsigned long old_addr;
+            struct page_info *old_page;
+
+            old_addr = *old & PAGE_MASK;
+            old_page = mfn_to_page(old_addr >> PAGE_SHIFT);
+            copy_page(page, old_page);
+            *old = addr | (*old & ~PAGE_MASK);
+
+            addr = old_addr;
+            page = old_page;
+            break;
+        }
+        else
+        {
+            /* Place the page on the destination list I
+             * will use it later.
+             */
+            page_list_add(page, &image->dest_pages);
+        }
+    }
+
+    return page;
+}
+
+static int kimage_load_normal_segment(struct kexec_image *image,
+                                      xen_kexec_segment_t *segment)
+{
+    unsigned long to_copy;
+    unsigned long src_offset;
+    unsigned long dest;
+    int ret;
+
+    to_copy = segment->buf_size;
+    src_offset = 0;
+    dest = segment->dest_maddr;
+
+    ret = kimage_set_destination(image, dest);
+    if ( ret < 0 )
+        return ret;
+
+    while ( to_copy )
+    {
+        unsigned long dest_mfn;
+        size_t dest_off;
+        struct page_info *page;
+        void *dest_va;
+        size_t size;
+
+        dest_mfn = dest >> PAGE_SHIFT;
+        dest_off = dest & ~PAGE_MASK;
+
+        size = min(PAGE_SIZE - dest_off, to_copy);
+
+        page = kimage_alloc_page(image, dest);
+        if ( !page )
+            return -ENOMEM;
+        ret = kimage_add_page(image, page_to_mfn(page) << PAGE_SHIFT);
+        if ( ret < 0 )
+            return ret;
+
+        dest_va = page_to_virt(page);
+        clear_page(dest_va);
+        ret = copy_from_guest_offset(dest_va + dest_off, segment->buf, src_offset, size);
+        if ( ret )
+            return -EFAULT;
+
+        to_copy -= size;
+        src_offset += size;
+        dest += size;
+    }
+
+    return 0;
+}
+
+static int kimage_load_crash_segment(struct kexec_image *image,
+                                     xen_kexec_segment_t *segment)
+{
+    /* For crash dumps kernels we simply copy the data from
+     * user space to it's destination.
+     * We do things a page at a time for the sake of kmap.
+     */
+	unsigned long dest;
+	unsigned long sbytes, dbytes;
+    int ret = 0;
+    unsigned long src_offset = 0;
+
+	sbytes = segment->buf_size;
+	dbytes = segment->dest_size;
+	dest = segment->dest_maddr;
+
+	while ( dbytes )
+    {
+        unsigned long dest_mfn;
+        size_t dest_off;
+        void *dest_va;
+		size_t schunk, dchunk;
+
+        dest_mfn = dest >> PAGE_SHIFT;
+        dest_off = dest & ~PAGE_MASK;
+
+		dchunk = min(PAGE_SIZE - dest_off, dbytes);
+        schunk = min(dchunk, sbytes);
+
+		dest_va = vmap(&dest_mfn, 1);
+        if ( dest_va == NULL )
+            return -EINVAL;
+
+        ret = copy_from_guest_offset(dest_va + dest_off, segment->buf, src_offset, schunk);
+        memset(dest_va + dest_off + schunk, 0, dchunk - schunk);
+
+		vunmap(dest_va);
+		if ( ret )
+            return -EFAULT;
+
+		dbytes -= dchunk;
+		sbytes -= schunk;
+		dest += dchunk;
+        src_offset += schunk;
+	}
+
+    return 0;
+}
+
+static int kimage_load_segment(struct kexec_image *image, xen_kexec_segment_t *segment)
+{
+    int result = -ENOMEM;
+
+    switch ( image->type )
+    {
+    case KEXEC_TYPE_DEFAULT:
+        result = kimage_load_normal_segment(image, segment);
+        break;
+    case KEXEC_TYPE_CRASH:
+        result = kimage_load_crash_segment(image, segment);
+        break;
+    }
+
+    return result;
+}
+
+int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch,
+                 uint64_t entry_maddr,
+                 uint32_t nr_segments, xen_kexec_segment_t *segment)
+{
+    int result;
+
+    switch( type )
+    {
+    case KEXEC_TYPE_DEFAULT:
+        result = kimage_normal_alloc(rimage, entry_maddr, nr_segments, segment);
+        break;
+    case KEXEC_TYPE_CRASH:
+        result = kimage_crash_alloc(rimage, entry_maddr, nr_segments, segment);
+        break;
+    default:
+        result = -EINVAL;
+        break;
+    }
+    if ( result < 0 )
+        return result;
+
+    (*rimage)->arch = arch;
+
+    return result;
+}
+
+int kimage_load_segments(struct kexec_image *image)
+{
+    int s;
+    int result;
+
+    for ( s = 0; s < image->nr_segments; s++ ) {
+        result = kimage_load_segment(image, &image->segments[s]);
+        if ( result < 0 )
+            return result;
+    }
+    kimage_terminate(image);
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h
new file mode 100644
index 0000000..dc71b87
--- /dev/null
+++ b/xen/include/xen/kimage.h
@@ -0,0 +1,64 @@
+#ifndef __XEN_KIMAGE_H__
+#define __XEN_KIMAGE_H__
+
+#include <xen/list.h>
+#include <xen/mm.h>
+#include <public/kexec.h>
+
+#define KEXEC_DESTINATION_MEMORY_LIMIT (~0ul)
+#define KEXEC_CONTROL_MEMORY_LIMIT (~0ul)
+#define KEXEC_CRASH_CONTROL_MEMORY_LIMIT (~0ul)
+#define KEXEC_SOURCE_MEMORY_LIMIT (~0ul)
+
+#define KEXEC_CONTROL_PAGE_SIZE PAGE_SIZE
+
+#define KEXEC_SEGMENT_MAX 16
+
+typedef unsigned long kimage_entry_t;
+#define IND_DESTINATION  0x1
+#define IND_INDIRECTION  0x2
+#define IND_DONE         0x4
+#define IND_SOURCE       0x8
+
+struct kexec_image {
+    uint8_t type;
+    uint16_t arch;
+    uint64_t entry_maddr;
+    uint32_t nr_segments;
+    xen_kexec_segment_t *segments;
+
+    kimage_entry_t head;
+    kimage_entry_t *entry;
+    kimage_entry_t *last_entry;
+
+    unsigned long destination;
+
+    struct page_info *control_code_page;
+    struct page_info *aux_page;
+
+    struct page_list_head control_pages;
+    struct page_list_head dest_pages;
+    struct page_list_head unuseable_pages;
+
+    /* Address of next control page to allocate for crash kernels. */
+    unsigned long control_page;
+};
+
+int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch,
+                 uint64_t entry_maddr,
+                 uint32_t nr_segments, xen_kexec_segment_t *segment);
+void kimage_free(struct kexec_image *image);
+int kimage_load_segments(struct kexec_image *image);
+struct page_info *kimage_alloc_control_page(struct kexec_image *image);
+
+#endif /* __XEN_KIMAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.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 Feb 21 17:48:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17:48: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 1U8aG8-0005CJ-9y; Thu, 21 Feb 2013 17:48:40 +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 1U8aG5-0005Ap-Tf
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:38 +0000
Received: from [85.158.139.211:56591] by server-2.bemta-5.messagelabs.com id
	60/00-16911-5FD56215; Thu, 21 Feb 2013 17:48:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361468913!18669277!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16286 invoked from network); 21 Feb 2013 17:48:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803707"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-Gb;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:10 +0000
Message-ID: <1361468894-18655-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/8] kexec: add infrastructure for handling
	kexec images
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the code needed to handle and load kexec images into Xen memory or
into the crash region.  This is needed for the new KEXEC_CMD_load and
KEXEC_CMD_unload hypercall sub-ops.

Much of this code is derived from the Linux kernel.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/Makefile      |    1 +
 xen/common/kimage.c      |  887 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/kimage.h |   64 ++++
 3 files changed, 952 insertions(+), 0 deletions(-)
 create mode 100644 xen/common/kimage.c
 create mode 100644 xen/include/xen/kimage.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1677342..4c04018 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
 obj-$(HAS_KEXEC) += kexec.o
+obj-$(HAS_KEXEC) += kimage.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
new file mode 100644
index 0000000..c5f07c3
--- /dev/null
+++ b/xen/common/kimage.c
@@ -0,0 +1,887 @@
+/*
+ * Kexec Image
+ *
+ * Copyright (C) 2013 Citrix Systems R&D Ltd.
+ *
+ * Derived from kernel/kexec.c from Linux:
+ *
+ *   Copyright (C) 2002-2004 Eric Biederman  <ebiederm@xmission.com>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/init.h>
+#include <xen/kernel.h>
+#include <xen/errno.h>
+#include <xen/spinlock.h>
+#include <xen/guest_access.h>
+#include <xen/mm.h>
+#include <xen/kexec.h>
+#include <xen/kimage.h>
+
+#include <asm/page.h>
+
+/*
+ * When kexec transitions to the new kernel there is a one-to-one
+ * mapping between physical and virtual addresses.  On processors
+ * where you can disable the MMU this is trivial, and easy.  For
+ * others it is still a simple predictable page table to setup.
+ *
+ * In that environment kexec copies the new kernel to its final
+ * resting place.  This means I can only support memory whose
+ * physical address can fit in an unsigned long.  In particular
+ * addresses where (pfn << PAGE_SHIFT) > ULONG_MAX cannot be handled.
+ * If the assembly stub has more restrictive requirements
+ * KEXEC_SOURCE_MEMORY_LIMIT and KEXEC_DEST_MEMORY_LIMIT can be
+ * defined more restrictively in <asm/kexec.h>.
+ *
+ * The code for the transition from the current kernel to the
+ * the new kernel is placed in the control_code_buffer, whose size
+ * is given by KEXEC_CONTROL_PAGE_SIZE.  In the best case only a single
+ * page of memory is necessary, but some architectures require more.
+ * Because this memory must be identity mapped in the transition from
+ * virtual to physical addresses it must live in the range
+ * 0 - TASK_SIZE, as only the user space mappings are arbitrarily
+ * modifiable.
+ *
+ * The assembly stub in the control code buffer is passed a linked list
+ * of descriptor pages detailing the source pages of the new kernel,
+ * and the destination addresses of those source pages.  As this data
+ * structure is not used in the context of the current OS, it must
+ * be self-contained.
+ *
+ * The code has been made to work with highmem pages and will use a
+ * destination page in its final resting place (if it happens
+ * to allocate it).  The end product of this is that most of the
+ * physical address space, and most of RAM can be used.
+ *
+ * Future directions include:
+ *  - allocating a page table with the control code buffer identity
+ *    mapped, to simplify machine_kexec and make kexec_on_panic more
+ *    reliable.
+ */
+
+/*
+ * KIMAGE_NO_DEST is an impossible destination address..., for
+ * allocating pages whose destination address we do not care about.
+ */
+#define KIMAGE_NO_DEST (-1UL)
+
+static int kimage_is_destination_range(struct kexec_image *image,
+                                       unsigned long start, unsigned long end);
+static struct page_info *kimage_alloc_page(struct kexec_image *image,
+                                           unsigned long dest);
+
+static struct page_info *kimage_alloc_xen_page(void)
+{
+    void *p;
+
+    p = alloc_xenheap_page();
+    if ( p == NULL )
+        return NULL;
+    return virt_to_page(p);
+}
+
+static void kimage_free_xen_page(struct page_info *page)
+{
+    free_xenheap_page(page_to_virt(page));
+}
+
+static int do_kimage_alloc(struct kexec_image **rimage, unsigned long entry,
+                           unsigned long nr_segments,
+                           xen_kexec_segment_t *segments)
+{
+    struct kexec_image *image;
+    unsigned long i;
+    int result;
+
+    /* Allocate a controlling structure */
+    result = -ENOMEM;
+    image = xzalloc(typeof(*image));
+    if ( !image )
+        goto out;
+
+    image->head = 0;
+    image->entry = &image->head;
+    image->last_entry = &image->head;
+    image->control_page = ~0; /* By default this does not apply */
+    image->entry_maddr = entry;
+    image->type = KEXEC_TYPE_DEFAULT;
+    image->nr_segments = nr_segments;
+    image->segments = segments;
+
+    INIT_PAGE_LIST_HEAD(&image->control_pages);
+    INIT_PAGE_LIST_HEAD(&image->dest_pages);
+    INIT_PAGE_LIST_HEAD(&image->unuseable_pages);
+
+    /*
+     * Verify we have good destination addresses.  The caller is
+     * responsible for making certain we don't attempt to load
+     * the new image into invalid or reserved areas of RAM.  This
+     * just verifies it is an address we can use.
+     *
+     * Since the kernel does everything in page size chunks ensure
+     * the destination addresses are page aligned.  Too many
+     * special cases crop of when we don't do this.  The most
+     * insidious is getting overlapping destination addresses
+     * simply because addresses are changed to page size
+     * granularity.
+     */
+    result = -EADDRNOTAVAIL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+
+        mstart = image->segments[i].dest_maddr;
+        mend   = mstart + image->segments[i].dest_size;
+        if ( (mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK) )
+            goto out;
+        if ( mend >= KEXEC_DESTINATION_MEMORY_LIMIT )
+            goto out;
+    }
+
+    /* Verify our destination addresses do not overlap.
+     * If we alloed overlapping destination addresses
+     * through very weird things can happen with no
+     * easy explanation as one segment stops on another.
+     */
+    result = -EINVAL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+        unsigned long j;
+
+        mstart = image->segments[i].dest_maddr;
+        mend   = mstart + image->segments[i].dest_size;
+        for (j = 0; j < i; j++ )
+        {
+            unsigned long pstart, pend;
+            pstart = image->segments[j].dest_maddr;
+            pend   = pstart + image->segments[j].dest_size;
+            /* Do the segments overlap ? */
+            if ( (mend > pstart) && (mstart < pend) )
+                goto out;
+        }
+    }
+
+    /* Ensure our buffer sizes are strictly less than
+     * our memory sizes.  This should always be the case,
+     * and it is easier to check up front than to be surprised
+     * later on.
+     */
+    result = -EINVAL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        if ( image->segments[i].buf_size > image->segments[i].dest_size )
+            goto out;
+    }
+
+    result = 0;
+out:
+    if ( result == 0 )
+        *rimage = image;
+    else
+        kimage_free(image);
+
+    return result;
+
+}
+
+static int kimage_normal_alloc(struct kexec_image **rimage, unsigned long entry,
+                               unsigned long nr_segments,
+                               xen_kexec_segment_t *segments)
+{
+    int result;
+    struct kexec_image *image;
+    void *code_page;
+
+    /* Allocate and initialize a controlling structure */
+    image = NULL;
+    result = do_kimage_alloc(&image, entry, nr_segments, segments);
+    if ( result )
+        goto out;
+
+    *rimage = image;
+
+    /*
+     * The control code page must still be accessible after the
+     * processor has switched to 32-bit mode.
+     */
+    code_page = alloc_xenheap_pages(0, MEMF_bits(32));
+    if ( code_page == NULL )
+    {
+        result = -ENOMEM;
+        gdprintk(XENLOG_WARNING, "Could not allocate control_code_buffer\n");
+        goto out;
+    }
+    image->control_code_page = virt_to_page(code_page);
+
+    result = 0;
+out:
+    if ( result == 0 )
+        *rimage = image;
+    else
+        xfree(image);
+
+    return result;
+}
+
+static int kimage_crash_alloc(struct kexec_image **rimage, unsigned long entry,
+                              unsigned long nr_segments,
+                              xen_kexec_segment_t *segments)
+{
+    int result;
+    struct kexec_image *image;
+    unsigned long i;
+
+    image = NULL;
+    /* Verify we have a valid entry point */
+    if ( (entry < kexec_crash_area.start)
+         || (entry > kexec_crash_area.start + kexec_crash_area.size))
+    {
+        result = -EADDRNOTAVAIL;
+        goto out;
+    }
+
+    /* Allocate and initialize a controlling structure */
+    result = do_kimage_alloc(&image, entry, nr_segments, segments);
+    if ( result )
+        goto out;
+
+    /* Enable the special crash kernel control page
+     * allocation policy.
+     */
+    image->control_page = kexec_crash_area.start;
+    image->type = KEXEC_TYPE_CRASH;
+
+    /*
+     * Verify we have good destination addresses.  Normally
+     * the caller is responsible for making certain we don't
+     * attempt to load the new image into invalid or reserved
+     * areas of RAM.  But crash kernels are preloaded into a
+     * reserved area of ram.  We must ensure the addresses
+     * are in the reserved area otherwise preloading the
+     * kernel could corrupt things.
+     */
+    result = -EADDRNOTAVAIL;
+    for ( i = 0; i < nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+
+        mstart = image->segments[i].dest_maddr;
+        mend = mstart + image->segments[i].dest_size - 1;
+        /* Ensure we are within the crash kernel limits */
+        if ( (mstart < kexec_crash_area.start )
+             || (mend > kexec_crash_area.start + kexec_crash_area.size))
+            goto out;
+    }
+
+    /*
+     * Find a location for the control code buffer, and add
+     * the vector of segments so that it's pages will also be
+     * counted as destination pages.
+     */
+    result = -ENOMEM;
+    image->control_code_page = kimage_alloc_control_page(image);
+    if ( !image->control_code_page )
+    {
+        gdprintk(XENLOG_WARNING, "Could not allocate control_code_buffer\n");
+        goto out;
+    }
+
+    result = 0;
+out:
+    if ( result == 0 )
+        *rimage = image;
+    else
+        xfree(image);
+
+    return result;
+}
+
+static int kimage_is_destination_range(struct kexec_image *image,
+                                       unsigned long start,
+                                       unsigned long end)
+{
+    unsigned long i;
+
+    for ( i = 0; i < image->nr_segments; i++ )
+    {
+        unsigned long mstart, mend;
+
+        mstart = image->segments[i].dest_maddr;
+        mend = mstart + image->segments[i].dest_size;
+        if ( (end > mstart) && (start < mend) )
+            return 1;
+    }
+
+    return 0;
+}
+
+static void kimage_free_page_list(struct page_list_head *list)
+{
+    struct page_info *page, *next;
+
+    page_list_for_each_safe(page, next, list)
+    {
+        printk("delete page %p\n", page);
+        page_list_del(page, list);
+        kimage_free_xen_page(page);
+    }
+}
+
+static struct page_info *kimage_alloc_normal_control_page(struct kexec_image *image)
+{
+    /* Control pages are special, they are the intermediaries
+     * that are needed while we copy the rest of the pages
+     * to their final resting place.  As such they must
+     * not conflict with either the destination addresses
+     * or memory the kernel is already using.
+     *
+     * The only case where we really need more than one of
+     * these are for architectures where we cannot disable
+     * the MMU and must instead generate an identity mapped
+     * page table for all of the memory.
+     *
+     * At worst this runs in O(N) of the image size.
+     */
+    struct page_list_head extra_pages;
+    struct page_info *page = NULL;
+
+    INIT_PAGE_LIST_HEAD(&extra_pages);
+
+    /* Loop while I can allocate a page and the page allocated
+     * is a destination page.
+     */
+    do {
+        unsigned long mfn, emfn, addr, eaddr;
+
+        page = kimage_alloc_xen_page();
+        if ( !page )
+            break;
+        mfn   = page_to_mfn(page);
+        emfn  = mfn + 1;
+        addr  = mfn << PAGE_SHIFT;
+        eaddr = emfn << PAGE_SHIFT;
+        if ( (emfn >= (KEXEC_CONTROL_MEMORY_LIMIT >> PAGE_SHIFT)) ||
+             kimage_is_destination_range(image, addr, eaddr) )
+        {
+            printk("add page %p\n", page);
+            page_list_add(page, &extra_pages);
+            page = NULL;
+        }
+    } while ( !page );
+
+    if ( page )
+    {
+        /* Remember the allocated page... */
+        page_list_add(page, &image->control_pages);
+
+        /* Because the page is already in it's destination
+         * location we will never allocate another page at
+         * that address.  Therefore kimage_alloc_page
+         * will not return it (again) and we don't need
+         * to give it an entry in image->segments[].
+         */
+    }
+    /* Deal with the destination pages I have inadvertently allocated.
+     *
+     * Ideally I would convert multi-page allocations into single
+     * page allocations, and add everything to image->dest_pages.
+     *
+     * For now it is simpler to just free the pages.
+     */
+    kimage_free_page_list(&extra_pages);
+
+    return page;
+}
+
+static struct page_info *kimage_alloc_crash_control_page(struct kexec_image *image)
+{
+    /* Control pages are special, they are the intermediaries
+     * that are needed while we copy the rest of the pages
+     * to their final resting place.  As such they must
+     * not conflict with either the destination addresses
+     * or memory the kernel is already using.
+     *
+     * Control pages are also the only pags we must allocate
+     * when loading a crash kernel.  All of the other pages
+     * are specified by the segments and we just memcpy
+     * into them directly.
+     *
+     * The only case where we really need more than one of
+     * these are for architectures where we cannot disable
+     * the MMU and must instead generate an identity mapped
+     * page table for all of the memory.
+     *
+     * Given the low demand this implements a very simple
+     * allocator that finds the first hole of the appropriate
+     * size in the reserved memory region, and allocates all
+     * of the memory up to and including the hole.
+     */
+    unsigned long hole_start, hole_end, size;
+    struct page_info *page;
+
+    page = NULL;
+    size = PAGE_SIZE;
+    hole_start = (image->control_page + (size - 1)) & ~(size - 1);
+    hole_end   = hole_start + size - 1;
+    while ( hole_end <= kexec_crash_area.start + kexec_crash_area.size )
+    {
+        unsigned long i;
+
+        if ( hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT )
+            break;
+        if ( hole_end > kexec_crash_area.start + kexec_crash_area.size )
+            break;
+        /* See if I overlap any of the segments */
+        for ( i = 0; i < image->nr_segments; i++ )
+        {
+            unsigned long mstart, mend;
+
+            mstart = image->segments[i].dest_maddr;
+            mend   = mstart + image->segments[i].dest_size - 1;
+            if ( (hole_end >= mstart) && (hole_start <= mend) )
+            {
+                /* Advance the hole to the end of the segment */
+                hole_start = (mend + (size - 1)) & ~(size - 1);
+                hole_end   = hole_start + size - 1;
+                break;
+            }
+        }
+        /* If I don't overlap any segments I have found my hole! */
+        if ( i == image->nr_segments )
+        {
+            page = mfn_to_page(hole_start >> PAGE_SHIFT);
+            break;
+        }
+    }
+    if ( page )
+        image->control_page = hole_end;
+
+    return page;
+}
+
+
+struct page_info *kimage_alloc_control_page(struct kexec_image *image)
+{
+    struct page_info *pages = NULL;
+
+    switch ( image->type )
+    {
+    case KEXEC_TYPE_DEFAULT:
+        pages = kimage_alloc_normal_control_page(image);
+        break;
+    case KEXEC_TYPE_CRASH:
+        pages = kimage_alloc_crash_control_page(image);
+        break;
+    }
+
+    if ( pages )
+        clear_page(page_to_virt(pages));
+
+    return pages;
+}
+
+static int kimage_add_entry(struct kexec_image *image, kimage_entry_t entry)
+{
+    if ( *image->entry != 0 )
+        image->entry++;
+
+    if ( image->entry == image->last_entry )
+    {
+        kimage_entry_t *ind_page;
+        struct page_info *page;
+
+        page = kimage_alloc_page(image, KIMAGE_NO_DEST);
+        if ( !page )
+            return -ENOMEM;
+
+        ind_page = page_to_virt(page);
+        *image->entry = page_to_maddr(page) | IND_INDIRECTION;
+        image->entry = ind_page;
+        image->last_entry = ind_page +
+            ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
+    }
+    *image->entry = entry;
+    image->entry++;
+    *image->entry = 0;
+
+    return 0;
+}
+
+static int kimage_set_destination(struct kexec_image *image,
+                                  unsigned long destination)
+{
+    int result;
+
+    destination &= PAGE_MASK;
+    result = kimage_add_entry(image, destination | IND_DESTINATION);
+    if ( result == 0 )
+        image->destination = destination;
+
+    return result;
+}
+
+
+static int kimage_add_page(struct kexec_image *image, unsigned long page)
+{
+    int result;
+
+    page &= PAGE_MASK;
+    result = kimage_add_entry(image, page | IND_SOURCE);
+    if ( result == 0 )
+        image->destination += PAGE_SIZE;
+
+    return result;
+}
+
+
+static void kimage_free_extra_pages(struct kexec_image *image)
+{
+    kimage_free_page_list(&image->dest_pages);
+    kimage_free_page_list(&image->unuseable_pages);
+
+}
+
+static void kimage_terminate(struct kexec_image *image)
+{
+    if ( *image->entry != 0 )
+        image->entry++;
+
+    *image->entry = IND_DONE;
+}
+
+#define for_each_kimage_entry(image, ptr, entry)                      \
+    for ( ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE ); \
+          ptr = (entry & IND_INDIRECTION) ?                           \
+              maddr_to_virt((entry & PAGE_MASK)) : ptr + 1)
+
+static void kimage_free_entry(kimage_entry_t entry)
+{
+    struct page_info *page;
+
+    page = mfn_to_page(entry >> PAGE_SHIFT);
+    kimage_free_xen_page(page);
+}
+
+void kimage_free(struct kexec_image *image)
+{
+    kimage_entry_t *ptr, entry;
+    kimage_entry_t ind = 0;
+
+    if ( !image )
+        return;
+
+    kimage_free_extra_pages(image);
+    for_each_kimage_entry(image, ptr, entry)
+    {
+        if ( entry & IND_INDIRECTION )
+        {
+            /* Free the previous indirection page */
+            if ( ind & IND_INDIRECTION )
+                kimage_free_entry(ind);
+            /* Save this indirection page until we are
+             * done with it.
+             */
+            ind = entry;
+        }
+        else if ( entry & IND_SOURCE )
+            kimage_free_entry(entry);
+    }
+    /* Free the final indirection page */
+    if ( ind & IND_INDIRECTION )
+        kimage_free_entry(ind);
+
+    /* Free the kexec control pages... */
+    kimage_free_page_list(&image->control_pages);
+    xfree(image->segments);
+    xfree(image);
+}
+
+static kimage_entry_t *kimage_dst_used(struct kexec_image *image,
+                                       unsigned long page)
+{
+    kimage_entry_t *ptr, entry;
+    unsigned long destination = 0;
+
+    for_each_kimage_entry(image, ptr, entry)
+    {
+        if ( entry & IND_DESTINATION )
+            destination = entry & PAGE_MASK;
+        else if ( entry & IND_SOURCE )
+        {
+            if ( page == destination )
+                return ptr;
+            destination += PAGE_SIZE;
+        }
+    }
+
+    return NULL;
+}
+
+static struct page_info *kimage_alloc_page(struct kexec_image *image,
+                                      unsigned long destination)
+{
+    /*
+     * Here we implement safeguards to ensure that a source page
+     * is not copied to its destination page before the data on
+     * the destination page is no longer useful.
+     *
+     * To do this we maintain the invariant that a source page is
+     * either its own destination page, or it is not a
+     * destination page at all.
+     *
+     * That is slightly stronger than required, but the proof
+     * that no problems will not occur is trivial, and the
+     * implementation is simply to verify.
+     *
+     * When allocating all pages normally this algorithm will run
+     * in O(N) time, but in the worst case it will run in O(N^2)
+     * time.   If the runtime is a problem the data structures can
+     * be fixed.
+     */
+    struct page_info *page;
+    unsigned long addr;
+
+    /*
+     * Walk through the list of destination pages, and see if I
+     * have a match.
+     */
+    page_list_for_each(page, &image->dest_pages)
+    {
+        addr = page_to_mfn(page) << PAGE_SHIFT;
+        if ( addr == destination )
+        {
+            page_list_del(page, &image->dest_pages);
+            return page;
+        }
+    }
+    page = NULL;
+    for (;;)
+    {
+        kimage_entry_t *old;
+
+        /* Allocate a page, if we run out of memory give up */
+        page = kimage_alloc_xen_page();
+        if ( !page )
+            return NULL;
+        /* If the page cannot be used file it away */
+        if ( page_to_mfn(page) >
+             (KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT) )
+        {
+            page_list_add(page, &image->unuseable_pages);
+            continue;
+        }
+        addr = page_to_mfn(page) << PAGE_SHIFT;
+
+        /* If it is the destination page we want use it */
+        if ( addr == destination )
+            break;
+
+        /* If the page is not a destination page use it */
+        if ( !kimage_is_destination_range(image, addr,
+                                          addr + PAGE_SIZE) )
+            break;
+
+        /*
+         * I know that the page is someones destination page.
+         * See if there is already a source page for this
+         * destination page.  And if so swap the source pages.
+         */
+        old = kimage_dst_used(image, addr);
+        if ( old )
+        {
+            /* If so move it */
+            unsigned long old_addr;
+            struct page_info *old_page;
+
+            old_addr = *old & PAGE_MASK;
+            old_page = mfn_to_page(old_addr >> PAGE_SHIFT);
+            copy_page(page, old_page);
+            *old = addr | (*old & ~PAGE_MASK);
+
+            addr = old_addr;
+            page = old_page;
+            break;
+        }
+        else
+        {
+            /* Place the page on the destination list I
+             * will use it later.
+             */
+            page_list_add(page, &image->dest_pages);
+        }
+    }
+
+    return page;
+}
+
+static int kimage_load_normal_segment(struct kexec_image *image,
+                                      xen_kexec_segment_t *segment)
+{
+    unsigned long to_copy;
+    unsigned long src_offset;
+    unsigned long dest;
+    int ret;
+
+    to_copy = segment->buf_size;
+    src_offset = 0;
+    dest = segment->dest_maddr;
+
+    ret = kimage_set_destination(image, dest);
+    if ( ret < 0 )
+        return ret;
+
+    while ( to_copy )
+    {
+        unsigned long dest_mfn;
+        size_t dest_off;
+        struct page_info *page;
+        void *dest_va;
+        size_t size;
+
+        dest_mfn = dest >> PAGE_SHIFT;
+        dest_off = dest & ~PAGE_MASK;
+
+        size = min(PAGE_SIZE - dest_off, to_copy);
+
+        page = kimage_alloc_page(image, dest);
+        if ( !page )
+            return -ENOMEM;
+        ret = kimage_add_page(image, page_to_mfn(page) << PAGE_SHIFT);
+        if ( ret < 0 )
+            return ret;
+
+        dest_va = page_to_virt(page);
+        clear_page(dest_va);
+        ret = copy_from_guest_offset(dest_va + dest_off, segment->buf, src_offset, size);
+        if ( ret )
+            return -EFAULT;
+
+        to_copy -= size;
+        src_offset += size;
+        dest += size;
+    }
+
+    return 0;
+}
+
+static int kimage_load_crash_segment(struct kexec_image *image,
+                                     xen_kexec_segment_t *segment)
+{
+    /* For crash dumps kernels we simply copy the data from
+     * user space to it's destination.
+     * We do things a page at a time for the sake of kmap.
+     */
+	unsigned long dest;
+	unsigned long sbytes, dbytes;
+    int ret = 0;
+    unsigned long src_offset = 0;
+
+	sbytes = segment->buf_size;
+	dbytes = segment->dest_size;
+	dest = segment->dest_maddr;
+
+	while ( dbytes )
+    {
+        unsigned long dest_mfn;
+        size_t dest_off;
+        void *dest_va;
+		size_t schunk, dchunk;
+
+        dest_mfn = dest >> PAGE_SHIFT;
+        dest_off = dest & ~PAGE_MASK;
+
+		dchunk = min(PAGE_SIZE - dest_off, dbytes);
+        schunk = min(dchunk, sbytes);
+
+		dest_va = vmap(&dest_mfn, 1);
+        if ( dest_va == NULL )
+            return -EINVAL;
+
+        ret = copy_from_guest_offset(dest_va + dest_off, segment->buf, src_offset, schunk);
+        memset(dest_va + dest_off + schunk, 0, dchunk - schunk);
+
+		vunmap(dest_va);
+		if ( ret )
+            return -EFAULT;
+
+		dbytes -= dchunk;
+		sbytes -= schunk;
+		dest += dchunk;
+        src_offset += schunk;
+	}
+
+    return 0;
+}
+
+static int kimage_load_segment(struct kexec_image *image, xen_kexec_segment_t *segment)
+{
+    int result = -ENOMEM;
+
+    switch ( image->type )
+    {
+    case KEXEC_TYPE_DEFAULT:
+        result = kimage_load_normal_segment(image, segment);
+        break;
+    case KEXEC_TYPE_CRASH:
+        result = kimage_load_crash_segment(image, segment);
+        break;
+    }
+
+    return result;
+}
+
+int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch,
+                 uint64_t entry_maddr,
+                 uint32_t nr_segments, xen_kexec_segment_t *segment)
+{
+    int result;
+
+    switch( type )
+    {
+    case KEXEC_TYPE_DEFAULT:
+        result = kimage_normal_alloc(rimage, entry_maddr, nr_segments, segment);
+        break;
+    case KEXEC_TYPE_CRASH:
+        result = kimage_crash_alloc(rimage, entry_maddr, nr_segments, segment);
+        break;
+    default:
+        result = -EINVAL;
+        break;
+    }
+    if ( result < 0 )
+        return result;
+
+    (*rimage)->arch = arch;
+
+    return result;
+}
+
+int kimage_load_segments(struct kexec_image *image)
+{
+    int s;
+    int result;
+
+    for ( s = 0; s < image->nr_segments; s++ ) {
+        result = kimage_load_segment(image, &image->segments[s]);
+        if ( result < 0 )
+            return result;
+    }
+    kimage_terminate(image);
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h
new file mode 100644
index 0000000..dc71b87
--- /dev/null
+++ b/xen/include/xen/kimage.h
@@ -0,0 +1,64 @@
+#ifndef __XEN_KIMAGE_H__
+#define __XEN_KIMAGE_H__
+
+#include <xen/list.h>
+#include <xen/mm.h>
+#include <public/kexec.h>
+
+#define KEXEC_DESTINATION_MEMORY_LIMIT (~0ul)
+#define KEXEC_CONTROL_MEMORY_LIMIT (~0ul)
+#define KEXEC_CRASH_CONTROL_MEMORY_LIMIT (~0ul)
+#define KEXEC_SOURCE_MEMORY_LIMIT (~0ul)
+
+#define KEXEC_CONTROL_PAGE_SIZE PAGE_SIZE
+
+#define KEXEC_SEGMENT_MAX 16
+
+typedef unsigned long kimage_entry_t;
+#define IND_DESTINATION  0x1
+#define IND_INDIRECTION  0x2
+#define IND_DONE         0x4
+#define IND_SOURCE       0x8
+
+struct kexec_image {
+    uint8_t type;
+    uint16_t arch;
+    uint64_t entry_maddr;
+    uint32_t nr_segments;
+    xen_kexec_segment_t *segments;
+
+    kimage_entry_t head;
+    kimage_entry_t *entry;
+    kimage_entry_t *last_entry;
+
+    unsigned long destination;
+
+    struct page_info *control_code_page;
+    struct page_info *aux_page;
+
+    struct page_list_head control_pages;
+    struct page_list_head dest_pages;
+    struct page_list_head unuseable_pages;
+
+    /* Address of next control page to allocate for crash kernels. */
+    unsigned long control_page;
+};
+
+int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch,
+                 uint64_t entry_maddr,
+                 uint32_t nr_segments, xen_kexec_segment_t *segment);
+void kimage_free(struct kexec_image *image);
+int kimage_load_segments(struct kexec_image *image);
+struct page_info *kimage_alloc_control_page(struct kexec_image *image);
+
+#endif /* __XEN_KIMAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.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 Feb 21 17:48:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aG7-0005Bm-G4; Thu, 21 Feb 2013 17:48:39 +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 1U8aG5-0005Ak-EA
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:37 +0000
Received: from [85.158.139.211:56542] by server-12.bemta-5.messagelabs.com id
	CD/92-20195-4FD56215; Thu, 21 Feb 2013 17:48:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15769 invoked from network); 21 Feb 2013 17:48:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803702"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-DC;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:08 +0000
Message-ID: <1361468894-18655-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] xen: make GUEST_HANDLE_64() and
	uint64_aligned_t available everywhere
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

GUEST_HANDLE_64() and uint64_aligned_t allow hypercall ABI structures
to be identical (binary compatible) for 32 and 64-bit guests.  They
are currently limited to only being available for use in sysctls and
domctls.  Relax this limit so it may be used by any new structures.

There is a minimal cost for 32-bit guests on 64-but hypervisors as
set_guest_handle() needs to 0 the whole field on GUEST_HANDLE_64()
handles, but this is expected to be less than the overhead of having
to translate compat structures.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/include/public/arch-x86/xen-x86_32.h |    4 +---
 xen/include/public/xen.h                 |   13 ++++++++-----
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/include/public/arch-x86/xen-x86_32.h b/xen/include/public/arch-x86/xen-x86_32.h
index 906e74a..08fac7a 100644
--- a/xen/include/public/arch-x86/xen-x86_32.h
+++ b/xen/include/public/arch-x86/xen-x86_32.h
@@ -91,8 +91,7 @@
 #define machine_to_phys_mapping ((unsigned long *)MACH2PHYS_VIRT_START)
 #endif
 
-/* 32-/64-bit invariability for control interfaces (domctl/sysctl). */
-#if defined(__XEN__) || defined(__XEN_TOOLS__)
+/* 32-/64-bit invariability. */
 #undef ___DEFINE_XEN_GUEST_HANDLE
 #define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
     typedef struct { type *p; }                                 \
@@ -107,7 +106,6 @@
 #define uint64_aligned_t uint64_t __attribute__((aligned(8)))
 #define __XEN_GUEST_HANDLE_64(name) __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE_64(name) __XEN_GUEST_HANDLE_64(name)
-#endif
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..c18e7ce 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -840,9 +840,14 @@ __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
 
 #endif /* !__ASSEMBLY__ */
 
-/* Default definitions for macros used by domctl/sysctl. */
-#if defined(__XEN__) || defined(__XEN_TOOLS__)
-
+/*
+ * Default definitions for 32/64-bit invariant macros.
+ *
+ * Use these in ABI structures that should be identical for 32 and
+ * 64-bit guests. There is some (very small) overhead in using
+ * XEN_GUEST_HANDLE_64() instead of XEN_GUEST_HANDLE() so avoid for
+ * very hot paths.
+ */
 #ifndef uint64_aligned_t
 #define uint64_aligned_t uint64_t
 #endif
@@ -857,8 +862,6 @@ struct xenctl_cpumap {
 };
 #endif
 
-#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
-
 #endif /* __XEN_PUBLIC_XEN_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 Thu Feb 21 17:48:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aG7-0005Bm-G4; Thu, 21 Feb 2013 17:48:39 +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 1U8aG5-0005Ak-EA
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:48:37 +0000
Received: from [85.158.139.211:56542] by server-12.bemta-5.messagelabs.com id
	CD/92-20195-4FD56215; Thu, 21 Feb 2013 17:48:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361468904!18624452!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15769 invoked from network); 21 Feb 2013 17:48:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:48:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8803702"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:48:23 -0500
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 1U8aFr-0001Ag-DC;
	Thu, 21 Feb 2013 17:48:23 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:48:08 +0000
Message-ID: <1361468894-18655-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/8] xen: make GUEST_HANDLE_64() and
	uint64_aligned_t available everywhere
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

GUEST_HANDLE_64() and uint64_aligned_t allow hypercall ABI structures
to be identical (binary compatible) for 32 and 64-bit guests.  They
are currently limited to only being available for use in sysctls and
domctls.  Relax this limit so it may be used by any new structures.

There is a minimal cost for 32-bit guests on 64-but hypervisors as
set_guest_handle() needs to 0 the whole field on GUEST_HANDLE_64()
handles, but this is expected to be less than the overhead of having
to translate compat structures.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/include/public/arch-x86/xen-x86_32.h |    4 +---
 xen/include/public/xen.h                 |   13 ++++++++-----
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/include/public/arch-x86/xen-x86_32.h b/xen/include/public/arch-x86/xen-x86_32.h
index 906e74a..08fac7a 100644
--- a/xen/include/public/arch-x86/xen-x86_32.h
+++ b/xen/include/public/arch-x86/xen-x86_32.h
@@ -91,8 +91,7 @@
 #define machine_to_phys_mapping ((unsigned long *)MACH2PHYS_VIRT_START)
 #endif
 
-/* 32-/64-bit invariability for control interfaces (domctl/sysctl). */
-#if defined(__XEN__) || defined(__XEN_TOOLS__)
+/* 32-/64-bit invariability. */
 #undef ___DEFINE_XEN_GUEST_HANDLE
 #define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
     typedef struct { type *p; }                                 \
@@ -107,7 +106,6 @@
 #define uint64_aligned_t uint64_t __attribute__((aligned(8)))
 #define __XEN_GUEST_HANDLE_64(name) __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE_64(name) __XEN_GUEST_HANDLE_64(name)
-#endif
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..c18e7ce 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -840,9 +840,14 @@ __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
 
 #endif /* !__ASSEMBLY__ */
 
-/* Default definitions for macros used by domctl/sysctl. */
-#if defined(__XEN__) || defined(__XEN_TOOLS__)
-
+/*
+ * Default definitions for 32/64-bit invariant macros.
+ *
+ * Use these in ABI structures that should be identical for 32 and
+ * 64-bit guests. There is some (very small) overhead in using
+ * XEN_GUEST_HANDLE_64() instead of XEN_GUEST_HANDLE() so avoid for
+ * very hot paths.
+ */
 #ifndef uint64_aligned_t
 #define uint64_aligned_t uint64_t
 #endif
@@ -857,8 +862,6 @@ struct xenctl_cpumap {
 };
 #endif
 
-#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
-
 #endif /* __XEN_PUBLIC_XEN_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 Thu Feb 21 17:54:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aM2-0006px-Bp; Thu, 21 Feb 2013 17:54:46 +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 1U8aM1-0006pq-3C
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:54:45 +0000
Received: from [85.158.137.99:61894] by server-11.bemta-3.messagelabs.com id
	D3/9D-10249-46F56215; Thu, 21 Feb 2013 17:54:44 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361469281!12338789!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9004 invoked from network); 21 Feb 2013 17:54:43 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:54:43 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so11631774iea.22
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 09:54:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=cJaUzcsB7j+Rm+MCkGU+pFEpNcDJrq5HwD78JPshfwo=;
	b=P4EoZgY7GcLVmTkymMCW0cJ/iwEuVLZVwJZAtaOoGn0YA8WYSHXjtYdR/4fGKoEeDC
	avNSpVSoBeF1Ky3KdkRU+LoIJDFHD2v2WnmuUrj4TBzRq7yRQc990iVtdYQwFBfeYF78
	8r2q2PGXSJ5iElC1Lv9S9GliXTelt5FAGZsNYTFwSpM52Im+iWD3rty8msHjZBkf7Hxl
	tGdp9KynOw2ta84NYvqt4Mo9HWkly8XpW41Em02eiYKXe/PR+x4DkYHYwpvb4+XrUpuy
	87WwLDp3cyjpoVUuHcL6TeyBFEGR8NtbiaBIlccP3O8NjJpl0HsGjWYhXTsQ0q288TVi
	dhZw==
X-Received: by 10.42.148.71 with SMTP id q7mr11234201icv.53.1361469281336;
	Thu, 21 Feb 2013 09:54:41 -0800 (PST)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id z1sm1831092igc.1.2013.02.21.09.54.38
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 09:54:40 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20130221174253.GG24051@ocelot.phlegethon.org>
Date: Thu, 21 Feb 2013 12:54:46 -0500
Message-Id: <84EEC443-403A-45DD-9105-464195DD9055@gridcentric.ca>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
	<A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
	<20130221174253.GG24051@ocelot.phlegethon.org>
To: Tim Deegan <tim@xen.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnO+LPSVOwSdA5IkrjplwmavpFcoI4hPGTG2CcEb1hqjA44xp+BePrJF9QdMtFFekz3+xtf
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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

On Feb 21, 2013, at 12:42 PM, Tim Deegan <tim@xen.org> wrote:

> At 09:58 -0500 on 21 Feb (1361440689), Andres Lagar-Cavilla wrote:
>>> The remaining locked lookups are in sh_page_fault() (in a path that's
>>> almost always already serializing on the paging lock), and in
>>> emulate_map_dest() (which can probably be updated to use
>>> get_page_from_gfn()).
>> That is absolutely the case. Here is a rough patch:
> 
> Applied, thanks.  I've taken your S-o-b below to apply to this patch
> too; hope that's OK. 

Cool, thanks
Andres

> 
> Tim.
> 
>> diff -r 7324955b35ad xen/arch/x86/mm/shadow/multi.c
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -4861,6 +4861,7 @@ static mfn_t emulate_gva_to_mfn(struct v
>>                                 struct sh_emulate_ctxt *sh_ctxt)
>> {
>>     unsigned long gfn;
>> +    struct page_info *page;
>>     mfn_t mfn;
>>     p2m_type_t p2mt;
>>     uint32_t pfec = PFEC_page_present | PFEC_write_access;
>> @@ -4878,22 +4879,30 @@ static mfn_t emulate_gva_to_mfn(struct v
>> 
>>     /* Translate the GFN to an MFN */
>>     ASSERT(!paging_locked_by_me(v->domain));
>> -    mfn = get_gfn(v->domain, _gfn(gfn), &p2mt);
>> -        
>> +    page = get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
>> +
>> +    /* Sanity checking */
>> +    if ( page == NULL )
>> +    {
>> +        return _mfn(BAD_GFN_TO_MFN);
>> +    }
>>     if ( p2m_is_readonly(p2mt) )
>>     {
>> -        put_gfn(v->domain, gfn);
>> +        put_page(page);
>>         return _mfn(READONLY_GFN);
>>     }
>>     if ( !p2m_is_ram(p2mt) )
>>     {
>> -        put_gfn(v->domain, gfn);
>> +        put_page(page);
>>         return _mfn(BAD_GFN_TO_MFN);
>>     }
>> -
>> +    mfn = page_to_mfn(page);
>>     ASSERT(mfn_valid(mfn));
>> +
>>     v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
>> -    put_gfn(v->domain, gfn);
>> +    /* Note shadow cannot page out or unshare this mfn, so the map won't
>> +     * disappear. Otherwise, caller must hold onto page until done. */
>> +    put_page(page);
>>     return mfn;
>> }
>> 
>> 
>> 
>>> They're not addressed here but may be in a
>>> follow-up patch.
>>> 
>> 
>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> or Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>? see http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:54:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aM2-0006px-Bp; Thu, 21 Feb 2013 17:54:46 +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 1U8aM1-0006pq-3C
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:54:45 +0000
Received: from [85.158.137.99:61894] by server-11.bemta-3.messagelabs.com id
	D3/9D-10249-46F56215; Thu, 21 Feb 2013 17:54:44 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361469281!12338789!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9004 invoked from network); 21 Feb 2013 17:54:43 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:54:43 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so11631774iea.22
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 09:54:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=cJaUzcsB7j+Rm+MCkGU+pFEpNcDJrq5HwD78JPshfwo=;
	b=P4EoZgY7GcLVmTkymMCW0cJ/iwEuVLZVwJZAtaOoGn0YA8WYSHXjtYdR/4fGKoEeDC
	avNSpVSoBeF1Ky3KdkRU+LoIJDFHD2v2WnmuUrj4TBzRq7yRQc990iVtdYQwFBfeYF78
	8r2q2PGXSJ5iElC1Lv9S9GliXTelt5FAGZsNYTFwSpM52Im+iWD3rty8msHjZBkf7Hxl
	tGdp9KynOw2ta84NYvqt4Mo9HWkly8XpW41Em02eiYKXe/PR+x4DkYHYwpvb4+XrUpuy
	87WwLDp3cyjpoVUuHcL6TeyBFEGR8NtbiaBIlccP3O8NjJpl0HsGjWYhXTsQ0q288TVi
	dhZw==
X-Received: by 10.42.148.71 with SMTP id q7mr11234201icv.53.1361469281336;
	Thu, 21 Feb 2013 09:54:41 -0800 (PST)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id z1sm1831092igc.1.2013.02.21.09.54.38
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 09:54:40 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20130221174253.GG24051@ocelot.phlegethon.org>
Date: Thu, 21 Feb 2013 12:54:46 -0500
Message-Id: <84EEC443-403A-45DD-9105-464195DD9055@gridcentric.ca>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
	<A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
	<20130221174253.GG24051@ocelot.phlegethon.org>
To: Tim Deegan <tim@xen.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnO+LPSVOwSdA5IkrjplwmavpFcoI4hPGTG2CcEb1hqjA44xp+BePrJF9QdMtFFekz3+xtf
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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

On Feb 21, 2013, at 12:42 PM, Tim Deegan <tim@xen.org> wrote:

> At 09:58 -0500 on 21 Feb (1361440689), Andres Lagar-Cavilla wrote:
>>> The remaining locked lookups are in sh_page_fault() (in a path that's
>>> almost always already serializing on the paging lock), and in
>>> emulate_map_dest() (which can probably be updated to use
>>> get_page_from_gfn()).
>> That is absolutely the case. Here is a rough patch:
> 
> Applied, thanks.  I've taken your S-o-b below to apply to this patch
> too; hope that's OK. 

Cool, thanks
Andres

> 
> Tim.
> 
>> diff -r 7324955b35ad xen/arch/x86/mm/shadow/multi.c
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -4861,6 +4861,7 @@ static mfn_t emulate_gva_to_mfn(struct v
>>                                 struct sh_emulate_ctxt *sh_ctxt)
>> {
>>     unsigned long gfn;
>> +    struct page_info *page;
>>     mfn_t mfn;
>>     p2m_type_t p2mt;
>>     uint32_t pfec = PFEC_page_present | PFEC_write_access;
>> @@ -4878,22 +4879,30 @@ static mfn_t emulate_gva_to_mfn(struct v
>> 
>>     /* Translate the GFN to an MFN */
>>     ASSERT(!paging_locked_by_me(v->domain));
>> -    mfn = get_gfn(v->domain, _gfn(gfn), &p2mt);
>> -        
>> +    page = get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
>> +
>> +    /* Sanity checking */
>> +    if ( page == NULL )
>> +    {
>> +        return _mfn(BAD_GFN_TO_MFN);
>> +    }
>>     if ( p2m_is_readonly(p2mt) )
>>     {
>> -        put_gfn(v->domain, gfn);
>> +        put_page(page);
>>         return _mfn(READONLY_GFN);
>>     }
>>     if ( !p2m_is_ram(p2mt) )
>>     {
>> -        put_gfn(v->domain, gfn);
>> +        put_page(page);
>>         return _mfn(BAD_GFN_TO_MFN);
>>     }
>> -
>> +    mfn = page_to_mfn(page);
>>     ASSERT(mfn_valid(mfn));
>> +
>>     v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
>> -    put_gfn(v->domain, gfn);
>> +    /* Note shadow cannot page out or unshare this mfn, so the map won't
>> +     * disappear. Otherwise, caller must hold onto page until done. */
>> +    put_page(page);
>>     return mfn;
>> }
>> 
>> 
>> 
>>> They're not addressed here but may be in a
>>> follow-up patch.
>>> 
>> 
>> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> or Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>? see http://lists.xen.org/archives/html/xen-devel/2012-04/msg00962.html
>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP5-0006zE-Sg; Thu, 21 Feb 2013 17:57:55 +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 1U8aP4-0006yF-Gy
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:54 +0000
Received: from [85.158.139.83:4129] by server-4.bemta-5.messagelabs.com id
	12/96-29496-12066215; Thu, 21 Feb 2013 17:57:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361469468!24447645!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15871 invoked from network); 21 Feb 2013 17:57:52 -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;
	21 Feb 2013 17:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8806244"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-GP;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:39 +0000
Message-ID: <1361469460-18771-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] kexec/xen: use libxc to get location of
	crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 xc_kexec_get_range(KEXEC_RANGE_MA_CPU) instead of parsing
/proc/iomem (which is only populated by non-upstream ("classic") Xen
kernels).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 kexec/crashdump-xen.c |   61 ++++++++++++++++++++++++++++---------------------
 1 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index ff4706c..13335a5 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -163,42 +163,51 @@ unsigned long xen_architecture(struct crash_elf_info *elf_info)
 	return machine;
 }
 
-static int xen_crash_note_callback(void *UNUSED(data), int nr,
-				   char *UNUSED(str),
-				   unsigned long base,
-				   unsigned long length)
-{
-	struct crash_note_info *note = xen_phys_notes + nr;
-
-	note->base = base;
-	note->length = length;
-
-	return 0;
-}
-
+#ifdef HAVE_LIBXENCTRL
 int xen_get_nr_phys_cpus(void)
 {
-	char *match = "Crash note\n";
-	int cpus, n;
+	xc_interface *xc;
+	int cpu;
 
 	if (xen_phys_cpus)
 		return xen_phys_cpus;
 
-	if ((cpus = kexec_iomem_for_each_line(match, NULL, NULL))) {
-		n = sizeof(struct crash_note_info) * cpus;
-		xen_phys_notes = malloc(n);
-		if (!xen_phys_notes) {
-			fprintf(stderr, "failed to allocate xen_phys_notes.\n");
+	xc = xc_interface_open(NULL, NULL, 0);
+	if ( !xc ) {
+		fprintf(stderr, "failed to open xen control interface.\n");
+		return -1;
+	}
+
+	for (cpu = 0;; cpu++) {
+		uint64_t size, start;
+		int ret;
+
+		ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_CPU, cpu, &size, &start);
+		if (ret < 0)
+			break;
+
+		xen_phys_notes = realloc(xen_phys_notes,
+					 sizeof(*xen_phys_notes) * (cpu + 1));
+		if (xen_phys_notes == NULL)
 			return -1;
-		}
-		memset(xen_phys_notes, 0, n);
-		kexec_iomem_for_each_line(match,
-					  xen_crash_note_callback, NULL);
-		xen_phys_cpus = cpus;
+
+		xen_phys_notes[cpu].base = start;
+		xen_phys_notes[cpu].length = size;
 	}
 
-	return cpus;
+	xc_interface_close(xc);
+
+	xen_phys_cpus = cpu;
+
+	return cpu;
 }
+#else
+int xen_get_nr_phys_cpus(void)
+{
+	return -1;
+}
+#endif
+
 
 int xen_get_note(int cpu, uint64_t *addr, uint64_t *len)
 {
-- 
1.7.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 Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP2-0006xn-Vv; Thu, 21 Feb 2013 17:57:52 +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 1U8aP1-0006xO-H3
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:51 +0000
Received: from [85.158.137.99:38086] by server-6.bemta-3.messagelabs.com id
	D0/18-29959-E1066215; Thu, 21 Feb 2013 17:57:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361469467!17352487!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31893 invoked from network); 21 Feb 2013 17:57:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:57:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8373186"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-Fs;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:38 +0000
Message-ID: <1361469460-18771-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] kexec/xen: require libxc from Xen 4.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: David Vrabel <david.vrabel@citrix.com>

libxc from Xen 4.3 added xc_kexec_load() which will be required to
load images into Xen in the future.

Remove all the #ifdef'ery for older versions of libxc.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 configure.ac                       |    5 +-
 kexec/arch/i386/crashdump-x86.c    |  109 ------------------------------------
 kexec/arch/i386/kexec-x86-common.c |  103 ----------------------------------
 kexec/crashdump-xen.c              |   12 ----
 4 files changed, 1 insertions(+), 228 deletions(-)

diff --git a/configure.ac b/configure.ac
index 438b3c9..120a5ed 100644
--- a/configure.ac
+++ b/configure.ac
@@ -161,11 +161,8 @@ fi
 dnl find Xen control stack libraries
 if test "$with_xen" = yes ; then
 	AC_CHECK_HEADER(xenctrl.h,
-		AC_CHECK_LIB(xenctrl, xc_version, ,
+		AC_CHECK_LIB(xenctrl, xc_kexec_load, ,
 		AC_MSG_NOTICE([Xen support disabled])))
-	if test "$ac_cv_lib_xenctrl_xc_version" = yes ; then
-		AC_CHECK_FUNCS(xc_get_machine_memory_map)
-	fi
 fi
 
 dnl ---Sanity checks
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 245402c..f9709fe 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -43,14 +43,7 @@
 #include "crashdump-x86.h"
 
 #ifdef HAVE_LIBXENCTRL
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 #include <xenctrl.h>
-#else
-#define __XEN_TOOLS__	1
-#include <xen/xen.h>
-#include <xen/memory.h>
-#include <xen/sys/privcmd.h>
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
 #endif /* HAVE_LIBXENCTRL */
 
 #include <x86/x86-linux.h>
@@ -294,34 +287,20 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 }
 
 #ifdef HAVE_LIBXENCTRL
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 static int get_crash_memory_ranges_xen(struct memory_range **range,
 					int *ranges, unsigned long lowmem_limit)
 {
 	int j, rc, ret = -1;
 	struct e820entry e820entries[CRASH_MAX_MEMORY_RANGES];
 	unsigned int i;
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc_interface *xc;
-#else
-	int xc;
-#endif
 
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc = xc_interface_open(NULL, NULL, 0);
 
 	if (!xc) {
 		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
 		goto err;
 	}
-#else
-	xc = xc_interface_open();
-
-	if (xc == -1) {
-		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
-		goto err;
-	}
-#endif
 
 	rc = xc_get_machine_memory_map(xc, e820entries, CRASH_MAX_MEMORY_RANGES);
 
@@ -357,94 +336,6 @@ err:
 static int get_crash_memory_ranges_xen(struct memory_range **range,
 					int *ranges, unsigned long lowmem_limit)
 {
-	int fd, j, rc, ret = -1;
-	privcmd_hypercall_t hypercall;
-	struct e820entry *e820entries = NULL;
-	struct xen_memory_map *xen_memory_map = NULL;
-	unsigned int i;
-
-	fd = open("/proc/xen/privcmd", O_RDWR);
-
-	if (fd == -1) {
-		fprintf(stderr, "%s: open(/proc/xen/privcmd): %m\n", __func__);
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&e820entries, getpagesize(),
-			    sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(e820entries): %s\n", __func__, strerror(rc));
-		e820entries = NULL;
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&xen_memory_map, getpagesize(),
-			    sizeof(struct xen_memory_map));
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(xen_memory_map): %s\n", __func__, strerror(rc));
-		xen_memory_map = NULL;
-		goto err;
-	}
-
-	if (mlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES) == -1) {
-		fprintf(stderr, "%s: mlock(e820entries): %m\n", __func__);
-		goto err;
-	}
-
-	if (mlock(xen_memory_map, sizeof(struct xen_memory_map)) == -1) {
-		fprintf(stderr, "%s: mlock(xen_memory_map): %m\n", __func__);
-		goto err;
-	}
-
-	xen_memory_map->nr_entries = CRASH_MAX_MEMORY_RANGES;
-	set_xen_guest_handle(xen_memory_map->buffer, e820entries);
-
-	hypercall.op = __HYPERVISOR_memory_op;
-	hypercall.arg[0] = XENMEM_machine_memory_map;
-	hypercall.arg[1] = (__u64)xen_memory_map;
-
-	rc = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
-
-	if (rc == -1) {
-		fprintf(stderr, "%s: ioctl(IOCTL_PRIVCMD_HYPERCALL): %m\n", __func__);
-		goto err;
-	}
-
-	for (i = 0, j = 0; i < xen_memory_map->nr_entries &&
-				j < CRASH_MAX_MEMORY_RANGES; ++i, ++j) {
-		crash_memory_range[j].start = e820entries[i].addr;
-		crash_memory_range[j].end = e820entries[i].addr + e820entries[i].size - 1;
-		crash_memory_range[j].type = xen_e820_to_kexec_type(e820entries[i].type);
-		segregate_lowmem_region(&j, lowmem_limit);
-	}
-
-	*range = crash_memory_range;
-	*ranges = j;
-
-	qsort(*range, *ranges, sizeof(struct memory_range), compare_ranges);
-
-	if (exclude_region(ranges, crash_reserved_mem.start,
-						crash_reserved_mem.end) < 0)
-		goto err;
-
-	ret = 0;
-
-err:
-	munlock(xen_memory_map, sizeof(struct xen_memory_map));
-	munlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
-	free(xen_memory_map);
-	free(e820entries);
-	close(fd);
-
-	return ret;
-}
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
-#else
-static int get_crash_memory_ranges_xen(struct memory_range **range,
-					int *ranges, unsigned long lowmem_limit)
-{
 	return 0;
 }
 #endif /* HAVE_LIBXENCTRL */
diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index 02471a8..dba89f2 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -40,15 +40,7 @@
 #include "kexec-x86.h"
 
 #ifdef HAVE_LIBXENCTRL
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 #include <xenctrl.h>
-#else
-#define __XEN_TOOLS__	1
-#include <x86/x86-linux.h>
-#include <xen/xen.h>
-#include <xen/memory.h>
-#include <xen/sys/privcmd.h>
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
 #endif /* HAVE_LIBXENCTRL */
 
 static struct memory_range memory_range[MAX_MEMORY_RANGES];
@@ -175,33 +167,19 @@ unsigned xen_e820_to_kexec_type(uint32_t type)
  *
  * @return 0 on success, any other value on failure.
  */
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 {
 	int rc, ret = -1;
 	struct e820entry e820entries[MAX_MEMORY_RANGES];
 	unsigned int i;
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc_interface *xc;
-#else
-	int xc;
-#endif
 
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc = xc_interface_open(NULL, NULL, 0);
 
 	if (!xc) {
 		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
 		goto err;
 	}
-#else
-	xc = xc_interface_open();
-
-	if (xc == -1) {
-		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
-		goto err;
-	}
-#endif
 
 	rc = xc_get_machine_memory_map(xc, e820entries, MAX_MEMORY_RANGES);
 
@@ -231,87 +209,6 @@ err:
 #else
 static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 {
-	int fd, rc, ret = -1;
-	privcmd_hypercall_t hypercall;
-	struct e820entry *e820entries = NULL;
-	struct xen_memory_map *xen_memory_map = NULL;
-	unsigned int i;
-
-	fd = open("/proc/xen/privcmd", O_RDWR);
-
-	if (fd == -1) {
-		fprintf(stderr, "%s: open(/proc/xen/privcmd): %m\n", __func__);
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&e820entries, sysconf(_SC_PAGESIZE),
-			    sizeof(struct e820entry) * MAX_MEMORY_RANGES);
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(e820entries): %s\n", __func__, strerror(rc));
-		e820entries = NULL;
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&xen_memory_map, sysconf(_SC_PAGESIZE),
-			    sizeof(struct xen_memory_map));
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(xen_memory_map): %s\n", __func__, strerror(rc));
-		xen_memory_map = NULL;
-		goto err;
-	}
-
-	if (mlock(e820entries, sizeof(struct e820entry) * MAX_MEMORY_RANGES) == -1) {
-		fprintf(stderr, "%s: mlock(e820entries): %m\n", __func__);
-		goto err;
-	}
-
-	if (mlock(xen_memory_map, sizeof(struct xen_memory_map)) == -1) {
-		fprintf(stderr, "%s: mlock(xen_memory_map): %m\n", __func__);
-		goto err;
-	}
-
-	xen_memory_map->nr_entries = MAX_MEMORY_RANGES;
-	set_xen_guest_handle(xen_memory_map->buffer, e820entries);
-
-	hypercall.op = __HYPERVISOR_memory_op;
-	hypercall.arg[0] = XENMEM_machine_memory_map;
-	hypercall.arg[1] = (__u64)xen_memory_map;
-
-	rc = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
-
-	if (rc == -1) {
-		fprintf(stderr, "%s: ioctl(IOCTL_PRIVCMD_HYPERCALL): %m\n", __func__);
-		goto err;
-	}
-
-	for (i = 0; i < xen_memory_map->nr_entries; ++i) {
-		memory_range[i].start = e820entries[i].addr;
-		memory_range[i].end = e820entries[i].addr + e820entries[i].size;
-		memory_range[i].type = xen_e820_to_kexec_type(e820entries[i].type);
-	}
-
-	qsort(memory_range, xen_memory_map->nr_entries, sizeof(struct memory_range), compare_ranges);
-
-	*range = memory_range;
-	*ranges = xen_memory_map->nr_entries;
-
-	ret = 0;
-
-err:
-	munlock(xen_memory_map, sizeof(struct xen_memory_map));
-	munlock(e820entries, sizeof(struct e820entry) * MAX_MEMORY_RANGES);
-	free(xen_memory_map);
-	free(e820entries);
-	close(fd);
-
-	return ret;
-}
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
-#else
-static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
-{
 	return 0;
 }
 #endif /* HAVE_LIBXENCTRL */
diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index d8bd0f4..ff4706c 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -131,30 +131,18 @@ unsigned long xen_architecture(struct crash_elf_info *elf_info)
 #ifdef HAVE_LIBXENCTRL
 	int rc;
 	xen_capabilities_info_t capabilities;
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc_interface *xc;
-#else
-	int xc;
-#endif
 
 	if (!xen_present())
 		goto out;
 
 	memset(capabilities, '0', XEN_CAPABILITIES_INFO_LEN);
 
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc = xc_interface_open(NULL, NULL, 0);
 	if ( !xc ) {
 		fprintf(stderr, "failed to open xen control interface.\n");
 		goto out;
 	}
-#else
-	xc = xc_interface_open();
-	if ( xc == -1 ) {
-		fprintf(stderr, "failed to open xen control interface.\n");
-		goto out;
-	}
-#endif
 
 	rc = xc_version(xc, XENVER_capabilities, &capabilities[0]);
 	if ( rc == -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 Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP5-0006z5-F4; Thu, 21 Feb 2013 17:57:55 +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 1U8aP4-0006yA-5F
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:54 +0000
Received: from [85.158.139.83:40303] by server-2.bemta-5.messagelabs.com id
	F3/6B-16911-12066215; Thu, 21 Feb 2013 17:57:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361469468!24447645!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15811 invoked from network); 21 Feb 2013 17:57:52 -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;
	21 Feb 2013 17:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8806243"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-EE;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:37 +0000
Message-ID: <1361469460-18771-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] purgatory: put variables altered by kexec
	in .data not .bss
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

elf_rel_set_symbol() fails if the symbol is in the .bss section.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 purgatory/arch/i386/console-x86.c        |    6 +++---
 purgatory/arch/i386/crashdump_backup.c   |    8 +++++---
 purgatory/arch/x86_64/purgatory-x86_64.c |    6 +++---
 purgatory/include/purgatory.h            |    4 ++++
 purgatory/purgatory.c                    |    4 ++--
 5 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/purgatory/arch/i386/console-x86.c b/purgatory/arch/i386/console-x86.c
index 9773573..40a734b 100644
--- a/purgatory/arch/i386/console-x86.c
+++ b/purgatory/arch/i386/console-x86.c
@@ -55,9 +55,9 @@ static void putchar_vga(int ch)
  */
 
 /* Base Address */
-uint8_t console_serial = 0;
-uint16_t serial_base = 0x3f8; /* TTYS0 */
-uint32_t serial_baud = 0;
+uint8_t console_serial __data = 0;
+uint16_t serial_base __data = 0x3f8; /* TTYS0 */
+uint32_t serial_baud __data = 0;
 
 #define XMTRDY          0x20
 
diff --git a/purgatory/arch/i386/crashdump_backup.c b/purgatory/arch/i386/crashdump_backup.c
index 365eb5d..0438a75 100644
--- a/purgatory/arch/i386/crashdump_backup.c
+++ b/purgatory/arch/i386/crashdump_backup.c
@@ -21,13 +21,15 @@
 #include <stdint.h>
 #include <string.h>
 
+#include <purgatory.h>
+
 /* Backup region start gets set after /proc/iomem has been parsed. */
 /* We reuse the same code for x86_64 also so changing backup_start to
    unsigned long */
-unsigned long  backup_start = 0;
+unsigned long  backup_start __data = 0;
 
-unsigned long backup_src_start = 0;
-unsigned long backup_src_size = 0;
+unsigned long backup_src_start __data = 0;
+unsigned long backup_src_size __data = 0;
 
 /* Backup first 640K of memory to backup region as reserved by kexec.
  * Assuming first 640K has to be present on i386 machines and no address
diff --git a/purgatory/arch/x86_64/purgatory-x86_64.c b/purgatory/arch/x86_64/purgatory-x86_64.c
index c25a9c2..8a3e24d 100644
--- a/purgatory/arch/x86_64/purgatory-x86_64.c
+++ b/purgatory/arch/x86_64/purgatory-x86_64.c
@@ -3,11 +3,11 @@
 #include <purgatory.h>
 #include "purgatory-x86_64.h"
 
-uint8_t reset_vga = 0;
+uint8_t reset_vga __data = 0;
 uint8_t legacy_pic = 0;
-uint8_t panic_kernel = 0;
+uint8_t panic_kernel __data = 0;
 unsigned long jump_back_entry = 0;
-char *cmdline_end = NULL;
+char *cmdline_end __data = NULL;
 
 void setup_arch(void)
 {
diff --git a/purgatory/include/purgatory.h b/purgatory/include/purgatory.h
index ed50dc4..e2b061a 100644
--- a/purgatory/include/purgatory.h
+++ b/purgatory/include/purgatory.h
@@ -1,6 +1,10 @@
 #ifndef PURGATORY_H
 #define PURGATORY_H
 
+/* Force variables that are adjusted by kexec to be in .data not
+   .bss. */
+#define __data __attribute__((section("data")))
+
 void putchar(int ch);
 void sprintf(char *buffer, const char *fmt, ...);
 void printf(const char *fmt, ...);
diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
index 3bbcc09..05f3b48 100644
--- a/purgatory/purgatory.c
+++ b/purgatory/purgatory.c
@@ -6,8 +6,8 @@
 #include <string.h>
 #include "../kexec/kexec-sha256.h"
 
-struct sha256_region sha256_regions[SHA256_REGIONS] = {};
-sha256_digest_t sha256_digest = { };
+struct sha256_region sha256_regions[SHA256_REGIONS] __data = {};
+sha256_digest_t sha256_digest __data = { };
 
 int verify_sha256_digest(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 Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP5-0006zE-Sg; Thu, 21 Feb 2013 17:57:55 +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 1U8aP4-0006yF-Gy
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:54 +0000
Received: from [85.158.139.83:4129] by server-4.bemta-5.messagelabs.com id
	12/96-29496-12066215; Thu, 21 Feb 2013 17:57:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361469468!24447645!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15871 invoked from network); 21 Feb 2013 17:57:52 -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;
	21 Feb 2013 17:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8806244"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-GP;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:39 +0000
Message-ID: <1361469460-18771-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 3/4] kexec/xen: use libxc to get location of
	crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 xc_kexec_get_range(KEXEC_RANGE_MA_CPU) instead of parsing
/proc/iomem (which is only populated by non-upstream ("classic") Xen
kernels).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 kexec/crashdump-xen.c |   61 ++++++++++++++++++++++++++++---------------------
 1 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index ff4706c..13335a5 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -163,42 +163,51 @@ unsigned long xen_architecture(struct crash_elf_info *elf_info)
 	return machine;
 }
 
-static int xen_crash_note_callback(void *UNUSED(data), int nr,
-				   char *UNUSED(str),
-				   unsigned long base,
-				   unsigned long length)
-{
-	struct crash_note_info *note = xen_phys_notes + nr;
-
-	note->base = base;
-	note->length = length;
-
-	return 0;
-}
-
+#ifdef HAVE_LIBXENCTRL
 int xen_get_nr_phys_cpus(void)
 {
-	char *match = "Crash note\n";
-	int cpus, n;
+	xc_interface *xc;
+	int cpu;
 
 	if (xen_phys_cpus)
 		return xen_phys_cpus;
 
-	if ((cpus = kexec_iomem_for_each_line(match, NULL, NULL))) {
-		n = sizeof(struct crash_note_info) * cpus;
-		xen_phys_notes = malloc(n);
-		if (!xen_phys_notes) {
-			fprintf(stderr, "failed to allocate xen_phys_notes.\n");
+	xc = xc_interface_open(NULL, NULL, 0);
+	if ( !xc ) {
+		fprintf(stderr, "failed to open xen control interface.\n");
+		return -1;
+	}
+
+	for (cpu = 0;; cpu++) {
+		uint64_t size, start;
+		int ret;
+
+		ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_CPU, cpu, &size, &start);
+		if (ret < 0)
+			break;
+
+		xen_phys_notes = realloc(xen_phys_notes,
+					 sizeof(*xen_phys_notes) * (cpu + 1));
+		if (xen_phys_notes == NULL)
 			return -1;
-		}
-		memset(xen_phys_notes, 0, n);
-		kexec_iomem_for_each_line(match,
-					  xen_crash_note_callback, NULL);
-		xen_phys_cpus = cpus;
+
+		xen_phys_notes[cpu].base = start;
+		xen_phys_notes[cpu].length = size;
 	}
 
-	return cpus;
+	xc_interface_close(xc);
+
+	xen_phys_cpus = cpu;
+
+	return cpu;
 }
+#else
+int xen_get_nr_phys_cpus(void)
+{
+	return -1;
+}
+#endif
+
 
 int xen_get_note(int cpu, uint64_t *addr, uint64_t *len)
 {
-- 
1.7.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 Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP2-0006xn-Vv; Thu, 21 Feb 2013 17:57:52 +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 1U8aP1-0006xO-H3
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:51 +0000
Received: from [85.158.137.99:38086] by server-6.bemta-3.messagelabs.com id
	D0/18-29959-E1066215; Thu, 21 Feb 2013 17:57:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361469467!17352487!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31893 invoked from network); 21 Feb 2013 17:57:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:57:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8373186"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-Fs;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:38 +0000
Message-ID: <1361469460-18771-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 2/4] kexec/xen: require libxc from Xen 4.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: David Vrabel <david.vrabel@citrix.com>

libxc from Xen 4.3 added xc_kexec_load() which will be required to
load images into Xen in the future.

Remove all the #ifdef'ery for older versions of libxc.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 configure.ac                       |    5 +-
 kexec/arch/i386/crashdump-x86.c    |  109 ------------------------------------
 kexec/arch/i386/kexec-x86-common.c |  103 ----------------------------------
 kexec/crashdump-xen.c              |   12 ----
 4 files changed, 1 insertions(+), 228 deletions(-)

diff --git a/configure.ac b/configure.ac
index 438b3c9..120a5ed 100644
--- a/configure.ac
+++ b/configure.ac
@@ -161,11 +161,8 @@ fi
 dnl find Xen control stack libraries
 if test "$with_xen" = yes ; then
 	AC_CHECK_HEADER(xenctrl.h,
-		AC_CHECK_LIB(xenctrl, xc_version, ,
+		AC_CHECK_LIB(xenctrl, xc_kexec_load, ,
 		AC_MSG_NOTICE([Xen support disabled])))
-	if test "$ac_cv_lib_xenctrl_xc_version" = yes ; then
-		AC_CHECK_FUNCS(xc_get_machine_memory_map)
-	fi
 fi
 
 dnl ---Sanity checks
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 245402c..f9709fe 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -43,14 +43,7 @@
 #include "crashdump-x86.h"
 
 #ifdef HAVE_LIBXENCTRL
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 #include <xenctrl.h>
-#else
-#define __XEN_TOOLS__	1
-#include <xen/xen.h>
-#include <xen/memory.h>
-#include <xen/sys/privcmd.h>
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
 #endif /* HAVE_LIBXENCTRL */
 
 #include <x86/x86-linux.h>
@@ -294,34 +287,20 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 }
 
 #ifdef HAVE_LIBXENCTRL
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 static int get_crash_memory_ranges_xen(struct memory_range **range,
 					int *ranges, unsigned long lowmem_limit)
 {
 	int j, rc, ret = -1;
 	struct e820entry e820entries[CRASH_MAX_MEMORY_RANGES];
 	unsigned int i;
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc_interface *xc;
-#else
-	int xc;
-#endif
 
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc = xc_interface_open(NULL, NULL, 0);
 
 	if (!xc) {
 		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
 		goto err;
 	}
-#else
-	xc = xc_interface_open();
-
-	if (xc == -1) {
-		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
-		goto err;
-	}
-#endif
 
 	rc = xc_get_machine_memory_map(xc, e820entries, CRASH_MAX_MEMORY_RANGES);
 
@@ -357,94 +336,6 @@ err:
 static int get_crash_memory_ranges_xen(struct memory_range **range,
 					int *ranges, unsigned long lowmem_limit)
 {
-	int fd, j, rc, ret = -1;
-	privcmd_hypercall_t hypercall;
-	struct e820entry *e820entries = NULL;
-	struct xen_memory_map *xen_memory_map = NULL;
-	unsigned int i;
-
-	fd = open("/proc/xen/privcmd", O_RDWR);
-
-	if (fd == -1) {
-		fprintf(stderr, "%s: open(/proc/xen/privcmd): %m\n", __func__);
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&e820entries, getpagesize(),
-			    sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(e820entries): %s\n", __func__, strerror(rc));
-		e820entries = NULL;
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&xen_memory_map, getpagesize(),
-			    sizeof(struct xen_memory_map));
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(xen_memory_map): %s\n", __func__, strerror(rc));
-		xen_memory_map = NULL;
-		goto err;
-	}
-
-	if (mlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES) == -1) {
-		fprintf(stderr, "%s: mlock(e820entries): %m\n", __func__);
-		goto err;
-	}
-
-	if (mlock(xen_memory_map, sizeof(struct xen_memory_map)) == -1) {
-		fprintf(stderr, "%s: mlock(xen_memory_map): %m\n", __func__);
-		goto err;
-	}
-
-	xen_memory_map->nr_entries = CRASH_MAX_MEMORY_RANGES;
-	set_xen_guest_handle(xen_memory_map->buffer, e820entries);
-
-	hypercall.op = __HYPERVISOR_memory_op;
-	hypercall.arg[0] = XENMEM_machine_memory_map;
-	hypercall.arg[1] = (__u64)xen_memory_map;
-
-	rc = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
-
-	if (rc == -1) {
-		fprintf(stderr, "%s: ioctl(IOCTL_PRIVCMD_HYPERCALL): %m\n", __func__);
-		goto err;
-	}
-
-	for (i = 0, j = 0; i < xen_memory_map->nr_entries &&
-				j < CRASH_MAX_MEMORY_RANGES; ++i, ++j) {
-		crash_memory_range[j].start = e820entries[i].addr;
-		crash_memory_range[j].end = e820entries[i].addr + e820entries[i].size - 1;
-		crash_memory_range[j].type = xen_e820_to_kexec_type(e820entries[i].type);
-		segregate_lowmem_region(&j, lowmem_limit);
-	}
-
-	*range = crash_memory_range;
-	*ranges = j;
-
-	qsort(*range, *ranges, sizeof(struct memory_range), compare_ranges);
-
-	if (exclude_region(ranges, crash_reserved_mem.start,
-						crash_reserved_mem.end) < 0)
-		goto err;
-
-	ret = 0;
-
-err:
-	munlock(xen_memory_map, sizeof(struct xen_memory_map));
-	munlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
-	free(xen_memory_map);
-	free(e820entries);
-	close(fd);
-
-	return ret;
-}
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
-#else
-static int get_crash_memory_ranges_xen(struct memory_range **range,
-					int *ranges, unsigned long lowmem_limit)
-{
 	return 0;
 }
 #endif /* HAVE_LIBXENCTRL */
diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index 02471a8..dba89f2 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -40,15 +40,7 @@
 #include "kexec-x86.h"
 
 #ifdef HAVE_LIBXENCTRL
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 #include <xenctrl.h>
-#else
-#define __XEN_TOOLS__	1
-#include <x86/x86-linux.h>
-#include <xen/xen.h>
-#include <xen/memory.h>
-#include <xen/sys/privcmd.h>
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
 #endif /* HAVE_LIBXENCTRL */
 
 static struct memory_range memory_range[MAX_MEMORY_RANGES];
@@ -175,33 +167,19 @@ unsigned xen_e820_to_kexec_type(uint32_t type)
  *
  * @return 0 on success, any other value on failure.
  */
-#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
 static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 {
 	int rc, ret = -1;
 	struct e820entry e820entries[MAX_MEMORY_RANGES];
 	unsigned int i;
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc_interface *xc;
-#else
-	int xc;
-#endif
 
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc = xc_interface_open(NULL, NULL, 0);
 
 	if (!xc) {
 		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
 		goto err;
 	}
-#else
-	xc = xc_interface_open();
-
-	if (xc == -1) {
-		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
-		goto err;
-	}
-#endif
 
 	rc = xc_get_machine_memory_map(xc, e820entries, MAX_MEMORY_RANGES);
 
@@ -231,87 +209,6 @@ err:
 #else
 static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 {
-	int fd, rc, ret = -1;
-	privcmd_hypercall_t hypercall;
-	struct e820entry *e820entries = NULL;
-	struct xen_memory_map *xen_memory_map = NULL;
-	unsigned int i;
-
-	fd = open("/proc/xen/privcmd", O_RDWR);
-
-	if (fd == -1) {
-		fprintf(stderr, "%s: open(/proc/xen/privcmd): %m\n", __func__);
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&e820entries, sysconf(_SC_PAGESIZE),
-			    sizeof(struct e820entry) * MAX_MEMORY_RANGES);
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(e820entries): %s\n", __func__, strerror(rc));
-		e820entries = NULL;
-		goto err;
-	}
-
-	rc = posix_memalign((void **)&xen_memory_map, sysconf(_SC_PAGESIZE),
-			    sizeof(struct xen_memory_map));
-
-	if (rc) {
-		fprintf(stderr, "%s: posix_memalign(xen_memory_map): %s\n", __func__, strerror(rc));
-		xen_memory_map = NULL;
-		goto err;
-	}
-
-	if (mlock(e820entries, sizeof(struct e820entry) * MAX_MEMORY_RANGES) == -1) {
-		fprintf(stderr, "%s: mlock(e820entries): %m\n", __func__);
-		goto err;
-	}
-
-	if (mlock(xen_memory_map, sizeof(struct xen_memory_map)) == -1) {
-		fprintf(stderr, "%s: mlock(xen_memory_map): %m\n", __func__);
-		goto err;
-	}
-
-	xen_memory_map->nr_entries = MAX_MEMORY_RANGES;
-	set_xen_guest_handle(xen_memory_map->buffer, e820entries);
-
-	hypercall.op = __HYPERVISOR_memory_op;
-	hypercall.arg[0] = XENMEM_machine_memory_map;
-	hypercall.arg[1] = (__u64)xen_memory_map;
-
-	rc = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
-
-	if (rc == -1) {
-		fprintf(stderr, "%s: ioctl(IOCTL_PRIVCMD_HYPERCALL): %m\n", __func__);
-		goto err;
-	}
-
-	for (i = 0; i < xen_memory_map->nr_entries; ++i) {
-		memory_range[i].start = e820entries[i].addr;
-		memory_range[i].end = e820entries[i].addr + e820entries[i].size;
-		memory_range[i].type = xen_e820_to_kexec_type(e820entries[i].type);
-	}
-
-	qsort(memory_range, xen_memory_map->nr_entries, sizeof(struct memory_range), compare_ranges);
-
-	*range = memory_range;
-	*ranges = xen_memory_map->nr_entries;
-
-	ret = 0;
-
-err:
-	munlock(xen_memory_map, sizeof(struct xen_memory_map));
-	munlock(e820entries, sizeof(struct e820entry) * MAX_MEMORY_RANGES);
-	free(xen_memory_map);
-	free(e820entries);
-	close(fd);
-
-	return ret;
-}
-#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
-#else
-static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
-{
 	return 0;
 }
 #endif /* HAVE_LIBXENCTRL */
diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index d8bd0f4..ff4706c 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -131,30 +131,18 @@ unsigned long xen_architecture(struct crash_elf_info *elf_info)
 #ifdef HAVE_LIBXENCTRL
 	int rc;
 	xen_capabilities_info_t capabilities;
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc_interface *xc;
-#else
-	int xc;
-#endif
 
 	if (!xen_present())
 		goto out;
 
 	memset(capabilities, '0', XEN_CAPABILITIES_INFO_LEN);
 
-#ifdef XENCTRL_HAS_XC_INTERFACE
 	xc = xc_interface_open(NULL, NULL, 0);
 	if ( !xc ) {
 		fprintf(stderr, "failed to open xen control interface.\n");
 		goto out;
 	}
-#else
-	xc = xc_interface_open();
-	if ( xc == -1 ) {
-		fprintf(stderr, "failed to open xen control interface.\n");
-		goto out;
-	}
-#endif
 
 	rc = xc_version(xc, XENVER_capabilities, &capabilities[0]);
 	if ( rc == -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 Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP5-0006z5-F4; Thu, 21 Feb 2013 17:57:55 +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 1U8aP4-0006yA-5F
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:54 +0000
Received: from [85.158.139.83:40303] by server-2.bemta-5.messagelabs.com id
	F3/6B-16911-12066215; Thu, 21 Feb 2013 17:57:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361469468!24447645!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15811 invoked from network); 21 Feb 2013 17:57:52 -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;
	21 Feb 2013 17:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8806243"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-EE;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:37 +0000
Message-ID: <1361469460-18771-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 1/4] purgatory: put variables altered by kexec
	in .data not .bss
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>

elf_rel_set_symbol() fails if the symbol is in the .bss section.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 purgatory/arch/i386/console-x86.c        |    6 +++---
 purgatory/arch/i386/crashdump_backup.c   |    8 +++++---
 purgatory/arch/x86_64/purgatory-x86_64.c |    6 +++---
 purgatory/include/purgatory.h            |    4 ++++
 purgatory/purgatory.c                    |    4 ++--
 5 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/purgatory/arch/i386/console-x86.c b/purgatory/arch/i386/console-x86.c
index 9773573..40a734b 100644
--- a/purgatory/arch/i386/console-x86.c
+++ b/purgatory/arch/i386/console-x86.c
@@ -55,9 +55,9 @@ static void putchar_vga(int ch)
  */
 
 /* Base Address */
-uint8_t console_serial = 0;
-uint16_t serial_base = 0x3f8; /* TTYS0 */
-uint32_t serial_baud = 0;
+uint8_t console_serial __data = 0;
+uint16_t serial_base __data = 0x3f8; /* TTYS0 */
+uint32_t serial_baud __data = 0;
 
 #define XMTRDY          0x20
 
diff --git a/purgatory/arch/i386/crashdump_backup.c b/purgatory/arch/i386/crashdump_backup.c
index 365eb5d..0438a75 100644
--- a/purgatory/arch/i386/crashdump_backup.c
+++ b/purgatory/arch/i386/crashdump_backup.c
@@ -21,13 +21,15 @@
 #include <stdint.h>
 #include <string.h>
 
+#include <purgatory.h>
+
 /* Backup region start gets set after /proc/iomem has been parsed. */
 /* We reuse the same code for x86_64 also so changing backup_start to
    unsigned long */
-unsigned long  backup_start = 0;
+unsigned long  backup_start __data = 0;
 
-unsigned long backup_src_start = 0;
-unsigned long backup_src_size = 0;
+unsigned long backup_src_start __data = 0;
+unsigned long backup_src_size __data = 0;
 
 /* Backup first 640K of memory to backup region as reserved by kexec.
  * Assuming first 640K has to be present on i386 machines and no address
diff --git a/purgatory/arch/x86_64/purgatory-x86_64.c b/purgatory/arch/x86_64/purgatory-x86_64.c
index c25a9c2..8a3e24d 100644
--- a/purgatory/arch/x86_64/purgatory-x86_64.c
+++ b/purgatory/arch/x86_64/purgatory-x86_64.c
@@ -3,11 +3,11 @@
 #include <purgatory.h>
 #include "purgatory-x86_64.h"
 
-uint8_t reset_vga = 0;
+uint8_t reset_vga __data = 0;
 uint8_t legacy_pic = 0;
-uint8_t panic_kernel = 0;
+uint8_t panic_kernel __data = 0;
 unsigned long jump_back_entry = 0;
-char *cmdline_end = NULL;
+char *cmdline_end __data = NULL;
 
 void setup_arch(void)
 {
diff --git a/purgatory/include/purgatory.h b/purgatory/include/purgatory.h
index ed50dc4..e2b061a 100644
--- a/purgatory/include/purgatory.h
+++ b/purgatory/include/purgatory.h
@@ -1,6 +1,10 @@
 #ifndef PURGATORY_H
 #define PURGATORY_H
 
+/* Force variables that are adjusted by kexec to be in .data not
+   .bss. */
+#define __data __attribute__((section("data")))
+
 void putchar(int ch);
 void sprintf(char *buffer, const char *fmt, ...);
 void printf(const char *fmt, ...);
diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
index 3bbcc09..05f3b48 100644
--- a/purgatory/purgatory.c
+++ b/purgatory/purgatory.c
@@ -6,8 +6,8 @@
 #include <string.h>
 #include "../kexec/kexec-sha256.h"
 
-struct sha256_region sha256_regions[SHA256_REGIONS] = {};
-sha256_digest_t sha256_digest = { };
+struct sha256_region sha256_regions[SHA256_REGIONS] __data = {};
+sha256_digest_t sha256_digest __data = { };
 
 int verify_sha256_digest(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 Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP4-0006yl-TF; Thu, 21 Feb 2013 17:57:54 +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 1U8aP2-0006xY-Nh
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:53 +0000
Received: from [85.158.137.99:20251] by server-12.bemta-3.messagelabs.com id
	7D/23-05889-F1066215; Thu, 21 Feb 2013 17:57:51 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361469467!17352487!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31990 invoked from network); 21 Feb 2013 17:57:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:57:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8373187"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-H2;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:40 +0000
Message-ID: <1361469460-18771-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] kexec/xen: directly load images images into
	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

From: David Vrabel <david.vrabel@citrix.com>

Xen 4.3 has an improvided kexec hypercall ABI that allows images to be
loaded and executed without any kernel involvement.  Use the API
provided by libxc to load images when running in a Xen guest.

Support for loading images via the kexec_load syscall in non-upstream
("classic") Xen kernels is no longer supported.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 kexec/Makefile                     |    1 +
 kexec/arch/i386/crashdump-x86.c    |   19 ++++++++-
 kexec/arch/i386/kexec-x86-common.c |    6 +-
 kexec/crashdump-xen.c              |   34 ++++++++++++++++
 kexec/crashdump.h                  |    3 +-
 kexec/kexec-xen.c                  |   76 ++++++++++++++++++++++++++++++++++++
 kexec/kexec.c                      |   10 ++++-
 kexec/kexec.h                      |    5 ++
 8 files changed, 147 insertions(+), 7 deletions(-)
 create mode 100644 kexec/kexec-xen.c

diff --git a/kexec/Makefile b/kexec/Makefile
index 8a6138d..dc9dab1 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -25,6 +25,7 @@ KEXEC_SRCS_base += kexec/phys_arch.c
 KEXEC_SRCS_base += kexec/kernel_version.c
 KEXEC_SRCS_base += kexec/lzma.c
 KEXEC_SRCS_base += kexec/zlib.c
+KEXEC_SRCS_base += kexec/kexec-xen.c
 
 KEXEC_GENERATED_SRCS += $(PURGATORY_HEX_C)
 
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index f9709fe..46a76f9 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -939,11 +939,28 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	return 0;
 }
 
+int get_crashkernel_region(uint64_t *start, uint64_t *end)
+{
+	int ret;
+
+	if (xen_present())
+		ret = xen_get_crashkernel_region(start, end);
+	else
+		ret = parse_iomem_single("Crash kernel\n", start, end);
+	if (ret < 0)
+		return ret;
+	if (start == end)
+		return -1;
+	return 0;
+}
+
 int is_crashkernel_mem_reserved(void)
 {
 	uint64_t start, end;
+	int rc;
 
-	if (parse_iomem_single("Crash kernel\n", &start, &end) || start == end)
+	rc = get_crashkernel_region(&start, &end);
+	if (rc < 0)
 		return 0;
 
 	crash_reserved_mem.start = start;
diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index dba89f2..2477dee 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -364,9 +364,9 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 	    !(kexec_flags & KEXEC_PRESERVE_CONTEXT)) {
 		uint64_t start, end;
 
-		ret = parse_iomem_single("Crash kernel\n", &start, &end);
-		if (ret != 0) {
-			fprintf(stderr, "parse_iomem_single failed.\n");
+		ret = get_crashkernel_region(&start, &end);
+		if (ret < 0) {
+			fprintf(stderr, "No crash region available.\n");
 			return -1;
 		}
 
diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index 13335a5..434fe66 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -223,3 +223,37 @@ int xen_get_note(int cpu, uint64_t *addr, uint64_t *len)
 
 	return 0;
 }
+
+#ifdef HAVE_LIBXENCTRL
+int xen_get_crashkernel_region(uint64_t *start, uint64_t *end)
+{
+	uint64_t size;
+	xc_interface *xc;
+	int rc = -1;
+
+	xc = xc_interface_open(NULL, NULL, 0);
+	if (!xc) {
+		fprintf(stderr, "failed to open xen control interface.\n");
+		goto out;
+	}
+
+	rc = xc_kexec_get_range(xc, KEXEC_RANGE_MA_CRASH, 0, &size, start);
+	if (rc < 0) {
+		fprintf(stderr, "failed to get crash region from hypervisor.\n");
+		goto out_close;
+	}
+
+	*end = *start + size - 1;
+
+out_close:
+	xc_interface_close(xc);
+
+out:
+	return rc;
+}
+#else
+int xen_get_crashkernel_region(uint64_t *start, uint64_t *end)
+{
+	return -1;
+}
+#endif
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 0f7c2ea..95f1f0c 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -1,6 +1,7 @@
 #ifndef CRASHDUMP_H
 #define CRASHDUMP_H
 
+int get_crashkernel_region(uint64_t *start, uint64_t *end);
 extern int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len);
 extern int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len);
 extern int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len);
@@ -56,9 +57,9 @@ unsigned long crash_architecture(struct crash_elf_info *elf_info);
 unsigned long phys_to_virt(struct crash_elf_info *elf_info,
 			   unsigned long paddr);
 
-int xen_present(void);
 unsigned long xen_architecture(struct crash_elf_info *elf_info);
 int xen_get_nr_phys_cpus(void);
 int xen_get_note(int cpu, uint64_t *addr, uint64_t *len);
+int xen_get_crashkernel_region(uint64_t *start, uint64_t *end);
 
 #endif /* CRASHDUMP_H */
diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c
new file mode 100644
index 0000000..8bc16aa
--- /dev/null
+++ b/kexec/kexec-xen.c
@@ -0,0 +1,76 @@
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include "kexec.h"
+#include "crashdump.h"
+
+#include "config.h"
+
+#ifdef HAVE_LIBXENCTRL
+#include <xenctrl.h>
+
+#include "crashdump.h"
+
+int xen_kexec_load(uint64_t entry,
+		   uint32_t nr_segments, struct kexec_segment *segments,
+		   uint64_t kexec_flags)
+{
+	xc_interface *xch;
+	xc_hypercall_buffer_array_t *array = NULL;
+	uint8_t type;
+	uint8_t arch;
+	xen_kexec_segment_t *xen_segs;
+	int s;
+	int ret = -1;
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch)
+		return -1;
+
+	xen_segs = calloc(nr_segments, sizeof(*xen_segs));
+	if (!xen_segs)
+		goto out;
+
+	array = xc_hypercall_buffer_array_create(xch, nr_segments);
+	if (array == NULL)
+		goto out;
+
+	for (s = 0; s < nr_segments; s++) {
+		DECLARE_HYPERCALL_BUFFER(void, seg_buf);
+
+		seg_buf = xc_hypercall_buffer_array_alloc(xch, array, s,
+							  seg_buf, segments[s].bufsz);
+		if (seg_buf == NULL)
+			goto out;
+		memcpy(seg_buf, segments[s].buf, segments[s].bufsz);
+
+		set_xen_guest_handle(xen_segs[s].buf, seg_buf);
+		xen_segs[s].buf_size = segments[s].bufsz;
+		xen_segs[s].dest_maddr = (uint64_t)segments[s].mem;
+		xen_segs[s].dest_size = segments[s].memsz;
+	}
+
+	type = kexec_flags & KEXEC_TYPE_CRASH;
+	arch = (kexec_flags >> 16) & 0xffff;
+
+	ret = xc_kexec_load(xch, type, arch, entry, nr_segments, xen_segs);
+
+out:
+	xc_hypercall_buffer_array_destroy(xch, array);
+	free(xen_segs);
+	xc_interface_close(xch);
+
+	return ret;
+}
+
+#else /* ! HAVE_LIBXENCTRL */
+
+int xen_kexec_load(uint64_t entry,
+		   uint32_t nr_segments, struct kexec_segment *segments,
+		   uint64_t kexec_flags)
+{
+	return -1;
+}
+
+#endif
diff --git a/kexec/kexec.c b/kexec/kexec.c
index 16c6308..3eab839 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -764,8 +764,14 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
 		info.entry, info.kexec_flags);
 	print_segments(stderr, &info);
 #endif
-	result = kexec_load(
-		info.entry, info.nr_segments, info.segment, info.kexec_flags);
+	if (xen_present())
+		result = xen_kexec_load((uint64_t)info.entry,
+					info.nr_segments, info.segment,
+					info.kexec_flags);
+	else
+		result = kexec_load(info.entry,
+				    info.nr_segments, info.segment,
+				    info.kexec_flags);
 	if (result != 0) {
 		/* The load failed, print some debugging information */
 		fprintf(stderr, "kexec_load failed: %s\n", 
diff --git a/kexec/kexec.h b/kexec/kexec.h
index 94c62c1..4ef8906 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -280,4 +280,9 @@ extern int add_backup_segments(struct kexec_info *info,
 
 char *concat_cmdline(const char *base, const char *append);
 
+int xen_present(void);
+int xen_kexec_load(uint64_t entry,
+		   uint32_t nr_segments, struct kexec_segment *segments,
+		   uint64_t kexec_flags);
+
 #endif /* KEXEC_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 Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP4-0006yY-F4; Thu, 21 Feb 2013 17:57:54 +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 1U8aP2-0006xZ-Q4
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:52 +0000
Received: from [85.158.139.83:40241] by server-9.bemta-5.messagelabs.com id
	BB/17-24440-F1066215; Thu, 21 Feb 2013 17:57:51 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361469468!24447645!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15724 invoked from network); 21 Feb 2013 17:57:49 -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;
	21 Feb 2013 17:57:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8806242"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-CR;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:36 +0000
Message-ID: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

The series adds support for the new hypercall ABI which should be
provided by Xen 4.3.  Images are loaded into Xen directly with no
kernel involvement.

Do not apply until the hypervisor side patches are applied to Xen.

Patch 1 is unrelated but kexec wouldn't work for me without it. Not
sure why I had problems, perhaps a toolstack specific issue?

Patch 2 makes libxc 4.3 mandatory for Xen support.

Patch 3 removes a use of /proc/iomem in favour of libxc.

Patch 4 adds the support for loading an image into Xen.

This series explicitly drops support for older version of libxc/Xen as
supporting kexec on these hypervisors requires kernel support that
will never be available upstream.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP4-0006yl-TF; Thu, 21 Feb 2013 17:57:54 +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 1U8aP2-0006xY-Nh
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:53 +0000
Received: from [85.158.137.99:20251] by server-12.bemta-3.messagelabs.com id
	7D/23-05889-F1066215; Thu, 21 Feb 2013 17:57:51 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361469467!17352487!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM3OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31990 invoked from network); 21 Feb 2013 17:57:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 17:57:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8373187"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-H2;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:40 +0000
Message-ID: <1361469460-18771-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 4/4] kexec/xen: directly load images images into
	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

From: David Vrabel <david.vrabel@citrix.com>

Xen 4.3 has an improvided kexec hypercall ABI that allows images to be
loaded and executed without any kernel involvement.  Use the API
provided by libxc to load images when running in a Xen guest.

Support for loading images via the kexec_load syscall in non-upstream
("classic") Xen kernels is no longer supported.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 kexec/Makefile                     |    1 +
 kexec/arch/i386/crashdump-x86.c    |   19 ++++++++-
 kexec/arch/i386/kexec-x86-common.c |    6 +-
 kexec/crashdump-xen.c              |   34 ++++++++++++++++
 kexec/crashdump.h                  |    3 +-
 kexec/kexec-xen.c                  |   76 ++++++++++++++++++++++++++++++++++++
 kexec/kexec.c                      |   10 ++++-
 kexec/kexec.h                      |    5 ++
 8 files changed, 147 insertions(+), 7 deletions(-)
 create mode 100644 kexec/kexec-xen.c

diff --git a/kexec/Makefile b/kexec/Makefile
index 8a6138d..dc9dab1 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -25,6 +25,7 @@ KEXEC_SRCS_base += kexec/phys_arch.c
 KEXEC_SRCS_base += kexec/kernel_version.c
 KEXEC_SRCS_base += kexec/lzma.c
 KEXEC_SRCS_base += kexec/zlib.c
+KEXEC_SRCS_base += kexec/kexec-xen.c
 
 KEXEC_GENERATED_SRCS += $(PURGATORY_HEX_C)
 
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index f9709fe..46a76f9 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -939,11 +939,28 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	return 0;
 }
 
+int get_crashkernel_region(uint64_t *start, uint64_t *end)
+{
+	int ret;
+
+	if (xen_present())
+		ret = xen_get_crashkernel_region(start, end);
+	else
+		ret = parse_iomem_single("Crash kernel\n", start, end);
+	if (ret < 0)
+		return ret;
+	if (start == end)
+		return -1;
+	return 0;
+}
+
 int is_crashkernel_mem_reserved(void)
 {
 	uint64_t start, end;
+	int rc;
 
-	if (parse_iomem_single("Crash kernel\n", &start, &end) || start == end)
+	rc = get_crashkernel_region(&start, &end);
+	if (rc < 0)
 		return 0;
 
 	crash_reserved_mem.start = start;
diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index dba89f2..2477dee 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -364,9 +364,9 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 	    !(kexec_flags & KEXEC_PRESERVE_CONTEXT)) {
 		uint64_t start, end;
 
-		ret = parse_iomem_single("Crash kernel\n", &start, &end);
-		if (ret != 0) {
-			fprintf(stderr, "parse_iomem_single failed.\n");
+		ret = get_crashkernel_region(&start, &end);
+		if (ret < 0) {
+			fprintf(stderr, "No crash region available.\n");
 			return -1;
 		}
 
diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index 13335a5..434fe66 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -223,3 +223,37 @@ int xen_get_note(int cpu, uint64_t *addr, uint64_t *len)
 
 	return 0;
 }
+
+#ifdef HAVE_LIBXENCTRL
+int xen_get_crashkernel_region(uint64_t *start, uint64_t *end)
+{
+	uint64_t size;
+	xc_interface *xc;
+	int rc = -1;
+
+	xc = xc_interface_open(NULL, NULL, 0);
+	if (!xc) {
+		fprintf(stderr, "failed to open xen control interface.\n");
+		goto out;
+	}
+
+	rc = xc_kexec_get_range(xc, KEXEC_RANGE_MA_CRASH, 0, &size, start);
+	if (rc < 0) {
+		fprintf(stderr, "failed to get crash region from hypervisor.\n");
+		goto out_close;
+	}
+
+	*end = *start + size - 1;
+
+out_close:
+	xc_interface_close(xc);
+
+out:
+	return rc;
+}
+#else
+int xen_get_crashkernel_region(uint64_t *start, uint64_t *end)
+{
+	return -1;
+}
+#endif
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 0f7c2ea..95f1f0c 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -1,6 +1,7 @@
 #ifndef CRASHDUMP_H
 #define CRASHDUMP_H
 
+int get_crashkernel_region(uint64_t *start, uint64_t *end);
 extern int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len);
 extern int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len);
 extern int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len);
@@ -56,9 +57,9 @@ unsigned long crash_architecture(struct crash_elf_info *elf_info);
 unsigned long phys_to_virt(struct crash_elf_info *elf_info,
 			   unsigned long paddr);
 
-int xen_present(void);
 unsigned long xen_architecture(struct crash_elf_info *elf_info);
 int xen_get_nr_phys_cpus(void);
 int xen_get_note(int cpu, uint64_t *addr, uint64_t *len);
+int xen_get_crashkernel_region(uint64_t *start, uint64_t *end);
 
 #endif /* CRASHDUMP_H */
diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c
new file mode 100644
index 0000000..8bc16aa
--- /dev/null
+++ b/kexec/kexec-xen.c
@@ -0,0 +1,76 @@
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include "kexec.h"
+#include "crashdump.h"
+
+#include "config.h"
+
+#ifdef HAVE_LIBXENCTRL
+#include <xenctrl.h>
+
+#include "crashdump.h"
+
+int xen_kexec_load(uint64_t entry,
+		   uint32_t nr_segments, struct kexec_segment *segments,
+		   uint64_t kexec_flags)
+{
+	xc_interface *xch;
+	xc_hypercall_buffer_array_t *array = NULL;
+	uint8_t type;
+	uint8_t arch;
+	xen_kexec_segment_t *xen_segs;
+	int s;
+	int ret = -1;
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch)
+		return -1;
+
+	xen_segs = calloc(nr_segments, sizeof(*xen_segs));
+	if (!xen_segs)
+		goto out;
+
+	array = xc_hypercall_buffer_array_create(xch, nr_segments);
+	if (array == NULL)
+		goto out;
+
+	for (s = 0; s < nr_segments; s++) {
+		DECLARE_HYPERCALL_BUFFER(void, seg_buf);
+
+		seg_buf = xc_hypercall_buffer_array_alloc(xch, array, s,
+							  seg_buf, segments[s].bufsz);
+		if (seg_buf == NULL)
+			goto out;
+		memcpy(seg_buf, segments[s].buf, segments[s].bufsz);
+
+		set_xen_guest_handle(xen_segs[s].buf, seg_buf);
+		xen_segs[s].buf_size = segments[s].bufsz;
+		xen_segs[s].dest_maddr = (uint64_t)segments[s].mem;
+		xen_segs[s].dest_size = segments[s].memsz;
+	}
+
+	type = kexec_flags & KEXEC_TYPE_CRASH;
+	arch = (kexec_flags >> 16) & 0xffff;
+
+	ret = xc_kexec_load(xch, type, arch, entry, nr_segments, xen_segs);
+
+out:
+	xc_hypercall_buffer_array_destroy(xch, array);
+	free(xen_segs);
+	xc_interface_close(xch);
+
+	return ret;
+}
+
+#else /* ! HAVE_LIBXENCTRL */
+
+int xen_kexec_load(uint64_t entry,
+		   uint32_t nr_segments, struct kexec_segment *segments,
+		   uint64_t kexec_flags)
+{
+	return -1;
+}
+
+#endif
diff --git a/kexec/kexec.c b/kexec/kexec.c
index 16c6308..3eab839 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -764,8 +764,14 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
 		info.entry, info.kexec_flags);
 	print_segments(stderr, &info);
 #endif
-	result = kexec_load(
-		info.entry, info.nr_segments, info.segment, info.kexec_flags);
+	if (xen_present())
+		result = xen_kexec_load((uint64_t)info.entry,
+					info.nr_segments, info.segment,
+					info.kexec_flags);
+	else
+		result = kexec_load(info.entry,
+				    info.nr_segments, info.segment,
+				    info.kexec_flags);
 	if (result != 0) {
 		/* The load failed, print some debugging information */
 		fprintf(stderr, "kexec_load failed: %s\n", 
diff --git a/kexec/kexec.h b/kexec/kexec.h
index 94c62c1..4ef8906 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -280,4 +280,9 @@ extern int add_backup_segments(struct kexec_info *info,
 
 char *concat_cmdline(const char *base, const char *append);
 
+int xen_present(void);
+int xen_kexec_load(uint64_t entry,
+		   uint32_t nr_segments, struct kexec_segment *segments,
+		   uint64_t kexec_flags);
+
 #endif /* KEXEC_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 Thu Feb 21 17:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 17: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 1U8aP4-0006yY-F4; Thu, 21 Feb 2013 17:57:54 +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 1U8aP2-0006xZ-Q4
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 17:57:52 +0000
Received: from [85.158.139.83:40241] by server-9.bemta-5.messagelabs.com id
	BB/17-24440-F1066215; Thu, 21 Feb 2013 17:57:51 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361469468!24447645!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDAzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15724 invoked from network); 21 Feb 2013 17:57:49 -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;
	21 Feb 2013 17:57:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; 
   d="scan'208";a="8806242"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	21 Feb 2013 17:57:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 21 Feb 2013 12:57:46 -0500
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 1U8aOw-0001J8-CR;
	Thu, 21 Feb 2013 17:57:46 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 21 Feb 2013 17:57:36 +0000
Message-ID: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

The series adds support for the new hypercall ABI which should be
provided by Xen 4.3.  Images are loaded into Xen directly with no
kernel involvement.

Do not apply until the hypervisor side patches are applied to Xen.

Patch 1 is unrelated but kexec wouldn't work for me without it. Not
sure why I had problems, perhaps a toolstack specific issue?

Patch 2 makes libxc 4.3 mandatory for Xen support.

Patch 3 removes a use of /proc/iomem in favour of libxc.

Patch 4 adds the support for loading an image into Xen.

This series explicitly drops support for older version of libxc/Xen as
supporting kexec on these hypervisors requires kernel support that
will never be available upstream.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 18:06:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18:06: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 1U8aWx-0007vY-V7; Thu, 21 Feb 2013 18:06:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8aWv-0007vT-Cz
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:06:01 +0000
Received: from [85.158.139.211:58873] by server-4.bemta-5.messagelabs.com id
	A9/E0-29496-80266215; Thu, 21 Feb 2013 18:06:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361469959!17135701!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32207 invoked from network); 21 Feb 2013 18:06:00 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-206.messagelabs.com with SMTP;
	21 Feb 2013 18:06:00 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 67874C56195;
	Thu, 21 Feb 2013 18:05:48 +0000 (GMT)
Date: Thu, 21 Feb 2013 18:05:46 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <E956941E2B3742BB71DC0702@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

Thanks. I take it the libxl patches can now go in.

Alex

--On 21 February 2013 12:42:43 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I have applied this series
>
> On Wed, 20 Feb 2013, Alex Bligh wrote:
>> This patch series consists of 2	parts:
>> * 11 patches to	libxl
>> * 6 patches to QEMU
>>
>> The 11 patches to libxl are unchanged and I am not resending
>> them this time.
>>
>> The 6 patches to QEMU are unchanged since version 2 of the patch.
>>
>> These patches enable live-migrate on HVM using the upstream qemu-xen
>> device model under Xen 4.2. Currently this is unimplemented. In	the
>> main they are backports of patches in xen-unstable, thought the
>> QEMU side in particular needed some fiddling.
>>
>> I would	suggest these patches should be included in 4.2.2.
>>
>> I have made minor changes per Stefano Stabellini's requests and
>> these patches are compile-tested only and sent for comment. The
>> changes are:
>> * TB invalidation patch backported
>> * Patch 3 (now 4) now applies cleanly, so no need to break whitespace
>> * Comment added to patch 4 (now 5)
>> * Comment added to patch 5 (now 6)
>>
>> I did not redo the VRAM patch (patch 5, now patch 6) for the reasons
>> set out separately, but added a comment to explain the problem instead.
>>
>> Alex Bligh (6):
>>   QMP, Introduce xen-set-global-dirty-log command.
>>   xen: Introduce xen_modified_memory.
>>   cpu_physical_memory_write_rom() needs to do TB invalidates
>>   exec: Introduce helper to set dirty flags.
>>   exec, memory: Call to xen_modified_memory.
>>   xen: Set the vram dirty when an error occurs.
>>
>>  exec.c           |   49
>>  +++++++++++++++++++++---------------------------- hw/xen.h         |
>>  1 +
>>  memory.c         |    4 ++++
>>  qapi-schema.json |   13 +++++++++++++
>>  qmp-commands.hx  |   24 ++++++++++++++++++++++++
>>  xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
>>  xen-stub.c       |    9 +++++++++
>>  7 files changed, 117 insertions(+), 30 deletions(-)
>>
>
>



-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 18:06:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18:06: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 1U8aWx-0007vY-V7; Thu, 21 Feb 2013 18:06:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8aWv-0007vT-Cz
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:06:01 +0000
Received: from [85.158.139.211:58873] by server-4.bemta-5.messagelabs.com id
	A9/E0-29496-80266215; Thu, 21 Feb 2013 18:06:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361469959!17135701!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32207 invoked from network); 21 Feb 2013 18:06:00 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-206.messagelabs.com with SMTP;
	21 Feb 2013 18:06:00 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 67874C56195;
	Thu, 21 Feb 2013 18:05:48 +0000 (GMT)
Date: Thu, 21 Feb 2013 18:05:46 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <E956941E2B3742BB71DC0702@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

Thanks. I take it the libxl patches can now go in.

Alex

--On 21 February 2013 12:42:43 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I have applied this series
>
> On Wed, 20 Feb 2013, Alex Bligh wrote:
>> This patch series consists of 2	parts:
>> * 11 patches to	libxl
>> * 6 patches to QEMU
>>
>> The 11 patches to libxl are unchanged and I am not resending
>> them this time.
>>
>> The 6 patches to QEMU are unchanged since version 2 of the patch.
>>
>> These patches enable live-migrate on HVM using the upstream qemu-xen
>> device model under Xen 4.2. Currently this is unimplemented. In	the
>> main they are backports of patches in xen-unstable, thought the
>> QEMU side in particular needed some fiddling.
>>
>> I would	suggest these patches should be included in 4.2.2.
>>
>> I have made minor changes per Stefano Stabellini's requests and
>> these patches are compile-tested only and sent for comment. The
>> changes are:
>> * TB invalidation patch backported
>> * Patch 3 (now 4) now applies cleanly, so no need to break whitespace
>> * Comment added to patch 4 (now 5)
>> * Comment added to patch 5 (now 6)
>>
>> I did not redo the VRAM patch (patch 5, now patch 6) for the reasons
>> set out separately, but added a comment to explain the problem instead.
>>
>> Alex Bligh (6):
>>   QMP, Introduce xen-set-global-dirty-log command.
>>   xen: Introduce xen_modified_memory.
>>   cpu_physical_memory_write_rom() needs to do TB invalidates
>>   exec: Introduce helper to set dirty flags.
>>   exec, memory: Call to xen_modified_memory.
>>   xen: Set the vram dirty when an error occurs.
>>
>>  exec.c           |   49
>>  +++++++++++++++++++++---------------------------- hw/xen.h         |
>>  1 +
>>  memory.c         |    4 ++++
>>  qapi-schema.json |   13 +++++++++++++
>>  qmp-commands.hx  |   24 ++++++++++++++++++++++++
>>  xen-all.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--
>>  xen-stub.c       |    9 +++++++++
>>  7 files changed, 117 insertions(+), 30 deletions(-)
>>
>
>



-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 18:27:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18: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 1U8arR-0008Ke-1C; Thu, 21 Feb 2013 18:27:13 +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 1U8arP-0008KW-UP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:27:12 +0000
Received: from [193.109.254.147:57058] by server-3.bemta-14.messagelabs.com id
	F0/08-22141-FF666215; Thu, 21 Feb 2013 18:27:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361471229!2426413!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10736 invoked from network); 21 Feb 2013 18:27:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 18:27:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8arJ-00086d-PK; Thu, 21 Feb 2013 18:27:05 +0000
Date: Thu, 21 Feb 2013 18:27:05 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Message-ID: <20130221182705.GA31110@ocelot.phlegethon.org>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
	<A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
	<20130221174253.GG24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221174253.GG24051@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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 17:42 +0000 on 21 Feb (1361468573), Tim Deegan wrote:
> At 09:58 -0500 on 21 Feb (1361440689), Andres Lagar-Cavilla wrote:
> > > The remaining locked lookups are in sh_page_fault() (in a path that's
> > > almost always already serializing on the paging lock), and in
> > > emulate_map_dest() (which can probably be updated to use
> > > get_page_from_gfn()).
> > That is absolutely the case. Here is a rough patch:
> 
> Applied, thanks.  I've taken your S-o-b below to apply to this patch
> too; hope that's OK. 

Jan, this second patch isn't necessary for 4.2 -- the performance
regression it fixes isn't even measurable on 4-vcpu compile-tests.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 18:27:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18: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 1U8arR-0008Ke-1C; Thu, 21 Feb 2013 18:27:13 +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 1U8arP-0008KW-UP
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:27:12 +0000
Received: from [193.109.254.147:57058] by server-3.bemta-14.messagelabs.com id
	F0/08-22141-FF666215; Thu, 21 Feb 2013 18:27:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361471229!2426413!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10736 invoked from network); 21 Feb 2013 18:27:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 18:27:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8arJ-00086d-PK; Thu, 21 Feb 2013 18:27:05 +0000
Date: Thu, 21 Feb 2013 18:27:05 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Message-ID: <20130221182705.GA31110@ocelot.phlegethon.org>
References: <mailman.24350.1361456629.1399.xen-devel@lists.xen.org>
	<A978846D-55E7-4CDE-9D47-B02D80A1B4C3@gridcentric.ca>
	<20130221174253.GG24051@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221174253.GG24051@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] x86/mm: Take the p2m lock even 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 17:42 +0000 on 21 Feb (1361468573), Tim Deegan wrote:
> At 09:58 -0500 on 21 Feb (1361440689), Andres Lagar-Cavilla wrote:
> > > The remaining locked lookups are in sh_page_fault() (in a path that's
> > > almost always already serializing on the paging lock), and in
> > > emulate_map_dest() (which can probably be updated to use
> > > get_page_from_gfn()).
> > That is absolutely the case. Here is a rough patch:
> 
> Applied, thanks.  I've taken your S-o-b below to apply to this patch
> too; hope that's OK. 

Jan, this second patch isn't necessary for 4.2 -- the performance
regression it fixes isn't even measurable on 4-vcpu compile-tests.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 18:41:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18:41: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 1U8b4z-0000ds-1a; Thu, 21 Feb 2013 18:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1U8b4w-0000dn-W2
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:41:11 +0000
Received: from [85.158.139.83:13628] by server-12.bemta-5.messagelabs.com id
	27/F1-20195-64A66215; Thu, 21 Feb 2013 18:41:10 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361472067!28391962!1
X-Originating-IP: [209.85.223.174]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23139 invoked from network); 21 Feb 2013 18:41:08 -0000
Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com)
	(209.85.223.174)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 18:41:08 -0000
Received: by mail-ie0-f174.google.com with SMTP id k10so11723101iea.33
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 10:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=9jaQTfOSqWjjCBFOcptRzlrul9S2nRZQWNxA+aRqKnI=;
	b=l8IB3ECbfKMgjkbBN94JOSoCn4hMgzDwKoBbqozW/hfe0XIRU7IcJ31xBM6Dgz41rm
	kw8Y83+DOeZhHqHWO8OBAv63m11ncMVj8NpZXdKIA5zd20WA16Hj+MxICE6L2XzUwRLM
	R6Bgw8AfX8pvjl60hs7oUhgSYr0Oe4p/f1o3uK2n7ENorBFkrQc1RKt+kV7kHH+83YZG
	sDrJ1WS3jpm5f0ckwguoYZSZ3bRNrOVVRaXCRumdIMw4nZwORhaSrPWIuX2O1LmPdG/l
	lKK4ltelnsmK6Z4BFnIZSiujfZdEOjbse7fTUllT1upcuwphXoN1wB9XpKVL6uEdHLIO
	eCtg==
MIME-Version: 1.0
X-Received: by 10.50.196.130 with SMTP id im2mr13119556igc.90.1361472066936;
	Thu, 21 Feb 2013 10:41:06 -0800 (PST)
Received: by 10.42.41.5 with HTTP; Thu, 21 Feb 2013 10:41:06 -0800 (PST)
In-Reply-To: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
References: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
Date: Thu, 21 Feb 2013 11:41:06 -0700
Message-ID: <CAHyyzzRwY-u6DL94Oct-w+vOt+7T7vvNHV+eLgaH9kvt5cwf5Q@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: disable docs for QEMU 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="===============0210538234650776389=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0210538234650776389==
Content-Type: multipart/alternative; boundary=14dae9341071ebde7904d6406ac9

--14dae9341071ebde7904d6406ac9
Content-Type: text/plain; charset=ISO-8859-1

This patch work perfectly . Nice work around

On Thu, Feb 21, 2013 at 10:10 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
> disable it.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/Makefile |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 2ca43b9..bea1489 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -197,6 +197,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
>                 --bindir=$(LIBEXEC) \
>                 --datadir=$(SHAREDIR)/qemu-xen \
>                 --disable-kvm \
> +               --disable-docs \
>                 --python=$(PYTHON) \
>                 $(IOEMU_CONFIGURE_CROSS); \
>         $(MAKE) all
> --
> 1.7.10.4
>
>

--14dae9341071ebde7904d6406ac9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch work perfectly . Nice work around<br><br><div class=3D"gmail_quo=
te">On Thu, Feb 21, 2013 at 10:10 AM, Wei Liu <span dir=3D"ltr">&lt;<a href=
=3D"mailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citrix.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Texinfo 5 breaks QEMU builds. As we do not n=
eed documents from QEMU, just<br>
disable it.<br>
<br>
Signed-off-by: Wei Liu &lt;<a href=3D"mailto:wei.liu2@citrix.com">wei.liu2@=
citrix.com</a>&gt;<br>
---<br>
=A0tools/Makefile | =A0 =A01 +<br>
=A01 file changed, 1 insertion(+)<br>
<br>
diff --git a/tools/Makefile b/tools/Makefile<br>
index 2ca43b9..bea1489 100644<br>
--- a/tools/Makefile<br>
+++ b/tools/Makefile<br>
@@ -197,6 +197,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --bindir=3D$(LIBEXEC) \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --datadir=3D$(SHAREDIR)/qemu-xen \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --disable-kvm \<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 --disable-docs \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --python=3D$(PYTHON) \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $(IOEMU_CONFIGURE_CROSS); \<br>
=A0 =A0 =A0 =A0 $(MAKE) all<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
1.7.10.4<br>
<br>
</font></span></blockquote></div><br>

--14dae9341071ebde7904d6406ac9--


--===============0210538234650776389==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0210538234650776389==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 18:41:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18:41: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 1U8b4z-0000ds-1a; Thu, 21 Feb 2013 18:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1U8b4w-0000dn-W2
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:41:11 +0000
Received: from [85.158.139.83:13628] by server-12.bemta-5.messagelabs.com id
	27/F1-20195-64A66215; Thu, 21 Feb 2013 18:41:10 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361472067!28391962!1
X-Originating-IP: [209.85.223.174]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23139 invoked from network); 21 Feb 2013 18:41:08 -0000
Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com)
	(209.85.223.174)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 18:41:08 -0000
Received: by mail-ie0-f174.google.com with SMTP id k10so11723101iea.33
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 10:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=9jaQTfOSqWjjCBFOcptRzlrul9S2nRZQWNxA+aRqKnI=;
	b=l8IB3ECbfKMgjkbBN94JOSoCn4hMgzDwKoBbqozW/hfe0XIRU7IcJ31xBM6Dgz41rm
	kw8Y83+DOeZhHqHWO8OBAv63m11ncMVj8NpZXdKIA5zd20WA16Hj+MxICE6L2XzUwRLM
	R6Bgw8AfX8pvjl60hs7oUhgSYr0Oe4p/f1o3uK2n7ENorBFkrQc1RKt+kV7kHH+83YZG
	sDrJ1WS3jpm5f0ckwguoYZSZ3bRNrOVVRaXCRumdIMw4nZwORhaSrPWIuX2O1LmPdG/l
	lKK4ltelnsmK6Z4BFnIZSiujfZdEOjbse7fTUllT1upcuwphXoN1wB9XpKVL6uEdHLIO
	eCtg==
MIME-Version: 1.0
X-Received: by 10.50.196.130 with SMTP id im2mr13119556igc.90.1361472066936;
	Thu, 21 Feb 2013 10:41:06 -0800 (PST)
Received: by 10.42.41.5 with HTTP; Thu, 21 Feb 2013 10:41:06 -0800 (PST)
In-Reply-To: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
References: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
Date: Thu, 21 Feb 2013 11:41:06 -0700
Message-ID: <CAHyyzzRwY-u6DL94Oct-w+vOt+7T7vvNHV+eLgaH9kvt5cwf5Q@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: disable docs for QEMU 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="===============0210538234650776389=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0210538234650776389==
Content-Type: multipart/alternative; boundary=14dae9341071ebde7904d6406ac9

--14dae9341071ebde7904d6406ac9
Content-Type: text/plain; charset=ISO-8859-1

This patch work perfectly . Nice work around

On Thu, Feb 21, 2013 at 10:10 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
> disable it.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  tools/Makefile |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 2ca43b9..bea1489 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -197,6 +197,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
>                 --bindir=$(LIBEXEC) \
>                 --datadir=$(SHAREDIR)/qemu-xen \
>                 --disable-kvm \
> +               --disable-docs \
>                 --python=$(PYTHON) \
>                 $(IOEMU_CONFIGURE_CROSS); \
>         $(MAKE) all
> --
> 1.7.10.4
>
>

--14dae9341071ebde7904d6406ac9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch work perfectly . Nice work around<br><br><div class=3D"gmail_quo=
te">On Thu, Feb 21, 2013 at 10:10 AM, Wei Liu <span dir=3D"ltr">&lt;<a href=
=3D"mailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citrix.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Texinfo 5 breaks QEMU builds. As we do not n=
eed documents from QEMU, just<br>
disable it.<br>
<br>
Signed-off-by: Wei Liu &lt;<a href=3D"mailto:wei.liu2@citrix.com">wei.liu2@=
citrix.com</a>&gt;<br>
---<br>
=A0tools/Makefile | =A0 =A01 +<br>
=A01 file changed, 1 insertion(+)<br>
<br>
diff --git a/tools/Makefile b/tools/Makefile<br>
index 2ca43b9..bea1489 100644<br>
--- a/tools/Makefile<br>
+++ b/tools/Makefile<br>
@@ -197,6 +197,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --bindir=3D$(LIBEXEC) \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --datadir=3D$(SHAREDIR)/qemu-xen \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --disable-kvm \<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 --disable-docs \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --python=3D$(PYTHON) \<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 $(IOEMU_CONFIGURE_CROSS); \<br>
=A0 =A0 =A0 =A0 $(MAKE) all<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
1.7.10.4<br>
<br>
</font></span></blockquote></div><br>

--14dae9341071ebde7904d6406ac9--


--===============0210538234650776389==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0210538234650776389==--


From xen-devel-bounces@lists.xen.org Thu Feb 21 18:43:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18:43: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 1U8b7H-0000n7-N4; Thu, 21 Feb 2013 18:43:35 +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 1U8b7G-0000my-8f
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:43:34 +0000
Received: from [85.158.139.83:24381] by server-7.bemta-5.messagelabs.com id
	0D/1D-11121-5DA66215; Thu, 21 Feb 2013 18:43:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361472212!24398737!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2965 invoked from network); 21 Feb 2013 18:43:32 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 18:43:32 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so7996225wic.11
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 10:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+5CNma0dBLpbIpkLdNakjzN5mFOWr/8wONSRAnPlMGc=;
	b=BK8hYDiDOfDI5D+gva1NU3XabWw5XdL+QqRotzot/sTgmHM6ZL1jeyUF0+OxkVh9rd
	9wVt1YsmX+h8ML3XomD2tARuuk8S6hsDWEOFed4ICydTTPy3LmIeFAQCO1hqk+IYja2G
	hDHS6bY30Ptb0IMejeDDpHuJtoIBZqc2RNjYfiB7IrvR58qmrX9loPmKAFiAMKbUXeei
	mPOIY9wBby8OCH9JWt6OpU5xPs0v/pPtDr5y1MxpYhm0KMlTcUWnl/5ACU1xVg6jqke6
	PnvxWRp6w7SLHiXkwkAl0n4q0vwclj8VucbckXE2UpWFbhJTzMipB8ZkaWbdo/woIv7j
	6nDA==
X-Received: by 10.194.172.197 with SMTP id be5mr43740684wjc.20.1361472212185; 
	Thu, 21 Feb 2013 10:43:32 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id fx5sm10913wib.11.2013.02.21.10.43.28
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 10:43:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 18:43:23 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD4C1B4B.4C72B%keir.xen@gmail.com>
Thread-Topic: [PATCH XEN] xen: event channel arrays are xen_ulong_t and not
	unsigned long
Thread-Index: Ac4QY1OObYhZzvCVl0eii+cpuFzYLg==
In-Reply-To: <1361466961.26546.85.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 17:16, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> On ARM we want these to be the same size on 32- and 64-bit.
>> 
>> This is an ABI change on ARM. X86 does not change.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Jan Beulich <JBeulich@suse.com>
>> Cc: Keir (Xen.org) <keir@xen.org>
> 
> Are you guys (un)happy with this change from the Xen & x86 side?

Fine by me.

 -- Keir

>> Cc: Tim Deegan <tim@xen.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: xen-devel@lists.xen.org
>> ---
>>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>>  xen/include/public/xen.h              |    8 ++++----
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/tools/include/xen-foreign/mkheader.py
>> b/tools/include/xen-foreign/mkheader.py
>> index d189b07..57681fa 100644
>> --- a/tools/include/xen-foreign/mkheader.py
>> +++ b/tools/include/xen-foreign/mkheader.py
>> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint64_t",
>> +    "xen_ulong_t"   : "uint64_t",
>>  };
>> +header["arm"] = """
>> +#define __arm___ARM32 1
>> +""";
>>  
>>  # x86_32
>>  inttypes["x86_32"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint32_t",
>> +    "xen_ulong_t"   : "uint32_t",
>>  };
>>  header["x86_32"] = """
>>  #define __i386___X86_32 1
>> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>>      "unsigned long" : "__align8__ uint64_t",
>>      "long"          : "__align8__ uint64_t",
>>      "xen_pfn_t"     : "__align8__ uint64_t",
>> +    "xen_ulong_t"   : "__align8__ uint64_t",
>>  };
>>  header["x86_64"] = """
>>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 5593066..99c8212 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>>   * Event channel endpoints per domain:
>>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>>   */
>> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) *
>> 64)
>> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>>  
>>  struct vcpu_time_info {
>>      /*
>> @@ -613,7 +613,7 @@ struct vcpu_info {
>>       */
>>      uint8_t evtchn_upcall_pending;
>>      uint8_t evtchn_upcall_mask;
>> -    unsigned long evtchn_pending_sel;
>> +    xen_ulong_t evtchn_pending_sel;
>>      struct arch_vcpu_info arch;
>>      struct vcpu_time_info time;
>>  }; /* 64 bytes (x86) */
>> @@ -663,8 +663,8 @@ struct shared_info {
>>       * per-vcpu selector word to be set. Each bit in the selector covers a
>>       * 'C long' in the PENDING bitfield array.
>>       */
>> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
>> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
>> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
>> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>>  
>>      /*
>>       * Wallclock time: updated only by control software. Guests should base
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 18:43:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 18:43: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 1U8b7H-0000n7-N4; Thu, 21 Feb 2013 18:43:35 +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 1U8b7G-0000my-8f
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 18:43:34 +0000
Received: from [85.158.139.83:24381] by server-7.bemta-5.messagelabs.com id
	0D/1D-11121-5DA66215; Thu, 21 Feb 2013 18:43:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361472212!24398737!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2965 invoked from network); 21 Feb 2013 18:43:32 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Feb 2013 18:43:32 -0000
Received: by mail-wi0-f178.google.com with SMTP id o1so7996225wic.11
	for <xen-devel@lists.xen.org>; Thu, 21 Feb 2013 10:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+5CNma0dBLpbIpkLdNakjzN5mFOWr/8wONSRAnPlMGc=;
	b=BK8hYDiDOfDI5D+gva1NU3XabWw5XdL+QqRotzot/sTgmHM6ZL1jeyUF0+OxkVh9rd
	9wVt1YsmX+h8ML3XomD2tARuuk8S6hsDWEOFed4ICydTTPy3LmIeFAQCO1hqk+IYja2G
	hDHS6bY30Ptb0IMejeDDpHuJtoIBZqc2RNjYfiB7IrvR58qmrX9loPmKAFiAMKbUXeei
	mPOIY9wBby8OCH9JWt6OpU5xPs0v/pPtDr5y1MxpYhm0KMlTcUWnl/5ACU1xVg6jqke6
	PnvxWRp6w7SLHiXkwkAl0n4q0vwclj8VucbckXE2UpWFbhJTzMipB8ZkaWbdo/woIv7j
	6nDA==
X-Received: by 10.194.172.197 with SMTP id be5mr43740684wjc.20.1361472212185; 
	Thu, 21 Feb 2013 10:43:32 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id fx5sm10913wib.11.2013.02.21.10.43.28
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 21 Feb 2013 10:43:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 21 Feb 2013 18:43:23 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD4C1B4B.4C72B%keir.xen@gmail.com>
Thread-Topic: [PATCH XEN] xen: event channel arrays are xen_ulong_t and not
	unsigned long
Thread-Index: Ac4QY1OObYhZzvCVl0eii+cpuFzYLg==
In-Reply-To: <1361466961.26546.85.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 17:16, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> On ARM we want these to be the same size on 32- and 64-bit.
>> 
>> This is an ABI change on ARM. X86 does not change.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Jan Beulich <JBeulich@suse.com>
>> Cc: Keir (Xen.org) <keir@xen.org>
> 
> Are you guys (un)happy with this change from the Xen & x86 side?

Fine by me.

 -- Keir

>> Cc: Tim Deegan <tim@xen.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: xen-devel@lists.xen.org
>> ---
>>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>>  xen/include/public/xen.h              |    8 ++++----
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/tools/include/xen-foreign/mkheader.py
>> b/tools/include/xen-foreign/mkheader.py
>> index d189b07..57681fa 100644
>> --- a/tools/include/xen-foreign/mkheader.py
>> +++ b/tools/include/xen-foreign/mkheader.py
>> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint64_t",
>> +    "xen_ulong_t"   : "uint64_t",
>>  };
>> +header["arm"] = """
>> +#define __arm___ARM32 1
>> +""";
>>  
>>  # x86_32
>>  inttypes["x86_32"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint32_t",
>> +    "xen_ulong_t"   : "uint32_t",
>>  };
>>  header["x86_32"] = """
>>  #define __i386___X86_32 1
>> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>>      "unsigned long" : "__align8__ uint64_t",
>>      "long"          : "__align8__ uint64_t",
>>      "xen_pfn_t"     : "__align8__ uint64_t",
>> +    "xen_ulong_t"   : "__align8__ uint64_t",
>>  };
>>  header["x86_64"] = """
>>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 5593066..99c8212 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>>   * Event channel endpoints per domain:
>>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>>   */
>> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) *
>> 64)
>> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>>  
>>  struct vcpu_time_info {
>>      /*
>> @@ -613,7 +613,7 @@ struct vcpu_info {
>>       */
>>      uint8_t evtchn_upcall_pending;
>>      uint8_t evtchn_upcall_mask;
>> -    unsigned long evtchn_pending_sel;
>> +    xen_ulong_t evtchn_pending_sel;
>>      struct arch_vcpu_info arch;
>>      struct vcpu_time_info time;
>>  }; /* 64 bytes (x86) */
>> @@ -663,8 +663,8 @@ struct shared_info {
>>       * per-vcpu selector word to be set. Each bit in the selector covers a
>>       * 'C long' in the PENDING bitfield array.
>>       */
>> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
>> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
>> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
>> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>>  
>>      /*
>>       * Wallclock time: updated only by control software. Guests should base
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 19:20:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 19:20: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 1U8bgk-0001u4-Cv; Thu, 21 Feb 2013 19:20:14 +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 1U8bgi-0001tu-IW
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 19:20:12 +0000
Received: from [85.158.137.99:48238] by server-10.bemta-3.messagelabs.com id
	3D/A7-10609-B6376215; Thu, 21 Feb 2013 19:20:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361474408!12107144!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTAxNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28794 invoked from network); 21 Feb 2013 19:20:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 19:20:09 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LJK68F029459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 19:20:07 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
	r1LJK6ac001059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 19:20:06 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
	r1LJK5E0002354; Thu, 21 Feb 2013 13:20:05 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 11:20:05 -0800
Date: Thu, 21 Feb 2013 11:20:04 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130221112004.05fdb740@mantra.us.oracle.com>
In-Reply-To: <20130221091001.GD24051@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@ocelot.phlegethon.org>
	<20130220190519.5fb537b1@mantra.us.oracle.com>
	<20130221091001.GD24051@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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 Thu, 21 Feb 2013 09:10:01 +0000
Tim Deegan <tim@xen.org> wrote:

> At 19:05 -0800 on 20 Feb (1361387119), Mukesh Rathor wrote:
> > On Wed, 20 Feb 2013 09:58:28 +0000
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > > > On Thu, 24 Jan 2013 16:31:22 +0000
> > > > Tim Deegan <tim@xen.org> wrote:
> > > > 
> > > > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > > > +
> > > > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > > > +        {
> > > > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > > > +                pv_cpuid(regs);
> > > > > > +
> > > > > > +                /* Because we are setting CR4.OSFXSR to 0,
> > > > > > we need to disable
> > > > > > +                 * this because, during boot, user process
> > > > > > "init" (which doesn't
> > > > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > > > cause #UD. For now 
> > > > > > +                 * disable this. HVM doesn't allow setting
> > > > > > of CR4.OSFXSR.
> > > > > > +                 * fixme: this and also look at
> > > > > > CR4.OSXSAVE */ +
> > > > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > > > 
> > > > > Shouldn't this be gated on which leaf the guest asked for?
> > > > 
> > > > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > > > work. The user process "init" running nash is executing pxor
> > > > %xmm0, %xmm0 and taking #UD. Strangely, it works with EAX==0,
> > > > meaning if I clear the bit for EAX==0, changing the intel
> > > > string "ineI".  This user process doesn't do cpuid, so it must
> > > > be affected by it some other way.
> > > > 
> > > > Pretty hard to debug since it's in nash user code from ramdisk
> > > > and I am not able to set breakpoint or put printf's easily to
> > > > figure why clearing bit for EAX==0 makes it work, or what's
> > > > going on for PV and HVM guest. CR0.EM is 0, so UD is coming
> > > > from CR4.OSFXSR==0. Reading the SDMs to learn OSFXSR stuff
> > > > better....
> > > 
> > > Perhaps you need to clear the FXSR feature bit in leaf
> > > 0x80000001:EDX as well?
> > 
> > That appears to be AMD only.
> 
> It still needs to be handled. :)   You are testing this stuff on AMD
> as well, right?

Right, in pvh_svm.c when its ported. I had talked to someone from AMD
at xen summit who said he'd port it to AMD as soon as phase I patch
is checked in. It shouldn't be too hard to do that. I estimate a week
or two if I was to do SVM changes. 

Right now my hurdle working on Version 2 of the patch is all this SSE
stuff that I'm trying to figure out. I was hoping to punt it to phase
II by turning off whatever bits in CPUID, but nothing works. 

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 Feb 21 19:20:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 19:20: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 1U8bgk-0001u4-Cv; Thu, 21 Feb 2013 19:20:14 +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 1U8bgi-0001tu-IW
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 19:20:12 +0000
Received: from [85.158.137.99:48238] by server-10.bemta-3.messagelabs.com id
	3D/A7-10609-B6376215; Thu, 21 Feb 2013 19:20:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361474408!12107144!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTAxNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28794 invoked from network); 21 Feb 2013 19:20:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 19:20:09 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LJK68F029459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 19:20:07 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
	r1LJK6ac001059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 19:20:06 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
	r1LJK5E0002354; Thu, 21 Feb 2013 13:20:05 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 11:20:05 -0800
Date: Thu, 21 Feb 2013 11:20:04 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130221112004.05fdb740@mantra.us.oracle.com>
In-Reply-To: <20130221091001.GD24051@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@ocelot.phlegethon.org>
	<20130220190519.5fb537b1@mantra.us.oracle.com>
	<20130221091001.GD24051@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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 Thu, 21 Feb 2013 09:10:01 +0000
Tim Deegan <tim@xen.org> wrote:

> At 19:05 -0800 on 20 Feb (1361387119), Mukesh Rathor wrote:
> > On Wed, 20 Feb 2013 09:58:28 +0000
> > Tim Deegan <tim@xen.org> wrote:
> > 
> > > At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > > > On Thu, 24 Jan 2013 16:31:22 +0000
> > > > Tim Deegan <tim@xen.org> wrote:
> > > > 
> > > > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > > > +
> > > > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > > > +        {
> > > > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > > > +                pv_cpuid(regs);
> > > > > > +
> > > > > > +                /* Because we are setting CR4.OSFXSR to 0,
> > > > > > we need to disable
> > > > > > +                 * this because, during boot, user process
> > > > > > "init" (which doesn't
> > > > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > > > cause #UD. For now 
> > > > > > +                 * disable this. HVM doesn't allow setting
> > > > > > of CR4.OSFXSR.
> > > > > > +                 * fixme: this and also look at
> > > > > > CR4.OSXSAVE */ +
> > > > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > > > 
> > > > > Shouldn't this be gated on which leaf the guest asked for?
> > > > 
> > > > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > > > work. The user process "init" running nash is executing pxor
> > > > %xmm0, %xmm0 and taking #UD. Strangely, it works with EAX==0,
> > > > meaning if I clear the bit for EAX==0, changing the intel
> > > > string "ineI".  This user process doesn't do cpuid, so it must
> > > > be affected by it some other way.
> > > > 
> > > > Pretty hard to debug since it's in nash user code from ramdisk
> > > > and I am not able to set breakpoint or put printf's easily to
> > > > figure why clearing bit for EAX==0 makes it work, or what's
> > > > going on for PV and HVM guest. CR0.EM is 0, so UD is coming
> > > > from CR4.OSFXSR==0. Reading the SDMs to learn OSFXSR stuff
> > > > better....
> > > 
> > > Perhaps you need to clear the FXSR feature bit in leaf
> > > 0x80000001:EDX as well?
> > 
> > That appears to be AMD only.
> 
> It still needs to be handled. :)   You are testing this stuff on AMD
> as well, right?

Right, in pvh_svm.c when its ported. I had talked to someone from AMD
at xen summit who said he'd port it to AMD as soon as phase I patch
is checked in. It shouldn't be too hard to do that. I estimate a week
or two if I was to do SVM changes. 

Right now my hurdle working on Version 2 of the patch is all this SSE
stuff that I'm trying to figure out. I was hoping to punt it to phase
II by turning off whatever bits in CPUID, but nothing works. 

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 Feb 21 20:34:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 20:34: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 1U8cq0-0003wN-Lr; Thu, 21 Feb 2013 20:33:52 +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 1U8cpy-0003wI-Rp
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 20:33:50 +0000
Received: from [85.158.138.51:17408] by server-2.bemta-3.messagelabs.com id
	22/B6-25961-9A486215; Thu, 21 Feb 2013 20:33:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361478824!22279507!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9001 invoked from network); 21 Feb 2013 20:33:44 -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; 21 Feb 2013 20:33:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8cpr-0008Ng-GU; Thu, 21 Feb 2013 20:33:43 +0000
Date: Thu, 21 Feb 2013 20:33:43 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130221203343.GA32191@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@ocelot.phlegethon.org>
	<20130220190519.5fb537b1@mantra.us.oracle.com>
	<20130221091001.GD24051@ocelot.phlegethon.org>
	<20130221112004.05fdb740@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221112004.05fdb740@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] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 11:20 -0800 on 21 Feb (1361445604), Mukesh Rathor wrote:
> > It still needs to be handled. :)   You are testing this stuff on AMD
> > as well, right?
> 
> Right, in pvh_svm.c when its ported. I had talked to someone from AMD
> at xen summit who said he'd port it to AMD as soon as phase I patch
> is checked in. It shouldn't be too hard to do that. I estimate a week
> or two if I was to do SVM changes. 

OK, so long as there's a plan. :)

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 Feb 21 20:34:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 20:34: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 1U8cq0-0003wN-Lr; Thu, 21 Feb 2013 20:33:52 +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 1U8cpy-0003wI-Rp
	for Xen-devel@lists.xensource.com; Thu, 21 Feb 2013 20:33:50 +0000
Received: from [85.158.138.51:17408] by server-2.bemta-3.messagelabs.com id
	22/B6-25961-9A486215; Thu, 21 Feb 2013 20:33:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361478824!22279507!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9001 invoked from network); 21 Feb 2013 20:33:44 -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; 21 Feb 2013 20:33:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8cpr-0008Ng-GU; Thu, 21 Feb 2013 20:33:43 +0000
Date: Thu, 21 Feb 2013 20:33:43 +0000
From: Tim Deegan <tim@xen.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20130221203343.GA32191@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
	<20130220095828.GA12083@ocelot.phlegethon.org>
	<20130220190519.5fb537b1@mantra.us.oracle.com>
	<20130221091001.GD24051@ocelot.phlegethon.org>
	<20130221112004.05fdb740@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221112004.05fdb740@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] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.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 11:20 -0800 on 21 Feb (1361445604), Mukesh Rathor wrote:
> > It still needs to be handled. :)   You are testing this stuff on AMD
> > as well, right?
> 
> Right, in pvh_svm.c when its ported. I had talked to someone from AMD
> at xen summit who said he'd port it to AMD as soon as phase I patch
> is checked in. It shouldn't be too hard to do that. I estimate a week
> or two if I was to do SVM changes. 

OK, so long as there's a plan. :)

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 Feb 21 22:23:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22:23: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 1U8eXv-0006HB-Ca; Thu, 21 Feb 2013 22:23:19 +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 1U8eXu-0006H6-As
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:23:18 +0000
Received: from [193.109.254.147:11873] by server-14.bemta-14.messagelabs.com
	id EA/31-02031-55E96215; Thu, 21 Feb 2013 22:23:17 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361485391!8890659!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTE1NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16040 invoked from network); 21 Feb 2013 22:23:12 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 22:23:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMN84x000989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:23:09 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
	r1LMN8uV009101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:23:08 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1LMN8SG030692; Thu, 21 Feb 2013 16:23:08 -0600
MIME-Version: 1.0
Message-ID: <b4461f13-77d4-4235-a3cd-362b23b26020@default>
Date: Thu, 21 Feb 2013 14:23:08 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Kai Luo <luokain@gmail.com>, xen-devel@lists.xen.org
References: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
In-Reply-To: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6665.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] Question about PoD and Transcendent Memory for 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

> From: Kai Luo [mailto:luokain@gmail.com]
> Subject: [Xen-devel] Question about PoD and Transcendent Memory for HVM
> 
> Hi:
>       I am working at the source code of Xen 4.1.3 and have two questions that confused me.
>       I remembered a mail of XCP-mail-list which said when a hvm is created,xen allocate all memory it
> requests,which can guarantee the stability and Qos or something.However,when I come into the part of
> memory source code,I tind the existance of PoD,which can adjust memory dynamically,so I want to make
> sure whether the mechanism of memory management between XCP and Xen is differrent,Xen can adjust the
> memory size of HVM dynamically instead of a fixed memory size,am I right?
>       I know the Transcendent Memory is a better techniche of memory reuse,is it used in xen for HVM
> now?
>       Thank you for your answering!

Transcendent Memory works fine for HVM domains.  It does require
a tmem-capable guest kernel.  This requires a very recent distro
(and means tmem does not help Windows guests... though it does
co-exist with them).

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:23:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22:23: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 1U8eXv-0006HB-Ca; Thu, 21 Feb 2013 22:23:19 +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 1U8eXu-0006H6-As
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:23:18 +0000
Received: from [193.109.254.147:11873] by server-14.bemta-14.messagelabs.com
	id EA/31-02031-55E96215; Thu, 21 Feb 2013 22:23:17 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361485391!8890659!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTE1NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16040 invoked from network); 21 Feb 2013 22:23:12 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 22:23:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMN84x000989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:23:09 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
	r1LMN8uV009101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:23:08 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1LMN8SG030692; Thu, 21 Feb 2013 16:23:08 -0600
MIME-Version: 1.0
Message-ID: <b4461f13-77d4-4235-a3cd-362b23b26020@default>
Date: Thu, 21 Feb 2013 14:23:08 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Kai Luo <luokain@gmail.com>, xen-devel@lists.xen.org
References: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
In-Reply-To: <CAN71wUK_jS7Azm6OHkgJSS0OncemGLadNg+k2rVACHQRbAGSxw@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6665.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] Question about PoD and Transcendent Memory for 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

> From: Kai Luo [mailto:luokain@gmail.com]
> Subject: [Xen-devel] Question about PoD and Transcendent Memory for HVM
> 
> Hi:
>       I am working at the source code of Xen 4.1.3 and have two questions that confused me.
>       I remembered a mail of XCP-mail-list which said when a hvm is created,xen allocate all memory it
> requests,which can guarantee the stability and Qos or something.However,when I come into the part of
> memory source code,I tind the existance of PoD,which can adjust memory dynamically,so I want to make
> sure whether the mechanism of memory management between XCP and Xen is differrent,Xen can adjust the
> memory size of HVM dynamically instead of a fixed memory size,am I right?
>       I know the Transcendent Memory is a better techniche of memory reuse,is it used in xen for HVM
> now?
>       Thank you for your answering!

Transcendent Memory works fine for HVM domains.  It does require
a tmem-capable guest kernel.  This requires a very recent distro
(and means tmem does not help Windows guests... though it does
co-exist with them).

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:30:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22:30: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 1U8eeF-0006QC-7a; Thu, 21 Feb 2013 22:29:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1U8eeD-0006Q3-H4
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:29:49 +0000
Received: from [85.158.139.83:53267] by server-15.bemta-5.messagelabs.com id
	35/60-18914-CDF96215; Thu, 21 Feb 2013 22:29:48 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361485786!28363272!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQwMjk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24515 invoked from network); 21 Feb 2013 22:29:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 22:29:47 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMTesT022433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:29:41 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
	r1LMTepF010334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:29:40 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
	r1LMTdkG003089; Thu, 21 Feb 2013 16:29:39 -0600
Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 14:29:39 -0800
Date: Thu, 21 Feb 2013 23:29:28 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130221222928.GA18464@host-192-168-1-59.local.net-space.pl>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kexec@lists.infradead.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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, Feb 21, 2013 at 05:48:09PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Add replacement KEXEC_CMD_load and KEXEC_CMD_unload sub-ops to the
> kexec hypercall.  These new sub-ops allow a priviledged guest to
> provide the image data to be loaded into Xen memory or the crash
> region instead of guests loading the image data themselves and
> providing the relocation code and metadata.
>
> The old interface is provided to guests requesting an interface
> version prior to 4.3.
>
> Signed-off: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/common/kexec.c         |   12 ++++----
>  xen/include/public/kexec.h |   66 +++++++++++++++++++++++++++++++++++++++++--
>  2 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/xen/common/kexec.c b/xen/common/kexec.c
> index 6dd20c6..2cbb62c 100644
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -732,7 +732,7 @@ static void crash_save_vmcoreinfo(void)
>  #endif
>  }
>
> -static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
> +static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_v1_t *load)
>  {
>      xen_kexec_image_t *image;
>      int base, bit, pos;
> @@ -779,7 +779,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
>
>  static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
>  {
> -    xen_kexec_load_t load;
> +    xen_kexec_load_v1_t load;
>
>      if ( unlikely(copy_from_guest(&load, uarg, 1)) )
>          return -EFAULT;
> @@ -791,8 +791,8 @@ static int kexec_load_unload_compat(unsigned long op,
>                                      XEN_GUEST_HANDLE_PARAM(void) uarg)
>  {
>  #ifdef CONFIG_COMPAT
> -    compat_kexec_load_t compat_load;
> -    xen_kexec_load_t load;
> +    compat_kexec_load_v1_t compat_load;
> +    xen_kexec_load_v1_t load;
>
>      if ( unlikely(copy_from_guest(&compat_load, uarg, 1)) )
>          return -EFAULT;
> @@ -864,8 +864,8 @@ static int do_kexec_op_internal(unsigned long op,
>          else
>                  ret = kexec_get_range(uarg);
>          break;
> -    case KEXEC_CMD_kexec_load:
> -    case KEXEC_CMD_kexec_unload:
> +    case KEXEC_CMD_kexec_load_v1:
> +    case KEXEC_CMD_kexec_unload_v1:
>          spin_lock_irqsave(&kexec_lock, flags);
>          if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
>          {
> diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h
> index 61a8d7d..5259446 100644
> --- a/xen/include/public/kexec.h
> +++ b/xen/include/public/kexec.h
> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>   * image == relocation information for kexec (ignored for unload) [in]
>   */
> -#define KEXEC_CMD_kexec_load            1
> -#define KEXEC_CMD_kexec_unload          2
> -typedef struct xen_kexec_load {
> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
> +typedef struct xen_kexec_load_v1 {
>      int type;
>      xen_kexec_image_t image;
> -} xen_kexec_load_t;
> +} xen_kexec_load_v1_t;
>
>  #define KEXEC_RANGE_MA_CRASH      0 /* machine address and size of crash area */
>  #define KEXEC_RANGE_MA_XEN        1 /* machine address and size of Xen itself */
> @@ -152,6 +152,64 @@ typedef struct xen_kexec_range {
>      unsigned long start;
>  } xen_kexec_range_t;
>
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040300
> +/*
> + * A contiguous chunk of a kexec image and it's destination machine
> + * address.
> + */
> +typedef struct xen_kexec_segment {
> +    XEN_GUEST_HANDLE_64(const_void) buf;
> +    uint64_t buf_size;
> +    uint64_t dest_maddr;
> +    uint64_t dest_size;
> +} xen_kexec_segment_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_segment_t);
> +
> +/*
> + * Load a kexec image into memory.
> + *
> + * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
> + * The image is relocated prior to being executed.
> + *
> + * For KEXEC_TYPE_CRASH images, each segment of the image must reside
> + * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
> + * the entry point must be within the image. The caller is responsible
> + * for ensuring that multiple images do not overlap.

What do you mean by "The caller is responsible for ensuring
that multiple images do not overlap."?

> + */
> +
> +#define KEXEC_CMD_kexec_load 4
> +typedef struct xen_kexec_load {
> +    uint8_t  type;        /* One of KEXEC_TYPE_* */
> +    uint16_t arch;        /* ELF machine type (EM_*). */
> +    uint32_t __pad;

Why do you need __pad here?

> +    uint64_t entry_maddr; /* image entry point machine address. */
> +    uint32_t nr_segments;
> +    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
> +} xen_kexec_load_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
> +
> +/*
> + * Unload a kexec image.
> + *
> + * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH.
> + */
> +#define KEXEC_CMD_kexec_unload 5
> +typedef struct xen_kexec_unload {
> +    uint8_t type;
> +} xen_kexec_unload_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t);
> +
> +#else /* __XEN_INTERFACE_VERSION__ < 0x00040300 */
> +
> +#undef KEXEC_CMD_kexec_load
> +#undef KEXEC_CMD_kexec_unload
> +#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1
> +#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1

Could you define all constants in one place at the
beginning of this file? It is very difficult to
see what is going on. Especially those undefs are
crazy for me.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:30:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22:30: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 1U8eeF-0006QC-7a; Thu, 21 Feb 2013 22:29:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1U8eeD-0006Q3-H4
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:29:49 +0000
Received: from [85.158.139.83:53267] by server-15.bemta-5.messagelabs.com id
	35/60-18914-CDF96215; Thu, 21 Feb 2013 22:29:48 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361485786!28363272!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQwMjk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24515 invoked from network); 21 Feb 2013 22:29:47 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 22:29:47 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMTesT022433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:29:41 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
	r1LMTepF010334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:29:40 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
	r1LMTdkG003089; Thu, 21 Feb 2013 16:29:39 -0600
Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 14:29:39 -0800
Date: Thu, 21 Feb 2013 23:29:28 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130221222928.GA18464@host-192-168-1-59.local.net-space.pl>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kexec@lists.infradead.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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, Feb 21, 2013 at 05:48:09PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Add replacement KEXEC_CMD_load and KEXEC_CMD_unload sub-ops to the
> kexec hypercall.  These new sub-ops allow a priviledged guest to
> provide the image data to be loaded into Xen memory or the crash
> region instead of guests loading the image data themselves and
> providing the relocation code and metadata.
>
> The old interface is provided to guests requesting an interface
> version prior to 4.3.
>
> Signed-off: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/common/kexec.c         |   12 ++++----
>  xen/include/public/kexec.h |   66 +++++++++++++++++++++++++++++++++++++++++--
>  2 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/xen/common/kexec.c b/xen/common/kexec.c
> index 6dd20c6..2cbb62c 100644
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -732,7 +732,7 @@ static void crash_save_vmcoreinfo(void)
>  #endif
>  }
>
> -static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
> +static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_v1_t *load)
>  {
>      xen_kexec_image_t *image;
>      int base, bit, pos;
> @@ -779,7 +779,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
>
>  static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
>  {
> -    xen_kexec_load_t load;
> +    xen_kexec_load_v1_t load;
>
>      if ( unlikely(copy_from_guest(&load, uarg, 1)) )
>          return -EFAULT;
> @@ -791,8 +791,8 @@ static int kexec_load_unload_compat(unsigned long op,
>                                      XEN_GUEST_HANDLE_PARAM(void) uarg)
>  {
>  #ifdef CONFIG_COMPAT
> -    compat_kexec_load_t compat_load;
> -    xen_kexec_load_t load;
> +    compat_kexec_load_v1_t compat_load;
> +    xen_kexec_load_v1_t load;
>
>      if ( unlikely(copy_from_guest(&compat_load, uarg, 1)) )
>          return -EFAULT;
> @@ -864,8 +864,8 @@ static int do_kexec_op_internal(unsigned long op,
>          else
>                  ret = kexec_get_range(uarg);
>          break;
> -    case KEXEC_CMD_kexec_load:
> -    case KEXEC_CMD_kexec_unload:
> +    case KEXEC_CMD_kexec_load_v1:
> +    case KEXEC_CMD_kexec_unload_v1:
>          spin_lock_irqsave(&kexec_lock, flags);
>          if (!test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags))
>          {
> diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h
> index 61a8d7d..5259446 100644
> --- a/xen/include/public/kexec.h
> +++ b/xen/include/public/kexec.h
> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>   * image == relocation information for kexec (ignored for unload) [in]
>   */
> -#define KEXEC_CMD_kexec_load            1
> -#define KEXEC_CMD_kexec_unload          2
> -typedef struct xen_kexec_load {
> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
> +typedef struct xen_kexec_load_v1 {
>      int type;
>      xen_kexec_image_t image;
> -} xen_kexec_load_t;
> +} xen_kexec_load_v1_t;
>
>  #define KEXEC_RANGE_MA_CRASH      0 /* machine address and size of crash area */
>  #define KEXEC_RANGE_MA_XEN        1 /* machine address and size of Xen itself */
> @@ -152,6 +152,64 @@ typedef struct xen_kexec_range {
>      unsigned long start;
>  } xen_kexec_range_t;
>
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040300
> +/*
> + * A contiguous chunk of a kexec image and it's destination machine
> + * address.
> + */
> +typedef struct xen_kexec_segment {
> +    XEN_GUEST_HANDLE_64(const_void) buf;
> +    uint64_t buf_size;
> +    uint64_t dest_maddr;
> +    uint64_t dest_size;
> +} xen_kexec_segment_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_segment_t);
> +
> +/*
> + * Load a kexec image into memory.
> + *
> + * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
> + * The image is relocated prior to being executed.
> + *
> + * For KEXEC_TYPE_CRASH images, each segment of the image must reside
> + * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
> + * the entry point must be within the image. The caller is responsible
> + * for ensuring that multiple images do not overlap.

What do you mean by "The caller is responsible for ensuring
that multiple images do not overlap."?

> + */
> +
> +#define KEXEC_CMD_kexec_load 4
> +typedef struct xen_kexec_load {
> +    uint8_t  type;        /* One of KEXEC_TYPE_* */
> +    uint16_t arch;        /* ELF machine type (EM_*). */
> +    uint32_t __pad;

Why do you need __pad here?

> +    uint64_t entry_maddr; /* image entry point machine address. */
> +    uint32_t nr_segments;
> +    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
> +} xen_kexec_load_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
> +
> +/*
> + * Unload a kexec image.
> + *
> + * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH.
> + */
> +#define KEXEC_CMD_kexec_unload 5
> +typedef struct xen_kexec_unload {
> +    uint8_t type;
> +} xen_kexec_unload_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t);
> +
> +#else /* __XEN_INTERFACE_VERSION__ < 0x00040300 */
> +
> +#undef KEXEC_CMD_kexec_load
> +#undef KEXEC_CMD_kexec_unload
> +#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1
> +#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1

Could you define all constants in one place at the
beginning of this file? It is very difficult to
see what is going on. Especially those undefs are
crazy for me.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:42:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22:42: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 1U8epu-0006oU-G7; Thu, 21 Feb 2013 22:41:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1U8ept-0006oP-Fr
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:41:53 +0000
Received: from [193.109.254.147:59852] by server-11.bemta-14.messagelabs.com
	id C2/D5-30685-0B2A6215; Thu, 21 Feb 2013 22:41:52 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361486510!1533963!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTE1NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1665 invoked from network); 21 Feb 2013 22:41:52 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 22:41:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMflBk018877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:41:47 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
	r1LMfkYF010328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:41:46 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
	r1LMfjuk011618; Thu, 21 Feb 2013 16:41:45 -0600
Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 14:41:45 -0800
Date: Thu, 21 Feb 2013 23:41:41 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130221224141.GB18464@host-192-168-1-59.local.net-space.pl>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361468894-18655-6-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: kexec@lists.infradead.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
	load/unload 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>
Content-Type: text/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, Feb 21, 2013 at 05:48:11PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> In the existing kexec hypercall, the load and unload ops depend on
> internals of the Linux kernel (the page list and code page provided by
> the kernel).  The code page is used to transition between Xen context
> and the image so using kernel code doesn't make sense and will not
> work for PVH guests.
>
> Add replacement KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload ops
> that no longer require a code page to be provided by the guest -- Xen
> now provides the code for calling the image directly.
>
> The new load op looks similar to the Linux kexec_load system call and
> allows the guest to provide the image data to be loaded.  The guest
> specifies the architecture of the image which may be a 32-bit subarch
> of the hypervisor's architecture (i.e., an EM_386 image on an
> EM_X86_64 hypervisor).
>
> The toolstack can now load images without kernel involvement.  This is
> required for supporting kexec when using a dom0 with an upstream
> kernel.
>
> Crash images are copied directly into the crash region on load.
> Default images are copied into Xen heap pages and a list of source and
> destination machine addresses is created.  This is list is used in
> kexec_reloc() to relocate the image to its destination.
>
> The old load and unload sub-ops are still available (as
> KEXEC_CMD_load_v1 and KEXEC_CMD_unload_v1) and are implemented on top
> of the new infrastructure.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

[...]

> diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S
> new file mode 100644
> index 0000000..e68842c
> --- /dev/null
> +++ b/xen/arch/x86/x86_64/kexec_reloc.S
> @@ -0,0 +1,229 @@
> +/*
> + * Relocate a kexec_image to its destination and call it.
> + *
> + * Copyright (C) 2013 Citrix Systems R&D Ltd.
> + *
> + * Portions derived from Linux's arch/x86/kernel/relocate_kernel_64.S.
> + *
> + *   Copyright (C) 2002-2005 Eric Biederman  <ebiederm@xmission.com>
> + *
> + * This source code is licensed under the GNU General Public License,
> + * Version 2.  See the file COPYING for more details.
> + */
> +#include <xen/config.h>
> +
> +#include <asm/asm_defns.h>
> +#include <asm/msr.h>
> +#include <asm/page.h>
> +#include <asm/machine_kexec.h>
> +
> +/* The unrelocated physical address of a symbol. */
> +#define SYM_PHYS(sym)          ((sym) - __XEN_VIRT_START)
> +
> +/* Load physical address of symbol into register and relocate it. */
> +#define RELOCATE_SYM(sym,reg)  mov $SYM_PHYS(sym), reg ; \
> +                               add xen_phys_start(%rip), reg
> +
> +#define DBG(c) \
> +1:      mov     $0x3f8+5, %dx ; \
> +        inb     %dx, %al     ; \
> +        test    $0x20, %al   ; \
> +        je      1b           ; \
> +        mov     $0x3f8, %dx  ; \
> +        mov     $c, %al      ; \
> +        outb    %al, %dx     ;

Nice feature but I think that it is dangerous to write
to serial port unconditionally. There are a lot of machines
in the wild which do not have coms these days. Maybe it should be
enabled if Xen is compiled with debug feature. Then serial port
address should be established on the base of console argument.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:42:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22:42: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 1U8epu-0006oU-G7; Thu, 21 Feb 2013 22:41:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1U8ept-0006oP-Fr
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:41:53 +0000
Received: from [193.109.254.147:59852] by server-11.bemta-14.messagelabs.com
	id C2/D5-30685-0B2A6215; Thu, 21 Feb 2013 22:41:52 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361486510!1533963!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTE1NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1665 invoked from network); 21 Feb 2013 22:41:52 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Feb 2013 22:41:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMflBk018877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:41:47 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
	r1LMfkYF010328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:41:46 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
	r1LMfjuk011618; Thu, 21 Feb 2013 16:41:45 -0600
Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 14:41:45 -0800
Date: Thu, 21 Feb 2013 23:41:41 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130221224141.GB18464@host-192-168-1-59.local.net-space.pl>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361468894-18655-6-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: kexec@lists.infradead.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
	load/unload 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>
Content-Type: text/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, Feb 21, 2013 at 05:48:11PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> In the existing kexec hypercall, the load and unload ops depend on
> internals of the Linux kernel (the page list and code page provided by
> the kernel).  The code page is used to transition between Xen context
> and the image so using kernel code doesn't make sense and will not
> work for PVH guests.
>
> Add replacement KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload ops
> that no longer require a code page to be provided by the guest -- Xen
> now provides the code for calling the image directly.
>
> The new load op looks similar to the Linux kexec_load system call and
> allows the guest to provide the image data to be loaded.  The guest
> specifies the architecture of the image which may be a 32-bit subarch
> of the hypervisor's architecture (i.e., an EM_386 image on an
> EM_X86_64 hypervisor).
>
> The toolstack can now load images without kernel involvement.  This is
> required for supporting kexec when using a dom0 with an upstream
> kernel.
>
> Crash images are copied directly into the crash region on load.
> Default images are copied into Xen heap pages and a list of source and
> destination machine addresses is created.  This is list is used in
> kexec_reloc() to relocate the image to its destination.
>
> The old load and unload sub-ops are still available (as
> KEXEC_CMD_load_v1 and KEXEC_CMD_unload_v1) and are implemented on top
> of the new infrastructure.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

[...]

> diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S
> new file mode 100644
> index 0000000..e68842c
> --- /dev/null
> +++ b/xen/arch/x86/x86_64/kexec_reloc.S
> @@ -0,0 +1,229 @@
> +/*
> + * Relocate a kexec_image to its destination and call it.
> + *
> + * Copyright (C) 2013 Citrix Systems R&D Ltd.
> + *
> + * Portions derived from Linux's arch/x86/kernel/relocate_kernel_64.S.
> + *
> + *   Copyright (C) 2002-2005 Eric Biederman  <ebiederm@xmission.com>
> + *
> + * This source code is licensed under the GNU General Public License,
> + * Version 2.  See the file COPYING for more details.
> + */
> +#include <xen/config.h>
> +
> +#include <asm/asm_defns.h>
> +#include <asm/msr.h>
> +#include <asm/page.h>
> +#include <asm/machine_kexec.h>
> +
> +/* The unrelocated physical address of a symbol. */
> +#define SYM_PHYS(sym)          ((sym) - __XEN_VIRT_START)
> +
> +/* Load physical address of symbol into register and relocate it. */
> +#define RELOCATE_SYM(sym,reg)  mov $SYM_PHYS(sym), reg ; \
> +                               add xen_phys_start(%rip), reg
> +
> +#define DBG(c) \
> +1:      mov     $0x3f8+5, %dx ; \
> +        inb     %dx, %al     ; \
> +        test    $0x20, %al   ; \
> +        je      1b           ; \
> +        mov     $0x3f8, %dx  ; \
> +        mov     $c, %al      ; \
> +        outb    %al, %dx     ;

Nice feature but I think that it is dangerous to write
to serial port unconditionally. There are a lot of machines
in the wild which do not have coms these days. Maybe it should be
enabled if Xen is compiled with debug feature. Then serial port
address should be established on the base of console argument.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:47:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22: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 1U8ev9-0006xH-8m; Thu, 21 Feb 2013 22:47:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1U8ev8-0006xB-7l
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:47:18 +0000
Received: from [85.158.139.83:43419] by server-7.bemta-5.messagelabs.com id
	1D/4D-11121-5F3A6215; Thu, 21 Feb 2013 22:47:17 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361486835!28641651!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM4ODM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25663 invoked from network); 21 Feb 2013 22:47:16 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 22:47:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMlBdQ006652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:47:12 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
	r1LMlBJu005647
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:47:11 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
	r1LMlBWD003883; Thu, 21 Feb 2013 16:47:11 -0600
Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 14:47:10 -0800
Date: Thu, 21 Feb 2013 23:47:04 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130221224704.GC18464@host-192-168-1-59.local.net-space.pl>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kexec@lists.infradead.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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 Thu, Feb 21, 2013 at 05:48:06PM +0000, David Vrabel wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image.  This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
>
> The first patch is a simple clean-up.
>
> The second patch allows hypercall structures to be ABI compatible
> between 32- and 64-bit guests (by reusing stuff present for domctls
> and sysctls).  This seems better than having to keep adding compat
> handling for new hypercalls etc.
>
> Patch 3 introduces the new ABI.
>
> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
> the new code.
>
> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
> SHUTDOWN_crash.
>
> Patches 7 and 8 add the libxc API for the kexec calls.
>
> The required patch series for kexec-tools will be posted shortly.

On first sight both patch series looks quite good for me.
Give me a week or two to do some tests.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 21 22:47:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 21 Feb 2013 22: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 1U8ev9-0006xH-8m; Thu, 21 Feb 2013 22:47:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1U8ev8-0006xB-7l
	for xen-devel@lists.xen.org; Thu, 21 Feb 2013 22:47:18 +0000
Received: from [85.158.139.83:43419] by server-7.bemta-5.messagelabs.com id
	1D/4D-11121-5F3A6215; Thu, 21 Feb 2013 22:47:17 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361486835!28641651!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjM4ODM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25663 invoked from network); 21 Feb 2013 22:47:16 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Feb 2013 22:47:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1LMlBdQ006652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 21 Feb 2013 22:47:12 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
	r1LMlBJu005647
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 22:47:11 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
	r1LMlBWD003883; Thu, 21 Feb 2013 16:47:11 -0600
Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 21 Feb 2013 14:47:10 -0800
Date: Thu, 21 Feb 2013 23:47:04 +0100
From: Daniel Kiper <daniel.kiper@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130221224704.GC18464@host-192-168-1-59.local.net-space.pl>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kexec@lists.infradead.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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 Thu, Feb 21, 2013 at 05:48:06PM +0000, David Vrabel wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image.  This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
>
> The first patch is a simple clean-up.
>
> The second patch allows hypercall structures to be ABI compatible
> between 32- and 64-bit guests (by reusing stuff present for domctls
> and sysctls).  This seems better than having to keep adding compat
> handling for new hypercalls etc.
>
> Patch 3 introduces the new ABI.
>
> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
> the new code.
>
> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
> SHUTDOWN_crash.
>
> Patches 7 and 8 add the libxc API for the kexec calls.
>
> The required patch series for kexec-tools will be posted shortly.

On first sight both patch series looks quite good for me.
Give me a week or two to do some tests.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 03:15:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 03:15: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 1U8j6a-0008Ao-CM; Fri, 22 Feb 2013 03:15:24 +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 1U8j6Z-0008Aj-GS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 03:15:23 +0000
Received: from [85.158.137.99:44691] by server-13.bemta-3.messagelabs.com id
	8D/B3-20653-AC2E6215; Fri, 22 Feb 2013 03:15:22 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361502920!12370566!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxODg5NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6045 invoked from network); 22 Feb 2013 03:15:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-217.messagelabs.com with SMTP;
	22 Feb 2013 03:15:21 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 21 Feb 2013 19:15:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,713,1355126400"; d="scan'208";a="294462596"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga002.fm.intel.com with ESMTP; 21 Feb 2013 19:15:16 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: aliguori@us.ibm.com,
	mst@redhat.com,
	qemu-devel@nongnu.org
Date: Fri, 22 Feb 2013 11:23:13 +0800
Message-Id: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: xen-devel@lists.xen.org, Xudong Hao <xudong.hao@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] qemu: define a TOM register to report the base
	of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Define a TOM(top of memory) register to report the base of PCI memory, update
memory region dynamically.

The use case of this register defination is for Xen till now.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/pc.h       |  4 ---
 hw/pc_piix.c  |  6 -----
 hw/piix_pci.c | 79 ++++++++++++++++++++++++++++++++++++++++++++---------------
 3 files changed, 59 insertions(+), 30 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..2a60490 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -134,10 +134,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory,
                     MemoryRegion *ram_memory);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..98cf467 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
                               system_memory, system_io, ram_size,
-                              below_4g_mem_size,
-                              0x100000000ULL - below_4g_mem_size,
-                              0x100000000ULL + above_4g_mem_size,
-                              (sizeof(hwaddr) == 4
-                               ? 0
-                               : ((uint64_t)1 << 62)),
                               pci_memory, ram_memory);
     } else {
         pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..88bd688 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
 #define I440FX_PAM_SIZE 7
 #define I440FX_SMRAM    0x72
 
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use four bytes 0xb0-0xb3 for this purpose, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
 static void piix3_set_irq(void *opaque, int pirq, int level);
 static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
 static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
     return (pci_intx + slot_addend) & 3;
 }
 
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+    ram_addr_t above_4g_mem_size;
+    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
+
+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 4);
+    pci_hole_size = 0x100000000ULL - pci_hole_start;
+
+    if (ram_size >= pci_hole_start) {
+        above_4g_mem_size = ram_size - pci_hole_start;
+    } else {
+        above_4g_mem_size = 0;
+    }
+    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
+    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
+
+    if (del) {
+        memory_region_del_subregion(f->system_memory, &f->pci_hole);
+        if (pci_hole64_size) {
+            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
+        }
+    }
+
+    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
+                             pci_hole_start, pci_hole_size);
+    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
+    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
+                             f->pci_address_space,
+                             pci_hole64_start, pci_hole64_size);
+    if (pci_hole64_size) {
+        memory_region_add_subregion(f->system_memory, pci_hole64_start,
+                                    &f->pci_hole_64bit);
+    }
+}
+
+
 static void i440fx_update_memory_mappings(PCII440FXState *d)
 {
     int i;
@@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
         range_covers_byte(address, len, I440FX_SMRAM)) {
         i440fx_update_memory_mappings(d);
     }
+    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
+        i440fx_update_pci_mem_hole(d, true);
+    }
 }
 
 static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
@@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
 
     d->dev.config[I440FX_SMRAM] = 0x02;
 
+    /* Emulate top of memory, here use 0xe0000000 as default val*/
+    if (xen_enabled()) {
+        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
+    } else {
+        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
+    }
+    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
+    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
+    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
+
     cpu_smm_register(&i440fx_set_smm, d);
     return 0;
 }
@@ -214,10 +272,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
                                   MemoryRegion *address_space_mem,
                                   MemoryRegion *address_space_io,
                                   ram_addr_t ram_size,
-                                  hwaddr pci_hole_start,
-                                  hwaddr pci_hole_size,
-                                  hwaddr pci_hole64_start,
-                                  hwaddr pci_hole64_size,
                                   MemoryRegion *pci_address_space,
                                   MemoryRegion *ram_memory)
 {
@@ -244,16 +298,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
     f->ram_memory = ram_memory;
-    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
-                             pci_hole_start, pci_hole_size);
-    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
-    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
-                             f->pci_address_space,
-                             pci_hole64_start, pci_hole64_size);
-    if (pci_hole64_size) {
-        memory_region_add_subregion(f->system_memory, pci_hole64_start,
-                                    &f->pci_hole_64bit);
-    }
     memory_region_init_alias(&f->smram_region, "smram-region",
                              f->pci_address_space, 0xa0000, 0x20000);
     memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
@@ -295,6 +339,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
     (*pi440fx_state)->dev.config[0x57]=ram_size;
 
     i440fx_update_memory_mappings(f);
+    i440fx_update_pci_mem_hole(f, false);
 
     return b;
 }
@@ -304,10 +349,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory, MemoryRegion *ram_memory)
 
 {
@@ -315,8 +356,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
 
     b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
                            address_space_mem, address_space_io, ram_size,
-                           pci_hole_start, pci_hole_size,
-                           pci_hole64_start, pci_hole64_size,
                            pci_memory, ram_memory);
     return b;
 }
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 03:15:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 03:15: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 1U8j6a-0008Ao-CM; Fri, 22 Feb 2013 03:15:24 +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 1U8j6Z-0008Aj-GS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 03:15:23 +0000
Received: from [85.158.137.99:44691] by server-13.bemta-3.messagelabs.com id
	8D/B3-20653-AC2E6215; Fri, 22 Feb 2013 03:15:22 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361502920!12370566!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxODg5NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6045 invoked from network); 22 Feb 2013 03:15:21 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-7.tower-217.messagelabs.com with SMTP;
	22 Feb 2013 03:15:21 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 21 Feb 2013 19:15:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,713,1355126400"; d="scan'208";a="294462596"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga002.fm.intel.com with ESMTP; 21 Feb 2013 19:15:16 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: aliguori@us.ibm.com,
	mst@redhat.com,
	qemu-devel@nongnu.org
Date: Fri, 22 Feb 2013 11:23:13 +0800
Message-Id: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: xen-devel@lists.xen.org, Xudong Hao <xudong.hao@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] qemu: define a TOM register to report the base
	of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Define a TOM(top of memory) register to report the base of PCI memory, update
memory region dynamically.

The use case of this register defination is for Xen till now.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/pc.h       |  4 ---
 hw/pc_piix.c  |  6 -----
 hw/piix_pci.c | 79 ++++++++++++++++++++++++++++++++++++++++++++---------------
 3 files changed, 59 insertions(+), 30 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..2a60490 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -134,10 +134,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory,
                     MemoryRegion *ram_memory);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..98cf467 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
                               system_memory, system_io, ram_size,
-                              below_4g_mem_size,
-                              0x100000000ULL - below_4g_mem_size,
-                              0x100000000ULL + above_4g_mem_size,
-                              (sizeof(hwaddr) == 4
-                               ? 0
-                               : ((uint64_t)1 << 62)),
                               pci_memory, ram_memory);
     } else {
         pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..88bd688 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
 #define I440FX_PAM_SIZE 7
 #define I440FX_SMRAM    0x72
 
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use four bytes 0xb0-0xb3 for this purpose, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
 static void piix3_set_irq(void *opaque, int pirq, int level);
 static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
 static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
     return (pci_intx + slot_addend) & 3;
 }
 
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+    ram_addr_t above_4g_mem_size;
+    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
+
+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 4);
+    pci_hole_size = 0x100000000ULL - pci_hole_start;
+
+    if (ram_size >= pci_hole_start) {
+        above_4g_mem_size = ram_size - pci_hole_start;
+    } else {
+        above_4g_mem_size = 0;
+    }
+    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
+    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
+
+    if (del) {
+        memory_region_del_subregion(f->system_memory, &f->pci_hole);
+        if (pci_hole64_size) {
+            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
+        }
+    }
+
+    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
+                             pci_hole_start, pci_hole_size);
+    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
+    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
+                             f->pci_address_space,
+                             pci_hole64_start, pci_hole64_size);
+    if (pci_hole64_size) {
+        memory_region_add_subregion(f->system_memory, pci_hole64_start,
+                                    &f->pci_hole_64bit);
+    }
+}
+
+
 static void i440fx_update_memory_mappings(PCII440FXState *d)
 {
     int i;
@@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
         range_covers_byte(address, len, I440FX_SMRAM)) {
         i440fx_update_memory_mappings(d);
     }
+    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
+        i440fx_update_pci_mem_hole(d, true);
+    }
 }
 
 static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
@@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
 
     d->dev.config[I440FX_SMRAM] = 0x02;
 
+    /* Emulate top of memory, here use 0xe0000000 as default val*/
+    if (xen_enabled()) {
+        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
+    } else {
+        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
+    }
+    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
+    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
+    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
+
     cpu_smm_register(&i440fx_set_smm, d);
     return 0;
 }
@@ -214,10 +272,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
                                   MemoryRegion *address_space_mem,
                                   MemoryRegion *address_space_io,
                                   ram_addr_t ram_size,
-                                  hwaddr pci_hole_start,
-                                  hwaddr pci_hole_size,
-                                  hwaddr pci_hole64_start,
-                                  hwaddr pci_hole64_size,
                                   MemoryRegion *pci_address_space,
                                   MemoryRegion *ram_memory)
 {
@@ -244,16 +298,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
     f->ram_memory = ram_memory;
-    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
-                             pci_hole_start, pci_hole_size);
-    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
-    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
-                             f->pci_address_space,
-                             pci_hole64_start, pci_hole64_size);
-    if (pci_hole64_size) {
-        memory_region_add_subregion(f->system_memory, pci_hole64_start,
-                                    &f->pci_hole_64bit);
-    }
     memory_region_init_alias(&f->smram_region, "smram-region",
                              f->pci_address_space, 0xa0000, 0x20000);
     memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
@@ -295,6 +339,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
     (*pi440fx_state)->dev.config[0x57]=ram_size;
 
     i440fx_update_memory_mappings(f);
+    i440fx_update_pci_mem_hole(f, false);
 
     return b;
 }
@@ -304,10 +349,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory, MemoryRegion *ram_memory)
 
 {
@@ -315,8 +356,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
 
     b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
                            address_space_mem, address_space_io, ram_size,
-                           pci_hole_start, pci_hole_size,
-                           pci_hole64_start, pci_hole64_size,
                            pci_memory, ram_memory);
     return b;
 }
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 03:18:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 03: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 1U8j9R-0008Gf-VO; Fri, 22 Feb 2013 03:18:21 +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 1U8j9Q-0008Ga-W6
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 03:18:21 +0000
Received: from [193.109.254.147:46626] by server-7.bemta-14.messagelabs.com id
	2E/A4-13581-C73E6215; Fri, 22 Feb 2013 03:18:20 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361503073!2358697!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzUxMDY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2371 invoked from network); 22 Feb 2013 03:17:54 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-27.messagelabs.com with SMTP;
	22 Feb 2013 03:17:54 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 21 Feb 2013 19:17:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,713,1355126400"; d="scan'208";a="266017072"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 21 Feb 2013 19:17:46 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: ian.campbell@citrix.com,
	keir@xen.org
Date: Fri, 22 Feb 2013 11:25:43 +0800
Message-Id: <1361503543-10751-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: aliguori@us.ibm.com, Stefano.Stabellini@eu.citrix.com, mst@redhat.com,
	Xudong Hao <xudong.hao@intel.com>, xen-devel@lists.xen.org,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH]xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Define a TOM(top of memory) register to report the base of PCI memory, so that
qemu should update MMIO by reading this register value.

With the combination of qemu upstream, this should be a fix for PCI MMIO hole
configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set MMIO
to 0x80000000~0xe0000000.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 tools/firmware/hvmloader/pci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c7c87a7..a70e1d1 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -34,6 +34,29 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+#define PCI_CLASS_BRIDGE_HOST            0x0600
+#define PCI_VENDOR_ID_INTEL              0x8086
+#define PCI_DEVICE_ID_INTEL_82441        0x1237
+#define I440FX_PCI_HOLE_BASE             0xb0
+
+static void pci_adjust_pci_hole(uint32_t pci_hole_start)
+{
+    uint16_t class, vendor_id, device_id;
+    if (pci_hole_start == 0xf0000000)
+        return;
+
+    /* Check whether it is I440FX */
+    class     = pci_readw(0, PCI_CLASS_DEVICE);
+    vendor_id = pci_readw(0, PCI_VENDOR_ID);
+    device_id = pci_readw(0, PCI_DEVICE_ID);
+
+    if (class != PCI_CLASS_BRIDGE_HOST ||
+        vendor_id != PCI_VENDOR_ID_INTEL ||
+        device_id != PCI_DEVICE_ID_INTEL_82441)
+        return;
+    pci_writel(0, I440FX_PCI_HOLE_BASE, pci_hole_start);
+
+}
 void pci_setup(void)
 {
     uint8_t is_64bar, using_64bar, bar64_relocate = 0;
@@ -236,6 +259,7 @@ void pci_setup(void)
             BUG();
         hvm_info->high_mem_pgend += nr_pages;
     }
+    pci_adjust_pci_hole(hvm_info->low_mem_pgend << PAGE_SHIFT);
 
     high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
     high_mem_resource.max = 1ull << cpu_phys_addr();
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 03:18:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 03: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 1U8j9R-0008Gf-VO; Fri, 22 Feb 2013 03:18:21 +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 1U8j9Q-0008Ga-W6
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 03:18:21 +0000
Received: from [193.109.254.147:46626] by server-7.bemta-14.messagelabs.com id
	2E/A4-13581-C73E6215; Fri, 22 Feb 2013 03:18:20 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361503073!2358697!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzUxMDY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2371 invoked from network); 22 Feb 2013 03:17:54 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-27.messagelabs.com with SMTP;
	22 Feb 2013 03:17:54 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 21 Feb 2013 19:17:48 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,713,1355126400"; d="scan'208";a="266017072"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 21 Feb 2013 19:17:46 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: ian.campbell@citrix.com,
	keir@xen.org
Date: Fri, 22 Feb 2013 11:25:43 +0800
Message-Id: <1361503543-10751-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: aliguori@us.ibm.com, Stefano.Stabellini@eu.citrix.com, mst@redhat.com,
	Xudong Hao <xudong.hao@intel.com>, xen-devel@lists.xen.org,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH]xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Define a TOM(top of memory) register to report the base of PCI memory, so that
qemu should update MMIO by reading this register value.

With the combination of qemu upstream, this should be a fix for PCI MMIO hole
configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set MMIO
to 0x80000000~0xe0000000.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 tools/firmware/hvmloader/pci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c7c87a7..a70e1d1 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -34,6 +34,29 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+#define PCI_CLASS_BRIDGE_HOST            0x0600
+#define PCI_VENDOR_ID_INTEL              0x8086
+#define PCI_DEVICE_ID_INTEL_82441        0x1237
+#define I440FX_PCI_HOLE_BASE             0xb0
+
+static void pci_adjust_pci_hole(uint32_t pci_hole_start)
+{
+    uint16_t class, vendor_id, device_id;
+    if (pci_hole_start == 0xf0000000)
+        return;
+
+    /* Check whether it is I440FX */
+    class     = pci_readw(0, PCI_CLASS_DEVICE);
+    vendor_id = pci_readw(0, PCI_VENDOR_ID);
+    device_id = pci_readw(0, PCI_DEVICE_ID);
+
+    if (class != PCI_CLASS_BRIDGE_HOST ||
+        vendor_id != PCI_VENDOR_ID_INTEL ||
+        device_id != PCI_DEVICE_ID_INTEL_82441)
+        return;
+    pci_writel(0, I440FX_PCI_HOLE_BASE, pci_hole_start);
+
+}
 void pci_setup(void)
 {
     uint8_t is_64bar, using_64bar, bar64_relocate = 0;
@@ -236,6 +259,7 @@ void pci_setup(void)
             BUG();
         hvm_info->high_mem_pgend += nr_pages;
     }
+    pci_adjust_pci_hole(hvm_info->low_mem_pgend << PAGE_SHIFT);
 
     high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
     high_mem_resource.max = 1ull << cpu_phys_addr();
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 07:42:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 07:42: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 1U8nGf-0004C4-32; Fri, 22 Feb 2013 07:42:05 +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 1U8nGd-0004Bz-0W
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 07:42:03 +0000
Received: from [85.158.137.99:59768] by server-10.bemta-3.messagelabs.com id
	29/EC-10609-A4127215; Fri, 22 Feb 2013 07:42:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361518912!16664992!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9506 invoked from network); 22 Feb 2013 07:41:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 07:41:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 07:41:51 +0000
Message-Id: <51272F8902000078000C0361@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 07:42:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
In-Reply-To: <20130221173115.GA13045@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Feb 21, Jan Beulich wrote:
> 
>> What you could do to get a better understanding of when this
>> happens is to add a WARN_ON() alongside the printk() (perhaps
>> such that it triggers only once for each of the two different
>> cases), and then let us look at the call trace.
> 
> It did not happen with xl.

Odd.

> Here is the output while doing xm migrate:
> ...
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c0170fb2>] get_page+0xfb/0x151
> (XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
> (XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
> (XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
> (XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
> (XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
> (XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
> (XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145
> ...
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c0170fdc>] get_page+0x125/0x151
> (XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
> (XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
> (XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
> (XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
> (XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
> (XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
> (XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145

And that's without paging or anything similar? Else I would expect
the problem to be in the interaction there. But I'll also take a look
at the grant table code assuming this is a problem even without
any enhanced memory management functionality...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 07:42:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 07:42: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 1U8nGf-0004C4-32; Fri, 22 Feb 2013 07:42:05 +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 1U8nGd-0004Bz-0W
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 07:42:03 +0000
Received: from [85.158.137.99:59768] by server-10.bemta-3.messagelabs.com id
	29/EC-10609-A4127215; Fri, 22 Feb 2013 07:42:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361518912!16664992!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9506 invoked from network); 22 Feb 2013 07:41:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 07:41:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 07:41:51 +0000
Message-Id: <51272F8902000078000C0361@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 07:42:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
In-Reply-To: <20130221173115.GA13045@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> On Thu, Feb 21, Jan Beulich wrote:
> 
>> What you could do to get a better understanding of when this
>> happens is to add a WARN_ON() alongside the printk() (perhaps
>> such that it triggers only once for each of the two different
>> cases), and then let us look at the call trace.
> 
> It did not happen with xl.

Odd.

> Here is the output while doing xm migrate:
> ...
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c0170fb2>] get_page+0xfb/0x151
> (XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
> (XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
> (XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
> (XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
> (XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
> (XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
> (XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145
> ...
> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c0170fdc>] get_page+0x125/0x151
> (XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
> (XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
> (XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
> (XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
> (XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
> (XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
> (XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145

And that's without paging or anything similar? Else I would expect
the problem to be in the interaction there. But I'll also take a look
at the grant table code assuming this is a problem even without
any enhanced memory management functionality...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:11:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8niu-0005AD-3z; Fri, 22 Feb 2013 08:11:16 +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 1U8nis-0005A8-98
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:11:14 +0000
Received: from [193.109.254.147:3021] by server-5.bemta-14.messagelabs.com id
	67/3D-21539-12827215; Fri, 22 Feb 2013 08:11:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361520669!4147437!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1264 invoked from network); 22 Feb 2013 08:11:09 -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; 22 Feb 2013 08:11:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:11:08 +0000
Message-Id: <5127366502000078000C0380@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:12:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361466961.26546.85.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> On ARM we want these to be the same size on 32- and 64-bit.
>> 
>> This is an ABI change on ARM. X86 does not change.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Jan Beulich <JBeulich@suse.com>
>> Cc: Keir (Xen.org) <keir@xen.org>
> 
> Are you guys (un)happy with this change from the Xen & x86 side?

I don't see any problem with it.

Jan

>> Cc: Tim Deegan <tim@xen.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: linux-arm-kernel@lists.infradead.org 
>> Cc: xen-devel@lists.xen.org 
>> ---
>>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>>  xen/include/public/xen.h              |    8 ++++----
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/tools/include/xen-foreign/mkheader.py 
> b/tools/include/xen-foreign/mkheader.py
>> index d189b07..57681fa 100644
>> --- a/tools/include/xen-foreign/mkheader.py
>> +++ b/tools/include/xen-foreign/mkheader.py
>> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint64_t",
>> +    "xen_ulong_t"   : "uint64_t",
>>  };
>> +header["arm"] = """
>> +#define __arm___ARM32 1
>> +""";
>>  
>>  # x86_32
>>  inttypes["x86_32"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint32_t",
>> +    "xen_ulong_t"   : "uint32_t",
>>  };
>>  header["x86_32"] = """
>>  #define __i386___X86_32 1
>> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>>      "unsigned long" : "__align8__ uint64_t",
>>      "long"          : "__align8__ uint64_t",
>>      "xen_pfn_t"     : "__align8__ uint64_t",
>> +    "xen_ulong_t"   : "__align8__ uint64_t",
>>  };
>>  header["x86_64"] = """
>>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 5593066..99c8212 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>>   * Event channel endpoints per domain:
>>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>>   */
>> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 
> 64)
>> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>>  
>>  struct vcpu_time_info {
>>      /*
>> @@ -613,7 +613,7 @@ struct vcpu_info {
>>       */
>>      uint8_t evtchn_upcall_pending;
>>      uint8_t evtchn_upcall_mask;
>> -    unsigned long evtchn_pending_sel;
>> +    xen_ulong_t evtchn_pending_sel;
>>      struct arch_vcpu_info arch;
>>      struct vcpu_time_info time;
>>  }; /* 64 bytes (x86) */
>> @@ -663,8 +663,8 @@ struct shared_info {
>>       * per-vcpu selector word to be set. Each bit in the selector covers a
>>       * 'C long' in the PENDING bitfield array.
>>       */
>> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
>> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
>> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
>> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>>  
>>      /*
>>       * Wallclock time: updated only by control software. Guests should base




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:11:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8niu-0005AD-3z; Fri, 22 Feb 2013 08:11:16 +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 1U8nis-0005A8-98
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:11:14 +0000
Received: from [193.109.254.147:3021] by server-5.bemta-14.messagelabs.com id
	67/3D-21539-12827215; Fri, 22 Feb 2013 08:11:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361520669!4147437!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1264 invoked from network); 22 Feb 2013 08:11:09 -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; 22 Feb 2013 08:11:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:11:08 +0000
Message-Id: <5127366502000078000C0380@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:12:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361466961.26546.85.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim\(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> On ARM we want these to be the same size on 32- and 64-bit.
>> 
>> This is an ABI change on ARM. X86 does not change.
>> 
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Jan Beulich <JBeulich@suse.com>
>> Cc: Keir (Xen.org) <keir@xen.org>
> 
> Are you guys (un)happy with this change from the Xen & x86 side?

I don't see any problem with it.

Jan

>> Cc: Tim Deegan <tim@xen.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: linux-arm-kernel@lists.infradead.org 
>> Cc: xen-devel@lists.xen.org 
>> ---
>>  tools/include/xen-foreign/mkheader.py |    6 ++++++
>>  xen/include/public/xen.h              |    8 ++++----
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/tools/include/xen-foreign/mkheader.py 
> b/tools/include/xen-foreign/mkheader.py
>> index d189b07..57681fa 100644
>> --- a/tools/include/xen-foreign/mkheader.py
>> +++ b/tools/include/xen-foreign/mkheader.py
>> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint64_t",
>> +    "xen_ulong_t"   : "uint64_t",
>>  };
>> +header["arm"] = """
>> +#define __arm___ARM32 1
>> +""";
>>  
>>  # x86_32
>>  inttypes["x86_32"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>>      "xen_pfn_t"     : "uint32_t",
>> +    "xen_ulong_t"   : "uint32_t",
>>  };
>>  header["x86_32"] = """
>>  #define __i386___X86_32 1
>> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>>      "unsigned long" : "__align8__ uint64_t",
>>      "long"          : "__align8__ uint64_t",
>>      "xen_pfn_t"     : "__align8__ uint64_t",
>> +    "xen_ulong_t"   : "__align8__ uint64_t",
>>  };
>>  header["x86_64"] = """
>>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 5593066..99c8212 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>>   * Event channel endpoints per domain:
>>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>>   */
>> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 
> 64)
>> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>>  
>>  struct vcpu_time_info {
>>      /*
>> @@ -613,7 +613,7 @@ struct vcpu_info {
>>       */
>>      uint8_t evtchn_upcall_pending;
>>      uint8_t evtchn_upcall_mask;
>> -    unsigned long evtchn_pending_sel;
>> +    xen_ulong_t evtchn_pending_sel;
>>      struct arch_vcpu_info arch;
>>      struct vcpu_time_info time;
>>  }; /* 64 bytes (x86) */
>> @@ -663,8 +663,8 @@ struct shared_info {
>>       * per-vcpu selector word to be set. Each bit in the selector covers a
>>       * 'C long' in the PENDING bitfield array.
>>       */
>> -    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
>> -    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
>> +    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
>> +    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>>  
>>      /*
>>       * Wallclock time: updated only by control software. Guests should base




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:14:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8nlU-0005GL-NK; Fri, 22 Feb 2013 08:13:56 +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 1U8nlU-0005GF-13
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:13:56 +0000
Received: from [193.109.254.147:29040] by server-12.bemta-14.messagelabs.com
	id 6F/E3-32582-3C827215; Fri, 22 Feb 2013 08:13:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361520785!9266853!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19377 invoked from network); 22 Feb 2013 08:13:06 -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; 22 Feb 2013 08:13:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:13:05 +0000
Message-Id: <512736DA02000078000C038C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:14:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

>>> On 21.02.13 at 18:57, David Vrabel <david.vrabel@citrix.com> wrote:
> The series adds support for the new hypercall ABI which should be
> provided by Xen 4.3.  Images are loaded into Xen directly with no
> kernel involvement.
> 
> Do not apply until the hypervisor side patches are applied to Xen.
> 
> Patch 1 is unrelated but kexec wouldn't work for me without it. Not
> sure why I had problems, perhaps a toolstack specific issue?
> 
> Patch 2 makes libxc 4.3 mandatory for Xen support.

That doesn't sound right. How do you envision this to be
incorporated into existing distros that don't right away switch
to Xen 4.3?

Jan

> Patch 3 removes a use of /proc/iomem in favour of libxc.
> 
> Patch 4 adds the support for loading an image into Xen.
> 
> This series explicitly drops support for older version of libxc/Xen as
> supporting kexec on these hypervisors requires kernel support that
> will never be available upstream.
> 
> 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 Fri Feb 22 08:14:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8nlU-0005GL-NK; Fri, 22 Feb 2013 08:13:56 +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 1U8nlU-0005GF-13
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:13:56 +0000
Received: from [193.109.254.147:29040] by server-12.bemta-14.messagelabs.com
	id 6F/E3-32582-3C827215; Fri, 22 Feb 2013 08:13:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361520785!9266853!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19377 invoked from network); 22 Feb 2013 08:13:06 -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; 22 Feb 2013 08:13:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:13:05 +0000
Message-Id: <512736DA02000078000C038C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:14:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

>>> On 21.02.13 at 18:57, David Vrabel <david.vrabel@citrix.com> wrote:
> The series adds support for the new hypercall ABI which should be
> provided by Xen 4.3.  Images are loaded into Xen directly with no
> kernel involvement.
> 
> Do not apply until the hypervisor side patches are applied to Xen.
> 
> Patch 1 is unrelated but kexec wouldn't work for me without it. Not
> sure why I had problems, perhaps a toolstack specific issue?
> 
> Patch 2 makes libxc 4.3 mandatory for Xen support.

That doesn't sound right. How do you envision this to be
incorporated into existing distros that don't right away switch
to Xen 4.3?

Jan

> Patch 3 removes a use of /proc/iomem in favour of libxc.
> 
> Patch 4 adds the support for loading an image into Xen.
> 
> This series explicitly drops support for older version of libxc/Xen as
> supporting kexec on these hypervisors requires kernel support that
> will never be available upstream.
> 
> 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 Fri Feb 22 08:16:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:16: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 1U8no0-0005Oc-Bm; Fri, 22 Feb 2013 08:16: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 1U8nnz-0005OU-8d
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:16:31 +0000
Received: from [193.109.254.147:2121] by server-2.bemta-14.messagelabs.com id
	39/69-16277-E5927215; Fri, 22 Feb 2013 08:16:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361520986!8636933!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12941 invoked from network); 22 Feb 2013 08:16:27 -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; 22 Feb 2013 08:16:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:16:26 +0000
Message-Id: <512737A302000078000C038F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:17:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image.  This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
> 
> The first patch is a simple clean-up.
> 
> The second patch allows hypercall structures to be ABI compatible
> between 32- and 64-bit guests (by reusing stuff present for domctls
> and sysctls).  This seems better than having to keep adding compat
> handling for new hypercalls etc.
> 
> Patch 3 introduces the new ABI.
> 
> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
> the new code.
> 
> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
> SHUTDOWN_crash.

Am I right in understanding that at this point no kexec support is
necessary in the Dom0 kernel at all anymore? If so, that's a very
nice move - thanks for doing that!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:16:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:16: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 1U8no0-0005Oc-Bm; Fri, 22 Feb 2013 08:16: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 1U8nnz-0005OU-8d
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:16:31 +0000
Received: from [193.109.254.147:2121] by server-2.bemta-14.messagelabs.com id
	39/69-16277-E5927215; Fri, 22 Feb 2013 08:16:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361520986!8636933!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12941 invoked from network); 22 Feb 2013 08:16:27 -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; 22 Feb 2013 08:16:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:16:26 +0000
Message-Id: <512737A302000078000C038F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:17:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image.  This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
> 
> The first patch is a simple clean-up.
> 
> The second patch allows hypercall structures to be ABI compatible
> between 32- and 64-bit guests (by reusing stuff present for domctls
> and sysctls).  This seems better than having to keep adding compat
> handling for new hypercalls etc.
> 
> Patch 3 introduces the new ABI.
> 
> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
> the new code.
> 
> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
> SHUTDOWN_crash.

Am I right in understanding that at this point no kexec support is
necessary in the Dom0 kernel at all anymore? If so, that's a very
nice move - thanks for doing that!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:29:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:29: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 1U8nzr-0005lf-LI; Fri, 22 Feb 2013 08:28:47 +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 1U8nzq-0005lP-8w
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:28:46 +0000
Received: from [193.109.254.147:29380] by server-7.bemta-14.messagelabs.com id
	B8/C1-13581-D3C27215; Fri, 22 Feb 2013 08:28:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361521724!9268954!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6481 invoked from network); 22 Feb 2013 08:28:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:28:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1770297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:28: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.297.1;
	Fri, 22 Feb 2013 08:28:37 +0000
Message-ID: <1361521714.26546.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 22 Feb 2013 08:28:34 +0000
In-Reply-To: <CD4C1B4B.4C72B%keir.xen@gmail.com>
References: <CD4C1B4B.4C72B%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 18:43 +0000, Keir Fraser wrote:
> On 21/02/2013 17:16, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> >> On ARM we want these to be the same size on 32- and 64-bit.
> >> 
> >> This is an ABI change on ARM. X86 does not change.
> >> 
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> Cc: Jan Beulich <JBeulich@suse.com>
> >> Cc: Keir (Xen.org) <keir@xen.org>
> > 
> > Are you guys (un)happy with this change from the Xen & x86 side?
> 
> Fine by me.

I'm going to take that as an Acked-by then, assuming that's ok with you.
I suppose Fine-by: Keir would do too ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:29:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:29: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 1U8nzr-0005lf-LI; Fri, 22 Feb 2013 08:28:47 +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 1U8nzq-0005lP-8w
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:28:46 +0000
Received: from [193.109.254.147:29380] by server-7.bemta-14.messagelabs.com id
	B8/C1-13581-D3C27215; Fri, 22 Feb 2013 08:28:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361521724!9268954!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6481 invoked from network); 22 Feb 2013 08:28:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:28:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1770297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:28: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.297.1;
	Fri, 22 Feb 2013 08:28:37 +0000
Message-ID: <1361521714.26546.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 22 Feb 2013 08:28:34 +0000
In-Reply-To: <CD4C1B4B.4C72B%keir.xen@gmail.com>
References: <CD4C1B4B.4C72B%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	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@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 18:43 +0000, Keir Fraser wrote:
> On 21/02/2013 17:16, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> >> On ARM we want these to be the same size on 32- and 64-bit.
> >> 
> >> This is an ABI change on ARM. X86 does not change.
> >> 
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> Cc: Jan Beulich <JBeulich@suse.com>
> >> Cc: Keir (Xen.org) <keir@xen.org>
> > 
> > Are you guys (un)happy with this change from the Xen & x86 side?
> 
> Fine by me.

I'm going to take that as an Acked-by then, assuming that's ok with you.
I suppose Fine-by: Keir would do too ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:29:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:29: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 1U8nzr-0005lY-7V; Fri, 22 Feb 2013 08:28:47 +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 1U8nzq-0005lO-8n
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:28:46 +0000
Received: from [193.109.254.147:55482] by server-6.bemta-14.messagelabs.com id
	D6/45-12010-D3C27215; Fri, 22 Feb 2013 08:28:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361521724!9268954!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6483 invoked from network); 22 Feb 2013 08:28:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:28:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1770299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:28: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.297.1;
	Fri, 22 Feb 2013 08:28:41 +0000
Message-ID: <1361521720.26546.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 08:28:40 +0000
In-Reply-To: <5127366502000078000C0380@nat28.tlf.novell.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> >> On ARM we want these to be the same size on 32- and 64-bit.
> >> 
> >> This is an ABI change on ARM. X86 does not change.
> >> 
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> Cc: Jan Beulich <JBeulich@suse.com>
> >> Cc: Keir (Xen.org) <keir@xen.org>
> > 
> > Are you guys (un)happy with this change from the Xen & x86 side?
> 
> I don't see any problem with it.

I'll take this as an Acked-by if that's ok with you.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:29:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:29: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 1U8nzr-0005lY-7V; Fri, 22 Feb 2013 08:28:47 +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 1U8nzq-0005lO-8n
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:28:46 +0000
Received: from [193.109.254.147:55482] by server-6.bemta-14.messagelabs.com id
	D6/45-12010-D3C27215; Fri, 22 Feb 2013 08:28:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361521724!9268954!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6483 invoked from network); 22 Feb 2013 08:28:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:28:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1770299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:28: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.297.1;
	Fri, 22 Feb 2013 08:28:41 +0000
Message-ID: <1361521720.26546.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 08:28:40 +0000
In-Reply-To: <5127366502000078000C0380@nat28.tlf.novell.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> >> On ARM we want these to be the same size on 32- and 64-bit.
> >> 
> >> This is an ABI change on ARM. X86 does not change.
> >> 
> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> Cc: Jan Beulich <JBeulich@suse.com>
> >> Cc: Keir (Xen.org) <keir@xen.org>
> > 
> > Are you guys (un)happy with this change from the Xen & x86 side?
> 
> I don't see any problem with it.

I'll take this as an Acked-by if that's ok with you.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:33:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8o3z-00068E-EH; Fri, 22 Feb 2013 08:33:03 +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 1U8o3y-000682-6O
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:33:02 +0000
Received: from [85.158.139.211:32527] by server-14.bemta-5.messagelabs.com id
	1D/66-06967-D3D27215; Fri, 22 Feb 2013 08:33:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361521980!18733477!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12601 invoked from network); 22 Feb 2013 08:33:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 08:33:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:33:00 +0000
Message-Id: <51273B8502000078000C03BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:33:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
> --- a/xen/include/public/kexec.h
> +++ b/xen/include/public/kexec.h
> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>   * image == relocation information for kexec (ignored for unload) [in]
>   */
> -#define KEXEC_CMD_kexec_load            1
> -#define KEXEC_CMD_kexec_unload          2
> -typedef struct xen_kexec_load {
> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
> +typedef struct xen_kexec_load_v1 {
>      int type;
>      xen_kexec_image_t image;
> -} xen_kexec_load_t;
> +} xen_kexec_load_v1_t;

You can't change type names like this without also guarding them
with a __XEN_INTERFACE_VERSION__ conditional or providing
backward compatibility #define-s.

>  
>  #define KEXEC_RANGE_MA_CRASH      0 /* machine address and size of crash area */
>  #define KEXEC_RANGE_MA_XEN        1 /* machine address and size of Xen itself */
> @@ -152,6 +152,64 @@ typedef struct xen_kexec_range {
>      unsigned long start;
>  } xen_kexec_range_t;
>  
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040300
> +/*
> + * A contiguous chunk of a kexec image and it's destination machine
> + * address.
> + */
> +typedef struct xen_kexec_segment {
> +    XEN_GUEST_HANDLE_64(const_void) buf;
> +    uint64_t buf_size;
> +    uint64_t dest_maddr;
> +    uint64_t dest_size;
> +} xen_kexec_segment_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_segment_t);
> +
> +/*
> + * Load a kexec image into memory.
> + *
> + * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
> + * The image is relocated prior to being executed.
> + *
> + * For KEXEC_TYPE_CRASH images, each segment of the image must reside
> + * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
> + * the entry point must be within the image. The caller is responsible
> + * for ensuring that multiple images do not overlap.
> + */
> +
> +#define KEXEC_CMD_kexec_load 4
> +typedef struct xen_kexec_load {
> +    uint8_t  type;        /* One of KEXEC_TYPE_* */

uint8_t __pad1;

> +    uint16_t arch;        /* ELF machine type (EM_*). */
> +    uint32_t __pad;

Put nr_segments here instead?

> +    uint64_t entry_maddr; /* image entry point machine address. */
> +    uint32_t nr_segments;
> +    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
> +} xen_kexec_load_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:33:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8o3z-00068E-EH; Fri, 22 Feb 2013 08:33:03 +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 1U8o3y-000682-6O
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:33:02 +0000
Received: from [85.158.139.211:32527] by server-14.bemta-5.messagelabs.com id
	1D/66-06967-D3D27215; Fri, 22 Feb 2013 08:33:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361521980!18733477!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12601 invoked from network); 22 Feb 2013 08:33:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 08:33:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:33:00 +0000
Message-Id: <51273B8502000078000C03BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:33:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
> --- a/xen/include/public/kexec.h
> +++ b/xen/include/public/kexec.h
> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>   * image == relocation information for kexec (ignored for unload) [in]
>   */
> -#define KEXEC_CMD_kexec_load            1
> -#define KEXEC_CMD_kexec_unload          2
> -typedef struct xen_kexec_load {
> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
> +typedef struct xen_kexec_load_v1 {
>      int type;
>      xen_kexec_image_t image;
> -} xen_kexec_load_t;
> +} xen_kexec_load_v1_t;

You can't change type names like this without also guarding them
with a __XEN_INTERFACE_VERSION__ conditional or providing
backward compatibility #define-s.

>  
>  #define KEXEC_RANGE_MA_CRASH      0 /* machine address and size of crash area */
>  #define KEXEC_RANGE_MA_XEN        1 /* machine address and size of Xen itself */
> @@ -152,6 +152,64 @@ typedef struct xen_kexec_range {
>      unsigned long start;
>  } xen_kexec_range_t;
>  
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040300
> +/*
> + * A contiguous chunk of a kexec image and it's destination machine
> + * address.
> + */
> +typedef struct xen_kexec_segment {
> +    XEN_GUEST_HANDLE_64(const_void) buf;
> +    uint64_t buf_size;
> +    uint64_t dest_maddr;
> +    uint64_t dest_size;
> +} xen_kexec_segment_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_segment_t);
> +
> +/*
> + * Load a kexec image into memory.
> + *
> + * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
> + * The image is relocated prior to being executed.
> + *
> + * For KEXEC_TYPE_CRASH images, each segment of the image must reside
> + * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
> + * the entry point must be within the image. The caller is responsible
> + * for ensuring that multiple images do not overlap.
> + */
> +
> +#define KEXEC_CMD_kexec_load 4
> +typedef struct xen_kexec_load {
> +    uint8_t  type;        /* One of KEXEC_TYPE_* */

uint8_t __pad1;

> +    uint16_t arch;        /* ELF machine type (EM_*). */
> +    uint32_t __pad;

Put nr_segments here instead?

> +    uint64_t entry_maddr; /* image entry point machine address. */
> +    uint32_t nr_segments;
> +    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
> +} xen_kexec_load_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:34:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:34: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 1U8o58-0006DE-V1; Fri, 22 Feb 2013 08:34: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 1U8o58-0006D3-2P
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 08:34:14 +0000
Received: from [85.158.143.99:16813] by server-1.bemta-4.messagelabs.com id
	16/46-06203-58D27215; Fri, 22 Feb 2013 08:34:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361521940!17232755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12095 invoked from network); 22 Feb 2013 08:32:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:32:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1770422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:32: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.297.1;
	Fri, 22 Feb 2013 08:32:20 +0000
Message-ID: <1361521938.26546.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Ian
	Jackson" <Ian.Jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 08:32:18 +0000
In-Reply-To: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
References: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [Xen-staging] [xen] x86/mm: Take the p2m lock even
 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

Ian, 

I suppose this came from the commit bot on the xen.git tree? Could we
get the branch added to the Subject (e.g. [xen staging] / [xen
staging/4.2] etc). If it could include the committer as well as the
author in the metadata that might be useful too.

Cheers,
Ian.

On Thu, 2013-02-21 at 19:12 +0000, patchbot@xen.org wrote:
> commit a15d87475ed95840dba693ab0a56d0b48a215cbc
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 21 14:07:19 2013 +0000
> 
>     x86/mm: Take the p2m lock even in shadow mode.
>     
>     The reworking of p2m lookups to use get_gfn()/put_gfn() left the
>     shadow code not taking the p2m lock, even in cases where the p2m would
>     be updated (i.e. PoD).
>     
>     In many cases, shadow code doesn't need the exclusion that
>     get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
>     updates, but this is taking things too far, and can lead to crashes in
>     the PoD code.
>     
>     Now that most shadow-code p2m lookups are done with explicitly
>     unlocked accessors, or with the get_page_from_gfn() accessor, which is
>     often lock-free, we can just turn this locking on.
>     
>     The remaining locked lookups are in sh_page_fault() (in a path that's
>     almost always already serializing on the paging lock), and in
>     emulate_map_dest() (which can probably be updated to use
>     get_page_from_gfn()).  They're not addressed here but may be in a
>     follow-up patch.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>
>     Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> ---
>  xen/arch/x86/mm/p2m.c |    6 ++----
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index de1dd82..2db73c9 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -218,8 +218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
>          return _mfn(gfn);
>      }
>  
> -    /* 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);
>  
> @@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
>  
>  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;
>  
> --
> generated by git-patchbot for /home/xen/git/xen.git#staging
> 
> _______________________________________________
> 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 Fri Feb 22 08:34:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:34: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 1U8o58-0006DE-V1; Fri, 22 Feb 2013 08:34: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 1U8o58-0006D3-2P
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 08:34:14 +0000
Received: from [85.158.143.99:16813] by server-1.bemta-4.messagelabs.com id
	16/46-06203-58D27215; Fri, 22 Feb 2013 08:34:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361521940!17232755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12095 invoked from network); 22 Feb 2013 08:32:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:32:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1770422"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:32: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.297.1;
	Fri, 22 Feb 2013 08:32:20 +0000
Message-ID: <1361521938.26546.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Ian
	Jackson" <Ian.Jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 08:32:18 +0000
In-Reply-To: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
References: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [Xen-staging] [xen] x86/mm: Take the p2m lock even
 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

Ian, 

I suppose this came from the commit bot on the xen.git tree? Could we
get the branch added to the Subject (e.g. [xen staging] / [xen
staging/4.2] etc). If it could include the committer as well as the
author in the metadata that might be useful too.

Cheers,
Ian.

On Thu, 2013-02-21 at 19:12 +0000, patchbot@xen.org wrote:
> commit a15d87475ed95840dba693ab0a56d0b48a215cbc
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 21 14:07:19 2013 +0000
> 
>     x86/mm: Take the p2m lock even in shadow mode.
>     
>     The reworking of p2m lookups to use get_gfn()/put_gfn() left the
>     shadow code not taking the p2m lock, even in cases where the p2m would
>     be updated (i.e. PoD).
>     
>     In many cases, shadow code doesn't need the exclusion that
>     get_gfn()/put_gfn() provides, as it has its own interlocks against p2m
>     updates, but this is taking things too far, and can lead to crashes in
>     the PoD code.
>     
>     Now that most shadow-code p2m lookups are done with explicitly
>     unlocked accessors, or with the get_page_from_gfn() accessor, which is
>     often lock-free, we can just turn this locking on.
>     
>     The remaining locked lookups are in sh_page_fault() (in a path that's
>     almost always already serializing on the paging lock), and in
>     emulate_map_dest() (which can probably be updated to use
>     get_page_from_gfn()).  They're not addressed here but may be in a
>     follow-up patch.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>
>     Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> ---
>  xen/arch/x86/mm/p2m.c |    6 ++----
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index de1dd82..2db73c9 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -218,8 +218,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
>          return _mfn(gfn);
>      }
>  
> -    /* 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);
>  
> @@ -248,8 +247,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
>  
>  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;
>  
> --
> generated by git-patchbot for /home/xen/git/xen.git#staging
> 
> _______________________________________________
> 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 Fri Feb 22 08:42:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:42: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 1U8oCc-0006jB-Ns; Fri, 22 Feb 2013 08:41:58 +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 1U8oCb-0006j6-FS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:41:57 +0000
Received: from [85.158.139.83:34084] by server-3.bemta-5.messagelabs.com id
	FE/6E-07037-45F27215; Fri, 22 Feb 2013 08:41:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361522515!25697497!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2809 invoked from network); 22 Feb 2013 08:41:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 08:41:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:41:55 +0000
Message-Id: <51273D9D02000078000C03D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:42:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
 load/unload 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>
Content-Type: text/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.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
> Crash images are copied directly into the crash region on load.
> Default images are copied into Xen heap pages and a list of source and
> destination machine addresses is created.  This is list is used in
> kexec_reloc() to relocate the image to its destination.

Did you carefully consider the implications of using Xen heap pages
here as opposed to domain heap ones? On huge systems, this may
prevent kexec from working, as you're not just trying to allocate a
handful of pages. IOW, is the less complex code really worth the
increased likelihood of a failure here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:42:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:42: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 1U8oCc-0006jB-Ns; Fri, 22 Feb 2013 08:41:58 +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 1U8oCb-0006j6-FS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:41:57 +0000
Received: from [85.158.139.83:34084] by server-3.bemta-5.messagelabs.com id
	FE/6E-07037-45F27215; Fri, 22 Feb 2013 08:41:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361522515!25697497!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2809 invoked from network); 22 Feb 2013 08:41:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 08:41:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:41:55 +0000
Message-Id: <51273D9D02000078000C03D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:42:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
 load/unload 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>
Content-Type: text/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.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
> Crash images are copied directly into the crash region on load.
> Default images are copied into Xen heap pages and a list of source and
> destination machine addresses is created.  This is list is used in
> kexec_reloc() to relocate the image to its destination.

Did you carefully consider the implications of using Xen heap pages
here as opposed to domain heap ones? On huge systems, this may
prevent kexec from working, as you're not just trying to allocate a
handful of pages. IOW, is the less complex code really worth the
increased likelihood of a failure here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:47:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:47: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 1U8oHz-00079z-5M; Fri, 22 Feb 2013 08:47:31 +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 1U8oHy-00079r-As
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:47:30 +0000
Received: from [193.109.254.147:46627] by server-10.bemta-14.messagelabs.com
	id B9/CE-12679-1A037215; Fri, 22 Feb 2013 08:47:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361522848!9142556!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1044 invoked from network); 22 Feb 2013 08:47:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 08:47:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:47:25 +0000
Message-Id: <51273EE602000078000C03DC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:48:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
	<1361521720.26546.93.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361521720.26546.93.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir\(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
>> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> >> On ARM we want these to be the same size on 32- and 64-bit.
>> >> 
>> >> This is an ABI change on ARM. X86 does not change.
>> >> 
>> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> >> Cc: Jan Beulich <JBeulich@suse.com>
>> >> Cc: Keir (Xen.org) <keir@xen.org>
>> > 
>> > Are you guys (un)happy with this change from the Xen & x86 side?
>> 
>> I don't see any problem with it.
> 
> I'll take this as an Acked-by if that's ok with you.

Well, I specifically didn't say "ack": I don't really mind the change,
but I'm also not eager see it go in. Not seeing a problem with it
doesn't really mean there's none lurking - type changes in public
interfaces are always an at least slightly risky business.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:47:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:47: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 1U8oHz-00079z-5M; Fri, 22 Feb 2013 08:47:31 +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 1U8oHy-00079r-As
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:47:30 +0000
Received: from [193.109.254.147:46627] by server-10.bemta-14.messagelabs.com
	id B9/CE-12679-1A037215; Fri, 22 Feb 2013 08:47:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361522848!9142556!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1044 invoked from network); 22 Feb 2013 08:47:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 08:47:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 08:47:25 +0000
Message-Id: <51273EE602000078000C03DC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 08:48:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
	<1361521720.26546.93.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361521720.26546.93.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir\(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
>> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> >> On ARM we want these to be the same size on 32- and 64-bit.
>> >> 
>> >> This is an ABI change on ARM. X86 does not change.
>> >> 
>> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> >> Cc: Jan Beulich <JBeulich@suse.com>
>> >> Cc: Keir (Xen.org) <keir@xen.org>
>> > 
>> > Are you guys (un)happy with this change from the Xen & x86 side?
>> 
>> I don't see any problem with it.
> 
> I'll take this as an Acked-by if that's ok with you.

Well, I specifically didn't say "ack": I don't really mind the change,
but I'm also not eager see it go in. Not seeing a problem with it
doesn't really mean there's none lurking - type changes in public
interfaces are always an at least slightly risky business.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:51:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8oLR-0007Vm-75; Fri, 22 Feb 2013 08:51: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 1U8oLP-0007UX-Gy
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:51:03 +0000
Received: from [85.158.143.99:9730] by server-1.bemta-4.messagelabs.com id
	6B/87-06203-67137215; Fri, 22 Feb 2013 08:51:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361523053!28651748!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4447 invoked from network); 22 Feb 2013 08:50:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1771003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08: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.297.1;
	Fri, 22 Feb 2013 08:50:52 +0000
Message-ID: <1361523051.26546.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Fri, 22 Feb 2013 08:50:51 +0000
In-Reply-To: <1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 16:13 +0000, Frediano Ziglio wrote:
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 410d7db..50e0c4b 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -84,6 +84,13 @@ SECTIONS
>         *(.init.data)
>         *(.init.data.rel)
>         *(.init.data.rel.*)
> +
> +       . = ALIGN(4);
> +       __CTOR_LIST__ = .;
> +       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> +       *(.ctors)
> +       LONG(0)
> +       __CTOR_END__ = .;
>    } :text
>    . = ALIGN(32);
>    .init.setup : { 


This broke my 64-bit branch (not your fault, it's not merged yet, but I
was planning to commit it shortly):
        prelink.o: In function `init_constructors':
        /local/scratch/ianc/devel/arm/xen.git/xen/common/lib.c:491:(.init.text+0xc44): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `__CTOR_LIST__' defined in .init.data section in /local/scratch/ianc/devel/arm/xen.git/xen/.xen-arm64-syms.0
        
To fixup I intend to add the following to my "xen: arm64: initial build
+ config changes, start of day code".

Xen doesn't have a xen/xen.lds.h header, but perhaps adding that and
using it to define common things like this as macros might be an
interesting future cleanup.

8<--------------------------------------

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9043994..5136b79 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -91,9 +91,9 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
-       . = ALIGN(4);
+       . = ALIGN(BYTES_PER_LONG);
        __CTOR_LIST__ = .;
-       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
        *(.ctors)
        LONG(0)
        __CTOR_END__ = .;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:51:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8oLR-0007Vm-75; Fri, 22 Feb 2013 08:51: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 1U8oLP-0007UX-Gy
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:51:03 +0000
Received: from [85.158.143.99:9730] by server-1.bemta-4.messagelabs.com id
	6B/87-06203-67137215; Fri, 22 Feb 2013 08:51:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361523053!28651748!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4447 invoked from network); 22 Feb 2013 08:50:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1771003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08: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.297.1;
	Fri, 22 Feb 2013 08:50:52 +0000
Message-ID: <1361523051.26546.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Fri, 22 Feb 2013 08:50:51 +0000
In-Reply-To: <1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-21 at 16:13 +0000, Frediano Ziglio wrote:
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 410d7db..50e0c4b 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -84,6 +84,13 @@ SECTIONS
>         *(.init.data)
>         *(.init.data.rel)
>         *(.init.data.rel.*)
> +
> +       . = ALIGN(4);
> +       __CTOR_LIST__ = .;
> +       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> +       *(.ctors)
> +       LONG(0)
> +       __CTOR_END__ = .;
>    } :text
>    . = ALIGN(32);
>    .init.setup : { 


This broke my 64-bit branch (not your fault, it's not merged yet, but I
was planning to commit it shortly):
        prelink.o: In function `init_constructors':
        /local/scratch/ianc/devel/arm/xen.git/xen/common/lib.c:491:(.init.text+0xc44): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `__CTOR_LIST__' defined in .init.data section in /local/scratch/ianc/devel/arm/xen.git/xen/.xen-arm64-syms.0
        
To fixup I intend to add the following to my "xen: arm64: initial build
+ config changes, start of day code".

Xen doesn't have a xen/xen.lds.h header, but perhaps adding that and
using it to define common things like this as macros might be an
interesting future cleanup.

8<--------------------------------------

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9043994..5136b79 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -91,9 +91,9 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
-       . = ALIGN(4);
+       . = ALIGN(BYTES_PER_LONG);
        __CTOR_LIST__ = .;
-       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
        *(.ctors)
        LONG(0)
        __CTOR_END__ = .;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:55:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8oPX-0007lv-U7; Fri, 22 Feb 2013 08:55:19 +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 1U8oPW-0007lq-Gh
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:55:18 +0000
Received: from [85.158.138.51:35676] by server-13.bemta-3.messagelabs.com id
	CB/73-20653-57237215; Fri, 22 Feb 2013 08:55:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361523315!22343205!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18355 invoked from network); 22 Feb 2013 08:55:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:55:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1771174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:55: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.297.1;
	Fri, 22 Feb 2013 08:55:15 +0000
Message-ID: <1361523313.26546.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 08:55:13 +0000
In-Reply-To: <51273EE602000078000C03DC@nat28.tlf.novell.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
	<1361521720.26546.93.camel@zakaz.uk.xensource.com>
	<51273EE602000078000C03DC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 08:48 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 09:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
> >> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> >> >> On ARM we want these to be the same size on 32- and 64-bit.
> >> >> 
> >> >> This is an ABI change on ARM. X86 does not change.
> >> >> 
> >> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> >> Cc: Jan Beulich <JBeulich@suse.com>
> >> >> Cc: Keir (Xen.org) <keir@xen.org>
> >> > 
> >> > Are you guys (un)happy with this change from the Xen & x86 side?
> >> 
> >> I don't see any problem with it.
> > 
> > I'll take this as an Acked-by if that's ok with you.
> 
> Well, I specifically didn't say "ack": I don't really mind the change,
> but I'm also not eager see it go in. Not seeing a problem with it
> doesn't really mean there's none lurking - type changes in public
> interfaces are always an at least slightly risky business.

For x86 there is no change here since:
xen/include/public/arch-x86/xen.h:typedef unsigned long xen_ulong_t;

Also the tools/include/xen-foreign checks show no change in the size of
things on x86.

On ARM the change is deliberate, if there is any fallout we can fix 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 Feb 22 08:55:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08: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 1U8oPX-0007lv-U7; Fri, 22 Feb 2013 08:55:19 +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 1U8oPW-0007lq-Gh
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:55:18 +0000
Received: from [85.158.138.51:35676] by server-13.bemta-3.messagelabs.com id
	CB/73-20653-57237215; Fri, 22 Feb 2013 08:55:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361523315!22343205!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18355 invoked from network); 22 Feb 2013 08:55:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:55:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1771174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:55: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.297.1;
	Fri, 22 Feb 2013 08:55:15 +0000
Message-ID: <1361523313.26546.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 08:55:13 +0000
In-Reply-To: <51273EE602000078000C03DC@nat28.tlf.novell.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
	<1361521720.26546.93.camel@zakaz.uk.xensource.com>
	<51273EE602000078000C03DC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 08:48 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 09:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
> >> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
> >> >> On ARM we want these to be the same size on 32- and 64-bit.
> >> >> 
> >> >> This is an ABI change on ARM. X86 does not change.
> >> >> 
> >> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >> >> Cc: Jan Beulich <JBeulich@suse.com>
> >> >> Cc: Keir (Xen.org) <keir@xen.org>
> >> > 
> >> > Are you guys (un)happy with this change from the Xen & x86 side?
> >> 
> >> I don't see any problem with it.
> > 
> > I'll take this as an Acked-by if that's ok with you.
> 
> Well, I specifically didn't say "ack": I don't really mind the change,
> but I'm also not eager see it go in. Not seeing a problem with it
> doesn't really mean there's none lurking - type changes in public
> interfaces are always an at least slightly risky business.

For x86 there is no change here since:
xen/include/public/arch-x86/xen.h:typedef unsigned long xen_ulong_t;

Also the tools/include/xen-foreign checks show no change in the size of
things on x86.

On ARM the change is deliberate, if there is any fallout we can fix 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 Feb 22 08:58:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:58: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 1U8oS1-0007xi-Qg; Fri, 22 Feb 2013 08:57:53 +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 1U8oS0-0007xZ-Ty
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:57:53 +0000
Received: from [85.158.139.211:43936] by server-16.bemta-5.messagelabs.com id
	FF/D7-14948-01337215; Fri, 22 Feb 2013 08:57:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361523471!18732645!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13912 invoked from network); 22 Feb 2013 08:57:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-206.messagelabs.com with SMTP;
	22 Feb 2013 08:57:51 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (jored mo12) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N00488p1M80nGi ;
	Fri, 22 Feb 2013 09:57:46 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 58B5A1884C; Fri, 22 Feb 2013 09:57:45 +0100 (CET)
Date: Fri, 22 Feb 2013 09:57:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222085745.GA10325@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
	<51272F8902000078000C0361@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51272F8902000078000C0361@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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, Feb 22, Jan Beulich wrote:

> And that's without paging or anything similar? Else I would expect
> the problem to be in the interaction there. But I'll also take a look
> at the grant table code assuming this is a problem even without
> any enhanced memory management functionality...

Nothing like this is enabled.


name="domU"
description="something"
uuid="a062cabb-5981-4472-9d3b-da7bd8e2594e"
memory=512
vcpus=2
serial="pty"
builder="hvm"
boot="dcn"
disk=[
        'file:/some/vdisk0,hda,w',
]
vif=[
        'bridge=br0,model=rtl8139,type=netfront'
]
vfb = [
        'type=vnc,vncunused=1,keymap=de'
]
on_crash="preserve"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 08:58:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 08:58: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 1U8oS1-0007xi-Qg; Fri, 22 Feb 2013 08:57:53 +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 1U8oS0-0007xZ-Ty
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:57:53 +0000
Received: from [85.158.139.211:43936] by server-16.bemta-5.messagelabs.com id
	FF/D7-14948-01337215; Fri, 22 Feb 2013 08:57:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361523471!18732645!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13912 invoked from network); 22 Feb 2013 08:57:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-206.messagelabs.com with SMTP;
	22 Feb 2013 08:57:51 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (jored mo12) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N00488p1M80nGi ;
	Fri, 22 Feb 2013 09:57:46 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 58B5A1884C; Fri, 22 Feb 2013 09:57:45 +0100 (CET)
Date: Fri, 22 Feb 2013 09:57:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222085745.GA10325@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
	<51272F8902000078000C0361@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51272F8902000078000C0361@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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, Feb 22, Jan Beulich wrote:

> And that's without paging or anything similar? Else I would expect
> the problem to be in the interaction there. But I'll also take a look
> at the grant table code assuming this is a problem even without
> any enhanced memory management functionality...

Nothing like this is enabled.


name="domU"
description="something"
uuid="a062cabb-5981-4472-9d3b-da7bd8e2594e"
memory=512
vcpus=2
serial="pty"
builder="hvm"
boot="dcn"
disk=[
        'file:/some/vdisk0,hda,w',
]
vif=[
        'bridge=br0,model=rtl8139,type=netfront'
]
vfb = [
        'type=vnc,vncunused=1,keymap=de'
]
on_crash="preserve"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTz-00089n-6E; Fri, 22 Feb 2013 08:59:55 +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 1U8oTx-00088V-0G
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:53 +0000
Received: from [85.158.138.51:38081] by server-13.bemta-3.messagelabs.com id
	C3/DA-20653-88337215; Fri, 22 Feb 2013 08:59:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361523583!19798843!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29805 invoked from network); 22 Feb 2013 08:59:48 -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;
	22 Feb 2013 08:59:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955724"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-4s;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:45 +0000
Message-ID: <1361523505-7604-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 06/46] xen: arm64: basic config and types
	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

The 64-bit bitops are taken from the Linux asm-generic implementations. They
should be replaced with optimised versions from the Linux arm64 port when they
become available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: mention bitops heritage.
---
 xen/arch/arm/arm64/Makefile            |    2 +
 xen/arch/arm/arm64/lib/Makefile        |    1 +
 xen/arch/arm/arm64/lib/bitops.c        |   22 +++
 xen/arch/arm/arm64/lib/find_next_bit.c |  284 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm32/bitops.h     |   54 ++++++
 xen/include/asm-arm/arm64/bitops.h     |  283 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h           |   65 ++------
 xen/include/asm-arm/config.h           |   15 ++
 xen/include/asm-arm/types.h            |   17 ++-
 9 files changed, 686 insertions(+), 57 deletions(-)
 create mode 100644 xen/arch/arm/arm64/lib/Makefile
 create mode 100644 xen/arch/arm/arm64/lib/bitops.c
 create mode 100644 xen/arch/arm/arm64/lib/find_next_bit.c
 create mode 100644 xen/include/asm-arm/arm32/bitops.h
 create mode 100644 xen/include/asm-arm/arm64/bitops.h

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index dffbeb1..c447eaa 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1 +1,3 @@
+subdir-y += lib
+
 obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/lib/Makefile b/xen/arch/arm/arm64/lib/Makefile
new file mode 100644
index 0000000..32c02c4
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/Makefile
@@ -0,0 +1 @@
+obj-y += bitops.o find_next_bit.o
diff --git a/xen/arch/arm/arm64/lib/bitops.c b/xen/arch/arm/arm64/lib/bitops.c
new file mode 100644
index 0000000..02d8d78
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/bitops.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 ARM Limited
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/spinlock.h>
+#include <xen/bitops.h>
+
+spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] /*__lock_aligned*/ = {
+       [0 ... (ATOMIC_HASH_SIZE-1)]  = SPIN_LOCK_UNLOCKED
+};
diff --git a/xen/arch/arm/arm64/lib/find_next_bit.c b/xen/arch/arm/arm64/lib/find_next_bit.c
new file mode 100644
index 0000000..aea69c2
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/find_next_bit.c
@@ -0,0 +1,284 @@
+/* find_next_bit.c: fallback find next bit implementation
+ *
+ * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * 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 of the License, or (at your option) any later version.
+ */
+#include <xen/config.h>
+#include <xen/bitops.h>
+#include <asm/types.h>
+#include <asm/byteorder.h>
+
+#define BITOP_WORD(nr)		((nr) / BITS_PER_LONG)
+
+#ifndef find_next_bit
+/*
+ * Find the next set bit in a memory region.
+ */
+unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
+			    unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_next_bit);
+#endif
+
+#ifndef find_next_zero_bit
+/*
+ * This implementation of find_{first,next}_zero_bit was stolen from
+ * Linus' asm-alpha/bitops.h.
+ */
+unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
+				 unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp |= ~0UL >> (BITS_PER_LONG - offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_next_zero_bit);
+#endif
+
+#ifndef find_first_bit
+/*
+ * Find the first set bit in a memory region.
+ */
+unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) & (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_first_bit);
+#endif
+
+#ifndef find_first_zero_bit
+/*
+ * Find the first cleared bit in a memory region.
+ */
+unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) | (~0UL << size);
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_first_zero_bit);
+#endif
+
+#ifdef __BIG_ENDIAN
+
+/* include/linux/byteorder does not support "unsigned long" type */
+static inline unsigned long ext2_swabp(const unsigned long * x)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64p((u64 *) x);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32p((u32 *) x);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+/* include/linux/byteorder doesn't support "unsigned long" type */
+static inline unsigned long ext2_swab(const unsigned long y)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64((u64) y);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32((u32) y);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+#ifndef find_next_zero_bit_le
+unsigned long find_next_zero_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp |= (~0UL >> (BITS_PER_LONG - offset));
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size; /* Nope. Skip ffz */
+found_middle:
+	return result + ffz(tmp);
+
+found_middle_swap:
+	return result + ffz(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_zero_bit_le);
+#endif
+
+#ifndef find_next_bit_le
+unsigned long find_next_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		tmp = *(p++);
+		if (tmp)
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size; /* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+
+found_middle_swap:
+	return result + __ffs(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_bit_le);
+#endif
+
+#endif /* __BIG_ENDIAN */
diff --git a/xen/include/asm-arm/arm32/bitops.h b/xen/include/asm-arm/arm32/bitops.h
new file mode 100644
index 0000000..0d05258
--- /dev/null
+++ b/xen/include/asm-arm/arm32/bitops.h
@@ -0,0 +1,54 @@
+#ifndef _ARM_ARM32_BITOPS_H
+#define _ARM_ARM32_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+#endif /* _ARM_ARM32_BITOPS_H */
diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
new file mode 100644
index 0000000..847d65c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -0,0 +1,283 @@
+#ifndef _ARM_ARM64_BITOPS_H
+#define _ARM_ARM64_BITOPS_H
+
+/* Generic bitop support. Based on linux/include/asm-generic/bitops/atomic.h */
+
+#include <xen/spinlock.h>
+#include <xen/cache.h>          /* we use L1_CACHE_BYTES */
+
+/* Use an array of spinlocks for our atomic_ts.
+ * Hash function to index into a different SPINLOCK.
+ * Since "a" is usually an address, use one spinlock per cacheline.
+ */
+#  define ATOMIC_HASH_SIZE 4
+#  define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) a)/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
+
+extern spinlock_t __atomic_hash[ATOMIC_HASH_SIZE]/* __lock_aligned*/;
+
+#define _atomic_spin_lock_irqsave(l,f) do {     \
+       spinlock_t *s = ATOMIC_HASH(l);          \
+       spin_lock_irqsave(s, f);\
+} while(0)
+
+#define _atomic_spin_unlock_irqrestore(l,f) do {\
+        spinlock_t *s = ATOMIC_HASH(l);         \
+        spin_unlock_irqrestore(s,f);		\
+} while(0)
+
+#define FIXUP(_p, _mask)                        \
+    {                                           \
+        unsigned long __p = (unsigned long)_p;  \
+        if (__p & 0x7) {                        \
+            if (_mask > 0xffffffff) {           \
+             __p = (__p+32)&~0x7; _mask >>=32;  \
+            } else {                            \
+                __p &= ~0x7; _mask <<= 32;      \
+            }                                   \
+            if (0)printk("BITOPS: Fixup misaligned ptr %p => %#lx\n", _p, __p); \
+            _p = (void *)__p;                   \
+        }                                       \
+    }
+
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * This function is atomic and may not be reordered.  See __set_bit()
+ * if you do not require the atomic guarantees.
+ *
+ * Note: there are no guarantees that this function will not be reordered
+ * on non x86 architectures, so if you are writing portable code,
+ * make sure not to rely on its reordering guarantees.
+ *
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+
+static inline void set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        FIXUP(p, mask);
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        //printk("before *p is %#lx\n", *p);
+	_atomic_spin_lock_irqsave(p, flags);
+	*p  |= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+        //printk(" after *p is %#lx\n", *p);
+}
+
+/**
+ * clear_bit - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and may not be reordered.  However, it does
+ * not contain a memory barrier, so if it is used for locking purposes,
+ * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * in order to ensure changes are visible on other processors.
+ */
+static inline void clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p &= ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * change_bit - Toggle a bit in memory
+ * @nr: Bit to change
+ * @addr: Address to start counting from
+ *
+ * change_bit() is atomic and may not be reordered. It may be
+ * reordered on other architectures than x86.
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+static inline void change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p ^= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It may be reordered on other architectures than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old | mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It can be reorderdered on other architectures other than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old & ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_change_bit - Change a bit and return its old value
+ * @nr: Bit to change
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old ^ mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
+/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static /*__*/always_inline unsigned long __ffs(unsigned long word)
+{
+        return __builtin_ctzl(word);
+}
+
+/* Based on linux/include/asm-generic/bitops/ffz.h */
+/*
+ * ffz - find first zero in word.
+ * @word: The word to search
+ *
+ * Undefined if no zero exists, so code should check against ~0UL first.
+ */
+#define ffz(x)  __ffs(~(x))
+
+
+
+/* Based on linux/include/asm-generic/bitops/find.h */
+
+#ifndef find_next_bit
+/**
+ * find_next_bit - find the next set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
+		size, unsigned long offset);
+#endif
+
+#ifndef find_next_zero_bit
+/**
+ * find_next_zero_bit - find the next cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
+		long size, unsigned long offset);
+#endif
+
+#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
+
+/**
+ * find_first_bit - find the first set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first set bit.
+ */
+extern unsigned long find_first_bit(const unsigned long *addr,
+				    unsigned long size);
+
+/**
+ * find_first_zero_bit - find the first cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first cleared bit.
+ */
+extern unsigned long find_first_zero_bit(const unsigned long *addr,
+					 unsigned long size);
+#else /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
+#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 0)
+
+#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+
+#endif /* _ARM_ARM64_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
index 0d8ac9a..0a7caee 100644
--- a/xen/include/asm-arm/bitops.h
+++ b/xen/include/asm-arm/bitops.h
@@ -9,28 +9,14 @@
 #ifndef _ARM_BITOPS_H
 #define _ARM_BITOPS_H
 
-extern void _set_bit(int nr, volatile void * p);
-extern void _clear_bit(int nr, volatile void * p);
-extern void _change_bit(int nr, volatile void * p);
-extern int _test_and_set_bit(int nr, volatile void * p);
-extern int _test_and_clear_bit(int nr, volatile void * p);
-extern int _test_and_change_bit(int nr, volatile void * p);
-
-#define set_bit(n,p)              _set_bit(n,p)
-#define clear_bit(n,p)            _clear_bit(n,p)
-#define change_bit(n,p)           _change_bit(n,p)
-#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
-#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
-#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
-
 /*
  * Non-atomic bit manipulation.
  *
  * Implemented using atomics to be interrupt safe. Could alternatively
  * implement with local interrupt masking.
  */
-#define __set_bit(n,p)            _set_bit(n,p)
-#define __clear_bit(n,p)          _clear_bit(n,p)
+#define __set_bit(n,p)            set_bit(n,p)
+#define __clear_bit(n,p)          clear_bit(n,p)
 
 #define BIT(nr)                 (1UL << (nr))
 #define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
@@ -40,6 +26,14 @@ extern int _test_and_change_bit(int nr, volatile void * p);
 #define ADDR (*(volatile long *) addr)
 #define CONST_ADDR (*(const volatile long *) addr)
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/bitops.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/bitops.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /**
  * __test_and_set_bit - Set a bit and return its old value
  * @nr: Bit to set
@@ -104,42 +98,6 @@ static inline int test_bit(int nr, const volatile void *addr)
         return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
 }
 
-/*
- * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
- */
-extern int _find_first_zero_bit_le(const void * p, unsigned size);
-extern int _find_next_zero_bit_le(const void * p, int size, int offset);
-extern int _find_first_bit_le(const unsigned long *p, unsigned size);
-extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
-
-/*
- * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
- */
-extern int _find_first_zero_bit_be(const void * p, unsigned size);
-extern int _find_next_zero_bit_be(const void * p, int size, int offset);
-extern int _find_first_bit_be(const unsigned long *p, unsigned size);
-extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
-
-#ifndef __ARMEB__
-/*
- * These are the little endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
-
-#else
-/*
- * These are the big endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
-
-#endif
-
 static inline int constant_fls(int x)
 {
         int r = 32;
@@ -182,10 +140,11 @@ static inline int fls(int x)
                return constant_fls(x);
 
         asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
-        ret = 32 - ret;
+        ret = BITS_PER_LONG - ret;
         return ret;
 }
 
+
 #define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
 
 /**
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 5a1ea1d..3910dd2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -7,6 +7,21 @@
 #ifndef __ARM_CONFIG_H__
 #define __ARM_CONFIG_H__
 
+#if defined(__aarch64__)
+# define CONFIG_ARM_64 1
+#elif defined(__arm__)
+# define CONFIG_ARM_32 1
+#endif
+
+#if defined(CONFIG_ARM_64)
+# define LONG_BYTEORDER 3
+#else
+# define LONG_BYTEORDER 2
+#endif
+
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
+#define BITS_PER_LONG (BYTES_PER_LONG << 3)
+
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 19231ef..3f6317b 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -15,8 +15,13 @@ typedef __signed__ int __s32;
 typedef unsigned int __u32;
 
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#if defined(CONFIG_ARM_32)
 typedef __signed__ long long __s64;
 typedef unsigned long long __u64;
+#elif defined (CONFIG_ARM_64)
+typedef __signed__ long __s64;
+typedef unsigned long __u64;
+#endif
 #endif
 
 typedef signed char s8;
@@ -28,11 +33,19 @@ typedef unsigned short u16;
 typedef signed int s32;
 typedef unsigned int u32;
 
+#if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+#elif defined (CONFIG_ARM_64)
+typedef signed long s64;
+typedef unsigned long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "016lx"
+#endif
 
 typedef unsigned long size_t;
 
@@ -42,10 +55,6 @@ typedef char bool_t;
 
 #endif /* __ASSEMBLY__ */
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
-#define LONG_BYTEORDER 2
-
 #endif /* __ARM_TYPES_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTz-00089n-6E; Fri, 22 Feb 2013 08:59:55 +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 1U8oTx-00088V-0G
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:53 +0000
Received: from [85.158.138.51:38081] by server-13.bemta-3.messagelabs.com id
	C3/DA-20653-88337215; Fri, 22 Feb 2013 08:59:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361523583!19798843!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29805 invoked from network); 22 Feb 2013 08:59:48 -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;
	22 Feb 2013 08:59:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955724"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-4s;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:45 +0000
Message-ID: <1361523505-7604-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 06/46] xen: arm64: basic config and types
	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

The 64-bit bitops are taken from the Linux asm-generic implementations. They
should be replaced with optimised versions from the Linux arm64 port when they
become available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: mention bitops heritage.
---
 xen/arch/arm/arm64/Makefile            |    2 +
 xen/arch/arm/arm64/lib/Makefile        |    1 +
 xen/arch/arm/arm64/lib/bitops.c        |   22 +++
 xen/arch/arm/arm64/lib/find_next_bit.c |  284 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm32/bitops.h     |   54 ++++++
 xen/include/asm-arm/arm64/bitops.h     |  283 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h           |   65 ++------
 xen/include/asm-arm/config.h           |   15 ++
 xen/include/asm-arm/types.h            |   17 ++-
 9 files changed, 686 insertions(+), 57 deletions(-)
 create mode 100644 xen/arch/arm/arm64/lib/Makefile
 create mode 100644 xen/arch/arm/arm64/lib/bitops.c
 create mode 100644 xen/arch/arm/arm64/lib/find_next_bit.c
 create mode 100644 xen/include/asm-arm/arm32/bitops.h
 create mode 100644 xen/include/asm-arm/arm64/bitops.h

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index dffbeb1..c447eaa 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1 +1,3 @@
+subdir-y += lib
+
 obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/lib/Makefile b/xen/arch/arm/arm64/lib/Makefile
new file mode 100644
index 0000000..32c02c4
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/Makefile
@@ -0,0 +1 @@
+obj-y += bitops.o find_next_bit.o
diff --git a/xen/arch/arm/arm64/lib/bitops.c b/xen/arch/arm/arm64/lib/bitops.c
new file mode 100644
index 0000000..02d8d78
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/bitops.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 ARM Limited
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/spinlock.h>
+#include <xen/bitops.h>
+
+spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] /*__lock_aligned*/ = {
+       [0 ... (ATOMIC_HASH_SIZE-1)]  = SPIN_LOCK_UNLOCKED
+};
diff --git a/xen/arch/arm/arm64/lib/find_next_bit.c b/xen/arch/arm/arm64/lib/find_next_bit.c
new file mode 100644
index 0000000..aea69c2
--- /dev/null
+++ b/xen/arch/arm/arm64/lib/find_next_bit.c
@@ -0,0 +1,284 @@
+/* find_next_bit.c: fallback find next bit implementation
+ *
+ * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * 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 of the License, or (at your option) any later version.
+ */
+#include <xen/config.h>
+#include <xen/bitops.h>
+#include <asm/types.h>
+#include <asm/byteorder.h>
+
+#define BITOP_WORD(nr)		((nr) / BITS_PER_LONG)
+
+#ifndef find_next_bit
+/*
+ * Find the next set bit in a memory region.
+ */
+unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
+			    unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_next_bit);
+#endif
+
+#ifndef find_next_zero_bit
+/*
+ * This implementation of find_{first,next}_zero_bit was stolen from
+ * Linus' asm-alpha/bitops.h.
+ */
+unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
+				 unsigned long offset)
+{
+	const unsigned long *p = addr + BITOP_WORD(offset);
+	unsigned long result = offset & ~(BITS_PER_LONG-1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	size -= result;
+	offset %= BITS_PER_LONG;
+	if (offset) {
+		tmp = *(p++);
+		tmp |= ~0UL >> (BITS_PER_LONG - offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = *p;
+
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found_middle:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_next_zero_bit);
+#endif
+
+#ifndef find_first_bit
+/*
+ * Find the first set bit in a memory region.
+ */
+unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if ((tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) & (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size;	/* Nope. */
+found:
+	return result + __ffs(tmp);
+}
+EXPORT_SYMBOL(find_first_bit);
+#endif
+
+#ifndef find_first_zero_bit
+/*
+ * Find the first cleared bit in a memory region.
+ */
+unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long size)
+{
+	const unsigned long *p = addr;
+	unsigned long result = 0;
+	unsigned long tmp;
+
+	while (size & ~(BITS_PER_LONG-1)) {
+		if (~(tmp = *(p++)))
+			goto found;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+
+	tmp = (*p) | (~0UL << size);
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size;	/* Nope. */
+found:
+	return result + ffz(tmp);
+}
+EXPORT_SYMBOL(find_first_zero_bit);
+#endif
+
+#ifdef __BIG_ENDIAN
+
+/* include/linux/byteorder does not support "unsigned long" type */
+static inline unsigned long ext2_swabp(const unsigned long * x)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64p((u64 *) x);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32p((u32 *) x);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+/* include/linux/byteorder doesn't support "unsigned long" type */
+static inline unsigned long ext2_swab(const unsigned long y)
+{
+#if BITS_PER_LONG == 64
+	return (unsigned long) __swab64((u64) y);
+#elif BITS_PER_LONG == 32
+	return (unsigned long) __swab32((u32) y);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+
+#ifndef find_next_zero_bit_le
+unsigned long find_next_zero_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp |= (~0UL >> (BITS_PER_LONG - offset));
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (~tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		if (~(tmp = *(p++)))
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp |= ~0UL << size;
+	if (tmp == ~0UL)	/* Are any bits zero? */
+		return result + size; /* Nope. Skip ffz */
+found_middle:
+	return result + ffz(tmp);
+
+found_middle_swap:
+	return result + ffz(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_zero_bit_le);
+#endif
+
+#ifndef find_next_bit_le
+unsigned long find_next_bit_le(const void *addr, unsigned
+		long size, unsigned long offset)
+{
+	const unsigned long *p = addr;
+	unsigned long result = offset & ~(BITS_PER_LONG - 1);
+	unsigned long tmp;
+
+	if (offset >= size)
+		return size;
+	p += BITOP_WORD(offset);
+	size -= result;
+	offset &= (BITS_PER_LONG - 1UL);
+	if (offset) {
+		tmp = ext2_swabp(p++);
+		tmp &= (~0UL << offset);
+		if (size < BITS_PER_LONG)
+			goto found_first;
+		if (tmp)
+			goto found_middle;
+		size -= BITS_PER_LONG;
+		result += BITS_PER_LONG;
+	}
+
+	while (size & ~(BITS_PER_LONG - 1)) {
+		tmp = *(p++);
+		if (tmp)
+			goto found_middle_swap;
+		result += BITS_PER_LONG;
+		size -= BITS_PER_LONG;
+	}
+	if (!size)
+		return result;
+	tmp = ext2_swabp(p);
+found_first:
+	tmp &= (~0UL >> (BITS_PER_LONG - size));
+	if (tmp == 0UL)		/* Are any bits set? */
+		return result + size; /* Nope. */
+found_middle:
+	return result + __ffs(tmp);
+
+found_middle_swap:
+	return result + __ffs(ext2_swab(tmp));
+}
+EXPORT_SYMBOL(find_next_bit_le);
+#endif
+
+#endif /* __BIG_ENDIAN */
diff --git a/xen/include/asm-arm/arm32/bitops.h b/xen/include/asm-arm/arm32/bitops.h
new file mode 100644
index 0000000..0d05258
--- /dev/null
+++ b/xen/include/asm-arm/arm32/bitops.h
@@ -0,0 +1,54 @@
+#ifndef _ARM_ARM32_BITOPS_H
+#define _ARM_ARM32_BITOPS_H
+
+extern void _set_bit(int nr, volatile void * p);
+extern void _clear_bit(int nr, volatile void * p);
+extern void _change_bit(int nr, volatile void * p);
+extern int _test_and_set_bit(int nr, volatile void * p);
+extern int _test_and_clear_bit(int nr, volatile void * p);
+extern int _test_and_change_bit(int nr, volatile void * p);
+
+#define set_bit(n,p)              _set_bit(n,p)
+#define clear_bit(n,p)            _clear_bit(n,p)
+#define change_bit(n,p)           _change_bit(n,p)
+#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
+#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
+#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+#endif /* _ARM_ARM32_BITOPS_H */
diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
new file mode 100644
index 0000000..847d65c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -0,0 +1,283 @@
+#ifndef _ARM_ARM64_BITOPS_H
+#define _ARM_ARM64_BITOPS_H
+
+/* Generic bitop support. Based on linux/include/asm-generic/bitops/atomic.h */
+
+#include <xen/spinlock.h>
+#include <xen/cache.h>          /* we use L1_CACHE_BYTES */
+
+/* Use an array of spinlocks for our atomic_ts.
+ * Hash function to index into a different SPINLOCK.
+ * Since "a" is usually an address, use one spinlock per cacheline.
+ */
+#  define ATOMIC_HASH_SIZE 4
+#  define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) a)/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
+
+extern spinlock_t __atomic_hash[ATOMIC_HASH_SIZE]/* __lock_aligned*/;
+
+#define _atomic_spin_lock_irqsave(l,f) do {     \
+       spinlock_t *s = ATOMIC_HASH(l);          \
+       spin_lock_irqsave(s, f);\
+} while(0)
+
+#define _atomic_spin_unlock_irqrestore(l,f) do {\
+        spinlock_t *s = ATOMIC_HASH(l);         \
+        spin_unlock_irqrestore(s,f);		\
+} while(0)
+
+#define FIXUP(_p, _mask)                        \
+    {                                           \
+        unsigned long __p = (unsigned long)_p;  \
+        if (__p & 0x7) {                        \
+            if (_mask > 0xffffffff) {           \
+             __p = (__p+32)&~0x7; _mask >>=32;  \
+            } else {                            \
+                __p &= ~0x7; _mask <<= 32;      \
+            }                                   \
+            if (0)printk("BITOPS: Fixup misaligned ptr %p => %#lx\n", _p, __p); \
+            _p = (void *)__p;                   \
+        }                                       \
+    }
+
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * This function is atomic and may not be reordered.  See __set_bit()
+ * if you do not require the atomic guarantees.
+ *
+ * Note: there are no guarantees that this function will not be reordered
+ * on non x86 architectures, so if you are writing portable code,
+ * make sure not to rely on its reordering guarantees.
+ *
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+
+static inline void set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        FIXUP(p, mask);
+        //printk("set_bit: nr %d addr %p mask %#lx p %p lock %p\n",
+        //       nr, addr, mask, p, ATOMIC_HASH(p));
+        //printk("before *p is %#lx\n", *p);
+	_atomic_spin_lock_irqsave(p, flags);
+	*p  |= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+        //printk(" after *p is %#lx\n", *p);
+}
+
+/**
+ * clear_bit - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and may not be reordered.  However, it does
+ * not contain a memory barrier, so if it is used for locking purposes,
+ * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * in order to ensure changes are visible on other processors.
+ */
+static inline void clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p &= ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * change_bit - Toggle a bit in memory
+ * @nr: Bit to change
+ * @addr: Address to start counting from
+ *
+ * change_bit() is atomic and may not be reordered. It may be
+ * reordered on other architectures than x86.
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
+static inline void change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	*p ^= mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+}
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It may be reordered on other architectures than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_set_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old | mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It can be reorderdered on other architectures other than x86.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_clear_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old & ~mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/**
+ * test_and_change_bit - Change a bit and return its old value
+ * @nr: Bit to change
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.
+ * It also implies a memory barrier.
+ */
+static inline int test_and_change_bit(int nr, volatile void *addr)
+{
+	unsigned long mask = BIT_MASK(nr);
+	unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+	unsigned long old;
+	unsigned long flags;
+
+        FIXUP(p, mask);
+
+	_atomic_spin_lock_irqsave(p, flags);
+	old = *p;
+	*p = old ^ mask;
+	_atomic_spin_unlock_irqrestore(p, flags);
+
+	return (old & mask) != 0;
+}
+
+/* Based on linux/include/asm-generic/bitops/builtin-__ffs.h */
+/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static /*__*/always_inline unsigned long __ffs(unsigned long word)
+{
+        return __builtin_ctzl(word);
+}
+
+/* Based on linux/include/asm-generic/bitops/ffz.h */
+/*
+ * ffz - find first zero in word.
+ * @word: The word to search
+ *
+ * Undefined if no zero exists, so code should check against ~0UL first.
+ */
+#define ffz(x)  __ffs(~(x))
+
+
+
+/* Based on linux/include/asm-generic/bitops/find.h */
+
+#ifndef find_next_bit
+/**
+ * find_next_bit - find the next set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
+		size, unsigned long offset);
+#endif
+
+#ifndef find_next_zero_bit
+/**
+ * find_next_zero_bit - find the next cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ */
+extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
+		long size, unsigned long offset);
+#endif
+
+#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
+
+/**
+ * find_first_bit - find the first set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first set bit.
+ */
+extern unsigned long find_first_bit(const unsigned long *addr,
+				    unsigned long size);
+
+/**
+ * find_first_zero_bit - find the first cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum size to search
+ *
+ * Returns the bit number of the first cleared bit.
+ */
+extern unsigned long find_first_zero_bit(const unsigned long *addr,
+					 unsigned long size);
+#else /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
+#define find_first_zero_bit(addr, size) find_next_zero_bit((addr), (size), 0)
+
+#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+
+
+#endif /* _ARM_ARM64_BITOPS_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
index 0d8ac9a..0a7caee 100644
--- a/xen/include/asm-arm/bitops.h
+++ b/xen/include/asm-arm/bitops.h
@@ -9,28 +9,14 @@
 #ifndef _ARM_BITOPS_H
 #define _ARM_BITOPS_H
 
-extern void _set_bit(int nr, volatile void * p);
-extern void _clear_bit(int nr, volatile void * p);
-extern void _change_bit(int nr, volatile void * p);
-extern int _test_and_set_bit(int nr, volatile void * p);
-extern int _test_and_clear_bit(int nr, volatile void * p);
-extern int _test_and_change_bit(int nr, volatile void * p);
-
-#define set_bit(n,p)              _set_bit(n,p)
-#define clear_bit(n,p)            _clear_bit(n,p)
-#define change_bit(n,p)           _change_bit(n,p)
-#define test_and_set_bit(n,p)     _test_and_set_bit(n,p)
-#define test_and_clear_bit(n,p)   _test_and_clear_bit(n,p)
-#define test_and_change_bit(n,p)  _test_and_change_bit(n,p)
-
 /*
  * Non-atomic bit manipulation.
  *
  * Implemented using atomics to be interrupt safe. Could alternatively
  * implement with local interrupt masking.
  */
-#define __set_bit(n,p)            _set_bit(n,p)
-#define __clear_bit(n,p)          _clear_bit(n,p)
+#define __set_bit(n,p)            set_bit(n,p)
+#define __clear_bit(n,p)          clear_bit(n,p)
 
 #define BIT(nr)                 (1UL << (nr))
 #define BIT_MASK(nr)            (1UL << ((nr) % BITS_PER_LONG))
@@ -40,6 +26,14 @@ extern int _test_and_change_bit(int nr, volatile void * p);
 #define ADDR (*(volatile long *) addr)
 #define CONST_ADDR (*(const volatile long *) addr)
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/bitops.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/bitops.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /**
  * __test_and_set_bit - Set a bit and return its old value
  * @nr: Bit to set
@@ -104,42 +98,6 @@ static inline int test_bit(int nr, const volatile void *addr)
         return 1UL & (p[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
 }
 
-/*
- * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
- */
-extern int _find_first_zero_bit_le(const void * p, unsigned size);
-extern int _find_next_zero_bit_le(const void * p, int size, int offset);
-extern int _find_first_bit_le(const unsigned long *p, unsigned size);
-extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
-
-/*
- * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
- */
-extern int _find_first_zero_bit_be(const void * p, unsigned size);
-extern int _find_next_zero_bit_be(const void * p, int size, int offset);
-extern int _find_first_bit_be(const unsigned long *p, unsigned size);
-extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
-
-#ifndef __ARMEB__
-/*
- * These are the little endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
-
-#else
-/*
- * These are the big endian, atomic definitions.
- */
-#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
-
-#endif
-
 static inline int constant_fls(int x)
 {
         int r = 32;
@@ -182,10 +140,11 @@ static inline int fls(int x)
                return constant_fls(x);
 
         asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
-        ret = 32 - ret;
+        ret = BITS_PER_LONG - ret;
         return ret;
 }
 
+
 #define ffs(x) ({ unsigned long __t = (x); fls(__t & -__t); })
 
 /**
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 5a1ea1d..3910dd2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -7,6 +7,21 @@
 #ifndef __ARM_CONFIG_H__
 #define __ARM_CONFIG_H__
 
+#if defined(__aarch64__)
+# define CONFIG_ARM_64 1
+#elif defined(__arm__)
+# define CONFIG_ARM_32 1
+#endif
+
+#if defined(CONFIG_ARM_64)
+# define LONG_BYTEORDER 3
+#else
+# define LONG_BYTEORDER 2
+#endif
+
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
+#define BITS_PER_LONG (BYTES_PER_LONG << 3)
+
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 19231ef..3f6317b 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -15,8 +15,13 @@ typedef __signed__ int __s32;
 typedef unsigned int __u32;
 
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#if defined(CONFIG_ARM_32)
 typedef __signed__ long long __s64;
 typedef unsigned long long __u64;
+#elif defined (CONFIG_ARM_64)
+typedef __signed__ long __s64;
+typedef unsigned long __u64;
+#endif
 #endif
 
 typedef signed char s8;
@@ -28,11 +33,19 @@ typedef unsigned short u16;
 typedef signed int s32;
 typedef unsigned int u32;
 
+#if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+#elif defined (CONFIG_ARM_64)
+typedef signed long s64;
+typedef unsigned long u64;
+typedef u64 paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "016lx"
+#endif
 
 typedef unsigned long size_t;
 
@@ -42,10 +55,6 @@ typedef char bool_t;
 
 #endif /* __ASSEMBLY__ */
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
-#define LONG_BYTEORDER 2
-
 #endif /* __ARM_TYPES_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTx-00089A-OZ; Fri, 22 Feb 2013 08:59:53 +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 1U8oTw-00088L-Ix
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:52 +0000
Received: from [85.158.138.51:38037] by server-12.bemta-3.messagelabs.com id
	21/30-05889-78337215; Fri, 22 Feb 2013 08:59:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361523583!19798843!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29624 invoked from network); 22 Feb 2013 08:59:45 -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;
	22 Feb 2013 08:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955718"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-0e;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:41 +0000
Message-ID: <1361523505-7604-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 02/46] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-foreign/mkheader.py |    4 +++-
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index eee28f3..e3e61f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,17 +21,18 @@ inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 """;
 
-
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -46,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 106d2be..c4d08d6 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTx-00089A-OZ; Fri, 22 Feb 2013 08:59:53 +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 1U8oTw-00088L-Ix
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:52 +0000
Received: from [85.158.138.51:38037] by server-12.bemta-3.messagelabs.com id
	21/30-05889-78337215; Fri, 22 Feb 2013 08:59:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361523583!19798843!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29624 invoked from network); 22 Feb 2013 08:59:45 -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;
	22 Feb 2013 08:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955718"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-0e;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:41 +0000
Message-ID: <1361523505-7604-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 02/46] xen: event channel arrays are
	xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM we want these to be the same size on 32- and 64-bit.

This is an ABI change on ARM. X86 does not change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-foreign/mkheader.py |    4 +++-
 xen/include/public/xen.h              |    8 ++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index eee28f3..e3e61f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,17 +21,18 @@ inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 """;
 
-
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint32_t",
+    "xen_ulong_t"   : "uint32_t",
 };
 header["x86_32"] = """
 #define __i386___X86_32 1
@@ -46,6 +47,7 @@ inttypes["x86_64"] = {
     "unsigned long" : "__align8__ uint64_t",
     "long"          : "__align8__ uint64_t",
     "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
 };
 header["x86_64"] = """
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 106d2be..c4d08d6 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
  * Event channel endpoints per domain:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
 
 struct vcpu_time_info {
     /*
@@ -613,7 +613,7 @@ struct vcpu_info {
      */
     uint8_t evtchn_upcall_pending;
     uint8_t evtchn_upcall_mask;
-    unsigned long evtchn_pending_sel;
+    xen_ulong_t evtchn_pending_sel;
     struct arch_vcpu_info arch;
     struct vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
      * per-vcpu selector word to be set. Each bit in the selector covers a
      * 'C long' in the PENDING bitfield array.
      */
-    unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-    unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+    xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+    xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
 
     /*
      * Wallclock time: updated only by control software. Guests should base
-- 
1.7.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 Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTu-00087k-KF; Fri, 22 Feb 2013 08:59:50 +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 1U8oTs-00086d-Tr
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:49 +0000
Received: from [85.158.137.99:48258] by server-16.bemta-3.messagelabs.com id
	2B/AB-02727-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25647 invoked from network); 22 Feb 2013 08:59:46 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955721"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-6A;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:48 +0000
Message-ID: <1361523505-7604-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 09/46] xen: arm: refactor co-pro and sysreg
	reg 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

AArch64 has removed the concept of co-processors replacing them with a
combination of specific instructions (cache and tlb flushes etc) and
system registers (which are understood by name in the assembler).

However most system registers are equivalent to a particular AArch32
co-pro register and can be used by generic code in the same way. Note
that the names of the registers differ (often only slightly)

For consistency it would be better to use only set of names in the
common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
differ #defines will be provided on 32-bit.

HSR_CPREG and friends are required even on 64-bit in order to decode
traps from 32 bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/processor.h |   68 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/processor.h |   37 ++++++++++++++++++
 xen/include/asm-arm/cpregs.h          |   40 +++----------------
 xen/include/asm-arm/processor.h       |    9 +++-
 4 files changed, 118 insertions(+), 36 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/processor.h
 create mode 100644 xen/include/asm-arm/arm64/processor.h

diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
new file mode 100644
index 0000000..843fbd2
--- /dev/null
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -0,0 +1,68 @@
+#ifndef __ASM_ARM_ARM32_PROCESSOR_H
+#define __ASM_ARM_ARM32_PROCESSOR_H
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+#ifndef __ASSEMBLY__
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+/*
+ * C wrappers for accessing system registers.
+ *
+ * Registers come in 3 types:
+ * - those which are always 32-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG32).
+ * - those which are always 64-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG64).
+ * - those which vary between AArch32 and AArch64 (use {READ,WRITE}_SYSREG).
+ */
+#define READ_SYSREG32(R...)     READ_CP32(R)
+#define WRITE_SYSREG32(V, R...) WRITE_CP32(V, R)
+
+#define READ_SYSREG64(R...)     READ_CP64(R)
+#define WRITE_SYSREG64(V, R...) WRITE_CP64(V, R)
+
+#define READ_SYSREG(R...)       READ_SYSREG32(R)
+#define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM32_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
new file mode 100644
index 0000000..fdb0dab
--- /dev/null
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -0,0 +1,37 @@
+#ifndef __ASM_ARM_ARM64_PROCESSOR_H
+#define __ASM_ARM_ARM64_PROCESSOR_H
+
+#ifndef __ASSEMBLY__
+
+#define READ_SYSREG32(name) ({                          \
+    uint32_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+#define WRITE_SYSREG32(v, name) do {                    \
+    uint32_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+
+#define WRITE_SYSREG64(v, name) do {                    \
+    uint64_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+#define READ_SYSREG64(name) ({                          \
+    uint64_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+
+#define READ_SYSREG(name)     READ_SYSREG64(name)
+#define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM64_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 2daaf8e..dbb5049 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -3,40 +3,12 @@
 
 #include <xen/stringify.h>
 
-/* Co-processor registers */
-
-/* Layout as used in assembly, with src/dest registers mixed in */
-#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
-#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
-#define CP32(r, name...) __CP32(r, name)
-#define CP64(r, name...) __CP64(r, name)
-
-/* Stringified for inline assembly */
-#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
-#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
-#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
-#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
-
-/* C wrappers */
-#define READ_CP32(name...) ({                                   \
-    register uint32_t _r;                                       \
-    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP32(v, name...) do {                             \
-    register uint32_t _r = (v);                                 \
-    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
-} while (0)
-
-#define READ_CP64(name...) ({                                   \
-    register uint64_t _r;                                       \
-    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP64(v, name...) do {                             \
-    register uint64_t _r = (v);                                 \
-    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
-} while (0)
+/*
+ * AArch32 Co-processor registers.
+ *
+ * Note that AArch64 requires many of these definitions in order to
+ * support 32-bit guests.
+ */
 
 #define __HSR_CPREG_c0  0
 #define __HSR_CPREG_c1  1
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 0175e11..86e6f26 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -225,8 +225,13 @@ union hsr {
 #define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
 #define ID_PFR1_GT_v1    0x00010000
 
-#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
-#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/processor.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/processor.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #ifndef __ASSEMBLY__
 extern uint32_t hyp_traps_vector[8];
-- 
1.7.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 Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTq-00086V-PV; Fri, 22 Feb 2013 08:59:46 +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 1U8oTp-00086D-0E
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:45 +0000
Received: from [85.158.137.99:14600] by server-13.bemta-3.messagelabs.com id
	70/AA-20653-F7337215; Fri, 22 Feb 2013 08:59:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361523580!12405602!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13689 invoked from network); 22 Feb 2013 08:59:42 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518205"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-5l;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:47 +0000
Message-ID: <1361523505-7604-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 08/46] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>

---
v2: Remove unused, #if-0'd, 64-bit atomics.
---
 xen/include/asm-arm/arm32/atomic.h |  151 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/atomic.h |  163 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/atomic.h       |  186 +++++++-----------------------------
 3 files changed, 347 insertions(+), 153 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/atomic.h
 create mode 100644 xen/include/asm-arm/arm64/atomic.h

diff --git a/xen/include/asm-arm/arm32/atomic.h b/xen/include/asm-arm/arm32/atomic.h
new file mode 100644
index 0000000..4ee6626
--- /dev/null
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -0,0 +1,151 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * 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.
+ */
+#ifndef __ARCH_ARM_ARM32_ATOMIC__
+#define __ARCH_ARM_ARM32_ATOMIC__
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#endif /* __ARCH_ARM_ARM32_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/atomic.h b/xen/include/asm-arm/arm64/atomic.h
new file mode 100644
index 0000000..972d50c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -0,0 +1,163 @@
+/*
+ * Based on arch/arm64/include/asm/atomic.h
+ * which in turn is
+ * Based on arch/arm/include/asm/atomic.h
+ *
+ * Copyright (C) 1996 Russell King.
+ * Copyright (C) 2002 Deep Blue Solutions Ltd.
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ARCH_ARM_ARM64_ATOMIC
+#define __ARCH_ARM_ARM64_ATOMIC
+
+/*
+ * AArch64 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add\n"
+"1:	ldxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub\n"
+"1:	ldxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+	unsigned long tmp;
+	int oldval;
+
+	asm volatile("// atomic_cmpxchg\n"
+"1:	ldaxr	%w1, [%3]\n"
+"	cmp	%w1, %w4\n"
+"	b.ne	2f\n"
+"	stlxr	%w0, %w5, [%3]\n"
+"	cbnz	%w0, 1b\n"
+"2:"
+	: "=&r" (tmp), "=&r" (oldval), "+o" (ptr->counter)
+	: "r" (&ptr->counter), "Ir" (old), "r" (new)
+	: "cc");
+
+	return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+	unsigned long tmp, tmp2;
+
+	asm volatile("// atomic_clear_mask\n"
+"1:	ldxr	%0, [%3]\n"
+"	bic	%0, %0, %4\n"
+"	stxr	%w1, %0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (tmp), "=&r" (tmp2), "+o" (*addr)
+	: "r" (addr), "Ir" (mask)
+	: "cc");
+}
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+{
+	int c, old;
+
+	c = atomic_read(v);
+	while (c != u && (old = atomic_cmpxchg((v), c, c + a)) != c)
+		c = old;
+	return c;
+}
+
+#define atomic_inc(v)		atomic_add(1, v)
+#define atomic_dec(v)		atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)	(atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)	(atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#define smp_mb__before_atomic_dec()	smp_mb()
+#define smp_mb__after_atomic_dec()	smp_mb()
+#define smp_mb__before_atomic_inc()	smp_mb()
+#define smp_mb__after_atomic_inc()	smp_mb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 3dc2427..69c8f3f 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -1,48 +1,49 @@
-/*
- *  arch/arm/include/asm/atomic.h
- *
- *  Copyright (C) 1996 Russell King.
- *  Copyright (C) 2002 Deep Blue Solutions Ltd.
- *
- * 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.
- */
 #ifndef __ARCH_ARM_ATOMIC__
 #define __ARCH_ARM_ATOMIC__
 
 #include <xen/config.h>
 #include <asm/system.h>
 
-#define build_atomic_read(name, size, type, reg)   \
+#define build_atomic_read(name, size, width, type, reg)\
 static inline type name(const volatile type *addr) \
 {                                                  \
     type ret;                                      \
-    asm volatile("ldr" size " %0,%1"               \
+    asm volatile("ldr" size " %" width "0,%1"      \
                  : reg (ret)                       \
                  : "m" (*(volatile type *)addr));  \
     return ret;                                    \
 }
 
-#define build_atomic_write(name, size, type, reg)      \
+#define build_atomic_write(name, size, width, type, reg) \
 static inline void name(volatile type *addr, type val) \
 {                                                      \
-    asm volatile("str" size " %1,%0"                   \
+    asm volatile("str" size " %"width"1,%0"            \
                  : "=m" (*(volatile type *)addr)       \
                  : reg (val));                         \
 }
 
-build_atomic_read(read_u8_atomic, "b", uint8_t, "=q")
-build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
-build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
-//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
-build_atomic_read(read_int_atomic, "", int, "=r")
-
-build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
-build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
-build_atomic_write(write_u32_atomic, "", uint32_t, "r")
-//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
-build_atomic_write(write_int_atomic, "", int, "r")
+#if defined (CONFIG_ARM_32)
+#define BYTE ""
+#define WORD ""
+#elif defined (CONFIG_ARM_64)
+#define BYTE "w"
+#define WORD "w"
+#endif
+
+build_atomic_read(read_u8_atomic,  "b", BYTE, uint8_t, "=r")
+build_atomic_read(read_u16_atomic, "h", WORD, uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "",  WORD, uint32_t, "=r")
+build_atomic_read(read_int_atomic, "",  WORD, int, "=r")
+
+build_atomic_write(write_u8_atomic,  "b", BYTE, uint8_t, "r")
+build_atomic_write(write_u16_atomic, "h", WORD, uint16_t, "r")
+build_atomic_write(write_u32_atomic, "",  WORD, uint32_t, "r")
+build_atomic_write(write_int_atomic, "",  WORD, int, "r")
+
+#if 0 /* defined (CONFIG_ARM_64) */
+build_atomic_read(read_u64_atomic, "x", uint64_t, "=r")
+build_atomic_write(write_u64_atomic, "x", uint64_t, "r")
+#endif
 
 void __bad_atomic_size(void);
 
@@ -88,134 +89,13 @@ typedef struct { int counter; } atomic_t;
 #define _atomic_set(v,i) (((v).counter) = (i))
 #define atomic_set(v,i) (((v)->counter) = (i))
 
-/*
- * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
- * store exclusive to ensure that these are atomic.  We may loop
- * to ensure that the update happens.
- */
-static inline void atomic_add(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_add\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_add_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_add_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline void atomic_sub(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_sub\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_sub_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_sub_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
-{
-        unsigned long oldval, res;
-
-        smp_mb();
-
-        do {
-                __asm__ __volatile__("@ atomic_cmpxchg\n"
-                "ldrex  %1, [%3]\n"
-                "mov    %0, #0\n"
-                "teq    %1, %4\n"
-                "strexeq %0, %5, [%3]\n"
-                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
-                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
-                    : "cc");
-        } while (res);
-
-        smp_mb();
-
-        return oldval;
-}
-
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
-{
-        unsigned long tmp, tmp2;
-
-        __asm__ __volatile__("@ atomic_clear_mask\n"
-"1:     ldrex   %0, [%3]\n"
-"       bic     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
-        : "r" (addr), "Ir" (mask)
-        : "cc");
-}
-
-#define atomic_inc(v)           atomic_add(1, v)
-#define atomic_dec(v)           atomic_sub(1, v)
-
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)    (atomic_add_return(1, v))
-#define atomic_dec_return(v)    (atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/atomic.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/atomic.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 static inline atomic_t atomic_compareandswap(
     atomic_t old, atomic_t new, atomic_t *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 Fri Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTu-00087k-KF; Fri, 22 Feb 2013 08:59:50 +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 1U8oTs-00086d-Tr
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:49 +0000
Received: from [85.158.137.99:48258] by server-16.bemta-3.messagelabs.com id
	2B/AB-02727-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25647 invoked from network); 22 Feb 2013 08:59:46 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955721"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-6A;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:48 +0000
Message-ID: <1361523505-7604-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 09/46] xen: arm: refactor co-pro and sysreg
	reg 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

AArch64 has removed the concept of co-processors replacing them with a
combination of specific instructions (cache and tlb flushes etc) and
system registers (which are understood by name in the assembler).

However most system registers are equivalent to a particular AArch32
co-pro register and can be used by generic code in the same way. Note
that the names of the registers differ (often only slightly)

For consistency it would be better to use only set of names in the
common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
differ #defines will be provided on 32-bit.

HSR_CPREG and friends are required even on 64-bit in order to decode
traps from 32 bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/processor.h |   68 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/processor.h |   37 ++++++++++++++++++
 xen/include/asm-arm/cpregs.h          |   40 +++----------------
 xen/include/asm-arm/processor.h       |    9 +++-
 4 files changed, 118 insertions(+), 36 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/processor.h
 create mode 100644 xen/include/asm-arm/arm64/processor.h

diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
new file mode 100644
index 0000000..843fbd2
--- /dev/null
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -0,0 +1,68 @@
+#ifndef __ASM_ARM_ARM32_PROCESSOR_H
+#define __ASM_ARM_ARM32_PROCESSOR_H
+
+/* Layout as used in assembly, with src/dest registers mixed in */
+#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
+#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
+#define CP32(r, name...) __CP32(r, name)
+#define CP64(r, name...) __CP64(r, name)
+
+/* Stringified for inline assembly */
+#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
+#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
+#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
+#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
+
+#ifndef __ASSEMBLY__
+
+/* C wrappers */
+#define READ_CP32(name...) ({                                   \
+    register uint32_t _r;                                       \
+    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP32(v, name...) do {                             \
+    register uint32_t _r = (v);                                 \
+    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
+} while (0)
+
+#define READ_CP64(name...) ({                                   \
+    register uint64_t _r;                                       \
+    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
+    _r; })
+
+#define WRITE_CP64(v, name...) do {                             \
+    register uint64_t _r = (v);                                 \
+    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
+} while (0)
+
+/*
+ * C wrappers for accessing system registers.
+ *
+ * Registers come in 3 types:
+ * - those which are always 32-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG32).
+ * - those which are always 64-bit regardless of AArch32 vs AArch64
+ *   (use {READ,WRITE}_SYSREG64).
+ * - those which vary between AArch32 and AArch64 (use {READ,WRITE}_SYSREG).
+ */
+#define READ_SYSREG32(R...)     READ_CP32(R)
+#define WRITE_SYSREG32(V, R...) WRITE_CP32(V, R)
+
+#define READ_SYSREG64(R...)     READ_CP64(R)
+#define WRITE_SYSREG64(V, R...) WRITE_CP64(V, R)
+
+#define READ_SYSREG(R...)       READ_SYSREG32(R)
+#define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM32_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
new file mode 100644
index 0000000..fdb0dab
--- /dev/null
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -0,0 +1,37 @@
+#ifndef __ASM_ARM_ARM64_PROCESSOR_H
+#define __ASM_ARM_ARM64_PROCESSOR_H
+
+#ifndef __ASSEMBLY__
+
+#define READ_SYSREG32(name) ({                          \
+    uint32_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+#define WRITE_SYSREG32(v, name) do {                    \
+    uint32_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+
+#define WRITE_SYSREG64(v, name) do {                    \
+    uint64_t _r = v;                                    \
+    asm volatile("msr "#name", %0" : : "r" (_r));       \
+} while (0)
+#define READ_SYSREG64(name) ({                          \
+    uint64_t _r;                                        \
+    asm volatile("mrs  %0, "#name : "=r" (_r));         \
+    _r; })
+
+#define READ_SYSREG(name)     READ_SYSREG64(name)
+#define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_ARM_ARM64_PROCESSOR_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 2daaf8e..dbb5049 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -3,40 +3,12 @@
 
 #include <xen/stringify.h>
 
-/* Co-processor registers */
-
-/* Layout as used in assembly, with src/dest registers mixed in */
-#define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
-#define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
-#define CP32(r, name...) __CP32(r, name)
-#define CP64(r, name...) __CP64(r, name)
-
-/* Stringified for inline assembly */
-#define LOAD_CP32(r, name...)  "mrc " __stringify(CP32(%r, name)) ";"
-#define STORE_CP32(r, name...) "mcr " __stringify(CP32(%r, name)) ";"
-#define LOAD_CP64(r, name...)  "mrrc " __stringify(CP64(%r, %H##r, name)) ";"
-#define STORE_CP64(r, name...) "mcrr " __stringify(CP64(%r, %H##r, name)) ";"
-
-/* C wrappers */
-#define READ_CP32(name...) ({                                   \
-    register uint32_t _r;                                       \
-    asm volatile(LOAD_CP32(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP32(v, name...) do {                             \
-    register uint32_t _r = (v);                                 \
-    asm volatile(STORE_CP32(0, name) : : "r" (_r));             \
-} while (0)
-
-#define READ_CP64(name...) ({                                   \
-    register uint64_t _r;                                       \
-    asm volatile(LOAD_CP64(0, name) : "=r" (_r));               \
-    _r; })
-
-#define WRITE_CP64(v, name...) do {                             \
-    register uint64_t _r = (v);                                 \
-    asm volatile(STORE_CP64(0, name) : : "r" (_r));             \
-} while (0)
+/*
+ * AArch32 Co-processor registers.
+ *
+ * Note that AArch64 requires many of these definitions in order to
+ * support 32-bit guests.
+ */
 
 #define __HSR_CPREG_c0  0
 #define __HSR_CPREG_c1  1
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 0175e11..86e6f26 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -225,8 +225,13 @@ union hsr {
 #define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
 #define ID_PFR1_GT_v1    0x00010000
 
-#define MSR(reg,val)        asm volatile ("msr "#reg", %0\n" : : "r" (val))
-#define MRS(val,reg)        asm volatile ("mrs %0,"#reg"\n" : "=r" (v))
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/processor.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/processor.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #ifndef __ASSEMBLY__
 extern uint32_t hyp_traps_vector[8];
-- 
1.7.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 Feb 22 09:00:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTq-00086V-PV; Fri, 22 Feb 2013 08:59:46 +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 1U8oTp-00086D-0E
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:45 +0000
Received: from [85.158.137.99:14600] by server-13.bemta-3.messagelabs.com id
	70/AA-20653-F7337215; Fri, 22 Feb 2013 08:59:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361523580!12405602!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13689 invoked from network); 22 Feb 2013 08:59:42 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518205"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-5l;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:47 +0000
Message-ID: <1361523505-7604-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 08/46] xen: arm64: atomics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>

---
v2: Remove unused, #if-0'd, 64-bit atomics.
---
 xen/include/asm-arm/arm32/atomic.h |  151 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/atomic.h |  163 +++++++++++++++++++++++++++++++
 xen/include/asm-arm/atomic.h       |  186 +++++++-----------------------------
 3 files changed, 347 insertions(+), 153 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/atomic.h
 create mode 100644 xen/include/asm-arm/arm64/atomic.h

diff --git a/xen/include/asm-arm/arm32/atomic.h b/xen/include/asm-arm/arm32/atomic.h
new file mode 100644
index 0000000..4ee6626
--- /dev/null
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -0,0 +1,151 @@
+/*
+ *  arch/arm/include/asm/atomic.h
+ *
+ *  Copyright (C) 1996 Russell King.
+ *  Copyright (C) 2002 Deep Blue Solutions Ltd.
+ *
+ * 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.
+ */
+#ifndef __ARCH_ARM_ARM32_ATOMIC__
+#define __ARCH_ARM_ARM32_ATOMIC__
+
+/*
+ * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_add\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_add_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       add     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        __asm__ __volatile__("@ atomic_sub\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+        unsigned long tmp;
+        int result;
+
+        smp_mb();
+
+        __asm__ __volatile__("@ atomic_sub_return\n"
+"1:     ldrex   %0, [%3]\n"
+"       sub     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+        : "r" (&v->counter), "Ir" (i)
+        : "cc");
+
+        smp_mb();
+
+        return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+        unsigned long oldval, res;
+
+        smp_mb();
+
+        do {
+                __asm__ __volatile__("@ atomic_cmpxchg\n"
+                "ldrex  %1, [%3]\n"
+                "mov    %0, #0\n"
+                "teq    %1, %4\n"
+                "strexeq %0, %5, [%3]\n"
+                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
+                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
+                    : "cc");
+        } while (res);
+
+        smp_mb();
+
+        return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+        unsigned long tmp, tmp2;
+
+        __asm__ __volatile__("@ atomic_clear_mask\n"
+"1:     ldrex   %0, [%3]\n"
+"       bic     %0, %0, %4\n"
+"       strex   %1, %0, [%3]\n"
+"       teq     %1, #0\n"
+"       bne     1b"
+        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
+        : "r" (addr), "Ir" (mask)
+        : "cc");
+}
+
+#define atomic_inc(v)           atomic_add(1, v)
+#define atomic_dec(v)           atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#endif /* __ARCH_ARM_ARM32_ATOMIC__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/atomic.h b/xen/include/asm-arm/arm64/atomic.h
new file mode 100644
index 0000000..972d50c
--- /dev/null
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -0,0 +1,163 @@
+/*
+ * Based on arch/arm64/include/asm/atomic.h
+ * which in turn is
+ * Based on arch/arm/include/asm/atomic.h
+ *
+ * Copyright (C) 1996 Russell King.
+ * Copyright (C) 2002 Deep Blue Solutions Ltd.
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ARCH_ARM_ARM64_ATOMIC
+#define __ARCH_ARM_ARM64_ATOMIC
+
+/*
+ * AArch64 UP and SMP safe atomic ops.  We use load exclusive and
+ * store exclusive to ensure that these are atomic.  We may loop
+ * to ensure that the update happens.
+ */
+static inline void atomic_add(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add\n"
+"1:	ldxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_add_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_add_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	add	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline void atomic_sub(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub\n"
+"1:	ldxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+}
+
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+	unsigned long tmp;
+	int result;
+
+	asm volatile("// atomic_sub_return\n"
+"1:	ldaxr	%w0, [%3]\n"
+"	sub	%w0, %w0, %w4\n"
+"	stlxr	%w1, %w0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (result), "=&r" (tmp), "+o" (v->counter)
+	: "r" (&v->counter), "Ir" (i)
+	: "cc");
+
+	return result;
+}
+
+static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+{
+	unsigned long tmp;
+	int oldval;
+
+	asm volatile("// atomic_cmpxchg\n"
+"1:	ldaxr	%w1, [%3]\n"
+"	cmp	%w1, %w4\n"
+"	b.ne	2f\n"
+"	stlxr	%w0, %w5, [%3]\n"
+"	cbnz	%w0, 1b\n"
+"2:"
+	: "=&r" (tmp), "=&r" (oldval), "+o" (ptr->counter)
+	: "r" (&ptr->counter), "Ir" (old), "r" (new)
+	: "cc");
+
+	return oldval;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+	unsigned long tmp, tmp2;
+
+	asm volatile("// atomic_clear_mask\n"
+"1:	ldxr	%0, [%3]\n"
+"	bic	%0, %0, %4\n"
+"	stxr	%w1, %0, [%3]\n"
+"	cbnz	%w1, 1b"
+	: "=&r" (tmp), "=&r" (tmp2), "+o" (*addr)
+	: "r" (addr), "Ir" (mask)
+	: "cc");
+}
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+{
+	int c, old;
+
+	c = atomic_read(v);
+	while (c != u && (old = atomic_cmpxchg((v), c, c + a)) != c)
+		c = old;
+	return c;
+}
+
+#define atomic_inc(v)		atomic_add(1, v)
+#define atomic_dec(v)		atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)	(atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)	(atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)    (atomic_add_return(1, v))
+#define atomic_dec_return(v)    (atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#define smp_mb__before_atomic_dec()	smp_mb()
+#define smp_mb__after_atomic_dec()	smp_mb()
+#define smp_mb__before_atomic_inc()	smp_mb()
+#define smp_mb__after_atomic_inc()	smp_mb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 3dc2427..69c8f3f 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -1,48 +1,49 @@
-/*
- *  arch/arm/include/asm/atomic.h
- *
- *  Copyright (C) 1996 Russell King.
- *  Copyright (C) 2002 Deep Blue Solutions Ltd.
- *
- * 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.
- */
 #ifndef __ARCH_ARM_ATOMIC__
 #define __ARCH_ARM_ATOMIC__
 
 #include <xen/config.h>
 #include <asm/system.h>
 
-#define build_atomic_read(name, size, type, reg)   \
+#define build_atomic_read(name, size, width, type, reg)\
 static inline type name(const volatile type *addr) \
 {                                                  \
     type ret;                                      \
-    asm volatile("ldr" size " %0,%1"               \
+    asm volatile("ldr" size " %" width "0,%1"      \
                  : reg (ret)                       \
                  : "m" (*(volatile type *)addr));  \
     return ret;                                    \
 }
 
-#define build_atomic_write(name, size, type, reg)      \
+#define build_atomic_write(name, size, width, type, reg) \
 static inline void name(volatile type *addr, type val) \
 {                                                      \
-    asm volatile("str" size " %1,%0"                   \
+    asm volatile("str" size " %"width"1,%0"            \
                  : "=m" (*(volatile type *)addr)       \
                  : reg (val));                         \
 }
 
-build_atomic_read(read_u8_atomic, "b", uint8_t, "=q")
-build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
-build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
-//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
-build_atomic_read(read_int_atomic, "", int, "=r")
-
-build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
-build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
-build_atomic_write(write_u32_atomic, "", uint32_t, "r")
-//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
-build_atomic_write(write_int_atomic, "", int, "r")
+#if defined (CONFIG_ARM_32)
+#define BYTE ""
+#define WORD ""
+#elif defined (CONFIG_ARM_64)
+#define BYTE "w"
+#define WORD "w"
+#endif
+
+build_atomic_read(read_u8_atomic,  "b", BYTE, uint8_t, "=r")
+build_atomic_read(read_u16_atomic, "h", WORD, uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "",  WORD, uint32_t, "=r")
+build_atomic_read(read_int_atomic, "",  WORD, int, "=r")
+
+build_atomic_write(write_u8_atomic,  "b", BYTE, uint8_t, "r")
+build_atomic_write(write_u16_atomic, "h", WORD, uint16_t, "r")
+build_atomic_write(write_u32_atomic, "",  WORD, uint32_t, "r")
+build_atomic_write(write_int_atomic, "",  WORD, int, "r")
+
+#if 0 /* defined (CONFIG_ARM_64) */
+build_atomic_read(read_u64_atomic, "x", uint64_t, "=r")
+build_atomic_write(write_u64_atomic, "x", uint64_t, "r")
+#endif
 
 void __bad_atomic_size(void);
 
@@ -88,134 +89,13 @@ typedef struct { int counter; } atomic_t;
 #define _atomic_set(v,i) (((v).counter) = (i))
 #define atomic_set(v,i) (((v)->counter) = (i))
 
-/*
- * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
- * store exclusive to ensure that these are atomic.  We may loop
- * to ensure that the update happens.
- */
-static inline void atomic_add(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_add\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_add_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_add_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       add     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline void atomic_sub(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        __asm__ __volatile__("@ atomic_sub\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-}
-
-static inline int atomic_sub_return(int i, atomic_t *v)
-{
-        unsigned long tmp;
-        int result;
-
-        smp_mb();
-
-        __asm__ __volatile__("@ atomic_sub_return\n"
-"1:     ldrex   %0, [%3]\n"
-"       sub     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
-        : "r" (&v->counter), "Ir" (i)
-        : "cc");
-
-        smp_mb();
-
-        return result;
-}
-
-static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
-{
-        unsigned long oldval, res;
-
-        smp_mb();
-
-        do {
-                __asm__ __volatile__("@ atomic_cmpxchg\n"
-                "ldrex  %1, [%3]\n"
-                "mov    %0, #0\n"
-                "teq    %1, %4\n"
-                "strexeq %0, %5, [%3]\n"
-                    : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
-                    : "r" (&ptr->counter), "Ir" (old), "r" (new)
-                    : "cc");
-        } while (res);
-
-        smp_mb();
-
-        return oldval;
-}
-
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
-{
-        unsigned long tmp, tmp2;
-
-        __asm__ __volatile__("@ atomic_clear_mask\n"
-"1:     ldrex   %0, [%3]\n"
-"       bic     %0, %0, %4\n"
-"       strex   %1, %0, [%3]\n"
-"       teq     %1, #0\n"
-"       bne     1b"
-        : "=&r" (tmp), "=&r" (tmp2), "+Qo" (*addr)
-        : "r" (addr), "Ir" (mask)
-        : "cc");
-}
-
-#define atomic_inc(v)           atomic_add(1, v)
-#define atomic_dec(v)           atomic_sub(1, v)
-
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)    (atomic_add_return(1, v))
-#define atomic_dec_return(v)    (atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/atomic.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/atomic.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 static inline atomic_t atomic_compareandswap(
     atomic_t old, atomic_t new, atomic_t *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 Fri Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTt-00086z-7x; Fri, 22 Feb 2013 08:59: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 1U8oTs-00086d-AW
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:48 +0000
Received: from [85.158.137.99:48239] by server-16.bemta-3.messagelabs.com id
	39/AB-02727-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25374 invoked from network); 22 Feb 2013 08:59:43 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955719"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSX-0005il-Uz;
	Fri, 22 Feb 2013 08:58:25 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:40 +0000
Message-ID: <1361523505-7604-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 01/46] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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 define __arm__ARM32 as required.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v2: s/x86_32/arm32/ in the right place
    s/__arm__ARM32/__arm___ARM32/
    Update gitignore
---
 .gitignore                               |    2 +-
 tools/include/xen-foreign/Makefile       |    4 ++--
 tools/include/xen-foreign/mkheader.py    |    6 +++++-
 tools/include/xen-foreign/reference.size |    2 +-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index ce6eeb3..3834e4b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -366,7 +366,7 @@ tools/include/xen-foreign/checker.c
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
-tools/include/xen-foreign/arm.h
+tools/include/xen-foreign/arm32.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..5bc2d46 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..eee28f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,15 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["arm32"] = """
+#define __arm___ARM32 1
+""";
+
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..9f1bfac 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,5 +1,5 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32  x86_32  x86_64
 
 start_info                |       -    1112    1168
 trap_info                 |       -       8      16
-- 
1.7.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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTt-00086z-7x; Fri, 22 Feb 2013 08:59: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 1U8oTs-00086d-AW
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:48 +0000
Received: from [85.158.137.99:48239] by server-16.bemta-3.messagelabs.com id
	39/AB-02727-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25374 invoked from network); 22 Feb 2013 08:59:43 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955719"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSX-0005il-Uz;
	Fri, 22 Feb 2013 08:58:25 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:40 +0000
Message-ID: <1361523505-7604-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 01/46] tools: s/arm/arm32/ in foreign header
	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>
Content-Type: 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 define __arm__ARM32 as required.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v2: s/x86_32/arm32/ in the right place
    s/__arm__ARM32/__arm___ARM32/
    Update gitignore
---
 .gitignore                               |    2 +-
 tools/include/xen-foreign/Makefile       |    4 ++--
 tools/include/xen-foreign/mkheader.py    |    6 +++++-
 tools/include/xen-foreign/reference.size |    2 +-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index ce6eeb3..3834e4b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -366,7 +366,7 @@ tools/include/xen-foreign/checker.c
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
-tools/include/xen-foreign/arm.h
+tools/include/xen-foreign/arm32.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index cfaf790..5bc2d46 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm x86_32 x86_64
+architectures := arm32 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,7 +22,7 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
-arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index d189b07..eee28f3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -17,11 +17,15 @@ header = {};
 footer = {};
 
 #arm
-inttypes["arm"] = {
+inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
     "xen_pfn_t"     : "uint64_t",
 };
+header["arm32"] = """
+#define __arm___ARM32 1
+""";
+
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index a2cbfd6..9f1bfac 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,5 +1,5 @@
 
-structs                   |     arm  x86_32  x86_64
+structs                   |   arm32  x86_32  x86_64
 
 start_info                |       -    1112    1168
 trap_info                 |       -       8      16
-- 
1.7.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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTv-00087r-0p; Fri, 22 Feb 2013 08:59: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 1U8oTt-00086d-IF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:49 +0000
Received: from [85.158.137.99:48387] by server-16.bemta-3.messagelabs.com id
	32/BB-02727-48337215; Fri, 22 Feb 2013 08:59:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25823 invoked from network); 22 Feb 2013 08:59:47 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955723"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-4Q;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:44 +0000
Message-ID: <1361523505-7604-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 05/46] xen: arm64: initial build + config
	changes, start of day 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: - s/hyp/el2/
    - remove dead code
    - fix comment formatting
    - Fix xen.lds.S constructor definitions, s/4/BYTES_PER_LONG/g
v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
      defining in head.S
    - Nuke hard tabs in head.S and mode_switch.S with expand(1)

fixup
---
 Config.mk                        |    2 +-
 config/arm64.mk                  |   12 ++
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/Rules.mk            |    6 +
 xen/arch/arm/arm64/Makefile      |    1 +
 xen/arch/arm/arm64/head.S        |  393 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
 xen/arch/arm/xen.lds.S           |   12 +-
 xen/include/asm-arm/page.h       |    1 +
 xen/include/public/arch-arm.h    |   14 ++
 xen/include/public/hvm/save.h    |    2 +-
 xen/include/public/xen.h         |    2 +-
 xen/include/xen/libelf.h         |    2 +-
 13 files changed, 524 insertions(+), 7 deletions(-)
 create mode 100644 config/arm64.mk
 create mode 100644 xen/arch/arm/arm64/Makefile
 create mode 100644 xen/arch/arm/arm64/head.S
 create mode 100644 xen/arch/arm/arm64/mode_switch.S

diff --git a/Config.mk b/Config.mk
index 07b30ba..a61d7e1 100644
--- a/Config.mk
+++ b/Config.mk
@@ -18,7 +18,7 @@ coverage ?= n
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
-                         -e s/armv7.*/arm32/)
+                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
 
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
diff --git a/config/arm64.mk b/config/arm64.mk
new file mode 100644
index 0000000..b2457eb
--- /dev/null
+++ b/config/arm64.mk
@@ -0,0 +1,12 @@
+CONFIG_ARM := y
+CONFIG_ARM_64 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+CFLAGS += #-marm -march= -mcpu= etc
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+LDFLAGS_DIRECT += -maarch64elf
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 3954dbb..677e232 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-$(arm64) += arm64
 subdir-y += platforms
 
 obj-y += early_printk.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 0843e50..a0a14e0 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -27,6 +27,12 @@ arm32 := y
 arm64 := n
 endif
 
+ifeq ($(TARGET_SUBARCH),arm64)
+CFLAGS += -mcpu=generic
+arm32 := n
+arm64 := y
+endif
+
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
new file mode 100644
index 0000000..dffbeb1
--- /dev/null
+++ b/xen/arch/arm/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
new file mode 100644
index 0000000..b7ab251
--- /dev/null
+++ b/xen/arch/arm/arm64/head.S
@@ -0,0 +1,393 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv8.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * Based on ARMv7-A head.S by
+ * Tim Deegan <tim@xen.org>
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
+#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
+#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
+#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+        adr   x0, 98f ; \
+        bl    puts    ; \
+        b     99f     ; \
+98:     .asciz _s     ; \
+        .align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+        /*.aarch64*/
+
+        /*
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * The requirements are:
+         *   MMU = off, D-cache = off, I-cache = on or off,
+         *   x0 = physical address to the FDT blob.
+         *
+         * This must be the very first address in the loaded image.
+         * It should be linked at XEN_VIRT_START, and loaded at any
+         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+         * or the initial pagetable code below will need adjustment.
+         */
+
+        .global start
+start:
+        /*
+         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
+         */
+        b       real_start           /* branch to kernel start, magic */
+        .long   0                    /* reserved */
+        .quad   0                    /* Image load offset from start of RAM */
+        .quad   0                    /* reserved */
+        .quad   0                    /* reserved */
+
+real_start:
+        msr   DAIFSet, 0xf           /* Disable all interrupts */
+
+        /* Save the bootloader arguments in less-clobberable registers */
+        mov   x21, x0                /* x21 := DTB, physical address  */
+
+        /* Find out where we are */
+        ldr   x0, =start
+        adr   x19, start             /* x19 := paddr (start) */
+        sub   x20, x19, x0           /* x20 := phys-offset */
+
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   x21, =_sdtb
+        add   x21, x21, x20          /* x21 := paddr(DTB) */
+#endif
+
+        /* Are we the boot CPU? */
+        mov   x22, #0                /* x22 := CPU ID */
+        mrs   x0, mpidr_el1
+        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
+        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
+
+        mov   x13, #(0xff << 24)
+        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
+        b.eq  boot_cpu               /* If we're CPU 0, boot now */
+
+        /* Non-boot CPUs wait here to be woken up one at a time. */
+1:      dsb   sy
+        ldr   x0, =smp_up_cpu        /* VA of gate */
+        add   x0, x0, x20            /* PA of gate */
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x22                /* Is it us? */
+        b.eq  2f
+        wfe
+        b     1b
+2:
+
+boot_cpu:
+#ifdef EARLY_UART_ADDRESS
+        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
+        cbnz  x22, 1f
+        bl    init_uart                 /* CPU 0 sets up the UART too */
+1:      PRINT("- CPU ")
+        mov   x0, x22
+        bl    putn
+        PRINT(" booting -\r\n")
+#endif
+
+        PRINT("- Current EL ")
+        mrs   x0, CurrentEL
+        bl    putn
+        PRINT(" -\r\n")
+
+        /* Are we in EL3 */
+        mrs   x0, CurrentEL
+        cmp   x0, #PSR_MODE_EL3t
+        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
+        b.eq  1f /* Yes */
+
+        /* Are we in EL2 */
+        cmp   x0, #PSR_MODE_EL2t
+        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
+        b.eq  2f /* Yes */
+
+        /* Otherwise, it must have been EL0 or EL1 */
+        PRINT("- CPU is not in EL3 or EL2 -\r\n")
+        b     fail
+
+1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
+        ldr   x1, =enter_el2_mode    /* VA of function */
+        add   x1, x1, x20            /* PA of function */
+        adr   x30, el2               /* Set return address for call */
+        br    x1                     /* Call function */
+
+2:      PRINT("- Started in EL2 mode -\r\n")
+
+el2:
+        /* Zero BSS On the boot CPU to avoid nasty surprises */
+        cbnz  x22, skip_bss
+
+        PRINT("- Zero BSS -\r\n")
+        ldr   x0, =__bss_start       /* Load start & end of bss */
+        ldr   x1, =__bss_end
+        add   x0, x0, x20            /* Apply physical offset */
+        add   x1, x1, x20
+
+1:      str   xzr, [x0], #8
+        cmp   x0, x1
+        b.lo  1b
+
+skip_bss:
+
+        PRINT("- Setting up control registers -\r\n")
+
+        /* Set up memory attribute type tables */
+        ldr   x0, =MAIRVAL
+        msr   mair_el2, x0
+
+        /* Set up the HTCR:
+         * PASize -- 4G
+         * Top byte is used
+         * PT walks use Outer-Shareable accesses,
+         * PT walks are write-back, no-write-allocate in both cache levels,
+         * Full 64-bit address space goes through this table. */
+        ldr   x0, =0x80802500
+        msr   tcr_el2, x0
+
+        /* Set up the HSCTLR:
+         * Exceptions in LE ARM,
+         * Low-latency IRQs disabled,
+         * Write-implies-XN disabled (for now),
+         * D-cache disabled (for now),
+         * I-cache enabled,
+         * Alignment checking enabled,
+         * MMU translation disabled (for now). */
+        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
+        msr   SCTLR_EL2, x0
+
+        /* Write Xen's PT's paddr into the HTTBR */
+        ldr   x4, =xen_pgtable
+        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
+        msr   TTBR0_EL2, x4
+
+        /* Non-boot CPUs don't need to rebuild the pagetable */
+        cbnz  x22, pt_ready
+
+        ldr   x1, =xen_first
+        add   x1, x1, x20            /* x1 := paddr (xen_first) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_first */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+
+        mov   x4, x1                 /* Next level into xen_first */
+
+       /* console fixmap */
+#ifdef EARLY_UART_ADDRESS
+        ldr   x1, =xen_fixmap
+        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
+        lsr   x2, x23, #12
+        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
+        mov   x3, #PT_DEV_L3
+        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
+        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
+#endif
+
+        /* Build the baseline idle pagetable's first-level entries */
+        ldr   x1, =xen_second
+        add   x1, x1, x20            /* x1 := paddr (xen_second) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_second */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
+
+        /* Now set up the second-level entries */
+        mov   x3, #PT_MEM
+        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
+        orr   x4, xzr, x19, lsr #18
+        str   x2, [x1, x4]           /* Map Xen there */
+        ldr   x4, =start
+        lsr   x4, x4, #18            /* Slot for vaddr(start) */
+        str   x2, [x1, x4]           /* Map Xen there too */
+
+        /* xen_fixmap pagetable */
+        ldr   x2, =xen_fixmap
+        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
+        mov   x3, #PT_PT
+        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
+
+        lsr   x2, x21, #21
+        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
+        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
+        orr   x2, x2, x3
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the early boot slot */
+
+pt_ready:
+        PRINT("- Turning on paging -\r\n")
+
+        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
+        mrs   x0, SCTLR_EL2
+        orr   x0, x0, #SCTLR_M       /* Enable MMU */
+        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
+        dsb   sy                     /* Flush PTE writes and finish reads */
+        msr   SCTLR_EL2, x0          /* now paging is enabled */
+        isb                          /* Now, flush the icache */
+        br    x1                     /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+        /* Use a virtual address to access the UART. */
+        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+#endif
+
+        PRINT("- Ready -\r\n")
+
+        /* The boot CPU should go straight into C now */
+        cbz   x22, launch
+
+        /* Non-boot CPUs need to move on to the relocated pagetables */
+        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
+        add   x4, x4, x20            /* PA of it */
+        ldr   x4, [x4]               /* Actual value */
+        dsb   sy
+        msr   TTBR0_EL2, x4
+        dsb   sy
+        isb
+        tlbi  alle2
+        dsb   sy                     /* Ensure completion of TLB flush */
+        isb
+
+        /* Non-boot CPUs report that they've got this far */
+        ldr   x0, =ready_cpus
+1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
+        add   x1, x1, #1             /* Atomically { ++                   } */
+        stlxr w2, x1, [x0]           /*            { writeback            } */
+        cbnz  w2, 1b
+        dsb   sy
+        dc    cvac, x0               /* Flush D-Cache */
+        dsb   sy
+
+        /* Here, the non-boot CPUs must wait again -- they're now running on
+         * the boot CPU's pagetables so it's safe for the boot CPU to
+         * overwrite the non-relocated copy of Xen.  Once it's done that,
+         * and brought up the memory allocator, non-boot CPUs can get their
+         * own stacks and enter C. */
+1:      wfe
+        dsb   sy
+        ldr   x0, =smp_up_cpu
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x12                /* Is it us? */
+        b.ne  1b
+
+launch:
+        ldr   x0, =init_stack        /* Find the boot-time stack */
+        ldr   x0, [x0]
+        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
+        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
+        mov   sp, x0
+
+        mov   x0, x20                /* Marshal args: - phys_offset */
+        mov   x1, x21                /*               - FDT */
+        mov   x2, x22                /*               - CPU ID */
+        cbz   x22, start_xen         /* and disappear into the land of C */
+        b     start_secondary        /* (to the appropriate entry point) */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:   PRINT("- Boot failed -\r\n")
+1:      wfe
+        b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+        mov   x1, #0x0
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+        mov   x1, #0x60              /* 8n1 */
+        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
+        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
+        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
+        adr   x0, 1f
+        b     puts
+1:      .asciz "- UART enabled -\r\n"
+        .align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  puts                   /* Wait for the UART to be ready */
+        ldrb  w2, [x0], #1           /* Load next char */
+        cbz   w2, 1f                 /* Exit on nul */
+        str   w2, [x23]              /* -> UARTDR (Data Register) */
+        b     puts
+1:
+        ret
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+        adr   x1, hex
+        mov   x3, #8
+1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  1b                     /* Wait for the UART to be ready */
+        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
+        lsr   x2, x2, #28
+        ldrb  w2, [x1, x2]           /* Convert to a char */
+        strb  w2, [x23]              /* -> UARTDR (Data Register) */
+        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
+        subs  x3, x3, #1
+        b.ne  1b
+        ret
+
+hex:    .ascii "0123456789abcdef"
+        .align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:   mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
new file mode 100644
index 0000000..4c38181
--- /dev/null
+++ b/xen/arch/arm/arm64/mode_switch.S
@@ -0,0 +1,83 @@
+/*
+ * xen/arch/arm/arm64/mode_switch.S
+ *
+ * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
+ *       bootwrapper.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+/* Get up a CPU into EL2.  Clobbers x0-x3.
+ *
+ * Expects x22 == CPU number
+ * Expects x30  == EL2 entry point
+ *
+ * This code is specific to the VE model, and not intended to be used
+ * on production systems.  As such it's a bit hackier than the main
+ * boot code in head.S.  In future it will be replaced by better
+ * integration with the bootloader/firmware so that Xen always starts
+ * at EL2.
+ */
+
+.globl enter_el2_mode
+enter_el2_mode:
+        mov     x0, #0x30                       // RES1
+        orr     x0, x0, #(1 << 0)               // Non-secure EL1
+        orr     x0, x0, #(1 << 8)               // HVC enable
+        orr     x0, x0, #(1 << 10)              // 64-bit EL2
+        msr     scr_el3, x0
+
+        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
+
+        ldr     x0, =0x01800000                 // 24Mhz
+        msr     cntfrq_el0, x0
+
+        /*
+         * Check for the primary CPU to avoid a race on the distributor
+         * registers.
+         */
+        cbnz    x22, 1f
+
+        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
+        mov     w0, #~0                         // Grp1 interrupts
+        str     w0, [x1], #4
+        b.ne    2f                              // Only local interrupts for secondary CPUs
+        str     w0, [x1], #4
+        str     w0, [x1], #4
+
+2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
+        ldr     w0, [x1]
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
+        str     w0, [x1, #4]                    // GICC_PMR
+
+        msr     sctlr_el2, xzr
+
+        /*
+         * Prepare the switch to the EL2_SP1 mode from EL3
+         */
+        msr     elr_el3, x30                    // Return to desired function
+        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+        msr     spsr_el3, x1
+        eret
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 50e0c4b..5136b79 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -11,7 +11,13 @@
 
 ENTRY(start)
 
-OUTPUT_ARCH(arm)
+#if defined(__arm__)
+#define FORMAT arm
+#elif defined(__aarch64__)
+#define FORMAT aarch64
+#endif
+
+OUTPUT_ARCH(FORMAT)
 
 PHDRS
 {
@@ -85,9 +91,9 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
-       . = ALIGN(4);
+       . = ALIGN(BYTES_PER_LONG);
        __CTOR_LIST__ = .;
-       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
        *(.ctors)
        LONG(0)
        __CTOR_END__ = .;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index cd74950..45ded77 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -38,6 +38,7 @@
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
+#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
 
 /*
  * Attribute Indexes.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 6ae1009..5306f79 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -172,6 +172,8 @@ typedef uint64_t xen_callback_t;
 
 /* 0-4: Mode */
 #define PSR_MODE_MASK 0x1f
+
+/* 32 bit modes */
 #define PSR_MODE_USR 0x10
 #define PSR_MODE_FIQ 0x11
 #define PSR_MODE_IRQ 0x12
@@ -182,6 +184,18 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
+/* 64 bit modes */
+#ifdef CONFIG_ARM_64
+#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
+#define PSR_MODE_EL3h 0x0d
+#define PSR_MODE_EL3t 0x0c
+#define PSR_MODE_EL2h 0x09
+#define PSR_MODE_EL2t 0x08
+#define PSR_MODE_EL1h 0x05
+#define PSR_MODE_EL1t 0x04
+#define PSR_MODE_EL0t 0x00
+#endif
+
 #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
 #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
 #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index 5538d8e..cc8b5fd 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "../arch-x86/hvm/save.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined(__aarch64__)
 #include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index c4d08d6..e9431e2 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -31,7 +31,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "arch-x86/xen.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined (__aarch64__)
 #include "arch-arm.h"
 #else
 #error "Unsupported architecture"
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index e8f6508..218bb18 100644
--- 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(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTv-00087r-0p; Fri, 22 Feb 2013 08:59: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 1U8oTt-00086d-IF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:49 +0000
Received: from [85.158.137.99:48387] by server-16.bemta-3.messagelabs.com id
	32/BB-02727-48337215; Fri, 22 Feb 2013 08:59:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25823 invoked from network); 22 Feb 2013 08:59:47 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955723"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-4Q;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:44 +0000
Message-ID: <1361523505-7604-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 05/46] xen: arm64: initial build + config
	changes, start of day 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: - s/hyp/el2/
    - remove dead code
    - fix comment formatting
    - Fix xen.lds.S constructor definitions, s/4/BYTES_PER_LONG/g
v2: - Add PSR_MODE definitions for 64-bit to arch-arm.h and use instead of
      defining in head.S
    - Nuke hard tabs in head.S and mode_switch.S with expand(1)

fixup
---
 Config.mk                        |    2 +-
 config/arm64.mk                  |   12 ++
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/Rules.mk            |    6 +
 xen/arch/arm/arm64/Makefile      |    1 +
 xen/arch/arm/arm64/head.S        |  393 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/mode_switch.S |   83 ++++++++
 xen/arch/arm/xen.lds.S           |   12 +-
 xen/include/asm-arm/page.h       |    1 +
 xen/include/public/arch-arm.h    |   14 ++
 xen/include/public/hvm/save.h    |    2 +-
 xen/include/public/xen.h         |    2 +-
 xen/include/xen/libelf.h         |    2 +-
 13 files changed, 524 insertions(+), 7 deletions(-)
 create mode 100644 config/arm64.mk
 create mode 100644 xen/arch/arm/arm64/Makefile
 create mode 100644 xen/arch/arm/arm64/head.S
 create mode 100644 xen/arch/arm/arm64/mode_switch.S

diff --git a/Config.mk b/Config.mk
index 07b30ba..a61d7e1 100644
--- a/Config.mk
+++ b/Config.mk
@@ -18,7 +18,7 @@ coverage ?= n
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ \
-                         -e s/armv7.*/arm32/)
+                         -e s/armv7.*/arm32/ -e s/armv8.*/arm64/)
 
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
diff --git a/config/arm64.mk b/config/arm64.mk
new file mode 100644
index 0000000..b2457eb
--- /dev/null
+++ b/config/arm64.mk
@@ -0,0 +1,12 @@
+CONFIG_ARM := y
+CONFIG_ARM_64 := y
+CONFIG_ARM_$(XEN_OS) := y
+
+CFLAGS += #-marm -march= -mcpu= etc
+
+HAS_PL011 := y
+
+# Use only if calling $(LD) directly.
+LDFLAGS_DIRECT += -maarch64elf
+
+CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 3954dbb..677e232 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,4 +1,5 @@
 subdir-$(arm32) += arm32
+subdir-$(arm64) += arm64
 subdir-y += platforms
 
 obj-y += early_printk.o
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 0843e50..a0a14e0 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -27,6 +27,12 @@ arm32 := y
 arm64 := n
 endif
 
+ifeq ($(TARGET_SUBARCH),arm64)
+CFLAGS += -mcpu=generic
+arm32 := n
+arm64 := y
+endif
+
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
new file mode 100644
index 0000000..dffbeb1
--- /dev/null
+++ b/xen/arch/arm/arm64/Makefile
@@ -0,0 +1 @@
+obj-y += mode_switch.o
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
new file mode 100644
index 0000000..b7ab251
--- /dev/null
+++ b/xen/arch/arm/arm64/head.S
@@ -0,0 +1,393 @@
+/*
+ * xen/arch/arm/head.S
+ *
+ * Start-of-day code for an ARMv8.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * Based on ARMv7-A head.S by
+ * Tim Deegan <tim@xen.org>
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+#define PT_PT     0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
+#define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
+#define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
+#define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+
+/* Macro to print a string to the UART, if there is one.
+ * Clobbers r0-r3. */
+#ifdef EARLY_UART_ADDRESS
+#define PRINT(_s)       \
+        adr   x0, 98f ; \
+        bl    puts    ; \
+        b     99f     ; \
+98:     .asciz _s     ; \
+        .align 2      ; \
+99:
+#else
+#define PRINT(s)
+#endif
+
+        /*.aarch64*/
+
+        /*
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * The requirements are:
+         *   MMU = off, D-cache = off, I-cache = on or off,
+         *   x0 = physical address to the FDT blob.
+         *
+         * This must be the very first address in the loaded image.
+         * It should be linked at XEN_VIRT_START, and loaded at any
+         * 2MB-aligned address.  All of text+data+bss must fit in 2MB,
+         * or the initial pagetable code below will need adjustment.
+         */
+
+        .global start
+start:
+        /*
+         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
+         */
+        b       real_start           /* branch to kernel start, magic */
+        .long   0                    /* reserved */
+        .quad   0                    /* Image load offset from start of RAM */
+        .quad   0                    /* reserved */
+        .quad   0                    /* reserved */
+
+real_start:
+        msr   DAIFSet, 0xf           /* Disable all interrupts */
+
+        /* Save the bootloader arguments in less-clobberable registers */
+        mov   x21, x0                /* x21 := DTB, physical address  */
+
+        /* Find out where we are */
+        ldr   x0, =start
+        adr   x19, start             /* x19 := paddr (start) */
+        sub   x20, x19, x0           /* x20 := phys-offset */
+
+        /* Using the DTB in the .dtb section? */
+#ifdef CONFIG_DTB_FILE
+        ldr   x21, =_sdtb
+        add   x21, x21, x20          /* x21 := paddr(DTB) */
+#endif
+
+        /* Are we the boot CPU? */
+        mov   x22, #0                /* x22 := CPU ID */
+        mrs   x0, mpidr_el1
+        tbz   x0, 31, boot_cpu       /* Multiprocessor extension supported? */
+        tbnz  x0, 30, boot_cpu       /* Uniprocessor system? */
+
+        mov   x13, #(0xff << 24)
+        bics  x22, x0, x13           /* Mask out flags to get CPU ID */
+        b.eq  boot_cpu               /* If we're CPU 0, boot now */
+
+        /* Non-boot CPUs wait here to be woken up one at a time. */
+1:      dsb   sy
+        ldr   x0, =smp_up_cpu        /* VA of gate */
+        add   x0, x0, x20            /* PA of gate */
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x22                /* Is it us? */
+        b.eq  2f
+        wfe
+        b     1b
+2:
+
+boot_cpu:
+#ifdef EARLY_UART_ADDRESS
+        ldr   x23, =EARLY_UART_ADDRESS  /* x23 := UART base address */
+        cbnz  x22, 1f
+        bl    init_uart                 /* CPU 0 sets up the UART too */
+1:      PRINT("- CPU ")
+        mov   x0, x22
+        bl    putn
+        PRINT(" booting -\r\n")
+#endif
+
+        PRINT("- Current EL ")
+        mrs   x0, CurrentEL
+        bl    putn
+        PRINT(" -\r\n")
+
+        /* Are we in EL3 */
+        mrs   x0, CurrentEL
+        cmp   x0, #PSR_MODE_EL3t
+        ccmp  x0, #PSR_MODE_EL3h, #0x4, ne
+        b.eq  1f /* Yes */
+
+        /* Are we in EL2 */
+        cmp   x0, #PSR_MODE_EL2t
+        ccmp  x0, #PSR_MODE_EL2h, #0x4, ne
+        b.eq  2f /* Yes */
+
+        /* Otherwise, it must have been EL0 or EL1 */
+        PRINT("- CPU is not in EL3 or EL2 -\r\n")
+        b     fail
+
+1:      PRINT("- Started in EL3 -\r\n- Entering EL2 -\r\n")
+        ldr   x1, =enter_el2_mode    /* VA of function */
+        add   x1, x1, x20            /* PA of function */
+        adr   x30, el2               /* Set return address for call */
+        br    x1                     /* Call function */
+
+2:      PRINT("- Started in EL2 mode -\r\n")
+
+el2:
+        /* Zero BSS On the boot CPU to avoid nasty surprises */
+        cbnz  x22, skip_bss
+
+        PRINT("- Zero BSS -\r\n")
+        ldr   x0, =__bss_start       /* Load start & end of bss */
+        ldr   x1, =__bss_end
+        add   x0, x0, x20            /* Apply physical offset */
+        add   x1, x1, x20
+
+1:      str   xzr, [x0], #8
+        cmp   x0, x1
+        b.lo  1b
+
+skip_bss:
+
+        PRINT("- Setting up control registers -\r\n")
+
+        /* Set up memory attribute type tables */
+        ldr   x0, =MAIRVAL
+        msr   mair_el2, x0
+
+        /* Set up the HTCR:
+         * PASize -- 4G
+         * Top byte is used
+         * PT walks use Outer-Shareable accesses,
+         * PT walks are write-back, no-write-allocate in both cache levels,
+         * Full 64-bit address space goes through this table. */
+        ldr   x0, =0x80802500
+        msr   tcr_el2, x0
+
+        /* Set up the HSCTLR:
+         * Exceptions in LE ARM,
+         * Low-latency IRQs disabled,
+         * Write-implies-XN disabled (for now),
+         * D-cache disabled (for now),
+         * I-cache enabled,
+         * Alignment checking enabled,
+         * MMU translation disabled (for now). */
+        ldr   x0, =(HSCTLR_BASE|SCTLR_A)
+        msr   SCTLR_EL2, x0
+
+        /* Write Xen's PT's paddr into the HTTBR */
+        ldr   x4, =xen_pgtable
+        add   x4, x4, x20            /* x4 := paddr (xen_pagetable) */
+        msr   TTBR0_EL2, x4
+
+        /* Non-boot CPUs don't need to rebuild the pagetable */
+        cbnz  x22, pt_ready
+
+        ldr   x1, =xen_first
+        add   x1, x1, x20            /* x1 := paddr (xen_first) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_first */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+
+        mov   x4, x1                 /* Next level into xen_first */
+
+       /* console fixmap */
+#ifdef EARLY_UART_ADDRESS
+        ldr   x1, =xen_fixmap
+        add   x1, x1, x20            /* x1 := paddr (xen_fixmap) */
+        lsr   x2, x23, #12
+        lsl   x2, x2, #12            /* 4K aligned paddr of UART */
+        mov   x3, #PT_DEV_L3
+        orr   x2, x2, x3             /* x2 := 4K dev map including UART */
+        str   x2, [x1, #(FIXMAP_CONSOLE*8)] /* Map it in the first fixmap's slot */
+#endif
+
+        /* Build the baseline idle pagetable's first-level entries */
+        ldr   x1, =xen_second
+        add   x1, x1, x20            /* x1 := paddr (xen_second) */
+        mov   x3, #PT_PT             /* x2 := table map of xen_second */
+        orr   x2, x1, x3             /* (+ rights for linear PT) */
+        str   x2, [x4, #0]           /* Map it in slot 0 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #8]           /* Map 2nd page in slot 1 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #16]          /* Map 3rd page in slot 2 */
+        add   x2, x2, #0x1000
+        str   x2, [x4, #24]          /* Map 4th page in slot 3 */
+
+        /* Now set up the second-level entries */
+        mov   x3, #PT_MEM
+        orr   x2, x19, x3            /* x2 := 2MB normal map of Xen */
+        orr   x4, xzr, x19, lsr #18
+        str   x2, [x1, x4]           /* Map Xen there */
+        ldr   x4, =start
+        lsr   x4, x4, #18            /* Slot for vaddr(start) */
+        str   x2, [x1, x4]           /* Map Xen there too */
+
+        /* xen_fixmap pagetable */
+        ldr   x2, =xen_fixmap
+        add   x2, x2, x20            /* x2 := paddr (xen_fixmap) */
+        mov   x3, #PT_PT
+        orr   x2, x2, x3             /* x2 := table map of xen_fixmap */
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the fixmap's slot */
+
+        lsr   x2, x21, #21
+        lsl   x2, x2, #21            /* 2MB-aligned paddr of DTB */
+        mov   x3, #PT_MEM            /* x2 := 2MB RAM incl. DTB */
+        orr   x2, x2, x3
+        add   x4, x4, #8
+        str   x2, [x1, x4]           /* Map it in the early boot slot */
+
+pt_ready:
+        PRINT("- Turning on paging -\r\n")
+
+        ldr   x1, =paging            /* Explicit vaddr, not RIP-relative */
+        mrs   x0, SCTLR_EL2
+        orr   x0, x0, #SCTLR_M       /* Enable MMU */
+        orr   x0, x0, #SCTLR_C       /* Enable D-cache */
+        dsb   sy                     /* Flush PTE writes and finish reads */
+        msr   SCTLR_EL2, x0          /* now paging is enabled */
+        isb                          /* Now, flush the icache */
+        br    x1                     /* Get a proper vaddr into PC */
+paging:
+
+#ifdef EARLY_UART_ADDRESS
+        /* Use a virtual address to access the UART. */
+        ldr   x23, =FIXMAP_ADDR(FIXMAP_CONSOLE)
+#endif
+
+        PRINT("- Ready -\r\n")
+
+        /* The boot CPU should go straight into C now */
+        cbz   x22, launch
+
+        /* Non-boot CPUs need to move on to the relocated pagetables */
+        ldr   x4, =boot_ttbr         /* VA of TTBR0_EL2 stashed by CPU 0 */
+        add   x4, x4, x20            /* PA of it */
+        ldr   x4, [x4]               /* Actual value */
+        dsb   sy
+        msr   TTBR0_EL2, x4
+        dsb   sy
+        isb
+        tlbi  alle2
+        dsb   sy                     /* Ensure completion of TLB flush */
+        isb
+
+        /* Non-boot CPUs report that they've got this far */
+        ldr   x0, =ready_cpus
+1:      ldaxr x1, [x0]               /*            { read # of ready CPUs } */
+        add   x1, x1, #1             /* Atomically { ++                   } */
+        stlxr w2, x1, [x0]           /*            { writeback            } */
+        cbnz  w2, 1b
+        dsb   sy
+        dc    cvac, x0               /* Flush D-Cache */
+        dsb   sy
+
+        /* Here, the non-boot CPUs must wait again -- they're now running on
+         * the boot CPU's pagetables so it's safe for the boot CPU to
+         * overwrite the non-relocated copy of Xen.  Once it's done that,
+         * and brought up the memory allocator, non-boot CPUs can get their
+         * own stacks and enter C. */
+1:      wfe
+        dsb   sy
+        ldr   x0, =smp_up_cpu
+        ldr   x1, [x0]               /* Which CPU is being booted? */
+        cmp   x1, x12                /* Is it us? */
+        b.ne  1b
+
+launch:
+        ldr   x0, =init_stack        /* Find the boot-time stack */
+        ldr   x0, [x0]
+        add   x0, x0, #STACK_SIZE    /* (which grows down from the top). */
+        sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
+        mov   sp, x0
+
+        mov   x0, x20                /* Marshal args: - phys_offset */
+        mov   x1, x21                /*               - FDT */
+        mov   x2, x22                /*               - CPU ID */
+        cbz   x22, start_xen         /* and disappear into the land of C */
+        b     start_secondary        /* (to the appropriate entry point) */
+
+/* Fail-stop
+ * r0: string explaining why */
+fail:   PRINT("- Boot failed -\r\n")
+1:      wfe
+        b     1b
+
+#ifdef EARLY_UART_ADDRESS
+
+/* Bring up the UART. Specific to the PL011 UART.
+ * Clobbers r0-r2 */
+init_uart:
+        mov   x1, #0x0
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor fraction) */
+        mov   x1, #0x4               /* 7.3728MHz / 0x4 == 16 * 115200 */
+        strh  w1, [x23, #0x24]       /* -> UARTIBRD (Baud divisor integer) */
+        mov   x1, #0x60              /* 8n1 */
+        strh  w1, [x23, #0x24]       /* -> UARTLCR_H (Line control) */
+        ldr   x1, =0x00000301        /* RXE | TXE | UARTEN */
+        strh  w1, [x23, #0x30]       /* -> UARTCR (Control Register) */
+        adr   x0, 1f
+        b     puts
+1:      .asciz "- UART enabled -\r\n"
+        .align 4
+
+/* Print early debug messages.  Specific to the PL011 UART.
+ * r0: Nul-terminated string to print.
+ * Clobbers r0-r2 */
+puts:
+        ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  puts                   /* Wait for the UART to be ready */
+        ldrb  w2, [x0], #1           /* Load next char */
+        cbz   w2, 1f                 /* Exit on nul */
+        str   w2, [x23]              /* -> UARTDR (Data Register) */
+        b     puts
+1:
+        ret
+
+/* Print a 32-bit number in hex.  Specific to the PL011 UART.
+ * r0: Number to print.
+ * clobbers r0-r3 */
+putn:
+        adr   x1, hex
+        mov   x3, #8
+1:      ldrh  w2, [x23, #0x18]       /* <- UARTFR (Flag register) */
+        tst   w2, #0x8               /* Check BUSY bit */
+        b.ne  1b                     /* Wait for the UART to be ready */
+        and   x2, x0, #0xf0000000    /* Mask off the top nybble */
+        lsr   x2, x2, #28
+        ldrb  w2, [x1, x2]           /* Convert to a char */
+        strb  w2, [x23]              /* -> UARTDR (Data Register) */
+        lsl   x0, x0, #4             /* Roll it through one nybble at a time */
+        subs  x3, x3, #1
+        b.ne  1b
+        ret
+
+hex:    .ascii "0123456789abcdef"
+        .align 2
+
+#else  /* EARLY_UART_ADDRESS */
+
+init_uart:
+.global early_puts
+early_puts:
+puts:
+putn:   mov   pc, lr
+
+#endif /* EARLY_UART_ADDRESS */
diff --git a/xen/arch/arm/arm64/mode_switch.S b/xen/arch/arm/arm64/mode_switch.S
new file mode 100644
index 0000000..4c38181
--- /dev/null
+++ b/xen/arch/arm/arm64/mode_switch.S
@@ -0,0 +1,83 @@
+/*
+ * xen/arch/arm/arm64/mode_switch.S
+ *
+ * Start-of day code to take a CPU from EL3 to EL2. Largely taken from
+ *       bootwrapper.
+ *
+ * Ian Campbell <ian.campbell@citrix.com>
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <asm/config.h>
+#include <asm/page.h>
+#include <asm/asm_defns.h>
+
+/* Get up a CPU into EL2.  Clobbers x0-x3.
+ *
+ * Expects x22 == CPU number
+ * Expects x30  == EL2 entry point
+ *
+ * This code is specific to the VE model, and not intended to be used
+ * on production systems.  As such it's a bit hackier than the main
+ * boot code in head.S.  In future it will be replaced by better
+ * integration with the bootloader/firmware so that Xen always starts
+ * at EL2.
+ */
+
+.globl enter_el2_mode
+enter_el2_mode:
+        mov     x0, #0x30                       // RES1
+        orr     x0, x0, #(1 << 0)               // Non-secure EL1
+        orr     x0, x0, #(1 << 8)               // HVC enable
+        orr     x0, x0, #(1 << 10)              // 64-bit EL2
+        msr     scr_el3, x0
+
+        msr     cptr_el3, xzr                   // Disable copro. traps to EL3
+
+        ldr     x0, =0x01800000                 // 24Mhz
+        msr     cntfrq_el0, x0
+
+        /*
+         * Check for the primary CPU to avoid a race on the distributor
+         * registers.
+         */
+        cbnz    x22, 1f
+
+        ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET) // GICD_CTLR
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+1:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_DR_OFFSET+0x80) // GICD_IGROUPR
+        mov     w0, #~0                         // Grp1 interrupts
+        str     w0, [x1], #4
+        b.ne    2f                              // Only local interrupts for secondary CPUs
+        str     w0, [x1], #4
+        str     w0, [x1], #4
+
+2:      ldr     x1, =(GIC_BASE_ADDRESS+GIC_CR_OFFSET) // GICC_CTLR
+        ldr     w0, [x1]
+        mov     w0, #3                          // EnableGrp0 | EnableGrp1
+        str     w0, [x1]
+
+        mov     w0, #1 << 7                     // allow NS access to GICC_PMR
+        str     w0, [x1, #4]                    // GICC_PMR
+
+        msr     sctlr_el2, xzr
+
+        /*
+         * Prepare the switch to the EL2_SP1 mode from EL3
+         */
+        msr     elr_el3, x30                    // Return to desired function
+        mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+        msr     spsr_el3, x1
+        eret
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 50e0c4b..5136b79 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -11,7 +11,13 @@
 
 ENTRY(start)
 
-OUTPUT_ARCH(arm)
+#if defined(__arm__)
+#define FORMAT arm
+#elif defined(__aarch64__)
+#define FORMAT aarch64
+#endif
+
+OUTPUT_ARCH(FORMAT)
 
 PHDRS
 {
@@ -85,9 +91,9 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
-       . = ALIGN(4);
+       . = ALIGN(BYTES_PER_LONG);
        __CTOR_LIST__ = .;
-       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
        *(.ctors)
        LONG(0)
        __CTOR_END__ = .;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index cd74950..45ded77 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -38,6 +38,7 @@
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff000004
+#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
 
 /*
  * Attribute Indexes.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 6ae1009..5306f79 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -172,6 +172,8 @@ typedef uint64_t xen_callback_t;
 
 /* 0-4: Mode */
 #define PSR_MODE_MASK 0x1f
+
+/* 32 bit modes */
 #define PSR_MODE_USR 0x10
 #define PSR_MODE_FIQ 0x11
 #define PSR_MODE_IRQ 0x12
@@ -182,6 +184,18 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
+/* 64 bit modes */
+#ifdef CONFIG_ARM_64
+#define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
+#define PSR_MODE_EL3h 0x0d
+#define PSR_MODE_EL3t 0x0c
+#define PSR_MODE_EL2h 0x09
+#define PSR_MODE_EL2t 0x08
+#define PSR_MODE_EL1h 0x05
+#define PSR_MODE_EL1t 0x04
+#define PSR_MODE_EL0t 0x00
+#endif
+
 #define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
 #define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
 #define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index 5538d8e..cc8b5fd 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -102,7 +102,7 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "../arch-x86/hvm/save.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined(__aarch64__)
 #include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index c4d08d6..e9431e2 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -31,7 +31,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 #include "arch-x86/xen.h"
-#elif defined(__arm__)
+#elif defined(__arm__) || defined (__aarch64__)
 #include "arch-arm.h"
 #else
 #error "Unsupported architecture"
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index e8f6508..218bb18 100644
--- 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(__arm__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 #define XEN_ELF_LITTLE_ENDIAN
 #else
 #error define architectural endianness
-- 
1.7.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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTp-00086F-DD; Fri, 22 Feb 2013 08:59:45 +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 1U8oTn-000862-F3
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:43 +0000
Received: from [85.158.137.99:59085] by server-15.bemta-3.messagelabs.com id
	0A/1C-25405-E7337215; Fri, 22 Feb 2013 08:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361523580!12405602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13592 invoked from network); 22 Feb 2013 08:59:41 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518204"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-2p;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:43 +0000
Message-ID: <1361523505-7604-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 04/46] xen: consolidate implementations of
	LOG() 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

arm64 is going to add another one shortly, so take control now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
---
 xen/arch/arm/arm32/asm-offsets.c  |    8 +-------
 xen/arch/x86/x86_64/asm-offsets.c |    8 +-------
 xen/include/xen/bitops.h          |    7 +++++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index 104430a..776c974 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -18,13 +19,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
    OFFSET(UREGS_sp, struct cpu_user_regs, sp);
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index b6d1919..6dc832c 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/perfc.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <compat/xen.h>
 #include <asm/fixmap.h>
 #include <asm/hardirq.h>
@@ -20,13 +21,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
     OFFSET(UREGS_r15, struct cpu_user_regs, r15);
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 190d96b..c6a78b6 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -175,4 +175,11 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
     return (word >> shift) | (word << (32 - shift));
 }
 
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
 #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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTp-00086F-DD; Fri, 22 Feb 2013 08:59:45 +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 1U8oTn-000862-F3
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:43 +0000
Received: from [85.158.137.99:59085] by server-15.bemta-3.messagelabs.com id
	0A/1C-25405-E7337215; Fri, 22 Feb 2013 08:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361523580!12405602!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13592 invoked from network); 22 Feb 2013 08:59:41 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518204"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-2p;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:43 +0000
Message-ID: <1361523505-7604-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 04/46] xen: consolidate implementations of
	LOG() 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

arm64 is going to add another one shortly, so take control now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
---
 xen/arch/arm/arm32/asm-offsets.c  |    8 +-------
 xen/arch/x86/x86_64/asm-offsets.c |    8 +-------
 xen/include/xen/bitops.h          |    7 +++++++
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm32/asm-offsets.c b/xen/arch/arm/arm32/asm-offsets.c
index 104430a..776c974 100644
--- a/xen/arch/arm/arm32/asm-offsets.c
+++ b/xen/arch/arm/arm32/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <public/xen.h>
 #include <asm/current.h>
 
@@ -18,13 +19,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
    OFFSET(UREGS_sp, struct cpu_user_regs, sp);
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index b6d1919..6dc832c 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -8,6 +8,7 @@
 #include <xen/config.h>
 #include <xen/perfc.h>
 #include <xen/sched.h>
+#include <xen/bitops.h>
 #include <compat/xen.h>
 #include <asm/fixmap.h>
 #include <asm/hardirq.h>
@@ -20,13 +21,6 @@
 #define OFFSET(_sym, _str, _mem) \
     DEFINE(_sym, offsetof(_str, _mem));
 
-/* base-2 logarithm */
-#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
-#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
-#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
-#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
-#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
-
 void __dummy__(void)
 {
     OFFSET(UREGS_r15, struct cpu_user_regs, r15);
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 190d96b..c6a78b6 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -175,4 +175,11 @@ static inline __u32 ror32(__u32 word, unsigned int shift)
     return (word >> shift) | (word << (32 - shift));
 }
 
+/* base-2 logarithm */
+#define __L2(_x)  (((_x) & 0x00000002) ?   1 : 0)
+#define __L4(_x)  (((_x) & 0x0000000c) ? ( 2 + __L2( (_x)>> 2)) : __L2( _x))
+#define __L8(_x)  (((_x) & 0x000000f0) ? ( 4 + __L4( (_x)>> 4)) : __L4( _x))
+#define __L16(_x) (((_x) & 0x0000ff00) ? ( 8 + __L8( (_x)>> 8)) : __L8( _x))
+#define LOG_2(_x) (((_x) & 0xffff0000) ? (16 + __L16((_x)>>16)) : __L16(_x))
+
 #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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTt-00087D-Kv; Fri, 22 Feb 2013 08:59: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 1U8oTs-00086e-AZ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:48 +0000
Received: from [85.158.137.99:2093] by server-2.bemta-3.messagelabs.com id
	83/E5-25961-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24919 invoked from network); 22 Feb 2013 08:59:41 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955717"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-2Q;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:42 +0000
Message-ID: <1361523505-7604-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 03/46] arm: avoid inline asm for dsb, isb,
	wfi and sev.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
synonymous) on arm32 but we have a macro so lets use it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c  |    5 ++++-
 xen/arch/arm/smpboot.c |   10 ++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 63a166d..2445b6a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -29,7 +29,10 @@ void idle_loop(void)
 
         local_irq_disable();
         if ( cpu_is_haltable(smp_processor_id()) )
-            asm volatile ("dsb; wfi");
+        {
+            dsb();
+            wfi();
+        }
         local_irq_enable();
 
         do_tasklet();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 8936123..d9b43a8 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -122,7 +122,8 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
         /* TODO: handle boards where CPUIDs are not contiguous */
         *gate = i;
         flush_xen_dcache(*gate);
-        asm volatile("isb; sev");
+        isb();
+        sev();
         /* And wait for it to respond */
         while ( ready_cpus < i )
             smp_rmb();
@@ -204,8 +205,8 @@ void stop_cpu(void)
     /* Make sure the write happens before we sleep forever */
     dsb();
     isb();
-    while ( 1 ) 
-        asm volatile("wfi");
+    while ( 1 )
+        wfi();
 }
 
 /* Bring up a remote CPU */
@@ -220,7 +221,8 @@ int __cpu_up(unsigned int cpu)
     /* we need to make sure that the change to smp_up_cpu is visible to
      * secondary cpus with D-cache off */
     flush_xen_dcache(smp_up_cpu);
-    asm volatile("isb; sev");
+    isb();
+    sev();
 
     while ( !cpu_online(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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTt-00087D-Kv; Fri, 22 Feb 2013 08:59: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 1U8oTs-00086e-AZ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:48 +0000
Received: from [85.158.137.99:2093] by server-2.bemta-3.messagelabs.com id
	83/E5-25961-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24919 invoked from network); 22 Feb 2013 08:59:41 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955717"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-2Q;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:42 +0000
Message-ID: <1361523505-7604-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 03/46] arm: avoid inline asm for dsb, isb,
	wfi and sev.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
synonymous) on arm32 but we have a macro so lets use it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain.c  |    5 ++++-
 xen/arch/arm/smpboot.c |   10 ++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 63a166d..2445b6a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -29,7 +29,10 @@ void idle_loop(void)
 
         local_irq_disable();
         if ( cpu_is_haltable(smp_processor_id()) )
-            asm volatile ("dsb; wfi");
+        {
+            dsb();
+            wfi();
+        }
         local_irq_enable();
 
         do_tasklet();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 8936123..d9b43a8 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -122,7 +122,8 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
         /* TODO: handle boards where CPUIDs are not contiguous */
         *gate = i;
         flush_xen_dcache(*gate);
-        asm volatile("isb; sev");
+        isb();
+        sev();
         /* And wait for it to respond */
         while ( ready_cpus < i )
             smp_rmb();
@@ -204,8 +205,8 @@ void stop_cpu(void)
     /* Make sure the write happens before we sleep forever */
     dsb();
     isb();
-    while ( 1 ) 
-        asm volatile("wfi");
+    while ( 1 )
+        wfi();
 }
 
 /* Bring up a remote CPU */
@@ -220,7 +221,8 @@ int __cpu_up(unsigned int cpu)
     /* we need to make sure that the change to smp_up_cpu is visible to
      * secondary cpus with D-cache off */
     flush_xen_dcache(smp_up_cpu);
-    asm volatile("isb; sev");
+    isb();
+    sev();
 
     while ( !cpu_online(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 Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTu-00087Q-0q; Fri, 22 Feb 2013 08:59:50 +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 1U8oTs-00086f-CS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:48 +0000
Received: from [85.158.137.99:48214] by server-3.bemta-3.messagelabs.com id
	EF/C7-31070-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25470 invoked from network); 22 Feb 2013 08:59:45 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955720"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-5L;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:46 +0000
Message-ID: <1361523505-7604-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 07/46] xen: arm64: 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>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: no change, but these need to be revisited considering the interaction of
sev/wfe etc. May need to rework the generic code in order to make best use of
wfe (on 32-bit ARM too)
---
 xen/include/asm-arm/arm32/spinlock.h |  141 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/spinlock.h |  125 ++++++++++++++++++++++++++++++
 xen/include/asm-arm/spinlock.h       |  135 ++------------------------------
 3 files changed, 273 insertions(+), 128 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/spinlock.h
 create mode 100644 xen/include/asm-arm/arm64/spinlock.h

diff --git a/xen/include/asm-arm/arm32/spinlock.h b/xen/include/asm-arm/arm32/spinlock.h
new file mode 100644
index 0000000..a7bcdbf
--- /dev/null
+++ b/xen/include/asm-arm/arm32/spinlock.h
@@ -0,0 +1,141 @@
+#ifndef __ASM_ARM32_SPINLOCK_H
+#define __ASM_ARM32_SPINLOCK_H
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/spinlock.h b/xen/include/asm-arm/arm64/spinlock.h
new file mode 100644
index 0000000..52ad688
--- /dev/null
+++ b/xen/include/asm-arm/arm64/spinlock.h
@@ -0,0 +1,125 @@
+/*
+ * Derived from Linux arch64 spinlock.h which is:
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM64_SPINLOCK_H
+#define __ASM_ARM64_SPINLOCK_H
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&lock->lock), "r" (0) : "memory");
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&lock->lock), "r" (1)
+        : "memory");
+
+    return !tmp;
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2 = 1;
+
+    asm volatile(
+        "       ldaxr   %w0, [%2]\n"
+        "       add     %w0, %w0, #1\n"
+        "       tbnz    %w0, #31, 1f\n"
+        "       stxr    %w1, %w0, [%2]\n"
+        "1:\n"
+        : "=&r" (tmp), "+r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+
+    return !tmp2;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&rw->lock), "r" (0x80000000)
+        : "memory");
+
+    return !tmp;
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2;
+
+    asm volatile(
+        "1:     ldxr    %w0, [%2]\n"
+        "       sub     %w0, %w0, #1\n"
+        "       stlxr   %w1, %w0, [%2]\n"
+        "       cbnz    %w1, 1b\n"
+        : "=&r" (tmp), "=&r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&rw->lock), "r" (0) : "memory");
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
index a66b4eb..a064f73 100644
--- a/xen/include/asm-arm/spinlock.h
+++ b/xen/include/asm-arm/spinlock.h
@@ -4,134 +4,13 @@
 #include <xen/config.h>
 #include <xen/lib.h>
 
-static inline void dsb_sev(void)
-{
-    __asm__ __volatile__ (
-        "dsb\n"
-        "sev\n"
-        );
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_spinlock_t;
-
-#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
-
-#define _raw_spin_is_locked(x)          ((x)->lock != 0)
-
-static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
-{
-    ASSERT(_raw_spin_is_locked(lock));
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"   str     %1, [%0]\n"
-    :
-    : "r" (&lock->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"   ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&lock->lock), "r" (1)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_rwlock_t;
-
-#define _RAW_RW_LOCK_UNLOCKED { 0 }
-
-static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2 = 1;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   adds    %0, %0, #1\n"
-"   strexpl %1, %0, [%2]\n"
-    : "=&r" (tmp), "+r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    smp_mb();
-    return tmp2 == 0;
-}
-
-static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&rw->lock), "r" (0x80000000)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-static inline void _raw_read_unlock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2;
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   sub     %0, %0, #1\n"
-"   strex   %1, %0, [%2]\n"
-"   teq     %1, #0\n"
-"   bne     1b"
-    : "=&r" (tmp), "=&r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    if (tmp == 0)
-        dsb_sev();
-}
-
-static inline void _raw_write_unlock(raw_rwlock_t *rw)
-{
-    smp_mb();
-
-    __asm__ __volatile__(
-    "str    %1, [%0]\n"
-    :
-    : "r" (&rw->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-#define _raw_rw_is_locked(x) ((x)->lock != 0)
-#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/spinlock.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/spinlock.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #endif /* __ASM_SPINLOCK_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 Fri Feb 22 09:00:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oTu-00087Q-0q; Fri, 22 Feb 2013 08:59:50 +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 1U8oTs-00086f-CS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 08:59:48 +0000
Received: from [85.158.137.99:48214] by server-3.bemta-3.messagelabs.com id
	EF/C7-31070-38337215; Fri, 22 Feb 2013 08:59:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361523580!17562516!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25470 invoked from network); 22 Feb 2013 08:59:45 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955720"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-5L;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:46 +0000
Message-ID: <1361523505-7604-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 07/46] xen: arm64: 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>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: no change, but these need to be revisited considering the interaction of
sev/wfe etc. May need to rework the generic code in order to make best use of
wfe (on 32-bit ARM too)
---
 xen/include/asm-arm/arm32/spinlock.h |  141 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/spinlock.h |  125 ++++++++++++++++++++++++++++++
 xen/include/asm-arm/spinlock.h       |  135 ++------------------------------
 3 files changed, 273 insertions(+), 128 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/spinlock.h
 create mode 100644 xen/include/asm-arm/arm64/spinlock.h

diff --git a/xen/include/asm-arm/arm32/spinlock.h b/xen/include/asm-arm/arm32/spinlock.h
new file mode 100644
index 0000000..a7bcdbf
--- /dev/null
+++ b/xen/include/asm-arm/arm32/spinlock.h
@@ -0,0 +1,141 @@
+#ifndef __ASM_ARM32_SPINLOCK_H
+#define __ASM_ARM32_SPINLOCK_H
+
+static inline void dsb_sev(void)
+{
+    __asm__ __volatile__ (
+        "dsb\n"
+        "sev\n"
+        );
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"   str     %1, [%0]\n"
+    :
+    : "r" (&lock->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"   ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&lock->lock), "r" (1)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2 = 1;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   adds    %0, %0, #1\n"
+"   strexpl %1, %0, [%2]\n"
+    : "=&r" (tmp), "+r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    smp_mb();
+    return tmp2 == 0;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned long tmp;
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%1]\n"
+"   teq     %0, #0\n"
+"   strexeq %0, %2, [%1]"
+    : "=&r" (tmp)
+    : "r" (&rw->lock), "r" (0x80000000)
+    : "cc");
+
+    if (tmp == 0) {
+        smp_mb();
+        return 1;
+    } else {
+        return 0;
+    }
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned long tmp, tmp2;
+
+    smp_mb();
+
+    __asm__ __volatile__(
+"1: ldrex   %0, [%2]\n"
+"   sub     %0, %0, #1\n"
+"   strex   %1, %0, [%2]\n"
+"   teq     %1, #0\n"
+"   bne     1b"
+    : "=&r" (tmp), "=&r" (tmp2)
+    : "r" (&rw->lock)
+    : "cc");
+
+    if (tmp == 0)
+        dsb_sev();
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    smp_mb();
+
+    __asm__ __volatile__(
+    "str    %1, [%0]\n"
+    :
+    : "r" (&rw->lock), "r" (0)
+    : "cc");
+
+    dsb_sev();
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/spinlock.h b/xen/include/asm-arm/arm64/spinlock.h
new file mode 100644
index 0000000..52ad688
--- /dev/null
+++ b/xen/include/asm-arm/arm64/spinlock.h
@@ -0,0 +1,125 @@
+/*
+ * Derived from Linux arch64 spinlock.h which is:
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ASM_ARM64_SPINLOCK_H
+#define __ASM_ARM64_SPINLOCK_H
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_spinlock_t;
+
+#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+#define _raw_spin_is_locked(x)          ((x)->lock != 0)
+
+static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
+{
+    ASSERT(_raw_spin_is_locked(lock));
+
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&lock->lock), "r" (0) : "memory");
+}
+
+static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&lock->lock), "r" (1)
+        : "memory");
+
+    return !tmp;
+}
+
+typedef struct {
+    volatile unsigned int lock;
+} raw_rwlock_t;
+
+#define _RAW_RW_LOCK_UNLOCKED { 0 }
+
+static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2 = 1;
+
+    asm volatile(
+        "       ldaxr   %w0, [%2]\n"
+        "       add     %w0, %w0, #1\n"
+        "       tbnz    %w0, #31, 1f\n"
+        "       stxr    %w1, %w0, [%2]\n"
+        "1:\n"
+        : "=&r" (tmp), "+r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+
+    return !tmp2;
+}
+
+static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
+{
+    unsigned int tmp;
+
+    asm volatile(
+        "       ldaxr   %w0, [%1]\n"
+        "       cbnz    %w0, 1f\n"
+        "       stxr    %w0, %w2, [%1]\n"
+        "1:\n"
+        : "=&r" (tmp)
+        : "r" (&rw->lock), "r" (0x80000000)
+        : "memory");
+
+    return !tmp;
+}
+
+static inline void _raw_read_unlock(raw_rwlock_t *rw)
+{
+    unsigned int tmp, tmp2;
+
+    asm volatile(
+        "1:     ldxr    %w0, [%2]\n"
+        "       sub     %w0, %w0, #1\n"
+        "       stlxr   %w1, %w0, [%2]\n"
+        "       cbnz    %w1, 1b\n"
+        : "=&r" (tmp), "=&r" (tmp2)
+        : "r" (&rw->lock)
+        : "memory");
+}
+
+static inline void _raw_write_unlock(raw_rwlock_t *rw)
+{
+    asm volatile(
+        "       stlr    %w1, [%0]\n"
+        : : "r" (&rw->lock), "r" (0) : "memory");
+}
+
+#define _raw_rw_is_locked(x) ((x)->lock != 0)
+#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+
+#endif /* __ASM_SPINLOCK_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
index a66b4eb..a064f73 100644
--- a/xen/include/asm-arm/spinlock.h
+++ b/xen/include/asm-arm/spinlock.h
@@ -4,134 +4,13 @@
 #include <xen/config.h>
 #include <xen/lib.h>
 
-static inline void dsb_sev(void)
-{
-    __asm__ __volatile__ (
-        "dsb\n"
-        "sev\n"
-        );
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_spinlock_t;
-
-#define _RAW_SPIN_LOCK_UNLOCKED { 0 }
-
-#define _raw_spin_is_locked(x)          ((x)->lock != 0)
-
-static always_inline void _raw_spin_unlock(raw_spinlock_t *lock)
-{
-    ASSERT(_raw_spin_is_locked(lock));
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"   str     %1, [%0]\n"
-    :
-    : "r" (&lock->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-static always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"   ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&lock->lock), "r" (1)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-typedef struct {
-    volatile unsigned int lock;
-} raw_rwlock_t;
-
-#define _RAW_RW_LOCK_UNLOCKED { 0 }
-
-static always_inline int _raw_read_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2 = 1;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   adds    %0, %0, #1\n"
-"   strexpl %1, %0, [%2]\n"
-    : "=&r" (tmp), "+r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    smp_mb();
-    return tmp2 == 0;
-}
-
-static always_inline int _raw_write_trylock(raw_rwlock_t *rw)
-{
-    unsigned long tmp;
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%1]\n"
-"   teq     %0, #0\n"
-"   strexeq %0, %2, [%1]"
-    : "=&r" (tmp)
-    : "r" (&rw->lock), "r" (0x80000000)
-    : "cc");
-
-    if (tmp == 0) {
-        smp_mb();
-        return 1;
-    } else {
-        return 0;
-    }
-}
-
-static inline void _raw_read_unlock(raw_rwlock_t *rw)
-{
-    unsigned long tmp, tmp2;
-
-    smp_mb();
-
-    __asm__ __volatile__(
-"1: ldrex   %0, [%2]\n"
-"   sub     %0, %0, #1\n"
-"   strex   %1, %0, [%2]\n"
-"   teq     %1, #0\n"
-"   bne     1b"
-    : "=&r" (tmp), "=&r" (tmp2)
-    : "r" (&rw->lock)
-    : "cc");
-
-    if (tmp == 0)
-        dsb_sev();
-}
-
-static inline void _raw_write_unlock(raw_rwlock_t *rw)
-{
-    smp_mb();
-
-    __asm__ __volatile__(
-    "str    %1, [%0]\n"
-    :
-    : "r" (&rw->lock), "r" (0)
-    : "cc");
-
-    dsb_sev();
-}
-
-#define _raw_rw_is_locked(x) ((x)->lock != 0)
-#define _raw_rw_is_write_locked(x) ((x)->lock == 0x80000000)
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/spinlock.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/spinlock.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 #endif /* __ASM_SPINLOCK_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 Fri Feb 22 09:00:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oUc-00005V-46; Fri, 22 Feb 2013 09:00: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 1U8oUa-0008Vr-4s
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:00:32 +0000
Received: from [85.158.143.99:42181] by server-1.bemta-4.messagelabs.com id
	C0/90-06203-FA337215; Fri, 22 Feb 2013 09:00:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361523585!28716799!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3535 invoked from network); 22 Feb 2013 08:59:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955722"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-7q;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:49 +0000
Message-ID: <1361523505-7604-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 10/46] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: remove comment wondering if they should be inner-shareable flushes, they
    shouldn't for now.

    combine with other patch titled "TLB flushes." which followed in a couple
    of patches time.

    remove flush_guest_tlb(), nothing was calling it

    remove stray reference to flush branch predictor, which isn't necessary on
    64-bit.
---
 xen/include/asm-arm/arm32/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm32/page.h     |   69 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm64/page.h     |   67 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/flushtlb.h       |   34 +++++------------
 xen/include/asm-arm/page.h           |   67 ++++-----------------------------
 6 files changed, 222 insertions(+), 83 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm32/page.h
 create mode 100644 xen/include/asm-arm/arm64/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm64/page.h

diff --git a/xen/include/asm-arm/arm32/flushtlb.h b/xen/include/asm-arm/arm32/flushtlb.h
new file mode 100644
index 0000000..e6dabd4
--- /dev/null
+++ b/xen/include/asm-arm/arm32/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM32_FLUSHTLB_H__
+#define __ASM_ARM_ARM32_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALL);
+
+    dsb();
+    isb();
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
+
+    dsb();
+    isb();
+}
+
+#endif /* __ASM_ARM_ARM32_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
new file mode 100644
index 0000000..073b8d1
--- /dev/null
+++ b/xen/include/asm-arm/arm32/page.h
@@ -0,0 +1,69 @@
+#ifndef __ARM_ARM32_PAGE_H__
+#define __ARM_ARM32_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB and branch predictor.
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile (
+        "isb;"                        /* Ensure synchronization with previous changes to text */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (r0) /*dummy*/ : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile(STORE_CP32(0, TLBIMVAH)
+                     : : "r" (va) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM32_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/flushtlb.h b/xen/include/asm-arm/arm64/flushtlb.h
new file mode 100644
index 0000000..ca74fe3
--- /dev/null
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
+#define __ASM_ARM_ARM64_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi vmalle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi alle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+#endif /* __ASM_ARM_ARM64_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
new file mode 100644
index 0000000..636fb63
--- /dev/null
+++ b/xen/include/asm-arm/arm64/page.h
@@ -0,0 +1,67 @@
+#ifndef __ARM_ARM64_PAGE_H__
+#define __ARM_ARM64_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    asm volatile (
+        "isb;"       /* Ensure synchronization with previous changes to text */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "ic     iallu;"                 /* Flush I-cache */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    asm volatile (
+        "dsb    sy;"                    /* Ensure visibility of PTE writes */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile("tlbi vae2, %0;"
+                     : : "r" (va>>PAGE_SHIFT) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM64_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
index 23376ac..329fbb4 100644
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -1,5 +1,5 @@
-#ifndef __FLUSHTLB_H__
-#define __FLUSHTLB_H__
+#ifndef __ASM_ARM_FLUSHTLB_H__
+#define __ASM_ARM_FLUSHTLB_H__
 
 #include <xen/cpumask.h>
 
@@ -14,32 +14,18 @@ do {                                                                    \
 
 #define tlbflush_current_time()                 (0)
 
-/* Flush local TLBs, current VMID only */
-static inline void flush_tlb_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALL);
-
-    dsb();
-    isb();
-}
-
-/* Flush local TLBs, all VMIDs, non-hypervisor mode */
-static inline void flush_tlb_all_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
-
-    dsb();
-    isb();
-}
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/flushtlb.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/flushtlb.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 /* Flush specified CPUs' TLBs */
 void flush_tlb_mask(const cpumask_t *mask);
 
-#endif /* __FLUSHTLB_H__ */
+#endif /* __ASM_ARM_FLUSHTLB_H__ */
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 45ded77..8909375 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -250,6 +250,14 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/page.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/page.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /* Architectural minimum cacheline size is 4 32-bit words. */
 #define MIN_CACHELINE_BYTES 16
 /* Actual cacheline size on the boot CPU. */
@@ -282,65 +290,6 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
             : : "r" (_p), "m" (*_p));                                   \
 } while (0)
 
-
-/*
- * Flush all hypervisor mappings from the TLB and branch predictor.
- * This is needed after changing Xen code mappings.
- *
- * The caller needs to issue the necessary DSB and D-cache flushes
- * before calling flush_xen_text_tlb.
- */
-static inline void flush_xen_text_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile (
-        "isb;"                        /* Ensure synchronization with previous changes to text */
-        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
-        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
-        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
-        "dsb;"                        /* Ensure completion of TLB+BP flush */
-        "isb;"
-        : : "r" (r0) /*dummy*/ : "memory");
-}
-
-/*
- * Flush all hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile("dsb;" /* Ensure preceding are visible */
-                 STORE_CP32(0, TLBIALLH)
-                 "dsb;" /* Ensure completion of the TLB flush */
-                 "isb;"
-                 : : "r" (r0) /* dummy */: "memory");
-}
-
-/*
- * Flush a range of VA's hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
-{
-    unsigned long end = va + size;
-    dsb(); /* Ensure preceding are visible */
-    while ( va < end ) {
-        asm volatile(STORE_CP32(0, TLBIMVAH)
-                     : : "r" (va) : "memory");
-        va += PAGE_SIZE;
-    }
-    dsb(); /* Ensure completion of the TLB flush */
-    isb();
-}
-
-/* Flush all non-hypervisor mappings from the TLB */
-static inline void flush_guest_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
-}
-
 /* Print a walk of an arbitrary page table */
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
-- 
1.7.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 Feb 22 09:00:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:00: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 1U8oUc-00005V-46; Fri, 22 Feb 2013 09:00: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 1U8oUa-0008Vr-4s
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:00:32 +0000
Received: from [85.158.143.99:42181] by server-1.bemta-4.messagelabs.com id
	C0/90-06203-FA337215; Fri, 22 Feb 2013 09:00:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361523585!28716799!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3535 invoked from network); 22 Feb 2013 08:59:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:59:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8955722"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 08:58:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 03:58:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-7q;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:49 +0000
Message-ID: <1361523505-7604-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 10/46] xen: arm64: TLB flushes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: remove comment wondering if they should be inner-shareable flushes, they
    shouldn't for now.

    combine with other patch titled "TLB flushes." which followed in a couple
    of patches time.

    remove flush_guest_tlb(), nothing was calling it

    remove stray reference to flush branch predictor, which isn't necessary on
    64-bit.
---
 xen/include/asm-arm/arm32/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm32/page.h     |   69 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/flushtlb.h |   34 +++++++++++++++++
 xen/include/asm-arm/arm64/page.h     |   67 +++++++++++++++++++++++++++++++++
 xen/include/asm-arm/flushtlb.h       |   34 +++++------------
 xen/include/asm-arm/page.h           |   67 ++++-----------------------------
 6 files changed, 222 insertions(+), 83 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm32/page.h
 create mode 100644 xen/include/asm-arm/arm64/flushtlb.h
 create mode 100644 xen/include/asm-arm/arm64/page.h

diff --git a/xen/include/asm-arm/arm32/flushtlb.h b/xen/include/asm-arm/arm32/flushtlb.h
new file mode 100644
index 0000000..e6dabd4
--- /dev/null
+++ b/xen/include/asm-arm/arm32/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM32_FLUSHTLB_H__
+#define __ASM_ARM_ARM32_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALL);
+
+    dsb();
+    isb();
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    dsb();
+
+    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
+
+    dsb();
+    isb();
+}
+
+#endif /* __ASM_ARM_ARM32_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
new file mode 100644
index 0000000..073b8d1
--- /dev/null
+++ b/xen/include/asm-arm/arm32/page.h
@@ -0,0 +1,69 @@
+#ifndef __ARM_ARM32_PAGE_H__
+#define __ARM_ARM32_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB and branch predictor.
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile (
+        "isb;"                        /* Ensure synchronization with previous changes to text */
+        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
+        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
+        "dsb;"                        /* Ensure completion of TLB+BP flush */
+        "isb;"
+        : : "r" (r0) /*dummy*/ : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    register unsigned long r0 asm ("r0");
+    asm volatile("dsb;" /* Ensure preceding are visible */
+                 STORE_CP32(0, TLBIALLH)
+                 "dsb;" /* Ensure completion of the TLB flush */
+                 "isb;"
+                 : : "r" (r0) /* dummy */: "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile(STORE_CP32(0, TLBIMVAH)
+                     : : "r" (va) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM32_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/flushtlb.h b/xen/include/asm-arm/arm64/flushtlb.h
new file mode 100644
index 0000000..ca74fe3
--- /dev/null
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -0,0 +1,34 @@
+#ifndef __ASM_ARM_ARM64_FLUSHTLB_H__
+#define __ASM_ARM_ARM64_FLUSHTLB_H__
+
+/* Flush local TLBs, current VMID only */
+static inline void flush_tlb_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi vmalle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+/* Flush local TLBs, all VMIDs, non-hypervisor mode */
+static inline void flush_tlb_all_local(void)
+{
+    asm volatile(
+        "dsb sy;"
+        "tlbi alle1;"
+        "dsb sy;"
+        "isb;"
+        : : : "memory");
+}
+
+#endif /* __ASM_ARM_ARM64_FLUSHTLB_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
new file mode 100644
index 0000000..636fb63
--- /dev/null
+++ b/xen/include/asm-arm/arm64/page.h
@@ -0,0 +1,67 @@
+#ifndef __ARM_ARM64_PAGE_H__
+#define __ARM_ARM64_PAGE_H__
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Flush all hypervisor mappings from the TLB
+ * This is needed after changing Xen code mappings.
+ *
+ * The caller needs to issue the necessary DSB and D-cache flushes
+ * before calling flush_xen_text_tlb.
+ */
+static inline void flush_xen_text_tlb(void)
+{
+    asm volatile (
+        "isb;"       /* Ensure synchronization with previous changes to text */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "ic     iallu;"                 /* Flush I-cache */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush all hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb(void)
+{
+    asm volatile (
+        "dsb    sy;"                    /* Ensure visibility of PTE writes */
+        "tlbi   alle2;"                 /* Flush hypervisor TLB */
+        "dsb    sy;"                    /* Ensure completion of TLB flush */
+        "isb;"
+        : : : "memory");
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the data TLB. This is not
+ * sufficient when changing code mappings or for self modifying code.
+ */
+static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
+{
+    unsigned long end = va + size;
+    dsb(); /* Ensure preceding are visible */
+    while ( va < end ) {
+        asm volatile("tlbi vae2, %0;"
+                     : : "r" (va>>PAGE_SHIFT) : "memory");
+        va += PAGE_SIZE;
+    }
+    dsb(); /* Ensure completion of the TLB flush */
+    isb();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM64_PAGE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h
index 23376ac..329fbb4 100644
--- a/xen/include/asm-arm/flushtlb.h
+++ b/xen/include/asm-arm/flushtlb.h
@@ -1,5 +1,5 @@
-#ifndef __FLUSHTLB_H__
-#define __FLUSHTLB_H__
+#ifndef __ASM_ARM_FLUSHTLB_H__
+#define __ASM_ARM_FLUSHTLB_H__
 
 #include <xen/cpumask.h>
 
@@ -14,32 +14,18 @@ do {                                                                    \
 
 #define tlbflush_current_time()                 (0)
 
-/* Flush local TLBs, current VMID only */
-static inline void flush_tlb_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALL);
-
-    dsb();
-    isb();
-}
-
-/* Flush local TLBs, all VMIDs, non-hypervisor mode */
-static inline void flush_tlb_all_local(void)
-{
-    dsb();
-
-    WRITE_CP32((uint32_t) 0, TLBIALLNSNH);
-
-    dsb();
-    isb();
-}
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/flushtlb.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/flushtlb.h>
+#else
+# error "unknown ARM variant"
+#endif
 
 /* Flush specified CPUs' TLBs */
 void flush_tlb_mask(const cpumask_t *mask);
 
-#endif /* __FLUSHTLB_H__ */
+#endif /* __ASM_ARM_FLUSHTLB_H__ */
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 45ded77..8909375 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -250,6 +250,14 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/page.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/page.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 /* Architectural minimum cacheline size is 4 32-bit words. */
 #define MIN_CACHELINE_BYTES 16
 /* Actual cacheline size on the boot CPU. */
@@ -282,65 +290,6 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
             : : "r" (_p), "m" (*_p));                                   \
 } while (0)
 
-
-/*
- * Flush all hypervisor mappings from the TLB and branch predictor.
- * This is needed after changing Xen code mappings.
- *
- * The caller needs to issue the necessary DSB and D-cache flushes
- * before calling flush_xen_text_tlb.
- */
-static inline void flush_xen_text_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile (
-        "isb;"                        /* Ensure synchronization with previous changes to text */
-        STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
-        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
-        STORE_CP32(0, BPIALL)         /* Flush branch predictor */
-        "dsb;"                        /* Ensure completion of TLB+BP flush */
-        "isb;"
-        : : "r" (r0) /*dummy*/ : "memory");
-}
-
-/*
- * Flush all hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    asm volatile("dsb;" /* Ensure preceding are visible */
-                 STORE_CP32(0, TLBIALLH)
-                 "dsb;" /* Ensure completion of the TLB flush */
-                 "isb;"
-                 : : "r" (r0) /* dummy */: "memory");
-}
-
-/*
- * Flush a range of VA's hypervisor mappings from the data TLB. This is not
- * sufficient when changing code mappings or for self modifying code.
- */
-static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
-{
-    unsigned long end = va + size;
-    dsb(); /* Ensure preceding are visible */
-    while ( va < end ) {
-        asm volatile(STORE_CP32(0, TLBIMVAH)
-                     : : "r" (va) : "memory");
-        va += PAGE_SIZE;
-    }
-    dsb(); /* Ensure completion of the TLB flush */
-    isb();
-}
-
-/* Flush all non-hypervisor mappings from the TLB */
-static inline void flush_guest_tlb(void)
-{
-    register unsigned long r0 asm ("r0");
-    WRITE_CP32(r0 /* dummy */, TLBIALLNSNH);
-}
-
 /* Print a walk of an arbitrary page table */
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
-- 
1.7.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 Feb 22 09:02:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oWh-0000wT-Mi; Fri, 22 Feb 2013 09:02: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 1U8oWf-0000vk-TS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:42 +0000
Received: from [85.158.143.99:3903] by server-1.bemta-4.messagelabs.com id
	08/63-06203-13437215; Fri, 22 Feb 2013 09:02:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361523757!28653388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21790 invoked from network); 22 Feb 2013 09:02:39 -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;
	22 Feb 2013 09:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518675"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-M7;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:04 +0000
Message-ID: <1361523505-7604-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 25/46] xen: arm64: add guest type to domain
	field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 32 bit PV is the only option.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Remove nested CONFIG_ARM_64
---
 xen/arch/arm/kernel.c        |    4 ++++
 xen/arch/arm/kernel.h        |    4 ++++
 xen/include/asm-arm/domain.h |   16 ++++++++++++++++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f694747..8f4a60d 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -228,6 +228,10 @@ int kernel_prepare(struct kernel_info *info)
     if (rc < 0)
         rc = kernel_try_elf_prepare(info, start, size);
 
+#ifdef CONFIG_ARM_64
+    info->type = DOMAIN_PV32; /* No 64-bit guest support yet */
+#endif
+
     return rc;
 }
 
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 58e942b..1776a4d 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -10,6 +10,10 @@
 #include <xen/device_tree.h>
 
 struct kernel_info {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
     struct dt_mem_info mem;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3732ac8..4e9d38d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -35,8 +35,24 @@ struct hvm_domain
     uint64_t              params[HVM_NR_PARAMS];
 }  __cacheline_aligned;
 
+#ifdef CONFIG_ARM_64
+enum domain_type {
+    DOMAIN_PV32,
+    DOMAIN_PV64,
+};
+#define is_pv32_domain(d) ((d)->arch.type == DOMAIN_PV32)
+#define is_pv64_domain(d) ((d)->arch.type == DOMAIN_PV64)
+#else
+#define is_pv32_domain(d) (1)
+#define is_pv64_domain(d) (0)
+#endif
+
 struct arch_domain
 {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     struct p2m_domain p2m;
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
-- 
1.7.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 Feb 22 09:02:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oWh-0000wT-Mi; Fri, 22 Feb 2013 09:02: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 1U8oWf-0000vk-TS
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:42 +0000
Received: from [85.158.143.99:3903] by server-1.bemta-4.messagelabs.com id
	08/63-06203-13437215; Fri, 22 Feb 2013 09:02:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361523757!28653388!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21790 invoked from network); 22 Feb 2013 09:02:39 -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;
	22 Feb 2013 09:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518675"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-M7;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:04 +0000
Message-ID: <1361523505-7604-25-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 25/46] xen: arm64: add guest type to domain
	field.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 32 bit PV is the only option.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Remove nested CONFIG_ARM_64
---
 xen/arch/arm/kernel.c        |    4 ++++
 xen/arch/arm/kernel.h        |    4 ++++
 xen/include/asm-arm/domain.h |   16 ++++++++++++++++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f694747..8f4a60d 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -228,6 +228,10 @@ int kernel_prepare(struct kernel_info *info)
     if (rc < 0)
         rc = kernel_try_elf_prepare(info, start, size);
 
+#ifdef CONFIG_ARM_64
+    info->type = DOMAIN_PV32; /* No 64-bit guest support yet */
+#endif
+
     return rc;
 }
 
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 58e942b..1776a4d 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -10,6 +10,10 @@
 #include <xen/device_tree.h>
 
 struct kernel_info {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     void *fdt; /* flat device tree */
     paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
     struct dt_mem_info mem;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3732ac8..4e9d38d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -35,8 +35,24 @@ struct hvm_domain
     uint64_t              params[HVM_NR_PARAMS];
 }  __cacheline_aligned;
 
+#ifdef CONFIG_ARM_64
+enum domain_type {
+    DOMAIN_PV32,
+    DOMAIN_PV64,
+};
+#define is_pv32_domain(d) ((d)->arch.type == DOMAIN_PV32)
+#define is_pv64_domain(d) ((d)->arch.type == DOMAIN_PV64)
+#else
+#define is_pv32_domain(d) (1)
+#define is_pv64_domain(d) (0)
+#endif
+
 struct arch_domain
 {
+#ifdef CONFIG_ARM_64
+    enum domain_type type;
+#endif
+
     struct p2m_domain p2m;
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
-- 
1.7.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 Feb 22 09:02:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWj-0000wt-3q; Fri, 22 Feb 2013 09:02: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 1U8oWh-0000w9-DY
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:43 +0000
Received: from [85.158.143.99:3916] by server-2.bemta-4.messagelabs.com id
	08/83-12656-23437215; Fri, 22 Feb 2013 09:02:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361523757!28653388!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21849 invoked from network); 22 Feb 2013 09:02:40 -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;
	22 Feb 2013 09:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518724"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:37 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-7s;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:24 +0000
Message-ID: <1361523505-7604-45-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 45/46] xen: arm: Fix guest mode for 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Need to check for the 64-bit EL2 modes, not 32-bit HYP mode.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/regs.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index 093caec..079c0ca 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -13,10 +13,16 @@
 #define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
 #define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
 #define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
-#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
 #define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
 #define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
 
+#ifdef CONFIG_ARM_32
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#else
+#define hyp_mode(r)     (psr_mode((r)->cpsr,PSR_MODE_EL2h) || \
+                         psr_mode((r)->cpsr,PSR_MODE_EL2t))
+#endif
+
 #define guest_mode(r)                                                         \
 ({                                                                            \
     unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
-- 
1.7.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 Feb 22 09:02:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWj-0000wt-3q; Fri, 22 Feb 2013 09:02: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 1U8oWh-0000w9-DY
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:43 +0000
Received: from [85.158.143.99:3916] by server-2.bemta-4.messagelabs.com id
	08/83-12656-23437215; Fri, 22 Feb 2013 09:02:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361523757!28653388!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21849 invoked from network); 22 Feb 2013 09:02:40 -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;
	22 Feb 2013 09:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518724"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:37 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-7s;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:24 +0000
Message-ID: <1361523505-7604-45-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 45/46] xen: arm: Fix guest mode for 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Need to check for the 64-bit EL2 modes, not 32-bit HYP mode.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/regs.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index 093caec..079c0ca 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -13,10 +13,16 @@
 #define svc_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SVC)
 #define mon_mode(r)     psr_mode((r)->cpsr,PSR_MODE_MON)
 #define abt_mode(r)     psr_mode((r)->cpsr,PSR_MODE_ABT)
-#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
 #define und_mode(r)     psr_mode((r)->cpsr,PSR_MODE_UND)
 #define sys_mode(r)     psr_mode((r)->cpsr,PSR_MODE_SYS)
 
+#ifdef CONFIG_ARM_32
+#define hyp_mode(r)     psr_mode((r)->cpsr,PSR_MODE_HYP)
+#else
+#define hyp_mode(r)     (psr_mode((r)->cpsr,PSR_MODE_EL2h) || \
+                         psr_mode((r)->cpsr,PSR_MODE_EL2t))
+#endif
+
 #define guest_mode(r)                                                         \
 ({                                                                            \
     unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);         \
-- 
1.7.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 Feb 22 09:02:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWk-0000xe-JJ; Fri, 22 Feb 2013 09:02:46 +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 1U8oWj-0000wk-8Y
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:45 +0000
Received: from [85.158.137.99:41306] by server-2.bemta-3.messagelabs.com id
	2A/EA-25961-43437215; Fri, 22 Feb 2013 09:02:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26955 invoked from network); 22 Feb 2013 09:02:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518770"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:41 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-04;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:16 +0000
Message-ID: <1361523505-7604-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 37/46] xen: arm: select_user_reg support for
	64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 75d42ab..6be70fa 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -72,6 +72,7 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
+#ifdef CONFIG_ARM_32
     /*
      * We rely heavily on the layout of cpu_user_regs to avoid having
      * to handle all of the registers individually. Use BUILD_BUG_ON to
@@ -124,6 +125,15 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
         BUG();
     }
 #undef REGOFFS
+#else
+    /* In 64 bit the syndrome register contains the AArch64 register
+     * number even if the trap was from AArch32 mode. Except that
+     * AArch32 R15 (PC) is encoded as 0b11111.
+     */
+    if ( reg == 0x1f /* && is aarch32 guest */)
+        return &regs->pc;
+    return &regs->x0 + reg;
+#endif
 }
 
 static const char *decode_fsc(uint32_t fsc, 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 Fri Feb 22 09:02:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWk-0000xe-JJ; Fri, 22 Feb 2013 09:02:46 +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 1U8oWj-0000wk-8Y
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:45 +0000
Received: from [85.158.137.99:41306] by server-2.bemta-3.messagelabs.com id
	2A/EA-25961-43437215; Fri, 22 Feb 2013 09:02:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26955 invoked from network); 22 Feb 2013 09:02:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518770"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:41 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-04;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:16 +0000
Message-ID: <1361523505-7604-37-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 37/46] xen: arm: select_user_reg support for
	64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 75d42ab..6be70fa 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -72,6 +72,7 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
+#ifdef CONFIG_ARM_32
     /*
      * We rely heavily on the layout of cpu_user_regs to avoid having
      * to handle all of the registers individually. Use BUILD_BUG_ON to
@@ -124,6 +125,15 @@ register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
         BUG();
     }
 #undef REGOFFS
+#else
+    /* In 64 bit the syndrome register contains the AArch64 register
+     * number even if the trap was from AArch32 mode. Except that
+     * AArch32 R15 (PC) is encoded as 0b11111.
+     */
+    if ( reg == 0x1f /* && is aarch32 guest */)
+        return &regs->pc;
+    return &regs->x0 + reg;
+#endif
 }
 
 static const char *decode_fsc(uint32_t fsc, 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 Fri Feb 22 09:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWp-00010S-85; Fri, 22 Feb 2013 09:02: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 1U8oWn-0000yd-5a
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:49 +0000
Received: from [85.158.137.99:3301] by server-3.bemta-3.messagelabs.com id
	33/8B-31070-83437215; Fri, 22 Feb 2013 09:02:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27359 invoked from network); 22 Feb 2013 09:02:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518799"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:46 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-DQ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:53 +0000
Message-ID: <1361523505-7604-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 14/46] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: - smp barriers are the same as up (which are conservative)
    - add dmb
---
 xen/include/asm-arm/arm32/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   20 ++++++++------------
 3 files changed, 66 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/system.h
 create mode 100644 xen/include/asm-arm/arm64/system.h

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
new file mode 100644
index 0000000..1380084
--- /dev/null
+++ b/xen/include/asm-arm/arm32/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_ARM32_SYSTEM_H
+#define __ASM_ARM32_SYSTEM_H
+
+#define sev() __asm__ __volatile__ ("sev" : : : "memory")
+#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
+#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        mb()
+#define smp_rmb()       rmb()
+#define smp_wmb()       wmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
new file mode 100644
index 0000000..53c6f96
--- /dev/null
+++ b/xen/include/asm-arm/arm64/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm64 */
+#ifndef __ASM_ARM64_SYSTEM_H
+#define __ASM_ARM64_SYSTEM_H
+
+#define sev()           asm volatile("sev" : : : "memory")
+#define wfe()           asm volatile("wfe" : : : "memory")
+#define wfi()           asm volatile("wfi" : : : "memory")
+
+#define isb()           asm volatile("isb" : : : "memory")
+#define dsb()           asm volatile("dsb sy" : : : "memory")
+#define dmb()           asm volatile("dmb sy" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        mb()
+#define smp_rmb()       rmb()
+#define smp_wmb()       wmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index f1e6f5e..2acef02 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -11,18 +11,6 @@
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
 
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
-
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           mb()
-
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
-
 /*
  * This is used to ensure the compiler did actually allocate the register we
  * asked it for some inline assembly sequences.  Apparently we can't trust
@@ -33,6 +21,14 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/system.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/system.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 extern void __bad_xchg(volatile void *, int);
 
 static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 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 Fri Feb 22 09:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWp-00010S-85; Fri, 22 Feb 2013 09:02: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 1U8oWn-0000yd-5a
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:49 +0000
Received: from [85.158.137.99:3301] by server-3.bemta-3.messagelabs.com id
	33/8B-31070-83437215; Fri, 22 Feb 2013 09:02:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27359 invoked from network); 22 Feb 2013 09:02:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518799"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:46 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-DQ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:53 +0000
Message-ID: <1361523505-7604-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 14/46] xen: arm64: barriers and wait for
	interrupts/events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: - smp barriers are the same as up (which are conservative)
    - add dmb
---
 xen/include/asm-arm/arm32/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   29 +++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   20 ++++++++------------
 3 files changed, 66 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/asm-arm/arm32/system.h
 create mode 100644 xen/include/asm-arm/arm64/system.h

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
new file mode 100644
index 0000000..1380084
--- /dev/null
+++ b/xen/include/asm-arm/arm32/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm */
+#ifndef __ASM_ARM32_SYSTEM_H
+#define __ASM_ARM32_SYSTEM_H
+
+#define sev() __asm__ __volatile__ ("sev" : : : "memory")
+#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
+#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+
+#define isb() __asm__ __volatile__ ("isb" : : : "memory")
+#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
+#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        mb()
+#define smp_rmb()       rmb()
+#define smp_wmb()       wmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
new file mode 100644
index 0000000..53c6f96
--- /dev/null
+++ b/xen/include/asm-arm/arm64/system.h
@@ -0,0 +1,29 @@
+/* Portions taken from Linux arch arm64 */
+#ifndef __ASM_ARM64_SYSTEM_H
+#define __ASM_ARM64_SYSTEM_H
+
+#define sev()           asm volatile("sev" : : : "memory")
+#define wfe()           asm volatile("wfe" : : : "memory")
+#define wfi()           asm volatile("wfi" : : : "memory")
+
+#define isb()           asm volatile("isb" : : : "memory")
+#define dsb()           asm volatile("dsb sy" : : : "memory")
+#define dmb()           asm volatile("dmb sy" : : : "memory")
+
+#define mb()            dsb()
+#define rmb()           dsb()
+#define wmb()           mb()
+
+#define smp_mb()        mb()
+#define smp_rmb()       rmb()
+#define smp_wmb()       wmb()
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index f1e6f5e..2acef02 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -11,18 +11,6 @@
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
 
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
-
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           mb()
-
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
-
 /*
  * This is used to ensure the compiler did actually allocate the register we
  * asked it for some inline assembly sequences.  Apparently we can't trust
@@ -33,6 +21,14 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#if defined(CONFIG_ARM_32)
+# include <asm/arm32/system.h>
+#elif defined(CONFIG_ARM_64)
+# include <asm/arm64/system.h>
+#else
+# error "unknown ARM variant"
+#endif
+
 extern void __bad_xchg(volatile void *, int);
 
 static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 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 Fri Feb 22 09:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWp-000116-QM; Fri, 22 Feb 2013 09:02: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 1U8oWo-0000zp-Mq
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:51 +0000
Received: from [85.158.139.211:41725] by server-15.bemta-5.messagelabs.com id
	08/4B-18914-A3437215; Fri, 22 Feb 2013 09:02:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 318 invoked from network); 22 Feb 2013 09:02:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956510"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:34 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Mk;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:06 +0000
Message-ID: <1361523505-7604-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 27/46] xen: arm: arm64 trap 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: use bitops.h provided LOG() macro
    use simple bl instead of preloading lr and b
    remove an incorrectly placed and inaccurate comment
    declare hyp_traps_vector as an array, avoiding & on uses
v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
    restoring state.
---
 xen/arch/arm/arm64/Makefile      |    2 +
 xen/arch/arm/arm64/asm-offsets.c |   58 +++++++++
 xen/arch/arm/arm64/entry.S       |  254 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/traps.c       |   56 +++++++++
 xen/arch/arm/smpboot.c           |    2 +-
 xen/arch/arm/traps.c             |   17 ++-
 xen/include/asm-arm/cpregs.h     |    1 +
 xen/include/asm-arm/processor.h  |    2 +-
 8 files changed, 386 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/arm/arm64/asm-offsets.c
 create mode 100644 xen/arch/arm/arm64/entry.S
 create mode 100644 xen/arch/arm/arm64/traps.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 815f305..be41f43 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,5 +1,7 @@
 subdir-y += lib
 
+obj-y += entry.o
 obj-y += mode_switch.o
 
+obj-y += traps.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
new file mode 100644
index 0000000..7949e3e
--- /dev/null
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -0,0 +1,58 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/bitops.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_LR, struct cpu_user_regs, lr);
+
+   OFFSET(UREGS_SP, struct cpu_user_regs, sp);
+   OFFSET(UREGS_PC, struct cpu_user_regs, pc);
+   OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
+
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_el0, struct cpu_user_regs, sp_el0);
+   OFFSET(UREGS_SP_el1, struct cpu_user_regs, sp_el1);
+   OFFSET(UREGS_ELR_el1, struct cpu_user_regs, elr_el1);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
new file mode 100644
index 0000000..e35b6ea
--- /dev/null
+++ b/xen/arch/arm/arm64/entry.S
@@ -0,0 +1,254 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+/*
+ * Register aliases.
+ */
+lr      .req    x30             // link register
+
+/*
+ * Stack pushing/popping (register pairs only). Equivalent to store decrement
+ * before, load increment after.
+ */
+        .macro  push, xreg1, xreg2
+        stp     \xreg1, \xreg2, [sp, #-16]!
+        .endm
+
+        .macro  pop, xreg1, xreg2
+        ldp     \xreg1, \xreg2, [sp], #16
+        .endm
+
+/*
+ * Save/restore guest mode specific state, outer stack frame
+ */
+        .macro  entry_guest, compat
+
+        add     x21, sp, #UREGS_SPSR_el1
+        mrs     x23, SPSR_EL1
+        str     x23, [x21]
+
+        .if \compat == 0 /* Aarch64 mode */
+
+        add     x21, sp, #UREGS_SP_el0
+        mrs     x22, SP_el0
+        str     x22, [x21]
+
+        add     x21, sp, #UREGS_ELR_el1
+        mrs     x22, SP_el1
+        mrs     x23, ELR_el1
+        stp     x22, x23, [x21]
+
+        .else             /* Aarch32 mode */
+
+        add     x21, sp, #UREGS_SPSR_fiq
+        mrs     x22, spsr_fiq
+        mrs     x23, spsr_irq
+        stp     w22, w23, [x21]
+
+        add     x21, sp, #UREGS_SPSR_und
+        mrs     x22, spsr_und
+        mrs     x23, spsr_abt
+        stp     w22, w23, [x21]
+
+        .endif
+
+        .endm
+
+/*
+ * Save state on entry to hypervisor
+ */
+        .macro  entry, hyp, compat
+        sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_SP)
+        push    x28, x29
+        push    x26, x27
+        push    x24, x25
+        push    x22, x23
+        push    x20, x21
+        push    x18, x19
+        push    x16, x17
+        push    x14, x15
+        push    x12, x13
+        push    x10, x11
+        push    x8, x9
+        push    x6, x7
+        push    x4, x5
+        push    x2, x3
+        push    x0, x1
+
+        .if \hyp == 1        /* Hypervisor mode */
+
+        add     x21, sp, #(UREGS_X0 - UREGS_SP)
+
+        .else                /* Guest mode */
+
+        entry_guest \compat
+        mov     x21, ~0 /* sp only valid for hyp frame XXX */
+
+        .endif
+
+        stp     lr, x21, [sp, #UREGS_LR]
+
+        mrs     x22, elr_el2
+        mrs     x23, spsr_el2
+        stp     x22, x23, [sp, #UREGS_PC]
+
+        .endm
+
+/*
+ * Bad Abort numbers
+ *-----------------
+ */
+#define BAD_SYNC        0
+#define BAD_IRQ         1
+#define BAD_FIQ         2
+#define BAD_ERROR       3
+
+        .macro  invalid, reason
+        mov     x0, sp
+        mov     x1, #\reason
+        b       do_bad_mode
+        .endm
+
+hyp_sync_invalid:
+        entry   hyp=1
+        invalid BAD_SYNC
+
+hyp_irq_invalid:
+        entry   hyp=1
+        invalid BAD_IRQ
+
+hyp_fiq_invalid:
+        entry   hyp=1
+        invalid BAD_FIQ
+
+hyp_error_invalid:
+        entry   hyp=1
+        invalid BAD_ERROR
+
+/* Traps taken in Current EL with SP_ELx */
+hyp_sync:
+        entry   hyp=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_hypervisor
+
+hyp_irq:
+        entry   hyp=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_hypervisor
+
+guest_sync:
+        entry   hyp=0, compat=0
+        invalid BAD_SYNC /* No AArch64 guest support yet */
+
+guest_irq:
+        entry   hyp=0, compat=0
+        invalid BAD_IRQ /* No AArch64 guest support yet */
+
+guest_fiq_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_FIQ
+
+guest_error_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_ERROR
+
+guest_sync_compat:
+        entry   hyp=0, compat=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_guest
+
+guest_irq_compat:
+        entry   hyp=0, compat=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_guest
+
+guest_fiq_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_FIQ
+
+guest_error_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_ERROR
+
+ENTRY(return_to_new_vcpu)
+        ldr     x21, [sp, #UREGS_CPSR]
+        and     x21, x21, #PSR_MODE_MASK
+        /* Returning to EL2? */
+        cmp     x21, #PSR_MODE_EL2t
+        ccmp    x21, #PSR_MODE_EL2h, #0x4, ne
+        b.eq    return_to_hypervisor /* Yes */
+        /* Fall thru */
+ENTRY(return_to_guest)
+        bl      leave_hypervisor_tail /* Disables interrupts on return */
+        /* Fall thru */
+ENTRY(return_to_hypervisor)
+        msr     daifset, #2 /* Mask interrupts */
+
+        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
+
+        pop     x0, x1
+        pop     x2, x3
+        pop     x4, x5
+        pop     x6, x7
+        pop     x8, x9
+
+        msr     elr_el2, x21                    // set up the return data
+        msr     spsr_el2, x22
+
+        pop     x10, x11
+        pop     x12, x13
+        pop     x14, x15
+        pop     x16, x17
+        pop     x18, x19
+        pop     x20, x21
+        pop     x22, x23
+        pop     x24, x25
+        pop     x26, x27
+        pop     x28, x29
+
+        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
+        eret
+
+/*
+ * Exception vectors.
+ */
+        .macro  ventry  label
+        .align  7
+        b       \label
+        .endm
+
+        .align  11
+ENTRY(hyp_traps_vector)
+        ventry  hyp_sync_invalid                // Synchronous EL2t
+        ventry  hyp_irq_invalid                 // IRQ EL2t
+        ventry  hyp_fiq_invalid                 // FIQ EL2t
+        ventry  hyp_error_invalid               // Error EL2t
+
+        ventry  hyp_sync                        // Synchronous EL2h
+        ventry  hyp_irq                         // IRQ EL2h
+        ventry  hyp_fiq_invalid                 // FIQ EL2h
+        ventry  hyp_error_invalid               // Error EL2h
+
+        ventry  guest_sync                      // Synchronous 64-bit EL0/EL1
+        ventry  guest_irq                       // IRQ 64-bit EL0/EL1
+        ventry  guest_fiq_invalid               // FIQ 64-bit EL0/EL1
+        ventry  guest_error_invalid             // Error 64-bit EL0/EL1
+
+        ventry  guest_sync_compat               // Synchronous 32-bit EL0/EL1
+        ventry  guest_irq_compat                // IRQ 32-bit EL0/EL1
+        ventry  guest_fiq_invalid_compat        // FIQ 32-bit EL0/EL1
+        ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
new file mode 100644
index 0000000..02ef992
--- /dev/null
+++ b/xen/arch/arm/arm64/traps.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/traps.c
+ *
+ * ARM AArch64 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <asm/system.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
+{
+    panic("Unhandled serror trap\n");
+}
+
+static const char *handler[]= {
+        "Synchronous Abort",
+        "IRQ",
+        "FIQ",
+        "Error"
+};
+
+asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
+{
+    uint64_t esr = READ_SYSREG64(ESR_EL2);
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
+           handler[reason], esr);
+
+    local_irq_disable();
+    panic("bad mode");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 5f0188f..75ee8a9 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f96365b..ccd698c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -628,7 +628,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
-void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
     uint32_t ttbr0 = READ_CP32(TTBR0);
@@ -636,7 +636,7 @@ void dump_guest_s1_walk(struct domain *d, uint32_t addr)
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
-    printk("dom%d VA 0x%08"PRIx32"\n", d->domain_id, addr);
+    printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
     printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
@@ -692,7 +692,11 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     mmio_info_t info;
 
     info.dabt = dabt;
+#ifdef CONFIG_ARM_32
     info.gva = READ_CP32(HDFAR);
+#else
+    info.gva = READ_SYSREG64(FAR_EL2);
+#endif
 
     if (dabt.s1ptw)
         goto bad_data_abort;
@@ -713,7 +717,7 @@ bad_data_abort:
 
     /* XXX inject a suitable fault into the guest */
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32"\n",
+           "    gva=%"PRIvaddr"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
            info.gva);
@@ -736,13 +740,17 @@ bad_data_abort:
 
 asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
 {
-    union hsr hsr = { .bits = READ_CP32(HSR) };
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
 
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_32(regs, hsr);
         break;
     case HSR_EC_CP15_64:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_64(regs, hsr);
         break;
     case HSR_EC_HVC:
@@ -754,6 +762,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
     default:
+ bad_trap:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
         do_unexpected_trap("Hypervisor", regs);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7a7c598..ccd8335 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -228,6 +228,7 @@
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
 #define CSSELR_EL1              CSSELR
+#define ESR_EL2                 HSR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 63f03ac..c1d7d70 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -238,7 +238,7 @@ union hsr {
 #endif
 
 #ifndef __ASSEMBLY__
-extern uint32_t hyp_traps_vector[8];
+extern uint32_t hyp_traps_vector[];
 
 void panic_PAR(uint64_t par);
 
-- 
1.7.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 Feb 22 09:02:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:02: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 1U8oWp-000116-QM; Fri, 22 Feb 2013 09:02: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 1U8oWo-0000zp-Mq
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:51 +0000
Received: from [85.158.139.211:41725] by server-15.bemta-5.messagelabs.com id
	08/4B-18914-A3437215; Fri, 22 Feb 2013 09:02:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 318 invoked from network); 22 Feb 2013 09:02:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956510"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:34 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Mk;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:06 +0000
Message-ID: <1361523505-7604-27-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 27/46] xen: arm: arm64 trap 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v3: use bitops.h provided LOG() macro
    use simple bl instead of preloading lr and b
    remove an incorrectly placed and inaccurate comment
    declare hyp_traps_vector as an array, avoiding & on uses
v2: Call leave_hypervisor_tail on exit back to guest, disable interrupts while
    restoring state.
---
 xen/arch/arm/arm64/Makefile      |    2 +
 xen/arch/arm/arm64/asm-offsets.c |   58 +++++++++
 xen/arch/arm/arm64/entry.S       |  254 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/arm64/traps.c       |   56 +++++++++
 xen/arch/arm/smpboot.c           |    2 +-
 xen/arch/arm/traps.c             |   17 ++-
 xen/include/asm-arm/cpregs.h     |    1 +
 xen/include/asm-arm/processor.h  |    2 +-
 8 files changed, 386 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/arm/arm64/asm-offsets.c
 create mode 100644 xen/arch/arm/arm64/entry.S
 create mode 100644 xen/arch/arm/arm64/traps.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 815f305..be41f43 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,5 +1,7 @@
 subdir-y += lib
 
+obj-y += entry.o
 obj-y += mode_switch.o
 
+obj-y += traps.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
new file mode 100644
index 0000000..7949e3e
--- /dev/null
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -0,0 +1,58 @@
+/*
+ * Generate definitions needed by assembly language modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ */
+#define COMPILE_OFFSETS
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/bitops.h>
+#include <public/xen.h>
+#include <asm/current.h>
+
+#define DEFINE(_sym, _val) \
+    __asm__ __volatile__ ( "\n->" #_sym " %0 " #_val : : "i" (_val) )
+#define BLANK() \
+    __asm__ __volatile__ ( "\n->" : : )
+#define OFFSET(_sym, _str, _mem) \
+    DEFINE(_sym, offsetof(_str, _mem));
+
+void __dummy__(void)
+{
+   OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_LR, struct cpu_user_regs, lr);
+
+   OFFSET(UREGS_SP, struct cpu_user_regs, sp);
+   OFFSET(UREGS_PC, struct cpu_user_regs, pc);
+   OFFSET(UREGS_CPSR, struct cpu_user_regs, cpsr);
+
+   OFFSET(UREGS_SPSR_el1, struct cpu_user_regs, spsr_el1);
+
+   OFFSET(UREGS_SPSR_fiq, struct cpu_user_regs, spsr_fiq);
+   OFFSET(UREGS_SPSR_irq, struct cpu_user_regs, spsr_irq);
+   OFFSET(UREGS_SPSR_und, struct cpu_user_regs, spsr_und);
+   OFFSET(UREGS_SPSR_abt, struct cpu_user_regs, spsr_abt);
+
+   OFFSET(UREGS_SP_el0, struct cpu_user_regs, sp_el0);
+   OFFSET(UREGS_SP_el1, struct cpu_user_regs, sp_el1);
+   OFFSET(UREGS_ELR_el1, struct cpu_user_regs, elr_el1);
+
+   OFFSET(UREGS_kernel_sizeof, struct cpu_user_regs, cpsr);
+   DEFINE(UREGS_user_sizeof, sizeof(struct cpu_user_regs));
+   BLANK();
+
+   DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+
+   OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
new file mode 100644
index 0000000..e35b6ea
--- /dev/null
+++ b/xen/arch/arm/arm64/entry.S
@@ -0,0 +1,254 @@
+#include <xen/config.h>
+#include <asm/asm_defns.h>
+#include <public/xen.h>
+
+/*
+ * Register aliases.
+ */
+lr      .req    x30             // link register
+
+/*
+ * Stack pushing/popping (register pairs only). Equivalent to store decrement
+ * before, load increment after.
+ */
+        .macro  push, xreg1, xreg2
+        stp     \xreg1, \xreg2, [sp, #-16]!
+        .endm
+
+        .macro  pop, xreg1, xreg2
+        ldp     \xreg1, \xreg2, [sp], #16
+        .endm
+
+/*
+ * Save/restore guest mode specific state, outer stack frame
+ */
+        .macro  entry_guest, compat
+
+        add     x21, sp, #UREGS_SPSR_el1
+        mrs     x23, SPSR_EL1
+        str     x23, [x21]
+
+        .if \compat == 0 /* Aarch64 mode */
+
+        add     x21, sp, #UREGS_SP_el0
+        mrs     x22, SP_el0
+        str     x22, [x21]
+
+        add     x21, sp, #UREGS_ELR_el1
+        mrs     x22, SP_el1
+        mrs     x23, ELR_el1
+        stp     x22, x23, [x21]
+
+        .else             /* Aarch32 mode */
+
+        add     x21, sp, #UREGS_SPSR_fiq
+        mrs     x22, spsr_fiq
+        mrs     x23, spsr_irq
+        stp     w22, w23, [x21]
+
+        add     x21, sp, #UREGS_SPSR_und
+        mrs     x22, spsr_und
+        mrs     x23, spsr_abt
+        stp     w22, w23, [x21]
+
+        .endif
+
+        .endm
+
+/*
+ * Save state on entry to hypervisor
+ */
+        .macro  entry, hyp, compat
+        sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_SP)
+        push    x28, x29
+        push    x26, x27
+        push    x24, x25
+        push    x22, x23
+        push    x20, x21
+        push    x18, x19
+        push    x16, x17
+        push    x14, x15
+        push    x12, x13
+        push    x10, x11
+        push    x8, x9
+        push    x6, x7
+        push    x4, x5
+        push    x2, x3
+        push    x0, x1
+
+        .if \hyp == 1        /* Hypervisor mode */
+
+        add     x21, sp, #(UREGS_X0 - UREGS_SP)
+
+        .else                /* Guest mode */
+
+        entry_guest \compat
+        mov     x21, ~0 /* sp only valid for hyp frame XXX */
+
+        .endif
+
+        stp     lr, x21, [sp, #UREGS_LR]
+
+        mrs     x22, elr_el2
+        mrs     x23, spsr_el2
+        stp     x22, x23, [sp, #UREGS_PC]
+
+        .endm
+
+/*
+ * Bad Abort numbers
+ *-----------------
+ */
+#define BAD_SYNC        0
+#define BAD_IRQ         1
+#define BAD_FIQ         2
+#define BAD_ERROR       3
+
+        .macro  invalid, reason
+        mov     x0, sp
+        mov     x1, #\reason
+        b       do_bad_mode
+        .endm
+
+hyp_sync_invalid:
+        entry   hyp=1
+        invalid BAD_SYNC
+
+hyp_irq_invalid:
+        entry   hyp=1
+        invalid BAD_IRQ
+
+hyp_fiq_invalid:
+        entry   hyp=1
+        invalid BAD_FIQ
+
+hyp_error_invalid:
+        entry   hyp=1
+        invalid BAD_ERROR
+
+/* Traps taken in Current EL with SP_ELx */
+hyp_sync:
+        entry   hyp=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_hypervisor
+
+hyp_irq:
+        entry   hyp=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_hypervisor
+
+guest_sync:
+        entry   hyp=0, compat=0
+        invalid BAD_SYNC /* No AArch64 guest support yet */
+
+guest_irq:
+        entry   hyp=0, compat=0
+        invalid BAD_IRQ /* No AArch64 guest support yet */
+
+guest_fiq_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_FIQ
+
+guest_error_invalid:
+        entry   hyp=0, compat=0
+        invalid BAD_ERROR
+
+guest_sync_compat:
+        entry   hyp=0, compat=1
+        msr     daifclr, #2
+        mov     x0, sp
+        bl      do_trap_hypervisor
+        b       return_to_guest
+
+guest_irq_compat:
+        entry   hyp=0, compat=1
+        mov     x0, sp
+        bl      do_trap_irq
+        b       return_to_guest
+
+guest_fiq_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_FIQ
+
+guest_error_invalid_compat:
+        entry   hyp=0, compat=1
+        invalid BAD_ERROR
+
+ENTRY(return_to_new_vcpu)
+        ldr     x21, [sp, #UREGS_CPSR]
+        and     x21, x21, #PSR_MODE_MASK
+        /* Returning to EL2? */
+        cmp     x21, #PSR_MODE_EL2t
+        ccmp    x21, #PSR_MODE_EL2h, #0x4, ne
+        b.eq    return_to_hypervisor /* Yes */
+        /* Fall thru */
+ENTRY(return_to_guest)
+        bl      leave_hypervisor_tail /* Disables interrupts on return */
+        /* Fall thru */
+ENTRY(return_to_hypervisor)
+        msr     daifset, #2 /* Mask interrupts */
+
+        ldp     x21, x22, [sp, #UREGS_PC]       // load ELR, SPSR
+
+        pop     x0, x1
+        pop     x2, x3
+        pop     x4, x5
+        pop     x6, x7
+        pop     x8, x9
+
+        msr     elr_el2, x21                    // set up the return data
+        msr     spsr_el2, x22
+
+        pop     x10, x11
+        pop     x12, x13
+        pop     x14, x15
+        pop     x16, x17
+        pop     x18, x19
+        pop     x20, x21
+        pop     x22, x23
+        pop     x24, x25
+        pop     x26, x27
+        pop     x28, x29
+
+        ldr     lr, [sp], #(UREGS_SPSR_el1 - UREGS_SP)
+        eret
+
+/*
+ * Exception vectors.
+ */
+        .macro  ventry  label
+        .align  7
+        b       \label
+        .endm
+
+        .align  11
+ENTRY(hyp_traps_vector)
+        ventry  hyp_sync_invalid                // Synchronous EL2t
+        ventry  hyp_irq_invalid                 // IRQ EL2t
+        ventry  hyp_fiq_invalid                 // FIQ EL2t
+        ventry  hyp_error_invalid               // Error EL2t
+
+        ventry  hyp_sync                        // Synchronous EL2h
+        ventry  hyp_irq                         // IRQ EL2h
+        ventry  hyp_fiq_invalid                 // FIQ EL2h
+        ventry  hyp_error_invalid               // Error EL2h
+
+        ventry  guest_sync                      // Synchronous 64-bit EL0/EL1
+        ventry  guest_irq                       // IRQ 64-bit EL0/EL1
+        ventry  guest_fiq_invalid               // FIQ 64-bit EL0/EL1
+        ventry  guest_error_invalid             // Error 64-bit EL0/EL1
+
+        ventry  guest_sync_compat               // Synchronous 32-bit EL0/EL1
+        ventry  guest_irq_compat                // IRQ 32-bit EL0/EL1
+        ventry  guest_fiq_invalid_compat        // FIQ 32-bit EL0/EL1
+        ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
new file mode 100644
index 0000000..02ef992
--- /dev/null
+++ b/xen/arch/arm/arm64/traps.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/traps.c
+ *
+ * ARM AArch64 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <asm/system.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
+{
+    panic("Unhandled serror trap\n");
+}
+
+static const char *handler[]= {
+        "Synchronous Abort",
+        "IRQ",
+        "FIQ",
+        "Error"
+};
+
+asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
+{
+    uint64_t esr = READ_SYSREG64(ESR_EL2);
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
+           handler[reason], esr);
+
+    local_irq_disable();
+    panic("bad mode");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 5f0188f..75ee8a9 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f96365b..ccd698c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -628,7 +628,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 }
 
-void dump_guest_s1_walk(struct domain *d, uint32_t addr)
+void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
     uint32_t ttbr0 = READ_CP32(TTBR0);
@@ -636,7 +636,7 @@ void dump_guest_s1_walk(struct domain *d, uint32_t addr)
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
-    printk("dom%d VA 0x%08"PRIx32"\n", d->domain_id, addr);
+    printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
     printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
@@ -692,7 +692,11 @@ static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
     mmio_info_t info;
 
     info.dabt = dabt;
+#ifdef CONFIG_ARM_32
     info.gva = READ_CP32(HDFAR);
+#else
+    info.gva = READ_SYSREG64(FAR_EL2);
+#endif
 
     if (dabt.s1ptw)
         goto bad_data_abort;
@@ -713,7 +717,7 @@ bad_data_abort:
 
     /* XXX inject a suitable fault into the guest */
     printk("Guest data abort: %s%s%s\n"
-           "    gva=%"PRIx32"\n",
+           "    gva=%"PRIvaddr"\n",
            msg, dabt.s1ptw ? " S2 during S1" : "",
            fsc_level_str(level),
            info.gva);
@@ -736,13 +740,17 @@ bad_data_abort:
 
 asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
 {
-    union hsr hsr = { .bits = READ_CP32(HSR) };
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
 
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_32(regs, hsr);
         break;
     case HSR_EC_CP15_64:
+        if ( ! is_pv32_domain(current->domain) )
+            goto bad_trap;
         do_cp15_64(regs, hsr);
         break;
     case HSR_EC_HVC:
@@ -754,6 +762,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
         do_trap_data_abort_guest(regs, hsr.dabt);
         break;
     default:
+ bad_trap:
         printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x Syndrome=%"PRIx32"\n",
                hsr.bits, hsr.ec, hsr.len, hsr.iss);
         do_unexpected_trap("Hypervisor", regs);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 7a7c598..ccd8335 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -228,6 +228,7 @@
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
 #define CSSELR_EL1              CSSELR
+#define ESR_EL2                 HSR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 63f03ac..c1d7d70 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -238,7 +238,7 @@ union hsr {
 #endif
 
 #ifndef __ASSEMBLY__
-extern uint32_t hyp_traps_vector[8];
+extern uint32_t hyp_traps_vector[];
 
 void panic_PAR(uint64_t par);
 
-- 
1.7.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 Feb 22 09:03:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oWy-00017E-7M; Fri, 22 Feb 2013 09:03: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 1U8oWx-00012E-5H
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:59 +0000
Received: from [85.158.143.99:60727] by server-1.bemta-4.messagelabs.com id
	3A/B3-06203-24437215; Fri, 22 Feb 2013 09:02:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361523778!18264332!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10915 invoked from network); 22 Feb 2013 09:02:58 -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; 22 Feb 2013 09:02:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 09:02:58 +0000
Message-Id: <5127428C02000078000C040A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 09:03:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: aliguori@us.ibm.com, mst@redhat.com, stefano.stabellini@eu.citrix.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
 base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    if (xen_enabled()) {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> +    } else {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> +    }
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }

Isn't this the wrong way round (big endian, when it needs to be
little)?

Or else, this read and calculation

>+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 4);
>+    pci_hole_size = 0x100000000ULL - pci_hole_start;

would seem wrong (e.g. if the granularity is meant to be 16M).

And then again, wasting 4 bytes of config space on something that
one ought to be allowed to expect to be at least 64k-aligned seems
questionable too. hvmloader surely could align the value up to the
next 64k boundary before writing the - then only word size - field.
That would come closer to how real chipsets normally implement
things like this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:03:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oWy-00017E-7M; Fri, 22 Feb 2013 09:03: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 1U8oWx-00012E-5H
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:02:59 +0000
Received: from [85.158.143.99:60727] by server-1.bemta-4.messagelabs.com id
	3A/B3-06203-24437215; Fri, 22 Feb 2013 09:02:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361523778!18264332!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10915 invoked from network); 22 Feb 2013 09:02:58 -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; 22 Feb 2013 09:02:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 09:02:58 +0000
Message-Id: <5127428C02000078000C040A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 09:03:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: aliguori@us.ibm.com, mst@redhat.com, stefano.stabellini@eu.citrix.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
 base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    if (xen_enabled()) {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> +    } else {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> +    }
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }

Isn't this the wrong way round (big endian, when it needs to be
little)?

Or else, this read and calculation

>+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 4);
>+    pci_hole_size = 0x100000000ULL - pci_hole_start;

would seem wrong (e.g. if the granularity is meant to be 16M).

And then again, wasting 4 bytes of config space on something that
one ought to be allowed to expect to be at least 64k-aligned seems
questionable too. hvmloader surely could align the value up to the
next 64k boundary before writing the - then only word size - field.
That would come closer to how real chipsets normally implement
things like this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:03:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oWy-00017i-Qo; Fri, 22 Feb 2013 09:03: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 1U8oWx-00016b-QZ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:00 +0000
Received: from [85.158.137.99:6912] by server-7.bemta-3.messagelabs.com id
	66/E2-10367-E3437215; Fri, 22 Feb 2013 09:02:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27854 invoked from network); 22 Feb 2013 09:02:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518813"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-8G;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:25 +0000
Message-ID: <1361523505-7604-46-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 46/46] xen: arm: implement cpuinfo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 to:

 - Only context switch ThumbEE state if the processor implements it. In
   particular the ARMv8 FastModels do not.
 - Detect the generic timer, and therefore call identify_cpu before
   init_xen_time.

Also improve the boot time messages a bit.

I haven't added decoding for all of the CPUID words, it seems like overkill
for the moment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: stefano.stabellini@citrix.com
---
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/cpu.c               |   69 +++++++++++++++++++++
 xen/arch/arm/domain.c            |   39 +++++++++---
 xen/arch/arm/setup.c             |  109 +++++++++++++++++++++++++--------
 xen/arch/arm/smpboot.c           |    7 ++
 xen/arch/arm/time.c              |    5 +-
 xen/include/asm-arm/cpregs.h     |   11 ++--
 xen/include/asm-arm/cpufeature.h |   40 ++++++++++++
 xen/include/asm-arm/domain.h     |   10 +++-
 xen/include/asm-arm/processor.h  |  125 ++++++++++++++++++++++++++++++++++++-
 10 files changed, 368 insertions(+), 48 deletions(-)
 create mode 100644 xen/arch/arm/cpu.c
 create mode 100644 xen/include/asm-arm/cpufeature.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 677e232..2106a4f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-$(arm64) += arm64
 subdir-y += platforms
 
 obj-y += early_printk.o
+obj-y += cpu.o
 obj-y += domain.o
 obj-y += domctl.o
 obj-y += sysctl.o
diff --git a/xen/arch/arm/cpu.c b/xen/arch/arm/cpu.c
new file mode 100644
index 0000000..7a8ad33
--- /dev/null
+++ b/xen/arch/arm/cpu.c
@@ -0,0 +1,69 @@
+/*
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+
+#include <asm/processor.h>
+
+void __cpuinit identify_cpu(struct cpuinfo_arm *c)
+{
+        c->midr.bits = READ_SYSREG32(MIDR_EL1);
+        c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
+
+#ifdef CONFIG_ARM_64
+        c->pfr64.bits[0] = READ_SYSREG64(ID_AA64PFR0_EL1);
+        c->pfr64.bits[1] = READ_SYSREG64(ID_AA64PFR1_EL1);
+
+        c->dbg64.bits[0] = READ_SYSREG64(ID_AA64DFR0_EL1);
+        c->dbg64.bits[1] = READ_SYSREG64(ID_AA64DFR1_EL1);
+
+        c->aux64.bits[0] = READ_SYSREG64(ID_AA64AFR0_EL1);
+        c->aux64.bits[1] = READ_SYSREG64(ID_AA64AFR1_EL1);
+
+        c->mm64.bits[0]  = READ_SYSREG64(ID_AA64MMFR0_EL1);
+        c->mm64.bits[1]  = READ_SYSREG64(ID_AA64MMFR1_EL1);
+
+        c->isa64.bits[0] = READ_SYSREG64(ID_AA64ISAR0_EL1);
+        c->isa64.bits[1] = READ_SYSREG64(ID_AA64ISAR1_EL1);
+#endif
+
+        c->pfr32.bits[0] = READ_SYSREG32(ID_PFR0_EL1);
+        c->pfr32.bits[1] = READ_SYSREG32(ID_PFR1_EL1);
+
+        c->dbg32.bits[0] = READ_SYSREG32(ID_DFR0_EL1);
+
+        c->aux32.bits[0] = READ_SYSREG32(ID_AFR0_EL1);
+
+        c->mm32.bits[0]  = READ_SYSREG32(ID_MMFR0_EL1);
+        c->mm32.bits[1]  = READ_SYSREG32(ID_MMFR1_EL1);
+        c->mm32.bits[2]  = READ_SYSREG32(ID_MMFR2_EL1);
+        c->mm32.bits[3]  = READ_SYSREG32(ID_MMFR3_EL1);
+
+        c->isa32.bits[0] = READ_SYSREG32(ID_ISAR0_EL1);
+        c->isa32.bits[1] = READ_SYSREG32(ID_ISAR1_EL1);
+        c->isa32.bits[2] = READ_SYSREG32(ID_ISAR2_EL1);
+        c->isa32.bits[3] = READ_SYSREG32(ID_ISAR3_EL1);
+        c->isa32.bits[4] = READ_SYSREG32(ID_ISAR4_EL1);
+        c->isa32.bits[5] = READ_SYSREG32(ID_ISAR5_EL1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index dce7ea1..bca3d89 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1,3 +1,14 @@
+/*
+ * 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 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.
+ */
 #include <xen/config.h>
 #include <xen/init.h>
 #include <xen/lib.h>
@@ -13,6 +24,7 @@
 #include <asm/regs.h>
 #include <asm/p2m.h>
 #include <asm/irq.h>
+#include <asm/cpufeature.h>
 
 #include <asm/gic.h>
 #include "vtimer.h"
@@ -58,11 +70,13 @@ static void ctxt_switch_from(struct vcpu *p)
     /* Arch timer */
     virt_timer_save(p);
 
-#if defined(CONFIG_ARM_32)
-    /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    p->arch.teecr = READ_CP32(TEECR);
-    p->arch.teehbr = READ_CP32(TEEHBR);
+    if ( is_pv32_domain(p->domain) && cpu_has_thumbee )
+    {
+        p->arch.teecr = READ_SYSREG32(TEECR32_EL1);
+        p->arch.teehbr = READ_SYSREG32(TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
 #endif
@@ -121,6 +135,9 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
     isb();
 
+    WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
+    WRITE_SYSREG(n->domain->arch.vmpidr, VMPIDR_EL2);
+
     /* VGIC */
     gic_restore_state(n);
 
@@ -169,11 +186,13 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
     WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
-#if defined(CONFIG_ARM_32)
-    /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    WRITE_CP32(n->arch.teecr, TEECR);
-    WRITE_CP32(n->arch.teehbr, TEEHBR);
+    if ( is_pv32_domain(n->domain) && cpu_has_thumbee )
+    {
+        WRITE_SYSREG32(n->arch.teecr, TEECR32_EL1);
+        WRITE_SYSREG32(n->arch.teehbr, TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
 #endif
@@ -447,6 +466,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
         goto fail;
 
+    /* Default the virtual ID to match the physical */
+    d->arch.vpidr = boot_cpu_data.midr.bits;
+    d->arch.vmpidr = boot_cpu_data.mpidr.bits;
+
     clear_page(d->shared_info);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 8326034..566f36c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,9 @@
 #include <asm/vfp.h>
 #include <asm/early_printk.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
+
+struct cpuinfo_arm __read_mostly boot_cpu_data;
 
 static __used void init_done(void)
 {
@@ -54,41 +57,93 @@ static void __init init_idle_domain(void)
     /* TODO: setup_idle_pagetable(); */
 }
 
+static const char * __initdata processor_implementers[] = {
+    ['A'] = "ARM Limited",
+    ['D'] = "Digital Equipment Corp",
+    ['M'] = "Motorola, Freescale Semiconductor Inc.",
+    ['Q'] = "Qualcomm Inc.",
+    ['V'] = "Marvell Semiconductor Inc.",
+    ['i'] = "Intel Corporation",
+};
+
 static void __init processor_id(void)
 {
+    const char *implementer = "Unknown";
+    struct cpuinfo_arm *c = &boot_cpu_data;
+
+    identify_cpu(c);
+    current_cpu_data = *c;
+
+    if ( c->midr.implementer < ARRAY_SIZE(processor_implementers) &&
+         processor_implementers[c->midr.implementer] )
+        implementer = processor_implementers[c->midr.implementer];
 
-    /* Setup the virtual ID to match the physical */
-    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
-    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+    if ( c->midr.architecture != 0xf )
+        printk("Huh, cpu architecture %x, expected 0xf (defined by cpuid)\n",
+               c->midr.architecture);
+
+    printk("Processor: \"%s\", variant: 0x%x, part 0x%03x, rev 0x%x\n",
+           implementer, c->midr.variant, c->midr.part_number, c->midr.revision);
 
 #if defined(CONFIG_ARM_64)
-    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
-    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
-    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
-    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
-    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+    printk("64-bit Execution:\n");
+    printk("  Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.pfr64.bits[0], boot_cpu_data.pfr64.bits[1]);
+    printk("    Exception Levels: EL3:%s EL2:%s EL1:%s EL0:%s\n",
+           cpu_has_el3_32 ? "64+32" : cpu_has_el3_64 ? "64" : "No",
+           cpu_has_el2_32 ? "64+32" : cpu_has_el2_64 ? "64" : "No",
+           cpu_has_el1_32 ? "64+32" : cpu_has_el1_64 ? "64" : "No",
+           cpu_has_el0_32 ? "64+32" : cpu_has_el0_64 ? "64" : "No");
+    printk("    Extensions:%s%s\n",
+           cpu_has_fp ? " FloatingPoint" : "",
+           cpu_has_simd ? " AdvancedSIMD" : "");
+
+    printk("  Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
+    printk("  Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.aux64.bits[0], boot_cpu_data.aux64.bits[1]);
+    printk("  Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.mm64.bits[0], boot_cpu_data.mm64.bits[1]);
+    printk("  ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.isa64.bits[0], boot_cpu_data.isa64.bits[1]);
 #endif
+
     /*
      * On AArch64 these refer to the capabilities when running in
      * AArch32 mode.
      */
-    printk("32-bit Processor Features: %08x %08x\n",
-           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
-    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
-    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
-    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
-           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
-    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
-           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
-           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
-
+    if ( cpu_has_aarch32 )
+    {
+        printk("32-bit Execution:\n");
+        printk("  Processor Features: %08"PRIx32":%08"PRIx32"\n",
+               boot_cpu_data.pfr32.bits[0], boot_cpu_data.pfr32.bits[1]);
+        printk("    Instruction Sets:%s%s%s%s%s\n",
+               cpu_has_aarch32 ? " AArch32" : "",
+               cpu_has_thumb ? " Thumb" : "",
+               cpu_has_thumb2 ? " Thumb-2" : "",
+               cpu_has_thumbee ? " ThumbEE" : "",
+               cpu_has_jazelle ? " Jazelle" : "");
+        printk("    Extensions:%s%s\n",
+               cpu_has_gentimer ? " GenericTimer" : "",
+               cpu_has_security ? " Security" : "");
+
+        printk("  Debug Features: %08"PRIx32"\n",
+               boot_cpu_data.dbg32.bits[0]);
+        printk("  Auxiliary Features: %08"PRIx32"\n",
+               boot_cpu_data.aux32.bits[0]);
+        printk("  Memory Model Features: "
+               "%08"PRIx32" %08"PRIx32" %08"PRIx32" %08"PRIx32"\n",
+               boot_cpu_data.mm32.bits[0], boot_cpu_data.mm32.bits[1],
+               boot_cpu_data.mm32.bits[2], boot_cpu_data.mm32.bits[3]);
+        printk(" ISA Features: %08x %08x %08x %08x %08x %08x\n",
+               boot_cpu_data.isa32.bits[0], boot_cpu_data.isa32.bits[1],
+               boot_cpu_data.isa32.bits[2], boot_cpu_data.isa32.bits[3],
+               boot_cpu_data.isa32.bits[4], boot_cpu_data.isa32.bits[5]);
+    }
+    else
+    {
+        printk("32-bit Execution: Unsupported\n");
+    }
 }
 
 void __init discard_initial_modules(void)
@@ -379,6 +434,8 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
+    processor_id();
+
     init_xen_time();
 
     gic_init();
@@ -400,8 +457,6 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
-    processor_id();
-
     enable_vfp();
 
     softirq_init();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 75ee8a9..b2af42e 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -38,6 +38,8 @@ EXPORT_SYMBOL(cpu_online_map);
 cpumask_t cpu_possible_map;
 EXPORT_SYMBOL(cpu_possible_map);
 
+struct cpuinfo_arm cpu_data[NR_CPUS];
+
 /* Fake one node for now. See also include/asm-arm/numa.h */
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
@@ -136,11 +138,16 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
                                unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
+    struct cpuinfo_arm *c = cpu_data + cpuid;
+
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));
 
     /* TODO: handle boards where CPUIDs are not contiguous */
     set_processor_id(cpuid);
 
+    *c = boot_cpu_data;
+    identify_cpu(c);
+
     /* Setup Hyp vector base */
     WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c53d79e..82f69d2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -31,6 +31,7 @@
 #include <asm/system.h>
 #include <asm/time.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
 
 /*
  * Unfortunately the hypervisor timer interrupt appears to be buggy in
@@ -90,10 +91,8 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
-#if defined(CONFIG_ARM_32)
-    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+    if ( !cpu_has_gentimer )
         panic("CPU does not support the Generic Timer v1 interface.\n");
-#endif
 
     cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
     boot_count = READ_SYSREG64(CNTPCT_EL0);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 17ac1e9..f08d59a 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -265,10 +265,14 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define IFSR32_EL2              IFSR
+#define MIDR_EL1                MIDR
+#define MPIDR_EL1               MPIDR
 #define PAR_EL1                 PAR
 #define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
 #define TCR_EL1                 TTBCR
+#define TEECR32_EL1             TEECR
+#define TEEHBR32_EL1            TEEHBR
 #define TPIDRRO_EL0             TPIDRURO
 #define TPIDR_EL0               TPIDRURW
 #define TPIDR_EL1               TPIDRPRW
@@ -278,13 +282,10 @@
 #define TTBR1_EL1               TTBR1
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
+#define VMPIDR_EL2              VMPIDR
+#define VPIDR_EL2               VPIDR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
-#define MIDR_EL1                MIDR
-#define VPIDR_EL2               VPIDR
-#define MPIDR_EL1               MPIDR
-#define VMPIDR_EL2              VMPIDR
-
 #endif
 
 #endif
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
new file mode 100644
index 0000000..e633239
--- /dev/null
+++ b/xen/include/asm-arm/cpufeature.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_ARM_CPUFEATURE_H
+#define __ASM_ARM_CPUFEATURE_H
+
+#ifdef CONFIG_ARM_64
+#define cpu_feature64(c, feat)         ((c)->pfr64.feat)
+#define boot_cpu_feature64(feat)       (boot_cpu_data.pfr64.feat)
+
+#define cpu_has_el0_32    (boot_cpu_feature64(el0) == 2)
+#define cpu_has_el0_64    (boot_cpu_feature64(el0) >= 1)
+#define cpu_has_el1_32    (boot_cpu_feature64(el1) == 2)
+#define cpu_has_el1_64    (boot_cpu_feature64(el1) >= 1)
+#define cpu_has_el2_32    (boot_cpu_feature64(el2) == 2)
+#define cpu_has_el2_64    (boot_cpu_feature64(el2) >= 1)
+#define cpu_has_el3_32    (boot_cpu_feature64(el3) == 2)
+#define cpu_has_el3_64    (boot_cpu_feature64(el3) >= 1)
+#define cpu_has_fp        (boot_cpu_feature64(fp) == 0)
+#define cpu_has_simd      (boot_cpu_feature64(simd) == 0)
+#endif
+
+#define cpu_feature32(c, feat)         ((c)->pfr32.feat)
+#define boot_cpu_feature32(feat)       (boot_cpu_data.pfr32.feat)
+
+#define cpu_has_aarch32   (boot_cpu_feature32(arm) == 1)
+#define cpu_has_thumb     (boot_cpu_feature32(thumb) >= 1)
+#define cpu_has_thumb2    (boot_cpu_feature32(thumb) >= 3)
+#define cpu_has_jazelle   (boot_cpu_feature32(jazelle) >= 0)
+#define cpu_has_thumbee   (boot_cpu_feature32(thumbee) == 1)
+
+#define cpu_has_gentimer  (boot_cpu_feature32(gentimer) == 1)
+#define cpu_has_security  (boot_cpu_feature32(security) > 0)
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 04518b3..bf9caff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,10 @@ struct arch_domain
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
 
+    /* Virtual CPUID */
+    uint32_t vpidr;
+    register_t vmpidr;
+
     struct {
         /*
          * Covers access to other members of this struct _except_ for
@@ -166,8 +170,12 @@ struct arch_vcpu
     register_t tpidr_el1;
     register_t tpidrro_el0;
 
+    uint32_t teecr, teehbr; /* ThumbEE, 32-bit guests only */
 #ifdef CONFIG_ARM_32
-    uint32_t teecr, teehbr;
+    /*
+     * ARMv8 only supports a trivial implementation on Jazelle when in AArch32
+     * mode and therefore has no extended control registers.
+     */
     uint32_t joscr, jmcr;
 #endif
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index c1d7d70..6fbe2fa 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -91,6 +91,123 @@
 #define HSR_EC_DATA_ABORT_HYP       0x25
 
 #ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+
+struct cpuinfo_arm {
+    union {
+        uint32_t bits;
+        struct {
+            unsigned long revision:4;
+            unsigned long part_number:12;
+            unsigned long architecture:4;
+            unsigned long variant:4;
+            unsigned long implementer:8;
+        };
+    } midr;
+    union {
+        register_t bits;
+        struct {
+            unsigned long aff0:8;
+            unsigned long aff1:8;
+            unsigned long aff2:8;
+            unsigned long mt:1; /* Multi-thread, iff MP == 1 */
+            unsigned long __res0:5;
+            unsigned long up:1; /* UP system, iff MP == 1 */
+            unsigned long mp:1; /* MP extensions */
+
+#ifdef CONFIG_ARM_64
+            unsigned long aff3:8;
+            unsigned long __res1:24;
+#endif
+        };
+    } mpidr;
+
+#ifdef CONFIG_ARM_64
+    /* 64-bit CPUID registers. */
+    union {
+        uint64_t bits[2];
+        struct {
+            unsigned long el0:4;
+            unsigned long el1:4;
+            unsigned long el2:4;
+            unsigned long el3:4;
+            unsigned long fp:4;   /* Floating Point */
+            unsigned long simd:4; /* Advanced SIMD */
+            unsigned long __res0:8;
+
+            unsigned long __res1;
+        };
+    } pfr64;
+
+    struct {
+        uint64_t bits[2];
+    } dbg64;
+
+    struct {
+        uint64_t bits[2];
+    } aux64;
+
+    struct {
+        uint64_t bits[2];
+    } mm64;
+
+    struct {
+        uint64_t bits[2];
+    } isa64;
+
+#endif
+
+    /*
+     * 32-bit CPUID registers. On ARMv8 these describe the properties
+     * when running in 32-bit mode.
+     */
+    union {
+        uint32_t bits[2];
+        struct {
+            unsigned long arm:4;
+            unsigned long thumb:4;
+            unsigned long jazelle:4;
+            unsigned long thumbee:4;
+            unsigned long __res0:16;
+
+            unsigned long progmodel:4;
+            unsigned long security:4;
+            unsigned long mprofile:4;
+            unsigned long virt:4;
+            unsigned long gentimer:4;
+            unsigned long __res1:12;
+        };
+    } pfr32;
+
+    struct {
+        uint32_t bits[1];
+    } dbg32;
+
+    struct {
+        uint32_t bits[1];
+    } aux32;
+
+    struct {
+        uint32_t bits[4];
+    } mm32;
+
+    struct {
+        uint32_t bits[6];
+    } isa32;
+};
+
+/*
+ * capabilities of CPUs
+ */
+
+extern struct cpuinfo_arm boot_cpu_data;
+
+extern void identify_cpu(struct cpuinfo_arm *);
+
+extern struct cpuinfo_arm cpu_data[];
+#define current_cpu_data cpu_data[smp_processor_id()]
+
 union hsr {
     uint32_t bits;
     struct {
@@ -225,10 +342,6 @@ union hsr {
 #define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
 #define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
 
-/* CPUID bits */
-#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
-#define ID_PFR1_GT_v1    0x00010000
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/processor.h>
 #elif defined(CONFIG_ARM_64)
@@ -260,6 +373,10 @@ void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
                            const struct vcpu_guest_core_regs *regs);
 
+struct cpuinfo_x86 {
+    uint32_t pfr32[2];
+};
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_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 Fri Feb 22 09:03:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oWy-00017i-Qo; Fri, 22 Feb 2013 09:03: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 1U8oWx-00016b-QZ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:00 +0000
Received: from [85.158.137.99:6912] by server-7.bemta-3.messagelabs.com id
	66/E2-10367-E3437215; Fri, 22 Feb 2013 09:02:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27854 invoked from network); 22 Feb 2013 09:02:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518813"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:51 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-8G;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:25 +0000
Message-ID: <1361523505-7604-46-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 46/46] xen: arm: implement cpuinfo
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 to:

 - Only context switch ThumbEE state if the processor implements it. In
   particular the ARMv8 FastModels do not.
 - Detect the generic timer, and therefore call identify_cpu before
   init_xen_time.

Also improve the boot time messages a bit.

I haven't added decoding for all of the CPUID words, it seems like overkill
for the moment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Cc: stefano.stabellini@citrix.com
---
 xen/arch/arm/Makefile            |    1 +
 xen/arch/arm/cpu.c               |   69 +++++++++++++++++++++
 xen/arch/arm/domain.c            |   39 +++++++++---
 xen/arch/arm/setup.c             |  109 +++++++++++++++++++++++++--------
 xen/arch/arm/smpboot.c           |    7 ++
 xen/arch/arm/time.c              |    5 +-
 xen/include/asm-arm/cpregs.h     |   11 ++--
 xen/include/asm-arm/cpufeature.h |   40 ++++++++++++
 xen/include/asm-arm/domain.h     |   10 +++-
 xen/include/asm-arm/processor.h  |  125 ++++++++++++++++++++++++++++++++++++-
 10 files changed, 368 insertions(+), 48 deletions(-)
 create mode 100644 xen/arch/arm/cpu.c
 create mode 100644 xen/include/asm-arm/cpufeature.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 677e232..2106a4f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-$(arm64) += arm64
 subdir-y += platforms
 
 obj-y += early_printk.o
+obj-y += cpu.o
 obj-y += domain.o
 obj-y += domctl.o
 obj-y += sysctl.o
diff --git a/xen/arch/arm/cpu.c b/xen/arch/arm/cpu.c
new file mode 100644
index 0000000..7a8ad33
--- /dev/null
+++ b/xen/arch/arm/cpu.c
@@ -0,0 +1,69 @@
+/*
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/sched.h>
+
+#include <asm/processor.h>
+
+void __cpuinit identify_cpu(struct cpuinfo_arm *c)
+{
+        c->midr.bits = READ_SYSREG32(MIDR_EL1);
+        c->mpidr.bits = READ_SYSREG(MPIDR_EL1);
+
+#ifdef CONFIG_ARM_64
+        c->pfr64.bits[0] = READ_SYSREG64(ID_AA64PFR0_EL1);
+        c->pfr64.bits[1] = READ_SYSREG64(ID_AA64PFR1_EL1);
+
+        c->dbg64.bits[0] = READ_SYSREG64(ID_AA64DFR0_EL1);
+        c->dbg64.bits[1] = READ_SYSREG64(ID_AA64DFR1_EL1);
+
+        c->aux64.bits[0] = READ_SYSREG64(ID_AA64AFR0_EL1);
+        c->aux64.bits[1] = READ_SYSREG64(ID_AA64AFR1_EL1);
+
+        c->mm64.bits[0]  = READ_SYSREG64(ID_AA64MMFR0_EL1);
+        c->mm64.bits[1]  = READ_SYSREG64(ID_AA64MMFR1_EL1);
+
+        c->isa64.bits[0] = READ_SYSREG64(ID_AA64ISAR0_EL1);
+        c->isa64.bits[1] = READ_SYSREG64(ID_AA64ISAR1_EL1);
+#endif
+
+        c->pfr32.bits[0] = READ_SYSREG32(ID_PFR0_EL1);
+        c->pfr32.bits[1] = READ_SYSREG32(ID_PFR1_EL1);
+
+        c->dbg32.bits[0] = READ_SYSREG32(ID_DFR0_EL1);
+
+        c->aux32.bits[0] = READ_SYSREG32(ID_AFR0_EL1);
+
+        c->mm32.bits[0]  = READ_SYSREG32(ID_MMFR0_EL1);
+        c->mm32.bits[1]  = READ_SYSREG32(ID_MMFR1_EL1);
+        c->mm32.bits[2]  = READ_SYSREG32(ID_MMFR2_EL1);
+        c->mm32.bits[3]  = READ_SYSREG32(ID_MMFR3_EL1);
+
+        c->isa32.bits[0] = READ_SYSREG32(ID_ISAR0_EL1);
+        c->isa32.bits[1] = READ_SYSREG32(ID_ISAR1_EL1);
+        c->isa32.bits[2] = READ_SYSREG32(ID_ISAR2_EL1);
+        c->isa32.bits[3] = READ_SYSREG32(ID_ISAR3_EL1);
+        c->isa32.bits[4] = READ_SYSREG32(ID_ISAR4_EL1);
+        c->isa32.bits[5] = READ_SYSREG32(ID_ISAR5_EL1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index dce7ea1..bca3d89 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1,3 +1,14 @@
+/*
+ * 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 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.
+ */
 #include <xen/config.h>
 #include <xen/init.h>
 #include <xen/lib.h>
@@ -13,6 +24,7 @@
 #include <asm/regs.h>
 #include <asm/p2m.h>
 #include <asm/irq.h>
+#include <asm/cpufeature.h>
 
 #include <asm/gic.h>
 #include "vtimer.h"
@@ -58,11 +70,13 @@ static void ctxt_switch_from(struct vcpu *p)
     /* Arch timer */
     virt_timer_save(p);
 
-#if defined(CONFIG_ARM_32)
-    /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    p->arch.teecr = READ_CP32(TEECR);
-    p->arch.teehbr = READ_CP32(TEEHBR);
+    if ( is_pv32_domain(p->domain) && cpu_has_thumbee )
+    {
+        p->arch.teecr = READ_SYSREG32(TEECR32_EL1);
+        p->arch.teehbr = READ_SYSREG32(TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
 #endif
@@ -121,6 +135,9 @@ static void ctxt_switch_to(struct vcpu *n)
     p2m_load_VTTBR(n->domain);
     isb();
 
+    WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
+    WRITE_SYSREG(n->domain->arch.vmpidr, VMPIDR_EL2);
+
     /* VGIC */
     gic_restore_state(n);
 
@@ -169,11 +186,13 @@ static void ctxt_switch_to(struct vcpu *n)
     WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
     WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
-#if defined(CONFIG_ARM_32)
-    /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
-    WRITE_CP32(n->arch.teecr, TEECR);
-    WRITE_CP32(n->arch.teehbr, TEEHBR);
+    if ( is_pv32_domain(n->domain) && cpu_has_thumbee )
+    {
+        WRITE_SYSREG32(n->arch.teecr, TEECR32_EL1);
+        WRITE_SYSREG32(n->arch.teehbr, TEEHBR32_EL1);
+    }
 
+#ifdef CONFIG_ARM_32
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
 #endif
@@ -447,6 +466,10 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
     if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
         goto fail;
 
+    /* Default the virtual ID to match the physical */
+    d->arch.vpidr = boot_cpu_data.midr.bits;
+    d->arch.vmpidr = boot_cpu_data.mpidr.bits;
+
     clear_page(d->shared_info);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 8326034..566f36c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,9 @@
 #include <asm/vfp.h>
 #include <asm/early_printk.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
+
+struct cpuinfo_arm __read_mostly boot_cpu_data;
 
 static __used void init_done(void)
 {
@@ -54,41 +57,93 @@ static void __init init_idle_domain(void)
     /* TODO: setup_idle_pagetable(); */
 }
 
+static const char * __initdata processor_implementers[] = {
+    ['A'] = "ARM Limited",
+    ['D'] = "Digital Equipment Corp",
+    ['M'] = "Motorola, Freescale Semiconductor Inc.",
+    ['Q'] = "Qualcomm Inc.",
+    ['V'] = "Marvell Semiconductor Inc.",
+    ['i'] = "Intel Corporation",
+};
+
 static void __init processor_id(void)
 {
+    const char *implementer = "Unknown";
+    struct cpuinfo_arm *c = &boot_cpu_data;
+
+    identify_cpu(c);
+    current_cpu_data = *c;
+
+    if ( c->midr.implementer < ARRAY_SIZE(processor_implementers) &&
+         processor_implementers[c->midr.implementer] )
+        implementer = processor_implementers[c->midr.implementer];
 
-    /* Setup the virtual ID to match the physical */
-    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
-    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+    if ( c->midr.architecture != 0xf )
+        printk("Huh, cpu architecture %x, expected 0xf (defined by cpuid)\n",
+               c->midr.architecture);
+
+    printk("Processor: \"%s\", variant: 0x%x, part 0x%03x, rev 0x%x\n",
+           implementer, c->midr.variant, c->midr.part_number, c->midr.revision);
 
 #if defined(CONFIG_ARM_64)
-    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
-    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
-    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
-    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
-    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
-           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+    printk("64-bit Execution:\n");
+    printk("  Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.pfr64.bits[0], boot_cpu_data.pfr64.bits[1]);
+    printk("    Exception Levels: EL3:%s EL2:%s EL1:%s EL0:%s\n",
+           cpu_has_el3_32 ? "64+32" : cpu_has_el3_64 ? "64" : "No",
+           cpu_has_el2_32 ? "64+32" : cpu_has_el2_64 ? "64" : "No",
+           cpu_has_el1_32 ? "64+32" : cpu_has_el1_64 ? "64" : "No",
+           cpu_has_el0_32 ? "64+32" : cpu_has_el0_64 ? "64" : "No");
+    printk("    Extensions:%s%s\n",
+           cpu_has_fp ? " FloatingPoint" : "",
+           cpu_has_simd ? " AdvancedSIMD" : "");
+
+    printk("  Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
+    printk("  Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.aux64.bits[0], boot_cpu_data.aux64.bits[1]);
+    printk("  Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.mm64.bits[0], boot_cpu_data.mm64.bits[1]);
+    printk("  ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           boot_cpu_data.isa64.bits[0], boot_cpu_data.isa64.bits[1]);
 #endif
+
     /*
      * On AArch64 these refer to the capabilities when running in
      * AArch32 mode.
      */
-    printk("32-bit Processor Features: %08x %08x\n",
-           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
-    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
-    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
-    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
-           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
-    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
-           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
-           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
-
+    if ( cpu_has_aarch32 )
+    {
+        printk("32-bit Execution:\n");
+        printk("  Processor Features: %08"PRIx32":%08"PRIx32"\n",
+               boot_cpu_data.pfr32.bits[0], boot_cpu_data.pfr32.bits[1]);
+        printk("    Instruction Sets:%s%s%s%s%s\n",
+               cpu_has_aarch32 ? " AArch32" : "",
+               cpu_has_thumb ? " Thumb" : "",
+               cpu_has_thumb2 ? " Thumb-2" : "",
+               cpu_has_thumbee ? " ThumbEE" : "",
+               cpu_has_jazelle ? " Jazelle" : "");
+        printk("    Extensions:%s%s\n",
+               cpu_has_gentimer ? " GenericTimer" : "",
+               cpu_has_security ? " Security" : "");
+
+        printk("  Debug Features: %08"PRIx32"\n",
+               boot_cpu_data.dbg32.bits[0]);
+        printk("  Auxiliary Features: %08"PRIx32"\n",
+               boot_cpu_data.aux32.bits[0]);
+        printk("  Memory Model Features: "
+               "%08"PRIx32" %08"PRIx32" %08"PRIx32" %08"PRIx32"\n",
+               boot_cpu_data.mm32.bits[0], boot_cpu_data.mm32.bits[1],
+               boot_cpu_data.mm32.bits[2], boot_cpu_data.mm32.bits[3]);
+        printk(" ISA Features: %08x %08x %08x %08x %08x %08x\n",
+               boot_cpu_data.isa32.bits[0], boot_cpu_data.isa32.bits[1],
+               boot_cpu_data.isa32.bits[2], boot_cpu_data.isa32.bits[3],
+               boot_cpu_data.isa32.bits[4], boot_cpu_data.isa32.bits[5]);
+    }
+    else
+    {
+        printk("32-bit Execution: Unsupported\n");
+    }
 }
 
 void __init discard_initial_modules(void)
@@ -379,6 +434,8 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
+    processor_id();
+
     init_xen_time();
 
     gic_init();
@@ -400,8 +457,6 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
-    processor_id();
-
     enable_vfp();
 
     softirq_init();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 75ee8a9..b2af42e 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -38,6 +38,8 @@ EXPORT_SYMBOL(cpu_online_map);
 cpumask_t cpu_possible_map;
 EXPORT_SYMBOL(cpu_possible_map);
 
+struct cpuinfo_arm cpu_data[NR_CPUS];
+
 /* Fake one node for now. See also include/asm-arm/numa.h */
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
@@ -136,11 +138,16 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
                                unsigned long fdt_paddr,
                                unsigned long cpuid)
 {
+    struct cpuinfo_arm *c = cpu_data + cpuid;
+
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));
 
     /* TODO: handle boards where CPUIDs are not contiguous */
     set_processor_id(cpuid);
 
+    *c = boot_cpu_data;
+    identify_cpu(c);
+
     /* Setup Hyp vector base */
     WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c53d79e..82f69d2 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -31,6 +31,7 @@
 #include <asm/system.h>
 #include <asm/time.h>
 #include <asm/gic.h>
+#include <asm/cpufeature.h>
 
 /*
  * Unfortunately the hypervisor timer interrupt appears to be buggy in
@@ -90,10 +91,8 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
-#if defined(CONFIG_ARM_32)
-    if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
+    if ( !cpu_has_gentimer )
         panic("CPU does not support the Generic Timer v1 interface.\n");
-#endif
 
     cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
     boot_count = READ_SYSREG64(CNTPCT_EL0);
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 17ac1e9..f08d59a 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -265,10 +265,14 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define IFSR32_EL2              IFSR
+#define MIDR_EL1                MIDR
+#define MPIDR_EL1               MPIDR
 #define PAR_EL1                 PAR
 #define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
 #define TCR_EL1                 TTBCR
+#define TEECR32_EL1             TEECR
+#define TEEHBR32_EL1            TEEHBR
 #define TPIDRRO_EL0             TPIDRURO
 #define TPIDR_EL0               TPIDRURW
 #define TPIDR_EL1               TPIDRPRW
@@ -278,13 +282,10 @@
 #define TTBR1_EL1               TTBR1
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
+#define VMPIDR_EL2              VMPIDR
+#define VPIDR_EL2               VPIDR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
-#define MIDR_EL1                MIDR
-#define VPIDR_EL2               VPIDR
-#define MPIDR_EL1               MPIDR
-#define VMPIDR_EL2              VMPIDR
-
 #endif
 
 #endif
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
new file mode 100644
index 0000000..e633239
--- /dev/null
+++ b/xen/include/asm-arm/cpufeature.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_ARM_CPUFEATURE_H
+#define __ASM_ARM_CPUFEATURE_H
+
+#ifdef CONFIG_ARM_64
+#define cpu_feature64(c, feat)         ((c)->pfr64.feat)
+#define boot_cpu_feature64(feat)       (boot_cpu_data.pfr64.feat)
+
+#define cpu_has_el0_32    (boot_cpu_feature64(el0) == 2)
+#define cpu_has_el0_64    (boot_cpu_feature64(el0) >= 1)
+#define cpu_has_el1_32    (boot_cpu_feature64(el1) == 2)
+#define cpu_has_el1_64    (boot_cpu_feature64(el1) >= 1)
+#define cpu_has_el2_32    (boot_cpu_feature64(el2) == 2)
+#define cpu_has_el2_64    (boot_cpu_feature64(el2) >= 1)
+#define cpu_has_el3_32    (boot_cpu_feature64(el3) == 2)
+#define cpu_has_el3_64    (boot_cpu_feature64(el3) >= 1)
+#define cpu_has_fp        (boot_cpu_feature64(fp) == 0)
+#define cpu_has_simd      (boot_cpu_feature64(simd) == 0)
+#endif
+
+#define cpu_feature32(c, feat)         ((c)->pfr32.feat)
+#define boot_cpu_feature32(feat)       (boot_cpu_data.pfr32.feat)
+
+#define cpu_has_aarch32   (boot_cpu_feature32(arm) == 1)
+#define cpu_has_thumb     (boot_cpu_feature32(thumb) >= 1)
+#define cpu_has_thumb2    (boot_cpu_feature32(thumb) >= 3)
+#define cpu_has_jazelle   (boot_cpu_feature32(jazelle) >= 0)
+#define cpu_has_thumbee   (boot_cpu_feature32(thumbee) == 1)
+
+#define cpu_has_gentimer  (boot_cpu_feature32(gentimer) == 1)
+#define cpu_has_security  (boot_cpu_feature32(security) > 0)
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 04518b3..bf9caff 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -57,6 +57,10 @@ struct arch_domain
     struct hvm_domain hvm_domain;
     xen_pfn_t *grant_table_gpfn;
 
+    /* Virtual CPUID */
+    uint32_t vpidr;
+    register_t vmpidr;
+
     struct {
         /*
          * Covers access to other members of this struct _except_ for
@@ -166,8 +170,12 @@ struct arch_vcpu
     register_t tpidr_el1;
     register_t tpidrro_el0;
 
+    uint32_t teecr, teehbr; /* ThumbEE, 32-bit guests only */
 #ifdef CONFIG_ARM_32
-    uint32_t teecr, teehbr;
+    /*
+     * ARMv8 only supports a trivial implementation on Jazelle when in AArch32
+     * mode and therefore has no extended control registers.
+     */
     uint32_t joscr, jmcr;
 #endif
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index c1d7d70..6fbe2fa 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -91,6 +91,123 @@
 #define HSR_EC_DATA_ABORT_HYP       0x25
 
 #ifndef __ASSEMBLY__
+
+#include <xen/types.h>
+
+struct cpuinfo_arm {
+    union {
+        uint32_t bits;
+        struct {
+            unsigned long revision:4;
+            unsigned long part_number:12;
+            unsigned long architecture:4;
+            unsigned long variant:4;
+            unsigned long implementer:8;
+        };
+    } midr;
+    union {
+        register_t bits;
+        struct {
+            unsigned long aff0:8;
+            unsigned long aff1:8;
+            unsigned long aff2:8;
+            unsigned long mt:1; /* Multi-thread, iff MP == 1 */
+            unsigned long __res0:5;
+            unsigned long up:1; /* UP system, iff MP == 1 */
+            unsigned long mp:1; /* MP extensions */
+
+#ifdef CONFIG_ARM_64
+            unsigned long aff3:8;
+            unsigned long __res1:24;
+#endif
+        };
+    } mpidr;
+
+#ifdef CONFIG_ARM_64
+    /* 64-bit CPUID registers. */
+    union {
+        uint64_t bits[2];
+        struct {
+            unsigned long el0:4;
+            unsigned long el1:4;
+            unsigned long el2:4;
+            unsigned long el3:4;
+            unsigned long fp:4;   /* Floating Point */
+            unsigned long simd:4; /* Advanced SIMD */
+            unsigned long __res0:8;
+
+            unsigned long __res1;
+        };
+    } pfr64;
+
+    struct {
+        uint64_t bits[2];
+    } dbg64;
+
+    struct {
+        uint64_t bits[2];
+    } aux64;
+
+    struct {
+        uint64_t bits[2];
+    } mm64;
+
+    struct {
+        uint64_t bits[2];
+    } isa64;
+
+#endif
+
+    /*
+     * 32-bit CPUID registers. On ARMv8 these describe the properties
+     * when running in 32-bit mode.
+     */
+    union {
+        uint32_t bits[2];
+        struct {
+            unsigned long arm:4;
+            unsigned long thumb:4;
+            unsigned long jazelle:4;
+            unsigned long thumbee:4;
+            unsigned long __res0:16;
+
+            unsigned long progmodel:4;
+            unsigned long security:4;
+            unsigned long mprofile:4;
+            unsigned long virt:4;
+            unsigned long gentimer:4;
+            unsigned long __res1:12;
+        };
+    } pfr32;
+
+    struct {
+        uint32_t bits[1];
+    } dbg32;
+
+    struct {
+        uint32_t bits[1];
+    } aux32;
+
+    struct {
+        uint32_t bits[4];
+    } mm32;
+
+    struct {
+        uint32_t bits[6];
+    } isa32;
+};
+
+/*
+ * capabilities of CPUs
+ */
+
+extern struct cpuinfo_arm boot_cpu_data;
+
+extern void identify_cpu(struct cpuinfo_arm *);
+
+extern struct cpuinfo_arm cpu_data[];
+#define current_cpu_data cpu_data[smp_processor_id()]
+
 union hsr {
     uint32_t bits;
     struct {
@@ -225,10 +342,6 @@ union hsr {
 #define CNTx_CTL_MASK     (1u<<1)  /* Mask IRQ */
 #define CNTx_CTL_PENDING  (1u<<2)  /* IRQ pending */
 
-/* CPUID bits */
-#define ID_PFR1_GT_MASK  0x000F0000  /* Generic Timer interface support */
-#define ID_PFR1_GT_v1    0x00010000
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/processor.h>
 #elif defined(CONFIG_ARM_64)
@@ -260,6 +373,10 @@ void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
                            const struct vcpu_guest_core_regs *regs);
 
+struct cpuinfo_x86 {
+    uint32_t pfr32[2];
+};
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_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 Fri Feb 22 09:03:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oX5-0001CV-EM; Fri, 22 Feb 2013 09:03: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 1U8oX3-0001B8-NH
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:06 +0000
Received: from [85.158.137.99:7391] by server-11.bemta-3.messagelabs.com id
	C5/A9-10249-44437215; Fri, 22 Feb 2013 09:03:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28477 invoked from network); 22 Feb 2013 09:02:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518823"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:58 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-En;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:57 +0000
Message-ID: <1361523505-7604-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 18/46] xen: arm64: start of day changes to
	setup.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: s/CSSELR_EL1/CCSIDR_EL1
---
 xen/arch/arm/setup.c         |   54 ++++++++++++++++++++++++++++--------------
 xen/include/asm-arm/cpregs.h |   25 +++++++++++++++++++
 2 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e07c1cb..f40cc7f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,16 +56,34 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
-    printk("Processor Features: %08x %08x\n",
-           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
-    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
-    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
-    printk("Memory Model Features: %08x %08x %08x %08x\n",
-           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
-           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
-    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
-           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+#if defined(CONFIG_ARM_64)
+    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
+    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
+    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
+    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
+    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+#endif
+    /*
+     * On AArch64 these refer to the capabilities when running in
+     * AArch32 mode.
+     */
+    printk("32-bit Processor Features: %08x %08x\n",
+           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
+    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
+    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
+    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
+           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
+    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
+           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
+           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
+
 }
 
 void __init discard_initial_modules(void)
@@ -250,7 +268,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n",
+                 xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -320,8 +339,8 @@ void __init setup_cache(void)
     uint32_t ccsid;
 
     /* Read the cache size ID register for the level-0 data cache */
-    WRITE_CP32(0, CSSELR);
-    ccsid = READ_CP32(CCSIDR);
+    WRITE_SYSREG32(0, CSSELR_EL1);
+    ccsid = READ_SYSREG32(CCSIDR_EL1);
 
     /* Low 3 bits are log2(cacheline size in words) - 2. */
     cacheline_bytes = 1U << (4 + (ccsid & 0x7));
@@ -366,16 +385,15 @@ void __init start_xen(unsigned long boot_phys_offset,
     idle_vcpu[0] = current;
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
-    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
-           READ_CP32(HVBAR), hyp_traps_vector);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    isb();
 
     /* Setup Stage 2 address translation */
     /* SH0=00, ORGN0=IRGN0=01
      * SL0=01 (Level-1)
      * T0SZ=(1)1000 = -8 (40 bit physical addresses)
      */
-    WRITE_CP32(0x80002558, VTCR); isb();
+    WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
     processor_id();
 
@@ -455,7 +473,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* Switch on to the dynamically allocated stack for the idle vcpu
      * since the static one we're running on is about to be freed. */
-    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(), 
+    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
            sizeof(struct cpu_info));
     switch_stack_and_jump(idle_vcpu[0]->arch.cpu_info, init_done);
 }
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index dbb5049..e34e066 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -222,6 +222,31 @@
 
 /* CP15 CR15: Implementation Defined Registers */
 
+/* Aliases of AArch64 names for use in common code when building for AArch32 */
+#ifdef CONFIG_ARM_32
+/* Alphabetically... */
+#define CCSIDR_EL1              CCSIDR
+#define CLIDR_EL1               CLIDR
+#define CSSELR_EL1              CSSELR
+#define ID_AFR0_EL1             ID_AFR0
+#define ID_DFR0_EL1             ID_DFR0
+#define ID_ISAR0_EL1            ID_ISAR0
+#define ID_ISAR1_EL1            ID_ISAR1
+#define ID_ISAR2_EL1            ID_ISAR2
+#define ID_ISAR3_EL1            ID_ISAR3
+#define ID_ISAR4_EL1            ID_ISAR4
+#define ID_ISAR5_EL1            ID_ISAR5
+#define ID_MMFR0_EL1            ID_MMFR0
+#define ID_MMFR1_EL1            ID_MMFR1
+#define ID_MMFR2_EL1            ID_MMFR2
+#define ID_MMFR3_EL1            ID_MMFR3
+#define ID_PFR0_EL1             ID_PFR0
+#define ID_PFR1_EL1             ID_PFR1
+#define VBAR_EL2                HVBAR
+#define VTCR_EL2                VTCR
+
+#endif
+
 #endif
 /*
  * Local variables:
-- 
1.7.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 Feb 22 09:03:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oX5-0001CV-EM; Fri, 22 Feb 2013 09:03: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 1U8oX3-0001B8-NH
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:06 +0000
Received: from [85.158.137.99:7391] by server-11.bemta-3.messagelabs.com id
	C5/A9-10249-44437215; Fri, 22 Feb 2013 09:03:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523762!17522139!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28477 invoked from network); 22 Feb 2013 09:02:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518823"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:58 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-En;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:57 +0000
Message-ID: <1361523505-7604-18-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 18/46] xen: arm64: start of day changes to
	setup.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: s/CSSELR_EL1/CCSIDR_EL1
---
 xen/arch/arm/setup.c         |   54 ++++++++++++++++++++++++++++--------------
 xen/include/asm-arm/cpregs.h |   25 +++++++++++++++++++
 2 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e07c1cb..f40cc7f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,16 +56,34 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
-    printk("Processor Features: %08x %08x\n",
-           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
-    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
-    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
-    printk("Memory Model Features: %08x %08x %08x %08x\n",
-           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
-           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
-    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
-           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
-           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+#if defined(CONFIG_ARM_64)
+    printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
+    printk("64-bit Debug Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64DFR0_EL1), READ_SYSREG64(ID_AA64DFR1_EL1));
+    printk("64-bit Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64AFR0_EL1), READ_SYSREG64(ID_AA64AFR1_EL1));
+    printk("64-bit Memory Model Features: %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64MMFR0_EL1), READ_SYSREG64(ID_AA64MMFR1_EL1));
+    printk("64-bit ISA Features:  %016"PRIx64" %016"PRIx64"\n",
+           READ_SYSREG64(ID_AA64ISAR0_EL1), READ_SYSREG64(ID_AA64ISAR1_EL1));
+#endif
+    /*
+     * On AArch64 these refer to the capabilities when running in
+     * AArch32 mode.
+     */
+    printk("32-bit Processor Features: %08x %08x\n",
+           READ_SYSREG32(ID_PFR0_EL1), READ_SYSREG32(ID_PFR1_EL1));
+    printk("32-bit Debug Features: %08x\n", READ_SYSREG32(ID_DFR0_EL1));
+    printk("32-bit Auxiliary Features: %08x\n", READ_SYSREG32(ID_AFR0_EL1));
+    printk("32-bit Memory Model Features: %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_MMFR0_EL1), READ_SYSREG32(ID_MMFR1_EL1),
+           READ_SYSREG32(ID_MMFR2_EL1), READ_SYSREG32(ID_MMFR3_EL1));
+    printk("32-bit ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_SYSREG32(ID_ISAR0_EL1), READ_SYSREG32(ID_ISAR1_EL1),
+           READ_SYSREG32(ID_ISAR2_EL1), READ_SYSREG32(ID_ISAR3_EL1),
+           READ_SYSREG32(ID_ISAR4_EL1), READ_SYSREG32(ID_ISAR5_EL1));
+
 }
 
 void __init discard_initial_modules(void)
@@ -250,7 +268,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 
     domheap_pages = heap_pages - xenheap_pages;
 
-    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
+    early_printk("Xen heap: %lu pages  Dom heap: %lu pages\n",
+                 xenheap_pages, domheap_pages);
 
     setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
@@ -320,8 +339,8 @@ void __init setup_cache(void)
     uint32_t ccsid;
 
     /* Read the cache size ID register for the level-0 data cache */
-    WRITE_CP32(0, CSSELR);
-    ccsid = READ_CP32(CCSIDR);
+    WRITE_SYSREG32(0, CSSELR_EL1);
+    ccsid = READ_SYSREG32(CCSIDR_EL1);
 
     /* Low 3 bits are log2(cacheline size in words) - 2. */
     cacheline_bytes = 1U << (4 + (ccsid & 0x7));
@@ -366,16 +385,15 @@ void __init start_xen(unsigned long boot_phys_offset,
     idle_vcpu[0] = current;
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
-    printk("Set hyp vector base to %"PRIx32" (expected %p)\n",
-           READ_CP32(HVBAR), hyp_traps_vector);
+    WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
+    isb();
 
     /* Setup Stage 2 address translation */
     /* SH0=00, ORGN0=IRGN0=01
      * SL0=01 (Level-1)
      * T0SZ=(1)1000 = -8 (40 bit physical addresses)
      */
-    WRITE_CP32(0x80002558, VTCR); isb();
+    WRITE_SYSREG32(0x80002558, VTCR_EL2); isb();
 
     processor_id();
 
@@ -455,7 +473,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* Switch on to the dynamically allocated stack for the idle vcpu
      * since the static one we're running on is about to be freed. */
-    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(), 
+    memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
            sizeof(struct cpu_info));
     switch_stack_and_jump(idle_vcpu[0]->arch.cpu_info, init_done);
 }
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index dbb5049..e34e066 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -222,6 +222,31 @@
 
 /* CP15 CR15: Implementation Defined Registers */
 
+/* Aliases of AArch64 names for use in common code when building for AArch32 */
+#ifdef CONFIG_ARM_32
+/* Alphabetically... */
+#define CCSIDR_EL1              CCSIDR
+#define CLIDR_EL1               CLIDR
+#define CSSELR_EL1              CSSELR
+#define ID_AFR0_EL1             ID_AFR0
+#define ID_DFR0_EL1             ID_DFR0
+#define ID_ISAR0_EL1            ID_ISAR0
+#define ID_ISAR1_EL1            ID_ISAR1
+#define ID_ISAR2_EL1            ID_ISAR2
+#define ID_ISAR3_EL1            ID_ISAR3
+#define ID_ISAR4_EL1            ID_ISAR4
+#define ID_ISAR5_EL1            ID_ISAR5
+#define ID_MMFR0_EL1            ID_MMFR0
+#define ID_MMFR1_EL1            ID_MMFR1
+#define ID_MMFR2_EL1            ID_MMFR2
+#define ID_MMFR3_EL1            ID_MMFR3
+#define ID_PFR0_EL1             ID_PFR0
+#define ID_PFR1_EL1             ID_PFR1
+#define VBAR_EL2                HVBAR
+#define VTCR_EL2                VTCR
+
+#endif
+
 #endif
 /*
  * Local variables:
-- 
1.7.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 Feb 22 09:03:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXC-0001Hs-Rh; Fri, 22 Feb 2013 09:03: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 1U8oXB-0001GG-IZ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:13 +0000
Received: from [85.158.137.99:11689] by server-2.bemta-3.messagelabs.com id
	41/CB-25961-05437215; Fri, 22 Feb 2013 09:03:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523790!17522267!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29866 invoked from network); 22 Feb 2013 09:03:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518848"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:09 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Vy;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:15 +0000
Message-ID: <1361523505-7604-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 36/46] xen: arm: Use 64-bit compatible
	registers in vtimer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, don't crash the host if we fail to emulate a vtimer access,
just kill the guest.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c  |   14 ++++++++++++--
 xen/arch/arm/vtimer.c |   21 ++++++++++++---------
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ed87f8..75d42ab 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -712,7 +712,12 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 32-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
@@ -742,7 +747,12 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 64-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 802c2bc..dfe3a3e 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -43,7 +43,7 @@ static void virt_timer_expired(void *data)
     t->ctl |= CNTx_CTL_MASK;
     vgic_vcpu_inject_irq(t->v, 27, 1);
 }
- 
+
 int vcpu_vtimer_init(struct vcpu *v)
 {
     struct vtimer *t = &v->arch.phys_timer;
@@ -58,7 +58,7 @@ int vcpu_vtimer_init(struct vcpu *v)
     t = &v->arch.virt_timer;
     init_timer(&t->timer, virt_timer_expired, t, smp_processor_id());
     t->ctl = 0;
-    t->offset = READ_CP64(CNTVCT) + READ_CP64(CNTVOFF);
+    t->offset = READ_SYSREG64(CNTVCT_EL0) + READ_SYSREG64(CNTVOFF_EL2);
     t->cval = 0;
     t->irq = 27;
     t->v = v;
@@ -77,9 +77,9 @@ int virt_timer_save(struct vcpu *v)
     if ( is_idle_domain(v->domain) )
         return 0;
 
-    v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
-    v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
+    v->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL_EL0);
+    v->arch.virt_timer.cval = READ_SYSREG64(CNTV_CVAL_EL0);
     if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
@@ -95,12 +95,12 @@ int virt_timer_restore(struct vcpu *v)
 
     stop_timer(&v->arch.virt_timer.timer);
 
-    WRITE_CP64(v->arch.virt_timer.offset, CNTVOFF);
-    WRITE_CP64(v->arch.virt_timer.cval, CNTV_CVAL);
-    WRITE_CP32(v->arch.virt_timer.ctl, CNTV_CTL);
+    WRITE_SYSREG64(v->arch.virt_timer.offset, CNTVOFF_EL2);
+    WRITE_SYSREG64(v->arch.virt_timer.cval, CNTV_CVAL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl, CNTV_CTL_EL0);
     return 0;
 }
- 
+
 static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
@@ -186,6 +186,9 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 
 int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
 {
+    if ( !is_pv32_domain(current->domain) )
+        return -EINVAL;
+
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
         return vtimer_emulate_32(regs, hsr);
-- 
1.7.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 Feb 22 09:03:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXC-0001Hs-Rh; Fri, 22 Feb 2013 09:03: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 1U8oXB-0001GG-IZ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:13 +0000
Received: from [85.158.137.99:11689] by server-2.bemta-3.messagelabs.com id
	41/CB-25961-05437215; Fri, 22 Feb 2013 09:03:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361523790!17522267!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29866 invoked from network); 22 Feb 2013 09:03:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518848"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:09 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Vy;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:15 +0000
Message-ID: <1361523505-7604-36-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 36/46] xen: arm: Use 64-bit compatible
	registers in vtimer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, don't crash the host if we fail to emulate a vtimer access,
just kill the guest.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c  |   14 ++++++++++++--
 xen/arch/arm/vtimer.c |   21 ++++++++++++---------
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ed87f8..75d42ab 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -712,7 +712,12 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 32-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
@@ -742,7 +747,12 @@ static void do_cp15_64(struct cpu_user_regs *regs,
     switch ( hsr.bits & HSR_CP64_REGS_MASK )
     {
     case HSR_CPREG64(CNTPCT):
-        BUG_ON(!vtimer_emulate(regs, hsr));
+        if ( !vtimer_emulate(regs, hsr) )
+        {
+            dprintk(XENLOG_ERR,
+                    "failed emulation of 64-bit vtimer CP register access\n");
+            domain_crash_synchronous();
+        }
         break;
     default:
         printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 802c2bc..dfe3a3e 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -43,7 +43,7 @@ static void virt_timer_expired(void *data)
     t->ctl |= CNTx_CTL_MASK;
     vgic_vcpu_inject_irq(t->v, 27, 1);
 }
- 
+
 int vcpu_vtimer_init(struct vcpu *v)
 {
     struct vtimer *t = &v->arch.phys_timer;
@@ -58,7 +58,7 @@ int vcpu_vtimer_init(struct vcpu *v)
     t = &v->arch.virt_timer;
     init_timer(&t->timer, virt_timer_expired, t, smp_processor_id());
     t->ctl = 0;
-    t->offset = READ_CP64(CNTVCT) + READ_CP64(CNTVOFF);
+    t->offset = READ_SYSREG64(CNTVCT_EL0) + READ_SYSREG64(CNTVOFF_EL2);
     t->cval = 0;
     t->irq = 27;
     t->v = v;
@@ -77,9 +77,9 @@ int virt_timer_save(struct vcpu *v)
     if ( is_idle_domain(v->domain) )
         return 0;
 
-    v->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL);
-    v->arch.virt_timer.cval = READ_CP64(CNTV_CVAL);
+    v->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl & ~CNTx_CTL_ENABLE, CNTV_CTL_EL0);
+    v->arch.virt_timer.cval = READ_SYSREG64(CNTV_CVAL_EL0);
     if ( v->arch.virt_timer.ctl & CNTx_CTL_ENABLE )
     {
         set_timer(&v->arch.virt_timer.timer, ticks_to_ns(v->arch.virt_timer.cval +
@@ -95,12 +95,12 @@ int virt_timer_restore(struct vcpu *v)
 
     stop_timer(&v->arch.virt_timer.timer);
 
-    WRITE_CP64(v->arch.virt_timer.offset, CNTVOFF);
-    WRITE_CP64(v->arch.virt_timer.cval, CNTV_CVAL);
-    WRITE_CP32(v->arch.virt_timer.ctl, CNTV_CTL);
+    WRITE_SYSREG64(v->arch.virt_timer.offset, CNTVOFF_EL2);
+    WRITE_SYSREG64(v->arch.virt_timer.cval, CNTV_CVAL_EL0);
+    WRITE_SYSREG32(v->arch.virt_timer.ctl, CNTV_CTL_EL0);
     return 0;
 }
- 
+
 static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
@@ -186,6 +186,9 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 
 int vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr)
 {
+    if ( !is_pv32_domain(current->domain) )
+        return -EINVAL;
+
     switch (hsr.ec) {
     case HSR_EC_CP15_32:
         return vtimer_emulate_32(regs, hsr);
-- 
1.7.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 Feb 22 09:03:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8oXE-0001J7-8J; Fri, 22 Feb 2013 09:03:16 +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 1U8oXD-0001He-16
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:15 +0000
Received: from [85.158.139.211:60252] by server-16.bemta-5.messagelabs.com id
	24/84-14948-25437215; Fri, 22 Feb 2013 09:03:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2308 invoked from network); 22 Feb 2013 09:02:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956576"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:49 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Lk;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:03 +0000
Message-ID: <1361523505-7604-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 24/46] xen: arm: separate guest user regs
	from internal guest 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

struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).

This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.

So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.

In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.

This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Allow 32-bit to see 64-bit register names too, this is needed so that
    32-bit toolstacks can access/control 64-bit guests.
---
 tools/include/xen-foreign/mkheader.py    |   16 ++++
 tools/include/xen-foreign/reference.size |    5 +-
 tools/include/xen-foreign/structs.py     |    1 +
 tools/libxc/xc_dom_arm.c                 |   10 ++--
 xen/arch/arm/arm32/Makefile              |    2 +
 xen/arch/arm/arm32/domain.c              |   51 +++++++++++++
 xen/arch/arm/arm64/Makefile              |    2 +
 xen/arch/arm/arm64/domain.c              |   66 +++++++++++++++++
 xen/arch/arm/domain.c                    |    4 +-
 xen/arch/arm/domctl.c                    |    4 +-
 xen/include/asm-arm/arm32/processor.h    |   52 +++++++++++++
 xen/include/asm-arm/arm64/processor.h    |   81 +++++++++++++++++++++
 xen/include/asm-arm/current.h            |    1 +
 xen/include/asm-arm/processor.h          |    5 ++
 xen/include/public/arch-arm.h            |  115 ++++++++++++++++++------------
 15 files changed, 359 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain.c
 create mode 100644 xen/arch/arm/arm64/domain.c

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index c63db31..8a784d3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -25,7 +25,15 @@ inttypes["arm32"] = {
 };
 header["arm32"] = """
 #define __arm___ARM32 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
+footer["arm32"] = """
+#undef __DECL_REG
+"""
 
 inttypes["arm64"] = {
     "unsigned long" : "__danger_unsigned_long_on_arm64",
@@ -35,7 +43,15 @@ inttypes["arm64"] = {
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
+footer["arm64"] = """
+#undef __DECL_REG
+"""
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 1d75ff3..de36455 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -3,8 +3,9 @@ structs                   |   arm32   arm64  x86_32  x86_64
 
 start_info                |       -       -    1112    1168
 trap_info                 |       -       -       8      16
-cpu_user_regs             |     160     160      68     200
-vcpu_guest_context        |     180     160    2800    5168
+cpu_user_regs             |       -       -      68     200
+vcpu_guest_core_regs      |     304     304       -       -
+vcpu_guest_context        |     336     336    2800    5168
 arch_vcpu_info            |       -       -      24      16
 vcpu_time_info            |       -       -      32      32
 vcpu_info                 |       -       -      64      64
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 5aec2c5..0b33a77 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -6,6 +6,7 @@ unions  = [ "vcpu_cr_regs",
 structs = [ "start_info",
             "trap_info",
             "cpu_user_regs",
+            "vcpu_guest_core_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 7f6d7ce..041832e 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -107,17 +107,17 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     /* clear everything */
     memset(ctxt, 0, sizeof(*ctxt));
 
-    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.pc32 = dom->parms.virt_entry;
 
     /* Linux boot protocol. See linux.Documentation/arm/Booting. */
-    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r0_usr = 0; /* SBZ */
     /* Machine ID: We use DTB therefore no machine id */
-    ctxt->user_regs.r1 = 0xffffffff;
+    ctxt->user_regs.r1_usr = 0xffffffff;
     /* ATAGS/DTB: We currently require that the guest kernel to be
      * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look
      * like a valid pointer to a set of ATAGS or a DTB.
      */
-    ctxt->user_regs.r2 = 0xffffffff;
+    ctxt->user_regs.r2_usr = 0xffffffff;
 
     ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
 
@@ -130,7 +130,7 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     ctxt->flags = VGCF_online;
 
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
-           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
     return 0;
 }
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 20931fa..29898ae 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -3,3 +3,5 @@ subdir-y += lib
 obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm32/domain.c b/xen/arch/arm/arm32/domain.c
new file mode 100644
index 0000000..f75a2c6
--- /dev/null
+++ b/xen/arch/arm/arm32/domain.c
@@ -0,0 +1,51 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(r0,r0_usr);   C(r1,r1_usr);   C(r2,r2_usr);   C(r3,r3_usr);   \
+    C(r4,r4_usr);   C(r5,r5_usr);   C(r6,r6_usr);   C(r7,r7_usr);   \
+    C(r8,r8_usr);   C(r9,r9_usr);   C(r10,r10_usr); C(r11,r11_usr); \
+    C(r12,r12_usr); \
+    C(sp_usr,sp_usr); \
+    C(lr,lr_usr); \
+    C(spsr_irq,spsr_irq); C(lr_irq,lr_irq); C(sp_irq,sp_irq); \
+    C(spsr_svc,spsr_svc); C(lr_svc,lr_svc); C(sp_svc,sp_svc); \
+    C(spsr_abt,spsr_abt); C(lr_abt,lr_abt); C(sp_abt,sp_abt); \
+    C(spsr_und,spsr_und); C(lr_und,lr_und); C(sp_und,sp_und); \
+    C(spsr_fiq,spsr_fiq); C(sp_fiq,sp_fiq); C(sp_fiq,sp_fiq); \
+    C(r8_fiq,r8_fiq); C(r9_fiq,r9_fiq); \
+    C(r10_fiq,r10_fiq); C(r11_fiq,r11_fiq); C(r12_fiq,r12_fiq); \
+    C(pc,pc32); \
+    C(cpsr,cpsr)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c447eaa..815f305 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,3 +1,5 @@
 subdir-y += lib
 
 obj-y += mode_switch.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm64/domain.c b/xen/arch/arm/arm64/domain.c
new file mode 100644
index 0000000..05df29e
--- /dev/null
+++ b/xen/arch/arm/arm64/domain.c
@@ -0,0 +1,66 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(x0,x0);   C(x1,x1);   C(x2,x2);   C(x3,x3);   \
+    C(x4,x4);   C(x5,x5);   C(x6,x6);   C(x7,x7);   \
+    C(x8,x8);   C(x9,x9);   C(x10,x10); C(x11,x11); \
+    C(x12,x12); C(x13,x13); C(x14,x14); C(x15,x15); \
+    C(x16,x16); C(x17,x17); C(x18,x18); C(x19,x19); \
+    C(x20,x20); C(x21,x21); C(x22,x22); C(x23,x23); \
+    C(x24,x24); C(x25,x25); C(x26,x26); C(x27,x27); \
+    C(x28,x28); C(fp,x29);  C(lr,x30);  C(pc,pc64); \
+    C(cpsr, cpsr); C(spsr_el1, spsr_el1)
+
+#define ALLREGS32 C(spsr_fiq, spsr_fiq); C(spsr_irq,spsr_irq); \
+                  C(spsr_und,spsr_und); C(spsr_abt,spsr_abt)
+
+#define ALLREGS64 C(sp_el0,sp_el0); C(sp_el1,sp_el1); C(elr_el1,elr_el1)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2445b6a..3d21f0e 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,7 +486,7 @@ int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
     if ( !is_guest_psr(regs->cpsr) )
         return -EINVAL;
@@ -502,7 +502,7 @@ int arch_set_info_guest(
     if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
         return -EINVAL;
 
-    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+    vcpu_regs_user_to_hyp(v, regs);
 
     v->arch.sctlr = ctxt->sctlr;
     v->arch.ttbr0 = ctxt->ttbr0;
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index c0f30e2..851ee40 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -20,9 +20,9 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
-    *regs = v->arch.cpu_info->guest_cpu_user_regs;
+    vcpu_regs_hyp_to_user(v, regs);
 
     ctxt->sctlr = v->arch.sctlr;
     ctxt->ttbr0 = v->arch.ttbr0;
diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
index 843fbd2..a782d96 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,58 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#ifndef __ASSEMBLY__
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+        uint32_t r11;
+        uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+        uint32_t lr_usr;
+    };
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_irq, lr_irq;
+    uint32_t sp_svc, lr_svc;
+    uint32_t sp_abt, lr_abt;
+    uint32_t sp_und, lr_und;
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+    uint32_t sp_fiq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
+};
+#endif
+
 /* Layout as used in assembly, with src/dest registers mixed in */
 #define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
 #define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
index fdb0dab..b4602fa 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,87 @@
 
 #ifndef __ASSEMBLY__
 
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+
+#define __DECL_REG(n64, n32) union {            \
+    uint64_t n64;                               \
+    uint32_t n32;                               \
+}
+
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0/*_usr*/);
+    __DECL_REG(x1,           r1/*_usr*/);
+    __DECL_REG(x2,           r2/*_usr*/);
+    __DECL_REG(x3,           r3/*_usr*/);
+    __DECL_REG(x4,           r4/*_usr*/);
+    __DECL_REG(x5,           r5/*_usr*/);
+    __DECL_REG(x6,           r6/*_usr*/);
+    __DECL_REG(x7,           r7/*_usr*/);
+    __DECL_REG(x8,           r8/*_usr*/);
+    __DECL_REG(x9,           r9/*_usr*/);
+    __DECL_REG(x10,          r10/*_usr*/);
+    __DECL_REG(x11 ,         r11/*_usr*/);
+    __DECL_REG(x12,          r12/*_usr*/);
+
+    __DECL_REG(x13,          /* r13_usr */ sp_usr);
+    __DECL_REG(x14,          /* r14_usr */ lr_usr);
+
+    __DECL_REG(x15,          /* r13_hyp */ __unused_sp_hyp);
+
+    __DECL_REG(x16,          /* r14_irq */ lr_irq);
+    __DECL_REG(x17,          /* r13_irq */ sp_irq);
+
+    __DECL_REG(x18,          /* r14_svc */ lr_svc);
+    __DECL_REG(x19,          /* r13_svc */ sp_svc);
+
+    __DECL_REG(x20,          /* r14_abt */ lr_abt);
+    __DECL_REG(x21,          /* r13_abt */ sp_abt);
+
+    __DECL_REG(x22,          /* r14_und */ lr_und);
+    __DECL_REG(x23,          /* r13_und */ sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+    __DECL_REG(/* x29 */ fp, /* r13_fiq */ sp_fiq);
+    __DECL_REG(/* x30 */ lr, /* r14_fiq */ lr_fiq);
+
+    register_t sp; /* Valid for hypervisor frames */
+
+    /* Return address and mode */
+    __DECL_REG(pc,           pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
+
+    uint64_t pad0;
+
+    /* Outer guest frame only from here on... */
+
+    union {
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
+    };
+
+    uint32_t pad1; /* Align */
+
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
+
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
+
+    uint64_t pad2; /* Doubleword-align the user half of the frame */
+};
+
+#undef __DECL_REG
+
+/* Access to system registers */
+
 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
     asm volatile("mrs  %0, "#name : "=r" (_r));         \
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index f3432bb..65c0cdf 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -6,6 +6,7 @@
 #include <public/xen.h>
 
 #include <asm/percpu.h>
+#include <asm/processor.h>
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index a9ce041..f7aa9e2 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,11 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs);
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_H */
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 5306f79..3333399 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -86,55 +86,80 @@
 #endif
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-struct cpu_user_regs
-{
-    uint32_t r0;
-    uint32_t r1;
-    uint32_t r2;
-    uint32_t r3;
-    uint32_t r4;
-    uint32_t r5;
-    uint32_t r6;
-    uint32_t r7;
-    uint32_t r8;
-    uint32_t r9;
-    uint32_t r10;
-    union {
-        uint32_t r11;
-        uint32_t fp;
-    };
-    uint32_t r12;
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+# define __DECL_REG(n64, n32) union {          \
+        uint64_t n64;                          \
+        uint32_t n32;                          \
+    }
+#else
+/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
+#define __DECL_REG(n64, n32) uint64_t n64
+#endif
 
-    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+struct vcpu_guest_core_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0_usr);
+    __DECL_REG(x1,           r1_usr);
+    __DECL_REG(x2,           r2_usr);
+    __DECL_REG(x3,           r3_usr);
+    __DECL_REG(x4,           r4_usr);
+    __DECL_REG(x5,           r5_usr);
+    __DECL_REG(x6,           r6_usr);
+    __DECL_REG(x7,           r7_usr);
+    __DECL_REG(x8,           r8_usr);
+    __DECL_REG(x9,           r9_usr);
+    __DECL_REG(x10,          r10_usr);
+    __DECL_REG(x11,          r11_usr);
+    __DECL_REG(x12,          r12_usr);
+
+    __DECL_REG(x13,          sp_usr);
+    __DECL_REG(x14,          lr_usr);
+
+    __DECL_REG(x15,          __unused_sp_hyp);
+
+    __DECL_REG(x16,          lr_irq);
+    __DECL_REG(x17,          sp_irq);
+
+    __DECL_REG(x18,          lr_svc);
+    __DECL_REG(x19,          sp_svc);
+
+    __DECL_REG(x20,          lr_abt);
+    __DECL_REG(x21,          sp_abt);
+
+    __DECL_REG(x22,          lr_und);
+    __DECL_REG(x23,          sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+
+    __DECL_REG(x29,          sp_fiq);
+    __DECL_REG(x30,          lr_fiq);
+
+    /* Return address and mode */
+    __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
 
-    /* r14 - LR: is the same physical register as LR_usr */
     union {
-        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
-        uint32_t lr_usr;
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
     };
 
-    uint32_t pc; /* Return IP */
-    uint32_t cpsr; /* Return mode */
-    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
-
-    /* Outer guest frame only from here on... */
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
 
-    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
-
-    uint32_t sp_irq, lr_irq;
-    uint32_t sp_svc, lr_svc;
-    uint32_t sp_abt, lr_abt;
-    uint32_t sp_und, lr_und;
-
-    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
-    uint32_t sp_fiq, lr_fiq;
-
-    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
-
-    uint32_t pad1; /* Doubleword-align the user half of the frame */
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
 };
-typedef struct cpu_user_regs cpu_user_regs_t;
-DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+typedef struct vcpu_guest_core_regs vcpu_guest_core_regs_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
+
+#undef __DECL_REG
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
@@ -151,10 +176,10 @@ struct vcpu_guest_context {
 #define VGCF_online                    (1<<_VGCF_online)
     uint32_t flags;                         /* VGCF_* */
 
-    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    struct vcpu_guest_core_regs user_regs;  /* Core CPU registers */
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
1.7.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 Feb 22 09:03:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8oXE-0001J7-8J; Fri, 22 Feb 2013 09:03:16 +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 1U8oXD-0001He-16
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:15 +0000
Received: from [85.158.139.211:60252] by server-16.bemta-5.messagelabs.com id
	24/84-14948-25437215; Fri, 22 Feb 2013 09:03:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2308 invoked from network); 22 Feb 2013 09:02:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956576"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:49 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Lk;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:03 +0000
Message-ID: <1361523505-7604-24-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 24/46] xen: arm: separate guest user regs
	from internal guest 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

struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).

This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.

So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.

In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.

This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Allow 32-bit to see 64-bit register names too, this is needed so that
    32-bit toolstacks can access/control 64-bit guests.
---
 tools/include/xen-foreign/mkheader.py    |   16 ++++
 tools/include/xen-foreign/reference.size |    5 +-
 tools/include/xen-foreign/structs.py     |    1 +
 tools/libxc/xc_dom_arm.c                 |   10 ++--
 xen/arch/arm/arm32/Makefile              |    2 +
 xen/arch/arm/arm32/domain.c              |   51 +++++++++++++
 xen/arch/arm/arm64/Makefile              |    2 +
 xen/arch/arm/arm64/domain.c              |   66 +++++++++++++++++
 xen/arch/arm/domain.c                    |    4 +-
 xen/arch/arm/domctl.c                    |    4 +-
 xen/include/asm-arm/arm32/processor.h    |   52 +++++++++++++
 xen/include/asm-arm/arm64/processor.h    |   81 +++++++++++++++++++++
 xen/include/asm-arm/current.h            |    1 +
 xen/include/asm-arm/processor.h          |    5 ++
 xen/include/public/arch-arm.h            |  115 ++++++++++++++++++------------
 15 files changed, 359 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/arm32/domain.c
 create mode 100644 xen/arch/arm/arm64/domain.c

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index c63db31..8a784d3 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -25,7 +25,15 @@ inttypes["arm32"] = {
 };
 header["arm32"] = """
 #define __arm___ARM32 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
+footer["arm32"] = """
+#undef __DECL_REG
+"""
 
 inttypes["arm64"] = {
     "unsigned long" : "__danger_unsigned_long_on_arm64",
@@ -35,7 +43,15 @@ inttypes["arm64"] = {
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+# define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+#else
+# define __DECL_REG(n64, n32) uint64_t n64
+#endif
 """;
+footer["arm64"] = """
+#undef __DECL_REG
+"""
 
 # x86_32
 inttypes["x86_32"] = {
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 1d75ff3..de36455 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -3,8 +3,9 @@ structs                   |   arm32   arm64  x86_32  x86_64
 
 start_info                |       -       -    1112    1168
 trap_info                 |       -       -       8      16
-cpu_user_regs             |     160     160      68     200
-vcpu_guest_context        |     180     160    2800    5168
+cpu_user_regs             |       -       -      68     200
+vcpu_guest_core_regs      |     304     304       -       -
+vcpu_guest_context        |     336     336    2800    5168
 arch_vcpu_info            |       -       -      24      16
 vcpu_time_info            |       -       -      32      32
 vcpu_info                 |       -       -      64      64
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 5aec2c5..0b33a77 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -6,6 +6,7 @@ unions  = [ "vcpu_cr_regs",
 structs = [ "start_info",
             "trap_info",
             "cpu_user_regs",
+            "vcpu_guest_core_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 7f6d7ce..041832e 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -107,17 +107,17 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     /* clear everything */
     memset(ctxt, 0, sizeof(*ctxt));
 
-    ctxt->user_regs.pc = dom->parms.virt_entry;
+    ctxt->user_regs.pc32 = dom->parms.virt_entry;
 
     /* Linux boot protocol. See linux.Documentation/arm/Booting. */
-    ctxt->user_regs.r0 = 0; /* SBZ */
+    ctxt->user_regs.r0_usr = 0; /* SBZ */
     /* Machine ID: We use DTB therefore no machine id */
-    ctxt->user_regs.r1 = 0xffffffff;
+    ctxt->user_regs.r1_usr = 0xffffffff;
     /* ATAGS/DTB: We currently require that the guest kernel to be
      * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look
      * like a valid pointer to a set of ATAGS or a DTB.
      */
-    ctxt->user_regs.r2 = 0xffffffff;
+    ctxt->user_regs.r2_usr = 0xffffffff;
 
     ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078;
 
@@ -130,7 +130,7 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr)
     ctxt->flags = VGCF_online;
 
     DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32,
-           ctxt->user_regs.cpsr, ctxt->user_regs.pc);
+           ctxt->user_regs.cpsr, ctxt->user_regs.pc32);
 
     return 0;
 }
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 20931fa..29898ae 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -3,3 +3,5 @@ subdir-y += lib
 obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm32/domain.c b/xen/arch/arm/arm32/domain.c
new file mode 100644
index 0000000..f75a2c6
--- /dev/null
+++ b/xen/arch/arm/arm32/domain.c
@@ -0,0 +1,51 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(r0,r0_usr);   C(r1,r1_usr);   C(r2,r2_usr);   C(r3,r3_usr);   \
+    C(r4,r4_usr);   C(r5,r5_usr);   C(r6,r6_usr);   C(r7,r7_usr);   \
+    C(r8,r8_usr);   C(r9,r9_usr);   C(r10,r10_usr); C(r11,r11_usr); \
+    C(r12,r12_usr); \
+    C(sp_usr,sp_usr); \
+    C(lr,lr_usr); \
+    C(spsr_irq,spsr_irq); C(lr_irq,lr_irq); C(sp_irq,sp_irq); \
+    C(spsr_svc,spsr_svc); C(lr_svc,lr_svc); C(sp_svc,sp_svc); \
+    C(spsr_abt,spsr_abt); C(lr_abt,lr_abt); C(sp_abt,sp_abt); \
+    C(spsr_und,spsr_und); C(lr_und,lr_und); C(sp_und,sp_und); \
+    C(spsr_fiq,spsr_fiq); C(sp_fiq,sp_fiq); C(sp_fiq,sp_fiq); \
+    C(r8_fiq,r8_fiq); C(r9_fiq,r9_fiq); \
+    C(r10_fiq,r10_fiq); C(r11_fiq,r11_fiq); C(r12_fiq,r12_fiq); \
+    C(pc,pc32); \
+    C(cpsr,cpsr)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c447eaa..815f305 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,3 +1,5 @@
 subdir-y += lib
 
 obj-y += mode_switch.o
+
+obj-y += domain.o
diff --git a/xen/arch/arm/arm64/domain.c b/xen/arch/arm/arm64/domain.c
new file mode 100644
index 0000000..05df29e
--- /dev/null
+++ b/xen/arch/arm/arm64/domain.c
@@ -0,0 +1,66 @@
+#include <xen/config.h>
+#include <xen/sched.h>
+
+#include <asm/domain.h>
+#include <asm/processor.h>
+
+#include <public/xen.h>
+
+/* C(hyp,user), hyp is Xen internal name, user is user API name. */
+
+#define ALLREGS \
+    C(x0,x0);   C(x1,x1);   C(x2,x2);   C(x3,x3);   \
+    C(x4,x4);   C(x5,x5);   C(x6,x6);   C(x7,x7);   \
+    C(x8,x8);   C(x9,x9);   C(x10,x10); C(x11,x11); \
+    C(x12,x12); C(x13,x13); C(x14,x14); C(x15,x15); \
+    C(x16,x16); C(x17,x17); C(x18,x18); C(x19,x19); \
+    C(x20,x20); C(x21,x21); C(x22,x22); C(x23,x23); \
+    C(x24,x24); C(x25,x25); C(x26,x26); C(x27,x27); \
+    C(x28,x28); C(fp,x29);  C(lr,x30);  C(pc,pc64); \
+    C(cpsr, cpsr); C(spsr_el1, spsr_el1)
+
+#define ALLREGS32 C(spsr_fiq, spsr_fiq); C(spsr_irq,spsr_irq); \
+                  C(spsr_und,spsr_und); C(spsr_abt,spsr_abt)
+
+#define ALLREGS64 C(sp_el0,sp_el0); C(sp_el1,sp_el1); C(elr_el1,elr_el1)
+
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) regs->user = vcpu->arch.cpu_info->guest_cpu_user_regs.hyp
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs)
+{
+#define C(hyp,user) vcpu->arch.cpu_info->guest_cpu_user_regs.hyp = regs->user
+    ALLREGS;
+    if ( is_pv32_domain(vcpu->domain) )
+    {
+        ALLREGS32;
+    }
+    else
+    {
+        ALLREGS64;
+    }
+#undef C
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2445b6a..3d21f0e 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -486,7 +486,7 @@ int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
     if ( !is_guest_psr(regs->cpsr) )
         return -EINVAL;
@@ -502,7 +502,7 @@ int arch_set_info_guest(
     if ( regs->spsr_fiq && !is_guest_psr(regs->spsr_fiq) )
         return -EINVAL;
 
-    v->arch.cpu_info->guest_cpu_user_regs = *regs;
+    vcpu_regs_user_to_hyp(v, regs);
 
     v->arch.sctlr = ctxt->sctlr;
     v->arch.ttbr0 = ctxt->ttbr0;
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index c0f30e2..851ee40 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -20,9 +20,9 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
 {
     struct vcpu_guest_context *ctxt = c.nat;
-    struct cpu_user_regs *regs = &c.nat->user_regs;
+    struct vcpu_guest_core_regs *regs = &c.nat->user_regs;
 
-    *regs = v->arch.cpu_info->guest_cpu_user_regs;
+    vcpu_regs_hyp_to_user(v, regs);
 
     ctxt->sctlr = v->arch.sctlr;
     ctxt->ttbr0 = v->arch.ttbr0;
diff --git a/xen/include/asm-arm/arm32/processor.h b/xen/include/asm-arm/arm32/processor.h
index 843fbd2..a782d96 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -1,6 +1,58 @@
 #ifndef __ASM_ARM_ARM32_PROCESSOR_H
 #define __ASM_ARM_ARM32_PROCESSOR_H
 
+#ifndef __ASSEMBLY__
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    uint32_t r0;
+    uint32_t r1;
+    uint32_t r2;
+    uint32_t r3;
+    uint32_t r4;
+    uint32_t r5;
+    uint32_t r6;
+    uint32_t r7;
+    uint32_t r8;
+    uint32_t r9;
+    uint32_t r10;
+    union {
+        uint32_t r11;
+        uint32_t fp;
+    };
+    uint32_t r12;
+
+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+
+    /* r14 - LR: is the same physical register as LR_usr */
+    union {
+        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
+
+        uint32_t lr_usr;
+    };
+
+    uint32_t pc; /* Return IP */
+    uint32_t cpsr; /* Return mode */
+    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
+
+    /* Outer guest frame only from here on... */
+
+    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
+
+    uint32_t sp_irq, lr_irq;
+    uint32_t sp_svc, lr_svc;
+    uint32_t sp_abt, lr_abt;
+    uint32_t sp_und, lr_und;
+
+    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
+    uint32_t sp_fiq, lr_fiq;
+
+    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
+
+    uint32_t pad1; /* Doubleword-align the user half of the frame */
+};
+#endif
+
 /* Layout as used in assembly, with src/dest registers mixed in */
 #define __CP32(r, coproc, opc1, crn, crm, opc2) coproc, opc1, r, crn, crm, opc2
 #define __CP64(r1, r2, coproc, opc, crm) coproc, opc, r1, r2, crm
diff --git a/xen/include/asm-arm/arm64/processor.h b/xen/include/asm-arm/arm64/processor.h
index fdb0dab..b4602fa 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -3,6 +3,87 @@
 
 #ifndef __ASSEMBLY__
 
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+
+#define __DECL_REG(n64, n32) union {            \
+    uint64_t n64;                               \
+    uint32_t n32;                               \
+}
+
+/* On stack VCPU state */
+struct cpu_user_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0/*_usr*/);
+    __DECL_REG(x1,           r1/*_usr*/);
+    __DECL_REG(x2,           r2/*_usr*/);
+    __DECL_REG(x3,           r3/*_usr*/);
+    __DECL_REG(x4,           r4/*_usr*/);
+    __DECL_REG(x5,           r5/*_usr*/);
+    __DECL_REG(x6,           r6/*_usr*/);
+    __DECL_REG(x7,           r7/*_usr*/);
+    __DECL_REG(x8,           r8/*_usr*/);
+    __DECL_REG(x9,           r9/*_usr*/);
+    __DECL_REG(x10,          r10/*_usr*/);
+    __DECL_REG(x11 ,         r11/*_usr*/);
+    __DECL_REG(x12,          r12/*_usr*/);
+
+    __DECL_REG(x13,          /* r13_usr */ sp_usr);
+    __DECL_REG(x14,          /* r14_usr */ lr_usr);
+
+    __DECL_REG(x15,          /* r13_hyp */ __unused_sp_hyp);
+
+    __DECL_REG(x16,          /* r14_irq */ lr_irq);
+    __DECL_REG(x17,          /* r13_irq */ sp_irq);
+
+    __DECL_REG(x18,          /* r14_svc */ lr_svc);
+    __DECL_REG(x19,          /* r13_svc */ sp_svc);
+
+    __DECL_REG(x20,          /* r14_abt */ lr_abt);
+    __DECL_REG(x21,          /* r13_abt */ sp_abt);
+
+    __DECL_REG(x22,          /* r14_und */ lr_und);
+    __DECL_REG(x23,          /* r13_und */ sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+    __DECL_REG(/* x29 */ fp, /* r13_fiq */ sp_fiq);
+    __DECL_REG(/* x30 */ lr, /* r14_fiq */ lr_fiq);
+
+    register_t sp; /* Valid for hypervisor frames */
+
+    /* Return address and mode */
+    __DECL_REG(pc,           pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
+
+    uint64_t pad0;
+
+    /* Outer guest frame only from here on... */
+
+    union {
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
+    };
+
+    uint32_t pad1; /* Align */
+
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
+
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
+
+    uint64_t pad2; /* Doubleword-align the user half of the frame */
+};
+
+#undef __DECL_REG
+
+/* Access to system registers */
+
 #define READ_SYSREG32(name) ({                          \
     uint32_t _r;                                        \
     asm volatile("mrs  %0, "#name : "=r" (_r));         \
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index f3432bb..65c0cdf 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -6,6 +6,7 @@
 #include <public/xen.h>
 
 #include <asm/percpu.h>
+#include <asm/processor.h>
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index a9ce041..f7aa9e2 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,11 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
+                           struct vcpu_guest_core_regs *regs);
+void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
+                           const struct vcpu_guest_core_regs *regs);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_ARM_PROCESSOR_H */
 /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 5306f79..3333399 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -86,55 +86,80 @@
 #endif
 #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
 
-struct cpu_user_regs
-{
-    uint32_t r0;
-    uint32_t r1;
-    uint32_t r2;
-    uint32_t r3;
-    uint32_t r4;
-    uint32_t r5;
-    uint32_t r6;
-    uint32_t r7;
-    uint32_t r8;
-    uint32_t r9;
-    uint32_t r10;
-    union {
-        uint32_t r11;
-        uint32_t fp;
-    };
-    uint32_t r12;
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
+# define __DECL_REG(n64, n32) union {          \
+        uint64_t n64;                          \
+        uint32_t n32;                          \
+    }
+#else
+/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
+#define __DECL_REG(n64, n32) uint64_t n64
+#endif
 
-    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked (see below) */
+struct vcpu_guest_core_regs
+{
+    /*         Aarch64       Aarch32 */
+    __DECL_REG(x0,           r0_usr);
+    __DECL_REG(x1,           r1_usr);
+    __DECL_REG(x2,           r2_usr);
+    __DECL_REG(x3,           r3_usr);
+    __DECL_REG(x4,           r4_usr);
+    __DECL_REG(x5,           r5_usr);
+    __DECL_REG(x6,           r6_usr);
+    __DECL_REG(x7,           r7_usr);
+    __DECL_REG(x8,           r8_usr);
+    __DECL_REG(x9,           r9_usr);
+    __DECL_REG(x10,          r10_usr);
+    __DECL_REG(x11,          r11_usr);
+    __DECL_REG(x12,          r12_usr);
+
+    __DECL_REG(x13,          sp_usr);
+    __DECL_REG(x14,          lr_usr);
+
+    __DECL_REG(x15,          __unused_sp_hyp);
+
+    __DECL_REG(x16,          lr_irq);
+    __DECL_REG(x17,          sp_irq);
+
+    __DECL_REG(x18,          lr_svc);
+    __DECL_REG(x19,          sp_svc);
+
+    __DECL_REG(x20,          lr_abt);
+    __DECL_REG(x21,          sp_abt);
+
+    __DECL_REG(x22,          lr_und);
+    __DECL_REG(x23,          sp_und);
+
+    __DECL_REG(x24,          r8_fiq);
+    __DECL_REG(x25,          r9_fiq);
+    __DECL_REG(x26,          r10_fiq);
+    __DECL_REG(x27,          r11_fiq);
+    __DECL_REG(x28,          r12_fiq);
+
+    __DECL_REG(x29,          sp_fiq);
+    __DECL_REG(x30,          lr_fiq);
+
+    /* Return address and mode */
+    __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
+    uint32_t cpsr;                              /* SPSR_EL2 */
 
-    /* r14 - LR: is the same physical register as LR_usr */
     union {
-        uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as lr_usr. */
-        uint32_t lr_usr;
+        uint32_t spsr_el1;       /* AArch64 */
+        uint32_t spsr_svc;       /* AArch32 */
     };
 
-    uint32_t pc; /* Return IP */
-    uint32_t cpsr; /* Return mode */
-    uint32_t pad0; /* Doubleword-align the kernel half of the frame */
-
-    /* Outer guest frame only from here on... */
+    /* AArch32 guests only */
+    uint32_t spsr_fiq, spsr_irq, spsr_und, spsr_abt;
 
-    uint32_t sp_usr; /* LR_usr is the same register as LR, see above */
-
-    uint32_t sp_irq, lr_irq;
-    uint32_t sp_svc, lr_svc;
-    uint32_t sp_abt, lr_abt;
-    uint32_t sp_und, lr_und;
-
-    uint32_t r8_fiq, r9_fiq, r10_fiq, r11_fiq, r12_fiq;
-    uint32_t sp_fiq, lr_fiq;
-
-    uint32_t spsr_svc, spsr_abt, spsr_und, spsr_irq, spsr_fiq;
-
-    uint32_t pad1; /* Doubleword-align the user half of the frame */
+    /* AArch64 guests only */
+    uint64_t sp_el0;
+    uint64_t sp_el1, elr_el1;
 };
-typedef struct cpu_user_regs cpu_user_regs_t;
-DEFINE_XEN_GUEST_HANDLE(cpu_user_regs_t);
+typedef struct vcpu_guest_core_regs vcpu_guest_core_regs_t;
+DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
+
+#undef __DECL_REG
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
@@ -151,10 +176,10 @@ struct vcpu_guest_context {
 #define VGCF_online                    (1<<_VGCF_online)
     uint32_t flags;                         /* VGCF_* */
 
-    struct cpu_user_regs user_regs;         /* User-level CPU registers     */
+    struct vcpu_guest_core_regs user_regs;  /* Core CPU registers */
 
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
-- 
1.7.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 Feb 22 09:03:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXH-0001ND-Ra; Fri, 22 Feb 2013 09:03: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 1U8oXG-0001KU-CJ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:18 +0000
Received: from [85.158.139.211:50293] by server-6.bemta-5.messagelabs.com id
	C9/B0-01489-55437215; Fri, 22 Feb 2013 09:03:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4367 invoked from network); 22 Feb 2013 09:03:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956602"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:00 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-2M;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:19 +0000
Message-ID: <1361523505-7604-40-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 40/46] xen: arm: implement do_multicall_call
	for both 32 and 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Obviously nothing is actually making multicalls even on 32-bit so
this isn't tested.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   22 ++++++++++++++++++++++
 xen/include/asm-arm/multicall.h |   11 +----------
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f24920..836762e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -675,6 +675,28 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 #endif
 }
 
+void do_multicall_call(struct multicall_entry *multi)
+{
+    arm_hypercall_fn_t call = NULL;
+
+    if ( multi->op >= ARRAY_SIZE(arm_hypercall_table) )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    call = arm_hypercall_table[multi->op].fn;
+    if ( call == NULL )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    multi->result = call(multi->args[0], multi->args[1],
+                        multi->args[2], multi->args[3],
+                        multi->args[4]);
+}
+
 static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
index 1713ded..b959262 100644
--- a/xen/include/asm-arm/multicall.h
+++ b/xen/include/asm-arm/multicall.h
@@ -1,16 +1,7 @@
 #ifndef __ASM_ARM_MULTICALL_H__
 #define __ASM_ARM_MULTICALL_H__
 
-#define do_multicall_call(_call)                             \
-    do {                                                     \
-        __asm__ __volatile__ (                               \
-            ".word 0xe7f000f0@; do_multicall_call\n"         \
-            "    mov r0,#0; @ do_multicall_call\n"           \
-            "    str r0, [r0];\n"                            \
-            :                                                \
-            :                                                \
-            : );                                             \
-    } while ( 0 )
+extern void do_multicall_call(struct multicall_entry *call);
 
 #endif /* __ASM_ARM_MULTICALL_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 Fri Feb 22 09:03:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXH-0001ND-Ra; Fri, 22 Feb 2013 09:03: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 1U8oXG-0001KU-CJ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:18 +0000
Received: from [85.158.139.211:50293] by server-6.bemta-5.messagelabs.com id
	C9/B0-01489-55437215; Fri, 22 Feb 2013 09:03:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4367 invoked from network); 22 Feb 2013 09:03:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956602"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:00 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-2M;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:19 +0000
Message-ID: <1361523505-7604-40-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 40/46] xen: arm: implement do_multicall_call
	for both 32 and 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Obviously nothing is actually making multicalls even on 32-bit so
this isn't tested.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c            |   22 ++++++++++++++++++++++
 xen/include/asm-arm/multicall.h |   11 +----------
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f24920..836762e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -675,6 +675,28 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss)
 #endif
 }
 
+void do_multicall_call(struct multicall_entry *multi)
+{
+    arm_hypercall_fn_t call = NULL;
+
+    if ( multi->op >= ARRAY_SIZE(arm_hypercall_table) )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    call = arm_hypercall_table[multi->op].fn;
+    if ( call == NULL )
+    {
+        multi->result = -ENOSYS;
+        return;
+    }
+
+    multi->result = call(multi->args[0], multi->args[1],
+                        multi->args[2], multi->args[3],
+                        multi->args[4]);
+}
+
 static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
diff --git a/xen/include/asm-arm/multicall.h b/xen/include/asm-arm/multicall.h
index 1713ded..b959262 100644
--- a/xen/include/asm-arm/multicall.h
+++ b/xen/include/asm-arm/multicall.h
@@ -1,16 +1,7 @@
 #ifndef __ASM_ARM_MULTICALL_H__
 #define __ASM_ARM_MULTICALL_H__
 
-#define do_multicall_call(_call)                             \
-    do {                                                     \
-        __asm__ __volatile__ (                               \
-            ".word 0xe7f000f0@; do_multicall_call\n"         \
-            "    mov r0,#0; @ do_multicall_call\n"           \
-            "    str r0, [r0];\n"                            \
-            :                                                \
-            :                                                \
-            : );                                             \
-    } while ( 0 )
+extern void do_multicall_call(struct multicall_entry *call);
 
 #endif /* __ASM_ARM_MULTICALL_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 Fri Feb 22 09:03:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXI-0001O9-LN; Fri, 22 Feb 2013 09:03:20 +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 1U8oXH-0001Ly-9V
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:19 +0000
Received: from [85.158.139.211:47098] by server-13.bemta-5.messagelabs.com id
	E2/21-06769-65437215; Fri, 22 Feb 2013 09:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1406 invoked from network); 22 Feb 2013 09:02:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956563"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:43 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-2h;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:20 +0000
Message-ID: <1361523505-7604-41-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 41/46] xen: arm: Enable VFP is a nop on
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/vfp.h |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/vfp.h b/xen/include/asm-arm/vfp.h
index 9477916..b800816 100644
--- a/xen/include/asm-arm/vfp.h
+++ b/xen/include/asm-arm/vfp.h
@@ -3,6 +3,9 @@
 
 #include <xen/types.h>
 
+
+#ifdef CONFIG_ARM_32
+
 #define FPEXC_EN (1u << 30)
 
 /* Save and restore FP state.
@@ -17,12 +20,17 @@
     asm volatile ("fmxr fp" #reg ", %0" : : "r" (val)); \
 } while (0)
 
-
 /* Start-of-day: Turn on VFP */
 static inline void enable_vfp(void)
 {
     WRITE_FP(exc, READ_FP(exc) | FPEXC_EN);
 }
+#else
+static inline void enable_vfp(void)
+{
+    /* Always enable on 64-bit */
+}
+#endif
 
 #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 Feb 22 09:03:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXI-0001O9-LN; Fri, 22 Feb 2013 09:03:20 +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 1U8oXH-0001Ly-9V
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:19 +0000
Received: from [85.158.139.211:47098] by server-13.bemta-5.messagelabs.com id
	E2/21-06769-65437215; Fri, 22 Feb 2013 09:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1406 invoked from network); 22 Feb 2013 09:02:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956563"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:43 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-2h;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:20 +0000
Message-ID: <1361523505-7604-41-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 41/46] xen: arm: Enable VFP is a nop on
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/vfp.h |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/vfp.h b/xen/include/asm-arm/vfp.h
index 9477916..b800816 100644
--- a/xen/include/asm-arm/vfp.h
+++ b/xen/include/asm-arm/vfp.h
@@ -3,6 +3,9 @@
 
 #include <xen/types.h>
 
+
+#ifdef CONFIG_ARM_32
+
 #define FPEXC_EN (1u << 30)
 
 /* Save and restore FP state.
@@ -17,12 +20,17 @@
     asm volatile ("fmxr fp" #reg ", %0" : : "r" (val)); \
 } while (0)
 
-
 /* Start-of-day: Turn on VFP */
 static inline void enable_vfp(void)
 {
     WRITE_FP(exc, READ_FP(exc) | FPEXC_EN);
 }
+#else
+static inline void enable_vfp(void)
+{
+    /* Always enable on 64-bit */
+}
+#endif
 
 #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 Feb 22 09:03:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXI-0001Nd-7c; Fri, 22 Feb 2013 09:03: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 1U8oXG-0001LC-I8
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:18 +0000
Received: from [85.158.138.51:27674] by server-7.bemta-3.messagelabs.com id
	6D/43-10367-55437215; Fri, 22 Feb 2013 09:03:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4700 invoked from network); 22 Feb 2013 09:03:16 -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;
	22 Feb 2013 09:03:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518856"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:14 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-U4;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:13 +0000
Message-ID: <1361523505-7604-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 34/46] xen: arm: time: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c          |   48 +++++++++++++++++++++--------------------
 xen/include/asm-arm/cpregs.h |   12 ++++++++++
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index e48305f..c53d79e 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -76,9 +76,9 @@ static uint32_t calibrate_timer(void)
     sec = rtc[0] + 1;
     do {} while ( rtc[0] != sec );
     // Now time a few seconds
-    start = READ_CP64(CNTPCT);
+    start = READ_SYSREG64(CNTPCT_EL0);
     do {} while ( rtc[0] < sec + 32 );
-    end = READ_CP64(CNTPCT);
+    end = READ_SYSREG64(CNTPCT_EL0);
     printk("done.\n");
 
     clear_fixmap(FIXMAP_MISC);
@@ -90,11 +90,13 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
+#if defined(CONFIG_ARM_32)
     if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
         panic("CPU does not support the Generic Timer v1 interface.\n");
+#endif
 
-    cpu_khz = READ_CP32(CNTFRQ) / 1000;
-    boot_count = READ_CP64(CNTPCT);
+    cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+    boot_count = READ_SYSREG64(CNTPCT_EL0);
     printk("Using generic timer at %lu KHz\n", cpu_khz);
 
     return 0;
@@ -103,7 +105,7 @@ int __init init_xen_time(void)
 /* Return number of nanoseconds since boot */
 s_time_t get_s_time(void)
 {
-    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    uint64_t ticks = READ_SYSREG64(CNTPCT_EL0) - boot_count;
     return ticks_to_ns(ticks);
 }
 
@@ -117,20 +119,20 @@ int reprogram_timer(s_time_t timeout)
     if ( timeout == 0 )
     {
 #if USE_HYP_TIMER
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
 #else
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
 #endif
         return 1;
     }
 
     deadline = ns_to_ticks(timeout) + boot_count;
 #if USE_HYP_TIMER
-    WRITE_CP64(deadline, CNTHP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+    WRITE_SYSREG64(deadline, CNTHP_CVAL_EL2);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTHP_CTL_EL2);
 #else
-    WRITE_CP64(deadline, CNTP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+    WRITE_SYSREG64(deadline, CNTP_CVAL_EL0);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTP_CTL_EL0);
 #endif
     isb();
 
@@ -142,27 +144,27 @@ int reprogram_timer(s_time_t timeout)
 /* Handle the firing timer */
 static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    if ( irq == 26 && READ_SYSREG32(CNTHP_CTL_EL2) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
     }
 
-    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    if (irq == 30 && READ_SYSREG32(CNTP_CTL_EL0) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
     }
 }
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
+    current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, irq, 1);
 }
 
@@ -170,17 +172,17 @@ static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 void __cpuinit init_timer_interrupt(void)
 {
     /* Sensible defaults */
-    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
-    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+    WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
+    WRITE_SYSREG32(0, CNTKCTL_EL1);     /* No user-mode access */
 #if USE_HYP_TIMER
     /* Do not let the VMs program the physical timer, only read the physical counter */
-    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
+    WRITE_SYSREG32(CNTHCTL_PA, CNTHCTL_EL2);
 #else
     /* Cannot let VMs access physical counter if we are using it */
-    WRITE_CP32(0, CNTHCTL);
+    WRITE_SYSREG32(0, CNTHCTL_EL2);
 #endif
-    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
-    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    WRITE_SYSREG32(0, CNTP_CTL_EL0);    /* Physical timer disabled */
+    WRITE_SYSREG32(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
     isb();
 
     /* XXX Need to find this IRQ number from devicetree? */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 8a66719..35c0ee6 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -230,6 +230,18 @@
 #define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CNTFRQ_EL0              CNTFRQ
+#define CNTHCTL_EL2             CNTHCTL
+#define CNTHP_CTL_EL2           CNTHP_CTL
+#define CNTHP_CVAL_EL2          CNTHP_CVAL
+#define CNTKCTL_EL1             CNTKCTL
+#define CNTPCT_EL0              CNTPCT
+#define CNTP_CTL_EL0            CNTP_CTL
+#define CNTP_CVAL_EL0           CNTP_CVAL
+#define CNTVCT_EL0              CNTVCT
+#define CNTVOFF_EL2             CNTVOFF
+#define CNTV_CTL_EL0            CNTV_CTL
+#define CNTV_CVAL_EL0           CNTV_CVAL
 #define CONTEXTIDR_EL1          CONTEXTIDR
 #define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
-- 
1.7.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 Feb 22 09:03:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXI-0001Nd-7c; Fri, 22 Feb 2013 09:03: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 1U8oXG-0001LC-I8
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:18 +0000
Received: from [85.158.138.51:27674] by server-7.bemta-3.messagelabs.com id
	6D/43-10367-55437215; Fri, 22 Feb 2013 09:03:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4700 invoked from network); 22 Feb 2013 09:03:16 -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;
	22 Feb 2013 09:03:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518856"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:14 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-U4;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:13 +0000
Message-ID: <1361523505-7604-34-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 34/46] xen: arm: time: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/time.c          |   48 +++++++++++++++++++++--------------------
 xen/include/asm-arm/cpregs.h |   12 ++++++++++
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index e48305f..c53d79e 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -76,9 +76,9 @@ static uint32_t calibrate_timer(void)
     sec = rtc[0] + 1;
     do {} while ( rtc[0] != sec );
     // Now time a few seconds
-    start = READ_CP64(CNTPCT);
+    start = READ_SYSREG64(CNTPCT_EL0);
     do {} while ( rtc[0] < sec + 32 );
-    end = READ_CP64(CNTPCT);
+    end = READ_SYSREG64(CNTPCT_EL0);
     printk("done.\n");
 
     clear_fixmap(FIXMAP_MISC);
@@ -90,11 +90,13 @@ static uint32_t calibrate_timer(void)
 int __init init_xen_time(void)
 {
     /* Check that this CPU supports the Generic Timer interface */
+#if defined(CONFIG_ARM_32)
     if ( (READ_CP32(ID_PFR1) & ID_PFR1_GT_MASK) != ID_PFR1_GT_v1 )
         panic("CPU does not support the Generic Timer v1 interface.\n");
+#endif
 
-    cpu_khz = READ_CP32(CNTFRQ) / 1000;
-    boot_count = READ_CP64(CNTPCT);
+    cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+    boot_count = READ_SYSREG64(CNTPCT_EL0);
     printk("Using generic timer at %lu KHz\n", cpu_khz);
 
     return 0;
@@ -103,7 +105,7 @@ int __init init_xen_time(void)
 /* Return number of nanoseconds since boot */
 s_time_t get_s_time(void)
 {
-    uint64_t ticks = READ_CP64(CNTPCT) - boot_count;
+    uint64_t ticks = READ_SYSREG64(CNTPCT_EL0) - boot_count;
     return ticks_to_ns(ticks);
 }
 
@@ -117,20 +119,20 @@ int reprogram_timer(s_time_t timeout)
     if ( timeout == 0 )
     {
 #if USE_HYP_TIMER
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
 #else
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
 #endif
         return 1;
     }
 
     deadline = ns_to_ticks(timeout) + boot_count;
 #if USE_HYP_TIMER
-    WRITE_CP64(deadline, CNTHP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTHP_CTL);
+    WRITE_SYSREG64(deadline, CNTHP_CVAL_EL2);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTHP_CTL_EL2);
 #else
-    WRITE_CP64(deadline, CNTP_CVAL);
-    WRITE_CP32(CNTx_CTL_ENABLE, CNTP_CTL);
+    WRITE_SYSREG64(deadline, CNTP_CVAL_EL0);
+    WRITE_SYSREG32(CNTx_CTL_ENABLE, CNTP_CTL_EL0);
 #endif
     isb();
 
@@ -142,27 +144,27 @@ int reprogram_timer(s_time_t timeout)
 /* Handle the firing timer */
 static void timer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    if ( irq == 26 && READ_CP32(CNTHP_CTL) & CNTx_CTL_PENDING )
+    if ( irq == 26 && READ_SYSREG32(CNTHP_CTL_EL2) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTHP_CTL);
+        WRITE_SYSREG32(0, CNTHP_CTL_EL2);
     }
 
-    if (irq == 30 && READ_CP32(CNTP_CTL) & CNTx_CTL_PENDING )
+    if (irq == 30 && READ_SYSREG32(CNTP_CTL_EL0) & CNTx_CTL_PENDING )
     {
         /* Signal the generic timer code to do its work */
         raise_softirq(TIMER_SOFTIRQ);
         /* Disable the timer to avoid more interrupts */
-        WRITE_CP32(0, CNTP_CTL);
+        WRITE_SYSREG32(0, CNTP_CTL_EL0);
     }
 }
 
 static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 {
-    current->arch.virt_timer.ctl = READ_CP32(CNTV_CTL);
-    WRITE_CP32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL);
+    current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
+    WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
     vgic_vcpu_inject_irq(current, irq, 1);
 }
 
@@ -170,17 +172,17 @@ static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
 void __cpuinit init_timer_interrupt(void)
 {
     /* Sensible defaults */
-    WRITE_CP64(0, CNTVOFF);     /* No VM-specific offset */
-    WRITE_CP32(0, CNTKCTL);     /* No user-mode access */
+    WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
+    WRITE_SYSREG32(0, CNTKCTL_EL1);     /* No user-mode access */
 #if USE_HYP_TIMER
     /* Do not let the VMs program the physical timer, only read the physical counter */
-    WRITE_CP32(CNTHCTL_PA, CNTHCTL);
+    WRITE_SYSREG32(CNTHCTL_PA, CNTHCTL_EL2);
 #else
     /* Cannot let VMs access physical counter if we are using it */
-    WRITE_CP32(0, CNTHCTL);
+    WRITE_SYSREG32(0, CNTHCTL_EL2);
 #endif
-    WRITE_CP32(0, CNTP_CTL);    /* Physical timer disabled */
-    WRITE_CP32(0, CNTHP_CTL);   /* Hypervisor's timer disabled */
+    WRITE_SYSREG32(0, CNTP_CTL_EL0);    /* Physical timer disabled */
+    WRITE_SYSREG32(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
     isb();
 
     /* XXX Need to find this IRQ number from devicetree? */
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 8a66719..35c0ee6 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -230,6 +230,18 @@
 #define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CNTFRQ_EL0              CNTFRQ
+#define CNTHCTL_EL2             CNTHCTL
+#define CNTHP_CTL_EL2           CNTHP_CTL
+#define CNTHP_CVAL_EL2          CNTHP_CVAL
+#define CNTKCTL_EL1             CNTKCTL
+#define CNTPCT_EL0              CNTPCT
+#define CNTP_CTL_EL0            CNTP_CTL
+#define CNTP_CVAL_EL0           CNTP_CVAL
+#define CNTVCT_EL0              CNTVCT
+#define CNTVOFF_EL2             CNTVOFF
+#define CNTV_CTL_EL0            CNTV_CTL
+#define CNTV_CVAL_EL0           CNTV_CVAL
 #define CONTEXTIDR_EL1          CONTEXTIDR
 #define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
-- 
1.7.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 Feb 22 09:03:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXK-0001Rl-Su; Fri, 22 Feb 2013 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 1U8oXJ-0001P0-N1
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:21 +0000
Received: from [85.158.138.51:45962] by server-10.bemta-3.messagelabs.com id
	DA/CA-10609-85437215; Fri, 22 Feb 2013 09:03:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4917 invoked from network); 22 Feb 2013 09:03:20 -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;
	22 Feb 2013 09:03:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518869"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:19 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-8D;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:50 +0000
Message-ID: <1361523505-7604-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 11/46] xen: arm64: PTE 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/page.h |   20 ++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   15 +++++++++++++++
 xen/include/asm-arm/page.h       |   20 --------------------
 3 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 073b8d1..a384f04 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -3,6 +3,26 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry.
+ *
+ * If the table entry is changing a text mapping, it is responsibility
+ * of the caller to issue an ISB after write_pte.
+ */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb;"
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        "dsb;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 636fb63..99b7296 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -3,6 +3,21 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb sy;"
+        "str %0, [%1];"         /* Write the entry */
+        "dsb sy;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        "dc cvac, %1;"
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb sy;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 8909375..476b00c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -230,26 +230,6 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
     return e;
 }
 
-/* Write a pagetable entry.
- *
- * If the table entry is changing a text mapping, it is responsibility
- * of the caller to issue an ISB after write_pte.
- */
-static inline void write_pte(lpae_t *p, lpae_t pte)
-{
-    asm volatile (
-        /* Ensure any writes have completed with the old mappings. */
-        "dsb;"
-        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
-        "strd %0, %H0, [%1];"
-        "dsb;"
-        /* Push this cacheline to the PoC so the rest of the system sees it. */
-        STORE_CP32(1, DCCMVAC)
-        /* Ensure that the data flush is completed before proceeding */
-        "dsb;"
-        : : "r" (pte.bits), "r" (p) : "memory");
-}
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/page.h>
 #elif defined(CONFIG_ARM_64)
-- 
1.7.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 Feb 22 09:03:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXK-0001Rl-Su; Fri, 22 Feb 2013 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 1U8oXJ-0001P0-N1
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:21 +0000
Received: from [85.158.138.51:45962] by server-10.bemta-3.messagelabs.com id
	DA/CA-10609-85437215; Fri, 22 Feb 2013 09:03:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4917 invoked from network); 22 Feb 2013 09:03:20 -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;
	22 Feb 2013 09:03:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518869"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:19 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-8D;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:50 +0000
Message-ID: <1361523505-7604-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 11/46] xen: arm64: PTE 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/page.h |   20 ++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   15 +++++++++++++++
 xen/include/asm-arm/page.h       |   20 --------------------
 3 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 073b8d1..a384f04 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -3,6 +3,26 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry.
+ *
+ * If the table entry is changing a text mapping, it is responsibility
+ * of the caller to issue an ISB after write_pte.
+ */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb;"
+        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
+        "strd %0, %H0, [%1];"
+        "dsb;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        STORE_CP32(1, DCCMVAC)
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 636fb63..99b7296 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -3,6 +3,21 @@
 
 #ifndef __ASSEMBLY__
 
+/* Write a pagetable entry */
+static inline void write_pte(lpae_t *p, lpae_t pte)
+{
+    asm volatile (
+        /* Ensure any writes have completed with the old mappings. */
+        "dsb sy;"
+        "str %0, [%1];"         /* Write the entry */
+        "dsb sy;"
+        /* Push this cacheline to the PoC so the rest of the system sees it. */
+        "dc cvac, %1;"
+        /* Ensure that the data flush is completed before proceeding */
+        "dsb sy;"
+        : : "r" (pte.bits), "r" (p) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 8909375..476b00c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -230,26 +230,6 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
     return e;
 }
 
-/* Write a pagetable entry.
- *
- * If the table entry is changing a text mapping, it is responsibility
- * of the caller to issue an ISB after write_pte.
- */
-static inline void write_pte(lpae_t *p, lpae_t pte)
-{
-    asm volatile (
-        /* Ensure any writes have completed with the old mappings. */
-        "dsb;"
-        /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
-        "strd %0, %H0, [%1];"
-        "dsb;"
-        /* Push this cacheline to the PoC so the rest of the system sees it. */
-        STORE_CP32(1, DCCMVAC)
-        /* Ensure that the data flush is completed before proceeding */
-        "dsb;"
-        : : "r" (pte.bits), "r" (p) : "memory");
-}
-
 #if defined(CONFIG_ARM_32)
 # include <asm/arm32/page.h>
 #elif defined(CONFIG_ARM_64)
-- 
1.7.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 Feb 22 09:03:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXK-0001QI-3l; Fri, 22 Feb 2013 09:03:22 +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 1U8oXI-0001NQ-FT
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:20 +0000
Received: from [85.158.139.211:60851] by server-2.bemta-5.messagelabs.com id
	81/98-16911-75437215; Fri, 22 Feb 2013 09:03:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 987 invoked from network); 22 Feb 2013 09:02:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956524"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:39 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-ET;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:56 +0000
Message-ID: <1361523505-7604-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 17/46] xen: arm64: div64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/div64.h |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
index f2574e5..1cd58bc 100644
--- a/xen/include/asm-arm/div64.h
+++ b/xen/include/asm-arm/div64.h
@@ -21,6 +21,19 @@
  * calling convention for arguments and results (beware).
  */
 
+
+#if BITS_PER_LONG == 64
+
+# define do_div(n,base) ({                                      \
+        uint32_t __base = (base);                               \
+        uint32_t __rem;                                         \
+        __rem = ((uint64_t)(n)) % __base;                       \
+        (n) = ((uint64_t)(n)) / __base;                         \
+        __rem;                                                  \
+ })
+
+#elif BITS_PER_LONG == 32
+
 #ifdef __ARMEB__
 #define __xh "r0"
 #define __xl "r1"
@@ -222,7 +235,9 @@
 	__nr;								\
 })
 
-#endif
+#endif /* GCC version */
+
+#endif /* BITS_PER_LONG */
 
 #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 Feb 22 09:03:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXK-0001QI-3l; Fri, 22 Feb 2013 09:03:22 +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 1U8oXI-0001NQ-FT
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:20 +0000
Received: from [85.158.139.211:60851] by server-2.bemta-5.messagelabs.com id
	81/98-16911-75437215; Fri, 22 Feb 2013 09:03:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 987 invoked from network); 22 Feb 2013 09:02:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956524"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:39 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-ET;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:56 +0000
Message-ID: <1361523505-7604-17-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 17/46] xen: arm64: div64
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/div64.h |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/xen/include/asm-arm/div64.h b/xen/include/asm-arm/div64.h
index f2574e5..1cd58bc 100644
--- a/xen/include/asm-arm/div64.h
+++ b/xen/include/asm-arm/div64.h
@@ -21,6 +21,19 @@
  * calling convention for arguments and results (beware).
  */
 
+
+#if BITS_PER_LONG == 64
+
+# define do_div(n,base) ({                                      \
+        uint32_t __base = (base);                               \
+        uint32_t __rem;                                         \
+        __rem = ((uint64_t)(n)) % __base;                       \
+        (n) = ((uint64_t)(n)) / __base;                         \
+        __rem;                                                  \
+ })
+
+#elif BITS_PER_LONG == 32
+
 #ifdef __ARMEB__
 #define __xh "r0"
 #define __xl "r1"
@@ -222,7 +235,9 @@
 	__nr;								\
 })
 
-#endif
+#endif /* GCC version */
+
+#endif /* BITS_PER_LONG */
 
 #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 Feb 22 09:03:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXM-0001UX-Hz; Fri, 22 Feb 2013 09:03: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 1U8oXK-0001Qf-M4
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:22 +0000
Received: from [85.158.139.211:61104] by server-11.bemta-5.messagelabs.com id
	D3/FC-19159-95437215; Fri, 22 Feb 2013 09:03:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4654 invoked from network); 22 Feb 2013 09:03:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956616"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:02 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Br;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:52 +0000
Message-ID: <1361523505-7604-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 13/46] xen: arm64: address translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
I'm torn between unsigned long and vaddr_t...
---
 xen/include/asm-arm/arm32/page.h |   34 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   35 +++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/page.h       |   38 ++------------------------------------
 xen/include/asm-arm/types.h      |    4 ++++
 4 files changed, 75 insertions(+), 36 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 2b15c22..d295316 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -77,6 +77,40 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM32_PAGE_H__ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 4911ba3..9bf41fb 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -70,6 +70,41 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e2r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s12e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM64_PAGE_H__ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 012ec38..100666b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -278,19 +278,7 @@ extern void dump_hyp_walk(uint32_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
-/* Ask the MMU to translate a VA for us */
-static inline uint64_t __va_to_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1HR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline uint64_t va_to_par(uint32_t va)
+static inline uint64_t va_to_par(vaddr_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
@@ -302,29 +290,7 @@ static inline uint64_t va_to_par(uint32_t va)
     return par;
 }
 
-/* Ask the MMU to translate a Guest VA for us */
-static inline uint64_t gva_to_ma_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS12NSOPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-static inline uint64_t gva_to_ipa_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1CPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline int gva_to_ipa(uint32_t va, paddr_t *paddr)
+static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 {
     uint64_t par = gva_to_ipa_par(va);
     if ( par & PAR_F )
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 3f6317b..9c20fea 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -36,12 +36,16 @@ typedef unsigned int u32;
 #if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
+typedef u32 vaddr_t;
+#define PRIvaddr PRIx32
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
+typedef u64 vaddr_t;
+#define PRIvaddr PRIx64
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
-- 
1.7.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 Feb 22 09:03:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXM-0001UX-Hz; Fri, 22 Feb 2013 09:03: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 1U8oXK-0001Qf-M4
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:22 +0000
Received: from [85.158.139.211:61104] by server-11.bemta-5.messagelabs.com id
	D3/FC-19159-95437215; Fri, 22 Feb 2013 09:03:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4654 invoked from network); 22 Feb 2013 09:03:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956616"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:02 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Br;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:52 +0000
Message-ID: <1361523505-7604-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 13/46] xen: arm64: address translation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
I'm torn between unsigned long and vaddr_t...
---
 xen/include/asm-arm/arm32/page.h |   34 ++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/page.h |   35 +++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/page.h       |   38 ++------------------------------------
 xen/include/asm-arm/types.h      |    4 ++++
 4 files changed, 75 insertions(+), 36 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index 2b15c22..d295316 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -77,6 +77,40 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1HR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS12NSOPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp;
+    tmp = READ_CP64(PAR);
+    WRITE_CP32(va, ATS1CPR);
+    isb(); /* Ensure result is available. */
+    par = READ_CP64(PAR);
+    WRITE_CP64(tmp, PAR);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM32_PAGE_H__ */
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 4911ba3..9bf41fb 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -70,6 +70,41 @@ static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long s
     isb();
 }
 
+/* Ask the MMU to translate a VA for us */
+static inline uint64_t __va_to_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e2r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+/* Ask the MMU to translate a Guest VA for us */
+static inline uint64_t gva_to_ma_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s12e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
+static inline uint64_t gva_to_ipa_par(vaddr_t va)
+{
+    uint64_t par, tmp = READ_SYSREG64(PAR_EL1);
+
+    asm volatile ("at s1e1r, %0;" : : "r" (va));
+    isb();
+    par = READ_SYSREG64(PAR_EL1);
+    WRITE_SYSREG64(tmp, PAR_EL1);
+    return par;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ARM_ARM64_PAGE_H__ */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 012ec38..100666b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -278,19 +278,7 @@ extern void dump_hyp_walk(uint32_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
-/* Ask the MMU to translate a VA for us */
-static inline uint64_t __va_to_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1HR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline uint64_t va_to_par(uint32_t va)
+static inline uint64_t va_to_par(vaddr_t va)
 {
     uint64_t par = __va_to_par(va);
     /* It is not OK to call this with an invalid VA */
@@ -302,29 +290,7 @@ static inline uint64_t va_to_par(uint32_t va)
     return par;
 }
 
-/* Ask the MMU to translate a Guest VA for us */
-static inline uint64_t gva_to_ma_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS12NSOPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-static inline uint64_t gva_to_ipa_par(uint32_t va)
-{
-    uint64_t par, tmp;
-    tmp = READ_CP64(PAR);
-    WRITE_CP32(va, ATS1CPR);
-    isb(); /* Ensure result is available. */
-    par = READ_CP64(PAR);
-    WRITE_CP64(tmp, PAR);
-    return par;
-}
-
-static inline int gva_to_ipa(uint32_t va, paddr_t *paddr)
+static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 {
     uint64_t par = gva_to_ipa_par(va);
     if ( par & PAR_F )
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 3f6317b..9c20fea 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -36,12 +36,16 @@ typedef unsigned int u32;
 #if defined(CONFIG_ARM_32)
 typedef signed long long s64;
 typedef unsigned long long u64;
+typedef u32 vaddr_t;
+#define PRIvaddr PRIx32
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
+typedef u64 vaddr_t;
+#define PRIvaddr PRIx64
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
-- 
1.7.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 Feb 22 09:03:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXN-0001X1-Ug; Fri, 22 Feb 2013 09:03: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 1U8oXK-0001Qa-LY
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:22 +0000
Received: from [85.158.139.211:50761] by server-16.bemta-5.messagelabs.com id
	02/C4-14948-95437215; Fri, 22 Feb 2013 09:03:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5446 invoked from network); 22 Feb 2013 09:03:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956626"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:07 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-E7;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:55 +0000
Message-ID: <1361523505-7604-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 16/46] xen: arm64: interrupt/abort mask/unmask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |   44 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   54 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   44 -----------------------------
 3 files changed, 98 insertions(+), 44 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 276e363..f28879d 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -133,6 +133,50 @@ static always_inline unsigned long __cmpxchg(
     ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
                                    (unsigned long)(n),sizeof(*(ptr))))
 
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 8692a5d..daa221e 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -173,6 +173,60 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
                                        (unsigned long)(n),              \
                                        sizeof(*(ptr))))
 
+/* Uses uimm4 as a bitmask to select the clearing of one or more of
+ * the DAIF exception mask bits:
+ * bit 3 selects the D mask,
+ * bit 2 the A mask,
+ * bit 1 the I mask and
+ * bit 0 the F mask.
+*/
+
+#define local_fiq_disable()   asm volatile ( "msr daifset, #1\n" ::: "memory" )
+#define local_fiq_enable()    asm volatile ( "msr daifclr, #1\n" ::: "memory" )
+#define local_irq_disable()   asm volatile ( "msr daifset, #2\n" ::: "memory" )
+#define local_irq_enable()    asm volatile ( "msr daifclr, #2\n" ::: "memory" )
+#define local_abort_disable() asm volatile ( "msr daifset, #4\n" ::: "memory" )
+#define local_abort_enable()  asm volatile ( "msr daifclr, #4\n" ::: "memory" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile(                                                \
+        "mrs    %0, daif    // local_save_flags\n"               \
+                : "=r" (x)                                       \
+                :                                                \
+                : "memory");                                     \
+})
+
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+        "msr    daif, %0                // local_irq_restore"    \
+        :                                                        \
+        : "r" (flags)                                            \
+        : "memory");                                             \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index f2a87d4..290d38d 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,50 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
-#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
-
-#define local_save_flags(x)                                      \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
-                  : "=r" (x) :: "memory", "cc" );                \
-})
-#define local_irq_save(x)                                        \
-({                                                               \
-    local_save_flags(x);                                         \
-    local_irq_disable();                                         \
-})
-#define local_irq_restore(x)                                     \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile (                                               \
-            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
-            :                                                    \
-            : "r" (flags)                                        \
-            : "memory", "cc");                                   \
-})
-
-static inline int local_irq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !(flags & PSR_IRQ_MASK);
-}
-
-#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
-#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
-
-#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
-#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
-
-static inline int local_fiq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !!(flags & PSR_FIQ_MASK);
-}
-
 extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
 
 #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 Feb 22 09:03:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXN-0001X1-Ug; Fri, 22 Feb 2013 09:03: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 1U8oXK-0001Qa-LY
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:22 +0000
Received: from [85.158.139.211:50761] by server-16.bemta-5.messagelabs.com id
	02/C4-14948-95437215; Fri, 22 Feb 2013 09:03:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5446 invoked from network); 22 Feb 2013 09:03:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956626"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:07 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-E7;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:55 +0000
Message-ID: <1361523505-7604-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 16/46] xen: arm64: interrupt/abort mask/unmask
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |   44 +++++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |   54 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |   44 -----------------------------
 3 files changed, 98 insertions(+), 44 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 276e363..f28879d 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -133,6 +133,50 @@ static always_inline unsigned long __cmpxchg(
     ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
                                    (unsigned long)(n),sizeof(*(ptr))))
 
+#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
+#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
+                  : "=r" (x) :: "memory", "cc" );                \
+})
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
+            :                                                    \
+            : "r" (flags)                                        \
+            : "memory", "cc");                                   \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
+#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
+
+#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
+#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 8692a5d..daa221e 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -173,6 +173,60 @@ static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
                                        (unsigned long)(n),              \
                                        sizeof(*(ptr))))
 
+/* Uses uimm4 as a bitmask to select the clearing of one or more of
+ * the DAIF exception mask bits:
+ * bit 3 selects the D mask,
+ * bit 2 the A mask,
+ * bit 1 the I mask and
+ * bit 0 the F mask.
+*/
+
+#define local_fiq_disable()   asm volatile ( "msr daifset, #1\n" ::: "memory" )
+#define local_fiq_enable()    asm volatile ( "msr daifclr, #1\n" ::: "memory" )
+#define local_irq_disable()   asm volatile ( "msr daifset, #2\n" ::: "memory" )
+#define local_irq_enable()    asm volatile ( "msr daifclr, #2\n" ::: "memory" )
+#define local_abort_disable() asm volatile ( "msr daifset, #4\n" ::: "memory" )
+#define local_abort_enable()  asm volatile ( "msr daifclr, #4\n" ::: "memory" )
+
+#define local_save_flags(x)                                      \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile(                                                \
+        "mrs    %0, daif    // local_save_flags\n"               \
+                : "=r" (x)                                       \
+                :                                                \
+                : "memory");                                     \
+})
+
+#define local_irq_save(x)                                        \
+({                                                               \
+    local_save_flags(x);                                         \
+    local_irq_disable();                                         \
+})
+#define local_irq_restore(x)                                     \
+({                                                               \
+    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
+    asm volatile (                                               \
+        "msr    daif, %0                // local_irq_restore"    \
+        :                                                        \
+        : "r" (flags)                                            \
+        : "memory");                                             \
+})
+
+static inline int local_irq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_IRQ_MASK);
+}
+
+static inline int local_fiq_is_enabled(void)
+{
+    unsigned long flags;
+    local_save_flags(flags);
+    return !(flags & PSR_FIQ_MASK);
+}
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index f2a87d4..290d38d 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,50 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-#define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
-#define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
-
-#define local_save_flags(x)                                      \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile ( "mrs %0, cpsr     @ local_save_flags\n"       \
-                  : "=r" (x) :: "memory", "cc" );                \
-})
-#define local_irq_save(x)                                        \
-({                                                               \
-    local_save_flags(x);                                         \
-    local_irq_disable();                                         \
-})
-#define local_irq_restore(x)                                     \
-({                                                               \
-    BUILD_BUG_ON(sizeof(x) != sizeof(long));                     \
-    asm volatile (                                               \
-            "msr     cpsr_c, %0      @ local_irq_restore\n"      \
-            :                                                    \
-            : "r" (flags)                                        \
-            : "memory", "cc");                                   \
-})
-
-static inline int local_irq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !(flags & PSR_IRQ_MASK);
-}
-
-#define local_fiq_enable()  __asm__("cpsie f   @ __stf\n" : : : "memory", "cc")
-#define local_fiq_disable() __asm__("cpsid f   @ __clf\n" : : : "memory", "cc")
-
-#define local_abort_enable() __asm__("cpsie a  @ __sta\n" : : : "memory", "cc")
-#define local_abort_disable() __asm__("cpsid a @ __sta\n" : : : "memory", "cc")
-
-static inline int local_fiq_is_enabled(void)
-{
-    unsigned long flags;
-    local_save_flags(flags);
-    return !!(flags & PSR_FIQ_MASK);
-}
-
 extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
 
 #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 Feb 22 09:03:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXO-0001Yt-Qh; Fri, 22 Feb 2013 09:03:26 +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 1U8oXM-0001Tx-Pk
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:25 +0000
Received: from [85.158.138.51:46373] by server-9.bemta-3.messagelabs.com id
	A9/31-09484-B5437215; Fri, 22 Feb 2013 09:03:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361523786!19979573!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16703 invoked from network); 22 Feb 2013 09:03:09 -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;
	22 Feb 2013 09:03:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518835"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:05 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-MQ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:05 +0000
Message-ID: <1361523505-7604-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 26/46] xen: arm: move arm32 specific trap
	handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm32/Makefile     |    3 +-
 xen/arch/arm/arm32/traps.c      |   53 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c            |   22 +---------------
 xen/include/asm-arm/processor.h |    2 +
 4 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 xen/arch/arm/arm32/traps.c

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 29898ae..1ad3364 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -4,4 +4,5 @@ obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
 
-obj-y += domain.o
+obj-y += traps.o
+obj-y += domain.o
\ No newline at end of file
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
new file mode 100644
index 0000000..a93c2f7
--- /dev/null
+++ b/xen/arch/arm/arm32/traps.c
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/arm32/traps.c
+ *
+ * ARM AArch32 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <public/xen.h>
+
+#include <asm/processor.h>
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 391cecc..f96365b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -423,33 +423,13 @@ void vcpu_show_execution_state(struct vcpu *v)
     vcpu_unpause(v);
 }
 
-static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
     show_execution_state(regs);
     while(1);
 }
 
-asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Undefined Instruction", regs);
-}
-
-asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Supervisor Call", regs);
-}
-
-asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Prefetch Abort", regs);
-}
-
-asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Data Abort", regs);
-}
-
 unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 {
         printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index f7aa9e2..63f03ac 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,8 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs);
+
 void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
                            struct vcpu_guest_core_regs *regs);
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
-- 
1.7.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 Feb 22 09:03:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXO-0001Yt-Qh; Fri, 22 Feb 2013 09:03:26 +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 1U8oXM-0001Tx-Pk
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:25 +0000
Received: from [85.158.138.51:46373] by server-9.bemta-3.messagelabs.com id
	A9/31-09484-B5437215; Fri, 22 Feb 2013 09:03:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361523786!19979573!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16703 invoked from network); 22 Feb 2013 09:03:09 -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;
	22 Feb 2013 09:03:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518835"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:05 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-MQ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:05 +0000
Message-ID: <1361523505-7604-26-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 26/46] xen: arm: move arm32 specific trap
	handlers to xen/arch/arm/arm32
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm32/Makefile     |    3 +-
 xen/arch/arm/arm32/traps.c      |   53 +++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/traps.c            |   22 +---------------
 xen/include/asm-arm/processor.h |    2 +
 4 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 xen/arch/arm/arm32/traps.c

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 29898ae..1ad3364 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -4,4 +4,5 @@ obj-y += entry.o
 obj-y += mode_switch.o
 obj-y += proc-ca15.o
 
-obj-y += domain.o
+obj-y += traps.o
+obj-y += domain.o
\ No newline at end of file
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
new file mode 100644
index 0000000..a93c2f7
--- /dev/null
+++ b/xen/arch/arm/arm32/traps.c
@@ -0,0 +1,53 @@
+/*
+ * xen/arch/arm/arm32/traps.c
+ *
+ * ARM AArch32 Specific Trap handlers
+ *
+ * Copyright (c) 2012 Citrix Systems.
+ *
+ * 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 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.
+ */
+
+#include <xen/config.h>
+#include <xen/lib.h>
+
+#include <public/xen.h>
+
+#include <asm/processor.h>
+
+asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Undefined Instruction", regs);
+}
+
+asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Supervisor Call", regs);
+}
+
+asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Prefetch Abort", regs);
+}
+
+asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
+{
+    do_unexpected_trap("Data Abort", regs);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 391cecc..f96365b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -423,33 +423,13 @@ void vcpu_show_execution_state(struct vcpu *v)
     vcpu_unpause(v);
 }
 
-static void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
 {
     printk("Unexpected Trap: %s\n", msg);
     show_execution_state(regs);
     while(1);
 }
 
-asmlinkage void do_trap_undefined_instruction(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Undefined Instruction", regs);
-}
-
-asmlinkage void do_trap_supervisor_call(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Supervisor Call", regs);
-}
-
-asmlinkage void do_trap_prefetch_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Prefetch Abort", regs);
-}
-
-asmlinkage void do_trap_data_abort(struct cpu_user_regs *regs)
-{
-    do_unexpected_trap("Data Abort", regs);
-}
-
 unsigned long do_arch_0(unsigned int cmd, unsigned long long value)
 {
         printk("do_arch_0 cmd=%x arg=%llx\n", cmd, value);
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index f7aa9e2..63f03ac 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -253,6 +253,8 @@ void show_registers(struct cpu_user_regs *regs);
 #define cpu_to_core(_cpu)   (0)
 #define cpu_to_socket(_cpu) (0)
 
+void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs);
+
 void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
                            struct vcpu_guest_core_regs *regs);
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
-- 
1.7.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 Feb 22 09:03:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXP-0001aO-DL; Fri, 22 Feb 2013 09:03: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 1U8oXO-0001Wj-8z
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:26 +0000
Received: from [85.158.138.51:32492] by server-16.bemta-3.messagelabs.com id
	95/43-02727-D5437215; Fri, 22 Feb 2013 09:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5239 invoked from network); 22 Feb 2013 09:03: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;
	22 Feb 2013 09:03:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518880"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:23 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Vd;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:14 +0000
Message-ID: <1361523505-7604-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 35/46] xen: arm: p2m: use 64-bit compatible
	registers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/p2m.c           |    2 +-
 xen/include/asm-arm/cpregs.h |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c4fc05e..1e8c8b4 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -29,7 +29,7 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    WRITE_CP64(vttbr, VTTBR);
+    WRITE_SYSREG64(vttbr, VTTBR_EL2);
     isb(); /* Ensure update is visible */
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 35c0ee6..ae89e40 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -277,6 +277,7 @@
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
+#define VTTBR_EL2               VTTBR
 
 #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 Feb 22 09:03:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXP-0001aO-DL; Fri, 22 Feb 2013 09:03: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 1U8oXO-0001Wj-8z
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:26 +0000
Received: from [85.158.138.51:32492] by server-16.bemta-3.messagelabs.com id
	95/43-02727-D5437215; Fri, 22 Feb 2013 09:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5239 invoked from network); 22 Feb 2013 09:03: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;
	22 Feb 2013 09:03:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518880"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:23 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Vd;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:14 +0000
Message-ID: <1361523505-7604-35-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 35/46] xen: arm: p2m: use 64-bit compatible
	registers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/p2m.c           |    2 +-
 xen/include/asm-arm/cpregs.h |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c4fc05e..1e8c8b4 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -29,7 +29,7 @@ void p2m_load_VTTBR(struct domain *d)
 
     vttbr |= ((uint64_t)p2m->vmid&0xff)<<48;
 
-    WRITE_CP64(vttbr, VTTBR);
+    WRITE_SYSREG64(vttbr, VTTBR_EL2);
     isb(); /* Ensure update is visible */
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 35c0ee6..ae89e40 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -277,6 +277,7 @@
 #define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
+#define VTTBR_EL2               VTTBR
 
 #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 Feb 22 09:03:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXU-0001kF-Vu; Fri, 22 Feb 2013 09:03: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 1U8oXT-0001gk-7b
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:31 +0000
Received: from [85.158.138.51:33025] by server-1.bemta-3.messagelabs.com id
	16/39-08955-26437215; Fri, 22 Feb 2013 09:03:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5657 invoked from network); 22 Feb 2013 09:03:29 -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;
	22 Feb 2013 09:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518887"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:28 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-GN;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:58 +0000
Message-ID: <1361523505-7604-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 19/46] xen: arm64: changes to
	setup_pagetables and mm.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Make *_table_offset return an unsigned int and adjust callers where
    necessary.
    Print "TTBR" instead of "TTBR0_EL2" when it is obvious from the ctxt.
---
 xen/arch/arm/arm32/head.S    |    2 +-
 xen/arch/arm/mm.c            |   46 +++++++++++++++++++++++------------------
 xen/include/asm-arm/cpregs.h |    2 +
 xen/include/asm-arm/page.h   |   10 +++++---
 4 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 5ec46c3..db3baa0 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -292,7 +292,7 @@ paging:
 
         /* Non-boot CPUs need to move on to the relocated pagetables */
         mov   r0, #0
-        ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
+        ldr   r4, =boot_ttbr         /* VA of HTTBR value stashed by CPU 0 */
         add   r4, r4, r10            /* PA of it */
         ldrd  r4, r5, [r4]           /* Actual value */
         dsb
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c6fc50b..9661f10 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -40,7 +40,11 @@
 struct domain *dom_xen, *dom_io, *dom_cow;
 
 /* Static start-of-day pagetables that we use before the allocators are up */
+/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#ifdef CONFIG_ARM_64
+lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#endif
 /* N.B. The second-level table is 4 contiguous pages long, and covers
  * all addresses from 0 to 0xffffffff.  Offsets into it are calculated
  * with second_linear_offset(), not second_table_offset(). */
@@ -49,7 +53,7 @@ lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
 /* Non-boot CPUs use this to find the correct pagetables. */
-uint64_t boot_httbr;
+uint64_t boot_ttbr;
 
 static paddr_t phys_offset;
 
@@ -73,24 +77,21 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
     if ( first_table_offset(addr) >= LPAE_ENTRIES )
         return;
 
-    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
-           first_table_offset(addr),
+    printk("1ST[0x%x] = 0x%"PRIpaddr"\n", first_table_offset(addr),
            first[first_table_offset(addr)].bits);
     if ( !first[first_table_offset(addr)].walk.valid ||
          !first[first_table_offset(addr)].walk.table )
         goto done;
 
     second = map_domain_page(first[first_table_offset(addr)].walk.base);
-    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
-           second_table_offset(addr),
+    printk("2ND[0x%x] = 0x%"PRIpaddr"\n", second_table_offset(addr),
            second[second_table_offset(addr)].bits);
     if ( !second[second_table_offset(addr)].walk.valid ||
          !second[second_table_offset(addr)].walk.table )
         goto done;
 
     third = map_domain_page(second[second_table_offset(addr)].walk.base);
-    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
-           third_table_offset(addr),
+    printk("3RD[0x%x] = 0x%"PRIpaddr"\n", third_table_offset(addr),
            third[third_table_offset(addr)].bits);
 
 done:
@@ -99,14 +100,14 @@ done:
 
 }
 
-void dump_hyp_walk(uint32_t addr)
+void dump_hyp_walk(vaddr_t addr)
 {
-    uint64_t httbr = READ_CP64(HTTBR);
+    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
 
-    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
-           addr, httbr);
+    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR 0x%016"PRIx64"\n",
+           addr, ttbr);
 
-    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != xen_pgtable );
     dump_pt_walk(xen_pgtable, addr);
 }
 
@@ -135,7 +136,7 @@ void *map_domain_page(unsigned long mfn)
     unsigned long flags;
     lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
     unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
-    uint32_t va;
+    vaddr_t va;
     lpae_t pte;
     int i, slot;
 
@@ -275,26 +276,31 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 
     /* Update the copy of xen_pgtable to use the new paddrs */
     p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+#ifdef CONFIG_ARM_64
+    p[0].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_first + dest_va - (unsigned long) _start;
+#endif
     for ( i = 0; i < 4; i++)
         p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
     p = (void *) xen_second + dest_va - (unsigned long) _start;
     if ( boot_phys_offset != 0 )
     {
         /* Remove the old identity mapping of the boot paddr */
-        unsigned long va = (unsigned long)_start + boot_phys_offset;
+        vaddr_t va = (vaddr_t)_start + boot_phys_offset;
         p[second_linear_offset(va)].bits = 0;
     }
     for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
         if ( p[i].pt.valid )
-                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+            p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
 
     /* Change pagetables to the copy in the relocated Xen */
-    boot_httbr = (unsigned long) xen_pgtable + phys_offset;
-    flush_xen_dcache(boot_httbr);
+    boot_ttbr = (uintptr_t) xen_pgtable + phys_offset;
+    flush_xen_dcache(boot_ttbr);
     flush_xen_dcache_va_range((void*)dest_va, _end - _start);
     flush_xen_text_tlb();
 
-    WRITE_CP64(boot_httbr, HTTBR); /* Change translation base */
+    WRITE_SYSREG64(boot_ttbr, TTBR0_EL2);
     dsb();                         /* Ensure visibility of HTTBR update */
     flush_xen_text_tlb();
 
@@ -339,7 +345,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     /* TLBFLUSH and ISB would be needed here, but wait until we set WXN */
 
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     /* Flush everything after setting WXN bit. */
     flush_xen_text_tlb();
 }
@@ -348,7 +354,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 void __cpuinit mmu_init_secondary_cpu(void)
 {
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     flush_xen_text_tlb();
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index e34e066..7a7c598 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -242,6 +242,8 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define SCTLR_EL2               HSCTLR
+#define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 100666b..14e63eb 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -274,7 +274,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
 /* Print a walk of the hypervisor's page tables for a virtual addr. */
-extern void dump_hyp_walk(uint32_t addr);
+extern void dump_hyp_walk(vaddr_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
@@ -326,9 +326,11 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 #define first_linear_offset(va) (va >> FIRST_SHIFT)
 #define second_linear_offset(va) (va >> SECOND_SHIFT)
 #define third_linear_offset(va) (va >> THIRD_SHIFT)
-#define first_table_offset(va) (first_linear_offset(va))
-#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
-#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define TABLE_OFFSET(offs) ((unsigned int)(offs) & LPAE_ENTRY_MASK)
+#define first_table_offset(va)  TABLE_OFFSET(first_linear_offset(va))
+#define second_table_offset(va) TABLE_OFFSET(second_linear_offset(va))
+#define third_table_offset(va)  TABLE_OFFSET(third_linear_offset(va))
 
 #define clear_page(page)memset((void *)(page), 0, PAGE_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 Fri Feb 22 09:03:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXU-0001kF-Vu; Fri, 22 Feb 2013 09:03: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 1U8oXT-0001gk-7b
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:31 +0000
Received: from [85.158.138.51:33025] by server-1.bemta-3.messagelabs.com id
	16/39-08955-26437215; Fri, 22 Feb 2013 09:03:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5657 invoked from network); 22 Feb 2013 09:03:29 -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;
	22 Feb 2013 09:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518887"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:28 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-GN;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:58 +0000
Message-ID: <1361523505-7604-19-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 19/46] xen: arm64: changes to
	setup_pagetables and mm.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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Make *_table_offset return an unsigned int and adjust callers where
    necessary.
    Print "TTBR" instead of "TTBR0_EL2" when it is obvious from the ctxt.
---
 xen/arch/arm/arm32/head.S    |    2 +-
 xen/arch/arm/mm.c            |   46 +++++++++++++++++++++++------------------
 xen/include/asm-arm/cpregs.h |    2 +
 xen/include/asm-arm/page.h   |   10 +++++---
 4 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 5ec46c3..db3baa0 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -292,7 +292,7 @@ paging:
 
         /* Non-boot CPUs need to move on to the relocated pagetables */
         mov   r0, #0
-        ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
+        ldr   r4, =boot_ttbr         /* VA of HTTBR value stashed by CPU 0 */
         add   r4, r4, r10            /* PA of it */
         ldrd  r4, r5, [r4]           /* Actual value */
         dsb
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c6fc50b..9661f10 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -40,7 +40,11 @@
 struct domain *dom_xen, *dom_io, *dom_cow;
 
 /* Static start-of-day pagetables that we use before the allocators are up */
+/* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#ifdef CONFIG_ARM_64
+lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#endif
 /* N.B. The second-level table is 4 contiguous pages long, and covers
  * all addresses from 0 to 0xffffffff.  Offsets into it are calculated
  * with second_linear_offset(), not second_table_offset(). */
@@ -49,7 +53,7 @@ lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
 /* Non-boot CPUs use this to find the correct pagetables. */
-uint64_t boot_httbr;
+uint64_t boot_ttbr;
 
 static paddr_t phys_offset;
 
@@ -73,24 +77,21 @@ void dump_pt_walk(lpae_t *first, paddr_t addr)
     if ( first_table_offset(addr) >= LPAE_ENTRIES )
         return;
 
-    printk("1ST[0x%llx] = 0x%"PRIpaddr"\n",
-           first_table_offset(addr),
+    printk("1ST[0x%x] = 0x%"PRIpaddr"\n", first_table_offset(addr),
            first[first_table_offset(addr)].bits);
     if ( !first[first_table_offset(addr)].walk.valid ||
          !first[first_table_offset(addr)].walk.table )
         goto done;
 
     second = map_domain_page(first[first_table_offset(addr)].walk.base);
-    printk("2ND[0x%llx] = 0x%"PRIpaddr"\n",
-           second_table_offset(addr),
+    printk("2ND[0x%x] = 0x%"PRIpaddr"\n", second_table_offset(addr),
            second[second_table_offset(addr)].bits);
     if ( !second[second_table_offset(addr)].walk.valid ||
          !second[second_table_offset(addr)].walk.table )
         goto done;
 
     third = map_domain_page(second[second_table_offset(addr)].walk.base);
-    printk("3RD[0x%llx] = 0x%"PRIpaddr"\n",
-           third_table_offset(addr),
+    printk("3RD[0x%x] = 0x%"PRIpaddr"\n", third_table_offset(addr),
            third[third_table_offset(addr)].bits);
 
 done:
@@ -99,14 +100,14 @@ done:
 
 }
 
-void dump_hyp_walk(uint32_t addr)
+void dump_hyp_walk(vaddr_t addr)
 {
-    uint64_t httbr = READ_CP64(HTTBR);
+    uint64_t ttbr = READ_SYSREG64(TTBR0_EL2);
 
-    printk("Walking Hypervisor VA 0x%08"PRIx32" via HTTBR 0x%016"PRIx64"\n",
-           addr, httbr);
+    printk("Walking Hypervisor VA 0x%"PRIvaddr" via TTBR 0x%016"PRIx64"\n",
+           addr, ttbr);
 
-    BUG_ON( (lpae_t *)(unsigned long)(httbr - phys_offset) != xen_pgtable );
+    BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != xen_pgtable );
     dump_pt_walk(xen_pgtable, addr);
 }
 
@@ -135,7 +136,7 @@ void *map_domain_page(unsigned long mfn)
     unsigned long flags;
     lpae_t *map = xen_second + second_linear_offset(DOMHEAP_VIRT_START);
     unsigned long slot_mfn = mfn & ~LPAE_ENTRY_MASK;
-    uint32_t va;
+    vaddr_t va;
     lpae_t pte;
     int i, slot;
 
@@ -275,26 +276,31 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 
     /* Update the copy of xen_pgtable to use the new paddrs */
     p = (void *) xen_pgtable + dest_va - (unsigned long) _start;
+#ifdef CONFIG_ARM_64
+    p[0].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+    p = (void *) xen_first + dest_va - (unsigned long) _start;
+#endif
     for ( i = 0; i < 4; i++)
         p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+
     p = (void *) xen_second + dest_va - (unsigned long) _start;
     if ( boot_phys_offset != 0 )
     {
         /* Remove the old identity mapping of the boot paddr */
-        unsigned long va = (unsigned long)_start + boot_phys_offset;
+        vaddr_t va = (vaddr_t)_start + boot_phys_offset;
         p[second_linear_offset(va)].bits = 0;
     }
     for ( i = 0; i < 4 * LPAE_ENTRIES; i++)
         if ( p[i].pt.valid )
-                p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
+            p[i].pt.base += (phys_offset - boot_phys_offset) >> PAGE_SHIFT;
 
     /* Change pagetables to the copy in the relocated Xen */
-    boot_httbr = (unsigned long) xen_pgtable + phys_offset;
-    flush_xen_dcache(boot_httbr);
+    boot_ttbr = (uintptr_t) xen_pgtable + phys_offset;
+    flush_xen_dcache(boot_ttbr);
     flush_xen_dcache_va_range((void*)dest_va, _end - _start);
     flush_xen_text_tlb();
 
-    WRITE_CP64(boot_httbr, HTTBR); /* Change translation base */
+    WRITE_SYSREG64(boot_ttbr, TTBR0_EL2);
     dsb();                         /* Ensure visibility of HTTBR update */
     flush_xen_text_tlb();
 
@@ -339,7 +345,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     /* TLBFLUSH and ISB would be needed here, but wait until we set WXN */
 
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     /* Flush everything after setting WXN bit. */
     flush_xen_text_tlb();
 }
@@ -348,7 +354,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 void __cpuinit mmu_init_secondary_cpu(void)
 {
     /* From now on, no mapping may be both writable and executable. */
-    WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
     flush_xen_text_tlb();
 }
 
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index e34e066..7a7c598 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -242,6 +242,8 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define SCTLR_EL2               HSCTLR
+#define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 100666b..14e63eb 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -274,7 +274,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 void dump_pt_walk(lpae_t *table, paddr_t addr);
 
 /* Print a walk of the hypervisor's page tables for a virtual addr. */
-extern void dump_hyp_walk(uint32_t addr);
+extern void dump_hyp_walk(vaddr_t addr);
 /* Print a walk of the p2m for a domain for a physical address. */
 extern void dump_p2m_lookup(struct domain *d, paddr_t addr);
 
@@ -326,9 +326,11 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr)
 #define first_linear_offset(va) (va >> FIRST_SHIFT)
 #define second_linear_offset(va) (va >> SECOND_SHIFT)
 #define third_linear_offset(va) (va >> THIRD_SHIFT)
-#define first_table_offset(va) (first_linear_offset(va))
-#define second_table_offset(va) (second_linear_offset(va) & LPAE_ENTRY_MASK)
-#define third_table_offset(va) (third_linear_offset(va) & LPAE_ENTRY_MASK)
+
+#define TABLE_OFFSET(offs) ((unsigned int)(offs) & LPAE_ENTRY_MASK)
+#define first_table_offset(va)  TABLE_OFFSET(first_linear_offset(va))
+#define second_table_offset(va) TABLE_OFFSET(second_linear_offset(va))
+#define third_table_offset(va)  TABLE_OFFSET(third_linear_offset(va))
 
 #define clear_page(page)memset((void *)(page), 0, PAGE_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 Fri Feb 22 09:03:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXX-0001oL-M3; Fri, 22 Feb 2013 09:03:35 +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 1U8oXW-0001m3-KX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:34 +0000
Received: from [85.158.139.211:57769] by server-3.bemta-5.messagelabs.com id
	EE/31-07037-56437215; Fri, 22 Feb 2013 09:03:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3699 invoked from network); 22 Feb 2013 09:02:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956591"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:55 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-0P;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:17 +0000
Message-ID: <1361523505-7604-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 38/46] xen: arm: handle 32-bit guest CP
	register traps on 64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6be70fa..d1cf0e6 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -700,16 +700,16 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to write to read-only register CLIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CLIDR);
+        *r = READ_SYSREG32(CLIDR_EL1);
         break;
     case HSR_CPREG32(CCSIDR):
         if ( !cp32.read )
         {
             dprintk(XENLOG_ERR,
-                    "attempt to write to read-only register CSSIDR\n");
+                    "attempt to write to read-only register CCSIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CCSIDR);
+        *r = READ_SYSREG32(CCSIDR_EL1);
         break;
     case HSR_CPREG32(DCCISW):
         if ( cp32.read )
@@ -718,7 +718,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to read from write-only register DCCISW\n");
             domain_crash_synchronous();
         }
+#ifdef CONFIG_ARM_32
         WRITE_CP32(*r, DCCISW);
+#else
+        asm volatile("dc cisw, %0;" : : "r" (*r) : "memory");
+#endif
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-- 
1.7.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 Feb 22 09:03:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXX-0001oL-M3; Fri, 22 Feb 2013 09:03:35 +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 1U8oXW-0001m3-KX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:34 +0000
Received: from [85.158.139.211:57769] by server-3.bemta-5.messagelabs.com id
	EE/31-07037-56437215; Fri, 22 Feb 2013 09:03:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3699 invoked from network); 22 Feb 2013 09:02:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956591"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:02:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:02:55 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-0P;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:17 +0000
Message-ID: <1361523505-7604-38-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 38/46] xen: arm: handle 32-bit guest CP
	register traps on 64-bit 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6be70fa..d1cf0e6 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -700,16 +700,16 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to write to read-only register CLIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CLIDR);
+        *r = READ_SYSREG32(CLIDR_EL1);
         break;
     case HSR_CPREG32(CCSIDR):
         if ( !cp32.read )
         {
             dprintk(XENLOG_ERR,
-                    "attempt to write to read-only register CSSIDR\n");
+                    "attempt to write to read-only register CCSIDR\n");
             domain_crash_synchronous();
         }
-        *r = READ_CP32(CCSIDR);
+        *r = READ_SYSREG32(CCSIDR_EL1);
         break;
     case HSR_CPREG32(DCCISW):
         if ( cp32.read )
@@ -718,7 +718,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                     "attempt to read from write-only register DCCISW\n");
             domain_crash_synchronous();
         }
+#ifdef CONFIG_ARM_32
         WRITE_CP32(*r, DCCISW);
+#else
+        asm volatile("dc cisw, %0;" : : "r" (*r) : "memory");
+#endif
         break;
     case HSR_CPREG32(CNTP_CTL):
     case HSR_CPREG32(CNTP_TVAL):
-- 
1.7.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 Feb 22 09:03:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXZ-0001qP-74; Fri, 22 Feb 2013 09:03:37 +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 1U8oXX-0001nS-Fk
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:35 +0000
Received: from [85.158.138.51:47588] by server-15.bemta-3.messagelabs.com id
	0C/F4-25405-66437215; Fri, 22 Feb 2013 09:03:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6080 invoked from network); 22 Feb 2013 09:03:33 -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;
	22 Feb 2013 09:03:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518919"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Hz;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:59 +0000
Message-ID: <1361523505-7604-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 20/46] xen: arm64: add to foreign struct
	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>
Content-Type: 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>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .gitignore                               |    1 +
 tools/include/xen-foreign/Makefile       |    5 ++++-
 tools/include/xen-foreign/mkheader.py    |   13 +++++++++++++
 tools/include/xen-foreign/reference.size |   20 ++++++++++----------
 tools/include/xen-foreign/structs.py     |    1 +
 5 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 3834e4b..fce8c89 100644
--- a/.gitignore
+++ b/.gitignore
@@ -367,6 +367,7 @@ tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
 tools/include/xen-foreign/arm32.h
+tools/include/xen-foreign/arm64.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 5bc2d46..8e0be83 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm32 x86_32 x86_64
+architectures := arm32 arm64 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -25,6 +25,9 @@ check-headers: checker
 arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
+arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index e3e61f3..c63db31 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -27,6 +27,16 @@ header["arm32"] = """
 #define __arm___ARM32 1
 """;
 
+inttypes["arm64"] = {
+    "unsigned long" : "__danger_unsigned_long_on_arm64",
+    "long"          : "__danger_long_on_arm64",
+    "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
+};
+header["arm64"] = """
+#define __aarch64___ARM64 1
+""";
+
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
@@ -59,6 +69,9 @@ header["x86_64"] = """
 #endif
 #define __x86_64___X86_64 1
 """;
+footer["x86_64"] = """
+#undef __DECL_REG
+"""
 
 ###########################################################################
 # main
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 9f1bfac..1d75ff3 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,13 @@
 
-structs                   |   arm32  x86_32  x86_64
+structs                   |   arm32   arm64  x86_32  x86_64
 
-start_info                |       -    1112    1168
-trap_info                 |       -       8      16
-cpu_user_regs             |     160      68     200
-vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+start_info                |       -       -    1112    1168
+trap_info                 |       -       -       8      16
+cpu_user_regs             |     160     160      68     200
+vcpu_guest_context        |     180     160    2800    5168
+arch_vcpu_info            |       -       -      24      16
+vcpu_time_info            |       -       -      32      32
+vcpu_info                 |       -       -      64      64
+arch_shared_info          |       -       -     268     280
+shared_info               |       -       -    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 51a77c0..5aec2c5 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -14,6 +14,7 @@ structs = [ "start_info",
             "shared_info" ];
 
 defines = [ "__arm__",
+            "__aarch64__",
             "__i386__",
             "__x86_64__",
 
-- 
1.7.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 Feb 22 09:03:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXZ-0001qP-74; Fri, 22 Feb 2013 09:03:37 +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 1U8oXX-0001nS-Fk
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:35 +0000
Received: from [85.158.138.51:47588] by server-15.bemta-3.messagelabs.com id
	0C/F4-25405-66437215; Fri, 22 Feb 2013 09:03:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6080 invoked from network); 22 Feb 2013 09:03:33 -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;
	22 Feb 2013 09:03:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518919"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:33 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:32 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Hz;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:59 +0000
Message-ID: <1361523505-7604-20-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 20/46] xen: arm64: add to foreign struct
	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>
Content-Type: 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>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .gitignore                               |    1 +
 tools/include/xen-foreign/Makefile       |    5 ++++-
 tools/include/xen-foreign/mkheader.py    |   13 +++++++++++++
 tools/include/xen-foreign/reference.size |   20 ++++++++++----------
 tools/include/xen-foreign/structs.py     |    1 +
 5 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 3834e4b..fce8c89 100644
--- a/.gitignore
+++ b/.gitignore
@@ -367,6 +367,7 @@ tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
 tools/include/xen-foreign/arm32.h
+tools/include/xen-foreign/arm64.h
 
 .git
 tools/misc/xen-hptool
diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 5bc2d46..8e0be83 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := arm32 x86_32 x86_64
+architectures := arm32 arm64 x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -25,6 +25,9 @@ check-headers: checker
 arm32.h: mkheader.py structs.py $(ROOT)/arch-arm.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
+arm64.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index e3e61f3..c63db31 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -27,6 +27,16 @@ header["arm32"] = """
 #define __arm___ARM32 1
 """;
 
+inttypes["arm64"] = {
+    "unsigned long" : "__danger_unsigned_long_on_arm64",
+    "long"          : "__danger_long_on_arm64",
+    "xen_pfn_t"     : "uint64_t",
+    "xen_ulong_t"   : "uint64_t",
+};
+header["arm64"] = """
+#define __aarch64___ARM64 1
+""";
+
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
@@ -59,6 +69,9 @@ header["x86_64"] = """
 #endif
 #define __x86_64___X86_64 1
 """;
+footer["x86_64"] = """
+#undef __DECL_REG
+"""
 
 ###########################################################################
 # main
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index 9f1bfac..1d75ff3 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,13 @@
 
-structs                   |   arm32  x86_32  x86_64
+structs                   |   arm32   arm64  x86_32  x86_64
 
-start_info                |       -    1112    1168
-trap_info                 |       -       8      16
-cpu_user_regs             |     160      68     200
-vcpu_guest_context        |     180    2800    5168
-arch_vcpu_info            |       -      24      16
-vcpu_time_info            |       -      32      32
-vcpu_info                 |       -      64      64
-arch_shared_info          |       -     268     280
-shared_info               |       -    2584    3368
+start_info                |       -       -    1112    1168
+trap_info                 |       -       -       8      16
+cpu_user_regs             |     160     160      68     200
+vcpu_guest_context        |     180     160    2800    5168
+arch_vcpu_info            |       -       -      24      16
+vcpu_time_info            |       -       -      32      32
+vcpu_info                 |       -       -      64      64
+arch_shared_info          |       -       -     268     280
+shared_info               |       -       -    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 51a77c0..5aec2c5 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -14,6 +14,7 @@ structs = [ "start_info",
             "shared_info" ];
 
 defines = [ "__arm__",
+            "__aarch64__",
             "__i386__",
             "__x86_64__",
 
-- 
1.7.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 Feb 22 09:03:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXf-0001zP-3k; Fri, 22 Feb 2013 09:03:43 +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 1U8oXc-0001uD-Js
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:40 +0000
Received: from [85.158.138.51:38047] by server-16.bemta-3.messagelabs.com id
	54/C3-02727-B6437215; Fri, 22 Feb 2013 09:03:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6676 invoked from network); 22 Feb 2013 09:03:38 -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;
	22 Feb 2013 09:03:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518966"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:37 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-IJ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:00 +0000
Message-ID: <1361523505-7604-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 21/46] xen: arm: extend HSR struct
	definitions to 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change is that the 4-bit register specifiers are extended
to 5 bits by taking in an adjacent SBZP bit.

Also 64-bit has two other properties indicting whether or not the
target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
instruction has acquire/release semantics.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/processor.h |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 86e6f26..a9ce041 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -99,11 +99,11 @@ union hsr {
         unsigned long ec:6;    /* Exception Class */
     };
 
+    /* reg, reg0, reg1 are 4 bits on AArch32, the fifth bit is sbzp. */
     struct hsr_cp32 {
         unsigned long read:1;  /* Direction */
         unsigned long crm:4;   /* CRm */
-        unsigned long reg:4;   /* Rt */
-        unsigned long sbzp:1;
+        unsigned long reg:5;   /* Rt */
         unsigned long crn:4;   /* CRn */
         unsigned long op1:3;   /* Op1 */
         unsigned long op2:3;   /* Op2 */
@@ -116,10 +116,9 @@ union hsr {
     struct hsr_cp64 {
         unsigned long read:1;   /* Direction */
         unsigned long crm:4;    /* CRm */
-        unsigned long reg1:4;   /* Rt1 */
-        unsigned long sbzp1:1;
-        unsigned long reg2:4;   /* Rt2 */
-        unsigned long sbzp2:2;
+        unsigned long reg1:5;   /* Rt1 */
+        unsigned long reg2:5;   /* Rt2 */
+        unsigned long sbzp2:1;
         unsigned long op1:4;   /* Op1 */
         unsigned long cc:4;    /* Condition Code */
         unsigned long ccvalid:1;/* CC Valid */
@@ -133,9 +132,14 @@ union hsr {
         unsigned long s1ptw:1; /* */
         unsigned long cache:1; /* Cache Maintenance */
         unsigned long eat:1;   /* External Abort Type */
+#ifdef CONFIG_ARM_32
         unsigned long sbzp0:6;
-        unsigned long reg:4;   /* Register */
-        unsigned long sbzp1:1;
+#else
+        unsigned long sbzp0:4;
+        unsigned long ar:1;    /* Acquire Release */
+        unsigned long sf:1;    /* Sixty Four bit register */
+#endif
+        unsigned long reg:5;   /* Register */
         unsigned long sign:1;  /* Sign extend */
         unsigned long size:2;  /* Access Size */
         unsigned long valid:1; /* Syndrome Valid */
-- 
1.7.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 Feb 22 09:03:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXf-0001zP-3k; Fri, 22 Feb 2013 09:03:43 +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 1U8oXc-0001uD-Js
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:40 +0000
Received: from [85.158.138.51:38047] by server-16.bemta-3.messagelabs.com id
	54/C3-02727-B6437215; Fri, 22 Feb 2013 09:03:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6676 invoked from network); 22 Feb 2013 09:03:38 -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;
	22 Feb 2013 09:03:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518966"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:37 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-IJ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:00 +0000
Message-ID: <1361523505-7604-21-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 21/46] xen: arm: extend HSR struct
	definitions to 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 main change is that the 4-bit register specifiers are extended
to 5 bits by taking in an adjacent SBZP bit.

Also 64-bit has two other properties indicting whether or not the
target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
instruction has acquire/release semantics.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/processor.h |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 86e6f26..a9ce041 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -99,11 +99,11 @@ union hsr {
         unsigned long ec:6;    /* Exception Class */
     };
 
+    /* reg, reg0, reg1 are 4 bits on AArch32, the fifth bit is sbzp. */
     struct hsr_cp32 {
         unsigned long read:1;  /* Direction */
         unsigned long crm:4;   /* CRm */
-        unsigned long reg:4;   /* Rt */
-        unsigned long sbzp:1;
+        unsigned long reg:5;   /* Rt */
         unsigned long crn:4;   /* CRn */
         unsigned long op1:3;   /* Op1 */
         unsigned long op2:3;   /* Op2 */
@@ -116,10 +116,9 @@ union hsr {
     struct hsr_cp64 {
         unsigned long read:1;   /* Direction */
         unsigned long crm:4;    /* CRm */
-        unsigned long reg1:4;   /* Rt1 */
-        unsigned long sbzp1:1;
-        unsigned long reg2:4;   /* Rt2 */
-        unsigned long sbzp2:2;
+        unsigned long reg1:5;   /* Rt1 */
+        unsigned long reg2:5;   /* Rt2 */
+        unsigned long sbzp2:1;
         unsigned long op1:4;   /* Op1 */
         unsigned long cc:4;    /* Condition Code */
         unsigned long ccvalid:1;/* CC Valid */
@@ -133,9 +132,14 @@ union hsr {
         unsigned long s1ptw:1; /* */
         unsigned long cache:1; /* Cache Maintenance */
         unsigned long eat:1;   /* External Abort Type */
+#ifdef CONFIG_ARM_32
         unsigned long sbzp0:6;
-        unsigned long reg:4;   /* Register */
-        unsigned long sbzp1:1;
+#else
+        unsigned long sbzp0:4;
+        unsigned long ar:1;    /* Acquire Release */
+        unsigned long sf:1;    /* Sixty Four bit register */
+#endif
+        unsigned long reg:5;   /* Register */
         unsigned long sign:1;  /* Sign extend */
         unsigned long size:2;  /* Access Size */
         unsigned long valid:1; /* Syndrome Valid */
-- 
1.7.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 Feb 22 09:03:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXf-00020C-Iq; Fri, 22 Feb 2013 09:03: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 1U8oXd-0001vm-I3
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:41 +0000
Received: from [85.158.139.211:58489] by server-3.bemta-5.messagelabs.com id
	BE/81-07037-C6437215; Fri, 22 Feb 2013 09:03:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!11
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7816 invoked from network); 22 Feb 2013 09:03:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956652"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:21 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-0k;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:18 +0000
Message-ID: <1361523505-7604-39-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 39/46] xen: arm: guest stage 1 walks on
	64-bit 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

Still only supports non-LPAE 32-bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d1cf0e6..6f24920 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -780,8 +780,8 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
-    uint32_t ttbcr = READ_CP32(TTBCR);
-    uint64_t ttbr0 = READ_CP64(TTBR0);
+    uint32_t ttbcr = READ_SYSREG32(TCR_EL1);
+    uint64_t ttbr0 = READ_SYSREG64(TTBR0_EL1);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = 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 Fri Feb 22 09:03:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXf-00020C-Iq; Fri, 22 Feb 2013 09:03: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 1U8oXd-0001vm-I3
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:41 +0000
Received: from [85.158.139.211:58489] by server-3.bemta-5.messagelabs.com id
	BE/81-07037-C6437215; Fri, 22 Feb 2013 09:03:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!11
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7816 invoked from network); 22 Feb 2013 09:03:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956652"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:21 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-0k;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:18 +0000
Message-ID: <1361523505-7604-39-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 39/46] xen: arm: guest stage 1 walks on
	64-bit 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

Still only supports non-LPAE 32-bit guests.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d1cf0e6..6f24920 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -780,8 +780,8 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
-    uint32_t ttbcr = READ_CP32(TTBCR);
-    uint64_t ttbr0 = READ_CP64(TTBR0);
+    uint32_t ttbcr = READ_SYSREG32(TCR_EL1);
+    uint64_t ttbr0 = READ_SYSREG64(TTBR0_EL1);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = 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 Fri Feb 22 09:03:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXj-000288-Bb; Fri, 22 Feb 2013 09:03: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 1U8oXg-000216-K2
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:44 +0000
Received: from [85.158.139.211:58793] by server-12.bemta-5.messagelabs.com id
	07/27-20195-F6437215; Fri, 22 Feb 2013 09:03:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!12
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8298 invoked from network); 22 Feb 2013 09:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956662"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-NJ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:07 +0000
Message-ID: <1361523505-7604-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 28/46] xen: arm: pcpu context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm64/entry.S   |   30 ++++++++++++++++++++++++++++++
 xen/arch/arm/domain.c        |    4 ++--
 xen/include/asm-arm/domain.h |   33 +++++++++++++++++++++++----------
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index e35b6ea..9d38088 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -247,6 +247,36 @@ ENTRY(hyp_traps_vector)
         ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
 
 /*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * x0 - prev
+ * x1 - next
+ *
+ * Returns prev in x0
+ */
+ENTRY(__context_switch)
+        add     x8, x0, #VCPU_arch_saved_context
+        mov     x9, sp
+        stp     x19, x20, [x8], #16             // store callee-saved registers
+        stp     x21, x22, [x8], #16
+        stp     x23, x24, [x8], #16
+        stp     x25, x26, [x8], #16
+        stp     x27, x28, [x8], #16
+        stp     x29, x9, [x8], #16
+        str     lr, [x8]
+
+        add     x8, x1, #VCPU_arch_saved_context
+        ldp     x19, x20, [x8], #16             // restore callee-saved registers
+        ldp     x21, x22, [x8], #16
+        ldp     x23, x24, [x8], #16
+        ldp     x25, x26, [x8], #16
+        ldp     x27, x28, [x8], #16
+        ldp     x29, x9, [x8], #16
+        ldr     lr, [x8]
+        mov     sp, x9
+        ret
+
+/*
  * Local variables:
  * mode: ASM
  * indent-tabs-mode: nil
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3d21f0e..883a681 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -387,8 +387,8 @@ int vcpu_initialise(struct vcpu *v)
                                            - sizeof(struct cpu_info));
 
     memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
-    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
-    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+    v->arch.saved_context.sp = (register_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (register_t)continue_new_vcpu;
 
     /* Idle VCPUs don't need the rest of this setup */
     if ( is_idle_vcpu(v) )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4e9d38d..f691c26 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -99,16 +99,29 @@ struct vtimer {
 struct arch_vcpu
 {
     struct {
-        uint32_t    r4;
-        uint32_t    r5;
-        uint32_t    r6;
-        uint32_t    r7;
-        uint32_t    r8;
-        uint32_t    r9;
-        uint32_t    sl;
-        uint32_t    fp;
-        uint32_t    sp;
-        uint32_t    pc;
+#ifdef CONFIG_ARM_32
+        register_t r4;
+        register_t r5;
+        register_t r6;
+        register_t r7;
+        register_t r8;
+        register_t r9;
+        register_t sl;
+#else
+        register_t x19;
+        register_t x20;
+        register_t x21;
+        register_t x22;
+        register_t x23;
+        register_t x24;
+        register_t x25;
+        register_t x26;
+        register_t x27;
+        register_t x28;
+#endif
+        register_t fp;
+        register_t sp;
+        register_t pc;
     } saved_context;
 
     void *stack;
-- 
1.7.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 Feb 22 09:03:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXj-000288-Bb; Fri, 22 Feb 2013 09:03: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 1U8oXg-000216-K2
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:44 +0000
Received: from [85.158.139.211:58793] by server-12.bemta-5.messagelabs.com id
	07/27-20195-F6437215; Fri, 22 Feb 2013 09:03:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!12
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8298 invoked from network); 22 Feb 2013 09:03:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956662"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:26 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-NJ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:07 +0000
Message-ID: <1361523505-7604-28-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 28/46] xen: arm: pcpu context switch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/arm64/entry.S   |   30 ++++++++++++++++++++++++++++++
 xen/arch/arm/domain.c        |    4 ++--
 xen/include/asm-arm/domain.h |   33 +++++++++++++++++++++++----------
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index e35b6ea..9d38088 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -247,6 +247,36 @@ ENTRY(hyp_traps_vector)
         ventry  guest_error_invalid_compat      // Error 32-bit EL0/EL1
 
 /*
+ * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next)
+ *
+ * x0 - prev
+ * x1 - next
+ *
+ * Returns prev in x0
+ */
+ENTRY(__context_switch)
+        add     x8, x0, #VCPU_arch_saved_context
+        mov     x9, sp
+        stp     x19, x20, [x8], #16             // store callee-saved registers
+        stp     x21, x22, [x8], #16
+        stp     x23, x24, [x8], #16
+        stp     x25, x26, [x8], #16
+        stp     x27, x28, [x8], #16
+        stp     x29, x9, [x8], #16
+        str     lr, [x8]
+
+        add     x8, x1, #VCPU_arch_saved_context
+        ldp     x19, x20, [x8], #16             // restore callee-saved registers
+        ldp     x21, x22, [x8], #16
+        ldp     x23, x24, [x8], #16
+        ldp     x25, x26, [x8], #16
+        ldp     x27, x28, [x8], #16
+        ldp     x29, x9, [x8], #16
+        ldr     lr, [x8]
+        mov     sp, x9
+        ret
+
+/*
  * Local variables:
  * mode: ASM
  * indent-tabs-mode: nil
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3d21f0e..883a681 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -387,8 +387,8 @@ int vcpu_initialise(struct vcpu *v)
                                            - sizeof(struct cpu_info));
 
     memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context));
-    v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info;
-    v->arch.saved_context.pc = (uint32_t)continue_new_vcpu;
+    v->arch.saved_context.sp = (register_t)v->arch.cpu_info;
+    v->arch.saved_context.pc = (register_t)continue_new_vcpu;
 
     /* Idle VCPUs don't need the rest of this setup */
     if ( is_idle_vcpu(v) )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4e9d38d..f691c26 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -99,16 +99,29 @@ struct vtimer {
 struct arch_vcpu
 {
     struct {
-        uint32_t    r4;
-        uint32_t    r5;
-        uint32_t    r6;
-        uint32_t    r7;
-        uint32_t    r8;
-        uint32_t    r9;
-        uint32_t    sl;
-        uint32_t    fp;
-        uint32_t    sp;
-        uint32_t    pc;
+#ifdef CONFIG_ARM_32
+        register_t r4;
+        register_t r5;
+        register_t r6;
+        register_t r7;
+        register_t r8;
+        register_t r9;
+        register_t sl;
+#else
+        register_t x19;
+        register_t x20;
+        register_t x21;
+        register_t x22;
+        register_t x23;
+        register_t x24;
+        register_t x25;
+        register_t x26;
+        register_t x27;
+        register_t x28;
+#endif
+        register_t fp;
+        register_t sp;
+        register_t pc;
     } saved_context;
 
     void *stack;
-- 
1.7.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 Feb 22 09:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXj-00029K-TC; Fri, 22 Feb 2013 09:03: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 1U8oXg-00021k-QJ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5823] by server-1.bemta-5.messagelabs.com id
	BB/75-29263-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!9
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6194 invoked from network); 22 Feb 2013 09:03:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956638"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:12 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Jq;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:01 +0000
Message-ID: <1361523505-7604-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 22/46] xen: arm: use vaddr_t more widely.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v7: mmio_info_t too
---
 xen/arch/arm/guestcopy.c |   16 +++++++++-------
 xen/arch/arm/io.h        |    2 +-
 xen/include/asm-arm/mm.h |    6 +++---
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index c47558f..d146cd6 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -8,7 +8,7 @@
 unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -17,7 +17,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -38,7 +38,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 unsigned long raw_clear_guest(void *to, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -47,7 +47,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -66,19 +66,21 @@ unsigned long raw_clear_guest(void *to, unsigned len)
 
 unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned len)
 {
+    unsigned offset = (vaddr_t)from & ~PAGE_MASK;
+
     while ( len )
     {
         int rc;
         paddr_t g;
         void *p;
-        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
 
-        rc = gvirt_to_maddr((uint32_t) from & PAGE_MASK, &g);
+        rc = gvirt_to_maddr((vaddr_t) from & PAGE_MASK, &g);
         if ( rc )
             return rc;
 
         p = map_domain_page(g>>PAGE_SHIFT);
-        p += ((unsigned long)from & (~PAGE_MASK));
+        p += ((vaddr_t)from & (~PAGE_MASK));
 
         memcpy(to, p, size);
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 4b0b985..661dce1 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -26,7 +26,7 @@
 typedef struct
 {
     struct hsr_dabt dabt;
-    uint32_t gva;
+    vaddr_t gva;
     paddr_t gpa;
 } mmio_info_t;
 
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 261a173..19e5bc2 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -181,8 +181,8 @@ void* early_ioremap(paddr_t start, size_t len, unsigned attributes);
 
 static inline paddr_t virt_to_maddr(const void *va)
 {
-    uint64_t par = va_to_par((uint32_t)va);
-    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+    uint64_t par = va_to_par((vaddr_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((vaddr_t) va & ~PAGE_MASK);
 }
 
 static inline void *maddr_to_virt(paddr_t ma)
@@ -192,7 +192,7 @@ static inline void *maddr_to_virt(paddr_t ma)
     return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
 }
 
-static inline int gvirt_to_maddr(uint32_t va, paddr_t *pa)
+static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa)
 {
     uint64_t par = gva_to_ma_par(va);
     if ( par & PAR_F )
-- 
1.7.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 Feb 22 09:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXj-00029K-TC; Fri, 22 Feb 2013 09:03: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 1U8oXg-00021k-QJ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5823] by server-1.bemta-5.messagelabs.com id
	BB/75-29263-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!9
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6194 invoked from network); 22 Feb 2013 09:03:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956638"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:12 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Jq;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:01 +0000
Message-ID: <1361523505-7604-22-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 22/46] xen: arm: use vaddr_t more widely.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
v7: mmio_info_t too
---
 xen/arch/arm/guestcopy.c |   16 +++++++++-------
 xen/arch/arm/io.h        |    2 +-
 xen/include/asm-arm/mm.h |    6 +++---
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index c47558f..d146cd6 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -8,7 +8,7 @@
 unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -17,7 +17,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -38,7 +38,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
 unsigned long raw_clear_guest(void *to, unsigned len)
 {
     /* XXX needs to handle faults */
-    unsigned offset = ((unsigned long)to & ~PAGE_MASK);
+    unsigned offset = (vaddr_t)to & ~PAGE_MASK;
 
     while ( len )
     {
@@ -47,7 +47,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
         void *p;
         unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
 
-        rc = gvirt_to_maddr((uint32_t) to, &g);
+        rc = gvirt_to_maddr((vaddr_t) to, &g);
         if ( rc )
             return rc;
 
@@ -66,19 +66,21 @@ unsigned long raw_clear_guest(void *to, unsigned len)
 
 unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned len)
 {
+    unsigned offset = (vaddr_t)from & ~PAGE_MASK;
+
     while ( len )
     {
         int rc;
         paddr_t g;
         void *p;
-        unsigned size = min(len, (unsigned)(PAGE_SIZE - ((unsigned)from & (~PAGE_MASK))));
+        unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
 
-        rc = gvirt_to_maddr((uint32_t) from & PAGE_MASK, &g);
+        rc = gvirt_to_maddr((vaddr_t) from & PAGE_MASK, &g);
         if ( rc )
             return rc;
 
         p = map_domain_page(g>>PAGE_SHIFT);
-        p += ((unsigned long)from & (~PAGE_MASK));
+        p += ((vaddr_t)from & (~PAGE_MASK));
 
         memcpy(to, p, size);
 
diff --git a/xen/arch/arm/io.h b/xen/arch/arm/io.h
index 4b0b985..661dce1 100644
--- a/xen/arch/arm/io.h
+++ b/xen/arch/arm/io.h
@@ -26,7 +26,7 @@
 typedef struct
 {
     struct hsr_dabt dabt;
-    uint32_t gva;
+    vaddr_t gva;
     paddr_t gpa;
 } mmio_info_t;
 
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 261a173..19e5bc2 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -181,8 +181,8 @@ void* early_ioremap(paddr_t start, size_t len, unsigned attributes);
 
 static inline paddr_t virt_to_maddr(const void *va)
 {
-    uint64_t par = va_to_par((uint32_t)va);
-    return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
+    uint64_t par = va_to_par((vaddr_t)va);
+    return (par & PADDR_MASK & PAGE_MASK) | ((vaddr_t) va & ~PAGE_MASK);
 }
 
 static inline void *maddr_to_virt(paddr_t ma)
@@ -192,7 +192,7 @@ static inline void *maddr_to_virt(paddr_t ma)
     return (void *)(unsigned long) ma + XENHEAP_VIRT_START;
 }
 
-static inline int gvirt_to_maddr(uint32_t va, paddr_t *pa)
+static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa)
 {
     uint64_t par = gva_to_ma_par(va);
     if ( par & PAR_F )
-- 
1.7.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 Feb 22 09:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXk-0002AS-FM; Fri, 22 Feb 2013 09:03: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 1U8oXh-00022H-0k
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5851] by server-13.bemta-5.messagelabs.com id
	76/32-06769-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!10
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6968 invoked from network); 22 Feb 2013 09:03:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956647"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:16 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-SA;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:11 +0000
Message-ID: <1361523505-7604-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 32/46] xen: arm: make dom0 builder work on
	64-bit 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

This still only builds a 32-bit dom0, although it lays a bit of
simple ground work for 64-bit dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c |   53 ++++++++++++++++++++++++++++--------------
 1 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f05b2df..13dc049 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -68,7 +68,7 @@ static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
             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);
+        printk("Populate P2M %#"PRIx64"->%#"PRIx64"\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;
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
@@ -319,7 +319,8 @@ int construct_dom0(struct domain *d)
     gic_route_irq_to_guest(d, 47, "eth");
 
     /* Enable second stage translation */
-    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+    WRITE_SYSREG(READ_SYSREG(HCR_EL2) | HCR_VM, HCR_EL2);
+    isb();
 
     /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
@@ -337,24 +338,40 @@ int construct_dom0(struct domain *d)
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
-/* FROM LINUX head.S
-
- * Kernel startup entry point.
- * ---------------------------
- *
- * This is normally called from the decompressor code.  The requirements
- * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
- * r1 = machine nr, r2 = atags or dtb pointer.
- *...
- */
+#ifdef CONFIG_ARM_64
+    d->arch.type = kinfo.type;
+#endif
 
-    regs->r0 = 0; /* SBZ */
-    regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
-    regs->r2 = kinfo.dtb_paddr;
+    if ( is_pv32_domain(d) )
+    {
+        /* FROM LINUX head.S
+         *
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * This is normally called from the decompressor code.  The requirements
+         * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+         * r1 = machine nr, r2 = atags or dtb pointer.
+         *...
+         */
+        regs->r0 = 0; /* SBZ */
+        regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
+        regs->r2 = kinfo.dtb_paddr;
+    }
+#ifdef CONFIG_ARM_64
+    else
+    {
+        /* From linux/Documentation/arm64/booting.txt */
+        regs->x0 = kinfo.dtb_paddr;
+        regs->x1 = 0; /* Reserved for future use */
+        regs->x2 = 0; /* Reserved for future use */
+        regs->x3 = 0; /* Reserved for future use */
+    }
+#endif
 
-    WRITE_CP32(SCTLR_BASE, SCTLR);
+    v->arch.sctlr = SCTLR_BASE;
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_SYSREG(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR_EL2);
     isb();
 
     local_abort_enable();
-- 
1.7.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 Feb 22 09:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXk-0002AS-FM; Fri, 22 Feb 2013 09:03: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 1U8oXh-00022H-0k
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5851] by server-13.bemta-5.messagelabs.com id
	76/32-06769-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!10
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6968 invoked from network); 22 Feb 2013 09:03:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956647"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:16 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-SA;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:11 +0000
Message-ID: <1361523505-7604-32-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 32/46] xen: arm: make dom0 builder work on
	64-bit 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

This still only builds a 32-bit dom0, although it lays a bit of
simple ground work for 64-bit dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/domain_build.c |   53 ++++++++++++++++++++++++++++--------------
 1 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f05b2df..13dc049 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -68,7 +68,7 @@ static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
             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);
+        printk("Populate P2M %#"PRIx64"->%#"PRIx64"\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;
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
@@ -319,7 +319,8 @@ int construct_dom0(struct domain *d)
     gic_route_irq_to_guest(d, 47, "eth");
 
     /* Enable second stage translation */
-    WRITE_CP32(READ_CP32(HCR) | HCR_VM, HCR); isb();
+    WRITE_SYSREG(READ_SYSREG(HCR_EL2) | HCR_VM, HCR_EL2);
+    isb();
 
     /* The following loads use the domain's p2m */
     p2m_load_VTTBR(d);
@@ -337,24 +338,40 @@ int construct_dom0(struct domain *d)
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
-/* FROM LINUX head.S
-
- * Kernel startup entry point.
- * ---------------------------
- *
- * This is normally called from the decompressor code.  The requirements
- * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
- * r1 = machine nr, r2 = atags or dtb pointer.
- *...
- */
+#ifdef CONFIG_ARM_64
+    d->arch.type = kinfo.type;
+#endif
 
-    regs->r0 = 0; /* SBZ */
-    regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
-    regs->r2 = kinfo.dtb_paddr;
+    if ( is_pv32_domain(d) )
+    {
+        /* FROM LINUX head.S
+         *
+         * Kernel startup entry point.
+         * ---------------------------
+         *
+         * This is normally called from the decompressor code.  The requirements
+         * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
+         * r1 = machine nr, r2 = atags or dtb pointer.
+         *...
+         */
+        regs->r0 = 0; /* SBZ */
+        regs->r1 = 0xffffffff; /* We use DTB therefore no machine id */
+        regs->r2 = kinfo.dtb_paddr;
+    }
+#ifdef CONFIG_ARM_64
+    else
+    {
+        /* From linux/Documentation/arm64/booting.txt */
+        regs->x0 = kinfo.dtb_paddr;
+        regs->x1 = 0; /* Reserved for future use */
+        regs->x2 = 0; /* Reserved for future use */
+        regs->x3 = 0; /* Reserved for future use */
+    }
+#endif
 
-    WRITE_CP32(SCTLR_BASE, SCTLR);
+    v->arch.sctlr = SCTLR_BASE;
 
-    WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR);
+    WRITE_SYSREG(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR_EL2);
     isb();
 
     local_abort_enable();
-- 
1.7.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 Feb 22 09:03:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXl-0002Cq-W5; Fri, 22 Feb 2013 09:03: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 1U8oXh-00022X-7g
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:54051] by server-9.bemta-5.messagelabs.com id
	F0/1B-24440-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!13
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9457 invoked from network); 22 Feb 2013 09:03:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956678"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:30 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-AJ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:51 +0000
Message-ID: <1361523505-7604-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 12/46] xen: arm64: dcache 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 "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.

Abstract the actual flush operation into a macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: revert to inline asm
---
 xen/include/asm-arm/arm32/page.h |    3 +++
 xen/include/asm-arm/arm64/page.h |    3 +++
 xen/include/asm-arm/page.h       |    8 ++++----
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index a384f04..2b15c22 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 99b7296..4911ba3 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 476b00c..012ec38 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
     void *end;
     dsb();           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
-        WRITE_CP32((uint32_t) p, DCCMVAC);
+        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
     dsb();           /* So we know the flushes happen before continuing */
 }
 
@@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
         flush_xen_dcache_va_range(_p, sizeof(x));                       \
     else                                                                \
         asm volatile (                                                  \
-            "dsb;"   /* Finish all earlier writes */                    \
-            STORE_CP32(0, DCCMVAC)                                      \
-            "dsb;"   /* Finish flush before continuing */               \
+            "dsb sy;"   /* Finish all earlier writes */                 \
+            __flush_xen_dcache_one(0)                                   \
+            "dsb sy;"   /* Finish flush before continuing */            \
             : : "r" (_p), "m" (*_p));                                   \
 } while (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 Feb 22 09:03:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXl-0002Cq-W5; Fri, 22 Feb 2013 09:03: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 1U8oXh-00022X-7g
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:54051] by server-9.bemta-5.messagelabs.com id
	F0/1B-24440-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!13
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9457 invoked from network); 22 Feb 2013 09:03:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956678"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:30 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-AJ;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:51 +0000
Message-ID: <1361523505-7604-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 12/46] xen: arm64: dcache 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 "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.

Abstract the actual flush operation into a macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: revert to inline asm
---
 xen/include/asm-arm/arm32/page.h |    3 +++
 xen/include/asm-arm/arm64/page.h |    3 +++
 xen/include/asm-arm/page.h       |    8 ++++----
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index a384f04..2b15c22 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -23,6 +23,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) STORE_CP32(R, DCCMVAC)
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 99b7296..4911ba3 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -18,6 +18,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to flush dcache on register R (may be an inline asm operand) */
+#define __flush_xen_dcache_one(R) "dc cvac, %" #R ";"
+
 /*
  * Flush all hypervisor mappings from the TLB
  * This is needed after changing Xen code mappings.
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 476b00c..012ec38 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -251,7 +251,7 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
     void *end;
     dsb();           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
-        WRITE_CP32((uint32_t) p, DCCMVAC);
+        asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
     dsb();           /* So we know the flushes happen before continuing */
 }
 
@@ -264,9 +264,9 @@ static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
         flush_xen_dcache_va_range(_p, sizeof(x));                       \
     else                                                                \
         asm volatile (                                                  \
-            "dsb;"   /* Finish all earlier writes */                    \
-            STORE_CP32(0, DCCMVAC)                                      \
-            "dsb;"   /* Finish flush before continuing */               \
+            "dsb sy;"   /* Finish all earlier writes */                 \
+            __flush_xen_dcache_one(0)                                   \
+            "dsb sy;"   /* Finish flush before continuing */            \
             : : "r" (_p), "m" (*_p));                                   \
 } while (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 Feb 22 09:03:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXn-0002G6-AN; Fri, 22 Feb 2013 09:03: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 1U8oXh-00021k-DX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5920] by server-1.bemta-5.messagelabs.com id
	51/85-29263-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!14
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10294 invoked from network); 22 Feb 2013 09:03:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956722"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:35 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-6I;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:23 +0000
Message-ID: <1361523505-7604-44-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 44/46] xen: arm: print arm64 not arm32 in xen
	info when appropriate.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 836762e..600113c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -63,8 +63,13 @@ static void print_xen_info(void)
 {
     char taint_str[TAINT_STRING_MAX_LEN];
 
-    printk("----[ Xen-%d.%d%s  arm32  debug=%c  %s ]----\n",
+    printk("----[ Xen-%d.%d%s  %s  debug=%c  %s ]----\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
+#ifdef CONFIG_ARM_32
+           "arm32",
+#else
+           "arm64",
+#endif
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-- 
1.7.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 Feb 22 09:03:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXn-0002G6-AN; Fri, 22 Feb 2013 09:03: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 1U8oXh-00021k-DX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5920] by server-1.bemta-5.messagelabs.com id
	51/85-29263-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!14
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10294 invoked from network); 22 Feb 2013 09:03:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956722"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:35 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-6I;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:23 +0000
Message-ID: <1361523505-7604-44-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 44/46] xen: arm: print arm64 not arm32 in xen
	info when appropriate.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 836762e..600113c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -63,8 +63,13 @@ static void print_xen_info(void)
 {
     char taint_str[TAINT_STRING_MAX_LEN];
 
-    printk("----[ Xen-%d.%d%s  arm32  debug=%c  %s ]----\n",
+    printk("----[ Xen-%d.%d%s  %s  debug=%c  %s ]----\n",
            xen_major_version(), xen_minor_version(), xen_extra_version(),
+#ifdef CONFIG_ARM_32
+           "arm32",
+#else
+           "arm64",
+#endif
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-- 
1.7.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 Feb 22 09:03:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXp-0002LB-6i; Fri, 22 Feb 2013 09:03:53 +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 1U8oXh-00022H-Jd
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5912] by server-13.bemta-5.messagelabs.com id
	A9/32-06769-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!15
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11282 invoked from network); 22 Feb 2013 09:03:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956754"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:40 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-PD;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:09 +0000
Message-ID: <1361523505-7604-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 30/46] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

One side effect of this is that we now save the full 64-bit
TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
support LPAE guests (although this patch doesn't implement anything
other than the context switch).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Nuke XXX and rationalise naming:
 s/tpidrurw/tpidr_el0/
 s/tpidrprw/tpidr_el1/
 s/tpidruro/tpidrro_el0/
---
 xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
 xen/arch/arm/traps.c         |   14 +++---
 xen/include/asm-arm/cpregs.h |   21 +++++++-
 xen/include/asm-arm/domain.h |   29 ++++++++---
 4 files changed, 115 insertions(+), 62 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 883a681..dce7ea1 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -43,55 +43,67 @@ void idle_loop(void)
 static void ctxt_switch_from(struct vcpu *p)
 {
     /* CP 15 */
-    p->arch.csselr = READ_CP32(CSSELR);
+    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
 
     /* Control Registers */
-    p->arch.actlr = READ_CP32(ACTLR);
-    p->arch.sctlr = READ_CP32(SCTLR);
-    p->arch.cpacr = READ_CP32(CPACR);
+    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
+    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
+    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
 
-    p->arch.contextidr = READ_CP32(CONTEXTIDR);
-    p->arch.tpidrurw = READ_CP32(TPIDRURW);
-    p->arch.tpidruro = READ_CP32(TPIDRURO);
-    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
+    p->arch.tpidr_el0 = READ_SYSREG(TPIDR_EL0);
+    p->arch.tpidrro_el0 = READ_SYSREG(TPIDRRO_EL0);
+    p->arch.tpidr_el1 = READ_SYSREG(TPIDR_EL1);
 
     /* Arch timer */
     virt_timer_save(p);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     p->arch.teecr = READ_CP32(TEECR);
     p->arch.teehbr = READ_CP32(TEEHBR);
 
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
+#endif
 
     isb();
 
     /* MMU */
-    p->arch.vbar = READ_CP32(VBAR);
-    p->arch.ttbcr = READ_CP32(TTBCR);
-    /* XXX save 64 bit TTBR if guest is LPAE */
-    p->arch.ttbr0 = READ_CP32(TTBR0);
-    p->arch.ttbr1 = READ_CP32(TTBR1);
-
-    p->arch.dacr = READ_CP32(DACR);
-    p->arch.par = READ_CP64(PAR);
+    p->arch.vbar = READ_SYSREG(VBAR_EL1);
+    p->arch.ttbcr = READ_SYSREG(TCR_EL1);
+    p->arch.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    p->arch.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+    if ( is_pv32_domain(p->domain) )
+        p->arch.dacr = READ_SYSREG(DACR32_EL2);
+    p->arch.par = READ_SYSREG64(PAR_EL1);
+#if defined(CONFIG_ARM_32)
     p->arch.mair0 = READ_CP32(MAIR0);
     p->arch.mair1 = READ_CP32(MAIR1);
+#else
+    p->arch.mair = READ_SYSREG64(MAIR_EL1);
+#endif
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     p->arch.dfar = READ_CP32(DFAR);
     p->arch.ifar = READ_CP32(IFAR);
     p->arch.dfsr = READ_CP32(DFSR);
-    p->arch.ifsr = READ_CP32(IFSR);
-    p->arch.adfsr = READ_CP32(ADFSR);
-    p->arch.aifsr = READ_CP32(AIFSR);
+#elif defined(CONFIG_ARM_64)
+    p->arch.far = READ_SYSREG64(FAR_EL1);
+    p->arch.esr = READ_SYSREG64(ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(p->domain) )
+        p->arch.ifsr  = READ_SYSREG(IFSR32_EL2);
+    p->arch.afsr0 = READ_SYSREG(AFSR0_EL1);
+    p->arch.afsr1 = READ_SYSREG(AFSR1_EL1);
 
     /* XXX MPU */
 
     /* XXX VFP */
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_save_state(p);
 
     isb();
@@ -100,16 +112,16 @@ static void ctxt_switch_from(struct vcpu *p)
 
 static void ctxt_switch_to(struct vcpu *n)
 {
-    uint32_t hcr;
+    register_t hcr;
 
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
     isb();
 
     p2m_load_VTTBR(n->domain);
     isb();
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_restore_state(n);
 
     /* XXX VFP */
@@ -117,51 +129,62 @@ static void ctxt_switch_to(struct vcpu *n)
     /* XXX MPU */
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.dfar, DFAR);
     WRITE_CP32(n->arch.ifar, IFAR);
     WRITE_CP32(n->arch.dfsr, DFSR);
-    WRITE_CP32(n->arch.ifsr, IFSR);
-    WRITE_CP32(n->arch.adfsr, ADFSR);
-    WRITE_CP32(n->arch.aifsr, AIFSR);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.far, FAR_EL1);
+    WRITE_SYSREG64(n->arch.esr, ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.ifsr, IFSR32_EL2);
+    WRITE_SYSREG(n->arch.afsr0, AFSR0_EL1);
+    WRITE_SYSREG(n->arch.afsr1, AFSR1_EL1);
 
     /* MMU */
-    WRITE_CP32(n->arch.vbar, VBAR);
-    WRITE_CP32(n->arch.ttbcr, TTBCR);
-    /* XXX restore 64 bit TTBR if guest is LPAE */
-    WRITE_CP32(n->arch.ttbr0, TTBR0);
-    WRITE_CP32(n->arch.ttbr1, TTBR1);
-
-    WRITE_CP32(n->arch.dacr, DACR);
-    WRITE_CP64(n->arch.par, PAR);
+    WRITE_SYSREG(n->arch.vbar, VBAR_EL1);
+    WRITE_SYSREG(n->arch.ttbcr, TCR_EL1);
+    WRITE_SYSREG64(n->arch.ttbr0, TTBR0_EL1);
+    WRITE_SYSREG64(n->arch.ttbr1, TTBR1_EL1);
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.dacr, DACR32_EL2);
+    WRITE_SYSREG64(n->arch.par, PAR_EL1);
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.mair0, MAIR0);
     WRITE_CP32(n->arch.mair1, MAIR1);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.mair, MAIR_EL1);
+#endif
     isb();
 
     /* Control Registers */
-    WRITE_CP32(n->arch.actlr, ACTLR);
-    WRITE_CP32(n->arch.sctlr, SCTLR);
-    WRITE_CP32(n->arch.cpacr, CPACR);
+    WRITE_SYSREG(n->arch.actlr, ACTLR_EL1);
+    WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
+    WRITE_SYSREG(n->arch.cpacr, CPACR_EL1);
 
-    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
-    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
-    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
-    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+    WRITE_SYSREG(n->arch.contextidr, CONTEXTIDR_EL1);
+    WRITE_SYSREG(n->arch.tpidr_el0, TPIDR_EL0);
+    WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
+    WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     WRITE_CP32(n->arch.teecr, TEECR);
     WRITE_CP32(n->arch.teehbr, TEEHBR);
 
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
-
+#endif
     isb();
 
     /* CP 15 */
-    WRITE_CP32(n->arch.csselr, CSSELR);
+    WRITE_SYSREG(n->arch.csselr, CSSELR_EL1);
 
     isb();
 
-    WRITE_CP32(hcr, HCR);
+    WRITE_SYSREG(hcr, HCR_EL2);
     isb();
 
     /* This is could trigger an hardware interrupt from the virtual
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ccd698c..0687acf 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,8 +214,8 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 static void _show_registers(struct cpu_user_regs *regs,
                             struct reg_ctxt *ctxt,
@@ -265,7 +265,7 @@ static void _show_registers(struct cpu_user_regs *regs,
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
         printk("\n");
-        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
                ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
@@ -295,8 +295,8 @@ void show_registers(struct cpu_user_regs *regs)
     struct reg_ctxt ctxt;
     ctxt.sctlr = READ_CP32(SCTLR);
     ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP32(TTBR0);
-    ctxt.ttbr1 = READ_CP32(TTBR1);
+    ctxt.ttbr0 = READ_CP64(TTBR0);
+    ctxt.ttbr1 = READ_CP64(TTBR1);
     _show_registers(regs, &ctxt, guest_mode(regs));
 }
 
@@ -631,14 +631,14 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
-    uint32_t ttbr0 = READ_CP32(TTBR0);
+    uint64_t ttbr0 = READ_CP64(TTBR0);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
     printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
-    printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
+    printk("    TTBR0: 0x%010"PRIx64" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
 
     if ( ttbcr & TTBCR_EAE )
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 80768d9..8a66719 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -106,9 +106,9 @@
 #define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
 
 /* CP15 CR2: Translation Table Base and Control Registers */
-#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
-#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
 #define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define TTBR0           p15,0,c2        /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,1,c2        /* Translation Table Base Reg. 1 */
 #define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
 #define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
 #define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
@@ -225,10 +225,17 @@
 /* Aliases of AArch64 names for use in common code when building for AArch32 */
 #ifdef CONFIG_ARM_32
 /* Alphabetically... */
+#define ACTLR_EL1               ACTLR
+#define AFSR0_EL1               ADFSR
+#define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CONTEXTIDR_EL1          CONTEXTIDR
+#define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
+#define DACR32_EL2              DACR
 #define ESR_EL2                 HSR
+#define HCR_EL2                 HCR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
@@ -243,9 +250,19 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define IFSR32_EL2              IFSR
+#define PAR_EL1                 PAR
+#define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
+#define TCR_EL1                 TTBCR
+#define TPIDRRO_EL0             TPIDRURO
+#define TPIDR_EL0               TPIDRURW
+#define TPIDR_EL1               TPIDRPRW
 #define TPIDR_EL2               HTPIDR
+#define TTBR0_EL1               TTBR0
 #define TTBR0_EL2               HTTBR
+#define TTBR1_EL1               TTBR1
+#define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f691c26..04518b3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -133,30 +133,43 @@ struct arch_vcpu
     struct cpu_info *cpu_info;
 
     /* Fault Status */
+#ifdef CONFIG_ARM_32
+    uint32_t dfsr;
     uint32_t dfar, ifar;
-    uint32_t dfsr, ifsr;
-    uint32_t adfsr, aifsr;
+#else
+    uint64_t far;
+    uint32_t esr;
+#endif
+
+    uint32_t ifsr; /* 32-bit guests only */
+    uint32_t afsr0, afsr1;
 
     /* MMU */
-    uint32_t vbar;
+    register_t vbar;
     uint32_t ttbcr;
-    uint32_t ttbr0, ttbr1;
+    uint64_t ttbr0, ttbr1;
 
-    uint32_t dacr;
+    uint32_t dacr; /* 32-bit guests only */
     uint64_t par;
+#ifdef CONFIG_ARM_32
     uint32_t mair0, mair1;
+#else
+    uint64_t mair;
+#endif
 
     /* Control Registers */
     uint32_t actlr, sctlr;
     uint32_t cpacr;
 
     uint32_t contextidr;
-    uint32_t tpidrurw;
-    uint32_t tpidruro;
-    uint32_t tpidrprw;
+    register_t tpidr_el0;
+    register_t tpidr_el1;
+    register_t tpidrro_el0;
 
+#ifdef CONFIG_ARM_32
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
+#endif
 
     /* CP 15 */
     uint32_t csselr;
-- 
1.7.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 Feb 22 09:03:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oXp-0002LB-6i; Fri, 22 Feb 2013 09:03:53 +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 1U8oXh-00022H-Jd
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:45 +0000
Received: from [85.158.139.211:5912] by server-13.bemta-5.messagelabs.com id
	A9/32-06769-07437215; Fri, 22 Feb 2013 09:03:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!15
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11282 invoked from network); 22 Feb 2013 09:03:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956754"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:40 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-PD;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:09 +0000
Message-ID: <1361523505-7604-30-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 30/46] xen: arm: guest context switching.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

One side effect of this is that we now save the full 64-bit
TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
support LPAE guests (although this patch doesn't implement anything
other than the context switch).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
v2: Nuke XXX and rationalise naming:
 s/tpidrurw/tpidr_el0/
 s/tpidrprw/tpidr_el1/
 s/tpidruro/tpidrro_el0/
---
 xen/arch/arm/domain.c        |  113 +++++++++++++++++++++++++-----------------
 xen/arch/arm/traps.c         |   14 +++---
 xen/include/asm-arm/cpregs.h |   21 +++++++-
 xen/include/asm-arm/domain.h |   29 ++++++++---
 4 files changed, 115 insertions(+), 62 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 883a681..dce7ea1 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -43,55 +43,67 @@ void idle_loop(void)
 static void ctxt_switch_from(struct vcpu *p)
 {
     /* CP 15 */
-    p->arch.csselr = READ_CP32(CSSELR);
+    p->arch.csselr = READ_SYSREG(CSSELR_EL1);
 
     /* Control Registers */
-    p->arch.actlr = READ_CP32(ACTLR);
-    p->arch.sctlr = READ_CP32(SCTLR);
-    p->arch.cpacr = READ_CP32(CPACR);
+    p->arch.actlr = READ_SYSREG(ACTLR_EL1);
+    p->arch.sctlr = READ_SYSREG(SCTLR_EL1);
+    p->arch.cpacr = READ_SYSREG(CPACR_EL1);
 
-    p->arch.contextidr = READ_CP32(CONTEXTIDR);
-    p->arch.tpidrurw = READ_CP32(TPIDRURW);
-    p->arch.tpidruro = READ_CP32(TPIDRURO);
-    p->arch.tpidrprw = READ_CP32(TPIDRPRW);
+    p->arch.contextidr = READ_SYSREG(CONTEXTIDR_EL1);
+    p->arch.tpidr_el0 = READ_SYSREG(TPIDR_EL0);
+    p->arch.tpidrro_el0 = READ_SYSREG(TPIDRRO_EL0);
+    p->arch.tpidr_el1 = READ_SYSREG(TPIDR_EL1);
 
     /* Arch timer */
     virt_timer_save(p);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only save these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     p->arch.teecr = READ_CP32(TEECR);
     p->arch.teehbr = READ_CP32(TEEHBR);
 
     p->arch.joscr = READ_CP32(JOSCR);
     p->arch.jmcr = READ_CP32(JMCR);
+#endif
 
     isb();
 
     /* MMU */
-    p->arch.vbar = READ_CP32(VBAR);
-    p->arch.ttbcr = READ_CP32(TTBCR);
-    /* XXX save 64 bit TTBR if guest is LPAE */
-    p->arch.ttbr0 = READ_CP32(TTBR0);
-    p->arch.ttbr1 = READ_CP32(TTBR1);
-
-    p->arch.dacr = READ_CP32(DACR);
-    p->arch.par = READ_CP64(PAR);
+    p->arch.vbar = READ_SYSREG(VBAR_EL1);
+    p->arch.ttbcr = READ_SYSREG(TCR_EL1);
+    p->arch.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    p->arch.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+    if ( is_pv32_domain(p->domain) )
+        p->arch.dacr = READ_SYSREG(DACR32_EL2);
+    p->arch.par = READ_SYSREG64(PAR_EL1);
+#if defined(CONFIG_ARM_32)
     p->arch.mair0 = READ_CP32(MAIR0);
     p->arch.mair1 = READ_CP32(MAIR1);
+#else
+    p->arch.mair = READ_SYSREG64(MAIR_EL1);
+#endif
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     p->arch.dfar = READ_CP32(DFAR);
     p->arch.ifar = READ_CP32(IFAR);
     p->arch.dfsr = READ_CP32(DFSR);
-    p->arch.ifsr = READ_CP32(IFSR);
-    p->arch.adfsr = READ_CP32(ADFSR);
-    p->arch.aifsr = READ_CP32(AIFSR);
+#elif defined(CONFIG_ARM_64)
+    p->arch.far = READ_SYSREG64(FAR_EL1);
+    p->arch.esr = READ_SYSREG64(ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(p->domain) )
+        p->arch.ifsr  = READ_SYSREG(IFSR32_EL2);
+    p->arch.afsr0 = READ_SYSREG(AFSR0_EL1);
+    p->arch.afsr1 = READ_SYSREG(AFSR1_EL1);
 
     /* XXX MPU */
 
     /* XXX VFP */
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_save_state(p);
 
     isb();
@@ -100,16 +112,16 @@ static void ctxt_switch_from(struct vcpu *p)
 
 static void ctxt_switch_to(struct vcpu *n)
 {
-    uint32_t hcr;
+    register_t hcr;
 
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr & ~HCR_VM, HCR);
+    hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
     isb();
 
     p2m_load_VTTBR(n->domain);
     isb();
 
-    /* XXX VGIC */
+    /* VGIC */
     gic_restore_state(n);
 
     /* XXX VFP */
@@ -117,51 +129,62 @@ static void ctxt_switch_to(struct vcpu *n)
     /* XXX MPU */
 
     /* Fault Status */
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.dfar, DFAR);
     WRITE_CP32(n->arch.ifar, IFAR);
     WRITE_CP32(n->arch.dfsr, DFSR);
-    WRITE_CP32(n->arch.ifsr, IFSR);
-    WRITE_CP32(n->arch.adfsr, ADFSR);
-    WRITE_CP32(n->arch.aifsr, AIFSR);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.far, FAR_EL1);
+    WRITE_SYSREG64(n->arch.esr, ESR_EL1);
+#endif
+
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.ifsr, IFSR32_EL2);
+    WRITE_SYSREG(n->arch.afsr0, AFSR0_EL1);
+    WRITE_SYSREG(n->arch.afsr1, AFSR1_EL1);
 
     /* MMU */
-    WRITE_CP32(n->arch.vbar, VBAR);
-    WRITE_CP32(n->arch.ttbcr, TTBCR);
-    /* XXX restore 64 bit TTBR if guest is LPAE */
-    WRITE_CP32(n->arch.ttbr0, TTBR0);
-    WRITE_CP32(n->arch.ttbr1, TTBR1);
-
-    WRITE_CP32(n->arch.dacr, DACR);
-    WRITE_CP64(n->arch.par, PAR);
+    WRITE_SYSREG(n->arch.vbar, VBAR_EL1);
+    WRITE_SYSREG(n->arch.ttbcr, TCR_EL1);
+    WRITE_SYSREG64(n->arch.ttbr0, TTBR0_EL1);
+    WRITE_SYSREG64(n->arch.ttbr1, TTBR1_EL1);
+    if ( is_pv32_domain(n->domain) )
+        WRITE_SYSREG(n->arch.dacr, DACR32_EL2);
+    WRITE_SYSREG64(n->arch.par, PAR_EL1);
+#if defined(CONFIG_ARM_32)
     WRITE_CP32(n->arch.mair0, MAIR0);
     WRITE_CP32(n->arch.mair1, MAIR1);
+#elif defined(CONFIG_ARM_64)
+    WRITE_SYSREG64(n->arch.mair, MAIR_EL1);
+#endif
     isb();
 
     /* Control Registers */
-    WRITE_CP32(n->arch.actlr, ACTLR);
-    WRITE_CP32(n->arch.sctlr, SCTLR);
-    WRITE_CP32(n->arch.cpacr, CPACR);
+    WRITE_SYSREG(n->arch.actlr, ACTLR_EL1);
+    WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
+    WRITE_SYSREG(n->arch.cpacr, CPACR_EL1);
 
-    WRITE_CP32(n->arch.contextidr, CONTEXTIDR);
-    WRITE_CP32(n->arch.tpidrurw, TPIDRURW);
-    WRITE_CP32(n->arch.tpidruro, TPIDRURO);
-    WRITE_CP32(n->arch.tpidrprw, TPIDRPRW);
+    WRITE_SYSREG(n->arch.contextidr, CONTEXTIDR_EL1);
+    WRITE_SYSREG(n->arch.tpidr_el0, TPIDR_EL0);
+    WRITE_SYSREG(n->arch.tpidrro_el0, TPIDRRO_EL0);
+    WRITE_SYSREG(n->arch.tpidr_el1, TPIDR_EL1);
 
+#if defined(CONFIG_ARM_32)
     /* XXX only restore these if ThumbEE e.g. ID_PFR0.THUMB_EE_SUPPORT */
     WRITE_CP32(n->arch.teecr, TEECR);
     WRITE_CP32(n->arch.teehbr, TEEHBR);
 
     WRITE_CP32(n->arch.joscr, JOSCR);
     WRITE_CP32(n->arch.jmcr, JMCR);
-
+#endif
     isb();
 
     /* CP 15 */
-    WRITE_CP32(n->arch.csselr, CSSELR);
+    WRITE_SYSREG(n->arch.csselr, CSSELR_EL1);
 
     isb();
 
-    WRITE_CP32(hcr, HCR);
+    WRITE_SYSREG(hcr, HCR_EL2);
     isb();
 
     /* This is could trigger an hardware interrupt from the virtual
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ccd698c..0687acf 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,8 +214,8 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr;
-    uint32_t ttbr0, ttbr1, ttbcr;
+    uint32_t sctlr, ttbcr;
+    uint64_t ttbr0, ttbr1;
 };
 static void _show_registers(struct cpu_user_regs *regs,
                             struct reg_ctxt *ctxt,
@@ -265,7 +265,7 @@ static void _show_registers(struct cpu_user_regs *regs,
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
         printk("\n");
-        printk("TTBR0 %08"PRIx32" TTBR1 %08"PRIx32" TTBCR %08"PRIx32"\n",
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
                ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
         printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
@@ -295,8 +295,8 @@ void show_registers(struct cpu_user_regs *regs)
     struct reg_ctxt ctxt;
     ctxt.sctlr = READ_CP32(SCTLR);
     ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP32(TTBR0);
-    ctxt.ttbr1 = READ_CP32(TTBR1);
+    ctxt.ttbr0 = READ_CP64(TTBR0);
+    ctxt.ttbr1 = READ_CP64(TTBR1);
     _show_registers(regs, &ctxt, guest_mode(regs));
 }
 
@@ -631,14 +631,14 @@ static void do_cp15_64(struct cpu_user_regs *regs,
 void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
     uint32_t ttbcr = READ_CP32(TTBCR);
-    uint32_t ttbr0 = READ_CP32(TTBR0);
+    uint64_t ttbr0 = READ_CP64(TTBR0);
     paddr_t paddr;
     uint32_t offset;
     uint32_t *first = NULL, *second = NULL;
 
     printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
     printk("    TTBCR: 0x%08"PRIx32"\n", ttbcr);
-    printk("    TTBR0: 0x%08"PRIx32" = 0x%"PRIpaddr"\n",
+    printk("    TTBR0: 0x%010"PRIx64" = 0x%"PRIpaddr"\n",
            ttbr0, p2m_lookup(d, ttbr0 & PAGE_MASK));
 
     if ( ttbcr & TTBCR_EAE )
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 80768d9..8a66719 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -106,9 +106,9 @@
 #define HCR             p15,4,c1,c1,0   /* Hyp. Configuration Register */
 
 /* CP15 CR2: Translation Table Base and Control Registers */
-#define TTBR0           p15,0,c2,c0,0   /* Translation Table Base Reg. 0 */
-#define TTBR1           p15,0,c2,c0,1   /* Translation Table Base Reg. 1 */
 #define TTBCR           p15,0,c2,c0,2   /* Translatation Table Base Control Register */
+#define TTBR0           p15,0,c2        /* Translation Table Base Reg. 0 */
+#define TTBR1           p15,1,c2        /* Translation Table Base Reg. 1 */
 #define HTTBR           p15,4,c2        /* Hyp. Translation Table Base Register */
 #define HTCR            p15,4,c2,c0,2   /* Hyp. Translation Control Register */
 #define VTCR            p15,4,c2,c1,2   /* Virtualization Translation Control Register */
@@ -225,10 +225,17 @@
 /* Aliases of AArch64 names for use in common code when building for AArch32 */
 #ifdef CONFIG_ARM_32
 /* Alphabetically... */
+#define ACTLR_EL1               ACTLR
+#define AFSR0_EL1               ADFSR
+#define AFSR1_EL1               AIFSR
 #define CCSIDR_EL1              CCSIDR
 #define CLIDR_EL1               CLIDR
+#define CONTEXTIDR_EL1          CONTEXTIDR
+#define CPACR_EL1               CPACR
 #define CSSELR_EL1              CSSELR
+#define DACR32_EL2              DACR
 #define ESR_EL2                 HSR
+#define HCR_EL2                 HCR
 #define ID_AFR0_EL1             ID_AFR0
 #define ID_DFR0_EL1             ID_DFR0
 #define ID_ISAR0_EL1            ID_ISAR0
@@ -243,9 +250,19 @@
 #define ID_MMFR3_EL1            ID_MMFR3
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
+#define IFSR32_EL2              IFSR
+#define PAR_EL1                 PAR
+#define SCTLR_EL1               SCTLR
 #define SCTLR_EL2               HSCTLR
+#define TCR_EL1                 TTBCR
+#define TPIDRRO_EL0             TPIDRURO
+#define TPIDR_EL0               TPIDRURW
+#define TPIDR_EL1               TPIDRPRW
 #define TPIDR_EL2               HTPIDR
+#define TTBR0_EL1               TTBR0
 #define TTBR0_EL2               HTTBR
+#define TTBR1_EL1               TTBR1
+#define VBAR_EL1                VBAR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index f691c26..04518b3 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -133,30 +133,43 @@ struct arch_vcpu
     struct cpu_info *cpu_info;
 
     /* Fault Status */
+#ifdef CONFIG_ARM_32
+    uint32_t dfsr;
     uint32_t dfar, ifar;
-    uint32_t dfsr, ifsr;
-    uint32_t adfsr, aifsr;
+#else
+    uint64_t far;
+    uint32_t esr;
+#endif
+
+    uint32_t ifsr; /* 32-bit guests only */
+    uint32_t afsr0, afsr1;
 
     /* MMU */
-    uint32_t vbar;
+    register_t vbar;
     uint32_t ttbcr;
-    uint32_t ttbr0, ttbr1;
+    uint64_t ttbr0, ttbr1;
 
-    uint32_t dacr;
+    uint32_t dacr; /* 32-bit guests only */
     uint64_t par;
+#ifdef CONFIG_ARM_32
     uint32_t mair0, mair1;
+#else
+    uint64_t mair;
+#endif
 
     /* Control Registers */
     uint32_t actlr, sctlr;
     uint32_t cpacr;
 
     uint32_t contextidr;
-    uint32_t tpidrurw;
-    uint32_t tpidruro;
-    uint32_t tpidrprw;
+    register_t tpidr_el0;
+    register_t tpidr_el1;
+    register_t tpidrro_el0;
 
+#ifdef CONFIG_ARM_32
     uint32_t teecr, teehbr;
     uint32_t joscr, jmcr;
+#endif
 
     /* CP 15 */
     uint32_t csselr;
-- 
1.7.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 Feb 22 09:03:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXq-0002Nv-AE; Fri, 22 Feb 2013 09:03:54 +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 1U8oXi-000258-7u
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:46 +0000
Received: from [85.158.138.51:48874] by server-10.bemta-3.messagelabs.com id
	E2/BB-10609-17437215; Fri, 22 Feb 2013 09:03:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7093 invoked from network); 22 Feb 2013 09:03:43 -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;
	22 Feb 2013 09:03:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518995"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:42 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-LP;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:02 +0000
Message-ID: <1361523505-7604-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 23/46] xen: arm: add register_t type,
	native register size for the 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/smpboot.c      |    2 +-
 xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
 xen/arch/arm/vgic.c         |   18 ++++++++--------
 xen/arch/arm/vpl011.c       |    6 ++--
 xen/arch/arm/vtimer.c       |    6 ++--
 xen/include/asm-arm/regs.h  |    2 +-
 xen/include/asm-arm/types.h |    4 +++
 8 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 879a20d..f05b2df 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d9b43a8..5f0188f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 3257060..391cecc 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -68,7 +68,7 @@ static void print_xen_info(void)
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
+register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
@@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 
     switch ( reg ) {
     case 0 ... 7: /* Unbanked registers */
-        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
+        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
         return &regs->r0 + reg;
     case 8 ... 12: /* Register banked in FIQ mode */
-        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
+        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
         if ( fiq_mode(regs) )
             return &regs->r8_fiq + reg - 8;
         else
             return &regs->r8 + reg - 8;
     case 13 ... 14: /* Banked SP + LR registers */
-        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
-        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
-        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
-        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
-        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
+        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
+        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
+        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
+        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
+        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
         switch ( regs->cpsr & PSR_MODE_MASK )
         {
         case PSR_MODE_USR:
@@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
     printk("GUEST STACK GOES HERE\n");
 }
 
-#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
 
 static void show_trace(struct cpu_user_regs *regs)
 {
-    uint32_t *frame, next, addr, low, high;
+    register_t *frame, next, addr, low, high;
 
     printk("Xen call trace:\n   ");
 
@@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
     print_symbol(" %s\n   ", regs->pc);
 
     /* Bounds for range of valid frame pointer. */
-    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
     high = (low & ~(STACK_SIZE - 1)) +
         (STACK_SIZE - sizeof(struct cpu_info));
 
@@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
             break;
         {
             /* Ordinary stack frame. */
-            frame = (uint32_t *)next;
+            frame = (register_t *)next;
             next  = frame[-1];
             addr  = frame[0];
         }
@@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
         printk("[<%p>]", _p(addr));
         print_symbol(" %s\n   ", addr);
 
-        low = (uint32_t)&frame[1];
+        low = (register_t)&frame[1];
     }
 
     printk("\n");
@@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
 
 void show_stack(struct cpu_user_regs *regs)
 {
-    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
     int i;
 
     if ( guest_mode(regs) )
@@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
-    uint32_t reg, *r;
+    register_t *r;
+    uint32_t reg;
     uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = select_user_reg(regs, reg);
-        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
                domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
+        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
         break;
     case 0xfe:
-        printk("%c", (char)(regs->r0 & 0xff));
+        r = select_user_reg(regs, 0);
+        printk("%c", (char)(*r & 0xff));
         break;
     case 0xff:
         printk("DOM%d: DEBUG\n", domid);
@@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
 
     if ( !cp32.ccvalid ) {
         dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
@@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
                cp32.read ? "mrc" : "mcr",
                cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
         panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
@@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
                cp64.read ? "mrrc" : "mcrr",
                cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
         panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6ae33f6..0d24df0 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISPENDR ... GICD_ISPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
         return 0;
 
     case GICD_ICPENDR ... GICD_ICPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
         return 0;
 
@@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_SGIR:
         if ( dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
                *r, gicd_reg - GICD_ICFGR);
         return 0;
 
     case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
         return 0;
 
     case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
         return 0;
 
@@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
         goto write_ignore;
 
     default:
-        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         return 0;
     }
 
 bad_width:
-    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
            dabt.size, dabt.reg, *r, offset);
     domain_crash_synchronous();
     return 0;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index b5fdc87..9472d0a 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
         /* Silently ignore */
         return 1;
     default:
-        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         domain_crash_synchronous();
     }
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index cc9238b..802c2bc 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -105,7 +105,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
     s_time_t now;
 
     switch ( hsr.bits & HSR_CP32_REGS_MASK )
@@ -157,8 +157,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp64 cp64 = hsr.cp64;
-    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
-    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
+    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
+    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
     uint64_t ticks;
     s_time_t now;
 
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index b86ea71..093caec 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -34,7 +34,7 @@
  * Returns a pointer to the given register value in regs, taking the
  * processor mode (CPSR) into account.
  */
-extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
+extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 9c20fea..6875a62 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,6 +41,8 @@ typedef u32 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+typedef u32 register_t;
+#define PRIregister "x"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
@@ -49,6 +51,8 @@ typedef u64 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
+typedef u64 register_t;
+#define PRIregister "lx"
 #endif
 
 typedef unsigned long size_t;
-- 
1.7.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 Feb 22 09:03:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXq-0002Nv-AE; Fri, 22 Feb 2013 09:03:54 +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 1U8oXi-000258-7u
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:46 +0000
Received: from [85.158.138.51:48874] by server-10.bemta-3.messagelabs.com id
	E2/BB-10609-17437215; Fri, 22 Feb 2013 09:03:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7093 invoked from network); 22 Feb 2013 09:03:43 -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;
	22 Feb 2013 09:03:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8518995"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:42 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-LP;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:02 +0000
Message-ID: <1361523505-7604-23-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 23/46] xen: arm: add register_t type,
	native register size for the 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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
---
 xen/arch/arm/domain_build.c |    2 +-
 xen/arch/arm/smpboot.c      |    2 +-
 xen/arch/arm/traps.c        |   44 ++++++++++++++++++++++--------------------
 xen/arch/arm/vgic.c         |   18 ++++++++--------
 xen/arch/arm/vpl011.c       |    6 ++--
 xen/arch/arm/vtimer.c       |    6 ++--
 xen/include/asm-arm/regs.h  |    2 +-
 xen/include/asm-arm/types.h |    4 +++
 8 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 879a20d..f05b2df 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -268,7 +268,7 @@ static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 
 static void dtb_load(struct kernel_info *kinfo)
 {
-    void * __user dtb_virt = (void *)(u32)kinfo->dtb_paddr;
+    void * __user dtb_virt = (void *)(register_t)kinfo->dtb_paddr;
 
     raw_copy_to_guest(dtb_virt, kinfo->fdt, fdt_totalsize(kinfo->fdt));
     xfree(kinfo->fdt);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d9b43a8..5f0188f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -142,7 +142,7 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset,
     set_processor_id(cpuid);
 
     /* Setup Hyp vector base */
-    WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
+    WRITE_CP32((register_t) hyp_traps_vector, HVBAR);
 
     mmu_init_secondary_cpu();
     enable_vfp();
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 3257060..391cecc 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -68,7 +68,7 @@ static void print_xen_info(void)
            debug_build() ? 'y' : 'n', print_tainted(taint_str));
 }
 
-uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
+register_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 {
     BUG_ON( !guest_mode(regs) );
 
@@ -81,20 +81,20 @@ uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg)
 
     switch ( reg ) {
     case 0 ... 7: /* Unbanked registers */
-        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(uint32_t) != REGOFFS(r7));
+        BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
         return &regs->r0 + reg;
     case 8 ... 12: /* Register banked in FIQ mode */
-        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(uint32_t) != REGOFFS(r12_fiq));
+        BUILD_BUG_ON(REGOFFS(r8_fiq) + 4*sizeof(register_t) != REGOFFS(r12_fiq));
         if ( fiq_mode(regs) )
             return &regs->r8_fiq + reg - 8;
         else
             return &regs->r8 + reg - 8;
     case 13 ... 14: /* Banked SP + LR registers */
-        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(uint32_t) != REGOFFS(lr_fiq));
-        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(uint32_t) != REGOFFS(lr_irq));
-        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(uint32_t) != REGOFFS(lr_svc));
-        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(uint32_t) != REGOFFS(lr_abt));
-        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(uint32_t) != REGOFFS(lr_und));
+        BUILD_BUG_ON(REGOFFS(sp_fiq) + 1*sizeof(register_t) != REGOFFS(lr_fiq));
+        BUILD_BUG_ON(REGOFFS(sp_irq) + 1*sizeof(register_t) != REGOFFS(lr_irq));
+        BUILD_BUG_ON(REGOFFS(sp_svc) + 1*sizeof(register_t) != REGOFFS(lr_svc));
+        BUILD_BUG_ON(REGOFFS(sp_abt) + 1*sizeof(register_t) != REGOFFS(lr_abt));
+        BUILD_BUG_ON(REGOFFS(sp_und) + 1*sizeof(register_t) != REGOFFS(lr_und));
         switch ( regs->cpsr & PSR_MODE_MASK )
         {
         case PSR_MODE_USR:
@@ -315,11 +315,11 @@ static void show_guest_stack(struct cpu_user_regs *regs)
     printk("GUEST STACK GOES HERE\n");
 }
 
-#define STACK_BEFORE_EXCEPTION(regs) ((uint32_t*)(regs)->sp)
+#define STACK_BEFORE_EXCEPTION(regs) ((register_t*)(regs)->sp)
 
 static void show_trace(struct cpu_user_regs *regs)
 {
-    uint32_t *frame, next, addr, low, high;
+    register_t *frame, next, addr, low, high;
 
     printk("Xen call trace:\n   ");
 
@@ -327,7 +327,7 @@ static void show_trace(struct cpu_user_regs *regs)
     print_symbol(" %s\n   ", regs->pc);
 
     /* Bounds for range of valid frame pointer. */
-    low  = (uint32_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
+    low  = (register_t)(STACK_BEFORE_EXCEPTION(regs)/* - 2*/);
     high = (low & ~(STACK_SIZE - 1)) +
         (STACK_SIZE - sizeof(struct cpu_info));
 
@@ -356,7 +356,7 @@ static void show_trace(struct cpu_user_regs *regs)
             break;
         {
             /* Ordinary stack frame. */
-            frame = (uint32_t *)next;
+            frame = (register_t *)next;
             next  = frame[-1];
             addr  = frame[0];
         }
@@ -364,7 +364,7 @@ static void show_trace(struct cpu_user_regs *regs)
         printk("[<%p>]", _p(addr));
         print_symbol(" %s\n   ", addr);
 
-        low = (uint32_t)&frame[1];
+        low = (register_t)&frame[1];
     }
 
     printk("\n");
@@ -372,7 +372,7 @@ static void show_trace(struct cpu_user_regs *regs)
 
 void show_stack(struct cpu_user_regs *regs)
 {
-    uint32_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
+    register_t *stack = STACK_BEFORE_EXCEPTION(regs), addr;
     int i;
 
     if ( guest_mode(regs) )
@@ -486,20 +486,22 @@ static arm_hypercall_t arm_hypercall_table[] = {
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
 {
-    uint32_t reg, *r;
+    register_t *r;
+    uint32_t reg;
     uint32_t domid = current->domain->domain_id;
     switch ( code ) {
     case 0xe0 ... 0xef:
         reg = code - 0xe0;
         r = select_user_reg(regs, reg);
-        printk("DOM%d: R%d = %#010"PRIx32" at %#010"PRIx32"\n",
+        printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
                domid, reg, *r, regs->pc);
         break;
     case 0xfd:
-        printk("DOM%d: Reached %#010"PRIx32"\n", domid, regs->pc);
+        printk("DOM%d: Reached %"PRIvaddr"\n", domid, regs->pc);
         break;
     case 0xfe:
-        printk("%c", (char)(regs->r0 & 0xff));
+        r = select_user_reg(regs, 0);
+        printk("%c", (char)(*r & 0xff));
         break;
     case 0xff:
         printk("DOM%d: DEBUG\n", domid);
@@ -561,7 +563,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
                        union hsr hsr)
 {
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
 
     if ( !cp32.ccvalid ) {
         dprintk(XENLOG_ERR, "cp_15(32): need to handle invalid condition codes\n");
@@ -607,7 +609,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ %#08x\n",
+        printk("%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%"PRIregister"\n",
                cp32.read ? "mrc" : "mcr",
                cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs->pc);
         panic("unhandled 32-bit CP15 access %#x\n", hsr.bits & HSR_CP32_REGS_MASK);
@@ -637,7 +639,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
         BUG_ON(!vtimer_emulate(regs, hsr));
         break;
     default:
-        printk("%s p15, %d, r%d, r%d, cr%d @ %#08x\n",
+        printk("%s p15, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",
                cp64.read ? "mrrc" : "mcrr",
                cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs->pc);
         panic("unhandled 64-bit CP15 access %#x\n", hsr.bits & HSR_CP64_REGS_MASK);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6ae33f6..0d24df0 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     struct vgic_irq_rank *rank;
     int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS);
     int gicd_reg = REG(offset);
@@ -421,13 +421,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISPENDR ... GICD_ISPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ISPENDR);
         return 0;
 
     case GICD_ICPENDR ... GICD_ICPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_ICPENDR);
         return 0;
 
@@ -499,19 +499,19 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_SGIR:
         if ( dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled write %#"PRIx32" to ICFGR%d\n",
+        printk("vGICD: unhandled write %#"PRIregister" to ICFGR%d\n",
                *r, gicd_reg - GICD_ICFGR);
         return 0;
 
     case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ICPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ICPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_CPENDSGIR);
         return 0;
 
     case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        printk("vGICD: unhandled %s write %#"PRIx32" to ISPENDSGIR%d\n",
+        printk("vGICD: unhandled %s write %#"PRIregister" to ISPENDSGIR%d\n",
                dabt.size ? "word" : "byte", *r, gicd_reg - GICD_SPENDSGIR);
         return 0;
 
@@ -537,13 +537,13 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
         goto write_ignore;
 
     default:
-        printk("vGICD: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("vGICD: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         return 0;
     }
 
 bad_width:
-    printk("vGICD: bad write width %d r%d=%"PRIx32" offset %#08x\n",
+    printk("vGICD: bad write width %d r%d=%"PRIregister" offset %#08x\n",
            dabt.size, dabt.reg, *r, offset);
     domain_crash_synchronous();
     return 0;
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index b5fdc87..9472d0a 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -92,7 +92,7 @@ static int uart0_mmio_read(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -114,7 +114,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
 {
     struct hsr_dabt dabt = info->dabt;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
-    uint32_t *r = select_user_reg(regs, dabt.reg);
+    register_t *r = select_user_reg(regs, dabt.reg);
     int offset = (int)(info->gpa - UART0_START);
 
     switch ( offset )
@@ -127,7 +127,7 @@ static int uart0_mmio_write(struct vcpu *v, mmio_info_t *info)
         /* Silently ignore */
         return 1;
     default:
-        printk("VPL011: unhandled write r%d=%"PRIx32" offset %#08x\n",
+        printk("VPL011: unhandled write r%d=%"PRIregister" offset %#08x\n",
                dabt.reg, *r, offset);
         domain_crash_synchronous();
     }
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index cc9238b..802c2bc 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -105,7 +105,7 @@ static int vtimer_emulate_32(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp32 cp32 = hsr.cp32;
-    uint32_t *r = select_user_reg(regs, cp32.reg);
+    uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
     s_time_t now;
 
     switch ( hsr.bits & HSR_CP32_REGS_MASK )
@@ -157,8 +157,8 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr)
 {
     struct vcpu *v = current;
     struct hsr_cp64 cp64 = hsr.cp64;
-    uint32_t *r1 = select_user_reg(regs, cp64.reg1);
-    uint32_t *r2 = select_user_reg(regs, cp64.reg2);
+    uint32_t *r1 = (uint32_t *)select_user_reg(regs, cp64.reg1);
+    uint32_t *r2 = (uint32_t *)select_user_reg(regs, cp64.reg2);
     uint64_t ticks;
     s_time_t now;
 
diff --git a/xen/include/asm-arm/regs.h b/xen/include/asm-arm/regs.h
index b86ea71..093caec 100644
--- a/xen/include/asm-arm/regs.h
+++ b/xen/include/asm-arm/regs.h
@@ -34,7 +34,7 @@
  * Returns a pointer to the given register value in regs, taking the
  * processor mode (CPSR) into account.
  */
-extern uint32_t *select_user_reg(struct cpu_user_regs *regs, int reg);
+extern register_t *select_user_reg(struct cpu_user_regs *regs, int reg);
 
 #endif /* __ARM_REGS_H__ */
 /*
diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 9c20fea..6875a62 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,6 +41,8 @@ typedef u32 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+typedef u32 register_t;
+#define PRIregister "x"
 #elif defined (CONFIG_ARM_64)
 typedef signed long s64;
 typedef unsigned long u64;
@@ -49,6 +51,8 @@ typedef u64 vaddr_t;
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
+typedef u64 register_t;
+#define PRIregister "lx"
 #endif
 
 typedef unsigned long size_t;
-- 
1.7.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 Feb 22 09:03:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXt-0002UI-2f; Fri, 22 Feb 2013 09:03:57 +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 1U8oXm-0002Da-GF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:50 +0000
Received: from [85.158.138.51:49532] by server-4.bemta-3.messagelabs.com id
	CE/E4-17521-57437215; Fri, 22 Feb 2013 09:03:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7407 invoked from network); 22 Feb 2013 09:03:48 -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;
	22 Feb 2013 09:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8519009"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:47 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-5o;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:22 +0000
Message-ID: <1361523505-7604-43-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 43/46] xen: arm: Explicitly setup VPIDR &
	VMPIDR at start of day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 are supposed to reset to the value of the underlying hardware
but appears not to be on at least some v8 models. There's no harm in
setting them explicitly.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/setup.c         |    5 +++++
 xen/include/asm-arm/cpregs.h |    6 ++++++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f40cc7f..8326034 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,6 +56,11 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
+
+    /* Setup the virtual ID to match the physical */
+    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
+    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+
 #if defined(CONFIG_ARM_64)
     printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
            READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ae89e40..17ac1e9 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -95,6 +95,8 @@
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+#define VPIDR           p15,4,c0,c0,0   /* Virtualization Processor ID Register */
+#define VMPIDR          p15,4,c0,c0,5   /* Virtualization Multiprocessor ID Register */
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
@@ -278,6 +280,10 @@
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
+#define MIDR_EL1                MIDR
+#define VPIDR_EL2               VPIDR
+#define MPIDR_EL1               MPIDR
+#define VMPIDR_EL2              VMPIDR
 
 #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 Feb 22 09:03:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXt-0002UI-2f; Fri, 22 Feb 2013 09:03:57 +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 1U8oXm-0002Da-GF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:50 +0000
Received: from [85.158.138.51:49532] by server-4.bemta-3.messagelabs.com id
	CE/E4-17521-57437215; Fri, 22 Feb 2013 09:03:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7407 invoked from network); 22 Feb 2013 09:03:48 -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;
	22 Feb 2013 09:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8519009"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:47 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-5o;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:22 +0000
Message-ID: <1361523505-7604-43-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 43/46] xen: arm: Explicitly setup VPIDR &
	VMPIDR at start of day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 are supposed to reset to the value of the underlying hardware
but appears not to be on at least some v8 models. There's no harm in
setting them explicitly.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/setup.c         |    5 +++++
 xen/include/asm-arm/cpregs.h |    6 ++++++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f40cc7f..8326034 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -56,6 +56,11 @@ static void __init init_idle_domain(void)
 
 static void __init processor_id(void)
 {
+
+    /* Setup the virtual ID to match the physical */
+    WRITE_SYSREG32(READ_SYSREG32(MIDR_EL1), VPIDR_EL2);
+    WRITE_SYSREG(READ_SYSREG(MPIDR_EL1), VMPIDR_EL2);
+
 #if defined(CONFIG_ARM_64)
     printk("64-bit Processor Features: %016"PRIx64" %016"PRIx64"\n",
            READ_SYSREG64(ID_AA64PFR0_EL1), READ_SYSREG64(ID_AA64PFR1_EL1));
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ae89e40..17ac1e9 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -95,6 +95,8 @@
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
+#define VPIDR           p15,4,c0,c0,0   /* Virtualization Processor ID Register */
+#define VMPIDR          p15,4,c0,c0,5   /* Virtualization Multiprocessor ID Register */
 
 /* CP15 CR1: System Control Registers */
 #define SCTLR           p15,0,c1,c0,0   /* System Control Register */
@@ -278,6 +280,10 @@
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
 #define VTTBR_EL2               VTTBR
+#define MIDR_EL1                MIDR
+#define VPIDR_EL2               VPIDR
+#define MPIDR_EL1               MPIDR
+#define VMPIDR_EL2              VMPIDR
 
 #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 Feb 22 09:03:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXr-0002QF-BE; Fri, 22 Feb 2013 09:03: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 1U8oXk-00029H-AX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:48 +0000
Received: from [85.158.139.211:59145] by server-16.bemta-5.messagelabs.com id
	1D/D5-14948-37437215; Fri, 22 Feb 2013 09:03:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!16
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12045 invoked from network); 22 Feb 2013 09:03:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956778"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:45 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Dk;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:54 +0000
Message-ID: <1361523505-7604-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 15/46] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |  114 --------------------------
 3 files changed, 270 insertions(+), 114 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 1380084..276e363 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -18,6 +18,121 @@
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
 
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 53c6f96..8692a5d 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -18,6 +18,161 @@
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
 
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret, tmp;
+
+        switch (size) {
+        case 1:
+                asm volatile("//        __xchg1\n"
+                "1:     ldaxrb  %w0, [%3]\n"
+                "       stlxrb  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 2:
+                asm volatile("//        __xchg2\n"
+                "1:     ldaxrh  %w0, [%3]\n"
+                "       stlxrh  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("//        __xchg4\n"
+                "1:     ldaxr   %w0, [%3]\n"
+                "       stlxr   %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 8:
+                asm volatile("//        __xchg8\n"
+                "1:     ldaxr   %0, [%3]\n"
+                "       stlxr   %w1, %2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+
+        return ret;
+}
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
+                                      unsigned long new, int size)
+{
+        unsigned long oldval = 0, res;
+
+        switch (size) {
+        case 1:
+                do {
+                        asm volatile("// __cmpxchg1\n"
+                        "       ldxrb   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrb   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 2:
+                do {
+                        asm volatile("// __cmpxchg2\n"
+                        "       ldxrh   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrh   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "memory", "cc");
+                } while (res);
+                break;
+
+        case 4:
+                do {
+                        asm volatile("// __cmpxchg4\n"
+                        "       ldxr    %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 8:
+                do {
+                        asm volatile("// __cmpxchg8\n"
+                        "       ldxr    %1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %1, %3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        default:
+		__bad_cmpxchg(ptr, size);
+		oldval = 0;
+        }
+
+        return oldval;
+}
+
+static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
+                                         unsigned long new, int size)
+{
+        unsigned long ret;
+
+        smp_mb();
+        ret = __cmpxchg(ptr, old, new, size);
+        smp_mb();
+
+        return ret;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+        ((__typeof__(*(ptr)))__cmpxchg_mb((ptr),                        \
+                                          (unsigned long)(o),           \
+                                          (unsigned long)(n),           \
+                                          sizeof(*(ptr))))
+
+#define cmpxchg_local(ptr,o,n)                                          \
+        ((__typeof__(*(ptr)))__cmpxchg((ptr),                           \
+                                       (unsigned long)(o),              \
+                                       (unsigned long)(n),              \
+                                       sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 2acef02..f2a87d4 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,120 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-extern void __bad_xchg(volatile void *, int);
-
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
-{
-        unsigned long ret;
-        unsigned int tmp;
-
-        smp_mb();
-
-        switch (size) {
-        case 1:
-                asm volatile("@ __xchg1\n"
-                "1:     ldrexb  %0, [%3]\n"
-                "       strexb  %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        case 4:
-                asm volatile("@ __xchg4\n"
-                "1:     ldrex   %0, [%3]\n"
-                "       strex   %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        default:
-                __bad_xchg(ptr, size), ret = 0;
-                break;
-        }
-        smp_mb();
-
-        return ret;
-}
-
-/*
- * Atomic compare and exchange.  Compare OLD with MEM, if identical,
- * store NEW in MEM.  Return the initial value in MEM.  Success is
- * indicated by comparing RETURN with OLD.
- */
-
-extern void __bad_cmpxchg(volatile void *ptr, int size);
-
-static always_inline unsigned long __cmpxchg(
-    volatile void *ptr, unsigned long old, unsigned long new, int size)
-{
-    unsigned long /*long*/ oldval, res;
-
-    switch (size) {
-    case 1:
-        do {
-            asm volatile("@ __cmpxchg1\n"
-                         "       ldrexb  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexbeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 2:
-        do {
-            asm volatile("@ __cmpxchg2\n"
-                         "       ldrexh  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexheq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 4:
-        do {
-            asm volatile("@ __cmpxchg4\n"
-                         "       ldrex   %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#if 0
-    case 8:
-        do {
-            asm volatile("@ __cmpxchg8\n"
-                         "       ldrexd   %1, [%2]\n"
-                         "       mov      %0, #0\n"
-                         "       teq      %1, %3\n"
-                         "       strexdeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#endif
-    default:
-        __bad_cmpxchg(ptr, size);
-        oldval = 0;
-    }
-
-    return oldval;
-}
-#define cmpxchg(ptr,o,n)                                                \
-    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
-                                   (unsigned long)(n),sizeof(*(ptr))))
-
 #define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
 #define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
 
-- 
1.7.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 Feb 22 09:03:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:03: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 1U8oXr-0002QF-BE; Fri, 22 Feb 2013 09:03: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 1U8oXk-00029H-AX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:48 +0000
Received: from [85.158.139.211:59145] by server-16.bemta-5.messagelabs.com id
	1D/D5-14948-37437215; Fri, 22 Feb 2013 09:03:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!16
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12045 invoked from network); 22 Feb 2013 09:03:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956778"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:45 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Dk;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:57:54 +0000
Message-ID: <1361523505-7604-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 15/46] xen: arm64: xchg and cmpxchg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/arm32/system.h |  115 ++++++++++++++++++++++++++
 xen/include/asm-arm/arm64/system.h |  155 ++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/system.h       |  114 --------------------------
 3 files changed, 270 insertions(+), 114 deletions(-)

diff --git a/xen/include/asm-arm/arm32/system.h b/xen/include/asm-arm/arm32/system.h
index 1380084..276e363 100644
--- a/xen/include/asm-arm/arm32/system.h
+++ b/xen/include/asm-arm/arm32/system.h
@@ -18,6 +18,121 @@
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
 
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret;
+        unsigned int tmp;
+
+        smp_mb();
+
+        switch (size) {
+        case 1:
+                asm volatile("@ __xchg1\n"
+                "1:     ldrexb  %0, [%3]\n"
+                "       strexb  %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("@ __xchg4\n"
+                "1:     ldrex   %0, [%3]\n"
+                "       strex   %1, %2, [%3]\n"
+                "       teq     %1, #0\n"
+                "       bne     1b"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+        smp_mb();
+
+        return ret;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ */
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static always_inline unsigned long __cmpxchg(
+    volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+    unsigned long /*long*/ oldval, res;
+
+    switch (size) {
+    case 1:
+        do {
+            asm volatile("@ __cmpxchg1\n"
+                         "       ldrexb  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexbeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 2:
+        do {
+            asm volatile("@ __cmpxchg2\n"
+                         "       ldrexh  %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexheq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+    case 4:
+        do {
+            asm volatile("@ __cmpxchg4\n"
+                         "       ldrex   %1, [%2]\n"
+                         "       mov     %0, #0\n"
+                         "       teq     %1, %3\n"
+                         "       strexeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#if 0
+    case 8:
+        do {
+            asm volatile("@ __cmpxchg8\n"
+                         "       ldrexd   %1, [%2]\n"
+                         "       mov      %0, #0\n"
+                         "       teq      %1, %3\n"
+                         "       strexdeq %0, %4, [%2]\n"
+                         : "=&r" (res), "=&r" (oldval)
+                         : "r" (ptr), "Ir" (old), "r" (new)
+                         : "memory", "cc");
+        } while (res);
+        break;
+#endif
+    default:
+        __bad_cmpxchg(ptr, size);
+        oldval = 0;
+    }
+
+    return oldval;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
+                                   (unsigned long)(n),sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/system.h b/xen/include/asm-arm/arm64/system.h
index 53c6f96..8692a5d 100644
--- a/xen/include/asm-arm/arm64/system.h
+++ b/xen/include/asm-arm/arm64/system.h
@@ -18,6 +18,161 @@
 #define smp_rmb()       rmb()
 #define smp_wmb()       wmb()
 
+
+extern void __bad_xchg(volatile void *, int);
+
+static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
+{
+        unsigned long ret, tmp;
+
+        switch (size) {
+        case 1:
+                asm volatile("//        __xchg1\n"
+                "1:     ldaxrb  %w0, [%3]\n"
+                "       stlxrb  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 2:
+                asm volatile("//        __xchg2\n"
+                "1:     ldaxrh  %w0, [%3]\n"
+                "       stlxrh  %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 4:
+                asm volatile("//        __xchg4\n"
+                "1:     ldaxr   %w0, [%3]\n"
+                "       stlxr   %w1, %w2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        case 8:
+                asm volatile("//        __xchg8\n"
+                "1:     ldaxr   %0, [%3]\n"
+                "       stlxr   %w1, %2, [%3]\n"
+                "       cbnz    %w1, 1b\n"
+                        : "=&r" (ret), "=&r" (tmp)
+                        : "r" (x), "r" (ptr)
+                        : "memory", "cc");
+                break;
+        default:
+                __bad_xchg(ptr, size), ret = 0;
+                break;
+        }
+
+        return ret;
+}
+
+#define xchg(ptr,x) \
+        ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
+
+extern void __bad_cmpxchg(volatile void *ptr, int size);
+
+static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
+                                      unsigned long new, int size)
+{
+        unsigned long oldval = 0, res;
+
+        switch (size) {
+        case 1:
+                do {
+                        asm volatile("// __cmpxchg1\n"
+                        "       ldxrb   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrb   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 2:
+                do {
+                        asm volatile("// __cmpxchg2\n"
+                        "       ldxrh   %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxrh   %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "memory", "cc");
+                } while (res);
+                break;
+
+        case 4:
+                do {
+                        asm volatile("// __cmpxchg4\n"
+                        "       ldxr    %w1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %w1, %w3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %w4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        case 8:
+                do {
+                        asm volatile("// __cmpxchg8\n"
+                        "       ldxr    %1, [%2]\n"
+                        "       mov     %w0, #0\n"
+                        "       cmp     %1, %3\n"
+                        "       b.ne    1f\n"
+                        "       stxr    %w0, %4, [%2]\n"
+                        "1:\n"
+                                : "=&r" (res), "=&r" (oldval)
+                                : "r" (ptr), "Ir" (old), "r" (new)
+                                : "cc");
+                } while (res);
+                break;
+
+        default:
+		__bad_cmpxchg(ptr, size);
+		oldval = 0;
+        }
+
+        return oldval;
+}
+
+static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
+                                         unsigned long new, int size)
+{
+        unsigned long ret;
+
+        smp_mb();
+        ret = __cmpxchg(ptr, old, new, size);
+        smp_mb();
+
+        return ret;
+}
+
+#define cmpxchg(ptr,o,n)                                                \
+        ((__typeof__(*(ptr)))__cmpxchg_mb((ptr),                        \
+                                          (unsigned long)(o),           \
+                                          (unsigned long)(n),           \
+                                          sizeof(*(ptr))))
+
+#define cmpxchg_local(ptr,o,n)                                          \
+        ((__typeof__(*(ptr)))__cmpxchg((ptr),                           \
+                                       (unsigned long)(o),              \
+                                       (unsigned long)(n),              \
+                                       sizeof(*(ptr))))
+
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 2acef02..f2a87d4 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -29,120 +29,6 @@
 # error "unknown ARM variant"
 #endif
 
-extern void __bad_xchg(volatile void *, int);
-
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
-{
-        unsigned long ret;
-        unsigned int tmp;
-
-        smp_mb();
-
-        switch (size) {
-        case 1:
-                asm volatile("@ __xchg1\n"
-                "1:     ldrexb  %0, [%3]\n"
-                "       strexb  %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        case 4:
-                asm volatile("@ __xchg4\n"
-                "1:     ldrex   %0, [%3]\n"
-                "       strex   %1, %2, [%3]\n"
-                "       teq     %1, #0\n"
-                "       bne     1b"
-                        : "=&r" (ret), "=&r" (tmp)
-                        : "r" (x), "r" (ptr)
-                        : "memory", "cc");
-                break;
-        default:
-                __bad_xchg(ptr, size), ret = 0;
-                break;
-        }
-        smp_mb();
-
-        return ret;
-}
-
-/*
- * Atomic compare and exchange.  Compare OLD with MEM, if identical,
- * store NEW in MEM.  Return the initial value in MEM.  Success is
- * indicated by comparing RETURN with OLD.
- */
-
-extern void __bad_cmpxchg(volatile void *ptr, int size);
-
-static always_inline unsigned long __cmpxchg(
-    volatile void *ptr, unsigned long old, unsigned long new, int size)
-{
-    unsigned long /*long*/ oldval, res;
-
-    switch (size) {
-    case 1:
-        do {
-            asm volatile("@ __cmpxchg1\n"
-                         "       ldrexb  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexbeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 2:
-        do {
-            asm volatile("@ __cmpxchg2\n"
-                         "       ldrexh  %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexheq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-    case 4:
-        do {
-            asm volatile("@ __cmpxchg4\n"
-                         "       ldrex   %1, [%2]\n"
-                         "       mov     %0, #0\n"
-                         "       teq     %1, %3\n"
-                         "       strexeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#if 0
-    case 8:
-        do {
-            asm volatile("@ __cmpxchg8\n"
-                         "       ldrexd   %1, [%2]\n"
-                         "       mov      %0, #0\n"
-                         "       teq      %1, %3\n"
-                         "       strexdeq %0, %4, [%2]\n"
-                         : "=&r" (res), "=&r" (oldval)
-                         : "r" (ptr), "Ir" (old), "r" (new)
-                         : "memory", "cc");
-        } while (res);
-        break;
-#endif
-    default:
-        __bad_cmpxchg(ptr, size);
-        oldval = 0;
-    }
-
-    return oldval;
-}
-#define cmpxchg(ptr,o,n)                                                \
-    ((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),            \
-                                   (unsigned long)(n),sizeof(*(ptr))))
-
 #define local_irq_disable() asm volatile ( "cpsid i @ local_irq_disable\n" : : : "cc" )
 #define local_irq_enable()  asm volatile ( "cpsie i @ local_irq_enable\n" : : : "cc" )
 
-- 
1.7.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 Feb 22 09:04:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:04: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 1U8oXv-0002ag-JN; Fri, 22 Feb 2013 09:03: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 1U8oXo-0002Ig-OF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:52 +0000
Received: from [85.158.139.211:6436] by server-1.bemta-5.messagelabs.com id
	5D/B5-29263-77437215; Fri, 22 Feb 2013 09:03:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!17
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12057 invoked from network); 22 Feb 2013 09:03:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956789"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:50 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Ot;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:08 +0000
Message-ID: <1361523505-7604-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 29/46] xen: arm64: percpu variable 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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/cpregs.h |    1 +
 xen/include/asm-arm/percpu.h |    5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ccd8335..80768d9 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -244,6 +244,7 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define SCTLR_EL2               HSCTLR
+#define TPIDR_EL2               HTPIDR
 #define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
index 3a2ba11..a0c38ce 100644
--- a/xen/include/asm-arm/percpu.h
+++ b/xen/include/asm-arm/percpu.h
@@ -11,18 +11,17 @@ void percpu_init_areas(void);
     __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
-
 #define per_cpu(var, cpu)  \
     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
 #define __get_cpu_var(var) \
-    (*RELOC_HIDE(&per_cpu__##var, READ_CP32(HTPIDR)))
+    (*RELOC_HIDE(&per_cpu__##var, READ_SYSREG(TPIDR_EL2)))
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 
 DECLARE_PER_CPU(unsigned int, cpu_id);
 #define get_processor_id()    (this_cpu(cpu_id))
 #define set_processor_id(id)  do {                      \
-    WRITE_CP32(__per_cpu_offset[id], HTPIDR);           \
+    WRITE_SYSREG(__per_cpu_offset[id], TPIDR_EL2);      \
     this_cpu(cpu_id) = (id);                            \
 } while(0)
 #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 Feb 22 09:04:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:04: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 1U8oXv-0002ag-JN; Fri, 22 Feb 2013 09:03: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 1U8oXo-0002Ig-OF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:52 +0000
Received: from [85.158.139.211:6436] by server-1.bemta-5.messagelabs.com id
	5D/B5-29263-77437215; Fri, 22 Feb 2013 09:03:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!17
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12057 invoked from network); 22 Feb 2013 09:03:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956789"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:50 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Ot;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:08 +0000
Message-ID: <1361523505-7604-29-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 29/46] xen: arm64: percpu variable 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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/cpregs.h |    1 +
 xen/include/asm-arm/percpu.h |    5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index ccd8335..80768d9 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -244,6 +244,7 @@
 #define ID_PFR0_EL1             ID_PFR0
 #define ID_PFR1_EL1             ID_PFR1
 #define SCTLR_EL2               HSCTLR
+#define TPIDR_EL2               HTPIDR
 #define TTBR0_EL2               HTTBR
 #define VBAR_EL2                HVBAR
 #define VTCR_EL2                VTCR
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
index 3a2ba11..a0c38ce 100644
--- a/xen/include/asm-arm/percpu.h
+++ b/xen/include/asm-arm/percpu.h
@@ -11,18 +11,17 @@ void percpu_init_areas(void);
     __section(".bss.percpu" #suffix)                            \
     __typeof__(type) per_cpu_##name
 
-
 #define per_cpu(var, cpu)  \
     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
 #define __get_cpu_var(var) \
-    (*RELOC_HIDE(&per_cpu__##var, READ_CP32(HTPIDR)))
+    (*RELOC_HIDE(&per_cpu__##var, READ_SYSREG(TPIDR_EL2)))
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 
 DECLARE_PER_CPU(unsigned int, cpu_id);
 #define get_processor_id()    (this_cpu(cpu_id))
 #define set_processor_id(id)  do {                      \
-    WRITE_CP32(__per_cpu_offset[id], HTPIDR);           \
+    WRITE_SYSREG(__per_cpu_offset[id], TPIDR_EL2);      \
     this_cpu(cpu_id) = (id);                            \
 } while(0)
 #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 Feb 22 09:04:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:04: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 1U8oXx-0002eM-A6; Fri, 22 Feb 2013 09:04: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 1U8oXq-0002NX-KX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:54 +0000
Received: from [85.158.138.51:39669] by server-11.bemta-3.messagelabs.com id
	48/DB-10249-97437215; Fri, 22 Feb 2013 09:03:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7856 invoked from network); 22 Feb 2013 09:03:53 -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;
	22 Feb 2013 09:03:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8519022"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:52 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-4H;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:21 +0000
Message-ID: <1361523505-7604-42-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 42/46] xen: arm: Use generic mem{cpy, move,
	set, zero} on 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 optimised versions are available in Linux yet (meaning I couldn't
copy them).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/string.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
index 9cd4dd7..abfa9d2 100644
--- a/xen/include/asm-arm/string.h
+++ b/xen/include/asm-arm/string.h
@@ -3,6 +3,7 @@
 
 #include <xen/config.h>
 
+#if defined(CONFIG_ARM_32)
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);
 
@@ -27,6 +28,8 @@ extern void __memzero(void *ptr, __kernel_size_t n);
                 (__p);                                                  \
         })
 
+#endif
+
 #endif /* __ARM_STRING_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 22 09:04:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:04: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 1U8oXx-0002eM-A6; Fri, 22 Feb 2013 09:04: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 1U8oXq-0002NX-KX
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:54 +0000
Received: from [85.158.138.51:39669] by server-11.bemta-3.messagelabs.com id
	48/DB-10249-97437215; Fri, 22 Feb 2013 09:03:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7856 invoked from network); 22 Feb 2013 09:03:53 -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;
	22 Feb 2013 09:03:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8519022"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:52 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSZ-0005il-4H;
	Fri, 22 Feb 2013 08:58:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:21 +0000
Message-ID: <1361523505-7604-42-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 42/46] xen: arm: Use generic mem{cpy, move,
	set, zero} on 64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 optimised versions are available in Linux yet (meaning I couldn't
copy them).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/include/asm-arm/string.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/include/asm-arm/string.h b/xen/include/asm-arm/string.h
index 9cd4dd7..abfa9d2 100644
--- a/xen/include/asm-arm/string.h
+++ b/xen/include/asm-arm/string.h
@@ -3,6 +3,7 @@
 
 #include <xen/config.h>
 
+#if defined(CONFIG_ARM_32)
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);
 
@@ -27,6 +28,8 @@ extern void __memzero(void *ptr, __kernel_size_t n);
                 (__p);                                                  \
         })
 
+#endif
+
 #endif /* __ARM_STRING_H__ */
 /*
  * Local variables:
-- 
1.7.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 Feb 22 09:04:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8oXy-0002gS-7N; Fri, 22 Feb 2013 09:04: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 1U8oXt-0002Up-Nb
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:58 +0000
Received: from [85.158.139.211:2277] by server-5.bemta-5.messagelabs.com id
	1C/62-11945-C7437215; Fri, 22 Feb 2013 09:03:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!18
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12073 invoked from network); 22 Feb 2013 09:03:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956798"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:54 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-QM;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:10 +0000
Message-ID: <1361523505-7604-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 31/46] xen: arm: show_registers() support for
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |  176 +++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 151 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0687acf..9ed87f8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,12 +214,19 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr, ttbcr;
+    uint32_t sctlr, tcr;
     uint64_t ttbr0, ttbr1;
+#ifdef CONFIG_ARM_32
+    uint32_t dfar, ifar;
+#else
+    uint64_t far;
+#endif
 };
-static void _show_registers(struct cpu_user_regs *regs,
-                            struct reg_ctxt *ctxt,
-                            int guest_mode)
+
+static void show_registers_32(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -233,25 +240,34 @@ static void _show_registers(struct cpu_user_regs *regs,
        [PSR_MODE_SYS] = "SYS"
     };
 
-    print_xen_info();
-    printk("CPU:    %d\n", smp_processor_id());
+#ifdef CONFIG_ARM_64
+    printk("PC:     %08"PRIx32"\n", regs->pc32);
+#else
     printk("PC:     %08"PRIx32, regs->pc);
     if ( !guest_mode )
-            print_symbol(" %s", regs->pc);
+        print_symbol(" %s", regs->pc);
     printk("\n");
-    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
-           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+#endif
+    printk("CPSR:   %08"PRIx32" MODE:%s%s\n", regs->cpsr,
+           guest_mode ? "32-bit Guest " : "Hypervisor",
+           guest_mode ? mode_strings[regs->cpsr & PSR_MODE_MASK] : "");
     printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
            regs->r0, regs->r1, regs->r2, regs->r3);
     printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
            regs->r4, regs->r5, regs->r6, regs->r7);
     printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
-           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+           regs->r8, regs->r9, regs->r10,
+#ifdef CONFIG_ARM_64
+           regs->r11,
+#else
+           regs->fp,
+#endif
+           regs->r12);
 
     if ( guest_mode )
     {
-        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
-               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIregister"\n",
+               regs->sp_usr, regs->lr);
         printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
                regs->sp_svc, regs->lr_svc, regs->spsr_svc);
         printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
@@ -264,50 +280,160 @@ static void _show_registers(struct cpu_user_regs *regs,
                regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
-        printk("\n");
-        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
-               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+    }
+#ifndef CONFIG_ARM_64
+    else
+    {
+        printk("HYP: SP: %08"PRIx32" LR: %08"PRIregister"\n", regs->sp, regs->lr);
+    }
+#endif
+    printk("\n");
+
+    if ( guest_mode )
+    {
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TCR %08"PRIx32"\n",
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->tcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
-        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("IFAR %08"PRIx32" DFAR %08"PRIx32"\n",
+#ifdef CONFIG_ARM_64
+               (uint32_t)(ctxt->far >> 32),
+               (uint32_t)(ctxt->far & 0xffffffff)
+#else
+               ctxt->ifar, ctxt->dfar
+#endif
+            );
         printk("\n");
     }
-    else
+}
+
+#ifdef CONFIG_ARM_64
+static void show_registers_64(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
+{
+    printk("PC:     %016"PRIx64, regs->pc);
+    if ( !guest_mode )
+        print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("SP:     %08"PRIx64"\n", regs->sp);
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           guest_mode ? "64-bit Guest" : "Hypervisor");
+    printk("     X0: %016"PRIx64"  X1: %016"PRIx64"  X2: %016"PRIx64"\n",
+           regs->x0, regs->x1, regs->x2);
+    printk("     X3: %016"PRIx64"  X4: %016"PRIx64"  X5: %016"PRIx64"\n",
+           regs->x3, regs->x4, regs->x5);
+    printk("     X6: %016"PRIx64"  X7: %016"PRIx64"  X8: %016"PRIx64"\n",
+           regs->x6, regs->x7, regs->x8);
+    printk("     X9: %016"PRIx64" X10: %016"PRIx64" X11: %016"PRIx64"\n",
+           regs->x9, regs->x10, regs->x11);
+    printk("    X12: %016"PRIx64" X13: %016"PRIx64" X14: %016"PRIx64"\n",
+           regs->x12, regs->x13, regs->x14);
+    printk("    X15: %016"PRIx64" X16: %016"PRIx64" X17: %016"PRIx64"\n",
+           regs->x15, regs->x16, regs->x17);
+    printk("    X18: %016"PRIx64" X19: %016"PRIx64" X20: %016"PRIx64"\n",
+           regs->x18, regs->x19, regs->x20);
+    printk("    X21: %016"PRIx64" X22: %016"PRIx64" X23: %016"PRIx64"\n",
+           regs->x21, regs->x22, regs->x23);
+    printk("    X24: %016"PRIx64" X25: %016"PRIx64" X26: %016"PRIx64"\n",
+           regs->x24, regs->x25, regs->x26);
+    printk("    X27: %016"PRIx64" X28: %016"PRIx64" X29: %016"PRIx64"\n",
+           regs->x27, regs->x28, regs->lr);
+    printk("\n");
+
+    if ( guest_mode )
     {
-        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
+        printk("  TCR_EL1: %08"PRIx32"\n", ctxt->tcr);
+        printk("TTBR0_EL1: %010"PRIx64"\n", ctxt->ttbr0);
+        printk("TTBR1_EL1: %010"PRIx64"\n", ctxt->ttbr1);
+        printk("  FAR_EL1: %010"PRIx64"\n", ctxt->far);
         printk("\n");
     }
+}
+#endif
+
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode,
+                            const struct vcpu *v)
+{
+    print_xen_info();
+
+    printk("CPU:    %d\n", smp_processor_id());
+
+    if ( guest_mode )
+    {
+        if ( is_pv32_domain(v->domain) )
+            show_registers_32(regs, ctxt, guest_mode, v);
+#ifdef CONFIG_ARM_64
+        else if ( is_pv64_domain(v->domain) )
+            show_registers_64(regs, ctxt, guest_mode, v);
+#endif
+    }
+    else
+    {
+#ifdef CONFIG_ARM_64
+        show_registers_64(regs, ctxt, guest_mode, v);
+#else
+        show_registers_32(regs, ctxt, guest_mode, v);
+#endif
+    }
 
+#ifdef CONFIG_ARM_32
     printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
     printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
     printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
     printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
     printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
     printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
     printk("\n");
 
     printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
     printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
     printk("\n");
+#else
+    printk("TTBR0_EL2: %"PRIx64"\n", READ_SYSREG64(TTBR0_EL2));
+    printk("  FAR_EL2: %"PRIx64"\n", READ_SYSREG64(FAR_EL2));
+    printk("HPFAR_EL2: %"PRIx64"\n", READ_SYSREG64(HPFAR_EL2));
+    printk("  HCR_EL2: %"PRIx64"\n", READ_SYSREG64(HCR_EL2));
+    printk("  ESR_EL2: %"PRIx64"\n", READ_SYSREG64(ESR_EL2));
+    printk("VTTBR_EL2: %"PRIx64"\n", READ_SYSREG64(VTTBR_EL2));
+    printk("\n");
+#endif
 }
 
 void show_registers(struct cpu_user_regs *regs)
 {
     struct reg_ctxt ctxt;
-    ctxt.sctlr = READ_CP32(SCTLR);
-    ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP64(TTBR0);
-    ctxt.ttbr1 = READ_CP64(TTBR1);
-    _show_registers(regs, &ctxt, guest_mode(regs));
+    ctxt.sctlr = READ_SYSREG(SCTLR_EL1);
+    ctxt.tcr = READ_SYSREG(TCR_EL1);
+    ctxt.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    ctxt.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = READ_CP32(DFAR);
+    ctxt.ifar = READ_CP32(IFAR);
+#else
+    ctxt.far = READ_SYSREG(FAR_EL1);
+#endif
+    _show_registers(regs, &ctxt, guest_mode(regs), current);
 }
 
 void vcpu_show_registers(const struct vcpu *v)
 {
     struct reg_ctxt ctxt;
     ctxt.sctlr = v->arch.sctlr;
-    ctxt.ttbcr = v->arch.ttbcr;
+    ctxt.tcr = v->arch.ttbcr;
     ctxt.ttbr0 = v->arch.ttbr0;
     ctxt.ttbr1 = v->arch.ttbr1;
-    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = v->arch.dfar;
+    ctxt.ifar = v->arch.ifar;
+#else
+    ctxt.far = v->arch.far;
+#endif
+    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1, v);
 }
 
 static void show_guest_stack(struct cpu_user_regs *regs)
-- 
1.7.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 Feb 22 09:04:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8oXy-0002gS-7N; Fri, 22 Feb 2013 09:04: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 1U8oXt-0002Up-Nb
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:58 +0000
Received: from [85.158.139.211:2277] by server-5.bemta-5.messagelabs.com id
	1C/62-11945-C7437215; Fri, 22 Feb 2013 09:03:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361523755!18301163!18
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12073 invoked from network); 22 Feb 2013 09:03:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:03:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8956798"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:54 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-QM;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:10 +0000
Message-ID: <1361523505-7604-31-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 31/46] xen: arm: show_registers() support for
	64-bit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/traps.c |  176 +++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 151 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0687acf..9ed87f8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -214,12 +214,19 @@ void panic_PAR(uint64_t par)
 }
 
 struct reg_ctxt {
-    uint32_t sctlr, ttbcr;
+    uint32_t sctlr, tcr;
     uint64_t ttbr0, ttbr1;
+#ifdef CONFIG_ARM_32
+    uint32_t dfar, ifar;
+#else
+    uint64_t far;
+#endif
 };
-static void _show_registers(struct cpu_user_regs *regs,
-                            struct reg_ctxt *ctxt,
-                            int guest_mode)
+
+static void show_registers_32(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
 {
     static const char *mode_strings[] = {
        [PSR_MODE_USR] = "USR",
@@ -233,25 +240,34 @@ static void _show_registers(struct cpu_user_regs *regs,
        [PSR_MODE_SYS] = "SYS"
     };
 
-    print_xen_info();
-    printk("CPU:    %d\n", smp_processor_id());
+#ifdef CONFIG_ARM_64
+    printk("PC:     %08"PRIx32"\n", regs->pc32);
+#else
     printk("PC:     %08"PRIx32, regs->pc);
     if ( !guest_mode )
-            print_symbol(" %s", regs->pc);
+        print_symbol(" %s", regs->pc);
     printk("\n");
-    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
-           mode_strings[regs->cpsr & PSR_MODE_MASK]);
+#endif
+    printk("CPSR:   %08"PRIx32" MODE:%s%s\n", regs->cpsr,
+           guest_mode ? "32-bit Guest " : "Hypervisor",
+           guest_mode ? mode_strings[regs->cpsr & PSR_MODE_MASK] : "");
     printk("     R0: %08"PRIx32" R1: %08"PRIx32" R2: %08"PRIx32" R3: %08"PRIx32"\n",
            regs->r0, regs->r1, regs->r2, regs->r3);
     printk("     R4: %08"PRIx32" R5: %08"PRIx32" R6: %08"PRIx32" R7: %08"PRIx32"\n",
            regs->r4, regs->r5, regs->r6, regs->r7);
     printk("     R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
-           regs->r8, regs->r9, regs->r10, regs->r11, regs->r12);
+           regs->r8, regs->r9, regs->r10,
+#ifdef CONFIG_ARM_64
+           regs->r11,
+#else
+           regs->fp,
+#endif
+           regs->r12);
 
     if ( guest_mode )
     {
-        printk("USR: SP: %08"PRIx32" LR: %08"PRIx32" CPSR:%08"PRIx32"\n",
-               regs->sp_usr, regs->lr_usr, regs->cpsr);
+        printk("USR: SP: %08"PRIx32" LR: %08"PRIregister"\n",
+               regs->sp_usr, regs->lr);
         printk("SVC: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
                regs->sp_svc, regs->lr_svc, regs->spsr_svc);
         printk("ABT: SP: %08"PRIx32" LR: %08"PRIx32" SPSR:%08"PRIx32"\n",
@@ -264,50 +280,160 @@ static void _show_registers(struct cpu_user_regs *regs,
                regs->sp_fiq, regs->lr_fiq, regs->spsr_fiq);
         printk("FIQ: R8: %08"PRIx32" R9: %08"PRIx32" R10:%08"PRIx32" R11:%08"PRIx32" R12:%08"PRIx32"\n",
                regs->r8_fiq, regs->r9_fiq, regs->r10_fiq, regs->r11_fiq, regs->r11_fiq);
-        printk("\n");
-        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TTBCR %08"PRIx32"\n",
-               ctxt->ttbr0, ctxt->ttbr1, ctxt->ttbcr);
+    }
+#ifndef CONFIG_ARM_64
+    else
+    {
+        printk("HYP: SP: %08"PRIx32" LR: %08"PRIregister"\n", regs->sp, regs->lr);
+    }
+#endif
+    printk("\n");
+
+    if ( guest_mode )
+    {
+        printk("TTBR0 %010"PRIx64" TTBR1 %010"PRIx64" TCR %08"PRIx32"\n",
+               ctxt->ttbr0, ctxt->ttbr1, ctxt->tcr);
         printk("SCTLR %08"PRIx32"\n", ctxt->sctlr);
-        printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
+        printk("IFAR %08"PRIx32" DFAR %08"PRIx32"\n",
+#ifdef CONFIG_ARM_64
+               (uint32_t)(ctxt->far >> 32),
+               (uint32_t)(ctxt->far & 0xffffffff)
+#else
+               ctxt->ifar, ctxt->dfar
+#endif
+            );
         printk("\n");
     }
-    else
+}
+
+#ifdef CONFIG_ARM_64
+static void show_registers_64(struct cpu_user_regs *regs,
+                              struct reg_ctxt *ctxt,
+                              int guest_mode,
+                              const struct vcpu *v)
+{
+    printk("PC:     %016"PRIx64, regs->pc);
+    if ( !guest_mode )
+        print_symbol(" %s", regs->pc);
+    printk("\n");
+    printk("SP:     %08"PRIx64"\n", regs->sp);
+    printk("CPSR:   %08"PRIx32" MODE:%s\n", regs->cpsr,
+           guest_mode ? "64-bit Guest" : "Hypervisor");
+    printk("     X0: %016"PRIx64"  X1: %016"PRIx64"  X2: %016"PRIx64"\n",
+           regs->x0, regs->x1, regs->x2);
+    printk("     X3: %016"PRIx64"  X4: %016"PRIx64"  X5: %016"PRIx64"\n",
+           regs->x3, regs->x4, regs->x5);
+    printk("     X6: %016"PRIx64"  X7: %016"PRIx64"  X8: %016"PRIx64"\n",
+           regs->x6, regs->x7, regs->x8);
+    printk("     X9: %016"PRIx64" X10: %016"PRIx64" X11: %016"PRIx64"\n",
+           regs->x9, regs->x10, regs->x11);
+    printk("    X12: %016"PRIx64" X13: %016"PRIx64" X14: %016"PRIx64"\n",
+           regs->x12, regs->x13, regs->x14);
+    printk("    X15: %016"PRIx64" X16: %016"PRIx64" X17: %016"PRIx64"\n",
+           regs->x15, regs->x16, regs->x17);
+    printk("    X18: %016"PRIx64" X19: %016"PRIx64" X20: %016"PRIx64"\n",
+           regs->x18, regs->x19, regs->x20);
+    printk("    X21: %016"PRIx64" X22: %016"PRIx64" X23: %016"PRIx64"\n",
+           regs->x21, regs->x22, regs->x23);
+    printk("    X24: %016"PRIx64" X25: %016"PRIx64" X26: %016"PRIx64"\n",
+           regs->x24, regs->x25, regs->x26);
+    printk("    X27: %016"PRIx64" X28: %016"PRIx64" X29: %016"PRIx64"\n",
+           regs->x27, regs->x28, regs->lr);
+    printk("\n");
+
+    if ( guest_mode )
     {
-        printk("     SP: %08"PRIx32" LR: %08"PRIx32"\n", regs->sp, regs->lr);
+        printk("SCTLR_EL1: %08"PRIx32"\n", ctxt->sctlr);
+        printk("  TCR_EL1: %08"PRIx32"\n", ctxt->tcr);
+        printk("TTBR0_EL1: %010"PRIx64"\n", ctxt->ttbr0);
+        printk("TTBR1_EL1: %010"PRIx64"\n", ctxt->ttbr1);
+        printk("  FAR_EL1: %010"PRIx64"\n", ctxt->far);
         printk("\n");
     }
+}
+#endif
+
+static void _show_registers(struct cpu_user_regs *regs,
+                            struct reg_ctxt *ctxt,
+                            int guest_mode,
+                            const struct vcpu *v)
+{
+    print_xen_info();
+
+    printk("CPU:    %d\n", smp_processor_id());
+
+    if ( guest_mode )
+    {
+        if ( is_pv32_domain(v->domain) )
+            show_registers_32(regs, ctxt, guest_mode, v);
+#ifdef CONFIG_ARM_64
+        else if ( is_pv64_domain(v->domain) )
+            show_registers_64(regs, ctxt, guest_mode, v);
+#endif
+    }
+    else
+    {
+#ifdef CONFIG_ARM_64
+        show_registers_64(regs, ctxt, guest_mode, v);
+#else
+        show_registers_32(regs, ctxt, guest_mode, v);
+#endif
+    }
 
+#ifdef CONFIG_ARM_32
     printk("HTTBR %"PRIx64"\n", READ_CP64(HTTBR));
     printk("HDFAR %"PRIx32"\n", READ_CP32(HDFAR));
     printk("HIFAR %"PRIx32"\n", READ_CP32(HIFAR));
     printk("HPFAR %"PRIx32"\n", READ_CP32(HPFAR));
     printk("HCR %08"PRIx32"\n", READ_CP32(HCR));
     printk("HSR   %"PRIx32"\n", READ_CP32(HSR));
+    printk("VTTBR %010"PRIx64"\n", READ_CP64(VTTBR));
     printk("\n");
 
     printk("DFSR %"PRIx32" DFAR %"PRIx32"\n", READ_CP32(DFSR), READ_CP32(DFAR));
     printk("IFSR %"PRIx32" IFAR %"PRIx32"\n", READ_CP32(IFSR), READ_CP32(IFAR));
     printk("\n");
+#else
+    printk("TTBR0_EL2: %"PRIx64"\n", READ_SYSREG64(TTBR0_EL2));
+    printk("  FAR_EL2: %"PRIx64"\n", READ_SYSREG64(FAR_EL2));
+    printk("HPFAR_EL2: %"PRIx64"\n", READ_SYSREG64(HPFAR_EL2));
+    printk("  HCR_EL2: %"PRIx64"\n", READ_SYSREG64(HCR_EL2));
+    printk("  ESR_EL2: %"PRIx64"\n", READ_SYSREG64(ESR_EL2));
+    printk("VTTBR_EL2: %"PRIx64"\n", READ_SYSREG64(VTTBR_EL2));
+    printk("\n");
+#endif
 }
 
 void show_registers(struct cpu_user_regs *regs)
 {
     struct reg_ctxt ctxt;
-    ctxt.sctlr = READ_CP32(SCTLR);
-    ctxt.ttbcr = READ_CP32(TTBCR);
-    ctxt.ttbr0 = READ_CP64(TTBR0);
-    ctxt.ttbr1 = READ_CP64(TTBR1);
-    _show_registers(regs, &ctxt, guest_mode(regs));
+    ctxt.sctlr = READ_SYSREG(SCTLR_EL1);
+    ctxt.tcr = READ_SYSREG(TCR_EL1);
+    ctxt.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+    ctxt.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = READ_CP32(DFAR);
+    ctxt.ifar = READ_CP32(IFAR);
+#else
+    ctxt.far = READ_SYSREG(FAR_EL1);
+#endif
+    _show_registers(regs, &ctxt, guest_mode(regs), current);
 }
 
 void vcpu_show_registers(const struct vcpu *v)
 {
     struct reg_ctxt ctxt;
     ctxt.sctlr = v->arch.sctlr;
-    ctxt.ttbcr = v->arch.ttbcr;
+    ctxt.tcr = v->arch.ttbcr;
     ctxt.ttbr0 = v->arch.ttbr0;
     ctxt.ttbr1 = v->arch.ttbr1;
-    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1);
+#ifdef CONFIG_ARM_32
+    ctxt.dfar = v->arch.dfar;
+    ctxt.ifar = v->arch.ifar;
+#else
+    ctxt.far = v->arch.far;
+#endif
+    _show_registers(&v->arch.cpu_info->guest_cpu_user_regs, &ctxt, 1, v);
 }
 
 static void show_guest_stack(struct cpu_user_regs *regs)
-- 
1.7.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 Feb 22 09:04:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oY0-0002mT-Oc; Fri, 22 Feb 2013 09:04: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 1U8oXv-0002Z9-Ii
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:59 +0000
Received: from [85.158.138.51:44080] by server-5.bemta-3.messagelabs.com id
	34/96-04457-E7437215; Fri, 22 Feb 2013 09:03:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8197 invoked from network); 22 Feb 2013 09:03:57 -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;
	22 Feb 2013 09:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8519038"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:57 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Tg;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:12 +0000
Message-ID: <1361523505-7604-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 33/46] xen: arm: gic: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a84988e..41abdfb 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -267,7 +267,7 @@ static void __init gic_dist_init(void)
 
     /* Disable all global interrupts */
     for ( i = 32; i < gic.lines; i += 32 )
-        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+        GICD[GICD_ICENABLER + i / 32] = (uint32_t)~0ul;
 
     /* Turn on the distributor */
     GICD[GICD_CTLR] = GICD_CTL_ENABLE;
@@ -530,18 +530,16 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 
 static void gic_inject_irq_start(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr | HCR_VI, HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr | HCR_VI, HCR_EL2);
     isb();
 }
 
 static void gic_inject_irq_stop(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
     if (hcr & HCR_VI) {
-        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        WRITE_SYSREG(hcr & ~HCR_VI, HCR_EL2);
         isb();
     }
 }
-- 
1.7.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 Feb 22 09:04:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oY0-0002mT-Oc; Fri, 22 Feb 2013 09:04: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 1U8oXv-0002Z9-Ii
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:03:59 +0000
Received: from [85.158.138.51:44080] by server-5.bemta-3.messagelabs.com id
	34/96-04457-E7437215; Fri, 22 Feb 2013 09:03:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361523795!28660960!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDMzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8197 invoked from network); 22 Feb 2013 09:03:57 -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;
	22 Feb 2013 09:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8519038"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 09:03:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 04:03:57 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8oSY-0005il-Tg;
	Fri, 22 Feb 2013 08:58:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:12 +0000
Message-ID: <1361523505-7604-33-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v3 33/46] xen: arm: gic: use 64-bit compatible
	registers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
Acked-by: Tim Deegan <tim@xen.org>
---
 xen/arch/arm/gic.c |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a84988e..41abdfb 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -267,7 +267,7 @@ static void __init gic_dist_init(void)
 
     /* Disable all global interrupts */
     for ( i = 32; i < gic.lines; i += 32 )
-        GICD[GICD_ICENABLER + i / 32] = ~0ul;
+        GICD[GICD_ICENABLER + i / 32] = (uint32_t)~0ul;
 
     /* Turn on the distributor */
     GICD[GICD_CTLR] = GICD_CTL_ENABLE;
@@ -530,18 +530,16 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 
 static void gic_inject_irq_start(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
-    WRITE_CP32(hcr | HCR_VI, HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
+    WRITE_SYSREG(hcr | HCR_VI, HCR_EL2);
     isb();
 }
 
 static void gic_inject_irq_stop(void)
 {
-    uint32_t hcr;
-    hcr = READ_CP32(HCR);
+    register_t hcr = READ_SYSREG(HCR_EL2);
     if (hcr & HCR_VI) {
-        WRITE_CP32(hcr & ~HCR_VI, HCR);
+        WRITE_SYSREG(hcr & ~HCR_VI, HCR_EL2);
         isb();
     }
 }
-- 
1.7.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 Feb 22 09:04:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:04: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 1U8oYo-0004JL-N4; Fri, 22 Feb 2013 09:04: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 1U8oYk-00047b-Iz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:04:51 +0000
Received: from [85.158.143.99:13733] by server-3.bemta-4.messagelabs.com id
	CE/84-02186-EA437215; Fri, 22 Feb 2013 09:04:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361523871!27759467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11563 invoked from network); 22 Feb 2013 09:04:32 -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; 22 Feb 2013 09:04:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 09:04:31 +0000
Message-Id: <512742E902000078000C0454@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 09:05:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
	<1361521720.26546.93.camel@zakaz.uk.xensource.com>
	<51273EE602000078000C03DC@nat28.tlf.novell.com>
	<1361523313.26546.109.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361523313.26546.109.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir\(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-22 at 08:48 +0000, Jan Beulich wrote:
>> >>> On 22.02.13 at 09:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
>> >> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> >> >> On ARM we want these to be the same size on 32- and 64-bit.
>> >> >> 
>> >> >> This is an ABI change on ARM. X86 does not change.
>> >> >> 
>> >> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> >> >> Cc: Jan Beulich <JBeulich@suse.com>
>> >> >> Cc: Keir (Xen.org) <keir@xen.org>
>> >> > 
>> >> > Are you guys (un)happy with this change from the Xen & x86 side?
>> >> 
>> >> I don't see any problem with it.
>> > 
>> > I'll take this as an Acked-by if that's ok with you.
>> 
>> Well, I specifically didn't say "ack": I don't really mind the change,
>> but I'm also not eager see it go in. Not seeing a problem with it
>> doesn't really mean there's none lurking - type changes in public
>> interfaces are always an at least slightly risky business.
> 
> For x86 there is no change here since:
> xen/include/public/arch-x86/xen.h:typedef unsigned long xen_ulong_t;
> 
> Also the tools/include/xen-foreign checks show no change in the size of
> things on x86.

Which is why I said I see no problem with it.

> On ARM the change is deliberate, if there is any fallout we can fix it.

I understand that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:04:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:04: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 1U8oYo-0004JL-N4; Fri, 22 Feb 2013 09:04: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 1U8oYk-00047b-Iz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:04:51 +0000
Received: from [85.158.143.99:13733] by server-3.bemta-4.messagelabs.com id
	CE/84-02186-EA437215; Fri, 22 Feb 2013 09:04:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361523871!27759467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11563 invoked from network); 22 Feb 2013 09:04:32 -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; 22 Feb 2013 09:04:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 09:04:31 +0000
Message-Id: <512742E902000078000C0454@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 09:05:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361285327.1051.115.camel@zakaz.uk.xensource.com>
	<1361285363-27133-1-git-send-email-ian.campbell@citrix.com>
	<1361466961.26546.85.camel@zakaz.uk.xensource.com>
	<5127366502000078000C0380@nat28.tlf.novell.com>
	<1361521720.26546.93.camel@zakaz.uk.xensource.com>
	<51273EE602000078000C03DC@nat28.tlf.novell.com>
	<1361523313.26546.109.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361523313.26546.109.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir\(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH XEN] xen: event channel arrays are
 xen_ulong_t and not unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-22 at 08:48 +0000, Jan Beulich wrote:
>> >>> On 22.02.13 at 09:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2013-02-22 at 08:12 +0000, Jan Beulich wrote:
>> >> >>> On 21.02.13 at 18:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> > On Tue, 2013-02-19 at 14:49 +0000, Ian Campbell wrote:
>> >> >> On ARM we want these to be the same size on 32- and 64-bit.
>> >> >> 
>> >> >> This is an ABI change on ARM. X86 does not change.
>> >> >> 
>> >> >> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> >> >> Cc: Jan Beulich <JBeulich@suse.com>
>> >> >> Cc: Keir (Xen.org) <keir@xen.org>
>> >> > 
>> >> > Are you guys (un)happy with this change from the Xen & x86 side?
>> >> 
>> >> I don't see any problem with it.
>> > 
>> > I'll take this as an Acked-by if that's ok with you.
>> 
>> Well, I specifically didn't say "ack": I don't really mind the change,
>> but I'm also not eager see it go in. Not seeing a problem with it
>> doesn't really mean there's none lurking - type changes in public
>> interfaces are always an at least slightly risky business.
> 
> For x86 there is no change here since:
> xen/include/public/arch-x86/xen.h:typedef unsigned long xen_ulong_t;
> 
> Also the tools/include/xen-foreign checks show no change in the size of
> things on x86.

Which is why I said I see no problem with it.

> On ARM the change is deliberate, if there is any fallout we can fix it.

I understand that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:05:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oZ2-0004ae-6M; Fri, 22 Feb 2013 09:05: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 1U8oYx-0004Vs-Tz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:05:04 +0000
Received: from [85.158.143.99:17102] by server-3.bemta-4.messagelabs.com id
	1B/E4-02186-FB437215; Fri, 22 Feb 2013 09:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361523490!17236880!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25548 invoked from network); 22 Feb 2013 08:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1771245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:58: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.297.1;
	Fri, 22 Feb 2013 08:58:10 +0000
Message-ID: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:08 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 00/46] initial arm v8 (64-bit) 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

This round implements all of the review comments from V2 and all patches
are now acked. Unless there are any objections I intend to apply later
this morning.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:05:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8oZ2-0004ae-6M; Fri, 22 Feb 2013 09:05: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 1U8oYx-0004Vs-Tz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:05:04 +0000
Received: from [85.158.143.99:17102] by server-3.bemta-4.messagelabs.com id
	1B/E4-02186-FB437215; Fri, 22 Feb 2013 09:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361523490!17236880!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25548 invoked from network); 22 Feb 2013 08:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 08:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1771245"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 08:58: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.297.1;
	Fri, 22 Feb 2013 08:58:10 +0000
Message-ID: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 08:58:08 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v3 00/46] initial arm v8 (64-bit) 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

This round implements all of the review comments from V2 and all patches
are now acked. Unless there are any objections I intend to apply later
this morning.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:11:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:11: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 1U8oer-0006xW-4B; Fri, 22 Feb 2013 09:11:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8ggX-0001GS-OY
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 00:40:22 +0000
Received: from [85.158.137.99:26277] by server-10.bemta-3.messagelabs.com id
	06/B6-10609-47EB6215; Fri, 22 Feb 2013 00:40:20 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361493603!15155767!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30792 invoked from network); 22 Feb 2013 00:40:18 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 00:40:18 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id r1M0Y71W008312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 16:34:12 -0800
Received: (from hpa@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id r1M0Y6O8008311;
	Thu, 21 Feb 2013 16:34:06 -0800
Date: Thu, 21 Feb 2013 16:34:06 -0800
Message-Id: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
X-Authentication-Warning: terminus.zytor.com: hpa set sender to hpa@zytor.com
	using -f
From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7
	(terminus.zytor.com [127.0.0.1]);
	Thu, 21 Feb 2013 16:34:13 -0800 (PST)
X-Mailman-Approved-At: Fri, 22 Feb 2013 09:11:07 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>, gleb@redhat.com, "H. J. Lu" <hjl.tools@gmail.com>, Frederic Weisbecker <fweisbec@gmail.com>, Joe Millenbach <jmillenbach@gmail.com>, virtualization@lists.linux-foundation.org, Gokul Caushik <caushik1@gmail.com>, Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>, "H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>, Ville Syrjälä <ville.syrjala@linux.intel.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Andrea Arcangeli <aarcange@redhat.com>, Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com, Russell King <linux@arm.linux.org.uk>, Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Hugh Dickins <hughd@google.com>, Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>, Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>, Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>, avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>, Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>, Arnd Bergmann <arnd@arndb.de>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>, Josh Triplett <josh@joshtriplett.org>, Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>, Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>, Andrzej Pietrasiewicz <andrzej.p@samsung.com>, Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@intel.com>, Daniel J Blueman <daniel@numascale-asia.com>, Zachary Amsden <zamsden@gmail.com>, linux-pm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>, Pekka Enberg <penberg@kernel.org>, Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com, "Eric W. Biederman" <ebiederm@xmission.com>, Rob Landley <rob@landley.net>, Johannes Weiner <hannes@cmpxchg.org>, Andrew Morton <akpm@linux-foundation.org>, "H. Peter Anvin" <hpa@linux.intel.com>, Linus Torvalds <torvalds@linux-foundation.org>, "David S. Miller" <davem@davemloft.net>, shuahkhan@gmail.com
Subject: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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: multipart/mixed; boundary="===============4512842034443146681=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4512842034443146681==
Content-Type: text/plain

Hi Linus,

This is a huge set of several partly interrelated (and concurrently
developed) changes, which is why the branch history is messier than
one would like.

The *really* big items are two humonguous patchsets mostly developed
by Yinghai Lu at my request, which completely revamps the way we
create initial page tables.  In particular, rather than estimating how
much memory we will need for page tables and then build them into that
memory -- a calculation that has shown to be incredibly fragile -- we
now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
a #PF handler which creates temporary page tables on demand.

This has several advantages:

1. It makes it much easier to support things that need access to
   data very early (a followon patchset uses this to load microcode
   way early in the kernel startup).

2. It allows the kernel and all the kernel data objects to be invoked
   from above the 4 GB limit.  This allows kdump to work on very large
   systems.

3. It greatly reduces the difference between Xen and native (Xen's
   equivalent of the #PF handler are the temporary page tables created
   by the domain builder), eliminating a bunch of fragile hooks.

The patch series also gets us a bit closer to W^X.

Additional work in this pull is the 64-bit get_user() work which you
were also involved with, and a bunch of cleanups/speedups to
__phys_addr()/__pa().

----------------------------------------------------------------

The following changes since commit 5dcd14ecd41ea2b3ae3295a9b30d98769d52165f:

  x86, boot: Sanitize boot_params if not zeroed on creation (2013-01-29 01:22:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-for-linus

for you to fetch changes up to 0da3e7f526fde7a6522a3038b7ce609fc50f6707:

  Merge branch 'x86/mm2' into x86/mm (2013-02-15 09:25:08 -0800)

----------------------------------------------------------------

Alexander Duyck (9):
      x86: Move some contents of page_64_types.h into pgtable_64.h and page_64.h
      x86: Improve __phys_addr performance by making use of carry flags and inlining
      x86: Make it so that __pa_symbol can only process kernel symbols on x86_64
      x86: Drop 4 unnecessary calls to __pa_symbol
      x86: Use __pa_symbol instead of __pa on C visible symbols
      x86/ftrace: Use __pa_symbol instead of __pa on C visible symbols
      x86/acpi: Use __pa_symbol instead of __pa on C visible symbols
      x86/lguest: Use __pa_symbol instead of __pa on C visible symbols
      x86: Fix warning about cast from pointer to integer of different size

Borislav Petkov (1):
      x86/numa: Use __pa_nodebug() instead

Dave Hansen (6):
      x86, mm: Make DEBUG_VIRTUAL work earlier in boot
      x86, mm: Pagetable level size/shift/mask helpers
      x86, mm: Use new pagetable helpers in try_preserve_large_page()
      x86, mm: Create slow_virt_to_phys()
      x86, kvm: Fix kvm's use of __pa() on percpu areas
      x86-32, mm: Rip out x86_32 NUMA remapping code

H. Peter Anvin (13):
      Merge branch 'x86/mm' of ssh://ra.kernel.org/.../tip/tip into x86/mm
      Merge tag 'v3.8-rc5' into x86/mm
      Merge remote-tracking branch 'origin/x86/boot' into x86/mm2
      x86, 64bit: Use a #PF handler to materialize early mappings on demand
      x86-32, mm: Remove reference to resume_map_numa_kva()
      x86-32, mm: Remove reference to alloc_remap()
      Merge remote-tracking branch 'origin/x86/mm' into x86/mm2
      x86, mm: Use a bitfield to mask nuisance get_user() warnings
      x86: Be consistent with data size in getuser.S
      x86, mm: Redesign get_user with a __builtin_choose_expr hack
      x86, doc: Clarify the use of asm("%edx") in uaccess.h
      x86, mm: Move reserving low memory later in initialization
      Merge branch 'x86/mm2' into x86/mm

Ingo Molnar (1):
      x86/mm: Don't flush the TLB on #WP pmd fixups

Jacob Shin (3):
      x86, mm: if kernel .text .data .bss are not marked as E820_RAM, complain and fix
      x86, mm: Fixup code testing if a pfn is direct mapped
      x86, mm: Only direct map addresses that are marked as E820_RAM

Shuah Khan (1):
      x86/kvm: Fix compile warning in kvm_register_steal_time()

Stefano Stabellini (1):
      x86, mm: Add pointer about Xen mmu requirement for alloc_low_pages

Ville Syrjälä (1):
      x86-32: Add support for 64bit get_user()

Yinghai Lu (74):
      x86, mm: Add global page_size_mask and probe one time only
      x86, mm: Split out split_mem_range from init_memory_mapping
      x86, mm: Move down find_early_table_space()
      x86, mm: Move init_memory_mapping calling out of setup.c
      x86, mm: Revert back good_end setting for 64bit
      x86, mm: Change find_early_table_space() paramters
      x86, mm: Find early page table buffer together
      x86, mm: Separate out calculate_table_space_size()
      x86, mm: Set memblock initial limit to 1M
      x86, mm: use pfn_range_is_mapped() with CPA
      x86, mm: use pfn_range_is_mapped() with gart
      x86, mm: use pfn_range_is_mapped() with reserve_initrd
      x86, mm: relocate initrd under all mem for 64bit
      x86, mm: Align start address to correct big page size
      x86, mm: Use big page size for small memory range
      x86, mm: Don't clear page table if range is ram
      x86, mm: Break down init_all_memory_mapping
      x86, mm: setup page table in top-down
      x86, mm: Remove early_memremap workaround for page table accessing on 64bit
      x86, mm: Remove parameter in alloc_low_page for 64bit
      x86, mm: Merge alloc_low_page between 64bit and 32bit
      x86, mm: Move min_pfn_mapped back to mm/init.c
      x86, mm, Xen: Remove mapping_pagetable_reserve()
      x86, mm: Add alloc_low_pages(num)
      x86, mm: only call early_ioremap_page_table_range_init() once
      x86, mm: Move back pgt_buf_* to mm/init.c
      x86, mm: Move init_gbpages() out of setup.c
      x86, mm: change low/hignmem_pfn_init to static on 32bit
      x86, mm: Move function declaration into mm_internal.h
      x86, mm: Add check before clear pte above max_low_pfn on 32bit
      x86, mm: use round_up/down in split_mem_range()
      x86, mm: use PFN_DOWN in split_mem_range()
      x86, mm: use pfn instead of pos in split_mem_range
      x86, mm: use limit_pfn for end pfn
      x86, mm: Unifying after_bootmem for 32bit and 64bit
      x86, mm: Move after_bootmem to mm_internel.h
      x86, mm: Use clamp_t() in init_range_memory_mapping
      x86, mm: kill numa_free_all_bootmem()
      x86, mm: kill numa_64.h
      sparc, mm: Remove calling of free_all_bootmem_node()
      mm: Kill NO_BOOTMEM version free_all_bootmem_node()
      x86, mm: Let "memmap=" take more entries one time
      x86, mm: Fix page table early allocation offset checking
      x86: Factor out e820_add_kernel_range()
      x86, 64bit, mm: Make pgd next calculation consistent with pud/pmd
      x86, realmode: Set real_mode permissions early
      x86, 64bit, mm: Add generic kernel/ident mapping helper
      x86, 64bit: Copy struct boot_params early
      x86, 64bit, realmode: Use init_level4_pgt to set trampoline_pgd directly
      x86, realmode: Separate real_mode reserve and setup
      x86, 64bit: #PF handler set page to cover only 2M per #PF
      x86, 64bit: Don't set max_pfn_mapped wrong value early on native path
      x86: Merge early_reserve_initrd for 32bit and 64bit
      x86: Add get_ramdisk_image/size()
      x86, boot: Add get_cmd_line_ptr()
      x86, boot: Move checking of cmd_line_ptr out of common path
      x86, boot: Pass cmd_line_ptr with unsigned long instead
      x86, boot: Move verify_cpu.S and no_longmode down
      x86, boot: Move lldt/ltr out of 64bit code section
      x86, kexec: Remove 1024G limitation for kexec buffer on 64bit
      x86, kexec: Set ident mapping for kernel that is above max_pfn
      x86, kexec: Replace ident_mapping_init and init_level4_page
      x86, kexec, 64bit: Only set ident mapping for ram.
      x86, boot: Support loading bzImage, boot_params and ramdisk above 4G
      x86, boot: Update comments about entries for 64bit image
      x86, boot: Not need to check setup_header version for setup_data
      memblock: Add memblock_mem_size()
      x86, kdump: Remove crashkernel range find limit for 64bit
      x86: Add Crash kernel low reservation
      x86: Merge early kernel reserve for 32bit and 64bit
      x86, 64bit, mm: Mark data/bss/brk to nx
      x86, 64bit, mm: hibernate use generic mapping_init
      mm: Add alloc_bootmem_low_pages_nopanic()
      x86: Don't panic if can not alloc buffer for swiotlb

 Documentation/kernel-parameters.txt     |   3 +
 Documentation/x86/boot.txt              |  38 +++
 arch/mips/cavium-octeon/dma-octeon.c    |   3 +-
 arch/sparc/mm/init_64.c                 |  24 +-
 arch/x86/Kconfig                        |   4 -
 arch/x86/boot/boot.h                    |  18 +-
 arch/x86/boot/cmdline.c                 |  12 +-
 arch/x86/boot/compressed/cmdline.c      |  12 +-
 arch/x86/boot/compressed/head_64.S      |  48 ++--
 arch/x86/boot/header.S                  |  10 +-
 arch/x86/include/asm/init.h             |  28 +-
 arch/x86/include/asm/kexec.h            |   6 +-
 arch/x86/include/asm/mmzone_32.h        |   6 -
 arch/x86/include/asm/numa.h             |   2 -
 arch/x86/include/asm/numa_64.h          |   6 -
 arch/x86/include/asm/page.h             |   7 +-
 arch/x86/include/asm/page_32.h          |   1 +
 arch/x86/include/asm/page_64.h          |  36 +++
 arch/x86/include/asm/page_64_types.h    |  22 --
 arch/x86/include/asm/page_types.h       |   2 +
 arch/x86/include/asm/pgtable.h          |  16 ++
 arch/x86/include/asm/pgtable_64.h       |   5 +
 arch/x86/include/asm/pgtable_64_types.h |   4 +
 arch/x86/include/asm/pgtable_types.h    |   4 +-
 arch/x86/include/asm/processor.h        |   1 +
 arch/x86/include/asm/realmode.h         |   3 +-
 arch/x86/include/asm/uaccess.h          |  55 ++--
 arch/x86/include/asm/x86_init.h         |  12 -
 arch/x86/kernel/acpi/boot.c             |   1 -
 arch/x86/kernel/acpi/sleep.c            |   2 +-
 arch/x86/kernel/amd_gart_64.c           |   5 +-
 arch/x86/kernel/apic/apic_numachip.c    |   1 +
 arch/x86/kernel/cpu/amd.c               |   9 +-
 arch/x86/kernel/cpu/intel.c             |   3 +-
 arch/x86/kernel/e820.c                  |  16 +-
 arch/x86/kernel/ftrace.c                |   4 +-
 arch/x86/kernel/head32.c                |  20 --
 arch/x86/kernel/head64.c                | 131 ++++++---
 arch/x86/kernel/head_64.S               | 210 +++++++++------
 arch/x86/kernel/i386_ksyms_32.c         |   1 +
 arch/x86/kernel/kvm.c                   |  11 +-
 arch/x86/kernel/kvmclock.c              |   4 +-
 arch/x86/kernel/machine_kexec_64.c      | 171 ++++--------
 arch/x86/kernel/setup.c                 | 260 +++++++++++-------
 arch/x86/kernel/traps.c                 |   9 +
 arch/x86/kernel/x8664_ksyms_64.c        |   3 +
 arch/x86/kernel/x86_init.c              |   4 -
 arch/x86/lguest/boot.c                  |   3 +-
 arch/x86/lib/getuser.S                  |  43 ++-
 arch/x86/mm/init.c                      | 459 +++++++++++++++++++++-----------
 arch/x86/mm/init_32.c                   | 106 +++++---
 arch/x86/mm/init_64.c                   | 255 ++++++++++--------
 arch/x86/mm/mm_internal.h               |  19 ++
 arch/x86/mm/numa.c                      |  32 +--
 arch/x86/mm/numa_32.c                   | 161 -----------
 arch/x86/mm/numa_64.c                   |  13 -
 arch/x86/mm/numa_internal.h             |   6 -
 arch/x86/mm/pageattr.c                  |  66 +++--
 arch/x86/mm/pat.c                       |   4 +-
 arch/x86/mm/pgtable.c                   |   7 +-
 arch/x86/mm/physaddr.c                  |  60 +++--
 arch/x86/platform/efi/efi.c             |  11 +-
 arch/x86/power/hibernate_32.c           |   2 -
 arch/x86/power/hibernate_64.c           |  66 ++---
 arch/x86/realmode/init.c                |  49 ++--
 arch/x86/xen/mmu.c                      |  28 --
 drivers/xen/swiotlb-xen.c               |   4 +-
 include/linux/bootmem.h                 |   5 +
 include/linux/kexec.h                   |   3 +
 include/linux/memblock.h                |   1 +
 include/linux/mm.h                      |   1 -
 include/linux/swiotlb.h                 |   2 +-
 kernel/kexec.c                          |  34 ++-
 lib/swiotlb.c                           |  47 ++--
 mm/bootmem.c                            |   8 +
 mm/memblock.c                           |  17 ++
 mm/nobootmem.c                          |  23 +-
 77 files changed, 1541 insertions(+), 1247 deletions(-)

[Skipping the full diff due to size]


--===============4512842034443146681==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4512842034443146681==--

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:11:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:11: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 1U8oer-0006xW-4B; Fri, 22 Feb 2013 09:11:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8ggX-0001GS-OY
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 00:40:22 +0000
Received: from [85.158.137.99:26277] by server-10.bemta-3.messagelabs.com id
	06/B6-10609-47EB6215; Fri, 22 Feb 2013 00:40:20 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361493603!15155767!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30792 invoked from network); 22 Feb 2013 00:40:18 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 00:40:18 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id r1M0Y71W008312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 21 Feb 2013 16:34:12 -0800
Received: (from hpa@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id r1M0Y6O8008311;
	Thu, 21 Feb 2013 16:34:06 -0800
Date: Thu, 21 Feb 2013 16:34:06 -0800
Message-Id: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
X-Authentication-Warning: terminus.zytor.com: hpa set sender to hpa@zytor.com
	using -f
From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7
	(terminus.zytor.com [127.0.0.1]);
	Thu, 21 Feb 2013 16:34:13 -0800 (PST)
X-Mailman-Approved-At: Fri, 22 Feb 2013 09:11:07 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>, gleb@redhat.com, "H. J. Lu" <hjl.tools@gmail.com>, Frederic Weisbecker <fweisbec@gmail.com>, Joe Millenbach <jmillenbach@gmail.com>, virtualization@lists.linux-foundation.org, Gokul Caushik <caushik1@gmail.com>, Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>, "H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>, Ville Syrjälä <ville.syrjala@linux.intel.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Andrea Arcangeli <aarcange@redhat.com>, Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com, Russell King <linux@arm.linux.org.uk>, Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Hugh Dickins <hughd@google.com>, Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>, Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>, Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>, avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>, Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>, Arnd Bergmann <arnd@arndb.de>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>, Josh Triplett <josh@joshtriplett.org>, Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>, Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>, Andrzej Pietrasiewicz <andrzej.p@samsung.com>, Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>, Yinghai Lu <yinghai@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@intel.com>, Daniel J Blueman <daniel@numascale-asia.com>, Zachary Amsden <zamsden@gmail.com>, linux-pm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>, Pekka Enberg <penberg@kernel.org>, Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com, "Eric W. Biederman" <ebiederm@xmission.com>, Rob Landley <rob@landley.net>, Johannes Weiner <hannes@cmpxchg.org>, Andrew Morton <akpm@linux-foundation.org>, "H. Peter Anvin" <hpa@linux.intel.com>, Linus Torvalds <torvalds@linux-foundation.org>, "David S. Miller" <davem@davemloft.net>, shuahkhan@gmail.com
Subject: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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: multipart/mixed; boundary="===============4512842034443146681=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4512842034443146681==
Content-Type: text/plain

Hi Linus,

This is a huge set of several partly interrelated (and concurrently
developed) changes, which is why the branch history is messier than
one would like.

The *really* big items are two humonguous patchsets mostly developed
by Yinghai Lu at my request, which completely revamps the way we
create initial page tables.  In particular, rather than estimating how
much memory we will need for page tables and then build them into that
memory -- a calculation that has shown to be incredibly fragile -- we
now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
a #PF handler which creates temporary page tables on demand.

This has several advantages:

1. It makes it much easier to support things that need access to
   data very early (a followon patchset uses this to load microcode
   way early in the kernel startup).

2. It allows the kernel and all the kernel data objects to be invoked
   from above the 4 GB limit.  This allows kdump to work on very large
   systems.

3. It greatly reduces the difference between Xen and native (Xen's
   equivalent of the #PF handler are the temporary page tables created
   by the domain builder), eliminating a bunch of fragile hooks.

The patch series also gets us a bit closer to W^X.

Additional work in this pull is the 64-bit get_user() work which you
were also involved with, and a bunch of cleanups/speedups to
__phys_addr()/__pa().

----------------------------------------------------------------

The following changes since commit 5dcd14ecd41ea2b3ae3295a9b30d98769d52165f:

  x86, boot: Sanitize boot_params if not zeroed on creation (2013-01-29 01:22:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-for-linus

for you to fetch changes up to 0da3e7f526fde7a6522a3038b7ce609fc50f6707:

  Merge branch 'x86/mm2' into x86/mm (2013-02-15 09:25:08 -0800)

----------------------------------------------------------------

Alexander Duyck (9):
      x86: Move some contents of page_64_types.h into pgtable_64.h and page_64.h
      x86: Improve __phys_addr performance by making use of carry flags and inlining
      x86: Make it so that __pa_symbol can only process kernel symbols on x86_64
      x86: Drop 4 unnecessary calls to __pa_symbol
      x86: Use __pa_symbol instead of __pa on C visible symbols
      x86/ftrace: Use __pa_symbol instead of __pa on C visible symbols
      x86/acpi: Use __pa_symbol instead of __pa on C visible symbols
      x86/lguest: Use __pa_symbol instead of __pa on C visible symbols
      x86: Fix warning about cast from pointer to integer of different size

Borislav Petkov (1):
      x86/numa: Use __pa_nodebug() instead

Dave Hansen (6):
      x86, mm: Make DEBUG_VIRTUAL work earlier in boot
      x86, mm: Pagetable level size/shift/mask helpers
      x86, mm: Use new pagetable helpers in try_preserve_large_page()
      x86, mm: Create slow_virt_to_phys()
      x86, kvm: Fix kvm's use of __pa() on percpu areas
      x86-32, mm: Rip out x86_32 NUMA remapping code

H. Peter Anvin (13):
      Merge branch 'x86/mm' of ssh://ra.kernel.org/.../tip/tip into x86/mm
      Merge tag 'v3.8-rc5' into x86/mm
      Merge remote-tracking branch 'origin/x86/boot' into x86/mm2
      x86, 64bit: Use a #PF handler to materialize early mappings on demand
      x86-32, mm: Remove reference to resume_map_numa_kva()
      x86-32, mm: Remove reference to alloc_remap()
      Merge remote-tracking branch 'origin/x86/mm' into x86/mm2
      x86, mm: Use a bitfield to mask nuisance get_user() warnings
      x86: Be consistent with data size in getuser.S
      x86, mm: Redesign get_user with a __builtin_choose_expr hack
      x86, doc: Clarify the use of asm("%edx") in uaccess.h
      x86, mm: Move reserving low memory later in initialization
      Merge branch 'x86/mm2' into x86/mm

Ingo Molnar (1):
      x86/mm: Don't flush the TLB on #WP pmd fixups

Jacob Shin (3):
      x86, mm: if kernel .text .data .bss are not marked as E820_RAM, complain and fix
      x86, mm: Fixup code testing if a pfn is direct mapped
      x86, mm: Only direct map addresses that are marked as E820_RAM

Shuah Khan (1):
      x86/kvm: Fix compile warning in kvm_register_steal_time()

Stefano Stabellini (1):
      x86, mm: Add pointer about Xen mmu requirement for alloc_low_pages

Ville Syrjälä (1):
      x86-32: Add support for 64bit get_user()

Yinghai Lu (74):
      x86, mm: Add global page_size_mask and probe one time only
      x86, mm: Split out split_mem_range from init_memory_mapping
      x86, mm: Move down find_early_table_space()
      x86, mm: Move init_memory_mapping calling out of setup.c
      x86, mm: Revert back good_end setting for 64bit
      x86, mm: Change find_early_table_space() paramters
      x86, mm: Find early page table buffer together
      x86, mm: Separate out calculate_table_space_size()
      x86, mm: Set memblock initial limit to 1M
      x86, mm: use pfn_range_is_mapped() with CPA
      x86, mm: use pfn_range_is_mapped() with gart
      x86, mm: use pfn_range_is_mapped() with reserve_initrd
      x86, mm: relocate initrd under all mem for 64bit
      x86, mm: Align start address to correct big page size
      x86, mm: Use big page size for small memory range
      x86, mm: Don't clear page table if range is ram
      x86, mm: Break down init_all_memory_mapping
      x86, mm: setup page table in top-down
      x86, mm: Remove early_memremap workaround for page table accessing on 64bit
      x86, mm: Remove parameter in alloc_low_page for 64bit
      x86, mm: Merge alloc_low_page between 64bit and 32bit
      x86, mm: Move min_pfn_mapped back to mm/init.c
      x86, mm, Xen: Remove mapping_pagetable_reserve()
      x86, mm: Add alloc_low_pages(num)
      x86, mm: only call early_ioremap_page_table_range_init() once
      x86, mm: Move back pgt_buf_* to mm/init.c
      x86, mm: Move init_gbpages() out of setup.c
      x86, mm: change low/hignmem_pfn_init to static on 32bit
      x86, mm: Move function declaration into mm_internal.h
      x86, mm: Add check before clear pte above max_low_pfn on 32bit
      x86, mm: use round_up/down in split_mem_range()
      x86, mm: use PFN_DOWN in split_mem_range()
      x86, mm: use pfn instead of pos in split_mem_range
      x86, mm: use limit_pfn for end pfn
      x86, mm: Unifying after_bootmem for 32bit and 64bit
      x86, mm: Move after_bootmem to mm_internel.h
      x86, mm: Use clamp_t() in init_range_memory_mapping
      x86, mm: kill numa_free_all_bootmem()
      x86, mm: kill numa_64.h
      sparc, mm: Remove calling of free_all_bootmem_node()
      mm: Kill NO_BOOTMEM version free_all_bootmem_node()
      x86, mm: Let "memmap=" take more entries one time
      x86, mm: Fix page table early allocation offset checking
      x86: Factor out e820_add_kernel_range()
      x86, 64bit, mm: Make pgd next calculation consistent with pud/pmd
      x86, realmode: Set real_mode permissions early
      x86, 64bit, mm: Add generic kernel/ident mapping helper
      x86, 64bit: Copy struct boot_params early
      x86, 64bit, realmode: Use init_level4_pgt to set trampoline_pgd directly
      x86, realmode: Separate real_mode reserve and setup
      x86, 64bit: #PF handler set page to cover only 2M per #PF
      x86, 64bit: Don't set max_pfn_mapped wrong value early on native path
      x86: Merge early_reserve_initrd for 32bit and 64bit
      x86: Add get_ramdisk_image/size()
      x86, boot: Add get_cmd_line_ptr()
      x86, boot: Move checking of cmd_line_ptr out of common path
      x86, boot: Pass cmd_line_ptr with unsigned long instead
      x86, boot: Move verify_cpu.S and no_longmode down
      x86, boot: Move lldt/ltr out of 64bit code section
      x86, kexec: Remove 1024G limitation for kexec buffer on 64bit
      x86, kexec: Set ident mapping for kernel that is above max_pfn
      x86, kexec: Replace ident_mapping_init and init_level4_page
      x86, kexec, 64bit: Only set ident mapping for ram.
      x86, boot: Support loading bzImage, boot_params and ramdisk above 4G
      x86, boot: Update comments about entries for 64bit image
      x86, boot: Not need to check setup_header version for setup_data
      memblock: Add memblock_mem_size()
      x86, kdump: Remove crashkernel range find limit for 64bit
      x86: Add Crash kernel low reservation
      x86: Merge early kernel reserve for 32bit and 64bit
      x86, 64bit, mm: Mark data/bss/brk to nx
      x86, 64bit, mm: hibernate use generic mapping_init
      mm: Add alloc_bootmem_low_pages_nopanic()
      x86: Don't panic if can not alloc buffer for swiotlb

 Documentation/kernel-parameters.txt     |   3 +
 Documentation/x86/boot.txt              |  38 +++
 arch/mips/cavium-octeon/dma-octeon.c    |   3 +-
 arch/sparc/mm/init_64.c                 |  24 +-
 arch/x86/Kconfig                        |   4 -
 arch/x86/boot/boot.h                    |  18 +-
 arch/x86/boot/cmdline.c                 |  12 +-
 arch/x86/boot/compressed/cmdline.c      |  12 +-
 arch/x86/boot/compressed/head_64.S      |  48 ++--
 arch/x86/boot/header.S                  |  10 +-
 arch/x86/include/asm/init.h             |  28 +-
 arch/x86/include/asm/kexec.h            |   6 +-
 arch/x86/include/asm/mmzone_32.h        |   6 -
 arch/x86/include/asm/numa.h             |   2 -
 arch/x86/include/asm/numa_64.h          |   6 -
 arch/x86/include/asm/page.h             |   7 +-
 arch/x86/include/asm/page_32.h          |   1 +
 arch/x86/include/asm/page_64.h          |  36 +++
 arch/x86/include/asm/page_64_types.h    |  22 --
 arch/x86/include/asm/page_types.h       |   2 +
 arch/x86/include/asm/pgtable.h          |  16 ++
 arch/x86/include/asm/pgtable_64.h       |   5 +
 arch/x86/include/asm/pgtable_64_types.h |   4 +
 arch/x86/include/asm/pgtable_types.h    |   4 +-
 arch/x86/include/asm/processor.h        |   1 +
 arch/x86/include/asm/realmode.h         |   3 +-
 arch/x86/include/asm/uaccess.h          |  55 ++--
 arch/x86/include/asm/x86_init.h         |  12 -
 arch/x86/kernel/acpi/boot.c             |   1 -
 arch/x86/kernel/acpi/sleep.c            |   2 +-
 arch/x86/kernel/amd_gart_64.c           |   5 +-
 arch/x86/kernel/apic/apic_numachip.c    |   1 +
 arch/x86/kernel/cpu/amd.c               |   9 +-
 arch/x86/kernel/cpu/intel.c             |   3 +-
 arch/x86/kernel/e820.c                  |  16 +-
 arch/x86/kernel/ftrace.c                |   4 +-
 arch/x86/kernel/head32.c                |  20 --
 arch/x86/kernel/head64.c                | 131 ++++++---
 arch/x86/kernel/head_64.S               | 210 +++++++++------
 arch/x86/kernel/i386_ksyms_32.c         |   1 +
 arch/x86/kernel/kvm.c                   |  11 +-
 arch/x86/kernel/kvmclock.c              |   4 +-
 arch/x86/kernel/machine_kexec_64.c      | 171 ++++--------
 arch/x86/kernel/setup.c                 | 260 +++++++++++-------
 arch/x86/kernel/traps.c                 |   9 +
 arch/x86/kernel/x8664_ksyms_64.c        |   3 +
 arch/x86/kernel/x86_init.c              |   4 -
 arch/x86/lguest/boot.c                  |   3 +-
 arch/x86/lib/getuser.S                  |  43 ++-
 arch/x86/mm/init.c                      | 459 +++++++++++++++++++++-----------
 arch/x86/mm/init_32.c                   | 106 +++++---
 arch/x86/mm/init_64.c                   | 255 ++++++++++--------
 arch/x86/mm/mm_internal.h               |  19 ++
 arch/x86/mm/numa.c                      |  32 +--
 arch/x86/mm/numa_32.c                   | 161 -----------
 arch/x86/mm/numa_64.c                   |  13 -
 arch/x86/mm/numa_internal.h             |   6 -
 arch/x86/mm/pageattr.c                  |  66 +++--
 arch/x86/mm/pat.c                       |   4 +-
 arch/x86/mm/pgtable.c                   |   7 +-
 arch/x86/mm/physaddr.c                  |  60 +++--
 arch/x86/platform/efi/efi.c             |  11 +-
 arch/x86/power/hibernate_32.c           |   2 -
 arch/x86/power/hibernate_64.c           |  66 ++---
 arch/x86/realmode/init.c                |  49 ++--
 arch/x86/xen/mmu.c                      |  28 --
 drivers/xen/swiotlb-xen.c               |   4 +-
 include/linux/bootmem.h                 |   5 +
 include/linux/kexec.h                   |   3 +
 include/linux/memblock.h                |   1 +
 include/linux/mm.h                      |   1 -
 include/linux/swiotlb.h                 |   2 +-
 kernel/kexec.c                          |  34 ++-
 lib/swiotlb.c                           |  47 ++--
 mm/bootmem.c                            |   8 +
 mm/memblock.c                           |  17 ++
 mm/nobootmem.c                          |  23 +-
 77 files changed, 1541 insertions(+), 1247 deletions(-)

[Skipping the full diff due to size]


--===============4512842034443146681==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4512842034443146681==--

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:41:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:41: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 1U8p86-0000OG-LU; Fri, 22 Feb 2013 09:41:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8p85-0000OB-7a
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:41:21 +0000
Received: from [85.158.139.211:48522] by server-16.bemta-5.messagelabs.com id
	56/7B-14948-04D37215; Fri, 22 Feb 2013 09:41:20 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361526019!17226209!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13618 invoked from network); 22 Feb 2013 09:40:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:40:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1773619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 09:40:20 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 22 Feb 2013
	09:40:19 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 22 Feb 2013 09:40:17 +0000
Thread-Topic: [PATCH v10 1/5] gcov: Call constructors during initialization
Thread-Index: Ac4Q4J/FkvixanF6SkaknwcNrhwVKA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45839F@LONPMAILBOX01.citrite.net>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
	<1361523051.26546.106.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361523051.26546.106.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: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 08:50 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 16:13 +0000, Frediano Ziglio wrote:
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 410d7db..50e0c4b 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -84,6 +84,13 @@ SECTIONS
> >         *(.init.data)
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> > +
> > +       . = ALIGN(4);
> > +       __CTOR_LIST__ = .;
> > +       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > +       *(.ctors)
> > +       LONG(0)
> > +       __CTOR_END__ = .;
> >    } :text
> >    . = ALIGN(32);
> >    .init.setup : { 
> 
> 
> This broke my 64-bit branch (not your fault, it's not merged yet, but I
> was planning to commit it shortly):
>         prelink.o: In function `init_constructors':
>         /local/scratch/ianc/devel/arm/xen.git/xen/common/lib.c:491:(.init.text+0xc44): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `__CTOR_LIST__' defined in .init.data section in /local/scratch/ianc/devel/arm/xen.git/xen/.xen-arm64-syms.0
>         
> To fixup I intend to add the following to my "xen: arm64: initial build
> + config changes, start of day code".
> 
> Xen doesn't have a xen/xen.lds.h header, but perhaps adding that and
> using it to define common things like this as macros might be an
> interesting future cleanup.
> 
> 8<--------------------------------------
> 
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 9043994..5136b79 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -91,9 +91,9 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
>  
> -       . = ALIGN(4);
> +       . = ALIGN(BYTES_PER_LONG);
>         __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> +       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
>         *(.ctors)
>         LONG(0)
>         __CTOR_END__ = .;
> 
> 
> 
> 

Hi,
  this does not work, LONG is always 32 bit but if you use pointers
should be QUAD. Or I can change structure to be just a range of pointers
addressed by start and end, so in ld script

       . = ALIGN(8);
       __CTOR_LIST__ = .;
       *(.ctors)
       __CTOR_END__ = .;

In code:

typedef void (*ctor_func_t)(void);
extern const ctor_func_t __CTOR_LIST__[1], __CTOR_END__[1];

void __init init_constructors(void)
{
    const ctor_func_t pf = __CTOR_LIST__;
    for ( ; pf < __CTOR_END__; ++pf )
        pf();
}

This will work for both 32 and 64 bit. At this point I would rename __CTOR_LIST__ with a more "Xen" name.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:41:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09:41: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 1U8p86-0000OG-LU; Fri, 22 Feb 2013 09:41:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8p85-0000OB-7a
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:41:21 +0000
Received: from [85.158.139.211:48522] by server-16.bemta-5.messagelabs.com id
	56/7B-14948-04D37215; Fri, 22 Feb 2013 09:41:20 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361526019!17226209!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13618 invoked from network); 22 Feb 2013 09:40:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:40:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1773619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 09:40:20 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 22 Feb 2013
	09:40:19 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 22 Feb 2013 09:40:17 +0000
Thread-Topic: [PATCH v10 1/5] gcov: Call constructors during initialization
Thread-Index: Ac4Q4J/FkvixanF6SkaknwcNrhwVKA==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45839F@LONPMAILBOX01.citrite.net>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
	<1361523051.26546.106.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361523051.26546.106.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: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 08:50 +0000, Ian Campbell wrote:
> On Thu, 2013-02-21 at 16:13 +0000, Frediano Ziglio wrote:
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 410d7db..50e0c4b 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -84,6 +84,13 @@ SECTIONS
> >         *(.init.data)
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> > +
> > +       . = ALIGN(4);
> > +       __CTOR_LIST__ = .;
> > +       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > +       *(.ctors)
> > +       LONG(0)
> > +       __CTOR_END__ = .;
> >    } :text
> >    . = ALIGN(32);
> >    .init.setup : { 
> 
> 
> This broke my 64-bit branch (not your fault, it's not merged yet, but I
> was planning to commit it shortly):
>         prelink.o: In function `init_constructors':
>         /local/scratch/ianc/devel/arm/xen.git/xen/common/lib.c:491:(.init.text+0xc44): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `__CTOR_LIST__' defined in .init.data section in /local/scratch/ianc/devel/arm/xen.git/xen/.xen-arm64-syms.0
>         
> To fixup I intend to add the following to my "xen: arm64: initial build
> + config changes, start of day code".
> 
> Xen doesn't have a xen/xen.lds.h header, but perhaps adding that and
> using it to define common things like this as macros might be an
> interesting future cleanup.
> 
> 8<--------------------------------------
> 
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 9043994..5136b79 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -91,9 +91,9 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
>  
> -       . = ALIGN(4);
> +       . = ALIGN(BYTES_PER_LONG);
>         __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> +       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
>         *(.ctors)
>         LONG(0)
>         __CTOR_END__ = .;
> 
> 
> 
> 

Hi,
  this does not work, LONG is always 32 bit but if you use pointers
should be QUAD. Or I can change structure to be just a range of pointers
addressed by start and end, so in ld script

       . = ALIGN(8);
       __CTOR_LIST__ = .;
       *(.ctors)
       __CTOR_END__ = .;

In code:

typedef void (*ctor_func_t)(void);
extern const ctor_func_t __CTOR_LIST__[1], __CTOR_END__[1];

void __init init_constructors(void)
{
    const ctor_func_t pf = __CTOR_LIST__;
    for ( ; pf < __CTOR_END__; ++pf )
        pf();
}

This will work for both 32 and 64 bit. At this point I would rename __CTOR_LIST__ with a more "Xen" name.

Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:45:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8pCH-0000gL-IC; Fri, 22 Feb 2013 09:45:41 +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 1U8pCG-0000gF-Kf
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:45:40 +0000
Received: from [85.158.138.51:61161] by server-6.bemta-3.messagelabs.com id
	FA/F5-29959-34E37215; Fri, 22 Feb 2013 09:45:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361526338!27652755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16879 invoked from network); 22 Feb 2013 09:45:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1773934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 09:45: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.297.1;
	Fri, 22 Feb 2013 09:45:38 +0000
Message-ID: <1361526335.26546.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Fri, 22 Feb 2013 09:45:35 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45839F@LONPMAILBOX01.citrite.net>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
	<1361523051.26546.106.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D45839F@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 09:40 +0000, Frediano Ziglio wrote:
> On Fri, 2013-02-22 at 08:50 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-21 at 16:13 +0000, Frediano Ziglio wrote:
> > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > > index 410d7db..50e0c4b 100644
> > > --- a/xen/arch/arm/xen.lds.S
> > > +++ b/xen/arch/arm/xen.lds.S
> > > @@ -84,6 +84,13 @@ SECTIONS
> > >         *(.init.data)
> > >         *(.init.data.rel)
> > >         *(.init.data.rel.*)
> > > +
> > > +       . = ALIGN(4);
> > > +       __CTOR_LIST__ = .;
> > > +       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > > +       *(.ctors)
> > > +       LONG(0)
> > > +       __CTOR_END__ = .;
> > >    } :text
> > >    . = ALIGN(32);
> > >    .init.setup : { 
> > 
> > 
> > This broke my 64-bit branch (not your fault, it's not merged yet, but I
> > was planning to commit it shortly):
> >         prelink.o: In function `init_constructors':
> >         /local/scratch/ianc/devel/arm/xen.git/xen/common/lib.c:491:(.init.text+0xc44): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `__CTOR_LIST__' defined in .init.data section in /local/scratch/ianc/devel/arm/xen.git/xen/.xen-arm64-syms.0
> >         
> > To fixup I intend to add the following to my "xen: arm64: initial build
> > + config changes, start of day code".
> > 
> > Xen doesn't have a xen/xen.lds.h header, but perhaps adding that and
> > using it to define common things like this as macros might be an
> > interesting future cleanup.
> > 
> > 8<--------------------------------------
> > 
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 9043994..5136b79 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -91,9 +91,9 @@ SECTIONS
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> >  
> > -       . = ALIGN(4);
> > +       . = ALIGN(BYTES_PER_LONG);
> >         __CTOR_LIST__ = .;
> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > +       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
> >         *(.ctors)
> >         LONG(0)
> >         __CTOR_END__ = .;
> > 
> > 
> > 
> > 
> 
> Hi,
>   this does not work, LONG is always 32 bit

Yes, I'm just discovering that ;-)

> but if you use pointers should be QUAD. Or I can change structure to be just a range of pointers
> addressed by start and end, so in ld script
> 
>        . = ALIGN(8);
>        __CTOR_LIST__ = .;
>        *(.ctors)
>        __CTOR_END__ = .;
> 
> In code:
> 
> typedef void (*ctor_func_t)(void);
> extern const ctor_func_t __CTOR_LIST__[1], __CTOR_END__[1];
> 
> void __init init_constructors(void)
> {
>     const ctor_func_t pf = __CTOR_LIST__;
>     for ( ; pf < __CTOR_END__; ++pf )
>         pf();
> }
> 
> This will work for both 32 and 64 bit. At this point I would rename __CTOR_LIST__ with a more "Xen" name.

Let me play with something along these lines. I'll send out a patch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 09:45:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 09: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 1U8pCH-0000gL-IC; Fri, 22 Feb 2013 09:45:41 +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 1U8pCG-0000gF-Kf
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 09:45:40 +0000
Received: from [85.158.138.51:61161] by server-6.bemta-3.messagelabs.com id
	FA/F5-29959-34E37215; Fri, 22 Feb 2013 09:45:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361526338!27652755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16879 invoked from network); 22 Feb 2013 09:45:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 09:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1773934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 09:45: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.297.1;
	Fri, 22 Feb 2013 09:45:38 +0000
Message-ID: <1361526335.26546.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Fri, 22 Feb 2013 09:45:35 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D45839F@LONPMAILBOX01.citrite.net>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<1361463225-21750-2-git-send-email-frediano.ziglio@citrix.com>
	<1361523051.26546.106.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D45839F@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v10 1/5] gcov: Call constructors during
	initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 09:40 +0000, Frediano Ziglio wrote:
> On Fri, 2013-02-22 at 08:50 +0000, Ian Campbell wrote:
> > On Thu, 2013-02-21 at 16:13 +0000, Frediano Ziglio wrote:
> > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > > index 410d7db..50e0c4b 100644
> > > --- a/xen/arch/arm/xen.lds.S
> > > +++ b/xen/arch/arm/xen.lds.S
> > > @@ -84,6 +84,13 @@ SECTIONS
> > >         *(.init.data)
> > >         *(.init.data.rel)
> > >         *(.init.data.rel.*)
> > > +
> > > +       . = ALIGN(4);
> > > +       __CTOR_LIST__ = .;
> > > +       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > > +       *(.ctors)
> > > +       LONG(0)
> > > +       __CTOR_END__ = .;
> > >    } :text
> > >    . = ALIGN(32);
> > >    .init.setup : { 
> > 
> > 
> > This broke my 64-bit branch (not your fault, it's not merged yet, but I
> > was planning to commit it shortly):
> >         prelink.o: In function `init_constructors':
> >         /local/scratch/ianc/devel/arm/xen.git/xen/common/lib.c:491:(.init.text+0xc44): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `__CTOR_LIST__' defined in .init.data section in /local/scratch/ianc/devel/arm/xen.git/xen/.xen-arm64-syms.0
> >         
> > To fixup I intend to add the following to my "xen: arm64: initial build
> > + config changes, start of day code".
> > 
> > Xen doesn't have a xen/xen.lds.h header, but perhaps adding that and
> > using it to define common things like this as macros might be an
> > interesting future cleanup.
> > 
> > 8<--------------------------------------
> > 
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 9043994..5136b79 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -91,9 +91,9 @@ SECTIONS
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> >  
> > -       . = ALIGN(4);
> > +       . = ALIGN(BYTES_PER_LONG);
> >         __CTOR_LIST__ = .;
> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > +       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
> >         *(.ctors)
> >         LONG(0)
> >         __CTOR_END__ = .;
> > 
> > 
> > 
> > 
> 
> Hi,
>   this does not work, LONG is always 32 bit

Yes, I'm just discovering that ;-)

> but if you use pointers should be QUAD. Or I can change structure to be just a range of pointers
> addressed by start and end, so in ld script
> 
>        . = ALIGN(8);
>        __CTOR_LIST__ = .;
>        *(.ctors)
>        __CTOR_END__ = .;
> 
> In code:
> 
> typedef void (*ctor_func_t)(void);
> extern const ctor_func_t __CTOR_LIST__[1], __CTOR_END__[1];
> 
> void __init init_constructors(void)
> {
>     const ctor_func_t pf = __CTOR_LIST__;
>     for ( ; pf < __CTOR_END__; ++pf )
>         pf();
> }
> 
> This will work for both 32 and 64 bit. At this point I would rename __CTOR_LIST__ with a more "Xen" name.

Let me play with something along these lines. I'll send out a patch.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 10:47:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 10: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 1U8q9i-0002du-8x; Fri, 22 Feb 2013 10:47: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 1U8q9g-0002dp-EE
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 10:47:04 +0000
Received: from [193.109.254.147:15616] by server-10.bemta-14.messagelabs.com
	id B0/19-12679-7AC47215; Fri, 22 Feb 2013 10:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361530022!8726752!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7832 invoked from network); 22 Feb 2013 10:47:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 10:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1777314"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 10:47: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.297.1;
	Fri, 22 Feb 2013 10:47:02 +0000
Message-ID: <1361530021.26546.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 10:47:01 +0000
In-Reply-To: <1361523505-7604-5-git-send-email-ian.campbell@citrix.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
	<1361523505-7604-5-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v3 05/46] xen: arm64: initial build + config
 changes, start of day 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 Fri, 2013-02-22 at 08:57 +0000, Ian Campbell wrote:
> @@ -85,9 +91,9 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
> 
> -       . = ALIGN(4);
> +       . = ALIGN(BYTES_PER_LONG);
>         __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> +       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
>         *(.ctors)
>         LONG(0)
>         __CTOR_END__ = .; 

This hunk is incorrect. I'll drop it and post a fix for coverage on
ARM64 separately.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 10:47:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 10: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 1U8q9i-0002du-8x; Fri, 22 Feb 2013 10:47: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 1U8q9g-0002dp-EE
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 10:47:04 +0000
Received: from [193.109.254.147:15616] by server-10.bemta-14.messagelabs.com
	id B0/19-12679-7AC47215; Fri, 22 Feb 2013 10:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361530022!8726752!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7832 invoked from network); 22 Feb 2013 10:47:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 10:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="1777314"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 10:47: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.297.1;
	Fri, 22 Feb 2013 10:47:02 +0000
Message-ID: <1361530021.26546.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 10:47:01 +0000
In-Reply-To: <1361523505-7604-5-git-send-email-ian.campbell@citrix.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
	<1361523505-7604-5-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v3 05/46] xen: arm64: initial build + config
 changes, start of day 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 Fri, 2013-02-22 at 08:57 +0000, Ian Campbell wrote:
> @@ -85,9 +91,9 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
> 
> -       . = ALIGN(4);
> +       . = ALIGN(BYTES_PER_LONG);
>         __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> +       LONG((__CTOR_END__ - __CTOR_LIST__) / BYTES_PER_LONG - 2)
>         *(.ctors)
>         LONG(0)
>         __CTOR_END__ = .; 

This hunk is incorrect. I'll drop it and post a fix for coverage on
ARM64 separately.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 10:58:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 10:58: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 1U8qKJ-00032b-Vp; Fri, 22 Feb 2013 10:58: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 1U8qKH-00032W-4u
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 10:58:02 +0000
Received: from [85.158.138.51:26901] by server-13.bemta-3.messagelabs.com id
	59/96-20653-83F47215; Fri, 22 Feb 2013 10:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361530678!26957080!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18862 invoked from network); 22 Feb 2013 10:57:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 10:57:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8973770"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 10:57:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 05:57:40 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8qJw-0007b0-DY;
	Fri, 22 Feb 2013 10:57:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 10:57:40 +0000
Message-ID: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, keir@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a list of pointers to simplify the handling of 32- vs 64-bit.

Also on ARM the section name is ".init_array" and not ".ctors".

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
Cc: keir@xen.org
---
This applies independently of my 64-bit ARM series.
---
 xen/arch/arm/xen.lds.S |   10 ++++------
 xen/arch/x86/xen.lds.S |    6 ++----
 xen/common/lib.c       |   13 +++++--------
 3 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9043994..fd755d7 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -91,12 +91,10 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
-       . = ALIGN(4);
-       __CTOR_LIST__ = .;
-       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
-       *(.ctors)
-       LONG(0)
-       __CTOR_END__ = .;
+       . = ALIGN(8);
+       __ctors_start = .;
+       *(.init_array)
+       __ctors_end = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 5570389..d959941 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -110,11 +110,9 @@ SECTIONS
        __trampoline_seg_stop = .;
 
        . = ALIGN(8);
-       __CTOR_LIST__ = .;
-       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       __ctors_start = .;
        *(.ctors)
-       QUAD(0)
-       __CTOR_END__ = .;
+       __ctors_end = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index e0c65cf..6b80601 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
-extern const struct
-{
-    unsigned long count;
-    void (*funcs[1])(void);
-} __CTOR_LIST__;
+typedef void (*ctor_func_t)(void);
+extern const ctor_func_t __ctors_start[], __ctors_end[];
 
 void __init init_constructors(void)
 {
-    unsigned long n;
-    for ( n = 0; n < __CTOR_LIST__.count; ++n )
-        __CTOR_LIST__.funcs[n]();
+    const ctor_func_t *f;
+    for (f = __ctors_start; f < __ctors_end; ++f )
+        (*f)();
 }
 
 /*
-- 
1.7.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 Feb 22 10:58:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 10:58: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 1U8qKJ-00032b-Vp; Fri, 22 Feb 2013 10:58: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 1U8qKH-00032W-4u
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 10:58:02 +0000
Received: from [85.158.138.51:26901] by server-13.bemta-3.messagelabs.com id
	59/96-20653-83F47215; Fri, 22 Feb 2013 10:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361530678!26957080!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18862 invoked from network); 22 Feb 2013 10:57:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 10:57:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; 
   d="scan'208";a="8973770"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 10:57:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 05:57:40 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1U8qJw-0007b0-DY;
	Fri, 22 Feb 2013 10:57:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 10:57:40 +0000
Message-ID: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, keir@xen.org,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a list of pointers to simplify the handling of 32- vs 64-bit.

Also on ARM the section name is ".init_array" and not ".ctors".

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
Cc: keir@xen.org
---
This applies independently of my 64-bit ARM series.
---
 xen/arch/arm/xen.lds.S |   10 ++++------
 xen/arch/x86/xen.lds.S |    6 ++----
 xen/common/lib.c       |   13 +++++--------
 3 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9043994..fd755d7 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -91,12 +91,10 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
-       . = ALIGN(4);
-       __CTOR_LIST__ = .;
-       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
-       *(.ctors)
-       LONG(0)
-       __CTOR_END__ = .;
+       . = ALIGN(8);
+       __ctors_start = .;
+       *(.init_array)
+       __ctors_end = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 5570389..d959941 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -110,11 +110,9 @@ SECTIONS
        __trampoline_seg_stop = .;
 
        . = ALIGN(8);
-       __CTOR_LIST__ = .;
-       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
+       __ctors_start = .;
        *(.ctors)
-       QUAD(0)
-       __CTOR_END__ = .;
+       __ctors_end = .;
   } :text
   . = ALIGN(32);
   .init.setup : {
diff --git a/xen/common/lib.c b/xen/common/lib.c
index e0c65cf..6b80601 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
     return ret;
 }
 
-extern const struct
-{
-    unsigned long count;
-    void (*funcs[1])(void);
-} __CTOR_LIST__;
+typedef void (*ctor_func_t)(void);
+extern const ctor_func_t __ctors_start[], __ctors_end[];
 
 void __init init_constructors(void)
 {
-    unsigned long n;
-    for ( n = 0; n < __CTOR_LIST__.count; ++n )
-        __CTOR_LIST__.funcs[n]();
+    const ctor_func_t *f;
+    for (f = __ctors_start; f < __ctors_end; ++f )
+        (*f)();
 }
 
 /*
-- 
1.7.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 Feb 22 11:16:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:16: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 1U8qcB-0003gA-TH; Fri, 22 Feb 2013 11:16:31 +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 1U8qcA-0003g5-AG
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:16:30 +0000
Received: from [85.158.138.51:16869] by server-16.bemta-3.messagelabs.com id
	E6/CE-02727-D8357215; Fri, 22 Feb 2013 11:16:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361531735!20626119!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32049 invoked from network); 22 Feb 2013 11:15:36 -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; 22 Feb 2013 11:15:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 11:15:35 +0000
Message-Id: <512761A202000078000C0589@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 11:16:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -91,12 +91,10 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
>  
> -       . = ALIGN(4);
> -       __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> -       *(.ctors)
> -       LONG(0)
> -       __CTOR_END__ = .;
> +       . = ALIGN(8);
> +       __ctors_start = .;
> +       *(.init_array)

Is this renaming from .ctors to .init_array really intended (i.e. was
using .ctors here wrong)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:16:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:16: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 1U8qcB-0003gA-TH; Fri, 22 Feb 2013 11:16:31 +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 1U8qcA-0003g5-AG
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:16:30 +0000
Received: from [85.158.138.51:16869] by server-16.bemta-3.messagelabs.com id
	E6/CE-02727-D8357215; Fri, 22 Feb 2013 11:16:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361531735!20626119!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32049 invoked from network); 22 Feb 2013 11:15:36 -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; 22 Feb 2013 11:15:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 11:15:35 +0000
Message-Id: <512761A202000078000C0589@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 11:16:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -91,12 +91,10 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
>  
> -       . = ALIGN(4);
> -       __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> -       *(.ctors)
> -       LONG(0)
> -       __CTOR_END__ = .;
> +       . = ALIGN(8);
> +       __ctors_start = .;
> +       *(.init_array)

Is this renaming from .ctors to .init_array really intended (i.e. was
using .ctors here wrong)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:25:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:25: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 1U8qkd-00043U-0p; Fri, 22 Feb 2013 11:25: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 1U8qkb-00043P-2y
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:25:13 +0000
Received: from [85.158.143.99:30356] by server-2.bemta-4.messagelabs.com id
	80/EF-12656-89557215; Fri, 22 Feb 2013 11:25:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361532310!23459506!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7919 invoked from network); 22 Feb 2013 11:25:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1779095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 11:24: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.297.1;
	Fri, 22 Feb 2013 11:24:53 +0000
Message-ID: <1361532291.26546.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 11:24:51 +0000
In-Reply-To: <512761A202000078000C0589@nat28.tlf.novell.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<512761A202000078000C0589@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 11:16 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -91,12 +91,10 @@ SECTIONS
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> >  
> > -       . = ALIGN(4);
> > -       __CTOR_LIST__ = .;
> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > -       *(.ctors)
> > -       LONG(0)
> > -       __CTOR_END__ = .;
> > +       . = ALIGN(8);
> > +       __ctors_start = .;
> > +       *(.init_array)
> 
> Is this renaming from .ctors to .init_array really intended (i.e. was
> using .ctors here wrong)?

Yes, I mentioned it in the commit message, it is called .init_array on
ARM for whatever reason. Probably either historical accident or
compatibility eg. with ARM's compilers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:25:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:25: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 1U8qkd-00043U-0p; Fri, 22 Feb 2013 11:25: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 1U8qkb-00043P-2y
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:25:13 +0000
Received: from [85.158.143.99:30356] by server-2.bemta-4.messagelabs.com id
	80/EF-12656-89557215; Fri, 22 Feb 2013 11:25:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361532310!23459506!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7919 invoked from network); 22 Feb 2013 11:25:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1779095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 11:24: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.297.1;
	Fri, 22 Feb 2013 11:24:53 +0000
Message-ID: <1361532291.26546.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 11:24:51 +0000
In-Reply-To: <512761A202000078000C0589@nat28.tlf.novell.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<512761A202000078000C0589@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 11:16 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -91,12 +91,10 @@ SECTIONS
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> >  
> > -       . = ALIGN(4);
> > -       __CTOR_LIST__ = .;
> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > -       *(.ctors)
> > -       LONG(0)
> > -       __CTOR_END__ = .;
> > +       . = ALIGN(8);
> > +       __ctors_start = .;
> > +       *(.init_array)
> 
> Is this renaming from .ctors to .init_array really intended (i.e. was
> using .ctors here wrong)?

Yes, I mentioned it in the commit message, it is called .init_array on
ARM for whatever reason. Probably either historical accident or
compatibility eg. with ARM's compilers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:33:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8qs1-0004Q7-3S; Fri, 22 Feb 2013 11:32: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 1U8qrz-0004Q2-Px
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:32:51 +0000
Received: from [85.158.139.83:7242] by server-11.bemta-5.messagelabs.com id
	88/A7-19159-26757215; Fri, 22 Feb 2013 11:32:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361532749!17185474!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6535 invoked from network); 22 Feb 2013 11:32:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:32:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1779360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 11: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.297.1; Fri, 22 Feb 2013 11:32:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8qrd-0000aq-Mo; Fri, 22 Feb 2013 11:32:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8qrd-0002n9-EQ;
	Fri, 22 Feb 2013 11:32:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.22349.171516.924833@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 11:32:29 +0000
To: jacek burghardt <jaceksburghardt@gmail.com>
In-Reply-To: <CAHyyzzRwY-u6DL94Oct-w+vOt+7T7vvNHV+eLgaH9kvt5cwf5Q@mail.gmail.com>
References: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
	<CAHyyzzRwY-u6DL94Oct-w+vOt+7T7vvNHV+eLgaH9kvt5cwf5Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: disable docs for QEMU 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

jacek burghardt writes ("Re: [PATCH] tools: disable docs for QEMU build"):
> This patch work perfectly . Nice work around
> 
> On Thu, Feb 21, 2013 at 10:10 AM, Wei Liu <wei.liu2@citrix.com<mailto:wei.liu2@citrix.com>> wrote:
> Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
> disable it.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com<mailto:wei.liu2@citrix.com>>

Applied, 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 Feb 22 11:33:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8qs1-0004Q7-3S; Fri, 22 Feb 2013 11:32: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 1U8qrz-0004Q2-Px
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:32:51 +0000
Received: from [85.158.139.83:7242] by server-11.bemta-5.messagelabs.com id
	88/A7-19159-26757215; Fri, 22 Feb 2013 11:32:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361532749!17185474!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6535 invoked from network); 22 Feb 2013 11:32:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:32:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1779360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 11: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.297.1; Fri, 22 Feb 2013 11:32:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8qrd-0000aq-Mo; Fri, 22 Feb 2013 11:32:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8qrd-0002n9-EQ;
	Fri, 22 Feb 2013 11:32:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.22349.171516.924833@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 11:32:29 +0000
To: jacek burghardt <jaceksburghardt@gmail.com>
In-Reply-To: <CAHyyzzRwY-u6DL94Oct-w+vOt+7T7vvNHV+eLgaH9kvt5cwf5Q@mail.gmail.com>
References: <1361466628-20655-1-git-send-email-wei.liu2@citrix.com>
	<CAHyyzzRwY-u6DL94Oct-w+vOt+7T7vvNHV+eLgaH9kvt5cwf5Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: disable docs for QEMU 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

jacek burghardt writes ("Re: [PATCH] tools: disable docs for QEMU build"):
> This patch work perfectly . Nice work around
> 
> On Thu, Feb 21, 2013 at 10:10 AM, Wei Liu <wei.liu2@citrix.com<mailto:wei.liu2@citrix.com>> wrote:
> Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
> disable it.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com<mailto:wei.liu2@citrix.com>>

Applied, 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 Feb 22 11:40:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8qyu-0004Zb-0p; Fri, 22 Feb 2013 11:40:00 +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 1U8qys-0004ZW-9w
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:39:58 +0000
Received: from [193.109.254.147:50221] by server-5.bemta-14.messagelabs.com id
	AF/10-21539-D0957215; Fri, 22 Feb 2013 11:39:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361533195!1601659!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6235 invoked from network); 22 Feb 2013 11:39:57 -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;
	22 Feb 2013 11:39:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8979211"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:39:55 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:39:55 -0500
Message-ID: <51275909.5020801@citrix.com>
Date: Fri, 22 Feb 2013 11:39:53 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
	<512736DA02000078000C038C@nat28.tlf.novell.com>
In-Reply-To: <512736DA02000078000C038C@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

On 22/02/13 08:14, Jan Beulich wrote:
>>>> On 21.02.13 at 18:57, David Vrabel <david.vrabel@citrix.com> wrote:
>> The series adds support for the new hypercall ABI which should be
>> provided by Xen 4.3.  Images are loaded into Xen directly with no
>> kernel involvement.
>>
>> Do not apply until the hypervisor side patches are applied to Xen.
>>
>> Patch 1 is unrelated but kexec wouldn't work for me without it. Not
>> sure why I had problems, perhaps a toolstack specific issue?
>>
>> Patch 2 makes libxc 4.3 mandatory for Xen support.
> 
> That doesn't sound right. How do you envision this to be
> incorporated into existing distros that don't right away switch
> to Xen 4.3?

Eric Bierderman said in an earlier thread[1]:

"Certainly /sbin/kexec will only support the new hypercall once the
support has merged."

David

[1] http://lists.xen.org/archives/html/xen-devel/2013-01/msg00754.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:40:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8qyu-0004Zb-0p; Fri, 22 Feb 2013 11:40:00 +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 1U8qys-0004ZW-9w
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:39:58 +0000
Received: from [193.109.254.147:50221] by server-5.bemta-14.messagelabs.com id
	AF/10-21539-D0957215; Fri, 22 Feb 2013 11:39:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361533195!1601659!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6235 invoked from network); 22 Feb 2013 11:39:57 -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;
	22 Feb 2013 11:39:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8979211"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:39:55 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:39:55 -0500
Message-ID: <51275909.5020801@citrix.com>
Date: Fri, 22 Feb 2013 11:39:53 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
	<512736DA02000078000C038C@nat28.tlf.novell.com>
In-Reply-To: <512736DA02000078000C038C@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

On 22/02/13 08:14, Jan Beulich wrote:
>>>> On 21.02.13 at 18:57, David Vrabel <david.vrabel@citrix.com> wrote:
>> The series adds support for the new hypercall ABI which should be
>> provided by Xen 4.3.  Images are loaded into Xen directly with no
>> kernel involvement.
>>
>> Do not apply until the hypervisor side patches are applied to Xen.
>>
>> Patch 1 is unrelated but kexec wouldn't work for me without it. Not
>> sure why I had problems, perhaps a toolstack specific issue?
>>
>> Patch 2 makes libxc 4.3 mandatory for Xen support.
> 
> That doesn't sound right. How do you envision this to be
> incorporated into existing distros that don't right away switch
> to Xen 4.3?

Eric Bierderman said in an earlier thread[1]:

"Certainly /sbin/kexec will only support the new hypercall once the
support has merged."

David

[1] http://lists.xen.org/archives/html/xen-devel/2013-01/msg00754.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:43:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:43: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 1U8r21-0004v3-NQ; Fri, 22 Feb 2013 11:43:13 +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 1U8r20-0004uu-H1
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:43:12 +0000
Received: from [193.109.254.147:34801] by server-3.bemta-14.messagelabs.com id
	A4/72-22141-FC957215; Fri, 22 Feb 2013 11:43:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361533259!9295817!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1533 invoked from network); 22 Feb 2013 11:41:01 -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; 22 Feb 2013 11:41:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 11:40:59 +0000
Message-Id: <5127679602000078000C05A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 11:41:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<512761A202000078000C0589@nat28.tlf.novell.com>
	<1361532291.26546.118.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361532291.26546.118.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-22 at 11:16 +0000, Jan Beulich wrote:
>> >>> On 22.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > --- a/xen/arch/arm/xen.lds.S
>> > +++ b/xen/arch/arm/xen.lds.S
>> > @@ -91,12 +91,10 @@ SECTIONS
>> >         *(.init.data.rel)
>> >         *(.init.data.rel.*)
>> >  
>> > -       . = ALIGN(4);
>> > -       __CTOR_LIST__ = .;
>> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
>> > -       *(.ctors)
>> > -       LONG(0)
>> > -       __CTOR_END__ = .;
>> > +       . = ALIGN(8);
>> > +       __ctors_start = .;
>> > +       *(.init_array)
>> 
>> Is this renaming from .ctors to .init_array really intended (i.e. was
>> using .ctors here wrong)?
> 
> Yes, I mentioned it in the commit message,

Oops, sorry, managed to skip that line somehow.

> it is called .init_array on
> ARM for whatever reason. Probably either historical accident or
> compatibility eg. with ARM's compilers.

Or rather the other way around, because .init_array is a (newer)
ELF concept, whereas .ctors isn't.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:43:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:43: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 1U8r21-0004v3-NQ; Fri, 22 Feb 2013 11:43:13 +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 1U8r20-0004uu-H1
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:43:12 +0000
Received: from [193.109.254.147:34801] by server-3.bemta-14.messagelabs.com id
	A4/72-22141-FC957215; Fri, 22 Feb 2013 11:43:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361533259!9295817!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1533 invoked from network); 22 Feb 2013 11:41:01 -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; 22 Feb 2013 11:41:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 11:40:59 +0000
Message-Id: <5127679602000078000C05A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 11:41:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<512761A202000078000C0589@nat28.tlf.novell.com>
	<1361532291.26546.118.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361532291.26546.118.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2013-02-22 at 11:16 +0000, Jan Beulich wrote:
>> >>> On 22.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > --- a/xen/arch/arm/xen.lds.S
>> > +++ b/xen/arch/arm/xen.lds.S
>> > @@ -91,12 +91,10 @@ SECTIONS
>> >         *(.init.data.rel)
>> >         *(.init.data.rel.*)
>> >  
>> > -       . = ALIGN(4);
>> > -       __CTOR_LIST__ = .;
>> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
>> > -       *(.ctors)
>> > -       LONG(0)
>> > -       __CTOR_END__ = .;
>> > +       . = ALIGN(8);
>> > +       __ctors_start = .;
>> > +       *(.init_array)
>> 
>> Is this renaming from .ctors to .init_array really intended (i.e. was
>> using .ctors here wrong)?
> 
> Yes, I mentioned it in the commit message,

Oops, sorry, managed to skip that line somehow.

> it is called .init_array on
> ARM for whatever reason. Probably either historical accident or
> compatibility eg. with ARM's compilers.

Or rather the other way around, because .init_array is a (newer)
ELF concept, whereas .ctors isn't.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:45:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:45: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 1U8r3e-00052Z-Iw; Fri, 22 Feb 2013 11:44:54 +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 1U8r3d-00052R-FO
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:44:53 +0000
Received: from [85.158.139.211:52087] by server-16.bemta-5.messagelabs.com id
	0D/99-14948-43A57215; Fri, 22 Feb 2013 11:44:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361533491!18747074!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 585 invoked from network); 22 Feb 2013 11:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1779795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 11:44: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.297.1;
	Fri, 22 Feb 2013 11:44:52 +0000
Message-ID: <1361533490.26546.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 11:44:50 +0000
In-Reply-To: <5127679602000078000C05A0@nat28.tlf.novell.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<512761A202000078000C0589@nat28.tlf.novell.com>
	<1361532291.26546.118.camel@zakaz.uk.xensource.com>
	<5127679602000078000C05A0@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 11:41 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 12:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-22 at 11:16 +0000, Jan Beulich wrote:
> >> >>> On 22.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > --- a/xen/arch/arm/xen.lds.S
> >> > +++ b/xen/arch/arm/xen.lds.S
> >> > @@ -91,12 +91,10 @@ SECTIONS
> >> >         *(.init.data.rel)
> >> >         *(.init.data.rel.*)
> >> >  
> >> > -       . = ALIGN(4);
> >> > -       __CTOR_LIST__ = .;
> >> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> >> > -       *(.ctors)
> >> > -       LONG(0)
> >> > -       __CTOR_END__ = .;
> >> > +       . = ALIGN(8);
> >> > +       __ctors_start = .;
> >> > +       *(.init_array)
> >> 
> >> Is this renaming from .ctors to .init_array really intended (i.e. was
> >> using .ctors here wrong)?
> > 
> > Yes, I mentioned it in the commit message,
> 
> Oops, sorry, managed to skip that line somehow.
> 
> > it is called .init_array on
> > ARM for whatever reason. Probably either historical accident or
> > compatibility eg. with ARM's compilers.
> 
> Or rather the other way around, because .init_array is a (newer)
> ELF concept, whereas .ctors isn't.

Ah, that explains 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 Fri Feb 22 11:45:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:45: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 1U8r3e-00052Z-Iw; Fri, 22 Feb 2013 11:44:54 +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 1U8r3d-00052R-FO
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:44:53 +0000
Received: from [85.158.139.211:52087] by server-16.bemta-5.messagelabs.com id
	0D/99-14948-43A57215; Fri, 22 Feb 2013 11:44:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361533491!18747074!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 585 invoked from network); 22 Feb 2013 11:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1779795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 11:44: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.297.1;
	Fri, 22 Feb 2013 11:44:52 +0000
Message-ID: <1361533490.26546.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 11:44:50 +0000
In-Reply-To: <5127679602000078000C05A0@nat28.tlf.novell.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<512761A202000078000C0589@nat28.tlf.novell.com>
	<1361532291.26546.118.camel@zakaz.uk.xensource.com>
	<5127679602000078000C05A0@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 11:41 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 12:24, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2013-02-22 at 11:16 +0000, Jan Beulich wrote:
> >> >>> On 22.02.13 at 11:57, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > --- a/xen/arch/arm/xen.lds.S
> >> > +++ b/xen/arch/arm/xen.lds.S
> >> > @@ -91,12 +91,10 @@ SECTIONS
> >> >         *(.init.data.rel)
> >> >         *(.init.data.rel.*)
> >> >  
> >> > -       . = ALIGN(4);
> >> > -       __CTOR_LIST__ = .;
> >> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> >> > -       *(.ctors)
> >> > -       LONG(0)
> >> > -       __CTOR_END__ = .;
> >> > +       . = ALIGN(8);
> >> > +       __ctors_start = .;
> >> > +       *(.init_array)
> >> 
> >> Is this renaming from .ctors to .init_array really intended (i.e. was
> >> using .ctors here wrong)?
> > 
> > Yes, I mentioned it in the commit message,
> 
> Oops, sorry, managed to skip that line somehow.
> 
> > it is called .init_array on
> > ARM for whatever reason. Probably either historical accident or
> > compatibility eg. with ARM's compilers.
> 
> Or rather the other way around, because .init_array is a (newer)
> ELF concept, whereas .ctors isn't.

Ah, that explains 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 Fri Feb 22 11:49:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:49: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 1U8r82-0005Ff-DQ; Fri, 22 Feb 2013 11:49:26 +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 1U8r80-0005FZ-JJ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:49:24 +0000
Received: from [85.158.143.99:2335] by server-2.bemta-4.messagelabs.com id
	FA/89-12656-34B57215; Fri, 22 Feb 2013 11:49:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361533761!23440671!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6065 invoked from network); 22 Feb 2013 11:49:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:49:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8980278"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:49:21 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:49:20 -0500
Message-ID: <51275B3F.7010503@citrix.com>
Date: Fri, 22 Feb 2013 11:49:19 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Daniel Kiper <daniel.kiper@oracle.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
	<20130221222928.GA18464@host-192-168-1-59.local.net-space.pl>
In-Reply-To: <20130221222928.GA18464@host-192-168-1-59.local.net-space.pl>
X-Originating-IP: [10.80.2.76]
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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/02/13 22:29, Daniel Kiper wrote:
> On Thu, Feb 21, 2013 at 05:48:09PM +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Add replacement KEXEC_CMD_load and KEXEC_CMD_unload sub-ops to the
>> kexec hypercall.  These new sub-ops allow a priviledged guest to
>> provide the image data to be loaded into Xen memory or the crash
>> region instead of guests loading the image data themselves and
>> providing the relocation code and metadata.
>>
>> The old interface is provided to guests requesting an interface
>> version prior to 4.3.
>>
[...]
>> +/*
>> + * Load a kexec image into memory.
>> + *
>> + * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
>> + * The image is relocated prior to being executed.
>> + *
>> + * For KEXEC_TYPE_CRASH images, each segment of the image must reside
>> + * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
>> + * the entry point must be within the image. The caller is responsible
>> + * for ensuring that multiple images do not overlap.
> 
> What do you mean by "The caller is responsible for ensuring
> that multiple images do not overlap."?

The intention here is to allow for safe replacement of a crash image by
loading the second image at a different location in the crash region.

This won't actually work however, as the control pages (also allocated
from the crash region) will conflict.

This is the behaviour of the Linux implementation.  It's less than ideal
and something I plan to look at later on (it's low priority as replacing
crash images isn't an interesting use case).

>> + */
>> +
>> +#define KEXEC_CMD_kexec_load 4
>> +typedef struct xen_kexec_load {
>> +    uint8_t  type;        /* One of KEXEC_TYPE_* */
>> +    uint16_t arch;        /* ELF machine type (EM_*). */
>> +    uint32_t __pad;
> 
> Why do you need __pad here?

To ensure that the following uint64_t is aligned to 8 bytes in both 32
and 64-bit.

Annoyingly uint64_t only has 4 byte alignment on 32-bit architectures.

>> +    uint64_t entry_maddr; /* image entry point machine address. */
>> +    uint32_t nr_segments;
>> +    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
>> +} xen_kexec_load_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
>> +
>> +/*
>> + * Unload a kexec image.
>> + *
>> + * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH.
>> + */
>> +#define KEXEC_CMD_kexec_unload 5
>> +typedef struct xen_kexec_unload {
>> +    uint8_t type;
>> +} xen_kexec_unload_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t);
>> +
>> +#else /* __XEN_INTERFACE_VERSION__ < 0x00040300 */
>> +
>> +#undef KEXEC_CMD_kexec_load
>> +#undef KEXEC_CMD_kexec_unload
>> +#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1
>> +#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1
> 
> Could you define all constants in one place at the
> beginning of this file? It is very difficult to
> see what is going on. Especially those undefs are
> crazy for me.

I was copying the style used for sched_op_compat.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:49:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:49: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 1U8r82-0005Ff-DQ; Fri, 22 Feb 2013 11:49:26 +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 1U8r80-0005FZ-JJ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:49:24 +0000
Received: from [85.158.143.99:2335] by server-2.bemta-4.messagelabs.com id
	FA/89-12656-34B57215; Fri, 22 Feb 2013 11:49:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361533761!23440671!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6065 invoked from network); 22 Feb 2013 11:49:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:49:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8980278"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:49:21 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:49:20 -0500
Message-ID: <51275B3F.7010503@citrix.com>
Date: Fri, 22 Feb 2013 11:49:19 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Daniel Kiper <daniel.kiper@oracle.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
	<20130221222928.GA18464@host-192-168-1-59.local.net-space.pl>
In-Reply-To: <20130221222928.GA18464@host-192-168-1-59.local.net-space.pl>
X-Originating-IP: [10.80.2.76]
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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/02/13 22:29, Daniel Kiper wrote:
> On Thu, Feb 21, 2013 at 05:48:09PM +0000, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Add replacement KEXEC_CMD_load and KEXEC_CMD_unload sub-ops to the
>> kexec hypercall.  These new sub-ops allow a priviledged guest to
>> provide the image data to be loaded into Xen memory or the crash
>> region instead of guests loading the image data themselves and
>> providing the relocation code and metadata.
>>
>> The old interface is provided to guests requesting an interface
>> version prior to 4.3.
>>
[...]
>> +/*
>> + * Load a kexec image into memory.
>> + *
>> + * For KEXEC_TYPE_DEFAULT images, the segments may be anywhere in RAM.
>> + * The image is relocated prior to being executed.
>> + *
>> + * For KEXEC_TYPE_CRASH images, each segment of the image must reside
>> + * in the memory region reserved for kexec (KEXEC_RANGE_MA_CRASH) and
>> + * the entry point must be within the image. The caller is responsible
>> + * for ensuring that multiple images do not overlap.
> 
> What do you mean by "The caller is responsible for ensuring
> that multiple images do not overlap."?

The intention here is to allow for safe replacement of a crash image by
loading the second image at a different location in the crash region.

This won't actually work however, as the control pages (also allocated
from the crash region) will conflict.

This is the behaviour of the Linux implementation.  It's less than ideal
and something I plan to look at later on (it's low priority as replacing
crash images isn't an interesting use case).

>> + */
>> +
>> +#define KEXEC_CMD_kexec_load 4
>> +typedef struct xen_kexec_load {
>> +    uint8_t  type;        /* One of KEXEC_TYPE_* */
>> +    uint16_t arch;        /* ELF machine type (EM_*). */
>> +    uint32_t __pad;
> 
> Why do you need __pad here?

To ensure that the following uint64_t is aligned to 8 bytes in both 32
and 64-bit.

Annoyingly uint64_t only has 4 byte alignment on 32-bit architectures.

>> +    uint64_t entry_maddr; /* image entry point machine address. */
>> +    uint32_t nr_segments;
>> +    XEN_GUEST_HANDLE_64(xen_kexec_segment_t) segments;
>> +} xen_kexec_load_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);
>> +
>> +/*
>> + * Unload a kexec image.
>> + *
>> + * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH.
>> + */
>> +#define KEXEC_CMD_kexec_unload 5
>> +typedef struct xen_kexec_unload {
>> +    uint8_t type;
>> +} xen_kexec_unload_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t);
>> +
>> +#else /* __XEN_INTERFACE_VERSION__ < 0x00040300 */
>> +
>> +#undef KEXEC_CMD_kexec_load
>> +#undef KEXEC_CMD_kexec_unload
>> +#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1
>> +#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1
> 
> Could you define all constants in one place at the
> beginning of this file? It is very difficult to
> see what is going on. Especially those undefs are
> crazy for me.

I was copying the style used for sched_op_compat.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:51:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:51: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 1U8r9b-0005MS-W8; Fri, 22 Feb 2013 11:51:04 +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 1U8r9a-0005MJ-9M
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:51:02 +0000
Received: from [85.158.139.83:42355] by server-2.bemta-5.messagelabs.com id
	BC/1A-16911-5AB57215; Fri, 22 Feb 2013 11:51:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361533842!28451729!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 22 Feb 2013 11:50:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:50:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8540523"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:50:29 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:50:29 -0500
Message-ID: <51275B84.2030905@citrix.com>
Date: Fri, 22 Feb 2013 11:50:28 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
	<51273B8502000078000C03BF@nat28.tlf.novell.com>
In-Reply-To: <51273B8502000078000C03BF@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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/02/13 08:33, Jan Beulich wrote:
>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>> --- a/xen/include/public/kexec.h
>> +++ b/xen/include/public/kexec.h
>> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>>   * image == relocation information for kexec (ignored for unload) [in]
>>   */
>> -#define KEXEC_CMD_kexec_load            1
>> -#define KEXEC_CMD_kexec_unload          2
>> -typedef struct xen_kexec_load {
>> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
>> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
>> +typedef struct xen_kexec_load_v1 {
>>      int type;
>>      xen_kexec_image_t image;
>> -} xen_kexec_load_t;
>> +} xen_kexec_load_v1_t;
> 
> You can't change type names like this without also guarding them
> with a __XEN_INTERFACE_VERSION__ conditional or providing
> backward compatibility #define-s.

There are backward compatible definitions provided at the end of the
header file.

I will probably refactor this as it confused Daniel as well.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:51:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11:51: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 1U8r9b-0005MS-W8; Fri, 22 Feb 2013 11:51:04 +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 1U8r9a-0005MJ-9M
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:51:02 +0000
Received: from [85.158.139.83:42355] by server-2.bemta-5.messagelabs.com id
	BC/1A-16911-5AB57215; Fri, 22 Feb 2013 11:51:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361533842!28451729!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 22 Feb 2013 11:50:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:50:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8540523"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:50:29 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:50:29 -0500
Message-ID: <51275B84.2030905@citrix.com>
Date: Fri, 22 Feb 2013 11:50:28 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
	<51273B8502000078000C03BF@nat28.tlf.novell.com>
In-Reply-To: <51273B8502000078000C03BF@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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/02/13 08:33, Jan Beulich wrote:
>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>> --- a/xen/include/public/kexec.h
>> +++ b/xen/include/public/kexec.h
>> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>>   * image == relocation information for kexec (ignored for unload) [in]
>>   */
>> -#define KEXEC_CMD_kexec_load            1
>> -#define KEXEC_CMD_kexec_unload          2
>> -typedef struct xen_kexec_load {
>> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
>> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
>> +typedef struct xen_kexec_load_v1 {
>>      int type;
>>      xen_kexec_image_t image;
>> -} xen_kexec_load_t;
>> +} xen_kexec_load_v1_t;
> 
> You can't change type names like this without also guarding them
> with a __XEN_INTERFACE_VERSION__ conditional or providing
> backward compatibility #define-s.

There are backward compatible definitions provided at the end of the
header file.

I will probably refactor this as it confused Daniel as well.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:55:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8rDO-0005Xp-PN; Fri, 22 Feb 2013 11:54:58 +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 1U8rDM-0005Xf-SK
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:54:57 +0000
Received: from [85.158.139.83:5360] by server-14.bemta-5.messagelabs.com id
	42/D9-06967-09C57215; Fri, 22 Feb 2013 11:54:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361534094!28721349!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5092 invoked from network); 22 Feb 2013 11:54:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:54:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8980881"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:54:53 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:54:53 -0500
Message-ID: <51275C8C.80506@citrix.com>
Date: Fri, 22 Feb 2013 11:54:52 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
	<51273D9D02000078000C03D4@nat28.tlf.novell.com>
In-Reply-To: <51273D9D02000078000C03D4@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
 load/unload 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>
Content-Type: text/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/02/13 08:42, Jan Beulich wrote:
>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>> Crash images are copied directly into the crash region on load.
>> Default images are copied into Xen heap pages and a list of source and
>> destination machine addresses is created.  This is list is used in
>> kexec_reloc() to relocate the image to its destination.
> 
> Did you carefully consider the implications of using Xen heap pages
> here as opposed to domain heap ones? On huge systems, this may
> prevent kexec from working, as you're not just trying to allocate a
> handful of pages. IOW, is the less complex code really worth the
> increased likelihood of a failure here?

I wouldn't say carefully considered... I thought about using dom heap
briefly and took the lazy route.

I take your point though and will change it to use the dom heap.  Is
there a way to verify that all the map/unmaps are correctly done and it
isn't just working by chance?  Some sort of debug option?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:55:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8rDO-0005Xp-PN; Fri, 22 Feb 2013 11:54:58 +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 1U8rDM-0005Xf-SK
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:54:57 +0000
Received: from [85.158.139.83:5360] by server-14.bemta-5.messagelabs.com id
	42/D9-06967-09C57215; Fri, 22 Feb 2013 11:54:56 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361534094!28721349!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5092 invoked from network); 22 Feb 2013 11:54:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 11:54:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8980881"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:54:53 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:54:53 -0500
Message-ID: <51275C8C.80506@citrix.com>
Date: Fri, 22 Feb 2013 11:54:52 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
	<51273D9D02000078000C03D4@nat28.tlf.novell.com>
In-Reply-To: <51273D9D02000078000C03D4@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
 load/unload 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>
Content-Type: text/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/02/13 08:42, Jan Beulich wrote:
>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>> Crash images are copied directly into the crash region on load.
>> Default images are copied into Xen heap pages and a list of source and
>> destination machine addresses is created.  This is list is used in
>> kexec_reloc() to relocate the image to its destination.
> 
> Did you carefully consider the implications of using Xen heap pages
> here as opposed to domain heap ones? On huge systems, this may
> prevent kexec from working, as you're not just trying to allocate a
> handful of pages. IOW, is the less complex code really worth the
> increased likelihood of a failure here?

I wouldn't say carefully considered... I thought about using dom heap
briefly and took the lazy route.

I take your point though and will change it to use the dom heap.  Is
there a way to verify that all the map/unmaps are correctly done and it
isn't just working by chance?  Some sort of debug option?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:56:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8rF3-0005qa-BE; Fri, 22 Feb 2013 11:56:41 +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 1U8rF1-0005qR-4x
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:56:39 +0000
Received: from [85.158.139.83:24800] by server-11.bemta-5.messagelabs.com id
	F0/EE-19159-6FC57215; Fri, 22 Feb 2013 11:56:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361534196!27777925!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26564 invoked from network); 22 Feb 2013 11:56:37 -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;
	22 Feb 2013 11:56:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8981068"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:56:36 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:56:35 -0500
Message-ID: <51275CF2.8080109@citrix.com>
Date: Fri, 22 Feb 2013 11:56:34 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<512737A302000078000C038F@nat28.tlf.novell.com>
In-Reply-To: <512737A302000078000C038F@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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 22/02/13 08:17, Jan Beulich wrote:
>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>> The series improves the kexec hypercall by making Xen responsible for
>> loading and relocating the image.  This allows kexec to be usable by
>> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
>> privileged domain.
>>
>> The first patch is a simple clean-up.
>>
>> The second patch allows hypercall structures to be ABI compatible
>> between 32- and 64-bit guests (by reusing stuff present for domctls
>> and sysctls).  This seems better than having to keep adding compat
>> handling for new hypercalls etc.
>>
>> Patch 3 introduces the new ABI.
>>
>> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
>> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
>> the new code.
>>
>> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
>> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
>> SHUTDOWN_crash.
> 
> Am I right in understanding that at this point no kexec support is
> necessary in the Dom0 kernel at all anymore? If so, that's a very
> nice move - thanks for doing that!

Yes.  It will kexec slightly later than it would on native (or classic)
but I don't think this will be a problem in practice.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 11:56:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 11: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 1U8rF3-0005qa-BE; Fri, 22 Feb 2013 11:56:41 +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 1U8rF1-0005qR-4x
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 11:56:39 +0000
Received: from [85.158.139.83:24800] by server-11.bemta-5.messagelabs.com id
	F0/EE-19159-6FC57215; Fri, 22 Feb 2013 11:56:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361534196!27777925!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26564 invoked from network); 22 Feb 2013 11:56:37 -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;
	22 Feb 2013 11:56:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8981068"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 11:56:36 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 06:56:35 -0500
Message-ID: <51275CF2.8080109@citrix.com>
Date: Fri, 22 Feb 2013 11:56:34 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<512737A302000078000C038F@nat28.tlf.novell.com>
In-Reply-To: <512737A302000078000C038F@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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 22/02/13 08:17, Jan Beulich wrote:
>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>> The series improves the kexec hypercall by making Xen responsible for
>> loading and relocating the image.  This allows kexec to be usable by
>> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
>> privileged domain.
>>
>> The first patch is a simple clean-up.
>>
>> The second patch allows hypercall structures to be ABI compatible
>> between 32- and 64-bit guests (by reusing stuff present for domctls
>> and sysctls).  This seems better than having to keep adding compat
>> handling for new hypercalls etc.
>>
>> Patch 3 introduces the new ABI.
>>
>> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
>> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
>> the new code.
>>
>> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
>> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
>> SHUTDOWN_crash.
> 
> Am I right in understanding that at this point no kexec support is
> necessary in the Dom0 kernel at all anymore? If so, that's a very
> nice move - thanks for doing that!

Yes.  It will kexec slightly later than it would on native (or classic)
but I don't think this will be a problem in practice.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:05:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:05: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 1U8rN9-0006Sf-Mz; Fri, 22 Feb 2013 12:05: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 1U8rN8-0006SZ-Po
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 12:05:02 +0000
Received: from [85.158.138.51:28072] by server-12.bemta-3.messagelabs.com id
	2B/D7-05889-EEE57215; Fri, 22 Feb 2013 12:05:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361534701!20635451!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30841 invoked from network); 22 Feb 2013 12:05:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:05:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1780680"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:05: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.297.1; Fri, 22 Feb 2013 12:05:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8rN6-0000kX-KI; Fri, 22 Feb 2013 12:05:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8rN6-0002rb-Fo;
	Fri, 22 Feb 2013 12:05:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.24300.354284.473756@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 12:05:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361521938.26546.96.camel@zakaz.uk.xensource.com>
References: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
	<1361521938.26546.96.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] [Xen-staging] [xen] x86/mm: Take the p2m lock even
 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

Ian Campbell writes ("Re: [Xen-staging] [xen] x86/mm: Take the p2m lock even in shadow mode."):
> I suppose this came from the commit bot on the xen.git tree? Could we
> get the branch added to the Subject (e.g. [xen staging] / [xen
> staging/4.2] etc). If it could include the committer as well as the
> author in the metadata that might be useful too.

Done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:05:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:05: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 1U8rN9-0006Sf-Mz; Fri, 22 Feb 2013 12:05: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 1U8rN8-0006SZ-Po
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 12:05:02 +0000
Received: from [85.158.138.51:28072] by server-12.bemta-3.messagelabs.com id
	2B/D7-05889-EEE57215; Fri, 22 Feb 2013 12:05:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361534701!20635451!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30841 invoked from network); 22 Feb 2013 12:05:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:05:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1780680"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:05: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.297.1; Fri, 22 Feb 2013 12:05:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8rN6-0000kX-KI; Fri, 22 Feb 2013 12:05:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8rN6-0002rb-Fo;
	Fri, 22 Feb 2013 12:05:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.24300.354284.473756@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 12:05:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361521938.26546.96.camel@zakaz.uk.xensource.com>
References: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
	<1361521938.26546.96.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] [Xen-staging] [xen] x86/mm: Take the p2m lock even
 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

Ian Campbell writes ("Re: [Xen-staging] [xen] x86/mm: Take the p2m lock even in shadow mode."):
> I suppose this came from the commit bot on the xen.git tree? Could we
> get the branch added to the Subject (e.g. [xen staging] / [xen
> staging/4.2] etc). If it could include the committer as well as the
> author in the metadata that might be useful too.

Done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:12:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:12: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 1U8rU9-0006qU-Lo; Fri, 22 Feb 2013 12:12:17 +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 1U8rU8-0006qP-PB
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 12:12:16 +0000
Received: from [85.158.138.51:29588] by server-7.bemta-3.messagelabs.com id
	7F/25-10367-B9067215; Fri, 22 Feb 2013 12:12:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361535131!28700220!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5271 invoked from network); 22 Feb 2013 12:12:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:12:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1781044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:12: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.297.1;
	Fri, 22 Feb 2013 12:12:10 +0000
Message-ID: <1361535129.26546.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 12:12:09 +0000
In-Reply-To: <20775.24300.354284.473756@mariner.uk.xensource.com>
References: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
	<1361521938.26546.96.camel@zakaz.uk.xensource.com>
	<20775.24300.354284.473756@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-staging] [xen] x86/mm: Take the p2m lock even
 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

On Fri, 2013-02-22 at 12:05 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-staging] [xen] x86/mm: Take the p2m lock even in shadow mode."):
> > I suppose this came from the commit bot on the xen.git tree? Could we
> > get the branch added to the Subject (e.g. [xen staging] / [xen
> > staging/4.2] etc). If it could include the committer as well as the
> > author in the metadata that might be useful too.
> 
> Done.

Thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:12:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:12: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 1U8rU9-0006qU-Lo; Fri, 22 Feb 2013 12:12:17 +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 1U8rU8-0006qP-PB
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 12:12:16 +0000
Received: from [85.158.138.51:29588] by server-7.bemta-3.messagelabs.com id
	7F/25-10367-B9067215; Fri, 22 Feb 2013 12:12:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361535131!28700220!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5271 invoked from network); 22 Feb 2013 12:12:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:12:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1781044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:12: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.297.1;
	Fri, 22 Feb 2013 12:12:10 +0000
Message-ID: <1361535129.26546.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 12:12:09 +0000
In-Reply-To: <20775.24300.354284.473756@mariner.uk.xensource.com>
References: <E1U8bZe-0004jo-Ph@xenbits.xen.org>
	<1361521938.26546.96.camel@zakaz.uk.xensource.com>
	<20775.24300.354284.473756@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-staging] [xen] x86/mm: Take the p2m lock even
 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

On Fri, 2013-02-22 at 12:05 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-staging] [xen] x86/mm: Take the p2m lock even in shadow mode."):
> > I suppose this came from the commit bot on the xen.git tree? Could we
> > get the branch added to the Subject (e.g. [xen staging] / [xen
> > staging/4.2] etc). If it could include the committer as well as the
> > author in the metadata that might be useful too.
> 
> Done.

Thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:27:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12: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 1U8riL-000781-9s; Fri, 22 Feb 2013 12:26:57 +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 1U8riJ-00077w-Lw
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:26:55 +0000
Received: from [85.158.138.51:8656] by server-16.bemta-3.messagelabs.com id
	C1/1D-02727-E0467215; Fri, 22 Feb 2013 12:26:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361536014!20639571!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14776 invoked from network); 22 Feb 2013 12:26:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:26:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1781482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12: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.297.1;
	Fri, 22 Feb 2013 12:26:53 +0000
Message-ID: <1361536012.26546.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 12:26:52 +0000
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v3 00/46] initial arm v8 (64-bit) 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 Fri, 2013-02-22 at 08:58 +0000, Ian Campbell wrote:
> This round implements all of the review comments from V2 and all patches
> are now acked. Unless there are any objections I intend to apply later
> this morning.

Done, thanks everyone.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:27:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12: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 1U8riL-000781-9s; Fri, 22 Feb 2013 12:26:57 +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 1U8riJ-00077w-Lw
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:26:55 +0000
Received: from [85.158.138.51:8656] by server-16.bemta-3.messagelabs.com id
	C1/1D-02727-E0467215; Fri, 22 Feb 2013 12:26:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361536014!20639571!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14776 invoked from network); 22 Feb 2013 12:26:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:26:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1781482"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12: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.297.1;
	Fri, 22 Feb 2013 12:26:53 +0000
Message-ID: <1361536012.26546.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 22 Feb 2013 12:26:52 +0000
In-Reply-To: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
References: <1361523488.26546.111.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v3 00/46] initial arm v8 (64-bit) 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 Fri, 2013-02-22 at 08:58 +0000, Ian Campbell wrote:
> This round implements all of the review comments from V2 and all patches
> are now acked. Unless there are any objections I intend to apply later
> this morning.

Done, thanks everyone.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:35:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:35: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 1U8rqb-0007br-CS; Fri, 22 Feb 2013 12:35: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 1U8rqa-0007bm-Eu
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:35:28 +0000
Received: from [85.158.137.99:10773] by server-1.bemta-3.messagelabs.com id
	54/E5-08955-F0667215; Fri, 22 Feb 2013 12:35:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361536520!15247648!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2483 invoked from network); 22 Feb 2013 12:35:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8547308"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 12:35:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 07:35:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8rqQ-0000gl-HR;
	Fri, 22 Feb 2013 12:35:18 +0000
Date: Fri, 22 Feb 2013 12:35:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1302221233080.22997@kaball.uk.xensource.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
	base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Xudong Hao wrote:
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically.
> 
> The use case of this register defination is for Xen till now.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

Thanks for the patch!

Aside from Jan's comment on the pci config endianness, I would also like
to see an #define somewhere in QEMU to specific what's the default TOM.
In particular I wouldn't want 0xe0000000 (and 0xf0000000) to be
hardcoded in more than one place.


>  hw/pc.h       |  4 ---
>  hw/pc_piix.c  |  6 -----
>  hw/piix_pci.c | 79 ++++++++++++++++++++++++++++++++++++++++++++---------------
>  3 files changed, 59 insertions(+), 30 deletions(-)
> 
> diff --git a/hw/pc.h b/hw/pc.h
> index fbcf43d..2a60490 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -134,10 +134,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory,
>                      MemoryRegion *ram_memory);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0a6923d..98cf467 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>                                system_memory, system_io, ram_size,
> -                              below_4g_mem_size,
> -                              0x100000000ULL - below_4g_mem_size,
> -                              0x100000000ULL + above_4g_mem_size,
> -                              (sizeof(hwaddr) == 4
> -                               ? 0
> -                               : ((uint64_t)1 << 62)),
>                                pci_memory, ram_memory);
>      } else {
>          pci_bus = NULL;
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3d79c73..88bd688 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -86,6 +86,14 @@ struct PCII440FXState {
>  #define I440FX_PAM_SIZE 7
>  #define I440FX_SMRAM    0x72
>  
> +/* The maximum vaule of TOM(top of memory) register in I440FX
> + * is 1G, so it doesn't meet any popular virutal machines, so
> + * define another register to report the base of PCI memory.
> + * Use four bytes 0xb0-0xb3 for this purpose, they are originally
> + * resevered for host bridge.
> + * */
> +#define I440FX_PCI_HOLE_BASE 0xb0
> +
>  static void piix3_set_irq(void *opaque, int pirq, int level);
>  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
>  static void piix3_write_config_xen(PCIDevice *dev,
> @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> +
> +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> +{
> +    ram_addr_t above_4g_mem_size;
> +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
> +
> +    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 4);
> +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> +
> +    if (ram_size >= pci_hole_start) {
> +        above_4g_mem_size = ram_size - pci_hole_start;
> +    } else {
> +        above_4g_mem_size = 0;
> +    }
> +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> +
> +    if (del) {
> +        memory_region_del_subregion(f->system_memory, &f->pci_hole);
> +        if (pci_hole64_size) {
> +            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
> +        }
> +    }
> +
> +    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> +                             pci_hole_start, pci_hole_size);
> +    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> +                             f->pci_address_space,
> +                             pci_hole64_start, pci_hole64_size);
> +    if (pci_hole64_size) {
> +        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> +                                    &f->pci_hole_64bit);
> +    }
> +}
> +
> +
>  static void i440fx_update_memory_mappings(PCII440FXState *d)
>  {
>      int i;
> @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
>          range_covers_byte(address, len, I440FX_SMRAM)) {
>          i440fx_update_memory_mappings(d);
>      }
> +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> +        i440fx_update_pci_mem_hole(d, true);
> +    }
>  }
>  
>  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    if (xen_enabled()) {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> +    } else {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> +    }
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }
> @@ -214,10 +272,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>                                    MemoryRegion *address_space_mem,
>                                    MemoryRegion *address_space_io,
>                                    ram_addr_t ram_size,
> -                                  hwaddr pci_hole_start,
> -                                  hwaddr pci_hole_size,
> -                                  hwaddr pci_hole64_start,
> -                                  hwaddr pci_hole64_size,
>                                    MemoryRegion *pci_address_space,
>                                    MemoryRegion *ram_memory)
>  {
> @@ -244,16 +298,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      f->system_memory = address_space_mem;
>      f->pci_address_space = pci_address_space;
>      f->ram_memory = ram_memory;
> -    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> -                             pci_hole_start, pci_hole_size);
> -    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> -                             f->pci_address_space,
> -                             pci_hole64_start, pci_hole64_size);
> -    if (pci_hole64_size) {
> -        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> -                                    &f->pci_hole_64bit);
> -    }
>      memory_region_init_alias(&f->smram_region, "smram-region",
>                               f->pci_address_space, 0xa0000, 0x20000);
>      memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
> @@ -295,6 +339,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      (*pi440fx_state)->dev.config[0x57]=ram_size;
>  
>      i440fx_update_memory_mappings(f);
> +    i440fx_update_pci_mem_hole(f, false);
>  
>      return b;
>  }
> @@ -304,10 +349,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory, MemoryRegion *ram_memory)
>  
>  {
> @@ -315,8 +356,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>  
>      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
>                             address_space_mem, address_space_io, ram_size,
> -                           pci_hole_start, pci_hole_size,
> -                           pci_hole64_start, pci_hole64_size,
>                             pci_memory, ram_memory);
>      return b;
>  }
> -- 
> 1.7.12.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:35:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:35: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 1U8rqb-0007br-CS; Fri, 22 Feb 2013 12:35: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 1U8rqa-0007bm-Eu
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:35:28 +0000
Received: from [85.158.137.99:10773] by server-1.bemta-3.messagelabs.com id
	54/E5-08955-F0667215; Fri, 22 Feb 2013 12:35:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361536520!15247648!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2483 invoked from network); 22 Feb 2013 12:35:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="8547308"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 12:35:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 07:35:18 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8rqQ-0000gl-HR;
	Fri, 22 Feb 2013 12:35:18 +0000
Date: Fri, 22 Feb 2013 12:35:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1302221233080.22997@kaball.uk.xensource.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
	base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Xudong Hao wrote:
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically.
> 
> The use case of this register defination is for Xen till now.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

Thanks for the patch!

Aside from Jan's comment on the pci config endianness, I would also like
to see an #define somewhere in QEMU to specific what's the default TOM.
In particular I wouldn't want 0xe0000000 (and 0xf0000000) to be
hardcoded in more than one place.


>  hw/pc.h       |  4 ---
>  hw/pc_piix.c  |  6 -----
>  hw/piix_pci.c | 79 ++++++++++++++++++++++++++++++++++++++++++++---------------
>  3 files changed, 59 insertions(+), 30 deletions(-)
> 
> diff --git a/hw/pc.h b/hw/pc.h
> index fbcf43d..2a60490 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -134,10 +134,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory,
>                      MemoryRegion *ram_memory);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0a6923d..98cf467 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>                                system_memory, system_io, ram_size,
> -                              below_4g_mem_size,
> -                              0x100000000ULL - below_4g_mem_size,
> -                              0x100000000ULL + above_4g_mem_size,
> -                              (sizeof(hwaddr) == 4
> -                               ? 0
> -                               : ((uint64_t)1 << 62)),
>                                pci_memory, ram_memory);
>      } else {
>          pci_bus = NULL;
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3d79c73..88bd688 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -86,6 +86,14 @@ struct PCII440FXState {
>  #define I440FX_PAM_SIZE 7
>  #define I440FX_SMRAM    0x72
>  
> +/* The maximum vaule of TOM(top of memory) register in I440FX
> + * is 1G, so it doesn't meet any popular virutal machines, so
> + * define another register to report the base of PCI memory.
> + * Use four bytes 0xb0-0xb3 for this purpose, they are originally
> + * resevered for host bridge.
> + * */
> +#define I440FX_PCI_HOLE_BASE 0xb0
> +
>  static void piix3_set_irq(void *opaque, int pirq, int level);
>  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
>  static void piix3_write_config_xen(PCIDevice *dev,
> @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> +
> +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> +{
> +    ram_addr_t above_4g_mem_size;
> +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
> +
> +    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 4);
> +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> +
> +    if (ram_size >= pci_hole_start) {
> +        above_4g_mem_size = ram_size - pci_hole_start;
> +    } else {
> +        above_4g_mem_size = 0;
> +    }
> +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> +
> +    if (del) {
> +        memory_region_del_subregion(f->system_memory, &f->pci_hole);
> +        if (pci_hole64_size) {
> +            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
> +        }
> +    }
> +
> +    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> +                             pci_hole_start, pci_hole_size);
> +    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> +                             f->pci_address_space,
> +                             pci_hole64_start, pci_hole64_size);
> +    if (pci_hole64_size) {
> +        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> +                                    &f->pci_hole_64bit);
> +    }
> +}
> +
> +
>  static void i440fx_update_memory_mappings(PCII440FXState *d)
>  {
>      int i;
> @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
>          range_covers_byte(address, len, I440FX_SMRAM)) {
>          i440fx_update_memory_mappings(d);
>      }
> +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> +        i440fx_update_pci_mem_hole(d, true);
> +    }
>  }
>  
>  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    if (xen_enabled()) {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> +    } else {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> +    }
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }
> @@ -214,10 +272,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>                                    MemoryRegion *address_space_mem,
>                                    MemoryRegion *address_space_io,
>                                    ram_addr_t ram_size,
> -                                  hwaddr pci_hole_start,
> -                                  hwaddr pci_hole_size,
> -                                  hwaddr pci_hole64_start,
> -                                  hwaddr pci_hole64_size,
>                                    MemoryRegion *pci_address_space,
>                                    MemoryRegion *ram_memory)
>  {
> @@ -244,16 +298,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      f->system_memory = address_space_mem;
>      f->pci_address_space = pci_address_space;
>      f->ram_memory = ram_memory;
> -    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> -                             pci_hole_start, pci_hole_size);
> -    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> -                             f->pci_address_space,
> -                             pci_hole64_start, pci_hole64_size);
> -    if (pci_hole64_size) {
> -        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> -                                    &f->pci_hole_64bit);
> -    }
>      memory_region_init_alias(&f->smram_region, "smram-region",
>                               f->pci_address_space, 0xa0000, 0x20000);
>      memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
> @@ -295,6 +339,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      (*pi440fx_state)->dev.config[0x57]=ram_size;
>  
>      i440fx_update_memory_mappings(f);
> +    i440fx_update_pci_mem_hole(f, false);
>  
>      return b;
>  }
> @@ -304,10 +349,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory, MemoryRegion *ram_memory)
>  
>  {
> @@ -315,8 +356,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>  
>      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
>                             address_space_mem, address_space_io, ram_size,
> -                           pci_hole_start, pci_hole_size,
> -                           pci_hole64_start, pci_hole64_size,
>                             pci_memory, ram_memory);
>      return b;
>  }
> -- 
> 1.7.12.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:44:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12: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 1U8ryd-00080B-Cq; Fri, 22 Feb 2013 12:43:47 +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 1U8ryb-000806-U9
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:43:46 +0000
Received: from [85.158.137.99:37786] by server-14.bemta-3.messagelabs.com id
	01/5A-23533-10867215; Fri, 22 Feb 2013 12:43:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361537020!11950851!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18047 invoked from network); 22 Feb 2013 12:43:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:43:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1782033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:43: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.297.1; Fri, 22 Feb 2013 12:43:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8ryV-0000wT-Iu; Fri, 22 Feb 2013 12:43:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8ryV-0002ud-Ez;
	Fri, 22 Feb 2013 12:43:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.26619.350562.868457@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 12:43:39 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5126437D02000078000C0006@nat28.tlf.novell.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich writes ("Re: Moving xen*.hg to git"):
> So one thing I found very handy with hg was that there was a
> single line history with easy to look at changeset numbers. Is there
> any way to achieve the same with git? I'm asking particularly in the
> context of backporting: In order to pick changes from unstable (now
> master), so far I simply scanned the history, tracking (on a sheet of
> paper) at which c/s I last left off.

Of course you can do this
  git-log <last>..master
or whatever to show all the commits which are included in master but
not in <last>.

Replace <last> with the hex commit id from your piece of paper, and
when you're done write down the commit id of master.  You can also get
git to remember where you got up to by making a local tag with
git-tag.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:44:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12: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 1U8ryd-00080B-Cq; Fri, 22 Feb 2013 12:43:47 +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 1U8ryb-000806-U9
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:43:46 +0000
Received: from [85.158.137.99:37786] by server-14.bemta-3.messagelabs.com id
	01/5A-23533-10867215; Fri, 22 Feb 2013 12:43:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361537020!11950851!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18047 invoked from network); 22 Feb 2013 12:43:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:43:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1782033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:43: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.297.1; Fri, 22 Feb 2013 12:43:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8ryV-0000wT-Iu; Fri, 22 Feb 2013 12:43:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8ryV-0002ud-Ez;
	Fri, 22 Feb 2013 12:43:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.26619.350562.868457@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 12:43:39 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <5126437D02000078000C0006@nat28.tlf.novell.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
	<5126437D02000078000C0006@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich writes ("Re: Moving xen*.hg to git"):
> So one thing I found very handy with hg was that there was a
> single line history with easy to look at changeset numbers. Is there
> any way to achieve the same with git? I'm asking particularly in the
> context of backporting: In order to pick changes from unstable (now
> master), so far I simply scanned the history, tracking (on a sheet of
> paper) at which c/s I last left off.

Of course you can do this
  git-log <last>..master
or whatever to show all the commits which are included in master but
not in <last>.

Replace <last> with the hex commit id from your piece of paper, and
when you're done write down the commit id of master.  You can also get
git to remember where you got up to by making a local tag with
git-tag.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:45: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 1U8rzi-00083d-Ss; Fri, 22 Feb 2013 12:44: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 1U8rzh-00083Q-8v
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:44:53 +0000
Received: from [193.109.254.147:10037] by server-2.bemta-14.messagelabs.com id
	92/7F-16277-44867215; Fri, 22 Feb 2013 12:44:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361537092!6248534!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 22 Feb 2013 12:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1782065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:44: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.297.1; Fri, 22 Feb 2013 12:44:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8rzf-0000wr-Nw; Fri, 22 Feb 2013 12:44:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8rzf-0002uq-KB;
	Fri, 22 Feb 2013 12:44:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.26691.498806.840757@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 12:44:51 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("Moving xen*.hg to git"):
> The process will be as follows:
>   1. Autotester push gate shut down
>   2. Announcement and coordination with committers
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped
>   5. git tree made writeable by committers.
>   6. git->hg mirror outputs checked for sanity
>   7. git->hg mirror enabled, pointing at old hg trees
>   8. Autotester push gate told to use git and restarted

The autotester has been a bit confused, trying to produce logs between
hg and git commit ids, etc.  I think it's sorted now but we'll see...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 12:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 12:45: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 1U8rzi-00083d-Ss; Fri, 22 Feb 2013 12:44: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 1U8rzh-00083Q-8v
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 12:44:53 +0000
Received: from [193.109.254.147:10037] by server-2.bemta-14.messagelabs.com id
	92/7F-16277-44867215; Fri, 22 Feb 2013 12:44:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361537092!6248534!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 22 Feb 2013 12:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 12:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1782065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 12:44: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.297.1; Fri, 22 Feb 2013 12:44:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8rzf-0000wr-Nw; Fri, 22 Feb 2013 12:44:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8rzf-0002uq-KB;
	Fri, 22 Feb 2013 12:44:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.26691.498806.840757@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 12:44:51 +0000
To: <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, "Keir
	(Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Anthony Perard
	<anthony.perard@citrix.com>
In-Reply-To: <20772.60284.798388.635292@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
	<20772.60284.798388.635292@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("Moving xen*.hg to git"):
> The process will be as follows:
>   1. Autotester push gate shut down
>   2. Announcement and coordination with committers
>   3. hg trees made read-only (other than by forthcoming git->hg mirror)
>   4. hg->git mirroring process stopped
>   5. git tree made writeable by committers.
>   6. git->hg mirror outputs checked for sanity
>   7. git->hg mirror enabled, pointing at old hg trees
>   8. Autotester push gate told to use git and restarted

The autotester has been a bit confused, trying to produce logs between
hg and git commit ids, etc.  I think it's sorted now but we'll see...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:10:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13: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 1U8sOM-0000MR-6J; Fri, 22 Feb 2013 13:10:22 +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 1U8sOK-0000MM-Rp
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:10:20 +0000
Received: from [85.158.139.211:5492] by server-4.bemta-5.messagelabs.com id
	0B/A5-29496-B3E67215; Fri, 22 Feb 2013 13:10:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361538618!17267683!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1429 invoked from network); 22 Feb 2013 13:10:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 13:10:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 13:10:03 +0000
Message-Id: <51277C7602000078000C0634@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 13:11:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
	<51273D9D02000078000C03D4@nat28.tlf.novell.com>
	<51275C8C.80506@citrix.com>
In-Reply-To: <51275C8C.80506@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
 load/unload 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>
Content-Type: text/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.02.13 at 12:54, David Vrabel <david.vrabel@citrix.com> wrote:
> I take your point though and will change it to use the dom heap.  Is
> there a way to verify that all the map/unmaps are correctly done and it
> isn't just working by chance?  Some sort of debug option?

Not currently (other than running out of map space at some point,
resulting in a BUG_ON() to trigger).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:10:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13: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 1U8sOM-0000MR-6J; Fri, 22 Feb 2013 13:10:22 +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 1U8sOK-0000MM-Rp
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:10:20 +0000
Received: from [85.158.139.211:5492] by server-4.bemta-5.messagelabs.com id
	0B/A5-29496-B3E67215; Fri, 22 Feb 2013 13:10:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361538618!17267683!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1429 invoked from network); 22 Feb 2013 13:10:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 13:10:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 13:10:03 +0000
Message-Id: <51277C7602000078000C0634@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 13:11:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-6-git-send-email-david.vrabel@citrix.com>
	<51273D9D02000078000C03D4@nat28.tlf.novell.com>
	<51275C8C.80506@citrix.com>
In-Reply-To: <51275C8C.80506@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved
 load/unload 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>
Content-Type: text/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.02.13 at 12:54, David Vrabel <david.vrabel@citrix.com> wrote:
> I take your point though and will change it to use the dom heap.  Is
> there a way to verify that all the map/unmaps are correctly done and it
> isn't just working by chance?  Some sort of debug option?

Not currently (other than running out of map space at some point,
resulting in a BUG_ON() to trigger).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:11:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13:11: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 1U8sOq-0000OQ-P8; Fri, 22 Feb 2013 13:10:52 +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 1U8sOp-0000OC-74
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:10:51 +0000
Received: from [85.158.139.211:64094] by server-7.bemta-5.messagelabs.com id
	64/D2-11121-95E67215; Fri, 22 Feb 2013 13:10:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361538637!18789773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18818 invoked from network); 22 Feb 2013 13:10:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 13:10:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 13:09:00 +0000
Message-Id: <51277C3502000078000C0631@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 13:09:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
	<51273B8502000078000C03BF@nat28.tlf.novell.com>
	<51275B84.2030905@citrix.com>
In-Reply-To: <51275B84.2030905@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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.02.13 at 12:50, David Vrabel <david.vrabel@citrix.com> wrote:
> On 22/02/13 08:33, Jan Beulich wrote:
>>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>>> --- a/xen/include/public/kexec.h
>>> +++ b/xen/include/public/kexec.h
>>> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>>>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>>>   * image == relocation information for kexec (ignored for unload) [in]
>>>   */
>>> -#define KEXEC_CMD_kexec_load            1
>>> -#define KEXEC_CMD_kexec_unload          2
>>> -typedef struct xen_kexec_load {
>>> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
>>> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
>>> +typedef struct xen_kexec_load_v1 {
>>>      int type;
>>>      xen_kexec_image_t image;
>>> -} xen_kexec_load_t;
>>> +} xen_kexec_load_v1_t;
>> 
>> You can't change type names like this without also guarding them
>> with a __XEN_INTERFACE_VERSION__ conditional or providing
>> backward compatibility #define-s.
> 
> There are backward compatible definitions provided at the end of the
> header file.

There's a typedef producing xen_kexec_load_t, but there's no
way for a consumer to use struct xen_kexec_load afaics.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:11:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13:11: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 1U8sOq-0000OQ-P8; Fri, 22 Feb 2013 13:10:52 +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 1U8sOp-0000OC-74
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:10:51 +0000
Received: from [85.158.139.211:64094] by server-7.bemta-5.messagelabs.com id
	64/D2-11121-95E67215; Fri, 22 Feb 2013 13:10:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361538637!18789773!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18818 invoked from network); 22 Feb 2013 13:10:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 13:10:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 13:09:00 +0000
Message-Id: <51277C3502000078000C0631@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 13:09:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
	<1361468894-18655-4-git-send-email-david.vrabel@citrix.com>
	<51273B8502000078000C03BF@nat28.tlf.novell.com>
	<51275B84.2030905@citrix.com>
In-Reply-To: <51275B84.2030905@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for
 improved load/unload sub-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>
Content-Type: text/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.02.13 at 12:50, David Vrabel <david.vrabel@citrix.com> wrote:
> On 22/02/13 08:33, Jan Beulich wrote:
>>>>> On 21.02.13 at 18:48, David Vrabel <david.vrabel@citrix.com> wrote:
>>> --- a/xen/include/public/kexec.h
>>> +++ b/xen/include/public/kexec.h
>>> @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec {
>>>   * type  == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in]
>>>   * image == relocation information for kexec (ignored for unload) [in]
>>>   */
>>> -#define KEXEC_CMD_kexec_load            1
>>> -#define KEXEC_CMD_kexec_unload          2
>>> -typedef struct xen_kexec_load {
>>> +#define KEXEC_CMD_kexec_load_v1         1 /* obsolete since 0x00040300 */
>>> +#define KEXEC_CMD_kexec_unload_v1       2 /* obsolete since 0x00040300 */
>>> +typedef struct xen_kexec_load_v1 {
>>>      int type;
>>>      xen_kexec_image_t image;
>>> -} xen_kexec_load_t;
>>> +} xen_kexec_load_v1_t;
>> 
>> You can't change type names like this without also guarding them
>> with a __XEN_INTERFACE_VERSION__ conditional or providing
>> backward compatibility #define-s.
> 
> There are backward compatible definitions provided at the end of the
> header file.

There's a typedef producing xen_kexec_load_t, but there's no
way for a consumer to use struct xen_kexec_load afaics.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:12:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13: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 1U8sPk-0000gM-7V; Fri, 22 Feb 2013 13:11:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1U8sPi-0000be-Gs
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:11:46 +0000
Received: from [193.109.254.147:60571] by server-11.bemta-14.messagelabs.com
	id D8/41-30685-19E67215; Fri, 22 Feb 2013 13:11:45 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361538530!8642977!1
X-Originating-IP: [209.85.214.47]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31746 invoked from network); 22 Feb 2013 13:08:51 -0000
Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com)
	(209.85.214.47)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 13:08:51 -0000
Received: by mail-bk0-f47.google.com with SMTP id jc3so276645bkc.6
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 05:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=S9Ree64bjl71eYBP65A5UX9ybVy22fCxrh8FTmk9BU0=;
	b=vq6Wht7pGgpC+6u7WvCyKA66jqFX8jCuO4qnJ4wPKnRQX4lsYJAZaXq2APnDjLhhm5
	UQy8kq427pc8rd8cvBxiPfVIBl1Kx4040iyOpxHgqeN3H5/ggHlf8ZI93Y8mgy3329vg
	jAaYW/+lqkzzPP9Hgo/oDxgGBVjmWWoQ5oOLKkPwE8vnea44WyBKWWOmCjutDs1j1sZQ
	4G4XLPsc4YMVKF6KqhNqX8N4DJW1+DDTj50rq7uWQKkEhIpR+Gm82is33JQI3APY+EAC
	WxgbiCeFO0m0qoVYyIxQmOvF+8iO7BlBKhx9rDPdx8TsBPSK+shZ+u03ECK3N2E4Z4P4
	p6ww==
X-Received: by 10.204.147.18 with SMTP id j18mr984949bkv.2.1361538530802; Fri,
	22 Feb 2013 05:08:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.37.203 with HTTP; Fri, 22 Feb 2013 05:08:30 -0800 (PST)
In-Reply-To: <511E660E.7000107@canonical.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
	<20130215164010.GE13775@phenom.dumpdata.com>
	<511E660E.7000107@canonical.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Fri, 22 Feb 2013 14:08:30 +0100
Message-ID: <CAJ75kXZQno5MEeKj39vrNUbwt3fFJ8SeQ4vOXoRJtwR=04WVVA@mail.gmail.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 5:45 PM, Stefan Bader
<stefan.bader@canonical.com> wrote:
> Not sure it makes the difference but keep in mind that the report is about a 3.2
> kernel. They initially claimed that 3.5 works, but then some comments seem to
> say that was when using dom0_mem= which would in that case work around the bug.
> Maybe time to go back and ask whether a recent kernel without dom0_mem on the
> same machine still crashes...

I have the same issue on a dom0 3.4.x (3.4.33 in my case)

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:12:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13: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 1U8sPk-0000gM-7V; Fri, 22 Feb 2013 13:11:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1U8sPi-0000be-Gs
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:11:46 +0000
Received: from [193.109.254.147:60571] by server-11.bemta-14.messagelabs.com
	id D8/41-30685-19E67215; Fri, 22 Feb 2013 13:11:45 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361538530!8642977!1
X-Originating-IP: [209.85.214.47]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31746 invoked from network); 22 Feb 2013 13:08:51 -0000
Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com)
	(209.85.214.47)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 13:08:51 -0000
Received: by mail-bk0-f47.google.com with SMTP id jc3so276645bkc.6
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 05:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=S9Ree64bjl71eYBP65A5UX9ybVy22fCxrh8FTmk9BU0=;
	b=vq6Wht7pGgpC+6u7WvCyKA66jqFX8jCuO4qnJ4wPKnRQX4lsYJAZaXq2APnDjLhhm5
	UQy8kq427pc8rd8cvBxiPfVIBl1Kx4040iyOpxHgqeN3H5/ggHlf8ZI93Y8mgy3329vg
	jAaYW/+lqkzzPP9Hgo/oDxgGBVjmWWoQ5oOLKkPwE8vnea44WyBKWWOmCjutDs1j1sZQ
	4G4XLPsc4YMVKF6KqhNqX8N4DJW1+DDTj50rq7uWQKkEhIpR+Gm82is33JQI3APY+EAC
	WxgbiCeFO0m0qoVYyIxQmOvF+8iO7BlBKhx9rDPdx8TsBPSK+shZ+u03ECK3N2E4Z4P4
	p6ww==
X-Received: by 10.204.147.18 with SMTP id j18mr984949bkv.2.1361538530802; Fri,
	22 Feb 2013 05:08:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.37.203 with HTTP; Fri, 22 Feb 2013 05:08:30 -0800 (PST)
In-Reply-To: <511E660E.7000107@canonical.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
	<20130215164010.GE13775@phenom.dumpdata.com>
	<511E660E.7000107@canonical.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Fri, 22 Feb 2013 14:08:30 +0100
Message-ID: <CAJ75kXZQno5MEeKj39vrNUbwt3fFJ8SeQ4vOXoRJtwR=04WVVA@mail.gmail.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 15, 2013 at 5:45 PM, Stefan Bader
<stefan.bader@canonical.com> wrote:
> Not sure it makes the difference but keep in mind that the report is about a 3.2
> kernel. They initially claimed that 3.5 works, but then some comments seem to
> say that was when using dom0_mem= which would in that case work around the bug.
> Maybe time to go back and ask whether a recent kernel without dom0_mem on the
> same machine still crashes...

I have the same issue on a dom0 3.4.x (3.4.33 in my case)

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 13:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13:22: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 1U8sZl-0001Ha-G5; Fri, 22 Feb 2013 13:22:09 +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 1U8sZk-0001HV-B6
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:22:08 +0000
Received: from [85.158.143.99:37059] by server-1.bemta-4.messagelabs.com id
	E0/E7-06203-FF077215; Fri, 22 Feb 2013 13:22:07 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361539326!28770357!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 22 Feb 2013 13:22:06 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 13:22:06 -0000
Received: from p5b2e3f6a.dip.t-dialin.net ([91.46.63.106] 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 1U8sZg-0004yH-KZ; Fri, 22 Feb 2013 13:22:04 +0000
Message-ID: <512770FB.7060509@canonical.com>
Date: Fri, 22 Feb 2013 14:22:03 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: William Dauchy <wdauchy@gmail.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
	<20130215164010.GE13775@phenom.dumpdata.com>
	<511E660E.7000107@canonical.com>
	<CAJ75kXZQno5MEeKj39vrNUbwt3fFJ8SeQ4vOXoRJtwR=04WVVA@mail.gmail.com>
In-Reply-To: <CAJ75kXZQno5MEeKj39vrNUbwt3fFJ8SeQ4vOXoRJtwR=04WVVA@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Cc: xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7028842432055193350=="
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)
--===============7028842432055193350==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigE5BC87C96D4896EFBD73AB04"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE5BC87C96D4896EFBD73AB04
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 22.02.2013 14:08, William Dauchy wrote:
> On Fri, Feb 15, 2013 at 5:45 PM, Stefan Bader
> <stefan.bader@canonical.com> wrote:
>> Not sure it makes the difference but keep in mind that the report is a=
bout a 3.2
>> kernel. They initially claimed that 3.5 works, but then some comments =
seem to
>> say that was when using dom0_mem=3D which would in that case work arou=
nd the bug.
>> Maybe time to go back and ask whether a recent kernel without dom0_mem=
 on the
>> same machine still crashes...
>=20
> I have the same issue on a dom0 3.4.x (3.4.33 in my case)
>=20
Hrm, while my reporter claims the affected machine boots with kernel 3.3 =
and
later. Something is wrong with the picture... somewhere... :/

-Stefan


--------------enigE5BC87C96D4896EFBD73AB04
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRJ3D7AAoJEOhnXe7L7s6js/8P/09v9cUAgyCuREgfD93Fp0qC
Mqd1v+paEkYuymRXEpKRnvGYCcgxo25OH8wvzSFeGKATNn+88HFvanOOwCcUc5US
Qp00EAgtQAi5hawPq+3PDcJZM8mmf8lTkGmBQYNS11glT23xZYS6YlK6Temh84ag
OQy+CYsrABmk6j9IvGNJSSaMHCBitKm0uqx8xigSawyHyRzcD8tc/2NytPNoIB3T
qa6Y4Qa5jSdcy2ivXnBssUEDI3CsTofu07KXhuYnXJaKFp1fRLqYXeGSustu107N
krUgAV7iRZ5LmN1HgooTOwEGSJugHPjf912t7UD3J6NNM9XpfJ0vy7Vq7JWGQg6s
XiT+ElyZn+uJhVxdUGeW2Bf/0MyfJGMtzY619PK3CSMdM1NVUO4LiALnreWdM8lx
w6FvcMY0GdY4QObpkElsyhUqV+mriCmyaWP3ZGehJJK9PCNHgzFxWOUVZNdSHzfo
ubnVDpkxjbRh5+nsMI57O4hyD/CP+/O6s5zeM7MqpORPRYnOMnke6euMw/PyjVZ8
4kVcNs3dHh16zvOxTR3s2ya7U3vlj61M3dQ3OB1hrYr+/jZwZ3wf8QHjM+3Fud+M
bvNc8i3sA8Naw2mX1hGtYNiNZTsmzmY4NdIN8FrvsOoSgRK1QoOwg8jBcMKGp/zO
mjMDo1XG1po7XOhgbTi+
=b2Bh
-----END PGP SIGNATURE-----

--------------enigE5BC87C96D4896EFBD73AB04--


--===============7028842432055193350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7028842432055193350==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 13:22:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13:22: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 1U8sZl-0001Ha-G5; Fri, 22 Feb 2013 13:22:09 +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 1U8sZk-0001HV-B6
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 13:22:08 +0000
Received: from [85.158.143.99:37059] by server-1.bemta-4.messagelabs.com id
	E0/E7-06203-FF077215; Fri, 22 Feb 2013 13:22:07 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361539326!28770357!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 22 Feb 2013 13:22:06 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 13:22:06 -0000
Received: from p5b2e3f6a.dip.t-dialin.net ([91.46.63.106] 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 1U8sZg-0004yH-KZ; Fri, 22 Feb 2013 13:22:04 +0000
Message-ID: <512770FB.7060509@canonical.com>
Date: Fri, 22 Feb 2013 14:22:03 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: William Dauchy <wdauchy@gmail.com>
References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com>
	<511E0BBE02000078000BE9A8@nat28.tlf.novell.com>
	<511E0F34.6010107@canonical.com>
	<511E268002000078000BE9FA@nat28.tlf.novell.com>
	<20130215134720.GG11777@phenom.dumpdata.com>
	<511E59C902000078000BEC18@nat28.tlf.novell.com>
	<20130215164010.GE13775@phenom.dumpdata.com>
	<511E660E.7000107@canonical.com>
	<CAJ75kXZQno5MEeKj39vrNUbwt3fFJ8SeQ4vOXoRJtwR=04WVVA@mail.gmail.com>
In-Reply-To: <CAJ75kXZQno5MEeKj39vrNUbwt3fFJ8SeQ4vOXoRJtwR=04WVVA@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Cc: xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when
 not covered by MTRRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7028842432055193350=="
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)
--===============7028842432055193350==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigE5BC87C96D4896EFBD73AB04"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE5BC87C96D4896EFBD73AB04
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 22.02.2013 14:08, William Dauchy wrote:
> On Fri, Feb 15, 2013 at 5:45 PM, Stefan Bader
> <stefan.bader@canonical.com> wrote:
>> Not sure it makes the difference but keep in mind that the report is a=
bout a 3.2
>> kernel. They initially claimed that 3.5 works, but then some comments =
seem to
>> say that was when using dom0_mem=3D which would in that case work arou=
nd the bug.
>> Maybe time to go back and ask whether a recent kernel without dom0_mem=
 on the
>> same machine still crashes...
>=20
> I have the same issue on a dom0 3.4.x (3.4.33 in my case)
>=20
Hrm, while my reporter claims the affected machine boots with kernel 3.3 =
and
later. Something is wrong with the picture... somewhere... :/

-Stefan


--------------enigE5BC87C96D4896EFBD73AB04
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRJ3D7AAoJEOhnXe7L7s6js/8P/09v9cUAgyCuREgfD93Fp0qC
Mqd1v+paEkYuymRXEpKRnvGYCcgxo25OH8wvzSFeGKATNn+88HFvanOOwCcUc5US
Qp00EAgtQAi5hawPq+3PDcJZM8mmf8lTkGmBQYNS11glT23xZYS6YlK6Temh84ag
OQy+CYsrABmk6j9IvGNJSSaMHCBitKm0uqx8xigSawyHyRzcD8tc/2NytPNoIB3T
qa6Y4Qa5jSdcy2ivXnBssUEDI3CsTofu07KXhuYnXJaKFp1fRLqYXeGSustu107N
krUgAV7iRZ5LmN1HgooTOwEGSJugHPjf912t7UD3J6NNM9XpfJ0vy7Vq7JWGQg6s
XiT+ElyZn+uJhVxdUGeW2Bf/0MyfJGMtzY619PK3CSMdM1NVUO4LiALnreWdM8lx
w6FvcMY0GdY4QObpkElsyhUqV+mriCmyaWP3ZGehJJK9PCNHgzFxWOUVZNdSHzfo
ubnVDpkxjbRh5+nsMI57O4hyD/CP+/O6s5zeM7MqpORPRYnOMnke6euMw/PyjVZ8
4kVcNs3dHh16zvOxTR3s2ya7U3vlj61M3dQ3OB1hrYr+/jZwZ3wf8QHjM+3Fud+M
bvNc8i3sA8Naw2mX1hGtYNiNZTsmzmY4NdIN8FrvsOoSgRK1QoOwg8jBcMKGp/zO
mjMDo1XG1po7XOhgbTi+
=b2Bh
-----END PGP SIGNATURE-----

--------------enigE5BC87C96D4896EFBD73AB04--


--===============7028842432055193350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7028842432055193350==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 13:54:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13:54: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 1U8t50-0002Al-Ip; Fri, 22 Feb 2013 13:54:26 +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 1U8t4y-0002Ag-Pl
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 13:54:25 +0000
Received: from [85.158.138.51:33397] by server-13.bemta-3.messagelabs.com id
	D2/8F-20653-F8877215; Fri, 22 Feb 2013 13:54:23 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361541259!21003201!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 22 Feb 2013 13:54:20 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-174.messagelabs.com with SMTP;
	22 Feb 2013 13:54:20 -0000
Received: from p5b2e3f6a.dip.t-dialin.net ([91.46.63.106] 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 1U8t4s-0005x3-Ir; Fri, 22 Feb 2013 13:54:18 +0000
Message-ID: <51277888.50908@canonical.com>
Date: Fri, 22 Feb 2013 14:54:16 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Enigmail-Version: 1.4.6
Cc: Colin Ian King <colin.king@canonical.com>
Subject: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8724829359746806098=="
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)
--===============8724829359746806098==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig7522780D77765EAEDB8A3A8D"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7522780D77765EAEDB8A3A8D
Content-Type: multipart/mixed;
 boundary="------------030502040503010602030802"

This is a multi-part message in MIME format.
--------------030502040503010602030802
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Konrad,

here is another one from the hm-what? department:

Colin discovered that running the attached program with the fork active (=
e.g.
"./mmap-example -f 0x10000", the address can be that or iomem) this trigg=
ers the
following weird messages:

[ 6824.453724] mmap-example:3481 map pfn expected mapping type write-back=
 for
[mem 0x00010000-0x00010fff], got uncached-minus
[ 6824.453776] ------------[ cut here ]------------
[ 6824.453796] WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:77=
4
untrack_pfn+0xb8/0xd0()
=2E..
[ 6824.453920] Pid: 3481, comm: mmap-example Tainted: GF
3.8.0-6-generic #13-Ubuntu
[ 6824.453926] Call Trace:
[ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
[ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
[ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
[ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
[ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
[ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
[ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
[ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
[ 6824.454027]  [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
[ 6824.454038]  [<ffffffff81057931>] do_fork+0x91/0x350
[ 6824.454048]  [<ffffffff81057c76>] sys_clone+0x16/0x20
[ 6824.454060]  [<ffffffff816ccbf9>] stub_clone+0x69/0x90
[ 6824.454069]  [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f
[ 6824.454076] ---[ end trace 4918cdd0a4c9fea4 ]---

I found that this is related to your bandaid patch

commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Feb 10 09:16:27 2012 -0500

    xen/pat: Disable PAT support for now.

I just do not understand how this happens. From the trace it seems the fo=
rk
fails when duplicating the VMAs (dup_mm calls mmput on failure). So maybe=
 the
warning is just related to this. So primarily the question is how on fork=
 the
_PAGE_PCD bit can become set? That and _PAGE_PWT are cleared from the sup=
ported
mask by the patch, so somehow I would think nothing should be able to set=
 it...
But apparently not so.
Not sure it is a big deal since I never saw this in normal operation and =
it
seems to be ok when unapping before doing the fork. It is just plain odd.=


-Stefan

--------------030502040503010602030802
Content-Type: text/x-csrc;
 name="mmap-example.c"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="mmap-example.c"

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>

int main(int argc, char **argv)
{
	uint8_t *data;
	int fd;
	unsigned long long offset;
	pid_t pid;
	int status;
	int opt;
	bool opt_fork =3D false;

	while ((opt =3D getopt(argc, argv, "f")) !=3D -1) {
		switch (opt) {
		case 'f':
			opt_fork =3D true;
			break;
		}
	}

	if (argc <=3D optind) {
		fprintf(stderr, "%s: [-f] address\n", argv[0]);
		fprintf(stderr, "\t-f specifices if we should fork with the mmap\n");
		exit(EXIT_FAILURE);
	}
	if (sscanf(argv[optind], "%lli", &offset) !=3D 1) {
		fprintf(stderr, "Cannot determine mmap address from %s\n", argv[optind]=
);
		exit(EXIT_FAILURE);
	}

	if ((fd =3D open("/dev/mem", O_RDONLY)) < 0) {
		fprintf(stderr, "Cannot open /dev/mem\n");
		exit(EXIT_FAILURE);
	}

	printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095);

	if ((data =3D mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, (off_t)offset=
)) =3D=3D MAP_FAILED) {
		fprintf(stderr, "Cannot mmap 0x%llx\n", offset);
		exit(EXIT_FAILURE);
	}

	close(fd);

	if (opt_fork) {
		pid =3D fork();
		if (pid =3D=3D 0) {
			/* child */
			_exit(0);
		} else {
			/* parent */
			waitpid(pid, &status, 0);
		}
	}

	if (munmap(data, 4096) < 0) {
		fprintf(stderr, "Cannot munmap %p\n", data);
		exit(EXIT_FAILURE);
	}
	exit(EXIT_SUCCESS);
}


--------------030502040503010602030802--

--------------enig7522780D77765EAEDB8A3A8D
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRJ3iJAAoJEOhnXe7L7s6jPw4QAOetxY2qfwACXWGpfDaErHiG
NHUJ1/IL0eNJ6mOd23bNHUKvWYIosiDM3Ujasz3mA82qCrrUqYM/WGPvGUjTDPMI
4zsK5Kasr8auwZiJALWLhB33nemJN5y/IFqHHiDRPLD2kZNMgXP0oztWUL1yMFMN
BPfCYeMC5mT4z7PjcOu9bBQbTkgzqJJGtJRP805IJ2AdQB0G/o4NJPaTr8RrHtSj
9TPSr1oKwQABvUnRIjTLMyGVaD7lh58eQ/UVtzY17LYnhtydqypsgOnn7+TpvYIn
arGUffVICP3OeyJilwVeFKL4ZnqKJ0dPI/cVNDv0kmWqRcE2O4H1knEOMG3t75AN
b+BQP/Z8qSZBPF+Z3DF3mwh8pcQnbiSKxgSTB36ozXn3G2yqMzPs8gzfuBiNZMXg
BtVz00fw+ZTy30ymZ6T3zKa9hMPc3r6Rhwmung5qfQuHOx3JrajZrKi+12f8P0dT
BPBIcLtnRjjkyPnd2F7CidhiIGi1NC87TBwPbyTxA+lzPV3A709eOr7yegfFizD0
HI+omSTCtjEYRsJ+UW60gxfFH/eUd31TIHT2LbL4tbDFuU6+5+7k0ae1D1CgwFxw
Mn+x+x7s4ub3NhJOyZvWwuc640Yi3ive4i/S75ETtsPTjeB2ozOclH4tmGEPIxo4
HYknnUhNEmL+b7HBCTbA
=IIIv
-----END PGP SIGNATURE-----

--------------enig7522780D77765EAEDB8A3A8D--


--===============8724829359746806098==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8724829359746806098==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 13:54:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 13:54: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 1U8t50-0002Al-Ip; Fri, 22 Feb 2013 13:54:26 +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 1U8t4y-0002Ag-Pl
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 13:54:25 +0000
Received: from [85.158.138.51:33397] by server-13.bemta-3.messagelabs.com id
	D2/8F-20653-F8877215; Fri, 22 Feb 2013 13:54:23 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361541259!21003201!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 22 Feb 2013 13:54:20 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-174.messagelabs.com with SMTP;
	22 Feb 2013 13:54:20 -0000
Received: from p5b2e3f6a.dip.t-dialin.net ([91.46.63.106] 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 1U8t4s-0005x3-Ir; Fri, 22 Feb 2013 13:54:18 +0000
Message-ID: <51277888.50908@canonical.com>
Date: Fri, 22 Feb 2013 14:54:16 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Enigmail-Version: 1.4.6
Cc: Colin Ian King <colin.king@canonical.com>
Subject: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8724829359746806098=="
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)
--===============8724829359746806098==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig7522780D77765EAEDB8A3A8D"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7522780D77765EAEDB8A3A8D
Content-Type: multipart/mixed;
 boundary="------------030502040503010602030802"

This is a multi-part message in MIME format.
--------------030502040503010602030802
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Konrad,

here is another one from the hm-what? department:

Colin discovered that running the attached program with the fork active (=
e.g.
"./mmap-example -f 0x10000", the address can be that or iomem) this trigg=
ers the
following weird messages:

[ 6824.453724] mmap-example:3481 map pfn expected mapping type write-back=
 for
[mem 0x00010000-0x00010fff], got uncached-minus
[ 6824.453776] ------------[ cut here ]------------
[ 6824.453796] WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:77=
4
untrack_pfn+0xb8/0xd0()
=2E..
[ 6824.453920] Pid: 3481, comm: mmap-example Tainted: GF
3.8.0-6-generic #13-Ubuntu
[ 6824.453926] Call Trace:
[ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
[ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
[ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
[ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
[ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
[ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
[ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
[ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
[ 6824.454027]  [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
[ 6824.454038]  [<ffffffff81057931>] do_fork+0x91/0x350
[ 6824.454048]  [<ffffffff81057c76>] sys_clone+0x16/0x20
[ 6824.454060]  [<ffffffff816ccbf9>] stub_clone+0x69/0x90
[ 6824.454069]  [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f
[ 6824.454076] ---[ end trace 4918cdd0a4c9fea4 ]---

I found that this is related to your bandaid patch

commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Feb 10 09:16:27 2012 -0500

    xen/pat: Disable PAT support for now.

I just do not understand how this happens. From the trace it seems the fo=
rk
fails when duplicating the VMAs (dup_mm calls mmput on failure). So maybe=
 the
warning is just related to this. So primarily the question is how on fork=
 the
_PAGE_PCD bit can become set? That and _PAGE_PWT are cleared from the sup=
ported
mask by the patch, so somehow I would think nothing should be able to set=
 it...
But apparently not so.
Not sure it is a big deal since I never saw this in normal operation and =
it
seems to be ok when unapping before doing the fork. It is just plain odd.=


-Stefan

--------------030502040503010602030802
Content-Type: text/x-csrc;
 name="mmap-example.c"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="mmap-example.c"

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>

int main(int argc, char **argv)
{
	uint8_t *data;
	int fd;
	unsigned long long offset;
	pid_t pid;
	int status;
	int opt;
	bool opt_fork =3D false;

	while ((opt =3D getopt(argc, argv, "f")) !=3D -1) {
		switch (opt) {
		case 'f':
			opt_fork =3D true;
			break;
		}
	}

	if (argc <=3D optind) {
		fprintf(stderr, "%s: [-f] address\n", argv[0]);
		fprintf(stderr, "\t-f specifices if we should fork with the mmap\n");
		exit(EXIT_FAILURE);
	}
	if (sscanf(argv[optind], "%lli", &offset) !=3D 1) {
		fprintf(stderr, "Cannot determine mmap address from %s\n", argv[optind]=
);
		exit(EXIT_FAILURE);
	}

	if ((fd =3D open("/dev/mem", O_RDONLY)) < 0) {
		fprintf(stderr, "Cannot open /dev/mem\n");
		exit(EXIT_FAILURE);
	}

	printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095);

	if ((data =3D mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, (off_t)offset=
)) =3D=3D MAP_FAILED) {
		fprintf(stderr, "Cannot mmap 0x%llx\n", offset);
		exit(EXIT_FAILURE);
	}

	close(fd);

	if (opt_fork) {
		pid =3D fork();
		if (pid =3D=3D 0) {
			/* child */
			_exit(0);
		} else {
			/* parent */
			waitpid(pid, &status, 0);
		}
	}

	if (munmap(data, 4096) < 0) {
		fprintf(stderr, "Cannot munmap %p\n", data);
		exit(EXIT_FAILURE);
	}
	exit(EXIT_SUCCESS);
}


--------------030502040503010602030802--

--------------enig7522780D77765EAEDB8A3A8D
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRJ3iJAAoJEOhnXe7L7s6jPw4QAOetxY2qfwACXWGpfDaErHiG
NHUJ1/IL0eNJ6mOd23bNHUKvWYIosiDM3Ujasz3mA82qCrrUqYM/WGPvGUjTDPMI
4zsK5Kasr8auwZiJALWLhB33nemJN5y/IFqHHiDRPLD2kZNMgXP0oztWUL1yMFMN
BPfCYeMC5mT4z7PjcOu9bBQbTkgzqJJGtJRP805IJ2AdQB0G/o4NJPaTr8RrHtSj
9TPSr1oKwQABvUnRIjTLMyGVaD7lh58eQ/UVtzY17LYnhtydqypsgOnn7+TpvYIn
arGUffVICP3OeyJilwVeFKL4ZnqKJ0dPI/cVNDv0kmWqRcE2O4H1knEOMG3t75AN
b+BQP/Z8qSZBPF+Z3DF3mwh8pcQnbiSKxgSTB36ozXn3G2yqMzPs8gzfuBiNZMXg
BtVz00fw+ZTy30ymZ6T3zKa9hMPc3r6Rhwmung5qfQuHOx3JrajZrKi+12f8P0dT
BPBIcLtnRjjkyPnd2F7CidhiIGi1NC87TBwPbyTxA+lzPV3A709eOr7yegfFizD0
HI+omSTCtjEYRsJ+UW60gxfFH/eUd31TIHT2LbL4tbDFuU6+5+7k0ae1D1CgwFxw
Mn+x+x7s4ub3NhJOyZvWwuc640Yi3ive4i/S75ETtsPTjeB2ozOclH4tmGEPIxo4
HYknnUhNEmL+b7HBCTbA
=IIIv
-----END PGP SIGNATURE-----

--------------enig7522780D77765EAEDB8A3A8D--


--===============8724829359746806098==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8724829359746806098==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 14:04:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14: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 1U8tES-0002cf-Pf; Fri, 22 Feb 2013 14:04: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 1U8tER-0002ca-Kz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:04:11 +0000
Received: from [85.158.137.99:27509] by server-9.bemta-3.messagelabs.com id
	06/1B-09484-ADA77215; Fri, 22 Feb 2013 14:04:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361541661!12244063!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12857 invoked from network); 22 Feb 2013 14:01:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:01:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 14:00:01 +0000
Message-Id: <5127882D02000078000C068D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 14:01:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
In-Reply-To: <20130221173115.GA13045@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> It did not happen with xl.

But the same guest and Dom0 kernel, and the same hypervisor?

> Here is the output while doing xm migrate:
> 
> (XEN) HVM2 restore: VMCE_VCPU 0
> (XEN) HVM2 restore: VMCE_VCPU 1
> (XEN) HVM2 restore: TSC_ADJUST 0
> (XEN) HVM2 restore: TSC_ADJUST 1
> (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001

Didn't even notice yesterday that this is apparently after restore
has already started. Which makes me curious whether the domain
that is being referenced with rd= is the old or the new one (would
require printing the domain ID; honestly I never understood what
use printing of the domain pointer is).

I'm also confused by the domain pointer always being the same;
I would expect it to at least toggle between two values, but
probably even be different between every instance of the guest.
But you're not having a stubdom configured for the guest either,
according to the config you sent earlier...

> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c0170fb2>] get_page+0xfb/0x151
> (XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
> (XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
> (XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
> (XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
> (XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
> (XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
> (XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145

The only user of grant copies is netback, and hence I would suppose
that the failed transmit (in whichever direction) is simply being retried,
thus preventing the error from becoming user visible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:04:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14: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 1U8tES-0002cf-Pf; Fri, 22 Feb 2013 14:04: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 1U8tER-0002ca-Kz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:04:11 +0000
Received: from [85.158.137.99:27509] by server-9.bemta-3.messagelabs.com id
	06/1B-09484-ADA77215; Fri, 22 Feb 2013 14:04:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361541661!12244063!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12857 invoked from network); 22 Feb 2013 14:01:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:01:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 14:00:01 +0000
Message-Id: <5127882D02000078000C068D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 14:01:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
In-Reply-To: <20130221173115.GA13045@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> It did not happen with xl.

But the same guest and Dom0 kernel, and the same hypervisor?

> Here is the output while doing xm migrate:
> 
> (XEN) HVM2 restore: VMCE_VCPU 0
> (XEN) HVM2 restore: VMCE_VCPU 1
> (XEN) HVM2 restore: TSC_ADJUST 0
> (XEN) HVM2 restore: TSC_ADJUST 1
> (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001

Didn't even notice yesterday that this is apparently after restore
has already started. Which makes me curious whether the domain
that is being referenced with rd= is the old or the new one (would
require printing the domain ID; honestly I never understood what
use printing of the domain pointer is).

I'm also confused by the domain pointer always being the same;
I would expect it to at least toggle between two values, but
probably even be different between every instance of the guest.
But you're not having a stubdom configured for the guest either,
according to the config you sent earlier...

> (XEN) Xen call trace:
> (XEN)    [<ffff82c4c0170fb2>] get_page+0xfb/0x151
> (XEN)    [<ffff82c4c01e1d87>] get_page_from_gfn_p2m+0x17e/0x284
> (XEN)    [<ffff82c4c01098ae>] __get_paged_frame+0x5d/0x170
> (XEN)    [<ffff82c4c0109e55>] __acquire_grant_for_copy+0x494/0x6ae
> (XEN)    [<ffff82c4c010bef0>] gnttab_copy+0x53b/0x843
> (XEN)    [<ffff82c4c010e3b8>] do_grant_table_op+0x11c5/0x1b82
> (XEN)    [<ffff82c4c011502f>] do_multicall+0x227/0x444
> (XEN)    [<ffff82c4c0227f0b>] syscall_enter+0xeb/0x145

The only user of grant copies is netback, and hence I would suppose
that the failed transmit (in whichever direction) is simply being retried,
thus preventing the error from becoming user visible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:17:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:17: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 1U8tQj-00031L-U6; Fri, 22 Feb 2013 14:16:53 +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 1U8tQi-00031G-PB
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:16:52 +0000
Received: from [85.158.137.99:30552] by server-2.bemta-3.messagelabs.com id
	A1/3F-25961-3DD77215; Fri, 22 Feb 2013 14:16:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361542610!14450911!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 22 Feb 2013 14:16:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:16:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 14:16:50 +0000
Message-Id: <51278C1D02000078000C06A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 14:17:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <E1U2iMn-0008As-4b@xenbits.xen.org>
In-Reply-To: <E1U2iMn-0008As-4b@xenbits.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen Security Advisory 43 (CVE-2013-0231) - Linux
 pciback DoS via not rate limited log 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 05.02.13 at 14:15, Xen.org security team <security@xen.org> wrote:
> RESOLUTION
> ==========
> 
> Applying the appropriate attached patch resolves this issue.
> 
> xsa43-pvops.patch            Apply to mainline Linux 3.8-rc5.

I realized the other day that stable@ wasn't Cc-ed on this one
either, and I think it would be more authoritative if you as the
maintainer of the patched code asked for this being added there.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:17:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:17: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 1U8tQj-00031L-U6; Fri, 22 Feb 2013 14:16:53 +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 1U8tQi-00031G-PB
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:16:52 +0000
Received: from [85.158.137.99:30552] by server-2.bemta-3.messagelabs.com id
	A1/3F-25961-3DD77215; Fri, 22 Feb 2013 14:16:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361542610!14450911!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 22 Feb 2013 14:16:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:16:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 14:16:50 +0000
Message-Id: <51278C1D02000078000C06A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 14:17:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <E1U2iMn-0008As-4b@xenbits.xen.org>
In-Reply-To: <E1U2iMn-0008As-4b@xenbits.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen Security Advisory 43 (CVE-2013-0231) - Linux
 pciback DoS via not rate limited log 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 05.02.13 at 14:15, Xen.org security team <security@xen.org> wrote:
> RESOLUTION
> ==========
> 
> Applying the appropriate attached patch resolves this issue.
> 
> xsa43-pvops.patch            Apply to mainline Linux 3.8-rc5.

I realized the other day that stable@ wasn't Cc-ed on this one
either, and I think it would be more authoritative if you as the
maintainer of the patched code asked for this being added there.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:30:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8tda-0003Yd-DT; Fri, 22 Feb 2013 14:30:10 +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 1U8tdY-0003YY-K7
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:30:08 +0000
Received: from [85.158.138.51:45599] by server-6.bemta-3.messagelabs.com id
	CF/8E-29959-FE087215; Fri, 22 Feb 2013 14:30:07 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361543386!21009677!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17334 invoked from network); 22 Feb 2013 14:29:49 -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;
	22 Feb 2013 14:29:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="9010963"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 14:28:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 09:28:31 -0500
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 1U8tc0-0002j1-4J;
	Fri, 22 Feb 2013 14:28:32 +0000
Message-ID: <51277EC1.7020707@eu.citrix.com>
Date: Fri, 22 Feb 2013 14:20:49 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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-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

Whose ACKs do you need for this to be checked in?

  -George

On 21/02/13 16:13, Frediano Ziglio wrote:
> Updated set of patches for coverage.
>
> Changes:
> - remove small outdated note on commit text
> - add signature where missing
> - rebased
>
> Frediano Ziglio (5):
>    gcov: Call constructors during initialization
>    gcov: Adding support for coverage information
>    gcov: Implement code to read coverage informations
>    gcov: Add small utility to deal with test coverage information from
>      Xen
>    gcov: Add documentation for coverage
>
>   .gitignore                  |    3 +
>   .hgignore                   |    3 +
>   Config.mk                   |    3 +
>   docs/misc/coverage.markdown |   39 ++++++++
>   tools/misc/Makefile         |    8 +-
>   tools/misc/xencov.c         |  152 +++++++++++++++++++++++++++++
>   xen/Rules.mk                |    2 +
>   xen/arch/arm/setup.c        |    2 +
>   xen/arch/arm/xen.lds.S      |    7 ++
>   xen/arch/x86/setup.c        |    2 +
>   xen/arch/x86/xen.lds.S      |    7 ++
>   xen/common/Makefile         |    2 +
>   xen/common/gcov/Makefile    |    2 +
>   xen/common/gcov/gcov.c      |  225 +++++++++++++++++++++++++++++++++++++++++++
>   xen/common/lib.c            |   14 +++
>   xen/common/sysctl.c         |    6 ++
>   xen/include/public/gcov.h   |  115 ++++++++++++++++++++++
>   xen/include/public/sysctl.h |   38 ++++++++
>   xen/include/xen/gcov.h      |   93 ++++++++++++++++++
>   xen/include/xen/lib.h       |    2 +
>   20 files changed, 723 insertions(+), 2 deletions(-)
>   create mode 100644 docs/misc/coverage.markdown
>   create mode 100644 tools/misc/xencov.c
>   create mode 100644 xen/common/gcov/Makefile
>   create mode 100644 xen/common/gcov/gcov.c
>   create mode 100644 xen/include/public/gcov.h
>   create mode 100644 xen/include/xen/gcov.h
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:30:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8tda-0003Yd-DT; Fri, 22 Feb 2013 14:30:10 +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 1U8tdY-0003YY-K7
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:30:08 +0000
Received: from [85.158.138.51:45599] by server-6.bemta-3.messagelabs.com id
	CF/8E-29959-FE087215; Fri, 22 Feb 2013 14:30:07 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361543386!21009677!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17334 invoked from network); 22 Feb 2013 14:29:49 -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;
	22 Feb 2013 14:29:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="9010963"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 14:28:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 09:28:31 -0500
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 1U8tc0-0002j1-4J;
	Fri, 22 Feb 2013 14:28:32 +0000
Message-ID: <51277EC1.7020707@eu.citrix.com>
Date: Fri, 22 Feb 2013 14:20:49 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Frediano Ziglio <frediano.ziglio@citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
In-Reply-To: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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-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

Whose ACKs do you need for this to be checked in?

  -George

On 21/02/13 16:13, Frediano Ziglio wrote:
> Updated set of patches for coverage.
>
> Changes:
> - remove small outdated note on commit text
> - add signature where missing
> - rebased
>
> Frediano Ziglio (5):
>    gcov: Call constructors during initialization
>    gcov: Adding support for coverage information
>    gcov: Implement code to read coverage informations
>    gcov: Add small utility to deal with test coverage information from
>      Xen
>    gcov: Add documentation for coverage
>
>   .gitignore                  |    3 +
>   .hgignore                   |    3 +
>   Config.mk                   |    3 +
>   docs/misc/coverage.markdown |   39 ++++++++
>   tools/misc/Makefile         |    8 +-
>   tools/misc/xencov.c         |  152 +++++++++++++++++++++++++++++
>   xen/Rules.mk                |    2 +
>   xen/arch/arm/setup.c        |    2 +
>   xen/arch/arm/xen.lds.S      |    7 ++
>   xen/arch/x86/setup.c        |    2 +
>   xen/arch/x86/xen.lds.S      |    7 ++
>   xen/common/Makefile         |    2 +
>   xen/common/gcov/Makefile    |    2 +
>   xen/common/gcov/gcov.c      |  225 +++++++++++++++++++++++++++++++++++++++++++
>   xen/common/lib.c            |   14 +++
>   xen/common/sysctl.c         |    6 ++
>   xen/include/public/gcov.h   |  115 ++++++++++++++++++++++
>   xen/include/public/sysctl.h |   38 ++++++++
>   xen/include/xen/gcov.h      |   93 ++++++++++++++++++
>   xen/include/xen/lib.h       |    2 +
>   20 files changed, 723 insertions(+), 2 deletions(-)
>   create mode 100644 docs/misc/coverage.markdown
>   create mode 100644 tools/misc/xencov.c
>   create mode 100644 xen/common/gcov/Makefile
>   create mode 100644 xen/common/gcov/gcov.c
>   create mode 100644 xen/include/public/gcov.h
>   create mode 100644 xen/include/xen/gcov.h
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:36:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:36: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 1U8tjD-00041d-VF; Fri, 22 Feb 2013 14:35:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8tjC-00041X-5W
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:35:58 +0000
Received: from [85.158.139.211:13760] by server-5.bemta-5.messagelabs.com id
	28/0A-11945-B4287215; Fri, 22 Feb 2013 14:35:55 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361543755!18806164!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17839 invoked from network); 22 Feb 2013 14:35:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 14:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1788106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 14:35:56 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 22 Feb 2013
	14:35:55 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Fri, 22 Feb 2013 14:35:54 +0000
Thread-Topic: [PATCH v10 0/5] gcov: Coverage support
Thread-Index: Ac4RCeuLLp7ig88PTUCCMfuZQdOD8A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D4583A2@LONPMAILBOX01.citrite.net>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<51277EC1.7020707@eu.citrix.com>
In-Reply-To: <51277EC1.7020707@eu.citrix.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: "konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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

I don't know. 

Frediano

On Fri, 2013-02-22 at 14:20 +0000, George Dunlap wrote:
> Whose ACKs do you need for this to be checked in?
> 
>   -George
> 
> On 21/02/13 16:13, Frediano Ziglio wrote:
> > Updated set of patches for coverage.
> >
> > Changes:
> > - remove small outdated note on commit text
> > - add signature where missing
> > - rebased
> >
> > Frediano Ziglio (5):
> >    gcov: Call constructors during initialization
> >    gcov: Adding support for coverage information
> >    gcov: Implement code to read coverage informations
> >    gcov: Add small utility to deal with test coverage information from
> >      Xen
> >    gcov: Add documentation for coverage
> >
> >   .gitignore                  |    3 +
> >   .hgignore                   |    3 +
> >   Config.mk                   |    3 +
> >   docs/misc/coverage.markdown |   39 ++++++++
> >   tools/misc/Makefile         |    8 +-
> >   tools/misc/xencov.c         |  152 +++++++++++++++++++++++++++++
> >   xen/Rules.mk                |    2 +
> >   xen/arch/arm/setup.c        |    2 +
> >   xen/arch/arm/xen.lds.S      |    7 ++
> >   xen/arch/x86/setup.c        |    2 +
> >   xen/arch/x86/xen.lds.S      |    7 ++
> >   xen/common/Makefile         |    2 +
> >   xen/common/gcov/Makefile    |    2 +
> >   xen/common/gcov/gcov.c      |  225 +++++++++++++++++++++++++++++++++++++++++++
> >   xen/common/lib.c            |   14 +++
> >   xen/common/sysctl.c         |    6 ++
> >   xen/include/public/gcov.h   |  115 ++++++++++++++++++++++
> >   xen/include/public/sysctl.h |   38 ++++++++
> >   xen/include/xen/gcov.h      |   93 ++++++++++++++++++
> >   xen/include/xen/lib.h       |    2 +
> >   20 files changed, 723 insertions(+), 2 deletions(-)
> >   create mode 100644 docs/misc/coverage.markdown
> >   create mode 100644 tools/misc/xencov.c
> >   create mode 100644 xen/common/gcov/Makefile
> >   create mode 100644 xen/common/gcov/gcov.c
> >   create mode 100644 xen/include/public/gcov.h
> >   create mode 100644 xen/include/xen/gcov.h
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:36:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:36: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 1U8tjD-00041d-VF; Fri, 22 Feb 2013 14:35:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1U8tjC-00041X-5W
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:35:58 +0000
Received: from [85.158.139.211:13760] by server-5.bemta-5.messagelabs.com id
	28/0A-11945-B4287215; Fri, 22 Feb 2013 14:35:55 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361543755!18806164!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17839 invoked from network); 22 Feb 2013 14:35:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 14:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1788106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 14:35:56 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 22 Feb 2013
	14:35:55 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Fri, 22 Feb 2013 14:35:54 +0000
Thread-Topic: [PATCH v10 0/5] gcov: Coverage support
Thread-Index: Ac4RCeuLLp7ig88PTUCCMfuZQdOD8A==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC201058D4583A2@LONPMAILBOX01.citrite.net>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<51277EC1.7020707@eu.citrix.com>
In-Reply-To: <51277EC1.7020707@eu.citrix.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: "konrad@kernel.org" <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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

I don't know. 

Frediano

On Fri, 2013-02-22 at 14:20 +0000, George Dunlap wrote:
> Whose ACKs do you need for this to be checked in?
> 
>   -George
> 
> On 21/02/13 16:13, Frediano Ziglio wrote:
> > Updated set of patches for coverage.
> >
> > Changes:
> > - remove small outdated note on commit text
> > - add signature where missing
> > - rebased
> >
> > Frediano Ziglio (5):
> >    gcov: Call constructors during initialization
> >    gcov: Adding support for coverage information
> >    gcov: Implement code to read coverage informations
> >    gcov: Add small utility to deal with test coverage information from
> >      Xen
> >    gcov: Add documentation for coverage
> >
> >   .gitignore                  |    3 +
> >   .hgignore                   |    3 +
> >   Config.mk                   |    3 +
> >   docs/misc/coverage.markdown |   39 ++++++++
> >   tools/misc/Makefile         |    8 +-
> >   tools/misc/xencov.c         |  152 +++++++++++++++++++++++++++++
> >   xen/Rules.mk                |    2 +
> >   xen/arch/arm/setup.c        |    2 +
> >   xen/arch/arm/xen.lds.S      |    7 ++
> >   xen/arch/x86/setup.c        |    2 +
> >   xen/arch/x86/xen.lds.S      |    7 ++
> >   xen/common/Makefile         |    2 +
> >   xen/common/gcov/Makefile    |    2 +
> >   xen/common/gcov/gcov.c      |  225 +++++++++++++++++++++++++++++++++++++++++++
> >   xen/common/lib.c            |   14 +++
> >   xen/common/sysctl.c         |    6 ++
> >   xen/include/public/gcov.h   |  115 ++++++++++++++++++++++
> >   xen/include/public/sysctl.h |   38 ++++++++
> >   xen/include/xen/gcov.h      |   93 ++++++++++++++++++
> >   xen/include/xen/lib.h       |    2 +
> >   20 files changed, 723 insertions(+), 2 deletions(-)
> >   create mode 100644 docs/misc/coverage.markdown
> >   create mode 100644 tools/misc/xencov.c
> >   create mode 100644 xen/common/gcov/Makefile
> >   create mode 100644 xen/common/gcov/gcov.c
> >   create mode 100644 xen/include/public/gcov.h
> >   create mode 100644 xen/include/xen/gcov.h
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:36:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:36: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 1U8tjb-00042n-Cm; Fri, 22 Feb 2013 14:36:23 +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 1U8tjZ-00042T-KK
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:36:21 +0000
Received: from [85.158.139.211:15647] by server-12.bemta-5.messagelabs.com id
	6E/B1-20195-46287215; Fri, 22 Feb 2013 14:36:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361543721!18803755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7108 invoked from network); 22 Feb 2013 14:35:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 14:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1788081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 14:35: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.297.1;
	Fri, 22 Feb 2013 14:35:21 +0000
Message-ID: <1361543720.26546.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 22 Feb 2013 14:35:20 +0000
In-Reply-To: <51277EC1.7020707@eu.citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<51277EC1.7020707@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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 Fri, 2013-02-22 at 14:20 +0000, George Dunlap wrote:
> Whose ACKs do you need for this to be checked in?

It's in now.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:36:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:36: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 1U8tjb-00042n-Cm; Fri, 22 Feb 2013 14:36:23 +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 1U8tjZ-00042T-KK
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:36:21 +0000
Received: from [85.158.139.211:15647] by server-12.bemta-5.messagelabs.com id
	6E/B1-20195-46287215; Fri, 22 Feb 2013 14:36:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361543721!18803755!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7108 invoked from network); 22 Feb 2013 14:35:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 14:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; 
   d="scan'208";a="1788081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 14:35: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.297.1;
	Fri, 22 Feb 2013 14:35:21 +0000
Message-ID: <1361543720.26546.125.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Fri, 22 Feb 2013 14:35:20 +0000
In-Reply-To: <51277EC1.7020707@eu.citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<51277EC1.7020707@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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 Fri, 2013-02-22 at 14:20 +0000, George Dunlap wrote:
> Whose ACKs do you need for this to be checked in?

It's in now.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:38:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14: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 1U8tlO-0004Cj-UN; Fri, 22 Feb 2013 14:38: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 1U8tlM-0004CY-O5
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:38:12 +0000
Received: from [85.158.137.99:61192] by server-8.bemta-3.messagelabs.com id
	66/E8-25687-FC287215; Fri, 22 Feb 2013 14:38:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361543886!17627663!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32159 invoked from network); 22 Feb 2013 14:38:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:38:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 14:38:06 +0000
Message-Id: <5127911802000078000C06CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 14:39:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>,
	"George Dunlap" <george.dunlap@eu.citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<51277EC1.7020707@eu.citrix.com>
In-Reply-To: <51277EC1.7020707@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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 22.02.13 at 15:20, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> Whose ACKs do you need for this to be checked in?

Keir committed these already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:38:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14: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 1U8tlO-0004Cj-UN; Fri, 22 Feb 2013 14:38: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 1U8tlM-0004CY-O5
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 14:38:12 +0000
Received: from [85.158.137.99:61192] by server-8.bemta-3.messagelabs.com id
	66/E8-25687-FC287215; Fri, 22 Feb 2013 14:38:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361543886!17627663!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32159 invoked from network); 22 Feb 2013 14:38:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:38:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 14:38:06 +0000
Message-Id: <5127911802000078000C06CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 14:39:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Frediano Ziglio" <frediano.ziglio@citrix.com>,
	"George Dunlap" <george.dunlap@eu.citrix.com>
References: <1361463225-21750-1-git-send-email-frediano.ziglio@citrix.com>
	<51277EC1.7020707@eu.citrix.com>
In-Reply-To: <51277EC1.7020707@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v10 0/5] gcov: Coverage 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 22.02.13 at 15:20, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> Whose ACKs do you need for this to be checked in?

Keir committed these already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 14:51:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:51: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 1U8txg-0004jL-7t; Fri, 22 Feb 2013 14:50: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 1U8txf-0004jG-Bs
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 14:50:55 +0000
Received: from [193.109.254.147:6747] by server-9.bemta-14.messagelabs.com id
	2A/3F-30867-EC587215; Fri, 22 Feb 2013 14:50:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361544651!8983123!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 22 Feb 2013 14:50:53 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 14:50:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MEonqs029250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 14:50:50 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
	r1MEom1Q014097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 14:50:49 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
	r1MEomso028377; Fri, 22 Feb 2013 08:50:48 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 06:50:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 57C6F1C3935; Fri, 22 Feb 2013 09:50:47 -0500 (EST)
Date: Fri, 22 Feb 2013 09:50:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20130222145047.GA8017@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.9-rc0-tag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8494694214791259383=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8494694214791259383==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A"
Content-Disposition: inline


--9zSXsLTf0vkW971A
Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.9-rc0-tag

which has two new ACPI drivers for Xen - a physical CPU offline/online and
a memory hotplug. The way this works is that ACPI kicks the drivers and they
make the appropiate hypercall to the hypervisor to tell it that there is a new
CPU or memory. There also some changes to the Xen ARM ABIs and couple of fixes.
One particularly nasty bug in the Xen PV spinlock code was fixed by Stefan Bader
- and has been there since the 2.6.32!

During the linux-next cycle we found that some of the changes in Rafael's
pm+acpi-3.9-rc1 tree will cause compile conflicts with my tree.
Stephen Rothwell found and developed a fix - which I am including as an
attachment to this - please apply it immediately after my tree. There are some
other patches that ought to be done on top of this to deal with the new ACPI API
changes - I've them in this #linux-next-resolved tree:

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved

if you are curious - but I was thinking to submit them _after_ the rc1 has been
tagged as I am sure I will have some bug-fixes. There looks to be a lot
of regressions this season already :-(

 arch/arm/include/asm/xen/events.h |  22 ++
 arch/arm/include/asm/xen/page.h   |   4 +
 arch/arm/xen/enlighten.c          |   8 +-
 arch/x86/include/asm/xen/events.h |   3 +
 arch/x86/include/asm/xen/page.h   |   2 +
 arch/x86/xen/smp.c                |  42 ++--
 arch/x86/xen/spinlock.c           |   1 -
 drivers/tty/hvc/hvc_xen.c         |   2 +-
 drivers/xen/Kconfig               |  34 +++
 drivers/xen/Makefile              |   3 +
 drivers/xen/events.c              | 115 +++++----
 drivers/xen/evtchn.c              |  14 +-
 drivers/xen/grant-table.c         |   2 +-
 drivers/xen/pcpu.c                |  35 +++
 drivers/xen/tmem.c                |   2 +-
 drivers/xen/xen-acpi-cpuhotplug.c | 471 +++++++++++++++++++++++++++++++++++++
 drivers/xen/xen-acpi-memhotplug.c | 483 ++++++++++++++++++++++++++++++++++++++
 drivers/xen/xen-stub.c            | 101 ++++++++
 drivers/xen/xenbus/xenbus_probe.c |   2 +-
 include/xen/acpi.h                |  35 +++
 include/xen/interface/memory.h    |   6 +
 include/xen/interface/platform.h  |  21 +-
 include/xen/interface/xen.h       |   8 +-
 23 files changed, 1331 insertions(+), 85 deletions(-)

Ian Campbell (2):
      xen: implement updated XENMEM_add_to_physmap_range ABI
      xen: event channel arrays are xen_ulong_t and not unsigned long

Konrad Rzeszutek Wilk (2):
      xen/smp: Move the common CPU init code a bit to prep for PVH patch.
      xen/tmem: Add missing %s in the printk statement.

Liu Jinsong (6):
      xen/stub: driver for memory hotplug
      xen/acpi: ACPI memory hotplug
      xen/stub: driver for CPU hotplug
      xen/acpi: Move xen_acpi_get_pxm to Xen's acpi.h
      xen/acpi: ACPI cpu hotplug
      xen/acpi: move xen_acpi_get_pxm under CONFIG_XEN_DOM0

Stefan Bader (1):
      xen: Send spinlock IPI to all waiters

Stefano Stabellini (1):
      xen: introduce xen_remap, use it instead of ioremap

Wei Liu (2):
      xen-evtchn: correct comment and error output
      xen: close evtchn port if binding to irq fails


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-xen-acpi-fix-up-for-apci_bus_add-api-change.patch"
Content-Transfer-Encoding: quoted-printable

=46rom 56810ee0f6d5ce9da9f5dddfc459ee0041eb22cc Mon Sep 17 00:00:00 2001
=46rom: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Feb 2013 15:45:51 +1100
Subject: [PATCH] xen/acpi: fix up for apci_bus_add api change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-acpi-cpuhotplug.c | 2 +-
 drivers/xen/xen-acpi-memhotplug.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuho=
tplug.c
index 9eefbb0..acc5b12 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -251,7 +251,7 @@ int acpi_processor_device_add(acpi_handle handle, struc=
t acpi_device **device)
 	if (acpi_bus_get_device(phandle, &pdev))
 		return -ENODEV;
=20
-	if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR))
+	if (acpi_bus_scan(handle))
 		return -ENODEV;
=20
 	return 0;
diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memho=
tplug.c
index 678680c..164287b 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -188,7 +188,7 @@ acpi_memory_get_device(acpi_handle handle,
 	 * Now add the notified device.  This creates the acpi_device
 	 * and invokes .add function
 	 */
-	result =3D acpi_bus_add(&device, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
+	result =3D acpi_bus_scan(handle);
 	if (result) {
 		pr_warn(PREFIX "Cannot add acpi bus\n");
 		return -EINVAL;
--=20
1.8.0.2


--oyUTqETQ0mS9luUI--

--9zSXsLTf0vkW971A
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQEcBAEBAgAGBQJRJ4XBAAoJEFjIrFwIi8fJKQYIAKT23ASusPoYamrmn7hKFdx8
9C+GpeQY+HeuLanH17dRZuIRFtclXKGNugV8nswhJEGzsxkEFWV/8xo+A2wX3X3w
qsu8L1LSsvGERGGqNs0BQK0A+aeIeRi1hZMGhYhpIK+XqqLoAJrBHOpuu/jJea5N
v8PxrY3jCuanBnq7EsfLTGMCJBG7tClXel6sHXSU/htCPwPT+zo+f4tOC+uwkDqN
FFG36vTsdnFpbzqP9IaIfYRwFuFz0pAF5OZOnl9lp0rIghGHQs+9CwzvDB0rYrnx
bVa7dVe2E6CVY9rMw3UoesJaSZzsdO3WO+ItpbBqN8OLadmpMoFAX1pECY1+eNs=
=B8G4
-----END PGP SIGNATURE-----

--9zSXsLTf0vkW971A--


--===============8494694214791259383==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8494694214791259383==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 14:51:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14:51: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 1U8txg-0004jL-7t; Fri, 22 Feb 2013 14:50: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 1U8txf-0004jG-Bs
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 14:50:55 +0000
Received: from [193.109.254.147:6747] by server-9.bemta-14.messagelabs.com id
	2A/3F-30867-EC587215; Fri, 22 Feb 2013 14:50:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361544651!8983123!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 22 Feb 2013 14:50:53 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 14:50:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MEonqs029250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 14:50:50 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
	r1MEom1Q014097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 14:50:49 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
	r1MEomso028377; Fri, 22 Feb 2013 08:50:48 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 06:50:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 57C6F1C3935; Fri, 22 Feb 2013 09:50:47 -0500 (EST)
Date: Fri, 22 Feb 2013 09:50:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20130222145047.GA8017@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.9-rc0-tag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8494694214791259383=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8494694214791259383==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A"
Content-Disposition: inline


--9zSXsLTf0vkW971A
Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.9-rc0-tag

which has two new ACPI drivers for Xen - a physical CPU offline/online and
a memory hotplug. The way this works is that ACPI kicks the drivers and they
make the appropiate hypercall to the hypervisor to tell it that there is a new
CPU or memory. There also some changes to the Xen ARM ABIs and couple of fixes.
One particularly nasty bug in the Xen PV spinlock code was fixed by Stefan Bader
- and has been there since the 2.6.32!

During the linux-next cycle we found that some of the changes in Rafael's
pm+acpi-3.9-rc1 tree will cause compile conflicts with my tree.
Stephen Rothwell found and developed a fix - which I am including as an
attachment to this - please apply it immediately after my tree. There are some
other patches that ought to be done on top of this to deal with the new ACPI API
changes - I've them in this #linux-next-resolved tree:

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved

if you are curious - but I was thinking to submit them _after_ the rc1 has been
tagged as I am sure I will have some bug-fixes. There looks to be a lot
of regressions this season already :-(

 arch/arm/include/asm/xen/events.h |  22 ++
 arch/arm/include/asm/xen/page.h   |   4 +
 arch/arm/xen/enlighten.c          |   8 +-
 arch/x86/include/asm/xen/events.h |   3 +
 arch/x86/include/asm/xen/page.h   |   2 +
 arch/x86/xen/smp.c                |  42 ++--
 arch/x86/xen/spinlock.c           |   1 -
 drivers/tty/hvc/hvc_xen.c         |   2 +-
 drivers/xen/Kconfig               |  34 +++
 drivers/xen/Makefile              |   3 +
 drivers/xen/events.c              | 115 +++++----
 drivers/xen/evtchn.c              |  14 +-
 drivers/xen/grant-table.c         |   2 +-
 drivers/xen/pcpu.c                |  35 +++
 drivers/xen/tmem.c                |   2 +-
 drivers/xen/xen-acpi-cpuhotplug.c | 471 +++++++++++++++++++++++++++++++++++++
 drivers/xen/xen-acpi-memhotplug.c | 483 ++++++++++++++++++++++++++++++++++++++
 drivers/xen/xen-stub.c            | 101 ++++++++
 drivers/xen/xenbus/xenbus_probe.c |   2 +-
 include/xen/acpi.h                |  35 +++
 include/xen/interface/memory.h    |   6 +
 include/xen/interface/platform.h  |  21 +-
 include/xen/interface/xen.h       |   8 +-
 23 files changed, 1331 insertions(+), 85 deletions(-)

Ian Campbell (2):
      xen: implement updated XENMEM_add_to_physmap_range ABI
      xen: event channel arrays are xen_ulong_t and not unsigned long

Konrad Rzeszutek Wilk (2):
      xen/smp: Move the common CPU init code a bit to prep for PVH patch.
      xen/tmem: Add missing %s in the printk statement.

Liu Jinsong (6):
      xen/stub: driver for memory hotplug
      xen/acpi: ACPI memory hotplug
      xen/stub: driver for CPU hotplug
      xen/acpi: Move xen_acpi_get_pxm to Xen's acpi.h
      xen/acpi: ACPI cpu hotplug
      xen/acpi: move xen_acpi_get_pxm under CONFIG_XEN_DOM0

Stefan Bader (1):
      xen: Send spinlock IPI to all waiters

Stefano Stabellini (1):
      xen: introduce xen_remap, use it instead of ioremap

Wei Liu (2):
      xen-evtchn: correct comment and error output
      xen: close evtchn port if binding to irq fails


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-xen-acpi-fix-up-for-apci_bus_add-api-change.patch"
Content-Transfer-Encoding: quoted-printable

=46rom 56810ee0f6d5ce9da9f5dddfc459ee0041eb22cc Mon Sep 17 00:00:00 2001
=46rom: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Feb 2013 15:45:51 +1100
Subject: [PATCH] xen/acpi: fix up for apci_bus_add api change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-acpi-cpuhotplug.c | 2 +-
 drivers/xen/xen-acpi-memhotplug.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuho=
tplug.c
index 9eefbb0..acc5b12 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -251,7 +251,7 @@ int acpi_processor_device_add(acpi_handle handle, struc=
t acpi_device **device)
 	if (acpi_bus_get_device(phandle, &pdev))
 		return -ENODEV;
=20
-	if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR))
+	if (acpi_bus_scan(handle))
 		return -ENODEV;
=20
 	return 0;
diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memho=
tplug.c
index 678680c..164287b 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -188,7 +188,7 @@ acpi_memory_get_device(acpi_handle handle,
 	 * Now add the notified device.  This creates the acpi_device
 	 * and invokes .add function
 	 */
-	result =3D acpi_bus_add(&device, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
+	result =3D acpi_bus_scan(handle);
 	if (result) {
 		pr_warn(PREFIX "Cannot add acpi bus\n");
 		return -EINVAL;
--=20
1.8.0.2


--oyUTqETQ0mS9luUI--

--9zSXsLTf0vkW971A
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQEcBAEBAgAGBQJRJ4XBAAoJEFjIrFwIi8fJKQYIAKT23ASusPoYamrmn7hKFdx8
9C+GpeQY+HeuLanH17dRZuIRFtclXKGNugV8nswhJEGzsxkEFWV/8xo+A2wX3X3w
qsu8L1LSsvGERGGqNs0BQK0A+aeIeRi1hZMGhYhpIK+XqqLoAJrBHOpuu/jJea5N
v8PxrY3jCuanBnq7EsfLTGMCJBG7tClXel6sHXSU/htCPwPT+zo+f4tOC+uwkDqN
FFG36vTsdnFpbzqP9IaIfYRwFuFz0pAF5OZOnl9lp0rIghGHQs+9CwzvDB0rYrnx
bVa7dVe2E6CVY9rMw3UoesJaSZzsdO3WO+ItpbBqN8OLadmpMoFAX1pECY1+eNs=
=B8G4
-----END PGP SIGNATURE-----

--9zSXsLTf0vkW971A--


--===============8494694214791259383==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8494694214791259383==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 14:53:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14: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 1U8u07-000547-Qf; Fri, 22 Feb 2013 14:53:27 +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 1U8u06-000540-Ca
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 14:53:26 +0000
Received: from [85.158.139.211:40939] by server-6.bemta-5.messagelabs.com id
	B4/C3-01489-56687215; Fri, 22 Feb 2013 14:53:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361544803!18846113!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTMyNTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16440 invoked from network); 22 Feb 2013 14:53:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:53:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MErJAE029015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 14:53:20 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
	r1MErIvJ018345
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 14:53:18 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
	r1MErITh024977; Fri, 22 Feb 2013 08:53:18 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 06:53:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 083331C3935; Fri, 22 Feb 2013 09:53:17 -0500 (EST)
Date: Fri, 22 Feb 2013 09:53:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>, jinsong.liu@intel.com
Message-ID: <20130222145316.GB8017@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51277888.50908@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> Hi Konrad,

Hey Stefan,
> 
> here is another one from the hm-what? department:

Heh - the really good-bug-hunting one. Lets also include Jinsong as he has
been tracking a similar one with mcelog.
> 
> Colin discovered that running the attached program with the fork active (e.g.
> "./mmap-example -f 0x10000", the address can be that or iomem) this triggers the
> following weird messages:
> 
> [ 6824.453724] mmap-example:3481 map pfn expected mapping type write-back for
> [mem 0x00010000-0x00010fff], got uncached-minus
> [ 6824.453776] ------------[ cut here ]------------
> [ 6824.453796] WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> untrack_pfn+0xb8/0xd0()
> ...
> [ 6824.453920] Pid: 3481, comm: mmap-example Tainted: GF
> 3.8.0-6-generic #13-Ubuntu
> [ 6824.453926] Call Trace:
> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> [ 6824.454027]  [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
> [ 6824.454038]  [<ffffffff81057931>] do_fork+0x91/0x350
> [ 6824.454048]  [<ffffffff81057c76>] sys_clone+0x16/0x20
> [ 6824.454060]  [<ffffffff816ccbf9>] stub_clone+0x69/0x90
> [ 6824.454069]  [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f
> [ 6824.454076] ---[ end trace 4918cdd0a4c9fea4 ]---
> 
> I found that this is related to your bandaid patch
> 
> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Fri Feb 10 09:16:27 2012 -0500
> 
>     xen/pat: Disable PAT support for now.
> 
> I just do not understand how this happens. From the trace it seems the fork
> fails when duplicating the VMAs (dup_mm calls mmput on failure). So maybe the
> warning is just related to this. So primarily the question is how on fork the
> _PAGE_PCD bit can become set? That and _PAGE_PWT are cleared from the supported
> mask by the patch, so somehow I would think nothing should be able to set it...
> But apparently not so.
> Not sure it is a big deal since I never saw this in normal operation and it
> seems to be ok when unapping before doing the fork. It is just plain odd.

Jinsong mentioned that there is some oddity with the MTRR. Somehow the
ranges are swapped or not correct. Jinsong, could you shed some light on
what you have found so far?

> 
> -Stefan

> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <stdbool.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <fcntl.h>
> 
> int main(int argc, char **argv)
> {
> 	uint8_t *data;
> 	int fd;
> 	unsigned long long offset;
> 	pid_t pid;
> 	int status;
> 	int opt;
> 	bool opt_fork = false;
> 
> 	while ((opt = getopt(argc, argv, "f")) != -1) {
> 		switch (opt) {
> 		case 'f':
> 			opt_fork = true;
> 			break;
> 		}
> 	}
> 
> 	if (argc <= optind) {
> 		fprintf(stderr, "%s: [-f] address\n", argv[0]);
> 		fprintf(stderr, "\t-f specifices if we should fork with the mmap\n");
> 		exit(EXIT_FAILURE);
> 	}
> 	if (sscanf(argv[optind], "%lli", &offset) != 1) {
> 		fprintf(stderr, "Cannot determine mmap address from %s\n", argv[optind]);
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	if ((fd = open("/dev/mem", O_RDONLY)) < 0) {
> 		fprintf(stderr, "Cannot open /dev/mem\n");
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095);
> 
> 	if ((data = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, (off_t)offset)) == MAP_FAILED) {
> 		fprintf(stderr, "Cannot mmap 0x%llx\n", offset);
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	close(fd);
> 
> 	if (opt_fork) {
> 		pid = fork();
> 		if (pid == 0) {
> 			/* child */
> 			_exit(0);
> 		} else {
> 			/* parent */
> 			waitpid(pid, &status, 0);
> 		}
> 	}
> 
> 	if (munmap(data, 4096) < 0) {
> 		fprintf(stderr, "Cannot munmap %p\n", data);
> 		exit(EXIT_FAILURE);
> 	}
> 	exit(EXIT_SUCCESS);
> }
> 




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 22 14:53:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 14: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 1U8u07-000547-Qf; Fri, 22 Feb 2013 14:53:27 +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 1U8u06-000540-Ca
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 14:53:26 +0000
Received: from [85.158.139.211:40939] by server-6.bemta-5.messagelabs.com id
	B4/C3-01489-56687215; Fri, 22 Feb 2013 14:53:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361544803!18846113!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTMyNTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16440 invoked from network); 22 Feb 2013 14:53:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 14:53:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MErJAE029015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 14:53:20 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
	r1MErIvJ018345
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 14:53:18 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
	r1MErITh024977; Fri, 22 Feb 2013 08:53:18 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 06:53:18 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 083331C3935; Fri, 22 Feb 2013 09:53:17 -0500 (EST)
Date: Fri, 22 Feb 2013 09:53:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>, jinsong.liu@intel.com
Message-ID: <20130222145316.GB8017@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51277888.50908@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> Hi Konrad,

Hey Stefan,
> 
> here is another one from the hm-what? department:

Heh - the really good-bug-hunting one. Lets also include Jinsong as he has
been tracking a similar one with mcelog.
> 
> Colin discovered that running the attached program with the fork active (e.g.
> "./mmap-example -f 0x10000", the address can be that or iomem) this triggers the
> following weird messages:
> 
> [ 6824.453724] mmap-example:3481 map pfn expected mapping type write-back for
> [mem 0x00010000-0x00010fff], got uncached-minus
> [ 6824.453776] ------------[ cut here ]------------
> [ 6824.453796] WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> untrack_pfn+0xb8/0xd0()
> ...
> [ 6824.453920] Pid: 3481, comm: mmap-example Tainted: GF
> 3.8.0-6-generic #13-Ubuntu
> [ 6824.453926] Call Trace:
> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> [ 6824.454027]  [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
> [ 6824.454038]  [<ffffffff81057931>] do_fork+0x91/0x350
> [ 6824.454048]  [<ffffffff81057c76>] sys_clone+0x16/0x20
> [ 6824.454060]  [<ffffffff816ccbf9>] stub_clone+0x69/0x90
> [ 6824.454069]  [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f
> [ 6824.454076] ---[ end trace 4918cdd0a4c9fea4 ]---
> 
> I found that this is related to your bandaid patch
> 
> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Fri Feb 10 09:16:27 2012 -0500
> 
>     xen/pat: Disable PAT support for now.
> 
> I just do not understand how this happens. From the trace it seems the fork
> fails when duplicating the VMAs (dup_mm calls mmput on failure). So maybe the
> warning is just related to this. So primarily the question is how on fork the
> _PAGE_PCD bit can become set? That and _PAGE_PWT are cleared from the supported
> mask by the patch, so somehow I would think nothing should be able to set it...
> But apparently not so.
> Not sure it is a big deal since I never saw this in normal operation and it
> seems to be ok when unapping before doing the fork. It is just plain odd.

Jinsong mentioned that there is some oddity with the MTRR. Somehow the
ranges are swapped or not correct. Jinsong, could you shed some light on
what you have found so far?

> 
> -Stefan

> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <stdbool.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <fcntl.h>
> 
> int main(int argc, char **argv)
> {
> 	uint8_t *data;
> 	int fd;
> 	unsigned long long offset;
> 	pid_t pid;
> 	int status;
> 	int opt;
> 	bool opt_fork = false;
> 
> 	while ((opt = getopt(argc, argv, "f")) != -1) {
> 		switch (opt) {
> 		case 'f':
> 			opt_fork = true;
> 			break;
> 		}
> 	}
> 
> 	if (argc <= optind) {
> 		fprintf(stderr, "%s: [-f] address\n", argv[0]);
> 		fprintf(stderr, "\t-f specifices if we should fork with the mmap\n");
> 		exit(EXIT_FAILURE);
> 	}
> 	if (sscanf(argv[optind], "%lli", &offset) != 1) {
> 		fprintf(stderr, "Cannot determine mmap address from %s\n", argv[optind]);
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	if ((fd = open("/dev/mem", O_RDONLY)) < 0) {
> 		fprintf(stderr, "Cannot open /dev/mem\n");
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095);
> 
> 	if ((data = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, (off_t)offset)) == MAP_FAILED) {
> 		fprintf(stderr, "Cannot mmap 0x%llx\n", offset);
> 		exit(EXIT_FAILURE);
> 	}
> 
> 	close(fd);
> 
> 	if (opt_fork) {
> 		pid = fork();
> 		if (pid == 0) {
> 			/* child */
> 			_exit(0);
> 		} else {
> 			/* parent */
> 			waitpid(pid, &status, 0);
> 		}
> 	}
> 
> 	if (munmap(data, 4096) < 0) {
> 		fprintf(stderr, "Cannot munmap %p\n", data);
> 		exit(EXIT_FAILURE);
> 	}
> 	exit(EXIT_SUCCESS);
> }
> 




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 22 15:29:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15: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 1U8uYG-00065Z-RI; Fri, 22 Feb 2013 15:28: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 1U8uYF-00065S-8A
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 15:28:43 +0000
Received: from [85.158.139.211:33483] by server-16.bemta-5.messagelabs.com id
	AD/35-14948-9AE87215; Fri, 22 Feb 2013 15:28:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361546896!18791152!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12635 invoked from network); 22 Feb 2013 15:28:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 15:28:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1790649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 15:27: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.297.1; Fri, 22 Feb 2013 15:27:17 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U8uWr-0001th-8Q;
	Fri, 22 Feb 2013 15:27:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U8uWq-0004xn-TK;
	Fri, 22 Feb 2013 15:27:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16224-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 15:27:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16224: 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 16224 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16224/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 15:29:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15: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 1U8uYG-00065Z-RI; Fri, 22 Feb 2013 15:28: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 1U8uYF-00065S-8A
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 15:28:43 +0000
Received: from [85.158.139.211:33483] by server-16.bemta-5.messagelabs.com id
	AD/35-14948-9AE87215; Fri, 22 Feb 2013 15:28:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361546896!18791152!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12635 invoked from network); 22 Feb 2013 15:28:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 15:28:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1790649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 15:27: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.297.1; Fri, 22 Feb 2013 15:27:17 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U8uWr-0001th-8Q;
	Fri, 22 Feb 2013 15:27:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U8uWq-0004xn-TK;
	Fri, 22 Feb 2013 15:27:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16224-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 15:27:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16224: 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 16224 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16224/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 15:38:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15: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 1U8uhG-0006WF-6N; Fri, 22 Feb 2013 15:38:02 +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 1U8uhD-0006W9-Jz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 15:38:00 +0000
Received: from [85.158.137.99:50269] by server-4.bemta-3.messagelabs.com id
	42/EE-17521-6D097215; Fri, 22 Feb 2013 15:37:58 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361547477!17637221!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxOTE4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12071 invoked from network); 22 Feb 2013 15:37:58 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-217.messagelabs.com with SMTP;
	22 Feb 2013 15:37:58 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 22 Feb 2013 07:37:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,717,1355126400"; d="scan'208";a="294676731"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 22 Feb 2013 07:37:55 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Feb 2013 07:37:55 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.51]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.236]) with mapi id
	14.01.0355.002; Fri, 22 Feb 2013 23:37:53 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] qemu: define a TOM register to report the
	base of PCI
Thread-Index: AQHOEKroXKAcVJ2MUUi0HHAo5Gs24piFD6QAgACairA=
Date: Fri, 22 Feb 2013 15:37:52 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
In-Reply-To: <5127428C02000078000C040A@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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
 base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Friday, February 22, 2013 5:04 PM
> To: Hao, Xudong
> Cc: stefano.stabellini@eu.citrix.com; Zhang, Xiantao; xen-devel@lists.xen.org;
> qemu-devel@nongnu.org; mst@redhat.com; aliguori@us.ibm.com
> Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
> base of PCI
> 
> >>> On 22.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
> > @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
> >
> >      d->dev.config[I440FX_SMRAM] = 0x02;
> >
> > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > +    if (xen_enabled()) {
> > +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> > +    } else {
> > +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> > +    }
> > +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> > +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> > +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> > +
> >      cpu_smm_register(&i440fx_set_smm, d);
> >      return 0;
> >  }
> 
> Isn't this the wrong way round (big endian, when it needs to be
> little)?
> 
Jan, 

Here it should be little endian since the following config reading is little endian, I'll correct it. Thanks your comments.

> Or else, this read and calculation
> 
> >+    pci_hole_start = pci_default_read_config(&f->dev,
> I440FX_PCI_HOLE_BASE, 4);
> >+    pci_hole_size = 0x100000000ULL - pci_hole_start;
> 
> would seem wrong (e.g. if the granularity is meant to be 16M).
> 
> And then again, wasting 4 bytes of config space on something that
> one ought to be allowed to expect to be at least 64k-aligned seems
> questionable too. hvmloader surely could align the value up to the
> next 64k boundary before writing the - then only word size - field.
Hvmloader did 64k-aligned, I'm not quite understand, could you help to point out?

If considering wasting of config space, actually hvmloader only write 4 values in this register: 3.75G(0xf0000000), 3.5G(0xe0000000), 3G(0xc0000000), 2G(0x80000000), then 1 byte is enough for xen. 

> That would come closer to how real chipsets normally implement
> things like this.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 15:38:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15: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 1U8uhG-0006WF-6N; Fri, 22 Feb 2013 15:38:02 +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 1U8uhD-0006W9-Jz
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 15:38:00 +0000
Received: from [85.158.137.99:50269] by server-4.bemta-3.messagelabs.com id
	42/EE-17521-6D097215; Fri, 22 Feb 2013 15:37:58 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361547477!17637221!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxOTE4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12071 invoked from network); 22 Feb 2013 15:37:58 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-217.messagelabs.com with SMTP;
	22 Feb 2013 15:37:58 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 22 Feb 2013 07:37:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,717,1355126400"; d="scan'208";a="294676731"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 22 Feb 2013 07:37:55 -0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Feb 2013 07:37:55 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.51]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.236]) with mapi id
	14.01.0355.002; Fri, 22 Feb 2013 23:37:53 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH] qemu: define a TOM register to report the
	base of PCI
Thread-Index: AQHOEKroXKAcVJ2MUUi0HHAo5Gs24piFD6QAgACairA=
Date: Fri, 22 Feb 2013 15:37:52 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
In-Reply-To: <5127428C02000078000C040A@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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
 base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Friday, February 22, 2013 5:04 PM
> To: Hao, Xudong
> Cc: stefano.stabellini@eu.citrix.com; Zhang, Xiantao; xen-devel@lists.xen.org;
> qemu-devel@nongnu.org; mst@redhat.com; aliguori@us.ibm.com
> Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
> base of PCI
> 
> >>> On 22.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
> > @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
> >
> >      d->dev.config[I440FX_SMRAM] = 0x02;
> >
> > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > +    if (xen_enabled()) {
> > +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> > +    } else {
> > +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> > +    }
> > +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> > +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> > +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> > +
> >      cpu_smm_register(&i440fx_set_smm, d);
> >      return 0;
> >  }
> 
> Isn't this the wrong way round (big endian, when it needs to be
> little)?
> 
Jan, 

Here it should be little endian since the following config reading is little endian, I'll correct it. Thanks your comments.

> Or else, this read and calculation
> 
> >+    pci_hole_start = pci_default_read_config(&f->dev,
> I440FX_PCI_HOLE_BASE, 4);
> >+    pci_hole_size = 0x100000000ULL - pci_hole_start;
> 
> would seem wrong (e.g. if the granularity is meant to be 16M).
> 
> And then again, wasting 4 bytes of config space on something that
> one ought to be allowed to expect to be at least 64k-aligned seems
> questionable too. hvmloader surely could align the value up to the
> next 64k boundary before writing the - then only word size - field.
Hvmloader did 64k-aligned, I'm not quite understand, could you help to point out?

If considering wasting of config space, actually hvmloader only write 4 values in this register: 3.75G(0xf0000000), 3.5G(0xe0000000), 3G(0xc0000000), 2G(0x80000000), then 1 byte is enough for xen. 

> That would come closer to how real chipsets normally implement
> things like this.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 15:43:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15:43: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 1U8um3-0006tS-UL; Fri, 22 Feb 2013 15:42:59 +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 1U8um2-0006tJ-7s
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 15:42:58 +0000
Received: from [85.158.137.99:24491] by server-11.bemta-3.messagelabs.com id
	44/46-10249-10297215; Fri, 22 Feb 2013 15:42:57 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361547775!17596413!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg4MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24709 invoked from network); 22 Feb 2013 15:42:56 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-217.messagelabs.com with SMTP;
	22 Feb 2013 15:42:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Feb 2013 07:41:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,717,1355126400"; d="scan'208";a="266264996"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 22 Feb 2013 07:42:50 -0800
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Feb 2013 07:42:50 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Feb 2013 07:42:49 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.51]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Fri, 22 Feb 2013 23:42:48 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH] qemu: define a TOM register to report the base of PCI
Thread-Index: AQHOEKroXKAcVJ2MUUi0HHAo5Gs24piFSqyAgAC58dA=
Date: Fri, 22 Feb 2013 15:42:47 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FF79C47@SHSMSX102.ccr.corp.intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302221233080.22997@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302221233080.22997@kaball.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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, "mst@redhat.com" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
	base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Friday, February 22, 2013 8:35 PM
> To: Hao, Xudong
> Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org;
> Stefano Stabellini; xen-devel@lists.xen.org; Zhang, Xiantao
> Subject: Re: [PATCH] qemu: define a TOM register to report the base of PCI
> 
> On Fri, 22 Feb 2013, Xudong Hao wrote:
> > Define a TOM(top of memory) register to report the base of PCI memory,
> update
> > memory region dynamically.
> >
> > The use case of this register defination is for Xen till now.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> 
> Thanks for the patch!
> 
> Aside from Jan's comment on the pci config endianness, I would also like
> to see an #define somewhere in QEMU to specific what's the default TOM.
> In particular I wouldn't want 0xe0000000 (and 0xf0000000) to be
> hardcoded in more than one place.
> 
> 
Good comments, I'll define the default TOM out and replace the hardcode.

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 Feb 22 15:43:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15:43: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 1U8um3-0006tS-UL; Fri, 22 Feb 2013 15:42:59 +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 1U8um2-0006tJ-7s
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 15:42:58 +0000
Received: from [85.158.137.99:24491] by server-11.bemta-3.messagelabs.com id
	44/46-10249-10297215; Fri, 22 Feb 2013 15:42:57 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361547775!17596413!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg4MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24709 invoked from network); 22 Feb 2013 15:42:56 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-14.tower-217.messagelabs.com with SMTP;
	22 Feb 2013 15:42:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 22 Feb 2013 07:41:32 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,717,1355126400"; d="scan'208";a="266264996"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 22 Feb 2013 07:42:50 -0800
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Feb 2013 07:42:50 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 22 Feb 2013 07:42:49 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.51]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Fri, 22 Feb 2013 23:42:48 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH] qemu: define a TOM register to report the base of PCI
Thread-Index: AQHOEKroXKAcVJ2MUUi0HHAo5Gs24piFSqyAgAC58dA=
Date: Fri, 22 Feb 2013 15:42:47 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FF79C47@SHSMSX102.ccr.corp.intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302221233080.22997@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302221233080.22997@kaball.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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>, "mst@redhat.com" <mst@redhat.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
	base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Friday, February 22, 2013 8:35 PM
> To: Hao, Xudong
> Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org;
> Stefano Stabellini; xen-devel@lists.xen.org; Zhang, Xiantao
> Subject: Re: [PATCH] qemu: define a TOM register to report the base of PCI
> 
> On Fri, 22 Feb 2013, Xudong Hao wrote:
> > Define a TOM(top of memory) register to report the base of PCI memory,
> update
> > memory region dynamically.
> >
> > The use case of this register defination is for Xen till now.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> 
> Thanks for the patch!
> 
> Aside from Jan's comment on the pci config endianness, I would also like
> to see an #define somewhere in QEMU to specific what's the default TOM.
> In particular I wouldn't want 0xe0000000 (and 0xf0000000) to be
> hardcoded in more than one place.
> 
> 
Good comments, I'll define the default TOM out and replace the hardcode.

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 Feb 22 15:45:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15:45: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 1U8unf-0006yi-Hg; Fri, 22 Feb 2013 15:44:39 +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 1U8und-0006yY-O5
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 15:44:37 +0000
Received: from [85.158.137.99:11959] by server-10.bemta-3.messagelabs.com id
	59/91-10609-06297215; Fri, 22 Feb 2013 15:44:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361547870!17596703!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5973 invoked from network); 22 Feb 2013 15:44:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 15:44:31 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MFiQr3032630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 15:44: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
	r1MFiPkv002278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 15:44:25 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
	r1MFiPvN006174; Fri, 22 Feb 2013 09:44:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 07:44:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 700B41C3935; Fri, 22 Feb 2013 10:44:24 -0500 (EST)
Date: Fri, 22 Feb 2013 10:44:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222154424.GA8809@phenom.dumpdata.com>
References: <E1U2iMn-0008As-4b@xenbits.xen.org>
	<51278C1D02000078000C06A8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51278C1D02000078000C06A8@nat28.tlf.novell.com>
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
Subject: Re: [Xen-devel] Xen Security Advisory 43 (CVE-2013-0231) - Linux
 pciback DoS via not rate limited log 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 Fri, Feb 22, 2013 at 02:17:49PM +0000, Jan Beulich wrote:
> >>> On 05.02.13 at 14:15, Xen.org security team <security@xen.org> wrote:
> > RESOLUTION
> > ==========
> > 
> > Applying the appropriate attached patch resolves this issue.
> > 
> > xsa43-pvops.patch            Apply to mainline Linux 3.8-rc5.
> 
> I realized the other day that stable@ wasn't Cc-ed on this one
> either, and I think it would be more authoritative if you as the
> maintainer of the patched code asked for this being added there.

Yikes. Let me do that.
> 
> Thanks, Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 15:45:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 15:45: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 1U8unf-0006yi-Hg; Fri, 22 Feb 2013 15:44:39 +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 1U8und-0006yY-O5
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 15:44:37 +0000
Received: from [85.158.137.99:11959] by server-10.bemta-3.messagelabs.com id
	59/91-10609-06297215; Fri, 22 Feb 2013 15:44:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361547870!17596703!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5973 invoked from network); 22 Feb 2013 15:44:31 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 15:44:31 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MFiQr3032630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 15:44: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
	r1MFiPkv002278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 15:44:25 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
	r1MFiPvN006174; Fri, 22 Feb 2013 09:44:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 07:44:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 700B41C3935; Fri, 22 Feb 2013 10:44:24 -0500 (EST)
Date: Fri, 22 Feb 2013 10:44:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222154424.GA8809@phenom.dumpdata.com>
References: <E1U2iMn-0008As-4b@xenbits.xen.org>
	<51278C1D02000078000C06A8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51278C1D02000078000C06A8@nat28.tlf.novell.com>
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
Subject: Re: [Xen-devel] Xen Security Advisory 43 (CVE-2013-0231) - Linux
 pciback DoS via not rate limited log 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 Fri, Feb 22, 2013 at 02:17:49PM +0000, Jan Beulich wrote:
> >>> On 05.02.13 at 14:15, Xen.org security team <security@xen.org> wrote:
> > RESOLUTION
> > ==========
> > 
> > Applying the appropriate attached patch resolves this issue.
> > 
> > xsa43-pvops.patch            Apply to mainline Linux 3.8-rc5.
> 
> I realized the other day that stable@ wasn't Cc-ed on this one
> either, and I think it would be more authoritative if you as the
> maintainer of the patched code asked for this being added there.

Yikes. Let me do that.
> 
> Thanks, Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:34:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8vZm-0000kH-BC; Fri, 22 Feb 2013 16:34: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 1U8vZk-0000k7-TV
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:34:21 +0000
Received: from [85.158.139.211:8670] by server-2.bemta-5.messagelabs.com id
	D1/D6-16911-B0E97215; Fri, 22 Feb 2013 16:34:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361550858!14829933!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1109 invoked from network); 22 Feb 2013 16:34:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16:34: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.297.1; Fri, 22 Feb 2013 16:34:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vZh-0002FT-O9; Fri, 22 Feb 2013 16:34:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vZh-0003Ao-JX;
	Fri, 22 Feb 2013 16:34:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.40457.508414.413369@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:34:17 +0000
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458384@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458384@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] doc: Improve xc_domain_restore
	inline	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

Frediano Ziglio writes ("[Xen-devel] [PATCH] doc: Improve xc_domain_restore inline documentation"):
> Was not clear that xc_domain_restore did not resume the machine.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Applied, 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 Feb 22 16:34:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8vZm-0000kH-BC; Fri, 22 Feb 2013 16:34: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 1U8vZk-0000k7-TV
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:34:21 +0000
Received: from [85.158.139.211:8670] by server-2.bemta-5.messagelabs.com id
	D1/D6-16911-B0E97215; Fri, 22 Feb 2013 16:34:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361550858!14829933!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1109 invoked from network); 22 Feb 2013 16:34:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16:34: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.297.1; Fri, 22 Feb 2013 16:34:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vZh-0002FT-O9; Fri, 22 Feb 2013 16:34:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vZh-0003Ao-JX;
	Fri, 22 Feb 2013 16:34:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.40457.508414.413369@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:34:17 +0000
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458384@LONPMAILBOX01.citrite.net>
References: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458384@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] doc: Improve xc_domain_restore
	inline	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

Frediano Ziglio writes ("[Xen-devel] [PATCH] doc: Improve xc_domain_restore inline documentation"):
> Was not clear that xc_domain_restore did not resume the machine.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Applied, 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 Feb 22 16:36:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:36: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 1U8vbh-0000qS-Rv; Fri, 22 Feb 2013 16:36:21 +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 1U8vbg-0000qJ-Ha
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 16:36:20 +0000
Received: from [85.158.143.99:64189] by server-1.bemta-4.messagelabs.com id
	D1/85-06203-38E97215; Fri, 22 Feb 2013 16:36:19 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361550976!21315231!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23908 invoked from network); 22 Feb 2013 16:36:16 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 16:36:16 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 1B6844008F2;
	Fri, 22 Feb 2013 17:36:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Jv+MSBykk86B; Fri, 22 Feb 2013 17:36:15 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 9BF3F40086D;
	Fri, 22 Feb 2013 17:36:12 +0100 (CET)
Message-ID: <51279E76.8050703@tiscali.it>
Date: Fri, 22 Feb 2013 17:36:06 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, xudong.hao@intel.com, 
	frediano.ziglio@citrix.com
Subject: [Xen-devel] Emulated vgas problems with qemu upstream on Xen
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="===============2894083883518449947=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2894083883518449947==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060707020309070002050901"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060707020309070002050901
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Some times ago I have reported several times the problem with emulated=20
vgas with qemu upstream on xen.
For example this was my last report about:
> WIth both cirrus and stdvga under qemu upstream with xen the=20
> performance are poor even if I increase video memory, respect to=20
> qemu-only and qemu-kvm (without xen).
> Qxl is definitely not working under xen and conversely is ok on=20
> qemu-kvm and qemu-only.
>
> It seem that xen need change and/or fix to have full working emulated=20
> vga on qemu upstream.
> At the moment all emulated vgas have problems with xen that aren't=20
> present without xen.
>
> The performance differences are noticeable (in some case very big)=20
> with xen and without xen using resolution > 1024x768.
>
> Probably the first link explain the change/fix necessary in xen about=20
> vga (probably in hvmloader).
> I tried to do that more times failing but unfortunately I do not have=20
> sufficient knowledge about this.
> Can someone help me please?
>
> I think this is important, years ago the minimal resolution used on=20
> desktop was 1024x768, and no problem with actual vga setting but now=20
> minimal resolution seems increased to up 1366x768 and many people are=20
> using even higher resolutions.
> http://www.screenresolution.org/year-2013/

When I started testing qemu upstream at the end of 2011 there were=20
critical bugs on videoram setting resolved with patches on qemu and xen.
I did recently libxl patch that correctly set videoram and add qxl=20
support but it seems that on xen with qemu upstream all the emulated vga =

working only as standard vga.
What I mean is: even if I see the total amout of ram (i.e. 64 mb) on=20
guest, the performances are poor in special mode when I increase the=20
resolution even in real simple operations like screen updates.

I spent some days to find a solution, after comparative tests with=20
qemu-kvm and qemu-only when using same build of qemu and seabios on both =

linux/windows domU/vm the problem seem of hvmloader.
I have tried to find what is exactly the culprit to no avail.
I don't have knownladge about bios parts.
I also tried to see the differences of seabios tables between xen and=20
kvm or qemu-only with:

-chardev stdio,id=3Dseabios -device isa-debugcon,iobase=3D0x402,chardev=3D=
seabios

but Xen domU doesn't show the details (probably because seabios with xen =

uses the tables passed by hvmloader)

Today I also tested this patches probably related to solution:

[PATCH]xen/hvmloader: define a TOM register
[PATCH] qemu: define a TOM register to report the base of PCI

The problem persists, probably this is only partial solution about=20
hvmloader changes needed for full support upstream qemu vgas.

This is an important problem to solve, not only for support bigger=20
resolutions and good support of a opensource vdi solution but also=20
because with stdvga is impossible to use some resolutions, for example=20
the actually most used 1366x768.
(screenshots of examples with windows 7 on attachment)
Screenshots show list of resolutions supported by standard vga and qxl=20
full working.

There is also a strange difference on bios info line of qxl between xen=20
and kvm.
Someone tells that hvmloader do not cause problem with upstream qemu=20
vgabioses, the difference is only caused by hvmloader generated tables=20
or probably or is there another problem to found?

I also did some tests with ovmf after applied this patch:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg01363.html
and using updated tianocore git, but it seems there are more work to do=20
on hvmloader for complete integration.
I think like others that a hvmloader rewrite more minimal without=20
including firmwares in hvmloader but linking them instead and using ovmf =

with seabios included (for support both eufi and bios) will be the best=20
definitive solution for future of hvm domU.
Probably now the more important thing is fixes to hvmloader with seabios =

to have a full feature and stable qemu upstream on xen 4.3.

Is there someone that can help me to solve emulated vgas problem with=20
upstream qemu?

Thanks for any reply and sorry for my bad english.


--------------ms060707020309070002050901
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMjE2MzYwNlowIwYJKoZIhvcNAQkEMRYEFCVV2K/X8sqQ21mLIa2AgVqJ
ttUsMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEABpH54UqPKBPGHLZuRr2PP5pk
PfNwh4jbSRLE41F9bGuI92HlkYyV+js7n6ZePcPjV0zYGNyUDB/ZTLK7C6c54RN9Xl6Bs6vT
5J7WfRF6VLVbr6uMJSfNvCwLl7AjMPX2PLwPlXutTXuT8miCxALb6rSTKqLM8aEJeWpoBk30
Mj/ZTWDE0eLNAScwv45TRCQRsFqT3Wy/dBXm8dnwM3TuQ5cfVUzu+AQfi8LP6Tt3qFwL4cab
ed/94zRUYcruaTm0bdT8fOnvR83ZzIgW+itMl0z6pFztV6x4hE0Oj6yckUpxOWUVKSHPCOqF
e4WMmzYxfIOo3UYVhWPLnaXZiu8AigAAAAAAAA==
--------------ms060707020309070002050901--


--===============2894083883518449947==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2894083883518449947==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 16:36:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:36: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 1U8vbh-0000qS-Rv; Fri, 22 Feb 2013 16:36:21 +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 1U8vbg-0000qJ-Ha
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 16:36:20 +0000
Received: from [85.158.143.99:64189] by server-1.bemta-4.messagelabs.com id
	D1/85-06203-38E97215; Fri, 22 Feb 2013 16:36:19 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361550976!21315231!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23908 invoked from network); 22 Feb 2013 16:36:16 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 16:36:16 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 1B6844008F2;
	Fri, 22 Feb 2013 17:36:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Jv+MSBykk86B; Fri, 22 Feb 2013 17:36:15 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 9BF3F40086D;
	Fri, 22 Feb 2013 17:36:12 +0100 (CET)
Message-ID: <51279E76.8050703@tiscali.it>
Date: Fri, 22 Feb 2013 17:36:06 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, xudong.hao@intel.com, 
	frediano.ziglio@citrix.com
Subject: [Xen-devel] Emulated vgas problems with qemu upstream on Xen
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="===============2894083883518449947=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2894083883518449947==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060707020309070002050901"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060707020309070002050901
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Some times ago I have reported several times the problem with emulated=20
vgas with qemu upstream on xen.
For example this was my last report about:
> WIth both cirrus and stdvga under qemu upstream with xen the=20
> performance are poor even if I increase video memory, respect to=20
> qemu-only and qemu-kvm (without xen).
> Qxl is definitely not working under xen and conversely is ok on=20
> qemu-kvm and qemu-only.
>
> It seem that xen need change and/or fix to have full working emulated=20
> vga on qemu upstream.
> At the moment all emulated vgas have problems with xen that aren't=20
> present without xen.
>
> The performance differences are noticeable (in some case very big)=20
> with xen and without xen using resolution > 1024x768.
>
> Probably the first link explain the change/fix necessary in xen about=20
> vga (probably in hvmloader).
> I tried to do that more times failing but unfortunately I do not have=20
> sufficient knowledge about this.
> Can someone help me please?
>
> I think this is important, years ago the minimal resolution used on=20
> desktop was 1024x768, and no problem with actual vga setting but now=20
> minimal resolution seems increased to up 1366x768 and many people are=20
> using even higher resolutions.
> http://www.screenresolution.org/year-2013/

When I started testing qemu upstream at the end of 2011 there were=20
critical bugs on videoram setting resolved with patches on qemu and xen.
I did recently libxl patch that correctly set videoram and add qxl=20
support but it seems that on xen with qemu upstream all the emulated vga =

working only as standard vga.
What I mean is: even if I see the total amout of ram (i.e. 64 mb) on=20
guest, the performances are poor in special mode when I increase the=20
resolution even in real simple operations like screen updates.

I spent some days to find a solution, after comparative tests with=20
qemu-kvm and qemu-only when using same build of qemu and seabios on both =

linux/windows domU/vm the problem seem of hvmloader.
I have tried to find what is exactly the culprit to no avail.
I don't have knownladge about bios parts.
I also tried to see the differences of seabios tables between xen and=20
kvm or qemu-only with:

-chardev stdio,id=3Dseabios -device isa-debugcon,iobase=3D0x402,chardev=3D=
seabios

but Xen domU doesn't show the details (probably because seabios with xen =

uses the tables passed by hvmloader)

Today I also tested this patches probably related to solution:

[PATCH]xen/hvmloader: define a TOM register
[PATCH] qemu: define a TOM register to report the base of PCI

The problem persists, probably this is only partial solution about=20
hvmloader changes needed for full support upstream qemu vgas.

This is an important problem to solve, not only for support bigger=20
resolutions and good support of a opensource vdi solution but also=20
because with stdvga is impossible to use some resolutions, for example=20
the actually most used 1366x768.
(screenshots of examples with windows 7 on attachment)
Screenshots show list of resolutions supported by standard vga and qxl=20
full working.

There is also a strange difference on bios info line of qxl between xen=20
and kvm.
Someone tells that hvmloader do not cause problem with upstream qemu=20
vgabioses, the difference is only caused by hvmloader generated tables=20
or probably or is there another problem to found?

I also did some tests with ovmf after applied this patch:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg01363.html
and using updated tianocore git, but it seems there are more work to do=20
on hvmloader for complete integration.
I think like others that a hvmloader rewrite more minimal without=20
including firmwares in hvmloader but linking them instead and using ovmf =

with seabios included (for support both eufi and bios) will be the best=20
definitive solution for future of hvm domU.
Probably now the more important thing is fixes to hvmloader with seabios =

to have a full feature and stable qemu upstream on xen 4.3.

Is there someone that can help me to solve emulated vgas problem with=20
upstream qemu?

Thanks for any reply and sorry for my bad english.


--------------ms060707020309070002050901
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyMjE2MzYwNlowIwYJKoZIhvcNAQkEMRYEFCVV2K/X8sqQ21mLIa2AgVqJ
ttUsMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEABpH54UqPKBPGHLZuRr2PP5pk
PfNwh4jbSRLE41F9bGuI92HlkYyV+js7n6ZePcPjV0zYGNyUDB/ZTLK7C6c54RN9Xl6Bs6vT
5J7WfRF6VLVbr6uMJSfNvCwLl7AjMPX2PLwPlXutTXuT8miCxALb6rSTKqLM8aEJeWpoBk30
Mj/ZTWDE0eLNAScwv45TRCQRsFqT3Wy/dBXm8dnwM3TuQ5cfVUzu+AQfi8LP6Tt3qFwL4cab
ed/94zRUYcruaTm0bdT8fOnvR83ZzIgW+itMl0z6pFztV6x4hE0Oj6yckUpxOWUVKSHPCOqF
e4WMmzYxfIOo3UYVhWPLnaXZiu8AigAAAAAAAA==
--------------ms060707020309070002050901--


--===============2894083883518449947==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2894083883518449947==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 16:37:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:37: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 1U8vcI-0000tl-In; Fri, 22 Feb 2013 16:36: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 1U8vcH-0000ta-UN
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:36:58 +0000
Received: from [85.158.137.99:32647] by server-9.bemta-3.messagelabs.com id
	68/94-09484-8AE97215; Fri, 22 Feb 2013 16:36:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361550981!12904216!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25494 invoked from network); 22 Feb 2013 16:36:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16:36: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.297.1; Fri, 22 Feb 2013 16:36:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vbh-0002GF-8B; Fri, 22 Feb 2013 16:36:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vbh-0003CN-1j;
	Fri, 22 Feb 2013 16:36:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.40580.954215.94206@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:36:20 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20130219184712.GB21783@aepfle.de>
References: <0f9c7503650fa1b1103b.1360862057@probook.site>
	<20771.49862.534182.856929@mariner.uk.xensource.com>
	<20130219184712.GB21783@aepfle.de>
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] tools/xend: Only add cpuid and cpuid_check
 to sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xend: Only add cpuid and cpuid_check to sexpr once"):
> The result of having cpuid= in the domU.cfg and doing a rcxend restart is
> that the sxp string is not properly converted into a list and dict(?),
> instead the string is partly passed as is. xend will reject the sxp and
> the domU disappears until its readded with xm new.
> 
> This change has been used almost a year now in production, no errors
> were reported.

Thanks for the reassurance, I have applied 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 Fri Feb 22 16:37:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:37: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 1U8vcI-0000tl-In; Fri, 22 Feb 2013 16:36: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 1U8vcH-0000ta-UN
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:36:58 +0000
Received: from [85.158.137.99:32647] by server-9.bemta-3.messagelabs.com id
	68/94-09484-8AE97215; Fri, 22 Feb 2013 16:36:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361550981!12904216!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25494 invoked from network); 22 Feb 2013 16:36:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:36:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16:36: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.297.1; Fri, 22 Feb 2013 16:36:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vbh-0002GF-8B; Fri, 22 Feb 2013 16:36:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vbh-0003CN-1j;
	Fri, 22 Feb 2013 16:36:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.40580.954215.94206@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:36:20 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20130219184712.GB21783@aepfle.de>
References: <0f9c7503650fa1b1103b.1360862057@probook.site>
	<20771.49862.534182.856929@mariner.uk.xensource.com>
	<20130219184712.GB21783@aepfle.de>
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] tools/xend: Only add cpuid and cpuid_check
 to sexpr once
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xend: Only add cpuid and cpuid_check to sexpr once"):
> The result of having cpuid= in the domU.cfg and doing a rcxend restart is
> that the sxp string is not properly converted into a list and dict(?),
> instead the string is partly passed as is. xend will reject the sxp and
> the domU disappears until its readded with xm new.
> 
> This change has been used almost a year now in production, no errors
> were reported.

Thanks for the reassurance, I have applied 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 Fri Feb 22 16:41:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:41: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 1U8vgb-0001Wa-5B; Fri, 22 Feb 2013 16:41: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 1U8vga-0001WQ-7X
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:41:24 +0000
Received: from [193.109.254.147:60272] by server-15.bemta-14.messagelabs.com
	id 54/FC-24599-3BF97215; Fri, 22 Feb 2013 16:41:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361551282!6280990!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15441 invoked from network); 22 Feb 2013 16:41:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16:41: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.297.1; Fri, 22 Feb 2013 16:41:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vgX-0002I2-OZ; Fri, 22 Feb 2013 16:41:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vgX-0003EX-KQ;
	Fri, 22 Feb 2013 16:41:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.40881.538940.898878@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:41:21 +0000
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CA+YWh9bx3w6OKDSug+yiHvZ1+JWRco5wpo4UM_T16LXC-8aeZg@mail.gmail.com>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
	<1361379682.26546.18.camel@zakaz.uk.xensource.com>
	<CA+YWh9bx3w6OKDSug+yiHvZ1+JWRco5wpo4UM_T16LXC-8aeZg@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] build: Fix distclean when repo
	location	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Andrei Lifchits writes ("Re: [Xen-devel] [PATCH] build: Fix distclean when repo location changes"):
> On Wed, Feb 20, 2013 at 5:01 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2013-02-20 at 16:47 +0000, Andrei Lifchits wrote:
> >> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
> >> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
> >> breaks distclean because make attempts to clean inside those first and fails to
> >> find Makefile (which is also a symlink).
> 
> Signed-off-by: Andrei Lifchits <andrei.lifchits@citrix.com>

Thanks, I've applied the patch.

> > Would it be possible to arrange for the symlinks to be relative in the
> > first place?
> 
> Good idea, I'll look into it when I have time (there are a lot of
> those symlinks in various places).

Right.  As I say I don't think this is a thing that should be expected
to be work but I won't block you from working on it :-).

Making "distclean" work after the tree is moved might be easier than
making just "make" still work; the latter would involve making sure
that all the -Is etc. were relative, as those paths end up in .d
files.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:41:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:41: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 1U8vgb-0001Wa-5B; Fri, 22 Feb 2013 16:41: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 1U8vga-0001WQ-7X
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:41:24 +0000
Received: from [193.109.254.147:60272] by server-15.bemta-14.messagelabs.com
	id 54/FC-24599-3BF97215; Fri, 22 Feb 2013 16:41:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361551282!6280990!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15441 invoked from network); 22 Feb 2013 16:41:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16:41: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.297.1; Fri, 22 Feb 2013 16:41:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vgX-0002I2-OZ; Fri, 22 Feb 2013 16:41:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vgX-0003EX-KQ;
	Fri, 22 Feb 2013 16:41:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.40881.538940.898878@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:41:21 +0000
To: Andrei Lifchits <andrei.lifchits@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CA+YWh9bx3w6OKDSug+yiHvZ1+JWRco5wpo4UM_T16LXC-8aeZg@mail.gmail.com>
References: <8f69a0bcab522d7dae5a.1361378871@st28.blah>
	<1361379682.26546.18.camel@zakaz.uk.xensource.com>
	<CA+YWh9bx3w6OKDSug+yiHvZ1+JWRco5wpo4UM_T16LXC-8aeZg@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] build: Fix distclean when repo
	location	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Andrei Lifchits writes ("Re: [Xen-devel] [PATCH] build: Fix distclean when repo location changes"):
> On Wed, Feb 20, 2013 at 5:01 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2013-02-20 at 16:47 +0000, Andrei Lifchits wrote:
> >> If the path to xen-unstable.hg changes (i.e. you move the repo), the symlinks
> >> inside xen-unstable.hg/stubdom/libxc-x86_[32|64]/ all become broken, which
> >> breaks distclean because make attempts to clean inside those first and fails to
> >> find Makefile (which is also a symlink).
> 
> Signed-off-by: Andrei Lifchits <andrei.lifchits@citrix.com>

Thanks, I've applied the patch.

> > Would it be possible to arrange for the symlinks to be relative in the
> > first place?
> 
> Good idea, I'll look into it when I have time (there are a lot of
> those symlinks in various places).

Right.  As I say I don't think this is a thing that should be expected
to be work but I won't block you from working on it :-).

Making "distclean" work after the tree is moved might be easier than
making just "make" still work; the latter would involve making sure
that all the -Is etc. were relative, as those paths end up in .d
files.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:43:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:43: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 1U8viT-0001jT-MP; Fri, 22 Feb 2013 16:43: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 1U8viS-0001jG-9y
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:43:20 +0000
Received: from [85.158.143.99:40064] by server-2.bemta-4.messagelabs.com id
	D6/2A-12656-720A7215; Fri, 22 Feb 2013 16:43:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361551399!21226380!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26696 invoked from network); 22 Feb 2013 16:43:19 -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; 22 Feb 2013 16:43:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 16:43:18 +0000
Message-Id: <5127AE7102000078000C075D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 16:44:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
 base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:37, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> And then again, wasting 4 bytes of config space on something that
>> one ought to be allowed to expect to be at least 64k-aligned seems
>> questionable too. hvmloader surely could align the value up to the
>> next 64k boundary before writing the - then only word size - field.
> Hvmloader did 64k-aligned, I'm not quite understand, could you help to point 
> out?
> 
> If considering wasting of config space, actually hvmloader only write 4 
> values in this register: 3.75G(0xf0000000), 3.5G(0xe0000000), 3G(0xc0000000), 
> 2G(0x80000000), then 1 byte is enough for xen. 

I'd be fine with that too, but whether use 16M granularity here is
acceptable going forward I don't know.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:43:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:43: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 1U8viT-0001jT-MP; Fri, 22 Feb 2013 16:43: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 1U8viS-0001jG-9y
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:43:20 +0000
Received: from [85.158.143.99:40064] by server-2.bemta-4.messagelabs.com id
	D6/2A-12656-720A7215; Fri, 22 Feb 2013 16:43:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361551399!21226380!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ2NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26696 invoked from network); 22 Feb 2013 16:43:19 -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; 22 Feb 2013 16:43:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 22 Feb 2013 16:43:18 +0000
Message-Id: <5127AE7102000078000C075D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 22 Feb 2013 16:44:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xudong Hao" <xudong.hao@intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report the
 base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:37, "Hao, Xudong" <xudong.hao@intel.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> And then again, wasting 4 bytes of config space on something that
>> one ought to be allowed to expect to be at least 64k-aligned seems
>> questionable too. hvmloader surely could align the value up to the
>> next 64k boundary before writing the - then only word size - field.
> Hvmloader did 64k-aligned, I'm not quite understand, could you help to point 
> out?
> 
> If considering wasting of config space, actually hvmloader only write 4 
> values in this register: 3.75G(0xf0000000), 3.5G(0xe0000000), 3G(0xc0000000), 
> 2G(0x80000000), then 1 byte is enough for xen. 

I'd be fine with that too, but whether use 16M granularity here is
acceptable going forward I don't know.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:49:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16: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 1U8vo6-00023P-NI; Fri, 22 Feb 2013 16:49:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linus971@gmail.com>) id 1U8vOb-0000EP-UK
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 16:22:50 +0000
Received: from [193.109.254.147:48062] by server-10.bemta-14.messagelabs.com
	id 30/1D-12679-95B97215; Fri, 22 Feb 2013 16:22:49 +0000
X-Env-Sender: linus971@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361550155!2108582!1
X-Originating-IP: [209.85.220.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10179 invoked from network); 22 Feb 2013 16:22:37 -0000
Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com)
	(209.85.220.182)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:22:37 -0000
Received: by mail-vc0-f182.google.com with SMTP id fl17so514957vcb.27
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 08:22:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1/z2HptjR302a24hbbwFqasOppfSVXf9++eQRkTCQfg=;
	b=VbcTdscRO9XJN17mD+K8OqTtO2yVQqfFd5nOrFjVjk3nInRZmQyqmTCbIIXCN4Is0E
	IDz4nCF4IzcYIErIlNgIRLaqg0js/lw9L1ATQZm8g+jeLE5GH2x9QHrgxFTLWV8Qev6V
	Tx3vxudvwdz/ggsrqkGLvrknejVhIIR5RyhRWMdAAAiImEBspdDqko3EYLP/4SdmRBAr
	9ipR5Z03g62NMAubLBz0sQGfQlonZt6O6JOYYXRoqF4U8dBYHu7nVyrszNsv8WfzRD1+
	hesGos+W54+1//rJd2uS//6yNyndHplo/c3qNiDku8mDskOU43/nz1prNSEn/GVVgBRy
	3w1Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=google;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1/z2HptjR302a24hbbwFqasOppfSVXf9++eQRkTCQfg=;
	b=ZHHGAMIgdbc7cqAoTBRpCP0MBYTYP4K+2SiGCeMGuyz0aco812PBFwC71UMfU8V038
	u7m4sC9TR0D9ciBvfNnaaSn+XxVDQHF8HHCIvZlLIo0zry+YVEAQ6Q0n7aFGyTffYjSJ
	YsT9Z5IIaPSnTGKJDZTgDB0qacX/fqfieVP3g=
MIME-Version: 1.0
X-Received: by 10.52.179.3 with SMTP id dc3mr2901372vdc.74.1361550150480; Fri,
	22 Feb 2013 08:22:30 -0800 (PST)
Received: by 10.220.145.131 with HTTP; Fri, 22 Feb 2013 08:22:30 -0800 (PST)
In-Reply-To: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
Date: Fri, 22 Feb 2013 08:22:30 -0800
X-Google-Sender-Auth: nbH_-pnQ2K1dUI4spHtJjNaHXAE
Message-ID: <CA+55aFy=tW2X4O-qKLh_YQjSFX7aBaBme4uy8kxawn1koKdt-g@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "H. Peter Anvin" <hpa@linux.intel.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 16:49:08 +0000
Cc: linux-mips <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	Avi Kivity <avi@redhat.com>, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 4:34 PM, H. Peter Anvin <hpa@linux.intel.com> wrote:
>
> This is a huge set of several partly interrelated (and concurrently
> developed) changes, which is why the branch history is messier than
> one would like.
>
> The *really* big items are two humonguous patchsets mostly developed
> by Yinghai Lu at my request, which completely revamps the way we
> create initial page tables.

Ugh. So I've tried to walk through this, and it's painful. If this
results in problems, we're going to be *so* screwed. Is it bisectable?

I also don't understand how "early_idt_handler" could *possibly* work.
In particular, it seems to rely on the trap number being set up in the
stack frame:

        cmpl $14,72(%rsp)       # Page fault?

but that's not even *true*. Why? Because we export both the
early_idt_handlers[] array (that sets up the trap number and makes the
stack frame be reliable) and the single early_idt_handler function
(that relies on the trap number and the reliable stack frame), AND
AFAIK WE USE THE LATTER!

See x86_64_start_kernel():

        for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
#ifdef CONFIG_EARLY_PRINTK
                set_intr_gate(i, &early_idt_handlers[i]);
#else
                set_intr_gate(i, early_idt_handler);
#endif
        }

so unless you have CONFIG_EARLY_PRINTK, the interrupt gate will point
to that raw early_idt_handler function that doesn't *work* on its own,
afaik.

Btw, it's not just the page fault index testing that is wrong. The whole

        cmpl $__KERNEL_CS,96(%rsp)
        jne 11f

also relies on the stack frame being set up the same way for all
exceptions - which again is only true if we ran through the
early_idt_handlers[] prologue that added the extra stack entry.

How does this even work for me? I don't have EARLY_PRINTK enabled.

What am I missing?

                Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:49:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16: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 1U8vo6-00023P-NI; Fri, 22 Feb 2013 16:49:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linus971@gmail.com>) id 1U8vOb-0000EP-UK
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 16:22:50 +0000
Received: from [193.109.254.147:48062] by server-10.bemta-14.messagelabs.com
	id 30/1D-12679-95B97215; Fri, 22 Feb 2013 16:22:49 +0000
X-Env-Sender: linus971@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361550155!2108582!1
X-Originating-IP: [209.85.220.182]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10179 invoked from network); 22 Feb 2013 16:22:37 -0000
Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com)
	(209.85.220.182)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:22:37 -0000
Received: by mail-vc0-f182.google.com with SMTP id fl17so514957vcb.27
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 08:22:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1/z2HptjR302a24hbbwFqasOppfSVXf9++eQRkTCQfg=;
	b=VbcTdscRO9XJN17mD+K8OqTtO2yVQqfFd5nOrFjVjk3nInRZmQyqmTCbIIXCN4Is0E
	IDz4nCF4IzcYIErIlNgIRLaqg0js/lw9L1ATQZm8g+jeLE5GH2x9QHrgxFTLWV8Qev6V
	Tx3vxudvwdz/ggsrqkGLvrknejVhIIR5RyhRWMdAAAiImEBspdDqko3EYLP/4SdmRBAr
	9ipR5Z03g62NMAubLBz0sQGfQlonZt6O6JOYYXRoqF4U8dBYHu7nVyrszNsv8WfzRD1+
	hesGos+W54+1//rJd2uS//6yNyndHplo/c3qNiDku8mDskOU43/nz1prNSEn/GVVgBRy
	3w1Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=google;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1/z2HptjR302a24hbbwFqasOppfSVXf9++eQRkTCQfg=;
	b=ZHHGAMIgdbc7cqAoTBRpCP0MBYTYP4K+2SiGCeMGuyz0aco812PBFwC71UMfU8V038
	u7m4sC9TR0D9ciBvfNnaaSn+XxVDQHF8HHCIvZlLIo0zry+YVEAQ6Q0n7aFGyTffYjSJ
	YsT9Z5IIaPSnTGKJDZTgDB0qacX/fqfieVP3g=
MIME-Version: 1.0
X-Received: by 10.52.179.3 with SMTP id dc3mr2901372vdc.74.1361550150480; Fri,
	22 Feb 2013 08:22:30 -0800 (PST)
Received: by 10.220.145.131 with HTTP; Fri, 22 Feb 2013 08:22:30 -0800 (PST)
In-Reply-To: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
Date: Fri, 22 Feb 2013 08:22:30 -0800
X-Google-Sender-Auth: nbH_-pnQ2K1dUI4spHtJjNaHXAE
Message-ID: <CA+55aFy=tW2X4O-qKLh_YQjSFX7aBaBme4uy8kxawn1koKdt-g@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "H. Peter Anvin" <hpa@linux.intel.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 16:49:08 +0000
Cc: linux-mips <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	Avi Kivity <avi@redhat.com>, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 4:34 PM, H. Peter Anvin <hpa@linux.intel.com> wrote:
>
> This is a huge set of several partly interrelated (and concurrently
> developed) changes, which is why the branch history is messier than
> one would like.
>
> The *really* big items are two humonguous patchsets mostly developed
> by Yinghai Lu at my request, which completely revamps the way we
> create initial page tables.

Ugh. So I've tried to walk through this, and it's painful. If this
results in problems, we're going to be *so* screwed. Is it bisectable?

I also don't understand how "early_idt_handler" could *possibly* work.
In particular, it seems to rely on the trap number being set up in the
stack frame:

        cmpl $14,72(%rsp)       # Page fault?

but that's not even *true*. Why? Because we export both the
early_idt_handlers[] array (that sets up the trap number and makes the
stack frame be reliable) and the single early_idt_handler function
(that relies on the trap number and the reliable stack frame), AND
AFAIK WE USE THE LATTER!

See x86_64_start_kernel():

        for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
#ifdef CONFIG_EARLY_PRINTK
                set_intr_gate(i, &early_idt_handlers[i]);
#else
                set_intr_gate(i, early_idt_handler);
#endif
        }

so unless you have CONFIG_EARLY_PRINTK, the interrupt gate will point
to that raw early_idt_handler function that doesn't *work* on its own,
afaik.

Btw, it's not just the page fault index testing that is wrong. The whole

        cmpl $__KERNEL_CS,96(%rsp)
        jne 11f

also relies on the stack frame being set up the same way for all
exceptions - which again is only true if we ran through the
early_idt_handlers[] prologue that added the extra stack entry.

How does this even work for me? I don't have EARLY_PRINTK enabled.

What am I missing?

                Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:51:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16: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 1U8vq6-0002BN-9B; Fri, 22 Feb 2013 16:51: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 1U8vq5-0002BE-0d
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:51:13 +0000
Received: from [193.109.254.147:13508] by server-7.bemta-14.messagelabs.com id
	C9/8C-13581-002A7215; Fri, 22 Feb 2013 16:51:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361551826!2112033!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23704 invoked from network); 22 Feb 2013 16:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16: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.297.1; Fri, 22 Feb 2013 16:50:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vpK-0002Kx-2R; Fri, 22 Feb 2013 16:50:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vpJ-0003Fe-UO;
	Fri, 22 Feb 2013 16:50:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.41425.748693.408786@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:50:25 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <E956941E2B3742BB71DC0702@nimrod.local>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> Thanks. I take it the libxl patches can now go in.

This was done on Tuesday.  They haven't reached 4.2-stable yet because
of unrelated difficulties with the 4.2 tree and the push gate, but
they're in 4.2-staging.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:51:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16: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 1U8vq6-0002BN-9B; Fri, 22 Feb 2013 16:51: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 1U8vq5-0002BE-0d
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:51:13 +0000
Received: from [193.109.254.147:13508] by server-7.bemta-14.messagelabs.com id
	C9/8C-13581-002A7215; Fri, 22 Feb 2013 16:51:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361551826!2112033!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23704 invoked from network); 22 Feb 2013 16:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1794791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16: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.297.1; Fri, 22 Feb 2013 16:50:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vpK-0002Kx-2R; Fri, 22 Feb 2013 16:50:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vpJ-0003Fe-UO;
	Fri, 22 Feb 2013 16:50:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.41425.748693.408786@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:50:25 +0000
To: Alex Bligh <alex@alex.org.uk>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <E956941E2B3742BB71DC0702@nimrod.local>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> Thanks. I take it the libxl patches can now go in.

This was done on Tuesday.  They haven't reached 4.2-stable yet because
of unrelated difficulties with the 4.2 tree and the push gate, but
they're in 4.2-staging.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:56:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:56: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 1U8vuu-0002fv-0E; Fri, 22 Feb 2013 16:56: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 1U8vus-0002fn-UO
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:56:11 +0000
Received: from [85.158.139.83:5825] by server-1.bemta-5.messagelabs.com id
	A7/35-29263-923A7215; Fri, 22 Feb 2013 16:56:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361552168!28522369!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6177 invoked from network); 22 Feb 2013 16:56:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:56:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16: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.297.1; Fri, 22 Feb 2013 16:56:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vul-0002Ml-AU; Fri, 22 Feb 2013 16:56:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vul-0003G6-5b;
	Fri, 22 Feb 2013 16:56:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.41762.930346.912025@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:56:02 +0000
To: Ross Philipson <Ross.Philipson@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320CC33BC@FTLPMAILBOX02.citrite.net>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
	<836217002.20130218235800@eikelenboom.it>
	<831D55AF5A11D64C9B4B43F59EEBF720A320CC33BC@FTLPMAILBOX02.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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

Ross Philipson writes ("Re: [Xen-devel] xl segfaults on latest staging/xen-unstable"):
> Yes I got hit with that recently too. BTW I noticed in the configure script
> that ac_default_prefix is set twice, as in:
> 
> ac_default_prefix=/usr/local
> 
> ... a bit later on
> 
> ac_default_prefix=/usr
> 
> Is that intentional or an artifact?

I think this is probably the result of a mistake somewhere...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 16:56:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 16:56: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 1U8vuu-0002fv-0E; Fri, 22 Feb 2013 16:56: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 1U8vus-0002fn-UO
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 16:56:11 +0000
Received: from [85.158.139.83:5825] by server-1.bemta-5.messagelabs.com id
	A7/35-29263-923A7215; Fri, 22 Feb 2013 16:56:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361552168!28522369!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6177 invoked from network); 22 Feb 2013 16:56:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 16:56:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 16: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.297.1; Fri, 22 Feb 2013 16:56:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8vul-0002Ml-AU; Fri, 22 Feb 2013 16:56:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8vul-0003G6-5b;
	Fri, 22 Feb 2013 16:56:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.41762.930346.912025@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 16:56:02 +0000
To: Ross Philipson <Ross.Philipson@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A320CC33BC@FTLPMAILBOX02.citrite.net>
References: <16282745.20130218112144@eikelenboom.it>
	<1361184758.31407.145.camel@zakaz.uk.xensource.com>
	<836217002.20130218235800@eikelenboom.it>
	<831D55AF5A11D64C9B4B43F59EEBF720A320CC33BC@FTLPMAILBOX02.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl segfaults on latest staging/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

Ross Philipson writes ("Re: [Xen-devel] xl segfaults on latest staging/xen-unstable"):
> Yes I got hit with that recently too. BTW I noticed in the configure script
> that ac_default_prefix is set twice, as in:
> 
> ac_default_prefix=/usr/local
> 
> ... a bit later on
> 
> ac_default_prefix=/usr
> 
> Is that intentional or an artifact?

I think this is probably the result of a mistake somewhere...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:00:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8vzA-0002qw-Px; Fri, 22 Feb 2013 17:00:36 +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 1U8vxr-0002nd-Ep
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 16:59:17 +0000
Received: from [85.158.139.211:32423] by server-7.bemta-5.messagelabs.com id
	79/14-11121-2E3A7215; Fri, 22 Feb 2013 16:59:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361552345!18393963!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25369 invoked from network); 22 Feb 2013 16:59:11 -0000
Received: from unknown (HELO aserp1040.oracle.com) (141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 16:59:11 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MGteJ5029018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 16:55:41 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
	r1MGtb0U026898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 16:55:38 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
	r1MGtaWE031325; Fri, 22 Feb 2013 10:55:36 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 08:55:35 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B90E1C3935; Fri, 22 Feb 2013 11:55:31 -0500 (EST)
Date: Fri, 22 Feb 2013 11:55:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Message-ID: <20130222165531.GA29308@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:00:36 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
> Hi Linus,
> 
> This is a huge set of several partly interrelated (and concurrently
> developed) changes, which is why the branch history is messier than
> one would like.
> 
> The *really* big items are two humonguous patchsets mostly developed
> by Yinghai Lu at my request, which completely revamps the way we
> create initial page tables.  In particular, rather than estimating how
> much memory we will need for page tables and then build them into that
> memory -- a calculation that has shown to be incredibly fragile -- we
> now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
> a #PF handler which creates temporary page tables on demand.
> 
> This has several advantages:
> 
> 1. It makes it much easier to support things that need access to
>    data very early (a followon patchset uses this to load microcode
>    way early in the kernel startup).
> 
> 2. It allows the kernel and all the kernel data objects to be invoked
>    from above the 4 GB limit.  This allows kdump to work on very large
>    systems.
> 
> 3. It greatly reduces the difference between Xen and native (Xen's
>    equivalent of the #PF handler are the temporary page tables created
>    by the domain builder), eliminating a bunch of fragile hooks.
> 
> The patch series also gets us a bit closer to W^X.
> 
> Additional work in this pull is the 64-bit get_user() work which you
> were also involved with, and a bunch of cleanups/speedups to
> __phys_addr()/__pa().

Looking at figuring out which of the patches in the branch did this, but
with this merge I am getting a crash with a very simple PV guest (booted with
one 1G):

Call Trace:
  [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
  [<ffffffff8103feba>] xen_get_user_pgd+0x5a 
  [<ffffffff81042d27>] xen_write_cr3+0x77 
  [<ffffffff81ad2d21>] init_mem_mapping+0x1f9 
  [<ffffffff81ac293f>] setup_arch+0x742 
  [<ffffffff81666d71>] printk+0x48 
  [<ffffffff81abcd62>] start_kernel+0x90 
  [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b 
  [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a 
  [<ffffffff81abf0c7>] xen_start_kernel+0x564 

And the hypervisor says:
(XEN) d7:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea000005b2d0:
(XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 7 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e033:[<ffffffff8103feba>]
(XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
(XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
(XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
(XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
(XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
(XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a01d90:
(XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
(XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b


What is bizzare is that I do recall testing this (and Stefano also did it).
So I am not sure what has altered.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:00:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8vzA-0002qw-Px; Fri, 22 Feb 2013 17:00:36 +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 1U8vxr-0002nd-Ep
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 16:59:17 +0000
Received: from [85.158.139.211:32423] by server-7.bemta-5.messagelabs.com id
	79/14-11121-2E3A7215; Fri, 22 Feb 2013 16:59:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361552345!18393963!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25369 invoked from network); 22 Feb 2013 16:59:11 -0000
Received: from unknown (HELO aserp1040.oracle.com) (141.146.126.69)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 16:59:11 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MGteJ5029018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 16:55:41 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
	r1MGtb0U026898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 16:55:38 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
	r1MGtaWE031325; Fri, 22 Feb 2013 10:55:36 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 08:55:35 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B90E1C3935; Fri, 22 Feb 2013 11:55:31 -0500 (EST)
Date: Fri, 22 Feb 2013 11:55:31 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Message-ID: <20130222165531.GA29308@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:00:36 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
> Hi Linus,
> 
> This is a huge set of several partly interrelated (and concurrently
> developed) changes, which is why the branch history is messier than
> one would like.
> 
> The *really* big items are two humonguous patchsets mostly developed
> by Yinghai Lu at my request, which completely revamps the way we
> create initial page tables.  In particular, rather than estimating how
> much memory we will need for page tables and then build them into that
> memory -- a calculation that has shown to be incredibly fragile -- we
> now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
> a #PF handler which creates temporary page tables on demand.
> 
> This has several advantages:
> 
> 1. It makes it much easier to support things that need access to
>    data very early (a followon patchset uses this to load microcode
>    way early in the kernel startup).
> 
> 2. It allows the kernel and all the kernel data objects to be invoked
>    from above the 4 GB limit.  This allows kdump to work on very large
>    systems.
> 
> 3. It greatly reduces the difference between Xen and native (Xen's
>    equivalent of the #PF handler are the temporary page tables created
>    by the domain builder), eliminating a bunch of fragile hooks.
> 
> The patch series also gets us a bit closer to W^X.
> 
> Additional work in this pull is the 64-bit get_user() work which you
> were also involved with, and a bunch of cleanups/speedups to
> __phys_addr()/__pa().

Looking at figuring out which of the patches in the branch did this, but
with this merge I am getting a crash with a very simple PV guest (booted with
one 1G):

Call Trace:
  [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
  [<ffffffff8103feba>] xen_get_user_pgd+0x5a 
  [<ffffffff81042d27>] xen_write_cr3+0x77 
  [<ffffffff81ad2d21>] init_mem_mapping+0x1f9 
  [<ffffffff81ac293f>] setup_arch+0x742 
  [<ffffffff81666d71>] printk+0x48 
  [<ffffffff81abcd62>] start_kernel+0x90 
  [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b 
  [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a 
  [<ffffffff81abf0c7>] xen_start_kernel+0x564 

And the hypervisor says:
(XEN) d7:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea000005b2d0:
(XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 7 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e033:[<ffffffff8103feba>]
(XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
(XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
(XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
(XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
(XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
(XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a01d90:
(XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
(XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b


What is bizzare is that I do recall testing this (and Stefano also did it).
So I am not sure what has altered.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:02:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:02: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 1U8w0a-0002yg-D4; Fri, 22 Feb 2013 17:02:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aliguori@us.ibm.com>) id 1U8w0Z-0002yW-N5
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:02:03 +0000
Received: from [85.158.137.99:6496] by server-4.bemta-3.messagelabs.com id
	90/1A-17521-684A7215; Fri, 22 Feb 2013 17:01:58 +0000
X-Env-Sender: aliguori@us.ibm.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361552514!17466079!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAzMTQ3MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5137 invoked from network); 22 Feb 2013 17:01:57 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:01:57 -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 <aliguori@us.ibm.com>;
	Sat, 23 Feb 2013 02:55:42 +1000
Received: from d23dlp02.au.ibm.com (202.81.31.213)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 23 Feb 2013 02:55:41 +1000
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120])
	by d23dlp02.au.ibm.com (Postfix) with ESMTP id 7CF572BB0051
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 04:01:50 +1100 (EST)
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
	r1MGnPAU8519946
	for <xen-devel@lists.xensource.com>; Sat, 23 Feb 2013 03:49:28 +1100
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
	r1MH1kRc007498
	for <xen-devel@lists.xensource.com>; Sat, 23 Feb 2013 04:01:47 +1100
Received: from localhost6.localdomain6 (sig-9-49-153-3.mts.ibm.com
	[9.49.153.3])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	r1MH1gHi007410; Sat, 23 Feb 2013 04:01:43 +1100
Message-Id: <201302221701.r1MH1gHi007410@d23av04.au.ibm.com>
From: Anthony Liguori <aliguori@us.ibm.com>
To: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
In-Reply-To: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
Date: Fri, 22 Feb 2013 17:01:42 -0000
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13022216-5490-0000-0000-0000030247B0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mark.cave-ayland@ilande.co.uk, agraf@suse.de,
	qemu-stable@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH v2] vga: fix byteswapping.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Applied.  Thanks.

Regards,

Anthony Liguori


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:02:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:02: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 1U8w0a-0002yg-D4; Fri, 22 Feb 2013 17:02:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aliguori@us.ibm.com>) id 1U8w0Z-0002yW-N5
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:02:03 +0000
Received: from [85.158.137.99:6496] by server-4.bemta-3.messagelabs.com id
	90/1A-17521-684A7215; Fri, 22 Feb 2013 17:01:58 +0000
X-Env-Sender: aliguori@us.ibm.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361552514!17466079!1
X-Originating-IP: [202.81.31.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NCA9PiAzMTQ3MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5137 invoked from network); 22 Feb 2013 17:01:57 -0000
Received: from e23smtp02.au.ibm.com (HELO e23smtp02.au.ibm.com) (202.81.31.144)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:01:57 -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 <aliguori@us.ibm.com>;
	Sat, 23 Feb 2013 02:55:42 +1000
Received: from d23dlp02.au.ibm.com (202.81.31.213)
	by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 23 Feb 2013 02:55:41 +1000
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120])
	by d23dlp02.au.ibm.com (Postfix) with ESMTP id 7CF572BB0051
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 04:01:50 +1100 (EST)
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
	r1MGnPAU8519946
	for <xen-devel@lists.xensource.com>; Sat, 23 Feb 2013 03:49:28 +1100
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
	r1MH1kRc007498
	for <xen-devel@lists.xensource.com>; Sat, 23 Feb 2013 04:01:47 +1100
Received: from localhost6.localdomain6 (sig-9-49-153-3.mts.ibm.com
	[9.49.153.3])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	r1MH1gHi007410; Sat, 23 Feb 2013 04:01:43 +1100
Message-Id: <201302221701.r1MH1gHi007410@d23av04.au.ibm.com>
From: Anthony Liguori <aliguori@us.ibm.com>
To: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
In-Reply-To: <1361349432-23884-1-git-send-email-kraxel@redhat.com>
Date: Fri, 22 Feb 2013 17:01:42 -0000
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13022216-5490-0000-0000-0000030247B0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	mark.cave-ayland@ilande.co.uk, agraf@suse.de,
	qemu-stable@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH v2] vga: fix byteswapping.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Applied.  Thanks.

Regards,

Anthony Liguori


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:03:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:03: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 1U8w1c-0003IY-T3; Fri, 22 Feb 2013 17:03: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 1U8w1b-0003IE-Sl
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:03:08 +0000
Received: from [85.158.139.211:30295] by server-16.bemta-5.messagelabs.com id
	D8/BB-14948-AC4A7215; Fri, 22 Feb 2013 17:03:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361552585!17960788!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 22 Feb 2013 17:03:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:03:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:03: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.297.1; Fri, 22 Feb 2013 17:03:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8w1Z-0002Om-Ht; Fri, 22 Feb 2013 17:03:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8w1Z-0003Hs-E4;
	Fri, 22 Feb 2013 17:03:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42185.250978.461354@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:03:05 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d13841ebeb080e3dea9b.1360770779@probook.site>
References: <patchbomb.1360770778@probook.site>
	<d13841ebeb080e3dea9b.1360770779@probook.site>
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 1 of 7] tools/xc: fix logic error
	in	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1 of 7] tools/xc: fix logic error in stdiostream_progress"):
> tools/xc: fix logic error in stdiostream_progress

Applied, 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 Feb 22 17:03:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:03: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 1U8w1c-0003IY-T3; Fri, 22 Feb 2013 17:03: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 1U8w1b-0003IE-Sl
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:03:08 +0000
Received: from [85.158.139.211:30295] by server-16.bemta-5.messagelabs.com id
	D8/BB-14948-AC4A7215; Fri, 22 Feb 2013 17:03:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361552585!17960788!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 22 Feb 2013 17:03:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:03:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:03: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.297.1; Fri, 22 Feb 2013 17:03:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8w1Z-0002Om-Ht; Fri, 22 Feb 2013 17:03:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8w1Z-0003Hs-E4;
	Fri, 22 Feb 2013 17:03:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42185.250978.461354@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:03:05 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d13841ebeb080e3dea9b.1360770779@probook.site>
References: <patchbomb.1360770778@probook.site>
	<d13841ebeb080e3dea9b.1360770779@probook.site>
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 1 of 7] tools/xc: fix logic error
	in	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1 of 7] tools/xc: fix logic error in stdiostream_progress"):
> tools/xc: fix logic error in stdiostream_progress

Applied, 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 Feb 22 17:05:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:05: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 1U8w3X-0003St-E0; Fri, 22 Feb 2013 17:05: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 1U8w3V-0003Se-Pb
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:05:05 +0000
Received: from [85.158.137.99:30220] by server-3.bemta-3.messagelabs.com id
	A1/A8-31070-C35A7215; Fri, 22 Feb 2013 17:05:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361552699!12276536!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24994 invoked from network); 22 Feb 2013 17:05:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:05: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.297.1; Fri, 22 Feb 2013 17:04:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8w3P-0002PN-9p; Fri, 22 Feb 2013 17:04:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8w3P-0003IJ-5b;
	Fri, 22 Feb 2013 17:04:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42298.906250.582926@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:04:58 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1518e1b1341a56e8ea52.1360770780@probook.site>
References: <patchbomb.1360770778@probook.site>
	<1518e1b1341a56e8ea52.1360770780@probook.site>
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 2 of 7] tools/xc: handle tty output
 differently in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 2 of 7] tools/xc: handle tty output differently in stdiostream_progress"):
> tools/xc: handle tty output differently in stdiostream_progress
> 
> If the output goes to a tty, rewind the cursor and print everything in a
> single line as it was done up to now. If the output goes to a file or
> pipe print a newline after each progress output. This will fix logging
> of progress messages from xc_save to xend.log.
> 
> To support XTL_STDIOSTREAM_SHOW_PID or XTL_STDIOSTREAM_SHOW_DATE print
> the output via vmessage if the output is not a tty.

Can we lift the call to isatty out of the loop by calling it at
setup ?

Calling it continually is undesirable not really for performance
reasons but because it always trashes errno and because it will make
strace output more noisy.

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 Feb 22 17:05:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:05: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 1U8w3X-0003St-E0; Fri, 22 Feb 2013 17:05: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 1U8w3V-0003Se-Pb
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:05:05 +0000
Received: from [85.158.137.99:30220] by server-3.bemta-3.messagelabs.com id
	A1/A8-31070-C35A7215; Fri, 22 Feb 2013 17:05:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361552699!12276536!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24994 invoked from network); 22 Feb 2013 17:05:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:05:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:05: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.297.1; Fri, 22 Feb 2013 17:04:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8w3P-0002PN-9p; Fri, 22 Feb 2013 17:04:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8w3P-0003IJ-5b;
	Fri, 22 Feb 2013 17:04:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42298.906250.582926@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:04:58 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1518e1b1341a56e8ea52.1360770780@probook.site>
References: <patchbomb.1360770778@probook.site>
	<1518e1b1341a56e8ea52.1360770780@probook.site>
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 2 of 7] tools/xc: handle tty output
 differently in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 2 of 7] tools/xc: handle tty output differently in stdiostream_progress"):
> tools/xc: handle tty output differently in stdiostream_progress
> 
> If the output goes to a tty, rewind the cursor and print everything in a
> single line as it was done up to now. If the output goes to a file or
> pipe print a newline after each progress output. This will fix logging
> of progress messages from xc_save to xend.log.
> 
> To support XTL_STDIOSTREAM_SHOW_PID or XTL_STDIOSTREAM_SHOW_DATE print
> the output via vmessage if the output is not a tty.

Can we lift the call to isatty out of the loop by calling it at
setup ?

Calling it continually is undesirable not really for performance
reasons but because it always trashes errno and because it will make
strace output more noisy.

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 Feb 22 17:06:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:06: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 1U8w58-0003cQ-UV; Fri, 22 Feb 2013 17:06:46 +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 1U8w57-0003c7-2G
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:06:45 +0000
Received: from [193.109.254.147:8110] by server-1.bemta-14.messagelabs.com id
	72/E4-29874-4A5A7215; Fri, 22 Feb 2013 17:06:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361552803!2560193!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTY1Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTY1Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4592 invoked from network); 22 Feb 2013 17:06:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with SMTP;
	22 Feb 2013 17:06:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (josoe mo46) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D04dbbp1MGOR0E ;
	Fri, 22 Feb 2013 18:06:43 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 09EBD1884C; Fri, 22 Feb 2013 18:06:42 +0100 (CET)
Date: Fri, 22 Feb 2013 18:06:42 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130222170642.GA25362@aepfle.de>
References: <patchbomb.1360770778@probook.site>
	<1518e1b1341a56e8ea52.1360770780@probook.site>
	<20775.42298.906250.582926@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20775.42298.906250.582926@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output
 differently in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output differently in stdiostream_progress"):
> > tools/xc: handle tty output differently in stdiostream_progress
> > 
> > If the output goes to a tty, rewind the cursor and print everything in a
> > single line as it was done up to now. If the output goes to a file or
> > pipe print a newline after each progress output. This will fix logging
> > of progress messages from xc_save to xend.log.
> > 
> > To support XTL_STDIOSTREAM_SHOW_PID or XTL_STDIOSTREAM_SHOW_DATE print
> > the output via vmessage if the output is not a tty.
> 
> Can we lift the call to isatty out of the loop by calling it at
> setup ?
> 
> Calling it continually is undesirable not really for performance
> reasons but because it always trashes errno and because it will make
> strace output more noisy.

Ok, I will prepare a patch. I think that series is already applied.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:06:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:06: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 1U8w58-0003cQ-UV; Fri, 22 Feb 2013 17:06:46 +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 1U8w57-0003c7-2G
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:06:45 +0000
Received: from [193.109.254.147:8110] by server-1.bemta-14.messagelabs.com id
	72/E4-29874-4A5A7215; Fri, 22 Feb 2013 17:06:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361552803!2560193!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTY1Mjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1OTY1Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4592 invoked from network); 22 Feb 2013 17:06:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with SMTP;
	22 Feb 2013 17:06:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (josoe mo46) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D04dbbp1MGOR0E ;
	Fri, 22 Feb 2013 18:06:43 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 09EBD1884C; Fri, 22 Feb 2013 18:06:42 +0100 (CET)
Date: Fri, 22 Feb 2013 18:06:42 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130222170642.GA25362@aepfle.de>
References: <patchbomb.1360770778@probook.site>
	<1518e1b1341a56e8ea52.1360770780@probook.site>
	<20775.42298.906250.582926@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20775.42298.906250.582926@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output
 differently in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output differently in stdiostream_progress"):
> > tools/xc: handle tty output differently in stdiostream_progress
> > 
> > If the output goes to a tty, rewind the cursor and print everything in a
> > single line as it was done up to now. If the output goes to a file or
> > pipe print a newline after each progress output. This will fix logging
> > of progress messages from xc_save to xend.log.
> > 
> > To support XTL_STDIOSTREAM_SHOW_PID or XTL_STDIOSTREAM_SHOW_DATE print
> > the output via vmessage if the output is not a tty.
> 
> Can we lift the call to isatty out of the loop by calling it at
> setup ?
> 
> Calling it continually is undesirable not really for performance
> reasons but because it always trashes errno and because it will make
> strace output more noisy.

Ok, I will prepare a patch. I think that series is already applied.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:08:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8w6l-0003lj-MM; Fri, 22 Feb 2013 17:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8w6k-0003la-6k
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:08:26 +0000
Received: from [85.158.143.99:40781] by server-1.bemta-4.messagelabs.com id
	02/9D-06203-906A7215; Fri, 22 Feb 2013 17:08:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361552904!21767457!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12803 invoked from network); 22 Feb 2013 17:08:24 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-6.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 17:08:24 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1F846C56195;
	Fri, 22 Feb 2013 17:08:12 +0000 (GMT)
Date: Fri, 22 Feb 2013 17:08:11 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <4CECB0F28D4441D2BD4AC7E3@nimrod.local>
In-Reply-To: <20775.41425.748693.408786@mariner.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

--On 22 February 2013 16:50:25 +0000 Ian Jackson 
<Ian.Jackson@eu.citrix.com> wrote:

> Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling
> live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
>> Thanks. I take it the libxl patches can now go in.
>
> This was done on Tuesday.  They haven't reached 4.2-stable yet because
> of unrelated difficulties with the 4.2 tree and the push gate, but
> they're in 4.2-staging.

Thanks. Would I expect to see a commit in xen's -staging that references the
change in qemu commit ID or does that only happen once things have got
to -stable?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:08:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8w6l-0003lj-MM; Fri, 22 Feb 2013 17:08:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8w6k-0003la-6k
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:08:26 +0000
Received: from [85.158.143.99:40781] by server-1.bemta-4.messagelabs.com id
	02/9D-06203-906A7215; Fri, 22 Feb 2013 17:08:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361552904!21767457!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12803 invoked from network); 22 Feb 2013 17:08:24 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-6.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 17:08:24 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1F846C56195;
	Fri, 22 Feb 2013 17:08:12 +0000 (GMT)
Date: Fri, 22 Feb 2013 17:08:11 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <4CECB0F28D4441D2BD4AC7E3@nimrod.local>
In-Reply-To: <20775.41425.748693.408786@mariner.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Ian,

--On 22 February 2013 16:50:25 +0000 Ian Jackson 
<Ian.Jackson@eu.citrix.com> wrote:

> Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling
> live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
>> Thanks. I take it the libxl patches can now go in.
>
> This was done on Tuesday.  They haven't reached 4.2-stable yet because
> of unrelated difficulties with the 4.2 tree and the push gate, but
> they're in 4.2-staging.

Thanks. Would I expect to see a commit in xen's -staging that references the
change in qemu commit ID or does that only happen once things have got
to -stable?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:10:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:10: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 1U8w8S-0003uL-6b; Fri, 22 Feb 2013 17:10: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 1U8w8R-0003uE-91
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:10:11 +0000
Received: from [85.158.143.99:38581] by server-3.bemta-4.messagelabs.com id
	0F/24-02186-276A7215; Fri, 22 Feb 2013 17:10:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361553009!21767696!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17860 invoked from network); 22 Feb 2013 17:10:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:10:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:10: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.297.1; Fri, 22 Feb 2013 17:10:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8w8O-0002R2-NM; Fri, 22 Feb 2013 17:10:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8w8O-0003LC-Iz;
	Fri, 22 Feb 2013 17:10:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42608.387984.342464@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:10:08 +0000
To: Olaf Hering <olaf@aepfle.de>,
    xen-devel@lists.xen.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20775.42298.906250.582926@mariner.uk.xensource.com>
References: <patchbomb.1360770778@probook.site>
	<1518e1b1341a56e8ea52.1360770780@probook.site>
	<20775.42298.906250.582926@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output
 differently in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 2 of 7] tools/xc: handle tty output> Can we lift the call to isatty out of the loop by calling it at
> setup ?
> 
> Calling it continually is undesirable not really for performance
> reasons but because it always trashes errno and because it will make
> strace output more noisy.

Never mind, I see Ian Campbell has applied this already.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:10:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:10: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 1U8w8S-0003uL-6b; Fri, 22 Feb 2013 17:10: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 1U8w8R-0003uE-91
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:10:11 +0000
Received: from [85.158.143.99:38581] by server-3.bemta-4.messagelabs.com id
	0F/24-02186-276A7215; Fri, 22 Feb 2013 17:10:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361553009!21767696!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17860 invoked from network); 22 Feb 2013 17:10:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:10:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:10: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.297.1; Fri, 22 Feb 2013 17:10:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8w8O-0002R2-NM; Fri, 22 Feb 2013 17:10:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8w8O-0003LC-Iz;
	Fri, 22 Feb 2013 17:10:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42608.387984.342464@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:10:08 +0000
To: Olaf Hering <olaf@aepfle.de>,
    xen-devel@lists.xen.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20775.42298.906250.582926@mariner.uk.xensource.com>
References: <patchbomb.1360770778@probook.site>
	<1518e1b1341a56e8ea52.1360770780@probook.site>
	<20775.42298.906250.582926@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 2 of 7] tools/xc: handle tty output
 differently in stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 2 of 7] tools/xc: handle tty output> Can we lift the call to isatty out of the loop by calling it at
> setup ?
> 
> Calling it continually is undesirable not really for performance
> reasons but because it always trashes errno and because it will make
> strace output more noisy.

Never mind, I see Ian Campbell has applied this already.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:13:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wBN-0004PO-Ty; Fri, 22 Feb 2013 17:13: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 1U8wBL-0004PB-Ey
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:13:11 +0000
Received: from [85.158.139.83:59742] by server-9.bemta-5.messagelabs.com id
	98/FA-24440-627A7215; Fri, 22 Feb 2013 17:13:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361553189!24619523!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32575 invoked from network); 22 Feb 2013 17:13:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:13:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:13: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.297.1; Fri, 22 Feb 2013 17:13:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wBI-0002TD-Qt; Fri, 22 Feb 2013 17:13:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wBI-0003Mq-L8;
	Fri, 22 Feb 2013 17:13:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42788.510270.735773@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:13:08 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <4CECB0F28D4441D2BD4AC7E3@nimrod.local>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
	<4CECB0F28D4441D2BD4AC7E3@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> Ian,
> 
> --On 22 February 2013 16:50:25 +0000 Ian Jackson 
> <Ian.Jackson@eu.citrix.com> wrote:
> 
> > Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling
> > live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> >> Thanks. I take it the libxl patches can now go in.
> >
> > This was done on Tuesday.  They haven't reached 4.2-stable yet because
> > of unrelated difficulties with the 4.2 tree and the push gate, but
> > they're in 4.2-staging.
> 
> Thanks. Would I expect to see a commit in xen's -staging that references the
> change in qemu commit ID or does that only happen once things have got
> to -stable?

I was referring to the libxl changes.  The changes to
qemu-xen-upstream's tag in Config.mk don't seem to have been done
yet.  Stefano, do you have a process for updating that ?  Shall I do
it this time ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:13:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wBN-0004PO-Ty; Fri, 22 Feb 2013 17:13: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 1U8wBL-0004PB-Ey
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:13:11 +0000
Received: from [85.158.139.83:59742] by server-9.bemta-5.messagelabs.com id
	98/FA-24440-627A7215; Fri, 22 Feb 2013 17:13:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361553189!24619523!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32575 invoked from network); 22 Feb 2013 17:13:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:13:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:13: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.297.1; Fri, 22 Feb 2013 17:13:09 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wBI-0002TD-Qt; Fri, 22 Feb 2013 17:13:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wBI-0003Mq-L8;
	Fri, 22 Feb 2013 17:13:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.42788.510270.735773@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:13:08 +0000
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <4CECB0F28D4441D2BD4AC7E3@nimrod.local>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
	<4CECB0F28D4441D2BD4AC7E3@nimrod.local>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> Ian,
> 
> --On 22 February 2013 16:50:25 +0000 Ian Jackson 
> <Ian.Jackson@eu.citrix.com> wrote:
> 
> > Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling
> > live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> >> Thanks. I take it the libxl patches can now go in.
> >
> > This was done on Tuesday.  They haven't reached 4.2-stable yet because
> > of unrelated difficulties with the 4.2 tree and the push gate, but
> > they're in 4.2-staging.
> 
> Thanks. Would I expect to see a commit in xen's -staging that references the
> change in qemu commit ID or does that only happen once things have got
> to -stable?

I was referring to the libxl changes.  The changes to
qemu-xen-upstream's tag in Config.mk don't seem to have been done
yet.  Stefano, do you have a process for updating that ?  Shall I do
it this time ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:14:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:14: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 1U8wC4-0004Sj-BW; Fri, 22 Feb 2013 17:13:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8wC3-0004SY-Hs
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:13:55 +0000
Received: from [85.158.143.99:2988] by server-1.bemta-4.messagelabs.com id
	4F/31-06203-257A7215; Fri, 22 Feb 2013 17:13:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361553234!25429358!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21464 invoked from network); 22 Feb 2013 17:13:54 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 17:13:54 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1D2D6C5618E;
	Fri, 22 Feb 2013 17:13:42 +0000 (GMT)
Date: Fri, 22 Feb 2013 17:13:41 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Message-ID: <73B7FEB65DB959FF75707D5A@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

The xen debian packaging currently produces a debian package of what
'make install' would produce. This includes a fair amount of development
only stuff, puts the hypervisor in /boot etc.

This packaging is not used by Ubuntu (I don't know about debian).

I have a hack:
 
https://github.com/abligh/xen-4.2-live-migrate/commit/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74

that produces a 'minideb'. The idea was to put in the minimum of userspace
code that would be required to run xen4.2 and xl. This excludes the
hypervisor which if I were less lazy would be in a separate package,
as you don't need that on disk when you are network booting.

Is there any interest in taking this into mainline if I clear it up?
It's just another make target (make minideb) so is pretty unintrusive.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:14:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:14: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 1U8wC4-0004Sj-BW; Fri, 22 Feb 2013 17:13:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8wC3-0004SY-Hs
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:13:55 +0000
Received: from [85.158.143.99:2988] by server-1.bemta-4.messagelabs.com id
	4F/31-06203-257A7215; Fri, 22 Feb 2013 17:13:54 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361553234!25429358!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21464 invoked from network); 22 Feb 2013 17:13:54 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 17:13:54 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 1D2D6C5618E;
	Fri, 22 Feb 2013 17:13:42 +0000 (GMT)
Date: Fri, 22 Feb 2013 17:13:41 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Xen Devel <xen-devel@lists.xen.org>
Message-ID: <73B7FEB65DB959FF75707D5A@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

The xen debian packaging currently produces a debian package of what
'make install' would produce. This includes a fair amount of development
only stuff, puts the hypervisor in /boot etc.

This packaging is not used by Ubuntu (I don't know about debian).

I have a hack:
 
https://github.com/abligh/xen-4.2-live-migrate/commit/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74

that produces a 'minideb'. The idea was to put in the minimum of userspace
code that would be required to run xen4.2 and xl. This excludes the
hypervisor which if I were less lazy would be in a separate package,
as you don't need that on disk when you are network booting.

Is there any interest in taking this into mainline if I clear it up?
It's just another make target (make minideb) so is pretty unintrusive.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:18:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wGi-0004j3-9a; Fri, 22 Feb 2013 17:18: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 1U8wGg-0004iv-BI
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:18:42 +0000
Received: from [85.158.139.211:57853] by server-12.bemta-5.messagelabs.com id
	DD/9C-20195-178A7215; Fri, 22 Feb 2013 17:18:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361553520!18808033!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16446 invoked from network); 22 Feb 2013 17:18:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:18:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:17: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.297.1; Fri, 22 Feb 2013 17:17:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wFT-0002UZ-Ac; Fri, 22 Feb 2013 17:17:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wFT-0003VV-64;
	Fri, 22 Feb 2013 17:17:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.43039.389368.622913@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:17:19 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
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 0/3] FLASK policy build rework
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("[Xen-devel] [PATCH 0/3] FLASK policy build rework"):
> These patches update the example FLASK policy shipped with Xen and
> enable its build if the required tools are present. The third patch
> requires rerunning autoconf to update tools/configure.
> 
> [PATCH 1/3] flask/policy: sort dom0 accesses
> [PATCH 2/3] flask/policy: rework policy build system
> [PATCH 3/3] tools/flask: add FLASK policy to build

Applied all three, 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 Feb 22 17:18:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wGi-0004j3-9a; Fri, 22 Feb 2013 17:18: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 1U8wGg-0004iv-BI
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:18:42 +0000
Received: from [85.158.139.211:57853] by server-12.bemta-5.messagelabs.com id
	DD/9C-20195-178A7215; Fri, 22 Feb 2013 17:18:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361553520!18808033!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16446 invoked from network); 22 Feb 2013 17:18:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:18:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1795870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:17: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.297.1; Fri, 22 Feb 2013 17:17:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wFT-0002UZ-Ac; Fri, 22 Feb 2013 17:17:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wFT-0003VV-64;
	Fri, 22 Feb 2013 17:17:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.43039.389368.622913@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:17:19 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1360771294-11763-1-git-send-email-dgdegra@tycho.nsa.gov>
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 0/3] FLASK policy build rework
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("[Xen-devel] [PATCH 0/3] FLASK policy build rework"):
> These patches update the example FLASK policy shipped with Xen and
> enable its build if the required tools are present. The third patch
> requires rerunning autoconf to update tools/configure.
> 
> [PATCH 1/3] flask/policy: sort dom0 accesses
> [PATCH 2/3] flask/policy: rework policy build system
> [PATCH 3/3] tools/flask: add FLASK policy to build

Applied all three, 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 Feb 22 17:20:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wID-0004q6-To; Fri, 22 Feb 2013 17:20:17 +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 1U8wGX-0004iP-4R
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:18:33 +0000
Received: from [193.109.254.147:29879] by server-2.bemta-14.messagelabs.com id
	EA/B2-16277-868A7215; Fri, 22 Feb 2013 17:18:32 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361553502!2561419!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10699 invoked from network); 22 Feb 2013 17:18:25 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:18:25 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHD24g006576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:13:03 -0800
Message-ID: <5127A719.3060702@zytor.com>
Date: Fri, 22 Feb 2013 09:12:57 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
In-Reply-To: <20130222165531.GA29308@phenom.dumpdata.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:20:16 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>
> What is bizzare is that I do recall testing this (and Stefano also did it).
> So I am not sure what has altered.
>

Yes, there was a very specific reason why I wanted you guys to test it...

	-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 Fri Feb 22 17:20:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wID-0004q6-To; Fri, 22 Feb 2013 17:20:17 +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 1U8wGX-0004iP-4R
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:18:33 +0000
Received: from [193.109.254.147:29879] by server-2.bemta-14.messagelabs.com id
	EA/B2-16277-868A7215; Fri, 22 Feb 2013 17:18:32 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361553502!2561419!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10699 invoked from network); 22 Feb 2013 17:18:25 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:18:25 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHD24g006576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:13:03 -0800
Message-ID: <5127A719.3060702@zytor.com>
Date: Fri, 22 Feb 2013 09:12:57 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
In-Reply-To: <20130222165531.GA29308@phenom.dumpdata.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:20:16 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>
> What is bizzare is that I do recall testing this (and Stefano also did it).
> So I am not sure what has altered.
>

Yes, there was a very specific reason why I wanted you guys to test it...

	-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 Fri Feb 22 17:27:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:27: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 1U8wOu-0005M1-0n; Fri, 22 Feb 2013 17:27: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 1U8wNz-0005LN-Ne
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:26:16 +0000
Received: from [85.158.138.51:31693] by server-6.bemta-3.messagelabs.com id
	AF/D0-29959-23AA7215; Fri, 22 Feb 2013 17:26:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361553961!20690849!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10400 invoked from network); 22 Feb 2013 17:26:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:26:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHOD8J031407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:24: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
	r1MHO9mE000990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:24:10 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
	r1MHO8CM022422; Fri, 22 Feb 2013 11:24:08 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:24:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E7D701C3935; Fri, 22 Feb 2013 12:24:03 -0500 (EST)
Date: Fri, 22 Feb 2013 12:24:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>, yinghai@kernel.org
Message-ID: <20130222172403.GA17056@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130222165531.GA29308@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:27:11 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
> > Hi Linus,
> > 
> > This is a huge set of several partly interrelated (and concurrently
> > developed) changes, which is why the branch history is messier than
> > one would like.
> > 
> > The *really* big items are two humonguous patchsets mostly developed
> > by Yinghai Lu at my request, which completely revamps the way we
> > create initial page tables.  In particular, rather than estimating how
> > much memory we will need for page tables and then build them into that
> > memory -- a calculation that has shown to be incredibly fragile -- we
> > now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
> > a #PF handler which creates temporary page tables on demand.
> > 
> > This has several advantages:
> > 
> > 1. It makes it much easier to support things that need access to
> >    data very early (a followon patchset uses this to load microcode
> >    way early in the kernel startup).
> > 
> > 2. It allows the kernel and all the kernel data objects to be invoked
> >    from above the 4 GB limit.  This allows kdump to work on very large
> >    systems.
> > 
> > 3. It greatly reduces the difference between Xen and native (Xen's
> >    equivalent of the #PF handler are the temporary page tables created
> >    by the domain builder), eliminating a bunch of fragile hooks.
> > 
> > The patch series also gets us a bit closer to W^X.
> > 
> > Additional work in this pull is the 64-bit get_user() work which you
> > were also involved with, and a bunch of cleanups/speedups to
> > __phys_addr()/__pa().
> 
> Looking at figuring out which of the patches in the branch did this, but
> with this merge I am getting a crash with a very simple PV guest (booted with
> one 1G):
> 
> Call Trace:
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a 
>   [<ffffffff81042d27>] xen_write_cr3+0x77 
>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9 
>   [<ffffffff81ac293f>] setup_arch+0x742 
>   [<ffffffff81666d71>] printk+0x48 
>   [<ffffffff81abcd62>] start_kernel+0x90 
>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b 
>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a 
>   [<ffffffff81abf0c7>] xen_start_kernel+0x564 
> 
> And the hypervisor says:
> (XEN) d7:v0: unhandled page fault (ec=0000)
> (XEN) Pagetable walk from ffffea000005b2d0:
> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 7 (vcpu#0) crashed on cpu#3:
> (XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    3
> (XEN) RIP:    e033:[<ffffffff8103feba>]
> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
> (XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
> (XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> (XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b

Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
kernel with 8GB):

PXELINUX 3.82 2009-06-09  Copyright (C) 1994-2009 H. Peter Anvin et al
boot: 
Loading xen.gz... ok
Loading vmlinuz... ok
Loading initramfs.cpio.gz... ok
 __  __            _  _    _   ____                    
 \ \/ /___ _ __   | || |  / | | ___|    _ __  _ __ ___ 
  \  // _ \ '_(_)_(_)____/   | .__/|_|  \___|
                                       |_|             
(XEN) Xen version 4.1.5-pre (konrad@dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) Fri Feb 22 11:37:00 EST 2013
(XEN) Latest ChangeSet: Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
(XEN) Console output is synchronous.
(XEN) Bootloader: unknown
(XEN) Command line: cpuinfo conring_size=1048576 sync_console cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ec00 (usable)
(XEN)  000000000009ec00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 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)
(XEN)  00000000badc9000 - 00000000badd1000 (ACPI data)
(XEN)  00000000badd1000 - 00000000badf4000 (reserved)
(XEN)  00000000badf4000 - 00000000badf6000 (usable)
(XEN)  00000000badf6000 - 00000000bae06000 (reserved)
(XEN)  00000000bae06000 - 00000000bae14000 (ACPI NVS)
(XEN)  00000000bae14000 - 00000000bae3c000 (reserved)
(XEN)  00000000bae3c000 - 00000000bae7f000 (ACPI NVS)
(XEN)  00000000bae7f000 - 00000000bb000000 (usable)
(XEN)  00000000bb800000 - 00000000bfa00000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000023fe00000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BADC9068, 0054 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN)  PROC        1 MSFT  3000001)
(XEN) ACPI: MCFG BADD0580, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: HPET BADD05C0, 0038 (r1 ALASKA    A M I  1072009 AMI.        4)
(XEN) ACPI: ASF! BADD05F8, 00A0 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) System RAM: 8104MB (8299140kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000023fe00000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fcde0
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - bae0bf80/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[bae0bf8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
(XEN) Processor #1 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
(XEN) Processor #3 6:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 3093.067 MHz processor.
(XEN) Initing memory sharing.
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 3072K
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
(XEN) CPU0: Thermal monitoring enabled (TM1)
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 1048576 KiB.
(XEN) VMX: Supported advanced features:
(isation
(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
(XEN) Booting processor 1/1 eip 7c000
(XEN) Initializing CPU#1
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) CPU: L1 I cache: 32K, L1 D
(XEN) Initializing CPU#2
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 3072K
(XEN) CPU2: Thermal monitoring enabled (TM1)
(XEN) CPU2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
(XEN) Booting processor 3/3 eip 7c000
(XEN) Initializing CPU#3
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CPU: L1 I cache: 32K, L1 D100 CPU @ 3.10GHz stepping 07
(XEN) Brought up 4 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x9e0000
(XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xa60f0
(XEN): paddr=0x1abc000 memsz=0x61b000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x20d7000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81abc1e0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff820d7000
(XEN)     virt_entry       = 0xffffffff81abc1e0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20d7000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (1661249 pages to be allocated)
(XEN)  Init. ramdisk: 000000022cbdc000->000000023fe00000
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff820d7000
(XEN)  Init. ramdisk: ffffffff820d7000->ffffffff952fb000
(XEN)  Phys-Mach map: ffffffff952fb000->ffffffff96060b28
(XEN)  Start info:    ffffffff96061000->ffffffff960614b4
(XEN)  Page tables:   ffffffff96062000->ffffffff96117000
(XEN)  Boot stack:    ffffffff96117000->ffffffff96118000
(XEN)  TOTAL:         ffffffff80000000->ffffffff96400000
(XEN)  ENTRY ADDRESS: ffffffff81abc1e0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff819e0000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81aa60f0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81aa7000 -> 0xffffffff81abbbc0
(XEN) elf_load_binary: phdr 3 at 0xffffffff81abc000 -> 0xffffffff81baf000
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) ***************************intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1... 
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 224kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0upstream-06471-g2ef14f4-dirty (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 11:36:48 EST 2013
[    0.000000] Command line: initcall_debug debug console=hvc0 loglevel=10 xen-pciback.hide=(01:00.0) earlyprintk=xen
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] 1-1 mapping on 9e->100
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] Freeing 40000-40200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 40000->40200
[    0.000000] Freeing bad80-badf4 pfn range: 116 pages freed
[    0.000000] 1-1 mapping on bad80->badf4
[    0.000000] Freeing badf6-bae7f pfn range: 137 pages freed
[    0.000000] 1-1 mapping on badf6->bae7f
[    0.000000] Freeing bb000-100000 pfn range: 282624 pages freed
[    0.000000] 1-1 mapping on bb000->100000
[    0.000000] Released 283999 pages of unused memory
[    0.000000] Set 283999 page(s) to 1-1 mapping
[    0.000000] Populating 1acb65-1f20c4 pfn range: 283999 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x000000000009ec00-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable
[    0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved
[    0.000000] Xen: [mem 0x0000000040200000-0x00000000bad7ffff] usable
[    0.000000] Xen: [mem 0x00000000bad80000-0x00000000badc8fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000badc9000-0x00000000badd0fff] ACPI data
[    0.000000] Xen: [mem 0x00000000badd1000-0x00000000badf3fff] reserved
[    0.000000] Xen: [mem 0x00000000badf4000-0x00000000badf5fff] usable
[    0.000000] Xen: [mem 0x00000000badf6000-0x00000000bae05fff] reserved
[    0.000000] Xen: [mem 0x00000000bae06000-0x00000000bae13fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bae14000-0x00000000bae3bfff] reserved
[    0.000000] Xen: [mem 0x00000000bae3c000-0x00000000bae7efff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bae7f000-0x00000000baffffff] usable
[    0.000000] Xen: [mem 0x00000000bb800000-0x00000000bf9fffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000023fdfffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
[    0.000000] e820: lacanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
[    0.000000] reserving inaccessible SNB gfx pages
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
[    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
[    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
[    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
[    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
[    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
[    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
[    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
[    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
[    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
[    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
[    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
[    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
[    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
[    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
[    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k
(XEN) d0:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea000005b2d0:
(XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff8103feba>]
(XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
(XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
(XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
(XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
(XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
(XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a01d90:
(XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
(XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
(XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
(XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
(XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
(XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
(XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
(XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
(XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
(XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
(XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
(XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:27:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:27: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 1U8wOu-0005M1-0n; Fri, 22 Feb 2013 17:27: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 1U8wNz-0005LN-Ne
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:26:16 +0000
Received: from [85.158.138.51:31693] by server-6.bemta-3.messagelabs.com id
	AF/D0-29959-23AA7215; Fri, 22 Feb 2013 17:26:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361553961!20690849!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10400 invoked from network); 22 Feb 2013 17:26:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:26:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHOD8J031407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:24: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
	r1MHO9mE000990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:24:10 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
	r1MHO8CM022422; Fri, 22 Feb 2013 11:24:08 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:24:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E7D701C3935; Fri, 22 Feb 2013 12:24:03 -0500 (EST)
Date: Fri, 22 Feb 2013 12:24:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>, yinghai@kernel.org
Message-ID: <20130222172403.GA17056@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130222165531.GA29308@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:27:11 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
> > Hi Linus,
> > 
> > This is a huge set of several partly interrelated (and concurrently
> > developed) changes, which is why the branch history is messier than
> > one would like.
> > 
> > The *really* big items are two humonguous patchsets mostly developed
> > by Yinghai Lu at my request, which completely revamps the way we
> > create initial page tables.  In particular, rather than estimating how
> > much memory we will need for page tables and then build them into that
> > memory -- a calculation that has shown to be incredibly fragile -- we
> > now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
> > a #PF handler which creates temporary page tables on demand.
> > 
> > This has several advantages:
> > 
> > 1. It makes it much easier to support things that need access to
> >    data very early (a followon patchset uses this to load microcode
> >    way early in the kernel startup).
> > 
> > 2. It allows the kernel and all the kernel data objects to be invoked
> >    from above the 4 GB limit.  This allows kdump to work on very large
> >    systems.
> > 
> > 3. It greatly reduces the difference between Xen and native (Xen's
> >    equivalent of the #PF handler are the temporary page tables created
> >    by the domain builder), eliminating a bunch of fragile hooks.
> > 
> > The patch series also gets us a bit closer to W^X.
> > 
> > Additional work in this pull is the 64-bit get_user() work which you
> > were also involved with, and a bunch of cleanups/speedups to
> > __phys_addr()/__pa().
> 
> Looking at figuring out which of the patches in the branch did this, but
> with this merge I am getting a crash with a very simple PV guest (booted with
> one 1G):
> 
> Call Trace:
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a 
>   [<ffffffff81042d27>] xen_write_cr3+0x77 
>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9 
>   [<ffffffff81ac293f>] setup_arch+0x742 
>   [<ffffffff81666d71>] printk+0x48 
>   [<ffffffff81abcd62>] start_kernel+0x90 
>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b 
>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a 
>   [<ffffffff81abf0c7>] xen_start_kernel+0x564 
> 
> And the hypervisor says:
> (XEN) d7:v0: unhandled page fault (ec=0000)
> (XEN) Pagetable walk from ffffea000005b2d0:
> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 7 (vcpu#0) crashed on cpu#3:
> (XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    3
> (XEN) RIP:    e033:[<ffffffff8103feba>]
> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
> (XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
> (XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> (XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b

Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
kernel with 8GB):

PXELINUX 3.82 2009-06-09  Copyright (C) 1994-2009 H. Peter Anvin et al
boot: 
Loading xen.gz... ok
Loading vmlinuz... ok
Loading initramfs.cpio.gz... ok
 __  __            _  _    _   ____                    
 \ \/ /___ _ __   | || |  / | | ___|    _ __  _ __ ___ 
  \  // _ \ '_(_)_(_)____/   | .__/|_|  \___|
                                       |_|             
(XEN) Xen version 4.1.5-pre (konrad@dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) Fri Feb 22 11:37:00 EST 2013
(XEN) Latest ChangeSet: Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
(XEN) Console output is synchronous.
(XEN) Bootloader: unknown
(XEN) Command line: cpuinfo conring_size=1048576 sync_console cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ec00 (usable)
(XEN)  000000000009ec00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 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)
(XEN)  00000000badc9000 - 00000000badd1000 (ACPI data)
(XEN)  00000000badd1000 - 00000000badf4000 (reserved)
(XEN)  00000000badf4000 - 00000000badf6000 (usable)
(XEN)  00000000badf6000 - 00000000bae06000 (reserved)
(XEN)  00000000bae06000 - 00000000bae14000 (ACPI NVS)
(XEN)  00000000bae14000 - 00000000bae3c000 (reserved)
(XEN)  00000000bae3c000 - 00000000bae7f000 (ACPI NVS)
(XEN)  00000000bae7f000 - 00000000bb000000 (usable)
(XEN)  00000000bb800000 - 00000000bfa00000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000023fe00000 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BADC9068, 0054 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN)  PROC        1 MSFT  3000001)
(XEN) ACPI: MCFG BADD0580, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: HPET BADD05C0, 0038 (r1 ALASKA    A M I  1072009 AMI.        4)
(XEN) ACPI: ASF! BADD05F8, 00A0 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) System RAM: 8104MB (8299140kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000023fe00000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fcde0
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - bae0bf80/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[bae0bf8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
(XEN) Processor #1 6:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
(XEN) Processor #3 6:10 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: Not using MMCONFIG.
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 3093.067 MHz processor.
(XEN) Initing memory sharing.
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 3072K
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
(XEN) CPU0: Thermal monitoring enabled (TM1)
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 1048576 KiB.
(XEN) VMX: Supported advanced features:
(isation
(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
(XEN) Booting processor 1/1 eip 7c000
(XEN) Initializing CPU#1
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) CPU: L1 I cache: 32K, L1 D
(XEN) Initializing CPU#2
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 3072K
(XEN) CPU2: Thermal monitoring enabled (TM1)
(XEN) CPU2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
(XEN) Booting processor 3/3 eip 7c000
(XEN) Initializing CPU#3
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CPU: L1 I cache: 32K, L1 D100 CPU @ 3.10GHz stepping 07
(XEN) Brought up 4 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x9e0000
(XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xa60f0
(XEN): paddr=0x1abc000 memsz=0x61b000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x20d7000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81abc1e0
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff820d7000
(XEN)     virt_entry       = 0xffffffff81abc1e0
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20d7000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (1661249 pages to be allocated)
(XEN)  Init. ramdisk: 000000022cbdc000->000000023fe00000
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff820d7000
(XEN)  Init. ramdisk: ffffffff820d7000->ffffffff952fb000
(XEN)  Phys-Mach map: ffffffff952fb000->ffffffff96060b28
(XEN)  Start info:    ffffffff96061000->ffffffff960614b4
(XEN)  Page tables:   ffffffff96062000->ffffffff96117000
(XEN)  Boot stack:    ffffffff96117000->ffffffff96118000
(XEN)  TOTAL:         ffffffff80000000->ffffffff96400000
(XEN)  ENTRY ADDRESS: ffffffff81abc1e0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff819e0000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81aa60f0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81aa7000 -> 0xffffffff81abbbc0
(XEN) elf_load_binary: phdr 3 at 0xffffffff81abc000 -> 0xffffffff81baf000
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) ***************************intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1... 
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 224kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0upstream-06471-g2ef14f4-dirty (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 11:36:48 EST 2013
[    0.000000] Command line: initcall_debug debug console=hvc0 loglevel=10 xen-pciback.hide=(01:00.0) earlyprintk=xen
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] 1-1 mapping on 9e->100
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 20000->20200
[    0.000000] Freeing 40000-40200 pfn range: 512 pages freed
[    0.000000] 1-1 mapping on 40000->40200
[    0.000000] Freeing bad80-badf4 pfn range: 116 pages freed
[    0.000000] 1-1 mapping on bad80->badf4
[    0.000000] Freeing badf6-bae7f pfn range: 137 pages freed
[    0.000000] 1-1 mapping on badf6->bae7f
[    0.000000] Freeing bb000-100000 pfn range: 282624 pages freed
[    0.000000] 1-1 mapping on bb000->100000
[    0.000000] Released 283999 pages of unused memory
[    0.000000] Set 283999 page(s) to 1-1 mapping
[    0.000000] Populating 1acb65-1f20c4 pfn range: 283999 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x000000000009ec00-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable
[    0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved
[    0.000000] Xen: [mem 0x0000000040200000-0x00000000bad7ffff] usable
[    0.000000] Xen: [mem 0x00000000bad80000-0x00000000badc8fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000badc9000-0x00000000badd0fff] ACPI data
[    0.000000] Xen: [mem 0x00000000badd1000-0x00000000badf3fff] reserved
[    0.000000] Xen: [mem 0x00000000badf4000-0x00000000badf5fff] usable
[    0.000000] Xen: [mem 0x00000000badf6000-0x00000000bae05fff] reserved
[    0.000000] Xen: [mem 0x00000000bae06000-0x00000000bae13fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bae14000-0x00000000bae3bfff] reserved
[    0.000000] Xen: [mem 0x00000000bae3c000-0x00000000bae7efff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000bae7f000-0x00000000baffffff] usable
[    0.000000] Xen: [mem 0x00000000bb800000-0x00000000bf9fffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000023fdfffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
[    0.000000] e820: lacanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
[    0.000000] reserving inaccessible SNB gfx pages
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
[    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
[    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
[    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
[    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
[    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
[    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
[    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
[    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
[    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
[    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
[    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
[    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
[    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
[    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
[    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k
(XEN) d0:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea000005b2d0:
(XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff8103feba>]
(XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
(XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
(XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
(XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
(XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
(XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a01d90:
(XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
(XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
(XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
(XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
(XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
(XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
(XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
(XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
(XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
(XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
(XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
(XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:27:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:27: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 1U8wOw-0005Md-In; Fri, 22 Feb 2013 17:27:14 +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 1U8wOv-0005MI-6l
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:27:13 +0000
Received: from [193.109.254.147:46134] by server-6.bemta-14.messagelabs.com id
	AC/28-12010-07AA7215; Fri, 22 Feb 2013 17:27:12 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361554005!8783044!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10797 invoked from network); 22 Feb 2013 17:26:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="asc'?scan'208";a="1796308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:26: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.297.1;
	Fri, 22 Feb 2013 17:26:44 +0000
Message-ID: <1361554003.16232.33.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 18:26:43 +0100
In-Reply-To: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3852352388587675179=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3852352388587675179==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-lTS40SGvF0pMKbeg+5DD"

--=-lTS40SGvF0pMKbeg+5DD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
>
> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>  {
>      s_time_t delta;
> +    uint64_t val;
>      unsigned int credits;
> =20
>      /* Assert svc is current */
> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>      if ( (delta =3D now - svc->start_time) <=3D 0 )
>          return;
> =20
> -    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLI=
SECS(1);
> +    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> +    svc->residual =3D do_div(val, MILLISECS(1));
> +    credits =3D val;
> +    ASSERT(credits =3D=3D val);

I may be missing something, but how can the assert ever be false, given
the assignment right before it?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-lTS40SGvF0pMKbeg+5DD
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)

iEYEABECAAYFAlEnqlMACgkQk4XaBE3IOsRQlACgihS4ewwtnKp8vgxjMmsBranb
g3QAnA7XsiBxiVqp2hoHEeJKcbheUYht
=Ar0Y
-----END PGP SIGNATURE-----

--=-lTS40SGvF0pMKbeg+5DD--


--===============3852352388587675179==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3852352388587675179==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 17:27:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:27: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 1U8wOw-0005Md-In; Fri, 22 Feb 2013 17:27:14 +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 1U8wOv-0005MI-6l
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:27:13 +0000
Received: from [193.109.254.147:46134] by server-6.bemta-14.messagelabs.com id
	AC/28-12010-07AA7215; Fri, 22 Feb 2013 17:27:12 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361554005!8783044!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRv
	bmVkOiBhYm91dC5tZS9kYXJpby5mYWdnaW9s\naSk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10797 invoked from network); 22 Feb 2013 17:26:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="asc'?scan'208";a="1796308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:26: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.297.1;
	Fri, 22 Feb 2013 17:26:44 +0000
Message-ID: <1361554003.16232.33.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 22 Feb 2013 18:26:43 +0100
In-Reply-To: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3852352388587675179=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3852352388587675179==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-lTS40SGvF0pMKbeg+5DD"

--=-lTS40SGvF0pMKbeg+5DD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
>
> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>  {
>      s_time_t delta;
> +    uint64_t val;
>      unsigned int credits;
> =20
>      /* Assert svc is current */
> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>      if ( (delta =3D now - svc->start_time) <=3D 0 )
>          return;
> =20
> -    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLI=
SECS(1);
> +    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> +    svc->residual =3D do_div(val, MILLISECS(1));
> +    credits =3D val;
> +    ASSERT(credits =3D=3D val);

I may be missing something, but how can the assert ever be false, given
the assignment right before it?

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-lTS40SGvF0pMKbeg+5DD
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)

iEYEABECAAYFAlEnqlMACgkQk4XaBE3IOsRQlACgihS4ewwtnKp8vgxjMmsBranb
g3QAnA7XsiBxiVqp2hoHEeJKcbheUYht
=Ar0Y
-----END PGP SIGNATURE-----

--=-lTS40SGvF0pMKbeg+5DD--


--===============3852352388587675179==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3852352388587675179==--


From xen-devel-bounces@lists.xen.org Fri Feb 22 17:29:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:29: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 1U8wQg-0005Ws-Ed; Fri, 22 Feb 2013 17:29:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8wQd-0005Wd-DA
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:28:59 +0000
Received: from [85.158.139.211:54298] by server-3.bemta-5.messagelabs.com id
	7E/B2-07037-9DAA7215; Fri, 22 Feb 2013 17:28:57 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361554137!14837332!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7179 invoked from network); 22 Feb 2013 17:28:57 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-206.messagelabs.com with SMTP;
	22 Feb 2013 17:28:57 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 05B5FC5618E;
	Fri, 22 Feb 2013 17:28:44 +0000 (GMT)
Date: Fri, 22 Feb 2013 17:28:42 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Message-ID: <330E687E05E24E508F95A610@nimrod.local>
In-Reply-To: <656C0D5981D3A8BFB9993B2E@nimrod.local>
References: <5B4525F296F6ABEB38B0E614@nimrod.local> 
	<50CEFDA602000078000B0B11@nat28.tlf.novell.com> 
	<3B1D0701EAEA6532CEA91EA0@Ximines.local> 
	<alpine.DEB.2.02.1301161302020.4978@kaball.uk.xensource.com> 
	<F1DF150F7B2469CFD587A2A4@Ximines.local> 
	<alpine.DEB.2.02.1301161620390.4978@kaball.uk.xensource.com> 
	<E57EC0AFE2B6901CB9A11068@Ximines.local> 
	<alpine.DEB.2.02.1301161718120.4978@kaball.uk.xensource.com> 
	<77822E2DDAEA8F94631B6A52@Ximines.local> 
	<1358781790.3279.224.camel@zakaz.uk.xensource.com> 
	<F7F59FF70A5F8648886565B5@Ximines.local> 
	<1358783420.3279.235.camel@zakaz.uk.xensource.com> 
	<F7775BEAD1475FBBDEB2B9C4@Ximines.local>
	<19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Konrad / Stefano,

Any update here?

I can't help but think a crashed dom0 and guaranteed domU corruption is
less bad than a theoretical data loss on a crash (not that we know
that theoretical possibility exists yet).

I'm currently using this trivial patch
 https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
96aebc21af15074f3bf64c5c6795ca05f16

Alex


--On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:

> Konrad / Stefano,
>
> Any movement / ideas on this one?
>
> Alex
>
> --On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
>
>> Konrad,
>>
>> --On 23 January 2013 16:29:20 +0000 Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>
>>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>>> index a402ac8..1c3a6f5 100644
>>>> --- a/hw/xen_disk.c
>>>> +++ b/hw/xen_disk.c
>>>> @@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
>>>>      }
>>>>
>>>>      /* read-only ? */
>>>> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
>>>> +    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
>>>> BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
>>>>          qflags |= BDRV_O_RDWR;
>>>>      } else {
>>>
>>> Before going for something like that I would like a confirmation from
>>> Konrad about blkfront behavior regarding barriers and
>>> BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
>>> corruptions.
>>
>> Any ideas?
>>
>>
>> A slightly prettier patch would look like the one pasted
>> below (not sent with git-sendemail so beware whitespace issues).
>>
>> --
>> Alex Bligh
>>
>> commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
>> Author: Alex Bligh <alex@alex.org.uk>
>> Date:   Thu Jan 24 09:41:34 2013 +0000
>>
>>     Disable use of O_DIRECT by default as it results in crashes.
>>
>>     See:
>>       http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
>>     for more details.
>>
>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>> index a402ac8..a618d8d 100644
>> --- a/hw/xen_disk.c
>> +++ b/hw/xen_disk.c
>> @@ -45,6 +45,8 @@ static int batch_maps   = 0;
>>
>>  static int max_requests = 32;
>>
>> +static int use_o_direct = 0;
>> +
>>  /* ------------------------------------------------------------- */
>>
>>  # define BLOCK_SIZE  512
>> @@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
>>      }
>>
>>      /* read-only ? */
>> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
>> +    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
>> BDRV_O_NATIVE_AIO;
>>      if (strcmp(blkdev->mode, "w") == 0) {
>>          qflags |= BDRV_O_RDWR;
>>      } else {
>>
>>
>>
>
>
>
> --
> Alex Bligh
>
>



-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:29:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:29: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 1U8wQg-0005Ws-Ed; Fri, 22 Feb 2013 17:29:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8wQd-0005Wd-DA
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:28:59 +0000
Received: from [85.158.139.211:54298] by server-3.bemta-5.messagelabs.com id
	7E/B2-07037-9DAA7215; Fri, 22 Feb 2013 17:28:57 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361554137!14837332!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7179 invoked from network); 22 Feb 2013 17:28:57 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-13.tower-206.messagelabs.com with SMTP;
	22 Feb 2013 17:28:57 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 05B5FC5618E;
	Fri, 22 Feb 2013 17:28:44 +0000 (GMT)
Date: Fri, 22 Feb 2013 17:28:42 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Message-ID: <330E687E05E24E508F95A610@nimrod.local>
In-Reply-To: <656C0D5981D3A8BFB9993B2E@nimrod.local>
References: <5B4525F296F6ABEB38B0E614@nimrod.local> 
	<50CEFDA602000078000B0B11@nat28.tlf.novell.com> 
	<3B1D0701EAEA6532CEA91EA0@Ximines.local> 
	<alpine.DEB.2.02.1301161302020.4978@kaball.uk.xensource.com> 
	<F1DF150F7B2469CFD587A2A4@Ximines.local> 
	<alpine.DEB.2.02.1301161620390.4978@kaball.uk.xensource.com> 
	<E57EC0AFE2B6901CB9A11068@Ximines.local> 
	<alpine.DEB.2.02.1301161718120.4978@kaball.uk.xensource.com> 
	<77822E2DDAEA8F94631B6A52@Ximines.local> 
	<1358781790.3279.224.camel@zakaz.uk.xensource.com> 
	<F7F59FF70A5F8648886565B5@Ximines.local> 
	<1358783420.3279.235.camel@zakaz.uk.xensource.com> 
	<F7775BEAD1475FBBDEB2B9C4@Ximines.local>
	<19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Konrad / Stefano,

Any update here?

I can't help but think a crashed dom0 and guaranteed domU corruption is
less bad than a theoretical data loss on a crash (not that we know
that theoretical possibility exists yet).

I'm currently using this trivial patch
 https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
96aebc21af15074f3bf64c5c6795ca05f16

Alex


--On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:

> Konrad / Stefano,
>
> Any movement / ideas on this one?
>
> Alex
>
> --On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
>
>> Konrad,
>>
>> --On 23 January 2013 16:29:20 +0000 Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>>
>>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>>> index a402ac8..1c3a6f5 100644
>>>> --- a/hw/xen_disk.c
>>>> +++ b/hw/xen_disk.c
>>>> @@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
>>>>      }
>>>>
>>>>      /* read-only ? */
>>>> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
>>>> +    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
>>>> BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
>>>>          qflags |= BDRV_O_RDWR;
>>>>      } else {
>>>
>>> Before going for something like that I would like a confirmation from
>>> Konrad about blkfront behavior regarding barriers and
>>> BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
>>> corruptions.
>>
>> Any ideas?
>>
>>
>> A slightly prettier patch would look like the one pasted
>> below (not sent with git-sendemail so beware whitespace issues).
>>
>> --
>> Alex Bligh
>>
>> commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
>> Author: Alex Bligh <alex@alex.org.uk>
>> Date:   Thu Jan 24 09:41:34 2013 +0000
>>
>>     Disable use of O_DIRECT by default as it results in crashes.
>>
>>     See:
>>       http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
>>     for more details.
>>
>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>> index a402ac8..a618d8d 100644
>> --- a/hw/xen_disk.c
>> +++ b/hw/xen_disk.c
>> @@ -45,6 +45,8 @@ static int batch_maps   = 0;
>>
>>  static int max_requests = 32;
>>
>> +static int use_o_direct = 0;
>> +
>>  /* ------------------------------------------------------------- */
>>
>>  # define BLOCK_SIZE  512
>> @@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
>>      }
>>
>>      /* read-only ? */
>> -    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
>> +    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
>> BDRV_O_NATIVE_AIO;
>>      if (strcmp(blkdev->mode, "w") == 0) {
>>          qflags |= BDRV_O_RDWR;
>>      } else {
>>
>>
>>
>
>
>
> --
> Alex Bligh
>
>



-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:39:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:39: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 1U8waO-00067x-VV; Fri, 22 Feb 2013 17:39:04 +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 1U8waN-00067s-Fw
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:39:03 +0000
Received: from [85.158.139.211:9542] by server-14.bemta-5.messagelabs.com id
	AE/E6-06967-63DA7215; Fri, 22 Feb 2013 17:39:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361554741!14838539!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11353 invoked from network); 22 Feb 2013 17:39:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:39:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1796862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:39: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.297.1;
	Fri, 22 Feb 2013 17:39:01 +0000
Message-ID: <1361554740.26546.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Fri, 22 Feb 2013 17:39:00 +0000
In-Reply-To: <73B7FEB65DB959FF75707D5A@nimrod.local>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 17:13 +0000, Alex Bligh wrote:
> The xen debian packaging currently produces a debian package of what
> 'make install' would produce. This includes a fair amount of development
> only stuff, puts the hypervisor in /boot etc.

Xen make deb target is intended as a developer convenience package
(essentially to allow a cleaner uninstall) and is not intended as a full
user focused package.

> This packaging is not used by Ubuntu (I don't know about debian).

It's not expected to be, both of these have good proper packages of Xen.

Ian.

> 
> I have a hack:
>  
> https://github.com/abligh/xen-4.2-live-migrate/commit/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74
> 
> that produces a 'minideb'. The idea was to put in the minimum of userspace
> code that would be required to run xen4.2 and xl. This excludes the
> hypervisor which if I were less lazy would be in a separate package,
> as you don't need that on disk when you are network booting.
> 
> Is there any interest in taking this into mainline if I clear it up?
> It's just another make target (make minideb) so is pretty unintrusive.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:39:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:39: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 1U8waO-00067x-VV; Fri, 22 Feb 2013 17:39:04 +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 1U8waN-00067s-Fw
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:39:03 +0000
Received: from [85.158.139.211:9542] by server-14.bemta-5.messagelabs.com id
	AE/E6-06967-63DA7215; Fri, 22 Feb 2013 17:39:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361554741!14838539!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11353 invoked from network); 22 Feb 2013 17:39:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:39:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1796862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:39: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.297.1;
	Fri, 22 Feb 2013 17:39:01 +0000
Message-ID: <1361554740.26546.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Fri, 22 Feb 2013 17:39:00 +0000
In-Reply-To: <73B7FEB65DB959FF75707D5A@nimrod.local>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 17:13 +0000, Alex Bligh wrote:
> The xen debian packaging currently produces a debian package of what
> 'make install' would produce. This includes a fair amount of development
> only stuff, puts the hypervisor in /boot etc.

Xen make deb target is intended as a developer convenience package
(essentially to allow a cleaner uninstall) and is not intended as a full
user focused package.

> This packaging is not used by Ubuntu (I don't know about debian).

It's not expected to be, both of these have good proper packages of Xen.

Ian.

> 
> I have a hack:
>  
> https://github.com/abligh/xen-4.2-live-migrate/commit/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74
> 
> that produces a 'minideb'. The idea was to put in the minimum of userspace
> code that would be required to run xen4.2 and xl. This excludes the
> hypervisor which if I were less lazy would be in a separate package,
> as you don't need that on disk when you are network booting.
> 
> Is there any interest in taking this into mainline if I clear it up?
> It's just another make target (make minideb) so is pretty unintrusive.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:39:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8waT-00068T-4h; Fri, 22 Feb 2013 17:39:09 +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 1U8wYN-00067L-KX
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:37:00 +0000
Received: from [85.158.139.83:7462] by server-12.bemta-5.messagelabs.com id
	E4/44-20195-ABCA7215; Fri, 22 Feb 2013 17:36:58 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361554615!27835540!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20291 invoked from network); 22 Feb 2013 17:36:57 -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; 22 Feb 2013 17:36:57 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHXdwS012535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:33:39 -0800
Message-ID: <5127ABEE.8080303@zytor.com>
Date: Fri, 22 Feb 2013 09:33:34 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Dave Hansen <dave@linux.vnet.ibm.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127AB34.8090406@linux.vnet.ibm.com>
In-Reply-To: <5127AB34.8090406@linux.vnet.ibm.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:39:07 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	"H. J. Lu" <hjl.tools@gmail.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, linux-pm@vger.kernel.org,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 09:30 AM, Dave Hansen wrote:
>
> Do you have CONFIG_DEBUG_VIRTUAL on?
>
> You're probably hitting the new BUG_ON() in __phys_addr().  It's
> intended to detect places where someone is doing a __pa()/__phys_addr()
> on an address that's outside the kernel's identity mapping.
>
> There are a lot of __pa() calls around there, but from the looks of it,
> it's this code:
>
> static pgd_t *xen_get_user_pgd(pgd_t *pgd)
> {
> ...
>          if (offset < pgd_index(USER_LIMIT)) {
>                  struct page *page = virt_to_page(pgd_page);
>
> I'm a bit fuzzy on exactly what the code is trying to do here.  It could
> mean either that the identity mapping isn't set up enough yet, or that
> __pa() is getting called on a bogus address.
>
> I'm especially fuzzy on why we'd be calling anything that's looking at
> userspace pagetables (xen_get_user_pgd() ??) this early in boot.
>

Ah yes, of course.

This is unrelated to the early page table setups, which is why it didn't 
trip in Konrad's earlier testing.

This debugging bits has already found real bugs in the kernel, and this 
might be another.

	-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 Fri Feb 22 17:39:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8waT-00068T-4h; Fri, 22 Feb 2013 17:39:09 +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 1U8wYN-00067L-KX
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:37:00 +0000
Received: from [85.158.139.83:7462] by server-12.bemta-5.messagelabs.com id
	E4/44-20195-ABCA7215; Fri, 22 Feb 2013 17:36:58 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361554615!27835540!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20291 invoked from network); 22 Feb 2013 17:36:57 -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; 22 Feb 2013 17:36:57 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHXdwS012535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:33:39 -0800
Message-ID: <5127ABEE.8080303@zytor.com>
Date: Fri, 22 Feb 2013 09:33:34 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Dave Hansen <dave@linux.vnet.ibm.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127AB34.8090406@linux.vnet.ibm.com>
In-Reply-To: <5127AB34.8090406@linux.vnet.ibm.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:39:07 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	"H. J. Lu" <hjl.tools@gmail.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, linux-pm@vger.kernel.org,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 09:30 AM, Dave Hansen wrote:
>
> Do you have CONFIG_DEBUG_VIRTUAL on?
>
> You're probably hitting the new BUG_ON() in __phys_addr().  It's
> intended to detect places where someone is doing a __pa()/__phys_addr()
> on an address that's outside the kernel's identity mapping.
>
> There are a lot of __pa() calls around there, but from the looks of it,
> it's this code:
>
> static pgd_t *xen_get_user_pgd(pgd_t *pgd)
> {
> ...
>          if (offset < pgd_index(USER_LIMIT)) {
>                  struct page *page = virt_to_page(pgd_page);
>
> I'm a bit fuzzy on exactly what the code is trying to do here.  It could
> mean either that the identity mapping isn't set up enough yet, or that
> __pa() is getting called on a bogus address.
>
> I'm especially fuzzy on why we'd be calling anything that's looking at
> userspace pagetables (xen_get_user_pgd() ??) this early in boot.
>

Ah yes, of course.

This is unrelated to the early page table setups, which is why it didn't 
trip in Konrad's earlier testing.

This debugging bits has already found real bugs in the kernel, and this 
might be another.

	-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 Fri Feb 22 17:39:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8waS-00068D-Bu; Fri, 22 Feb 2013 17:39:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8wWi-00066c-II
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:35:16 +0000
Received: from [85.158.143.99:28433] by server-3.bemta-4.messagelabs.com id
	AC/53-02186-35CA7215; Fri, 22 Feb 2013 17:35:15 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361554508!27848546!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21365 invoked from network); 22 Feb 2013 17:35:10 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:35:10 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHUDNJ011902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:30:13 -0800
Message-ID: <5127AB1F.1030407@zytor.com>
Date: Fri, 22 Feb 2013 09:30:07 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
In-Reply-To: <20130222172403.GA17056@phenom.dumpdata.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:39:07 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>,
	Thomas Gleixner <tglx@linutronix.de>, yinghai@kernel.org,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 09:24 AM, Konrad Rzeszutek Wilk wrote:
>
> Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
> kernel with 8GB):
>

Configuration, please, especially: is early_printk compiled in?  Also, 
since this is Xen-related we really need your help on this.  A lot of 
this is not going to be meaningful to non-Xen people.

	-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 Fri Feb 22 17:39:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8waS-00068D-Bu; Fri, 22 Feb 2013 17:39:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8wWi-00066c-II
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:35:16 +0000
Received: from [85.158.143.99:28433] by server-3.bemta-4.messagelabs.com id
	AC/53-02186-35CA7215; Fri, 22 Feb 2013 17:35:15 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361554508!27848546!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21365 invoked from network); 22 Feb 2013 17:35:10 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:35:10 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHUDNJ011902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:30:13 -0800
Message-ID: <5127AB1F.1030407@zytor.com>
Date: Fri, 22 Feb 2013 09:30:07 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
In-Reply-To: <20130222172403.GA17056@phenom.dumpdata.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:39:07 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>,
	Thomas Gleixner <tglx@linutronix.de>, yinghai@kernel.org,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 09:24 AM, Konrad Rzeszutek Wilk wrote:
>
> Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
> kernel with 8GB):
>

Configuration, please, especially: is early_printk compiled in?  Also, 
since this is Xen-related we really need your help on this.  A lot of 
this is not going to be meaningful to non-Xen people.

	-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 Fri Feb 22 17:39:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8waS-00068K-Ni; Fri, 22 Feb 2013 17:39:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8wXK-00066w-Vv
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:35:55 +0000
Received: from [85.158.143.99:31040] by server-2.bemta-4.messagelabs.com id
	9C/DD-12656-A7CA7215; Fri, 22 Feb 2013 17:35:54 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361554551!21323475!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25591 invoked from network); 22 Feb 2013 17:35:52 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:35:52 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHVWRV012019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:31:32 -0800
Message-ID: <5127AB6F.3060806@zytor.com>
Date: Fri, 22 Feb 2013 09:31:27 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<CA+55aFy=tW2X4O-qKLh_YQjSFX7aBaBme4uy8kxawn1koKdt-g@mail.gmail.com>
In-Reply-To: <CA+55aFy=tW2X4O-qKLh_YQjSFX7aBaBme4uy8kxawn1koKdt-g@mail.gmail.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:39:07 +0000
Cc: linux-mips <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	Avi Kivity <avi@redhat.com>, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 08:22 AM, Linus Torvalds wrote:
>
> Ugh. So I've tried to walk through this, and it's painful. If this
> results in problems, we're going to be *so* screwed. Is it bisectable?
>

I can't tell you for sure that it is bisectable at every point.  There 
are definite bisection points in there, though, as this is several 
pieces of work from two kernel cycles that were independently tested.

> I also don't understand how "early_idt_handler" could *possibly* work.
> In particular, it seems to rely on the trap number being set up in the
> stack frame:
>
>          cmpl $14,72(%rsp)       # Page fault?
>
> but that's not even *true*. Why? Because we export both the
> early_idt_handlers[] array (that sets up the trap number and makes the
> stack frame be reliable) and the single early_idt_handler function
> (that relies on the trap number and the reliable stack frame), AND
> AFAIK WE USE THE LATTER!
>
> See x86_64_start_kernel():
>
>          for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
> #ifdef CONFIG_EARLY_PRINTK
>                  set_intr_gate(i, &early_idt_handlers[i]);
> #else
>                  set_intr_gate(i, early_idt_handler);
> #endif
>          }
>
> so unless you have CONFIG_EARLY_PRINTK, the interrupt gate will point
> to that raw early_idt_handler function that doesn't *work* on its own,
> afaik.
>

This is a (pre-existing!) bug that absolutely needs to be fixed, which 
ought to break other things too (early use of *msr_safe for example, or 
anything else that relies on an early exception entry, which there 
aren't a lot of so far).  The fix is simple and obvious.
But you're right... what the heck is going on here?

My own testing would probably not have caught this, as I consider 
EARLY_PRINTK a must have, but Ingo's test machines definitely would have.

> Btw, it's not just the page fault index testing that is wrong. The whole
>
>          cmpl $__KERNEL_CS,96(%rsp)
>          jne 11f
>
> also relies on the stack frame being set up the same way for all
> exceptions - which again is only true if we ran through the
> early_idt_handlers[] prologue that added the extra stack entry.
>
> How does this even work for me? I don't have EARLY_PRINTK enabled.
>
> What am I missing?

I just ran a simulation without EARLY_PRINTK, presumably based on the 
memory layout, we can apparently go through the entire bootup sequence 
without actually ever taking an early trap.  It is a bug, though, and it 
is a bug even without this patchset.  I will submit a fix.  However, the 
Xen "we tested this, this worked, now it doesn't" worries me a lot.

	-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 Fri Feb 22 17:39:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8waS-00068K-Ni; Fri, 22 Feb 2013 17:39:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8wXK-00066w-Vv
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:35:55 +0000
Received: from [85.158.143.99:31040] by server-2.bemta-4.messagelabs.com id
	9C/DD-12656-A7CA7215; Fri, 22 Feb 2013 17:35:54 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361554551!21323475!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25591 invoked from network); 22 Feb 2013 17:35:52 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:35:52 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MHVWRV012019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 09:31:32 -0800
Message-ID: <5127AB6F.3060806@zytor.com>
Date: Fri, 22 Feb 2013 09:31:27 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<CA+55aFy=tW2X4O-qKLh_YQjSFX7aBaBme4uy8kxawn1koKdt-g@mail.gmail.com>
In-Reply-To: <CA+55aFy=tW2X4O-qKLh_YQjSFX7aBaBme4uy8kxawn1koKdt-g@mail.gmail.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:39:07 +0000
Cc: linux-mips <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	Avi Kivity <avi@redhat.com>, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/22/2013 08:22 AM, Linus Torvalds wrote:
>
> Ugh. So I've tried to walk through this, and it's painful. If this
> results in problems, we're going to be *so* screwed. Is it bisectable?
>

I can't tell you for sure that it is bisectable at every point.  There 
are definite bisection points in there, though, as this is several 
pieces of work from two kernel cycles that were independently tested.

> I also don't understand how "early_idt_handler" could *possibly* work.
> In particular, it seems to rely on the trap number being set up in the
> stack frame:
>
>          cmpl $14,72(%rsp)       # Page fault?
>
> but that's not even *true*. Why? Because we export both the
> early_idt_handlers[] array (that sets up the trap number and makes the
> stack frame be reliable) and the single early_idt_handler function
> (that relies on the trap number and the reliable stack frame), AND
> AFAIK WE USE THE LATTER!
>
> See x86_64_start_kernel():
>
>          for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
> #ifdef CONFIG_EARLY_PRINTK
>                  set_intr_gate(i, &early_idt_handlers[i]);
> #else
>                  set_intr_gate(i, early_idt_handler);
> #endif
>          }
>
> so unless you have CONFIG_EARLY_PRINTK, the interrupt gate will point
> to that raw early_idt_handler function that doesn't *work* on its own,
> afaik.
>

This is a (pre-existing!) bug that absolutely needs to be fixed, which 
ought to break other things too (early use of *msr_safe for example, or 
anything else that relies on an early exception entry, which there 
aren't a lot of so far).  The fix is simple and obvious.
But you're right... what the heck is going on here?

My own testing would probably not have caught this, as I consider 
EARLY_PRINTK a must have, but Ingo's test machines definitely would have.

> Btw, it's not just the page fault index testing that is wrong. The whole
>
>          cmpl $__KERNEL_CS,96(%rsp)
>          jne 11f
>
> also relies on the stack frame being set up the same way for all
> exceptions - which again is only true if we ran through the
> early_idt_handlers[] prologue that added the extra stack entry.
>
> How does this even work for me? I don't have EARLY_PRINTK enabled.
>
> What am I missing?

I just ran a simulation without EARLY_PRINTK, presumably based on the 
memory layout, we can apparently go through the entire bootup sequence 
without actually ever taking an early trap.  It is a bug, though, and it 
is a bug even without this patchset.  I will submit a fix.  However, the 
Xen "we tested this, this worked, now it doesn't" worries me a lot.

	-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 Fri Feb 22 17:39:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:39: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 1U8wal-0006D2-Oe; Fri, 22 Feb 2013 17:39: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 1U8wak-0006Cc-KF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:39:26 +0000
Received: from [85.158.143.99:46157] by server-1.bemta-4.messagelabs.com id
	4C/00-06203-D4DA7215; Fri, 22 Feb 2013 17:39:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361554763!21771205!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22081 invoked from network); 22 Feb 2013 17:39:25 -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;
	22 Feb 2013 17:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8626227"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 17:39:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 12:39:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8wag-00063V-TS;
	Fri, 22 Feb 2013 17:39:22 +0000
Date: Fri, 22 Feb 2013 17:39:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20775.42788.510270.735773@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302221738560.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
	<4CECB0F28D4441D2BD4AC7E3@nimrod.local>
	<20775.42788.510270.735773@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Ian Jackson wrote:
> Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> > Ian,
> > 
> > --On 22 February 2013 16:50:25 +0000 Ian Jackson 
> > <Ian.Jackson@eu.citrix.com> wrote:
> > 
> > > Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling
> > > live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> > >> Thanks. I take it the libxl patches can now go in.
> > >
> > > This was done on Tuesday.  They haven't reached 4.2-stable yet because
> > > of unrelated difficulties with the 4.2 tree and the push gate, but
> > > they're in 4.2-staging.
> > 
> > Thanks. Would I expect to see a commit in xen's -staging that references the
> > change in qemu commit ID or does that only happen once things have got
> > to -stable?
> 
> I was referring to the libxl changes.  The changes to
> qemu-xen-upstream's tag in Config.mk don't seem to have been done
> yet.  Stefano, do you have a process for updating that ?

No, I haven't

> Shall I do
> it this time ?

Yes, please

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:39:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:39: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 1U8wal-0006D2-Oe; Fri, 22 Feb 2013 17:39: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 1U8wak-0006Cc-KF
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:39:26 +0000
Received: from [85.158.143.99:46157] by server-1.bemta-4.messagelabs.com id
	4C/00-06203-D4DA7215; Fri, 22 Feb 2013 17:39:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361554763!21771205!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22081 invoked from network); 22 Feb 2013 17:39:25 -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;
	22 Feb 2013 17:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8626227"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 17:39:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 12:39:23 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8wag-00063V-TS;
	Fri, 22 Feb 2013 17:39:22 +0000
Date: Fri, 22 Feb 2013 17:39:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20775.42788.510270.735773@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302221738560.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
	<4CECB0F28D4441D2BD4AC7E3@nimrod.local>
	<20775.42788.510270.735773@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Ian Jackson wrote:
> Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> > Ian,
> > 
> > --On 22 February 2013 16:50:25 +0000 Ian Jackson 
> > <Ian.Jackson@eu.citrix.com> wrote:
> > 
> > > Alex Bligh writes ("Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling
> > > live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> > >> Thanks. I take it the libxl patches can now go in.
> > >
> > > This was done on Tuesday.  They haven't reached 4.2-stable yet because
> > > of unrelated difficulties with the 4.2 tree and the push gate, but
> > > they're in 4.2-staging.
> > 
> > Thanks. Would I expect to see a commit in xen's -staging that references the
> > change in qemu commit ID or does that only happen once things have got
> > to -stable?
> 
> I was referring to the libxl changes.  The changes to
> qemu-xen-upstream's tag in Config.mk don't seem to have been done
> yet.  Stefano, do you have a process for updating that ?

No, I haven't

> Shall I do
> it this time ?

Yes, please

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:40:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:40: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 1U8wbQ-0006O6-C6; Fri, 22 Feb 2013 17:40:08 +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 1U8wax-0006G2-V5
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:39:40 +0000
Received: from [85.158.137.99:21964] by server-12.bemta-3.messagelabs.com id
	3B/31-05889-B5DA7215; Fri, 22 Feb 2013 17:39:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361554776!17657596!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTMyNTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5614 invoked from network); 22 Feb 2013 17:39:38 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:39:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHcEIr014128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:38:15 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
	r1MHcCoQ001862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:38:12 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
	r1MHcAQ8005390; Fri, 22 Feb 2013 11:38:10 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:38:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B5AA41C3935; Fri, 22 Feb 2013 12:38:05 -0500 (EST)
Date: Fri, 22 Feb 2013 12:38:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130222173805.GC7768@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5127A719.3060702@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:40:06 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
> On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
> >
> >What is bizzare is that I do recall testing this (and Stefano also did it).
> >So I am not sure what has altered.
> >
> 
> Yes, there was a very specific reason why I wanted you guys to test it...

Exactly. And I re-ran the same test, but with a new kernel. This is what
git reflog tells me:

473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
[konrad@build linux]$ git show 08f321e
commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Nov 8 00:00:19 2012 -0800

    mm: Kill NO_BOOTMEM version free_all_bootmem_node()

And I recall Stefano later on testing (I was in a conference and did not have
the opportunity to test it). Not sure what he ran with.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:40:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:40: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 1U8wbQ-0006O6-C6; Fri, 22 Feb 2013 17:40:08 +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 1U8wax-0006G2-V5
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:39:40 +0000
Received: from [85.158.137.99:21964] by server-12.bemta-3.messagelabs.com id
	3B/31-05889-B5DA7215; Fri, 22 Feb 2013 17:39:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361554776!17657596!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTMyNTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5614 invoked from network); 22 Feb 2013 17:39:38 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:39:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHcEIr014128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:38:15 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
	r1MHcCoQ001862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:38:12 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
	r1MHcAQ8005390; Fri, 22 Feb 2013 11:38:10 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:38:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B5AA41C3935; Fri, 22 Feb 2013 12:38:05 -0500 (EST)
Date: Fri, 22 Feb 2013 12:38:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130222173805.GC7768@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5127A719.3060702@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 17:40:06 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	sparclinux@vger.kernel.org, Christoph Lameter <cl@linux.com>,
	Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
> On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
> >
> >What is bizzare is that I do recall testing this (and Stefano also did it).
> >So I am not sure what has altered.
> >
> 
> Yes, there was a very specific reason why I wanted you guys to test it...

Exactly. And I re-ran the same test, but with a new kernel. This is what
git reflog tells me:

473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
[konrad@build linux]$ git show 08f321e
commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Nov 8 00:00:19 2012 -0800

    mm: Kill NO_BOOTMEM version free_all_bootmem_node()

And I recall Stefano later on testing (I was in a conference and did not have
the opportunity to test it). Not sure what he ran with.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:40:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wbX-0006Qo-Qv; Fri, 22 Feb 2013 17:40:15 +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 1U8wbW-0006Q1-9O
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:40:14 +0000
Received: from [85.158.139.211:34757] by server-4.bemta-5.messagelabs.com id
	3F/B2-29496-C7DA7215; Fri, 22 Feb 2013 17:40:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361554811!18762832!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12288 invoked from network); 22 Feb 2013 17:40:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:40:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8wbS-000Boe-GR; Fri, 22 Feb 2013 17:40:10 +0000
Date: Fri, 22 Feb 2013 17:40:10 +0000
From: Tim Deegan <tim@xen.org>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130222174010.GC40494@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <73B7FEB65DB959FF75707D5A@nimrod.local>
User-Agent: Mutt/1.4.2.1i
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
> The xen debian packaging currently produces a debian package of what
> 'make install' would produce. This includes a fair amount of development
> only stuff, puts the hypervisor in /boot etc.
> 
> This packaging is not used by Ubuntu (I don't know about debian).

Debian also has its own packaging of Xen.

The 'make deb' target is explicitly not an attempt to package Xen in a
way that's suitable for deployment -- it's just a way for developers to
to install a build onto a testbox and cleanly uninstall it later.

Your minideb seems much more like a 'proper' package to me (with init
files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
packaging for Xen doesn't do what you need you should get involved in
Debian/Ubuntu to make it so rather than duplicating effort here.

That said, tools and packaging aren't really my area and the tools
maintainers may disagree.  I'm just commenting as the person responsible
for the original make deb target.

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 Feb 22 17:40:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wbX-0006Qo-Qv; Fri, 22 Feb 2013 17:40:15 +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 1U8wbW-0006Q1-9O
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:40:14 +0000
Received: from [85.158.139.211:34757] by server-4.bemta-5.messagelabs.com id
	3F/B2-29496-C7DA7215; Fri, 22 Feb 2013 17:40:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361554811!18762832!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12288 invoked from network); 22 Feb 2013 17:40:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 17:40:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U8wbS-000Boe-GR; Fri, 22 Feb 2013 17:40:10 +0000
Date: Fri, 22 Feb 2013 17:40:10 +0000
From: Tim Deegan <tim@xen.org>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130222174010.GC40494@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <73B7FEB65DB959FF75707D5A@nimrod.local>
User-Agent: Mutt/1.4.2.1i
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
> The xen debian packaging currently produces a debian package of what
> 'make install' would produce. This includes a fair amount of development
> only stuff, puts the hypervisor in /boot etc.
> 
> This packaging is not used by Ubuntu (I don't know about debian).

Debian also has its own packaging of Xen.

The 'make deb' target is explicitly not an attempt to package Xen in a
way that's suitable for deployment -- it's just a way for developers to
to install a build onto a testbox and cleanly uninstall it later.

Your minideb seems much more like a 'proper' package to me (with init
files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
packaging for Xen doesn't do what you need you should get involved in
Debian/Ubuntu to make it so rather than duplicating effort here.

That said, tools and packaging aren't really my area and the tools
maintainers may disagree.  I'm just commenting as the person responsible
for the original make deb target.

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 Feb 22 17:42:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:42: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 1U8wd8-00076R-HG; Fri, 22 Feb 2013 17:41:54 +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 1U8wd7-00075x-0u
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:41:53 +0000
Received: from [85.158.137.99:33390] by server-16.bemta-3.messagelabs.com id
	A8/98-02727-0EDA7215; Fri, 22 Feb 2013 17:41:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361554909!17533341!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27762 invoked from network); 22 Feb 2013 17:41:50 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:41:50 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHfWkZ020652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:41:32 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
	r1MHfVmR019793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:41:31 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1MHfV8Y003749; Fri, 22 Feb 2013 11:41:31 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:41:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B69F51C3935; Fri, 22 Feb 2013 12:41:29 -0500 (EST)
Date: Fri, 22 Feb 2013 12:41:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130222174129.GD7768@phenom.dumpdata.com>
References: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
	<330E687E05E24E508F95A610@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <330E687E05E24E508F95A610@nimrod.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Xen Devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 05:28:42PM +0000, Alex Bligh wrote:
> Konrad / Stefano,
> 
> Any update here?

Sorry, been so busy with bugs that this keeps on getting deferred.
> 
> I can't help but think a crashed dom0 and guaranteed domU corruption is
> less bad than a theoretical data loss on a crash (not that we know
> that theoretical possibility exists yet).

So from a perspective of blkif protocol, as long as the sync requests
is properly being sent - then we are fine. I recall Stefano (or mayber Roger)
finding some oddity in the xen_disk were the fsync wasn't sent.

You should be able to test this rather easy by (in your guest)
mounting an ext3 or ext4 with barrier support and then looking at
the blktrace/blkparse to make sure that the sync commands are indeed hitting
the platter.

Thought there is probably a nice framework to do all of this automatically.
Perhaps fio does that already..

> 
> I'm currently using this trivial patch
> https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
> 96aebc21af15074f3bf64c5c6795ca05f16
> 
> Alex
> 
> 
> --On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> 
> >Konrad / Stefano,
> >
> >Any movement / ideas on this one?
> >
> >Alex
> >
> >--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> >
> >>Konrad,
> >>
> >>--On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> >><stefano.stabellini@eu.citrix.com> wrote:
> >>
> >>>>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >>>>index a402ac8..1c3a6f5 100644
> >>>>--- a/hw/xen_disk.c
> >>>>+++ b/hw/xen_disk.c
> >>>>@@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
> >>>>     }
> >>>>
> >>>>     /* read-only ? */
> >>>>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> >>>>+    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
> >>>>BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
> >>>>         qflags |= BDRV_O_RDWR;
> >>>>     } else {
> >>>
> >>>Before going for something like that I would like a confirmation from
> >>>Konrad about blkfront behavior regarding barriers and
> >>>BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
> >>>corruptions.
> >>
> >>Any ideas?
> >>
> >>
> >>A slightly prettier patch would look like the one pasted
> >>below (not sent with git-sendemail so beware whitespace issues).
> >>
> >>--
> >>Alex Bligh
> >>
> >>commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> >>Author: Alex Bligh <alex@alex.org.uk>
> >>Date:   Thu Jan 24 09:41:34 2013 +0000
> >>
> >>    Disable use of O_DIRECT by default as it results in crashes.
> >>
> >>    See:
> >>      http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
> >>    for more details.
> >>
> >>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >>index a402ac8..a618d8d 100644
> >>--- a/hw/xen_disk.c
> >>+++ b/hw/xen_disk.c
> >>@@ -45,6 +45,8 @@ static int batch_maps   = 0;
> >>
> >> static int max_requests = 32;
> >>
> >>+static int use_o_direct = 0;
> >>+
> >> /* ------------------------------------------------------------- */
> >>
> >> # define BLOCK_SIZE  512
> >>@@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
> >>     }
> >>
> >>     /* read-only ? */
> >>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> >>+    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> >>BDRV_O_NATIVE_AIO;
> >>     if (strcmp(blkdev->mode, "w") == 0) {
> >>         qflags |= BDRV_O_RDWR;
> >>     } else {
> >>
> >>
> >>
> >
> >
> >
> >--
> >Alex Bligh
> >
> >
> 
> 
> 
> -- 
> Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:42:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:42: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 1U8wd8-00076R-HG; Fri, 22 Feb 2013 17:41:54 +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 1U8wd7-00075x-0u
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:41:53 +0000
Received: from [85.158.137.99:33390] by server-16.bemta-3.messagelabs.com id
	A8/98-02727-0EDA7215; Fri, 22 Feb 2013 17:41:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361554909!17533341!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27762 invoked from network); 22 Feb 2013 17:41:50 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:41:50 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHfWkZ020652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:41:32 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
	r1MHfVmR019793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:41:31 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1MHfV8Y003749; Fri, 22 Feb 2013 11:41:31 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:41:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B69F51C3935; Fri, 22 Feb 2013 12:41:29 -0500 (EST)
Date: Fri, 22 Feb 2013 12:41:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20130222174129.GD7768@phenom.dumpdata.com>
References: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
	<330E687E05E24E508F95A610@nimrod.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <330E687E05E24E508F95A610@nimrod.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Xen Devel <xen-devel@lists.xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 05:28:42PM +0000, Alex Bligh wrote:
> Konrad / Stefano,
> 
> Any update here?

Sorry, been so busy with bugs that this keeps on getting deferred.
> 
> I can't help but think a crashed dom0 and guaranteed domU corruption is
> less bad than a theoretical data loss on a crash (not that we know
> that theoretical possibility exists yet).

So from a perspective of blkif protocol, as long as the sync requests
is properly being sent - then we are fine. I recall Stefano (or mayber Roger)
finding some oddity in the xen_disk were the fsync wasn't sent.

You should be able to test this rather easy by (in your guest)
mounting an ext3 or ext4 with barrier support and then looking at
the blktrace/blkparse to make sure that the sync commands are indeed hitting
the platter.

Thought there is probably a nice framework to do all of this automatically.
Perhaps fio does that already..

> 
> I'm currently using this trivial patch
> https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
> 96aebc21af15074f3bf64c5c6795ca05f16
> 
> Alex
> 
> 
> --On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> 
> >Konrad / Stefano,
> >
> >Any movement / ideas on this one?
> >
> >Alex
> >
> >--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> >
> >>Konrad,
> >>
> >>--On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> >><stefano.stabellini@eu.citrix.com> wrote:
> >>
> >>>>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >>>>index a402ac8..1c3a6f5 100644
> >>>>--- a/hw/xen_disk.c
> >>>>+++ b/hw/xen_disk.c
> >>>>@@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
> >>>>     }
> >>>>
> >>>>     /* read-only ? */
> >>>>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> >>>>+    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
> >>>>BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
> >>>>         qflags |= BDRV_O_RDWR;
> >>>>     } else {
> >>>
> >>>Before going for something like that I would like a confirmation from
> >>>Konrad about blkfront behavior regarding barriers and
> >>>BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
> >>>corruptions.
> >>
> >>Any ideas?
> >>
> >>
> >>A slightly prettier patch would look like the one pasted
> >>below (not sent with git-sendemail so beware whitespace issues).
> >>
> >>--
> >>Alex Bligh
> >>
> >>commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> >>Author: Alex Bligh <alex@alex.org.uk>
> >>Date:   Thu Jan 24 09:41:34 2013 +0000
> >>
> >>    Disable use of O_DIRECT by default as it results in crashes.
> >>
> >>    See:
> >>      http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
> >>    for more details.
> >>
> >>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >>index a402ac8..a618d8d 100644
> >>--- a/hw/xen_disk.c
> >>+++ b/hw/xen_disk.c
> >>@@ -45,6 +45,8 @@ static int batch_maps   = 0;
> >>
> >> static int max_requests = 32;
> >>
> >>+static int use_o_direct = 0;
> >>+
> >> /* ------------------------------------------------------------- */
> >>
> >> # define BLOCK_SIZE  512
> >>@@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
> >>     }
> >>
> >>     /* read-only ? */
> >>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> >>+    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> >>BDRV_O_NATIVE_AIO;
> >>     if (strcmp(blkdev->mode, "w") == 0) {
> >>         qflags |= BDRV_O_RDWR;
> >>     } else {
> >>
> >>
> >>
> >
> >
> >
> >--
> >Alex Bligh
> >
> >
> 
> 
> 
> -- 
> Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:45:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wgW-0007XM-5u; Fri, 22 Feb 2013 17:45:24 +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 1U8wgU-0007XG-PV
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:45:23 +0000
Received: from [85.158.137.99:51025] by server-5.bemta-3.messagelabs.com id
	8E/43-04457-DAEA7215; Fri, 22 Feb 2013 17:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361555115!17533749!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4461 invoked from network); 22 Feb 2013 17:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:45: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.297.1;
	Fri, 22 Feb 2013 17:45:15 +0000
Message-ID: <1361555113.26546.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 22 Feb 2013 17:45:13 +0000
In-Reply-To: <20130222174010.GC40494@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 17:40 +0000, Tim Deegan wrote:
> At 17:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
> > The xen debian packaging currently produces a debian package of what
> > 'make install' would produce. This includes a fair amount of development
> > only stuff, puts the hypervisor in /boot etc.
> > 
> > This packaging is not used by Ubuntu (I don't know about debian).
> 
> Debian also has its own packaging of Xen.
> 
> The 'make deb' target is explicitly not an attempt to package Xen in a
> way that's suitable for deployment -- it's just a way for developers to
> to install a build onto a testbox and cleanly uninstall it later.
> 
> Your minideb seems much more like a 'proper' package to me (with init
> files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
> packaging for Xen doesn't do what you need you should get involved in
> Debian/Ubuntu to make it so rather than duplicating effort here.
> 
> That said, tools and packaging aren't really my area and the tools
> maintainers may disagree.

FWIW I agree.

> I'm just commenting as the person responsible for the original make deb target.
> 
> 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 Fri Feb 22 17:45:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wgW-0007XM-5u; Fri, 22 Feb 2013 17:45:24 +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 1U8wgU-0007XG-PV
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:45:23 +0000
Received: from [85.158.137.99:51025] by server-5.bemta-3.messagelabs.com id
	8E/43-04457-DAEA7215; Fri, 22 Feb 2013 17:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361555115!17533749!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4461 invoked from network); 22 Feb 2013 17:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:45: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.297.1;
	Fri, 22 Feb 2013 17:45:15 +0000
Message-ID: <1361555113.26546.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 22 Feb 2013 17:45:13 +0000
In-Reply-To: <20130222174010.GC40494@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 17:40 +0000, Tim Deegan wrote:
> At 17:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
> > The xen debian packaging currently produces a debian package of what
> > 'make install' would produce. This includes a fair amount of development
> > only stuff, puts the hypervisor in /boot etc.
> > 
> > This packaging is not used by Ubuntu (I don't know about debian).
> 
> Debian also has its own packaging of Xen.
> 
> The 'make deb' target is explicitly not an attempt to package Xen in a
> way that's suitable for deployment -- it's just a way for developers to
> to install a build onto a testbox and cleanly uninstall it later.
> 
> Your minideb seems much more like a 'proper' package to me (with init
> files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
> packaging for Xen doesn't do what you need you should get involved in
> Debian/Ubuntu to make it so rather than duplicating effort here.
> 
> That said, tools and packaging aren't really my area and the tools
> maintainers may disagree.

FWIW I agree.

> I'm just commenting as the person responsible for the original make deb target.
> 
> 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 Fri Feb 22 17:50:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:50: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 1U8wko-0007hh-Sm; Fri, 22 Feb 2013 17:49: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 1U8wko-0007hb-9h
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:49:50 +0000
Received: from [85.158.137.99:38526] by server-9.bemta-3.messagelabs.com id
	6B/74-09484-6BFA7215; Fri, 22 Feb 2013 17:49:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361555380!12282517!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22713 invoked from network); 22 Feb 2013 17:49:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:49:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHnclw030849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 17:49:39 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
	r1MHnckh013855
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 17:49:38 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
	r1MHnbRA009549
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 11:49:37 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:49:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CC0FE1C3935; Fri, 22 Feb 2013 12:49:36 -0500 (EST)
Date: Fri, 22 Feb 2013 12:49:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130222174936.GA24736@phenom.dumpdata.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221130013.GA7240@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 08:00:13AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
> and I kept on getting:
> xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed (rc=-3): Internal error
> 
> Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> bisection but any thoughts off which one I ought to try out first?

So I tried also 23430 (RELEASE_4_1_4) and it hit the same issue. Then I tried on a
different box - an Intel one - and I did not see any issues.

I am wondering if that particular AMD box is suspect (F1A75-M, BIOS 0406 06/11/2011,
AMD A8-3850, Fam 18).
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 22 17:50:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:50: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 1U8wko-0007hh-Sm; Fri, 22 Feb 2013 17:49: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 1U8wko-0007hb-9h
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:49:50 +0000
Received: from [85.158.137.99:38526] by server-9.bemta-3.messagelabs.com id
	6B/74-09484-6BFA7215; Fri, 22 Feb 2013 17:49:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361555380!12282517!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22713 invoked from network); 22 Feb 2013 17:49:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:49:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHnclw030849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 17:49:39 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
	r1MHnckh013855
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 17:49:38 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
	r1MHnbRA009549
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 11:49:37 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:49:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CC0FE1C3935; Fri, 22 Feb 2013 12:49:36 -0500 (EST)
Date: Fri, 22 Feb 2013 12:49:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130222174936.GA24736@phenom.dumpdata.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221130013.GA7240@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 08:00:13AM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
> and I kept on getting:
> xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed (rc=-3): Internal error
> 
> Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> bisection but any thoughts off which one I ought to try out first?

So I tried also 23430 (RELEASE_4_1_4) and it hit the same issue. Then I tried on a
different box - an Intel one - and I did not see any issues.

I am wondering if that particular AMD box is suspect (F1A75-M, BIOS 0406 06/11/2011,
AMD A8-3850, Fam 18).
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 22 17:50:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wlU-0007kY-C9; Fri, 22 Feb 2013 17:50:32 +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 1U8wlS-0007k9-Qf
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:50:31 +0000
Received: from [85.158.137.99:35863] by server-11.bemta-3.messagelabs.com id
	FB/F6-10249-EDFA7215; Fri, 22 Feb 2013 17:50:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361555420!14487344!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTMyNTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26454 invoked from network); 22 Feb 2013 17:50:21 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:50:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHoIbS029385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:50:19 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
	r1MHoIrR024580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:50:18 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1MHoHrT010058; Fri, 22 Feb 2013 11:50:17 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:50:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFD301C3935; Fri, 22 Feb 2013 12:50:16 -0500 (EST)
Date: Fri, 22 Feb 2013 12:50:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222175016.GB24736@phenom.dumpdata.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
	<51262B5202000078000BFF10@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51262B5202000078000BFF10@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 01:12:34PM +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 14:00, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 
> > 23459:9f12bdd6b7f0
> > and I kept on getting:
> > xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed 
> > (rc=-3): Internal error
> > 
> > Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> > bisection but any thoughts off which one I ought to try out first?
> 
> Apart from a couple of QEMU_TAG updates and the oxenstored
> security fixes I don't see any tools changes since 4.1.4 at all, so
> a tools side regression seems rather unlikely. And the hypervisor
> side changes also don't look like they could cause this sort of a
> failure.
> 
> You didn't happen to have some stale (from another version's
> build) shared libraries left installed?

No. The build thing does a nice clean slate of this.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:50:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17: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 1U8wlU-0007kY-C9; Fri, 22 Feb 2013 17:50:32 +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 1U8wlS-0007k9-Qf
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:50:31 +0000
Received: from [85.158.137.99:35863] by server-11.bemta-3.messagelabs.com id
	FB/F6-10249-EDFA7215; Fri, 22 Feb 2013 17:50:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361555420!14487344!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTMyNTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26454 invoked from network); 22 Feb 2013 17:50:21 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:50:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MHoIbS029385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 17:50:19 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
	r1MHoIrR024580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 17:50:18 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1MHoHrT010058; Fri, 22 Feb 2013 11:50:17 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 09:50:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFD301C3935; Fri, 22 Feb 2013 12:50:16 -0500 (EST)
Date: Fri, 22 Feb 2013 12:50:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222175016.GB24736@phenom.dumpdata.com>
References: <20130221130013.GA7240@phenom.dumpdata.com>
	<51262B5202000078000BFF10@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51262B5202000078000BFF10@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression with Xen 4.1.5 (cs 23459 compared to cs
 23431)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 01:12:34PM +0000, Jan Beulich wrote:
> >>> On 21.02.13 at 14:00, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > So I tried to start an PV guest with Fri Feb 15 15:31:55 2013 +0100 
> > 23459:9f12bdd6b7f0
> > and I kept on getting:
> > xc: error: panic: xc_dom_core.c:315: xc_dom_do_gunzip: inflate failed 
> > (rc=-3): Internal error
> > 
> > Then rebuilt it with cs 23431 and it booted fine. Hadn't tried any specific
> > bisection but any thoughts off which one I ought to try out first?
> 
> Apart from a couple of QEMU_TAG updates and the oxenstored
> security fixes I don't see any tools changes since 4.1.4 at all, so
> a tools side regression seems rather unlikely. And the hypervisor
> side changes also don't look like they could cause this sort of a
> failure.
> 
> You didn't happen to have some stale (from another version's
> build) shared libraries left installed?

No. The build thing does a nice clean slate of this.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:58:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:58: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 1U8wsf-0008RP-Qd; Fri, 22 Feb 2013 17:57:57 +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 1U8wse-0008RK-IQ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:57:56 +0000
Received: from [85.158.138.51:61845] by server-3.bemta-3.messagelabs.com id
	BE/2B-31070-3A1B7215; Fri, 22 Feb 2013 17:57:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361555873!10110043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6589 invoked from network); 22 Feb 2013 17:57:55 -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;
	22 Feb 2013 17:57:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="9076199"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 17:57:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 12:57:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8wsa-0006Jq-KZ;
	Fri, 22 Feb 2013 17:57:52 +0000
Date: Fri, 22 Feb 2013 17:57:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130222174010.GC40494@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Tim Deegan wrote:
> At 17:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
> > The xen debian packaging currently produces a debian package of what
> > 'make install' would produce. This includes a fair amount of development
> > only stuff, puts the hypervisor in /boot etc.
> > 
> > This packaging is not used by Ubuntu (I don't know about debian).
> 
> Debian also has its own packaging of Xen.
> 
> The 'make deb' target is explicitly not an attempt to package Xen in a
> way that's suitable for deployment -- it's just a way for developers to
> to install a build onto a testbox and cleanly uninstall it later.
> 
> Your minideb seems much more like a 'proper' package to me (with init
> files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
> packaging for Xen doesn't do what you need you should get involved in
> Debian/Ubuntu to make it so rather than duplicating effort here.
> 
> That said, tools and packaging aren't really my area and the tools
> maintainers may disagree.  I'm just commenting as the person responsible
> for the original make deb target.

I think it could still be very useful to many people. If not on the
xen-unstable repository, it should still be published somewhere.
Maybe a link on the wiki or a blog article?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:58:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:58: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 1U8wsf-0008RP-Qd; Fri, 22 Feb 2013 17:57:57 +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 1U8wse-0008RK-IQ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:57:56 +0000
Received: from [85.158.138.51:61845] by server-3.bemta-3.messagelabs.com id
	BE/2B-31070-3A1B7215; Fri, 22 Feb 2013 17:57:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361555873!10110043!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA2NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6589 invoked from network); 22 Feb 2013 17:57:55 -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;
	22 Feb 2013 17:57:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="9076199"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 17:57:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 12:57:53 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8wsa-0006Jq-KZ;
	Fri, 22 Feb 2013 17:57:52 +0000
Date: Fri, 22 Feb 2013 17:57:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130222174010.GC40494@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Tim Deegan wrote:
> At 17:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
> > The xen debian packaging currently produces a debian package of what
> > 'make install' would produce. This includes a fair amount of development
> > only stuff, puts the hypervisor in /boot etc.
> > 
> > This packaging is not used by Ubuntu (I don't know about debian).
> 
> Debian also has its own packaging of Xen.
> 
> The 'make deb' target is explicitly not an attempt to package Xen in a
> way that's suitable for deployment -- it's just a way for developers to
> to install a build onto a testbox and cleanly uninstall it later.
> 
> Your minideb seems much more like a 'proper' package to me (with init
> files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
> packaging for Xen doesn't do what you need you should get involved in
> Debian/Ubuntu to make it so rather than duplicating effort here.
> 
> That said, tools and packaging aren't really my area and the tools
> maintainers may disagree.  I'm just commenting as the person responsible
> for the original make deb target.

I think it could still be very useful to many people. If not on the
xen-unstable repository, it should still be published somewhere.
Maybe a link on the wiki or a blog article?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 17:59:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:59: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 1U8wtV-0008UO-8f; Fri, 22 Feb 2013 17:58:49 +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 1U8wtU-0008UD-Br
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:58:48 +0000
Received: from [85.158.138.51:12096] by server-9.bemta-3.messagelabs.com id
	01/0D-09484-7D1B7215; Fri, 22 Feb 2013 17:58:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361555926!28756466!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3087 invoked from network); 22 Feb 2013 17:58:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:58: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.297.1; Fri, 22 Feb 2013 17:58:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wtS-0002pf-HG; Fri, 22 Feb 2013 17:58:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wtS-0003dA-CE;
	Fri, 22 Feb 2013 17:58:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.45523.174629.539552@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:58:43 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1302221738560.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
	<4CECB0F28D4441D2BD4AC7E3@nimrod.local>
	<20775.42788.510270.735773@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302221738560.22997@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> On Fri, 22 Feb 2013, Ian Jackson wrote:
> > I was referring to the libxl changes.  The changes to
> > qemu-xen-upstream's tag in Config.mk don't seem to have been done
> > yet.  Stefano, do you have a process for updating that ?
> 
> No, I haven't

Done.  I have a shonky script which I use for this, which I haven't
updated to use git yet.  When I do that I'll try to remember to email
it to you so you can DIY...

> > Shall I do
> > it this time ?
> 
> Yes, please

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 Fri Feb 22 17:59:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 17:59: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 1U8wtV-0008UO-8f; Fri, 22 Feb 2013 17:58:49 +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 1U8wtU-0008UD-Br
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 17:58:48 +0000
Received: from [85.158.138.51:12096] by server-9.bemta-3.messagelabs.com id
	01/0D-09484-7D1B7215; Fri, 22 Feb 2013 17:58:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361555926!28756466!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3087 invoked from network); 22 Feb 2013 17:58:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 17:58: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.297.1; Fri, 22 Feb 2013 17:58:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wtS-0002pf-HG; Fri, 22 Feb 2013 17:58:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wtS-0003dA-CE;
	Fri, 22 Feb 2013 17:58:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.45523.174629.539552@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 17:58:43 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1302221738560.22997@kaball.uk.xensource.com>
References: <1361393761-957-1-git-send-email-alex@alex.org.uk>
	<alpine.DEB.2.02.1302211208550.22997@kaball.uk.xensource.com>
	<E956941E2B3742BB71DC0702@nimrod.local>
	<20775.41425.748693.408786@mariner.uk.xensource.com>
	<4CECB0F28D4441D2BD4AC7E3@nimrod.local>
	<20775.42788.510270.735773@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302221738560.22997@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on
 qemu-xen device model in 4.2 - qemu patchset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] [PATCHv5 0/6] QEMU: Enabling live-migrate on HVM on qemu-xen device model in 4.2 - qemu patchset"):
> On Fri, 22 Feb 2013, Ian Jackson wrote:
> > I was referring to the libxl changes.  The changes to
> > qemu-xen-upstream's tag in Config.mk don't seem to have been done
> > yet.  Stefano, do you have a process for updating that ?
> 
> No, I haven't

Done.  I have a shonky script which I use for this, which I haven't
updated to use git yet.  When I do that I'll try to remember to email
it to you so you can DIY...

> > Shall I do
> > it this time ?
> 
> Yes, please

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 Fri Feb 22 18:00:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:00: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 1U8wuz-0000Ev-Sd; Fri, 22 Feb 2013 18:00:21 +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 1U8wuy-0000Ej-Mh
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:00:21 +0000
Received: from [85.158.139.211:18753] by server-2.bemta-5.messagelabs.com id
	69/D7-16911-332B7215; Fri, 22 Feb 2013 18:00:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361556013!18194019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19801 invoked from network); 22 Feb 2013 18:00:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:00:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8630308"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 18:00:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 13:00:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8wuq-0006MH-TH;
	Fri, 22 Feb 2013 18:00:12 +0000
Date: Fri, 22 Feb 2013 18:00:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130222174129.GD7768@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302221759000.22997@kaball.uk.xensource.com>
References: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
	<330E687E05E24E508F95A610@nimrod.local>
	<20130222174129.GD7768@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 05:28:42PM +0000, Alex Bligh wrote:
> > Konrad / Stefano,
> > 
> > Any update here?
> 
> Sorry, been so busy with bugs that this keeps on getting deferred.

I also have been too busy to look at this yet


> > I can't help but think a crashed dom0 and guaranteed domU corruption is
> > less bad than a theoretical data loss on a crash (not that we know
> > that theoretical possibility exists yet).
> 
> So from a perspective of blkif protocol, as long as the sync requests
> is properly being sent - then we are fine. I recall Stefano (or mayber Roger)
> finding some oddity in the xen_disk were the fsync wasn't sent.
> 
> You should be able to test this rather easy by (in your guest)
> mounting an ext3 or ext4 with barrier support and then looking at
> the blktrace/blkparse to make sure that the sync commands are indeed hitting
> the platter.
> 
> Thought there is probably a nice framework to do all of this automatically.
> Perhaps fio does that already..

Yes, if you can prove that the sync requests are all sent at the right
time and handled properly, then I am OK with the change.


> > I'm currently using this trivial patch
> > https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
> > 96aebc21af15074f3bf64c5c6795ca05f16
> > 
> > Alex
> > 
> > 
> > --On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> > 
> > >Konrad / Stefano,
> > >
> > >Any movement / ideas on this one?
> > >
> > >Alex
> > >
> > >--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> > >
> > >>Konrad,
> > >>
> > >>--On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> > >><stefano.stabellini@eu.citrix.com> wrote:
> > >>
> > >>>>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > >>>>index a402ac8..1c3a6f5 100644
> > >>>>--- a/hw/xen_disk.c
> > >>>>+++ b/hw/xen_disk.c
> > >>>>@@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
> > >>>>     }
> > >>>>
> > >>>>     /* read-only ? */
> > >>>>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> > >>>>+    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
> > >>>>BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
> > >>>>         qflags |= BDRV_O_RDWR;
> > >>>>     } else {
> > >>>
> > >>>Before going for something like that I would like a confirmation from
> > >>>Konrad about blkfront behavior regarding barriers and
> > >>>BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
> > >>>corruptions.
> > >>
> > >>Any ideas?
> > >>
> > >>
> > >>A slightly prettier patch would look like the one pasted
> > >>below (not sent with git-sendemail so beware whitespace issues).
> > >>
> > >>--
> > >>Alex Bligh
> > >>
> > >>commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> > >>Author: Alex Bligh <alex@alex.org.uk>
> > >>Date:   Thu Jan 24 09:41:34 2013 +0000
> > >>
> > >>    Disable use of O_DIRECT by default as it results in crashes.
> > >>
> > >>    See:
> > >>      http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
> > >>    for more details.
> > >>
> > >>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > >>index a402ac8..a618d8d 100644
> > >>--- a/hw/xen_disk.c
> > >>+++ b/hw/xen_disk.c
> > >>@@ -45,6 +45,8 @@ static int batch_maps   = 0;
> > >>
> > >> static int max_requests = 32;
> > >>
> > >>+static int use_o_direct = 0;
> > >>+
> > >> /* ------------------------------------------------------------- */
> > >>
> > >> # define BLOCK_SIZE  512
> > >>@@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
> > >>     }
> > >>
> > >>     /* read-only ? */
> > >>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> > >>+    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> > >>BDRV_O_NATIVE_AIO;
> > >>     if (strcmp(blkdev->mode, "w") == 0) {
> > >>         qflags |= BDRV_O_RDWR;
> > >>     } else {
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >--
> > >Alex Bligh
> > >
> > >
> > 
> > 
> > 
> > -- 
> > Alex Bligh
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:00:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:00: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 1U8wuz-0000Ev-Sd; Fri, 22 Feb 2013 18:00:21 +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 1U8wuy-0000Ej-Mh
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:00:21 +0000
Received: from [85.158.139.211:18753] by server-2.bemta-5.messagelabs.com id
	69/D7-16911-332B7215; Fri, 22 Feb 2013 18:00:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361556013!18194019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19801 invoked from network); 22 Feb 2013 18:00:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:00:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8630308"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 18:00:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 13:00:13 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8wuq-0006MH-TH;
	Fri, 22 Feb 2013 18:00:12 +0000
Date: Fri, 22 Feb 2013 18:00:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130222174129.GD7768@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302221759000.22997@kaball.uk.xensource.com>
References: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
	<330E687E05E24E508F95A610@nimrod.local>
	<20130222174129.GD7768@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, Xen Devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 05:28:42PM +0000, Alex Bligh wrote:
> > Konrad / Stefano,
> > 
> > Any update here?
> 
> Sorry, been so busy with bugs that this keeps on getting deferred.

I also have been too busy to look at this yet


> > I can't help but think a crashed dom0 and guaranteed domU corruption is
> > less bad than a theoretical data loss on a crash (not that we know
> > that theoretical possibility exists yet).
> 
> So from a perspective of blkif protocol, as long as the sync requests
> is properly being sent - then we are fine. I recall Stefano (or mayber Roger)
> finding some oddity in the xen_disk were the fsync wasn't sent.
> 
> You should be able to test this rather easy by (in your guest)
> mounting an ext3 or ext4 with barrier support and then looking at
> the blktrace/blkparse to make sure that the sync commands are indeed hitting
> the platter.
> 
> Thought there is probably a nice framework to do all of this automatically.
> Perhaps fio does that already..

Yes, if you can prove that the sync requests are all sent at the right
time and handled properly, then I am OK with the change.


> > I'm currently using this trivial patch
> > https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
> > 96aebc21af15074f3bf64c5c6795ca05f16
> > 
> > Alex
> > 
> > 
> > --On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> > 
> > >Konrad / Stefano,
> > >
> > >Any movement / ideas on this one?
> > >
> > >Alex
> > >
> > >--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> > >
> > >>Konrad,
> > >>
> > >>--On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> > >><stefano.stabellini@eu.citrix.com> wrote:
> > >>
> > >>>>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > >>>>index a402ac8..1c3a6f5 100644
> > >>>>--- a/hw/xen_disk.c
> > >>>>+++ b/hw/xen_disk.c
> > >>>>@@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
> > >>>>     }
> > >>>>
> > >>>>     /* read-only ? */
> > >>>>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> > >>>>+    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
> > >>>>BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
> > >>>>         qflags |= BDRV_O_RDWR;
> > >>>>     } else {
> > >>>
> > >>>Before going for something like that I would like a confirmation from
> > >>>Konrad about blkfront behavior regarding barriers and
> > >>>BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
> > >>>corruptions.
> > >>
> > >>Any ideas?
> > >>
> > >>
> > >>A slightly prettier patch would look like the one pasted
> > >>below (not sent with git-sendemail so beware whitespace issues).
> > >>
> > >>--
> > >>Alex Bligh
> > >>
> > >>commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> > >>Author: Alex Bligh <alex@alex.org.uk>
> > >>Date:   Thu Jan 24 09:41:34 2013 +0000
> > >>
> > >>    Disable use of O_DIRECT by default as it results in crashes.
> > >>
> > >>    See:
> > >>      http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
> > >>    for more details.
> > >>
> > >>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> > >>index a402ac8..a618d8d 100644
> > >>--- a/hw/xen_disk.c
> > >>+++ b/hw/xen_disk.c
> > >>@@ -45,6 +45,8 @@ static int batch_maps   = 0;
> > >>
> > >> static int max_requests = 32;
> > >>
> > >>+static int use_o_direct = 0;
> > >>+
> > >> /* ------------------------------------------------------------- */
> > >>
> > >> # define BLOCK_SIZE  512
> > >>@@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
> > >>     }
> > >>
> > >>     /* read-only ? */
> > >>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> > >>+    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> > >>BDRV_O_NATIVE_AIO;
> > >>     if (strcmp(blkdev->mode, "w") == 0) {
> > >>         qflags |= BDRV_O_RDWR;
> > >>     } else {
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >--
> > >Alex Bligh
> > >
> > >
> > 
> > 
> > 
> > -- 
> > Alex Bligh
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:01:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8wvv-0000Lx-BW; Fri, 22 Feb 2013 18:01: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 1U8wvt-0000Le-Gx
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:01:17 +0000
Received: from [85.158.143.99:37895] by server-3.bemta-4.messagelabs.com id
	24/00-02186-C62B7215; Fri, 22 Feb 2013 18:01:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361556075!19009142!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20170 invoked from network); 22 Feb 2013 18:01:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:01:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 18:01: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.297.1; Fri, 22 Feb 2013 18:01:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wvr-0002qX-5s; Fri, 22 Feb 2013 18:01:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wvr-0003fv-21;
	Fri, 22 Feb 2013 18:01:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.45674.842338.160840@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 18:01:14 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1212101227490.4633@kaball.uk.xensource.com>
References: <CAKhsbWaCbg0cP1eUYS6JdeNjpHZenEegOQ-7w7KFHE=xEJkoTQ@mail.gmail.com>
	<alpine.DEB.2.02.1212101227490.4633@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "G.R." <firemeteor@users.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen-trad/pt_msi_disable: do not clear
	all	MSI 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu-xen-trad/pt_msi_disabl=
e: do not clear all MSI flags"):
> "qemu-xen-trad: fix msi_translate with PV event delivery" added a
> pt_msi_disable() call into pt_msgctrl_reg_write, clearing the MSI flags
> as a consequence. MSIs get enabled again soon after by calling
> pt_msi_setup.
> =

> However the MSI flags are only setup once in=A0the pt_msgctrl_reg_init
> function, so from the QEMU point of view the device has lost some
> important properties, like for example PCI_MSI_FLAGS_64BIT.
> =

> This patch fixes the bug by clearing only the MSI
> enabled/mapped/initialized flags in pt_msi_disable.
> =

> =

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: G.R. <firemeteor@users.sourceforge.net>
> Xen-devel: http://marc.info/?l=3Dxen-devel&m=3D135489879503075

Applied, thanks.  Sorry for the delay.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:01:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8wvv-0000Lx-BW; Fri, 22 Feb 2013 18:01: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 1U8wvt-0000Le-Gx
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:01:17 +0000
Received: from [85.158.143.99:37895] by server-3.bemta-4.messagelabs.com id
	24/00-02186-C62B7215; Fri, 22 Feb 2013 18:01:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361556075!19009142!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20170 invoked from network); 22 Feb 2013 18:01:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:01:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 18:01: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.297.1; Fri, 22 Feb 2013 18:01:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wvr-0002qX-5s; Fri, 22 Feb 2013 18:01:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wvr-0003fv-21;
	Fri, 22 Feb 2013 18:01:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.45674.842338.160840@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 18:01:14 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1212101227490.4633@kaball.uk.xensource.com>
References: <CAKhsbWaCbg0cP1eUYS6JdeNjpHZenEegOQ-7w7KFHE=xEJkoTQ@mail.gmail.com>
	<alpine.DEB.2.02.1212101227490.4633@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "G.R." <firemeteor@users.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen-trad/pt_msi_disable: do not clear
	all	MSI 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu-xen-trad/pt_msi_disabl=
e: do not clear all MSI flags"):
> "qemu-xen-trad: fix msi_translate with PV event delivery" added a
> pt_msi_disable() call into pt_msgctrl_reg_write, clearing the MSI flags
> as a consequence. MSIs get enabled again soon after by calling
> pt_msi_setup.
> =

> However the MSI flags are only setup once in=A0the pt_msgctrl_reg_init
> function, so from the QEMU point of view the device has lost some
> important properties, like for example PCI_MSI_FLAGS_64BIT.
> =

> This patch fixes the bug by clearing only the MSI
> enabled/mapped/initialized flags in pt_msi_disable.
> =

> =

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: G.R. <firemeteor@users.sourceforge.net>
> Xen-devel: http://marc.info/?l=3Dxen-devel&m=3D135489879503075

Applied, thanks.  Sorry for the delay.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:05:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8wzx-0000sp-1O; Fri, 22 Feb 2013 18: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 1U8wzw-0000si-4q
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:05:28 +0000
Received: from [85.158.139.83:24712] by server-5.bemta-5.messagelabs.com id
	60/AA-11945-663B7215; Fri, 22 Feb 2013 18:05:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361556325!21308687!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24918 invoked from network); 22 Feb 2013 18:05:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:05:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 18:05: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.297.1; Fri, 22 Feb 2013 18:05:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wzt-0002rl-4g; Fri, 22 Feb 2013 18:05:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wzt-0003lo-0C;
	Fri, 22 Feb 2013 18:05:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.45924.670290.551847@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 18:05:24 +0000
To: "G.R." <firemeteor@users.sourceforge.net>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.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 v2] qemu-xen:Correctly expose PCH ISA bridge
	for	IGD 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

G.R. writes ("[Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough"):
> Fix IGD passthrough logic to properly expose PCH ISA bridge (instead
> of exposing as pci-pci bridge). The i915 driver require this to
> correctly detect the PCH version and enable version specific code
> path.

Applied, thanks.  I fixed up some wrap damage.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:05:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8wzx-0000sp-1O; Fri, 22 Feb 2013 18: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 1U8wzw-0000si-4q
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:05:28 +0000
Received: from [85.158.139.83:24712] by server-5.bemta-5.messagelabs.com id
	60/AA-11945-663B7215; Fri, 22 Feb 2013 18:05:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361556325!21308687!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24918 invoked from network); 22 Feb 2013 18:05:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:05:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1797584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 18:05: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.297.1; Fri, 22 Feb 2013 18:05:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8wzt-0002rl-4g; Fri, 22 Feb 2013 18:05:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8wzt-0003lo-0C;
	Fri, 22 Feb 2013 18:05:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.45924.670290.551847@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 18:05:24 +0000
To: "G.R." <firemeteor@users.sourceforge.net>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.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 v2] qemu-xen:Correctly expose PCH ISA bridge
	for	IGD 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

G.R. writes ("[Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough"):
> Fix IGD passthrough logic to properly expose PCH ISA bridge (instead
> of exposing as pci-pci bridge). The i915 driver require this to
> correctly detect the PCH version and enable version specific code
> path.

Applied, thanks.  I fixed up some wrap damage.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:07:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8x1J-00013f-KV; Fri, 22 Feb 2013 18:06:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave@linux.vnet.ibm.com>) id 1U8wbb-0006S8-Cf
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:40:19 +0000
Received: from [85.158.143.99:47983] by server-1.bemta-4.messagelabs.com id
	EC/60-06203-28DA7215; Fri, 22 Feb 2013 17:40:18 +0000
X-Env-Sender: dave@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361554814!28151740!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzODY1NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1822 invoked from network); 22 Feb 2013 17:40:15 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:40:15 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <dave@linux.vnet.ibm.com>;
	Fri, 22 Feb 2013 12:40:13 -0500
Received: from d01dlp01.pok.ibm.com (9.56.250.166)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 22 Feb 2013 12:40:09 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1BDCC38C801F
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 12:40:08 -0500 (EST)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	r1MHe64C348598
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 12:40:07 -0500
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id r1MHdDhM032706
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 10:39:29 -0700
Received: from kernel.stglabs.ibm.com (kernel.stglabs.ibm.com [9.114.214.19])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id r1MHd9qx031972; Fri, 22 Feb 2013 10:39:09 -0700
Received: from [9.65.132.22] (sig-9-65-132-22.mts.ibm.com [9.65.132.22])
	by kernel.stglabs.ibm.com (Postfix) with SMTP id 712E924028D;
	Fri, 22 Feb 2013 09:30:30 -0800 (PST)
Message-ID: <5127AB34.8090406@linux.vnet.ibm.com>
Date: Fri, 22 Feb 2013 09:30:28 -0800
From: Dave Hansen <dave@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
In-Reply-To: <20130222165531.GA29308@phenom.dumpdata.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13022217-5806-0000-0000-0000200700CD
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:06:52 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
>> Hi Linus,
>>
>> This is a huge set of several partly interrelated (and concurrently
>> developed) changes, which is why the branch history is messier than
>> one would like.
>>
>> The *really* big items are two humonguous patchsets mostly developed
>> by Yinghai Lu at my request, which completely revamps the way we
>> create initial page tables.  In particular, rather than estimating how
>> much memory we will need for page tables and then build them into that
>> memory -- a calculation that has shown to be incredibly fragile -- we
>> now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
>> a #PF handler which creates temporary page tables on demand.
>>
>> This has several advantages:
>>
>> 1. It makes it much easier to support things that need access to
>>    data very early (a followon patchset uses this to load microcode
>>    way early in the kernel startup).
>>
>> 2. It allows the kernel and all the kernel data objects to be invoked
>>    from above the 4 GB limit.  This allows kdump to work on very large
>>    systems.
>>
>> 3. It greatly reduces the difference between Xen and native (Xen's
>>    equivalent of the #PF handler are the temporary page tables created
>>    by the domain builder), eliminating a bunch of fragile hooks.
>>
>> The patch series also gets us a bit closer to W^X.
>>
>> Additional work in this pull is the 64-bit get_user() work which you
>> were also involved with, and a bunch of cleanups/speedups to
>> __phys_addr()/__pa().
> 
> Looking at figuring out which of the patches in the branch did this, but
> with this merge I am getting a crash with a very simple PV guest (booted with
> one 1G):
> 
> Call Trace:
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a 
>   [<ffffffff81042d27>] xen_write_cr3+0x77 
>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9 
>   [<ffffffff81ac293f>] setup_arch+0x742 
>   [<ffffffff81666d71>] printk+0x48 
>   [<ffffffff81abcd62>] start_kernel+0x90 
>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b 
>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a 
>   [<ffffffff81abf0c7>] xen_start_kernel+0x564 

Do you have CONFIG_DEBUG_VIRTUAL on?

You're probably hitting the new BUG_ON() in __phys_addr().  It's
intended to detect places where someone is doing a __pa()/__phys_addr()
on an address that's outside the kernel's identity mapping.

There are a lot of __pa() calls around there, but from the looks of it,
it's this code:

static pgd_t *xen_get_user_pgd(pgd_t *pgd)
{
...
        if (offset < pgd_index(USER_LIMIT)) {
                struct page *page = virt_to_page(pgd_page);

I'm a bit fuzzy on exactly what the code is trying to do here.  It could
mean either that the identity mapping isn't set up enough yet, or that
__pa() is getting called on a bogus address.

I'm especially fuzzy on why we'd be calling anything that's looking at
userspace pagetables (xen_get_user_pgd() ??) this early in boot.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:07:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8x1J-00013f-KV; Fri, 22 Feb 2013 18:06:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave@linux.vnet.ibm.com>) id 1U8wbb-0006S8-Cf
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:40:19 +0000
Received: from [85.158.143.99:47983] by server-1.bemta-4.messagelabs.com id
	EC/60-06203-28DA7215; Fri, 22 Feb 2013 17:40:18 +0000
X-Env-Sender: dave@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361554814!28151740!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzODY1NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1822 invoked from network); 22 Feb 2013 17:40:15 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 17:40:15 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <dave@linux.vnet.ibm.com>;
	Fri, 22 Feb 2013 12:40:13 -0500
Received: from d01dlp01.pok.ibm.com (9.56.250.166)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 22 Feb 2013 12:40:09 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1BDCC38C801F
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 12:40:08 -0500 (EST)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	r1MHe64C348598
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 12:40:07 -0500
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id r1MHdDhM032706
	for <xen-devel@lists.xensource.com>; Fri, 22 Feb 2013 10:39:29 -0700
Received: from kernel.stglabs.ibm.com (kernel.stglabs.ibm.com [9.114.214.19])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP
	id r1MHd9qx031972; Fri, 22 Feb 2013 10:39:09 -0700
Received: from [9.65.132.22] (sig-9-65-132-22.mts.ibm.com [9.65.132.22])
	by kernel.stglabs.ibm.com (Postfix) with SMTP id 712E924028D;
	Fri, 22 Feb 2013 09:30:30 -0800 (PST)
Message-ID: <5127AB34.8090406@linux.vnet.ibm.com>
Date: Fri, 22 Feb 2013 09:30:28 -0800
From: Dave Hansen <dave@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
In-Reply-To: <20130222165531.GA29308@phenom.dumpdata.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13022217-5806-0000-0000-0000200700CD
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:06:52 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
>> Hi Linus,
>>
>> This is a huge set of several partly interrelated (and concurrently
>> developed) changes, which is why the branch history is messier than
>> one would like.
>>
>> The *really* big items are two humonguous patchsets mostly developed
>> by Yinghai Lu at my request, which completely revamps the way we
>> create initial page tables.  In particular, rather than estimating how
>> much memory we will need for page tables and then build them into that
>> memory -- a calculation that has shown to be incredibly fragile -- we
>> now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
>> a #PF handler which creates temporary page tables on demand.
>>
>> This has several advantages:
>>
>> 1. It makes it much easier to support things that need access to
>>    data very early (a followon patchset uses this to load microcode
>>    way early in the kernel startup).
>>
>> 2. It allows the kernel and all the kernel data objects to be invoked
>>    from above the 4 GB limit.  This allows kdump to work on very large
>>    systems.
>>
>> 3. It greatly reduces the difference between Xen and native (Xen's
>>    equivalent of the #PF handler are the temporary page tables created
>>    by the domain builder), eliminating a bunch of fragile hooks.
>>
>> The patch series also gets us a bit closer to W^X.
>>
>> Additional work in this pull is the 64-bit get_user() work which you
>> were also involved with, and a bunch of cleanups/speedups to
>> __phys_addr()/__pa().
> 
> Looking at figuring out which of the patches in the branch did this, but
> with this merge I am getting a crash with a very simple PV guest (booted with
> one 1G):
> 
> Call Trace:
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a 
>   [<ffffffff81042d27>] xen_write_cr3+0x77 
>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9 
>   [<ffffffff81ac293f>] setup_arch+0x742 
>   [<ffffffff81666d71>] printk+0x48 
>   [<ffffffff81abcd62>] start_kernel+0x90 
>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b 
>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a 
>   [<ffffffff81abf0c7>] xen_start_kernel+0x564 

Do you have CONFIG_DEBUG_VIRTUAL on?

You're probably hitting the new BUG_ON() in __phys_addr().  It's
intended to detect places where someone is doing a __pa()/__phys_addr()
on an address that's outside the kernel's identity mapping.

There are a lot of __pa() calls around there, but from the looks of it,
it's this code:

static pgd_t *xen_get_user_pgd(pgd_t *pgd)
{
...
        if (offset < pgd_index(USER_LIMIT)) {
                struct page *page = virt_to_page(pgd_page);

I'm a bit fuzzy on exactly what the code is trying to do here.  It could
mean either that the identity mapping isn't set up enough yet, or that
__pa() is getting called on a bogus address.

I'm especially fuzzy on why we'd be calling anything that's looking at
userspace pagetables (xen_get_user_pgd() ??) this early in boot.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:07:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8x1K-00013w-EM; Fri, 22 Feb 2013 18:06:54 +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 1U8x0g-0000wm-56
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:06:14 +0000
Received: from [85.158.138.51:47790] by server-1.bemta-3.messagelabs.com id
	77/69-08955-593B7215; Fri, 22 Feb 2013 18:06:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361556370!28834695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10806 invoked from network); 22 Feb 2013 18:06:12 -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;
	22 Feb 2013 18:06:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8631647"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 18:06:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 13:06:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8x0b-0006RG-4R;
	Fri, 22 Feb 2013 18:06:09 +0000
Date: Fri, 22 Feb 2013 18:06:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130222173805.GC7768@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:06:52 +0000
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?Q?Ville_Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"mst@redhat.com" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
	Rob Landley <rob@landley.net>, Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
> > On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
> > >
> > >What is bizzare is that I do recall testing this (and Stefano also did it).
> > >So I am not sure what has altered.
> > >
> > 
> > Yes, there was a very specific reason why I wanted you guys to test it...
> 
> Exactly. And I re-ran the same test, but with a new kernel. This is what
> git reflog tells me:
> 
> 473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
> 08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
> eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
> [konrad@build linux]$ git show 08f321e
> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
> Author: Yinghai Lu <yinghai@kernel.org>
> Date:   Thu Nov 8 00:00:19 2012 -0800
> 
>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
> 
> And I recall Stefano later on testing (I was in a conference and did not have
> the opportunity to test it). Not sure what he ran with.
> 

FYI the last patch series I tested was Yinghai's "x86, boot, 64bit: Add
support for loading ramdisk and bzImage above 4G" v7u1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:07:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8x1K-00013w-EM; Fri, 22 Feb 2013 18:06:54 +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 1U8x0g-0000wm-56
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:06:14 +0000
Received: from [85.158.138.51:47790] by server-1.bemta-3.messagelabs.com id
	77/69-08955-593B7215; Fri, 22 Feb 2013 18:06:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361556370!28834695!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10806 invoked from network); 22 Feb 2013 18:06:12 -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;
	22 Feb 2013 18:06:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8631647"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 18:06:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 13:06:09 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U8x0b-0006RG-4R;
	Fri, 22 Feb 2013 18:06:09 +0000
Date: Fri, 22 Feb 2013 18:06:04 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130222173805.GC7768@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:06:52 +0000
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?UTF-8?Q?Ville_Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"mst@redhat.com" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
	Rob Landley <rob@landley.net>, Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
> > On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
> > >
> > >What is bizzare is that I do recall testing this (and Stefano also did it).
> > >So I am not sure what has altered.
> > >
> > 
> > Yes, there was a very specific reason why I wanted you guys to test it...
> 
> Exactly. And I re-ran the same test, but with a new kernel. This is what
> git reflog tells me:
> 
> 473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
> 08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
> eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
> [konrad@build linux]$ git show 08f321e
> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
> Author: Yinghai Lu <yinghai@kernel.org>
> Date:   Thu Nov 8 00:00:19 2012 -0800
> 
>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
> 
> And I recall Stefano later on testing (I was in a conference and did not have
> the opportunity to test it). Not sure what he ran with.
> 

FYI the last patch series I tested was Yinghai's "x86, boot, 64bit: Add
support for loading ramdisk and bzImage above 4G" v7u1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:07:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8x1J-00013n-W1; Fri, 22 Feb 2013 18:06:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U8wo6-0008Ix-RN
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:53:15 +0000
Received: from [85.158.137.99:3217] by server-4.bemta-3.messagelabs.com id
	23/CD-17521-480B7215; Fri, 22 Feb 2013 17:53:08 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361555584!12282904!1
X-Originating-IP: [209.85.210.180]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 454 invoked from network); 22 Feb 2013 17:53:06 -0000
Received: from mail-ia0-f180.google.com (HELO mail-ia0-f180.google.com)
	(209.85.210.180)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:53:06 -0000
Received: by mail-ia0-f180.google.com with SMTP id f27so781056iae.11
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 09:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=8f6j8iLpIG3zT5eiJK3fuUFAYJwHJmuVHYnSTwjeQQg=;
	b=h/+y2on2H2jja84COrXlpe7//ClYZnHRwVcOQPwLlhyd+Qw+VERTlRDdfhZh364rXp
	iRApKmE6KvByx2FRi0RS2xTp0vpJjdiJDlz7jDfa1o+oI23tyztHwKJ4srUopaHEr8kT
	iGNlM2TaxqTC8X2Q3uZnretwPB9RBCo2K/vDeCqHC+U7/9keE0lhQLlc0KRzijnGKJRm
	JB+n59lXonYrYIEDBiJ3OZE9e66KEm+GjMiunSXQevX1m/Pq6p6OXgL6TcKTyrWBlMFo
	lpx6Gj/OOfNMdHAjBnZ0sqlGmplhZDdEzwpxNJt4e6bgrzoxtnPxwKpuRG+94UjOFRHF
	QB7A==
MIME-Version: 1.0
X-Received: by 10.50.197.131 with SMTP id iu3mr15326530igc.109.1361555584360; 
	Fri, 22 Feb 2013 09:53:04 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 09:53:04 -0800 (PST)
In-Reply-To: <20130222172403.GA17056@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
Date: Fri, 22 Feb 2013 09:53:04 -0800
X-Google-Sender-Auth: id8MzEWj1Jum5e4cIb5THdgo6aw
Message-ID: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:06:52 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 9:24 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
>> > Hi Linus,
>> >
>> > This is a huge set of several partly interrelated (and concurrently
>> > developed) changes, which is why the branch history is messier than
>> > one would like.
>> >
>> > The *really* big items are two humonguous patchsets mostly developed
>> > by Yinghai Lu at my request, which completely revamps the way we
>> > create initial page tables.  In particular, rather than estimating how
>> > much memory we will need for page tables and then build them into that
>> > memory -- a calculation that has shown to be incredibly fragile -- we
>> > now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
>> > a #PF handler which creates temporary page tables on demand.
>> >
>> > This has several advantages:
>> >
>> > 1. It makes it much easier to support things that need access to
>> >    data very early (a followon patchset uses this to load microcode
>> >    way early in the kernel startup).
>> >
>> > 2. It allows the kernel and all the kernel data objects to be invoked
>> >    from above the 4 GB limit.  This allows kdump to work on very large
>> >    systems.
>> >
>> > 3. It greatly reduces the difference between Xen and native (Xen's
>> >    equivalent of the #PF handler are the temporary page tables created
>> >    by the domain builder), eliminating a bunch of fragile hooks.
>> >
>> > The patch series also gets us a bit closer to W^X.
>> >
>> > Additional work in this pull is the 64-bit get_user() work which you
>> > were also involved with, and a bunch of cleanups/speedups to
>> > __phys_addr()/__pa().
>>
>> Looking at figuring out which of the patches in the branch did this, but
>> with this merge I am getting a crash with a very simple PV guest (booted with
>> one 1G):
>>
>> Call Trace:
>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a
>>   [<ffffffff81042d27>] xen_write_cr3+0x77
>>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
>>   [<ffffffff81ac293f>] setup_arch+0x742
>>   [<ffffffff81666d71>] printk+0x48
>>   [<ffffffff81abcd62>] start_kernel+0x90
>>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
>>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
>>   [<ffffffff81abf0c7>] xen_start_kernel+0x564
>>
>> And the hypervisor says:
>> (XEN) d7:v0: unhandled page fault (ec=0000)
>> (XEN) Pagetable walk from ffffea000005b2d0:
>> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 7 (vcpu#0) crashed on cpu#3:
>> (XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    3
>> (XEN) RIP:    e033:[<ffffffff8103feba>]
>> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
>> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
>> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
>> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
>> (XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
>> (XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
>> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
>> (XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
>> (XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
>> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
>
> Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
> kernel with 8GB):
>
> PXELINUX 3.82 2009-06-09  Copyright (C) 1994-2009 H. Peter Anvin et al
> boot:
> Loading xen.gz... ok
> Loading vmlinuz... ok
> Loading initramfs.cpio.gz... ok
>  __  __            _  _    _   ____
>  \ \/ /___ _ __   | || |  / | | ___|    _ __  _ __ ___
>   \  // _ \ '_(_)_(_)____/   | .__/|_|  \___|
>                                        |_|
> (XEN) Xen version 4.1.5-pre (konrad@dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) Fri Feb 22 11:37:00 EST 2013
> (XEN) Latest ChangeSet: Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
> (XEN) Console output is synchronous.
> (XEN) Bootloader: unknown
> (XEN) Command line: cpuinfo conring_size=1048576 sync_console cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009ec00 (usable)
> (XEN)  000000000009ec00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 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)
> (XEN)  00000000badc9000 - 00000000badd1000 (ACPI data)
> (XEN)  00000000badd1000 - 00000000badf4000 (reserved)
> (XEN)  00000000badf4000 - 00000000badf6000 (usable)
> (XEN)  00000000badf6000 - 00000000bae06000 (reserved)
> (XEN)  00000000bae06000 - 00000000bae14000 (ACPI NVS)
> (XEN)  00000000bae14000 - 00000000bae3c000 (reserved)
> (XEN)  00000000bae3c000 - 00000000bae7f000 (ACPI NVS)
> (XEN)  00000000bae7f000 - 00000000bb000000 (usable)
> (XEN)  00000000bb800000 - 00000000bfa00000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 000000023fe00000 (usable)
> (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
> (XEN) ACPI: XSDT BADC9068, 0054 (r1 ALASKA    A M I  1072009 AMI     10013)
> (XEN)  PROC        1 MSFT  3000001)
> (XEN) ACPI: MCFG BADD0580, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
> (XEN) ACPI: HPET BADD05C0, 0038 (r1 ALASKA    A M I  1072009 AMI.        4)
> (XEN) ACPI: ASF! BADD05F8, 00A0 (r32 INTEL       HCG        1 TFSM    F4240)
> (XEN) System RAM: 8104MB (8299140kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-000000023fe00000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000fcde0
> (XEN) DMI 2.7 present.
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x408
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
> (XEN) ACPI: 32/64X FACS address mismatch in FADT - bae0bf80/0000000000000000, using 32
> (XEN) ACPI:                  wakeup_vec[bae0bf8c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 6:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> (XEN) Processor #2 6:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
> (XEN) Processor #1 6:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> (XEN) Processor #3 6:10 APIC version 21
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ2 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> (XEN) PCI: Not using MMCONFIG.
> (XEN) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Initializing CPU#0
> (XEN) Detected 3093.067 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 0
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 256K
> (XEN) CPU: L3 cache: 3072K
> (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
> (XEN) CPU0: Thermal monitoring enabled (TM1)
> (XEN) Intel machine check reporting enabled
> (XEN) I/O virtualisation disabled
> (XEN) CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
> (XEN) Enabled directed EOI with ioapic_ack_old on!
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using old ACK method
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> (XEN) TSC deadline timer enabled
> (XEN) Platform timer is 14.318MHz HPET
> (XEN) Allocated console ring of 1048576 KiB.
> (XEN) VMX: Supported advanced features:
> (isation
> (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
> (XEN) Booting processor 1/1 eip 7c000
> (XEN) Initializing CPU#1
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 0
> (XEN) CPU: L1 I cache: 32K, L1 D
> (XEN) Initializing CPU#2
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 256K
> (XEN) CPU: L3 cache: 3072K
> (XEN) CPU2: Thermal monitoring enabled (TM1)
> (XEN) CPU2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
> (XEN) Booting processor 3/3 eip 7c000
> (XEN) Initializing CPU#3
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CPU: L1 I cache: 32K, L1 D100 CPU @ 3.10GHz stepping 07
> (XEN) Brought up 4 CPUs
> (XEN) ACPI sleep modes: S3
> (XEN) mcheck_poll: Machine check polling timer started.
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x9e0000
> (XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xa60f0
> (XEN): paddr=0x1abc000 memsz=0x61b000
> (XEN) elf_parse_binary: memory: 0x1000000 -> 0x20d7000
> (XEN) elf_xen_parse_note: GUEST_OS = "linux"
> (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
> (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
> (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
> (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81abc1e0
> (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
> (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
> (XEN) elf_xen_parse_note: PAE_MODE = "yes"
> (XEN) elf_xen_parse_note: LOADER = "generic"
> (XEN) elf_xen_parse_note: unknown xen elf note (0xd)
> (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
> (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
> (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
> (XEN) elf_xen_addr_calc_check: addresses:
> (XEN)     virt_base        = 0xffffffff80000000
> (XEN)     elf_paddr_offset = 0x0
> (XEN)     virt_offset      = 0xffffffff80000000
> (XEN)     virt_kstart      = 0xffffffff81000000
> (XEN)     virt_kend        = 0xffffffff820d7000
> (XEN)     virt_entry       = 0xffffffff81abc1e0
> (XEN)     p2m_base         = 0xffffffffffffffff
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20d7000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (1661249 pages to be allocated)
> (XEN)  Init. ramdisk: 000000022cbdc000->000000023fe00000
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: ffffffff81000000->ffffffff820d7000
> (XEN)  Init. ramdisk: ffffffff820d7000->ffffffff952fb000
> (XEN)  Phys-Mach map: ffffffff952fb000->ffffffff96060b28
> (XEN)  Start info:    ffffffff96061000->ffffffff960614b4
> (XEN)  Page tables:   ffffffff96062000->ffffffff96117000
> (XEN)  Boot stack:    ffffffff96117000->ffffffff96118000
> (XEN)  TOTAL:         ffffffff80000000->ffffffff96400000
> (XEN)  ENTRY ADDRESS: ffffffff81abc1e0
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff819e0000
> (XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81aa60f0
> (XEN) elf_load_binary: phdr 2 at 0xffffffff81aa7000 -> 0xffffffff81abbbc0
> (XEN) elf_load_binary: phdr 3 at 0xffffffff81abc000 -> 0xffffffff81baf000
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) ***************************intended to aid debugging of Xen by ensuring
> (XEN) ******* that all output is synchronously delivered on the serial line.
> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
> (XEN) ******* timekeeping. It is NOT recommended for production use!
> (XEN) **********************************************
> (XEN) 3... 2... 1...
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) Freed 224kB init memory.
> mapping kernel into physical memory
> about to get started...
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.8.0upstream-06471-g2ef14f4-dirty (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 11:36:48 EST 2013
> [    0.000000] Command line: initcall_debug debug console=hvc0 loglevel=10 xen-pciback.hide=(01:00.0) earlyprintk=xen
> [    0.000000] Freeing 9e-100 pfn range: 98 pages freed
> [    0.000000] 1-1 mapping on 9e->100
> [    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
> [    0.000000] 1-1 mapping on 20000->20200
> [    0.000000] Freeing 40000-40200 pfn range: 512 pages freed
> [    0.000000] 1-1 mapping on 40000->40200
> [    0.000000] Freeing bad80-badf4 pfn range: 116 pages freed
> [    0.000000] 1-1 mapping on bad80->badf4
> [    0.000000] Freeing badf6-bae7f pfn range: 137 pages freed
> [    0.000000] 1-1 mapping on badf6->bae7f
> [    0.000000] Freeing bb000-100000 pfn range: 282624 pages freed
> [    0.000000] 1-1 mapping on bb000->100000
> [    0.000000] Released 283999 pages of unused memory
> [    0.000000] Set 283999 page(s) to 1-1 mapping
> [    0.000000] Populating 1acb65-1f20c4 pfn range: 283999 pages added
> [    0.000000] e820: BIOS-provided physical RAM map:
> [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
> [    0.000000] Xen: [mem 0x000000000009ec00-0x00000000000fffff] reserved
> [    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
> [    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
> [    0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable
> [    0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved
> [    0.000000] Xen: [mem 0x0000000040200000-0x00000000bad7ffff] usable
> [    0.000000] Xen: [mem 0x00000000bad80000-0x00000000badc8fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000badc9000-0x00000000badd0fff] ACPI data
> [    0.000000] Xen: [mem 0x00000000badd1000-0x00000000badf3fff] reserved
> [    0.000000] Xen: [mem 0x00000000badf4000-0x00000000badf5fff] usable
> [    0.000000] Xen: [mem 0x00000000badf6000-0x00000000bae05fff] reserved
> [    0.000000] Xen: [mem 0x00000000bae06000-0x00000000bae13fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000bae14000-0x00000000bae3bfff] reserved
> [    0.000000] Xen: [mem 0x00000000bae3c000-0x00000000bae7efff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000bae7f000-0x00000000baffffff] usable
> [    0.000000] Xen: [mem 0x00000000bb800000-0x00000000bf9fffff] reserved
> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [    0.000000] Xen: [mem 0x0000000100000000-0x000000023fdfffff] usable
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] SMBIOS 2.7 present.
> [    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
> [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> [    0.000000] No AGP bridge found
> [    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
> [    0.000000] e820: lacanning 1 areas for low memory corruption
> [    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
> [    0.000000] reserving inaccessible SNB gfx pages
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
> [    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
> [    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
> [    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
> [    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
> [    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
> [    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
> [    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
> [    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
> [    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
> [    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
> [    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
> [    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
> [    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
> [    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
> [    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
> [    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
> [    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
> [    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k

so init_memory_mapping are all done.

> (XEN) d0:v0: unhandled page fault (ec=0000)
> (XEN) Pagetable walk from ffffea000005b2d0:
> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[<ffffffff8103feba>]
> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
> (XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
> (XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> (XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
> (XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
> (XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
> (XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
> (XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
> (XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
> (XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
> (XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
> (XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
> (XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
> (XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

can we get kernel trace instead?

>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:07:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8x1J-00013n-W1; Fri, 22 Feb 2013 18:06:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U8wo6-0008Ix-RN
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 17:53:15 +0000
Received: from [85.158.137.99:3217] by server-4.bemta-3.messagelabs.com id
	23/CD-17521-480B7215; Fri, 22 Feb 2013 17:53:08 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361555584!12282904!1
X-Originating-IP: [209.85.210.180]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 454 invoked from network); 22 Feb 2013 17:53:06 -0000
Received: from mail-ia0-f180.google.com (HELO mail-ia0-f180.google.com)
	(209.85.210.180)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 17:53:06 -0000
Received: by mail-ia0-f180.google.com with SMTP id f27so781056iae.11
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 09:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=8f6j8iLpIG3zT5eiJK3fuUFAYJwHJmuVHYnSTwjeQQg=;
	b=h/+y2on2H2jja84COrXlpe7//ClYZnHRwVcOQPwLlhyd+Qw+VERTlRDdfhZh364rXp
	iRApKmE6KvByx2FRi0RS2xTp0vpJjdiJDlz7jDfa1o+oI23tyztHwKJ4srUopaHEr8kT
	iGNlM2TaxqTC8X2Q3uZnretwPB9RBCo2K/vDeCqHC+U7/9keE0lhQLlc0KRzijnGKJRm
	JB+n59lXonYrYIEDBiJ3OZE9e66KEm+GjMiunSXQevX1m/Pq6p6OXgL6TcKTyrWBlMFo
	lpx6Gj/OOfNMdHAjBnZ0sqlGmplhZDdEzwpxNJt4e6bgrzoxtnPxwKpuRG+94UjOFRHF
	QB7A==
MIME-Version: 1.0
X-Received: by 10.50.197.131 with SMTP id iu3mr15326530igc.109.1361555584360; 
	Fri, 22 Feb 2013 09:53:04 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 09:53:04 -0800 (PST)
In-Reply-To: <20130222172403.GA17056@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
Date: Fri, 22 Feb 2013 09:53:04 -0800
X-Google-Sender-Auth: id8MzEWj1Jum5e4cIb5THdgo6aw
Message-ID: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:06:52 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 9:24 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
>> > Hi Linus,
>> >
>> > This is a huge set of several partly interrelated (and concurrently
>> > developed) changes, which is why the branch history is messier than
>> > one would like.
>> >
>> > The *really* big items are two humonguous patchsets mostly developed
>> > by Yinghai Lu at my request, which completely revamps the way we
>> > create initial page tables.  In particular, rather than estimating how
>> > much memory we will need for page tables and then build them into that
>> > memory -- a calculation that has shown to be incredibly fragile -- we
>> > now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
>> > a #PF handler which creates temporary page tables on demand.
>> >
>> > This has several advantages:
>> >
>> > 1. It makes it much easier to support things that need access to
>> >    data very early (a followon patchset uses this to load microcode
>> >    way early in the kernel startup).
>> >
>> > 2. It allows the kernel and all the kernel data objects to be invoked
>> >    from above the 4 GB limit.  This allows kdump to work on very large
>> >    systems.
>> >
>> > 3. It greatly reduces the difference between Xen and native (Xen's
>> >    equivalent of the #PF handler are the temporary page tables created
>> >    by the domain builder), eliminating a bunch of fragile hooks.
>> >
>> > The patch series also gets us a bit closer to W^X.
>> >
>> > Additional work in this pull is the 64-bit get_user() work which you
>> > were also involved with, and a bunch of cleanups/speedups to
>> > __phys_addr()/__pa().
>>
>> Looking at figuring out which of the patches in the branch did this, but
>> with this merge I am getting a crash with a very simple PV guest (booted with
>> one 1G):
>>
>> Call Trace:
>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a
>>   [<ffffffff81042d27>] xen_write_cr3+0x77
>>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
>>   [<ffffffff81ac293f>] setup_arch+0x742
>>   [<ffffffff81666d71>] printk+0x48
>>   [<ffffffff81abcd62>] start_kernel+0x90
>>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
>>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
>>   [<ffffffff81abf0c7>] xen_start_kernel+0x564
>>
>> And the hypervisor says:
>> (XEN) d7:v0: unhandled page fault (ec=0000)
>> (XEN) Pagetable walk from ffffea000005b2d0:
>> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 7 (vcpu#0) crashed on cpu#3:
>> (XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    3
>> (XEN) RIP:    e033:[<ffffffff8103feba>]
>> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
>> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
>> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
>> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
>> (XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
>> (XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
>> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
>> (XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
>> (XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
>> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
>
> Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
> kernel with 8GB):
>
> PXELINUX 3.82 2009-06-09  Copyright (C) 1994-2009 H. Peter Anvin et al
> boot:
> Loading xen.gz... ok
> Loading vmlinuz... ok
> Loading initramfs.cpio.gz... ok
>  __  __            _  _    _   ____
>  \ \/ /___ _ __   | || |  / | | ___|    _ __  _ __ ___
>   \  // _ \ '_(_)_(_)____/   | .__/|_|  \___|
>                                        |_|
> (XEN) Xen version 4.1.5-pre (konrad@dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) Fri Feb 22 11:37:00 EST 2013
> (XEN) Latest ChangeSet: Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
> (XEN) Console output is synchronous.
> (XEN) Bootloader: unknown
> (XEN) Command line: cpuinfo conring_size=1048576 sync_console cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009ec00 (usable)
> (XEN)  000000000009ec00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e0000 - 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)
> (XEN)  00000000badc9000 - 00000000badd1000 (ACPI data)
> (XEN)  00000000badd1000 - 00000000badf4000 (reserved)
> (XEN)  00000000badf4000 - 00000000badf6000 (usable)
> (XEN)  00000000badf6000 - 00000000bae06000 (reserved)
> (XEN)  00000000bae06000 - 00000000bae14000 (ACPI NVS)
> (XEN)  00000000bae14000 - 00000000bae3c000 (reserved)
> (XEN)  00000000bae3c000 - 00000000bae7f000 (ACPI NVS)
> (XEN)  00000000bae7f000 - 00000000bb000000 (usable)
> (XEN)  00000000bb800000 - 00000000bfa00000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 000000023fe00000 (usable)
> (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
> (XEN) ACPI: XSDT BADC9068, 0054 (r1 ALASKA    A M I  1072009 AMI     10013)
> (XEN)  PROC        1 MSFT  3000001)
> (XEN) ACPI: MCFG BADD0580, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
> (XEN) ACPI: HPET BADD05C0, 0038 (r1 ALASKA    A M I  1072009 AMI.        4)
> (XEN) ACPI: ASF! BADD05F8, 00A0 (r32 INTEL       HCG        1 TFSM    F4240)
> (XEN) System RAM: 8104MB (8299140kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-000000023fe00000
> (XEN) Domain heap initialised
> (XEN) found SMP MP-table at 000fcde0
> (XEN) DMI 2.7 present.
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x408
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
> (XEN) ACPI: 32/64X FACS address mismatch in FADT - bae0bf80/0000000000000000, using 32
> (XEN) ACPI:                  wakeup_vec[bae0bf8c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 6:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> (XEN) Processor #2 6:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
> (XEN) Processor #1 6:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> (XEN) Processor #3 6:10 APIC version 21
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ2 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> (XEN) PCI: Not using MMCONFIG.
> (XEN) Table is not found!
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Initializing CPU#0
> (XEN) Detected 3093.067 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 0
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 256K
> (XEN) CPU: L3 cache: 3072K
> (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
> (XEN) CPU0: Thermal monitoring enabled (TM1)
> (XEN) Intel machine check reporting enabled
> (XEN) I/O virtualisation disabled
> (XEN) CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
> (XEN) Enabled directed EOI with ioapic_ack_old on!
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using old ACK method
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> (XEN) TSC deadline timer enabled
> (XEN) Platform timer is 14.318MHz HPET
> (XEN) Allocated console ring of 1048576 KiB.
> (XEN) VMX: Supported advanced features:
> (isation
> (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
> (XEN) Booting processor 1/1 eip 7c000
> (XEN) Initializing CPU#1
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 0
> (XEN) CPU: L1 I cache: 32K, L1 D
> (XEN) Initializing CPU#2
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 256K
> (XEN) CPU: L3 cache: 3072K
> (XEN) CPU2: Thermal monitoring enabled (TM1)
> (XEN) CPU2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
> (XEN) Booting processor 3/3 eip 7c000
> (XEN) Initializing CPU#3
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CPU: L1 I cache: 32K, L1 D100 CPU @ 3.10GHz stepping 07
> (XEN) Brought up 4 CPUs
> (XEN) ACPI sleep modes: S3
> (XEN) mcheck_poll: Machine check polling timer started.
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x9e0000
> (XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xa60f0
> (XEN): paddr=0x1abc000 memsz=0x61b000
> (XEN) elf_parse_binary: memory: 0x1000000 -> 0x20d7000
> (XEN) elf_xen_parse_note: GUEST_OS = "linux"
> (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
> (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
> (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
> (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81abc1e0
> (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
> (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
> (XEN) elf_xen_parse_note: PAE_MODE = "yes"
> (XEN) elf_xen_parse_note: LOADER = "generic"
> (XEN) elf_xen_parse_note: unknown xen elf note (0xd)
> (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
> (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
> (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
> (XEN) elf_xen_addr_calc_check: addresses:
> (XEN)     virt_base        = 0xffffffff80000000
> (XEN)     elf_paddr_offset = 0x0
> (XEN)     virt_offset      = 0xffffffff80000000
> (XEN)     virt_kstart      = 0xffffffff81000000
> (XEN)     virt_kend        = 0xffffffff820d7000
> (XEN)     virt_entry       = 0xffffffff81abc1e0
> (XEN)     p2m_base         = 0xffffffffffffffff
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20d7000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (1661249 pages to be allocated)
> (XEN)  Init. ramdisk: 000000022cbdc000->000000023fe00000
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: ffffffff81000000->ffffffff820d7000
> (XEN)  Init. ramdisk: ffffffff820d7000->ffffffff952fb000
> (XEN)  Phys-Mach map: ffffffff952fb000->ffffffff96060b28
> (XEN)  Start info:    ffffffff96061000->ffffffff960614b4
> (XEN)  Page tables:   ffffffff96062000->ffffffff96117000
> (XEN)  Boot stack:    ffffffff96117000->ffffffff96118000
> (XEN)  TOTAL:         ffffffff80000000->ffffffff96400000
> (XEN)  ENTRY ADDRESS: ffffffff81abc1e0
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff819e0000
> (XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81aa60f0
> (XEN) elf_load_binary: phdr 2 at 0xffffffff81aa7000 -> 0xffffffff81abbbc0
> (XEN) elf_load_binary: phdr 3 at 0xffffffff81abc000 -> 0xffffffff81baf000
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) ***************************intended to aid debugging of Xen by ensuring
> (XEN) ******* that all output is synchronously delivered on the serial line.
> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
> (XEN) ******* timekeeping. It is NOT recommended for production use!
> (XEN) **********************************************
> (XEN) 3... 2... 1...
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) Freed 224kB init memory.
> mapping kernel into physical memory
> about to get started...
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.8.0upstream-06471-g2ef14f4-dirty (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 11:36:48 EST 2013
> [    0.000000] Command line: initcall_debug debug console=hvc0 loglevel=10 xen-pciback.hide=(01:00.0) earlyprintk=xen
> [    0.000000] Freeing 9e-100 pfn range: 98 pages freed
> [    0.000000] 1-1 mapping on 9e->100
> [    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
> [    0.000000] 1-1 mapping on 20000->20200
> [    0.000000] Freeing 40000-40200 pfn range: 512 pages freed
> [    0.000000] 1-1 mapping on 40000->40200
> [    0.000000] Freeing bad80-badf4 pfn range: 116 pages freed
> [    0.000000] 1-1 mapping on bad80->badf4
> [    0.000000] Freeing badf6-bae7f pfn range: 137 pages freed
> [    0.000000] 1-1 mapping on badf6->bae7f
> [    0.000000] Freeing bb000-100000 pfn range: 282624 pages freed
> [    0.000000] 1-1 mapping on bb000->100000
> [    0.000000] Released 283999 pages of unused memory
> [    0.000000] Set 283999 page(s) to 1-1 mapping
> [    0.000000] Populating 1acb65-1f20c4 pfn range: 283999 pages added
> [    0.000000] e820: BIOS-provided physical RAM map:
> [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
> [    0.000000] Xen: [mem 0x000000000009ec00-0x00000000000fffff] reserved
> [    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
> [    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
> [    0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable
> [    0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved
> [    0.000000] Xen: [mem 0x0000000040200000-0x00000000bad7ffff] usable
> [    0.000000] Xen: [mem 0x00000000bad80000-0x00000000badc8fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000badc9000-0x00000000badd0fff] ACPI data
> [    0.000000] Xen: [mem 0x00000000badd1000-0x00000000badf3fff] reserved
> [    0.000000] Xen: [mem 0x00000000badf4000-0x00000000badf5fff] usable
> [    0.000000] Xen: [mem 0x00000000badf6000-0x00000000bae05fff] reserved
> [    0.000000] Xen: [mem 0x00000000bae06000-0x00000000bae13fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000bae14000-0x00000000bae3bfff] reserved
> [    0.000000] Xen: [mem 0x00000000bae3c000-0x00000000bae7efff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000bae7f000-0x00000000baffffff] usable
> [    0.000000] Xen: [mem 0x00000000bb800000-0x00000000bf9fffff] reserved
> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [    0.000000] Xen: [mem 0x0000000100000000-0x000000023fdfffff] usable
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] SMBIOS 2.7 present.
> [    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
> [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> [    0.000000] No AGP bridge found
> [    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
> [    0.000000] e820: lacanning 1 areas for low memory corruption
> [    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
> [    0.000000] reserving inaccessible SNB gfx pages
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
> [    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
> [    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
> [    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
> [    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
> [    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
> [    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
> [    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
> [    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
> [    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
> [    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
> [    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
> [    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
> [    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
> [    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
> [    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
> [    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
> [    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
> [    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
> [    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k

so init_memory_mapping are all done.

> (XEN) d0:v0: unhandled page fault (ec=0000)
> (XEN) Pagetable walk from ffffea000005b2d0:
> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[<ffffffff8103feba>]
> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
> (XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
> (XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> (XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
> (XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
> (XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
> (XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
> (XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
> (XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
> (XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
> (XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
> (XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
> (XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
> (XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

can we get kernel trace instead?

>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:16:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8xAM-0001wE-07; Fri, 22 Feb 2013 18:16:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U8x3X-0001QT-8A
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:09:11 +0000
Received: from [193.109.254.147:53770] by server-6.bemta-14.messagelabs.com id
	99/06-12010-644B7215; Fri, 22 Feb 2013 18:09:10 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361556503!8786865!1
X-Originating-IP: [209.85.210.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14723 invoked from network); 22 Feb 2013 18:08:24 -0000
Received: from mail-ia0-f170.google.com (HELO mail-ia0-f170.google.com)
	(209.85.210.170)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:08:24 -0000
Received: by mail-ia0-f170.google.com with SMTP id k20so787091iak.15
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 10:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=yHadZE0k7RbMizTRu9CY5ebriUWS+mgnLnMobvPY34Y=;
	b=iHTqeVkY2skJySmHE1c6XP+510F6hYrMFWoB/3/jwOLpNDxK6yaz6hzaHtllfs65KU
	8+/k8OiKf/KZuPjBhxRtLmiLKFSvZEw9SuBbld9A9hriPmt/eGHnyl8UgOAw3fwFJTag
	ztzAFOYLRT4hvaHVEfdfU3+k6LL70Eh7M5gZaiAhuMTgIYxe8AhW7WC+16pzCYzfT46t
	EIs/DDhjnokSIKbZ1c+r3V+TOfpo6ml8Uc6y80I6MYiPwzUXEGkP0xcRfzetB/ji9xBO
	ZFYDQqDYMisftU/usGmZenD6waO/zW1KykhNoqIoPQrs6/oE5c3eZjsG+Tsb+FXEfcv5
	VEdw==
MIME-Version: 1.0
X-Received: by 10.50.186.165 with SMTP id fl5mr27295igc.81.1361556502652; Fri,
	22 Feb 2013 10:08:22 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 10:08:22 -0800 (PST)
In-Reply-To: <20130222173805.GC7768@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
Date: Fri, 22 Feb 2013 10:08:22 -0800
X-Google-Sender-Auth: dLxEIz2E_oiR6OplMiNFNvUZ4uo
Message-ID: <CAE9FiQXWyD_Fe_6OnLg13ReANM=43J76BFif9obLjBHtzzY8Ew@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:16:12 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 9:38 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
>> On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>> >
>> >What is bizzare is that I do recall testing this (and Stefano also did it).
>> >So I am not sure what has altered.
>> >
>>
>> Yes, there was a very specific reason why I wanted you guys to test it...
>
> Exactly. And I re-ran the same test, but with a new kernel. This is what
> git reflog tells me:
>
> 473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
> 08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
> eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
> [konrad@build linux]$ git show 08f321e
> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
> Author: Yinghai Lu <yinghai@kernel.org>
> Date:   Thu Nov 8 00:00:19 2012 -0800
>
>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
>
> And I recall Stefano later on testing (I was in a conference and did not have
> the opportunity to test it). Not sure what he ran with.

the commit in tip and linus tree have different hash...

commit 600cc5b7f6371706679490d7ee108015ae57ac2f
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Nov 16 19:39:22 2012 -0800

    mm: Kill NO_BOOTMEM version free_all_bootmem_node()

    Now NO_BOOTMEM version free_all_bootmem_node() does not really
    do free_bootmem at all, and it only call register_page_bootmem_info_node
    for online nodes instead.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:16:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8xAM-0001wE-07; Fri, 22 Feb 2013 18:16:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U8x3X-0001QT-8A
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:09:11 +0000
Received: from [193.109.254.147:53770] by server-6.bemta-14.messagelabs.com id
	99/06-12010-644B7215; Fri, 22 Feb 2013 18:09:10 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361556503!8786865!1
X-Originating-IP: [209.85.210.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14723 invoked from network); 22 Feb 2013 18:08:24 -0000
Received: from mail-ia0-f170.google.com (HELO mail-ia0-f170.google.com)
	(209.85.210.170)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:08:24 -0000
Received: by mail-ia0-f170.google.com with SMTP id k20so787091iak.15
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 10:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=yHadZE0k7RbMizTRu9CY5ebriUWS+mgnLnMobvPY34Y=;
	b=iHTqeVkY2skJySmHE1c6XP+510F6hYrMFWoB/3/jwOLpNDxK6yaz6hzaHtllfs65KU
	8+/k8OiKf/KZuPjBhxRtLmiLKFSvZEw9SuBbld9A9hriPmt/eGHnyl8UgOAw3fwFJTag
	ztzAFOYLRT4hvaHVEfdfU3+k6LL70Eh7M5gZaiAhuMTgIYxe8AhW7WC+16pzCYzfT46t
	EIs/DDhjnokSIKbZ1c+r3V+TOfpo6ml8Uc6y80I6MYiPwzUXEGkP0xcRfzetB/ji9xBO
	ZFYDQqDYMisftU/usGmZenD6waO/zW1KykhNoqIoPQrs6/oE5c3eZjsG+Tsb+FXEfcv5
	VEdw==
MIME-Version: 1.0
X-Received: by 10.50.186.165 with SMTP id fl5mr27295igc.81.1361556502652; Fri,
	22 Feb 2013 10:08:22 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 10:08:22 -0800 (PST)
In-Reply-To: <20130222173805.GC7768@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
Date: Fri, 22 Feb 2013 10:08:22 -0800
X-Google-Sender-Auth: dLxEIz2E_oiR6OplMiNFNvUZ4uo
Message-ID: <CAE9FiQXWyD_Fe_6OnLg13ReANM=43J76BFif9obLjBHtzzY8Ew@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:16:12 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 9:38 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
>> On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>> >
>> >What is bizzare is that I do recall testing this (and Stefano also did it).
>> >So I am not sure what has altered.
>> >
>>
>> Yes, there was a very specific reason why I wanted you guys to test it...
>
> Exactly. And I re-ran the same test, but with a new kernel. This is what
> git reflog tells me:
>
> 473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
> 08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
> eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
> [konrad@build linux]$ git show 08f321e
> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
> Author: Yinghai Lu <yinghai@kernel.org>
> Date:   Thu Nov 8 00:00:19 2012 -0800
>
>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
>
> And I recall Stefano later on testing (I was in a conference and did not have
> the opportunity to test it). Not sure what he ran with.

the commit in tip and linus tree have different hash...

commit 600cc5b7f6371706679490d7ee108015ae57ac2f
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Nov 16 19:39:22 2012 -0800

    mm: Kill NO_BOOTMEM version free_all_bootmem_node()

    Now NO_BOOTMEM version free_all_bootmem_node() does not really
    do free_bootmem at all, and it only call register_page_bootmem_info_node
    for online nodes instead.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:26:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:26: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 1U8xJk-0002WH-KD; Fri, 22 Feb 2013 18:25:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U8xHF-0002Un-4h
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:23:21 +0000
Received: from [85.158.139.83:2562] by server-6.bemta-5.messagelabs.com id
	F1/18-01489-797B7215; Fri, 22 Feb 2013 18:23:19 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361557379!28532187!1
X-Originating-IP: [209.85.223.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8103 invoked from network); 22 Feb 2013 18:23:01 -0000
Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com)
	(209.85.223.174)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:23:01 -0000
Received: by mail-ie0-f174.google.com with SMTP id k10so1056070iea.5
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 10:22:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=eawHSTBHCwjL2bRkJUFYFi1yDzmmlhlZR4+sK0dg5So=;
	b=GlP0/wJrAcIExv+bUMErz+l/wB39q9/qwScD0qOtLtJ7+l37Y2jM1eeMcyfdxPygnA
	/HBRB2eKwVJXggk5wPs4wugdvciOfBAbf75fZuMDTurbFDfZSjbQPzW4i27yGUqqAYDB
	yTQONC5plr4vYPhVf+qLfNasfcijDYp7kjGyD1+eitwxU44t523zjfVzNTHuTX7DM2ye
	B/fMPSBAnoYhnj0ImcC0YUr0aKl/vNNuslANNiD1SLKizl3T7a1RZ/V2vRhGHZykbZ+X
	oRmjF4xyCzU1Tk9oqVfzK4NnlvFAnhGDyvMLW8+BJnGOA9/53IrHAK/MySSNnQm5Sim+
	6KYA==
MIME-Version: 1.0
X-Received: by 10.50.186.165 with SMTP id fl5mr46888igc.81.1361557379147; Fri,
	22 Feb 2013 10:22:59 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 10:22:59 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
	<alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
Date: Fri, 22 Feb 2013 10:22:59 -0800
X-Google-Sender-Auth: OfM_9rT84W15D603mqOA0AtPjYI
Message-ID: <CAE9FiQV8U-7rZZU4Uj_3MVRZiFeq3uEW0ErmCuy1m8AE55gxfw@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:25:55 +0000
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"mst@redhat.com" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
	Rob Landley <rob@landley.net>, Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 10:06 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
>> > On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>> > >
>> > >What is bizzare is that I do recall testing this (and Stefano also did it).
>> > >So I am not sure what has altered.
>> > >
>> >
>> > Yes, there was a very specific reason why I wanted you guys to test it...
>>
>> Exactly. And I re-ran the same test, but with a new kernel. This is what
>> git reflog tells me:
>>
>> 473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
>> 08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
>> eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
>> [konrad@build linux]$ git show 08f321e
>> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
>> Author: Yinghai Lu <yinghai@kernel.org>
>> Date:   Thu Nov 8 00:00:19 2012 -0800
>>
>>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
>>
>> And I recall Stefano later on testing (I was in a conference and did not have
>> the opportunity to test it). Not sure what he ran with.
>>
>
> FYI the last patch series I tested was Yinghai's "x86, boot, 64bit: Add
> support for loading ramdisk and bzImage above 4G" v7u1.


the one in tip and linus's tree is
---
-v7u2: update changelog and comments, and clear more fields for sentinel.
     Update swiotlb autoswitch off patch.
     Fix crash with xen PV guest with 2G.
---

and it fixes xen crash that you reported with v7u1, and you tested
that add-on patch
fix_xen_2g.patch with v7u1.
and I fold the addon patch into offending patch in v7u2.


Thanks

Yinghai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:26:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:26: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 1U8xJk-0002WH-KD; Fri, 22 Feb 2013 18:25:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U8xHF-0002Un-4h
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:23:21 +0000
Received: from [85.158.139.83:2562] by server-6.bemta-5.messagelabs.com id
	F1/18-01489-797B7215; Fri, 22 Feb 2013 18:23:19 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361557379!28532187!1
X-Originating-IP: [209.85.223.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8103 invoked from network); 22 Feb 2013 18:23:01 -0000
Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com)
	(209.85.223.174)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:23:01 -0000
Received: by mail-ie0-f174.google.com with SMTP id k10so1056070iea.5
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 10:22:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=eawHSTBHCwjL2bRkJUFYFi1yDzmmlhlZR4+sK0dg5So=;
	b=GlP0/wJrAcIExv+bUMErz+l/wB39q9/qwScD0qOtLtJ7+l37Y2jM1eeMcyfdxPygnA
	/HBRB2eKwVJXggk5wPs4wugdvciOfBAbf75fZuMDTurbFDfZSjbQPzW4i27yGUqqAYDB
	yTQONC5plr4vYPhVf+qLfNasfcijDYp7kjGyD1+eitwxU44t523zjfVzNTHuTX7DM2ye
	B/fMPSBAnoYhnj0ImcC0YUr0aKl/vNNuslANNiD1SLKizl3T7a1RZ/V2vRhGHZykbZ+X
	oRmjF4xyCzU1Tk9oqVfzK4NnlvFAnhGDyvMLW8+BJnGOA9/53IrHAK/MySSNnQm5Sim+
	6KYA==
MIME-Version: 1.0
X-Received: by 10.50.186.165 with SMTP id fl5mr46888igc.81.1361557379147; Fri,
	22 Feb 2013 10:22:59 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 10:22:59 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
	<alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
Date: Fri, 22 Feb 2013 10:22:59 -0800
X-Google-Sender-Auth: OfM_9rT84W15D603mqOA0AtPjYI
Message-ID: <CAE9FiQV8U-7rZZU4Uj_3MVRZiFeq3uEW0ErmCuy1m8AE55gxfw@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:25:55 +0000
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>, Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"mst@redhat.com" <mst@redhat.com>, Eric Biederman <ebiederm@xmission.com>,
	Rob Landley <rob@landley.net>, Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 10:06 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
>> > On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>> > >
>> > >What is bizzare is that I do recall testing this (and Stefano also did it).
>> > >So I am not sure what has altered.
>> > >
>> >
>> > Yes, there was a very specific reason why I wanted you guys to test it...
>>
>> Exactly. And I re-ran the same test, but with a new kernel. This is what
>> git reflog tells me:
>>
>> 473cd24 HEAD@{75}: checkout: moving from 08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
>> 08f321e HEAD@{76}: checkout: moving from linux-next to yinghai/for-x86-mm
>> eb827a7 HEAD@{77}: checkout: moving from 1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
>> [konrad@build linux]$ git show 08f321e
>> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
>> Author: Yinghai Lu <yinghai@kernel.org>
>> Date:   Thu Nov 8 00:00:19 2012 -0800
>>
>>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
>>
>> And I recall Stefano later on testing (I was in a conference and did not have
>> the opportunity to test it). Not sure what he ran with.
>>
>
> FYI the last patch series I tested was Yinghai's "x86, boot, 64bit: Add
> support for loading ramdisk and bzImage above 4G" v7u1.


the one in tip and linus's tree is
---
-v7u2: update changelog and comments, and clear more fields for sentinel.
     Update swiotlb autoswitch off patch.
     Fix crash with xen PV guest with 2G.
---

and it fixes xen crash that you reported with v7u1, and you tested
that add-on patch
fix_xen_2g.patch with v7u1.
and I fold the addon patch into offending patch in v7u2.


Thanks

Yinghai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:26:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:26: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 1U8xJs-0002Wf-0v; Fri, 22 Feb 2013 18:26:04 +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 1U8xIn-0002VZ-OI
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:24:58 +0000
Received: from [85.158.137.99:23539] by server-16.bemta-3.messagelabs.com id
	80/10-02727-4F7B7215; Fri, 22 Feb 2013 18:24:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361557490!17476276!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28842 invoked from network); 22 Feb 2013 18:24:52 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 18:24:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MINTKq002870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 18:23:30 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
	r1MINRdU002118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 18:23:28 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
	r1MINRNv001337; Fri, 22 Feb 2013 12:23:27 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 10:23:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 099CB1C3935; Fri, 22 Feb 2013 13:23:22 -0500 (EST)
Date: Fri, 22 Feb 2013 13:23:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Yinghai Lu <yinghai@kernel.org>
Message-ID: <20130222182321.GA11311@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
	<CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:26:02 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > [    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
> > [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> > [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> > [    0.000000] No AGP bridge found
> > [    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
> > [    0.000000] e820: lacanning 1 areas for low memory corruption
> > [    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
> > [    0.000000] reserving inaccessible SNB gfx pages
> > [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> > [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
> > [    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
> > [    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
> > [    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
> > [    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
> > [    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
> > [    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
> > [    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
> > [    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
> > [    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
> > [    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
> > [    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
> > [    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
> > [    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
> > [    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
> > [    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
> > [    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
> > [    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k
> 
> so init_memory_mapping are all done.

Not so.
> 
> > (XEN) d0:v0: unhandled page fault (ec=0000)
> > (XEN) Pagetable walk from ffffea000005b2d0:
> > (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
> > (XEN) domain_crash_sync called from entry.S
> > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > (XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
> > (XEN) CPU:    0
> > (XEN) RIP:    e033:[<ffffffff8103feba>]
> > (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
> > (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
> > (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
> > (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
> > (XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
> > (XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
> > (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
> > (XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> > (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> > (XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
> > (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
> > (XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
> > (XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
> > (XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
> > (XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
> > (XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
> > (XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
> > (XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
> > (XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
> > (XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
> > (XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
> > (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> can we get kernel trace instead?

If you look at the initial one I had posted:

> >> Call Trace:
> >>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
> >>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a
> >>   [<ffffffff81042d27>] xen_write_cr3+0x77
> >>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
> >>   [<ffffffff81ac293f>] setup_arch+0x742
> >>   [<ffffffff81666d71>] printk+0x48
> >>   [<ffffffff81abcd62>] start_kernel+0x90
> >>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
> >>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
> >>   [<ffffffff81abf0c7>] xen_start_kernel+0x564

The EIP matches with what this stack strace has. So we are still in
init_mem_mapping.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:26:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:26: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 1U8xJs-0002Wf-0v; Fri, 22 Feb 2013 18:26:04 +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 1U8xIn-0002VZ-OI
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:24:58 +0000
Received: from [85.158.137.99:23539] by server-16.bemta-3.messagelabs.com id
	80/10-02727-4F7B7215; Fri, 22 Feb 2013 18:24:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361557490!17476276!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28842 invoked from network); 22 Feb 2013 18:24:52 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 18:24:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MINTKq002870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 18:23:30 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
	r1MINRdU002118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 18:23:28 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
	r1MINRNv001337; Fri, 22 Feb 2013 12:23:27 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 10:23:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 099CB1C3935; Fri, 22 Feb 2013 13:23:22 -0500 (EST)
Date: Fri, 22 Feb 2013 13:23:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Yinghai Lu <yinghai@kernel.org>
Message-ID: <20130222182321.GA11311@phenom.dumpdata.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
	<CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:26:02 +0000
Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, "H. J. Lu" <hjl.tools@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	virtualization@lists.linux-foundation.org,
	Gokul Caushik <caushik1@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>, Pavel Machek <pavel@ucw.cz>,
	"H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>, xen-devel@lists.xensource.com,
	Russell King <linux@arm.linux.org.uk>,
	Len Brown <len.brown@intel.com>, Joerg Roedel <joro@8bytes.org>,
	linux-pm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	avi@redhat.com, Alexander Duyck <alexander.h.duyck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Matt Fleming <matt.fleming@intel.com>, Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Zachary Amsden <zamsden@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable@vger.kernel.org, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>, mst@redhat.com,
	Eric Biederman <ebiederm@xmission.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > [    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
> > [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> > [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> > [    0.000000] No AGP bridge found
> > [    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
> > [    0.000000] e820: lacanning 1 areas for low memory corruption
> > [    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
> > [    0.000000] reserving inaccessible SNB gfx pages
> > [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> > [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
> > [    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
> > [    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
> > [    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
> > [    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
> > [    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
> > [    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
> > [    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
> > [    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
> > [    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
> > [    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
> > [    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
> > [    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
> > [    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
> > [    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
> > [    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
> > [    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
> > [    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
> > [    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k
> 
> so init_memory_mapping are all done.

Not so.
> 
> > (XEN) d0:v0: unhandled page fault (ec=0000)
> > (XEN) Pagetable walk from ffffea000005b2d0:
> > (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
> > (XEN) domain_crash_sync called from entry.S
> > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > (XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
> > (XEN) CPU:    0
> > (XEN) RIP:    e033:[<ffffffff8103feba>]
> > (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
> > (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
> > (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
> > (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
> > (XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
> > (XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
> > (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
> > (XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> > (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> > (XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
> > (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
> > (XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
> > (XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
> > (XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
> > (XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
> > (XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
> > (XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
> > (XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
> > (XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
> > (XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
> > (XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
> > (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> can we get kernel trace instead?

If you look at the initial one I had posted:

> >> Call Trace:
> >>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
> >>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a
> >>   [<ffffffff81042d27>] xen_write_cr3+0x77
> >>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
> >>   [<ffffffff81ac293f>] setup_arch+0x742
> >>   [<ffffffff81666d71>] printk+0x48
> >>   [<ffffffff81abcd62>] start_kernel+0x90
> >>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
> >>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
> >>   [<ffffffff81abf0c7>] xen_start_kernel+0x564

The EIP matches with what this stack strace has. So we are still in
init_mem_mapping.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:26:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8xJs-0002Wn-E8; Fri, 22 Feb 2013 18:26:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8xJg-0002Vy-Nb
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:25:53 +0000
Received: from [85.158.138.51:6597] by server-3.bemta-3.messagelabs.com id
	0B/00-31070-F28B7215; Fri, 22 Feb 2013 18:25:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361557549!28836346!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28101 invoked from network); 22 Feb 2013 18:25:50 -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;
	22 Feb 2013 18:25:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8635636"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 18:25:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 13:25:48 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8xJb-0006mv-CE;
	Fri, 22 Feb 2013 18:25:47 +0000
Message-ID: <5127B82A.3000506@citrix.com>
Date: Fri, 22 Feb 2013 18:25:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Yinghai Lu <yinghai@kernel.org>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
	<CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
In-Reply-To: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
X-Enigmail-Version: 1.4
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:26:01 +0000
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, Len Brown <len.brown@intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Pavel Machek <pavel@ucw.cz>, "H. Peter Anvin" <hpa@zytor.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Zachary Amsden <zamsden@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Hugh Dickins <hughd@google.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	"H. J. Lu" <hjl.tools@gmail.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J.
	Wysocki" <rjw@sisk.pl>, Daniel J Blueman <daniel@numascale-asia.com>,
	Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	Matt Fleming <matt.fleming@intel.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"mst@redhat.com" <mst@redhat.com>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 17:53, Yinghai Lu wrote:
> On Fri, Feb 22, 2013 at 9:24 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Fri, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
>>>> Hi Linus,
>>>>
>>>> This is a huge set of several partly interrelated (and concurrently
>>>> developed) changes, which is why the branch history is messier than
>>>> one would like.
>>>>
>>>> The *really* big items are two humonguous patchsets mostly developed
>>>> by Yinghai Lu at my request, which completely revamps the way we
>>>> create initial page tables.  In particular, rather than estimating how
>>>> much memory we will need for page tables and then build them into that
>>>> memory -- a calculation that has shown to be incredibly fragile -- we
>>>> now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
>>>> a #PF handler which creates temporary page tables on demand.
>>>>
>>>> This has several advantages:
>>>>
>>>> 1. It makes it much easier to support things that need access to
>>>>    data very early (a followon patchset uses this to load microcode
>>>>    way early in the kernel startup).
>>>>
>>>> 2. It allows the kernel and all the kernel data objects to be invoked
>>>>    from above the 4 GB limit.  This allows kdump to work on very large
>>>>    systems.
>>>>
>>>> 3. It greatly reduces the difference between Xen and native (Xen's
>>>>    equivalent of the #PF handler are the temporary page tables created
>>>>    by the domain builder), eliminating a bunch of fragile hooks.
>>>>
>>>> The patch series also gets us a bit closer to W^X.
>>>>
>>>> Additional work in this pull is the 64-bit get_user() work which you
>>>> were also involved with, and a bunch of cleanups/speedups to
>>>> __phys_addr()/__pa().
>>> Looking at figuring out which of the patches in the branch did this, but
>>> with this merge I am getting a crash with a very simple PV guest (booted with
>>> one 1G):
>>>
>>> Call Trace:
>>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a
>>>   [<ffffffff81042d27>] xen_write_cr3+0x77
>>>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
>>>   [<ffffffff81ac293f>] setup_arch+0x742
>>>   [<ffffffff81666d71>] printk+0x48
>>>   [<ffffffff81abcd62>] start_kernel+0x90
>>>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
>>>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
>>>   [<ffffffff81abf0c7>] xen_start_kernel+0x564
>>>
>>> And the hypervisor says:
>>> (XEN) d7:v0: unhandled page fault (ec=0000)
>>> (XEN) Pagetable walk from ffffea000005b2d0:
>>> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
>>> (XEN) domain_crash_sync called from entry.S
>>> (XEN) Domain 7 (vcpu#0) crashed on cpu#3:
>>> (XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
>>> (XEN) CPU:    3
>>> (XEN) RIP:    e033:[<ffffffff8103feba>]
>>> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
>>> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
>>> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
>>> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
>>> (XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
>>> (XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
>>> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
>>> (XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
>>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>>> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
>>> (XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
>>> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
>> Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
>> kernel with 8GB):
>>
>> PXELINUX 3.82 2009-06-09  Copyright (C) 1994-2009 H. Peter Anvin et al
>> boot:
>> Loading xen.gz... ok
>> Loading vmlinuz... ok
>> Loading initramfs.cpio.gz... ok
>>  __  __            _  _    _   ____
>>  \ \/ /___ _ __   | || |  / | | ___|    _ __  _ __ ___
>>   \  // _ \ '_(_)_(_)____/   | .__/|_|  \___|
>>                                        |_|
>> (XEN) Xen version 4.1.5-pre (konrad@dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) Fri Feb 22 11:37:00 EST 2013
>> (XEN) Latest ChangeSet: Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
>> (XEN) Console output is synchronous.
>> (XEN) Bootloader: unknown
>> (XEN) Command line: cpuinfo conring_size=1048576 sync_console cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all
>> (XEN) Video information:
>> (XEN)  VGA is text mode 80x25, font 8x16
>> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
>> (XEN)  EDID info not retrieved because no DDC retrieval method detected
>> (XEN) Disc information:
>> (XEN)  Found 1 MBR signatures
>> (XEN)  Found 1 EDD information structures
>> (XEN) Xen-e820 RAM map:
>> (XEN)  0000000000000000 - 000000000009ec00 (usable)
>> (XEN)  000000000009ec00 - 00000000000a0000 (reserved)
>> (XEN)  00000000000e0000 - 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)
>> (XEN)  00000000badc9000 - 00000000badd1000 (ACPI data)
>> (XEN)  00000000badd1000 - 00000000badf4000 (reserved)
>> (XEN)  00000000badf4000 - 00000000badf6000 (usable)
>> (XEN)  00000000badf6000 - 00000000bae06000 (reserved)
>> (XEN)  00000000bae06000 - 00000000bae14000 (ACPI NVS)
>> (XEN)  00000000bae14000 - 00000000bae3c000 (reserved)
>> (XEN)  00000000bae3c000 - 00000000bae7f000 (ACPI NVS)
>> (XEN)  00000000bae7f000 - 00000000bb000000 (usable)
>> (XEN)  00000000bb800000 - 00000000bfa00000 (reserved)
>> (XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
>> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
>> (XEN)  0000000100000000 - 000000023fe00000 (usable)
>> (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
>> (XEN) ACPI: XSDT BADC9068, 0054 (r1 ALASKA    A M I  1072009 AMI     10013)
>> (XEN)  PROC        1 MSFT  3000001)
>> (XEN) ACPI: MCFG BADD0580, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
>> (XEN) ACPI: HPET BADD05C0, 0038 (r1 ALASKA    A M I  1072009 AMI.        4)
>> (XEN) ACPI: ASF! BADD05F8, 00A0 (r32 INTEL       HCG        1 TFSM    F4240)
>> (XEN) System RAM: 8104MB (8299140kB)
>> (XEN) No NUMA configuration found
>> (XEN) Faking a node at 0000000000000000-000000023fe00000
>> (XEN) Domain heap initialised
>> (XEN) found SMP MP-table at 000fcde0
>> (XEN) DMI 2.7 present.
>> (XEN) Using APIC driver default
>> (XEN) ACPI: PM-Timer IO Port: 0x408
>> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
>> (XEN) ACPI: 32/64X FACS address mismatch in FADT - bae0bf80/0000000000000000, using 32
>> (XEN) ACPI:                  wakeup_vec[bae0bf8c], vec_size[20]
>> (XEN) ACPI: Local APIC address 0xfee00000
>> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>> (XEN) Processor #0 6:10 APIC version 21
>> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
>> (XEN) Processor #2 6:10 APIC version 21
>> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
>> (XEN) Processor #1 6:10 APIC version 21
>> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
>> (XEN) Processor #3 6:10 APIC version 21
>> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
>> (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
>> (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
>> (XEN) ACPI: IRQ0 used by override.
>> (XEN) ACPI: IRQ2 used by override.
>> (XEN) ACPI: IRQ9 used by override.
>> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
>> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
>> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
>> (XEN) PCI: Not using MMCONFIG.
>> (XEN) Table is not found!
>> (XEN) Using ACPI (MADT) for SMP configuration information
>> (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) Initializing CPU#0
>> (XEN) Detected 3093.067 MHz processor.
>> (XEN) Initing memory sharing.
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 0
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 256K
>> (XEN) CPU: L3 cache: 3072K
>> (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
>> (XEN) CPU0: Thermal monitoring enabled (TM1)
>> (XEN) Intel machine check reporting enabled
>> (XEN) I/O virtualisation disabled
>> (XEN) CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
>> (XEN) Enabled directed EOI with ioapic_ack_old on!
>> (XEN) ENABLING IO-APIC IRQs
>> (XEN)  -> Using old ACK method
>> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>> (XEN) TSC deadline timer enabled
>> (XEN) Platform timer is 14.318MHz HPET
>> (XEN) Allocated console ring of 1048576 KiB.
>> (XEN) VMX: Supported advanced features:
>> (isation
>> (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
>> (XEN) Booting processor 1/1 eip 7c000
>> (XEN) Initializing CPU#1
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 0
>> (XEN) CPU: L1 I cache: 32K, L1 D
>> (XEN) Initializing CPU#2
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 256K
>> (XEN) CPU: L3 cache: 3072K
>> (XEN) CPU2: Thermal monitoring enabled (TM1)
>> (XEN) CPU2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
>> (XEN) Booting processor 3/3 eip 7c000
>> (XEN) Initializing CPU#3
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CPU: L1 I cache: 32K, L1 D100 CPU @ 3.10GHz stepping 07
>> (XEN) Brought up 4 CPUs
>> (XEN) ACPI sleep modes: S3
>> (XEN) mcheck_poll: Machine check polling timer started.
>> (XEN) *** LOADING DOMAIN 0 ***
>> (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x9e0000
>> (XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xa60f0
>> (XEN): paddr=0x1abc000 memsz=0x61b000
>> (XEN) elf_parse_binary: memory: 0x1000000 -> 0x20d7000
>> (XEN) elf_xen_parse_note: GUEST_OS = "linux"
>> (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
>> (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
>> (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
>> (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81abc1e0
>> (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
>> (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
>> (XEN) elf_xen_parse_note: PAE_MODE = "yes"
>> (XEN) elf_xen_parse_note: LOADER = "generic"
>> (XEN) elf_xen_parse_note: unknown xen elf note (0xd)
>> (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
>> (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
>> (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
>> (XEN) elf_xen_addr_calc_check: addresses:
>> (XEN)     virt_base        = 0xffffffff80000000
>> (XEN)     elf_paddr_offset = 0x0
>> (XEN)     virt_offset      = 0xffffffff80000000
>> (XEN)     virt_kstart      = 0xffffffff81000000
>> (XEN)     virt_kend        = 0xffffffff820d7000
>> (XEN)     virt_entry       = 0xffffffff81abc1e0
>> (XEN)     p2m_base         = 0xffffffffffffffff
>> (XEN)  Xen  kernel: 64-bit, lsb, compat32
>> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20d7000
>> (XEN) PHYSICAL MEMORY ARRANGEMENT:
>> (XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (1661249 pages to be allocated)
>> (XEN)  Init. ramdisk: 000000022cbdc000->000000023fe00000
>> (XEN) VIRTUAL MEMORY ARRANGEMENT:
>> (XEN)  Loaded kernel: ffffffff81000000->ffffffff820d7000
>> (XEN)  Init. ramdisk: ffffffff820d7000->ffffffff952fb000
>> (XEN)  Phys-Mach map: ffffffff952fb000->ffffffff96060b28
>> (XEN)  Start info:    ffffffff96061000->ffffffff960614b4
>> (XEN)  Page tables:   ffffffff96062000->ffffffff96117000
>> (XEN)  Boot stack:    ffffffff96117000->ffffffff96118000
>> (XEN)  TOTAL:         ffffffff80000000->ffffffff96400000
>> (XEN)  ENTRY ADDRESS: ffffffff81abc1e0
>> (XEN) Dom0 has maximum 4 VCPUs
>> (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff819e0000
>> (XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81aa60f0
>> (XEN) elf_load_binary: phdr 2 at 0xffffffff81aa7000 -> 0xffffffff81abbbc0
>> (XEN) elf_load_binary: phdr 3 at 0xffffffff81abc000 -> 0xffffffff81baf000
>> (XEN) Scrubbing Free RAM: .done.
>> (XEN) Xen trace buffers: disabled
>> (XEN) Std. Loglevel: All
>> (XEN) Guest Loglevel: All
>> (XEN) ***************************intended to aid debugging of Xen by ensuring
>> (XEN) ******* that all output is synchronously delivered on the serial line.
>> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
>> (XEN) ******* timekeeping. It is NOT recommended for production use!
>> (XEN) **********************************************
>> (XEN) 3... 2... 1...
>> (XEN) Xen is relinquishing VGA console.
>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
>> (XEN) Freed 224kB init memory.
>> mapping kernel into physical memory
>> about to get started...
>> [    0.000000] Initializing cgroup subsys cpuset
>> [    0.000000] Initializing cgroup subsys cpu
>> [    0.000000] Linux version 3.8.0upstream-06471-g2ef14f4-dirty (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 11:36:48 EST 2013
>> [    0.000000] Command line: initcall_debug debug console=hvc0 loglevel=10 xen-pciback.hide=(01:00.0) earlyprintk=xen
>> [    0.000000] Freeing 9e-100 pfn range: 98 pages freed
>> [    0.000000] 1-1 mapping on 9e->100
>> [    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
>> [    0.000000] 1-1 mapping on 20000->20200
>> [    0.000000] Freeing 40000-40200 pfn range: 512 pages freed
>> [    0.000000] 1-1 mapping on 40000->40200
>> [    0.000000] Freeing bad80-badf4 pfn range: 116 pages freed
>> [    0.000000] 1-1 mapping on bad80->badf4
>> [    0.000000] Freeing badf6-bae7f pfn range: 137 pages freed
>> [    0.000000] 1-1 mapping on badf6->bae7f
>> [    0.000000] Freeing bb000-100000 pfn range: 282624 pages freed
>> [    0.000000] 1-1 mapping on bb000->100000
>> [    0.000000] Released 283999 pages of unused memory
>> [    0.000000] Set 283999 page(s) to 1-1 mapping
>> [    0.000000] Populating 1acb65-1f20c4 pfn range: 283999 pages added
>> [    0.000000] e820: BIOS-provided physical RAM map:
>> [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
>> [    0.000000] Xen: [mem 0x000000000009ec00-0x00000000000fffff] reserved
>> [    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
>> [    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
>> [    0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable
>> [    0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved
>> [    0.000000] Xen: [mem 0x0000000040200000-0x00000000bad7ffff] usable
>> [    0.000000] Xen: [mem 0x00000000bad80000-0x00000000badc8fff] ACPI NVS
>> [    0.000000] Xen: [mem 0x00000000badc9000-0x00000000badd0fff] ACPI data
>> [    0.000000] Xen: [mem 0x00000000badd1000-0x00000000badf3fff] reserved
>> [    0.000000] Xen: [mem 0x00000000badf4000-0x00000000badf5fff] usable
>> [    0.000000] Xen: [mem 0x00000000badf6000-0x00000000bae05fff] reserved
>> [    0.000000] Xen: [mem 0x00000000bae06000-0x00000000bae13fff] ACPI NVS
>> [    0.000000] Xen: [mem 0x00000000bae14000-0x00000000bae3bfff] reserved
>> [    0.000000] Xen: [mem 0x00000000bae3c000-0x00000000bae7efff] ACPI NVS
>> [    0.000000] Xen: [mem 0x00000000bae7f000-0x00000000baffffff] usable
>> [    0.000000] Xen: [mem 0x00000000bb800000-0x00000000bf9fffff] reserved
>> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
>> [    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
>> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
>> [    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
>> [    0.000000] Xen: [mem 0x0000000100000000-0x000000023fdfffff] usable
>> [    0.000000] bootconsole [xenboot0] enabled
>> [    0.000000] NX (Execute Disable) protection: active
>> [    0.000000] SMBIOS 2.7 present.
>> [    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
>> [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
>> [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
>> [    0.000000] No AGP bridge found
>> [    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
>> [    0.000000] e820: lacanning 1 areas for low memory corruption
>> [    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
>> [    0.000000] reserving inaccessible SNB gfx pages
>> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
>> [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
>> [    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
>> [    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
>> [    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
>> [    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
>> [    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
>> [    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
>> [    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
>> [    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
>> [    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
>> [    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
>> [    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
>> [    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
>> [    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
>> [    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
>> [    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
>> [    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
>> [    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k
> so init_memory_mapping are all done.
>
>> (XEN) d0:v0: unhandled page fault (ec=0000)
>> (XEN) Pagetable walk from ffffea000005b2d0:
>> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    e033:[<ffffffff8103feba>]
>> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
>> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
>> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
>> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
>> (XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
>> (XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
>> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
>> (XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
>> (XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
>> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
>> (XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
>> (XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
>> (XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
>> (XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
>> (XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
>> (XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
>> (XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
>> (XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
>> (XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
>> (XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
>> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> can we get kernel trace instead?

(XEN) d0:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea000005b2d0:
(XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S

This means that Xen was unable to context switch back to dom0

The value in rax looks suspiciously related to the faulting address in cr2.

Konrad: is the instruction at ffffffff8103feba possibly a rax-relative
dereference?

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 22 18:26:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 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 1U8xJs-0002Wn-E8; Fri, 22 Feb 2013 18:26:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1U8xJg-0002Vy-Nb
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:25:53 +0000
Received: from [85.158.138.51:6597] by server-3.bemta-3.messagelabs.com id
	0B/00-31070-F28B7215; Fri, 22 Feb 2013 18:25:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361557549!28836346!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM1NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28101 invoked from network); 22 Feb 2013 18:25:50 -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;
	22 Feb 2013 18:25:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="8635636"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	22 Feb 2013 18:25:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Fri, 22 Feb 2013 13:25:48 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1U8xJb-0006mv-CE;
	Fri, 22 Feb 2013 18:25:47 +0000
Message-ID: <5127B82A.3000506@citrix.com>
Date: Fri, 22 Feb 2013 18:25:46 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Yinghai Lu <yinghai@kernel.org>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<20130222172403.GA17056@phenom.dumpdata.com>
	<CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
In-Reply-To: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
X-Enigmail-Version: 1.4
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:26:01 +0000
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Gleb Natapov <gleb@redhat.com>, Len Brown <len.brown@intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Joe Millenbach <jmillenbach@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Gokul Caushik <caushik1@gmail.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Pavel Machek <pavel@ucw.cz>, "H. Peter Anvin" <hpa@zytor.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King <linux@arm.linux.org.uk>, Zachary Amsden <zamsden@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Hugh Dickins <hughd@google.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>, Paul Turner <pjt@google.com>,
	"avi@redhat.com" <avi@redhat.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	"H. J. Lu" <hjl.tools@gmail.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Jamie Lokier <jamie@shareable.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>, "Rafael J.
	Wysocki" <rjw@sisk.pl>, Daniel J Blueman <daniel@numascale-asia.com>,
	Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Shuah Khan <shuah.khan@hp.com>, Thomas Gleixner <tglx@linutronix.de>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	Matt Fleming <matt.fleming@intel.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Jacob Shin <jacob.shin@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"mst@redhat.com" <mst@redhat.com>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>, Rob Landley <rob@landley.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>, Shuah Khan <shuahkhan@gmail.com>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 17:53, Yinghai Lu wrote:
> On Fri, Feb 22, 2013 at 9:24 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Fri, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
>>>> Hi Linus,
>>>>
>>>> This is a huge set of several partly interrelated (and concurrently
>>>> developed) changes, which is why the branch history is messier than
>>>> one would like.
>>>>
>>>> The *really* big items are two humonguous patchsets mostly developed
>>>> by Yinghai Lu at my request, which completely revamps the way we
>>>> create initial page tables.  In particular, rather than estimating how
>>>> much memory we will need for page tables and then build them into that
>>>> memory -- a calculation that has shown to be incredibly fragile -- we
>>>> now build them (on 64 bits) with the aid of a "pseudo-linear mode" --
>>>> a #PF handler which creates temporary page tables on demand.
>>>>
>>>> This has several advantages:
>>>>
>>>> 1. It makes it much easier to support things that need access to
>>>>    data very early (a followon patchset uses this to load microcode
>>>>    way early in the kernel startup).
>>>>
>>>> 2. It allows the kernel and all the kernel data objects to be invoked
>>>>    from above the 4 GB limit.  This allows kdump to work on very large
>>>>    systems.
>>>>
>>>> 3. It greatly reduces the difference between Xen and native (Xen's
>>>>    equivalent of the #PF handler are the temporary page tables created
>>>>    by the domain builder), eliminating a bunch of fragile hooks.
>>>>
>>>> The patch series also gets us a bit closer to W^X.
>>>>
>>>> Additional work in this pull is the 64-bit get_user() work which you
>>>> were also involved with, and a bunch of cleanups/speedups to
>>>> __phys_addr()/__pa().
>>> Looking at figuring out which of the patches in the branch did this, but
>>> with this merge I am getting a crash with a very simple PV guest (booted with
>>> one 1G):
>>>
>>> Call Trace:
>>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a  <--
>>>   [<ffffffff8103feba>] xen_get_user_pgd+0x5a
>>>   [<ffffffff81042d27>] xen_write_cr3+0x77
>>>   [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
>>>   [<ffffffff81ac293f>] setup_arch+0x742
>>>   [<ffffffff81666d71>] printk+0x48
>>>   [<ffffffff81abcd62>] start_kernel+0x90
>>>   [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
>>>   [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
>>>   [<ffffffff81abf0c7>] xen_start_kernel+0x564
>>>
>>> And the hypervisor says:
>>> (XEN) d7:v0: unhandled page fault (ec=0000)
>>> (XEN) Pagetable walk from ffffea000005b2d0:
>>> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
>>> (XEN) domain_crash_sync called from entry.S
>>> (XEN) Domain 7 (vcpu#0) crashed on cpu#3:
>>> (XEN) ----[ Xen-4.2.0  x86_64  debug=n  Not tainted ]----
>>> (XEN) CPU:    3
>>> (XEN) RIP:    e033:[<ffffffff8103feba>]
>>> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
>>> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
>>> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
>>> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
>>> (XEN) r9:  0000000010000001   r10: 0000000000000000   r11: 0000000000000000
>>> (XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
>>> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000406f0
>>> (XEN) cr3: 0000000411165000   cr2: ffffea000005b2d0
>>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>>> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
>>> (XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba
>>> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
>> Here is a better serial log of the crash (just booting a normal Xen 4.1 + initial
>> kernel with 8GB):
>>
>> PXELINUX 3.82 2009-06-09  Copyright (C) 1994-2009 H. Peter Anvin et al
>> boot:
>> Loading xen.gz... ok
>> Loading vmlinuz... ok
>> Loading initramfs.cpio.gz... ok
>>  __  __            _  _    _   ____
>>  \ \/ /___ _ __   | || |  / | | ___|    _ __  _ __ ___
>>   \  // _ \ '_(_)_(_)____/   | .__/|_|  \___|
>>                                        |_|
>> (XEN) Xen version 4.1.5-pre (konrad@dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) Fri Feb 22 11:37:00 EST 2013
>> (XEN) Latest ChangeSet: Fri Feb 15 15:31:55 2013 +0100 23459:9f12bdd6b7f0
>> (XEN) Console output is synchronous.
>> (XEN) Bootloader: unknown
>> (XEN) Command line: cpuinfo conring_size=1048576 sync_console cpufreq=verbose com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all
>> (XEN) Video information:
>> (XEN)  VGA is text mode 80x25, font 8x16
>> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
>> (XEN)  EDID info not retrieved because no DDC retrieval method detected
>> (XEN) Disc information:
>> (XEN)  Found 1 MBR signatures
>> (XEN)  Found 1 EDD information structures
>> (XEN) Xen-e820 RAM map:
>> (XEN)  0000000000000000 - 000000000009ec00 (usable)
>> (XEN)  000000000009ec00 - 00000000000a0000 (reserved)
>> (XEN)  00000000000e0000 - 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)
>> (XEN)  00000000badc9000 - 00000000badd1000 (ACPI data)
>> (XEN)  00000000badd1000 - 00000000badf4000 (reserved)
>> (XEN)  00000000badf4000 - 00000000badf6000 (usable)
>> (XEN)  00000000badf6000 - 00000000bae06000 (reserved)
>> (XEN)  00000000bae06000 - 00000000bae14000 (ACPI NVS)
>> (XEN)  00000000bae14000 - 00000000bae3c000 (reserved)
>> (XEN)  00000000bae3c000 - 00000000bae7f000 (ACPI NVS)
>> (XEN)  00000000bae7f000 - 00000000bb000000 (usable)
>> (XEN)  00000000bb800000 - 00000000bfa00000 (reserved)
>> (XEN)  00000000fed1c000 - 00000000fed40000 (reserved)
>> (XEN)  00000000ff000000 - 0000000100000000 (reserved)
>> (XEN)  0000000100000000 - 000000023fe00000 (usable)
>> (XEN) ACPI: RSDP 000F0450, 0024 (r2 ALASKA)
>> (XEN) ACPI: XSDT BADC9068, 0054 (r1 ALASKA    A M I  1072009 AMI     10013)
>> (XEN)  PROC        1 MSFT  3000001)
>> (XEN) ACPI: MCFG BADD0580, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
>> (XEN) ACPI: HPET BADD05C0, 0038 (r1 ALASKA    A M I  1072009 AMI.        4)
>> (XEN) ACPI: ASF! BADD05F8, 00A0 (r32 INTEL       HCG        1 TFSM    F4240)
>> (XEN) System RAM: 8104MB (8299140kB)
>> (XEN) No NUMA configuration found
>> (XEN) Faking a node at 0000000000000000-000000023fe00000
>> (XEN) Domain heap initialised
>> (XEN) found SMP MP-table at 000fcde0
>> (XEN) DMI 2.7 present.
>> (XEN) Using APIC driver default
>> (XEN) ACPI: PM-Timer IO Port: 0x408
>> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
>> (XEN) ACPI: 32/64X FACS address mismatch in FADT - bae0bf80/0000000000000000, using 32
>> (XEN) ACPI:                  wakeup_vec[bae0bf8c], vec_size[20]
>> (XEN) ACPI: Local APIC address 0xfee00000
>> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>> (XEN) Processor #0 6:10 APIC version 21
>> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
>> (XEN) Processor #2 6:10 APIC version 21
>> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
>> (XEN) Processor #1 6:10 APIC version 21
>> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
>> (XEN) Processor #3 6:10 APIC version 21
>> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
>> (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
>> (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
>> (XEN) ACPI: IRQ0 used by override.
>> (XEN) ACPI: IRQ2 used by override.
>> (XEN) ACPI: IRQ9 used by override.
>> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
>> (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
>> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
>> (XEN) PCI: Not using MMCONFIG.
>> (XEN) Table is not found!
>> (XEN) Using ACPI (MADT) for SMP configuration information
>> (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) Initializing CPU#0
>> (XEN) Detected 3093.067 MHz processor.
>> (XEN) Initing memory sharing.
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 0
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 256K
>> (XEN) CPU: L3 cache: 3072K
>> (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0
>> (XEN) CPU0: Thermal monitoring enabled (TM1)
>> (XEN) Intel machine check reporting enabled
>> (XEN) I/O virtualisation disabled
>> (XEN) CPU0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
>> (XEN) Enabled directed EOI with ioapic_ack_old on!
>> (XEN) ENABLING IO-APIC IRQs
>> (XEN)  -> Using old ACK method
>> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>> (XEN) TSC deadline timer enabled
>> (XEN) Platform timer is 14.318MHz HPET
>> (XEN) Allocated console ring of 1048576 KiB.
>> (XEN) VMX: Supported advanced features:
>> (isation
>> (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
>> (XEN) Booting processor 1/1 eip 7c000
>> (XEN) Initializing CPU#1
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 0
>> (XEN) CPU: L1 I cache: 32K, L1 D
>> (XEN) Initializing CPU#2
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 256K
>> (XEN) CPU: L3 cache: 3072K
>> (XEN) CPU2: Thermal monitoring enabled (TM1)
>> (XEN) CPU2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz stepping 07
>> (XEN) Booting processor 3/3 eip 7c000
>> (XEN) Initializing CPU#3
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CPU: L1 I cache: 32K, L1 D100 CPU @ 3.10GHz stepping 07
>> (XEN) Brought up 4 CPUs
>> (XEN) ACPI sleep modes: S3
>> (XEN) mcheck_poll: Machine check polling timer started.
>> (XEN) *** LOADING DOMAIN 0 ***
>> (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x9e0000
>> (XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xa60f0
>> (XEN): paddr=0x1abc000 memsz=0x61b000
>> (XEN) elf_parse_binary: memory: 0x1000000 -> 0x20d7000
>> (XEN) elf_xen_parse_note: GUEST_OS = "linux"
>> (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
>> (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
>> (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
>> (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81abc1e0
>> (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
>> (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
>> (XEN) elf_xen_parse_note: PAE_MODE = "yes"
>> (XEN) elf_xen_parse_note: LOADER = "generic"
>> (XEN) elf_xen_parse_note: unknown xen elf note (0xd)
>> (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
>> (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
>> (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
>> (XEN) elf_xen_addr_calc_check: addresses:
>> (XEN)     virt_base        = 0xffffffff80000000
>> (XEN)     elf_paddr_offset = 0x0
>> (XEN)     virt_offset      = 0xffffffff80000000
>> (XEN)     virt_kstart      = 0xffffffff81000000
>> (XEN)     virt_kend        = 0xffffffff820d7000
>> (XEN)     virt_entry       = 0xffffffff81abc1e0
>> (XEN)     p2m_base         = 0xffffffffffffffff
>> (XEN)  Xen  kernel: 64-bit, lsb, compat32
>> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20d7000
>> (XEN) PHYSICAL MEMORY ARRANGEMENT:
>> (XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (1661249 pages to be allocated)
>> (XEN)  Init. ramdisk: 000000022cbdc000->000000023fe00000
>> (XEN) VIRTUAL MEMORY ARRANGEMENT:
>> (XEN)  Loaded kernel: ffffffff81000000->ffffffff820d7000
>> (XEN)  Init. ramdisk: ffffffff820d7000->ffffffff952fb000
>> (XEN)  Phys-Mach map: ffffffff952fb000->ffffffff96060b28
>> (XEN)  Start info:    ffffffff96061000->ffffffff960614b4
>> (XEN)  Page tables:   ffffffff96062000->ffffffff96117000
>> (XEN)  Boot stack:    ffffffff96117000->ffffffff96118000
>> (XEN)  TOTAL:         ffffffff80000000->ffffffff96400000
>> (XEN)  ENTRY ADDRESS: ffffffff81abc1e0
>> (XEN) Dom0 has maximum 4 VCPUs
>> (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff819e0000
>> (XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81aa60f0
>> (XEN) elf_load_binary: phdr 2 at 0xffffffff81aa7000 -> 0xffffffff81abbbc0
>> (XEN) elf_load_binary: phdr 3 at 0xffffffff81abc000 -> 0xffffffff81baf000
>> (XEN) Scrubbing Free RAM: .done.
>> (XEN) Xen trace buffers: disabled
>> (XEN) Std. Loglevel: All
>> (XEN) Guest Loglevel: All
>> (XEN) ***************************intended to aid debugging of Xen by ensuring
>> (XEN) ******* that all output is synchronously delivered on the serial line.
>> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
>> (XEN) ******* timekeeping. It is NOT recommended for production use!
>> (XEN) **********************************************
>> (XEN) 3... 2... 1...
>> (XEN) Xen is relinquishing VGA console.
>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
>> (XEN) Freed 224kB init memory.
>> mapping kernel into physical memory
>> about to get started...
>> [    0.000000] Initializing cgroup subsys cpuset
>> [    0.000000] Initializing cgroup subsys cpu
>> [    0.000000] Linux version 3.8.0upstream-06471-g2ef14f4-dirty (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 11:36:48 EST 2013
>> [    0.000000] Command line: initcall_debug debug console=hvc0 loglevel=10 xen-pciback.hide=(01:00.0) earlyprintk=xen
>> [    0.000000] Freeing 9e-100 pfn range: 98 pages freed
>> [    0.000000] 1-1 mapping on 9e->100
>> [    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
>> [    0.000000] 1-1 mapping on 20000->20200
>> [    0.000000] Freeing 40000-40200 pfn range: 512 pages freed
>> [    0.000000] 1-1 mapping on 40000->40200
>> [    0.000000] Freeing bad80-badf4 pfn range: 116 pages freed
>> [    0.000000] 1-1 mapping on bad80->badf4
>> [    0.000000] Freeing badf6-bae7f pfn range: 137 pages freed
>> [    0.000000] 1-1 mapping on badf6->bae7f
>> [    0.000000] Freeing bb000-100000 pfn range: 282624 pages freed
>> [    0.000000] 1-1 mapping on bb000->100000
>> [    0.000000] Released 283999 pages of unused memory
>> [    0.000000] Set 283999 page(s) to 1-1 mapping
>> [    0.000000] Populating 1acb65-1f20c4 pfn range: 283999 pages added
>> [    0.000000] e820: BIOS-provided physical RAM map:
>> [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
>> [    0.000000] Xen: [mem 0x000000000009ec00-0x00000000000fffff] reserved
>> [    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
>> [    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
>> [    0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable
>> [    0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved
>> [    0.000000] Xen: [mem 0x0000000040200000-0x00000000bad7ffff] usable
>> [    0.000000] Xen: [mem 0x00000000bad80000-0x00000000badc8fff] ACPI NVS
>> [    0.000000] Xen: [mem 0x00000000badc9000-0x00000000badd0fff] ACPI data
>> [    0.000000] Xen: [mem 0x00000000badd1000-0x00000000badf3fff] reserved
>> [    0.000000] Xen: [mem 0x00000000badf4000-0x00000000badf5fff] usable
>> [    0.000000] Xen: [mem 0x00000000badf6000-0x00000000bae05fff] reserved
>> [    0.000000] Xen: [mem 0x00000000bae06000-0x00000000bae13fff] ACPI NVS
>> [    0.000000] Xen: [mem 0x00000000bae14000-0x00000000bae3bfff] reserved
>> [    0.000000] Xen: [mem 0x00000000bae3c000-0x00000000bae7efff] ACPI NVS
>> [    0.000000] Xen: [mem 0x00000000bae7f000-0x00000000baffffff] usable
>> [    0.000000] Xen: [mem 0x00000000bb800000-0x00000000bf9fffff] reserved
>> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
>> [    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
>> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
>> [    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
>> [    0.000000] Xen: [mem 0x0000000100000000-0x000000023fdfffff] usable
>> [    0.000000] bootconsole [xenboot0] enabled
>> [    0.000000] NX (Execute Disable) protection: active
>> [    0.000000] SMBIOS 2.7 present.
>> [    0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
>> [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
>> [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
>> [    0.000000] No AGP bridge found
>> [    0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
>> [    0.000000] e820: lacanning 1 areas for low memory corruption
>> [    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
>> [    0.000000] reserving inaccessible SNB gfx pages
>> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
>> [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
>> [    0.000000]  [mem 0x1f2000000-0x1f20c3fff] page 4k
>> [    0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
>> [    0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
>> [    0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
>> [    0.000000]  [mem 0x1f0000000-0x1f1ffffff] page 4k
>> [    0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
>> [    0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
>> [    0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
>> [    0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
>> [    0.000000]  [mem 0x180000000-0x1efffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
>> [    0.000000]  [mem 0x00100000-0x1fffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
>> [    0.000000]  [mem 0x20200000-0x3fffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
>> [    0.000000]  [mem 0x40200000-0xbad7ffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
>> [    0.000000]  [mem 0xbadf4000-0xbadf5fff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
>> [    0.000000]  [mem 0xbae7f000-0xbaffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
>> [    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
>> [    0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
>> [    0.000000]  [mem 0x1f20c4000-0x23fdfffff] page 4k
> so init_memory_mapping are all done.
>
>> (XEN) d0:v0: unhandled page fault (ec=0000)
>> (XEN) Pagetable walk from ffffea000005b2d0:
>> (XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) ----[ Xen-4.1.5-pre  x86_64  debug=y  Tainted:    C ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    e033:[<ffffffff8103feba>]
>> (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest
>> (XEN) rax: ffffea0000000000   rbx: 0000000001a0c000   rcx: 0000000080000000
>> (XEN) rdx: 000000000005b2a0   rsi: 0000000001a0c000   rdi: 0000000000000000
>> (XEN) rbp: ffffffff81a01dd8   rsp: ffffffff81a01d90   r8:  0000000000000000
>> (XEN) r9:  0000000010000001   r10: 0000000000000005   r11: 0000000000100000
>> (XEN) r12: 0000000000000000   r13: 0000020000000000   r14: 0000000000000000
>> (XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
>> (XEN) cr3: 0000000221a0c000   cr2: ffffea000005b2d0
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>> (XEN) Guest stack trace from rsp=ffffffff81a01d90:
>> (XEN)    0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
>> (XEN)    000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
>> (XEN)    0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
>> (XEN)    00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
>> (XEN)    ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
>> (XEN)    ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
>> (XEN)    ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
>> (XEN)    ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
>> (XEN)    ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
>> (XEN)    ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
>> (XEN)    0000000000000005 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> (XEN)    0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
>> (XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
>> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> can we get kernel trace instead?

(XEN) d0:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea000005b2d0:
(XEN)  L4[0x1d4] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S

This means that Xen was unable to context switch back to dom0

The value in rax looks suspiciously related to the faulting address in cr2.

Konrad: is the instruction at ffffffff8103feba possibly a rax-relative
dereference?

~Andrew

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 22 18:30:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:30: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 1U8xNY-0002uq-DC; Fri, 22 Feb 2013 18:29:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8xM9-0002pU-9e
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:28:25 +0000
Received: from [85.158.138.51:14842] by server-10.bemta-3.messagelabs.com id
	6B/FB-10609-8C8B7215; Fri, 22 Feb 2013 18:28:24 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361557701!28759473!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31875 invoked from network); 22 Feb 2013 18:28:23 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 18:28:23 -0000
Received: from [22.165.177.223] (me40536d0.tmodns.net [208.54.5.228])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MIOx7d027151
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Fri, 22 Feb 2013 10:25:00 -0800
Message-Id: <201302221825.r1MIOx7d027151@mail.zytor.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAE9FiQV8U-7rZZU4Uj_3MVRZiFeq3uEW0ErmCuy1m8AE55gxfw@mail.gmail.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
	<alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
	<CAE9FiQV8U-7rZZU4Uj_3MVRZiFeq3uEW0ErmCuy1m8AE55gxfw@mail.gmail.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri, 22 Feb 2013 10:24:48 -0800
To: Yinghai Lu <yinghai@kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:29:51 +0000
Cc: Gleb Natapov <gleb@redhat.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Gokul Caushik <caushik1@gmail.com>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	"H. J. Lu" <hjl.tools@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jamie.Lokier@zytor.com, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Jacob Shin <jacob.shin@amd.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

<jamie@shareable.org>,Jarkko Sakkinen <jarkko.sakkinen@intel.com>,Jeremy Fitzhardinge <jeremy@goop.org>,Joe Millenbach <jmillenbach@gmail.com>,Joerg Roedel <joro@8bytes.org>,Johannes Weiner <hannes@cmpxchg.org>,Josh Triplett <josh@joshtriplett.org>,Kyungmin Park <kyungmin.park@samsung.com>,Lee Schermerhorn <Lee.Schermerhorn@hp.com>,Len Brown <len.brown@intel.com>,Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,Marcelo Tosatti <mtosatti@redhat.com>,Marek Szyprowski <m.szyprowski@samsung.com>,Matt Fleming <matt.fleming@intel.com>,Mel Gorman <mgorman@suse.de>,Paul Turner <pjt@google.com>,Pavel Machek <pavel@ucw.cz>,Pekka Enberg <penberg@kernel.org>,Peter Zijlstra <a.p.zijlstra@chello.nl>,Ralf Baechle <ralf@linux-mips.org>,Rik van Riel <riel@redhat.com>,Rob Landley <rob@landley.net>,Russell King <linux@arm.linux.org.uk>,Rusty Russell <rusty@rustcorp.com.au>,Shuah Khan <shuah.khan@hp.com>,Shuah Khan <shuahkhan@gmail.com>,Steven Rostedt <rostedt@goodmis.org>,Thomas Gleixn!
 er
<tglx@linutronix.de>,=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,Zachary Amsden <zamsden@gmail.com>,"avi@redhat.com" <avi@redhat.com>,"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,"mst@redhat.com" <mst@redhat.com>,"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,"virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>,"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <1b89b5cf-4ad4-4c25-ab76-a8ac6910c2ec@email.android.com>

Again... you probably want to check into Dave's debug changes first. Makes more sense.

Yinghai Lu <yinghai@kernel.org> wrote:

>On Fri, Feb 22, 2013 at 10:06 AM, Stefano Stabellini
><stefano.stabellini@eu.citrix.com> wrote:
>> On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
>>> > On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>>> > >
>>> > >What is bizzare is that I do recall testing this (and Stefano
>also did it).
>>> > >So I am not sure what has altered.
>>> > >
>>> >
>>> > Yes, there was a very specific reason why I wanted you guys to
>test it...
>>>
>>> Exactly. And I re-ran the same test, but with a new kernel. This is
>what
>>> git reflog tells me:
>>>
>>> 473cd24 HEAD@{75}: checkout: moving from
>08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
>>> 08f321e HEAD@{76}: checkout: moving from linux-next to
>yinghai/for-x86-mm
>>> eb827a7 HEAD@{77}: checkout: moving from
>1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
>>> [konrad@build linux]$ git show 08f321e
>>> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
>>> Author: Yinghai Lu <yinghai@kernel.org>
>>> Date:   Thu Nov 8 00:00:19 2012 -0800
>>>
>>>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
>>>
>>> And I recall Stefano later on testing (I was in a conference and did
>not have
>>> the opportunity to test it). Not sure what he ran with.
>>>
>>
>> FYI the last patch series I tested was Yinghai's "x86, boot, 64bit:
>Add
>> support for loading ramdisk and bzImage above 4G" v7u1.
>
>
>the one in tip and linus's tree is
>---
>-v7u2: update changelog and comments, and clear more fields for
>sentinel.
>     Update swiotlb autoswitch off patch.
>     Fix crash with xen PV guest with 2G.
>---
>
>and it fixes xen crash that you reported with v7u1, and you tested
>that add-on patch
>fix_xen_2g.patch with v7u1.
>and I fold the addon patch into offending patch in v7u2.
>
>
>Thanks
>
>Yinghai

-- 
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 Fri Feb 22 18:30:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:30: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 1U8xNY-0002uq-DC; Fri, 22 Feb 2013 18:29:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1U8xM9-0002pU-9e
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 18:28:25 +0000
Received: from [85.158.138.51:14842] by server-10.bemta-3.messagelabs.com id
	6B/FB-10609-8C8B7215; Fri, 22 Feb 2013 18:28:24 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361557701!28759473!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31875 invoked from network); 22 Feb 2013 18:28:23 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Feb 2013 18:28:23 -0000
Received: from [22.165.177.223] (me40536d0.tmodns.net [208.54.5.228])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1MIOx7d027151
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Fri, 22 Feb 2013 10:25:00 -0800
Message-Id: <201302221825.r1MIOx7d027151@mail.zytor.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAE9FiQV8U-7rZZU4Uj_3MVRZiFeq3uEW0ErmCuy1m8AE55gxfw@mail.gmail.com>
References: <201302220034.r1M0Y6O8008311@terminus.zytor.com>
	<20130222165531.GA29308@phenom.dumpdata.com>
	<5127A719.3060702@zytor.com>
	<20130222173805.GC7768@phenom.dumpdata.com>
	<alpine.DEB.2.02.1302221804340.22997@kaball.uk.xensource.com>
	<CAE9FiQV8U-7rZZU4Uj_3MVRZiFeq3uEW0ErmCuy1m8AE55gxfw@mail.gmail.com>
MIME-Version: 1.0
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri, 22 Feb 2013 10:24:48 -0800
To: Yinghai Lu <yinghai@kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Mailman-Approved-At: Fri, 22 Feb 2013 18:29:51 +0000
Cc: Gleb Natapov <gleb@redhat.com>, Fenghua Yu <fenghua.yu@intel.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Gokul Caushik <caushik1@gmail.com>,
	Christoph Lameter <cl@linux.com>, Ingo Molnar <mingo@kernel.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@elte.hu>,
	Borislav Petkov <bp@suse.de>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	"H. J. Lu" <hjl.tools@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jamie.Lokier@zytor.com, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Borislav Petkov <bp@alien8.de>,
	Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Jacob Shin <jacob.shin@amd.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Xen-devel] [GIT PULL] x86/mm changes for v3.9-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

<jamie@shareable.org>,Jarkko Sakkinen <jarkko.sakkinen@intel.com>,Jeremy Fitzhardinge <jeremy@goop.org>,Joe Millenbach <jmillenbach@gmail.com>,Joerg Roedel <joro@8bytes.org>,Johannes Weiner <hannes@cmpxchg.org>,Josh Triplett <josh@joshtriplett.org>,Kyungmin Park <kyungmin.park@samsung.com>,Lee Schermerhorn <Lee.Schermerhorn@hp.com>,Len Brown <len.brown@intel.com>,Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,Marcelo Tosatti <mtosatti@redhat.com>,Marek Szyprowski <m.szyprowski@samsung.com>,Matt Fleming <matt.fleming@intel.com>,Mel Gorman <mgorman@suse.de>,Paul Turner <pjt@google.com>,Pavel Machek <pavel@ucw.cz>,Pekka Enberg <penberg@kernel.org>,Peter Zijlstra <a.p.zijlstra@chello.nl>,Ralf Baechle <ralf@linux-mips.org>,Rik van Riel <riel@redhat.com>,Rob Landley <rob@landley.net>,Russell King <linux@arm.linux.org.uk>,Rusty Russell <rusty@rustcorp.com.au>,Shuah Khan <shuah.khan@hp.com>,Shuah Khan <shuahkhan@gmail.com>,Steven Rostedt <rostedt@goodmis.org>,Thomas Gleixn!
 er
<tglx@linutronix.de>,=?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,Zachary Amsden <zamsden@gmail.com>,"avi@redhat.com" <avi@redhat.com>,"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,"mst@redhat.com" <mst@redhat.com>,"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,"virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>,"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <1b89b5cf-4ad4-4c25-ab76-a8ac6910c2ec@email.android.com>

Again... you probably want to check into Dave's debug changes first. Makes more sense.

Yinghai Lu <yinghai@kernel.org> wrote:

>On Fri, Feb 22, 2013 at 10:06 AM, Stefano Stabellini
><stefano.stabellini@eu.citrix.com> wrote:
>> On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Feb 22, 2013 at 09:12:57AM -0800, H. Peter Anvin wrote:
>>> > On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
>>> > >
>>> > >What is bizzare is that I do recall testing this (and Stefano
>also did it).
>>> > >So I am not sure what has altered.
>>> > >
>>> >
>>> > Yes, there was a very specific reason why I wanted you guys to
>test it...
>>>
>>> Exactly. And I re-ran the same test, but with a new kernel. This is
>what
>>> git reflog tells me:
>>>
>>> 473cd24 HEAD@{75}: checkout: moving from
>08f321ed97353cf3b3fafa6b1c1971d6a8970830 to linux-next
>>> 08f321e HEAD@{76}: checkout: moving from linux-next to
>yinghai/for-x86-mm
>>> eb827a7 HEAD@{77}: checkout: moving from
>1b66ccf15ff4bd0200567e8d70446a8763f96ee7 to linux-next
>>> [konrad@build linux]$ git show 08f321e
>>> commit 08f321ed97353cf3b3fafa6b1c1971d6a8970830
>>> Author: Yinghai Lu <yinghai@kernel.org>
>>> Date:   Thu Nov 8 00:00:19 2012 -0800
>>>
>>>     mm: Kill NO_BOOTMEM version free_all_bootmem_node()
>>>
>>> And I recall Stefano later on testing (I was in a conference and did
>not have
>>> the opportunity to test it). Not sure what he ran with.
>>>
>>
>> FYI the last patch series I tested was Yinghai's "x86, boot, 64bit:
>Add
>> support for loading ramdisk and bzImage above 4G" v7u1.
>
>
>the one in tip and linus's tree is
>---
>-v7u2: update changelog and comments, and clear more fields for
>sentinel.
>     Update swiotlb autoswitch off patch.
>     Fix crash with xen PV guest with 2G.
>---
>
>and it fixes xen crash that you reported with v7u1, and you tested
>that add-on patch
>fix_xen_2g.patch with v7u1.
>and I fold the addon patch into offending patch in v7u2.
>
>
>Thanks
>
>Yinghai

-- 
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 Fri Feb 22 18:49:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8xg3-00047Y-1V; Fri, 22 Feb 2013 18:48: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 1U8xg1-00047T-JU
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:48:57 +0000
Received: from [85.158.143.99:27711] by server-2.bemta-4.messagelabs.com id
	63/6D-12656-89DB7215; Fri, 22 Feb 2013 18:48:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361558930!21777917!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24776 invoked from network); 22 Feb 2013 18:48:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:48:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1798666"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 18:48: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.297.1; Fri, 22 Feb 2013 18:48:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8xfu-0003Cs-Hf; Fri, 22 Feb 2013 18:48:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8xfu-0005m7-3n;
	Fri, 22 Feb 2013 18:48:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.48529.939151.359987@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 18:48:49 +0000
To: xen-devel@lists.xen.org, Jim Fehlig <jfehlig@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358960210-22667-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1358960210-22667-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 0/4] XEN 4.2 libxl: fix event races exposed
	by	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0/4] XEN 4.2 libxl: fix event races exposed by libvirt"):
> If we prefix my event race fixes with a couple of backports they apply
> cleanly.
> 
> This is a backport of part of a changeset from unstable, which makes
> the two codebases more textually similar:
>  1/4 libxl: rename "abs" variables to "absolute"
> 
> This is a straightforward cherry pick of a bugfix from unstable:
>  2/4 libxl: Fix passing of application data to timeout_deregister hook
> 
> These are the meat:
>  3/4 libxl: fix stale fd event callback race
>  4/4 libxl: fix stale timeout event callback race

3 and 4 have been in unstable for a while without problems, so I have
pushed 1,3,4 to 4.2-staging (and as Jim notes 2 was there already).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:49:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18: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 1U8xg3-00047Y-1V; Fri, 22 Feb 2013 18:48: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 1U8xg1-00047T-JU
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:48:57 +0000
Received: from [85.158.143.99:27711] by server-2.bemta-4.messagelabs.com id
	63/6D-12656-89DB7215; Fri, 22 Feb 2013 18:48:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361558930!21777917!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24776 invoked from network); 22 Feb 2013 18:48:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 18:48:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1798666"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 18:48: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.297.1; Fri, 22 Feb 2013 18:48:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U8xfu-0003Cs-Hf; Fri, 22 Feb 2013 18:48:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U8xfu-0005m7-3n;
	Fri, 22 Feb 2013 18:48:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20775.48529.939151.359987@mariner.uk.xensource.com>
Date: Fri, 22 Feb 2013 18:48:49 +0000
To: xen-devel@lists.xen.org, Jim Fehlig <jfehlig@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1358960210-22667-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1358960210-22667-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 0/4] XEN 4.2 libxl: fix event races exposed
	by	libvirt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 0/4] XEN 4.2 libxl: fix event races exposed by libvirt"):
> If we prefix my event race fixes with a couple of backports they apply
> cleanly.
> 
> This is a backport of part of a changeset from unstable, which makes
> the two codebases more textually similar:
>  1/4 libxl: rename "abs" variables to "absolute"
> 
> This is a straightforward cherry pick of a bugfix from unstable:
>  2/4 libxl: Fix passing of application data to timeout_deregister hook
> 
> These are the meat:
>  3/4 libxl: fix stale fd event callback race
>  4/4 libxl: fix stale timeout event callback race

3 and 4 have been in unstable for a while without problems, so I have
pushed 1,3,4 to 4.2-staging (and as Jim notes 2 was there already).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:52:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:52: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 1U8xjV-0004UD-MA; Fri, 22 Feb 2013 18:52:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1U8xjU-0004U2-CQ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:52:32 +0000
Received: from [85.158.139.211:63363] by server-9.bemta-5.messagelabs.com id
	40/24-24440-E6EB7215; Fri, 22 Feb 2013 18:52:30 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361559150!18892593!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29921 invoked from network); 22 Feb 2013 18:52:30 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 18:52:30 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9F951A4E0C;
	Fri, 22 Feb 2013 19:52:28 +0100 (CET)
Message-ID: <5127BE6A.60304@suse.de>
Date: Fri, 22 Feb 2013 19:52:26 +0100
From: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130105 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Hao, Xudong" <xudong.hao@intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
X-Enigmail-Version: 1.5
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: define a TOM register to
 report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Am 22.02.2013 16:37, schrieb Hao, Xudong:
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, February 22, 2013 5:04 PM
>> To: Hao, Xudong
>> Cc: stefano.stabellini@eu.citrix.com; Zhang, Xiantao; xen-devel@lists.xe=
n.org;
>> qemu-devel@nongnu.org; mst@redhat.com; aliguori@us.ibm.com
>> Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report t=
he
>> base of PCI
>>
>>>>> On 22.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
>>> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>>>
>>>      d->dev.config[I440FX_SMRAM] =3D 0x02;
>>>
>>> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
>>> +    if (xen_enabled()) {
>>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xf0;
>>> +    } else {
>>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xe0;
>>> +    }
>>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] =3D 0x00;
>>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] =3D 0x00;
>>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] =3D 0x00;
>>> +
>>>      cpu_smm_register(&i440fx_set_smm, d);
>>>      return 0;
>>>  }
>>
>> Isn't this the wrong way round (big endian, when it needs to be
>> little)?
>>
> Jan, =

> =

> Here it should be little endian since the following config reading is lit=
tle endian, I'll correct it. Thanks your comments.

Your colleague David Woodhouse has just prepared some i440fx cleanups.
Please use dev->config instead of the indirect d->dev.config.

Given Jan's endianness comment, would alignment allow you to simply
write as follows?

uint32_t addr =3D xen_enabled() ? 0xe0000000 : 0xf0000000;
*(uint32_t *)&dev->config[I440FX_PCI_HOLE_BASE] =3D cpu_to_le32(addr);

Then the byte-swapping would be explicit and the address in one piece
grep'able. Alternatively:

cpu_to_le32s(&addr);
for (i =3D 0; i < 4; i++) {
    dev->config[... + i] =3D ((uint8_t *)&addr)[i];
}

Anyway, please use "piix: " in the subject rather than "qemu: " if this
is supposed to go into upstream qemu.git.

Regards,
Andreas

-- =

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnberg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 18:52:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 18:52: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 1U8xjV-0004UD-MA; Fri, 22 Feb 2013 18:52:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <afaerber@suse.de>) id 1U8xjU-0004U2-CQ
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 18:52:32 +0000
Received: from [85.158.139.211:63363] by server-9.bemta-5.messagelabs.com id
	40/24-24440-E6EB7215; Fri, 22 Feb 2013 18:52:30 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361559150!18892593!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29921 invoked from network); 22 Feb 2013 18:52:30 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 18:52:30 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 9F951A4E0C;
	Fri, 22 Feb 2013 19:52:28 +0100 (CET)
Message-ID: <5127BE6A.60304@suse.de>
Date: Fri, 22 Feb 2013 19:52:26 +0100
From: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130105 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Hao, Xudong" <xudong.hao@intel.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
X-Enigmail-Version: 1.5
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: define a TOM register to
 report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Am 22.02.2013 16:37, schrieb Hao, Xudong:
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Friday, February 22, 2013 5:04 PM
>> To: Hao, Xudong
>> Cc: stefano.stabellini@eu.citrix.com; Zhang, Xiantao; xen-devel@lists.xe=
n.org;
>> qemu-devel@nongnu.org; mst@redhat.com; aliguori@us.ibm.com
>> Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report t=
he
>> base of PCI
>>
>>>>> On 22.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
>>> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>>>
>>>      d->dev.config[I440FX_SMRAM] =3D 0x02;
>>>
>>> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
>>> +    if (xen_enabled()) {
>>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xf0;
>>> +    } else {
>>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xe0;
>>> +    }
>>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] =3D 0x00;
>>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] =3D 0x00;
>>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] =3D 0x00;
>>> +
>>>      cpu_smm_register(&i440fx_set_smm, d);
>>>      return 0;
>>>  }
>>
>> Isn't this the wrong way round (big endian, when it needs to be
>> little)?
>>
> Jan, =

> =

> Here it should be little endian since the following config reading is lit=
tle endian, I'll correct it. Thanks your comments.

Your colleague David Woodhouse has just prepared some i440fx cleanups.
Please use dev->config instead of the indirect d->dev.config.

Given Jan's endianness comment, would alignment allow you to simply
write as follows?

uint32_t addr =3D xen_enabled() ? 0xe0000000 : 0xf0000000;
*(uint32_t *)&dev->config[I440FX_PCI_HOLE_BASE] =3D cpu_to_le32(addr);

Then the byte-swapping would be explicit and the address in one piece
grep'able. Alternatively:

cpu_to_le32s(&addr);
for (i =3D 0; i < 4; i++) {
    dev->config[... + i] =3D ((uint8_t *)&addr)[i];
}

Anyway, please use "piix: " in the subject rather than "qemu: " if this
is supposed to go into upstream qemu.git.

Regards,
Andreas

-- =

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnberg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 19:45:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 19: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 1U8yYK-0006OV-1T; Fri, 22 Feb 2013 19:45:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8yYH-0006OQ-Ob
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 19:45:02 +0000
Received: from [85.158.139.83:22022] by server-6.bemta-5.messagelabs.com id
	D0/43-01489-CBAC7215; Fri, 22 Feb 2013 19:45:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361562299!28538695!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7158 invoked from network); 22 Feb 2013 19:44:59 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-182.messagelabs.com with SMTP;
	22 Feb 2013 19:44:59 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 96928C5618E;
	Fri, 22 Feb 2013 19:44:48 +0000 (GMT)
Date: Fri, 22 Feb 2013 19:44:46 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Tim Deegan <tim@xen.org>
Message-ID: <DC981C243CBC0B54A53C8765@nimrod.local>
In-Reply-To: <20130222174010.GC40494@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Tim,

--On 22 February 2013 17:40:10 +0000 Tim Deegan <tim@xen.org> wrote:

> At 17:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
>> The xen debian packaging currently produces a debian package of what
>> 'make install' would produce. This includes a fair amount of development
>> only stuff, puts the hypervisor in /boot etc.
>>
>> This packaging is not used by Ubuntu (I don't know about debian).
>
> Debian also has its own packaging of Xen.
>
> The 'make deb' target is explicitly not an attempt to package Xen in a
> way that's suitable for deployment -- it's just a way for developers to
> to install a build onto a testbox and cleanly uninstall it later.

That's not too far from how we use the minideb thing. We can't develop
on our appliance boxes as they have no disk, so we need a convenient
way to get xen on there. As it happens, we use the same method in
production (it pulls over a pile of .debs). As we use this for other
things too, it was easier than moving over a .tgz.

> Your minideb seems much more like a 'proper' package to me (with init
> files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
> packaging for Xen doesn't do what you need you should get involved in
> Debian/Ubuntu to make it so rather than duplicating effort here.

Sure. Last time I looked neither Ubuntu nor Debian shipped 4.2. That
appears to have changed(-ish), in that Ubuntu raring now has 4.2 in.
We needed to build our own binaries and had sufficient issues with
their packaging before that we went our own way. Perhaps I should
reexamine their packaging again.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 19:45:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 19: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 1U8yYK-0006OV-1T; Fri, 22 Feb 2013 19:45:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8yYH-0006OQ-Ob
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 19:45:02 +0000
Received: from [85.158.139.83:22022] by server-6.bemta-5.messagelabs.com id
	D0/43-01489-CBAC7215; Fri, 22 Feb 2013 19:45:00 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361562299!28538695!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7158 invoked from network); 22 Feb 2013 19:44:59 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-182.messagelabs.com with SMTP;
	22 Feb 2013 19:44:59 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 96928C5618E;
	Fri, 22 Feb 2013 19:44:48 +0000 (GMT)
Date: Fri, 22 Feb 2013 19:44:46 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Tim Deegan <tim@xen.org>
Message-ID: <DC981C243CBC0B54A53C8765@nimrod.local>
In-Reply-To: <20130222174010.GC40494@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Tim,

--On 22 February 2013 17:40:10 +0000 Tim Deegan <tim@xen.org> wrote:

> At 17:13 +0000 on 22 Feb (1361553221), Alex Bligh wrote:
>> The xen debian packaging currently produces a debian package of what
>> 'make install' would produce. This includes a fair amount of development
>> only stuff, puts the hypervisor in /boot etc.
>>
>> This packaging is not used by Ubuntu (I don't know about debian).
>
> Debian also has its own packaging of Xen.
>
> The 'make deb' target is explicitly not an attempt to package Xen in a
> way that's suitable for deployment -- it's just a way for developers to
> to install a build onto a testbox and cleanly uninstall it later.

That's not too far from how we use the minideb thing. We can't develop
on our appliance boxes as they have no disk, so we need a convenient
way to get xen on there. As it happens, we use the same method in
production (it pulls over a pile of .debs). As we use this for other
things too, it was easier than moving over a .tgz.

> Your minideb seems much more like a 'proper' package to me (with init
> files &c), and I'm inclined to suggest that if Debian's/Ubuntu's own
> packaging for Xen doesn't do what you need you should get involved in
> Debian/Ubuntu to make it so rather than duplicating effort here.

Sure. Last time I looked neither Ubuntu nor Debian shipped 4.2. That
appears to have changed(-ish), in that Ubuntu raring now has 4.2 in.
We needed to build our own binaries and had sufficient issues with
their packaging before that we went our own way. Perhaps I should
reexamine their packaging again.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 19:49:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 19:49: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 1U8ybm-0006VC-MK; Fri, 22 Feb 2013 19:48:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8ybl-0006V6-92
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 19:48:37 +0000
Received: from [85.158.139.83:44385] by server-12.bemta-5.messagelabs.com id
	C4/98-20195-39BC7215; Fri, 22 Feb 2013 19:48:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361562515!21184852!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16264 invoked from network); 22 Feb 2013 19:48:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-182.messagelabs.com with SMTP;
	22 Feb 2013 19:48:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C6387C5618E;
	Fri, 22 Feb 2013 19:48:22 +0000 (GMT)
Date: Fri, 22 Feb 2013 19:48:20 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <044C88EAD95AA5B1839F9185@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 22 February 2013 17:57:47 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I think it could still be very useful to many people. If not on the
> xen-unstable repository, it should still be published somewhere.
> Maybe a link on the wiki or a blog article?

I'm happy to tidy it up a bit if people think it is useful, and publish
it wherever. From memory the impact on the main code base is a 3 line
change to the Makefile, and doubtless I could minimise the other files
too.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 19:49:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 19:49: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 1U8ybm-0006VC-MK; Fri, 22 Feb 2013 19:48:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8ybl-0006V6-92
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 19:48:37 +0000
Received: from [85.158.139.83:44385] by server-12.bemta-5.messagelabs.com id
	C4/98-20195-39BC7215; Fri, 22 Feb 2013 19:48:35 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361562515!21184852!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16264 invoked from network); 22 Feb 2013 19:48:35 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-16.tower-182.messagelabs.com with SMTP;
	22 Feb 2013 19:48:35 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C6387C5618E;
	Fri, 22 Feb 2013 19:48:22 +0000 (GMT)
Date: Fri, 22 Feb 2013 19:48:20 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <044C88EAD95AA5B1839F9185@nimrod.local>
In-Reply-To: <alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 22 February 2013 17:57:47 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I think it could still be very useful to many people. If not on the
> xen-unstable repository, it should still be published somewhere.
> Maybe a link on the wiki or a blog article?

I'm happy to tidy it up a bit if people think it is useful, and publish
it wherever. From memory the impact on the main code base is a 3 line
change to the Makefile, and doubtless I could minimise the other files
too.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 19:53:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 19: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 1U8ygd-0006vp-Mj; Fri, 22 Feb 2013 19:53:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8ygb-0006vX-S2
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 19:53:37 +0000
Received: from [85.158.143.99:16699] by server-1.bemta-4.messagelabs.com id
	B3/E3-06203-1CCC7215; Fri, 22 Feb 2013 19:53:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361562816!28825562!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 22 Feb 2013 19:53:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 19:53:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4AC0CC5618E;
	Fri, 22 Feb 2013 19:53:24 +0000 (GMT)
Date: Fri, 22 Feb 2013 19:53:22 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <C997FAB0FF8E85982A18EC3A@nimrod.local>
In-Reply-To: <20130222174129.GD7768@phenom.dumpdata.com>
References: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
	<330E687E05E24E508F95A610@nimrod.local>
	<20130222174129.GD7768@phenom.dumpdata.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <stefano.stabellini@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] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Konrad,

--On 22 February 2013 12:41:29 -0500 Konrad Rzeszutek Wilk 
<konrad.wilk@oracle.com> wrote:

> You should be able to test this rather easy by (in your guest)
> mounting an ext3 or ext4 with barrier support and then looking at
> the blktrace/blkparse to make sure that the sync commands are indeed
> hitting the platter.

OK, I will do that.

I take it that it will sufficient to show:
a) blktrace on the guest performing FUA/FLUSH operations; and
b) blktrace on the host performing FUA/FLUSH operations
in each case where there is an ext4 FS with barrier support turned
on.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 19:53:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 19: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 1U8ygd-0006vp-Mj; Fri, 22 Feb 2013 19:53:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1U8ygb-0006vX-S2
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 19:53:37 +0000
Received: from [85.158.143.99:16699] by server-1.bemta-4.messagelabs.com id
	B3/E3-06203-1CCC7215; Fri, 22 Feb 2013 19:53:37 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361562816!28825562!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 22 Feb 2013 19:53:36 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 19:53:36 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 4AC0CC5618E;
	Fri, 22 Feb 2013 19:53:24 +0000 (GMT)
Date: Fri, 22 Feb 2013 19:53:22 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <C997FAB0FF8E85982A18EC3A@nimrod.local>
In-Reply-To: <20130222174129.GD7768@phenom.dumpdata.com>
References: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
	<alpine.DEB.2.02.1301221531040.29727@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1301221558180.29727@kaball.uk.xensource.com>
	<4D54EE421529BA5E0A511E31@nimrod.local>
	<alpine.DEB.2.02.1301231144300.29727@kaball.uk.xensource.com>
	<DEBAB6AE486E0674778F7C2D@nimrod.local>
	<alpine.DEB.2.02.1301231627440.29727@kaball.uk.xensource.com>
	<850CD247D67BBF77A4CF0417@nimrod.local>
	<656C0D5981D3A8BFB9993B2E@nimrod.local>
	<330E687E05E24E508F95A610@nimrod.local>
	<20130222174129.GD7768@phenom.dumpdata.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <stefano.stabellini@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] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Konrad,

--On 22 February 2013 12:41:29 -0500 Konrad Rzeszutek Wilk 
<konrad.wilk@oracle.com> wrote:

> You should be able to test this rather easy by (in your guest)
> mounting an ext3 or ext4 with barrier support and then looking at
> the blktrace/blkparse to make sure that the sync commands are indeed
> hitting the platter.

OK, I will do that.

I take it that it will sufficient to show:
a) blktrace on the guest performing FUA/FLUSH operations; and
b) blktrace on the host performing FUA/FLUSH operations
in each case where there is an ext4 FS with barrier support turned
on.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 20:08:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 20:08: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 1U8yuS-0007Qz-Bp; Fri, 22 Feb 2013 20:07:56 +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 1U8yuQ-0007Qu-Uu
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 20:07:55 +0000
Received: from [85.158.138.51:23725] by server-4.bemta-3.messagelabs.com id
	B8/D2-17521-A10D7215; Fri, 22 Feb 2013 20:07:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361563673!27744855!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16213 invoked from network); 22 Feb 2013 20:07:53 -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 SMTP;
	22 Feb 2013 20:07:53 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (joses mo23) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I019d5p1MJv3JI ;
	Fri, 22 Feb 2013 21:07:47 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 57EFD1884C; Fri, 22 Feb 2013 21:07:47 +0100 (CET)
Date: Fri, 22 Feb 2013 21:07:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222200746.GA26772@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
	<5127882D02000078000C068D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5127882D02000078000C068D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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, Feb 22, Jan Beulich wrote:

> >>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> > It did not happen with xl.
> 
> But the same guest and Dom0 kernel, and the same hypervisor?

Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.

> > Here is the output while doing xm migrate:
> > 
> > (XEN) HVM2 restore: VMCE_VCPU 0
> > (XEN) HVM2 restore: VMCE_VCPU 1
> > (XEN) HVM2 restore: TSC_ADJUST 0
> > (XEN) HVM2 restore: TSC_ADJUST 1
> > (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
> 
> Didn't even notice yesterday that this is apparently after restore
> has already started. Which makes me curious whether the domain
> that is being referenced with rd= is the old or the new one (would
> require printing the domain ID; honestly I never understood what
> use printing of the domain pointer is).
> 
> I'm also confused by the domain pointer always being the same;
> I would expect it to at least toggle between two values, but
> probably even be different between every instance of the guest.
> But you're not having a stubdom configured for the guest either,
> according to the config you sent earlier...

The rd->domain_id is DOMID_COW in both cases.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 20:08:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 20:08: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 1U8yuS-0007Qz-Bp; Fri, 22 Feb 2013 20:07:56 +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 1U8yuQ-0007Qu-Uu
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 20:07:55 +0000
Received: from [85.158.138.51:23725] by server-4.bemta-3.messagelabs.com id
	B8/D2-17521-A10D7215; Fri, 22 Feb 2013 20:07:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361563673!27744855!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODA4MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16213 invoked from network); 22 Feb 2013 20:07:53 -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 SMTP;
	22 Feb 2013 20:07:53 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (joses mo23) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I019d5p1MJv3JI ;
	Fri, 22 Feb 2013 21:07:47 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 57EFD1884C; Fri, 22 Feb 2013 21:07:47 +0100 (CET)
Date: Fri, 22 Feb 2013 21:07:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130222200746.GA26772@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
	<5127882D02000078000C068D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5127882D02000078000C068D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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, Feb 22, Jan Beulich wrote:

> >>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> > It did not happen with xl.
> 
> But the same guest and Dom0 kernel, and the same hypervisor?

Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.

> > Here is the output while doing xm migrate:
> > 
> > (XEN) HVM2 restore: VMCE_VCPU 0
> > (XEN) HVM2 restore: VMCE_VCPU 1
> > (XEN) HVM2 restore: TSC_ADJUST 0
> > (XEN) HVM2 restore: TSC_ADJUST 1
> > (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, od=0000000000000000, caf=180000000000000, taf=7400000000000001
> 
> Didn't even notice yesterday that this is apparently after restore
> has already started. Which makes me curious whether the domain
> that is being referenced with rd= is the old or the new one (would
> require printing the domain ID; honestly I never understood what
> use printing of the domain pointer is).
> 
> I'm also confused by the domain pointer always being the same;
> I would expect it to at least toggle between two values, but
> probably even be different between every instance of the guest.
> But you're not having a stubdom configured for the guest either,
> according to the config you sent earlier...

The rd->domain_id is DOMID_COW in both cases.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 20:09:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 20:09: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 1U8yvK-0007Tb-QW; Fri, 22 Feb 2013 20:08: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 1U8yvI-0007TN-Qx
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 20:08:49 +0000
Received: from [85.158.143.99:54932] by server-1.bemta-4.messagelabs.com id
	4D/39-06203-050D7215; Fri, 22 Feb 2013 20:08:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361563727!28826783!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTI2NTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTI2NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16797 invoked from network); 22 Feb 2013 20:08:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 20:08:47 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (jored mo44) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j00ddcp1MJrVLr
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 21:08:47 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DB89C1863F
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 21:08:46 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1b36a6c0a956cc94ddb0024099bf60fb4cbe02d7
Message-Id: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Fri, 22 Feb 2013 21:08:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: update tty detection in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1361561865 -3600
# Node ID 1b36a6c0a956cc94ddb0024099bf60fb4cbe02d7
# Parent  dc086ced6b0c7ecf21e56155f42fb16dabe39097
tools/xc: update tty detection in stdiostream_progress

As suggested by IanJ:
Check isatty only once to preserve the errno of ->progress users, and to
reduce the noice in strace output.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dc086ced6b0c -r 1b36a6c0a956 tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -35,6 +35,7 @@ struct xentoollog_logger_stdiostream {
     xentoollog_level min_level;
     unsigned flags;
     int progress_erase_len, progress_last_percent;
+    int isatty;
 };
 
 static void progress_erase(xentoollog_logger_stdiostream *lg) {
@@ -118,7 +119,7 @@ static void stdiostream_progress(struct 
 
     lg->progress_last_percent = percent;
 
-    if (isatty(fileno(lg->f)) <= 0) {
+    if (!lg->isatty) {
         stdiostream_message(logger_in, this_level, context,
                             "%s: %lu/%lu  %3d%%",
                             doing_what, done, total, percent);
@@ -166,6 +167,7 @@ xentoollog_logger_stdiostream *xtl_creat
     newlogger.f = f;
     newlogger.min_level = min_level;
     newlogger.flags = flags;
+    newlogger.isatty = isatty(fileno(lg->f)) > 0;
 
     if (newlogger.flags & XTL_STDIOSTREAM_SHOW_DATE) tzset();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 20:09:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 20:09: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 1U8yvK-0007Tb-QW; Fri, 22 Feb 2013 20:08: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 1U8yvI-0007TN-Qx
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 20:08:49 +0000
Received: from [85.158.143.99:54932] by server-1.bemta-4.messagelabs.com id
	4D/39-06203-050D7215; Fri, 22 Feb 2013 20:08:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361563727!28826783!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTI2NTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTI2NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16797 invoked from network); 22 Feb 2013 20:08:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Feb 2013 20:08:47 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5r/TwSacz0g=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-104.pools.arcor-ip.net [84.57.87.104])
	by smtp.strato.de (jored mo44) (RZmta 31.17 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j00ddcp1MJrVLr
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 21:08:47 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DB89C1863F
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 21:08:46 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1b36a6c0a956cc94ddb0024099bf60fb4cbe02d7
Message-Id: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Fri, 22 Feb 2013 21:08:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/xc: update tty detection in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1361561865 -3600
# Node ID 1b36a6c0a956cc94ddb0024099bf60fb4cbe02d7
# Parent  dc086ced6b0c7ecf21e56155f42fb16dabe39097
tools/xc: update tty detection in stdiostream_progress

As suggested by IanJ:
Check isatty only once to preserve the errno of ->progress users, and to
reduce the noice in strace output.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dc086ced6b0c -r 1b36a6c0a956 tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -35,6 +35,7 @@ struct xentoollog_logger_stdiostream {
     xentoollog_level min_level;
     unsigned flags;
     int progress_erase_len, progress_last_percent;
+    int isatty;
 };
 
 static void progress_erase(xentoollog_logger_stdiostream *lg) {
@@ -118,7 +119,7 @@ static void stdiostream_progress(struct 
 
     lg->progress_last_percent = percent;
 
-    if (isatty(fileno(lg->f)) <= 0) {
+    if (!lg->isatty) {
         stdiostream_message(logger_in, this_level, context,
                             "%s: %lu/%lu  %3d%%",
                             doing_what, done, total, percent);
@@ -166,6 +167,7 @@ xentoollog_logger_stdiostream *xtl_creat
     newlogger.f = f;
     newlogger.min_level = min_level;
     newlogger.flags = flags;
+    newlogger.isatty = isatty(fileno(lg->f)) > 0;
 
     if (newlogger.flags & XTL_STDIOSTREAM_SHOW_DATE) tzset();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 20:19:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 20:19: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 1U8z5l-00082K-BT; Fri, 22 Feb 2013 20:19: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 1U8z5j-00082E-Hq
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 20:19:36 +0000
Received: from [85.158.139.211:45910] by server-7.bemta-5.messagelabs.com id
	AB/F5-11121-6D2D7215; Fri, 22 Feb 2013 20:19:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361564373!17327114!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16521 invoked from network); 22 Feb 2013 20:19:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 20:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1800846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 20:19: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.297.1; Fri, 22 Feb 2013 20:19:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U8z5h-0003hb-0E;
	Fri, 22 Feb 2013 20:19:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U8z5g-0001CH-J0;
	Fri, 22 Feb 2013 20:19:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16226-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 20:19:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable baseline test] 16226: 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 16226 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16226/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check      fail baseline untested
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemut-win  7 windows-install        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-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-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 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fb034f42648ecac835a1666def468f673edd2725
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 22 20:19:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 20:19: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 1U8z5l-00082K-BT; Fri, 22 Feb 2013 20:19: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 1U8z5j-00082E-Hq
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 20:19:36 +0000
Received: from [85.158.139.211:45910] by server-7.bemta-5.messagelabs.com id
	AB/F5-11121-6D2D7215; Fri, 22 Feb 2013 20:19:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361564373!17327114!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16521 invoked from network); 22 Feb 2013 20:19:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 20:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; 
   d="scan'208";a="1800846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Feb 2013 20:19: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.297.1; Fri, 22 Feb 2013 20:19:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U8z5h-0003hb-0E;
	Fri, 22 Feb 2013 20:19:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U8z5g-0001CH-J0;
	Fri, 22 Feb 2013 20:19:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16226-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 22 Feb 2013 20:19:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable baseline test] 16226: 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 16226 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16226/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check      fail baseline untested
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemut-win  7 windows-install        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-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-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 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fb034f42648ecac835a1666def468f673edd2725
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 22 21:01:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 21:01: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 1U8zjm-00012n-5P; Fri, 22 Feb 2013 21:00:58 +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 1U8zjj-00012i-PT
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 21:00:56 +0000
Received: from [85.158.138.51:4417] by server-5.bemta-3.messagelabs.com id
	DA/66-04457-68CD7215; Fri, 22 Feb 2013 21:00:54 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361566854!27404134!1
X-Originating-IP: [209.85.215.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5766 invoked from network); 22 Feb 2013 21:00:54 -0000
Received: from mail-ea0-f177.google.com (HELO mail-ea0-f177.google.com)
	(209.85.215.177)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 21:00:54 -0000
Received: by mail-ea0-f177.google.com with SMTP id n13so447599eaa.8
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 13:00:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=5GQupM19dudvem7wTxZE6hRVrletBKjBQwwN4Pq3tqQ=;
	b=ymdBZCO87FRc2wOQhqWEhAnCQb+LLRvLr1C/cgH9LsoULLmTSTQK5pHVmPgh/WFttg
	eQRUrEiTt4YUCUsc679kOckLjzB5zqyYi8Y2lwIB4ZU2j28pbTLt+bivfvosgaQpTeuA
	PxBhJWJECB7nXFoz3hcgEfHg4ipVEtbCoKPZQTxrR/oLmNkUOMIAuzTWEjPzt50D1fZ3
	muHX1T3+RjVJMSyxVjY7I9dQZlDr0xSE4OhhqSY9UiYMV1nqvBNcxIDKfdkVIZmQpLHA
	5HoY+fvBYe8TL+XX0hnk+WYbya5ZQhMR12hVakHr3uh3q5KZ9O2Ik/DSfHjf7RiS7al0
	N2YQ==
MIME-Version: 1.0
X-Received: by 10.14.220.135 with SMTP id o7mr10414152eep.3.1361566854044;
	Fri, 22 Feb 2013 13:00:54 -0800 (PST)
Received: by 10.223.177.201 with HTTP; Fri, 22 Feb 2013 13:00:53 -0800 (PST)
In-Reply-To: <044C88EAD95AA5B1839F9185@nimrod.local>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
Date: Fri, 22 Feb 2013 13:00:53 -0800
Message-ID: <CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
>
>
> --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>
>> I think it could still be very useful to many people. If not on the
>> xen-unstable repository, it should still be published somewhere.
>> Maybe a link on the wiki or a blog article?
>
>
> I'm happy to tidy it up a bit if people think it is useful, and publish
> it wherever. From memory the impact on the main code base is a 3 line
> change to the Makefile, and doubtless I could minimise the other files
> too.

This would be very useful for people trying to create their own
minimal Xen image. I have been struggling with this for the past few
days.

http://xen.markmail.org/thread/dac5kkuliky5373l

Thanks,
AP

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 21:01:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 21:01: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 1U8zjm-00012n-5P; Fri, 22 Feb 2013 21:00:58 +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 1U8zjj-00012i-PT
	for xen-devel@lists.xen.org; Fri, 22 Feb 2013 21:00:56 +0000
Received: from [85.158.138.51:4417] by server-5.bemta-3.messagelabs.com id
	DA/66-04457-68CD7215; Fri, 22 Feb 2013 21:00:54 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361566854!27404134!1
X-Originating-IP: [209.85.215.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5766 invoked from network); 22 Feb 2013 21:00:54 -0000
Received: from mail-ea0-f177.google.com (HELO mail-ea0-f177.google.com)
	(209.85.215.177)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 21:00:54 -0000
Received: by mail-ea0-f177.google.com with SMTP id n13so447599eaa.8
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 13:00:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=5GQupM19dudvem7wTxZE6hRVrletBKjBQwwN4Pq3tqQ=;
	b=ymdBZCO87FRc2wOQhqWEhAnCQb+LLRvLr1C/cgH9LsoULLmTSTQK5pHVmPgh/WFttg
	eQRUrEiTt4YUCUsc679kOckLjzB5zqyYi8Y2lwIB4ZU2j28pbTLt+bivfvosgaQpTeuA
	PxBhJWJECB7nXFoz3hcgEfHg4ipVEtbCoKPZQTxrR/oLmNkUOMIAuzTWEjPzt50D1fZ3
	muHX1T3+RjVJMSyxVjY7I9dQZlDr0xSE4OhhqSY9UiYMV1nqvBNcxIDKfdkVIZmQpLHA
	5HoY+fvBYe8TL+XX0hnk+WYbya5ZQhMR12hVakHr3uh3q5KZ9O2Ik/DSfHjf7RiS7al0
	N2YQ==
MIME-Version: 1.0
X-Received: by 10.14.220.135 with SMTP id o7mr10414152eep.3.1361566854044;
	Fri, 22 Feb 2013 13:00:54 -0800 (PST)
Received: by 10.223.177.201 with HTTP; Fri, 22 Feb 2013 13:00:53 -0800 (PST)
In-Reply-To: <044C88EAD95AA5B1839F9185@nimrod.local>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
Date: Fri, 22 Feb 2013 13:00:53 -0800
Message-ID: <CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
>
>
> --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>
>> I think it could still be very useful to many people. If not on the
>> xen-unstable repository, it should still be published somewhere.
>> Maybe a link on the wiki or a blog article?
>
>
> I'm happy to tidy it up a bit if people think it is useful, and publish
> it wherever. From memory the impact on the main code base is a 3 line
> change to the Makefile, and doubtless I could minimise the other files
> too.

This would be very useful for people trying to create their own
minimal Xen image. I have been struggling with this for the past few
days.

http://xen.markmail.org/thread/dac5kkuliky5373l

Thanks,
AP

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 21:48:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 21: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 1U90Th-0002U3-9n; Fri, 22 Feb 2013 21:48:25 +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 1U90Tf-0002Ty-4z
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 21:48:24 +0000
Received: from [85.158.138.51:29028] by server-10.bemta-3.messagelabs.com id
	FB/BD-10609-6A7E7215; Fri, 22 Feb 2013 21:48:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361569699!19462799!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8208 invoked from network); 22 Feb 2013 21:48:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 21:48:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MLmFkU016185
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 21:48:16 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
	r1MLmEg6013663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 21:48:15 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
	r1MLmCtY009292; Fri, 22 Feb 2013 15:48:13 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 13:48:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 346841C3935; Fri, 22 Feb 2013 16:48:11 -0500 (EST)
Date: Fri, 22 Feb 2013 16:48:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rafael.j.wysocki@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Message-ID: <20130222214811.GA25445@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Regression introduced by
 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device
 objects from probing ACPI drivers) in v3.9-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Rafael,

Per git bisect it looks like that patch: 
ACPI: Separate adding ACPI device objects from probing ACPI drivers
blows up when running under Xen PV guests:

(please notice that ACPI is turned off with normal Xen PV guests):
547 #ifdef CONFIG_ACPI
548         if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
549                 printk(KERN_INFO "ACPI in unprivileged domain disabled\n");
550                 disable_acpi();
551         }
552 #endif

(in arch/x86/xen/setup.c). Here is what the console tells me
(I can't get the early console somehow to work):

[    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.001000] pid_max: default: 32768 minimum: 301
[    0.001000] Security Framework initialized
[    0.001000] SELinux:  Initializing.
[    0.001000] SELinux:  Starting in permissive mode
[    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001224] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001488] Mount-cache hash table entries: 256
[    0.001774] Initializing cgroup subsys cpuacct
[    0.001782] Initializing cgroup subsys freezer
[    0.001860] tseg: 00adf00000
[    0.001868] CPU: Physical Processor ID: 0
[    0.001874] CPU: Processor Core ID: 1
[    0.001883] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.001883] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.001883] tlb_flushall_shift: 5
[    0.028911] cpu 0 spinlock event irq 17
[    0.028956] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
[    0.028966] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
[    0.028976] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
[    0.028986] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
[    0.028997] calling  init_hw_perf_events+0x0/0x414 @ 1
[    0.029000] Performance Events: 
[    0.029000] perf: AMD core performance counters detected
[    0.029000] no APIC, boot with the "lapic" boot parameter to force-enable it.
[    0.029000] no hardware sampling interrupt available.
[    0.029000] Broken PMU hardware detected, using software events only.
[    0.029005] Failed to access perfctr msr (MSR c0010201 is 0)
[    0.029014] initcall init_hw_perf_events+0x0/0x414 returned 0 after 976 usecs
[    0.029024] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
[    0.029034] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
[    0.029044] calling  spawn_ksoftirqd+0x0/0x28 @ 1
[    0.029093] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
[    0.029103] calling  init_workqueues+0x0/0x33a @ 1
[    0.029316] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
[    0.029327] calling  migration_init+0x0/0x71 @ 1
[    0.029337] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
[    0.029346] calling  cpu_stop_init+0x0/0xb4 @ 1
[    0.029392] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
[    0.029402] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
[    0.029413] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
[    0.029423] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
[    0.029493] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
[    0.029502] calling  relay_init+0x0/0x14 @ 1
[    0.029510] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[    0.029519] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
[    0.029565] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
[    0.029575] calling  init_events+0x0/0x61 @ 1
[    0.029584] initcall init_events+0x0/0x61 returned 0 after 0 usecs
[    0.029592] calling  init_trace_printk+0x0/0x12 @ 1
[    0.029601] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[    0.029610] calling  jump_label_init_module+0x0/0x12 @ 1
[    0.029618] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
[    0.029630] calling  mce_amd_init+0x0/0x110 @ 1
[    0.029638] MCE: In-kernel MCE decoding enabled.
[    0.029647] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
[    0.029760] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.030028] installing Xen timer for CPU 1
[    0.030051] cpu 1 spinlock event irq 24
[    0.030092] SMP alternatives: switching to SMP code
[    0.056501] installing Xen timer for CPU 2
[    0.056544] cpu 2 spinlock event irq 31
[    0.057032] Brought up 3 CPUs
[    0.058000] calling  ipc_ns_init+0x0/0x14 @ 1
[    0.058000] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
[    0.058000] calling  init_mmap_min_addr+0x0/0x26 @ 1
[    0.058000] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[    0.058000] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[    0.058000] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
[    0.058000] calling  net_ns_init+0x0/0xfd @ 1
[    0.061054] initcall net_ns_init+0x0/0xfd returned 0 after 976 usecs
[    0.061056] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
[    0.061069] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
[    0.061081] calling  cpufreq_tsc+0x0/0x37 @ 1
[    0.061092] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
[    0.061104] calling  reboot_init+0x0/0x1d @ 1
[    0.061116] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
[    0.061128] calling  init_lapic_sysfs+0x0/0x20 @ 1
[    0.061138] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
[    0.109030] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
[    0.109044] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
[    0.109056] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.110000] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.111008] calling  ksysfs_init+0x0/0x94 @ 1
[    0.111035] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[    0.111045] calling  pm_init+0x0/0x4e @ 1
[    0.111063] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
[    0.111072] calling  pm_disk_init+0x0/0x19 @ 1
[    0.111092] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[    0.111102] calling  swsusp_header_init+0x0/0x30 @ 1
[    0.111113] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
[    0.111122] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[    0.111137] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
[    0.111148] calling  event_trace_enable+0x0/0xa9 @ 1
[    0.111191] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
[    0.111202] calling  init_zero_pfn+0x0/0x35 @ 1
[    0.111211] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
[    0.111222] calling  fsnotify_init+0x0/0x26 @ 1
[    0.111235] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
[    0.111246] calling  filelock_init+0x0/0x2a @ 1
[    0.111317] initcall filelock_init+0x0/0x2a returned 0 after 976 usecs
[    0.111329] calling  init_misc_binfmt+0x0/0x31 @ 1
[    0.111341] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
[    0.111351] calling  init_script_binfmt+0x0/0x16 @ 1
[    0.111361] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.111371] calling  init_elf_binfmt+0x0/0x16 @ 1
[    0.111381] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.111391] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
[    0.111401] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.111412] calling  debugfs_init+0x0/0x5c @ 1
[    0.111425] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[    0.111435] calling  securityfs_init+0x0/0x53 @ 1
[    0.111448] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
[    0.111458] calling  prandom_init+0x0/0xd9 @ 1
[    0.111469] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
[    0.111480] calling  virtio_init+0x0/0x30 @ 1
[    0.112062] kworker/u:0 (26) used greatest stack depth: 5592 bytes left
[    0.112092] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
[    0.112092] calling  __gnttab_init+0x0/0x30 @ 1
[    0.112092] Grant tables using version 2 layout.
[    0.112109] Grant table initialized
[    0.112118] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
[    0.112130] calling  early_resume_init+0x0/0x1d0 @ 1
[    0.126868] RTC time: 165:165:165, date: 165/165/65
[    0.126887] initcall early_resume_init+0x0/0x1d0 returned 0 after 14648 usecs
[    0.126901] calling  cpufreq_core_init+0x0/0xc7 @ 1
[    0.126911] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
[    0.126921] calling  cpuidle_init+0x0/0x40 @ 1
[    0.126930] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
[    0.126941] calling  bsp_pm_check_init+0x0/0x14 @ 1
[    0.126951] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
[    0.126960] calling  sock_init+0x0/0x89 @ 1
[    0.128845] initcall sock_init+0x0/0x89 returned 0 after 1953 usecs
[    0.128856] calling  net_inuse_init+0x0/0x26 @ 1
[    0.128867] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[    0.128877] calling  netpoll_init+0x0/0x31 @ 1
[    0.128886] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[    0.128896] calling  netlink_proto_init+0x0/0x1b3 @ 1
[    0.128919] NET: Registered protocol family 16
[    0.128953] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
[    0.128985] calling  bdi_class_init+0x0/0x4d @ 1
[    0.129075] initcall bdi_class_init+0x0/0x4d returned 0 after 0 usecs
[    0.129075] calling  kobject_uevent_init+0x0/0x12 @ 1
[    0.129077] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
[    0.129087] calling  pcibus_class_init+0x0/0x19 @ 1
[    0.129114] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.129114] calling  pci_driver_init+0x0/0x19 @ 1
[    0.129114] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
[    0.129114] calling  backlight_class_init+0x0/0x5d @ 1
[    0.129114] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
[    0.129114] calling  video_output_class_init+0x0/0x19 @ 1
[    0.129114] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.217038] calling  xenbus_init+0x0/0x21a @ 1
[    0.217110] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
[    0.217110] calling  tty_class_init+0x0/0x38 @ 1
[    0.217110] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
[    0.217110] calling  vtconsole_class_init+0x0/0xc2 @ 1
[    0.217110] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
[    0.217110] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
[    0.217110] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
[    0.217110] calling  register_node_type+0x0/0x34 @ 1
[    0.218034] initcall register_node_type+0x0/0x34 returned 0 after 976 usecs
[    0.218045] calling  i2c_init+0x0/0x77 @ 1
[    0.218063] initcall i2c_init+0x0/0x77 returned 0 after 0 usecs
[    0.218063] calling  amd_postcore_init+0x0/0x143 @ 1
[    0.218673] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
[    0.218710] calling  set_real_mode_permissions+0x0/0xa9 @ 1
[    0.221082] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 2929 usecs
[    0.221097] calling  arch_kdebugfs_init+0x0/0x233 @ 1
[    0.221181] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
[    0.221193] calling  mtrr_if_init+0x0/0x78 @ 1
[    0.221202] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
[    0.221212] calling  ffh_cstate_init+0x0/0x2a @ 1
[    0.221222] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
[    0.221233] initcall ffh_cstate_init+0x0/0x2a returned with error code -1 
[    0.221243] calling  activate_jump_labels+0x0/0x32 @ 1
[    0.221253] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
[    0.221263] calling  acpi_pci_init+0x0/0x5c @ 1
[    0.221273] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
[    0.221283] calling  dma_bus_init+0x0/0x19 @ 1
[    0.221306] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
[    0.221306] calling  dma_channel_table_init+0x0/0x119 @ 1
[    0.221306] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
[    0.221306] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[    0.226301] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 4882 usecs
[    0.226320] calling  register_xen_pci_notifier+0x0/0x38 @ 1
[    0.226331] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
[    0.226342] calling  xen_pcpu_init+0x0/0xcc @ 1
[    0.226353] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
[    0.226364] calling  dmi_id_init+0x0/0x31d @ 1
[    0.226374] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
[    0.226385] calling  dca_init+0x0/0x20 @ 1
[    0.226394] dca service started, version 1.12.1
[    0.226499] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
[    0.226511] calling  pci_arch_init+0x0/0x69 @ 1
[    0.227009] PCI: setting up Xen PCI frontend stub
[    0.227020] PCI: pci_cache_line_size set to 64 bytes
[    0.227032] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
[    0.227066] calling  topology_init+0x0/0x98 @ 1
[    0.227348] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
[    0.227360] calling  mtrr_init_finialize+0x0/0x36 @ 1
[    0.227370] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
[    0.227380] calling  init_vdso+0x0/0x135 @ 1
[    0.227393] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
[    0.227403] calling  sysenter_setup+0x0/0x2dd @ 1
[    0.227417] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
[    0.227427] calling  param_sysfs_init+0x0/0x192 @ 1
[    0.243968] initcall param_sysfs_init+0x0/0x192 returned 0 after 15625 usecs
[    0.243988] calling  pm_sysrq_init+0x0/0x19 @ 1
[    0.243999] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[    0.244000] calling  default_bdi_init+0x0/0x37 @ 1
[    0.244189] initcall default_bdi_init+0x0/0x37 returned 0 after 976 usecs
[    0.244202] calling  init_bio+0x0/0xe8 @ 1
[    0.244226] bio: create slab <bio-0> at 0
[    0.244247] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
[    0.244258] calling  fsnotify_notification_init+0x0/0x8b @ 1
[    0.244281] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
[    0.244294] calling  cryptomgr_init+0x0/0x12 @ 1
[    0.244304] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[    0.244314] calling  blk_settings_init+0x0/0x2c @ 1
[    0.244323] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
[    0.244333] calling  blk_ioc_init+0x0/0x2a @ 1
[    0.244350] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[    0.244360] calling  blk_softirq_init+0x0/0x6e @ 1
[    0.244371] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[    0.244382] calling  blk_iopoll_setup+0x0/0x6e @ 1
[    0.244391] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[    0.244401] calling  genhd_device_init+0x0/0x85 @ 1
[    0.244544] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
[    0.244557] calling  pci_slot_init+0x0/0x50 @ 1
[    0.244571] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
[    0.244581] calling  fbmem_init+0x0/0x98 @ 1
[    0.244684] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
[    0.244697] calling  acpi_init+0x0/0xbc @ 1
[    0.244705] ACPI: Interpreter disabled.
[    0.244714] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
[    0.244724] calling  dock_init+0x0/0x7b @ 1
[    0.244733] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
[    0.244744] calling  acpi_pci_link_init+0x0/0x43 @ 1
[    0.244754] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
[    0.244764] calling  pnp_init+0x0/0x19 @ 1
[    0.244875] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
[    0.244887] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
[    0.246077] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 1953 usecs
[    0.246091] calling  balloon_init+0x0/0x133 @ 1
[    0.246099] xen/balloon: Initialising balloon driver.
[    0.247065] initcall balloon_init+0x0/0x133 returned 0 after 976 usecs
[    0.247078] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
[    0.255037] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 7812 usecs
[    0.255055] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
[    0.259050] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 3906 usecs
[    0.259065] calling  xen_acpi_pad_init+0x0/0x47 @ 1
[    0.259075] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
[    0.259084] calling  balloon_init+0x0/0xfa @ 1
[    0.259093] xen-balloon: Initialising balloon driver.
[    0.259328] initcall balloon_init+0x0/0xfa returned 0 after 0 usecs
[    0.259328] calling  xen_selfballoon_init+0x0/0xb9 @ 1
[    0.259328] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
[    0.259328] calling  misc_init+0x0/0xba @ 1
[    0.259328] initcall misc_init+0x0/0xba returned 0 after 0 usecs
[    0.259328] calling  vga_arb_device_init+0x0/0xde @ 1
[    0.259419] vgaarb: loaded
[    0.259430] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
[    0.259442] calling  cn_init+0x0/0xc0 @ 1
[    0.259466] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
[    0.259477] calling  phy_init+0x0/0x2e @ 1
[    0.260111] initcall phy_init+0x0/0x2e returned 0 after 976 usecs
[    0.260123] calling  init_pcmcia_cs+0x0/0x3d @ 1
[    0.260208] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
[    0.260219] calling  usb_init+0x0/0x170 @ 1
[    0.260418] usbcore: registered new interface driver usbfs
[    0.260511] usbcore: registered new interface driver hub
[    0.260635] usbcore: registered new device driver usb
[    0.260646] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
[    0.260656] calling  serio_init+0x0/0x38 @ 1
[    0.260750] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
[    0.260760] calling  input_init+0x0/0x103 @ 1
[    0.260852] initcall input_init+0x0/0x103 returned 0 after 0 usecs
[    0.260863] calling  rtc_init+0x0/0x71 @ 1
[    0.260943] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
[    0.260954] calling  pps_init+0x0/0xb7 @ 1
[    0.261000] pps_core: LinuxPPS API ver. 1 registered
[    0.261000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.261000] initcall pps_init+0x0/0xb7 returned 0 after 0 usecs
[    0.261014] calling  ptp_init+0x0/0xa4 @ 1
[    0.261102] PTP clock support registered
[    0.261112] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
[    0.261122] calling  power_supply_class_init+0x0/0x44 @ 1
[    0.261204] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
[    0.261215] calling  hwmon_init+0x0/0xf6 @ 1
[    0.261296] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
[    0.261307] calling  leds_init+0x0/0x48 @ 1
[    0.261388] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
[    0.261399] calling  iommu_init+0x0/0x58 @ 1
[    0.261411] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
[    0.261423] calling  pci_subsys_init+0x0/0x4f @ 1
[    0.261432] PCI: System does not support PCI
[    0.261440] PCI: System does not support PCI
[    0.261450] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
[    0.261459] calling  proto_init+0x0/0x12 @ 1
[    0.261474] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[    0.261485] calling  net_dev_init+0x0/0x1c7 @ 1
[    0.261931] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
[    0.261942] calling  neigh_init+0x0/0x80 @ 1
[    0.261952] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
[    0.261961] calling  fib_rules_init+0x0/0xaf @ 1
[    0.261972] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
[    0.261982] calling  pktsched_init+0x0/0xfe @ 1
[    0.261997] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
[    0.262000] calling  tc_filter_init+0x0/0x55 @ 1
[    0.262000] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
[    0.262000] calling  tc_action_init+0x0/0x55 @ 1
[    0.262000] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
[    0.262000] calling  genl_init+0x0/0x75 @ 1
[    0.262033] initcall genl_init+0x0/0x75 returned 0 after 976 usecs
[    0.263021] calling  cipso_v4_init+0x0/0x61 @ 1
[    0.263039] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[    0.263052] calling  netlbl_init+0x0/0x81 @ 1
[    0.263062] NetLabel: Initializing
[    0.263072] NetLabel:  domain hash size = 128
[    0.263081] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.263126] NetLabel:  unlabeled traffic allowed by default
[    0.263137] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[    0.263147] calling  rfkill_init+0x0/0x79 @ 1
[    0.263402] initcall rfkill_init+0x0/0x79 returned 0 after 0 usecs
[    0.263436] calling  xen_p2m_debugfs+0x0/0x4a @ 1
[    0.263478] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
[    0.263489] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
[    0.263645] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
[    0.263659] calling  hpet_late_init+0x0/0x101 @ 1
[    0.263671] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
[    0.263682] calling  init_amd_nbs+0x0/0xb8 @ 1
[    0.263693] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
[    0.263704] calling  clocksource_done_booting+0x0/0x5a @ 1
[    0.263714] Switching to clocksource xen
[    0.263742] initcall clocksource_done_booting+0x0/0x5a returned 0 after 8 usecs
[    0.263756] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
[    0.263756] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 511 usecs
[    0.263756] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[    0.263756] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 7 usecs
[    0.263756] calling  event_trace_init+0x0/0x271 @ 1
[    0.275332] initcall event_trace_init+0x0/0x271 returned 0 after 11443 usecs
[    0.275351] calling  init_kprobe_trace+0x0/0x93 @ 1
[    0.275377] initcall init_kprobe_trace+0x0/0x93 returned 0 after 15 usecs
[    0.275389] calling  init_pipe_fs+0x0/0x4c @ 1
[    0.275432] initcall init_pipe_fs+0x0/0x4c returned 0 after 31 usecs
[    0.275443] calling  eventpoll_init+0x0/0xda @ 1
[    0.275466] initcall eventpoll_init+0x0/0xda returned 0 after 12 usecs
[    0.275477] calling  anon_inode_init+0x0/0x5b @ 1
[    0.275513] initcall anon_inode_init+0x0/0x5b returned 0 after 26 usecs
[    0.275524] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[    0.275533] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
[    0.275543] calling  acpi_event_init+0x0/0x81 @ 1
[    0.275553] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
[    0.275563] calling  pnp_system_init+0x0/0x12 @ 1
[    0.275708] initcall pnp_system_init+0x0/0x12 returned 0 after 131 usecs
[    0.275719] calling  pnpacpi_init+0x0/0x8c @ 1
[    0.275726] pnp: PnP ACPI: disabled
[    0.275734] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
[    0.275742] calling  pcistub_init+0x0/0x29f @ 1
[    0.275843] initcall pcistub_init+0x0/0x29f returned 0 after 90 usecs
[    0.275852] calling  chr_dev_init+0x0/0xc6 @ 1
[    0.283039] initcall chr_dev_init+0x0/0xc6 returned 0 after 7006 usecs
[    0.283108] calling  firmware_class_init+0x0/0xda @ 1
[    0.283203] initcall firmware_class_init+0x0/0xda returned 0 after 82 usecs
[    0.283213] calling  init_pcmcia_bus+0x0/0x6c @ 1
[    0.283298] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 73 usecs
[    0.283309] calling  thermal_init+0x0/0x75 @ 1
[    0.283400] initcall thermal_init+0x0/0x75 returned 0 after 80 usecs
[    0.283411] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
[    0.283422] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
[    0.283432] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[    0.283442] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
[    0.283454] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
[    0.283465] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
[    0.283476] calling  pcibios_assign_resources+0x0/0xf8 @ 1
[    0.283489] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
[    0.283500] calling  sysctl_core_init+0x0/0x2c @ 1
[    0.283523] initcall sysctl_core_init+0x0/0x2c returned 0 after 13 usecs
[    0.283534] calling  inet_init+0x0/0x2a1 @ 1
[    0.283572] NET: Registered protocol family 2
[    0.283850] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.283962] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.284018] TCP: Hash tables configured (established 16384 bind 16384)
[    0.284118] TCP: reno registered
[    0.284136] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    0.284162] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    0.284282] initcall inet_init+0x0/0x2a1 returned 0 after 720 usecs
[    0.284292] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.284304] initcall ipv4_offload_init+0x0/0x68 returned 0 after 1 usecs
[    0.284314] calling  af_unix_init+0x0/0x55 @ 1
[    0.284326] NET: Registered protocol family 1
[    0.284346] initcall af_unix_init+0x0/0x55 returned 0 after 21 usecs
[    0.284356] calling  ipv6_offload_init+0x0/0x6e @ 1
[    0.467091] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
[    0.467106] calling  init_sunrpc+0x0/0x69 @ 1
[    0.467311] RPC: Registered named UNIX socket transport module.
[    0.467321] RPC: Registered udp transport module.
[    0.467330] RPC: Registered tcp transport module.
[    0.467338] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.467348] initcall init_sunrpc+0x0/0x69 returned 0 after 225 usecs
[    0.467358] calling  pci_apply_final_quirks+0x0/0x117 @ 1
[    0.467370] PCI: CLS 0 bytes, default 64
[    0.467379] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 10 usecs
[    0.467390] calling  populate_rootfs+0x0/0x10d @ 1
[    0.467693] Unpacking initramfs...
[    1.224465] Freeing initrd memory: 339320k freed
[    1.330309] initcall populate_rootfs+0x0/0x10d returned 0 after 842675 usecs
[    1.330328] calling  pci_iommu_init+0x0/0x41 @ 1
[    1.330339] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
[    1.330349] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
[    1.330358] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
[    1.330395] calling  irqfd_module_init+0x0/0x33 @ 1
[    1.330489] initcall irqfd_module_init+0x0/0x33 returned 0 after 81 usecs
[    1.330500] calling  i8259A_init_ops+0x0/0x21 @ 1
[    1.330510] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
[    1.330520] calling  vsyscall_init+0x0/0x27 @ 1
[    1.330534] initcall vsyscall_init+0x0/0x27 returned 0 after 4 usecs
[    1.330544] calling  sbf_init+0x0/0xf6 @ 1
[    1.330553] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
[    1.330563] calling  init_tsc_clocksource+0x0/0x89 @ 1
[    1.330576] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
[    1.330585] calling  add_rtc_cmos+0x0/0x96 @ 1
[    1.330729] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    1.330741] initcall add_rtc_cmos+0x0/0x96 returned 0 after 143 usecs
[    1.330751] calling  i8237A_init_ops+0x0/0x14 @ 1
[    1.330761] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.330771] calling  cache_sysfs_init+0x0/0x6c @ 1
[    1.330843] initcall cache_sysfs_init+0x0/0x6c returned 0 after 60 usecs
[    1.330855] calling  intel_uncore_init+0x0/0x3fa @ 1
[    1.330866] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
[    1.330878] calling  inject_init+0x0/0x30 @ 1
[    1.330886] Machine check injector initialized
[    1.330897] initcall inject_init+0x0/0x30 returned 0 after 9 usecs
[    1.330906] calling  thermal_throttle_init_device+0x0/0x9d @ 1
[    1.330917] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
[    1.330929] calling  amd_ibs_init+0x0/0x48d @ 1
[    1.330939] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
[    1.330949] calling  msr_init+0x0/0x162 @ 1
[    1.331168] initcall msr_init+0x0/0x162 returned 0 after 204 usecs
[    1.331179] calling  cpuid_init+0x0/0x162 @ 1
[    1.331356] initcall cpuid_init+0x0/0x162 returned 0 after 161 usecs
[    1.331368] calling  ioapic_init_ops+0x0/0x14 @ 1
[    1.331379] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.331389] calling  add_pcspkr+0x0/0x40 @ 1
[    1.331493] initcall add_pcspkr+0x0/0x40 returned 0 after 91 usecs
[    1.331504] calling  microcode_init+0x0/0x1b1 @ 1
[    1.331600] microcode: CPU0: patch_level=0x06000626
[    1.331698] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    1.331710] initcall microcode_init+0x0/0x1b1 returned 0 after 193 usecs
[    1.331721] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
[    1.331731] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
[    1.331741] calling  audit_classes_init+0x0/0xaf @ 1
[    1.331756] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
[    1.331767] calling  pt_dump_init+0x0/0x30 @ 1
[    1.331801] initcall pt_dump_init+0x0/0x30 returned 0 after 24 usecs
[    1.331815] calling  ia32_binfmt_init+0x0/0x14 @ 1
[    1.331833] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 6 usecs
[    1.331844] calling  proc_execdomains_init+0x0/0x22 @ 1
[    1.331861] initcall proc_execdomains_init+0x0/0x22 returned 0 after 6 usecs
[    1.331871] calling  ioresources_init+0x0/0x3c @ 1
[    1.331887] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
[    1.331896] calling  uid_cache_init+0x0/0xa5 @ 1
[    1.331911] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
[    1.331923] calling  init_posix_timers+0x0/0x1f4 @ 1
[    1.331940] initcall init_posix_timers+0x0/0x1f4 returned 0 after 5 usecs
[    1.331950] calling  init_posix_cpu_timers+0x0/0xbf @ 1
[    1.331959] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
[    1.331969] calling  proc_schedstat_init+0x0/0x22 @ 1
[    1.331982] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
[    1.331992] calling  snapshot_device_init+0x0/0x12 @ 1
[    1.332147] initcall snapshot_device_init+0x0/0x12 returned 0 after 141 usecs
[    1.332162] calling  create_proc_profile+0x0/0x2c0 @ 1
[    1.332173] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
[    1.332185] calling  timekeeping_init_ops+0x0/0x14 @ 1
[    1.332198] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.332209] calling  init_clocksource_sysfs+0x0/0x52 @ 1
[    1.332448] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 219 usecs
[    1.332464] calling  init_timer_list_procfs+0x0/0x2c @ 1
[    1.332489] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 7 usecs
[    1.332504] calling  alarmtimer_init+0x0/0x15d @ 1
[    1.332743] initcall alarmtimer_init+0x0/0x15d returned 0 after 221 usecs
[    1.332754] calling  init_tstats_procfs+0x0/0x2c @ 1
[    1.332771] initcall init_tstats_procfs+0x0/0x2c returned 0 after 5 usecs
[    1.332781] calling  futex_init+0x0/0x65 @ 1
[    1.332804] initcall futex_init+0x0/0x65 returned 0 after 9 usecs
[    1.427360] calling  proc_dma_init+0x0/0x22 @ 1
[    1.427383] initcall proc_dma_init+0x0/0x22 returned 0 after 9 usecs
[    1.427394] calling  proc_modules_init+0x0/0x22 @ 1
[    1.427408] initcall proc_modules_init+0x0/0x22 returned 0 after 4 usecs
[    1.427417] calling  kallsyms_init+0x0/0x25 @ 1
[    1.427430] initcall kallsyms_init+0x0/0x25 returned 0 after 3 usecs
[    1.427440] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
[    1.427469] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 18 usecs
[    1.427480] calling  crash_notes_memory_init+0x0/0x36 @ 1
[    1.427493] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 4 usecs
[    1.427503] calling  pid_namespaces_init+0x0/0x2d @ 1
[    1.427519] initcall pid_namespaces_init+0x0/0x2d returned 0 after 6 usecs
[    1.427529] calling  ikconfig_init+0x0/0x3a @ 1
[    1.427542] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
[    1.427552] calling  audit_init+0x0/0x141 @ 1
[    1.427563] audit: initializing netlink socket (disabled)
[    1.427590] type=2000 audit(1361569070.777:1): initialized
[    1.427603] initcall audit_init+0x0/0x141 returned 0 after 38 usecs
[    1.427613] calling  audit_watch_init+0x0/0x3a @ 1
[    1.427624] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
[    1.427636] calling  audit_tree_init+0x0/0x49 @ 1
[    1.427647] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[    1.427656] calling  init_kprobes+0x0/0x16c @ 1
[    1.439621] initcall init_kprobes+0x0/0x16c returned 0 after 11669 usecs
[    1.439637] calling  hung_task_init+0x0/0x56 @ 1
[    1.439718] initcall hung_task_init+0x0/0x56 returned 0 after 68 usecs
[    1.439729] calling  irq_pm_init_ops+0x0/0x14 @ 1
[    1.439738] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.439748] calling  utsname_sysctl_init+0x0/0x14 @ 1
[    1.439767] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 9 usecs
[    1.439778] calling  init_tracepoints+0x0/0x20 @ 1
[    1.439788] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
[    1.439798] calling  init_blk_tracer+0x0/0x5a @ 1
[    1.439808] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
[    1.439818] calling  perf_event_sysfs_init+0x0/0x9a @ 1
[    1.440270] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 431 usecs
[    1.440283] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
[    1.440420] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 122 usecs
[    1.440433] calling  kswapd_init+0x0/0x76 @ 1
[    1.440489] initcall kswapd_init+0x0/0x76 returned 0 after 45 usecs
[    1.440499] calling  extfrag_debug_init+0x0/0x7e @ 1
[    1.440539] initcall extfrag_debug_init+0x0/0x7e returned 0 after 29 usecs
[    1.440549] calling  setup_vmstat+0x0/0xc8 @ 1
[    1.440578] initcall setup_vmstat+0x0/0xc8 returned 0 after 18 usecs
[    1.440589] calling  mm_sysfs_init+0x0/0x29 @ 1
[    1.440602] initcall mm_sysfs_init+0x0/0x29 returned 0 after 3 usecs
[    1.440613] calling  slab_proc_init+0x0/0x25 @ 1
[    1.440626] initcall slab_proc_init+0x0/0x25 returned 0 after 4 usecs
[    1.440636] calling  proc_vmalloc_init+0x0/0x25 @ 1
[    1.440650] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
[    1.440660] calling  procswaps_init+0x0/0x22 @ 1
[    1.440673] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
[    1.440684] calling  init_frontswap+0x0/0x96 @ 1
[    1.440737] initcall init_frontswap+0x0/0x96 returned 0 after 43 usecs
[    1.440749] calling  hugetlb_init+0x0/0x415 @ 1
[    1.440759] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.440788] initcall hugetlb_init+0x0/0x415 returned 0 after 28 usecs
[    1.440797] calling  mmu_notifier_init+0x0/0x12 @ 1
[    1.440810] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
[    1.440821] calling  slab_proc_init+0x0/0x8 @ 1
[    1.440831] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
[    1.440840] calling  cpucache_init+0x0/0x52 @ 1
[    1.440851] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
[    1.440861] calling  hugepage_init+0x0/0x191 @ 1
[    1.440870] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
[    1.440880] initcall hugepage_init+0x0/0x191 returned with error code -22 
[    1.440890] calling  init_cleancache+0x0/0x96 @ 1
[    1.440939] initcall init_cleancache+0x0/0x96 returned 0 after 38 usecs
[    1.440949] calling  fcntl_init+0x0/0x2a @ 1
[    1.440964] initcall fcntl_init+0x0/0x2a returned 0 after 5 usecs
[    1.440974] calling  proc_filesystems_init+0x0/0x22 @ 1
[    1.440991] initcall proc_filesystems_init+0x0/0x22 returned 0 after 7 usecs
[    1.441002] calling  dio_init+0x0/0x2d @ 1
[    1.441016] initcall dio_init+0x0/0x2d returned 0 after 5 usecs
[    1.441025] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    1.441109] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 71 usecs
[    1.441119] calling  dnotify_init+0x0/0x7b @ 1
[    1.441137] initcall dnotify_init+0x0/0x7b returned 0 after 8 usecs
[    1.441146] calling  inotify_user_setup+0x0/0x70 @ 1
[    1.441163] initcall inotify_user_setup+0x0/0x70 returned 0 after 7 usecs
[    1.441173] calling  aio_setup+0x0/0x7c @ 1
[    1.441192] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
[    1.627775] calling  proc_locks_init+0x0/0x22 @ 1
[    1.627796] initcall proc_locks_init+0x0/0x22 returned 0 after 9 usecs
[    1.627806] calling  init_sys32_ioctl+0x0/0x28 @ 1
[    1.627885] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 67 usecs
[    1.627895] calling  dquot_init+0x0/0x121 @ 1
[    1.627904] VFS: Disk quotas dquot_6.5.2
[    1.627962] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.627974] initcall dquot_init+0x0/0x121 returned 0 after 66 usecs
[    1.627985] calling  init_v2_quota_format+0x0/0x22 @ 1
[    1.627996] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
[    1.628006] calling  quota_init+0x0/0x26 @ 1
[    1.628027] initcall quota_init+0x0/0x26 returned 0 after 10 usecs
[    1.628037] calling  proc_cmdline_init+0x0/0x22 @ 1
[    1.628072] initcall proc_cmdline_init+0x0/0x22 returned 0 after 22 usecs
[    1.628088] calling  proc_consoles_init+0x0/0x22 @ 1
[    1.628105] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
[    1.628115] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[    1.628129] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 4 usecs
[    1.628140] calling  proc_devices_init+0x0/0x22 @ 1
[    1.628154] initcall proc_devices_init+0x0/0x22 returned 0 after 3 usecs
[    1.628165] calling  proc_interrupts_init+0x0/0x22 @ 1
[    1.628179] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
[    1.628189] calling  proc_loadavg_init+0x0/0x22 @ 1
[    1.628204] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
[    1.628214] calling  proc_meminfo_init+0x0/0x22 @ 1
[    1.628228] initcall proc_meminfo_init+0x0/0x22 returned 0 after 3 usecs
[    1.628237] calling  proc_stat_init+0x0/0x22 @ 1
[    1.628251] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
[    1.628261] calling  proc_uptime_init+0x0/0x22 @ 1
[    1.628275] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
[    1.628287] calling  proc_version_init+0x0/0x22 @ 1
[    1.628300] initcall proc_version_init+0x0/0x22 returned 0 after 3 usecs
[    1.645978] calling  proc_softirqs_init+0x0/0x22 @ 1
[    1.646001] initcall proc_softirqs_init+0x0/0x22 returned 0 after 10 usecs
[    1.646012] calling  proc_kcore_init+0x0/0xb5 @ 1
[    1.646032] initcall proc_kcore_init+0x0/0xb5 returned 0 after 8 usecs
[    1.646042] calling  vmcore_init+0x0/0x370 @ 1
[    1.646052] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
[    1.646063] calling  proc_kmsg_init+0x0/0x25 @ 1
[    1.646076] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
[    1.646086] calling  proc_page_init+0x0/0x42 @ 1
[    1.646104] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
[    1.646125] calling  init_devpts_fs+0x0/0x62 @ 1
[    1.646192] initcall init_devpts_fs+0x0/0x62 returned 0 after 54 usecs
[    1.646203] calling  init_ramfs_fs+0x0/0x12 @ 1
[    1.646213] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
[    1.646224] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
[    1.646302] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 66 usecs
[    1.646313] calling  init_fat_fs+0x0/0x4f @ 1
[    1.646329] initcall init_fat_fs+0x0/0x4f returned 0 after 6 usecs
[    1.646340] calling  init_vfat_fs+0x0/0x12 @ 1
[    1.646350] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
[    1.646360] calling  init_msdos_fs+0x0/0x12 @ 1
[    1.646370] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[    1.646380] calling  init_iso9660_fs+0x0/0x70 @ 1
[    1.646412] initcall init_iso9660_fs+0x0/0x70 returned 0 after 22 usecs
[    1.646422] calling  init_nfs_fs+0x0/0x16c @ 1
[    1.646598] initcall init_nfs_fs+0x0/0x16c returned 0 after 162 usecs
[    1.646609] calling  init_nfs_v2+0x0/0x14 @ 1
[    1.646619] initcall init_nfs_v2+0x0/0x14 returned 0 after 0 usecs
[    1.646629] calling  init_nfs_v3+0x0/0x14 @ 1
[    1.646639] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
[    1.646649] calling  init_nfs_v4+0x0/0x3b @ 1
[    1.646658] NFS: Registering the id_resolver key type
[    1.646685] Key type id_resolver registered
[    1.646694] Key type id_legacy registered
[    1.646708] initcall init_nfs_v4+0x0/0x3b returned 0 after 47 usecs
[    1.646717] calling  init_nlm+0x0/0x4c @ 1
[    1.646732] initcall init_nlm+0x0/0x4c returned 0 after 6 usecs
[    1.646742] calling  init_nls_cp437+0x0/0x12 @ 1
[    1.646752] initcall init_nls_cp437+0x0/0x12 returned 0 after 1 usecs
[    1.646760] calling  init_nls_ascii+0x0/0x12 @ 1
[    1.646770] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[    1.646780] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[    1.646790] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[    1.646799] calling  init_nls_utf8+0x0/0x2b @ 1
[    1.646810] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
[    1.646819] calling  init_ntfs_fs+0x0/0x1d1 @ 1
[    1.646827] NTFS driver 2.1.30 [Flags: R/W].
[    1.646853] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 23 usecs
[    1.646863] calling  init_autofs4_fs+0x0/0x2a @ 1
[    1.647010] initcall init_autofs4_fs+0x0/0x2a returned 0 after 133 usecs
[    1.647019] calling  init_pstore_fs+0x0/0x12 @ 1
[    1.647030] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
[    1.647040] calling  ipc_init+0x0/0x2f @ 1
[    1.647079] msgmni has been set to 2923
[    1.647097] initcall ipc_init+0x0/0x2f returned 0 after 46 usecs
[    1.647106] calling  ipc_sysctl_init+0x0/0x14 @ 1
[    1.647123] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.647132] calling  init_mqueue_fs+0x0/0xa2 @ 1
[    1.647183] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 40 usecs
[    1.647193] calling  key_proc_init+0x0/0x5e @ 1
[    1.647210] initcall key_proc_init+0x0/0x5e returned 0 after 7 usecs
[    1.647220] calling  selinux_nf_ip_init+0x0/0x69 @ 1
[    1.647228] SELinux:  Registering netfilter hooks
[    1.647457] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 222 usecs
[    1.647467] calling  init_sel_fs+0x0/0xa5 @ 1
[    1.647812] initcall init_sel_fs+0x0/0xa5 returned 0 after 327 usecs
[    1.647822] calling  selnl_init+0x0/0x56 @ 1
[    1.647839] initcall selnl_init+0x0/0x56 returned 0 after 7 usecs
[    1.647848] calling  sel_netif_init+0x0/0x5c @ 1
[    1.647860] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
[    1.647870] calling  sel_netnode_init+0x0/0x6a @ 1
[    1.647880] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
[    1.647889] calling  sel_netport_init+0x0/0x6a @ 1
[    1.647900] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
[    1.647909] calling  aurule_init+0x0/0x2d @ 1
[    1.647921] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
[    1.647932] calling  crypto_wq_init+0x0/0x33 @ 1
[    1.647976] initcall crypto_wq_init+0x0/0x33 returned 0 after 33 usecs
[    1.647986] calling  crypto_algapi_init+0x0/0xd @ 1
[    1.647999] initcall crypto_algapi_init+0x0/0xd returned 0 after 4 usecs
[    1.829390] calling  skcipher_module_init+0x0/0x35 @ 1
[    1.829403] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
[    1.829414] calling  chainiv_module_init+0x0/0x12 @ 1
[    1.829425] initcall chainiv_module_init+0x0/0x12 returned 0 after 1 usecs
[    1.829435] calling  eseqiv_module_init+0x0/0x12 @ 1
[    1.829445] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.829455] calling  hmac_module_init+0x0/0x12 @ 1
[    1.829464] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.829474] calling  md5_mod_init+0x0/0x12 @ 1
[    1.829598] initcall md5_mod_init+0x0/0x12 returned 0 after 111 usecs
[    1.829609] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[    1.829676] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 55 usecs
[    1.829687] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[    1.829696] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.829706] calling  des_generic_mod_init+0x0/0x17 @ 1
[    1.829828] initcall des_generic_mod_init+0x0/0x17 returned 0 after 109 usecs
[    1.829839] calling  aes_init+0x0/0x12 @ 1
[    1.829904] initcall aes_init+0x0/0x12 returned 0 after 54 usecs
[    1.829917] calling  zlib_mod_init+0x0/0x12 @ 1
[    1.829983] initcall zlib_mod_init+0x0/0x12 returned 0 after 55 usecs
[    1.829995] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[    1.830005] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.830016] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
[    1.830026] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.830037] calling  lzo_mod_init+0x0/0x12 @ 1
[    1.830133] initcall lzo_mod_init+0x0/0x12 returned 0 after 84 usecs
[    1.830143] calling  krng_mod_init+0x0/0x12 @ 1
[    1.830208] initcall krng_mod_init+0x0/0x12 returned 0 after 53 usecs
[    1.830219] calling  proc_genhd_init+0x0/0x3c @ 1
[    1.830241] initcall proc_genhd_init+0x0/0x3c returned 0 after 11 usecs
[    1.830251] calling  bsg_init+0x0/0x12e @ 1
[    1.830364] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.830375] initcall bsg_init+0x0/0x12e returned 0 after 112 usecs
[    1.830385] calling  noop_init+0x0/0x12 @ 1
[    1.830394] io scheduler noop registered
[    1.830403] initcall noop_init+0x0/0x12 returned 0 after 9 usecs
[    1.830412] calling  deadline_init+0x0/0x12 @ 1
[    1.830421] io scheduler deadline registered
[    1.830430] initcall deadline_init+0x0/0x12 returned 0 after 8 usecs
[    1.830439] calling  cfq_init+0x0/0x8b @ 1
[    1.830456] io scheduler cfq registered (default)
[    1.830466] initcall cfq_init+0x0/0x8b returned 0 after 16 usecs
[    1.830475] calling  percpu_counter_startup+0x0/0x38 @ 1
[    1.830488] initcall percpu_counter_startup+0x0/0x38 returned 0 after 2 usecs
[    1.830498] calling  pci_proc_init+0x0/0x6a @ 1
[    1.830517] initcall pci_proc_init+0x0/0x6a returned 0 after 9 usecs
[    1.830527] calling  pcie_portdrv_init+0x0/0x7a @ 1
[    1.830717] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 175 usecs
[    1.830729] calling  aer_service_init+0x0/0x2b @ 1
[    1.830742] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
[    1.830762] IP: [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
[    1.830780] PGD 0 
[    1.830791] Oops: 0000 [#1] SMP 
[    1.830806] Modules linked in:
[    1.830819] CPU 0 
[    1.830827] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc2upstream-00002-g92ef2a2 #1  
[    1.830838] RIP: e030:[<ffffffff813862fa>]  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
[    1.830853] RSP: e02b:ffff88005bb69e98  EFLAGS: 00010246
[    1.830862] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000017
[    1.830871] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81328b30
[    1.830880] RBP: ffff88005bb69eb8 R08: 00000000833df7a7 R09: 0720072007200720
[    1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
[    1.830899] R13: ffffffff81328b30 R14: 0000000000000000 R15: 0000000000000000
[    1.830913] FS:  0000000000000000(0000) GS:ffff88005d600000(0000) knlGS:0000000000000000
[    1.830926] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    1.830935] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000040660
[    1.830945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.830955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    1.830965] Process swapper/0 (pid: 1, threadinfo ffff88005bb68000, task ffff88005bb627f0)
[    1.830975] Stack:
[    1.830981]  0000000000000030 0000000000000000 ffffffff81ae8f60 000000006d1ed4e7
[    1.831007]  ffff88005bb69ec8 ffffffff81328b8b ffff88005bb69ed8 ffffffff81ae8f72
[    1.831033]  ffff88005bb69f08 ffffffff81002124 0000000000000030 0000000000000007
[    1.831057] Call Trace:
[    1.831057]  [<ffffffff81ae8f60>] ? pcie_portdrv_init+0x7a/0x7a
[    1.831057]  [<ffffffff81328b8b>] aer_acpi_firmware_first+0x1b/0x30
[    1.831057]  [<ffffffff81ae8f72>] aer_service_init+0x12/0x2b
[    1.831057]  [<ffffffff81002124>] do_one_initcall+0x124/0x170
[    1.831057]  [<ffffffff81645404>] kernel_init+0x174/0x2f0
[    1.831057]  [<ffffffff81abd5ca>] ? parse_early_options+0x2b/0x2b
[    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
[    1.831057]  [<ffffffff81663ffc>] ret_from_fork+0x7c/0xb0
[    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
[    1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d 
[    1.831057] RIP  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
[    1.831057]  RSP <ffff88005bb69e98>
[    1.831057] CR2: 0000000000000024
[    2.028436] ---[ end trace dad4411f23c0dcf5 ]---
[    2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
[    2.028476] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    2.028476] 
Parsing config from test.xm
Daemon running with PID 5069

This is what git bisect tells me:

git bisect start
# good: [eb2689e06b3526c7684b09beecf26070f05ee825] Merge tag 'regmap-domain-deps' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good eb2689e06b3526c7684b09beecf26070f05ee825
# bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
# good: [dff8360a4a079692e65e55fbaa6c5dc605528403] Merge tag 'gpio-for-v3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect good dff8360a4a079692e65e55fbaa6c5dc605528403
# good: [8287361abca36504da813638310d2547469283eb] Merge tag 'headers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 8287361abca36504da813638310d2547469283eb
# good: [3c2e81ef344a90bb0a39d84af6878b4aeff568a2] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect good 3c2e81ef344a90bb0a39d84af6878b4aeff568a2
# good: [478740a14826c50595649b3dafed71576796dd95] s390/pci: define read*_relaxed functions
git bisect good 478740a14826c50595649b3dafed71576796dd95
# good: [42976ad0b26b2465f33c9a9146eb15f3a644d269] Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 42976ad0b26b2465f33c9a9146eb15f3a644d269
# good: [88cff241596f29122e9125a41b20d21dfed873cd] Merge tag 'regmap-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good 88cff241596f29122e9125a41b20d21dfed873cd
# good: [10b6339e93244156fac901560117e94bf9dca120] Merge tag 'clk-for-linus' of git://git.linaro.org/people/mturquette/linux
git bisect good 10b6339e93244156fac901560117e94bf9dca120
# bad: [95ecb407699825278f4031f153dbbe0f0713ff28] Merge branch 'pm-tools'
git bisect bad 95ecb407699825278f4031f153dbbe0f0713ff28
# bad: [48694bdb38769c8b9fad4750df25681e32bd815a] Merge branch 'acpica'
git bisect bad 48694bdb38769c8b9fad4750df25681e32bd815a
# good: [3f654bad3257427bea7ba1c4d43a23d99a03622b] ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.
git bisect good 3f654bad3257427bea7ba1c4d43a23d99a03622b
# bad: [b17b537ac1429a609addb55bf985f5ebfcf4ae7b] ACPI / scan: Drop the second argument of acpi_device_unregister()
git bisect bad b17b537ac1429a609addb55bf985f5ebfcf4ae7b
# bad: [209d3b1743c8187c67cc75dbe9fefbcd3121fba0] ACPI: Replace ACPI device add_type field with a match_driver flag
git bisect bad 209d3b1743c8187c67cc75dbe9fefbcd3121fba0
# bad: [a2d06a1a0851fb3d7e775b9d878cdffb9e0300ee] ACPI: Replace struct acpi_bus_ops with enum type
git bisect bad a2d06a1a0851fb3d7e775b9d878cdffb9e0300ee
# bad: [92ef2a25c763338905dce8344a0584606f842920] ACPI: Change the ordering of PCI root bridge driver registrarion
git bisect bad 92ef2a25c763338905dce8344a0584606f842920
# bad: [805d410fb0dbd65e1a57a810858fa2491e75822d] ACPI: Separate adding ACPI device objects from probing ACPI drivers
git bisect bad 805d410fb0dbd65e1a57a810858fa2491e75822d


and just to double-check, if I use commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jan 2 18:13:21 2013 -0800

    Linux 3.8-rc2

(which is the baseline for 805d410fb0dbd65e1a57a810858fa2491e75822d)
the it boots up fine.


And here is with a good (so with 3.8-rc2):

[    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.001000] pid_max: default: 32768 minimum: 301
[    0.001000] Security Framework initialized
[    0.001000] SELinux:  Initializing.
[    0.001000] SELinux:  Starting in permissive mode
[    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001186] Mount-cache hash table entries: 256
[    0.001416] Initializing cgroup subsys cpuacct
[    0.001422] Initializing cgroup subsys freezer
[    0.001477] tseg: 00adf00000
[    0.001484] CPU: Physical Processor ID: 0
[    0.001489] CPU: Processor Core ID: 6
[    0.001495] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.001495] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.001495] tlb_flushall_shift: 5
[    0.022164] cpu 0 spinlock event irq 17
[    0.022202] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
[    0.022211] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
[    0.022219] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
[    0.022227] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
[    0.022236] calling  init_hw_perf_events+0x0/0x414 @ 1
[    0.022242] Performance Events: 
[    0.022247] perf: AMD core performance counters detected
[    0.022254] no APIC, boot with the "lapic" boot parameter to force-enable it.
[    0.022261] no hardware sampling interrupt available.
[    0.022277] Broken PMU hardware detected, using software events only.
[    0.022284] Failed to access perfctr msr (MSR c0010201 is 0)
[    0.022292] initcall init_hw_perf_events+0x0/0x414 returned 0 after 0 usecs
[    0.022299] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
[    0.022307] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
[    0.022316] calling  spawn_ksoftirqd+0x0/0x28 @ 1
[    0.022360] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
[    0.022368] calling  init_workqueues+0x0/0x33a @ 1
[    0.022543] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
[    0.022552] calling  migration_init+0x0/0x71 @ 1
[    0.022560] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
[    0.022568] calling  cpu_stop_init+0x0/0xb4 @ 1
[    0.022606] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
[    0.022615] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
[    0.022622] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
[    0.022630] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
[    0.022684] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
[    0.022692] calling  relay_init+0x0/0x14 @ 1
[    0.022698] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[    0.022705] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
[    0.022746] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
[    0.022753] calling  init_events+0x0/0x61 @ 1
[    0.022761] initcall init_events+0x0/0x61 returned 0 after 0 usecs
[    0.022768] calling  init_trace_printk+0x0/0x12 @ 1
[    0.022775] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[    0.022782] calling  jump_label_init_module+0x0/0x12 @ 1
[    0.022789] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
[    0.022797] calling  mce_amd_init+0x0/0x110 @ 1
[    0.022803] MCE: In-kernel MCE decoding enabled.
[    0.022811] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
[    0.022903] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.023115] installing Xen timer for CPU 1
[    0.023134] cpu 1 spinlock event irq 24
[    0.023185] SMP alternatives: switching to SMP code
[    0.042382] installing Xen timer for CPU 2
[    0.042402] cpu 2 spinlock event irq 31
[    0.042544] Brought up 3 CPUs
[    0.044906] calling  ipc_ns_init+0x0/0x14 @ 1
[    0.044915] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
[    0.044923] calling  init_mmap_min_addr+0x0/0x26 @ 1
[    0.044930] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[    0.044938] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[    0.044948] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
[    0.044957] calling  net_ns_init+0x0/0xfd @ 1
[    0.044990] initcall net_ns_init+0x0/0xfd returned 0 after 0 usecs
[    0.045019] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
[    0.045027] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
[    0.045036] calling  cpufreq_tsc+0x0/0x37 @ 1
[    0.045044] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
[    0.046007] calling  reboot_init+0x0/0x1d @ 1
[    0.046017] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
[    0.046025] calling  init_lapic_sysfs+0x0/0x20 @ 1
[    0.046032] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
[    0.046040] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
[    0.046049] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
[    0.046057] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.046065] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.046073] calling  ksysfs_init+0x0/0x94 @ 1
[    0.046094] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[    0.046103] calling  pm_init+0x0/0x4e @ 1
[    0.046117] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
[    0.046125] calling  pm_disk_init+0x0/0x19 @ 1
[    0.046136] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[    0.046146] calling  swsusp_header_init+0x0/0x30 @ 1
[    0.046154] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
[    0.046162] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[    0.046172] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
[    0.046181] calling  event_trace_enable+0x0/0xa9 @ 1
[    0.046213] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
[    0.046222] calling  init_zero_pfn+0x0/0x35 @ 1
[    0.046229] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
[    0.046237] calling  fsnotify_init+0x0/0x26 @ 1
[    0.046246] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
[    0.046254] calling  filelock_init+0x0/0x2a @ 1
[    0.046281] initcall filelock_init+0x0/0x2a returned 0 after 0 usecs
[    0.046290] calling  init_misc_binfmt+0x0/0x31 @ 1
[    0.046298] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
[    0.046306] calling  init_script_binfmt+0x0/0x16 @ 1
[    0.046314] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046322] calling  init_elf_binfmt+0x0/0x16 @ 1
[    0.046330] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046338] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
[    0.046346] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046354] calling  debugfs_init+0x0/0x5c @ 1
[    0.046364] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[    0.046371] calling  securityfs_init+0x0/0x53 @ 1
[    0.046381] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
[    0.046389] calling  prandom_init+0x0/0xd9 @ 1
[    0.046397] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
[    0.046406] calling  virtio_init+0x0/0x30 @ 1
[    0.046429] kworker/u:0 (26) used greatest stack depth: 6136 bytes left
[    0.046429] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  __gnttab_init+0x0/0x30 @ 1
[    0.046429] Grant tables using version 2 layout.
[    0.046429] Grant table initialized
[    0.046429] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  early_resume_init+0x0/0x1d0 @ 1
[    0.065694] RTC time: 165:165:165, date: 165/165/65
[    0.065702] initcall early_resume_init+0x0/0x1d0 returned 0 after 18554 usecs
[    0.065711] calling  cpufreq_core_init+0x0/0xc7 @ 1
[    0.065719] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
[    0.065727] calling  cpuidle_init+0x0/0x40 @ 1
[    0.065734] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
[    0.065742] calling  bsp_pm_check_init+0x0/0x14 @ 1
[    0.065749] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
[    0.065756] calling  sock_init+0x0/0x89 @ 1
[    0.065842] initcall sock_init+0x0/0x89 returned 0 after 0 usecs
[    0.065850] calling  net_inuse_init+0x0/0x26 @ 1
[    0.065859] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[    0.065867] calling  netpoll_init+0x0/0x31 @ 1
[    0.065874] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[    0.065881] calling  netlink_proto_init+0x0/0x1b3 @ 1
[    0.065897] NET: Registered protocol family 16
[    0.065917] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
[    0.065938] calling  bdi_class_init+0x0/0x4d @ 1
[    0.066049] initcall bdi_class_init+0x0/0x4d returned 0 after 976 usecs
[    0.066060] calling  kobject_uevent_init+0x0/0x12 @ 1
[    0.066071] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
[    0.066079] calling  pcibus_class_init+0x0/0x19 @ 1
[    0.066096] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  pci_driver_init+0x0/0x19 @ 1
[    0.066096] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  backlight_class_init+0x0/0x5d @ 1
[    0.067045] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
[    0.067045] calling  video_output_class_init+0x0/0x19 @ 1
[    0.067063] kworker/u:0 (31) used greatest stack depth: 5592 bytes left
[    0.067063] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.067063] calling  xenbus_init+0x0/0x21a @ 1
[    0.067093] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
[    0.067093] calling  tty_class_init+0x0/0x38 @ 1
[    0.067093] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
[    0.067093] calling  vtconsole_class_init+0x0/0xc2 @ 1
[    0.067093] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
[    0.067093] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
[    0.067093] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
[    0.067093] calling  register_node_type+0x0/0x34 @ 1
[    0.067093] initcall register_node_type+0x0/0x34 returned 0 after 0 usecs
[    0.067093] calling  i2c_init+0x0/0x77 @ 1
[    0.068032] initcall i2c_init+0x0/0x77 returned 0 after 976 usecs
[    0.068043] calling  amd_postcore_init+0x0/0x143 @ 1
[    0.068130] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
[    0.068160] calling  set_real_mode_permissions+0x0/0xa9 @ 1
[    0.068216] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 0 usecs
[    0.068227] calling  arch_kdebugfs_init+0x0/0x233 @ 1
[    0.068268] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
[    0.068278] calling  mtrr_if_init+0x0/0x78 @ 1
[    0.068286] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
[    0.068294] calling  ffh_cstate_init+0x0/0x2a @ 1
[    0.068303] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
[    0.068311] initcall ffh_cstate_init+0x0/0x2a returned with error code -1 
[    0.068319] calling  activate_jump_labels+0x0/0x32 @ 1
[    0.068327] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
[    0.068335] calling  acpi_pci_init+0x0/0x5c @ 1
[    0.068343] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
[    0.068352] calling  dma_bus_init+0x0/0x19 @ 1
[    0.068371] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
[    0.068371] calling  dma_channel_table_init+0x0/0x119 @ 1
[    0.068371] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
[    0.068371] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[    0.070221] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 1953 usecs
[    0.070233] calling  register_xen_pci_notifier+0x0/0x38 @ 1
[    0.070241] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
[    0.070249] calling  xen_pcpu_init+0x0/0xcc @ 1
[    0.070256] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
[    0.070264] calling  dmi_id_init+0x0/0x31d @ 1
[    0.070272] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
[    0.070280] calling  dca_init+0x0/0x20 @ 1
[    0.070286] dca service started, version 1.12.1
[    0.070358] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
[    0.070366] calling  pci_arch_init+0x0/0x69 @ 1
[    0.071009] PCI: setting up Xen PCI frontend stub
[    0.071016] PCI: pci_cache_line_size set to 64 bytes
[    0.071024] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
[    0.071045] calling  topology_init+0x0/0x98 @ 1
[    0.071262] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
[    0.071271] calling  mtrr_init_finialize+0x0/0x36 @ 1
[    0.071278] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
[    0.071286] calling  init_vdso+0x0/0x135 @ 1
[    0.071296] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
[    0.071304] calling  sysenter_setup+0x0/0x2dd @ 1
[    0.071314] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
[    0.071322] calling  param_sysfs_init+0x0/0x192 @ 1
[    0.083778] initcall param_sysfs_init+0x0/0x192 returned 0 after 11718 usecs
[    0.083790] calling  pm_sysrq_init+0x0/0x19 @ 1
[    0.083800] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[    0.083808] calling  default_bdi_init+0x0/0x37 @ 1
[    0.083946] initcall default_bdi_init+0x0/0x37 returned 0 after 0 usecs
[    0.084039] calling  init_bio+0x0/0xe8 @ 1
[    0.084059] bio: create slab <bio-0> at 0
[    0.084078] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
[    0.084087] calling  fsnotify_notification_init+0x0/0x8b @ 1
[    0.084105] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
[    0.084114] calling  cryptomgr_init+0x0/0x12 @ 1
[    0.084122] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[    0.084130] calling  blk_settings_init+0x0/0x2c @ 1
[    0.084138] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
[    0.084146] calling  blk_ioc_init+0x0/0x2a @ 1
[    0.084157] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[    0.084165] calling  blk_softirq_init+0x0/0x6e @ 1
[    0.084174] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[    0.084181] calling  blk_iopoll_setup+0x0/0x6e @ 1
[    0.084189] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[    0.084197] calling  genhd_device_init+0x0/0x85 @ 1
[    0.084326] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
[    0.084337] calling  pci_slot_init+0x0/0x50 @ 1
[    0.084347] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
[    0.084355] calling  fbmem_init+0x0/0x98 @ 1
[    0.084428] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
[    0.084438] calling  acpi_init+0x0/0xbc @ 1
[    0.084444] ACPI: Interpreter disabled.
[    0.084451] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
[    0.084459] calling  dock_init+0x0/0x7b @ 1
[    0.084467] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
[    0.084475] calling  acpi_pci_root_init+0x0/0x32 @ 1
[    0.084483] initcall acpi_pci_root_init+0x0/0x32 returned 0 after 0 usecs
[    0.084491] calling  acpi_pci_link_init+0x0/0x43 @ 1
[    0.084499] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
[    0.084507] calling  pnp_init+0x0/0x19 @ 1
[    0.084576] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
[    0.084586] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
[    0.084600] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 0 usecs
[    0.084600] calling  balloon_init+0x0/0x133 @ 1
[    0.084600] xen/balloon: Initialising balloon driver.
[    0.084600] initcall balloon_init+0x0/0x133 returned 0 after 0 usecs
[    0.084600] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
[    0.085058] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 976 usecs
[    0.085058] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
[    0.085110] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 0 usecs
[    0.085110] calling  xen_acpi_pad_init+0x0/0x47 @ 1
[    0.085110] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
[    0.085110] calling  balloon_init+0x0/0xfa @ 1
[    0.085110] xen-balloon: Initialising balloon driver.
[    0.086035] initcall balloon_init+0x0/0xfa returned 0 after 976 usecs
[    0.086035] calling  xen_selfballoon_init+0x0/0xb9 @ 1
[    0.086043] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
[    0.086051] calling  misc_init+0x0/0xba @ 1
[    0.086151] initcall misc_init+0x0/0xba returned 0 after 0 usecs
[    0.086159] calling  vga_arb_device_init+0x0/0xde @ 1
[    0.086269] vgaarb: loaded
[    0.086276] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
[    0.086285] calling  cn_init+0x0/0xc0 @ 1
[    0.086302] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
[    0.086310] calling  phy_init+0x0/0x2e @ 1
[    0.086493] initcall phy_init+0x0/0x2e returned 0 after 0 usecs
[    0.086501] calling  init_pcmcia_cs+0x0/0x3d @ 1
[    0.086564] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
[    0.086572] calling  usb_init+0x0/0x170 @ 1
[    0.086726] usbcore: registered new interface driver usbfs
[    0.086798] usbcore: registered new interface driver hub
[    0.086890] usbcore: registered new device driver usb
[    0.086898] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
[    0.086906] calling  serio_init+0x0/0x38 @ 1
[    0.086974] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
[    0.086982] calling  input_init+0x0/0x103 @ 1
[    0.087087] initcall input_init+0x0/0x103 returned 0 after 0 usecs
[    0.087095] calling  rtc_init+0x0/0x71 @ 1
[    0.087158] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
[    0.087166] calling  pps_init+0x0/0xb7 @ 1
[    0.087227] pps_core: LinuxPPS API ver. 1 registered
[    0.088018] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.088030] initcall pps_init+0x0/0xb7 returned 0 after 976 usecs
[    0.088038] calling  ptp_init+0x0/0xa4 @ 1
[    0.088113] PTP clock support registered
[    0.088122] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
[    0.088130] calling  power_supply_class_init+0x0/0x44 @ 1
[    0.088195] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
[    0.088204] calling  hwmon_init+0x0/0xf6 @ 1
[    0.088268] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
[    0.088277] calling  leds_init+0x0/0x48 @ 1
[    0.088340] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
[    0.088349] calling  iommu_init+0x0/0x58 @ 1
[    0.088359] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
[    0.088367] calling  pci_subsys_init+0x0/0x4f @ 1
[    0.088374] PCI: System does not support PCI
[    0.088381] PCI: System does not support PCI
[    0.088388] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
[    0.088396] calling  proto_init+0x0/0x12 @ 1
[    0.088407] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[    0.088415] calling  net_dev_init+0x0/0x1c7 @ 1
[    0.088739] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
[    0.088748] calling  neigh_init+0x0/0x80 @ 1
[    0.088757] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
[    0.088765] calling  fib_rules_init+0x0/0xaf @ 1
[    0.088773] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
[    0.088781] calling  pktsched_init+0x0/0xfe @ 1
[    0.088792] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
[    0.088800] calling  tc_filter_init+0x0/0x55 @ 1
[    0.088807] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
[    0.088816] calling  tc_action_init+0x0/0x55 @ 1
[    0.088823] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
[    0.088831] calling  genl_init+0x0/0x75 @ 1
[    0.088845] initcall genl_init+0x0/0x75 returned 0 after 0 usecs
[    0.088853] calling  cipso_v4_init+0x0/0x61 @ 1
[    0.088862] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[    0.088870] calling  netlbl_init+0x0/0x81 @ 1
[    0.088876] NetLabel: Initializing
[    0.088882] NetLabel:  domain hash size = 128
[    0.088888] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.088910] NetLabel:  unlabeled traffic allowed by default
[    0.088919] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[    0.088926] calling  rfkill_init+0x0/0x79 @ 1
[    0.089030] initcall rfkill_init+0x0/0x79 returned 0 after 976 usecs
[    0.089054] calling  xen_p2m_debugfs+0x0/0x4a @ 1
[    0.089087] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
[    0.089095] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
[    0.089219] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
[    0.089228] calling  hpet_late_init+0x0/0x101 @ 1
[    0.089235] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
[    0.089243] calling  init_amd_nbs+0x0/0xb8 @ 1
[    0.089251] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
[    0.089260] calling  clocksource_done_booting+0x0/0x5a @ 1
[    0.089267] Switching to clocksource xen
[    0.089294] initcall clocksource_done_booting+0x0/0x5a returned 0 after 11 usecs
[    0.089303] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
[    0.089711] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 391 usecs
[    0.089720] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[    0.089734] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 6 usecs
[    0.089743] calling  event_trace_init+0x0/0x271 @ 1
[    0.099475] initcall event_trace_init+0x0/0x271 returned 0 after 9769 usecs
[    0.099485] calling  init_kprobe_trace+0x0/0x93 @ 1
[    0.099505] initcall init_kprobe_trace+0x0/0x93 returned 0 after 12 usecs
[    0.099513] calling  init_pipe_fs+0x0/0x4c @ 1
[    0.099543] initcall init_pipe_fs+0x0/0x4c returned 0 after 22 usecs
[    0.099552] calling  eventpoll_init+0x0/0xda @ 1
[    0.099566] initcall eventpoll_init+0x0/0xda returned 0 after 6 usecs
[    0.099574] calling  anon_inode_init+0x0/0x5b @ 1
[    0.099604] initcall anon_inode_init+0x0/0x5b returned 0 after 21 usecs
[    0.099612] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[    0.099620] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
[    0.287868] calling  acpi_event_init+0x0/0x81 @ 1
[    0.287878] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
[    0.287887] calling  pnp_system_init+0x0/0x12 @ 1
[    0.288027] initcall pnp_system_init+0x0/0x12 returned 0 after 127 usecs
[    0.288036] calling  pnpacpi_init+0x0/0x8c @ 1
[    0.288044] pnp: PnP ACPI: disabled
[    0.288052] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
[    0.288100] calling  pcistub_init+0x0/0x29f @ 1
[    0.288197] initcall pcistub_init+0x0/0x29f returned 0 after 86 usecs
[    0.288207] calling  chr_dev_init+0x0/0xc6 @ 1
[    0.293859] initcall chr_dev_init+0x0/0xc6 returned 0 after 5511 usecs
[    0.293869] calling  firmware_class_init+0x0/0xda @ 1
[    0.293941] initcall firmware_class_init+0x0/0xda returned 0 after 60 usecs
[    0.293951] calling  init_pcmcia_bus+0x0/0x6c @ 1
[    0.294023] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 62 usecs
[    0.294032] calling  thermal_init+0x0/0x75 @ 1
[    0.294193] initcall thermal_init+0x0/0x75 returned 0 after 149 usecs
[    0.294203] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
[    0.294212] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
[    0.294221] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[    0.294229] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
[    0.294239] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
[    0.294247] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
[    0.294256] calling  pcibios_assign_resources+0x0/0xf8 @ 1
[    0.294267] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
[    0.294276] calling  sysctl_core_init+0x0/0x2c @ 1
[    0.294295] initcall sysctl_core_init+0x0/0x2c returned 0 after 11 usecs
[    0.294303] calling  inet_init+0x0/0x2a1 @ 1
[    0.294332] NET: Registered protocol family 2
[    0.294575] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294649] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294697] TCP: Hash tables configured (established 16384 bind 16384)
[    0.294733] TCP: reno registered
[    0.294747] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294767] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294857] initcall inet_init+0x0/0x2a1 returned 0 after 533 usecs
[    0.294866] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.294875] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs
[    0.294883] calling  af_unix_init+0x0/0x55 @ 1
[    0.294891] NET: Registered protocol family 1
[    0.294907] initcall af_unix_init+0x0/0x55 returned 0 after 16 usecs
[    0.294916] calling  ipv6_offload_init+0x0/0x6e @ 1
[    0.294925] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
[    0.294933] calling  init_sunrpc+0x0/0x69 @ 1
[    0.295092] RPC: Registered named UNIX socket transport module.
[    0.295101] RPC: Registered udp transport module.
[    0.295108] RPC: Registered tcp transport module.
[    0.295114] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.295123] initcall init_sunrpc+0x0/0x69 returned 0 after 177 usecs
[    0.295131] calling  pci_apply_final_quirks+0x0/0x117 @ 1
[    0.295139] PCI: CLS 0 bytes, default 64
[    0.295146] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 6 usecs
[    0.295155] calling  populate_rootfs+0x0/0x10d @ 1
[    0.295384] Unpacking initramfs...
[    0.854446] Freeing initrd memory: 339316k freed
[    0.941088] initcall populate_rootfs+0x0/0x10d returned 0 after 630779 usecs
[    0.941109] calling  pci_iommu_init+0x0/0x41 @ 1
[    0.941118] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
[    0.941126] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
[    0.941135] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
[    0.941164] calling  irqfd_module_init+0x0/0x33 @ 1
[    0.941260] initcall irqfd_module_init+0x0/0x33 returned 0 after 85 usecs
[    0.941270] calling  i8259A_init_ops+0x0/0x21 @ 1
[    0.941278] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
[    0.941286] calling  vsyscall_init+0x0/0x27 @ 1
[    0.941303] initcall vsyscall_init+0x0/0x27 returned 0 after 6 usecs
[    0.941312] calling  sbf_init+0x0/0xf6 @ 1
[    0.941320] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
[    0.941330] calling  init_tsc_clocksource+0x0/0x89 @ 1
[    0.941343] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
[    0.941353] calling  add_rtc_cmos+0x0/0x96 @ 1
[    0.941554] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.941575] initcall add_rtc_cmos+0x0/0x96 returned 0 after 204 usecs
[    0.941587] calling  i8237A_init_ops+0x0/0x14 @ 1
[    0.941597] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.941610] calling  cache_sysfs_init+0x0/0x6c @ 1
[    0.941692] initcall cache_sysfs_init+0x0/0x6c returned 0 after 70 usecs
[    0.941703] calling  intel_uncore_init+0x0/0x3fa @ 1
[    0.941712] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
[    0.941721] calling  inject_init+0x0/0x30 @ 1
[    0.941728] Machine check injector initialized
[    0.941737] initcall inject_init+0x0/0x30 returned 0 after 7 usecs
[    0.941745] calling  thermal_throttle_init_device+0x0/0x9d @ 1
[    0.941754] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
[    0.941763] calling  amd_ibs_init+0x0/0x48d @ 1
[    0.941772] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
[    0.941781] calling  msr_init+0x0/0x162 @ 1
[    0.941942] initcall msr_init+0x0/0x162 returned 0 after 149 usecs
[    0.941952] calling  cpuid_init+0x0/0x162 @ 1
[    0.942124] initcall cpuid_init+0x0/0x162 returned 0 after 159 usecs
[    0.942133] calling  ioapic_init_ops+0x0/0x14 @ 1
[    0.942141] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942149] calling  add_pcspkr+0x0/0x40 @ 1
[    0.942229] initcall add_pcspkr+0x0/0x40 returned 0 after 70 usecs
[    0.942238] calling  microcode_init+0x0/0x1b1 @ 1
[    0.942318] microcode: CPU0: patch_level=0x06000626
[    0.942401] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.942412] initcall microcode_init+0x0/0x1b1 returned 0 after 162 usecs
[    0.942422] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
[    0.942430] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
[    0.942439] calling  audit_classes_init+0x0/0xaf @ 1
[    0.942452] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
[    0.942460] calling  pt_dump_init+0x0/0x30 @ 1
[    0.942485] initcall pt_dump_init+0x0/0x30 returned 0 after 16 usecs
[    0.942494] calling  ia32_binfmt_init+0x0/0x14 @ 1
[    0.942507] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 5 usecs
[    0.942515] calling  proc_execdomains_init+0x0/0x22 @ 1
[    0.942529] initcall proc_execdomains_init+0x0/0x22 returned 0 after 5 usecs
[    0.942538] calling  ioresources_init+0x0/0x3c @ 1
[    0.942552] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
[    0.942561] calling  uid_cache_init+0x0/0xa5 @ 1
[    0.942574] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
[    0.942582] calling  init_posix_timers+0x0/0x1f4 @ 1
[    0.942598] initcall init_posix_timers+0x0/0x1f4 returned 0 after 7 usecs
[    0.942606] calling  init_posix_cpu_timers+0x0/0xbf @ 1
[    0.942614] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
[    0.942623] calling  proc_schedstat_init+0x0/0x22 @ 1
[    0.942634] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
[    0.942642] calling  snapshot_device_init+0x0/0x12 @ 1
[    0.942724] initcall snapshot_device_init+0x0/0x12 returned 0 after 72 usecs
[    0.942733] calling  create_proc_profile+0x0/0x2c0 @ 1
[    0.942741] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
[    0.942749] calling  timekeeping_init_ops+0x0/0x14 @ 1
[    0.942757] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942765] calling  init_clocksource_sysfs+0x0/0x52 @ 1
[    0.942913] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 136 usecs
[    0.942923] calling  init_timer_list_procfs+0x0/0x2c @ 1
[    0.942934] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 3 usecs
[    0.942943] calling  alarmtimer_init+0x0/0x15d @ 1
[    0.943122] initcall alarmtimer_init+0x0/0x15d returned 0 after 166 usecs
[    0.943131] calling  init_tstats_procfs+0x0/0x2c @ 1
[    0.943143] initcall init_tstats_procfs+0x0/0x2c returned 0 after 4 usecs
[    0.943150] calling  futex_init+0x0/0x65 @ 1
[    0.943163] initcall futex_init+0x0/0x65 returned 0 after 5 usecs
[    0.943170] calling  proc_dma_init+0x0/0x22 @ 1
[    0.943181] initcall proc_dma_init+0x0/0x22 returned 0 after 3 usecs
[    0.943188] calling  proc_modules_init+0x0/0x22 @ 1
[    0.943199] initcall proc_modules_init+0x0/0x22 returned 0 after 3 usecs
[    0.943207] calling  kallsyms_init+0x0/0x25 @ 1
[    0.943217] initcall kallsyms_init+0x0/0x25 returned 0 after 2 usecs
[    0.943224] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
[    1.054869] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 14 usecs
[    1.054879] calling  crash_notes_memory_init+0x0/0x36 @ 1
[    1.054891] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 3 usecs
[    1.054900] calling  pid_namespaces_init+0x0/0x2d @ 1
[    1.054910] initcall pid_namespaces_init+0x0/0x2d returned 0 after 2 usecs
[    1.054918] calling  ikconfig_init+0x0/0x3a @ 1
[    1.054929] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
[    1.054936] calling  audit_init+0x0/0x141 @ 1
[    1.054943] audit: initializing netlink socket (disabled)
[    1.054961] type=2000 audit(1361569587.289:1): initialized
[    1.054971] initcall audit_init+0x0/0x141 returned 0 after 26 usecs
[    1.054979] calling  audit_watch_init+0x0/0x3a @ 1
[    1.054986] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
[    1.054994] calling  audit_tree_init+0x0/0x49 @ 1
[    1.055003] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[    1.055010] calling  init_kprobes+0x0/0x16c @ 1
[    1.065934] initcall init_kprobes+0x0/0x16c returned 0 after 10660 usecs
[    1.065947] calling  hung_task_init+0x0/0x56 @ 1
[    1.065990] initcall hung_task_init+0x0/0x56 returned 0 after 33 usecs
[    1.065998] calling  irq_pm_init_ops+0x0/0x14 @ 1
[    1.066009] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.066017] calling  utsname_sysctl_init+0x0/0x14 @ 1
[    1.066031] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.066039] calling  init_tracepoints+0x0/0x20 @ 1
[    1.066047] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
[    1.066083] calling  init_blk_tracer+0x0/0x5a @ 1
[    1.066092] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
[    1.066100] calling  perf_event_sysfs_init+0x0/0x9a @ 1
[    1.066383] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 268 usecs
[    1.066394] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
[    1.066511] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 105 usecs
[    1.066521] calling  kswapd_init+0x0/0x76 @ 1
[    1.066562] initcall kswapd_init+0x0/0x76 returned 0 after 32 usecs
[    1.066571] calling  extfrag_debug_init+0x0/0x7e @ 1
[    1.066600] initcall extfrag_debug_init+0x0/0x7e returned 0 after 20 usecs
[    1.066609] calling  setup_vmstat+0x0/0xc8 @ 1
[    1.066630] initcall setup_vmstat+0x0/0xc8 returned 0 after 13 usecs
[    1.066639] calling  mm_sysfs_init+0x0/0x29 @ 1
[    1.066649] initcall mm_sysfs_init+0x0/0x29 returned 0 after 2 usecs
[    1.066657] calling  slab_proc_init+0x0/0x25 @ 1
[    1.066668] initcall slab_proc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066676] calling  proc_vmalloc_init+0x0/0x25 @ 1
[    1.066687] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066695] calling  procswaps_init+0x0/0x22 @ 1
[    1.066706] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
[    1.066714] calling  init_frontswap+0x0/0x96 @ 1
[    1.066761] initcall init_frontswap+0x0/0x96 returned 0 after 37 usecs
[    1.066771] calling  hugetlb_init+0x0/0x415 @ 1
[    1.066781] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.066813] initcall hugetlb_init+0x0/0x415 returned 0 after 31 usecs
[    1.066822] calling  mmu_notifier_init+0x0/0x12 @ 1
[    1.066833] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
[    1.066843] calling  slab_proc_init+0x0/0x8 @ 1
[    1.066852] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
[    1.066861] calling  cpucache_init+0x0/0x52 @ 1
[    1.066871] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
[    1.066881] calling  hugepage_init+0x0/0x191 @ 1
[    1.066890] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
[    1.066900] initcall hugepage_init+0x0/0x191 returned with error code -22 
[    1.066910] calling  init_cleancache+0x0/0x96 @ 1
[    1.066956] initcall init_cleancache+0x0/0x96 returned 0 after 35 usecs
[    1.066964] calling  fcntl_init+0x0/0x2a @ 1
[    1.066974] initcall fcntl_init+0x0/0x2a returned 0 after 2 usecs
[    1.066983] calling  proc_filesystems_init+0x0/0x22 @ 1
[    1.066997] initcall proc_filesystems_init+0x0/0x22 returned 0 after 6 usecs
[    1.067005] calling  dio_init+0x0/0x2d @ 1
[    1.067017] initcall dio_init+0x0/0x2d returned 0 after 4 usecs
[    1.067025] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    1.067086] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 51 usecs
[    1.067094] calling  dnotify_init+0x0/0x7b @ 1
[    1.067112] initcall dnotify_init+0x0/0x7b returned 0 after 9 usecs
[    1.067120] calling  inotify_user_setup+0x0/0x70 @ 1
[    1.067135] initcall inotify_user_setup+0x0/0x70 returned 0 after 6 usecs
[    1.067143] calling  aio_setup+0x0/0x7c @ 1
[    1.067160] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
[    1.067168] calling  proc_locks_init+0x0/0x22 @ 1
[    1.067179] initcall proc_locks_init+0x0/0x22 returned 0 after 3 usecs
[    1.067187] calling  init_sys32_ioctl+0x0/0x28 @ 1
[    1.255161] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 71 usecs
[    1.255177] calling  dquot_init+0x0/0x121 @ 1
[    1.255185] VFS: Disk quotas dquot_6.5.2
[    1.255226] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.255238] initcall dquot_init+0x0/0x121 returned 0 after 50 usecs
[    1.255249] calling  init_v2_quota_format+0x0/0x22 @ 1
[    1.255259] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
[    1.255267] calling  quota_init+0x0/0x26 @ 1
[    1.255286] initcall quota_init+0x0/0x26 returned 0 after 8 usecs
[    1.255296] calling  proc_cmdline_init+0x0/0x22 @ 1
[    1.255312] initcall proc_cmdline_init+0x0/0x22 returned 0 after 5 usecs
[    1.255323] calling  proc_consoles_init+0x0/0x22 @ 1
[    1.255338] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
[    1.255349] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[    1.255362] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 3 usecs
[    1.255371] calling  proc_devices_init+0x0/0x22 @ 1
[    1.255383] initcall proc_devices_init+0x0/0x22 returned 0 after 4 usecs
[    1.255393] calling  proc_interrupts_init+0x0/0x22 @ 1
[    1.255407] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
[    1.255418] calling  proc_loadavg_init+0x0/0x22 @ 1
[    1.255432] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
[    1.255442] calling  proc_meminfo_init+0x0/0x22 @ 1
[    1.255457] initcall proc_meminfo_init+0x0/0x22 returned 0 after 4 usecs
[    1.255467] calling  proc_stat_init+0x0/0x22 @ 1
[    1.255481] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
[    1.255491] calling  proc_uptime_init+0x0/0x22 @ 1
[    1.255505] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
[    1.255516] calling  proc_version_init+0x0/0x22 @ 1
[    1.255530] initcall proc_version_init+0x0/0x22 returned 0 after 4 usecs
[    1.255540] calling  proc_softirqs_init+0x0/0x22 @ 1
[    1.255554] initcall proc_softirqs_init+0x0/0x22 returned 0 after 4 usecs
[    1.255565] calling  proc_kcore_init+0x0/0xb5 @ 1
[    1.255581] initcall proc_kcore_init+0x0/0xb5 returned 0 after 7 usecs
[    1.255592] calling  vmcore_init+0x0/0x370 @ 1
[    1.255602] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
[    1.255612] calling  proc_kmsg_init+0x0/0x25 @ 1
[    1.255627] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
[    1.255637] calling  proc_page_init+0x0/0x42 @ 1
[    1.255655] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
[    1.255665] calling  init_devpts_fs+0x0/0x62 @ 1
[    1.255717] initcall init_devpts_fs+0x0/0x62 returned 0 after 40 usecs
[    1.255728] calling  init_ramfs_fs+0x0/0x12 @ 1
[    1.255738] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255747] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
[    1.255811] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 53 usecs
[    1.255819] calling  init_fat_fs+0x0/0x4f @ 1
[    1.255837] initcall init_fat_fs+0x0/0x4f returned 0 after 9 usecs
[    1.255845] calling  init_vfat_fs+0x0/0x12 @ 1
[    1.255854] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255862] calling  init_msdos_fs+0x0/0x12 @ 1
[    1.255870] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255878] calling  init_iso9660_fs+0x0/0x70 @ 1
[    1.255905] initcall init_iso9660_fs+0x0/0x70 returned 0 after 18 usecs
[    1.255913] calling  init_nfs_fs+0x0/0x16c @ 1
[    1.256045] initcall init_nfs_fs+0x0/0x16c returned 0 after 120 usecs
[    1.256077] calling  init_nfs_v2+0x0/0x14 @ 1
[    1.256086] initcall init_nfs_v2+0x0/0x14 returned 0 after 1 usecs
[    1.256093] calling  init_nfs_v3+0x0/0x14 @ 1
[    1.256101] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
[    1.256108] calling  init_nfs_v4+0x0/0x3b @ 1
[    1.256115] NFS: Registering the id_resolver key type
[    1.256134] Key type id_resolver registered
[    1.256140] Key type id_legacy registered
[    1.256151] initcall init_nfs_v4+0x0/0x3b returned 0 after 34 usecs
[    1.256159] calling  init_nlm+0x0/0x4c @ 1
[    1.256171] initcall init_nlm+0x0/0x4c returned 0 after 5 usecs
[    1.256179] calling  init_nls_cp437+0x0/0x12 @ 1
[    1.256187] initcall init_nls_cp437+0x0/0x12 returned 0 after 0 usecs
[    1.256194] calling  init_nls_ascii+0x0/0x12 @ 1
[    1.256202] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[    1.256209] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[    1.256217] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[    1.256225] calling  init_nls_utf8+0x0/0x2b @ 1
[    1.256233] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
[    1.256240] calling  init_ntfs_fs+0x0/0x1d1 @ 1
[    1.256246] NTFS driver 2.1.30 [Flags: R/W].
[    1.455160] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 194248 usecs
[    1.455177] calling  init_autofs4_fs+0x0/0x2a @ 1
[    1.455306] initcall init_autofs4_fs+0x0/0x2a returned 0 after 117 usecs
[    1.455315] calling  init_pstore_fs+0x0/0x12 @ 1
[    1.455324] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
[    1.455331] calling  ipc_init+0x0/0x2f @ 1
[    1.455345] msgmni has been set to 2923
[    1.455359] initcall ipc_init+0x0/0x2f returned 0 after 19 usecs
[    1.455367] calling  ipc_sysctl_init+0x0/0x14 @ 1
[    1.455381] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.455389] calling  init_mqueue_fs+0x0/0xa2 @ 1
[    1.455434] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 36 usecs
[    1.455442] calling  key_proc_init+0x0/0x5e @ 1
[    1.455456] initcall key_proc_init+0x0/0x5e returned 0 after 6 usecs
[    1.455464] calling  selinux_nf_ip_init+0x0/0x69 @ 1
[    1.455471] SELinux:  Registering netfilter hooks
[    1.455652] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 175 usecs
[    1.455661] calling  init_sel_fs+0x0/0xa5 @ 1
[    1.455945] initcall init_sel_fs+0x0/0xa5 returned 0 after 269 usecs
[    1.455954] calling  selnl_init+0x0/0x56 @ 1
[    1.455967] initcall selnl_init+0x0/0x56 returned 0 after 5 usecs
[    1.455975] calling  sel_netif_init+0x0/0x5c @ 1
[    1.455984] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
[    1.455992] calling  sel_netnode_init+0x0/0x6a @ 1
[    1.456001] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
[    1.456008] calling  sel_netport_init+0x0/0x6a @ 1
[    1.456017] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
[    1.456025] calling  aurule_init+0x0/0x2d @ 1
[    1.456033] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
[    1.456040] calling  crypto_wq_init+0x0/0x33 @ 1
[    1.456101] initcall crypto_wq_init+0x0/0x33 returned 0 after 51 usecs
[    1.456110] calling  crypto_algapi_init+0x0/0xd @ 1
[    1.456121] initcall crypto_algapi_init+0x0/0xd returned 0 after 3 usecs
[    1.456129] calling  skcipher_module_init+0x0/0x35 @ 1
[    1.456137] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
[    1.456145] calling  chainiv_module_init+0x0/0x12 @ 1
[    1.456153] initcall chainiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456161] calling  eseqiv_module_init+0x0/0x12 @ 1
[    1.456169] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456176] calling  hmac_module_init+0x0/0x12 @ 1
[    1.456184] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456192] calling  md5_mod_init+0x0/0x12 @ 1
[    1.456254] initcall md5_mod_init+0x0/0x12 returned 0 after 53 usecs
[    1.456263] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[    1.456315] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456324] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[    1.456332] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456340] calling  des_generic_mod_init+0x0/0x17 @ 1
[    1.456434] initcall des_generic_mod_init+0x0/0x17 returned 0 after 84 usecs
[    1.456442] calling  aes_init+0x0/0x12 @ 1
[    1.456493] initcall aes_init+0x0/0x12 returned 0 after 42 usecs
[    1.456501] calling  zlib_mod_init+0x0/0x12 @ 1
[    1.456551] initcall zlib_mod_init+0x0/0x12 returned 0 after 41 usecs
[    1.456559] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[    1.456567] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456575] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
[    1.456584] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456592] calling  lzo_mod_init+0x0/0x12 @ 1
[    1.456643] initcall lzo_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456651] calling  krng_mod_init+0x0/0x12 @ 1
[    1.456702] initcall krng_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456710] calling  proc_genhd_init+0x0/0x3c @ 1
[    1.456724] initcall proc_genhd_init+0x0/0x3c returned 0 after 6 usecs
[    1.456732] calling  bsg_init+0x0/0x12e @ 1
[    1.456803] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.456812] initcall bsg_init+0x0/0x12e returned 0 after 71 usecs
[    1.456820] calling  noop_init+0x0/0x12 @ 1
[    1.456827] io scheduler noop registered
[    1.456834] initcall noop_init+0x0/0x12 returned 0 after 7 usecs
[    1.456842] calling  deadline_init+0x0/0x12 @ 1
[    1.456849] io scheduler deadline registered
[    1.456856] initcall deadline_init+0x0/0x12 returned 0 after 6 usecs
[    1.456864] calling  cfq_init+0x0/0x8b @ 1
[    1.456878] io scheduler cfq registered (default)
[    1.456885] initcall cfq_init+0x0/0x8b returned 0 after 14 usecs
[    1.456893] calling  percpu_counter_startup+0x0/0x38 @ 1
[    1.456902] initcall percpu_counter_startup+0x0/0x38 returned 0 after 1 usecs
[    1.456910] calling  pci_proc_init+0x0/0x6a @ 1
[    1.654703] initcall pci_proc_init+0x0/0x6a returned 0 after 8 usecs
[    1.654716] calling  pcie_portdrv_init+0x0/0x7a @ 1
[    1.654876] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 148 usecs
[    1.654885] calling  aer_service_init+0x0/0x2b @ 1
[    1.654958] initcall aer_service_init+0x0/0x2b returned 0 after 63 usecs
[    1.654967] calling  pci_hotplug_init+0x0/0x1d @ 1
[    1.654974] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.654982] initcall pci_hotplug_init+0x0/0x1d returned 0 after 6 usecs
[    1.654990] calling  pcifront_init+0x0/0x3f @ 1
[    1.655085] initcall pcifront_init+0x0/0x3f returned 0 after 85 usecs
[    1.655094] calling  genericbl_driver_init+0x0/0x12 @ 1
[    1.655169] initcall genericbl_driver_init+0x0/0x12 returned 0 after 65 usecs
[    1.655178] calling  cirrusfb_init+0x0/0xcc @ 1
[    1.655265] initcall cirrusfb_init+0x0/0xcc returned 0 after 75 usecs
[    1.655277] calling  efifb_init+0x0/0x298 @ 1
[    1.655287] initcall efifb_init+0x0/0x298 returned -19 after 1 usecs
[    1.655297] calling  intel_idle_init+0x0/0x326 @ 1
[    1.655305] initcall intel_idle_init+0x0/0x326 returned -19 after 0 usecs
[    1.655313] calling  acpi_reserve_resources+0x0/0xeb @ 1
[    1.655322] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 usecs
[    1.655330] calling  irqrouter_init_ops+0x0/0x26 @ 1
[    1.655338] initcall irqrouter_init_ops+0x0/0x26 returned 0 after 0 usecs
[    1.655347] calling  acpi_ac_init+0x0/0x28 @ 1
[    1.655357] initcall acpi_ac_init+0x0/0x28 returned -19 after 0 usecs
[    1.655369] calling  acpi_button_driver_init+0x0/0x12 @ 1
[    1.655379] initcall acpi_button_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655390] calling  acpi_fan_driver_init+0x0/0x12 @ 1
[    1.655399] initcall acpi_fan_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655409] calling  acpi_processor_init+0x0/0x6d @ 1
[    1.655419] initcall acpi_processor_init+0x0/0x6d returned 0 after 0 usecs
[    1.655429] calling  acpi_container_init+0x0/0x4a @ 1
[    1.655439] initcall acpi_container_init+0x0/0x4a returned -19 after 0 usecs
[    1.655450] calling  acpi_thermal_init+0x0/0x42 @ 1
[    1.655458] initcall acpi_thermal_init+0x0/0x42 returned -19 after 0 usecs
[    1.655466] calling  acpi_battery_init+0x0/0x16 @ 1
[    1.655478] initcall acpi_battery_init+0x0/0x16 returned 0 after 3 usecs
[    1.655486] calling  acpi_hed_driver_init+0x0/0x12 @ 1
[    1.655494] initcall acpi_hed_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655502] calling  erst_init+0x0/0x2bb @ 1
[    1.655510] initcall erst_init+0x0/0x2bb returned 0 after 0 usecs
[    1.655518] calling  ghes_init+0x0/0x171 @ 1
[    1.655527] initcall ghes_init+0x0/0x171 returned -19 after 0 usecs
[    1.655535] calling  einj_init+0x0/0x49d @ 1
[    1.655543] initcall einj_init+0x0/0x49d returned -19 after 0 usecs
[    1.655551] calling  ioat_init_module+0x0/0x80 @ 1
[    1.655559] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    1.655595] calling  1_acpi_battery_init_async+0x0/0x1b @ 6
[    1.655603] initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 0 usecs
[    1.655672] initcall ioat_init_module+0x0/0x80 returned 0 after 109 usecs
[    1.655683] calling  virtio_mmio_init+0x0/0x12 @ 1
[    1.655766] initcall virtio_mmio_init+0x0/0x12 returned 0 after 72 usecs
[    1.655777] calling  init+0x0/0x12 @ 1
[    1.655855] initcall init+0x0/0x12 returned 0 after 67 usecs
[    1.655864] calling  xenbus_probe_initcall+0x0/0x39 @ 1
[    1.655873] initcall xenbus_probe_initcall+0x0/0x39 returned 0 after 0 usecs
[    1.655882] calling  xenbus_init+0x0/0x3d @ 1
[    1.655975] initcall xenbus_init+0x0/0x3d returned 0 after 81 usecs
[    1.655985] calling  xenbus_backend_init+0x0/0x51 @ 1
[    1.655993] initcall xenbus_backend_init+0x0/0x51 returned -19 after 0 usecs
[    1.656002] calling  gntdev_init+0x0/0x4d @ 1
[    1.656125] initcall gntdev_init+0x0/0x4d returned 0 after 111 usecs
[    1.656134] calling  gntalloc_init+0x0/0x3d @ 1
[    1.656209] initcall gntalloc_init+0x0/0x3d returned 0 after 66 usecs
[    1.656217] calling  hypervisor_subsys_init+0x0/0x25 @ 1
[    1.656225] initcall hypervisor_subsys_init+0x0/0x25 returned 0 after 0 usecs
[    1.656233] calling  hyper_sysfs_init+0x0/0xfb @ 1
[    1.656254] initcall hyper_sysfs_init+0x0/0xfb returned 0 after 13 usecs
[    1.656262] calling  platform_pci_module_init+0x0/0x1b @ 1
[    1.656336] initcall platform_pci_module_init+0x0/0x1b returned 0 after 64 usecs
[    1.656344] calling  xen_tmem_init+0x0/0x9a @ 1
[    1.656352] initcall xen_tmem_init+0x0/0x9a returned 0 after 0 usecs
[    1.656360] calling  xen_late_init_mcelog+0x0/0x3d @ 1
[    1.656367] initcall xen_late_init_mcelog+0x0/0x3d returned -19 after 0 usecs
[    1.656375] calling  xen_pcibk_init+0x0/0x13f @ 1
[    1.656383] initcall xen_pcibk_init+0x0/0x13f returned -19 after 0 usecs
[    1.854937] calling  xen_acpi_processor_init+0x0/0x41f @ 1
[    1.854949] initcall xen_acpi_processor_init+0x0/0x41f returned -19 after 0 usecs
[    1.854957] calling  pty_init+0x0/0x453 @ 1
[    1.890528] initcall pty_init+0x0/0x453 returned 0 after 34728 usecs
[    1.890543] calling  sysrq_init+0x0/0x78 @ 1
[    1.890557] initcall sysrq_init+0x0/0x78 returned 0 after 5 usecs
[    1.890564] calling  xen_hvc_init+0x0/0x249 @ 1
[    1.891318] initcall xen_hvc_init+0x0/0x249 returned 0 after 728 usecs
[    1.891328] calling  serial8250_init+0x0/0x17d @ 1
[    1.891335] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.891949] initcall serial8250_init+0x0/0x17d returned 0 after 598 usecs
[    1.891959] calling  serial_pci_driver_init+0x0/0x1b @ 1
[    1.892030] initcall serial_pci_driver_init+0x0/0x1b returned 0 after 62 usecs
[    1.892040] calling  init_kgdboc+0x0/0x16 @ 1
[    1.892048] initcall init_kgdboc+0x0/0x16 returned 0 after 0 usecs
[    1.892103] calling  rand_initialize+0x0/0x30 @ 1
[    1.892125] initcall rand_initialize+0x0/0x30 returned 0 after 10 usecs
[    1.892135] calling  init+0x0/0x111 @ 1
[    1.892349] initcall init+0x0/0x111 returned 0 after 201 usecs
[    1.892358] calling  hpet_init+0x0/0x6a @ 1
[    1.892517] initcall hpet_init+0x0/0x6a returned -19 after 147 usecs
[    1.892526] calling  nvram_init+0x0/0x82 @ 1
[    1.892602] Non-volatile memory driver v1.3
[    1.892610] initcall nvram_init+0x0/0x82 returned 0 after 74 usecs
[    1.892618] calling  mod_init+0x0/0x5a @ 1
[    1.892625] initcall mod_init+0x0/0x5a returned -19 after 0 usecs
[    1.892633] calling  rng_init+0x0/0x12 @ 1
[    1.892709] initcall rng_init+0x0/0x12 returned 0 after 66 usecs
[    1.892718] calling  agp_init+0x0/0x26 @ 1
[    1.892725] Linux agpgart interface v0.103
[    1.892732] initcall agp_init+0x0/0x26 returned 0 after 6 usecs
[    1.892739] calling  agp_amd64_mod_init+0x0/0x22 @ 1
[    1.892876] initcall agp_amd64_mod_init+0x0/0x22 returned -19 after 125 usecs
[    1.892885] calling  agp_intel_init+0x0/0x29 @ 1
[    1.892955] initcall agp_intel_init+0x0/0x29 returned 0 after 60 usecs
[    1.892964] calling  agp_sis_init+0x0/0x29 @ 1
[    1.893035] initcall agp_sis_init+0x0/0x29 returned 0 after 61 usecs
[    1.893043] calling  agp_via_init+0x0/0x29 @ 1
[    1.893136] initcall agp_via_init+0x0/0x29 returned 0 after 83 usecs
[    1.893144] calling  drm_core_init+0x0/0x139 @ 1
[    1.893223] [drm] Initialized drm 1.1.0 20060810
[    1.893231] initcall drm_core_init+0x0/0x139 returned 0 after 77 usecs
[    1.893239] calling  cn_proc_init+0x0/0x3d @ 1
[    1.893247] initcall cn_proc_init+0x0/0x3d returned 0 after 1 usecs
[    1.893256] calling  topology_sysfs_init+0x0/0x58 @ 1
[    1.893274] initcall topology_sysfs_init+0x0/0x58 returned 0 after 9 usecs
[    1.893282] calling  loop_init+0x0/0x137 @ 1
[    1.895048] loop: module loaded
[    1.895089] initcall loop_init+0x0/0x137 returned 0 after 1757 usecs
[    1.895098] calling  xen_blkif_init+0x0/0x25f @ 1
[    1.895308] initcall xen_blkif_init+0x0/0x25f returned 0 after 197 usecs
[    1.895316] calling  mac_hid_init+0x0/0x22 @ 1
[    1.895328] initcall mac_hid_init+0x0/0x22 returned 0 after 4 usecs
[    1.895336] calling  macvlan_init_module+0x0/0x3d @ 1
[    1.895345] initcall macvlan_init_module+0x0/0x3d returned 0 after 1 usecs
[    1.895353] calling  macvtap_init+0x0/0x100 @ 1
[    1.895419] initcall macvtap_init+0x0/0x100 returned 0 after 56 usecs
[    1.895427] calling  net_olddevs_init+0x0/0x86 @ 1
[    1.895436] initcall net_olddevs_init+0x0/0x86 returned 0 after 1 usecs
[    1.895444] calling  fixed_mdio_bus_init+0x0/0x105 @ 1
[    1.895589] libphy: Fixed MDIO Bus: probed
[    1.895597] initcall fixed_mdio_bus_init+0x0/0x105 returned 0 after 141 usecs
[    1.895605] calling  tun_init+0x0/0x93 @ 1
[    1.895612] tun: Universal TUN/TAP device driver, 1.6
[    1.895618] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.895698] initcall tun_init+0x0/0x93 returned 0 after 83 usecs
[    1.895706] calling  tg3_init+0x0/0x1b @ 1
[    1.895780] initcall tg3_init+0x0/0x1b returned 0 after 65 usecs
[    1.895788] calling  ixgbevf_init_module+0x0/0x4c @ 1
[    2.055322] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k
[    2.055332] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    2.055427] initcall ixgbevf_init_module+0x0/0x4c returned 0 after 101 usecs
[    2.055436] calling  init_nic+0x0/0x1b @ 1
[    2.055512] initcall init_nic+0x0/0x1b returned 0 after 66 usecs
[    2.055521] calling  netback_init+0x0/0x212 @ 1
[    2.055638] initcall netback_init+0x0/0x212 returned 0 after 106 usecs
[    2.055647] calling  nonstatic_sysfs_init+0x0/0x12 @ 1
[    2.055656] initcall nonstatic_sysfs_init+0x0/0x12 returned 0 after 1 usecs
[    2.055664] calling  yenta_socket_init+0x0/0x1b @ 1
[    2.055744] initcall yenta_socket_init+0x0/0x1b returned 0 after 70 usecs
[    2.055754] calling  mon_init+0x0/0xfe @ 1
[    2.055909] initcall mon_init+0x0/0xfe returned 0 after 144 usecs
[    2.055918] calling  ehci_hcd_init+0x0/0xb7 @ 1
[    2.055925] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.055933] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    2.055951] initcall ehci_hcd_init+0x0/0xb7 returned 0 after 24 usecs
[    2.055959] calling  ehci_pci_init+0x0/0x69 @ 1
[    2.055966] ehci-pci: EHCI PCI platform driver
[    2.056038] initcall ehci_pci_init+0x0/0x69 returned 0 after 68 usecs
[    2.056047] calling  ohci_hcd_mod_init+0x0/0xbf @ 1
[    2.056086] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.056094] ohci_hcd: block sizes: ed 80 td 96
[    2.056181] initcall ohci_hcd_mod_init+0x0/0xbf returned 0 after 92 usecs
[    2.056190] calling  uhci_hcd_init+0x0/0x129 @ 1
[    2.056197] uhci_hcd: USB Universal Host Controller Interface driver
[    2.056290] initcall uhci_hcd_init+0x0/0x129 returned 0 after 89 usecs
[    2.056299] calling  usblp_driver_init+0x0/0x1b @ 1
[    2.056375] usbcore: registered new interface driver usblp
[    2.056384] initcall usblp_driver_init+0x0/0x1b returned 0 after 75 usecs
[    2.056393] calling  kgdbdbgp_start_thread+0x0/0x4f @ 1
[    2.056401] initcall kgdbdbgp_start_thread+0x0/0x4f returned 0 after 0 usecs
[    2.056409] calling  i8042_init+0x0/0x3c5 @ 1
[    2.056657] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.068374] i8042: No controller found
[    3.068394] initcall i8042_init+0x0/0x3c5 returned -19 after 988256 usecs
[    3.068403] calling  serport_init+0x0/0x34 @ 1
[    3.068412] initcall serport_init+0x0/0x34 returned 0 after 1 usecs
[    3.068420] calling  mousedev_init+0x0/0x62 @ 1
[    3.068590] mousedev: PS/2 mouse device common for all mice
[    3.068600] initcall mousedev_init+0x0/0x62 returned 0 after 167 usecs
[    3.068608] calling  evdev_init+0x0/0x12 @ 1
[    3.068617] initcall evdev_init+0x0/0x12 returned 0 after 0 usecs
[    3.068625] calling  atkbd_init+0x0/0x27 @ 1
[    3.068713] initcall atkbd_init+0x0/0x27 returned 0 after 78 usecs
[    3.068724] calling  psmouse_init+0x0/0x7b @ 1
[    3.068871] initcall psmouse_init+0x0/0x7b returned 0 after 132 usecs
[    3.068888] calling  cmos_init+0x0/0x6a @ 1
[    3.129156] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    3.129267] rtc_cmos: probe of rtc_cmos failed with error -38
[    3.129462] initcall cmos_init+0x0/0x6a returned -19 after 59144 usecs
[    3.129471] calling  i2c_i801_init+0x0/0xad @ 1
[    3.129552] initcall i2c_i801_init+0x0/0xad returned 0 after 70 usecs
[    3.129562] calling  cpufreq_gov_dbs_init+0x0/0x95 @ 1
[    3.129571] initcall cpufreq_gov_dbs_init+0x0/0x95 returned -19 after 1 usecs
[    3.129580] calling  init_ladder+0x0/0x12 @ 1
[    3.129588] initcall init_ladder+0x0/0x12 returned -19 after 0 usecs
[    3.129596] calling  init_menu+0x0/0x12 @ 1
[    3.129603] initcall init_menu+0x0/0x12 returned -19 after 0 usecs
[    3.129612] calling  efivars_init+0x0/0x105 @ 1
[    3.129619] EFI Variables Facility v0.08 2004-May-17
[    3.129626] initcall efivars_init+0x0/0x105 returned 0 after 6 usecs
[    3.129635] calling  vhost_net_init+0x0/0x30 @ 1
[    3.129714] initcall vhost_net_init+0x0/0x30 returned 0 after 68 usecs
[    3.129723] calling  staging_init+0x0/0x8 @ 1
[    3.129731] initcall staging_init+0x0/0x8 returned 0 after 0 usecs
[    3.129739] calling  zram_init+0x0/0x2e4 @ 1
[    3.129746] zram: num_devices not specified. Using default: 1
[    3.129753] zram: Creating 1 devices ...
[    3.130028] initcall zram_init+0x0/0x2e4 returned 0 after 273 usecs
[    3.130038] calling  zcache_init+0x0/0x297 @ 1
[    3.130115] initcall zcache_init+0x0/0x297 returned 0 after 67 usecs
[    3.130127] calling  zs_init+0x0/0x90 @ 1
[    3.130139] initcall zs_init+0x0/0x90 returned 0 after 3 usecs
[    3.130149] calling  eeepc_laptop_init+0x0/0x58 @ 1
[    3.130320] initcall eeepc_laptop_init+0x0/0x58 returned -19 after 157 usecs
[    3.130331] calling  sock_diag_init+0x0/0x12 @ 1
[    3.130347] initcall sock_diag_init+0x0/0x12 returned 0 after 8 usecs
[    3.130355] calling  flow_cache_init_global+0x0/0x19f @ 1
[    3.130373] initcall flow_cache_init_global+0x0/0x19f returned 0 after 10 usecs
[    3.130382] calling  llc_init+0x0/0x20 @ 1
[    3.130390] initcall llc_init+0x0/0x20 returned 0 after 1 usecs
[    3.130397] calling  snap_init+0x0/0x38 @ 1
[    3.130408] initcall snap_init+0x0/0x38 returned 0 after 1 usecs
[    3.130417] calling  blackhole_module_init+0x0/0x12 @ 1
[    3.130427] initcall blackhole_module_init+0x0/0x12 returned 0 after 0 usecs
[    3.130436] calling  nfnetlink_init+0x0/0x27 @ 1
[    3.130444] Netfilter messages via NETLINK v0.30.
[    3.130464] initcall nfnetlink_init+0x0/0x27 returned 0 after 18 usecs
[    3.130474] calling  nfnetlink_log_init+0x0/0xdb @ 1
[    3.130491] initcall nfnetlink_log_init+0x0/0xdb returned 0 after 9 usecs
[    3.130499] calling  nf_conntrack_standalone_init+0x0/0x12 @ 1
[    3.130507] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    3.130600] initcall nf_conntrack_standalone_init+0x0/0x12 returned 0 after 90 usecs
[    3.130609] calling  ctnetlink_init+0x0/0xa4 @ 1
[    3.130616] ctnetlink v0.93: registering with nfnetlink.
[    3.130623] initcall ctnetlink_init+0x0/0xa4 returned 0 after 6 usecs
[    3.130631] calling  nf_conntrack_ftp_init+0x0/0x1ca @ 1
[    3.130639] initcall nf_conntrack_ftp_init+0x0/0x1ca returned 0 after 0 usecs
[    3.130647] calling  nf_conntrack_irc_init+0x0/0x173 @ 1
[    3.130658] initcall nf_conntrack_irc_init+0x0/0x173 returned 0 after 3 usecs
[    3.130666] calling  nf_conntrack_sip_init+0x0/0x215 @ 1
[    3.130675] initcall nf_conntrack_sip_init+0x0/0x215 returned 0 after 0 usecs
[    3.130683] calling  xt_init+0x0/0x118 @ 1
[    3.130693] initcall xt_init+0x0/0x118 returned 0 after 1 usecs
[    3.130701] calling  tcpudp_mt_init+0x0/0x17 @ 1
[    3.130709] initcall tcpudp_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.130717] calling  connsecmark_tg_init+0x0/0x12 @ 1
[    3.268638] initcall connsecmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268647] calling  nflog_tg_init+0x0/0x12 @ 1
[    3.268656] initcall nflog_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268664] calling  secmark_tg_init+0x0/0x12 @ 1
[    3.268671] initcall secmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268679] calling  tcpmss_tg_init+0x0/0x17 @ 1
[    3.268687] initcall tcpmss_tg_init+0x0/0x17 returned 0 after 0 usecs
[    3.268696] calling  conntrack_mt_init+0x0/0x17 @ 1
[    3.268707] initcall conntrack_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.268715] calling  policy_mt_init+0x0/0x17 @ 1
[    3.268723] initcall policy_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.268730] calling  state_mt_init+0x0/0x12 @ 1
[    3.268738] initcall state_mt_init+0x0/0x12 returned 0 after 0 usecs
[    3.268746] calling  sysctl_ipv4_init+0x0/0x92 @ 1
[    3.268793] initcall sysctl_ipv4_init+0x0/0x92 returned 0 after 37 usecs
[    3.268804] calling  init_syncookies+0x0/0x19 @ 1
[    3.268835] initcall init_syncookies+0x0/0x19 returned 0 after 21 usecs
[    3.268845] calling  tunnel4_init+0x0/0x72 @ 1
[    3.268854] initcall tunnel4_init+0x0/0x72 returned 0 after 0 usecs
[    3.268865] calling  ipv4_netfilter_init+0x0/0x12 @ 1
[    3.268876] initcall ipv4_netfilter_init+0x0/0x12 returned 0 after 0 usecs
[    3.268886] calling  nf_conntrack_l3proto_ipv4_init+0x0/0xb8 @ 1
[    3.269010] initcall nf_conntrack_l3proto_ipv4_init+0x0/0xb8 returned 0 after 110 usecs
[    3.269021] calling  nf_defrag_init+0x0/0x17 @ 1
[    3.269029] initcall nf_defrag_init+0x0/0x17 returned 0 after 0 usecs
[    3.269037] calling  ip_tables_init+0x0/0xaa @ 1
[    3.269064] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.269072] initcall ip_tables_init+0x0/0xaa returned 0 after 26 usecs
[    3.269083] calling  iptable_filter_init+0x0/0x51 @ 1
[    3.269107] initcall iptable_filter_init+0x0/0x51 returned 0 after 13 usecs
[    3.269118] calling  iptable_mangle_init+0x0/0x51 @ 1
[    3.269139] initcall iptable_mangle_init+0x0/0x51 returned 0 after 10 usecs
[    3.269150] calling  reject_tg_init+0x0/0x12 @ 1
[    3.269159] initcall reject_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.269169] calling  ulog_tg_init+0x0/0x104 @ 1
[    3.269184] initcall ulog_tg_init+0x0/0x104 returned 0 after 5 usecs
[    3.269195] calling  cubictcp_register+0x0/0x5c @ 1
[    3.269204] TCP: cubic registered
[    3.269213] initcall cubictcp_register+0x0/0x5c returned 0 after 9 usecs
[    3.269221] calling  xfrm_user_init+0x0/0x4a @ 1
[    3.269230] Initializing XFRM netlink socket
[    3.269244] initcall xfrm_user_init+0x0/0x4a returned 0 after 12 usecs
[    3.269255] calling  inet6_init+0x0/0x315 @ 1
[    3.269288] NET: Registered protocol family 10
[    3.269523] initcall inet6_init+0x0/0x315 returned 0 after 252 usecs
[    3.269532] calling  ah6_init+0x0/0x79 @ 1
[    3.269539] initcall ah6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269547] calling  esp6_init+0x0/0x79 @ 1
[    3.269555] initcall esp6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269563] calling  xfrm6_transport_init+0x0/0x17 @ 1
[    3.269571] initcall xfrm6_transport_init+0x0/0x17 returned 0 after 0 usecs
[    3.269579] calling  xfrm6_mode_tunnel_init+0x0/0x17 @ 1
[    3.269587] initcall xfrm6_mode_tunnel_init+0x0/0x17 returned 0 after 0 usecs
[    3.269595] calling  xfrm6_beet_init+0x0/0x17 @ 1
[    3.269602] initcall xfrm6_beet_init+0x0/0x17 returned 0 after 0 usecs
[    3.269610] calling  ip6_tables_init+0x0/0xaa @ 1
[    3.269627] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    3.269635] initcall ip6_tables_init+0x0/0xaa returned 0 after 16 usecs
[    3.269643] calling  ip6table_filter_init+0x0/0x51 @ 1
[    3.269764] initcall ip6table_filter_init+0x0/0x51 returned 0 after 110 usecs
[    3.269773] calling  ip6table_mangle_init+0x0/0x51 @ 1
[    3.269822] initcall ip6table_mangle_init+0x0/0x51 returned 0 after 40 usecs
[    3.269831] calling  nf_conntrack_l3proto_ipv6_init+0x0/0x8a @ 1
[    3.269846] initcall nf_conntrack_l3proto_ipv6_init+0x0/0x8a returned 0 after 6 usecs
[    3.269855] calling  nf_defrag_init+0x0/0x54 @ 1
[    3.269868] initcall nf_defrag_init+0x0/0x54 returned 0 after 5 usecs
[    3.269876] calling  ipv6header_mt6_init+0x0/0x12 @ 1
[    3.269884] initcall ipv6header_mt6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269892] calling  reject_tg6_init+0x0/0x12 @ 1
[    3.269900] initcall reject_tg6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269908] calling  sit_init+0x0/0x8c @ 1
[    3.269914] sit: IPv6 over IPv4 tunneling driver
[    3.270252] initcall sit_init+0x0/0x8c returned 0 after 329 usecs
[    3.270261] calling  packet_init+0x0/0x47 @ 1
[    3.270268] NET: Registered protocol family 17
[    3.270280] initcall packet_init+0x0/0x47 returned 0 after 11 usecs
[    3.468657] calling  br_init+0x0/0xa2 @ 1
[    3.468683] initcall br_init+0x0/0xa2 returned 0 after 16 usecs
[    3.468691] calling  init_rpcsec_gss+0x0/0x64 @ 1
[    3.468734] initcall init_rpcsec_gss+0x0/0x64 returned 0 after 32 usecs
[    3.468745] calling  dcbnl_init+0x0/0x4d @ 1
[    3.468756] initcall dcbnl_init+0x0/0x4d returned 0 after 0 usecs
[    3.468765] calling  init_dns_resolver+0x0/0xe4 @ 1
[    3.468790] Key type dns_resolver registered
[    3.468801] initcall init_dns_resolver+0x0/0xe4 returned 0 after 23 usecs
[    3.468812] calling  mcheck_init_device+0x0/0x123 @ 1
[    3.468822] initcall mcheck_init_device+0x0/0x123 returned -5 after 0 usecs
[    3.468833] initcall mcheck_init_device+0x0/0x123 returned with error code -5 
[    3.468865] calling  tboot_late_init+0x0/0x216 @ 1
[    3.468875] initcall tboot_late_init+0x0/0x216 returned 0 after 0 usecs
[    3.468885] calling  mcheck_debugfs_init+0x0/0x3c @ 1
[    3.468915] initcall mcheck_debugfs_init+0x0/0x3c returned 0 after 19 usecs
[    3.468923] calling  severities_debugfs_init+0x0/0x3c @ 1
[    3.468942] initcall severities_debugfs_init+0x0/0x3c returned 0 after 7 usecs
[    3.468954] calling  threshold_init_device+0x0/0x8d @ 1
[    3.468964] initcall threshold_init_device+0x0/0x8d returned 0 after 0 usecs
[    3.468975] calling  hpet_insert_resource+0x0/0x23 @ 1
[    3.468985] initcall hpet_insert_resource+0x0/0x23 returned 1 after 0 usecs
[    3.468995] initcall hpet_insert_resource+0x0/0x23 returned with error code 1 
[    3.469007] calling  update_mp_table+0x0/0x56d @ 1
[    3.469018] initcall update_mp_table+0x0/0x56d returned 0 after 0 usecs
[    3.469028] calling  lapic_insert_resource+0x0/0x3f @ 1
[    3.469037] initcall lapic_insert_resource+0x0/0x3f returned -1 after 0 usecs
[    3.469047] initcall lapic_insert_resource+0x0/0x3f returned with error code -1 
[    3.469072] calling  io_apic_bug_finalize+0x0/0x1b @ 1
[    3.469083] initcall io_apic_bug_finalize+0x0/0x1b returned 0 after 0 usecs
[    3.469092] calling  print_ICs+0x0/0x508 @ 1
[    3.469102] initcall print_ICs+0x0/0x508 returned 0 after 0 usecs
[    3.469112] calling  check_early_ioremap_leak+0x0/0x65 @ 1
[    3.469122] initcall check_early_ioremap_leak+0x0/0x65 returned 0 after 0 usecs
[    3.469133] calling  pat_memtype_list_init+0x0/0x32 @ 1
[    3.469156] initcall pat_memtype_list_init+0x0/0x32 returned 0 after 13 usecs
[    3.469169] calling  init_oops_id+0x0/0x40 @ 1
[    3.469189] initcall init_oops_id+0x0/0x40 returned 0 after 4 usecs
[    3.469199] calling  printk_late_init+0x0/0x59 @ 1
[    3.469211] initcall printk_late_init+0x0/0x59 returned 0 after 1 usecs
[    3.469220] calling  pm_qos_power_init+0x0/0x7b @ 1
[    3.469460] initcall pm_qos_power_init+0x0/0x7b returned 0 after 223 usecs
[    3.469469] calling  pm_debugfs_init+0x0/0x24 @ 1
[    3.469483] initcall pm_debugfs_init+0x0/0x24 returned 0 after 6 usecs
[    3.469492] calling  software_resume+0x0/0x290 @ 1
[    3.469499] PM: Hibernation image not present or could not be loaded.
[    3.469507] initcall software_resume+0x0/0x290 returned -2 after 7 usecs
[    3.469515] initcall software_resume+0x0/0x290 returned with error code -2 
[    3.469524] calling  debugfs_kprobe_init+0x0/0x90 @ 1
[    3.469551] initcall debugfs_kprobe_init+0x0/0x90 returned 0 after 19 usecs
[    3.469559] calling  taskstats_init+0x0/0x95 @ 1
[    3.469570] registered taskstats version 1
[    3.469577] initcall taskstats_init+0x0/0x95 returned 0 after 10 usecs
[    3.469585] calling  clear_boot_tracer+0x0/0x2d @ 1
[    3.469593] initcall clear_boot_tracer+0x0/0x2d returned 0 after 0 usecs
[    3.469601] calling  max_swapfiles_check+0x0/0x8 @ 1
[    3.469608] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs
[    3.469617] calling  set_recommended_min_free_kbytes+0x0/0xa0 @ 1
[    3.469625] initcall set_recommended_min_free_kbytes+0x0/0xa0 returned 0 after 0 usecs
[    3.469634] calling  fail_make_request_debugfs+0x0/0x2a @ 1
[    3.469692] initcall fail_make_request_debugfs+0x0/0x2a returned 0 after 49 usecs
[    3.469701] calling  prandom_reseed+0x0/0xb4 @ 1
[    3.469722] initcall prandom_reseed+0x0/0xb4 returned 0 after 13 usecs
[    3.469730] calling  pci_resource_alignment_sysfs_init+0x0/0x19 @ 1
[    3.469740] initcall pci_resource_alignment_sysfs_init+0x0/0x19 returned 0 after 1 usecs
[    3.469748] calling  pci_sysfs_init+0x0/0x51 @ 1
[    3.469757] initcall pci_sysfs_init+0x0/0x51 returned 0 after 1 usecs
[    3.469765] calling  boot_wait_for_devices+0x0/0x30 @ 1
[    3.669552] XENBUS: Device with no driver: device/vif/0
[    3.669562] initcall boot_wait_for_devices+0x0/0x30 returned 0 after 12 usecs
[    3.669575] calling  random_int_secret_init+0x0/0x19 @ 1
[    3.669594] initcall random_int_secret_init+0x0/0x19 returned 0 after 10 usecs
[    3.669604] calling  deferred_probe_initcall+0x0/0x60 @ 1
[    3.669664] initcall deferred_probe_initcall+0x0/0x60 returned 0 after 50 usecs
[    3.669681] calling  late_resume_init+0x0/0x1d0 @ 1
[    3.669690]   Magic number: 1:252:3141
[    3.669768] initcall late_resume_init+0x0/0x1d0 returned 0 after 75 usecs
[    3.669778] calling  firmware_memmap_init+0x0/0x38 @ 1
[    3.669805] initcall firmware_memmap_init+0x0/0x38 returned 0 after 18 usecs
[    3.669815] calling  pci_mmcfg_late_insert_resources+0x0/0x50 @ 1
[    3.669824] initcall pci_mmcfg_late_insert_resources+0x0/0x50 returned 0 after 0 usecs
[    3.669835] calling  net_secret_init+0x0/0x19 @ 1
[    3.669857] initcall net_secret_init+0x0/0x19 returned 0 after 11 usecs
[    3.669866] calling  tcp_congestion_default+0x0/0x12 @ 1
[    3.669878] initcall tcp_congestion_default+0x0/0x12 returned 0 after 1 usecs
[    3.669889] calling  tcp_fastopen_init+0x0/0x30 @ 1
[    3.669910] initcall tcp_fastopen_init+0x0/0x30 returned 0 after 11 usecs
[    3.669921] calling  ip_auto_config+0x0/0xe62 @ 1
[    3.669937] initcall ip_auto_config+0x0/0xe62 returned 0 after 5 usecs
[    3.669947] calling  initialize_hashrnd+0x0/0x19 @ 1
[    3.669961] initcall initialize_hashrnd+0x0/0x19 returned 0 after 4 usecs
[    3.670862] Freeing unused kernel memory: 756k freed
[    3.671087] Write protecting the kernel read-only data: 10240k
[    3.677203] Freeing unused kernel memory: 1620k freed
[    3.677696] Freeing unused kernel memory: 136k freed
init started: BusyBox v1.14.3 (2013-01-15 17:27:03 EST)
[    3.683393] consoletype (1029) used greatest stack depth: 5288 bytes left
Mounting directories  [  OK  ]
mount: mount point /proc/bus/usb does not exist
[    3.991865] calling  privcmd_init+0x0/0x1000 [xen_privcmd] @ 1058
[    3.991978] initcall privcmd_init+0x0/0x1000 [xen_privcmd] returned 0 after 93 usecs
[    3.992361] calling  xenfs_init+0x0/0x1000 [xenfs] @ 1058
[    3.992373] initcall xenfs_init+0x0/0x1000 [xenfs] returned 0 after 1 usecs
[    3.992538] modprobe (1058) used greatest stack depth: 5272 bytes left
mount: mount point /sys/kernel/config does not exist
[    4.003403] core_filesystem (1030) used greatest stack depth: 4984 bytes left
[    4.012398] calling  xenkbd_init+0x0/0x1000 [xen_kbdfront] @ 1069
[    4.012500] initcall xenkbd_init+0x0/0x1000 [xen_kbdfront] returned 0 after 84 usecs
[    4.015993] calling  xenfb_init+0x0/0x1000 [xen_fbfront] @ 1072
[    4.016125] initcall xenfb_init+0x0/0x1000 [xen_fbfront] returned 0 after 113 usecs
[    4.019032] calling  netif_init+0x0/0x1000 [xen_netfront] @ 1079
[    4.019044] Initialising Xen virtual ethernet driver.
[    4.119124] initcall netif_init+0x0/0x1000 [xen_netfront] returned 0 after 97731 usecs
[    4.121939] calling  xlblk_init+0x0/0x1000 [xen_blkfront] @ 1085
[    4.122045] initcall xlblk_init+0x0/0x1000 [xen_blkfront] returned 0 after 87 usecs
[    4.136417] udevd (1091): /proc/1091/oom_adj is deprecated, please use /proc/1091/oom_score_adj instead.
udevd-work[1093]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory

[    4.190158] calling  crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] @ 1112
[    4.190457] initcall crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] returned 0 after 273 usecs
[    4.294865] ip (1240) used greatest stack depth: 3896 bytes left
Waiting for devices [  OK  ]
Waiting for fb [  OK  ]
Starting..[/dev/fb0]
Could not open; err: 2
FATAL: Module agpgart_intel not found.
[    4.617936] calling  drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] @ 1861
[    4.618103] initcall drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] returned 0 after 143 usecs
[    4.622178] calling  ttm_init+0x0/0x1000 [ttm] @ 1861
[    4.622835] initcall ttm_init+0x0/0x1000 [ttm] returned 0 after 623 usecs
[    4.638477] calling  radeon_init+0x0/0x1000 [radeon] @ 1861
[    4.638494] [drm] radeon kernel modesetting enabled.
[    4.639366] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 831 usecs
[    4.644900] calling  acpi_wmi_init+0x0/0x1000 [wmi] @ 1872
[    4.644911] initcall acpi_wmi_init+0x0/0x1000 [wmi] returned -19 after 0 usecs
[    4.645279] calling  fb_console_init+0x0/0x1000 [fbcon] @ 1863
WARNING: Error inserting video (/lib/modules/3.8.0-rc2upstream/kernel/drivers/acpi/video.ko): No such device
WARNING: Error inserting mxm_wmi (/lib/modules/3.8.0-rc2upstream/kernel/drivers/platform/x86/mxm-wmi.ko): No such device
WARNING: Error inserting drm_kms_helper (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
WARNING: Error inserting ttm (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device
FATAL: Error inserting nouveau (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device
[    4.648295] initcall fb_console_init+0x0/0x1000 [fbcon] returned 0 after 2934 usecs
[    4.648680] calling  acpi_video_init+0x0/0xfee [video] @ 1877
[    4.648692] initcall acpi_video_init+0x0/0xfee [video] returned -19 after 1 usecs
WARNING: Error inserting drm_kms_helper (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
FATAL: Error inserting i915 (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/i915/i915.ko): No such device
Starting..[/dev/fb0]
Could not open; err: 2
VGA: 0000:
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  [    4.919737] device eth0 entered promiscuous mode
[  OK  ]
Bringing up interface switch:  
Determining IP information for switch...[    4.973883] switch: port 1(eth0) entered forwarding state
[    4.973901] switch: port 1(eth0) entered forwarding state
 done.
[  OK  ]
Waiting for init.custom [  OK  ]

Starting SSHd ...

    SSH started [2158]


Waiting for SSHd [  OK  ]
WARNING: ssh currently running [2158] ignoring start request
FATAL: Module dump_dma not found.
ERROR: Module dump_dma does not exist in /proc/modules
[    7.304760] calling  crc32c_mod_init+0x0/0x1000 [crc32c] @ 2192
[    7.304839] initcall crc32c_mod_init+0x0/0x1000 [crc32c] returned 0 after 60 usecs
[    7.307385] calling  libcrc32c_mod_init+0x0/0x1000 [libcrc32c] @ 2195
[    7.307403] initcall libcrc32c_mod_init+0x0/0x1000 [libcrc32c] returned 0 after 2 usecs
[    7.313643] calling  init_scsi+0x0/0x91 [scsi_mod] @ 2197
[    7.314342] SCSI subsystem initialized
[    7.314356] initcall init_scsi+0x0/0x91 [scsi_mod] returned 0 after 679 usecs
[    7.316111] calling  iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] @ 2197
[    7.316129] Loading iSCSI transport class v2.0-870.
[    7.317289] initcall iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] returned 0 after 1129 usecs
[    7.319114] calling  iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] @ 2197
[    7.319320] iscsi: registered transport (tcp)
[    7.319329] initcall iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] returned 0 after 198 usecs
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get list of targets from firmware.
Feb 22 21:46:33 g-pvops syslogd 1.5.0: restart.
Running in PV context on Xen v4.2.
FATAL: Module evtchn not found.
[    7.371756] calling  evtchn_init+0x0/0x1000 [xen_evtchn] @ 2237
[    7.372190] Event-channel device installed.
[    7.372199] initcall evtchn_init+0x0/0x1000 [xen_evtchn] returned 0 after 420 usecs
           CPU0       
 16:       2640  xen-percpu-virq      timer0
 17:          0  xen-percpu-ipi       spinlock0
 18:         29  xen-percpu-ipi       resched0
 19:          3  xen-percpu-ipi       callfunc0
 20:          0  xen-percpu-virq      debug0
 21:          1  xen-percpu-ipi       callfuncsingle0
 22:          0  xen-percpu-ipi       irqwork0
 23:         85   xen-dyn-event     hvc_console
 24:         20   xen-dyn-event     eth0
 37:        139   xen-dyn-event     xenbus
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
IWI:          0   IRQ work interrupts
RTR:          0   APIC ICR read retries
RES:         29   Rescheduling interrupts
CAL:          4   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:          0   Machine check polls
ERR:          0
MIS:          0
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-5ddfffff : System RAM
  01000000-01668597 : Kernel code
  01668598-01aa69ff : Kernel data
  01b6c000-01c6efff : Kernel bss
MemTotal:        1499108 kB
MemFree:         1111008 kB
Buffers:               0 kB
Cached:           353132 kB
SwapCached:            0 kB
Active:            21064 kB
Inactive:         331820 kB
Active(anon):      15064 kB
Inactive(anon):   160104 kB
Active(file):       6000 kB
Inactive(file):   171716 kB
Unevictable:        4928 kB
Mlocked:            4928 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          4748 kB
Mapped:             5124 kB
Shmem:            171788 kB
Slab:              18968 kB
SReclaimable:      11300 kB
SUnreclaim:         7668 kB
KernelStack:         464 kB
PageTables:          736 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      749552 kB
Committed_AS:     180652 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        3924 kB
VmallocChunk:   34359734387 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1538048 kB
DirectMap2M:           0 kB
Waiting for init.late [  OK  ]
PING build.dumpdata.com (192.168.101.3) 56(84) bytes of data.

--- build.dumpdata.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 0.310/0.310/0.310/0.000 ms
[    7.471343] mount.nfs (2258) used greatest stack depth: 3480 bytes left
NFS done
 [0x0->0x5de00] pfn
 [0x0->0x5de00] level entry
 [0x5de00->0x80000] level middle
 [0x5de00->0x7cfffff] missing
 [0x80000->0x7cfffff] level top
libxl: error: libxl.c:87:libxl_ctx_alloc: Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
cannot init xl context
[    8.469522] calling  dm_init+0x0/0x48 [dm_mod] @ 2272
[    8.470002] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[    8.470021] initcall dm_init+0x0/0x48 [dm_mod] returned 0 after 467 usecs
[    8.471073] calling  dm_multipath_init+0x0/0x1000 [dm_multipath] @ 2272
[    8.471163] device-mapper: multipath: version 1.5.0 loaded
[    8.471175] initcall dm_multipath_init+0x0/0x1000 [dm_multipath] returned 0 after 83 usecs
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260]
[    8.734032] scsi0 : iSCSI Initiator over TCP/IP
[    8.991392] scsi 0:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[    8.995124] calling  init_sd+0x0/0x1000 [sd_mod] @ 2290
[    8.995995] initcall init_sd+0x0/0x1000 [sd_mod] returned 0 after 833 usecs
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] successful.
[    8.999267] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    8.999841] sd 0:0:0:0: [sda] Write Protect is off
[    8.999852] sd 0:0:0:0: [sda] Mode Sense: 2f 00 00 00
[    9.000230] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    9.003886]  sda: unknown partition table
[    9.005627] sd 0:0:0:0: [sda] Attached SCSI disk
[    9.008859] calling  init_sg+0x0/0x1000 [sg] @ 2303
[    9.009224] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    9.009265] initcall init_sg+0x0/0x1000 [sg] returned 0 after 380 usecs
Feb 22 21:46:35 g-pvops iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] through [iface: default] is operational now
  PV /dev/sda   VG guests   lvm2 [931.51 GiB / 176.51 GiB free]
  Total: 1 [931.51 GiB] / in use: 1 [931.51 GiB] / in no VG: 0 [0   ]
[   14.059832] bio: create slab <bio-1> at 1
  26 logical volume(s) in volume group "guests" now active
22 Feb 21:46:44 ntpdate[2421]: step time server 17.171.4.34 offset 0.785497 sec
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Fri Feb 22 21:46:44 UTC 2013
Feb 22 21:46:44 g-pvops init: starting pid 2437, tty '/dev/tty0': '/bin/sh'
Feb 22 21:46:44 g-pvops init: starting pid 2438, tty '/dev/tty1': '/bin/sh'
Feb 22 21:46:44 g-pvops init: starting pid 2439, tty '/dev/ttyS0': '/bin/sh'


BusyBox v1.14.3 (2013-01-15 17:27:03 EST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# Feb 22 21:46:44 g-pvops init: starting pid 2440, tty '/dev/hvc0': '/bin/sh'
Feb 22 21:46:45 g-pvops init: process '/bin/sh' (pid 2439) exited. Scheduling for restart.
Feb 22 21:46:45 g-pvops init: starting pid 2441, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:46 g-pvops init: process '/bin/sh' (pid 2441) exited. Scheduling for restart.
Feb 22 21:46:46 g-pvops init: starting pid 2442, tty '/dev/ttyS0': '/bin/sh'
[   20.000116] switch: port 1(eth0) entered forwarding state
Feb 22 21:46:47 g-pvops init: process '/bin/sh' (pid 2442) exited. Scheduling for restart.
Feb 22 21:46:47 g-pvops init: starting pid 2443, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:48 g-pvops init: process '/bin/sh' (pid 2443) exited. Scheduling for restart.
Feb 22 21:46:48 g-pvops init: starting pid 2444, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:49 g-pvops init: process '/bin/sh' (pid 2444) exited. Scheduling for restart.
Feb 22 21:46:49 g-pvops init: starting pid 2445, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:50 g-pvops init: process '/bin/sh' (pid 2445) exited. Scheduling for restart.
Feb 22 21:46:50 g-pvops init: starting pid 2446, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:51 g-pvops init: process '/bin/sh' (pid 2446) exited. Scheduling for restart.
Feb 22 21:46:51 g-pvops init: starting pid 2447, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:52 g-pvops init: process '/bin/sh' (pid 2447) exited. Scheduling for restart.
Feb 22 21:46:52 g-pvops init: starting pid 2448, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:53 g-pvops init: process '/bin/sh' (pid 2448) exited. Scheduling for restart.
Feb 22 21:46:53 g-pvops init: starting pid 2449, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:54 g-pvops init: process '/bin/sh' (pid 2449) exited. Scheduling for restart.
Feb 22 21:46:54 g-pvops init: starting pid 2450, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:55 g-pvops init: process '/bin/sh' (pid 2450) exited. Scheduling for restart.
Feb 22 21:46:55 g-pvops init: starting pid 2451, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:56 g-pvops init: process '/bin/sh' (pid 2451) exited. Scheduling for restart.
Feb 22 21:46:56 g-pvops init: starting pid 2452, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:57 g-pvops init: process '/bin/sh' (pid 2452) exited. Scheduling for restart.
Feb 22 21:46:57 g-pvops init: starting pid 2453, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:58 g-pvops init: process '/bin/sh' (pid 2453) exited. Scheduling for restart.
Feb 22 21:46:58 g-pvops init: starting pid 2454, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:59 g-pvops init: process '/bin/sh' (pid 2454) exited. Scheduling for restart.
Feb 22 21:46:59 g-pvops init: starting pid 2455, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:00 g-pvops init: process '/bin/sh' (pid 2455) exited. Scheduling for restart.
Feb 22 21:47:00 g-pvops init: starting pid 2456, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:01 g-pvops init: process '/bin/sh' (pid 2456) exited. Scheduling for restart.
Feb 22 21:47:01 g-pvops init: starting pid 2457, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:02 g-pvops init: process '/bin/sh' (pid 2457) exited. Scheduling for restart.
Feb 22 21:47:02 g-pvops init: starting pid 2458, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:03 g-pvops init: process '/bin/sh' (pid 2458) exited. Scheduling for restart.
Feb 22 21:47:03 g-pvops init: starting pid 2459, tty '/dev/ttyS0': '/bin/sh'
kill -Feb 22 21:47:04 g-pvops init: process '/bin/sh' (pid 2459) exited. Scheduling for restart.
Feb 22 21:47:04 g-pvops init: starting pid 2460, tty '/dev/ttyS0': '/bin/sh'
1 1
# Feb 22 21:47:05 g-pvops init: reloading /etc/inittab
dmesg
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0-rc2upstream (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 16:38:14 EST 2013
[    0.000000] Command line: console=hvc0 debug earlyprintk=xen memblock=debug loglevel=8 initcall_debug
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000005ddfffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x5de00 max_arch_pfn = 0x400000000
[    0.000000] memblock_reserve: [0x00000001c6f000-0x00000001c7e000] setup_arch+0x5e5/0xbc6
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x5dd90000 reserved size = 0x15b87000
[    0.000000]  memory.cnt  = 0x2
[    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009ffff], 0x90000 bytes
[    0.000000]  memory[0x1]	[0x00000000100000-0x0000005ddfffff], 0x5dd00000 bytes
[    0.000000]  reserved.cnt  = 0x3
[    0.000000]  reserved[0x0]	[0x00000001000000-0x00000001c7dfff], 0xc7e000 bytes
[    0.000000]  reserved[0x1]	[0x0000000208c000-0x00000016edafff], 0x14e4f000 bytes
[    0.000000]  reserved[0x2]	[0x00000016ede000-0x00000016f97fff], 0xba000 bytes
[    0.000000] initial memory mapped: [mem 0x00000000-0x16be8fff]
[    0.000000] memblock_reserve: [0x0000000009a000-0x000000000a0000] setup_real_mode+0x69/0x19b
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x5ddfffff]
[    0.000000]  [mem 0x00000000-0x5ddfffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x5ddfffff @ [mem 0x01d9a000-0x0208bfff]
[    0.000000] memblock_reserve: [0x00000001d9a000-0x00000001fd0000] native_pagetable_reserve+0xc/0xe
[    0.000000] xen: setting RW the range 1fd0000 - 208c000
[    0.000000] RAMDISK: [mem 0x0208c000-0x16be8fff]
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000005ddfffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x5ddfffff]
[    0.000000] memblock_reserve: [0x0000005ddfc000-0x0000005de00000] memblock_alloc_base_nid+0x3f/0x52
[    0.000000]   NODE_DATA [mem 0x5ddfc000-0x5ddfffff]
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x5dd90000 reserved size = 0x15dc7000
[    0.000000]  memory.cnt  = 0x2
[    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009ffff], 0x90000 bytes on node 0
[    0.000000]  memory[0x1]	[0x00000000100000-0x0000005ddfffff], 0x5dd00000 bytes on node 0
[    0.000000]  reserved.cnt  = 0x6
[    0.000000]  reserved[0x0]	[0x0000000009a000-0x0000000009ffff], 0x6000 bytes
[    0.000000]  reserved[0x1]	[0x00000001000000-0x00000001c7dfff], 0xc7e000 bytes
[    0.000000]  reserved[0x2]	[0x00000001d9a000-0x00000001fcffff], 0x236000 bytes
[    0.000000]  reserved[0x3]	[0x0000000208c000-0x00000016edafff], 0x14e4f000 bytes
[    0.000000]  reserved[0x4]	[0x00000016ede000-0x00000016f97fff], 0xba000 bytes
[    0.000000]  reserved[0x5]	[0x0000005ddfc000-0x0000005ddfffff], 0x4000 bytes
[    0.000000] memblock_reserve: [0x0000005ddfb000-0x0000005ddfc000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d9fb000-0x0000005ddfb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d9fae80-0x0000005d9fb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5fae80-0x0000005d9fae80] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005bc00000-0x0000005d400000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f9000-0x0000005d5fa000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f8000-0x0000005d5f9000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f7000-0x0000005d5f8000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f6000-0x0000005d5f7000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f5000-0x0000005d5f6000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f4000-0x0000005d5f5000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f3000-0x0000005d5f4000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f2000-0x0000005d5f3000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f1000-0x0000005d5f2000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f0000-0x0000005d5f1000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5ef000-0x0000005d5f0000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5ee000-0x0000005d5ef000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5ed000-0x0000005d5ee000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x0000005d100000-0x0000005d400000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d5fae80-0x0000005d9fae80] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d9fb000-0x0000005ddfb000] free_bootmem+0x9/0xb
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009ffff]
[    0.000000]   node   0: [mem 0x00100000-0x5ddfffff]
[    0.000000] On node 0 totalpages: 384400
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3922 pages, LIFO batch:0
[    0.000000] memblock_reserve: [0x0000005dde3000-0x0000005ddfb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]   DMA32 zone: 5201 pages used for memmap
[    0.000000]   DMA32 zone: 375215 pages, LIFO batch:31
[    0.000000] memblock_reserve: [0x0000005ddcb000-0x0000005dde3000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dadc000-0x0000005ddcb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x00000016be9000-0x00000016ed8000] xen_pagetable_init+0xc9/0x1d8
[    0.000000] memblock_reserve: [0x0000005dadb000-0x0000005dadc000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dada000-0x0000005dadb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad9000-0x0000005dada000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad8000-0x0000005dad9000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] smpboot: Allowing 3 CPUs, 0 hotplug CPUs
[    0.000000] No local APIC present
[    0.000000] APIC: disable apic facility
[    0.000000] APIC: switched to apic NOOP
[    0.000000] nr_irqs_gsi: 16
[    0.000000] memblock_reserve: [0x0000005dad7f00-0x0000005dad7fe0] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7e80-0x0000005dad7ee8] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7e00-0x0000005dad7e68] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7d80-0x0000005dad7de8] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7d40-0x0000005dad7d60] __alloc_memory_core_early+0x5c/0x64
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] e820: [mem 0x5de00000-0xffffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.0 (preserve-AD)
[    0.000000] memblock_reserve: [0x0000005dad7cc0-0x0000005dad7d0c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7c40-0x0000005dad7c8c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:3 nr_node_ids:1
[    0.000000] memblock_reserve: [0x0000005dad6c40-0x0000005dad7c40] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5c40-0x0000005dad6c40] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d600000-0x0000005d800000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x0000005d61c000-0x0000005d680000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d69c000-0x0000005d700000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d71c000-0x0000005d780000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d780000-0x0000005d800000] free_bootmem+0x9/0xb
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88005d600000 s84480 r8192 d22016 u524288
[    0.000000] memblock_reserve: [0x0000005dad5c00-0x0000005dad5c08] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5bc0-0x0000005dad5bc8] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5b80-0x0000005dad5b8c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5b40-0x0000005dad5b58] __alloc_memory_core_early+0x5c/0x64
[    0.000000] pcpu-alloc: s84480 r8192 d22016 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 - 
[    0.000000] memblock_reserve: [0x0000005dad5a00-0x0000005dad5b30] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5980-0x0000005dad59d0] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5900-0x0000005dad5950] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x0000005dad6c40-0x0000005dad7c40] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005dad5c40-0x0000005dad6c40] free_bootmem+0x9/0xb
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 379137
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: console=hvc0 debug earlyprintk=xen memblock=debug loglevel=8 initcall_debug
[    0.000000] memblock_reserve: [0x0000005dacd900-0x0000005dad5900] __alloc_memory_core_early+0x5c/0x64
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] memblock_reserve: [0x0000005dad7900-0x0000005dad7c40] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad78c0-0x0000005dad78cc] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7880-0x0000005dad788c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] Memory: 1157280k/1538048k available (6561k kernel code, 448k absent, 380320k reserved, 4345k data, 756k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=3.
[    0.000000] NR_IRQS:33024 nr_irqs:296 16
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.001000] pid_max: default: 32768 minimum: 301
[    0.001000] Security Framework initialized
[    0.001000] SELinux:  Initializing.
[    0.001000] SELinux:  Starting in permissive mode
[    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001186] Mount-cache hash table entries: 256
[    0.001416] Initializing cgroup subsys cpuacct
[    0.001422] Initializing cgroup subsys freezer
[    0.001477] tseg: 00adf00000
[    0.001484] CPU: Physical Processor ID: 0
[    0.001489] CPU: Processor Core ID: 6
[    0.001495] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.001495] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.001495] tlb_flushall_shift: 5
[    0.022164] cpu 0 spinlock event irq 17
[    0.022202] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
[    0.022211] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
[    0.022219] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
[    0.022227] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
[    0.022236] calling  init_hw_perf_events+0x0/0x414 @ 1
[    0.022242] Performance Events: 
[    0.022247] perf: AMD core performance counters detected
[    0.022254] no APIC, boot with the "lapic" boot parameter to force-enable it.
[    0.022261] no hardware sampling interrupt available.
[    0.022277] Broken PMU hardware detected, using software events only.
[    0.022284] Failed to access perfctr msr (MSR c0010201 is 0)
[    0.022292] initcall init_hw_perf_events+0x0/0x414 returned 0 after 0 usecs
[    0.022299] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
[    0.022307] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
[    0.022316] calling  spawn_ksoftirqd+0x0/0x28 @ 1
[    0.022360] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
[    0.022368] calling  init_workqueues+0x0/0x33a @ 1
[    0.022543] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
[    0.022552] calling  migration_init+0x0/0x71 @ 1
[    0.022560] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
[    0.022568] calling  cpu_stop_init+0x0/0xb4 @ 1
[    0.022606] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
[    0.022615] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
[    0.022622] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
[    0.022630] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
[    0.022684] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
[    0.022692] calling  relay_init+0x0/0x14 @ 1
[    0.022698] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[    0.022705] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
[    0.022746] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
[    0.022753] calling  init_events+0x0/0x61 @ 1
[    0.022761] initcall init_events+0x0/0x61 returned 0 after 0 usecs
[    0.022768] calling  init_trace_printk+0x0/0x12 @ 1
[    0.022775] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[    0.022782] calling  jump_label_init_module+0x0/0x12 @ 1
[    0.022789] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
[    0.022797] calling  mce_amd_init+0x0/0x110 @ 1
[    0.022803] MCE: In-kernel MCE decoding enabled.
[    0.022811] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
[    0.022903] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.023115] installing Xen timer for CPU 1
[    0.023134] cpu 1 spinlock event irq 24
[    0.023185] SMP alternatives: switching to SMP code
[    0.042382] installing Xen timer for CPU 2
[    0.042402] cpu 2 spinlock event irq 31
[    0.042544] Brought up 3 CPUs
[    0.044906] calling  ipc_ns_init+0x0/0x14 @ 1
[    0.044915] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
[    0.044923] calling  init_mmap_min_addr+0x0/0x26 @ 1
[    0.044930] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[    0.044938] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[    0.044948] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
[    0.044957] calling  net_ns_init+0x0/0xfd @ 1
[    0.044990] initcall net_ns_init+0x0/0xfd returned 0 after 0 usecs
[    0.045019] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
[    0.045027] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
[    0.045036] calling  cpufreq_tsc+0x0/0x37 @ 1
[    0.045044] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
[    0.046007] calling  reboot_init+0x0/0x1d @ 1
[    0.046017] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
[    0.046025] calling  init_lapic_sysfs+0x0/0x20 @ 1
[    0.046032] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
[    0.046040] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
[    0.046049] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
[    0.046057] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.046065] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.046073] calling  ksysfs_init+0x0/0x94 @ 1
[    0.046094] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[    0.046103] calling  pm_init+0x0/0x4e @ 1
[    0.046117] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
[    0.046125] calling  pm_disk_init+0x0/0x19 @ 1
[    0.046136] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[    0.046146] calling  swsusp_header_init+0x0/0x30 @ 1
[    0.046154] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
[    0.046162] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[    0.046172] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
[    0.046181] calling  event_trace_enable+0x0/0xa9 @ 1
[    0.046213] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
[    0.046222] calling  init_zero_pfn+0x0/0x35 @ 1
[    0.046229] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
[    0.046237] calling  fsnotify_init+0x0/0x26 @ 1
[    0.046246] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
[    0.046254] calling  filelock_init+0x0/0x2a @ 1
[    0.046281] initcall filelock_init+0x0/0x2a returned 0 after 0 usecs
[    0.046290] calling  init_misc_binfmt+0x0/0x31 @ 1
[    0.046298] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
[    0.046306] calling  init_script_binfmt+0x0/0x16 @ 1
[    0.046314] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046322] calling  init_elf_binfmt+0x0/0x16 @ 1
[    0.046330] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046338] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
[    0.046346] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046354] calling  debugfs_init+0x0/0x5c @ 1
[    0.046364] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[    0.046371] calling  securityfs_init+0x0/0x53 @ 1
[    0.046381] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
[    0.046389] calling  prandom_init+0x0/0xd9 @ 1
[    0.046397] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
[    0.046406] calling  virtio_init+0x0/0x30 @ 1
[    0.046429] kworker/u:0 (26) used greatest stack depth: 6136 bytes left
[    0.046429] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  __gnttab_init+0x0/0x30 @ 1
[    0.046429] Grant tables using version 2 layout.
[    0.046429] Grant table initialized
[    0.046429] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  early_resume_init+0x0/0x1d0 @ 1
[    0.065694] RTC time: 165:165:165, date: 165/165/65
[    0.065702] initcall early_resume_init+0x0/0x1d0 returned 0 after 18554 usecs
[    0.065711] calling  cpufreq_core_init+0x0/0xc7 @ 1
[    0.065719] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
[    0.065727] calling  cpuidle_init+0x0/0x40 @ 1
[    0.065734] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
[    0.065742] calling  bsp_pm_check_init+0x0/0x14 @ 1
[    0.065749] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
[    0.065756] calling  sock_init+0x0/0x89 @ 1
[    0.065842] initcall sock_init+0x0/0x89 returned 0 after 0 usecs
[    0.065850] calling  net_inuse_init+0x0/0x26 @ 1
[    0.065859] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[    0.065867] calling  netpoll_init+0x0/0x31 @ 1
[    0.065874] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[    0.065881] calling  netlink_proto_init+0x0/0x1b3 @ 1
[    0.065897] NET: Registered protocol family 16
[    0.065917] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
[    0.065938] calling  bdi_class_init+0x0/0x4d @ 1
[    0.066049] initcall bdi_class_init+0x0/0x4d returned 0 after 976 usecs
[    0.066060] calling  kobject_uevent_init+0x0/0x12 @ 1
[    0.066071] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
[    0.066079] calling  pcibus_class_init+0x0/0x19 @ 1
[    0.066096] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  pci_driver_init+0x0/0x19 @ 1
[    0.066096] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  backlight_class_init+0x0/0x5d @ 1
[    0.067045] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
[    0.067045] calling  video_output_class_init+0x0/0x19 @ 1
[    0.067063] kworker/u:0 (31) used greatest stack depth: 5592 bytes left
[    0.067063] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.067063] calling  xenbus_init+0x0/0x21a @ 1
[    0.067093] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
[    0.067093] calling  tty_class_init+0x0/0x38 @ 1
[    0.067093] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
[    0.067093] calling  vtconsole_class_init+0x0/0xc2 @ 1
[    0.067093] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
[    0.067093] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
[    0.067093] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
[    0.067093] calling  register_node_type+0x0/0x34 @ 1
[    0.067093] initcall register_node_type+0x0/0x34 returned 0 after 0 usecs
[    0.067093] calling  i2c_init+0x0/0x77 @ 1
[    0.068032] initcall i2c_init+0x0/0x77 returned 0 after 976 usecs
[    0.068043] calling  amd_postcore_init+0x0/0x143 @ 1
[    0.068130] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
[    0.068160] calling  set_real_mode_permissions+0x0/0xa9 @ 1
[    0.068216] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 0 usecs
[    0.068227] calling  arch_kdebugfs_init+0x0/0x233 @ 1
[    0.068268] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
[    0.068278] calling  mtrr_if_init+0x0/0x78 @ 1
[    0.068286] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
[    0.068294] calling  ffh_cstate_init+0x0/0x2a @ 1
[    0.068303] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
[    0.068311] initcall ffh_cstate_init+0x0/0x2a returned with error code -1 
[    0.068319] calling  activate_jump_labels+0x0/0x32 @ 1
[    0.068327] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
[    0.068335] calling  acpi_pci_init+0x0/0x5c @ 1
[    0.068343] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
[    0.068352] calling  dma_bus_init+0x0/0x19 @ 1
[    0.068371] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
[    0.068371] calling  dma_channel_table_init+0x0/0x119 @ 1
[    0.068371] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
[    0.068371] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[    0.070221] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 1953 usecs
[    0.070233] calling  register_xen_pci_notifier+0x0/0x38 @ 1
[    0.070241] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
[    0.070249] calling  xen_pcpu_init+0x0/0xcc @ 1
[    0.070256] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
[    0.070264] calling  dmi_id_init+0x0/0x31d @ 1
[    0.070272] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
[    0.070280] calling  dca_init+0x0/0x20 @ 1
[    0.070286] dca service started, version 1.12.1
[    0.070358] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
[    0.070366] calling  pci_arch_init+0x0/0x69 @ 1
[    0.071009] PCI: setting up Xen PCI frontend stub
[    0.071016] PCI: pci_cache_line_size set to 64 bytes
[    0.071024] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
[    0.071045] calling  topology_init+0x0/0x98 @ 1
[    0.071262] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
[    0.071271] calling  mtrr_init_finialize+0x0/0x36 @ 1
[    0.071278] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
[    0.071286] calling  init_vdso+0x0/0x135 @ 1
[    0.071296] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
[    0.071304] calling  sysenter_setup+0x0/0x2dd @ 1
[    0.071314] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
[    0.071322] calling  param_sysfs_init+0x0/0x192 @ 1
[    0.083778] initcall param_sysfs_init+0x0/0x192 returned 0 after 11718 usecs
[    0.083790] calling  pm_sysrq_init+0x0/0x19 @ 1
[    0.083800] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[    0.083808] calling  default_bdi_init+0x0/0x37 @ 1
[    0.083946] initcall default_bdi_init+0x0/0x37 returned 0 after 0 usecs
[    0.084039] calling  init_bio+0x0/0xe8 @ 1
[    0.084059] bio: create slab <bio-0> at 0
[    0.084078] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
[    0.084087] calling  fsnotify_notification_init+0x0/0x8b @ 1
[    0.084105] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
[    0.084114] calling  cryptomgr_init+0x0/0x12 @ 1
[    0.084122] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[    0.084130] calling  blk_settings_init+0x0/0x2c @ 1
[    0.084138] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
[    0.084146] calling  blk_ioc_init+0x0/0x2a @ 1
[    0.084157] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[    0.084165] calling  blk_softirq_init+0x0/0x6e @ 1
[    0.084174] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[    0.084181] calling  blk_iopoll_setup+0x0/0x6e @ 1
[    0.084189] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[    0.084197] calling  genhd_device_init+0x0/0x85 @ 1
[    0.084326] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
[    0.084337] calling  pci_slot_init+0x0/0x50 @ 1
[    0.084347] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
[    0.084355] calling  fbmem_init+0x0/0x98 @ 1
[    0.084428] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
[    0.084438] calling  acpi_init+0x0/0xbc @ 1
[    0.084444] ACPI: Interpreter disabled.
[    0.084451] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
[    0.084459] calling  dock_init+0x0/0x7b @ 1
[    0.084467] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
[    0.084475] calling  acpi_pci_root_init+0x0/0x32 @ 1
[    0.084483] initcall acpi_pci_root_init+0x0/0x32 returned 0 after 0 usecs
[    0.084491] calling  acpi_pci_link_init+0x0/0x43 @ 1
[    0.084499] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
[    0.084507] calling  pnp_init+0x0/0x19 @ 1
[    0.084576] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
[    0.084586] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
[    0.084600] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 0 usecs
[    0.084600] calling  balloon_init+0x0/0x133 @ 1
[    0.084600] xen/balloon: Initialising balloon driver.
[    0.084600] initcall balloon_init+0x0/0x133 returned 0 after 0 usecs
[    0.084600] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
[    0.085058] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 976 usecs
[    0.085058] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
[    0.085110] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 0 usecs
[    0.085110] calling  xen_acpi_pad_init+0x0/0x47 @ 1
[    0.085110] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
[    0.085110] calling  balloon_init+0x0/0xfa @ 1
[    0.085110] xen-balloon: Initialising balloon driver.
[    0.086035] initcall balloon_init+0x0/0xfa returned 0 after 976 usecs
[    0.086035] calling  xen_selfballoon_init+0x0/0xb9 @ 1
[    0.086043] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
[    0.086051] calling  misc_init+0x0/0xba @ 1
[    0.086151] initcall misc_init+0x0/0xba returned 0 after 0 usecs
[    0.086159] calling  vga_arb_device_init+0x0/0xde @ 1
[    0.086269] vgaarb: loaded
[    0.086276] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
[    0.086285] calling  cn_init+0x0/0xc0 @ 1
[    0.086302] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
[    0.086310] calling  phy_init+0x0/0x2e @ 1
[    0.086493] initcall phy_init+0x0/0x2e returned 0 after 0 usecs
[    0.086501] calling  init_pcmcia_cs+0x0/0x3d @ 1
[    0.086564] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
[    0.086572] calling  usb_init+0x0/0x170 @ 1
[    0.086726] usbcore: registered new interface driver usbfs
[    0.086798] usbcore: registered new interface driver hub
[    0.086890] usbcore: registered new device driver usb
[    0.086898] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
[    0.086906] calling  serio_init+0x0/0x38 @ 1
[    0.086974] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
[    0.086982] calling  input_init+0x0/0x103 @ 1
[    0.087087] initcall input_init+0x0/0x103 returned 0 after 0 usecs
[    0.087095] calling  rtc_init+0x0/0x71 @ 1
[    0.087158] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
[    0.087166] calling  pps_init+0x0/0xb7 @ 1
[    0.087227] pps_core: LinuxPPS API ver. 1 registered
[    0.088018] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.088030] initcall pps_init+0x0/0xb7 returned 0 after 976 usecs
[    0.088038] calling  ptp_init+0x0/0xa4 @ 1
[    0.088113] PTP clock support registered
[    0.088122] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
[    0.088130] calling  power_supply_class_init+0x0/0x44 @ 1
[    0.088195] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
[    0.088204] calling  hwmon_init+0x0/0xf6 @ 1
[    0.088268] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
[    0.088277] calling  leds_init+0x0/0x48 @ 1
[    0.088340] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
[    0.088349] calling  iommu_init+0x0/0x58 @ 1
[    0.088359] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
[    0.088367] calling  pci_subsys_init+0x0/0x4f @ 1
[    0.088374] PCI: System does not support PCI
[    0.088381] PCI: System does not support PCI
[    0.088388] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
[    0.088396] calling  proto_init+0x0/0x12 @ 1
[    0.088407] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[    0.088415] calling  net_dev_init+0x0/0x1c7 @ 1
[    0.088739] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
[    0.088748] calling  neigh_init+0x0/0x80 @ 1
[    0.088757] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
[    0.088765] calling  fib_rules_init+0x0/0xaf @ 1
[    0.088773] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
[    0.088781] calling  pktsched_init+0x0/0xfe @ 1
[    0.088792] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
[    0.088800] calling  tc_filter_init+0x0/0x55 @ 1
[    0.088807] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
[    0.088816] calling  tc_action_init+0x0/0x55 @ 1
[    0.088823] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
[    0.088831] calling  genl_init+0x0/0x75 @ 1
[    0.088845] initcall genl_init+0x0/0x75 returned 0 after 0 usecs
[    0.088853] calling  cipso_v4_init+0x0/0x61 @ 1
[    0.088862] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[    0.088870] calling  netlbl_init+0x0/0x81 @ 1
[    0.088876] NetLabel: Initializing
[    0.088882] NetLabel:  domain hash size = 128
[    0.088888] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.088910] NetLabel:  unlabeled traffic allowed by default
[    0.088919] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[    0.088926] calling  rfkill_init+0x0/0x79 @ 1
[    0.089030] initcall rfkill_init+0x0/0x79 returned 0 after 976 usecs
[    0.089054] calling  xen_p2m_debugfs+0x0/0x4a @ 1
[    0.089087] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
[    0.089095] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
[    0.089219] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
[    0.089228] calling  hpet_late_init+0x0/0x101 @ 1
[    0.089235] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
[    0.089243] calling  init_amd_nbs+0x0/0xb8 @ 1
[    0.089251] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
[    0.089260] calling  clocksource_done_booting+0x0/0x5a @ 1
[    0.089267] Switching to clocksource xen
[    0.089294] initcall clocksource_done_booting+0x0/0x5a returned 0 after 11 usecs
[    0.089303] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
[    0.089711] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 391 usecs
[    0.089720] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[    0.089734] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 6 usecs
[    0.089743] calling  event_trace_init+0x0/0x271 @ 1
[    0.099475] initcall event_trace_init+0x0/0x271 returned 0 after 9769 usecs
[    0.099485] calling  init_kprobe_trace+0x0/0x93 @ 1
[    0.099505] initcall init_kprobe_trace+0x0/0x93 returned 0 after 12 usecs
[    0.099513] calling  init_pipe_fs+0x0/0x4c @ 1
[    0.099543] initcall init_pipe_fs+0x0/0x4c returned 0 after 22 usecs
[    0.099552] calling  eventpoll_init+0x0/0xda @ 1
[    0.099566] initcall eventpoll_init+0x0/0xda returned 0 after 6 usecs
[    0.099574] calling  anon_inode_init+0x0/0x5b @ 1
[    0.099604] initcall anon_inode_init+0x0/0x5b returned 0 after 21 usecs
[    0.099612] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[    0.099620] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
[    0.287868] calling  acpi_event_init+0x0/0x81 @ 1
[    0.287878] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
[    0.287887] calling  pnp_system_init+0x0/0x12 @ 1
[    0.288027] initcall pnp_system_init+0x0/0x12 returned 0 after 127 usecs
[    0.288036] calling  pnpacpi_init+0x0/0x8c @ 1
[    0.288044] pnp: PnP ACPI: disabled
[    0.288052] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
[    0.288100] calling  pcistub_init+0x0/0x29f @ 1
[    0.288197] initcall pcistub_init+0x0/0x29f returned 0 after 86 usecs
[    0.288207] calling  chr_dev_init+0x0/0xc6 @ 1
[    0.293859] initcall chr_dev_init+0x0/0xc6 returned 0 after 5511 usecs
[    0.293869] calling  firmware_class_init+0x0/0xda @ 1
[    0.293941] initcall firmware_class_init+0x0/0xda returned 0 after 60 usecs
[    0.293951] calling  init_pcmcia_bus+0x0/0x6c @ 1
[    0.294023] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 62 usecs
[    0.294032] calling  thermal_init+0x0/0x75 @ 1
[    0.294193] initcall thermal_init+0x0/0x75 returned 0 after 149 usecs
[    0.294203] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
[    0.294212] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
[    0.294221] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[    0.294229] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
[    0.294239] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
[    0.294247] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
[    0.294256] calling  pcibios_assign_resources+0x0/0xf8 @ 1
[    0.294267] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
[    0.294276] calling  sysctl_core_init+0x0/0x2c @ 1
[    0.294295] initcall sysctl_core_init+0x0/0x2c returned 0 after 11 usecs
[    0.294303] calling  inet_init+0x0/0x2a1 @ 1
[    0.294332] NET: Registered protocol family 2
[    0.294575] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294649] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294697] TCP: Hash tables configured (established 16384 bind 16384)
[    0.294733] TCP: reno registered
[    0.294747] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294767] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294857] initcall inet_init+0x0/0x2a1 returned 0 after 533 usecs
[    0.294866] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.294875] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs
[    0.294883] calling  af_unix_init+0x0/0x55 @ 1
[    0.294891] NET: Registered protocol family 1
[    0.294907] initcall af_unix_init+0x0/0x55 returned 0 after 16 usecs
[    0.294916] calling  ipv6_offload_init+0x0/0x6e @ 1
[    0.294925] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
[    0.294933] calling  init_sunrpc+0x0/0x69 @ 1
[    0.295092] RPC: Registered named UNIX socket transport module.
[    0.295101] RPC: Registered udp transport module.
[    0.295108] RPC: Registered tcp transport module.
[    0.295114] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.295123] initcall init_sunrpc+0x0/0x69 returned 0 after 177 usecs
[    0.295131] calling  pci_apply_final_quirks+0x0/0x117 @ 1
[    0.295139] PCI: CLS 0 bytes, default 64
[    0.295146] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 6 usecs
[    0.295155] calling  populate_rootfs+0x0/0x10d @ 1
[    0.295384] Unpacking initramfs...
[    0.854446] Freeing initrd memory: 339316k freed
[    0.941088] initcall populate_rootfs+0x0/0x10d returned 0 after 630779 usecs
[    0.941109] calling  pci_iommu_init+0x0/0x41 @ 1
[    0.941118] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
[    0.941126] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
[    0.941135] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
[    0.941164] calling  irqfd_module_init+0x0/0x33 @ 1
[    0.941260] initcall irqfd_module_init+0x0/0x33 returned 0 after 85 usecs
[    0.941270] calling  i8259A_init_ops+0x0/0x21 @ 1
[    0.941278] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
[    0.941286] calling  vsyscall_init+0x0/0x27 @ 1
[    0.941303] initcall vsyscall_init+0x0/0x27 returned 0 after 6 usecs
[    0.941312] calling  sbf_init+0x0/0xf6 @ 1
[    0.941320] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
[    0.941330] calling  init_tsc_clocksource+0x0/0x89 @ 1
[    0.941343] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
[    0.941353] calling  add_rtc_cmos+0x0/0x96 @ 1
[    0.941554] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.941575] initcall add_rtc_cmos+0x0/0x96 returned 0 after 204 usecs
[    0.941587] calling  i8237A_init_ops+0x0/0x14 @ 1
[    0.941597] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.941610] calling  cache_sysfs_init+0x0/0x6c @ 1
[    0.941692] initcall cache_sysfs_init+0x0/0x6c returned 0 after 70 usecs
[    0.941703] calling  intel_uncore_init+0x0/0x3fa @ 1
[    0.941712] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
[    0.941721] calling  inject_init+0x0/0x30 @ 1
[    0.941728] Machine check injector initialized
[    0.941737] initcall inject_init+0x0/0x30 returned 0 after 7 usecs
[    0.941745] calling  thermal_throttle_init_device+0x0/0x9d @ 1
[    0.941754] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
[    0.941763] calling  amd_ibs_init+0x0/0x48d @ 1
[    0.941772] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
[    0.941781] calling  msr_init+0x0/0x162 @ 1
[    0.941942] initcall msr_init+0x0/0x162 returned 0 after 149 usecs
[    0.941952] calling  cpuid_init+0x0/0x162 @ 1
[    0.942124] initcall cpuid_init+0x0/0x162 returned 0 after 159 usecs
[    0.942133] calling  ioapic_init_ops+0x0/0x14 @ 1
[    0.942141] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942149] calling  add_pcspkr+0x0/0x40 @ 1
[    0.942229] initcall add_pcspkr+0x0/0x40 returned 0 after 70 usecs
[    0.942238] calling  microcode_init+0x0/0x1b1 @ 1
[    0.942318] microcode: CPU0: patch_level=0x06000626
[    0.942401] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.942412] initcall microcode_init+0x0/0x1b1 returned 0 after 162 usecs
[    0.942422] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
[    0.942430] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
[    0.942439] calling  audit_classes_init+0x0/0xaf @ 1
[    0.942452] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
[    0.942460] calling  pt_dump_init+0x0/0x30 @ 1
[    0.942485] initcall pt_dump_init+0x0/0x30 returned 0 after 16 usecs
[    0.942494] calling  ia32_binfmt_init+0x0/0x14 @ 1
[    0.942507] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 5 usecs
[    0.942515] calling  proc_execdomains_init+0x0/0x22 @ 1
[    0.942529] initcall proc_execdomains_init+0x0/0x22 returned 0 after 5 usecs
[    0.942538] calling  ioresources_init+0x0/0x3c @ 1
[    0.942552] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
[    0.942561] calling  uid_cache_init+0x0/0xa5 @ 1
[    0.942574] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
[    0.942582] calling  init_posix_timers+0x0/0x1f4 @ 1
[    0.942598] initcall init_posix_timers+0x0/0x1f4 returned 0 after 7 usecs
[    0.942606] calling  init_posix_cpu_timers+0x0/0xbf @ 1
[    0.942614] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
[    0.942623] calling  proc_schedstat_init+0x0/0x22 @ 1
[    0.942634] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
[    0.942642] calling  snapshot_device_init+0x0/0x12 @ 1
[    0.942724] initcall snapshot_device_init+0x0/0x12 returned 0 after 72 usecs
[    0.942733] calling  create_proc_profile+0x0/0x2c0 @ 1
[    0.942741] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
[    0.942749] calling  timekeeping_init_ops+0x0/0x14 @ 1
[    0.942757] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942765] calling  init_clocksource_sysfs+0x0/0x52 @ 1
[    0.942913] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 136 usecs
[    0.942923] calling  init_timer_list_procfs+0x0/0x2c @ 1
[    0.942934] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 3 usecs
[    0.942943] calling  alarmtimer_init+0x0/0x15d @ 1
[    0.943122] initcall alarmtimer_init+0x0/0x15d returned 0 after 166 usecs
[    0.943131] calling  init_tstats_procfs+0x0/0x2c @ 1
[    0.943143] initcall init_tstats_procfs+0x0/0x2c returned 0 after 4 usecs
[    0.943150] calling  futex_init+0x0/0x65 @ 1
[    0.943163] initcall futex_init+0x0/0x65 returned 0 after 5 usecs
[    0.943170] calling  proc_dma_init+0x0/0x22 @ 1
[    0.943181] initcall proc_dma_init+0x0/0x22 returned 0 after 3 usecs
[    0.943188] calling  proc_modules_init+0x0/0x22 @ 1
[    0.943199] initcall proc_modules_init+0x0/0x22 returned 0 after 3 usecs
[    0.943207] calling  kallsyms_init+0x0/0x25 @ 1
[    0.943217] initcall kallsyms_init+0x0/0x25 returned 0 after 2 usecs
[    0.943224] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
[    1.054869] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 14 usecs
[    1.054879] calling  crash_notes_memory_init+0x0/0x36 @ 1
[    1.054891] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 3 usecs
[    1.054900] calling  pid_namespaces_init+0x0/0x2d @ 1
[    1.054910] initcall pid_namespaces_init+0x0/0x2d returned 0 after 2 usecs
[    1.054918] calling  ikconfig_init+0x0/0x3a @ 1
[    1.054929] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
[    1.054936] calling  audit_init+0x0/0x141 @ 1
[    1.054943] audit: initializing netlink socket (disabled)
[    1.054961] type=2000 audit(1361569587.289:1): initialized
[    1.054971] initcall audit_init+0x0/0x141 returned 0 after 26 usecs
[    1.054979] calling  audit_watch_init+0x0/0x3a @ 1
[    1.054986] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
[    1.054994] calling  audit_tree_init+0x0/0x49 @ 1
[    1.055003] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[    1.055010] calling  init_kprobes+0x0/0x16c @ 1
[    1.065934] initcall init_kprobes+0x0/0x16c returned 0 after 10660 usecs
[    1.065947] calling  hung_task_init+0x0/0x56 @ 1
[    1.065990] initcall hung_task_init+0x0/0x56 returned 0 after 33 usecs
[    1.065998] calling  irq_pm_init_ops+0x0/0x14 @ 1
[    1.066009] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.066017] calling  utsname_sysctl_init+0x0/0x14 @ 1
[    1.066031] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.066039] calling  init_tracepoints+0x0/0x20 @ 1
[    1.066047] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
[    1.066083] calling  init_blk_tracer+0x0/0x5a @ 1
[    1.066092] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
[    1.066100] calling  perf_event_sysfs_init+0x0/0x9a @ 1
[    1.066383] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 268 usecs
[    1.066394] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
[    1.066511] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 105 usecs
[    1.066521] calling  kswapd_init+0x0/0x76 @ 1
[    1.066562] initcall kswapd_init+0x0/0x76 returned 0 after 32 usecs
[    1.066571] calling  extfrag_debug_init+0x0/0x7e @ 1
[    1.066600] initcall extfrag_debug_init+0x0/0x7e returned 0 after 20 usecs
[    1.066609] calling  setup_vmstat+0x0/0xc8 @ 1
[    1.066630] initcall setup_vmstat+0x0/0xc8 returned 0 after 13 usecs
[    1.066639] calling  mm_sysfs_init+0x0/0x29 @ 1
[    1.066649] initcall mm_sysfs_init+0x0/0x29 returned 0 after 2 usecs
[    1.066657] calling  slab_proc_init+0x0/0x25 @ 1
[    1.066668] initcall slab_proc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066676] calling  proc_vmalloc_init+0x0/0x25 @ 1
[    1.066687] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066695] calling  procswaps_init+0x0/0x22 @ 1
[    1.066706] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
[    1.066714] calling  init_frontswap+0x0/0x96 @ 1
[    1.066761] initcall init_frontswap+0x0/0x96 returned 0 after 37 usecs
[    1.066771] calling  hugetlb_init+0x0/0x415 @ 1
[    1.066781] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.066813] initcall hugetlb_init+0x0/0x415 returned 0 after 31 usecs
[    1.066822] calling  mmu_notifier_init+0x0/0x12 @ 1
[    1.066833] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
[    1.066843] calling  slab_proc_init+0x0/0x8 @ 1
[    1.066852] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
[    1.066861] calling  cpucache_init+0x0/0x52 @ 1
[    1.066871] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
[    1.066881] calling  hugepage_init+0x0/0x191 @ 1
[    1.066890] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
[    1.066900] initcall hugepage_init+0x0/0x191 returned with error code -22 
[    1.066910] calling  init_cleancache+0x0/0x96 @ 1
[    1.066956] initcall init_cleancache+0x0/0x96 returned 0 after 35 usecs
[    1.066964] calling  fcntl_init+0x0/0x2a @ 1
[    1.066974] initcall fcntl_init+0x0/0x2a returned 0 after 2 usecs
[    1.066983] calling  proc_filesystems_init+0x0/0x22 @ 1
[    1.066997] initcall proc_filesystems_init+0x0/0x22 returned 0 after 6 usecs
[    1.067005] calling  dio_init+0x0/0x2d @ 1
[    1.067017] initcall dio_init+0x0/0x2d returned 0 after 4 usecs
[    1.067025] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    1.067086] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 51 usecs
[    1.067094] calling  dnotify_init+0x0/0x7b @ 1
[    1.067112] initcall dnotify_init+0x0/0x7b returned 0 after 9 usecs
[    1.067120] calling  inotify_user_setup+0x0/0x70 @ 1
[    1.067135] initcall inotify_user_setup+0x0/0x70 returned 0 after 6 usecs
[    1.067143] calling  aio_setup+0x0/0x7c @ 1
[    1.067160] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
[    1.067168] calling  proc_locks_init+0x0/0x22 @ 1
[    1.067179] initcall proc_locks_init+0x0/0x22 returned 0 after 3 usecs
[    1.067187] calling  init_sys32_ioctl+0x0/0x28 @ 1
[    1.255161] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 71 usecs
[    1.255177] calling  dquot_init+0x0/0x121 @ 1
[    1.255185] VFS: Disk quotas dquot_6.5.2
[    1.255226] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.255238] initcall dquot_init+0x0/0x121 returned 0 after 50 usecs
[    1.255249] calling  init_v2_quota_format+0x0/0x22 @ 1
[    1.255259] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
[    1.255267] calling  quota_init+0x0/0x26 @ 1
[    1.255286] initcall quota_init+0x0/0x26 returned 0 after 8 usecs
[    1.255296] calling  proc_cmdline_init+0x0/0x22 @ 1
[    1.255312] initcall proc_cmdline_init+0x0/0x22 returned 0 after 5 usecs
[    1.255323] calling  proc_consoles_init+0x0/0x22 @ 1
[    1.255338] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
[    1.255349] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[    1.255362] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 3 usecs
[    1.255371] calling  proc_devices_init+0x0/0x22 @ 1
[    1.255383] initcall proc_devices_init+0x0/0x22 returned 0 after 4 usecs
[    1.255393] calling  proc_interrupts_init+0x0/0x22 @ 1
[    1.255407] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
[    1.255418] calling  proc_loadavg_init+0x0/0x22 @ 1
[    1.255432] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
[    1.255442] calling  proc_meminfo_init+0x0/0x22 @ 1
[    1.255457] initcall proc_meminfo_init+0x0/0x22 returned 0 after 4 usecs
[    1.255467] calling  proc_stat_init+0x0/0x22 @ 1
[    1.255481] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
[    1.255491] calling  proc_uptime_init+0x0/0x22 @ 1
[    1.255505] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
[    1.255516] calling  proc_version_init+0x0/0x22 @ 1
[    1.255530] initcall proc_version_init+0x0/0x22 returned 0 after 4 usecs
[    1.255540] calling  proc_softirqs_init+0x0/0x22 @ 1
[    1.255554] initcall proc_softirqs_init+0x0/0x22 returned 0 after 4 usecs
[    1.255565] calling  proc_kcore_init+0x0/0xb5 @ 1
[    1.255581] initcall proc_kcore_init+0x0/0xb5 returned 0 after 7 usecs
[    1.255592] calling  vmcore_init+0x0/0x370 @ 1
[    1.255602] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
[    1.255612] calling  proc_kmsg_init+0x0/0x25 @ 1
[    1.255627] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
[    1.255637] calling  proc_page_init+0x0/0x42 @ 1
[    1.255655] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
[    1.255665] calling  init_devpts_fs+0x0/0x62 @ 1
[    1.255717] initcall init_devpts_fs+0x0/0x62 returned 0 after 40 usecs
[    1.255728] calling  init_ramfs_fs+0x0/0x12 @ 1
[    1.255738] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255747] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
[    1.255811] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 53 usecs
[    1.255819] calling  init_fat_fs+0x0/0x4f @ 1
[    1.255837] initcall init_fat_fs+0x0/0x4f returned 0 after 9 usecs
[    1.255845] calling  init_vfat_fs+0x0/0x12 @ 1
[    1.255854] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255862] calling  init_msdos_fs+0x0/0x12 @ 1
[    1.255870] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255878] calling  init_iso9660_fs+0x0/0x70 @ 1
[    1.255905] initcall init_iso9660_fs+0x0/0x70 returned 0 after 18 usecs
[    1.255913] calling  init_nfs_fs+0x0/0x16c @ 1
[    1.256045] initcall init_nfs_fs+0x0/0x16c returned 0 after 120 usecs
[    1.256077] calling  init_nfs_v2+0x0/0x14 @ 1
[    1.256086] initcall init_nfs_v2+0x0/0x14 returned 0 after 1 usecs
[    1.256093] calling  init_nfs_v3+0x0/0x14 @ 1
[    1.256101] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
[    1.256108] calling  init_nfs_v4+0x0/0x3b @ 1
[    1.256115] NFS: Registering the id_resolver key type
[    1.256134] Key type id_resolver registered
[    1.256140] Key type id_legacy registered
[    1.256151] initcall init_nfs_v4+0x0/0x3b returned 0 after 34 usecs
[    1.256159] calling  init_nlm+0x0/0x4c @ 1
[    1.256171] initcall init_nlm+0x0/0x4c returned 0 after 5 usecs
[    1.256179] calling  init_nls_cp437+0x0/0x12 @ 1
[    1.256187] initcall init_nls_cp437+0x0/0x12 returned 0 after 0 usecs
[    1.256194] calling  init_nls_ascii+0x0/0x12 @ 1
[    1.256202] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[    1.256209] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[    1.256217] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[    1.256225] calling  init_nls_utf8+0x0/0x2b @ 1
[    1.256233] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
[    1.256240] calling  init_ntfs_fs+0x0/0x1d1 @ 1
[    1.256246] NTFS driver 2.1.30 [Flags: R/W].
[    1.455160] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 194248 usecs
[    1.455177] calling  init_autofs4_fs+0x0/0x2a @ 1
[    1.455306] initcall init_autofs4_fs+0x0/0x2a returned 0 after 117 usecs
[    1.455315] calling  init_pstore_fs+0x0/0x12 @ 1
[    1.455324] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
[    1.455331] calling  ipc_init+0x0/0x2f @ 1
[    1.455345] msgmni has been set to 2923
[    1.455359] initcall ipc_init+0x0/0x2f returned 0 after 19 usecs
[    1.455367] calling  ipc_sysctl_init+0x0/0x14 @ 1
[    1.455381] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.455389] calling  init_mqueue_fs+0x0/0xa2 @ 1
[    1.455434] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 36 usecs
[    1.455442] calling  key_proc_init+0x0/0x5e @ 1
[    1.455456] initcall key_proc_init+0x0/0x5e returned 0 after 6 usecs
[    1.455464] calling  selinux_nf_ip_init+0x0/0x69 @ 1
[    1.455471] SELinux:  Registering netfilter hooks
[    1.455652] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 175 usecs
[    1.455661] calling  init_sel_fs+0x0/0xa5 @ 1
[    1.455945] initcall init_sel_fs+0x0/0xa5 returned 0 after 269 usecs
[    1.455954] calling  selnl_init+0x0/0x56 @ 1
[    1.455967] initcall selnl_init+0x0/0x56 returned 0 after 5 usecs
[    1.455975] calling  sel_netif_init+0x0/0x5c @ 1
[    1.455984] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
[    1.455992] calling  sel_netnode_init+0x0/0x6a @ 1
[    1.456001] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
[    1.456008] calling  sel_netport_init+0x0/0x6a @ 1
[    1.456017] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
[    1.456025] calling  aurule_init+0x0/0x2d @ 1
[    1.456033] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
[    1.456040] calling  crypto_wq_init+0x0/0x33 @ 1
[    1.456101] initcall crypto_wq_init+0x0/0x33 returned 0 after 51 usecs
[    1.456110] calling  crypto_algapi_init+0x0/0xd @ 1
[    1.456121] initcall crypto_algapi_init+0x0/0xd returned 0 after 3 usecs
[    1.456129] calling  skcipher_module_init+0x0/0x35 @ 1
[    1.456137] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
[    1.456145] calling  chainiv_module_init+0x0/0x12 @ 1
[    1.456153] initcall chainiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456161] calling  eseqiv_module_init+0x0/0x12 @ 1
[    1.456169] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456176] calling  hmac_module_init+0x0/0x12 @ 1
[    1.456184] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456192] calling  md5_mod_init+0x0/0x12 @ 1
[    1.456254] initcall md5_mod_init+0x0/0x12 returned 0 after 53 usecs
[    1.456263] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[    1.456315] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456324] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[    1.456332] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456340] calling  des_generic_mod_init+0x0/0x17 @ 1
[    1.456434] initcall des_generic_mod_init+0x0/0x17 returned 0 after 84 usecs
[    1.456442] calling  aes_init+0x0/0x12 @ 1
[    1.456493] initcall aes_init+0x0/0x12 returned 0 after 42 usecs
[    1.456501] calling  zlib_mod_init+0x0/0x12 @ 1
[    1.456551] initcall zlib_mod_init+0x0/0x12 returned 0 after 41 usecs
[    1.456559] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[    1.456567] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456575] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
[    1.456584] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456592] calling  lzo_mod_init+0x0/0x12 @ 1
[    1.456643] initcall lzo_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456651] calling  krng_mod_init+0x0/0x12 @ 1
[    1.456702] initcall krng_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456710] calling  proc_genhd_init+0x0/0x3c @ 1
[    1.456724] initcall proc_genhd_init+0x0/0x3c returned 0 after 6 usecs
[    1.456732] calling  bsg_init+0x0/0x12e @ 1
[    1.456803] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.456812] initcall bsg_init+0x0/0x12e returned 0 after 71 usecs
[    1.456820] calling  noop_init+0x0/0x12 @ 1
[    1.456827] io scheduler noop registered
[    1.456834] initcall noop_init+0x0/0x12 returned 0 after 7 usecs
[    1.456842] calling  deadline_init+0x0/0x12 @ 1
[    1.456849] io scheduler deadline registered
[    1.456856] initcall deadline_init+0x0/0x12 returned 0 after 6 usecs
[    1.456864] calling  cfq_init+0x0/0x8b @ 1
[    1.456878] io scheduler cfq registered (default)
[    1.456885] initcall cfq_init+0x0/0x8b returned 0 after 14 usecs
[    1.456893] calling  percpu_counter_startup+0x0/0x38 @ 1
[    1.456902] initcall percpu_counter_startup+0x0/0x38 returned 0 after 1 usecs
[    1.456910] calling  pci_proc_init+0x0/0x6a @ 1
[    1.654703] initcall pci_proc_init+0x0/0x6a returned 0 after 8 usecs
[    1.654716] calling  pcie_portdrv_init+0x0/0x7a @ 1
[    1.654876] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 148 usecs
[    1.654885] calling  aer_service_init+0x0/0x2b @ 1
[    1.654958] initcall aer_service_init+0x0/0x2b returned 0 after 63 usecs
[    1.654967] calling  pci_hotplug_init+0x0/0x1d @ 1
[    1.654974] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.654982] initcall pci_hotplug_init+0x0/0x1d returned 0 after 6 usecs
[    1.654990] calling  pcifront_init+0x0/0x3f @ 1
[    1.655085] initcall pcifront_init+0x0/0x3f returned 0 after 85 usecs
[    1.655094] calling  genericbl_driver_init+0x0/0x12 @ 1
[    1.655169] initcall genericbl_driver_init+0x0/0x12 returned 0 after 65 usecs
[    1.655178] calling  cirrusfb_init+0x0/0xcc @ 1
[    1.655265] initcall cirrusfb_init+0x0/0xcc returned 0 after 75 usecs
[    1.655277] calling  efifb_init+0x0/0x298 @ 1
[    1.655287] initcall efifb_init+0x0/0x298 returned -19 after 1 usecs
[    1.655297] calling  intel_idle_init+0x0/0x326 @ 1
[    1.655305] initcall intel_idle_init+0x0/0x326 returned -19 after 0 usecs
[    1.655313] calling  acpi_reserve_resources+0x0/0xeb @ 1
[    1.655322] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 usecs
[    1.655330] calling  irqrouter_init_ops+0x0/0x26 @ 1
[    1.655338] initcall irqrouter_init_ops+0x0/0x26 returned 0 after 0 usecs
[    1.655347] calling  acpi_ac_init+0x0/0x28 @ 1
[    1.655357] initcall acpi_ac_init+0x0/0x28 returned -19 after 0 usecs
[    1.655369] calling  acpi_button_driver_init+0x0/0x12 @ 1
[    1.655379] initcall acpi_button_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655390] calling  acpi_fan_driver_init+0x0/0x12 @ 1
[    1.655399] initcall acpi_fan_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655409] calling  acpi_processor_init+0x0/0x6d @ 1
[    1.655419] initcall acpi_processor_init+0x0/0x6d returned 0 after 0 usecs
[    1.655429] calling  acpi_container_init+0x0/0x4a @ 1
[    1.655439] initcall acpi_container_init+0x0/0x4a returned -19 after 0 usecs
[    1.655450] calling  acpi_thermal_init+0x0/0x42 @ 1
[    1.655458] initcall acpi_thermal_init+0x0/0x42 returned -19 after 0 usecs
[    1.655466] calling  acpi_battery_init+0x0/0x16 @ 1
[    1.655478] initcall acpi_battery_init+0x0/0x16 returned 0 after 3 usecs
[    1.655486] calling  acpi_hed_driver_init+0x0/0x12 @ 1
[    1.655494] initcall acpi_hed_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655502] calling  erst_init+0x0/0x2bb @ 1
[    1.655510] initcall erst_init+0x0/0x2bb returned 0 after 0 usecs
[    1.655518] calling  ghes_init+0x0/0x171 @ 1
[    1.655527] initcall ghes_init+0x0/0x171 returned -19 after 0 usecs
[    1.655535] calling  einj_init+0x0/0x49d @ 1
[    1.655543] initcall einj_init+0x0/0x49d returned -19 after 0 usecs
[    1.655551] calling  ioat_init_module+0x0/0x80 @ 1
[    1.655559] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    1.655595] calling  1_acpi_battery_init_async+0x0/0x1b @ 6
[    1.655603] initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 0 usecs
[    1.655672] initcall ioat_init_module+0x0/0x80 returned 0 after 109 usecs
[    1.655683] calling  virtio_mmio_init+0x0/0x12 @ 1
[    1.655766] initcall virtio_mmio_init+0x0/0x12 returned 0 after 72 usecs
[    1.655777] calling  init+0x0/0x12 @ 1
[    1.655855] initcall init+0x0/0x12 returned 0 after 67 usecs
[    1.655864] calling  xenbus_probe_initcall+0x0/0x39 @ 1
[    1.655873] initcall xenbus_probe_initcall+0x0/0x39 returned 0 after 0 usecs
[    1.655882] calling  xenbus_init+0x0/0x3d @ 1
[    1.655975] initcall xenbus_init+0x0/0x3d returned 0 after 81 usecs
[    1.655985] calling  xenbus_backend_init+0x0/0x51 @ 1
[    1.655993] initcall xenbus_backend_init+0x0/0x51 returned -19 after 0 usecs
[    1.656002] calling  gntdev_init+0x0/0x4d @ 1
[    1.656125] initcall gntdev_init+0x0/0x4d returned 0 after 111 usecs
[    1.656134] calling  gntalloc_init+0x0/0x3d @ 1
[    1.656209] initcall gntalloc_init+0x0/0x3d returned 0 after 66 usecs
[    1.656217] calling  hypervisor_subsys_init+0x0/0x25 @ 1
[    1.656225] initcall hypervisor_subsys_init+0x0/0x25 returned 0 after 0 usecs
[    1.656233] calling  hyper_sysfs_init+0x0/0xfb @ 1
[    1.656254] initcall hyper_sysfs_init+0x0/0xfb returned 0 after 13 usecs
[    1.656262] calling  platform_pci_module_init+0x0/0x1b @ 1
[    1.656336] initcall platform_pci_module_init+0x0/0x1b returned 0 after 64 usecs
[    1.656344] calling  xen_tmem_init+0x0/0x9a @ 1
[    1.656352] initcall xen_tmem_init+0x0/0x9a returned 0 after 0 usecs
[    1.656360] calling  xen_late_init_mcelog+0x0/0x3d @ 1
[    1.656367] initcall xen_late_init_mcelog+0x0/0x3d returned -19 after 0 usecs
[    1.656375] calling  xen_pcibk_init+0x0/0x13f @ 1
[    1.656383] initcall xen_pcibk_init+0x0/0x13f returned -19 after 0 usecs
[    1.854937] calling  xen_acpi_processor_init+0x0/0x41f @ 1
[    1.854949] initcall xen_acpi_processor_init+0x0/0x41f returned -19 after 0 usecs
[    1.854957] calling  pty_init+0x0/0x453 @ 1
[    1.890528] initcall pty_init+0x0/0x453 returned 0 after 34728 usecs
[    1.890543] calling  sysrq_init+0x0/0x78 @ 1
[    1.890557] initcall sysrq_init+0x0/0x78 returned 0 after 5 usecs
[    1.890564] calling  xen_hvc_init+0x0/0x249 @ 1
[    1.891318] initcall xen_hvc_init+0x0/0x249 returned 0 after 728 usecs
[    1.891328] calling  serial8250_init+0x0/0x17d @ 1
[    1.891335] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.891949] initcall serial8250_init+0x0/0x17d returned 0 after 598 usecs
[    1.891959] calling  serial_pci_driver_init+0x0/0x1b @ 1
[    1.892030] initcall serial_pci_driver_init+0x0/0x1b returned 0 after 62 usecs
[    1.892040] calling  init_kgdboc+0x0/0x16 @ 1
[    1.892048] initcall init_kgdboc+0x0/0x16 returned 0 after 0 usecs
[    1.892103] calling  rand_initialize+0x0/0x30 @ 1
[    1.892125] initcall rand_initialize+0x0/0x30 returned 0 after 10 usecs
[    1.892135] calling  init+0x0/0x111 @ 1
[    1.892349] initcall init+0x0/0x111 returned 0 after 201 usecs
[    1.892358] calling  hpet_init+0x0/0x6a @ 1
[    1.892517] initcall hpet_init+0x0/0x6a returned -19 after 147 usecs
[    1.892526] calling  nvram_init+0x0/0x82 @ 1
[    1.892602] Non-volatile memory driver v1.3
[    1.892610] initcall nvram_init+0x0/0x82 returned 0 after 74 usecs
[    1.892618] calling  mod_init+0x0/0x5a @ 1
[    1.892625] initcall mod_init+0x0/0x5a returned -19 after 0 usecs
[    1.892633] calling  rng_init+0x0/0x12 @ 1
[    1.892709] initcall rng_init+0x0/0x12 returned 0 after 66 usecs
[    1.892718] calling  agp_init+0x0/0x26 @ 1
[    1.892725] Linux agpgart interface v0.103
[    1.892732] initcall agp_init+0x0/0x26 returned 0 after 6 usecs
[    1.892739] calling  agp_amd64_mod_init+0x0/0x22 @ 1
[    1.892876] initcall agp_amd64_mod_init+0x0/0x22 returned -19 after 125 usecs
[    1.892885] calling  agp_intel_init+0x0/0x29 @ 1
[    1.892955] initcall agp_intel_init+0x0/0x29 returned 0 after 60 usecs
[    1.892964] calling  agp_sis_init+0x0/0x29 @ 1
[    1.893035] initcall agp_sis_init+0x0/0x29 returned 0 after 61 usecs
[    1.893043] calling  agp_via_init+0x0/0x29 @ 1
[    1.893136] initcall agp_via_init+0x0/0x29 returned 0 after 83 usecs
[    1.893144] calling  drm_core_init+0x0/0x139 @ 1
[    1.893223] [drm] Initialized drm 1.1.0 20060810
[    1.893231] initcall drm_core_init+0x0/0x139 returned 0 after 77 usecs
[    1.893239] calling  cn_proc_init+0x0/0x3d @ 1
[    1.893247] initcall cn_proc_init+0x0/0x3d returned 0 after 1 usecs
[    1.893256] calling  topology_sysfs_init+0x0/0x58 @ 1
[    1.893274] initcall topology_sysfs_init+0x0/0x58 returned 0 after 9 usecs
[    1.893282] calling  loop_init+0x0/0x137 @ 1
[    1.895048] loop: module loaded
[    1.895089] initcall loop_init+0x0/0x137 returned 0 after 1757 usecs
p[    1.895098] calling  xen_blkif_init+0x0/0x25f @ 1
[    1.895308] initcall xen_blkif_init+0x0/0x25f returned 0 after 197 usecs
[    1.895316] calling  mac_hid_init+0x0/0x22 @ 1
[    1.895328] initcall mac_hid_init+0x0/0x22 returned 0 after 4 usecs
[    1.895336] calling  macvlan_init_module+0x0/0x3d @ 1
[    1.895345] initcall macvlan_init_module+0x0/0x3d returned 0 after 1 usecs
[    1.895353] calling  macvtap_init+0x0/0x100 @ 1
[    1.895419] initcall macvtap_init+0x0/0x100 returned 0 after 56 usecs
[    1.895427] calling  net_olddevs_init+0x0/0x86 @ 1
[    1.895436] initcall net_olddevs_init+0x0/0x86 returned 0 after 1 usecs
[    1.895444] calling  fixed_mdio_bus_init+0x0/0x105 @ 1
[    1.895589] libphy: Fixed MDIO Bus: probed
[    1.895597] initcall fixed_mdio_bus_init+0x0/0x105 returned 0 after 141 usecs
[    1.895605] calling  tun_init+0x0/0x93 @ 1
[    1.895612] tun: Universal TUN/TAP device driver, 1.6
[    1.895618] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.895698] initcall tun_init+0x0/0x93 returned 0 after 83 usecs
[    1.895706] calling  tg3_init+0x0/0x1b @ 1
[    1.895780] initcall tg3_init+0x0/0x1b returned 0 after 65 usecs
[    1.895788] calling  ixgbevf_init_module+0x0/0x4c @ 1
[    2.055322] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k
[    2.055332] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    2.055427] initcall ixgbevf_init_module+0x0/0x4c returned 0 after 101 usecs
[    2.055436] calling  init_nic+0x0/0x1b @ 1
[    2.055512] initcall init_nic+0x0/0x1b returned 0 after 66 usecs
[    2.055521] calling  netback_init+0x0/0x212 @ 1
[    2.055638] initcall netback_init+0x0/0x212 returned 0 after 106 usecs
[    2.055647] calling  nonstatic_sysfs_init+0x0/0x12 @ 1
[    2.055656] initcall nonstatic_sysfs_init+0x0/0x12 returned 0 after 1 usecs
[    2.055664] calling  yenta_socket_init+0x0/0x1b @ 1
[    2.055744] initcall yenta_socket_init+0x0/0x1b returned 0 after 70 usecs
[    2.055754] calling  mon_init+0x0/0xfe @ 1
[    2.055909] initcall mon_init+0x0/0xfe returned 0 after 144 usecs
[    2.055918] calling  ehci_hcd_init+0x0/0xb7 @ 1
[    2.055925] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.055933] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    2.055951] initcall ehci_hcd_init+0x0/0xb7 returned 0 after 24 usecs
[    2.055959] calling  ehci_pci_init+0x0/0x69 @ 1
[    2.055966] ehci-pci: EHCI PCI platform driver
[    2.056038] initcall ehci_pci_init+0x0/0x69 returned 0 after 68 usecs
[    2.056047] calling  ohci_hcd_mod_init+0x0/0xbf @ 1
[    2.056086] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.056094] ohci_hcd: block sizes: ed 80 td 96
[    2.056181] initcall ohci_hcd_mod_init+0x0/0xbf returned 0 after 92 usecs
[    2.056190] calling  uhci_hcd_init+0x0/0x129 @ 1
[    2.056197] uhci_hcd: USB Universal Host Controller Interface driver
[    2.056290] initcall uhci_hcd_init+0x0/0x129 returned 0 after 89 usecs
[    2.056299] calling  usblp_driver_init+0x0/0x1b @ 1
[    2.056375] usbcore: registered new interface driver usblp
[    2.056384] initcall usblp_driver_init+0x0/0x1b returned 0 after 75 usecs
[    2.056393] calling  kgdbdbgp_start_thread+0x0/0x4f @ 1
[    2.056401] initcall kgdbdbgp_start_thread+0x0/0x4f returned 0 after 0 usecs
[    2.056409] calling  i8042_init+0x0/0x3c5 @ 1
[    2.056657] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.068374] i8042: No controller found
[    3.068394] initcall i8042_init+0x0/0x3c5 returned -19 after 988256 usecs
[    3.068403] calling  serport_init+0x0/0x34 @ 1
[    3.068412] initcall serport_init+0x0/0x34 returned 0 after 1 usecs
[    3.068420] calling  mousedev_init+0x0/0x62 @ 1
[    3.068590] mousedev: PS/2 mouse device common for all mice
[    3.068600] initcall mousedev_init+0x0/0x62 returned 0 after 167 usecs
[    3.068608] calling  evdev_init+0x0/0x12 @ 1
[    3.068617] initcall evdev_init+0x0/0x12 returned 0 after 0 usecs
[    3.068625] calling  atkbd_init+0x0/0x27 @ 1
[    3.068713] initcall atkbd_init+0x0/0x27 returned 0 after 78 usecs
[    3.068724] calling  psmouse_init+0x0/0x7b @ 1
[    3.068871] initcall psmouse_init+0x0/0x7b returned 0 after 132 usecs
[    3.068888] calling  cmos_init+0x0/0x6a @ 1
[    3.129156] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    3.129267] rtc_cmos: probe of rtc_cmos failed with error -38
[    3.129462] initcall cmos_init+0x0/0x6a returned -19 after 59144 usecs
[    3.129471] calling  i2c_i801_init+0x0/0xad @ 1
[    3.129552] initcall i2c_i801_init+0x0/0xad returned 0 after 70 usecs
ow[    3.129562] calling  cpufreq_gov_dbs_init+0x0/0x95 @ 1
[    3.129571] initcall cpufreq_gov_dbs_init+0x0/0x95 returned -19 after 1 usecs
[    3.129580] calling  init_ladder+0x0/0x12 @ 1
[    3.129588] initcall init_ladder+0x0/0x12 returned -19 after 0 usecs
[    3.129596] calling  init_menu+0x0/0x12 @ 1
[    3.129603] initcall init_menu+0x0/0x12 returned -19 after 0 usecs
[    3.129612] calling  efivars_init+0x0/0x105 @ 1
[    3.129619] EFI Variables Facility v0.08 2004-May-17
[    3.129626] initcall efivars_init+0x0/0x105 returned 0 after 6 usecs
[    3.129635] calling  vhost_net_init+0x0/0x30 @ 1
[    3.129714] initcall vhost_net_init+0x0/0x30 returned 0 after 68 usecs
[    3.129723] calling  staging_init+0x0/0x8 @ 1
[    3.129731] initcall staging_init+0x0/0x8 returned 0 after 0 usecs
[    3.129739] calling  zram_init+0x0/0x2e4 @ 1
[    3.129746] zram: num_devices not specified. Using default: 1
[    3.129753] zram: Creating 1 devices ...
[    3.130028] initcall zram_init+0x0/0x2e4 returned 0 after 273 usecs
[    3.130038] calling  zcache_init+0x0/0x297 @ 1
[    3.130115] initcall zcache_init+0x0/0x297 returned 0 after 67 usecs
[    3.130127] calling  zs_init+0x0/0x90 @ 1
[    3.130139] initcall zs_init+0x0/0x90 returned 0 after 3 usecs
[    3.130149] calling  eeepc_laptop_init+0x0/0x58 @ 1
[    3.130320] initcall eeepc_laptop_init+0x0/0x58 returned -19 after 157 usecs
[    3.130331] calling  sock_diag_init+0x0/0x12 @ 1
[    3.130347] initcall sock_diag_init+0x0/0x12 returned 0 after 8 usecs
[    3.130355] calling  flow_cache_init_global+0x0/0x19f @ 1
[    3.130373] initcall flow_cache_init_global+0x0/0x19f returned 0 after 10 usecs
[    3.130382] calling  llc_init+0x0/0x20 @ 1
[    3.130390] initcall llc_init+0x0/0x20 returned 0 after 1 usecs
[    3.130397] calling  snap_init+0x0/0x38 @ 1
[    3.130408] initcall snap_init+0x0/0x38 returned 0 after 1 usecs
[    3.130417] calling  blackhole_module_init+0x0/0x12 @ 1
[    3.130427] initcall blackhole_module_init+0x0/0x12 returned 0 after 0 usecs
[    3.130436] calling  nfnetlink_init+0x0/0x27 @ 1
[    3.130444] Netfilter messages via NETLINK v0.30.
[    3.130464] initcall nfnetlink_init+0x0/0x27 returned 0 after 18 usecs
[    3.130474] calling  nfnetlink_log_init+0x0/0xdb @ 1
[    3.130491] initcall nfnetlink_log_init+0x0/0xdb returned 0 after 9 usecs
[    3.130499] calling  nf_conntrack_standalone_init+0x0/0x12 @ 1
[    3.130507] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    3.130600] initcall nf_conntrack_standalone_init+0x0/0x12 returned 0 after 90 usecs
[    3.130609] calling  ctnetlink_init+0x0/0xa4 @ 1
[    3.130616] ctnetlink v0.93: registering with nfnetlink.
[    3.130623] initcall ctnetlink_init+0x0/0xa4 returned 0 after 6 usecs
[    3.130631] calling  nf_conntrack_ftp_init+0x0/0x1ca @ 1
[    3.130639] initcall nf_conntrack_ftp_init+0x0/0x1ca returned 0 after 0 usecs
[    3.130647] calling  nf_conntrack_irc_init+0x0/0x173 @ 1
[    3.130658] initcall nf_conntrack_irc_init+0x0/0x173 returned 0 after 3 usecs
[    3.130666] calling  nf_conntrack_sip_init+0x0/0x215 @ 1
[    3.130675] initcall nf_conntrack_sip_init+0x0/0x215 returned 0 after 0 usecs
[    3.130683] calling  xt_init+0x0/0x118 @ 1
[    3.130693] initcall xt_init+0x0/0x118 returned 0 after 1 usecs
[    3.130701] calling  tcpudp_mt_init+0x0/0x17 @ 1
[    3.130709] initcall tcpudp_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.130717] calling  connsecmark_tg_init+0x0/0x12 @ 1
[    3.268638] initcall connsecmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268647] calling  nflog_tg_init+0x0/0x12 @ 1
[    3.268656] initcall nflog_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268664] calling  secmark_tg_init+0x0/0x12 @ 1
[    3.268671] initcall secmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268679] calling  tcpmss_tg_init+0x0/0x17 @ 1
[    3.268687] initcall tcpmss_tg_init+0x0/0x17 returned 0 after 0 usecs
[    3.268696] calling  conntrack_mt_init+0x0/0x17 @ 1
[    3.268707] initcall conntrack_mt_init+0x0/0x17 returned 0 after 0 usecs
er[    3.268715] calling  policy_mt_init+0x0/0x17 @ 1
[    3.268723] initcall policy_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.268730] calling  state_mt_init+0x0/0x12 @ 1
[    3.268738] initcall state_mt_init+0x0/0x12 returned 0 after 0 usecs
[    3.268746] calling  sysctl_ipv4_init+0x0/0x92 @ 1
[    3.268793] initcall sysctl_ipv4_init+0x0/0x92 returned 0 after 37 usecs
[    3.268804] calling  init_syncookies+0x0/0x19 @ 1
[    3.268835] initcall init_syncookies+0x0/0x19 returned 0 after 21 usecs
[    3.268845] calling  tunnel4_init+0x0/0x72 @ 1
[    3.268854] initcall tunnel4_init+0x0/0x72 returned 0 after 0 usecs
[    3.268865] calling  ipv4_netfilter_init+0x0/0x12 @ 1
[    3.268876] initcall ipv4_netfilter_init+0x0/0x12 returned 0 after 0 usecs
[    3.268886] calling  nf_conntrack_l3proto_ipv4_init+0x0/0xb8 @ 1
[    3.269010] initcall nf_conntrack_l3proto_ipv4_init+0x0/0xb8 returned 0 after 110 usecs
[    3.269021] calling  nf_defrag_init+0x0/0x17 @ 1
[    3.269029] initcall nf_defrag_init+0x0/0x17 returned 0 after 0 usecs
[    3.269037] calling  ip_tables_init+0x0/0xaa @ 1
[    3.269064] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.269072] initcall ip_tables_init+0x0/0xaa returned 0 after 26 usecs
[    3.269083] calling  iptable_filter_init+0x0/0x51 @ 1
[    3.269107] initcall iptable_filter_init+0x0/0x51 returned 0 after 13 usecs
[    3.269118] calling  iptable_mangle_init+0x0/0x51 @ 1
[    3.269139] initcall iptable_mangle_init+0x0/0x51 returned 0 after 10 usecs
[    3.269150] calling  reject_tg_init+0x0/0x12 @ 1
[    3.269159] initcall reject_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.269169] calling  ulog_tg_init+0x0/0x104 @ 1
[    3.269184] initcall ulog_tg_init+0x0/0x104 returned 0 after 5 usecs
[    3.269195] calling  cubictcp_register+0x0/0x5c @ 1
[    3.269204] TCP: cubic registered
[    3.269213] initcall cubictcp_register+0x0/0x5c returned 0 after 9 usecs
[    3.269221] calling  xfrm_user_init+0x0/0x4a @ 1
[    3.269230] Initializing XFRM netlink socket
[    3.269244] initcall xfrm_user_init+0x0/0x4a returned 0 after 12 usecs
[    3.269255] calling  inet6_init+0x0/0x315 @ 1
[    3.269288] NET: Registered protocol family 10
[    3.269523] initcall inet6_init+0x0/0x315 returned 0 after 252 usecs
[    3.269532] calling  ah6_init+0x0/0x79 @ 1
[    3.269539] initcall ah6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269547] calling  esp6_init+0x0/0x79 @ 1
[    3.269555] initcall esp6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269563] calling  xfrm6_transport_init+0x0/0x17 @ 1
[    3.269571] initcall xfrm6_transport_init+0x0/0x17 returned 0 after 0 usecs
[    3.269579] calling  xfrm6_mode_tunnel_init+0x0/0x17 @ 1
[    3.269587] initcall xfrm6_mode_tunnel_init+0x0/0x17 returned 0 after 0 usecs
[    3.269595] calling  xfrm6_beet_init+0x0/0x17 @ 1
[    3.269602] initcall xfrm6_beet_init+0x0/0x17 returned 0 after 0 usecs
[    3.269610] calling  ip6_tables_init+0x0/0xaa @ 1
[    3.269627] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    3.269635] initcall ip6_tables_init+0x0/0xaa returned 0 after 16 usecs
[    3.269643] calling  ip6table_filter_init+0x0/0x51 @ 1
[    3.269764] initcall ip6table_filter_init+0x0/0x51 returned 0 after 110 usecs
[    3.269773] calling  ip6table_mangle_init+0x0/0x51 @ 1
[    3.269822] initcall ip6table_mangle_init+0x0/0x51 returned 0 after 40 usecs
[    3.269831] calling  nf_conntrack_l3proto_ipv6_init+0x0/0x8a @ 1
[    3.269846] initcall nf_conntrack_l3proto_ipv6_init+0x0/0x8a returned 0 after 6 usecs
[    3.269855] calling  nf_defrag_init+0x0/0x54 @ 1
[    3.269868] initcall nf_defrag_init+0x0/0x54 returned 0 after 5 usecs
[    3.269876] calling  ipv6header_mt6_init+0x0/0x12 @ 1
[    3.269884] initcall ipv6header_mt6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269892] calling  reject_tg6_init+0x0/0x12 @ 1
[    3.269900] initcall reject_tg6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269908] calling  sit_init+0x0/0x8c @ 1
[    3.269914] sit: IPv6 over IPv4 tunneling driver
[    3.270252] initcall sit_init+0x0/0x8c returned 0 after 329 usecs
[    3.270261] calling  packet_init+0x0/0x47 @ 1
[    3.270268] NET: Registered protocol family 17
[    3.270280] initcall packet_init+0x0/0x47 returned 0 after 11 usecs
[    3.468657] calling  br_init+0x0/0xa2 @ 1
of[    3.468683] initcall br_init+0x0/0xa2 returned 0 after 16 usecs
[    3.468691] calling  init_rpcsec_gss+0x0/0x64 @ 1
[    3.468734] initcall init_rpcsec_gss+0x0/0x64 returned 0 after 32 usecs
[    3.468745] calling  dcbnl_init+0x0/0x4d @ 1
[    3.468756] initcall dcbnl_init+0x0/0x4d returned 0 after 0 usecs
[    3.468765] calling  init_dns_resolver+0x0/0xe4 @ 1
[    3.468790] Key type dns_resolver registered
[    3.468801] initcall init_dns_resolver+0x0/0xe4 returned 0 after 23 usecs
[    3.468812] calling  mcheck_init_device+0x0/0x123 @ 1
[    3.468822] initcall mcheck_init_device+0x0/0x123 returned -5 after 0 usecs
[    3.468833] initcall mcheck_init_device+0x0/0x123 returned with error code -5 
[    3.468865] calling  tboot_late_init+0x0/0x216 @ 1
[    3.468875] initcall tboot_late_init+0x0/0x216 returned 0 after 0 usecs
[    3.468885] calling  mcheck_debugfs_init+0x0/0x3c @ 1
[    3.468915] initcall mcheck_debugfs_init+0x0/0x3c returned 0 after 19 usecs
[    3.468923] calling  severities_debugfs_init+0x0/0x3c @ 1
[    3.468942] initcall severities_debugfs_init+0x0/0x3c returned 0 after 7 usecs
[    3.468954] calling  threshold_init_device+0x0/0x8d @ 1
[    3.468964] initcall threshold_init_device+0x0/0x8d returned 0 after 0 usecs
[    3.468975] calling  hpet_insert_resource+0x0/0x23 @ 1
[    3.468985] initcall hpet_insert_resource+0x0/0x23 returned 1 after 0 usecs
[    3.468995] initcall hpet_insert_resource+0x0/0x23 returned with error code 1 
[    3.469007] calling  update_mp_table+0x0/0x56d @ 1
[    3.469018] initcall update_mp_table+0x0/0x56d returned 0 after 0 usecs
[    3.469028] calling  lapic_insert_resource+0x0/0x3f @ 1
[    3.469037] initcall lapic_insert_resource+0x0/0x3f returned -1 after 0 usecs
[    3.469047] initcall lapic_insert_resource+0x0/0x3f returned with error code -1 
[    3.469072] calling  io_apic_bug_finalize+0x0/0x1b @ 1
[    3.469083] initcall io_apic_bug_finalize+0x0/0x1b returned 0 after 0 usecs
[    3.469092] calling  print_ICs+0x0/0x508 @ 1
[    3.469102] initcall print_ICs+0x0/0x508 returned 0 after 0 usecs
[    3.469112] calling  check_early_ioremap_leak+0x0/0x65 @ 1
[    3.469122] initcall check_early_ioremap_leak+0x0/0x65 returned 0 after 0 usecs
[    3.469133] calling  pat_memtype_list_init+0x0/0x32 @ 1
[    3.469156] initcall pat_memtype_list_init+0x0/0x32 returned 0 after 13 usecs
[    3.469169] calling  init_oops_id+0x0/0x40 @ 1
[    3.469189] initcall init_oops_id+0x0/0x40 returned 0 after 4 usecs
[    3.469199] calling  printk_late_init+0x0/0x59 @ 1
[    3.469211] initcall printk_late_init+0x0/0x59 returned 0 after 1 usecs
[    3.469220] calling  pm_qos_power_init+0x0/0x7b @ 1
[    3.469460] initcall pm_qos_power_init+0x0/0x7b returned 0 after 223 usecs
[    3.469469] calling  pm_debugfs_init+0x0/0x24 @ 1
[    3.469483] initcall pm_debugfs_init+0x0/0x24 returned 0 after 6 usecs
[    3.469492] calling  software_resume+0x0/0x290 @ 1
[    3.469499] PM: Hibernation image not present or could not be loaded.
[    3.469507] initcall software_resume+0x0/0x290 returned -2 after 7 usecs
[    3.469515] initcall software_resume+0x0/0x290 returned with error code -2 
[    3.469524] calling  debugfs_kprobe_init+0x0/0x90 @ 1
[    3.469551] initcall debugfs_kprobe_init+0x0/0x90 returned 0 after 19 usecs
[    3.469559] calling  taskstats_init+0x0/0x95 @ 1
[    3.469570] registered taskstats version 1
[    3.469577] initcall taskstats_init+0x0/0x95 returned 0 after 10 usecs
[    3.469585] calling  clear_boot_tracer+0x0/0x2d @ 1
[    3.469593] initcall clear_boot_tracer+0x0/0x2d returned 0 after 0 usecs
[    3.469601] calling  max_swapfiles_check+0x0/0x8 @ 1
[    3.469608] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs
[    3.469617] calling  set_recommended_min_free_kbytes+0x0/0xa0 @ 1
[    3.469625] initcall set_recommended_min_free_kbytes+0x0/0xa0 returned 0 after 0 usecs
[    3.469634] calling  fail_make_request_debugfs+0x0/0x2a @ 1
[    3.469692] initcall fail_make_request_debugfs+0x0/0x2a returned 0 after 49 usecs
[    3.469701] calling  prandom_reseed+0x0/0xb4 @ 1
[    3.469722] initcall prandom_reseed+0x0/0xb4 returned 0 after 13 usecs
[    3.469730] calling  pci_resource_alignment_sysfs_init+0x0/0x19 @ 1
[    3.469740] initcall pci_resource_alignment_sysfs_init+0x0/0x19 returned 0 after 1 usecs
[    3.469748] calling  pci_sysfs_init+0x0/0x51 @ 1
[    3.469757] initcall pci_sysfs_init+0x0/0x51 returned 0 after 1 usecs
[    3.469765] calling  boot_wait_for_devices+0x0/0x30 @ 1
[    3.669552] XENBUS: Device with no driver: device/vif/0
[    3.669562] initcall boot_wait_for_devices+0x0/0x30 returned 0 after 12 usecs
[    3.669575] calling  random_int_secret_init+0x0/0x19 @ 1
[    3.669594] initcall random_int_secret_init+0x0/0x19 returned 0 after 10 usecs
[    3.669604] calling  deferred_probe_initcall+0x0/0x60 @ 1
[    3.669664] initcall deferred_probe_initcall+0x0/0x60 returned 0 after 50 usecs
f[    3.669681] calling  late_resume_init+0x0/0x1d0 @ 1
[    3.669690]   Magic number: 1:252:3141
[    3.669768] initcall late_resume_init+0x0/0x1d0 returned 0 after 75 usecs
[    3.669778] calling  firmware_memmap_init+0x0/0x38 @ 1
[    3.669805] initcall firmware_memmap_init+0x0/0x38 returned 0 after 18 usecs
[    3.669815] calling  pci_mmcfg_late_insert_resources+0x0/0x50 @ 1
[    3.669824] initcall pci_mmcfg_late_insert_resources+0x0/0x50 returned 0 after 0 usecs
[    3.669835] calling  net_secret_init+0x0/0x19 @ 1
[    3.669857] initcall net_secret_init+0x0/0x19 returned 0 after 11 usecs
[    3.669866] calling  tcp_congestion_default+0x0/0x12 @ 1
[    3.669878] initcall tcp_congestion_default+0x0/0x12 returned 0 after 1 usecs
[    3.669889] calling  tcp_fastopen_init+0x0/0x30 @ 1
[    3.669910] initcall tcp_fastopen_init+0x0/0x30 returned 0 after 11 usecs
[    3.669921] calling  ip_auto_config+0x0/0xe62 @ 1
[    3.669937] initcall ip_auto_config+0x0/0xe62 returned 0 after 5 usecs
[    3.669947] calling  initialize_hashrnd+0x0/0x19 @ 1
[    3.669961] initcall initialize_hashrnd+0x0/0x19 returned 0 after 4 usecs
[    3.670862] Freeing unused kernel memory: 756k freed
[    3.671087] Write protecting the kernel read-only data: 10240k
[    3.677203] Freeing unused kernel memory: 1620k freed
[    3.677696] Freeing unused kernel memory: 136k freed
[    3.683393] consoletype (1029) used greatest stack depth: 5288 bytes left
[    3.991865] calling  privcmd_init+0x0/0x1000 [xen_privcmd] @ 1058
[    3.991978] initcall privcmd_init+0x0/0x1000 [xen_privcmd] returned 0 after 93 usecs
[    3.992361] calling  xenfs_init+0x0/0x1000 [xenfs] @ 1058
[    3.992373] initcall xenfs_init+0x0/0x1000 [xenfs] returned 0 after 1 usecs
[    3.992538] modprobe (1058) used greatest stack depth: 5272 bytes left
[    4.003403] core_filesystem (1030) used greatest stack depth: 4984 bytes left
[    4.012398] calling  xenkbd_init+0x0/0x1000 [xen_kbdfront] @ 1069
[    4.012500] initcall xenkbd_init+0x0/0x1000 [xen_kbdfront] returned 0 after 84 usecs
[    4.015993] calling  xenfb_init+0x0/0x1000 [xen_fbfront] @ 1072
[    4.016125] initcall xenfb_init+0x0/0x1000 [xen_fbfront] returned 0 after 113 usecs
[    4.019032] calling  netif_init+0x0/0x1000 [xen_netfront] @ 1079
[    4.019044] Initialising Xen virtual ethernet driver.
[    4.119124] initcall netif_init+0x0/0x1000 [xen_netfront] returned 0 after 97731 usecs
[    4.121939] calling  xlblk_init+0x0/0x1000 [xen_blkfront] @ 1085
[    4.122045] initcall xlblk_init+0x0/0x1000 [xen_blkfront] returned 0 after 87 usecs
[    4.136417] udevd (1091): /proc/1091/oom_adj is deprecated, please use /proc/1091/oom_score_adj instead.
[    4.190158] calling  crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] @ 1112
[    4.190457] initcall crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] returned 0 after 273 usecs
[    4.294865] ip (1240) used greatest stack depth: 3896 bytes left
[    4.617936] calling  drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] @ 1861
[    4.618103] initcall drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] returned 0 after 143 usecs
[    4.622178] calling  ttm_init+0x0/0x1000 [ttm] @ 1861
[    4.622835] initcall ttm_init+0x0/0x1000 [ttm] returned 0 after 623 usecs
[    4.638477] calling  radeon_init+0x0/0x1000 [radeon] @ 1861
[    4.638494] [drm] radeon kernel modesetting enabled.
[    4.639366] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 831 usecs
[    4.644900] calling  acpi_wmi_init+0x0/0x1000 [wmi] @ 1872
[    4.644911] initcall acpi_wmi_init+0x0/0x1000 [wmi] returned -19 after 0 usecs
[    4.645279] calling  fb_console_init+0x0/0x1000 [fbcon] @ 1863
[    4.648295] initcall fb_console_init+0x0/0x1000 [fbcon] returned 0 after 2934 usecs
[    4.648680] calling  acpi_video_init+0x0/0xfee [video] @ 1877
[    4.648692] initcall acpi_video_init+0x0/0xfee [video] returned -19 after 1 usecs
[    4.919737] device eth0 entered promiscuous mode
[    4.973883] switch: port 1(eth0) entered forwarding state
[    4.973901] switch: port 1(eth0) entered forwarding state
[    7.304760] calling  crc32c_mod_init+0x0/0x1000 [crc32c] @ 2192
[    7.304839] initcall crc32c_mod_init+0x0/0x1000 [crc32c] returned 0 after 60 usecs
[    7.307385] calling  libcrc32c_mod_init+0x0/0x1000 [libcrc32c] @ 2195
[    7.307403] initcall libcrc32c_mod_init+0x0/0x1000 [libcrc32c] returned 0 after 2 usecs
[    7.313643] calling  init_scsi+0x0/0x91 [scsi_mod] @ 2197
[    7.314342] SCSI subsystem initialized
[    7.314356] initcall init_scsi+0x0/0x91 [scsi_mod] returned 0 after 679 usecs
[    7.316111] calling  iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] @ 2197
[    7.316129] Loading iSCSI transport class v2.0-870.
[    7.317289] initcall iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] returned 0 after 1129 usecs
[    7.319114] calling  iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] @ 2197
[    7.319320] iscsi: registered transport (tcp)
[    7.319329] initcall iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] returned 0 after 198 usecs
[    7.371756] calling  evtchn_init+0x0/0x1000 [xen_evtchn] @ 2237
[    7.372190] Event-channel device installed.
[    7.372199] initcall evtchn_init+0x0/0x1000 [xen_evtchn] returned 0 after 420 usecs
[    7.471343] mount.nfs (2258) used greatest stack depth: 3480 bytes left
[    8.469522] calling  dm_init+0x0/0x48 [dm_mod] @ 2272
[    8.470002] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[    8.470021] initcall dm_init+0x0/0x48 [dm_mod] returned 0 after 467 usecs
[    8.471073] calling  dm_multipath_init+0x0/0x1000 [dm_multipath] @ 2272
[    8.471163] device-mapper: multipath: version 1.5.0 loaded
[    8.471175] initcall dm_multipath_init+0x0/0x1000 [dm_multipath] returned 0 after 83 usecs
[    8.734032] scsi0 : iSCSI Initiator over TCP/IP
[    8.991392] scsi 0:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[    8.995124] calling  init_sd+0x0/0x1000 [sd_mod] @ 2290
[    8.995995] initcall init_sd+0x0/0x1000 [sd_mod] returned 0 after 833 usecs
[    8.999267] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    8.999841] sd 0:0:0:0: [sda] Write Protect is off
[    8.999852] sd 0:0:0:0: [sda] Mode Sense: 2f 00 00 00
[    9.000230] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    9.003886]  sda: unknown partition table
[    9.005627] sd 0:0:0:0: [sda] Attached SCSI disk
[    9.008859] calling  init_sg+0x0/0x1000 [sg] @ 2303
[    9.009224] sd 0:0:0:0: Attached scsi generic sg0 type 0

[    9.009265] initcall init_sg+0x0/0x1000 [sg] returned 0 after 380 usecs
[   14.059832] bio: create slab <bio-1> at 1
[   20.000116] switch: port 1(eth0) entered forwarding state
# poweroff
Feb 22 21:47:09 g-pvops init: starting pid 2464, tty '': '/etc/init.d/halt'
# Usage: /etc/init.d/halt {start}
The system is going down NOW!
Sent SIGTERM to all processes
Feb 22 21:47:09 g-pvops exiting on signal 15
Sent SIGKILL to all processes
Requesting system poweroff
[   44.590513] sd 0:0:0:0: shutdown
[   44.590947] vif vif-0: shutdown
[   44.603898] PM: Calling i8259A_shutdown+0x0/0x10
[   44.603928] System halted.
Parsing config from test.xm
Daemon running with PID 6859

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 21:48:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 21: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 1U90Th-0002U3-9n; Fri, 22 Feb 2013 21:48:25 +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 1U90Tf-0002Ty-4z
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 21:48:24 +0000
Received: from [85.158.138.51:29028] by server-10.bemta-3.messagelabs.com id
	FB/BD-10609-6A7E7215; Fri, 22 Feb 2013 21:48:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361569699!19462799!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQyMDE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8208 invoked from network); 22 Feb 2013 21:48:20 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Feb 2013 21:48:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1MLmFkU016185
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 22 Feb 2013 21:48:16 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
	r1MLmEg6013663
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 22 Feb 2013 21:48:15 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
	r1MLmCtY009292; Fri, 22 Feb 2013 15:48:13 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 13:48:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 346841C3935; Fri, 22 Feb 2013 16:48:11 -0500 (EST)
Date: Fri, 22 Feb 2013 16:48:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: rafael.j.wysocki@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Message-ID: <20130222214811.GA25445@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Regression introduced by
 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device
 objects from probing ACPI drivers) in v3.9-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Rafael,

Per git bisect it looks like that patch: 
ACPI: Separate adding ACPI device objects from probing ACPI drivers
blows up when running under Xen PV guests:

(please notice that ACPI is turned off with normal Xen PV guests):
547 #ifdef CONFIG_ACPI
548         if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
549                 printk(KERN_INFO "ACPI in unprivileged domain disabled\n");
550                 disable_acpi();
551         }
552 #endif

(in arch/x86/xen/setup.c). Here is what the console tells me
(I can't get the early console somehow to work):

[    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.001000] pid_max: default: 32768 minimum: 301
[    0.001000] Security Framework initialized
[    0.001000] SELinux:  Initializing.
[    0.001000] SELinux:  Starting in permissive mode
[    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001224] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001488] Mount-cache hash table entries: 256
[    0.001774] Initializing cgroup subsys cpuacct
[    0.001782] Initializing cgroup subsys freezer
[    0.001860] tseg: 00adf00000
[    0.001868] CPU: Physical Processor ID: 0
[    0.001874] CPU: Processor Core ID: 1
[    0.001883] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.001883] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.001883] tlb_flushall_shift: 5
[    0.028911] cpu 0 spinlock event irq 17
[    0.028956] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
[    0.028966] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
[    0.028976] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
[    0.028986] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
[    0.028997] calling  init_hw_perf_events+0x0/0x414 @ 1
[    0.029000] Performance Events: 
[    0.029000] perf: AMD core performance counters detected
[    0.029000] no APIC, boot with the "lapic" boot parameter to force-enable it.
[    0.029000] no hardware sampling interrupt available.
[    0.029000] Broken PMU hardware detected, using software events only.
[    0.029005] Failed to access perfctr msr (MSR c0010201 is 0)
[    0.029014] initcall init_hw_perf_events+0x0/0x414 returned 0 after 976 usecs
[    0.029024] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
[    0.029034] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
[    0.029044] calling  spawn_ksoftirqd+0x0/0x28 @ 1
[    0.029093] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
[    0.029103] calling  init_workqueues+0x0/0x33a @ 1
[    0.029316] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
[    0.029327] calling  migration_init+0x0/0x71 @ 1
[    0.029337] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
[    0.029346] calling  cpu_stop_init+0x0/0xb4 @ 1
[    0.029392] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
[    0.029402] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
[    0.029413] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
[    0.029423] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
[    0.029493] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
[    0.029502] calling  relay_init+0x0/0x14 @ 1
[    0.029510] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[    0.029519] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
[    0.029565] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
[    0.029575] calling  init_events+0x0/0x61 @ 1
[    0.029584] initcall init_events+0x0/0x61 returned 0 after 0 usecs
[    0.029592] calling  init_trace_printk+0x0/0x12 @ 1
[    0.029601] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[    0.029610] calling  jump_label_init_module+0x0/0x12 @ 1
[    0.029618] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
[    0.029630] calling  mce_amd_init+0x0/0x110 @ 1
[    0.029638] MCE: In-kernel MCE decoding enabled.
[    0.029647] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
[    0.029760] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.030028] installing Xen timer for CPU 1
[    0.030051] cpu 1 spinlock event irq 24
[    0.030092] SMP alternatives: switching to SMP code
[    0.056501] installing Xen timer for CPU 2
[    0.056544] cpu 2 spinlock event irq 31
[    0.057032] Brought up 3 CPUs
[    0.058000] calling  ipc_ns_init+0x0/0x14 @ 1
[    0.058000] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
[    0.058000] calling  init_mmap_min_addr+0x0/0x26 @ 1
[    0.058000] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[    0.058000] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[    0.058000] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
[    0.058000] calling  net_ns_init+0x0/0xfd @ 1
[    0.061054] initcall net_ns_init+0x0/0xfd returned 0 after 976 usecs
[    0.061056] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
[    0.061069] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
[    0.061081] calling  cpufreq_tsc+0x0/0x37 @ 1
[    0.061092] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
[    0.061104] calling  reboot_init+0x0/0x1d @ 1
[    0.061116] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
[    0.061128] calling  init_lapic_sysfs+0x0/0x20 @ 1
[    0.061138] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
[    0.109030] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
[    0.109044] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
[    0.109056] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.110000] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.111008] calling  ksysfs_init+0x0/0x94 @ 1
[    0.111035] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[    0.111045] calling  pm_init+0x0/0x4e @ 1
[    0.111063] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
[    0.111072] calling  pm_disk_init+0x0/0x19 @ 1
[    0.111092] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[    0.111102] calling  swsusp_header_init+0x0/0x30 @ 1
[    0.111113] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
[    0.111122] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[    0.111137] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
[    0.111148] calling  event_trace_enable+0x0/0xa9 @ 1
[    0.111191] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
[    0.111202] calling  init_zero_pfn+0x0/0x35 @ 1
[    0.111211] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
[    0.111222] calling  fsnotify_init+0x0/0x26 @ 1
[    0.111235] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
[    0.111246] calling  filelock_init+0x0/0x2a @ 1
[    0.111317] initcall filelock_init+0x0/0x2a returned 0 after 976 usecs
[    0.111329] calling  init_misc_binfmt+0x0/0x31 @ 1
[    0.111341] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
[    0.111351] calling  init_script_binfmt+0x0/0x16 @ 1
[    0.111361] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.111371] calling  init_elf_binfmt+0x0/0x16 @ 1
[    0.111381] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.111391] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
[    0.111401] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.111412] calling  debugfs_init+0x0/0x5c @ 1
[    0.111425] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[    0.111435] calling  securityfs_init+0x0/0x53 @ 1
[    0.111448] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
[    0.111458] calling  prandom_init+0x0/0xd9 @ 1
[    0.111469] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
[    0.111480] calling  virtio_init+0x0/0x30 @ 1
[    0.112062] kworker/u:0 (26) used greatest stack depth: 5592 bytes left
[    0.112092] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
[    0.112092] calling  __gnttab_init+0x0/0x30 @ 1
[    0.112092] Grant tables using version 2 layout.
[    0.112109] Grant table initialized
[    0.112118] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
[    0.112130] calling  early_resume_init+0x0/0x1d0 @ 1
[    0.126868] RTC time: 165:165:165, date: 165/165/65
[    0.126887] initcall early_resume_init+0x0/0x1d0 returned 0 after 14648 usecs
[    0.126901] calling  cpufreq_core_init+0x0/0xc7 @ 1
[    0.126911] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
[    0.126921] calling  cpuidle_init+0x0/0x40 @ 1
[    0.126930] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
[    0.126941] calling  bsp_pm_check_init+0x0/0x14 @ 1
[    0.126951] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
[    0.126960] calling  sock_init+0x0/0x89 @ 1
[    0.128845] initcall sock_init+0x0/0x89 returned 0 after 1953 usecs
[    0.128856] calling  net_inuse_init+0x0/0x26 @ 1
[    0.128867] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[    0.128877] calling  netpoll_init+0x0/0x31 @ 1
[    0.128886] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[    0.128896] calling  netlink_proto_init+0x0/0x1b3 @ 1
[    0.128919] NET: Registered protocol family 16
[    0.128953] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
[    0.128985] calling  bdi_class_init+0x0/0x4d @ 1
[    0.129075] initcall bdi_class_init+0x0/0x4d returned 0 after 0 usecs
[    0.129075] calling  kobject_uevent_init+0x0/0x12 @ 1
[    0.129077] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
[    0.129087] calling  pcibus_class_init+0x0/0x19 @ 1
[    0.129114] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.129114] calling  pci_driver_init+0x0/0x19 @ 1
[    0.129114] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
[    0.129114] calling  backlight_class_init+0x0/0x5d @ 1
[    0.129114] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
[    0.129114] calling  video_output_class_init+0x0/0x19 @ 1
[    0.129114] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.217038] calling  xenbus_init+0x0/0x21a @ 1
[    0.217110] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
[    0.217110] calling  tty_class_init+0x0/0x38 @ 1
[    0.217110] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
[    0.217110] calling  vtconsole_class_init+0x0/0xc2 @ 1
[    0.217110] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
[    0.217110] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
[    0.217110] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
[    0.217110] calling  register_node_type+0x0/0x34 @ 1
[    0.218034] initcall register_node_type+0x0/0x34 returned 0 after 976 usecs
[    0.218045] calling  i2c_init+0x0/0x77 @ 1
[    0.218063] initcall i2c_init+0x0/0x77 returned 0 after 0 usecs
[    0.218063] calling  amd_postcore_init+0x0/0x143 @ 1
[    0.218673] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
[    0.218710] calling  set_real_mode_permissions+0x0/0xa9 @ 1
[    0.221082] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 2929 usecs
[    0.221097] calling  arch_kdebugfs_init+0x0/0x233 @ 1
[    0.221181] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
[    0.221193] calling  mtrr_if_init+0x0/0x78 @ 1
[    0.221202] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
[    0.221212] calling  ffh_cstate_init+0x0/0x2a @ 1
[    0.221222] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
[    0.221233] initcall ffh_cstate_init+0x0/0x2a returned with error code -1 
[    0.221243] calling  activate_jump_labels+0x0/0x32 @ 1
[    0.221253] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
[    0.221263] calling  acpi_pci_init+0x0/0x5c @ 1
[    0.221273] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
[    0.221283] calling  dma_bus_init+0x0/0x19 @ 1
[    0.221306] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
[    0.221306] calling  dma_channel_table_init+0x0/0x119 @ 1
[    0.221306] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
[    0.221306] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[    0.226301] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 4882 usecs
[    0.226320] calling  register_xen_pci_notifier+0x0/0x38 @ 1
[    0.226331] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
[    0.226342] calling  xen_pcpu_init+0x0/0xcc @ 1
[    0.226353] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
[    0.226364] calling  dmi_id_init+0x0/0x31d @ 1
[    0.226374] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
[    0.226385] calling  dca_init+0x0/0x20 @ 1
[    0.226394] dca service started, version 1.12.1
[    0.226499] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
[    0.226511] calling  pci_arch_init+0x0/0x69 @ 1
[    0.227009] PCI: setting up Xen PCI frontend stub
[    0.227020] PCI: pci_cache_line_size set to 64 bytes
[    0.227032] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
[    0.227066] calling  topology_init+0x0/0x98 @ 1
[    0.227348] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
[    0.227360] calling  mtrr_init_finialize+0x0/0x36 @ 1
[    0.227370] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
[    0.227380] calling  init_vdso+0x0/0x135 @ 1
[    0.227393] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
[    0.227403] calling  sysenter_setup+0x0/0x2dd @ 1
[    0.227417] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
[    0.227427] calling  param_sysfs_init+0x0/0x192 @ 1
[    0.243968] initcall param_sysfs_init+0x0/0x192 returned 0 after 15625 usecs
[    0.243988] calling  pm_sysrq_init+0x0/0x19 @ 1
[    0.243999] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[    0.244000] calling  default_bdi_init+0x0/0x37 @ 1
[    0.244189] initcall default_bdi_init+0x0/0x37 returned 0 after 976 usecs
[    0.244202] calling  init_bio+0x0/0xe8 @ 1
[    0.244226] bio: create slab <bio-0> at 0
[    0.244247] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
[    0.244258] calling  fsnotify_notification_init+0x0/0x8b @ 1
[    0.244281] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
[    0.244294] calling  cryptomgr_init+0x0/0x12 @ 1
[    0.244304] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[    0.244314] calling  blk_settings_init+0x0/0x2c @ 1
[    0.244323] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
[    0.244333] calling  blk_ioc_init+0x0/0x2a @ 1
[    0.244350] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[    0.244360] calling  blk_softirq_init+0x0/0x6e @ 1
[    0.244371] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[    0.244382] calling  blk_iopoll_setup+0x0/0x6e @ 1
[    0.244391] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[    0.244401] calling  genhd_device_init+0x0/0x85 @ 1
[    0.244544] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
[    0.244557] calling  pci_slot_init+0x0/0x50 @ 1
[    0.244571] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
[    0.244581] calling  fbmem_init+0x0/0x98 @ 1
[    0.244684] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
[    0.244697] calling  acpi_init+0x0/0xbc @ 1
[    0.244705] ACPI: Interpreter disabled.
[    0.244714] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
[    0.244724] calling  dock_init+0x0/0x7b @ 1
[    0.244733] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
[    0.244744] calling  acpi_pci_link_init+0x0/0x43 @ 1
[    0.244754] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
[    0.244764] calling  pnp_init+0x0/0x19 @ 1
[    0.244875] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
[    0.244887] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
[    0.246077] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 1953 usecs
[    0.246091] calling  balloon_init+0x0/0x133 @ 1
[    0.246099] xen/balloon: Initialising balloon driver.
[    0.247065] initcall balloon_init+0x0/0x133 returned 0 after 976 usecs
[    0.247078] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
[    0.255037] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 7812 usecs
[    0.255055] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
[    0.259050] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 3906 usecs
[    0.259065] calling  xen_acpi_pad_init+0x0/0x47 @ 1
[    0.259075] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
[    0.259084] calling  balloon_init+0x0/0xfa @ 1
[    0.259093] xen-balloon: Initialising balloon driver.
[    0.259328] initcall balloon_init+0x0/0xfa returned 0 after 0 usecs
[    0.259328] calling  xen_selfballoon_init+0x0/0xb9 @ 1
[    0.259328] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
[    0.259328] calling  misc_init+0x0/0xba @ 1
[    0.259328] initcall misc_init+0x0/0xba returned 0 after 0 usecs
[    0.259328] calling  vga_arb_device_init+0x0/0xde @ 1
[    0.259419] vgaarb: loaded
[    0.259430] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
[    0.259442] calling  cn_init+0x0/0xc0 @ 1
[    0.259466] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
[    0.259477] calling  phy_init+0x0/0x2e @ 1
[    0.260111] initcall phy_init+0x0/0x2e returned 0 after 976 usecs
[    0.260123] calling  init_pcmcia_cs+0x0/0x3d @ 1
[    0.260208] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
[    0.260219] calling  usb_init+0x0/0x170 @ 1
[    0.260418] usbcore: registered new interface driver usbfs
[    0.260511] usbcore: registered new interface driver hub
[    0.260635] usbcore: registered new device driver usb
[    0.260646] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
[    0.260656] calling  serio_init+0x0/0x38 @ 1
[    0.260750] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
[    0.260760] calling  input_init+0x0/0x103 @ 1
[    0.260852] initcall input_init+0x0/0x103 returned 0 after 0 usecs
[    0.260863] calling  rtc_init+0x0/0x71 @ 1
[    0.260943] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
[    0.260954] calling  pps_init+0x0/0xb7 @ 1
[    0.261000] pps_core: LinuxPPS API ver. 1 registered
[    0.261000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.261000] initcall pps_init+0x0/0xb7 returned 0 after 0 usecs
[    0.261014] calling  ptp_init+0x0/0xa4 @ 1
[    0.261102] PTP clock support registered
[    0.261112] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
[    0.261122] calling  power_supply_class_init+0x0/0x44 @ 1
[    0.261204] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
[    0.261215] calling  hwmon_init+0x0/0xf6 @ 1
[    0.261296] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
[    0.261307] calling  leds_init+0x0/0x48 @ 1
[    0.261388] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
[    0.261399] calling  iommu_init+0x0/0x58 @ 1
[    0.261411] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
[    0.261423] calling  pci_subsys_init+0x0/0x4f @ 1
[    0.261432] PCI: System does not support PCI
[    0.261440] PCI: System does not support PCI
[    0.261450] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
[    0.261459] calling  proto_init+0x0/0x12 @ 1
[    0.261474] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[    0.261485] calling  net_dev_init+0x0/0x1c7 @ 1
[    0.261931] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
[    0.261942] calling  neigh_init+0x0/0x80 @ 1
[    0.261952] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
[    0.261961] calling  fib_rules_init+0x0/0xaf @ 1
[    0.261972] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
[    0.261982] calling  pktsched_init+0x0/0xfe @ 1
[    0.261997] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
[    0.262000] calling  tc_filter_init+0x0/0x55 @ 1
[    0.262000] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
[    0.262000] calling  tc_action_init+0x0/0x55 @ 1
[    0.262000] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
[    0.262000] calling  genl_init+0x0/0x75 @ 1
[    0.262033] initcall genl_init+0x0/0x75 returned 0 after 976 usecs
[    0.263021] calling  cipso_v4_init+0x0/0x61 @ 1
[    0.263039] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[    0.263052] calling  netlbl_init+0x0/0x81 @ 1
[    0.263062] NetLabel: Initializing
[    0.263072] NetLabel:  domain hash size = 128
[    0.263081] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.263126] NetLabel:  unlabeled traffic allowed by default
[    0.263137] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[    0.263147] calling  rfkill_init+0x0/0x79 @ 1
[    0.263402] initcall rfkill_init+0x0/0x79 returned 0 after 0 usecs
[    0.263436] calling  xen_p2m_debugfs+0x0/0x4a @ 1
[    0.263478] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
[    0.263489] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
[    0.263645] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
[    0.263659] calling  hpet_late_init+0x0/0x101 @ 1
[    0.263671] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
[    0.263682] calling  init_amd_nbs+0x0/0xb8 @ 1
[    0.263693] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
[    0.263704] calling  clocksource_done_booting+0x0/0x5a @ 1
[    0.263714] Switching to clocksource xen
[    0.263742] initcall clocksource_done_booting+0x0/0x5a returned 0 after 8 usecs
[    0.263756] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
[    0.263756] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 511 usecs
[    0.263756] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[    0.263756] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 7 usecs
[    0.263756] calling  event_trace_init+0x0/0x271 @ 1
[    0.275332] initcall event_trace_init+0x0/0x271 returned 0 after 11443 usecs
[    0.275351] calling  init_kprobe_trace+0x0/0x93 @ 1
[    0.275377] initcall init_kprobe_trace+0x0/0x93 returned 0 after 15 usecs
[    0.275389] calling  init_pipe_fs+0x0/0x4c @ 1
[    0.275432] initcall init_pipe_fs+0x0/0x4c returned 0 after 31 usecs
[    0.275443] calling  eventpoll_init+0x0/0xda @ 1
[    0.275466] initcall eventpoll_init+0x0/0xda returned 0 after 12 usecs
[    0.275477] calling  anon_inode_init+0x0/0x5b @ 1
[    0.275513] initcall anon_inode_init+0x0/0x5b returned 0 after 26 usecs
[    0.275524] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[    0.275533] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
[    0.275543] calling  acpi_event_init+0x0/0x81 @ 1
[    0.275553] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
[    0.275563] calling  pnp_system_init+0x0/0x12 @ 1
[    0.275708] initcall pnp_system_init+0x0/0x12 returned 0 after 131 usecs
[    0.275719] calling  pnpacpi_init+0x0/0x8c @ 1
[    0.275726] pnp: PnP ACPI: disabled
[    0.275734] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
[    0.275742] calling  pcistub_init+0x0/0x29f @ 1
[    0.275843] initcall pcistub_init+0x0/0x29f returned 0 after 90 usecs
[    0.275852] calling  chr_dev_init+0x0/0xc6 @ 1
[    0.283039] initcall chr_dev_init+0x0/0xc6 returned 0 after 7006 usecs
[    0.283108] calling  firmware_class_init+0x0/0xda @ 1
[    0.283203] initcall firmware_class_init+0x0/0xda returned 0 after 82 usecs
[    0.283213] calling  init_pcmcia_bus+0x0/0x6c @ 1
[    0.283298] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 73 usecs
[    0.283309] calling  thermal_init+0x0/0x75 @ 1
[    0.283400] initcall thermal_init+0x0/0x75 returned 0 after 80 usecs
[    0.283411] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
[    0.283422] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
[    0.283432] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[    0.283442] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
[    0.283454] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
[    0.283465] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
[    0.283476] calling  pcibios_assign_resources+0x0/0xf8 @ 1
[    0.283489] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
[    0.283500] calling  sysctl_core_init+0x0/0x2c @ 1
[    0.283523] initcall sysctl_core_init+0x0/0x2c returned 0 after 13 usecs
[    0.283534] calling  inet_init+0x0/0x2a1 @ 1
[    0.283572] NET: Registered protocol family 2
[    0.283850] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.283962] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.284018] TCP: Hash tables configured (established 16384 bind 16384)
[    0.284118] TCP: reno registered
[    0.284136] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    0.284162] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    0.284282] initcall inet_init+0x0/0x2a1 returned 0 after 720 usecs
[    0.284292] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.284304] initcall ipv4_offload_init+0x0/0x68 returned 0 after 1 usecs
[    0.284314] calling  af_unix_init+0x0/0x55 @ 1
[    0.284326] NET: Registered protocol family 1
[    0.284346] initcall af_unix_init+0x0/0x55 returned 0 after 21 usecs
[    0.284356] calling  ipv6_offload_init+0x0/0x6e @ 1
[    0.467091] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
[    0.467106] calling  init_sunrpc+0x0/0x69 @ 1
[    0.467311] RPC: Registered named UNIX socket transport module.
[    0.467321] RPC: Registered udp transport module.
[    0.467330] RPC: Registered tcp transport module.
[    0.467338] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.467348] initcall init_sunrpc+0x0/0x69 returned 0 after 225 usecs
[    0.467358] calling  pci_apply_final_quirks+0x0/0x117 @ 1
[    0.467370] PCI: CLS 0 bytes, default 64
[    0.467379] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 10 usecs
[    0.467390] calling  populate_rootfs+0x0/0x10d @ 1
[    0.467693] Unpacking initramfs...
[    1.224465] Freeing initrd memory: 339320k freed
[    1.330309] initcall populate_rootfs+0x0/0x10d returned 0 after 842675 usecs
[    1.330328] calling  pci_iommu_init+0x0/0x41 @ 1
[    1.330339] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
[    1.330349] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
[    1.330358] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
[    1.330395] calling  irqfd_module_init+0x0/0x33 @ 1
[    1.330489] initcall irqfd_module_init+0x0/0x33 returned 0 after 81 usecs
[    1.330500] calling  i8259A_init_ops+0x0/0x21 @ 1
[    1.330510] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
[    1.330520] calling  vsyscall_init+0x0/0x27 @ 1
[    1.330534] initcall vsyscall_init+0x0/0x27 returned 0 after 4 usecs
[    1.330544] calling  sbf_init+0x0/0xf6 @ 1
[    1.330553] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
[    1.330563] calling  init_tsc_clocksource+0x0/0x89 @ 1
[    1.330576] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
[    1.330585] calling  add_rtc_cmos+0x0/0x96 @ 1
[    1.330729] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    1.330741] initcall add_rtc_cmos+0x0/0x96 returned 0 after 143 usecs
[    1.330751] calling  i8237A_init_ops+0x0/0x14 @ 1
[    1.330761] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.330771] calling  cache_sysfs_init+0x0/0x6c @ 1
[    1.330843] initcall cache_sysfs_init+0x0/0x6c returned 0 after 60 usecs
[    1.330855] calling  intel_uncore_init+0x0/0x3fa @ 1
[    1.330866] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
[    1.330878] calling  inject_init+0x0/0x30 @ 1
[    1.330886] Machine check injector initialized
[    1.330897] initcall inject_init+0x0/0x30 returned 0 after 9 usecs
[    1.330906] calling  thermal_throttle_init_device+0x0/0x9d @ 1
[    1.330917] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
[    1.330929] calling  amd_ibs_init+0x0/0x48d @ 1
[    1.330939] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
[    1.330949] calling  msr_init+0x0/0x162 @ 1
[    1.331168] initcall msr_init+0x0/0x162 returned 0 after 204 usecs
[    1.331179] calling  cpuid_init+0x0/0x162 @ 1
[    1.331356] initcall cpuid_init+0x0/0x162 returned 0 after 161 usecs
[    1.331368] calling  ioapic_init_ops+0x0/0x14 @ 1
[    1.331379] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.331389] calling  add_pcspkr+0x0/0x40 @ 1
[    1.331493] initcall add_pcspkr+0x0/0x40 returned 0 after 91 usecs
[    1.331504] calling  microcode_init+0x0/0x1b1 @ 1
[    1.331600] microcode: CPU0: patch_level=0x06000626
[    1.331698] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    1.331710] initcall microcode_init+0x0/0x1b1 returned 0 after 193 usecs
[    1.331721] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
[    1.331731] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
[    1.331741] calling  audit_classes_init+0x0/0xaf @ 1
[    1.331756] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
[    1.331767] calling  pt_dump_init+0x0/0x30 @ 1
[    1.331801] initcall pt_dump_init+0x0/0x30 returned 0 after 24 usecs
[    1.331815] calling  ia32_binfmt_init+0x0/0x14 @ 1
[    1.331833] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 6 usecs
[    1.331844] calling  proc_execdomains_init+0x0/0x22 @ 1
[    1.331861] initcall proc_execdomains_init+0x0/0x22 returned 0 after 6 usecs
[    1.331871] calling  ioresources_init+0x0/0x3c @ 1
[    1.331887] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
[    1.331896] calling  uid_cache_init+0x0/0xa5 @ 1
[    1.331911] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
[    1.331923] calling  init_posix_timers+0x0/0x1f4 @ 1
[    1.331940] initcall init_posix_timers+0x0/0x1f4 returned 0 after 5 usecs
[    1.331950] calling  init_posix_cpu_timers+0x0/0xbf @ 1
[    1.331959] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
[    1.331969] calling  proc_schedstat_init+0x0/0x22 @ 1
[    1.331982] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
[    1.331992] calling  snapshot_device_init+0x0/0x12 @ 1
[    1.332147] initcall snapshot_device_init+0x0/0x12 returned 0 after 141 usecs
[    1.332162] calling  create_proc_profile+0x0/0x2c0 @ 1
[    1.332173] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
[    1.332185] calling  timekeeping_init_ops+0x0/0x14 @ 1
[    1.332198] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.332209] calling  init_clocksource_sysfs+0x0/0x52 @ 1
[    1.332448] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 219 usecs
[    1.332464] calling  init_timer_list_procfs+0x0/0x2c @ 1
[    1.332489] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 7 usecs
[    1.332504] calling  alarmtimer_init+0x0/0x15d @ 1
[    1.332743] initcall alarmtimer_init+0x0/0x15d returned 0 after 221 usecs
[    1.332754] calling  init_tstats_procfs+0x0/0x2c @ 1
[    1.332771] initcall init_tstats_procfs+0x0/0x2c returned 0 after 5 usecs
[    1.332781] calling  futex_init+0x0/0x65 @ 1
[    1.332804] initcall futex_init+0x0/0x65 returned 0 after 9 usecs
[    1.427360] calling  proc_dma_init+0x0/0x22 @ 1
[    1.427383] initcall proc_dma_init+0x0/0x22 returned 0 after 9 usecs
[    1.427394] calling  proc_modules_init+0x0/0x22 @ 1
[    1.427408] initcall proc_modules_init+0x0/0x22 returned 0 after 4 usecs
[    1.427417] calling  kallsyms_init+0x0/0x25 @ 1
[    1.427430] initcall kallsyms_init+0x0/0x25 returned 0 after 3 usecs
[    1.427440] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
[    1.427469] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 18 usecs
[    1.427480] calling  crash_notes_memory_init+0x0/0x36 @ 1
[    1.427493] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 4 usecs
[    1.427503] calling  pid_namespaces_init+0x0/0x2d @ 1
[    1.427519] initcall pid_namespaces_init+0x0/0x2d returned 0 after 6 usecs
[    1.427529] calling  ikconfig_init+0x0/0x3a @ 1
[    1.427542] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
[    1.427552] calling  audit_init+0x0/0x141 @ 1
[    1.427563] audit: initializing netlink socket (disabled)
[    1.427590] type=2000 audit(1361569070.777:1): initialized
[    1.427603] initcall audit_init+0x0/0x141 returned 0 after 38 usecs
[    1.427613] calling  audit_watch_init+0x0/0x3a @ 1
[    1.427624] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
[    1.427636] calling  audit_tree_init+0x0/0x49 @ 1
[    1.427647] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[    1.427656] calling  init_kprobes+0x0/0x16c @ 1
[    1.439621] initcall init_kprobes+0x0/0x16c returned 0 after 11669 usecs
[    1.439637] calling  hung_task_init+0x0/0x56 @ 1
[    1.439718] initcall hung_task_init+0x0/0x56 returned 0 after 68 usecs
[    1.439729] calling  irq_pm_init_ops+0x0/0x14 @ 1
[    1.439738] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.439748] calling  utsname_sysctl_init+0x0/0x14 @ 1
[    1.439767] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 9 usecs
[    1.439778] calling  init_tracepoints+0x0/0x20 @ 1
[    1.439788] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
[    1.439798] calling  init_blk_tracer+0x0/0x5a @ 1
[    1.439808] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
[    1.439818] calling  perf_event_sysfs_init+0x0/0x9a @ 1
[    1.440270] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 431 usecs
[    1.440283] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
[    1.440420] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 122 usecs
[    1.440433] calling  kswapd_init+0x0/0x76 @ 1
[    1.440489] initcall kswapd_init+0x0/0x76 returned 0 after 45 usecs
[    1.440499] calling  extfrag_debug_init+0x0/0x7e @ 1
[    1.440539] initcall extfrag_debug_init+0x0/0x7e returned 0 after 29 usecs
[    1.440549] calling  setup_vmstat+0x0/0xc8 @ 1
[    1.440578] initcall setup_vmstat+0x0/0xc8 returned 0 after 18 usecs
[    1.440589] calling  mm_sysfs_init+0x0/0x29 @ 1
[    1.440602] initcall mm_sysfs_init+0x0/0x29 returned 0 after 3 usecs
[    1.440613] calling  slab_proc_init+0x0/0x25 @ 1
[    1.440626] initcall slab_proc_init+0x0/0x25 returned 0 after 4 usecs
[    1.440636] calling  proc_vmalloc_init+0x0/0x25 @ 1
[    1.440650] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
[    1.440660] calling  procswaps_init+0x0/0x22 @ 1
[    1.440673] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
[    1.440684] calling  init_frontswap+0x0/0x96 @ 1
[    1.440737] initcall init_frontswap+0x0/0x96 returned 0 after 43 usecs
[    1.440749] calling  hugetlb_init+0x0/0x415 @ 1
[    1.440759] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.440788] initcall hugetlb_init+0x0/0x415 returned 0 after 28 usecs
[    1.440797] calling  mmu_notifier_init+0x0/0x12 @ 1
[    1.440810] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
[    1.440821] calling  slab_proc_init+0x0/0x8 @ 1
[    1.440831] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
[    1.440840] calling  cpucache_init+0x0/0x52 @ 1
[    1.440851] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
[    1.440861] calling  hugepage_init+0x0/0x191 @ 1
[    1.440870] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
[    1.440880] initcall hugepage_init+0x0/0x191 returned with error code -22 
[    1.440890] calling  init_cleancache+0x0/0x96 @ 1
[    1.440939] initcall init_cleancache+0x0/0x96 returned 0 after 38 usecs
[    1.440949] calling  fcntl_init+0x0/0x2a @ 1
[    1.440964] initcall fcntl_init+0x0/0x2a returned 0 after 5 usecs
[    1.440974] calling  proc_filesystems_init+0x0/0x22 @ 1
[    1.440991] initcall proc_filesystems_init+0x0/0x22 returned 0 after 7 usecs
[    1.441002] calling  dio_init+0x0/0x2d @ 1
[    1.441016] initcall dio_init+0x0/0x2d returned 0 after 5 usecs
[    1.441025] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    1.441109] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 71 usecs
[    1.441119] calling  dnotify_init+0x0/0x7b @ 1
[    1.441137] initcall dnotify_init+0x0/0x7b returned 0 after 8 usecs
[    1.441146] calling  inotify_user_setup+0x0/0x70 @ 1
[    1.441163] initcall inotify_user_setup+0x0/0x70 returned 0 after 7 usecs
[    1.441173] calling  aio_setup+0x0/0x7c @ 1
[    1.441192] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
[    1.627775] calling  proc_locks_init+0x0/0x22 @ 1
[    1.627796] initcall proc_locks_init+0x0/0x22 returned 0 after 9 usecs
[    1.627806] calling  init_sys32_ioctl+0x0/0x28 @ 1
[    1.627885] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 67 usecs
[    1.627895] calling  dquot_init+0x0/0x121 @ 1
[    1.627904] VFS: Disk quotas dquot_6.5.2
[    1.627962] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.627974] initcall dquot_init+0x0/0x121 returned 0 after 66 usecs
[    1.627985] calling  init_v2_quota_format+0x0/0x22 @ 1
[    1.627996] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
[    1.628006] calling  quota_init+0x0/0x26 @ 1
[    1.628027] initcall quota_init+0x0/0x26 returned 0 after 10 usecs
[    1.628037] calling  proc_cmdline_init+0x0/0x22 @ 1
[    1.628072] initcall proc_cmdline_init+0x0/0x22 returned 0 after 22 usecs
[    1.628088] calling  proc_consoles_init+0x0/0x22 @ 1
[    1.628105] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
[    1.628115] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[    1.628129] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 4 usecs
[    1.628140] calling  proc_devices_init+0x0/0x22 @ 1
[    1.628154] initcall proc_devices_init+0x0/0x22 returned 0 after 3 usecs
[    1.628165] calling  proc_interrupts_init+0x0/0x22 @ 1
[    1.628179] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
[    1.628189] calling  proc_loadavg_init+0x0/0x22 @ 1
[    1.628204] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
[    1.628214] calling  proc_meminfo_init+0x0/0x22 @ 1
[    1.628228] initcall proc_meminfo_init+0x0/0x22 returned 0 after 3 usecs
[    1.628237] calling  proc_stat_init+0x0/0x22 @ 1
[    1.628251] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
[    1.628261] calling  proc_uptime_init+0x0/0x22 @ 1
[    1.628275] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
[    1.628287] calling  proc_version_init+0x0/0x22 @ 1
[    1.628300] initcall proc_version_init+0x0/0x22 returned 0 after 3 usecs
[    1.645978] calling  proc_softirqs_init+0x0/0x22 @ 1
[    1.646001] initcall proc_softirqs_init+0x0/0x22 returned 0 after 10 usecs
[    1.646012] calling  proc_kcore_init+0x0/0xb5 @ 1
[    1.646032] initcall proc_kcore_init+0x0/0xb5 returned 0 after 8 usecs
[    1.646042] calling  vmcore_init+0x0/0x370 @ 1
[    1.646052] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
[    1.646063] calling  proc_kmsg_init+0x0/0x25 @ 1
[    1.646076] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
[    1.646086] calling  proc_page_init+0x0/0x42 @ 1
[    1.646104] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
[    1.646125] calling  init_devpts_fs+0x0/0x62 @ 1
[    1.646192] initcall init_devpts_fs+0x0/0x62 returned 0 after 54 usecs
[    1.646203] calling  init_ramfs_fs+0x0/0x12 @ 1
[    1.646213] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
[    1.646224] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
[    1.646302] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 66 usecs
[    1.646313] calling  init_fat_fs+0x0/0x4f @ 1
[    1.646329] initcall init_fat_fs+0x0/0x4f returned 0 after 6 usecs
[    1.646340] calling  init_vfat_fs+0x0/0x12 @ 1
[    1.646350] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
[    1.646360] calling  init_msdos_fs+0x0/0x12 @ 1
[    1.646370] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[    1.646380] calling  init_iso9660_fs+0x0/0x70 @ 1
[    1.646412] initcall init_iso9660_fs+0x0/0x70 returned 0 after 22 usecs
[    1.646422] calling  init_nfs_fs+0x0/0x16c @ 1
[    1.646598] initcall init_nfs_fs+0x0/0x16c returned 0 after 162 usecs
[    1.646609] calling  init_nfs_v2+0x0/0x14 @ 1
[    1.646619] initcall init_nfs_v2+0x0/0x14 returned 0 after 0 usecs
[    1.646629] calling  init_nfs_v3+0x0/0x14 @ 1
[    1.646639] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
[    1.646649] calling  init_nfs_v4+0x0/0x3b @ 1
[    1.646658] NFS: Registering the id_resolver key type
[    1.646685] Key type id_resolver registered
[    1.646694] Key type id_legacy registered
[    1.646708] initcall init_nfs_v4+0x0/0x3b returned 0 after 47 usecs
[    1.646717] calling  init_nlm+0x0/0x4c @ 1
[    1.646732] initcall init_nlm+0x0/0x4c returned 0 after 6 usecs
[    1.646742] calling  init_nls_cp437+0x0/0x12 @ 1
[    1.646752] initcall init_nls_cp437+0x0/0x12 returned 0 after 1 usecs
[    1.646760] calling  init_nls_ascii+0x0/0x12 @ 1
[    1.646770] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[    1.646780] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[    1.646790] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[    1.646799] calling  init_nls_utf8+0x0/0x2b @ 1
[    1.646810] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
[    1.646819] calling  init_ntfs_fs+0x0/0x1d1 @ 1
[    1.646827] NTFS driver 2.1.30 [Flags: R/W].
[    1.646853] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 23 usecs
[    1.646863] calling  init_autofs4_fs+0x0/0x2a @ 1
[    1.647010] initcall init_autofs4_fs+0x0/0x2a returned 0 after 133 usecs
[    1.647019] calling  init_pstore_fs+0x0/0x12 @ 1
[    1.647030] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
[    1.647040] calling  ipc_init+0x0/0x2f @ 1
[    1.647079] msgmni has been set to 2923
[    1.647097] initcall ipc_init+0x0/0x2f returned 0 after 46 usecs
[    1.647106] calling  ipc_sysctl_init+0x0/0x14 @ 1
[    1.647123] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.647132] calling  init_mqueue_fs+0x0/0xa2 @ 1
[    1.647183] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 40 usecs
[    1.647193] calling  key_proc_init+0x0/0x5e @ 1
[    1.647210] initcall key_proc_init+0x0/0x5e returned 0 after 7 usecs
[    1.647220] calling  selinux_nf_ip_init+0x0/0x69 @ 1
[    1.647228] SELinux:  Registering netfilter hooks
[    1.647457] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 222 usecs
[    1.647467] calling  init_sel_fs+0x0/0xa5 @ 1
[    1.647812] initcall init_sel_fs+0x0/0xa5 returned 0 after 327 usecs
[    1.647822] calling  selnl_init+0x0/0x56 @ 1
[    1.647839] initcall selnl_init+0x0/0x56 returned 0 after 7 usecs
[    1.647848] calling  sel_netif_init+0x0/0x5c @ 1
[    1.647860] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
[    1.647870] calling  sel_netnode_init+0x0/0x6a @ 1
[    1.647880] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
[    1.647889] calling  sel_netport_init+0x0/0x6a @ 1
[    1.647900] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
[    1.647909] calling  aurule_init+0x0/0x2d @ 1
[    1.647921] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
[    1.647932] calling  crypto_wq_init+0x0/0x33 @ 1
[    1.647976] initcall crypto_wq_init+0x0/0x33 returned 0 after 33 usecs
[    1.647986] calling  crypto_algapi_init+0x0/0xd @ 1
[    1.647999] initcall crypto_algapi_init+0x0/0xd returned 0 after 4 usecs
[    1.829390] calling  skcipher_module_init+0x0/0x35 @ 1
[    1.829403] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
[    1.829414] calling  chainiv_module_init+0x0/0x12 @ 1
[    1.829425] initcall chainiv_module_init+0x0/0x12 returned 0 after 1 usecs
[    1.829435] calling  eseqiv_module_init+0x0/0x12 @ 1
[    1.829445] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.829455] calling  hmac_module_init+0x0/0x12 @ 1
[    1.829464] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.829474] calling  md5_mod_init+0x0/0x12 @ 1
[    1.829598] initcall md5_mod_init+0x0/0x12 returned 0 after 111 usecs
[    1.829609] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[    1.829676] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 55 usecs
[    1.829687] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[    1.829696] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.829706] calling  des_generic_mod_init+0x0/0x17 @ 1
[    1.829828] initcall des_generic_mod_init+0x0/0x17 returned 0 after 109 usecs
[    1.829839] calling  aes_init+0x0/0x12 @ 1
[    1.829904] initcall aes_init+0x0/0x12 returned 0 after 54 usecs
[    1.829917] calling  zlib_mod_init+0x0/0x12 @ 1
[    1.829983] initcall zlib_mod_init+0x0/0x12 returned 0 after 55 usecs
[    1.829995] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[    1.830005] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.830016] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
[    1.830026] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.830037] calling  lzo_mod_init+0x0/0x12 @ 1
[    1.830133] initcall lzo_mod_init+0x0/0x12 returned 0 after 84 usecs
[    1.830143] calling  krng_mod_init+0x0/0x12 @ 1
[    1.830208] initcall krng_mod_init+0x0/0x12 returned 0 after 53 usecs
[    1.830219] calling  proc_genhd_init+0x0/0x3c @ 1
[    1.830241] initcall proc_genhd_init+0x0/0x3c returned 0 after 11 usecs
[    1.830251] calling  bsg_init+0x0/0x12e @ 1
[    1.830364] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.830375] initcall bsg_init+0x0/0x12e returned 0 after 112 usecs
[    1.830385] calling  noop_init+0x0/0x12 @ 1
[    1.830394] io scheduler noop registered
[    1.830403] initcall noop_init+0x0/0x12 returned 0 after 9 usecs
[    1.830412] calling  deadline_init+0x0/0x12 @ 1
[    1.830421] io scheduler deadline registered
[    1.830430] initcall deadline_init+0x0/0x12 returned 0 after 8 usecs
[    1.830439] calling  cfq_init+0x0/0x8b @ 1
[    1.830456] io scheduler cfq registered (default)
[    1.830466] initcall cfq_init+0x0/0x8b returned 0 after 16 usecs
[    1.830475] calling  percpu_counter_startup+0x0/0x38 @ 1
[    1.830488] initcall percpu_counter_startup+0x0/0x38 returned 0 after 2 usecs
[    1.830498] calling  pci_proc_init+0x0/0x6a @ 1
[    1.830517] initcall pci_proc_init+0x0/0x6a returned 0 after 9 usecs
[    1.830527] calling  pcie_portdrv_init+0x0/0x7a @ 1
[    1.830717] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 175 usecs
[    1.830729] calling  aer_service_init+0x0/0x2b @ 1
[    1.830742] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
[    1.830762] IP: [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
[    1.830780] PGD 0 
[    1.830791] Oops: 0000 [#1] SMP 
[    1.830806] Modules linked in:
[    1.830819] CPU 0 
[    1.830827] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc2upstream-00002-g92ef2a2 #1  
[    1.830838] RIP: e030:[<ffffffff813862fa>]  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
[    1.830853] RSP: e02b:ffff88005bb69e98  EFLAGS: 00010246
[    1.830862] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000017
[    1.830871] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81328b30
[    1.830880] RBP: ffff88005bb69eb8 R08: 00000000833df7a7 R09: 0720072007200720
[    1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
[    1.830899] R13: ffffffff81328b30 R14: 0000000000000000 R15: 0000000000000000
[    1.830913] FS:  0000000000000000(0000) GS:ffff88005d600000(0000) knlGS:0000000000000000
[    1.830926] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[    1.830935] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000040660
[    1.830945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.830955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    1.830965] Process swapper/0 (pid: 1, threadinfo ffff88005bb68000, task ffff88005bb627f0)
[    1.830975] Stack:
[    1.830981]  0000000000000030 0000000000000000 ffffffff81ae8f60 000000006d1ed4e7
[    1.831007]  ffff88005bb69ec8 ffffffff81328b8b ffff88005bb69ed8 ffffffff81ae8f72
[    1.831033]  ffff88005bb69f08 ffffffff81002124 0000000000000030 0000000000000007
[    1.831057] Call Trace:
[    1.831057]  [<ffffffff81ae8f60>] ? pcie_portdrv_init+0x7a/0x7a
[    1.831057]  [<ffffffff81328b8b>] aer_acpi_firmware_first+0x1b/0x30
[    1.831057]  [<ffffffff81ae8f72>] aer_service_init+0x12/0x2b
[    1.831057]  [<ffffffff81002124>] do_one_initcall+0x124/0x170
[    1.831057]  [<ffffffff81645404>] kernel_init+0x174/0x2f0
[    1.831057]  [<ffffffff81abd5ca>] ? parse_early_options+0x2b/0x2b
[    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
[    1.831057]  [<ffffffff81663ffc>] ret_from_fork+0x7c/0xb0
[    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
[    1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d 
[    1.831057] RIP  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
[    1.831057]  RSP <ffff88005bb69e98>
[    1.831057] CR2: 0000000000000024
[    2.028436] ---[ end trace dad4411f23c0dcf5 ]---
[    2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
[    2.028476] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    2.028476] 
Parsing config from test.xm
Daemon running with PID 5069

This is what git bisect tells me:

git bisect start
# good: [eb2689e06b3526c7684b09beecf26070f05ee825] Merge tag 'regmap-domain-deps' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good eb2689e06b3526c7684b09beecf26070f05ee825
# bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
# good: [dff8360a4a079692e65e55fbaa6c5dc605528403] Merge tag 'gpio-for-v3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect good dff8360a4a079692e65e55fbaa6c5dc605528403
# good: [8287361abca36504da813638310d2547469283eb] Merge tag 'headers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 8287361abca36504da813638310d2547469283eb
# good: [3c2e81ef344a90bb0a39d84af6878b4aeff568a2] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect good 3c2e81ef344a90bb0a39d84af6878b4aeff568a2
# good: [478740a14826c50595649b3dafed71576796dd95] s390/pci: define read*_relaxed functions
git bisect good 478740a14826c50595649b3dafed71576796dd95
# good: [42976ad0b26b2465f33c9a9146eb15f3a644d269] Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 42976ad0b26b2465f33c9a9146eb15f3a644d269
# good: [88cff241596f29122e9125a41b20d21dfed873cd] Merge tag 'regmap-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good 88cff241596f29122e9125a41b20d21dfed873cd
# good: [10b6339e93244156fac901560117e94bf9dca120] Merge tag 'clk-for-linus' of git://git.linaro.org/people/mturquette/linux
git bisect good 10b6339e93244156fac901560117e94bf9dca120
# bad: [95ecb407699825278f4031f153dbbe0f0713ff28] Merge branch 'pm-tools'
git bisect bad 95ecb407699825278f4031f153dbbe0f0713ff28
# bad: [48694bdb38769c8b9fad4750df25681e32bd815a] Merge branch 'acpica'
git bisect bad 48694bdb38769c8b9fad4750df25681e32bd815a
# good: [3f654bad3257427bea7ba1c4d43a23d99a03622b] ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.
git bisect good 3f654bad3257427bea7ba1c4d43a23d99a03622b
# bad: [b17b537ac1429a609addb55bf985f5ebfcf4ae7b] ACPI / scan: Drop the second argument of acpi_device_unregister()
git bisect bad b17b537ac1429a609addb55bf985f5ebfcf4ae7b
# bad: [209d3b1743c8187c67cc75dbe9fefbcd3121fba0] ACPI: Replace ACPI device add_type field with a match_driver flag
git bisect bad 209d3b1743c8187c67cc75dbe9fefbcd3121fba0
# bad: [a2d06a1a0851fb3d7e775b9d878cdffb9e0300ee] ACPI: Replace struct acpi_bus_ops with enum type
git bisect bad a2d06a1a0851fb3d7e775b9d878cdffb9e0300ee
# bad: [92ef2a25c763338905dce8344a0584606f842920] ACPI: Change the ordering of PCI root bridge driver registrarion
git bisect bad 92ef2a25c763338905dce8344a0584606f842920
# bad: [805d410fb0dbd65e1a57a810858fa2491e75822d] ACPI: Separate adding ACPI device objects from probing ACPI drivers
git bisect bad 805d410fb0dbd65e1a57a810858fa2491e75822d


and just to double-check, if I use commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jan 2 18:13:21 2013 -0800

    Linux 3.8-rc2

(which is the baseline for 805d410fb0dbd65e1a57a810858fa2491e75822d)
the it boots up fine.


And here is with a good (so with 3.8-rc2):

[    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.001000] pid_max: default: 32768 minimum: 301
[    0.001000] Security Framework initialized
[    0.001000] SELinux:  Initializing.
[    0.001000] SELinux:  Starting in permissive mode
[    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001186] Mount-cache hash table entries: 256
[    0.001416] Initializing cgroup subsys cpuacct
[    0.001422] Initializing cgroup subsys freezer
[    0.001477] tseg: 00adf00000
[    0.001484] CPU: Physical Processor ID: 0
[    0.001489] CPU: Processor Core ID: 6
[    0.001495] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.001495] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.001495] tlb_flushall_shift: 5
[    0.022164] cpu 0 spinlock event irq 17
[    0.022202] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
[    0.022211] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
[    0.022219] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
[    0.022227] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
[    0.022236] calling  init_hw_perf_events+0x0/0x414 @ 1
[    0.022242] Performance Events: 
[    0.022247] perf: AMD core performance counters detected
[    0.022254] no APIC, boot with the "lapic" boot parameter to force-enable it.
[    0.022261] no hardware sampling interrupt available.
[    0.022277] Broken PMU hardware detected, using software events only.
[    0.022284] Failed to access perfctr msr (MSR c0010201 is 0)
[    0.022292] initcall init_hw_perf_events+0x0/0x414 returned 0 after 0 usecs
[    0.022299] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
[    0.022307] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
[    0.022316] calling  spawn_ksoftirqd+0x0/0x28 @ 1
[    0.022360] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
[    0.022368] calling  init_workqueues+0x0/0x33a @ 1
[    0.022543] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
[    0.022552] calling  migration_init+0x0/0x71 @ 1
[    0.022560] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
[    0.022568] calling  cpu_stop_init+0x0/0xb4 @ 1
[    0.022606] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
[    0.022615] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
[    0.022622] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
[    0.022630] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
[    0.022684] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
[    0.022692] calling  relay_init+0x0/0x14 @ 1
[    0.022698] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[    0.022705] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
[    0.022746] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
[    0.022753] calling  init_events+0x0/0x61 @ 1
[    0.022761] initcall init_events+0x0/0x61 returned 0 after 0 usecs
[    0.022768] calling  init_trace_printk+0x0/0x12 @ 1
[    0.022775] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[    0.022782] calling  jump_label_init_module+0x0/0x12 @ 1
[    0.022789] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
[    0.022797] calling  mce_amd_init+0x0/0x110 @ 1
[    0.022803] MCE: In-kernel MCE decoding enabled.
[    0.022811] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
[    0.022903] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.023115] installing Xen timer for CPU 1
[    0.023134] cpu 1 spinlock event irq 24
[    0.023185] SMP alternatives: switching to SMP code
[    0.042382] installing Xen timer for CPU 2
[    0.042402] cpu 2 spinlock event irq 31
[    0.042544] Brought up 3 CPUs
[    0.044906] calling  ipc_ns_init+0x0/0x14 @ 1
[    0.044915] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
[    0.044923] calling  init_mmap_min_addr+0x0/0x26 @ 1
[    0.044930] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[    0.044938] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[    0.044948] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
[    0.044957] calling  net_ns_init+0x0/0xfd @ 1
[    0.044990] initcall net_ns_init+0x0/0xfd returned 0 after 0 usecs
[    0.045019] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
[    0.045027] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
[    0.045036] calling  cpufreq_tsc+0x0/0x37 @ 1
[    0.045044] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
[    0.046007] calling  reboot_init+0x0/0x1d @ 1
[    0.046017] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
[    0.046025] calling  init_lapic_sysfs+0x0/0x20 @ 1
[    0.046032] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
[    0.046040] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
[    0.046049] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
[    0.046057] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.046065] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.046073] calling  ksysfs_init+0x0/0x94 @ 1
[    0.046094] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[    0.046103] calling  pm_init+0x0/0x4e @ 1
[    0.046117] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
[    0.046125] calling  pm_disk_init+0x0/0x19 @ 1
[    0.046136] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[    0.046146] calling  swsusp_header_init+0x0/0x30 @ 1
[    0.046154] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
[    0.046162] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[    0.046172] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
[    0.046181] calling  event_trace_enable+0x0/0xa9 @ 1
[    0.046213] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
[    0.046222] calling  init_zero_pfn+0x0/0x35 @ 1
[    0.046229] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
[    0.046237] calling  fsnotify_init+0x0/0x26 @ 1
[    0.046246] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
[    0.046254] calling  filelock_init+0x0/0x2a @ 1
[    0.046281] initcall filelock_init+0x0/0x2a returned 0 after 0 usecs
[    0.046290] calling  init_misc_binfmt+0x0/0x31 @ 1
[    0.046298] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
[    0.046306] calling  init_script_binfmt+0x0/0x16 @ 1
[    0.046314] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046322] calling  init_elf_binfmt+0x0/0x16 @ 1
[    0.046330] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046338] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
[    0.046346] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046354] calling  debugfs_init+0x0/0x5c @ 1
[    0.046364] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[    0.046371] calling  securityfs_init+0x0/0x53 @ 1
[    0.046381] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
[    0.046389] calling  prandom_init+0x0/0xd9 @ 1
[    0.046397] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
[    0.046406] calling  virtio_init+0x0/0x30 @ 1
[    0.046429] kworker/u:0 (26) used greatest stack depth: 6136 bytes left
[    0.046429] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  __gnttab_init+0x0/0x30 @ 1
[    0.046429] Grant tables using version 2 layout.
[    0.046429] Grant table initialized
[    0.046429] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  early_resume_init+0x0/0x1d0 @ 1
[    0.065694] RTC time: 165:165:165, date: 165/165/65
[    0.065702] initcall early_resume_init+0x0/0x1d0 returned 0 after 18554 usecs
[    0.065711] calling  cpufreq_core_init+0x0/0xc7 @ 1
[    0.065719] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
[    0.065727] calling  cpuidle_init+0x0/0x40 @ 1
[    0.065734] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
[    0.065742] calling  bsp_pm_check_init+0x0/0x14 @ 1
[    0.065749] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
[    0.065756] calling  sock_init+0x0/0x89 @ 1
[    0.065842] initcall sock_init+0x0/0x89 returned 0 after 0 usecs
[    0.065850] calling  net_inuse_init+0x0/0x26 @ 1
[    0.065859] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[    0.065867] calling  netpoll_init+0x0/0x31 @ 1
[    0.065874] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[    0.065881] calling  netlink_proto_init+0x0/0x1b3 @ 1
[    0.065897] NET: Registered protocol family 16
[    0.065917] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
[    0.065938] calling  bdi_class_init+0x0/0x4d @ 1
[    0.066049] initcall bdi_class_init+0x0/0x4d returned 0 after 976 usecs
[    0.066060] calling  kobject_uevent_init+0x0/0x12 @ 1
[    0.066071] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
[    0.066079] calling  pcibus_class_init+0x0/0x19 @ 1
[    0.066096] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  pci_driver_init+0x0/0x19 @ 1
[    0.066096] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  backlight_class_init+0x0/0x5d @ 1
[    0.067045] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
[    0.067045] calling  video_output_class_init+0x0/0x19 @ 1
[    0.067063] kworker/u:0 (31) used greatest stack depth: 5592 bytes left
[    0.067063] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.067063] calling  xenbus_init+0x0/0x21a @ 1
[    0.067093] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
[    0.067093] calling  tty_class_init+0x0/0x38 @ 1
[    0.067093] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
[    0.067093] calling  vtconsole_class_init+0x0/0xc2 @ 1
[    0.067093] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
[    0.067093] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
[    0.067093] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
[    0.067093] calling  register_node_type+0x0/0x34 @ 1
[    0.067093] initcall register_node_type+0x0/0x34 returned 0 after 0 usecs
[    0.067093] calling  i2c_init+0x0/0x77 @ 1
[    0.068032] initcall i2c_init+0x0/0x77 returned 0 after 976 usecs
[    0.068043] calling  amd_postcore_init+0x0/0x143 @ 1
[    0.068130] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
[    0.068160] calling  set_real_mode_permissions+0x0/0xa9 @ 1
[    0.068216] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 0 usecs
[    0.068227] calling  arch_kdebugfs_init+0x0/0x233 @ 1
[    0.068268] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
[    0.068278] calling  mtrr_if_init+0x0/0x78 @ 1
[    0.068286] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
[    0.068294] calling  ffh_cstate_init+0x0/0x2a @ 1
[    0.068303] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
[    0.068311] initcall ffh_cstate_init+0x0/0x2a returned with error code -1 
[    0.068319] calling  activate_jump_labels+0x0/0x32 @ 1
[    0.068327] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
[    0.068335] calling  acpi_pci_init+0x0/0x5c @ 1
[    0.068343] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
[    0.068352] calling  dma_bus_init+0x0/0x19 @ 1
[    0.068371] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
[    0.068371] calling  dma_channel_table_init+0x0/0x119 @ 1
[    0.068371] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
[    0.068371] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[    0.070221] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 1953 usecs
[    0.070233] calling  register_xen_pci_notifier+0x0/0x38 @ 1
[    0.070241] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
[    0.070249] calling  xen_pcpu_init+0x0/0xcc @ 1
[    0.070256] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
[    0.070264] calling  dmi_id_init+0x0/0x31d @ 1
[    0.070272] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
[    0.070280] calling  dca_init+0x0/0x20 @ 1
[    0.070286] dca service started, version 1.12.1
[    0.070358] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
[    0.070366] calling  pci_arch_init+0x0/0x69 @ 1
[    0.071009] PCI: setting up Xen PCI frontend stub
[    0.071016] PCI: pci_cache_line_size set to 64 bytes
[    0.071024] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
[    0.071045] calling  topology_init+0x0/0x98 @ 1
[    0.071262] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
[    0.071271] calling  mtrr_init_finialize+0x0/0x36 @ 1
[    0.071278] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
[    0.071286] calling  init_vdso+0x0/0x135 @ 1
[    0.071296] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
[    0.071304] calling  sysenter_setup+0x0/0x2dd @ 1
[    0.071314] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
[    0.071322] calling  param_sysfs_init+0x0/0x192 @ 1
[    0.083778] initcall param_sysfs_init+0x0/0x192 returned 0 after 11718 usecs
[    0.083790] calling  pm_sysrq_init+0x0/0x19 @ 1
[    0.083800] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[    0.083808] calling  default_bdi_init+0x0/0x37 @ 1
[    0.083946] initcall default_bdi_init+0x0/0x37 returned 0 after 0 usecs
[    0.084039] calling  init_bio+0x0/0xe8 @ 1
[    0.084059] bio: create slab <bio-0> at 0
[    0.084078] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
[    0.084087] calling  fsnotify_notification_init+0x0/0x8b @ 1
[    0.084105] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
[    0.084114] calling  cryptomgr_init+0x0/0x12 @ 1
[    0.084122] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[    0.084130] calling  blk_settings_init+0x0/0x2c @ 1
[    0.084138] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
[    0.084146] calling  blk_ioc_init+0x0/0x2a @ 1
[    0.084157] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[    0.084165] calling  blk_softirq_init+0x0/0x6e @ 1
[    0.084174] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[    0.084181] calling  blk_iopoll_setup+0x0/0x6e @ 1
[    0.084189] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[    0.084197] calling  genhd_device_init+0x0/0x85 @ 1
[    0.084326] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
[    0.084337] calling  pci_slot_init+0x0/0x50 @ 1
[    0.084347] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
[    0.084355] calling  fbmem_init+0x0/0x98 @ 1
[    0.084428] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
[    0.084438] calling  acpi_init+0x0/0xbc @ 1
[    0.084444] ACPI: Interpreter disabled.
[    0.084451] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
[    0.084459] calling  dock_init+0x0/0x7b @ 1
[    0.084467] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
[    0.084475] calling  acpi_pci_root_init+0x0/0x32 @ 1
[    0.084483] initcall acpi_pci_root_init+0x0/0x32 returned 0 after 0 usecs
[    0.084491] calling  acpi_pci_link_init+0x0/0x43 @ 1
[    0.084499] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
[    0.084507] calling  pnp_init+0x0/0x19 @ 1
[    0.084576] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
[    0.084586] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
[    0.084600] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 0 usecs
[    0.084600] calling  balloon_init+0x0/0x133 @ 1
[    0.084600] xen/balloon: Initialising balloon driver.
[    0.084600] initcall balloon_init+0x0/0x133 returned 0 after 0 usecs
[    0.084600] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
[    0.085058] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 976 usecs
[    0.085058] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
[    0.085110] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 0 usecs
[    0.085110] calling  xen_acpi_pad_init+0x0/0x47 @ 1
[    0.085110] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
[    0.085110] calling  balloon_init+0x0/0xfa @ 1
[    0.085110] xen-balloon: Initialising balloon driver.
[    0.086035] initcall balloon_init+0x0/0xfa returned 0 after 976 usecs
[    0.086035] calling  xen_selfballoon_init+0x0/0xb9 @ 1
[    0.086043] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
[    0.086051] calling  misc_init+0x0/0xba @ 1
[    0.086151] initcall misc_init+0x0/0xba returned 0 after 0 usecs
[    0.086159] calling  vga_arb_device_init+0x0/0xde @ 1
[    0.086269] vgaarb: loaded
[    0.086276] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
[    0.086285] calling  cn_init+0x0/0xc0 @ 1
[    0.086302] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
[    0.086310] calling  phy_init+0x0/0x2e @ 1
[    0.086493] initcall phy_init+0x0/0x2e returned 0 after 0 usecs
[    0.086501] calling  init_pcmcia_cs+0x0/0x3d @ 1
[    0.086564] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
[    0.086572] calling  usb_init+0x0/0x170 @ 1
[    0.086726] usbcore: registered new interface driver usbfs
[    0.086798] usbcore: registered new interface driver hub
[    0.086890] usbcore: registered new device driver usb
[    0.086898] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
[    0.086906] calling  serio_init+0x0/0x38 @ 1
[    0.086974] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
[    0.086982] calling  input_init+0x0/0x103 @ 1
[    0.087087] initcall input_init+0x0/0x103 returned 0 after 0 usecs
[    0.087095] calling  rtc_init+0x0/0x71 @ 1
[    0.087158] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
[    0.087166] calling  pps_init+0x0/0xb7 @ 1
[    0.087227] pps_core: LinuxPPS API ver. 1 registered
[    0.088018] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.088030] initcall pps_init+0x0/0xb7 returned 0 after 976 usecs
[    0.088038] calling  ptp_init+0x0/0xa4 @ 1
[    0.088113] PTP clock support registered
[    0.088122] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
[    0.088130] calling  power_supply_class_init+0x0/0x44 @ 1
[    0.088195] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
[    0.088204] calling  hwmon_init+0x0/0xf6 @ 1
[    0.088268] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
[    0.088277] calling  leds_init+0x0/0x48 @ 1
[    0.088340] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
[    0.088349] calling  iommu_init+0x0/0x58 @ 1
[    0.088359] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
[    0.088367] calling  pci_subsys_init+0x0/0x4f @ 1
[    0.088374] PCI: System does not support PCI
[    0.088381] PCI: System does not support PCI
[    0.088388] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
[    0.088396] calling  proto_init+0x0/0x12 @ 1
[    0.088407] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[    0.088415] calling  net_dev_init+0x0/0x1c7 @ 1
[    0.088739] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
[    0.088748] calling  neigh_init+0x0/0x80 @ 1
[    0.088757] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
[    0.088765] calling  fib_rules_init+0x0/0xaf @ 1
[    0.088773] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
[    0.088781] calling  pktsched_init+0x0/0xfe @ 1
[    0.088792] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
[    0.088800] calling  tc_filter_init+0x0/0x55 @ 1
[    0.088807] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
[    0.088816] calling  tc_action_init+0x0/0x55 @ 1
[    0.088823] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
[    0.088831] calling  genl_init+0x0/0x75 @ 1
[    0.088845] initcall genl_init+0x0/0x75 returned 0 after 0 usecs
[    0.088853] calling  cipso_v4_init+0x0/0x61 @ 1
[    0.088862] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[    0.088870] calling  netlbl_init+0x0/0x81 @ 1
[    0.088876] NetLabel: Initializing
[    0.088882] NetLabel:  domain hash size = 128
[    0.088888] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.088910] NetLabel:  unlabeled traffic allowed by default
[    0.088919] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[    0.088926] calling  rfkill_init+0x0/0x79 @ 1
[    0.089030] initcall rfkill_init+0x0/0x79 returned 0 after 976 usecs
[    0.089054] calling  xen_p2m_debugfs+0x0/0x4a @ 1
[    0.089087] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
[    0.089095] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
[    0.089219] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
[    0.089228] calling  hpet_late_init+0x0/0x101 @ 1
[    0.089235] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
[    0.089243] calling  init_amd_nbs+0x0/0xb8 @ 1
[    0.089251] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
[    0.089260] calling  clocksource_done_booting+0x0/0x5a @ 1
[    0.089267] Switching to clocksource xen
[    0.089294] initcall clocksource_done_booting+0x0/0x5a returned 0 after 11 usecs
[    0.089303] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
[    0.089711] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 391 usecs
[    0.089720] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[    0.089734] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 6 usecs
[    0.089743] calling  event_trace_init+0x0/0x271 @ 1
[    0.099475] initcall event_trace_init+0x0/0x271 returned 0 after 9769 usecs
[    0.099485] calling  init_kprobe_trace+0x0/0x93 @ 1
[    0.099505] initcall init_kprobe_trace+0x0/0x93 returned 0 after 12 usecs
[    0.099513] calling  init_pipe_fs+0x0/0x4c @ 1
[    0.099543] initcall init_pipe_fs+0x0/0x4c returned 0 after 22 usecs
[    0.099552] calling  eventpoll_init+0x0/0xda @ 1
[    0.099566] initcall eventpoll_init+0x0/0xda returned 0 after 6 usecs
[    0.099574] calling  anon_inode_init+0x0/0x5b @ 1
[    0.099604] initcall anon_inode_init+0x0/0x5b returned 0 after 21 usecs
[    0.099612] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[    0.099620] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
[    0.287868] calling  acpi_event_init+0x0/0x81 @ 1
[    0.287878] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
[    0.287887] calling  pnp_system_init+0x0/0x12 @ 1
[    0.288027] initcall pnp_system_init+0x0/0x12 returned 0 after 127 usecs
[    0.288036] calling  pnpacpi_init+0x0/0x8c @ 1
[    0.288044] pnp: PnP ACPI: disabled
[    0.288052] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
[    0.288100] calling  pcistub_init+0x0/0x29f @ 1
[    0.288197] initcall pcistub_init+0x0/0x29f returned 0 after 86 usecs
[    0.288207] calling  chr_dev_init+0x0/0xc6 @ 1
[    0.293859] initcall chr_dev_init+0x0/0xc6 returned 0 after 5511 usecs
[    0.293869] calling  firmware_class_init+0x0/0xda @ 1
[    0.293941] initcall firmware_class_init+0x0/0xda returned 0 after 60 usecs
[    0.293951] calling  init_pcmcia_bus+0x0/0x6c @ 1
[    0.294023] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 62 usecs
[    0.294032] calling  thermal_init+0x0/0x75 @ 1
[    0.294193] initcall thermal_init+0x0/0x75 returned 0 after 149 usecs
[    0.294203] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
[    0.294212] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
[    0.294221] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[    0.294229] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
[    0.294239] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
[    0.294247] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
[    0.294256] calling  pcibios_assign_resources+0x0/0xf8 @ 1
[    0.294267] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
[    0.294276] calling  sysctl_core_init+0x0/0x2c @ 1
[    0.294295] initcall sysctl_core_init+0x0/0x2c returned 0 after 11 usecs
[    0.294303] calling  inet_init+0x0/0x2a1 @ 1
[    0.294332] NET: Registered protocol family 2
[    0.294575] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294649] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294697] TCP: Hash tables configured (established 16384 bind 16384)
[    0.294733] TCP: reno registered
[    0.294747] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294767] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294857] initcall inet_init+0x0/0x2a1 returned 0 after 533 usecs
[    0.294866] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.294875] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs
[    0.294883] calling  af_unix_init+0x0/0x55 @ 1
[    0.294891] NET: Registered protocol family 1
[    0.294907] initcall af_unix_init+0x0/0x55 returned 0 after 16 usecs
[    0.294916] calling  ipv6_offload_init+0x0/0x6e @ 1
[    0.294925] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
[    0.294933] calling  init_sunrpc+0x0/0x69 @ 1
[    0.295092] RPC: Registered named UNIX socket transport module.
[    0.295101] RPC: Registered udp transport module.
[    0.295108] RPC: Registered tcp transport module.
[    0.295114] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.295123] initcall init_sunrpc+0x0/0x69 returned 0 after 177 usecs
[    0.295131] calling  pci_apply_final_quirks+0x0/0x117 @ 1
[    0.295139] PCI: CLS 0 bytes, default 64
[    0.295146] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 6 usecs
[    0.295155] calling  populate_rootfs+0x0/0x10d @ 1
[    0.295384] Unpacking initramfs...
[    0.854446] Freeing initrd memory: 339316k freed
[    0.941088] initcall populate_rootfs+0x0/0x10d returned 0 after 630779 usecs
[    0.941109] calling  pci_iommu_init+0x0/0x41 @ 1
[    0.941118] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
[    0.941126] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
[    0.941135] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
[    0.941164] calling  irqfd_module_init+0x0/0x33 @ 1
[    0.941260] initcall irqfd_module_init+0x0/0x33 returned 0 after 85 usecs
[    0.941270] calling  i8259A_init_ops+0x0/0x21 @ 1
[    0.941278] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
[    0.941286] calling  vsyscall_init+0x0/0x27 @ 1
[    0.941303] initcall vsyscall_init+0x0/0x27 returned 0 after 6 usecs
[    0.941312] calling  sbf_init+0x0/0xf6 @ 1
[    0.941320] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
[    0.941330] calling  init_tsc_clocksource+0x0/0x89 @ 1
[    0.941343] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
[    0.941353] calling  add_rtc_cmos+0x0/0x96 @ 1
[    0.941554] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.941575] initcall add_rtc_cmos+0x0/0x96 returned 0 after 204 usecs
[    0.941587] calling  i8237A_init_ops+0x0/0x14 @ 1
[    0.941597] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.941610] calling  cache_sysfs_init+0x0/0x6c @ 1
[    0.941692] initcall cache_sysfs_init+0x0/0x6c returned 0 after 70 usecs
[    0.941703] calling  intel_uncore_init+0x0/0x3fa @ 1
[    0.941712] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
[    0.941721] calling  inject_init+0x0/0x30 @ 1
[    0.941728] Machine check injector initialized
[    0.941737] initcall inject_init+0x0/0x30 returned 0 after 7 usecs
[    0.941745] calling  thermal_throttle_init_device+0x0/0x9d @ 1
[    0.941754] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
[    0.941763] calling  amd_ibs_init+0x0/0x48d @ 1
[    0.941772] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
[    0.941781] calling  msr_init+0x0/0x162 @ 1
[    0.941942] initcall msr_init+0x0/0x162 returned 0 after 149 usecs
[    0.941952] calling  cpuid_init+0x0/0x162 @ 1
[    0.942124] initcall cpuid_init+0x0/0x162 returned 0 after 159 usecs
[    0.942133] calling  ioapic_init_ops+0x0/0x14 @ 1
[    0.942141] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942149] calling  add_pcspkr+0x0/0x40 @ 1
[    0.942229] initcall add_pcspkr+0x0/0x40 returned 0 after 70 usecs
[    0.942238] calling  microcode_init+0x0/0x1b1 @ 1
[    0.942318] microcode: CPU0: patch_level=0x06000626
[    0.942401] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.942412] initcall microcode_init+0x0/0x1b1 returned 0 after 162 usecs
[    0.942422] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
[    0.942430] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
[    0.942439] calling  audit_classes_init+0x0/0xaf @ 1
[    0.942452] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
[    0.942460] calling  pt_dump_init+0x0/0x30 @ 1
[    0.942485] initcall pt_dump_init+0x0/0x30 returned 0 after 16 usecs
[    0.942494] calling  ia32_binfmt_init+0x0/0x14 @ 1
[    0.942507] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 5 usecs
[    0.942515] calling  proc_execdomains_init+0x0/0x22 @ 1
[    0.942529] initcall proc_execdomains_init+0x0/0x22 returned 0 after 5 usecs
[    0.942538] calling  ioresources_init+0x0/0x3c @ 1
[    0.942552] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
[    0.942561] calling  uid_cache_init+0x0/0xa5 @ 1
[    0.942574] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
[    0.942582] calling  init_posix_timers+0x0/0x1f4 @ 1
[    0.942598] initcall init_posix_timers+0x0/0x1f4 returned 0 after 7 usecs
[    0.942606] calling  init_posix_cpu_timers+0x0/0xbf @ 1
[    0.942614] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
[    0.942623] calling  proc_schedstat_init+0x0/0x22 @ 1
[    0.942634] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
[    0.942642] calling  snapshot_device_init+0x0/0x12 @ 1
[    0.942724] initcall snapshot_device_init+0x0/0x12 returned 0 after 72 usecs
[    0.942733] calling  create_proc_profile+0x0/0x2c0 @ 1
[    0.942741] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
[    0.942749] calling  timekeeping_init_ops+0x0/0x14 @ 1
[    0.942757] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942765] calling  init_clocksource_sysfs+0x0/0x52 @ 1
[    0.942913] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 136 usecs
[    0.942923] calling  init_timer_list_procfs+0x0/0x2c @ 1
[    0.942934] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 3 usecs
[    0.942943] calling  alarmtimer_init+0x0/0x15d @ 1
[    0.943122] initcall alarmtimer_init+0x0/0x15d returned 0 after 166 usecs
[    0.943131] calling  init_tstats_procfs+0x0/0x2c @ 1
[    0.943143] initcall init_tstats_procfs+0x0/0x2c returned 0 after 4 usecs
[    0.943150] calling  futex_init+0x0/0x65 @ 1
[    0.943163] initcall futex_init+0x0/0x65 returned 0 after 5 usecs
[    0.943170] calling  proc_dma_init+0x0/0x22 @ 1
[    0.943181] initcall proc_dma_init+0x0/0x22 returned 0 after 3 usecs
[    0.943188] calling  proc_modules_init+0x0/0x22 @ 1
[    0.943199] initcall proc_modules_init+0x0/0x22 returned 0 after 3 usecs
[    0.943207] calling  kallsyms_init+0x0/0x25 @ 1
[    0.943217] initcall kallsyms_init+0x0/0x25 returned 0 after 2 usecs
[    0.943224] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
[    1.054869] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 14 usecs
[    1.054879] calling  crash_notes_memory_init+0x0/0x36 @ 1
[    1.054891] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 3 usecs
[    1.054900] calling  pid_namespaces_init+0x0/0x2d @ 1
[    1.054910] initcall pid_namespaces_init+0x0/0x2d returned 0 after 2 usecs
[    1.054918] calling  ikconfig_init+0x0/0x3a @ 1
[    1.054929] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
[    1.054936] calling  audit_init+0x0/0x141 @ 1
[    1.054943] audit: initializing netlink socket (disabled)
[    1.054961] type=2000 audit(1361569587.289:1): initialized
[    1.054971] initcall audit_init+0x0/0x141 returned 0 after 26 usecs
[    1.054979] calling  audit_watch_init+0x0/0x3a @ 1
[    1.054986] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
[    1.054994] calling  audit_tree_init+0x0/0x49 @ 1
[    1.055003] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[    1.055010] calling  init_kprobes+0x0/0x16c @ 1
[    1.065934] initcall init_kprobes+0x0/0x16c returned 0 after 10660 usecs
[    1.065947] calling  hung_task_init+0x0/0x56 @ 1
[    1.065990] initcall hung_task_init+0x0/0x56 returned 0 after 33 usecs
[    1.065998] calling  irq_pm_init_ops+0x0/0x14 @ 1
[    1.066009] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.066017] calling  utsname_sysctl_init+0x0/0x14 @ 1
[    1.066031] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.066039] calling  init_tracepoints+0x0/0x20 @ 1
[    1.066047] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
[    1.066083] calling  init_blk_tracer+0x0/0x5a @ 1
[    1.066092] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
[    1.066100] calling  perf_event_sysfs_init+0x0/0x9a @ 1
[    1.066383] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 268 usecs
[    1.066394] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
[    1.066511] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 105 usecs
[    1.066521] calling  kswapd_init+0x0/0x76 @ 1
[    1.066562] initcall kswapd_init+0x0/0x76 returned 0 after 32 usecs
[    1.066571] calling  extfrag_debug_init+0x0/0x7e @ 1
[    1.066600] initcall extfrag_debug_init+0x0/0x7e returned 0 after 20 usecs
[    1.066609] calling  setup_vmstat+0x0/0xc8 @ 1
[    1.066630] initcall setup_vmstat+0x0/0xc8 returned 0 after 13 usecs
[    1.066639] calling  mm_sysfs_init+0x0/0x29 @ 1
[    1.066649] initcall mm_sysfs_init+0x0/0x29 returned 0 after 2 usecs
[    1.066657] calling  slab_proc_init+0x0/0x25 @ 1
[    1.066668] initcall slab_proc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066676] calling  proc_vmalloc_init+0x0/0x25 @ 1
[    1.066687] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066695] calling  procswaps_init+0x0/0x22 @ 1
[    1.066706] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
[    1.066714] calling  init_frontswap+0x0/0x96 @ 1
[    1.066761] initcall init_frontswap+0x0/0x96 returned 0 after 37 usecs
[    1.066771] calling  hugetlb_init+0x0/0x415 @ 1
[    1.066781] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.066813] initcall hugetlb_init+0x0/0x415 returned 0 after 31 usecs
[    1.066822] calling  mmu_notifier_init+0x0/0x12 @ 1
[    1.066833] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
[    1.066843] calling  slab_proc_init+0x0/0x8 @ 1
[    1.066852] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
[    1.066861] calling  cpucache_init+0x0/0x52 @ 1
[    1.066871] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
[    1.066881] calling  hugepage_init+0x0/0x191 @ 1
[    1.066890] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
[    1.066900] initcall hugepage_init+0x0/0x191 returned with error code -22 
[    1.066910] calling  init_cleancache+0x0/0x96 @ 1
[    1.066956] initcall init_cleancache+0x0/0x96 returned 0 after 35 usecs
[    1.066964] calling  fcntl_init+0x0/0x2a @ 1
[    1.066974] initcall fcntl_init+0x0/0x2a returned 0 after 2 usecs
[    1.066983] calling  proc_filesystems_init+0x0/0x22 @ 1
[    1.066997] initcall proc_filesystems_init+0x0/0x22 returned 0 after 6 usecs
[    1.067005] calling  dio_init+0x0/0x2d @ 1
[    1.067017] initcall dio_init+0x0/0x2d returned 0 after 4 usecs
[    1.067025] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    1.067086] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 51 usecs
[    1.067094] calling  dnotify_init+0x0/0x7b @ 1
[    1.067112] initcall dnotify_init+0x0/0x7b returned 0 after 9 usecs
[    1.067120] calling  inotify_user_setup+0x0/0x70 @ 1
[    1.067135] initcall inotify_user_setup+0x0/0x70 returned 0 after 6 usecs
[    1.067143] calling  aio_setup+0x0/0x7c @ 1
[    1.067160] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
[    1.067168] calling  proc_locks_init+0x0/0x22 @ 1
[    1.067179] initcall proc_locks_init+0x0/0x22 returned 0 after 3 usecs
[    1.067187] calling  init_sys32_ioctl+0x0/0x28 @ 1
[    1.255161] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 71 usecs
[    1.255177] calling  dquot_init+0x0/0x121 @ 1
[    1.255185] VFS: Disk quotas dquot_6.5.2
[    1.255226] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.255238] initcall dquot_init+0x0/0x121 returned 0 after 50 usecs
[    1.255249] calling  init_v2_quota_format+0x0/0x22 @ 1
[    1.255259] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
[    1.255267] calling  quota_init+0x0/0x26 @ 1
[    1.255286] initcall quota_init+0x0/0x26 returned 0 after 8 usecs
[    1.255296] calling  proc_cmdline_init+0x0/0x22 @ 1
[    1.255312] initcall proc_cmdline_init+0x0/0x22 returned 0 after 5 usecs
[    1.255323] calling  proc_consoles_init+0x0/0x22 @ 1
[    1.255338] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
[    1.255349] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[    1.255362] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 3 usecs
[    1.255371] calling  proc_devices_init+0x0/0x22 @ 1
[    1.255383] initcall proc_devices_init+0x0/0x22 returned 0 after 4 usecs
[    1.255393] calling  proc_interrupts_init+0x0/0x22 @ 1
[    1.255407] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
[    1.255418] calling  proc_loadavg_init+0x0/0x22 @ 1
[    1.255432] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
[    1.255442] calling  proc_meminfo_init+0x0/0x22 @ 1
[    1.255457] initcall proc_meminfo_init+0x0/0x22 returned 0 after 4 usecs
[    1.255467] calling  proc_stat_init+0x0/0x22 @ 1
[    1.255481] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
[    1.255491] calling  proc_uptime_init+0x0/0x22 @ 1
[    1.255505] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
[    1.255516] calling  proc_version_init+0x0/0x22 @ 1
[    1.255530] initcall proc_version_init+0x0/0x22 returned 0 after 4 usecs
[    1.255540] calling  proc_softirqs_init+0x0/0x22 @ 1
[    1.255554] initcall proc_softirqs_init+0x0/0x22 returned 0 after 4 usecs
[    1.255565] calling  proc_kcore_init+0x0/0xb5 @ 1
[    1.255581] initcall proc_kcore_init+0x0/0xb5 returned 0 after 7 usecs
[    1.255592] calling  vmcore_init+0x0/0x370 @ 1
[    1.255602] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
[    1.255612] calling  proc_kmsg_init+0x0/0x25 @ 1
[    1.255627] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
[    1.255637] calling  proc_page_init+0x0/0x42 @ 1
[    1.255655] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
[    1.255665] calling  init_devpts_fs+0x0/0x62 @ 1
[    1.255717] initcall init_devpts_fs+0x0/0x62 returned 0 after 40 usecs
[    1.255728] calling  init_ramfs_fs+0x0/0x12 @ 1
[    1.255738] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255747] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
[    1.255811] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 53 usecs
[    1.255819] calling  init_fat_fs+0x0/0x4f @ 1
[    1.255837] initcall init_fat_fs+0x0/0x4f returned 0 after 9 usecs
[    1.255845] calling  init_vfat_fs+0x0/0x12 @ 1
[    1.255854] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255862] calling  init_msdos_fs+0x0/0x12 @ 1
[    1.255870] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255878] calling  init_iso9660_fs+0x0/0x70 @ 1
[    1.255905] initcall init_iso9660_fs+0x0/0x70 returned 0 after 18 usecs
[    1.255913] calling  init_nfs_fs+0x0/0x16c @ 1
[    1.256045] initcall init_nfs_fs+0x0/0x16c returned 0 after 120 usecs
[    1.256077] calling  init_nfs_v2+0x0/0x14 @ 1
[    1.256086] initcall init_nfs_v2+0x0/0x14 returned 0 after 1 usecs
[    1.256093] calling  init_nfs_v3+0x0/0x14 @ 1
[    1.256101] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
[    1.256108] calling  init_nfs_v4+0x0/0x3b @ 1
[    1.256115] NFS: Registering the id_resolver key type
[    1.256134] Key type id_resolver registered
[    1.256140] Key type id_legacy registered
[    1.256151] initcall init_nfs_v4+0x0/0x3b returned 0 after 34 usecs
[    1.256159] calling  init_nlm+0x0/0x4c @ 1
[    1.256171] initcall init_nlm+0x0/0x4c returned 0 after 5 usecs
[    1.256179] calling  init_nls_cp437+0x0/0x12 @ 1
[    1.256187] initcall init_nls_cp437+0x0/0x12 returned 0 after 0 usecs
[    1.256194] calling  init_nls_ascii+0x0/0x12 @ 1
[    1.256202] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[    1.256209] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[    1.256217] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[    1.256225] calling  init_nls_utf8+0x0/0x2b @ 1
[    1.256233] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
[    1.256240] calling  init_ntfs_fs+0x0/0x1d1 @ 1
[    1.256246] NTFS driver 2.1.30 [Flags: R/W].
[    1.455160] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 194248 usecs
[    1.455177] calling  init_autofs4_fs+0x0/0x2a @ 1
[    1.455306] initcall init_autofs4_fs+0x0/0x2a returned 0 after 117 usecs
[    1.455315] calling  init_pstore_fs+0x0/0x12 @ 1
[    1.455324] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
[    1.455331] calling  ipc_init+0x0/0x2f @ 1
[    1.455345] msgmni has been set to 2923
[    1.455359] initcall ipc_init+0x0/0x2f returned 0 after 19 usecs
[    1.455367] calling  ipc_sysctl_init+0x0/0x14 @ 1
[    1.455381] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.455389] calling  init_mqueue_fs+0x0/0xa2 @ 1
[    1.455434] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 36 usecs
[    1.455442] calling  key_proc_init+0x0/0x5e @ 1
[    1.455456] initcall key_proc_init+0x0/0x5e returned 0 after 6 usecs
[    1.455464] calling  selinux_nf_ip_init+0x0/0x69 @ 1
[    1.455471] SELinux:  Registering netfilter hooks
[    1.455652] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 175 usecs
[    1.455661] calling  init_sel_fs+0x0/0xa5 @ 1
[    1.455945] initcall init_sel_fs+0x0/0xa5 returned 0 after 269 usecs
[    1.455954] calling  selnl_init+0x0/0x56 @ 1
[    1.455967] initcall selnl_init+0x0/0x56 returned 0 after 5 usecs
[    1.455975] calling  sel_netif_init+0x0/0x5c @ 1
[    1.455984] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
[    1.455992] calling  sel_netnode_init+0x0/0x6a @ 1
[    1.456001] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
[    1.456008] calling  sel_netport_init+0x0/0x6a @ 1
[    1.456017] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
[    1.456025] calling  aurule_init+0x0/0x2d @ 1
[    1.456033] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
[    1.456040] calling  crypto_wq_init+0x0/0x33 @ 1
[    1.456101] initcall crypto_wq_init+0x0/0x33 returned 0 after 51 usecs
[    1.456110] calling  crypto_algapi_init+0x0/0xd @ 1
[    1.456121] initcall crypto_algapi_init+0x0/0xd returned 0 after 3 usecs
[    1.456129] calling  skcipher_module_init+0x0/0x35 @ 1
[    1.456137] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
[    1.456145] calling  chainiv_module_init+0x0/0x12 @ 1
[    1.456153] initcall chainiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456161] calling  eseqiv_module_init+0x0/0x12 @ 1
[    1.456169] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456176] calling  hmac_module_init+0x0/0x12 @ 1
[    1.456184] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456192] calling  md5_mod_init+0x0/0x12 @ 1
[    1.456254] initcall md5_mod_init+0x0/0x12 returned 0 after 53 usecs
[    1.456263] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[    1.456315] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456324] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[    1.456332] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456340] calling  des_generic_mod_init+0x0/0x17 @ 1
[    1.456434] initcall des_generic_mod_init+0x0/0x17 returned 0 after 84 usecs
[    1.456442] calling  aes_init+0x0/0x12 @ 1
[    1.456493] initcall aes_init+0x0/0x12 returned 0 after 42 usecs
[    1.456501] calling  zlib_mod_init+0x0/0x12 @ 1
[    1.456551] initcall zlib_mod_init+0x0/0x12 returned 0 after 41 usecs
[    1.456559] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[    1.456567] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456575] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
[    1.456584] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456592] calling  lzo_mod_init+0x0/0x12 @ 1
[    1.456643] initcall lzo_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456651] calling  krng_mod_init+0x0/0x12 @ 1
[    1.456702] initcall krng_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456710] calling  proc_genhd_init+0x0/0x3c @ 1
[    1.456724] initcall proc_genhd_init+0x0/0x3c returned 0 after 6 usecs
[    1.456732] calling  bsg_init+0x0/0x12e @ 1
[    1.456803] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.456812] initcall bsg_init+0x0/0x12e returned 0 after 71 usecs
[    1.456820] calling  noop_init+0x0/0x12 @ 1
[    1.456827] io scheduler noop registered
[    1.456834] initcall noop_init+0x0/0x12 returned 0 after 7 usecs
[    1.456842] calling  deadline_init+0x0/0x12 @ 1
[    1.456849] io scheduler deadline registered
[    1.456856] initcall deadline_init+0x0/0x12 returned 0 after 6 usecs
[    1.456864] calling  cfq_init+0x0/0x8b @ 1
[    1.456878] io scheduler cfq registered (default)
[    1.456885] initcall cfq_init+0x0/0x8b returned 0 after 14 usecs
[    1.456893] calling  percpu_counter_startup+0x0/0x38 @ 1
[    1.456902] initcall percpu_counter_startup+0x0/0x38 returned 0 after 1 usecs
[    1.456910] calling  pci_proc_init+0x0/0x6a @ 1
[    1.654703] initcall pci_proc_init+0x0/0x6a returned 0 after 8 usecs
[    1.654716] calling  pcie_portdrv_init+0x0/0x7a @ 1
[    1.654876] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 148 usecs
[    1.654885] calling  aer_service_init+0x0/0x2b @ 1
[    1.654958] initcall aer_service_init+0x0/0x2b returned 0 after 63 usecs
[    1.654967] calling  pci_hotplug_init+0x0/0x1d @ 1
[    1.654974] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.654982] initcall pci_hotplug_init+0x0/0x1d returned 0 after 6 usecs
[    1.654990] calling  pcifront_init+0x0/0x3f @ 1
[    1.655085] initcall pcifront_init+0x0/0x3f returned 0 after 85 usecs
[    1.655094] calling  genericbl_driver_init+0x0/0x12 @ 1
[    1.655169] initcall genericbl_driver_init+0x0/0x12 returned 0 after 65 usecs
[    1.655178] calling  cirrusfb_init+0x0/0xcc @ 1
[    1.655265] initcall cirrusfb_init+0x0/0xcc returned 0 after 75 usecs
[    1.655277] calling  efifb_init+0x0/0x298 @ 1
[    1.655287] initcall efifb_init+0x0/0x298 returned -19 after 1 usecs
[    1.655297] calling  intel_idle_init+0x0/0x326 @ 1
[    1.655305] initcall intel_idle_init+0x0/0x326 returned -19 after 0 usecs
[    1.655313] calling  acpi_reserve_resources+0x0/0xeb @ 1
[    1.655322] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 usecs
[    1.655330] calling  irqrouter_init_ops+0x0/0x26 @ 1
[    1.655338] initcall irqrouter_init_ops+0x0/0x26 returned 0 after 0 usecs
[    1.655347] calling  acpi_ac_init+0x0/0x28 @ 1
[    1.655357] initcall acpi_ac_init+0x0/0x28 returned -19 after 0 usecs
[    1.655369] calling  acpi_button_driver_init+0x0/0x12 @ 1
[    1.655379] initcall acpi_button_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655390] calling  acpi_fan_driver_init+0x0/0x12 @ 1
[    1.655399] initcall acpi_fan_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655409] calling  acpi_processor_init+0x0/0x6d @ 1
[    1.655419] initcall acpi_processor_init+0x0/0x6d returned 0 after 0 usecs
[    1.655429] calling  acpi_container_init+0x0/0x4a @ 1
[    1.655439] initcall acpi_container_init+0x0/0x4a returned -19 after 0 usecs
[    1.655450] calling  acpi_thermal_init+0x0/0x42 @ 1
[    1.655458] initcall acpi_thermal_init+0x0/0x42 returned -19 after 0 usecs
[    1.655466] calling  acpi_battery_init+0x0/0x16 @ 1
[    1.655478] initcall acpi_battery_init+0x0/0x16 returned 0 after 3 usecs
[    1.655486] calling  acpi_hed_driver_init+0x0/0x12 @ 1
[    1.655494] initcall acpi_hed_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655502] calling  erst_init+0x0/0x2bb @ 1
[    1.655510] initcall erst_init+0x0/0x2bb returned 0 after 0 usecs
[    1.655518] calling  ghes_init+0x0/0x171 @ 1
[    1.655527] initcall ghes_init+0x0/0x171 returned -19 after 0 usecs
[    1.655535] calling  einj_init+0x0/0x49d @ 1
[    1.655543] initcall einj_init+0x0/0x49d returned -19 after 0 usecs
[    1.655551] calling  ioat_init_module+0x0/0x80 @ 1
[    1.655559] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    1.655595] calling  1_acpi_battery_init_async+0x0/0x1b @ 6
[    1.655603] initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 0 usecs
[    1.655672] initcall ioat_init_module+0x0/0x80 returned 0 after 109 usecs
[    1.655683] calling  virtio_mmio_init+0x0/0x12 @ 1
[    1.655766] initcall virtio_mmio_init+0x0/0x12 returned 0 after 72 usecs
[    1.655777] calling  init+0x0/0x12 @ 1
[    1.655855] initcall init+0x0/0x12 returned 0 after 67 usecs
[    1.655864] calling  xenbus_probe_initcall+0x0/0x39 @ 1
[    1.655873] initcall xenbus_probe_initcall+0x0/0x39 returned 0 after 0 usecs
[    1.655882] calling  xenbus_init+0x0/0x3d @ 1
[    1.655975] initcall xenbus_init+0x0/0x3d returned 0 after 81 usecs
[    1.655985] calling  xenbus_backend_init+0x0/0x51 @ 1
[    1.655993] initcall xenbus_backend_init+0x0/0x51 returned -19 after 0 usecs
[    1.656002] calling  gntdev_init+0x0/0x4d @ 1
[    1.656125] initcall gntdev_init+0x0/0x4d returned 0 after 111 usecs
[    1.656134] calling  gntalloc_init+0x0/0x3d @ 1
[    1.656209] initcall gntalloc_init+0x0/0x3d returned 0 after 66 usecs
[    1.656217] calling  hypervisor_subsys_init+0x0/0x25 @ 1
[    1.656225] initcall hypervisor_subsys_init+0x0/0x25 returned 0 after 0 usecs
[    1.656233] calling  hyper_sysfs_init+0x0/0xfb @ 1
[    1.656254] initcall hyper_sysfs_init+0x0/0xfb returned 0 after 13 usecs
[    1.656262] calling  platform_pci_module_init+0x0/0x1b @ 1
[    1.656336] initcall platform_pci_module_init+0x0/0x1b returned 0 after 64 usecs
[    1.656344] calling  xen_tmem_init+0x0/0x9a @ 1
[    1.656352] initcall xen_tmem_init+0x0/0x9a returned 0 after 0 usecs
[    1.656360] calling  xen_late_init_mcelog+0x0/0x3d @ 1
[    1.656367] initcall xen_late_init_mcelog+0x0/0x3d returned -19 after 0 usecs
[    1.656375] calling  xen_pcibk_init+0x0/0x13f @ 1
[    1.656383] initcall xen_pcibk_init+0x0/0x13f returned -19 after 0 usecs
[    1.854937] calling  xen_acpi_processor_init+0x0/0x41f @ 1
[    1.854949] initcall xen_acpi_processor_init+0x0/0x41f returned -19 after 0 usecs
[    1.854957] calling  pty_init+0x0/0x453 @ 1
[    1.890528] initcall pty_init+0x0/0x453 returned 0 after 34728 usecs
[    1.890543] calling  sysrq_init+0x0/0x78 @ 1
[    1.890557] initcall sysrq_init+0x0/0x78 returned 0 after 5 usecs
[    1.890564] calling  xen_hvc_init+0x0/0x249 @ 1
[    1.891318] initcall xen_hvc_init+0x0/0x249 returned 0 after 728 usecs
[    1.891328] calling  serial8250_init+0x0/0x17d @ 1
[    1.891335] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.891949] initcall serial8250_init+0x0/0x17d returned 0 after 598 usecs
[    1.891959] calling  serial_pci_driver_init+0x0/0x1b @ 1
[    1.892030] initcall serial_pci_driver_init+0x0/0x1b returned 0 after 62 usecs
[    1.892040] calling  init_kgdboc+0x0/0x16 @ 1
[    1.892048] initcall init_kgdboc+0x0/0x16 returned 0 after 0 usecs
[    1.892103] calling  rand_initialize+0x0/0x30 @ 1
[    1.892125] initcall rand_initialize+0x0/0x30 returned 0 after 10 usecs
[    1.892135] calling  init+0x0/0x111 @ 1
[    1.892349] initcall init+0x0/0x111 returned 0 after 201 usecs
[    1.892358] calling  hpet_init+0x0/0x6a @ 1
[    1.892517] initcall hpet_init+0x0/0x6a returned -19 after 147 usecs
[    1.892526] calling  nvram_init+0x0/0x82 @ 1
[    1.892602] Non-volatile memory driver v1.3
[    1.892610] initcall nvram_init+0x0/0x82 returned 0 after 74 usecs
[    1.892618] calling  mod_init+0x0/0x5a @ 1
[    1.892625] initcall mod_init+0x0/0x5a returned -19 after 0 usecs
[    1.892633] calling  rng_init+0x0/0x12 @ 1
[    1.892709] initcall rng_init+0x0/0x12 returned 0 after 66 usecs
[    1.892718] calling  agp_init+0x0/0x26 @ 1
[    1.892725] Linux agpgart interface v0.103
[    1.892732] initcall agp_init+0x0/0x26 returned 0 after 6 usecs
[    1.892739] calling  agp_amd64_mod_init+0x0/0x22 @ 1
[    1.892876] initcall agp_amd64_mod_init+0x0/0x22 returned -19 after 125 usecs
[    1.892885] calling  agp_intel_init+0x0/0x29 @ 1
[    1.892955] initcall agp_intel_init+0x0/0x29 returned 0 after 60 usecs
[    1.892964] calling  agp_sis_init+0x0/0x29 @ 1
[    1.893035] initcall agp_sis_init+0x0/0x29 returned 0 after 61 usecs
[    1.893043] calling  agp_via_init+0x0/0x29 @ 1
[    1.893136] initcall agp_via_init+0x0/0x29 returned 0 after 83 usecs
[    1.893144] calling  drm_core_init+0x0/0x139 @ 1
[    1.893223] [drm] Initialized drm 1.1.0 20060810
[    1.893231] initcall drm_core_init+0x0/0x139 returned 0 after 77 usecs
[    1.893239] calling  cn_proc_init+0x0/0x3d @ 1
[    1.893247] initcall cn_proc_init+0x0/0x3d returned 0 after 1 usecs
[    1.893256] calling  topology_sysfs_init+0x0/0x58 @ 1
[    1.893274] initcall topology_sysfs_init+0x0/0x58 returned 0 after 9 usecs
[    1.893282] calling  loop_init+0x0/0x137 @ 1
[    1.895048] loop: module loaded
[    1.895089] initcall loop_init+0x0/0x137 returned 0 after 1757 usecs
[    1.895098] calling  xen_blkif_init+0x0/0x25f @ 1
[    1.895308] initcall xen_blkif_init+0x0/0x25f returned 0 after 197 usecs
[    1.895316] calling  mac_hid_init+0x0/0x22 @ 1
[    1.895328] initcall mac_hid_init+0x0/0x22 returned 0 after 4 usecs
[    1.895336] calling  macvlan_init_module+0x0/0x3d @ 1
[    1.895345] initcall macvlan_init_module+0x0/0x3d returned 0 after 1 usecs
[    1.895353] calling  macvtap_init+0x0/0x100 @ 1
[    1.895419] initcall macvtap_init+0x0/0x100 returned 0 after 56 usecs
[    1.895427] calling  net_olddevs_init+0x0/0x86 @ 1
[    1.895436] initcall net_olddevs_init+0x0/0x86 returned 0 after 1 usecs
[    1.895444] calling  fixed_mdio_bus_init+0x0/0x105 @ 1
[    1.895589] libphy: Fixed MDIO Bus: probed
[    1.895597] initcall fixed_mdio_bus_init+0x0/0x105 returned 0 after 141 usecs
[    1.895605] calling  tun_init+0x0/0x93 @ 1
[    1.895612] tun: Universal TUN/TAP device driver, 1.6
[    1.895618] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.895698] initcall tun_init+0x0/0x93 returned 0 after 83 usecs
[    1.895706] calling  tg3_init+0x0/0x1b @ 1
[    1.895780] initcall tg3_init+0x0/0x1b returned 0 after 65 usecs
[    1.895788] calling  ixgbevf_init_module+0x0/0x4c @ 1
[    2.055322] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k
[    2.055332] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    2.055427] initcall ixgbevf_init_module+0x0/0x4c returned 0 after 101 usecs
[    2.055436] calling  init_nic+0x0/0x1b @ 1
[    2.055512] initcall init_nic+0x0/0x1b returned 0 after 66 usecs
[    2.055521] calling  netback_init+0x0/0x212 @ 1
[    2.055638] initcall netback_init+0x0/0x212 returned 0 after 106 usecs
[    2.055647] calling  nonstatic_sysfs_init+0x0/0x12 @ 1
[    2.055656] initcall nonstatic_sysfs_init+0x0/0x12 returned 0 after 1 usecs
[    2.055664] calling  yenta_socket_init+0x0/0x1b @ 1
[    2.055744] initcall yenta_socket_init+0x0/0x1b returned 0 after 70 usecs
[    2.055754] calling  mon_init+0x0/0xfe @ 1
[    2.055909] initcall mon_init+0x0/0xfe returned 0 after 144 usecs
[    2.055918] calling  ehci_hcd_init+0x0/0xb7 @ 1
[    2.055925] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.055933] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    2.055951] initcall ehci_hcd_init+0x0/0xb7 returned 0 after 24 usecs
[    2.055959] calling  ehci_pci_init+0x0/0x69 @ 1
[    2.055966] ehci-pci: EHCI PCI platform driver
[    2.056038] initcall ehci_pci_init+0x0/0x69 returned 0 after 68 usecs
[    2.056047] calling  ohci_hcd_mod_init+0x0/0xbf @ 1
[    2.056086] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.056094] ohci_hcd: block sizes: ed 80 td 96
[    2.056181] initcall ohci_hcd_mod_init+0x0/0xbf returned 0 after 92 usecs
[    2.056190] calling  uhci_hcd_init+0x0/0x129 @ 1
[    2.056197] uhci_hcd: USB Universal Host Controller Interface driver
[    2.056290] initcall uhci_hcd_init+0x0/0x129 returned 0 after 89 usecs
[    2.056299] calling  usblp_driver_init+0x0/0x1b @ 1
[    2.056375] usbcore: registered new interface driver usblp
[    2.056384] initcall usblp_driver_init+0x0/0x1b returned 0 after 75 usecs
[    2.056393] calling  kgdbdbgp_start_thread+0x0/0x4f @ 1
[    2.056401] initcall kgdbdbgp_start_thread+0x0/0x4f returned 0 after 0 usecs
[    2.056409] calling  i8042_init+0x0/0x3c5 @ 1
[    2.056657] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.068374] i8042: No controller found
[    3.068394] initcall i8042_init+0x0/0x3c5 returned -19 after 988256 usecs
[    3.068403] calling  serport_init+0x0/0x34 @ 1
[    3.068412] initcall serport_init+0x0/0x34 returned 0 after 1 usecs
[    3.068420] calling  mousedev_init+0x0/0x62 @ 1
[    3.068590] mousedev: PS/2 mouse device common for all mice
[    3.068600] initcall mousedev_init+0x0/0x62 returned 0 after 167 usecs
[    3.068608] calling  evdev_init+0x0/0x12 @ 1
[    3.068617] initcall evdev_init+0x0/0x12 returned 0 after 0 usecs
[    3.068625] calling  atkbd_init+0x0/0x27 @ 1
[    3.068713] initcall atkbd_init+0x0/0x27 returned 0 after 78 usecs
[    3.068724] calling  psmouse_init+0x0/0x7b @ 1
[    3.068871] initcall psmouse_init+0x0/0x7b returned 0 after 132 usecs
[    3.068888] calling  cmos_init+0x0/0x6a @ 1
[    3.129156] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    3.129267] rtc_cmos: probe of rtc_cmos failed with error -38
[    3.129462] initcall cmos_init+0x0/0x6a returned -19 after 59144 usecs
[    3.129471] calling  i2c_i801_init+0x0/0xad @ 1
[    3.129552] initcall i2c_i801_init+0x0/0xad returned 0 after 70 usecs
[    3.129562] calling  cpufreq_gov_dbs_init+0x0/0x95 @ 1
[    3.129571] initcall cpufreq_gov_dbs_init+0x0/0x95 returned -19 after 1 usecs
[    3.129580] calling  init_ladder+0x0/0x12 @ 1
[    3.129588] initcall init_ladder+0x0/0x12 returned -19 after 0 usecs
[    3.129596] calling  init_menu+0x0/0x12 @ 1
[    3.129603] initcall init_menu+0x0/0x12 returned -19 after 0 usecs
[    3.129612] calling  efivars_init+0x0/0x105 @ 1
[    3.129619] EFI Variables Facility v0.08 2004-May-17
[    3.129626] initcall efivars_init+0x0/0x105 returned 0 after 6 usecs
[    3.129635] calling  vhost_net_init+0x0/0x30 @ 1
[    3.129714] initcall vhost_net_init+0x0/0x30 returned 0 after 68 usecs
[    3.129723] calling  staging_init+0x0/0x8 @ 1
[    3.129731] initcall staging_init+0x0/0x8 returned 0 after 0 usecs
[    3.129739] calling  zram_init+0x0/0x2e4 @ 1
[    3.129746] zram: num_devices not specified. Using default: 1
[    3.129753] zram: Creating 1 devices ...
[    3.130028] initcall zram_init+0x0/0x2e4 returned 0 after 273 usecs
[    3.130038] calling  zcache_init+0x0/0x297 @ 1
[    3.130115] initcall zcache_init+0x0/0x297 returned 0 after 67 usecs
[    3.130127] calling  zs_init+0x0/0x90 @ 1
[    3.130139] initcall zs_init+0x0/0x90 returned 0 after 3 usecs
[    3.130149] calling  eeepc_laptop_init+0x0/0x58 @ 1
[    3.130320] initcall eeepc_laptop_init+0x0/0x58 returned -19 after 157 usecs
[    3.130331] calling  sock_diag_init+0x0/0x12 @ 1
[    3.130347] initcall sock_diag_init+0x0/0x12 returned 0 after 8 usecs
[    3.130355] calling  flow_cache_init_global+0x0/0x19f @ 1
[    3.130373] initcall flow_cache_init_global+0x0/0x19f returned 0 after 10 usecs
[    3.130382] calling  llc_init+0x0/0x20 @ 1
[    3.130390] initcall llc_init+0x0/0x20 returned 0 after 1 usecs
[    3.130397] calling  snap_init+0x0/0x38 @ 1
[    3.130408] initcall snap_init+0x0/0x38 returned 0 after 1 usecs
[    3.130417] calling  blackhole_module_init+0x0/0x12 @ 1
[    3.130427] initcall blackhole_module_init+0x0/0x12 returned 0 after 0 usecs
[    3.130436] calling  nfnetlink_init+0x0/0x27 @ 1
[    3.130444] Netfilter messages via NETLINK v0.30.
[    3.130464] initcall nfnetlink_init+0x0/0x27 returned 0 after 18 usecs
[    3.130474] calling  nfnetlink_log_init+0x0/0xdb @ 1
[    3.130491] initcall nfnetlink_log_init+0x0/0xdb returned 0 after 9 usecs
[    3.130499] calling  nf_conntrack_standalone_init+0x0/0x12 @ 1
[    3.130507] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    3.130600] initcall nf_conntrack_standalone_init+0x0/0x12 returned 0 after 90 usecs
[    3.130609] calling  ctnetlink_init+0x0/0xa4 @ 1
[    3.130616] ctnetlink v0.93: registering with nfnetlink.
[    3.130623] initcall ctnetlink_init+0x0/0xa4 returned 0 after 6 usecs
[    3.130631] calling  nf_conntrack_ftp_init+0x0/0x1ca @ 1
[    3.130639] initcall nf_conntrack_ftp_init+0x0/0x1ca returned 0 after 0 usecs
[    3.130647] calling  nf_conntrack_irc_init+0x0/0x173 @ 1
[    3.130658] initcall nf_conntrack_irc_init+0x0/0x173 returned 0 after 3 usecs
[    3.130666] calling  nf_conntrack_sip_init+0x0/0x215 @ 1
[    3.130675] initcall nf_conntrack_sip_init+0x0/0x215 returned 0 after 0 usecs
[    3.130683] calling  xt_init+0x0/0x118 @ 1
[    3.130693] initcall xt_init+0x0/0x118 returned 0 after 1 usecs
[    3.130701] calling  tcpudp_mt_init+0x0/0x17 @ 1
[    3.130709] initcall tcpudp_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.130717] calling  connsecmark_tg_init+0x0/0x12 @ 1
[    3.268638] initcall connsecmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268647] calling  nflog_tg_init+0x0/0x12 @ 1
[    3.268656] initcall nflog_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268664] calling  secmark_tg_init+0x0/0x12 @ 1
[    3.268671] initcall secmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268679] calling  tcpmss_tg_init+0x0/0x17 @ 1
[    3.268687] initcall tcpmss_tg_init+0x0/0x17 returned 0 after 0 usecs
[    3.268696] calling  conntrack_mt_init+0x0/0x17 @ 1
[    3.268707] initcall conntrack_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.268715] calling  policy_mt_init+0x0/0x17 @ 1
[    3.268723] initcall policy_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.268730] calling  state_mt_init+0x0/0x12 @ 1
[    3.268738] initcall state_mt_init+0x0/0x12 returned 0 after 0 usecs
[    3.268746] calling  sysctl_ipv4_init+0x0/0x92 @ 1
[    3.268793] initcall sysctl_ipv4_init+0x0/0x92 returned 0 after 37 usecs
[    3.268804] calling  init_syncookies+0x0/0x19 @ 1
[    3.268835] initcall init_syncookies+0x0/0x19 returned 0 after 21 usecs
[    3.268845] calling  tunnel4_init+0x0/0x72 @ 1
[    3.268854] initcall tunnel4_init+0x0/0x72 returned 0 after 0 usecs
[    3.268865] calling  ipv4_netfilter_init+0x0/0x12 @ 1
[    3.268876] initcall ipv4_netfilter_init+0x0/0x12 returned 0 after 0 usecs
[    3.268886] calling  nf_conntrack_l3proto_ipv4_init+0x0/0xb8 @ 1
[    3.269010] initcall nf_conntrack_l3proto_ipv4_init+0x0/0xb8 returned 0 after 110 usecs
[    3.269021] calling  nf_defrag_init+0x0/0x17 @ 1
[    3.269029] initcall nf_defrag_init+0x0/0x17 returned 0 after 0 usecs
[    3.269037] calling  ip_tables_init+0x0/0xaa @ 1
[    3.269064] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.269072] initcall ip_tables_init+0x0/0xaa returned 0 after 26 usecs
[    3.269083] calling  iptable_filter_init+0x0/0x51 @ 1
[    3.269107] initcall iptable_filter_init+0x0/0x51 returned 0 after 13 usecs
[    3.269118] calling  iptable_mangle_init+0x0/0x51 @ 1
[    3.269139] initcall iptable_mangle_init+0x0/0x51 returned 0 after 10 usecs
[    3.269150] calling  reject_tg_init+0x0/0x12 @ 1
[    3.269159] initcall reject_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.269169] calling  ulog_tg_init+0x0/0x104 @ 1
[    3.269184] initcall ulog_tg_init+0x0/0x104 returned 0 after 5 usecs
[    3.269195] calling  cubictcp_register+0x0/0x5c @ 1
[    3.269204] TCP: cubic registered
[    3.269213] initcall cubictcp_register+0x0/0x5c returned 0 after 9 usecs
[    3.269221] calling  xfrm_user_init+0x0/0x4a @ 1
[    3.269230] Initializing XFRM netlink socket
[    3.269244] initcall xfrm_user_init+0x0/0x4a returned 0 after 12 usecs
[    3.269255] calling  inet6_init+0x0/0x315 @ 1
[    3.269288] NET: Registered protocol family 10
[    3.269523] initcall inet6_init+0x0/0x315 returned 0 after 252 usecs
[    3.269532] calling  ah6_init+0x0/0x79 @ 1
[    3.269539] initcall ah6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269547] calling  esp6_init+0x0/0x79 @ 1
[    3.269555] initcall esp6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269563] calling  xfrm6_transport_init+0x0/0x17 @ 1
[    3.269571] initcall xfrm6_transport_init+0x0/0x17 returned 0 after 0 usecs
[    3.269579] calling  xfrm6_mode_tunnel_init+0x0/0x17 @ 1
[    3.269587] initcall xfrm6_mode_tunnel_init+0x0/0x17 returned 0 after 0 usecs
[    3.269595] calling  xfrm6_beet_init+0x0/0x17 @ 1
[    3.269602] initcall xfrm6_beet_init+0x0/0x17 returned 0 after 0 usecs
[    3.269610] calling  ip6_tables_init+0x0/0xaa @ 1
[    3.269627] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    3.269635] initcall ip6_tables_init+0x0/0xaa returned 0 after 16 usecs
[    3.269643] calling  ip6table_filter_init+0x0/0x51 @ 1
[    3.269764] initcall ip6table_filter_init+0x0/0x51 returned 0 after 110 usecs
[    3.269773] calling  ip6table_mangle_init+0x0/0x51 @ 1
[    3.269822] initcall ip6table_mangle_init+0x0/0x51 returned 0 after 40 usecs
[    3.269831] calling  nf_conntrack_l3proto_ipv6_init+0x0/0x8a @ 1
[    3.269846] initcall nf_conntrack_l3proto_ipv6_init+0x0/0x8a returned 0 after 6 usecs
[    3.269855] calling  nf_defrag_init+0x0/0x54 @ 1
[    3.269868] initcall nf_defrag_init+0x0/0x54 returned 0 after 5 usecs
[    3.269876] calling  ipv6header_mt6_init+0x0/0x12 @ 1
[    3.269884] initcall ipv6header_mt6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269892] calling  reject_tg6_init+0x0/0x12 @ 1
[    3.269900] initcall reject_tg6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269908] calling  sit_init+0x0/0x8c @ 1
[    3.269914] sit: IPv6 over IPv4 tunneling driver
[    3.270252] initcall sit_init+0x0/0x8c returned 0 after 329 usecs
[    3.270261] calling  packet_init+0x0/0x47 @ 1
[    3.270268] NET: Registered protocol family 17
[    3.270280] initcall packet_init+0x0/0x47 returned 0 after 11 usecs
[    3.468657] calling  br_init+0x0/0xa2 @ 1
[    3.468683] initcall br_init+0x0/0xa2 returned 0 after 16 usecs
[    3.468691] calling  init_rpcsec_gss+0x0/0x64 @ 1
[    3.468734] initcall init_rpcsec_gss+0x0/0x64 returned 0 after 32 usecs
[    3.468745] calling  dcbnl_init+0x0/0x4d @ 1
[    3.468756] initcall dcbnl_init+0x0/0x4d returned 0 after 0 usecs
[    3.468765] calling  init_dns_resolver+0x0/0xe4 @ 1
[    3.468790] Key type dns_resolver registered
[    3.468801] initcall init_dns_resolver+0x0/0xe4 returned 0 after 23 usecs
[    3.468812] calling  mcheck_init_device+0x0/0x123 @ 1
[    3.468822] initcall mcheck_init_device+0x0/0x123 returned -5 after 0 usecs
[    3.468833] initcall mcheck_init_device+0x0/0x123 returned with error code -5 
[    3.468865] calling  tboot_late_init+0x0/0x216 @ 1
[    3.468875] initcall tboot_late_init+0x0/0x216 returned 0 after 0 usecs
[    3.468885] calling  mcheck_debugfs_init+0x0/0x3c @ 1
[    3.468915] initcall mcheck_debugfs_init+0x0/0x3c returned 0 after 19 usecs
[    3.468923] calling  severities_debugfs_init+0x0/0x3c @ 1
[    3.468942] initcall severities_debugfs_init+0x0/0x3c returned 0 after 7 usecs
[    3.468954] calling  threshold_init_device+0x0/0x8d @ 1
[    3.468964] initcall threshold_init_device+0x0/0x8d returned 0 after 0 usecs
[    3.468975] calling  hpet_insert_resource+0x0/0x23 @ 1
[    3.468985] initcall hpet_insert_resource+0x0/0x23 returned 1 after 0 usecs
[    3.468995] initcall hpet_insert_resource+0x0/0x23 returned with error code 1 
[    3.469007] calling  update_mp_table+0x0/0x56d @ 1
[    3.469018] initcall update_mp_table+0x0/0x56d returned 0 after 0 usecs
[    3.469028] calling  lapic_insert_resource+0x0/0x3f @ 1
[    3.469037] initcall lapic_insert_resource+0x0/0x3f returned -1 after 0 usecs
[    3.469047] initcall lapic_insert_resource+0x0/0x3f returned with error code -1 
[    3.469072] calling  io_apic_bug_finalize+0x0/0x1b @ 1
[    3.469083] initcall io_apic_bug_finalize+0x0/0x1b returned 0 after 0 usecs
[    3.469092] calling  print_ICs+0x0/0x508 @ 1
[    3.469102] initcall print_ICs+0x0/0x508 returned 0 after 0 usecs
[    3.469112] calling  check_early_ioremap_leak+0x0/0x65 @ 1
[    3.469122] initcall check_early_ioremap_leak+0x0/0x65 returned 0 after 0 usecs
[    3.469133] calling  pat_memtype_list_init+0x0/0x32 @ 1
[    3.469156] initcall pat_memtype_list_init+0x0/0x32 returned 0 after 13 usecs
[    3.469169] calling  init_oops_id+0x0/0x40 @ 1
[    3.469189] initcall init_oops_id+0x0/0x40 returned 0 after 4 usecs
[    3.469199] calling  printk_late_init+0x0/0x59 @ 1
[    3.469211] initcall printk_late_init+0x0/0x59 returned 0 after 1 usecs
[    3.469220] calling  pm_qos_power_init+0x0/0x7b @ 1
[    3.469460] initcall pm_qos_power_init+0x0/0x7b returned 0 after 223 usecs
[    3.469469] calling  pm_debugfs_init+0x0/0x24 @ 1
[    3.469483] initcall pm_debugfs_init+0x0/0x24 returned 0 after 6 usecs
[    3.469492] calling  software_resume+0x0/0x290 @ 1
[    3.469499] PM: Hibernation image not present or could not be loaded.
[    3.469507] initcall software_resume+0x0/0x290 returned -2 after 7 usecs
[    3.469515] initcall software_resume+0x0/0x290 returned with error code -2 
[    3.469524] calling  debugfs_kprobe_init+0x0/0x90 @ 1
[    3.469551] initcall debugfs_kprobe_init+0x0/0x90 returned 0 after 19 usecs
[    3.469559] calling  taskstats_init+0x0/0x95 @ 1
[    3.469570] registered taskstats version 1
[    3.469577] initcall taskstats_init+0x0/0x95 returned 0 after 10 usecs
[    3.469585] calling  clear_boot_tracer+0x0/0x2d @ 1
[    3.469593] initcall clear_boot_tracer+0x0/0x2d returned 0 after 0 usecs
[    3.469601] calling  max_swapfiles_check+0x0/0x8 @ 1
[    3.469608] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs
[    3.469617] calling  set_recommended_min_free_kbytes+0x0/0xa0 @ 1
[    3.469625] initcall set_recommended_min_free_kbytes+0x0/0xa0 returned 0 after 0 usecs
[    3.469634] calling  fail_make_request_debugfs+0x0/0x2a @ 1
[    3.469692] initcall fail_make_request_debugfs+0x0/0x2a returned 0 after 49 usecs
[    3.469701] calling  prandom_reseed+0x0/0xb4 @ 1
[    3.469722] initcall prandom_reseed+0x0/0xb4 returned 0 after 13 usecs
[    3.469730] calling  pci_resource_alignment_sysfs_init+0x0/0x19 @ 1
[    3.469740] initcall pci_resource_alignment_sysfs_init+0x0/0x19 returned 0 after 1 usecs
[    3.469748] calling  pci_sysfs_init+0x0/0x51 @ 1
[    3.469757] initcall pci_sysfs_init+0x0/0x51 returned 0 after 1 usecs
[    3.469765] calling  boot_wait_for_devices+0x0/0x30 @ 1
[    3.669552] XENBUS: Device with no driver: device/vif/0
[    3.669562] initcall boot_wait_for_devices+0x0/0x30 returned 0 after 12 usecs
[    3.669575] calling  random_int_secret_init+0x0/0x19 @ 1
[    3.669594] initcall random_int_secret_init+0x0/0x19 returned 0 after 10 usecs
[    3.669604] calling  deferred_probe_initcall+0x0/0x60 @ 1
[    3.669664] initcall deferred_probe_initcall+0x0/0x60 returned 0 after 50 usecs
[    3.669681] calling  late_resume_init+0x0/0x1d0 @ 1
[    3.669690]   Magic number: 1:252:3141
[    3.669768] initcall late_resume_init+0x0/0x1d0 returned 0 after 75 usecs
[    3.669778] calling  firmware_memmap_init+0x0/0x38 @ 1
[    3.669805] initcall firmware_memmap_init+0x0/0x38 returned 0 after 18 usecs
[    3.669815] calling  pci_mmcfg_late_insert_resources+0x0/0x50 @ 1
[    3.669824] initcall pci_mmcfg_late_insert_resources+0x0/0x50 returned 0 after 0 usecs
[    3.669835] calling  net_secret_init+0x0/0x19 @ 1
[    3.669857] initcall net_secret_init+0x0/0x19 returned 0 after 11 usecs
[    3.669866] calling  tcp_congestion_default+0x0/0x12 @ 1
[    3.669878] initcall tcp_congestion_default+0x0/0x12 returned 0 after 1 usecs
[    3.669889] calling  tcp_fastopen_init+0x0/0x30 @ 1
[    3.669910] initcall tcp_fastopen_init+0x0/0x30 returned 0 after 11 usecs
[    3.669921] calling  ip_auto_config+0x0/0xe62 @ 1
[    3.669937] initcall ip_auto_config+0x0/0xe62 returned 0 after 5 usecs
[    3.669947] calling  initialize_hashrnd+0x0/0x19 @ 1
[    3.669961] initcall initialize_hashrnd+0x0/0x19 returned 0 after 4 usecs
[    3.670862] Freeing unused kernel memory: 756k freed
[    3.671087] Write protecting the kernel read-only data: 10240k
[    3.677203] Freeing unused kernel memory: 1620k freed
[    3.677696] Freeing unused kernel memory: 136k freed
init started: BusyBox v1.14.3 (2013-01-15 17:27:03 EST)
[    3.683393] consoletype (1029) used greatest stack depth: 5288 bytes left
Mounting directories  [  OK  ]
mount: mount point /proc/bus/usb does not exist
[    3.991865] calling  privcmd_init+0x0/0x1000 [xen_privcmd] @ 1058
[    3.991978] initcall privcmd_init+0x0/0x1000 [xen_privcmd] returned 0 after 93 usecs
[    3.992361] calling  xenfs_init+0x0/0x1000 [xenfs] @ 1058
[    3.992373] initcall xenfs_init+0x0/0x1000 [xenfs] returned 0 after 1 usecs
[    3.992538] modprobe (1058) used greatest stack depth: 5272 bytes left
mount: mount point /sys/kernel/config does not exist
[    4.003403] core_filesystem (1030) used greatest stack depth: 4984 bytes left
[    4.012398] calling  xenkbd_init+0x0/0x1000 [xen_kbdfront] @ 1069
[    4.012500] initcall xenkbd_init+0x0/0x1000 [xen_kbdfront] returned 0 after 84 usecs
[    4.015993] calling  xenfb_init+0x0/0x1000 [xen_fbfront] @ 1072
[    4.016125] initcall xenfb_init+0x0/0x1000 [xen_fbfront] returned 0 after 113 usecs
[    4.019032] calling  netif_init+0x0/0x1000 [xen_netfront] @ 1079
[    4.019044] Initialising Xen virtual ethernet driver.
[    4.119124] initcall netif_init+0x0/0x1000 [xen_netfront] returned 0 after 97731 usecs
[    4.121939] calling  xlblk_init+0x0/0x1000 [xen_blkfront] @ 1085
[    4.122045] initcall xlblk_init+0x0/0x1000 [xen_blkfront] returned 0 after 87 usecs
[    4.136417] udevd (1091): /proc/1091/oom_adj is deprecated, please use /proc/1091/oom_score_adj instead.
udevd-work[1093]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory

[    4.190158] calling  crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] @ 1112
[    4.190457] initcall crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] returned 0 after 273 usecs
[    4.294865] ip (1240) used greatest stack depth: 3896 bytes left
Waiting for devices [  OK  ]
Waiting for fb [  OK  ]
Starting..[/dev/fb0]
Could not open; err: 2
FATAL: Module agpgart_intel not found.
[    4.617936] calling  drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] @ 1861
[    4.618103] initcall drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] returned 0 after 143 usecs
[    4.622178] calling  ttm_init+0x0/0x1000 [ttm] @ 1861
[    4.622835] initcall ttm_init+0x0/0x1000 [ttm] returned 0 after 623 usecs
[    4.638477] calling  radeon_init+0x0/0x1000 [radeon] @ 1861
[    4.638494] [drm] radeon kernel modesetting enabled.
[    4.639366] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 831 usecs
[    4.644900] calling  acpi_wmi_init+0x0/0x1000 [wmi] @ 1872
[    4.644911] initcall acpi_wmi_init+0x0/0x1000 [wmi] returned -19 after 0 usecs
[    4.645279] calling  fb_console_init+0x0/0x1000 [fbcon] @ 1863
WARNING: Error inserting video (/lib/modules/3.8.0-rc2upstream/kernel/drivers/acpi/video.ko): No such device
WARNING: Error inserting mxm_wmi (/lib/modules/3.8.0-rc2upstream/kernel/drivers/platform/x86/mxm-wmi.ko): No such device
WARNING: Error inserting drm_kms_helper (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
WARNING: Error inserting ttm (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device
FATAL: Error inserting nouveau (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device
[    4.648295] initcall fb_console_init+0x0/0x1000 [fbcon] returned 0 after 2934 usecs
[    4.648680] calling  acpi_video_init+0x0/0xfee [video] @ 1877
[    4.648692] initcall acpi_video_init+0x0/0xfee [video] returned -19 after 1 usecs
WARNING: Error inserting drm_kms_helper (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
FATAL: Error inserting i915 (/lib/modules/3.8.0-rc2upstream/kernel/drivers/gpu/drm/i915/i915.ko): No such device
Starting..[/dev/fb0]
Could not open; err: 2
VGA: 0000:
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  [    4.919737] device eth0 entered promiscuous mode
[  OK  ]
Bringing up interface switch:  
Determining IP information for switch...[    4.973883] switch: port 1(eth0) entered forwarding state
[    4.973901] switch: port 1(eth0) entered forwarding state
 done.
[  OK  ]
Waiting for init.custom [  OK  ]

Starting SSHd ...

    SSH started [2158]


Waiting for SSHd [  OK  ]
WARNING: ssh currently running [2158] ignoring start request
FATAL: Module dump_dma not found.
ERROR: Module dump_dma does not exist in /proc/modules
[    7.304760] calling  crc32c_mod_init+0x0/0x1000 [crc32c] @ 2192
[    7.304839] initcall crc32c_mod_init+0x0/0x1000 [crc32c] returned 0 after 60 usecs
[    7.307385] calling  libcrc32c_mod_init+0x0/0x1000 [libcrc32c] @ 2195
[    7.307403] initcall libcrc32c_mod_init+0x0/0x1000 [libcrc32c] returned 0 after 2 usecs
[    7.313643] calling  init_scsi+0x0/0x91 [scsi_mod] @ 2197
[    7.314342] SCSI subsystem initialized
[    7.314356] initcall init_scsi+0x0/0x91 [scsi_mod] returned 0 after 679 usecs
[    7.316111] calling  iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] @ 2197
[    7.316129] Loading iSCSI transport class v2.0-870.
[    7.317289] initcall iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] returned 0 after 1129 usecs
[    7.319114] calling  iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] @ 2197
[    7.319320] iscsi: registered transport (tcp)
[    7.319329] initcall iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] returned 0 after 198 usecs
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get list of targets from firmware.
Feb 22 21:46:33 g-pvops syslogd 1.5.0: restart.
Running in PV context on Xen v4.2.
FATAL: Module evtchn not found.
[    7.371756] calling  evtchn_init+0x0/0x1000 [xen_evtchn] @ 2237
[    7.372190] Event-channel device installed.
[    7.372199] initcall evtchn_init+0x0/0x1000 [xen_evtchn] returned 0 after 420 usecs
           CPU0       
 16:       2640  xen-percpu-virq      timer0
 17:          0  xen-percpu-ipi       spinlock0
 18:         29  xen-percpu-ipi       resched0
 19:          3  xen-percpu-ipi       callfunc0
 20:          0  xen-percpu-virq      debug0
 21:          1  xen-percpu-ipi       callfuncsingle0
 22:          0  xen-percpu-ipi       irqwork0
 23:         85   xen-dyn-event     hvc_console
 24:         20   xen-dyn-event     eth0
 37:        139   xen-dyn-event     xenbus
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
IWI:          0   IRQ work interrupts
RTR:          0   APIC ICR read retries
RES:         29   Rescheduling interrupts
CAL:          4   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:          0   Machine check polls
ERR:          0
MIS:          0
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-5ddfffff : System RAM
  01000000-01668597 : Kernel code
  01668598-01aa69ff : Kernel data
  01b6c000-01c6efff : Kernel bss
MemTotal:        1499108 kB
MemFree:         1111008 kB
Buffers:               0 kB
Cached:           353132 kB
SwapCached:            0 kB
Active:            21064 kB
Inactive:         331820 kB
Active(anon):      15064 kB
Inactive(anon):   160104 kB
Active(file):       6000 kB
Inactive(file):   171716 kB
Unevictable:        4928 kB
Mlocked:            4928 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          4748 kB
Mapped:             5124 kB
Shmem:            171788 kB
Slab:              18968 kB
SReclaimable:      11300 kB
SUnreclaim:         7668 kB
KernelStack:         464 kB
PageTables:          736 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      749552 kB
Committed_AS:     180652 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        3924 kB
VmallocChunk:   34359734387 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1538048 kB
DirectMap2M:           0 kB
Waiting for init.late [  OK  ]
PING build.dumpdata.com (192.168.101.3) 56(84) bytes of data.

--- build.dumpdata.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 0.310/0.310/0.310/0.000 ms
[    7.471343] mount.nfs (2258) used greatest stack depth: 3480 bytes left
NFS done
 [0x0->0x5de00] pfn
 [0x0->0x5de00] level entry
 [0x5de00->0x80000] level middle
 [0x5de00->0x7cfffff] missing
 [0x80000->0x7cfffff] level top
libxl: error: libxl.c:87:libxl_ctx_alloc: Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
cannot init xl context
[    8.469522] calling  dm_init+0x0/0x48 [dm_mod] @ 2272
[    8.470002] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[    8.470021] initcall dm_init+0x0/0x48 [dm_mod] returned 0 after 467 usecs
[    8.471073] calling  dm_multipath_init+0x0/0x1000 [dm_multipath] @ 2272
[    8.471163] device-mapper: multipath: version 1.5.0 loaded
[    8.471175] initcall dm_multipath_init+0x0/0x1000 [dm_multipath] returned 0 after 83 usecs
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260]
[    8.734032] scsi0 : iSCSI Initiator over TCP/IP
[    8.991392] scsi 0:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[    8.995124] calling  init_sd+0x0/0x1000 [sd_mod] @ 2290
[    8.995995] initcall init_sd+0x0/0x1000 [sd_mod] returned 0 after 833 usecs
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] successful.
[    8.999267] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    8.999841] sd 0:0:0:0: [sda] Write Protect is off
[    8.999852] sd 0:0:0:0: [sda] Mode Sense: 2f 00 00 00
[    9.000230] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    9.003886]  sda: unknown partition table
[    9.005627] sd 0:0:0:0: [sda] Attached SCSI disk
[    9.008859] calling  init_sg+0x0/0x1000 [sg] @ 2303
[    9.009224] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    9.009265] initcall init_sg+0x0/0x1000 [sg] returned 0 after 380 usecs
Feb 22 21:46:35 g-pvops iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] through [iface: default] is operational now
  PV /dev/sda   VG guests   lvm2 [931.51 GiB / 176.51 GiB free]
  Total: 1 [931.51 GiB] / in use: 1 [931.51 GiB] / in no VG: 0 [0   ]
[   14.059832] bio: create slab <bio-1> at 1
  26 logical volume(s) in volume group "guests" now active
22 Feb 21:46:44 ntpdate[2421]: step time server 17.171.4.34 offset 0.785497 sec
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Fri Feb 22 21:46:44 UTC 2013
Feb 22 21:46:44 g-pvops init: starting pid 2437, tty '/dev/tty0': '/bin/sh'
Feb 22 21:46:44 g-pvops init: starting pid 2438, tty '/dev/tty1': '/bin/sh'
Feb 22 21:46:44 g-pvops init: starting pid 2439, tty '/dev/ttyS0': '/bin/sh'


BusyBox v1.14.3 (2013-01-15 17:27:03 EST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# Feb 22 21:46:44 g-pvops init: starting pid 2440, tty '/dev/hvc0': '/bin/sh'
Feb 22 21:46:45 g-pvops init: process '/bin/sh' (pid 2439) exited. Scheduling for restart.
Feb 22 21:46:45 g-pvops init: starting pid 2441, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:46 g-pvops init: process '/bin/sh' (pid 2441) exited. Scheduling for restart.
Feb 22 21:46:46 g-pvops init: starting pid 2442, tty '/dev/ttyS0': '/bin/sh'
[   20.000116] switch: port 1(eth0) entered forwarding state
Feb 22 21:46:47 g-pvops init: process '/bin/sh' (pid 2442) exited. Scheduling for restart.
Feb 22 21:46:47 g-pvops init: starting pid 2443, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:48 g-pvops init: process '/bin/sh' (pid 2443) exited. Scheduling for restart.
Feb 22 21:46:48 g-pvops init: starting pid 2444, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:49 g-pvops init: process '/bin/sh' (pid 2444) exited. Scheduling for restart.
Feb 22 21:46:49 g-pvops init: starting pid 2445, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:50 g-pvops init: process '/bin/sh' (pid 2445) exited. Scheduling for restart.
Feb 22 21:46:50 g-pvops init: starting pid 2446, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:51 g-pvops init: process '/bin/sh' (pid 2446) exited. Scheduling for restart.
Feb 22 21:46:51 g-pvops init: starting pid 2447, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:52 g-pvops init: process '/bin/sh' (pid 2447) exited. Scheduling for restart.
Feb 22 21:46:52 g-pvops init: starting pid 2448, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:53 g-pvops init: process '/bin/sh' (pid 2448) exited. Scheduling for restart.
Feb 22 21:46:53 g-pvops init: starting pid 2449, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:54 g-pvops init: process '/bin/sh' (pid 2449) exited. Scheduling for restart.
Feb 22 21:46:54 g-pvops init: starting pid 2450, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:55 g-pvops init: process '/bin/sh' (pid 2450) exited. Scheduling for restart.
Feb 22 21:46:55 g-pvops init: starting pid 2451, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:56 g-pvops init: process '/bin/sh' (pid 2451) exited. Scheduling for restart.
Feb 22 21:46:56 g-pvops init: starting pid 2452, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:57 g-pvops init: process '/bin/sh' (pid 2452) exited. Scheduling for restart.
Feb 22 21:46:57 g-pvops init: starting pid 2453, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:58 g-pvops init: process '/bin/sh' (pid 2453) exited. Scheduling for restart.
Feb 22 21:46:58 g-pvops init: starting pid 2454, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:46:59 g-pvops init: process '/bin/sh' (pid 2454) exited. Scheduling for restart.
Feb 22 21:46:59 g-pvops init: starting pid 2455, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:00 g-pvops init: process '/bin/sh' (pid 2455) exited. Scheduling for restart.
Feb 22 21:47:00 g-pvops init: starting pid 2456, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:01 g-pvops init: process '/bin/sh' (pid 2456) exited. Scheduling for restart.
Feb 22 21:47:01 g-pvops init: starting pid 2457, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:02 g-pvops init: process '/bin/sh' (pid 2457) exited. Scheduling for restart.
Feb 22 21:47:02 g-pvops init: starting pid 2458, tty '/dev/ttyS0': '/bin/sh'
Feb 22 21:47:03 g-pvops init: process '/bin/sh' (pid 2458) exited. Scheduling for restart.
Feb 22 21:47:03 g-pvops init: starting pid 2459, tty '/dev/ttyS0': '/bin/sh'
kill -Feb 22 21:47:04 g-pvops init: process '/bin/sh' (pid 2459) exited. Scheduling for restart.
Feb 22 21:47:04 g-pvops init: starting pid 2460, tty '/dev/ttyS0': '/bin/sh'
1 1
# Feb 22 21:47:05 g-pvops init: reloading /etc/inittab
dmesg
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0-rc2upstream (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 16:38:14 EST 2013
[    0.000000] Command line: console=hvc0 debug earlyprintk=xen memblock=debug loglevel=8 initcall_debug
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000005ddfffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x5de00 max_arch_pfn = 0x400000000
[    0.000000] memblock_reserve: [0x00000001c6f000-0x00000001c7e000] setup_arch+0x5e5/0xbc6
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x5dd90000 reserved size = 0x15b87000
[    0.000000]  memory.cnt  = 0x2
[    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009ffff], 0x90000 bytes
[    0.000000]  memory[0x1]	[0x00000000100000-0x0000005ddfffff], 0x5dd00000 bytes
[    0.000000]  reserved.cnt  = 0x3
[    0.000000]  reserved[0x0]	[0x00000001000000-0x00000001c7dfff], 0xc7e000 bytes
[    0.000000]  reserved[0x1]	[0x0000000208c000-0x00000016edafff], 0x14e4f000 bytes
[    0.000000]  reserved[0x2]	[0x00000016ede000-0x00000016f97fff], 0xba000 bytes
[    0.000000] initial memory mapped: [mem 0x00000000-0x16be8fff]
[    0.000000] memblock_reserve: [0x0000000009a000-0x000000000a0000] setup_real_mode+0x69/0x19b
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x5ddfffff]
[    0.000000]  [mem 0x00000000-0x5ddfffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x5ddfffff @ [mem 0x01d9a000-0x0208bfff]
[    0.000000] memblock_reserve: [0x00000001d9a000-0x00000001fd0000] native_pagetable_reserve+0xc/0xe
[    0.000000] xen: setting RW the range 1fd0000 - 208c000
[    0.000000] RAMDISK: [mem 0x0208c000-0x16be8fff]
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000005ddfffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x5ddfffff]
[    0.000000] memblock_reserve: [0x0000005ddfc000-0x0000005de00000] memblock_alloc_base_nid+0x3f/0x52
[    0.000000]   NODE_DATA [mem 0x5ddfc000-0x5ddfffff]
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x5dd90000 reserved size = 0x15dc7000
[    0.000000]  memory.cnt  = 0x2
[    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009ffff], 0x90000 bytes on node 0
[    0.000000]  memory[0x1]	[0x00000000100000-0x0000005ddfffff], 0x5dd00000 bytes on node 0
[    0.000000]  reserved.cnt  = 0x6
[    0.000000]  reserved[0x0]	[0x0000000009a000-0x0000000009ffff], 0x6000 bytes
[    0.000000]  reserved[0x1]	[0x00000001000000-0x00000001c7dfff], 0xc7e000 bytes
[    0.000000]  reserved[0x2]	[0x00000001d9a000-0x00000001fcffff], 0x236000 bytes
[    0.000000]  reserved[0x3]	[0x0000000208c000-0x00000016edafff], 0x14e4f000 bytes
[    0.000000]  reserved[0x4]	[0x00000016ede000-0x00000016f97fff], 0xba000 bytes
[    0.000000]  reserved[0x5]	[0x0000005ddfc000-0x0000005ddfffff], 0x4000 bytes
[    0.000000] memblock_reserve: [0x0000005ddfb000-0x0000005ddfc000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d9fb000-0x0000005ddfb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d9fae80-0x0000005d9fb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5fae80-0x0000005d9fae80] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005bc00000-0x0000005d400000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f9000-0x0000005d5fa000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f8000-0x0000005d5f9000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f7000-0x0000005d5f8000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f6000-0x0000005d5f7000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f5000-0x0000005d5f6000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f4000-0x0000005d5f5000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f3000-0x0000005d5f4000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f2000-0x0000005d5f3000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f1000-0x0000005d5f2000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5f0000-0x0000005d5f1000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5ef000-0x0000005d5f0000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5ee000-0x0000005d5ef000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d5ed000-0x0000005d5ee000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x0000005d100000-0x0000005d400000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d5fae80-0x0000005d9fae80] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d9fb000-0x0000005ddfb000] free_bootmem+0x9/0xb
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009ffff]
[    0.000000]   node   0: [mem 0x00100000-0x5ddfffff]
[    0.000000] On node 0 totalpages: 384400
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3922 pages, LIFO batch:0
[    0.000000] memblock_reserve: [0x0000005dde3000-0x0000005ddfb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]   DMA32 zone: 5201 pages used for memmap
[    0.000000]   DMA32 zone: 375215 pages, LIFO batch:31
[    0.000000] memblock_reserve: [0x0000005ddcb000-0x0000005dde3000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dadc000-0x0000005ddcb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x00000016be9000-0x00000016ed8000] xen_pagetable_init+0xc9/0x1d8
[    0.000000] memblock_reserve: [0x0000005dadb000-0x0000005dadc000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dada000-0x0000005dadb000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad9000-0x0000005dada000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad8000-0x0000005dad9000] __alloc_memory_core_early+0x5c/0x64
[    0.000000] smpboot: Allowing 3 CPUs, 0 hotplug CPUs
[    0.000000] No local APIC present
[    0.000000] APIC: disable apic facility
[    0.000000] APIC: switched to apic NOOP
[    0.000000] nr_irqs_gsi: 16
[    0.000000] memblock_reserve: [0x0000005dad7f00-0x0000005dad7fe0] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7e80-0x0000005dad7ee8] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7e00-0x0000005dad7e68] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7d80-0x0000005dad7de8] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7d40-0x0000005dad7d60] __alloc_memory_core_early+0x5c/0x64
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] e820: [mem 0x5de00000-0xffffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.0 (preserve-AD)
[    0.000000] memblock_reserve: [0x0000005dad7cc0-0x0000005dad7d0c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7c40-0x0000005dad7c8c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:3 nr_node_ids:1
[    0.000000] memblock_reserve: [0x0000005dad6c40-0x0000005dad7c40] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5c40-0x0000005dad6c40] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005d600000-0x0000005d800000] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x0000005d61c000-0x0000005d680000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d69c000-0x0000005d700000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d71c000-0x0000005d780000] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005d780000-0x0000005d800000] free_bootmem+0x9/0xb
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88005d600000 s84480 r8192 d22016 u524288
[    0.000000] memblock_reserve: [0x0000005dad5c00-0x0000005dad5c08] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5bc0-0x0000005dad5bc8] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5b80-0x0000005dad5b8c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5b40-0x0000005dad5b58] __alloc_memory_core_early+0x5c/0x64
[    0.000000] pcpu-alloc: s84480 r8192 d22016 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 - 
[    0.000000] memblock_reserve: [0x0000005dad5a00-0x0000005dad5b30] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5980-0x0000005dad59d0] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad5900-0x0000005dad5950] __alloc_memory_core_early+0x5c/0x64
[    0.000000]    memblock_free: [0x0000005dad6c40-0x0000005dad7c40] free_bootmem+0x9/0xb
[    0.000000]    memblock_free: [0x0000005dad5c40-0x0000005dad6c40] free_bootmem+0x9/0xb
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 379137
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: console=hvc0 debug earlyprintk=xen memblock=debug loglevel=8 initcall_debug
[    0.000000] memblock_reserve: [0x0000005dacd900-0x0000005dad5900] __alloc_memory_core_early+0x5c/0x64
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] memblock_reserve: [0x0000005dad7900-0x0000005dad7c40] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad78c0-0x0000005dad78cc] __alloc_memory_core_early+0x5c/0x64
[    0.000000] memblock_reserve: [0x0000005dad7880-0x0000005dad788c] __alloc_memory_core_early+0x5c/0x64
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] Memory: 1157280k/1538048k available (6561k kernel code, 448k absent, 380320k reserved, 4345k data, 756k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=3.
[    0.000000] NR_IRQS:33024 nr_irqs:296 16
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.001000] pid_max: default: 32768 minimum: 301
[    0.001000] Security Framework initialized
[    0.001000] SELinux:  Initializing.
[    0.001000] SELinux:  Starting in permissive mode
[    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001186] Mount-cache hash table entries: 256
[    0.001416] Initializing cgroup subsys cpuacct
[    0.001422] Initializing cgroup subsys freezer
[    0.001477] tseg: 00adf00000
[    0.001484] CPU: Physical Processor ID: 0
[    0.001489] CPU: Processor Core ID: 6
[    0.001495] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.001495] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.001495] tlb_flushall_shift: 5
[    0.022164] cpu 0 spinlock event irq 17
[    0.022202] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
[    0.022211] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
[    0.022219] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
[    0.022227] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
[    0.022236] calling  init_hw_perf_events+0x0/0x414 @ 1
[    0.022242] Performance Events: 
[    0.022247] perf: AMD core performance counters detected
[    0.022254] no APIC, boot with the "lapic" boot parameter to force-enable it.
[    0.022261] no hardware sampling interrupt available.
[    0.022277] Broken PMU hardware detected, using software events only.
[    0.022284] Failed to access perfctr msr (MSR c0010201 is 0)
[    0.022292] initcall init_hw_perf_events+0x0/0x414 returned 0 after 0 usecs
[    0.022299] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
[    0.022307] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
[    0.022316] calling  spawn_ksoftirqd+0x0/0x28 @ 1
[    0.022360] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
[    0.022368] calling  init_workqueues+0x0/0x33a @ 1
[    0.022543] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
[    0.022552] calling  migration_init+0x0/0x71 @ 1
[    0.022560] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
[    0.022568] calling  cpu_stop_init+0x0/0xb4 @ 1
[    0.022606] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
[    0.022615] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
[    0.022622] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
[    0.022630] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
[    0.022684] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
[    0.022692] calling  relay_init+0x0/0x14 @ 1
[    0.022698] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
[    0.022705] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
[    0.022746] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
[    0.022753] calling  init_events+0x0/0x61 @ 1
[    0.022761] initcall init_events+0x0/0x61 returned 0 after 0 usecs
[    0.022768] calling  init_trace_printk+0x0/0x12 @ 1
[    0.022775] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
[    0.022782] calling  jump_label_init_module+0x0/0x12 @ 1
[    0.022789] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
[    0.022797] calling  mce_amd_init+0x0/0x110 @ 1
[    0.022803] MCE: In-kernel MCE decoding enabled.
[    0.022811] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
[    0.022903] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.023115] installing Xen timer for CPU 1
[    0.023134] cpu 1 spinlock event irq 24
[    0.023185] SMP alternatives: switching to SMP code
[    0.042382] installing Xen timer for CPU 2
[    0.042402] cpu 2 spinlock event irq 31
[    0.042544] Brought up 3 CPUs
[    0.044906] calling  ipc_ns_init+0x0/0x14 @ 1
[    0.044915] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
[    0.044923] calling  init_mmap_min_addr+0x0/0x26 @ 1
[    0.044930] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
[    0.044938] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
[    0.044948] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
[    0.044957] calling  net_ns_init+0x0/0xfd @ 1
[    0.044990] initcall net_ns_init+0x0/0xfd returned 0 after 0 usecs
[    0.045019] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
[    0.045027] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
[    0.045036] calling  cpufreq_tsc+0x0/0x37 @ 1
[    0.045044] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
[    0.046007] calling  reboot_init+0x0/0x1d @ 1
[    0.046017] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
[    0.046025] calling  init_lapic_sysfs+0x0/0x20 @ 1
[    0.046032] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
[    0.046040] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
[    0.046049] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
[    0.046057] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.046065] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.046073] calling  ksysfs_init+0x0/0x94 @ 1
[    0.046094] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
[    0.046103] calling  pm_init+0x0/0x4e @ 1
[    0.046117] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
[    0.046125] calling  pm_disk_init+0x0/0x19 @ 1
[    0.046136] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
[    0.046146] calling  swsusp_header_init+0x0/0x30 @ 1
[    0.046154] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
[    0.046162] calling  init_jiffies_clocksource+0x0/0x12 @ 1
[    0.046172] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
[    0.046181] calling  event_trace_enable+0x0/0xa9 @ 1
[    0.046213] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
[    0.046222] calling  init_zero_pfn+0x0/0x35 @ 1
[    0.046229] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
[    0.046237] calling  fsnotify_init+0x0/0x26 @ 1
[    0.046246] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
[    0.046254] calling  filelock_init+0x0/0x2a @ 1
[    0.046281] initcall filelock_init+0x0/0x2a returned 0 after 0 usecs
[    0.046290] calling  init_misc_binfmt+0x0/0x31 @ 1
[    0.046298] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
[    0.046306] calling  init_script_binfmt+0x0/0x16 @ 1
[    0.046314] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046322] calling  init_elf_binfmt+0x0/0x16 @ 1
[    0.046330] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046338] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
[    0.046346] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
[    0.046354] calling  debugfs_init+0x0/0x5c @ 1
[    0.046364] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
[    0.046371] calling  securityfs_init+0x0/0x53 @ 1
[    0.046381] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
[    0.046389] calling  prandom_init+0x0/0xd9 @ 1
[    0.046397] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
[    0.046406] calling  virtio_init+0x0/0x30 @ 1
[    0.046429] kworker/u:0 (26) used greatest stack depth: 6136 bytes left
[    0.046429] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  __gnttab_init+0x0/0x30 @ 1
[    0.046429] Grant tables using version 2 layout.
[    0.046429] Grant table initialized
[    0.046429] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
[    0.046429] calling  early_resume_init+0x0/0x1d0 @ 1
[    0.065694] RTC time: 165:165:165, date: 165/165/65
[    0.065702] initcall early_resume_init+0x0/0x1d0 returned 0 after 18554 usecs
[    0.065711] calling  cpufreq_core_init+0x0/0xc7 @ 1
[    0.065719] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
[    0.065727] calling  cpuidle_init+0x0/0x40 @ 1
[    0.065734] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
[    0.065742] calling  bsp_pm_check_init+0x0/0x14 @ 1
[    0.065749] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
[    0.065756] calling  sock_init+0x0/0x89 @ 1
[    0.065842] initcall sock_init+0x0/0x89 returned 0 after 0 usecs
[    0.065850] calling  net_inuse_init+0x0/0x26 @ 1
[    0.065859] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
[    0.065867] calling  netpoll_init+0x0/0x31 @ 1
[    0.065874] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
[    0.065881] calling  netlink_proto_init+0x0/0x1b3 @ 1
[    0.065897] NET: Registered protocol family 16
[    0.065917] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
[    0.065938] calling  bdi_class_init+0x0/0x4d @ 1
[    0.066049] initcall bdi_class_init+0x0/0x4d returned 0 after 976 usecs
[    0.066060] calling  kobject_uevent_init+0x0/0x12 @ 1
[    0.066071] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
[    0.066079] calling  pcibus_class_init+0x0/0x19 @ 1
[    0.066096] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  pci_driver_init+0x0/0x19 @ 1
[    0.066096] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
[    0.066096] calling  backlight_class_init+0x0/0x5d @ 1
[    0.067045] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
[    0.067045] calling  video_output_class_init+0x0/0x19 @ 1
[    0.067063] kworker/u:0 (31) used greatest stack depth: 5592 bytes left
[    0.067063] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
[    0.067063] calling  xenbus_init+0x0/0x21a @ 1
[    0.067093] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
[    0.067093] calling  tty_class_init+0x0/0x38 @ 1
[    0.067093] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
[    0.067093] calling  vtconsole_class_init+0x0/0xc2 @ 1
[    0.067093] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
[    0.067093] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
[    0.067093] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
[    0.067093] calling  register_node_type+0x0/0x34 @ 1
[    0.067093] initcall register_node_type+0x0/0x34 returned 0 after 0 usecs
[    0.067093] calling  i2c_init+0x0/0x77 @ 1
[    0.068032] initcall i2c_init+0x0/0x77 returned 0 after 976 usecs
[    0.068043] calling  amd_postcore_init+0x0/0x143 @ 1
[    0.068130] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
[    0.068160] calling  set_real_mode_permissions+0x0/0xa9 @ 1
[    0.068216] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 0 usecs
[    0.068227] calling  arch_kdebugfs_init+0x0/0x233 @ 1
[    0.068268] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
[    0.068278] calling  mtrr_if_init+0x0/0x78 @ 1
[    0.068286] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
[    0.068294] calling  ffh_cstate_init+0x0/0x2a @ 1
[    0.068303] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
[    0.068311] initcall ffh_cstate_init+0x0/0x2a returned with error code -1 
[    0.068319] calling  activate_jump_labels+0x0/0x32 @ 1
[    0.068327] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
[    0.068335] calling  acpi_pci_init+0x0/0x5c @ 1
[    0.068343] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
[    0.068352] calling  dma_bus_init+0x0/0x19 @ 1
[    0.068371] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
[    0.068371] calling  dma_channel_table_init+0x0/0x119 @ 1
[    0.068371] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
[    0.068371] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
[    0.070221] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 1953 usecs
[    0.070233] calling  register_xen_pci_notifier+0x0/0x38 @ 1
[    0.070241] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
[    0.070249] calling  xen_pcpu_init+0x0/0xcc @ 1
[    0.070256] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
[    0.070264] calling  dmi_id_init+0x0/0x31d @ 1
[    0.070272] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
[    0.070280] calling  dca_init+0x0/0x20 @ 1
[    0.070286] dca service started, version 1.12.1
[    0.070358] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
[    0.070366] calling  pci_arch_init+0x0/0x69 @ 1
[    0.071009] PCI: setting up Xen PCI frontend stub
[    0.071016] PCI: pci_cache_line_size set to 64 bytes
[    0.071024] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
[    0.071045] calling  topology_init+0x0/0x98 @ 1
[    0.071262] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
[    0.071271] calling  mtrr_init_finialize+0x0/0x36 @ 1
[    0.071278] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
[    0.071286] calling  init_vdso+0x0/0x135 @ 1
[    0.071296] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
[    0.071304] calling  sysenter_setup+0x0/0x2dd @ 1
[    0.071314] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
[    0.071322] calling  param_sysfs_init+0x0/0x192 @ 1
[    0.083778] initcall param_sysfs_init+0x0/0x192 returned 0 after 11718 usecs
[    0.083790] calling  pm_sysrq_init+0x0/0x19 @ 1
[    0.083800] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
[    0.083808] calling  default_bdi_init+0x0/0x37 @ 1
[    0.083946] initcall default_bdi_init+0x0/0x37 returned 0 after 0 usecs
[    0.084039] calling  init_bio+0x0/0xe8 @ 1
[    0.084059] bio: create slab <bio-0> at 0
[    0.084078] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
[    0.084087] calling  fsnotify_notification_init+0x0/0x8b @ 1
[    0.084105] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
[    0.084114] calling  cryptomgr_init+0x0/0x12 @ 1
[    0.084122] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
[    0.084130] calling  blk_settings_init+0x0/0x2c @ 1
[    0.084138] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
[    0.084146] calling  blk_ioc_init+0x0/0x2a @ 1
[    0.084157] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
[    0.084165] calling  blk_softirq_init+0x0/0x6e @ 1
[    0.084174] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
[    0.084181] calling  blk_iopoll_setup+0x0/0x6e @ 1
[    0.084189] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
[    0.084197] calling  genhd_device_init+0x0/0x85 @ 1
[    0.084326] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
[    0.084337] calling  pci_slot_init+0x0/0x50 @ 1
[    0.084347] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
[    0.084355] calling  fbmem_init+0x0/0x98 @ 1
[    0.084428] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
[    0.084438] calling  acpi_init+0x0/0xbc @ 1
[    0.084444] ACPI: Interpreter disabled.
[    0.084451] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
[    0.084459] calling  dock_init+0x0/0x7b @ 1
[    0.084467] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
[    0.084475] calling  acpi_pci_root_init+0x0/0x32 @ 1
[    0.084483] initcall acpi_pci_root_init+0x0/0x32 returned 0 after 0 usecs
[    0.084491] calling  acpi_pci_link_init+0x0/0x43 @ 1
[    0.084499] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
[    0.084507] calling  pnp_init+0x0/0x19 @ 1
[    0.084576] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
[    0.084586] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
[    0.084600] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 0 usecs
[    0.084600] calling  balloon_init+0x0/0x133 @ 1
[    0.084600] xen/balloon: Initialising balloon driver.
[    0.084600] initcall balloon_init+0x0/0x133 returned 0 after 0 usecs
[    0.084600] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
[    0.085058] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 976 usecs
[    0.085058] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
[    0.085110] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 0 usecs
[    0.085110] calling  xen_acpi_pad_init+0x0/0x47 @ 1
[    0.085110] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
[    0.085110] calling  balloon_init+0x0/0xfa @ 1
[    0.085110] xen-balloon: Initialising balloon driver.
[    0.086035] initcall balloon_init+0x0/0xfa returned 0 after 976 usecs
[    0.086035] calling  xen_selfballoon_init+0x0/0xb9 @ 1
[    0.086043] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
[    0.086051] calling  misc_init+0x0/0xba @ 1
[    0.086151] initcall misc_init+0x0/0xba returned 0 after 0 usecs
[    0.086159] calling  vga_arb_device_init+0x0/0xde @ 1
[    0.086269] vgaarb: loaded
[    0.086276] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
[    0.086285] calling  cn_init+0x0/0xc0 @ 1
[    0.086302] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
[    0.086310] calling  phy_init+0x0/0x2e @ 1
[    0.086493] initcall phy_init+0x0/0x2e returned 0 after 0 usecs
[    0.086501] calling  init_pcmcia_cs+0x0/0x3d @ 1
[    0.086564] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
[    0.086572] calling  usb_init+0x0/0x170 @ 1
[    0.086726] usbcore: registered new interface driver usbfs
[    0.086798] usbcore: registered new interface driver hub
[    0.086890] usbcore: registered new device driver usb
[    0.086898] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
[    0.086906] calling  serio_init+0x0/0x38 @ 1
[    0.086974] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
[    0.086982] calling  input_init+0x0/0x103 @ 1
[    0.087087] initcall input_init+0x0/0x103 returned 0 after 0 usecs
[    0.087095] calling  rtc_init+0x0/0x71 @ 1
[    0.087158] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
[    0.087166] calling  pps_init+0x0/0xb7 @ 1
[    0.087227] pps_core: LinuxPPS API ver. 1 registered
[    0.088018] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.088030] initcall pps_init+0x0/0xb7 returned 0 after 976 usecs
[    0.088038] calling  ptp_init+0x0/0xa4 @ 1
[    0.088113] PTP clock support registered
[    0.088122] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
[    0.088130] calling  power_supply_class_init+0x0/0x44 @ 1
[    0.088195] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
[    0.088204] calling  hwmon_init+0x0/0xf6 @ 1
[    0.088268] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
[    0.088277] calling  leds_init+0x0/0x48 @ 1
[    0.088340] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
[    0.088349] calling  iommu_init+0x0/0x58 @ 1
[    0.088359] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
[    0.088367] calling  pci_subsys_init+0x0/0x4f @ 1
[    0.088374] PCI: System does not support PCI
[    0.088381] PCI: System does not support PCI
[    0.088388] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
[    0.088396] calling  proto_init+0x0/0x12 @ 1
[    0.088407] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
[    0.088415] calling  net_dev_init+0x0/0x1c7 @ 1
[    0.088739] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
[    0.088748] calling  neigh_init+0x0/0x80 @ 1
[    0.088757] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
[    0.088765] calling  fib_rules_init+0x0/0xaf @ 1
[    0.088773] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
[    0.088781] calling  pktsched_init+0x0/0xfe @ 1
[    0.088792] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
[    0.088800] calling  tc_filter_init+0x0/0x55 @ 1
[    0.088807] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
[    0.088816] calling  tc_action_init+0x0/0x55 @ 1
[    0.088823] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
[    0.088831] calling  genl_init+0x0/0x75 @ 1
[    0.088845] initcall genl_init+0x0/0x75 returned 0 after 0 usecs
[    0.088853] calling  cipso_v4_init+0x0/0x61 @ 1
[    0.088862] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
[    0.088870] calling  netlbl_init+0x0/0x81 @ 1
[    0.088876] NetLabel: Initializing
[    0.088882] NetLabel:  domain hash size = 128
[    0.088888] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.088910] NetLabel:  unlabeled traffic allowed by default
[    0.088919] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
[    0.088926] calling  rfkill_init+0x0/0x79 @ 1
[    0.089030] initcall rfkill_init+0x0/0x79 returned 0 after 976 usecs
[    0.089054] calling  xen_p2m_debugfs+0x0/0x4a @ 1
[    0.089087] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
[    0.089095] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
[    0.089219] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
[    0.089228] calling  hpet_late_init+0x0/0x101 @ 1
[    0.089235] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
[    0.089243] calling  init_amd_nbs+0x0/0xb8 @ 1
[    0.089251] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
[    0.089260] calling  clocksource_done_booting+0x0/0x5a @ 1
[    0.089267] Switching to clocksource xen
[    0.089294] initcall clocksource_done_booting+0x0/0x5a returned 0 after 11 usecs
[    0.089303] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
[    0.089711] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 391 usecs
[    0.089720] calling  init_trace_printk_function_export+0x0/0x2f @ 1
[    0.089734] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 6 usecs
[    0.089743] calling  event_trace_init+0x0/0x271 @ 1
[    0.099475] initcall event_trace_init+0x0/0x271 returned 0 after 9769 usecs
[    0.099485] calling  init_kprobe_trace+0x0/0x93 @ 1
[    0.099505] initcall init_kprobe_trace+0x0/0x93 returned 0 after 12 usecs
[    0.099513] calling  init_pipe_fs+0x0/0x4c @ 1
[    0.099543] initcall init_pipe_fs+0x0/0x4c returned 0 after 22 usecs
[    0.099552] calling  eventpoll_init+0x0/0xda @ 1
[    0.099566] initcall eventpoll_init+0x0/0xda returned 0 after 6 usecs
[    0.099574] calling  anon_inode_init+0x0/0x5b @ 1
[    0.099604] initcall anon_inode_init+0x0/0x5b returned 0 after 21 usecs
[    0.099612] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
[    0.099620] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
[    0.287868] calling  acpi_event_init+0x0/0x81 @ 1
[    0.287878] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
[    0.287887] calling  pnp_system_init+0x0/0x12 @ 1
[    0.288027] initcall pnp_system_init+0x0/0x12 returned 0 after 127 usecs
[    0.288036] calling  pnpacpi_init+0x0/0x8c @ 1
[    0.288044] pnp: PnP ACPI: disabled
[    0.288052] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
[    0.288100] calling  pcistub_init+0x0/0x29f @ 1
[    0.288197] initcall pcistub_init+0x0/0x29f returned 0 after 86 usecs
[    0.288207] calling  chr_dev_init+0x0/0xc6 @ 1
[    0.293859] initcall chr_dev_init+0x0/0xc6 returned 0 after 5511 usecs
[    0.293869] calling  firmware_class_init+0x0/0xda @ 1
[    0.293941] initcall firmware_class_init+0x0/0xda returned 0 after 60 usecs
[    0.293951] calling  init_pcmcia_bus+0x0/0x6c @ 1
[    0.294023] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 62 usecs
[    0.294032] calling  thermal_init+0x0/0x75 @ 1
[    0.294193] initcall thermal_init+0x0/0x75 returned 0 after 149 usecs
[    0.294203] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
[    0.294212] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
[    0.294221] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
[    0.294229] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
[    0.294239] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
[    0.294247] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
[    0.294256] calling  pcibios_assign_resources+0x0/0xf8 @ 1
[    0.294267] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
[    0.294276] calling  sysctl_core_init+0x0/0x2c @ 1
[    0.294295] initcall sysctl_core_init+0x0/0x2c returned 0 after 11 usecs
[    0.294303] calling  inet_init+0x0/0x2a1 @ 1
[    0.294332] NET: Registered protocol family 2
[    0.294575] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294649] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    0.294697] TCP: Hash tables configured (established 16384 bind 16384)
[    0.294733] TCP: reno registered
[    0.294747] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294767] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    0.294857] initcall inet_init+0x0/0x2a1 returned 0 after 533 usecs
[    0.294866] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.294875] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs
[    0.294883] calling  af_unix_init+0x0/0x55 @ 1
[    0.294891] NET: Registered protocol family 1
[    0.294907] initcall af_unix_init+0x0/0x55 returned 0 after 16 usecs
[    0.294916] calling  ipv6_offload_init+0x0/0x6e @ 1
[    0.294925] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
[    0.294933] calling  init_sunrpc+0x0/0x69 @ 1
[    0.295092] RPC: Registered named UNIX socket transport module.
[    0.295101] RPC: Registered udp transport module.
[    0.295108] RPC: Registered tcp transport module.
[    0.295114] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.295123] initcall init_sunrpc+0x0/0x69 returned 0 after 177 usecs
[    0.295131] calling  pci_apply_final_quirks+0x0/0x117 @ 1
[    0.295139] PCI: CLS 0 bytes, default 64
[    0.295146] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 6 usecs
[    0.295155] calling  populate_rootfs+0x0/0x10d @ 1
[    0.295384] Unpacking initramfs...
[    0.854446] Freeing initrd memory: 339316k freed
[    0.941088] initcall populate_rootfs+0x0/0x10d returned 0 after 630779 usecs
[    0.941109] calling  pci_iommu_init+0x0/0x41 @ 1
[    0.941118] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
[    0.941126] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
[    0.941135] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
[    0.941164] calling  irqfd_module_init+0x0/0x33 @ 1
[    0.941260] initcall irqfd_module_init+0x0/0x33 returned 0 after 85 usecs
[    0.941270] calling  i8259A_init_ops+0x0/0x21 @ 1
[    0.941278] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
[    0.941286] calling  vsyscall_init+0x0/0x27 @ 1
[    0.941303] initcall vsyscall_init+0x0/0x27 returned 0 after 6 usecs
[    0.941312] calling  sbf_init+0x0/0xf6 @ 1
[    0.941320] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
[    0.941330] calling  init_tsc_clocksource+0x0/0x89 @ 1
[    0.941343] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
[    0.941353] calling  add_rtc_cmos+0x0/0x96 @ 1
[    0.941554] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.941575] initcall add_rtc_cmos+0x0/0x96 returned 0 after 204 usecs
[    0.941587] calling  i8237A_init_ops+0x0/0x14 @ 1
[    0.941597] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.941610] calling  cache_sysfs_init+0x0/0x6c @ 1
[    0.941692] initcall cache_sysfs_init+0x0/0x6c returned 0 after 70 usecs
[    0.941703] calling  intel_uncore_init+0x0/0x3fa @ 1
[    0.941712] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
[    0.941721] calling  inject_init+0x0/0x30 @ 1
[    0.941728] Machine check injector initialized
[    0.941737] initcall inject_init+0x0/0x30 returned 0 after 7 usecs
[    0.941745] calling  thermal_throttle_init_device+0x0/0x9d @ 1
[    0.941754] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
[    0.941763] calling  amd_ibs_init+0x0/0x48d @ 1
[    0.941772] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
[    0.941781] calling  msr_init+0x0/0x162 @ 1
[    0.941942] initcall msr_init+0x0/0x162 returned 0 after 149 usecs
[    0.941952] calling  cpuid_init+0x0/0x162 @ 1
[    0.942124] initcall cpuid_init+0x0/0x162 returned 0 after 159 usecs
[    0.942133] calling  ioapic_init_ops+0x0/0x14 @ 1
[    0.942141] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942149] calling  add_pcspkr+0x0/0x40 @ 1
[    0.942229] initcall add_pcspkr+0x0/0x40 returned 0 after 70 usecs
[    0.942238] calling  microcode_init+0x0/0x1b1 @ 1
[    0.942318] microcode: CPU0: patch_level=0x06000626
[    0.942401] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.942412] initcall microcode_init+0x0/0x1b1 returned 0 after 162 usecs
[    0.942422] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
[    0.942430] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
[    0.942439] calling  audit_classes_init+0x0/0xaf @ 1
[    0.942452] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
[    0.942460] calling  pt_dump_init+0x0/0x30 @ 1
[    0.942485] initcall pt_dump_init+0x0/0x30 returned 0 after 16 usecs
[    0.942494] calling  ia32_binfmt_init+0x0/0x14 @ 1
[    0.942507] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 5 usecs
[    0.942515] calling  proc_execdomains_init+0x0/0x22 @ 1
[    0.942529] initcall proc_execdomains_init+0x0/0x22 returned 0 after 5 usecs
[    0.942538] calling  ioresources_init+0x0/0x3c @ 1
[    0.942552] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
[    0.942561] calling  uid_cache_init+0x0/0xa5 @ 1
[    0.942574] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
[    0.942582] calling  init_posix_timers+0x0/0x1f4 @ 1
[    0.942598] initcall init_posix_timers+0x0/0x1f4 returned 0 after 7 usecs
[    0.942606] calling  init_posix_cpu_timers+0x0/0xbf @ 1
[    0.942614] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
[    0.942623] calling  proc_schedstat_init+0x0/0x22 @ 1
[    0.942634] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
[    0.942642] calling  snapshot_device_init+0x0/0x12 @ 1
[    0.942724] initcall snapshot_device_init+0x0/0x12 returned 0 after 72 usecs
[    0.942733] calling  create_proc_profile+0x0/0x2c0 @ 1
[    0.942741] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
[    0.942749] calling  timekeeping_init_ops+0x0/0x14 @ 1
[    0.942757] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
[    0.942765] calling  init_clocksource_sysfs+0x0/0x52 @ 1
[    0.942913] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 136 usecs
[    0.942923] calling  init_timer_list_procfs+0x0/0x2c @ 1
[    0.942934] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 3 usecs
[    0.942943] calling  alarmtimer_init+0x0/0x15d @ 1
[    0.943122] initcall alarmtimer_init+0x0/0x15d returned 0 after 166 usecs
[    0.943131] calling  init_tstats_procfs+0x0/0x2c @ 1
[    0.943143] initcall init_tstats_procfs+0x0/0x2c returned 0 after 4 usecs
[    0.943150] calling  futex_init+0x0/0x65 @ 1
[    0.943163] initcall futex_init+0x0/0x65 returned 0 after 5 usecs
[    0.943170] calling  proc_dma_init+0x0/0x22 @ 1
[    0.943181] initcall proc_dma_init+0x0/0x22 returned 0 after 3 usecs
[    0.943188] calling  proc_modules_init+0x0/0x22 @ 1
[    0.943199] initcall proc_modules_init+0x0/0x22 returned 0 after 3 usecs
[    0.943207] calling  kallsyms_init+0x0/0x25 @ 1
[    0.943217] initcall kallsyms_init+0x0/0x25 returned 0 after 2 usecs
[    0.943224] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
[    1.054869] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 14 usecs
[    1.054879] calling  crash_notes_memory_init+0x0/0x36 @ 1
[    1.054891] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 3 usecs
[    1.054900] calling  pid_namespaces_init+0x0/0x2d @ 1
[    1.054910] initcall pid_namespaces_init+0x0/0x2d returned 0 after 2 usecs
[    1.054918] calling  ikconfig_init+0x0/0x3a @ 1
[    1.054929] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
[    1.054936] calling  audit_init+0x0/0x141 @ 1
[    1.054943] audit: initializing netlink socket (disabled)
[    1.054961] type=2000 audit(1361569587.289:1): initialized
[    1.054971] initcall audit_init+0x0/0x141 returned 0 after 26 usecs
[    1.054979] calling  audit_watch_init+0x0/0x3a @ 1
[    1.054986] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
[    1.054994] calling  audit_tree_init+0x0/0x49 @ 1
[    1.055003] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
[    1.055010] calling  init_kprobes+0x0/0x16c @ 1
[    1.065934] initcall init_kprobes+0x0/0x16c returned 0 after 10660 usecs
[    1.065947] calling  hung_task_init+0x0/0x56 @ 1
[    1.065990] initcall hung_task_init+0x0/0x56 returned 0 after 33 usecs
[    1.065998] calling  irq_pm_init_ops+0x0/0x14 @ 1
[    1.066009] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
[    1.066017] calling  utsname_sysctl_init+0x0/0x14 @ 1
[    1.066031] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.066039] calling  init_tracepoints+0x0/0x20 @ 1
[    1.066047] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
[    1.066083] calling  init_blk_tracer+0x0/0x5a @ 1
[    1.066092] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
[    1.066100] calling  perf_event_sysfs_init+0x0/0x9a @ 1
[    1.066383] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 268 usecs
[    1.066394] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
[    1.066511] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 105 usecs
[    1.066521] calling  kswapd_init+0x0/0x76 @ 1
[    1.066562] initcall kswapd_init+0x0/0x76 returned 0 after 32 usecs
[    1.066571] calling  extfrag_debug_init+0x0/0x7e @ 1
[    1.066600] initcall extfrag_debug_init+0x0/0x7e returned 0 after 20 usecs
[    1.066609] calling  setup_vmstat+0x0/0xc8 @ 1
[    1.066630] initcall setup_vmstat+0x0/0xc8 returned 0 after 13 usecs
[    1.066639] calling  mm_sysfs_init+0x0/0x29 @ 1
[    1.066649] initcall mm_sysfs_init+0x0/0x29 returned 0 after 2 usecs
[    1.066657] calling  slab_proc_init+0x0/0x25 @ 1
[    1.066668] initcall slab_proc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066676] calling  proc_vmalloc_init+0x0/0x25 @ 1
[    1.066687] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
[    1.066695] calling  procswaps_init+0x0/0x22 @ 1
[    1.066706] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
[    1.066714] calling  init_frontswap+0x0/0x96 @ 1
[    1.066761] initcall init_frontswap+0x0/0x96 returned 0 after 37 usecs
[    1.066771] calling  hugetlb_init+0x0/0x415 @ 1
[    1.066781] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.066813] initcall hugetlb_init+0x0/0x415 returned 0 after 31 usecs
[    1.066822] calling  mmu_notifier_init+0x0/0x12 @ 1
[    1.066833] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
[    1.066843] calling  slab_proc_init+0x0/0x8 @ 1
[    1.066852] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
[    1.066861] calling  cpucache_init+0x0/0x52 @ 1
[    1.066871] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
[    1.066881] calling  hugepage_init+0x0/0x191 @ 1
[    1.066890] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
[    1.066900] initcall hugepage_init+0x0/0x191 returned with error code -22 
[    1.066910] calling  init_cleancache+0x0/0x96 @ 1
[    1.066956] initcall init_cleancache+0x0/0x96 returned 0 after 35 usecs
[    1.066964] calling  fcntl_init+0x0/0x2a @ 1
[    1.066974] initcall fcntl_init+0x0/0x2a returned 0 after 2 usecs
[    1.066983] calling  proc_filesystems_init+0x0/0x22 @ 1
[    1.066997] initcall proc_filesystems_init+0x0/0x22 returned 0 after 6 usecs
[    1.067005] calling  dio_init+0x0/0x2d @ 1
[    1.067017] initcall dio_init+0x0/0x2d returned 0 after 4 usecs
[    1.067025] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    1.067086] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 51 usecs
[    1.067094] calling  dnotify_init+0x0/0x7b @ 1
[    1.067112] initcall dnotify_init+0x0/0x7b returned 0 after 9 usecs
[    1.067120] calling  inotify_user_setup+0x0/0x70 @ 1
[    1.067135] initcall inotify_user_setup+0x0/0x70 returned 0 after 6 usecs
[    1.067143] calling  aio_setup+0x0/0x7c @ 1
[    1.067160] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
[    1.067168] calling  proc_locks_init+0x0/0x22 @ 1
[    1.067179] initcall proc_locks_init+0x0/0x22 returned 0 after 3 usecs
[    1.067187] calling  init_sys32_ioctl+0x0/0x28 @ 1
[    1.255161] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 71 usecs
[    1.255177] calling  dquot_init+0x0/0x121 @ 1
[    1.255185] VFS: Disk quotas dquot_6.5.2
[    1.255226] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.255238] initcall dquot_init+0x0/0x121 returned 0 after 50 usecs
[    1.255249] calling  init_v2_quota_format+0x0/0x22 @ 1
[    1.255259] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
[    1.255267] calling  quota_init+0x0/0x26 @ 1
[    1.255286] initcall quota_init+0x0/0x26 returned 0 after 8 usecs
[    1.255296] calling  proc_cmdline_init+0x0/0x22 @ 1
[    1.255312] initcall proc_cmdline_init+0x0/0x22 returned 0 after 5 usecs
[    1.255323] calling  proc_consoles_init+0x0/0x22 @ 1
[    1.255338] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
[    1.255349] calling  proc_cpuinfo_init+0x0/0x22 @ 1
[    1.255362] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 3 usecs
[    1.255371] calling  proc_devices_init+0x0/0x22 @ 1
[    1.255383] initcall proc_devices_init+0x0/0x22 returned 0 after 4 usecs
[    1.255393] calling  proc_interrupts_init+0x0/0x22 @ 1
[    1.255407] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
[    1.255418] calling  proc_loadavg_init+0x0/0x22 @ 1
[    1.255432] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
[    1.255442] calling  proc_meminfo_init+0x0/0x22 @ 1
[    1.255457] initcall proc_meminfo_init+0x0/0x22 returned 0 after 4 usecs
[    1.255467] calling  proc_stat_init+0x0/0x22 @ 1
[    1.255481] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
[    1.255491] calling  proc_uptime_init+0x0/0x22 @ 1
[    1.255505] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
[    1.255516] calling  proc_version_init+0x0/0x22 @ 1
[    1.255530] initcall proc_version_init+0x0/0x22 returned 0 after 4 usecs
[    1.255540] calling  proc_softirqs_init+0x0/0x22 @ 1
[    1.255554] initcall proc_softirqs_init+0x0/0x22 returned 0 after 4 usecs
[    1.255565] calling  proc_kcore_init+0x0/0xb5 @ 1
[    1.255581] initcall proc_kcore_init+0x0/0xb5 returned 0 after 7 usecs
[    1.255592] calling  vmcore_init+0x0/0x370 @ 1
[    1.255602] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
[    1.255612] calling  proc_kmsg_init+0x0/0x25 @ 1
[    1.255627] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
[    1.255637] calling  proc_page_init+0x0/0x42 @ 1
[    1.255655] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
[    1.255665] calling  init_devpts_fs+0x0/0x62 @ 1
[    1.255717] initcall init_devpts_fs+0x0/0x62 returned 0 after 40 usecs
[    1.255728] calling  init_ramfs_fs+0x0/0x12 @ 1
[    1.255738] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255747] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
[    1.255811] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 53 usecs
[    1.255819] calling  init_fat_fs+0x0/0x4f @ 1
[    1.255837] initcall init_fat_fs+0x0/0x4f returned 0 after 9 usecs
[    1.255845] calling  init_vfat_fs+0x0/0x12 @ 1
[    1.255854] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255862] calling  init_msdos_fs+0x0/0x12 @ 1
[    1.255870] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
[    1.255878] calling  init_iso9660_fs+0x0/0x70 @ 1
[    1.255905] initcall init_iso9660_fs+0x0/0x70 returned 0 after 18 usecs
[    1.255913] calling  init_nfs_fs+0x0/0x16c @ 1
[    1.256045] initcall init_nfs_fs+0x0/0x16c returned 0 after 120 usecs
[    1.256077] calling  init_nfs_v2+0x0/0x14 @ 1
[    1.256086] initcall init_nfs_v2+0x0/0x14 returned 0 after 1 usecs
[    1.256093] calling  init_nfs_v3+0x0/0x14 @ 1
[    1.256101] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
[    1.256108] calling  init_nfs_v4+0x0/0x3b @ 1
[    1.256115] NFS: Registering the id_resolver key type
[    1.256134] Key type id_resolver registered
[    1.256140] Key type id_legacy registered
[    1.256151] initcall init_nfs_v4+0x0/0x3b returned 0 after 34 usecs
[    1.256159] calling  init_nlm+0x0/0x4c @ 1
[    1.256171] initcall init_nlm+0x0/0x4c returned 0 after 5 usecs
[    1.256179] calling  init_nls_cp437+0x0/0x12 @ 1
[    1.256187] initcall init_nls_cp437+0x0/0x12 returned 0 after 0 usecs
[    1.256194] calling  init_nls_ascii+0x0/0x12 @ 1
[    1.256202] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
[    1.256209] calling  init_nls_iso8859_1+0x0/0x12 @ 1
[    1.256217] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
[    1.256225] calling  init_nls_utf8+0x0/0x2b @ 1
[    1.256233] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
[    1.256240] calling  init_ntfs_fs+0x0/0x1d1 @ 1
[    1.256246] NTFS driver 2.1.30 [Flags: R/W].
[    1.455160] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 194248 usecs
[    1.455177] calling  init_autofs4_fs+0x0/0x2a @ 1
[    1.455306] initcall init_autofs4_fs+0x0/0x2a returned 0 after 117 usecs
[    1.455315] calling  init_pstore_fs+0x0/0x12 @ 1
[    1.455324] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
[    1.455331] calling  ipc_init+0x0/0x2f @ 1
[    1.455345] msgmni has been set to 2923
[    1.455359] initcall ipc_init+0x0/0x2f returned 0 after 19 usecs
[    1.455367] calling  ipc_sysctl_init+0x0/0x14 @ 1
[    1.455381] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
[    1.455389] calling  init_mqueue_fs+0x0/0xa2 @ 1
[    1.455434] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 36 usecs
[    1.455442] calling  key_proc_init+0x0/0x5e @ 1
[    1.455456] initcall key_proc_init+0x0/0x5e returned 0 after 6 usecs
[    1.455464] calling  selinux_nf_ip_init+0x0/0x69 @ 1
[    1.455471] SELinux:  Registering netfilter hooks
[    1.455652] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 175 usecs
[    1.455661] calling  init_sel_fs+0x0/0xa5 @ 1
[    1.455945] initcall init_sel_fs+0x0/0xa5 returned 0 after 269 usecs
[    1.455954] calling  selnl_init+0x0/0x56 @ 1
[    1.455967] initcall selnl_init+0x0/0x56 returned 0 after 5 usecs
[    1.455975] calling  sel_netif_init+0x0/0x5c @ 1
[    1.455984] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
[    1.455992] calling  sel_netnode_init+0x0/0x6a @ 1
[    1.456001] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
[    1.456008] calling  sel_netport_init+0x0/0x6a @ 1
[    1.456017] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
[    1.456025] calling  aurule_init+0x0/0x2d @ 1
[    1.456033] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
[    1.456040] calling  crypto_wq_init+0x0/0x33 @ 1
[    1.456101] initcall crypto_wq_init+0x0/0x33 returned 0 after 51 usecs
[    1.456110] calling  crypto_algapi_init+0x0/0xd @ 1
[    1.456121] initcall crypto_algapi_init+0x0/0xd returned 0 after 3 usecs
[    1.456129] calling  skcipher_module_init+0x0/0x35 @ 1
[    1.456137] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
[    1.456145] calling  chainiv_module_init+0x0/0x12 @ 1
[    1.456153] initcall chainiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456161] calling  eseqiv_module_init+0x0/0x12 @ 1
[    1.456169] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456176] calling  hmac_module_init+0x0/0x12 @ 1
[    1.456184] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456192] calling  md5_mod_init+0x0/0x12 @ 1
[    1.456254] initcall md5_mod_init+0x0/0x12 returned 0 after 53 usecs
[    1.456263] calling  sha1_generic_mod_init+0x0/0x12 @ 1
[    1.456315] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456324] calling  crypto_cbc_module_init+0x0/0x12 @ 1
[    1.456332] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456340] calling  des_generic_mod_init+0x0/0x17 @ 1
[    1.456434] initcall des_generic_mod_init+0x0/0x17 returned 0 after 84 usecs
[    1.456442] calling  aes_init+0x0/0x12 @ 1
[    1.456493] initcall aes_init+0x0/0x12 returned 0 after 42 usecs
[    1.456501] calling  zlib_mod_init+0x0/0x12 @ 1
[    1.456551] initcall zlib_mod_init+0x0/0x12 returned 0 after 41 usecs
[    1.456559] calling  crypto_authenc_module_init+0x0/0x12 @ 1
[    1.456567] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456575] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
[    1.456584] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
[    1.456592] calling  lzo_mod_init+0x0/0x12 @ 1
[    1.456643] initcall lzo_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456651] calling  krng_mod_init+0x0/0x12 @ 1
[    1.456702] initcall krng_mod_init+0x0/0x12 returned 0 after 42 usecs
[    1.456710] calling  proc_genhd_init+0x0/0x3c @ 1
[    1.456724] initcall proc_genhd_init+0x0/0x3c returned 0 after 6 usecs
[    1.456732] calling  bsg_init+0x0/0x12e @ 1
[    1.456803] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.456812] initcall bsg_init+0x0/0x12e returned 0 after 71 usecs
[    1.456820] calling  noop_init+0x0/0x12 @ 1
[    1.456827] io scheduler noop registered
[    1.456834] initcall noop_init+0x0/0x12 returned 0 after 7 usecs
[    1.456842] calling  deadline_init+0x0/0x12 @ 1
[    1.456849] io scheduler deadline registered
[    1.456856] initcall deadline_init+0x0/0x12 returned 0 after 6 usecs
[    1.456864] calling  cfq_init+0x0/0x8b @ 1
[    1.456878] io scheduler cfq registered (default)
[    1.456885] initcall cfq_init+0x0/0x8b returned 0 after 14 usecs
[    1.456893] calling  percpu_counter_startup+0x0/0x38 @ 1
[    1.456902] initcall percpu_counter_startup+0x0/0x38 returned 0 after 1 usecs
[    1.456910] calling  pci_proc_init+0x0/0x6a @ 1
[    1.654703] initcall pci_proc_init+0x0/0x6a returned 0 after 8 usecs
[    1.654716] calling  pcie_portdrv_init+0x0/0x7a @ 1
[    1.654876] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 148 usecs
[    1.654885] calling  aer_service_init+0x0/0x2b @ 1
[    1.654958] initcall aer_service_init+0x0/0x2b returned 0 after 63 usecs
[    1.654967] calling  pci_hotplug_init+0x0/0x1d @ 1
[    1.654974] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.654982] initcall pci_hotplug_init+0x0/0x1d returned 0 after 6 usecs
[    1.654990] calling  pcifront_init+0x0/0x3f @ 1
[    1.655085] initcall pcifront_init+0x0/0x3f returned 0 after 85 usecs
[    1.655094] calling  genericbl_driver_init+0x0/0x12 @ 1
[    1.655169] initcall genericbl_driver_init+0x0/0x12 returned 0 after 65 usecs
[    1.655178] calling  cirrusfb_init+0x0/0xcc @ 1
[    1.655265] initcall cirrusfb_init+0x0/0xcc returned 0 after 75 usecs
[    1.655277] calling  efifb_init+0x0/0x298 @ 1
[    1.655287] initcall efifb_init+0x0/0x298 returned -19 after 1 usecs
[    1.655297] calling  intel_idle_init+0x0/0x326 @ 1
[    1.655305] initcall intel_idle_init+0x0/0x326 returned -19 after 0 usecs
[    1.655313] calling  acpi_reserve_resources+0x0/0xeb @ 1
[    1.655322] initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 usecs
[    1.655330] calling  irqrouter_init_ops+0x0/0x26 @ 1
[    1.655338] initcall irqrouter_init_ops+0x0/0x26 returned 0 after 0 usecs
[    1.655347] calling  acpi_ac_init+0x0/0x28 @ 1
[    1.655357] initcall acpi_ac_init+0x0/0x28 returned -19 after 0 usecs
[    1.655369] calling  acpi_button_driver_init+0x0/0x12 @ 1
[    1.655379] initcall acpi_button_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655390] calling  acpi_fan_driver_init+0x0/0x12 @ 1
[    1.655399] initcall acpi_fan_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655409] calling  acpi_processor_init+0x0/0x6d @ 1
[    1.655419] initcall acpi_processor_init+0x0/0x6d returned 0 after 0 usecs
[    1.655429] calling  acpi_container_init+0x0/0x4a @ 1
[    1.655439] initcall acpi_container_init+0x0/0x4a returned -19 after 0 usecs
[    1.655450] calling  acpi_thermal_init+0x0/0x42 @ 1
[    1.655458] initcall acpi_thermal_init+0x0/0x42 returned -19 after 0 usecs
[    1.655466] calling  acpi_battery_init+0x0/0x16 @ 1
[    1.655478] initcall acpi_battery_init+0x0/0x16 returned 0 after 3 usecs
[    1.655486] calling  acpi_hed_driver_init+0x0/0x12 @ 1
[    1.655494] initcall acpi_hed_driver_init+0x0/0x12 returned -19 after 0 usecs
[    1.655502] calling  erst_init+0x0/0x2bb @ 1
[    1.655510] initcall erst_init+0x0/0x2bb returned 0 after 0 usecs
[    1.655518] calling  ghes_init+0x0/0x171 @ 1
[    1.655527] initcall ghes_init+0x0/0x171 returned -19 after 0 usecs
[    1.655535] calling  einj_init+0x0/0x49d @ 1
[    1.655543] initcall einj_init+0x0/0x49d returned -19 after 0 usecs
[    1.655551] calling  ioat_init_module+0x0/0x80 @ 1
[    1.655559] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    1.655595] calling  1_acpi_battery_init_async+0x0/0x1b @ 6
[    1.655603] initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 0 usecs
[    1.655672] initcall ioat_init_module+0x0/0x80 returned 0 after 109 usecs
[    1.655683] calling  virtio_mmio_init+0x0/0x12 @ 1
[    1.655766] initcall virtio_mmio_init+0x0/0x12 returned 0 after 72 usecs
[    1.655777] calling  init+0x0/0x12 @ 1
[    1.655855] initcall init+0x0/0x12 returned 0 after 67 usecs
[    1.655864] calling  xenbus_probe_initcall+0x0/0x39 @ 1
[    1.655873] initcall xenbus_probe_initcall+0x0/0x39 returned 0 after 0 usecs
[    1.655882] calling  xenbus_init+0x0/0x3d @ 1
[    1.655975] initcall xenbus_init+0x0/0x3d returned 0 after 81 usecs
[    1.655985] calling  xenbus_backend_init+0x0/0x51 @ 1
[    1.655993] initcall xenbus_backend_init+0x0/0x51 returned -19 after 0 usecs
[    1.656002] calling  gntdev_init+0x0/0x4d @ 1
[    1.656125] initcall gntdev_init+0x0/0x4d returned 0 after 111 usecs
[    1.656134] calling  gntalloc_init+0x0/0x3d @ 1
[    1.656209] initcall gntalloc_init+0x0/0x3d returned 0 after 66 usecs
[    1.656217] calling  hypervisor_subsys_init+0x0/0x25 @ 1
[    1.656225] initcall hypervisor_subsys_init+0x0/0x25 returned 0 after 0 usecs
[    1.656233] calling  hyper_sysfs_init+0x0/0xfb @ 1
[    1.656254] initcall hyper_sysfs_init+0x0/0xfb returned 0 after 13 usecs
[    1.656262] calling  platform_pci_module_init+0x0/0x1b @ 1
[    1.656336] initcall platform_pci_module_init+0x0/0x1b returned 0 after 64 usecs
[    1.656344] calling  xen_tmem_init+0x0/0x9a @ 1
[    1.656352] initcall xen_tmem_init+0x0/0x9a returned 0 after 0 usecs
[    1.656360] calling  xen_late_init_mcelog+0x0/0x3d @ 1
[    1.656367] initcall xen_late_init_mcelog+0x0/0x3d returned -19 after 0 usecs
[    1.656375] calling  xen_pcibk_init+0x0/0x13f @ 1
[    1.656383] initcall xen_pcibk_init+0x0/0x13f returned -19 after 0 usecs
[    1.854937] calling  xen_acpi_processor_init+0x0/0x41f @ 1
[    1.854949] initcall xen_acpi_processor_init+0x0/0x41f returned -19 after 0 usecs
[    1.854957] calling  pty_init+0x0/0x453 @ 1
[    1.890528] initcall pty_init+0x0/0x453 returned 0 after 34728 usecs
[    1.890543] calling  sysrq_init+0x0/0x78 @ 1
[    1.890557] initcall sysrq_init+0x0/0x78 returned 0 after 5 usecs
[    1.890564] calling  xen_hvc_init+0x0/0x249 @ 1
[    1.891318] initcall xen_hvc_init+0x0/0x249 returned 0 after 728 usecs
[    1.891328] calling  serial8250_init+0x0/0x17d @ 1
[    1.891335] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.891949] initcall serial8250_init+0x0/0x17d returned 0 after 598 usecs
[    1.891959] calling  serial_pci_driver_init+0x0/0x1b @ 1
[    1.892030] initcall serial_pci_driver_init+0x0/0x1b returned 0 after 62 usecs
[    1.892040] calling  init_kgdboc+0x0/0x16 @ 1
[    1.892048] initcall init_kgdboc+0x0/0x16 returned 0 after 0 usecs
[    1.892103] calling  rand_initialize+0x0/0x30 @ 1
[    1.892125] initcall rand_initialize+0x0/0x30 returned 0 after 10 usecs
[    1.892135] calling  init+0x0/0x111 @ 1
[    1.892349] initcall init+0x0/0x111 returned 0 after 201 usecs
[    1.892358] calling  hpet_init+0x0/0x6a @ 1
[    1.892517] initcall hpet_init+0x0/0x6a returned -19 after 147 usecs
[    1.892526] calling  nvram_init+0x0/0x82 @ 1
[    1.892602] Non-volatile memory driver v1.3
[    1.892610] initcall nvram_init+0x0/0x82 returned 0 after 74 usecs
[    1.892618] calling  mod_init+0x0/0x5a @ 1
[    1.892625] initcall mod_init+0x0/0x5a returned -19 after 0 usecs
[    1.892633] calling  rng_init+0x0/0x12 @ 1
[    1.892709] initcall rng_init+0x0/0x12 returned 0 after 66 usecs
[    1.892718] calling  agp_init+0x0/0x26 @ 1
[    1.892725] Linux agpgart interface v0.103
[    1.892732] initcall agp_init+0x0/0x26 returned 0 after 6 usecs
[    1.892739] calling  agp_amd64_mod_init+0x0/0x22 @ 1
[    1.892876] initcall agp_amd64_mod_init+0x0/0x22 returned -19 after 125 usecs
[    1.892885] calling  agp_intel_init+0x0/0x29 @ 1
[    1.892955] initcall agp_intel_init+0x0/0x29 returned 0 after 60 usecs
[    1.892964] calling  agp_sis_init+0x0/0x29 @ 1
[    1.893035] initcall agp_sis_init+0x0/0x29 returned 0 after 61 usecs
[    1.893043] calling  agp_via_init+0x0/0x29 @ 1
[    1.893136] initcall agp_via_init+0x0/0x29 returned 0 after 83 usecs
[    1.893144] calling  drm_core_init+0x0/0x139 @ 1
[    1.893223] [drm] Initialized drm 1.1.0 20060810
[    1.893231] initcall drm_core_init+0x0/0x139 returned 0 after 77 usecs
[    1.893239] calling  cn_proc_init+0x0/0x3d @ 1
[    1.893247] initcall cn_proc_init+0x0/0x3d returned 0 after 1 usecs
[    1.893256] calling  topology_sysfs_init+0x0/0x58 @ 1
[    1.893274] initcall topology_sysfs_init+0x0/0x58 returned 0 after 9 usecs
[    1.893282] calling  loop_init+0x0/0x137 @ 1
[    1.895048] loop: module loaded
[    1.895089] initcall loop_init+0x0/0x137 returned 0 after 1757 usecs
p[    1.895098] calling  xen_blkif_init+0x0/0x25f @ 1
[    1.895308] initcall xen_blkif_init+0x0/0x25f returned 0 after 197 usecs
[    1.895316] calling  mac_hid_init+0x0/0x22 @ 1
[    1.895328] initcall mac_hid_init+0x0/0x22 returned 0 after 4 usecs
[    1.895336] calling  macvlan_init_module+0x0/0x3d @ 1
[    1.895345] initcall macvlan_init_module+0x0/0x3d returned 0 after 1 usecs
[    1.895353] calling  macvtap_init+0x0/0x100 @ 1
[    1.895419] initcall macvtap_init+0x0/0x100 returned 0 after 56 usecs
[    1.895427] calling  net_olddevs_init+0x0/0x86 @ 1
[    1.895436] initcall net_olddevs_init+0x0/0x86 returned 0 after 1 usecs
[    1.895444] calling  fixed_mdio_bus_init+0x0/0x105 @ 1
[    1.895589] libphy: Fixed MDIO Bus: probed
[    1.895597] initcall fixed_mdio_bus_init+0x0/0x105 returned 0 after 141 usecs
[    1.895605] calling  tun_init+0x0/0x93 @ 1
[    1.895612] tun: Universal TUN/TAP device driver, 1.6
[    1.895618] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.895698] initcall tun_init+0x0/0x93 returned 0 after 83 usecs
[    1.895706] calling  tg3_init+0x0/0x1b @ 1
[    1.895780] initcall tg3_init+0x0/0x1b returned 0 after 65 usecs
[    1.895788] calling  ixgbevf_init_module+0x0/0x4c @ 1
[    2.055322] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k
[    2.055332] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    2.055427] initcall ixgbevf_init_module+0x0/0x4c returned 0 after 101 usecs
[    2.055436] calling  init_nic+0x0/0x1b @ 1
[    2.055512] initcall init_nic+0x0/0x1b returned 0 after 66 usecs
[    2.055521] calling  netback_init+0x0/0x212 @ 1
[    2.055638] initcall netback_init+0x0/0x212 returned 0 after 106 usecs
[    2.055647] calling  nonstatic_sysfs_init+0x0/0x12 @ 1
[    2.055656] initcall nonstatic_sysfs_init+0x0/0x12 returned 0 after 1 usecs
[    2.055664] calling  yenta_socket_init+0x0/0x1b @ 1
[    2.055744] initcall yenta_socket_init+0x0/0x1b returned 0 after 70 usecs
[    2.055754] calling  mon_init+0x0/0xfe @ 1
[    2.055909] initcall mon_init+0x0/0xfe returned 0 after 144 usecs
[    2.055918] calling  ehci_hcd_init+0x0/0xb7 @ 1
[    2.055925] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.055933] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    2.055951] initcall ehci_hcd_init+0x0/0xb7 returned 0 after 24 usecs
[    2.055959] calling  ehci_pci_init+0x0/0x69 @ 1
[    2.055966] ehci-pci: EHCI PCI platform driver
[    2.056038] initcall ehci_pci_init+0x0/0x69 returned 0 after 68 usecs
[    2.056047] calling  ohci_hcd_mod_init+0x0/0xbf @ 1
[    2.056086] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.056094] ohci_hcd: block sizes: ed 80 td 96
[    2.056181] initcall ohci_hcd_mod_init+0x0/0xbf returned 0 after 92 usecs
[    2.056190] calling  uhci_hcd_init+0x0/0x129 @ 1
[    2.056197] uhci_hcd: USB Universal Host Controller Interface driver
[    2.056290] initcall uhci_hcd_init+0x0/0x129 returned 0 after 89 usecs
[    2.056299] calling  usblp_driver_init+0x0/0x1b @ 1
[    2.056375] usbcore: registered new interface driver usblp
[    2.056384] initcall usblp_driver_init+0x0/0x1b returned 0 after 75 usecs
[    2.056393] calling  kgdbdbgp_start_thread+0x0/0x4f @ 1
[    2.056401] initcall kgdbdbgp_start_thread+0x0/0x4f returned 0 after 0 usecs
[    2.056409] calling  i8042_init+0x0/0x3c5 @ 1
[    2.056657] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    3.068374] i8042: No controller found
[    3.068394] initcall i8042_init+0x0/0x3c5 returned -19 after 988256 usecs
[    3.068403] calling  serport_init+0x0/0x34 @ 1
[    3.068412] initcall serport_init+0x0/0x34 returned 0 after 1 usecs
[    3.068420] calling  mousedev_init+0x0/0x62 @ 1
[    3.068590] mousedev: PS/2 mouse device common for all mice
[    3.068600] initcall mousedev_init+0x0/0x62 returned 0 after 167 usecs
[    3.068608] calling  evdev_init+0x0/0x12 @ 1
[    3.068617] initcall evdev_init+0x0/0x12 returned 0 after 0 usecs
[    3.068625] calling  atkbd_init+0x0/0x27 @ 1
[    3.068713] initcall atkbd_init+0x0/0x27 returned 0 after 78 usecs
[    3.068724] calling  psmouse_init+0x0/0x7b @ 1
[    3.068871] initcall psmouse_init+0x0/0x7b returned 0 after 132 usecs
[    3.068888] calling  cmos_init+0x0/0x6a @ 1
[    3.129156] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    3.129267] rtc_cmos: probe of rtc_cmos failed with error -38
[    3.129462] initcall cmos_init+0x0/0x6a returned -19 after 59144 usecs
[    3.129471] calling  i2c_i801_init+0x0/0xad @ 1
[    3.129552] initcall i2c_i801_init+0x0/0xad returned 0 after 70 usecs
ow[    3.129562] calling  cpufreq_gov_dbs_init+0x0/0x95 @ 1
[    3.129571] initcall cpufreq_gov_dbs_init+0x0/0x95 returned -19 after 1 usecs
[    3.129580] calling  init_ladder+0x0/0x12 @ 1
[    3.129588] initcall init_ladder+0x0/0x12 returned -19 after 0 usecs
[    3.129596] calling  init_menu+0x0/0x12 @ 1
[    3.129603] initcall init_menu+0x0/0x12 returned -19 after 0 usecs
[    3.129612] calling  efivars_init+0x0/0x105 @ 1
[    3.129619] EFI Variables Facility v0.08 2004-May-17
[    3.129626] initcall efivars_init+0x0/0x105 returned 0 after 6 usecs
[    3.129635] calling  vhost_net_init+0x0/0x30 @ 1
[    3.129714] initcall vhost_net_init+0x0/0x30 returned 0 after 68 usecs
[    3.129723] calling  staging_init+0x0/0x8 @ 1
[    3.129731] initcall staging_init+0x0/0x8 returned 0 after 0 usecs
[    3.129739] calling  zram_init+0x0/0x2e4 @ 1
[    3.129746] zram: num_devices not specified. Using default: 1
[    3.129753] zram: Creating 1 devices ...
[    3.130028] initcall zram_init+0x0/0x2e4 returned 0 after 273 usecs
[    3.130038] calling  zcache_init+0x0/0x297 @ 1
[    3.130115] initcall zcache_init+0x0/0x297 returned 0 after 67 usecs
[    3.130127] calling  zs_init+0x0/0x90 @ 1
[    3.130139] initcall zs_init+0x0/0x90 returned 0 after 3 usecs
[    3.130149] calling  eeepc_laptop_init+0x0/0x58 @ 1
[    3.130320] initcall eeepc_laptop_init+0x0/0x58 returned -19 after 157 usecs
[    3.130331] calling  sock_diag_init+0x0/0x12 @ 1
[    3.130347] initcall sock_diag_init+0x0/0x12 returned 0 after 8 usecs
[    3.130355] calling  flow_cache_init_global+0x0/0x19f @ 1
[    3.130373] initcall flow_cache_init_global+0x0/0x19f returned 0 after 10 usecs
[    3.130382] calling  llc_init+0x0/0x20 @ 1
[    3.130390] initcall llc_init+0x0/0x20 returned 0 after 1 usecs
[    3.130397] calling  snap_init+0x0/0x38 @ 1
[    3.130408] initcall snap_init+0x0/0x38 returned 0 after 1 usecs
[    3.130417] calling  blackhole_module_init+0x0/0x12 @ 1
[    3.130427] initcall blackhole_module_init+0x0/0x12 returned 0 after 0 usecs
[    3.130436] calling  nfnetlink_init+0x0/0x27 @ 1
[    3.130444] Netfilter messages via NETLINK v0.30.
[    3.130464] initcall nfnetlink_init+0x0/0x27 returned 0 after 18 usecs
[    3.130474] calling  nfnetlink_log_init+0x0/0xdb @ 1
[    3.130491] initcall nfnetlink_log_init+0x0/0xdb returned 0 after 9 usecs
[    3.130499] calling  nf_conntrack_standalone_init+0x0/0x12 @ 1
[    3.130507] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    3.130600] initcall nf_conntrack_standalone_init+0x0/0x12 returned 0 after 90 usecs
[    3.130609] calling  ctnetlink_init+0x0/0xa4 @ 1
[    3.130616] ctnetlink v0.93: registering with nfnetlink.
[    3.130623] initcall ctnetlink_init+0x0/0xa4 returned 0 after 6 usecs
[    3.130631] calling  nf_conntrack_ftp_init+0x0/0x1ca @ 1
[    3.130639] initcall nf_conntrack_ftp_init+0x0/0x1ca returned 0 after 0 usecs
[    3.130647] calling  nf_conntrack_irc_init+0x0/0x173 @ 1
[    3.130658] initcall nf_conntrack_irc_init+0x0/0x173 returned 0 after 3 usecs
[    3.130666] calling  nf_conntrack_sip_init+0x0/0x215 @ 1
[    3.130675] initcall nf_conntrack_sip_init+0x0/0x215 returned 0 after 0 usecs
[    3.130683] calling  xt_init+0x0/0x118 @ 1
[    3.130693] initcall xt_init+0x0/0x118 returned 0 after 1 usecs
[    3.130701] calling  tcpudp_mt_init+0x0/0x17 @ 1
[    3.130709] initcall tcpudp_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.130717] calling  connsecmark_tg_init+0x0/0x12 @ 1
[    3.268638] initcall connsecmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268647] calling  nflog_tg_init+0x0/0x12 @ 1
[    3.268656] initcall nflog_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268664] calling  secmark_tg_init+0x0/0x12 @ 1
[    3.268671] initcall secmark_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.268679] calling  tcpmss_tg_init+0x0/0x17 @ 1
[    3.268687] initcall tcpmss_tg_init+0x0/0x17 returned 0 after 0 usecs
[    3.268696] calling  conntrack_mt_init+0x0/0x17 @ 1
[    3.268707] initcall conntrack_mt_init+0x0/0x17 returned 0 after 0 usecs
er[    3.268715] calling  policy_mt_init+0x0/0x17 @ 1
[    3.268723] initcall policy_mt_init+0x0/0x17 returned 0 after 0 usecs
[    3.268730] calling  state_mt_init+0x0/0x12 @ 1
[    3.268738] initcall state_mt_init+0x0/0x12 returned 0 after 0 usecs
[    3.268746] calling  sysctl_ipv4_init+0x0/0x92 @ 1
[    3.268793] initcall sysctl_ipv4_init+0x0/0x92 returned 0 after 37 usecs
[    3.268804] calling  init_syncookies+0x0/0x19 @ 1
[    3.268835] initcall init_syncookies+0x0/0x19 returned 0 after 21 usecs
[    3.268845] calling  tunnel4_init+0x0/0x72 @ 1
[    3.268854] initcall tunnel4_init+0x0/0x72 returned 0 after 0 usecs
[    3.268865] calling  ipv4_netfilter_init+0x0/0x12 @ 1
[    3.268876] initcall ipv4_netfilter_init+0x0/0x12 returned 0 after 0 usecs
[    3.268886] calling  nf_conntrack_l3proto_ipv4_init+0x0/0xb8 @ 1
[    3.269010] initcall nf_conntrack_l3proto_ipv4_init+0x0/0xb8 returned 0 after 110 usecs
[    3.269021] calling  nf_defrag_init+0x0/0x17 @ 1
[    3.269029] initcall nf_defrag_init+0x0/0x17 returned 0 after 0 usecs
[    3.269037] calling  ip_tables_init+0x0/0xaa @ 1
[    3.269064] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.269072] initcall ip_tables_init+0x0/0xaa returned 0 after 26 usecs
[    3.269083] calling  iptable_filter_init+0x0/0x51 @ 1
[    3.269107] initcall iptable_filter_init+0x0/0x51 returned 0 after 13 usecs
[    3.269118] calling  iptable_mangle_init+0x0/0x51 @ 1
[    3.269139] initcall iptable_mangle_init+0x0/0x51 returned 0 after 10 usecs
[    3.269150] calling  reject_tg_init+0x0/0x12 @ 1
[    3.269159] initcall reject_tg_init+0x0/0x12 returned 0 after 0 usecs
[    3.269169] calling  ulog_tg_init+0x0/0x104 @ 1
[    3.269184] initcall ulog_tg_init+0x0/0x104 returned 0 after 5 usecs
[    3.269195] calling  cubictcp_register+0x0/0x5c @ 1
[    3.269204] TCP: cubic registered
[    3.269213] initcall cubictcp_register+0x0/0x5c returned 0 after 9 usecs
[    3.269221] calling  xfrm_user_init+0x0/0x4a @ 1
[    3.269230] Initializing XFRM netlink socket
[    3.269244] initcall xfrm_user_init+0x0/0x4a returned 0 after 12 usecs
[    3.269255] calling  inet6_init+0x0/0x315 @ 1
[    3.269288] NET: Registered protocol family 10
[    3.269523] initcall inet6_init+0x0/0x315 returned 0 after 252 usecs
[    3.269532] calling  ah6_init+0x0/0x79 @ 1
[    3.269539] initcall ah6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269547] calling  esp6_init+0x0/0x79 @ 1
[    3.269555] initcall esp6_init+0x0/0x79 returned 0 after 0 usecs
[    3.269563] calling  xfrm6_transport_init+0x0/0x17 @ 1
[    3.269571] initcall xfrm6_transport_init+0x0/0x17 returned 0 after 0 usecs
[    3.269579] calling  xfrm6_mode_tunnel_init+0x0/0x17 @ 1
[    3.269587] initcall xfrm6_mode_tunnel_init+0x0/0x17 returned 0 after 0 usecs
[    3.269595] calling  xfrm6_beet_init+0x0/0x17 @ 1
[    3.269602] initcall xfrm6_beet_init+0x0/0x17 returned 0 after 0 usecs
[    3.269610] calling  ip6_tables_init+0x0/0xaa @ 1
[    3.269627] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    3.269635] initcall ip6_tables_init+0x0/0xaa returned 0 after 16 usecs
[    3.269643] calling  ip6table_filter_init+0x0/0x51 @ 1
[    3.269764] initcall ip6table_filter_init+0x0/0x51 returned 0 after 110 usecs
[    3.269773] calling  ip6table_mangle_init+0x0/0x51 @ 1
[    3.269822] initcall ip6table_mangle_init+0x0/0x51 returned 0 after 40 usecs
[    3.269831] calling  nf_conntrack_l3proto_ipv6_init+0x0/0x8a @ 1
[    3.269846] initcall nf_conntrack_l3proto_ipv6_init+0x0/0x8a returned 0 after 6 usecs
[    3.269855] calling  nf_defrag_init+0x0/0x54 @ 1
[    3.269868] initcall nf_defrag_init+0x0/0x54 returned 0 after 5 usecs
[    3.269876] calling  ipv6header_mt6_init+0x0/0x12 @ 1
[    3.269884] initcall ipv6header_mt6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269892] calling  reject_tg6_init+0x0/0x12 @ 1
[    3.269900] initcall reject_tg6_init+0x0/0x12 returned 0 after 0 usecs
[    3.269908] calling  sit_init+0x0/0x8c @ 1
[    3.269914] sit: IPv6 over IPv4 tunneling driver
[    3.270252] initcall sit_init+0x0/0x8c returned 0 after 329 usecs
[    3.270261] calling  packet_init+0x0/0x47 @ 1
[    3.270268] NET: Registered protocol family 17
[    3.270280] initcall packet_init+0x0/0x47 returned 0 after 11 usecs
[    3.468657] calling  br_init+0x0/0xa2 @ 1
of[    3.468683] initcall br_init+0x0/0xa2 returned 0 after 16 usecs
[    3.468691] calling  init_rpcsec_gss+0x0/0x64 @ 1
[    3.468734] initcall init_rpcsec_gss+0x0/0x64 returned 0 after 32 usecs
[    3.468745] calling  dcbnl_init+0x0/0x4d @ 1
[    3.468756] initcall dcbnl_init+0x0/0x4d returned 0 after 0 usecs
[    3.468765] calling  init_dns_resolver+0x0/0xe4 @ 1
[    3.468790] Key type dns_resolver registered
[    3.468801] initcall init_dns_resolver+0x0/0xe4 returned 0 after 23 usecs
[    3.468812] calling  mcheck_init_device+0x0/0x123 @ 1
[    3.468822] initcall mcheck_init_device+0x0/0x123 returned -5 after 0 usecs
[    3.468833] initcall mcheck_init_device+0x0/0x123 returned with error code -5 
[    3.468865] calling  tboot_late_init+0x0/0x216 @ 1
[    3.468875] initcall tboot_late_init+0x0/0x216 returned 0 after 0 usecs
[    3.468885] calling  mcheck_debugfs_init+0x0/0x3c @ 1
[    3.468915] initcall mcheck_debugfs_init+0x0/0x3c returned 0 after 19 usecs
[    3.468923] calling  severities_debugfs_init+0x0/0x3c @ 1
[    3.468942] initcall severities_debugfs_init+0x0/0x3c returned 0 after 7 usecs
[    3.468954] calling  threshold_init_device+0x0/0x8d @ 1
[    3.468964] initcall threshold_init_device+0x0/0x8d returned 0 after 0 usecs
[    3.468975] calling  hpet_insert_resource+0x0/0x23 @ 1
[    3.468985] initcall hpet_insert_resource+0x0/0x23 returned 1 after 0 usecs
[    3.468995] initcall hpet_insert_resource+0x0/0x23 returned with error code 1 
[    3.469007] calling  update_mp_table+0x0/0x56d @ 1
[    3.469018] initcall update_mp_table+0x0/0x56d returned 0 after 0 usecs
[    3.469028] calling  lapic_insert_resource+0x0/0x3f @ 1
[    3.469037] initcall lapic_insert_resource+0x0/0x3f returned -1 after 0 usecs
[    3.469047] initcall lapic_insert_resource+0x0/0x3f returned with error code -1 
[    3.469072] calling  io_apic_bug_finalize+0x0/0x1b @ 1
[    3.469083] initcall io_apic_bug_finalize+0x0/0x1b returned 0 after 0 usecs
[    3.469092] calling  print_ICs+0x0/0x508 @ 1
[    3.469102] initcall print_ICs+0x0/0x508 returned 0 after 0 usecs
[    3.469112] calling  check_early_ioremap_leak+0x0/0x65 @ 1
[    3.469122] initcall check_early_ioremap_leak+0x0/0x65 returned 0 after 0 usecs
[    3.469133] calling  pat_memtype_list_init+0x0/0x32 @ 1
[    3.469156] initcall pat_memtype_list_init+0x0/0x32 returned 0 after 13 usecs
[    3.469169] calling  init_oops_id+0x0/0x40 @ 1
[    3.469189] initcall init_oops_id+0x0/0x40 returned 0 after 4 usecs
[    3.469199] calling  printk_late_init+0x0/0x59 @ 1
[    3.469211] initcall printk_late_init+0x0/0x59 returned 0 after 1 usecs
[    3.469220] calling  pm_qos_power_init+0x0/0x7b @ 1
[    3.469460] initcall pm_qos_power_init+0x0/0x7b returned 0 after 223 usecs
[    3.469469] calling  pm_debugfs_init+0x0/0x24 @ 1
[    3.469483] initcall pm_debugfs_init+0x0/0x24 returned 0 after 6 usecs
[    3.469492] calling  software_resume+0x0/0x290 @ 1
[    3.469499] PM: Hibernation image not present or could not be loaded.
[    3.469507] initcall software_resume+0x0/0x290 returned -2 after 7 usecs
[    3.469515] initcall software_resume+0x0/0x290 returned with error code -2 
[    3.469524] calling  debugfs_kprobe_init+0x0/0x90 @ 1
[    3.469551] initcall debugfs_kprobe_init+0x0/0x90 returned 0 after 19 usecs
[    3.469559] calling  taskstats_init+0x0/0x95 @ 1
[    3.469570] registered taskstats version 1
[    3.469577] initcall taskstats_init+0x0/0x95 returned 0 after 10 usecs
[    3.469585] calling  clear_boot_tracer+0x0/0x2d @ 1
[    3.469593] initcall clear_boot_tracer+0x0/0x2d returned 0 after 0 usecs
[    3.469601] calling  max_swapfiles_check+0x0/0x8 @ 1
[    3.469608] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs
[    3.469617] calling  set_recommended_min_free_kbytes+0x0/0xa0 @ 1
[    3.469625] initcall set_recommended_min_free_kbytes+0x0/0xa0 returned 0 after 0 usecs
[    3.469634] calling  fail_make_request_debugfs+0x0/0x2a @ 1
[    3.469692] initcall fail_make_request_debugfs+0x0/0x2a returned 0 after 49 usecs
[    3.469701] calling  prandom_reseed+0x0/0xb4 @ 1
[    3.469722] initcall prandom_reseed+0x0/0xb4 returned 0 after 13 usecs
[    3.469730] calling  pci_resource_alignment_sysfs_init+0x0/0x19 @ 1
[    3.469740] initcall pci_resource_alignment_sysfs_init+0x0/0x19 returned 0 after 1 usecs
[    3.469748] calling  pci_sysfs_init+0x0/0x51 @ 1
[    3.469757] initcall pci_sysfs_init+0x0/0x51 returned 0 after 1 usecs
[    3.469765] calling  boot_wait_for_devices+0x0/0x30 @ 1
[    3.669552] XENBUS: Device with no driver: device/vif/0
[    3.669562] initcall boot_wait_for_devices+0x0/0x30 returned 0 after 12 usecs
[    3.669575] calling  random_int_secret_init+0x0/0x19 @ 1
[    3.669594] initcall random_int_secret_init+0x0/0x19 returned 0 after 10 usecs
[    3.669604] calling  deferred_probe_initcall+0x0/0x60 @ 1
[    3.669664] initcall deferred_probe_initcall+0x0/0x60 returned 0 after 50 usecs
f[    3.669681] calling  late_resume_init+0x0/0x1d0 @ 1
[    3.669690]   Magic number: 1:252:3141
[    3.669768] initcall late_resume_init+0x0/0x1d0 returned 0 after 75 usecs
[    3.669778] calling  firmware_memmap_init+0x0/0x38 @ 1
[    3.669805] initcall firmware_memmap_init+0x0/0x38 returned 0 after 18 usecs
[    3.669815] calling  pci_mmcfg_late_insert_resources+0x0/0x50 @ 1
[    3.669824] initcall pci_mmcfg_late_insert_resources+0x0/0x50 returned 0 after 0 usecs
[    3.669835] calling  net_secret_init+0x0/0x19 @ 1
[    3.669857] initcall net_secret_init+0x0/0x19 returned 0 after 11 usecs
[    3.669866] calling  tcp_congestion_default+0x0/0x12 @ 1
[    3.669878] initcall tcp_congestion_default+0x0/0x12 returned 0 after 1 usecs
[    3.669889] calling  tcp_fastopen_init+0x0/0x30 @ 1
[    3.669910] initcall tcp_fastopen_init+0x0/0x30 returned 0 after 11 usecs
[    3.669921] calling  ip_auto_config+0x0/0xe62 @ 1
[    3.669937] initcall ip_auto_config+0x0/0xe62 returned 0 after 5 usecs
[    3.669947] calling  initialize_hashrnd+0x0/0x19 @ 1
[    3.669961] initcall initialize_hashrnd+0x0/0x19 returned 0 after 4 usecs
[    3.670862] Freeing unused kernel memory: 756k freed
[    3.671087] Write protecting the kernel read-only data: 10240k
[    3.677203] Freeing unused kernel memory: 1620k freed
[    3.677696] Freeing unused kernel memory: 136k freed
[    3.683393] consoletype (1029) used greatest stack depth: 5288 bytes left
[    3.991865] calling  privcmd_init+0x0/0x1000 [xen_privcmd] @ 1058
[    3.991978] initcall privcmd_init+0x0/0x1000 [xen_privcmd] returned 0 after 93 usecs
[    3.992361] calling  xenfs_init+0x0/0x1000 [xenfs] @ 1058
[    3.992373] initcall xenfs_init+0x0/0x1000 [xenfs] returned 0 after 1 usecs
[    3.992538] modprobe (1058) used greatest stack depth: 5272 bytes left
[    4.003403] core_filesystem (1030) used greatest stack depth: 4984 bytes left
[    4.012398] calling  xenkbd_init+0x0/0x1000 [xen_kbdfront] @ 1069
[    4.012500] initcall xenkbd_init+0x0/0x1000 [xen_kbdfront] returned 0 after 84 usecs
[    4.015993] calling  xenfb_init+0x0/0x1000 [xen_fbfront] @ 1072
[    4.016125] initcall xenfb_init+0x0/0x1000 [xen_fbfront] returned 0 after 113 usecs
[    4.019032] calling  netif_init+0x0/0x1000 [xen_netfront] @ 1079
[    4.019044] Initialising Xen virtual ethernet driver.
[    4.119124] initcall netif_init+0x0/0x1000 [xen_netfront] returned 0 after 97731 usecs
[    4.121939] calling  xlblk_init+0x0/0x1000 [xen_blkfront] @ 1085
[    4.122045] initcall xlblk_init+0x0/0x1000 [xen_blkfront] returned 0 after 87 usecs
[    4.136417] udevd (1091): /proc/1091/oom_adj is deprecated, please use /proc/1091/oom_score_adj instead.
[    4.190158] calling  crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] @ 1112
[    4.190457] initcall crc32c_intel_mod_init+0x0/0x1000 [crc32c_intel] returned 0 after 273 usecs
[    4.294865] ip (1240) used greatest stack depth: 3896 bytes left
[    4.617936] calling  drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] @ 1861
[    4.618103] initcall drm_fb_helper_modinit+0x0/0x1000 [drm_kms_helper] returned 0 after 143 usecs
[    4.622178] calling  ttm_init+0x0/0x1000 [ttm] @ 1861
[    4.622835] initcall ttm_init+0x0/0x1000 [ttm] returned 0 after 623 usecs
[    4.638477] calling  radeon_init+0x0/0x1000 [radeon] @ 1861
[    4.638494] [drm] radeon kernel modesetting enabled.
[    4.639366] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 831 usecs
[    4.644900] calling  acpi_wmi_init+0x0/0x1000 [wmi] @ 1872
[    4.644911] initcall acpi_wmi_init+0x0/0x1000 [wmi] returned -19 after 0 usecs
[    4.645279] calling  fb_console_init+0x0/0x1000 [fbcon] @ 1863
[    4.648295] initcall fb_console_init+0x0/0x1000 [fbcon] returned 0 after 2934 usecs
[    4.648680] calling  acpi_video_init+0x0/0xfee [video] @ 1877
[    4.648692] initcall acpi_video_init+0x0/0xfee [video] returned -19 after 1 usecs
[    4.919737] device eth0 entered promiscuous mode
[    4.973883] switch: port 1(eth0) entered forwarding state
[    4.973901] switch: port 1(eth0) entered forwarding state
[    7.304760] calling  crc32c_mod_init+0x0/0x1000 [crc32c] @ 2192
[    7.304839] initcall crc32c_mod_init+0x0/0x1000 [crc32c] returned 0 after 60 usecs
[    7.307385] calling  libcrc32c_mod_init+0x0/0x1000 [libcrc32c] @ 2195
[    7.307403] initcall libcrc32c_mod_init+0x0/0x1000 [libcrc32c] returned 0 after 2 usecs
[    7.313643] calling  init_scsi+0x0/0x91 [scsi_mod] @ 2197
[    7.314342] SCSI subsystem initialized
[    7.314356] initcall init_scsi+0x0/0x91 [scsi_mod] returned 0 after 679 usecs
[    7.316111] calling  iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] @ 2197
[    7.316129] Loading iSCSI transport class v2.0-870.
[    7.317289] initcall iscsi_transport_init+0x0/0x1000 [scsi_transport_iscsi] returned 0 after 1129 usecs
[    7.319114] calling  iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] @ 2197
[    7.319320] iscsi: registered transport (tcp)
[    7.319329] initcall iscsi_sw_tcp_init+0x0/0x1000 [iscsi_tcp] returned 0 after 198 usecs
[    7.371756] calling  evtchn_init+0x0/0x1000 [xen_evtchn] @ 2237
[    7.372190] Event-channel device installed.
[    7.372199] initcall evtchn_init+0x0/0x1000 [xen_evtchn] returned 0 after 420 usecs
[    7.471343] mount.nfs (2258) used greatest stack depth: 3480 bytes left
[    8.469522] calling  dm_init+0x0/0x48 [dm_mod] @ 2272
[    8.470002] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[    8.470021] initcall dm_init+0x0/0x48 [dm_mod] returned 0 after 467 usecs
[    8.471073] calling  dm_multipath_init+0x0/0x1000 [dm_multipath] @ 2272
[    8.471163] device-mapper: multipath: version 1.5.0 loaded
[    8.471175] initcall dm_multipath_init+0x0/0x1000 [dm_multipath] returned 0 after 83 usecs
[    8.734032] scsi0 : iSCSI Initiator over TCP/IP
[    8.991392] scsi 0:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[    8.995124] calling  init_sd+0x0/0x1000 [sd_mod] @ 2290
[    8.995995] initcall init_sd+0x0/0x1000 [sd_mod] returned 0 after 833 usecs
[    8.999267] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    8.999841] sd 0:0:0:0: [sda] Write Protect is off
[    8.999852] sd 0:0:0:0: [sda] Mode Sense: 2f 00 00 00
[    9.000230] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    9.003886]  sda: unknown partition table
[    9.005627] sd 0:0:0:0: [sda] Attached SCSI disk
[    9.008859] calling  init_sg+0x0/0x1000 [sg] @ 2303
[    9.009224] sd 0:0:0:0: Attached scsi generic sg0 type 0

[    9.009265] initcall init_sg+0x0/0x1000 [sg] returned 0 after 380 usecs
[   14.059832] bio: create slab <bio-1> at 1
[   20.000116] switch: port 1(eth0) entered forwarding state
# poweroff
Feb 22 21:47:09 g-pvops init: starting pid 2464, tty '': '/etc/init.d/halt'
# Usage: /etc/init.d/halt {start}
The system is going down NOW!
Sent SIGTERM to all processes
Feb 22 21:47:09 g-pvops exiting on signal 15
Sent SIGKILL to all processes
Requesting system poweroff
[   44.590513] sd 0:0:0:0: shutdown
[   44.590947] vif vif-0: shutdown
[   44.603898] PM: Calling i8259A_shutdown+0x0/0x10
[   44.603928] System halted.
Parsing config from test.xm
Daemon running with PID 6859

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 23:40:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 23: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 1U92D6-0005aQ-VX; Fri, 22 Feb 2013 23:39:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U92D4-0005aL-S8
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 23:39:23 +0000
Received: from [85.158.139.83:35931] by server-11.bemta-5.messagelabs.com id
	16/AE-19159-AA108215; Fri, 22 Feb 2013 23:39:22 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361576357!24195871!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29892 invoked from network); 22 Feb 2013 23:39:18 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 23:39:18 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so1399728iea.22
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 15:38:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SQ0fB3lGFSqmQ24eYgkVPU/qgf8+xiX99XIYZp13G+k=;
	b=OXAU1nBlPSETjhKUsHLVdV2oTxq2dXrwOb1aYrn4TltZGd2xwITBLFN3+YNhlh6a8T
	3jnvixby4cNwJJy079juNY+I/WeBvzVhODEcYZZPE/PWEqU2a0gXKPwWy681tHQFpaGw
	zP+APoW3b2EmeejgUlBTOrhkNw9aEaS9XmTlbM+oGg5m10Wx0GWfbmBYlIGHL0GaCCWb
	xkxOeMDw0wOmfGmxdSAXyVTvK2pvFVen1y3FdhDpppALeiCa6lh7ENITh4n8kWdoJvHL
	puvSfbugvHeEbBU3aB5Y6pNw4j+4mPola14oCuVJ1T1XXeC1vPkLfClO3bKgdPwi3/yj
	5B1g==
MIME-Version: 1.0
X-Received: by 10.50.168.41 with SMTP id zt9mr99846igb.42.1361576298198; Fri,
	22 Feb 2013 15:38:18 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 15:38:18 -0800 (PST)
In-Reply-To: <20130222214811.GA25445@phenom.dumpdata.com>
References: <20130222214811.GA25445@phenom.dumpdata.com>
Date: Fri, 22 Feb 2013 15:38:18 -0800
X-Google-Sender-Auth: yuXU6wXPkdAQLax99S9LDl0qdGM
Message-ID: <CAE9FiQUjj_bqF0aLVHDg01rc+A-1xKMuFc0yHN6Tqnxc5A-h3g@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: rafael.j.wysocki@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Regression introduced by
 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device
 objects from probing ACPI drivers) in v3.9-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 1:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Hey Rafael,
>
> Per git bisect it looks like that patch:
> ACPI: Separate adding ACPI device objects from probing ACPI drivers
> blows up when running under Xen PV guests:
>
> (please notice that ACPI is turned off with normal Xen PV guests):
> 547 #ifdef CONFIG_ACPI
> 548         if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> 549                 printk(KERN_INFO "ACPI in unprivileged domain disabled\n");
> 550                 disable_acpi();
> 551         }
> 552 #endif
>
> (in arch/x86/xen/setup.c). Here is what the console tells me
> (I can't get the early console somehow to work):
>
> [    0.000000] console [hvc0] enabled, bootconsole disabled
> [    0.000000] Xen: using vcpuop timer interface
> [    0.000000] installing Xen timer for CPU 0
> [    0.000000] tsc: Detected 3901.188 MHz processor
> [    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
> [    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
> [    0.001000] pid_max: default: 32768 minimum: 301
> [    0.001000] Security Framework initialized
> [    0.001000] SELinux:  Initializing.
> [    0.001000] SELinux:  Starting in permissive mode
> [    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> [    0.001224] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [    0.001488] Mount-cache hash table entries: 256
> [    0.001774] Initializing cgroup subsys cpuacct
> [    0.001782] Initializing cgroup subsys freezer
> [    0.001860] tseg: 00adf00000
> [    0.001868] CPU: Physical Processor ID: 0
> [    0.001874] CPU: Processor Core ID: 1
> [    0.001883] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
> [    0.001883] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
> [    0.001883] tlb_flushall_shift: 5
> [    0.028911] cpu 0 spinlock event irq 17
> [    0.028956] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
> [    0.028966] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
> [    0.028976] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
> [    0.028986] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
> [    0.028997] calling  init_hw_perf_events+0x0/0x414 @ 1
> [    0.029000] Performance Events:
> [    0.029000] perf: AMD core performance counters detected
> [    0.029000] no APIC, boot with the "lapic" boot parameter to force-enable it.
> [    0.029000] no hardware sampling interrupt available.
> [    0.029000] Broken PMU hardware detected, using software events only.
> [    0.029005] Failed to access perfctr msr (MSR c0010201 is 0)
> [    0.029014] initcall init_hw_perf_events+0x0/0x414 returned 0 after 976 usecs
> [    0.029024] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
> [    0.029034] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
> [    0.029044] calling  spawn_ksoftirqd+0x0/0x28 @ 1
> [    0.029093] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
> [    0.029103] calling  init_workqueues+0x0/0x33a @ 1
> [    0.029316] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
> [    0.029327] calling  migration_init+0x0/0x71 @ 1
> [    0.029337] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
> [    0.029346] calling  cpu_stop_init+0x0/0xb4 @ 1
> [    0.029392] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
> [    0.029402] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
> [    0.029413] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
> [    0.029423] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
> [    0.029493] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
> [    0.029502] calling  relay_init+0x0/0x14 @ 1
> [    0.029510] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
> [    0.029519] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
> [    0.029565] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
> [    0.029575] calling  init_events+0x0/0x61 @ 1
> [    0.029584] initcall init_events+0x0/0x61 returned 0 after 0 usecs
> [    0.029592] calling  init_trace_printk+0x0/0x12 @ 1
> [    0.029601] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
> [    0.029610] calling  jump_label_init_module+0x0/0x12 @ 1
> [    0.029618] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
> [    0.029630] calling  mce_amd_init+0x0/0x110 @ 1
> [    0.029638] MCE: In-kernel MCE decoding enabled.
> [    0.029647] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
> [    0.029760] NMI watchdog: disabled (cpu0): hardware events not enabled
> [    0.030028] installing Xen timer for CPU 1
> [    0.030051] cpu 1 spinlock event irq 24
> [    0.030092] SMP alternatives: switching to SMP code
> [    0.056501] installing Xen timer for CPU 2
> [    0.056544] cpu 2 spinlock event irq 31
> [    0.057032] Brought up 3 CPUs
> [    0.058000] calling  ipc_ns_init+0x0/0x14 @ 1
> [    0.058000] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
> [    0.058000] calling  init_mmap_min_addr+0x0/0x26 @ 1
> [    0.058000] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
> [    0.058000] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
> [    0.058000] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
> [    0.058000] calling  net_ns_init+0x0/0xfd @ 1
> [    0.061054] initcall net_ns_init+0x0/0xfd returned 0 after 976 usecs
> [    0.061056] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
> [    0.061069] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
> [    0.061081] calling  cpufreq_tsc+0x0/0x37 @ 1
> [    0.061092] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
> [    0.061104] calling  reboot_init+0x0/0x1d @ 1
> [    0.061116] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
> [    0.061128] calling  init_lapic_sysfs+0x0/0x20 @ 1
> [    0.061138] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
> [    0.109030] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
> [    0.109044] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
> [    0.109056] calling  alloc_frozen_cpus+0x0/0x8 @ 1
> [    0.110000] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
> [    0.111008] calling  ksysfs_init+0x0/0x94 @ 1
> [    0.111035] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
> [    0.111045] calling  pm_init+0x0/0x4e @ 1
> [    0.111063] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
> [    0.111072] calling  pm_disk_init+0x0/0x19 @ 1
> [    0.111092] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
> [    0.111102] calling  swsusp_header_init+0x0/0x30 @ 1
> [    0.111113] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
> [    0.111122] calling  init_jiffies_clocksource+0x0/0x12 @ 1
> [    0.111137] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
> [    0.111148] calling  event_trace_enable+0x0/0xa9 @ 1
> [    0.111191] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
> [    0.111202] calling  init_zero_pfn+0x0/0x35 @ 1
> [    0.111211] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
> [    0.111222] calling  fsnotify_init+0x0/0x26 @ 1
> [    0.111235] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
> [    0.111246] calling  filelock_init+0x0/0x2a @ 1
> [    0.111317] initcall filelock_init+0x0/0x2a returned 0 after 976 usecs
> [    0.111329] calling  init_misc_binfmt+0x0/0x31 @ 1
> [    0.111341] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
> [    0.111351] calling  init_script_binfmt+0x0/0x16 @ 1
> [    0.111361] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
> [    0.111371] calling  init_elf_binfmt+0x0/0x16 @ 1
> [    0.111381] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
> [    0.111391] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
> [    0.111401] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
> [    0.111412] calling  debugfs_init+0x0/0x5c @ 1
> [    0.111425] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
> [    0.111435] calling  securityfs_init+0x0/0x53 @ 1
> [    0.111448] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
> [    0.111458] calling  prandom_init+0x0/0xd9 @ 1
> [    0.111469] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
> [    0.111480] calling  virtio_init+0x0/0x30 @ 1
> [    0.112062] kworker/u:0 (26) used greatest stack depth: 5592 bytes left
> [    0.112092] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
> [    0.112092] calling  __gnttab_init+0x0/0x30 @ 1
> [    0.112092] Grant tables using version 2 layout.
> [    0.112109] Grant table initialized
> [    0.112118] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
> [    0.112130] calling  early_resume_init+0x0/0x1d0 @ 1
> [    0.126868] RTC time: 165:165:165, date: 165/165/65
> [    0.126887] initcall early_resume_init+0x0/0x1d0 returned 0 after 14648 usecs
> [    0.126901] calling  cpufreq_core_init+0x0/0xc7 @ 1
> [    0.126911] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
> [    0.126921] calling  cpuidle_init+0x0/0x40 @ 1
> [    0.126930] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
> [    0.126941] calling  bsp_pm_check_init+0x0/0x14 @ 1
> [    0.126951] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
> [    0.126960] calling  sock_init+0x0/0x89 @ 1
> [    0.128845] initcall sock_init+0x0/0x89 returned 0 after 1953 usecs
> [    0.128856] calling  net_inuse_init+0x0/0x26 @ 1
> [    0.128867] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
> [    0.128877] calling  netpoll_init+0x0/0x31 @ 1
> [    0.128886] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
> [    0.128896] calling  netlink_proto_init+0x0/0x1b3 @ 1
> [    0.128919] NET: Registered protocol family 16
> [    0.128953] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
> [    0.128985] calling  bdi_class_init+0x0/0x4d @ 1
> [    0.129075] initcall bdi_class_init+0x0/0x4d returned 0 after 0 usecs
> [    0.129075] calling  kobject_uevent_init+0x0/0x12 @ 1
> [    0.129077] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
> [    0.129087] calling  pcibus_class_init+0x0/0x19 @ 1
> [    0.129114] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
> [    0.129114] calling  pci_driver_init+0x0/0x19 @ 1
> [    0.129114] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
> [    0.129114] calling  backlight_class_init+0x0/0x5d @ 1
> [    0.129114] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
> [    0.129114] calling  video_output_class_init+0x0/0x19 @ 1
> [    0.129114] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
> [    0.217038] calling  xenbus_init+0x0/0x21a @ 1
> [    0.217110] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
> [    0.217110] calling  tty_class_init+0x0/0x38 @ 1
> [    0.217110] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
> [    0.217110] calling  vtconsole_class_init+0x0/0xc2 @ 1
> [    0.217110] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
> [    0.217110] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
> [    0.217110] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
> [    0.217110] calling  register_node_type+0x0/0x34 @ 1
> [    0.218034] initcall register_node_type+0x0/0x34 returned 0 after 976 usecs
> [    0.218045] calling  i2c_init+0x0/0x77 @ 1
> [    0.218063] initcall i2c_init+0x0/0x77 returned 0 after 0 usecs
> [    0.218063] calling  amd_postcore_init+0x0/0x143 @ 1
> [    0.218673] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
> [    0.218710] calling  set_real_mode_permissions+0x0/0xa9 @ 1
> [    0.221082] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 2929 usecs
> [    0.221097] calling  arch_kdebugfs_init+0x0/0x233 @ 1
> [    0.221181] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
> [    0.221193] calling  mtrr_if_init+0x0/0x78 @ 1
> [    0.221202] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
> [    0.221212] calling  ffh_cstate_init+0x0/0x2a @ 1
> [    0.221222] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
> [    0.221233] initcall ffh_cstate_init+0x0/0x2a returned with error code -1
> [    0.221243] calling  activate_jump_labels+0x0/0x32 @ 1
> [    0.221253] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
> [    0.221263] calling  acpi_pci_init+0x0/0x5c @ 1
> [    0.221273] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
> [    0.221283] calling  dma_bus_init+0x0/0x19 @ 1
> [    0.221306] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
> [    0.221306] calling  dma_channel_table_init+0x0/0x119 @ 1
> [    0.221306] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
> [    0.221306] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
> [    0.226301] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 4882 usecs
> [    0.226320] calling  register_xen_pci_notifier+0x0/0x38 @ 1
> [    0.226331] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
> [    0.226342] calling  xen_pcpu_init+0x0/0xcc @ 1
> [    0.226353] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
> [    0.226364] calling  dmi_id_init+0x0/0x31d @ 1
> [    0.226374] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
> [    0.226385] calling  dca_init+0x0/0x20 @ 1
> [    0.226394] dca service started, version 1.12.1
> [    0.226499] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
> [    0.226511] calling  pci_arch_init+0x0/0x69 @ 1
> [    0.227009] PCI: setting up Xen PCI frontend stub
> [    0.227020] PCI: pci_cache_line_size set to 64 bytes
> [    0.227032] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
> [    0.227066] calling  topology_init+0x0/0x98 @ 1
> [    0.227348] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
> [    0.227360] calling  mtrr_init_finialize+0x0/0x36 @ 1
> [    0.227370] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
> [    0.227380] calling  init_vdso+0x0/0x135 @ 1
> [    0.227393] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
> [    0.227403] calling  sysenter_setup+0x0/0x2dd @ 1
> [    0.227417] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
> [    0.227427] calling  param_sysfs_init+0x0/0x192 @ 1
> [    0.243968] initcall param_sysfs_init+0x0/0x192 returned 0 after 15625 usecs
> [    0.243988] calling  pm_sysrq_init+0x0/0x19 @ 1
> [    0.243999] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
> [    0.244000] calling  default_bdi_init+0x0/0x37 @ 1
> [    0.244189] initcall default_bdi_init+0x0/0x37 returned 0 after 976 usecs
> [    0.244202] calling  init_bio+0x0/0xe8 @ 1
> [    0.244226] bio: create slab <bio-0> at 0
> [    0.244247] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
> [    0.244258] calling  fsnotify_notification_init+0x0/0x8b @ 1
> [    0.244281] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
> [    0.244294] calling  cryptomgr_init+0x0/0x12 @ 1
> [    0.244304] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
> [    0.244314] calling  blk_settings_init+0x0/0x2c @ 1
> [    0.244323] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
> [    0.244333] calling  blk_ioc_init+0x0/0x2a @ 1
> [    0.244350] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
> [    0.244360] calling  blk_softirq_init+0x0/0x6e @ 1
> [    0.244371] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
> [    0.244382] calling  blk_iopoll_setup+0x0/0x6e @ 1
> [    0.244391] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
> [    0.244401] calling  genhd_device_init+0x0/0x85 @ 1
> [    0.244544] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
> [    0.244557] calling  pci_slot_init+0x0/0x50 @ 1
> [    0.244571] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
> [    0.244581] calling  fbmem_init+0x0/0x98 @ 1
> [    0.244684] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
> [    0.244697] calling  acpi_init+0x0/0xbc @ 1
> [    0.244705] ACPI: Interpreter disabled.
> [    0.244714] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
> [    0.244724] calling  dock_init+0x0/0x7b @ 1
> [    0.244733] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
> [    0.244744] calling  acpi_pci_link_init+0x0/0x43 @ 1
> [    0.244754] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
> [    0.244764] calling  pnp_init+0x0/0x19 @ 1
> [    0.244875] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
> [    0.244887] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
> [    0.246077] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 1953 usecs
> [    0.246091] calling  balloon_init+0x0/0x133 @ 1
> [    0.246099] xen/balloon: Initialising balloon driver.
> [    0.247065] initcall balloon_init+0x0/0x133 returned 0 after 976 usecs
> [    0.247078] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
> [    0.255037] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 7812 usecs
> [    0.255055] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
> [    0.259050] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 3906 usecs
> [    0.259065] calling  xen_acpi_pad_init+0x0/0x47 @ 1
> [    0.259075] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
> [    0.259084] calling  balloon_init+0x0/0xfa @ 1
> [    0.259093] xen-balloon: Initialising balloon driver.
> [    0.259328] initcall balloon_init+0x0/0xfa returned 0 after 0 usecs
> [    0.259328] calling  xen_selfballoon_init+0x0/0xb9 @ 1
> [    0.259328] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
> [    0.259328] calling  misc_init+0x0/0xba @ 1
> [    0.259328] initcall misc_init+0x0/0xba returned 0 after 0 usecs
> [    0.259328] calling  vga_arb_device_init+0x0/0xde @ 1
> [    0.259419] vgaarb: loaded
> [    0.259430] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
> [    0.259442] calling  cn_init+0x0/0xc0 @ 1
> [    0.259466] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
> [    0.259477] calling  phy_init+0x0/0x2e @ 1
> [    0.260111] initcall phy_init+0x0/0x2e returned 0 after 976 usecs
> [    0.260123] calling  init_pcmcia_cs+0x0/0x3d @ 1
> [    0.260208] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
> [    0.260219] calling  usb_init+0x0/0x170 @ 1
> [    0.260418] usbcore: registered new interface driver usbfs
> [    0.260511] usbcore: registered new interface driver hub
> [    0.260635] usbcore: registered new device driver usb
> [    0.260646] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
> [    0.260656] calling  serio_init+0x0/0x38 @ 1
> [    0.260750] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
> [    0.260760] calling  input_init+0x0/0x103 @ 1
> [    0.260852] initcall input_init+0x0/0x103 returned 0 after 0 usecs
> [    0.260863] calling  rtc_init+0x0/0x71 @ 1
> [    0.260943] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
> [    0.260954] calling  pps_init+0x0/0xb7 @ 1
> [    0.261000] pps_core: LinuxPPS API ver. 1 registered
> [    0.261000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
> [    0.261000] initcall pps_init+0x0/0xb7 returned 0 after 0 usecs
> [    0.261014] calling  ptp_init+0x0/0xa4 @ 1
> [    0.261102] PTP clock support registered
> [    0.261112] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
> [    0.261122] calling  power_supply_class_init+0x0/0x44 @ 1
> [    0.261204] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
> [    0.261215] calling  hwmon_init+0x0/0xf6 @ 1
> [    0.261296] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
> [    0.261307] calling  leds_init+0x0/0x48 @ 1
> [    0.261388] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
> [    0.261399] calling  iommu_init+0x0/0x58 @ 1
> [    0.261411] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
> [    0.261423] calling  pci_subsys_init+0x0/0x4f @ 1
> [    0.261432] PCI: System does not support PCI
> [    0.261440] PCI: System does not support PCI
> [    0.261450] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
> [    0.261459] calling  proto_init+0x0/0x12 @ 1
> [    0.261474] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
> [    0.261485] calling  net_dev_init+0x0/0x1c7 @ 1
> [    0.261931] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
> [    0.261942] calling  neigh_init+0x0/0x80 @ 1
> [    0.261952] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
> [    0.261961] calling  fib_rules_init+0x0/0xaf @ 1
> [    0.261972] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
> [    0.261982] calling  pktsched_init+0x0/0xfe @ 1
> [    0.261997] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
> [    0.262000] calling  tc_filter_init+0x0/0x55 @ 1
> [    0.262000] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
> [    0.262000] calling  tc_action_init+0x0/0x55 @ 1
> [    0.262000] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
> [    0.262000] calling  genl_init+0x0/0x75 @ 1
> [    0.262033] initcall genl_init+0x0/0x75 returned 0 after 976 usecs
> [    0.263021] calling  cipso_v4_init+0x0/0x61 @ 1
> [    0.263039] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
> [    0.263052] calling  netlbl_init+0x0/0x81 @ 1
> [    0.263062] NetLabel: Initializing
> [    0.263072] NetLabel:  domain hash size = 128
> [    0.263081] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.263126] NetLabel:  unlabeled traffic allowed by default
> [    0.263137] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
> [    0.263147] calling  rfkill_init+0x0/0x79 @ 1
> [    0.263402] initcall rfkill_init+0x0/0x79 returned 0 after 0 usecs
> [    0.263436] calling  xen_p2m_debugfs+0x0/0x4a @ 1
> [    0.263478] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
> [    0.263489] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
> [    0.263645] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
> [    0.263659] calling  hpet_late_init+0x0/0x101 @ 1
> [    0.263671] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
> [    0.263682] calling  init_amd_nbs+0x0/0xb8 @ 1
> [    0.263693] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
> [    0.263704] calling  clocksource_done_booting+0x0/0x5a @ 1
> [    0.263714] Switching to clocksource xen
> [    0.263742] initcall clocksource_done_booting+0x0/0x5a returned 0 after 8 usecs
> [    0.263756] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
> [    0.263756] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 511 usecs
> [    0.263756] calling  init_trace_printk_function_export+0x0/0x2f @ 1
> [    0.263756] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 7 usecs
> [    0.263756] calling  event_trace_init+0x0/0x271 @ 1
> [    0.275332] initcall event_trace_init+0x0/0x271 returned 0 after 11443 usecs
> [    0.275351] calling  init_kprobe_trace+0x0/0x93 @ 1
> [    0.275377] initcall init_kprobe_trace+0x0/0x93 returned 0 after 15 usecs
> [    0.275389] calling  init_pipe_fs+0x0/0x4c @ 1
> [    0.275432] initcall init_pipe_fs+0x0/0x4c returned 0 after 31 usecs
> [    0.275443] calling  eventpoll_init+0x0/0xda @ 1
> [    0.275466] initcall eventpoll_init+0x0/0xda returned 0 after 12 usecs
> [    0.275477] calling  anon_inode_init+0x0/0x5b @ 1
> [    0.275513] initcall anon_inode_init+0x0/0x5b returned 0 after 26 usecs
> [    0.275524] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
> [    0.275533] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
> [    0.275543] calling  acpi_event_init+0x0/0x81 @ 1
> [    0.275553] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
> [    0.275563] calling  pnp_system_init+0x0/0x12 @ 1
> [    0.275708] initcall pnp_system_init+0x0/0x12 returned 0 after 131 usecs
> [    0.275719] calling  pnpacpi_init+0x0/0x8c @ 1
> [    0.275726] pnp: PnP ACPI: disabled
> [    0.275734] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
> [    0.275742] calling  pcistub_init+0x0/0x29f @ 1
> [    0.275843] initcall pcistub_init+0x0/0x29f returned 0 after 90 usecs
> [    0.275852] calling  chr_dev_init+0x0/0xc6 @ 1
> [    0.283039] initcall chr_dev_init+0x0/0xc6 returned 0 after 7006 usecs
> [    0.283108] calling  firmware_class_init+0x0/0xda @ 1
> [    0.283203] initcall firmware_class_init+0x0/0xda returned 0 after 82 usecs
> [    0.283213] calling  init_pcmcia_bus+0x0/0x6c @ 1
> [    0.283298] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 73 usecs
> [    0.283309] calling  thermal_init+0x0/0x75 @ 1
> [    0.283400] initcall thermal_init+0x0/0x75 returned 0 after 80 usecs
> [    0.283411] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
> [    0.283422] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
> [    0.283432] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
> [    0.283442] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
> [    0.283454] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
> [    0.283465] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
> [    0.283476] calling  pcibios_assign_resources+0x0/0xf8 @ 1
> [    0.283489] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
> [    0.283500] calling  sysctl_core_init+0x0/0x2c @ 1
> [    0.283523] initcall sysctl_core_init+0x0/0x2c returned 0 after 13 usecs
> [    0.283534] calling  inet_init+0x0/0x2a1 @ 1
> [    0.283572] NET: Registered protocol family 2
> [    0.283850] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
> [    0.283962] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
> [    0.284018] TCP: Hash tables configured (established 16384 bind 16384)
> [    0.284118] TCP: reno registered
> [    0.284136] UDP hash table entries: 1024 (order: 3, 32768 bytes)
> [    0.284162] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
> [    0.284282] initcall inet_init+0x0/0x2a1 returned 0 after 720 usecs
> [    0.284292] calling  ipv4_offload_init+0x0/0x68 @ 1
> [    0.284304] initcall ipv4_offload_init+0x0/0x68 returned 0 after 1 usecs
> [    0.284314] calling  af_unix_init+0x0/0x55 @ 1
> [    0.284326] NET: Registered protocol family 1
> [    0.284346] initcall af_unix_init+0x0/0x55 returned 0 after 21 usecs
> [    0.284356] calling  ipv6_offload_init+0x0/0x6e @ 1
> [    0.467091] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
> [    0.467106] calling  init_sunrpc+0x0/0x69 @ 1
> [    0.467311] RPC: Registered named UNIX socket transport module.
> [    0.467321] RPC: Registered udp transport module.
> [    0.467330] RPC: Registered tcp transport module.
> [    0.467338] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.467348] initcall init_sunrpc+0x0/0x69 returned 0 after 225 usecs
> [    0.467358] calling  pci_apply_final_quirks+0x0/0x117 @ 1
> [    0.467370] PCI: CLS 0 bytes, default 64
> [    0.467379] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 10 usecs
> [    0.467390] calling  populate_rootfs+0x0/0x10d @ 1
> [    0.467693] Unpacking initramfs...
> [    1.224465] Freeing initrd memory: 339320k freed
> [    1.330309] initcall populate_rootfs+0x0/0x10d returned 0 after 842675 usecs
> [    1.330328] calling  pci_iommu_init+0x0/0x41 @ 1
> [    1.330339] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
> [    1.330349] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
> [    1.330358] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
> [    1.330395] calling  irqfd_module_init+0x0/0x33 @ 1
> [    1.330489] initcall irqfd_module_init+0x0/0x33 returned 0 after 81 usecs
> [    1.330500] calling  i8259A_init_ops+0x0/0x21 @ 1
> [    1.330510] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
> [    1.330520] calling  vsyscall_init+0x0/0x27 @ 1
> [    1.330534] initcall vsyscall_init+0x0/0x27 returned 0 after 4 usecs
> [    1.330544] calling  sbf_init+0x0/0xf6 @ 1
> [    1.330553] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
> [    1.330563] calling  init_tsc_clocksource+0x0/0x89 @ 1
> [    1.330576] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
> [    1.330585] calling  add_rtc_cmos+0x0/0x96 @ 1
> [    1.330729] platform rtc_cmos: registered platform RTC device (no PNP device found)
> [    1.330741] initcall add_rtc_cmos+0x0/0x96 returned 0 after 143 usecs
> [    1.330751] calling  i8237A_init_ops+0x0/0x14 @ 1
> [    1.330761] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.330771] calling  cache_sysfs_init+0x0/0x6c @ 1
> [    1.330843] initcall cache_sysfs_init+0x0/0x6c returned 0 after 60 usecs
> [    1.330855] calling  intel_uncore_init+0x0/0x3fa @ 1
> [    1.330866] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
> [    1.330878] calling  inject_init+0x0/0x30 @ 1
> [    1.330886] Machine check injector initialized
> [    1.330897] initcall inject_init+0x0/0x30 returned 0 after 9 usecs
> [    1.330906] calling  thermal_throttle_init_device+0x0/0x9d @ 1
> [    1.330917] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
> [    1.330929] calling  amd_ibs_init+0x0/0x48d @ 1
> [    1.330939] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
> [    1.330949] calling  msr_init+0x0/0x162 @ 1
> [    1.331168] initcall msr_init+0x0/0x162 returned 0 after 204 usecs
> [    1.331179] calling  cpuid_init+0x0/0x162 @ 1
> [    1.331356] initcall cpuid_init+0x0/0x162 returned 0 after 161 usecs
> [    1.331368] calling  ioapic_init_ops+0x0/0x14 @ 1
> [    1.331379] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.331389] calling  add_pcspkr+0x0/0x40 @ 1
> [    1.331493] initcall add_pcspkr+0x0/0x40 returned 0 after 91 usecs
> [    1.331504] calling  microcode_init+0x0/0x1b1 @ 1
> [    1.331600] microcode: CPU0: patch_level=0x06000626
> [    1.331698] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    1.331710] initcall microcode_init+0x0/0x1b1 returned 0 after 193 usecs
> [    1.331721] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
> [    1.331731] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
> [    1.331741] calling  audit_classes_init+0x0/0xaf @ 1
> [    1.331756] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
> [    1.331767] calling  pt_dump_init+0x0/0x30 @ 1
> [    1.331801] initcall pt_dump_init+0x0/0x30 returned 0 after 24 usecs
> [    1.331815] calling  ia32_binfmt_init+0x0/0x14 @ 1
> [    1.331833] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 6 usecs
> [    1.331844] calling  proc_execdomains_init+0x0/0x22 @ 1
> [    1.331861] initcall proc_execdomains_init+0x0/0x22 returned 0 after 6 usecs
> [    1.331871] calling  ioresources_init+0x0/0x3c @ 1
> [    1.331887] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
> [    1.331896] calling  uid_cache_init+0x0/0xa5 @ 1
> [    1.331911] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
> [    1.331923] calling  init_posix_timers+0x0/0x1f4 @ 1
> [    1.331940] initcall init_posix_timers+0x0/0x1f4 returned 0 after 5 usecs
> [    1.331950] calling  init_posix_cpu_timers+0x0/0xbf @ 1
> [    1.331959] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
> [    1.331969] calling  proc_schedstat_init+0x0/0x22 @ 1
> [    1.331982] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
> [    1.331992] calling  snapshot_device_init+0x0/0x12 @ 1
> [    1.332147] initcall snapshot_device_init+0x0/0x12 returned 0 after 141 usecs
> [    1.332162] calling  create_proc_profile+0x0/0x2c0 @ 1
> [    1.332173] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
> [    1.332185] calling  timekeeping_init_ops+0x0/0x14 @ 1
> [    1.332198] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.332209] calling  init_clocksource_sysfs+0x0/0x52 @ 1
> [    1.332448] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 219 usecs
> [    1.332464] calling  init_timer_list_procfs+0x0/0x2c @ 1
> [    1.332489] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 7 usecs
> [    1.332504] calling  alarmtimer_init+0x0/0x15d @ 1
> [    1.332743] initcall alarmtimer_init+0x0/0x15d returned 0 after 221 usecs
> [    1.332754] calling  init_tstats_procfs+0x0/0x2c @ 1
> [    1.332771] initcall init_tstats_procfs+0x0/0x2c returned 0 after 5 usecs
> [    1.332781] calling  futex_init+0x0/0x65 @ 1
> [    1.332804] initcall futex_init+0x0/0x65 returned 0 after 9 usecs
> [    1.427360] calling  proc_dma_init+0x0/0x22 @ 1
> [    1.427383] initcall proc_dma_init+0x0/0x22 returned 0 after 9 usecs
> [    1.427394] calling  proc_modules_init+0x0/0x22 @ 1
> [    1.427408] initcall proc_modules_init+0x0/0x22 returned 0 after 4 usecs
> [    1.427417] calling  kallsyms_init+0x0/0x25 @ 1
> [    1.427430] initcall kallsyms_init+0x0/0x25 returned 0 after 3 usecs
> [    1.427440] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
> [    1.427469] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 18 usecs
> [    1.427480] calling  crash_notes_memory_init+0x0/0x36 @ 1
> [    1.427493] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 4 usecs
> [    1.427503] calling  pid_namespaces_init+0x0/0x2d @ 1
> [    1.427519] initcall pid_namespaces_init+0x0/0x2d returned 0 after 6 usecs
> [    1.427529] calling  ikconfig_init+0x0/0x3a @ 1
> [    1.427542] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
> [    1.427552] calling  audit_init+0x0/0x141 @ 1
> [    1.427563] audit: initializing netlink socket (disabled)
> [    1.427590] type=2000 audit(1361569070.777:1): initialized
> [    1.427603] initcall audit_init+0x0/0x141 returned 0 after 38 usecs
> [    1.427613] calling  audit_watch_init+0x0/0x3a @ 1
> [    1.427624] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
> [    1.427636] calling  audit_tree_init+0x0/0x49 @ 1
> [    1.427647] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
> [    1.427656] calling  init_kprobes+0x0/0x16c @ 1
> [    1.439621] initcall init_kprobes+0x0/0x16c returned 0 after 11669 usecs
> [    1.439637] calling  hung_task_init+0x0/0x56 @ 1
> [    1.439718] initcall hung_task_init+0x0/0x56 returned 0 after 68 usecs
> [    1.439729] calling  irq_pm_init_ops+0x0/0x14 @ 1
> [    1.439738] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.439748] calling  utsname_sysctl_init+0x0/0x14 @ 1
> [    1.439767] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 9 usecs
> [    1.439778] calling  init_tracepoints+0x0/0x20 @ 1
> [    1.439788] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
> [    1.439798] calling  init_blk_tracer+0x0/0x5a @ 1
> [    1.439808] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
> [    1.439818] calling  perf_event_sysfs_init+0x0/0x9a @ 1
> [    1.440270] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 431 usecs
> [    1.440283] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
> [    1.440420] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 122 usecs
> [    1.440433] calling  kswapd_init+0x0/0x76 @ 1
> [    1.440489] initcall kswapd_init+0x0/0x76 returned 0 after 45 usecs
> [    1.440499] calling  extfrag_debug_init+0x0/0x7e @ 1
> [    1.440539] initcall extfrag_debug_init+0x0/0x7e returned 0 after 29 usecs
> [    1.440549] calling  setup_vmstat+0x0/0xc8 @ 1
> [    1.440578] initcall setup_vmstat+0x0/0xc8 returned 0 after 18 usecs
> [    1.440589] calling  mm_sysfs_init+0x0/0x29 @ 1
> [    1.440602] initcall mm_sysfs_init+0x0/0x29 returned 0 after 3 usecs
> [    1.440613] calling  slab_proc_init+0x0/0x25 @ 1
> [    1.440626] initcall slab_proc_init+0x0/0x25 returned 0 after 4 usecs
> [    1.440636] calling  proc_vmalloc_init+0x0/0x25 @ 1
> [    1.440650] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
> [    1.440660] calling  procswaps_init+0x0/0x22 @ 1
> [    1.440673] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
> [    1.440684] calling  init_frontswap+0x0/0x96 @ 1
> [    1.440737] initcall init_frontswap+0x0/0x96 returned 0 after 43 usecs
> [    1.440749] calling  hugetlb_init+0x0/0x415 @ 1
> [    1.440759] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    1.440788] initcall hugetlb_init+0x0/0x415 returned 0 after 28 usecs
> [    1.440797] calling  mmu_notifier_init+0x0/0x12 @ 1
> [    1.440810] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
> [    1.440821] calling  slab_proc_init+0x0/0x8 @ 1
> [    1.440831] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
> [    1.440840] calling  cpucache_init+0x0/0x52 @ 1
> [    1.440851] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
> [    1.440861] calling  hugepage_init+0x0/0x191 @ 1
> [    1.440870] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
> [    1.440880] initcall hugepage_init+0x0/0x191 returned with error code -22
> [    1.440890] calling  init_cleancache+0x0/0x96 @ 1
> [    1.440939] initcall init_cleancache+0x0/0x96 returned 0 after 38 usecs
> [    1.440949] calling  fcntl_init+0x0/0x2a @ 1
> [    1.440964] initcall fcntl_init+0x0/0x2a returned 0 after 5 usecs
> [    1.440974] calling  proc_filesystems_init+0x0/0x22 @ 1
> [    1.440991] initcall proc_filesystems_init+0x0/0x22 returned 0 after 7 usecs
> [    1.441002] calling  dio_init+0x0/0x2d @ 1
> [    1.441016] initcall dio_init+0x0/0x2d returned 0 after 5 usecs
> [    1.441025] calling  fsnotify_mark_init+0x0/0x40 @ 1
> [    1.441109] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 71 usecs
> [    1.441119] calling  dnotify_init+0x0/0x7b @ 1
> [    1.441137] initcall dnotify_init+0x0/0x7b returned 0 after 8 usecs
> [    1.441146] calling  inotify_user_setup+0x0/0x70 @ 1
> [    1.441163] initcall inotify_user_setup+0x0/0x70 returned 0 after 7 usecs
> [    1.441173] calling  aio_setup+0x0/0x7c @ 1
> [    1.441192] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
> [    1.627775] calling  proc_locks_init+0x0/0x22 @ 1
> [    1.627796] initcall proc_locks_init+0x0/0x22 returned 0 after 9 usecs
> [    1.627806] calling  init_sys32_ioctl+0x0/0x28 @ 1
> [    1.627885] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 67 usecs
> [    1.627895] calling  dquot_init+0x0/0x121 @ 1
> [    1.627904] VFS: Disk quotas dquot_6.5.2
> [    1.627962] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    1.627974] initcall dquot_init+0x0/0x121 returned 0 after 66 usecs
> [    1.627985] calling  init_v2_quota_format+0x0/0x22 @ 1
> [    1.627996] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
> [    1.628006] calling  quota_init+0x0/0x26 @ 1
> [    1.628027] initcall quota_init+0x0/0x26 returned 0 after 10 usecs
> [    1.628037] calling  proc_cmdline_init+0x0/0x22 @ 1
> [    1.628072] initcall proc_cmdline_init+0x0/0x22 returned 0 after 22 usecs
> [    1.628088] calling  proc_consoles_init+0x0/0x22 @ 1
> [    1.628105] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628115] calling  proc_cpuinfo_init+0x0/0x22 @ 1
> [    1.628129] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628140] calling  proc_devices_init+0x0/0x22 @ 1
> [    1.628154] initcall proc_devices_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628165] calling  proc_interrupts_init+0x0/0x22 @ 1
> [    1.628179] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628189] calling  proc_loadavg_init+0x0/0x22 @ 1
> [    1.628204] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628214] calling  proc_meminfo_init+0x0/0x22 @ 1
> [    1.628228] initcall proc_meminfo_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628237] calling  proc_stat_init+0x0/0x22 @ 1
> [    1.628251] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628261] calling  proc_uptime_init+0x0/0x22 @ 1
> [    1.628275] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628287] calling  proc_version_init+0x0/0x22 @ 1
> [    1.628300] initcall proc_version_init+0x0/0x22 returned 0 after 3 usecs
> [    1.645978] calling  proc_softirqs_init+0x0/0x22 @ 1
> [    1.646001] initcall proc_softirqs_init+0x0/0x22 returned 0 after 10 usecs
> [    1.646012] calling  proc_kcore_init+0x0/0xb5 @ 1
> [    1.646032] initcall proc_kcore_init+0x0/0xb5 returned 0 after 8 usecs
> [    1.646042] calling  vmcore_init+0x0/0x370 @ 1
> [    1.646052] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
> [    1.646063] calling  proc_kmsg_init+0x0/0x25 @ 1
> [    1.646076] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
> [    1.646086] calling  proc_page_init+0x0/0x42 @ 1
> [    1.646104] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
> [    1.646125] calling  init_devpts_fs+0x0/0x62 @ 1
> [    1.646192] initcall init_devpts_fs+0x0/0x62 returned 0 after 54 usecs
> [    1.646203] calling  init_ramfs_fs+0x0/0x12 @ 1
> [    1.646213] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.646224] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
> [    1.646302] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 66 usecs
> [    1.646313] calling  init_fat_fs+0x0/0x4f @ 1
> [    1.646329] initcall init_fat_fs+0x0/0x4f returned 0 after 6 usecs
> [    1.646340] calling  init_vfat_fs+0x0/0x12 @ 1
> [    1.646350] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.646360] calling  init_msdos_fs+0x0/0x12 @ 1
> [    1.646370] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.646380] calling  init_iso9660_fs+0x0/0x70 @ 1
> [    1.646412] initcall init_iso9660_fs+0x0/0x70 returned 0 after 22 usecs
> [    1.646422] calling  init_nfs_fs+0x0/0x16c @ 1
> [    1.646598] initcall init_nfs_fs+0x0/0x16c returned 0 after 162 usecs
> [    1.646609] calling  init_nfs_v2+0x0/0x14 @ 1
> [    1.646619] initcall init_nfs_v2+0x0/0x14 returned 0 after 0 usecs
> [    1.646629] calling  init_nfs_v3+0x0/0x14 @ 1
> [    1.646639] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
> [    1.646649] calling  init_nfs_v4+0x0/0x3b @ 1
> [    1.646658] NFS: Registering the id_resolver key type
> [    1.646685] Key type id_resolver registered
> [    1.646694] Key type id_legacy registered
> [    1.646708] initcall init_nfs_v4+0x0/0x3b returned 0 after 47 usecs
> [    1.646717] calling  init_nlm+0x0/0x4c @ 1
> [    1.646732] initcall init_nlm+0x0/0x4c returned 0 after 6 usecs
> [    1.646742] calling  init_nls_cp437+0x0/0x12 @ 1
> [    1.646752] initcall init_nls_cp437+0x0/0x12 returned 0 after 1 usecs
> [    1.646760] calling  init_nls_ascii+0x0/0x12 @ 1
> [    1.646770] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
> [    1.646780] calling  init_nls_iso8859_1+0x0/0x12 @ 1
> [    1.646790] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
> [    1.646799] calling  init_nls_utf8+0x0/0x2b @ 1
> [    1.646810] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
> [    1.646819] calling  init_ntfs_fs+0x0/0x1d1 @ 1
> [    1.646827] NTFS driver 2.1.30 [Flags: R/W].
> [    1.646853] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 23 usecs
> [    1.646863] calling  init_autofs4_fs+0x0/0x2a @ 1
> [    1.647010] initcall init_autofs4_fs+0x0/0x2a returned 0 after 133 usecs
> [    1.647019] calling  init_pstore_fs+0x0/0x12 @ 1
> [    1.647030] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.647040] calling  ipc_init+0x0/0x2f @ 1
> [    1.647079] msgmni has been set to 2923
> [    1.647097] initcall ipc_init+0x0/0x2f returned 0 after 46 usecs
> [    1.647106] calling  ipc_sysctl_init+0x0/0x14 @ 1
> [    1.647123] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
> [    1.647132] calling  init_mqueue_fs+0x0/0xa2 @ 1
> [    1.647183] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 40 usecs
> [    1.647193] calling  key_proc_init+0x0/0x5e @ 1
> [    1.647210] initcall key_proc_init+0x0/0x5e returned 0 after 7 usecs
> [    1.647220] calling  selinux_nf_ip_init+0x0/0x69 @ 1
> [    1.647228] SELinux:  Registering netfilter hooks
> [    1.647457] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 222 usecs
> [    1.647467] calling  init_sel_fs+0x0/0xa5 @ 1
> [    1.647812] initcall init_sel_fs+0x0/0xa5 returned 0 after 327 usecs
> [    1.647822] calling  selnl_init+0x0/0x56 @ 1
> [    1.647839] initcall selnl_init+0x0/0x56 returned 0 after 7 usecs
> [    1.647848] calling  sel_netif_init+0x0/0x5c @ 1
> [    1.647860] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
> [    1.647870] calling  sel_netnode_init+0x0/0x6a @ 1
> [    1.647880] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
> [    1.647889] calling  sel_netport_init+0x0/0x6a @ 1
> [    1.647900] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
> [    1.647909] calling  aurule_init+0x0/0x2d @ 1
> [    1.647921] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
> [    1.647932] calling  crypto_wq_init+0x0/0x33 @ 1
> [    1.647976] initcall crypto_wq_init+0x0/0x33 returned 0 after 33 usecs
> [    1.647986] calling  crypto_algapi_init+0x0/0xd @ 1
> [    1.647999] initcall crypto_algapi_init+0x0/0xd returned 0 after 4 usecs
> [    1.829390] calling  skcipher_module_init+0x0/0x35 @ 1
> [    1.829403] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
> [    1.829414] calling  chainiv_module_init+0x0/0x12 @ 1
> [    1.829425] initcall chainiv_module_init+0x0/0x12 returned 0 after 1 usecs
> [    1.829435] calling  eseqiv_module_init+0x0/0x12 @ 1
> [    1.829445] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.829455] calling  hmac_module_init+0x0/0x12 @ 1
> [    1.829464] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.829474] calling  md5_mod_init+0x0/0x12 @ 1
> [    1.829598] initcall md5_mod_init+0x0/0x12 returned 0 after 111 usecs
> [    1.829609] calling  sha1_generic_mod_init+0x0/0x12 @ 1
> [    1.829676] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 55 usecs
> [    1.829687] calling  crypto_cbc_module_init+0x0/0x12 @ 1
> [    1.829696] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.829706] calling  des_generic_mod_init+0x0/0x17 @ 1
> [    1.829828] initcall des_generic_mod_init+0x0/0x17 returned 0 after 109 usecs
> [    1.829839] calling  aes_init+0x0/0x12 @ 1
> [    1.829904] initcall aes_init+0x0/0x12 returned 0 after 54 usecs
> [    1.829917] calling  zlib_mod_init+0x0/0x12 @ 1
> [    1.829983] initcall zlib_mod_init+0x0/0x12 returned 0 after 55 usecs
> [    1.829995] calling  crypto_authenc_module_init+0x0/0x12 @ 1
> [    1.830005] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.830016] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
> [    1.830026] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.830037] calling  lzo_mod_init+0x0/0x12 @ 1
> [    1.830133] initcall lzo_mod_init+0x0/0x12 returned 0 after 84 usecs
> [    1.830143] calling  krng_mod_init+0x0/0x12 @ 1
> [    1.830208] initcall krng_mod_init+0x0/0x12 returned 0 after 53 usecs
> [    1.830219] calling  proc_genhd_init+0x0/0x3c @ 1
> [    1.830241] initcall proc_genhd_init+0x0/0x3c returned 0 after 11 usecs
> [    1.830251] calling  bsg_init+0x0/0x12e @ 1
> [    1.830364] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> [    1.830375] initcall bsg_init+0x0/0x12e returned 0 after 112 usecs
> [    1.830385] calling  noop_init+0x0/0x12 @ 1
> [    1.830394] io scheduler noop registered
> [    1.830403] initcall noop_init+0x0/0x12 returned 0 after 9 usecs
> [    1.830412] calling  deadline_init+0x0/0x12 @ 1
> [    1.830421] io scheduler deadline registered
> [    1.830430] initcall deadline_init+0x0/0x12 returned 0 after 8 usecs
> [    1.830439] calling  cfq_init+0x0/0x8b @ 1
> [    1.830456] io scheduler cfq registered (default)
> [    1.830466] initcall cfq_init+0x0/0x8b returned 0 after 16 usecs
> [    1.830475] calling  percpu_counter_startup+0x0/0x38 @ 1
> [    1.830488] initcall percpu_counter_startup+0x0/0x38 returned 0 after 2 usecs
> [    1.830498] calling  pci_proc_init+0x0/0x6a @ 1
> [    1.830517] initcall pci_proc_init+0x0/0x6a returned 0 after 9 usecs
> [    1.830527] calling  pcie_portdrv_init+0x0/0x7a @ 1
> [    1.830717] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 175 usecs
> [    1.830729] calling  aer_service_init+0x0/0x2b @ 1
> [    1.830742] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
> [    1.830762] IP: [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> [    1.830780] PGD 0
> [    1.830791] Oops: 0000 [#1] SMP
> [    1.830806] Modules linked in:
> [    1.830819] CPU 0
> [    1.830827] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc2upstream-00002-g92ef2a2 #1
> [    1.830838] RIP: e030:[<ffffffff813862fa>]  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> [    1.830853] RSP: e02b:ffff88005bb69e98  EFLAGS: 00010246
> [    1.830862] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000017
> [    1.830871] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81328b30
> [    1.830880] RBP: ffff88005bb69eb8 R08: 00000000833df7a7 R09: 0720072007200720
> [    1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
> [    1.830899] R13: ffffffff81328b30 R14: 0000000000000000 R15: 0000000000000000
> [    1.830913] FS:  0000000000000000(0000) GS:ffff88005d600000(0000) knlGS:0000000000000000
> [    1.830926] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    1.830935] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000040660
> [    1.830945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    1.830955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [    1.830965] Process swapper/0 (pid: 1, threadinfo ffff88005bb68000, task ffff88005bb627f0)
> [    1.830975] Stack:
> [    1.830981]  0000000000000030 0000000000000000 ffffffff81ae8f60 000000006d1ed4e7
> [    1.831007]  ffff88005bb69ec8 ffffffff81328b8b ffff88005bb69ed8 ffffffff81ae8f72
> [    1.831033]  ffff88005bb69f08 ffffffff81002124 0000000000000030 0000000000000007
> [    1.831057] Call Trace:
> [    1.831057]  [<ffffffff81ae8f60>] ? pcie_portdrv_init+0x7a/0x7a
> [    1.831057]  [<ffffffff81328b8b>] aer_acpi_firmware_first+0x1b/0x30
> [    1.831057]  [<ffffffff81ae8f72>] aer_service_init+0x12/0x2b
> [    1.831057]  [<ffffffff81002124>] do_one_initcall+0x124/0x170
> [    1.831057]  [<ffffffff81645404>] kernel_init+0x174/0x2f0
> [    1.831057]  [<ffffffff81abd5ca>] ? parse_early_options+0x2b/0x2b
> [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> [    1.831057]  [<ffffffff81663ffc>] ret_from_fork+0x7c/0xb0
> [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> [    1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d
> [    1.831057] RIP  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> [    1.831057]  RSP <ffff88005bb69e98>
> [    1.831057] CR2: 0000000000000024
> [    2.028436] ---[ end trace dad4411f23c0dcf5 ]---
> [    2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
> [    2.028476] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [    2.028476]
> Parsing config from test.xm
> Daemon running with PID 5069
>


https://patchwork.kernel.org/patch/2175871/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Feb 22 23:40:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 22 Feb 2013 23: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 1U92D6-0005aQ-VX; Fri, 22 Feb 2013 23:39:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yhlu.kernel@gmail.com>) id 1U92D4-0005aL-S8
	for xen-devel@lists.xensource.com; Fri, 22 Feb 2013 23:39:23 +0000
Received: from [85.158.139.83:35931] by server-11.bemta-5.messagelabs.com id
	16/AE-19159-AA108215; Fri, 22 Feb 2013 23:39:22 +0000
X-Env-Sender: yhlu.kernel@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361576357!24195871!1
X-Originating-IP: [209.85.223.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29892 invoked from network); 22 Feb 2013 23:39:18 -0000
Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com)
	(209.85.223.177)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Feb 2013 23:39:18 -0000
Received: by mail-ie0-f177.google.com with SMTP id 16so1399728iea.22
	for <xen-devel@lists.xensource.com>;
	Fri, 22 Feb 2013 15:38:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SQ0fB3lGFSqmQ24eYgkVPU/qgf8+xiX99XIYZp13G+k=;
	b=OXAU1nBlPSETjhKUsHLVdV2oTxq2dXrwOb1aYrn4TltZGd2xwITBLFN3+YNhlh6a8T
	3jnvixby4cNwJJy079juNY+I/WeBvzVhODEcYZZPE/PWEqU2a0gXKPwWy681tHQFpaGw
	zP+APoW3b2EmeejgUlBTOrhkNw9aEaS9XmTlbM+oGg5m10Wx0GWfbmBYlIGHL0GaCCWb
	xkxOeMDw0wOmfGmxdSAXyVTvK2pvFVen1y3FdhDpppALeiCa6lh7ENITh4n8kWdoJvHL
	puvSfbugvHeEbBU3aB5Y6pNw4j+4mPola14oCuVJ1T1XXeC1vPkLfClO3bKgdPwi3/yj
	5B1g==
MIME-Version: 1.0
X-Received: by 10.50.168.41 with SMTP id zt9mr99846igb.42.1361576298198; Fri,
	22 Feb 2013 15:38:18 -0800 (PST)
Received: by 10.64.33.203 with HTTP; Fri, 22 Feb 2013 15:38:18 -0800 (PST)
In-Reply-To: <20130222214811.GA25445@phenom.dumpdata.com>
References: <20130222214811.GA25445@phenom.dumpdata.com>
Date: Fri, 22 Feb 2013 15:38:18 -0800
X-Google-Sender-Auth: yuXU6wXPkdAQLax99S9LDl0qdGM
Message-ID: <CAE9FiQUjj_bqF0aLVHDg01rc+A-1xKMuFc0yHN6Tqnxc5A-h3g@mail.gmail.com>
From: Yinghai Lu <yinghai@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: rafael.j.wysocki@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Regression introduced by
 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device
 objects from probing ACPI drivers) in v3.9-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 22, 2013 at 1:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Hey Rafael,
>
> Per git bisect it looks like that patch:
> ACPI: Separate adding ACPI device objects from probing ACPI drivers
> blows up when running under Xen PV guests:
>
> (please notice that ACPI is turned off with normal Xen PV guests):
> 547 #ifdef CONFIG_ACPI
> 548         if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> 549                 printk(KERN_INFO "ACPI in unprivileged domain disabled\n");
> 550                 disable_acpi();
> 551         }
> 552 #endif
>
> (in arch/x86/xen/setup.c). Here is what the console tells me
> (I can't get the early console somehow to work):
>
> [    0.000000] console [hvc0] enabled, bootconsole disabled
> [    0.000000] Xen: using vcpuop timer interface
> [    0.000000] installing Xen timer for CPU 0
> [    0.000000] tsc: Detected 3901.188 MHz processor
> [    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
> [    0.001000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
> [    0.001000] pid_max: default: 32768 minimum: 301
> [    0.001000] Security Framework initialized
> [    0.001000] SELinux:  Initializing.
> [    0.001000] SELinux:  Starting in permissive mode
> [    0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> [    0.001224] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [    0.001488] Mount-cache hash table entries: 256
> [    0.001774] Initializing cgroup subsys cpuacct
> [    0.001782] Initializing cgroup subsys freezer
> [    0.001860] tseg: 00adf00000
> [    0.001868] CPU: Physical Processor ID: 0
> [    0.001874] CPU: Processor Core ID: 1
> [    0.001883] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
> [    0.001883] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
> [    0.001883] tlb_flushall_shift: 5
> [    0.028911] cpu 0 spinlock event irq 17
> [    0.028956] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
> [    0.028966] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 usecs
> [    0.028976] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
> [    0.028986] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 0 usecs
> [    0.028997] calling  init_hw_perf_events+0x0/0x414 @ 1
> [    0.029000] Performance Events:
> [    0.029000] perf: AMD core performance counters detected
> [    0.029000] no APIC, boot with the "lapic" boot parameter to force-enable it.
> [    0.029000] no hardware sampling interrupt available.
> [    0.029000] Broken PMU hardware detected, using software events only.
> [    0.029005] Failed to access perfctr msr (MSR c0010201 is 0)
> [    0.029014] initcall init_hw_perf_events+0x0/0x414 returned 0 after 976 usecs
> [    0.029024] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
> [    0.029034] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 0 after 0 usecs
> [    0.029044] calling  spawn_ksoftirqd+0x0/0x28 @ 1
> [    0.029093] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
> [    0.029103] calling  init_workqueues+0x0/0x33a @ 1
> [    0.029316] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
> [    0.029327] calling  migration_init+0x0/0x71 @ 1
> [    0.029337] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
> [    0.029346] calling  cpu_stop_init+0x0/0xb4 @ 1
> [    0.029392] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
> [    0.029402] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
> [    0.029413] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 after 0 usecs
> [    0.029423] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
> [    0.029493] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
> [    0.029502] calling  relay_init+0x0/0x14 @ 1
> [    0.029510] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
> [    0.029519] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
> [    0.029565] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 usecs
> [    0.029575] calling  init_events+0x0/0x61 @ 1
> [    0.029584] initcall init_events+0x0/0x61 returned 0 after 0 usecs
> [    0.029592] calling  init_trace_printk+0x0/0x12 @ 1
> [    0.029601] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
> [    0.029610] calling  jump_label_init_module+0x0/0x12 @ 1
> [    0.029618] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 usecs
> [    0.029630] calling  mce_amd_init+0x0/0x110 @ 1
> [    0.029638] MCE: In-kernel MCE decoding enabled.
> [    0.029647] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
> [    0.029760] NMI watchdog: disabled (cpu0): hardware events not enabled
> [    0.030028] installing Xen timer for CPU 1
> [    0.030051] cpu 1 spinlock event irq 24
> [    0.030092] SMP alternatives: switching to SMP code
> [    0.056501] installing Xen timer for CPU 2
> [    0.056544] cpu 2 spinlock event irq 31
> [    0.057032] Brought up 3 CPUs
> [    0.058000] calling  ipc_ns_init+0x0/0x14 @ 1
> [    0.058000] initcall ipc_ns_init+0x0/0x14 returned 0 after 0 usecs
> [    0.058000] calling  init_mmap_min_addr+0x0/0x26 @ 1
> [    0.058000] initcall init_mmap_min_addr+0x0/0x26 returned 0 after 0 usecs
> [    0.058000] calling  init_cpufreq_transition_notifier_list+0x0/0x1b @ 1
> [    0.058000] initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 usecs
> [    0.058000] calling  net_ns_init+0x0/0xfd @ 1
> [    0.061054] initcall net_ns_init+0x0/0xfd returned 0 after 976 usecs
> [    0.061056] calling  e820_mark_nvs_memory+0x0/0x41 @ 1
> [    0.061069] initcall e820_mark_nvs_memory+0x0/0x41 returned 0 after 0 usecs
> [    0.061081] calling  cpufreq_tsc+0x0/0x37 @ 1
> [    0.061092] initcall cpufreq_tsc+0x0/0x37 returned 0 after 0 usecs
> [    0.061104] calling  reboot_init+0x0/0x1d @ 1
> [    0.061116] initcall reboot_init+0x0/0x1d returned 0 after 0 usecs
> [    0.061128] calling  init_lapic_sysfs+0x0/0x20 @ 1
> [    0.061138] initcall init_lapic_sysfs+0x0/0x20 returned 0 after 0 usecs
> [    0.109030] calling  cpu_hotplug_pm_sync_init+0x0/0x2f @ 1
> [    0.109044] initcall cpu_hotplug_pm_sync_init+0x0/0x2f returned 0 after 0 usecs
> [    0.109056] calling  alloc_frozen_cpus+0x0/0x8 @ 1
> [    0.110000] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
> [    0.111008] calling  ksysfs_init+0x0/0x94 @ 1
> [    0.111035] initcall ksysfs_init+0x0/0x94 returned 0 after 0 usecs
> [    0.111045] calling  pm_init+0x0/0x4e @ 1
> [    0.111063] initcall pm_init+0x0/0x4e returned 0 after 0 usecs
> [    0.111072] calling  pm_disk_init+0x0/0x19 @ 1
> [    0.111092] initcall pm_disk_init+0x0/0x19 returned 0 after 0 usecs
> [    0.111102] calling  swsusp_header_init+0x0/0x30 @ 1
> [    0.111113] initcall swsusp_header_init+0x0/0x30 returned 0 after 0 usecs
> [    0.111122] calling  init_jiffies_clocksource+0x0/0x12 @ 1
> [    0.111137] initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 usecs
> [    0.111148] calling  event_trace_enable+0x0/0xa9 @ 1
> [    0.111191] initcall event_trace_enable+0x0/0xa9 returned 0 after 0 usecs
> [    0.111202] calling  init_zero_pfn+0x0/0x35 @ 1
> [    0.111211] initcall init_zero_pfn+0x0/0x35 returned 0 after 0 usecs
> [    0.111222] calling  fsnotify_init+0x0/0x26 @ 1
> [    0.111235] initcall fsnotify_init+0x0/0x26 returned 0 after 0 usecs
> [    0.111246] calling  filelock_init+0x0/0x2a @ 1
> [    0.111317] initcall filelock_init+0x0/0x2a returned 0 after 976 usecs
> [    0.111329] calling  init_misc_binfmt+0x0/0x31 @ 1
> [    0.111341] initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
> [    0.111351] calling  init_script_binfmt+0x0/0x16 @ 1
> [    0.111361] initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
> [    0.111371] calling  init_elf_binfmt+0x0/0x16 @ 1
> [    0.111381] initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
> [    0.111391] calling  init_compat_elf_binfmt+0x0/0x16 @ 1
> [    0.111401] initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
> [    0.111412] calling  debugfs_init+0x0/0x5c @ 1
> [    0.111425] initcall debugfs_init+0x0/0x5c returned 0 after 0 usecs
> [    0.111435] calling  securityfs_init+0x0/0x53 @ 1
> [    0.111448] initcall securityfs_init+0x0/0x53 returned 0 after 0 usecs
> [    0.111458] calling  prandom_init+0x0/0xd9 @ 1
> [    0.111469] initcall prandom_init+0x0/0xd9 returned 0 after 0 usecs
> [    0.111480] calling  virtio_init+0x0/0x30 @ 1
> [    0.112062] kworker/u:0 (26) used greatest stack depth: 5592 bytes left
> [    0.112092] initcall virtio_init+0x0/0x30 returned 0 after 0 usecs
> [    0.112092] calling  __gnttab_init+0x0/0x30 @ 1
> [    0.112092] Grant tables using version 2 layout.
> [    0.112109] Grant table initialized
> [    0.112118] initcall __gnttab_init+0x0/0x30 returned 0 after 0 usecs
> [    0.112130] calling  early_resume_init+0x0/0x1d0 @ 1
> [    0.126868] RTC time: 165:165:165, date: 165/165/65
> [    0.126887] initcall early_resume_init+0x0/0x1d0 returned 0 after 14648 usecs
> [    0.126901] calling  cpufreq_core_init+0x0/0xc7 @ 1
> [    0.126911] initcall cpufreq_core_init+0x0/0xc7 returned -19 after 0 usecs
> [    0.126921] calling  cpuidle_init+0x0/0x40 @ 1
> [    0.126930] initcall cpuidle_init+0x0/0x40 returned -19 after 0 usecs
> [    0.126941] calling  bsp_pm_check_init+0x0/0x14 @ 1
> [    0.126951] initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
> [    0.126960] calling  sock_init+0x0/0x89 @ 1
> [    0.128845] initcall sock_init+0x0/0x89 returned 0 after 1953 usecs
> [    0.128856] calling  net_inuse_init+0x0/0x26 @ 1
> [    0.128867] initcall net_inuse_init+0x0/0x26 returned 0 after 0 usecs
> [    0.128877] calling  netpoll_init+0x0/0x31 @ 1
> [    0.128886] initcall netpoll_init+0x0/0x31 returned 0 after 0 usecs
> [    0.128896] calling  netlink_proto_init+0x0/0x1b3 @ 1
> [    0.128919] NET: Registered protocol family 16
> [    0.128953] initcall netlink_proto_init+0x0/0x1b3 returned 0 after 0 usecs
> [    0.128985] calling  bdi_class_init+0x0/0x4d @ 1
> [    0.129075] initcall bdi_class_init+0x0/0x4d returned 0 after 0 usecs
> [    0.129075] calling  kobject_uevent_init+0x0/0x12 @ 1
> [    0.129077] initcall kobject_uevent_init+0x0/0x12 returned 0 after 0 usecs
> [    0.129087] calling  pcibus_class_init+0x0/0x19 @ 1
> [    0.129114] initcall pcibus_class_init+0x0/0x19 returned 0 after 0 usecs
> [    0.129114] calling  pci_driver_init+0x0/0x19 @ 1
> [    0.129114] initcall pci_driver_init+0x0/0x19 returned 0 after 0 usecs
> [    0.129114] calling  backlight_class_init+0x0/0x5d @ 1
> [    0.129114] initcall backlight_class_init+0x0/0x5d returned 0 after 0 usecs
> [    0.129114] calling  video_output_class_init+0x0/0x19 @ 1
> [    0.129114] initcall video_output_class_init+0x0/0x19 returned 0 after 0 usecs
> [    0.217038] calling  xenbus_init+0x0/0x21a @ 1
> [    0.217110] initcall xenbus_init+0x0/0x21a returned 0 after 0 usecs
> [    0.217110] calling  tty_class_init+0x0/0x38 @ 1
> [    0.217110] initcall tty_class_init+0x0/0x38 returned 0 after 0 usecs
> [    0.217110] calling  vtconsole_class_init+0x0/0xc2 @ 1
> [    0.217110] initcall vtconsole_class_init+0x0/0xc2 returned 0 after 0 usecs
> [    0.217110] calling  wakeup_sources_debugfs_init+0x0/0x2b @ 1
> [    0.217110] initcall wakeup_sources_debugfs_init+0x0/0x2b returned 0 after 0 usecs
> [    0.217110] calling  register_node_type+0x0/0x34 @ 1
> [    0.218034] initcall register_node_type+0x0/0x34 returned 0 after 976 usecs
> [    0.218045] calling  i2c_init+0x0/0x77 @ 1
> [    0.218063] initcall i2c_init+0x0/0x77 returned 0 after 0 usecs
> [    0.218063] calling  amd_postcore_init+0x0/0x143 @ 1
> [    0.218673] initcall amd_postcore_init+0x0/0x143 returned 0 after 0 usecs
> [    0.218710] calling  set_real_mode_permissions+0x0/0xa9 @ 1
> [    0.221082] initcall set_real_mode_permissions+0x0/0xa9 returned 0 after 2929 usecs
> [    0.221097] calling  arch_kdebugfs_init+0x0/0x233 @ 1
> [    0.221181] initcall arch_kdebugfs_init+0x0/0x233 returned 0 after 0 usecs
> [    0.221193] calling  mtrr_if_init+0x0/0x78 @ 1
> [    0.221202] initcall mtrr_if_init+0x0/0x78 returned -19 after 0 usecs
> [    0.221212] calling  ffh_cstate_init+0x0/0x2a @ 1
> [    0.221222] initcall ffh_cstate_init+0x0/0x2a returned -1 after 0 usecs
> [    0.221233] initcall ffh_cstate_init+0x0/0x2a returned with error code -1
> [    0.221243] calling  activate_jump_labels+0x0/0x32 @ 1
> [    0.221253] initcall activate_jump_labels+0x0/0x32 returned 0 after 0 usecs
> [    0.221263] calling  acpi_pci_init+0x0/0x5c @ 1
> [    0.221273] initcall acpi_pci_init+0x0/0x5c returned 0 after 0 usecs
> [    0.221283] calling  dma_bus_init+0x0/0x19 @ 1
> [    0.221306] initcall dma_bus_init+0x0/0x19 returned 0 after 0 usecs
> [    0.221306] calling  dma_channel_table_init+0x0/0x119 @ 1
> [    0.221306] initcall dma_channel_table_init+0x0/0x119 returned 0 after 0 usecs
> [    0.221306] calling  setup_vcpu_hotplug_event+0x0/0x22 @ 1
> [    0.226301] initcall setup_vcpu_hotplug_event+0x0/0x22 returned 0 after 4882 usecs
> [    0.226320] calling  register_xen_pci_notifier+0x0/0x38 @ 1
> [    0.226331] initcall register_xen_pci_notifier+0x0/0x38 returned 0 after 0 usecs
> [    0.226342] calling  xen_pcpu_init+0x0/0xcc @ 1
> [    0.226353] initcall xen_pcpu_init+0x0/0xcc returned -19 after 0 usecs
> [    0.226364] calling  dmi_id_init+0x0/0x31d @ 1
> [    0.226374] initcall dmi_id_init+0x0/0x31d returned -19 after 0 usecs
> [    0.226385] calling  dca_init+0x0/0x20 @ 1
> [    0.226394] dca service started, version 1.12.1
> [    0.226499] initcall dca_init+0x0/0x20 returned 0 after 0 usecs
> [    0.226511] calling  pci_arch_init+0x0/0x69 @ 1
> [    0.227009] PCI: setting up Xen PCI frontend stub
> [    0.227020] PCI: pci_cache_line_size set to 64 bytes
> [    0.227032] initcall pci_arch_init+0x0/0x69 returned 0 after 976 usecs
> [    0.227066] calling  topology_init+0x0/0x98 @ 1
> [    0.227348] initcall topology_init+0x0/0x98 returned 0 after 0 usecs
> [    0.227360] calling  mtrr_init_finialize+0x0/0x36 @ 1
> [    0.227370] initcall mtrr_init_finialize+0x0/0x36 returned 0 after 0 usecs
> [    0.227380] calling  init_vdso+0x0/0x135 @ 1
> [    0.227393] initcall init_vdso+0x0/0x135 returned 0 after 0 usecs
> [    0.227403] calling  sysenter_setup+0x0/0x2dd @ 1
> [    0.227417] initcall sysenter_setup+0x0/0x2dd returned 0 after 0 usecs
> [    0.227427] calling  param_sysfs_init+0x0/0x192 @ 1
> [    0.243968] initcall param_sysfs_init+0x0/0x192 returned 0 after 15625 usecs
> [    0.243988] calling  pm_sysrq_init+0x0/0x19 @ 1
> [    0.243999] initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 usecs
> [    0.244000] calling  default_bdi_init+0x0/0x37 @ 1
> [    0.244189] initcall default_bdi_init+0x0/0x37 returned 0 after 976 usecs
> [    0.244202] calling  init_bio+0x0/0xe8 @ 1
> [    0.244226] bio: create slab <bio-0> at 0
> [    0.244247] initcall init_bio+0x0/0xe8 returned 0 after 0 usecs
> [    0.244258] calling  fsnotify_notification_init+0x0/0x8b @ 1
> [    0.244281] initcall fsnotify_notification_init+0x0/0x8b returned 0 after 0 usecs
> [    0.244294] calling  cryptomgr_init+0x0/0x12 @ 1
> [    0.244304] initcall cryptomgr_init+0x0/0x12 returned 0 after 0 usecs
> [    0.244314] calling  blk_settings_init+0x0/0x2c @ 1
> [    0.244323] initcall blk_settings_init+0x0/0x2c returned 0 after 0 usecs
> [    0.244333] calling  blk_ioc_init+0x0/0x2a @ 1
> [    0.244350] initcall blk_ioc_init+0x0/0x2a returned 0 after 0 usecs
> [    0.244360] calling  blk_softirq_init+0x0/0x6e @ 1
> [    0.244371] initcall blk_softirq_init+0x0/0x6e returned 0 after 0 usecs
> [    0.244382] calling  blk_iopoll_setup+0x0/0x6e @ 1
> [    0.244391] initcall blk_iopoll_setup+0x0/0x6e returned 0 after 0 usecs
> [    0.244401] calling  genhd_device_init+0x0/0x85 @ 1
> [    0.244544] initcall genhd_device_init+0x0/0x85 returned 0 after 0 usecs
> [    0.244557] calling  pci_slot_init+0x0/0x50 @ 1
> [    0.244571] initcall pci_slot_init+0x0/0x50 returned 0 after 0 usecs
> [    0.244581] calling  fbmem_init+0x0/0x98 @ 1
> [    0.244684] initcall fbmem_init+0x0/0x98 returned 0 after 0 usecs
> [    0.244697] calling  acpi_init+0x0/0xbc @ 1
> [    0.244705] ACPI: Interpreter disabled.
> [    0.244714] initcall acpi_init+0x0/0xbc returned -19 after 0 usecs
> [    0.244724] calling  dock_init+0x0/0x7b @ 1
> [    0.244733] initcall dock_init+0x0/0x7b returned 0 after 0 usecs
> [    0.244744] calling  acpi_pci_link_init+0x0/0x43 @ 1
> [    0.244754] initcall acpi_pci_link_init+0x0/0x43 returned 0 after 0 usecs
> [    0.244764] calling  pnp_init+0x0/0x19 @ 1
> [    0.244875] initcall pnp_init+0x0/0x19 returned 0 after 0 usecs
> [    0.244887] calling  xen_setup_shutdown_event+0x0/0x30 @ 1
> [    0.246077] initcall xen_setup_shutdown_event+0x0/0x30 returned 0 after 1953 usecs
> [    0.246091] calling  balloon_init+0x0/0x133 @ 1
> [    0.246099] xen/balloon: Initialising balloon driver.
> [    0.247065] initcall balloon_init+0x0/0x133 returned 0 after 976 usecs
> [    0.247078] calling  xenbus_probe_backend_init+0x0/0x34 @ 1
> [    0.255037] initcall xenbus_probe_backend_init+0x0/0x34 returned 0 after 7812 usecs
> [    0.255055] calling  xenbus_probe_frontend_init+0x0/0x34 @ 1
> [    0.259050] initcall xenbus_probe_frontend_init+0x0/0x34 returned 0 after 3906 usecs
> [    0.259065] calling  xen_acpi_pad_init+0x0/0x47 @ 1
> [    0.259075] initcall xen_acpi_pad_init+0x0/0x47 returned -19 after 0 usecs
> [    0.259084] calling  balloon_init+0x0/0xfa @ 1
> [    0.259093] xen-balloon: Initialising balloon driver.
> [    0.259328] initcall balloon_init+0x0/0xfa returned 0 after 0 usecs
> [    0.259328] calling  xen_selfballoon_init+0x0/0xb9 @ 1
> [    0.259328] initcall xen_selfballoon_init+0x0/0xb9 returned -19 after 0 usecs
> [    0.259328] calling  misc_init+0x0/0xba @ 1
> [    0.259328] initcall misc_init+0x0/0xba returned 0 after 0 usecs
> [    0.259328] calling  vga_arb_device_init+0x0/0xde @ 1
> [    0.259419] vgaarb: loaded
> [    0.259430] initcall vga_arb_device_init+0x0/0xde returned 0 after 0 usecs
> [    0.259442] calling  cn_init+0x0/0xc0 @ 1
> [    0.259466] initcall cn_init+0x0/0xc0 returned 0 after 0 usecs
> [    0.259477] calling  phy_init+0x0/0x2e @ 1
> [    0.260111] initcall phy_init+0x0/0x2e returned 0 after 976 usecs
> [    0.260123] calling  init_pcmcia_cs+0x0/0x3d @ 1
> [    0.260208] initcall init_pcmcia_cs+0x0/0x3d returned 0 after 0 usecs
> [    0.260219] calling  usb_init+0x0/0x170 @ 1
> [    0.260418] usbcore: registered new interface driver usbfs
> [    0.260511] usbcore: registered new interface driver hub
> [    0.260635] usbcore: registered new device driver usb
> [    0.260646] initcall usb_init+0x0/0x170 returned 0 after 0 usecs
> [    0.260656] calling  serio_init+0x0/0x38 @ 1
> [    0.260750] initcall serio_init+0x0/0x38 returned 0 after 0 usecs
> [    0.260760] calling  input_init+0x0/0x103 @ 1
> [    0.260852] initcall input_init+0x0/0x103 returned 0 after 0 usecs
> [    0.260863] calling  rtc_init+0x0/0x71 @ 1
> [    0.260943] initcall rtc_init+0x0/0x71 returned 0 after 0 usecs
> [    0.260954] calling  pps_init+0x0/0xb7 @ 1
> [    0.261000] pps_core: LinuxPPS API ver. 1 registered
> [    0.261000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
> [    0.261000] initcall pps_init+0x0/0xb7 returned 0 after 0 usecs
> [    0.261014] calling  ptp_init+0x0/0xa4 @ 1
> [    0.261102] PTP clock support registered
> [    0.261112] initcall ptp_init+0x0/0xa4 returned 0 after 0 usecs
> [    0.261122] calling  power_supply_class_init+0x0/0x44 @ 1
> [    0.261204] initcall power_supply_class_init+0x0/0x44 returned 0 after 0 usecs
> [    0.261215] calling  hwmon_init+0x0/0xf6 @ 1
> [    0.261296] initcall hwmon_init+0x0/0xf6 returned 0 after 0 usecs
> [    0.261307] calling  leds_init+0x0/0x48 @ 1
> [    0.261388] initcall leds_init+0x0/0x48 returned 0 after 0 usecs
> [    0.261399] calling  iommu_init+0x0/0x58 @ 1
> [    0.261411] initcall iommu_init+0x0/0x58 returned 0 after 0 usecs
> [    0.261423] calling  pci_subsys_init+0x0/0x4f @ 1
> [    0.261432] PCI: System does not support PCI
> [    0.261440] PCI: System does not support PCI
> [    0.261450] initcall pci_subsys_init+0x0/0x4f returned 0 after 0 usecs
> [    0.261459] calling  proto_init+0x0/0x12 @ 1
> [    0.261474] initcall proto_init+0x0/0x12 returned 0 after 0 usecs
> [    0.261485] calling  net_dev_init+0x0/0x1c7 @ 1
> [    0.261931] initcall net_dev_init+0x0/0x1c7 returned 0 after 0 usecs
> [    0.261942] calling  neigh_init+0x0/0x80 @ 1
> [    0.261952] initcall neigh_init+0x0/0x80 returned 0 after 0 usecs
> [    0.261961] calling  fib_rules_init+0x0/0xaf @ 1
> [    0.261972] initcall fib_rules_init+0x0/0xaf returned 0 after 0 usecs
> [    0.261982] calling  pktsched_init+0x0/0xfe @ 1
> [    0.261997] initcall pktsched_init+0x0/0xfe returned 0 after 0 usecs
> [    0.262000] calling  tc_filter_init+0x0/0x55 @ 1
> [    0.262000] initcall tc_filter_init+0x0/0x55 returned 0 after 0 usecs
> [    0.262000] calling  tc_action_init+0x0/0x55 @ 1
> [    0.262000] initcall tc_action_init+0x0/0x55 returned 0 after 0 usecs
> [    0.262000] calling  genl_init+0x0/0x75 @ 1
> [    0.262033] initcall genl_init+0x0/0x75 returned 0 after 976 usecs
> [    0.263021] calling  cipso_v4_init+0x0/0x61 @ 1
> [    0.263039] initcall cipso_v4_init+0x0/0x61 returned 0 after 0 usecs
> [    0.263052] calling  netlbl_init+0x0/0x81 @ 1
> [    0.263062] NetLabel: Initializing
> [    0.263072] NetLabel:  domain hash size = 128
> [    0.263081] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.263126] NetLabel:  unlabeled traffic allowed by default
> [    0.263137] initcall netlbl_init+0x0/0x81 returned 0 after 0 usecs
> [    0.263147] calling  rfkill_init+0x0/0x79 @ 1
> [    0.263402] initcall rfkill_init+0x0/0x79 returned 0 after 0 usecs
> [    0.263436] calling  xen_p2m_debugfs+0x0/0x4a @ 1
> [    0.263478] initcall xen_p2m_debugfs+0x0/0x4a returned 0 after 0 usecs
> [    0.263489] calling  xen_spinlock_debugfs+0x0/0x24e @ 1
> [    0.263645] initcall xen_spinlock_debugfs+0x0/0x24e returned 0 after 0 usecs
> [    0.263659] calling  hpet_late_init+0x0/0x101 @ 1
> [    0.263671] initcall hpet_late_init+0x0/0x101 returned -19 after 0 usecs
> [    0.263682] calling  init_amd_nbs+0x0/0xb8 @ 1
> [    0.263693] initcall init_amd_nbs+0x0/0xb8 returned 0 after 0 usecs
> [    0.263704] calling  clocksource_done_booting+0x0/0x5a @ 1
> [    0.263714] Switching to clocksource xen
> [    0.263742] initcall clocksource_done_booting+0x0/0x5a returned 0 after 8 usecs
> [    0.263756] calling  tracer_init_debugfs+0x0/0x3a4 @ 1
> [    0.263756] initcall tracer_init_debugfs+0x0/0x3a4 returned 0 after 511 usecs
> [    0.263756] calling  init_trace_printk_function_export+0x0/0x2f @ 1
> [    0.263756] initcall init_trace_printk_function_export+0x0/0x2f returned 0 after 7 usecs
> [    0.263756] calling  event_trace_init+0x0/0x271 @ 1
> [    0.275332] initcall event_trace_init+0x0/0x271 returned 0 after 11443 usecs
> [    0.275351] calling  init_kprobe_trace+0x0/0x93 @ 1
> [    0.275377] initcall init_kprobe_trace+0x0/0x93 returned 0 after 15 usecs
> [    0.275389] calling  init_pipe_fs+0x0/0x4c @ 1
> [    0.275432] initcall init_pipe_fs+0x0/0x4c returned 0 after 31 usecs
> [    0.275443] calling  eventpoll_init+0x0/0xda @ 1
> [    0.275466] initcall eventpoll_init+0x0/0xda returned 0 after 12 usecs
> [    0.275477] calling  anon_inode_init+0x0/0x5b @ 1
> [    0.275513] initcall anon_inode_init+0x0/0x5b returned 0 after 26 usecs
> [    0.275524] calling  blk_scsi_ioctl_init+0x0/0x289 @ 1
> [    0.275533] initcall blk_scsi_ioctl_init+0x0/0x289 returned 0 after 0 usecs
> [    0.275543] calling  acpi_event_init+0x0/0x81 @ 1
> [    0.275553] initcall acpi_event_init+0x0/0x81 returned 0 after 0 usecs
> [    0.275563] calling  pnp_system_init+0x0/0x12 @ 1
> [    0.275708] initcall pnp_system_init+0x0/0x12 returned 0 after 131 usecs
> [    0.275719] calling  pnpacpi_init+0x0/0x8c @ 1
> [    0.275726] pnp: PnP ACPI: disabled
> [    0.275734] initcall pnpacpi_init+0x0/0x8c returned 0 after 6 usecs
> [    0.275742] calling  pcistub_init+0x0/0x29f @ 1
> [    0.275843] initcall pcistub_init+0x0/0x29f returned 0 after 90 usecs
> [    0.275852] calling  chr_dev_init+0x0/0xc6 @ 1
> [    0.283039] initcall chr_dev_init+0x0/0xc6 returned 0 after 7006 usecs
> [    0.283108] calling  firmware_class_init+0x0/0xda @ 1
> [    0.283203] initcall firmware_class_init+0x0/0xda returned 0 after 82 usecs
> [    0.283213] calling  init_pcmcia_bus+0x0/0x6c @ 1
> [    0.283298] initcall init_pcmcia_bus+0x0/0x6c returned 0 after 73 usecs
> [    0.283309] calling  thermal_init+0x0/0x75 @ 1
> [    0.283400] initcall thermal_init+0x0/0x75 returned 0 after 80 usecs
> [    0.283411] calling  thermal_gov_step_wise_init+0x0/0x12 @ 1
> [    0.283422] initcall thermal_gov_step_wise_init+0x0/0x12 returned 0 after 0 usecs
> [    0.283432] calling  cpufreq_gov_performance_init+0x0/0x12 @ 1
> [    0.283442] initcall cpufreq_gov_performance_init+0x0/0x12 returned -19 after 0 usecs
> [    0.283454] calling  init_acpi_pm_clocksource+0x0/0xec @ 1
> [    0.283465] initcall init_acpi_pm_clocksource+0x0/0xec returned -19 after 0 usecs
> [    0.283476] calling  pcibios_assign_resources+0x0/0xf8 @ 1
> [    0.283489] initcall pcibios_assign_resources+0x0/0xf8 returned 0 after 2 usecs
> [    0.283500] calling  sysctl_core_init+0x0/0x2c @ 1
> [    0.283523] initcall sysctl_core_init+0x0/0x2c returned 0 after 13 usecs
> [    0.283534] calling  inet_init+0x0/0x2a1 @ 1
> [    0.283572] NET: Registered protocol family 2
> [    0.283850] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
> [    0.283962] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
> [    0.284018] TCP: Hash tables configured (established 16384 bind 16384)
> [    0.284118] TCP: reno registered
> [    0.284136] UDP hash table entries: 1024 (order: 3, 32768 bytes)
> [    0.284162] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
> [    0.284282] initcall inet_init+0x0/0x2a1 returned 0 after 720 usecs
> [    0.284292] calling  ipv4_offload_init+0x0/0x68 @ 1
> [    0.284304] initcall ipv4_offload_init+0x0/0x68 returned 0 after 1 usecs
> [    0.284314] calling  af_unix_init+0x0/0x55 @ 1
> [    0.284326] NET: Registered protocol family 1
> [    0.284346] initcall af_unix_init+0x0/0x55 returned 0 after 21 usecs
> [    0.284356] calling  ipv6_offload_init+0x0/0x6e @ 1
> [    0.467091] initcall ipv6_offload_init+0x0/0x6e returned 0 after 1 usecs
> [    0.467106] calling  init_sunrpc+0x0/0x69 @ 1
> [    0.467311] RPC: Registered named UNIX socket transport module.
> [    0.467321] RPC: Registered udp transport module.
> [    0.467330] RPC: Registered tcp transport module.
> [    0.467338] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.467348] initcall init_sunrpc+0x0/0x69 returned 0 after 225 usecs
> [    0.467358] calling  pci_apply_final_quirks+0x0/0x117 @ 1
> [    0.467370] PCI: CLS 0 bytes, default 64
> [    0.467379] initcall pci_apply_final_quirks+0x0/0x117 returned 0 after 10 usecs
> [    0.467390] calling  populate_rootfs+0x0/0x10d @ 1
> [    0.467693] Unpacking initramfs...
> [    1.224465] Freeing initrd memory: 339320k freed
> [    1.330309] initcall populate_rootfs+0x0/0x10d returned 0 after 842675 usecs
> [    1.330328] calling  pci_iommu_init+0x0/0x41 @ 1
> [    1.330339] initcall pci_iommu_init+0x0/0x41 returned 0 after 0 usecs
> [    1.330349] calling  calgary_fixup_tce_spaces+0x0/0x105 @ 1
> [    1.330358] initcall calgary_fixup_tce_spaces+0x0/0x105 returned -19 after 0 usecs
> [    1.330395] calling  irqfd_module_init+0x0/0x33 @ 1
> [    1.330489] initcall irqfd_module_init+0x0/0x33 returned 0 after 81 usecs
> [    1.330500] calling  i8259A_init_ops+0x0/0x21 @ 1
> [    1.330510] initcall i8259A_init_ops+0x0/0x21 returned 0 after 0 usecs
> [    1.330520] calling  vsyscall_init+0x0/0x27 @ 1
> [    1.330534] initcall vsyscall_init+0x0/0x27 returned 0 after 4 usecs
> [    1.330544] calling  sbf_init+0x0/0xf6 @ 1
> [    1.330553] initcall sbf_init+0x0/0xf6 returned 0 after 0 usecs
> [    1.330563] calling  init_tsc_clocksource+0x0/0x89 @ 1
> [    1.330576] initcall init_tsc_clocksource+0x0/0x89 returned 0 after 3 usecs
> [    1.330585] calling  add_rtc_cmos+0x0/0x96 @ 1
> [    1.330729] platform rtc_cmos: registered platform RTC device (no PNP device found)
> [    1.330741] initcall add_rtc_cmos+0x0/0x96 returned 0 after 143 usecs
> [    1.330751] calling  i8237A_init_ops+0x0/0x14 @ 1
> [    1.330761] initcall i8237A_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.330771] calling  cache_sysfs_init+0x0/0x6c @ 1
> [    1.330843] initcall cache_sysfs_init+0x0/0x6c returned 0 after 60 usecs
> [    1.330855] calling  intel_uncore_init+0x0/0x3fa @ 1
> [    1.330866] initcall intel_uncore_init+0x0/0x3fa returned -19 after 0 usecs
> [    1.330878] calling  inject_init+0x0/0x30 @ 1
> [    1.330886] Machine check injector initialized
> [    1.330897] initcall inject_init+0x0/0x30 returned 0 after 9 usecs
> [    1.330906] calling  thermal_throttle_init_device+0x0/0x9d @ 1
> [    1.330917] initcall thermal_throttle_init_device+0x0/0x9d returned 0 after 0 usecs
> [    1.330929] calling  amd_ibs_init+0x0/0x48d @ 1
> [    1.330939] initcall amd_ibs_init+0x0/0x48d returned -19 after 0 usecs
> [    1.330949] calling  msr_init+0x0/0x162 @ 1
> [    1.331168] initcall msr_init+0x0/0x162 returned 0 after 204 usecs
> [    1.331179] calling  cpuid_init+0x0/0x162 @ 1
> [    1.331356] initcall cpuid_init+0x0/0x162 returned 0 after 161 usecs
> [    1.331368] calling  ioapic_init_ops+0x0/0x14 @ 1
> [    1.331379] initcall ioapic_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.331389] calling  add_pcspkr+0x0/0x40 @ 1
> [    1.331493] initcall add_pcspkr+0x0/0x40 returned 0 after 91 usecs
> [    1.331504] calling  microcode_init+0x0/0x1b1 @ 1
> [    1.331600] microcode: CPU0: patch_level=0x06000626
> [    1.331698] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    1.331710] initcall microcode_init+0x0/0x1b1 returned 0 after 193 usecs
> [    1.331721] calling  start_periodic_check_for_corruption+0x0/0x50 @ 1
> [    1.331731] initcall start_periodic_check_for_corruption+0x0/0x50 returned 0 after 0 usecs
> [    1.331741] calling  audit_classes_init+0x0/0xaf @ 1
> [    1.331756] initcall audit_classes_init+0x0/0xaf returned 0 after 5 usecs
> [    1.331767] calling  pt_dump_init+0x0/0x30 @ 1
> [    1.331801] initcall pt_dump_init+0x0/0x30 returned 0 after 24 usecs
> [    1.331815] calling  ia32_binfmt_init+0x0/0x14 @ 1
> [    1.331833] initcall ia32_binfmt_init+0x0/0x14 returned 0 after 6 usecs
> [    1.331844] calling  proc_execdomains_init+0x0/0x22 @ 1
> [    1.331861] initcall proc_execdomains_init+0x0/0x22 returned 0 after 6 usecs
> [    1.331871] calling  ioresources_init+0x0/0x3c @ 1
> [    1.331887] initcall ioresources_init+0x0/0x3c returned 0 after 6 usecs
> [    1.331896] calling  uid_cache_init+0x0/0xa5 @ 1
> [    1.331911] initcall uid_cache_init+0x0/0xa5 returned 0 after 5 usecs
> [    1.331923] calling  init_posix_timers+0x0/0x1f4 @ 1
> [    1.331940] initcall init_posix_timers+0x0/0x1f4 returned 0 after 5 usecs
> [    1.331950] calling  init_posix_cpu_timers+0x0/0xbf @ 1
> [    1.331959] initcall init_posix_cpu_timers+0x0/0xbf returned 0 after 0 usecs
> [    1.331969] calling  proc_schedstat_init+0x0/0x22 @ 1
> [    1.331982] initcall proc_schedstat_init+0x0/0x22 returned 0 after 3 usecs
> [    1.331992] calling  snapshot_device_init+0x0/0x12 @ 1
> [    1.332147] initcall snapshot_device_init+0x0/0x12 returned 0 after 141 usecs
> [    1.332162] calling  create_proc_profile+0x0/0x2c0 @ 1
> [    1.332173] initcall create_proc_profile+0x0/0x2c0 returned 0 after 0 usecs
> [    1.332185] calling  timekeeping_init_ops+0x0/0x14 @ 1
> [    1.332198] initcall timekeeping_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.332209] calling  init_clocksource_sysfs+0x0/0x52 @ 1
> [    1.332448] initcall init_clocksource_sysfs+0x0/0x52 returned 0 after 219 usecs
> [    1.332464] calling  init_timer_list_procfs+0x0/0x2c @ 1
> [    1.332489] initcall init_timer_list_procfs+0x0/0x2c returned 0 after 7 usecs
> [    1.332504] calling  alarmtimer_init+0x0/0x15d @ 1
> [    1.332743] initcall alarmtimer_init+0x0/0x15d returned 0 after 221 usecs
> [    1.332754] calling  init_tstats_procfs+0x0/0x2c @ 1
> [    1.332771] initcall init_tstats_procfs+0x0/0x2c returned 0 after 5 usecs
> [    1.332781] calling  futex_init+0x0/0x65 @ 1
> [    1.332804] initcall futex_init+0x0/0x65 returned 0 after 9 usecs
> [    1.427360] calling  proc_dma_init+0x0/0x22 @ 1
> [    1.427383] initcall proc_dma_init+0x0/0x22 returned 0 after 9 usecs
> [    1.427394] calling  proc_modules_init+0x0/0x22 @ 1
> [    1.427408] initcall proc_modules_init+0x0/0x22 returned 0 after 4 usecs
> [    1.427417] calling  kallsyms_init+0x0/0x25 @ 1
> [    1.427430] initcall kallsyms_init+0x0/0x25 returned 0 after 3 usecs
> [    1.427440] calling  crash_save_vmcoreinfo_init+0x0/0x4a9 @ 1
> [    1.427469] initcall crash_save_vmcoreinfo_init+0x0/0x4a9 returned 0 after 18 usecs
> [    1.427480] calling  crash_notes_memory_init+0x0/0x36 @ 1
> [    1.427493] initcall crash_notes_memory_init+0x0/0x36 returned 0 after 4 usecs
> [    1.427503] calling  pid_namespaces_init+0x0/0x2d @ 1
> [    1.427519] initcall pid_namespaces_init+0x0/0x2d returned 0 after 6 usecs
> [    1.427529] calling  ikconfig_init+0x0/0x3a @ 1
> [    1.427542] initcall ikconfig_init+0x0/0x3a returned 0 after 3 usecs
> [    1.427552] calling  audit_init+0x0/0x141 @ 1
> [    1.427563] audit: initializing netlink socket (disabled)
> [    1.427590] type=2000 audit(1361569070.777:1): initialized
> [    1.427603] initcall audit_init+0x0/0x141 returned 0 after 38 usecs
> [    1.427613] calling  audit_watch_init+0x0/0x3a @ 1
> [    1.427624] initcall audit_watch_init+0x0/0x3a returned 0 after 0 usecs
> [    1.427636] calling  audit_tree_init+0x0/0x49 @ 1
> [    1.427647] initcall audit_tree_init+0x0/0x49 returned 0 after 0 usecs
> [    1.427656] calling  init_kprobes+0x0/0x16c @ 1
> [    1.439621] initcall init_kprobes+0x0/0x16c returned 0 after 11669 usecs
> [    1.439637] calling  hung_task_init+0x0/0x56 @ 1
> [    1.439718] initcall hung_task_init+0x0/0x56 returned 0 after 68 usecs
> [    1.439729] calling  irq_pm_init_ops+0x0/0x14 @ 1
> [    1.439738] initcall irq_pm_init_ops+0x0/0x14 returned 0 after 0 usecs
> [    1.439748] calling  utsname_sysctl_init+0x0/0x14 @ 1
> [    1.439767] initcall utsname_sysctl_init+0x0/0x14 returned 0 after 9 usecs
> [    1.439778] calling  init_tracepoints+0x0/0x20 @ 1
> [    1.439788] initcall init_tracepoints+0x0/0x20 returned 0 after 0 usecs
> [    1.439798] calling  init_blk_tracer+0x0/0x5a @ 1
> [    1.439808] initcall init_blk_tracer+0x0/0x5a returned 0 after 1 usecs
> [    1.439818] calling  perf_event_sysfs_init+0x0/0x9a @ 1
> [    1.440270] initcall perf_event_sysfs_init+0x0/0x9a returned 0 after 431 usecs
> [    1.440283] calling  init_per_zone_wmark_min+0x0/0x8c @ 1
> [    1.440420] initcall init_per_zone_wmark_min+0x0/0x8c returned 0 after 122 usecs
> [    1.440433] calling  kswapd_init+0x0/0x76 @ 1
> [    1.440489] initcall kswapd_init+0x0/0x76 returned 0 after 45 usecs
> [    1.440499] calling  extfrag_debug_init+0x0/0x7e @ 1
> [    1.440539] initcall extfrag_debug_init+0x0/0x7e returned 0 after 29 usecs
> [    1.440549] calling  setup_vmstat+0x0/0xc8 @ 1
> [    1.440578] initcall setup_vmstat+0x0/0xc8 returned 0 after 18 usecs
> [    1.440589] calling  mm_sysfs_init+0x0/0x29 @ 1
> [    1.440602] initcall mm_sysfs_init+0x0/0x29 returned 0 after 3 usecs
> [    1.440613] calling  slab_proc_init+0x0/0x25 @ 1
> [    1.440626] initcall slab_proc_init+0x0/0x25 returned 0 after 4 usecs
> [    1.440636] calling  proc_vmalloc_init+0x0/0x25 @ 1
> [    1.440650] initcall proc_vmalloc_init+0x0/0x25 returned 0 after 3 usecs
> [    1.440660] calling  procswaps_init+0x0/0x22 @ 1
> [    1.440673] initcall procswaps_init+0x0/0x22 returned 0 after 3 usecs
> [    1.440684] calling  init_frontswap+0x0/0x96 @ 1
> [    1.440737] initcall init_frontswap+0x0/0x96 returned 0 after 43 usecs
> [    1.440749] calling  hugetlb_init+0x0/0x415 @ 1
> [    1.440759] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    1.440788] initcall hugetlb_init+0x0/0x415 returned 0 after 28 usecs
> [    1.440797] calling  mmu_notifier_init+0x0/0x12 @ 1
> [    1.440810] initcall mmu_notifier_init+0x0/0x12 returned 0 after 2 usecs
> [    1.440821] calling  slab_proc_init+0x0/0x8 @ 1
> [    1.440831] initcall slab_proc_init+0x0/0x8 returned 0 after 0 usecs
> [    1.440840] calling  cpucache_init+0x0/0x52 @ 1
> [    1.440851] initcall cpucache_init+0x0/0x52 returned 0 after 1 usecs
> [    1.440861] calling  hugepage_init+0x0/0x191 @ 1
> [    1.440870] initcall hugepage_init+0x0/0x191 returned -22 after 0 usecs
> [    1.440880] initcall hugepage_init+0x0/0x191 returned with error code -22
> [    1.440890] calling  init_cleancache+0x0/0x96 @ 1
> [    1.440939] initcall init_cleancache+0x0/0x96 returned 0 after 38 usecs
> [    1.440949] calling  fcntl_init+0x0/0x2a @ 1
> [    1.440964] initcall fcntl_init+0x0/0x2a returned 0 after 5 usecs
> [    1.440974] calling  proc_filesystems_init+0x0/0x22 @ 1
> [    1.440991] initcall proc_filesystems_init+0x0/0x22 returned 0 after 7 usecs
> [    1.441002] calling  dio_init+0x0/0x2d @ 1
> [    1.441016] initcall dio_init+0x0/0x2d returned 0 after 5 usecs
> [    1.441025] calling  fsnotify_mark_init+0x0/0x40 @ 1
> [    1.441109] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 71 usecs
> [    1.441119] calling  dnotify_init+0x0/0x7b @ 1
> [    1.441137] initcall dnotify_init+0x0/0x7b returned 0 after 8 usecs
> [    1.441146] calling  inotify_user_setup+0x0/0x70 @ 1
> [    1.441163] initcall inotify_user_setup+0x0/0x70 returned 0 after 7 usecs
> [    1.441173] calling  aio_setup+0x0/0x7c @ 1
> [    1.441192] initcall aio_setup+0x0/0x7c returned 0 after 9 usecs
> [    1.627775] calling  proc_locks_init+0x0/0x22 @ 1
> [    1.627796] initcall proc_locks_init+0x0/0x22 returned 0 after 9 usecs
> [    1.627806] calling  init_sys32_ioctl+0x0/0x28 @ 1
> [    1.627885] initcall init_sys32_ioctl+0x0/0x28 returned 0 after 67 usecs
> [    1.627895] calling  dquot_init+0x0/0x121 @ 1
> [    1.627904] VFS: Disk quotas dquot_6.5.2
> [    1.627962] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    1.627974] initcall dquot_init+0x0/0x121 returned 0 after 66 usecs
> [    1.627985] calling  init_v2_quota_format+0x0/0x22 @ 1
> [    1.627996] initcall init_v2_quota_format+0x0/0x22 returned 0 after 1 usecs
> [    1.628006] calling  quota_init+0x0/0x26 @ 1
> [    1.628027] initcall quota_init+0x0/0x26 returned 0 after 10 usecs
> [    1.628037] calling  proc_cmdline_init+0x0/0x22 @ 1
> [    1.628072] initcall proc_cmdline_init+0x0/0x22 returned 0 after 22 usecs
> [    1.628088] calling  proc_consoles_init+0x0/0x22 @ 1
> [    1.628105] initcall proc_consoles_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628115] calling  proc_cpuinfo_init+0x0/0x22 @ 1
> [    1.628129] initcall proc_cpuinfo_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628140] calling  proc_devices_init+0x0/0x22 @ 1
> [    1.628154] initcall proc_devices_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628165] calling  proc_interrupts_init+0x0/0x22 @ 1
> [    1.628179] initcall proc_interrupts_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628189] calling  proc_loadavg_init+0x0/0x22 @ 1
> [    1.628204] initcall proc_loadavg_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628214] calling  proc_meminfo_init+0x0/0x22 @ 1
> [    1.628228] initcall proc_meminfo_init+0x0/0x22 returned 0 after 3 usecs
> [    1.628237] calling  proc_stat_init+0x0/0x22 @ 1
> [    1.628251] initcall proc_stat_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628261] calling  proc_uptime_init+0x0/0x22 @ 1
> [    1.628275] initcall proc_uptime_init+0x0/0x22 returned 0 after 4 usecs
> [    1.628287] calling  proc_version_init+0x0/0x22 @ 1
> [    1.628300] initcall proc_version_init+0x0/0x22 returned 0 after 3 usecs
> [    1.645978] calling  proc_softirqs_init+0x0/0x22 @ 1
> [    1.646001] initcall proc_softirqs_init+0x0/0x22 returned 0 after 10 usecs
> [    1.646012] calling  proc_kcore_init+0x0/0xb5 @ 1
> [    1.646032] initcall proc_kcore_init+0x0/0xb5 returned 0 after 8 usecs
> [    1.646042] calling  vmcore_init+0x0/0x370 @ 1
> [    1.646052] initcall vmcore_init+0x0/0x370 returned 0 after 0 usecs
> [    1.646063] calling  proc_kmsg_init+0x0/0x25 @ 1
> [    1.646076] initcall proc_kmsg_init+0x0/0x25 returned 0 after 3 usecs
> [    1.646086] calling  proc_page_init+0x0/0x42 @ 1
> [    1.646104] initcall proc_page_init+0x0/0x42 returned 0 after 7 usecs
> [    1.646125] calling  init_devpts_fs+0x0/0x62 @ 1
> [    1.646192] initcall init_devpts_fs+0x0/0x62 returned 0 after 54 usecs
> [    1.646203] calling  init_ramfs_fs+0x0/0x12 @ 1
> [    1.646213] initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.646224] calling  init_hugetlbfs_fs+0x0/0x15d @ 1
> [    1.646302] initcall init_hugetlbfs_fs+0x0/0x15d returned 0 after 66 usecs
> [    1.646313] calling  init_fat_fs+0x0/0x4f @ 1
> [    1.646329] initcall init_fat_fs+0x0/0x4f returned 0 after 6 usecs
> [    1.646340] calling  init_vfat_fs+0x0/0x12 @ 1
> [    1.646350] initcall init_vfat_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.646360] calling  init_msdos_fs+0x0/0x12 @ 1
> [    1.646370] initcall init_msdos_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.646380] calling  init_iso9660_fs+0x0/0x70 @ 1
> [    1.646412] initcall init_iso9660_fs+0x0/0x70 returned 0 after 22 usecs
> [    1.646422] calling  init_nfs_fs+0x0/0x16c @ 1
> [    1.646598] initcall init_nfs_fs+0x0/0x16c returned 0 after 162 usecs
> [    1.646609] calling  init_nfs_v2+0x0/0x14 @ 1
> [    1.646619] initcall init_nfs_v2+0x0/0x14 returned 0 after 0 usecs
> [    1.646629] calling  init_nfs_v3+0x0/0x14 @ 1
> [    1.646639] initcall init_nfs_v3+0x0/0x14 returned 0 after 0 usecs
> [    1.646649] calling  init_nfs_v4+0x0/0x3b @ 1
> [    1.646658] NFS: Registering the id_resolver key type
> [    1.646685] Key type id_resolver registered
> [    1.646694] Key type id_legacy registered
> [    1.646708] initcall init_nfs_v4+0x0/0x3b returned 0 after 47 usecs
> [    1.646717] calling  init_nlm+0x0/0x4c @ 1
> [    1.646732] initcall init_nlm+0x0/0x4c returned 0 after 6 usecs
> [    1.646742] calling  init_nls_cp437+0x0/0x12 @ 1
> [    1.646752] initcall init_nls_cp437+0x0/0x12 returned 0 after 1 usecs
> [    1.646760] calling  init_nls_ascii+0x0/0x12 @ 1
> [    1.646770] initcall init_nls_ascii+0x0/0x12 returned 0 after 0 usecs
> [    1.646780] calling  init_nls_iso8859_1+0x0/0x12 @ 1
> [    1.646790] initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 usecs
> [    1.646799] calling  init_nls_utf8+0x0/0x2b @ 1
> [    1.646810] initcall init_nls_utf8+0x0/0x2b returned 0 after 0 usecs
> [    1.646819] calling  init_ntfs_fs+0x0/0x1d1 @ 1
> [    1.646827] NTFS driver 2.1.30 [Flags: R/W].
> [    1.646853] initcall init_ntfs_fs+0x0/0x1d1 returned 0 after 23 usecs
> [    1.646863] calling  init_autofs4_fs+0x0/0x2a @ 1
> [    1.647010] initcall init_autofs4_fs+0x0/0x2a returned 0 after 133 usecs
> [    1.647019] calling  init_pstore_fs+0x0/0x12 @ 1
> [    1.647030] initcall init_pstore_fs+0x0/0x12 returned 0 after 0 usecs
> [    1.647040] calling  ipc_init+0x0/0x2f @ 1
> [    1.647079] msgmni has been set to 2923
> [    1.647097] initcall ipc_init+0x0/0x2f returned 0 after 46 usecs
> [    1.647106] calling  ipc_sysctl_init+0x0/0x14 @ 1
> [    1.647123] initcall ipc_sysctl_init+0x0/0x14 returned 0 after 6 usecs
> [    1.647132] calling  init_mqueue_fs+0x0/0xa2 @ 1
> [    1.647183] initcall init_mqueue_fs+0x0/0xa2 returned 0 after 40 usecs
> [    1.647193] calling  key_proc_init+0x0/0x5e @ 1
> [    1.647210] initcall key_proc_init+0x0/0x5e returned 0 after 7 usecs
> [    1.647220] calling  selinux_nf_ip_init+0x0/0x69 @ 1
> [    1.647228] SELinux:  Registering netfilter hooks
> [    1.647457] initcall selinux_nf_ip_init+0x0/0x69 returned 0 after 222 usecs
> [    1.647467] calling  init_sel_fs+0x0/0xa5 @ 1
> [    1.647812] initcall init_sel_fs+0x0/0xa5 returned 0 after 327 usecs
> [    1.647822] calling  selnl_init+0x0/0x56 @ 1
> [    1.647839] initcall selnl_init+0x0/0x56 returned 0 after 7 usecs
> [    1.647848] calling  sel_netif_init+0x0/0x5c @ 1
> [    1.647860] initcall sel_netif_init+0x0/0x5c returned 0 after 2 usecs
> [    1.647870] calling  sel_netnode_init+0x0/0x6a @ 1
> [    1.647880] initcall sel_netnode_init+0x0/0x6a returned 0 after 1 usecs
> [    1.647889] calling  sel_netport_init+0x0/0x6a @ 1
> [    1.647900] initcall sel_netport_init+0x0/0x6a returned 0 after 1 usecs
> [    1.647909] calling  aurule_init+0x0/0x2d @ 1
> [    1.647921] initcall aurule_init+0x0/0x2d returned 0 after 0 usecs
> [    1.647932] calling  crypto_wq_init+0x0/0x33 @ 1
> [    1.647976] initcall crypto_wq_init+0x0/0x33 returned 0 after 33 usecs
> [    1.647986] calling  crypto_algapi_init+0x0/0xd @ 1
> [    1.647999] initcall crypto_algapi_init+0x0/0xd returned 0 after 4 usecs
> [    1.829390] calling  skcipher_module_init+0x0/0x35 @ 1
> [    1.829403] initcall skcipher_module_init+0x0/0x35 returned 0 after 0 usecs
> [    1.829414] calling  chainiv_module_init+0x0/0x12 @ 1
> [    1.829425] initcall chainiv_module_init+0x0/0x12 returned 0 after 1 usecs
> [    1.829435] calling  eseqiv_module_init+0x0/0x12 @ 1
> [    1.829445] initcall eseqiv_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.829455] calling  hmac_module_init+0x0/0x12 @ 1
> [    1.829464] initcall hmac_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.829474] calling  md5_mod_init+0x0/0x12 @ 1
> [    1.829598] initcall md5_mod_init+0x0/0x12 returned 0 after 111 usecs
> [    1.829609] calling  sha1_generic_mod_init+0x0/0x12 @ 1
> [    1.829676] initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 55 usecs
> [    1.829687] calling  crypto_cbc_module_init+0x0/0x12 @ 1
> [    1.829696] initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.829706] calling  des_generic_mod_init+0x0/0x17 @ 1
> [    1.829828] initcall des_generic_mod_init+0x0/0x17 returned 0 after 109 usecs
> [    1.829839] calling  aes_init+0x0/0x12 @ 1
> [    1.829904] initcall aes_init+0x0/0x12 returned 0 after 54 usecs
> [    1.829917] calling  zlib_mod_init+0x0/0x12 @ 1
> [    1.829983] initcall zlib_mod_init+0x0/0x12 returned 0 after 55 usecs
> [    1.829995] calling  crypto_authenc_module_init+0x0/0x12 @ 1
> [    1.830005] initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.830016] calling  crypto_authenc_esn_module_init+0x0/0x12 @ 1
> [    1.830026] initcall crypto_authenc_esn_module_init+0x0/0x12 returned 0 after 0 usecs
> [    1.830037] calling  lzo_mod_init+0x0/0x12 @ 1
> [    1.830133] initcall lzo_mod_init+0x0/0x12 returned 0 after 84 usecs
> [    1.830143] calling  krng_mod_init+0x0/0x12 @ 1
> [    1.830208] initcall krng_mod_init+0x0/0x12 returned 0 after 53 usecs
> [    1.830219] calling  proc_genhd_init+0x0/0x3c @ 1
> [    1.830241] initcall proc_genhd_init+0x0/0x3c returned 0 after 11 usecs
> [    1.830251] calling  bsg_init+0x0/0x12e @ 1
> [    1.830364] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> [    1.830375] initcall bsg_init+0x0/0x12e returned 0 after 112 usecs
> [    1.830385] calling  noop_init+0x0/0x12 @ 1
> [    1.830394] io scheduler noop registered
> [    1.830403] initcall noop_init+0x0/0x12 returned 0 after 9 usecs
> [    1.830412] calling  deadline_init+0x0/0x12 @ 1
> [    1.830421] io scheduler deadline registered
> [    1.830430] initcall deadline_init+0x0/0x12 returned 0 after 8 usecs
> [    1.830439] calling  cfq_init+0x0/0x8b @ 1
> [    1.830456] io scheduler cfq registered (default)
> [    1.830466] initcall cfq_init+0x0/0x8b returned 0 after 16 usecs
> [    1.830475] calling  percpu_counter_startup+0x0/0x38 @ 1
> [    1.830488] initcall percpu_counter_startup+0x0/0x38 returned 0 after 2 usecs
> [    1.830498] calling  pci_proc_init+0x0/0x6a @ 1
> [    1.830517] initcall pci_proc_init+0x0/0x6a returned 0 after 9 usecs
> [    1.830527] calling  pcie_portdrv_init+0x0/0x7a @ 1
> [    1.830717] initcall pcie_portdrv_init+0x0/0x7a returned 0 after 175 usecs
> [    1.830729] calling  aer_service_init+0x0/0x2b @ 1
> [    1.830742] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
> [    1.830762] IP: [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> [    1.830780] PGD 0
> [    1.830791] Oops: 0000 [#1] SMP
> [    1.830806] Modules linked in:
> [    1.830819] CPU 0
> [    1.830827] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc2upstream-00002-g92ef2a2 #1
> [    1.830838] RIP: e030:[<ffffffff813862fa>]  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> [    1.830853] RSP: e02b:ffff88005bb69e98  EFLAGS: 00010246
> [    1.830862] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000017
> [    1.830871] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81328b30
> [    1.830880] RBP: ffff88005bb69eb8 R08: 00000000833df7a7 R09: 0720072007200720
> [    1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
> [    1.830899] R13: ffffffff81328b30 R14: 0000000000000000 R15: 0000000000000000
> [    1.830913] FS:  0000000000000000(0000) GS:ffff88005d600000(0000) knlGS:0000000000000000
> [    1.830926] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    1.830935] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000040660
> [    1.830945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [    1.830955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [    1.830965] Process swapper/0 (pid: 1, threadinfo ffff88005bb68000, task ffff88005bb627f0)
> [    1.830975] Stack:
> [    1.830981]  0000000000000030 0000000000000000 ffffffff81ae8f60 000000006d1ed4e7
> [    1.831007]  ffff88005bb69ec8 ffffffff81328b8b ffff88005bb69ed8 ffffffff81ae8f72
> [    1.831033]  ffff88005bb69f08 ffffffff81002124 0000000000000030 0000000000000007
> [    1.831057] Call Trace:
> [    1.831057]  [<ffffffff81ae8f60>] ? pcie_portdrv_init+0x7a/0x7a
> [    1.831057]  [<ffffffff81328b8b>] aer_acpi_firmware_first+0x1b/0x30
> [    1.831057]  [<ffffffff81ae8f72>] aer_service_init+0x12/0x2b
> [    1.831057]  [<ffffffff81002124>] do_one_initcall+0x124/0x170
> [    1.831057]  [<ffffffff81645404>] kernel_init+0x174/0x2f0
> [    1.831057]  [<ffffffff81abd5ca>] ? parse_early_options+0x2b/0x2b
> [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> [    1.831057]  [<ffffffff81663ffc>] ret_from_fork+0x7c/0xb0
> [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> [    1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d
> [    1.831057] RIP  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> [    1.831057]  RSP <ffff88005bb69e98>
> [    1.831057] CR2: 0000000000000024
> [    2.028436] ---[ end trace dad4411f23c0dcf5 ]---
> [    2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
> [    2.028476] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [    2.028476]
> Parsing config from test.xm
> Daemon running with PID 5069
>


https://patchwork.kernel.org/patch/2175871/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 00:28:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 00: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 1U92y3-0007Ve-Lb; Sat, 23 Feb 2013 00:27: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 1U92y1-0007VZ-V8
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 00:27:54 +0000
Received: from [85.158.139.83:19776] by server-6.bemta-5.messagelabs.com id
	A0/70-01489-90D08215; Sat, 23 Feb 2013 00:27:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361579272!27866984!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9599 invoked from network); 23 Feb 2013 00:27:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 00:27:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,719,1355097600"; 
   d="scan'208";a="1804164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 00:27: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.297.1; Sat, 23 Feb 2013 00:27:51 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U92xz-0004vV-Ky;
	Sat, 23 Feb 2013 00:27:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U92xz-0007ld-1p;
	Sat, 23 Feb 2013 00:27:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16228-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 00:27:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing baseline test] 16228: 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 16228 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16228/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemut-win-vcpus1  3 host-install(3)   broken baseline untested

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       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-i386-qemut-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             broken  
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 Feb 23 00:28:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 00: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 1U92y3-0007Ve-Lb; Sat, 23 Feb 2013 00:27: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 1U92y1-0007VZ-V8
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 00:27:54 +0000
Received: from [85.158.139.83:19776] by server-6.bemta-5.messagelabs.com id
	A0/70-01489-90D08215; Sat, 23 Feb 2013 00:27:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361579272!27866984!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzNzIy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9599 invoked from network); 23 Feb 2013 00:27:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 00:27:52 -0000
X-IronPort-AV: E=Sophos;i="4.84,719,1355097600"; 
   d="scan'208";a="1804164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 00:27: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.297.1; Sat, 23 Feb 2013 00:27:51 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U92xz-0004vV-Ky;
	Sat, 23 Feb 2013 00:27:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U92xz-0007ld-1p;
	Sat, 23 Feb 2013 00:27:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16228-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 00:27:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing baseline test] 16228: 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 16228 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16228/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-qemut-win-vcpus1  3 host-install(3)   broken baseline untested

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       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-i386-qemut-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             broken  
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 Feb 23 01:07:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 01: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 1U93ZJ-00043n-Sx; Sat, 23 Feb 2013 01:06:25 +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 1U93ZI-00043i-Tf
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 01:06:25 +0000
Received: from [193.109.254.147:26957] by server-9.bemta-14.messagelabs.com id
	A4/CA-30867-01618215; Sat, 23 Feb 2013 01:06:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361581579!1680392!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTQ1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19377 invoked from network); 23 Feb 2013 01:06:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 01:06:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1N16DBS007982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 01:06: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
	r1N16CMG008877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 01:06:12 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
	r1N168v5013979; Fri, 22 Feb 2013 19:06:08 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 17:06:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 763701C3935; Fri, 22 Feb 2013 20:06:07 -0500 (EST)
Date: Fri, 22 Feb 2013 20:06:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Samu Kallio <samu.kallio@aberdeencloud.com>, mingo@redhat.com
Message-ID: <20130223010607.GA15337@phenom.dumpdata.com>
References: <1361068552-21529-1-git-send-email-samu.kallio@aberdeencloud.com>
	<20130221123306.GA6781@phenom.dumpdata.com>
	<CAOn_CrHifkBieZumEBje1FiSU3abJrZ8QRKK4FGkKbp217He9w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOn_CrHifkBieZumEBje1FiSU3abJrZ8QRKK4FGkKbp217He9w@mail.gmail.com>
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,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] x86: mm: Fix vmalloc_fault oops during lazy MMU
	updates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 05:56:35PM +0200, Samu Kallio wrote:
> On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Sun, Feb 17, 2013 at 02:35:52AM -0000, Samu Kallio wrote:
> >> In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
> >> when lazy MMU updates are enabled, because set_pgd effects are being
> >> deferred.
> >>
> >> One instance of this problem is during process mm cleanup with memory
> >> cgroups enabled. The chain of events is as follows:
> >>
> >> - zap_pte_range enables lazy MMU updates
> >> - zap_pte_range eventually calls mem_cgroup_charge_statistics,
> >>   which accesses the vmalloc'd mem_cgroup per-cpu stat area
> >> - vmalloc_fault is triggered which tries to sync the corresponding
> >>   PGD entry with set_pgd, but the update is deferred
> >> - vmalloc_fault oopses due to a mismatch in the PUD entries
> >>
> >> Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
> >> changes visible to the consistency checks.
> >
> > How do you reproduce this? Is there a BUG() or WARN() trace that
> > is triggered when this happens?
> 
> In my case I've seen this triggered on an Amazon EC2 (Xen PV) instance
> under heavy load spawning many LXC containers. The best I can say at
> this point is that the frequency of this bug seems to be linked to how
> busy the machine is.
> 
> The earliest report of this problem was from 3.3:
>     http://comments.gmane.org/gmane.linux.kernel.cgroups/5540
> I can personally confirm the issue since 3.5.
> 
> Here's a sample bug report from a 3.7 kernel (vanilla with Xen XSAVE patch
> for EC2 compatibility). The latest kernel version I have tested and seen this
> problem occur is 3.7.9.

Ingo,

I am OK with this patch. Are you OK taking this in or should I take
it (and add the nice RIP below)?

It should also have CC: stable@vger.kernel.org on it.

FYI, There is also a Red Hat bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=914737

> 
> [11852214.733630] ------------[ cut here ]------------
> [11852214.733642] kernel BUG at arch/x86/mm/fault.c:397!
> [11852214.733648] invalid opcode: 0000 [#1] SMP
> [11852214.733654] Modules linked in: veth xt_nat xt_comment fuse btrfs
> libcrc32c zlib_deflate ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat
> xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
> bridge stp llc iptable_filter ip_tables x_tables ghash_clmulni_intel
> aesni_intel aes_x86_64 ablk_helper cryptd xts lrw gf128mul microcode
> ext4 crc16 jbd2 mbcache
> [11852214.733695] CPU 1
> [11852214.733700] Pid: 1617, comm: qmgr Not tainted 3.7.0-1-ec2 #1
> [11852214.733705] RIP: e030:[<ffffffff8143018d>]  [<ffffffff8143018d>]
> vmalloc_fault+0x14b/0x249
> [11852214.733725] RSP: e02b:ffff88083e57d7f8  EFLAGS: 00010046
> [11852214.733730] RAX: 0000000854046000 RBX: ffffe8ffffc80d70 RCX:
> ffff880000000000
> [11852214.733736] RDX: 00003ffffffff000 RSI: ffff880854046ff8 RDI:
> 0000000000000000
> [11852214.733744] RBP: ffff88083e57d818 R08: 0000000000000000 R09:
> ffff880000000ff8
> [11852214.733750] R10: 0000000000007ff0 R11: 0000000000000001 R12:
> ffff880854686e88
> [11852214.733758] R13: ffffffff8180ce88 R14: ffff88083e57d948 R15:
> 0000000000000000
> [11852214.733768] FS:  00007ff3bf0f8740(0000)
> GS:ffff88088b480000(0000) knlGS:0000000000000000
> [11852214.733777] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [11852214.733782] CR2: ffffe8ffffc80d70 CR3: 0000000854686000 CR4:
> 0000000000002660
> [11852214.733790] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [11852214.733796] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [11852214.733803] Process qmgr (pid: 1617, threadinfo
> ffff88083e57c000, task ffff88084474b3e0)
> [11852214.733810] Stack:
> [11852214.733814]  0000000000000029 0000000000000002 ffffe8ffffc80d70
> ffff88083e57d948
> [11852214.733828]  ffff88083e57d928 ffffffff8103e0c7 0000000000000000
> ffff88083e57d8d0
> [11852214.733840]  ffff88084474b3e0 0000000000000060 0000000000000000
> 0000000000006cf6
> [11852214.733852] Call Trace:
> [11852214.733861]  [<ffffffff8103e0c7>] __do_page_fault+0x2c7/0x4a0
> [11852214.733871]  [<ffffffff81004ac2>] ? xen_mc_flush+0xb2/0x1b0
> [11852214.733880]  [<ffffffff810032ce>] ? xen_end_context_switch+0x1e/0x30
> [11852214.733888]  [<ffffffff810043cb>] ? xen_write_msr_safe+0x9b/0xc0
> [11852214.733900]  [<ffffffff810125b3>] ? __switch_to+0x163/0x4a0
> [11852214.733907]  [<ffffffff8103e2de>] do_page_fault+0xe/0x10
> [11852214.733919]  [<ffffffff81437f98>] page_fault+0x28/0x30
> [11852214.733930]  [<ffffffff8115e873>] ?
> mem_cgroup_charge_statistics.isra.12+0x13/0x50
> [11852214.733940]  [<ffffffff8116012e>] __mem_cgroup_uncharge_common+0xce/0x2d0
> [11852214.733948]  [<ffffffff81007fee>] ? xen_pte_val+0xe/0x10
> [11852214.733958]  [<ffffffff8116391a>] mem_cgroup_uncharge_page+0x2a/0x30
> [11852214.733966]  [<ffffffff81139e78>] page_remove_rmap+0xf8/0x150
> [11852214.733976]  [<ffffffff8112d78a>] ? vm_normal_page+0x1a/0x80
> [11852214.733984]  [<ffffffff8112e5b3>] unmap_single_vma+0x573/0x860
> [11852214.733994]  [<ffffffff81114520>] ? release_pages+0x1f0/0x230
> [11852214.734004]  [<ffffffff810054aa>] ? __xen_pgd_walk+0x16a/0x260
> [11852214.734018]  [<ffffffff8112f0b2>] unmap_vmas+0x52/0xa0
> [11852214.734026]  [<ffffffff81136e08>] exit_mmap+0x98/0x170
> [11852214.734034]  [<ffffffff8104b929>] mmput+0x59/0x110
> [11852214.734043]  [<ffffffff81053d95>] exit_mm+0x105/0x130
> [11852214.734051]  [<ffffffff814376e0>] ? _raw_spin_lock_irq+0x10/0x40
> [11852214.734059]  [<ffffffff81053f27>] do_exit+0x167/0x900
> [11852214.734070]  [<ffffffff8106093d>] ? __sigqueue_free+0x3d/0x50
> [11852214.734079]  [<ffffffff81060b9e>] ? __dequeue_signal+0x10e/0x1f0
> [11852214.734087]  [<ffffffff810549ff>] do_group_exit+0x3f/0xb0
> [11852214.734097]  [<ffffffff81063431>] get_signal_to_deliver+0x1c1/0x5e0
> [11852214.734107]  [<ffffffff8101334f>] do_signal+0x3f/0x960
> [11852214.734114]  [<ffffffff811aae61>] ? ep_poll+0x2a1/0x360
> [11852214.734122]  [<ffffffff81083420>] ? try_to_wake_up+0x2d0/0x2d0
> [11852214.734129]  [<ffffffff81013cd8>] do_notify_resume+0x48/0x60
> [11852214.734138]  [<ffffffff81438a5a>] int_signal+0x12/0x17
> [11852214.734143] Code: ff ff 3f 00 00 48 21 d0 4c 8d 0c 30 ff 14 25
> b8 f3 81 81 48 21 d0 48 01 c6 48 83 3e 00 0f 84 fa 00 00 00 49 8b 39
> 48 85 ff 75 02 <0f> 0b ff 14 25 e0 f3 81 81 49 89 c0 48 8b 3e ff 14 25
> e0 f3 81
> [11852214.734212] RIP  [<ffffffff8143018d>] vmalloc_fault+0x14b/0x249
> [11852214.734222]  RSP <ffff88083e57d7f8>
> [11852214.734231] ---[ end trace 81ac798210f95867 ]---
> [11852214.734237] Fixing recursive fault but reboot is needed!
> 
> > Also pls next time also CC me.
> 
> Will do, I originally CC'd Jeremy since made some lazy MMU related
> cleanups in arch/x86/mm/fault.c, and I thought he might have a comment
> on this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 01:07:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 01: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 1U93ZJ-00043n-Sx; Sat, 23 Feb 2013 01:06:25 +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 1U93ZI-00043i-Tf
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 01:06:25 +0000
Received: from [193.109.254.147:26957] by server-9.bemta-14.messagelabs.com id
	A4/CA-30867-01618215; Sat, 23 Feb 2013 01:06:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361581579!1680392!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTQ1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19377 invoked from network); 23 Feb 2013 01:06:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 01:06:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1N16DBS007982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 01:06: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
	r1N16CMG008877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 01:06:12 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
	r1N168v5013979; Fri, 22 Feb 2013 19:06:08 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 17:06:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 763701C3935; Fri, 22 Feb 2013 20:06:07 -0500 (EST)
Date: Fri, 22 Feb 2013 20:06:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Samu Kallio <samu.kallio@aberdeencloud.com>, mingo@redhat.com
Message-ID: <20130223010607.GA15337@phenom.dumpdata.com>
References: <1361068552-21529-1-git-send-email-samu.kallio@aberdeencloud.com>
	<20130221123306.GA6781@phenom.dumpdata.com>
	<CAOn_CrHifkBieZumEBje1FiSU3abJrZ8QRKK4FGkKbp217He9w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOn_CrHifkBieZumEBje1FiSU3abJrZ8QRKK4FGkKbp217He9w@mail.gmail.com>
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,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] x86: mm: Fix vmalloc_fault oops during lazy MMU
	updates.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 21, 2013 at 05:56:35PM +0200, Samu Kallio wrote:
> On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Sun, Feb 17, 2013 at 02:35:52AM -0000, Samu Kallio wrote:
> >> In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
> >> when lazy MMU updates are enabled, because set_pgd effects are being
> >> deferred.
> >>
> >> One instance of this problem is during process mm cleanup with memory
> >> cgroups enabled. The chain of events is as follows:
> >>
> >> - zap_pte_range enables lazy MMU updates
> >> - zap_pte_range eventually calls mem_cgroup_charge_statistics,
> >>   which accesses the vmalloc'd mem_cgroup per-cpu stat area
> >> - vmalloc_fault is triggered which tries to sync the corresponding
> >>   PGD entry with set_pgd, but the update is deferred
> >> - vmalloc_fault oopses due to a mismatch in the PUD entries
> >>
> >> Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
> >> changes visible to the consistency checks.
> >
> > How do you reproduce this? Is there a BUG() or WARN() trace that
> > is triggered when this happens?
> 
> In my case I've seen this triggered on an Amazon EC2 (Xen PV) instance
> under heavy load spawning many LXC containers. The best I can say at
> this point is that the frequency of this bug seems to be linked to how
> busy the machine is.
> 
> The earliest report of this problem was from 3.3:
>     http://comments.gmane.org/gmane.linux.kernel.cgroups/5540
> I can personally confirm the issue since 3.5.
> 
> Here's a sample bug report from a 3.7 kernel (vanilla with Xen XSAVE patch
> for EC2 compatibility). The latest kernel version I have tested and seen this
> problem occur is 3.7.9.

Ingo,

I am OK with this patch. Are you OK taking this in or should I take
it (and add the nice RIP below)?

It should also have CC: stable@vger.kernel.org on it.

FYI, There is also a Red Hat bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=914737

> 
> [11852214.733630] ------------[ cut here ]------------
> [11852214.733642] kernel BUG at arch/x86/mm/fault.c:397!
> [11852214.733648] invalid opcode: 0000 [#1] SMP
> [11852214.733654] Modules linked in: veth xt_nat xt_comment fuse btrfs
> libcrc32c zlib_deflate ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat
> xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
> bridge stp llc iptable_filter ip_tables x_tables ghash_clmulni_intel
> aesni_intel aes_x86_64 ablk_helper cryptd xts lrw gf128mul microcode
> ext4 crc16 jbd2 mbcache
> [11852214.733695] CPU 1
> [11852214.733700] Pid: 1617, comm: qmgr Not tainted 3.7.0-1-ec2 #1
> [11852214.733705] RIP: e030:[<ffffffff8143018d>]  [<ffffffff8143018d>]
> vmalloc_fault+0x14b/0x249
> [11852214.733725] RSP: e02b:ffff88083e57d7f8  EFLAGS: 00010046
> [11852214.733730] RAX: 0000000854046000 RBX: ffffe8ffffc80d70 RCX:
> ffff880000000000
> [11852214.733736] RDX: 00003ffffffff000 RSI: ffff880854046ff8 RDI:
> 0000000000000000
> [11852214.733744] RBP: ffff88083e57d818 R08: 0000000000000000 R09:
> ffff880000000ff8
> [11852214.733750] R10: 0000000000007ff0 R11: 0000000000000001 R12:
> ffff880854686e88
> [11852214.733758] R13: ffffffff8180ce88 R14: ffff88083e57d948 R15:
> 0000000000000000
> [11852214.733768] FS:  00007ff3bf0f8740(0000)
> GS:ffff88088b480000(0000) knlGS:0000000000000000
> [11852214.733777] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [11852214.733782] CR2: ffffe8ffffc80d70 CR3: 0000000854686000 CR4:
> 0000000000002660
> [11852214.733790] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [11852214.733796] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [11852214.733803] Process qmgr (pid: 1617, threadinfo
> ffff88083e57c000, task ffff88084474b3e0)
> [11852214.733810] Stack:
> [11852214.733814]  0000000000000029 0000000000000002 ffffe8ffffc80d70
> ffff88083e57d948
> [11852214.733828]  ffff88083e57d928 ffffffff8103e0c7 0000000000000000
> ffff88083e57d8d0
> [11852214.733840]  ffff88084474b3e0 0000000000000060 0000000000000000
> 0000000000006cf6
> [11852214.733852] Call Trace:
> [11852214.733861]  [<ffffffff8103e0c7>] __do_page_fault+0x2c7/0x4a0
> [11852214.733871]  [<ffffffff81004ac2>] ? xen_mc_flush+0xb2/0x1b0
> [11852214.733880]  [<ffffffff810032ce>] ? xen_end_context_switch+0x1e/0x30
> [11852214.733888]  [<ffffffff810043cb>] ? xen_write_msr_safe+0x9b/0xc0
> [11852214.733900]  [<ffffffff810125b3>] ? __switch_to+0x163/0x4a0
> [11852214.733907]  [<ffffffff8103e2de>] do_page_fault+0xe/0x10
> [11852214.733919]  [<ffffffff81437f98>] page_fault+0x28/0x30
> [11852214.733930]  [<ffffffff8115e873>] ?
> mem_cgroup_charge_statistics.isra.12+0x13/0x50
> [11852214.733940]  [<ffffffff8116012e>] __mem_cgroup_uncharge_common+0xce/0x2d0
> [11852214.733948]  [<ffffffff81007fee>] ? xen_pte_val+0xe/0x10
> [11852214.733958]  [<ffffffff8116391a>] mem_cgroup_uncharge_page+0x2a/0x30
> [11852214.733966]  [<ffffffff81139e78>] page_remove_rmap+0xf8/0x150
> [11852214.733976]  [<ffffffff8112d78a>] ? vm_normal_page+0x1a/0x80
> [11852214.733984]  [<ffffffff8112e5b3>] unmap_single_vma+0x573/0x860
> [11852214.733994]  [<ffffffff81114520>] ? release_pages+0x1f0/0x230
> [11852214.734004]  [<ffffffff810054aa>] ? __xen_pgd_walk+0x16a/0x260
> [11852214.734018]  [<ffffffff8112f0b2>] unmap_vmas+0x52/0xa0
> [11852214.734026]  [<ffffffff81136e08>] exit_mmap+0x98/0x170
> [11852214.734034]  [<ffffffff8104b929>] mmput+0x59/0x110
> [11852214.734043]  [<ffffffff81053d95>] exit_mm+0x105/0x130
> [11852214.734051]  [<ffffffff814376e0>] ? _raw_spin_lock_irq+0x10/0x40
> [11852214.734059]  [<ffffffff81053f27>] do_exit+0x167/0x900
> [11852214.734070]  [<ffffffff8106093d>] ? __sigqueue_free+0x3d/0x50
> [11852214.734079]  [<ffffffff81060b9e>] ? __dequeue_signal+0x10e/0x1f0
> [11852214.734087]  [<ffffffff810549ff>] do_group_exit+0x3f/0xb0
> [11852214.734097]  [<ffffffff81063431>] get_signal_to_deliver+0x1c1/0x5e0
> [11852214.734107]  [<ffffffff8101334f>] do_signal+0x3f/0x960
> [11852214.734114]  [<ffffffff811aae61>] ? ep_poll+0x2a1/0x360
> [11852214.734122]  [<ffffffff81083420>] ? try_to_wake_up+0x2d0/0x2d0
> [11852214.734129]  [<ffffffff81013cd8>] do_notify_resume+0x48/0x60
> [11852214.734138]  [<ffffffff81438a5a>] int_signal+0x12/0x17
> [11852214.734143] Code: ff ff 3f 00 00 48 21 d0 4c 8d 0c 30 ff 14 25
> b8 f3 81 81 48 21 d0 48 01 c6 48 83 3e 00 0f 84 fa 00 00 00 49 8b 39
> 48 85 ff 75 02 <0f> 0b ff 14 25 e0 f3 81 81 49 89 c0 48 8b 3e ff 14 25
> e0 f3 81
> [11852214.734212] RIP  [<ffffffff8143018d>] vmalloc_fault+0x14b/0x249
> [11852214.734222]  RSP <ffff88083e57d7f8>
> [11852214.734231] ---[ end trace 81ac798210f95867 ]---
> [11852214.734237] Fixing recursive fault but reboot is needed!
> 
> > Also pls next time also CC me.
> 
> Will do, I originally CC'd Jeremy since made some lazy MMU related
> cleanups in arch/x86/mm/fault.c, and I thought he might have a comment
> on this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 01:08:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 01: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 1U93aS-00046r-BT; Sat, 23 Feb 2013 01:07:36 +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 1U93aQ-00046h-NA
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 01:07:34 +0000
Received: from [85.158.139.211:12288] by server-9.bemta-5.messagelabs.com id
	76/DC-24440-55618215; Sat, 23 Feb 2013 01:07:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361581651!18431433!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTQ1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6829 invoked from network); 23 Feb 2013 01:07:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 01:07:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1N17Pxc008866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 01:07:26 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
	r1N17P1J001624
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 01:07:25 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1N17PHK010485; Fri, 22 Feb 2013 19:07:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 17:07:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F070D1C3935; Fri, 22 Feb 2013 20:07:23 -0500 (EST)
Date: Fri, 22 Feb 2013 20:07:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Yinghai Lu <yinghai@kernel.org>
Message-ID: <20130223010723.GA9542@phenom.dumpdata.com>
References: <20130222214811.GA25445@phenom.dumpdata.com>
	<CAE9FiQUjj_bqF0aLVHDg01rc+A-1xKMuFc0yHN6Tqnxc5A-h3g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE9FiQUjj_bqF0aLVHDg01rc+A-1xKMuFc0yHN6Tqnxc5A-h3g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: rafael.j.wysocki@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Regression introduced by
 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device
 objects from probing ACPI drivers) in v3.9-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > [    1.830762] IP: [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> > [    1.830780] PGD 0
> > [    1.830791] Oops: 0000 [#1] SMP
> > [    1.830806] Modules linked in:
> > [    1.830819] CPU 0
> > [    1.830827] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc2upstream-00002-g92ef2a2 #1
> > [    1.830838] RIP: e030:[<ffffffff813862fa>]  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> > [    1.830853] RSP: e02b:ffff88005bb69e98  EFLAGS: 00010246
> > [    1.830862] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000017
> > [    1.830871] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81328b30
> > [    1.830880] RBP: ffff88005bb69eb8 R08: 00000000833df7a7 R09: 0720072007200720
> > [    1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
> > [    1.830899] R13: ffffffff81328b30 R14: 0000000000000000 R15: 0000000000000000
> > [    1.830913] FS:  0000000000000000(0000) GS:ffff88005d600000(0000) knlGS:0000000000000000
> > [    1.830926] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [    1.830935] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000040660
> > [    1.830945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    1.830955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [    1.830965] Process swapper/0 (pid: 1, threadinfo ffff88005bb68000, task ffff88005bb627f0)
> > [    1.830975] Stack:
> > [    1.830981]  0000000000000030 0000000000000000 ffffffff81ae8f60 000000006d1ed4e7
> > [    1.831007]  ffff88005bb69ec8 ffffffff81328b8b ffff88005bb69ed8 ffffffff81ae8f72
> > [    1.831033]  ffff88005bb69f08 ffffffff81002124 0000000000000030 0000000000000007
> > [    1.831057] Call Trace:
> > [    1.831057]  [<ffffffff81ae8f60>] ? pcie_portdrv_init+0x7a/0x7a
> > [    1.831057]  [<ffffffff81328b8b>] aer_acpi_firmware_first+0x1b/0x30
> > [    1.831057]  [<ffffffff81ae8f72>] aer_service_init+0x12/0x2b
> > [    1.831057]  [<ffffffff81002124>] do_one_initcall+0x124/0x170
> > [    1.831057]  [<ffffffff81645404>] kernel_init+0x174/0x2f0
> > [    1.831057]  [<ffffffff81abd5ca>] ? parse_early_options+0x2b/0x2b
> > [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> > [    1.831057]  [<ffffffff81663ffc>] ret_from_fork+0x7c/0xb0
> > [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> > [    1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d
> > [    1.831057] RIP  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> > [    1.831057]  RSP <ffff88005bb69e98>
> > [    1.831057] CR2: 0000000000000024
> > [    2.028436] ---[ end trace dad4411f23c0dcf5 ]---
> > [    2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
> > [    2.028476] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> > [    2.028476]
> > Parsing config from test.xm
> > Daemon running with PID 5069
> >
> 
> 
> https://patchwork.kernel.org/patch/2175871/

And Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 01:08:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 01: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 1U93aS-00046r-BT; Sat, 23 Feb 2013 01:07:36 +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 1U93aQ-00046h-NA
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 01:07:34 +0000
Received: from [85.158.139.211:12288] by server-9.bemta-5.messagelabs.com id
	76/DC-24440-55618215; Sat, 23 Feb 2013 01:07:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361581651!18431433!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTQ1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6829 invoked from network); 23 Feb 2013 01:07:33 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 01:07:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1N17Pxc008866
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 01:07:26 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
	r1N17P1J001624
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 01:07:25 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1N17PHK010485; Fri, 22 Feb 2013 19:07:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 17:07:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F070D1C3935; Fri, 22 Feb 2013 20:07:23 -0500 (EST)
Date: Fri, 22 Feb 2013 20:07:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Yinghai Lu <yinghai@kernel.org>
Message-ID: <20130223010723.GA9542@phenom.dumpdata.com>
References: <20130222214811.GA25445@phenom.dumpdata.com>
	<CAE9FiQUjj_bqF0aLVHDg01rc+A-1xKMuFc0yHN6Tqnxc5A-h3g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE9FiQUjj_bqF0aLVHDg01rc+A-1xKMuFc0yHN6Tqnxc5A-h3g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: rafael.j.wysocki@intel.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Regression introduced by
 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device
 objects from probing ACPI drivers) in v3.9-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > [    1.830762] IP: [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> > [    1.830780] PGD 0
> > [    1.830791] Oops: 0000 [#1] SMP
> > [    1.830806] Modules linked in:
> > [    1.830819] CPU 0
> > [    1.830827] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc2upstream-00002-g92ef2a2 #1
> > [    1.830838] RIP: e030:[<ffffffff813862fa>]  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> > [    1.830853] RSP: e02b:ffff88005bb69e98  EFLAGS: 00010246
> > [    1.830862] RAX: 00000000ffffffea RBX: 0000000000000030 RCX: 0000000000000017
> > [    1.830871] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81328b30
> > [    1.830880] RBP: ffff88005bb69eb8 R08: 00000000833df7a7 R09: 0720072007200720
> > [    1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
> > [    1.830899] R13: ffffffff81328b30 R14: 0000000000000000 R15: 0000000000000000
> > [    1.830913] FS:  0000000000000000(0000) GS:ffff88005d600000(0000) knlGS:0000000000000000
> > [    1.830926] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [    1.830935] CR2: 0000000000000024 CR3: 0000000001a0c000 CR4: 0000000000040660
> > [    1.830945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    1.830955] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [    1.830965] Process swapper/0 (pid: 1, threadinfo ffff88005bb68000, task ffff88005bb627f0)
> > [    1.830975] Stack:
> > [    1.830981]  0000000000000030 0000000000000000 ffffffff81ae8f60 000000006d1ed4e7
> > [    1.831007]  ffff88005bb69ec8 ffffffff81328b8b ffff88005bb69ed8 ffffffff81ae8f72
> > [    1.831033]  ffff88005bb69f08 ffffffff81002124 0000000000000030 0000000000000007
> > [    1.831057] Call Trace:
> > [    1.831057]  [<ffffffff81ae8f60>] ? pcie_portdrv_init+0x7a/0x7a
> > [    1.831057]  [<ffffffff81328b8b>] aer_acpi_firmware_first+0x1b/0x30
> > [    1.831057]  [<ffffffff81ae8f72>] aer_service_init+0x12/0x2b
> > [    1.831057]  [<ffffffff81002124>] do_one_initcall+0x124/0x170
> > [    1.831057]  [<ffffffff81645404>] kernel_init+0x174/0x2f0
> > [    1.831057]  [<ffffffff81abd5ca>] ? parse_early_options+0x2b/0x2b
> > [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> > [    1.831057]  [<ffffffff81663ffc>] ret_from_fork+0x7c/0xb0
> > [    1.831057]  [<ffffffff81645290>] ? rest_init+0xa0/0xa0
> > [    1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d
> > [    1.831057] RIP  [<ffffffff813862fa>] apei_hest_parse+0x2a/0x140
> > [    1.831057]  RSP <ffff88005bb69e98>
> > [    1.831057] CR2: 0000000000000024
> > [    2.028436] ---[ end trace dad4411f23c0dcf5 ]---
> > [    2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
> > [    2.028476] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> > [    2.028476]
> > Parsing config from test.xm
> > Daemon running with PID 5069
> >
> 
> 
> https://patchwork.kernel.org/patch/2175871/

And Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 01:18:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 01: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 1U93kr-0004bL-IK; Sat, 23 Feb 2013 01:18:21 +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 1U93kp-0004bG-1b
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 01:18:19 +0000
Received: from [193.109.254.147:6267] by server-14.bemta-14.messagelabs.com id
	FE/37-02031-AD818215; Sat, 23 Feb 2013 01:18:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361582295!8705603!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTQ1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28062 invoked from network); 23 Feb 2013 01:18:17 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 01:18:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1N1I3SY016418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 01:18: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
	r1N1I21Z022719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 01:18:02 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
	r1N1I1vR023521; Fri, 22 Feb 2013 19:18:01 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 17:18:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 643D01C3935; Fri, 22 Feb 2013 20:18:00 -0500 (EST)
Date: Fri, 22 Feb 2013 20:18:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	xen-devel@lists.xensource.com
Message-ID: <20130223011800.GA2465@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Regression introduced with
 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot
 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

Hey Thomas,

I don't know if this is b/c the Xen code is missing something or
expects something that never happend. I hadn't looked at your
patch in any detail (was going to do that on Monday).

Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
this is I what get:


Loading initramf.gz....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ready.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0upstream-06472-g6661875-dirty (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 20:00:54 EST 2013
[    0.000000] Command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb   sleep BOOT_IMAGE=vmlinuz 
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003f7fffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.2.
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x3f800 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at [ffff8800000fbba0]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x3a000000-0x3a1c8fff]
[    0.000000] init_memory_mapping: [mem 0x38000000-0x39ffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0x37ffffff]
[    0.000000] init_memory_mapping: [mem 0x3a1c9000-0x3f7fffff]
[    0.000000] RAMDISK: [mem 0x3a1c9000-0x3f7defff]
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc010140 00054 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00fe00 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc004180 0BBF6 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: FACS 00000000fc004140 00040
[    0.000000] ACPI: APIC 00000000fc00ff00 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc010050 00038 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc010090 00028 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc0100c0 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: SSDT 00000000fc010100 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003f7fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3f7fffff]
[    0.000000]   NODE_DATA [mem 0x3f7fc000-0x3f7fffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0x3f7fffff]
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] e820: [mem 0x3f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880039e00000 s84928 r8192 d21568 u131072
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256420
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb  acpi_sleep=tss sleep BOOT_IMAGE=vmlinuz 
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 922436k/1040384k available (6617k kernel code, 396k absent, 117552k reserved, 4286k data, 1028k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15.
[    0.000000] NR_IRQS:33024 nr_irqs:1208 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.014003] pid_max: default: 32768 minimum: 301
[    0.017037] Security Framework initialized
[    0.019004] SELinux:  Initializing.
[    0.022076] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.026231] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.032090] Mount-cache hash table entries: 256
[    0.035127] Initializing cgroup subsys cpuacct
[    0.037003] Initializing cgroup subsys freezer
[    0.041103] CPU: Physical Processor ID: 0
[    0.043003] CPU: Processor Core ID: 0
[    0.046004] mce: CPU supports 2 MCE banks
[    0.049023] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.049023] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.049023] tlb_flushall_shift: 5
[    0.059141] Freeing SMP alternatives: 24k freed
[    0.066206] ACPI: Core revision 20130117
[    0.073794] ACPI: All ACPI Tables successfully acquired
[    0.077280] Switched APIC routing to physical flat.
[    0.083403] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.097551] smpboot: CPU0: AMD FX(tm)-8150 Eight-Core Processor (fam: 15, model: 01, stepping: 02)
[    0.103014] installing Xen timer for CPU 0
[    0.106078] cpu 0 spinlock event irq 70
[    0.107023] Performance Events: 
[    0.108005] ------------[ cut here ]------------
[    0.109008] WARNING: at /home/konrad/linux/arch/x86/kernel/cpu/perf_event_amd.c:772 amd_pmu_init+0x191/0x24b()
[    0.110010] Hardware name: HVM domU
[    0.111005] Odd, counter constraints enabled but no core perfctrs detected!
[    0.112005] Modules linked in:
[    0.113186] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-06472-g6661875-dirty #1
[    0.114004] Call Trace:
[    0.115010]  [<ffffffff8109228a>] warn_slowpath_common+0x7a/0xb0
[    0.116007]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.117007]  [<ffffffff81092361>] warn_slowpath_fmt+0x41/0x50
[    0.118005]  [<ffffffff81ac6bc3>] amd_pmu_init+0x191/0x24b
[    0.119005]  [<ffffffff81ac6639>] init_hw_perf_events+0x3f/0x438
[    0.120006]  [<ffffffff81ac1bb4>] ? set_real_mode_permissions+0x9d/0xab
[    0.121015]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.122007]  [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
[    0.123008]  [<ffffffff81abc960>] kernel_init_freeable+0xb1/0x1e6
[    0.124008]  [<ffffffff81653140>] ? rest_init+0xa0/0xa0
[    0.125013]  [<ffffffff81653149>] kernel_init+0x9/0xf0
[    0.126008]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[    0.127013]  [<ffffffff81653140>] ? rest_init+0xa0/0xa0
[    0.128010] ---[ end trace 42ab141fb39a85a5 ]---
[    0.129011] Broken PMU hardware detected, using software events only.
[    0.130007] Failed to access perfctr msr (MSR c0010004 is 0)
[    0.131193] MCE: In-kernel MCE decoding enabled.
[    0.132131] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.133081] cpu 1 spinlock event irq 71
[    0.134049] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
[    0.205154] Brought up 2 CPUs
[    0.205156] smpboot: Total of 2 processors activated (16021.74 BogoMIPS)

[   28.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
[   28.134000] Modules linked in:
[   28.134000] CPU 0 
[   28.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[   28.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[   28.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[   28.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[   28.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[   28.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[   28.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[   28.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[   28.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[   28.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[   28.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   28.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   28.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[   28.134000] Stack:
[   28.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[   28.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[   28.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[   28.134000] Call Trace:
[   28.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[   28.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[   28.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[   28.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[   28.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[   28.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[   28.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[   28.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   28.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[   28.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   28.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[   56.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
[   56.134000] Modules linked in:
[   56.134000] CPU 0 
[   56.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[   56.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[   56.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[   56.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[   56.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[   56.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[   56.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[   56.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[   56.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[   56.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   56.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[   56.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   56.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   56.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[   56.134000] Stack:
[   56.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[   56.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[   56.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[   56.134000] Call Trace:
[   56.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[   56.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[   56.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[   56.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[   56.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[   56.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[   56.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[   56.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   56.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[   56.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   56.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[   84.134000] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:8]
[   84.134000] Modules linked in:
[   84.134000] CPU 0 
[   84.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[   84.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[   84.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[   84.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[   84.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[   84.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[   84.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[   84.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[   84.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[   84.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   84.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[   84.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   84.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   84.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[   84.134000] Stack:
[   84.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[   84.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[   84.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[   84.134000] Call Trace:
[   84.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[   84.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[   84.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[   84.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[   84.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[   84.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[   84.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[   84.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   84.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[   84.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   84.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[  112.134000] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:8]
[  112.134000] Modules linked in:
[  112.134000] CPU 0 
[  112.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[  112.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[  112.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[  112.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[  112.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[  112.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[  112.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[  112.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[  112.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[  112.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  112.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[  112.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  112.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  112.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[  112.134000] Stack:
[  112.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[  112.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[  112.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[  112.134000] Call Trace:
[  112.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[  112.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[  112.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[  112.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[  112.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[  112.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[  112.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[  112.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  112.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[  112.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  112.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[  140.134000] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:8]
[  140.134000] Modules linked in:
[  140.134000] CPU 0 
[  140.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[  140.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[  140.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[  140.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[  140.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[  140.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[  140.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[  140.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[  140.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[  140.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  140.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[  140.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  140.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  140.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[  140.134000] Stack:
[  140.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[  140.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[  140.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[  140.134000] Call Trace:
[  140.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[  140.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[  140.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[  140.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[  140.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[  140.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[  140.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[  140.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  140.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[  140.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  140.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 


if I revert the above mention git commit it boots just fine:

Loading vmlinuz........................................................................
Loading initramf.gz....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ready.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0upstream-06474-g23618fa (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 20:11:27 EST 2013
[    0.000000] Command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb  acpi_sleep=tss sleep BOOT_IMAGE=vmlinuz 
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003f7fffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.2.
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x3f800 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at [ffff8800000fbba0]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x3a000000-0x3a1c9fff]
[    0.000000] init_memory_mapping: [mem 0x38000000-0x39ffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0x37ffffff]
[    0.000000] init_memory_mapping: [mem 0x3a1ca000-0x3f7fffff]
[    0.000000] RAMDISK: [mem 0x3a1ca000-0x3f7defff]
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc010140 00054 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00fe00 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc004180 0BBF6 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: FACS 00000000fc004140 00040
[    0.000000] ACPI: APIC 00000000fc00ff00 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc010050 00038 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc010090 00028 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc0100c0 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: SSDT 00000000fc010100 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003f7fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3f7fffff]
[    0.000000]   NODE_DATA [mem 0x3f7fc000-0x3f7fffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0x3f7fffff]
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] e820: [mem 0x3f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880039e00000 s84928 r8192 d21568 u131072
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256420
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb  acpi_sleep=tss sleep BOOT_IMAGE=vmlinuz 
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 922440k/1040384k available (6617k kernel code, 396k absent, 117548k reserved, 4285k data, 1028k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15.
[    0.000000] NR_IRQS:33024 nr_irqs:1208 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.014004] pid_max: default: 32768 minimum: 301
[    0.017038] Security Framework initialized
[    0.019003] SELinux:  Initializing.
[    0.022097] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.028113] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.033110] Mount-cache hash table entries: 256
[    0.036144] Initializing cgroup subsys cpuacct
[    0.039004] Initializing cgroup subsys freezer
[    0.042101] CPU: Physical Processor ID: 0
[    0.045004] CPU: Processor Core ID: 0
[    0.047005] mce: CPU supports 2 MCE banks
[    0.049025] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.049025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.049025] tlb_flushall_shift: 5
[    0.060140] Freeing SMP alternatives: 24k freed
[    0.067402] ACPI: Core revision 20130117
[    0.075448] ACPI: All ACPI Tables successfully acquired
[    0.079303] Switched APIC routing to physical flat.
[    0.086337] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.100652] smpboot: CPU0: AMD FX(tm)-8150 Eight-Core Processor (fam: 15, model: 01, stepping: 02)
[    0.107016] installing Xen timer for CPU 0
[    0.109084] cpu 0 spinlock event irq 70
[    0.110026] Performance Events: 
[    0.111005] ------------[ cut here ]------------
[    0.112008] WARNING: at /home/konrad/linux/arch/x86/kernel/cpu/perf_event_amd.c:772 amd_pmu_init+0x191/0x24b()
[    0.113010] Hardware name: HVM domU
[    0.114005] Odd, counter constraints enabled but no core perfctrs detected!
[    0.115007] Modules linked in:
[    0.116190] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-06474-g23618fa #1
[    0.117005] Call Trace:
[    0.118011]  [<ffffffff8109228a>] warn_slowpath_common+0x7a/0xb0
[    0.119007]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.120014]  [<ffffffff81092361>] warn_slowpath_fmt+0x41/0x50
[    0.121010]  [<ffffffff81ac6bc3>] amd_pmu_init+0x191/0x24b
[    0.122008]  [<ffffffff81ac6639>] init_hw_perf_events+0x3f/0x438
[    0.123008]  [<ffffffff81ac1bb4>] ? set_real_mode_permissions+0x9d/0xab
[    0.124011]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.125010]  [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
[    0.126011]  [<ffffffff81abc960>] kernel_init_freeable+0xb1/0x1e6
[    0.127009]  [<ffffffff81653040>] ? rest_init+0xa0/0xa0
[    0.128008]  [<ffffffff81653049>] kernel_init+0x9/0xf0
[    0.129008]  [<ffffffff81671fbc>] ret_from_fork+0x7c/0xb0
[    0.130008]  [<ffffffff81653040>] ? rest_init+0xa0/0xa0
[    0.131009] ---[ end trace 7957b7a5e5b198bd ]---
[    0.132012] Broken PMU hardware detected, using software events only.
[    0.133009] Failed to access perfctr msr (MSR c0010004 is 0)
[    0.134179] MCE: In-kernel MCE decoding enabled.
[    0.135132] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.136107] cpu 1 spinlock event irq 71
[    0.137063] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
[    0.209200] Brought up 2 CPUs
[    0.209202] smpboot: Total of 2 processors activated (16015.74 BogoMIPS)

[    0.220139] kworker/u:0 (20) used greatest stack depth: 6168 bytes left
[    0.220139] RTC time:  1:16:41, date: 02/23/13
[    0.229069] NET: Registered protocol family 16
[    0.230054] kworker/u:0 (22) used greatest stack depth: 5704 bytes left
[    0.237060] ACPI: bus type pci registered
[    0.240049] dca service started, version 1.12.1
[    0.244256] PCI: Using configuration type 1 for base access
[    0.247015] PCI: Using configuration type 1 for extended access
[    0.264073] bio: create slab <bio-0> at 0
[    0.265073] ACPI: Added _OSI(Module Device)
[    0.268052] ACPI: Added _OSI(Processor Device)
[    0.270007] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.273006] ACPI: Added _OSI(Processor Aggregator Device)
[    0.282063] ACPI: Interpreter enabled
[    0.284007] ACPI: (supports S0ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568)
[    0.291009] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568)
[    0.298018]  S3 S4 S5)
[    0.299770] ACPI: Using IOAPIC for interrupt routing
[    0.303054] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.358147] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.363225] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[    0.368006] acpi PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
[    0.374173] PCI host bridge to bus 0000:00
[    0.377030] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.380007] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.384012] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.389013] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.394008] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    0.405302] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
[    0.405302] * this clock source is slow. Consider trying other clock sources
[    0.415684] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    0.425458] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.430254] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    0.434187] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.438297] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.443247] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    0.468107] ACPI: Enabled 2 GPEs in block 00 to 0F
[    0.495342] ACPI: No dock devices found.
[    0.498051] xen/balloon: Initialising balloon driver.
[    0.503021] xen-balloon: Initialising balloon driver.
[    0.507315] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.513020] vgaarb: loaded
[    0.515008] vgaarb: bridge control possible 0000:00:02.0
[    0.519043] ACPI: bus type usb registered
[    0.521025] usbcore: registered new interface driver usbfs
[    0.525050] usbcore: registered new interface driver hub
[    0.529032] usbcore: registered new device driver usb
[    0.532030] pps_core: LinuxPPS API ver. 1 registered
[    0.535010] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.541034] PTP clock support registered
[    0.544021] PCI: Using ACPI for IRQ routing
[    0.547504] NetLabel: Initializing
[    0.550020] NetLabel:  domain hash size = 128
[    0.553005] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.556023] NetLabel:  unlabeled traffic allowed by default
[    0.560086] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.563850] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.570000] Switching to clocksource xen
[    0.575292] pnp: PnP ACPI init
[    0.577723] ACPI: bus type pnp registered
[    0.580940] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.586188] system 00:02: [io  0x08a0-0x08a3] has been reserved
[    0.590258] system 00:02: [io  0x0cc0-0x0ccf] has been reserved
[    0.594253] system 00:02: [io  0x04d0-0x04d1] has been reserved
[    0.599358] system 00:0b: [io  0x10c0-0x1141] has been reserved
[    0.603955] system 00:0b: [io  0xb044-0xb047] has been reserved
[    0.628468] pnp: PnP ACPI: found 12 devices
[    0.631442] ACPI: ACPI bus type pnp unregistered
[    0.645562] NET: Registered protocol family 2
[    0.649044] TCP established hash table entries: 8192 (order: 5, 131072 bytes)
[    0.654286] TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
[    0.658984] TCP: Hash tables configured (established 8192 bind 8192)
[    0.663716] TCP: reno registered
[    0.666075] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.670360] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.675037] NET: Registered protocol family 1
[    0.678309] RPC: Registered named UNIX socket transport module.
[    0.682174] RPC: Registered udp transport module.
[    0.687129] RPC: Registered tcp transport module.
[    0.691254] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.696034] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.699773] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.703675] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.708489] Unpacking initramfs...
[    2.141533] Freeing initrd memory: 88148k freed
[    2.164129] Machine check injector initialized
[    2.168316] microcode: CPU0: patch_level=0x06000626
[    2.172993] microcode: CPU1: patch_level=0x06000626
[    2.176728] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    2.182905] Scanning for low memory corruption every 60 seconds
[    2.187817] audit: initializing netlink socket (disabled)
[    2.191843] type=2000 audit(1361582202.962:1): initialized
[    2.207210] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    2.211912] VFS: Disk quotas dquot_6.5.2
[    2.214690] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.219888] NFS: Registering the id_resolver key type
[    2.223132] Key type id_resolver registered
[    2.225832] Key type id_legacy registered
[    2.228426] NTFS driver 2.1.30 [Flags: R/W].
[    2.231310] msgmni has been set to 1973
[    2.234951] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    2.240338] io scheduler noop registered
[    2.243302] io scheduler deadline registered
[    2.246944] io scheduler cfq registered (default)
[    2.250838] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    2.254918] cirrusfb 0000:00:02.0: Cirrus Logic chipset on PCI bus, RAM (4096 kB) at 0xf0000000
[    2.260761] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    2.265458] ACPI: Power Button [PWRF]
[    2.267894] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    2.272527] ACPI: Sleep Button [SLPF]
[    2.299201] GHES: HEST is not enabled!
[    2.301887] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    2.306244] Grant tables using version 1 layout.
[    2.309719] Grant table initialized
[    2.350043] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.384350] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.389781] Non-volatile memory driver v1.3
[    2.392982] Linux agpgart interface v0.103
[    2.396500] [drm] Initialized drm 1.1.0 20060810
[    2.401266] loop: module loaded
[    2.404010] libphy: Fixed MDIO Bus: probed
[    2.406982] tun: Universal TUN/TAP device driver, 1.6
[    2.410646] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    2.415328] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k
[    2.421802] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    2.426813] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.431520] ehci-pci: EHCI PCI platform driver
[    2.434881] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.438958] uhci_hcd: USB Universal Host Controller Interface driver
[    2.443235] uhci_hcd 0000:00:01.2: UHCI Host Controller
[    2.446671] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
[    2.451329] uhci_hcd 0000:00:01.2: detected 2 ports
[    2.454517] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c200
[    2.459396] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    2.464574] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.469834] usb usb1: Product: UHCI Host Controller
[    2.473420] usb usb1: Manufacturer: Linux 3.8.0upstream-06474-g23618fa uhci_hcd
[    2.478471] usb usb1: SerialNumber: 0000:00:01.2
[    2.482206] hub 1-0:1.0: USB hub found
[    2.484834] hub 1-0:1.0: 2 ports detected
[    2.488090] usbcore: registered new interface driver usblp
[    2.492447] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    2.500167] serio: i8042 KBD port at 0x60,0x64 irq 1
[    2.503714] serio: i8042 AUX port at 0x60,0x64 irq 12
[    2.507763] mousedev: PS/2 mouse device common for all mice
[    2.512933] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    2.524976] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    2.529542] rtc_cmos 00:04: alarms up to one day, 114 bytes nvram, hpet irqs
[    2.534889] cpuidle: using governor ladder
[    2.537830] cpuidle: using governor menu
[    2.540584] EFI Variables Facility v0.08 2004-May-17
[    2.544414] zram: Created 1 device(s) ...
[    2.547839] Netfilter messages via NETLINK v0.30.
[    2.551376] nf_conntrack version 0.5.0 (7895 buckets, 31580 max)
[    2.555360] ctnetlink v0.93: registering with nfnetlink.
[    2.558943] ip_tables: (C) 2000-2006 Netfilter Core Team
[    2.562389] TCP: cubic registered
[    2.564542] Initializing XFRM netlink socket
[    2.567367] NET: Registered protocol family 10
[    2.570381] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    2.575240] sit: IPv6 over IPv4 tunneling driver
[    2.578803] NET: Registered protocol family 17
[    2.582316] Key type dns_resolver registered
[    2.585987] registered taskstats version 1
[    2.589437] XENBUS: Device with no driver: device/vbd/5632
[    2.593412] XENBUS: Device with no driver: device/vbd/51712
[    2.597376] XENBUS: Device with no driver: device/vkbd/0
[    2.601142] XENBUS: Device with no driver: device/vif/0
[    2.606914]   Magic number: 1:525:256
[    2.610031] tty ttytf: hash matches
[    2.614105] Freeing unused kernel memory: 1028k freed
[    2.617578] Write protecting the kernel read-only data: 10240k
[    2.624349] Freeing unused kernel memory: 1564k freed
[    2.628174] Freeing unused kernel memory: 124k freed
init started: BusyBox v1.14.3 (2013-02-22 20:12:24 EST)
[    2.637307] consoletype (1105) used greatest stack depth: 5272 bytes left
Mounting directories  [  OK  ]
mount: mount point /proc/bus/usb does not exist
[    2.803957] modprobe (1135) used greatest stack depth: 5256 bytes left
mount: mount point /sys/kernel/config does not exist
[    2.815744] core_filesystem (1106) used greatest stack depth: 4968 bytes left
[    2.824824] input: Xen Virtual Keyboard as /devices/virtual/input/input3
[    2.830810] input: Xen Virtual Pointer as /devices/virtual/input/input4
FATAL: Error inserting xen_fbfront (/lib/modules/3.8.0upstream-06474-g23618fa/kernel/drivers/video/xen-fbfront.ko): No such device
[    2.952663] Initialising Xen virtual ethernet driver.
[    3.058902] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    3.063787] vbd vbd-5632: failed to write error node for device/vbd/5632 (19 xenbus_dev_probe on device/vbd/5632)
[    3.078892] blkfront: xvda: barrier or flush: disabled using persistent grants
[    3.086048]  xvda: unknown partition table
[    3.130560] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5
[    3.179037] udevd (1177): /proc/1177/oom_adj is deprecated, please use /proc/1177/oom_score_adj instead.
udevd-work[1460]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory
Waiting for devices [  OK  ]

[    3.242701] SCSI subsystem initialized
[    3.280922] ACPI: bus type scsi registered
[    3.291177] ip (2088) used greatest stack depth: 3928 bytes left
[    3.298854] libata version 3.00 loaded.
[    3.303746] ata_piix 0000:00:01.1: version 2.13
[    3.307420] ata_piix 0000:00:01.1: setting latency timer to 64
[    3.315495] scsi0 : ata_piix
[    3.318138] scsi1 : ata_piix
[    3.320673] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc220 irq 14
[    3.325880] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc228 irq 15
[    3.484370] ata2.01: NODEV after polling detection
[    3.489426] ata2.00: ATAPI: QEMU DVD-ROM, 0.10.2, max UDMA/100
[    3.495340] ata2.00: configured for MWDMA2
[    3.500231] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     0.10 PQ: 0 ANSI: 5
[    3.511465] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
[    3.516801] cdrom: Uniform CD-ROM driver Revision: 3.20
[    3.522597] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    3.528965] sr 1:0:0:0: Attached scsi generic sg0 type 5
[    3.704201] usb usb1: suspend_rh (auto-stop)
Waiting for fb [  OK  ]
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  poRTNETLINK answers: Network is unreachable
[  OK  ]
wWaiting for init.custom [  OK  ]

Starting SSHd ...
eroff

    SSH started [2385]


Waiting for SSHd [  OK  ]
WARNING: ssh currently running [2385] ignoring start request
FATAL: Module dump_dma not found.
ERROR: Module dump_dma does not exist in /proc/modules
[    9.388889] Loading iSCSI transport class v2.0-870.
[    9.394686] iscsi: registered transport (tcp)
hostname: Name or service not known
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get list of targets from firmware.
Feb 23 01:16:50 (none) syslogd 1.5.0: restart.
Running in HVM context on Xen v4.2.
You might have to do kill -1 1 if you see 'can't open /dev/hvc0'
[1:0:0:0]    cd/dvd  QEMU     QEMU DVD-ROM     0.10  /dev/sr0 
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
            CPU0       CPU1       
   0:        109          0   IO-APIC-edge      timer
   1:          9          0  xen-pirq-ioapic-edge  i8042
   4:        201          0  xen-pirq-ioapic-edge  serial
   8:         59          0  xen-pirq-ioapic-edge  rtc0
   9:          0          0   IO-APIC-fasteoi   acpi
  12:        125          0  xen-pirq-ioapic-edge  i8042
  14:          0          0   IO-APIC-edge      ata_piix
  15:         96          0   IO-APIC-edge      ata_piix
  23:          0          0  xen-pirq-ioapic-level  uhci_hcd:usb1
  64:       3128          0  xen-percpu-virq      timer0
  65:       2815          0  xen-percpu-ipi       resched0
  66:          0          0  xen-percpu-ipi       callfunc0
  67:          0          0  xen-percpu-virq      debug0
  68:        214          0  xen-percpu-ipi       callfuncsingle0
  69:          0          0  xen-percpu-ipi       irqwork0
  70:          0          0  xen-percpu-ipi       spinlock0
  71:          0          0  xen-percpu-ipi       spinlock1
  72:          0       3338  xen-percpu-ipi       resched1
  73:          0          0  xen-percpu-ipi       callfunc1
  74:          0          0  xen-percpu-virq      debug1
  75:          0        243  xen-percpu-ipi       callfuncsingle1
  76:          0          0  xen-percpu-ipi       irqwork1
  77:          0       1802  xen-percpu-virq      timer1
  78:        344          0   xen-dyn-event     xenbus
  80:          0          0   xen-dyn-event     vkbd
  81:         14          0   xen-dyn-event     eth0
  82:          2          0   xen-dyn-event     blkif
 NMI:          0          0   Non-maskable interrupts
 LOC:          0          0   Local timer interrupts
 SPU:          0          0   Spurious interrupts
 PMI:          0          0   Performance monitoring interrupts
 IWI:          0          0   IRQ work interrupts
 RTR:          0          0   APIC ICR read retries
 RES:       2815       3338   Rescheduling interrupts
 CAL:        131        150   Function call interrupts
 TLB:         83         93   TLB shootdowns
 TRM:          0          0   Thermal event interrupts
 THR:          0          0   Threshold APIC interrupts
 MCE:          0          0   Machine check exceptions
 MCP:          1          1   Machine check polls
 ERR:          0
 MIS:          0
00000000-00000fff : reserved
00001000-0009dfff : System RAM
0009e000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c8bff : Video ROM
000c9000-000c99ff : Adapter ROM
000e0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-3f7fffff : System RAM
  01000000-01676677 : Kernel code
  01676678-01aa5dbf : Kernel data
  01baf000-01cb4fff : Kernel bss
3f800000-3fffffff : RAM buffer
f0000000-fbffffff : PCI Bus 0000:00
  f0000000-f1ffffff : 0000:00:02.0
    f0000000-f1ffffff : cirrusfb
  f2000000-f2ffffff : 0000:00:03.0
    f2000000-f2ffffff : xen-platform-pci
  f3000000-f3000fff : 0000:00:02.0
    f3000000-f3000fff : cirrusfb
fc000000-ffffffff : reserved
  fec00000-fec003ff : IOAPIC 0
  fed00000-fed003ff : HPET 0
  fee00000-fee00fff : Local APIC
MemTotal:        1013328 kB
MemFree:          624868 kB
Buffers:               0 kB
Cached:           350448 kB
SwapCached:            0 kB
Active:            15968 kB
Inactive:         334816 kB
Active(anon):      10204 kB
Inactive(anon):   163096 kB
Active(file):       5764 kB
Inactive(file):   171720 kB
Unevictable:        4896 kB
Mlocked:            4896 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          5180 kB
Mapped:             4948 kB
Shmem:            169428 kB
Slab:              22776 kB
SReclaimable:      11768 kB
SUnreclaim:        11008 kB
KernelStack:         648 kB
PageTables:          868 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      506664 kB
Committed_AS:     181212 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        6324 kB
VmallocChunk:   34359731835 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       32768 kB
DirectMap2M:     1009664 kB
Waiting for init.late [  OK  ]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 01:18:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 01: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 1U93kr-0004bL-IK; Sat, 23 Feb 2013 01:18:21 +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 1U93kp-0004bG-1b
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 01:18:19 +0000
Received: from [193.109.254.147:6267] by server-14.bemta-14.messagelabs.com id
	FE/37-02031-AD818215; Sat, 23 Feb 2013 01:18:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361582295!8705603!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTQ1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28062 invoked from network); 23 Feb 2013 01:18:17 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 01:18:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1N1I3SY016418
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 01:18: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
	r1N1I21Z022719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 01:18:02 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
	r1N1I1vR023521; Fri, 22 Feb 2013 19:18:01 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 22 Feb 2013 17:18:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 643D01C3935; Fri, 22 Feb 2013 20:18:00 -0500 (EST)
Date: Fri, 22 Feb 2013 20:18:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	xen-devel@lists.xensource.com
Message-ID: <20130223011800.GA2465@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Regression introduced with
 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot
 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

Hey Thomas,

I don't know if this is b/c the Xen code is missing something or
expects something that never happend. I hadn't looked at your
patch in any detail (was going to do that on Monday).

Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
this is I what get:


Loading initramf.gz....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ready.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0upstream-06472-g6661875-dirty (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 20:00:54 EST 2013
[    0.000000] Command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb   sleep BOOT_IMAGE=vmlinuz 
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003f7fffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.2.
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x3f800 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at [ffff8800000fbba0]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x3a000000-0x3a1c8fff]
[    0.000000] init_memory_mapping: [mem 0x38000000-0x39ffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0x37ffffff]
[    0.000000] init_memory_mapping: [mem 0x3a1c9000-0x3f7fffff]
[    0.000000] RAMDISK: [mem 0x3a1c9000-0x3f7defff]
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc010140 00054 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00fe00 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc004180 0BBF6 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: FACS 00000000fc004140 00040
[    0.000000] ACPI: APIC 00000000fc00ff00 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc010050 00038 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc010090 00028 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc0100c0 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: SSDT 00000000fc010100 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003f7fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3f7fffff]
[    0.000000]   NODE_DATA [mem 0x3f7fc000-0x3f7fffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0x3f7fffff]
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] e820: [mem 0x3f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880039e00000 s84928 r8192 d21568 u131072
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256420
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb  acpi_sleep=tss sleep BOOT_IMAGE=vmlinuz 
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 922436k/1040384k available (6617k kernel code, 396k absent, 117552k reserved, 4286k data, 1028k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15.
[    0.000000] NR_IRQS:33024 nr_irqs:1208 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.014003] pid_max: default: 32768 minimum: 301
[    0.017037] Security Framework initialized
[    0.019004] SELinux:  Initializing.
[    0.022076] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.026231] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.032090] Mount-cache hash table entries: 256
[    0.035127] Initializing cgroup subsys cpuacct
[    0.037003] Initializing cgroup subsys freezer
[    0.041103] CPU: Physical Processor ID: 0
[    0.043003] CPU: Processor Core ID: 0
[    0.046004] mce: CPU supports 2 MCE banks
[    0.049023] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.049023] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.049023] tlb_flushall_shift: 5
[    0.059141] Freeing SMP alternatives: 24k freed
[    0.066206] ACPI: Core revision 20130117
[    0.073794] ACPI: All ACPI Tables successfully acquired
[    0.077280] Switched APIC routing to physical flat.
[    0.083403] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.097551] smpboot: CPU0: AMD FX(tm)-8150 Eight-Core Processor (fam: 15, model: 01, stepping: 02)
[    0.103014] installing Xen timer for CPU 0
[    0.106078] cpu 0 spinlock event irq 70
[    0.107023] Performance Events: 
[    0.108005] ------------[ cut here ]------------
[    0.109008] WARNING: at /home/konrad/linux/arch/x86/kernel/cpu/perf_event_amd.c:772 amd_pmu_init+0x191/0x24b()
[    0.110010] Hardware name: HVM domU
[    0.111005] Odd, counter constraints enabled but no core perfctrs detected!
[    0.112005] Modules linked in:
[    0.113186] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-06472-g6661875-dirty #1
[    0.114004] Call Trace:
[    0.115010]  [<ffffffff8109228a>] warn_slowpath_common+0x7a/0xb0
[    0.116007]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.117007]  [<ffffffff81092361>] warn_slowpath_fmt+0x41/0x50
[    0.118005]  [<ffffffff81ac6bc3>] amd_pmu_init+0x191/0x24b
[    0.119005]  [<ffffffff81ac6639>] init_hw_perf_events+0x3f/0x438
[    0.120006]  [<ffffffff81ac1bb4>] ? set_real_mode_permissions+0x9d/0xab
[    0.121015]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.122007]  [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
[    0.123008]  [<ffffffff81abc960>] kernel_init_freeable+0xb1/0x1e6
[    0.124008]  [<ffffffff81653140>] ? rest_init+0xa0/0xa0
[    0.125013]  [<ffffffff81653149>] kernel_init+0x9/0xf0
[    0.126008]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[    0.127013]  [<ffffffff81653140>] ? rest_init+0xa0/0xa0
[    0.128010] ---[ end trace 42ab141fb39a85a5 ]---
[    0.129011] Broken PMU hardware detected, using software events only.
[    0.130007] Failed to access perfctr msr (MSR c0010004 is 0)
[    0.131193] MCE: In-kernel MCE decoding enabled.
[    0.132131] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.133081] cpu 1 spinlock event irq 71
[    0.134049] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
[    0.205154] Brought up 2 CPUs
[    0.205156] smpboot: Total of 2 processors activated (16021.74 BogoMIPS)

[   28.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
[   28.134000] Modules linked in:
[   28.134000] CPU 0 
[   28.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[   28.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[   28.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[   28.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[   28.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[   28.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[   28.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[   28.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[   28.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[   28.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[   28.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   28.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   28.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[   28.134000] Stack:
[   28.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[   28.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[   28.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[   28.134000] Call Trace:
[   28.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[   28.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[   28.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[   28.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[   28.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[   28.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[   28.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[   28.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   28.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[   28.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   28.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[   56.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
[   56.134000] Modules linked in:
[   56.134000] CPU 0 
[   56.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[   56.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[   56.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[   56.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[   56.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[   56.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[   56.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[   56.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[   56.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[   56.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   56.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[   56.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   56.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   56.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[   56.134000] Stack:
[   56.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[   56.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[   56.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[   56.134000] Call Trace:
[   56.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[   56.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[   56.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[   56.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[   56.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[   56.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[   56.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[   56.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   56.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[   56.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   56.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[   84.134000] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:8]
[   84.134000] Modules linked in:
[   84.134000] CPU 0 
[   84.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[   84.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[   84.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[   84.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[   84.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[   84.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[   84.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[   84.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[   84.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[   84.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   84.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[   84.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   84.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   84.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[   84.134000] Stack:
[   84.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[   84.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[   84.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[   84.134000] Call Trace:
[   84.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[   84.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[   84.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[   84.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[   84.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[   84.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[   84.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[   84.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   84.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[   84.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[   84.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[  112.134000] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:8]
[  112.134000] Modules linked in:
[  112.134000] CPU 0 
[  112.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[  112.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[  112.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[  112.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[  112.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[  112.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[  112.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[  112.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[  112.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[  112.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  112.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[  112.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  112.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  112.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[  112.134000] Stack:
[  112.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[  112.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[  112.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[  112.134000] Call Trace:
[  112.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[  112.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[  112.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[  112.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[  112.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[  112.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[  112.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[  112.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  112.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[  112.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  112.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 
[  140.134000] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:8]
[  140.134000] Modules linked in:
[  140.134000] CPU 0 
[  140.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
[  140.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0
[  140.134000] RSP: 0000:ffff880039a4dd38  EFLAGS: 00000293
[  140.134000] RAX: 0000000000000001 RBX: ffffffff810c14c7 RCX: 0000000000000000
[  140.134000] RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff880039a37de8
[  140.134000] RBP: ffff880039a4dd68 R08: 0000000000000000 R09: 0000000000000001
[  140.134000] R10: 0000000000000000 R11: 0000000000000003 R12: ffff880039a4c000
[  140.134000] R13: 0000000000000000 R14: ffffffff810cac35 R15: ffff880039a4dcb8
[  140.134000] FS:  0000000000000000(0000) GS:ffff880039e00000(0000) knlGS:0000000000000000
[  140.134000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  140.134000] CR2: ffff880001cb7000 CR3: 0000000001a0c000 CR4: 00000000000406f0
[  140.134000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  140.134000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  140.134000] Process migration/0 (pid: 8, threadinfo ffff880039a4c000, task ffff880039a2b000)
[  140.134000] Stack:
[  140.134000]  ffff880039a4dd98 ffff880039a37d58 ffff880039a4c000 ffffffff811070a0
[  140.134000]  ffff880039a37de8 ffff880039e0e5e0 ffff880039a4de48 ffffffff81106df3
[  140.134000]  ffff880039a4dda8 ffff880039a4dfd8 ffff880039e0e5e8 ffff880039a4c000
[  140.134000] Call Trace:
[  140.134000]  [<ffffffff811070a0>] ? stop_one_cpu_nowait+0x30/0x30
[  140.134000]  [<ffffffff81106df3>] cpu_stopper_thread+0xb3/0x160
[  140.134000]  [<ffffffff81668b11>] ? __schedule+0x3d1/0x7e0
[  140.134000]  [<ffffffff81080069>] ? default_spin_lock_flags+0x9/0x10
[  140.134000]  [<ffffffff810c0127>] smpboot_thread_fn+0x157/0x1e0
[  140.134000]  [<ffffffff810bffd0>] ? smpboot_create_threads+0x80/0x80
[  140.134000]  [<ffffffff810b7446>] kthread+0xc6/0xd0
[  140.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  140.134000]  [<ffffffff81671ebc>] ret_from_fork+0x7c/0xb0
[  140.134000]  [<ffffffff810b7380>] ? kthread_freezable_should_stop+0x80/0x80
[  140.134000] Code: 41 83 fd 03 74 42 f0 41 ff 0e 0f 94 c0 84 c0 74 0f 8b 43 20 8b 4b 10 83 c0 01 89 4b 24 89 43 20 41 83 fd 04 74 3a 44 89 e8 f3 90 <44> 8b 6b 20 41 39 c5 74 ec 41 83 fd 02 75 c6 fa 66 66 90 66 66 


if I revert the above mention git commit it boots just fine:

Loading vmlinuz........................................................................
Loading initramf.gz....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ready.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.0upstream-06474-g23618fa (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Fri Feb 22 20:11:27 EST 2013
[    0.000000] Command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb  acpi_sleep=tss sleep BOOT_IMAGE=vmlinuz 
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003f7fffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.2.
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x3f800 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at [ffff8800000fbba0]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x3a000000-0x3a1c9fff]
[    0.000000] init_memory_mapping: [mem 0x38000000-0x39ffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0x37ffffff]
[    0.000000] init_memory_mapping: [mem 0x3a1ca000-0x3f7fffff]
[    0.000000] RAMDISK: [mem 0x3a1ca000-0x3f7defff]
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc010140 00054 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc00fe00 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc004180 0BBF6 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: FACS 00000000fc004140 00040
[    0.000000] ACPI: APIC 00000000fc00ff00 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000fc010050 00038 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: WAET 00000000fc010090 00028 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000fc0100c0 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] ACPI: SSDT 00000000fc010100 00031 (v02    Xen      HVM 00000000 INTL 20100528)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003f7fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3f7fffff]
[    0.000000]   NODE_DATA [mem 0x3f7fc000-0x3f7fffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0x3f7fffff]
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] e820: [mem 0x3f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880039e00000 s84928 r8192 d21568 u131072
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 256420
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb  acpi_sleep=tss sleep BOOT_IMAGE=vmlinuz 
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 922440k/1040384k available (6617k kernel code, 396k absent, 117548k reserved, 4285k data, 1028k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15.
[    0.000000] NR_IRQS:33024 nr_irqs:1208 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] tsc: Detected 3901.188 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7802.37 BogoMIPS (lpj=3901188)
[    0.014004] pid_max: default: 32768 minimum: 301
[    0.017038] Security Framework initialized
[    0.019003] SELinux:  Initializing.
[    0.022097] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.028113] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.033110] Mount-cache hash table entries: 256
[    0.036144] Initializing cgroup subsys cpuacct
[    0.039004] Initializing cgroup subsys freezer
[    0.042101] CPU: Physical Processor ID: 0
[    0.045004] CPU: Processor Core ID: 0
[    0.047005] mce: CPU supports 2 MCE banks
[    0.049025] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.049025] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
[    0.049025] tlb_flushall_shift: 5
[    0.060140] Freeing SMP alternatives: 24k freed
[    0.067402] ACPI: Core revision 20130117
[    0.075448] ACPI: All ACPI Tables successfully acquired
[    0.079303] Switched APIC routing to physical flat.
[    0.086337] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.100652] smpboot: CPU0: AMD FX(tm)-8150 Eight-Core Processor (fam: 15, model: 01, stepping: 02)
[    0.107016] installing Xen timer for CPU 0
[    0.109084] cpu 0 spinlock event irq 70
[    0.110026] Performance Events: 
[    0.111005] ------------[ cut here ]------------
[    0.112008] WARNING: at /home/konrad/linux/arch/x86/kernel/cpu/perf_event_amd.c:772 amd_pmu_init+0x191/0x24b()
[    0.113010] Hardware name: HVM domU
[    0.114005] Odd, counter constraints enabled but no core perfctrs detected!
[    0.115007] Modules linked in:
[    0.116190] Pid: 1, comm: swapper/0 Not tainted 3.8.0upstream-06474-g23618fa #1
[    0.117005] Call Trace:
[    0.118011]  [<ffffffff8109228a>] warn_slowpath_common+0x7a/0xb0
[    0.119007]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.120014]  [<ffffffff81092361>] warn_slowpath_fmt+0x41/0x50
[    0.121010]  [<ffffffff81ac6bc3>] amd_pmu_init+0x191/0x24b
[    0.122008]  [<ffffffff81ac6639>] init_hw_perf_events+0x3f/0x438
[    0.123008]  [<ffffffff81ac1bb4>] ? set_real_mode_permissions+0x9d/0xab
[    0.124011]  [<ffffffff81ac65fa>] ? check_bugs+0x2d/0x2d
[    0.125010]  [<ffffffff8100203d>] do_one_initcall+0x3d/0x170
[    0.126011]  [<ffffffff81abc960>] kernel_init_freeable+0xb1/0x1e6
[    0.127009]  [<ffffffff81653040>] ? rest_init+0xa0/0xa0
[    0.128008]  [<ffffffff81653049>] kernel_init+0x9/0xf0
[    0.129008]  [<ffffffff81671fbc>] ret_from_fork+0x7c/0xb0
[    0.130008]  [<ffffffff81653040>] ? rest_init+0xa0/0xa0
[    0.131009] ---[ end trace 7957b7a5e5b198bd ]---
[    0.132012] Broken PMU hardware detected, using software events only.
[    0.133009] Failed to access perfctr msr (MSR c0010004 is 0)
[    0.134179] MCE: In-kernel MCE decoding enabled.
[    0.135132] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.136107] cpu 1 spinlock event irq 71
[    0.137063] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
[    0.209200] Brought up 2 CPUs
[    0.209202] smpboot: Total of 2 processors activated (16015.74 BogoMIPS)

[    0.220139] kworker/u:0 (20) used greatest stack depth: 6168 bytes left
[    0.220139] RTC time:  1:16:41, date: 02/23/13
[    0.229069] NET: Registered protocol family 16
[    0.230054] kworker/u:0 (22) used greatest stack depth: 5704 bytes left
[    0.237060] ACPI: bus type pci registered
[    0.240049] dca service started, version 1.12.1
[    0.244256] PCI: Using configuration type 1 for base access
[    0.247015] PCI: Using configuration type 1 for extended access
[    0.264073] bio: create slab <bio-0> at 0
[    0.265073] ACPI: Added _OSI(Module Device)
[    0.268052] ACPI: Added _OSI(Processor Device)
[    0.270007] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.273006] ACPI: Added _OSI(Processor Aggregator Device)
[    0.282063] ACPI: Interpreter enabled
[    0.284007] ACPI: (supports S0ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130117/hwxface-568)
[    0.291009] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130117/hwxface-568)
[    0.298018]  S3 S4 S5)
[    0.299770] ACPI: Using IOAPIC for interrupt routing
[    0.303054] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.358147] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.363225] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[    0.368006] acpi PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
[    0.374173] PCI host bridge to bus 0000:00
[    0.377030] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.380007] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.384012] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.389013] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.394008] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    0.405302] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
[    0.405302] * this clock source is slow. Consider trying other clock sources
[    0.415684] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    0.425458] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.430254] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    0.434187] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.438297] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.443247] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    0.468107] ACPI: Enabled 2 GPEs in block 00 to 0F
[    0.495342] ACPI: No dock devices found.
[    0.498051] xen/balloon: Initialising balloon driver.
[    0.503021] xen-balloon: Initialising balloon driver.
[    0.507315] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.513020] vgaarb: loaded
[    0.515008] vgaarb: bridge control possible 0000:00:02.0
[    0.519043] ACPI: bus type usb registered
[    0.521025] usbcore: registered new interface driver usbfs
[    0.525050] usbcore: registered new interface driver hub
[    0.529032] usbcore: registered new device driver usb
[    0.532030] pps_core: LinuxPPS API ver. 1 registered
[    0.535010] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.541034] PTP clock support registered
[    0.544021] PCI: Using ACPI for IRQ routing
[    0.547504] NetLabel: Initializing
[    0.550020] NetLabel:  domain hash size = 128
[    0.553005] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.556023] NetLabel:  unlabeled traffic allowed by default
[    0.560086] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.563850] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.570000] Switching to clocksource xen
[    0.575292] pnp: PnP ACPI init
[    0.577723] ACPI: bus type pnp registered
[    0.580940] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.586188] system 00:02: [io  0x08a0-0x08a3] has been reserved
[    0.590258] system 00:02: [io  0x0cc0-0x0ccf] has been reserved
[    0.594253] system 00:02: [io  0x04d0-0x04d1] has been reserved
[    0.599358] system 00:0b: [io  0x10c0-0x1141] has been reserved
[    0.603955] system 00:0b: [io  0xb044-0xb047] has been reserved
[    0.628468] pnp: PnP ACPI: found 12 devices
[    0.631442] ACPI: ACPI bus type pnp unregistered
[    0.645562] NET: Registered protocol family 2
[    0.649044] TCP established hash table entries: 8192 (order: 5, 131072 bytes)
[    0.654286] TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
[    0.658984] TCP: Hash tables configured (established 8192 bind 8192)
[    0.663716] TCP: reno registered
[    0.666075] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.670360] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.675037] NET: Registered protocol family 1
[    0.678309] RPC: Registered named UNIX socket transport module.
[    0.682174] RPC: Registered udp transport module.
[    0.687129] RPC: Registered tcp transport module.
[    0.691254] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.696034] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.699773] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.703675] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.708489] Unpacking initramfs...
[    2.141533] Freeing initrd memory: 88148k freed
[    2.164129] Machine check injector initialized
[    2.168316] microcode: CPU0: patch_level=0x06000626
[    2.172993] microcode: CPU1: patch_level=0x06000626
[    2.176728] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    2.182905] Scanning for low memory corruption every 60 seconds
[    2.187817] audit: initializing netlink socket (disabled)
[    2.191843] type=2000 audit(1361582202.962:1): initialized
[    2.207210] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    2.211912] VFS: Disk quotas dquot_6.5.2
[    2.214690] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.219888] NFS: Registering the id_resolver key type
[    2.223132] Key type id_resolver registered
[    2.225832] Key type id_legacy registered
[    2.228426] NTFS driver 2.1.30 [Flags: R/W].
[    2.231310] msgmni has been set to 1973
[    2.234951] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    2.240338] io scheduler noop registered
[    2.243302] io scheduler deadline registered
[    2.246944] io scheduler cfq registered (default)
[    2.250838] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    2.254918] cirrusfb 0000:00:02.0: Cirrus Logic chipset on PCI bus, RAM (4096 kB) at 0xf0000000
[    2.260761] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    2.265458] ACPI: Power Button [PWRF]
[    2.267894] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    2.272527] ACPI: Sleep Button [SLPF]
[    2.299201] GHES: HEST is not enabled!
[    2.301887] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    2.306244] Grant tables using version 1 layout.
[    2.309719] Grant table initialized
[    2.350043] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.384350] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.389781] Non-volatile memory driver v1.3
[    2.392982] Linux agpgart interface v0.103
[    2.396500] [drm] Initialized drm 1.1.0 20060810
[    2.401266] loop: module loaded
[    2.404010] libphy: Fixed MDIO Bus: probed
[    2.406982] tun: Universal TUN/TAP device driver, 1.6
[    2.410646] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    2.415328] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.7.12-k
[    2.421802] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    2.426813] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.431520] ehci-pci: EHCI PCI platform driver
[    2.434881] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.438958] uhci_hcd: USB Universal Host Controller Interface driver
[    2.443235] uhci_hcd 0000:00:01.2: UHCI Host Controller
[    2.446671] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
[    2.451329] uhci_hcd 0000:00:01.2: detected 2 ports
[    2.454517] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c200
[    2.459396] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    2.464574] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.469834] usb usb1: Product: UHCI Host Controller
[    2.473420] usb usb1: Manufacturer: Linux 3.8.0upstream-06474-g23618fa uhci_hcd
[    2.478471] usb usb1: SerialNumber: 0000:00:01.2
[    2.482206] hub 1-0:1.0: USB hub found
[    2.484834] hub 1-0:1.0: 2 ports detected
[    2.488090] usbcore: registered new interface driver usblp
[    2.492447] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    2.500167] serio: i8042 KBD port at 0x60,0x64 irq 1
[    2.503714] serio: i8042 AUX port at 0x60,0x64 irq 12
[    2.507763] mousedev: PS/2 mouse device common for all mice
[    2.512933] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    2.524976] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    2.529542] rtc_cmos 00:04: alarms up to one day, 114 bytes nvram, hpet irqs
[    2.534889] cpuidle: using governor ladder
[    2.537830] cpuidle: using governor menu
[    2.540584] EFI Variables Facility v0.08 2004-May-17
[    2.544414] zram: Created 1 device(s) ...
[    2.547839] Netfilter messages via NETLINK v0.30.
[    2.551376] nf_conntrack version 0.5.0 (7895 buckets, 31580 max)
[    2.555360] ctnetlink v0.93: registering with nfnetlink.
[    2.558943] ip_tables: (C) 2000-2006 Netfilter Core Team
[    2.562389] TCP: cubic registered
[    2.564542] Initializing XFRM netlink socket
[    2.567367] NET: Registered protocol family 10
[    2.570381] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    2.575240] sit: IPv6 over IPv4 tunneling driver
[    2.578803] NET: Registered protocol family 17
[    2.582316] Key type dns_resolver registered
[    2.585987] registered taskstats version 1
[    2.589437] XENBUS: Device with no driver: device/vbd/5632
[    2.593412] XENBUS: Device with no driver: device/vbd/51712
[    2.597376] XENBUS: Device with no driver: device/vkbd/0
[    2.601142] XENBUS: Device with no driver: device/vif/0
[    2.606914]   Magic number: 1:525:256
[    2.610031] tty ttytf: hash matches
[    2.614105] Freeing unused kernel memory: 1028k freed
[    2.617578] Write protecting the kernel read-only data: 10240k
[    2.624349] Freeing unused kernel memory: 1564k freed
[    2.628174] Freeing unused kernel memory: 124k freed
init started: BusyBox v1.14.3 (2013-02-22 20:12:24 EST)
[    2.637307] consoletype (1105) used greatest stack depth: 5272 bytes left
Mounting directories  [  OK  ]
mount: mount point /proc/bus/usb does not exist
[    2.803957] modprobe (1135) used greatest stack depth: 5256 bytes left
mount: mount point /sys/kernel/config does not exist
[    2.815744] core_filesystem (1106) used greatest stack depth: 4968 bytes left
[    2.824824] input: Xen Virtual Keyboard as /devices/virtual/input/input3
[    2.830810] input: Xen Virtual Pointer as /devices/virtual/input/input4
FATAL: Error inserting xen_fbfront (/lib/modules/3.8.0upstream-06474-g23618fa/kernel/drivers/video/xen-fbfront.ko): No such device
[    2.952663] Initialising Xen virtual ethernet driver.
[    3.058902] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    3.063787] vbd vbd-5632: failed to write error node for device/vbd/5632 (19 xenbus_dev_probe on device/vbd/5632)
[    3.078892] blkfront: xvda: barrier or flush: disabled using persistent grants
[    3.086048]  xvda: unknown partition table
[    3.130560] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5
[    3.179037] udevd (1177): /proc/1177/oom_adj is deprecated, please use /proc/1177/oom_score_adj instead.
udevd-work[1460]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory
Waiting for devices [  OK  ]

[    3.242701] SCSI subsystem initialized
[    3.280922] ACPI: bus type scsi registered
[    3.291177] ip (2088) used greatest stack depth: 3928 bytes left
[    3.298854] libata version 3.00 loaded.
[    3.303746] ata_piix 0000:00:01.1: version 2.13
[    3.307420] ata_piix 0000:00:01.1: setting latency timer to 64
[    3.315495] scsi0 : ata_piix
[    3.318138] scsi1 : ata_piix
[    3.320673] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc220 irq 14
[    3.325880] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc228 irq 15
[    3.484370] ata2.01: NODEV after polling detection
[    3.489426] ata2.00: ATAPI: QEMU DVD-ROM, 0.10.2, max UDMA/100
[    3.495340] ata2.00: configured for MWDMA2
[    3.500231] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     0.10 PQ: 0 ANSI: 5
[    3.511465] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
[    3.516801] cdrom: Uniform CD-ROM driver Revision: 3.20
[    3.522597] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    3.528965] sr 1:0:0:0: Attached scsi generic sg0 type 5
[    3.704201] usb usb1: suspend_rh (auto-stop)
Waiting for fb [  OK  ]
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  poRTNETLINK answers: Network is unreachable
[  OK  ]
wWaiting for init.custom [  OK  ]

Starting SSHd ...
eroff

    SSH started [2385]


Waiting for SSHd [  OK  ]
WARNING: ssh currently running [2385] ignoring start request
FATAL: Module dump_dma not found.
ERROR: Module dump_dma does not exist in /proc/modules
[    9.388889] Loading iSCSI transport class v2.0-870.
[    9.394686] iscsi: registered transport (tcp)
hostname: Name or service not known
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get list of targets from firmware.
Feb 23 01:16:50 (none) syslogd 1.5.0: restart.
Running in HVM context on Xen v4.2.
You might have to do kill -1 1 if you see 'can't open /dev/hvc0'
[1:0:0:0]    cd/dvd  QEMU     QEMU DVD-ROM     0.10  /dev/sr0 
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01)
            CPU0       CPU1       
   0:        109          0   IO-APIC-edge      timer
   1:          9          0  xen-pirq-ioapic-edge  i8042
   4:        201          0  xen-pirq-ioapic-edge  serial
   8:         59          0  xen-pirq-ioapic-edge  rtc0
   9:          0          0   IO-APIC-fasteoi   acpi
  12:        125          0  xen-pirq-ioapic-edge  i8042
  14:          0          0   IO-APIC-edge      ata_piix
  15:         96          0   IO-APIC-edge      ata_piix
  23:          0          0  xen-pirq-ioapic-level  uhci_hcd:usb1
  64:       3128          0  xen-percpu-virq      timer0
  65:       2815          0  xen-percpu-ipi       resched0
  66:          0          0  xen-percpu-ipi       callfunc0
  67:          0          0  xen-percpu-virq      debug0
  68:        214          0  xen-percpu-ipi       callfuncsingle0
  69:          0          0  xen-percpu-ipi       irqwork0
  70:          0          0  xen-percpu-ipi       spinlock0
  71:          0          0  xen-percpu-ipi       spinlock1
  72:          0       3338  xen-percpu-ipi       resched1
  73:          0          0  xen-percpu-ipi       callfunc1
  74:          0          0  xen-percpu-virq      debug1
  75:          0        243  xen-percpu-ipi       callfuncsingle1
  76:          0          0  xen-percpu-ipi       irqwork1
  77:          0       1802  xen-percpu-virq      timer1
  78:        344          0   xen-dyn-event     xenbus
  80:          0          0   xen-dyn-event     vkbd
  81:         14          0   xen-dyn-event     eth0
  82:          2          0   xen-dyn-event     blkif
 NMI:          0          0   Non-maskable interrupts
 LOC:          0          0   Local timer interrupts
 SPU:          0          0   Spurious interrupts
 PMI:          0          0   Performance monitoring interrupts
 IWI:          0          0   IRQ work interrupts
 RTR:          0          0   APIC ICR read retries
 RES:       2815       3338   Rescheduling interrupts
 CAL:        131        150   Function call interrupts
 TLB:         83         93   TLB shootdowns
 TRM:          0          0   Thermal event interrupts
 THR:          0          0   Threshold APIC interrupts
 MCE:          0          0   Machine check exceptions
 MCP:          1          1   Machine check polls
 ERR:          0
 MIS:          0
00000000-00000fff : reserved
00001000-0009dfff : System RAM
0009e000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c8bff : Video ROM
000c9000-000c99ff : Adapter ROM
000e0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-3f7fffff : System RAM
  01000000-01676677 : Kernel code
  01676678-01aa5dbf : Kernel data
  01baf000-01cb4fff : Kernel bss
3f800000-3fffffff : RAM buffer
f0000000-fbffffff : PCI Bus 0000:00
  f0000000-f1ffffff : 0000:00:02.0
    f0000000-f1ffffff : cirrusfb
  f2000000-f2ffffff : 0000:00:03.0
    f2000000-f2ffffff : xen-platform-pci
  f3000000-f3000fff : 0000:00:02.0
    f3000000-f3000fff : cirrusfb
fc000000-ffffffff : reserved
  fec00000-fec003ff : IOAPIC 0
  fed00000-fed003ff : HPET 0
  fee00000-fee00fff : Local APIC
MemTotal:        1013328 kB
MemFree:          624868 kB
Buffers:               0 kB
Cached:           350448 kB
SwapCached:            0 kB
Active:            15968 kB
Inactive:         334816 kB
Active(anon):      10204 kB
Inactive(anon):   163096 kB
Active(file):       5764 kB
Inactive(file):   171720 kB
Unevictable:        4896 kB
Mlocked:            4896 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          5180 kB
Mapped:             4948 kB
Shmem:            169428 kB
Slab:              22776 kB
SReclaimable:      11768 kB
SUnreclaim:        11008 kB
KernelStack:         648 kB
PageTables:          868 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      506664 kB
Committed_AS:     181212 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        6324 kB
VmallocChunk:   34359731835 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       32768 kB
DirectMap2M:     1009664 kB
Waiting for init.late [  OK  ]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 02:33:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 02: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 1U94vA-0007Cr-18; Sat, 23 Feb 2013 02:33: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 1U94v8-0007Ck-Om
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 02:33:02 +0000
Received: from [85.158.138.51:45709] by server-16.bemta-3.messagelabs.com id
	8B/25-02727-D5A28215; Sat, 23 Feb 2013 02:33:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361586781!27065280!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTQ1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7736 invoked from network); 23 Feb 2013 02:33:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 02:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,720,1355097600"; 
   d="scan'208";a="1805284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 02:33: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.297.1; Sat, 23 Feb 2013 02:33:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U94v6-0005Xd-D7;
	Sat, 23 Feb 2013 02:33:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U94v6-0006Nb-06;
	Sat, 23 Feb 2013 02:33:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16227-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 02:33:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16227: 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 16227 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16227/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-win    5 xen-boot                    fail pass in 16224

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check      fail in 16224 never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 02:33:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 02: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 1U94vA-0007Cr-18; Sat, 23 Feb 2013 02:33: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 1U94v8-0007Ck-Om
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 02:33:02 +0000
Received: from [85.158.138.51:45709] by server-16.bemta-3.messagelabs.com id
	8B/25-02727-D5A28215; Sat, 23 Feb 2013 02:33:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361586781!27065280!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTQ1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7736 invoked from network); 23 Feb 2013 02:33:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 02:33:01 -0000
X-IronPort-AV: E=Sophos;i="4.84,720,1355097600"; 
   d="scan'208";a="1805284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 02:33: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.297.1; Sat, 23 Feb 2013 02:33:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U94v6-0005Xd-D7;
	Sat, 23 Feb 2013 02:33:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U94v6-0006Nb-06;
	Sat, 23 Feb 2013 02:33:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16227-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 02:33:00 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16227: 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 16227 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16227/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-win    5 xen-boot                    fail pass in 16224

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check      fail in 16224 never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 05:44:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 05: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 1U97u5-0004NI-3J; Sat, 23 Feb 2013 05:44:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xi.wang@gmail.com>) id 1U97u3-0004NA-BC
	for xen-devel@lists.xen.org; Sat, 23 Feb 2013 05:44:07 +0000
Received: from [85.158.137.99:52328] by server-12.bemta-3.messagelabs.com id
	F0/52-05889-62758215; Sat, 23 Feb 2013 05:44:06 +0000
X-Env-Sender: xi.wang@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361598244!16830044!1
X-Originating-IP: [209.85.128.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20910 invoked from network); 23 Feb 2013 05:44:05 -0000
Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com)
	(209.85.128.179)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 05:44:05 -0000
Received: by mail-ve0-f179.google.com with SMTP id da11so1146835veb.24
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 21:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=YKC+zUfA8C13NoSBI4+/RvpXH8suWijhZqORCnu2IbM=;
	b=FUXIWTv6Cu1s6Nz6oOkBj5lW5P4XrNR0wvLOO3oXfv+iFBREiFZ5m8BlFLDyBdYVtS
	rQRgZOeqdF2AjI/dGvMgJAcxdjeE5VYZBRfTUkOIlqDK6aAEH6ssHrycNoJxP1ED3CzH
	fv3KJMXFzN/WN/sKRinptJluHQvfpwjB9rEwtE3QgeOg+nCparPRKRmZDio+wtL/cIo9
	NsMYmKAQ8uP+yULLUKTnERlypMbGqd+z+P5aVjGLlCvtIReqC6dzcS10BLjmEuPxayLH
	PA7t0LifPUHI4p/YfWpMwRcit0MBvx8RgimXewBru/JVo2zmNh5VXGcgl9jMZabd8T6N
	QEvA==
X-Received: by 10.58.245.40 with SMTP id xl8mr6245073vec.33.1361598244576;
	Fri, 22 Feb 2013 21:44:04 -0800 (PST)
Received: from hchen.csail.mit.edu (hchen.csail.mit.edu. [18.26.5.5])
	by mx.google.com with ESMTPS id yu4sm7758149veb.7.2013.02.22.21.44.03
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 22 Feb 2013 21:44:03 -0800 (PST)
From: Xi Wang <xi@mit.edu>
To: xen-devel@lists.xen.org
Date: Sat, 23 Feb 2013 00:43:48 -0500
Message-Id: <1361598228-25041-1-git-send-email-xi@mit.edu>
X-Mailer: git-send-email 1.7.10.4
Cc: Xi Wang <xi@mit.edu>
Subject: [Xen-devel] [PATCH] x86: fix null pointer dereference in
	intel_get_extended_msrs()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

`memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
null pointer dereference.  Replace `&mc_ext' with `mc_ext'.

Signed-off-by: Xi Wang <xi@mit.edu>
---
 xen/arch/x86/cpu/mcheck/mce_intel.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index d80f692..57e93d4 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -200,7 +200,7 @@ intel_get_extended_msrs(struct mcinfo_global *mig, struct mc_info *mi)
     }
 
     /* this function will called when CAP(9).MCG_EXT_P = 1 */
-    memset(&mc_ext, 0, sizeof(struct mcinfo_extended));
+    memset(mc_ext, 0, sizeof(struct mcinfo_extended));
     mc_ext->common.type = MC_TYPE_EXTENDED;
     mc_ext->common.size = sizeof(struct mcinfo_extended);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 05:44:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 05: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 1U97u5-0004NI-3J; Sat, 23 Feb 2013 05:44:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xi.wang@gmail.com>) id 1U97u3-0004NA-BC
	for xen-devel@lists.xen.org; Sat, 23 Feb 2013 05:44:07 +0000
Received: from [85.158.137.99:52328] by server-12.bemta-3.messagelabs.com id
	F0/52-05889-62758215; Sat, 23 Feb 2013 05:44:06 +0000
X-Env-Sender: xi.wang@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361598244!16830044!1
X-Originating-IP: [209.85.128.179]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20910 invoked from network); 23 Feb 2013 05:44:05 -0000
Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com)
	(209.85.128.179)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 05:44:05 -0000
Received: by mail-ve0-f179.google.com with SMTP id da11so1146835veb.24
	for <xen-devel@lists.xen.org>; Fri, 22 Feb 2013 21:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=YKC+zUfA8C13NoSBI4+/RvpXH8suWijhZqORCnu2IbM=;
	b=FUXIWTv6Cu1s6Nz6oOkBj5lW5P4XrNR0wvLOO3oXfv+iFBREiFZ5m8BlFLDyBdYVtS
	rQRgZOeqdF2AjI/dGvMgJAcxdjeE5VYZBRfTUkOIlqDK6aAEH6ssHrycNoJxP1ED3CzH
	fv3KJMXFzN/WN/sKRinptJluHQvfpwjB9rEwtE3QgeOg+nCparPRKRmZDio+wtL/cIo9
	NsMYmKAQ8uP+yULLUKTnERlypMbGqd+z+P5aVjGLlCvtIReqC6dzcS10BLjmEuPxayLH
	PA7t0LifPUHI4p/YfWpMwRcit0MBvx8RgimXewBru/JVo2zmNh5VXGcgl9jMZabd8T6N
	QEvA==
X-Received: by 10.58.245.40 with SMTP id xl8mr6245073vec.33.1361598244576;
	Fri, 22 Feb 2013 21:44:04 -0800 (PST)
Received: from hchen.csail.mit.edu (hchen.csail.mit.edu. [18.26.5.5])
	by mx.google.com with ESMTPS id yu4sm7758149veb.7.2013.02.22.21.44.03
	(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 22 Feb 2013 21:44:03 -0800 (PST)
From: Xi Wang <xi@mit.edu>
To: xen-devel@lists.xen.org
Date: Sat, 23 Feb 2013 00:43:48 -0500
Message-Id: <1361598228-25041-1-git-send-email-xi@mit.edu>
X-Mailer: git-send-email 1.7.10.4
Cc: Xi Wang <xi@mit.edu>
Subject: [Xen-devel] [PATCH] x86: fix null pointer dereference in
	intel_get_extended_msrs()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

`memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
null pointer dereference.  Replace `&mc_ext' with `mc_ext'.

Signed-off-by: Xi Wang <xi@mit.edu>
---
 xen/arch/x86/cpu/mcheck/mce_intel.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index d80f692..57e93d4 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -200,7 +200,7 @@ intel_get_extended_msrs(struct mcinfo_global *mig, struct mc_info *mi)
     }
 
     /* this function will called when CAP(9).MCG_EXT_P = 1 */
-    memset(&mc_ext, 0, sizeof(struct mcinfo_extended));
+    memset(mc_ext, 0, sizeof(struct mcinfo_extended));
     mc_ext->common.type = MC_TYPE_EXTENDED;
     mc_ext->common.size = sizeof(struct mcinfo_extended);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 06:50:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 06:50: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 1U98vj-0006Bx-0C; Sat, 23 Feb 2013 06:49: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 1U98vh-0006Bs-3O
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 06:49:53 +0000
Received: from [85.158.137.99:45235] by server-4.bemta-3.messagelabs.com id
	25/65-17521-F8668215; Sat, 23 Feb 2013 06:49:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361602191!17668606!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTQ1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19216 invoked from network); 23 Feb 2013 06:49:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 06:49:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1808401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 06:49: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.297.1; Sat, 23 Feb 2013 06:49:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U98ve-0006r7-IE;
	Sat, 23 Feb 2013 06:49:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U98ve-0000Et-3r;
	Sat, 23 Feb 2013 06:49:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16229-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 06:49:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing baseline test] 16229: 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 16229 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16229/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-sedf     11 guest-localmigrate      fail baseline untested

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2   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-i386-xl-qemut-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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemut-rhel6hvm-amd  7 redhat-install           fail never pass
 test-i386-i386-win           16 leak-check/check             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-qemut-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemut-win   7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-qemut-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemut-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-i386-xl-qemut-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass

version targeted for testing:
 xen                  2692df2a2c6ca3c09ef6c3d064f36e3630ff9bdc
baseline version:
 xen                  2692df2a2c6ca3c09ef6c3d064f36e3630ff9bdc

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 Feb 23 06:50:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 06:50: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 1U98vj-0006Bx-0C; Sat, 23 Feb 2013 06:49: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 1U98vh-0006Bs-3O
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 06:49:53 +0000
Received: from [85.158.137.99:45235] by server-4.bemta-3.messagelabs.com id
	25/65-17521-F8668215; Sat, 23 Feb 2013 06:49:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361602191!17668606!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTQ1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19216 invoked from network); 23 Feb 2013 06:49:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 06:49:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1808401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 06:49: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.297.1; Sat, 23 Feb 2013 06:49:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U98ve-0006r7-IE;
	Sat, 23 Feb 2013 06:49:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U98ve-0000Et-3r;
	Sat, 23 Feb 2013 06:49:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16229-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 06:49:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing baseline test] 16229: 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 16229 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16229/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot          fail baseline untested
 test-amd64-amd64-xl-sedf     11 guest-localmigrate      fail baseline untested

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2   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-i386-xl-qemut-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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64  8 guest-saverestore      fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-i386-qemut-rhel6hvm-amd  7 redhat-install           fail never pass
 test-i386-i386-win           16 leak-check/check             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-qemut-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  7 windows-install    fail never pass
 test-i386-i386-xl-qemut-win   7 windows-install              fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-qemut-winxpsp3  7 windows-install            fail never pass
 test-amd64-amd64-xl-qemut-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-i386-xl-qemut-win-vcpus1  7 windows-install         fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass

version targeted for testing:
 xen                  2692df2a2c6ca3c09ef6c3d064f36e3630ff9bdc
baseline version:
 xen                  2692df2a2c6ca3c09ef6c3d064f36e3630ff9bdc

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 Feb 23 11:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 11: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 1U9DIv-0006tu-9W; Sat, 23 Feb 2013 11:30: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 1U9DIs-0006tm-Ul
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 11:30:07 +0000
Received: from [85.158.139.83:2667] by server-4.bemta-5.messagelabs.com id
	D4/93-29496-E38A8215; Sat, 23 Feb 2013 11:30:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361619004!24690000!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTQ1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25426 invoked from network); 23 Feb 2013 11:30:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 11:30:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1810027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 11:30: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.297.1; Sat, 23 Feb 2013 11:30:02 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9DIo-0008Gk-Em;
	Sat, 23 Feb 2013 11:30:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9DIn-0003Oa-Th;
	Sat, 23 Feb 2013 11:30:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16230-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 11:30:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing baseline test] 16230: 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 16230 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16230/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv             5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-localmigrate/x10 fail baseline untested

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-win           16 leak-check/check             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-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 Feb 23 11:30:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 11: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 1U9DIv-0006tu-9W; Sat, 23 Feb 2013 11:30: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 1U9DIs-0006tm-Ul
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 11:30:07 +0000
Received: from [85.158.139.83:2667] by server-4.bemta-5.messagelabs.com id
	D4/93-29496-E38A8215; Sat, 23 Feb 2013 11:30:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361619004!24690000!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTQ1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25426 invoked from network); 23 Feb 2013 11:30:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 11:30:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1810027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 11:30: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.297.1; Sat, 23 Feb 2013 11:30:02 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9DIo-0008Gk-Em;
	Sat, 23 Feb 2013 11:30:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9DIn-0003Oa-Th;
	Sat, 23 Feb 2013 11:30:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16230-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 11:30:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing baseline test] 16230: 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 16230 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16230/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv             5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-sedf      5 xen-boot                fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-localmigrate/x10 fail baseline untested

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-win           16 leak-check/check             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-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-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-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 Feb 23 12:13:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 12: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 1U9Dyd-0000Pf-7c; Sat, 23 Feb 2013 12:13: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 1U9Dyb-0000Pa-H2
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 12:13:13 +0000
Received: from [85.158.139.83:60486] by server-8.bemta-5.messagelabs.com id
	BA/C5-19075-852B8215; Sat, 23 Feb 2013 12:13:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361621592!28059613!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31682 invoked from network); 23 Feb 2013 12:13:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 12:13:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1810367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 12:13: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.297.1; Sat, 23 Feb 2013 12:13:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9DyZ-0008Ti-MQ;
	Sat, 23 Feb 2013 12:13:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9DyZ-0006oz-Ct;
	Sat, 23 Feb 2013 12:13:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16231-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 12:13:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16231: 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 16231 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-xl-qemut-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-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 12:13:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 12: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 1U9Dyd-0000Pf-7c; Sat, 23 Feb 2013 12:13: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 1U9Dyb-0000Pa-H2
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 12:13:13 +0000
Received: from [85.158.139.83:60486] by server-8.bemta-5.messagelabs.com id
	BA/C5-19075-852B8215; Sat, 23 Feb 2013 12:13:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361621592!28059613!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31682 invoked from network); 23 Feb 2013 12:13:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 12:13:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1810367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 12:13: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.297.1; Sat, 23 Feb 2013 12:13:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9DyZ-0008Ti-MQ;
	Sat, 23 Feb 2013 12:13:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9DyZ-0006oz-Ct;
	Sat, 23 Feb 2013 12:13:11 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16231-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 12:13:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16231: 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 16231 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-xl-qemut-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-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 13:19:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 13:19: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 1U9F07-0001Se-OO; Sat, 23 Feb 2013 13:18:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@www.outflux.net>) id 1U99Zq-0007bz-Pv
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 07:31:22 +0000
Received: from [85.158.143.99:54974] by server-3.bemta-4.messagelabs.com id
	5C/52-02186-A4078215; Sat, 23 Feb 2013 07:31:22 +0000
X-Env-Sender: keescook@www.outflux.net
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361604679!18415809!1
X-Originating-IP: [198.145.64.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24629 invoked from network); 23 Feb 2013 07:31:21 -0000
Received: from smtp.outflux.net (HELO smtp.outflux.net) (198.145.64.163)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2013 07:31:21 -0000
Received: from www.outflux.net (serenity-end.outflux.net [10.2.0.2])
	by vinyl.outflux.net (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id
	r1N7TxZP007021; Fri, 22 Feb 2013 23:30:00 -0800
Date: Fri, 22 Feb 2013 23:29:59 -0800
From: Kees Cook <keescook@chromium.org>
To: linux-kernel@vger.kernel.org
Message-ID: <20130223072959.GA4894@www.outflux.net>
MIME-Version: 1.0
Content-Disposition: inline
X-MIMEDefang-Filter: outflux$Revision: 1.316 $
X-HELO: www.outflux.net
X-Scanned-By: MIMEDefang 2.71 on 10.2.0.1
X-Mailman-Approved-At: Sat, 23 Feb 2013 13:18:50 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 93ff4e1..8cada4c 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -53,7 +53,7 @@ config XEN_DEBUG_FS
 
 config XEN_X86_PVH
 	bool "Support for running as a PVH guest (EXPERIMENTAL)"
-	depends on X86_64 && XEN && EXPERIMENTAL
+	depends on X86_64 && XEN
 	default n
 	help
 	   This option enables support for running as a PVH guest (PV guest
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 13:19:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 13:19: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 1U9F07-0001Se-OO; Sat, 23 Feb 2013 13:18:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@www.outflux.net>) id 1U99Zq-0007bz-Pv
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 07:31:22 +0000
Received: from [85.158.143.99:54974] by server-3.bemta-4.messagelabs.com id
	5C/52-02186-A4078215; Sat, 23 Feb 2013 07:31:22 +0000
X-Env-Sender: keescook@www.outflux.net
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361604679!18415809!1
X-Originating-IP: [198.145.64.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24629 invoked from network); 23 Feb 2013 07:31:21 -0000
Received: from smtp.outflux.net (HELO smtp.outflux.net) (198.145.64.163)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Feb 2013 07:31:21 -0000
Received: from www.outflux.net (serenity-end.outflux.net [10.2.0.2])
	by vinyl.outflux.net (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id
	r1N7TxZP007021; Fri, 22 Feb 2013 23:30:00 -0800
Date: Fri, 22 Feb 2013 23:29:59 -0800
From: Kees Cook <keescook@chromium.org>
To: linux-kernel@vger.kernel.org
Message-ID: <20130223072959.GA4894@www.outflux.net>
MIME-Version: 1.0
Content-Disposition: inline
X-MIMEDefang-Filter: outflux$Revision: 1.316 $
X-HELO: www.outflux.net
X-Scanned-By: MIMEDefang 2.71 on 10.2.0.1
X-Mailman-Approved-At: Sat, 23 Feb 2013 13:18:50 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 93ff4e1..8cada4c 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -53,7 +53,7 @@ config XEN_DEBUG_FS
 
 config XEN_X86_PVH
 	bool "Support for running as a PVH guest (EXPERIMENTAL)"
-	depends on X86_64 && XEN && EXPERIMENTAL
+	depends on X86_64 && XEN
 	default n
 	help
 	   This option enables support for running as a PVH guest (PV guest
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 13:19:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 13:19: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 1U9F08-0001Sl-4T; Sat, 23 Feb 2013 13:18:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongsheng.song@gmail.com>) id 1U9Dla-0008Q0-Kb
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 11:59:46 +0000
Received: from [85.158.139.83:50934] by server-9.bemta-5.messagelabs.com id
	4E/68-24440-13FA8215; Sat, 23 Feb 2013 11:59:45 +0000
X-Env-Sender: dongsheng.song@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361620783!25862741!1
X-Originating-IP: [209.85.214.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2413 invoked from network); 23 Feb 2013 11:59:45 -0000
Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com)
	(209.85.214.174)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 11:59:45 -0000
Received: by mail-ob0-f174.google.com with SMTP id 16so1348848obc.19
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 03:59:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=TQ8tRUWtq+1dSd50TE2dnkgvW0tJlq3P5PXhOfKA0t4=;
	b=x759QiwtamIB2lzQnJ2qojkUsfZ6XUVKYKMlNx34IcrMNiLnviKxKw+UMBktSF9ERJ
	r9Z1jiLB5/q2A1/sU/BFswa80si0h6yoDK9LO+8mstIP3elY4dSxayAzcOz8nWZGzCik
	4m+LuU7cFhQPCSKrWnHlVlcYtISws7tXwmhjdiWajX1f+2v0TV3A4jYB2w9oSjYkMghw
	liOaryqO+TSeHtH1f9H2c5crlofpUF54J3UYWpNp9Ry7DNPtkUmCLGmE3FusFyLGgu/m
	lCA3HfMqNIwhMmjT7FlbLYdZ91/3+wzPU9FC2S9f9sUltEYNUwL5KQHdmPgOBBUqvVAs
	hRdA==
X-Received: by 10.60.3.41 with SMTP id 9mr2101992oez.53.1361620783489; Sat, 23
	Feb 2013 03:59:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.157.115 with HTTP; Sat, 23 Feb 2013 03:59:23 -0800 (PST)
In-Reply-To: <20130223072959.GA4894@www.outflux.net>
References: <20130223072959.GA4894@www.outflux.net>
From: Dongsheng Song <dongsheng.song@gmail.com>
Date: Sat, 23 Feb 2013 19:59:23 +0800
Message-ID: <CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
To: Kees Cook <keescook@chromium.org>
X-Mailman-Approved-At: Sat, 23 Feb 2013 13:18:50 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
>
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 93ff4e1..8cada4c 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
>
>  config XEN_X86_PVH
>         bool "Support for running as a PVH guest (EXPERIMENTAL)"

Why not remove this 'EXPERIMENTAL' too ?

> -       depends on X86_64 && XEN && EXPERIMENTAL
> +       depends on X86_64 && XEN
>         default n
>         help
>            This option enables support for running as a PVH guest (PV guest
> --
> 1.7.9.5
>
>
> --
> Kees Cook
> Chrome OS Security
> --
> 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 Sat Feb 23 13:19:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 13:19: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 1U9F08-0001Sl-4T; Sat, 23 Feb 2013 13:18:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongsheng.song@gmail.com>) id 1U9Dla-0008Q0-Kb
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 11:59:46 +0000
Received: from [85.158.139.83:50934] by server-9.bemta-5.messagelabs.com id
	4E/68-24440-13FA8215; Sat, 23 Feb 2013 11:59:45 +0000
X-Env-Sender: dongsheng.song@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361620783!25862741!1
X-Originating-IP: [209.85.214.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2413 invoked from network); 23 Feb 2013 11:59:45 -0000
Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com)
	(209.85.214.174)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 11:59:45 -0000
Received: by mail-ob0-f174.google.com with SMTP id 16so1348848obc.19
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 03:59:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=TQ8tRUWtq+1dSd50TE2dnkgvW0tJlq3P5PXhOfKA0t4=;
	b=x759QiwtamIB2lzQnJ2qojkUsfZ6XUVKYKMlNx34IcrMNiLnviKxKw+UMBktSF9ERJ
	r9Z1jiLB5/q2A1/sU/BFswa80si0h6yoDK9LO+8mstIP3elY4dSxayAzcOz8nWZGzCik
	4m+LuU7cFhQPCSKrWnHlVlcYtISws7tXwmhjdiWajX1f+2v0TV3A4jYB2w9oSjYkMghw
	liOaryqO+TSeHtH1f9H2c5crlofpUF54J3UYWpNp9Ry7DNPtkUmCLGmE3FusFyLGgu/m
	lCA3HfMqNIwhMmjT7FlbLYdZ91/3+wzPU9FC2S9f9sUltEYNUwL5KQHdmPgOBBUqvVAs
	hRdA==
X-Received: by 10.60.3.41 with SMTP id 9mr2101992oez.53.1361620783489; Sat, 23
	Feb 2013 03:59:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.157.115 with HTTP; Sat, 23 Feb 2013 03:59:23 -0800 (PST)
In-Reply-To: <20130223072959.GA4894@www.outflux.net>
References: <20130223072959.GA4894@www.outflux.net>
From: Dongsheng Song <dongsheng.song@gmail.com>
Date: Sat, 23 Feb 2013 19:59:23 +0800
Message-ID: <CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
To: Kees Cook <keescook@chromium.org>
X-Mailman-Approved-At: Sat, 23 Feb 2013 13:18:50 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, x86@kernel.org,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
>
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 93ff4e1..8cada4c 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
>
>  config XEN_X86_PVH
>         bool "Support for running as a PVH guest (EXPERIMENTAL)"

Why not remove this 'EXPERIMENTAL' too ?

> -       depends on X86_64 && XEN && EXPERIMENTAL
> +       depends on X86_64 && XEN
>         default n
>         help
>            This option enables support for running as a PVH guest (PV guest
> --
> 1.7.9.5
>
>
> --
> Kees Cook
> Chrome OS Security
> --
> 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 Sat Feb 23 16:10:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 16:10: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 1U9HfJ-0004lP-Lo; Sat, 23 Feb 2013 16:09: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 1U9HfI-0004lK-Bq
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 16:09:32 +0000
Received: from [85.158.143.99:39350] by server-2.bemta-4.messagelabs.com id
	58/36-12656-BB9E8215; Sat, 23 Feb 2013 16:09:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361635770!23615921!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1471 invoked from network); 23 Feb 2013 16:09:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 16:09:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1812099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 16:09: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.297.1; Sat, 23 Feb 2013 16:09:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9HfF-0001Et-Vl; Sat, 23 Feb 2013 16:09:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9HfF-0006fT-RI;
	Sat, 23 Feb 2013 16:09:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20776.59833.627696.520908@mariner.uk.xensource.com>
Date: Sat, 23 Feb 2013 16:09:29 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <ian.campbell@citrix.com>
In-Reply-To: <osstest-16231-mainreport@xen.org>
References: <osstest-16231-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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

xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):
> flight 16231 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386                    4 xen-build             fail REGR. vs. 16226

gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c
./checker > tmp.size
diff -u reference.size tmp.size
--- reference.size	2013-02-22 22:53:31.000000000 +0000
+++ tmp.size	2013-02-22 23:12:05.000000000 +0000
@@ -5,7 +5,7 @@
 trap_info                 |       -       -       8      16
 cpu_user_regs             |       -       -      68     200
 vcpu_guest_core_regs      |     304     304       -       -
-vcpu_guest_context        |     336     336    2800    5168
+vcpu_guest_context        |     332     332    2800    5168
 arch_vcpu_info            |       -       -      24      16
 vcpu_time_info            |       -       -      32      32
 vcpu_info                 |       -       -      64      64
make[4]: *** [check-headers] Error 1
make[4]: Leaving directory `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'
make[3]: Leaving directory `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'
make[3]: *** [xen-foreign] Error 2

Are we supposed to still be doing this for i386 ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 16:10:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 16:10: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 1U9HfJ-0004lP-Lo; Sat, 23 Feb 2013 16:09: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 1U9HfI-0004lK-Bq
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 16:09:32 +0000
Received: from [85.158.143.99:39350] by server-2.bemta-4.messagelabs.com id
	58/36-12656-BB9E8215; Sat, 23 Feb 2013 16:09:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361635770!23615921!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1471 invoked from network); 23 Feb 2013 16:09:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 16:09:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,721,1355097600"; 
   d="scan'208";a="1812099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 16:09: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.297.1; Sat, 23 Feb 2013 16:09:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9HfF-0001Et-Vl; Sat, 23 Feb 2013 16:09:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9HfF-0006fT-RI;
	Sat, 23 Feb 2013 16:09:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20776.59833.627696.520908@mariner.uk.xensource.com>
Date: Sat, 23 Feb 2013 16:09:29 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <ian.campbell@citrix.com>
In-Reply-To: <osstest-16231-mainreport@xen.org>
References: <osstest-16231-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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

xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):
> flight 16231 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386                    4 xen-build             fail REGR. vs. 16226

gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c
./checker > tmp.size
diff -u reference.size tmp.size
--- reference.size	2013-02-22 22:53:31.000000000 +0000
+++ tmp.size	2013-02-22 23:12:05.000000000 +0000
@@ -5,7 +5,7 @@
 trap_info                 |       -       -       8      16
 cpu_user_regs             |       -       -      68     200
 vcpu_guest_core_regs      |     304     304       -       -
-vcpu_guest_context        |     336     336    2800    5168
+vcpu_guest_context        |     332     332    2800    5168
 arch_vcpu_info            |       -       -      24      16
 vcpu_time_info            |       -       -      32      32
 vcpu_info                 |       -       -      64      64
make[4]: *** [check-headers] Error 1
make[4]: Leaving directory `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'
make[3]: Leaving directory `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'
make[3]: *** [xen-foreign] Error 2

Are we supposed to still be doing this for i386 ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 16:27:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 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 1U9Hvs-0005Nf-0S; Sat, 23 Feb 2013 16:26:40 +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 1U9Hvr-0005NX-9C
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 16:26:39 +0000
Received: from [85.158.139.83:56012] by server-8.bemta-5.messagelabs.com id
	A0/F5-19075-EBDE8215; Sat, 23 Feb 2013 16:26:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361636797!25880990!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14381 invoked from network); 23 Feb 2013 16:26:37 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 16:26:37 -0000
Received: by mail-wg0-f51.google.com with SMTP id 8so1291717wgl.6
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 08:26:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kX3QfWCzjdKnyrl8CJ20vJL4/gVIpAHUpTf/o17SXVc=;
	b=kFgZsZd9mbGPj/o029f71kLn95hitrC7rapJNlD/SBgSB2gKK51O3r5PDegaoYJdOO
	VtlB0bFXBnHoWslmvqcN8265Pc/Rl8ENagOlNkPTTYm2T0r40LG1aUyiVl5yvi2isMDN
	/6aY6SiViAxMKcjzaEUqGK1wUL+8lmqJ90+hsZyes5WD5rotvVz+D1JqWUkXvFLVr8G0
	g/3L/0lgsIducWhHhAO+0sEW/tOApJ0MjGzAYrKgV0/3iosmaWN4ylf43RcTr9t0+OH8
	DBEZIRBuOeLFq4/Lc4KiEtKNk4Fp7o+lZm8bRluPXHneK/sTBGtyXJactdCossx+WGqF
	P5pQ==
X-Received: by 10.194.119.68 with SMTP id ks4mr9830645wjb.3.1361636797386;
	Sat, 23 Feb 2013 08:26:37 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id n2sm4313461wiy.6.2013.02.23.08.26.34
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Sat, 23 Feb 2013 08:26:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Sat, 23 Feb 2013 16:26:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Message-ID: <CD4E9E36.4C83D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL
Thread-Index: Ac4R4okN4cZRYR7BCkqq6Rg2Jymejw==
In-Reply-To: <20776.59833.627696.520908@mariner.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 23/02/2013 16:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):
>> flight 16231 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-i386                    4 xen-build             fail REGR. vs. 16226
> 
> gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
> -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c
> ./checker > tmp.size
> diff -u reference.size tmp.size
> --- reference.size 2013-02-22 22:53:31.000000000 +0000
> +++ tmp.size 2013-02-22 23:12:05.000000000 +0000
> @@ -5,7 +5,7 @@
>  trap_info                 |       -       -       8      16
>  cpu_user_regs             |       -       -      68     200
>  vcpu_guest_core_regs      |     304     304       -       -
> -vcpu_guest_context        |     336     336    2800    5168
> +vcpu_guest_context        |     332     332    2800    5168
>  arch_vcpu_info            |       -       -      24      16
>  vcpu_time_info            |       -       -      32      32
>  vcpu_info                 |       -       -      64      64
> make[4]: *** [check-headers] Error 1
> make[4]: Leaving directory
> `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'
> make[3]: Leaving directory
> `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'
> make[3]: *** [xen-foreign] Error 2
> 
> Are we supposed to still be doing this for i386 ?

Yes we are, as we still support our i386 guest ABI.

However, the problem in this case appears to be that the ARM structure size
has changed. If so, that needs to be fixed, or reference.size needs to be
updated.

 -- 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 Sat Feb 23 16:27:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 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 1U9Hvs-0005Nf-0S; Sat, 23 Feb 2013 16:26:40 +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 1U9Hvr-0005NX-9C
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 16:26:39 +0000
Received: from [85.158.139.83:56012] by server-8.bemta-5.messagelabs.com id
	A0/F5-19075-EBDE8215; Sat, 23 Feb 2013 16:26:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361636797!25880990!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14381 invoked from network); 23 Feb 2013 16:26:37 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 16:26:37 -0000
Received: by mail-wg0-f51.google.com with SMTP id 8so1291717wgl.6
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 08:26:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kX3QfWCzjdKnyrl8CJ20vJL4/gVIpAHUpTf/o17SXVc=;
	b=kFgZsZd9mbGPj/o029f71kLn95hitrC7rapJNlD/SBgSB2gKK51O3r5PDegaoYJdOO
	VtlB0bFXBnHoWslmvqcN8265Pc/Rl8ENagOlNkPTTYm2T0r40LG1aUyiVl5yvi2isMDN
	/6aY6SiViAxMKcjzaEUqGK1wUL+8lmqJ90+hsZyes5WD5rotvVz+D1JqWUkXvFLVr8G0
	g/3L/0lgsIducWhHhAO+0sEW/tOApJ0MjGzAYrKgV0/3iosmaWN4ylf43RcTr9t0+OH8
	DBEZIRBuOeLFq4/Lc4KiEtKNk4Fp7o+lZm8bRluPXHneK/sTBGtyXJactdCossx+WGqF
	P5pQ==
X-Received: by 10.194.119.68 with SMTP id ks4mr9830645wjb.3.1361636797386;
	Sat, 23 Feb 2013 08:26:37 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id n2sm4313461wiy.6.2013.02.23.08.26.34
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Sat, 23 Feb 2013 08:26:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Sat, 23 Feb 2013 16:26:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Message-ID: <CD4E9E36.4C83D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL
Thread-Index: Ac4R4okN4cZRYR7BCkqq6Rg2Jymejw==
In-Reply-To: <20776.59833.627696.520908@mariner.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 23/02/2013 16:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):
>> flight 16231 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-i386                    4 xen-build             fail REGR. vs. 16226
> 
> gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
> -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c
> ./checker > tmp.size
> diff -u reference.size tmp.size
> --- reference.size 2013-02-22 22:53:31.000000000 +0000
> +++ tmp.size 2013-02-22 23:12:05.000000000 +0000
> @@ -5,7 +5,7 @@
>  trap_info                 |       -       -       8      16
>  cpu_user_regs             |       -       -      68     200
>  vcpu_guest_core_regs      |     304     304       -       -
> -vcpu_guest_context        |     336     336    2800    5168
> +vcpu_guest_context        |     332     332    2800    5168
>  arch_vcpu_info            |       -       -      24      16
>  vcpu_time_info            |       -       -      32      32
>  vcpu_info                 |       -       -      64      64
> make[4]: *** [check-headers] Error 1
> make[4]: Leaving directory
> `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'
> make[3]: Leaving directory
> `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'
> make[3]: *** [xen-foreign] Error 2
> 
> Are we supposed to still be doing this for i386 ?

Yes we are, as we still support our i386 guest ABI.

However, the problem in this case appears to be that the ARM structure size
has changed. If so, that needs to be fixed, or reference.size needs to be
updated.

 -- 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 Sat Feb 23 17:03:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 17:03: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 1U9IVR-0006I8-1S; Sat, 23 Feb 2013 17:03:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@google.com>) id 1U9IVQ-0006I3-0H
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 17:03:24 +0000
Received: from [85.158.139.211:28396] by server-16.bemta-5.messagelabs.com id
	7D/9B-14948-B56F8215; Sat, 23 Feb 2013 17:03:23 +0000
X-Env-Sender: keescook@google.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361639001!18934410!1
X-Originating-IP: [209.85.219.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25006 invoked from network); 23 Feb 2013 17:03:22 -0000
Received: from mail-oa0-f42.google.com (HELO mail-oa0-f42.google.com)
	(209.85.219.42)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 17:03:22 -0000
Received: by mail-oa0-f42.google.com with SMTP id i18so1575256oag.29
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 09:03:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=WP2og9iJ+vg7o1XFSmnGzn6CE9JY5tZ5XfA6b5MKIxU=;
	b=XwJidVqXjQigkHUtxQ30tgZM3ldewDcFXhrPfncDIfFqTkR+e32kh8tuw7syseoqGb
	YJgOmt5fPqlfmKyNRIUZK0dy7QX6SVNpDJ2VrNFIn/a+VauijuuC1bS77EtpniLQVn0V
	A/A6v/abUdv6cS1sRoiADOl6o+/U1DnPu3003LMuYKrUIMJaNhG5HjypdxGTybMwP80W
	3EITlvkEMpcno2oHTiMg9V7BWQ71LxTWKcayCms3RjC1sGni9j89chdH+pF91Ftk4hh+
	2sIAfKCY4SSAHT+CHsb//mj3Oa1fZdExEbpskG08uFt7N1KKI0BaEyj0AaT6AUDz2oRN
	McXg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=WP2og9iJ+vg7o1XFSmnGzn6CE9JY5tZ5XfA6b5MKIxU=;
	b=cUxDSvJA41d2ScxZrvlaP3A+8MHaae6RAuC3XOlGzKFYjfz02LxjW9ZAtS4qhKdWph
	zmgkX6MqS4BpYF7bkGgtE2f31Wh250F+NKP67KOjs6vwo1MPxoma1ByyyaTYygnY+mm6
	UBshJ/xw2xpjQuAzhVcp1AC4GhgAofqI6nw8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=WP2og9iJ+vg7o1XFSmnGzn6CE9JY5tZ5XfA6b5MKIxU=;
	b=kNHA0LTEgWiGZ0d1oY0uCiqZv8Praeq/OseWxnRfRhzFprK2TDP31udjXOqL9GExOJ
	UGAJnEgByEjQNJUbWym8l0J9h1AXyp1whPpNhSCA4tICIBkMkXyPzhqb+pdxeQdgcV/4
	dciRHVCCEubGR7Pct28jpWJregntYqyuVbpcRBz/C1VY5gikUm7bNa+SlCsl92PawjPN
	NxzEjrmFbToNbq+Uw8mb1kpsdW222xNI5x+4ylym71SK1vhEr9Nme0xF7LMeOIlRNwtJ
	WbZpRV4Mjzbncvz1s71QdSRTtkwmS8ffVQWH9otn7UhTjLmtnY3qZ2CWH+8EOkH9Zs23
	vSfg==
MIME-Version: 1.0
X-Received: by 10.182.86.162 with SMTP id q2mr833245obz.35.1361639000853; Sat,
	23 Feb 2013 09:03:20 -0800 (PST)
Received: by 10.182.95.5 with HTTP; Sat, 23 Feb 2013 09:03:20 -0800 (PST)
In-Reply-To: <CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
Date: Sat, 23 Feb 2013 09:03:20 -0800
X-Google-Sender-Auth: DDPNUkbAiqmudKOOrWPCNWZ3hiQ
Message-ID: <CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
From: Kees Cook <keescook@chromium.org>
To: Dongsheng Song <dongsheng.song@gmail.com>
X-Gm-Message-State: ALoCoQkLw3xwpyrnEMUQ7S4mI9TckZmmTF1wIO1gC0rDoC0DbNdLfWik6dOmlUov7QTRWidgMznNqSEs6ZaRrQr3943293iGWrFj+UqxSDwgMSh1HvKxbRQkZeTk4q+UlARM3F/nyglgZ5oNzjzhe/dBR+XxpZFotLeVIwgaOyrdUC9680+O7zrn1xjHcEcCTUER+xkVBg7BdDOlP7FJqXQyKDDWCxpfPA==
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 23, 2013 at 3:59 AM, Dongsheng Song
<dongsheng.song@gmail.com> wrote:
> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
>> while now and is almost always enabled by default. As agreed during the
>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  arch/x86/xen/Kconfig |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index 93ff4e1..8cada4c 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
>>
>>  config XEN_X86_PVH
>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
>
> Why not remove this 'EXPERIMENTAL' too ?

It was unclear to me if the feature was actually considered unstable.
I can resend with the text removed from the title too, if that's the
correct action here?

-Kees

>
>> -       depends on X86_64 && XEN && EXPERIMENTAL
>> +       depends on X86_64 && XEN
>>         default n
>>         help
>>            This option enables support for running as a PVH guest (PV guest
>> --
>> 1.7.9.5
>>
>>
>> --
>> Kees Cook
>> Chrome OS Security
>> --
>> 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/



-- 
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 17:03:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 17:03: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 1U9IVR-0006I8-1S; Sat, 23 Feb 2013 17:03:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@google.com>) id 1U9IVQ-0006I3-0H
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 17:03:24 +0000
Received: from [85.158.139.211:28396] by server-16.bemta-5.messagelabs.com id
	7D/9B-14948-B56F8215; Sat, 23 Feb 2013 17:03:23 +0000
X-Env-Sender: keescook@google.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361639001!18934410!1
X-Originating-IP: [209.85.219.42]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25006 invoked from network); 23 Feb 2013 17:03:22 -0000
Received: from mail-oa0-f42.google.com (HELO mail-oa0-f42.google.com)
	(209.85.219.42)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 17:03:22 -0000
Received: by mail-oa0-f42.google.com with SMTP id i18so1575256oag.29
	for <xen-devel@lists.xensource.com>;
	Sat, 23 Feb 2013 09:03:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=WP2og9iJ+vg7o1XFSmnGzn6CE9JY5tZ5XfA6b5MKIxU=;
	b=XwJidVqXjQigkHUtxQ30tgZM3ldewDcFXhrPfncDIfFqTkR+e32kh8tuw7syseoqGb
	YJgOmt5fPqlfmKyNRIUZK0dy7QX6SVNpDJ2VrNFIn/a+VauijuuC1bS77EtpniLQVn0V
	A/A6v/abUdv6cS1sRoiADOl6o+/U1DnPu3003LMuYKrUIMJaNhG5HjypdxGTybMwP80W
	3EITlvkEMpcno2oHTiMg9V7BWQ71LxTWKcayCms3RjC1sGni9j89chdH+pF91Ftk4hh+
	2sIAfKCY4SSAHT+CHsb//mj3Oa1fZdExEbpskG08uFt7N1KKI0BaEyj0AaT6AUDz2oRN
	McXg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=WP2og9iJ+vg7o1XFSmnGzn6CE9JY5tZ5XfA6b5MKIxU=;
	b=cUxDSvJA41d2ScxZrvlaP3A+8MHaae6RAuC3XOlGzKFYjfz02LxjW9ZAtS4qhKdWph
	zmgkX6MqS4BpYF7bkGgtE2f31Wh250F+NKP67KOjs6vwo1MPxoma1ByyyaTYygnY+mm6
	UBshJ/xw2xpjQuAzhVcp1AC4GhgAofqI6nw8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=WP2og9iJ+vg7o1XFSmnGzn6CE9JY5tZ5XfA6b5MKIxU=;
	b=kNHA0LTEgWiGZ0d1oY0uCiqZv8Praeq/OseWxnRfRhzFprK2TDP31udjXOqL9GExOJ
	UGAJnEgByEjQNJUbWym8l0J9h1AXyp1whPpNhSCA4tICIBkMkXyPzhqb+pdxeQdgcV/4
	dciRHVCCEubGR7Pct28jpWJregntYqyuVbpcRBz/C1VY5gikUm7bNa+SlCsl92PawjPN
	NxzEjrmFbToNbq+Uw8mb1kpsdW222xNI5x+4ylym71SK1vhEr9Nme0xF7LMeOIlRNwtJ
	WbZpRV4Mjzbncvz1s71QdSRTtkwmS8ffVQWH9otn7UhTjLmtnY3qZ2CWH+8EOkH9Zs23
	vSfg==
MIME-Version: 1.0
X-Received: by 10.182.86.162 with SMTP id q2mr833245obz.35.1361639000853; Sat,
	23 Feb 2013 09:03:20 -0800 (PST)
Received: by 10.182.95.5 with HTTP; Sat, 23 Feb 2013 09:03:20 -0800 (PST)
In-Reply-To: <CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
Date: Sat, 23 Feb 2013 09:03:20 -0800
X-Google-Sender-Auth: DDPNUkbAiqmudKOOrWPCNWZ3hiQ
Message-ID: <CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
From: Kees Cook <keescook@chromium.org>
To: Dongsheng Song <dongsheng.song@gmail.com>
X-Gm-Message-State: ALoCoQkLw3xwpyrnEMUQ7S4mI9TckZmmTF1wIO1gC0rDoC0DbNdLfWik6dOmlUov7QTRWidgMznNqSEs6ZaRrQr3943293iGWrFj+UqxSDwgMSh1HvKxbRQkZeTk4q+UlARM3F/nyglgZ5oNzjzhe/dBR+XxpZFotLeVIwgaOyrdUC9680+O7zrn1xjHcEcCTUER+xkVBg7BdDOlP7FJqXQyKDDWCxpfPA==
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 23, 2013 at 3:59 AM, Dongsheng Song
<dongsheng.song@gmail.com> wrote:
> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
>> while now and is almost always enabled by default. As agreed during the
>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  arch/x86/xen/Kconfig |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index 93ff4e1..8cada4c 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
>>
>>  config XEN_X86_PVH
>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
>
> Why not remove this 'EXPERIMENTAL' too ?

It was unclear to me if the feature was actually considered unstable.
I can resend with the text removed from the title too, if that's the
correct action here?

-Kees

>
>> -       depends on X86_64 && XEN && EXPERIMENTAL
>> +       depends on X86_64 && XEN
>>         default n
>>         help
>>            This option enables support for running as a PVH guest (PV guest
>> --
>> 1.7.9.5
>>
>>
>> --
>> Kees Cook
>> Chrome OS Security
>> --
>> 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/



-- 
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 17:53:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 17:53: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 1U9JHH-0007Df-BQ; Sat, 23 Feb 2013 17:52:51 +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 1U9JHE-0007Da-Rm
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 17:52:49 +0000
Received: from [85.158.138.51:8967] by server-8.bemta-3.messagelabs.com id
	7C/65-25687-BE109215; Sat, 23 Feb 2013 17:52:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361641962!20780924!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26150 invoked from network); 23 Feb 2013 17:52:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 17:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,723,1355097600"; 
   d="scan'208";a="1812609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 17:52: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.297.1; Sat, 23 Feb 2013 17:51:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9IxZ-0001fW-No;
	Sat, 23 Feb 2013 17:32:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9IxZ-0007Oi-Fs;
	Sat, 23 Feb 2013 17:32:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16232-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 17:32:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16232: 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 16232 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16232/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10   fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-qemut-win   3 host-install(3)         broken REGR. vs. 16228

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 17:53:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 17:53: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 1U9JHH-0007Df-BQ; Sat, 23 Feb 2013 17:52:51 +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 1U9JHE-0007Da-Rm
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 17:52:49 +0000
Received: from [85.158.138.51:8967] by server-8.bemta-3.messagelabs.com id
	7C/65-25687-BE109215; Sat, 23 Feb 2013 17:52:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361641962!20780924!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26150 invoked from network); 23 Feb 2013 17:52:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 17:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,723,1355097600"; 
   d="scan'208";a="1812609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 17:52: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.297.1; Sat, 23 Feb 2013 17:51:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9IxZ-0001fW-No;
	Sat, 23 Feb 2013 17:32:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9IxZ-0007Oi-Fs;
	Sat, 23 Feb 2013 17:32:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16232-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 17:32:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16232: 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 16232 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16232/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10   fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-qemut-win   3 host-install(3)         broken REGR. vs. 16228

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 19:12:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 19: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 1U9KVn-0000Yg-9p; Sat, 23 Feb 2013 19:11:55 +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 1U9KVl-0000Yb-Kv
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 19:11:53 +0000
Received: from [85.158.139.83:27088] by server-3.bemta-5.messagelabs.com id
	BB/C5-07037-87419215; Sat, 23 Feb 2013 19:11:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361646709!28657341!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTU5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1886 invoked from network); 23 Feb 2013 19:11:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 19:11:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1NJBOJc023487
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 19:11:25 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
	r1NJBLjR001117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 19:11:21 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
	r1NJBIEU009604; Sat, 23 Feb 2013 13:11:18 -0600
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 23 Feb 2013 11:11:18 -0800
Date: Sat, 23 Feb 2013 14:11:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kees Cook <keescook@chromium.org>
Message-ID: <20130223191104.GA12606@konrad-lan.dumpdata.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
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,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> <dongsheng.song@gmail.com> wrote:
> > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> >>
> >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >> while now and is almost always enabled by default. As agreed during the
> >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> ---
> >>  arch/x86/xen/Kconfig |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >> index 93ff4e1..8cada4c 100644
> >> --- a/arch/x86/xen/Kconfig
> >> +++ b/arch/x86/xen/Kconfig
> >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> >>
> >>  config XEN_X86_PVH
> >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >
> > Why not remove this 'EXPERIMENTAL' too ?
> 
> It was unclear to me if the feature was actually considered unstable.
> I can resend with the text removed from the title too, if that's the
> correct action here?

It certainly is unstable right now (which is why it was unstaged from
the v3.9 train). I hope that by v3.10 it won't be - at which
point this patch (and the EXPERIMENTAL) makes sense.

So could you respin it please with the text removed as well - and I will
queue it up in the branch that carries the PVH feature?

Thanks!
> 
> -Kees
> 
> >
> >> -       depends on X86_64 && XEN && EXPERIMENTAL
> >> +       depends on X86_64 && XEN
> >>         default n
> >>         help
> >>            This option enables support for running as a PVH guest (PV guest
> >> --
> >> 1.7.9.5
> >>
> >>
> >> --
> >> Kees Cook
> >> Chrome OS Security
> >> --
> >> 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/
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 19:12:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 19: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 1U9KVn-0000Yg-9p; Sat, 23 Feb 2013 19:11:55 +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 1U9KVl-0000Yb-Kv
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 19:11:53 +0000
Received: from [85.158.139.83:27088] by server-3.bemta-5.messagelabs.com id
	BB/C5-07037-87419215; Sat, 23 Feb 2013 19:11:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361646709!28657341!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTU5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1886 invoked from network); 23 Feb 2013 19:11:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Feb 2013 19:11:51 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1NJBOJc023487
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 19:11:25 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
	r1NJBLjR001117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 23 Feb 2013 19:11:21 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
	r1NJBIEU009604; Sat, 23 Feb 2013 13:11:18 -0600
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 23 Feb 2013 11:11:18 -0800
Date: Sat, 23 Feb 2013 14:11:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kees Cook <keescook@chromium.org>
Message-ID: <20130223191104.GA12606@konrad-lan.dumpdata.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
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,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> <dongsheng.song@gmail.com> wrote:
> > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> >>
> >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >> while now and is almost always enabled by default. As agreed during the
> >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> ---
> >>  arch/x86/xen/Kconfig |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >> index 93ff4e1..8cada4c 100644
> >> --- a/arch/x86/xen/Kconfig
> >> +++ b/arch/x86/xen/Kconfig
> >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> >>
> >>  config XEN_X86_PVH
> >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >
> > Why not remove this 'EXPERIMENTAL' too ?
> 
> It was unclear to me if the feature was actually considered unstable.
> I can resend with the text removed from the title too, if that's the
> correct action here?

It certainly is unstable right now (which is why it was unstaged from
the v3.9 train). I hope that by v3.10 it won't be - at which
point this patch (and the EXPERIMENTAL) makes sense.

So could you respin it please with the text removed as well - and I will
queue it up in the branch that carries the PVH feature?

Thanks!
> 
> -Kees
> 
> >
> >> -       depends on X86_64 && XEN && EXPERIMENTAL
> >> +       depends on X86_64 && XEN
> >>         default n
> >>         help
> >>            This option enables support for running as a PVH guest (PV guest
> >> --
> >> 1.7.9.5
> >>
> >>
> >> --
> >> Kees Cook
> >> Chrome OS Security
> >> --
> >> 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/
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 19:17:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 19:17: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 1U9Kaa-0000gI-1n; Sat, 23 Feb 2013 19: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.Jackson@eu.citrix.com>) id 1U9KaY-0000gD-Kv
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 19:16:50 +0000
Received: from [85.158.138.51:35790] by server-15.bemta-3.messagelabs.com id
	D5/D1-25405-1A519215; Sat, 23 Feb 2013 19:16:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361647008!23456177!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31384 invoked from network); 23 Feb 2013 19:16:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 19:16:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,723,1355097600"; 
   d="scan'208";a="1813122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 19:16: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.297.1; Sat, 23 Feb 2013 19:16:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9KaV-0002D2-D8;
	Sat, 23 Feb 2013 19:16:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9KaV-0003Hh-0v;
	Sat, 23 Feb 2013 19:16:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16233-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 19:16:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16233: 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 16233 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16233/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 19:17:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 19:17: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 1U9Kaa-0000gI-1n; Sat, 23 Feb 2013 19: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.Jackson@eu.citrix.com>) id 1U9KaY-0000gD-Kv
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 19:16:50 +0000
Received: from [85.158.138.51:35790] by server-15.bemta-3.messagelabs.com id
	D5/D1-25405-1A519215; Sat, 23 Feb 2013 19:16:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361647008!23456177!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31384 invoked from network); 23 Feb 2013 19:16:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 19:16:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,723,1355097600"; 
   d="scan'208";a="1813122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 19:16: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.297.1; Sat, 23 Feb 2013 19:16:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9KaV-0002D2-D8;
	Sat, 23 Feb 2013 19:16:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9KaV-0003Hh-0v;
	Sat, 23 Feb 2013 19:16:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16233-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 19:16:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16233: 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 16233 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16233/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 20:42:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 20:42: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 1U9Lut-0002C4-1h; Sat, 23 Feb 2013 20:41:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1U9Lur-0002Bz-OI
	for xen-devel@lists.xen.org; Sat, 23 Feb 2013 20:41:53 +0000
Received: from [193.109.254.147:56442] by server-14.bemta-14.messagelabs.com
	id CF/2F-02031-09929215; Sat, 23 Feb 2013 20:41:52 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361652111!1736344!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQ3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10674 invoked from network); 23 Feb 2013 20:41:52 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	23 Feb 2013 20:41:52 -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 r1NKfeJs003151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 15:41:41 -0500
Received: from redhat.com (vpn1-7-149.ams2.redhat.com [10.36.7.149])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1NKfaru020796; Sat, 23 Feb 2013 15:41:37 -0500
Date: Sat, 23 Feb 2013 22:41:42 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>
Message-ID: <20130223204142.GA19069@redhat.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
	<5127BE6A.60304@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5127BE6A.60304@suse.de>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: define a TOM register to
 report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 22, 2013 at 07:52:26PM +0100, Andreas F=E4rber wrote:
> Am 22.02.2013 16:37, schrieb Hao, Xudong:
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Friday, February 22, 2013 5:04 PM
> >> To: Hao, Xudong
> >> Cc: stefano.stabellini@eu.citrix.com; Zhang, Xiantao; xen-devel@lists.=
xen.org;
> >> qemu-devel@nongnu.org; mst@redhat.com; aliguori@us.ibm.com
> >> Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report=
 the
> >> base of PCI
> >>
> >>>>> On 22.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
> >>> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
> >>>
> >>>      d->dev.config[I440FX_SMRAM] =3D 0x02;
> >>>
> >>> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> >>> +    if (xen_enabled()) {
> >>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xf0;
> >>> +    } else {
> >>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xe0;
> >>> +    }
> >>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] =3D 0x00;
> >>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] =3D 0x00;
> >>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] =3D 0x00;
> >>> +
> >>>      cpu_smm_register(&i440fx_set_smm, d);
> >>>      return 0;
> >>>  }
> >>
> >> Isn't this the wrong way round (big endian, when it needs to be
> >> little)?
> >>
> > Jan, =

> > =

> > Here it should be little endian since the following config reading is l=
ittle endian, I'll correct it. Thanks your comments.
> =

> Your colleague David Woodhouse has just prepared some i440fx cleanups.
> Please use dev->config instead of the indirect d->dev.config.
> =

> Given Jan's endianness comment, would alignment allow you to simply
> write as follows?
> =

> uint32_t addr =3D xen_enabled() ? 0xe0000000 : 0xf0000000;
> *(uint32_t *)&dev->config[I440FX_PCI_HOLE_BASE] =3D cpu_to_le32(addr);
> Then the byte-swapping would be explicit and the address in one piece
> grep'able. Alternatively:
> =

> cpu_to_le32s(&addr);
> for (i =3D 0; i < 4; i++) {
>     dev->config[... + i] =3D ((uint8_t *)&addr)[i];
> }

Please don't do either of these things, do not hack endian-ness manually,
we have APIs for pci endian-ness.  Please use pci_set_long
and friends for pci config accesses.

> =

> Anyway, please use "piix: " in the subject rather than "qemu: " if this
> is supposed to go into upstream qemu.git.
> =

> Regards,
> Andreas
> =

> -- =

> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe=
rg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 20:42:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 20:42: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 1U9Lut-0002C4-1h; Sat, 23 Feb 2013 20:41:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1U9Lur-0002Bz-OI
	for xen-devel@lists.xen.org; Sat, 23 Feb 2013 20:41:53 +0000
Received: from [193.109.254.147:56442] by server-14.bemta-14.messagelabs.com
	id CF/2F-02031-09929215; Sat, 23 Feb 2013 20:41:52 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361652111!1736344!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQ3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10674 invoked from network); 23 Feb 2013 20:41:52 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	23 Feb 2013 20:41:52 -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 r1NKfeJs003151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 23 Feb 2013 15:41:41 -0500
Received: from redhat.com (vpn1-7-149.ams2.redhat.com [10.36.7.149])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r1NKfaru020796; Sat, 23 Feb 2013 15:41:37 -0500
Date: Sat, 23 Feb 2013 22:41:42 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>
Message-ID: <20130223204142.GA19069@redhat.com>
References: <1361503393-10726-1-git-send-email-xudong.hao@intel.com>
	<5127428C02000078000C040A@nat28.tlf.novell.com>
	<403610A45A2B5242BD291EDAE8B37D300FF79C1F@SHSMSX102.ccr.corp.intel.com>
	<5127BE6A.60304@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5127BE6A.60304@suse.de>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: define a TOM register to
 report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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, Feb 22, 2013 at 07:52:26PM +0100, Andreas F=E4rber wrote:
> Am 22.02.2013 16:37, schrieb Hao, Xudong:
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Friday, February 22, 2013 5:04 PM
> >> To: Hao, Xudong
> >> Cc: stefano.stabellini@eu.citrix.com; Zhang, Xiantao; xen-devel@lists.=
xen.org;
> >> qemu-devel@nongnu.org; mst@redhat.com; aliguori@us.ibm.com
> >> Subject: Re: [Xen-devel] [PATCH] qemu: define a TOM register to report=
 the
> >> base of PCI
> >>
> >>>>> On 22.02.13 at 04:23, Xudong Hao <xudong.hao@intel.com> wrote:
> >>> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
> >>>
> >>>      d->dev.config[I440FX_SMRAM] =3D 0x02;
> >>>
> >>> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> >>> +    if (xen_enabled()) {
> >>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xf0;
> >>> +    } else {
> >>> +        d->dev.config[I440FX_PCI_HOLE_BASE] =3D 0xe0;
> >>> +    }
> >>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] =3D 0x00;
> >>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] =3D 0x00;
> >>> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] =3D 0x00;
> >>> +
> >>>      cpu_smm_register(&i440fx_set_smm, d);
> >>>      return 0;
> >>>  }
> >>
> >> Isn't this the wrong way round (big endian, when it needs to be
> >> little)?
> >>
> > Jan, =

> > =

> > Here it should be little endian since the following config reading is l=
ittle endian, I'll correct it. Thanks your comments.
> =

> Your colleague David Woodhouse has just prepared some i440fx cleanups.
> Please use dev->config instead of the indirect d->dev.config.
> =

> Given Jan's endianness comment, would alignment allow you to simply
> write as follows?
> =

> uint32_t addr =3D xen_enabled() ? 0xe0000000 : 0xf0000000;
> *(uint32_t *)&dev->config[I440FX_PCI_HOLE_BASE] =3D cpu_to_le32(addr);
> Then the byte-swapping would be explicit and the address in one piece
> grep'able. Alternatively:
> =

> cpu_to_le32s(&addr);
> for (i =3D 0; i < 4; i++) {
>     dev->config[... + i] =3D ((uint8_t *)&addr)[i];
> }

Please don't do either of these things, do not hack endian-ness manually,
we have APIs for pci endian-ness.  Please use pci_set_long
and friends for pci config accesses.

> =

> Anyway, please use "piix: " in the subject rather than "qemu: " if this
> is supposed to go into upstream qemu.git.
> =

> Regards,
> Andreas
> =

> -- =

> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe=
rg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 20:48:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 20:48: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 1U9M0L-0002Tt-04; Sat, 23 Feb 2013 20:47:33 +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 1U9M0K-0002Tn-4Q
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 20:47:32 +0000
Received: from [85.158.139.211:15895] by server-1.bemta-5.messagelabs.com id
	1F/FA-29263-3EA29215; Sat, 23 Feb 2013 20:47:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361652449!17416966!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3817 invoked from network); 23 Feb 2013 20:47:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 20:47:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; 
   d="scan'208";a="9213307"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	23 Feb 2013 20:47:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Sat, 23 Feb 2013 15:47:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9M0G-0006Ly-6F;
	Sat, 23 Feb 2013 20:47:28 +0000
Date: Sat, 23 Feb 2013 20:47:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130223191104.GA12606@konrad-lan.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<20130223191104.GA12606@konrad-lan.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kees Cook <keescook@chromium.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dongsheng Song <dongsheng.song@gmail.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > <dongsheng.song@gmail.com> wrote:
> > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > >>
> > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > >> while now and is almost always enabled by default. As agreed during the
> > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > >>
> > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >> ---
> > >>  arch/x86/xen/Kconfig |    2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > >> index 93ff4e1..8cada4c 100644
> > >> --- a/arch/x86/xen/Kconfig
> > >> +++ b/arch/x86/xen/Kconfig
> > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > >>
> > >>  config XEN_X86_PVH
> > >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > >
> > > Why not remove this 'EXPERIMENTAL' too ?
> > 
> > It was unclear to me if the feature was actually considered unstable.
> > I can resend with the text removed from the title too, if that's the
> > correct action here?
> 
> It certainly is unstable right now (which is why it was unstaged from
> the v3.9 train). I hope that by v3.10 it won't be - at which
> point this patch (and the EXPERIMENTAL) makes sense.
> 
> So could you respin it please with the text removed as well - and I will
> queue it up in the branch that carries the PVH feature?

We also have the same flag on Xen ARM, and the reason is that the ABI is
not stable yet. As soon as it is (I think soon now), I'll send a patch
to remove EXPERIMENTAL from there too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 20:48:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 20:48: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 1U9M0L-0002Tt-04; Sat, 23 Feb 2013 20:47:33 +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 1U9M0K-0002Tn-4Q
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 20:47:32 +0000
Received: from [85.158.139.211:15895] by server-1.bemta-5.messagelabs.com id
	1F/FA-29263-3EA29215; Sat, 23 Feb 2013 20:47:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361652449!17416966!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3817 invoked from network); 23 Feb 2013 20:47:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 20:47:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; 
   d="scan'208";a="9213307"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	23 Feb 2013 20:47:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Sat, 23 Feb 2013 15:47:28 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9M0G-0006Ly-6F;
	Sat, 23 Feb 2013 20:47:28 +0000
Date: Sat, 23 Feb 2013 20:47:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130223191104.GA12606@konrad-lan.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<20130223191104.GA12606@konrad-lan.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kees Cook <keescook@chromium.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dongsheng Song <dongsheng.song@gmail.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > <dongsheng.song@gmail.com> wrote:
> > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > >>
> > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > >> while now and is almost always enabled by default. As agreed during the
> > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > >>
> > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >> ---
> > >>  arch/x86/xen/Kconfig |    2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > >> index 93ff4e1..8cada4c 100644
> > >> --- a/arch/x86/xen/Kconfig
> > >> +++ b/arch/x86/xen/Kconfig
> > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > >>
> > >>  config XEN_X86_PVH
> > >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > >
> > > Why not remove this 'EXPERIMENTAL' too ?
> > 
> > It was unclear to me if the feature was actually considered unstable.
> > I can resend with the text removed from the title too, if that's the
> > correct action here?
> 
> It certainly is unstable right now (which is why it was unstaged from
> the v3.9 train). I hope that by v3.10 it won't be - at which
> point this patch (and the EXPERIMENTAL) makes sense.
> 
> So could you respin it please with the text removed as well - and I will
> queue it up in the branch that carries the PVH feature?

We also have the same flag on Xen ARM, and the reason is that the ABI is
not stable yet. As soon as it is (I think soon now), I'll send a patch
to remove EXPERIMENTAL from there too.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 23:19:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 23:19: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 1U9OMU-0006rx-Iy; Sat, 23 Feb 2013 23:18: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 1U9OMS-0006rs-RC
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 23:18:33 +0000
Received: from [85.158.143.99:54546] by server-1.bemta-4.messagelabs.com id
	1D/BF-06203-74E49215; Sat, 23 Feb 2013 23:18:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361661511!18474160!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5273 invoked from network); 23 Feb 2013 23:18:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 23:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; 
   d="scan'208";a="1814329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 23:18: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.297.1; Sat, 23 Feb 2013 23:18:30 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9OMQ-0003TL-Ju;
	Sat, 23 Feb 2013 23:18:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9OMQ-0007eE-Hc;
	Sat, 23 Feb 2013 23:18:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16234-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 23:18:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16234: 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 16234 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16234/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 16230

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Feb 23 23:19:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 23 Feb 2013 23:19: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 1U9OMU-0006rx-Iy; Sat, 23 Feb 2013 23:18: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 1U9OMS-0006rs-RC
	for xen-devel@lists.xensource.com; Sat, 23 Feb 2013 23:18:33 +0000
Received: from [85.158.143.99:54546] by server-1.bemta-4.messagelabs.com id
	1D/BF-06203-74E49215; Sat, 23 Feb 2013 23:18:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361661511!18474160!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5273 invoked from network); 23 Feb 2013 23:18:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Feb 2013 23:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; 
   d="scan'208";a="1814329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Feb 2013 23:18: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.297.1; Sat, 23 Feb 2013 23:18:30 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9OMQ-0003TL-Ju;
	Sat, 23 Feb 2013 23:18:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9OMQ-0007eE-Hc;
	Sat, 23 Feb 2013 23:18:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16234-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 23 Feb 2013 23:18:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16234: 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 16234 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16234/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 16230

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 00:39:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 00:39: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 1U9Pck-0000Rk-Ol; Sun, 24 Feb 2013 00:39: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 1U9Pcj-0000Rf-4m
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 00:39:25 +0000
Received: from [193.109.254.147:65223] by server-15.bemta-14.messagelabs.com
	id 68/A4-24599-C3169215; Sun, 24 Feb 2013 00:39:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361666363!8887963!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11880 invoked from network); 24 Feb 2013 00:39:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 00:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; 
   d="scan'208";a="1814670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 00:39: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.297.1; Sun, 24 Feb 2013 00:39:23 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9Pch-0003rr-8b;
	Sun, 24 Feb 2013 00:39:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9Pch-00016C-7w;
	Sun, 24 Feb 2013 00:39:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16235-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 00:39:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16235: 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 16235 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16235/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 00:39:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 00:39: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 1U9Pck-0000Rk-Ol; Sun, 24 Feb 2013 00:39: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 1U9Pcj-0000Rf-4m
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 00:39:25 +0000
Received: from [193.109.254.147:65223] by server-15.bemta-14.messagelabs.com
	id 68/A4-24599-C3169215; Sun, 24 Feb 2013 00:39:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361666363!8887963!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11880 invoked from network); 24 Feb 2013 00:39:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 00:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; 
   d="scan'208";a="1814670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 00:39: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.297.1; Sun, 24 Feb 2013 00:39:23 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9Pch-0003rr-8b;
	Sun, 24 Feb 2013 00:39:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9Pch-00016C-7w;
	Sun, 24 Feb 2013 00:39:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16235-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 00:39:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16235: 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 16235 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16235/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 01:15:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 01: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 1U9QBg-0005C1-Uq; Sun, 24 Feb 2013 01:15:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@mimuw.edu.pl>) id 1U9QBf-0005Bu-8K
	for xen-devel@lists.xen.org; Sun, 24 Feb 2013 01:15:31 +0000
Received: from [193.109.254.147:27085] by server-9.bemta-14.messagelabs.com id
	E9/5D-30867-2B969215; Sun, 24 Feb 2013 01:15:30 +0000
X-Env-Sender: marmarek@mimuw.edu.pl
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361668529!9447347!1
X-Originating-IP: [193.0.96.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17450 invoked from network); 24 Feb 2013 01:15:29 -0000
Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2013 01:15:29 -0000
Received: from localhost (localhost [127.0.0.1] ident=amavis)
	by duch.mimuw.edu.pl (Postfix) with ESMTP id 1804638;
	Sun, 24 Feb 2013 02:15:28 +0100 (CET)
X-Virus-Scanned: amavisd-new at mimuw.edu.pl
Received: from mail.mimuw.edu.pl ([193.0.96.6])
	by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10028)
	with ESMTP id Yw0U5KTgk0vz; Sun, 24 Feb 2013 02:15:26 +0100 (CET)
Received: by duch.mimuw.edu.pl (Postfix, from userid 1575)
	id 816E829; Sun, 24 Feb 2013 02:15:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9f7e5ef02139a2e1844e39844f1230c5ee899cc8
Message-Id: <9f7e5ef02139a2e1844e.1361668187@localhost.localdomain>
User-Agent: Mercurial-patchbomb/2.2.3
Date: Sun, 24 Feb 2013 02:09:47 +0100
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xen.org
Cc: marmarek@invisiblethingslab.com
Subject: [Xen-devel] [PATCH] libxl: Fix not initialized variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Marek Marczykowski <marmarek@invisiblethingslab.com>
# Date 1361668098 -3600
# Node ID 9f7e5ef02139a2e1844e39844f1230c5ee899cc8
# Parent  9f12bdd6b7f00e421f963775a80429c0f0c1740a
libxl: Fix not initialized variable

It is used for result domid from libxl__domain_make, but actually this function
have assert on an initial value.

This patch is intended for xen-4.1 only - 4.2 and later have reworked this
part of code already containing the fix.

Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -458,7 +458,7 @@ static int libxl_create_stubdom(libxl_ct
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
     libxl_domain_build_state state;
-    uint32_t domid;
+    uint32_t domid = 0;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 01:15:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 01: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 1U9QBg-0005C1-Uq; Sun, 24 Feb 2013 01:15:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marmarek@mimuw.edu.pl>) id 1U9QBf-0005Bu-8K
	for xen-devel@lists.xen.org; Sun, 24 Feb 2013 01:15:31 +0000
Received: from [193.109.254.147:27085] by server-9.bemta-14.messagelabs.com id
	E9/5D-30867-2B969215; Sun, 24 Feb 2013 01:15:30 +0000
X-Env-Sender: marmarek@mimuw.edu.pl
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361668529!9447347!1
X-Originating-IP: [193.0.96.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17450 invoked from network); 24 Feb 2013 01:15:29 -0000
Received: from mail.mimuw.edu.pl (HELO mail.mimuw.edu.pl) (193.0.96.6)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Feb 2013 01:15:29 -0000
Received: from localhost (localhost [127.0.0.1] ident=amavis)
	by duch.mimuw.edu.pl (Postfix) with ESMTP id 1804638;
	Sun, 24 Feb 2013 02:15:28 +0100 (CET)
X-Virus-Scanned: amavisd-new at mimuw.edu.pl
Received: from mail.mimuw.edu.pl ([193.0.96.6])
	by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10028)
	with ESMTP id Yw0U5KTgk0vz; Sun, 24 Feb 2013 02:15:26 +0100 (CET)
Received: by duch.mimuw.edu.pl (Postfix, from userid 1575)
	id 816E829; Sun, 24 Feb 2013 02:15:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9f7e5ef02139a2e1844e39844f1230c5ee899cc8
Message-Id: <9f7e5ef02139a2e1844e.1361668187@localhost.localdomain>
User-Agent: Mercurial-patchbomb/2.2.3
Date: Sun, 24 Feb 2013 02:09:47 +0100
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xen.org
Cc: marmarek@invisiblethingslab.com
Subject: [Xen-devel] [PATCH] libxl: Fix not initialized variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Marek Marczykowski <marmarek@invisiblethingslab.com>
# Date 1361668098 -3600
# Node ID 9f7e5ef02139a2e1844e39844f1230c5ee899cc8
# Parent  9f12bdd6b7f00e421f963775a80429c0f0c1740a
libxl: Fix not initialized variable

It is used for result domid from libxl__domain_make, but actually this function
have assert on an initial value.

This patch is intended for xen-4.1 only - 4.2 and later have reworked this
part of code already containing the fix.

Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -458,7 +458,7 @@ static int libxl_create_stubdom(libxl_ct
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
     libxl_domain_build_state state;
-    uint32_t domid;
+    uint32_t domid = 0;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 03:11:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 03:11: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 1U9RzC-0007an-Fv; Sun, 24 Feb 2013 03:10:46 +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 1U9RzB-0007aQ-9F; Sun, 24 Feb 2013 03:10:45 +0000
Received: from [193.109.254.147:10505] by server-10.bemta-14.messagelabs.com
	id 2F/A0-12679-4B489215; Sun, 24 Feb 2013 03:10:44 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361675441!2540620!1
X-Originating-IP: [209.85.210.46]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4967 invoked from network); 24 Feb 2013 03:10:43 -0000
Received: from mail-da0-f46.google.com (HELO mail-da0-f46.google.com)
	(209.85.210.46)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 03:10:43 -0000
Received: by mail-da0-f46.google.com with SMTP id p5so957183dak.33
	for <multiple recipients>; Sat, 23 Feb 2013 19:10:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=pM0uwOYK080X9hD292LxTpDT8VeuGZvejSLwPJf/fOU=;
	b=gGDTdOq9XGSEyk+b+v2CHbHcNP7vSPQ17SUi2fz6vJqHllH1q6ZHx+hqJ+cJhys6tZ
	soXDmVs0jmI98g4fJ1/soiwNxjv+HwRP05TyXErnYMY8QfgJIqgo3hq1uIY/Box7wPQE
	Xsc2iisrT15Nwj336YypY1YUSHnRtG/D+CUZciCfQ2JEgcpPP4AAGoi0i2hKNIICqcMX
	xSbf0qpqltkcLJZro49UNcoHz4Di2CydmjZdSy3g+V1hpcR5bV+JeUF4xyrG8E3kPOAG
	h4KRluBe9N4Tgn7nKCOmElL/fK5pNZIk6MZHME3kr0/5tCri1PhR3fXjmge/0iXCLEo6
	ikNw==
X-Received: by 10.68.213.7 with SMTP id no7mr11028718pbc.48.1361675441041;
	Sat, 23 Feb 2013 19:10:41 -0800 (PST)
Received: from [172.16.26.11] (dhcp50-95-220-163.hil-laxahhh.lax.wayport.net.
	[50.95.220.163])
	by mx.google.com with ESMTPS id rl3sm7811360pbb.28.2013.02.23.19.10.39
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 23 Feb 2013 19:10:39 -0800 (PST)
Message-ID: <512984AE.2060400@xen.org>
Date: Sun, 24 Feb 2013 03:10:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Anil Madhavapeddy <anil@recoil.org>, Amir M Chaudhry <amc79@cam.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-arm@lists.xen.org
Subject: [Xen-devel] [Vote] Results of formal vote for Mirage to be accepted
 as Xen.org Incubation Project
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,

sorry for the delay in posting the vote results for 
http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal.

The vote breakdown:
- 6 out of 7 Xen committers voted (including project leads)
- 5 were in favour
- 1 abstained due to the "choice of the ISC licence rather than a 
copyleft licence such as LGPLv2+"

So overall the vote carries.

We also several other community members voting in support of the 
proposal. We also discussed the proposal at the last Xen Maintainer, 
Committer and Developer Meeting, which expressed support for the proposal.

What happens next?
I will work with the Mirage project lead on a detailed plan for the 
Incubation phase.

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 Sun Feb 24 03:11:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 03:11: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 1U9RzC-0007an-Fv; Sun, 24 Feb 2013 03:10:46 +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 1U9RzB-0007aQ-9F; Sun, 24 Feb 2013 03:10:45 +0000
Received: from [193.109.254.147:10505] by server-10.bemta-14.messagelabs.com
	id 2F/A0-12679-4B489215; Sun, 24 Feb 2013 03:10:44 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361675441!2540620!1
X-Originating-IP: [209.85.210.46]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4967 invoked from network); 24 Feb 2013 03:10:43 -0000
Received: from mail-da0-f46.google.com (HELO mail-da0-f46.google.com)
	(209.85.210.46)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 03:10:43 -0000
Received: by mail-da0-f46.google.com with SMTP id p5so957183dak.33
	for <multiple recipients>; Sat, 23 Feb 2013 19:10:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=pM0uwOYK080X9hD292LxTpDT8VeuGZvejSLwPJf/fOU=;
	b=gGDTdOq9XGSEyk+b+v2CHbHcNP7vSPQ17SUi2fz6vJqHllH1q6ZHx+hqJ+cJhys6tZ
	soXDmVs0jmI98g4fJ1/soiwNxjv+HwRP05TyXErnYMY8QfgJIqgo3hq1uIY/Box7wPQE
	Xsc2iisrT15Nwj336YypY1YUSHnRtG/D+CUZciCfQ2JEgcpPP4AAGoi0i2hKNIICqcMX
	xSbf0qpqltkcLJZro49UNcoHz4Di2CydmjZdSy3g+V1hpcR5bV+JeUF4xyrG8E3kPOAG
	h4KRluBe9N4Tgn7nKCOmElL/fK5pNZIk6MZHME3kr0/5tCri1PhR3fXjmge/0iXCLEo6
	ikNw==
X-Received: by 10.68.213.7 with SMTP id no7mr11028718pbc.48.1361675441041;
	Sat, 23 Feb 2013 19:10:41 -0800 (PST)
Received: from [172.16.26.11] (dhcp50-95-220-163.hil-laxahhh.lax.wayport.net.
	[50.95.220.163])
	by mx.google.com with ESMTPS id rl3sm7811360pbb.28.2013.02.23.19.10.39
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 23 Feb 2013 19:10:39 -0800 (PST)
Message-ID: <512984AE.2060400@xen.org>
Date: Sun, 24 Feb 2013 03:10:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Anil Madhavapeddy <anil@recoil.org>, Amir M Chaudhry <amc79@cam.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-arm@lists.xen.org
Subject: [Xen-devel] [Vote] Results of formal vote for Mirage to be accepted
 as Xen.org Incubation Project
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,

sorry for the delay in posting the vote results for 
http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal.

The vote breakdown:
- 6 out of 7 Xen committers voted (including project leads)
- 5 were in favour
- 1 abstained due to the "choice of the ISC licence rather than a 
copyleft licence such as LGPLv2+"

So overall the vote carries.

We also several other community members voting in support of the 
proposal. We also discussed the proposal at the last Xen Maintainer, 
Committer and Developer Meeting, which expressed support for the proposal.

What happens next?
I will work with the Mirage project lead on a detailed plan for the 
Incubation phase.

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 Sun Feb 24 04:41:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 04:41: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 1U9TOI-00016z-KS; Sun, 24 Feb 2013 04:40:46 +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 1U9TOG-00016s-OL
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 04:40:45 +0000
Received: from [85.158.138.51:45045] by server-5.bemta-3.messagelabs.com id
	94/E2-04457-7C999215; Sun, 24 Feb 2013 04:40:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361680838!10233435!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7980 invoked from network); 24 Feb 2013 04:40:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 04:40:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,726,1355097600"; 
   d="scan'208";a="1815221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 04:40: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.297.1; Sun, 24 Feb 2013 04:40:38 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9TOA-000543-49;
	Sun, 24 Feb 2013 04:40:38 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9TOA-0008Ml-3B;
	Sun, 24 Feb 2013 04:40:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16236-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 04:40:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16236: 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 16236 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16236/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot           fail REGR. vs. 15418
 test-amd64-i386-xl-qemut-win-vcpus1  3 host-install(3)  broken REGR. vs. 15418

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

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-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 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-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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 04:41:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 04:41: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 1U9TOI-00016z-KS; Sun, 24 Feb 2013 04:40:46 +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 1U9TOG-00016s-OL
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 04:40:45 +0000
Received: from [85.158.138.51:45045] by server-5.bemta-3.messagelabs.com id
	94/E2-04457-7C999215; Sun, 24 Feb 2013 04:40:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361680838!10233435!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTY5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7980 invoked from network); 24 Feb 2013 04:40:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 04:40:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,726,1355097600"; 
   d="scan'208";a="1815221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 04:40: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.297.1; Sun, 24 Feb 2013 04:40:38 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9TOA-000543-49;
	Sun, 24 Feb 2013 04:40:38 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9TOA-0008Ml-3B;
	Sun, 24 Feb 2013 04:40:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16236-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 04:40:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16236: 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 16236 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16236/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot           fail REGR. vs. 15418
 test-amd64-i386-xl-qemut-win-vcpus1  3 host-install(3)  broken REGR. vs. 15418

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

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-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 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-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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 09:47:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 09:47: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 1U9YAO-0007DK-9W; Sun, 24 Feb 2013 09:46: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 1U9YAM-0007DF-SB
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 09:46:43 +0000
Received: from [85.158.139.83:34533] by server-4.bemta-5.messagelabs.com id
	F4/A3-29496-181E9215; Sun, 24 Feb 2013 09:46:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361699201!24311613!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19233 invoked from network); 24 Feb 2013 09:46:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 09:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,727,1355097600"; 
   d="scan'208";a="1816563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 09:46: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.297.1; Sun, 24 Feb 2013 09:46:40 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9YAK-0006d4-EO;
	Sun, 24 Feb 2013 09:46:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9YAK-0006vS-CP;
	Sun, 24 Feb 2013 09:46:40 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16260-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 09:46:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16260: 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 16260 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16260/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 16232
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 16232
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 16232
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16232 pass in 16260
 test-i386-i386-xl-qemut-win   3 host-install(3)  broken in 16232 pass in 16260

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 16232 never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 09:47:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 09:47: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 1U9YAO-0007DK-9W; Sun, 24 Feb 2013 09:46: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 1U9YAM-0007DF-SB
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 09:46:43 +0000
Received: from [85.158.139.83:34533] by server-4.bemta-5.messagelabs.com id
	F4/A3-29496-181E9215; Sun, 24 Feb 2013 09:46:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361699201!24311613!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19233 invoked from network); 24 Feb 2013 09:46:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 09:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,727,1355097600"; 
   d="scan'208";a="1816563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 09:46: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.297.1; Sun, 24 Feb 2013 09:46:40 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9YAK-0006d4-EO;
	Sun, 24 Feb 2013 09:46:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9YAK-0006vS-CP;
	Sun, 24 Feb 2013 09:46:40 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16260-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 09:46:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16260: 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 16260 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16260/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate          fail pass in 16232
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 16232
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 16232
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16232 pass in 16260
 test-i386-i386-xl-qemut-win   3 host-install(3)  broken in 16232 pass in 16260

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 16232 never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 10:19:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 10: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 1U9YfR-0007xp-7V; Sun, 24 Feb 2013 10:18:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongsheng.song@gmail.com>) id 1U9YFb-0007UZ-Rt
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 09:52:08 +0000
Received: from [85.158.138.51:4917] by server-1.bemta-3.messagelabs.com id
	28/80-08955-7C2E9215; Sun, 24 Feb 2013 09:52:07 +0000
X-Env-Sender: dongsheng.song@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361699524!23501625!1
X-Originating-IP: [209.85.219.54]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7632 invoked from network); 24 Feb 2013 09:52:06 -0000
Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com)
	(209.85.219.54)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 09:52:06 -0000
Received: by mail-oa0-f54.google.com with SMTP id n12so1949753oag.13
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Feb 2013 01:52:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=41tOAa6fNQLOliHrUvc/LeGtiB65J4nolRhMm/ZiOtA=;
	b=GggSqOcVWTTtrUuOr89kNwOWtRhKCXswzEWD6RHLWnA+RTzC78OW+8v85qFBxstPnW
	rkiDAagoqsZTPFb+D1FbnJqyET4PsJ9XWHj9vnFoV+1y3BAdE/CBrP2519ByPKiB7HMh
	oc3efTyz/7lR9N1fgWmEyxuvXI/rDnurav9oEAYcvfEtxO9ceexg4R5TAlHoHU/hOnID
	M31ikdrMW6SCJYzKSuRXArsN5MXGK+XBR0ulzB8igdRS2nAVvIK+6zkzHYD+pHBygHoF
	BxKZtnUu0x5rZ521Q8Ki1/zMPKKBpbVLywl3WLoeJR3tgJZV7FltzozISTbRjmOXIdSw
	Wwkw==
X-Received: by 10.182.156.44 with SMTP id wb12mr4232113obb.20.1361699524518;
	Sun, 24 Feb 2013 01:52:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.157.115 with HTTP; Sun, 24 Feb 2013 01:51:44 -0800 (PST)
In-Reply-To: <CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
From: Dongsheng Song <dongsheng.song@gmail.com>
Date: Sun, 24 Feb 2013 17:51:44 +0800
Message-ID: <CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
To: Kees Cook <keescook@chromium.org>
X-Mailman-Approved-At: Sun, 24 Feb 2013 10:18:48 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> <dongsheng.song@gmail.com> wrote:
>> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>>
>>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
>>> while now and is almost always enabled by default. As agreed during the
>>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>>>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>  arch/x86/xen/Kconfig |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>>> index 93ff4e1..8cada4c 100644
>>> --- a/arch/x86/xen/Kconfig
>>> +++ b/arch/x86/xen/Kconfig
>>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
>>>
>>>  config XEN_X86_PVH
>>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
>>
>> Why not remove this 'EXPERIMENTAL' too ?
>
> It was unclear to me if the feature was actually considered unstable.
> I can resend with the text removed from the title too, if that's the
> correct action here?
>
> -Kees
>

If such a feature was considered unstable, it should depends on EXPERIMENTAL.
We should not surprised users.

>>
>>> -       depends on X86_64 && XEN && EXPERIMENTAL
>>> +       depends on X86_64 && XEN
>>>         default n
>>>         help
>>>            This option enables support for running as a PVH guest (PV guest
>>> --
>>> 1.7.9.5
>>>
>>>
>>> --
>>> Kees Cook
>>> Chrome OS Security
>>> --
>>> 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/
>
>
>
> --
> Kees Cook
> Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 10:19:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 10: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 1U9YfR-0007xp-7V; Sun, 24 Feb 2013 10:18:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongsheng.song@gmail.com>) id 1U9YFb-0007UZ-Rt
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 09:52:08 +0000
Received: from [85.158.138.51:4917] by server-1.bemta-3.messagelabs.com id
	28/80-08955-7C2E9215; Sun, 24 Feb 2013 09:52:07 +0000
X-Env-Sender: dongsheng.song@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361699524!23501625!1
X-Originating-IP: [209.85.219.54]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7632 invoked from network); 24 Feb 2013 09:52:06 -0000
Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com)
	(209.85.219.54)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 09:52:06 -0000
Received: by mail-oa0-f54.google.com with SMTP id n12so1949753oag.13
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Feb 2013 01:52:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=41tOAa6fNQLOliHrUvc/LeGtiB65J4nolRhMm/ZiOtA=;
	b=GggSqOcVWTTtrUuOr89kNwOWtRhKCXswzEWD6RHLWnA+RTzC78OW+8v85qFBxstPnW
	rkiDAagoqsZTPFb+D1FbnJqyET4PsJ9XWHj9vnFoV+1y3BAdE/CBrP2519ByPKiB7HMh
	oc3efTyz/7lR9N1fgWmEyxuvXI/rDnurav9oEAYcvfEtxO9ceexg4R5TAlHoHU/hOnID
	M31ikdrMW6SCJYzKSuRXArsN5MXGK+XBR0ulzB8igdRS2nAVvIK+6zkzHYD+pHBygHoF
	BxKZtnUu0x5rZ521Q8Ki1/zMPKKBpbVLywl3WLoeJR3tgJZV7FltzozISTbRjmOXIdSw
	Wwkw==
X-Received: by 10.182.156.44 with SMTP id wb12mr4232113obb.20.1361699524518;
	Sun, 24 Feb 2013 01:52:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.157.115 with HTTP; Sun, 24 Feb 2013 01:51:44 -0800 (PST)
In-Reply-To: <CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
From: Dongsheng Song <dongsheng.song@gmail.com>
Date: Sun, 24 Feb 2013 17:51:44 +0800
Message-ID: <CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
To: Kees Cook <keescook@chromium.org>
X-Mailman-Approved-At: Sun, 24 Feb 2013 10:18:48 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> <dongsheng.song@gmail.com> wrote:
>> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>>
>>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
>>> while now and is almost always enabled by default. As agreed during the
>>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>>>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>  arch/x86/xen/Kconfig |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>>> index 93ff4e1..8cada4c 100644
>>> --- a/arch/x86/xen/Kconfig
>>> +++ b/arch/x86/xen/Kconfig
>>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
>>>
>>>  config XEN_X86_PVH
>>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
>>
>> Why not remove this 'EXPERIMENTAL' too ?
>
> It was unclear to me if the feature was actually considered unstable.
> I can resend with the text removed from the title too, if that's the
> correct action here?
>
> -Kees
>

If such a feature was considered unstable, it should depends on EXPERIMENTAL.
We should not surprised users.

>>
>>> -       depends on X86_64 && XEN && EXPERIMENTAL
>>> +       depends on X86_64 && XEN
>>>         default n
>>>         help
>>>            This option enables support for running as a PVH guest (PV guest
>>> --
>>> 1.7.9.5
>>>
>>>
>>> --
>>> Kees Cook
>>> Chrome OS Security
>>> --
>>> 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/
>
>
>
> --
> Kees Cook
> Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 11:29:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 11: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 1U9Zlb-00010r-DK; Sun, 24 Feb 2013 11:29: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 1U9Zla-00010m-8d
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 11:29:14 +0000
Received: from [85.158.138.51:37791] by server-9.bemta-3.messagelabs.com id
	72/82-09484-989F9215; Sun, 24 Feb 2013 11:29:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361705352!20837672!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17111 invoked from network); 24 Feb 2013 11:29:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 11:29:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,727,1355097600"; 
   d="scan'208";a="1817138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 11:29: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.297.1; Sun, 24 Feb 2013 11:29:12 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9ZlY-00078b-4Q;
	Sun, 24 Feb 2013 11:29:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9ZlY-0001sI-2t;
	Sun, 24 Feb 2013 11:29:12 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16275-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 11:29:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16275: 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 16275 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16275/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 11:29:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 11: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 1U9Zlb-00010r-DK; Sun, 24 Feb 2013 11:29: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 1U9Zla-00010m-8d
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 11:29:14 +0000
Received: from [85.158.138.51:37791] by server-9.bemta-3.messagelabs.com id
	72/82-09484-989F9215; Sun, 24 Feb 2013 11:29:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1361705352!20837672!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17111 invoked from network); 24 Feb 2013 11:29:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 11:29:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,727,1355097600"; 
   d="scan'208";a="1817138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 11:29: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.297.1; Sun, 24 Feb 2013 11:29:12 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9ZlY-00078b-4Q;
	Sun, 24 Feb 2013 11:29:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9ZlY-0001sI-2t;
	Sun, 24 Feb 2013 11:29:12 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16275-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 11:29:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16275: 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 16275 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16275/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-xend-qemuu-winxpsp3 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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 14:40:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 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 1U9cjq-0004wR-3f; Sun, 24 Feb 2013 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 <gregkh@linuxfoundation.org>) id 1U9cjo-0004wM-QP
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 14:39:37 +0000
Received: from [85.158.143.99:18876] by server-2.bemta-4.messagelabs.com id
	A3/43-12656-8262A215; Sun, 24 Feb 2013 14:39:36 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361716773!23690633!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31823 invoked from network); 24 Feb 2013 14:39:35 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 14:39:35 -0000
Received: by mail-da0-f45.google.com with SMTP id v40so1079588dad.18
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Feb 2013 06:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=XsfeBDCMER1/Xml7zdF8PzCnM/PzSHxC6YP6911POVE=;
	b=hLrd3IUAUoOGNiP2H3NYrxQ5/nKgvtFqyWFSKLvEefbQ/p8qpyl7Sd+6MfEMR5FN/s
	gXrTV0x202Hmv6UL93PH7hueKHsFkfYOfhlDF+uE85RvXaXU7pgM7BFi1/qZmV/q5P3w
	HxHDgnM8rO8ijeD6ywIJoVFzyw7lMjXAxoolE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-gm-message-state;
	bh=XsfeBDCMER1/Xml7zdF8PzCnM/PzSHxC6YP6911POVE=;
	b=kvB/rdl+G2xQcEJP5K2Kldxr6g17FIte+YFm65FAVoFyynn+FQuiC1JyZqHr35ZeS9
	BNeAdn+64TFYO0euu6v8/SN4WQMcyfwl6KqYcU8QURQrOW7LA3OXIl4XOi9QRPRxHK2P
	MIJyFVAgB4TehTslf8AXNJPmiM4PCD4cn7O/P+F05eVSvKPkzAgMdRxhNOxifeW17iKL
	gQ2/rNdVJEqt5JxDX1undiVwf7BTE9PXjsarHRelwAeM2XJypV/9jyPCuFd4T/1x2N1o
	p+DV1TqI969OwhH7lafQ6/7wKK8AawD1egtfHKjQqhNKG+kUe/4r9DDzljqo2DXE/dhj
	OxPg==
X-Received: by 10.66.13.136 with SMTP id h8mr13085125pac.204.1361716772819;
	Sun, 24 Feb 2013 06:39:32 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id rl3sm9416356pbb.28.2013.02.24.06.39.30
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sun, 24 Feb 2013 06:39:31 -0800 (PST)
Date: Sun, 24 Feb 2013 06:40:17 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dongsheng Song <dongsheng.song@gmail.com>
Message-ID: <20130224144017.GB1111@kroah.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQm4ufInSdOGdT28aBgsfwYsIFUHBLD3rbzaAlF6dyV21RUo/DlF2uHdNWZHySoODRgI3KUC
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Kees Cook <keescook@chromium.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > <dongsheng.song@gmail.com> wrote:
> >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> >>>
> >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >>> while now and is almost always enabled by default. As agreed during the
> >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>>
> >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> >>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> ---
> >>>  arch/x86/xen/Kconfig |    2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >>> index 93ff4e1..8cada4c 100644
> >>> --- a/arch/x86/xen/Kconfig
> >>> +++ b/arch/x86/xen/Kconfig
> >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> >>>
> >>>  config XEN_X86_PVH
> >>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >>
> >> Why not remove this 'EXPERIMENTAL' too ?
> >
> > It was unclear to me if the feature was actually considered unstable.
> > I can resend with the text removed from the title too, if that's the
> > correct action here?
> >
> > -Kees
> >
> 
> If such a feature was considered unstable, it should depends on EXPERIMENTAL.

CONFIG_EXPERIMENTAL is going away.

> We should not surprised users.

You should not have unstable options in the kernel in the first place,
sorry.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 14:40:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 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 1U9cjq-0004wR-3f; Sun, 24 Feb 2013 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 <gregkh@linuxfoundation.org>) id 1U9cjo-0004wM-QP
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 14:39:37 +0000
Received: from [85.158.143.99:18876] by server-2.bemta-4.messagelabs.com id
	A3/43-12656-8262A215; Sun, 24 Feb 2013 14:39:36 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361716773!23690633!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31823 invoked from network); 24 Feb 2013 14:39:35 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 14:39:35 -0000
Received: by mail-da0-f45.google.com with SMTP id v40so1079588dad.18
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Feb 2013 06:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=XsfeBDCMER1/Xml7zdF8PzCnM/PzSHxC6YP6911POVE=;
	b=hLrd3IUAUoOGNiP2H3NYrxQ5/nKgvtFqyWFSKLvEefbQ/p8qpyl7Sd+6MfEMR5FN/s
	gXrTV0x202Hmv6UL93PH7hueKHsFkfYOfhlDF+uE85RvXaXU7pgM7BFi1/qZmV/q5P3w
	HxHDgnM8rO8ijeD6ywIJoVFzyw7lMjXAxoolE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-gm-message-state;
	bh=XsfeBDCMER1/Xml7zdF8PzCnM/PzSHxC6YP6911POVE=;
	b=kvB/rdl+G2xQcEJP5K2Kldxr6g17FIte+YFm65FAVoFyynn+FQuiC1JyZqHr35ZeS9
	BNeAdn+64TFYO0euu6v8/SN4WQMcyfwl6KqYcU8QURQrOW7LA3OXIl4XOi9QRPRxHK2P
	MIJyFVAgB4TehTslf8AXNJPmiM4PCD4cn7O/P+F05eVSvKPkzAgMdRxhNOxifeW17iKL
	gQ2/rNdVJEqt5JxDX1undiVwf7BTE9PXjsarHRelwAeM2XJypV/9jyPCuFd4T/1x2N1o
	p+DV1TqI969OwhH7lafQ6/7wKK8AawD1egtfHKjQqhNKG+kUe/4r9DDzljqo2DXE/dhj
	OxPg==
X-Received: by 10.66.13.136 with SMTP id h8mr13085125pac.204.1361716772819;
	Sun, 24 Feb 2013 06:39:32 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id rl3sm9416356pbb.28.2013.02.24.06.39.30
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sun, 24 Feb 2013 06:39:31 -0800 (PST)
Date: Sun, 24 Feb 2013 06:40:17 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dongsheng Song <dongsheng.song@gmail.com>
Message-ID: <20130224144017.GB1111@kroah.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQm4ufInSdOGdT28aBgsfwYsIFUHBLD3rbzaAlF6dyV21RUo/DlF2uHdNWZHySoODRgI3KUC
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Kees Cook <keescook@chromium.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > <dongsheng.song@gmail.com> wrote:
> >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> >>>
> >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >>> while now and is almost always enabled by default. As agreed during the
> >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>>
> >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> >>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> ---
> >>>  arch/x86/xen/Kconfig |    2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >>> index 93ff4e1..8cada4c 100644
> >>> --- a/arch/x86/xen/Kconfig
> >>> +++ b/arch/x86/xen/Kconfig
> >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> >>>
> >>>  config XEN_X86_PVH
> >>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >>
> >> Why not remove this 'EXPERIMENTAL' too ?
> >
> > It was unclear to me if the feature was actually considered unstable.
> > I can resend with the text removed from the title too, if that's the
> > correct action here?
> >
> > -Kees
> >
> 
> If such a feature was considered unstable, it should depends on EXPERIMENTAL.

CONFIG_EXPERIMENTAL is going away.

> We should not surprised users.

You should not have unstable options in the kernel in the first place,
sorry.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 14:54:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 14: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 1U9cxU-0005RK-JI; Sun, 24 Feb 2013 14:53:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1U9cxS-0005RA-Ik
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 14:53:42 +0000
Received: from [85.158.137.99:30107] by server-13.bemta-3.messagelabs.com id
	A1/18-20653-5792A215; Sun, 24 Feb 2013 14:53:41 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361717619!12176714!1
X-Originating-IP: [209.85.210.174]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17539 invoked from network); 24 Feb 2013 14:53:40 -0000
Received: from mail-ia0-f174.google.com (HELO mail-ia0-f174.google.com)
	(209.85.210.174)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 14:53:40 -0000
Received: by mail-ia0-f174.google.com with SMTP id u20so1773631iag.19
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Feb 2013 06:53:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=XvK4kDIvZhQc/ZI1YhKRFOt5OIMn9T7kSbd5xmuTBu4=;
	b=g81+FomQd6621LXN4WNIbITBat6EcY80uD16jbs4Qsa8MfRPUVZyPxF67Ykpd/pPhi
	hw4RFRjBp23klHYeHHz4ePe8HXYv+6zSuraQxPwGkZoVdI8xHvcaVRq8xWYvdKwe2bvl
	EhCvVw9Z5sNp5MQ7yOv4CxTWmve2uGLg7tuManqp9BU0XA9scEz7DgkbeF/lSYu0jTD7
	AM0K7RZVNitJWRA2j5NXCca6Jz9sLvnnsmGD0hCrbghOXfGdNlICfEjVGDkjaZfJoLCX
	QzYGwqtRH16h2GYMh0PqYHtxT7eb6mfNvve+1RULtAICkjU9kbc+FulhrJ2TdaRWM0cl
	Ucng==
MIME-Version: 1.0
X-Received: by 10.50.17.163 with SMTP id p3mr1993052igd.90.1361717619177; Sun,
	24 Feb 2013 06:53:39 -0800 (PST)
Received: by 10.42.41.5 with HTTP; Sun, 24 Feb 2013 06:53:39 -0800 (PST)
Date: Sun, 24 Feb 2013 07:53:39 -0700
Message-ID: <CAHyyzzSddetdReODcxE3tM2Lz4NhRoc+m_VOxBe-kToRJViKrw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen hvm fails to 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="===============4600405755030791620=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4600405755030791620==
Content-Type: multipart/alternative; boundary=14dae93407cff9b95604d6799675

--14dae93407cff9b95604d6799675
Content-Type: text/plain; charset=ISO-8859-1

When I try to start hvm qemu-xen I get this error It seems that the path my
be off. Can someone point me were in source code path to qemu pid is
defined .It seems that qeum-xen points to loacation I don't see were it is
defined.
xc: detail: elf_load_binary: phdr 0 at 0x0x7f71cac72000 -> 0x0x7f71cad079d5
libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed
libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl_dm.c:1250:libxl__destroy_device_model: could not find
device-model's pid for dom 14
libxl: error: libxl.c:1414:libxl__destroy_domid:
libxl__destroy_device_model failed for 14
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x1bcc300:
complete, rc=-3
libxl: debug: libxl_create.c:1227:do_domain_create: ao 0x1bcc300:
inprogress: poller=0x1bccf70, flags=ic
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x1bcc300: destroy
xc: debug: hypercall buffer: total allocations:1166 total releases:1166
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:1158 misses:4 toobig:4

--14dae93407cff9b95604d6799675
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

When I try to start hvm qemu-xen I get this error It seems that the path my=
 be off. Can someone point me were in source code path to qemu pid is defin=
ed .It seems that qeum-xen points to loacation I don&#39;t see were it is d=
efined.=A0 <br>
xc: detail: elf_load_binary: phdr 0 at 0x0x7f71cac72000 -&gt; 0x0x7f71cad07=
9d5<br>libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed<=
br>libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)bui=
ld domain: -3<br>
libxl: error: libxl_dm.c:1250:libxl__destroy_device_model: could not find d=
evice-model&#39;s pid for dom 14<br>libxl: error: libxl.c:1414:libxl__destr=
oy_domid: libxl__destroy_device_model failed for 14<br>libxl: debug: libxl_=
event.c:1569:libxl__ao_complete: ao 0x1bcc300: complete, rc=3D-3<br>
libxl: debug: libxl_create.c:1227:do_domain_create: ao 0x1bcc300: inprogres=
s: poller=3D0x1bccf70, flags=3Dic<br>libxl: debug: libxl_event.c:1541:libxl=
__ao__destroy: ao 0x1bcc300: destroy<br>xc: debug: hypercall buffer: total =
allocations:1166 total releases:1166<br>
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4<br=
>xc: debug: hypercall buffer: cache current size:4<br>xc: debug: hypercall =
buffer: cache hits:1158 misses:4 toobig:4<br><br>

--14dae93407cff9b95604d6799675--


--===============4600405755030791620==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4600405755030791620==--


From xen-devel-bounces@lists.xen.org Sun Feb 24 14:54:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 14: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 1U9cxU-0005RK-JI; Sun, 24 Feb 2013 14:53:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jaceksburghardt@gmail.com>) id 1U9cxS-0005RA-Ik
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 14:53:42 +0000
Received: from [85.158.137.99:30107] by server-13.bemta-3.messagelabs.com id
	A1/18-20653-5792A215; Sun, 24 Feb 2013 14:53:41 +0000
X-Env-Sender: jaceksburghardt@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361717619!12176714!1
X-Originating-IP: [209.85.210.174]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17539 invoked from network); 24 Feb 2013 14:53:40 -0000
Received: from mail-ia0-f174.google.com (HELO mail-ia0-f174.google.com)
	(209.85.210.174)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 14:53:40 -0000
Received: by mail-ia0-f174.google.com with SMTP id u20so1773631iag.19
	for <xen-devel@lists.xensource.com>;
	Sun, 24 Feb 2013 06:53:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=XvK4kDIvZhQc/ZI1YhKRFOt5OIMn9T7kSbd5xmuTBu4=;
	b=g81+FomQd6621LXN4WNIbITBat6EcY80uD16jbs4Qsa8MfRPUVZyPxF67Ykpd/pPhi
	hw4RFRjBp23klHYeHHz4ePe8HXYv+6zSuraQxPwGkZoVdI8xHvcaVRq8xWYvdKwe2bvl
	EhCvVw9Z5sNp5MQ7yOv4CxTWmve2uGLg7tuManqp9BU0XA9scEz7DgkbeF/lSYu0jTD7
	AM0K7RZVNitJWRA2j5NXCca6Jz9sLvnnsmGD0hCrbghOXfGdNlICfEjVGDkjaZfJoLCX
	QzYGwqtRH16h2GYMh0PqYHtxT7eb6mfNvve+1RULtAICkjU9kbc+FulhrJ2TdaRWM0cl
	Ucng==
MIME-Version: 1.0
X-Received: by 10.50.17.163 with SMTP id p3mr1993052igd.90.1361717619177; Sun,
	24 Feb 2013 06:53:39 -0800 (PST)
Received: by 10.42.41.5 with HTTP; Sun, 24 Feb 2013 06:53:39 -0800 (PST)
Date: Sun, 24 Feb 2013 07:53:39 -0700
Message-ID: <CAHyyzzSddetdReODcxE3tM2Lz4NhRoc+m_VOxBe-kToRJViKrw@mail.gmail.com>
From: jacek burghardt <jaceksburghardt@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xen hvm fails to 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="===============4600405755030791620=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4600405755030791620==
Content-Type: multipart/alternative; boundary=14dae93407cff9b95604d6799675

--14dae93407cff9b95604d6799675
Content-Type: text/plain; charset=ISO-8859-1

When I try to start hvm qemu-xen I get this error It seems that the path my
be off. Can someone point me were in source code path to qemu pid is
defined .It seems that qeum-xen points to loacation I don't see were it is
defined.
xc: detail: elf_load_binary: phdr 0 at 0x0x7f71cac72000 -> 0x0x7f71cad079d5
libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed
libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)build
domain: -3
libxl: error: libxl_dm.c:1250:libxl__destroy_device_model: could not find
device-model's pid for dom 14
libxl: error: libxl.c:1414:libxl__destroy_domid:
libxl__destroy_device_model failed for 14
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x1bcc300:
complete, rc=-3
libxl: debug: libxl_create.c:1227:do_domain_create: ao 0x1bcc300:
inprogress: poller=0x1bccf70, flags=ic
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x1bcc300: destroy
xc: debug: hypercall buffer: total allocations:1166 total releases:1166
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:1158 misses:4 toobig:4

--14dae93407cff9b95604d6799675
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

When I try to start hvm qemu-xen I get this error It seems that the path my=
 be off. Can someone point me were in source code path to qemu pid is defin=
ed .It seems that qeum-xen points to loacation I don&#39;t see were it is d=
efined.=A0 <br>
xc: detail: elf_load_binary: phdr 0 at 0x0x7f71cac72000 -&gt; 0x0x7f71cad07=
9d5<br>libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed<=
br>libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)bui=
ld domain: -3<br>
libxl: error: libxl_dm.c:1250:libxl__destroy_device_model: could not find d=
evice-model&#39;s pid for dom 14<br>libxl: error: libxl.c:1414:libxl__destr=
oy_domid: libxl__destroy_device_model failed for 14<br>libxl: debug: libxl_=
event.c:1569:libxl__ao_complete: ao 0x1bcc300: complete, rc=3D-3<br>
libxl: debug: libxl_create.c:1227:do_domain_create: ao 0x1bcc300: inprogres=
s: poller=3D0x1bccf70, flags=3Dic<br>libxl: debug: libxl_event.c:1541:libxl=
__ao__destroy: ao 0x1bcc300: destroy<br>xc: debug: hypercall buffer: total =
allocations:1166 total releases:1166<br>
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4<br=
>xc: debug: hypercall buffer: cache current size:4<br>xc: debug: hypercall =
buffer: cache hits:1158 misses:4 toobig:4<br><br>

--14dae93407cff9b95604d6799675--


--===============4600405755030791620==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4600405755030791620==--


From xen-devel-bounces@lists.xen.org Sun Feb 24 15:28:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 15:28: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 1U9dUy-0006GH-0o; Sun, 24 Feb 2013 15:28:20 +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 1U9dUw-0006GC-Kt
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 15:28:18 +0000
Received: from [85.158.137.99:6692] by server-1.bemta-3.messagelabs.com id
	CD/72-08955-1913A215; Sun, 24 Feb 2013 15:28:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361719696!14551117!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10281 invoked from network); 24 Feb 2013 15:28:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 15:28:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,728,1355097600"; 
   d="scan'208";a="1818506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 15:28: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.297.1; Sun, 24 Feb 2013 15:28:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9dUu-0008LV-De;
	Sun, 24 Feb 2013 15:28:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9dUu-0008Oz-C2;
	Sun, 24 Feb 2013 15:28:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16308-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 15:28:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16308: 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 16308 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6743c50ca91da63de23ad52f037bf9eadacfb492
+ branch=xen-4.1-testing
+ revision=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : 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
++ : osstest@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
++ : 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=osstest@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@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 6743c50ca91da63de23ad52f037bf9eadacfb492 ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
------------------------------------------------------------
commit 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 15:28:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 15:28: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 1U9dUy-0006GH-0o; Sun, 24 Feb 2013 15:28:20 +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 1U9dUw-0006GC-Kt
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 15:28:18 +0000
Received: from [85.158.137.99:6692] by server-1.bemta-3.messagelabs.com id
	CD/72-08955-1913A215; Sun, 24 Feb 2013 15:28:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361719696!14551117!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10281 invoked from network); 24 Feb 2013 15:28:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 15:28:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,728,1355097600"; 
   d="scan'208";a="1818506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 15:28: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.297.1; Sun, 24 Feb 2013 15:28:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9dUu-0008LV-De;
	Sun, 24 Feb 2013 15:28:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9dUu-0008Oz-C2;
	Sun, 24 Feb 2013 15:28:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16308-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 15:28:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16308: 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 16308 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6743c50ca91da63de23ad52f037bf9eadacfb492
+ branch=xen-4.1-testing
+ revision=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : 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
++ : osstest@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
++ : 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=osstest@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@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 6743c50ca91da63de23ad52f037bf9eadacfb492 ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
------------------------------------------------------------
commit 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 17:04:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 17: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 1U9ezd-000087-Px; Sun, 24 Feb 2013 17: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.Jackson@eu.citrix.com>) id 1U9ezc-000082-LZ
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 17:04:04 +0000
Received: from [85.158.138.51:26840] by server-15.bemta-3.messagelabs.com id
	1B/A3-25405-3084A215; Sun, 24 Feb 2013 17:04:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361725442!23529475!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5063 invoked from network); 24 Feb 2013 17:04:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 17:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,728,1355097600"; 
   d="scan'208";a="1819081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 17:04: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.297.1; Sun, 24 Feb 2013 17:04:01 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9ezZ-0000Og-6h;
	Sun, 24 Feb 2013 17:04:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9ezZ-000592-2w;
	Sun, 24 Feb 2013 17:04:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16327-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 17:04:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16327: 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 16327 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16327/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-saverestore.2   fail pass in 16235
 test-amd64-amd64-pair        11 debian-install/dst_host     fail pass in 16235

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install  fail in 16235 blocked in 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-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-winxpsp3 13 guest-stop      fail in 16235 never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 17:04:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 17: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 1U9ezd-000087-Px; Sun, 24 Feb 2013 17: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.Jackson@eu.citrix.com>) id 1U9ezc-000082-LZ
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 17:04:04 +0000
Received: from [85.158.138.51:26840] by server-15.bemta-3.messagelabs.com id
	1B/A3-25405-3084A215; Sun, 24 Feb 2013 17:04:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361725442!23529475!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5063 invoked from network); 24 Feb 2013 17:04:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 17:04:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,728,1355097600"; 
   d="scan'208";a="1819081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 17:04: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.297.1; Sun, 24 Feb 2013 17:04:01 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9ezZ-0000Og-6h;
	Sun, 24 Feb 2013 17:04:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9ezZ-000592-2w;
	Sun, 24 Feb 2013 17:04:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16327-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 17:04:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16327: 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 16327 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16327/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-saverestore.2   fail pass in 16235
 test-amd64-amd64-pair        11 debian-install/dst_host     fail pass in 16235

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install  fail in 16235 blocked in 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-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-winxpsp3 13 guest-stop      fail in 16235 never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 20:02:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 20:02: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 1U9hlD-000421-GI; Sun, 24 Feb 2013 20:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sander.bogaert@elis.ugent.be>) id 1U9hlB-00041w-Lb
	for xen-devel@lists.xen.org; Sun, 24 Feb 2013 20:01:22 +0000
Received: from [85.158.139.211:3585] by server-14.bemta-5.messagelabs.com id
	AC/95-06967-0917A215; Sun, 24 Feb 2013 20:01:20 +0000
X-Env-Sender: sander.bogaert@elis.ugent.be
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361736079!19017224!1
X-Originating-IP: [157.193.49.126]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU3LjE5My40OS4xMjYgPT4gMzYyOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12382 invoked from network); 24 Feb 2013 20:01:19 -0000
Received: from smtp2.ugent.be (HELO smtp2.ugent.be) (157.193.49.126)
	by server-6.tower-206.messagelabs.com with SMTP;
	24 Feb 2013 20:01:19 -0000
Received: from localhost (mcheck2.ugent.be [157.193.49.249])
	by smtp2.ugent.be (Postfix) with ESMTP id C594512C2A4
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:19 +0100 (CET)
X-Virus-Scanned: by UGent DICT
Received: from smtp2.ugent.be ([157.193.49.126])
	by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new,
	port 10024) with ESMTP id wwpWCi85Ch5T for <xen-devel@lists.xen.org>;
	Sun, 24 Feb 2013 21:01:19 +0100 (CET)
Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48])
	by smtp2.ugent.be (Postfix) with ESMTP id 26C3812C2CB
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:19 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mail.elis.ugent.be (Postfix) with ESMTP id 00815918C5F
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at elis.ugent.be
Received: from mail.elis.ugent.be ([127.0.0.1])
	by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3l2W7jtRgfZE for <xen-devel@lists.xen.org>;
	Sun, 24 Feb 2013 21:01:12 +0100 (CET)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com
	[209.85.214.182])
	by mail.elis.ugent.be (Postfix) with ESMTP id 3CDDF918C60
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:12 +0100 (CET)
Received: by mail-ob0-f182.google.com with SMTP id va7so2172863obc.13
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 12:01:10 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.27.9 with SMTP id p9mr5557145oeg.72.1361736070416; Sun,
	24 Feb 2013 12:01:10 -0800 (PST)
Received: by 10.60.77.39 with HTTP; Sun, 24 Feb 2013 12:01:10 -0800 (PST)
In-Reply-To: <CANO7gZcE6YxVx7MPDqGJJUBwv0Y+kyfKoQxR3V=eBwS+gSHPSQ@mail.gmail.com>
References: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
	<511D18D8.10605@citrix.com>
	<CANO7gZcE6YxVx7MPDqGJJUBwv0Y+kyfKoQxR3V=eBwS+gSHPSQ@mail.gmail.com>
Date: Sun, 24 Feb 2013 21:01:10 +0100
Message-ID: <CANO7gZd7s+42LJHt=ZntUQmzBMRbNyFtv6_o++Obgum9jr1JrA@mail.gmail.com>
From: Sander Bogaert <sander.bogaert@elis.ugent.be>
To: Anthony PERARD <anthony.perard@citrix.com>
X-Miltered: at jchkm1 with ID 512A718F.000 by Joe's j-chkmail
	(http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 512A718F.000 from
	mail.elis.UGent.be/mail.elis.UGent.be/157.193.206.48/mail.elis.ugent.be/<sander.bogaert@elis.ugent.be>
X-j-chkmail-Score: MSGID : 512A718F.000 on smtp2.ugent.be : j-chkmail score :
	. : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3227889242632823867=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3227889242632823867==
Content-Type: multipart/alternative; boundary=e89a8fb2062ec1571004d67de23a

--e89a8fb2062ec1571004d67de23a
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I was wondering if anyone else is facing the same issue. I've copied
Anthony's PXE setup as well but without result. Using PXE or just sdcards
and fatload both end up freezing at Xen start-up with the same " *- Turning
on paging -* " message. Anthony you mentioned you previously had the same
problem, maybe you could give me some more pointers on how to fix it?

Thx,
Sander


On 18 February 2013 11:33, Sander Bogaert <sander.bogaert@elis.ugent.be>wrote:

> On 14 February 2013 18:03, Anthony PERARD <anthony.perard@citrix.com>wrote:
>
>> On 14/02/13 15:09, Sander Bogaert wrote:
>> > Hi,
>> >
>> > I'm trying to get Xen working on the Arndale Board
>>
>> Hi, thanks for trying :).
>>
>> > using these
>> > instructions:
>> >
>> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale
>>
>> Sorry, this wiki page is probably not complete yet.
>>
>> > When trying to build the Linux kernel from Linaro,
>> >
>> http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
>> > (
>> > configured as specified on the Xen wiki page ) I run into the following
>> > error while compiling:
>> >
>> > *drivers/xen/xenbus/xenbus_client.c: In function
>> > 'xenbus_map_ring_valloc_hvm':*
>> > *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration
>> of
>> > function 'page_to_section' [-Werror=implicit-function-declaration]*
>> > *cc1: some warnings being treated as errors*
>> > *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*
>> >
>> > I was wondering if anyone else ran into this and if so how best to
>> solve it.
>>
>> Yes, I've got a patch for it:
>> diff --git a/drivers/xen/xenbus/xenbus_client.c
>> b/drivers/xen/xenbus/xenbus_client.c
>> index bcf3ba4..686142d 100644
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -35,6 +35,7 @@
>>  #include <linux/spinlock.h>
>>  #include <linux/vmalloc.h>
>>  #include <linux/export.h>
>> +#include <linux/mm.h>
>>  #include <asm/xen/hypervisor.h>
>>  #include <asm/xen/page.h>
>>  #include <xen/interface/xen.h>
>>
>
> Thanks, this fixes the compilation problem.
>
>
>>
>>
>> > Booting Xen on the board hangs on "Turning on paging", is this related
>> to
>> > not having a dom0?
>>
>> Should not be, there is many things printed by Xen before it is trying
>> to boot dom0, and it would say that it can not find a dom0.
>>
>> > *...*
>> > *Startinrrrrrrrrrrrrrrrr- UART enabled -*
>> > *- CPU 00000000 booting -*
>> > *- Started in Hyp mode -*
>> > *- Zero BSS -*
>> > *- Setting up control registers -*
>> > *- Turning on paging -*
>>
>> All right, I've been able to reproduce the behaviour. Are you starting
>> Xen using the u-boot command "go"? Because this does not work with me.
>> It gave me some headache sometime ago. The command that works is "bootm
>> $xen_addr -"
>> So, I'm curious, how do you start Xen on the board?
>>
>> Here is what env I have on u-boot:
>> ipaddr=10.y.y.y
>> ipconfig=10.y.y.y
>> kernel_addr_r=0x40007000
>> serverip=10.x.x.x
>> tftp_path=10.x.x.x:pxelinux.cfg
>> usbethaddr=00:40:5c:26:0a:5b
>> ethaddr=00:40:5c:26:0a:5b
>> xen_addr_r=0x50000000
>> bootcmd_load_linux=tftpboot 0x40007000 10.80.3.61:
>> pxelinux.cfg/linux-zImage
>> boot_xen=run bootcmd_load_linux; tftpboot $xen_addr_r
>> $tftp_path/xen-uImage; bootm $xen_addr_r -
>> bootcmd=run boot_xen
>>
>> with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp
>> server (or PXE server).
>>
>> By the way, I've pushed a new branch: arndale-2013-02-13 which fix few
>> things.
>>
>
> This is the branch I've been using so far, I have been monitoring the
> repository for updates too and this still seems to be the latest right?
>
>
>>
>> This should make you pass the "turning on paging" step.
>>
>
> I'm still stuck at this step. Here is my environement:
>
> ARNDALE5250 # pri
> baudrate=115200
> boot_xen=run fatload_cmd; bootm 0x50000000 -
> bootargs=root=/dev/mmcblk1p1   rw rootwait console=ttySAC2,115200n8 init
> --no-log
> bootcmd=run boot_xen
> bootdelay=3
> dt_addr_r=0x42000000
> ethact=asx0
> fatload_cmd=fatload mmc0 0 40007000 linaroarndalekernel;fatload mmc0 0
> 42000000 dt.dtb;fatload mmc0 0 50000000 xen_uimage
> filesize=88308
> kernel_addr_r=0x40007000
> preboot=usb start
> stderr=serial
> stdin=serial
> stdout=serial
> usbethaddr=00:40:5c:26:0a:5b
> xen_addr_r=0x50000000
>
> Environment size: 514/16380 bytes
>
> A big difference is that I'm not trying to boot over PXE, instead I'm
> using the microSD card to load all the files. It has a FAT partition which
> I load from ( as you can see in the env ). I'm still stuck at the same
> stage, any ideas? I just try 'run boot_xen' to boot. I took the 0x50000000
> from your environement.
>
> Two other questions;
>
> * Don't we need to supply a device tree somewhere?
> * I read on the wiki (
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale ):
> "So don't expect to have a usable dom0 yet." and was wondering if this is
> still the case or if someone has a working installation already. If not,
> can I see the progress somewhere ( notes? ) or can you tell me what the
> current problems are?
>
>
>
>>
>> After that, you will probably need few patches for Linux. I'll push them
>> later.
>>
>> Have fun,
>>
>> --
>> Anthony PERARD
>>
>
> Thanks a lot for your help so far!
>
> Sander
>

--e89a8fb2062ec1571004d67de23a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I was wondering if anyone else is f=
acing the same issue. I&#39;ve copied Anthony&#39;s PXE setup as well but w=
ithout result. Using PXE or just sdcards and fatload both end up freezing a=
t Xen start-up with the same &quot;=A0*- Turning on paging -* &quot; messag=
e. Anthony you mentioned you previously had the same problem, maybe you cou=
ld give me some more pointers on how to fix it?</div>
<div><br></div><div>Thx,</div><div>Sander<br><div class=3D"gmail_extra"><br=
><br><div class=3D"gmail_quote">On 18 February 2013 11:33, Sander Bogaert <=
span dir=3D"ltr">&lt;<a href=3D"mailto:sander.bogaert@elis.ugent.be" target=
=3D"_blank">sander.bogaert@elis.ugent.be</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"im">On 14 February 2013 18:=
03, Anthony PERARD <span dir=3D"ltr">&lt;<a href=3D"mailto:anthony.perard@c=
itrix.com" target=3D"_blank">anthony.perard@citrix.com</a>&gt;</span> wrote=
:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=
=3D"h5">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>On 14/02/13 15:09, Sander Bogaert wrote:<br>

&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m trying to get Xen working on the Arndale Board<br>
<br>
</div>Hi, thanks for trying :).<br>
<div><br>
&gt; using these<br>
&gt; instructions:<br>
&gt; <a href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Exte=
nsions/Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_V=
irtualization_Extensions/Arndale</a><br>
<br>
</div>Sorry, this wiki page is probably not complete yet.<br>
<div><br>
&gt; When trying to build the Linux kernel from Linaro,<br>
&gt; <a href=3D"http://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_sta=
ble.git;a=3Dshortlog;h=3Drefs/heads/lue_arndale_3.7" target=3D"_blank">http=
://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_stable.git;a=3Dshortlog=
;h=3Drefs/heads/lue_arndale_3.7</a><br>


&gt; (<br>
&gt; configured as specified on the Xen wiki page ) I run into the followin=
g<br>
&gt; error while compiling:<br>
&gt;<br>
</div>&gt; *drivers/xen/xenbus/xenbus_client.c: In function<br>
&gt; &#39;xenbus_map_ring_valloc_hvm&#39;:*<br>
&gt; *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration=
 of<br>
&gt; function &#39;page_to_section&#39; [-Werror=3Dimplicit-function-declar=
ation]*<br>
&gt; *cc1: some warnings being treated as errors*<br>
&gt; *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*<br>
<div>&gt;<br>
&gt; I was wondering if anyone else ran into this and if so how best to sol=
ve it.<br>
<br>
</div>Yes, I&#39;ve got a patch for it:<br>
diff --git a/drivers/xen/xenbus/xenbus_client.c<br>
b/drivers/xen/xenbus/xenbus_client.c<br>
index bcf3ba4..686142d 100644<br>
--- a/drivers/xen/xenbus/xenbus_client.c<br>
+++ b/drivers/xen/xenbus/xenbus_client.c<br>
@@ -35,6 +35,7 @@<br>
=A0#include &lt;linux/spinlock.h&gt;<br>
=A0#include &lt;linux/vmalloc.h&gt;<br>
=A0#include &lt;linux/export.h&gt;<br>
+#include &lt;linux/mm.h&gt;<br>
=A0#include &lt;asm/xen/hypervisor.h&gt;<br>
=A0#include &lt;asm/xen/page.h&gt;<br>
=A0#include &lt;xen/interface/xen.h&gt;<br></blockquote><div><br></div></di=
v></div><div class=3D"im"><div><span style=3D"font-family:arial,sans-serif;=
font-size:13.333333969116211px">Thanks, this fixes the compilation problem.=
</span></div>
<div>=A0</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">

<div><br>
<br><div><div class=3D"h5">
&gt; Booting Xen on the board hangs on &quot;Turning on paging&quot;, is th=
is related to<br>
&gt; not having a dom0?<br>
<br>
</div></div></div><div><div class=3D"h5">Should not be, there is many thing=
s printed by Xen before it is trying<br>
to boot dom0, and it would say that it can not find a dom0.<br>
<br>
&gt; *...*<br>
&gt; *Startinrrrrrrrrrrrrrrrr- UART enabled -*<br>
&gt; *- CPU 00000000 booting -*<br>
&gt; *- Started in Hyp mode -*<br>
&gt; *- Zero BSS -*<br>
&gt; *- Setting up control registers -*<br>
&gt; *- Turning on paging -*<br>
<br>
All right, I&#39;ve been able to reproduce the behaviour. Are you starting<=
br>
Xen using the u-boot command &quot;go&quot;? Because this does not work wit=
h me.<br>
It gave me some headache sometime ago. The command that works is &quot;boot=
m<br>
$xen_addr -&quot;<br>
So, I&#39;m curious, how do you start Xen on the board?<br>
<br>
Here is what env I have on u-boot:<br>
ipaddr=3D10.y.y.y<br>
ipconfig=3D10.y.y.y<br>
kernel_addr_r=3D0x40007000<br>
serverip=3D10.x.x.x<br>
tftp_path=3D10.x.x.x:pxelinux.cfg<br>
usbethaddr=3D00:40:5c:26:0a:5b<br>
ethaddr=3D00:40:5c:26:0a:5b<br>
xen_addr_r=3D0x50000000<br>
bootcmd_load_linux=3Dtftpboot 0x40007000 10.80.3.61:pxelinux.cfg/linux-zIma=
ge<br>
boot_xen=3Drun bootcmd_load_linux; tftpboot $xen_addr_r<br>
$tftp_path/xen-uImage; bootm $xen_addr_r -<br>
bootcmd=3Drun boot_xen<br>
<br>
with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp<br>
server (or PXE server).<br>
<br>
By the way, I&#39;ve pushed a new branch: arndale-2013-02-13 which fix few<=
br>
things.<br></div></div></blockquote><div><br></div><div class=3D"im"><div><=
span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">=
This is the branch I&#39;ve been using so far, I have been monitoring the r=
epository for updates too and this still seems to be the latest right?</spa=
n></div>

<div>=A0</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">
<br><div class=3D"im">
This should make you pass the &quot;turning on paging&quot; step.<br></div>=
</blockquote><div><br></div><div class=3D"gmail_extra" style=3D"font-family=
:arial,sans-serif;font-size:13.333333969116211px"><div class=3D"gmail_quote=
">
<div class=3D"im"><div>
I&#39;m still stuck at this step. Here is my environement:</div><div><br></=
div><div>ARNDALE5250 # pri</div><div>baudrate=3D115200</div><div>boot_xen=
=3Drun fatload_cmd; bootm 0x50000000 -</div><div>bootargs=3Droot=3D/dev/mmc=
blk1p1 =A0 rw rootwait console=3DttySAC2,115200n8 init --no-log</div>

<div>bootcmd=3Drun boot_xen</div><div>bootdelay=3D3</div><div>dt_addr_r=3D0=
x42000000</div><div>ethact=3Dasx0</div><div>fatload_cmd=3Dfatload mmc0 0 40=
007000 linaroarndalekernel;fatload mmc0 0 42000000 dt.dtb;fatload mmc0 0 50=
000000 xen_uimage</div>

<div>filesize=3D88308</div><div>kernel_addr_r=3D0x40007000</div><div>preboo=
t=3Dusb start</div><div>stderr=3Dserial</div><div>stdin=3Dserial</div><div>=
stdout=3Dserial</div></div><div class=3D"im"><div>usbethaddr=3D00:40:5c:26:=
0a:5b</div>
</div><div class=3D"im"><div>xen_addr_r=3D0x50000000</div>
<div><br></div><div>Environment size: 514/16380 bytes</div><div><br></div><=
div>A big difference is that I&#39;m not trying to boot over PXE, instead I=
&#39;m using the microSD card to load all the files. It has a FAT partition=
 which I load from ( as you can see in the env ). I&#39;m still stuck at th=
e same stage, any ideas? I just try &#39;run boot_xen&#39; to boot. I took =
the 0x50000000 from your environement.</div>

<div><br></div><div>Two other questions;=A0</div></div></div></div><div cla=
ss=3D"im"><blockquote style=3D"font-family:arial,sans-serif;font-size:13.33=
3333969116211px;margin:0px 0px 0px 40px;border:none;padding:0px"><div class=
=3D"gmail_extra">
<div class=3D"gmail_quote">
* Don&#39;t we need to supply a device tree somewhere?=A0</div></div><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">* I read on the wiki (=A0<a=
 href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/=
Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtuali=
zation_Extensions/Arndale</a>=A0): &quot;So don&#39;t expect to have a usab=
le dom0 yet.&quot; and was wondering if this is still the case or if someon=
e has a working installation already. If not, can I see the progress somewh=
ere ( notes? ) or can you tell me what the current problems are?</div>

</div></blockquote><div><span style=3D"font-family:arial,sans-serif;font-si=
ze:13.333333969116211px">=A0</span>=A0</div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br><div class=3D"im">
After that, you will probably need few patches for Linux. I&#39;ll push the=
m<br>
later.<br>
<br>
Have fun,<br>
<span><font color=3D"#888888"><br>
--<br>
Anthony PERARD<br>
</font></span></div></blockquote></div><br></div><div class=3D"im"><div cla=
ss=3D"gmail_extra"><span style=3D"font-family:arial,sans-serif;font-size:13=
.333333969116211px">Thanks a lot for your help so far!</span><br></div><div=
 class=3D"gmail_extra">
<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
><br>
</span></div><div class=3D"gmail_extra"><span style=3D"font-family:arial,sa=
ns-serif;font-size:13.333333969116211px">Sander</span></div></div></div>
</blockquote></div><br></div></div></div>

--e89a8fb2062ec1571004d67de23a--


--===============3227889242632823867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3227889242632823867==--


From xen-devel-bounces@lists.xen.org Sun Feb 24 20:02:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 20:02: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 1U9hlD-000421-GI; Sun, 24 Feb 2013 20:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sander.bogaert@elis.ugent.be>) id 1U9hlB-00041w-Lb
	for xen-devel@lists.xen.org; Sun, 24 Feb 2013 20:01:22 +0000
Received: from [85.158.139.211:3585] by server-14.bemta-5.messagelabs.com id
	AC/95-06967-0917A215; Sun, 24 Feb 2013 20:01:20 +0000
X-Env-Sender: sander.bogaert@elis.ugent.be
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361736079!19017224!1
X-Originating-IP: [157.193.49.126]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU3LjE5My40OS4xMjYgPT4gMzYyOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12382 invoked from network); 24 Feb 2013 20:01:19 -0000
Received: from smtp2.ugent.be (HELO smtp2.ugent.be) (157.193.49.126)
	by server-6.tower-206.messagelabs.com with SMTP;
	24 Feb 2013 20:01:19 -0000
Received: from localhost (mcheck2.ugent.be [157.193.49.249])
	by smtp2.ugent.be (Postfix) with ESMTP id C594512C2A4
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:19 +0100 (CET)
X-Virus-Scanned: by UGent DICT
Received: from smtp2.ugent.be ([157.193.49.126])
	by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new,
	port 10024) with ESMTP id wwpWCi85Ch5T for <xen-devel@lists.xen.org>;
	Sun, 24 Feb 2013 21:01:19 +0100 (CET)
Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48])
	by smtp2.ugent.be (Postfix) with ESMTP id 26C3812C2CB
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:19 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mail.elis.ugent.be (Postfix) with ESMTP id 00815918C5F
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at elis.ugent.be
Received: from mail.elis.ugent.be ([127.0.0.1])
	by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3l2W7jtRgfZE for <xen-devel@lists.xen.org>;
	Sun, 24 Feb 2013 21:01:12 +0100 (CET)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com
	[209.85.214.182])
	by mail.elis.ugent.be (Postfix) with ESMTP id 3CDDF918C60
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 21:01:12 +0100 (CET)
Received: by mail-ob0-f182.google.com with SMTP id va7so2172863obc.13
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 12:01:10 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.27.9 with SMTP id p9mr5557145oeg.72.1361736070416; Sun,
	24 Feb 2013 12:01:10 -0800 (PST)
Received: by 10.60.77.39 with HTTP; Sun, 24 Feb 2013 12:01:10 -0800 (PST)
In-Reply-To: <CANO7gZcE6YxVx7MPDqGJJUBwv0Y+kyfKoQxR3V=eBwS+gSHPSQ@mail.gmail.com>
References: <CANO7gZffUDGqcBvY=+u5zX4_eHgkYUHWVD85do=BOyMxotWkbA@mail.gmail.com>
	<511D18D8.10605@citrix.com>
	<CANO7gZcE6YxVx7MPDqGJJUBwv0Y+kyfKoQxR3V=eBwS+gSHPSQ@mail.gmail.com>
Date: Sun, 24 Feb 2013 21:01:10 +0100
Message-ID: <CANO7gZd7s+42LJHt=ZntUQmzBMRbNyFtv6_o++Obgum9jr1JrA@mail.gmail.com>
From: Sander Bogaert <sander.bogaert@elis.ugent.be>
To: Anthony PERARD <anthony.perard@citrix.com>
X-Miltered: at jchkm1 with ID 512A718F.000 by Joe's j-chkmail
	(http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 512A718F.000 from
	mail.elis.UGent.be/mail.elis.UGent.be/157.193.206.48/mail.elis.ugent.be/<sander.bogaert@elis.ugent.be>
X-j-chkmail-Score: MSGID : 512A718F.000 on smtp2.ugent.be : j-chkmail score :
	. : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Trying to boot on Arndale Board.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============3227889242632823867=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3227889242632823867==
Content-Type: multipart/alternative; boundary=e89a8fb2062ec1571004d67de23a

--e89a8fb2062ec1571004d67de23a
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I was wondering if anyone else is facing the same issue. I've copied
Anthony's PXE setup as well but without result. Using PXE or just sdcards
and fatload both end up freezing at Xen start-up with the same " *- Turning
on paging -* " message. Anthony you mentioned you previously had the same
problem, maybe you could give me some more pointers on how to fix it?

Thx,
Sander


On 18 February 2013 11:33, Sander Bogaert <sander.bogaert@elis.ugent.be>wrote:

> On 14 February 2013 18:03, Anthony PERARD <anthony.perard@citrix.com>wrote:
>
>> On 14/02/13 15:09, Sander Bogaert wrote:
>> > Hi,
>> >
>> > I'm trying to get Xen working on the Arndale Board
>>
>> Hi, thanks for trying :).
>>
>> > using these
>> > instructions:
>> >
>> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale
>>
>> Sorry, this wiki page is probably not complete yet.
>>
>> > When trying to build the Linux kernel from Linaro,
>> >
>> http://git.linaro.org/gitweb?p=people/ronynandy/linux_stable.git;a=shortlog;h=refs/heads/lue_arndale_3.7
>> > (
>> > configured as specified on the Xen wiki page ) I run into the following
>> > error while compiling:
>> >
>> > *drivers/xen/xenbus/xenbus_client.c: In function
>> > 'xenbus_map_ring_valloc_hvm':*
>> > *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration
>> of
>> > function 'page_to_section' [-Werror=implicit-function-declaration]*
>> > *cc1: some warnings being treated as errors*
>> > *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*
>> >
>> > I was wondering if anyone else ran into this and if so how best to
>> solve it.
>>
>> Yes, I've got a patch for it:
>> diff --git a/drivers/xen/xenbus/xenbus_client.c
>> b/drivers/xen/xenbus/xenbus_client.c
>> index bcf3ba4..686142d 100644
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -35,6 +35,7 @@
>>  #include <linux/spinlock.h>
>>  #include <linux/vmalloc.h>
>>  #include <linux/export.h>
>> +#include <linux/mm.h>
>>  #include <asm/xen/hypervisor.h>
>>  #include <asm/xen/page.h>
>>  #include <xen/interface/xen.h>
>>
>
> Thanks, this fixes the compilation problem.
>
>
>>
>>
>> > Booting Xen on the board hangs on "Turning on paging", is this related
>> to
>> > not having a dom0?
>>
>> Should not be, there is many things printed by Xen before it is trying
>> to boot dom0, and it would say that it can not find a dom0.
>>
>> > *...*
>> > *Startinrrrrrrrrrrrrrrrr- UART enabled -*
>> > *- CPU 00000000 booting -*
>> > *- Started in Hyp mode -*
>> > *- Zero BSS -*
>> > *- Setting up control registers -*
>> > *- Turning on paging -*
>>
>> All right, I've been able to reproduce the behaviour. Are you starting
>> Xen using the u-boot command "go"? Because this does not work with me.
>> It gave me some headache sometime ago. The command that works is "bootm
>> $xen_addr -"
>> So, I'm curious, how do you start Xen on the board?
>>
>> Here is what env I have on u-boot:
>> ipaddr=10.y.y.y
>> ipconfig=10.y.y.y
>> kernel_addr_r=0x40007000
>> serverip=10.x.x.x
>> tftp_path=10.x.x.x:pxelinux.cfg
>> usbethaddr=00:40:5c:26:0a:5b
>> ethaddr=00:40:5c:26:0a:5b
>> xen_addr_r=0x50000000
>> bootcmd_load_linux=tftpboot 0x40007000 10.80.3.61:
>> pxelinux.cfg/linux-zImage
>> boot_xen=run bootcmd_load_linux; tftpboot $xen_addr_r
>> $tftp_path/xen-uImage; bootm $xen_addr_r -
>> bootcmd=run boot_xen
>>
>> with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp
>> server (or PXE server).
>>
>> By the way, I've pushed a new branch: arndale-2013-02-13 which fix few
>> things.
>>
>
> This is the branch I've been using so far, I have been monitoring the
> repository for updates too and this still seems to be the latest right?
>
>
>>
>> This should make you pass the "turning on paging" step.
>>
>
> I'm still stuck at this step. Here is my environement:
>
> ARNDALE5250 # pri
> baudrate=115200
> boot_xen=run fatload_cmd; bootm 0x50000000 -
> bootargs=root=/dev/mmcblk1p1   rw rootwait console=ttySAC2,115200n8 init
> --no-log
> bootcmd=run boot_xen
> bootdelay=3
> dt_addr_r=0x42000000
> ethact=asx0
> fatload_cmd=fatload mmc0 0 40007000 linaroarndalekernel;fatload mmc0 0
> 42000000 dt.dtb;fatload mmc0 0 50000000 xen_uimage
> filesize=88308
> kernel_addr_r=0x40007000
> preboot=usb start
> stderr=serial
> stdin=serial
> stdout=serial
> usbethaddr=00:40:5c:26:0a:5b
> xen_addr_r=0x50000000
>
> Environment size: 514/16380 bytes
>
> A big difference is that I'm not trying to boot over PXE, instead I'm
> using the microSD card to load all the files. It has a FAT partition which
> I load from ( as you can see in the env ). I'm still stuck at the same
> stage, any ideas? I just try 'run boot_xen' to boot. I took the 0x50000000
> from your environement.
>
> Two other questions;
>
> * Don't we need to supply a device tree somewhere?
> * I read on the wiki (
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Arndale ):
> "So don't expect to have a usable dom0 yet." and was wondering if this is
> still the case or if someone has a working installation already. If not,
> can I see the progress somewhere ( notes? ) or can you tell me what the
> current problems are?
>
>
>
>>
>> After that, you will probably need few patches for Linux. I'll push them
>> later.
>>
>> Have fun,
>>
>> --
>> Anthony PERARD
>>
>
> Thanks a lot for your help so far!
>
> Sander
>

--e89a8fb2062ec1571004d67de23a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I was wondering if anyone else is f=
acing the same issue. I&#39;ve copied Anthony&#39;s PXE setup as well but w=
ithout result. Using PXE or just sdcards and fatload both end up freezing a=
t Xen start-up with the same &quot;=A0*- Turning on paging -* &quot; messag=
e. Anthony you mentioned you previously had the same problem, maybe you cou=
ld give me some more pointers on how to fix it?</div>
<div><br></div><div>Thx,</div><div>Sander<br><div class=3D"gmail_extra"><br=
><br><div class=3D"gmail_quote">On 18 February 2013 11:33, Sander Bogaert <=
span dir=3D"ltr">&lt;<a href=3D"mailto:sander.bogaert@elis.ugent.be" target=
=3D"_blank">sander.bogaert@elis.ugent.be</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"im">On 14 February 2013 18:=
03, Anthony PERARD <span dir=3D"ltr">&lt;<a href=3D"mailto:anthony.perard@c=
itrix.com" target=3D"_blank">anthony.perard@citrix.com</a>&gt;</span> wrote=
:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=
=3D"h5">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>On 14/02/13 15:09, Sander Bogaert wrote:<br>

&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m trying to get Xen working on the Arndale Board<br>
<br>
</div>Hi, thanks for trying :).<br>
<div><br>
&gt; using these<br>
&gt; instructions:<br>
&gt; <a href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Exte=
nsions/Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_V=
irtualization_Extensions/Arndale</a><br>
<br>
</div>Sorry, this wiki page is probably not complete yet.<br>
<div><br>
&gt; When trying to build the Linux kernel from Linaro,<br>
&gt; <a href=3D"http://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_sta=
ble.git;a=3Dshortlog;h=3Drefs/heads/lue_arndale_3.7" target=3D"_blank">http=
://git.linaro.org/gitweb?p=3Dpeople/ronynandy/linux_stable.git;a=3Dshortlog=
;h=3Drefs/heads/lue_arndale_3.7</a><br>


&gt; (<br>
&gt; configured as specified on the Xen wiki page ) I run into the followin=
g<br>
&gt; error while compiling:<br>
&gt;<br>
</div>&gt; *drivers/xen/xenbus/xenbus_client.c: In function<br>
&gt; &#39;xenbus_map_ring_valloc_hvm&#39;:*<br>
&gt; *drivers/xen/xenbus/xenbus_client.c:532:9: error: implicit declaration=
 of<br>
&gt; function &#39;page_to_section&#39; [-Werror=3Dimplicit-function-declar=
ation]*<br>
&gt; *cc1: some warnings being treated as errors*<br>
&gt; *make[3]: *** [drivers/xen/xenbus/xenbus_client.o] Error 1*<br>
<div>&gt;<br>
&gt; I was wondering if anyone else ran into this and if so how best to sol=
ve it.<br>
<br>
</div>Yes, I&#39;ve got a patch for it:<br>
diff --git a/drivers/xen/xenbus/xenbus_client.c<br>
b/drivers/xen/xenbus/xenbus_client.c<br>
index bcf3ba4..686142d 100644<br>
--- a/drivers/xen/xenbus/xenbus_client.c<br>
+++ b/drivers/xen/xenbus/xenbus_client.c<br>
@@ -35,6 +35,7 @@<br>
=A0#include &lt;linux/spinlock.h&gt;<br>
=A0#include &lt;linux/vmalloc.h&gt;<br>
=A0#include &lt;linux/export.h&gt;<br>
+#include &lt;linux/mm.h&gt;<br>
=A0#include &lt;asm/xen/hypervisor.h&gt;<br>
=A0#include &lt;asm/xen/page.h&gt;<br>
=A0#include &lt;xen/interface/xen.h&gt;<br></blockquote><div><br></div></di=
v></div><div class=3D"im"><div><span style=3D"font-family:arial,sans-serif;=
font-size:13.333333969116211px">Thanks, this fixes the compilation problem.=
</span></div>
<div>=A0</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">

<div><br>
<br><div><div class=3D"h5">
&gt; Booting Xen on the board hangs on &quot;Turning on paging&quot;, is th=
is related to<br>
&gt; not having a dom0?<br>
<br>
</div></div></div><div><div class=3D"h5">Should not be, there is many thing=
s printed by Xen before it is trying<br>
to boot dom0, and it would say that it can not find a dom0.<br>
<br>
&gt; *...*<br>
&gt; *Startinrrrrrrrrrrrrrrrr- UART enabled -*<br>
&gt; *- CPU 00000000 booting -*<br>
&gt; *- Started in Hyp mode -*<br>
&gt; *- Zero BSS -*<br>
&gt; *- Setting up control registers -*<br>
&gt; *- Turning on paging -*<br>
<br>
All right, I&#39;ve been able to reproduce the behaviour. Are you starting<=
br>
Xen using the u-boot command &quot;go&quot;? Because this does not work wit=
h me.<br>
It gave me some headache sometime ago. The command that works is &quot;boot=
m<br>
$xen_addr -&quot;<br>
So, I&#39;m curious, how do you start Xen on the board?<br>
<br>
Here is what env I have on u-boot:<br>
ipaddr=3D10.y.y.y<br>
ipconfig=3D10.y.y.y<br>
kernel_addr_r=3D0x40007000<br>
serverip=3D10.x.x.x<br>
tftp_path=3D10.x.x.x:pxelinux.cfg<br>
usbethaddr=3D00:40:5c:26:0a:5b<br>
ethaddr=3D00:40:5c:26:0a:5b<br>
xen_addr_r=3D0x50000000<br>
bootcmd_load_linux=3Dtftpboot 0x40007000 10.80.3.61:pxelinux.cfg/linux-zIma=
ge<br>
boot_xen=3Drun bootcmd_load_linux; tftpboot $xen_addr_r<br>
$tftp_path/xen-uImage; bootm $xen_addr_r -<br>
bootcmd=3Drun boot_xen<br>
<br>
with 10.y.y.y the ip addr of the board and 10.x.x.x the ip of a tftp<br>
server (or PXE server).<br>
<br>
By the way, I&#39;ve pushed a new branch: arndale-2013-02-13 which fix few<=
br>
things.<br></div></div></blockquote><div><br></div><div class=3D"im"><div><=
span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">=
This is the branch I&#39;ve been using so far, I have been monitoring the r=
epository for updates too and this still seems to be the latest right?</spa=
n></div>

<div>=A0</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">
<br><div class=3D"im">
This should make you pass the &quot;turning on paging&quot; step.<br></div>=
</blockquote><div><br></div><div class=3D"gmail_extra" style=3D"font-family=
:arial,sans-serif;font-size:13.333333969116211px"><div class=3D"gmail_quote=
">
<div class=3D"im"><div>
I&#39;m still stuck at this step. Here is my environement:</div><div><br></=
div><div>ARNDALE5250 # pri</div><div>baudrate=3D115200</div><div>boot_xen=
=3Drun fatload_cmd; bootm 0x50000000 -</div><div>bootargs=3Droot=3D/dev/mmc=
blk1p1 =A0 rw rootwait console=3DttySAC2,115200n8 init --no-log</div>

<div>bootcmd=3Drun boot_xen</div><div>bootdelay=3D3</div><div>dt_addr_r=3D0=
x42000000</div><div>ethact=3Dasx0</div><div>fatload_cmd=3Dfatload mmc0 0 40=
007000 linaroarndalekernel;fatload mmc0 0 42000000 dt.dtb;fatload mmc0 0 50=
000000 xen_uimage</div>

<div>filesize=3D88308</div><div>kernel_addr_r=3D0x40007000</div><div>preboo=
t=3Dusb start</div><div>stderr=3Dserial</div><div>stdin=3Dserial</div><div>=
stdout=3Dserial</div></div><div class=3D"im"><div>usbethaddr=3D00:40:5c:26:=
0a:5b</div>
</div><div class=3D"im"><div>xen_addr_r=3D0x50000000</div>
<div><br></div><div>Environment size: 514/16380 bytes</div><div><br></div><=
div>A big difference is that I&#39;m not trying to boot over PXE, instead I=
&#39;m using the microSD card to load all the files. It has a FAT partition=
 which I load from ( as you can see in the env ). I&#39;m still stuck at th=
e same stage, any ideas? I just try &#39;run boot_xen&#39; to boot. I took =
the 0x50000000 from your environement.</div>

<div><br></div><div>Two other questions;=A0</div></div></div></div><div cla=
ss=3D"im"><blockquote style=3D"font-family:arial,sans-serif;font-size:13.33=
3333969116211px;margin:0px 0px 0px 40px;border:none;padding:0px"><div class=
=3D"gmail_extra">
<div class=3D"gmail_quote">
* Don&#39;t we need to supply a device tree somewhere?=A0</div></div><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">* I read on the wiki (=A0<a=
 href=3D"http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/=
Arndale" target=3D"_blank">http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtuali=
zation_Extensions/Arndale</a>=A0): &quot;So don&#39;t expect to have a usab=
le dom0 yet.&quot; and was wondering if this is still the case or if someon=
e has a working installation already. If not, can I see the progress somewh=
ere ( notes? ) or can you tell me what the current problems are?</div>

</div></blockquote><div><span style=3D"font-family:arial,sans-serif;font-si=
ze:13.333333969116211px">=A0</span>=A0</div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br><div class=3D"im">
After that, you will probably need few patches for Linux. I&#39;ll push the=
m<br>
later.<br>
<br>
Have fun,<br>
<span><font color=3D"#888888"><br>
--<br>
Anthony PERARD<br>
</font></span></div></blockquote></div><br></div><div class=3D"im"><div cla=
ss=3D"gmail_extra"><span style=3D"font-family:arial,sans-serif;font-size:13=
.333333969116211px">Thanks a lot for your help so far!</span><br></div><div=
 class=3D"gmail_extra">
<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
><br>
</span></div><div class=3D"gmail_extra"><span style=3D"font-family:arial,sa=
ns-serif;font-size:13.333333969116211px">Sander</span></div></div></div>
</blockquote></div><br></div></div></div>

--e89a8fb2062ec1571004d67de23a--


--===============3227889242632823867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3227889242632823867==--


From xen-devel-bounces@lists.xen.org Sun Feb 24 22:06:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 22:06: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 1U9jhI-0006Xg-Mf; Sun, 24 Feb 2013 22:05:28 +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 1U9jhH-0006XR-Ub
	for xen-devel@lists.xen.org; Sun, 24 Feb 2013 22:05:28 +0000
Received: from [85.158.139.83:14680] by server-5.bemta-5.messagelabs.com id
	88/8E-11945-7AE8A215; Sun, 24 Feb 2013 22:05:27 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361743525!26917750!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzM3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11418 invoked from network); 24 Feb 2013 22:05:26 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2013 22:05:26 -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 3A6D727D4;
	Mon, 25 Feb 2013 00:05:24 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id AD3F1F4017; Mon, 25 Feb 2013 00:05:24 +0200 (EET)
Date: Mon, 25 Feb 2013 00:05:24 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130224220524.GY8912@reaktio.net>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221122913.GC6647@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > =

> > # modprobe xen-acpi-processor
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.ce=
ntos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output err=
or
> > =

> > Using "modprobe -v" doesn't provide any more information about the prob=
lem.
> > Also there's nothing in dom0 kernel dmesg.
> > =

> > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > Xen 4.2.1.
> > =

> > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable v=
ersion) =

> > with some additional Xen patches backported from later upstream kernels=
. =

> > Any tips how to troubleshoot this? =

> =

> Rebuild the module and add this
> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proc=
essor.c
> index 316df65..5d824a2 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -16,6 +16,7 @@
>   * more details.
>   *
>   */
> +#define DEBUG 1
>  =

>  #include <linux/cpumask.h>
>  #include <linux/cpufreq.h>
> =

> =

> That should help in figuring it out.
> =


This is what I get with DEBUG enabled:

# modprobe -v xen-acpi-processor
insmod /lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-pr=
ocessor.ko
FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.dbg1.el6.x=
86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error

in dom0 kernel dmesg:
xen-acpi-processor: Max ACPI ID: 24

.. and that's all.

Adding more debug options on the kernel cmdline I see this:
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned -5=
 after 67 usecs
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned wi=
th error code -5

And enabling some ACPI debug options:
processor_perflib-0430 [00] processor_get_performa: ACPI-based processor pe=
rformance control unavailable


I added a bunch of more calls to pr_debug() in xen_acpi_processor_init() an=
d it seems:

        /* Do initialization in ACPI core. It is OK to fail here. */
        (void)acpi_processor_preregister_performance(acpi_perf_data);

        for_each_possible_cpu(i) {
                struct acpi_processor_performance *perf;

                perf =3D per_cpu_ptr(acpi_perf_data, i);
                rc =3D acpi_processor_register_performance(perf, i);
                if (rc)
                        goto err_out;
        }

"goto err_out" is the path taken from here..
It seems acpi_processor_register_performance() returns -EIO.

.. which means in acpi_processor_register_performance()

        if (acpi_processor_get_performance_info(pr)) {
                pr->performance =3D NULL;
                mutex_unlock(&performance_mutex);
                return -EIO;
        }


It seems acpi_processor_get_performance_info() returns -ENODEV:

        if (ACPI_FAILURE(status)) {
                ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                                  "ACPI-based processor performance control=
 unavailable\n"));
                return -ENODEV;
        }


Does this ring any bells? =


Thanks,

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 22:06:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 22:06: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 1U9jhI-0006Xg-Mf; Sun, 24 Feb 2013 22:05:28 +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 1U9jhH-0006XR-Ub
	for xen-devel@lists.xen.org; Sun, 24 Feb 2013 22:05:28 +0000
Received: from [85.158.139.83:14680] by server-5.bemta-5.messagelabs.com id
	88/8E-11945-7AE8A215; Sun, 24 Feb 2013 22:05:27 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361743525!26917750!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzM3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11418 invoked from network); 24 Feb 2013 22:05:26 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Feb 2013 22:05:26 -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 3A6D727D4;
	Mon, 25 Feb 2013 00:05:24 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id AD3F1F4017; Mon, 25 Feb 2013 00:05:24 +0200 (EET)
Date: Mon, 25 Feb 2013 00:05:24 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130224220524.GY8912@reaktio.net>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221122913.GC6647@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > =

> > # modprobe xen-acpi-processor
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.ce=
ntos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output err=
or
> > =

> > Using "modprobe -v" doesn't provide any more information about the prob=
lem.
> > Also there's nothing in dom0 kernel dmesg.
> > =

> > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > Xen 4.2.1.
> > =

> > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable v=
ersion) =

> > with some additional Xen patches backported from later upstream kernels=
. =

> > Any tips how to troubleshoot this? =

> =

> Rebuild the module and add this
> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proc=
essor.c
> index 316df65..5d824a2 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -16,6 +16,7 @@
>   * more details.
>   *
>   */
> +#define DEBUG 1
>  =

>  #include <linux/cpumask.h>
>  #include <linux/cpufreq.h>
> =

> =

> That should help in figuring it out.
> =


This is what I get with DEBUG enabled:

# modprobe -v xen-acpi-processor
insmod /lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-pr=
ocessor.ko
FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.dbg1.el6.x=
86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error

in dom0 kernel dmesg:
xen-acpi-processor: Max ACPI ID: 24

.. and that's all.

Adding more debug options on the kernel cmdline I see this:
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned -5=
 after 67 usecs
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned wi=
th error code -5

And enabling some ACPI debug options:
processor_perflib-0430 [00] processor_get_performa: ACPI-based processor pe=
rformance control unavailable


I added a bunch of more calls to pr_debug() in xen_acpi_processor_init() an=
d it seems:

        /* Do initialization in ACPI core. It is OK to fail here. */
        (void)acpi_processor_preregister_performance(acpi_perf_data);

        for_each_possible_cpu(i) {
                struct acpi_processor_performance *perf;

                perf =3D per_cpu_ptr(acpi_perf_data, i);
                rc =3D acpi_processor_register_performance(perf, i);
                if (rc)
                        goto err_out;
        }

"goto err_out" is the path taken from here..
It seems acpi_processor_register_performance() returns -EIO.

.. which means in acpi_processor_register_performance()

        if (acpi_processor_get_performance_info(pr)) {
                pr->performance =3D NULL;
                mutex_unlock(&performance_mutex);
                return -EIO;
        }


It seems acpi_processor_get_performance_info() returns -ENODEV:

        if (ACPI_FAILURE(status)) {
                ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                                  "ACPI-based processor performance control=
 unavailable\n"));
                return -ENODEV;
        }


Does this ring any bells? =


Thanks,

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 22:47:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 22: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 1U9kL9-0007nY-Ta; Sun, 24 Feb 2013 22:46: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 1U9kL8-0007nT-68
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 22:46:38 +0000
Received: from [85.158.139.211:46758] by server-6.bemta-5.messagelabs.com id
	C8/CB-01489-D489A215; Sun, 24 Feb 2013 22:46:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361745996!19035286!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5382 invoked from network); 24 Feb 2013 22:46:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 22:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; 
   d="scan'208";a="1821449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 22:46: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.297.1; Sun, 24 Feb 2013 22:46:35 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9kL4-0002vn-Vi;
	Sun, 24 Feb 2013 22:46:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9kL4-000863-VK;
	Sun, 24 Feb 2013 22:46:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16436-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 22:46:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16436: 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 16436 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16436/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 16232
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 16232
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 16232
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16232 pass in 16436
 test-i386-i386-xl-qemut-win   3 host-install(3)  broken in 16232 pass in 16436

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 16232 never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Feb 24 22:47:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 24 Feb 2013 22: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 1U9kL9-0007nY-Ta; Sun, 24 Feb 2013 22:46: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 1U9kL8-0007nT-68
	for xen-devel@lists.xensource.com; Sun, 24 Feb 2013 22:46:38 +0000
Received: from [85.158.139.211:46758] by server-6.bemta-5.messagelabs.com id
	C8/CB-01489-D489A215; Sun, 24 Feb 2013 22:46:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361745996!19035286!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5382 invoked from network); 24 Feb 2013 22:46:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Feb 2013 22:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; 
   d="scan'208";a="1821449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Feb 2013 22:46: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.297.1; Sun, 24 Feb 2013 22:46:35 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9kL4-0002vn-Vi;
	Sun, 24 Feb 2013 22:46:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9kL4-000863-VK;
	Sun, 24 Feb 2013 22:46:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16436-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 24 Feb 2013 22:46:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16436: 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 16436 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16436/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 16232
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 16232
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install       fail pass in 16232
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16232 pass in 16436
 test-i386-i386-xl-qemut-win   3 host-install(3)  broken in 16232 pass in 16436

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 16232 never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 00:30:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 00: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 1U9lwY-0001iL-GI; Mon, 25 Feb 2013 00:29: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 1U9lwX-0001iG-3K
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 00:29:21 +0000
Received: from [85.158.143.99:18395] by server-1.bemta-4.messagelabs.com id
	2E/8A-06203-060BA215; Mon, 25 Feb 2013 00:29:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361752159!28353881!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22062 invoked from network); 25 Feb 2013 00:29:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 00:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; 
   d="scan'208";a="1821835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 00:29: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.297.1; Mon, 25 Feb 2013 00:29:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9lwV-0003ZR-Cn;
	Mon, 25 Feb 2013 00:29:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9lwV-0003qh-93;
	Mon, 25 Feb 2013 00:29:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16458-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 00:29:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16458: 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 16458 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16458/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 00:30:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 00: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 1U9lwY-0001iL-GI; Mon, 25 Feb 2013 00:29: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 1U9lwX-0001iG-3K
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 00:29:21 +0000
Received: from [85.158.143.99:18395] by server-1.bemta-4.messagelabs.com id
	2E/8A-06203-060BA215; Mon, 25 Feb 2013 00:29:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361752159!28353881!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22062 invoked from network); 25 Feb 2013 00:29:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 00:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,730,1355097600"; 
   d="scan'208";a="1821835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 00:29: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.297.1; Mon, 25 Feb 2013 00:29:19 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9lwV-0003ZR-Cn;
	Mon, 25 Feb 2013 00:29:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9lwV-0003qh-93;
	Mon, 25 Feb 2013 00:29:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16458-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 00:29:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16458: 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 16458 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16458/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 03:16:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 03:16: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 1U9oXR-0000kh-Ik; Mon, 25 Feb 2013 03:15:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1U9oXO-0000kc-W9
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 03:15:35 +0000
Received: from [85.158.139.83:54253] by server-14.bemta-5.messagelabs.com id
	50/0C-06967-657DA215; Mon, 25 Feb 2013 03:15:34 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361762123!28769168!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg4NzM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4321 invoked from network); 25 Feb 2013 03:15:25 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-182.messagelabs.com with SMTP;
	25 Feb 2013 03:15:25 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2013 19:13:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,731,1355126400"; d="scan'208";a="267038019"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 24 Feb 2013 19:15:20 -0800
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Feb 2013 19:15:17 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Feb 2013 19:15:17 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Mon, 25 Feb 2013 11:15:15 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefan Bader
	<stefan.bader@canonical.com>
Thread-Topic: [Xen-devel] PATastic fun
Thread-Index: AQHOEQxv++rTTiNfAESoDYAIhJawF5iJ6FMg
Date: Mon, 25 Feb 2013 03:15:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
In-Reply-To: <20130222145316.GB8017@phenom.dumpdata.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_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>> Hi Konrad,
>=20
> Hey Stefan,
>>=20
>> here is another one from the hm-what? department:
>=20
> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> he has been tracking a similar one with mcelog.
>>=20
>> Colin discovered that running the attached program with the fork
>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
>> iomem) this triggers the following weird messages:=20
>>=20
>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>> [ 6824.453776] ------------[ cut here ]------------
>> [ 6824.453796] WARNING: at
>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>> mmap-example Tainted: GF=20
>> 3.8.0-6-generic #13-Ubuntu
>> [ 6824.453926] Call Trace:
>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>> [ 6824.454027]  [<ffffffff81056d9f>]
>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>=20
>> I found that this is related to your bandaid patch
>>=20
>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>=20
>>     xen/pat: Disable PAT support for now.
>>=20
>> I just do not understand how this happens. From the trace it seems
>> the fork=20
>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
>> maybe the=20
>> warning is just related to this. So primarily the question is how on
>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>> cleared from the supported=20
>> mask by the patch, so somehow I would think nothing should be able
>> to set it...=20
>> But apparently not so.
>> Not sure it is a big deal since I never saw this in normal operation
>> and it=20
>> seems to be ok when unapping before doing the fork. It is just plain
>> odd.=20
>=20
> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> ranges are swapped or not correct. Jinsong, could you shed some light
> on what you have found so far?
>=20

Yes, Sander once also reported a similar weird warning when start mcelog da=
emon, as attached.

Basically, it occurs when mcelog user daemon start,=20
do_fork
  --> copy_process
    --> dup_mm
      --> dup_mmap
        --> copy_page_range
          --> track_pfn_copy
            --> reserve_pfn_range
              --> line 624: flags !=3D want_flags
It comes from different memory types of page table (_PAGE_CACHE_WB) and mtr=
r (_PAGE_CACHE_UC_MINUS).

However, why it get different memory types from page table and mtrr is stil=
l unclear, reproducing the bug is difficult and unstable.

Thanks,
Jinsong

>>=20
>> -Stefan
>=20
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <stdint.h>
>> #include <stdbool.h>
>> #include <unistd.h>
>> #include <sys/mman.h>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <sys/types.h>
>> #include <sys/wait.h>
>> #include <fcntl.h>
>>=20
>> int main(int argc, char **argv)
>> {
>> 	uint8_t *data;
>> 	int fd;
>> 	unsigned long long offset;
>> 	pid_t pid;
>> 	int status;
>> 	int opt;
>> 	bool opt_fork =3D false;
>>=20
>> 	while ((opt =3D getopt(argc, argv, "f")) !=3D -1) {
>> 		switch (opt) {
>> 		case 'f':
>> 			opt_fork =3D true;
>> 			break;
>> 		}
>> 	}
>>=20
>> 	if (argc <=3D optind) {
>> 		fprintf(stderr, "%s: [-f] address\n", argv[0]);
>> 		fprintf(stderr, "\t-f specifices if we should fork with the
>> 	mmap\n"); 		exit(EXIT_FAILURE); }
>> 	if (sscanf(argv[optind], "%lli", &offset) !=3D 1) {
>> 		fprintf(stderr, "Cannot determine mmap address from %s\n",
>> 	argv[optind]); 		exit(EXIT_FAILURE); }
>>=20
>> 	if ((fd =3D open("/dev/mem", O_RDONLY)) < 0) {
>> 		fprintf(stderr, "Cannot open /dev/mem\n");
>> 		exit(EXIT_FAILURE);
>> 	}
>>=20
>> 	printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095);
>>=20
>> 	if ((data =3D mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd,
>> 		(off_t)offset)) =3D=3D MAP_FAILED) { fprintf(stderr, "Cannot mmap
>> 		0x%llx\n", offset); exit(EXIT_FAILURE);
>> 	}
>>=20
>> 	close(fd);
>>=20
>> 	if (opt_fork) {
>> 		pid =3D fork();
>> 		if (pid =3D=3D 0) {
>> 			/* child */
>> 			_exit(0);
>> 		} else {
>> 			/* parent */
>> 			waitpid(pid, &status, 0);
>> 		}
>> 	}
>>=20
>> 	if (munmap(data, 4096) < 0) {
>> 		fprintf(stderr, "Cannot munmap %p\n", data);
>> 		exit(EXIT_FAILURE);
>> 	}
>> 	exit(EXIT_SUCCESS);
>> }
>>=20
>=20
>=20
>=20
>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


--_002_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Mon, 25 Feb 2013 03:15:12 GMT";
	modification-date="Mon, 25 Feb 2013 03:15:12 GMT"

Received: from fmsmsx105.amr.corp.intel.com (10.19.9.36) by
 SHSMSX151.ccr.corp.intel.com (10.239.6.50) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Mon, 19 Nov 2012 23:40:01 +0800
Received: from fmsmga001.fm.intel.com (10.253.24.23) by
 FMSMSX105-1.fm.intel.com (10.19.9.36) with Microsoft SMTP Server id
 14.1.355.2; Mon, 19 Nov 2012 07:40:00 -0800
Received: from fmsmga101.fm.intel.com ([10.1.193.65])  by
 fmsmga001-1.fm.intel.com with ESMTP; 19 Nov 2012 07:39:58 -0800
Received: from static.121.164.40.188.clients.your-server.de (HELO
 smtp.eikelenboom.it) ([188.40.164.121])  by mga01.intel.com with ESMTP; 19
 Nov 2012 07:39:57 -0800
Received: from 136-70-ftth.on.nl ([88.159.70.136]:54160 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 1TaTV0-0004xB-J9; Mon, 19 Nov 2012
 16:43:02 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Subject: Re: [ 3009.778974] mcelog:16842 map pfn expected mapping type
 write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
Thread-Topic: [ 3009.778974] mcelog:16842 map pfn expected mapping type
 write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
Thread-Index: AQHNxmwd15VBKwan9ka7+XGDG79Vdw==
Date: Mon, 19 Nov 2012 15:39:51 +0000
Message-ID: <368730331.20121119163951@eikelenboom.it>
References: <791265057.20121116134056@eikelenboom.it>
 <20121116160733.GO22320@phenom.dumpdata.com>
 <1422434855.20121116174754@eikelenboom.it>
 <20121116165834.GA18725@phenom.dumpdata.com>
 <DE8DF0795D48FD4CA783C40EC829233538E31B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233538E31B@SHSMSX101.ccr.corp.intel.com>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: FMSMSX105.amr.corp.intel.com
X-MS-Has-Attach: yes
X-Message-Flag: Follow up
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.83,280,1352102400";    d="scan'208";a="25123645"
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: ApcHAM9RqlC8KKR5/2dsb2JhbAA7ColjqAWNdIRtgh4BAQQBViMFCwUGGAkaCwINKh4GDhaHdgrAAow0EIR9A457jFmKa4Jw
Content-Type: multipart/mixed;
	boundary="_002_36873033120121119163951eikelenboomit_"
MIME-Version: 1.0

--_002_36873033120121119163951eikelenboomit_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A861B0F295519341B46F60C1CF40BA3D@intel.com>
Content-Transfer-Encoding: quoted-printable


Saturday, November 17, 2012, 3:14:10 PM, you wrote:

> Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 16, 2012 at 05:47:54PM +0100, Sander Eikelenboom wrote:
>>>=20
>>> Friday, November 16, 2012, 5:07:33 PM, you wrote:
>>>=20
>>>> On Fri, Nov 16, 2012 at 01:40:56PM +0100, Sander Eikelenboom wrote:
>>>>> Hi Konrad,
>>>>>=20
>>>>> Sometime ago i reported this one at boot up:
>>>>>=20
>>>>> [ 3009.778974] mcelog:16842 map pfn expected mapping type
>>>>> write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus [
>>>>> 3009.788570] ------------[ cut here ]------------ [ 3009.798175]
>>>>> WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0xa1/0xb0() [
>>>>> 3009.807966] Hardware name: MS-7640 [ 3009.817677] Modules linked
>>>>> in: [ 3009.827524] Pid: 16842, comm: mcelog Tainted: G        W  =20
>>>>> 3.7.0-rc5-20121116-reverted-persistent-warn-patwarn #1 [
>>>>> 3009.837415] Call Trace: [ 3009.847110]  [<ffffffff810674fa>]
>>>>> warn_slowpath_common+0x7a/0xb0 [ 3009.856857]=20
>>>>> [<ffffffff81067545>] warn_slowpath_null+0x15/0x20 [ 3009.866562]=20
>>>>> [<ffffffff81042041>] untrack_pfn+0xa1/0xb0 [ 3009.876201]=20
>>>>> [<ffffffff8111a59b>] unmap_single_vma+0x86b/0x8e0 [ 3009.885895]=20
>>>>> [<ffffffff81100f16>] ? release_pages+0x196/0x1f0 [ 3009.895488]=20
>>>>> [<ffffffff8111a65c>] unmap_vmas+0x4c/0xa0 [ 3009.905134]=20
>>>>> [<ffffffff8111c8fa>] exit_mmap+0x9a/0x180 [ 3009.914706]=20
>>>>> [<ffffffff81064e72>] mmput+0x52/0xd0 [ 3009.924252]=20
>>>>> [<ffffffff810652b7>] dup_mm+0x3c7/0x510 [ 3009.933839]=20
>>>>> [<ffffffff81065fd5>] copy_process+0xac5/0x14a0 [ 3009.943430]=20
>>>>> [<ffffffff81066af3>] do_fork+0x53/0x360 [ 3009.952843]=20
>>>>> [<ffffffff810b25c7>] ? lock_release+0x117/0x250 [ 3009.962283]=20
>>>>> [<ffffffff817d26c0>] ? _raw_spin_unlock+0x30/0x60 [ 3009.971532]=20
>>>>> [<ffffffff817d3495>] ? sysret_check+0x22/0x5d [ 3009.980820]=20
>>>>> [<ffffffff81017523>] sys_clone+0x23/0x30 [ 3009.990046]=20
>>>>> [<ffffffff817d37f3>] stub_clone+0x13/0x20 [ 3009.999335]=20
>>>>> [<ffffffff817d3469>] ? system_call_fastpath+0x16/0x1b [
>>>>> 3010.008667] ---[ end trace 2d9694c2c0a24da8 ]--- =20
>>>>>=20
>>>>>=20
>>>>> It seems to be due to the "mcelog" userspace tool provided with
>>>>> Debian Squeeze (mcelog 1.0~pre3-3  x86-64 Machine Check Exceptions
>>>>> collector and decoder). I can trigger this warning easily by
>>>>> restarting the mcelog tool with /etc/init.d/mcelog restart =20
>>>>>=20
>>>>> Should that one also function with the xen mcelog driver, or is a
>>>>> newer version required ?=20
>>>=20
>>>> The reason we get is b/c I had to disable the PAT functionality in
>>>> the Linux kernel for Xen. This is b/c it only worked one way -
>>>> meaning you could convert a page from=20
>>>> WriteBack to WriteCombine or WriteBack to Uncached. But you could
>>>> not=20
>>>> do WriteCombine back to WriteBack - due to one of the functions that
>>>> changes the bits was using an "unfiltered" way to identify the bits
>>>> on the=20
>>>> page.
>>>=20
>>>> Anyhow, we had a disaster b/c some of these pages that used to
>>>> WriteBack (WB)=20
>>>> got converted to WriteCombine (WC) and then were returned back as
>>>> such=20
>>>> to the page pool. And if they were re-used by filesystem invariably
>>>> we got=20
>>>> corruptions.
>>>=20
>>>> So until the PAT table lookup thing that Peter H. Anvin suggested
>>>> gets implemented this splat gotta show up :-(
>>>=20
>>> Not a big problem for me, i was just wondering :-)
>>> I'm more interested in the netfront troubles, since it's already rc5.
>>>=20
>>>> Does mcelog still work even with this warning?
>>>=20
>>> Not the daemon:
>>>=20
>>> serveerstertje:~# sh /etc/init.d/mcelog start
>>> Starting Machine Check Exceptions decoder: daemon: Cannot allocate
>>> memory=20
>>>=20
>> Ugh.
>> CC-ing Liu here.
>>=20

> How to reproduce it (sorry I miss the history of this thread)?
> I have a try at Xen side, w/ kernel 3.6.0-rc7+, no problem at my side.

I'm using:
- Xen-unstable, latest changeset=3D26152
- Linux 3.7.0-rc5 kernel latest changeset=3D79e979eae0df58831e85281e3285f63=
663f3cf76
- Dom0 OS =3D Debian Squeeze
- mcelog package: 1.0~pre3-3  x86-64 Machine Check Exceptions collector and=
 decoder)

I don't have particular interest in mcelog, but i just encountered this war=
n on boot.
The warn (see above) is shown when the mcelog daemon (from the debian packa=
ge) tries to start (for example on boot)

I have attached the .config from the used kernel.

If you need any more info, please ask !

--
Sander


> Thanks,
> Jinsong

>>>=20
>>>>>=20
>>>>> --
>>>>> Sander


--_002_36873033120121119163951eikelenboomit_
Content-Type: application/octet-stream; name="dotconfig"
Content-Description: dotconfig
Content-Disposition: attachment; filename="dotconfig"; size=85055;
	creation-date="Mon, 19 Nov 2012 15:40:01 GMT";
	modification-date="Mon, 19 Nov 2012 15:40:01 GMT"
Content-ID: <ED52B5CDF2756347BF4ADD1C99DA70F8@intel.com>
Content-Transfer-Encoding: base64

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4L3g4
Nl82NCAzLjcuMC1yYzUtMjAxMjExMTYtcmV2ZXJ0ZWQtcGVyc2lzdGVudC1idCBLZXJuZWwgQ29u
ZmlndXJhdGlvbgojCkNPTkZJR182NEJJVD15CkNPTkZJR19YODZfNjQ9eQpDT05GSUdfWDg2PXkK
Q09ORklHX0lOU1RSVUNUSU9OX0RFQ09ERVI9eQpDT05GSUdfT1VUUFVUX0ZPUk1BVD0iZWxmNjQt
eDg2LTY0IgpDT05GSUdfQVJDSF9ERUZDT05GSUc9ImFyY2gveDg2L2NvbmZpZ3MveDg2XzY0X2Rl
ZmNvbmZpZyIKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RSQUNFX1NVUFBP
UlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1VPXkKQ09ORklH
X05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdf
R0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0dFTkVSSUNfQlVH
X1JFTEFUSVZFX1BPSU5URVJTPXkKQ09ORklHX0dFTkVSSUNfSFdFSUdIVD15CkNPTkZJR19BUkNI
X01BWV9IQVZFX1BDX0ZEQz15CkNPTkZJR19SV1NFTV9YQ0hHQUREX0FMR09SSVRITT15CkNPTkZJ
R19HRU5FUklDX0NBTElCUkFURV9ERUxBWT15CkNPTkZJR19BUkNIX0hBU19DUFVfUkVMQVg9eQpD
T05GSUdfQVJDSF9IQVNfREVGQVVMVF9JRExFPXkKQ09ORklHX0FSQ0hfSEFTX0NBQ0hFX0xJTkVf
U0laRT15CkNPTkZJR19BUkNIX0hBU19DUFVfQVVUT1BST0JFPXkKQ09ORklHX0hBVkVfU0VUVVBf
UEVSX0NQVV9BUkVBPXkKQ09ORklHX05FRURfUEVSX0NQVV9FTUJFRF9GSVJTVF9DSFVOSz15CkNP
TkZJR19ORUVEX1BFUl9DUFVfUEFHRV9GSVJTVF9DSFVOSz15CkNPTkZJR19BUkNIX0hJQkVSTkFU
SU9OX1BPU1NJQkxFPXkKQ09ORklHX0FSQ0hfU1VTUEVORF9QT1NTSUJMRT15CkNPTkZJR19aT05F
X0RNQTMyPXkKQ09ORklHX0FVRElUX0FSQ0g9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19PUFRJTUla
RURfSU5MSU5JTkc9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19ERUJVR19QQUdFQUxMT0M9eQpDT05G
SUdfWDg2XzY0X1NNUD15CkNPTkZJR19YODZfSFQ9eQpDT05GSUdfQVJDSF9IV0VJR0hUX0NGTEFH
Uz0iLWZjYWxsLXNhdmVkLXJkaSAtZmNhbGwtc2F2ZWQtcnNpIC1mY2FsbC1zYXZlZC1yZHggLWZj
YWxsLXNhdmVkLXJjeCAtZmNhbGwtc2F2ZWQtcjggLWZjYWxsLXNhdmVkLXI5IC1mY2FsbC1zYXZl
ZC1yMTAgLWZjYWxsLXNhdmVkLXIxMSIKQ09ORklHX0FSQ0hfQ1BVX1BST0JFX1JFTEVBU0U9eQpD
T05GSUdfQVJDSF9TVVBQT1JUU19VUFJPQkVTPXkKQ09ORklHX0RFRkNPTkZJR19MSVNUPSIvbGli
L21vZHVsZXMvJFVOQU1FX1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0hBVkVfSVJRX1dPUks9eQpD
T05GSUdfSVJRX1dPUks9eQpDT05GSUdfQlVJTERUSU1FX0VYVEFCTEVfU09SVD15CgojCiMgR2Vu
ZXJhbCBzZXR1cAojCkNPTkZJR19FWFBFUklNRU5UQUw9eQpDT05GSUdfSU5JVF9FTlZfQVJHX0xJ
TUlUPTMyCkNPTkZJR19DUk9TU19DT01QSUxFPSIiCkNPTkZJR19MT0NBTFZFUlNJT049IiIKIyBD
T05GSUdfTE9DQUxWRVJTSU9OX0FVVE8gaXMgbm90IHNldApDT05GSUdfSEFWRV9LRVJORUxfR1pJ
UD15CkNPTkZJR19IQVZFX0tFUk5FTF9CWklQMj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk1BPXkK
Q09ORklHX0hBVkVfS0VSTkVMX1haPXkKQ09ORklHX0hBVkVfS0VSTkVMX0xaTz15CkNPTkZJR19L
RVJORUxfR1pJUD15CiMgQ09ORklHX0tFUk5FTF9CWklQMiBpcyBub3Qgc2V0CiMgQ09ORklHX0tF
Uk5FTF9MWk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX1haIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VSTkVMX0xaTyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSki
CkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lTVklQQ19TWVNDVEw9eQoj
IENPTkZJR19QT1NJWF9NUVVFVUUgaXMgbm90IHNldAojIENPTkZJR19GSEFORExFIGlzIG5vdCBz
ZXQKQ09ORklHX0FVRElUPXkKQ09ORklHX0FVRElUU1lTQ0FMTD15CkNPTkZJR19BVURJVF9XQVRD
SD15CkNPTkZJR19BVURJVF9UUkVFPXkKIyBDT05GSUdfQVVESVRfTE9HSU5VSURfSU1NVVRBQkxF
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfR0VORVJJQ19IQVJESVJRUz15CgojCiMgSVJRIHN1YnN5
c3RlbQojCkNPTkZJR19HRU5FUklDX0hBUkRJUlFTPXkKQ09ORklHX0dFTkVSSUNfSVJRX1BST0JF
PXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdfR0VORVJJQ19QRU5ESU5HX0lSUT15
CkNPTkZJR19JUlFfRE9NQUlOPXkKIyBDT05GSUdfSVJRX0RPTUFJTl9ERUJVRyBpcyBub3Qgc2V0
CkNPTkZJR19JUlFfRk9SQ0VEX1RIUkVBRElORz15CkNPTkZJR19TUEFSU0VfSVJRPXkKQ09ORklH
X0NMT0NLU09VUkNFX1dBVENIRE9HPXkKQ09ORklHX0FSQ0hfQ0xPQ0tTT1VSQ0VfREFUQT15CkNP
TkZJR19HRU5FUklDX1RJTUVfVlNZU0NBTEw9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UUz15
CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tF
VkVOVFNfQlJPQURDQVNUPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfTUlOX0FESlVTVD15
CkNPTkZJR19HRU5FUklDX0NNT1NfVVBEQVRFPXkKCiMKIyBUaW1lcnMgc3Vic3lzdGVtCiMKQ09O
RklHX1RJQ0tfT05FU0hPVD15CkNPTkZJR19OT19IWj15CkNPTkZJR19ISUdIX1JFU19USU1FUlM9
eQoKIwojIENQVS9UYXNrIHRpbWUgYW5kIHN0YXRzIGFjY291bnRpbmcKIwpDT05GSUdfVElDS19D
UFVfQUNDT1VOVElORz15CiMgQ09ORklHX0lSUV9USU1FX0FDQ09VTlRJTkcgaXMgbm90IHNldApD
T05GSUdfQlNEX1BST0NFU1NfQUNDVD15CiMgQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1RfVjMgaXMg
bm90IHNldApDT05GSUdfVEFTS1NUQVRTPXkKQ09ORklHX1RBU0tfREVMQVlfQUNDVD15CkNPTkZJ
R19UQVNLX1hBQ0NUPXkKQ09ORklHX1RBU0tfSU9fQUNDT1VOVElORz15CgojCiMgUkNVIFN1YnN5
c3RlbQojCkNPTkZJR19UUkVFX1BSRUVNUFRfUkNVPXkKQ09ORklHX1BSRUVNUFRfUkNVPXkKIyBD
T05GSUdfUkNVX1VTRVJfUVMgaXMgbm90IHNldApDT05GSUdfUkNVX0ZBTk9VVD02NApDT05GSUdf
UkNVX0ZBTk9VVF9MRUFGPTE2CiMgQ09ORklHX1JDVV9GQU5PVVRfRVhBQ1QgaXMgbm90IHNldApD
T05GSUdfUkNVX0ZBU1RfTk9fSFo9eQojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0
CkNPTkZJR19SQ1VfQk9PU1Q9eQpDT05GSUdfUkNVX0JPT1NUX1BSSU89MQpDT05GSUdfUkNVX0JP
T1NUX0RFTEFZPTUwMApDT05GSUdfSUtDT05GSUc9eQojIENPTkZJR19JS0NPTkZJR19QUk9DIGlz
IG5vdCBzZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTgKQ09ORklHX0hBVkVfVU5TVEFCTEVfU0NI
RURfQ0xPQ0s9eQpDT05GSUdfQ0dST1VQUz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qg
c2V0CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15CiMgQ09ORklHX0NHUk9VUF9ERVZJQ0UgaXMgbm90
IHNldApDT05GSUdfQ1BVU0VUUz15CkNPTkZJR19QUk9DX1BJRF9DUFVTRVQ9eQpDT05GSUdfQ0dS
T1VQX0NQVUFDQ1Q9eQpDT05GSUdfUkVTT1VSQ0VfQ09VTlRFUlM9eQojIENPTkZJR19NRU1DRyBp
cyBub3Qgc2V0CiMgQ09ORklHX0NHUk9VUF9IVUdFVExCIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dS
T1VQX1BFUkYgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JP
VVBfU0NIRUQ9eQojIENPTkZJR19DRlNfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRf
R1JPVVBfU0NIRUQgaXMgbm90IHNldApDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklHX0RFQlVH
X0JMS19DR1JPVVAgaXMgbm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RPUkUgaXMgbm90
IHNldApDT05GSUdfTkFNRVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05GSUdfSVBDX05TPXkK
Q09ORklHX1BJRF9OUz15CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NIRURfQVVUT0dST1VQPXkK
IyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1JFTEFZIGlzIG5v
dCBzZXQKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklHX0lOSVRSQU1GU19TT1VSQ0U9IiIK
Q09ORklHX1JEX0daSVA9eQpDT05GSUdfUkRfQlpJUDI9eQpDT05GSUdfUkRfTFpNQT15CkNPTkZJ
R19SRF9YWj15CkNPTkZJR19SRF9MWk89eQojIENPTkZJR19DQ19PUFRJTUlaRV9GT1JfU0laRSBp
cyBub3Qgc2V0CkNPTkZJR19TWVNDVEw9eQpDT05GSUdfQU5PTl9JTk9ERVM9eQojIENPTkZJR19F
WFBFUlQgaXMgbm90IHNldApDT05GSUdfSEFWRV9VSUQxNj15CkNPTkZJR19VSUQxNj15CiMgQ09O
RklHX1NZU0NUTF9TWVNDQUxMIGlzIG5vdCBzZXQKQ09ORklHX1NZU0NUTF9FWENFUFRJT05fVFJB
Q0U9eQpDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKQ09ORklHX0hPVFBM
VUc9eQpDT05GSUdfUFJJTlRLPXkKQ09ORklHX0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJ
R19QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdf
QkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZE
PXkKQ09ORklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJ
R19BSU89eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZF
TlRTPXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJ
R19QRVJGX0VWRU5UUz15CiMgQ09ORklHX0RFQlVHX1BFUkZfVVNFX1ZNQUxMT0MgaXMgbm90IHNl
dApDT05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdfUENJX1FVSVJLUz15CkNPTkZJR19T
TFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NMQUIg
aXMgbm90IHNldApDT05GSUdfU0xVQj15CiMgQ09ORklHX1BST0ZJTElORyBpcyBub3Qgc2V0CkNP
TkZJR19IQVZFX09QUk9GSUxFPXkKQ09ORklHX09QUk9GSUxFX05NSV9USU1FUj15CiMgQ09ORklH
X0tQUk9CRVMgaXMgbm90IHNldApDT05GSUdfSlVNUF9MQUJFTD15CkNPTkZJR19IQVZFX0VGRklD
SUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklHX0hBVkVfSU9SRU1BUF9QUk9UPXkKQ09ORklH
X0hBVkVfS1BST0JFUz15CkNPTkZJR19IQVZFX0tSRVRQUk9CRVM9eQpDT05GSUdfSEFWRV9PUFRQ
Uk9CRVM9eQpDT05GSUdfSEFWRV9BUkNIX1RSQUNFSE9PSz15CkNPTkZJR19IQVZFX0RNQV9BVFRS
Uz15CkNPTkZJR19VU0VfR0VORVJJQ19TTVBfSEVMUEVSUz15CkNPTkZJR19HRU5FUklDX1NNUF9J
RExFX1RIUkVBRD15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNLX0FDQ0VTU19BUEk9eQpDT05G
SUdfSEFWRV9ETUFfQVBJX0RFQlVHPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJ
R19IQVZFX01JWEVEX0JSRUFLUE9JTlRTX1JFR1M9eQpDT05GSUdfSEFWRV9VU0VSX1JFVFVSTl9O
T1RJRklFUj15CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTX05NST15CkNPTkZJR19IQVZFX1BFUkZf
UkVHUz15CkNPTkZJR19IQVZFX1BFUkZfVVNFUl9TVEFDS19EVU1QPXkKQ09ORklHX0hBVkVfQVJD
SF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfSEFWRV9OTUlfU0FGRV9DTVBYQ0hHPXkKQ09ORklH
X0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15CkNPTkZJR19IQVZFX0NNUFhDSEdfTE9DQUw9eQpD
T05GSUdfSEFWRV9DTVBYQ0hHX0RPVUJMRT15CkNPTkZJR19BUkNIX1dBTlRfQ09NUEFUX0lQQ19Q
QVJTRV9WRVJTSU9OPXkKQ09ORklHX0FSQ0hfV0FOVF9PTERfQ09NUEFUX0lQQz15CkNPTkZJR19H
RU5FUklDX0tFUk5FTF9USFJFQUQ9eQpDT05GSUdfR0VORVJJQ19LRVJORUxfRVhFQ1ZFPXkKQ09O
RklHX0hBVkVfQVJDSF9TRUNDT01QX0ZJTFRFUj15CkNPTkZJR19TRUNDT01QX0ZJTFRFUj15CkNP
TkZJR19IQVZFX1JDVV9VU0VSX1FTPXkKQ09ORklHX0hBVkVfSVJRX1RJTUVfQUNDT1VOVElORz15
CkNPTkZJR19IQVZFX0FSQ0hfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfTU9EVUxFU19V
U0VfRUxGX1JFTEE9eQoKIwojIEdDT1YtYmFzZWQga2VybmVsIHByb2ZpbGluZwojCiMgQ09ORklH
X0dDT1ZfS0VSTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFWRV9HRU5FUklDX0RNQV9DT0hFUkVO
VCBpcyBub3Qgc2V0CkNPTkZJR19TTEFCSU5GTz15CkNPTkZJR19SVF9NVVRFWEVTPXkKQ09ORklH
X0JBU0VfU01BTEw9MApDT05GSUdfTU9EVUxFUz15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9MT0FE
IGlzIG5vdCBzZXQKQ09ORklHX01PRFVMRV9VTkxPQUQ9eQojIENPTkZJR19NT0RVTEVfRk9SQ0Vf
VU5MT0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9EVkVSU0lPTlMgaXMgbm90IHNldAojIENPTkZJ
R19NT0RVTEVfU1JDVkVSU0lPTl9BTEwgaXMgbm90IHNldAojIENPTkZJR19NT0RVTEVfU0lHIGlz
IG5vdCBzZXQKQ09ORklHX1NUT1BfTUFDSElORT15CkNPTkZJR19CTE9DSz15CkNPTkZJR19CTEtf
REVWX0JTRz15CiMgQ09ORklHX0JMS19ERVZfQlNHTElCIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E
RVZfSU5URUdSSVRZPXkKIyBDT05GSUdfQkxLX0RFVl9USFJPVFRMSU5HIGlzIG5vdCBzZXQKCiMK
IyBQYXJ0aXRpb24gVHlwZXMKIwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEPXkKIyBDT05GSUdf
QUNPUk5fUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX09TRl9QQVJUSVRJT049eQpDT05GSUdf
QU1JR0FfUEFSVElUSU9OPXkKIyBDT05GSUdfQVRBUklfUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09O
RklHX01BQ19QQVJUSVRJT049eQpDT05GSUdfTVNET1NfUEFSVElUSU9OPXkKQ09ORklHX0JTRF9E
SVNLTEFCRUw9eQpDT05GSUdfTUlOSVhfU1VCUEFSVElUSU9OPXkKQ09ORklHX1NPTEFSSVNfWDg2
X1BBUlRJVElPTj15CkNPTkZJR19VTklYV0FSRV9ESVNLTEFCRUw9eQojIENPTkZJR19MRE1fUEFS
VElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX1NHSV9QQVJUSVRJT049eQojIENPTkZJR19VTFRSSVhf
UEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX1NVTl9QQVJUSVRJT049eQpDT05GSUdfS0FSTUFf
UEFSVElUSU9OPXkKQ09ORklHX0VGSV9QQVJUSVRJT049eQojIENPTkZJR19TWVNWNjhfUEFSVElU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMT0NLX0NPTVBBVD15CgojCiMgSU8gU2NoZWR1bGVycwoj
CkNPTkZJR19JT1NDSEVEX05PT1A9eQpDT05GSUdfSU9TQ0hFRF9ERUFETElORT15CkNPTkZJR19J
T1NDSEVEX0NGUT15CkNPTkZJR19DRlFfR1JPVVBfSU9TQ0hFRD15CiMgQ09ORklHX0RFRkFVTFRf
REVBRExJTkUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9DRlE9eQojIENPTkZJR19ERUZBVUxU
X05PT1AgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9JT1NDSEVEPSJjZnEiCkNPTkZJR19VTklO
TElORV9TUElOX1VOTE9DSz15CkNPTkZJR19GUkVFWkVSPXkKCiMKIyBQcm9jZXNzb3IgdHlwZSBh
bmQgZmVhdHVyZXMKIwpDT05GSUdfWk9ORV9ETUE9eQpDT05GSUdfU01QPXkKQ09ORklHX1g4Nl9N
UFBBUlNFPXkKQ09ORklHX1g4Nl9FWFRFTkRFRF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9WU01Q
IGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19T
Q0hFRF9PTUlUX0ZSQU1FX1BPSU5URVI9eQpDT05GSUdfUEFSQVZJUlRfR1VFU1Q9eQojIENPTkZJ
R19QQVJBVklSVF9USU1FX0FDQ09VTlRJTkcgaXMgbm90IHNldApDT05GSUdfWEVOPXkKQ09ORklH
X1hFTl9ET00wPXkKQ09ORklHX1hFTl9QUklWSUxFR0VEX0dVRVNUPXkKQ09ORklHX1hFTl9QVkhW
TT15CkNPTkZJR19YRU5fTUFYX0RPTUFJTl9NRU1PUlk9NTAwCkNPTkZJR19YRU5fU0FWRV9SRVNU
T1JFPXkKQ09ORklHX1hFTl9ERUJVR19GUz15CiMgQ09ORklHX0tWTV9HVUVTVCBpcyBub3Qgc2V0
CkNPTkZJR19QQVJBVklSVD15CiMgQ09ORklHX1BBUkFWSVJUX1NQSU5MT0NLUyBpcyBub3Qgc2V0
CkNPTkZJR19QQVJBVklSVF9DTE9DSz15CkNPTkZJR19QQVJBVklSVF9ERUJVRz15CkNPTkZJR19O
T19CT09UTUVNPXkKIyBDT05GSUdfTUVNVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19NSzg9eQojIENP
TkZJR19NUFNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNPUkUyIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUFUT00gaXMgbm90IHNldAojIENPTkZJR19HRU5FUklDX0NQVSBpcyBub3Qgc2V0CkNPTkZJR19Y
ODZfSU5URVJOT0RFX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4Nl9DTVBYQ0hHPXkKQ09ORklHX1g4
Nl9MMV9DQUNIRV9TSElGVD02CkNPTkZJR19YODZfWEFERD15CkNPTkZJR19YODZfV1BfV09SS1Nf
T0s9eQpDT05GSUdfWDg2X0lOVEVMX1VTRVJDT1BZPXkKQ09ORklHX1g4Nl9VU0VfUFBST19DSEVD
S1NVTT15CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdfWDg2
X0NNT1Y9eQpDT05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdfWDg2X0RFQlVH
Q1RMTVNSPXkKQ09ORklHX0NQVV9TVVBfSU5URUw9eQpDT05GSUdfQ1BVX1NVUF9BTUQ9eQpDT05G
SUdfQ1BVX1NVUF9DRU5UQVVSPXkKQ09ORklHX0hQRVRfVElNRVI9eQpDT05GSUdfSFBFVF9FTVVM
QVRFX1JUQz15CkNPTkZJR19ETUk9eQpDT05GSUdfR0FSVF9JT01NVT15CiMgQ09ORklHX0NBTEdB
UllfSU9NTVUgaXMgbm90IHNldApDT05GSUdfU1dJT1RMQj15CkNPTkZJR19JT01NVV9IRUxQRVI9
eQojIENPTkZJR19NQVhTTVAgaXMgbm90IHNldApDT05GSUdfTlJfQ1BVUz04CkNPTkZJR19TQ0hF
RF9TTVQ9eQpDT05GSUdfU0NIRURfTUM9eQojIENPTkZJR19QUkVFTVBUX05PTkUgaXMgbm90IHNl
dAojIENPTkZJR19QUkVFTVBUX1ZPTFVOVEFSWSBpcyBub3Qgc2V0CkNPTkZJR19QUkVFTVBUPXkK
Q09ORklHX1BSRUVNUFRfQ09VTlQ9eQpDT05GSUdfWDg2X0xPQ0FMX0FQSUM9eQpDT05GSUdfWDg2
X0lPX0FQSUM9eQpDT05GSUdfWDg2X1JFUk9VVEVfRk9SX0JST0tFTl9CT09UX0lSUVM9eQpDT05G
SUdfWDg2X01DRT15CkNPTkZJR19YODZfTUNFX0lOVEVMPXkKQ09ORklHX1g4Nl9NQ0VfQU1EPXkK
Q09ORklHX1g4Nl9NQ0VfVEhSRVNIT0xEPXkKIyBDT05GSUdfWDg2X01DRV9JTkpFQ1QgaXMgbm90
IHNldApDT05GSUdfWDg2X1RIRVJNQUxfVkVDVE9SPXkKIyBDT05GSUdfSThLIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUlDUk9DT0RFIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdfWDg2
X0NQVUlEPXkKQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFf
QUREUl9UXzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX05VTUE9eQpDT05G
SUdfQU1EX05VTUE9eQpDT05GSUdfWDg2XzY0X0FDUElfTlVNQT15CkNPTkZJR19OT0RFU19TUEFO
X09USEVSX05PREVTPXkKIyBDT05GSUdfTlVNQV9FTVUgaXMgbm90IHNldApDT05GSUdfTk9ERVNf
U0hJRlQ9OApDT05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkKQ09ORklHX0FSQ0hfU1BBUlNF
TUVNX0RFRkFVTFQ9eQpDT05GSUdfQVJDSF9TRUxFQ1RfTUVNT1JZX01PREVMPXkKQ09ORklHX0FS
Q0hfUFJPQ19LQ09SRV9URVhUPXkKQ09ORklHX0lMTEVHQUxfUE9JTlRFUl9WQUxVRT0weGRlYWQw
MDAwMDAwMDAwMDAKQ09ORklHX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfU1BBUlNFTUVN
X01BTlVBTD15CkNPTkZJR19TUEFSU0VNRU09eQpDT05GSUdfTkVFRF9NVUxUSVBMRV9OT0RFUz15
CkNPTkZJR19IQVZFX01FTU9SWV9QUkVTRU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1FPXkK
Q09ORklHX1NQQVJTRU1FTV9WTUVNTUFQX0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxMT0Nf
TUVNX01BUF9UT0dFVEhFUj15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19IQVZF
X01FTUJMT0NLPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0tfTk9ERV9NQVA9eQpDT05GSUdfQVJDSF9E
SVNDQVJEX01FTUJMT0NLPXkKIyBDT05GSUdfTUVNT1JZX0hPVFBMVUcgaXMgbm90IHNldApDT05G
SUdfUEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9DS19DUFVTPTk5OTk5OQpD
T05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdSQVRJT049eQpDT05GSUdfUEhZU19BRERSX1Rf
NjRCSVQ9eQpDT05GSUdfWk9ORV9ETUFfRkxBRz0xCkNPTkZJR19CT1VOQ0U9eQpDT05GSUdfVklS
VF9UT19CVVM9eQpDT05GSUdfTU1VX05PVElGSUVSPXkKIyBDT05GSUdfS1NNIGlzIG5vdCBzZXQK
Q09ORklHX0RFRkFVTFRfTU1BUF9NSU5fQUREUj00MDk2CkNPTkZJR19BUkNIX1NVUFBPUlRTX01F
TU9SWV9GQUlMVVJFPXkKIyBDT05GSUdfTUVNT1JZX0ZBSUxVUkUgaXMgbm90IHNldApDT05GSUdf
VFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0VfQUxXQVlT
PXkKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0VfTUFEVklTRSBpcyBub3Qgc2V0CkNPTkZJ
R19DUk9TU19NRU1PUllfQVRUQUNIPXkKIyBDT05GSUdfQ0xFQU5DQUNIRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0ZST05UU1dBUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfQ0hFQ0tfQklPU19DT1JSVVBU
SU9OPXkKQ09ORklHX1g4Nl9CT09UUEFSQU1fTUVNT1JZX0NPUlJVUFRJT05fQ0hFQ0s9eQpDT05G
SUdfWDg2X1JFU0VSVkVfTE9XPTY0CkNPTkZJR19NVFJSPXkKQ09ORklHX01UUlJfU0FOSVRJWkVS
PXkKQ09ORklHX01UUlJfU0FOSVRJWkVSX0VOQUJMRV9ERUZBVUxUPTAKQ09ORklHX01UUlJfU0FO
SVRJWkVSX1NQQVJFX1JFR19OUl9ERUZBVUxUPTEKQ09ORklHX1g4Nl9QQVQ9eQpDT05GSUdfQVJD
SF9VU0VTX1BHX1VOQ0FDSEVEPXkKQ09ORklHX0FSQ0hfUkFORE9NPXkKQ09ORklHX1g4Nl9TTUFQ
PXkKIyBDT05GSUdfRUZJIGlzIG5vdCBzZXQKQ09ORklHX1NFQ0NPTVA9eQojIENPTkZJR19DQ19T
VEFDS1BST1RFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMCBpcyBub3Qgc2V0CiMgQ09O
RklHX0haXzI1MCBpcyBub3Qgc2V0CkNPTkZJR19IWl8zMDA9eQojIENPTkZJR19IWl8xMDAwIGlz
IG5vdCBzZXQKQ09ORklHX0haPTMwMApDT05GSUdfU0NIRURfSFJUSUNLPXkKQ09ORklHX0tFWEVD
PXkKQ09ORklHX0NSQVNIX0RVTVA9eQpDT05GSUdfUEhZU0lDQUxfU1RBUlQ9MHgxMDAwMDAwCkNP
TkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAKQ09ORklH
X0hPVFBMVUdfQ1BVPXkKIyBDT05GSUdfQ09NUEFUX1ZEU08gaXMgbm90IHNldAojIENPTkZJR19D
TURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdfQVJDSF9FTkFCTEVfTUVNT1JZX0hPVFBMVUc9
eQpDT05GSUdfVVNFX1BFUkNQVV9OVU1BX05PREVfSUQ9eQoKIwojIFBvd2VyIG1hbmFnZW1lbnQg
YW5kIEFDUEkgb3B0aW9ucwojCiMgQ09ORklHX1NVU1BFTkQgaXMgbm90IHNldApDT05GSUdfSElC
RVJOQVRFX0NBTExCQUNLUz15CiMgQ09ORklHX0hJQkVSTkFUSU9OIGlzIG5vdCBzZXQKQ09ORklH
X1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMgQ09ORklHX1BNX0FVVE9TTEVFUCBp
cyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1JV
TlRJTUUgaXMgbm90IHNldApDT05GSUdfUE09eQpDT05GSUdfUE1fREVCVUc9eQojIENPTkZJR19Q
TV9BRFZBTkNFRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19QTV9TTEVFUF9ERUJVRz15CiMgQ09O
RklHX1BNX1RSQUNFX1JUQyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJPXkKQ09ORklHX0FDUElfUFJP
Q0ZTPXkKIyBDT05GSUdfQUNQSV9QUk9DRlNfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19BQ1BJ
X0VDX0RFQlVHRlMgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX1BST0NfRVZFTlQgaXMgbm90IHNl
dApDT05GSUdfQUNQSV9BQz15CkNPTkZJR19BQ1BJX0JBVFRFUlk9eQpDT05GSUdfQUNQSV9CVVRU
T049eQpDT05GSUdfQUNQSV9WSURFTz15CkNPTkZJR19BQ1BJX0ZBTj15CiMgQ09ORklHX0FDUElf
RE9DSyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19BQ1BJX0hPVFBM
VUdfQ1BVPXkKIyBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUiBpcyBub3Qgc2V0CkNP
TkZJR19BQ1BJX1RIRVJNQUw9eQpDT05GSUdfQUNQSV9OVU1BPXkKIyBDT05GSUdfQUNQSV9DVVNU
T01fRFNEVCBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdf
QUNQSV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9Q
TV9USU1FUj15CkNPTkZJR19BQ1BJX0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfU0JTIGlzIG5v
dCBzZXQKQ09ORklHX0FDUElfSEVEPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fTUVUSE9EIGlzIG5v
dCBzZXQKIyBDT05GSUdfQUNQSV9BUEVJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZJIGlzIG5vdCBz
ZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdfQ1BVX0ZSRVE9eQpDT05GSUdf
Q1BVX0ZSRVFfVEFCTEU9eQojIENPTkZJR19DUFVfRlJFUV9TVEFUIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfUEVSRk9STUFOQ0UgaXMgbm90IHNldApDT05GSUdfQ1BV
X0ZSRVFfREVGQVVMVF9HT1ZfVVNFUlNQQUNFPXkKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9H
T1ZfT05ERU1BTkQgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05T
RVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfR09WX1BFUkZPUk1BTkNFPXkKIyBD
T05GSUdfQ1BVX0ZSRVFfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9H
T1ZfVVNFUlNQQUNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9PTkRFTUFORD15CiMgQ09ORklHX0NQ
VV9GUkVRX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldAoKIwojIHg4NiBDUFUgZnJlcXVlbmN5
IHNjYWxpbmcgZHJpdmVycwojCkNPTkZJR19YODZfUENDX0NQVUZSRVE9eQpDT05GSUdfWDg2X0FD
UElfQ1BVRlJFUT15CkNPTkZJR19YODZfQUNQSV9DUFVGUkVRX0NQQj15CiMgQ09ORklHX1g4Nl9Q
T1dFUk5PV19LOCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk8gaXMg
bm90IHNldAojIENPTkZJR19YODZfUDRfQ0xPQ0tNT0QgaXMgbm90IHNldAoKIwojIHNoYXJlZCBv
cHRpb25zCiMKIyBDT05GSUdfWDg2X1NQRUVEU1RFUF9MSUIgaXMgbm90IHNldApDT05GSUdfQ1BV
X0lETEU9eQpDT05GSUdfQ1BVX0lETEVfR09WX0xBRERFUj15CkNPTkZJR19DUFVfSURMRV9HT1Zf
TUVOVT15CiMgQ09ORklHX0FSQ0hfTkVFRFNfQ1BVX0lETEVfQ09VUExFRCBpcyBub3Qgc2V0CiMg
Q09ORklHX0lOVEVMX0lETEUgaXMgbm90IHNldAoKIwojIE1lbW9yeSBwb3dlciBzYXZpbmdzCiMK
IyBDT05GSUdfSTczMDBfSURMRSBpcyBub3Qgc2V0CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMu
KQojCkNPTkZJR19QQ0k9eQpDT05GSUdfUENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05GSUc9
eQpDT05GSUdfUENJX1hFTj15CkNPTkZJR19QQ0lfRE9NQUlOUz15CkNPTkZJR19QQ0lFUE9SVEJV
Uz15CkNPTkZJR19IT1RQTFVHX1BDSV9QQ0lFPXkKQ09ORklHX1BDSUVBRVI9eQpDT05GSUdfUENJ
RV9FQ1JDPXkKQ09ORklHX1BDSUVBRVJfSU5KRUNUPXkKQ09ORklHX1BDSUVBU1BNPXkKQ09ORklH
X1BDSUVBU1BNX0RFQlVHPXkKQ09ORklHX1BDSUVBU1BNX0RFRkFVTFQ9eQojIENPTkZJR19QQ0lF
QVNQTV9QT1dFUlNBVkUgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQVNQTV9QRVJGT1JNQU5DRSBp
cyBub3Qgc2V0CkNPTkZJR19BUkNIX1NVUFBPUlRTX01TST15CkNPTkZJR19QQ0lfTVNJPXkKQ09O
RklHX1BDSV9ERUJVRz15CkNPTkZJR19QQ0lfUkVBTExPQ19FTkFCTEVfQVVUTz15CiMgQ09ORklH
X1BDSV9TVFVCIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9QQ0lERVZfRlJPTlRFTkQ9eQpDT05GSUdf
SFRfSVJRPXkKQ09ORklHX1BDSV9BVFM9eQpDT05GSUdfUENJX0lPVj15CkNPTkZJR19QQ0lfUFJJ
PXkKQ09ORklHX1BDSV9QQVNJRD15CkNPTkZJR19QQ0lfSU9BUElDPXkKQ09ORklHX1BDSV9MQUJF
TD15CkNPTkZJR19JU0FfRE1BX0FQST15CkNPTkZJR19BTURfTkI9eQpDT05GSUdfUENDQVJEPXkK
IyBDT05GSUdfUENNQ0lBIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FSREJVUyBpcyBub3Qgc2V0Cgoj
CiMgUEMtY2FyZCBicmlkZ2VzCiMKIyBDT05GSUdfWUVOVEEgaXMgbm90IHNldApDT05GSUdfSE9U
UExVR19QQ0k9eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQST15CkNPTkZJR19IT1RQTFVHX1BDSV9B
Q1BJX0lCTT15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJPXkKQ09ORklHX0hPVFBMVUdfUENJX0NQ
Q0lfWlQ1NTUwPXkKQ09ORklHX0hPVFBMVUdfUENJX0NQQ0lfR0VORVJJQz15CkNPTkZJR19IT1RQ
TFVHX1BDSV9TSFBDPXkKIyBDT05GSUdfUkFQSURJTyBpcyBub3Qgc2V0CgojCiMgRXhlY3V0YWJs
ZSBmaWxlIGZvcm1hdHMgLyBFbXVsYXRpb25zCiMKQ09ORklHX0JJTkZNVF9FTEY9eQpDT05GSUdf
Q09NUEFUX0JJTkZNVF9FTEY9eQpDT05GSUdfQVJDSF9CSU5GTVRfRUxGX1JBTkRPTUlaRV9QSUU9
eQpDT05GSUdfQ09SRV9EVU1QX0RFRkFVTFRfRUxGX0hFQURFUlM9eQojIENPTkZJR19IQVZFX0FP
VVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9eQpDT05GSUdfQ09SRURVTVA9eQpDT05G
SUdfSUEzMl9FTVVMQVRJT049eQojIENPTkZJR19JQTMyX0FPVVQgaXMgbm90IHNldAojIENPTkZJ
R19YODZfWDMyIGlzIG5vdCBzZXQKQ09ORklHX0NPTVBBVD15CkNPTkZJR19DT01QQVRfRk9SX1U2
NF9BTElHTk1FTlQ9eQpDT05GSUdfU1lTVklQQ19DT01QQVQ9eQpDT05GSUdfSEFWRV9URVhUX1BP
S0VfU01QPXkKQ09ORklHX1g4Nl9ERVZfRE1BX09QUz15CkNPTkZJR19ORVQ9eQoKIwojIE5ldHdv
cmtpbmcgb3B0aW9ucwojCkNPTkZJR19QQUNLRVQ9eQojIENPTkZJR19QQUNLRVRfRElBRyBpcyBu
b3Qgc2V0CkNPTkZJR19VTklYPXkKIyBDT05GSUdfVU5JWF9ESUFHIGlzIG5vdCBzZXQKIyBDT05G
SUdfWEZSTV9VU0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0tFWSBpcyBub3Qgc2V0CkNPTkZJ
R19JTkVUPXkKQ09ORklHX0lQX01VTFRJQ0FTVD15CkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9
eQojIENPTkZJR19JUF9GSUJfVFJJRV9TVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19JUF9NVUxUSVBM
RV9UQUJMRVM9eQpDT05GSUdfSVBfUk9VVEVfTVVMVElQQVRIPXkKQ09ORklHX0lQX1JPVVRFX1ZF
UkJPU0U9eQpDT05GSUdfSVBfUk9VVEVfQ0xBU1NJRD15CkNPTkZJR19JUF9QTlA9eQpDT05GSUdf
SVBfUE5QX0RIQ1A9eQpDT05GSUdfSVBfUE5QX0JPT1RQPXkKQ09ORklHX0lQX1BOUF9SQVJQPXkK
IyBDT05GSUdfTkVUX0lQSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfSVBHUkVfREVNVVggaXMg
bm90IHNldApDT05GSUdfSVBfTVJPVVRFPXkKIyBDT05GSUdfSVBfTVJPVVRFX01VTFRJUExFX1RB
QkxFUyBpcyBub3Qgc2V0CkNPTkZJR19JUF9QSU1TTV9WMT15CkNPTkZJR19JUF9QSU1TTV9WMj15
CiMgQ09ORklHX0FSUEQgaXMgbm90IHNldApDT05GSUdfU1lOX0NPT0tJRVM9eQojIENPTkZJR19J
TkVUX0FIIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9FU1AgaXMgbm90IHNldAojIENPTkZJR19J
TkVUX0lQQ09NUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9UVU5ORUwgaXMgbm90IHNl
dAojIENPTkZJR19JTkVUX1RVTk5FTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9NT0RF
X1RSQU5TUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9NT0RFX1RVTk5FTCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9NT0RFX0JFRVQgaXMgbm90IHNldApDT05GSUdfSU5F
VF9MUk89eQojIENPTkZJR19JTkVUX0RJQUcgaXMgbm90IHNldApDT05GSUdfVENQX0NPTkdfQURW
QU5DRUQ9eQojIENPTkZJR19UQ1BfQ09OR19CSUMgaXMgbm90IHNldApDT05GSUdfVENQX0NPTkdf
Q1VCSUM9eQojIENPTkZJR19UQ1BfQ09OR19XRVNUV09PRCBpcyBub3Qgc2V0CiMgQ09ORklHX1RD
UF9DT05HX0hUQ1AgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19IU1RDUCBpcyBub3Qgc2V0
CiMgQ09ORklHX1RDUF9DT05HX0hZQkxBIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfVkVH
QVMgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19TQ0FMQUJMRSBpcyBub3Qgc2V0CiMgQ09O
RklHX1RDUF9DT05HX0xQIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfVkVOTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1RDUF9DT05HX1lFQUggaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19J
TExJTk9JUyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NVQklDPXkKIyBDT05GSUdfREVGQVVM
VF9SRU5PIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfVENQX0NPTkc9ImN1YmljIgojIENPTkZJ
R19UQ1BfTUQ1U0lHIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNiBpcyBub3Qgc2V0CkNPTkZJR19O
RVRXT1JLX1NFQ01BUks9eQojIENPTkZJR19ORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgaXMgbm90
IHNldApDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5vdCBz
ZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNFRD15CkNPTkZJR19CUklER0VfTkVURklMVEVSPXkK
CiMKIyBDb3JlIE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKQ09ORklHX05FVEZJTFRFUl9ORVRM
SU5LPXkKQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX0FDQ1Q9eQpDT05GSUdfTkVURklMVEVSX05F
VExJTktfUVVFVUU9eQpDT05GSUdfTkVURklMVEVSX05FVExJTktfTE9HPXkKQ09ORklHX05GX0NP
Tk5UUkFDSz15CkNPTkZJR19ORl9DT05OVFJBQ0tfTUFSSz15CkNPTkZJR19ORl9DT05OVFJBQ0tf
U0VDTUFSSz15CkNPTkZJR19ORl9DT05OVFJBQ0tfUFJPQ0ZTPXkKQ09ORklHX05GX0NPTk5UUkFD
S19FVkVOVFM9eQojIENPTkZJR19ORl9DT05OVFJBQ0tfVElNRU9VVCBpcyBub3Qgc2V0CkNPTkZJ
R19ORl9DT05OVFJBQ0tfVElNRVNUQU1QPXkKIyBDT05GSUdfTkZfQ1RfUFJPVE9fRENDUCBpcyBu
b3Qgc2V0CkNPTkZJR19ORl9DVF9QUk9UT19HUkU9eQojIENPTkZJR19ORl9DVF9QUk9UT19TQ1RQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ1RfUFJPVE9fVURQTElURSBpcyBub3Qgc2V0CiMgQ09O
RklHX05GX0NPTk5UUkFDS19BTUFOREEgaXMgbm90IHNldApDT05GSUdfTkZfQ09OTlRSQUNLX0ZU
UD15CkNPTkZJR19ORl9DT05OVFJBQ0tfSDMyMz15CkNPTkZJR19ORl9DT05OVFJBQ0tfSVJDPXkK
IyBDT05GSUdfTkZfQ09OTlRSQUNLX05FVEJJT1NfTlMgaXMgbm90IHNldAojIENPTkZJR19ORl9D
T05OVFJBQ0tfU05NUCBpcyBub3Qgc2V0CkNPTkZJR19ORl9DT05OVFJBQ0tfUFBUUD15CiMgQ09O
RklHX05GX0NPTk5UUkFDS19TQU5FIGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5UUkFDS19TSVA9
eQojIENPTkZJR19ORl9DT05OVFJBQ0tfVEZUUCBpcyBub3Qgc2V0CkNPTkZJR19ORl9DVF9ORVRM
SU5LPXkKIyBDT05GSUdfTkZfQ1RfTkVUTElOS19USU1FT1VUIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkVURklMVEVSX05FVExJTktfUVVFVUVfQ1QgaXMgbm90IHNldApDT05GSUdfTkZfTkFUPXkKQ09O
RklHX05GX05BVF9ORUVERUQ9eQojIENPTkZJR19ORl9OQVRfQU1BTkRBIGlzIG5vdCBzZXQKQ09O
RklHX05GX05BVF9GVFA9eQpDT05GSUdfTkZfTkFUX0lSQz15CkNPTkZJR19ORl9OQVRfU0lQPXkK
IyBDT05GSUdfTkZfTkFUX1RGVFAgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfVFBST1hZ
IGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVEFCTEVTPXkKCiMKIyBYdGFibGVzIGNvbWJp
bmVkIG1vZHVsZXMKIwpDT05GSUdfTkVURklMVEVSX1hUX01BUks9eQpDT05GSUdfTkVURklMVEVS
X1hUX0NPTk5NQVJLPXkKIyBDT05GSUdfTkVURklMVEVSX1hUX1NFVCBpcyBub3Qgc2V0CgojCiMg
WHRhYmxlcyB0YXJnZXRzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQVVESVQ9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9DSEVDS1NVTT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX0NMQVNTSUZZPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ09OTk1BUks9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9DT05OU0VDTUFSSz15CiMgQ09ORklHX05FVEZJTFRFUl9Y
VF9UQVJHRVRfQ1QgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9EU0NQPXkK
Q09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSEw9eQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX0hNQVJLIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSURMRVRJTUVS
PXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTE9HPXkKQ09ORklHX05FVEZJTFRFUl9YVF9U
QVJHRVRfTUFSSz15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05FVE1BUD15CkNPTkZJR19O
RVRGSUxURVJfWFRfVEFSR0VUX05GTE9HPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTkZR
VUVVRT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1JBVEVFU1Q9eQpDT05GSUdfTkVURklM
VEVSX1hUX1RBUkdFVF9SRURJUkVDVD15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RFRT15
CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfVFJBQ0UgaXMgbm90IHNldApDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9TRUNNQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfVENQ
TVNTPXkKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUCBpcyBub3Qgc2V0
CgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9BRERSVFlQ
RT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0xVU1RFUj15CkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfQ09NTUVOVD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkJZVEVTPXkK
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hU
X01BVENIX0NPTk5NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJBQ0s9eQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0NQVT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf
RENDUD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9eQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX0RTQ1A9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VDTj15CkNPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfRVNQPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9IQVNI
TElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hFTFBFUj15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfSEw9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0U9eQpDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0lQVlM9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xF
TkdUSD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQ9eQpDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX01BQz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz15CkNPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9O
RkFDQ1Q9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09TRj15CkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfT1dORVI9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BIWVNERVY9eQpDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEU9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X1FVT1RBPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUPXkKQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9SRUFMTT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5UPXkK
IyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFAgaXMgbm90IHNldApDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX1NUQVRFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVEFUSVNUSUM9
eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUUklORz15CkNPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfVENQTVNTPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9USU1FPXkKQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9VMzI9eQpDT05GSUdfSVBfU0VUPXkKQ09ORklHX0lQX1NFVF9NQVg9
MjU2CkNPTkZJR19JUF9TRVRfQklUTUFQX0lQPXkKQ09ORklHX0lQX1NFVF9CSVRNQVBfSVBNQUM9
eQpDT05GSUdfSVBfU0VUX0JJVE1BUF9QT1JUPXkKQ09ORklHX0lQX1NFVF9IQVNIX0lQPXkKQ09O
RklHX0lQX1NFVF9IQVNIX0lQUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9JUFBPUlRJUD15CkNP
TkZJR19JUF9TRVRfSEFTSF9JUFBPUlRORVQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUPXkKQ09O
RklHX0lQX1NFVF9IQVNIX05FVFBPUlQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUSUZBQ0U9eQpD
T05GSUdfSVBfU0VUX0xJU1RfU0VUPXkKQ09ORklHX0lQX1ZTPXkKIyBDT05GSUdfSVBfVlNfREVC
VUcgaXMgbm90IHNldApDT05GSUdfSVBfVlNfVEFCX0JJVFM9MTIKCiMKIyBJUFZTIHRyYW5zcG9y
dCBwcm90b2NvbCBsb2FkIGJhbGFuY2luZyBzdXBwb3J0CiMKIyBDT05GSUdfSVBfVlNfUFJPVE9f
VENQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fVURQIGlzIG5vdCBzZXQKIyBDT05G
SUdfSVBfVlNfUFJPVE9fQUhfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fRVNQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fQUggaXMgbm90IHNldAojIENPTkZJR19J
UF9WU19QUk9UT19TQ1RQIGlzIG5vdCBzZXQKCiMKIyBJUFZTIHNjaGVkdWxlcgojCiMgQ09ORklH
X0lQX1ZTX1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfV1JSIGlzIG5vdCBzZXQKIyBDT05G
SUdfSVBfVlNfTEMgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19XTEMgaXMgbm90IHNldAojIENP
TkZJR19JUF9WU19MQkxDIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTEJMQ1IgaXMgbm90IHNl
dAojIENPTkZJR19JUF9WU19ESCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1ZTX1NIIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSVBfVlNfU0VEIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTlEgaXMgbm90
IHNldAoKIwojIElQVlMgU0ggc2NoZWR1bGVyCiMKQ09ORklHX0lQX1ZTX1NIX1RBQl9CSVRTPTgK
CiMKIyBJUFZTIGFwcGxpY2F0aW9uIGhlbHBlcgojCkNPTkZJR19JUF9WU19ORkNUPXkKCiMKIyBJ
UDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05G
SUdfTkZfQ09OTlRSQUNLX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkK
IyBDT05GSUdfSVBfTkZfUVVFVUUgaXMgbm90IHNldApDT05GSUdfSVBfTkZfSVBUQUJMRVM9eQpD
T05GSUdfSVBfTkZfTUFUQ0hfQUg9eQpDT05GSUdfSVBfTkZfTUFUQ0hfRUNOPXkKIyBDT05GSUdf
SVBfTkZfTUFUQ0hfUlBGSUxURVIgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTUFUQ0hfVFRMPXkK
Q09ORklHX0lQX05GX0ZJTFRFUj15CkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPXkKQ09ORklH
X0lQX05GX1RBUkdFVF9VTE9HPXkKQ09ORklHX05GX05BVF9JUFY0PXkKQ09ORklHX0lQX05GX1RB
UkdFVF9NQVNRVUVSQURFPXkKQ09ORklHX0lQX05GX1RBUkdFVF9ORVRNQVA9eQpDT05GSUdfSVBf
TkZfVEFSR0VUX1JFRElSRUNUPXkKQ09ORklHX05GX05BVF9QUk9UT19HUkU9eQpDT05GSUdfTkZf
TkFUX1BQVFA9eQpDT05GSUdfTkZfTkFUX0gzMjM9eQpDT05GSUdfSVBfTkZfTUFOR0xFPXkKIyBD
T05GSUdfSVBfTkZfVEFSR0VUX0NMVVNURVJJUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1RB
UkdFVF9FQ04gaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9UQVJHRVRfVFRMIGlzIG5vdCBzZXQK
Q09ORklHX0lQX05GX1JBVz15CiMgQ09ORklHX0lQX05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0CkNP
TkZJR19CUklER0VfTkZfRUJUQUJMRVM9eQojIENPTkZJR19CUklER0VfRUJUX0JST1VURSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfVF9GSUxURVIgaXMgbm90IHNldAojIENPTkZJR19C
UklER0VfRUJUX1RfTkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF84MDJfMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfQU1PTkcgaXMgbm90IHNldAojIENPTkZJR19CUklE
R0VfRUJUX0FSUCBpcyBub3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfSVAgaXMgbm90IHNldAoj
IENPTkZJR19CUklER0VfRUJUX0xJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9N
QVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9QS1RUWVBFIGlzIG5vdCBzZXQKIyBD
T05GSUdfQlJJREdFX0VCVF9TVFAgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1ZMQU4g
aXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX0FSUFJFUExZIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlJJREdFX0VCVF9ETkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9NQVJLX1Qg
aXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1JFRElSRUNUIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlJJREdFX0VCVF9TTkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9MT0cgaXMg
bm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1VMT0cgaXMgbm90IHNldAojIENPTkZJR19CUklE
R0VfRUJUX05GTE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfRENDUCBpcyBub3Qgc2V0CiMgQ09O
RklHX0lQX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19SRFMgaXMgbm90IHNldAojIENPTkZJR19U
SVBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTDJUUCBpcyBu
b3Qgc2V0CkNPTkZJR19TVFA9eQpDT05GSUdfQlJJREdFPXkKQ09ORklHX0JSSURHRV9JR01QX1NO
T09QSU5HPXkKIyBDT05GSUdfTkVUX0RTQSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZMQU5fODAyMVEg
aXMgbm90IHNldAojIENPTkZJR19ERUNORVQgaXMgbm90IHNldApDT05GSUdfTExDPXkKIyBDT05G
SUdfTExDMiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxL
IGlzIG5vdCBzZXQKIyBDT05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qg
c2V0CiMgQ09ORklHX1dBTl9ST1VURVIgaXMgbm90IHNldAojIENPTkZJR19QSE9ORVQgaXMgbm90
IHNldAojIENPTkZJR19JRUVFODAyMTU0IGlzIG5vdCBzZXQKQ09ORklHX05FVF9TQ0hFRD15Cgoj
CiMgUXVldWVpbmcvU2NoZWR1bGluZwojCiMgQ09ORklHX05FVF9TQ0hfQ0JRIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1NDSF9IVEIgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0hGU0MgaXMg
bm90IHNldAojIENPTkZJR19ORVRfU0NIX1BSSU8gaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NI
X01VTFRJUSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUkVEIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX1NDSF9TRkIgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1NGUSBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9TQ0hfVEVRTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfVEJGIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9HUkVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ND
SF9EU01BUksgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX05FVEVNIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1NDSF9EUlIgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX01RUFJJTyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfQ0hPS0UgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NI
X1FGUSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfQ09ERUwgaXMgbm90IHNldAojIENPTkZJ
R19ORVRfU0NIX0ZRX0NPREVMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9JTkdSRVNTIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9QTFVHIGlzIG5vdCBzZXQKCiMKIyBDbGFzc2lmaWNh
dGlvbgojCkNPTkZJR19ORVRfQ0xTPXkKIyBDT05GSUdfTkVUX0NMU19CQVNJQyBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9DTFNfVENJTkRFWCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfUk9V
VEU0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19GVyBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VF9DTFNfVTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19SU1ZQIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX0NMU19SU1ZQNiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfRkxPVyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfQ0dST1VQIGlzIG5vdCBzZXQKQ09ORklHX05FVF9FTUFU
Q0g9eQpDT05GSUdfTkVUX0VNQVRDSF9TVEFDSz0zMgojIENPTkZJR19ORVRfRU1BVENIX0NNUCBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfTkJZVEUgaXMgbm90IHNldAojIENPTkZJR19O
RVRfRU1BVENIX1UzMiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfTUVUQSBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfVEVYVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9FTUFU
Q0hfSVBTRVQgaXMgbm90IHNldApDT05GSUdfTkVUX0NMU19BQ1Q9eQojIENPTkZJR19ORVRfQUNU
X1BPTElDRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfR0FDVCBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVF9BQ1RfTUlSUkVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0FDVF9JUFQgaXMgbm90
IHNldAojIENPTkZJR19ORVRfQUNUX05BVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfUEVE
SVQgaXMgbm90IHNldAojIENPTkZJR19ORVRfQUNUX1NJTVAgaXMgbm90IHNldAojIENPTkZJR19O
RVRfQUNUX1NLQkVESVQgaXMgbm90IHNldAojIENPTkZJR19ORVRfQUNUX0NTVU0gaXMgbm90IHNl
dApDT05GSUdfTkVUX1NDSF9GSUZPPXkKIyBDT05GSUdfRENCIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkFUTUFOX0FEViBpcyBub3Qgc2V0CiMgQ09ORklHX09QRU5WU1dJVENIIGlzIG5vdCBzZXQKQ09O
RklHX1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKIyBDT05GSUdfTkVUUFJJ
T19DR1JPVVAgaXMgbm90IHNldApDT05GSUdfQlFMPXkKIyBDT05GSUdfQlBGX0pJVCBpcyBub3Qg
c2V0CgojCiMgTmV0d29yayB0ZXN0aW5nCiMKIyBDT05GSUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0
CiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOIGlzIG5vdCBzZXQKIyBD
T05GSUdfSVJEQSBpcyBub3Qgc2V0CkNPTkZJR19CVD15CkNPTkZJR19CVF9SRkNPTU09eQpDT05G
SUdfQlRfUkZDT01NX1RUWT15CkNPTkZJR19CVF9CTkVQPXkKQ09ORklHX0JUX0JORVBfTUNfRklM
VEVSPXkKQ09ORklHX0JUX0JORVBfUFJPVE9fRklMVEVSPXkKQ09ORklHX0JUX0hJRFA9eQoKIwoj
IEJsdWV0b290aCBkZXZpY2UgZHJpdmVycwojCkNPTkZJR19CVF9IQ0lCVFVTQj15CkNPTkZJR19C
VF9IQ0lVQVJUPXkKQ09ORklHX0JUX0hDSVVBUlRfSDQ9eQpDT05GSUdfQlRfSENJVUFSVF9CQ1NQ
PXkKQ09ORklHX0JUX0hDSVVBUlRfQVRIM0s9eQpDT05GSUdfQlRfSENJVUFSVF9MTD15CkNPTkZJ
R19CVF9IQ0lVQVJUXzNXSVJFPXkKQ09ORklHX0JUX0hDSUJDTTIwM1g9eQpDT05GSUdfQlRfSENJ
QlBBMTBYPXkKQ09ORklHX0JUX0hDSUJGVVNCPXkKQ09ORklHX0JUX0hDSVZIQ0k9eQpDT05GSUdf
QlRfTVJWTD15CkNPTkZJR19CVF9BVEgzSz15CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQK
Q09ORklHX0ZJQl9SVUxFUz15CkNPTkZJR19XSVJFTEVTUz15CiMgQ09ORklHX0NGRzgwMjExIGlz
IG5vdCBzZXQKIyBDT05GSUdfTElCODAyMTEgaXMgbm90IHNldAoKIwojIENGRzgwMjExIG5lZWRz
IHRvIGJlIGVuYWJsZWQgZm9yIE1BQzgwMjExCiMKIyBDT05GSUdfV0lNQVggaXMgbm90IHNldAoj
IENPTkZJR19SRktJTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENP
TkZJR19DQUlGIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAojIENPTkZJ
R19ORkMgaXMgbm90IHNldApDT05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVy
cwojCgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BB
VEg9Ii9zYmluL2hvdHBsdWciCiMgQ09ORklHX0RFVlRNUEZTIGlzIG5vdCBzZXQKQ09ORklHX1NU
QU5EQUxPTkU9eQpDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlMRD15CkNPTkZJR19GV19MT0FE
RVI9eQpDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMPXkKQ09ORklHX0VYVFJBX0ZJUk1XQVJFPSIi
CiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19ERVZSRVM9eQpD
T05GSUdfU1lTX0hZUEVSVklTT1I9eQojIENPTkZJR19HRU5FUklDX0NQVV9ERVZJQ0VTIGlzIG5v
dCBzZXQKQ09ORklHX0RNQV9TSEFSRURfQlVGRkVSPXkKCiMKIyBCdXMgZGV2aWNlcwojCiMgQ09O
RklHX09NQVBfT0NQMlNDUCBpcyBub3Qgc2V0CkNPTkZJR19DT05ORUNUT1I9eQpDT05GSUdfUFJP
Q19FVkVOVFM9eQojIENPTkZJR19NVEQgaXMgbm90IHNldAojIENPTkZJR19QQVJQT1JUIGlzIG5v
dCBzZXQKQ09ORklHX1BOUD15CkNPTkZJR19QTlBfREVCVUdfTUVTU0FHRVM9eQoKIwojIFByb3Rv
Y29scwojCkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JMS19ERVY9eQojIENPTkZJR19CTEtfREVW
X0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9QQ0lFU1NEX01USVAzMlhYIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19DUFFfQ0lTU19E
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkxLX0RFVl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5v
dCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5U
PTgKIyBDT05GSUdfQkxLX0RFVl9DUllQVE9MT09QIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9EUkJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJ
R19CTEtfREVWX05WTUUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NYOCBpcyBub3Qgc2V0
CkNPTkZJR19CTEtfREVWX1JBTT15CkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdf
QkxLX0RFVl9SQU1fU0laRT0xNjM4NAojIENPTkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CiMg
Q09ORklHX0NEUk9NX1BLVENEVkQgaXMgbm90IHNldAojIENPTkZJR19BVEFfT1ZFUl9FVEggaXMg
bm90IHNldApDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxLREVWX0JB
Q0tFTkQ9eQojIENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9S
QkQgaXMgbm90IHNldAoKIwojIE1pc2MgZGV2aWNlcwojCiMgQ09ORklHX1NFTlNPUlNfTElTM0xW
MDJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19J
Qk1fQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
VEVMX01JRF9QVEkgaXMgbm90IHNldAojIENPTkZJR19TR0lfSU9DNCBpcyBub3Qgc2V0CiMgQ09O
RklHX1RJRk1fQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lDUzkzMlM0MDEgaXMgbm90IHNldAoj
IENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldAojIENPTkZJR19IUF9JTE8gaXMg
bm90IHNldAojIENPTkZJR19BUERTOTgwMkFMUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDAz
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X1RTTDI1NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc4MCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BUERTOTkw
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90IHNldAojIENPTkZJR19EUzE2ODIg
aXMgbm90IHNldAojIENPTkZJR19WTVdBUkVfQkFMTE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0JN
UDA4NV9JMkMgaXMgbm90IHNldAojIENPTkZJR19QQ0hfUEhVQiBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9TV0lUQ0hfRlNBOTQ4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0MyUE9SVCBpcyBub3Qgc2V0
CgojCiMgRUVQUk9NIHN1cHBvcnQKIwojIENPTkZJR19FRVBST01fQVQyNCBpcyBub3Qgc2V0CiMg
Q09ORklHX0VFUFJPTV9MRUdBQ1kgaXMgbm90IHNldAojIENPTkZJR19FRVBST01fTUFYNjg3NSBp
cyBub3Qgc2V0CiMgQ09ORklHX0VFUFJPTV85M0NYNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NCNzEw
X0NPUkUgaXMgbm90IHNldAoKIwojIFRleGFzIEluc3RydW1lbnRzIHNoYXJlZCB0cmFuc3BvcnQg
bGluZSBkaXNjaXBsaW5lCiMKIyBDT05GSUdfU0VOU09SU19MSVMzX0kyQyBpcyBub3Qgc2V0Cgoj
CiMgQWx0ZXJhIEZQR0EgZmlybXdhcmUgZG93bmxvYWQgbW9kdWxlCiMKQ09ORklHX0FMVEVSQV9T
VEFQTD15CiMgQ09ORklHX0lOVEVMX01FSSBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0lERT15CiMg
Q09ORklHX0lERSBpcyBub3Qgc2V0CgojCiMgU0NTSSBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19T
Q1NJX01PRD15CiMgQ09ORklHX1JBSURfQVRUUlMgaXMgbm90IHNldApDT05GSUdfU0NTST15CkNP
TkZJR19TQ1NJX0RNQT15CiMgQ09ORklHX1NDU0lfVEdUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT
SV9ORVRMSU5LIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfUFJPQ19GUz15CgojCiMgU0NTSSBzdXBw
b3J0IHR5cGUgKGRpc2ssIHRhcGUsIENELVJPTSkKIwpDT05GSUdfQkxLX0RFVl9TRD15CiMgQ09O
RklHX0NIUl9ERVZfU1QgaXMgbm90IHNldAojIENPTkZJR19DSFJfREVWX09TU1QgaXMgbm90IHNl
dApDT05GSUdfQkxLX0RFVl9TUj15CkNPTkZJR19CTEtfREVWX1NSX1ZFTkRPUj15CkNPTkZJR19D
SFJfREVWX1NHPXkKIyBDT05GSUdfQ0hSX0RFVl9TQ0ggaXMgbm90IHNldAojIENPTkZJR19TQ1NJ
X01VTFRJX0xVTiBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0NPTlNUQU5UUz15CiMgQ09ORklHX1ND
U0lfTE9HR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0NBTl9BU1lOQyBpcyBub3Qgc2V0
CgojCiMgU0NTSSBUcmFuc3BvcnRzCiMKQ09ORklHX1NDU0lfU1BJX0FUVFJTPXkKIyBDT05GSUdf
U0NTSV9GQ19BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSVNDU0lfQVRUUlMgaXMgbm90
IHNldAojIENPTkZJR19TQ1NJX1NBU19BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0FT
X0xJQlNBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU1JQX0FUVFJTIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0NTSV9MT1dMRVZFTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREggaXMgbm90IHNl
dAojIENPTkZJR19TQ1NJX09TRF9JTklUSUFUT1IgaXMgbm90IHNldApDT05GSUdfQVRBPXkKIyBD
T05GSUdfQVRBX05PTlNUQU5EQVJEIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9WRVJCT1NFX0VSUk9S
PXkKQ09ORklHX0FUQV9BQ1BJPXkKQ09ORklHX1NBVEFfUE1QPXkKCiMKIyBDb250cm9sbGVycyB3
aXRoIG5vbi1TRkYgbmF0aXZlIGludGVyZmFjZQojCkNPTkZJR19TQVRBX0FIQ0k9eQpDT05GSUdf
U0FUQV9BSENJX1BMQVRGT1JNPXkKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NBVEFfQUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMMjQgaXMg
bm90IHNldAojIENPTkZJR19BVEFfU0ZGIGlzIG5vdCBzZXQKQ09ORklHX01EPXkKIyBDT05GSUdf
QkxLX0RFVl9NRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0RNPXkKQ09ORklHX0RNX0RFQlVH
PXkKQ09ORklHX0RNX0NSWVBUPXkKQ09ORklHX0RNX1NOQVBTSE9UPXkKIyBDT05GSUdfRE1fVEhJ
Tl9QUk9WSVNJT05JTkcgaXMgbm90IHNldApDT05GSUdfRE1fTUlSUk9SPXkKIyBDT05GSUdfRE1f
UkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0xPR19VU0VSU1BBQ0UgaXMgbm90IHNldApDT05G
SUdfRE1fWkVSTz15CiMgQ09ORklHX0RNX01VTFRJUEFUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0RN
X0RFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fVUVWRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdf
RE1fRkxBS0VZIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fVkVSSVRZIGlzIG5vdCBzZXQKIyBDT05G
SUdfVEFSR0VUX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19GVVNJT04gaXMgbm90IHNldAoKIwoj
IElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQKIwojIENPTkZJR19GSVJFV0lSRSBpcyBub3Qg
c2V0CiMgQ09ORklHX0ZJUkVXSVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJR19JMk8gaXMgbm90
IHNldAojIENPTkZJR19NQUNJTlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJ
Q0VTPXkKQ09ORklHX05FVF9DT1JFPXkKIyBDT05GSUdfQk9ORElORyBpcyBub3Qgc2V0CiMgQ09O
RklHX0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0ZDIGlzIG5vdCBzZXQKQ09ORklHX01JST15CiMgQ09ORklHX0lGQiBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9URUFNIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDVkxBTiBpcyBub3Qgc2V0
CiMgQ09ORklHX1ZYTEFOIGlzIG5vdCBzZXQKQ09ORklHX05FVENPTlNPTEU9eQpDT05GSUdfTkVU
UE9MTD15CiMgQ09ORklHX05FVFBPTExfVFJBUCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfUE9MTF9D
T05UUk9MTEVSPXkKQ09ORklHX1RVTj15CkNPTkZJR19WRVRIPXkKIyBDT05GSUdfQVJDTkVUIGlz
IG5vdCBzZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMKQ09ORklHX0VUSEVSTkVUPXkK
IyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9B
REFQVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9BTFRFT04gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQVRI
RVJPUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQlJPQURDT00gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX0JST0NBREUgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0FMWEVE
QV9YR01BQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQ0hFTFNJTyBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9WRU5ET1JfQ0lTQ08gaXMgbm90IHNldAojIENPTkZJR19ETkVUIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9ERUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX0RMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9FTVVMRVggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfVkVORE9SX0VYQVIgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X0hQIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfSU5URUw9eQojIENPTkZJR19FMTAwIGlz
IG5vdCBzZXQKQ09ORklHX0UxMDAwPXkKQ09ORklHX0UxMDAwRT15CkNPTkZJR19JR0I9eQojIENP
TkZJR19JR0JfUFRQIGlzIG5vdCBzZXQKQ09ORklHX0lHQlZGPXkKIyBDT05GSUdfSVhHQiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lYR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVhHQkVWRiBpcyBub3Qg
c2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX1pORVQgaXMgbm90IHNldAoj
IENPTkZJR19JUDEwMDAgaXMgbm90IHNldAojIENPTkZJR19KTUUgaXMgbm90IHNldAojIENPTkZJ
R19ORVRfVkVORE9SX01BUlZFTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX01FTExB
Tk9YIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9NSUNSRUwgaXMgbm90IHNldAojIENP
TkZJR19ORVRfVkVORE9SX01ZUkkgaXMgbm90IHNldAojIENPTkZJR19GRUFMTlggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfVkVORE9SX05BVFNFTUkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX05WSURJQSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfT0tJIGlzIG5vdCBzZXQK
IyBDT05GSUdfRVRIT0MgaXMgbm90IHNldAojIENPTkZJR19ORVRfUEFDS0VUX0VOR0lORSBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfUUxPR0lDIGlzIG5vdCBzZXQKQ09ORklHX05FVF9W
RU5ET1JfUkVBTFRFSz15CiMgQ09ORklHXzgxMzlDUCBpcyBub3Qgc2V0CiMgQ09ORklHXzgxMzlU
T08gaXMgbm90IHNldApDT05GSUdfUjgxNjk9eQojIENPTkZJR19ORVRfVkVORE9SX1JEQyBpcyBu
b3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NFRVE9eQojIENPTkZJR19TRUVRODAwNSBpcyBub3Qg
c2V0CkNPTkZJR19ORVRfVkVORE9SX1NJTEFOPXkKIyBDT05GSUdfU0M5MjAzMSBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9WRU5ET1JfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRP
Ul9TVE1JQ1JPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TVU4gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX1RFSFVUSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1Jf
VEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1ZJQSBpcyBub3Qgc2V0CkNPTkZJR19O
RVRfVkVORE9SX1dJWk5FVD15CiMgQ09ORklHX1dJWk5FVF9XNTEwMCBpcyBub3Qgc2V0CiMgQ09O
RklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMgbm90IHNldAojIENP
TkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldApDT05G
SUdfUEhZTElCPXkKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJzCiMKIyBDT05GSUdfQVQ4MDNY
X1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NQVJW
RUxMX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RBVklDT01fUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfUVNFTUlfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09O
RklHX0NJQ0FEQV9QSFkgaXMgbm90IHNldAojIENPTkZJR19WSVRFU1NFX1BIWSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NNU0NfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJPQURDT01fUEhZIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkNNODdYWF9QSFkgaXMgbm90IHNldAojIENPTkZJR19JQ1BMVVNfUEhZ
IGlzIG5vdCBzZXQKQ09ORklHX1JFQUxURUtfUEhZPXkKIyBDT05GSUdfTkFUSU9OQUxfUEhZIGlz
IG5vdCBzZXQKIyBDT05GSUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xTSV9FVDEwMTFD
X1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNldAojIENPTkZJR19G
SVhFRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcgaXMgbm90IHNldAojIENP
TkZJR19QUFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBVU0IgTmV0
d29yayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfVVNCTkVUIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0lQSEVUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1dMQU4gaXMgbm90IHNldAoK
IwojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBzZWUgdGhlIFdpTUFYIGRy
aXZlcnMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldApDT05GSUdfWEVOX05FVERFVl9GUk9OVEVO
RD15CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQojIENPTkZJR19WTVhORVQzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CgojCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpD
T05GSUdfSU5QVVQ9eQpDT05GSUdfSU5QVVRfRkZfTUVNTEVTUz15CkNPTkZJR19JTlBVVF9QT0xM
REVWPXkKQ09ORklHX0lOUFVUX1NQQVJTRUtNQVA9eQojIENPTkZJR19JTlBVVF9NQVRSSVhLTUFQ
IGlzIG5vdCBzZXQKCiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01PVVNF
REVWPXkKIyBDT05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVggaXMgbm90IHNldApDT05GSUdfSU5Q
VVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9
NzY4CiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRFVj15
CiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJpdmVy
cwojCkNPTkZJR19JTlBVVF9LRVlCT0FSRD15CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODggaXMg
bm90IHNldAojIENPTkZJR19LRVlCT0FSRF9BRFA1NTg5IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJP
QVJEX0FUS0JEPXkKIyBDT05GSUdfS0VZQk9BUkRfUVQxMDcwIGlzIG5vdCBzZXQKIyBDT05GSUdf
S0VZQk9BUkRfUVQyMTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTEtLQkQgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E2NDE2IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9B
UkRfVENBODQxOCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBub3Qgc2V0
CiMgQ09ORklHX0tFWUJPQVJEX0xNODMzMyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01B
WDczNTkgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90IHNldAojIENPTkZJ
R19LRVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9ORVdUT04gaXMg
bm90IHNldAojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMgbm90IHNldAojIENPTkZJR19L
RVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NVTktCRCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09NQVA0IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9B
UkRfWFRLQkQgaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0U9eQpDT05GSUdfTU9VU0VfUFMy
PXkKQ09ORklHX01PVVNFX1BTMl9BTFBTPXkKQ09ORklHX01PVVNFX1BTMl9MT0dJUFMyUFA9eQpD
T05GSUdfTU9VU0VfUFMyX1NZTkFQVElDUz15CkNPTkZJR19NT1VTRV9QUzJfTElGRUJPT0s9eQpD
T05GSUdfTU9VU0VfUFMyX1RSQUNLUE9JTlQ9eQojIENPTkZJR19NT1VTRV9QUzJfRUxBTlRFQ0gg
aXMgbm90IHNldAojIENPTkZJR19NT1VTRV9QUzJfU0VOVEVMSUMgaXMgbm90IHNldAojIENPTkZJ
R19NT1VTRV9QUzJfVE9VQ0hLSVQgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TRVJJQUwgaXMg
bm90IHNldAojIENPTkZJR19NT1VTRV9BUFBMRVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9V
U0VfQkNNNTk3NCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1ZTWFhYQUEgaXMgbm90IHNldAoj
IENPTkZJR19NT1VTRV9TWU5BUFRJQ1NfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfU1lO
QVBUSUNTX1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQK
Q09ORklHX0lOUFVUX1RBQkxFVD15CiMgQ09ORklHX1RBQkxFVF9VU0JfQUNFQ0FEIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVEFCTEVUX1VTQl9BSVBURUsgaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRf
VVNCX0dUQ08gaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRfVVNCX0hBTldBTkcgaXMgbm90IHNl
dAojIENPTkZJR19UQUJMRVRfVVNCX0tCVEFCIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFCTEVUX1VT
Ql9XQUNPTSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CiMgQ09ORklHX1RP
VUNIU0NSRUVOX0FENzg3OSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FUTUVMX01Y
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMTMgaXMgbm90IHNldAojIENP
TkZJR19UT1VDSFNDUkVFTl9DWVRUU1BfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NS
RUVOX0RZTkFQUk8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9IQU1QU0hJUkUgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9FRVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fRlVKSVRTVSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIxMFgg
aXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9HVU5aRSBpcyBub3Qgc2V0CiMgQ09ORklH
X1RPVUNIU0NSRUVOX0VMTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4
MDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fV0FDT01fSTJDIGlzIG5vdCBzZXQK
IyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUFYMTE4MDEgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFND
UkVFTl9NQ1M1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTU1TMTE0IGlzIG5v
dCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fSU5FWElPIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUs3MTIgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9QRU5NT1VOVCBpcyBub3Qgc2V0CiMgQ09ORklH
X1RPVUNIU0NSRUVOX0VEVF9GVDVYMDYgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9U
T1VDSFJJR0hUIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hXSU4gaXMgbm90
IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9QSVhDSVIgaXMgbm90IHNldAojIENPTkZJR19UT1VD
SFNDUkVFTl9VU0JfQ09NUE9TSVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9V
Q0hJVDIxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQ19TRVJJTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQzIwMDcgaXMgbm90IHNldAojIENPTkZJR19UT1VD
SFNDUkVFTl9TVDEyMzIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBp
cyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5QVVRfQk1BMTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUENT
UEtSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTU1BODQ1MCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lOUFVUX01QVTMwNTAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BUEFORUwgaXMgbm90IHNl
dAojIENPTkZJR19JTlBVVF9BVExBU19CVE5TIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQVRJ
X1JFTU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9LRVlTUEFOX1JFTU9URSBpcyBub3Qg
c2V0CiMgQ09ORklHX0lOUFVUX0tYVEo5IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUE9XRVJN
QVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfWUVBTElOSyBpcyBub3Qgc2V0CiMgQ09ORklH
X0lOUFVUX0NNMTA5IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfVUlOUFVUIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU5QVVRfUENGODU3NCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0FEWEwzNFgg
aXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTUEzMDAwIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVU
X1hFTl9LQkRERVZfRlJPTlRFTkQ9eQoKIwojIEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19T
RVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPXkKIyBDT05G
SUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90
IHNldApDT05GSUdfU0VSSU9fTElCUFMyPXkKIyBDT05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VSSU9fQUxURVJBX1BTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BTMk1V
TFQgaXMgbm90IHNldAojIENPTkZJR19HQU1FUE9SVCBpcyBub3Qgc2V0CgojCiMgQ2hhcmFjdGVy
IGRldmljZXMKIwpDT05GSUdfVlQ9eQpDT05GSUdfQ09OU09MRV9UUkFOU0xBVElPTlM9eQpDT05G
SUdfVlRfQ09OU09MRT15CkNPTkZJR19WVF9DT05TT0xFX1NMRUVQPXkKQ09ORklHX0hXX0NPTlNP
TEU9eQpDT05GSUdfVlRfSFdfQ09OU09MRV9CSU5ESU5HPXkKQ09ORklHX1VOSVg5OF9QVFlTPXkK
IyBDT05GSUdfREVWUFRTX01VTFRJUExFX0lOU1RBTkNFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xF
R0FDWV9QVFlTIGlzIG5vdCBzZXQKQ09ORklHX1NFUklBTF9OT05TVEFOREFSRD15CiMgQ09ORklH
X1JPQ0tFVFBPUlQgaXMgbm90IHNldAojIENPTkZJR19DWUNMQURFUyBpcyBub3Qgc2V0CiMgQ09O
RklHX01PWEFfSU5URUxMSU8gaXMgbm90IHNldAojIENPTkZJR19NT1hBX1NNQVJUSU8gaXMgbm90
IHNldAojIENPTkZJR19TWU5DTElOSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NZTkNMSU5LTVAgaXMg
bm90IHNldAojIENPTkZJR19TWU5DTElOS19HVCBpcyBub3Qgc2V0CiMgQ09ORklHX05PWk9NSSBp
cyBub3Qgc2V0CiMgQ09ORklHX0lTSSBpcyBub3Qgc2V0CiMgQ09ORklHX05fSERMQyBpcyBub3Qg
c2V0CiMgQ09ORklHX05fR1NNIGlzIG5vdCBzZXQKIyBDT05GSUdfVFJBQ0VfU0lOSyBpcyBub3Qg
c2V0CiMgQ09ORklHX0RFVktNRU0gaXMgbm90IHNldAojIENPTkZJR19TVEFMRFJWIGlzIG5vdCBz
ZXQKCiMKIyBTZXJpYWwgZHJpdmVycwojCkNPTkZJR19TRVJJQUxfODI1MD15CkNPTkZJR19TRVJJ
QUxfODI1MF9QTlA9eQpDT05GSUdfU0VSSUFMXzgyNTBfQ09OU09MRT15CkNPTkZJR19GSVhfRUFS
TFlDT05fTUVNPXkKQ09ORklHX1NFUklBTF84MjUwX1BDST15CkNPTkZJR19TRVJJQUxfODI1MF9O
Ul9VQVJUUz0zMgpDT05GSUdfU0VSSUFMXzgyNTBfUlVOVElNRV9VQVJUUz00CkNPTkZJR19TRVJJ
QUxfODI1MF9FWFRFTkRFRD15CkNPTkZJR19TRVJJQUxfODI1MF9NQU5ZX1BPUlRTPXkKQ09ORklH
X1NFUklBTF84MjUwX1NIQVJFX0lSUT15CkNPTkZJR19TRVJJQUxfODI1MF9ERVRFQ1RfSVJRPXkK
Q09ORklHX1NFUklBTF84MjUwX1JTQT15CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9y
dAojCiMgQ09ORklHX1NFUklBTF9NRkRfSFNVIGlzIG5vdCBzZXQKQ09ORklHX1NFUklBTF9DT1JF
PXkKQ09ORklHX1NFUklBTF9DT1JFX0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfSlNNIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VSSUFMX1NDQ05YUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9U
SU1CRVJEQUxFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9KVEFHVUFSVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
UklBTF9QQ0hfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9YSUxJTlhfUFNfVUFSVCBp
cyBub3Qgc2V0CkNPTkZJR19IVkNfRFJJVkVSPXkKQ09ORklHX0hWQ19JUlE9eQpDT05GSUdfSFZD
X1hFTj15CkNPTkZJR19IVkNfWEVOX0ZST05URU5EPXkKIyBDT05GSUdfSVBNSV9IQU5ETEVSIGlz
IG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT15CkNPTkZJR19IV19SQU5ET01fVElNRVJJT01FTT15
CkNPTkZJR19IV19SQU5ET01fSU5URUw9eQpDT05GSUdfSFdfUkFORE9NX0FNRD15CkNPTkZJR19I
V19SQU5ET01fVklBPXkKIyBDT05GSUdfTlZSQU0gaXMgbm90IHNldAojIENPTkZJR19SMzk2NCBp
cyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTVdBVkUgaXMg
bm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0hQRVQ9eQojIENP
TkZJR19IUEVUX01NQVAgaXMgbm90IHNldApDT05GSUdfSEFOR0NIRUNLX1RJTUVSPXkKIyBDT05G
SUdfVENHX1RQTSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFTENMT0NLIGlzIG5vdCBzZXQKQ09ORklH
X0RFVlBPUlQ9eQpDT05GSUdfSTJDPXkKQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdfSTJD
X0NPTVBBVD15CiMgQ09ORklHX0kyQ19DSEFSREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX01V
WCBpcyBub3Qgc2V0CkNPTkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FMR09CSVQ9
eQoKIwojIEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgUEMgU01CdXMgaG9zdCBjb250
cm9sbGVyIGRyaXZlcnMKIwojIENPTkZJR19JMkNfQUxJMTUzNSBpcyBub3Qgc2V0CiMgQ09ORklH
X0kyQ19BTEkxNTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1WDMgaXMgbm90IHNldApD
T05GSUdfSTJDX0FNRDc1Nj15CiMgQ09ORklHX0kyQ19BTUQ3NTZfUzQ4ODIgaXMgbm90IHNldApD
T05GSUdfSTJDX0FNRDgxMTE9eQpDT05GSUdfSTJDX0k4MDE9eQpDT05GSUdfSTJDX0lTQ0g9eQpD
T05GSUdfSTJDX1BJSVg0PXkKIyBDT05GSUdfSTJDX05GT1JDRTIgaXMgbm90IHNldAojIENPTkZJ
R19JMkNfU0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM2MzAgaXMgbm90IHNldAoj
IENPTkZJR19JMkNfU0lTOTZYIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1ZJQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0kyQ19WSUFQUk8gaXMgbm90IHNldAoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJ
R19JMkNfU0NNST15CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVk
IC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0RFU0lHTldBUkVfUENJIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSTJDX0VHMjBUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0lOVEVMX01JRCBp
cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19PQ09SRVMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUENB
X1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BYQV9QQ0kgaXMgbm90IHNldAojIENP
TkZJR19JMkNfU0lNVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1hJTElOWCBpcyBub3Qgc2V0
CgojCiMgRXh0ZXJuYWwgSTJDL1NNQnVzIGFkYXB0ZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19E
SU9MQU5fVTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQgaXMgbm90IHNl
dAojIENPTkZJR19JMkNfVEFPU19FVk0gaXMgbm90IHNldAojIENPTkZJR19JMkNfVElOWV9VU0Ig
aXMgbm90IHNldAoKIwojIE90aGVyIEkyQy9TTUJ1cyBidXMgZHJpdmVycwojCiMgQ09ORklHX0ky
Q19TVFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENP
TkZJR19JMkNfREVCVUdfQUxHTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMg
bm90IHNldAojIENPTkZJR19TUEkgaXMgbm90IHNldAojIENPTkZJR19IU0kgaXMgbm90IHNldAoK
IwojIFBQUyBzdXBwb3J0CiMKIyBDT05GSUdfUFBTIGlzIG5vdCBzZXQKCiMKIyBQUFMgZ2VuZXJh
dG9ycyBzdXBwb3J0CiMKCiMKIyBQVFAgY2xvY2sgc3VwcG9ydAojCgojCiMgRW5hYmxlIERldmlj
ZSBEcml2ZXJzIC0+IFBQUyB0byBzZWUgdGhlIFBUUCBjbG9jayBvcHRpb25zLgojCkNPTkZJR19B
UkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15CiMgQ09ORklHX0dQSU9MSUIgaXMgbm90IHNldAoj
IENPTkZJR19XMSBpcyBub3Qgc2V0CkNPTkZJR19QT1dFUl9TVVBQTFk9eQojIENPTkZJR19QT1dF
Ul9TVVBQTFlfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAoj
IENPTkZJR19URVNUX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODAgaXMg
bm90IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRF
UllfRFMyNzgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9TQlMgaXMgbm90IHNldAojIENP
TkZJR19CQVRURVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX01BWDE3MDQw
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBub3Qgc2V0CiMgQ09ORklH
X0NIQVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTFA4NzI3IGlzIG5v
dCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9TTUIzNDcgaXMgbm90IHNldAojIENPTkZJR19QT1dFUl9B
VlMgaXMgbm90IHNldApDT05GSUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPXkKIyBDT05GSUdf
SFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMKIwojIENPTkZJ
R19TRU5TT1JTX0FCSVRVR1VSVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUJJVFVHVVJV
MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19BRDc0MTggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjEgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FETTEwMjYgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjkgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX0FETTEwMzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTky
NDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0MTAgaXMgbm90IHNldAojIENPTkZJ
R19TRU5TT1JTX0FEVDc0MTEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NjIgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NzAgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0FEVDc0NzUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FTQzc2MjEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0s4VEVNUCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0sxMFRF
TVA9eQpDT05GSUdfU0VOU09SU19GQU0xNUhfUE9XRVI9eQojIENPTkZJR19TRU5TT1JTX0FTQjEw
MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX0RTNjIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0k1S19BTUIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19GNzE4
MDVGPXkKQ09ORklHX1NFTlNPUlNfRjcxODgyRkc9eQpDT05GSUdfU0VOU09SU19GNzUzNzVTPXkK
IyBDT05GSUdfU0VOU09SU19GU0NITUQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0c3NjBB
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19ISUg2MTMwIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19DT1JFVEVNUCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JT
X0lUODc9eQpDT05GSUdfU0VOU09SU19KQzQyPXkKIyBDT05GSUdfU0VOU09SU19MSU5FQUdFIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19MTTczIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc1IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc4IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgz
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19MTTg3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19MTTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkzIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MTUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19MVEM0MjE1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjQ1IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19MVEM0MjYxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1
MjQxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTYxOSBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTY2OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
TlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjM5IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19N
QVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
UEM4NzM2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CiMgQ09ORklHX1BNQlVTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0lT
NTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19ETUUxNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMxNDAzIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMyMTAzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19FTUM2VzIwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01TQzQ3TTEgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xOTIgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX1NNU0M0N0IzOTcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NDSDU2WFhfQ09NTU9O
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NjI3IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19TQ0g1NjM2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFMxMDE1IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFM3ODI4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19BTUM2ODIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19JTkEyWFggaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX1RITUM1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVE1QMTAy
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UTVA0MDEgaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX1RNUDQyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBX0NQVVRFTVAgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX1ZJQTY4NkEgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX1ZUMTIxMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQ4MjMxIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19XODM3ODFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3
OTFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTJEIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19XODM3OTMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5NSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19XODNMNzg2TkcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4MzYyN0hGIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM2MjdFSEYgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0FQUExFU01DIGlzIG5vdCBzZXQKCiMKIyBBQ1BJIGRyaXZlcnMKIwpDT05GSUdfU0VOU09S
U19BQ1BJX1BPV0VSPXkKIyBDT05GSUdfU0VOU09SU19BVEswMTEwIGlzIG5vdCBzZXQKQ09ORklH
X1RIRVJNQUw9eQpDT05GSUdfVEhFUk1BTF9IV01PTj15CiMgQ09ORklHX0NQVV9USEVSTUFMIGlz
IG5vdCBzZXQKQ09ORklHX1dBVENIRE9HPXkKQ09ORklHX1dBVENIRE9HX0NPUkU9eQojIENPTkZJ
R19XQVRDSERPR19OT1dBWU9VVCBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgRGV2aWNlIERyaXZl
cnMKIwojIENPTkZJR19TT0ZUX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNRVUlSRV9X
RFQgaXMgbm90IHNldAojIENPTkZJR19BRFZBTlRFQ0hfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdf
QUxJTTE1MzVfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfQUxJTTcxMDFfV0RUIGlzIG5vdCBzZXQK
IyBDT05GSUdfRjcxODA4RV9XRFQgaXMgbm90IHNldApDT05GSUdfU1A1MTAwX1RDTz15CiMgQ09O
RklHX1NDNTIwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NCQ19GSVRQQzJfV0FUQ0hET0cgaXMg
bm90IHNldAojIENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90IHNldAojIENPTkZJR19JQjcwMF9X
RFQgaXMgbm90IHNldAojIENPTkZJR19JQk1BU1IgaXMgbm90IHNldAojIENPTkZJR19XQUZFUl9X
RFQgaXMgbm90IHNldAojIENPTkZJR19JNjMwMEVTQl9XRFQgaXMgbm90IHNldAojIENPTkZJR19J
RTZYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19JVENPX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lUODcxMkZfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfSVQ4N19XRFQgaXMgbm90IHNldAojIENP
TkZJR19IUF9XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDMTIwMF9XRFQgaXMgbm90IHNl
dAojIENPTkZJR19QQzg3NDEzX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX05WX1RDTyBpcyBub3Qg
c2V0CiMgQ09ORklHXzYwWFhfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JDODM2MF9XRFQgaXMg
bm90IHNldAojIENPTkZJR19DUFU1X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0NfU0NIMzEx
WF9XRFQgaXMgbm90IHNldAojIENPTkZJR19TTVNDMzdCNzg3X1dEVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1ZJQV9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM2MjdIRl9XRFQgaXMgbm90IHNldAoj
IENPTkZJR19XODM2OTdIRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM2OTdVR19XRFQgaXMg
bm90IHNldAojIENPTkZJR19XODM4NzdGX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4Mzk3N0Zf
V0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDSFpfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JD
X0VQWF9DM19XQVRDSERPRyBpcyBub3Qgc2V0CkNPTkZJR19YRU5fV0RUPXkKCiMKIyBQQ0ktYmFz
ZWQgV2F0Y2hkb2cgQ2FyZHMKIwojIENPTkZJR19QQ0lQQ1dBVENIRE9HIGlzIG5vdCBzZXQKIyBD
T05GSUdfV0RUUENJIGlzIG5vdCBzZXQKCiMKIyBVU0ItYmFzZWQgV2F0Y2hkb2cgQ2FyZHMKIwoj
IENPTkZJR19VU0JQQ1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1NTQl9QT1NTSUJMRT15Cgoj
CiMgU29uaWNzIFNpbGljb24gQmFja3BsYW5lCiMKIyBDT05GSUdfU1NCIGlzIG5vdCBzZXQKQ09O
RklHX0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNwZWNpZmljIEFNQkEKIwojIENPTkZJ
R19CQ01BIGlzIG5vdCBzZXQKCiMKIyBNdWx0aWZ1bmN0aW9uIGRldmljZSBkcml2ZXJzCiMKQ09O
RklHX01GRF9DT1JFPXkKIyBDT05GSUdfTUZEXzg4UE04NjBYIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUZEXzg4UE04MDAgaXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTgwNSBpcyBub3Qgc2V0CiMg
Q09ORklHX01GRF9TTTUwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0hUQ19QQVNJQzMgaXMgbm90IHNl
dAojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjEwNVggaXMgbm90
IHNldAojIENPTkZJR19UUFM2NTA3WCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9UUFM2NTIxNyBp
cyBub3Qgc2V0CiMgQ09ORklHX1RXTDQwMzBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDYw
NDBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TVE1QRSBpcyBub3Qgc2V0CiMgQ09ORklH
X01GRF9UQzM1ODlYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RNSU8gaXMgbm90IHNldAojIENP
TkZJR19NRkRfU01TQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BNSUNfREE5MDNYIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX0RBOTA1Ml9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfREE5MDU1IGlz
IG5vdCBzZXQKIyBDT05GSUdfUE1JQ19BRFA1NTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xQ
ODc4OCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg3NzY4NiBpcyBub3Qgc2V0CiMgQ09ORklH
X01GRF9NQVg3NzY5MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTA3IGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX01BWDg5MjUgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODk5NyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTk4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1NFQ19D
T1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FSSVpPTkFfSTJDIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX1dNODQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzMVhfSTJDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUZEX1dNODM1MF9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004OTk0
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1BDRjUwNjMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X01DMTNYWFhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUJYNTAwX0NPUkUgaXMgbm90IHNldAoj
IENPTkZJR19NRkRfQ1M1NTM1IGlzIG5vdCBzZXQKQ09ORklHX0xQQ19TQ0g9eQojIENPTkZJR19M
UENfSUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JEQzMyMVggaXMgbm90IHNldAojIENPTkZJ
R19NRkRfSkFOWl9DTU9ESU8gaXMgbm90IHNldAojIENPTkZJR19NRkRfVlg4NTUgaXMgbm90IHNl
dAojIENPTkZJR19NRkRfV0wxMjczX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjUw
OTAgaXMgbm90IHNldAojIENPTkZJR19NRkRfUkM1VDU4MyBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9QQUxNQVMgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1IgaXMgbm90IHNldApDT05GSUdf
TUVESUFfU1VQUE9SVD15CgojCiMgTXVsdGltZWRpYSBjb3JlIHN1cHBvcnQKIwpDT05GSUdfTUVE
SUFfQ0FNRVJBX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfQU5BTE9HX1RWX1NVUFBPUlQ9eQpDT05G
SUdfTUVESUFfRElHSVRBTF9UVl9TVVBQT1JUPXkKQ09ORklHX01FRElBX1JBRElPX1NVUFBPUlQ9
eQpDT05GSUdfTUVESUFfUkNfU1VQUE9SVD15CiMgQ09ORklHX01FRElBX0NPTlRST0xMRVIgaXMg
bm90IHNldApDT05GSUdfVklERU9fREVWPXkKQ09ORklHX1ZJREVPX1Y0TDI9eQpDT05GSUdfVklE
RU9fQURWX0RFQlVHPXkKIyBDT05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBz
ZXQKQ09ORklHX1ZJREVPX1RVTkVSPXkKQ09ORklHX1ZJREVPQlVGX0dFTj15CkNPTkZJR19WSURF
T0JVRl9ETUFfU0c9eQpDT05GSUdfVklERU9CVUZfRFZCPXkKQ09ORklHX0RWQl9DT1JFPXkKQ09O
RklHX0RWQl9ORVQ9eQpDT05GSUdfRFZCX01BWF9BREFQVEVSUz04CiMgQ09ORklHX0RWQl9EWU5B
TUlDX01JTk9SUyBpcyBub3Qgc2V0CgojCiMgTWVkaWEgZHJpdmVycwojCkNPTkZJR19SQ19DT1JF
PXkKQ09ORklHX1JDX01BUD15CkNPTkZJR19SQ19ERUNPREVSUz15CkNPTkZJR19MSVJDPXkKQ09O
RklHX0lSX0xJUkNfQ09ERUM9eQpDT05GSUdfSVJfTkVDX0RFQ09ERVI9eQpDT05GSUdfSVJfUkM1
X0RFQ09ERVI9eQpDT05GSUdfSVJfUkM2X0RFQ09ERVI9eQpDT05GSUdfSVJfSlZDX0RFQ09ERVI9
eQpDT05GSUdfSVJfU09OWV9ERUNPREVSPXkKQ09ORklHX0lSX1JDNV9TWl9ERUNPREVSPXkKQ09O
RklHX0lSX1NBTllPX0RFQ09ERVI9eQpDT05GSUdfSVJfTUNFX0tCRF9ERUNPREVSPXkKIyBDT05G
SUdfUkNfREVWSUNFUyBpcyBub3Qgc2V0CkNPTkZJR19NRURJQV9VU0JfU1VQUE9SVD15CgojCiMg
V2ViY2FtIGRldmljZXMKIwojIENPTkZJR19VU0JfVklERU9fQ0xBU1MgaXMgbm90IHNldAojIENP
TkZJR19VU0JfR1NQQ0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfUFdDIGlzIG5vdCBzZXQKIyBD
T05GSUdfVklERU9fQ1BJQTIgaXMgbm90IHNldAojIENPTkZJR19VU0JfWlIzNjRYWCBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9TVEtXRUJDQU0gaXMgbm90IHNldAojIENPTkZJR19VU0JfUzIyNTUg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU045QzEwMiBpcyBub3Qgc2V0CgojCiMgQW5hbG9nIFRW
IFVTQiBkZXZpY2VzCiMKIyBDT05GSUdfVklERU9fQVUwODI4IGlzIG5vdCBzZXQKQ09ORklHX1ZJ
REVPX1BWUlVTQjI9eQpDT05GSUdfVklERU9fUFZSVVNCMl9TWVNGUz15CkNPTkZJR19WSURFT19Q
VlJVU0IyX0RWQj15CiMgQ09ORklHX1ZJREVPX1BWUlVTQjJfREVCVUdJRkMgaXMgbm90IHNldAoj
IENPTkZJR19WSURFT19IRFBWUiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RMRzIzMDAgaXMg
bm90IHNldAojIENPTkZJR19WSURFT19VU0JWSVNJT04gaXMgbm90IHNldAojIENPTkZJR19WSURF
T19TVEsxMTYwIGlzIG5vdCBzZXQKCiMKIyBBbmFsb2cvZGlnaXRhbCBUViBVU0IgZGV2aWNlcwoj
CiMgQ09ORklHX1ZJREVPX0NYMjMxWFggaXMgbm90IHNldAojIENPTkZJR19WSURFT19UTTYwMDAg
aXMgbm90IHNldAoKIwojIERpZ2l0YWwgVFYgVVNCIGRldmljZXMKIwojIENPTkZJR19EVkJfVVNC
IGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX1VTQl9WMiBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9U
VFVTQl9CVURHRVQgaXMgbm90IHNldAojIENPTkZJR19EVkJfVFRVU0JfREVDIGlzIG5vdCBzZXQK
IyBDT05GSUdfU01TX1VTQl9EUlYgaXMgbm90IHNldAojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09Q
X1VTQiBpcyBub3Qgc2V0CgojCiMgV2ViY2FtLCBUViAoYW5hbG9nL2RpZ2l0YWwpIFVTQiBkZXZp
Y2VzCiMKIyBDT05GSUdfVklERU9fRU0yOFhYIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1BDSV9T
VVBQT1JUPXkKCiMKIyBNZWRpYSBjYXB0dXJlIHN1cHBvcnQKIwoKIwojIE1lZGlhIGNhcHR1cmUv
YW5hbG9nIFRWIHN1cHBvcnQKIwojIENPTkZJR19WSURFT19JVlRWIGlzIG5vdCBzZXQKIyBDT05G
SUdfVklERU9fWk9SQU4gaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRVhJVU1fR0VNSU5JIGlz
IG5vdCBzZXQKIyBDT05GSUdfVklERU9fSEVYSVVNX09SSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdf
VklERU9fTVhCIGlzIG5vdCBzZXQKCiMKIyBNZWRpYSBjYXB0dXJlL2FuYWxvZy9oeWJyaWQgVFYg
c3VwcG9ydAojCiMgQ09ORklHX1ZJREVPX0NYMTggaXMgbm90IHNldAojIENPTkZJR19WSURFT19D
WDIzODg1IGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX0NYMjU4MjE9eQojIENPTkZJR19WSURFT19D
WDI1ODIxX0FMU0EgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DWDg4IGlzIG5vdCBzZXQKIyBD
T05GSUdfVklERU9fQlQ4NDggaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE3MTM0IGlzIG5v
dCBzZXQKIyBDT05GSUdfVklERU9fU0FBNzE2NCBpcyBub3Qgc2V0CgojCiMgTWVkaWEgZGlnaXRh
bCBUViBQQ0kgQWRhcHRlcnMKIwojIENPTkZJR19UVFBDSV9FRVBST00gaXMgbm90IHNldAojIENP
TkZJR19EVkJfQVY3MTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JVREdFVF9DT1JFIGlzIG5v
dCBzZXQKIyBDT05GSUdfRFZCX0IyQzJfRkxFWENPUF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19E
VkJfUExVVE8yIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0RNMTEwNSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RWQl9QVDEgaXMgbm90IHNldAojIENPTkZJR19NQU5USVNfQ09SRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0RWQl9OR0VORSBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9EREJSSURHRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1Y0TF9QTEFURk9STV9EUklWRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfVjRM
X01FTTJNRU1fRFJJVkVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1Y0TF9URVNUX0RSSVZFUlMgaXMg
bm90IHNldAoKIwojIFN1cHBvcnRlZCBNTUMvU0RJTyBhZGFwdGVycwojCiMgQ09ORklHX1JBRElP
X0FEQVBURVJTIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1NVQkRSVl9BVVRPU0VMRUNUPXkKCiMK
IyBNZWRpYSBhbmNpbGxhcnkgZHJpdmVycyAodHVuZXJzLCBzZW5zb3JzLCBpMmMsIGZyb250ZW5k
cykKIwpDT05GSUdfVklERU9fQlRDWD15CkNPTkZJR19WSURFT19UVkVFUFJPTT15CkNPTkZJR19W
SURFT19JUl9JMkM9eQoKIwojIEF1ZGlvIGRlY29kZXJzLCBwcm9jZXNzb3JzIGFuZCBtaXhlcnMK
IwpDT05GSUdfVklERU9fTVNQMzQwMD15CkNPTkZJR19WSURFT19DUzUzTDMyQT15CkNPTkZJR19W
SURFT19XTTg3NzU9eQoKIwojIFJEUyBkZWNvZGVycwojCgojCiMgVmlkZW8gZGVjb2RlcnMKIwpD
T05GSUdfVklERU9fU0FBNzExWD15CgojCiMgVmlkZW8gYW5kIGF1ZGlvIGRlY29kZXJzCiMKQ09O
RklHX1ZJREVPX0NYMjU4NDA9eQoKIwojIE1QRUcgdmlkZW8gZW5jb2RlcnMKIwpDT05GSUdfVklE
RU9fQ1gyMzQxWD15CgojCiMgVmlkZW8gZW5jb2RlcnMKIwoKIwojIENhbWVyYSBzZW5zb3IgZGV2
aWNlcwojCgojCiMgRmxhc2ggZGV2aWNlcwojCgojCiMgVmlkZW8gaW1wcm92ZW1lbnQgY2hpcHMK
IwoKIwojIE1pc2NlbGFuZW91cyBoZWxwZXIgY2hpcHMKIwoKIwojIFNlbnNvcnMgdXNlZCBvbiBz
b2NfY2FtZXJhIGRyaXZlcgojCiMgQ09ORklHX01FRElBX0FUVEFDSCBpcyBub3Qgc2V0CkNPTkZJ
R19NRURJQV9UVU5FUj15CkNPTkZJR19NRURJQV9UVU5FUl9TSU1QTEU9eQpDT05GSUdfTUVESUFf
VFVORVJfVERBODI5MD15CkNPTkZJR19NRURJQV9UVU5FUl9UREE4MjdYPXkKQ09ORklHX01FRElB
X1RVTkVSX1REQTE4MjcxPXkKQ09ORklHX01FRElBX1RVTkVSX1REQTk4ODc9eQpDT05GSUdfTUVE
SUFfVFVORVJfVEVBNTc2MT15CkNPTkZJR19NRURJQV9UVU5FUl9URUE1NzY3PXkKQ09ORklHX01F
RElBX1RVTkVSX01UMjBYWD15CkNPTkZJR19NRURJQV9UVU5FUl9YQzIwMjg9eQpDT05GSUdfTUVE
SUFfVFVORVJfWEM1MDAwPXkKQ09ORklHX01FRElBX1RVTkVSX1hDNDAwMD15CkNPTkZJR19NRURJ
QV9UVU5FUl9NQzQ0UzgwMz15CgojCiMgTXVsdGlzdGFuZGFyZCAoc2F0ZWxsaXRlKSBmcm9udGVu
ZHMKIwoKIwojIE11bHRpc3RhbmRhcmQgKGNhYmxlICsgdGVycmVzdHJpYWwpIGZyb250ZW5kcwoj
CgojCiMgRFZCLVMgKHNhdGVsbGl0ZSkgZnJvbnRlbmRzCiMKCiMKIyBEVkItVCAodGVycmVzdHJp
YWwpIGZyb250ZW5kcwojCkNPTkZJR19EVkJfVERBMTAwNDg9eQoKIwojIERWQi1DIChjYWJsZSkg
ZnJvbnRlbmRzCiMKCiMKIyBBVFNDIChOb3J0aCBBbWVyaWNhbi9Lb3JlYW4gVGVycmVzdHJpYWwv
Q2FibGUgRFRWKSBmcm9udGVuZHMKIwpDT05GSUdfRFZCX0xHRFQzMzBYPXkKQ09ORklHX0RWQl9T
NUgxNDA5PXkKQ09ORklHX0RWQl9TNUgxNDExPXkKCiMKIyBJU0RCLVQgKHRlcnJlc3RyaWFsKSBm
cm9udGVuZHMKIwoKIwojIERpZ2l0YWwgdGVycmVzdHJpYWwgb25seSB0dW5lcnMvUExMCiMKCiMK
IyBTRUMgY29udHJvbCBkZXZpY2VzIGZvciBEVkItUwojCgojCiMgVG9vbHMgdG8gZGV2ZWxvcCBu
ZXcgZnJvbnRlbmRzCiMKIyBDT05GSUdfRFZCX0RVTU1ZX0ZFIGlzIG5vdCBzZXQKCiMKIyBHcmFw
aGljcyBzdXBwb3J0CiMKQ09ORklHX0FHUD15CkNPTkZJR19BR1BfQU1ENjQ9eQpDT05GSUdfQUdQ
X0lOVEVMPXkKIyBDT05GSUdfQUdQX1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9WSUEgaXMg
bm90IHNldApDT05GSUdfVkdBX0FSQj15CkNPTkZJR19WR0FfQVJCX01BWF9HUFVTPTE2CiMgQ09O
RklHX1ZHQV9TV0lUQ0hFUk9PIGlzIG5vdCBzZXQKQ09ORklHX0RSTT15CkNPTkZJR19EUk1fS01T
X0hFTFBFUj15CiMgQ09ORklHX0RSTV9MT0FEX0VESURfRklSTVdBUkUgaXMgbm90IHNldAojIENP
TkZJR19EUk1fVERGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9SMTI4IGlzIG5vdCBzZXQKIyBD
T05GSUdfRFJNX1JBREVPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9OT1VWRUFVIGlzIG5vdCBz
ZXQKCiMKIyBJMkMgZW5jb2RlciBvciBoZWxwZXIgY2hpcHMKIwpDT05GSUdfRFJNX0kyQ19DSDcw
MDY9eQpDT05GSUdfRFJNX0kyQ19TSUwxNjQ9eQpDT05GSUdfRFJNX0k5MTU9eQpDT05GSUdfRFJN
X0k5MTVfS01TPXkKIyBDT05GSUdfRFJNX01HQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9TSVMg
aXMgbm90IHNldAojIENPTkZJR19EUk1fVklBIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1NBVkFH
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9WTVdHRlggaXMgbm90IHNldAojIENPTkZJR19EUk1f
R01BNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1VETCBpcyBub3Qgc2V0CiMgQ09ORklHX0RS
TV9BU1QgaXMgbm90IHNldAojIENPTkZJR19EUk1fTUdBRzIwMCBpcyBub3Qgc2V0CiMgQ09ORklH
X0RSTV9DSVJSVVNfUUVNVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1ZHQVNUQVRFIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX09VVFBVVF9DT05U
Uk9MPXkKQ09ORklHX0ZCPXkKIyBDT05GSUdfRklSTVdBUkVfRURJRCBpcyBub3Qgc2V0CiMgQ09O
RklHX0ZCX0REQyBpcyBub3Qgc2V0CkNPTkZJR19GQl9CT09UX1ZFU0FfU1VQUE9SVD15CkNPTkZJ
R19GQl9DRkJfRklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVBPXkKQ09ORklHX0ZCX0NG
Ql9JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9DRkJfUkVWX1BJWEVMU19JTl9CWVRFIGlzIG5vdCBz
ZXQKQ09ORklHX0ZCX1NZU19GSUxMUkVDVD15CkNPTkZJR19GQl9TWVNfQ09QWUFSRUE9eQpDT05G
SUdfRkJfU1lTX0lNQUdFQkxJVD15CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5ESUFOIGlzIG5vdCBz
ZXQKQ09ORklHX0ZCX1NZU19GT1BTPXkKIyBDT05GSUdfRkJfV01UX0dFX1JPUFMgaXMgbm90IHNl
dApDT05GSUdfRkJfREVGRVJSRURfSU89eQojIENPTkZJR19GQl9TVkdBTElCIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkJfTUFDTU9ERVMgaXMgbm90IHNldAojIENPTkZJR19GQl9CQUNLTElHSFQgaXMg
bm90IHNldApDT05GSUdfRkJfTU9ERV9IRUxQRVJTPXkKQ09ORklHX0ZCX1RJTEVCTElUVElORz15
CgojCiMgRnJhbWUgYnVmZmVyIGhhcmR3YXJlIGRyaXZlcnMKIwojIENPTkZJR19GQl9DSVJSVVMg
aXMgbm90IHNldAojIENPTkZJR19GQl9QTTIgaXMgbm90IHNldAojIENPTkZJR19GQl9DWUJFUjIw
MDAgaXMgbm90IHNldAojIENPTkZJR19GQl9BUkMgaXMgbm90IHNldAojIENPTkZJR19GQl9BU0lM
SUFOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0lNU1RUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
VkdBMTYgaXMgbm90IHNldAojIENPTkZJR19GQl9VVkVTQSBpcyBub3Qgc2V0CkNPTkZJR19GQl9W
RVNBPXkKIyBDT05GSUdfRkJfTjQxMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0hHQSBpcyBub3Qg
c2V0CiMgQ09ORklHX0ZCX1MxRDEzWFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTlZJRElBIGlz
IG5vdCBzZXQKIyBDT05GSUdfRkJfUklWQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0k3NDAgaXMg
bm90IHNldAojIENPTkZJR19GQl9MRTgwNTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTUFUUk9Y
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUkFERU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZ
MTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUzMg
aXMgbm90IHNldAojIENPTkZJR19GQl9TQVZBR0UgaXMgbm90IHNldAojIENPTkZJR19GQl9TSVMg
aXMgbm90IHNldAojIENPTkZJR19GQl9WSUEgaXMgbm90IHNldAojIENPTkZJR19GQl9ORU9NQUdJ
QyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0tZUk8gaXMgbm90IHNldAojIENPTkZJR19GQl8zREZY
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVk9PRE9PMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1ZU
ODYyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1RSSURFTlQgaXMgbm90IHNldAojIENPTkZJR19G
Ql9BUksgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTMgaXMgbm90IHNldAojIENPTkZJR19GQl9D
QVJNSU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfR0VPREUgaXMgbm90IHNldAojIENPTkZJR19G
Ql9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBpcyBub3Qgc2V0CkNPTkZJR19G
Ql9VREw9eQojIENPTkZJR19GQl9WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9G
Uk9OVEVORD15CiMgQ09ORklHX0ZCX01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01C
ODYyWFggaXMgbm90IHNldAojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05G
SUdfRkJfQVVPX0sxOTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhZTk9TX1ZJREVPIGlzIG5vdCBz
ZXQKQ09ORklHX0JBQ0tMSUdIVF9MQ0RfU1VQUE9SVD15CiMgQ09ORklHX0xDRF9DTEFTU19ERVZJ
Q0UgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0NMQVNTX0RFVklDRT15CkNPTkZJR19CQUNL
TElHSFRfR0VORVJJQz15CiMgQ09ORklHX0JBQ0tMSUdIVF9BUFBMRSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBQ0tMSUdIVF9TQUhBUkEgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfQURQODg2
MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BRFA4ODcwIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkFDS0xJR0hUX0xNMzYzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9MTTM2Mzkg
aXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTFA4NTVYIGlzIG5vdCBzZXQKCiMKIyBDb25z
b2xlIGRpc3BsYXkgZHJpdmVyIHN1cHBvcnQKIwpDT05GSUdfVkdBX0NPTlNPTEU9eQpDT05GSUdf
VkdBQ09OX1NPRlRfU0NST0xMQkFDSz15CkNPTkZJR19WR0FDT05fU09GVF9TQ1JPTExCQUNLX1NJ
WkU9NjQKQ09ORklHX0RVTU1ZX0NPTlNPTEU9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFX0RFVEVDVF9QUklNQVJZPXkKIyBDT05GSUdfRlJB
TUVCVUZGRVJfQ09OU09MRV9ST1RBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRTIGlzIG5v
dCBzZXQKQ09ORklHX0ZPTlRfOHg4PXkKQ09ORklHX0ZPTlRfOHgxNj15CkNPTkZJR19MT0dPPXkK
IyBDT05GSUdfTE9HT19MSU5VWF9NT05PIGlzIG5vdCBzZXQKIyBDT05GSUdfTE9HT19MSU5VWF9W
R0ExNiBpcyBub3Qgc2V0CkNPTkZJR19MT0dPX0xJTlVYX0NMVVQyMjQ9eQpDT05GSUdfU09VTkQ9
eQpDT05GSUdfU09VTkRfT1NTX0NPUkU9eQpDT05GSUdfU09VTkRfT1NTX0NPUkVfUFJFQ0xBSU09
eQpDT05GSUdfU05EPXkKQ09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRfUENNPXkKQ09ORklH
X1NORF9IV0RFUD15CkNPTkZJR19TTkRfUkFXTUlEST15CkNPTkZJR19TTkRfU0VRVUVOQ0VSPXkK
Q09ORklHX1NORF9TRVFfRFVNTVk9eQpDT05GSUdfU05EX09TU0VNVUw9eQpDT05GSUdfU05EX01J
WEVSX09TUz15CkNPTkZJR19TTkRfUENNX09TUz15CkNPTkZJR19TTkRfUENNX09TU19QTFVHSU5T
PXkKQ09ORklHX1NORF9TRVFVRU5DRVJfT1NTPXkKQ09ORklHX1NORF9IUlRJTUVSPXkKQ09ORklH
X1NORF9TRVFfSFJUSU1FUl9ERUZBVUxUPXkKQ09ORklHX1NORF9EWU5BTUlDX01JTk9SUz15CkNP
TkZJR19TTkRfU1VQUE9SVF9PTERfQVBJPXkKQ09ORklHX1NORF9WRVJCT1NFX1BST0NGUz15CiMg
Q09ORklHX1NORF9WRVJCT1NFX1BSSU5USyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9ERUJVRyBp
cyBub3Qgc2V0CkNPTkZJR19TTkRfVk1BU1RFUj15CkNPTkZJR19TTkRfS0NUTF9KQUNLPXkKQ09O
RklHX1NORF9ETUFfU0dCVUY9eQpDT05GSUdfU05EX1JBV01JRElfU0VRPXkKQ09ORklHX1NORF9P
UEwzX0xJQl9TRVE9eQojIENPTkZJR19TTkRfT1BMNF9MSUJfU0VRIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX1NCQVdFX1NFUSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9FTVUxMEsxX1NFUSBpcyBu
b3Qgc2V0CkNPTkZJR19TTkRfTVBVNDAxX1VBUlQ9eQpDT05GSUdfU05EX09QTDNfTElCPXkKQ09O
RklHX1NORF9EUklWRVJTPXkKIyBDT05GSUdfU05EX1BDU1AgaXMgbm90IHNldAojIENPTkZJR19T
TkRfRFVNTVkgaXMgbm90IHNldAojIENPTkZJR19TTkRfQUxPT1AgaXMgbm90IHNldAojIENPTkZJ
R19TTkRfVklSTUlESSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9NVFBBViBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9TRVJJQUxfVTE2NTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01QVTQwMSBp
cyBub3Qgc2V0CkNPTkZJR19TTkRfUENJPXkKIyBDT05GSUdfU05EX0FEMTg4OSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NORF9BTFMzMDAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQUxTNDAwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9BTEk1NDUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FTSUhQ
SSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BVElJWFAgaXMgbm90IHNldAojIENPTkZJR19TTkRf
QVRJSVhQX01PREVNIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVODgxMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9BVTg4MjAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODMwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU05EX0FXMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BWlQzMzI4IGlzIG5v
dCBzZXQKIyBDT05GSUdfU05EX0JUODdYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0NBMDEwNiBp
cyBub3Qgc2V0CkNPTkZJR19TTkRfQ01JUENJPXkKQ09ORklHX1NORF9PWFlHRU5fTElCPXkKQ09O
RklHX1NORF9PWFlHRU49eQojIENPTkZJR19TTkRfQ1M0MjgxIGlzIG5vdCBzZXQKIyBDT05GSUdf
U05EX0NTNDZYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzU1MzAgaXMgbm90IHNldAojIENP
TkZJR19TTkRfQ1M1NTM1QVVESU8gaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1RYRkkgaXMgbm90
IHNldAojIENPTkZJR19TTkRfREFSTEEyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9HSU5BMjAg
aXMgbm90IHNldAojIENPTkZJR19TTkRfTEFZTEEyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E
QVJMQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dJTkEyNCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9MQVlMQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01PTkEgaXMgbm90IHNldAojIENP
TkZJR19TTkRfTUlBIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VDSE8zRyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9JTkRJR08gaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdPSU8gaXMgbm90
IHNldAojIENPTkZJR19TTkRfSU5ESUdPREogaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdP
SU9YIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lORElHT0RKWCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9FTVUxMEsxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VNVTEwSzFYIGlzIG5vdCBzZXQK
IyBDT05GSUdfU05EX0VOUzEzNzAgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9FUzE5MzggaXMgbm90IHNldAojIENPTkZJR19TTkRfRVMxOTY4
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0ZNODAxIGlzIG5vdCBzZXQKQ09ORklHX1NORF9IREFf
SU5URUw9eQpDT05GSUdfU05EX0hEQV9QUkVBTExPQ19TSVpFPTY0CkNPTkZJR19TTkRfSERBX0hX
REVQPXkKIyBDT05GSUdfU05EX0hEQV9SRUNPTkZJRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9I
REFfSU5QVVRfQkVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9IREFfSU5QVVRfSkFDSyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9IREFfUEFUQ0hfTE9BREVSIGlzIG5vdCBzZXQKQ09ORklHX1NO
RF9IREFfQ09ERUNfUkVBTFRFSz15CkNPTkZJR19TTkRfSERBX0NPREVDX0FOQUxPRz15CkNPTkZJ
R19TTkRfSERBX0NPREVDX1NJR01BVEVMPXkKQ09ORklHX1NORF9IREFfQ09ERUNfVklBPXkKQ09O
RklHX1NORF9IREFfQ09ERUNfSERNST15CkNPTkZJR19TTkRfSERBX0NPREVDX0NJUlJVUz15CkNP
TkZJR19TTkRfSERBX0NPREVDX0NPTkVYQU5UPXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ0EwMTEw
PXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ0EwMTMyPXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ01F
RElBPXkKQ09ORklHX1NORF9IREFfQ09ERUNfU0kzMDU0PXkKQ09ORklHX1NORF9IREFfR0VORVJJ
Qz15CkNPTkZJR19TTkRfSERBX1BPV0VSX1NBVkVfREVGQVVMVD0wCiMgQ09ORklHX1NORF9IRFNQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0hEU1BNIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lD
RTE3MTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfSUNFMTcyNCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9JTlRFTDhYMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTlRFTDhYME0gaXMgbm90IHNl
dAojIENPTkZJR19TTkRfS09SRzEyMTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfTE9MQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9MWDY0NjRFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9NQUVT
VFJPMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9NSVhBUlQgaXMgbm90IHNldAojIENPTkZJR19T
TkRfTk0yNTYgaXMgbm90IHNldAojIENPTkZJR19TTkRfUENYSFIgaXMgbm90IHNldAojIENPTkZJ
R19TTkRfUklQVElERSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUUzMiBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9STUU5NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUU5NjUyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU05EX1NPTklDVklCRVMgaXMgbm90IHNldAojIENPTkZJR19TTkRfVFJJREVO
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WSUE4MlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E
X1ZJQTgyWFhfTU9ERU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfVklSVFVPU08gaXMgbm90IHNl
dAojIENPTkZJR19TTkRfVlgyMjIgaXMgbm90IHNldAojIENPTkZJR19TTkRfWU1GUENJIGlzIG5v
dCBzZXQKQ09ORklHX1NORF9VU0I9eQpDT05GSUdfU05EX1VTQl9BVURJTz15CkNPTkZJR19TTkRf
VVNCX1VBMTAxPXkKQ09ORklHX1NORF9VU0JfVVNYMlk9eQpDT05GSUdfU05EX1VTQl9DQUlBUT15
CkNPTkZJR19TTkRfVVNCX0NBSUFRX0lOUFVUPXkKIyBDT05GSUdfU05EX1VTQl9VUzEyMkwgaXMg
bm90IHNldApDT05GSUdfU05EX1VTQl82RklSRT15CiMgQ09ORklHX1NORF9TT0MgaXMgbm90IHNl
dAojIENPTkZJR19TT1VORF9QUklNRSBpcyBub3Qgc2V0CgojCiMgSElEIHN1cHBvcnQKIwpDT05G
SUdfSElEPXkKIyBDT05GSUdfSElEX0JBVFRFUllfU1RSRU5HVEggaXMgbm90IHNldApDT05GSUdf
SElEUkFXPXkKIyBDT05GSUdfVUhJRCBpcyBub3Qgc2V0CkNPTkZJR19ISURfR0VORVJJQz15Cgoj
CiMgU3BlY2lhbCBISUQgZHJpdmVycwojCkNPTkZJR19ISURfQTRURUNIPXkKIyBDT05GSUdfSElE
X0FDUlVYIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9BUFBMRT15CiMgQ09ORklHX0hJRF9BVVJFQUwg
aXMgbm90IHNldApDT05GSUdfSElEX0JFTEtJTj15CkNPTkZJR19ISURfQ0hFUlJZPXkKQ09ORklH
X0hJRF9DSElDT05ZPXkKIyBDT05GSUdfSElEX1BST0RJS0VZUyBpcyBub3Qgc2V0CkNPTkZJR19I
SURfQ1lQUkVTUz15CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FTEVDT00gaXMgbm90IHNldApDT05G
SUdfSElEX0VaS0VZPXkKIyBDT05GSUdfSElEX0hPTFRFSyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJ
RF9LRVlUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LWUUgaXMgbm90IHNldAojIENPTkZJ
R19ISURfVUNMT0dJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XQUxUT1AgaXMgbm90IHNldAoj
IENPTkZJR19ISURfR1lSQVRJT04gaXMgbm90IHNldAojIENPTkZJR19ISURfVFdJTkhBTiBpcyBu
b3Qgc2V0CkNPTkZJR19ISURfS0VOU0lOR1RPTj15CiMgQ09ORklHX0hJRF9MQ1BPV0VSIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX0xFTk9WT19UUEtCRCBpcyBub3Qgc2V0CkNPTkZJR19ISURfTE9H
SVRFQ0g9eQojIENPTkZJR19ISURfTE9HSVRFQ0hfREogaXMgbm90IHNldAojIENPTkZJR19MT0dJ
VEVDSF9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0lSVU1CTEVQQUQyX0ZGIGlzIG5vdCBzZXQK
IyBDT05GSUdfTE9HSUc5NDBfRkYgaXMgbm90IHNldAojIENPTkZJR19MT0dJV0hFRUxTX0ZGIGlz
IG5vdCBzZXQKIyBDT05GSUdfSElEX01BR0lDTU9VU0UgaXMgbm90IHNldApDT05GSUdfSElEX01J
Q1JPU09GVD15CkNPTkZJR19ISURfTU9OVEVSRVk9eQojIENPTkZJR19ISURfTVVMVElUT1VDSCBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9OVFJJRyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9PUlRF
SyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QQU5USEVSTE9SRCBpcyBub3Qgc2V0CiMgQ09ORklH
X0hJRF9QRVRBTFlOWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QSUNPTENEIGlzIG5vdCBzZXQK
IyBDT05GSUdfSElEX1BSSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUzNSRU1PVEUgaXMg
bm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NBSVRF
SyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1NPTlkgaXMgbm90IHNldAojIENPTkZJR19ISURfU1BFRURMSU5LIGlzIG5vdCBzZXQKIyBDT05G
SUdfSElEX1NVTlBMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfR1JFRU5BU0lBIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSElEX1NNQVJUSk9ZUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USVZP
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RPUFNFRUQgaXMgbm90IHNldAojIENPTkZJR19ISURf
VEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBQ09NIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX1dJSU1PVEUgaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BMVVMgaXMgbm90
IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09S
X0hVQiBpcyBub3Qgc2V0CgojCiMgVVNCIEhJRCBzdXBwb3J0CiMKQ09ORklHX1VTQl9ISUQ9eQpD
T05GSUdfSElEX1BJRD15CkNPTkZJR19VU0JfSElEREVWPXkKQ09ORklHX1VTQl9BUkNIX0hBU19P
SENJPXkKQ09ORklHX1VTQl9BUkNIX0hBU19FSENJPXkKQ09ORklHX1VTQl9BUkNIX0hBU19YSENJ
PXkKQ09ORklHX1VTQl9TVVBQT1JUPXkKQ09ORklHX1VTQl9DT01NT049eQpDT05GSUdfVVNCX0FS
Q0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldApD
T05GSUdfVVNCX0FOTk9VTkNFX05FV19ERVZJQ0VTPXkKCiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBv
cHRpb25zCiMKIyBDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKQ09ORklHX1VT
Ql9NT049eQojIENPTkZJR19VU0JfV1VTQl9DQkFGIGlzIG5vdCBzZXQKCiMKIyBVU0IgSG9zdCBD
b250cm9sbGVyIERyaXZlcnMKIwojIENPTkZJR19VU0JfQzY3WDAwX0hDRCBpcyBub3Qgc2V0CkNP
TkZJR19VU0JfWEhDSV9IQ0Q9eQojIENPTkZJR19VU0JfWEhDSV9IQ0RfREVCVUdHSU5HIGlzIG5v
dCBzZXQKQ09ORklHX1VTQl9FSENJX0hDRD15CkNPTkZJR19VU0JfRUhDSV9ST09UX0hVQl9UVD15
CkNPTkZJR19VU0JfRUhDSV9UVF9ORVdTQ0hFRD15CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9IQ0Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19V
U0JfSVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0QgaXMgbm90
IHNldApDT05GSUdfVVNCX09IQ0lfSENEPXkKIyBDT05GSUdfVVNCX09IQ0lfSENEX1BMQVRGT1JN
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0VIQ0lfSENEX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9ERVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09I
Q0lfQklHX0VORElBTl9NTUlPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0xJVFRMRV9FTkRJ
QU49eQpDT05GSUdfVVNCX1VIQ0lfSENEPXkKIyBDT05GSUdfVVNCX1NMODExX0hDRCBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfQ0hJ
UElERUEgaXMgbm90IHNldAoKIwojIFVTQiBEZXZpY2UgQ2xhc3MgZHJpdmVycwojCiMgQ09ORklH
X1VTQl9BQ00gaXMgbm90IHNldApDT05GSUdfVVNCX1BSSU5URVI9eQojIENPTkZJR19VU0JfV0RN
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RNQyBpcyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NU
T1JBR0UgZGVwZW5kcyBvbiBTQ1NJIGJ1dCBCTEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBu
ZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBIZWxwIGZvciBtb3JlIGluZm8KIwpDT05GSUdfVVNCX1NU
T1JBR0U9eQojIENPTkZJR19VU0JfU1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVE9SQUdFX1JFQUxURUsgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFC
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TVE9SQUdFX0lTRDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VT
QkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NUT1JBR0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0Vf
SlVNUFNIT1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T
VE9SQUdFX0tBUk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVTU19BVEFD
QiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0VORV9VQjYyNTAgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfVUFTIGlzIG5vdCBzZXQKCiMKIyBVU0IgSW1hZ2luZyBkZXZpY2VzCiMKIyBD
T05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NSUNST1RFSyBpcyBub3Qg
c2V0CgojCiMgVVNCIHBvcnQgZHJpdmVycwojCkNPTkZJR19VU0JfU0VSSUFMPXkKQ09ORklHX1VT
Ql9TRVJJQUxfQ09OU09MRT15CkNPTkZJR19VU0JfU0VSSUFMX0dFTkVSSUM9eQojIENPTkZJR19V
U0JfU0VSSUFMX0FJUkNBQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9BUkszMTE2
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9CRUxLSU4gaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU0VSSUFMX0NIMzQxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9XSElURUhF
QVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0RJR0lfQUNDRUxFUE9SVCBpcyBub3Qg
c2V0CkNPTkZJR19VU0JfU0VSSUFMX0NQMjEwWD15CkNPTkZJR19VU0JfU0VSSUFMX0NZUFJFU1Nf
TTg9eQojIENPTkZJR19VU0JfU0VSSUFMX0VNUEVHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF
UklBTF9GVERJX1NJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRlVOU09GVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfVklTT1IgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
U0VSSUFMX0lQQVEgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX1NFUklBTF9FREdFUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ
QUxfRURHRVBPUlRfVEkgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0Y4MTIzMiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfR0FSTUlOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NFUklBTF9JUFcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lVVSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTl9QREEgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
U0VSSUFMX0tFWVNQQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tMU0kgaXMgbm90
IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tPQklMX1NDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TRVJJQUxfTUNUX1UyMzIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01FVFJPIGlz
IG5vdCBzZXQKQ09ORklHX1VTQl9TRVJJQUxfTU9TNzcyMD15CkNPTkZJR19VU0JfU0VSSUFMX01P
Uzc4NDA9eQojIENPTkZJR19VU0JfU0VSSUFMX01PVE9ST0xBIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NFUklBTF9OQVZNQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1BMMjMwMyBp
cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfT1RJNjg1OCBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9TRVJJQUxfUUNBVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1FVQUxDT01N
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TUENQOFg1IGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1NFUklBTF9IUDRYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TQUZFIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TSUVNRU5TX01QSSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TRVJJQUxfU0lFUlJBV0lSRUxFU1MgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX1NZTUJPTCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfVEkgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfU0VSSUFMX0NZQkVSSkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ
QUxfWElSQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9PUFRJT04gaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU0VSSUFMX09NTklORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX09QVElDT04gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1ZJVk9QQVlfU0VSSUFM
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9aSU8gaXMgbm90IHNldAojIENPTkZJR19V
U0JfU0VSSUFMX1pURSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU1NVMTAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9RVDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBVU0IgTWlzY2VsbGFuZW91cyBkcml2ZXJzCiMKIyBD
T05GSUdfVVNCX0VNSTYyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0VNSTI2IGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0FEVVRVWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVZTRUcgaXMgbm90
IHNldAojIENPTkZJR19VU0JfUklPNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0xFR09UT1dF
UiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEVE
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NZUFJFU1NfQ1k3QzYzIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX0NZVEhFUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfSURNT1VTRSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9GVERJX0VMQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfQVBQTEVESVNQ
TEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NJU1VTQlZHQSBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9MRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9UUkFOQ0VWSUJSQVRPUiBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9JT1dBUlJJT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfVEVTVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9JU0lHSFRGVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ZVVJF
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FWlVTQl9GWDIgaXMgbm90IHNldAoKIwojIFVTQiBQ
aHlzaWNhbCBMYXllciBkcml2ZXJzCiMKIyBDT05GSUdfT01BUF9VU0IyIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBz
ZXQKCiMKIyBPVEcgYW5kIHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNC
X1hDRUlWIGlzIG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlz
IG5vdCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpD
T05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xNMzUz
MCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVE
U19QQ0E5NTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDM5NDQgaXMgbm90IHNldAojIENP
TkZJR19MRURTX0xQNTUyMSBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1NTIzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTEVEU19DTEVWT19NQUlMIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5
NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5NjMzIGlzIG5vdCBzZXQKIyBDT05GSUdf
TEVEU19CRDI4MDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX0lOVEVMX1NTNDIwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX0xFRFNfVENBNjUwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTV4
IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19PVDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNf
QkxJTktNIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSUyBpcyBub3Qgc2V0CgojCiMg
TEVEIFRyaWdnZXJzCiMKIyBDT05GSUdfQUNDRVNTSUJJTElUWSBpcyBub3Qgc2V0CiMgQ09ORklH
X0lORklOSUJBTkQgaXMgbm90IHNldAojIENPTkZJR19FREFDIGlzIG5vdCBzZXQKQ09ORklHX1JU
Q19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkKIyBDT05GSUdfUlRDX0hDVE9TWVMgaXMgbm90IHNl
dAojIENPTkZJR19SVENfREVCVUcgaXMgbm90IHNldAoKIwojIFJUQyBpbnRlcmZhY2VzCiMKQ09O
RklHX1JUQ19JTlRGX1NZU0ZTPXkKQ09ORklHX1JUQ19JTlRGX1BST0M9eQpDT05GSUdfUlRDX0lO
VEZfREVWPXkKIyBDT05GSUdfUlRDX0lOVEZfREVWX1VJRV9FTVVMIGlzIG5vdCBzZXQKIyBDT05G
SUdfUlRDX0RSVl9URVNUIGlzIG5vdCBzZXQKCiMKIyBJMkMgUlRDIGRyaXZlcnMKIwojIENPTkZJ
R19SVENfRFJWX0RTMTMwNyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzc0IGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE2NzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X0RTMzIzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTUFYNjkwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JUQ19EUlZfUlM1QzM3MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIw
OCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwMjIgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1gxMjA1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTYzIGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS
Vl9NNDFUODAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRMzJLIGlzIG5vdCBzZXQKIyBD
T05GSUdfUlRDX0RSVl9TMzUzOTBBIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9GTTMxMzAg
aXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODU4MSBpcyBub3Qgc2V0CiMgQ09ORklHX1JU
Q19EUlZfUlg4MDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9FTTMwMjcgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX1JWMzAyOUMyIGlzIG5vdCBzZXQKCiMKIyBTUEkgUlRDIGRyaXZl
cnMKIwoKIwojIFBsYXRmb3JtIFJUQyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfQ01PUz15CiMg
Q09ORklHX1JUQ19EUlZfRFMxMjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEg
aXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTU1MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JU
Q19EUlZfRFMxNzQyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9TVEsxN1RBOCBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9N
NDhUMzUgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX000OFQ1OSBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUQ19EUlZfTVNNNjI0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfQlE0ODAyIGlz
IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SUDVDMDEgaXMgbm90IHNldAojIENPTkZJR19SVENf
RFJWX1YzMDIwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzI0MDQgaXMgbm90IHNldAoK
IwojIG9uLUNQVSBSVEMgZHJpdmVycwojCiMgQ09ORklHX0RNQURFVklDRVMgaXMgbm90IHNldAoj
IENPTkZJR19BVVhESVNQTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPIGlzIG5vdCBzZXQKIyBD
T05GSUdfVkZJTyBpcyBub3Qgc2V0CgojCiMgVmlydGlvIGRyaXZlcnMKIwojIENPTkZJR19WSVJU
SU9fUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldAoKIwojIE1p
Y3Jvc29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQKIwojIENPTkZJR19IWVBFUlYgaXMgbm90IHNl
dAoKIwojIFhlbiBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19YRU5fQkFMTE9PTj15CkNPTkZJR19Y
RU5fU0NSVUJfUEFHRVM9eQpDT05GSUdfWEVOX0RFVl9FVlRDSE49eQpDT05GSUdfWEVOX0JBQ0tF
TkQ9eQpDT05GSUdfWEVORlM9eQpDT05GSUdfWEVOX0NPTVBBVF9YRU5GUz15CkNPTkZJR19YRU5f
U1lTX0hZUEVSVklTT1I9eQpDT05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD15CkNPTkZJR19YRU5f
R05UREVWPXkKQ09ORklHX1hFTl9HUkFOVF9ERVZfQUxMT0M9eQpDT05GSUdfU1dJT1RMQl9YRU49
eQpDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKQ09ORklHX1hFTl9QUklWQ01EPXkKQ09ORklH
X1hFTl9BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19YRU5fTUNFX0xPRz15CiMgQ09ORklHX1NUQUdJ
TkcgaXMgbm90IHNldAojIENPTkZJR19YODZfUExBVEZPUk1fREVWSUNFUyBpcyBub3Qgc2V0Cgoj
CiMgSGFyZHdhcmUgU3BpbmxvY2sgZHJpdmVycwojCkNPTkZJR19DTEtFVlRfSTgyNTM9eQpDT05G
SUdfSTgyNTNfTE9DSz15CkNPTkZJR19DTEtCTERfSTgyNTM9eQpDT05GSUdfSU9NTVVfQVBJPXkK
Q09ORklHX0lPTU1VX1NVUFBPUlQ9eQpDT05GSUdfQU1EX0lPTU1VPXkKQ09ORklHX0FNRF9JT01N
VV9TVEFUUz15CiMgQ09ORklHX0lOVEVMX0lPTU1VIGlzIG5vdCBzZXQKIyBDT05GSUdfSVJRX1JF
TUFQIGlzIG5vdCBzZXQKCiMKIyBSZW1vdGVwcm9jIGRyaXZlcnMgKEVYUEVSSU1FTlRBTCkKIwoj
IENPTkZJR19TVEVfTU9ERU1fUlBST0MgaXMgbm90IHNldAoKIwojIFJwbXNnIGRyaXZlcnMgKEVY
UEVSSU1FTlRBTCkKIwojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMgbm90IHNldAojIENPTkZJR19Q
TV9ERVZGUkVRIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09OIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUVNT1JZIGlzIG5vdCBzZXQKIyBDT05GSUdfSUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfVk1FX0JV
UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BXTSBpcyBub3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVy
cwojCiMgQ09ORklHX0VERCBpcyBub3Qgc2V0CkNPTkZJR19GSVJNV0FSRV9NRU1NQVA9eQojIENP
TkZJR19ERUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CkNPTkZJ
R19ETUlJRD15CkNPTkZJR19ETUlfU1lTRlM9eQojIENPTkZJR19JU0NTSV9JQkZUX0ZJTkQgaXMg
bm90IHNldAojIENPTkZJR19HT09HTEVfRklSTVdBUkUgaXMgbm90IHNldAoKIwojIEZpbGUgc3lz
dGVtcwojCkNPTkZJR19EQ0FDSEVfV09SRF9BQ0NFU1M9eQojIENPTkZJR19FWFQyX0ZTIGlzIG5v
dCBzZXQKQ09ORklHX0VYVDNfRlM9eQojIENPTkZJR19FWFQzX0RFRkFVTFRTX1RPX09SREVSRUQg
aXMgbm90IHNldApDT05GSUdfRVhUM19GU19YQVRUUj15CkNPTkZJR19FWFQzX0ZTX1BPU0lYX0FD
TD15CkNPTkZJR19FWFQzX0ZTX1NFQ1VSSVRZPXkKQ09ORklHX0VYVDRfRlM9eQpDT05GSUdfRVhU
NF9VU0VfRk9SX0VYVDIzPXkKQ09ORklHX0VYVDRfRlNfWEFUVFI9eQojIENPTkZJR19FWFQ0X0ZT
X1BPU0lYX0FDTCBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfRlNfU0VDVVJJVFkgaXMgbm90IHNl
dApDT05GSUdfRVhUNF9ERUJVRz15CkNPTkZJR19KQkQ9eQojIENPTkZJR19KQkRfREVCVUcgaXMg
bm90IHNldApDT05GSUdfSkJEMj15CkNPTkZJR19KQkQyX0RFQlVHPXkKQ09ORklHX0ZTX01CQ0FD
SEU9eQojIENPTkZJR19SRUlTRVJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0pGU19GUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1hGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0dGUzJfRlMgaXMgbm90
IHNldAojIENPTkZJR19CVFJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9GUyBpcyBu
b3Qgc2V0CkNPTkZJR19GU19QT1NJWF9BQ0w9eQpDT05GSUdfRklMRV9MT0NLSU5HPXkKQ09ORklH
X0ZTTk9USUZZPXkKQ09ORklHX0ROT1RJRlk9eQpDT05GSUdfSU5PVElGWV9VU0VSPXkKIyBDT05G
SUdfRkFOT1RJRlkgaXMgbm90IHNldApDT05GSUdfUVVPVEE9eQpDT05GSUdfUVVPVEFfTkVUTElO
S19JTlRFUkZBQ0U9eQojIENPTkZJR19QUklOVF9RVU9UQV9XQVJOSU5HIGlzIG5vdCBzZXQKIyBD
T05GSUdfUVVPVEFfREVCVUcgaXMgbm90IHNldApDT05GSUdfUVVPVEFfVFJFRT15CiMgQ09ORklH
X1FGTVRfVjEgaXMgbm90IHNldApDT05GSUdfUUZNVF9WMj15CkNPTkZJR19RVU9UQUNUTD15CkNP
TkZJR19RVU9UQUNUTF9DT01QQVQ9eQpDT05GSUdfQVVUT0ZTNF9GUz15CkNPTkZJR19GVVNFX0ZT
PXkKIyBDT05GSUdfQ1VTRSBpcyBub3Qgc2V0CkNPTkZJR19HRU5FUklDX0FDTD15CgojCiMgQ2Fj
aGVzCiMKIyBDT05GSUdfRlNDQUNIRSBpcyBub3Qgc2V0CgojCiMgQ0QtUk9NL0RWRCBGaWxlc3lz
dGVtcwojCkNPTkZJR19JU085NjYwX0ZTPXkKQ09ORklHX0pPTElFVD15CkNPTkZJR19aSVNPRlM9
eQojIENPTkZJR19VREZfRlMgaXMgbm90IHNldAoKIwojIERPUy9GQVQvTlQgRmlsZXN5c3RlbXMK
IwpDT05GSUdfRkFUX0ZTPXkKQ09ORklHX01TRE9TX0ZTPXkKQ09ORklHX1ZGQVRfRlM9eQpDT05G
SUdfRkFUX0RFRkFVTFRfQ09ERVBBR0U9NDM3CkNPTkZJR19GQVRfREVGQVVMVF9JT0NIQVJTRVQ9
Imlzbzg4NTktMSIKQ09ORklHX05URlNfRlM9eQojIENPTkZJR19OVEZTX0RFQlVHIGlzIG5vdCBz
ZXQKQ09ORklHX05URlNfUlc9eQoKIwojIFBzZXVkbyBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9D
X0ZTPXkKQ09ORklHX1BST0NfS0NPUkU9eQpDT05GSUdfUFJPQ19WTUNPUkU9eQpDT05GSUdfUFJP
Q19TWVNDVEw9eQpDT05GSUdfUFJPQ19QQUdFX01PTklUT1I9eQpDT05GSUdfU1lTRlM9eQpDT05G
SUdfVE1QRlM9eQpDT05GSUdfVE1QRlNfUE9TSVhfQUNMPXkKQ09ORklHX1RNUEZTX1hBVFRSPXkK
Q09ORklHX0hVR0VUTEJGUz15CkNPTkZJR19IVUdFVExCX1BBR0U9eQojIENPTkZJR19DT05GSUdG
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX01JU0NfRklMRVNZU1RFTVMgaXMgbm90IHNldAojIENP
TkZJR19ORVRXT1JLX0ZJTEVTWVNURU1TIGlzIG5vdCBzZXQKQ09ORklHX05MUz15CkNPTkZJR19O
TFNfREVGQVVMVD0idXRmOCIKQ09ORklHX05MU19DT0RFUEFHRV80Mzc9eQojIENPTkZJR19OTFNf
Q09ERVBBR0VfNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzc3NSBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E
RVBBR0VfODUyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NSBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTcgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB
R0VfODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0CiMg
Q09ORklHX05MU19DT0RFUEFHRV84NjIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf
ODYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NCBpcyBub3Qgc2V0CiMgQ09O
RklHX05MU19DT0RFUEFHRV84NjUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODY2
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0CiMgQ09ORklH
X05MU19DT0RFUEFHRV85MzYgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfOTUwIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzMiBpcyBub3Qgc2V0CiMgQ09ORklHX05M
U19DT0RFUEFHRV85NDkgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODc0IGlzIG5v
dCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfOCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RF
UEFHRV8xMjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTEgaXMgbm90IHNl
dApDT05GSUdfTkxTX0FTQ0lJPXkKQ09ORklHX05MU19JU084ODU5XzE9eQojIENPTkZJR19OTFNf
SVNPODg1OV8yIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0CiMg
Q09ORklHX05MU19JU084ODU5XzQgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV81IGlz
IG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J
U084ODU5XzcgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQKIyBD
T05GSUdfTkxTX0lTTzg4NTlfMTMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xNCBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X0tPSThfUiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1UgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfTUFDX1JPTUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19DRUxUSUMgaXMgbm90
IHNldAojIENPTkZJR19OTFNfTUFDX0NFTlRFVVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01B
Q19DUk9BVElBTiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfQ1lSSUxMSUMgaXMgbm90IHNl
dAojIENPTkZJR19OTFNfTUFDX0dBRUxJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfR1JF
RUsgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0lDRUxBTkQgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfTUFDX0lOVUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19ST01BTklBTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX05MU19NQUNfVFVSS0lTSCBpcyBub3Qgc2V0CkNPTkZJR19OTFNfVVRG
OD15CgojCiMgS2VybmVsIGhhY2tpbmcKIwpDT05GSUdfVFJBQ0VfSVJRRkxBR1NfU1VQUE9SVD15
CkNPTkZJR19QUklOVEtfVElNRT15CkNPTkZJR19ERUZBVUxUX01FU1NBR0VfTE9HTEVWRUw9Ngoj
IENPTkZJR19FTkFCTEVfV0FSTl9ERVBSRUNBVEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfRU5BQkxF
X01VU1RfQ0hFQ0sgaXMgbm90IHNldApDT05GSUdfRlJBTUVfV0FSTj0yMDQ4CkNPTkZJR19NQUdJ
Q19TWVNSUT15CiMgQ09ORklHX1NUUklQX0FTTV9TWU1TIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVB
REFCTEVfQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVU5VU0VEX1NZTUJPTFMgaXMgbm90IHNldApD
T05GSUdfREVCVUdfRlM9eQojIENPTkZJR19IRUFERVJTX0NIRUNLIGlzIG5vdCBzZXQKIyBDT05G
SUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19LRVJORUw9
eQpDT05GSUdfREVCVUdfU0hJUlE9eQpDT05GSUdfTE9DS1VQX0RFVEVDVE9SPXkKQ09ORklHX0hB
UkRMT0NLVVBfREVURUNUT1I9eQojIENPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQyBp
cyBub3Qgc2V0CkNPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQ19WQUxVRT0wCiMgQ09O
RklHX0JPT1RQQVJBTV9TT0ZUTE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklHX0JPT1RQQVJB
TV9TT0ZUTE9DS1VQX1BBTklDX1ZBTFVFPTAKIyBDT05GSUdfUEFOSUNfT05fT09QUyBpcyBub3Qg
c2V0CkNPTkZJR19QQU5JQ19PTl9PT1BTX1ZBTFVFPTAKQ09ORklHX0RFVEVDVF9IVU5HX1RBU0s9
eQpDT05GSUdfREVGQVVMVF9IVU5HX1RBU0tfVElNRU9VVD0xMjAKIyBDT05GSUdfQk9PVFBBUkFN
X0hVTkdfVEFTS19QQU5JQyBpcyBub3Qgc2V0CkNPTkZJR19CT09UUEFSQU1fSFVOR19UQVNLX1BB
TklDX1ZBTFVFPTAKIyBDT05GSUdfU0NIRURfREVCVUcgaXMgbm90IHNldApDT05GSUdfU0NIRURT
VEFUUz15CkNPTkZJR19USU1FUl9TVEFUUz15CiMgQ09ORklHX0RFQlVHX09CSkVDVFMgaXMgbm90
IHNldAojIENPTkZJR19TTFVCX0RFQlVHX09OIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xVQl9TVEFU
UyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0RFQlVHX0tNRU1MRUFLPXkKIyBDT05GSUdfREVCVUdf
S01FTUxFQUsgaXMgbm90IHNldApDT05GSUdfREVCVUdfUFJFRU1QVD15CkNPTkZJR19ERUJVR19S
VF9NVVRFWEVTPXkKQ09ORklHX0RFQlVHX1BJX0xJU1Q9eQojIENPTkZJR19SVF9NVVRFWF9URVNU
RVIgaXMgbm90IHNldApDT05GSUdfREVCVUdfU1BJTkxPQ0s9eQpDT05GSUdfREVCVUdfTVVURVhF
Uz15CkNPTkZJR19ERUJVR19MT0NLX0FMTE9DPXkKQ09ORklHX1BST1ZFX0xPQ0tJTkc9eQojIENP
TkZJR19QUk9WRV9SQ1UgaXMgbm90IHNldAojIENPTkZJR19QUk9WRV9SQ1VfREVMQVkgaXMgbm90
IHNldApDT05GSUdfU1BBUlNFX1JDVV9QT0lOVEVSPXkKQ09ORklHX0xPQ0tERVA9eQojIENPTkZJ
R19MT0NLX1NUQVQgaXMgbm90IHNldApDT05GSUdfREVCVUdfTE9DS0RFUD15CkNPTkZJR19UUkFD
RV9JUlFGTEFHUz15CiMgQ09ORklHX0RFQlVHX0FUT01JQ19TTEVFUCBpcyBub3Qgc2V0CiMgQ09O
RklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNUUyBpcyBub3Qgc2V0CkNPTkZJR19TVEFDS1RS
QUNFPXkKIyBDT05GSUdfREVCVUdfU1RBQ0tfVVNBR0UgaXMgbm90IHNldAojIENPTkZJR19ERUJV
R19LT0JKRUNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0JVR1ZFUkJPU0U9eQpDT05GSUdfREVC
VUdfSU5GTz15CiMgQ09ORklHX0RFQlVHX0lORk9fUkVEVUNFRCBpcyBub3Qgc2V0CiMgQ09ORklH
X0RFQlVHX1ZNIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVklSVFVBTCBpcyBub3Qgc2V0CkNP
TkZJR19ERUJVR19XUklURUNPVU5UPXkKQ09ORklHX0RFQlVHX01FTU9SWV9JTklUPXkKQ09ORklH
X0RFQlVHX0xJU1Q9eQojIENPTkZJR19URVNUX0xJU1RfU09SVCBpcyBub3Qgc2V0CkNPTkZJR19E
RUJVR19TRz15CiMgQ09ORklHX0RFQlVHX05PVElGSUVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RF
QlVHX0NSRURFTlRJQUxTIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfV0FOVF9GUkFNRV9QT0lOVEVS
Uz15CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkKIyBDT05GSUdfQk9PVF9QUklOVEtfREVMQVkgaXMg
bm90IHNldAojIENPTkZJR19SQ1VfVE9SVFVSRV9URVNUIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9D
UFVfU1RBTExfVElNRU9VVD02MApDT05GSUdfUkNVX0NQVV9TVEFMTF9WRVJCT1NFPXkKQ09ORklH
X1JDVV9DUFVfU1RBTExfSU5GTz15CiMgQ09ORklHX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBQ0tUUkFDRV9TRUxGX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19CTE9DS19F
WFRfREVWVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0ZPUkNFX1dFQUtfUEVSX0NQVSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BFUl9DUFVfTUFQUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xL
RFRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9USUZJRVJfRVJST1JfSU5KRUNUSU9OIGlzIG5vdCBz
ZXQKIyBDT05GSUdfRkFVTFRfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFURU5DWVRP
UCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BBR0VBTExPQyBpcyBub3Qgc2V0CkNPTkZJR19V
U0VSX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNP
TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dS
QVBIX0ZQX1RFU1Q9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRV9NQ09VTlRfVEVTVD15CkNP
TkZJR19IQVZFX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0hBVkVfRlRSQUNFX01DT1VOVF9SRUNP
UkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9JTlRTPXkKQ09ORklHX0hBVkVfRkVOVFJZ
PXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0lOR19TVVBQT1JUPXkK
IyBDT05GSUdfRlRSQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfUkJUUkVFX1RFU1QgaXMgbm90IHNl
dAojIENPTkZJR19JTlRFUlZBTF9UUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19QUk9WSURF
X09IQ0kxMzk0X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19ERUJVRyBpcyBu
b3Qgc2V0CkNPTkZJR19ETUFfQVBJX0RFQlVHPXkKIyBDT05GSUdfQVRPTUlDNjRfU0VMRlRFU1Qg
aXMgbm90IHNldAojIENPTkZJR19TQU1QTEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJDSF9L
R0RCPXkKIyBDT05GSUdfS0dEQiBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfS01FTUNIRUNL
PXkKIyBDT05GSUdfS01FTUNIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9LU1RSVE9YIGlz
IG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZFUkJPU0VfQk9PVFVQ
PXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BSSU5US19EQkdQIGlzIG5v
dCBzZXQKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4
Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRBPXkKIyBDT05GSUdfREVCVUdf
Uk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TRVRfTU9EVUxFX1JPTlggaXMg
bm90IHNldAojIENPTkZJR19ERUJVR19OWF9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf
VExCRkxVU0ggaXMgbm90IHNldApDT05GSUdfSU9NTVVfREVCVUc9eQojIENPTkZJR19JT01NVV9T
VFJFU1MgaXMgbm90IHNldApDT05GSUdfSU9NTVVfTEVBSz15CkNPTkZJR19IQVZFX01NSU9UUkFD
RV9TVVBQT1JUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxBWV9U
WVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVMQVlf
VFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8wWEVE
IGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdf
SU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MApD
T05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMgbm90IHNldAoj
IENPTkZJR19PUFRJTUlaRV9JTkxJTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NUUklD
VF9VU0VSX0NPUFlfQ0hFQ0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk1JX1NFTEZURVNU
IGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMKIyBDT05GSUdfS0VZUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NFQ1VSSVRZX0RNRVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VDVVJJVFkgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWUZTIGlzIG5vdCBzZXQKQ09ORklH
X0RFRkFVTFRfU0VDVVJJVFlfREFDPXkKQ09ORklHX0RFRkFVTFRfU0VDVVJJVFk9IiIKQ09ORklH
X0NSWVBUTz15CgojCiMgQ3J5cHRvIGNvcmUgb3IgaGVscGVyCiMKQ09ORklHX0NSWVBUT19BTEdB
UEk9eQpDT05GSUdfQ1JZUFRPX0FMR0FQSTI9eQpDT05GSUdfQ1JZUFRPX0FFQUQ9eQpDT05GSUdf
Q1JZUFRPX0FFQUQyPXkKQ09ORklHX0NSWVBUT19CTEtDSVBIRVI9eQpDT05GSUdfQ1JZUFRPX0JM
S0NJUEhFUjI9eQpDT05GSUdfQ1JZUFRPX0hBU0g9eQpDT05GSUdfQ1JZUFRPX0hBU0gyPXkKQ09O
RklHX0NSWVBUT19STkc9eQpDT05GSUdfQ1JZUFRPX1JORzI9eQpDT05GSUdfQ1JZUFRPX1BDT01Q
PXkKQ09ORklHX0NSWVBUT19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdf
Q1JZUFRPX01BTkFHRVIyPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldApDT05GSUdf
Q1JZUFRPX01BTkFHRVJfRElTQUJMRV9URVNUUz15CkNPTkZJR19DUllQVE9fR0YxMjhNVUw9eQoj
IENPTkZJR19DUllQVE9fTlVMTCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19QQ1JZUFQgaXMg
bm90IHNldApDT05GSUdfQ1JZUFRPX1dPUktRVUVVRT15CkNPTkZJR19DUllQVE9fQ1JZUFREPXkK
Q09ORklHX0NSWVBUT19BVVRIRU5DPXkKIyBDT05GSUdfQ1JZUFRPX1RFU1QgaXMgbm90IHNldApD
T05GSUdfQ1JZUFRPX0FCTEtfSEVMUEVSX1g4Nj15CkNPTkZJR19DUllQVE9fR0xVRV9IRUxQRVJf
WDg2PXkKCiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEK
IwojIENPTkZJR19DUllQVE9fQ0NNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0dDTSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TRVFJViBpcyBub3Qgc2V0CgojCiMgQmxvY2sgbW9kZXMK
IwpDT05GSUdfQ1JZUFRPX0NCQz15CiMgQ09ORklHX0NSWVBUT19DVFIgaXMgbm90IHNldAojIENP
TkZJR19DUllQVE9fQ1RTIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19FQ0I9eQpDT05GSUdfQ1JZ
UFRPX0xSVz15CiMgQ09ORklHX0NSWVBUT19QQ0JDIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19Y
VFM9eQoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9eQojIENPTkZJR19DUllQ
VE9fWENCQyBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19WTUFDIGlzIG5vdCBzZXQKCiMKIyBE
aWdlc3QKIwpDT05GSUdfQ1JZUFRPX0NSQzMyQz15CkNPTkZJR19DUllQVE9fQ1JDMzJDX0lOVEVM
PXkKIyBDT05GSUdfQ1JZUFRPX0dIQVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX01ENCBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fTUQ1PXkKIyBDT05GSUdfQ1JZUFRPX01JQ0hBRUxfTUlD
IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1JNRDEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19STUQxNjAgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMjU2IGlzIG5vdCBzZXQK
IyBDT05GSUdfQ1JZUFRPX1JNRDMyMCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBMT15CkNP
TkZJR19DUllQVE9fU0hBMV9TU1NFMz15CiMgQ09ORklHX0NSWVBUT19TSEEyNTYgaXMgbm90IHNl
dAojIENPTkZJR19DUllQVE9fU0hBNTEyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1RHUjE5
MiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19XUDUxMiBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19HSEFTSF9DTE1VTF9OSV9JTlRFTCBpcyBub3Qgc2V0CgojCiMgQ2lwaGVycwojCkNPTkZJ
R19DUllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19B
RVNfTklfSU5URUw9eQojIENPTkZJR19DUllQVE9fQU5VQklTIGlzIG5vdCBzZXQKQ09ORklHX0NS
WVBUT19BUkM0PXkKQ09ORklHX0NSWVBUT19CTE9XRklTSD15CkNPTkZJR19DUllQVE9fQkxPV0ZJ
U0hfQ09NTU9OPXkKQ09ORklHX0NSWVBUT19CTE9XRklTSF9YODZfNjQ9eQojIENPTkZJR19DUllQ
VE9fQ0FNRUxMSUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FNRUxMSUFfWDg2XzY0IGlz
IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRP
X0NBU1Q1X0FWWF9YODZfNjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDYgaXMgbm90
IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDZfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CkNPTkZJR19D
UllQVE9fREVTPXkKIyBDT05GSUdfQ1JZUFRPX0ZDUllQVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19LSEFaQUQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fU0FMU0EyMCBpcyBub3Qgc2V0
CiMgQ09ORklHX0NSWVBUT19TQUxTQTIwX1g4Nl82NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU
T19TRUVEIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19TRVJQRU5UPXkKQ09ORklHX0NSWVBUT19T
RVJQRU5UX1NTRTJfWDg2XzY0PXkKIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfQVZYX1g4Nl82NCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19URUEgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1RX
T0ZJU0g9eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfQ09NTU9OPXkKQ09ORklHX0NSWVBUT19UV09G
SVNIX1g4Nl82ND15CkNPTkZJR19DUllQVE9fVFdPRklTSF9YODZfNjRfM1dBWT15CiMgQ09ORklH
X0NSWVBUT19UV09GSVNIX0FWWF9YODZfNjQgaXMgbm90IHNldAoKIwojIENvbXByZXNzaW9uCiMK
Q09ORklHX0NSWVBUT19ERUZMQVRFPXkKQ09ORklHX0NSWVBUT19aTElCPXkKQ09ORklHX0NSWVBU
T19MWk89eQoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5T
SV9DUFJORz15CiMgQ09ORklHX0NSWVBUT19VU0VSX0FQSV9IQVNIIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0hX
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfS1ZNPXkKIyBDT05GSUdfVklSVFVBTElaQVRJT04gaXMg
bm90IHNldAojIENPTkZJR19CSU5BUllfUFJJTlRGIGlzIG5vdCBzZXQKCiMKIyBMaWJyYXJ5IHJv
dXRpbmVzCiMKQ09ORklHX0JJVFJFVkVSU0U9eQpDT05GSUdfR0VORVJJQ19TVFJOQ1BZX0ZST01f
VVNFUj15CkNPTkZJR19HRU5FUklDX1NUUk5MRU5fVVNFUj15CkNPTkZJR19HRU5FUklDX0ZJTkRf
RklSU1RfQklUPXkKQ09ORklHX0dFTkVSSUNfUENJX0lPTUFQPXkKQ09ORklHX0dFTkVSSUNfSU9N
QVA9eQpDT05GSUdfR0VORVJJQ19JTz15CiMgQ09ORklHX0NSQ19DQ0lUVCBpcyBub3Qgc2V0CkNP
TkZJR19DUkMxNj15CkNPTkZJR19DUkNfVDEwRElGPXkKIyBDT05GSUdfQ1JDX0lUVV9UIGlzIG5v
dCBzZXQKQ09ORklHX0NSQzMyPXkKQ09ORklHX0NSQzMyX1NFTEZURVNUPXkKQ09ORklHX0NSQzMy
X1NMSUNFQlk4PXkKIyBDT05GSUdfQ1JDMzJfU0xJQ0VCWTQgaXMgbm90IHNldAojIENPTkZJR19D
UkMzMl9TQVJXQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJfQklUIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ1JDNyBpcyBub3Qgc2V0CkNPTkZJR19MSUJDUkMzMkM9eQojIENPTkZJR19DUkM4IGlz
IG5vdCBzZXQKQ09ORklHX1pMSUJfSU5GTEFURT15CkNPTkZJR19aTElCX0RFRkxBVEU9eQpDT05G
SUdfTFpPX0NPTVBSRVNTPXkKQ09ORklHX0xaT19ERUNPTVBSRVNTPXkKQ09ORklHX1haX0RFQz15
CkNPTkZJR19YWl9ERUNfWDg2PXkKQ09ORklHX1haX0RFQ19QT1dFUlBDPXkKQ09ORklHX1haX0RF
Q19JQTY0PXkKQ09ORklHX1haX0RFQ19BUk09eQpDT05GSUdfWFpfREVDX0FSTVRIVU1CPXkKQ09O
RklHX1haX0RFQ19TUEFSQz15CkNPTkZJR19YWl9ERUNfQkNKPXkKIyBDT05GSUdfWFpfREVDX1RF
U1QgaXMgbm90IHNldApDT05GSUdfREVDT01QUkVTU19HWklQPXkKQ09ORklHX0RFQ09NUFJFU1Nf
QlpJUDI9eQpDT05GSUdfREVDT01QUkVTU19MWk1BPXkKQ09ORklHX0RFQ09NUFJFU1NfWFo9eQpD
T05GSUdfREVDT01QUkVTU19MWk89eQpDT05GSUdfVEVYVFNFQVJDSD15CkNPTkZJR19URVhUU0VB
UkNIX0tNUD15CkNPTkZJR19URVhUU0VBUkNIX0JNPXkKQ09ORklHX1RFWFRTRUFSQ0hfRlNNPXkK
Q09ORklHX0hBU19JT01FTT15CkNPTkZJR19IQVNfSU9QT1JUPXkKQ09ORklHX0hBU19ETUE9eQpD
T05GSUdfQ0hFQ0tfU0lHTkFUVVJFPXkKQ09ORklHX0NQVV9STUFQPXkKQ09ORklHX0RRTD15CkNP
TkZJR19OTEFUVFI9eQpDT05GSUdfQVJDSF9IQVNfQVRPTUlDNjRfREVDX0lGX1BPU0lUSVZFPXkK
Q09ORklHX0FWRVJBR0U9eQojIENPTkZJR19DT1JESUMgaXMgbm90IHNldAojIENPTkZJR19ERFIg
aXMgbm90IHNldAo=

--_002_36873033120121119163951eikelenboomit_--

--_002_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Feb 25 03:16:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 03:16: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 1U9oXR-0000kh-Ik; Mon, 25 Feb 2013 03:15:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1U9oXO-0000kc-W9
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 03:15:35 +0000
Received: from [85.158.139.83:54253] by server-14.bemta-5.messagelabs.com id
	50/0C-06967-657DA215; Mon, 25 Feb 2013 03:15:34 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361762123!28769168!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg4NzM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4321 invoked from network); 25 Feb 2013 03:15:25 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-182.messagelabs.com with SMTP;
	25 Feb 2013 03:15:25 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2013 19:13:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,731,1355126400"; d="scan'208";a="267038019"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 24 Feb 2013 19:15:20 -0800
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Feb 2013 19:15:17 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Feb 2013 19:15:17 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Mon, 25 Feb 2013 11:15:15 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefan Bader
	<stefan.bader@canonical.com>
Thread-Topic: [Xen-devel] PATastic fun
Thread-Index: AQHOEQxv++rTTiNfAESoDYAIhJawF5iJ6FMg
Date: Mon, 25 Feb 2013 03:15:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
In-Reply-To: <20130222145316.GB8017@phenom.dumpdata.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_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>> Hi Konrad,
>=20
> Hey Stefan,
>>=20
>> here is another one from the hm-what? department:
>=20
> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> he has been tracking a similar one with mcelog.
>>=20
>> Colin discovered that running the attached program with the fork
>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
>> iomem) this triggers the following weird messages:=20
>>=20
>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>> [ 6824.453776] ------------[ cut here ]------------
>> [ 6824.453796] WARNING: at
>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>> mmap-example Tainted: GF=20
>> 3.8.0-6-generic #13-Ubuntu
>> [ 6824.453926] Call Trace:
>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>> [ 6824.454027]  [<ffffffff81056d9f>]
>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>=20
>> I found that this is related to your bandaid patch
>>=20
>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>=20
>>     xen/pat: Disable PAT support for now.
>>=20
>> I just do not understand how this happens. From the trace it seems
>> the fork=20
>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
>> maybe the=20
>> warning is just related to this. So primarily the question is how on
>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>> cleared from the supported=20
>> mask by the patch, so somehow I would think nothing should be able
>> to set it...=20
>> But apparently not so.
>> Not sure it is a big deal since I never saw this in normal operation
>> and it=20
>> seems to be ok when unapping before doing the fork. It is just plain
>> odd.=20
>=20
> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> ranges are swapped or not correct. Jinsong, could you shed some light
> on what you have found so far?
>=20

Yes, Sander once also reported a similar weird warning when start mcelog da=
emon, as attached.

Basically, it occurs when mcelog user daemon start,=20
do_fork
  --> copy_process
    --> dup_mm
      --> dup_mmap
        --> copy_page_range
          --> track_pfn_copy
            --> reserve_pfn_range
              --> line 624: flags !=3D want_flags
It comes from different memory types of page table (_PAGE_CACHE_WB) and mtr=
r (_PAGE_CACHE_UC_MINUS).

However, why it get different memory types from page table and mtrr is stil=
l unclear, reproducing the bug is difficult and unstable.

Thanks,
Jinsong

>>=20
>> -Stefan
>=20
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <stdint.h>
>> #include <stdbool.h>
>> #include <unistd.h>
>> #include <sys/mman.h>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <sys/types.h>
>> #include <sys/wait.h>
>> #include <fcntl.h>
>>=20
>> int main(int argc, char **argv)
>> {
>> 	uint8_t *data;
>> 	int fd;
>> 	unsigned long long offset;
>> 	pid_t pid;
>> 	int status;
>> 	int opt;
>> 	bool opt_fork =3D false;
>>=20
>> 	while ((opt =3D getopt(argc, argv, "f")) !=3D -1) {
>> 		switch (opt) {
>> 		case 'f':
>> 			opt_fork =3D true;
>> 			break;
>> 		}
>> 	}
>>=20
>> 	if (argc <=3D optind) {
>> 		fprintf(stderr, "%s: [-f] address\n", argv[0]);
>> 		fprintf(stderr, "\t-f specifices if we should fork with the
>> 	mmap\n"); 		exit(EXIT_FAILURE); }
>> 	if (sscanf(argv[optind], "%lli", &offset) !=3D 1) {
>> 		fprintf(stderr, "Cannot determine mmap address from %s\n",
>> 	argv[optind]); 		exit(EXIT_FAILURE); }
>>=20
>> 	if ((fd =3D open("/dev/mem", O_RDONLY)) < 0) {
>> 		fprintf(stderr, "Cannot open /dev/mem\n");
>> 		exit(EXIT_FAILURE);
>> 	}
>>=20
>> 	printf("mmap: 0x%llx..0x%llx\n", offset, offset + 4095);
>>=20
>> 	if ((data =3D mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd,
>> 		(off_t)offset)) =3D=3D MAP_FAILED) { fprintf(stderr, "Cannot mmap
>> 		0x%llx\n", offset); exit(EXIT_FAILURE);
>> 	}
>>=20
>> 	close(fd);
>>=20
>> 	if (opt_fork) {
>> 		pid =3D fork();
>> 		if (pid =3D=3D 0) {
>> 			/* child */
>> 			_exit(0);
>> 		} else {
>> 			/* parent */
>> 			waitpid(pid, &status, 0);
>> 		}
>> 	}
>>=20
>> 	if (munmap(data, 4096) < 0) {
>> 		fprintf(stderr, "Cannot munmap %p\n", data);
>> 		exit(EXIT_FAILURE);
>> 	}
>> 	exit(EXIT_SUCCESS);
>> }
>>=20
>=20
>=20
>=20
>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


--_002_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Mon, 25 Feb 2013 03:15:12 GMT";
	modification-date="Mon, 25 Feb 2013 03:15:12 GMT"

Received: from fmsmsx105.amr.corp.intel.com (10.19.9.36) by
 SHSMSX151.ccr.corp.intel.com (10.239.6.50) with Microsoft SMTP Server (TLS)
 id 14.1.355.2; Mon, 19 Nov 2012 23:40:01 +0800
Received: from fmsmga001.fm.intel.com (10.253.24.23) by
 FMSMSX105-1.fm.intel.com (10.19.9.36) with Microsoft SMTP Server id
 14.1.355.2; Mon, 19 Nov 2012 07:40:00 -0800
Received: from fmsmga101.fm.intel.com ([10.1.193.65])  by
 fmsmga001-1.fm.intel.com with ESMTP; 19 Nov 2012 07:39:58 -0800
Received: from static.121.164.40.188.clients.your-server.de (HELO
 smtp.eikelenboom.it) ([188.40.164.121])  by mga01.intel.com with ESMTP; 19
 Nov 2012 07:39:57 -0800
Received: from 136-70-ftth.on.nl ([88.159.70.136]:54160 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 1TaTV0-0004xB-J9; Mon, 19 Nov 2012
 16:43:02 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Subject: Re: [ 3009.778974] mcelog:16842 map pfn expected mapping type
 write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
Thread-Topic: [ 3009.778974] mcelog:16842 map pfn expected mapping type
 write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
Thread-Index: AQHNxmwd15VBKwan9ka7+XGDG79Vdw==
Date: Mon, 19 Nov 2012 15:39:51 +0000
Message-ID: <368730331.20121119163951@eikelenboom.it>
References: <791265057.20121116134056@eikelenboom.it>
 <20121116160733.GO22320@phenom.dumpdata.com>
 <1422434855.20121116174754@eikelenboom.it>
 <20121116165834.GA18725@phenom.dumpdata.com>
 <DE8DF0795D48FD4CA783C40EC829233538E31B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233538E31B@SHSMSX101.ccr.corp.intel.com>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: FMSMSX105.amr.corp.intel.com
X-MS-Has-Attach: yes
X-Message-Flag: Follow up
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.83,280,1352102400";    d="scan'208";a="25123645"
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: ApcHAM9RqlC8KKR5/2dsb2JhbAA7ColjqAWNdIRtgh4BAQQBViMFCwUGGAkaCwINKh4GDhaHdgrAAow0EIR9A457jFmKa4Jw
Content-Type: multipart/mixed;
	boundary="_002_36873033120121119163951eikelenboomit_"
MIME-Version: 1.0

--_002_36873033120121119163951eikelenboomit_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A861B0F295519341B46F60C1CF40BA3D@intel.com>
Content-Transfer-Encoding: quoted-printable


Saturday, November 17, 2012, 3:14:10 PM, you wrote:

> Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 16, 2012 at 05:47:54PM +0100, Sander Eikelenboom wrote:
>>>=20
>>> Friday, November 16, 2012, 5:07:33 PM, you wrote:
>>>=20
>>>> On Fri, Nov 16, 2012 at 01:40:56PM +0100, Sander Eikelenboom wrote:
>>>>> Hi Konrad,
>>>>>=20
>>>>> Sometime ago i reported this one at boot up:
>>>>>=20
>>>>> [ 3009.778974] mcelog:16842 map pfn expected mapping type
>>>>> write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus [
>>>>> 3009.788570] ------------[ cut here ]------------ [ 3009.798175]
>>>>> WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0xa1/0xb0() [
>>>>> 3009.807966] Hardware name: MS-7640 [ 3009.817677] Modules linked
>>>>> in: [ 3009.827524] Pid: 16842, comm: mcelog Tainted: G        W  =20
>>>>> 3.7.0-rc5-20121116-reverted-persistent-warn-patwarn #1 [
>>>>> 3009.837415] Call Trace: [ 3009.847110]  [<ffffffff810674fa>]
>>>>> warn_slowpath_common+0x7a/0xb0 [ 3009.856857]=20
>>>>> [<ffffffff81067545>] warn_slowpath_null+0x15/0x20 [ 3009.866562]=20
>>>>> [<ffffffff81042041>] untrack_pfn+0xa1/0xb0 [ 3009.876201]=20
>>>>> [<ffffffff8111a59b>] unmap_single_vma+0x86b/0x8e0 [ 3009.885895]=20
>>>>> [<ffffffff81100f16>] ? release_pages+0x196/0x1f0 [ 3009.895488]=20
>>>>> [<ffffffff8111a65c>] unmap_vmas+0x4c/0xa0 [ 3009.905134]=20
>>>>> [<ffffffff8111c8fa>] exit_mmap+0x9a/0x180 [ 3009.914706]=20
>>>>> [<ffffffff81064e72>] mmput+0x52/0xd0 [ 3009.924252]=20
>>>>> [<ffffffff810652b7>] dup_mm+0x3c7/0x510 [ 3009.933839]=20
>>>>> [<ffffffff81065fd5>] copy_process+0xac5/0x14a0 [ 3009.943430]=20
>>>>> [<ffffffff81066af3>] do_fork+0x53/0x360 [ 3009.952843]=20
>>>>> [<ffffffff810b25c7>] ? lock_release+0x117/0x250 [ 3009.962283]=20
>>>>> [<ffffffff817d26c0>] ? _raw_spin_unlock+0x30/0x60 [ 3009.971532]=20
>>>>> [<ffffffff817d3495>] ? sysret_check+0x22/0x5d [ 3009.980820]=20
>>>>> [<ffffffff81017523>] sys_clone+0x23/0x30 [ 3009.990046]=20
>>>>> [<ffffffff817d37f3>] stub_clone+0x13/0x20 [ 3009.999335]=20
>>>>> [<ffffffff817d3469>] ? system_call_fastpath+0x16/0x1b [
>>>>> 3010.008667] ---[ end trace 2d9694c2c0a24da8 ]--- =20
>>>>>=20
>>>>>=20
>>>>> It seems to be due to the "mcelog" userspace tool provided with
>>>>> Debian Squeeze (mcelog 1.0~pre3-3  x86-64 Machine Check Exceptions
>>>>> collector and decoder). I can trigger this warning easily by
>>>>> restarting the mcelog tool with /etc/init.d/mcelog restart =20
>>>>>=20
>>>>> Should that one also function with the xen mcelog driver, or is a
>>>>> newer version required ?=20
>>>=20
>>>> The reason we get is b/c I had to disable the PAT functionality in
>>>> the Linux kernel for Xen. This is b/c it only worked one way -
>>>> meaning you could convert a page from=20
>>>> WriteBack to WriteCombine or WriteBack to Uncached. But you could
>>>> not=20
>>>> do WriteCombine back to WriteBack - due to one of the functions that
>>>> changes the bits was using an "unfiltered" way to identify the bits
>>>> on the=20
>>>> page.
>>>=20
>>>> Anyhow, we had a disaster b/c some of these pages that used to
>>>> WriteBack (WB)=20
>>>> got converted to WriteCombine (WC) and then were returned back as
>>>> such=20
>>>> to the page pool. And if they were re-used by filesystem invariably
>>>> we got=20
>>>> corruptions.
>>>=20
>>>> So until the PAT table lookup thing that Peter H. Anvin suggested
>>>> gets implemented this splat gotta show up :-(
>>>=20
>>> Not a big problem for me, i was just wondering :-)
>>> I'm more interested in the netfront troubles, since it's already rc5.
>>>=20
>>>> Does mcelog still work even with this warning?
>>>=20
>>> Not the daemon:
>>>=20
>>> serveerstertje:~# sh /etc/init.d/mcelog start
>>> Starting Machine Check Exceptions decoder: daemon: Cannot allocate
>>> memory=20
>>>=20
>> Ugh.
>> CC-ing Liu here.
>>=20

> How to reproduce it (sorry I miss the history of this thread)?
> I have a try at Xen side, w/ kernel 3.6.0-rc7+, no problem at my side.

I'm using:
- Xen-unstable, latest changeset=3D26152
- Linux 3.7.0-rc5 kernel latest changeset=3D79e979eae0df58831e85281e3285f63=
663f3cf76
- Dom0 OS =3D Debian Squeeze
- mcelog package: 1.0~pre3-3  x86-64 Machine Check Exceptions collector and=
 decoder)

I don't have particular interest in mcelog, but i just encountered this war=
n on boot.
The warn (see above) is shown when the mcelog daemon (from the debian packa=
ge) tries to start (for example on boot)

I have attached the .config from the used kernel.

If you need any more info, please ask !

--
Sander


> Thanks,
> Jinsong

>>>=20
>>>>>=20
>>>>> --
>>>>> Sander


--_002_36873033120121119163951eikelenboomit_
Content-Type: application/octet-stream; name="dotconfig"
Content-Description: dotconfig
Content-Disposition: attachment; filename="dotconfig"; size=85055;
	creation-date="Mon, 19 Nov 2012 15:40:01 GMT";
	modification-date="Mon, 19 Nov 2012 15:40:01 GMT"
Content-ID: <ED52B5CDF2756347BF4ADD1C99DA70F8@intel.com>
Content-Transfer-Encoding: base64

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4L3g4
Nl82NCAzLjcuMC1yYzUtMjAxMjExMTYtcmV2ZXJ0ZWQtcGVyc2lzdGVudC1idCBLZXJuZWwgQ29u
ZmlndXJhdGlvbgojCkNPTkZJR182NEJJVD15CkNPTkZJR19YODZfNjQ9eQpDT05GSUdfWDg2PXkK
Q09ORklHX0lOU1RSVUNUSU9OX0RFQ09ERVI9eQpDT05GSUdfT1VUUFVUX0ZPUk1BVD0iZWxmNjQt
eDg2LTY0IgpDT05GSUdfQVJDSF9ERUZDT05GSUc9ImFyY2gveDg2L2NvbmZpZ3MveDg2XzY0X2Rl
ZmNvbmZpZyIKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RSQUNFX1NVUFBP
UlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1VPXkKQ09ORklH
X05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdf
R0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0dFTkVSSUNfQlVH
X1JFTEFUSVZFX1BPSU5URVJTPXkKQ09ORklHX0dFTkVSSUNfSFdFSUdIVD15CkNPTkZJR19BUkNI
X01BWV9IQVZFX1BDX0ZEQz15CkNPTkZJR19SV1NFTV9YQ0hHQUREX0FMR09SSVRITT15CkNPTkZJ
R19HRU5FUklDX0NBTElCUkFURV9ERUxBWT15CkNPTkZJR19BUkNIX0hBU19DUFVfUkVMQVg9eQpD
T05GSUdfQVJDSF9IQVNfREVGQVVMVF9JRExFPXkKQ09ORklHX0FSQ0hfSEFTX0NBQ0hFX0xJTkVf
U0laRT15CkNPTkZJR19BUkNIX0hBU19DUFVfQVVUT1BST0JFPXkKQ09ORklHX0hBVkVfU0VUVVBf
UEVSX0NQVV9BUkVBPXkKQ09ORklHX05FRURfUEVSX0NQVV9FTUJFRF9GSVJTVF9DSFVOSz15CkNP
TkZJR19ORUVEX1BFUl9DUFVfUEFHRV9GSVJTVF9DSFVOSz15CkNPTkZJR19BUkNIX0hJQkVSTkFU
SU9OX1BPU1NJQkxFPXkKQ09ORklHX0FSQ0hfU1VTUEVORF9QT1NTSUJMRT15CkNPTkZJR19aT05F
X0RNQTMyPXkKQ09ORklHX0FVRElUX0FSQ0g9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19PUFRJTUla
RURfSU5MSU5JTkc9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19ERUJVR19QQUdFQUxMT0M9eQpDT05G
SUdfWDg2XzY0X1NNUD15CkNPTkZJR19YODZfSFQ9eQpDT05GSUdfQVJDSF9IV0VJR0hUX0NGTEFH
Uz0iLWZjYWxsLXNhdmVkLXJkaSAtZmNhbGwtc2F2ZWQtcnNpIC1mY2FsbC1zYXZlZC1yZHggLWZj
YWxsLXNhdmVkLXJjeCAtZmNhbGwtc2F2ZWQtcjggLWZjYWxsLXNhdmVkLXI5IC1mY2FsbC1zYXZl
ZC1yMTAgLWZjYWxsLXNhdmVkLXIxMSIKQ09ORklHX0FSQ0hfQ1BVX1BST0JFX1JFTEVBU0U9eQpD
T05GSUdfQVJDSF9TVVBQT1JUU19VUFJPQkVTPXkKQ09ORklHX0RFRkNPTkZJR19MSVNUPSIvbGli
L21vZHVsZXMvJFVOQU1FX1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0hBVkVfSVJRX1dPUks9eQpD
T05GSUdfSVJRX1dPUks9eQpDT05GSUdfQlVJTERUSU1FX0VYVEFCTEVfU09SVD15CgojCiMgR2Vu
ZXJhbCBzZXR1cAojCkNPTkZJR19FWFBFUklNRU5UQUw9eQpDT05GSUdfSU5JVF9FTlZfQVJHX0xJ
TUlUPTMyCkNPTkZJR19DUk9TU19DT01QSUxFPSIiCkNPTkZJR19MT0NBTFZFUlNJT049IiIKIyBD
T05GSUdfTE9DQUxWRVJTSU9OX0FVVE8gaXMgbm90IHNldApDT05GSUdfSEFWRV9LRVJORUxfR1pJ
UD15CkNPTkZJR19IQVZFX0tFUk5FTF9CWklQMj15CkNPTkZJR19IQVZFX0tFUk5FTF9MWk1BPXkK
Q09ORklHX0hBVkVfS0VSTkVMX1haPXkKQ09ORklHX0hBVkVfS0VSTkVMX0xaTz15CkNPTkZJR19L
RVJORUxfR1pJUD15CiMgQ09ORklHX0tFUk5FTF9CWklQMiBpcyBub3Qgc2V0CiMgQ09ORklHX0tF
Uk5FTF9MWk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX1haIGlzIG5vdCBzZXQKIyBDT05G
SUdfS0VSTkVMX0xaTyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1ROQU1FPSIobm9uZSki
CkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lTVklQQ19TWVNDVEw9eQoj
IENPTkZJR19QT1NJWF9NUVVFVUUgaXMgbm90IHNldAojIENPTkZJR19GSEFORExFIGlzIG5vdCBz
ZXQKQ09ORklHX0FVRElUPXkKQ09ORklHX0FVRElUU1lTQ0FMTD15CkNPTkZJR19BVURJVF9XQVRD
SD15CkNPTkZJR19BVURJVF9UUkVFPXkKIyBDT05GSUdfQVVESVRfTE9HSU5VSURfSU1NVVRBQkxF
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfR0VORVJJQ19IQVJESVJRUz15CgojCiMgSVJRIHN1YnN5
c3RlbQojCkNPTkZJR19HRU5FUklDX0hBUkRJUlFTPXkKQ09ORklHX0dFTkVSSUNfSVJRX1BST0JF
PXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdfR0VORVJJQ19QRU5ESU5HX0lSUT15
CkNPTkZJR19JUlFfRE9NQUlOPXkKIyBDT05GSUdfSVJRX0RPTUFJTl9ERUJVRyBpcyBub3Qgc2V0
CkNPTkZJR19JUlFfRk9SQ0VEX1RIUkVBRElORz15CkNPTkZJR19TUEFSU0VfSVJRPXkKQ09ORklH
X0NMT0NLU09VUkNFX1dBVENIRE9HPXkKQ09ORklHX0FSQ0hfQ0xPQ0tTT1VSQ0VfREFUQT15CkNP
TkZJR19HRU5FUklDX1RJTUVfVlNZU0NBTEw9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UUz15
CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tF
VkVOVFNfQlJPQURDQVNUPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfTUlOX0FESlVTVD15
CkNPTkZJR19HRU5FUklDX0NNT1NfVVBEQVRFPXkKCiMKIyBUaW1lcnMgc3Vic3lzdGVtCiMKQ09O
RklHX1RJQ0tfT05FU0hPVD15CkNPTkZJR19OT19IWj15CkNPTkZJR19ISUdIX1JFU19USU1FUlM9
eQoKIwojIENQVS9UYXNrIHRpbWUgYW5kIHN0YXRzIGFjY291bnRpbmcKIwpDT05GSUdfVElDS19D
UFVfQUNDT1VOVElORz15CiMgQ09ORklHX0lSUV9USU1FX0FDQ09VTlRJTkcgaXMgbm90IHNldApD
T05GSUdfQlNEX1BST0NFU1NfQUNDVD15CiMgQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1RfVjMgaXMg
bm90IHNldApDT05GSUdfVEFTS1NUQVRTPXkKQ09ORklHX1RBU0tfREVMQVlfQUNDVD15CkNPTkZJ
R19UQVNLX1hBQ0NUPXkKQ09ORklHX1RBU0tfSU9fQUNDT1VOVElORz15CgojCiMgUkNVIFN1YnN5
c3RlbQojCkNPTkZJR19UUkVFX1BSRUVNUFRfUkNVPXkKQ09ORklHX1BSRUVNUFRfUkNVPXkKIyBD
T05GSUdfUkNVX1VTRVJfUVMgaXMgbm90IHNldApDT05GSUdfUkNVX0ZBTk9VVD02NApDT05GSUdf
UkNVX0ZBTk9VVF9MRUFGPTE2CiMgQ09ORklHX1JDVV9GQU5PVVRfRVhBQ1QgaXMgbm90IHNldApD
T05GSUdfUkNVX0ZBU1RfTk9fSFo9eQojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0
CkNPTkZJR19SQ1VfQk9PU1Q9eQpDT05GSUdfUkNVX0JPT1NUX1BSSU89MQpDT05GSUdfUkNVX0JP
T1NUX0RFTEFZPTUwMApDT05GSUdfSUtDT05GSUc9eQojIENPTkZJR19JS0NPTkZJR19QUk9DIGlz
IG5vdCBzZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTgKQ09ORklHX0hBVkVfVU5TVEFCTEVfU0NI
RURfQ0xPQ0s9eQpDT05GSUdfQ0dST1VQUz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qg
c2V0CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15CiMgQ09ORklHX0NHUk9VUF9ERVZJQ0UgaXMgbm90
IHNldApDT05GSUdfQ1BVU0VUUz15CkNPTkZJR19QUk9DX1BJRF9DUFVTRVQ9eQpDT05GSUdfQ0dS
T1VQX0NQVUFDQ1Q9eQpDT05GSUdfUkVTT1VSQ0VfQ09VTlRFUlM9eQojIENPTkZJR19NRU1DRyBp
cyBub3Qgc2V0CiMgQ09ORklHX0NHUk9VUF9IVUdFVExCIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dS
T1VQX1BFUkYgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JP
VVBfU0NIRUQ9eQojIENPTkZJR19DRlNfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRf
R1JPVVBfU0NIRUQgaXMgbm90IHNldApDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklHX0RFQlVH
X0JMS19DR1JPVVAgaXMgbm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RPUkUgaXMgbm90
IHNldApDT05GSUdfTkFNRVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05GSUdfSVBDX05TPXkK
Q09ORklHX1BJRF9OUz15CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NIRURfQVVUT0dST1VQPXkK
IyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1JFTEFZIGlzIG5v
dCBzZXQKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklHX0lOSVRSQU1GU19TT1VSQ0U9IiIK
Q09ORklHX1JEX0daSVA9eQpDT05GSUdfUkRfQlpJUDI9eQpDT05GSUdfUkRfTFpNQT15CkNPTkZJ
R19SRF9YWj15CkNPTkZJR19SRF9MWk89eQojIENPTkZJR19DQ19PUFRJTUlaRV9GT1JfU0laRSBp
cyBub3Qgc2V0CkNPTkZJR19TWVNDVEw9eQpDT05GSUdfQU5PTl9JTk9ERVM9eQojIENPTkZJR19F
WFBFUlQgaXMgbm90IHNldApDT05GSUdfSEFWRV9VSUQxNj15CkNPTkZJR19VSUQxNj15CiMgQ09O
RklHX1NZU0NUTF9TWVNDQUxMIGlzIG5vdCBzZXQKQ09ORklHX1NZU0NUTF9FWENFUFRJT05fVFJB
Q0U9eQpDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKQ09ORklHX0hPVFBM
VUc9eQpDT05GSUdfUFJJTlRLPXkKQ09ORklHX0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJ
R19QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdf
QkFTRV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZE
PXkKQ09ORklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJ
R19BSU89eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZF
TlRTPXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJ
R19QRVJGX0VWRU5UUz15CiMgQ09ORklHX0RFQlVHX1BFUkZfVVNFX1ZNQUxMT0MgaXMgbm90IHNl
dApDT05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdfUENJX1FVSVJLUz15CkNPTkZJR19T
TFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NMQUIg
aXMgbm90IHNldApDT05GSUdfU0xVQj15CiMgQ09ORklHX1BST0ZJTElORyBpcyBub3Qgc2V0CkNP
TkZJR19IQVZFX09QUk9GSUxFPXkKQ09ORklHX09QUk9GSUxFX05NSV9USU1FUj15CiMgQ09ORklH
X0tQUk9CRVMgaXMgbm90IHNldApDT05GSUdfSlVNUF9MQUJFTD15CkNPTkZJR19IQVZFX0VGRklD
SUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklHX0hBVkVfSU9SRU1BUF9QUk9UPXkKQ09ORklH
X0hBVkVfS1BST0JFUz15CkNPTkZJR19IQVZFX0tSRVRQUk9CRVM9eQpDT05GSUdfSEFWRV9PUFRQ
Uk9CRVM9eQpDT05GSUdfSEFWRV9BUkNIX1RSQUNFSE9PSz15CkNPTkZJR19IQVZFX0RNQV9BVFRS
Uz15CkNPTkZJR19VU0VfR0VORVJJQ19TTVBfSEVMUEVSUz15CkNPTkZJR19HRU5FUklDX1NNUF9J
RExFX1RIUkVBRD15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNLX0FDQ0VTU19BUEk9eQpDT05G
SUdfSEFWRV9ETUFfQVBJX0RFQlVHPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJ
R19IQVZFX01JWEVEX0JSRUFLUE9JTlRTX1JFR1M9eQpDT05GSUdfSEFWRV9VU0VSX1JFVFVSTl9O
T1RJRklFUj15CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTX05NST15CkNPTkZJR19IQVZFX1BFUkZf
UkVHUz15CkNPTkZJR19IQVZFX1BFUkZfVVNFUl9TVEFDS19EVU1QPXkKQ09ORklHX0hBVkVfQVJD
SF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfSEFWRV9OTUlfU0FGRV9DTVBYQ0hHPXkKQ09ORklH
X0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15CkNPTkZJR19IQVZFX0NNUFhDSEdfTE9DQUw9eQpD
T05GSUdfSEFWRV9DTVBYQ0hHX0RPVUJMRT15CkNPTkZJR19BUkNIX1dBTlRfQ09NUEFUX0lQQ19Q
QVJTRV9WRVJTSU9OPXkKQ09ORklHX0FSQ0hfV0FOVF9PTERfQ09NUEFUX0lQQz15CkNPTkZJR19H
RU5FUklDX0tFUk5FTF9USFJFQUQ9eQpDT05GSUdfR0VORVJJQ19LRVJORUxfRVhFQ1ZFPXkKQ09O
RklHX0hBVkVfQVJDSF9TRUNDT01QX0ZJTFRFUj15CkNPTkZJR19TRUNDT01QX0ZJTFRFUj15CkNP
TkZJR19IQVZFX1JDVV9VU0VSX1FTPXkKQ09ORklHX0hBVkVfSVJRX1RJTUVfQUNDT1VOVElORz15
CkNPTkZJR19IQVZFX0FSQ0hfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfTU9EVUxFU19V
U0VfRUxGX1JFTEE9eQoKIwojIEdDT1YtYmFzZWQga2VybmVsIHByb2ZpbGluZwojCiMgQ09ORklH
X0dDT1ZfS0VSTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFWRV9HRU5FUklDX0RNQV9DT0hFUkVO
VCBpcyBub3Qgc2V0CkNPTkZJR19TTEFCSU5GTz15CkNPTkZJR19SVF9NVVRFWEVTPXkKQ09ORklH
X0JBU0VfU01BTEw9MApDT05GSUdfTU9EVUxFUz15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9MT0FE
IGlzIG5vdCBzZXQKQ09ORklHX01PRFVMRV9VTkxPQUQ9eQojIENPTkZJR19NT0RVTEVfRk9SQ0Vf
VU5MT0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9EVkVSU0lPTlMgaXMgbm90IHNldAojIENPTkZJ
R19NT0RVTEVfU1JDVkVSU0lPTl9BTEwgaXMgbm90IHNldAojIENPTkZJR19NT0RVTEVfU0lHIGlz
IG5vdCBzZXQKQ09ORklHX1NUT1BfTUFDSElORT15CkNPTkZJR19CTE9DSz15CkNPTkZJR19CTEtf
REVWX0JTRz15CiMgQ09ORklHX0JMS19ERVZfQlNHTElCIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E
RVZfSU5URUdSSVRZPXkKIyBDT05GSUdfQkxLX0RFVl9USFJPVFRMSU5HIGlzIG5vdCBzZXQKCiMK
IyBQYXJ0aXRpb24gVHlwZXMKIwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEPXkKIyBDT05GSUdf
QUNPUk5fUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX09TRl9QQVJUSVRJT049eQpDT05GSUdf
QU1JR0FfUEFSVElUSU9OPXkKIyBDT05GSUdfQVRBUklfUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09O
RklHX01BQ19QQVJUSVRJT049eQpDT05GSUdfTVNET1NfUEFSVElUSU9OPXkKQ09ORklHX0JTRF9E
SVNLTEFCRUw9eQpDT05GSUdfTUlOSVhfU1VCUEFSVElUSU9OPXkKQ09ORklHX1NPTEFSSVNfWDg2
X1BBUlRJVElPTj15CkNPTkZJR19VTklYV0FSRV9ESVNLTEFCRUw9eQojIENPTkZJR19MRE1fUEFS
VElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX1NHSV9QQVJUSVRJT049eQojIENPTkZJR19VTFRSSVhf
UEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX1NVTl9QQVJUSVRJT049eQpDT05GSUdfS0FSTUFf
UEFSVElUSU9OPXkKQ09ORklHX0VGSV9QQVJUSVRJT049eQojIENPTkZJR19TWVNWNjhfUEFSVElU
SU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMT0NLX0NPTVBBVD15CgojCiMgSU8gU2NoZWR1bGVycwoj
CkNPTkZJR19JT1NDSEVEX05PT1A9eQpDT05GSUdfSU9TQ0hFRF9ERUFETElORT15CkNPTkZJR19J
T1NDSEVEX0NGUT15CkNPTkZJR19DRlFfR1JPVVBfSU9TQ0hFRD15CiMgQ09ORklHX0RFRkFVTFRf
REVBRExJTkUgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9DRlE9eQojIENPTkZJR19ERUZBVUxU
X05PT1AgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9JT1NDSEVEPSJjZnEiCkNPTkZJR19VTklO
TElORV9TUElOX1VOTE9DSz15CkNPTkZJR19GUkVFWkVSPXkKCiMKIyBQcm9jZXNzb3IgdHlwZSBh
bmQgZmVhdHVyZXMKIwpDT05GSUdfWk9ORV9ETUE9eQpDT05GSUdfU01QPXkKQ09ORklHX1g4Nl9N
UFBBUlNFPXkKQ09ORklHX1g4Nl9FWFRFTkRFRF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9WU01Q
IGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19T
Q0hFRF9PTUlUX0ZSQU1FX1BPSU5URVI9eQpDT05GSUdfUEFSQVZJUlRfR1VFU1Q9eQojIENPTkZJ
R19QQVJBVklSVF9USU1FX0FDQ09VTlRJTkcgaXMgbm90IHNldApDT05GSUdfWEVOPXkKQ09ORklH
X1hFTl9ET00wPXkKQ09ORklHX1hFTl9QUklWSUxFR0VEX0dVRVNUPXkKQ09ORklHX1hFTl9QVkhW
TT15CkNPTkZJR19YRU5fTUFYX0RPTUFJTl9NRU1PUlk9NTAwCkNPTkZJR19YRU5fU0FWRV9SRVNU
T1JFPXkKQ09ORklHX1hFTl9ERUJVR19GUz15CiMgQ09ORklHX0tWTV9HVUVTVCBpcyBub3Qgc2V0
CkNPTkZJR19QQVJBVklSVD15CiMgQ09ORklHX1BBUkFWSVJUX1NQSU5MT0NLUyBpcyBub3Qgc2V0
CkNPTkZJR19QQVJBVklSVF9DTE9DSz15CkNPTkZJR19QQVJBVklSVF9ERUJVRz15CkNPTkZJR19O
T19CT09UTUVNPXkKIyBDT05GSUdfTUVNVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19NSzg9eQojIENP
TkZJR19NUFNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNPUkUyIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUFUT00gaXMgbm90IHNldAojIENPTkZJR19HRU5FUklDX0NQVSBpcyBub3Qgc2V0CkNPTkZJR19Y
ODZfSU5URVJOT0RFX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4Nl9DTVBYQ0hHPXkKQ09ORklHX1g4
Nl9MMV9DQUNIRV9TSElGVD02CkNPTkZJR19YODZfWEFERD15CkNPTkZJR19YODZfV1BfV09SS1Nf
T0s9eQpDT05GSUdfWDg2X0lOVEVMX1VTRVJDT1BZPXkKQ09ORklHX1g4Nl9VU0VfUFBST19DSEVD
S1NVTT15CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdfWDg2
X0NNT1Y9eQpDT05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdfWDg2X0RFQlVH
Q1RMTVNSPXkKQ09ORklHX0NQVV9TVVBfSU5URUw9eQpDT05GSUdfQ1BVX1NVUF9BTUQ9eQpDT05G
SUdfQ1BVX1NVUF9DRU5UQVVSPXkKQ09ORklHX0hQRVRfVElNRVI9eQpDT05GSUdfSFBFVF9FTVVM
QVRFX1JUQz15CkNPTkZJR19ETUk9eQpDT05GSUdfR0FSVF9JT01NVT15CiMgQ09ORklHX0NBTEdB
UllfSU9NTVUgaXMgbm90IHNldApDT05GSUdfU1dJT1RMQj15CkNPTkZJR19JT01NVV9IRUxQRVI9
eQojIENPTkZJR19NQVhTTVAgaXMgbm90IHNldApDT05GSUdfTlJfQ1BVUz04CkNPTkZJR19TQ0hF
RF9TTVQ9eQpDT05GSUdfU0NIRURfTUM9eQojIENPTkZJR19QUkVFTVBUX05PTkUgaXMgbm90IHNl
dAojIENPTkZJR19QUkVFTVBUX1ZPTFVOVEFSWSBpcyBub3Qgc2V0CkNPTkZJR19QUkVFTVBUPXkK
Q09ORklHX1BSRUVNUFRfQ09VTlQ9eQpDT05GSUdfWDg2X0xPQ0FMX0FQSUM9eQpDT05GSUdfWDg2
X0lPX0FQSUM9eQpDT05GSUdfWDg2X1JFUk9VVEVfRk9SX0JST0tFTl9CT09UX0lSUVM9eQpDT05G
SUdfWDg2X01DRT15CkNPTkZJR19YODZfTUNFX0lOVEVMPXkKQ09ORklHX1g4Nl9NQ0VfQU1EPXkK
Q09ORklHX1g4Nl9NQ0VfVEhSRVNIT0xEPXkKIyBDT05GSUdfWDg2X01DRV9JTkpFQ1QgaXMgbm90
IHNldApDT05GSUdfWDg2X1RIRVJNQUxfVkVDVE9SPXkKIyBDT05GSUdfSThLIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUlDUk9DT0RFIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdfWDg2
X0NQVUlEPXkKQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFf
QUREUl9UXzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX05VTUE9eQpDT05G
SUdfQU1EX05VTUE9eQpDT05GSUdfWDg2XzY0X0FDUElfTlVNQT15CkNPTkZJR19OT0RFU19TUEFO
X09USEVSX05PREVTPXkKIyBDT05GSUdfTlVNQV9FTVUgaXMgbm90IHNldApDT05GSUdfTk9ERVNf
U0hJRlQ9OApDT05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkKQ09ORklHX0FSQ0hfU1BBUlNF
TUVNX0RFRkFVTFQ9eQpDT05GSUdfQVJDSF9TRUxFQ1RfTUVNT1JZX01PREVMPXkKQ09ORklHX0FS
Q0hfUFJPQ19LQ09SRV9URVhUPXkKQ09ORklHX0lMTEVHQUxfUE9JTlRFUl9WQUxVRT0weGRlYWQw
MDAwMDAwMDAwMDAKQ09ORklHX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfU1BBUlNFTUVN
X01BTlVBTD15CkNPTkZJR19TUEFSU0VNRU09eQpDT05GSUdfTkVFRF9NVUxUSVBMRV9OT0RFUz15
CkNPTkZJR19IQVZFX01FTU9SWV9QUkVTRU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1FPXkK
Q09ORklHX1NQQVJTRU1FTV9WTUVNTUFQX0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxMT0Nf
TUVNX01BUF9UT0dFVEhFUj15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19IQVZF
X01FTUJMT0NLPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0tfTk9ERV9NQVA9eQpDT05GSUdfQVJDSF9E
SVNDQVJEX01FTUJMT0NLPXkKIyBDT05GSUdfTUVNT1JZX0hPVFBMVUcgaXMgbm90IHNldApDT05G
SUdfUEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9DS19DUFVTPTk5OTk5OQpD
T05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdSQVRJT049eQpDT05GSUdfUEhZU19BRERSX1Rf
NjRCSVQ9eQpDT05GSUdfWk9ORV9ETUFfRkxBRz0xCkNPTkZJR19CT1VOQ0U9eQpDT05GSUdfVklS
VF9UT19CVVM9eQpDT05GSUdfTU1VX05PVElGSUVSPXkKIyBDT05GSUdfS1NNIGlzIG5vdCBzZXQK
Q09ORklHX0RFRkFVTFRfTU1BUF9NSU5fQUREUj00MDk2CkNPTkZJR19BUkNIX1NVUFBPUlRTX01F
TU9SWV9GQUlMVVJFPXkKIyBDT05GSUdfTUVNT1JZX0ZBSUxVUkUgaXMgbm90IHNldApDT05GSUdf
VFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0VfQUxXQVlT
PXkKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0VfTUFEVklTRSBpcyBub3Qgc2V0CkNPTkZJ
R19DUk9TU19NRU1PUllfQVRUQUNIPXkKIyBDT05GSUdfQ0xFQU5DQUNIRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0ZST05UU1dBUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfQ0hFQ0tfQklPU19DT1JSVVBU
SU9OPXkKQ09ORklHX1g4Nl9CT09UUEFSQU1fTUVNT1JZX0NPUlJVUFRJT05fQ0hFQ0s9eQpDT05G
SUdfWDg2X1JFU0VSVkVfTE9XPTY0CkNPTkZJR19NVFJSPXkKQ09ORklHX01UUlJfU0FOSVRJWkVS
PXkKQ09ORklHX01UUlJfU0FOSVRJWkVSX0VOQUJMRV9ERUZBVUxUPTAKQ09ORklHX01UUlJfU0FO
SVRJWkVSX1NQQVJFX1JFR19OUl9ERUZBVUxUPTEKQ09ORklHX1g4Nl9QQVQ9eQpDT05GSUdfQVJD
SF9VU0VTX1BHX1VOQ0FDSEVEPXkKQ09ORklHX0FSQ0hfUkFORE9NPXkKQ09ORklHX1g4Nl9TTUFQ
PXkKIyBDT05GSUdfRUZJIGlzIG5vdCBzZXQKQ09ORklHX1NFQ0NPTVA9eQojIENPTkZJR19DQ19T
VEFDS1BST1RFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMCBpcyBub3Qgc2V0CiMgQ09O
RklHX0haXzI1MCBpcyBub3Qgc2V0CkNPTkZJR19IWl8zMDA9eQojIENPTkZJR19IWl8xMDAwIGlz
IG5vdCBzZXQKQ09ORklHX0haPTMwMApDT05GSUdfU0NIRURfSFJUSUNLPXkKQ09ORklHX0tFWEVD
PXkKQ09ORklHX0NSQVNIX0RVTVA9eQpDT05GSUdfUEhZU0lDQUxfU1RBUlQ9MHgxMDAwMDAwCkNP
TkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAKQ09ORklH
X0hPVFBMVUdfQ1BVPXkKIyBDT05GSUdfQ09NUEFUX1ZEU08gaXMgbm90IHNldAojIENPTkZJR19D
TURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdfQVJDSF9FTkFCTEVfTUVNT1JZX0hPVFBMVUc9
eQpDT05GSUdfVVNFX1BFUkNQVV9OVU1BX05PREVfSUQ9eQoKIwojIFBvd2VyIG1hbmFnZW1lbnQg
YW5kIEFDUEkgb3B0aW9ucwojCiMgQ09ORklHX1NVU1BFTkQgaXMgbm90IHNldApDT05GSUdfSElC
RVJOQVRFX0NBTExCQUNLUz15CiMgQ09ORklHX0hJQkVSTkFUSU9OIGlzIG5vdCBzZXQKQ09ORklH
X1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMgQ09ORklHX1BNX0FVVE9TTEVFUCBp
cyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1JV
TlRJTUUgaXMgbm90IHNldApDT05GSUdfUE09eQpDT05GSUdfUE1fREVCVUc9eQojIENPTkZJR19Q
TV9BRFZBTkNFRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19QTV9TTEVFUF9ERUJVRz15CiMgQ09O
RklHX1BNX1RSQUNFX1JUQyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJPXkKQ09ORklHX0FDUElfUFJP
Q0ZTPXkKIyBDT05GSUdfQUNQSV9QUk9DRlNfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19BQ1BJ
X0VDX0RFQlVHRlMgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX1BST0NfRVZFTlQgaXMgbm90IHNl
dApDT05GSUdfQUNQSV9BQz15CkNPTkZJR19BQ1BJX0JBVFRFUlk9eQpDT05GSUdfQUNQSV9CVVRU
T049eQpDT05GSUdfQUNQSV9WSURFTz15CkNPTkZJR19BQ1BJX0ZBTj15CiMgQ09ORklHX0FDUElf
RE9DSyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19BQ1BJX0hPVFBM
VUdfQ1BVPXkKIyBDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUiBpcyBub3Qgc2V0CkNP
TkZJR19BQ1BJX1RIRVJNQUw9eQpDT05GSUdfQUNQSV9OVU1BPXkKIyBDT05GSUdfQUNQSV9DVVNU
T01fRFNEVCBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdf
QUNQSV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9Q
TV9USU1FUj15CkNPTkZJR19BQ1BJX0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfU0JTIGlzIG5v
dCBzZXQKQ09ORklHX0FDUElfSEVEPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fTUVUSE9EIGlzIG5v
dCBzZXQKIyBDT05GSUdfQUNQSV9BUEVJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZJIGlzIG5vdCBz
ZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdfQ1BVX0ZSRVE9eQpDT05GSUdf
Q1BVX0ZSRVFfVEFCTEU9eQojIENPTkZJR19DUFVfRlJFUV9TVEFUIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfUEVSRk9STUFOQ0UgaXMgbm90IHNldApDT05GSUdfQ1BV
X0ZSRVFfREVGQVVMVF9HT1ZfVVNFUlNQQUNFPXkKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9H
T1ZfT05ERU1BTkQgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05T
RVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfR09WX1BFUkZPUk1BTkNFPXkKIyBD
T05GSUdfQ1BVX0ZSRVFfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9H
T1ZfVVNFUlNQQUNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9PTkRFTUFORD15CiMgQ09ORklHX0NQ
VV9GUkVRX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldAoKIwojIHg4NiBDUFUgZnJlcXVlbmN5
IHNjYWxpbmcgZHJpdmVycwojCkNPTkZJR19YODZfUENDX0NQVUZSRVE9eQpDT05GSUdfWDg2X0FD
UElfQ1BVRlJFUT15CkNPTkZJR19YODZfQUNQSV9DUFVGUkVRX0NQQj15CiMgQ09ORklHX1g4Nl9Q
T1dFUk5PV19LOCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk8gaXMg
bm90IHNldAojIENPTkZJR19YODZfUDRfQ0xPQ0tNT0QgaXMgbm90IHNldAoKIwojIHNoYXJlZCBv
cHRpb25zCiMKIyBDT05GSUdfWDg2X1NQRUVEU1RFUF9MSUIgaXMgbm90IHNldApDT05GSUdfQ1BV
X0lETEU9eQpDT05GSUdfQ1BVX0lETEVfR09WX0xBRERFUj15CkNPTkZJR19DUFVfSURMRV9HT1Zf
TUVOVT15CiMgQ09ORklHX0FSQ0hfTkVFRFNfQ1BVX0lETEVfQ09VUExFRCBpcyBub3Qgc2V0CiMg
Q09ORklHX0lOVEVMX0lETEUgaXMgbm90IHNldAoKIwojIE1lbW9yeSBwb3dlciBzYXZpbmdzCiMK
IyBDT05GSUdfSTczMDBfSURMRSBpcyBub3Qgc2V0CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMu
KQojCkNPTkZJR19QQ0k9eQpDT05GSUdfUENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05GSUc9
eQpDT05GSUdfUENJX1hFTj15CkNPTkZJR19QQ0lfRE9NQUlOUz15CkNPTkZJR19QQ0lFUE9SVEJV
Uz15CkNPTkZJR19IT1RQTFVHX1BDSV9QQ0lFPXkKQ09ORklHX1BDSUVBRVI9eQpDT05GSUdfUENJ
RV9FQ1JDPXkKQ09ORklHX1BDSUVBRVJfSU5KRUNUPXkKQ09ORklHX1BDSUVBU1BNPXkKQ09ORklH
X1BDSUVBU1BNX0RFQlVHPXkKQ09ORklHX1BDSUVBU1BNX0RFRkFVTFQ9eQojIENPTkZJR19QQ0lF
QVNQTV9QT1dFUlNBVkUgaXMgbm90IHNldAojIENPTkZJR19QQ0lFQVNQTV9QRVJGT1JNQU5DRSBp
cyBub3Qgc2V0CkNPTkZJR19BUkNIX1NVUFBPUlRTX01TST15CkNPTkZJR19QQ0lfTVNJPXkKQ09O
RklHX1BDSV9ERUJVRz15CkNPTkZJR19QQ0lfUkVBTExPQ19FTkFCTEVfQVVUTz15CiMgQ09ORklH
X1BDSV9TVFVCIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9QQ0lERVZfRlJPTlRFTkQ9eQpDT05GSUdf
SFRfSVJRPXkKQ09ORklHX1BDSV9BVFM9eQpDT05GSUdfUENJX0lPVj15CkNPTkZJR19QQ0lfUFJJ
PXkKQ09ORklHX1BDSV9QQVNJRD15CkNPTkZJR19QQ0lfSU9BUElDPXkKQ09ORklHX1BDSV9MQUJF
TD15CkNPTkZJR19JU0FfRE1BX0FQST15CkNPTkZJR19BTURfTkI9eQpDT05GSUdfUENDQVJEPXkK
IyBDT05GSUdfUENNQ0lBIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FSREJVUyBpcyBub3Qgc2V0Cgoj
CiMgUEMtY2FyZCBicmlkZ2VzCiMKIyBDT05GSUdfWUVOVEEgaXMgbm90IHNldApDT05GSUdfSE9U
UExVR19QQ0k9eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQST15CkNPTkZJR19IT1RQTFVHX1BDSV9B
Q1BJX0lCTT15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJPXkKQ09ORklHX0hPVFBMVUdfUENJX0NQ
Q0lfWlQ1NTUwPXkKQ09ORklHX0hPVFBMVUdfUENJX0NQQ0lfR0VORVJJQz15CkNPTkZJR19IT1RQ
TFVHX1BDSV9TSFBDPXkKIyBDT05GSUdfUkFQSURJTyBpcyBub3Qgc2V0CgojCiMgRXhlY3V0YWJs
ZSBmaWxlIGZvcm1hdHMgLyBFbXVsYXRpb25zCiMKQ09ORklHX0JJTkZNVF9FTEY9eQpDT05GSUdf
Q09NUEFUX0JJTkZNVF9FTEY9eQpDT05GSUdfQVJDSF9CSU5GTVRfRUxGX1JBTkRPTUlaRV9QSUU9
eQpDT05GSUdfQ09SRV9EVU1QX0RFRkFVTFRfRUxGX0hFQURFUlM9eQojIENPTkZJR19IQVZFX0FP
VVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9eQpDT05GSUdfQ09SRURVTVA9eQpDT05G
SUdfSUEzMl9FTVVMQVRJT049eQojIENPTkZJR19JQTMyX0FPVVQgaXMgbm90IHNldAojIENPTkZJ
R19YODZfWDMyIGlzIG5vdCBzZXQKQ09ORklHX0NPTVBBVD15CkNPTkZJR19DT01QQVRfRk9SX1U2
NF9BTElHTk1FTlQ9eQpDT05GSUdfU1lTVklQQ19DT01QQVQ9eQpDT05GSUdfSEFWRV9URVhUX1BP
S0VfU01QPXkKQ09ORklHX1g4Nl9ERVZfRE1BX09QUz15CkNPTkZJR19ORVQ9eQoKIwojIE5ldHdv
cmtpbmcgb3B0aW9ucwojCkNPTkZJR19QQUNLRVQ9eQojIENPTkZJR19QQUNLRVRfRElBRyBpcyBu
b3Qgc2V0CkNPTkZJR19VTklYPXkKIyBDT05GSUdfVU5JWF9ESUFHIGlzIG5vdCBzZXQKIyBDT05G
SUdfWEZSTV9VU0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0tFWSBpcyBub3Qgc2V0CkNPTkZJ
R19JTkVUPXkKQ09ORklHX0lQX01VTFRJQ0FTVD15CkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9
eQojIENPTkZJR19JUF9GSUJfVFJJRV9TVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19JUF9NVUxUSVBM
RV9UQUJMRVM9eQpDT05GSUdfSVBfUk9VVEVfTVVMVElQQVRIPXkKQ09ORklHX0lQX1JPVVRFX1ZF
UkJPU0U9eQpDT05GSUdfSVBfUk9VVEVfQ0xBU1NJRD15CkNPTkZJR19JUF9QTlA9eQpDT05GSUdf
SVBfUE5QX0RIQ1A9eQpDT05GSUdfSVBfUE5QX0JPT1RQPXkKQ09ORklHX0lQX1BOUF9SQVJQPXkK
IyBDT05GSUdfTkVUX0lQSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfSVBHUkVfREVNVVggaXMg
bm90IHNldApDT05GSUdfSVBfTVJPVVRFPXkKIyBDT05GSUdfSVBfTVJPVVRFX01VTFRJUExFX1RB
QkxFUyBpcyBub3Qgc2V0CkNPTkZJR19JUF9QSU1TTV9WMT15CkNPTkZJR19JUF9QSU1TTV9WMj15
CiMgQ09ORklHX0FSUEQgaXMgbm90IHNldApDT05GSUdfU1lOX0NPT0tJRVM9eQojIENPTkZJR19J
TkVUX0FIIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9FU1AgaXMgbm90IHNldAojIENPTkZJR19J
TkVUX0lQQ09NUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9UVU5ORUwgaXMgbm90IHNl
dAojIENPTkZJR19JTkVUX1RVTk5FTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9NT0RF
X1RSQU5TUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9NT0RFX1RVTk5FTCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lORVRfWEZSTV9NT0RFX0JFRVQgaXMgbm90IHNldApDT05GSUdfSU5F
VF9MUk89eQojIENPTkZJR19JTkVUX0RJQUcgaXMgbm90IHNldApDT05GSUdfVENQX0NPTkdfQURW
QU5DRUQ9eQojIENPTkZJR19UQ1BfQ09OR19CSUMgaXMgbm90IHNldApDT05GSUdfVENQX0NPTkdf
Q1VCSUM9eQojIENPTkZJR19UQ1BfQ09OR19XRVNUV09PRCBpcyBub3Qgc2V0CiMgQ09ORklHX1RD
UF9DT05HX0hUQ1AgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19IU1RDUCBpcyBub3Qgc2V0
CiMgQ09ORklHX1RDUF9DT05HX0hZQkxBIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfVkVH
QVMgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19TQ0FMQUJMRSBpcyBub3Qgc2V0CiMgQ09O
RklHX1RDUF9DT05HX0xQIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfVkVOTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1RDUF9DT05HX1lFQUggaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19J
TExJTk9JUyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NVQklDPXkKIyBDT05GSUdfREVGQVVM
VF9SRU5PIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfVENQX0NPTkc9ImN1YmljIgojIENPTkZJ
R19UQ1BfTUQ1U0lHIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNiBpcyBub3Qgc2V0CkNPTkZJR19O
RVRXT1JLX1NFQ01BUks9eQojIENPTkZJR19ORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgaXMgbm90
IHNldApDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5vdCBz
ZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNFRD15CkNPTkZJR19CUklER0VfTkVURklMVEVSPXkK
CiMKIyBDb3JlIE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKQ09ORklHX05FVEZJTFRFUl9ORVRM
SU5LPXkKQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX0FDQ1Q9eQpDT05GSUdfTkVURklMVEVSX05F
VExJTktfUVVFVUU9eQpDT05GSUdfTkVURklMVEVSX05FVExJTktfTE9HPXkKQ09ORklHX05GX0NP
Tk5UUkFDSz15CkNPTkZJR19ORl9DT05OVFJBQ0tfTUFSSz15CkNPTkZJR19ORl9DT05OVFJBQ0tf
U0VDTUFSSz15CkNPTkZJR19ORl9DT05OVFJBQ0tfUFJPQ0ZTPXkKQ09ORklHX05GX0NPTk5UUkFD
S19FVkVOVFM9eQojIENPTkZJR19ORl9DT05OVFJBQ0tfVElNRU9VVCBpcyBub3Qgc2V0CkNPTkZJ
R19ORl9DT05OVFJBQ0tfVElNRVNUQU1QPXkKIyBDT05GSUdfTkZfQ1RfUFJPVE9fRENDUCBpcyBu
b3Qgc2V0CkNPTkZJR19ORl9DVF9QUk9UT19HUkU9eQojIENPTkZJR19ORl9DVF9QUk9UT19TQ1RQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ1RfUFJPVE9fVURQTElURSBpcyBub3Qgc2V0CiMgQ09O
RklHX05GX0NPTk5UUkFDS19BTUFOREEgaXMgbm90IHNldApDT05GSUdfTkZfQ09OTlRSQUNLX0ZU
UD15CkNPTkZJR19ORl9DT05OVFJBQ0tfSDMyMz15CkNPTkZJR19ORl9DT05OVFJBQ0tfSVJDPXkK
IyBDT05GSUdfTkZfQ09OTlRSQUNLX05FVEJJT1NfTlMgaXMgbm90IHNldAojIENPTkZJR19ORl9D
T05OVFJBQ0tfU05NUCBpcyBub3Qgc2V0CkNPTkZJR19ORl9DT05OVFJBQ0tfUFBUUD15CiMgQ09O
RklHX05GX0NPTk5UUkFDS19TQU5FIGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5UUkFDS19TSVA9
eQojIENPTkZJR19ORl9DT05OVFJBQ0tfVEZUUCBpcyBub3Qgc2V0CkNPTkZJR19ORl9DVF9ORVRM
SU5LPXkKIyBDT05GSUdfTkZfQ1RfTkVUTElOS19USU1FT1VUIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkVURklMVEVSX05FVExJTktfUVVFVUVfQ1QgaXMgbm90IHNldApDT05GSUdfTkZfTkFUPXkKQ09O
RklHX05GX05BVF9ORUVERUQ9eQojIENPTkZJR19ORl9OQVRfQU1BTkRBIGlzIG5vdCBzZXQKQ09O
RklHX05GX05BVF9GVFA9eQpDT05GSUdfTkZfTkFUX0lSQz15CkNPTkZJR19ORl9OQVRfU0lQPXkK
IyBDT05GSUdfTkZfTkFUX1RGVFAgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfVFBST1hZ
IGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVEFCTEVTPXkKCiMKIyBYdGFibGVzIGNvbWJp
bmVkIG1vZHVsZXMKIwpDT05GSUdfTkVURklMVEVSX1hUX01BUks9eQpDT05GSUdfTkVURklMVEVS
X1hUX0NPTk5NQVJLPXkKIyBDT05GSUdfTkVURklMVEVSX1hUX1NFVCBpcyBub3Qgc2V0CgojCiMg
WHRhYmxlcyB0YXJnZXRzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQVVESVQ9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9DSEVDS1NVTT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX0NMQVNTSUZZPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ09OTk1BUks9eQpDT05G
SUdfTkVURklMVEVSX1hUX1RBUkdFVF9DT05OU0VDTUFSSz15CiMgQ09ORklHX05FVEZJTFRFUl9Y
VF9UQVJHRVRfQ1QgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9EU0NQPXkK
Q09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSEw9eQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFS
R0VUX0hNQVJLIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSURMRVRJTUVS
PXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTE9HPXkKQ09ORklHX05FVEZJTFRFUl9YVF9U
QVJHRVRfTUFSSz15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05FVE1BUD15CkNPTkZJR19O
RVRGSUxURVJfWFRfVEFSR0VUX05GTE9HPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTkZR
VUVVRT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1JBVEVFU1Q9eQpDT05GSUdfTkVURklM
VEVSX1hUX1RBUkdFVF9SRURJUkVDVD15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RFRT15
CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfVFJBQ0UgaXMgbm90IHNldApDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9TRUNNQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfVENQ
TVNTPXkKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUCBpcyBub3Qgc2V0
CgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9BRERSVFlQ
RT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0xVU1RFUj15CkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfQ09NTUVOVD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkJZVEVTPXkK
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OTElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hU
X01BVENIX0NPTk5NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJBQ0s9eQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0NQVT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf
RENDUD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9eQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX0RTQ1A9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VDTj15CkNPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfRVNQPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9IQVNI
TElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hFTFBFUj15CkNPTkZJR19ORVRGSUxU
RVJfWFRfTUFUQ0hfSEw9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0U9eQpDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0lQVlM9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xF
TkdUSD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQ9eQpDT05GSUdfTkVURklMVEVS
X1hUX01BVENIX01BQz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz15CkNPTkZJR19O
RVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9O
RkFDQ1Q9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09TRj15CkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfT1dORVI9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BIWVNERVY9eQpDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEU9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X1FVT1RBPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUPXkKQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9SRUFMTT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5UPXkK
IyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFAgaXMgbm90IHNldApDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX1NUQVRFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVEFUSVNUSUM9
eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUUklORz15CkNPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfVENQTVNTPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9USU1FPXkKQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9VMzI9eQpDT05GSUdfSVBfU0VUPXkKQ09ORklHX0lQX1NFVF9NQVg9
MjU2CkNPTkZJR19JUF9TRVRfQklUTUFQX0lQPXkKQ09ORklHX0lQX1NFVF9CSVRNQVBfSVBNQUM9
eQpDT05GSUdfSVBfU0VUX0JJVE1BUF9QT1JUPXkKQ09ORklHX0lQX1NFVF9IQVNIX0lQPXkKQ09O
RklHX0lQX1NFVF9IQVNIX0lQUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9JUFBPUlRJUD15CkNP
TkZJR19JUF9TRVRfSEFTSF9JUFBPUlRORVQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUPXkKQ09O
RklHX0lQX1NFVF9IQVNIX05FVFBPUlQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUSUZBQ0U9eQpD
T05GSUdfSVBfU0VUX0xJU1RfU0VUPXkKQ09ORklHX0lQX1ZTPXkKIyBDT05GSUdfSVBfVlNfREVC
VUcgaXMgbm90IHNldApDT05GSUdfSVBfVlNfVEFCX0JJVFM9MTIKCiMKIyBJUFZTIHRyYW5zcG9y
dCBwcm90b2NvbCBsb2FkIGJhbGFuY2luZyBzdXBwb3J0CiMKIyBDT05GSUdfSVBfVlNfUFJPVE9f
VENQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fVURQIGlzIG5vdCBzZXQKIyBDT05G
SUdfSVBfVlNfUFJPVE9fQUhfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fRVNQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fQUggaXMgbm90IHNldAojIENPTkZJR19J
UF9WU19QUk9UT19TQ1RQIGlzIG5vdCBzZXQKCiMKIyBJUFZTIHNjaGVkdWxlcgojCiMgQ09ORklH
X0lQX1ZTX1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfV1JSIGlzIG5vdCBzZXQKIyBDT05G
SUdfSVBfVlNfTEMgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19XTEMgaXMgbm90IHNldAojIENP
TkZJR19JUF9WU19MQkxDIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTEJMQ1IgaXMgbm90IHNl
dAojIENPTkZJR19JUF9WU19ESCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1ZTX1NIIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSVBfVlNfU0VEIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTlEgaXMgbm90
IHNldAoKIwojIElQVlMgU0ggc2NoZWR1bGVyCiMKQ09ORklHX0lQX1ZTX1NIX1RBQl9CSVRTPTgK
CiMKIyBJUFZTIGFwcGxpY2F0aW9uIGhlbHBlcgojCkNPTkZJR19JUF9WU19ORkNUPXkKCiMKIyBJ
UDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05G
SUdfTkZfQ09OTlRSQUNLX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkK
IyBDT05GSUdfSVBfTkZfUVVFVUUgaXMgbm90IHNldApDT05GSUdfSVBfTkZfSVBUQUJMRVM9eQpD
T05GSUdfSVBfTkZfTUFUQ0hfQUg9eQpDT05GSUdfSVBfTkZfTUFUQ0hfRUNOPXkKIyBDT05GSUdf
SVBfTkZfTUFUQ0hfUlBGSUxURVIgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTUFUQ0hfVFRMPXkK
Q09ORklHX0lQX05GX0ZJTFRFUj15CkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPXkKQ09ORklH
X0lQX05GX1RBUkdFVF9VTE9HPXkKQ09ORklHX05GX05BVF9JUFY0PXkKQ09ORklHX0lQX05GX1RB
UkdFVF9NQVNRVUVSQURFPXkKQ09ORklHX0lQX05GX1RBUkdFVF9ORVRNQVA9eQpDT05GSUdfSVBf
TkZfVEFSR0VUX1JFRElSRUNUPXkKQ09ORklHX05GX05BVF9QUk9UT19HUkU9eQpDT05GSUdfTkZf
TkFUX1BQVFA9eQpDT05GSUdfTkZfTkFUX0gzMjM9eQpDT05GSUdfSVBfTkZfTUFOR0xFPXkKIyBD
T05GSUdfSVBfTkZfVEFSR0VUX0NMVVNURVJJUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1RB
UkdFVF9FQ04gaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9UQVJHRVRfVFRMIGlzIG5vdCBzZXQK
Q09ORklHX0lQX05GX1JBVz15CiMgQ09ORklHX0lQX05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0CkNP
TkZJR19CUklER0VfTkZfRUJUQUJMRVM9eQojIENPTkZJR19CUklER0VfRUJUX0JST1VURSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfVF9GSUxURVIgaXMgbm90IHNldAojIENPTkZJR19C
UklER0VfRUJUX1RfTkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF84MDJfMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfQU1PTkcgaXMgbm90IHNldAojIENPTkZJR19CUklE
R0VfRUJUX0FSUCBpcyBub3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfSVAgaXMgbm90IHNldAoj
IENPTkZJR19CUklER0VfRUJUX0xJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9N
QVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9QS1RUWVBFIGlzIG5vdCBzZXQKIyBD
T05GSUdfQlJJREdFX0VCVF9TVFAgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1ZMQU4g
aXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX0FSUFJFUExZIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlJJREdFX0VCVF9ETkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9NQVJLX1Qg
aXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1JFRElSRUNUIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlJJREdFX0VCVF9TTkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9MT0cgaXMg
bm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1VMT0cgaXMgbm90IHNldAojIENPTkZJR19CUklE
R0VfRUJUX05GTE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfRENDUCBpcyBub3Qgc2V0CiMgQ09O
RklHX0lQX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19SRFMgaXMgbm90IHNldAojIENPTkZJR19U
SVBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTDJUUCBpcyBu
b3Qgc2V0CkNPTkZJR19TVFA9eQpDT05GSUdfQlJJREdFPXkKQ09ORklHX0JSSURHRV9JR01QX1NO
T09QSU5HPXkKIyBDT05GSUdfTkVUX0RTQSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZMQU5fODAyMVEg
aXMgbm90IHNldAojIENPTkZJR19ERUNORVQgaXMgbm90IHNldApDT05GSUdfTExDPXkKIyBDT05G
SUdfTExDMiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxL
IGlzIG5vdCBzZXQKIyBDT05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qg
c2V0CiMgQ09ORklHX1dBTl9ST1VURVIgaXMgbm90IHNldAojIENPTkZJR19QSE9ORVQgaXMgbm90
IHNldAojIENPTkZJR19JRUVFODAyMTU0IGlzIG5vdCBzZXQKQ09ORklHX05FVF9TQ0hFRD15Cgoj
CiMgUXVldWVpbmcvU2NoZWR1bGluZwojCiMgQ09ORklHX05FVF9TQ0hfQ0JRIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1NDSF9IVEIgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0hGU0MgaXMg
bm90IHNldAojIENPTkZJR19ORVRfU0NIX1BSSU8gaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NI
X01VTFRJUSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUkVEIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX1NDSF9TRkIgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1NGUSBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9TQ0hfVEVRTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfVEJGIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9HUkVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ND
SF9EU01BUksgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX05FVEVNIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1NDSF9EUlIgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX01RUFJJTyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfQ0hPS0UgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NI
X1FGUSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfQ09ERUwgaXMgbm90IHNldAojIENPTkZJ
R19ORVRfU0NIX0ZRX0NPREVMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9JTkdSRVNTIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9QTFVHIGlzIG5vdCBzZXQKCiMKIyBDbGFzc2lmaWNh
dGlvbgojCkNPTkZJR19ORVRfQ0xTPXkKIyBDT05GSUdfTkVUX0NMU19CQVNJQyBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9DTFNfVENJTkRFWCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfUk9V
VEU0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19GVyBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VF9DTFNfVTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19SU1ZQIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX0NMU19SU1ZQNiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfRkxPVyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9DTFNfQ0dST1VQIGlzIG5vdCBzZXQKQ09ORklHX05FVF9FTUFU
Q0g9eQpDT05GSUdfTkVUX0VNQVRDSF9TVEFDSz0zMgojIENPTkZJR19ORVRfRU1BVENIX0NNUCBp
cyBub3Qgc2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfTkJZVEUgaXMgbm90IHNldAojIENPTkZJR19O
RVRfRU1BVENIX1UzMiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfTUVUQSBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfVEVYVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9FTUFU
Q0hfSVBTRVQgaXMgbm90IHNldApDT05GSUdfTkVUX0NMU19BQ1Q9eQojIENPTkZJR19ORVRfQUNU
X1BPTElDRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfR0FDVCBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVF9BQ1RfTUlSUkVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0FDVF9JUFQgaXMgbm90
IHNldAojIENPTkZJR19ORVRfQUNUX05BVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfUEVE
SVQgaXMgbm90IHNldAojIENPTkZJR19ORVRfQUNUX1NJTVAgaXMgbm90IHNldAojIENPTkZJR19O
RVRfQUNUX1NLQkVESVQgaXMgbm90IHNldAojIENPTkZJR19ORVRfQUNUX0NTVU0gaXMgbm90IHNl
dApDT05GSUdfTkVUX1NDSF9GSUZPPXkKIyBDT05GSUdfRENCIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkFUTUFOX0FEViBpcyBub3Qgc2V0CiMgQ09ORklHX09QRU5WU1dJVENIIGlzIG5vdCBzZXQKQ09O
RklHX1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKIyBDT05GSUdfTkVUUFJJ
T19DR1JPVVAgaXMgbm90IHNldApDT05GSUdfQlFMPXkKIyBDT05GSUdfQlBGX0pJVCBpcyBub3Qg
c2V0CgojCiMgTmV0d29yayB0ZXN0aW5nCiMKIyBDT05GSUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0
CiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOIGlzIG5vdCBzZXQKIyBD
T05GSUdfSVJEQSBpcyBub3Qgc2V0CkNPTkZJR19CVD15CkNPTkZJR19CVF9SRkNPTU09eQpDT05G
SUdfQlRfUkZDT01NX1RUWT15CkNPTkZJR19CVF9CTkVQPXkKQ09ORklHX0JUX0JORVBfTUNfRklM
VEVSPXkKQ09ORklHX0JUX0JORVBfUFJPVE9fRklMVEVSPXkKQ09ORklHX0JUX0hJRFA9eQoKIwoj
IEJsdWV0b290aCBkZXZpY2UgZHJpdmVycwojCkNPTkZJR19CVF9IQ0lCVFVTQj15CkNPTkZJR19C
VF9IQ0lVQVJUPXkKQ09ORklHX0JUX0hDSVVBUlRfSDQ9eQpDT05GSUdfQlRfSENJVUFSVF9CQ1NQ
PXkKQ09ORklHX0JUX0hDSVVBUlRfQVRIM0s9eQpDT05GSUdfQlRfSENJVUFSVF9MTD15CkNPTkZJ
R19CVF9IQ0lVQVJUXzNXSVJFPXkKQ09ORklHX0JUX0hDSUJDTTIwM1g9eQpDT05GSUdfQlRfSENJ
QlBBMTBYPXkKQ09ORklHX0JUX0hDSUJGVVNCPXkKQ09ORklHX0JUX0hDSVZIQ0k9eQpDT05GSUdf
QlRfTVJWTD15CkNPTkZJR19CVF9BVEgzSz15CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQK
Q09ORklHX0ZJQl9SVUxFUz15CkNPTkZJR19XSVJFTEVTUz15CiMgQ09ORklHX0NGRzgwMjExIGlz
IG5vdCBzZXQKIyBDT05GSUdfTElCODAyMTEgaXMgbm90IHNldAoKIwojIENGRzgwMjExIG5lZWRz
IHRvIGJlIGVuYWJsZWQgZm9yIE1BQzgwMjExCiMKIyBDT05GSUdfV0lNQVggaXMgbm90IHNldAoj
IENPTkZJR19SRktJTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENP
TkZJR19DQUlGIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAojIENPTkZJ
R19ORkMgaXMgbm90IHNldApDT05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVy
cwojCgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BB
VEg9Ii9zYmluL2hvdHBsdWciCiMgQ09ORklHX0RFVlRNUEZTIGlzIG5vdCBzZXQKQ09ORklHX1NU
QU5EQUxPTkU9eQpDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlMRD15CkNPTkZJR19GV19MT0FE
RVI9eQpDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMPXkKQ09ORklHX0VYVFJBX0ZJUk1XQVJFPSIi
CiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19ERVZSRVM9eQpD
T05GSUdfU1lTX0hZUEVSVklTT1I9eQojIENPTkZJR19HRU5FUklDX0NQVV9ERVZJQ0VTIGlzIG5v
dCBzZXQKQ09ORklHX0RNQV9TSEFSRURfQlVGRkVSPXkKCiMKIyBCdXMgZGV2aWNlcwojCiMgQ09O
RklHX09NQVBfT0NQMlNDUCBpcyBub3Qgc2V0CkNPTkZJR19DT05ORUNUT1I9eQpDT05GSUdfUFJP
Q19FVkVOVFM9eQojIENPTkZJR19NVEQgaXMgbm90IHNldAojIENPTkZJR19QQVJQT1JUIGlzIG5v
dCBzZXQKQ09ORklHX1BOUD15CkNPTkZJR19QTlBfREVCVUdfTUVTU0FHRVM9eQoKIwojIFByb3Rv
Y29scwojCkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JMS19ERVY9eQojIENPTkZJR19CTEtfREVW
X0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9QQ0lFU1NEX01USVAzMlhYIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19DUFFfQ0lTU19E
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkxLX0RFVl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5v
dCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5U
PTgKIyBDT05GSUdfQkxLX0RFVl9DUllQVE9MT09QIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9EUkJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJ
R19CTEtfREVWX05WTUUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NYOCBpcyBub3Qgc2V0
CkNPTkZJR19CTEtfREVWX1JBTT15CkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdf
QkxLX0RFVl9SQU1fU0laRT0xNjM4NAojIENPTkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CiMg
Q09ORklHX0NEUk9NX1BLVENEVkQgaXMgbm90IHNldAojIENPTkZJR19BVEFfT1ZFUl9FVEggaXMg
bm90IHNldApDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxLREVWX0JB
Q0tFTkQ9eQojIENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9S
QkQgaXMgbm90IHNldAoKIwojIE1pc2MgZGV2aWNlcwojCiMgQ09ORklHX1NFTlNPUlNfTElTM0xW
MDJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19J
Qk1fQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
VEVMX01JRF9QVEkgaXMgbm90IHNldAojIENPTkZJR19TR0lfSU9DNCBpcyBub3Qgc2V0CiMgQ09O
RklHX1RJRk1fQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lDUzkzMlM0MDEgaXMgbm90IHNldAoj
IENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldAojIENPTkZJR19IUF9JTE8gaXMg
bm90IHNldAojIENPTkZJR19BUERTOTgwMkFMUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDAz
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X1RTTDI1NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc4MCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BUERTOTkw
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90IHNldAojIENPTkZJR19EUzE2ODIg
aXMgbm90IHNldAojIENPTkZJR19WTVdBUkVfQkFMTE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0JN
UDA4NV9JMkMgaXMgbm90IHNldAojIENPTkZJR19QQ0hfUEhVQiBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9TV0lUQ0hfRlNBOTQ4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0MyUE9SVCBpcyBub3Qgc2V0
CgojCiMgRUVQUk9NIHN1cHBvcnQKIwojIENPTkZJR19FRVBST01fQVQyNCBpcyBub3Qgc2V0CiMg
Q09ORklHX0VFUFJPTV9MRUdBQ1kgaXMgbm90IHNldAojIENPTkZJR19FRVBST01fTUFYNjg3NSBp
cyBub3Qgc2V0CiMgQ09ORklHX0VFUFJPTV85M0NYNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NCNzEw
X0NPUkUgaXMgbm90IHNldAoKIwojIFRleGFzIEluc3RydW1lbnRzIHNoYXJlZCB0cmFuc3BvcnQg
bGluZSBkaXNjaXBsaW5lCiMKIyBDT05GSUdfU0VOU09SU19MSVMzX0kyQyBpcyBub3Qgc2V0Cgoj
CiMgQWx0ZXJhIEZQR0EgZmlybXdhcmUgZG93bmxvYWQgbW9kdWxlCiMKQ09ORklHX0FMVEVSQV9T
VEFQTD15CiMgQ09ORklHX0lOVEVMX01FSSBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0lERT15CiMg
Q09ORklHX0lERSBpcyBub3Qgc2V0CgojCiMgU0NTSSBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19T
Q1NJX01PRD15CiMgQ09ORklHX1JBSURfQVRUUlMgaXMgbm90IHNldApDT05GSUdfU0NTST15CkNP
TkZJR19TQ1NJX0RNQT15CiMgQ09ORklHX1NDU0lfVEdUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT
SV9ORVRMSU5LIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfUFJPQ19GUz15CgojCiMgU0NTSSBzdXBw
b3J0IHR5cGUgKGRpc2ssIHRhcGUsIENELVJPTSkKIwpDT05GSUdfQkxLX0RFVl9TRD15CiMgQ09O
RklHX0NIUl9ERVZfU1QgaXMgbm90IHNldAojIENPTkZJR19DSFJfREVWX09TU1QgaXMgbm90IHNl
dApDT05GSUdfQkxLX0RFVl9TUj15CkNPTkZJR19CTEtfREVWX1NSX1ZFTkRPUj15CkNPTkZJR19D
SFJfREVWX1NHPXkKIyBDT05GSUdfQ0hSX0RFVl9TQ0ggaXMgbm90IHNldAojIENPTkZJR19TQ1NJ
X01VTFRJX0xVTiBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0NPTlNUQU5UUz15CiMgQ09ORklHX1ND
U0lfTE9HR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0NBTl9BU1lOQyBpcyBub3Qgc2V0
CgojCiMgU0NTSSBUcmFuc3BvcnRzCiMKQ09ORklHX1NDU0lfU1BJX0FUVFJTPXkKIyBDT05GSUdf
U0NTSV9GQ19BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSVNDU0lfQVRUUlMgaXMgbm90
IHNldAojIENPTkZJR19TQ1NJX1NBU19BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0FT
X0xJQlNBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU1JQX0FUVFJTIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0NTSV9MT1dMRVZFTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREggaXMgbm90IHNl
dAojIENPTkZJR19TQ1NJX09TRF9JTklUSUFUT1IgaXMgbm90IHNldApDT05GSUdfQVRBPXkKIyBD
T05GSUdfQVRBX05PTlNUQU5EQVJEIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9WRVJCT1NFX0VSUk9S
PXkKQ09ORklHX0FUQV9BQ1BJPXkKQ09ORklHX1NBVEFfUE1QPXkKCiMKIyBDb250cm9sbGVycyB3
aXRoIG5vbi1TRkYgbmF0aXZlIGludGVyZmFjZQojCkNPTkZJR19TQVRBX0FIQ0k9eQpDT05GSUdf
U0FUQV9BSENJX1BMQVRGT1JNPXkKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NBVEFfQUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMMjQgaXMg
bm90IHNldAojIENPTkZJR19BVEFfU0ZGIGlzIG5vdCBzZXQKQ09ORklHX01EPXkKIyBDT05GSUdf
QkxLX0RFVl9NRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0RNPXkKQ09ORklHX0RNX0RFQlVH
PXkKQ09ORklHX0RNX0NSWVBUPXkKQ09ORklHX0RNX1NOQVBTSE9UPXkKIyBDT05GSUdfRE1fVEhJ
Tl9QUk9WSVNJT05JTkcgaXMgbm90IHNldApDT05GSUdfRE1fTUlSUk9SPXkKIyBDT05GSUdfRE1f
UkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0xPR19VU0VSU1BBQ0UgaXMgbm90IHNldApDT05G
SUdfRE1fWkVSTz15CiMgQ09ORklHX0RNX01VTFRJUEFUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0RN
X0RFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fVUVWRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdf
RE1fRkxBS0VZIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fVkVSSVRZIGlzIG5vdCBzZXQKIyBDT05G
SUdfVEFSR0VUX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19GVVNJT04gaXMgbm90IHNldAoKIwoj
IElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQKIwojIENPTkZJR19GSVJFV0lSRSBpcyBub3Qg
c2V0CiMgQ09ORklHX0ZJUkVXSVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJR19JMk8gaXMgbm90
IHNldAojIENPTkZJR19NQUNJTlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJ
Q0VTPXkKQ09ORklHX05FVF9DT1JFPXkKIyBDT05GSUdfQk9ORElORyBpcyBub3Qgc2V0CiMgQ09O
RklHX0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0ZDIGlzIG5vdCBzZXQKQ09ORklHX01JST15CiMgQ09ORklHX0lGQiBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9URUFNIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDVkxBTiBpcyBub3Qgc2V0
CiMgQ09ORklHX1ZYTEFOIGlzIG5vdCBzZXQKQ09ORklHX05FVENPTlNPTEU9eQpDT05GSUdfTkVU
UE9MTD15CiMgQ09ORklHX05FVFBPTExfVFJBUCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfUE9MTF9D
T05UUk9MTEVSPXkKQ09ORklHX1RVTj15CkNPTkZJR19WRVRIPXkKIyBDT05GSUdfQVJDTkVUIGlz
IG5vdCBzZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMKQ09ORklHX0VUSEVSTkVUPXkK
IyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9B
REFQVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9BTFRFT04gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQVRI
RVJPUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQlJPQURDT00gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX0JST0NBREUgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0FMWEVE
QV9YR01BQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQ0hFTFNJTyBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9WRU5ET1JfQ0lTQ08gaXMgbm90IHNldAojIENPTkZJR19ETkVUIGlzIG5v
dCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9ERUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX0RMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9FTVVMRVggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfVkVORE9SX0VYQVIgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X0hQIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfSU5URUw9eQojIENPTkZJR19FMTAwIGlz
IG5vdCBzZXQKQ09ORklHX0UxMDAwPXkKQ09ORklHX0UxMDAwRT15CkNPTkZJR19JR0I9eQojIENP
TkZJR19JR0JfUFRQIGlzIG5vdCBzZXQKQ09ORklHX0lHQlZGPXkKIyBDT05GSUdfSVhHQiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lYR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVhHQkVWRiBpcyBub3Qg
c2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX1pORVQgaXMgbm90IHNldAoj
IENPTkZJR19JUDEwMDAgaXMgbm90IHNldAojIENPTkZJR19KTUUgaXMgbm90IHNldAojIENPTkZJ
R19ORVRfVkVORE9SX01BUlZFTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX01FTExB
Tk9YIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9NSUNSRUwgaXMgbm90IHNldAojIENP
TkZJR19ORVRfVkVORE9SX01ZUkkgaXMgbm90IHNldAojIENPTkZJR19GRUFMTlggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfVkVORE9SX05BVFNFTUkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX05WSURJQSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfT0tJIGlzIG5vdCBzZXQK
IyBDT05GSUdfRVRIT0MgaXMgbm90IHNldAojIENPTkZJR19ORVRfUEFDS0VUX0VOR0lORSBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfUUxPR0lDIGlzIG5vdCBzZXQKQ09ORklHX05FVF9W
RU5ET1JfUkVBTFRFSz15CiMgQ09ORklHXzgxMzlDUCBpcyBub3Qgc2V0CiMgQ09ORklHXzgxMzlU
T08gaXMgbm90IHNldApDT05GSUdfUjgxNjk9eQojIENPTkZJR19ORVRfVkVORE9SX1JEQyBpcyBu
b3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NFRVE9eQojIENPTkZJR19TRUVRODAwNSBpcyBub3Qg
c2V0CkNPTkZJR19ORVRfVkVORE9SX1NJTEFOPXkKIyBDT05GSUdfU0M5MjAzMSBpcyBub3Qgc2V0
CiMgQ09ORklHX05FVF9WRU5ET1JfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRP
Ul9TVE1JQ1JPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TVU4gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX1RFSFVUSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1Jf
VEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1ZJQSBpcyBub3Qgc2V0CkNPTkZJR19O
RVRfVkVORE9SX1dJWk5FVD15CiMgQ09ORklHX1dJWk5FVF9XNTEwMCBpcyBub3Qgc2V0CiMgQ09O
RklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMgbm90IHNldAojIENP
TkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldApDT05G
SUdfUEhZTElCPXkKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJzCiMKIyBDT05GSUdfQVQ4MDNY
X1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NQVJW
RUxMX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RBVklDT01fUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfUVNFTUlfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09O
RklHX0NJQ0FEQV9QSFkgaXMgbm90IHNldAojIENPTkZJR19WSVRFU1NFX1BIWSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NNU0NfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJPQURDT01fUEhZIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkNNODdYWF9QSFkgaXMgbm90IHNldAojIENPTkZJR19JQ1BMVVNfUEhZ
IGlzIG5vdCBzZXQKQ09ORklHX1JFQUxURUtfUEhZPXkKIyBDT05GSUdfTkFUSU9OQUxfUEhZIGlz
IG5vdCBzZXQKIyBDT05GSUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xTSV9FVDEwMTFD
X1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNldAojIENPTkZJR19G
SVhFRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcgaXMgbm90IHNldAojIENP
TkZJR19QUFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBVU0IgTmV0
d29yayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfVVNCTkVUIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0lQSEVUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1dMQU4gaXMgbm90IHNldAoK
IwojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBzZWUgdGhlIFdpTUFYIGRy
aXZlcnMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldApDT05GSUdfWEVOX05FVERFVl9GUk9OVEVO
RD15CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQojIENPTkZJR19WTVhORVQzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CgojCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpD
T05GSUdfSU5QVVQ9eQpDT05GSUdfSU5QVVRfRkZfTUVNTEVTUz15CkNPTkZJR19JTlBVVF9QT0xM
REVWPXkKQ09ORklHX0lOUFVUX1NQQVJTRUtNQVA9eQojIENPTkZJR19JTlBVVF9NQVRSSVhLTUFQ
IGlzIG5vdCBzZXQKCiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01PVVNF
REVWPXkKIyBDT05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVggaXMgbm90IHNldApDT05GSUdfSU5Q
VVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9
NzY4CiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRFVj15
CiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJpdmVy
cwojCkNPTkZJR19JTlBVVF9LRVlCT0FSRD15CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODggaXMg
bm90IHNldAojIENPTkZJR19LRVlCT0FSRF9BRFA1NTg5IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJP
QVJEX0FUS0JEPXkKIyBDT05GSUdfS0VZQk9BUkRfUVQxMDcwIGlzIG5vdCBzZXQKIyBDT05GSUdf
S0VZQk9BUkRfUVQyMTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTEtLQkQgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E2NDE2IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9B
UkRfVENBODQxOCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBub3Qgc2V0
CiMgQ09ORklHX0tFWUJPQVJEX0xNODMzMyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01B
WDczNTkgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90IHNldAojIENPTkZJ
R19LRVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9ORVdUT04gaXMg
bm90IHNldAojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMgbm90IHNldAojIENPTkZJR19L
RVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NVTktCRCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09NQVA0IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9B
UkRfWFRLQkQgaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0U9eQpDT05GSUdfTU9VU0VfUFMy
PXkKQ09ORklHX01PVVNFX1BTMl9BTFBTPXkKQ09ORklHX01PVVNFX1BTMl9MT0dJUFMyUFA9eQpD
T05GSUdfTU9VU0VfUFMyX1NZTkFQVElDUz15CkNPTkZJR19NT1VTRV9QUzJfTElGRUJPT0s9eQpD
T05GSUdfTU9VU0VfUFMyX1RSQUNLUE9JTlQ9eQojIENPTkZJR19NT1VTRV9QUzJfRUxBTlRFQ0gg
aXMgbm90IHNldAojIENPTkZJR19NT1VTRV9QUzJfU0VOVEVMSUMgaXMgbm90IHNldAojIENPTkZJ
R19NT1VTRV9QUzJfVE9VQ0hLSVQgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TRVJJQUwgaXMg
bm90IHNldAojIENPTkZJR19NT1VTRV9BUFBMRVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9V
U0VfQkNNNTk3NCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1ZTWFhYQUEgaXMgbm90IHNldAoj
IENPTkZJR19NT1VTRV9TWU5BUFRJQ1NfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfU1lO
QVBUSUNTX1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQK
Q09ORklHX0lOUFVUX1RBQkxFVD15CiMgQ09ORklHX1RBQkxFVF9VU0JfQUNFQ0FEIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVEFCTEVUX1VTQl9BSVBURUsgaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRf
VVNCX0dUQ08gaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRfVVNCX0hBTldBTkcgaXMgbm90IHNl
dAojIENPTkZJR19UQUJMRVRfVVNCX0tCVEFCIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFCTEVUX1VT
Ql9XQUNPTSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CiMgQ09ORklHX1RP
VUNIU0NSRUVOX0FENzg3OSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FUTUVMX01Y
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMTMgaXMgbm90IHNldAojIENP
TkZJR19UT1VDSFNDUkVFTl9DWVRUU1BfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NS
RUVOX0RZTkFQUk8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9IQU1QU0hJUkUgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9FRVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fRlVKSVRTVSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIxMFgg
aXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9HVU5aRSBpcyBub3Qgc2V0CiMgQ09ORklH
X1RPVUNIU0NSRUVOX0VMTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4
MDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fV0FDT01fSTJDIGlzIG5vdCBzZXQK
IyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUFYMTE4MDEgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFND
UkVFTl9NQ1M1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTU1TMTE0IGlzIG5v
dCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fSU5FWElPIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUs3MTIgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9QRU5NT1VOVCBpcyBub3Qgc2V0CiMgQ09ORklH
X1RPVUNIU0NSRUVOX0VEVF9GVDVYMDYgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9U
T1VDSFJJR0hUIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hXSU4gaXMgbm90
IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9QSVhDSVIgaXMgbm90IHNldAojIENPTkZJR19UT1VD
SFNDUkVFTl9VU0JfQ09NUE9TSVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9V
Q0hJVDIxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQ19TRVJJTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQzIwMDcgaXMgbm90IHNldAojIENPTkZJR19UT1VD
SFNDUkVFTl9TVDEyMzIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBp
cyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5QVVRfQk1BMTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUENT
UEtSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTU1BODQ1MCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lOUFVUX01QVTMwNTAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BUEFORUwgaXMgbm90IHNl
dAojIENPTkZJR19JTlBVVF9BVExBU19CVE5TIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQVRJ
X1JFTU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9LRVlTUEFOX1JFTU9URSBpcyBub3Qg
c2V0CiMgQ09ORklHX0lOUFVUX0tYVEo5IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUE9XRVJN
QVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfWUVBTElOSyBpcyBub3Qgc2V0CiMgQ09ORklH
X0lOUFVUX0NNMTA5IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfVUlOUFVUIGlzIG5vdCBzZXQK
IyBDT05GSUdfSU5QVVRfUENGODU3NCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0FEWEwzNFgg
aXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTUEzMDAwIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVU
X1hFTl9LQkRERVZfRlJPTlRFTkQ9eQoKIwojIEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19T
RVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPXkKIyBDT05G
SUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90
IHNldApDT05GSUdfU0VSSU9fTElCUFMyPXkKIyBDT05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VSSU9fQUxURVJBX1BTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BTMk1V
TFQgaXMgbm90IHNldAojIENPTkZJR19HQU1FUE9SVCBpcyBub3Qgc2V0CgojCiMgQ2hhcmFjdGVy
IGRldmljZXMKIwpDT05GSUdfVlQ9eQpDT05GSUdfQ09OU09MRV9UUkFOU0xBVElPTlM9eQpDT05G
SUdfVlRfQ09OU09MRT15CkNPTkZJR19WVF9DT05TT0xFX1NMRUVQPXkKQ09ORklHX0hXX0NPTlNP
TEU9eQpDT05GSUdfVlRfSFdfQ09OU09MRV9CSU5ESU5HPXkKQ09ORklHX1VOSVg5OF9QVFlTPXkK
IyBDT05GSUdfREVWUFRTX01VTFRJUExFX0lOU1RBTkNFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xF
R0FDWV9QVFlTIGlzIG5vdCBzZXQKQ09ORklHX1NFUklBTF9OT05TVEFOREFSRD15CiMgQ09ORklH
X1JPQ0tFVFBPUlQgaXMgbm90IHNldAojIENPTkZJR19DWUNMQURFUyBpcyBub3Qgc2V0CiMgQ09O
RklHX01PWEFfSU5URUxMSU8gaXMgbm90IHNldAojIENPTkZJR19NT1hBX1NNQVJUSU8gaXMgbm90
IHNldAojIENPTkZJR19TWU5DTElOSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NZTkNMSU5LTVAgaXMg
bm90IHNldAojIENPTkZJR19TWU5DTElOS19HVCBpcyBub3Qgc2V0CiMgQ09ORklHX05PWk9NSSBp
cyBub3Qgc2V0CiMgQ09ORklHX0lTSSBpcyBub3Qgc2V0CiMgQ09ORklHX05fSERMQyBpcyBub3Qg
c2V0CiMgQ09ORklHX05fR1NNIGlzIG5vdCBzZXQKIyBDT05GSUdfVFJBQ0VfU0lOSyBpcyBub3Qg
c2V0CiMgQ09ORklHX0RFVktNRU0gaXMgbm90IHNldAojIENPTkZJR19TVEFMRFJWIGlzIG5vdCBz
ZXQKCiMKIyBTZXJpYWwgZHJpdmVycwojCkNPTkZJR19TRVJJQUxfODI1MD15CkNPTkZJR19TRVJJ
QUxfODI1MF9QTlA9eQpDT05GSUdfU0VSSUFMXzgyNTBfQ09OU09MRT15CkNPTkZJR19GSVhfRUFS
TFlDT05fTUVNPXkKQ09ORklHX1NFUklBTF84MjUwX1BDST15CkNPTkZJR19TRVJJQUxfODI1MF9O
Ul9VQVJUUz0zMgpDT05GSUdfU0VSSUFMXzgyNTBfUlVOVElNRV9VQVJUUz00CkNPTkZJR19TRVJJ
QUxfODI1MF9FWFRFTkRFRD15CkNPTkZJR19TRVJJQUxfODI1MF9NQU5ZX1BPUlRTPXkKQ09ORklH
X1NFUklBTF84MjUwX1NIQVJFX0lSUT15CkNPTkZJR19TRVJJQUxfODI1MF9ERVRFQ1RfSVJRPXkK
Q09ORklHX1NFUklBTF84MjUwX1JTQT15CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9y
dAojCiMgQ09ORklHX1NFUklBTF9NRkRfSFNVIGlzIG5vdCBzZXQKQ09ORklHX1NFUklBTF9DT1JF
PXkKQ09ORklHX1NFUklBTF9DT1JFX0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfSlNNIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VSSUFMX1NDQ05YUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9U
SU1CRVJEQUxFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9KVEFHVUFSVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
UklBTF9QQ0hfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9YSUxJTlhfUFNfVUFSVCBp
cyBub3Qgc2V0CkNPTkZJR19IVkNfRFJJVkVSPXkKQ09ORklHX0hWQ19JUlE9eQpDT05GSUdfSFZD
X1hFTj15CkNPTkZJR19IVkNfWEVOX0ZST05URU5EPXkKIyBDT05GSUdfSVBNSV9IQU5ETEVSIGlz
IG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT15CkNPTkZJR19IV19SQU5ET01fVElNRVJJT01FTT15
CkNPTkZJR19IV19SQU5ET01fSU5URUw9eQpDT05GSUdfSFdfUkFORE9NX0FNRD15CkNPTkZJR19I
V19SQU5ET01fVklBPXkKIyBDT05GSUdfTlZSQU0gaXMgbm90IHNldAojIENPTkZJR19SMzk2NCBp
cyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTVdBVkUgaXMg
bm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0hQRVQ9eQojIENP
TkZJR19IUEVUX01NQVAgaXMgbm90IHNldApDT05GSUdfSEFOR0NIRUNLX1RJTUVSPXkKIyBDT05G
SUdfVENHX1RQTSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFTENMT0NLIGlzIG5vdCBzZXQKQ09ORklH
X0RFVlBPUlQ9eQpDT05GSUdfSTJDPXkKQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdfSTJD
X0NPTVBBVD15CiMgQ09ORklHX0kyQ19DSEFSREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX01V
WCBpcyBub3Qgc2V0CkNPTkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FMR09CSVQ9
eQoKIwojIEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgUEMgU01CdXMgaG9zdCBjb250
cm9sbGVyIGRyaXZlcnMKIwojIENPTkZJR19JMkNfQUxJMTUzNSBpcyBub3Qgc2V0CiMgQ09ORklH
X0kyQ19BTEkxNTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1WDMgaXMgbm90IHNldApD
T05GSUdfSTJDX0FNRDc1Nj15CiMgQ09ORklHX0kyQ19BTUQ3NTZfUzQ4ODIgaXMgbm90IHNldApD
T05GSUdfSTJDX0FNRDgxMTE9eQpDT05GSUdfSTJDX0k4MDE9eQpDT05GSUdfSTJDX0lTQ0g9eQpD
T05GSUdfSTJDX1BJSVg0PXkKIyBDT05GSUdfSTJDX05GT1JDRTIgaXMgbm90IHNldAojIENPTkZJ
R19JMkNfU0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM2MzAgaXMgbm90IHNldAoj
IENPTkZJR19JMkNfU0lTOTZYIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1ZJQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0kyQ19WSUFQUk8gaXMgbm90IHNldAoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJ
R19JMkNfU0NNST15CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVk
IC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0RFU0lHTldBUkVfUENJIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSTJDX0VHMjBUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0lOVEVMX01JRCBp
cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19PQ09SRVMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUENB
X1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BYQV9QQ0kgaXMgbm90IHNldAojIENP
TkZJR19JMkNfU0lNVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1hJTElOWCBpcyBub3Qgc2V0
CgojCiMgRXh0ZXJuYWwgSTJDL1NNQnVzIGFkYXB0ZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19E
SU9MQU5fVTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQgaXMgbm90IHNl
dAojIENPTkZJR19JMkNfVEFPU19FVk0gaXMgbm90IHNldAojIENPTkZJR19JMkNfVElOWV9VU0Ig
aXMgbm90IHNldAoKIwojIE90aGVyIEkyQy9TTUJ1cyBidXMgZHJpdmVycwojCiMgQ09ORklHX0ky
Q19TVFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENP
TkZJR19JMkNfREVCVUdfQUxHTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMg
bm90IHNldAojIENPTkZJR19TUEkgaXMgbm90IHNldAojIENPTkZJR19IU0kgaXMgbm90IHNldAoK
IwojIFBQUyBzdXBwb3J0CiMKIyBDT05GSUdfUFBTIGlzIG5vdCBzZXQKCiMKIyBQUFMgZ2VuZXJh
dG9ycyBzdXBwb3J0CiMKCiMKIyBQVFAgY2xvY2sgc3VwcG9ydAojCgojCiMgRW5hYmxlIERldmlj
ZSBEcml2ZXJzIC0+IFBQUyB0byBzZWUgdGhlIFBUUCBjbG9jayBvcHRpb25zLgojCkNPTkZJR19B
UkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15CiMgQ09ORklHX0dQSU9MSUIgaXMgbm90IHNldAoj
IENPTkZJR19XMSBpcyBub3Qgc2V0CkNPTkZJR19QT1dFUl9TVVBQTFk9eQojIENPTkZJR19QT1dF
Ul9TVVBQTFlfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAoj
IENPTkZJR19URVNUX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODAgaXMg
bm90IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRF
UllfRFMyNzgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9TQlMgaXMgbm90IHNldAojIENP
TkZJR19CQVRURVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX01BWDE3MDQw
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBub3Qgc2V0CiMgQ09ORklH
X0NIQVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTFA4NzI3IGlzIG5v
dCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9TTUIzNDcgaXMgbm90IHNldAojIENPTkZJR19QT1dFUl9B
VlMgaXMgbm90IHNldApDT05GSUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPXkKIyBDT05GSUdf
SFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMKIwojIENPTkZJ
R19TRU5TT1JTX0FCSVRVR1VSVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUJJVFVHVVJV
MyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19BRDc0MTggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjEgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FETTEwMjYgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjkgaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX0FETTEwMzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTky
NDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0MTAgaXMgbm90IHNldAojIENPTkZJ
R19TRU5TT1JTX0FEVDc0MTEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NjIgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NzAgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0FEVDc0NzUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FTQzc2MjEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0s4VEVNUCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0sxMFRF
TVA9eQpDT05GSUdfU0VOU09SU19GQU0xNUhfUE9XRVI9eQojIENPTkZJR19TRU5TT1JTX0FTQjEw
MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX0RTNjIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0k1S19BTUIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19GNzE4
MDVGPXkKQ09ORklHX1NFTlNPUlNfRjcxODgyRkc9eQpDT05GSUdfU0VOU09SU19GNzUzNzVTPXkK
IyBDT05GSUdfU0VOU09SU19GU0NITUQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0c3NjBB
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19ISUg2MTMwIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19DT1JFVEVNUCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JT
X0lUODc9eQpDT05GSUdfU0VOU09SU19KQzQyPXkKIyBDT05GSUdfU0VOU09SU19MSU5FQUdFIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19MTTczIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc1IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc4IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgz
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19MTTg3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19MTTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkzIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MTUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19MVEM0MjE1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjQ1IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19MVEM0MjYxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1
MjQxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTYxOSBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTY2OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
TlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjM5IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19N
QVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
UEM4NzM2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CiMgQ09ORklHX1BNQlVTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0lT
NTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19ETUUxNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMxNDAzIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMyMTAzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19FTUM2VzIwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01TQzQ3TTEgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xOTIgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX1NNU0M0N0IzOTcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NDSDU2WFhfQ09NTU9O
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NjI3IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19TQ0g1NjM2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFMxMDE1IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFM3ODI4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19BTUM2ODIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19JTkEyWFggaXMgbm90IHNldAoj
IENPTkZJR19TRU5TT1JTX1RITUM1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVE1QMTAy
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UTVA0MDEgaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX1RNUDQyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBX0NQVVRFTVAgaXMg
bm90IHNldAojIENPTkZJR19TRU5TT1JTX1ZJQTY4NkEgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX1ZUMTIxMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQ4MjMxIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19XODM3ODFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3
OTFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTJEIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19XODM3OTMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5NSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19XODNMNzg2TkcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4MzYyN0hGIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM2MjdFSEYgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0FQUExFU01DIGlzIG5vdCBzZXQKCiMKIyBBQ1BJIGRyaXZlcnMKIwpDT05GSUdfU0VOU09S
U19BQ1BJX1BPV0VSPXkKIyBDT05GSUdfU0VOU09SU19BVEswMTEwIGlzIG5vdCBzZXQKQ09ORklH
X1RIRVJNQUw9eQpDT05GSUdfVEhFUk1BTF9IV01PTj15CiMgQ09ORklHX0NQVV9USEVSTUFMIGlz
IG5vdCBzZXQKQ09ORklHX1dBVENIRE9HPXkKQ09ORklHX1dBVENIRE9HX0NPUkU9eQojIENPTkZJ
R19XQVRDSERPR19OT1dBWU9VVCBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgRGV2aWNlIERyaXZl
cnMKIwojIENPTkZJR19TT0ZUX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNRVUlSRV9X
RFQgaXMgbm90IHNldAojIENPTkZJR19BRFZBTlRFQ0hfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdf
QUxJTTE1MzVfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfQUxJTTcxMDFfV0RUIGlzIG5vdCBzZXQK
IyBDT05GSUdfRjcxODA4RV9XRFQgaXMgbm90IHNldApDT05GSUdfU1A1MTAwX1RDTz15CiMgQ09O
RklHX1NDNTIwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NCQ19GSVRQQzJfV0FUQ0hET0cgaXMg
bm90IHNldAojIENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90IHNldAojIENPTkZJR19JQjcwMF9X
RFQgaXMgbm90IHNldAojIENPTkZJR19JQk1BU1IgaXMgbm90IHNldAojIENPTkZJR19XQUZFUl9X
RFQgaXMgbm90IHNldAojIENPTkZJR19JNjMwMEVTQl9XRFQgaXMgbm90IHNldAojIENPTkZJR19J
RTZYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19JVENPX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lUODcxMkZfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfSVQ4N19XRFQgaXMgbm90IHNldAojIENP
TkZJR19IUF9XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDMTIwMF9XRFQgaXMgbm90IHNl
dAojIENPTkZJR19QQzg3NDEzX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX05WX1RDTyBpcyBub3Qg
c2V0CiMgQ09ORklHXzYwWFhfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JDODM2MF9XRFQgaXMg
bm90IHNldAojIENPTkZJR19DUFU1X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0NfU0NIMzEx
WF9XRFQgaXMgbm90IHNldAojIENPTkZJR19TTVNDMzdCNzg3X1dEVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1ZJQV9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM2MjdIRl9XRFQgaXMgbm90IHNldAoj
IENPTkZJR19XODM2OTdIRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM2OTdVR19XRFQgaXMg
bm90IHNldAojIENPTkZJR19XODM4NzdGX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4Mzk3N0Zf
V0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDSFpfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JD
X0VQWF9DM19XQVRDSERPRyBpcyBub3Qgc2V0CkNPTkZJR19YRU5fV0RUPXkKCiMKIyBQQ0ktYmFz
ZWQgV2F0Y2hkb2cgQ2FyZHMKIwojIENPTkZJR19QQ0lQQ1dBVENIRE9HIGlzIG5vdCBzZXQKIyBD
T05GSUdfV0RUUENJIGlzIG5vdCBzZXQKCiMKIyBVU0ItYmFzZWQgV2F0Y2hkb2cgQ2FyZHMKIwoj
IENPTkZJR19VU0JQQ1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1NTQl9QT1NTSUJMRT15Cgoj
CiMgU29uaWNzIFNpbGljb24gQmFja3BsYW5lCiMKIyBDT05GSUdfU1NCIGlzIG5vdCBzZXQKQ09O
RklHX0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNwZWNpZmljIEFNQkEKIwojIENPTkZJ
R19CQ01BIGlzIG5vdCBzZXQKCiMKIyBNdWx0aWZ1bmN0aW9uIGRldmljZSBkcml2ZXJzCiMKQ09O
RklHX01GRF9DT1JFPXkKIyBDT05GSUdfTUZEXzg4UE04NjBYIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUZEXzg4UE04MDAgaXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTgwNSBpcyBub3Qgc2V0CiMg
Q09ORklHX01GRF9TTTUwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0hUQ19QQVNJQzMgaXMgbm90IHNl
dAojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjEwNVggaXMgbm90
IHNldAojIENPTkZJR19UUFM2NTA3WCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9UUFM2NTIxNyBp
cyBub3Qgc2V0CiMgQ09ORklHX1RXTDQwMzBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDYw
NDBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TVE1QRSBpcyBub3Qgc2V0CiMgQ09ORklH
X01GRF9UQzM1ODlYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RNSU8gaXMgbm90IHNldAojIENP
TkZJR19NRkRfU01TQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BNSUNfREE5MDNYIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX0RBOTA1Ml9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfREE5MDU1IGlz
IG5vdCBzZXQKIyBDT05GSUdfUE1JQ19BRFA1NTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xQ
ODc4OCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg3NzY4NiBpcyBub3Qgc2V0CiMgQ09ORklH
X01GRF9NQVg3NzY5MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTA3IGlzIG5vdCBzZXQK
IyBDT05GSUdfTUZEX01BWDg5MjUgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODk5NyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4OTk4IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1NFQ19D
T1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0FSSVpPTkFfSTJDIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX1dNODQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzMVhfSTJDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUZEX1dNODM1MF9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004OTk0
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1BDRjUwNjMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X01DMTNYWFhfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUJYNTAwX0NPUkUgaXMgbm90IHNldAoj
IENPTkZJR19NRkRfQ1M1NTM1IGlzIG5vdCBzZXQKQ09ORklHX0xQQ19TQ0g9eQojIENPTkZJR19M
UENfSUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JEQzMyMVggaXMgbm90IHNldAojIENPTkZJ
R19NRkRfSkFOWl9DTU9ESU8gaXMgbm90IHNldAojIENPTkZJR19NRkRfVlg4NTUgaXMgbm90IHNl
dAojIENPTkZJR19NRkRfV0wxMjczX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjUw
OTAgaXMgbm90IHNldAojIENPTkZJR19NRkRfUkM1VDU4MyBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9QQUxNQVMgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1IgaXMgbm90IHNldApDT05GSUdf
TUVESUFfU1VQUE9SVD15CgojCiMgTXVsdGltZWRpYSBjb3JlIHN1cHBvcnQKIwpDT05GSUdfTUVE
SUFfQ0FNRVJBX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfQU5BTE9HX1RWX1NVUFBPUlQ9eQpDT05G
SUdfTUVESUFfRElHSVRBTF9UVl9TVVBQT1JUPXkKQ09ORklHX01FRElBX1JBRElPX1NVUFBPUlQ9
eQpDT05GSUdfTUVESUFfUkNfU1VQUE9SVD15CiMgQ09ORklHX01FRElBX0NPTlRST0xMRVIgaXMg
bm90IHNldApDT05GSUdfVklERU9fREVWPXkKQ09ORklHX1ZJREVPX1Y0TDI9eQpDT05GSUdfVklE
RU9fQURWX0RFQlVHPXkKIyBDT05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBz
ZXQKQ09ORklHX1ZJREVPX1RVTkVSPXkKQ09ORklHX1ZJREVPQlVGX0dFTj15CkNPTkZJR19WSURF
T0JVRl9ETUFfU0c9eQpDT05GSUdfVklERU9CVUZfRFZCPXkKQ09ORklHX0RWQl9DT1JFPXkKQ09O
RklHX0RWQl9ORVQ9eQpDT05GSUdfRFZCX01BWF9BREFQVEVSUz04CiMgQ09ORklHX0RWQl9EWU5B
TUlDX01JTk9SUyBpcyBub3Qgc2V0CgojCiMgTWVkaWEgZHJpdmVycwojCkNPTkZJR19SQ19DT1JF
PXkKQ09ORklHX1JDX01BUD15CkNPTkZJR19SQ19ERUNPREVSUz15CkNPTkZJR19MSVJDPXkKQ09O
RklHX0lSX0xJUkNfQ09ERUM9eQpDT05GSUdfSVJfTkVDX0RFQ09ERVI9eQpDT05GSUdfSVJfUkM1
X0RFQ09ERVI9eQpDT05GSUdfSVJfUkM2X0RFQ09ERVI9eQpDT05GSUdfSVJfSlZDX0RFQ09ERVI9
eQpDT05GSUdfSVJfU09OWV9ERUNPREVSPXkKQ09ORklHX0lSX1JDNV9TWl9ERUNPREVSPXkKQ09O
RklHX0lSX1NBTllPX0RFQ09ERVI9eQpDT05GSUdfSVJfTUNFX0tCRF9ERUNPREVSPXkKIyBDT05G
SUdfUkNfREVWSUNFUyBpcyBub3Qgc2V0CkNPTkZJR19NRURJQV9VU0JfU1VQUE9SVD15CgojCiMg
V2ViY2FtIGRldmljZXMKIwojIENPTkZJR19VU0JfVklERU9fQ0xBU1MgaXMgbm90IHNldAojIENP
TkZJR19VU0JfR1NQQ0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfUFdDIGlzIG5vdCBzZXQKIyBD
T05GSUdfVklERU9fQ1BJQTIgaXMgbm90IHNldAojIENPTkZJR19VU0JfWlIzNjRYWCBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9TVEtXRUJDQU0gaXMgbm90IHNldAojIENPTkZJR19VU0JfUzIyNTUg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU045QzEwMiBpcyBub3Qgc2V0CgojCiMgQW5hbG9nIFRW
IFVTQiBkZXZpY2VzCiMKIyBDT05GSUdfVklERU9fQVUwODI4IGlzIG5vdCBzZXQKQ09ORklHX1ZJ
REVPX1BWUlVTQjI9eQpDT05GSUdfVklERU9fUFZSVVNCMl9TWVNGUz15CkNPTkZJR19WSURFT19Q
VlJVU0IyX0RWQj15CiMgQ09ORklHX1ZJREVPX1BWUlVTQjJfREVCVUdJRkMgaXMgbm90IHNldAoj
IENPTkZJR19WSURFT19IRFBWUiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RMRzIzMDAgaXMg
bm90IHNldAojIENPTkZJR19WSURFT19VU0JWSVNJT04gaXMgbm90IHNldAojIENPTkZJR19WSURF
T19TVEsxMTYwIGlzIG5vdCBzZXQKCiMKIyBBbmFsb2cvZGlnaXRhbCBUViBVU0IgZGV2aWNlcwoj
CiMgQ09ORklHX1ZJREVPX0NYMjMxWFggaXMgbm90IHNldAojIENPTkZJR19WSURFT19UTTYwMDAg
aXMgbm90IHNldAoKIwojIERpZ2l0YWwgVFYgVVNCIGRldmljZXMKIwojIENPTkZJR19EVkJfVVNC
IGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX1VTQl9WMiBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9U
VFVTQl9CVURHRVQgaXMgbm90IHNldAojIENPTkZJR19EVkJfVFRVU0JfREVDIGlzIG5vdCBzZXQK
IyBDT05GSUdfU01TX1VTQl9EUlYgaXMgbm90IHNldAojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09Q
X1VTQiBpcyBub3Qgc2V0CgojCiMgV2ViY2FtLCBUViAoYW5hbG9nL2RpZ2l0YWwpIFVTQiBkZXZp
Y2VzCiMKIyBDT05GSUdfVklERU9fRU0yOFhYIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1BDSV9T
VVBQT1JUPXkKCiMKIyBNZWRpYSBjYXB0dXJlIHN1cHBvcnQKIwoKIwojIE1lZGlhIGNhcHR1cmUv
YW5hbG9nIFRWIHN1cHBvcnQKIwojIENPTkZJR19WSURFT19JVlRWIGlzIG5vdCBzZXQKIyBDT05G
SUdfVklERU9fWk9SQU4gaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRVhJVU1fR0VNSU5JIGlz
IG5vdCBzZXQKIyBDT05GSUdfVklERU9fSEVYSVVNX09SSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdf
VklERU9fTVhCIGlzIG5vdCBzZXQKCiMKIyBNZWRpYSBjYXB0dXJlL2FuYWxvZy9oeWJyaWQgVFYg
c3VwcG9ydAojCiMgQ09ORklHX1ZJREVPX0NYMTggaXMgbm90IHNldAojIENPTkZJR19WSURFT19D
WDIzODg1IGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX0NYMjU4MjE9eQojIENPTkZJR19WSURFT19D
WDI1ODIxX0FMU0EgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DWDg4IGlzIG5vdCBzZXQKIyBD
T05GSUdfVklERU9fQlQ4NDggaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE3MTM0IGlzIG5v
dCBzZXQKIyBDT05GSUdfVklERU9fU0FBNzE2NCBpcyBub3Qgc2V0CgojCiMgTWVkaWEgZGlnaXRh
bCBUViBQQ0kgQWRhcHRlcnMKIwojIENPTkZJR19UVFBDSV9FRVBST00gaXMgbm90IHNldAojIENP
TkZJR19EVkJfQVY3MTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JVREdFVF9DT1JFIGlzIG5v
dCBzZXQKIyBDT05GSUdfRFZCX0IyQzJfRkxFWENPUF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19E
VkJfUExVVE8yIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0RNMTEwNSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RWQl9QVDEgaXMgbm90IHNldAojIENPTkZJR19NQU5USVNfQ09SRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0RWQl9OR0VORSBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9EREJSSURHRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1Y0TF9QTEFURk9STV9EUklWRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfVjRM
X01FTTJNRU1fRFJJVkVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1Y0TF9URVNUX0RSSVZFUlMgaXMg
bm90IHNldAoKIwojIFN1cHBvcnRlZCBNTUMvU0RJTyBhZGFwdGVycwojCiMgQ09ORklHX1JBRElP
X0FEQVBURVJTIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1NVQkRSVl9BVVRPU0VMRUNUPXkKCiMK
IyBNZWRpYSBhbmNpbGxhcnkgZHJpdmVycyAodHVuZXJzLCBzZW5zb3JzLCBpMmMsIGZyb250ZW5k
cykKIwpDT05GSUdfVklERU9fQlRDWD15CkNPTkZJR19WSURFT19UVkVFUFJPTT15CkNPTkZJR19W
SURFT19JUl9JMkM9eQoKIwojIEF1ZGlvIGRlY29kZXJzLCBwcm9jZXNzb3JzIGFuZCBtaXhlcnMK
IwpDT05GSUdfVklERU9fTVNQMzQwMD15CkNPTkZJR19WSURFT19DUzUzTDMyQT15CkNPTkZJR19W
SURFT19XTTg3NzU9eQoKIwojIFJEUyBkZWNvZGVycwojCgojCiMgVmlkZW8gZGVjb2RlcnMKIwpD
T05GSUdfVklERU9fU0FBNzExWD15CgojCiMgVmlkZW8gYW5kIGF1ZGlvIGRlY29kZXJzCiMKQ09O
RklHX1ZJREVPX0NYMjU4NDA9eQoKIwojIE1QRUcgdmlkZW8gZW5jb2RlcnMKIwpDT05GSUdfVklE
RU9fQ1gyMzQxWD15CgojCiMgVmlkZW8gZW5jb2RlcnMKIwoKIwojIENhbWVyYSBzZW5zb3IgZGV2
aWNlcwojCgojCiMgRmxhc2ggZGV2aWNlcwojCgojCiMgVmlkZW8gaW1wcm92ZW1lbnQgY2hpcHMK
IwoKIwojIE1pc2NlbGFuZW91cyBoZWxwZXIgY2hpcHMKIwoKIwojIFNlbnNvcnMgdXNlZCBvbiBz
b2NfY2FtZXJhIGRyaXZlcgojCiMgQ09ORklHX01FRElBX0FUVEFDSCBpcyBub3Qgc2V0CkNPTkZJ
R19NRURJQV9UVU5FUj15CkNPTkZJR19NRURJQV9UVU5FUl9TSU1QTEU9eQpDT05GSUdfTUVESUFf
VFVORVJfVERBODI5MD15CkNPTkZJR19NRURJQV9UVU5FUl9UREE4MjdYPXkKQ09ORklHX01FRElB
X1RVTkVSX1REQTE4MjcxPXkKQ09ORklHX01FRElBX1RVTkVSX1REQTk4ODc9eQpDT05GSUdfTUVE
SUFfVFVORVJfVEVBNTc2MT15CkNPTkZJR19NRURJQV9UVU5FUl9URUE1NzY3PXkKQ09ORklHX01F
RElBX1RVTkVSX01UMjBYWD15CkNPTkZJR19NRURJQV9UVU5FUl9YQzIwMjg9eQpDT05GSUdfTUVE
SUFfVFVORVJfWEM1MDAwPXkKQ09ORklHX01FRElBX1RVTkVSX1hDNDAwMD15CkNPTkZJR19NRURJ
QV9UVU5FUl9NQzQ0UzgwMz15CgojCiMgTXVsdGlzdGFuZGFyZCAoc2F0ZWxsaXRlKSBmcm9udGVu
ZHMKIwoKIwojIE11bHRpc3RhbmRhcmQgKGNhYmxlICsgdGVycmVzdHJpYWwpIGZyb250ZW5kcwoj
CgojCiMgRFZCLVMgKHNhdGVsbGl0ZSkgZnJvbnRlbmRzCiMKCiMKIyBEVkItVCAodGVycmVzdHJp
YWwpIGZyb250ZW5kcwojCkNPTkZJR19EVkJfVERBMTAwNDg9eQoKIwojIERWQi1DIChjYWJsZSkg
ZnJvbnRlbmRzCiMKCiMKIyBBVFNDIChOb3J0aCBBbWVyaWNhbi9Lb3JlYW4gVGVycmVzdHJpYWwv
Q2FibGUgRFRWKSBmcm9udGVuZHMKIwpDT05GSUdfRFZCX0xHRFQzMzBYPXkKQ09ORklHX0RWQl9T
NUgxNDA5PXkKQ09ORklHX0RWQl9TNUgxNDExPXkKCiMKIyBJU0RCLVQgKHRlcnJlc3RyaWFsKSBm
cm9udGVuZHMKIwoKIwojIERpZ2l0YWwgdGVycmVzdHJpYWwgb25seSB0dW5lcnMvUExMCiMKCiMK
IyBTRUMgY29udHJvbCBkZXZpY2VzIGZvciBEVkItUwojCgojCiMgVG9vbHMgdG8gZGV2ZWxvcCBu
ZXcgZnJvbnRlbmRzCiMKIyBDT05GSUdfRFZCX0RVTU1ZX0ZFIGlzIG5vdCBzZXQKCiMKIyBHcmFw
aGljcyBzdXBwb3J0CiMKQ09ORklHX0FHUD15CkNPTkZJR19BR1BfQU1ENjQ9eQpDT05GSUdfQUdQ
X0lOVEVMPXkKIyBDT05GSUdfQUdQX1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9WSUEgaXMg
bm90IHNldApDT05GSUdfVkdBX0FSQj15CkNPTkZJR19WR0FfQVJCX01BWF9HUFVTPTE2CiMgQ09O
RklHX1ZHQV9TV0lUQ0hFUk9PIGlzIG5vdCBzZXQKQ09ORklHX0RSTT15CkNPTkZJR19EUk1fS01T
X0hFTFBFUj15CiMgQ09ORklHX0RSTV9MT0FEX0VESURfRklSTVdBUkUgaXMgbm90IHNldAojIENP
TkZJR19EUk1fVERGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9SMTI4IGlzIG5vdCBzZXQKIyBD
T05GSUdfRFJNX1JBREVPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9OT1VWRUFVIGlzIG5vdCBz
ZXQKCiMKIyBJMkMgZW5jb2RlciBvciBoZWxwZXIgY2hpcHMKIwpDT05GSUdfRFJNX0kyQ19DSDcw
MDY9eQpDT05GSUdfRFJNX0kyQ19TSUwxNjQ9eQpDT05GSUdfRFJNX0k5MTU9eQpDT05GSUdfRFJN
X0k5MTVfS01TPXkKIyBDT05GSUdfRFJNX01HQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9TSVMg
aXMgbm90IHNldAojIENPTkZJR19EUk1fVklBIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1NBVkFH
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9WTVdHRlggaXMgbm90IHNldAojIENPTkZJR19EUk1f
R01BNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1VETCBpcyBub3Qgc2V0CiMgQ09ORklHX0RS
TV9BU1QgaXMgbm90IHNldAojIENPTkZJR19EUk1fTUdBRzIwMCBpcyBub3Qgc2V0CiMgQ09ORklH
X0RSTV9DSVJSVVNfUUVNVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1ZHQVNUQVRFIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX09VVFBVVF9DT05U
Uk9MPXkKQ09ORklHX0ZCPXkKIyBDT05GSUdfRklSTVdBUkVfRURJRCBpcyBub3Qgc2V0CiMgQ09O
RklHX0ZCX0REQyBpcyBub3Qgc2V0CkNPTkZJR19GQl9CT09UX1ZFU0FfU1VQUE9SVD15CkNPTkZJ
R19GQl9DRkJfRklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVBPXkKQ09ORklHX0ZCX0NG
Ql9JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9DRkJfUkVWX1BJWEVMU19JTl9CWVRFIGlzIG5vdCBz
ZXQKQ09ORklHX0ZCX1NZU19GSUxMUkVDVD15CkNPTkZJR19GQl9TWVNfQ09QWUFSRUE9eQpDT05G
SUdfRkJfU1lTX0lNQUdFQkxJVD15CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5ESUFOIGlzIG5vdCBz
ZXQKQ09ORklHX0ZCX1NZU19GT1BTPXkKIyBDT05GSUdfRkJfV01UX0dFX1JPUFMgaXMgbm90IHNl
dApDT05GSUdfRkJfREVGRVJSRURfSU89eQojIENPTkZJR19GQl9TVkdBTElCIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkJfTUFDTU9ERVMgaXMgbm90IHNldAojIENPTkZJR19GQl9CQUNLTElHSFQgaXMg
bm90IHNldApDT05GSUdfRkJfTU9ERV9IRUxQRVJTPXkKQ09ORklHX0ZCX1RJTEVCTElUVElORz15
CgojCiMgRnJhbWUgYnVmZmVyIGhhcmR3YXJlIGRyaXZlcnMKIwojIENPTkZJR19GQl9DSVJSVVMg
aXMgbm90IHNldAojIENPTkZJR19GQl9QTTIgaXMgbm90IHNldAojIENPTkZJR19GQl9DWUJFUjIw
MDAgaXMgbm90IHNldAojIENPTkZJR19GQl9BUkMgaXMgbm90IHNldAojIENPTkZJR19GQl9BU0lM
SUFOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0lNU1RUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
VkdBMTYgaXMgbm90IHNldAojIENPTkZJR19GQl9VVkVTQSBpcyBub3Qgc2V0CkNPTkZJR19GQl9W
RVNBPXkKIyBDT05GSUdfRkJfTjQxMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0hHQSBpcyBub3Qg
c2V0CiMgQ09ORklHX0ZCX1MxRDEzWFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTlZJRElBIGlz
IG5vdCBzZXQKIyBDT05GSUdfRkJfUklWQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0k3NDAgaXMg
bm90IHNldAojIENPTkZJR19GQl9MRTgwNTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTUFUUk9Y
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUkFERU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZ
MTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUzMg
aXMgbm90IHNldAojIENPTkZJR19GQl9TQVZBR0UgaXMgbm90IHNldAojIENPTkZJR19GQl9TSVMg
aXMgbm90IHNldAojIENPTkZJR19GQl9WSUEgaXMgbm90IHNldAojIENPTkZJR19GQl9ORU9NQUdJ
QyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0tZUk8gaXMgbm90IHNldAojIENPTkZJR19GQl8zREZY
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVk9PRE9PMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1ZU
ODYyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1RSSURFTlQgaXMgbm90IHNldAojIENPTkZJR19G
Ql9BUksgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTMgaXMgbm90IHNldAojIENPTkZJR19GQl9D
QVJNSU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfR0VPREUgaXMgbm90IHNldAojIENPTkZJR19G
Ql9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBpcyBub3Qgc2V0CkNPTkZJR19G
Ql9VREw9eQojIENPTkZJR19GQl9WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9G
Uk9OVEVORD15CiMgQ09ORklHX0ZCX01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01C
ODYyWFggaXMgbm90IHNldAojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05G
SUdfRkJfQVVPX0sxOTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhZTk9TX1ZJREVPIGlzIG5vdCBz
ZXQKQ09ORklHX0JBQ0tMSUdIVF9MQ0RfU1VQUE9SVD15CiMgQ09ORklHX0xDRF9DTEFTU19ERVZJ
Q0UgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0NMQVNTX0RFVklDRT15CkNPTkZJR19CQUNL
TElHSFRfR0VORVJJQz15CiMgQ09ORklHX0JBQ0tMSUdIVF9BUFBMRSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBQ0tMSUdIVF9TQUhBUkEgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfQURQODg2
MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BRFA4ODcwIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkFDS0xJR0hUX0xNMzYzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9MTTM2Mzkg
aXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTFA4NTVYIGlzIG5vdCBzZXQKCiMKIyBDb25z
b2xlIGRpc3BsYXkgZHJpdmVyIHN1cHBvcnQKIwpDT05GSUdfVkdBX0NPTlNPTEU9eQpDT05GSUdf
VkdBQ09OX1NPRlRfU0NST0xMQkFDSz15CkNPTkZJR19WR0FDT05fU09GVF9TQ1JPTExCQUNLX1NJ
WkU9NjQKQ09ORklHX0RVTU1ZX0NPTlNPTEU9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFX0RFVEVDVF9QUklNQVJZPXkKIyBDT05GSUdfRlJB
TUVCVUZGRVJfQ09OU09MRV9ST1RBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRTIGlzIG5v
dCBzZXQKQ09ORklHX0ZPTlRfOHg4PXkKQ09ORklHX0ZPTlRfOHgxNj15CkNPTkZJR19MT0dPPXkK
IyBDT05GSUdfTE9HT19MSU5VWF9NT05PIGlzIG5vdCBzZXQKIyBDT05GSUdfTE9HT19MSU5VWF9W
R0ExNiBpcyBub3Qgc2V0CkNPTkZJR19MT0dPX0xJTlVYX0NMVVQyMjQ9eQpDT05GSUdfU09VTkQ9
eQpDT05GSUdfU09VTkRfT1NTX0NPUkU9eQpDT05GSUdfU09VTkRfT1NTX0NPUkVfUFJFQ0xBSU09
eQpDT05GSUdfU05EPXkKQ09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRfUENNPXkKQ09ORklH
X1NORF9IV0RFUD15CkNPTkZJR19TTkRfUkFXTUlEST15CkNPTkZJR19TTkRfU0VRVUVOQ0VSPXkK
Q09ORklHX1NORF9TRVFfRFVNTVk9eQpDT05GSUdfU05EX09TU0VNVUw9eQpDT05GSUdfU05EX01J
WEVSX09TUz15CkNPTkZJR19TTkRfUENNX09TUz15CkNPTkZJR19TTkRfUENNX09TU19QTFVHSU5T
PXkKQ09ORklHX1NORF9TRVFVRU5DRVJfT1NTPXkKQ09ORklHX1NORF9IUlRJTUVSPXkKQ09ORklH
X1NORF9TRVFfSFJUSU1FUl9ERUZBVUxUPXkKQ09ORklHX1NORF9EWU5BTUlDX01JTk9SUz15CkNP
TkZJR19TTkRfU1VQUE9SVF9PTERfQVBJPXkKQ09ORklHX1NORF9WRVJCT1NFX1BST0NGUz15CiMg
Q09ORklHX1NORF9WRVJCT1NFX1BSSU5USyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9ERUJVRyBp
cyBub3Qgc2V0CkNPTkZJR19TTkRfVk1BU1RFUj15CkNPTkZJR19TTkRfS0NUTF9KQUNLPXkKQ09O
RklHX1NORF9ETUFfU0dCVUY9eQpDT05GSUdfU05EX1JBV01JRElfU0VRPXkKQ09ORklHX1NORF9P
UEwzX0xJQl9TRVE9eQojIENPTkZJR19TTkRfT1BMNF9MSUJfU0VRIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX1NCQVdFX1NFUSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9FTVUxMEsxX1NFUSBpcyBu
b3Qgc2V0CkNPTkZJR19TTkRfTVBVNDAxX1VBUlQ9eQpDT05GSUdfU05EX09QTDNfTElCPXkKQ09O
RklHX1NORF9EUklWRVJTPXkKIyBDT05GSUdfU05EX1BDU1AgaXMgbm90IHNldAojIENPTkZJR19T
TkRfRFVNTVkgaXMgbm90IHNldAojIENPTkZJR19TTkRfQUxPT1AgaXMgbm90IHNldAojIENPTkZJ
R19TTkRfVklSTUlESSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9NVFBBViBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9TRVJJQUxfVTE2NTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01QVTQwMSBp
cyBub3Qgc2V0CkNPTkZJR19TTkRfUENJPXkKIyBDT05GSUdfU05EX0FEMTg4OSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NORF9BTFMzMDAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQUxTNDAwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9BTEk1NDUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FTSUhQ
SSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BVElJWFAgaXMgbm90IHNldAojIENPTkZJR19TTkRf
QVRJSVhQX01PREVNIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVODgxMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9BVTg4MjAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODMwIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU05EX0FXMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BWlQzMzI4IGlzIG5v
dCBzZXQKIyBDT05GSUdfU05EX0JUODdYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0NBMDEwNiBp
cyBub3Qgc2V0CkNPTkZJR19TTkRfQ01JUENJPXkKQ09ORklHX1NORF9PWFlHRU5fTElCPXkKQ09O
RklHX1NORF9PWFlHRU49eQojIENPTkZJR19TTkRfQ1M0MjgxIGlzIG5vdCBzZXQKIyBDT05GSUdf
U05EX0NTNDZYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzU1MzAgaXMgbm90IHNldAojIENP
TkZJR19TTkRfQ1M1NTM1QVVESU8gaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1RYRkkgaXMgbm90
IHNldAojIENPTkZJR19TTkRfREFSTEEyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9HSU5BMjAg
aXMgbm90IHNldAojIENPTkZJR19TTkRfTEFZTEEyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E
QVJMQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dJTkEyNCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9MQVlMQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01PTkEgaXMgbm90IHNldAojIENP
TkZJR19TTkRfTUlBIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VDSE8zRyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9JTkRJR08gaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdPSU8gaXMgbm90
IHNldAojIENPTkZJR19TTkRfSU5ESUdPREogaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdP
SU9YIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lORElHT0RKWCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9FTVUxMEsxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VNVTEwSzFYIGlzIG5vdCBzZXQK
IyBDT05GSUdfU05EX0VOUzEzNzAgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9FUzE5MzggaXMgbm90IHNldAojIENPTkZJR19TTkRfRVMxOTY4
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0ZNODAxIGlzIG5vdCBzZXQKQ09ORklHX1NORF9IREFf
SU5URUw9eQpDT05GSUdfU05EX0hEQV9QUkVBTExPQ19TSVpFPTY0CkNPTkZJR19TTkRfSERBX0hX
REVQPXkKIyBDT05GSUdfU05EX0hEQV9SRUNPTkZJRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9I
REFfSU5QVVRfQkVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9IREFfSU5QVVRfSkFDSyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9IREFfUEFUQ0hfTE9BREVSIGlzIG5vdCBzZXQKQ09ORklHX1NO
RF9IREFfQ09ERUNfUkVBTFRFSz15CkNPTkZJR19TTkRfSERBX0NPREVDX0FOQUxPRz15CkNPTkZJ
R19TTkRfSERBX0NPREVDX1NJR01BVEVMPXkKQ09ORklHX1NORF9IREFfQ09ERUNfVklBPXkKQ09O
RklHX1NORF9IREFfQ09ERUNfSERNST15CkNPTkZJR19TTkRfSERBX0NPREVDX0NJUlJVUz15CkNP
TkZJR19TTkRfSERBX0NPREVDX0NPTkVYQU5UPXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ0EwMTEw
PXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ0EwMTMyPXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ01F
RElBPXkKQ09ORklHX1NORF9IREFfQ09ERUNfU0kzMDU0PXkKQ09ORklHX1NORF9IREFfR0VORVJJ
Qz15CkNPTkZJR19TTkRfSERBX1BPV0VSX1NBVkVfREVGQVVMVD0wCiMgQ09ORklHX1NORF9IRFNQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0hEU1BNIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lD
RTE3MTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfSUNFMTcyNCBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9JTlRFTDhYMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTlRFTDhYME0gaXMgbm90IHNl
dAojIENPTkZJR19TTkRfS09SRzEyMTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfTE9MQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9MWDY0NjRFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9NQUVT
VFJPMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9NSVhBUlQgaXMgbm90IHNldAojIENPTkZJR19T
TkRfTk0yNTYgaXMgbm90IHNldAojIENPTkZJR19TTkRfUENYSFIgaXMgbm90IHNldAojIENPTkZJ
R19TTkRfUklQVElERSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUUzMiBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9STUU5NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUU5NjUyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU05EX1NPTklDVklCRVMgaXMgbm90IHNldAojIENPTkZJR19TTkRfVFJJREVO
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WSUE4MlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E
X1ZJQTgyWFhfTU9ERU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfVklSVFVPU08gaXMgbm90IHNl
dAojIENPTkZJR19TTkRfVlgyMjIgaXMgbm90IHNldAojIENPTkZJR19TTkRfWU1GUENJIGlzIG5v
dCBzZXQKQ09ORklHX1NORF9VU0I9eQpDT05GSUdfU05EX1VTQl9BVURJTz15CkNPTkZJR19TTkRf
VVNCX1VBMTAxPXkKQ09ORklHX1NORF9VU0JfVVNYMlk9eQpDT05GSUdfU05EX1VTQl9DQUlBUT15
CkNPTkZJR19TTkRfVVNCX0NBSUFRX0lOUFVUPXkKIyBDT05GSUdfU05EX1VTQl9VUzEyMkwgaXMg
bm90IHNldApDT05GSUdfU05EX1VTQl82RklSRT15CiMgQ09ORklHX1NORF9TT0MgaXMgbm90IHNl
dAojIENPTkZJR19TT1VORF9QUklNRSBpcyBub3Qgc2V0CgojCiMgSElEIHN1cHBvcnQKIwpDT05G
SUdfSElEPXkKIyBDT05GSUdfSElEX0JBVFRFUllfU1RSRU5HVEggaXMgbm90IHNldApDT05GSUdf
SElEUkFXPXkKIyBDT05GSUdfVUhJRCBpcyBub3Qgc2V0CkNPTkZJR19ISURfR0VORVJJQz15Cgoj
CiMgU3BlY2lhbCBISUQgZHJpdmVycwojCkNPTkZJR19ISURfQTRURUNIPXkKIyBDT05GSUdfSElE
X0FDUlVYIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9BUFBMRT15CiMgQ09ORklHX0hJRF9BVVJFQUwg
aXMgbm90IHNldApDT05GSUdfSElEX0JFTEtJTj15CkNPTkZJR19ISURfQ0hFUlJZPXkKQ09ORklH
X0hJRF9DSElDT05ZPXkKIyBDT05GSUdfSElEX1BST0RJS0VZUyBpcyBub3Qgc2V0CkNPTkZJR19I
SURfQ1lQUkVTUz15CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlzIG5vdCBzZXQKIyBDT05GSUdf
SElEX0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FTEVDT00gaXMgbm90IHNldApDT05G
SUdfSElEX0VaS0VZPXkKIyBDT05GSUdfSElEX0hPTFRFSyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJ
RF9LRVlUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LWUUgaXMgbm90IHNldAojIENPTkZJ
R19ISURfVUNMT0dJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XQUxUT1AgaXMgbm90IHNldAoj
IENPTkZJR19ISURfR1lSQVRJT04gaXMgbm90IHNldAojIENPTkZJR19ISURfVFdJTkhBTiBpcyBu
b3Qgc2V0CkNPTkZJR19ISURfS0VOU0lOR1RPTj15CiMgQ09ORklHX0hJRF9MQ1BPV0VSIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX0xFTk9WT19UUEtCRCBpcyBub3Qgc2V0CkNPTkZJR19ISURfTE9H
SVRFQ0g9eQojIENPTkZJR19ISURfTE9HSVRFQ0hfREogaXMgbm90IHNldAojIENPTkZJR19MT0dJ
VEVDSF9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0lSVU1CTEVQQUQyX0ZGIGlzIG5vdCBzZXQK
IyBDT05GSUdfTE9HSUc5NDBfRkYgaXMgbm90IHNldAojIENPTkZJR19MT0dJV0hFRUxTX0ZGIGlz
IG5vdCBzZXQKIyBDT05GSUdfSElEX01BR0lDTU9VU0UgaXMgbm90IHNldApDT05GSUdfSElEX01J
Q1JPU09GVD15CkNPTkZJR19ISURfTU9OVEVSRVk9eQojIENPTkZJR19ISURfTVVMVElUT1VDSCBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9OVFJJRyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9PUlRF
SyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QQU5USEVSTE9SRCBpcyBub3Qgc2V0CiMgQ09ORklH
X0hJRF9QRVRBTFlOWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QSUNPTENEIGlzIG5vdCBzZXQK
IyBDT05GSUdfSElEX1BSSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUzNSRU1PVEUgaXMg
bm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NBSVRF
SyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1NPTlkgaXMgbm90IHNldAojIENPTkZJR19ISURfU1BFRURMSU5LIGlzIG5vdCBzZXQKIyBDT05G
SUdfSElEX1NVTlBMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfR1JFRU5BU0lBIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSElEX1NNQVJUSk9ZUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USVZP
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RPUFNFRUQgaXMgbm90IHNldAojIENPTkZJR19ISURf
VEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBQ09NIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX1dJSU1PVEUgaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BMVVMgaXMgbm90
IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldAojIENPTkZJR19ISURfU0VOU09S
X0hVQiBpcyBub3Qgc2V0CgojCiMgVVNCIEhJRCBzdXBwb3J0CiMKQ09ORklHX1VTQl9ISUQ9eQpD
T05GSUdfSElEX1BJRD15CkNPTkZJR19VU0JfSElEREVWPXkKQ09ORklHX1VTQl9BUkNIX0hBU19P
SENJPXkKQ09ORklHX1VTQl9BUkNIX0hBU19FSENJPXkKQ09ORklHX1VTQl9BUkNIX0hBU19YSENJ
PXkKQ09ORklHX1VTQl9TVVBQT1JUPXkKQ09ORklHX1VTQl9DT01NT049eQpDT05GSUdfVVNCX0FS
Q0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldApD
T05GSUdfVVNCX0FOTk9VTkNFX05FV19ERVZJQ0VTPXkKCiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBv
cHRpb25zCiMKIyBDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKQ09ORklHX1VT
Ql9NT049eQojIENPTkZJR19VU0JfV1VTQl9DQkFGIGlzIG5vdCBzZXQKCiMKIyBVU0IgSG9zdCBD
b250cm9sbGVyIERyaXZlcnMKIwojIENPTkZJR19VU0JfQzY3WDAwX0hDRCBpcyBub3Qgc2V0CkNP
TkZJR19VU0JfWEhDSV9IQ0Q9eQojIENPTkZJR19VU0JfWEhDSV9IQ0RfREVCVUdHSU5HIGlzIG5v
dCBzZXQKQ09ORklHX1VTQl9FSENJX0hDRD15CkNPTkZJR19VU0JfRUhDSV9ST09UX0hVQl9UVD15
CkNPTkZJR19VU0JfRUhDSV9UVF9ORVdTQ0hFRD15CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9IQ0Qg
aXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19V
U0JfSVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0QgaXMgbm90
IHNldApDT05GSUdfVVNCX09IQ0lfSENEPXkKIyBDT05GSUdfVVNCX09IQ0lfSENEX1BMQVRGT1JN
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0VIQ0lfSENEX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9ERVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09I
Q0lfQklHX0VORElBTl9NTUlPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0xJVFRMRV9FTkRJ
QU49eQpDT05GSUdfVVNCX1VIQ0lfSENEPXkKIyBDT05GSUdfVVNCX1NMODExX0hDRCBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfQ0hJ
UElERUEgaXMgbm90IHNldAoKIwojIFVTQiBEZXZpY2UgQ2xhc3MgZHJpdmVycwojCiMgQ09ORklH
X1VTQl9BQ00gaXMgbm90IHNldApDT05GSUdfVVNCX1BSSU5URVI9eQojIENPTkZJR19VU0JfV0RN
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RNQyBpcyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NU
T1JBR0UgZGVwZW5kcyBvbiBTQ1NJIGJ1dCBCTEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBu
ZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBIZWxwIGZvciBtb3JlIGluZm8KIwpDT05GSUdfVVNCX1NU
T1JBR0U9eQojIENPTkZJR19VU0JfU1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVE9SQUdFX1JFQUxURUsgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFC
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TVE9SQUdFX0lTRDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VT
QkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NUT1JBR0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0Vf
SlVNUFNIT1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T
VE9SQUdFX0tBUk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVTU19BVEFD
QiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0VORV9VQjYyNTAgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfVUFTIGlzIG5vdCBzZXQKCiMKIyBVU0IgSW1hZ2luZyBkZXZpY2VzCiMKIyBD
T05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NSUNST1RFSyBpcyBub3Qg
c2V0CgojCiMgVVNCIHBvcnQgZHJpdmVycwojCkNPTkZJR19VU0JfU0VSSUFMPXkKQ09ORklHX1VT
Ql9TRVJJQUxfQ09OU09MRT15CkNPTkZJR19VU0JfU0VSSUFMX0dFTkVSSUM9eQojIENPTkZJR19V
U0JfU0VSSUFMX0FJUkNBQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9BUkszMTE2
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9CRUxLSU4gaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU0VSSUFMX0NIMzQxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9XSElURUhF
QVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0RJR0lfQUNDRUxFUE9SVCBpcyBub3Qg
c2V0CkNPTkZJR19VU0JfU0VSSUFMX0NQMjEwWD15CkNPTkZJR19VU0JfU0VSSUFMX0NZUFJFU1Nf
TTg9eQojIENPTkZJR19VU0JfU0VSSUFMX0VNUEVHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF
UklBTF9GVERJX1NJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRlVOU09GVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfVklTT1IgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
U0VSSUFMX0lQQVEgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX1NFUklBTF9FREdFUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ
QUxfRURHRVBPUlRfVEkgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0Y4MTIzMiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfR0FSTUlOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NFUklBTF9JUFcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lVVSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTl9QREEgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
U0VSSUFMX0tFWVNQQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tMU0kgaXMgbm90
IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tPQklMX1NDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TRVJJQUxfTUNUX1UyMzIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01FVFJPIGlz
IG5vdCBzZXQKQ09ORklHX1VTQl9TRVJJQUxfTU9TNzcyMD15CkNPTkZJR19VU0JfU0VSSUFMX01P
Uzc4NDA9eQojIENPTkZJR19VU0JfU0VSSUFMX01PVE9ST0xBIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NFUklBTF9OQVZNQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1BMMjMwMyBp
cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfT1RJNjg1OCBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9TRVJJQUxfUUNBVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1FVQUxDT01N
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TUENQOFg1IGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1NFUklBTF9IUDRYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TQUZFIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TSUVNRU5TX01QSSBpcyBub3Qgc2V0CiMgQ09O
RklHX1VTQl9TRVJJQUxfU0lFUlJBV0lSRUxFU1MgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX1NZTUJPTCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfVEkgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfU0VSSUFMX0NZQkVSSkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ
QUxfWElSQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9PUFRJT04gaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU0VSSUFMX09NTklORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX09QVElDT04gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1ZJVk9QQVlfU0VSSUFM
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9aSU8gaXMgbm90IHNldAojIENPTkZJR19V
U0JfU0VSSUFMX1pURSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU1NVMTAwIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9RVDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBVU0IgTWlzY2VsbGFuZW91cyBkcml2ZXJzCiMKIyBD
T05GSUdfVVNCX0VNSTYyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0VNSTI2IGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0FEVVRVWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVZTRUcgaXMgbm90
IHNldAojIENPTkZJR19VU0JfUklPNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0xFR09UT1dF
UiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEVE
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NZUFJFU1NfQ1k3QzYzIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX0NZVEhFUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfSURNT1VTRSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9GVERJX0VMQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfQVBQTEVESVNQ
TEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NJU1VTQlZHQSBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9MRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9UUkFOQ0VWSUJSQVRPUiBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9JT1dBUlJJT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfVEVTVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9JU0lHSFRGVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ZVVJF
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FWlVTQl9GWDIgaXMgbm90IHNldAoKIwojIFVTQiBQ
aHlzaWNhbCBMYXllciBkcml2ZXJzCiMKIyBDT05GSUdfT01BUF9VU0IyIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBz
ZXQKCiMKIyBPVEcgYW5kIHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNC
X1hDRUlWIGlzIG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlz
IG5vdCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpD
T05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xNMzUz
MCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVE
U19QQ0E5NTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDM5NDQgaXMgbm90IHNldAojIENP
TkZJR19MRURTX0xQNTUyMSBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1NTIzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTEVEU19DTEVWT19NQUlMIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5
NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5NjMzIGlzIG5vdCBzZXQKIyBDT05GSUdf
TEVEU19CRDI4MDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX0lOVEVMX1NTNDIwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX0xFRFNfVENBNjUwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTV4
IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19PVDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNf
QkxJTktNIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19UUklHR0VSUyBpcyBub3Qgc2V0CgojCiMg
TEVEIFRyaWdnZXJzCiMKIyBDT05GSUdfQUNDRVNTSUJJTElUWSBpcyBub3Qgc2V0CiMgQ09ORklH
X0lORklOSUJBTkQgaXMgbm90IHNldAojIENPTkZJR19FREFDIGlzIG5vdCBzZXQKQ09ORklHX1JU
Q19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkKIyBDT05GSUdfUlRDX0hDVE9TWVMgaXMgbm90IHNl
dAojIENPTkZJR19SVENfREVCVUcgaXMgbm90IHNldAoKIwojIFJUQyBpbnRlcmZhY2VzCiMKQ09O
RklHX1JUQ19JTlRGX1NZU0ZTPXkKQ09ORklHX1JUQ19JTlRGX1BST0M9eQpDT05GSUdfUlRDX0lO
VEZfREVWPXkKIyBDT05GSUdfUlRDX0lOVEZfREVWX1VJRV9FTVVMIGlzIG5vdCBzZXQKIyBDT05G
SUdfUlRDX0RSVl9URVNUIGlzIG5vdCBzZXQKCiMKIyBJMkMgUlRDIGRyaXZlcnMKIwojIENPTkZJ
R19SVENfRFJWX0RTMTMwNyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzc0IGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE2NzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X0RTMzIzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTUFYNjkwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JUQ19EUlZfUlM1QzM3MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIw
OCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwMjIgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1gxMjA1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTYzIGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS
Vl9NNDFUODAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRMzJLIGlzIG5vdCBzZXQKIyBD
T05GSUdfUlRDX0RSVl9TMzUzOTBBIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9GTTMxMzAg
aXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODU4MSBpcyBub3Qgc2V0CiMgQ09ORklHX1JU
Q19EUlZfUlg4MDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9FTTMwMjcgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX1JWMzAyOUMyIGlzIG5vdCBzZXQKCiMKIyBTUEkgUlRDIGRyaXZl
cnMKIwoKIwojIFBsYXRmb3JtIFJUQyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfQ01PUz15CiMg
Q09ORklHX1JUQ19EUlZfRFMxMjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEg
aXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTU1MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JU
Q19EUlZfRFMxNzQyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9TVEsxN1RBOCBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9N
NDhUMzUgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX000OFQ1OSBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUQ19EUlZfTVNNNjI0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfQlE0ODAyIGlz
IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SUDVDMDEgaXMgbm90IHNldAojIENPTkZJR19SVENf
RFJWX1YzMDIwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzI0MDQgaXMgbm90IHNldAoK
IwojIG9uLUNQVSBSVEMgZHJpdmVycwojCiMgQ09ORklHX0RNQURFVklDRVMgaXMgbm90IHNldAoj
IENPTkZJR19BVVhESVNQTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPIGlzIG5vdCBzZXQKIyBD
T05GSUdfVkZJTyBpcyBub3Qgc2V0CgojCiMgVmlydGlvIGRyaXZlcnMKIwojIENPTkZJR19WSVJU
SU9fUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldAoKIwojIE1p
Y3Jvc29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQKIwojIENPTkZJR19IWVBFUlYgaXMgbm90IHNl
dAoKIwojIFhlbiBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19YRU5fQkFMTE9PTj15CkNPTkZJR19Y
RU5fU0NSVUJfUEFHRVM9eQpDT05GSUdfWEVOX0RFVl9FVlRDSE49eQpDT05GSUdfWEVOX0JBQ0tF
TkQ9eQpDT05GSUdfWEVORlM9eQpDT05GSUdfWEVOX0NPTVBBVF9YRU5GUz15CkNPTkZJR19YRU5f
U1lTX0hZUEVSVklTT1I9eQpDT05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD15CkNPTkZJR19YRU5f
R05UREVWPXkKQ09ORklHX1hFTl9HUkFOVF9ERVZfQUxMT0M9eQpDT05GSUdfU1dJT1RMQl9YRU49
eQpDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKQ09ORklHX1hFTl9QUklWQ01EPXkKQ09ORklH
X1hFTl9BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19YRU5fTUNFX0xPRz15CiMgQ09ORklHX1NUQUdJ
TkcgaXMgbm90IHNldAojIENPTkZJR19YODZfUExBVEZPUk1fREVWSUNFUyBpcyBub3Qgc2V0Cgoj
CiMgSGFyZHdhcmUgU3BpbmxvY2sgZHJpdmVycwojCkNPTkZJR19DTEtFVlRfSTgyNTM9eQpDT05G
SUdfSTgyNTNfTE9DSz15CkNPTkZJR19DTEtCTERfSTgyNTM9eQpDT05GSUdfSU9NTVVfQVBJPXkK
Q09ORklHX0lPTU1VX1NVUFBPUlQ9eQpDT05GSUdfQU1EX0lPTU1VPXkKQ09ORklHX0FNRF9JT01N
VV9TVEFUUz15CiMgQ09ORklHX0lOVEVMX0lPTU1VIGlzIG5vdCBzZXQKIyBDT05GSUdfSVJRX1JF
TUFQIGlzIG5vdCBzZXQKCiMKIyBSZW1vdGVwcm9jIGRyaXZlcnMgKEVYUEVSSU1FTlRBTCkKIwoj
IENPTkZJR19TVEVfTU9ERU1fUlBST0MgaXMgbm90IHNldAoKIwojIFJwbXNnIGRyaXZlcnMgKEVY
UEVSSU1FTlRBTCkKIwojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMgbm90IHNldAojIENPTkZJR19Q
TV9ERVZGUkVRIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09OIGlzIG5vdCBzZXQKIyBDT05GSUdf
TUVNT1JZIGlzIG5vdCBzZXQKIyBDT05GSUdfSUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfVk1FX0JV
UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BXTSBpcyBub3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVy
cwojCiMgQ09ORklHX0VERCBpcyBub3Qgc2V0CkNPTkZJR19GSVJNV0FSRV9NRU1NQVA9eQojIENP
TkZJR19ERUxMX1JCVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CkNPTkZJ
R19ETUlJRD15CkNPTkZJR19ETUlfU1lTRlM9eQojIENPTkZJR19JU0NTSV9JQkZUX0ZJTkQgaXMg
bm90IHNldAojIENPTkZJR19HT09HTEVfRklSTVdBUkUgaXMgbm90IHNldAoKIwojIEZpbGUgc3lz
dGVtcwojCkNPTkZJR19EQ0FDSEVfV09SRF9BQ0NFU1M9eQojIENPTkZJR19FWFQyX0ZTIGlzIG5v
dCBzZXQKQ09ORklHX0VYVDNfRlM9eQojIENPTkZJR19FWFQzX0RFRkFVTFRTX1RPX09SREVSRUQg
aXMgbm90IHNldApDT05GSUdfRVhUM19GU19YQVRUUj15CkNPTkZJR19FWFQzX0ZTX1BPU0lYX0FD
TD15CkNPTkZJR19FWFQzX0ZTX1NFQ1VSSVRZPXkKQ09ORklHX0VYVDRfRlM9eQpDT05GSUdfRVhU
NF9VU0VfRk9SX0VYVDIzPXkKQ09ORklHX0VYVDRfRlNfWEFUVFI9eQojIENPTkZJR19FWFQ0X0ZT
X1BPU0lYX0FDTCBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfRlNfU0VDVVJJVFkgaXMgbm90IHNl
dApDT05GSUdfRVhUNF9ERUJVRz15CkNPTkZJR19KQkQ9eQojIENPTkZJR19KQkRfREVCVUcgaXMg
bm90IHNldApDT05GSUdfSkJEMj15CkNPTkZJR19KQkQyX0RFQlVHPXkKQ09ORklHX0ZTX01CQ0FD
SEU9eQojIENPTkZJR19SRUlTRVJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0pGU19GUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1hGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0dGUzJfRlMgaXMgbm90
IHNldAojIENPTkZJR19CVFJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9GUyBpcyBu
b3Qgc2V0CkNPTkZJR19GU19QT1NJWF9BQ0w9eQpDT05GSUdfRklMRV9MT0NLSU5HPXkKQ09ORklH
X0ZTTk9USUZZPXkKQ09ORklHX0ROT1RJRlk9eQpDT05GSUdfSU5PVElGWV9VU0VSPXkKIyBDT05G
SUdfRkFOT1RJRlkgaXMgbm90IHNldApDT05GSUdfUVVPVEE9eQpDT05GSUdfUVVPVEFfTkVUTElO
S19JTlRFUkZBQ0U9eQojIENPTkZJR19QUklOVF9RVU9UQV9XQVJOSU5HIGlzIG5vdCBzZXQKIyBD
T05GSUdfUVVPVEFfREVCVUcgaXMgbm90IHNldApDT05GSUdfUVVPVEFfVFJFRT15CiMgQ09ORklH
X1FGTVRfVjEgaXMgbm90IHNldApDT05GSUdfUUZNVF9WMj15CkNPTkZJR19RVU9UQUNUTD15CkNP
TkZJR19RVU9UQUNUTF9DT01QQVQ9eQpDT05GSUdfQVVUT0ZTNF9GUz15CkNPTkZJR19GVVNFX0ZT
PXkKIyBDT05GSUdfQ1VTRSBpcyBub3Qgc2V0CkNPTkZJR19HRU5FUklDX0FDTD15CgojCiMgQ2Fj
aGVzCiMKIyBDT05GSUdfRlNDQUNIRSBpcyBub3Qgc2V0CgojCiMgQ0QtUk9NL0RWRCBGaWxlc3lz
dGVtcwojCkNPTkZJR19JU085NjYwX0ZTPXkKQ09ORklHX0pPTElFVD15CkNPTkZJR19aSVNPRlM9
eQojIENPTkZJR19VREZfRlMgaXMgbm90IHNldAoKIwojIERPUy9GQVQvTlQgRmlsZXN5c3RlbXMK
IwpDT05GSUdfRkFUX0ZTPXkKQ09ORklHX01TRE9TX0ZTPXkKQ09ORklHX1ZGQVRfRlM9eQpDT05G
SUdfRkFUX0RFRkFVTFRfQ09ERVBBR0U9NDM3CkNPTkZJR19GQVRfREVGQVVMVF9JT0NIQVJTRVQ9
Imlzbzg4NTktMSIKQ09ORklHX05URlNfRlM9eQojIENPTkZJR19OVEZTX0RFQlVHIGlzIG5vdCBz
ZXQKQ09ORklHX05URlNfUlc9eQoKIwojIFBzZXVkbyBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9D
X0ZTPXkKQ09ORklHX1BST0NfS0NPUkU9eQpDT05GSUdfUFJPQ19WTUNPUkU9eQpDT05GSUdfUFJP
Q19TWVNDVEw9eQpDT05GSUdfUFJPQ19QQUdFX01PTklUT1I9eQpDT05GSUdfU1lTRlM9eQpDT05G
SUdfVE1QRlM9eQpDT05GSUdfVE1QRlNfUE9TSVhfQUNMPXkKQ09ORklHX1RNUEZTX1hBVFRSPXkK
Q09ORklHX0hVR0VUTEJGUz15CkNPTkZJR19IVUdFVExCX1BBR0U9eQojIENPTkZJR19DT05GSUdG
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX01JU0NfRklMRVNZU1RFTVMgaXMgbm90IHNldAojIENP
TkZJR19ORVRXT1JLX0ZJTEVTWVNURU1TIGlzIG5vdCBzZXQKQ09ORklHX05MUz15CkNPTkZJR19O
TFNfREVGQVVMVD0idXRmOCIKQ09ORklHX05MU19DT0RFUEFHRV80Mzc9eQojIENPTkZJR19OTFNf
Q09ERVBBR0VfNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzc3NSBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E
RVBBR0VfODUyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NSBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTcgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB
R0VfODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0CiMg
Q09ORklHX05MU19DT0RFUEFHRV84NjIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf
ODYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NCBpcyBub3Qgc2V0CiMgQ09O
RklHX05MU19DT0RFUEFHRV84NjUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODY2
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0CiMgQ09ORklH
X05MU19DT0RFUEFHRV85MzYgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfOTUwIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzMiBpcyBub3Qgc2V0CiMgQ09ORklHX05M
U19DT0RFUEFHRV85NDkgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODc0IGlzIG5v
dCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfOCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RF
UEFHRV8xMjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTEgaXMgbm90IHNl
dApDT05GSUdfTkxTX0FTQ0lJPXkKQ09ORklHX05MU19JU084ODU5XzE9eQojIENPTkZJR19OTFNf
SVNPODg1OV8yIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0CiMg
Q09ORklHX05MU19JU084ODU5XzQgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV81IGlz
IG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J
U084ODU5XzcgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQKIyBD
T05GSUdfTkxTX0lTTzg4NTlfMTMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xNCBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X0tPSThfUiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1UgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfTUFDX1JPTUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19DRUxUSUMgaXMgbm90
IHNldAojIENPTkZJR19OTFNfTUFDX0NFTlRFVVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01B
Q19DUk9BVElBTiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfQ1lSSUxMSUMgaXMgbm90IHNl
dAojIENPTkZJR19OTFNfTUFDX0dBRUxJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfR1JF
RUsgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0lDRUxBTkQgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfTUFDX0lOVUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19ST01BTklBTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX05MU19NQUNfVFVSS0lTSCBpcyBub3Qgc2V0CkNPTkZJR19OTFNfVVRG
OD15CgojCiMgS2VybmVsIGhhY2tpbmcKIwpDT05GSUdfVFJBQ0VfSVJRRkxBR1NfU1VQUE9SVD15
CkNPTkZJR19QUklOVEtfVElNRT15CkNPTkZJR19ERUZBVUxUX01FU1NBR0VfTE9HTEVWRUw9Ngoj
IENPTkZJR19FTkFCTEVfV0FSTl9ERVBSRUNBVEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfRU5BQkxF
X01VU1RfQ0hFQ0sgaXMgbm90IHNldApDT05GSUdfRlJBTUVfV0FSTj0yMDQ4CkNPTkZJR19NQUdJ
Q19TWVNSUT15CiMgQ09ORklHX1NUUklQX0FTTV9TWU1TIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVB
REFCTEVfQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVU5VU0VEX1NZTUJPTFMgaXMgbm90IHNldApD
T05GSUdfREVCVUdfRlM9eQojIENPTkZJR19IRUFERVJTX0NIRUNLIGlzIG5vdCBzZXQKIyBDT05G
SUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBpcyBub3Qgc2V0CkNPTkZJR19ERUJVR19LRVJORUw9
eQpDT05GSUdfREVCVUdfU0hJUlE9eQpDT05GSUdfTE9DS1VQX0RFVEVDVE9SPXkKQ09ORklHX0hB
UkRMT0NLVVBfREVURUNUT1I9eQojIENPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQyBp
cyBub3Qgc2V0CkNPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQ19WQUxVRT0wCiMgQ09O
RklHX0JPT1RQQVJBTV9TT0ZUTE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklHX0JPT1RQQVJB
TV9TT0ZUTE9DS1VQX1BBTklDX1ZBTFVFPTAKIyBDT05GSUdfUEFOSUNfT05fT09QUyBpcyBub3Qg
c2V0CkNPTkZJR19QQU5JQ19PTl9PT1BTX1ZBTFVFPTAKQ09ORklHX0RFVEVDVF9IVU5HX1RBU0s9
eQpDT05GSUdfREVGQVVMVF9IVU5HX1RBU0tfVElNRU9VVD0xMjAKIyBDT05GSUdfQk9PVFBBUkFN
X0hVTkdfVEFTS19QQU5JQyBpcyBub3Qgc2V0CkNPTkZJR19CT09UUEFSQU1fSFVOR19UQVNLX1BB
TklDX1ZBTFVFPTAKIyBDT05GSUdfU0NIRURfREVCVUcgaXMgbm90IHNldApDT05GSUdfU0NIRURT
VEFUUz15CkNPTkZJR19USU1FUl9TVEFUUz15CiMgQ09ORklHX0RFQlVHX09CSkVDVFMgaXMgbm90
IHNldAojIENPTkZJR19TTFVCX0RFQlVHX09OIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xVQl9TVEFU
UyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0RFQlVHX0tNRU1MRUFLPXkKIyBDT05GSUdfREVCVUdf
S01FTUxFQUsgaXMgbm90IHNldApDT05GSUdfREVCVUdfUFJFRU1QVD15CkNPTkZJR19ERUJVR19S
VF9NVVRFWEVTPXkKQ09ORklHX0RFQlVHX1BJX0xJU1Q9eQojIENPTkZJR19SVF9NVVRFWF9URVNU
RVIgaXMgbm90IHNldApDT05GSUdfREVCVUdfU1BJTkxPQ0s9eQpDT05GSUdfREVCVUdfTVVURVhF
Uz15CkNPTkZJR19ERUJVR19MT0NLX0FMTE9DPXkKQ09ORklHX1BST1ZFX0xPQ0tJTkc9eQojIENP
TkZJR19QUk9WRV9SQ1UgaXMgbm90IHNldAojIENPTkZJR19QUk9WRV9SQ1VfREVMQVkgaXMgbm90
IHNldApDT05GSUdfU1BBUlNFX1JDVV9QT0lOVEVSPXkKQ09ORklHX0xPQ0tERVA9eQojIENPTkZJ
R19MT0NLX1NUQVQgaXMgbm90IHNldApDT05GSUdfREVCVUdfTE9DS0RFUD15CkNPTkZJR19UUkFD
RV9JUlFGTEFHUz15CiMgQ09ORklHX0RFQlVHX0FUT01JQ19TTEVFUCBpcyBub3Qgc2V0CiMgQ09O
RklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNUUyBpcyBub3Qgc2V0CkNPTkZJR19TVEFDS1RS
QUNFPXkKIyBDT05GSUdfREVCVUdfU1RBQ0tfVVNBR0UgaXMgbm90IHNldAojIENPTkZJR19ERUJV
R19LT0JKRUNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0JVR1ZFUkJPU0U9eQpDT05GSUdfREVC
VUdfSU5GTz15CiMgQ09ORklHX0RFQlVHX0lORk9fUkVEVUNFRCBpcyBub3Qgc2V0CiMgQ09ORklH
X0RFQlVHX1ZNIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVklSVFVBTCBpcyBub3Qgc2V0CkNP
TkZJR19ERUJVR19XUklURUNPVU5UPXkKQ09ORklHX0RFQlVHX01FTU9SWV9JTklUPXkKQ09ORklH
X0RFQlVHX0xJU1Q9eQojIENPTkZJR19URVNUX0xJU1RfU09SVCBpcyBub3Qgc2V0CkNPTkZJR19E
RUJVR19TRz15CiMgQ09ORklHX0RFQlVHX05PVElGSUVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RF
QlVHX0NSRURFTlRJQUxTIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfV0FOVF9GUkFNRV9QT0lOVEVS
Uz15CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkKIyBDT05GSUdfQk9PVF9QUklOVEtfREVMQVkgaXMg
bm90IHNldAojIENPTkZJR19SQ1VfVE9SVFVSRV9URVNUIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9D
UFVfU1RBTExfVElNRU9VVD02MApDT05GSUdfUkNVX0NQVV9TVEFMTF9WRVJCT1NFPXkKQ09ORklH
X1JDVV9DUFVfU1RBTExfSU5GTz15CiMgQ09ORklHX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBQ0tUUkFDRV9TRUxGX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19CTE9DS19F
WFRfREVWVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0ZPUkNFX1dFQUtfUEVSX0NQVSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BFUl9DUFVfTUFQUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xL
RFRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9USUZJRVJfRVJST1JfSU5KRUNUSU9OIGlzIG5vdCBz
ZXQKIyBDT05GSUdfRkFVTFRfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFURU5DWVRP
UCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BBR0VBTExPQyBpcyBub3Qgc2V0CkNPTkZJR19V
U0VSX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNP
TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dS
QVBIX0ZQX1RFU1Q9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRV9NQ09VTlRfVEVTVD15CkNP
TkZJR19IQVZFX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0hBVkVfRlRSQUNFX01DT1VOVF9SRUNP
UkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9JTlRTPXkKQ09ORklHX0hBVkVfRkVOVFJZ
PXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0lOR19TVVBQT1JUPXkK
IyBDT05GSUdfRlRSQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfUkJUUkVFX1RFU1QgaXMgbm90IHNl
dAojIENPTkZJR19JTlRFUlZBTF9UUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19QUk9WSURF
X09IQ0kxMzk0X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19ERUJVRyBpcyBu
b3Qgc2V0CkNPTkZJR19ETUFfQVBJX0RFQlVHPXkKIyBDT05GSUdfQVRPTUlDNjRfU0VMRlRFU1Qg
aXMgbm90IHNldAojIENPTkZJR19TQU1QTEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJDSF9L
R0RCPXkKIyBDT05GSUdfS0dEQiBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfS01FTUNIRUNL
PXkKIyBDT05GSUdfS01FTUNIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9LU1RSVE9YIGlz
IG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZFUkJPU0VfQk9PVFVQ
PXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BSSU5US19EQkdQIGlzIG5v
dCBzZXQKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4
Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRBPXkKIyBDT05GSUdfREVCVUdf
Uk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TRVRfTU9EVUxFX1JPTlggaXMg
bm90IHNldAojIENPTkZJR19ERUJVR19OWF9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf
VExCRkxVU0ggaXMgbm90IHNldApDT05GSUdfSU9NTVVfREVCVUc9eQojIENPTkZJR19JT01NVV9T
VFJFU1MgaXMgbm90IHNldApDT05GSUdfSU9NTVVfTEVBSz15CkNPTkZJR19IQVZFX01NSU9UUkFD
RV9TVVBQT1JUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxBWV9U
WVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVMQVlf
VFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8wWEVE
IGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdf
SU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MApD
T05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMgbm90IHNldAoj
IENPTkZJR19PUFRJTUlaRV9JTkxJTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NUUklD
VF9VU0VSX0NPUFlfQ0hFQ0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk1JX1NFTEZURVNU
IGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMKIyBDT05GSUdfS0VZUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NFQ1VSSVRZX0RNRVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VDVVJJVFkgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWUZTIGlzIG5vdCBzZXQKQ09ORklH
X0RFRkFVTFRfU0VDVVJJVFlfREFDPXkKQ09ORklHX0RFRkFVTFRfU0VDVVJJVFk9IiIKQ09ORklH
X0NSWVBUTz15CgojCiMgQ3J5cHRvIGNvcmUgb3IgaGVscGVyCiMKQ09ORklHX0NSWVBUT19BTEdB
UEk9eQpDT05GSUdfQ1JZUFRPX0FMR0FQSTI9eQpDT05GSUdfQ1JZUFRPX0FFQUQ9eQpDT05GSUdf
Q1JZUFRPX0FFQUQyPXkKQ09ORklHX0NSWVBUT19CTEtDSVBIRVI9eQpDT05GSUdfQ1JZUFRPX0JM
S0NJUEhFUjI9eQpDT05GSUdfQ1JZUFRPX0hBU0g9eQpDT05GSUdfQ1JZUFRPX0hBU0gyPXkKQ09O
RklHX0NSWVBUT19STkc9eQpDT05GSUdfQ1JZUFRPX1JORzI9eQpDT05GSUdfQ1JZUFRPX1BDT01Q
PXkKQ09ORklHX0NSWVBUT19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdf
Q1JZUFRPX01BTkFHRVIyPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldApDT05GSUdf
Q1JZUFRPX01BTkFHRVJfRElTQUJMRV9URVNUUz15CkNPTkZJR19DUllQVE9fR0YxMjhNVUw9eQoj
IENPTkZJR19DUllQVE9fTlVMTCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19QQ1JZUFQgaXMg
bm90IHNldApDT05GSUdfQ1JZUFRPX1dPUktRVUVVRT15CkNPTkZJR19DUllQVE9fQ1JZUFREPXkK
Q09ORklHX0NSWVBUT19BVVRIRU5DPXkKIyBDT05GSUdfQ1JZUFRPX1RFU1QgaXMgbm90IHNldApD
T05GSUdfQ1JZUFRPX0FCTEtfSEVMUEVSX1g4Nj15CkNPTkZJR19DUllQVE9fR0xVRV9IRUxQRVJf
WDg2PXkKCiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEK
IwojIENPTkZJR19DUllQVE9fQ0NNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0dDTSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TRVFJViBpcyBub3Qgc2V0CgojCiMgQmxvY2sgbW9kZXMK
IwpDT05GSUdfQ1JZUFRPX0NCQz15CiMgQ09ORklHX0NSWVBUT19DVFIgaXMgbm90IHNldAojIENP
TkZJR19DUllQVE9fQ1RTIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19FQ0I9eQpDT05GSUdfQ1JZ
UFRPX0xSVz15CiMgQ09ORklHX0NSWVBUT19QQ0JDIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19Y
VFM9eQoKIwojIEhhc2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9eQojIENPTkZJR19DUllQ
VE9fWENCQyBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19WTUFDIGlzIG5vdCBzZXQKCiMKIyBE
aWdlc3QKIwpDT05GSUdfQ1JZUFRPX0NSQzMyQz15CkNPTkZJR19DUllQVE9fQ1JDMzJDX0lOVEVM
PXkKIyBDT05GSUdfQ1JZUFRPX0dIQVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX01ENCBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fTUQ1PXkKIyBDT05GSUdfQ1JZUFRPX01JQ0hBRUxfTUlD
IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1JNRDEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19STUQxNjAgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMjU2IGlzIG5vdCBzZXQK
IyBDT05GSUdfQ1JZUFRPX1JNRDMyMCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBMT15CkNP
TkZJR19DUllQVE9fU0hBMV9TU1NFMz15CiMgQ09ORklHX0NSWVBUT19TSEEyNTYgaXMgbm90IHNl
dAojIENPTkZJR19DUllQVE9fU0hBNTEyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1RHUjE5
MiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19XUDUxMiBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19HSEFTSF9DTE1VTF9OSV9JTlRFTCBpcyBub3Qgc2V0CgojCiMgQ2lwaGVycwojCkNPTkZJ
R19DUllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19B
RVNfTklfSU5URUw9eQojIENPTkZJR19DUllQVE9fQU5VQklTIGlzIG5vdCBzZXQKQ09ORklHX0NS
WVBUT19BUkM0PXkKQ09ORklHX0NSWVBUT19CTE9XRklTSD15CkNPTkZJR19DUllQVE9fQkxPV0ZJ
U0hfQ09NTU9OPXkKQ09ORklHX0NSWVBUT19CTE9XRklTSF9YODZfNjQ9eQojIENPTkZJR19DUllQ
VE9fQ0FNRUxMSUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FNRUxMSUFfWDg2XzY0IGlz
IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRP
X0NBU1Q1X0FWWF9YODZfNjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDYgaXMgbm90
IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDZfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CkNPTkZJR19D
UllQVE9fREVTPXkKIyBDT05GSUdfQ1JZUFRPX0ZDUllQVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19LSEFaQUQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fU0FMU0EyMCBpcyBub3Qgc2V0
CiMgQ09ORklHX0NSWVBUT19TQUxTQTIwX1g4Nl82NCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU
T19TRUVEIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19TRVJQRU5UPXkKQ09ORklHX0NSWVBUT19T
RVJQRU5UX1NTRTJfWDg2XzY0PXkKIyBDT05GSUdfQ1JZUFRPX1NFUlBFTlRfQVZYX1g4Nl82NCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19URUEgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1RX
T0ZJU0g9eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfQ09NTU9OPXkKQ09ORklHX0NSWVBUT19UV09G
SVNIX1g4Nl82ND15CkNPTkZJR19DUllQVE9fVFdPRklTSF9YODZfNjRfM1dBWT15CiMgQ09ORklH
X0NSWVBUT19UV09GSVNIX0FWWF9YODZfNjQgaXMgbm90IHNldAoKIwojIENvbXByZXNzaW9uCiMK
Q09ORklHX0NSWVBUT19ERUZMQVRFPXkKQ09ORklHX0NSWVBUT19aTElCPXkKQ09ORklHX0NSWVBU
T19MWk89eQoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5T
SV9DUFJORz15CiMgQ09ORklHX0NSWVBUT19VU0VSX0FQSV9IQVNIIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0hX
IGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfS1ZNPXkKIyBDT05GSUdfVklSVFVBTElaQVRJT04gaXMg
bm90IHNldAojIENPTkZJR19CSU5BUllfUFJJTlRGIGlzIG5vdCBzZXQKCiMKIyBMaWJyYXJ5IHJv
dXRpbmVzCiMKQ09ORklHX0JJVFJFVkVSU0U9eQpDT05GSUdfR0VORVJJQ19TVFJOQ1BZX0ZST01f
VVNFUj15CkNPTkZJR19HRU5FUklDX1NUUk5MRU5fVVNFUj15CkNPTkZJR19HRU5FUklDX0ZJTkRf
RklSU1RfQklUPXkKQ09ORklHX0dFTkVSSUNfUENJX0lPTUFQPXkKQ09ORklHX0dFTkVSSUNfSU9N
QVA9eQpDT05GSUdfR0VORVJJQ19JTz15CiMgQ09ORklHX0NSQ19DQ0lUVCBpcyBub3Qgc2V0CkNP
TkZJR19DUkMxNj15CkNPTkZJR19DUkNfVDEwRElGPXkKIyBDT05GSUdfQ1JDX0lUVV9UIGlzIG5v
dCBzZXQKQ09ORklHX0NSQzMyPXkKQ09ORklHX0NSQzMyX1NFTEZURVNUPXkKQ09ORklHX0NSQzMy
X1NMSUNFQlk4PXkKIyBDT05GSUdfQ1JDMzJfU0xJQ0VCWTQgaXMgbm90IHNldAojIENPTkZJR19D
UkMzMl9TQVJXQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJfQklUIGlzIG5vdCBzZXQKIyBD
T05GSUdfQ1JDNyBpcyBub3Qgc2V0CkNPTkZJR19MSUJDUkMzMkM9eQojIENPTkZJR19DUkM4IGlz
IG5vdCBzZXQKQ09ORklHX1pMSUJfSU5GTEFURT15CkNPTkZJR19aTElCX0RFRkxBVEU9eQpDT05G
SUdfTFpPX0NPTVBSRVNTPXkKQ09ORklHX0xaT19ERUNPTVBSRVNTPXkKQ09ORklHX1haX0RFQz15
CkNPTkZJR19YWl9ERUNfWDg2PXkKQ09ORklHX1haX0RFQ19QT1dFUlBDPXkKQ09ORklHX1haX0RF
Q19JQTY0PXkKQ09ORklHX1haX0RFQ19BUk09eQpDT05GSUdfWFpfREVDX0FSTVRIVU1CPXkKQ09O
RklHX1haX0RFQ19TUEFSQz15CkNPTkZJR19YWl9ERUNfQkNKPXkKIyBDT05GSUdfWFpfREVDX1RF
U1QgaXMgbm90IHNldApDT05GSUdfREVDT01QUkVTU19HWklQPXkKQ09ORklHX0RFQ09NUFJFU1Nf
QlpJUDI9eQpDT05GSUdfREVDT01QUkVTU19MWk1BPXkKQ09ORklHX0RFQ09NUFJFU1NfWFo9eQpD
T05GSUdfREVDT01QUkVTU19MWk89eQpDT05GSUdfVEVYVFNFQVJDSD15CkNPTkZJR19URVhUU0VB
UkNIX0tNUD15CkNPTkZJR19URVhUU0VBUkNIX0JNPXkKQ09ORklHX1RFWFRTRUFSQ0hfRlNNPXkK
Q09ORklHX0hBU19JT01FTT15CkNPTkZJR19IQVNfSU9QT1JUPXkKQ09ORklHX0hBU19ETUE9eQpD
T05GSUdfQ0hFQ0tfU0lHTkFUVVJFPXkKQ09ORklHX0NQVV9STUFQPXkKQ09ORklHX0RRTD15CkNP
TkZJR19OTEFUVFI9eQpDT05GSUdfQVJDSF9IQVNfQVRPTUlDNjRfREVDX0lGX1BPU0lUSVZFPXkK
Q09ORklHX0FWRVJBR0U9eQojIENPTkZJR19DT1JESUMgaXMgbm90IHNldAojIENPTkZJR19ERFIg
aXMgbm90IHNldAo=

--_002_36873033120121119163951eikelenboomit_--

--_002_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923354092DDSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Feb 25 03:21:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 03: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 1U9ocP-0000tf-M7; Mon, 25 Feb 2013 03:20: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 1U9ocO-0000tW-0F
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 03:20:44 +0000
Received: from [85.158.139.211:35293] by server-6.bemta-5.messagelabs.com id
	C9/EE-01489-B88DA215; Mon, 25 Feb 2013 03:20:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361762442!18605617!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 25 Feb 2013 03:20:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 03:20:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,731,1355097600"; 
   d="scan'208";a="1823108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 03:20: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.297.1; Mon, 25 Feb 2013 03:20:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9ocL-0004Qf-Pl;
	Mon, 25 Feb 2013 03:20:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9ocL-0000Qm-Ey;
	Mon, 25 Feb 2013 03:20:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16468-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 03:20:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16468: 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 16468 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16468/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1  8 guest-saverestore  fail REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore       fail pass in 16236
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot    fail in 16236 pass in 16468
 test-amd64-i386-xl-qemut-win-vcpus1 3 host-install(3) broken in 16236 pass in 16468

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

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-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-xend-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16236 never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 03:21:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 03: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 1U9ocP-0000tf-M7; Mon, 25 Feb 2013 03:20: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 1U9ocO-0000tW-0F
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 03:20:44 +0000
Received: from [85.158.139.211:35293] by server-6.bemta-5.messagelabs.com id
	C9/EE-01489-B88DA215; Mon, 25 Feb 2013 03:20:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361762442!18605617!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 25 Feb 2013 03:20:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 03:20:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,731,1355097600"; 
   d="scan'208";a="1823108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 03:20: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.297.1; Mon, 25 Feb 2013 03:20:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9ocL-0004Qf-Pl;
	Mon, 25 Feb 2013 03:20:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9ocL-0000Qm-Ey;
	Mon, 25 Feb 2013 03:20:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16468-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 03:20:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16468: 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 16468 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16468/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1  8 guest-saverestore  fail REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore       fail pass in 16236
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot    fail in 16236 pass in 16468
 test-amd64-i386-xl-qemut-win-vcpus1 3 host-install(3) broken in 16236 pass in 16468

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

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-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-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-i386-xend-qemut-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 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16236 never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 05:18:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 05:18: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 1U9qRZ-0003F1-80; Mon, 25 Feb 2013 05:17:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1U9qRV-0003Ew-19
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 05:17:37 +0000
Received: from [85.158.143.99:24293] by server-2.bemta-4.messagelabs.com id
	2B/05-12656-0F3FA215; Mon, 25 Feb 2013 05:17:36 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361769454!17547876!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21063 invoked from network); 25 Feb 2013 05:17:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-216.messagelabs.com with SMTP;
	25 Feb 2013 05:17:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 24 Feb 2013 21:17:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,732,1355126400"; d="scan'208";a="291292532"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 24 Feb 2013 21:17:32 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Feb 2013 21:17:32 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Mon, 25 Feb 2013 13:17:30 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
	table from PV guest accesses
Thread-Index: AQHOBIp1bevntmDnjEewxuNkgxh7+piKIr2A
Date: Mon, 25 Feb 2013 05:17:29 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564403439E80@SHSMSX101.ccr.corp.intel.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
In-Reply-To: <511297F502000078000BC935@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
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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

Hi, Jan
I think this fix also covers HVM side, right ?   For PV side,  I recalled there was already a fix in Xend to protect PV guest from accessing the related MMIO range. Also for HVM guest, last year you proposed and submitted a patch to Xen-Qemu for blocking guest's accesses to the related MMIO range.    Looks like the previous fixes are not needed any more if this fix got check-in, right ?  
Thanks! 
Xiantao

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Thursday, February 07, 2013 12:51 AM
> To: xen-devel
> Subject: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
> table from PV guest accesses
> 
> This adds two new physdev operations for Dom0 to invoke when resource
> allocation for devices is known to be complete, so that the hypervisor
> can arrange for the respective MMIO ranges to be marked read-only
> before an eventual guest getting such a device assigned even gets
> started, such that it won't be able to set up writable mappings for
> these MMIO ranges before Xen has a chance to protect them.
> 
> This also addresses another issue with the code being modified here,
> in that so far write protection for the address ranges in question got
> set up only once during the lifetime of a device (i.e. until either
> system shutdown or device hot removal), while teardown happened when
> the last interrupt was disposed of by the guest (which at least allowed
> the tables to be writable when the device got assigned to a second
> guest [instance] after the first terminated).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -656,8 +656,8 @@ static u64 read_pci_mem_bar(u16 seg, u8
>   * @entries: pointer to an array of struct msix_entry entries
>   * @nvec: number of @entries
>   *
> - * Setup the MSI-X capability structure of device function with a
> - * single MSI-X irq. A return of zero indicates the successful setup of
> + * Setup the MSI-X capability structure of device function with the
> requested
> + * number MSI-X irqs. A return of zero indicates the successful setup of
>   * requested MSI-X entries with allocated irqs or non-zero for otherwise.
>   **/
>  static int msix_capability_init(struct pci_dev *dev,
> @@ -665,86 +665,69 @@ static int msix_capability_init(struct p
>                                  struct msi_desc **desc,
>                                  unsigned int nr_entries)
>  {
> -    struct msi_desc *entry;
> -    int pos;
> +    struct msi_desc *entry = NULL;
> +    int pos, vf;
>      u16 control;
> -    u64 table_paddr, entry_paddr;
> -    u32 table_offset, entry_offset;
> -    u8 bir;
> -    void __iomem *base;
> -    int idx;
> +    u64 table_paddr;
> +    u32 table_offset;
> +    u8 bir, pbus, pslot, pfunc;
>      u16 seg = dev->seg;
>      u8 bus = dev->bus;
>      u8 slot = PCI_SLOT(dev->devfn);
>      u8 func = PCI_FUNC(dev->devfn);
> 
>      ASSERT(spin_is_locked(&pcidevs_lock));
> -    ASSERT(desc);
> 
>      pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
>      control = pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));
>      msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up */
> 
> -    /* MSI-X Table Initialization */
> -    entry = alloc_msi_entry();
> -    if ( !entry )
> -        return -ENOMEM;
> +    if ( desc )
> +    {
> +        entry = alloc_msi_entry();
> +        if ( !entry )
> +            return -ENOMEM;
> +        ASSERT(msi);
> +    }
> 
> -    /* Request & Map MSI-X table region */
> +    /* Locate MSI-X table region */
>      table_offset = pci_conf_read32(seg, bus, slot, func,
>                                     msix_table_offset_reg(pos));
>      bir = (u8)(table_offset & PCI_MSIX_BIRMASK);
>      table_offset &= ~PCI_MSIX_BIRMASK;
> -    entry_offset = msi->entry_nr * PCI_MSIX_ENTRY_SIZE;
> 
> -    table_paddr = msi->table_base + table_offset;
> -    entry_paddr = table_paddr + entry_offset;
> -    idx = msix_get_fixmap(dev, table_paddr, entry_paddr);
> -    if ( idx < 0 )
> -    {
> -        xfree(entry);
> -        return idx;
> -    }
> -    base = (void *)(fix_to_virt(idx) +
> -        ((unsigned long)entry_paddr & ((1UL << PAGE_SHIFT) - 1)));
> -
> -    entry->msi_attrib.type = PCI_CAP_ID_MSIX;
> -    entry->msi_attrib.is_64 = 1;
> -    entry->msi_attrib.entry_nr = msi->entry_nr;
> -    entry->msi_attrib.maskbit = 1;
> -    entry->msi_attrib.masked = 1;
> -    entry->msi_attrib.pos = pos;
> -    entry->irq = msi->irq;
> -    entry->dev = dev;
> -    entry->mask_base = base;
> -
> -    list_add_tail(&entry->list, &dev->msi_list);
> -
> -    if ( !dev->msix_nr_entries )
> +    if ( !dev->info.is_virtfn )
>      {
> -        u8 pbus, pslot, pfunc;
> -        int vf;
> -        u64 pba_paddr;
> -        u32 pba_offset;
> +        pbus = bus;
> +        pslot = slot;
> +        pfunc = func;
> +        vf = -1;
> +    }
> +    else
> +    {
> +        pbus = dev->info.physfn.bus;
> +        pslot = PCI_SLOT(dev->info.physfn.devfn);
> +        pfunc = PCI_FUNC(dev->info.physfn.devfn);
> +        vf = PCI_BDF2(dev->bus, dev->devfn);
> +    }
> 
> -        if ( !dev->info.is_virtfn )
> -        {
> -            pbus = bus;
> -            pslot = slot;
> -            pfunc = func;
> -            vf = -1;
> -        }
> -        else
> +    table_paddr = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf);
> +    WARN_ON(msi && msi->table_base != table_paddr);
> +    if ( !table_paddr )
> +    {
> +        if ( !msi || !msi->table_base )
>          {
> -            pbus = dev->info.physfn.bus;
> -            pslot = PCI_SLOT(dev->info.physfn.devfn);
> -            pfunc = PCI_FUNC(dev->info.physfn.devfn);
> -            vf = PCI_BDF2(dev->bus, dev->devfn);
> +            xfree(entry);
> +            return -ENXIO;
>          }
> +        table_paddr = msi->table_base;
> +    }
> +    table_paddr += table_offset;
> 
> -        ASSERT(!dev->msix_used_entries);
> -        WARN_ON(msi->table_base !=
> -                read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf));
> +    if ( !dev->msix_used_entries )
> +    {
> +        u64 pba_paddr;
> +        u32 pba_offset;
> 
>          dev->msix_nr_entries = nr_entries;
>          dev->msix_table.first = PFN_DOWN(table_paddr);
> @@ -765,7 +748,42 @@ static int msix_capability_init(struct p
>                                        BITS_TO_LONGS(nr_entries) - 1);
>          WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, dev-
> >msix_pba.first,
>                                          dev->msix_pba.last));
> +    }
> 
> +    if ( entry )
> +    {
> +        /* Map MSI-X table region */
> +        u64 entry_paddr = table_paddr + msi->entry_nr *
> PCI_MSIX_ENTRY_SIZE;
> +        int idx = msix_get_fixmap(dev, table_paddr, entry_paddr);
> +        void __iomem *base;
> +
> +        if ( idx < 0 )
> +        {
> +            xfree(entry);
> +            return idx;
> +        }
> +        base = (void *)(fix_to_virt(idx) +
> +                        ((unsigned long)entry_paddr & (PAGE_SIZE - 1)));
> +
> +        /* Mask interrupt here */
> +        writel(1, base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> +
> +        entry->msi_attrib.type = PCI_CAP_ID_MSIX;
> +        entry->msi_attrib.is_64 = 1;
> +        entry->msi_attrib.entry_nr = msi->entry_nr;
> +        entry->msi_attrib.maskbit = 1;
> +        entry->msi_attrib.masked = 1;
> +        entry->msi_attrib.pos = pos;
> +        entry->irq = msi->irq;
> +        entry->dev = dev;
> +        entry->mask_base = base;
> +
> +        list_add_tail(&entry->list, &dev->msi_list);
> +        *desc = entry;
> +    }
> +
> +    if ( !dev->msix_used_entries )
> +    {
>          if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
>                                  dev->msix_table.last) )
>              WARN();
> @@ -776,7 +794,7 @@ static int msix_capability_init(struct p
>          if ( dev->domain )
>              p2m_change_entry_type_global(dev->domain,
>                                           p2m_mmio_direct, p2m_mmio_direct);
> -        if ( !dev->domain || !paging_mode_translate(dev->domain) )
> +        if ( desc && (!dev->domain || !paging_mode_translate(dev->domain)) )
>          {
>              struct domain *d = dev->domain;
> 
> @@ -790,6 +808,13 @@ static int msix_capability_init(struct p
>                          break;
>              if ( d )
>              {
> +                if ( !IS_PRIV(d) && dev->msix_warned != d->domain_id )
> +                {
> +                    dev->msix_warned = d->domain_id;
> +                    printk(XENLOG_ERR
> +                           "Potentially insecure use of MSI-X on %04x:%02x:%02x.%u by
> Dom%d\n",
> +                           seg, bus, slot, func, d->domain_id);
> +                }
>                  /* XXX How to deal with existing mappings? */
>              }
>          }
> @@ -798,10 +823,6 @@ static int msix_capability_init(struct p
>      WARN_ON(dev->msix_table.first != (table_paddr >> PAGE_SHIFT));
>      ++dev->msix_used_entries;
> 
> -    /* Mask interrupt here */
> -    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> -
> -    *desc = entry;
>      /* Restore MSI-X enabled bits */
>      pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), control);
> 
> @@ -926,6 +947,19 @@ static int __pci_enable_msix(struct msi_
>      return status;
>  }
> 
> +static void _pci_cleanup_msix(struct pci_dev *dev)
> +{
> +    if ( !--dev->msix_used_entries )
> +    {
> +        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
> +                                   dev->msix_table.last) )
> +            WARN();
> +        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
> +                                   dev->msix_pba.last) )
> +            WARN();
> +    }
> +}
> +
>  static void __pci_disable_msix(struct msi_desc *entry)
>  {
>      struct pci_dev *dev;
> @@ -949,15 +983,42 @@ static void __pci_disable_msix(struct ms
> 
>      pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), control);
> 
> -    if ( !--dev->msix_used_entries )
> +    _pci_cleanup_msix(dev);
> +}
> +
> +int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off)
> +{
> +    int rc;
> +    struct pci_dev *pdev;
> +    u8 slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
> +    unsigned int pos = pci_find_cap_offset(seg, bus, slot, func,
> +                                           PCI_CAP_ID_MSIX);
> +
> +    if ( !pos )
> +        return -ENODEV;
> +
> +    spin_lock(&pcidevs_lock);
> +    pdev = pci_get_pdev(seg, bus, devfn);
> +    if ( !pdev )
> +        rc = -ENODEV;
> +    else if ( pdev->msix_used_entries != !!off )
> +        rc = -EBUSY;
> +    else if ( off )
>      {
> -        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
> -                                  dev->msix_table.last) )
> -            WARN();
> -        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
> -                                   dev->msix_pba.last) )
> -            WARN();
> +        _pci_cleanup_msix(pdev);
> +        rc = 0;
>      }
> +    else
> +    {
> +        u16 control = pci_conf_read16(seg, bus, slot, func,
> +                                      msix_control_reg(pos));
> +
> +        rc = msix_capability_init(pdev, NULL, NULL,
> +                                  multi_msix_capable(control));
> +    }
> +    spin_unlock(&pcidevs_lock);
> +
> +    return rc;
>  }
> 
>  /*
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -575,6 +575,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          break;
>      }
> 
> +    case PHYSDEVOP_prepare_msix:
> +    case PHYSDEVOP_release_msix: {
> +        struct physdev_pci_device dev;
> +
> +        if ( copy_from_guest(&dev, arg, 1) )
> +            ret = -EFAULT;
> +        else
> +            ret = pci_prepare_msix(dev.seg, dev.bus, dev.devfn,
> +                                   cmd != PHYSDEVOP_prepare_msix);
> +        break;
> +    }
> +
>      case PHYSDEVOP_pci_mmcfg_reserved: {
>          struct physdev_pci_mmcfg_reserved info;
> 
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -76,6 +76,7 @@ struct msi_desc;
>  /* Helper functions */
>  extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc);
>  extern void pci_disable_msi(struct msi_desc *desc);
> +extern int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off);
>  extern void pci_cleanup_msi(struct pci_dev *pdev);
>  extern void setup_msi_handler(struct irq_desc *, struct msi_desc *);
>  extern void setup_msi_irq(struct irq_desc *);
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -303,6 +303,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_devi
> 
>  #define PHYSDEVOP_pci_device_remove     26
>  #define PHYSDEVOP_restore_msi_ext       27
> +/*
> + * Dom0 should use these two to announce MMIO resources assigned to
> + * MSI-X capable devices won't (prepare) or may (release) change.
> + */
> +#define PHYSDEVOP_prepare_msix          30
> +#define PHYSDEVOP_release_msix          31
>  struct physdev_pci_device {
>      /* IN */
>      uint16_t seg;
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -57,6 +57,7 @@ struct pci_dev {
>      int msix_table_refcnt[MAX_MSIX_TABLE_PAGES];
>      int msix_table_idx[MAX_MSIX_TABLE_PAGES];
>      spinlock_t msix_table_lock;
> +    domid_t msix_warned;
> 
>      struct domain *domain;
>      const u16 seg;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 05:18:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 05:18: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 1U9qRZ-0003F1-80; Mon, 25 Feb 2013 05:17:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1U9qRV-0003Ew-19
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 05:17:37 +0000
Received: from [85.158.143.99:24293] by server-2.bemta-4.messagelabs.com id
	2B/05-12656-0F3FA215; Mon, 25 Feb 2013 05:17:36 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361769454!17547876!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21063 invoked from network); 25 Feb 2013 05:17:34 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-216.messagelabs.com with SMTP;
	25 Feb 2013 05:17:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 24 Feb 2013 21:17:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,732,1355126400"; d="scan'208";a="291292532"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 24 Feb 2013 21:17:32 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 24 Feb 2013 21:17:32 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Mon, 25 Feb 2013 13:17:30 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
	table from PV guest accesses
Thread-Index: AQHOBIp1bevntmDnjEewxuNkgxh7+piKIr2A
Date: Mon, 25 Feb 2013 05:17:29 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564403439E80@SHSMSX101.ccr.corp.intel.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
In-Reply-To: <511297F502000078000BC935@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
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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

Hi, Jan
I think this fix also covers HVM side, right ?   For PV side,  I recalled there was already a fix in Xend to protect PV guest from accessing the related MMIO range. Also for HVM guest, last year you proposed and submitted a patch to Xen-Qemu for blocking guest's accesses to the related MMIO range.    Looks like the previous fixes are not needed any more if this fix got check-in, right ?  
Thanks! 
Xiantao

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Thursday, February 07, 2013 12:51 AM
> To: xen-devel
> Subject: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
> table from PV guest accesses
> 
> This adds two new physdev operations for Dom0 to invoke when resource
> allocation for devices is known to be complete, so that the hypervisor
> can arrange for the respective MMIO ranges to be marked read-only
> before an eventual guest getting such a device assigned even gets
> started, such that it won't be able to set up writable mappings for
> these MMIO ranges before Xen has a chance to protect them.
> 
> This also addresses another issue with the code being modified here,
> in that so far write protection for the address ranges in question got
> set up only once during the lifetime of a device (i.e. until either
> system shutdown or device hot removal), while teardown happened when
> the last interrupt was disposed of by the guest (which at least allowed
> the tables to be writable when the device got assigned to a second
> guest [instance] after the first terminated).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -656,8 +656,8 @@ static u64 read_pci_mem_bar(u16 seg, u8
>   * @entries: pointer to an array of struct msix_entry entries
>   * @nvec: number of @entries
>   *
> - * Setup the MSI-X capability structure of device function with a
> - * single MSI-X irq. A return of zero indicates the successful setup of
> + * Setup the MSI-X capability structure of device function with the
> requested
> + * number MSI-X irqs. A return of zero indicates the successful setup of
>   * requested MSI-X entries with allocated irqs or non-zero for otherwise.
>   **/
>  static int msix_capability_init(struct pci_dev *dev,
> @@ -665,86 +665,69 @@ static int msix_capability_init(struct p
>                                  struct msi_desc **desc,
>                                  unsigned int nr_entries)
>  {
> -    struct msi_desc *entry;
> -    int pos;
> +    struct msi_desc *entry = NULL;
> +    int pos, vf;
>      u16 control;
> -    u64 table_paddr, entry_paddr;
> -    u32 table_offset, entry_offset;
> -    u8 bir;
> -    void __iomem *base;
> -    int idx;
> +    u64 table_paddr;
> +    u32 table_offset;
> +    u8 bir, pbus, pslot, pfunc;
>      u16 seg = dev->seg;
>      u8 bus = dev->bus;
>      u8 slot = PCI_SLOT(dev->devfn);
>      u8 func = PCI_FUNC(dev->devfn);
> 
>      ASSERT(spin_is_locked(&pcidevs_lock));
> -    ASSERT(desc);
> 
>      pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX);
>      control = pci_conf_read16(seg, bus, slot, func, msix_control_reg(pos));
>      msix_set_enable(dev, 0);/* Ensure msix is disabled as I set it up */
> 
> -    /* MSI-X Table Initialization */
> -    entry = alloc_msi_entry();
> -    if ( !entry )
> -        return -ENOMEM;
> +    if ( desc )
> +    {
> +        entry = alloc_msi_entry();
> +        if ( !entry )
> +            return -ENOMEM;
> +        ASSERT(msi);
> +    }
> 
> -    /* Request & Map MSI-X table region */
> +    /* Locate MSI-X table region */
>      table_offset = pci_conf_read32(seg, bus, slot, func,
>                                     msix_table_offset_reg(pos));
>      bir = (u8)(table_offset & PCI_MSIX_BIRMASK);
>      table_offset &= ~PCI_MSIX_BIRMASK;
> -    entry_offset = msi->entry_nr * PCI_MSIX_ENTRY_SIZE;
> 
> -    table_paddr = msi->table_base + table_offset;
> -    entry_paddr = table_paddr + entry_offset;
> -    idx = msix_get_fixmap(dev, table_paddr, entry_paddr);
> -    if ( idx < 0 )
> -    {
> -        xfree(entry);
> -        return idx;
> -    }
> -    base = (void *)(fix_to_virt(idx) +
> -        ((unsigned long)entry_paddr & ((1UL << PAGE_SHIFT) - 1)));
> -
> -    entry->msi_attrib.type = PCI_CAP_ID_MSIX;
> -    entry->msi_attrib.is_64 = 1;
> -    entry->msi_attrib.entry_nr = msi->entry_nr;
> -    entry->msi_attrib.maskbit = 1;
> -    entry->msi_attrib.masked = 1;
> -    entry->msi_attrib.pos = pos;
> -    entry->irq = msi->irq;
> -    entry->dev = dev;
> -    entry->mask_base = base;
> -
> -    list_add_tail(&entry->list, &dev->msi_list);
> -
> -    if ( !dev->msix_nr_entries )
> +    if ( !dev->info.is_virtfn )
>      {
> -        u8 pbus, pslot, pfunc;
> -        int vf;
> -        u64 pba_paddr;
> -        u32 pba_offset;
> +        pbus = bus;
> +        pslot = slot;
> +        pfunc = func;
> +        vf = -1;
> +    }
> +    else
> +    {
> +        pbus = dev->info.physfn.bus;
> +        pslot = PCI_SLOT(dev->info.physfn.devfn);
> +        pfunc = PCI_FUNC(dev->info.physfn.devfn);
> +        vf = PCI_BDF2(dev->bus, dev->devfn);
> +    }
> 
> -        if ( !dev->info.is_virtfn )
> -        {
> -            pbus = bus;
> -            pslot = slot;
> -            pfunc = func;
> -            vf = -1;
> -        }
> -        else
> +    table_paddr = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf);
> +    WARN_ON(msi && msi->table_base != table_paddr);
> +    if ( !table_paddr )
> +    {
> +        if ( !msi || !msi->table_base )
>          {
> -            pbus = dev->info.physfn.bus;
> -            pslot = PCI_SLOT(dev->info.physfn.devfn);
> -            pfunc = PCI_FUNC(dev->info.physfn.devfn);
> -            vf = PCI_BDF2(dev->bus, dev->devfn);
> +            xfree(entry);
> +            return -ENXIO;
>          }
> +        table_paddr = msi->table_base;
> +    }
> +    table_paddr += table_offset;
> 
> -        ASSERT(!dev->msix_used_entries);
> -        WARN_ON(msi->table_base !=
> -                read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf));
> +    if ( !dev->msix_used_entries )
> +    {
> +        u64 pba_paddr;
> +        u32 pba_offset;
> 
>          dev->msix_nr_entries = nr_entries;
>          dev->msix_table.first = PFN_DOWN(table_paddr);
> @@ -765,7 +748,42 @@ static int msix_capability_init(struct p
>                                        BITS_TO_LONGS(nr_entries) - 1);
>          WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, dev-
> >msix_pba.first,
>                                          dev->msix_pba.last));
> +    }
> 
> +    if ( entry )
> +    {
> +        /* Map MSI-X table region */
> +        u64 entry_paddr = table_paddr + msi->entry_nr *
> PCI_MSIX_ENTRY_SIZE;
> +        int idx = msix_get_fixmap(dev, table_paddr, entry_paddr);
> +        void __iomem *base;
> +
> +        if ( idx < 0 )
> +        {
> +            xfree(entry);
> +            return idx;
> +        }
> +        base = (void *)(fix_to_virt(idx) +
> +                        ((unsigned long)entry_paddr & (PAGE_SIZE - 1)));
> +
> +        /* Mask interrupt here */
> +        writel(1, base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> +
> +        entry->msi_attrib.type = PCI_CAP_ID_MSIX;
> +        entry->msi_attrib.is_64 = 1;
> +        entry->msi_attrib.entry_nr = msi->entry_nr;
> +        entry->msi_attrib.maskbit = 1;
> +        entry->msi_attrib.masked = 1;
> +        entry->msi_attrib.pos = pos;
> +        entry->irq = msi->irq;
> +        entry->dev = dev;
> +        entry->mask_base = base;
> +
> +        list_add_tail(&entry->list, &dev->msi_list);
> +        *desc = entry;
> +    }
> +
> +    if ( !dev->msix_used_entries )
> +    {
>          if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
>                                  dev->msix_table.last) )
>              WARN();
> @@ -776,7 +794,7 @@ static int msix_capability_init(struct p
>          if ( dev->domain )
>              p2m_change_entry_type_global(dev->domain,
>                                           p2m_mmio_direct, p2m_mmio_direct);
> -        if ( !dev->domain || !paging_mode_translate(dev->domain) )
> +        if ( desc && (!dev->domain || !paging_mode_translate(dev->domain)) )
>          {
>              struct domain *d = dev->domain;
> 
> @@ -790,6 +808,13 @@ static int msix_capability_init(struct p
>                          break;
>              if ( d )
>              {
> +                if ( !IS_PRIV(d) && dev->msix_warned != d->domain_id )
> +                {
> +                    dev->msix_warned = d->domain_id;
> +                    printk(XENLOG_ERR
> +                           "Potentially insecure use of MSI-X on %04x:%02x:%02x.%u by
> Dom%d\n",
> +                           seg, bus, slot, func, d->domain_id);
> +                }
>                  /* XXX How to deal with existing mappings? */
>              }
>          }
> @@ -798,10 +823,6 @@ static int msix_capability_init(struct p
>      WARN_ON(dev->msix_table.first != (table_paddr >> PAGE_SHIFT));
>      ++dev->msix_used_entries;
> 
> -    /* Mask interrupt here */
> -    writel(1, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> -
> -    *desc = entry;
>      /* Restore MSI-X enabled bits */
>      pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), control);
> 
> @@ -926,6 +947,19 @@ static int __pci_enable_msix(struct msi_
>      return status;
>  }
> 
> +static void _pci_cleanup_msix(struct pci_dev *dev)
> +{
> +    if ( !--dev->msix_used_entries )
> +    {
> +        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
> +                                   dev->msix_table.last) )
> +            WARN();
> +        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
> +                                   dev->msix_pba.last) )
> +            WARN();
> +    }
> +}
> +
>  static void __pci_disable_msix(struct msi_desc *entry)
>  {
>      struct pci_dev *dev;
> @@ -949,15 +983,42 @@ static void __pci_disable_msix(struct ms
> 
>      pci_conf_write16(seg, bus, slot, func, msix_control_reg(pos), control);
> 
> -    if ( !--dev->msix_used_entries )
> +    _pci_cleanup_msix(dev);
> +}
> +
> +int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off)
> +{
> +    int rc;
> +    struct pci_dev *pdev;
> +    u8 slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
> +    unsigned int pos = pci_find_cap_offset(seg, bus, slot, func,
> +                                           PCI_CAP_ID_MSIX);
> +
> +    if ( !pos )
> +        return -ENODEV;
> +
> +    spin_lock(&pcidevs_lock);
> +    pdev = pci_get_pdev(seg, bus, devfn);
> +    if ( !pdev )
> +        rc = -ENODEV;
> +    else if ( pdev->msix_used_entries != !!off )
> +        rc = -EBUSY;
> +    else if ( off )
>      {
> -        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_table.first,
> -                                  dev->msix_table.last) )
> -            WARN();
> -        if ( rangeset_remove_range(mmio_ro_ranges, dev->msix_pba.first,
> -                                   dev->msix_pba.last) )
> -            WARN();
> +        _pci_cleanup_msix(pdev);
> +        rc = 0;
>      }
> +    else
> +    {
> +        u16 control = pci_conf_read16(seg, bus, slot, func,
> +                                      msix_control_reg(pos));
> +
> +        rc = msix_capability_init(pdev, NULL, NULL,
> +                                  multi_msix_capable(control));
> +    }
> +    spin_unlock(&pcidevs_lock);
> +
> +    return rc;
>  }
> 
>  /*
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -575,6 +575,18 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          break;
>      }
> 
> +    case PHYSDEVOP_prepare_msix:
> +    case PHYSDEVOP_release_msix: {
> +        struct physdev_pci_device dev;
> +
> +        if ( copy_from_guest(&dev, arg, 1) )
> +            ret = -EFAULT;
> +        else
> +            ret = pci_prepare_msix(dev.seg, dev.bus, dev.devfn,
> +                                   cmd != PHYSDEVOP_prepare_msix);
> +        break;
> +    }
> +
>      case PHYSDEVOP_pci_mmcfg_reserved: {
>          struct physdev_pci_mmcfg_reserved info;
> 
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -76,6 +76,7 @@ struct msi_desc;
>  /* Helper functions */
>  extern int pci_enable_msi(struct msi_info *msi, struct msi_desc **desc);
>  extern void pci_disable_msi(struct msi_desc *desc);
> +extern int pci_prepare_msix(u16 seg, u8 bus, u8 devfn, bool_t off);
>  extern void pci_cleanup_msi(struct pci_dev *pdev);
>  extern void setup_msi_handler(struct irq_desc *, struct msi_desc *);
>  extern void setup_msi_irq(struct irq_desc *);
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -303,6 +303,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_devi
> 
>  #define PHYSDEVOP_pci_device_remove     26
>  #define PHYSDEVOP_restore_msi_ext       27
> +/*
> + * Dom0 should use these two to announce MMIO resources assigned to
> + * MSI-X capable devices won't (prepare) or may (release) change.
> + */
> +#define PHYSDEVOP_prepare_msix          30
> +#define PHYSDEVOP_release_msix          31
>  struct physdev_pci_device {
>      /* IN */
>      uint16_t seg;
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -57,6 +57,7 @@ struct pci_dev {
>      int msix_table_refcnt[MAX_MSIX_TABLE_PAGES];
>      int msix_table_idx[MAX_MSIX_TABLE_PAGES];
>      spinlock_t msix_table_lock;
> +    domid_t msix_warned;
> 
>      struct domain *domain;
>      const u16 seg;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 06:42:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 06:42: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 1U9rlQ-0004tj-UE; Mon, 25 Feb 2013 06:42:16 +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 1U9rlP-0004te-Ol
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 06:42:15 +0000
Received: from [193.109.254.147:8651] by server-12.bemta-14.messagelabs.com id
	05/0D-32582-7C70B215; Mon, 25 Feb 2013 06:42:15 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361774532!8817509!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13857 invoked from network); 25 Feb 2013 06:42:12 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-27.messagelabs.com with SMTP;
	25 Feb 2013 06:42:12 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 24 Feb 2013 22:42:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,732,1355126400"; d="scan'208";a="295403515"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga002.fm.intel.com with ESMTP; 24 Feb 2013 22:42:07 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: ian.campbell@citrix.com,
	keir@xen.org
Date: Mon, 25 Feb 2013 14:50:10 +0800
Message-Id: <1361775010-3426-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: aliguori@us.ibm.com, Stefano.Stabellini@eu.citrix.com, mst@redhat.com,
	Xudong Hao <xudong.hao@intel.com>, xen-devel@lists.xen.org,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH v2] xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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:
* Define TOM register as one byte

Define a TOM(top of memory) register to report the base of PCI memory, so that
qemu should update MMIO by reading this register value. TOM register are defined
to one byte in PCI configure space, because that only upper 4 bit of PCI memory
takes effect.

With the combination of qemu upstream, this should be a fix for PCI MMIO hole
configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set MMIO
to 0x80000000~0xe0000000.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 tools/firmware/hvmloader/pci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c7c87a7..6d03a6f 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -34,6 +34,29 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+#define PCI_CLASS_BRIDGE_HOST            0x0600
+#define PCI_VENDOR_ID_INTEL              0x8086
+#define PCI_DEVICE_ID_INTEL_82441        0x1237
+#define I440FX_PCI_HOLE_BASE             0xb0
+
+static void pci_adjust_pci_hole(uint8_t pci_hole_start)
+{
+    uint16_t class, vendor_id, device_id;
+    if (pci_hole_start == 0xf0)
+        return;
+
+    /* Check whether it is I440FX */
+    class     = pci_readw(0, PCI_CLASS_DEVICE);
+    vendor_id = pci_readw(0, PCI_VENDOR_ID);
+    device_id = pci_readw(0, PCI_DEVICE_ID);
+
+    if (class != PCI_CLASS_BRIDGE_HOST ||
+        vendor_id != PCI_VENDOR_ID_INTEL ||
+        device_id != PCI_DEVICE_ID_INTEL_82441)
+        return;
+    pci_writeb(0, I440FX_PCI_HOLE_BASE, pci_hole_start);
+
+}
 void pci_setup(void)
 {
     uint8_t is_64bar, using_64bar, bar64_relocate = 0;
@@ -236,6 +259,7 @@ void pci_setup(void)
             BUG();
         hvm_info->high_mem_pgend += nr_pages;
     }
+    pci_adjust_pci_hole((uint8_t)(pci_mem_start >> 24));
 
     high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
     high_mem_resource.max = 1ull << cpu_phys_addr();
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 06:42:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 06:42: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 1U9rlQ-0004tj-UE; Mon, 25 Feb 2013 06:42:16 +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 1U9rlP-0004te-Ol
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 06:42:15 +0000
Received: from [193.109.254.147:8651] by server-12.bemta-14.messagelabs.com id
	05/0D-32582-7C70B215; Mon, 25 Feb 2013 06:42:15 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361774532!8817509!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13857 invoked from network); 25 Feb 2013 06:42:12 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-27.messagelabs.com with SMTP;
	25 Feb 2013 06:42:12 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 24 Feb 2013 22:42:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,732,1355126400"; d="scan'208";a="295403515"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga002.fm.intel.com with ESMTP; 24 Feb 2013 22:42:07 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: ian.campbell@citrix.com,
	keir@xen.org
Date: Mon, 25 Feb 2013 14:50:10 +0800
Message-Id: <1361775010-3426-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: aliguori@us.ibm.com, Stefano.Stabellini@eu.citrix.com, mst@redhat.com,
	Xudong Hao <xudong.hao@intel.com>, xen-devel@lists.xen.org,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH v2] xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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:
* Define TOM register as one byte

Define a TOM(top of memory) register to report the base of PCI memory, so that
qemu should update MMIO by reading this register value. TOM register are defined
to one byte in PCI configure space, because that only upper 4 bit of PCI memory
takes effect.

With the combination of qemu upstream, this should be a fix for PCI MMIO hole
configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set MMIO
to 0x80000000~0xe0000000.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 tools/firmware/hvmloader/pci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c7c87a7..6d03a6f 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -34,6 +34,29 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+#define PCI_CLASS_BRIDGE_HOST            0x0600
+#define PCI_VENDOR_ID_INTEL              0x8086
+#define PCI_DEVICE_ID_INTEL_82441        0x1237
+#define I440FX_PCI_HOLE_BASE             0xb0
+
+static void pci_adjust_pci_hole(uint8_t pci_hole_start)
+{
+    uint16_t class, vendor_id, device_id;
+    if (pci_hole_start == 0xf0)
+        return;
+
+    /* Check whether it is I440FX */
+    class     = pci_readw(0, PCI_CLASS_DEVICE);
+    vendor_id = pci_readw(0, PCI_VENDOR_ID);
+    device_id = pci_readw(0, PCI_DEVICE_ID);
+
+    if (class != PCI_CLASS_BRIDGE_HOST ||
+        vendor_id != PCI_VENDOR_ID_INTEL ||
+        device_id != PCI_DEVICE_ID_INTEL_82441)
+        return;
+    pci_writeb(0, I440FX_PCI_HOLE_BASE, pci_hole_start);
+
+}
 void pci_setup(void)
 {
     uint8_t is_64bar, using_64bar, bar64_relocate = 0;
@@ -236,6 +259,7 @@ void pci_setup(void)
             BUG();
         hvm_info->high_mem_pgend += nr_pages;
     }
+    pci_adjust_pci_hole((uint8_t)(pci_mem_start >> 24));
 
     high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
     high_mem_resource.max = 1ull << cpu_phys_addr();
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 06:46:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 06:46: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 1U9roq-0004zp-Iv; Mon, 25 Feb 2013 06:45:48 +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 1U9rop-0004zh-0S
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 06:45:47 +0000
Received: from [85.158.138.51:60542] by server-10.bemta-3.messagelabs.com id
	CF/C2-10609-9980B215; Mon, 25 Feb 2013 06:45:45 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361774741!23581097!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg4NzM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3729 invoked from network); 25 Feb 2013 06:45:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	25 Feb 2013 06:45:43 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2013 22:44:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,732,1355126400"; d="scan'208";a="290008623"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga002.jf.intel.com with ESMTP; 24 Feb 2013 22:45:33 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: aliguori@us.ibm.com,
	mst@redhat.com,
	qemu-devel@nongnu.org
Date: Mon, 25 Feb 2013 14:53:37 +0800
Message-Id: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: stefano.stabellini@eu.citrix.com, Xudong Hao <xudong.hao@intel.com>,
	xen-devel@lists.xen.org, JBeulich@suse.com, afaerber@suse.de,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH v2] piix: define a TOM register to report the
	base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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:
* Use "piix: " in the subject rather than "qemu: "
* Define TOM register as one byte
* Define default TOM value instead of hardcode 0xe0000000 in more that one place
* Use API pci_set_byte for pci config access
* Use dev->config instead of the indirect d->dev.config

Define a TOM(top of memory) register to report the base of PCI memory, update
memory region dynamically. TOM register are defined to one byte in PCI configure
space, because that only upper 4 bit of PCI memory takes effect for Xen, so
it requires bios set TOM with 16M-aligned.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/pc.h       |  7 +++---
 hw/pc_piix.c  | 12 +++-------
 hw/piix_pci.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------------
 3 files changed, 59 insertions(+), 33 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..62adcc5 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -129,15 +129,14 @@ extern int no_hpet;
 struct PCII440FXState;
 typedef struct PCII440FXState PCII440FXState;
 
+#define I440FX_TOM     0xe0000000
+#define I440FX_XEN_TOM 0xf0000000
+
 PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
                     ISABus **isa_bus, qemu_irq *pic,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory,
                     MemoryRegion *ram_memory);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..2eef510 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
         kvmclock_create();
     }
 
-    if (ram_size >= 0xe0000000 ) {
-        above_4g_mem_size = ram_size - 0xe0000000;
-        below_4g_mem_size = 0xe0000000;
+    if (ram_size >= I440FX_TOM) {
+        above_4g_mem_size = ram_size - I440FX_TOM;
+        below_4g_mem_size = I440FX_TOM;
     } else {
         above_4g_mem_size = 0;
         below_4g_mem_size = ram_size;
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
                               system_memory, system_io, ram_size,
-                              below_4g_mem_size,
-                              0x100000000ULL - below_4g_mem_size,
-                              0x100000000ULL + above_4g_mem_size,
-                              (sizeof(hwaddr) == 4
-                               ? 0
-                               : ((uint64_t)1 << 62)),
                               pci_memory, ram_memory);
     } else {
         pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..3e5a25c 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
 #define I440FX_PAM_SIZE 7
 #define I440FX_SMRAM    0x72
 
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use one byte 0xb0 for the upper 8 bit, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
 static void piix3_set_irq(void *opaque, int pirq, int level);
 static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
 static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
     return (pci_intx + slot_addend) & 3;
 }
 
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+    ram_addr_t above_4g_mem_size;
+    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
+
+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 1) << 24;
+    pci_hole_size = 0x100000000ULL - pci_hole_start;
+
+    if (ram_size >= pci_hole_start) {
+        above_4g_mem_size = ram_size - pci_hole_start;
+    } else {
+        above_4g_mem_size = 0;
+    }
+    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
+    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
+
+    if (del) {
+        memory_region_del_subregion(f->system_memory, &f->pci_hole);
+        if (pci_hole64_size) {
+            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
+        }
+    }
+
+    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
+                             pci_hole_start, pci_hole_size);
+    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
+    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
+                             f->pci_address_space,
+                             pci_hole64_start, pci_hole64_size);
+    if (pci_hole64_size) {
+        memory_region_add_subregion(f->system_memory, pci_hole64_start,
+                                    &f->pci_hole_64bit);
+    }
+}
+
+
 static void i440fx_update_memory_mappings(PCII440FXState *d)
 {
     int i;
@@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
         range_covers_byte(address, len, I440FX_SMRAM)) {
         i440fx_update_memory_mappings(d);
     }
+    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
+        i440fx_update_pci_mem_hole(d, true);
+    }
 }
 
 static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
@@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
 
     d->dev.config[I440FX_SMRAM] = 0x02;
 
+    /* Emulate top of memory, here use 0xe0000000 as default val*/
+    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
+    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >> 24));
+
     cpu_smm_register(&i440fx_set_smm, d);
     return 0;
 }
@@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
                                   MemoryRegion *address_space_mem,
                                   MemoryRegion *address_space_io,
                                   ram_addr_t ram_size,
-                                  hwaddr pci_hole_start,
-                                  hwaddr pci_hole_size,
-                                  hwaddr pci_hole64_start,
-                                  hwaddr pci_hole64_size,
                                   MemoryRegion *pci_address_space,
                                   MemoryRegion *ram_memory)
 {
@@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
     f->ram_memory = ram_memory;
-    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
-                             pci_hole_start, pci_hole_size);
-    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
-    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
-                             f->pci_address_space,
-                             pci_hole64_start, pci_hole64_size);
-    if (pci_hole64_size) {
-        memory_region_add_subregion(f->system_memory, pci_hole64_start,
-                                    &f->pci_hole_64bit);
-    }
     memory_region_init_alias(&f->smram_region, "smram-region",
                              f->pci_address_space, 0xa0000, 0x20000);
     memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
@@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
     (*pi440fx_state)->dev.config[0x57]=ram_size;
 
     i440fx_update_memory_mappings(f);
+    i440fx_update_pci_mem_hole(f, false);
 
     return b;
 }
@@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory, MemoryRegion *ram_memory)
 
 {
@@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
 
     b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
                            address_space_mem, address_space_io, ram_size,
-                           pci_hole_start, pci_hole_size,
-                           pci_hole64_start, pci_hole64_size,
                            pci_memory, ram_memory);
     return b;
 }
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 06:46:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 06:46: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 1U9roq-0004zp-Iv; Mon, 25 Feb 2013 06:45:48 +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 1U9rop-0004zh-0S
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 06:45:47 +0000
Received: from [85.158.138.51:60542] by server-10.bemta-3.messagelabs.com id
	CF/C2-10609-9980B215; Mon, 25 Feb 2013 06:45:45 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361774741!23581097!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg4NzM1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3729 invoked from network); 25 Feb 2013 06:45:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	25 Feb 2013 06:45:43 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 24 Feb 2013 22:44:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,732,1355126400"; d="scan'208";a="290008623"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga002.jf.intel.com with ESMTP; 24 Feb 2013 22:45:33 -0800
From: Xudong Hao <xudong.hao@intel.com>
To: aliguori@us.ibm.com,
	mst@redhat.com,
	qemu-devel@nongnu.org
Date: Mon, 25 Feb 2013 14:53:37 +0800
Message-Id: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: stefano.stabellini@eu.citrix.com, Xudong Hao <xudong.hao@intel.com>,
	xen-devel@lists.xen.org, JBeulich@suse.com, afaerber@suse.de,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH v2] piix: define a TOM register to report the
	base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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:
* Use "piix: " in the subject rather than "qemu: "
* Define TOM register as one byte
* Define default TOM value instead of hardcode 0xe0000000 in more that one place
* Use API pci_set_byte for pci config access
* Use dev->config instead of the indirect d->dev.config

Define a TOM(top of memory) register to report the base of PCI memory, update
memory region dynamically. TOM register are defined to one byte in PCI configure
space, because that only upper 4 bit of PCI memory takes effect for Xen, so
it requires bios set TOM with 16M-aligned.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/pc.h       |  7 +++---
 hw/pc_piix.c  | 12 +++-------
 hw/piix_pci.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------------
 3 files changed, 59 insertions(+), 33 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index fbcf43d..62adcc5 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -129,15 +129,14 @@ extern int no_hpet;
 struct PCII440FXState;
 typedef struct PCII440FXState PCII440FXState;
 
+#define I440FX_TOM     0xe0000000
+#define I440FX_XEN_TOM 0xf0000000
+
 PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
                     ISABus **isa_bus, qemu_irq *pic,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory,
                     MemoryRegion *ram_memory);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0a6923d..2eef510 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
         kvmclock_create();
     }
 
-    if (ram_size >= 0xe0000000 ) {
-        above_4g_mem_size = ram_size - 0xe0000000;
-        below_4g_mem_size = 0xe0000000;
+    if (ram_size >= I440FX_TOM) {
+        above_4g_mem_size = ram_size - I440FX_TOM;
+        below_4g_mem_size = I440FX_TOM;
     } else {
         above_4g_mem_size = 0;
         below_4g_mem_size = ram_size;
@@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
                               system_memory, system_io, ram_size,
-                              below_4g_mem_size,
-                              0x100000000ULL - below_4g_mem_size,
-                              0x100000000ULL + above_4g_mem_size,
-                              (sizeof(hwaddr) == 4
-                               ? 0
-                               : ((uint64_t)1 << 62)),
                               pci_memory, ram_memory);
     } else {
         pci_bus = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 3d79c73..3e5a25c 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -86,6 +86,14 @@ struct PCII440FXState {
 #define I440FX_PAM_SIZE 7
 #define I440FX_SMRAM    0x72
 
+/* The maximum vaule of TOM(top of memory) register in I440FX
+ * is 1G, so it doesn't meet any popular virutal machines, so
+ * define another register to report the base of PCI memory.
+ * Use one byte 0xb0 for the upper 8 bit, they are originally
+ * resevered for host bridge.
+ * */
+#define I440FX_PCI_HOLE_BASE 0xb0
+
 static void piix3_set_irq(void *opaque, int pirq, int level);
 static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
 static void piix3_write_config_xen(PCIDevice *dev,
@@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
     return (pci_intx + slot_addend) & 3;
 }
 
+
+static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
+{
+    ram_addr_t above_4g_mem_size;
+    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
+
+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 1) << 24;
+    pci_hole_size = 0x100000000ULL - pci_hole_start;
+
+    if (ram_size >= pci_hole_start) {
+        above_4g_mem_size = ram_size - pci_hole_start;
+    } else {
+        above_4g_mem_size = 0;
+    }
+    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
+    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
+
+    if (del) {
+        memory_region_del_subregion(f->system_memory, &f->pci_hole);
+        if (pci_hole64_size) {
+            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
+        }
+    }
+
+    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
+                             pci_hole_start, pci_hole_size);
+    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
+    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
+                             f->pci_address_space,
+                             pci_hole64_start, pci_hole64_size);
+    if (pci_hole64_size) {
+        memory_region_add_subregion(f->system_memory, pci_hole64_start,
+                                    &f->pci_hole_64bit);
+    }
+}
+
+
 static void i440fx_update_memory_mappings(PCII440FXState *d)
 {
     int i;
@@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
         range_covers_byte(address, len, I440FX_SMRAM)) {
         i440fx_update_memory_mappings(d);
     }
+    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
+        i440fx_update_pci_mem_hole(d, true);
+    }
 }
 
 static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
@@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
 
     d->dev.config[I440FX_SMRAM] = 0x02;
 
+    /* Emulate top of memory, here use 0xe0000000 as default val*/
+    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
+    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >> 24));
+
     cpu_smm_register(&i440fx_set_smm, d);
     return 0;
 }
@@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
                                   MemoryRegion *address_space_mem,
                                   MemoryRegion *address_space_io,
                                   ram_addr_t ram_size,
-                                  hwaddr pci_hole_start,
-                                  hwaddr pci_hole_size,
-                                  hwaddr pci_hole64_start,
-                                  hwaddr pci_hole64_size,
                                   MemoryRegion *pci_address_space,
                                   MemoryRegion *ram_memory)
 {
@@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
     f->ram_memory = ram_memory;
-    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
-                             pci_hole_start, pci_hole_size);
-    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
-    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
-                             f->pci_address_space,
-                             pci_hole64_start, pci_hole64_size);
-    if (pci_hole64_size) {
-        memory_region_add_subregion(f->system_memory, pci_hole64_start,
-                                    &f->pci_hole_64bit);
-    }
     memory_region_init_alias(&f->smram_region, "smram-region",
                              f->pci_address_space, 0xa0000, 0x20000);
     memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
@@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
     (*pi440fx_state)->dev.config[0x57]=ram_size;
 
     i440fx_update_memory_mappings(f);
+    i440fx_update_pci_mem_hole(f, false);
 
     return b;
 }
@@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
                     MemoryRegion *address_space_mem,
                     MemoryRegion *address_space_io,
                     ram_addr_t ram_size,
-                    hwaddr pci_hole_start,
-                    hwaddr pci_hole_size,
-                    hwaddr pci_hole64_start,
-                    hwaddr pci_hole64_size,
                     MemoryRegion *pci_memory, MemoryRegion *ram_memory)
 
 {
@@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
 
     b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
                            address_space_mem, address_space_io, ram_size,
-                           pci_hole_start, pci_hole_size,
-                           pci_hole64_start, pci_hole64_size,
                            pci_memory, ram_memory);
     return b;
 }
-- 
1.7.12.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 07:08:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 07:08: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 1U9s9y-0005i4-0s; Mon, 25 Feb 2013 07:07:38 +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 1U9s9v-0005hz-E1
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 07:07:35 +0000
Received: from [85.158.137.99:64354] by server-6.bemta-3.messagelabs.com id
	53/46-29959-6BD0B215; Mon, 25 Feb 2013 07:07:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361776045!17770285!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10991 invoked from network); 25 Feb 2013 07:07:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 07:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,732,1355097600"; 
   d="scan'208";a="1826167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 07:07: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.297.1; Mon, 25 Feb 2013 07:07:25 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9s9l-0005Zt-4P;
	Mon, 25 Feb 2013 07:07:25 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9s9k-0008Uj-3a;
	Mon, 25 Feb 2013 07:07:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16508-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 07:07:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16508: 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 16508 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16508/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6743c50ca91da63de23ad52f037bf9eadacfb492
+ branch=xen-4.1-testing
+ revision=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : 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
++ : osstest@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
++ : 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=osstest@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@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 6743c50ca91da63de23ad52f037bf9eadacfb492 ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
------------------------------------------------------------
commit 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 07:08:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 07:08: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 1U9s9y-0005i4-0s; Mon, 25 Feb 2013 07:07:38 +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 1U9s9v-0005hz-E1
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 07:07:35 +0000
Received: from [85.158.137.99:64354] by server-6.bemta-3.messagelabs.com id
	53/46-29959-6BD0B215; Mon, 25 Feb 2013 07:07:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361776045!17770285!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10991 invoked from network); 25 Feb 2013 07:07:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 07:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,732,1355097600"; 
   d="scan'208";a="1826167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 07:07: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.297.1; Mon, 25 Feb 2013 07:07:25 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9s9l-0005Zt-4P;
	Mon, 25 Feb 2013 07:07:25 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9s9k-0008Uj-3a;
	Mon, 25 Feb 2013 07:07:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16508-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 07:07:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16508: 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 16508 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16508/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6743c50ca91da63de23ad52f037bf9eadacfb492
+ branch=xen-4.1-testing
+ revision=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : 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
++ : osstest@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
++ : 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=osstest@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@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 6743c50ca91da63de23ad52f037bf9eadacfb492 ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
------------------------------------------------------------
commit 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 07:47:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 07:47: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 1U9smO-0006Up-Hx; Mon, 25 Feb 2013 07:47:20 +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 1U9smN-0006Uk-DX
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 07:47:19 +0000
Received: from [85.158.143.99:7680] by server-1.bemta-4.messagelabs.com id
	3F/55-06203-6071B215; Mon, 25 Feb 2013 07:47:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361778406!22006355!1
X-Originating-IP: [74.125.82.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15384 invoked from network); 25 Feb 2013 07:46:46 -0000
Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com)
	(74.125.82.176)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 07:46:46 -0000
Received: by mail-we0-f176.google.com with SMTP id s43so2132318wey.7
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 23:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ihyD51/PILsBWUV0TKeYfMicMhv8+zpg990qco1Gc7E=;
	b=Z14WlfR1+AGXNgidgADCGqQCqG6aS+eWypwB1tuiWKILfpCsEVmuzC2N41S9po1h8D
	/Ednjtewac2pwf6TCR6RqFUJXJMDh1axxYWgSNXZ043ivu4nkTeQxlWAuRThFuj7OPrf
	JLiEiUW5hnXI7jFaPJTGERl0ehDx/rVywyHFvO1k2ewT4nINRmAi9HfuoMQJQv8c4/zH
	Dvmv+ZAdPhWzPsXr++oFkRYA3meMNbIarfV70hVUzHVrhzzvdJFtn1cy0fn0NrUbHG4e
	u0WqVI+IqwRjP6cX0mJtwmB89wZHz7C/tULaR3eR9sjYu6KfLaR/RNAvB9s7Dz19x6mh
	7Mbg==
X-Received: by 10.194.90.168 with SMTP id bx8mr16754941wjb.59.1361778406495;
	Sun, 24 Feb 2013 23:46:46 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ed6sm14719313wib.9.2013.02.24.23.46.40
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Sun, 24 Feb 2013 23:46:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 25 Feb 2013 07:46:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Xudong Hao <xudong.hao@intel.com>,
	<ian.campbell@citrix.com>
Message-ID: <CD50C75C.4C8F6%keir.xen@gmail.com>
Thread-Topic: [PATCH v2] xen/hvmloader: define a TOM register
Thread-Index: Ac4TLDzOPOPgU3J6H0umf8qsHLRHEw==
In-Reply-To: <1361775010-3426-1-git-send-email-xudong.hao@intel.com>
Mime-version: 1.0
Cc: aliguori@us.ibm.com, Stefano.Stabellini@eu.citrix.com, mst@redhat.com,
	Xiantao Zhang <xiantao.zhang@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 06:50, "Xudong Hao" <xudong.hao@intel.com> wrote:

> v2:
> * Define TOM register as one byte
> 
> Define a TOM(top of memory) register to report the base of PCI memory, so that
> qemu should update MMIO by reading this register value. TOM register are
> defined
> to one byte in PCI configure space, because that only upper 4 bit of PCI
> memory
> takes effect.
> 
> With the combination of qemu upstream, this should be a fix for PCI MMIO hole
> configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set
> MMIO
> to 0x80000000~0xe0000000.

Why does qemu (when used as the Xen device model) care about the location of
the PCI hole start?

 -- Keir

> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> ---
>  tools/firmware/hvmloader/pci.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index c7c87a7..6d03a6f 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -34,6 +34,29 @@ unsigned long pci_mem_end = PCI_MEM_END;
>  enum virtual_vga virtual_vga = VGA_none;
>  unsigned long igd_opregion_pgbase = 0;
>  
> +#define PCI_CLASS_BRIDGE_HOST            0x0600
> +#define PCI_VENDOR_ID_INTEL              0x8086
> +#define PCI_DEVICE_ID_INTEL_82441        0x1237
> +#define I440FX_PCI_HOLE_BASE             0xb0
> +
> +static void pci_adjust_pci_hole(uint8_t pci_hole_start)
> +{
> +    uint16_t class, vendor_id, device_id;
> +    if (pci_hole_start == 0xf0)
> +        return;
> +
> +    /* Check whether it is I440FX */
> +    class     = pci_readw(0, PCI_CLASS_DEVICE);
> +    vendor_id = pci_readw(0, PCI_VENDOR_ID);
> +    device_id = pci_readw(0, PCI_DEVICE_ID);
> +
> +    if (class != PCI_CLASS_BRIDGE_HOST ||
> +        vendor_id != PCI_VENDOR_ID_INTEL ||
> +        device_id != PCI_DEVICE_ID_INTEL_82441)
> +        return;
> +    pci_writeb(0, I440FX_PCI_HOLE_BASE, pci_hole_start);
> +
> +}
>  void pci_setup(void)
>  {
>      uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> @@ -236,6 +259,7 @@ void pci_setup(void)
>              BUG();
>          hvm_info->high_mem_pgend += nr_pages;
>      }
> +    pci_adjust_pci_hole((uint8_t)(pci_mem_start >> 24));
>  
>      high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
> PAGE_SHIFT; 
>      high_mem_resource.max = 1ull << cpu_phys_addr();



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 07:47:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 07:47: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 1U9smO-0006Up-Hx; Mon, 25 Feb 2013 07:47:20 +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 1U9smN-0006Uk-DX
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 07:47:19 +0000
Received: from [85.158.143.99:7680] by server-1.bemta-4.messagelabs.com id
	3F/55-06203-6071B215; Mon, 25 Feb 2013 07:47:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361778406!22006355!1
X-Originating-IP: [74.125.82.176]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15384 invoked from network); 25 Feb 2013 07:46:46 -0000
Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com)
	(74.125.82.176)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 07:46:46 -0000
Received: by mail-we0-f176.google.com with SMTP id s43so2132318wey.7
	for <xen-devel@lists.xen.org>; Sun, 24 Feb 2013 23:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ihyD51/PILsBWUV0TKeYfMicMhv8+zpg990qco1Gc7E=;
	b=Z14WlfR1+AGXNgidgADCGqQCqG6aS+eWypwB1tuiWKILfpCsEVmuzC2N41S9po1h8D
	/Ednjtewac2pwf6TCR6RqFUJXJMDh1axxYWgSNXZ043ivu4nkTeQxlWAuRThFuj7OPrf
	JLiEiUW5hnXI7jFaPJTGERl0ehDx/rVywyHFvO1k2ewT4nINRmAi9HfuoMQJQv8c4/zH
	Dvmv+ZAdPhWzPsXr++oFkRYA3meMNbIarfV70hVUzHVrhzzvdJFtn1cy0fn0NrUbHG4e
	u0WqVI+IqwRjP6cX0mJtwmB89wZHz7C/tULaR3eR9sjYu6KfLaR/RNAvB9s7Dz19x6mh
	7Mbg==
X-Received: by 10.194.90.168 with SMTP id bx8mr16754941wjb.59.1361778406495;
	Sun, 24 Feb 2013 23:46:46 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ed6sm14719313wib.9.2013.02.24.23.46.40
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Sun, 24 Feb 2013 23:46:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Mon, 25 Feb 2013 07:46:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Xudong Hao <xudong.hao@intel.com>,
	<ian.campbell@citrix.com>
Message-ID: <CD50C75C.4C8F6%keir.xen@gmail.com>
Thread-Topic: [PATCH v2] xen/hvmloader: define a TOM register
Thread-Index: Ac4TLDzOPOPgU3J6H0umf8qsHLRHEw==
In-Reply-To: <1361775010-3426-1-git-send-email-xudong.hao@intel.com>
Mime-version: 1.0
Cc: aliguori@us.ibm.com, Stefano.Stabellini@eu.citrix.com, mst@redhat.com,
	Xiantao Zhang <xiantao.zhang@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 06:50, "Xudong Hao" <xudong.hao@intel.com> wrote:

> v2:
> * Define TOM register as one byte
> 
> Define a TOM(top of memory) register to report the base of PCI memory, so that
> qemu should update MMIO by reading this register value. TOM register are
> defined
> to one byte in PCI configure space, because that only upper 4 bit of PCI
> memory
> takes effect.
> 
> With the combination of qemu upstream, this should be a fix for PCI MMIO hole
> configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set
> MMIO
> to 0x80000000~0xe0000000.

Why does qemu (when used as the Xen device model) care about the location of
the PCI hole start?

 -- Keir

> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> ---
>  tools/firmware/hvmloader/pci.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index c7c87a7..6d03a6f 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -34,6 +34,29 @@ unsigned long pci_mem_end = PCI_MEM_END;
>  enum virtual_vga virtual_vga = VGA_none;
>  unsigned long igd_opregion_pgbase = 0;
>  
> +#define PCI_CLASS_BRIDGE_HOST            0x0600
> +#define PCI_VENDOR_ID_INTEL              0x8086
> +#define PCI_DEVICE_ID_INTEL_82441        0x1237
> +#define I440FX_PCI_HOLE_BASE             0xb0
> +
> +static void pci_adjust_pci_hole(uint8_t pci_hole_start)
> +{
> +    uint16_t class, vendor_id, device_id;
> +    if (pci_hole_start == 0xf0)
> +        return;
> +
> +    /* Check whether it is I440FX */
> +    class     = pci_readw(0, PCI_CLASS_DEVICE);
> +    vendor_id = pci_readw(0, PCI_VENDOR_ID);
> +    device_id = pci_readw(0, PCI_DEVICE_ID);
> +
> +    if (class != PCI_CLASS_BRIDGE_HOST ||
> +        vendor_id != PCI_VENDOR_ID_INTEL ||
> +        device_id != PCI_DEVICE_ID_INTEL_82441)
> +        return;
> +    pci_writeb(0, I440FX_PCI_HOLE_BASE, pci_hole_start);
> +
> +}
>  void pci_setup(void)
>  {
>      uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> @@ -236,6 +259,7 @@ void pci_setup(void)
>              BUG();
>          hvm_info->high_mem_pgend += nr_pages;
>      }
> +    pci_adjust_pci_hole((uint8_t)(pci_mem_start >> 24));
>  
>      high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
> PAGE_SHIFT; 
>      high_mem_resource.max = 1ull << cpu_phys_addr();



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 08:49:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 08:49: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 1U9tk4-0008NB-3i; Mon, 25 Feb 2013 08:49:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ipavlikevich@gmail.com>) id 1U9tIv-0007pH-Vv
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 08:20:58 +0000
Received: from [85.158.139.211:63651] by server-7.bemta-5.messagelabs.com id
	3A/5D-12441-9EE1B215; Mon, 25 Feb 2013 08:20:57 +0000
X-Env-Sender: ipavlikevich@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361780432!18632244!1
X-Originating-IP: [209.85.217.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17171 invoked from network); 25 Feb 2013 08:20:32 -0000
Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com)
	(209.85.217.174)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 08:20:32 -0000
Received: by mail-lb0-f174.google.com with SMTP id l12so2049076lbo.33
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 00:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:content-type:mime-version:content-transfer-encoding
	:subject:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=/1B1fLl3Har0qYuF3zKpEiIyu1EyYIncf7EJ3Ju6+T4=;
	b=OU+hHyGVKEmP8YJXc4RJeTZXm+Arsb885GeuBSr1A0aRTW4JrOGMVT9OmixJKegoGJ
	H2oAULor35vMXO+OTXQtRxnHxNt7kW7/Eufmd0UR0UWxW8ukgzeq3Ylrqyz7x8VwoktV
	P/SCWcQZfI07RKlgcy+LRvSuEJRsAUIXkeIswsASfGvo0aUfEgqnjilaRRZL9MmNA54F
	8VJ+oyVaW1y5j6e+93p1HyIySMmrZpnHgbXNeCmFwRu8OiQiI3jISYVW4Se153H/Vpof
	AuWvzy2Szx7uvIA+gpxIOYpi/U45erqWuphJRFmvEHFWjBS3Ho1XnFNZU24lKDXKaqUg
	rAhQ==
X-Received: by 10.112.38.98 with SMTP id f2mr4088719lbk.61.1361780431810;
	Mon, 25 Feb 2013 00:20:31 -0800 (PST)
Received: from backup2.adv.ru ([80.255.20.22])
	by mx.google.com with ESMTPS id v7sm3831926lbg.13.2013.02.25.00.20.30
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 00:20:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4d2fb69d362be0cf33d98755b223c4a3e2ee62a4
Message-Id: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 25 Feb 2013 08:20:55 +0000
From: Igor Pavlikevich <ipavlikevich@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 25 Feb 2013 08:48:59 +0000
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] credit: fix race condition in csched_vcpu 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

When vcpu stops yielding, it's possible to overwrite CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_YIELD.

 332.970218393 -------x d1v1 runstate_continue d1v1 running->running
]332.970248371 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]                  yielding, flags=0x0002
]332.970251968 -------x d1v1                                           clearing 0x0002, flags=0
 332.970252175 -------x d1v1 runstate_continue d1v1 running->running
]332.970282574 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]                  yielding, flags=0x0002
]332.970283068 x------| d32767v0                                       entering csched_acct(), d1v1 flags=0x0002
]332.970285763 x------| d32767v0   28003(2:8:3) 2 [ 1 1 ]              calling vcpu_pause_nosync() for d1v1
]332.970286647 -------x d1v1                                           clearing 0x0002, flags=0
]332.970286771 x------| d32767v0                                       flags |= CSCHED_FLAG_VCPU_PARKED, flags=0x0003
]332.970286990 -------x d1v1   2800e(2:8:e) 2 [ 1 1cacfca ]
]332.970287122 -------x d1v1   2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]
]332.970287242 -------x d1v1   2800a(2:8:a) 4 [ 1 1 7fff 7 ]           exiting schedule(), flags=0
 332.970287417 -------x d1v1 runstate_change d1v1 running->offline
 332.970287629 -------x d?v? runstate_change d32767v7 runnable->running
]332.970288397 x------- d32767v0                                       exiting csched_acct(), flags=0x0003
]332.995349690 x------- d32767v0                                       entering csched_acct(), d1v1 flags=0x0000, flag lost.
]332.995352170 x------- d32767v0   28003(2:8:3) 2 [ 1 1 ]              calling vcpu_pause_nosync() for d1v1 again

>From this moment d1v1 has extra +1 in pause_count, so it goes offline right after credit>prv->credits_per_tslice forever.

Signed-off-by: Igor Pavlikevich <ipavlikevich@gmail.com>

diff -r 66f563be41d9 -r 4d2fb69d362b xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Feb 19 10:49:53 2013 +0100
+++ b/xen/common/sched_credit.c	Mon Feb 25 07:54:02 2013 +0000
@@ -1155,7 +1155,9 @@ csched_acct(void* dummy)
                 {
                     SCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
+                    vcpu_schedule_lock_irq(svc->vcpu);
                     svc->flags |= CSCHED_FLAG_VCPU_PARKED;
+                    vcpu_schedule_unlock_irq(svc->vcpu);
                 }
 
                 /* Lower bound on credits */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 08:49:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 08:49: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 1U9tk4-0008NB-3i; Mon, 25 Feb 2013 08:49:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ipavlikevich@gmail.com>) id 1U9tIv-0007pH-Vv
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 08:20:58 +0000
Received: from [85.158.139.211:63651] by server-7.bemta-5.messagelabs.com id
	3A/5D-12441-9EE1B215; Mon, 25 Feb 2013 08:20:57 +0000
X-Env-Sender: ipavlikevich@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361780432!18632244!1
X-Originating-IP: [209.85.217.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17171 invoked from network); 25 Feb 2013 08:20:32 -0000
Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com)
	(209.85.217.174)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 08:20:32 -0000
Received: by mail-lb0-f174.google.com with SMTP id l12so2049076lbo.33
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 00:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:content-type:mime-version:content-transfer-encoding
	:subject:x-mercurial-node:message-id:user-agent:date:from:to:cc;
	bh=/1B1fLl3Har0qYuF3zKpEiIyu1EyYIncf7EJ3Ju6+T4=;
	b=OU+hHyGVKEmP8YJXc4RJeTZXm+Arsb885GeuBSr1A0aRTW4JrOGMVT9OmixJKegoGJ
	H2oAULor35vMXO+OTXQtRxnHxNt7kW7/Eufmd0UR0UWxW8ukgzeq3Ylrqyz7x8VwoktV
	P/SCWcQZfI07RKlgcy+LRvSuEJRsAUIXkeIswsASfGvo0aUfEgqnjilaRRZL9MmNA54F
	8VJ+oyVaW1y5j6e+93p1HyIySMmrZpnHgbXNeCmFwRu8OiQiI3jISYVW4Se153H/Vpof
	AuWvzy2Szx7uvIA+gpxIOYpi/U45erqWuphJRFmvEHFWjBS3Ho1XnFNZU24lKDXKaqUg
	rAhQ==
X-Received: by 10.112.38.98 with SMTP id f2mr4088719lbk.61.1361780431810;
	Mon, 25 Feb 2013 00:20:31 -0800 (PST)
Received: from backup2.adv.ru ([80.255.20.22])
	by mx.google.com with ESMTPS id v7sm3831926lbg.13.2013.02.25.00.20.30
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 00:20:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4d2fb69d362be0cf33d98755b223c4a3e2ee62a4
Message-Id: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 25 Feb 2013 08:20:55 +0000
From: Igor Pavlikevich <ipavlikevich@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Mon, 25 Feb 2013 08:48:59 +0000
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] credit: fix race condition in csched_vcpu 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

When vcpu stops yielding, it's possible to overwrite CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_YIELD.

 332.970218393 -------x d1v1 runstate_continue d1v1 running->running
]332.970248371 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]                  yielding, flags=0x0002
]332.970251968 -------x d1v1                                           clearing 0x0002, flags=0
 332.970252175 -------x d1v1 runstate_continue d1v1 running->running
]332.970282574 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]                  yielding, flags=0x0002
]332.970283068 x------| d32767v0                                       entering csched_acct(), d1v1 flags=0x0002
]332.970285763 x------| d32767v0   28003(2:8:3) 2 [ 1 1 ]              calling vcpu_pause_nosync() for d1v1
]332.970286647 -------x d1v1                                           clearing 0x0002, flags=0
]332.970286771 x------| d32767v0                                       flags |= CSCHED_FLAG_VCPU_PARKED, flags=0x0003
]332.970286990 -------x d1v1   2800e(2:8:e) 2 [ 1 1cacfca ]
]332.970287122 -------x d1v1   2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]
]332.970287242 -------x d1v1   2800a(2:8:a) 4 [ 1 1 7fff 7 ]           exiting schedule(), flags=0
 332.970287417 -------x d1v1 runstate_change d1v1 running->offline
 332.970287629 -------x d?v? runstate_change d32767v7 runnable->running
]332.970288397 x------- d32767v0                                       exiting csched_acct(), flags=0x0003
]332.995349690 x------- d32767v0                                       entering csched_acct(), d1v1 flags=0x0000, flag lost.
]332.995352170 x------- d32767v0   28003(2:8:3) 2 [ 1 1 ]              calling vcpu_pause_nosync() for d1v1 again

>From this moment d1v1 has extra +1 in pause_count, so it goes offline right after credit>prv->credits_per_tslice forever.

Signed-off-by: Igor Pavlikevich <ipavlikevich@gmail.com>

diff -r 66f563be41d9 -r 4d2fb69d362b xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Feb 19 10:49:53 2013 +0100
+++ b/xen/common/sched_credit.c	Mon Feb 25 07:54:02 2013 +0000
@@ -1155,7 +1155,9 @@ csched_acct(void* dummy)
                 {
                     SCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
+                    vcpu_schedule_lock_irq(svc->vcpu);
                     svc->flags |= CSCHED_FLAG_VCPU_PARKED;
+                    vcpu_schedule_unlock_irq(svc->vcpu);
                 }
 
                 /* Lower bound on credits */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:11:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:11: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 1U9u59-0000SL-5I; Mon, 25 Feb 2013 09:10:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1U9u57-0000SG-A5
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:10:45 +0000
Received: from [85.158.139.83:37399] by server-11.bemta-5.messagelabs.com id
	19/C9-27486-49A2B215; Mon, 25 Feb 2013 09:10:44 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361783424!28808340!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18010 invoked from network); 25 Feb 2013 09:10:25 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-5.tower-182.messagelabs.com with SMTP;
	25 Feb 2013 09:10:25 -0000
Received: from p5b2e2e01.dip.t-dialin.net ([91.46.46.1] 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 1U9u4j-00039i-AI; Mon, 25 Feb 2013 09:10:21 +0000
Message-ID: <512B2A7C.1050906@canonical.com>
Date: Mon, 25 Feb 2013 10:10:20 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
X-Enigmail-Version: 1.4.6
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5205586490444852222=="
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)
--===============5205586490444852222==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig97FCB6AB750103D9194CF12B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig97FCB6AB750103D9194CF12B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 25.02.2013 04:15, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>> Hi Konrad,
>>
>> Hey Stefan,
>>>
>>> here is another one from the hm-what? department:
>>
>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
>> he has been tracking a similar one with mcelog.
>>>
>>> Colin discovered that running the attached program with the fork
>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
>>> iomem) this triggers the following weird messages:=20
>>>
>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>> [ 6824.453776] ------------[ cut here ]------------
>>> [ 6824.453796] WARNING: at
>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>> mmap-example Tainted: GF=20
>>> 3.8.0-6-generic #13-Ubuntu
>>> [ 6824.453926] Call Trace:
>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>
>>> I found that this is related to your bandaid patch
>>>
>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>
>>>     xen/pat: Disable PAT support for now.
>>>
>>> I just do not understand how this happens. From the trace it seems
>>> the fork=20
>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
>>> maybe the=20
>>> warning is just related to this. So primarily the question is how on
>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>> cleared from the supported=20
>>> mask by the patch, so somehow I would think nothing should be able
>>> to set it...=20
>>> But apparently not so.
>>> Not sure it is a big deal since I never saw this in normal operation
>>> and it=20
>>> seems to be ok when unapping before doing the fork. It is just plain
>>> odd.=20
>>
>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the=

>> ranges are swapped or not correct. Jinsong, could you shed some light
>> on what you have found so far?
>>
>=20
> Yes, Sander once also reported a similar weird warning when start mcelo=
g daemon, as attached.
>=20
> Basically, it occurs when mcelog user daemon start,=20
> do_fork
>   --> copy_process
>     --> dup_mm
>       --> dup_mmap
>         --> copy_page_range
>           --> track_pfn_copy
>             --> reserve_pfn_range
>               --> line 624: flags !=3D want_flags
> It comes from different memory types of page table (_PAGE_CACHE_WB) and=
 mtrr (_PAGE_CACHE_UC_MINUS).
>=20
> However, why it get different memory types from page table and mtrr is =
still unclear, reproducing the bug is difficult and unstable.
>=20
> Thanks,

Ok, so this seems to take the same code paths. As for the test program, i=
t fails
on duplicating some mmap on a fork. The test program does this all the ti=
me
(except the backtrace warning which is warn_once).
So you say, the UC- comes from the MTRR side... Hm, have to look at that.=


Thanks,
Stefan


--------------enig97FCB6AB750103D9194CF12B
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRKyp8AAoJEOhnXe7L7s6jxLwP/3AefCujtswFgxqD4C2HG1ww
dkp2oIJBe+Cu40HzIGRD2XJgBQ/BRXBp5JnJ5uBQr3YnbywHj/5nYzGM5SJBeqxf
2xqhASFz9Kkbe/ZGQf/7Yasj+8Q1x4/JS0CzswG0Ad0AFMubG37a4bGyFBNzz1Xn
n2UPGGDxrhEwSisDbJ6gXl448lkkdrkvhfmrbGmJM41G9VYpVb4jaDpf1SiY8/h5
KefjUSX7bfsDSixs6Be7G5clUufCSOCXCAL/cOkAj9Ww/KpSjZmOqljKITeEi9Jv
xnCJn+c6qFsKGx2nwnF4NoHhqYw0nvKTPrJOQmu3CZpaX69H/37foIpawcS1hNta
uzGJh8iUyS8IxMpYAg2pQ/dtqNbf2gK9gfe1mlPgYR64ix5XjkVukjQ0HuHUQX27
PFjOZfoRUvELIbk0wcwrObk9pylhGTYzdPWNAZj/FIK1gGYEGQ3nqyMZoLeCyssa
umqoGvHPrLi9kwsdS5bHLqbOxN5N8RsrzNjpxuYBc2G7kdrS2g+wySOE1dPT3Cck
kX+JkmFI7zHIpFh4S+gxoj9RrOL/8jX+9QOTWPU6bUQ7d01NbJXXUGQO0Qr9aWms
/lTMdLRBfDmCyBEiQZ4E6EwbL+VP/7+gcs0YEUG5oiHa9N4KxA3e76H95f83i+OY
ED0WY48/5DlVaMv05qdT
=FKX3
-----END PGP SIGNATURE-----

--------------enig97FCB6AB750103D9194CF12B--


--===============5205586490444852222==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5205586490444852222==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 09:11:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:11: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 1U9u59-0000SL-5I; Mon, 25 Feb 2013 09:10:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1U9u57-0000SG-A5
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:10:45 +0000
Received: from [85.158.139.83:37399] by server-11.bemta-5.messagelabs.com id
	19/C9-27486-49A2B215; Mon, 25 Feb 2013 09:10:44 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361783424!28808340!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18010 invoked from network); 25 Feb 2013 09:10:25 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-5.tower-182.messagelabs.com with SMTP;
	25 Feb 2013 09:10:25 -0000
Received: from p5b2e2e01.dip.t-dialin.net ([91.46.46.1] 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 1U9u4j-00039i-AI; Mon, 25 Feb 2013 09:10:21 +0000
Message-ID: <512B2A7C.1050906@canonical.com>
Date: Mon, 25 Feb 2013 10:10:20 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
X-Enigmail-Version: 1.4.6
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5205586490444852222=="
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)
--===============5205586490444852222==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig97FCB6AB750103D9194CF12B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig97FCB6AB750103D9194CF12B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 25.02.2013 04:15, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>> Hi Konrad,
>>
>> Hey Stefan,
>>>
>>> here is another one from the hm-what? department:
>>
>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
>> he has been tracking a similar one with mcelog.
>>>
>>> Colin discovered that running the attached program with the fork
>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
>>> iomem) this triggers the following weird messages:=20
>>>
>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>> [ 6824.453776] ------------[ cut here ]------------
>>> [ 6824.453796] WARNING: at
>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>> mmap-example Tainted: GF=20
>>> 3.8.0-6-generic #13-Ubuntu
>>> [ 6824.453926] Call Trace:
>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>
>>> I found that this is related to your bandaid patch
>>>
>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>
>>>     xen/pat: Disable PAT support for now.
>>>
>>> I just do not understand how this happens. From the trace it seems
>>> the fork=20
>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
>>> maybe the=20
>>> warning is just related to this. So primarily the question is how on
>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>> cleared from the supported=20
>>> mask by the patch, so somehow I would think nothing should be able
>>> to set it...=20
>>> But apparently not so.
>>> Not sure it is a big deal since I never saw this in normal operation
>>> and it=20
>>> seems to be ok when unapping before doing the fork. It is just plain
>>> odd.=20
>>
>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the=

>> ranges are swapped or not correct. Jinsong, could you shed some light
>> on what you have found so far?
>>
>=20
> Yes, Sander once also reported a similar weird warning when start mcelo=
g daemon, as attached.
>=20
> Basically, it occurs when mcelog user daemon start,=20
> do_fork
>   --> copy_process
>     --> dup_mm
>       --> dup_mmap
>         --> copy_page_range
>           --> track_pfn_copy
>             --> reserve_pfn_range
>               --> line 624: flags !=3D want_flags
> It comes from different memory types of page table (_PAGE_CACHE_WB) and=
 mtrr (_PAGE_CACHE_UC_MINUS).
>=20
> However, why it get different memory types from page table and mtrr is =
still unclear, reproducing the bug is difficult and unstable.
>=20
> Thanks,

Ok, so this seems to take the same code paths. As for the test program, i=
t fails
on duplicating some mmap on a fork. The test program does this all the ti=
me
(except the backtrace warning which is warn_once).
So you say, the UC- comes from the MTRR side... Hm, have to look at that.=


Thanks,
Stefan


--------------enig97FCB6AB750103D9194CF12B
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRKyp8AAoJEOhnXe7L7s6jxLwP/3AefCujtswFgxqD4C2HG1ww
dkp2oIJBe+Cu40HzIGRD2XJgBQ/BRXBp5JnJ5uBQr3YnbywHj/5nYzGM5SJBeqxf
2xqhASFz9Kkbe/ZGQf/7Yasj+8Q1x4/JS0CzswG0Ad0AFMubG37a4bGyFBNzz1Xn
n2UPGGDxrhEwSisDbJ6gXl448lkkdrkvhfmrbGmJM41G9VYpVb4jaDpf1SiY8/h5
KefjUSX7bfsDSixs6Be7G5clUufCSOCXCAL/cOkAj9Ww/KpSjZmOqljKITeEi9Jv
xnCJn+c6qFsKGx2nwnF4NoHhqYw0nvKTPrJOQmu3CZpaX69H/37foIpawcS1hNta
uzGJh8iUyS8IxMpYAg2pQ/dtqNbf2gK9gfe1mlPgYR64ix5XjkVukjQ0HuHUQX27
PFjOZfoRUvELIbk0wcwrObk9pylhGTYzdPWNAZj/FIK1gGYEGQ3nqyMZoLeCyssa
umqoGvHPrLi9kwsdS5bHLqbOxN5N8RsrzNjpxuYBc2G7kdrS2g+wySOE1dPT3Cck
kX+JkmFI7zHIpFh4S+gxoj9RrOL/8jX+9QOTWPU6bUQ7d01NbJXXUGQO0Qr9aWms
/lTMdLRBfDmCyBEiQZ4E6EwbL+VP/7+gcs0YEUG5oiHa9N4KxA3e76H95f83i+OY
ED0WY48/5DlVaMv05qdT
=FKX3
-----END PGP SIGNATURE-----

--------------enig97FCB6AB750103D9194CF12B--


--===============5205586490444852222==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5205586490444852222==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 09:20:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:20: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 1U9uDt-0000nE-Gq; Mon, 25 Feb 2013 09:19: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 1U9uDs-0000n9-7T
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:19:48 +0000
Received: from [85.158.138.51:61436] by server-14.bemta-3.messagelabs.com id
	02/6C-23533-3BC2B215; Mon, 25 Feb 2013 09:19:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361783986!20132130!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31735 invoked from network); 25 Feb 2013 09:19:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:19:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1829775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 09:19: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.297.1;
	Mon, 25 Feb 2013 09:19:45 +0000
Message-ID: <1361783984.26546.160.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 25 Feb 2013 09:19:44 +0000
In-Reply-To: <CD4E9E36.4C83D%keir.xen@gmail.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [xen-unstable test] 16231: 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 Sat, 2013-02-23 at 16:26 +0000, Keir Fraser wrote:
> On 23/02/2013 16:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
> > xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):
> >> flight 16231 xen-unstable real [real]
> >> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/
> >> 
> >> Regressions :-(
> >> 
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  build-i386                    4 xen-build             fail REGR. vs. 16226
> > 
> > gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
> > -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c
> > ./checker > tmp.size
> > diff -u reference.size tmp.size
> > --- reference.size 2013-02-22 22:53:31.000000000 +0000
> > +++ tmp.size 2013-02-22 23:12:05.000000000 +0000
> > @@ -5,7 +5,7 @@
> >  trap_info                 |       -       -       8      16
> >  cpu_user_regs             |       -       -      68     200
> >  vcpu_guest_core_regs      |     304     304       -       -
> > -vcpu_guest_context        |     336     336    2800    5168
> > +vcpu_guest_context        |     332     332    2800    5168
> >  arch_vcpu_info            |       -       -      24      16
> >  vcpu_time_info            |       -       -      32      32
> >  vcpu_info                 |       -       -      64      64
> > make[4]: *** [check-headers] Error 1
> > make[4]: Leaving directory
> > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'
> > make[3]: Leaving directory
> > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'
> > make[3]: *** [xen-foreign] Error 2
> > 
> > Are we supposed to still be doing this for i386 ?
> 
> Yes we are, as we still support our i386 guest ABI.
> 
> However, the problem in this case appears to be that the ARM structure size
> has changed. If so, that needs to be fixed, or reference.size needs to be
> updated.

The problem is the use of '#pragma pack(4)' when building the foreign
headers on x86_32.

I think it is useful to keep checking all arches on every build, rather
than splitting into x86 and arm checks, since that will help catch
inadvertent cross-arch breakage.

8<-------------------


>From a20962085ef8d4c3d55f830647cdcb496bc5ee4a Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 25 Feb 2013 09:11:04 +0000
Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm

When building the foreign headers on x86_32 we use '#pragma pack(4)' and
therefore need to explicitly align types which should be aligned to 8-byte
boundaries.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-foreign/mkheader.py |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 8a784d3..5bd6eec 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -20,15 +20,18 @@ footer = {};
 inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define FIXME
 #endif
 """;
 footer["arm32"] = """
@@ -38,15 +41,18 @@ footer["arm32"] = """
 inttypes["arm64"] = {
     "unsigned long" : "__danger_unsigned_long_on_arm64",
     "long"          : "__danger_long_on_arm64",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define FIXME
 #endif
 """;
 footer["arm64"] = """
-- 
1.7.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 Feb 25 09:20:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:20: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 1U9uDt-0000nE-Gq; Mon, 25 Feb 2013 09:19: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 1U9uDs-0000n9-7T
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:19:48 +0000
Received: from [85.158.138.51:61436] by server-14.bemta-3.messagelabs.com id
	02/6C-23533-3BC2B215; Mon, 25 Feb 2013 09:19:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361783986!20132130!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31735 invoked from network); 25 Feb 2013 09:19:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:19:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1829775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 09:19: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.297.1;
	Mon, 25 Feb 2013 09:19:45 +0000
Message-ID: <1361783984.26546.160.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 25 Feb 2013 09:19:44 +0000
In-Reply-To: <CD4E9E36.4C83D%keir.xen@gmail.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [xen-unstable test] 16231: 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 Sat, 2013-02-23 at 16:26 +0000, Keir Fraser wrote:
> On 23/02/2013 16:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
> > xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):
> >> flight 16231 xen-unstable real [real]
> >> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/
> >> 
> >> Regressions :-(
> >> 
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  build-i386                    4 xen-build             fail REGR. vs. 16226
> > 
> > gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
> > -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c
> > ./checker > tmp.size
> > diff -u reference.size tmp.size
> > --- reference.size 2013-02-22 22:53:31.000000000 +0000
> > +++ tmp.size 2013-02-22 23:12:05.000000000 +0000
> > @@ -5,7 +5,7 @@
> >  trap_info                 |       -       -       8      16
> >  cpu_user_regs             |       -       -      68     200
> >  vcpu_guest_core_regs      |     304     304       -       -
> > -vcpu_guest_context        |     336     336    2800    5168
> > +vcpu_guest_context        |     332     332    2800    5168
> >  arch_vcpu_info            |       -       -      24      16
> >  vcpu_time_info            |       -       -      32      32
> >  vcpu_info                 |       -       -      64      64
> > make[4]: *** [check-headers] Error 1
> > make[4]: Leaving directory
> > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'
> > make[3]: Leaving directory
> > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'
> > make[3]: *** [xen-foreign] Error 2
> > 
> > Are we supposed to still be doing this for i386 ?
> 
> Yes we are, as we still support our i386 guest ABI.
> 
> However, the problem in this case appears to be that the ARM structure size
> has changed. If so, that needs to be fixed, or reference.size needs to be
> updated.

The problem is the use of '#pragma pack(4)' when building the foreign
headers on x86_32.

I think it is useful to keep checking all arches on every build, rather
than splitting into x86 and arm checks, since that will help catch
inadvertent cross-arch breakage.

8<-------------------


>From a20962085ef8d4c3d55f830647cdcb496bc5ee4a Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 25 Feb 2013 09:11:04 +0000
Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm

When building the foreign headers on x86_32 we use '#pragma pack(4)' and
therefore need to explicitly align types which should be aligned to 8-byte
boundaries.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-foreign/mkheader.py |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 8a784d3..5bd6eec 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -20,15 +20,18 @@ footer = {};
 inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define FIXME
 #endif
 """;
 footer["arm32"] = """
@@ -38,15 +41,18 @@ footer["arm32"] = """
 inttypes["arm64"] = {
     "unsigned long" : "__danger_unsigned_long_on_arm64",
     "long"          : "__danger_long_on_arm64",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define FIXME
 #endif
 """;
 footer["arm64"] = """
-- 
1.7.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 Feb 25 09:25:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:25: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 1U9uJJ-0001BS-SL; Mon, 25 Feb 2013 09:25: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 1U9uJI-0001BF-V8
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:25:25 +0000
Received: from [85.158.139.211:26925] by server-4.bemta-5.messagelabs.com id
	89/E3-01980-40E2B215; Mon, 25 Feb 2013 09:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361784323!19011202!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 344 invoked from network); 25 Feb 2013 09:25:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1829961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 09:25: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.297.1;
	Mon, 25 Feb 2013 09:25:22 +0000
Message-ID: <1361784321.26546.162.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 25 Feb 2013 09:25:21 +0000
In-Reply-To: <alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<20130223191104.GA12606@konrad-lan.dumpdata.com>
	<alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kees Cook <keescook@chromium.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Greg
	Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dongsheng Song <dongsheng.song@gmail.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
 CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-23 at 20:47 +0000, Stefano Stabellini wrote:
> On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > <dongsheng.song@gmail.com> wrote:
> > > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > > >>
> > > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > > >> while now and is almost always enabled by default. As agreed during the
> > > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > > >>
> > > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > >> ---
> > > >>  arch/x86/xen/Kconfig |    2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > >> index 93ff4e1..8cada4c 100644
> > > >> --- a/arch/x86/xen/Kconfig
> > > >> +++ b/arch/x86/xen/Kconfig
> > > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > >>
> > > >>  config XEN_X86_PVH
> > > >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > >
> > > > Why not remove this 'EXPERIMENTAL' too ?
> > > 
> > > It was unclear to me if the feature was actually considered unstable.
> > > I can resend with the text removed from the title too, if that's the
> > > correct action here?
> > 
> > It certainly is unstable right now (which is why it was unstaged from
> > the v3.9 train). I hope that by v3.10 it won't be - at which
> > point this patch (and the EXPERIMENTAL) makes sense.
> > 
> > So could you respin it please with the text removed as well - and I will
> > queue it up in the branch that carries the PVH feature?
> 
> We also have the same flag on Xen ARM, and the reason is that the ABI is
> not stable yet. As soon as it is (I think soon now), I'll send a patch
> to remove EXPERIMENTAL from there too.

In the meantime if the depends EXPERIMENTAL is going away perhaps we
should explain the EXPERIMENTAL in the title:

8<----------------------------------------------------

>From bc22bd0f7b20296c449a05d82be950922042bc92 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 4 Oct 2012 09:12:51 +0100
Subject: [PATCH] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/Kconfig |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..ef14873 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1865,6 +1865,14 @@ config XEN
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
+
+	  This option is EXPERIMENTAL because the hypervisor
+	  interfaces which it uses are not yet considered stable
+	  therefore backwards and forwards compatibility is not yet
+	  guaranteed.
+
+	  If unsure, say N.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.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 Feb 25 09:25:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:25: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 1U9uJJ-0001BS-SL; Mon, 25 Feb 2013 09:25: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 1U9uJI-0001BF-V8
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:25:25 +0000
Received: from [85.158.139.211:26925] by server-4.bemta-5.messagelabs.com id
	89/E3-01980-40E2B215; Mon, 25 Feb 2013 09:25:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361784323!19011202!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 344 invoked from network); 25 Feb 2013 09:25:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1829961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 09:25: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.297.1;
	Mon, 25 Feb 2013 09:25:22 +0000
Message-ID: <1361784321.26546.162.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 25 Feb 2013 09:25:21 +0000
In-Reply-To: <alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<20130223191104.GA12606@konrad-lan.dumpdata.com>
	<alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kees Cook <keescook@chromium.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Greg
	Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dongsheng Song <dongsheng.song@gmail.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
 CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-23 at 20:47 +0000, Stefano Stabellini wrote:
> On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > <dongsheng.song@gmail.com> wrote:
> > > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > > >>
> > > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > > >> while now and is almost always enabled by default. As agreed during the
> > > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > > >>
> > > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > >> ---
> > > >>  arch/x86/xen/Kconfig |    2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > >> index 93ff4e1..8cada4c 100644
> > > >> --- a/arch/x86/xen/Kconfig
> > > >> +++ b/arch/x86/xen/Kconfig
> > > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > >>
> > > >>  config XEN_X86_PVH
> > > >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > >
> > > > Why not remove this 'EXPERIMENTAL' too ?
> > > 
> > > It was unclear to me if the feature was actually considered unstable.
> > > I can resend with the text removed from the title too, if that's the
> > > correct action here?
> > 
> > It certainly is unstable right now (which is why it was unstaged from
> > the v3.9 train). I hope that by v3.10 it won't be - at which
> > point this patch (and the EXPERIMENTAL) makes sense.
> > 
> > So could you respin it please with the text removed as well - and I will
> > queue it up in the branch that carries the PVH feature?
> 
> We also have the same flag on Xen ARM, and the reason is that the ABI is
> not stable yet. As soon as it is (I think soon now), I'll send a patch
> to remove EXPERIMENTAL from there too.

In the meantime if the depends EXPERIMENTAL is going away perhaps we
should explain the EXPERIMENTAL in the title:

8<----------------------------------------------------

>From bc22bd0f7b20296c449a05d82be950922042bc92 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 4 Oct 2012 09:12:51 +0100
Subject: [PATCH] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/Kconfig |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..ef14873 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1865,6 +1865,14 @@ config XEN
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
+
+	  This option is EXPERIMENTAL because the hypervisor
+	  interfaces which it uses are not yet considered stable
+	  therefore backwards and forwards compatibility is not yet
+	  guaranteed.
+
+	  If unsure, say N.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.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 Feb 25 09:29:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:29: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 1U9uN5-0001Os-Hw; Mon, 25 Feb 2013 09:29:19 +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 1U9uN4-0001Ol-5Z
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:29:18 +0000
Received: from [85.158.137.99:59465] by server-8.bemta-3.messagelabs.com id
	1B/97-25687-CEE2B215; Mon, 25 Feb 2013 09:29:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361784555!17918232!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14354 invoked from network); 25 Feb 2013 09:29:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 09:29:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 09:29:14 +0000
Message-Id: <512B3CF702000078000C0AC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 09:29:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <dario.faggioli@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
In-Reply-To: <1361554003.16232.33.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>> --- a/xen/common/sched_credit.c
>> +++ b/xen/common/sched_credit.c
>>
>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>  {
>>      s_time_t delta;
>> +    uint64_t val;
>>      unsigned int credits;
>>  
>>      /* Assert svc is current */
>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>      if ( (delta = now - svc->start_time) <= 0 )
>>          return;
>>  
>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>> +    svc->residual = do_div(val, MILLISECS(1));
>> +    credits = val;
>> +    ASSERT(credits == val);
> 
> I may be missing something, but how can the assert ever be false, given
> the assignment right before it?

val being wider than credit, this checks that there was no truncation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:29:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:29: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 1U9uN5-0001Os-Hw; Mon, 25 Feb 2013 09:29:19 +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 1U9uN4-0001Ol-5Z
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:29:18 +0000
Received: from [85.158.137.99:59465] by server-8.bemta-3.messagelabs.com id
	1B/97-25687-CEE2B215; Mon, 25 Feb 2013 09:29:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361784555!17918232!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14354 invoked from network); 25 Feb 2013 09:29:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 09:29:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 09:29:14 +0000
Message-Id: <512B3CF702000078000C0AC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 09:29:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <dario.faggioli@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
In-Reply-To: <1361554003.16232.33.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>> --- a/xen/common/sched_credit.c
>> +++ b/xen/common/sched_credit.c
>>
>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>  {
>>      s_time_t delta;
>> +    uint64_t val;
>>      unsigned int credits;
>>  
>>      /* Assert svc is current */
>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>      if ( (delta = now - svc->start_time) <= 0 )
>>          return;
>>  
>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>> +    svc->residual = do_div(val, MILLISECS(1));
>> +    credits = val;
>> +    ASSERT(credits == val);
> 
> I may be missing something, but how can the assert ever be false, given
> the assignment right before it?

val being wider than credit, this checks that there was no truncation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:34:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09: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 1U9uSK-00024G-1v; Mon, 25 Feb 2013 09:34: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 1U9uSI-00023s-Ty
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:34:43 +0000
Received: from [85.158.137.99:58117] by server-14.bemta-3.messagelabs.com id
	AA/CD-23533-1303B215; Mon, 25 Feb 2013 09:34:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361784880!17919797!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27082 invoked from network); 25 Feb 2013 09:34:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 09:34:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 09:34:40 +0000
Message-Id: <512B3E3C02000078000C0AE0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 09:34:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
	<5127882D02000078000C068D@nat28.tlf.novell.com>
	<20130222200746.GA26772@aepfle.de>
In-Reply-To: <20130222200746.GA26772@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 22.02.13 at 21:07, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 22, Jan Beulich wrote:
> 
>> >>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
>> > It did not happen with xl.
>> 
>> But the same guest and Dom0 kernel, and the same hypervisor?
> 
> Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.
> 
>> > Here is the output while doing xm migrate:
>> > 
>> > (XEN) HVM2 restore: VMCE_VCPU 0
>> > (XEN) HVM2 restore: VMCE_VCPU 1
>> > (XEN) HVM2 restore: TSC_ADJUST 0
>> > (XEN) HVM2 restore: TSC_ADJUST 1
>> > (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
>> 
>> Didn't even notice yesterday that this is apparently after restore
>> has already started. Which makes me curious whether the domain
>> that is being referenced with rd= is the old or the new one (would
>> require printing the domain ID; honestly I never understood what
>> use printing of the domain pointer is).
>> 
>> I'm also confused by the domain pointer always being the same;
>> I would expect it to at least toggle between two values, but
>> probably even be different between every instance of the guest.
>> But you're not having a stubdom configured for the guest either,
>> according to the config you sent earlier...
> 
> The rd->domain_id is DOMID_COW in both cases.

Which suggests that memory sharing is in use. At least I'm unaware
of other uses of that pseudo domain.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:34:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09: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 1U9uSK-00024G-1v; Mon, 25 Feb 2013 09:34: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 1U9uSI-00023s-Ty
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:34:43 +0000
Received: from [85.158.137.99:58117] by server-14.bemta-3.messagelabs.com id
	AA/CD-23533-1303B215; Mon, 25 Feb 2013 09:34:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361784880!17919797!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27082 invoked from network); 25 Feb 2013 09:34:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 09:34:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 09:34:40 +0000
Message-Id: <512B3E3C02000078000C0AE0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 09:34:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <20130221144841.GB23819@aepfle.de>
	<51265C7B02000078000C0167@nat28.tlf.novell.com>
	<20130221173115.GA13045@aepfle.de>
	<5127882D02000078000C068D@nat28.tlf.novell.com>
	<20130222200746.GA26772@aepfle.de>
In-Reply-To: <20130222200746.GA26772@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 22.02.13 at 21:07, Olaf Hering <olaf@aepfle.de> wrote:
> On Fri, Feb 22, Jan Beulich wrote:
> 
>> >>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
>> > It did not happen with xl.
>> 
>> But the same guest and Dom0 kernel, and the same hypervisor?
> 
> Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.
> 
>> > Here is the output while doing xm migrate:
>> > 
>> > (XEN) HVM2 restore: VMCE_VCPU 0
>> > (XEN) HVM2 restore: VMCE_VCPU 1
>> > (XEN) HVM2 restore: TSC_ADJUST 0
>> > (XEN) HVM2 restore: TSC_ADJUST 1
>> > (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, 
> od=0000000000000000, caf=180000000000000, taf=7400000000000001
>> 
>> Didn't even notice yesterday that this is apparently after restore
>> has already started. Which makes me curious whether the domain
>> that is being referenced with rd= is the old or the new one (would
>> require printing the domain ID; honestly I never understood what
>> use printing of the domain pointer is).
>> 
>> I'm also confused by the domain pointer always being the same;
>> I would expect it to at least toggle between two values, but
>> probably even be different between every instance of the guest.
>> But you're not having a stubdom configured for the guest either,
>> according to the config you sent earlier...
> 
> The rd->domain_id is DOMID_COW in both cases.

Which suggests that memory sharing is in use. At least I'm unaware
of other uses of that pseudo domain.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:34:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09: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 1U9uSE-00023G-L6; Mon, 25 Feb 2013 09:34:38 +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 1U9uSD-00022z-V2
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:34:38 +0000
Received: from [85.158.138.51:17380] by server-6.bemta-3.messagelabs.com id
	95/28-29959-C203B215; Mon, 25 Feb 2013 09:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361784871!28946969!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16426 invoked from network); 25 Feb 2013 09:34:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1830328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 09:34: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.297.1; Mon, 25 Feb 2013 09:34:31 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9uS7-0006JW-6T;
	Mon, 25 Feb 2013 09:34:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9uS7-0004rL-0I;
	Mon, 25 Feb 2013 09:34:31 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16521-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 09:34:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16521: 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 16521 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16521/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:34:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09: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 1U9uSE-00023G-L6; Mon, 25 Feb 2013 09:34:38 +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 1U9uSD-00022z-V2
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 09:34:38 +0000
Received: from [85.158.138.51:17380] by server-6.bemta-3.messagelabs.com id
	95/28-29959-C203B215; Mon, 25 Feb 2013 09:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361784871!28946969!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16426 invoked from network); 25 Feb 2013 09:34:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1830328"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 09:34: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.297.1; Mon, 25 Feb 2013 09:34:31 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9uS7-0006JW-6T;
	Mon, 25 Feb 2013 09:34:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9uS7-0004rL-0I;
	Mon, 25 Feb 2013 09:34:31 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16521-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 09:34:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16521: 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 16521 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16521/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 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-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:38:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09: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 1U9uWH-0002Xd-3O; Mon, 25 Feb 2013 09:38: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 1U9uWE-0002XU-K4
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:38:47 +0000
Received: from [85.158.137.99:40026] by server-10.bemta-3.messagelabs.com id
	D6/14-10609-5213B215; Mon, 25 Feb 2013 09:38:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361785125!15566802!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16035 invoked from network); 25 Feb 2013 09:38:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 09:38:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 09:38:44 +0000
Message-Id: <512B3F3202000078000C0AF3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 09:38:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xiantao Zhang" <xiantao.zhang@intel.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<B6C2EB9186482D47BD0C5A9A4834564403439E80@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <B6C2EB9186482D47BD0C5A9A4834564403439E80@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 25.02.13 at 06:17, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
> I think this fix also covers HVM side, right ?

The HVM case was already taken care of without this change.

>   For PV side,  I recalled 
> there was already a fix in Xend to protect PV guest from accessing the 
> related MMIO range.

There once was such a change, but iirc it got reverted quickly, and
no-one ever cared to restore it in a way that wouldn't break things.

Also, that wouldn't help xl in any way.

> Also for HVM guest, last year you proposed and submitted 
> a patch to Xen-Qemu for blocking guest's accesses to the related MMIO range.   

Not quite - that change was a pre-req to make it possible to also
deny Dom0 access to that range, because qemu was incorrectly
mapping the range in question.

>  Looks like the previous fixes are not needed any more if this fix got 
> check-in, right ?  

They all will still be necessary. This change (or one of the described
alternatives) is only to close the remaining hole for PV guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:38:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09: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 1U9uWH-0002Xd-3O; Mon, 25 Feb 2013 09:38: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 1U9uWE-0002XU-K4
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:38:47 +0000
Received: from [85.158.137.99:40026] by server-10.bemta-3.messagelabs.com id
	D6/14-10609-5213B215; Mon, 25 Feb 2013 09:38:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361785125!15566802!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16035 invoked from network); 25 Feb 2013 09:38:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 09:38:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 09:38:44 +0000
Message-Id: <512B3F3202000078000C0AF3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 09:38:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xiantao Zhang" <xiantao.zhang@intel.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<B6C2EB9186482D47BD0C5A9A4834564403439E80@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <B6C2EB9186482D47BD0C5A9A4834564403439E80@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 25.02.13 at 06:17, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
> I think this fix also covers HVM side, right ?

The HVM case was already taken care of without this change.

>   For PV side,  I recalled 
> there was already a fix in Xend to protect PV guest from accessing the 
> related MMIO range.

There once was such a change, but iirc it got reverted quickly, and
no-one ever cared to restore it in a way that wouldn't break things.

Also, that wouldn't help xl in any way.

> Also for HVM guest, last year you proposed and submitted 
> a patch to Xen-Qemu for blocking guest's accesses to the related MMIO range.   

Not quite - that change was a pre-req to make it possible to also
deny Dom0 access to that range, because qemu was incorrectly
mapping the range in question.

>  Looks like the previous fixes are not needed any more if this fix got 
> check-in, right ?  

They all will still be necessary. This change (or one of the described
alternatives) is only to close the remaining hole for PV guests.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:57:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:57: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 1U9uo7-0003GR-3M; Mon, 25 Feb 2013 09:57:15 +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 1U9uo5-0003G2-Mo; Mon, 25 Feb 2013 09:57:13 +0000
Received: from [85.158.139.211:49977] by server-15.bemta-5.messagelabs.com id
	CF/72-22815-8753B215; Mon, 25 Feb 2013 09:57:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361786230!18217806!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3747 invoked from network); 25 Feb 2013 09:57:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:57:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="9335508"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 09:57:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 04:57:09 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U9uo1-0002u6-1j;
	Mon, 25 Feb 2013 09:57:09 +0000
Message-ID: <1361786229.2109.15.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <xen-api@lists.xen.org>, xen-arm
	<xen-arm@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>
Date: Mon, 25 Feb 2013 09:57:09 +0000
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, wei.liu2@citrix.com
Subject: [Xen-devel] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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

Just a quick reminder that today is Xen documentation day! Join us on
freenode #xendocs to improve Xen documentation!

********************* 
* Xen Document Days * 
********************* 

We have another Xen document day come up next Monday. Xen Document Days
are for people who care about Xen Documentation and want to improve it.
We introduced Documentation Days, because working on documentation in
parallel with like minded-people, is just more fun than working alone!
Everybody who can contribute is welcome to join! 

For a list of items that need work, check out the community maintained
TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course,
you can work on anything you like: the list just provides suggestions. 

How do I participate? 
===================== 

- Join us on IRC: freenode channel #xendocs 
- 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!


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 09:57:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 09:57: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 1U9uo7-0003GR-3M; Mon, 25 Feb 2013 09:57:15 +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 1U9uo5-0003G2-Mo; Mon, 25 Feb 2013 09:57:13 +0000
Received: from [85.158.139.211:49977] by server-15.bemta-5.messagelabs.com id
	CF/72-22815-8753B215; Mon, 25 Feb 2013 09:57:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361786230!18217806!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3747 invoked from network); 25 Feb 2013 09:57:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 09:57:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="9335508"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 09:57:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 04:57:09 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1U9uo1-0002u6-1j;
	Mon, 25 Feb 2013 09:57:09 +0000
Message-ID: <1361786229.2109.15.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <xen-api@lists.xen.org>, xen-arm
	<xen-arm@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>
Date: Mon, 25 Feb 2013 09:57:09 +0000
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, wei.liu2@citrix.com
Subject: [Xen-devel] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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

Just a quick reminder that today is Xen documentation day! Join us on
freenode #xendocs to improve Xen documentation!

********************* 
* Xen Document Days * 
********************* 

We have another Xen document day come up next Monday. Xen Document Days
are for people who care about Xen Documentation and want to improve it.
We introduced Documentation Days, because working on documentation in
parallel with like minded-people, is just more fun than working alone!
Everybody who can contribute is welcome to join! 

For a list of items that need work, check out the community maintained
TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course,
you can work on anything you like: the list just provides suggestions. 

How do I participate? 
===================== 

- Join us on IRC: freenode channel #xendocs 
- 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!


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:13:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10: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 1U9v3m-0004GM-9G; Mon, 25 Feb 2013 10:13:26 +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 1U9v3k-0004GH-NS
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:13:24 +0000
Received: from [85.158.137.99:55858] by server-16.bemta-3.messagelabs.com id
	52/45-02727-F393B215; Mon, 25 Feb 2013 10:13:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361787151!15574780!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23732 invoked from network); 25 Feb 2013 10:12:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 10:12:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 10:10:31 +0000
Message-Id: <512B46A402000078000C0B3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 10:10:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"G.R." <firemeteor@users.sourceforge.net>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
In-Reply-To: <20775.45924.670290.551847@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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 22.02.13 at 19:05, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> G.R. writes ("[Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge 
> for IGD passthrough"):
>> Fix IGD passthrough logic to properly expose PCH ISA bridge (instead
>> of exposing as pci-pci bridge). The i915 driver require this to
>> correctly detect the PCH version and enable version specific code
>> path.
> 
> Applied, thanks.  I fixed up some wrap damage.

Which means that my pointing out of shortcomings in this patch
got completely ignored - we can only hope that this won't bite us
later...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:13:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10: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 1U9v3m-0004GM-9G; Mon, 25 Feb 2013 10:13:26 +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 1U9v3k-0004GH-NS
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:13:24 +0000
Received: from [85.158.137.99:55858] by server-16.bemta-3.messagelabs.com id
	52/45-02727-F393B215; Mon, 25 Feb 2013 10:13:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361787151!15574780!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23732 invoked from network); 25 Feb 2013 10:12:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 10:12:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 10:10:31 +0000
Message-Id: <512B46A402000078000C0B3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 10:10:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"G.R." <firemeteor@users.sourceforge.net>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
In-Reply-To: <20775.45924.670290.551847@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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 22.02.13 at 19:05, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> G.R. writes ("[Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge 
> for IGD passthrough"):
>> Fix IGD passthrough logic to properly expose PCH ISA bridge (instead
>> of exposing as pci-pci bridge). The i915 driver require this to
>> correctly detect the PCH version and enable version specific code
>> path.
> 
> Applied, thanks.  I fixed up some wrap damage.

Which means that my pointing out of shortcomings in this patch
got completely ignored - we can only hope that this won't bite us
later...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:19:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10:19: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 1U9v8y-0004PE-1g; Mon, 25 Feb 2013 10:18:48 +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 1U9v8x-0004P8-3C
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:18:47 +0000
Received: from [85.158.143.99:26778] by server-3.bemta-4.messagelabs.com id
	EC/0B-02186-68A3B215; Mon, 25 Feb 2013 10:18:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361787422!21550424!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21465 invoked from network); 25 Feb 2013 10:17:06 -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 Feb 2013 10:17:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 10:17:00 +0000
Message-Id: <512B482602000078000C0B41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 10:16:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-16308-mainreport@xen.org>
In-Reply-To: <osstest-16308-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 16308: 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

>>> On 24.02.13 at 16:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 16308 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/ 
> 
> Failures :-/ but no regressions.

"tolerable FAIL" but no push?

Jan

> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230
> 
> Tests which did not succeed, but are not blocking:
>  build-armhf                   4 xen-build                    fail   never pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
>  test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
>  test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
>  test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
>  test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
>  test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
>  test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
> 
> version targeted for testing:
>  xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
> baseline version:
>  xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:19:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10:19: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 1U9v8y-0004PE-1g; Mon, 25 Feb 2013 10:18:48 +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 1U9v8x-0004P8-3C
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:18:47 +0000
Received: from [85.158.143.99:26778] by server-3.bemta-4.messagelabs.com id
	EC/0B-02186-68A3B215; Mon, 25 Feb 2013 10:18:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361787422!21550424!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21465 invoked from network); 25 Feb 2013 10:17:06 -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 Feb 2013 10:17:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 10:17:00 +0000
Message-Id: <512B482602000078000C0B41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 10:16:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-16308-mainreport@xen.org>
In-Reply-To: <osstest-16308-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 16308: 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

>>> On 24.02.13 at 16:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 16308 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/ 
> 
> Failures :-/ but no regressions.

"tolerable FAIL" but no push?

Jan

> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230
> 
> Tests which did not succeed, but are not blocking:
>  build-armhf                   4 xen-build                    fail   never pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
>  test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
>  test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
>  test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
>  test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-win-vcpus1 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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
>  test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
>  test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
>  test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
>  test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never pass
>  test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 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-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
> 
> version targeted for testing:
>  xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
> baseline version:
>  xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:23:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10: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 1U9vDN-0004YQ-O0; Mon, 25 Feb 2013 10:23: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 1U9vDM-0004YK-Dt
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:23:20 +0000
Received: from [85.158.143.99:26262] by server-2.bemta-4.messagelabs.com id
	FD/5E-12656-79B3B215; Mon, 25 Feb 2013 10:23:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361787783!21551822!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22895 invoked from network); 25 Feb 2013 10:23:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 10:23:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1832570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 10:23: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.297.1;
	Mon, 25 Feb 2013 10:23:03 +0000
Message-ID: <1361787782.26546.171.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Feb 2013 10:23:02 +0000
In-Reply-To: <512B482602000078000C0B41@nat28.tlf.novell.com>
References: <osstest-16308-mainreport@xen.org>
	<512B482602000078000C0B41@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 test] 16308: 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

On Mon, 2013-02-25 at 10:16 +0000, Jan Beulich wrote:
> >>> On 24.02.13 at 16:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 16308 xen-4.1-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/ 
> > 
> > Failures :-/ but no regressions.
> 
> "tolerable FAIL" but no push?

Towards the end of the mail it said:

> + cd /export/home/osstest/repos/xen-4.1-testing.hg
> + hg push -r 6743c50ca91da63de23ad52f037bf9eadacfb492
> ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
> remote: abort: There is no Mercurial repository here (.hg not found)!
> abort: no suitable response from remote hg!

Oops!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:23:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10: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 1U9vDN-0004YQ-O0; Mon, 25 Feb 2013 10:23: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 1U9vDM-0004YK-Dt
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:23:20 +0000
Received: from [85.158.143.99:26262] by server-2.bemta-4.messagelabs.com id
	FD/5E-12656-79B3B215; Mon, 25 Feb 2013 10:23:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361787783!21551822!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22895 invoked from network); 25 Feb 2013 10:23:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 10:23:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1832570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 10:23: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.297.1;
	Mon, 25 Feb 2013 10:23:03 +0000
Message-ID: <1361787782.26546.171.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Feb 2013 10:23:02 +0000
In-Reply-To: <512B482602000078000C0B41@nat28.tlf.novell.com>
References: <osstest-16308-mainreport@xen.org>
	<512B482602000078000C0B41@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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 test] 16308: 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

On Mon, 2013-02-25 at 10:16 +0000, Jan Beulich wrote:
> >>> On 24.02.13 at 16:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 16308 xen-4.1-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/ 
> > 
> > Failures :-/ but no regressions.
> 
> "tolerable FAIL" but no push?

Towards the end of the mail it said:

> + cd /export/home/osstest/repos/xen-4.1-testing.hg
> + hg push -r 6743c50ca91da63de23ad52f037bf9eadacfb492
> ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
> remote: abort: There is no Mercurial repository here (.hg not found)!
> abort: no suitable response from remote hg!

Oops!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:23:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10:23: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 1U9vDS-0004Ym-3v; Mon, 25 Feb 2013 10:23:26 +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 1U9vDQ-0004Yb-Qp
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:23:24 +0000
Received: from [85.158.139.83:27595] by server-9.bemta-5.messagelabs.com id
	9B/2F-08547-C9B3B215; Mon, 25 Feb 2013 10:23:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361787802!28795930!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2895 invoked from network); 25 Feb 2013 10:23:22 -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 Feb 2013 10:23:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 10:23:22 +0000
Message-Id: <512B49A502000078000C0B4F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 10:23:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-16260-mainreport@xen.org>
In-Reply-To: <osstest-16260-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-4.2-testing test] 16260: 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 24.02.13 at 10:46, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 16260 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16260/ 
> 
> 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. 16228
>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
>  test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
>  test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

This is because I didn't pay attention to the fact that
2ea6abb8e60cf557b20b8a9904deb73433103d9b can do
what it does validly only on x86-64. Working on a fix...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:23:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10:23: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 1U9vDS-0004Ym-3v; Mon, 25 Feb 2013 10:23:26 +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 1U9vDQ-0004Yb-Qp
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:23:24 +0000
Received: from [85.158.139.83:27595] by server-9.bemta-5.messagelabs.com id
	9B/2F-08547-C9B3B215; Mon, 25 Feb 2013 10:23:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361787802!28795930!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2895 invoked from network); 25 Feb 2013 10:23:22 -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 Feb 2013 10:23:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 10:23:22 +0000
Message-Id: <512B49A502000078000C0B4F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 10:23:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-16260-mainreport@xen.org>
In-Reply-To: <osstest-16260-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-4.2-testing test] 16260: 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 24.02.13 at 10:46, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 16260 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16260/ 
> 
> 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. 16228
>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
>  test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
>  test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

This is because I didn't pay attention to the fact that
2ea6abb8e60cf557b20b8a9904deb73433103d9b can do
what it does validly only on x86-64. Working on a fix...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 10:50:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10: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 1U9vdX-0005Pt-Je; Mon, 25 Feb 2013 10:50:23 +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 1U9vdV-0005Po-TG
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:50:22 +0000
Received: from [85.158.143.99:65318] by server-2.bemta-4.messagelabs.com id
	76/E1-12656-CE14B215; Mon, 25 Feb 2013 10:50:20 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361789171!17593835!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDY2MTMgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21919 invoked from network); 25 Feb 2013 10:46:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 10:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; d="asc'?scan'208";a="1833751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 10:46: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.297.1;
	Mon, 25 Feb 2013 10:46:10 +0000
Message-ID: <1361789156.16489.1.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Feb 2013 11:45:56 +0100
In-Reply-To: <512B3CF702000078000C0AC6@nat28.tlf.novell.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7210795123279206784=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7210795123279206784==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-6rTH155Yb8VqVvhupINV"

--=-6rTH155Yb8VqVvhupINV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-02-25 at 09:29 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrot=
e:
> > On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
> >> --- a/xen/common/sched_credit.c
> >> +++ b/xen/common/sched_credit.c
> >>
> >> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
> >>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
> >>  {
> >>      s_time_t delta;
> >> +    uint64_t val;
> >>      unsigned int credits;
> >> =20
> >>      /* Assert svc is current */
> >> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
> >>      if ( (delta =3D now - svc->start_time) <=3D 0 )
> >>          return;
> >> =20
> >> -    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MI=
LLISECS(1);
> >> +    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> >> +    svc->residual =3D do_div(val, MILLISECS(1));
> >> +    credits =3D val;
> >> +    ASSERT(credits =3D=3D val);
> >=20
> > I may be missing something, but how can the assert ever be false, given
> > the assignment right before it?
>=20
> val being wider than credit, this checks that there was no truncation.
>=20
Ok. At least I was right in the "missing something" part. :-) TBH, I
figured it had to be something related to that, but was failing to spot
it... Sorry for the noise and thanks for the explanation!

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-6rTH155Yb8VqVvhupINV
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)

iEYEABECAAYFAlErQOUACgkQk4XaBE3IOsQg1QCgo4VG2s896fL/UKviXxVanCkE
sFQAmgLMs9/kszQxEl5oPSv6Y6auubJp
=dBzC
-----END PGP SIGNATURE-----

--=-6rTH155Yb8VqVvhupINV--


--===============7210795123279206784==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7210795123279206784==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 10:50:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 10: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 1U9vdX-0005Pt-Je; Mon, 25 Feb 2013 10:50:23 +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 1U9vdV-0005Po-TG
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 10:50:22 +0000
Received: from [85.158.143.99:65318] by server-2.bemta-4.messagelabs.com id
	76/E1-12656-CE14B215; Mon, 25 Feb 2013 10:50:20 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361789171!17593835!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n,ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDY2MTMgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21919 invoked from network); 25 Feb 2013 10:46:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 10:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; d="asc'?scan'208";a="1833751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 10:46: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.297.1;
	Mon, 25 Feb 2013 10:46:10 +0000
Message-ID: <1361789156.16489.1.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 25 Feb 2013 11:45:56 +0100
In-Reply-To: <512B3CF702000078000C0AC6@nat28.tlf.novell.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7210795123279206784=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7210795123279206784==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-6rTH155Yb8VqVvhupINV"

--=-6rTH155Yb8VqVvhupINV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-02-25 at 09:29 +0000, Jan Beulich wrote:
> >>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrot=
e:
> > On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
> >> --- a/xen/common/sched_credit.c
> >> +++ b/xen/common/sched_credit.c
> >>
> >> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
> >>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
> >>  {
> >>      s_time_t delta;
> >> +    uint64_t val;
> >>      unsigned int credits;
> >> =20
> >>      /* Assert svc is current */
> >> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
> >>      if ( (delta =3D now - svc->start_time) <=3D 0 )
> >>          return;
> >> =20
> >> -    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MI=
LLISECS(1);
> >> +    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> >> +    svc->residual =3D do_div(val, MILLISECS(1));
> >> +    credits =3D val;
> >> +    ASSERT(credits =3D=3D val);
> >=20
> > I may be missing something, but how can the assert ever be false, given
> > the assignment right before it?
>=20
> val being wider than credit, this checks that there was no truncation.
>=20
Ok. At least I was right in the "missing something" part. :-) TBH, I
figured it had to be something related to that, but was failing to spot
it... Sorry for the noise and thanks for the explanation!

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-6rTH155Yb8VqVvhupINV
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)

iEYEABECAAYFAlErQOUACgkQk4XaBE3IOsQg1QCgo4VG2s896fL/UKviXxVanCkE
sFQAmgLMs9/kszQxEl5oPSv6Y6auubJp
=dBzC
-----END PGP SIGNATURE-----

--=-6rTH155Yb8VqVvhupINV--


--===============7210795123279206784==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7210795123279206784==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 11:03:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9vqG-0005wj-1U; Mon, 25 Feb 2013 11:03: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 1U9vqE-0005we-93
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 11:03:30 +0000
Received: from [85.158.138.51:55077] by server-6.bemta-3.messagelabs.com id
	CC/84-29959-1054B215; Mon, 25 Feb 2013 11:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361790205!10379913!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19690 invoked from network); 25 Feb 2013 11:03:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:03:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1834796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11: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.297.1;
	Mon, 25 Feb 2013 11:03:25 +0000
Message-ID: <1361790202.26546.172.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 25 Feb 2013 11:03:22 +0000
In-Reply-To: <1361783984.26546.160.camel@zakaz.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [xen-unstable test] 16231: 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 Mon, 2013-02-25 at 09:19 +0000, Ian Campbell wrote:
> The problem is the use of '#pragma pack(4)' when building the foreign
> headers on x86_32.

IIRC this is to deal with the fact that on x86_32 8-byte types are
4-byte aligned when they are within a struct. This is not the case on
32-bit ARM. The following skanky test on armv7 returns:
        align of uint32_t 4
        align of uint64_t 8
        align of struct foo.t32 4
        align of struct foo.t64 8
Compared with x86_32:
        align of uint32_t 4
        align of uint64_t 8
        align of struct foo.t32 4
        align of struct foo.t64 4
        
Ian

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

struct foo
{
	uint32_t t32;
	uint64_t t64;
};

int main (void)
{
	struct foo f;
	printf("align of uint32_t %d\n", __alignof__(uint32_t));
	printf("align of uint64_t %d\n", __alignof__(uint64_t));
	printf("align of struct foo.t32 %d\n", __alignof__(f.t32));
	printf("align of struct foo.t64 %d\n", __alignof__(f.t64));
	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 Feb 25 11:03:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9vqG-0005wj-1U; Mon, 25 Feb 2013 11:03: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 1U9vqE-0005we-93
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 11:03:30 +0000
Received: from [85.158.138.51:55077] by server-6.bemta-3.messagelabs.com id
	CC/84-29959-1054B215; Mon, 25 Feb 2013 11:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361790205!10379913!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19690 invoked from network); 25 Feb 2013 11:03:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:03:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1834796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11: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.297.1;
	Mon, 25 Feb 2013 11:03:25 +0000
Message-ID: <1361790202.26546.172.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 25 Feb 2013 11:03:22 +0000
In-Reply-To: <1361783984.26546.160.camel@zakaz.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-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] [xen-unstable test] 16231: 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 Mon, 2013-02-25 at 09:19 +0000, Ian Campbell wrote:
> The problem is the use of '#pragma pack(4)' when building the foreign
> headers on x86_32.

IIRC this is to deal with the fact that on x86_32 8-byte types are
4-byte aligned when they are within a struct. This is not the case on
32-bit ARM. The following skanky test on armv7 returns:
        align of uint32_t 4
        align of uint64_t 8
        align of struct foo.t32 4
        align of struct foo.t64 8
Compared with x86_32:
        align of uint32_t 4
        align of uint64_t 8
        align of struct foo.t32 4
        align of struct foo.t64 4
        
Ian

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

struct foo
{
	uint32_t t32;
	uint64_t t64;
};

int main (void)
{
	struct foo f;
	printf("align of uint32_t %d\n", __alignof__(uint32_t));
	printf("align of uint64_t %d\n", __alignof__(uint64_t));
	printf("align of struct foo.t32 %d\n", __alignof__(f.t32));
	printf("align of struct foo.t64 %d\n", __alignof__(f.t64));
	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 Feb 25 11:13:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9vzF-0006Gs-4L; Mon, 25 Feb 2013 11:12:49 +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 1U9vzD-0006Gn-51
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:12:47 +0000
Received: from [193.109.254.147:38126] by server-9.bemta-14.messagelabs.com id
	74/BB-30867-E274B215; Mon, 25 Feb 2013 11:12:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361790762!3972036!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12291 invoked from network); 25 Feb 2013 11:12:44 -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;
	25 Feb 2013 11:12:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="9344629"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 11:12:38 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 06:12:37 -0500
Message-ID: <512B4724.5000603@citrix.com>
Date: Mon, 25 Feb 2013 11:12:36 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
In-Reply-To: <512B3CF702000078000C0AC6@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
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] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 09:29, Jan Beulich wrote:
>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>> --- a/xen/common/sched_credit.c
>>> +++ b/xen/common/sched_credit.c
>>>
>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>  {
>>>      s_time_t delta;
>>> +    uint64_t val;
>>>      unsigned int credits;
>>>  
>>>      /* Assert svc is current */
>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>      if ( (delta = now - svc->start_time) <= 0 )
>>>          return;
>>>  
>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>> +    svc->residual = do_div(val, MILLISECS(1));
>>> +    credits = val;
>>> +    ASSERT(credits == val);
>>
>> I may be missing something, but how can the assert ever be false, given
>> the assignment right before it?
> 
> val being wider than credit, this checks that there was no truncation.

ASSERT(val <= UINT_MAX);

Would be clearer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:13:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9vzF-0006Gs-4L; Mon, 25 Feb 2013 11:12:49 +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 1U9vzD-0006Gn-51
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:12:47 +0000
Received: from [193.109.254.147:38126] by server-9.bemta-14.messagelabs.com id
	74/BB-30867-E274B215; Mon, 25 Feb 2013 11:12:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361790762!3972036!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12291 invoked from network); 25 Feb 2013 11:12:44 -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;
	25 Feb 2013 11:12:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="9344629"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 11:12:38 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 06:12:37 -0500
Message-ID: <512B4724.5000603@citrix.com>
Date: Mon, 25 Feb 2013 11:12:36 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
In-Reply-To: <512B3CF702000078000C0AC6@nat28.tlf.novell.com>
X-Originating-IP: [10.80.2.76]
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] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 09:29, Jan Beulich wrote:
>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>> --- a/xen/common/sched_credit.c
>>> +++ b/xen/common/sched_credit.c
>>>
>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>  {
>>>      s_time_t delta;
>>> +    uint64_t val;
>>>      unsigned int credits;
>>>  
>>>      /* Assert svc is current */
>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>      if ( (delta = now - svc->start_time) <= 0 )
>>>          return;
>>>  
>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>> +    svc->residual = do_div(val, MILLISECS(1));
>>> +    credits = val;
>>> +    ASSERT(credits == val);
>>
>> I may be missing something, but how can the assert ever be false, given
>> the assignment right before it?
> 
> val being wider than credit, this checks that there was no truncation.

ASSERT(val <= UINT_MAX);

Would be clearer.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:16:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11:16: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 1U9w2H-0006P0-VX; Mon, 25 Feb 2013 11:15:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U9w2G-0006Or-ON
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 11:15:56 +0000
Received: from [85.158.138.51:59524] by server-10.bemta-3.messagelabs.com id
	02/21-10609-BE74B215; Mon, 25 Feb 2013 11:15:55 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361790954!27302215!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17960 invoked from network); 25 Feb 2013 11:15:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:15:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1835740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:15:55 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 25 Feb 2013
	11:15:54 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 25 Feb 2013 11:15:52 +0000
Thread-Topic: [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of
	blktap3 files
Thread-Index: Ac36LT+yhLmLzV4IROil8b4+j4sbIQZHDCAg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153DAC5A5CA@LONPMAILBOX01.citrite.net>
References: <patchbomb.1359030040@makatos-desktop>
In-Reply-To: <patchbomb.1359030040@makatos-desktop>
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 0 of 9 RFC v3] blktap3: Introduce a small
 subset of blktap3 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

Ping?

> -----Original Message-----
> From: Thanos Makatos [mailto:thanos.makatos@citrix.com]
> Sent: 24 January 2013 12:21
> To: xen-devel@lists.xensource.com
> Cc: Thanos Makatos
> Subject: [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of
> blktap3 files
> 
> blktap3 is a disk back-end driver. It is based on blktap2 but does not
> require
> the blktap/blkback kernel modules as it allows tapdisk to talk directly
> to
> blkfront. This primarily simplifies maintenance, and _may_ lead to
> performance
> improvements. blktap3 is based on a blktap2 fork maintained mostly by
> Citrix
> (it lives in github), so these changes are also imported, apart from
> the
> blktap3 ones.
> 
> I've organised my upstream effort as follows:
> 1. Upstream the smallest possible subset of blktap3 that will allow
> guest VMs
>    to use RAW images backed by blktap3. This will enable early testing
> on the
>    bits introduced by blktap3.
> 2. Upstream the remaining of blktap3, most notably back-end drivers,
> e.g. VHD
>    etc.
> 3. Import bug fixes from blktap2 living in github.
> 4. Import new features and optimisations from blktap2 living in github,
> e.g.
>    the mirroring plug-in.
> blktap3 is broken into patches that can be found here:
> https://bitbucket.org/tmakatos/blktap3-patches
> 
> blktap3 is made of the following components:
> 1. blkfront (not a blktap3 component and already upstream): a virtual
>    block device driver in the guest VM that receives block I/O requests
> and
>    forwards them to tapdisk via the shared ring.
> 2. tapdisk: a user space process that receives block I/O requests from
>    blkfront, translates them to whatever the current backing file
> format is
>    (i.e. RAW, VHD, qcow etc.), and performs the actual I/O. Apart from
> block
>    I/O requests, the tapdisk also allows basic management of each
> virtual
>    block device, e.g. a device may be temporarily paused. tapdisk
> listens to
>    a loopback socket for such commands. The tap-ctl utility (explained
> later)
>    can be used for managing the tapdisk.
> 3. libsring (formerly known as libxenio): a user space library that
> implements
>    the functionality required to access the shared ring. It is used by
> tapdisk
>    to obtain the block I/O requests forwarded by the front-end, and to
> produce
>    the corresponding responses.  This is the very "heart" of blktap3,
> it's
>    architecture will be thoroughly explained by the patch series that
>    introduces it.
> 4. tapback (formerly known as xenio): a user space daemon that acts as
> the
>    back-end of each virtual block device: it monitors XenStore for the
> block
>    front-end's state changes, creates/destroys the shared ring, and
> instructs
>    the tapdisk to connect to/disconnect from the shared ring. It also
>    communicates to the block front-end required parameters (e.g. block
> device
>    size in sectors) via XenStore. The tapback daemon is only involved
> during
>    the set up/tear down of the connection between the two ends, it does
> not
>    participate in the data path. There is one tapback daemon per back-
> end
>    driver domain, though we could have a tapback daemon per guest VM or
> per
>    VBD. In this prototype, the tapdisk is spawned/destroyed by libxl
> when a
>    domain is created/destroyed, in the exact same way as in blktap2
> (libxl
>    uses libblktapctl for this). When tapback detects a device creation
> request
>    from a front-end, it must locate the tapdisk (previously created by
> libxl)
>    designated to serve this VBD. There is no particular reason for this
> design,
>    we could as well have the tapback daemon spawning the tapdisk (the
> latter
>    choice looks neater IMO). Opting for the latter design wouldn't
> affect this
>    patch series that much.
> 5. libblktapctl: a user space library where the tapdisk management
> functions
>    are implemented, used by libxl and tap-ctl.
> 6. tap-ctl: a user space utility that allows management of the tapdisk,
> uses
>    libblktapctl.
> 
> This patch series introduces a small subset of files required by
> tapback (the
> tapback daemon is introduced by the next patch series):
> - basic blktap3 header files
> - a rudimentary implementation of libblktapctl. Only the bits required
> by
>   tapback to manage the tapdisk are introduced, the rest of this
> library will
>   be introduced by later patches.
> 
> ---
> Changed since v1:
> * In all patches the patch message has been improved.
> * Patches 1, 5, and 6 use GPLv2.
> * Patch 0: Basic explanation of blktap3's fundamental components.
> * Patch 9: Improved tools/blktap3/control/Makefile by moving hard coded
>   paths to config/StdGNU.mk.
> 
> Changed since v2:
> - Updated tapback daemon description.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:16:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11:16: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 1U9w2H-0006P0-VX; Mon, 25 Feb 2013 11:15:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1U9w2G-0006Or-ON
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 11:15:56 +0000
Received: from [85.158.138.51:59524] by server-10.bemta-3.messagelabs.com id
	02/21-10609-BE74B215; Mon, 25 Feb 2013 11:15:55 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1361790954!27302215!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17960 invoked from network); 25 Feb 2013 11:15:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:15:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1835740"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:15:55 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 25 Feb 2013
	11:15:54 +0000
From: Thanos Makatos <thanos.makatos@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 25 Feb 2013 11:15:52 +0000
Thread-Topic: [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of
	blktap3 files
Thread-Index: Ac36LT+yhLmLzV4IROil8b4+j4sbIQZHDCAg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE0153DAC5A5CA@LONPMAILBOX01.citrite.net>
References: <patchbomb.1359030040@makatos-desktop>
In-Reply-To: <patchbomb.1359030040@makatos-desktop>
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 0 of 9 RFC v3] blktap3: Introduce a small
 subset of blktap3 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

Ping?

> -----Original Message-----
> From: Thanos Makatos [mailto:thanos.makatos@citrix.com]
> Sent: 24 January 2013 12:21
> To: xen-devel@lists.xensource.com
> Cc: Thanos Makatos
> Subject: [PATCH 0 of 9 RFC v3] blktap3: Introduce a small subset of
> blktap3 files
> 
> blktap3 is a disk back-end driver. It is based on blktap2 but does not
> require
> the blktap/blkback kernel modules as it allows tapdisk to talk directly
> to
> blkfront. This primarily simplifies maintenance, and _may_ lead to
> performance
> improvements. blktap3 is based on a blktap2 fork maintained mostly by
> Citrix
> (it lives in github), so these changes are also imported, apart from
> the
> blktap3 ones.
> 
> I've organised my upstream effort as follows:
> 1. Upstream the smallest possible subset of blktap3 that will allow
> guest VMs
>    to use RAW images backed by blktap3. This will enable early testing
> on the
>    bits introduced by blktap3.
> 2. Upstream the remaining of blktap3, most notably back-end drivers,
> e.g. VHD
>    etc.
> 3. Import bug fixes from blktap2 living in github.
> 4. Import new features and optimisations from blktap2 living in github,
> e.g.
>    the mirroring plug-in.
> blktap3 is broken into patches that can be found here:
> https://bitbucket.org/tmakatos/blktap3-patches
> 
> blktap3 is made of the following components:
> 1. blkfront (not a blktap3 component and already upstream): a virtual
>    block device driver in the guest VM that receives block I/O requests
> and
>    forwards them to tapdisk via the shared ring.
> 2. tapdisk: a user space process that receives block I/O requests from
>    blkfront, translates them to whatever the current backing file
> format is
>    (i.e. RAW, VHD, qcow etc.), and performs the actual I/O. Apart from
> block
>    I/O requests, the tapdisk also allows basic management of each
> virtual
>    block device, e.g. a device may be temporarily paused. tapdisk
> listens to
>    a loopback socket for such commands. The tap-ctl utility (explained
> later)
>    can be used for managing the tapdisk.
> 3. libsring (formerly known as libxenio): a user space library that
> implements
>    the functionality required to access the shared ring. It is used by
> tapdisk
>    to obtain the block I/O requests forwarded by the front-end, and to
> produce
>    the corresponding responses.  This is the very "heart" of blktap3,
> it's
>    architecture will be thoroughly explained by the patch series that
>    introduces it.
> 4. tapback (formerly known as xenio): a user space daemon that acts as
> the
>    back-end of each virtual block device: it monitors XenStore for the
> block
>    front-end's state changes, creates/destroys the shared ring, and
> instructs
>    the tapdisk to connect to/disconnect from the shared ring. It also
>    communicates to the block front-end required parameters (e.g. block
> device
>    size in sectors) via XenStore. The tapback daemon is only involved
> during
>    the set up/tear down of the connection between the two ends, it does
> not
>    participate in the data path. There is one tapback daemon per back-
> end
>    driver domain, though we could have a tapback daemon per guest VM or
> per
>    VBD. In this prototype, the tapdisk is spawned/destroyed by libxl
> when a
>    domain is created/destroyed, in the exact same way as in blktap2
> (libxl
>    uses libblktapctl for this). When tapback detects a device creation
> request
>    from a front-end, it must locate the tapdisk (previously created by
> libxl)
>    designated to serve this VBD. There is no particular reason for this
> design,
>    we could as well have the tapback daemon spawning the tapdisk (the
> latter
>    choice looks neater IMO). Opting for the latter design wouldn't
> affect this
>    patch series that much.
> 5. libblktapctl: a user space library where the tapdisk management
> functions
>    are implemented, used by libxl and tap-ctl.
> 6. tap-ctl: a user space utility that allows management of the tapdisk,
> uses
>    libblktapctl.
> 
> This patch series introduces a small subset of files required by
> tapback (the
> tapback daemon is introduced by the next patch series):
> - basic blktap3 header files
> - a rudimentary implementation of libblktapctl. Only the bits required
> by
>   tapback to manage the tapdisk are introduced, the rest of this
> library will
>   be introduced by later patches.
> 
> ---
> Changed since v1:
> * In all patches the patch message has been improved.
> * Patches 1, 5, and 6 use GPLv2.
> * Patch 0: Basic explanation of blktap3's fundamental components.
> * Patch 9: Improved tools/blktap3/control/Makefile by moving hard coded
>   paths to config/StdGNU.mk.
> 
> Changed since v2:
> - Updated tapback daemon description.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:21:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9w7C-0006bP-PU; Mon, 25 Feb 2013 11:21:02 +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 1U9w7B-0006ac-I9
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:21:01 +0000
Received: from [85.158.139.83:48220] by server-11.bemta-5.messagelabs.com id
	C6/34-27486-C194B215; Mon, 25 Feb 2013 11:21:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361791258!26067697!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12783 invoked from network); 25 Feb 2013 11:20:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 11:20:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 11:20:58 +0000
Message-Id: <512B572702000078000C0BB6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 11:20:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-16260-mainreport@xen.org>
	<512B49A502000078000C0B4F@nat28.tlf.novell.com>
In-Reply-To: <512B49A502000078000C0B4F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5C6C2B07.1__="
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-4.2-testing test] 16260: 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>
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.

--=__Part5C6C2B07.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 25.02.13 at 11:23, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 24.02.13 at 10:46, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 16260 xen-4.2-testing real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16260/=20
>>=20
>> Regressions :-(
>>=20
>> 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. 16228
>>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. =
vs. 16228
>>  test-i386-i386-win            5 xen-boot                  fail REGR. =
vs. 16228
>>  test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. =
vs. 16228
>=20
> This is because I didn't pay attention to the fact that
> 2ea6abb8e60cf557b20b8a9904deb73433103d9b can do
> what it does validly only on x86-64. Working on a fix...

And this is the fix I'm going to commit:

x86_32: fix acpi_dmar_init()

map_pages_to_xen() can't be used here on x86_32, need to use up to 2
newly introduced fixmap entries for this instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -776,6 +776,7 @@ out:
 }
=20
 #ifdef CONFIG_X86
+#include <asm/fixmap.h>
 #include <asm/tboot.h>
 /* ACPI tables may not be DMA protected by tboot, so use DMAR copy */
 /* SINIT saved in SinitMleData in TXT heap (which is DMA protected) */
@@ -792,12 +793,26 @@ int __init acpi_dmar_init(void)
     if ( ACPI_SUCCESS(acpi_get_table_phys(ACPI_SIG_DMAR, 0,
                                           &dmar_addr, &dmar_len)) )
     {
+#ifdef CONFIG_X86_32
+        if ( dmar_addr + dmar_len > (DIRECTMAP_MBYTES << 20) )
+        {
+            unsigned long offset =3D dmar_addr & (PAGE_SIZE - 1);
+            unsigned long mapped_size =3D PAGE_SIZE - offset;
+
+            set_fixmap(FIX_DMAR_ZAP_LO, dmar_addr);
+            if ( mapped_size < sizeof(*dmar_table) )
+                set_fixmap(FIX_DMAR_ZAP_HI, dmar_addr + PAGE_SIZE);
+            dmar_table =3D (void *)fix_to_virt(FIX_DMAR_ZAP_LO) + offset;
+            goto exit;
+        }
+#endif
         map_pages_to_xen((unsigned long)__va(dmar_addr), PFN_DOWN(dmar_add=
r),
                          PFN_UP(dmar_addr + dmar_len) - PFN_DOWN(dmar_addr=
),
                          PAGE_HYPERVISOR);
         dmar_table =3D __va(dmar_addr);
     }
=20
+ exit: __attribute__((__unused__))
     return parse_dmar_table(acpi_parse_dmar);
 }
=20
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -37,6 +37,8 @@ enum fixed_addresses {
     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + NR_CPUS-1,
 #define FIX_VGC_END FIX_PAE_HIGHMEM_0
 #define FIX_VGC_BEGIN FIX_PAE_HIGHMEM_END
+    FIX_DMAR_ZAP_HI,
+    FIX_DMAR_ZAP_LO,
 #else
     FIX_VGC_END,
     FIX_VGC_BEGIN =3D FIX_VGC_END




--=__Part5C6C2B07.1__=
Content-Type: text/plain; name="26443-i386-fix.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="26443-i386-fix.patch"

x86_32: fix acpi_dmar_init()=0A=0Amap_pages_to_xen() can't be used here on =
x86_32, need to use up to 2=0Anewly introduced fixmap entries for this =
instead.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passthrough/vtd/dm=
ar.c=0A@@ -776,6 +776,7 @@ out:=0A }=0A =0A #ifdef CONFIG_X86=0A+#include =
<asm/fixmap.h>=0A #include <asm/tboot.h>=0A /* ACPI tables may not be DMA =
protected by tboot, so use DMAR copy */=0A /* SINIT saved in SinitMleData =
in TXT heap (which is DMA protected) */=0A@@ -792,12 +793,26 @@ int __init =
acpi_dmar_init(void)=0A     if ( ACPI_SUCCESS(acpi_get_table_phys(ACPI_SIG_=
DMAR, 0,=0A                                           &dmar_addr, =
&dmar_len)) )=0A     {=0A+#ifdef CONFIG_X86_32=0A+        if ( dmar_addr + =
dmar_len > (DIRECTMAP_MBYTES << 20) )=0A+        {=0A+            unsigned =
long offset =3D dmar_addr & (PAGE_SIZE - 1);=0A+            unsigned long =
mapped_size =3D PAGE_SIZE - offset;=0A+=0A+            set_fixmap(FIX_DMAR_=
ZAP_LO, dmar_addr);=0A+            if ( mapped_size < sizeof(*dmar_table) =
)=0A+                set_fixmap(FIX_DMAR_ZAP_HI, dmar_addr + PAGE_SIZE);=0A=
+            dmar_table =3D (void *)fix_to_virt(FIX_DMAR_ZAP_LO) + =
offset;=0A+            goto exit;=0A+        }=0A+#endif=0A         =
map_pages_to_xen((unsigned long)__va(dmar_addr), PFN_DOWN(dmar_addr),=0A   =
                       PFN_UP(dmar_addr + dmar_len) - PFN_DOWN(dmar_addr),=
=0A                          PAGE_HYPERVISOR);=0A         dmar_table =3D =
__va(dmar_addr);=0A     }=0A =0A+ exit: __attribute__((__unused__))=0A     =
return parse_dmar_table(acpi_parse_dmar);=0A }=0A =0A--- a/xen/include/asm-=
x86/fixmap.h=0A+++ b/xen/include/asm-x86/fixmap.h=0A@@ -37,6 +37,8 @@ enum =
fixed_addresses {=0A     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + =
NR_CPUS-1,=0A #define FIX_VGC_END FIX_PAE_HIGHMEM_0=0A #define FIX_VGC_BEGI=
N FIX_PAE_HIGHMEM_END=0A+    FIX_DMAR_ZAP_HI,=0A+    FIX_DMAR_ZAP_LO,=0A =
#else=0A     FIX_VGC_END,=0A     FIX_VGC_BEGIN =3D FIX_VGC_END=0A
--=__Part5C6C2B07.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

--=__Part5C6C2B07.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 25 11:21:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9w7C-0006bP-PU; Mon, 25 Feb 2013 11:21:02 +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 1U9w7B-0006ac-I9
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:21:01 +0000
Received: from [85.158.139.83:48220] by server-11.bemta-5.messagelabs.com id
	C6/34-27486-C194B215; Mon, 25 Feb 2013 11:21:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361791258!26067697!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12783 invoked from network); 25 Feb 2013 11:20:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 11:20:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 11:20:58 +0000
Message-Id: <512B572702000078000C0BB6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 11:20:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-16260-mainreport@xen.org>
	<512B49A502000078000C0B4F@nat28.tlf.novell.com>
In-Reply-To: <512B49A502000078000C0B4F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5C6C2B07.1__="
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-4.2-testing test] 16260: 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>
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.

--=__Part5C6C2B07.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 25.02.13 at 11:23, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 24.02.13 at 10:46, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 16260 xen-4.2-testing real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16260/=20
>>=20
>> Regressions :-(
>>=20
>> 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. 16228
>>  test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. =
vs. 16228
>>  test-i386-i386-win            5 xen-boot                  fail REGR. =
vs. 16228
>>  test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. =
vs. 16228
>=20
> This is because I didn't pay attention to the fact that
> 2ea6abb8e60cf557b20b8a9904deb73433103d9b can do
> what it does validly only on x86-64. Working on a fix...

And this is the fix I'm going to commit:

x86_32: fix acpi_dmar_init()

map_pages_to_xen() can't be used here on x86_32, need to use up to 2
newly introduced fixmap entries for this instead.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -776,6 +776,7 @@ out:
 }
=20
 #ifdef CONFIG_X86
+#include <asm/fixmap.h>
 #include <asm/tboot.h>
 /* ACPI tables may not be DMA protected by tboot, so use DMAR copy */
 /* SINIT saved in SinitMleData in TXT heap (which is DMA protected) */
@@ -792,12 +793,26 @@ int __init acpi_dmar_init(void)
     if ( ACPI_SUCCESS(acpi_get_table_phys(ACPI_SIG_DMAR, 0,
                                           &dmar_addr, &dmar_len)) )
     {
+#ifdef CONFIG_X86_32
+        if ( dmar_addr + dmar_len > (DIRECTMAP_MBYTES << 20) )
+        {
+            unsigned long offset =3D dmar_addr & (PAGE_SIZE - 1);
+            unsigned long mapped_size =3D PAGE_SIZE - offset;
+
+            set_fixmap(FIX_DMAR_ZAP_LO, dmar_addr);
+            if ( mapped_size < sizeof(*dmar_table) )
+                set_fixmap(FIX_DMAR_ZAP_HI, dmar_addr + PAGE_SIZE);
+            dmar_table =3D (void *)fix_to_virt(FIX_DMAR_ZAP_LO) + offset;
+            goto exit;
+        }
+#endif
         map_pages_to_xen((unsigned long)__va(dmar_addr), PFN_DOWN(dmar_add=
r),
                          PFN_UP(dmar_addr + dmar_len) - PFN_DOWN(dmar_addr=
),
                          PAGE_HYPERVISOR);
         dmar_table =3D __va(dmar_addr);
     }
=20
+ exit: __attribute__((__unused__))
     return parse_dmar_table(acpi_parse_dmar);
 }
=20
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -37,6 +37,8 @@ enum fixed_addresses {
     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + NR_CPUS-1,
 #define FIX_VGC_END FIX_PAE_HIGHMEM_0
 #define FIX_VGC_BEGIN FIX_PAE_HIGHMEM_END
+    FIX_DMAR_ZAP_HI,
+    FIX_DMAR_ZAP_LO,
 #else
     FIX_VGC_END,
     FIX_VGC_BEGIN =3D FIX_VGC_END




--=__Part5C6C2B07.1__=
Content-Type: text/plain; name="26443-i386-fix.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="26443-i386-fix.patch"

x86_32: fix acpi_dmar_init()=0A=0Amap_pages_to_xen() can't be used here on =
x86_32, need to use up to 2=0Anewly introduced fixmap entries for this =
instead.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passthrough/vtd/dm=
ar.c=0A@@ -776,6 +776,7 @@ out:=0A }=0A =0A #ifdef CONFIG_X86=0A+#include =
<asm/fixmap.h>=0A #include <asm/tboot.h>=0A /* ACPI tables may not be DMA =
protected by tboot, so use DMAR copy */=0A /* SINIT saved in SinitMleData =
in TXT heap (which is DMA protected) */=0A@@ -792,12 +793,26 @@ int __init =
acpi_dmar_init(void)=0A     if ( ACPI_SUCCESS(acpi_get_table_phys(ACPI_SIG_=
DMAR, 0,=0A                                           &dmar_addr, =
&dmar_len)) )=0A     {=0A+#ifdef CONFIG_X86_32=0A+        if ( dmar_addr + =
dmar_len > (DIRECTMAP_MBYTES << 20) )=0A+        {=0A+            unsigned =
long offset =3D dmar_addr & (PAGE_SIZE - 1);=0A+            unsigned long =
mapped_size =3D PAGE_SIZE - offset;=0A+=0A+            set_fixmap(FIX_DMAR_=
ZAP_LO, dmar_addr);=0A+            if ( mapped_size < sizeof(*dmar_table) =
)=0A+                set_fixmap(FIX_DMAR_ZAP_HI, dmar_addr + PAGE_SIZE);=0A=
+            dmar_table =3D (void *)fix_to_virt(FIX_DMAR_ZAP_LO) + =
offset;=0A+            goto exit;=0A+        }=0A+#endif=0A         =
map_pages_to_xen((unsigned long)__va(dmar_addr), PFN_DOWN(dmar_addr),=0A   =
                       PFN_UP(dmar_addr + dmar_len) - PFN_DOWN(dmar_addr),=
=0A                          PAGE_HYPERVISOR);=0A         dmar_table =3D =
__va(dmar_addr);=0A     }=0A =0A+ exit: __attribute__((__unused__))=0A     =
return parse_dmar_table(acpi_parse_dmar);=0A }=0A =0A--- a/xen/include/asm-=
x86/fixmap.h=0A+++ b/xen/include/asm-x86/fixmap.h=0A@@ -37,6 +37,8 @@ enum =
fixed_addresses {=0A     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + =
NR_CPUS-1,=0A #define FIX_VGC_END FIX_PAE_HIGHMEM_0=0A #define FIX_VGC_BEGI=
N FIX_PAE_HIGHMEM_END=0A+    FIX_DMAR_ZAP_HI,=0A+    FIX_DMAR_ZAP_LO,=0A =
#else=0A     FIX_VGC_END,=0A     FIX_VGC_BEGIN =3D FIX_VGC_END=0A
--=__Part5C6C2B07.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

--=__Part5C6C2B07.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 25 11:26:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wCe-0006sy-KW; Mon, 25 Feb 2013 11:26:40 +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 1U9wCc-0006st-QG
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:26:38 +0000
Received: from [85.158.137.99:47683] by server-16.bemta-3.messagelabs.com id
	EA/A3-02727-E6A4B215; Mon, 25 Feb 2013 11:26:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361791488!12294799!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6047 invoked from network); 25 Feb 2013 11:24:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:24:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1836119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:24: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.297.1; Mon, 25 Feb 2013 11:24:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9wAp-0006zP-Ie; Mon, 25 Feb 2013 11:24:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9wAp-0008Vc-Ec;
	Mon, 25 Feb 2013 11:24:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.18943.354989.936020@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:24:47 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B482602000078000C0B41@nat28.tlf.novell.com>
References: <osstest-16308-mainreport@xen.org>
	<512B482602000078000C0B41@nat28.tlf.novell.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.1-testing test] 16308: 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

Jan Beulich writes ("Re: [Xen-devel] [xen-4.1-testing test] 16308: tolerable FAIL"):
> >>> On 24.02.13 at 16:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 16308 xen-4.1-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/ 
> > 
> > Failures :-/ but no regressions.
> 
> "tolerable FAIL" but no push?

I expect this is related to the switch to git.  I will investigate.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:26:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wCe-0006sy-KW; Mon, 25 Feb 2013 11:26:40 +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 1U9wCc-0006st-QG
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:26:38 +0000
Received: from [85.158.137.99:47683] by server-16.bemta-3.messagelabs.com id
	EA/A3-02727-E6A4B215; Mon, 25 Feb 2013 11:26:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361791488!12294799!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6047 invoked from network); 25 Feb 2013 11:24:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:24:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1836119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:24: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.297.1; Mon, 25 Feb 2013 11:24:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9wAp-0006zP-Ie; Mon, 25 Feb 2013 11:24:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9wAp-0008Vc-Ec;
	Mon, 25 Feb 2013 11:24:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.18943.354989.936020@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:24:47 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B482602000078000C0B41@nat28.tlf.novell.com>
References: <osstest-16308-mainreport@xen.org>
	<512B482602000078000C0B41@nat28.tlf.novell.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.1-testing test] 16308: 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

Jan Beulich writes ("Re: [Xen-devel] [xen-4.1-testing test] 16308: tolerable FAIL"):
> >>> On 24.02.13 at 16:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 16308 xen-4.1-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/16308/ 
> > 
> > Failures :-/ but no regressions.
> 
> "tolerable FAIL" but no push?

I expect this is related to the switch to git.  I will investigate.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:27:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wCt-0006tj-3u; Mon, 25 Feb 2013 11:26: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 1U9wCs-0006tX-2v
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:26:54 +0000
Received: from [85.158.143.99:50252] by server-1.bemta-4.messagelabs.com id
	80/BF-06203-C7A4B215; Mon, 25 Feb 2013 11:26:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361791465!29090669!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24666 invoked from network); 25 Feb 2013 11:24:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:24:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1836106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11: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.297.1; Mon, 25 Feb 2013 11:24:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9wAT-0006zE-J8; Mon, 25 Feb 2013 11:24:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9wAT-0008VY-9l;
	Mon, 25 Feb 2013 11:24:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.18914.422564.346844@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:24:18 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B46A402000078000C0B3B@nat28.tlf.novell.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough"):
> > Applied, thanks.  I fixed up some wrap damage.
> 
> Which means that my pointing out of shortcomings in this patch
> got completely ignored - we can only hope that this won't bite us
> later...

Sorry about that, perhaps I didn't spot the thread.  Do you think it
should be reverted ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:27:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wCt-0006tj-3u; Mon, 25 Feb 2013 11:26: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 1U9wCs-0006tX-2v
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:26:54 +0000
Received: from [85.158.143.99:50252] by server-1.bemta-4.messagelabs.com id
	80/BF-06203-C7A4B215; Mon, 25 Feb 2013 11:26:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361791465!29090669!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24666 invoked from network); 25 Feb 2013 11:24:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:24:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1836106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11: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.297.1; Mon, 25 Feb 2013 11:24:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9wAT-0006zE-J8; Mon, 25 Feb 2013 11:24:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9wAT-0008VY-9l;
	Mon, 25 Feb 2013 11:24:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.18914.422564.346844@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:24:18 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B46A402000078000C0B3B@nat28.tlf.novell.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough"):
> > Applied, thanks.  I fixed up some wrap damage.
> 
> Which means that my pointing out of shortcomings in this patch
> got completely ignored - we can only hope that this won't bite us
> later...

Sorry about that, perhaps I didn't spot the thread.  Do you think it
should be reverted ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:29:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11:29: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 1U9wFH-000754-Sx; Mon, 25 Feb 2013 11:29: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 1U9wFG-00074p-Nb
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:29:22 +0000
Received: from [193.109.254.147:18697] by server-16.bemta-14.messagelabs.com
	id 29/70-25906-11B4B215; Mon, 25 Feb 2013 11:29:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361791756!4448631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18755 invoked from network); 25 Feb 2013 11:29:17 -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; 25 Feb 2013 11:29:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 11:29:16 +0000
Message-Id: <512B591702000078000C0BCE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 11:29:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
	<20779.18914.422564.346844@mariner.uk.xensource.com>
In-Reply-To: <20779.18914.422564.346844@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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 25.02.13 at 12:24, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH 
> ISA bridge for IGD passthrough"):
>> > Applied, thanks.  I fixed up some wrap damage.
>> 
>> Which means that my pointing out of shortcomings in this patch
>> got completely ignored - we can only hope that this won't bite us
>> later...
> 
> Sorry about that, perhaps I didn't spot the thread.  Do you think it
> should be reverted ?

I'd prefer if you did so, and wait for a cleaned up version of the
patch to be submitted. If you leave in what's there right now, I
would b afraid that we'd never get to see a fixup patch on top.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:29:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11:29: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 1U9wFH-000754-Sx; Mon, 25 Feb 2013 11:29: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 1U9wFG-00074p-Nb
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:29:22 +0000
Received: from [193.109.254.147:18697] by server-16.bemta-14.messagelabs.com
	id 29/70-25906-11B4B215; Mon, 25 Feb 2013 11:29:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361791756!4448631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18755 invoked from network); 25 Feb 2013 11:29:17 -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; 25 Feb 2013 11:29:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 11:29:16 +0000
Message-Id: <512B591702000078000C0BCE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 11:29:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
	<20779.18914.422564.346844@mariner.uk.xensource.com>
In-Reply-To: <20779.18914.422564.346844@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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 25.02.13 at 12:24, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH 
> ISA bridge for IGD passthrough"):
>> > Applied, thanks.  I fixed up some wrap damage.
>> 
>> Which means that my pointing out of shortcomings in this patch
>> got completely ignored - we can only hope that this won't bite us
>> later...
> 
> Sorry about that, perhaps I didn't spot the thread.  Do you think it
> should be reverted ?

I'd prefer if you did so, and wait for a cleaned up version of the
patch to be submitted. If you leave in what's there right now, I
would b afraid that we'd never get to see a fixup patch on top.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:41:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11:41: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 1U9wQT-0007WS-7v; Mon, 25 Feb 2013 11:40: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 1U9wQR-0007WN-Vy
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:40:56 +0000
Received: from [193.109.254.147:55630] by server-4.bemta-14.messagelabs.com id
	AE/7A-20719-7CD4B215; Mon, 25 Feb 2013 11:40:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361791811!9578725!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27498 invoked from network); 25 Feb 2013 11:30:11 -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; 25 Feb 2013 11:30:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 11:30:10 +0000
Message-Id: <512B594E02000078000C0BD1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 11:30:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
In-Reply-To: <512B4724.5000603@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
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] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
> On 25/02/13 09:29, Jan Beulich wrote:
>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>> --- a/xen/common/sched_credit.c
>>>> +++ b/xen/common/sched_credit.c
>>>>
>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>  {
>>>>      s_time_t delta;
>>>> +    uint64_t val;
>>>>      unsigned int credits;
>>>>  
>>>>      /* Assert svc is current */
>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>      if ( (delta = now - svc->start_time) <= 0 )
>>>>          return;
>>>>  
>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / 
> MILLISECS(1);
>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>> +    credits = val;
>>>> +    ASSERT(credits == val);
>>>
>>> I may be missing something, but how can the assert ever be false, given
>>> the assignment right before it?
>> 
>> val being wider than credit, this checks that there was no truncation.
> 
> ASSERT(val <= UINT_MAX);
> 
> Would be clearer.

A matter of taste perhaps...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:41:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11:41: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 1U9wQT-0007WS-7v; Mon, 25 Feb 2013 11:40: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 1U9wQR-0007WN-Vy
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:40:56 +0000
Received: from [193.109.254.147:55630] by server-4.bemta-14.messagelabs.com id
	AE/7A-20719-7CD4B215; Mon, 25 Feb 2013 11:40:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361791811!9578725!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27498 invoked from network); 25 Feb 2013 11:30:11 -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; 25 Feb 2013 11:30:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 11:30:10 +0000
Message-Id: <512B594E02000078000C0BD1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 11:30:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
In-Reply-To: <512B4724.5000603@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
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] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
> On 25/02/13 09:29, Jan Beulich wrote:
>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>> --- a/xen/common/sched_credit.c
>>>> +++ b/xen/common/sched_credit.c
>>>>
>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>  static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>  {
>>>>      s_time_t delta;
>>>> +    uint64_t val;
>>>>      unsigned int credits;
>>>>  
>>>>      /* Assert svc is current */
>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>      if ( (delta = now - svc->start_time) <= 0 )
>>>>          return;
>>>>  
>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / 
> MILLISECS(1);
>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>> +    credits = val;
>>>> +    ASSERT(credits == val);
>>>
>>> I may be missing something, but how can the assert ever be false, given
>>> the assignment right before it?
>> 
>> val being wider than credit, this checks that there was no truncation.
> 
> ASSERT(val <= UINT_MAX);
> 
> Would be clearer.

A matter of taste perhaps...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:52:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wbD-0007zI-JG; Mon, 25 Feb 2013 11:52: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 1U9wbC-0007yS-7K
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:52:02 +0000
Received: from [85.158.143.99:23507] by server-3.bemta-4.messagelabs.com id
	55/82-02186-1605B215; Mon, 25 Feb 2013 11:52:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361793120!22230101!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12524 invoked from network); 25 Feb 2013 11:52:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1837127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:52: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.297.1; Mon, 25 Feb 2013 11:52:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9wbA-00077w-7a; Mon, 25 Feb 2013 11:52:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9wbA-00006h-3b;
	Mon, 25 Feb 2013 11:52:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.20575.738275.516284@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:51:59 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361787782.26546.171.camel@zakaz.uk.xensource.com>
References: <osstest-16308-mainreport@xen.org>
	<512B482602000078000C0B41@nat28.tlf.novell.com>
	<1361787782.26546.171.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 16308: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-4.1-testing test] 16308: tolerable FAIL"):
> On Mon, 2013-02-25 at 10:16 +0000, Jan Beulich wrote:
> > + cd /export/home/osstest/repos/xen-4.1-testing.hg
> > + hg push -r 6743c50ca91da63de23ad52f037bf9eadacfb492
> > ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
> > remote: abort: There is no Mercurial repository here (.hg not found)!
> > abort: no suitable response from remote hg!
> 
> Oops!

I could swear I had edited that bit but apparently not.  I've aborted
the current 4.1 test as it's doomed to do the same thing.  I've bench
tested the push script and hopefully the next time it will work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:52:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wbD-0007zI-JG; Mon, 25 Feb 2013 11:52: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 1U9wbC-0007yS-7K
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 11:52:02 +0000
Received: from [85.158.143.99:23507] by server-3.bemta-4.messagelabs.com id
	55/82-02186-1605B215; Mon, 25 Feb 2013 11:52:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361793120!22230101!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12524 invoked from network); 25 Feb 2013 11:52:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; 
   d="scan'208";a="1837127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:52: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.297.1; Mon, 25 Feb 2013 11:52:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1U9wbA-00077w-7a; Mon, 25 Feb 2013 11:52:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1U9wbA-00006h-3b;
	Mon, 25 Feb 2013 11:52:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.20575.738275.516284@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:51:59 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361787782.26546.171.camel@zakaz.uk.xensource.com>
References: <osstest-16308-mainreport@xen.org>
	<512B482602000078000C0B41@nat28.tlf.novell.com>
	<1361787782.26546.171.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 16308: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-4.1-testing test] 16308: tolerable FAIL"):
> On Mon, 2013-02-25 at 10:16 +0000, Jan Beulich wrote:
> > + cd /export/home/osstest/repos/xen-4.1-testing.hg
> > + hg push -r 6743c50ca91da63de23ad52f037bf9eadacfb492
> > ssh://osstest@xenbits.xensource.com/HG/xen-4.1-testing.hg
> > remote: abort: There is no Mercurial repository here (.hg not found)!
> > abort: no suitable response from remote hg!
> 
> Oops!

I could swear I had edited that bit but apparently not.  I've aborted
the current 4.1 test as it's doomed to do the same thing.  I've bench
tested the push script and hopefully the next time it will work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:59:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wi3-0008CJ-Rn; Mon, 25 Feb 2013 11:59: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 1U9wi2-0008CE-DO
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 11:59:06 +0000
Received: from [85.158.137.99:17993] by server-6.bemta-3.messagelabs.com id
	2A/3B-29959-9025B215; Mon, 25 Feb 2013 11:59:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361793274!17908700!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28499 invoked from network); 25 Feb 2013 11:54:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1837202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:54: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.297.1; Mon, 25 Feb 2013 11:54:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9wdd-00078z-NS;
	Mon, 25 Feb 2013 11:54:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9wdd-0005Sp-MY;
	Mon, 25 Feb 2013 11:54:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16638-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 11:54:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16638: trouble:
	fail/pass/preparing/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

flight 16638 xen-4.1-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16638/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            3 host-install(3)          running [st=running!]
 test-i386-i386-xl             3 host-install(3)          running [st=running!]
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)          running [st=running!]
 test-amd64-amd64-xl-win       3 host-install(3)          running [st=running!]
 test-i386-i386-win            2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-win7-amd64  2 hosts-allocate          running [st=running!]
 test-amd64-i386-qemut-win-vcpus1  7 windows-install      running [st=running!]
 test-amd64-i386-xl-qemut-win7-amd64  2 hosts-allocate    running [st=running!]
 test-i386-i386-xl-qemut-win   2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-win-vcpus1  2 hosts-allocate          running [st=running!]
 test-i386-i386-xl-winxpsp3    3 host-install(3)          running [st=running!]
 test-amd64-i386-xl-winxpsp3-vcpus1  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xend-qemut-winxpsp3  2 hosts-allocate    running [st=running!]
 test-amd64-i386-qemut-win     2 hosts-allocate           running [st=running!]
 test-amd64-i386-xend-winxpsp3  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-qemut-win-vcpus1  2 hosts-allocate    running [st=running!]
 test-i386-i386-qemut-win      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win7-amd64  2 hosts-allocate         running [st=running!]
 test-amd64-amd64-qemut-win    2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemut-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-winxpsp3  7 windows-install          running [st=running!]
 test-i386-i386-xl-win         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install    running [st=running!]
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install    running [st=running!]

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-qemuu-winxpsp3 11 guest-localmigrate.2    fail pass in 16508

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             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-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 16508 never pass
 test-i386-i386-win           16 leak-check/check      fail in 16508 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 16508 never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop        fail in 16508 never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16508 never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop     fail in 16508 never pass
 test-i386-i386-xl-qemut-win  13 guest-stop            fail in 16508 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 16508 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 16508 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 16508 never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 16508 never pass
 test-amd64-i386-qemut-win    16 leak-check/check      fail in 16508 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 16508 never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop     fail in 16508 never pass
 test-i386-i386-qemut-win     16 leak-check/check      fail in 16508 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 16508 never pass
 test-amd64-amd64-qemut-win   16 leak-check/check      fail in 16508 never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop        fail in 16508 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 16508 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 16508 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 16508 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 16508 never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                           running 
 test-i386-i386-xl                                            running 
 test-amd64-i386-rhel6hvm-amd                                 running 
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          preparing
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               preparing
 test-amd64-i386-xl-win7-amd64                                preparing
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             running 
 test-amd64-i386-xl-qemut-win-vcpus1                          preparing
 test-amd64-i386-xl-win-vcpus1                                preparing
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           preparing
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           preparing
 test-amd64-amd64-qemut-win                                   preparing
 test-amd64-i386-qemut-win                                    preparing
 test-i386-i386-qemut-win                                     preparing
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  preparing
 test-amd64-amd64-xl-win                                      running 
 test-i386-i386-xl-win                                        preparing
 test-amd64-i386-xend-qemut-winxpsp3                          preparing
 test-amd64-amd64-xl-qemut-winxpsp3                           running 
 test-i386-i386-xl-qemut-winxpsp3                             preparing
 test-amd64-amd64-xl-qemuu-winxpsp3                           running 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                preparing
 test-amd64-amd64-xl-winxpsp3                                 running 
 test-i386-i386-xl-winxpsp3                                   running 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 11:59:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 11: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 1U9wi3-0008CJ-Rn; Mon, 25 Feb 2013 11:59: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 1U9wi2-0008CE-DO
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 11:59:06 +0000
Received: from [85.158.137.99:17993] by server-6.bemta-3.messagelabs.com id
	2A/3B-29959-9025B215; Mon, 25 Feb 2013 11:59:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361793274!17908700!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28499 invoked from network); 25 Feb 2013 11:54:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 11:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1837202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 11:54: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.297.1; Mon, 25 Feb 2013 11:54:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9wdd-00078z-NS;
	Mon, 25 Feb 2013 11:54:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9wdd-0005Sp-MY;
	Mon, 25 Feb 2013 11:54:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16638-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 11:54:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16638: trouble:
	fail/pass/preparing/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

flight 16638 xen-4.1-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16638/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            3 host-install(3)          running [st=running!]
 test-i386-i386-xl             3 host-install(3)          running [st=running!]
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)          running [st=running!]
 test-amd64-amd64-xl-win       3 host-install(3)          running [st=running!]
 test-i386-i386-win            2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-win7-amd64  2 hosts-allocate          running [st=running!]
 test-amd64-i386-qemut-win-vcpus1  7 windows-install      running [st=running!]
 test-amd64-i386-xl-qemut-win7-amd64  2 hosts-allocate    running [st=running!]
 test-i386-i386-xl-qemut-win   2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-win-vcpus1  2 hosts-allocate          running [st=running!]
 test-i386-i386-xl-winxpsp3    3 host-install(3)          running [st=running!]
 test-amd64-i386-xl-winxpsp3-vcpus1  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xend-qemut-winxpsp3  2 hosts-allocate    running [st=running!]
 test-amd64-i386-qemut-win     2 hosts-allocate           running [st=running!]
 test-amd64-i386-xend-winxpsp3  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-qemut-win-vcpus1  2 hosts-allocate    running [st=running!]
 test-i386-i386-qemut-win      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win7-amd64  2 hosts-allocate         running [st=running!]
 test-amd64-amd64-qemut-win    2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemut-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-winxpsp3  7 windows-install          running [st=running!]
 test-i386-i386-xl-win         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install    running [st=running!]
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install    running [st=running!]

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-qemuu-winxpsp3 11 guest-localmigrate.2    fail pass in 16508

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             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-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 16508 never pass
 test-i386-i386-win           16 leak-check/check      fail in 16508 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 16508 never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop        fail in 16508 never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16508 never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop     fail in 16508 never pass
 test-i386-i386-xl-qemut-win  13 guest-stop            fail in 16508 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 16508 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 16508 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 16508 never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 16508 never pass
 test-amd64-i386-qemut-win    16 leak-check/check      fail in 16508 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 16508 never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop     fail in 16508 never pass
 test-i386-i386-qemut-win     16 leak-check/check      fail in 16508 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 16508 never pass
 test-amd64-amd64-qemut-win   16 leak-check/check      fail in 16508 never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop        fail in 16508 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 16508 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 16508 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 16508 never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop      fail in 16508 never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                           running 
 test-i386-i386-xl                                            running 
 test-amd64-i386-rhel6hvm-amd                                 running 
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          preparing
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               preparing
 test-amd64-i386-xl-win7-amd64                                preparing
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             running 
 test-amd64-i386-xl-qemut-win-vcpus1                          preparing
 test-amd64-i386-xl-win-vcpus1                                preparing
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           preparing
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           preparing
 test-amd64-amd64-qemut-win                                   preparing
 test-amd64-i386-qemut-win                                    preparing
 test-i386-i386-qemut-win                                     preparing
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  preparing
 test-amd64-amd64-xl-win                                      running 
 test-i386-i386-xl-win                                        preparing
 test-amd64-i386-xend-qemut-winxpsp3                          preparing
 test-amd64-amd64-xl-qemut-winxpsp3                           running 
 test-i386-i386-xl-qemut-winxpsp3                             preparing
 test-amd64-amd64-xl-qemuu-winxpsp3                           running 
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                preparing
 test-amd64-amd64-xl-winxpsp3                                 running 
 test-i386-i386-xl-winxpsp3                                   running 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 6743c50ca91da63de23ad52f037bf9eadacfb492
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 22 13:58:20 2013 +0100

    AMD IOMMU: don't BUG() when we don't have to
    
    find_iommu_for_device() can easily return NULL instead, as all of its
    callers are prepared for that.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398
    master date: 2013-02-18 09:37:35 +0100
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:05:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12:05: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 1U9wno-0000Ep-Sd; Mon, 25 Feb 2013 12:05: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 1U9wnm-0000Ej-VR
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 12:05:03 +0000
Received: from [193.109.254.147:57781] by server-6.bemta-14.messagelabs.com id
	13/CA-12010-E635B215; Mon, 25 Feb 2013 12:05:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361793441!2362232!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4629 invoked from network); 25 Feb 2013 11:57:22 -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;
	25 Feb 2013 11:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9349814"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 11:57:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 06:57:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9wgJ-0004zu-SE;
	Mon, 25 Feb 2013 11:57:19 +0000
Date: Mon, 25 Feb 2013 11:57:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361784321.26546.162.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302251156480.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<20130223191104.GA12606@konrad-lan.dumpdata.com> 
	<alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
	<1361784321.26546.162.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kees Cook <keescook@chromium.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Dongsheng Song <dongsheng.song@gmail.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
 CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Ian Campbell wrote:
> On Sat, 2013-02-23 at 20:47 +0000, Stefano Stabellini wrote:
> > On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > > On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > > <dongsheng.song@gmail.com> wrote:
> > > > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > > > >>
> > > > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > > > >> while now and is almost always enabled by default. As agreed during the
> > > > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > > > >>
> > > > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > >> ---
> > > > >>  arch/x86/xen/Kconfig |    2 +-
> > > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >>
> > > > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > >> index 93ff4e1..8cada4c 100644
> > > > >> --- a/arch/x86/xen/Kconfig
> > > > >> +++ b/arch/x86/xen/Kconfig
> > > > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > > >>
> > > > >>  config XEN_X86_PVH
> > > > >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > > >
> > > > > Why not remove this 'EXPERIMENTAL' too ?
> > > > 
> > > > It was unclear to me if the feature was actually considered unstable.
> > > > I can resend with the text removed from the title too, if that's the
> > > > correct action here?
> > > 
> > > It certainly is unstable right now (which is why it was unstaged from
> > > the v3.9 train). I hope that by v3.10 it won't be - at which
> > > point this patch (and the EXPERIMENTAL) makes sense.
> > > 
> > > So could you respin it please with the text removed as well - and I will
> > > queue it up in the branch that carries the PVH feature?
> > 
> > We also have the same flag on Xen ARM, and the reason is that the ABI is
> > not stable yet. As soon as it is (I think soon now), I'll send a patch
> > to remove EXPERIMENTAL from there too.
> 
> In the meantime if the depends EXPERIMENTAL is going away perhaps we
> should explain the EXPERIMENTAL in the title:
> 
> 8<----------------------------------------------------
> 
> From bc22bd0f7b20296c449a05d82be950922042bc92 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 4 Oct 2012 09:12:51 +0100
> Subject: [PATCH] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/arm/Kconfig |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 67874b8..ef14873 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1865,6 +1865,14 @@ config XEN
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> +
> +	  This option is EXPERIMENTAL because the hypervisor
> +	  interfaces which it uses are not yet considered stable
> +	  therefore backwards and forwards compatibility is not yet
> +	  guaranteed.
> +
> +	  If unsure, say N.
> +
>  endmenu
>  
>  menu "Boot options"
> -- 
> 1.7.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 Feb 25 12:05:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12:05: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 1U9wno-0000Ep-Sd; Mon, 25 Feb 2013 12:05: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 1U9wnm-0000Ej-VR
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 12:05:03 +0000
Received: from [193.109.254.147:57781] by server-6.bemta-14.messagelabs.com id
	13/CA-12010-E635B215; Mon, 25 Feb 2013 12:05:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361793441!2362232!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4629 invoked from network); 25 Feb 2013 11:57:22 -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;
	25 Feb 2013 11:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9349814"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 11:57:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 06:57:20 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9wgJ-0004zu-SE;
	Mon, 25 Feb 2013 11:57:19 +0000
Date: Mon, 25 Feb 2013 11:57:17 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361784321.26546.162.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302251156480.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<20130223191104.GA12606@konrad-lan.dumpdata.com> 
	<alpine.DEB.2.02.1302232045320.5360@kaball.uk.xensource.com>
	<1361784321.26546.162.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Kees Cook <keescook@chromium.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Dongsheng Song <dongsheng.song@gmail.com>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
 CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Ian Campbell wrote:
> On Sat, 2013-02-23 at 20:47 +0000, Stefano Stabellini wrote:
> > On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > > On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > > <dongsheng.song@gmail.com> wrote:
> > > > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > > > >>
> > > > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > > > >> while now and is almost always enabled by default. As agreed during the
> > > > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > > > >>
> > > > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > >> ---
> > > > >>  arch/x86/xen/Kconfig |    2 +-
> > > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >>
> > > > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > >> index 93ff4e1..8cada4c 100644
> > > > >> --- a/arch/x86/xen/Kconfig
> > > > >> +++ b/arch/x86/xen/Kconfig
> > > > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > > >>
> > > > >>  config XEN_X86_PVH
> > > > >>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > > >
> > > > > Why not remove this 'EXPERIMENTAL' too ?
> > > > 
> > > > It was unclear to me if the feature was actually considered unstable.
> > > > I can resend with the text removed from the title too, if that's the
> > > > correct action here?
> > > 
> > > It certainly is unstable right now (which is why it was unstaged from
> > > the v3.9 train). I hope that by v3.10 it won't be - at which
> > > point this patch (and the EXPERIMENTAL) makes sense.
> > > 
> > > So could you respin it please with the text removed as well - and I will
> > > queue it up in the branch that carries the PVH feature?
> > 
> > We also have the same flag on Xen ARM, and the reason is that the ABI is
> > not stable yet. As soon as it is (I think soon now), I'll send a patch
> > to remove EXPERIMENTAL from there too.
> 
> In the meantime if the depends EXPERIMENTAL is going away perhaps we
> should explain the EXPERIMENTAL in the title:
> 
> 8<----------------------------------------------------
> 
> From bc22bd0f7b20296c449a05d82be950922042bc92 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 4 Oct 2012 09:12:51 +0100
> Subject: [PATCH] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/arm/Kconfig |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 67874b8..ef14873 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1865,6 +1865,14 @@ config XEN
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> +
> +	  This option is EXPERIMENTAL because the hypervisor
> +	  interfaces which it uses are not yet considered stable
> +	  therefore backwards and forwards compatibility is not yet
> +	  guaranteed.
> +
> +	  If unsure, say N.
> +
>  endmenu
>  
>  menu "Boot options"
> -- 
> 1.7.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 Feb 25 12:40:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12: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 1U9xLX-000104-5m; Mon, 25 Feb 2013 12:39:55 +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 1U9xLV-0000zz-1b
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 12:39:53 +0000
Received: from [193.109.254.147:45910] by server-14.bemta-14.messagelabs.com
	id 60/3B-02031-89B5B215; Mon, 25 Feb 2013 12:39:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361795971!2672359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25121 invoked from network); 25 Feb 2013 12:39:32 -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;
	25 Feb 2013 12:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9357485"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 12:39:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 07:39:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9xL7-0005bx-Vf;
	Mon, 25 Feb 2013 12:39:29 +0000
Date: Mon, 25 Feb 2013 12:39:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In-Reply-To: <20130224144017.GB1111@kroah.com>
Message-ID: <alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
	<20130224144017.GB1111@kroah.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Feb 2013, Greg Kroah-Hartman wrote:
> On Sun, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> > On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > <dongsheng.song@gmail.com> wrote:
> > >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > >>>
> > >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > >>> while now and is almost always enabled by default. As agreed during the
> > >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > >>>
> > >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> > >>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>> ---
> > >>>  arch/x86/xen/Kconfig |    2 +-
> > >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > >>> index 93ff4e1..8cada4c 100644
> > >>> --- a/arch/x86/xen/Kconfig
> > >>> +++ b/arch/x86/xen/Kconfig
> > >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > >>>
> > >>>  config XEN_X86_PVH
> > >>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > >>
> > >> Why not remove this 'EXPERIMENTAL' too ?
> > >
> > > It was unclear to me if the feature was actually considered unstable.
> > > I can resend with the text removed from the title too, if that's the
> > > correct action here?
> > >
> > > -Kees
> > >
> > 
> > If such a feature was considered unstable, it should depends on EXPERIMENTAL.
> 
> CONFIG_EXPERIMENTAL is going away.
> 
> > We should not surprised users.
> 
> You should not have unstable options in the kernel in the first place,
> sorry.
 
With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
for me personally or my work, I am going to give you my 2 cents on the
matter, but feel free to ignore them :)

While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
rejecting everything that is not fully stable and with external
interfaces set in stones, might hinder the development of new features.

After all, given how fast the kernel is moving nowadays, maintaining a
project out-of-tree until is completely ready for production can be
very expensive. Merging the project earlier and completing the
development upstream can bring better results. But in these cases one
wouldn't want to "market" the feature as stable yet, because it just
isn't. If CONFIG_EXPERIMENTAL is going away, is there anything in the
kernel that can be used to tag a feature as "I wouldn't use it in
production if I were you"? Maybe just a comment in the kconfig
description?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:40:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12: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 1U9xLX-000104-5m; Mon, 25 Feb 2013 12:39:55 +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 1U9xLV-0000zz-1b
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 12:39:53 +0000
Received: from [193.109.254.147:45910] by server-14.bemta-14.messagelabs.com
	id 60/3B-02031-89B5B215; Mon, 25 Feb 2013 12:39:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1361795971!2672359!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25121 invoked from network); 25 Feb 2013 12:39:32 -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;
	25 Feb 2013 12:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9357485"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 12:39:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 07:39:30 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9xL7-0005bx-Vf;
	Mon, 25 Feb 2013 12:39:29 +0000
Date: Mon, 25 Feb 2013 12:39:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In-Reply-To: <20130224144017.GB1111@kroah.com>
Message-ID: <alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
	<20130224144017.GB1111@kroah.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 24 Feb 2013, Greg Kroah-Hartman wrote:
> On Sun, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> > On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > <dongsheng.song@gmail.com> wrote:
> > >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > >>>
> > >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > >>> while now and is almost always enabled by default. As agreed during the
> > >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > >>>
> > >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> > >>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>> ---
> > >>>  arch/x86/xen/Kconfig |    2 +-
> > >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > >>> index 93ff4e1..8cada4c 100644
> > >>> --- a/arch/x86/xen/Kconfig
> > >>> +++ b/arch/x86/xen/Kconfig
> > >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > >>>
> > >>>  config XEN_X86_PVH
> > >>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > >>
> > >> Why not remove this 'EXPERIMENTAL' too ?
> > >
> > > It was unclear to me if the feature was actually considered unstable.
> > > I can resend with the text removed from the title too, if that's the
> > > correct action here?
> > >
> > > -Kees
> > >
> > 
> > If such a feature was considered unstable, it should depends on EXPERIMENTAL.
> 
> CONFIG_EXPERIMENTAL is going away.
> 
> > We should not surprised users.
> 
> You should not have unstable options in the kernel in the first place,
> sorry.
 
With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
for me personally or my work, I am going to give you my 2 cents on the
matter, but feel free to ignore them :)

While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
rejecting everything that is not fully stable and with external
interfaces set in stones, might hinder the development of new features.

After all, given how fast the kernel is moving nowadays, maintaining a
project out-of-tree until is completely ready for production can be
very expensive. Merging the project earlier and completing the
development upstream can bring better results. But in these cases one
wouldn't want to "market" the feature as stable yet, because it just
isn't. If CONFIG_EXPERIMENTAL is going away, is there anything in the
kernel that can be used to tag a feature as "I wouldn't use it in
production if I were you"? Maybe just a comment in the kconfig
description?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:44:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12: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 1U9xPc-0001Ho-Rt; Mon, 25 Feb 2013 12:44: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 1U9xPc-0001Hg-1V
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 12:44:08 +0000
Received: from [193.109.254.147:15556] by server-5.bemta-14.messagelabs.com id
	97/D9-21539-79C5B215; Mon, 25 Feb 2013 12:44:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361796245!3984859!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28114 invoked from network); 25 Feb 2013 12:44:06 -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;
	25 Feb 2013 12:44:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8897236"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 12:44:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 07:44:04 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9xPY-0005fS-A3;
	Mon, 25 Feb 2013 12:44:04 +0000
Date: Mon, 25 Feb 2013 12:44:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: AP <apxeng@gmail.com>
In-Reply-To: <CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, AP wrote:
> On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> >
> >
> > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >
> >> I think it could still be very useful to many people. If not on the
> >> xen-unstable repository, it should still be published somewhere.
> >> Maybe a link on the wiki or a blog article?
> >
> >
> > I'm happy to tidy it up a bit if people think it is useful, and publish
> > it wherever. From memory the impact on the main code base is a 3 line
> > change to the Makefile, and doubtless I could minimise the other files
> > too.
> 
> This would be very useful for people trying to create their own
> minimal Xen image. I have been struggling with this for the past few
> days.
> 
> http://xen.markmail.org/thread/dac5kkuliky5373l

If there is a need for it and clearly the upstream Debian maintainers
don't care either way, why shouldn't we add the minideb target to our
own build system? If we are going to have a deb target anyway, we might
as well make it a useful one...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:44:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12: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 1U9xPc-0001Ho-Rt; Mon, 25 Feb 2013 12:44: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 1U9xPc-0001Hg-1V
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 12:44:08 +0000
Received: from [193.109.254.147:15556] by server-5.bemta-14.messagelabs.com id
	97/D9-21539-79C5B215; Mon, 25 Feb 2013 12:44:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361796245!3984859!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28114 invoked from network); 25 Feb 2013 12:44:06 -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;
	25 Feb 2013 12:44:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8897236"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 12:44:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 07:44:04 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9xPY-0005fS-A3;
	Mon, 25 Feb 2013 12:44:04 +0000
Date: Mon, 25 Feb 2013 12:44:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: AP <apxeng@gmail.com>
In-Reply-To: <CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 22 Feb 2013, AP wrote:
> On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> >
> >
> > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >
> >> I think it could still be very useful to many people. If not on the
> >> xen-unstable repository, it should still be published somewhere.
> >> Maybe a link on the wiki or a blog article?
> >
> >
> > I'm happy to tidy it up a bit if people think it is useful, and publish
> > it wherever. From memory the impact on the main code base is a 3 line
> > change to the Makefile, and doubtless I could minimise the other files
> > too.
> 
> This would be very useful for people trying to create their own
> minimal Xen image. I have been struggling with this for the past few
> days.
> 
> http://xen.markmail.org/thread/dac5kkuliky5373l

If there is a need for it and clearly the upstream Debian maintainers
don't care either way, why shouldn't we add the minideb target to our
own build system? If we are going to have a deb target anyway, we might
as well make it a useful one...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:51:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12: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 1U9xWF-0001Rp-P2; Mon, 25 Feb 2013 12:50: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 1U9xWE-0001Rj-CZ
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 12:50:58 +0000
Received: from [85.158.139.83:29668] by server-7.bemta-5.messagelabs.com id
	8D/A1-12441-13E5B215; Mon, 25 Feb 2013 12:50:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361796550!28828483!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24190 invoked from network); 25 Feb 2013 12:49:12 -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;
	25 Feb 2013 12:49:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8898095"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 12:49:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 07:49:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9xUT-0005kb-W7;
	Mon, 25 Feb 2013 12:49:09 +0000
Date: Mon, 25 Feb 2013 12:49:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B591702000078000C0BCE@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1302251248100.5360@kaball.uk.xensource.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
	<20779.18914.422564.346844@mariner.uk.xensource.com>
	<512B591702000078000C0BCE@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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, 25 Feb 2013, Jan Beulich wrote:
> >>> On 25.02.13 at 12:24, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH 
> > ISA bridge for IGD passthrough"):
> >> > Applied, thanks.  I fixed up some wrap damage.
> >> 
> >> Which means that my pointing out of shortcomings in this patch
> >> got completely ignored - we can only hope that this won't bite us
> >> later...
> > 
> > Sorry about that, perhaps I didn't spot the thread.  Do you think it
> > should be reverted ?
> 
> I'd prefer if you did so, and wait for a cleaned up version of the
> patch to be submitted. If you leave in what's there right now, I
> would b afraid that we'd never get to see a fixup patch on top.

You are talking about 5114F15002000078000BD2B2@nat28.tlf.novell.com?
G.R., can you work on this patch a bit more and address Jan's comments?
It shouldn't take long..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:51:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12: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 1U9xWF-0001Rp-P2; Mon, 25 Feb 2013 12:50: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 1U9xWE-0001Rj-CZ
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 12:50:58 +0000
Received: from [85.158.139.83:29668] by server-7.bemta-5.messagelabs.com id
	8D/A1-12441-13E5B215; Mon, 25 Feb 2013 12:50:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361796550!28828483!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24190 invoked from network); 25 Feb 2013 12:49:12 -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;
	25 Feb 2013 12:49:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8898095"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 12:49:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 07:49:10 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9xUT-0005kb-W7;
	Mon, 25 Feb 2013 12:49:09 +0000
Date: Mon, 25 Feb 2013 12:49:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B591702000078000C0BCE@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1302251248100.5360@kaball.uk.xensource.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
	<20779.18914.422564.346844@mariner.uk.xensource.com>
	<512B591702000078000C0BCE@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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, 25 Feb 2013, Jan Beulich wrote:
> >>> On 25.02.13 at 12:24, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH 
> > ISA bridge for IGD passthrough"):
> >> > Applied, thanks.  I fixed up some wrap damage.
> >> 
> >> Which means that my pointing out of shortcomings in this patch
> >> got completely ignored - we can only hope that this won't bite us
> >> later...
> > 
> > Sorry about that, perhaps I didn't spot the thread.  Do you think it
> > should be reverted ?
> 
> I'd prefer if you did so, and wait for a cleaned up version of the
> patch to be submitted. If you leave in what's there right now, I
> would b afraid that we'd never get to see a fixup patch on top.

You are talking about 5114F15002000078000BD2B2@nat28.tlf.novell.com?
G.R., can you work on this patch a bit more and address Jan's comments?
It shouldn't take long..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:55:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12:55: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 1U9xan-0001lP-Gc; Mon, 25 Feb 2013 12:55:41 +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 1U9xal-0001lJ-SD
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 12:55:40 +0000
Received: from [85.158.138.51:47140] by server-12.bemta-3.messagelabs.com id
	EE/F4-05889-B4F5B215; Mon, 25 Feb 2013 12:55:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361796934!23652282!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31933 invoked from network); 25 Feb 2013 12:55:35 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 12:55:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PCtGSU031594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 12:55: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
	r1PCtFj5017497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 12:55:15 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
	r1PCtEtp029312; Mon, 25 Feb 2013 06:55:14 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 04:55:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AEA121C3935; Mon, 25 Feb 2013 07:55:12 -0500 (EST)
Date: Mon, 25 Feb 2013 07:55:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130225125512.GA3135@phenom.dumpdata.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
	<20130224144017.GB1111@kroah.com>
	<alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Kees Cook <keescook@chromium.org>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 12:39:27PM +0000, Stefano Stabellini wrote:
> On Sun, 24 Feb 2013, Greg Kroah-Hartman wrote:
> > On Sun, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> > > On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> > > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > > <dongsheng.song@gmail.com> wrote:
> > > >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > > >>>
> > > >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > > >>> while now and is almost always enabled by default. As agreed during the
> > > >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > > >>>
> > > >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> > > >>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > >>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > >>> ---
> > > >>>  arch/x86/xen/Kconfig |    2 +-
> > > >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > >>> index 93ff4e1..8cada4c 100644
> > > >>> --- a/arch/x86/xen/Kconfig
> > > >>> +++ b/arch/x86/xen/Kconfig
> > > >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > >>>
> > > >>>  config XEN_X86_PVH
> > > >>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > >>
> > > >> Why not remove this 'EXPERIMENTAL' too ?
> > > >
> > > > It was unclear to me if the feature was actually considered unstable.
> > > > I can resend with the text removed from the title too, if that's the
> > > > correct action here?
> > > >
> > > > -Kees
> > > >
> > > 
> > > If such a feature was considered unstable, it should depends on EXPERIMENTAL.
> > 
> > CONFIG_EXPERIMENTAL is going away.
> > 
> > > We should not surprised users.
> > 
> > You should not have unstable options in the kernel in the first place,
> > sorry.

Just to clarify - this 'unstable' part is that the hypercall interface has
not been nailed down. As such the patchseries ('PVH') is not going in
Linus's tree until that is nailed down. However, the 'PVH' is going in
in 3.10 merge window (barring again delays).

Initially it was scheduled to be in v3.8, hence the reason it has
been lingering in #linux-next.

>  
> With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
> for me personally or my work, I am going to give you my 2 cents on the
> matter, but feel free to ignore them :)
> 
> While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
> rejecting everything that is not fully stable and with external
> interfaces set in stones, might hinder the development of new features.
> 
> After all, given how fast the kernel is moving nowadays, maintaining a
> project out-of-tree until is completely ready for production can be
> very expensive. Merging the project earlier and completing the
> development upstream can bring better results. But in these cases one
> wouldn't want to "market" the feature as stable yet, because it just
> isn't. If CONFIG_EXPERIMENTAL is going away, is there anything in the
> kernel that can be used to tag a feature as "I wouldn't use it in
> production if I were you"? Maybe just a comment in the kconfig
> description?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 12:55:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 12:55: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 1U9xan-0001lP-Gc; Mon, 25 Feb 2013 12:55:41 +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 1U9xal-0001lJ-SD
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 12:55:40 +0000
Received: from [85.158.138.51:47140] by server-12.bemta-3.messagelabs.com id
	EE/F4-05889-B4F5B215; Mon, 25 Feb 2013 12:55:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361796934!23652282!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31933 invoked from network); 25 Feb 2013 12:55:35 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 12:55:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PCtGSU031594
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 12:55: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
	r1PCtFj5017497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 12:55:15 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
	r1PCtEtp029312; Mon, 25 Feb 2013 06:55:14 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 04:55:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AEA121C3935; Mon, 25 Feb 2013 07:55:12 -0500 (EST)
Date: Mon, 25 Feb 2013 07:55:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130225125512.GA3135@phenom.dumpdata.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
	<20130224144017.GB1111@kroah.com>
	<alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Kees Cook <keescook@chromium.org>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 12:39:27PM +0000, Stefano Stabellini wrote:
> On Sun, 24 Feb 2013, Greg Kroah-Hartman wrote:
> > On Sun, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> > > On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook <keescook@chromium.org> wrote:
> > > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > > <dongsheng.song@gmail.com> wrote:
> > > >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook <keescook@chromium.org> wrote:
> > > >>>
> > > >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > > >>> while now and is almost always enabled by default. As agreed during the
> > > >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > > >>>
> > > >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> > > >>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > >>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > >>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > >>> ---
> > > >>>  arch/x86/xen/Kconfig |    2 +-
> > > >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > >>> index 93ff4e1..8cada4c 100644
> > > >>> --- a/arch/x86/xen/Kconfig
> > > >>> +++ b/arch/x86/xen/Kconfig
> > > >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > >>>
> > > >>>  config XEN_X86_PVH
> > > >>>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > >>
> > > >> Why not remove this 'EXPERIMENTAL' too ?
> > > >
> > > > It was unclear to me if the feature was actually considered unstable.
> > > > I can resend with the text removed from the title too, if that's the
> > > > correct action here?
> > > >
> > > > -Kees
> > > >
> > > 
> > > If such a feature was considered unstable, it should depends on EXPERIMENTAL.
> > 
> > CONFIG_EXPERIMENTAL is going away.
> > 
> > > We should not surprised users.
> > 
> > You should not have unstable options in the kernel in the first place,
> > sorry.

Just to clarify - this 'unstable' part is that the hypercall interface has
not been nailed down. As such the patchseries ('PVH') is not going in
Linus's tree until that is nailed down. However, the 'PVH' is going in
in 3.10 merge window (barring again delays).

Initially it was scheduled to be in v3.8, hence the reason it has
been lingering in #linux-next.

>  
> With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
> for me personally or my work, I am going to give you my 2 cents on the
> matter, but feel free to ignore them :)
> 
> While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
> rejecting everything that is not fully stable and with external
> interfaces set in stones, might hinder the development of new features.
> 
> After all, given how fast the kernel is moving nowadays, maintaining a
> project out-of-tree until is completely ready for production can be
> very expensive. Merging the project earlier and completing the
> development upstream can bring better results. But in these cases one
> wouldn't want to "market" the feature as stable yet, because it just
> isn't. If CONFIG_EXPERIMENTAL is going away, is there anything in the
> kernel that can be used to tag a feature as "I wouldn't use it in
> production if I were you"? Maybe just a comment in the kconfig
> description?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 13:13:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13:13: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 1U9xrY-0002eF-OM; Mon, 25 Feb 2013 13:13: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 1U9xrX-0002eA-Ao
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 13:12:59 +0000
Received: from [85.158.139.211:12328] by server-2.bemta-5.messagelabs.com id
	BF/C8-23989-A536B215; Mon, 25 Feb 2013 13:12:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361797972!15137839!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11346 invoked from network); 25 Feb 2013 13:12:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 13:12:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U9xrM-000KtZ-Ej; Mon, 25 Feb 2013 13:12:48 +0000
Date: Mon, 25 Feb 2013 13:12:48 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130225131248.GA78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> On Fri, 22 Feb 2013, AP wrote:
> > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> > >
> > >
> > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > >
> > >> I think it could still be very useful to many people. If not on the
> > >> xen-unstable repository, it should still be published somewhere.
> > >> Maybe a link on the wiki or a blog article?
> > >
> > >
> > > I'm happy to tidy it up a bit if people think it is useful, and publish
> > > it wherever. From memory the impact on the main code base is a 3 line
> > > change to the Makefile, and doubtless I could minimise the other files
> > > too.
> > 
> > This would be very useful for people trying to create their own
> > minimal Xen image. I have been struggling with this for the past few
> > days.
> > 
> > http://xen.markmail.org/thread/dac5kkuliky5373l
> 
> If there is a need for it and clearly the upstream Debian maintainers
> don't care either way, why shouldn't we add the minideb target to our
> own build system? If we are going to have a deb target anyway, we might
> as well make it a useful one...

Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
Debian/Ubuntu.  That would be much more widely useful, for a similar
amount of effort.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 13:13:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13:13: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 1U9xrY-0002eF-OM; Mon, 25 Feb 2013 13:13: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 1U9xrX-0002eA-Ao
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 13:12:59 +0000
Received: from [85.158.139.211:12328] by server-2.bemta-5.messagelabs.com id
	BF/C8-23989-A536B215; Mon, 25 Feb 2013 13:12:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361797972!15137839!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11346 invoked from network); 25 Feb 2013 13:12:53 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 13:12:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1U9xrM-000KtZ-Ej; Mon, 25 Feb 2013 13:12:48 +0000
Date: Mon, 25 Feb 2013 13:12:48 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130225131248.GA78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> On Fri, 22 Feb 2013, AP wrote:
> > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> > >
> > >
> > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > >
> > >> I think it could still be very useful to many people. If not on the
> > >> xen-unstable repository, it should still be published somewhere.
> > >> Maybe a link on the wiki or a blog article?
> > >
> > >
> > > I'm happy to tidy it up a bit if people think it is useful, and publish
> > > it wherever. From memory the impact on the main code base is a 3 line
> > > change to the Makefile, and doubtless I could minimise the other files
> > > too.
> > 
> > This would be very useful for people trying to create their own
> > minimal Xen image. I have been struggling with this for the past few
> > days.
> > 
> > http://xen.markmail.org/thread/dac5kkuliky5373l
> 
> If there is a need for it and clearly the upstream Debian maintainers
> don't care either way, why shouldn't we add the minideb target to our
> own build system? If we are going to have a deb target anyway, we might
> as well make it a useful one...

Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
Debian/Ubuntu.  That would be much more widely useful, for a similar
amount of effort.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 13:16:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13: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 1U9xuB-0002lb-IE; Mon, 25 Feb 2013 13:15:43 +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 1U9xu9-0002lU-DP
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 13:15:41 +0000
Received: from [85.158.138.51:7274] by server-13.bemta-3.messagelabs.com id
	DD/40-20653-CF36B215; Mon, 25 Feb 2013 13:15:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361798139!20184645!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16739 invoked from network); 25 Feb 2013 13:15:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 13:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1840719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 13:15: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.297.1;
	Mon, 25 Feb 2013 13:15:39 +0000
Message-ID: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 25 Feb 2013 13:15:37 +0000
In-Reply-To: <20130225131248.GA78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
> At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> > On Fri, 22 Feb 2013, AP wrote:
> > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> > > >
> > > >
> > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > >
> > > >> I think it could still be very useful to many people. If not on the
> > > >> xen-unstable repository, it should still be published somewhere.
> > > >> Maybe a link on the wiki or a blog article?
> > > >
> > > >
> > > > I'm happy to tidy it up a bit if people think it is useful, and publish
> > > > it wherever. From memory the impact on the main code base is a 3 line
> > > > change to the Makefile, and doubtless I could minimise the other files
> > > > too.
> > > 
> > > This would be very useful for people trying to create their own
> > > minimal Xen image. I have been struggling with this for the past few
> > > days.
> > > 
> > > http://xen.markmail.org/thread/dac5kkuliky5373l
> > 
> > If there is a need for it and clearly the upstream Debian maintainers
> > don't care either way, why shouldn't we add the minideb target to our
> > own build system? If we are going to have a deb target anyway, we might
> > as well make it a useful one...
> 
> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> Debian/Ubuntu.  That would be much more widely useful, for a similar
> amount of effort.

4.2.0 is already in Debian experimental.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 13:16:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13: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 1U9xuB-0002lb-IE; Mon, 25 Feb 2013 13:15:43 +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 1U9xu9-0002lU-DP
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 13:15:41 +0000
Received: from [85.158.138.51:7274] by server-13.bemta-3.messagelabs.com id
	DD/40-20653-CF36B215; Mon, 25 Feb 2013 13:15:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361798139!20184645!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16739 invoked from network); 25 Feb 2013 13:15:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 13:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1840719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 13:15: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.297.1;
	Mon, 25 Feb 2013 13:15:39 +0000
Message-ID: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 25 Feb 2013 13:15:37 +0000
In-Reply-To: <20130225131248.GA78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
> At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> > On Fri, 22 Feb 2013, AP wrote:
> > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> > > >
> > > >
> > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > >
> > > >> I think it could still be very useful to many people. If not on the
> > > >> xen-unstable repository, it should still be published somewhere.
> > > >> Maybe a link on the wiki or a blog article?
> > > >
> > > >
> > > > I'm happy to tidy it up a bit if people think it is useful, and publish
> > > > it wherever. From memory the impact on the main code base is a 3 line
> > > > change to the Makefile, and doubtless I could minimise the other files
> > > > too.
> > > 
> > > This would be very useful for people trying to create their own
> > > minimal Xen image. I have been struggling with this for the past few
> > > days.
> > > 
> > > http://xen.markmail.org/thread/dac5kkuliky5373l
> > 
> > If there is a need for it and clearly the upstream Debian maintainers
> > don't care either way, why shouldn't we add the minideb target to our
> > own build system? If we are going to have a deb target anyway, we might
> > as well make it a useful one...
> 
> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> Debian/Ubuntu.  That would be much more widely useful, for a similar
> amount of effort.

4.2.0 is already in Debian experimental.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 13:34:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13:34: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 1U9yCU-0003KD-Ay; Mon, 25 Feb 2013 13:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <p.d@gmx.de>)
	id 1U9uSi-00029s-Je
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:35:08 +0000
Received: from [85.158.139.83:42115] by server-12.bemta-5.messagelabs.com id
	82/19-11486-B403B215; Mon, 25 Feb 2013 09:35:07 +0000
X-Env-Sender: p.d@gmx.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361784906!28784953!1
X-Originating-IP: [212.227.17.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4yMSA9PiAyMjA0Mg==\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32143 invoked from network); 25 Feb 2013 09:35:06 -0000
Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21)
	by server-12.tower-182.messagelabs.com with SMTP;
	25 Feb 2013 09:35:06 -0000
Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan
	(mrigmx001) with ESMTP (Nemesis) id 0MTuW7-1UITBe2vZJ-00QmhN for
	<xen-devel@lists.xen.org>; Mon, 25 Feb 2013 10:34:15 +0100
Received: (qmail invoked by alias); 25 Feb 2013 09:34:15 -0000
Received: from manz-590f36c7.pool.mediaWays.net (EHLO [192.168.179.15])
	[89.15.54.199]
	by mail.gmx.net (mp012) with SMTP; 25 Feb 2013 10:34:15 +0100
X-Authenticated: #16432423
X-Provags-ID: V01U2FsdGVkX18ZOUgNIgwZvQ2z6yn/D/IDFE9IYmbPzdiMOdeaqX
	zN001FFFxDO3ti
Date: Mon, 25 Feb 2013 10:34:13 +0100
From: p.d@gmx.de
X-Priority: 3 (Normal)
Message-ID: <128641971.20130225103413@gmx.de>
To: xen-devel@lists.xen.org
In-Reply-To: <CACA08DwJjqWXy92aCezSr9eoV4wDxWiVQEPJkyGiGJ+=W=Wf=g@mail.gmail.com>
References: <CACA08DwJjqWXy92aCezSr9eoV4wDxWiVQEPJkyGiGJ+=W=Wf=g@mail.gmail.com>
MIME-Version: 1.0
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Mon, 25 Feb 2013 13:34:37 +0000
Cc: Nicolas Brianchon <brianchon.n@gmail.com>
Subject: Re: [Xen-devel] SATA controller passthrough - option rom
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: p.d@gmx.de
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5166049421930620805=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5166049421930620805==
Content-Type: multipart/alternative;
 boundary="----------0000421733713B7F6"

------------0000421733713B7F6
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Some users ask me:

>Hello Denis,

>I found one of your post about asus U3S6 passthrough.
>http://comments.gmane.org/gmane.comp.emulators.xen.devel/137586

>I may have the same problem as you (DomU cannot find the disk connected to=
 the Marvell controller), and I would like to know if it's now working for =
you ?

>Have a good day.

>Regards,
>Nicolas
> briancho ** @gmail.com


Hello, Nicolas,

I have not found a solution.=20

The problem ist SATA-controllers own BIOS and his initialization in XEN-gue=
st. So I refuse from Sata-controller.

XEN had bad disk performance in guest. I tried KVM with guest-image-file on=
 SSD (mounted in Host system and through mainboard controller), here was be=
st disk performance. But I needed graphic card in guest and I could not ins=
tall the graphics card driver in KVM.
As You know XEN, as KVM  based on Qemu. So I tried Qemu. This solution I ha=
ve left me.

Following I attach my CrystalDiskMark tests.

-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 x64 (C) 2007-2012 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
RAMDISK :)
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]

           Sequential Read :  5431.277 MB/s
          Sequential Write :  5583.100 MB/s
         Random Read 512KB :  6012.069 MB/s
        Random Write 512KB :  6352.203 MB/s
    Random Read 4KB (QD=3D1) :   668.879 MB/s [163300.6 IOPS]
   Random Write 4KB (QD=3D1) :   626.097 MB/s [152855.7 IOPS]
   Random Read 4KB (QD=3D32) :   666.919 MB/s [162822.1 IOPS]
  Random Write 4KB (QD=3D32) :   595.098 MB/s [145287.6 IOPS]

  Test : 1000 MB [R: 28.8% (2063.4/7168.0 MB)] (x5)
  Date : 2012/10/31 1:28:05
    OS : Windows 8 Professional [6.2 Build 9200] (x64)


-----------------------------------------------------------------------
LVM RAID1, 2x Seagate HDD baracuda 11.7 ?
-----------------------------------------------------------------------
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]

           Sequential Read :  1853.501 MB/s
          Sequential Write :    55.046 MB/s
         Random Read 512KB :  1300.911 MB/s
        Random Write 512KB :    28.900 MB/s
    Random Read 4KB (QD=3D1) :    24.632 MB/s [  6013.6 IOPS]
   Random Write 4KB (QD=3D1) :     0.413 MB/s [   100.9 IOPS]
   Random Read 4KB (QD=3D32) :    82.125 MB/s [ 20050.0 IOPS]
  Random Write 4KB (QD=3D32) :     0.736 MB/s [   179.7 IOPS]

  Test : 1000 MB [E: 53.4% (10.7/20.0 GB)] (x5)
  Date : 2012/10/31 1:36:59
    OS : Windows 8 Professional [6.2 Build 9200] (x64)

-----------------------------------------------------------------------
(programme:\)qemu raw image file on SSD Vertex Agility 4:
-----------------------------------------------------------------------
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]

           Sequential Read :  2086.372 MB/s
          Sequential Write :   148.418 MB/s
         Random Read 512KB :  1230.134 MB/s
        Random Write 512KB :   140.760 MB/s
    Random Read 4KB (QD=3D1) :    36.603 MB/s [  8936.2 IOPS]
   Random Write 4KB (QD=3D1) :     6.762 MB/s [  1650.9 IOPS]
   Random Read 4KB (QD=3D32) :    78.257 MB/s [ 19105.8 IOPS]
  Random Write 4KB (QD=3D32) :     6.946 MB/s [  1695.7 IOPS]

  Test : 1000 MB [H: 22.5% (4.9/21.9 GB)] (x5)
  Date : 2012/10/31 1:45:31
    OS : Windows 8 Professional [6.2 Build 9200] (x64)


Regards,
Denis

______________________________
https://biwebco.com/produkte/ispmanager soon we start selling of german ISP=
-manager and other products from ISPsystem.


------------0000421733713B7F6
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><title>Re: [Xen-devel] SATA controller passthrough - option rom=
</title>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
</head>
<body>
<span style=3D" font-family:'Cambria'; font-size: 11pt;">Some users ask me:=
<br>
<br>
&gt;Hello Denis,<br>
<br>
&gt;I found one of your post about asus U3S6 passthrough.<br>
</span><a style=3D" font-family:'cambria'; font-size: 11pt;" href=3D"http:/=
/comments.gmane.org/gmane.comp.emulators.xen.devel/137586">&gt;http://comme=
nts.gmane.org/gmane.comp.emulators.xen.devel/137586</a><br>
<br>
<span style=3D" font-family:'cambria'; font-size: 11pt;">&gt;I may have the=
 same problem as you (DomU cannot find the disk connected to the Marvell co=
ntroller), and I would like to know if it's now working for you ?<br>
<br>
&gt;Have a good day.<br>
<br>
&gt;Regards,<br>
&gt;Nicolas<br>
&gt;&nbsp;</span><a style=3D" font-family:'Cambria'; font-size: 11pt;" href=
=3D"mailto:brianchon.n@gmail.com">briancho ** @gmail.com</a><br>
<br>
<br>
<span style=3D" font-family:'Cambria'; font-size: 11pt;">Hello, Nicolas,<br>
<br>
I have not found a solution.&nbsp;<br>
<br>
The problem ist SATA-controllers own BIOS and his initialization in XEN-gue=
st. So I refuse from Sata-controller.<br>
<br>
XEN had bad disk performance in guest. I tried KVM with guest-image-file on=
 SSD (mounted in Host system and through mainboard controller), here was be=
st disk performance. But I needed graphic card in guest and I could not ins=
tall the graphics card driver in KVM.<br>
As You know XEN, as KVM &nbsp;based on Qemu. So I tried Qemu. This solution=
 I have left me.<br>
<br>
Following I attach my CrystalDiskMark tests.<br>
<br>
-----------------------------------------------------------------------<br>
CrystalDiskMark 3.0.2 x64 (C) 2007-2012 hiyohiyo<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;Crystal Dew World : http://crystalmark.info/<br>
-----------------------------------------------------------------------<br>
RAMDISK :)<br>
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sequential Read : &nbsp;5431.277 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sequential Write : &nbsp;5583.100 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Random Read 512KB : &nbsp;6012.069 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; Random Write 512KB : &nbsp;6352.203 MB/s<br>
&nbsp; &nbsp; Random Read 4KB (QD=3D1) : &nbsp; 668.879 MB/s [163300.6 IOPS=
]<br>
&nbsp; &nbsp;Random Write 4KB (QD=3D1) : &nbsp; 626.097 MB/s [152855.7 IOPS=
]<br>
&nbsp; &nbsp;Random Read 4KB (QD=3D32) : &nbsp; 666.919 MB/s [162822.1 IOPS=
]<br>
&nbsp; Random Write 4KB (QD=3D32) : &nbsp; 595.098 MB/s [145287.6 IOPS]<br>
<br>
&nbsp; Test : 1000 MB [R: 28.8% (2063.4/7168.0 MB)] (x5)<br>
&nbsp; Date : 2012/10/31 1:28:05<br>
&nbsp; &nbsp; OS : Windows 8 Professional [6.2 Build 9200] (x64)<br>
<br>
<br>
-----------------------------------------------------------------------<br>
LVM RAID1, 2x Seagate HDD baracuda 11.7 ?<br>
-----------------------------------------------------------------------<br>
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sequential Read : &nbsp;1853.501 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sequential Write : &nbsp; &nbsp;55.046 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Random Read 512KB : &nbsp;1300.911 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; Random Write 512KB : &nbsp; &nbsp;28.900 MB/s<b=
r>
&nbsp; &nbsp; Random Read 4KB (QD=3D1) : &nbsp; &nbsp;24.632 MB/s [ &nbsp;6=
013.6 IOPS]<br>
&nbsp; &nbsp;Random Write 4KB (QD=3D1) : &nbsp; &nbsp; 0.413 MB/s [ &nbsp; =
100.9 IOPS]<br>
&nbsp; &nbsp;Random Read 4KB (QD=3D32) : &nbsp; &nbsp;82.125 MB/s [ 20050.0=
 IOPS]<br>
&nbsp; Random Write 4KB (QD=3D32) : &nbsp; &nbsp; 0.736 MB/s [ &nbsp; 179.7=
 IOPS]<br>
<br>
&nbsp; Test : 1000 MB [E: 53.4% (10.7/20.0 GB)] (x5)<br>
&nbsp; Date : 2012/10/31 1:36:59<br>
&nbsp; &nbsp; OS : Windows 8 Professional [6.2 Build 9200] (x64)<br>
<br>
-----------------------------------------------------------------------<br>
(programme:\)qemu raw image file on SSD Vertex Agility 4:<br>
-----------------------------------------------------------------------<br>
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sequential Read : &nbsp;2086.372 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sequential Write : &nbsp; 148.418 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Random Read 512KB : &nbsp;1230.134 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; Random Write 512KB : &nbsp; 140.760 MB/s<br>
&nbsp; &nbsp; Random Read 4KB (QD=3D1) : &nbsp; &nbsp;36.603 MB/s [ &nbsp;8=
936.2 IOPS]<br>
&nbsp; &nbsp;Random Write 4KB (QD=3D1) : &nbsp; &nbsp; 6.762 MB/s [ &nbsp;1=
650.9 IOPS]<br>
&nbsp; &nbsp;Random Read 4KB (QD=3D32) : &nbsp; &nbsp;78.257 MB/s [ 19105.8=
 IOPS]<br>
&nbsp; Random Write 4KB (QD=3D32) : &nbsp; &nbsp; 6.946 MB/s [ &nbsp;1695.7=
 IOPS]<br>
<br>
&nbsp; Test : 1000 MB [H: 22.5% (4.9/21.9 GB)] (x5)<br>
&nbsp; Date : 2012/10/31 1:45:31<br>
&nbsp; &nbsp; OS : Windows 8 Professional [6.2 Build 9200] (x64)<br>
<br>
<br>
Regards,<br>
Denis<br>
<br>
______________________________<br>
</span><a style=3D" font-family:'Cambria'; font-size: 11pt;" href=3D"https:=
//biwebco.com/produkte/ispmanager">https://biwebco.com/produkte/ispmanager<=
/a><span style=3D" font-family:'Cambria'; font-size: 11pt;">&nbsp;soon we s=
tart selling of german ISP-manager and other products from ISPsystem.<br>
<br>
<br>
</body></html>
------------0000421733713B7F6--



--===============5166049421930620805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5166049421930620805==--



From xen-devel-bounces@lists.xen.org Mon Feb 25 13:34:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13:34: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 1U9yCU-0003KD-Ay; Mon, 25 Feb 2013 13:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <p.d@gmx.de>)
	id 1U9uSi-00029s-Je
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 09:35:08 +0000
Received: from [85.158.139.83:42115] by server-12.bemta-5.messagelabs.com id
	82/19-11486-B403B215; Mon, 25 Feb 2013 09:35:07 +0000
X-Env-Sender: p.d@gmx.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361784906!28784953!1
X-Originating-IP: [212.227.17.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4yMSA9PiAyMjA0Mg==\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32143 invoked from network); 25 Feb 2013 09:35:06 -0000
Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21)
	by server-12.tower-182.messagelabs.com with SMTP;
	25 Feb 2013 09:35:06 -0000
Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan
	(mrigmx001) with ESMTP (Nemesis) id 0MTuW7-1UITBe2vZJ-00QmhN for
	<xen-devel@lists.xen.org>; Mon, 25 Feb 2013 10:34:15 +0100
Received: (qmail invoked by alias); 25 Feb 2013 09:34:15 -0000
Received: from manz-590f36c7.pool.mediaWays.net (EHLO [192.168.179.15])
	[89.15.54.199]
	by mail.gmx.net (mp012) with SMTP; 25 Feb 2013 10:34:15 +0100
X-Authenticated: #16432423
X-Provags-ID: V01U2FsdGVkX18ZOUgNIgwZvQ2z6yn/D/IDFE9IYmbPzdiMOdeaqX
	zN001FFFxDO3ti
Date: Mon, 25 Feb 2013 10:34:13 +0100
From: p.d@gmx.de
X-Priority: 3 (Normal)
Message-ID: <128641971.20130225103413@gmx.de>
To: xen-devel@lists.xen.org
In-Reply-To: <CACA08DwJjqWXy92aCezSr9eoV4wDxWiVQEPJkyGiGJ+=W=Wf=g@mail.gmail.com>
References: <CACA08DwJjqWXy92aCezSr9eoV4wDxWiVQEPJkyGiGJ+=W=Wf=g@mail.gmail.com>
MIME-Version: 1.0
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Mon, 25 Feb 2013 13:34:37 +0000
Cc: Nicolas Brianchon <brianchon.n@gmail.com>
Subject: Re: [Xen-devel] SATA controller passthrough - option rom
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: p.d@gmx.de
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5166049421930620805=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5166049421930620805==
Content-Type: multipart/alternative;
 boundary="----------0000421733713B7F6"

------------0000421733713B7F6
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Some users ask me:

>Hello Denis,

>I found one of your post about asus U3S6 passthrough.
>http://comments.gmane.org/gmane.comp.emulators.xen.devel/137586

>I may have the same problem as you (DomU cannot find the disk connected to=
 the Marvell controller), and I would like to know if it's now working for =
you ?

>Have a good day.

>Regards,
>Nicolas
> briancho ** @gmail.com


Hello, Nicolas,

I have not found a solution.=20

The problem ist SATA-controllers own BIOS and his initialization in XEN-gue=
st. So I refuse from Sata-controller.

XEN had bad disk performance in guest. I tried KVM with guest-image-file on=
 SSD (mounted in Host system and through mainboard controller), here was be=
st disk performance. But I needed graphic card in guest and I could not ins=
tall the graphics card driver in KVM.
As You know XEN, as KVM  based on Qemu. So I tried Qemu. This solution I ha=
ve left me.

Following I attach my CrystalDiskMark tests.

-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 x64 (C) 2007-2012 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
RAMDISK :)
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]

           Sequential Read :  5431.277 MB/s
          Sequential Write :  5583.100 MB/s
         Random Read 512KB :  6012.069 MB/s
        Random Write 512KB :  6352.203 MB/s
    Random Read 4KB (QD=3D1) :   668.879 MB/s [163300.6 IOPS]
   Random Write 4KB (QD=3D1) :   626.097 MB/s [152855.7 IOPS]
   Random Read 4KB (QD=3D32) :   666.919 MB/s [162822.1 IOPS]
  Random Write 4KB (QD=3D32) :   595.098 MB/s [145287.6 IOPS]

  Test : 1000 MB [R: 28.8% (2063.4/7168.0 MB)] (x5)
  Date : 2012/10/31 1:28:05
    OS : Windows 8 Professional [6.2 Build 9200] (x64)


-----------------------------------------------------------------------
LVM RAID1, 2x Seagate HDD baracuda 11.7 ?
-----------------------------------------------------------------------
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]

           Sequential Read :  1853.501 MB/s
          Sequential Write :    55.046 MB/s
         Random Read 512KB :  1300.911 MB/s
        Random Write 512KB :    28.900 MB/s
    Random Read 4KB (QD=3D1) :    24.632 MB/s [  6013.6 IOPS]
   Random Write 4KB (QD=3D1) :     0.413 MB/s [   100.9 IOPS]
   Random Read 4KB (QD=3D32) :    82.125 MB/s [ 20050.0 IOPS]
  Random Write 4KB (QD=3D32) :     0.736 MB/s [   179.7 IOPS]

  Test : 1000 MB [E: 53.4% (10.7/20.0 GB)] (x5)
  Date : 2012/10/31 1:36:59
    OS : Windows 8 Professional [6.2 Build 9200] (x64)

-----------------------------------------------------------------------
(programme:\)qemu raw image file on SSD Vertex Agility 4:
-----------------------------------------------------------------------
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]

           Sequential Read :  2086.372 MB/s
          Sequential Write :   148.418 MB/s
         Random Read 512KB :  1230.134 MB/s
        Random Write 512KB :   140.760 MB/s
    Random Read 4KB (QD=3D1) :    36.603 MB/s [  8936.2 IOPS]
   Random Write 4KB (QD=3D1) :     6.762 MB/s [  1650.9 IOPS]
   Random Read 4KB (QD=3D32) :    78.257 MB/s [ 19105.8 IOPS]
  Random Write 4KB (QD=3D32) :     6.946 MB/s [  1695.7 IOPS]

  Test : 1000 MB [H: 22.5% (4.9/21.9 GB)] (x5)
  Date : 2012/10/31 1:45:31
    OS : Windows 8 Professional [6.2 Build 9200] (x64)


Regards,
Denis

______________________________
https://biwebco.com/produkte/ispmanager soon we start selling of german ISP=
-manager and other products from ISPsystem.


------------0000421733713B7F6
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><title>Re: [Xen-devel] SATA controller passthrough - option rom=
</title>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
</head>
<body>
<span style=3D" font-family:'Cambria'; font-size: 11pt;">Some users ask me:=
<br>
<br>
&gt;Hello Denis,<br>
<br>
&gt;I found one of your post about asus U3S6 passthrough.<br>
</span><a style=3D" font-family:'cambria'; font-size: 11pt;" href=3D"http:/=
/comments.gmane.org/gmane.comp.emulators.xen.devel/137586">&gt;http://comme=
nts.gmane.org/gmane.comp.emulators.xen.devel/137586</a><br>
<br>
<span style=3D" font-family:'cambria'; font-size: 11pt;">&gt;I may have the=
 same problem as you (DomU cannot find the disk connected to the Marvell co=
ntroller), and I would like to know if it's now working for you ?<br>
<br>
&gt;Have a good day.<br>
<br>
&gt;Regards,<br>
&gt;Nicolas<br>
&gt;&nbsp;</span><a style=3D" font-family:'Cambria'; font-size: 11pt;" href=
=3D"mailto:brianchon.n@gmail.com">briancho ** @gmail.com</a><br>
<br>
<br>
<span style=3D" font-family:'Cambria'; font-size: 11pt;">Hello, Nicolas,<br>
<br>
I have not found a solution.&nbsp;<br>
<br>
The problem ist SATA-controllers own BIOS and his initialization in XEN-gue=
st. So I refuse from Sata-controller.<br>
<br>
XEN had bad disk performance in guest. I tried KVM with guest-image-file on=
 SSD (mounted in Host system and through mainboard controller), here was be=
st disk performance. But I needed graphic card in guest and I could not ins=
tall the graphics card driver in KVM.<br>
As You know XEN, as KVM &nbsp;based on Qemu. So I tried Qemu. This solution=
 I have left me.<br>
<br>
Following I attach my CrystalDiskMark tests.<br>
<br>
-----------------------------------------------------------------------<br>
CrystalDiskMark 3.0.2 x64 (C) 2007-2012 hiyohiyo<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp;Crystal Dew World : http://crystalmark.info/<br>
-----------------------------------------------------------------------<br>
RAMDISK :)<br>
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sequential Read : &nbsp;5431.277 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sequential Write : &nbsp;5583.100 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Random Read 512KB : &nbsp;6012.069 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; Random Write 512KB : &nbsp;6352.203 MB/s<br>
&nbsp; &nbsp; Random Read 4KB (QD=3D1) : &nbsp; 668.879 MB/s [163300.6 IOPS=
]<br>
&nbsp; &nbsp;Random Write 4KB (QD=3D1) : &nbsp; 626.097 MB/s [152855.7 IOPS=
]<br>
&nbsp; &nbsp;Random Read 4KB (QD=3D32) : &nbsp; 666.919 MB/s [162822.1 IOPS=
]<br>
&nbsp; Random Write 4KB (QD=3D32) : &nbsp; 595.098 MB/s [145287.6 IOPS]<br>
<br>
&nbsp; Test : 1000 MB [R: 28.8% (2063.4/7168.0 MB)] (x5)<br>
&nbsp; Date : 2012/10/31 1:28:05<br>
&nbsp; &nbsp; OS : Windows 8 Professional [6.2 Build 9200] (x64)<br>
<br>
<br>
-----------------------------------------------------------------------<br>
LVM RAID1, 2x Seagate HDD baracuda 11.7 ?<br>
-----------------------------------------------------------------------<br>
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sequential Read : &nbsp;1853.501 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sequential Write : &nbsp; &nbsp;55.046 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Random Read 512KB : &nbsp;1300.911 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; Random Write 512KB : &nbsp; &nbsp;28.900 MB/s<b=
r>
&nbsp; &nbsp; Random Read 4KB (QD=3D1) : &nbsp; &nbsp;24.632 MB/s [ &nbsp;6=
013.6 IOPS]<br>
&nbsp; &nbsp;Random Write 4KB (QD=3D1) : &nbsp; &nbsp; 0.413 MB/s [ &nbsp; =
100.9 IOPS]<br>
&nbsp; &nbsp;Random Read 4KB (QD=3D32) : &nbsp; &nbsp;82.125 MB/s [ 20050.0=
 IOPS]<br>
&nbsp; Random Write 4KB (QD=3D32) : &nbsp; &nbsp; 0.736 MB/s [ &nbsp; 179.7=
 IOPS]<br>
<br>
&nbsp; Test : 1000 MB [E: 53.4% (10.7/20.0 GB)] (x5)<br>
&nbsp; Date : 2012/10/31 1:36:59<br>
&nbsp; &nbsp; OS : Windows 8 Professional [6.2 Build 9200] (x64)<br>
<br>
-----------------------------------------------------------------------<br>
(programme:\)qemu raw image file on SSD Vertex Agility 4:<br>
-----------------------------------------------------------------------<br>
* MB/s =3D 1,000,000 byte/s [SATA/300 =3D 300,000,000 byte/s]<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sequential Read : &nbsp;2086.372 M=
B/s<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sequential Write : &nbsp; 148.418 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Random Read 512KB : &nbsp;1230.134 MB/s<b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; Random Write 512KB : &nbsp; 140.760 MB/s<br>
&nbsp; &nbsp; Random Read 4KB (QD=3D1) : &nbsp; &nbsp;36.603 MB/s [ &nbsp;8=
936.2 IOPS]<br>
&nbsp; &nbsp;Random Write 4KB (QD=3D1) : &nbsp; &nbsp; 6.762 MB/s [ &nbsp;1=
650.9 IOPS]<br>
&nbsp; &nbsp;Random Read 4KB (QD=3D32) : &nbsp; &nbsp;78.257 MB/s [ 19105.8=
 IOPS]<br>
&nbsp; Random Write 4KB (QD=3D32) : &nbsp; &nbsp; 6.946 MB/s [ &nbsp;1695.7=
 IOPS]<br>
<br>
&nbsp; Test : 1000 MB [H: 22.5% (4.9/21.9 GB)] (x5)<br>
&nbsp; Date : 2012/10/31 1:45:31<br>
&nbsp; &nbsp; OS : Windows 8 Professional [6.2 Build 9200] (x64)<br>
<br>
<br>
Regards,<br>
Denis<br>
<br>
______________________________<br>
</span><a style=3D" font-family:'Cambria'; font-size: 11pt;" href=3D"https:=
//biwebco.com/produkte/ispmanager">https://biwebco.com/produkte/ispmanager<=
/a><span style=3D" font-family:'Cambria'; font-size: 11pt;">&nbsp;soon we s=
tart selling of german ISP-manager and other products from ISPsystem.<br>
<br>
<br>
</body></html>
------------0000421733713B7F6--



--===============5166049421930620805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5166049421930620805==--



From xen-devel-bounces@lists.xen.org Mon Feb 25 13:45:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13:45: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 1U9yMF-0003eg-FJ; Mon, 25 Feb 2013 13:44:43 +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 1U9ikH-0005Ht-SL; Sun, 24 Feb 2013 21:04:30 +0000
Received: from [85.158.139.83:53723] by server-15.bemta-5.messagelabs.com id
	20/58-18914-D508A215; Sun, 24 Feb 2013 21:04:29 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361739867!23549157!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2962 invoked from network); 24 Feb 2013 21:04:28 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-7.tower-182.messagelabs.com with SMTP;
	24 Feb 2013 21:04:28 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r1OL3tLL030829;
	Sun, 24 Feb 2013 15:03:55 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id r1OL3tAg030828;
	Sun, 24 Feb 2013 15:03:55 -0600
Date: Sun, 24 Feb 2013 15:03:55 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201302242103.r1OL3tAg030828@wind.enjellic.com>
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	scst-devel@lists.sourceforge.net
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sun, 24 Feb 2013 15:03:55 -0600 (CST)
X-Mailman-Approved-At: Mon, 25 Feb 2013 13:44:41 +0000
Subject: [Xen-devel] Xen-SAN release.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: xen@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

Good afternoon, hope the weekend is going well for everyone.

Izzy the Golden Retriever, on behalf of Enjellic Systems Development,
would like to announce the release of the Xen-SAN system.  This is a
package which provides hotplug support and documentation for allowing
Xen DomU guests to participate as first class initiators in a Storage
Area Network (SAN).

The package can be downloaded from the following URL:

	ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.1.0.tar.gz

This implementation provides support for dynamic creation and
termination of SAN connections at the request of the XL toolstack.
The block devices implemented by these connections are exported by the
blkback interface to the guests.  This allows storage for Xen guests
to be managed as any other initiator in a SAN environment with the
advantage of the guest requiring no knowledge of SAN implementation
mechanics.

Due to interest in the package and development and testing deadlines
this release contains support only for iSCSI initiators.  NPIV support
for fibre-channel SAN's is under testing and will be included in a
subsequent release.

The package has been tested extensively with the following components:

        Xen 4.2.1
        open-iscsi 2.0.873
        kernel.org Linux 3.4.x Dom0/DomU
        SCST 2.2.x target implementation

The goal of the sub-system is to operate as standalone hotplug
scripts.  A small modification is required to extend lock coverage in
the 'block' script.  A modified 'block' script, which has been tested
to function identically to the script released with the Xen sources,
is included.  This package WILL NOT function properly with the default
script.

Since development in and function of the Linux/Xen hotplug environment
is best described as 'intrigueing' we are interested in feedback on
issues which may exist outside our customized storage and
virtualization environment.  Due to the complexity of the sub-systems
involved users are STRONGLY recommended to review the included
documentation.

We hope the open-storage and virtualization communities find this to
be a useful contribution to the eco-system.

Greg and Izzy

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
------------------------------------------------------------------------------
"Don't worry about people stealing your ideas.  If your ideas are any
 good, you'll have to ram them down people's throats."
                                -- Howard Aiken

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 13:45:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 13:45: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 1U9yMF-0003eg-FJ; Mon, 25 Feb 2013 13:44:43 +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 1U9ikH-0005Ht-SL; Sun, 24 Feb 2013 21:04:30 +0000
Received: from [85.158.139.83:53723] by server-15.bemta-5.messagelabs.com id
	20/58-18914-D508A215; Sun, 24 Feb 2013 21:04:29 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361739867!23549157!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2962 invoked from network); 24 Feb 2013 21:04:28 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-7.tower-182.messagelabs.com with SMTP;
	24 Feb 2013 21:04:28 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r1OL3tLL030829;
	Sun, 24 Feb 2013 15:03:55 -0600
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id r1OL3tAg030828;
	Sun, 24 Feb 2013 15:03:55 -0600
Date: Sun, 24 Feb 2013 15:03:55 -0600
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201302242103.r1OL3tAg030828@wind.enjellic.com>
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	scst-devel@lists.sourceforge.net
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sun, 24 Feb 2013 15:03:55 -0600 (CST)
X-Mailman-Approved-At: Mon, 25 Feb 2013 13:44:41 +0000
Subject: [Xen-devel] Xen-SAN release.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: xen@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

Good afternoon, hope the weekend is going well for everyone.

Izzy the Golden Retriever, on behalf of Enjellic Systems Development,
would like to announce the release of the Xen-SAN system.  This is a
package which provides hotplug support and documentation for allowing
Xen DomU guests to participate as first class initiators in a Storage
Area Network (SAN).

The package can be downloaded from the following URL:

	ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.1.0.tar.gz

This implementation provides support for dynamic creation and
termination of SAN connections at the request of the XL toolstack.
The block devices implemented by these connections are exported by the
blkback interface to the guests.  This allows storage for Xen guests
to be managed as any other initiator in a SAN environment with the
advantage of the guest requiring no knowledge of SAN implementation
mechanics.

Due to interest in the package and development and testing deadlines
this release contains support only for iSCSI initiators.  NPIV support
for fibre-channel SAN's is under testing and will be included in a
subsequent release.

The package has been tested extensively with the following components:

        Xen 4.2.1
        open-iscsi 2.0.873
        kernel.org Linux 3.4.x Dom0/DomU
        SCST 2.2.x target implementation

The goal of the sub-system is to operate as standalone hotplug
scripts.  A small modification is required to extend lock coverage in
the 'block' script.  A modified 'block' script, which has been tested
to function identically to the script released with the Xen sources,
is included.  This package WILL NOT function properly with the default
script.

Since development in and function of the Linux/Xen hotplug environment
is best described as 'intrigueing' we are interested in feedback on
issues which may exist outside our customized storage and
virtualization environment.  Due to the complexity of the sub-systems
involved users are STRONGLY recommended to review the included
documentation.

We hope the open-storage and virtualization communities find this to
be a useful contribution to the eco-system.

Greg and Izzy

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
------------------------------------------------------------------------------
"Don't worry about people stealing your ideas.  If your ideas are any
 good, you'll have to ram them down people's throats."
                                -- Howard Aiken

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:34:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14: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 1U9z8S-00056C-4a; Mon, 25 Feb 2013 14:34: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 1U9z8Q-000567-QQ
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 14:34:30 +0000
Received: from [193.109.254.147:42421] by server-10.bemta-14.messagelabs.com
	id 92/C8-12679-6767B215; Mon, 25 Feb 2013 14:34:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361802815!9600917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10195 invoked from network); 25 Feb 2013 14:33:35 -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; 25 Feb 2013 14:33:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 14:33:34 +0000
Message-Id: <512B844C02000078000C0C75@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 14:33:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] XENMEM_maximum_gpfn return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 coming from a shared info field, it has to be assumed to possibly
have any value. In particular, our kernels don't set up this field at all
if running as Dom0 and kexec isn't enabled (along with not setting up
the P2M frame lists, as that's simply wasted memory in that case).

So, with this being a guest provided value, we apparently have two
problems: do_memory_op()'s "rc" variable is only of type "int", thus
potentially truncating the result of domain_get_maximum_gpfn()
(considering that we now support 16Tb, an 8Tb+ guest ought to
be possible, and such would have a max GPFN with 32 significant
bits). And zero or a very large number being returned by the latter
will generally be mistaken as an error code by the caller of the
hypercall.

So, along with promoting "rc" to long, I'm considering enforcing a
sane lower bound on domain_get_maximum_gpfn()'s return value,
using d->tot_pages (under the assumption that each page would
have a representation in the physical map, and hence the
physical map can't reasonably be smaller than this). That would
overcome the subtraction of 1 done there for PV guests to
convert 0 to -1 (i.e. -EPERM). Similarly, a sane upper bound
ought to be enforced (to avoid collisions with the -E range).

Other thoughts? Is such a behavioral change acceptable for an
existing interface?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:34:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14: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 1U9z8S-00056C-4a; Mon, 25 Feb 2013 14:34: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 1U9z8Q-000567-QQ
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 14:34:30 +0000
Received: from [193.109.254.147:42421] by server-10.bemta-14.messagelabs.com
	id 92/C8-12679-6767B215; Mon, 25 Feb 2013 14:34:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361802815!9600917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10195 invoked from network); 25 Feb 2013 14:33:35 -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; 25 Feb 2013 14:33:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 14:33:34 +0000
Message-Id: <512B844C02000078000C0C75@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 14:33:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] XENMEM_maximum_gpfn return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 coming from a shared info field, it has to be assumed to possibly
have any value. In particular, our kernels don't set up this field at all
if running as Dom0 and kexec isn't enabled (along with not setting up
the P2M frame lists, as that's simply wasted memory in that case).

So, with this being a guest provided value, we apparently have two
problems: do_memory_op()'s "rc" variable is only of type "int", thus
potentially truncating the result of domain_get_maximum_gpfn()
(considering that we now support 16Tb, an 8Tb+ guest ought to
be possible, and such would have a max GPFN with 32 significant
bits). And zero or a very large number being returned by the latter
will generally be mistaken as an error code by the caller of the
hypercall.

So, along with promoting "rc" to long, I'm considering enforcing a
sane lower bound on domain_get_maximum_gpfn()'s return value,
using d->tot_pages (under the assumption that each page would
have a representation in the physical map, and hence the
physical map can't reasonably be smaller than this). That would
overcome the subtraction of 1 done there for PV guests to
convert 0 to -1 (i.e. -EPERM). Similarly, a sane upper bound
ought to be enforced (to avoid collisions with the -E range).

Other thoughts? Is such a behavioral change acceptable for an
existing interface?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:37:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14:37: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 1U9zAt-0005Bb-Mu; Mon, 25 Feb 2013 14:37:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1U9zAr-0005BV-B9
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 14:37:02 +0000
Received: from [193.109.254.147:18605] by server-4.bemta-14.messagelabs.com id
	76/5C-20719-C077B215; Mon, 25 Feb 2013 14:37:00 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361803002!2381740!1
X-Originating-IP: [209.85.220.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31452 invoked from network); 25 Feb 2013 14:36:44 -0000
Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com)
	(209.85.220.47)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 14:36:44 -0000
Received: by mail-pa0-f47.google.com with SMTP id bj3so1779014pad.6
	for <xen-devel@lists.xensource.com>;
	Mon, 25 Feb 2013 06:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=e66p/8wD1g72V54nWo59wr3ScUKjqgpqrRWKPxVSw+8=;
	b=dtn7QgtJkmJrkpIOlT5MFfFRVeg1ViyWXUrE7f7fNPEf2NyftZCl44i9qIMGN62Wqe
	uCC3VODRm6Sk46txjJD9oE1vwHwBPcUYnK89GX10jZX5BxYnpvWFbeRG9yNgyiyFvMds
	T716YRTlL+JxHk3xS8C9jPLoezQTzxAGgjtfI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-gm-message-state;
	bh=e66p/8wD1g72V54nWo59wr3ScUKjqgpqrRWKPxVSw+8=;
	b=NPP+fo9dWnQgLdVkE7IbJ6EdvQd53E6ZlV+aW5QBNafbYstNh1G3wv4TpPqKEsEE7A
	D9B6vPlMiBemJKv0+LxvOpbyKqUc9eS17kQ52leyhzJMz7x1Yhw1cFx5Yzd+OjZYOnxT
	UMIFci99Jym9T0ZUYaTquTK5NGcCU9+576IvN1BL3ziZ5nyDCDoEWghu6qcoeGKNfzmP
	HiALs5QfQd4yD1QBrbNBp7r7SYlCAw54kK5iIFTWuJstJjAhJdr+73xDvtCSXn84sFFH
	M/y1rtsEpobaLQNJ3a57PI1ZQZv/GcyUrCelLmMwFtSOZb7gSKnEgmxLwaqK+MaAcDdm
	RPqA==
X-Received: by 10.68.116.169 with SMTP id jx9mr18112599pbb.94.1361803001589;
	Mon, 25 Feb 2013 06:36:41 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id eh5sm12912583pbc.44.2013.02.25.06.36.39
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 06:36:40 -0800 (PST)
Date: Mon, 25 Feb 2013 06:37:30 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130225143730.GC14007@kroah.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
	<20130224144017.GB1111@kroah.com>
	<alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQnthf9EaGAN6/JNnHAv0zZm2ftChMx8MIUkVIITbIgsLvUSB22q3dxpaIY1uWdWctAVPi9m
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Kees Cook <keescook@chromium.org>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 12:39:27PM +0000, Stefano Stabellini wrote:
> On Sun, 24 Feb 2013, Greg Kroah-Hartman wrote:
> > 
> > You should not have unstable options in the kernel in the first place,
> > sorry.
>  
> With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
> for me personally or my work, I am going to give you my 2 cents on the
> matter, but feel free to ignore them :)
> 
> While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
> rejecting everything that is not fully stable and with external
> interfaces set in stones, might hinder the development of new features.

It's been this way for _years_ this isn't something new (the "you have
to get it right really quickly" problem).  See Documentation/ABI/ for
some words about how you can try to do this.

> After all, given how fast the kernel is moving nowadays,

No faster than it has in the past.

> maintaining a project out-of-tree until is completely ready for
> production can be very expensive. Merging the project earlier and
> completing the development upstream can bring better results.

Yes, but don't go changing user-visable apis when you do so.  That's
been a hard rule for a LONG time.

> But in these cases one wouldn't want to "market" the feature as stable
> yet, because it just isn't. If CONFIG_EXPERIMENTAL is going away, is
> there anything in the kernel that can be used to tag a feature as "I
> wouldn't use it in production if I were you"? Maybe just a comment in
> the kconfig description?

I know this is hard, I've had my own problems with it in the past.  You
don't know if you get an api right until you have a lot of users.  See
our previous "discussions" about this topic on lkml if you are curious
as to the eventual outcome of threads like this:

	Yes, it's hard, but that's kernel programming.

Sorry,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:37:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14:37: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 1U9zAt-0005Bb-Mu; Mon, 25 Feb 2013 14:37:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1U9zAr-0005BV-B9
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 14:37:02 +0000
Received: from [193.109.254.147:18605] by server-4.bemta-14.messagelabs.com id
	76/5C-20719-C077B215; Mon, 25 Feb 2013 14:37:00 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361803002!2381740!1
X-Originating-IP: [209.85.220.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31452 invoked from network); 25 Feb 2013 14:36:44 -0000
Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com)
	(209.85.220.47)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 14:36:44 -0000
Received: by mail-pa0-f47.google.com with SMTP id bj3so1779014pad.6
	for <xen-devel@lists.xensource.com>;
	Mon, 25 Feb 2013 06:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=e66p/8wD1g72V54nWo59wr3ScUKjqgpqrRWKPxVSw+8=;
	b=dtn7QgtJkmJrkpIOlT5MFfFRVeg1ViyWXUrE7f7fNPEf2NyftZCl44i9qIMGN62Wqe
	uCC3VODRm6Sk46txjJD9oE1vwHwBPcUYnK89GX10jZX5BxYnpvWFbeRG9yNgyiyFvMds
	T716YRTlL+JxHk3xS8C9jPLoezQTzxAGgjtfI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-gm-message-state;
	bh=e66p/8wD1g72V54nWo59wr3ScUKjqgpqrRWKPxVSw+8=;
	b=NPP+fo9dWnQgLdVkE7IbJ6EdvQd53E6ZlV+aW5QBNafbYstNh1G3wv4TpPqKEsEE7A
	D9B6vPlMiBemJKv0+LxvOpbyKqUc9eS17kQ52leyhzJMz7x1Yhw1cFx5Yzd+OjZYOnxT
	UMIFci99Jym9T0ZUYaTquTK5NGcCU9+576IvN1BL3ziZ5nyDCDoEWghu6qcoeGKNfzmP
	HiALs5QfQd4yD1QBrbNBp7r7SYlCAw54kK5iIFTWuJstJjAhJdr+73xDvtCSXn84sFFH
	M/y1rtsEpobaLQNJ3a57PI1ZQZv/GcyUrCelLmMwFtSOZb7gSKnEgmxLwaqK+MaAcDdm
	RPqA==
X-Received: by 10.68.116.169 with SMTP id jx9mr18112599pbb.94.1361803001589;
	Mon, 25 Feb 2013 06:36:41 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id eh5sm12912583pbc.44.2013.02.25.06.36.39
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 06:36:40 -0800 (PST)
Date: Mon, 25 Feb 2013 06:37:30 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130225143730.GC14007@kroah.com>
References: <20130223072959.GA4894@www.outflux.net>
	<CAE8XmWoX_TyHMTnGCMn6j_qiK0hptCgyrnVYpDJkfTAQfUNQPA@mail.gmail.com>
	<CAGXu5jKkaTStWRDQLOb6HxM7sGyj+1ekxxkGK8hw6rWkHRrVsQ@mail.gmail.com>
	<CAE8XmWq+dA5Pvhyoxm2Nqbt0psLpPxUdR7i5MKFhxVxubY0QtQ@mail.gmail.com>
	<20130224144017.GB1111@kroah.com>
	<alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302251157210.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQnthf9EaGAN6/JNnHAv0zZm2ftChMx8MIUkVIITbIgsLvUSB22q3dxpaIY1uWdWctAVPi9m
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Dongsheng Song <dongsheng.song@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Kees Cook <keescook@chromium.org>
Subject: Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 12:39:27PM +0000, Stefano Stabellini wrote:
> On Sun, 24 Feb 2013, Greg Kroah-Hartman wrote:
> > 
> > You should not have unstable options in the kernel in the first place,
> > sorry.
>  
> With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
> for me personally or my work, I am going to give you my 2 cents on the
> matter, but feel free to ignore them :)
> 
> While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
> rejecting everything that is not fully stable and with external
> interfaces set in stones, might hinder the development of new features.

It's been this way for _years_ this isn't something new (the "you have
to get it right really quickly" problem).  See Documentation/ABI/ for
some words about how you can try to do this.

> After all, given how fast the kernel is moving nowadays,

No faster than it has in the past.

> maintaining a project out-of-tree until is completely ready for
> production can be very expensive. Merging the project earlier and
> completing the development upstream can bring better results.

Yes, but don't go changing user-visable apis when you do so.  That's
been a hard rule for a LONG time.

> But in these cases one wouldn't want to "market" the feature as stable
> yet, because it just isn't. If CONFIG_EXPERIMENTAL is going away, is
> there anything in the kernel that can be used to tag a feature as "I
> wouldn't use it in production if I were you"? Maybe just a comment in
> the kconfig description?

I know this is hard, I've had my own problems with it in the past.  You
don't know if you get an api right until you have a lot of users.  See
our previous "discussions" about this topic on lkml if you are curious
as to the eventual outcome of threads like this:

	Yes, it's hard, but that's kernel programming.

Sorry,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:40:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14:40: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 1U9zDk-0005MF-HP; Mon, 25 Feb 2013 14:40: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 1U9zDj-0005M6-EZ
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 14:39:59 +0000
Received: from [85.158.139.211:23576] by server-9.bemta-5.messagelabs.com id
	5F/31-08547-EB77B215; Mon, 25 Feb 2013 14:39:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361802767!15156305!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19039 invoked from network); 25 Feb 2013 14:32:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 14:32:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1844517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 14:32: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.297.1; Mon, 25 Feb 2013 14:32:46 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9z6k-0007wr-R0;
	Mon, 25 Feb 2013 14:32:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9z6k-0000Mp-QQ;
	Mon, 25 Feb 2013 14:32:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16568-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 14:32:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16568: 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 16568 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16568/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 16232
 test-i386-i386-pv             5 xen-boot                    fail pass in 16436
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 16436
 test-i386-i386-pair           8 xen-boot/dst_host           fail pass in 16436
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16232 pass in 16568
 test-i386-i386-xl-qemut-win   3 host-install(3)  broken in 16232 pass in 16568
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 16436 pass in 16568
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 16436 pass in 16568

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-qemut-win    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-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 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                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:40:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14:40: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 1U9zDk-0005MF-HP; Mon, 25 Feb 2013 14:40: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 1U9zDj-0005M6-EZ
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 14:39:59 +0000
Received: from [85.158.139.211:23576] by server-9.bemta-5.messagelabs.com id
	5F/31-08547-EB77B215; Mon, 25 Feb 2013 14:39:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361802767!15156305!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19039 invoked from network); 25 Feb 2013 14:32:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 14:32:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1844517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 14:32: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.297.1; Mon, 25 Feb 2013 14:32:46 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1U9z6k-0007wr-R0;
	Mon, 25 Feb 2013 14:32:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1U9z6k-0000Mp-QQ;
	Mon, 25 Feb 2013 14:32:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16568-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 14:32:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16568: 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 16568 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16568/

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. 16228
 test-i386-i386-xl-qemuu-winxpsp3  5 xen-boot              fail REGR. vs. 16228
 test-i386-i386-win            5 xen-boot                  fail REGR. vs. 16228
 test-i386-i386-xl-winxpsp3    5 xen-boot                  fail REGR. vs. 16228

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     11 guest-localmigrate          fail pass in 16232
 test-i386-i386-pv             5 xen-boot                    fail pass in 16436
 test-i386-i386-pair           7 xen-boot/src_host           fail pass in 16436
 test-i386-i386-pair           8 xen-boot/dst_host           fail pass in 16436
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16232 pass in 16568
 test-i386-i386-xl-qemut-win   3 host-install(3)  broken in 16232 pass in 16568
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 16436 pass in 16568
 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 16436 pass in 16568

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-qemut-win    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-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6f0f339dd4378d062a211969f45cd23af12bf386
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jim Fehlig <jfehlig@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 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                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 6f0f339dd4378d062a211969f45cd23af12bf386
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Wed Jan 23 16:53:11 2013 +0000

    libxl: fix stale timeout event callback race
    
    Because there is not necessarily any lock held at the point the
    application (eg, libvirt) calls libxl_osevent_occurred_timeout, in a
    multithreaded program those calls may be arbitrarily delayed in
    relation to other activities within the program.
    
    Specifically this means when ->timeout_deregister returns, libxl does
    not know whether it can safely dispose of the for_libxl value or
    whether it needs to retain it in case of an in-progress call to
    _occurred_timeout.
    
    The interface could be fixed by requiring the application to make a
    new call into libxl to say that the deregistration was complete.
    
    However that new call would have to be threaded through the
    application's event loop; this is complicated and some application
    authors are likely not to implement it properly.  Furthermore the
    easiest way to implement this facility in most event loops is to queue
    up a time event for "now".
    
    Shortcut all of this by having libxl always call timeout_modify
    setting abs={0,0} (ie, ASAP) instead of timeout_deregister.  This will
    cause the application to call _occurred_timeout.  When processing this
    calldown we see that we were no longer actually interested and simply
    throw it away.
    
    Additionally, there is a race between _occurred_timeout and
    ->timeout_modify.  If libxl ever adjusts the deadline for a timeout
    the application may already be in the process of calling _occurred, in
    which case the situation with for_app's lifetime becomes very
    complicated.  Therefore abolish libxl__ev_time_modify_{abs,rel} (which
    have no callers) and promise to the application only ever to call
    ->timeout_modify with abs=={0,0}.  The application still needs to cope
    with ->timeout_modify racing with its internal function which calls
    _occurred_timeout.  Document this.
    
    This is a forwards-compatible change for applications using the libxl
    API, and will hopefully eliminate these races in callback-supplying
    applications (such as libvirt) without the need for corresponding
    changes to the application.  (It is possible that this might expose
    bugs in applications, though, as previously libxl would never call
    libxl_osevent_hooks->timeout_modify and now it never calls
    ->timeout_deregister).
    
    For clarity, fold the body of time_register_finite into its one
    remaining call site.  This makes the semantics of ev->infinite
    slightly clearer.
    
    Cc: Bamvor Jian Zhang <bjzhang@suse.com>
    Cc: Ian Campbell <Ian.Campbell@citrix.com>
    Tested-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Jim Fehlig <jfehlig@suse.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:53:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14: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 1U9zQD-00068v-07; Mon, 25 Feb 2013 14:52:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1U9zQB-00068p-Fg
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 14:52:51 +0000
Received: from [85.158.139.83:22632] by server-15.bemta-5.messagelabs.com id
	55/AF-22815-2CA7B215; Mon, 25 Feb 2013 14:52:50 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361803968!27050517!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25174 invoked from network); 25 Feb 2013 14:52:49 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 14:52:49 -0000
Received: by mail-ia0-f173.google.com with SMTP id h37so2516966iak.4
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 06:52:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=ZHwC4dKV8UCPqIMnjsZGlE4gspbImXXVR6Nt/X1dLJs=;
	b=JZoIYPKdYH7IaLf+sli2BjPK+cK0qjQaTzPJFRWi+ymfWVzOlCJ/D2yH8ValEkGPu5
	oBQUWowDB8FLmvHFN8dRkwPq8gLQD77uUBq8e/F4o4t4BxhP9kuhvWBUiLyBloJYykq1
	AS7m9d0c2pdea0pbD66NtedmMf0O3eFpMJkJYyyx8zGESzhnYBln4u8rT3QLLnyb/dpJ
	sCms1KEfNNE2bqRiLEXvd9jXux9F56QCzbsId+m6o+6dH03yEyQEHSh8jmErWcg0zbpu
	+MCLtuGl7LgmN0kkaHfH/QifaRe0oTuG/jQEiZT7jgK6ppC8lsnR1bzPfa3gdlbjO7ev
	BxLw==
X-Received: by 10.42.66.74 with SMTP id o10mr2155391ici.30.1361803968166;
	Mon, 25 Feb 2013 06:52:48 -0800 (PST)
Received: from [192.168.15.1] ([206.223.182.18])
	by mx.google.com with ESMTPS id wo8sm5457653igb.6.2013.02.25.06.52.45
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 06:52:46 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
Date: Mon, 25 Feb 2013 09:52:46 -0500
Message-Id: <0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm2Ajp9HWwU8/0cHV6ncVlze4fXDrVvzn/8ExMVmczHTPe1hv4zQgR8SIrK9UqIRfqwUZa3
Cc: Olaf Hering <olaf@aepfle.de>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 22.02.13 at 21:07, Olaf Hering <olaf@aepfle.de> wrote:
>> On Fri, Feb 22, Jan Beulich wrote:
>> 
>>>>>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
>>>> It did not happen with xl.
>>> 
>>> But the same guest and Dom0 kernel, and the same hypervisor?
>> 
>> Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.
>> 
>>>> Here is the output while doing xm migrate:
>>>> 
>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>> (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, 
>> od=0000000000000000, caf=180000000000000, taf=7400000000000001
>>> 
>>> Didn't even notice yesterday that this is apparently after restore
>>> has already started. Which makes me curious whether the domain
>>> that is being referenced with rd= is the old or the new one (would
>>> require printing the domain ID; honestly I never understood what
>>> use printing of the domain pointer is).
>>> 
>>> I'm also confused by the domain pointer always being the same;
>>> I would expect it to at least toggle between two values, but
>>> probably even be different between every instance of the guest.
>>> But you're not having a stubdom configured for the guest either,
>>> according to the config you sent earlier...
>> 
>> The rd->domain_id is DOMID_COW in both cases.
> 
> Which suggests that memory sharing is in use. At least I'm unaware
> of other uses of that pseudo domain.

There are none.

There seems to be something else amiss though. Unless I am parsing this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT | PCD? Looks like a very unlikely combination

Andres
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 14:53:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 14: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 1U9zQD-00068v-07; Mon, 25 Feb 2013 14:52:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1U9zQB-00068p-Fg
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 14:52:51 +0000
Received: from [85.158.139.83:22632] by server-15.bemta-5.messagelabs.com id
	55/AF-22815-2CA7B215; Mon, 25 Feb 2013 14:52:50 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361803968!27050517!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25174 invoked from network); 25 Feb 2013 14:52:49 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 14:52:49 -0000
Received: by mail-ia0-f173.google.com with SMTP id h37so2516966iak.4
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 06:52:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=ZHwC4dKV8UCPqIMnjsZGlE4gspbImXXVR6Nt/X1dLJs=;
	b=JZoIYPKdYH7IaLf+sli2BjPK+cK0qjQaTzPJFRWi+ymfWVzOlCJ/D2yH8ValEkGPu5
	oBQUWowDB8FLmvHFN8dRkwPq8gLQD77uUBq8e/F4o4t4BxhP9kuhvWBUiLyBloJYykq1
	AS7m9d0c2pdea0pbD66NtedmMf0O3eFpMJkJYyyx8zGESzhnYBln4u8rT3QLLnyb/dpJ
	sCms1KEfNNE2bqRiLEXvd9jXux9F56QCzbsId+m6o+6dH03yEyQEHSh8jmErWcg0zbpu
	+MCLtuGl7LgmN0kkaHfH/QifaRe0oTuG/jQEiZT7jgK6ppC8lsnR1bzPfa3gdlbjO7ev
	BxLw==
X-Received: by 10.42.66.74 with SMTP id o10mr2155391ici.30.1361803968166;
	Mon, 25 Feb 2013 06:52:48 -0800 (PST)
Received: from [192.168.15.1] ([206.223.182.18])
	by mx.google.com with ESMTPS id wo8sm5457653igb.6.2013.02.25.06.52.45
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 06:52:46 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
Date: Mon, 25 Feb 2013 09:52:46 -0500
Message-Id: <0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm2Ajp9HWwU8/0cHV6ncVlze4fXDrVvzn/8ExMVmczHTPe1hv4zQgR8SIrK9UqIRfqwUZa3
Cc: Olaf Hering <olaf@aepfle.de>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 22.02.13 at 21:07, Olaf Hering <olaf@aepfle.de> wrote:
>> On Fri, Feb 22, Jan Beulich wrote:
>> 
>>>>>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
>>>> It did not happen with xl.
>>> 
>>> But the same guest and Dom0 kernel, and the same hypervisor?
>> 
>> Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.
>> 
>>>> Here is the output while doing xm migrate:
>>>> 
>>>> (XEN) HVM2 restore: VMCE_VCPU 0
>>>> (XEN) HVM2 restore: VMCE_VCPU 1
>>>> (XEN) HVM2 restore: TSC_ADJUST 0
>>>> (XEN) HVM2 restore: TSC_ADJUST 1
>>>> (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, 
>> od=0000000000000000, caf=180000000000000, taf=7400000000000001
>>> 
>>> Didn't even notice yesterday that this is apparently after restore
>>> has already started. Which makes me curious whether the domain
>>> that is being referenced with rd= is the old or the new one (would
>>> require printing the domain ID; honestly I never understood what
>>> use printing of the domain pointer is).
>>> 
>>> I'm also confused by the domain pointer always being the same;
>>> I would expect it to at least toggle between two values, but
>>> probably even be different between every instance of the guest.
>>> But you're not having a stubdom configured for the guest either,
>>> according to the config you sent earlier...
>> 
>> The rd->domain_id is DOMID_COW in both cases.
> 
> Which suggests that memory sharing is in use. At least I'm unaware
> of other uses of that pseudo domain.

There are none.

There seems to be something else amiss though. Unless I am parsing this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT | PCD? Looks like a very unlikely combination

Andres
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 15:40:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15:40: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 1UA09Y-00083H-C8; Mon, 25 Feb 2013 15:39: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 1UA09X-000838-6R
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:39:43 +0000
Received: from [85.158.143.99:12453] by server-2.bemta-4.messagelabs.com id
	26/5C-12656-EB58B215; Mon, 25 Feb 2013 15:39:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361806782!28173312!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12853 invoked from network); 25 Feb 2013 15:39:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1848164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 15:38: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.297.1;
	Mon, 25 Feb 2013 15:38:41 +0000
Message-ID: <1361806720.26546.188.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xudong Hao <xudong.hao@intel.com>
Date: Mon, 25 Feb 2013 15:38:40 +0000
In-Reply-To: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] piix: define a TOM register to report
 the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 06:53 +0000, Xudong Hao wrote:
> v2:
> * Use "piix: " in the subject rather than "qemu: "
> * Define TOM register as one byte
> * Define default TOM value instead of hardcode 0xe0000000 in more that one place
> * Use API pci_set_byte for pci config access
> * Use dev->config instead of the indirect d->dev.config
> 
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically. TOM register are defined to one byte in PCI configure
> space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> it requires bios set TOM with 16M-aligned.

Is it really OK to just add registers to the PIIX like this? This is
supposed to be emulating an actual real life device after all.

Perhaps an HVM param or some other out of band mechanism would be better
here?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 15:40:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15:40: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 1UA09Y-00083H-C8; Mon, 25 Feb 2013 15:39: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 1UA09X-000838-6R
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:39:43 +0000
Received: from [85.158.143.99:12453] by server-2.bemta-4.messagelabs.com id
	26/5C-12656-EB58B215; Mon, 25 Feb 2013 15:39:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361806782!28173312!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12853 invoked from network); 25 Feb 2013 15:39:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1848164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 15:38: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.297.1;
	Mon, 25 Feb 2013 15:38:41 +0000
Message-ID: <1361806720.26546.188.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xudong Hao <xudong.hao@intel.com>
Date: Mon, 25 Feb 2013 15:38:40 +0000
In-Reply-To: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] piix: define a TOM register to report
 the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 06:53 +0000, Xudong Hao wrote:
> v2:
> * Use "piix: " in the subject rather than "qemu: "
> * Define TOM register as one byte
> * Define default TOM value instead of hardcode 0xe0000000 in more that one place
> * Use API pci_set_byte for pci config access
> * Use dev->config instead of the indirect d->dev.config
> 
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically. TOM register are defined to one byte in PCI configure
> space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> it requires bios set TOM with 16M-aligned.

Is it really OK to just add registers to the PIIX like this? This is
supposed to be emulating an actual real life device after all.

Perhaps an HVM param or some other out of band mechanism would be better
here?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 15:42:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15:42: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 1UA0Bm-0008Nu-U5; Mon, 25 Feb 2013 15:42: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 1UA0Bm-0008Nk-4O
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:42:02 +0000
Received: from [85.158.137.99:26581] by server-10.bemta-3.messagelabs.com id
	3B/C6-10609-9468B215; Mon, 25 Feb 2013 15:42:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361806600!17264380!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2592 invoked from network); 25 Feb 2013 15:36:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:36:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9405332"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 15:36:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 10:36:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9zwR-0000j4-8w;
	Mon, 25 Feb 2013 15:26:11 +0000
Date: Mon, 25 Feb 2013 15:26:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302251524260.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
> > At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> > > On Fri, 22 Feb 2013, AP wrote:
> > > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> > > > >
> > > > >
> > > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > >
> > > > >> I think it could still be very useful to many people. If not on the
> > > > >> xen-unstable repository, it should still be published somewhere.
> > > > >> Maybe a link on the wiki or a blog article?
> > > > >
> > > > >
> > > > > I'm happy to tidy it up a bit if people think it is useful, and publish
> > > > > it wherever. From memory the impact on the main code base is a 3 line
> > > > > change to the Makefile, and doubtless I could minimise the other files
> > > > > too.
> > > > 
> > > > This would be very useful for people trying to create their own
> > > > minimal Xen image. I have been struggling with this for the past few
> > > > days.
> > > > 
> > > > http://xen.markmail.org/thread/dac5kkuliky5373l
> > > 
> > > If there is a need for it and clearly the upstream Debian maintainers
> > > don't care either way, why shouldn't we add the minideb target to our
> > > own build system? If we are going to have a deb target anyway, we might
> > > as well make it a useful one...
> > 
> > Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> > Debian/Ubuntu.  That would be much more widely useful, for a similar
> > amount of effort.
> 
> 4.2.0 is already in Debian experimental.

There might be many reasons why one would want to roll his own packages
rather than using a distro package.
Given that we already have a deb target, it doesn't cost as much to add
a second one, that is actually useful.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 15:42:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15:42: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 1UA0Bm-0008Nu-U5; Mon, 25 Feb 2013 15:42: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 1UA0Bm-0008Nk-4O
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:42:02 +0000
Received: from [85.158.137.99:26581] by server-10.bemta-3.messagelabs.com id
	3B/C6-10609-9468B215; Mon, 25 Feb 2013 15:42:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361806600!17264380!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2592 invoked from network); 25 Feb 2013 15:36:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:36:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9405332"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 15:36:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 10:36:06 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1U9zwR-0000j4-8w;
	Mon, 25 Feb 2013 15:26:11 +0000
Date: Mon, 25 Feb 2013 15:26:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302251524260.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Ian Campbell wrote:
> On Mon, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
> > At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> > > On Fri, 22 Feb 2013, AP wrote:
> > > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> > > > >
> > > > >
> > > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> > > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > >
> > > > >> I think it could still be very useful to many people. If not on the
> > > > >> xen-unstable repository, it should still be published somewhere.
> > > > >> Maybe a link on the wiki or a blog article?
> > > > >
> > > > >
> > > > > I'm happy to tidy it up a bit if people think it is useful, and publish
> > > > > it wherever. From memory the impact on the main code base is a 3 line
> > > > > change to the Makefile, and doubtless I could minimise the other files
> > > > > too.
> > > > 
> > > > This would be very useful for people trying to create their own
> > > > minimal Xen image. I have been struggling with this for the past few
> > > > days.
> > > > 
> > > > http://xen.markmail.org/thread/dac5kkuliky5373l
> > > 
> > > If there is a need for it and clearly the upstream Debian maintainers
> > > don't care either way, why shouldn't we add the minideb target to our
> > > own build system? If we are going to have a deb target anyway, we might
> > > as well make it a useful one...
> > 
> > Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> > Debian/Ubuntu.  That would be much more widely useful, for a similar
> > amount of effort.
> 
> 4.2.0 is already in Debian experimental.

There might be many reasons why one would want to roll his own packages
rather than using a distro package.
Given that we already have a deb target, it doesn't cost as much to add
a second one, that is actually useful.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 15:44:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15: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 1UA0Dc-0000DJ-Ec; Mon, 25 Feb 2013 15:43:56 +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 1UA0Db-0000DB-F0
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 15:43:55 +0000
Received: from [85.158.139.83:32287] by server-14.bemta-5.messagelabs.com id
	30/9D-13158-AB68B215; Mon, 25 Feb 2013 15:43:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361807013!28879083!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9156 invoked from network); 25 Feb 2013 15:43:34 -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;
	25 Feb 2013 15:43:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8944931"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 15:43:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 10:43:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA0DD-00016l-6T;
	Mon, 25 Feb 2013 15:43:31 +0000
Date: Mon, 25 Feb 2013 15:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: jacek burghardt <jaceksburghardt@gmail.com>
In-Reply-To: <CAHyyzzSddetdReODcxE3tM2Lz4NhRoc+m_VOxBe-kToRJViKrw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302251531250.5360@kaball.uk.xensource.com>
References: <CAHyyzzSddetdReODcxE3tM2Lz4NhRoc+m_VOxBe-kToRJViKrw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1342847746-443108974-1361807008=:5360"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen hvm fails to 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-443108974-1361807008=:5360
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sun, 24 Feb 2013, jacek burghardt wrote:
> When I try to start hvm qemu-xen I get this error It seems that the path =
my be off. Can someone point me were in source code path
> to qemu pid is defined .It seems that qeum-xen points to loacation I don'=
t see were it is defined.=C2=A0
> xc: detail: elf_load_binary: phdr 0 at 0x0x7f71cac72000 -> 0x0x7f71cad079=
d5
> libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed
> libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)buil=
d domain: -3
> libxl: error: libxl_dm.c:1250:libxl__destroy_device_model: could not find=
 device-model's pid for dom 14
> libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_mo=
del failed for 14
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x1bcc300: comple=
te, rc=3D-3
> libxl: debug: libxl_create.c:1227:do_domain_create: ao 0x1bcc300: inprogr=
ess: poller=3D0x1bccf70, flags=3Dic
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x1bcc300: destro=
y
> xc: debug: hypercall buffer: total allocations:1166 total releases:1166
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:1158 misses:4 toobig:4

Maybe there isn't enough free memory in your system?

In any case by default qemu-xen lives in /usr/lib/xen/bin, the binary
name is qemu-system-i386.
--1342847746-443108974-1361807008=:5360
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-443108974-1361807008=:5360--


From xen-devel-bounces@lists.xen.org Mon Feb 25 15:44:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15: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 1UA0Dc-0000DJ-Ec; Mon, 25 Feb 2013 15:43:56 +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 1UA0Db-0000DB-F0
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 15:43:55 +0000
Received: from [85.158.139.83:32287] by server-14.bemta-5.messagelabs.com id
	30/9D-13158-AB68B215; Mon, 25 Feb 2013 15:43:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361807013!28879083!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9156 invoked from network); 25 Feb 2013 15:43:34 -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;
	25 Feb 2013 15:43:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8944931"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 15:43:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 10:43:31 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA0DD-00016l-6T;
	Mon, 25 Feb 2013 15:43:31 +0000
Date: Mon, 25 Feb 2013 15:43:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: jacek burghardt <jaceksburghardt@gmail.com>
In-Reply-To: <CAHyyzzSddetdReODcxE3tM2Lz4NhRoc+m_VOxBe-kToRJViKrw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302251531250.5360@kaball.uk.xensource.com>
References: <CAHyyzzSddetdReODcxE3tM2Lz4NhRoc+m_VOxBe-kToRJViKrw@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1342847746-443108974-1361807008=:5360"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen hvm fails to 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-443108974-1361807008=:5360
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sun, 24 Feb 2013, jacek burghardt wrote:
> When I try to start hvm qemu-xen I get this error It seems that the path =
my be off. Can someone point me were in source code path
> to qemu pid is defined .It seems that qeum-xen points to loacation I don'=
t see were it is defined.=C2=A0
> xc: detail: elf_load_binary: phdr 0 at 0x0x7f71cac72000 -> 0x0x7f71cad079=
d5
> libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed
> libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)buil=
d domain: -3
> libxl: error: libxl_dm.c:1250:libxl__destroy_device_model: could not find=
 device-model's pid for dom 14
> libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_mo=
del failed for 14
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x1bcc300: comple=
te, rc=3D-3
> libxl: debug: libxl_create.c:1227:do_domain_create: ao 0x1bcc300: inprogr=
ess: poller=3D0x1bccf70, flags=3Dic
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x1bcc300: destro=
y
> xc: debug: hypercall buffer: total allocations:1166 total releases:1166
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:1158 misses:4 toobig:4

Maybe there isn't enough free memory in your system?

In any case by default qemu-xen lives in /usr/lib/xen/bin, the binary
name is qemu-system-i386.
--1342847746-443108974-1361807008=:5360
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-443108974-1361807008=:5360--


From xen-devel-bounces@lists.xen.org Mon Feb 25 15:45:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15: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 1UA0FC-0000Ql-QV; Mon, 25 Feb 2013 15:45: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 1UA0FB-0000QM-Fh
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:45:33 +0000
Received: from [85.158.138.51:7089] by server-16.bemta-3.messagelabs.com id
	97/E4-02727-C178B215; Mon, 25 Feb 2013 15:45:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361807131!29167789!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27186 invoked from network); 25 Feb 2013 15:45:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:45:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1848496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 15:45: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.297.1;
	Mon, 25 Feb 2013 15:45:31 +0000
Message-ID: <1361807129.26546.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 25 Feb 2013 15:45:29 +0000
In-Reply-To: <alpine.DEB.2.02.1302251524260.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302251524260.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, Dario
	Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 15:26 +0000, Stefano Stabellini wrote:

> > 4.2.0 is already in Debian experimental.
> 
> There might be many reasons why one would want to roll his own packages
> rather than using a distro package.

Then start from the distro package, it's not that hard.

> Given that we already have a deb target, it doesn't cost as much to add
> a second one, that is actually useful.

There is a cost though, because once you start saying this is a user
focused thing which users should actually use then they will do so. A
proper package (especially of something like Xen) which integrates well
with the distro is a lot of work, which should rightly be happening in
the distro.

If the existing deb target is going to be the thin end of the wedge of
doing more and more packaging work in the Xen tree itself then I would
rather we just removed 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 Feb 25 15:45:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15: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 1UA0FC-0000Ql-QV; Mon, 25 Feb 2013 15:45: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 1UA0FB-0000QM-Fh
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:45:33 +0000
Received: from [85.158.138.51:7089] by server-16.bemta-3.messagelabs.com id
	97/E4-02727-C178B215; Mon, 25 Feb 2013 15:45:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361807131!29167789!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27186 invoked from network); 25 Feb 2013 15:45:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:45:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1848496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 15:45: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.297.1;
	Mon, 25 Feb 2013 15:45:31 +0000
Message-ID: <1361807129.26546.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 25 Feb 2013 15:45:29 +0000
In-Reply-To: <alpine.DEB.2.02.1302251524260.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302251524260.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, Dario
	Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Alex Bligh <alex@alex.org.uk>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 15:26 +0000, Stefano Stabellini wrote:

> > 4.2.0 is already in Debian experimental.
> 
> There might be many reasons why one would want to roll his own packages
> rather than using a distro package.

Then start from the distro package, it's not that hard.

> Given that we already have a deb target, it doesn't cost as much to add
> a second one, that is actually useful.

There is a cost though, because once you start saying this is a user
focused thing which users should actually use then they will do so. A
proper package (especially of something like Xen) which integrates well
with the distro is a lot of work, which should rightly be happening in
the distro.

If the existing deb target is going to be the thin end of the wedge of
doing more and more packaging work in the Xen tree itself then I would
rather we just removed 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 Feb 25 15:53:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15:53: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 1UA0Mj-00019g-Qc; Mon, 25 Feb 2013 15:53:21 +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 1UA0Mh-00019a-Vc
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:53:20 +0000
Received: from [85.158.137.99:16030] by server-13.bemta-3.messagelabs.com id
	7B/61-20653-AE88B215; Mon, 25 Feb 2013 15:53:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361807589!12354606!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4673 invoked from network); 25 Feb 2013 15:53:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8947103"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 15:52:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 10:52:52 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA0MG-0001HB-Gf;
	Mon, 25 Feb 2013 15:52:52 +0000
Date: Mon, 25 Feb 2013 15:52:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CD50C75C.4C8F6%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.02.1302251548590.5360@kaball.uk.xensource.com>
References: <CD50C75C.4C8F6%keir.xen@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "mst@redhat.com" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xudong Hao <xudong.hao@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Keir Fraser wrote:
> On 25/02/2013 06:50, "Xudong Hao" <xudong.hao@intel.com> wrote:
> 
> > v2:
> > * Define TOM register as one byte
> > 
> > Define a TOM(top of memory) register to report the base of PCI memory, so that
> > qemu should update MMIO by reading this register value. TOM register are
> > defined
> > to one byte in PCI configure space, because that only upper 4 bit of PCI
> > memory
> > takes effect.
> > 
> > With the combination of qemu upstream, this should be a fix for PCI MMIO hole
> > configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set
> > MMIO
> > to 0x80000000~0xe0000000.
> 
> Why does qemu (when used as the Xen device model) care about the location of
> the PCI hole start?

QEMU needs to know where the end of the guest's RAM is (because there is
where it allocates the videoram and other stuff), so at least the size
of the MMIO hole is important.
Also, given that Xen support is tightly integrated in QEMU now, and QEMU
assumes it knows everything about RAM and MMIO regions, it is probably a
good idea to give it these information anyway.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 15:53:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 15:53: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 1UA0Mj-00019g-Qc; Mon, 25 Feb 2013 15:53:21 +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 1UA0Mh-00019a-Vc
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 15:53:20 +0000
Received: from [85.158.137.99:16030] by server-13.bemta-3.messagelabs.com id
	7B/61-20653-AE88B215; Mon, 25 Feb 2013 15:53:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361807589!12354606!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4673 invoked from network); 25 Feb 2013 15:53:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 15:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="8947103"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 15:52:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 10:52:52 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA0MG-0001HB-Gf;
	Mon, 25 Feb 2013 15:52:52 +0000
Date: Mon, 25 Feb 2013 15:52:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CD50C75C.4C8F6%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.02.1302251548590.5360@kaball.uk.xensource.com>
References: <CD50C75C.4C8F6%keir.xen@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "mst@redhat.com" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xudong Hao <xudong.hao@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/hvmloader: define a TOM register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Keir Fraser wrote:
> On 25/02/2013 06:50, "Xudong Hao" <xudong.hao@intel.com> wrote:
> 
> > v2:
> > * Define TOM register as one byte
> > 
> > Define a TOM(top of memory) register to report the base of PCI memory, so that
> > qemu should update MMIO by reading this register value. TOM register are
> > defined
> > to one byte in PCI configure space, because that only upper 4 bit of PCI
> > memory
> > takes effect.
> > 
> > With the combination of qemu upstream, this should be a fix for PCI MMIO hole
> > configuration. Upstream qemu set 0xe0000000 as TOM, but guest bios may set
> > MMIO
> > to 0x80000000~0xe0000000.
> 
> Why does qemu (when used as the Xen device model) care about the location of
> the PCI hole start?

QEMU needs to know where the end of the guest's RAM is (because there is
where it allocates the videoram and other stuff), so at least the size
of the MMIO hole is important.
Also, given that Xen support is tightly integrated in QEMU now, and QEMU
assumes it knows everything about RAM and MMIO regions, it is probably a
good idea to give it these information anyway.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:06:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:06: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 1UA0Yy-0001yx-56; Mon, 25 Feb 2013 16:06: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 1UA0Yv-0001ys-Lh
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:05:57 +0000
Received: from [85.158.143.99:57112] by server-1.bemta-4.messagelabs.com id
	84/6B-06203-5EB8B215; Mon, 25 Feb 2013 16:05:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361808353!21577785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25683 invoked from network); 25 Feb 2013 16:05:55 -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;
	25 Feb 2013 16:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9413375"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 16:05:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 11:05:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA0Yp-0001Sy-M9;
	Mon, 25 Feb 2013 16:05:51 +0000
Date: Mon, 25 Feb 2013 16:05:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] piix: define a TOM register to report
 the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Xudong Hao wrote:
> v2:
> * Use "piix: " in the subject rather than "qemu: "
> * Define TOM register as one byte
> * Define default TOM value instead of hardcode 0xe0000000 in more that one place
> * Use API pci_set_byte for pci config access
> * Use dev->config instead of the indirect d->dev.config
> 
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically. TOM register are defined to one byte in PCI configure
> space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> it requires bios set TOM with 16M-aligned.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

The patch is OK from my POV, but I think that Ian raised a valid
concern: we are supposed to emulate a real piece of hardware, maybe
another mechanism (xenbus? hvmop?) to pass the information from
hvmloader to QEMU would be a better fit than this.
Otherwise at least we would need to advertize this feature somehow: if
hvmloader can use it, the guest kernel can use it too...



>  hw/pc.h       |  7 +++---
>  hw/pc_piix.c  | 12 +++-------
>  hw/piix_pci.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------------
>  3 files changed, 59 insertions(+), 33 deletions(-)
> 
> diff --git a/hw/pc.h b/hw/pc.h
> index fbcf43d..62adcc5 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -129,15 +129,14 @@ extern int no_hpet;
>  struct PCII440FXState;
>  typedef struct PCII440FXState PCII440FXState;
>  
> +#define I440FX_TOM     0xe0000000
> +#define I440FX_XEN_TOM 0xf0000000
> +
>  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>                      ISABus **isa_bus, qemu_irq *pic,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory,
>                      MemoryRegion *ram_memory);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0a6923d..2eef510 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
>          kvmclock_create();
>      }
>  
> -    if (ram_size >= 0xe0000000 ) {
> -        above_4g_mem_size = ram_size - 0xe0000000;
> -        below_4g_mem_size = 0xe0000000;
> +    if (ram_size >= I440FX_TOM) {
> +        above_4g_mem_size = ram_size - I440FX_TOM;
> +        below_4g_mem_size = I440FX_TOM;
>      } else {
>          above_4g_mem_size = 0;
>          below_4g_mem_size = ram_size;
> @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>                                system_memory, system_io, ram_size,
> -                              below_4g_mem_size,
> -                              0x100000000ULL - below_4g_mem_size,
> -                              0x100000000ULL + above_4g_mem_size,
> -                              (sizeof(hwaddr) == 4
> -                               ? 0
> -                               : ((uint64_t)1 << 62)),
>                                pci_memory, ram_memory);
>      } else {
>          pci_bus = NULL;
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3d79c73..3e5a25c 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -86,6 +86,14 @@ struct PCII440FXState {
>  #define I440FX_PAM_SIZE 7
>  #define I440FX_SMRAM    0x72
>  
> +/* The maximum vaule of TOM(top of memory) register in I440FX
> + * is 1G, so it doesn't meet any popular virutal machines, so
> + * define another register to report the base of PCI memory.
> + * Use one byte 0xb0 for the upper 8 bit, they are originally
> + * resevered for host bridge.
> + * */
> +#define I440FX_PCI_HOLE_BASE 0xb0
> +
>  static void piix3_set_irq(void *opaque, int pirq, int level);
>  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
>  static void piix3_write_config_xen(PCIDevice *dev,
> @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> +
> +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> +{
> +    ram_addr_t above_4g_mem_size;
> +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
> +
> +    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 1) << 24;
> +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> +
> +    if (ram_size >= pci_hole_start) {
> +        above_4g_mem_size = ram_size - pci_hole_start;
> +    } else {
> +        above_4g_mem_size = 0;
> +    }
> +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> +
> +    if (del) {
> +        memory_region_del_subregion(f->system_memory, &f->pci_hole);
> +        if (pci_hole64_size) {
> +            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
> +        }
> +    }
> +
> +    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> +                             pci_hole_start, pci_hole_size);
> +    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> +                             f->pci_address_space,
> +                             pci_hole64_start, pci_hole64_size);
> +    if (pci_hole64_size) {
> +        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> +                                    &f->pci_hole_64bit);
> +    }
> +}
> +
> +
>  static void i440fx_update_memory_mappings(PCII440FXState *d)
>  {
>      int i;
> @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
>          range_covers_byte(address, len, I440FX_SMRAM)) {
>          i440fx_update_memory_mappings(d);
>      }
> +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> +        i440fx_update_pci_mem_hole(d, true);
> +    }
>  }
>  
>  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >> 24));
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }
> @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>                                    MemoryRegion *address_space_mem,
>                                    MemoryRegion *address_space_io,
>                                    ram_addr_t ram_size,
> -                                  hwaddr pci_hole_start,
> -                                  hwaddr pci_hole_size,
> -                                  hwaddr pci_hole64_start,
> -                                  hwaddr pci_hole64_size,
>                                    MemoryRegion *pci_address_space,
>                                    MemoryRegion *ram_memory)
>  {
> @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      f->system_memory = address_space_mem;
>      f->pci_address_space = pci_address_space;
>      f->ram_memory = ram_memory;
> -    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> -                             pci_hole_start, pci_hole_size);
> -    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> -                             f->pci_address_space,
> -                             pci_hole64_start, pci_hole64_size);
> -    if (pci_hole64_size) {
> -        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> -                                    &f->pci_hole_64bit);
> -    }
>      memory_region_init_alias(&f->smram_region, "smram-region",
>                               f->pci_address_space, 0xa0000, 0x20000);
>      memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
> @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      (*pi440fx_state)->dev.config[0x57]=ram_size;
>  
>      i440fx_update_memory_mappings(f);
> +    i440fx_update_pci_mem_hole(f, false);
>  
>      return b;
>  }
> @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory, MemoryRegion *ram_memory)
>  
>  {
> @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>  
>      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
>                             address_space_mem, address_space_io, ram_size,
> -                           pci_hole_start, pci_hole_size,
> -                           pci_hole64_start, pci_hole64_size,
>                             pci_memory, ram_memory);
>      return b;
>  }
> -- 
> 1.7.12.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:06:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:06: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 1UA0Yy-0001yx-56; Mon, 25 Feb 2013 16:06: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 1UA0Yv-0001ys-Lh
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:05:57 +0000
Received: from [85.158.143.99:57112] by server-1.bemta-4.messagelabs.com id
	84/6B-06203-5EB8B215; Mon, 25 Feb 2013 16:05:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361808353!21577785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25683 invoked from network); 25 Feb 2013 16:05:55 -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;
	25 Feb 2013 16:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="9413375"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 16:05:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 11:05:51 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA0Yp-0001Sy-M9;
	Mon, 25 Feb 2013 16:05:51 +0000
Date: Mon, 25 Feb 2013 16:05:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] piix: define a TOM register to report
 the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Xudong Hao wrote:
> v2:
> * Use "piix: " in the subject rather than "qemu: "
> * Define TOM register as one byte
> * Define default TOM value instead of hardcode 0xe0000000 in more that one place
> * Use API pci_set_byte for pci config access
> * Use dev->config instead of the indirect d->dev.config
> 
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically. TOM register are defined to one byte in PCI configure
> space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> it requires bios set TOM with 16M-aligned.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

The patch is OK from my POV, but I think that Ian raised a valid
concern: we are supposed to emulate a real piece of hardware, maybe
another mechanism (xenbus? hvmop?) to pass the information from
hvmloader to QEMU would be a better fit than this.
Otherwise at least we would need to advertize this feature somehow: if
hvmloader can use it, the guest kernel can use it too...



>  hw/pc.h       |  7 +++---
>  hw/pc_piix.c  | 12 +++-------
>  hw/piix_pci.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------------
>  3 files changed, 59 insertions(+), 33 deletions(-)
> 
> diff --git a/hw/pc.h b/hw/pc.h
> index fbcf43d..62adcc5 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -129,15 +129,14 @@ extern int no_hpet;
>  struct PCII440FXState;
>  typedef struct PCII440FXState PCII440FXState;
>  
> +#define I440FX_TOM     0xe0000000
> +#define I440FX_XEN_TOM 0xf0000000
> +
>  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>                      ISABus **isa_bus, qemu_irq *pic,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory,
>                      MemoryRegion *ram_memory);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0a6923d..2eef510 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
>          kvmclock_create();
>      }
>  
> -    if (ram_size >= 0xe0000000 ) {
> -        above_4g_mem_size = ram_size - 0xe0000000;
> -        below_4g_mem_size = 0xe0000000;
> +    if (ram_size >= I440FX_TOM) {
> +        above_4g_mem_size = ram_size - I440FX_TOM;
> +        below_4g_mem_size = I440FX_TOM;
>      } else {
>          above_4g_mem_size = 0;
>          below_4g_mem_size = ram_size;
> @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>                                system_memory, system_io, ram_size,
> -                              below_4g_mem_size,
> -                              0x100000000ULL - below_4g_mem_size,
> -                              0x100000000ULL + above_4g_mem_size,
> -                              (sizeof(hwaddr) == 4
> -                               ? 0
> -                               : ((uint64_t)1 << 62)),
>                                pci_memory, ram_memory);
>      } else {
>          pci_bus = NULL;
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3d79c73..3e5a25c 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -86,6 +86,14 @@ struct PCII440FXState {
>  #define I440FX_PAM_SIZE 7
>  #define I440FX_SMRAM    0x72
>  
> +/* The maximum vaule of TOM(top of memory) register in I440FX
> + * is 1G, so it doesn't meet any popular virutal machines, so
> + * define another register to report the base of PCI memory.
> + * Use one byte 0xb0 for the upper 8 bit, they are originally
> + * resevered for host bridge.
> + * */
> +#define I440FX_PCI_HOLE_BASE 0xb0
> +
>  static void piix3_set_irq(void *opaque, int pirq, int level);
>  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
>  static void piix3_write_config_xen(PCIDevice *dev,
> @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> +
> +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> +{
> +    ram_addr_t above_4g_mem_size;
> +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
> +
> +    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 1) << 24;
> +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> +
> +    if (ram_size >= pci_hole_start) {
> +        above_4g_mem_size = ram_size - pci_hole_start;
> +    } else {
> +        above_4g_mem_size = 0;
> +    }
> +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> +
> +    if (del) {
> +        memory_region_del_subregion(f->system_memory, &f->pci_hole);
> +        if (pci_hole64_size) {
> +            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
> +        }
> +    }
> +
> +    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> +                             pci_hole_start, pci_hole_size);
> +    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> +                             f->pci_address_space,
> +                             pci_hole64_start, pci_hole64_size);
> +    if (pci_hole64_size) {
> +        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> +                                    &f->pci_hole_64bit);
> +    }
> +}
> +
> +
>  static void i440fx_update_memory_mappings(PCII440FXState *d)
>  {
>      int i;
> @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
>          range_covers_byte(address, len, I440FX_SMRAM)) {
>          i440fx_update_memory_mappings(d);
>      }
> +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> +        i440fx_update_pci_mem_hole(d, true);
> +    }
>  }
>  
>  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >> 24));
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }
> @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>                                    MemoryRegion *address_space_mem,
>                                    MemoryRegion *address_space_io,
>                                    ram_addr_t ram_size,
> -                                  hwaddr pci_hole_start,
> -                                  hwaddr pci_hole_size,
> -                                  hwaddr pci_hole64_start,
> -                                  hwaddr pci_hole64_size,
>                                    MemoryRegion *pci_address_space,
>                                    MemoryRegion *ram_memory)
>  {
> @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      f->system_memory = address_space_mem;
>      f->pci_address_space = pci_address_space;
>      f->ram_memory = ram_memory;
> -    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> -                             pci_hole_start, pci_hole_size);
> -    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> -                             f->pci_address_space,
> -                             pci_hole64_start, pci_hole64_size);
> -    if (pci_hole64_size) {
> -        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> -                                    &f->pci_hole_64bit);
> -    }
>      memory_region_init_alias(&f->smram_region, "smram-region",
>                               f->pci_address_space, 0xa0000, 0x20000);
>      memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
> @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
>      (*pi440fx_state)->dev.config[0x57]=ram_size;
>  
>      i440fx_update_memory_mappings(f);
> +    i440fx_update_pci_mem_hole(f, false);
>  
>      return b;
>  }
> @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory, MemoryRegion *ram_memory)
>  
>  {
> @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
>  
>      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus, pic,
>                             address_space_mem, address_space_io, ram_size,
> -                           pci_hole_start, pci_hole_size,
> -                           pci_hole64_start, pci_hole64_size,
>                             pci_memory, ram_memory);
>      return b;
>  }
> -- 
> 1.7.12.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:08:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:08: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 1UA0ai-00023g-OV; Mon, 25 Feb 2013 16:07:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1UA0ah-00023W-Tr
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:07:48 +0000
Received: from [85.158.137.99:22143] by server-4.bemta-3.messagelabs.com id
	68/4F-17521-25C8B215; Mon, 25 Feb 2013 16:07:46 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361808465!12358066!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15130 invoked from network); 25 Feb 2013 16:07:46 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:07:46 -0000
Received: (qmail 16160 invoked from network); 25 Feb 2013 18:07:44 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 18:07:44 +0200
Message-ID: <512B8C6B.90305@gmail.com>
Date: Mon, 25 Feb 2013 18:08:11 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.7.1697400, Dats:
	247827, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: f9e9823620de15231309382748b9d42d.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v1.4.7; Id:
	2m1g30h.17k15itcf.49fke], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45675
Subject: [Xen-devel] xc_domain_hvm_getcontext_partial(... CPU ...),
 the RIP register, and mem_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-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,

assuming that the VCPU is paused while waiting for userspace to respond 
to a page fault mem_event, and userspace calls libxc's 
xc_domain_hvm_getcontext_partial(... CPU ...) and tries to inspect RIP, 
is this a safe thing to do? Is RIP's value guaranteed to be safe to 
inspect in this context?

Thanks,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:08:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:08: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 1UA0ai-00023g-OV; Mon, 25 Feb 2013 16:07:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rzvncj@gmail.com>) id 1UA0ah-00023W-Tr
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:07:48 +0000
Received: from [85.158.137.99:22143] by server-4.bemta-3.messagelabs.com id
	68/4F-17521-25C8B215; Mon, 25 Feb 2013 16:07:46 +0000
X-Env-Sender: rzvncj@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361808465!12358066!1
X-Originating-IP: [91.199.104.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15130 invoked from network); 25 Feb 2013 16:07:46 -0000
Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:07:46 -0000
Received: (qmail 16160 invoked from network); 25 Feb 2013 18:07:44 +0200
Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?)
	(rcojocaru@bitdefender.com@10.10.14.59)
	by mail.bitdefender.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 18:07:44 +0200
Message-ID: <512B8C6B.90305@gmail.com>
Date: Mon, 25 Feb 2013 18:08:11 +0200
From: Razvan Cojocaru <rzvncj@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-BitDefender-Spam: No (0)
X-BitDefender-SpamStamp: Build: [Engines: 2.13.7.1697400, Dats:
	247827, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL:
	[Disabled], APM: [Enabled, Score: 500, Flags:
	NN_GMAIL_WITH_XMAILER_ADN; NN_NO_LINK_NMD;
	NN_EXEC_H_YAHOO_AND_GMAIL_NO_DOMAIN_KEY; NN_LEGIT_MAILING_LIST_TO],
	SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, 
	Hits: none, MD5: f9e9823620de15231309382748b9d42d.fuzzy.fzrbl.org],
	RTDA: [Enabled, Hit: No, Details: v1.4.7; Id:
	2m1g30h.17k15itcf.49fke], total: 0(775)
X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on
	elfie.dsd.hq, sigver: 7.45675
Subject: [Xen-devel] xc_domain_hvm_getcontext_partial(... CPU ...),
 the RIP register, and mem_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-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,

assuming that the VCPU is paused while waiting for userspace to respond 
to a page fault mem_event, and userspace calls libxc's 
xc_domain_hvm_getcontext_partial(... CPU ...) and tries to inspect RIP, 
is this a safe thing to do? Is RIP's value guaranteed to be safe to 
inspect in this context?

Thanks,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:18:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:18: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 1UA0ky-0002Vk-6N; Mon, 25 Feb 2013 16:18: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 1UA0kw-0002Vf-J5
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:18:22 +0000
Received: from [85.158.137.99:25194] by server-15.bemta-3.messagelabs.com id
	93/26-25405-DCE8B215; Mon, 25 Feb 2013 16:18:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361809100!12869494!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 25 Feb 2013 16:18:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1849935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16: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.297.1; Mon, 25 Feb 2013 16:18:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UA0kl-0008Tq-EL;
	Mon, 25 Feb 2013 16:18:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UA0kl-0007YZ-CZ;
	Mon, 25 Feb 2013 16:18:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16583-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 16:18:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16583: 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 16583 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16583/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:18:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:18: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 1UA0ky-0002Vk-6N; Mon, 25 Feb 2013 16:18: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 1UA0kw-0002Vf-J5
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:18:22 +0000
Received: from [85.158.137.99:25194] by server-15.bemta-3.messagelabs.com id
	93/26-25405-DCE8B215; Mon, 25 Feb 2013 16:18:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361809100!12869494!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 25 Feb 2013 16:18:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1849935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16: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.297.1; Mon, 25 Feb 2013 16:18:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UA0kl-0008Tq-EL;
	Mon, 25 Feb 2013 16:18:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UA0kl-0007YZ-CZ;
	Mon, 25 Feb 2013 16:18:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16583-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 16:18:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16583: 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 16583 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16583/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uT-0002tG-BC; Mon, 25 Feb 2013 16:28:13 +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 1UA0uR-0002st-Sx
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:12 +0000
Received: from [85.158.139.83:29211] by server-10.bemta-5.messagelabs.com id
	32/0E-23714-B119B215; Mon, 25 Feb 2013 16:28:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361809688!29117610!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16362 invoked from network); 25 Feb 2013 16:28:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:28:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5ZS006158
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:06 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
	r1PGS5Oi014861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4kT028968; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A6BB41C393C; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:59 -0500
Message-Id: <1361809680-10075-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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>
Subject: [Xen-devel] [PATCH 6/7] docs: Document start_info changes in 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>
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  25833:bb85bbccb1c9. "x86/32-on-64: adjust Dom0 initial page table layout"
fixes a bug in the reported value of pt_base versus where the page tables
actually start. This documents this in the start of the world header note.

This clarifies the implied understanding that the page table space is
pointed by pt_base. As in it is ".. implied that the range of page-tables
is the range [pt_base, pt_base + nr_pt_frames), whereas that that range
here indeed is [pt_base - 2, pt_base -2 + nr_pt_frames)" (Jan Beulich).

Also make it crystal clear that pt_base == %cr3.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/xen.h |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5e9bbcb..099ad24 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -693,7 +693,7 @@ typedef struct shared_info shared_info_t;
  *      c. list of allocated page frames [mfn_list, nr_pages]
  *         (unless relocated due to XEN_ELFNOTE_INIT_P2M)
  *      d. start_info_t structure        [register ESI (x86)]
- *      e. bootstrap page tables         [pt_base, CR3 (x86)]
+ *      e. bootstrap page tables         [pt_base and CR3 (x86)]
  *      f. bootstrap stack               [register ESP (x86)]
  *  4. Bootstrap elements are packed together, but each is 4kB-aligned.
  *  5. The initial ram disk may be omitted.
@@ -705,6 +705,16 @@ typedef struct shared_info shared_info_t;
  *  8. There is guaranteed to be at least 512kB padding after the final
  *     bootstrap element. If necessary, the bootstrap virtual region is
  *     extended by an extra 4MB to ensure this.
+ *
+ * Note: Prior to 25833:bb85bbccb1c9. ("x86/32-on-64 adjust Dom0 initial page
+ * table layout") a bug caused the pt_base (3.e above) and cr3 to not point
+ * to the start of the guest page tables (it was offset by two pages).
+ * This only manifested itself on 32-on-64 dom0 kernels and not 32-on-64 domU
+ * or 64-bit kernels of any colour. The page tables for a 32-on-64 dom0 got
+ * allocated in the order: 'first L1','first L2', 'first L3', so the offset
+ * to the page table base is by two pages back. The initial domain if it is
+ * 32-bit and runs under a 64-bit hypervisor should _NOT_ use two of the
+ * pages preceding pt_base and mark them as reserved/unused.
  */
 
 #define MAX_GUEST_CMDLINE 1024
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uT-0002tG-BC; Mon, 25 Feb 2013 16:28:13 +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 1UA0uR-0002st-Sx
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:12 +0000
Received: from [85.158.139.83:29211] by server-10.bemta-5.messagelabs.com id
	32/0E-23714-B119B215; Mon, 25 Feb 2013 16:28:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361809688!29117610!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16362 invoked from network); 25 Feb 2013 16:28:09 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:28:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5ZS006158
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:06 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
	r1PGS5Oi014861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4kT028968; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A6BB41C393C; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:59 -0500
Message-Id: <1361809680-10075-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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>
Subject: [Xen-devel] [PATCH 6/7] docs: Document start_info changes in 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>
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  25833:bb85bbccb1c9. "x86/32-on-64: adjust Dom0 initial page table layout"
fixes a bug in the reported value of pt_base versus where the page tables
actually start. This documents this in the start of the world header note.

This clarifies the implied understanding that the page table space is
pointed by pt_base. As in it is ".. implied that the range of page-tables
is the range [pt_base, pt_base + nr_pt_frames), whereas that that range
here indeed is [pt_base - 2, pt_base -2 + nr_pt_frames)" (Jan Beulich).

Also make it crystal clear that pt_base == %cr3.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/xen.h |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5e9bbcb..099ad24 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -693,7 +693,7 @@ typedef struct shared_info shared_info_t;
  *      c. list of allocated page frames [mfn_list, nr_pages]
  *         (unless relocated due to XEN_ELFNOTE_INIT_P2M)
  *      d. start_info_t structure        [register ESI (x86)]
- *      e. bootstrap page tables         [pt_base, CR3 (x86)]
+ *      e. bootstrap page tables         [pt_base and CR3 (x86)]
  *      f. bootstrap stack               [register ESP (x86)]
  *  4. Bootstrap elements are packed together, but each is 4kB-aligned.
  *  5. The initial ram disk may be omitted.
@@ -705,6 +705,16 @@ typedef struct shared_info shared_info_t;
  *  8. There is guaranteed to be at least 512kB padding after the final
  *     bootstrap element. If necessary, the bootstrap virtual region is
  *     extended by an extra 4MB to ensure this.
+ *
+ * Note: Prior to 25833:bb85bbccb1c9. ("x86/32-on-64 adjust Dom0 initial page
+ * table layout") a bug caused the pt_base (3.e above) and cr3 to not point
+ * to the start of the guest page tables (it was offset by two pages).
+ * This only manifested itself on 32-on-64 dom0 kernels and not 32-on-64 domU
+ * or 64-bit kernels of any colour. The page tables for a 32-on-64 dom0 got
+ * allocated in the order: 'first L1','first L2', 'first L3', so the offset
+ * to the page table base is by two pages back. The initial domain if it is
+ * 32-bit and runs under a 64-bit hypervisor should _NOT_ use two of the
+ * pages preceding pt_base and mark them as reserved/unused.
  */
 
 #define MAX_GUEST_CMDLINE 1024
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uR-0002su-IK; Mon, 25 Feb 2013 16:28: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 1UA0uQ-0002sj-A6
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:10 +0000
Received: from [85.158.139.83:20871] by server-5.bemta-5.messagelabs.com id
	16/55-02762-9119B215; Mon, 25 Feb 2013 16:28:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361809687!28887866!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31077 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4tg014576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS47b020432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS3Ik029347; Mon, 25 Feb 2013 10:28:03 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8BD621C3938; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:55 -0500
Message-Id: <1361809680-10075-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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 2/7] docs: Document the ELF_FEATURES 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>
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

Mark-up for inclusion of generated docs.

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/features.h |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index b4533cc..bfaf2db 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -28,6 +28,20 @@
 #define __XEN_PUBLIC_FEATURES_H__
 
 /*
+ * `incontents 200 elfnotes_features XEN_ELFNOTE_FEATURES
+ *
+ * The list of all the features the guest supports. They are set by
+ * parsing the XEN_ELFNOTE_FEATURES and XEN_ELFNOTE_SUPPORTED_FEATURES
+ * string. The format is the  feature names (as given here without the
+ * "XENFEAT_" prefix) separated by '|' characters.
+ * If a feature is required for the kernel to function then the feature name
+ * must be preceded by a '!' character.
+ *
+ * Note that if XEN_ELFNOTE_SUPPORTED_FEATURES is used, then in the
+ * XENFEAT_dom0 MUST be set if the guest is to be booted as dom0,
+ */
+
+/*
  * If set, the guest does not need to write-protect its pagetables, and can
  * update them via direct writes.
  */
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uR-0002su-IK; Mon, 25 Feb 2013 16:28: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 1UA0uQ-0002sj-A6
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:10 +0000
Received: from [85.158.139.83:20871] by server-5.bemta-5.messagelabs.com id
	16/55-02762-9119B215; Mon, 25 Feb 2013 16:28:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361809687!28887866!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31077 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4tg014576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS47b020432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS3Ik029347; Mon, 25 Feb 2013 10:28:03 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8BD621C3938; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:55 -0500
Message-Id: <1361809680-10075-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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 2/7] docs: Document the ELF_FEATURES 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>
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

Mark-up for inclusion of generated docs.

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/features.h |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index b4533cc..bfaf2db 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -28,6 +28,20 @@
 #define __XEN_PUBLIC_FEATURES_H__
 
 /*
+ * `incontents 200 elfnotes_features XEN_ELFNOTE_FEATURES
+ *
+ * The list of all the features the guest supports. They are set by
+ * parsing the XEN_ELFNOTE_FEATURES and XEN_ELFNOTE_SUPPORTED_FEATURES
+ * string. The format is the  feature names (as given here without the
+ * "XENFEAT_" prefix) separated by '|' characters.
+ * If a feature is required for the kernel to function then the feature name
+ * must be preceded by a '!' character.
+ *
+ * Note that if XEN_ELFNOTE_SUPPORTED_FEATURES is used, then in the
+ * XENFEAT_dom0 MUST be set if the guest is to be booted as dom0,
+ */
+
+/*
  * If set, the guest does not need to write-protect its pagetables, and can
  * update them via direct writes.
  */
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uX-0002u0-53; Mon, 25 Feb 2013 16:28:17 +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 1UA0uU-0002tS-Sx
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:15 +0000
Received: from [85.158.138.51:19459] by server-1.bemta-3.messagelabs.com id
	60/33-08955-9119B215; Mon, 25 Feb 2013 16:28:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361809687!19786480!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1715 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:28:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5oQ014597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:06 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
	r1PGS5qv009559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS5c8028974; Mon, 25 Feb 2013 10:28:05 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9E4A41C393B; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:58 -0500
Message-Id: <1361809680-10075-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/7] docs: Document the dom0_vga_console_info
	structure.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/xen.h |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e1748d1..5e9bbcb 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -779,7 +779,14 @@ struct xen_multiboot_mod_list
     /* Unused, must be zero */
     uint32_t pad;
 };
-
+/*
+ * `incontents 200 startofday_dom0_console Dom9_console
+ *
+ * The console structure in start_info.console.dom0
+ *
+ * This structure includes a variety of information required to
+ * have a working VGA/VESA console.
+ */
 typedef struct dom0_vga_console_info {
     uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uX-0002u0-53; Mon, 25 Feb 2013 16:28:17 +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 1UA0uU-0002tS-Sx
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:15 +0000
Received: from [85.158.138.51:19459] by server-1.bemta-3.messagelabs.com id
	60/33-08955-9119B215; Mon, 25 Feb 2013 16:28:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361809687!19786480!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1715 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:28:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5oQ014597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:06 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
	r1PGS5qv009559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS5c8028974; Mon, 25 Feb 2013 10:28:05 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9E4A41C393B; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:58 -0500
Message-Id: <1361809680-10075-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/7] docs: Document the dom0_vga_console_info
	structure.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/xen.h |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e1748d1..5e9bbcb 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -779,7 +779,14 @@ struct xen_multiboot_mod_list
     /* Unused, must be zero */
     uint32_t pad;
 };
-
+/*
+ * `incontents 200 startofday_dom0_console Dom9_console
+ *
+ * The console structure in start_info.console.dom0
+ *
+ * This structure includes a variety of information required to
+ * have a working VGA/VESA console.
+ */
 typedef struct dom0_vga_console_info {
     uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
 #define XEN_VGATYPE_TEXT_MODE_3 0x03
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uR-0002t1-U1; Mon, 25 Feb 2013 16:28:11 +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 1UA0uQ-0002sk-N0
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:10 +0000
Received: from [85.158.143.99:27768] by server-2.bemta-4.messagelabs.com id
	C4/61-12656-9119B215; Mon, 25 Feb 2013 16:28:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361809687!28496890!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14481 invoked from network); 25 Feb 2013 16:28:09 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5wS014603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:06 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
	r1PGS5qZ010101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4mv003310; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 981C41C393A; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:57 -0500
Message-Id: <1361809680-10075-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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/7] docs: Document the shared structure.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/xen.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..e1748d1 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -622,6 +622,7 @@ typedef struct vcpu_info vcpu_info_t;
 #endif
 
 /*
+ * `incontents 200 startofday_shared Start-of-day shared data structure
  * Xen/kernel shared data -- pointer provided in start_info.
  *
  * This structure is defined to be both smaller than a page, and the
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uR-0002t1-U1; Mon, 25 Feb 2013 16:28:11 +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 1UA0uQ-0002sk-N0
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:10 +0000
Received: from [85.158.143.99:27768] by server-2.bemta-4.messagelabs.com id
	C4/61-12656-9119B215; Mon, 25 Feb 2013 16:28:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361809687!28496890!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14481 invoked from network); 25 Feb 2013 16:28:09 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:09 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5wS014603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:06 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
	r1PGS5qZ010101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4mv003310; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 981C41C393A; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:57 -0500
Message-Id: <1361809680-10075-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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/7] docs: Document the shared structure.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/xen.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..e1748d1 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -622,6 +622,7 @@ typedef struct vcpu_info vcpu_info_t;
 #endif
 
 /*
+ * `incontents 200 startofday_shared Start-of-day shared data structure
  * Xen/kernel shared data -- pointer provided in start_info.
  *
  * This structure is defined to be both smaller than a page, and the
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uW-0002tq-Oc; Mon, 25 Feb 2013 16:28:16 +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 1UA0uU-0002tP-F5
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:14 +0000
Received: from [85.158.139.211:6300] by server-11.bemta-5.messagelabs.com id
	3A/61-27486-D119B215; Mon, 25 Feb 2013 16:28:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361809688!19186535!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21376 invoked from network); 25 Feb 2013 16:28:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5eB014589
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS5Kn009548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4WT028967; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AC6FB1C393D; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:28:00 -0500
Message-Id: <1361809680-10075-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 7/7] docs: Document the XenBus structure.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/io/xs_wire.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/io/xs_wire.h b/xen/include/public/io/xs_wire.h
index 7e454c4..761864e 100644
--- a/xen/include/public/io/xs_wire.h
+++ b/xen/include/public/io/xs_wire.h
@@ -103,7 +103,10 @@ enum xs_watch_type
     XS_WATCH_TOKEN
 };
 
-/* Inter-domain shared memory communications. */
+/*
+ * `incontents 150 xenstore_struct XenStore wire protocol.
+ *
+ * Inter-domain shared memory communications. */
 #define XENSTORE_RING_SIZE 1024
 typedef uint32_t XENSTORE_RING_IDX;
 #define MASK_XENSTORE_IDX(idx) ((idx) & (XENSTORE_RING_SIZE-1))
-- 
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 Feb 25 16:28:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0uW-0002tq-Oc; Mon, 25 Feb 2013 16:28:16 +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 1UA0uU-0002tP-F5
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:14 +0000
Received: from [85.158.139.211:6300] by server-11.bemta-5.messagelabs.com id
	3A/61-27486-D119B215; Mon, 25 Feb 2013 16:28:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361809688!19186535!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21376 invoked from network); 25 Feb 2013 16:28:10 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5eB014589
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS5Kn009548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4WT028967; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AC6FB1C393D; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:28:00 -0500
Message-Id: <1361809680-10075-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 7/7] docs: Document the XenBus structure.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/io/xs_wire.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/io/xs_wire.h b/xen/include/public/io/xs_wire.h
index 7e454c4..761864e 100644
--- a/xen/include/public/io/xs_wire.h
+++ b/xen/include/public/io/xs_wire.h
@@ -103,7 +103,10 @@ enum xs_watch_type
     XS_WATCH_TOKEN
 };
 
-/* Inter-domain shared memory communications. */
+/*
+ * `incontents 150 xenstore_struct XenStore wire protocol.
+ *
+ * Inter-domain shared memory communications. */
 #define XENSTORE_RING_SIZE 1024
 typedef uint32_t XENSTORE_RING_IDX;
 #define MASK_XENSTORE_IDX(idx) ((idx) & (XENSTORE_RING_SIZE-1))
-- 
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 Feb 25 16:28:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA0ue-0002w2-24; Mon, 25 Feb 2013 16:28:24 +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 1UA0ud-0002vS-4X
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:23 +0000
Received: from [193.109.254.147:64374] by server-15.bemta-14.messagelabs.com
	id 64/D0-24599-6219B215; Mon, 25 Feb 2013 16:28:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361809686!2832349!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28955 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:08 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4uC014581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS42x014839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS3Kv028955; Mon, 25 Feb 2013 10:28:03 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87E8A1C3937; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:54 -0500
Message-Id: <1361809680-10075-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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>
Subject: [Xen-devel] [PATCH 1/7] docs: Document the ELF notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Acked-by: Ian Campbell <ian.campbel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/elfnote.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 42d76da..3c57a06 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -28,6 +28,8 @@
 #define __XEN_PUBLIC_ELFNOTE_H__
 
 /*
+ * `incontents 200 elfnotes ELF notes
+ *
  * The notes should live in a PT_NOTE segment and have "Xen" in the
  * name field.
  *
-- 
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 Feb 25 16:28:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA0ue-0002w2-24; Mon, 25 Feb 2013 16:28:24 +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 1UA0ud-0002vS-4X
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:23 +0000
Received: from [193.109.254.147:64374] by server-15.bemta-14.messagelabs.com
	id 64/D0-24599-6219B215; Mon, 25 Feb 2013 16:28:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361809686!2832349!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28955 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:08 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4uC014581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS42x014839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS3Kv028955; Mon, 25 Feb 2013 10:28:03 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87E8A1C3937; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:54 -0500
Message-Id: <1361809680-10075-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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>
Subject: [Xen-devel] [PATCH 1/7] docs: Document the ELF notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Mark-up for inclusion of generated docs.

Acked-by: Ian Campbell <ian.campbel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/elfnote.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 42d76da..3c57a06 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -28,6 +28,8 @@
 #define __XEN_PUBLIC_ELFNOTE_H__
 
 /*
+ * `incontents 200 elfnotes ELF notes
+ *
  * The notes should live in a PT_NOTE segment and have "Xen" in the
  * name field.
  *
-- 
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 Feb 25 16:28:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA0uc-0002vQ-KJ; Mon, 25 Feb 2013 16:28:22 +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 1UA0ua-0002ul-SK
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:21 +0000
Received: from [193.109.254.147:22747] by server-1.bemta-14.messagelabs.com id
	00/A0-29874-4219B215; Mon, 25 Feb 2013 16:28:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361809687!2832352!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28975 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4Gp014580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4AQ020444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS47p029360; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 93CBE1C3939; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:56 -0500
Message-Id: <1361809680-10075-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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 3/7] docs: Add some extra details to the ELF
	note.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Such as how the string values MUST be NULL terminated ASCII.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/elfnote.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 3c57a06..6cb2ded 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -38,6 +38,9 @@
  *
  * LEGACY indicated the fields in the legacy __xen_guest string which
  * this a note type replaces.
+ *
+ * String values (for non-legacy) are NULL terminated ASCII, also known
+ * as ASCIZ type.
  */
 
 /*
@@ -160,6 +163,9 @@
 
 /*
  * Whether or not the guest supports cooperative suspend cancellation.
+ * This is a numeric value.
+ *
+ * Default is 0
  */
 #define XEN_ELFNOTE_SUSPEND_CANCEL 14
 
-- 
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 Feb 25 16:28:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA0uc-0002vQ-KJ; Mon, 25 Feb 2013 16:28:22 +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 1UA0ua-0002ul-SK
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:21 +0000
Received: from [193.109.254.147:22747] by server-1.bemta-14.messagelabs.com id
	00/A0-29874-4219B215; Mon, 25 Feb 2013 16:28:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361809687!2832352!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28975 invoked from network); 25 Feb 2013 16:28:08 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4Gp014580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4AQ020444
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS47p029360; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 93CBE1C3939; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:56 -0500
Message-Id: <1361809680-10075-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-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 3/7] docs: Add some extra details to the ELF
	note.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Such as how the string values MUST be NULL terminated ASCII.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/include/public/elfnote.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 3c57a06..6cb2ded 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -38,6 +38,9 @@
  *
  * LEGACY indicated the fields in the legacy __xen_guest string which
  * this a note type replaces.
+ *
+ * String values (for non-legacy) are NULL terminated ASCII, also known
+ * as ASCIZ type.
  */
 
 /*
@@ -160,6 +163,9 @@
 
 /*
  * Whether or not the guest supports cooperative suspend cancellation.
+ * This is a numeric value.
+ *
+ * Default is 0
  */
 #define XEN_ELFNOTE_SUSPEND_CANCEL 14
 
-- 
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 Feb 25 16:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0ur-00032w-5P; Mon, 25 Feb 2013 16:28:37 +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 1UA0up-00031u-Iu
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:35 +0000
Received: from [85.158.137.99:34609] by server-1.bemta-3.messagelabs.com id
	49/C3-08955-2319B215; Mon, 25 Feb 2013 16:28:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361809686!17139729!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13418 invoked from network); 25 Feb 2013 16:28:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:28:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4ef014579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4KE009529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS4a9003298; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 83D271C391E; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:53 -0500
Message-Id: <1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] =?utf-8?q?=5BPATCH_to_X86_PV_MMU_Wiki_v2=5D_Expand_th?=
	=?utf-8?q?e_bootup_section_to_include_ELF_and_memory_layout?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

djI6IEludGVncmF0ZSBJYW4ncyBjb21tZW50cy4KClNpZ25lZC1vZi1ieTogS29ucmFkIFJ6ZXN6
dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpkaWZmIC0tZ2l0IGEvaW50cm8udHh0
IGIvaW50cm8udHh0CmluZGV4IDhhMTZmOTIuLmZjODBlZjYgMTAwNjQ0Ci0tLSBhL2ludHJvLnR4
dAorKysgYi9pbnRyby50eHQKQEAgLTMzOSw2ICszMzksMTczIEBAIGludG8gdGhlIHBhZ2UgdGFi
bGUgYmFzZSByZWdpc3RlciBidXQgd2lsbCBub3QgYmUgZXhwbGljaXRseSBwaW5uZWQuCiBUaGUg
aW5pdGlhbCB2aXJ0dWFsIGFuZCBwc2V1ZG8tcGh5c2ljYWwgbGF5b3V0IG9mIGEgbmV3IGd1ZXN0
IGlzCiBkZXNjcmliZWQgW2h0dHA6Ly94ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBl
cmNhbGwvaW5jbHVkZSxwdWJsaWMseGVuLmguaHRtbCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXkgaGVy
ZV0uCiAKKworV2hlbiBndWVzdCBoYXMgc3RhcnRlZCwgdGhlIGtlcm5lbCBpbWFnZSBpcyByZWFk
IGFuZCB0aGUgRUxGIChQVF9OT1RFKSBwcm9ncmFtIGlzCitwYXJzZWQuVGhlIGh5cGVydmlzb3Ig
bG9va3MgaW4gdGhlIC5ub3RlIHNlY3Rpb25zCitmb3IgdGhlICdYZW4nIE5VTEwgdGVybWluYXRl
ZCBub3Rlcy4gVGhlIGRlc2NyaXB0aW9uIGZpZWxkcyBjb250YWluIHRoZQorcmVxdWlyZWQgaW5m
b3JtYXRpb24gdG8gZmluZCBvdXQ6IHdoZXJlIHRoZSBrZXJuZWwgZXhwZWN0cyBpdHMgdmlydHVh
bCBiYXNlIGFkZHJlc3MsCit3aGF0IHR5cGUgb2YgaHlwZXJ2aXNvciBpdCBjYW4gd29yayB3aXRo
LCBjZXJ0YWluIGZlYXR1cmVzIHRoZSBrZXJuZWwgaW1hZ2UKK2NhbiBzdXBwb3J0LCBhbmQgdGhl
IGxvY2F0aW9uIG9mIHRoZSBoeXBlcmNhbGwgcGFnZS4gVGhlcmUgYXJlIHR3byB2YXJpYW50cyBv
ZiB0aGlzOgorCis7IGEpLiBBIOKAnC5ub3RlLlhlbuKAnSBzZWN0aW9uIGluIEVMRiBoZWFkZXIg
Y29uZm9ybWluZyB0byB0aGUgRUxGIFBUX05PVEUgZm9ybWF0LgorVGhlIFBUX05PVEUgaGVhZGVy
IGlzIGRlc2NyaWJlZCBpbiBbaHR0cDovL3d3dy5uZXRic2Qub3JnL2RvY3Mva2VybmVsL2VsZi1u
b3Rlcy5odG1sXQorYW5kIGluIFtodHRwOi8vd3d3LnNjby5jb20vZGV2ZWxvcGVycy9nYWJpL2xh
dGVzdC9jb250ZW50cy5odG1sXQorCitUaGUgdHlwZSBmaWVsZCAoTmFtZSwgRGVzYywgVHlwZSkg
YXJlIG9mIHRoZSBFTEYgc3BlY2lmaWNhdGlvbi4gVGhlIHNwZWNpZmljCit0eXBlIHZhbHVlcyBh
bmQgdGhlIGRlc2NyaXB0aW9uIGlzIGRlZmluZWQgYnkgWGVuLgorCitUaGlzIHN0cnVjdHVyZSBp
cyBhIDQtYnl0ZSBhbGlnbmVkIHN0cnVjdHVyZS4gRmlyc3Qgc2VjdGlvbiBpcyBhbiBudW1lcmlj
YWwKK2tleSAoYWxpZ25lZCB0byA0IGJ5dGVzKTsgZm9sbG93ZWQgYnkgZWl0aGVyIGEgc3RyaW5n
IG9yIGEgbnVtZXJpY2FsIHZhbHVlCisoYWdhaW4sIGFsaWduZWQgdG8gNCBieXRlcykuIFRoZSB2
YWx1ZXMgY2FuIHVwIHRvIGFueSBsZW5ndGgsIGlmIHRoZSBrZXkgaXMKK2Fzc3VtZWQgdG8gYSBz
dHJpbmcuIElmIGl0IGlzIGEgbnVtZXJpY2FsIHZhbHVlLCBpdCBpcyBhIGxvbmcKKyg2NC1iaXQg
dmFsdWUgLSB3aGljaCBtZWFucyA4IGJ5dGVzKS4KKworRm9yIGV4YW1wbGUgdGhpcyBYRU5fRUxG
Tk9URV9YRU5fVkVSU0lPTiAoNSkgd2l0aCB0aGUgdmFsdWUgb2YgInhlbi0zLjAiOgorCisgIDA0
MDAwMDAwIDA4MDAwMDAwIDA1MDAwMDAwIDU4NjU2ZTAwIDc4NjU2ZTJkIDMzMmUzMDAwIC4uLi4u
Li4uWGVuLnhlbi0zLjAKKworVXNpbmcgcmVhZC1lbGYgd291bGQgcHJpbnQgb3V0IGFzIGEgZWln
aHQtYnl0ZSBsZW5ndGggdmFsdWUgd2l0aCB0eXBlIDU6CisKKyAgWGVuICAgICAgICAgICAgICAg
ICAgMHgwMDAwMDAwOAlVbmtub3duIG5vdGUgdHlwZTogKDB4MDAwMDAwMDUpCisKKzsgYikuIFRo
ZSBsZWdhY3kgQVNDSUlaIHN0cmluZyB3aXRoIGFsbCBvZiB0aGUga2V5cyBjb25jYXRlbmF0ZWQu
IEVhY2gga2V5CitiZWluZyBhIHN0cmluZyBhbmQgdGhlIGVxdWFsIHNpZ24gd2l0aCB0aGUgdmFs
dWUgYWxzbyBiZWluZyBhbiBzdHJpbmcKKyhudW1lcmljIHZhbHVlcyBhcmUgdHlwZWQgYXMgaGV4
YWRlY2ltYWwgc3RyaW5ncykuIFRoZSBkZWxpbWl0ZXIgaXMgYSBjb21tYS4KK1RoZSBrZXkgY2Fu
IGJlIHVwIHRvIDMyIGNoYXJhY3RlcnMgYW5kIHRoZSB2YWx1ZSB1cCB0byAxMjggY2hhcmFjdGVy
cy4KK0ZvciBleGFtcGxlOgorCisJR1VFU1RfT1M9TWluaS1PUyxYRU5fVkVSPXhlbi0zLjAsVklS
VF9CQVNFPTB4MCxFTEZfUEFERFJfT0ZGU0VUPTB4MCxIWVBFUkNBTExfUEFHRT0weDIsTE9BREVS
PWdlbmVyaWMKKworCitUaGUgbGVnYWN5IHNob3VsZCBub3QgYmUgdXNlZCBhcyBpdCBoYXMgbGlt
aXRlZCB2YWx1ZXMgdGhhdCBjYW4KK2JlIHVzZWQgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIGlzIGZy
b3plbi4KKworVGhlIHBhcmFtZXRlcnMgYW5kIGl0cyBwdXJwb3NlIGFyZSBleHBsYWluZWQgaW4K
K1todHRwOi8veGVuYml0cy54ZW4ub3JnL2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUs
cHVibGljLGVsZm5vdGUuaC5odG1sI2luY29udGVudHNfZWxmbm90ZSBoZXJlXS4KKworQW5kIHRo
ZSBYRU5fRUxGX0ZFQVRVUkVTIHZhbHVlcyBhcmUgZXhwbGFpbmVkIGluCitbaHR0cDovL3hlbmJp
dHMueGVuLm9yZy9kb2NzL3Vuc3RhYmxlL2h5cGVyY2FsbC9pbmNsdWRlLHB1YmxpYyxmZWF0dXJl
cy5oLmh0bWwjaW5jb250ZW50c19lbGZub3RlX2ZlYXR1cmVzIGhlcmVdLgorCitGb3IgZXhhbXBs
ZSwgaWYgdGhlIEVMRiB2YWx1ZXMgd2VyZSBhcyBzbzoKKwore3wgYm9yZGVyPSIxIiBjZWxscGFk
ZGluZz0iMiIgY2VsbHNwYWNpbmc9IjAiCisgfCBOYW1lIG9mIFhlbiBFTEYgZW50cnkKKyB8IENv
bnRlbnRzCisgfC0KKyB8IFhFTl9FTEZOT1RFX0dVRVNUX09TICg2KQorIHwgbGludXgKKyB8LQor
IHwgWEVOX0VMRk5PVEVfR1VFU1RfVkVSU0lPTiAoNykKKyB8IDIuNgorIHwtCisgfCBYRU5fRUxG
Tk9URV9YRU5fVkVSU0lPTiAoNSkKKyB8IHhlbi0zLjAKKyB8LQorIHwgWEVOX0VMRk5PVEVfVklS
VF9CQVNFICgzKQorIHwgMHhmZmZmZmZmZjgwMDAwMDAwCisgfC0KKyB8IFhFTl9FTEZOT1RFX0VO
VFJZICgxKQorIHwgMHhmZmZmZmZmZjgxODk5MjAwCisgfC0KKyB8IFhFTl9FTEZOT1RFX0hZUEVS
Q0FMTF9QQUdFICgyKQorIHwgMHhmZmZmZmZmZjgxMDAxMDAwCisgfC0KKyB8IFhFTl9FTEZOT1RF
X0ZFQVRVUkVTICgxMCkKKyB8ICF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVf
NGdiCisgfC0KKyB8IFhFTl9FTEZOT1RFX1BBRV9NT0RFICg5KQorIHwgeWVzCisgfC0KKyB8IFhF
Tl9FTEZOT1RFX0xPQURFUiAoOCkKKyB8IGdlbmVyaWMKKyB8LQorIHwgWEVOX0VMRk5PVEVfU1VT
UEVORF9DQU5DRUwgKDE0KQorIHwgMQorIHwtCisgfCBYRU5fRUxGTk9URV9IVl9TVEFSVF9MT1cK
KyB8IDB4ZmZmZjgwMDAwMDAwMDAwMAorIHwtCisgfCBYRU5fRUxGTk9URV9QQUREUl9PRkZTRVQK
KyB8IDAKKyB8fQorCitXaXRoIHRoYXQgc2V0dXAsIHRoZSBoeXBlcnZpc29yIGNvbnN0cnVjdHMg
YW4gaW5pdGlhbCBwYWdlIHRhYmxlIHRoYXQgc3BhbnMgdGhlCityZWdpb24gZnJvbSB2aXJ0dWFs
IHN0YXJ0IGFkZHJlc3MgdXAgKDB4ZmZmZmZmZmY4MDAwMDAwMCkgdG8gdGhlIGVuZCBvZiB0aGUK
K3AybSBtYXAuCisKK1VzaW5nIHRoYXQgRUxGIHByb2dyYW0gaGVhZGVyIGluZm9ybWF0aW9uLCB0
aGUgaHlwZXJ2aXNvciAob3IgdG9vbHN0YWNrKQorY29uc3RydWN0cyB0aGUgZG9tYWluIHdpdGgg
dGhlIGFwcHJvcGlhdGVseSBsb2NhdGVkIGRhdGEuIFRoaXMgRUxGIGRhdGEKK2lzIHVzZWQgdG8g
Y29uc3RydWN0IGEgZ3Vlc3Qgd2hpY2ggaXMgbGFpZCBvdXQgYXMgZW51bWVyYXRlZCBpbiB0aGlz
CitoZWFkZXI6CitbaHR0cDovL3hlbmJpdHMueGVuLm9yZy9kb2NzL3Vuc3RhYmxlL2h5cGVyY2Fs
bC9pbmNsdWRlLHB1YmxpYyx4ZW4uaC5odG1sI2luY29udGVudHNfc3RhcnRvZmRheV0KKworTk9U
RTogVGhpcyBpcyBhbiBleGFtcGxlIG9mIGEgNjQtYml0IGd1ZXN0IGFuZCBub3QgcGFydCBvZiB0
aGUgQUJJLgorCit7fCBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMCIK
KyB8IFBhZ2UgRnJhbWUgKFBGTikKKyB8IFZpcnR1YWwgQWRkcmVzcworIHwgY29udGVudHMKKyB8
LQorIHwgMHgwCisgfCAweGZmZmZmZmZmODAwMDAwMDAKKyB8IGxvY2F0aW9uIG9mIFtodHRwOi8v
eGVuYml0cy54ZW4ub3JnL2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUscHVibGljLHhl
bi5oLmh0bWwjaW5jb250ZW50c19zdGFydG9mZGF5X3NoYXJlZCBzdHJ1Y3Qgc2hhcmVkX2luZm9d
LiBUaGUgMy5kIGVudHJ5IChzdGFydF9pbmZvX3QpIGNvbnRhaW5zIHRoZSBtYWNoaW5lIGFkZHJl
c3Mgb2YgdGhpcyBzdHJ1Y3R1cmUuCisgfC0KKyB8IDB4MTAwMAorIHwgMHhmZmZmZmZmZjgxMDAw
MDAwCisgfCBsb2NhdGlvbiBvZiB0aGUga2VybmVsCisgfC0KKyB8IDB4MTAwMQorIHwgMHhmZmZm
ZmZmZjgxMDAxMDAwCisgfCBsb2NhdGlvbiBvZiB0aGUgaHlwZXJjYWxsIHdpdGhpbiB0aGUga2Vy
bmVsCisgfC0KKyB8IDB4MUUzRQorIHwgMHhmZmZmZmZmZjgxZTNlMDAwCisgfCByYW1kaXNrIChO
T1RFOiBUaGlzIGlzIGFuIGV4YW1wbGUgYW5kIHRoZSBrZXJuZWwgc2l6ZSBvciByYW1kaXNrIHdp
bGwgZGlmZmVyKQorIHwtCisgfCAweEZDNjkKKyB8IDB4ZmZmZmZmZmY4ZmM2OTAwMAorIHwgKE5P
VEUpOiBUaGlzIGlzIGFuIGV4YW1wbGUgYW5kIGJhc2VkIG9uIHRoZSBzaXplIG9mIHRoZSBrZXJu
ZWwgYW5kIHJhbWRpc2sgYW5kIHdpbGwgZGlmZmVyKS4gcGh5czJtYWNoIChQMk0pIC0gYW4gYXJy
YXkgb2YgbWFjaGluZSBmcmFtZSBudW1iZXJzLiBUaGUgdG90YWwgc2l6ZSBvZiB0aGlzIGFycmF5
IGlzIGRlcGVuZGVudCBvbiB0aGUgbnJfcGFnZXMgaW4KK1todHRwOi8veGVuYml0cy54ZW4ub3Jn
L2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUscHVibGljLHhlbi5oLmh0bWwjaW5jb250
ZW50c19zdGFydG9mZGF5IHN0cnVjdCBzdGFydF9pbmZvXQorYW5kIHRoZSBhcmNoaXRlY3R1cmUg
b2YgdGhlIGd1ZXN0IChlYWNoIGVudHJ5IGlzIGZvdXIgYnl0ZXMKK3VuZGVyIDMyLWJpdCBrZXJu
ZWxzIGFuZCBlaWdodCBieXRlcyB1bmRlciA2NC1iaXQga2VybmVscykuCisgfC0KKyB8IDB4RkNF
OQorIHwgMHhmZmZmZmZmZjhmY2U5MDAwCisgfCBsb2NhdGlvbiBvZgorW2h0dHA6Ly94ZW5iaXRz
Lnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMseGVuLmguaHRt
bCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXkgc3RhcnRfaW5mbyBzdHJ1Y3R1cmVdCisgfC0KKyB8IDB4
RkNFQQorIHwgMHhmZmZmZmZmZjhmY2VhMDAwCisgfCBsb2NhdGlvbiBvZgorW2h0dHA6Ly94ZW5i
aXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMsaW8seHNf
d2lyZS5oLmh0bWwjaW5jb250ZW50c194ZW5zdG9yZV9zdHJ1Y3QgWGVuU3RvcmUgc3RydWN0dXJl
XS4KK0Fsc28gcmVmZXIgdG8gaHR0cDovL3hlbmJpdHMueGVuLm9yZy9kb2NzL3Vuc3RhYmxlL21p
c2MveGVuc3RvcmUudHh0CisgfC0KKyB8IDB4RkNFQgorIHwgMHhmZmZmZmZmZjhmY2ViMDAwCisg
fCBEZXBlbmRpbmcgb24gdGhlIHR5cGUgb2YgdGhlIGd1ZXN0IChpbml0aWFsIGRvbWFpbiBvciBz
dWJzZXF1ZW50IGRvbWFpbnMpLCBpdCBjYW4gZWl0aGVyIGJlIHRoZQorW2h0dHA6Ly94ZW5iaXRz
Lnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMseGVuLmguaHRt
bCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXlfZG9tMF9jb25zb2xlIGRvbTBfdmdhX2NvbnNvbGVfaW5m
byBzdHJ1Y3R1cmVdCitvciAKK1todHRwOi8veGVuYml0cy54ZW4ub3JnL2RvY3MvdW5zdGFibGUv
aHlwZXJjYWxsL2luY2x1ZGUscHVibGljLGlvLGNvbnNvbGUuaC5odG1sIFhlbkNvbnNvbGUgc3Ry
dWN0dXJlXS4KK1RoZSBwYXJhbWV0ZXJzIGRlZmluaW5nIHRoaXMgbG9jYXRpb24gYXJlIGluIHRo
ZQorW2h0dHA6Ly94ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVk
ZSxwdWJsaWMseGVuLmguaHRtbCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXkgc3RhcnRfaW5mbyBzdHJ1
Y3R1cmVdCisgfC0KKyB8IDB4RkNFQworIHwgMHhmZmZmZmZmZjhmY2ZjMDAwCisgfCBib290c3Ry
YXAgcGFnZSB0YWJsZXMuIFRoZXNlIHBhZ2V0YWJsZXMgYXJlIGxvYWRlZCBpbiB0aGUgZ3Vlc3Qg
YXQgc3RhcnR1cAorYW5kIGNvdmVyIGZyb20gMHgwIHVwIHRvIDB4RkQ2ZiAodGhlIGJvb3RzdGFj
aykuCisgfC0KKyB8IDB4RkQ2RgorIHwgMHhmZmZmZmZmZjhmZDZmMDAwCisgfCBib290c3RyYXAg
c3RhY2suCisgfH0KKworV2hlbiB0aGUgZ3Vlc3QgaXMgbGF1bmNoZWQsIHBlcgorW2h0dHA6Ly94
ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMseGVu
LmguaHRtbCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXldCitleHBsYW5hdGlvbiwgdGhlIHJlZ2lzdGVy
ICVlc2kgY29udGFpbnMgdGhlIHZpcnR1YWwgYWRkcmVzcyB0byB0aGUKK3N0YXJ0X2luZm9fdCAo
MHhmZmZmZmZmZjhmY2U5MDAwKSwgdGhlICVjcjMgcG9pbnRzIHRvIHRoZSBiZWdpbm5pbmcgb2Yg
dGhlCitib290c3RyYXAgcGFnZS10YWJsZXMgKDB4ZmZmZmZmZmY4ZmNmYzAwMCksIGFuZCB0aGUg
JWVzcCBwb2ludHMgdG8gdGhlCitib290c3RyYXAgc3RhY2sgKDB4ZmZmZmZmZmY4ZmQ2ZjAwMCku
CisKID0gVmlydHVhbCBBZGRyZXNzIFNwYWNlID0KIAogWGVuIGVuZm9yY2VzIGNlcnRhaW4gcmVz
dHJpY3Rpb25zIG9uIHRoZSB2aXJ0dWFsIGFkZHJlc3NlcyB3aGljaCBhcmUKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0ur-00032w-5P; Mon, 25 Feb 2013 16:28:37 +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 1UA0up-00031u-Iu
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:35 +0000
Received: from [85.158.137.99:34609] by server-1.bemta-3.messagelabs.com id
	49/C3-08955-2319B215; Mon, 25 Feb 2013 16:28:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361809686!17139729!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13418 invoked from network); 25 Feb 2013 16:28:33 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:28:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS4ef014579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4KE009529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS4a9003298; Mon, 25 Feb 2013 10:28:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 83D271C391E; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:53 -0500
Message-Id: <1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
In-Reply-To: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] =?utf-8?q?=5BPATCH_to_X86_PV_MMU_Wiki_v2=5D_Expand_th?=
	=?utf-8?q?e_bootup_section_to_include_ELF_and_memory_layout?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

djI6IEludGVncmF0ZSBJYW4ncyBjb21tZW50cy4KClNpZ25lZC1vZi1ieTogS29ucmFkIFJ6ZXN6
dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpkaWZmIC0tZ2l0IGEvaW50cm8udHh0
IGIvaW50cm8udHh0CmluZGV4IDhhMTZmOTIuLmZjODBlZjYgMTAwNjQ0Ci0tLSBhL2ludHJvLnR4
dAorKysgYi9pbnRyby50eHQKQEAgLTMzOSw2ICszMzksMTczIEBAIGludG8gdGhlIHBhZ2UgdGFi
bGUgYmFzZSByZWdpc3RlciBidXQgd2lsbCBub3QgYmUgZXhwbGljaXRseSBwaW5uZWQuCiBUaGUg
aW5pdGlhbCB2aXJ0dWFsIGFuZCBwc2V1ZG8tcGh5c2ljYWwgbGF5b3V0IG9mIGEgbmV3IGd1ZXN0
IGlzCiBkZXNjcmliZWQgW2h0dHA6Ly94ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBl
cmNhbGwvaW5jbHVkZSxwdWJsaWMseGVuLmguaHRtbCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXkgaGVy
ZV0uCiAKKworV2hlbiBndWVzdCBoYXMgc3RhcnRlZCwgdGhlIGtlcm5lbCBpbWFnZSBpcyByZWFk
IGFuZCB0aGUgRUxGIChQVF9OT1RFKSBwcm9ncmFtIGlzCitwYXJzZWQuVGhlIGh5cGVydmlzb3Ig
bG9va3MgaW4gdGhlIC5ub3RlIHNlY3Rpb25zCitmb3IgdGhlICdYZW4nIE5VTEwgdGVybWluYXRl
ZCBub3Rlcy4gVGhlIGRlc2NyaXB0aW9uIGZpZWxkcyBjb250YWluIHRoZQorcmVxdWlyZWQgaW5m
b3JtYXRpb24gdG8gZmluZCBvdXQ6IHdoZXJlIHRoZSBrZXJuZWwgZXhwZWN0cyBpdHMgdmlydHVh
bCBiYXNlIGFkZHJlc3MsCit3aGF0IHR5cGUgb2YgaHlwZXJ2aXNvciBpdCBjYW4gd29yayB3aXRo
LCBjZXJ0YWluIGZlYXR1cmVzIHRoZSBrZXJuZWwgaW1hZ2UKK2NhbiBzdXBwb3J0LCBhbmQgdGhl
IGxvY2F0aW9uIG9mIHRoZSBoeXBlcmNhbGwgcGFnZS4gVGhlcmUgYXJlIHR3byB2YXJpYW50cyBv
ZiB0aGlzOgorCis7IGEpLiBBIOKAnC5ub3RlLlhlbuKAnSBzZWN0aW9uIGluIEVMRiBoZWFkZXIg
Y29uZm9ybWluZyB0byB0aGUgRUxGIFBUX05PVEUgZm9ybWF0LgorVGhlIFBUX05PVEUgaGVhZGVy
IGlzIGRlc2NyaWJlZCBpbiBbaHR0cDovL3d3dy5uZXRic2Qub3JnL2RvY3Mva2VybmVsL2VsZi1u
b3Rlcy5odG1sXQorYW5kIGluIFtodHRwOi8vd3d3LnNjby5jb20vZGV2ZWxvcGVycy9nYWJpL2xh
dGVzdC9jb250ZW50cy5odG1sXQorCitUaGUgdHlwZSBmaWVsZCAoTmFtZSwgRGVzYywgVHlwZSkg
YXJlIG9mIHRoZSBFTEYgc3BlY2lmaWNhdGlvbi4gVGhlIHNwZWNpZmljCit0eXBlIHZhbHVlcyBh
bmQgdGhlIGRlc2NyaXB0aW9uIGlzIGRlZmluZWQgYnkgWGVuLgorCitUaGlzIHN0cnVjdHVyZSBp
cyBhIDQtYnl0ZSBhbGlnbmVkIHN0cnVjdHVyZS4gRmlyc3Qgc2VjdGlvbiBpcyBhbiBudW1lcmlj
YWwKK2tleSAoYWxpZ25lZCB0byA0IGJ5dGVzKTsgZm9sbG93ZWQgYnkgZWl0aGVyIGEgc3RyaW5n
IG9yIGEgbnVtZXJpY2FsIHZhbHVlCisoYWdhaW4sIGFsaWduZWQgdG8gNCBieXRlcykuIFRoZSB2
YWx1ZXMgY2FuIHVwIHRvIGFueSBsZW5ndGgsIGlmIHRoZSBrZXkgaXMKK2Fzc3VtZWQgdG8gYSBz
dHJpbmcuIElmIGl0IGlzIGEgbnVtZXJpY2FsIHZhbHVlLCBpdCBpcyBhIGxvbmcKKyg2NC1iaXQg
dmFsdWUgLSB3aGljaCBtZWFucyA4IGJ5dGVzKS4KKworRm9yIGV4YW1wbGUgdGhpcyBYRU5fRUxG
Tk9URV9YRU5fVkVSU0lPTiAoNSkgd2l0aCB0aGUgdmFsdWUgb2YgInhlbi0zLjAiOgorCisgIDA0
MDAwMDAwIDA4MDAwMDAwIDA1MDAwMDAwIDU4NjU2ZTAwIDc4NjU2ZTJkIDMzMmUzMDAwIC4uLi4u
Li4uWGVuLnhlbi0zLjAKKworVXNpbmcgcmVhZC1lbGYgd291bGQgcHJpbnQgb3V0IGFzIGEgZWln
aHQtYnl0ZSBsZW5ndGggdmFsdWUgd2l0aCB0eXBlIDU6CisKKyAgWGVuICAgICAgICAgICAgICAg
ICAgMHgwMDAwMDAwOAlVbmtub3duIG5vdGUgdHlwZTogKDB4MDAwMDAwMDUpCisKKzsgYikuIFRo
ZSBsZWdhY3kgQVNDSUlaIHN0cmluZyB3aXRoIGFsbCBvZiB0aGUga2V5cyBjb25jYXRlbmF0ZWQu
IEVhY2gga2V5CitiZWluZyBhIHN0cmluZyBhbmQgdGhlIGVxdWFsIHNpZ24gd2l0aCB0aGUgdmFs
dWUgYWxzbyBiZWluZyBhbiBzdHJpbmcKKyhudW1lcmljIHZhbHVlcyBhcmUgdHlwZWQgYXMgaGV4
YWRlY2ltYWwgc3RyaW5ncykuIFRoZSBkZWxpbWl0ZXIgaXMgYSBjb21tYS4KK1RoZSBrZXkgY2Fu
IGJlIHVwIHRvIDMyIGNoYXJhY3RlcnMgYW5kIHRoZSB2YWx1ZSB1cCB0byAxMjggY2hhcmFjdGVy
cy4KK0ZvciBleGFtcGxlOgorCisJR1VFU1RfT1M9TWluaS1PUyxYRU5fVkVSPXhlbi0zLjAsVklS
VF9CQVNFPTB4MCxFTEZfUEFERFJfT0ZGU0VUPTB4MCxIWVBFUkNBTExfUEFHRT0weDIsTE9BREVS
PWdlbmVyaWMKKworCitUaGUgbGVnYWN5IHNob3VsZCBub3QgYmUgdXNlZCBhcyBpdCBoYXMgbGlt
aXRlZCB2YWx1ZXMgdGhhdCBjYW4KK2JlIHVzZWQgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIGlzIGZy
b3plbi4KKworVGhlIHBhcmFtZXRlcnMgYW5kIGl0cyBwdXJwb3NlIGFyZSBleHBsYWluZWQgaW4K
K1todHRwOi8veGVuYml0cy54ZW4ub3JnL2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUs
cHVibGljLGVsZm5vdGUuaC5odG1sI2luY29udGVudHNfZWxmbm90ZSBoZXJlXS4KKworQW5kIHRo
ZSBYRU5fRUxGX0ZFQVRVUkVTIHZhbHVlcyBhcmUgZXhwbGFpbmVkIGluCitbaHR0cDovL3hlbmJp
dHMueGVuLm9yZy9kb2NzL3Vuc3RhYmxlL2h5cGVyY2FsbC9pbmNsdWRlLHB1YmxpYyxmZWF0dXJl
cy5oLmh0bWwjaW5jb250ZW50c19lbGZub3RlX2ZlYXR1cmVzIGhlcmVdLgorCitGb3IgZXhhbXBs
ZSwgaWYgdGhlIEVMRiB2YWx1ZXMgd2VyZSBhcyBzbzoKKwore3wgYm9yZGVyPSIxIiBjZWxscGFk
ZGluZz0iMiIgY2VsbHNwYWNpbmc9IjAiCisgfCBOYW1lIG9mIFhlbiBFTEYgZW50cnkKKyB8IENv
bnRlbnRzCisgfC0KKyB8IFhFTl9FTEZOT1RFX0dVRVNUX09TICg2KQorIHwgbGludXgKKyB8LQor
IHwgWEVOX0VMRk5PVEVfR1VFU1RfVkVSU0lPTiAoNykKKyB8IDIuNgorIHwtCisgfCBYRU5fRUxG
Tk9URV9YRU5fVkVSU0lPTiAoNSkKKyB8IHhlbi0zLjAKKyB8LQorIHwgWEVOX0VMRk5PVEVfVklS
VF9CQVNFICgzKQorIHwgMHhmZmZmZmZmZjgwMDAwMDAwCisgfC0KKyB8IFhFTl9FTEZOT1RFX0VO
VFJZICgxKQorIHwgMHhmZmZmZmZmZjgxODk5MjAwCisgfC0KKyB8IFhFTl9FTEZOT1RFX0hZUEVS
Q0FMTF9QQUdFICgyKQorIHwgMHhmZmZmZmZmZjgxMDAxMDAwCisgfC0KKyB8IFhFTl9FTEZOT1RF
X0ZFQVRVUkVTICgxMCkKKyB8ICF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVf
NGdiCisgfC0KKyB8IFhFTl9FTEZOT1RFX1BBRV9NT0RFICg5KQorIHwgeWVzCisgfC0KKyB8IFhF
Tl9FTEZOT1RFX0xPQURFUiAoOCkKKyB8IGdlbmVyaWMKKyB8LQorIHwgWEVOX0VMRk5PVEVfU1VT
UEVORF9DQU5DRUwgKDE0KQorIHwgMQorIHwtCisgfCBYRU5fRUxGTk9URV9IVl9TVEFSVF9MT1cK
KyB8IDB4ZmZmZjgwMDAwMDAwMDAwMAorIHwtCisgfCBYRU5fRUxGTk9URV9QQUREUl9PRkZTRVQK
KyB8IDAKKyB8fQorCitXaXRoIHRoYXQgc2V0dXAsIHRoZSBoeXBlcnZpc29yIGNvbnN0cnVjdHMg
YW4gaW5pdGlhbCBwYWdlIHRhYmxlIHRoYXQgc3BhbnMgdGhlCityZWdpb24gZnJvbSB2aXJ0dWFs
IHN0YXJ0IGFkZHJlc3MgdXAgKDB4ZmZmZmZmZmY4MDAwMDAwMCkgdG8gdGhlIGVuZCBvZiB0aGUK
K3AybSBtYXAuCisKK1VzaW5nIHRoYXQgRUxGIHByb2dyYW0gaGVhZGVyIGluZm9ybWF0aW9uLCB0
aGUgaHlwZXJ2aXNvciAob3IgdG9vbHN0YWNrKQorY29uc3RydWN0cyB0aGUgZG9tYWluIHdpdGgg
dGhlIGFwcHJvcGlhdGVseSBsb2NhdGVkIGRhdGEuIFRoaXMgRUxGIGRhdGEKK2lzIHVzZWQgdG8g
Y29uc3RydWN0IGEgZ3Vlc3Qgd2hpY2ggaXMgbGFpZCBvdXQgYXMgZW51bWVyYXRlZCBpbiB0aGlz
CitoZWFkZXI6CitbaHR0cDovL3hlbmJpdHMueGVuLm9yZy9kb2NzL3Vuc3RhYmxlL2h5cGVyY2Fs
bC9pbmNsdWRlLHB1YmxpYyx4ZW4uaC5odG1sI2luY29udGVudHNfc3RhcnRvZmRheV0KKworTk9U
RTogVGhpcyBpcyBhbiBleGFtcGxlIG9mIGEgNjQtYml0IGd1ZXN0IGFuZCBub3QgcGFydCBvZiB0
aGUgQUJJLgorCit7fCBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMCIK
KyB8IFBhZ2UgRnJhbWUgKFBGTikKKyB8IFZpcnR1YWwgQWRkcmVzcworIHwgY29udGVudHMKKyB8
LQorIHwgMHgwCisgfCAweGZmZmZmZmZmODAwMDAwMDAKKyB8IGxvY2F0aW9uIG9mIFtodHRwOi8v
eGVuYml0cy54ZW4ub3JnL2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUscHVibGljLHhl
bi5oLmh0bWwjaW5jb250ZW50c19zdGFydG9mZGF5X3NoYXJlZCBzdHJ1Y3Qgc2hhcmVkX2luZm9d
LiBUaGUgMy5kIGVudHJ5IChzdGFydF9pbmZvX3QpIGNvbnRhaW5zIHRoZSBtYWNoaW5lIGFkZHJl
c3Mgb2YgdGhpcyBzdHJ1Y3R1cmUuCisgfC0KKyB8IDB4MTAwMAorIHwgMHhmZmZmZmZmZjgxMDAw
MDAwCisgfCBsb2NhdGlvbiBvZiB0aGUga2VybmVsCisgfC0KKyB8IDB4MTAwMQorIHwgMHhmZmZm
ZmZmZjgxMDAxMDAwCisgfCBsb2NhdGlvbiBvZiB0aGUgaHlwZXJjYWxsIHdpdGhpbiB0aGUga2Vy
bmVsCisgfC0KKyB8IDB4MUUzRQorIHwgMHhmZmZmZmZmZjgxZTNlMDAwCisgfCByYW1kaXNrIChO
T1RFOiBUaGlzIGlzIGFuIGV4YW1wbGUgYW5kIHRoZSBrZXJuZWwgc2l6ZSBvciByYW1kaXNrIHdp
bGwgZGlmZmVyKQorIHwtCisgfCAweEZDNjkKKyB8IDB4ZmZmZmZmZmY4ZmM2OTAwMAorIHwgKE5P
VEUpOiBUaGlzIGlzIGFuIGV4YW1wbGUgYW5kIGJhc2VkIG9uIHRoZSBzaXplIG9mIHRoZSBrZXJu
ZWwgYW5kIHJhbWRpc2sgYW5kIHdpbGwgZGlmZmVyKS4gcGh5czJtYWNoIChQMk0pIC0gYW4gYXJy
YXkgb2YgbWFjaGluZSBmcmFtZSBudW1iZXJzLiBUaGUgdG90YWwgc2l6ZSBvZiB0aGlzIGFycmF5
IGlzIGRlcGVuZGVudCBvbiB0aGUgbnJfcGFnZXMgaW4KK1todHRwOi8veGVuYml0cy54ZW4ub3Jn
L2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUscHVibGljLHhlbi5oLmh0bWwjaW5jb250
ZW50c19zdGFydG9mZGF5IHN0cnVjdCBzdGFydF9pbmZvXQorYW5kIHRoZSBhcmNoaXRlY3R1cmUg
b2YgdGhlIGd1ZXN0IChlYWNoIGVudHJ5IGlzIGZvdXIgYnl0ZXMKK3VuZGVyIDMyLWJpdCBrZXJu
ZWxzIGFuZCBlaWdodCBieXRlcyB1bmRlciA2NC1iaXQga2VybmVscykuCisgfC0KKyB8IDB4RkNF
OQorIHwgMHhmZmZmZmZmZjhmY2U5MDAwCisgfCBsb2NhdGlvbiBvZgorW2h0dHA6Ly94ZW5iaXRz
Lnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMseGVuLmguaHRt
bCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXkgc3RhcnRfaW5mbyBzdHJ1Y3R1cmVdCisgfC0KKyB8IDB4
RkNFQQorIHwgMHhmZmZmZmZmZjhmY2VhMDAwCisgfCBsb2NhdGlvbiBvZgorW2h0dHA6Ly94ZW5i
aXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMsaW8seHNf
d2lyZS5oLmh0bWwjaW5jb250ZW50c194ZW5zdG9yZV9zdHJ1Y3QgWGVuU3RvcmUgc3RydWN0dXJl
XS4KK0Fsc28gcmVmZXIgdG8gaHR0cDovL3hlbmJpdHMueGVuLm9yZy9kb2NzL3Vuc3RhYmxlL21p
c2MveGVuc3RvcmUudHh0CisgfC0KKyB8IDB4RkNFQgorIHwgMHhmZmZmZmZmZjhmY2ViMDAwCisg
fCBEZXBlbmRpbmcgb24gdGhlIHR5cGUgb2YgdGhlIGd1ZXN0IChpbml0aWFsIGRvbWFpbiBvciBz
dWJzZXF1ZW50IGRvbWFpbnMpLCBpdCBjYW4gZWl0aGVyIGJlIHRoZQorW2h0dHA6Ly94ZW5iaXRz
Lnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMseGVuLmguaHRt
bCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXlfZG9tMF9jb25zb2xlIGRvbTBfdmdhX2NvbnNvbGVfaW5m
byBzdHJ1Y3R1cmVdCitvciAKK1todHRwOi8veGVuYml0cy54ZW4ub3JnL2RvY3MvdW5zdGFibGUv
aHlwZXJjYWxsL2luY2x1ZGUscHVibGljLGlvLGNvbnNvbGUuaC5odG1sIFhlbkNvbnNvbGUgc3Ry
dWN0dXJlXS4KK1RoZSBwYXJhbWV0ZXJzIGRlZmluaW5nIHRoaXMgbG9jYXRpb24gYXJlIGluIHRo
ZQorW2h0dHA6Ly94ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVk
ZSxwdWJsaWMseGVuLmguaHRtbCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXkgc3RhcnRfaW5mbyBzdHJ1
Y3R1cmVdCisgfC0KKyB8IDB4RkNFQworIHwgMHhmZmZmZmZmZjhmY2ZjMDAwCisgfCBib290c3Ry
YXAgcGFnZSB0YWJsZXMuIFRoZXNlIHBhZ2V0YWJsZXMgYXJlIGxvYWRlZCBpbiB0aGUgZ3Vlc3Qg
YXQgc3RhcnR1cAorYW5kIGNvdmVyIGZyb20gMHgwIHVwIHRvIDB4RkQ2ZiAodGhlIGJvb3RzdGFj
aykuCisgfC0KKyB8IDB4RkQ2RgorIHwgMHhmZmZmZmZmZjhmZDZmMDAwCisgfCBib290c3RyYXAg
c3RhY2suCisgfH0KKworV2hlbiB0aGUgZ3Vlc3QgaXMgbGF1bmNoZWQsIHBlcgorW2h0dHA6Ly94
ZW5iaXRzLnhlbi5vcmcvZG9jcy91bnN0YWJsZS9oeXBlcmNhbGwvaW5jbHVkZSxwdWJsaWMseGVu
LmguaHRtbCNpbmNvbnRlbnRzX3N0YXJ0b2ZkYXldCitleHBsYW5hdGlvbiwgdGhlIHJlZ2lzdGVy
ICVlc2kgY29udGFpbnMgdGhlIHZpcnR1YWwgYWRkcmVzcyB0byB0aGUKK3N0YXJ0X2luZm9fdCAo
MHhmZmZmZmZmZjhmY2U5MDAwKSwgdGhlICVjcjMgcG9pbnRzIHRvIHRoZSBiZWdpbm5pbmcgb2Yg
dGhlCitib290c3RyYXAgcGFnZS10YWJsZXMgKDB4ZmZmZmZmZmY4ZmNmYzAwMCksIGFuZCB0aGUg
JWVzcCBwb2ludHMgdG8gdGhlCitib290c3RyYXAgc3RhY2sgKDB4ZmZmZmZmZmY4ZmQ2ZjAwMCku
CisKID0gVmlydHVhbCBBZGRyZXNzIFNwYWNlID0KIAogWGVuIGVuZm9yY2VzIGNlcnRhaW4gcmVz
dHJpY3Rpb25zIG9uIHRoZSB2aXJ0dWFsIGFkZHJlc3NlcyB3aGljaCBhcmUKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:28:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0up-000325-Gn; Mon, 25 Feb 2013 16:28:35 +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 1UA0uo-00031b-NW
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:34 +0000
Received: from [85.158.137.99:39271] by server-10.bemta-3.messagelabs.com id
	E0/2C-10609-D219B215; Mon, 25 Feb 2013 16:28:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361809696!14841232!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22533 invoked from network); 25 Feb 2013 16:28:24 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5nA014586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4Q9010054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS30Q028956; Mon, 25 Feb 2013 10:28:03 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 81BF81C3935; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:52 -0500
Message-Id: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [DOCS/PATCH v2]
	http://wiki.xen.org/wiki/X86_Paravirtualised_Memory_Management
	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 v2 of the patchset that I posted a month ago. The Wiki changes
are mentioned in the first (or zeroth?) patch. If folks are OK I put
that in the Wiki.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:28:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:28: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 1UA0up-000325-Gn; Mon, 25 Feb 2013 16:28:35 +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 1UA0uo-00031b-NW
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:28:34 +0000
Received: from [85.158.137.99:39271] by server-10.bemta-3.messagelabs.com id
	E0/2C-10609-D219B215; Mon, 25 Feb 2013 16:28:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361809696!14841232!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22533 invoked from network); 25 Feb 2013 16:28:24 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:28:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGS5nA014586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:28:05 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
	r1PGS4Q9010054
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:28:04 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
	r1PGS30Q028956; Mon, 25 Feb 2013 10:28:03 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:28:03 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 81BF81C3935; Mon, 25 Feb 2013 11:28:02 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Date: Mon, 25 Feb 2013 11:27:52 -0500
Message-Id: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [DOCS/PATCH v2]
	http://wiki.xen.org/wiki/X86_Paravirtualised_Memory_Management
	changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 v2 of the patchset that I posted a month ago. The Wiki changes
are mentioned in the first (or zeroth?) patch. If folks are OK I put
that in the Wiki.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:29:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:29: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 1UA0vv-0003XP-NK; Mon, 25 Feb 2013 16:29:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zulcss@gmail.com>) id 1UA0vu-0003Wo-O6
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:29:42 +0000
Received: from [85.158.139.83:41645] by server-10.bemta-5.messagelabs.com id
	D9/B1-23714-5719B215; Mon, 25 Feb 2013 16:29:41 +0000
X-Env-Sender: zulcss@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361809759!17591416!1
X-Originating-IP: [209.85.210.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12357 invoked from network); 25 Feb 2013 16:29:21 -0000
Received: from mail-ia0-f177.google.com (HELO mail-ia0-f177.google.com)
	(209.85.210.177)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:29:21 -0000
Received: by mail-ia0-f177.google.com with SMTP id o25so2614431iad.22
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 08:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=SldqnPEkmfv+ois/Z40rIZteSzm4XKB9tX1dv2RUgto=;
	b=MdoGgyulRGfLgdYJi2M1IwQdH8jhEzDm+l8zAx2eenCzjg8hJ92yA2VY5vV9VFuBbQ
	LWjRIrcLlu0F7L0FiZJiB0ZBVZTEjBtVa3YQrX6bRvuATIYfb6z1mxd6ZGlAQhhl5te6
	n3agLchbP9GAMQ2/NBb3buPFQK4tMriATySW/vub8pBXqerse2FU/QZgpZZK6rYM+ohm
	jMDddK976Pn1HAqwacXv/Izc93AWjjqeAWiCn8wmOe962ojDw9tXlrp0l5Ob91X7KhCq
	qitPauYcpsuULGdguiGopXVtgaKHb43Ny8BYP26hAoFqtUCmyUdDrhTc8uSb0yhY0CKF
	jNJA==
MIME-Version: 1.0
X-Received: by 10.50.181.136 with SMTP id dw8mr3725336igc.39.1361809759309;
	Mon, 25 Feb 2013 08:29:19 -0800 (PST)
Received: by 10.64.23.108 with HTTP; Mon, 25 Feb 2013 08:29:19 -0800 (PST)
In-Reply-To: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:29:19 -0500
Message-ID: <CAMJ5SagoP6OXhzDrZ5op0M2HHqDEytWBtMg6aNF0fpJX1BEtWQ@mail.gmail.com>
From: Chuck Short <zulcss@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 8:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
>> At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
>> > On Fri, 22 Feb 2013, AP wrote:
>> > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
>> > > >
>> > > >
>> > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > >
>> > > >> I think it could still be very useful to many people. If not on the
>> > > >> xen-unstable repository, it should still be published somewhere.
>> > > >> Maybe a link on the wiki or a blog article?
>> > > >
>> > > >
>> > > > I'm happy to tidy it up a bit if people think it is useful, and publish
>> > > > it wherever. From memory the impact on the main code base is a 3 line
>> > > > change to the Makefile, and doubtless I could minimise the other files
>> > > > too.
>> > >
>> > > This would be very useful for people trying to create their own
>> > > minimal Xen image. I have been struggling with this for the past few
>> > > days.
>> > >
>> > > http://xen.markmail.org/thread/dac5kkuliky5373l
>> >
>> > If there is a need for it and clearly the upstream Debian maintainers
>> > don't care either way, why shouldn't we add the minideb target to our
>> > own build system? If we are going to have a deb target anyway, we might
>> > as well make it a useful one...
>>
>> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
>> Debian/Ubuntu.  That would be much more widely useful, for a similar
>> amount of effort.
>
> 4.2.0 is already in Debian experimental.
>
> Ian.
>
>
4.2.0 is in Ubuntu raring as well.

chuck
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 25 16:29:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:29: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 1UA0vv-0003XP-NK; Mon, 25 Feb 2013 16:29:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zulcss@gmail.com>) id 1UA0vu-0003Wo-O6
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:29:42 +0000
Received: from [85.158.139.83:41645] by server-10.bemta-5.messagelabs.com id
	D9/B1-23714-5719B215; Mon, 25 Feb 2013 16:29:41 +0000
X-Env-Sender: zulcss@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361809759!17591416!1
X-Originating-IP: [209.85.210.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12357 invoked from network); 25 Feb 2013 16:29:21 -0000
Received: from mail-ia0-f177.google.com (HELO mail-ia0-f177.google.com)
	(209.85.210.177)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:29:21 -0000
Received: by mail-ia0-f177.google.com with SMTP id o25so2614431iad.22
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 08:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=SldqnPEkmfv+ois/Z40rIZteSzm4XKB9tX1dv2RUgto=;
	b=MdoGgyulRGfLgdYJi2M1IwQdH8jhEzDm+l8zAx2eenCzjg8hJ92yA2VY5vV9VFuBbQ
	LWjRIrcLlu0F7L0FiZJiB0ZBVZTEjBtVa3YQrX6bRvuATIYfb6z1mxd6ZGlAQhhl5te6
	n3agLchbP9GAMQ2/NBb3buPFQK4tMriATySW/vub8pBXqerse2FU/QZgpZZK6rYM+ohm
	jMDddK976Pn1HAqwacXv/Izc93AWjjqeAWiCn8wmOe962ojDw9tXlrp0l5Ob91X7KhCq
	qitPauYcpsuULGdguiGopXVtgaKHb43Ny8BYP26hAoFqtUCmyUdDrhTc8uSb0yhY0CKF
	jNJA==
MIME-Version: 1.0
X-Received: by 10.50.181.136 with SMTP id dw8mr3725336igc.39.1361809759309;
	Mon, 25 Feb 2013 08:29:19 -0800 (PST)
Received: by 10.64.23.108 with HTTP; Mon, 25 Feb 2013 08:29:19 -0800 (PST)
In-Reply-To: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
Date: Mon, 25 Feb 2013 11:29:19 -0500
Message-ID: <CAMJ5SagoP6OXhzDrZ5op0M2HHqDEytWBtMg6aNF0fpJX1BEtWQ@mail.gmail.com>
From: Chuck Short <zulcss@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 8:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
>> At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
>> > On Fri, 22 Feb 2013, AP wrote:
>> > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
>> > > >
>> > > >
>> > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > >
>> > > >> I think it could still be very useful to many people. If not on the
>> > > >> xen-unstable repository, it should still be published somewhere.
>> > > >> Maybe a link on the wiki or a blog article?
>> > > >
>> > > >
>> > > > I'm happy to tidy it up a bit if people think it is useful, and publish
>> > > > it wherever. From memory the impact on the main code base is a 3 line
>> > > > change to the Makefile, and doubtless I could minimise the other files
>> > > > too.
>> > >
>> > > This would be very useful for people trying to create their own
>> > > minimal Xen image. I have been struggling with this for the past few
>> > > days.
>> > >
>> > > http://xen.markmail.org/thread/dac5kkuliky5373l
>> >
>> > If there is a need for it and clearly the upstream Debian maintainers
>> > don't care either way, why shouldn't we add the minideb target to our
>> > own build system? If we are going to have a deb target anyway, we might
>> > as well make it a useful one...
>>
>> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
>> Debian/Ubuntu.  That would be much more widely useful, for a similar
>> amount of effort.
>
> 4.2.0 is already in Debian experimental.
>
> Ian.
>
>
4.2.0 is in Ubuntu raring as well.

chuck
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 25 16:33:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA0zl-0004bi-2a; Mon, 25 Feb 2013 16:33:41 +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 1UA0zj-0004bE-F7
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:33:39 +0000
Received: from [85.158.143.99:58570] by server-3.bemta-4.messagelabs.com id
	B5/17-02186-2629B215; Mon, 25 Feb 2013 16:33:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361810017!29159091!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22570 invoked from network); 25 Feb 2013 16:33:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:33:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGXYUk022568
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:33:35 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
	r1PGXYrg024127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:33:34 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
	r1PGXY9S001943; Mon, 25 Feb 2013 10:33:34 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:33:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C78871C3935; Mon, 25 Feb 2013 11:33:32 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ian.campbell@citrix.com, xen-devel@lists.xensource.com
Date: Mon, 25 Feb 2013 11:33:30 -0500
Message-Id: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] libxl: Made it possible to use
	'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 assertion only allows values of 1 (no_delay_for_missed_ticks)
up to 3 (one_missed_tick_pending). It should be possible to
use the value of 1 (delay_for_missed_ticks) for the timer configuration
option.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_dom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1cd9a4..de555ee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -417,7 +417,7 @@ out:
 static unsigned long timer_mode(const libxl_domain_build_info *info)
 {
     const libxl_timer_mode mode = info->u.hvm.timer_mode;
-    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+    assert(mode >= LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
            mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
     return ((unsigned long)mode);
 }
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:33:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA0zl-0004bi-2a; Mon, 25 Feb 2013 16:33:41 +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 1UA0zj-0004bE-F7
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:33:39 +0000
Received: from [85.158.143.99:58570] by server-3.bemta-4.messagelabs.com id
	B5/17-02186-2629B215; Mon, 25 Feb 2013 16:33:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361810017!29159091!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22570 invoked from network); 25 Feb 2013 16:33:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:33:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGXYUk022568
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:33:35 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
	r1PGXYrg024127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:33:34 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
	r1PGXY9S001943; Mon, 25 Feb 2013 10:33:34 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:33:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C78871C3935; Mon, 25 Feb 2013 11:33:32 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ian.campbell@citrix.com, xen-devel@lists.xensource.com
Date: Mon, 25 Feb 2013 11:33:30 -0500
Message-Id: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] libxl: Made it possible to use
	'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 assertion only allows values of 1 (no_delay_for_missed_ticks)
up to 3 (one_missed_tick_pending). It should be possible to
use the value of 1 (delay_for_missed_ticks) for the timer configuration
option.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_dom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1cd9a4..de555ee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -417,7 +417,7 @@ out:
 static unsigned long timer_mode(const libxl_domain_build_info *info)
 {
     const libxl_timer_mode mode = info->u.hvm.timer_mode;
-    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+    assert(mode >= LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
            mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
     return ((unsigned long)mode);
 }
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:37:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA13n-0004qG-Pz; Mon, 25 Feb 2013 16:37: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 1UA13m-0004qA-8A
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:37:50 +0000
Received: from [193.109.254.147:30720] by server-9.bemta-14.messagelabs.com id
	8A/29-30867-D539B215; Mon, 25 Feb 2013 16:37:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361810169!8826697!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1276 invoked from network); 25 Feb 2013 16:36:11 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:36:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGa8TY017868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:36: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
	r1PGa8K9009292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:36:08 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
	r1PGa7pF010715
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 10:36:08 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:36:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D59641C3935; Mon, 25 Feb 2013 11:36:06 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Date: Mon, 25 Feb 2013 11:36:05 -0500
Message-Id: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the upstream
	Linux development tree 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>
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

And also put my name behind the mainternship.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0358a3e..e2252fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
 
 LINUX (PV_OPS)
 M:	Jeremy Fitzhardinge <jeremy@goop.org>
+M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 S:	Supported
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
 
 LINUX (XCP)
 M:	Ian Campbell <ian.campbell@citrix.com>
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:37:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA13n-0004qG-Pz; Mon, 25 Feb 2013 16:37: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 1UA13m-0004qA-8A
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:37:50 +0000
Received: from [193.109.254.147:30720] by server-9.bemta-14.messagelabs.com id
	8A/29-30867-D539B215; Mon, 25 Feb 2013 16:37:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361810169!8826697!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1276 invoked from network); 25 Feb 2013 16:36:11 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:36:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGa8TY017868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:36: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
	r1PGa8K9009292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:36:08 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
	r1PGa7pF010715
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 10:36:08 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:36:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D59641C3935; Mon, 25 Feb 2013 11:36:06 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Date: Mon, 25 Feb 2013 11:36:05 -0500
Message-Id: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.8.0.2
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the upstream
	Linux development tree 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>
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

And also put my name behind the mainternship.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0358a3e..e2252fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
 
 LINUX (PV_OPS)
 M:	Jeremy Fitzhardinge <jeremy@goop.org>
+M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 S:	Supported
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
 
 LINUX (XCP)
 M:	Ian Campbell <ian.campbell@citrix.com>
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:42:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA185-00054I-Hr; Mon, 25 Feb 2013 16:42:17 +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 1UA184-00054C-Md
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:42:16 +0000
Received: from [85.158.138.51:6590] by server-3.bemta-3.messagelabs.com id
	1C/42-31070-7649B215; Mon, 25 Feb 2013 16:42:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361810533!20228428!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6539 invoked from network); 25 Feb 2013 16:42:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:42:15 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGgCcf025962
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:42:13 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
	r1PGgBY2014306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:42:12 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
	r1PGgB0K015583
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 10:42:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:42:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 876001C3935; Mon, 25 Feb 2013 11:42:10 -0500 (EST)
Date: Mon, 25 Feb 2013 11:42:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130225164210.GA10580@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] How to get write checkin for xen.git tree?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

There are some patches I've and a bunch of other work that I forsee coming that
will mean more patches. I was wondering what the process is of getting
checkin access for the Xen tree?

P.S.
'konradwilk' is the account name.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:42:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA185-00054I-Hr; Mon, 25 Feb 2013 16:42:17 +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 1UA184-00054C-Md
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:42:16 +0000
Received: from [85.158.138.51:6590] by server-3.bemta-3.messagelabs.com id
	1C/42-31070-7649B215; Mon, 25 Feb 2013 16:42:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361810533!20228428!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6539 invoked from network); 25 Feb 2013 16:42:15 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:42:15 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGgCcf025962
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:42:13 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
	r1PGgBY2014306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 16:42:12 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
	r1PGgB0K015583
	for <xen-devel@lists.xensource.com>; Mon, 25 Feb 2013 10:42:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:42:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 876001C3935; Mon, 25 Feb 2013 11:42:10 -0500 (EST)
Date: Mon, 25 Feb 2013 11:42:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20130225164210.GA10580@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] How to get write checkin for xen.git tree?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

There are some patches I've and a bunch of other work that I forsee coming that
will mean more patches. I was wondering what the process is of getting
checkin access for the Xen tree?

P.S.
'konradwilk' is the account name.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:46:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1C3-0005Eu-8X; Mon, 25 Feb 2013 16:46: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 1UA1C1-0005Eo-Ur
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:46:22 +0000
Received: from [85.158.143.99:20780] by server-1.bemta-4.messagelabs.com id
	10/E6-06203-D559B215; Mon, 25 Feb 2013 16:46:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361810771!29161192!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10014 invoked from network); 25 Feb 2013 16:46:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 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.297.1; Mon, 25 Feb 2013 16:46:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UA1Br-0000Dd-4x; Mon, 25 Feb 2013 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 1UA1Bq-0000ZL-5F;
	Mon, 25 Feb 2013 16:46:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.38225.318737.330617@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 16:46:09 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B591702000078000C0BCE@nat28.tlf.novell.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
	<20779.18914.422564.346844@mariner.uk.xensource.com>
	<512B591702000078000C0BCE@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly
expose PCH ISA bridge for IGD passthrough"):
> [Ian Jackson:]
> > Sorry about that, perhaps I didn't spot the thread.  Do you think it
> > should be reverted ?
> 
> I'd prefer if you did so, and wait for a cleaned up version of the
> patch to be submitted. If you leave in what's there right now, I
> would b afraid that we'd never get to see a fixup patch on top.

Done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:46:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1C3-0005Eu-8X; Mon, 25 Feb 2013 16:46: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 1UA1C1-0005Eo-Ur
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:46:22 +0000
Received: from [85.158.143.99:20780] by server-1.bemta-4.messagelabs.com id
	10/E6-06203-D559B215; Mon, 25 Feb 2013 16:46:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361810771!29161192!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10014 invoked from network); 25 Feb 2013 16:46:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:46:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 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.297.1; Mon, 25 Feb 2013 16:46:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UA1Br-0000Dd-4x; Mon, 25 Feb 2013 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 1UA1Bq-0000ZL-5F;
	Mon, 25 Feb 2013 16:46:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20779.38225.318737.330617@mariner.uk.xensource.com>
Date: Mon, 25 Feb 2013 16:46:09 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512B591702000078000C0BCE@nat28.tlf.novell.com>
References: <CAKhsbWbezhvrAV=a=tvJmWosfeN0xsPb74sjqB6J9JViv2F7BQ@mail.gmail.com>
	<20775.45924.670290.551847@mariner.uk.xensource.com>
	<512B46A402000078000C0B3B@nat28.tlf.novell.com>
	<20779.18914.422564.346844@mariner.uk.xensource.com>
	<512B591702000078000C0BCE@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>,
	"G.R." <firemeteor@users.sourceforge.net>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge
 for IGD 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

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] qemu-xen:Correctly
expose PCH ISA bridge for IGD passthrough"):
> [Ian Jackson:]
> > Sorry about that, perhaps I didn't spot the thread.  Do you think it
> > should be reverted ?
> 
> I'd prefer if you did so, and wait for a cleaned up version of the
> patch to be submitted. If you leave in what's there right now, I
> would b afraid that we'd never get to see a fixup patch on top.

Done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:47:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:47: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 1UA1DJ-0005KX-Oe; Mon, 25 Feb 2013 16:47:41 +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 1UA1DI-0005KL-L7
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:47:40 +0000
Received: from [193.109.254.147:61710] by server-2.bemta-14.messagelabs.com id
	E1/DC-16277-BA59B215; Mon, 25 Feb 2013 16:47:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361810593!8827528!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22204 invoked from network); 25 Feb 2013 16:43:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:43:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16:43: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.297.1;
	Mon, 25 Feb 2013 16:43:13 +0000
Message-ID: <1361810590.26546.196.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 16:43:10 +0000
In-Reply-To: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
References: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 16:33 +0000, Konrad Rzeszutek Wilk wrote:
> The assertion only allows values of 1 (no_delay_for_missed_ticks)
> up to 3 (one_missed_tick_pending). It should be possible to
> use the value of 1 (delay_for_missed_ticks) for the timer configuration
> option.

Doh! That was very likely a brainfart by me...

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Ian Campbell <ian.cambell@citrix.com>

> ---
>  tools/libxl/libxl_dom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index e1cd9a4..de555ee 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -417,7 +417,7 @@ out:
>  static unsigned long timer_mode(const libxl_domain_build_info *info)
>  {
>      const libxl_timer_mode mode = info->u.hvm.timer_mode;
> -    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
> +    assert(mode >= LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
>             mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
>      return ((unsigned long)mode);
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:47:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:47: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 1UA1DJ-0005KX-Oe; Mon, 25 Feb 2013 16:47:41 +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 1UA1DI-0005KL-L7
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:47:40 +0000
Received: from [193.109.254.147:61710] by server-2.bemta-14.messagelabs.com id
	E1/DC-16277-BA59B215; Mon, 25 Feb 2013 16:47:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1361810593!8827528!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22204 invoked from network); 25 Feb 2013 16:43:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:43:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16:43: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.297.1;
	Mon, 25 Feb 2013 16:43:13 +0000
Message-ID: <1361810590.26546.196.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 16:43:10 +0000
In-Reply-To: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
References: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 16:33 +0000, Konrad Rzeszutek Wilk wrote:
> The assertion only allows values of 1 (no_delay_for_missed_ticks)
> up to 3 (one_missed_tick_pending). It should be possible to
> use the value of 1 (delay_for_missed_ticks) for the timer configuration
> option.

Doh! That was very likely a brainfart by me...

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Ian Campbell <ian.cambell@citrix.com>

> ---
>  tools/libxl/libxl_dom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index e1cd9a4..de555ee 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -417,7 +417,7 @@ out:
>  static unsigned long timer_mode(const libxl_domain_build_info *info)
>  {
>      const libxl_timer_mode mode = info->u.hvm.timer_mode;
> -    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
> +    assert(mode >= LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
>             mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
>      return ((unsigned long)mode);
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:49:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1FP-0005VZ-Ea; Mon, 25 Feb 2013 16:49:51 +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 1UA1FN-0005VJ-R6
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:49:50 +0000
Received: from [193.109.254.147:25929] by server-1.bemta-14.messagelabs.com id
	CB/9B-29874-D269B215; Mon, 25 Feb 2013 16:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361810969!2834917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17707 invoked from network); 25 Feb 2013 16:49: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; 25 Feb 2013 16:49:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 16:49:28 +0000
Message-Id: <512BA42602000078000C0D64@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 16:49:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part82B2F506.1__="
Cc: Jinsong Liu <jinsong.liu@intel.com>, Yongjie Ren <yongjie.ren@intel.com>
Subject: [Xen-devel] [PATCH] x86: fix CMCI injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part82B2F506.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This fixes the wrong use of literal vector 0xF7 with an "int"
instruction (invalidated by 25113:14609be41f36) and the fact that doing
the injection via a software interrupt was never valid anyway (because
cmci_interrupt() acks the LAPIC, which does the wrong thing if the
interrupt didn't get delivered though it).

In order to do latter, the patch introduces send_IPI_self(), at once
removing two opend coded uses of "genapic" in the IRQ handling code.

Reported-by: Yongjie Ren <yongjie.ren@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -34,6 +34,7 @@ bool_t __read_mostly mce_broadcast =3D 0;
 bool_t is_mc_panic;
 unsigned int __read_mostly nr_mce_banks;
 unsigned int __read_mostly firstbank;
+uint8_t __read_mostly cmci_apic_vector;
=20
 DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
 DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
@@ -1198,12 +1199,6 @@ static void x86_mc_mceinject(void *data)
     __asm__ __volatile__("int $0x12");
 }
=20
-static void x86_cmci_inject(void *data)
-{
-    printk("Simulating CMCI on cpu %d\n", smp_processor_id());
-    __asm__ __volatile__("int $0xf7");
-}
-
 #if BITS_PER_LONG =3D=3D 64
=20
 #define ID2COOKIE(id) ((mctelem_cookie_t)(id))
@@ -1479,11 +1474,15 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
             on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
             break;
         case XEN_MC_INJECT_TYPE_CMCI:
-            if ( !cmci_support )
+            if ( !cmci_apic_vector )
                 ret =3D x86_mcerr(
                     "No CMCI supported in platform\n", -EINVAL);
             else
-                on_selected_cpus(cpumap, x86_cmci_inject, NULL, 1);
+            {
+                if ( cpumask_test_cpu(smp_processor_id(), cpumap) )
+                    send_IPI_self(cmci_apic_vector);
+                send_IPI_mask(cpumap, cmci_apic_vector);
+            }
             break;
         default:
             ret =3D x86_mcerr("Wrong mca type\n", -EINVAL);
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -37,6 +37,8 @@ enum mcheck_type {
 	mcheck_intel
 };
=20
+extern uint8_t cmci_apic_vector;
+
 /* Init functions */
 enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -644,7 +644,6 @@ static void intel_init_cmci(struct cpuin
 {
     u32 l, apic;
     int cpu =3D smp_processor_id();
-    static uint8_t cmci_apic_vector;
=20
     if (!mce_available(c) || !cmci_support) {
         if (opt_cpu_info)
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -646,7 +646,7 @@ void irq_move_cleanup_interrupt(struct c
          * to myself.
          */
         if (irr  & (1 << (vector % 32))) {
-            genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
+            send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
             TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
                      irq, vector, smp_processor_id());
             goto unlock;
@@ -692,7 +692,7 @@ static void send_cleanup_vector(struct i
=20
     cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask, &cpu_online_map);
     desc->arch.move_cleanup_count =3D cpumask_weight(&cleanup_mask);
-    genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
+    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
=20
     desc->arch.move_in_progress =3D 0;
 }
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -38,6 +38,11 @@ void send_IPI_mask(const cpumask_t *mask
     genapic->send_IPI_mask(mask, vector);
 }
=20
+void send_IPI_self(int vector)
+{
+    genapic->send_IPI_self(vector);
+}
+
 /*
  *	Some notes on x86 processor bugs affecting SMP operation:
  *
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
=20
 void smp_send_nmi_allbutself(void);
=20
-void  send_IPI_mask(const cpumask_t *mask, int vector);
+void send_IPI_mask(const cpumask_t *, int vector);
+void send_IPI_self(int vector);
=20
 extern void (*mtrr_hook) (void);
=20



--=__Part82B2F506.1__=
Content-Type: text/plain; name="x86-CMCI-inject.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-CMCI-inject.patch"

x86: fix CMCI injection=0A=0AThis fixes the wrong use of literal vector =
0xF7 with an "int"=0Ainstruction (invalidated by 25113:14609be41f36) and =
the fact that doing=0Athe injection via a software interrupt was never =
valid anyway (because=0Acmci_interrupt() acks the LAPIC, which does the =
wrong thing if the=0Ainterrupt didn't get delivered though it).=0A=0AIn =
order to do latter, the patch introduces send_IPI_self(), at once=0Aremovin=
g two opend coded uses of "genapic" in the IRQ handling code.=0A=0AReported=
-by: Yongjie Ren <yongjie.ren@intel.com>=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/mcheck/mce.c=0A+++ =
b/xen/arch/x86/cpu/mcheck/mce.c=0A@@ -34,6 +34,7 @@ bool_t __read_mostly =
mce_broadcast =3D 0;=0A bool_t is_mc_panic;=0A unsigned int __read_mostly =
nr_mce_banks;=0A unsigned int __read_mostly firstbank;=0A+uint8_t =
__read_mostly cmci_apic_vector;=0A =0A DEFINE_PER_CPU_READ_MOSTLY(struct =
mca_banks *, poll_bankmask);=0A DEFINE_PER_CPU_READ_MOSTLY(struct =
mca_banks *, no_cmci_banks);=0A@@ -1198,12 +1199,6 @@ static void =
x86_mc_mceinject(void *data)=0A     __asm__ __volatile__("int $0x12");=0A =
}=0A =0A-static void x86_cmci_inject(void *data)=0A-{=0A-    printk("Simula=
ting CMCI on cpu %d\n", smp_processor_id());=0A-    __asm__ __volatile__("i=
nt $0xf7");=0A-}=0A-=0A #if BITS_PER_LONG =3D=3D 64=0A =0A #define =
ID2COOKIE(id) ((mctelem_cookie_t)(id))=0A@@ -1479,11 +1474,15 @@ long =
do_mca(XEN_GUEST_HANDLE_PARAM(xen_m=0A             on_selected_cpus(cpumap,=
 x86_mc_mceinject, NULL, 1);=0A             break;=0A         case =
XEN_MC_INJECT_TYPE_CMCI:=0A-            if ( !cmci_support )=0A+           =
 if ( !cmci_apic_vector )=0A                 ret =3D x86_mcerr(=0A         =
            "No CMCI supported in platform\n", -EINVAL);=0A             =
else=0A-                on_selected_cpus(cpumap, x86_cmci_inject, NULL, =
1);=0A+            {=0A+                if ( cpumask_test_cpu(smp_processor=
_id(), cpumap) )=0A+                    send_IPI_self(cmci_apic_vector);=0A=
+                send_IPI_mask(cpumap, cmci_apic_vector);=0A+            =
}=0A             break;=0A         default:=0A             ret =3D =
x86_mcerr("Wrong mca type\n", -EINVAL);=0A--- a/xen/arch/x86/cpu/mcheck/mce=
.h=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -37,6 +37,8 @@ enum =
mcheck_type {=0A 	mcheck_intel=0A };=0A =0A+extern uint8_t cmci_apic_=
vector;=0A+=0A /* Init functions */=0A enum mcheck_type amd_mcheck_init(str=
uct cpuinfo_x86 *c);=0A enum mcheck_type intel_mcheck_init(struct =
cpuinfo_x86 *c, bool_t bsp);=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A=
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c=0A@@ -644,7 +644,6 @@ static =
void intel_init_cmci(struct cpuin=0A {=0A     u32 l, apic;=0A     int cpu =
=3D smp_processor_id();=0A-    static uint8_t cmci_apic_vector;=0A =0A     =
if (!mce_available(c) || !cmci_support) {=0A         if (opt_cpu_info)=0A--=
- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -646,7 +646,7 @@ =
void irq_move_cleanup_interrupt(struct c=0A          * to myself.=0A       =
   */=0A         if (irr  & (1 << (vector % 32))) {=0A-            =
genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);=0A+            send_IPI_se=
lf(IRQ_MOVE_CLEANUP_VECTOR);=0A             TRACE_3D(TRC_HW_IRQ_MOVE_CLEANU=
P_DELAY,=0A                      irq, vector, smp_processor_id());=0A      =
       goto unlock;=0A@@ -692,7 +692,7 @@ static void send_cleanup_vector(s=
truct i=0A =0A     cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask, =
&cpu_online_map);=0A     desc->arch.move_cleanup_count =3D cpumask_weight(&=
cleanup_mask);=0A-    genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANU=
P_VECTOR);=0A+    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);=0A=
 =0A     desc->arch.move_in_progress =3D 0;=0A }=0A--- a/xen/arch/x86/smp.c=
=0A+++ b/xen/arch/x86/smp.c=0A@@ -38,6 +38,11 @@ void send_IPI_mask(const =
cpumask_t *mask=0A     genapic->send_IPI_mask(mask, vector);=0A }=0A =
=0A+void send_IPI_self(int vector)=0A+{=0A+    genapic->send_IPI_self(vecto=
r);=0A+}=0A+=0A /*=0A  *	Some notes on x86 processor bugs affecting =
SMP operation:=0A  *=0A--- a/xen/include/asm-x86/smp.h=0A+++ b/xen/include/=
asm-x86/smp.h=0A@@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, =
cpu_core_=0A =0A void smp_send_nmi_allbutself(void);=0A =0A-void  =
send_IPI_mask(const cpumask_t *mask, int vector);=0A+void send_IPI_mask(con=
st cpumask_t *, int vector);=0A+void send_IPI_self(int vector);=0A =0A =
extern void (*mtrr_hook) (void);=0A =0A
--=__Part82B2F506.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

--=__Part82B2F506.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 25 16:49:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1FP-0005VZ-Ea; Mon, 25 Feb 2013 16:49:51 +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 1UA1FN-0005VJ-R6
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:49:50 +0000
Received: from [193.109.254.147:25929] by server-1.bemta-14.messagelabs.com id
	CB/9B-29874-D269B215; Mon, 25 Feb 2013 16:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361810969!2834917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17707 invoked from network); 25 Feb 2013 16:49: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; 25 Feb 2013 16:49:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 25 Feb 2013 16:49:28 +0000
Message-Id: <512BA42602000078000C0D64@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Mon, 25 Feb 2013 16:49:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part82B2F506.1__="
Cc: Jinsong Liu <jinsong.liu@intel.com>, Yongjie Ren <yongjie.ren@intel.com>
Subject: [Xen-devel] [PATCH] x86: fix CMCI injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part82B2F506.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This fixes the wrong use of literal vector 0xF7 with an "int"
instruction (invalidated by 25113:14609be41f36) and the fact that doing
the injection via a software interrupt was never valid anyway (because
cmci_interrupt() acks the LAPIC, which does the wrong thing if the
interrupt didn't get delivered though it).

In order to do latter, the patch introduces send_IPI_self(), at once
removing two opend coded uses of "genapic" in the IRQ handling code.

Reported-by: Yongjie Ren <yongjie.ren@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -34,6 +34,7 @@ bool_t __read_mostly mce_broadcast =3D 0;
 bool_t is_mc_panic;
 unsigned int __read_mostly nr_mce_banks;
 unsigned int __read_mostly firstbank;
+uint8_t __read_mostly cmci_apic_vector;
=20
 DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
 DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
@@ -1198,12 +1199,6 @@ static void x86_mc_mceinject(void *data)
     __asm__ __volatile__("int $0x12");
 }
=20
-static void x86_cmci_inject(void *data)
-{
-    printk("Simulating CMCI on cpu %d\n", smp_processor_id());
-    __asm__ __volatile__("int $0xf7");
-}
-
 #if BITS_PER_LONG =3D=3D 64
=20
 #define ID2COOKIE(id) ((mctelem_cookie_t)(id))
@@ -1479,11 +1474,15 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
             on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
             break;
         case XEN_MC_INJECT_TYPE_CMCI:
-            if ( !cmci_support )
+            if ( !cmci_apic_vector )
                 ret =3D x86_mcerr(
                     "No CMCI supported in platform\n", -EINVAL);
             else
-                on_selected_cpus(cpumap, x86_cmci_inject, NULL, 1);
+            {
+                if ( cpumask_test_cpu(smp_processor_id(), cpumap) )
+                    send_IPI_self(cmci_apic_vector);
+                send_IPI_mask(cpumap, cmci_apic_vector);
+            }
             break;
         default:
             ret =3D x86_mcerr("Wrong mca type\n", -EINVAL);
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -37,6 +37,8 @@ enum mcheck_type {
 	mcheck_intel
 };
=20
+extern uint8_t cmci_apic_vector;
+
 /* Init functions */
 enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -644,7 +644,6 @@ static void intel_init_cmci(struct cpuin
 {
     u32 l, apic;
     int cpu =3D smp_processor_id();
-    static uint8_t cmci_apic_vector;
=20
     if (!mce_available(c) || !cmci_support) {
         if (opt_cpu_info)
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -646,7 +646,7 @@ void irq_move_cleanup_interrupt(struct c
          * to myself.
          */
         if (irr  & (1 << (vector % 32))) {
-            genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
+            send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
             TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
                      irq, vector, smp_processor_id());
             goto unlock;
@@ -692,7 +692,7 @@ static void send_cleanup_vector(struct i
=20
     cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask, &cpu_online_map);
     desc->arch.move_cleanup_count =3D cpumask_weight(&cleanup_mask);
-    genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
+    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
=20
     desc->arch.move_in_progress =3D 0;
 }
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -38,6 +38,11 @@ void send_IPI_mask(const cpumask_t *mask
     genapic->send_IPI_mask(mask, vector);
 }
=20
+void send_IPI_self(int vector)
+{
+    genapic->send_IPI_self(vector);
+}
+
 /*
  *	Some notes on x86 processor bugs affecting SMP operation:
  *
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
=20
 void smp_send_nmi_allbutself(void);
=20
-void  send_IPI_mask(const cpumask_t *mask, int vector);
+void send_IPI_mask(const cpumask_t *, int vector);
+void send_IPI_self(int vector);
=20
 extern void (*mtrr_hook) (void);
=20



--=__Part82B2F506.1__=
Content-Type: text/plain; name="x86-CMCI-inject.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-CMCI-inject.patch"

x86: fix CMCI injection=0A=0AThis fixes the wrong use of literal vector =
0xF7 with an "int"=0Ainstruction (invalidated by 25113:14609be41f36) and =
the fact that doing=0Athe injection via a software interrupt was never =
valid anyway (because=0Acmci_interrupt() acks the LAPIC, which does the =
wrong thing if the=0Ainterrupt didn't get delivered though it).=0A=0AIn =
order to do latter, the patch introduces send_IPI_self(), at once=0Aremovin=
g two opend coded uses of "genapic" in the IRQ handling code.=0A=0AReported=
-by: Yongjie Ren <yongjie.ren@intel.com>=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/mcheck/mce.c=0A+++ =
b/xen/arch/x86/cpu/mcheck/mce.c=0A@@ -34,6 +34,7 @@ bool_t __read_mostly =
mce_broadcast =3D 0;=0A bool_t is_mc_panic;=0A unsigned int __read_mostly =
nr_mce_banks;=0A unsigned int __read_mostly firstbank;=0A+uint8_t =
__read_mostly cmci_apic_vector;=0A =0A DEFINE_PER_CPU_READ_MOSTLY(struct =
mca_banks *, poll_bankmask);=0A DEFINE_PER_CPU_READ_MOSTLY(struct =
mca_banks *, no_cmci_banks);=0A@@ -1198,12 +1199,6 @@ static void =
x86_mc_mceinject(void *data)=0A     __asm__ __volatile__("int $0x12");=0A =
}=0A =0A-static void x86_cmci_inject(void *data)=0A-{=0A-    printk("Simula=
ting CMCI on cpu %d\n", smp_processor_id());=0A-    __asm__ __volatile__("i=
nt $0xf7");=0A-}=0A-=0A #if BITS_PER_LONG =3D=3D 64=0A =0A #define =
ID2COOKIE(id) ((mctelem_cookie_t)(id))=0A@@ -1479,11 +1474,15 @@ long =
do_mca(XEN_GUEST_HANDLE_PARAM(xen_m=0A             on_selected_cpus(cpumap,=
 x86_mc_mceinject, NULL, 1);=0A             break;=0A         case =
XEN_MC_INJECT_TYPE_CMCI:=0A-            if ( !cmci_support )=0A+           =
 if ( !cmci_apic_vector )=0A                 ret =3D x86_mcerr(=0A         =
            "No CMCI supported in platform\n", -EINVAL);=0A             =
else=0A-                on_selected_cpus(cpumap, x86_cmci_inject, NULL, =
1);=0A+            {=0A+                if ( cpumask_test_cpu(smp_processor=
_id(), cpumap) )=0A+                    send_IPI_self(cmci_apic_vector);=0A=
+                send_IPI_mask(cpumap, cmci_apic_vector);=0A+            =
}=0A             break;=0A         default:=0A             ret =3D =
x86_mcerr("Wrong mca type\n", -EINVAL);=0A--- a/xen/arch/x86/cpu/mcheck/mce=
.h=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -37,6 +37,8 @@ enum =
mcheck_type {=0A 	mcheck_intel=0A };=0A =0A+extern uint8_t cmci_apic_=
vector;=0A+=0A /* Init functions */=0A enum mcheck_type amd_mcheck_init(str=
uct cpuinfo_x86 *c);=0A enum mcheck_type intel_mcheck_init(struct =
cpuinfo_x86 *c, bool_t bsp);=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=0A=
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c=0A@@ -644,7 +644,6 @@ static =
void intel_init_cmci(struct cpuin=0A {=0A     u32 l, apic;=0A     int cpu =
=3D smp_processor_id();=0A-    static uint8_t cmci_apic_vector;=0A =0A     =
if (!mce_available(c) || !cmci_support) {=0A         if (opt_cpu_info)=0A--=
- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -646,7 +646,7 @@ =
void irq_move_cleanup_interrupt(struct c=0A          * to myself.=0A       =
   */=0A         if (irr  & (1 << (vector % 32))) {=0A-            =
genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);=0A+            send_IPI_se=
lf(IRQ_MOVE_CLEANUP_VECTOR);=0A             TRACE_3D(TRC_HW_IRQ_MOVE_CLEANU=
P_DELAY,=0A                      irq, vector, smp_processor_id());=0A      =
       goto unlock;=0A@@ -692,7 +692,7 @@ static void send_cleanup_vector(s=
truct i=0A =0A     cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask, =
&cpu_online_map);=0A     desc->arch.move_cleanup_count =3D cpumask_weight(&=
cleanup_mask);=0A-    genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANU=
P_VECTOR);=0A+    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);=0A=
 =0A     desc->arch.move_in_progress =3D 0;=0A }=0A--- a/xen/arch/x86/smp.c=
=0A+++ b/xen/arch/x86/smp.c=0A@@ -38,6 +38,11 @@ void send_IPI_mask(const =
cpumask_t *mask=0A     genapic->send_IPI_mask(mask, vector);=0A }=0A =
=0A+void send_IPI_self(int vector)=0A+{=0A+    genapic->send_IPI_self(vecto=
r);=0A+}=0A+=0A /*=0A  *	Some notes on x86 processor bugs affecting =
SMP operation:=0A  *=0A--- a/xen/include/asm-x86/smp.h=0A+++ b/xen/include/=
asm-x86/smp.h=0A@@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, =
cpu_core_=0A =0A void smp_send_nmi_allbutself(void);=0A =0A-void  =
send_IPI_mask(const cpumask_t *mask, int vector);=0A+void send_IPI_mask(con=
st cpumask_t *, int vector);=0A+void send_IPI_self(int vector);=0A =0A =
extern void (*mtrr_hook) (void);=0A =0A
--=__Part82B2F506.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

--=__Part82B2F506.1__=--


From xen-devel-bounces@lists.xen.org Mon Feb 25 16:50:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1Fb-0005Wi-Cr; Mon, 25 Feb 2013 16:50:03 +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 1UA1FY-0005WR-EG
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:50:00 +0000
Received: from [85.158.139.211:59820] by server-10.bemta-5.messagelabs.com id
	AA/21-23714-7369B215; Mon, 25 Feb 2013 16:49:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361810974!18233896!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14181 invoked from network); 25 Feb 2013 16:49:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:49:35 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGnVaY003035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:49:32 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
	r1PGnUSO001186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:49:31 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
	r1PGnUjt014693; Mon, 25 Feb 2013 10:49:30 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:49:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7D0D01C3935; Mon, 25 Feb 2013 11:49:29 -0500 (EST)
Date: Mon, 25 Feb 2013 11:49:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130225164929.GB10672@phenom.dumpdata.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
	<511E88B4.7060205@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E88B4.7060205@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="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, Feb 15, 2013 at 08:12:52PM +0100, Roger Pau Monn=E9 wrote:
> On 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
> >> Should be backported to 3.8 stable.
> > =

> > Lets do one thing at a time.
> > =

> > The patch I have in the tree (and that I've asked Jens to pull for 3.9 =
- so
> > he might have already in his tree) is the old hybrid where we still use=
 llist
> > but change the loop from 'for' to 'while'.
> > =

> > This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/li=
nux/kernel/git/konrad/xen.git =

> > =

> > Could you rebase your patch on top of that tree and just simplify the l=
oop?
> > =

> > Sorry about the mess about this - but I had already pulled the trigger
> > so to say - hoping that Jens would pull the tree and do a git pull to L=
inus.
> > =

> > And you are absolutly sure that we don't need any extra locking when sw=
itching
> > over to list_head? Say if blkif_completion is called while we are
> > processing in blkif_queue_request and doing ?
> =

> Will recheck it, but blkif_completition is called with the io_lock hold,
> as does blkif_queue_request (I've added extra assert_spin_locked before
> every list modification).

Can you rebase this patch on top of 'stable/for-jens-3.9' when you get a ch=
ance
please?

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:50:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1Fb-0005Wi-Cr; Mon, 25 Feb 2013 16:50:03 +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 1UA1FY-0005WR-EG
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:50:00 +0000
Received: from [85.158.139.211:59820] by server-10.bemta-5.messagelabs.com id
	AA/21-23714-7369B215; Mon, 25 Feb 2013 16:49:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361810974!18233896!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14181 invoked from network); 25 Feb 2013 16:49:35 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 16:49:35 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PGnVaY003035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 16:49:32 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
	r1PGnUSO001186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 16:49:31 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
	r1PGnUjt014693; Mon, 25 Feb 2013 10:49:30 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 08:49:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7D0D01C3935; Mon, 25 Feb 2013 11:49:29 -0500 (EST)
Date: Mon, 25 Feb 2013 11:49:29 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
Message-ID: <20130225164929.GB10672@phenom.dumpdata.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
	<511E88B4.7060205@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <511E88B4.7060205@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="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, Feb 15, 2013 at 08:12:52PM +0100, Roger Pau Monn=E9 wrote:
> On 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
> >> Should be backported to 3.8 stable.
> > =

> > Lets do one thing at a time.
> > =

> > The patch I have in the tree (and that I've asked Jens to pull for 3.9 =
- so
> > he might have already in his tree) is the old hybrid where we still use=
 llist
> > but change the loop from 'for' to 'while'.
> > =

> > This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/li=
nux/kernel/git/konrad/xen.git =

> > =

> > Could you rebase your patch on top of that tree and just simplify the l=
oop?
> > =

> > Sorry about the mess about this - but I had already pulled the trigger
> > so to say - hoping that Jens would pull the tree and do a git pull to L=
inus.
> > =

> > And you are absolutly sure that we don't need any extra locking when sw=
itching
> > over to list_head? Say if blkif_completion is called while we are
> > processing in blkif_queue_request and doing ?
> =

> Will recheck it, but blkif_completition is called with the io_lock hold,
> as does blkif_queue_request (I've added extra assert_spin_locked before
> every list modification).

Can you rebase this patch on top of 'stable/for-jens-3.9' when you get a ch=
ance
please?

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:56:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1Li-0006A8-6v; Mon, 25 Feb 2013 16:56:22 +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 1UA1Lg-00069q-QB
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:56:20 +0000
Received: from [85.158.139.211:25578] by server-14.bemta-5.messagelabs.com id
	CE/CC-13158-3B79B215; Mon, 25 Feb 2013 16:56:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361811378!18747276!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 777 invoked from network); 25 Feb 2013 16:56:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16:56: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.297.1;
	Mon, 25 Feb 2013 16:56:18 +0000
Message-ID: <1361811376.26546.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 16:56:16 +0000
In-Reply-To: <20130225164210.GA10580@phenom.dumpdata.com>
References: <20130225164210.GA10580@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] How to get write checkin for xen.git tree?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 16:42 +0000, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> There are some patches I've and a bunch of other work that I forsee coming that
> will mean more patches. I was wondering what the process is of getting
> checkin access for the Xen tree?

Usually you would be a maintainer for whichever subsystem in the tree
first. See "Maintainer Elections" and "Committer Elections" in
http://www.xen.org/projects/governance.html

What subsystem in xen.git are all these patches against? I think we
should start by processing them as normal patches (i.e. patch to list,
acks, some existing committer shovels them in) and work from there.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:56:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1Li-0006A8-6v; Mon, 25 Feb 2013 16:56:22 +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 1UA1Lg-00069q-QB
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:56:20 +0000
Received: from [85.158.139.211:25578] by server-14.bemta-5.messagelabs.com id
	CE/CC-13158-3B79B215; Mon, 25 Feb 2013 16:56:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1361811378!18747276!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 777 invoked from network); 25 Feb 2013 16:56:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16:56: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.297.1;
	Mon, 25 Feb 2013 16:56:18 +0000
Message-ID: <1361811376.26546.204.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 16:56:16 +0000
In-Reply-To: <20130225164210.GA10580@phenom.dumpdata.com>
References: <20130225164210.GA10580@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] How to get write checkin for xen.git tree?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 16:42 +0000, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> There are some patches I've and a bunch of other work that I forsee coming that
> will mean more patches. I was wondering what the process is of getting
> checkin access for the Xen tree?

Usually you would be a maintainer for whichever subsystem in the tree
first. See "Maintainer Elections" and "Committer Elections" in
http://www.xen.org/projects/governance.html

What subsystem in xen.git are all these patches against? I think we
should start by processing them as normal patches (i.e. patch to list,
acks, some existing committer shovels them in) and work from there.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:56:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:56: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 1UA1M5-0006Cl-KN; Mon, 25 Feb 2013 16:56:45 +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 1UA1M3-0006CT-Tx
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:56:44 +0000
Received: from [193.109.254.147:32350] by server-1.bemta-14.messagelabs.com id
	DD/23-29874-BC79B215; Mon, 25 Feb 2013 16:56:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361811392!4486946!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6821 invoked from network); 25 Feb 2013 16:56:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16:56: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.297.1;
	Mon, 25 Feb 2013 16:56:31 +0000
Message-ID: <1361811390.26546.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 16:56:30 +0000
In-Reply-To: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> And also put my name behind the mainternship.

I think you could also safely remove Jeremy these days?

Maybe we should have a Linux style CREDITS file to retain the names of
historical contributors/maintainers?

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0358a3e..e2252fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
>  
>  LINUX (PV_OPS)
>  M:	Jeremy Fitzhardinge <jeremy@goop.org>
> +M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>  S:	Supported
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>  
>  LINUX (XCP)
>  M:	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 Mon Feb 25 16:56:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16:56: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 1UA1M5-0006Cl-KN; Mon, 25 Feb 2013 16:56:45 +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 1UA1M3-0006CT-Tx
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 16:56:44 +0000
Received: from [193.109.254.147:32350] by server-1.bemta-14.messagelabs.com id
	DD/23-29874-BC79B215; Mon, 25 Feb 2013 16:56:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361811392!4486946!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6821 invoked from network); 25 Feb 2013 16:56:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 16:56:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 16:56: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.297.1;
	Mon, 25 Feb 2013 16:56:31 +0000
Message-ID: <1361811390.26546.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 16:56:30 +0000
In-Reply-To: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> And also put my name behind the mainternship.

I think you could also safely remove Jeremy these days?

Maybe we should have a Linux style CREDITS file to retain the names of
historical contributors/maintainers?

> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0358a3e..e2252fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
>  
>  LINUX (PV_OPS)
>  M:	Jeremy Fitzhardinge <jeremy@goop.org>
> +M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>  S:	Supported
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>  
>  LINUX (XCP)
>  M:	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 Mon Feb 25 16:56:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1MB-0006DM-0F; Mon, 25 Feb 2013 16:56:51 +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 1UA1M9-0006DB-W1
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:56:50 +0000
Received: from [85.158.137.99:36476] by server-2.bemta-3.messagelabs.com id
	40/BC-25961-1D79B215; Mon, 25 Feb 2013 16:56:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361811408!14846600!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1679 invoked from network); 25 Feb 2013 16:56:48 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:56:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UA1M4-000LkR-Sb; Mon, 25 Feb 2013 16:56:44 +0000
Date: Mon, 25 Feb 2013 16:56:44 +0000
From: Tim Deegan <tim@xen.org>
To: Chuck Short <zulcss@gmail.com>
Message-ID: <20130225165644.GB78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
	<CAMJ5SagoP6OXhzDrZ5op0M2HHqDEytWBtMg6aNF0fpJX1BEtWQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMJ5SagoP6OXhzDrZ5op0M2HHqDEytWBtMg6aNF0fpJX1BEtWQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Lars Kurth <lars.kurth@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:29 -0500 on 25 Feb (1361791759), Chuck Short wrote:
> On Mon, Feb 25, 2013 at 8:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
> >> At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> >> > On Fri, 22 Feb 2013, AP wrote:
> >> > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> >> > > >
> >> > > >
> >> > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> >> > > > <stefano.stabellini@eu.citrix.com> wrote:
> >> > > >
> >> > > >> I think it could still be very useful to many people. If not on the
> >> > > >> xen-unstable repository, it should still be published somewhere.
> >> > > >> Maybe a link on the wiki or a blog article?
> >> > > >
> >> > > >
> >> > > > I'm happy to tidy it up a bit if people think it is useful, and publish
> >> > > > it wherever. From memory the impact on the main code base is a 3 line
> >> > > > change to the Makefile, and doubtless I could minimise the other files
> >> > > > too.
> >> > >
> >> > > This would be very useful for people trying to create their own
> >> > > minimal Xen image. I have been struggling with this for the past few
> >> > > days.
> >> > >
> >> > > http://xen.markmail.org/thread/dac5kkuliky5373l
> >> >
> >> > If there is a need for it and clearly the upstream Debian maintainers
> >> > don't care either way, why shouldn't we add the minideb target to our
> >> > own build system? If we are going to have a deb target anyway, we might
> >> > as well make it a useful one...
> >>
> >> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> >> Debian/Ubuntu.  That would be much more widely useful, for a similar
> >> amount of effort.
> >
> > 4.2.0 is already in Debian experimental.
> >
> > Ian.
> >
> >
> 4.2.0 is in Ubuntu raring as well.

Excellent! :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:56:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1MB-0006DM-0F; Mon, 25 Feb 2013 16:56:51 +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 1UA1M9-0006DB-W1
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:56:50 +0000
Received: from [85.158.137.99:36476] by server-2.bemta-3.messagelabs.com id
	40/BC-25961-1D79B215; Mon, 25 Feb 2013 16:56:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361811408!14846600!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1679 invoked from network); 25 Feb 2013 16:56:48 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 16:56:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UA1M4-000LkR-Sb; Mon, 25 Feb 2013 16:56:44 +0000
Date: Mon, 25 Feb 2013 16:56:44 +0000
From: Tim Deegan <tim@xen.org>
To: Chuck Short <zulcss@gmail.com>
Message-ID: <20130225165644.GB78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
	<CAMJ5SagoP6OXhzDrZ5op0M2HHqDEytWBtMg6aNF0fpJX1BEtWQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMJ5SagoP6OXhzDrZ5op0M2HHqDEytWBtMg6aNF0fpJX1BEtWQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Lars Kurth <lars.kurth@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:29 -0500 on 25 Feb (1361791759), Chuck Short wrote:
> On Mon, Feb 25, 2013 at 8:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2013-02-25 at 13:12 +0000, Tim Deegan wrote:
> >> At 12:44 +0000 on 25 Feb (1361796242), Stefano Stabellini wrote:
> >> > On Fri, 22 Feb 2013, AP wrote:
> >> > > On Fri, Feb 22, 2013 at 11:48 AM, Alex Bligh <alex@alex.org.uk> wrote:
> >> > > >
> >> > > >
> >> > > > --On 22 February 2013 17:57:47 +0000 Stefano Stabellini
> >> > > > <stefano.stabellini@eu.citrix.com> wrote:
> >> > > >
> >> > > >> I think it could still be very useful to many people. If not on the
> >> > > >> xen-unstable repository, it should still be published somewhere.
> >> > > >> Maybe a link on the wiki or a blog article?
> >> > > >
> >> > > >
> >> > > > I'm happy to tidy it up a bit if people think it is useful, and publish
> >> > > > it wherever. From memory the impact on the main code base is a 3 line
> >> > > > change to the Makefile, and doubtless I could minimise the other files
> >> > > > too.
> >> > >
> >> > > This would be very useful for people trying to create their own
> >> > > minimal Xen image. I have been struggling with this for the past few
> >> > > days.
> >> > >
> >> > > http://xen.markmail.org/thread/dac5kkuliky5373l
> >> >
> >> > If there is a need for it and clearly the upstream Debian maintainers
> >> > don't care either way, why shouldn't we add the minideb target to our
> >> > own build system? If we are going to have a deb target anyway, we might
> >> > as well make it a useful one...
> >>
> >> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> >> Debian/Ubuntu.  That would be much more widely useful, for a similar
> >> amount of effort.
> >
> > 4.2.0 is already in Debian experimental.
> >
> > Ian.
> >
> >
> 4.2.0 is in Ubuntu raring as well.

Excellent! :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 16:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1NC-0006P8-G4; Mon, 25 Feb 2013 16:57: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 1UA1NB-0006Ow-7P
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:57:53 +0000
Received: from [85.158.139.83:18045] by server-11.bemta-5.messagelabs.com id
	2C/33-27486-0189B215; Mon, 25 Feb 2013 16:57:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361811463!21529420!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22710 invoked from network); 25 Feb 2013 16:57:43 -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; 25 Feb 2013 16:57:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UA1N1-000Lko-9b; Mon, 25 Feb 2013 16:57:43 +0000
Date: Mon, 25 Feb 2013 16:57:43 +0000
From: Tim Deegan <tim@xen.org>
To: Razvan Cojocaru <rzvncj@gmail.com>
Message-ID: <20130225165743.GC78606@ocelot.phlegethon.org>
References: <512B8C6B.90305@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512B8C6B.90305@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xc_domain_hvm_getcontext_partial(... CPU ...),
	the RIP register, and mem_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

At 18:08 +0200 on 25 Feb (1361815691), Razvan Cojocaru wrote:
> Hello,
> 
> assuming that the VCPU is paused while waiting for userspace to respond 
> to a page fault mem_event, and userspace calls libxc's 
> xc_domain_hvm_getcontext_partial(... CPU ...) and tries to inspect RIP, 
> is this a safe thing to do? Is RIP's value guaranteed to be safe to 
> inspect in this context?

Yes.

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 Feb 25 16:58:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 16: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 1UA1NC-0006P8-G4; Mon, 25 Feb 2013 16:57: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 1UA1NB-0006Ow-7P
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 16:57:53 +0000
Received: from [85.158.139.83:18045] by server-11.bemta-5.messagelabs.com id
	2C/33-27486-0189B215; Mon, 25 Feb 2013 16:57:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361811463!21529420!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22710 invoked from network); 25 Feb 2013 16:57:43 -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; 25 Feb 2013 16:57:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UA1N1-000Lko-9b; Mon, 25 Feb 2013 16:57:43 +0000
Date: Mon, 25 Feb 2013 16:57:43 +0000
From: Tim Deegan <tim@xen.org>
To: Razvan Cojocaru <rzvncj@gmail.com>
Message-ID: <20130225165743.GC78606@ocelot.phlegethon.org>
References: <512B8C6B.90305@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512B8C6B.90305@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xc_domain_hvm_getcontext_partial(... CPU ...),
	the RIP register, and mem_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

At 18:08 +0200 on 25 Feb (1361815691), Razvan Cojocaru wrote:
> Hello,
> 
> assuming that the VCPU is paused while waiting for userspace to respond 
> to a page fault mem_event, and userspace calls libxc's 
> xc_domain_hvm_getcontext_partial(... CPU ...) and tries to inspect RIP, 
> is this a safe thing to do? Is RIP's value guaranteed to be safe to 
> inspect in this context?

Yes.

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 Feb 25 17:00:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17:00: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 1UA1PW-0006k8-63; Mon, 25 Feb 2013 17:00:18 +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 1UA1PU-0006jn-CD
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 17:00:16 +0000
Received: from [85.158.138.51:19196] by server-1.bemta-3.messagelabs.com id
	6F/60-08955-E989B215; Mon, 25 Feb 2013 17:00:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361811613!27363336!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12463 invoked from network); 25 Feb 2013 17:00:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 17:00:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 17:00:13 +0000
Received: from Roger-2.local (10.150.17.232) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Mon, 25 Feb 2013 17:00:13 +0000
Message-ID: <512B98C9.2020008@citrix.com>
Date: Mon, 25 Feb 2013 18:00:57 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
	<511E88B4.7060205@citrix.com>
	<20130225164929.GB10672@phenom.dumpdata.com>
In-Reply-To: <20130225164929.GB10672@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/02/13 17:49, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 15, 2013 at 08:12:52PM +0100, Roger Pau Monn=E9 wrote:
>> On 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
>>>> Should be backported to 3.8 stable.
>>>
>>> Lets do one thing at a time.
>>>
>>> The patch I have in the tree (and that I've asked Jens to pull for 3.9 =
- so
>>> he might have already in his tree) is the old hybrid where we still use=
 llist
>>> but change the loop from 'for' to 'while'.
>>>
>>> This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/li=
nux/kernel/git/konrad/xen.git =

>>>
>>> Could you rebase your patch on top of that tree and just simplify the l=
oop?
>>>
>>> Sorry about the mess about this - but I had already pulled the trigger
>>> so to say - hoping that Jens would pull the tree and do a git pull to L=
inus.
>>>
>>> And you are absolutly sure that we don't need any extra locking when sw=
itching
>>> over to list_head? Say if blkif_completion is called while we are
>>> processing in blkif_queue_request and doing ?
>>
>> Will recheck it, but blkif_completition is called with the io_lock hold,
>> as does blkif_queue_request (I've added extra assert_spin_locked before
>> every list modification).
> =

> Can you rebase this patch on top of 'stable/for-jens-3.9' when you get a =
chance
> please?

Yes, I was going to resubmit it as part of my indirect descriptors
series (which I'm hoping to send before the end of the week), but if you
are in a rush I can send it earlier, I already have it rebased on top of
for-jens-3.9.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:00:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17:00: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 1UA1PW-0006k8-63; Mon, 25 Feb 2013 17:00:18 +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 1UA1PU-0006jn-CD
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 17:00:16 +0000
Received: from [85.158.138.51:19196] by server-1.bemta-3.messagelabs.com id
	6F/60-08955-E989B215; Mon, 25 Feb 2013 17:00:14 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361811613!27363336!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12463 invoked from network); 25 Feb 2013 17:00:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 17:00:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; 
   d="scan'208";a="1851999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 17:00:13 +0000
Received: from Roger-2.local (10.150.17.232) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Mon, 25 Feb 2013 17:00:13 +0000
Message-ID: <512B98C9.2020008@citrix.com>
Date: Mon, 25 Feb 2013 18:00:57 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
	<511E88B4.7060205@citrix.com>
	<20130225164929.GB10672@phenom.dumpdata.com>
In-Reply-To: <20130225164929.GB10672@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/02/13 17:49, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 15, 2013 at 08:12:52PM +0100, Roger Pau Monn=E9 wrote:
>> On 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
>>>> Should be backported to 3.8 stable.
>>>
>>> Lets do one thing at a time.
>>>
>>> The patch I have in the tree (and that I've asked Jens to pull for 3.9 =
- so
>>> he might have already in his tree) is the old hybrid where we still use=
 llist
>>> but change the loop from 'for' to 'while'.
>>>
>>> This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/li=
nux/kernel/git/konrad/xen.git =

>>>
>>> Could you rebase your patch on top of that tree and just simplify the l=
oop?
>>>
>>> Sorry about the mess about this - but I had already pulled the trigger
>>> so to say - hoping that Jens would pull the tree and do a git pull to L=
inus.
>>>
>>> And you are absolutly sure that we don't need any extra locking when sw=
itching
>>> over to list_head? Say if blkif_completion is called while we are
>>> processing in blkif_queue_request and doing ?
>>
>> Will recheck it, but blkif_completition is called with the io_lock hold,
>> as does blkif_queue_request (I've added extra assert_spin_locked before
>> every list modification).
> =

> Can you rebase this patch on top of 'stable/for-jens-3.9' when you get a =
chance
> please?

Yes, I was going to resubmit it as part of my indirect descriptors
series (which I'm hoping to send before the end of the week), but if you
are in a rush I can send it earlier, I already have it rebased on top of
for-jens-3.9.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:00:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17: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 1UA1Pz-0006or-Pd; Mon, 25 Feb 2013 17:00:47 +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 1UA1Px-0006oA-Lg
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 17:00:45 +0000
Received: from [85.158.143.99:28330] by server-1.bemta-4.messagelabs.com id
	46/34-06203-BB89B215; Mon, 25 Feb 2013 17:00:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361811640!28188768!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3611 invoked from network); 25 Feb 2013 17:00:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 17:00:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PH0b3O018009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 17:00:38 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
	r1PH0bhk024106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 17:00:37 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
	r1PH0awn023975; Mon, 25 Feb 2013 11:00:37 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 09:00:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0823B1C3935; Mon, 25 Feb 2013 12:00:35 -0500 (EST)
Date: Mon, 25 Feb 2013 12:00:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130225170034.GB10673@phenom.dumpdata.com>
References: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
	<1361810590.26546.196.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361810590.26546.196.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 04:43:10PM +0000, Ian Campbell wrote:
> On Mon, 2013-02-25 at 16:33 +0000, Konrad Rzeszutek Wilk wrote:
> > The assertion only allows values of 1 (no_delay_for_missed_ticks)
> > up to 3 (one_missed_tick_pending). It should be possible to
> > use the value of 1 (delay_for_missed_ticks) for the timer configuration
                     ^- 0

> > option.
> 
> Doh! That was very likely a brainfart by me...

And by me in the git commit description :-(
> 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Ian Campbell <ian.cambell@citrix.com>


>From 4f7bd24184f98b4cf53cd8a24b89829c17ca3d1d Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 11:30:18 -0500
Subject: [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'

The assertion only allows values of 1 (no_delay_for_missed_ticks)
up to 3 (one_missed_tick_pending). It should be possible to
use the value of 0 (delay_for_missed_ticks) for the timer configuration
option.

Acked-by: Ian Campbell <ian.cambell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_dom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1cd9a4..de555ee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -417,7 +417,7 @@ out:
 static unsigned long timer_mode(const libxl_domain_build_info *info)
 {
     const libxl_timer_mode mode = info->u.hvm.timer_mode;
-    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+    assert(mode >= LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
            mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
     return ((unsigned long)mode);
 }
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:00:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17: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 1UA1Pz-0006or-Pd; Mon, 25 Feb 2013 17:00:47 +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 1UA1Px-0006oA-Lg
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 17:00:45 +0000
Received: from [85.158.143.99:28330] by server-1.bemta-4.messagelabs.com id
	46/34-06203-BB89B215; Mon, 25 Feb 2013 17:00:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361811640!28188768!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3611 invoked from network); 25 Feb 2013 17:00:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 17:00:42 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PH0b3O018009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 17:00:38 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
	r1PH0bhk024106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 17:00:37 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
	r1PH0awn023975; Mon, 25 Feb 2013 11:00:37 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 09:00:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0823B1C3935; Mon, 25 Feb 2013 12:00:35 -0500 (EST)
Date: Mon, 25 Feb 2013 12:00:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130225170034.GB10673@phenom.dumpdata.com>
References: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
	<1361810590.26546.196.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361810590.26546.196.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 04:43:10PM +0000, Ian Campbell wrote:
> On Mon, 2013-02-25 at 16:33 +0000, Konrad Rzeszutek Wilk wrote:
> > The assertion only allows values of 1 (no_delay_for_missed_ticks)
> > up to 3 (one_missed_tick_pending). It should be possible to
> > use the value of 1 (delay_for_missed_ticks) for the timer configuration
                     ^- 0

> > option.
> 
> Doh! That was very likely a brainfart by me...

And by me in the git commit description :-(
> 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Ian Campbell <ian.cambell@citrix.com>


>From 4f7bd24184f98b4cf53cd8a24b89829c17ca3d1d Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 11:30:18 -0500
Subject: [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'

The assertion only allows values of 1 (no_delay_for_missed_ticks)
up to 3 (one_missed_tick_pending). It should be possible to
use the value of 0 (delay_for_missed_ticks) for the timer configuration
option.

Acked-by: Ian Campbell <ian.cambell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 tools/libxl/libxl_dom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1cd9a4..de555ee 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -417,7 +417,7 @@ out:
 static unsigned long timer_mode(const libxl_domain_build_info *info)
 {
     const libxl_timer_mode mode = info->u.hvm.timer_mode;
-    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+    assert(mode >= LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
            mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
     return ((unsigned long)mode);
 }
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17: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 1UA1Sn-0007E1-EO; Mon, 25 Feb 2013 17:03:41 +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 1UA1Sl-0007Dk-Vn
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 17:03:40 +0000
Received: from [85.158.143.99:46511] by server-1.bemta-4.messagelabs.com id
	BE/67-06203-B699B215; Mon, 25 Feb 2013 17:03:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361811817!23873887!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28329 invoked from network); 25 Feb 2013 17:03:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 17:03:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PH3QKv029299
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 17:03: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
	r1PH3PCl004552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 17:03:26 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
	r1PH3PRS026615; Mon, 25 Feb 2013 11:03:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 09:03:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7420B1C3935; Mon, 25 Feb 2013 12:03:21 -0500 (EST)
Date: Mon, 25 Feb 2013 12:03:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20130225170321.GA11165@phenom.dumpdata.com>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
	<20130221124252.GR8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221124252.GR8912@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 02:42:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > > Hello,
> > > =

> > > Does anyone know why loading xen-acpi-processor driver fails like thi=
s?:
> > > =

> > > # modprobe xen-acpi-processor
> > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.=
centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output e=
rror
> > > =

> > > Using "modprobe -v" doesn't provide any more information about the pr=
oblem.
> > > Also there's nothing in dom0 kernel dmesg.
> > > =

> > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > > Xen 4.2.1.
> > > =

> > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable=
 version) =

> > > with some additional Xen patches backported from later upstream kerne=
ls. =

> > > Any tips how to troubleshoot this? =

> > =

> > Rebuild the module and add this
> > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-pr=
ocessor.c
> > index 316df65..5d824a2 100644
> > --- a/drivers/xen/xen-acpi-processor.c
> > +++ b/drivers/xen/xen-acpi-processor.c
> > @@ -16,6 +16,7 @@
> >   * more details.
> >   *
> >   */
> > +#define DEBUG 1
> >  =

> >  #include <linux/cpumask.h>
> >  #include <linux/cpufreq.h>
> > =

> > =

> > That should help in figuring it out.
> > =

> =

> Ok, I'll do that.
> =

> Thanks!

The other thing is that I've been running with this compiled as '=3Dy' inst=
ead
of '=3Dm'!

That should temporarily fix it for you, but this does need to be fixed.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:03:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17: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 1UA1Sn-0007E1-EO; Mon, 25 Feb 2013 17:03:41 +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 1UA1Sl-0007Dk-Vn
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 17:03:40 +0000
Received: from [85.158.143.99:46511] by server-1.bemta-4.messagelabs.com id
	BE/67-06203-B699B215; Mon, 25 Feb 2013 17:03:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361811817!23873887!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28329 invoked from network); 25 Feb 2013 17:03:38 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 17:03:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PH3QKv029299
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 17:03: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
	r1PH3PCl004552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 17:03:26 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
	r1PH3PRS026615; Mon, 25 Feb 2013 11:03:25 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 09:03:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7420B1C3935; Mon, 25 Feb 2013 12:03:21 -0500 (EST)
Date: Mon, 25 Feb 2013 12:03:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20130225170321.GA11165@phenom.dumpdata.com>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
	<20130221124252.GR8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130221124252.GR8912@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 21, 2013 at 02:42:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > > Hello,
> > > =

> > > Does anyone know why loading xen-acpi-processor driver fails like thi=
s?:
> > > =

> > > # modprobe xen-acpi-processor
> > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.=
centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output e=
rror
> > > =

> > > Using "modprobe -v" doesn't provide any more information about the pr=
oblem.
> > > Also there's nothing in dom0 kernel dmesg.
> > > =

> > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > > Xen 4.2.1.
> > > =

> > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable=
 version) =

> > > with some additional Xen patches backported from later upstream kerne=
ls. =

> > > Any tips how to troubleshoot this? =

> > =

> > Rebuild the module and add this
> > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-pr=
ocessor.c
> > index 316df65..5d824a2 100644
> > --- a/drivers/xen/xen-acpi-processor.c
> > +++ b/drivers/xen/xen-acpi-processor.c
> > @@ -16,6 +16,7 @@
> >   * more details.
> >   *
> >   */
> > +#define DEBUG 1
> >  =

> >  #include <linux/cpumask.h>
> >  #include <linux/cpufreq.h>
> > =

> > =

> > That should help in figuring it out.
> > =

> =

> Ok, I'll do that.
> =

> Thanks!

The other thing is that I've been running with this compiled as '=3Dy' inst=
ead
of '=3Dm'!

That should temporarily fix it for you, but this does need to be fixed.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:05:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17:05: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 1UA1Ud-0007Sp-Vp; Mon, 25 Feb 2013 17:05:35 +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 1UA1Uc-0007SQ-IC
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 17:05:34 +0000
Received: from [85.158.139.83:18204] by server-8.bemta-5.messagelabs.com id
	86/0F-05790-DD99B215; Mon, 25 Feb 2013 17:05:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361811929!27077493!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11581 invoked from network); 25 Feb 2013 17:05:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 17:05:31 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PH5PrN024147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 17:05:26 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
	r1PH5PIB005005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 17:05:25 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
	r1PH5PiM028305; Mon, 25 Feb 2013 11:05:25 -0600
Received: from [10.154.155.17] (/10.154.155.17)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 09:05:25 -0800
Message-ID: <512B99D1.7060509@oracle.com>
Date: Mon, 25 Feb 2013 12:05:21 -0500
From: konrad wilk <konrad.wilk@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
	<511E88B4.7060205@citrix.com>
	<20130225164929.GB10672@phenom.dumpdata.com>
	<512B98C9.2020008@citrix.com>
In-Reply-To: <512B98C9.2020008@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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-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 2/25/2013 12:00 PM, Roger Pau Monn=E9 wrote:
> On 25/02/13 17:49, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 15, 2013 at 08:12:52PM +0100, Roger Pau Monn=E9 wrote:
>>> On 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
>>>>> Should be backported to 3.8 stable.
>>>> Lets do one thing at a time.
>>>>
>>>> The patch I have in the tree (and that I've asked Jens to pull for 3.9=
 - so
>>>> he might have already in his tree) is the old hybrid where we still us=
e llist
>>>> but change the loop from 'for' to 'while'.
>>>>
>>>> This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/l=
inux/kernel/git/konrad/xen.git
>>>>
>>>> Could you rebase your patch on top of that tree and just simplify the =
loop?
>>>>
>>>> Sorry about the mess about this - but I had already pulled the trigger
>>>> so to say - hoping that Jens would pull the tree and do a git pull to =
Linus.
>>>>
>>>> And you are absolutly sure that we don't need any extra locking when s=
witching
>>>> over to list_head? Say if blkif_completion is called while we are
>>>> processing in blkif_queue_request and doing ?
>>> Will recheck it, but blkif_completition is called with the io_lock hold,
>>> as does blkif_queue_request (I've added extra assert_spin_locked before
>>> every list modification).
>> Can you rebase this patch on top of 'stable/for-jens-3.9' when you get a=
 chance
>> please?
> Yes, I was going to resubmit it as part of my indirect descriptors
> series (which I'm hoping to send before the end of the week), but if you
> are in a rush I can send it earlier, I already have it rebased on top of
> for-jens-3.9.

No rush. Just want to make sure it did not get lost. Thanks!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 17:05:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 17:05: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 1UA1Ud-0007Sp-Vp; Mon, 25 Feb 2013 17:05:35 +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 1UA1Uc-0007SQ-IC
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 17:05:34 +0000
Received: from [85.158.139.83:18204] by server-8.bemta-5.messagelabs.com id
	86/0F-05790-DD99B215; Mon, 25 Feb 2013 17:05:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361811929!27077493!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11581 invoked from network); 25 Feb 2013 17:05:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 17:05:31 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PH5PrN024147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 17:05:26 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
	r1PH5PIB005005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 17:05:25 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
	r1PH5PiM028305; Mon, 25 Feb 2013 11:05:25 -0600
Received: from [10.154.155.17] (/10.154.155.17)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 09:05:25 -0800
Message-ID: <512B99D1.7060509@oracle.com>
Date: Mon, 25 Feb 2013 12:05:21 -0500
From: konrad wilk <konrad.wilk@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
References: <1360951381-26313-1-git-send-email-roger.pau@citrix.com>
	<20130215185644.GB29539@phenom.dumpdata.com>
	<511E88B4.7060205@citrix.com>
	<20130225164929.GB10672@phenom.dumpdata.com>
	<512B98C9.2020008@citrix.com>
In-Reply-To: <512B98C9.2020008@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: switch from llist to 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-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 2/25/2013 12:00 PM, Roger Pau Monn=E9 wrote:
> On 25/02/13 17:49, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 15, 2013 at 08:12:52PM +0100, Roger Pau Monn=E9 wrote:
>>> On 15/02/13 19:56, Konrad Rzeszutek Wilk wrote:
>>>>> Should be backported to 3.8 stable.
>>>> Lets do one thing at a time.
>>>>
>>>> The patch I have in the tree (and that I've asked Jens to pull for 3.9=
 - so
>>>> he might have already in his tree) is the old hybrid where we still us=
e llist
>>>> but change the loop from 'for' to 'while'.
>>>>
>>>> This is the stable/for-jens-3.8 tree in git://git.kernel.org/pub/scm/l=
inux/kernel/git/konrad/xen.git
>>>>
>>>> Could you rebase your patch on top of that tree and just simplify the =
loop?
>>>>
>>>> Sorry about the mess about this - but I had already pulled the trigger
>>>> so to say - hoping that Jens would pull the tree and do a git pull to =
Linus.
>>>>
>>>> And you are absolutly sure that we don't need any extra locking when s=
witching
>>>> over to list_head? Say if blkif_completion is called while we are
>>>> processing in blkif_queue_request and doing ?
>>> Will recheck it, but blkif_completition is called with the io_lock hold,
>>> as does blkif_queue_request (I've added extra assert_spin_locked before
>>> every list modification).
>> Can you rebase this patch on top of 'stable/for-jens-3.9' when you get a=
 chance
>> please?
> Yes, I was going to resubmit it as part of my indirect descriptors
> series (which I'm hoping to send before the end of the week), but if you
> are in a rush I can send it earlier, I already have it rebased on top of
> for-jens-3.9.

No rush. Just want to make sure it did not get lost. Thanks!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 18:15:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18:15: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 1UA2Ze-0001cC-HA; Mon, 25 Feb 2013 18:14:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1UA2Zd-0001c7-2R
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 18:14:49 +0000
Received: from [85.158.137.99:46543] by server-16.bemta-3.messagelabs.com id
	71/5C-02727-81AAB215; Mon, 25 Feb 2013 18:14:48 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361816087!17157605!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15521 invoked from network); 25 Feb 2013 18:14:47 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 18:14:47 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so1406314bkc.7
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 10:14:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=KOo69LCOJdvW3Bxzi4sSCBidHjRjXfp7LzATCqgNB/I=;
	b=AI96JiButQ/Hk45tLTzVxEx+fRb/4xDZC80hJggroyyXQ36M9ScmSFlHjuamYLqpi9
	Z39IiEn5EOd+b/ynUsjjfeEAshLDupIoc1qmbTAcS8Pkh/i4W/mVoE+zKiMamfwAZZuU
	eaBINrHbRJRjXjpAMLXxVTowAHfyGIqaORCHtH65XDXFLFMhNiPxBhcFHXyHYoENVs9z
	m4j5L31NME6O7zOJdq7SZhko2YtixdnQby/rjt54YUo6tZCCvQ1yPaxc6a5EzgBTo8Zj
	b0YpjOOTKdC5hYSclhtL1vZjltEUWxu4p+vZ5tW+2Ay4mDZGobo4U5Z5QgTqvJvfyZTY
	bbIg==
MIME-Version: 1.0
X-Received: by 10.204.131.89 with SMTP id w25mr5411948bks.22.1361816086974;
	Mon, 25 Feb 2013 10:14:46 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 25 Feb 2013 10:14:46 -0800 (PST)
In-Reply-To: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
Date: Mon, 25 Feb 2013 19:14:46 +0100
Message-ID: <CAF6-1L5XeVJxQdpmvVVsdFb0eJudCOWAeJucfWD67HNVqQvxBg@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQnhOhvKtUrMC7o7BCrqE0uljYU6dmg81FonDh0rgp2plHmx3Pc10bDZFM1c0MK2BdHjCXW/
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 4.2.0 is already in Debian experimental.

Unfortunately, it's 4.2.0 not 4.2.1 and it's also missing a lot of things.

No PVGrub, no qemu (either -xen or -traditional), ...

I've been trying to modify the packages to make it build those, but
not all the problems are solved yet. Debian applies a bunch of patches
to install stuff "at the right places" ...

Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 18:15:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18:15: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 1UA2Ze-0001cC-HA; Mon, 25 Feb 2013 18:14:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1UA2Zd-0001c7-2R
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 18:14:49 +0000
Received: from [85.158.137.99:46543] by server-16.bemta-3.messagelabs.com id
	71/5C-02727-81AAB215; Mon, 25 Feb 2013 18:14:48 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361816087!17157605!1
X-Originating-IP: [209.85.214.48]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15521 invoked from network); 25 Feb 2013 18:14:47 -0000
Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com)
	(209.85.214.48)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 18:14:47 -0000
Received: by mail-bk0-f48.google.com with SMTP id jf20so1406314bkc.7
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 10:14:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type:x-gm-message-state;
	bh=KOo69LCOJdvW3Bxzi4sSCBidHjRjXfp7LzATCqgNB/I=;
	b=AI96JiButQ/Hk45tLTzVxEx+fRb/4xDZC80hJggroyyXQ36M9ScmSFlHjuamYLqpi9
	Z39IiEn5EOd+b/ynUsjjfeEAshLDupIoc1qmbTAcS8Pkh/i4W/mVoE+zKiMamfwAZZuU
	eaBINrHbRJRjXjpAMLXxVTowAHfyGIqaORCHtH65XDXFLFMhNiPxBhcFHXyHYoENVs9z
	m4j5L31NME6O7zOJdq7SZhko2YtixdnQby/rjt54YUo6tZCCvQ1yPaxc6a5EzgBTo8Zj
	b0YpjOOTKdC5hYSclhtL1vZjltEUWxu4p+vZ5tW+2Ay4mDZGobo4U5Z5QgTqvJvfyZTY
	bbIg==
MIME-Version: 1.0
X-Received: by 10.204.131.89 with SMTP id w25mr5411948bks.22.1361816086974;
	Mon, 25 Feb 2013 10:14:46 -0800 (PST)
Received: by 10.205.137.141 with HTTP; Mon, 25 Feb 2013 10:14:46 -0800 (PST)
In-Reply-To: <1361798137.26546.177.camel@zakaz.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<1361798137.26546.177.camel@zakaz.uk.xensource.com>
Date: Mon, 25 Feb 2013 19:14:46 +0100
Message-ID: <CAF6-1L5XeVJxQdpmvVVsdFb0eJudCOWAeJucfWD67HNVqQvxBg@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Gm-Message-State: ALoCoQnhOhvKtUrMC7o7BCrqE0uljYU6dmg81FonDh0rgp2plHmx3Pc10bDZFM1c0MK2BdHjCXW/
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Tim Deegan <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 4.2.0 is already in Debian experimental.

Unfortunately, it's 4.2.0 not 4.2.1 and it's also missing a lot of things.

No PVGrub, no qemu (either -xen or -traditional), ...

I've been trying to modify the packages to make it build those, but
not all the problems are solved yet. Debian applies a bunch of patches
to install stuff "at the right places" ...

Cheers,

    Sylvain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 18:32:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18: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 1UA2px-0002Rr-E1; Mon, 25 Feb 2013 18:31:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>)
	id 1UA2pv-0002RJ-FY; Mon, 25 Feb 2013 18:31:39 +0000
Received: from [85.158.138.51:50512] by server-13.bemta-3.messagelabs.com id
	79/AA-20653-A0EAB215; Mon, 25 Feb 2013 18:31:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361817095!23716840!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28695 invoked from network); 25 Feb 2013 18:31:37 -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 Feb 2013 18:31:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="8990160"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 18:31:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 13:31:34 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UA2pq-0004SX-Qh;
	Mon, 25 Feb 2013 18:31:34 +0000
Message-ID: <1361817094.2109.36.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 25 Feb 2013 18:31:34 +0000
In-Reply-To: <CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
References: <1361786229.2109.15.camel@zion.uk.xensource.com>
	<CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-arm <xen-arm@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 18:26 +0000, Grant McWilliams wrote:
> 
> We have two Xen Document Days one week apart?


No. We remind people of the Xen Docsday one week before. And we also
send another email when it is happening. :-)


Regards
Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 18:32:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18: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 1UA2px-0002Rr-E1; Mon, 25 Feb 2013 18:31:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>)
	id 1UA2pv-0002RJ-FY; Mon, 25 Feb 2013 18:31:39 +0000
Received: from [85.158.138.51:50512] by server-13.bemta-3.messagelabs.com id
	79/AA-20653-A0EAB215; Mon, 25 Feb 2013 18:31:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361817095!23716840!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDM5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28695 invoked from network); 25 Feb 2013 18:31:37 -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 Feb 2013 18:31:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="8990160"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 18:31:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 13:31:34 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UA2pq-0004SX-Qh;
	Mon, 25 Feb 2013 18:31:34 +0000
Message-ID: <1361817094.2109.36.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 25 Feb 2013 18:31:34 +0000
In-Reply-To: <CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
References: <1361786229.2109.15.camel@zion.uk.xensource.com>
	<CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>, wei.liu2@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-arm <xen-arm@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 18:26 +0000, Grant McWilliams wrote:
> 
> We have two Xen Document Days one week apart?


No. We remind people of the Xen Docsday one week before. And we also
send another email when it is happening. :-)


Regards
Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 18:35:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18:35: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 1UA2su-0002rk-NS; Mon, 25 Feb 2013 18:34:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <don@cloudswitch.com>) id 1UA2st-0002rS-Sj
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 18:34:44 +0000
Received: from [85.158.139.83:59174] by server-9.bemta-5.messagelabs.com id
	58/95-08547-2CEAB215; Mon, 25 Feb 2013 18:34:42 +0000
X-Env-Sender: don@cloudswitch.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361817280!29137403!1
X-Originating-IP: [206.225.164.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjIyNS4xNjQuMjIyID0+IDc4MzU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24506 invoked from network); 25 Feb 2013 18:34:41 -0000
Received: from hub021-nj-6.exch021.serverdata.net (HELO
	hub021-nj-6.exch021.serverdata.net) (206.225.164.222)
	by server-10.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Feb 2013 18:34:41 -0000
Received: from don-760.CloudSwitch.com (152.179.192.130) by
	east.exch021.serverdata.net (10.240.4.93) with Microsoft SMTP Server
	(TLS) id 14.2.318.1; Mon, 25 Feb 2013 10:34:38 -0800
Message-ID: <512BAEB3.4010708@CloudSwitch.Com>
Date: Mon, 25 Feb 2013 13:34:27 -0500
From: Don Slutz <Don@CloudSwitch.Com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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-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/21/13 12:57, David Vrabel wrote:
> The series adds support for the new hypercall ABI which should be
> provided by Xen 4.3.  Images are loaded into Xen directly with no
> kernel involvement.
>
> Do not apply until the hypervisor side patches are applied to Xen.
>
> Patch 1 is unrelated but kexec wouldn't work for me without it. Not
> sure why I had problems, perhaps a toolstack specific issue?
>
> Patch 2 makes libxc 4.3 mandatory for Xen support.
>
> Patch 3 removes a use of /proc/iomem in favour of libxc.
>
> Patch 4 adds the support for loading an image into Xen.
>
> This series explicitly drops support for older version of libxc/Xen as
> supporting kexec on these hypervisors requires kernel support that
> will never be available upstream.
>
> David
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I did not find a fix/change to get_xen_vmcoreinfo() to call on 
xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, ...

I found the following to work.
    -Don Slutz

 From 2cabc018d7613b0d2ac487cbf2a2e9438a441a8d Mon Sep 17 00:00:00 2001
From: Don Slutz <Don@CloudSwitch.com>
Date: Fri, 22 Feb 2013 22:27:03 -0500
Subject: [PATCH 1/2] Switch to use xc_kexec_get_range for 
get_xen_vmcoreinfo.

Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
  kexec/crashdump-xen.c |   20 ++++++++++++++++++++
  kexec/crashdump.c     |    2 ++
  2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index 56b0653..8179b72 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -161,6 +161,26 @@ unsigned long xen_architecture(struct 
crash_elf_info *elf_info)
  }

  #ifdef HAVE_LIBXENCTRL
+int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
+{
+       xc_interface *xc;
+        int ret = 0;
+
+       xc = xc_interface_open(NULL, NULL, 0);
+       if ( !xc ) {
+               fprintf(stderr, "failed to open xen control interface.\n");
+               return -1;
+       }
+
+        ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, 0, len, 
addr);
+
+       xc_interface_close(xc);
+
+        if (ret < 0)
+            return -1;
+        return 0;
+}
+
  int xen_get_nr_phys_cpus(void)
  {
         xc_interface *xc;
diff --git a/kexec/crashdump.c b/kexec/crashdump.c
index 847d080..3d2c1b9 100644
--- a/kexec/crashdump.c
+++ b/kexec/crashdump.c
@@ -142,7 +142,9 @@ int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
         return get_vmcoreinfo("/sys/kernel/vmcoreinfo", addr, len);
  }

+#ifndef HAVE_LIBXENCTRL
  int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
  {
         return get_vmcoreinfo("/sys/hypervisor/vmcoreinfo", addr, len);
  }
+#endif
-- 
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 Feb 25 18:35:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18:35: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 1UA2su-0002rk-NS; Mon, 25 Feb 2013 18:34:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <don@cloudswitch.com>) id 1UA2st-0002rS-Sj
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 18:34:44 +0000
Received: from [85.158.139.83:59174] by server-9.bemta-5.messagelabs.com id
	58/95-08547-2CEAB215; Mon, 25 Feb 2013 18:34:42 +0000
X-Env-Sender: don@cloudswitch.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361817280!29137403!1
X-Originating-IP: [206.225.164.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjIyNS4xNjQuMjIyID0+IDc4MzU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24506 invoked from network); 25 Feb 2013 18:34:41 -0000
Received: from hub021-nj-6.exch021.serverdata.net (HELO
	hub021-nj-6.exch021.serverdata.net) (206.225.164.222)
	by server-10.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Feb 2013 18:34:41 -0000
Received: from don-760.CloudSwitch.com (152.179.192.130) by
	east.exch021.serverdata.net (10.240.4.93) with Microsoft SMTP Server
	(TLS) id 14.2.318.1; Mon, 25 Feb 2013 10:34:38 -0800
Message-ID: <512BAEB3.4010708@CloudSwitch.Com>
Date: Mon, 25 Feb 2013 13:34:27 -0500
From: Don Slutz <Don@CloudSwitch.Com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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-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/21/13 12:57, David Vrabel wrote:
> The series adds support for the new hypercall ABI which should be
> provided by Xen 4.3.  Images are loaded into Xen directly with no
> kernel involvement.
>
> Do not apply until the hypervisor side patches are applied to Xen.
>
> Patch 1 is unrelated but kexec wouldn't work for me without it. Not
> sure why I had problems, perhaps a toolstack specific issue?
>
> Patch 2 makes libxc 4.3 mandatory for Xen support.
>
> Patch 3 removes a use of /proc/iomem in favour of libxc.
>
> Patch 4 adds the support for loading an image into Xen.
>
> This series explicitly drops support for older version of libxc/Xen as
> supporting kexec on these hypervisors requires kernel support that
> will never be available upstream.
>
> David
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I did not find a fix/change to get_xen_vmcoreinfo() to call on 
xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, ...

I found the following to work.
    -Don Slutz

 From 2cabc018d7613b0d2ac487cbf2a2e9438a441a8d Mon Sep 17 00:00:00 2001
From: Don Slutz <Don@CloudSwitch.com>
Date: Fri, 22 Feb 2013 22:27:03 -0500
Subject: [PATCH 1/2] Switch to use xc_kexec_get_range for 
get_xen_vmcoreinfo.

Signed-off-by: Don Slutz <Don@CloudSwitch.com>
---
  kexec/crashdump-xen.c |   20 ++++++++++++++++++++
  kexec/crashdump.c     |    2 ++
  2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index 56b0653..8179b72 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -161,6 +161,26 @@ unsigned long xen_architecture(struct 
crash_elf_info *elf_info)
  }

  #ifdef HAVE_LIBXENCTRL
+int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
+{
+       xc_interface *xc;
+        int ret = 0;
+
+       xc = xc_interface_open(NULL, NULL, 0);
+       if ( !xc ) {
+               fprintf(stderr, "failed to open xen control interface.\n");
+               return -1;
+       }
+
+        ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, 0, len, 
addr);
+
+       xc_interface_close(xc);
+
+        if (ret < 0)
+            return -1;
+        return 0;
+}
+
  int xen_get_nr_phys_cpus(void)
  {
         xc_interface *xc;
diff --git a/kexec/crashdump.c b/kexec/crashdump.c
index 847d080..3d2c1b9 100644
--- a/kexec/crashdump.c
+++ b/kexec/crashdump.c
@@ -142,7 +142,9 @@ int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
         return get_vmcoreinfo("/sys/kernel/vmcoreinfo", addr, len);
  }

+#ifndef HAVE_LIBXENCTRL
  int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
  {
         return get_vmcoreinfo("/sys/hypervisor/vmcoreinfo", addr, len);
  }
+#endif
-- 
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 Feb 25 18:46:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18:46: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 1UA34L-0003gL-PU; Mon, 25 Feb 2013 18:46:33 +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 1UA34K-0003gD-4r
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 18:46:32 +0000
Received: from [85.158.137.99:19581] by server-12.bemta-3.messagelabs.com id
	3E/DB-05889-781BB215; Mon, 25 Feb 2013 18:46:31 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361817966!13283292!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3328 invoked from network); 25 Feb 2013 18:46:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 18:46:07 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 00834A4F28;
	Mon, 25 Feb 2013 19:46:01 +0100 (CET)
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
To: qemu-devel@nongnu.org
Date: Mon, 25 Feb 2013 19:45:49 +0100
Message-Id: <1361817954-8984-3-git-send-email-afaerber@suse.de>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361817954-8984-1-git-send-email-afaerber@suse.de>
References: <1361817954-8984-1-git-send-email-afaerber@suse.de>
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>, Guan Xuetao <gxt@mprc.pku.edu.cn>,
	"open list:Overall" <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Alexander Graf <agraf@suse.de>,
	Fabien Chouteau <chouteau@adacore.com>, Blue Swirl <blauwirbel@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>, Michael Walle <michael@walle.cc>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	"open list:e500" <qemu-ppc@nongnu.org>, Paul Brook <paul@codesourcery.com>,
	Scott Wood <scottwood@freescale.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Richard Henderson <rth@twiddle.net>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
	Aurelien Jarno <aurelien@aurel32.net>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [Xen-devel] [PATCH qom-cpu v2 2/7] cpu: Move halted and
	interrupt_request fields to CPUState
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Qm90aCBmaWVsZHMgYXJlIHVzZWQgaW4gVk1TdGF0ZSwgdGh1cyBuZWVkIHRvIGJlIG1vdmVkIHRv
Z2V0aGVyLgpFeHBsaWNpdGx5IHplcm8gdGhlbSBvbiByZXNldCBzaW5jZSB0aGV5IHdlcmUgbG9j
YXRlZCBiZWZvcmUKYnJlYWtwb2ludHMuCgpQYXNzIFBvd2VyUENDUFUgdG8ga3ZtcHBjX2hhbmRs
ZV9oYWx0KCkuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZWFzIEbDpHJiZXIgPGFmYWVyYmVyQHN1c2Uu
ZGU+Ci0tLQogY3B1LWV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMzQgKysrKysr
KysrKysrLS0tLS0tLS0tLS0tCiBjcHVzLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgNCArLS0KIGV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDE2ICsrKysr
KystLS0tLQogZ2Ric3R1Yi5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIGh3
L2xlb24zLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIGh3L29tYXAxLmMg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA3ICsrKy0tCiBody9vcGVucmlzY190aW1lci5j
ICAgICAgICAgICAgICAgIHwgICAgNCArKy0KIGh3L3BwYy5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgIDIyICsrKysrKysrKystLS0tLS0KIGh3L3BwYy9lNTAwLmMgICAgICAgICAgICAg
ICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9wcGNlNTAwX3NwaW4uYyAgICAgICAgICAgICAg
ICAgIHwgICAgMiArLQogaHcvcHhhMnh4X2dwaW8uYyAgICAgICAgICAgICAgICAgICB8ICAgIDMg
KystCiBody9weGEyeHhfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAgMyArKy0KIGh3L3Mz
OTB4L3MzOTAtdmlydGlvLmMgICAgICAgICAgICAgfCAgIDE0ICsrKysrKy0tLS0KIGh3L3NwYXBy
LmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9zcGFwcl9oY2Fs
bC5jICAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogaHcvc3BhcHJfcnRhcy5jICAgICAgICAg
ICAgICAgICAgICB8ICAgIDYgKystLS0KIGh3L3N1bjRtLmMgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgIDIxICsrKysrKysrLS0tLS0tLQogaHcvc3VuNHUuYyAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgMTUgKysrKysrKy0tLS0KIGh3L3hlbl9tYWNoaW5lX3B2LmMgICAgICAgICAgICAg
ICAgfCAgICA2ICsrLS0tCiBody94dGVuc2FfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAg
OCArKystLS0KIGluY2x1ZGUvZXhlYy9jcHUtZGVmcy5oICAgICAgICAgICAgfCAgICAyIC0tCiBp
bmNsdWRlL3FvbS9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArKysKIGt2bS1hbGwuYyAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAyICstCiBxb20vY3B1LmMgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgMiArKwogdGFyZ2V0LWFscGhhL2NwdS5oICAgICAgICAgICAgICAg
ICB8ICAgIDQgKy0tCiB0YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMgICAgICAgICAgIHwgICAgMyAr
Ky0KIHRhcmdldC1hcm0vY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0
LWFybS9oZWxwZXIuYyAgICAgICAgICAgICAgICB8ICAgIDQgKystCiB0YXJnZXQtYXJtL29wX2hl
bHBlci5jICAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1jcmlzL2NwdS5oICAgICAgICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LWNyaXMvaGVscGVyLmMgICAgICAgICAgICAgICB8
ICAgIDkgKysrKy0tLQogdGFyZ2V0LWNyaXMvdHJhbnNsYXRlLmMgICAgICAgICAgICB8ICAgIDMg
KystCiB0YXJnZXQtaTM4Ni9jcHUuYyAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogdGFyZ2V0
LWkzODYvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgMjAgKysrKysrKystLS0tLS0tCiB0YXJn
ZXQtaTM4Ni9oZWxwZXIuYyAgICAgICAgICAgICAgIHwgICAxMiArKysrKy0tLS0KIHRhcmdldC1p
Mzg2L2t2bS5jICAgICAgICAgICAgICAgICAgfCAgIDUwICsrKysrKysrKysrKysrKysrKystLS0t
LS0tLS0tLS0tLS0tLQogdGFyZ2V0LWkzODYvbWFjaGluZS5jICAgICAgICAgICAgICB8ICAgIDIg
Ky0KIHRhcmdldC1pMzg2L21pc2NfaGVscGVyLmMgICAgICAgICAgfCAgIDIxICsrKysrKysrKyst
LS0tLQogdGFyZ2V0LWkzODYvc3ZtX2hlbHBlci5jICAgICAgICAgICB8ICAgIDkgKysrKy0tLQog
dGFyZ2V0LWxtMzIvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtbG0z
Mi9vcF9oZWxwZXIuYyAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1tNjhrL2NwdS5oICAg
ICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LW02OGsvb3BfaGVscGVyLmMgICAgICAg
ICAgICB8ICAgIDQgKystCiB0YXJnZXQtbTY4ay9xcmVncy5kZWYgICAgICAgICAgICAgIHwgICAg
MSAtCiB0YXJnZXQtbTY4ay90cmFuc2xhdGUuYyAgICAgICAgICAgIHwgICAgOCArKysrKy0KIHRh
cmdldC1taWNyb2JsYXplL2NwdS5oICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LW1pcHMv
Y3B1LmggICAgICAgICAgICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtbWlwcy9vcF9oZWxwZXIu
YyAgICAgICAgICAgIHwgICAxMCArKysrKy0tLQogdGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMgICAg
ICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtb3BlbnJpc2MvY3B1LmggICAgICAgICAgICAgIHwg
ICAgNCArLS0KIHRhcmdldC1vcGVucmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMgfCAgICAzICsrLQog
dGFyZ2V0LW9wZW5yaXNjL3N5c19oZWxwZXIuYyAgICAgICB8ICAgIDMgKystCiB0YXJnZXQtcHBj
L2NwdS5oICAgICAgICAgICAgICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQtcHBjL2V4Y3BfaGVs
cGVyLmMgICAgICAgICAgIHwgICAyMiArKysrKysrKysrKy0tLS0tCiB0YXJnZXQtcHBjL2hlbHBl
cl9yZWdzLmggICAgICAgICAgIHwgICAxMSArKysrKy0tLQogdGFyZ2V0LXBwYy9rdm0uYyAgICAg
ICAgICAgICAgICAgICB8ICAgMTYgKysrKysrKy0tLS0tCiB0YXJnZXQtcHBjL3RyYW5zbGF0ZS5j
ICAgICAgICAgICAgIHwgICAgMyArKy0KIHRhcmdldC1zMzkweC9jcHUuYyAgICAgICAgICAgICAg
ICAgfCAgICA4ICsrKy0tLQogdGFyZ2V0LXMzOTB4L2NwdS5oICAgICAgICAgICAgICAgICB8ICAg
IDUgKystLQogdGFyZ2V0LXMzOTB4L2hlbHBlci5jICAgICAgICAgICAgICB8ICAgIDcgKysrLS0K
IHRhcmdldC1zaDQvY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LXNo
NC9oZWxwZXIuYyAgICAgICAgICAgICAgICB8ICAgIDUgKystLQogdGFyZ2V0LXNoNC9vcF9oZWxw
ZXIuYyAgICAgICAgICAgICB8ICAgIDQgKystCiB0YXJnZXQtc3BhcmMvY3B1LmggICAgICAgICAg
ICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQtc3BhcmMvaGVscGVyLmMgICAgICAgICAgICAgIHwg
ICAgNCArKy0KIHRhcmdldC11bmljb3JlMzIvY3B1LmggICAgICAgICAgICAgfCAgICA0ICstLQog
dGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11LmMgICAgICAgICB8ICAgIDMgKystCiB0YXJnZXQteHRl
bnNhL29wX2hlbHBlci5jICAgICAgICAgIHwgICAgNSArKystCiB0cmFuc2xhdGUtYWxsLmMgICAg
ICAgICAgICAgICAgICAgIHwgICAxMCArKysrLS0tLQogeGVuLWFsbC5jICAgICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgMTAgKysrKystLS0KIDcwIERhdGVpZW4gZ2XDpG5kZXJ0LCAzMTkgWmVp
bGVuIGhpbnp1Z2Vmw7xndCgrKSwgMjI0IFplaWxlbiBlbnRmZXJudCgtKQoKZGlmZiAtLWdpdCBh
L2NwdS1leGVjLmMgYi9jcHUtZXhlYy5jCmluZGV4IGFmYmU0OTcuLmYxZGE0ZTQgMTAwNjQ0Ci0t
LSBhL2NwdS1leGVjLmMKKysrIGIvY3B1LWV4ZWMuYwpAQCAtMTg4LDEyICsxODgsMTIgQEAgaW50
IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogICAgIHVpbnQ4X3QgKnRjX3B0cjsKICAgICB0
Y2dfdGFyZ2V0X3Vsb25nIG5leHRfdGI7CiAKLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBp
ZiAoY3B1LT5oYWx0ZWQpIHsKICAgICAgICAgaWYgKCFjcHVfaGFzX3dvcmsoY3B1KSkgewogICAg
ICAgICAgICAgcmV0dXJuIEVYQ1BfSEFMVEVEOwogICAgICAgICB9CiAKLSAgICAgICAgZW52LT5o
YWx0ZWQgPSAwOworICAgICAgICBjcHUtPmhhbHRlZCA9IDA7CiAgICAgfQogCiAgICAgY3B1X3Np
bmdsZV9lbnYgPSBlbnY7CkBAIC0yNjMsMTQgKzI2MywxNCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJj
aFN0YXRlICplbnYpCiAKICAgICAgICAgICAgIG5leHRfdGIgPSAwOyAvKiBmb3JjZSBsb29rdXAg
b2YgZmlyc3QgVEIgKi8KICAgICAgICAgICAgIGZvcig7OykgewotICAgICAgICAgICAgICAgIGlu
dGVycnVwdF9yZXF1ZXN0ID0gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdDsKKyAgICAgICAgICAgICAg
ICBpbnRlcnJ1cHRfcmVxdWVzdCA9IGNwdS0+aW50ZXJydXB0X3JlcXVlc3Q7CiAgICAgICAgICAg
ICAgICAgaWYgKHVubGlrZWx5KGludGVycnVwdF9yZXF1ZXN0KSkgewogICAgICAgICAgICAgICAg
ICAgICBpZiAodW5saWtlbHkoZW52LT5zaW5nbGVzdGVwX2VuYWJsZWQgJiBTU1RFUF9OT0lSUSkp
IHsKICAgICAgICAgICAgICAgICAgICAgICAgIC8qIE1hc2sgb3V0IGV4dGVybmFsIGludGVycnVw
dHMgZm9yIHRoaXMgc3RlcC4gKi8KICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycnVwdF9y
ZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NTVEVQX01BU0s7CiAgICAgICAgICAgICAgICAgICAg
IH0KICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9ERUJVRykgewotICAgICAgICAgICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9ERUJVRzsKKyAgICAgICAgICAgICAgICAgICAgICAgIGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfREVCVUc7CiAgICAgICAgICAg
ICAgICAgICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfREVCVUc7CiAgICAgICAg
ICAgICAgICAgICAgICAgICBjcHVfbG9vcF9leGl0KGVudik7CiAgICAgICAgICAgICAgICAgICAg
IH0KQEAgLTI3OCw4ICsyNzgsOCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAg
ICAgZGVmaW5lZChUQVJHRVRfUFBDKSB8fCBkZWZpbmVkKFRBUkdFVF9BTFBIQSkgfHwgZGVmaW5l
ZChUQVJHRVRfQ1JJUykgfHwgXAogICAgIGRlZmluZWQoVEFSR0VUX01JQ1JPQkxBWkUpIHx8IGRl
ZmluZWQoVEFSR0VUX0xNMzIpIHx8IGRlZmluZWQoVEFSR0VUX1VOSUNPUkUzMikKICAgICAgICAg
ICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQUxUKSB7
Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVf
SU5URVJSVVBUX0hBTFQ7Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCA9IDE7
CisgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVf
SU5URVJSVVBUX0hBTFQ7CisgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmhhbHRlZCA9IDE7
CiAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExU
OwogICAgICAgICAgICAgICAgICAgICAgICAgY3B1X2xvb3BfZXhpdChlbnYpOwogICAgICAgICAg
ICAgICAgICAgICB9CkBAIC0yODcsNyArMjg3LDcgQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0
ZSAqZW52KQogI2lmIGRlZmluZWQoVEFSR0VUX0kzODYpCiAjaWYgIWRlZmluZWQoQ09ORklHX1VT
RVJfT05MWSkKICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BV
X0lOVEVSUlVQVF9QT0xMKSB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7CisgICAgICAgICAgICAgICAgICAgICAg
ICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7CiAgICAgICAg
ICAgICAgICAgICAgICAgICBhcGljX3BvbGxfaXJxKGVudi0+YXBpY19zdGF0ZSk7CiAgICAgICAg
ICAgICAgICAgICAgIH0KICNlbmRpZgpAQCAtMzA0LDE3ICszMDQsMTcgQEAgaW50IGNwdV9leGVj
KENQVUFyY2hTdGF0ZSAqZW52KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICEoZW52LT5o
ZmxhZ3MgJiBIRl9TTU1fTUFTSykpIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHVf
c3ZtX2NoZWNrX2ludGVyY2VwdF9wYXJhbShlbnYsIFNWTV9FWElUX1NNSSwKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwKTsKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5U
RVJSVVBUX1NNSTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9y
ZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NNSTsKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBkb19zbW1fZW50ZXIoZW52KTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZXh0X3Ri
ID0gMDsKICAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxzZSBpZiAoKGludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9OTUkpICYmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICEoZW52LT5oZmxhZ3MyICYgSEYyX05NSV9NQVNLKSkgewotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfTk1J
OworICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0g
fkNQVV9JTlRFUlJVUFRfTk1JOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+aGZs
YWdzMiB8PSBIRjJfTk1JX01BU0s7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9faW50
ZXJydXB0X3g4Nl9oYXJkaXJxKGVudiwgRVhDUDAyX05NSSwgMSk7CiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAgICAgICAgICAgICAgICB9IGVsc2Ug
aWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9NQ0UpIHsKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBU
X01DRTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0
ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb19p
bnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBFWENQMTJfTUNISywgMCk7CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAgICAgICAgICAgICAgICB9IGVs
c2UgaWYgKChpbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKQEAgLTMy
Niw3ICszMjYsOCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaW50IGludG5vOwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNwdV9zdm1fY2hlY2tfaW50ZXJjZXB0X3BhcmFtKGVudiwgU1ZNX0VYSVRfSU5UUiwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwKTsK
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH4o
Q1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9WSVJRKTsKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH4oQ1BVX0lOVEVSUlVQVF9I
QVJEIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgQ1BVX0lOVEVSUlVQVF9WSVJRKTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bnRubyA9IGNwdV9nZXRfcGljX2ludGVycnVwdChlbnYpOwogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHFlbXVfbG9nX21hc2soQ1BVX0xPR19UQl9JTl9BU00sICJTZXJ2aWNpbmcgaGFyZHdh
cmUgSU5UPTB4JTAyeFxuIiwgaW50bm8pOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRv
X2ludGVycnVwdF94ODZfaGFyZGlycShlbnYsIGludG5vLCAxKTsKQEAgLTM0NCw3ICszNDUsNyBA
QCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaW50bm8gPSBsZGxfcGh5cyhlbnYtPnZtX3ZtY2IgKyBvZmZzZXRvZihzdHJ1Y3Qgdm1j
YiwgY29udHJvbC5pbnRfdmVjdG9yKSk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcWVt
dV9sb2dfbWFzayhDUFVfTE9HX1RCX0lOX0FTTSwgIlNlcnZpY2luZyB2aXJ0dWFsIGhhcmR3YXJl
IElOVD0weCUwMnhcbiIsIGludG5vKTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb19p
bnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBpbnRubywgMSk7Ci0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9WSVJROwor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQ
VV9JTlRFUlJVUFRfVklSUTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZXh0X3RiID0g
MDsKICNlbmRpZgogICAgICAgICAgICAgICAgICAgICAgICAgfQpAQCAtMzU1LDggKzM1Niw5IEBA
IGludCBjcHVfZXhlYyhDUFVBcmNoU3RhdGUgKmVudikKICAgICAgICAgICAgICAgICAgICAgfQog
ICAgICAgICAgICAgICAgICAgICBpZiAoaW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBU
X0hBUkQpIHsKICAgICAgICAgICAgICAgICAgICAgICAgIHBwY19od19pbnRlcnJ1cHQoZW52KTsK
LSAgICAgICAgICAgICAgICAgICAgICAgIGlmIChlbnYtPnBlbmRpbmdfaW50ZXJydXB0cyA9PSAw
KQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0g
fkNQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICAgICAgICAgICAgICAgICAgICAgIGlmIChlbnYtPnBl
bmRpbmdfaW50ZXJydXB0cyA9PSAwKSB7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3B1
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9IQVJEOworICAgICAgICAgICAg
ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAg
ICAgICAgICAgICAgICAgIH0KICNlbGlmIGRlZmluZWQoVEFSR0VUX0xNMzIpCkBAIC01MzMsOCAr
NTM1LDggQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogI2VuZGlmCiAgICAgICAg
ICAgICAgICAgICAgLyogRG9uJ3QgdXNlIHRoZSBjYWNoZWQgaW50ZXJydXB0X3JlcXVlc3QgdmFs
dWUsCiAgICAgICAgICAgICAgICAgICAgICAgZG9faW50ZXJydXB0IG1heSBoYXZlIHVwZGF0ZWQg
dGhlIEVYSVRUQiBmbGFnLiAqLwotICAgICAgICAgICAgICAgICAgICBpZiAoZW52LT5pbnRlcnJ1
cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfRVhJVFRCKSB7Ci0gICAgICAgICAgICAgICAgICAg
ICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAg
ICAgICAgICAgICAgICAgICAgaWYgKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX0VYSVRUQikgeworICAgICAgICAgICAgICAgICAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgICAgICAgICAgICAgICAgICAgICAv
KiBlbnN1cmUgdGhhdCBubyBUQiBqdW1wIHdpbGwgYmUgbW9kaWZpZWQgYXMKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZSBwcm9ncmFtIGZsb3cgd2FzIGNoYW5nZWQgKi8KICAgICAgICAg
ICAgICAgICAgICAgICAgIG5leHRfdGIgPSAwOwpkaWZmIC0tZ2l0IGEvY3B1cy5jIGIvY3B1cy5j
CmluZGV4IDQ2MzU1YzEuLjhkNDdiZmQgMTAwNjQ0Ci0tLSBhL2NwdXMuYworKysgYi9jcHVzLmMK
QEAgLTcyLDcgKzcyLDcgQEAgc3RhdGljIGJvb2wgY3B1X3RocmVhZF9pc19pZGxlKENQVUFyY2hT
dGF0ZSAqZW52KQogICAgIGlmIChjcHUtPnN0b3BwZWQgfHwgIXJ1bnN0YXRlX2lzX3J1bm5pbmco
KSkgewogICAgICAgICByZXR1cm4gdHJ1ZTsKICAgICB9Ci0gICAgaWYgKCFlbnYtPmhhbHRlZCB8
fCBxZW11X2NwdV9oYXNfd29yayhjcHUpIHx8CisgICAgaWYgKCFjcHUtPmhhbHRlZCB8fCBxZW11
X2NwdV9oYXNfd29yayhjcHUpIHx8CiAgICAgICAgIGt2bV9hc3luY19pbnRlcnJ1cHRzX2VuYWJs
ZWQoKSkgewogICAgICAgICByZXR1cm4gZmFsc2U7CiAgICAgfQpAQCAtMTE5OCw3ICsxMTk4LDcg
QEAgQ3B1SW5mb0xpc3QgKnFtcF9xdWVyeV9jcHVzKEVycm9yICoqZXJycCkKICAgICAgICAgaW5m
by0+dmFsdWUgPSBnX21hbGxvYzAoc2l6ZW9mKCppbmZvLT52YWx1ZSkpOwogICAgICAgICBpbmZv
LT52YWx1ZS0+Q1BVID0gY3B1LT5jcHVfaW5kZXg7CiAgICAgICAgIGluZm8tPnZhbHVlLT5jdXJy
ZW50ID0gKGVudiA9PSBmaXJzdF9jcHUpOwotICAgICAgICBpbmZvLT52YWx1ZS0+aGFsdGVkID0g
ZW52LT5oYWx0ZWQ7CisgICAgICAgIGluZm8tPnZhbHVlLT5oYWx0ZWQgPSBjcHUtPmhhbHRlZDsK
ICAgICAgICAgaW5mby0+dmFsdWUtPnRocmVhZF9pZCA9IGNwdS0+dGhyZWFkX2lkOwogI2lmIGRl
ZmluZWQoVEFSR0VUX0kzODYpCiAgICAgICAgIGluZm8tPnZhbHVlLT5oYXNfcGMgPSB0cnVlOwpk
aWZmIC0tZ2l0IGEvZXhlYy5jIGIvZXhlYy5jCmluZGV4IDg0ZTQzYmQuLmUxODBhZWMgMTAwNjQ0
Ci0tLSBhL2V4ZWMuYworKysgYi9leGVjLmMKQEAgLTIyMywxMiArMjIzLDEyIEBAIHZvaWQgY3B1
X2V4ZWNfaW5pdF9hbGwodm9pZCkKIAogc3RhdGljIGludCBjcHVfY29tbW9uX3Bvc3RfbG9hZCh2
b2lkICpvcGFxdWUsIGludCB2ZXJzaW9uX2lkKQogewotICAgIENQVUFyY2hTdGF0ZSAqZW52ID0g
b3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBvcGFxdWU7CiAKICAgICAvKiAweDAxIHdhcyBD
UFVfSU5URVJSVVBUX0VYSVQuIFRoaXMgbGluZSBjYW4gYmUgcmVtb3ZlZCB3aGVuIHRoZQogICAg
ICAgIHZlcnNpb25faWQgaXMgaW5jcmVhc2VkLiAqLwotICAgIGVudi0+aW50ZXJydXB0X3JlcXVl
c3QgJj0gfjB4MDE7Ci0gICAgdGxiX2ZsdXNoKGVudiwgMSk7CisgICAgY3B1LT5pbnRlcnJ1cHRf
cmVxdWVzdCAmPSB+MHgwMTsKKyAgICB0bGJfZmx1c2goY3B1LT5lbnZfcHRyLCAxKTsKIAogICAg
IHJldHVybiAwOwogfQpAQCAtMjQwLDggKzI0MCw4IEBAIHN0YXRpYyBjb25zdCBWTVN0YXRlRGVz
Y3JpcHRpb24gdm1zdGF0ZV9jcHVfY29tbW9uID0gewogICAgIC5taW5pbXVtX3ZlcnNpb25faWRf
b2xkID0gMSwKICAgICAucG9zdF9sb2FkID0gY3B1X2NvbW1vbl9wb3N0X2xvYWQsCiAgICAgLmZp
ZWxkcyAgICAgID0gKFZNU3RhdGVGaWVsZCBbXSkgewotICAgICAgICBWTVNUQVRFX1VJTlQzMiho
YWx0ZWQsIENQVUFyY2hTdGF0ZSksCi0gICAgICAgIFZNU1RBVEVfVUlOVDMyKGludGVycnVwdF9y
ZXF1ZXN0LCBDUFVBcmNoU3RhdGUpLAorICAgICAgICBWTVNUQVRFX1VJTlQzMihoYWx0ZWQsIENQ
VVN0YXRlKSwKKyAgICAgICAgVk1TVEFURV9VSU5UMzIoaW50ZXJydXB0X3JlcXVlc3QsIENQVVN0
YXRlKSwKICAgICAgICAgVk1TVEFURV9FTkRfT0ZfTElTVCgpCiAgICAgfQogfTsKQEAgLTI5Myw3
ICsyOTMsNyBAQCB2b2lkIGNwdV9leGVjX2luaXQoQ1BVQXJjaFN0YXRlICplbnYpCiAjaWYgZGVm
aW5lZChDT05GSUdfVVNFUl9PTkxZKQogICAgIGNwdV9saXN0X3VubG9jaygpOwogI2VuZGlmCi0g
ICAgdm1zdGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2NwdV9jb21tb24s
IGVudik7CisgICAgdm1zdGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2Nw
dV9jb21tb24sIGNwdSk7CiAjaWYgZGVmaW5lZChDUFVfU0FWRV9WRVJTSU9OKSAmJiAhZGVmaW5l
ZChDT05GSUdfVVNFUl9PTkxZKQogICAgIHJlZ2lzdGVyX3NhdmV2bShOVUxMLCAiY3B1IiwgY3B1
X2luZGV4LCBDUFVfU0FWRV9WRVJTSU9OLAogICAgICAgICAgICAgICAgICAgICBjcHVfc2F2ZSwg
Y3B1X2xvYWQsIGVudik7CkBAIC00OTQsNyArNDk0LDkgQEAgdm9pZCBjcHVfc2luZ2xlX3N0ZXAo
Q1BVQXJjaFN0YXRlICplbnYsIGludCBlbmFibGVkKQogCiB2b2lkIGNwdV9yZXNldF9pbnRlcnJ1
cHQoQ1BVQXJjaFN0YXRlICplbnYsIGludCBtYXNrKQogewotICAgIGVudi0+aW50ZXJydXB0X3Jl
cXVlc3QgJj0gfm1hc2s7CisgICAgQ1BVU3RhdGUgKmNwdSA9IEVOVl9HRVRfQ1BVKGVudik7CisK
KyAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5tYXNrOwogfQogCiB2b2lkIGNwdV9leGl0
KENQVUFyY2hTdGF0ZSAqZW52KQpkaWZmIC0tZ2l0IGEvZ2Ric3R1Yi5jIGIvZ2Ric3R1Yi5jCmlu
ZGV4IDMyZGZlYTkuLjg0NmRlMWMgMTAwNjQ0Ci0tLSBhL2dkYnN0dWIuYworKysgYi9nZGJzdHVi
LmMKQEAgLTI0MDgsNyArMjQwOCw3IEBAIHN0YXRpYyBpbnQgZ2RiX2hhbmRsZV9wYWNrZXQoR0RC
U3RhdGUgKnMsIGNvbnN0IGNoYXIgKmxpbmVfYnVmKQogICAgICAgICAgICAgICAgIGNwdV9zeW5j
aHJvbml6ZV9zdGF0ZShlbnYpOwogICAgICAgICAgICAgICAgIGxlbiA9IHNucHJpbnRmKChjaGFy
ICopbWVtX2J1Ziwgc2l6ZW9mKG1lbV9idWYpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICJDUFUjJWQgWyVzXSIsIGNwdS0+Y3B1X2luZGV4LAotICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGVudi0+aGFsdGVkID8gImhhbHRlZCAiIDogInJ1bm5pbmciKTsKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmhhbHRlZCA/ICJoYWx0ZWQgIiA6ICJydW5uaW5n
Iik7CiAgICAgICAgICAgICAgICAgbWVtdG9oZXgoYnVmLCBtZW1fYnVmLCBsZW4pOwogICAgICAg
ICAgICAgICAgIHB1dF9wYWNrZXQocywgYnVmKTsKICAgICAgICAgICAgIH0KZGlmZiAtLWdpdCBh
L2h3L2xlb24zLmMgYi9ody9sZW9uMy5jCmluZGV4IGYxNmE4YmIuLmU5NzFkNWMgMTAwNjQ0Ci0t
LSBhL2h3L2xlb24zLmMKKysrIGIvaHcvbGVvbjMuYwpAQCAtNDksMTEgKzQ5LDEyIEBAIHR5cGVk
ZWYgc3RydWN0IFJlc2V0RGF0YSB7CiBzdGF0aWMgdm9pZCBtYWluX2NwdV9yZXNldCh2b2lkICpv
cGFxdWUpCiB7CiAgICAgUmVzZXREYXRhICpzICAgPSAoUmVzZXREYXRhICopb3BhcXVlOworICAg
IENQVVN0YXRlICpjcHUgPSBDUFUocy0+Y3B1KTsKICAgICBDUFVTUEFSQ1N0YXRlICAqZW52ID0g
JnMtPmNwdS0+ZW52OwogCi0gICAgY3B1X3Jlc2V0KENQVShzLT5jcHUpKTsKKyAgICBjcHVfcmVz
ZXQoY3B1KTsKIAotICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICBjcHUtPmhhbHRlZCA9IDA7CiAg
ICAgZW52LT5wYyAgICAgPSBzLT5lbnRyeTsKICAgICBlbnYtPm5wYyAgICA9IHMtPmVudHJ5ICsg
NDsKIH0KZGlmZiAtLWdpdCBhL2h3L29tYXAxLmMgYi9ody9vbWFwMS5jCmluZGV4IDYyM2IxMDEu
LmMzNmEzMzAgMTAwNjQ0Ci0tLSBhL2h3L29tYXAxLmMKKysrIGIvaHcvb21hcDEuYwpAQCAtMTcy
MSw2ICsxNzIxLDcgQEAgc3RhdGljIHVpbnQ2NF90IG9tYXBfY2xrZHNwX3JlYWQodm9pZCAqb3Bh
cXVlLCBod2FkZHIgYWRkciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln
bmVkIHNpemUpCiB7CiAgICAgc3RydWN0IG9tYXBfbXB1X3N0YXRlX3MgKnMgPSAoc3RydWN0IG9t
YXBfbXB1X3N0YXRlX3MgKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBDUFUocy0+Y3B1
KTsKIAogICAgIGlmIChzaXplICE9IDIpIHsKICAgICAgICAgcmV0dXJuIG9tYXBfYmFkd2lkdGhf
cmVhZDE2KG9wYXF1ZSwgYWRkcik7CkBAIC0xNzM3LDggKzE3MzgsOSBAQCBzdGF0aWMgdWludDY0
X3Qgb21hcF9jbGtkc3BfcmVhZCh2b2lkICpvcGFxdWUsIGh3YWRkciBhZGRyLAogICAgICAgICBy
ZXR1cm4gcy0+Y2xrbS5kc3BfcnN0Y3QyOwogCiAgICAgY2FzZSAweDE4OgkvKiBEU1BfU1lTU1Qg
Ki8KKyAgICAgICAgY3B1ID0gQ1BVKHMtPmNwdSk7CiAgICAgICAgIHJldHVybiAocy0+Y2xrbS5j
bG9ja2luZ19zY2hlbWUgPDwgMTEpIHwgcy0+Y2xrbS5jb2xkX3N0YXJ0IHwKLSAgICAgICAgICAg
ICAgICAocy0+Y3B1LT5lbnYuaGFsdGVkIDw8IDYpOyAgICAgIC8qIFF1aXRlIHVzZWxlc3MuLi4g
Ki8KKyAgICAgICAgICAgICAgICAoY3B1LT5oYWx0ZWQgPDwgNik7ICAgICAgLyogUXVpdGUgdXNl
bGVzcy4uLiAqLwogICAgIH0KIAogICAgIE9NQVBfQkFEX1JFRyhhZGRyKTsKQEAgLTM3NTQsOCAr
Mzc1Niw5IEBAIHN0YXRpYyB2b2lkIG9tYXBfc2V0dXBfZHNwX21hcHBpbmcoTWVtb3J5UmVnaW9u
ICpzeXN0ZW1fbWVtb3J5LAogdm9pZCBvbWFwX21wdV93YWtldXAodm9pZCAqb3BhcXVlLCBpbnQg
aXJxLCBpbnQgcmVxKQogewogICAgIHN0cnVjdCBvbWFwX21wdV9zdGF0ZV9zICptcHUgPSAoc3Ry
dWN0IG9tYXBfbXB1X3N0YXRlX3MgKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBDUFUo
bXB1LT5jcHUpOwogCi0gICAgaWYgKG1wdS0+Y3B1LT5lbnYuaGFsdGVkKSB7CisgICAgaWYgKGNw
dS0+aGFsdGVkKSB7CiAgICAgICAgIGNwdV9pbnRlcnJ1cHQoJm1wdS0+Y3B1LT5lbnYsIENQVV9J
TlRFUlJVUFRfRVhJVFRCKTsKICAgICB9CiB9CmRpZmYgLS1naXQgYS9ody9vcGVucmlzY190aW1l
ci5jIGIvaHcvb3BlbnJpc2NfdGltZXIuYwppbmRleCBkOTY1YmU3Li5mOWYxMTZhIDEwMDY0NAot
LS0gYS9ody9vcGVucmlzY190aW1lci5jCisrKyBiL2h3L29wZW5yaXNjX3RpbWVyLmMKQEAgLTcz
LDggKzczLDEwIEBAIHN0YXRpYyB2b2lkIG9wZW5yaXNjX3RpbWVyX2NiKHZvaWQgKm9wYXF1ZSkK
IAogICAgIGlmICgoY3B1LT5lbnYudHRtciAmIFRUTVJfSUUpICYmCiAgICAgICAgICBxZW11X3Rp
bWVyX2V4cGlyZWQoY3B1LT5lbnYudGltZXIsIHFlbXVfZ2V0X2Nsb2NrX25zKHZtX2Nsb2NrKSkp
IHsKKyAgICAgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CisKICAgICAgICAgY3B1LT5lbnYu
dHRtciB8PSBUVE1SX0lQOwotICAgICAgICBjcHUtPmVudi5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBD
UFVfSU5URVJSVVBUX1RJTUVSOworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BV
X0lOVEVSUlVQVF9USU1FUjsKICAgICB9CiAKICAgICBzd2l0Y2ggKGNwdS0+ZW52LnR0bXIgJiBU
VE1SX00pIHsKZGlmZiAtLWdpdCBhL2h3L3BwYy5jIGIvaHcvcHBjLmMKaW5kZXggOGNmYjg0Zi4u
ZTExZDJmOCAxMDA2NDQKLS0tIGEvaHcvcHBjLmMKKysrIGIvaHcvcHBjLmMKQEAgLTcyLDcgKzcy
LDcgQEAgdm9pZCBwcGNfc2V0X2lycShQb3dlclBDQ1BVICpjcHUsIGludCBuX0lSUSwgaW50IGxl
dmVsKQogCiAgICAgTE9HX0lSUSgiJXM6ICVwIG5fSVJRICVkIGxldmVsICVkID0+IHBlbmRpbmcg
JTA4IiBQUkl4MzIKICAgICAgICAgICAgICAgICAicmVxICUwOHhcbiIsIF9fZnVuY19fLCBlbnYs
IG5fSVJRLCBsZXZlbCwKLSAgICAgICAgICAgICAgICBlbnYtPnBlbmRpbmdfaW50ZXJydXB0cywg
ZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCk7CisgICAgICAgICAgICAgICAgZW52LT5wZW5kaW5nX2lu
dGVycnVwdHMsIENQVShjcHUpLT5pbnRlcnJ1cHRfcmVxdWVzdCk7CiB9CiAKIC8qIFBvd2VyUEMg
Nnh4IC8gN3h4IGludGVybmFsIElSUSBjb250cm9sbGVyICovCkBAIC04Nyw2ICs4Nyw4IEBAIHN0
YXRpYyB2b2lkIHBwYzZ4eF9zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVs
KQogICAgIGN1cl9sZXZlbCA9IChlbnYtPmlycV9pbnB1dF9zdGF0ZSA+PiBwaW4pICYgMTsKICAg
ICAvKiBEb24ndCBnZW5lcmF0ZSBzcHVyaW91cyBldmVudHMgKi8KICAgICBpZiAoKGN1cl9sZXZl
bCA9PSAxICYmIGxldmVsID09IDApIHx8IChjdXJfbGV2ZWwgPT0gMCAmJiBsZXZlbCAhPSAwKSkg
eworICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKKwogICAgICAgICBzd2l0Y2ggKHBp
bikgewogICAgICAgICBjYXNlIFBQQzZ4eF9JTlBVVF9UQkVOOgogICAgICAgICAgICAgLyogTGV2
ZWwgc2Vuc2l0aXZlIC0gYWN0aXZlIGhpZ2ggKi8KQEAgLTEyNiw3ICsxMjgsNyBAQCBzdGF0aWMg
dm9pZCBwcGM2eHhfc2V0X2lycSh2b2lkICpvcGFxdWUsIGludCBwaW4sIGludCBsZXZlbCkKICAg
ICAgICAgICAgIC8qIFhYWDogTm90ZSB0aGF0IHRoZSBvbmx5IHdheSB0byByZXN0YXJ0IHRoZSBD
UFUgaXMgdG8gcmVzZXQgaXQgKi8KICAgICAgICAgICAgIGlmIChsZXZlbCkgewogICAgICAgICAg
ICAgICAgIExPR19JUlEoIiVzOiBzdG9wIHRoZSBDUFVcbiIsIF9fZnVuY19fKTsKLSAgICAgICAg
ICAgICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7
CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBQUEM2eHhf
SU5QVVRfSFJFU0VUOgpAQCAtMTc0LDYgKzE3Niw4IEBAIHN0YXRpYyB2b2lkIHBwYzk3MF9zZXRf
aXJxKHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQogICAgIGN1cl9sZXZlbCA9IChl
bnYtPmlycV9pbnB1dF9zdGF0ZSA+PiBwaW4pICYgMTsKICAgICAvKiBEb24ndCBnZW5lcmF0ZSBz
cHVyaW91cyBldmVudHMgKi8KICAgICBpZiAoKGN1cl9sZXZlbCA9PSAxICYmIGxldmVsID09IDAp
IHx8IChjdXJfbGV2ZWwgPT0gMCAmJiBsZXZlbCAhPSAwKSkgeworICAgICAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUoY3B1KTsKKwogICAgICAgICBzd2l0Y2ggKHBpbikgewogICAgICAgICBjYXNlIFBQ
Qzk3MF9JTlBVVF9JTlQ6CiAgICAgICAgICAgICAvKiBMZXZlbCBzZW5zaXRpdmUgLSBhY3RpdmUg
aGlnaCAqLwpAQCAtMjAzLDExICsyMDcsMTEgQEAgc3RhdGljIHZvaWQgcHBjOTcwX3NldF9pcnEo
dm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwpCiAgICAgICAgICAgICAvKiBYWFg6IFRP
RE86IHJlbGF5IHRoZSBzaWduYWwgdG8gQ0tTVFBfT1VUIHBpbiAqLwogICAgICAgICAgICAgaWYg
KGxldmVsKSB7CiAgICAgICAgICAgICAgICAgTE9HX0lSUSgiJXM6IHN0b3AgdGhlIENQVVxuIiwg
X19mdW5jX18pOwotICAgICAgICAgICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgICAg
ICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAg
ICAgTE9HX0lSUSgiJXM6IHJlc3RhcnQgdGhlIENQVVxuIiwgX19mdW5jX18pOwotICAgICAgICAg
ICAgICAgIGVudi0+aGFsdGVkID0gMDsKLSAgICAgICAgICAgICAgICBxZW11X2NwdV9raWNrKENQ
VShjcHUpKTsKKyAgICAgICAgICAgICAgICBjcy0+aGFsdGVkID0gMDsKKyAgICAgICAgICAgICAg
ICBxZW11X2NwdV9raWNrKGNzKTsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGJyZWFrOwog
ICAgICAgICBjYXNlIFBQQzk3MF9JTlBVVF9IUkVTRVQ6CkBAIC0yOTUsNiArMjk5LDggQEAgc3Rh
dGljIHZvaWQgcHBjNDB4X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwp
CiAgICAgY3VyX2xldmVsID0gKGVudi0+aXJxX2lucHV0X3N0YXRlID4+IHBpbikgJiAxOwogICAg
IC8qIERvbid0IGdlbmVyYXRlIHNwdXJpb3VzIGV2ZW50cyAqLwogICAgIGlmICgoY3VyX2xldmVs
ID09IDEgJiYgbGV2ZWwgPT0gMCkgfHwgKGN1cl9sZXZlbCA9PSAwICYmIGxldmVsICE9IDApKSB7
CisgICAgICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOworCiAgICAgICAgIHN3aXRjaCAocGlu
KSB7CiAgICAgICAgIGNhc2UgUFBDNDB4X0lOUFVUX1JFU0VUX1NZUzoKICAgICAgICAgICAgIGlm
IChsZXZlbCkgewpAQCAtMzMyLDExICszMzgsMTEgQEAgc3RhdGljIHZvaWQgcHBjNDB4X3NldF9p
cnEodm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwpCiAgICAgICAgICAgICAvKiBMZXZl
bCBzZW5zaXRpdmUgLSBhY3RpdmUgbG93ICovCiAgICAgICAgICAgICBpZiAobGV2ZWwpIHsKICAg
ICAgICAgICAgICAgICBMT0dfSVJRKCIlczogc3RvcCB0aGUgQ1BVXG4iLCBfX2Z1bmNfXyk7Ci0g
ICAgICAgICAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgICAgIGNzLT5oYWx0
ZWQgPSAxOwogICAgICAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgICAgICBMT0dfSVJRKCIl
czogcmVzdGFydCB0aGUgQ1BVXG4iLCBfX2Z1bmNfXyk7Ci0gICAgICAgICAgICAgICAgZW52LT5o
YWx0ZWQgPSAwOwotICAgICAgICAgICAgICAgIHFlbXVfY3B1X2tpY2soQ1BVKGNwdSkpOworICAg
ICAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAwOworICAgICAgICAgICAgICAgIHFlbXVfY3B1X2tp
Y2soY3MpOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2Ug
UFBDNDB4X0lOUFVUX0RFQlVHOgpkaWZmIC0tZ2l0IGEvaHcvcHBjL2U1MDAuYyBiL2h3L3BwYy9l
NTAwLmMKaW5kZXggNDUxNjgyYy4uZmVmOWM1ZCAxMDA2NDQKLS0tIGEvaHcvcHBjL2U1MDAuYwor
KysgYi9ody9wcGMvZTUwMC5jCkBAIC00MjAsMjYgKzQyMCwyOCBAQCBzdGF0aWMgdm9pZCBtbXVi
b29rZV9jcmVhdGVfaW5pdGlhbF9tYXBwaW5nKENQVVBQQ1N0YXRlICplbnYpCiBzdGF0aWMgdm9p
ZCBwcGNlNTAwX2NwdV9yZXNldF9zZWModm9pZCAqb3BhcXVlKQogewogICAgIFBvd2VyUENDUFUg
KmNwdSA9IG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVQUENT
dGF0ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgY3B1X3Jlc2V0KENQVShjcHUpKTsKKyAgICBj
cHVfcmVzZXQoY3MpOwogCiAgICAgLyogU2Vjb25kYXJ5IENQVSBzdGFydHMgaW4gaGFsdGVkIHN0
YXRlIGZvciBub3cuIE5lZWRzIHRvIGNoYW5nZSB3aGVuCiAgICAgICAgaW1wbGVtZW50aW5nIG5v
bi1rZXJuZWwgYm9vdC4gKi8KLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MtPmhhbHRlZCA9
IDE7CiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsKIH0KIAogc3RhdGljIHZv
aWQgcHBjZTUwMF9jcHVfcmVzZXQodm9pZCAqb3BhcXVlKQogewogICAgIFBvd2VyUENDUFUgKmNw
dSA9IG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVQUENTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogICAgIHN0cnVjdCBib290X2luZm8gKmJpID0gZW52LT5sb2Fk
X2luZm87CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNwdSkpOworICAgIGNwdV9yZXNldChjcyk7CiAK
ICAgICAvKiBTZXQgaW5pdGlhbCBndWVzdCBzdGF0ZS4gKi8KLSAgICBlbnYtPmhhbHRlZCA9IDA7
CisgICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgZW52LT5ncHJbMV0gPSAoMTY8PDIwKSAtIDg7CiAg
ICAgZW52LT5ncHJbM10gPSBiaS0+ZHRfYmFzZTsKICAgICBlbnYtPm5pcCA9IGJpLT5lbnRyeTsK
ZGlmZiAtLWdpdCBhL2h3L3BwY2U1MDBfc3Bpbi5jIGIvaHcvcHBjZTUwMF9zcGluLmMKaW5kZXgg
NWJkY2U1Mi4uMThjNWRiNCAxMDA2NDQKLS0tIGEvaHcvcHBjZTUwMF9zcGluLmMKKysrIGIvaHcv
cHBjZTUwMF9zcGluLmMKQEAgLTExMiw3ICsxMTIsNyBAQCBzdGF0aWMgdm9pZCBzcGluX2tpY2so
dm9pZCAqZGF0YSkKICAgICBtYXBfc3RhcnQgPSBsZHFfcCgmY3Vyc3Bpbi0+YWRkcikgJiB+KG1h
cF9zaXplIC0gMSk7CiAgICAgbW11Ym9va2VfY3JlYXRlX2luaXRpYWxfbWFwcGluZyhlbnYsIDAs
IG1hcF9zdGFydCwgbWFwX3NpemUpOwogCi0gICAgZW52LT5oYWx0ZWQgPSAwOworICAgIGNwdS0+
aGFsdGVkID0gMDsKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IC0xOwogICAgIGNwdS0+c3Rv
cHBlZCA9IGZhbHNlOwogICAgIHFlbXVfY3B1X2tpY2soY3B1KTsKZGlmZiAtLWdpdCBhL2h3L3B4
YTJ4eF9ncGlvLmMgYi9ody9weGEyeHhfZ3Bpby5jCmluZGV4IDA1ZDJhZDIuLmYwMGQxNTAgMTAw
NjQ0Ci0tLSBhL2h3L3B4YTJ4eF9ncGlvLmMKKysrIGIvaHcvcHhhMnh4X2dwaW8uYwpAQCAtOTMs
NiArOTMsNyBAQCBzdGF0aWMgY29uc3QgaW50IHB4YTJ4eF9ncGlvX3dha2VbUFhBMlhYX0dQSU9f
QkFOS1NdID0gewogc3RhdGljIHZvaWQgcHhhMnh4X2dwaW9fc2V0KHZvaWQgKm9wYXF1ZSwgaW50
IGxpbmUsIGludCBsZXZlbCkKIHsKICAgICBQWEEyeHhHUElPSW5mbyAqcyA9IChQWEEyeHhHUElP
SW5mbyAqKSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNwdSA9IENQVShzLT5jcHUpOwogICAgIGlu
dCBiYW5rOwogICAgIHVpbnQzMl90IG1hc2s7CiAKQEAgLTExOCw3ICsxMTksNyBAQCBzdGF0aWMg
dm9pZCBweGEyeHhfZ3Bpb19zZXQodm9pZCAqb3BhcXVlLCBpbnQgbGluZSwgaW50IGxldmVsKQog
ICAgICAgICBweGEyeHhfZ3Bpb19pcnFfdXBkYXRlKHMpOwogCiAgICAgLyogV2FrZS11cCBHUElP
cyAqLwotICAgIGlmIChzLT5jcHUtPmVudi5oYWx0ZWQgJiYgKG1hc2sgJiB+cy0+ZGlyW2Jhbmtd
ICYgcHhhMnh4X2dwaW9fd2FrZVtiYW5rXSkpIHsKKyAgICBpZiAoY3B1LT5oYWx0ZWQgJiYgKG1h
c2sgJiB+cy0+ZGlyW2JhbmtdICYgcHhhMnh4X2dwaW9fd2FrZVtiYW5rXSkpIHsKICAgICAgICAg
Y3B1X2ludGVycnVwdCgmcy0+Y3B1LT5lbnYsIENQVV9JTlRFUlJVUFRfRVhJVFRCKTsKICAgICB9
CiB9CmRpZmYgLS1naXQgYS9ody9weGEyeHhfcGljLmMgYi9ody9weGEyeHhfcGljLmMKaW5kZXgg
OTBiOGZlZi4uYzczZTcwOSAxMDA2NDQKLS0tIGEvaHcvcHhhMnh4X3BpYy5jCisrKyBiL2h3L3B4
YTJ4eF9waWMuYwpAQCAtNDYsOCArNDYsOSBAQCBzdGF0aWMgdm9pZCBweGEyeHhfcGljX3VwZGF0
ZSh2b2lkICpvcGFxdWUpCiB7CiAgICAgdWludDMyX3QgbWFza1syXTsKICAgICBQWEEyeHhQSUNT
dGF0ZSAqcyA9IChQWEEyeHhQSUNTdGF0ZSAqKSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNwdSA9
IENQVShzLT5jcHUpOwogCi0gICAgaWYgKHMtPmNwdS0+ZW52LmhhbHRlZCkgeworICAgIGlmIChj
cHUtPmhhbHRlZCkgewogICAgICAgICBtYXNrWzBdID0gcy0+aW50X3BlbmRpbmdbMF0gJiAocy0+
aW50X2VuYWJsZWRbMF0gfCBzLT5pbnRfaWRsZSk7CiAgICAgICAgIG1hc2tbMV0gPSBzLT5pbnRf
cGVuZGluZ1sxXSAmIChzLT5pbnRfZW5hYmxlZFsxXSB8IHMtPmludF9pZGxlKTsKICAgICAgICAg
aWYgKG1hc2tbMF0gfHwgbWFza1sxXSkgewpkaWZmIC0tZ2l0IGEvaHcvczM5MHgvczM5MC12aXJ0
aW8uYyBiL2h3L3MzOTB4L3MzOTAtdmlydGlvLmMKaW5kZXggZTI1YzMzMC4uY2EyNzViZCAxMDA2
NDQKLS0tIGEvaHcvczM5MHgvczM5MC12aXJ0aW8uYworKysgYi9ody9zMzkweC9zMzkwLXZpcnRp
by5jCkBAIC0xMzIsMjMgKzEzMiwyNSBAQCBzdGF0aWMgdW5zaWduZWQgczM5MF9ydW5uaW5nX2Nw
dXM7CiAKIHZvaWQgczM5MF9hZGRfcnVubmluZ19jcHUoUzM5MENQVSAqY3B1KQogeworICAgIENQ
VVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVMzOTBYU3RhdGUgKmVudiA9ICZjcHUtPmVu
djsKIAotICAgIGlmIChlbnYtPmhhbHRlZCkgeworICAgIGlmIChjcy0+aGFsdGVkKSB7CiAgICAg
ICAgIHMzOTBfcnVubmluZ19jcHVzKys7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICAg
ICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gLTE7CiAg
ICAgfQogfQogCiB1bnNpZ25lZCBzMzkwX2RlbF9ydW5uaW5nX2NwdShTMzkwQ1BVICpjcHUpCiB7
CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVUzM5MFhTdGF0ZSAqZW52ID0g
JmNwdS0+ZW52OwogCi0gICAgaWYgKGVudi0+aGFsdGVkID09IDApIHsKKyAgICBpZiAoY3MtPmhh
bHRlZCA9PSAwKSB7CiAgICAgICAgIGFzc2VydChzMzkwX3J1bm5pbmdfY3B1cyA+PSAxKTsKICAg
ICAgICAgczM5MF9ydW5uaW5nX2NwdXMtLTsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAg
ICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQ
X0hMVDsKICAgICB9CiAgICAgcmV0dXJuIHMzOTBfcnVubmluZ19jcHVzOwpAQCAtMTgzLDExICsx
ODUsMTMgQEAgdm9pZCBzMzkwX2luaXRfY3B1cyhjb25zdCBjaGFyICpjcHVfbW9kZWwsIHVpbnQ4
X3QgKnN0b3JhZ2Vfa2V5cykKIAogICAgIGZvciAoaSA9IDA7IGkgPCBzbXBfY3B1czsgaSsrKSB7
CiAgICAgICAgIFMzOTBDUFUgKmNwdTsKKyAgICAgICAgQ1BVU3RhdGUgKmNzOwogCiAgICAgICAg
IGNwdSA9IGNwdV9zMzkweF9pbml0KGNwdV9tb2RlbCk7CisgICAgICAgIGNzID0gQ1BVKGNwdSk7
CiAKICAgICAgICAgaXBpX3N0YXRlc1tpXSA9IGNwdTsKLSAgICAgICAgY3B1LT5lbnYuaGFsdGVk
ID0gMTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgIGNwdS0+ZW52LmV4Y2VwdGlv
bl9pbmRleCA9IEVYQ1BfSExUOwogICAgICAgICBjcHUtPmVudi5zdG9yYWdlX2tleXMgPSBzdG9y
YWdlX2tleXM7CiAgICAgfQpkaWZmIC0tZ2l0IGEvaHcvc3BhcHIuYyBiL2h3L3NwYXByLmMKaW5k
ZXggZTg4YTI3YS4uZGE1MTgxYyAxMDA2NDQKLS0tIGEvaHcvc3BhcHIuYworKysgYi9ody9zcGFw
ci5jCkBAIC02MTYsNiArNjE2LDggQEAgc3RhdGljIHZvaWQgc3BhcHJfcmVzZXRfaHRhYihzUEFQ
UkVudmlyb25tZW50ICpzcGFwcikKIAogc3RhdGljIHZvaWQgcHBjX3NwYXByX3Jlc2V0KHZvaWQp
CiB7CisgICAgQ1BVU3RhdGUgKmZpcnN0X2NwdV9jcHU7CisKICAgICAvKiBSZXNldCB0aGUgaGFz
aCB0YWJsZSAmIHJlY2FsYyB0aGUgUk1BICovCiAgICAgc3BhcHJfcmVzZXRfaHRhYihzcGFwcik7
CiAKQEAgLTYyNiw5ICs2MjgsMTAgQEAgc3RhdGljIHZvaWQgcHBjX3NwYXByX3Jlc2V0KHZvaWQp
CiAgICAgICAgICAgICAgICAgICAgICAgIHNwYXByLT5ydGFzX3NpemUpOwogCiAgICAgLyogU2V0
IHVwIHRoZSBlbnRyeSBzdGF0ZSAqLworICAgIGZpcnN0X2NwdV9jcHUgPSBDUFUoZmlyc3RfY3B1
KTsKICAgICBmaXJzdF9jcHUtPmdwclszXSA9IHNwYXByLT5mZHRfYWRkcjsKICAgICBmaXJzdF9j
cHUtPmdwcls1XSA9IDA7Ci0gICAgZmlyc3RfY3B1LT5oYWx0ZWQgPSAwOworICAgIGZpcnN0X2Nw
dV9jcHUtPmhhbHRlZCA9IDA7CiAgICAgZmlyc3RfY3B1LT5uaXAgPSBzcGFwci0+ZW50cnlfcG9p
bnQ7CiAKIH0KQEAgLTYzNiwxNCArNjM5LDE1IEBAIHN0YXRpYyB2b2lkIHBwY19zcGFwcl9yZXNl
dCh2b2lkKQogc3RhdGljIHZvaWQgc3BhcHJfY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAg
ICBQb3dlclBDQ1BVICpjcHUgPSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7
CiAgICAgQ1BVUFBDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKIAotICAgIGNwdV9yZXNldChDUFUo
Y3B1KSk7CisgICAgY3B1X3Jlc2V0KGNzKTsKIAogICAgIC8qIEFsbCBDUFVzIHN0YXJ0IGhhbHRl
ZC4gIENQVTAgaXMgdW5oYWx0ZWQgZnJvbSB0aGUgbWFjaGluZSBsZXZlbAogICAgICAqIHJlc2V0
IGNvZGUgYW5kIHRoZSByZXN0IGFyZSBleHBsaWNpdGx5IHN0YXJ0ZWQgdXAgYnkgdGhlIGd1ZXN0
CiAgICAgICogdXNpbmcgYW4gUlRBUyBjYWxsICovCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAg
IGNzLT5oYWx0ZWQgPSAxOwogCiAgICAgZW52LT5zcHJbU1BSX0hJT1JdID0gMDsKIApkaWZmIC0t
Z2l0IGEvaHcvc3BhcHJfaGNhbGwuYyBiL2h3L3NwYXByX2hjYWxsLmMKaW5kZXggN2I4OTU5NC4u
NTMxNTAxYiAxMDA2NDQKLS0tIGEvaHcvc3BhcHJfaGNhbGwuYworKysgYi9ody9zcGFwcl9oY2Fs
bC5jCkBAIC01MTMsNyArNTEzLDcgQEAgc3RhdGljIHRhcmdldF91bG9uZyBoX2NlZGUoUG93ZXJQ
Q0NQVSAqY3B1LCBzUEFQUkVudmlyb25tZW50ICpzcGFwciwKICAgICBlbnYtPm1zciB8PSAoMVVM
TCA8PCBNU1JfRUUpOwogICAgIGhyZWdfY29tcHV0ZV9oZmxhZ3MoZW52KTsKICAgICBpZiAoIWNw
dV9oYXNfd29yayhjcykpIHsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICBjcy0+
aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsKICAg
ICAgICAgY3MtPmV4aXRfcmVxdWVzdCA9IDE7CiAgICAgfQpkaWZmIC0tZ2l0IGEvaHcvc3BhcHJf
cnRhcy5jIGIvaHcvc3BhcHJfcnRhcy5jCmluZGV4IDVlYzc4N2YuLmEyNGU4NTMgMTAwNjQ0Ci0t
LSBhL2h3L3NwYXByX3J0YXMuYworKysgYi9ody9zcGFwcl9ydGFzLmMKQEAgLTE0NSw3ICsxNDUs
NyBAQCBzdGF0aWMgdm9pZCBydGFzX3F1ZXJ5X2NwdV9zdG9wcGVkX3N0YXRlKHNQQVBSRW52aXJv
bm1lbnQgKnNwYXByLAogICAgICAgICAgICAgY29udGludWU7CiAgICAgICAgIH0KIAotICAgICAg
ICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICAgICAgaWYgKGNwdS0+aGFsdGVkKSB7CiAgICAgICAg
ICAgICBydGFzX3N0KHJldHMsIDEsIDApOwogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAg
cnRhc19zdChyZXRzLCAxLCAyKTsKQEAgLTE4NCw3ICsxODQsNyBAQCBzdGF0aWMgdm9pZCBydGFz
X3N0YXJ0X2NwdShzUEFQUkVudmlyb25tZW50ICpzcGFwciwKICAgICAgICAgICAgIGNvbnRpbnVl
OwogICAgICAgICB9CiAKLSAgICAgICAgaWYgKCFlbnYtPmhhbHRlZCkgeworICAgICAgICBpZiAo
IWNwdS0+aGFsdGVkKSB7CiAgICAgICAgICAgICBydGFzX3N0KHJldHMsIDAsIC0xKTsKICAgICAg
ICAgICAgIHJldHVybjsKICAgICAgICAgfQpAQCAtMTk3LDcgKzE5Nyw3IEBAIHN0YXRpYyB2b2lk
IHJ0YXNfc3RhcnRfY3B1KHNQQVBSRW52aXJvbm1lbnQgKnNwYXByLAogICAgICAgICBlbnYtPm1z
ciA9ICgxVUxMIDw8IE1TUl9TRikgfCAoMVVMTCA8PCBNU1JfTUUpOwogICAgICAgICBlbnYtPm5p
cCA9IHN0YXJ0OwogICAgICAgICBlbnYtPmdwclszXSA9IHIzOwotICAgICAgICBlbnYtPmhhbHRl
ZCA9IDA7CisgICAgICAgIGNwdS0+aGFsdGVkID0gMDsKIAogICAgICAgICBxZW11X2NwdV9raWNr
KGNwdSk7CiAKZGlmZiAtLWdpdCBhL2h3L3N1bjRtLmMgYi9ody9zdW40bS5jCmluZGV4IDk5MDNm
NDQuLjQ1Zjk0NDEgMTAwNjQ0Ci0tLSBhL2h3L3N1bjRtLmMKKysrIGIvaHcvc3VuNG0uYwpAQCAt
MjU2LDEwICsyNTYsMTEgQEAgdm9pZCBjcHVfY2hlY2tfaXJxcyhDUFVTUEFSQ1N0YXRlICplbnYp
CiBzdGF0aWMgdm9pZCBjcHVfa2lja19pcnEoU1BBUkNDUFUgKmNwdSkKIHsKICAgICBDUFVTUEFS
Q1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAK
LSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgY3B1X2NoZWNr
X2lycXMoZW52KTsKLSAgICBxZW11X2NwdV9raWNrKENQVShjcHUpKTsKKyAgICBxZW11X2NwdV9r
aWNrKGNzKTsKIH0KIAogc3RhdGljIHZvaWQgY3B1X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQg
aXJxLCBpbnQgbGV2ZWwpCkBAIC0yODUsMTkgKzI4NiwxOSBAQCBzdGF0aWMgdm9pZCBkdW1teV9j
cHVfc2V0X2lycSh2b2lkICpvcGFxdWUsIGludCBpcnEsIGludCBsZXZlbCkKIHN0YXRpYyB2b2lk
IG1haW5fY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAgICBTUEFSQ0NQVSAqY3B1ID0gb3Bh
cXVlOwotICAgIENQVVNQQVJDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUoY3B1KTsKIAotICAgIGNwdV9yZXNldChDUFUoY3B1KSk7Ci0gICAgZW52LT5oYWx0
ZWQgPSAwOworICAgIGNwdV9yZXNldChjcyk7CisgICAgY3MtPmhhbHRlZCA9IDA7CiB9CiAKIHN0
YXRpYyB2b2lkIHNlY29uZGFyeV9jcHVfcmVzZXQodm9pZCAqb3BhcXVlKQogewogICAgIFNQQVJD
Q1BVICpjcHUgPSBvcGFxdWU7Ci0gICAgQ1BVU1BBUkNTdGF0ZSAqZW52ID0gJmNwdS0+ZW52Owor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogCi0gICAgY3B1X3Jlc2V0KENQVShjcHUpKTsK
LSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3B1X3Jlc2V0KGNzKTsKKyAgICBjcy0+aGFsdGVk
ID0gMTsKIH0KIAogc3RhdGljIHZvaWQgY3B1X2hhbHRfc2lnbmFsKHZvaWQgKm9wYXF1ZSwgaW50
IGlycSwgaW50IGxldmVsKQpAQCAtODI2LDYgKzgyNyw3IEBAIHN0YXRpYyBjb25zdCBUeXBlSW5m
byByYW1faW5mbyA9IHsKIHN0YXRpYyB2b2lkIGNwdV9kZXZpbml0KGNvbnN0IGNoYXIgKmNwdV9t
b2RlbCwgdW5zaWduZWQgaW50IGlkLAogICAgICAgICAgICAgICAgICAgICAgICAgdWludDY0X3Qg
cHJvbV9hZGRyLCBxZW11X2lycSAqKmNwdV9pcnFzKQogeworICAgIENQVVN0YXRlICpjczsKICAg
ICBTUEFSQ0NQVSAqY3B1OwogICAgIENQVVNQQVJDU3RhdGUgKmVudjsKIApAQCAtODQxLDcgKzg0
Myw4IEBAIHN0YXRpYyB2b2lkIGNwdV9kZXZpbml0KGNvbnN0IGNoYXIgKmNwdV9tb2RlbCwgdW5z
aWduZWQgaW50IGlkLAogICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0KG1haW5fY3B1X3Jlc2V0
LCBjcHUpOwogICAgIH0gZWxzZSB7CiAgICAgICAgIHFlbXVfcmVnaXN0ZXJfcmVzZXQoc2Vjb25k
YXJ5X2NwdV9yZXNldCwgY3B1KTsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICBj
cyA9IENQVShjcHUpOworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICB9CiAgICAgKmNwdV9p
cnFzID0gcWVtdV9hbGxvY2F0ZV9pcnFzKGNwdV9zZXRfaXJxLCBjcHUsIE1BWF9QSUxTKTsKICAg
ICBlbnYtPnByb21fYWRkciA9IHByb21fYWRkcjsKZGlmZiAtLWdpdCBhL2h3L3N1bjR1LmMgYi9o
dy9zdW40dS5jCmluZGV4IDlmYmRhMjkuLjA1NmJiNGQgMTAwNjQ0Ci0tLSBhL2h3L3N1bjR1LmMK
KysrIGIvaHcvc3VuNHUuYwpAQCAtMjU0LDYgKzI1NCw3IEBAIHN0YXRpYyB1aW50NjRfdCBzdW40
dV9sb2FkX2tlcm5lbChjb25zdCBjaGFyICprZXJuZWxfZmlsZW5hbWUsCiAKIHZvaWQgY3B1X2No
ZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogeworICAgIENQVVN0YXRlICpjczsKICAgICB1
aW50MzJfdCBwaWwgPSBlbnYtPnBpbF9pbiB8CiAgICAgICAgICAgICAgICAgICAoZW52LT5zb2Z0
aW50ICYgfihTT0ZUSU5UX1RJTUVSIHwgU09GVElOVF9TVElNRVIpKTsKIApAQCAtMjYxLDYgKzI2
Miw3IEBAIHZvaWQgY3B1X2NoZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogICAgIGlmIChl
bnYtPml2ZWNfc3RhdHVzICYgMHgyMCkgewogICAgICAgICByZXR1cm47CiAgICAgfQorICAgIGNz
ID0gQ1BVKHNwYXJjX2Vudl9nZXRfY3B1KGVudikpOwogICAgIC8qIGNoZWNrIGlmIFRNIG9yIFNN
IGluIFNPRlRJTlQgYXJlIHNldAogICAgICAgIHNldHRpbmcgdGhlc2UgYWxzbyBjYXVzZXMgaW50
ZXJydXB0IDE0ICovCiAgICAgaWYgKGVudi0+c29mdGludCAmIChTT0ZUSU5UX1RJTUVSIHwgU09G
VElOVF9TVElNRVIpKSB7CkBAIC0yNzAsNyArMjcyLDcgQEAgdm9pZCBjcHVfY2hlY2tfaXJxcyhD
UFVTUEFSQ1N0YXRlICplbnYpCiAgICAgLyogVGhlIGJpdCBjb3JyZXNwb25kaW5nIHRvIHBzcnBp
bCBpcyAoMTw8IHBzcnBpbCksIHRoZSBuZXh0IGJpdAogICAgICAgIGlzICgyIDw8IHBzcnBpbCku
ICovCiAgICAgaWYgKHBpbCA8ICgyIDw8IGVudi0+cHNycGlsKSl7Ci0gICAgICAgIGlmIChlbnYt
PmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSB7CisgICAgICAgIGlmIChj
cy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKICAgICAgICAgICAg
IENQVUlSUV9EUFJJTlRGKCJSZXNldCBDUFUgSVJRIChjdXJyZW50IGludGVycnVwdCAleClcbiIs
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9pbmRleCk7CiAgICAg
ICAgICAgICBlbnYtPmludGVycnVwdF9pbmRleCA9IDA7CkBAIC0zMDIsNyArMzA0LDcgQEAgdm9p
ZCBjcHVfY2hlY2tfaXJxcyhDUFVTUEFSQ1N0YXRlICplbnYpCiAgICAgICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgICAgICB9CiAgICAgICAgIH0KLSAgICB9IGVsc2UgaWYgKGVudi0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKKyAgICB9IGVsc2UgaWYgKGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgewogICAgICAgICBDUFVJUlFf
RFBSSU5URigiSW50ZXJydXB0cyBkaXNhYmxlZCwgcGlsPSUwOHggcGlsX2luPSUwOHggc29mdGlu
dD0lMDh4ICIKICAgICAgICAgICAgICAgICAgICAgICAgImN1cnJlbnQgaW50ZXJydXB0ICV4XG4i
LAogICAgICAgICAgICAgICAgICAgICAgICBwaWwsIGVudi0+cGlsX2luLCBlbnYtPnNvZnRpbnQs
IGVudi0+aW50ZXJydXB0X2luZGV4KTsKQEAgLTMxMywyMiArMzE1LDI1IEBAIHZvaWQgY3B1X2No
ZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogCiBzdGF0aWMgdm9pZCBjcHVfa2lja19pcnEo
U1BBUkNDUFUgKmNwdSkKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVT
UEFSQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CiAKLSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAg
Y3MtPmhhbHRlZCA9IDA7CiAgICAgY3B1X2NoZWNrX2lycXMoZW52KTsKLSAgICBxZW11X2NwdV9r
aWNrKENQVShjcHUpKTsKKyAgICBxZW11X2NwdV9raWNrKGNzKTsKIH0KIAogc3RhdGljIHZvaWQg
Y3B1X3NldF9pdmVjX2lycSh2b2lkICpvcGFxdWUsIGludCBpcnEsIGludCBsZXZlbCkKIHsKICAg
ICBTUEFSQ0NQVSAqY3B1ID0gb3BhcXVlOwogICAgIENQVVNQQVJDU3RhdGUgKmVudiA9ICZjcHUt
PmVudjsKKyAgICBDUFVTdGF0ZSAqY3M7CiAKICAgICBpZiAobGV2ZWwpIHsKICAgICAgICAgaWYg
KCEoZW52LT5pdmVjX3N0YXR1cyAmIDB4MjApKSB7CiAgICAgICAgICAgICBDUFVJUlFfRFBSSU5U
RigiUmFpc2UgSVZFQyBJUlEgJWRcbiIsIGlycSk7Ci0gICAgICAgICAgICBlbnYtPmhhbHRlZCA9
IDA7CisgICAgICAgICAgICBjcyA9IENQVShjcHUpOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9
IDA7CiAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9pbmRleCA9IFRUX0lWRUM7CiAgICAgICAg
ICAgICBlbnYtPml2ZWNfc3RhdHVzIHw9IDB4MjA7CiAgICAgICAgICAgICBlbnYtPml2ZWNfZGF0
YVswXSA9ICgweDFmIDw8IDYpIHwgaXJxOwpkaWZmIC0tZ2l0IGEvaHcveGVuX21hY2hpbmVfcHYu
YyBiL2h3L3hlbl9tYWNoaW5lX3B2LmMKaW5kZXggNjZlODk4MS4uNGZlYzRmYyAxMDA2NDQKLS0t
IGEvaHcveGVuX21hY2hpbmVfcHYuYworKysgYi9ody94ZW5fbWFjaGluZV9wdi5jCkBAIC0zNiw3
ICszNiw3IEBAIHN0YXRpYyB2b2lkIHhlbl9pbml0X3B2KFFFTVVNYWNoaW5lSW5pdEFyZ3MgKmFy
Z3MpCiAgICAgY29uc3QgY2hhciAqa2VybmVsX2NtZGxpbmUgPSBhcmdzLT5rZXJuZWxfY21kbGlu
ZTsKICAgICBjb25zdCBjaGFyICppbml0cmRfZmlsZW5hbWUgPSBhcmdzLT5pbml0cmRfZmlsZW5h
bWU7CiAgICAgWDg2Q1BVICpjcHU7Ci0gICAgQ1BVWDg2U3RhdGUgKmVudjsKKyAgICBDUFVTdGF0
ZSAqY3M7CiAgICAgRHJpdmVJbmZvICpkaW5mbzsKICAgICBpbnQgaTsKIApAQCAtNDksOCArNDks
OCBAQCBzdGF0aWMgdm9pZCB4ZW5faW5pdF9wdihRRU1VTWFjaGluZUluaXRBcmdzICphcmdzKQog
I2VuZGlmCiAgICAgfQogICAgIGNwdSA9IGNwdV94ODZfaW5pdChjcHVfbW9kZWwpOwotICAgIGVu
diA9ICZjcHUtPmVudjsKLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MgPSBDUFUoY3B1KTsK
KyAgICBjcy0+aGFsdGVkID0gMTsKIAogICAgIC8qIEluaXRpYWxpemUgYmFja2VuZCBjb3JlICYg
ZHJpdmVycyAqLwogICAgIGlmICh4ZW5fYmVfaW5pdCgpICE9IDApIHsKZGlmZiAtLWdpdCBhL2h3
L3h0ZW5zYV9waWMuYyBiL2h3L3h0ZW5zYV9waWMuYwppbmRleCA5N2QzNmJlLi5kY2ExNWI0IDEw
MDY0NAotLS0gYS9ody94dGVuc2FfcGljLmMKKysrIGIvaHcveHRlbnNhX3BpYy5jCkBAIC00Nyw2
ICs0Nyw3IEBAIHZvaWQgeHRlbnNhX2FkdmFuY2VfY2NvdW50KENQVVh0ZW5zYVN0YXRlICplbnYs
IHVpbnQzMl90IGQpCiAKIHZvaWQgY2hlY2tfaW50ZXJydXB0cyhDUFVYdGVuc2FTdGF0ZSAqZW52
KQogeworICAgIENQVVN0YXRlICpjcyA9IENQVSh4dGVuc2FfZW52X2dldF9jcHUoZW52KSk7CiAg
ICAgaW50IG1pbmxldmVsID0geHRlbnNhX2dldF9jaW50bGV2ZWwoZW52KTsKICAgICB1aW50MzJf
dCBpbnRfc2V0X2VuYWJsZWQgPSBlbnYtPnNyZWdzW0lOVFNFVF0gJiBlbnYtPnNyZWdzW0lOVEVO
QUJMRV07CiAgICAgaW50IGxldmVsOwpAQCAtNTQsNyArNTUsNyBAQCB2b2lkIGNoZWNrX2ludGVy
cnVwdHMoQ1BVWHRlbnNhU3RhdGUgKmVudikKICAgICAvKiBJZiB0aGUgQ1BVIGlzIGhhbHRlZCBh
ZHZhbmNlIENDT1VOVCBhY2NvcmRpbmcgdG8gdGhlIHZtX2Nsb2NrIHRpbWUKICAgICAgKiBlbGFw
c2VkIHNpbmNlIHRoZSBtb21lbnQgd2hlbiBpdCB3YXMgYWR2YW5jZWQgbGFzdCB0aW1lLgogICAg
ICAqLwotICAgIGlmIChlbnYtPmhhbHRlZCkgeworICAgIGlmIChjcy0+aGFsdGVkKSB7CiAgICAg
ICAgIGludDY0X3Qgbm93ID0gcWVtdV9nZXRfY2xvY2tfbnModm1fY2xvY2spOwogCiAgICAgICAg
IHh0ZW5zYV9hZHZhbmNlX2Njb3VudChlbnYsCkBAIC0xMjcsMTEgKzEyOCwxMiBAQCBzdGF0aWMg
dm9pZCB4dGVuc2FfY2NvbXBhcmVfY2Iodm9pZCAqb3BhcXVlKQogewogICAgIFh0ZW5zYUNQVSAq
Y3B1ID0gb3BhcXVlOwogICAgIENQVVh0ZW5zYVN0YXRlICplbnYgPSAmY3B1LT5lbnY7CisgICAg
Q1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAKLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBp
ZiAoY3MtPmhhbHRlZCkgewogICAgICAgICBlbnYtPmhhbHRfY2xvY2sgPSBxZW11X2dldF9jbG9j
a19ucyh2bV9jbG9jayk7CiAgICAgICAgIHh0ZW5zYV9hZHZhbmNlX2Njb3VudChlbnYsIGVudi0+
d2FrZV9jY291bnQgLSBlbnYtPnNyZWdzW0NDT1VOVF0pOwotICAgICAgICBpZiAoIWNwdV9oYXNf
d29yayhDUFUoY3B1KSkpIHsKKyAgICAgICAgaWYgKCFjcHVfaGFzX3dvcmsoY3MpKSB7CiAgICAg
ICAgICAgICBlbnYtPnNyZWdzW0NDT1VOVF0gPSBlbnYtPndha2VfY2NvdW50ICsgMTsKICAgICAg
ICAgICAgIHh0ZW5zYV9yZWFybV9jY29tcGFyZV90aW1lcihlbnYpOwogICAgICAgICB9CmRpZmYg
LS1naXQgYS9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMuaCBiL2luY2x1ZGUvZXhlYy9jcHUtZGVmcy5o
CmluZGV4IDNkYzk2NTYuLjBhZTk2N2EgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvZXhlYy9jcHUtZGVm
cy5oCisrKyBiL2luY2x1ZGUvZXhlYy9jcHUtZGVmcy5oCkBAIC0xNTYsOCArMTU2LDYgQEAgdHlw
ZWRlZiBzdHJ1Y3QgQ1BVV2F0Y2hwb2ludCB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YWNjZXNzZWQgKi8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgdGFyZ2V0
X3Vsb25nIG1lbV9pb192YWRkcjsgLyogdGFyZ2V0IHZpcnR1YWwgYWRkciBhdCB3aGljaCB0aGUg
ICAgICBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWVtb3J5IHdhcyBh
Y2Nlc3NlZCAqLyAgICAgICAgICAgICBcCi0gICAgdWludDMyX3QgaGFsdGVkOyAvKiBOb256ZXJv
IGlmIHRoZSBDUFUgaXMgaW4gc3VzcGVuZCBzdGF0ZSAqLyAgICAgICBcCi0gICAgdWludDMyX3Qg
aW50ZXJydXB0X3JlcXVlc3Q7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgQ1BVX0NPTU1PTl9UTEIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgc3RydWN0IFRyYW5zbGF0aW9uQmxvY2sgKnRiX2pt
cF9jYWNoZVtUQl9KTVBfQ0FDSEVfU0laRV07ICAgICAgICAgICBcCiAgICAgLyogYnVmZmVyIGZv
ciB0ZW1wb3JhcmllcyBpbiB0aGUgY29kZSBnZW5lcmF0b3IgKi8gICAgICAgICAgICAgICAgICBc
CmRpZmYgLS1naXQgYS9pbmNsdWRlL3FvbS9jcHUuaCBiL2luY2x1ZGUvcW9tL2NwdS5oCmluZGV4
IDY1ZTI0ZDMuLjMyNTgxZmEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvcW9tL2NwdS5oCisrKyBiL2lu
Y2x1ZGUvcW9tL2NwdS5oCkBAIC03Miw2ICs3Miw4IEBAIHN0cnVjdCBrdm1fcnVuOwogICogQGhv
c3RfdGlkOiBIb3N0IHRocmVhZCBJRC4KICAqIEBydW5uaW5nOiAjdHJ1ZSBpZiBDUFUgaXMgY3Vy
cmVudGx5IHJ1bm5pbmcgKHVzZXJtb2RlKS4KICAqIEBjcmVhdGVkOiBJbmRpY2F0ZXMgd2hldGhl
ciB0aGUgQ1BVIHRocmVhZCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgY3JlYXRlZC4KKyAqIEBpbnRl
cnJ1cHRfcmVxdWVzdDogSW5kaWNhdGVzIGEgcGVuZGluZyBpbnRlcnJ1cHQgcmVxdWVzdC4KKyAq
IEBoYWx0ZWQ6IE5vbnplcm8gaWYgdGhlIENQVSBpcyBpbiBzdXNwZW5kZWQgc3RhdGUuCiAgKiBA
c3RvcDogSW5kaWNhdGVzIGEgcGVuZGluZyBzdG9wIHJlcXVlc3QuCiAgKiBAc3RvcHBlZDogSW5k
aWNhdGVzIHRoZSBDUFUgaGFzIGJlZW4gYXJ0aWZpY2lhbGx5IHN0b3BwZWQuCiAgKiBAZW52X3B0
cjogUG9pbnRlciB0byBzdWJjbGFzcy1zcGVjaWZpYyBDUFVBcmNoU3RhdGUgZmllbGQuCkBAIC0x
MDMsNiArMTA1LDcgQEAgc3RydWN0IENQVVN0YXRlIHsKICAgICBib29sIHN0b3A7CiAgICAgYm9v
bCBzdG9wcGVkOwogICAgIHZvbGF0aWxlIHNpZ19hdG9taWNfdCBleGl0X3JlcXVlc3Q7CisgICAg
dWludDMyX3QgaW50ZXJydXB0X3JlcXVlc3Q7CiAKICAgICB2b2lkICplbnZfcHRyOyAvKiBDUFVB
cmNoU3RhdGUgKi8KICAgICBzdHJ1Y3QgVHJhbnNsYXRpb25CbG9jayAqY3VycmVudF90YjsKQEAg
LTExNCw2ICsxMTcsNyBAQCBzdHJ1Y3QgQ1BVU3RhdGUgewogCiAgICAgLyogVE9ETyBNb3ZlIGNv
bW1vbiBmaWVsZHMgZnJvbSBDUFVBcmNoU3RhdGUgaGVyZS4gKi8KICAgICBpbnQgY3B1X2luZGV4
OyAvKiB1c2VkIGJ5IGFscGhhIFRDRyAqLworICAgIHVpbnQzMl90IGhhbHRlZDsgLyogdXNlZCBi
eSBhbHBoYSwgY3JpcywgcHBjIFRDRyAqLwogfTsKIAogCmRpZmYgLS1naXQgYS9rdm0tYWxsLmMg
Yi9rdm0tYWxsLmMKaW5kZXggNGRlY2ZkYy4uMmI3NjFlMCAxMDA2NDQKLS0tIGEva3ZtLWFsbC5j
CisrKyBiL2t2bS1hbGwuYwpAQCAtODMwLDcgKzgzMCw3IEBAIHN0YXRpYyB2b2lkIGt2bV9oYW5k
bGVfaW50ZXJydXB0KENQVUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKIHsKICAgICBDUFVTdGF0
ZSAqY3B1ID0gRU5WX0dFVF9DUFUoZW52KTsKIAotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3Qg
fD0gbWFzazsKKyAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0IHw9IG1hc2s7CiAKICAgICBpZiAo
IXFlbXVfY3B1X2lzX3NlbGYoY3B1KSkgewogICAgICAgICBxZW11X2NwdV9raWNrKGNwdSk7CmRp
ZmYgLS1naXQgYS9xb20vY3B1LmMgYi9xb20vY3B1LmMKaW5kZXggMGEyMTk0ZC4uMGFhOWJlNyAx
MDA2NDQKLS0tIGEvcW9tL2NwdS5jCisrKyBiL3FvbS9jcHUuYwpAQCAtMzMsNyArMzMsOSBAQCB2
b2lkIGNwdV9yZXNldChDUFVTdGF0ZSAqY3B1KQogc3RhdGljIHZvaWQgY3B1X2NvbW1vbl9yZXNl
dChDUFVTdGF0ZSAqY3B1KQogewogICAgIGNwdS0+ZXhpdF9yZXF1ZXN0ID0gMDsKKyAgICBjcHUt
PmludGVycnVwdF9yZXF1ZXN0ID0gMDsKICAgICBjcHUtPmN1cnJlbnRfdGIgPSBOVUxMOworICAg
IGNwdS0+aGFsdGVkID0gMDsKIH0KIAogT2JqZWN0Q2xhc3MgKmNwdV9jbGFzc19ieV9uYW1lKGNv
bnN0IGNoYXIgKnR5cGVuYW1lLCBjb25zdCBjaGFyICpjcHVfbW9kZWwpCmRpZmYgLS1naXQgYS90
YXJnZXQtYWxwaGEvY3B1LmggYi90YXJnZXQtYWxwaGEvY3B1LmgKaW5kZXggZjFkYjY1MS4uOTBm
NzhhYyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWFscGhhL2NwdS5oCisrKyBiL3RhcmdldC1hbHBoYS9j
cHUuaApAQCAtNTE3LDggKzUxNyw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBjcHVfc2V0X3RscyhD
UFVBbHBoYVN0YXRlICplbnYsIHRhcmdldF91bG9uZyBuZXd0bHMpCiAKIHN0YXRpYyBpbmxpbmUg
Ym9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVBbHBoYVN0YXRlICpl
bnYgPSAmQUxQSEFfQ1BVKGNwdSktPmVudjsKLQogICAgIC8qIEhlcmUgd2UgYXJlIGNoZWNraW5n
IHRvIHNlZSBpZiB0aGUgQ1BVIHNob3VsZCB3YWtlIHVwIGZyb20gSEFMVC4KICAgICAgICBXZSB3
aWxsIGhhdmUgZ290dGVuIGludG8gdGhpcyBzdGF0ZSBvbmx5IGZvciBXVElOVCBmcm9tIFBBTG1v
ZGUuICAqLwogICAgIC8qID8/PyBJJ20gbm90IHN1cmUgaG93IHRoZSBJUEwgc3RhdGUgd29ya3Mg
d2l0aCBXVElOVCB0byBrZWVwIGEgQ1BVCkBAIC01MjYsNyArNTI0LDcgQEAgc3RhdGljIGlubGlu
ZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQogICAgICAgIGFzc3VtZSB0aGF0IGlm
IGEgQ1BVIHJlYWxseSB3YW50cyB0byBzdGF5IGFzbGVlcCwgaXQgd2lsbCBtYXNrCiAgICAgICAg
aW50ZXJydXB0cyBhdCB0aGUgY2hpcHNldCBsZXZlbCwgd2hpY2ggd2lsbCBwcmV2ZW50IHRoZXNl
IGJpdHMKICAgICAgICBmcm9tIGJlaW5nIHNldCBpbiB0aGUgZmlyc3QgcGxhY2UuICAqLwotICAg
IHJldHVybiBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRAorICAg
IHJldHVybiBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ1BVX0lOVEVSUlVQVF9USU1FUgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ1BVX0lOVEVSUlVQVF9TTVAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENQVV9JTlRFUlJVUFRfTUNI
Syk7CmRpZmYgLS1naXQgYS90YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMgYi90YXJnZXQtYWxwaGEv
dHJhbnNsYXRlLmMKaW5kZXggZjhmNzY5NS4uOTVhZTg4YSAxMDA2NDQKLS0tIGEvdGFyZ2V0LWFs
cGhhL3RyYW5zbGF0ZS5jCisrKyBiL3RhcmdldC1hbHBoYS90cmFuc2xhdGUuYwpAQCAtMTY4Niw3
ICsxNjg2LDggQEAgc3RhdGljIEV4aXRTdGF0dXMgZ2VuX210cHIoRGlzYXNDb250ZXh0ICpjdHgs
IGludCByYiwgaW50IHJlZ25vKQogICAgIGNhc2UgMjUzOgogICAgICAgICAvKiBXQUlUICovCiAg
ICAgICAgIHRtcCA9IHRjZ19jb25zdF9pNjQoMSk7Ci0gICAgICAgIHRjZ19nZW5fc3QzMl9pNjQo
dG1wLCBjcHVfZW52LCBvZmZzZXRvZihDUFVBbHBoYVN0YXRlLCBoYWx0ZWQpKTsKKyAgICAgICAg
dGNnX2dlbl9zdDMyX2k2NCh0bXAsIGNwdV9lbnYsIC1vZmZzZXRvZihBbHBoYUNQVSwgZW52KSAr
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZmZzZXRvZihDUFVTdGF0
ZSwgaGFsdGVkKSk7CiAgICAgICAgIHJldHVybiBnZW5fZXhjcChjdHgsIEVYQ1BfSExULCAwKTsK
IAogICAgIGNhc2UgMjUyOgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWFybS9jcHUuaCBiL3RhcmdldC1h
cm0vY3B1LmgKaW5kZXggMjkwMmJhNS4uN2M0NzQ2NyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWFybS9j
cHUuaAorKysgYi90YXJnZXQtYXJtL2NwdS5oCkBAIC03MjEsOSArNzIxLDcgQEAgc3RhdGljIGlu
bGluZSB2b2lkIGNwdV9nZXRfdGJfY3B1X3N0YXRlKENQVUFSTVN0YXRlICplbnYsIHRhcmdldF91
bG9uZyAqcGMsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNw
dSkKIHsKLSAgICBDUFVBUk1TdGF0ZSAqZW52ID0gJkFSTV9DUFUoY3B1KS0+ZW52OwotCi0gICAg
cmV0dXJuIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJgorICAgIHJldHVybiBjcHUtPmludGVycnVw
dF9yZXF1ZXN0ICYKICAgICAgICAgKENQVV9JTlRFUlJVUFRfRklRIHwgQ1BVX0lOVEVSUlVQVF9I
QVJEIHwgQ1BVX0lOVEVSUlVQVF9FWElUVEIpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtYXJt
L2hlbHBlci5jIGIvdGFyZ2V0LWFybS9oZWxwZXIuYwppbmRleCBlOTdlMWE1Li42NTUwOTNkIDEw
MDY0NAotLS0gYS90YXJnZXQtYXJtL2hlbHBlci5jCisrKyBiL3RhcmdldC1hcm0vaGVscGVyLmMK
QEAgLTE4MDIsNiArMTgwMiw3IEBAIHN0YXRpYyB2b2lkIGRvX2ludGVycnVwdF92N20oQ1BVQVJN
U3RhdGUgKmVudikKIC8qIEhhbmRsZSBhIENQVSBleGNlcHRpb24uICAqLwogdm9pZCBkb19pbnRl
cnJ1cHQoQ1BVQVJNU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAgdWludDMy
X3QgYWRkcjsKICAgICB1aW50MzJfdCBtYXNrOwogICAgIGludCBuZXdfbW9kZTsKQEAgLTE5MDgs
NyArMTkwOSw4IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVUFSTVN0YXRlICplbnYpCiAgICAgfQog
ICAgIGVudi0+cmVnc1sxNF0gPSBlbnYtPnJlZ3NbMTVdICsgb2Zmc2V0OwogICAgIGVudi0+cmVn
c1sxNV0gPSBhZGRyOwotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQ
VF9FWElUVEI7CisgICAgY3MgPSBDUFUoYXJtX2Vudl9nZXRfY3B1KGVudikpOworICAgIGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKIH0KIAogLyogQ2hlY2sg
c2VjdGlvbi9wYWdlIGFjY2VzcyBwZXJtaXNzaW9ucy4KZGlmZiAtLWdpdCBhL3RhcmdldC1hcm0v
b3BfaGVscGVyLmMgYi90YXJnZXQtYXJtL29wX2hlbHBlci5jCmluZGV4IGE1MjIzMTMuLmE5MThl
NWIgMTAwNjQ0Ci0tLSBhL3RhcmdldC1hcm0vb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LWFybS9v
cF9oZWxwZXIuYwpAQCAtMjE4LDggKzIxOCwxMCBAQCB1aW50MzJfdCBIRUxQRVIodXNhdDE2KShD
UFVBUk1TdGF0ZSAqZW52LCB1aW50MzJfdCB4LCB1aW50MzJfdCBzaGlmdCkKIAogdm9pZCBIRUxQ
RVIod2ZpKShDUFVBUk1TdGF0ZSAqZW52KQogeworICAgIENQVVN0YXRlICpjcyA9IENQVShhcm1f
ZW52X2dldF9jcHUoZW52KSk7CisKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExU
OwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcy0+aGFsdGVkID0gMTsKICAgICBjcHVfbG9v
cF9leGl0KGVudik7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC1jcmlzL2NwdS5oIGIvdGFyZ2V0
LWNyaXMvY3B1LmgKaW5kZXggZWJmMmQ0MC4uMmZjN2M1YyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWNy
aXMvY3B1LmgKKysrIGIvdGFyZ2V0LWNyaXMvY3B1LmgKQEAgLTI4OSw5ICsyODksNyBAQCB2b2lk
IGNyaXNfY3B1X2xpc3QoRklMRSAqZiwgZnByaW50Zl9mdW5jdGlvbiBjcHVfZnByaW50Zik7CiAK
IHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBD
UFVDUklTU3RhdGUgKmVudiA9ICZDUklTX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfCBDUFVfSU5URVJSVVBU
X05NSSk7CisgICAgcmV0dXJuIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQ
VF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9OTUkpOwogfQogCiAjaW5jbHVkZSAiZXhlYy9leGVjLWFs
bC5oIgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWNyaXMvaGVscGVyLmMgYi90YXJnZXQtY3Jpcy9oZWxw
ZXIuYwppbmRleCBkZTA0MTQzLi44ODVmNjdmIDEwMDY0NAotLS0gYS90YXJnZXQtY3Jpcy9oZWxw
ZXIuYworKysgYi90YXJnZXQtY3Jpcy9oZWxwZXIuYwpAQCAtNjYsNiArNjYsNyBAQCBzdGF0aWMg
dm9pZCBjcmlzX3NoaWZ0X2NjcyhDUFVDUklTU3RhdGUgKmVudikKIGludCBjcHVfY3Jpc19oYW5k
bGVfbW11X2ZhdWx0KENQVUNSSVNTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgYWRkcmVzcywgaW50
IHJ3LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IG1tdV9pZHgpCiB7CisgICAg
RChDUFVTdGF0ZSAqY3B1ID0gQ1BVKGNyaXNfZW52X2dldF9jcHUoZW52KSkpOwogICAgIHN0cnVj
dCBjcmlzX21tdV9yZXN1bHQgcmVzOwogICAgIGludCBwcm90LCBtaXNzOwogICAgIGludCByID0g
LTE7CkBAIC05OSw3ICsxMDAsNyBAQCBpbnQgY3B1X2NyaXNfaGFuZGxlX21tdV9mYXVsdChDUFVD
UklTU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIGFkZHJlc3MsIGludCBydywKICAgICB9CiAgICAg
aWYgKHIgPiAwKSB7CiAgICAgICAgIERfTE9HKCIlcyByZXR1cm5zICVkIGlycXJlcT0leCBhZGRy
PSV4IHBoeT0leCB2ZWM9JXggcGM9JXhcbiIsCi0gICAgICAgICAgICAgIF9fZnVuY19fLCByLCBl
bnYtPmludGVycnVwdF9yZXF1ZXN0LCBhZGRyZXNzLCByZXMucGh5LAorICAgICAgICAgICAgICBf
X2Z1bmNfXywgciwgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCwgYWRkcmVzcywgcmVzLnBoeSwKICAg
ICAgICAgICAgICAgcmVzLmJmX3ZlYywgZW52LT5wYyk7CiAgICAgfQogICAgIHJldHVybiByOwpA
QCAtMTA3LDExICsxMDgsMTIgQEAgaW50IGNwdV9jcmlzX2hhbmRsZV9tbXVfZmF1bHQoQ1BVQ1JJ
U1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBhZGRyZXNzLCBpbnQgcncsCiAKIHN0YXRpYyB2b2lk
IGRvX2ludGVycnVwdHYxMChDUFVDUklTU3RhdGUgKmVudikKIHsKKyAgICBEKENQVVN0YXRlICpj
cyA9IENQVShjcmlzX2Vudl9nZXRfY3B1KGVudikpKTsKICAgICBpbnQgZXhfdmVjID0gLTE7CiAK
ICAgICBEX0xPRygiZXhjZXB0aW9uIGluZGV4PSVkIGludGVycnVwdF9yZXE9JWRcbiIsCiAgICAg
ICAgICAgZW52LT5leGNlcHRpb25faW5kZXgsCi0gICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdCk7CisgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0KTsKIAogICAgIGFzc2VydCgh
KGVudi0+cHJlZ3NbUFJfQ0NTXSAmIFBGSVhfRkxBRykpOwogICAgIHN3aXRjaCAoZW52LT5leGNl
cHRpb25faW5kZXgpIHsKQEAgLTE2Miw2ICsxNjQsNyBAQCBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1
cHR2MTAoQ1BVQ1JJU1N0YXRlICplbnYpCiAKIHZvaWQgZG9faW50ZXJydXB0KENQVUNSSVNTdGF0
ZSAqZW52KQogeworICAgIEQoQ1BVU3RhdGUgKmNzID0gQ1BVKGNyaXNfZW52X2dldF9jcHUoZW52
KSkpOwogICAgIGludCBleF92ZWMgPSAtMTsKIAogICAgIGlmIChlbnYtPnByZWdzW1BSX1ZSXSA8
IDMyKSB7CkBAIC0xNzAsNyArMTczLDcgQEAgdm9pZCBkb19pbnRlcnJ1cHQoQ1BVQ1JJU1N0YXRl
ICplbnYpCiAKICAgICBEX0xPRygiZXhjZXB0aW9uIGluZGV4PSVkIGludGVycnVwdF9yZXE9JWRc
biIsCiAgICAgICAgICAgZW52LT5leGNlcHRpb25faW5kZXgsCi0gICAgICAgICAgZW52LT5pbnRl
cnJ1cHRfcmVxdWVzdCk7CisgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0KTsKIAogICAg
IHN3aXRjaCAoZW52LT5leGNlcHRpb25faW5kZXgpIHsKICAgICBjYXNlIEVYQ1BfQlJFQUs6CmRp
ZmYgLS1naXQgYS90YXJnZXQtY3Jpcy90cmFuc2xhdGUuYyBiL3RhcmdldC1jcmlzL3RyYW5zbGF0
ZS5jCmluZGV4IDE0YzE2N2YuLjRiNmQ2YzggMTAwNjQ0Ci0tLSBhL3RhcmdldC1jcmlzL3RyYW5z
bGF0ZS5jCisrKyBiL3RhcmdldC1jcmlzL3RyYW5zbGF0ZS5jCkBAIC0yODg4LDcgKzI4ODgsOCBA
QCBzdGF0aWMgaW50IGRlY19yZmVfZXRjKENQVUNSSVNTdGF0ZSAqZW52LCBEaXNhc0NvbnRleHQg
KmRjKQogICAgIGNyaXNfY2NfbWFzayhkYywgMCk7CiAKICAgICBpZiAoZGMtPm9wMiA9PSAxNSkg
ewotICAgICAgICB0X2dlbl9tb3ZfZW52X1ROKGhhbHRlZCwgdGNnX2NvbnN0X3RsKDEpKTsKKyAg
ICAgICAgdGNnX2dlbl9zdF9pMzIodGNnX2NvbnN0X2kzMigxKSwgY3B1X2VudiwKKyAgICAgICAg
ICAgICAgICAgICAgICAgLW9mZnNldG9mKENSSVNDUFUsIGVudikgKyBvZmZzZXRvZihDUFVTdGF0
ZSwgaGFsdGVkKSk7CiAgICAgICAgIHRjZ19nZW5fbW92aV90bChlbnZfcGMsIGRjLT5wYyArIDIp
OwogICAgICAgICB0X2dlbl9yYWlzZV9leGNlcHRpb24oRVhDUF9ITFQpOwogICAgICAgICByZXR1
cm4gMjsKZGlmZiAtLWdpdCBhL3RhcmdldC1pMzg2L2NwdS5jIGIvdGFyZ2V0LWkzODYvY3B1LmMK
aW5kZXggOWIxZjdkMS4uNTdiYTg0ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvY3B1LmMKKysr
IGIvdGFyZ2V0LWkzODYvY3B1LmMKQEAgLTIwMTQsNyArMjAxNCw3IEBAIHN0YXRpYyB2b2lkIHg4
Nl9jcHVfcmVzZXQoQ1BVU3RhdGUgKnMpCiAgICAgICAgIGFwaWNfZGVzaWduYXRlX2JzcChlbnYt
PmFwaWNfc3RhdGUpOwogICAgIH0KIAotICAgIGVudi0+aGFsdGVkID0gIWNwdV9pc19ic3AoY3B1
KTsKKyAgICBzLT5oYWx0ZWQgPSAhY3B1X2lzX2JzcChjcHUpOwogI2VuZGlmCiB9CiAKZGlmZiAt
LWdpdCBhL3RhcmdldC1pMzg2L2NwdS5oIGIvdGFyZ2V0LWkzODYvY3B1LmgKaW5kZXggMGMxYzVj
NS4uYmY2ZTIxMCAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvY3B1LmgKKysrIGIvdGFyZ2V0LWkz
ODYvY3B1LmgKQEAgLTk2Nyw2ICs5NjcsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X3g4Nl9s
b2FkX3NlZ19jYWNoZShDUFVYODZTdGF0ZSAqZW52LAogc3RhdGljIGlubGluZSB2b2lkIGNwdV94
ODZfbG9hZF9zZWdfY2FjaGVfc2lwaShYODZDUFUgKmNwdSwKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IHNpcGlfdmVjdG9yKQogeworICAgIENQVVN0
YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVg4NlN0YXRlICplbnYgPSAmY3B1LT5lbnY7CiAK
ICAgICBlbnYtPmVpcCA9IDA7CkBAIC05NzQsNyArOTc1LDcgQEAgc3RhdGljIGlubGluZSB2b2lk
IGNwdV94ODZfbG9hZF9zZWdfY2FjaGVfc2lwaShYODZDUFUgKmNwdSwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHNpcGlfdmVjdG9yIDw8IDEyLAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgZW52LT5zZWdzW1JfQ1NdLmxpbWl0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgZW52
LT5zZWdzW1JfQ1NdLmZsYWdzKTsKLSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgY3MtPmhhbHRl
ZCA9IDA7CiB9CiAKIGludCBjcHVfeDg2X2dldF9kZXNjcl9kZWJ1ZyhDUFVYODZTdGF0ZSAqZW52
LCB1bnNpZ25lZCBpbnQgc2VsZWN0b3IsCkBAIC0xMTY2LDE3ICsxMTY3LDE4IEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBjcHVfY2xvbmVfcmVncyhDUFVYODZTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcg
bmV3c3ApCiAjaW5jbHVkZSAiaHcvYXBpYy5oIgogI2VuZGlmCiAKLXN0YXRpYyBpbmxpbmUgYm9v
bCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKK3N0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFz
X3dvcmsoQ1BVU3RhdGUgKmNzKQogewotICAgIENQVVg4NlN0YXRlICplbnYgPSAmWDg2X0NQVShj
cHUpLT5lbnY7CisgICAgWDg2Q1BVICpjcHUgPSBYODZfQ1BVKGNzKTsKKyAgICBDUFVYODZTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgcmV0dXJuICgoZW52LT5pbnRlcnJ1cHRfcmVxdWVz
dCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQ1BVX0lOVEVSUlVQVF9QT0xMKSkgJiYKKyAgICByZXR1cm4gKChjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9QT0xMKSkgJiYKICAgICAgICAgICAgIChl
bnYtPmVmbGFncyAmIElGX01BU0spKSB8fAotICAgICAgICAgICAoZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmIChDUFVfSU5URVJSVVBUX05NSSB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIENQVV9JTlRFUlJVUFRfSU5JVCB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfU0lQSSB8Ci0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfTUNFKSk7CisgICAgICAgICAgIChjcy0+aW50
ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9OTUkgfAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfSU5JVCB8CisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9TSVBJIHwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX01DRSkpOwogfQogCiAjaW5jbHVk
ZSAiZXhlYy9leGVjLWFsbC5oIgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYvaGVscGVyLmMgYi90
YXJnZXQtaTM4Ni9oZWxwZXIuYwppbmRleCA4MmE3MzFjLi5iNDlhMGZjIDEwMDY0NAotLS0gYS90
YXJnZXQtaTM4Ni9oZWxwZXIuYworKysgYi90YXJnZXQtaTM4Ni9oZWxwZXIuYwpAQCAtMTgyLDYg
KzE4Miw3IEBAIGRvbmU6CiB2b2lkIGNwdV9kdW1wX3N0YXRlKENQVVg4NlN0YXRlICplbnYsIEZJ
TEUgKmYsIGZwcmludGZfZnVuY3Rpb24gY3B1X2ZwcmludGYsCiAgICAgICAgICAgICAgICAgICAg
IGludCBmbGFncykKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoeDg2X2Vudl9nZXRfY3B1KGVu
dikpOwogICAgIGludCBlZmxhZ3MsIGksIG5iOwogICAgIGNoYXIgY2Nfb3BfbmFtZVszMl07CiAg
ICAgc3RhdGljIGNvbnN0IGNoYXIgKnNlZ19uYW1lWzZdID0geyAiRVMiLCAiQ1MiLCAiU1MiLCAi
RFMiLCAiRlMiLCAiR1MiIH07CkBAIC0yMjUsNyArMjI2LDcgQEAgdm9pZCBjcHVfZHVtcF9zdGF0
ZShDUFVYODZTdGF0ZSAqZW52LCBGSUxFICpmLCBmcHJpbnRmX2Z1bmN0aW9uIGNwdV9mcHJpbnRm
LAogICAgICAgICAgICAgICAgICAgICAoZW52LT5oZmxhZ3MgPj4gSEZfSU5ISUJJVF9JUlFfU0hJ
RlQpICYgMSwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+YTIwX21hc2sgPj4gMjApICYgMSwK
ICAgICAgICAgICAgICAgICAgICAgKGVudi0+aGZsYWdzID4+IEhGX1NNTV9TSElGVCkgJiAxLAot
ICAgICAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCk7CisgICAgICAgICAgICAgICAgICAgIGNz
LT5oYWx0ZWQpOwogICAgIH0gZWxzZQogI2VuZGlmCiAgICAgewpAQCAtMjUyLDcgKzI1Myw3IEBA
IHZvaWQgY3B1X2R1bXBfc3RhdGUoQ1BVWDg2U3RhdGUgKmVudiwgRklMRSAqZiwgZnByaW50Zl9m
dW5jdGlvbiBjcHVfZnByaW50ZiwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+aGZsYWdzID4+
IEhGX0lOSElCSVRfSVJRX1NISUZUKSAmIDEsCiAgICAgICAgICAgICAgICAgICAgIChlbnYtPmEy
MF9tYXNrID4+IDIwKSAmIDEsCiAgICAgICAgICAgICAgICAgICAgIChlbnYtPmhmbGFncyA+PiBI
Rl9TTU1fU0hJRlQpICYgMSwKLSAgICAgICAgICAgICAgICAgICAgZW52LT5oYWx0ZWQpOworICAg
ICAgICAgICAgICAgICAgICBjcy0+aGFsdGVkKTsKICAgICB9CiAKICAgICBmb3IoaSA9IDA7IGkg
PCA2OyBpKyspIHsKQEAgLTEyODEsMTIgKzEyODIsMTMgQEAgaW50IGNwdV94ODZfZ2V0X2Rlc2Ny
X2RlYnVnKENQVVg4NlN0YXRlICplbnYsIHVuc2lnbmVkIGludCBzZWxlY3RvciwKICNpZiAhZGVm
aW5lZChDT05GSUdfVVNFUl9PTkxZKQogdm9pZCBkb19jcHVfaW5pdChYODZDUFUgKmNwdSkKIHsK
KyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVYODZTdGF0ZSAqZW52ID0gJmNw
dS0+ZW52OwotICAgIGludCBzaXBpID0gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRF
UlJVUFRfU0lQSTsKKyAgICBpbnQgc2lwaSA9IGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9J
TlRFUlJVUFRfU0lQSTsKICAgICB1aW50NjRfdCBwYXQgPSBlbnYtPnBhdDsKIAotICAgIGNwdV9y
ZXNldChDUFUoY3B1KSk7Ci0gICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCA9IHNpcGk7CisgICAg
Y3B1X3Jlc2V0KGNzKTsKKyAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgPSBzaXBpOwogICAgIGVu
di0+cGF0ID0gcGF0OwogICAgIGFwaWNfaW5pdF9yZXNldChlbnYtPmFwaWNfc3RhdGUpOwogfQpk
aWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYva3ZtLmMgYi90YXJnZXQtaTM4Ni9rdm0uYwppbmRleCAw
Y2Y0MTNkLi5kZjMwZmE2IDEwMDY0NAotLS0gYS90YXJnZXQtaTM4Ni9rdm0uYworKysgYi90YXJn
ZXQtaTM4Ni9rdm0uYwpAQCAtMTQ2MCwxNyArMTQ2MCwxOCBAQCBzdGF0aWMgaW50IGt2bV9wdXRf
bXBfc3RhdGUoWDg2Q1BVICpjcHUpCiAKIHN0YXRpYyBpbnQga3ZtX2dldF9tcF9zdGF0ZShYODZD
UFUgKmNwdSkKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVYODZTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogICAgIHN0cnVjdCBrdm1fbXBfc3RhdGUgbXBfc3RhdGU7CiAg
ICAgaW50IHJldDsKIAotICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKENQVShjcHUpLCBLVk1fR0VU
X01QX1NUQVRFLCAmbXBfc3RhdGUpOworICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKGNzLCBLVk1f
R0VUX01QX1NUQVRFLCAmbXBfc3RhdGUpOwogICAgIGlmIChyZXQgPCAwKSB7CiAgICAgICAgIHJl
dHVybiByZXQ7CiAgICAgfQogICAgIGVudi0+bXBfc3RhdGUgPSBtcF9zdGF0ZS5tcF9zdGF0ZTsK
ICAgICBpZiAoa3ZtX2lycWNoaXBfaW5fa2VybmVsKCkpIHsKLSAgICAgICAgZW52LT5oYWx0ZWQg
PSAobXBfc3RhdGUubXBfc3RhdGUgPT0gS1ZNX01QX1NUQVRFX0hBTFRFRCk7CisgICAgICAgIGNz
LT5oYWx0ZWQgPSAobXBfc3RhdGUubXBfc3RhdGUgPT0gS1ZNX01QX1NUQVRFX0hBTFRFRCk7CiAg
ICAgfQogICAgIHJldHVybiAwOwogfQpAQCAtMTc2Miw4ICsxNzYzLDggQEAgdm9pZCBrdm1fYXJj
aF9wcmVfcnVuKENQVVN0YXRlICpjcHUsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAgICAgaW50IHJl
dDsKIAogICAgIC8qIEluamVjdCBOTUkgKi8KLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVz
dCAmIENQVV9JTlRFUlJVUFRfTk1JKSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3Qg
Jj0gfkNQVV9JTlRFUlJVUFRfTk1JOworICAgIGlmIChjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYg
Q1BVX0lOVEVSUlVQVF9OTUkpIHsKKyAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+
Q1BVX0lOVEVSUlVQVF9OTUk7CiAgICAgICAgIERQUklOVEYoImluamVjdGVkIE5NSVxuIik7CiAg
ICAgICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKGNwdSwgS1ZNX05NSSk7CiAgICAgICAgIGlmIChy
ZXQgPCAwKSB7CkBAIC0xNzc1LDE4ICsxNzc2LDE4IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihD
UFVTdGF0ZSAqY3B1LCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogICAgIGlmICgha3ZtX2lycWNoaXBf
aW5fa2VybmVsKCkpIHsKICAgICAgICAgLyogRm9yY2UgdGhlIFZDUFUgb3V0IG9mIGl0cyBpbm5l
ciBsb29wIHRvIHByb2Nlc3MgYW55IElOSVQgcmVxdWVzdHMKICAgICAgICAgICogb3IgcGVuZGlu
ZyBUUFIgYWNjZXNzIHJlcG9ydHMuICovCi0gICAgICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICYKKyAgICAgICAgaWYgKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJgogICAgICAgICAgICAg
KENQVV9JTlRFUlJVUFRfSU5JVCB8IENQVV9JTlRFUlJVUFRfVFBSKSkgewogICAgICAgICAgICAg
Y3B1LT5leGl0X3JlcXVlc3QgPSAxOwogICAgICAgICB9CiAKICAgICAgICAgLyogVHJ5IHRvIGlu
amVjdCBhbiBpbnRlcnJ1cHQgaWYgdGhlIGd1ZXN0IGNhbiBhY2NlcHQgaXQgKi8KICAgICAgICAg
aWYgKHJ1bi0+cmVhZHlfZm9yX2ludGVycnVwdF9pbmplY3Rpb24gJiYKLSAgICAgICAgICAgIChl
bnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgICAgICAg
ICAgKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAg
ICAgICAgICAoZW52LT5lZmxhZ3MgJiBJRl9NQVNLKSkgewogICAgICAgICAgICAgaW50IGlycTsK
IAotICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9I
QVJEOworICAgICAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQ
VF9IQVJEOwogICAgICAgICAgICAgaXJxID0gY3B1X2dldF9waWNfaW50ZXJydXB0KGVudik7CiAg
ICAgICAgICAgICBpZiAoaXJxID49IDApIHsKICAgICAgICAgICAgICAgICBzdHJ1Y3Qga3ZtX2lu
dGVycnVwdCBpbnRyOwpAQCAtMTgwNiw3ICsxODA3LDcgQEAgdm9pZCBrdm1fYXJjaF9wcmVfcnVu
KENQVVN0YXRlICpjcHUsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAgICAgICAgICAqIGludGVycnVw
dCwgcmVxdWVzdCBhbiBpbnRlcnJ1cHQgd2luZG93IGV4aXQuICBUaGlzIHdpbGwKICAgICAgICAg
ICogY2F1c2UgYSByZXR1cm4gdG8gdXNlcnNwYWNlIGFzIHNvb24gYXMgdGhlIGd1ZXN0IGlzIHJl
YWR5IHRvCiAgICAgICAgICAqIHJlY2VpdmUgaW50ZXJydXB0cy4gKi8KLSAgICAgICAgaWYgKChl
bnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSkgeworICAgICAgICBp
ZiAoKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpKSB7CiAgICAg
ICAgICAgICBydW4tPnJlcXVlc3RfaW50ZXJydXB0X3dpbmRvdyA9IDE7CiAgICAgICAgIH0gZWxz
ZSB7CiAgICAgICAgICAgICBydW4tPnJlcXVlc3RfaW50ZXJydXB0X3dpbmRvdyA9IDA7CkBAIC0x
ODM2LDExICsxODM3LDExIEBAIGludCBrdm1fYXJjaF9wcm9jZXNzX2FzeW5jX2V2ZW50cyhDUFVT
dGF0ZSAqY3MpCiAgICAgWDg2Q1BVICpjcHUgPSBYODZfQ1BVKGNzKTsKICAgICBDUFVYODZTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBD
UFVfSU5URVJSVVBUX01DRSkgeworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVf
SU5URVJSVVBUX01DRSkgewogICAgICAgICAvKiBXZSBtdXN0IG5vdCByYWlzZSBDUFVfSU5URVJS
VVBUX01DRSBpZiBpdCdzIG5vdCBzdXBwb3J0ZWQuICovCiAgICAgICAgIGFzc2VydChlbnYtPm1j
Z19jYXApOwogCi0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJV
UFRfTUNFOworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRf
TUNFOwogCiAgICAgICAgIGt2bV9jcHVfc3luY2hyb25pemVfc3RhdGUoZW52KTsKIApAQCAtMTg1
Myw3ICsxODU0LDcgQEAgaW50IGt2bV9hcmNoX3Byb2Nlc3NfYXN5bmNfZXZlbnRzKENQVVN0YXRl
ICpjcykKICAgICAgICAgZW52LT5leGNlcHRpb25faW5qZWN0ZWQgPSBFWENQMTJfTUNISzsKICAg
ICAgICAgZW52LT5oYXNfZXJyb3JfY29kZSA9IDA7CiAKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAw
OworICAgICAgICBjcy0+aGFsdGVkID0gMDsKICAgICAgICAgaWYgKGt2bV9pcnFjaGlwX2luX2tl
cm5lbCgpICYmIGVudi0+bXBfc3RhdGUgPT0gS1ZNX01QX1NUQVRFX0hBTFRFRCkgewogICAgICAg
ICAgICAgZW52LT5tcF9zdGF0ZSA9IEtWTV9NUF9TVEFURV9SVU5OQUJMRTsKICAgICAgICAgfQpA
QCAtMTg2Myw0MSArMTg2NCw0MiBAQCBpbnQga3ZtX2FyY2hfcHJvY2Vzc19hc3luY19ldmVudHMo
Q1BVU3RhdGUgKmNzKQogICAgICAgICByZXR1cm4gMDsKICAgICB9CiAKLSAgICBpZiAoZW52LT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfUE9MTCkgewotICAgICAgICBlbnYtPmlu
dGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7CisgICAgaWYgKGNzLT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfUE9MTCkgeworICAgICAgICBjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfUE9MTDsKICAgICAgICAgYXBpY19wb2xsX2ly
cShlbnYtPmFwaWNfc3RhdGUpOwogICAgIH0KLSAgICBpZiAoKChlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgIGlmICgoKGNzLT5pbnRlcnJ1cHRfcmVx
dWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKICAgICAgICAgIChlbnYtPmVmbGFncyAmIElG
X01BU0spKSB8fAotICAgICAgICAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJV
UFRfTk1JKSkgewotICAgICAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgICAgIChjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkpIHsKKyAgICAgICAgY3MtPmhhbHRlZCA9
IDA7CiAgICAgfQotICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQ
VF9JTklUKSB7CisgICAgaWYgKGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRf
SU5JVCkgewogICAgICAgICBrdm1fY3B1X3N5bmNocm9uaXplX3N0YXRlKGVudik7CiAgICAgICAg
IGRvX2NwdV9pbml0KGNwdSk7CiAgICAgfQotICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0
ICYgQ1BVX0lOVEVSUlVQVF9TSVBJKSB7CisgICAgaWYgKGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfU0lQSSkgewogICAgICAgICBrdm1fY3B1X3N5bmNocm9uaXplX3N0YXRl
KGVudik7CiAgICAgICAgIGRvX2NwdV9zaXBpKGNwdSk7CiAgICAgfQotICAgIGlmIChlbnYtPmlu
dGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9UUFIpIHsKLSAgICAgICAgZW52LT5pbnRl
cnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9UUFI7CisgICAgaWYgKGNzLT5pbnRlcnJ1
cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfVFBSKSB7CisgICAgICAgIGNzLT5pbnRlcnJ1cHRf
cmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9UUFI7CiAgICAgICAgIGt2bV9jcHVfc3luY2hyb25p
emVfc3RhdGUoZW52KTsKICAgICAgICAgYXBpY19oYW5kbGVfdHByX2FjY2Vzc19yZXBvcnQoZW52
LT5hcGljX3N0YXRlLCBlbnYtPmVpcCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZW52LT50cHJfYWNjZXNzX3R5cGUpOwogICAgIH0KIAotICAgIHJldHVybiBlbnYtPmhh
bHRlZDsKKyAgICByZXR1cm4gY3MtPmhhbHRlZDsKIH0KIAogc3RhdGljIGludCBrdm1faGFuZGxl
X2hhbHQoWDg2Q1BVICpjcHUpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAg
Q1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKIAotICAgIGlmICghKChlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgIGlmICghKChjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAgICAgICAgKGVudi0+ZWZs
YWdzICYgSUZfTUFTSykpICYmCi0gICAgICAgICEoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQ
VV9JTlRFUlJVUFRfTk1JKSkgewotICAgICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICEo
Y3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9OTUkpKSB7CisgICAgICAgIGNz
LT5oYWx0ZWQgPSAxOwogICAgICAgICByZXR1cm4gRVhDUF9ITFQ7CiAgICAgfQogCmRpZmYgLS1n
aXQgYS90YXJnZXQtaTM4Ni9tYWNoaW5lLmMgYi90YXJnZXQtaTM4Ni9tYWNoaW5lLmMKaW5kZXgg
Yzk5ODRiOC4uYjgwYTVmNCAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvbWFjaGluZS5jCisrKyBi
L3RhcmdldC1pMzg2L21hY2hpbmUuYwpAQCAtNDUzLDcgKzQ1Myw3IEBAIGNvbnN0IFZNU3RhdGVE
ZXNjcmlwdGlvbiB2bXN0YXRlX3g4Nl9jcHUgPSB7CiAgICAgICAgIFZNU1RBVEVfVUlOVDY0X1Yo
ZW52LnBhdCwgWDg2Q1BVLCA1KSwKICAgICAgICAgVk1TVEFURV9VSU5UMzJfVihlbnYuaGZsYWdz
MiwgWDg2Q1BVLCA1KSwKIAotICAgICAgICBWTVNUQVRFX1VJTlQzMl9URVNUKGVudi5oYWx0ZWQs
IFg4NkNQVSwgdmVyc2lvbl9pc181KSwKKyAgICAgICAgVk1TVEFURV9VSU5UMzJfVEVTVChwYXJl
bnRfb2JqLmhhbHRlZCwgWDg2Q1BVLCB2ZXJzaW9uX2lzXzUpLAogICAgICAgICBWTVNUQVRFX1VJ
TlQ2NF9WKGVudi52bV9oc2F2ZSwgWDg2Q1BVLCA1KSwKICAgICAgICAgVk1TVEFURV9VSU5UNjRf
VihlbnYudm1fdm1jYiwgWDg2Q1BVLCA1KSwKICAgICAgICAgVk1TVEFURV9VSU5UNjRfVihlbnYu
dHNjX29mZnNldCwgWDg2Q1BVLCA1KSwKZGlmZiAtLWdpdCBhL3RhcmdldC1pMzg2L21pc2NfaGVs
cGVyLmMgYi90YXJnZXQtaTM4Ni9taXNjX2hlbHBlci5jCmluZGV4IGI2ZDU3NDAuLmRmYmMwN2Ig
MTAwNjQ0Ci0tLSBhL3RhcmdldC1pMzg2L21pc2NfaGVscGVyLmMKKysrIGIvdGFyZ2V0LWkzODYv
bWlzY19oZWxwZXIuYwpAQCAtNTUzLDIwICs1NTMsMjUgQEAgdm9pZCBoZWxwZXJfcmRtc3IoQ1BV
WDg2U3RhdGUgKmVudikKIH0KICNlbmRpZgogCi1zdGF0aWMgdm9pZCBkb19obHQoQ1BVWDg2U3Rh
dGUgKmVudikKK3N0YXRpYyB2b2lkIGRvX2hsdChYODZDUFUgKmNwdSkKIHsKKyAgICBDUFVTdGF0
ZSAqY3MgPSBDUFUoY3B1KTsKKyAgICBDUFVYODZTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OworCiAg
ICAgZW52LT5oZmxhZ3MgJj0gfkhGX0lOSElCSVRfSVJRX01BU0s7IC8qIG5lZWRlZCBpZiBzdGkg
aXMganVzdCBiZWZvcmUgKi8KLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MtPmhhbHRlZCA9
IDE7CiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsKICAgICBjcHVfbG9vcF9l
eGl0KGVudik7CiB9CiAKIHZvaWQgaGVscGVyX2hsdChDUFVYODZTdGF0ZSAqZW52LCBpbnQgbmV4
dF9laXBfYWRkZW5kKQogeworICAgIFg4NkNQVSAqY3B1ID0geDg2X2Vudl9nZXRfY3B1KGVudik7
CisKICAgICBjcHVfc3ZtX2NoZWNrX2ludGVyY2VwdF9wYXJhbShlbnYsIFNWTV9FWElUX0hMVCwg
MCk7CiAgICAgRUlQICs9IG5leHRfZWlwX2FkZGVuZDsKIAotICAgIGRvX2hsdChlbnYpOworICAg
IGRvX2hsdChjcHUpOwogfQogCiB2b2lkIGhlbHBlcl9tb25pdG9yKENQVVg4NlN0YXRlICplbnYs
IHRhcmdldF91bG9uZyBwdHIpCkBAIC01ODAsNyArNTg1LDggQEAgdm9pZCBoZWxwZXJfbW9uaXRv
cihDUFVYODZTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgcHRyKQogCiB2b2lkIGhlbHBlcl9td2Fp
dChDUFVYODZTdGF0ZSAqZW52LCBpbnQgbmV4dF9laXBfYWRkZW5kKQogewotICAgIENQVVN0YXRl
ICpjcHU7CisgICAgQ1BVU3RhdGUgKmNzOworICAgIFg4NkNQVSAqY3B1OwogCiAgICAgaWYgKCh1
aW50MzJfdClFQ1ggIT0gMCkgewogICAgICAgICByYWlzZV9leGNlcHRpb24oZW52LCBFWENQMERf
R1BGKTsKQEAgLTU4OCwxMyArNTk0LDE0IEBAIHZvaWQgaGVscGVyX213YWl0KENQVVg4NlN0YXRl
ICplbnYsIGludCBuZXh0X2VpcF9hZGRlbmQpCiAgICAgY3B1X3N2bV9jaGVja19pbnRlcmNlcHRf
cGFyYW0oZW52LCBTVk1fRVhJVF9NV0FJVCwgMCk7CiAgICAgRUlQICs9IG5leHRfZWlwX2FkZGVu
ZDsKIAotICAgIGNwdSA9IENQVSh4ODZfZW52X2dldF9jcHUoZW52KSk7CisgICAgY3B1ID0geDg2
X2Vudl9nZXRfY3B1KGVudik7CisgICAgY3MgPSBDUFUoY3B1KTsKICAgICAvKiBYWFg6IG5vdCBj
b21wbGV0ZSBidXQgbm90IGNvbXBsZXRlbHkgZXJyb25lb3VzICovCi0gICAgaWYgKGNwdS0+Y3B1
X2luZGV4ICE9IDAgfHwgZW52LT5uZXh0X2NwdSAhPSBOVUxMKSB7CisgICAgaWYgKGNzLT5jcHVf
aW5kZXggIT0gMCB8fCBlbnYtPm5leHRfY3B1ICE9IE5VTEwpIHsKICAgICAgICAgLyogbW9yZSB0
aGFuIG9uZSBDUFU6IGRvIG5vdCBzbGVlcCBiZWNhdXNlIGFub3RoZXIgQ1BVIG1heQogICAgICAg
ICAgICB3YWtlIHRoaXMgb25lICovCiAgICAgfSBlbHNlIHsKLSAgICAgICAgZG9faGx0KGVudik7
CisgICAgICAgIGRvX2hsdChjcHUpOwogICAgIH0KIH0KIApkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkz
ODYvc3ZtX2hlbHBlci5jIGIvdGFyZ2V0LWkzODYvc3ZtX2hlbHBlci5jCmluZGV4IDNmMjQ2ZTku
LmM0NmEyMTMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1pMzg2L3N2bV9oZWxwZXIuYworKysgYi90YXJn
ZXQtaTM4Ni9zdm1faGVscGVyLmMKQEAgLTI3MSw3ICsyNzEsOSBAQCB2b2lkIGhlbHBlcl92bXJ1
bihDUFVYODZTdGF0ZSAqZW52LCBpbnQgYWZsYWcsIGludCBuZXh0X2VpcF9hZGRlbmQpCiAgICAg
ZW52LT5oZmxhZ3MyIHw9IEhGMl9HSUZfTUFTSzsKIAogICAgIGlmIChpbnRfY3RsICYgVl9JUlFf
TUFTSykgewotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRf
VklSUTsKKyAgICAgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHg4Nl9lbnZfZ2V0X2NwdShlbnYpKTsK
KworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9WSVJROwog
ICAgIH0KIAogICAgIC8qIG1heWJlIHdlIG5lZWQgdG8gaW5qZWN0IGFuIGV2ZW50ICovCkBAIC01
NDgsNiArNTUwLDcgQEAgdm9pZCBoZWxwZXJfc3ZtX2NoZWNrX2lvKENQVVg4NlN0YXRlICplbnYs
IHVpbnQzMl90IHBvcnQsIHVpbnQzMl90IHBhcmFtLAogLyogTm90ZTogY3VycmVudGx5IG9ubHkg
MzIgYml0cyBvZiBleGl0X2NvZGUgYXJlIHVzZWQgKi8KIHZvaWQgaGVscGVyX3ZtZXhpdChDUFVY
ODZTdGF0ZSAqZW52LCB1aW50MzJfdCBleGl0X2NvZGUsIHVpbnQ2NF90IGV4aXRfaW5mb18xKQog
eworICAgIENQVVN0YXRlICpjcyA9IENQVSh4ODZfZW52X2dldF9jcHUoZW52KSk7CiAgICAgdWlu
dDMyX3QgaW50X2N0bDsKIAogICAgIHFlbXVfbG9nX21hc2soQ1BVX0xPR19UQl9JTl9BU00sICJ2
bWV4aXQoJTA4eCwgJTAxNiIgUFJJeDY0ICIsICUwMTYiCkBAIC01OTQsNyArNTk3LDcgQEAgdm9p
ZCBoZWxwZXJfdm1leGl0KENQVVg4NlN0YXRlICplbnYsIHVpbnQzMl90IGV4aXRfY29kZSwgdWlu
dDY0X3QgZXhpdF9pbmZvXzEpCiAgICAgaW50X2N0bCA9IGxkbF9waHlzKGVudi0+dm1fdm1jYiAr
IG9mZnNldG9mKHN0cnVjdCB2bWNiLCBjb250cm9sLmludF9jdGwpKTsKICAgICBpbnRfY3RsICY9
IH4oVl9UUFJfTUFTSyB8IFZfSVJRX01BU0spOwogICAgIGludF9jdGwgfD0gZW52LT52X3RwciAm
IFZfVFBSX01BU0s7Ci0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX1ZJUlEpIHsKKyAgICBpZiAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQ
VF9WSVJRKSB7CiAgICAgICAgIGludF9jdGwgfD0gVl9JUlFfTUFTSzsKICAgICB9CiAgICAgc3Rs
X3BoeXMoZW52LT52bV92bWNiICsgb2Zmc2V0b2Yoc3RydWN0IHZtY2IsIGNvbnRyb2wuaW50X2N0
bCksIGludF9jdGwpOwpAQCAtNjE1LDcgKzYxOCw3IEBAIHZvaWQgaGVscGVyX3ZtZXhpdChDUFVY
ODZTdGF0ZSAqZW52LCB1aW50MzJfdCBleGl0X2NvZGUsIHVpbnQ2NF90IGV4aXRfaW5mb18xKQog
ICAgIGVudi0+aGZsYWdzICY9IH5IRl9TVk1JX01BU0s7CiAgICAgZW52LT5pbnRlcmNlcHQgPSAw
OwogICAgIGVudi0+aW50ZXJjZXB0X2V4Y2VwdGlvbnMgPSAwOwotICAgIGVudi0+aW50ZXJydXB0
X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfVklSUTsKKyAgICBjcy0+aW50ZXJydXB0X3JlcXVl
c3QgJj0gfkNQVV9JTlRFUlJVUFRfVklSUTsKICAgICBlbnYtPnRzY19vZmZzZXQgPSAwOwogCiAg
ICAgZW52LT5nZHQuYmFzZSAgPSBsZHFfcGh5cyhlbnYtPnZtX2hzYXZlICsgb2Zmc2V0b2Yoc3Ry
dWN0IHZtY2IsCmRpZmYgLS1naXQgYS90YXJnZXQtbG0zMi9jcHUuaCBiL3RhcmdldC1sbTMyL2Nw
dS5oCmluZGV4IGUwYmJlMDQuLjNkMzE4MWIgMTAwNjQ0Ci0tLSBhL3RhcmdldC1sbTMyL2NwdS5o
CisrKyBiL3RhcmdldC1sbTMyL2NwdS5oCkBAIC0yNTIsOSArMjUyLDcgQEAgc3RhdGljIGlubGlu
ZSB2b2lkIGNwdV9nZXRfdGJfY3B1X3N0YXRlKENQVUxNMzJTdGF0ZSAqZW52LCB0YXJnZXRfdWxv
bmcgKnBjLAogCiBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUp
CiB7Ci0gICAgQ1BVTE0zMlN0YXRlICplbnYgPSAmTE0zMl9DUFUoY3B1KS0+ZW52OwotCi0gICAg
cmV0dXJuIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CisgICAg
cmV0dXJuIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CiB9CiAK
ICNpbmNsdWRlICJleGVjL2V4ZWMtYWxsLmgiCmRpZmYgLS1naXQgYS90YXJnZXQtbG0zMi9vcF9o
ZWxwZXIuYyBiL3RhcmdldC1sbTMyL29wX2hlbHBlci5jCmluZGV4IDUzNDEwYjEuLmViYzk0YTAg
MTAwNjQ0Ci0tLSBhL3RhcmdldC1sbTMyL29wX2hlbHBlci5jCisrKyBiL3RhcmdldC1sbTMyL29w
X2hlbHBlci5jCkBAIC0yNSw3ICsyNSw5IEBAIHZvaWQgaGVscGVyX3JhaXNlX2V4Y2VwdGlvbihD
UFVMTTMyU3RhdGUgKmVudiwgdWludDMyX3QgaW5kZXgpCiAKIHZvaWQgaGVscGVyX2hsdChDUFVM
TTMyU3RhdGUgKmVudikKIHsKLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgQ1BVU3RhdGUgKmNz
ID0gQ1BVKGxtMzJfZW52X2dldF9jcHUoZW52KSk7CisKKyAgICBjcy0+aGFsdGVkID0gMTsKICAg
ICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgIGNwdV9sb29wX2V4aXQoZW52
KTsKIH0KZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL2NwdS5oIGIvdGFyZ2V0LW02OGsvY3B1LmgK
aW5kZXggMjY3MmVhZS4uYmIyZmJkNiAxMDA2NDQKLS0tIGEvdGFyZ2V0LW02OGsvY3B1LmgKKysr
IGIvdGFyZ2V0LW02OGsvY3B1LmgKQEAgLTI2NSw5ICsyNjUsNyBAQCBzdGF0aWMgaW5saW5lIHZv
aWQgY3B1X2dldF90Yl9jcHVfc3RhdGUoQ1BVTTY4S1N0YXRlICplbnYsIHRhcmdldF91bG9uZyAq
cGMsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsK
LSAgICBDUFVNNjhLU3RhdGUgKmVudiA9ICZNNjhLX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1
cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICByZXR1
cm4gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKIH0KIAogI2lu
Y2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL29wX2hlbHBl
ci5jIGIvdGFyZ2V0LW02OGsvb3BfaGVscGVyLmMKaW5kZXggMTZkZjI0Yy4uZTExZjM0YiAxMDA2
NDQKLS0tIGEvdGFyZ2V0LW02OGsvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LW02OGsvb3BfaGVs
cGVyLmMKQEAgLTg0LDYgKzg0LDcgQEAgc3RhdGljIHZvaWQgZG9fcnRlKENQVU02OEtTdGF0ZSAq
ZW52KQogCiBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1cHRfYWxsKENQVU02OEtTdGF0ZSAqZW52LCBp
bnQgaXNfaHcpCiB7CisgICAgQ1BVU3RhdGUgKmNzOwogICAgIHVpbnQzMl90IHNwOwogICAgIHVp
bnQzMl90IGZtdDsKICAgICB1aW50MzJfdCByZXRhZGRyOwpAQCAtMTA4LDcgKzEwOSw4IEBAIHN0
YXRpYyB2b2lkIGRvX2ludGVycnVwdF9hbGwoQ1BVTTY4S1N0YXRlICplbnYsIGludCBpc19odykK
ICAgICAgICAgICAgICAgICBkb19tNjhrX3NlbWlob3N0aW5nKGVudiwgZW52LT5kcmVnc1swXSk7
CiAgICAgICAgICAgICAgICAgcmV0dXJuOwogICAgICAgICAgICAgfQotICAgICAgICAgICAgZW52
LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgY3MgPSBDUFUobTY4a19lbnZfZ2V0X2NwdShlbnYp
KTsKKyAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgICAgICAgICAgZW52LT5leGNlcHRp
b25faW5kZXggPSBFWENQX0hMVDsKICAgICAgICAgICAgIGNwdV9sb29wX2V4aXQoZW52KTsKICAg
ICAgICAgICAgIHJldHVybjsKZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL3FyZWdzLmRlZiBiL3Rh
cmdldC1tNjhrL3FyZWdzLmRlZgppbmRleCA0OTQwMGM0Li40MjM1YjAyIDEwMDY0NAotLS0gYS90
YXJnZXQtbTY4ay9xcmVncy5kZWYKKysrIGIvdGFyZ2V0LW02OGsvcXJlZ3MuZGVmCkBAIC04LDYg
KzgsNSBAQCBERUZPMzIoQ0NfWCwgY2NfeCkKIERFRk8zMihESVYxLCBkaXYxKQogREVGTzMyKERJ
VjIsIGRpdjIpCiBERUZPMzIoRVhDRVBUSU9OLCBleGNlcHRpb25faW5kZXgpCi1ERUZPMzIoSEFM
VEVELCBoYWx0ZWQpCiBERUZPMzIoTUFDU1IsIG1hY3NyKQogREVGTzMyKE1BQ19NQVNLLCBtYWNf
bWFzaykKZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LW02OGsv
dHJhbnNsYXRlLmMKaW5kZXggM2YxNDc4Yy4uNDBkZDBhMCAxMDA2NDQKLS0tIGEvdGFyZ2V0LW02
OGsvdHJhbnNsYXRlLmMKKysrIGIvdGFyZ2V0LW02OGsvdHJhbnNsYXRlLmMKQEAgLTQyLDYgKzQy
LDggQEAKICN1bmRlZiBERUZPNjQKICN1bmRlZiBERUZGNjQKIAorc3RhdGljIFRDR3ZfaTMyIGNw
dV9oYWx0ZWQ7CisKIHN0YXRpYyBUQ0d2X3B0ciBjcHVfZW52OwogCiBzdGF0aWMgY2hhciBjcHVf
cmVnX25hbWVzWzMqOCozICsgNSo0XTsKQEAgLTc2LDYgKzc4LDEwIEBAIHZvaWQgbTY4a190Y2df
aW5pdCh2b2lkKQogI3VuZGVmIERFRk82NAogI3VuZGVmIERFRkY2NAogCisgICAgY3B1X2hhbHRl
ZCA9IHRjZ19nbG9iYWxfbWVtX25ld19pMzIoVENHX0FSRUcwLAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC1vZmZzZXRvZihNNjhrQ1BVLCBlbnYpICsKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZmZzZXRvZihDUFVTdGF0ZSwgaGFsdGVk
KSwgIkhBTFRFRCIpOworCiAgICAgY3B1X2VudiA9IHRjZ19nbG9iYWxfcmVnX25ld19wdHIoVENH
X0FSRUcwLCAiZW52Iik7CiAKICAgICBwID0gY3B1X3JlZ19uYW1lczsKQEAgLTIwMjQsNyArMjAz
MCw3IEBAIERJU0FTX0lOU04oc3RvcCkKICAgICBzLT5wYyArPSAyOwogCiAgICAgZ2VuX3NldF9z
cl9pbShzLCBleHQsIDApOwotICAgIHRjZ19nZW5fbW92aV9pMzIoUVJFR19IQUxURUQsIDEpOwor
ICAgIHRjZ19nZW5fbW92aV9pMzIoY3B1X2hhbHRlZCwgMSk7CiAgICAgZ2VuX2V4Y2VwdGlvbihz
LCBzLT5wYywgRVhDUF9ITFQpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtbWljcm9ibGF6ZS9j
cHUuaCBiL3RhcmdldC1taWNyb2JsYXplL2NwdS5oCmluZGV4IGMzZGQ3ZjYuLjc1NDhhYTkgMTAw
NjQ0Ci0tLSBhL3RhcmdldC1taWNyb2JsYXplL2NwdS5oCisrKyBiL3RhcmdldC1taWNyb2JsYXpl
L2NwdS5oCkBAIC0zNzQsOSArMzc0LDcgQEAgdm9pZCBjcHVfdW5hc3NpZ25lZF9hY2Nlc3MoQ1BV
TUJTdGF0ZSAqZW52MSwgaHdhZGRyIGFkZHIsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFz
X3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVNQlN0YXRlICplbnYgPSAmTUlDUk9CTEFa
RV9DUFUoY3B1KS0+ZW52OwotCi0gICAgcmV0dXJuIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiAo
Q1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9OTUkpOworICAgIHJldHVybiBjcHUt
PmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8IENQVV9JTlRFUlJVUFRf
Tk1JKTsKIH0KIAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3Rhcmdl
dC1taXBzL2NwdS5oIGIvdGFyZ2V0LW1pcHMvY3B1LmgKaW5kZXggMGUxOThiMS4uNzQzNDA5OSAx
MDA2NDQKLS0tIGEvdGFyZ2V0LW1pcHMvY3B1LmgKKysrIGIvdGFyZ2V0LW1pcHMvY3B1LmgKQEAg
LTcxOSw3ICs3MTksNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRl
ICpjcHUpCiAgICAgLyogSXQgaXMgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50IGlmIG5vbi1lbmFi
bGVkIGludGVycnVwdHMKICAgICAgICB3YWtlLXVwIHRoZSBDUFUsIGhvd2V2ZXIgbW9zdCBvZiB0
aGUgaW1wbGVtZW50YXRpb25zIG9ubHkKICAgICAgICBjaGVjayBmb3IgaW50ZXJydXB0cyB0aGF0
IGNhbiBiZSB0YWtlbi4gKi8KLSAgICBpZiAoKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVf
SU5URVJSVVBUX0hBUkQpICYmCisgICAgaWYgKChjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BV
X0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAgICBjcHVfbWlwc19od19pbnRlcnJ1cHRzX3BlbmRp
bmcoZW52KSkgewogICAgICAgICBoYXNfd29yayA9IHRydWU7CiAgICAgfQpAQCAtNzI4LDcgKzcy
OCw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKICAg
ICBpZiAoZW52LT5DUDBfQ29uZmlnMyAmICgxIDw8IENQMEMzX01UKSkgewogICAgICAgICAvKiBU
aGUgUUVNVSBtb2RlbCB3aWxsIGlzc3VlIGFuIF9XQUtFIHJlcXVlc3Qgd2hlbmV2ZXIgdGhlIENQ
VXMKICAgICAgICAgICAgc2hvdWxkIGJlIHdva2VuIHVwLiAgKi8KLSAgICAgICAgaWYgKGVudi0+
aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1dBS0UpIHsKKyAgICAgICAgaWYgKGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1dBS0UpIHsKICAgICAgICAgICAg
IGhhc193b3JrID0gdHJ1ZTsKICAgICAgICAgfQogCmRpZmYgLS1naXQgYS90YXJnZXQtbWlwcy9v
cF9oZWxwZXIuYyBiL3RhcmdldC1taXBzL29wX2hlbHBlci5jCmluZGV4IDQ1Y2JiMmYuLjNhYjQz
NTYgMTAwNjQ0Ci0tLSBhL3RhcmdldC1taXBzL29wX2hlbHBlci5jCisrKyBiL3RhcmdldC1taXBz
L29wX2hlbHBlci5jCkBAIC01MTUsMTEgKzUxNSwxMiBAQCB2b2lkIGhlbHBlcl9zZG0oQ1BVTUlQ
U1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBhZGRyLCB0YXJnZXRfdWxvbmcgcmVnbGlzdCwKIC8q
IFNNUCBoZWxwZXJzLiAgKi8KIHN0YXRpYyBib29sIG1pcHNfdnBlX2lzX3dmaShNSVBTQ1BVICpj
KQogeworICAgIENQVVN0YXRlICpjcHUgPSBDUFUoYyk7CiAgICAgQ1BVTUlQU1N0YXRlICplbnYg
PSAmYy0+ZW52OwogCiAgICAgLyogSWYgdGhlIFZQRSBpcyBoYWx0ZWQgYnV0IG90aGVyd2lzZSBh
Y3RpdmUsIGl0IG1lYW5zIGl0J3Mgd2FpdGluZyBmb3IKICAgICAgICBhbiBpbnRlcnJ1cHQuICAq
LwotICAgIHJldHVybiBlbnYtPmhhbHRlZCAmJiBtaXBzX3ZwZV9hY3RpdmUoZW52KTsKKyAgICBy
ZXR1cm4gY3B1LT5oYWx0ZWQgJiYgbWlwc192cGVfYWN0aXZlKGVudik7CiB9CiAKIHN0YXRpYyBp
bmxpbmUgdm9pZCBtaXBzX3ZwZV93YWtlKENQVU1JUFNTdGF0ZSAqYykKQEAgLTUzMiwxMSArNTMz
LDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBtaXBzX3ZwZV93YWtlKENQVU1JUFNTdGF0ZSAqYykK
IAogc3RhdGljIGlubGluZSB2b2lkIG1pcHNfdnBlX3NsZWVwKE1JUFNDUFUgKmNwdSkKIHsKKyAg
ICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVNSVBTU3RhdGUgKmMgPSAmY3B1LT5l
bnY7CiAKICAgICAvKiBUaGUgVlBFIHdhcyBzaHV0IG9mZiwgcmVhbGx5IGdvIHRvIGJlZC4KICAg
ICAgICBSZXNldCBhbnkgb2xkIF9XQUtFIHJlcXVlc3RzLiAgKi8KLSAgICBjLT5oYWx0ZWQgPSAx
OworICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgIGNwdV9yZXNldF9pbnRlcnJ1cHQoYywgQ1BVX0lO
VEVSUlVQVF9XQUtFKTsKIH0KIApAQCAtMjA5OSw3ICsyMTAxLDkgQEAgdm9pZCBoZWxwZXJfcG1v
bihDUFVNSVBTU3RhdGUgKmVudiwgaW50IGZ1bmN0aW9uKQogCiB2b2lkIGhlbHBlcl93YWl0KENQ
VU1JUFNTdGF0ZSAqZW52KQogewotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUobWlwc19lbnZfZ2V0X2NwdShlbnYpKTsKKworICAgIGNzLT5oYWx0ZWQgPSAxOwog
ICAgIGNwdV9yZXNldF9pbnRlcnJ1cHQoZW52LCBDUFVfSU5URVJSVVBUX1dBS0UpOwogICAgIGhl
bHBlcl9yYWlzZV9leGNlcHRpb24oZW52LCBFWENQX0hMVCk7CiB9CmRpZmYgLS1naXQgYS90YXJn
ZXQtbWlwcy90cmFuc2xhdGUuYyBiL3RhcmdldC1taXBzL3RyYW5zbGF0ZS5jCmluZGV4IGYxMGE1
MzMuLjAxY2VhNjkgMTAwNjQ0Ci0tLSBhL3RhcmdldC1taXBzL3RyYW5zbGF0ZS5jCisrKyBiL3Rh
cmdldC1taXBzL3RyYW5zbGF0ZS5jCkBAIC0xNjAxMiw3ICsxNjAxMiw3IEBAIHZvaWQgY3B1X3N0
YXRlX3Jlc2V0KENQVU1JUFNTdGF0ZSAqZW52KQogICAgICAgICAgICAgZW52LT50Y3NbaV0uQ1Aw
X1RDSGFsdCA9IDE7CiAgICAgICAgIH0KICAgICAgICAgZW52LT5hY3RpdmVfdGMuQ1AwX1RDSGFs
dCA9IDE7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7
CiAKICAgICAgICAgaWYgKGNzLT5jcHVfaW5kZXggPT0gMCkgewogICAgICAgICAgICAgLyogVlBF
MCBzdGFydHMgdXAgZW5hYmxlZC4gICovCkBAIC0xNjAyMCw3ICsxNjAyMCw3IEBAIHZvaWQgY3B1
X3N0YXRlX3Jlc2V0KENQVU1JUFNTdGF0ZSAqZW52KQogICAgICAgICAgICAgZW52LT5DUDBfVlBF
Q29uZjAgfD0gKDEgPDwgQ1AwVlBFQzBfTVZQKSB8ICgxIDw8IENQMFZQRUMwX1ZQQSk7CiAKICAg
ICAgICAgICAgIC8qIFRDMCBzdGFydHMgdXAgdW5oYWx0ZWQuICAqLwotICAgICAgICAgICAgZW52
LT5oYWx0ZWQgPSAwOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgICAgICAgICBl
bnYtPmFjdGl2ZV90Yy5DUDBfVENIYWx0ID0gMDsKICAgICAgICAgICAgIGVudi0+dGNzWzBdLkNQ
MF9UQ0hhbHQgPSAwOwogICAgICAgICAgICAgLyogV2l0aCB0aHJlYWQgMCBhY3RpdmUuICAqLwpk
aWZmIC0tZ2l0IGEvdGFyZ2V0LW9wZW5yaXNjL2NwdS5oIGIvdGFyZ2V0LW9wZW5yaXNjL2NwdS5o
CmluZGV4IDRjZmQxYzcuLjY0MzcwYTMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1vcGVucmlzYy9jcHUu
aAorKysgYi90YXJnZXQtb3BlbnJpc2MvY3B1LmgKQEAgLTQyMyw5ICs0MjMsNyBAQCBzdGF0aWMg
aW5saW5lIGludCBjcHVfbW11X2luZGV4KENQVU9wZW5SSVNDU3RhdGUgKmVudikKICNkZWZpbmUg
Q1BVX0lOVEVSUlVQVF9USU1FUiAgIENQVV9JTlRFUlJVUFRfVEdUX0lOVF8wCiBzdGF0aWMgaW5s
aW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVT3BlblJJU0NT
dGF0ZSAqZW52ID0gJk9QRU5SSVNDX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfAorICAgIHJldHVybiBjcHUt
PmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9USU1FUik7CiB9CiAKZGlmZiAt
LWdpdCBhL3RhcmdldC1vcGVucmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMgYi90YXJnZXQtb3BlbnJp
c2MvaW50ZXJydXB0X2hlbHBlci5jCmluZGV4IGExNzY0NDEuLjg0NDY0OGYgMTAwNjQ0Ci0tLSBh
L3RhcmdldC1vcGVucmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMKKysrIGIvdGFyZ2V0LW9wZW5yaXNj
L2ludGVycnVwdF9oZWxwZXIuYwpAQCAtMjQsNiArMjQsNyBAQAogdm9pZCBIRUxQRVIocmZlKShD
UFVPcGVuUklTQ1N0YXRlICplbnYpCiB7CiAgICAgT3BlblJJU0NDUFUgKmNwdSA9IG9wZW5yaXNj
X2Vudl9nZXRfY3B1KGVudik7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAjaWZuZGVm
IENPTkZJR19VU0VSX09OTFkKICAgICBpbnQgbmVlZF9mbHVzaF90bGIgPSAoY3B1LT5lbnYuc3Ig
JiAoU1JfU00gfCBTUl9JTUUgfCBTUl9ETUUpKSBeCiAgICAgICAgICAgICAgICAgICAgICAgICAg
KGNwdS0+ZW52LmVzciAmIChTUl9TTSB8IFNSX0lNRSB8IFNSX0RNRSkpOwpAQCAtNTMsNSArNTQs
NSBAQCB2b2lkIEhFTFBFUihyZmUpKENQVU9wZW5SSVNDU3RhdGUgKmVudikKICAgICAgICAgdGxi
X2ZsdXNoKCZjcHUtPmVudiwgMSk7CiAgICAgfQogI2VuZGlmCi0gICAgY3B1LT5lbnYuaW50ZXJy
dXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgY3MtPmludGVycnVwdF9y
ZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOwogfQpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW9w
ZW5yaXNjL3N5c19oZWxwZXIuYyBiL3RhcmdldC1vcGVucmlzYy9zeXNfaGVscGVyLmMKaW5kZXgg
M2M1ZjQ1YS4uY2NjYmMwZSAxMDA2NDQKLS0tIGEvdGFyZ2V0LW9wZW5yaXNjL3N5c19oZWxwZXIu
YworKysgYi90YXJnZXQtb3BlbnJpc2Mvc3lzX2hlbHBlci5jCkBAIC0zMSw2ICszMSw3IEBAIHZv
aWQgSEVMUEVSKG10c3ByKShDUFVPcGVuUklTQ1N0YXRlICplbnYsCiAgICAgaW50IGlkeDsKIAog
ICAgIE9wZW5SSVNDQ1BVICpjcHUgPSBvcGVucmlzY19lbnZfZ2V0X2NwdShlbnYpOworICAgIENQ
VVN0YXRlICpjcyA9IENQVShjcHUpOwogCiAgICAgc3dpdGNoIChzcHIpIHsKICAgICBjYXNlIFRP
X1NQUigwLCAwKTogLyogVlIgKi8KQEAgLTEzMiw3ICsxMzMsNyBAQCB2b2lkIEhFTFBFUihtdHNw
cikoQ1BVT3BlblJJU0NTdGF0ZSAqZW52LAogICAgICAgICAgICAgICAgIGVudi0+dHRtciA9IChy
YiAmIH5UVE1SX0lQKSArIGlwOwogICAgICAgICAgICAgfSBlbHNlIHsgICAgLyogQ2xlYXIgSVAg
Yml0LiAgKi8KICAgICAgICAgICAgICAgICBlbnYtPnR0bXIgPSByYiAmIH5UVE1SX0lQOwotICAg
ICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfVElN
RVI7CisgICAgICAgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJS
VVBUX1RJTUVSOwogICAgICAgICAgICAgfQogCiAgICAgICAgICAgICBjcHVfb3BlbnJpc2NfY291
bnRfdXBkYXRlKGNwdSk7CmRpZmYgLS1naXQgYS90YXJnZXQtcHBjL2NwdS5oIGIvdGFyZ2V0LXBw
Yy9jcHUuaAppbmRleCAyMGY0NTY1Li5mNDVkN2EwIDEwMDY0NAotLS0gYS90YXJnZXQtcHBjL2Nw
dS5oCisrKyBiL3RhcmdldC1wcGMvY3B1LmgKQEAgLTIyMzEsOSArMjIzMSwxMCBAQCBleHRlcm4g
dm9pZCAoKmNwdV9wcGNfaHlwZXJjYWxsKShQb3dlclBDQ1BVICopOwogCiBzdGF0aWMgaW5saW5l
IGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVUFBDU3RhdGUgKmVu
diA9ICZQT1dFUlBDX0NQVShjcHUpLT5lbnY7CisgICAgUG93ZXJQQ0NQVSAqcHBjX2NwdSA9IFBP
V0VSUENfQ1BVKGNwdSk7CisgICAgQ1BVUFBDU3RhdGUgKmVudiA9ICZwcGNfY3B1LT5lbnY7CiAK
LSAgICByZXR1cm4gbXNyX2VlICYmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9IQVJEKTsKKyAgICByZXR1cm4gbXNyX2VlICYmIChjcHUtPmludGVycnVwdF9yZXF1ZXN0
ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKTsKIH0KIAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIK
ZGlmZiAtLWdpdCBhL3RhcmdldC1wcGMvZXhjcF9oZWxwZXIuYyBiL3RhcmdldC1wcGMvZXhjcF9o
ZWxwZXIuYwppbmRleCAwYTFhYzg2Li43OWNlN2JmIDEwMDY0NAotLS0gYS90YXJnZXQtcHBjL2V4
Y3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LXBwYy9leGNwX2hlbHBlci5jCkBAIC02Niw2ICs2Niw3
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBkdW1wX3N5c2NhbGwoQ1BVUFBDU3RhdGUgKmVudikKIHN0
YXRpYyBpbmxpbmUgdm9pZCBwb3dlcnBjX2V4Y3AoUG93ZXJQQ0NQVSAqY3B1LCBpbnQgZXhjcF9t
b2RlbCwgaW50IGV4Y3ApCiB7CiAgICAgQ1BVUFBDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKKyAg
ICBDUFVTdGF0ZSAqY3M7CiAgICAgdGFyZ2V0X3Vsb25nIG1zciwgbmV3X21zciwgdmVjdG9yOwog
ICAgIGludCBzcnIwLCBzcnIxLCBhc3JyMCwgYXNycjE7CiAgICAgaW50IGxwZXMwLCBscGVzMSwg
bGV2OwpAQCAtMTMxLDggKzEzMiw5IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBwb3dlcnBjX2V4Y3Ao
UG93ZXJQQ0NQVSAqY3B1LCBpbnQgZXhjcF9tb2RlbCwgaW50IGV4Y3ApCiAgICAgICAgICAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJNYWNoaW5lIGNoZWNrIHdoaWxlIG5vdCBhbGxvd2VkLiAiCiAg
ICAgICAgICAgICAgICAgICAgICAgICAiRW50ZXJpbmcgY2hlY2tzdG9wIHN0YXRlXG4iKTsKICAg
ICAgICAgICAgIH0KLSAgICAgICAgICAgIGVudi0+aGFsdGVkID0gMTsKLSAgICAgICAgICAgIGVu
di0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgICAgICAg
ICBjcyA9IENQVShjcHUpOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7CisgICAgICAgICAg
ICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgICAg
IH0KICAgICAgICAgaWYgKDApIHsKICAgICAgICAgICAgIC8qIFhYWDogZmluZCBhIHN1aXRhYmxl
IGNvbmRpdGlvbiB0byBlbmFibGUgdGhlIGh5cGVydmlzb3IgbW9kZSAqLwpAQCAtNjYzLDExICs2
NjUsMTIgQEAgdm9pZCBwcGNfaHdfaW50ZXJydXB0KENQVVBQQ1N0YXRlICplbnYpCiB7CiAgICAg
UG93ZXJQQ0NQVSAqY3B1ID0gcHBjX2Vudl9nZXRfY3B1KGVudik7CiAgICAgaW50IGhkaWNlOwot
CiAjaWYgMAorICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOworCiAgICAgcWVtdV9sb2dfbWFz
ayhDUFVfTE9HX0lOVCwgIiVzOiAlcCBwZW5kaW5nICUwOHggcmVxICUwOHggbWUgJWQgZWUgJWRc
biIsCi0gICAgICAgICAgICAgICAgX19mdW5jX18sIGVudiwgZW52LT5wZW5kaW5nX2ludGVycnVw
dHMsCi0gICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCwgKGludCltc3JfbWUs
IChpbnQpbXNyX2VlKTsKKyAgICAgICAgICAgICAgICAgIF9fZnVuY19fLCBlbnYsIGVudi0+cGVu
ZGluZ19pbnRlcnJ1cHRzLAorICAgICAgICAgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0
LCAoaW50KW1zcl9tZSwgKGludCltc3JfZWUpOwogI2VuZGlmCiAgICAgLyogRXh0ZXJuYWwgcmVz
ZXQgKi8KICAgICBpZiAoZW52LT5wZW5kaW5nX2ludGVycnVwdHMgJiAoMSA8PCBQUENfSU5URVJS
VVBUX1JFU0VUKSkgewpAQCAtODA3LDkgKzgxMCwxMiBAQCB2b2lkIGhlbHBlcl9yYWlzZV9leGNl
cHRpb24oQ1BVUFBDU3RhdGUgKmVudiwgdWludDMyX3QgZXhjZXB0aW9uKQogI2lmICFkZWZpbmVk
KENPTkZJR19VU0VSX09OTFkpCiB2b2lkIGhlbHBlcl9zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVu
diwgdGFyZ2V0X3Vsb25nIHZhbCkKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CisKICAgICB2YWwgPSBo
cmVnX3N0b3JlX21zcihlbnYsIHZhbCwgMCk7CiAgICAgaWYgKHZhbCAhPSAwKSB7Ci0gICAgICAg
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgICAg
IGNzID0gQ1BVKHBwY19lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICAgICAgY3MtPmludGVycnVwdF9y
ZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOwogICAgICAgICBoZWxwZXJfcmFpc2VfZXhj
ZXB0aW9uKGVudiwgdmFsKTsKICAgICB9CiB9CkBAIC04MTcsNiArODIzLDggQEAgdm9pZCBoZWxw
ZXJfc3RvcmVfbXNyKENQVVBQQ1N0YXRlICplbnYsIHRhcmdldF91bG9uZyB2YWwpCiBzdGF0aWMg
aW5saW5lIHZvaWQgZG9fcmZpKENQVVBQQ1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBuaXAsIHRh
cmdldF91bG9uZyBtc3IsCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldF91bG9uZyBt
c3JtLCBpbnQga2VlcF9tc3JoKQogeworICAgIENQVVN0YXRlICpjcyA9IENQVShwcGNfZW52X2dl
dF9jcHUoZW52KSk7CisKICNpZiBkZWZpbmVkKFRBUkdFVF9QUEM2NCkKICAgICBpZiAobXNyX2lz
XzY0Yml0KGVudiwgbXNyKSkgewogICAgICAgICBuaXAgPSAodWludDY0X3QpbmlwOwpAQCAtODQx
LDcgKzg0OSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBkb19yZmkoQ1BVUFBDU3RhdGUgKmVudiwg
dGFyZ2V0X3Vsb25nIG5pcCwgdGFyZ2V0X3Vsb25nIG1zciwKICAgICAvKiBObyBuZWVkIHRvIHJh
aXNlIGFuIGV4Y2VwdGlvbiBoZXJlLAogICAgICAqIGFzIHJmaSBpcyBhbHdheXMgdGhlIGxhc3Qg
aW5zbiBvZiBhIFRCCiAgICAgICovCi0gICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVf
SU5URVJSVVBUX0VYSVRUQjsKKyAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVS
UlVQVF9FWElUVEI7CiB9CiAKIHZvaWQgaGVscGVyX3JmaShDUFVQUENTdGF0ZSAqZW52KQpkaWZm
IC0tZ2l0IGEvdGFyZ2V0LXBwYy9oZWxwZXJfcmVncy5oIGIvdGFyZ2V0LXBwYy9oZWxwZXJfcmVn
cy5oCmluZGV4IDNjOTg4NTAuLmE2ZDVlMmYgMTAwNjQ0Ci0tLSBhL3RhcmdldC1wcGMvaGVscGVy
X3JlZ3MuaAorKysgYi90YXJnZXQtcHBjL2hlbHBlcl9yZWdzLmgKQEAgLTY4LDEwICs2OCwxMyBA
QCBzdGF0aWMgaW5saW5lIGludCBocmVnX3N0b3JlX21zcihDUFVQUENTdGF0ZSAqZW52LCB0YXJn
ZXRfdWxvbmcgdmFsdWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgYWx0
ZXJfaHYpCiB7CiAgICAgaW50IGV4Y3A7CisjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkK
KyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUocHBjX2Vudl9nZXRfY3B1KGVudikpOworI2VuZGlmCiAK
ICAgICBleGNwID0gMDsKICAgICB2YWx1ZSAmPSBlbnYtPm1zcl9tYXNrOwotI2lmICFkZWZpbmVk
IChDT05GSUdfVVNFUl9PTkxZKQorI2lmICFkZWZpbmVkKENPTkZJR19VU0VSX09OTFkpCiAgICAg
aWYgKCFhbHRlcl9odikgewogICAgICAgICAvKiBtdG1zciBjYW5ub3QgYWx0ZXIgdGhlIGh5cGVy
dmlzb3Igc3RhdGUgKi8KICAgICAgICAgdmFsdWUgJj0gfk1TUl9IVkI7CkBAIC04Miw3ICs4NSw3
IEBAIHN0YXRpYyBpbmxpbmUgaW50IGhyZWdfc3RvcmVfbXNyKENQVVBQQ1N0YXRlICplbnYsIHRh
cmdldF91bG9uZyB2YWx1ZSwKICAgICAgICAgLyogRmx1c2ggYWxsIHRsYiB3aGVuIGNoYW5naW5n
IHRyYW5zbGF0aW9uIG1vZGUgKi8KICAgICAgICAgdGxiX2ZsdXNoKGVudiwgMSk7CiAgICAgICAg
IGV4Y3AgPSBQT1dFUlBDX0VYQ1BfTk9ORTsKLSAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVz
dCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0
IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOwogICAgIH0KICAgICBpZiAodW5saWtlbHkoKGVudi0+
ZmxhZ3MgJiBQT1dFUlBDX0ZMQUdfVEdQUikgJiYKICAgICAgICAgICAgICAgICAgKCh2YWx1ZSBe
IGVudi0+bXNyKSAmICgxIDw8IE1TUl9UR1BSKSkpKSB7CkBAIC05NiwxMCArOTksMTAgQEAgc3Rh
dGljIGlubGluZSBpbnQgaHJlZ19zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVudiwgdGFyZ2V0X3Vs
b25nIHZhbHVlLAogI2VuZGlmCiAgICAgZW52LT5tc3IgPSB2YWx1ZTsKICAgICBocmVnX2NvbXB1
dGVfaGZsYWdzKGVudik7Ci0jaWYgIWRlZmluZWQgKENPTkZJR19VU0VSX09OTFkpCisjaWYgIWRl
ZmluZWQoQ09ORklHX1VTRVJfT05MWSkKICAgICBpZiAodW5saWtlbHkobXNyX3BvdyA9PSAxKSkg
ewogICAgICAgICBpZiAoKCplbnYtPmNoZWNrX3BvdykoZW52KSkgewotICAgICAgICAgICAgZW52
LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICBl
eGNwID0gRVhDUF9IQUxURUQ7CiAgICAgICAgIH0KICAgICB9CmRpZmYgLS1naXQgYS90YXJnZXQt
cHBjL2t2bS5jIGIvdGFyZ2V0LXBwYy9rdm0uYwppbmRleCA4ZTY0NDE2Li5mMGM0ODQzIDEwMDY0
NAotLS0gYS90YXJnZXQtcHBjL2t2bS5jCisrKyBiL3RhcmdldC1wcGMva3ZtLmMKQEAgLTc2MCw3
ICs3NjAsNyBAQCB2b2lkIGt2bV9hcmNoX3ByZV9ydW4oQ1BVU3RhdGUgKmNzLCBzdHJ1Y3Qga3Zt
X3J1biAqcnVuKQogICAgICAqIGludGVycnVwdCwgcmVzZXQsIGV0YykgaW4gUFBDLXNwZWNpZmlj
IGVudi0+aXJxX2lucHV0X3N0YXRlLiAqLwogICAgIGlmICghY2FwX2ludGVycnVwdF9sZXZlbCAm
JgogICAgICAgICBydW4tPnJlYWR5X2Zvcl9pbnRlcnJ1cHRfaW5qZWN0aW9uICYmCi0gICAgICAg
IChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgICAg
ICAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAg
ICAoZW52LT5pcnFfaW5wdXRfc3RhdGUgJiAoMTw8UFBDX0lOUFVUX0lOVCkpKQogICAgIHsKICAg
ICAgICAgLyogRm9yIG5vdyBLVk0gZGlzcmVnYXJkcyB0aGUgJ2lycScgYXJndW1lbnQuIEhvd2V2
ZXIsIGluIHRoZQpAQCAtNzkxLDE0ICs3OTEsMTYgQEAgdm9pZCBrdm1fYXJjaF9wb3N0X3J1bihD
UFVTdGF0ZSAqY3B1LCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogCiBpbnQga3ZtX2FyY2hfcHJvY2Vz
c19hc3luY19ldmVudHMoQ1BVU3RhdGUgKmNzKQogewotICAgIFBvd2VyUENDUFUgKmNwdSA9IFBP
V0VSUENfQ1BVKGNzKTsKLSAgICByZXR1cm4gY3B1LT5lbnYuaGFsdGVkOworICAgIHJldHVybiBj
cy0+aGFsdGVkOwogfQogCi1zdGF0aWMgaW50IGt2bXBwY19oYW5kbGVfaGFsdChDUFVQUENTdGF0
ZSAqZW52KQorc3RhdGljIGludCBrdm1wcGNfaGFuZGxlX2hhbHQoUG93ZXJQQ0NQVSAqY3B1KQog
ewotICAgIGlmICghKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQp
ICYmIChtc3JfZWUpKSB7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUoY3B1KTsKKyAgICBDUFVQUENTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OworCisgICAg
aWYgKCEoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJiAobXNy
X2VlKSkgeworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNlcHRpb25f
aW5kZXggPSBFWENQX0hMVDsKICAgICB9CiAKQEAgLTg0MCw3ICs4NDIsNyBAQCBpbnQga3ZtX2Fy
Y2hfaGFuZGxlX2V4aXQoQ1BVU3RhdGUgKmNzLCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogICAgICAg
ICBicmVhazsKICAgICBjYXNlIEtWTV9FWElUX0hMVDoKICAgICAgICAgZHByaW50ZigiaGFuZGxl
IGhhbHRcbiIpOwotICAgICAgICByZXQgPSBrdm1wcGNfaGFuZGxlX2hhbHQoZW52KTsKKyAgICAg
ICAgcmV0ID0ga3ZtcHBjX2hhbmRsZV9oYWx0KGNwdSk7CiAgICAgICAgIGJyZWFrOwogI2lmZGVm
IENPTkZJR19QU0VSSUVTCiAgICAgY2FzZSBLVk1fRVhJVF9QQVBSX0hDQUxMOgpkaWZmIC0tZ2l0
IGEvdGFyZ2V0LXBwYy90cmFuc2xhdGUuYyBiL3RhcmdldC1wcGMvdHJhbnNsYXRlLmMKaW5kZXgg
Zjg4NjQ0MS4uZDhjMmRkMSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXBwYy90cmFuc2xhdGUuYworKysg
Yi90YXJnZXQtcHBjL3RyYW5zbGF0ZS5jCkBAIC0zMTAyLDcgKzMxMDIsOCBAQCBzdGF0aWMgdm9p
ZCBnZW5fc3luYyhEaXNhc0NvbnRleHQgKmN0eCkKIHN0YXRpYyB2b2lkIGdlbl93YWl0KERpc2Fz
Q29udGV4dCAqY3R4KQogewogICAgIFRDR3ZfaTMyIHQwID0gdGNnX3RlbXBfbmV3X2kzMigpOwot
ICAgIHRjZ19nZW5fc3RfaTMyKHQwLCBjcHVfZW52LCBvZmZzZXRvZihDUFVQUENTdGF0ZSwgaGFs
dGVkKSk7CisgICAgdGNnX2dlbl9zdF9pMzIodDAsIGNwdV9lbnYsCisgICAgICAgICAgICAgICAg
ICAgLW9mZnNldG9mKFBvd2VyUENDUFUsIGVudikgKyBvZmZzZXRvZihDUFVTdGF0ZSwgaGFsdGVk
KSk7CiAgICAgdGNnX3RlbXBfZnJlZV9pMzIodDApOwogICAgIC8qIFN0b3AgdHJhbnNsYXRpb24s
IGFzIHRoZSBDUFUgaXMgc3VwcG9zZWQgdG8gc2xlZXAgZnJvbSBub3cgKi8KICAgICBnZW5fZXhj
ZXB0aW9uX2VycihjdHgsIEVYQ1BfSExULCAxKTsKZGlmZiAtLWdpdCBhL3RhcmdldC1zMzkweC9j
cHUuYyBiL3RhcmdldC1zMzkweC9jcHUuYwppbmRleCBiNzQ2NTQ3Li43MzhhMGFkIDEwMDY0NAot
LS0gYS90YXJnZXQtczM5MHgvY3B1LmMKKysrIGIvdGFyZ2V0LXMzOTB4L2NwdS5jCkBAIC04MCwx
MCArODAsMTAgQEAgc3RhdGljIHZvaWQgczM5MF9jcHVfcmVzZXQoQ1BVU3RhdGUgKnMpCiAgICAg
ZW52LT5jcmVnc1swXSA9IENSMF9SRVNFVDsKICAgICBlbnYtPmNyZWdzWzE0XSA9IENSMTRfUkVT
RVQ7CiAgICAgLyogc2V0IGhhbHRlZCB0byAxIHRvIG1ha2Ugc3VyZSB3ZSBjYW4gYWRkIHRoZSBj
cHUgaW4KLSAgICAgKiBzMzkwX2lwbF9jcHUgY29kZSwgd2hlcmUgZW52LT5oYWx0ZWQgaXMgc2V0
IGJhY2sgdG8gMAorICAgICAqIHMzOTBfaXBsX2NwdSBjb2RlLCB3aGVyZSBDUFVTdGF0ZTo6aGFs
dGVkIGlzIHNldCBiYWNrIHRvIDAKICAgICAgKiBhZnRlciBpbmNyZW1lbnRpbmcgdGhlIGNwdSBj
b3VudGVyICovCiAjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkKLSAgICBlbnYtPmhhbHRl
ZCA9IDE7CisgICAgcy0+aGFsdGVkID0gMTsKICNlbmRpZgogICAgIHRsYl9mbHVzaChlbnYsIDEp
OwogfQpAQCAtMTI5LDEwICsxMjksMTAgQEAgc3RhdGljIHZvaWQgczM5MF9jcHVfaW5pdGZuKE9i
amVjdCAqb2JqKQogICAgIGVudi0+dG9kX2Jhc2V0aW1lID0gMDsKICAgICBlbnYtPnRvZF90aW1l
ciA9IHFlbXVfbmV3X3RpbWVyX25zKHZtX2Nsb2NrLCBzMzkweF90b2RfdGltZXIsIGNwdSk7CiAg
ICAgZW52LT5jcHVfdGltZXIgPSBxZW11X25ld190aW1lcl9ucyh2bV9jbG9jaywgczM5MHhfY3B1
X3RpbWVyLCBjcHUpOwotICAgIC8qIHNldCBlbnYtPmhhbHRlZCBzdGF0ZSB0byAxIHRvIGF2b2lk
IGRlY3JlbWVudGluZyB0aGUgcnVubmluZworICAgIC8qIHNldCBDUFVTdGF0ZTo6aGFsdGVkIHN0
YXRlIHRvIDEgdG8gYXZvaWQgZGVjcmVtZW50aW5nIHRoZSBydW5uaW5nCiAgICAgICogY3B1IGNv
dW50ZXIgaW4gczM5MF9jcHVfcmVzZXQgdG8gYSBuZWdhdGl2ZSBudW1iZXIgYXQKICAgICAgKiBp
bml0aWFsIGlwbCAqLwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcy0+aGFsdGVkID0gMTsK
ICNlbmRpZgogICAgIGVudi0+Y3B1X251bSA9IGNwdV9udW0rKzsKICAgICBlbnYtPmV4dF9pbmRl
eCA9IC0xOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXMzOTB4L2NwdS5oIGIvdGFyZ2V0LXMzOTB4L2Nw
dS5oCmluZGV4IGU0NTBkYjcuLjg5N2FjNTkgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zMzkweC9jcHUu
aAorKysgYi90YXJnZXQtczM5MHgvY3B1LmgKQEAgLTEwMzksOSArMTAzOSwxMCBAQCBzdGF0aWMg
aW5saW5lIHZvaWQgY3B1X2luamVjdF9jcndfbWNoayhTMzkwQ1BVICpjcHUpCiAKIHN0YXRpYyBp
bmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVTMzkwWFN0
YXRlICplbnYgPSAmUzM5MF9DUFUoY3B1KS0+ZW52OworICAgIFMzOTBDUFUgKnMzOTBfY3B1ID0g
UzM5MF9DUFUoY3B1KTsKKyAgICBDUFVTMzkwWFN0YXRlICplbnYgPSAmczM5MF9jcHUtPmVudjsK
IAotICAgIHJldHVybiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFS
RCkgJiYKKyAgICByZXR1cm4gKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBU
X0hBUkQpICYmCiAgICAgICAgIChlbnYtPnBzdy5tYXNrICYgUFNXX01BU0tfRVhUKTsKIH0KIApk
aWZmIC0tZ2l0IGEvdGFyZ2V0LXMzOTB4L2hlbHBlci5jIGIvdGFyZ2V0LXMzOTB4L2hlbHBlci5j
CmluZGV4IDExODNiNDUuLmM4OGE1ODcgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zMzkweC9oZWxwZXIu
YworKysgYi90YXJnZXQtczM5MHgvaGVscGVyLmMKQEAgLTQzNyw2ICs0MzcsNyBAQCB2b2lkIGxv
YWRfcHN3KENQVVMzOTBYU3RhdGUgKmVudiwgdWludDY0X3QgbWFzaywgdWludDY0X3QgYWRkcikK
IHsKICAgICBpZiAobWFzayAmIFBTV19NQVNLX1dBSVQpIHsKICAgICAgICAgUzM5MENQVSAqY3B1
ID0gczM5MF9lbnZfZ2V0X2NwdShlbnYpOworICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1
KTsKICAgICAgICAgaWYgKCEobWFzayAmIChQU1dfTUFTS19JTyB8IFBTV19NQVNLX0VYVCB8IFBT
V19NQVNLX01DSEVDSykpKSB7CiAgICAgICAgICAgICBpZiAoczM5MF9kZWxfcnVubmluZ19jcHUo
Y3B1KSA9PSAwKSB7CiAjaWZuZGVmIENPTkZJR19VU0VSX09OTFkKQEAgLTQ0NCw3ICs0NDUsNyBA
QCB2b2lkIGxvYWRfcHN3KENQVVMzOTBYU3RhdGUgKmVudiwgdWludDY0X3QgbWFzaywgdWludDY0
X3QgYWRkcikKICNlbmRpZgogICAgICAgICAgICAgfQogICAgICAgICB9Ci0gICAgICAgIGVudi0+
aGFsdGVkID0gMTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgIGVudi0+ZXhjZXB0
aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiAgICAgfQogCkBAIC03MzksNiArNzQwLDcgQEAgc3RhdGlj
IHZvaWQgZG9fbWNoa19pbnRlcnJ1cHQoQ1BVUzM5MFhTdGF0ZSAqZW52KQogdm9pZCBkb19pbnRl
cnJ1cHQoQ1BVUzM5MFhTdGF0ZSAqZW52KQogewogICAgIFMzOTBDUFUgKmNwdSA9IHMzOTBfZW52
X2dldF9jcHUoZW52KTsKKyAgICBDUFVTdGF0ZSAqY3M7CiAKICAgICBxZW11X2xvZ19tYXNrKENQ
VV9MT0dfSU5ULCAiJXM6ICVkIGF0IHBjPSUiIFBSSXg2NCAiXG4iLAogICAgICAgICAgICAgICAg
ICAgX19mdW5jX18sIGVudi0+ZXhjZXB0aW9uX2luZGV4LCBlbnYtPnBzdy5hZGRyKTsKQEAgLTc5
Nyw3ICs3OTksOCBAQCB2b2lkIGRvX2ludGVycnVwdChDUFVTMzkwWFN0YXRlICplbnYpCiAgICAg
ZW52LT5leGNlcHRpb25faW5kZXggPSAtMTsKIAogICAgIGlmICghZW52LT5wZW5kaW5nX2ludCkg
ewotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBUkQ7
CisgICAgICAgIGNzID0gQ1BVKHMzOTBfZW52X2dldF9jcHUoZW52KSk7CisgICAgICAgIGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9IQVJEOwogICAgIH0KIH0KIApkaWZm
IC0tZ2l0IGEvdGFyZ2V0LXNoNC9jcHUuaCBiL3RhcmdldC1zaDQvY3B1LmgKaW5kZXggZjgwNTc3
OC4uNDk2NjM1NSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXNoNC9jcHUuaAorKysgYi90YXJnZXQtc2g0
L2NwdS5oCkBAIC0zNjksOSArMzY5LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGNwdV9nZXRfdGJf
Y3B1X3N0YXRlKENQVVNINFN0YXRlICplbnYsIHRhcmdldF91bG9uZyAqcGMsCiAKIHN0YXRpYyBp
bmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVTSDRTdGF0
ZSAqZW52ID0gJlNVUEVSSF9DUFUoY3B1KS0+ZW52OwotCi0gICAgcmV0dXJuIGVudi0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CisgICAgcmV0dXJuIGNwdS0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CiB9CiAKICNpbmNsdWRlICJleGVjL2V4
ZWMtYWxsLmgiCmRpZmYgLS1naXQgYS90YXJnZXQtc2g0L2hlbHBlci5jIGIvdGFyZ2V0LXNoNC9o
ZWxwZXIuYwppbmRleCBkZGViYzc4Li5mZDRlZmVlIDEwMDY0NAotLS0gYS90YXJnZXQtc2g0L2hl
bHBlci5jCisrKyBiL3RhcmdldC1zaDQvaGVscGVyLmMKQEAgLTc4LDkgKzc4LDEwIEBAIGludCBj
cHVfc2g0X2lzX2NhY2hlZChDUFVTSDRTdGF0ZSAqIGVudiwgdGFyZ2V0X3Vsb25nIGFkZHIpCiAj
ZGVmaW5lIE1NVV9EQUREUl9FUlJPUl9SRUFEICAgICAoLTEyKQogI2RlZmluZSBNTVVfREFERFJf
RVJST1JfV1JJVEUgICAgKC0xMykKIAotdm9pZCBkb19pbnRlcnJ1cHQoQ1BVU0g0U3RhdGUgKiBl
bnYpCit2b2lkIGRvX2ludGVycnVwdChDUFVTSDRTdGF0ZSAqZW52KQogewotICAgIGludCBkb19p
cnEgPSBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOworICAgIENQ
VVN0YXRlICpjcyA9IENQVShzaF9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICBpbnQgZG9faXJxID0g
Y3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOwogICAgIGludCBkb19l
eHAsIGlycV92ZWN0b3IgPSBlbnYtPmV4Y2VwdGlvbl9pbmRleDsKIAogICAgIC8qIHByaW9yaXRp
emUgZXhjZXB0aW9ucyBvdmVyIGludGVycnVwdHMgKi8KZGlmZiAtLWdpdCBhL3RhcmdldC1zaDQv
b3BfaGVscGVyLmMgYi90YXJnZXQtc2g0L29wX2hlbHBlci5jCmluZGV4IDA5ZTNkMjMuLmU5NTVl
ODEgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zaDQvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LXNoNC9v
cF9oZWxwZXIuYwpAQCAtMTAyLDcgKzEwMiw5IEBAIHZvaWQgaGVscGVyX2RlYnVnKENQVVNINFN0
YXRlICplbnYpCiAKIHZvaWQgaGVscGVyX3NsZWVwKENQVVNINFN0YXRlICplbnYpCiB7Ci0gICAg
ZW52LT5oYWx0ZWQgPSAxOworICAgIENQVVN0YXRlICpjcyA9IENQVShzaF9lbnZfZ2V0X2NwdShl
bnYpKTsKKworICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgIGVudi0+aW5fc2xlZXAgPSAxOwogICAg
IHJhaXNlX2V4Y2VwdGlvbihlbnYsIEVYQ1BfSExULCAwKTsKIH0KZGlmZiAtLWdpdCBhL3Rhcmdl
dC1zcGFyYy9jcHUuaCBiL3RhcmdldC1zcGFyYy9jcHUuaAppbmRleCBhMmYyY2M4Li44YTJmOGRm
IDEwMDY0NAotLS0gYS90YXJnZXQtc3BhcmMvY3B1LmgKKysrIGIvdGFyZ2V0LXNwYXJjL2NwdS5o
CkBAIC03NjIsOSArNzYyLDEwIEBAIHN0YXRpYyBpbmxpbmUgYm9vbCB0Yl9hbV9lbmFibGVkKGlu
dCB0Yl9mbGFncykKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAq
Y3B1KQogewotICAgIENQVVNQQVJDU3RhdGUgKmVudjEgPSAmU1BBUkNfQ1BVKGNwdSktPmVudjsK
KyAgICBTUEFSQ0NQVSAqc3BhcmNfY3B1ID0gU1BBUkNfQ1BVKGNwdSk7CisgICAgQ1BVU1BBUkNT
dGF0ZSAqZW52MSA9ICZzcGFyY19jcHUtPmVudjsKIAotICAgIHJldHVybiAoZW52MS0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCisgICAgcmV0dXJuIChjcHUtPmlu
dGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAgICAgICBjcHVf
aW50ZXJydXB0c19lbmFibGVkKGVudjEpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtc3BhcmMv
aGVscGVyLmMgYi90YXJnZXQtc3BhcmMvaGVscGVyLmMKaW5kZXggNThlN2VmZS4uNTdjMjBhZiAx
MDA2NDQKLS0tIGEvdGFyZ2V0LXNwYXJjL2hlbHBlci5jCisrKyBiL3RhcmdldC1zcGFyYy9oZWxw
ZXIuYwpAQCAtMjI5LDcgKzIyOSw5IEBAIHRhcmdldF91bG9uZyBoZWxwZXJfdHN1YmNjdHYoQ1BV
U1BBUkNTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgc3JjMSwKICNpZm5kZWYgVEFSR0VUX1NQQVJD
NjQKIHZvaWQgaGVscGVyX3Bvd2VyX2Rvd24oQ1BVU1BBUkNTdGF0ZSAqZW52KQogewotICAgIGVu
di0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoc3BhcmNfZW52X2dldF9jcHUo
ZW52KSk7CisKKyAgICBjcy0+aGFsdGVkID0gMTsKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9
IEVYQ1BfSExUOwogICAgIGVudi0+cGMgPSBlbnYtPm5wYzsKICAgICBlbnYtPm5wYyA9IGVudi0+
cGMgKyA0OwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXVuaWNvcmUzMi9jcHUuaCBiL3RhcmdldC11bmlj
b3JlMzIvY3B1LmgKaW5kZXggYWU5YTlkNi4uNThmMWYyMCAxMDA2NDQKLS0tIGEvdGFyZ2V0LXVu
aWNvcmUzMi9jcHUuaAorKysgYi90YXJnZXQtdW5pY29yZTMyL2NwdS5oCkBAIC0xODEsOSArMTgx
LDcgQEAgdm9pZCBzd2l0Y2hfbW9kZShDUFVVbmlDb3JlMzJTdGF0ZSAqLCBpbnQpOwogCiBzdGF0
aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVVW5p
Q29yZTMyU3RhdGUgKmVudiA9ICZVTklDT1JFMzJfQ1BVKGNwdSktPmVudjsKLQotICAgIHJldHVy
biBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYKKyAgICByZXR1cm4gY3B1LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmCiAgICAgICAgIChDUFVfSU5URVJSVVBUX0hBUkQgfCBDUFVfSU5URVJSVVBUX0VYSVRU
Qik7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jIGIvdGFyZ2V0
LXVuaWNvcmUzMi9zb2Z0bW11LmMKaW5kZXggZmMyNzEwMC4uMWM0YzdmNSAxMDA2NDQKLS0tIGEv
dGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11LmMKKysrIGIvdGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11
LmMKQEAgLTc0LDYgKzc0LDcgQEAgdm9pZCBzd2l0Y2hfbW9kZShDUFVVbmlDb3JlMzJTdGF0ZSAq
ZW52LCBpbnQgbW9kZSkKIC8qIEhhbmRsZSBhIENQVSBleGNlcHRpb24uICAqLwogdm9pZCBkb19p
bnRlcnJ1cHQoQ1BVVW5pQ29yZTMyU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBD
UFUodWMzMl9lbnZfZ2V0X2NwdShlbnYpKTsKICAgICB1aW50MzJfdCBhZGRyOwogICAgIGludCBu
ZXdfbW9kZTsKIApAQCAtMTEyLDcgKzExMyw3IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVVVuaUNv
cmUzMlN0YXRlICplbnYpCiAgICAgLyogVGhlIFBDIGFscmVhZHkgcG9pbnRzIHRvIHRoZSBwcm9w
ZXIgaW5zdHJ1Y3Rpb24uICAqLwogICAgIGVudi0+cmVnc1szMF0gPSBlbnYtPnJlZ3NbMzFdOwog
ICAgIGVudi0+cmVnc1szMV0gPSBhZGRyOwotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0g
Q1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9J
TlRFUlJVUFRfRVhJVFRCOwogfQogCiBzdGF0aWMgaW50IGdldF9waHlzX2FkZHJfdWN2MihDUFVV
bmlDb3JlMzJTdGF0ZSAqZW52LCB1aW50MzJfdCBhZGRyZXNzLApkaWZmIC0tZ2l0IGEvdGFyZ2V0
LXh0ZW5zYS9vcF9oZWxwZXIuYyBiL3RhcmdldC14dGVuc2Evb3BfaGVscGVyLmMKaW5kZXggMzgx
M2E3Mi4uMTAzNzEwMSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXh0ZW5zYS9vcF9oZWxwZXIuYworKysg
Yi90YXJnZXQteHRlbnNhL29wX2hlbHBlci5jCkBAIC0zNzMsNiArMzczLDggQEAgdm9pZCBIRUxQ
RVIoZHVtcF9zdGF0ZSkoQ1BVWHRlbnNhU3RhdGUgKmVudikKIAogdm9pZCBIRUxQRVIod2FpdGkp
KENQVVh0ZW5zYVN0YXRlICplbnYsIHVpbnQzMl90IHBjLCB1aW50MzJfdCBpbnRsZXZlbCkKIHsK
KyAgICBDUFVTdGF0ZSAqY3B1OworCiAgICAgZW52LT5wYyA9IHBjOwogICAgIGVudi0+c3JlZ3Nb
UFNdID0gKGVudi0+c3JlZ3NbUFNdICYgflBTX0lOVExFVkVMKSB8CiAgICAgICAgIChpbnRsZXZl
bCA8PCBQU19JTlRMRVZFTF9TSElGVCk7CkBAIC0zODIsOCArMzg0LDkgQEAgdm9pZCBIRUxQRVIo
d2FpdGkpKENQVVh0ZW5zYVN0YXRlICplbnYsIHVpbnQzMl90IHBjLCB1aW50MzJfdCBpbnRsZXZl
bCkKICAgICAgICAgcmV0dXJuOwogICAgIH0KIAorICAgIGNwdSA9IENQVSh4dGVuc2FfZW52X2dl
dF9jcHUoZW52KSk7CiAgICAgZW52LT5oYWx0X2Nsb2NrID0gcWVtdV9nZXRfY2xvY2tfbnModm1f
Y2xvY2spOwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcHUtPmhhbHRlZCA9IDE7CiAgICAg
aWYgKHh0ZW5zYV9vcHRpb25fZW5hYmxlZChlbnYtPmNvbmZpZywgWFRFTlNBX09QVElPTl9USU1F
Ul9JTlRFUlJVUFQpKSB7CiAgICAgICAgIHh0ZW5zYV9yZWFybV9jY29tcGFyZV90aW1lcihlbnYp
OwogICAgIH0KZGlmZiAtLWdpdCBhL3RyYW5zbGF0ZS1hbGwuYyBiL3RyYW5zbGF0ZS1hbGwuYwpp
bmRleCBiNTBmYjg5Li5hZGE4ZDdlIDEwMDY0NAotLS0gYS90cmFuc2xhdGUtYWxsLmMKKysrIGIv
dHJhbnNsYXRlLWFsbC5jCkBAIC0xMDc3LDggKzEwNzcsOCBAQCB2b2lkIHRiX2ludmFsaWRhdGVf
cGh5c19wYWdlX3JhbmdlKHRiX3BhZ2VfYWRkcl90IHN0YXJ0LCB0Yl9wYWdlX2FkZHJfdCBlbmQs
CiAgICAgICAgICAgICB0Yl9waHlzX2ludmFsaWRhdGUodGIsIC0xKTsKICAgICAgICAgICAgIGlm
IChjcHUgIT0gTlVMTCkgewogICAgICAgICAgICAgICAgIGNwdS0+Y3VycmVudF90YiA9IHNhdmVk
X3RiOwotICAgICAgICAgICAgICAgIGlmIChlbnYgJiYgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
JiBjcHUtPmN1cnJlbnRfdGIpIHsKLSAgICAgICAgICAgICAgICAgICAgY3B1X2ludGVycnVwdChl
bnYsIGVudi0+aW50ZXJydXB0X3JlcXVlc3QpOworICAgICAgICAgICAgICAgIGlmIChlbnYgJiYg
Y3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmJiBjcHUtPmN1cnJlbnRfdGIpIHsKKyAgICAgICAgICAg
ICAgICAgICAgY3B1X2ludGVycnVwdChlbnYsIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QpOwogICAg
ICAgICAgICAgICAgIH0KICAgICAgICAgICAgIH0KICAgICAgICAgfQpAQCAtMTQ1Niw4ICsxNDU2
LDggQEAgc3RhdGljIHZvaWQgdGNnX2hhbmRsZV9pbnRlcnJ1cHQoQ1BVQXJjaFN0YXRlICplbnYs
IGludCBtYXNrKQogICAgIENQVVN0YXRlICpjcHUgPSBFTlZfR0VUX0NQVShlbnYpOwogICAgIGlu
dCBvbGRfbWFzazsKIAotICAgIG9sZF9tYXNrID0gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdDsKLSAg
ICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IG1hc2s7CisgICAgb2xkX21hc2sgPSBjcHUtPmlu
dGVycnVwdF9yZXF1ZXN0OworICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgfD0gbWFzazsKIAog
ICAgIC8qCiAgICAgICogSWYgY2FsbGVkIGZyb20gaW90aHJlYWQgY29udGV4dCwgd2FrZSB0aGUg
dGFyZ2V0IGNwdSBpbgpAQCAtMTYyNSw3ICsxNjI1LDcgQEAgdm9pZCBjcHVfaW50ZXJydXB0KENQ
VUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKIHsKICAgICBDUFVTdGF0ZSAqY3B1ID0gRU5WX0dF
VF9DUFUoZW52KTsKIAotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gbWFzazsKKyAgICBj
cHUtPmludGVycnVwdF9yZXF1ZXN0IHw9IG1hc2s7CiAgICAgY3B1X3VubGlua190YihjcHUpOwog
fQogCmRpZmYgLS1naXQgYS94ZW4tYWxsLmMgYi94ZW4tYWxsLmMKaW5kZXggMTEwZjk1OC4uOGMw
NTg0MyAxMDA2NDQKLS0tIGEveGVuLWFsbC5jCisrKyBiL3hlbi1hbGwuYwpAQCAtNTc4LDE2ICs1
NzgsMTggQEAgdm9pZCBxbXBfeGVuX3NldF9nbG9iYWxfZGlydHlfbG9nKGJvb2wgZW5hYmxlLCBF
cnJvciAqKmVycnApCiAKIHN0YXRpYyB2b2lkIHhlbl9yZXNldF92Y3B1KHZvaWQgKm9wYXF1ZSkK
IHsKLSAgICBDUFVBcmNoU3RhdGUgKmVudiA9IG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3B1ID0g
b3BhcXVlOwogCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNwdS0+aGFsdGVkID0gMTsKIH0K
IAogdm9pZCB4ZW5fdmNwdV9pbml0KHZvaWQpCiB7CiAgICAgaWYgKGZpcnN0X2NwdSAhPSBOVUxM
KSB7Ci0gICAgICAgIHFlbXVfcmVnaXN0ZXJfcmVzZXQoeGVuX3Jlc2V0X3ZjcHUsIGZpcnN0X2Nw
dSk7Ci0gICAgICAgIHhlbl9yZXNldF92Y3B1KGZpcnN0X2NwdSk7CisgICAgICAgIENQVVN0YXRl
ICpjcHUgPSBFTlZfR0VUX0NQVShmaXJzdF9jcHUpOworCisgICAgICAgIHFlbXVfcmVnaXN0ZXJf
cmVzZXQoeGVuX3Jlc2V0X3ZjcHUsIGNwdSk7CisgICAgICAgIHhlbl9yZXNldF92Y3B1KGNwdSk7
CiAgICAgfQogICAgIC8qIGlmIHJ0Y19jbG9jayBpcyBsZWZ0IHRvIGRlZmF1bHQgKGhvc3RfY2xv
Y2spLCBkaXNhYmxlIGl0ICovCiAgICAgaWYgKHJ0Y19jbG9jayA9PSBob3N0X2Nsb2NrKSB7Ci0t
IAoxLjcuMTAuNAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 25 18:46:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 18:46: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 1UA34L-0003gL-PU; Mon, 25 Feb 2013 18:46:33 +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 1UA34K-0003gD-4r
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 18:46:32 +0000
Received: from [85.158.137.99:19581] by server-12.bemta-3.messagelabs.com id
	3E/DB-05889-781BB215; Mon, 25 Feb 2013 18:46:31 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361817966!13283292!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3328 invoked from network); 25 Feb 2013 18:46:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 18:46:07 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id 00834A4F28;
	Mon, 25 Feb 2013 19:46:01 +0100 (CET)
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>
To: qemu-devel@nongnu.org
Date: Mon, 25 Feb 2013 19:45:49 +0100
Message-Id: <1361817954-8984-3-git-send-email-afaerber@suse.de>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361817954-8984-1-git-send-email-afaerber@suse.de>
References: <1361817954-8984-1-git-send-email-afaerber@suse.de>
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>, Guan Xuetao <gxt@mprc.pku.edu.cn>,
	"open list:Overall" <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, Alexander Graf <agraf@suse.de>,
	Fabien Chouteau <chouteau@adacore.com>, Blue Swirl <blauwirbel@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>, Michael Walle <michael@walle.cc>,
	"open list:X86" <xen-devel@lists.xensource.com>,
	"open list:e500" <qemu-ppc@nongnu.org>, Paul Brook <paul@codesourcery.com>,
	Scott Wood <scottwood@freescale.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Richard Henderson <rth@twiddle.net>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
	Aurelien Jarno <aurelien@aurel32.net>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [Xen-devel] [PATCH qom-cpu v2 2/7] cpu: Move halted and
	interrupt_request fields to CPUState
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Qm90aCBmaWVsZHMgYXJlIHVzZWQgaW4gVk1TdGF0ZSwgdGh1cyBuZWVkIHRvIGJlIG1vdmVkIHRv
Z2V0aGVyLgpFeHBsaWNpdGx5IHplcm8gdGhlbSBvbiByZXNldCBzaW5jZSB0aGV5IHdlcmUgbG9j
YXRlZCBiZWZvcmUKYnJlYWtwb2ludHMuCgpQYXNzIFBvd2VyUENDUFUgdG8ga3ZtcHBjX2hhbmRs
ZV9oYWx0KCkuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZWFzIEbDpHJiZXIgPGFmYWVyYmVyQHN1c2Uu
ZGU+Ci0tLQogY3B1LWV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMzQgKysrKysr
KysrKysrLS0tLS0tLS0tLS0tCiBjcHVzLmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgNCArLS0KIGV4ZWMuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDE2ICsrKysr
KystLS0tLQogZ2Ric3R1Yi5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIGh3
L2xlb24zLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA1ICsrLS0KIGh3L29tYXAxLmMg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA3ICsrKy0tCiBody9vcGVucmlzY190aW1lci5j
ICAgICAgICAgICAgICAgIHwgICAgNCArKy0KIGh3L3BwYy5jICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgIDIyICsrKysrKysrKystLS0tLS0KIGh3L3BwYy9lNTAwLmMgICAgICAgICAgICAg
ICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9wcGNlNTAwX3NwaW4uYyAgICAgICAgICAgICAg
ICAgIHwgICAgMiArLQogaHcvcHhhMnh4X2dwaW8uYyAgICAgICAgICAgICAgICAgICB8ICAgIDMg
KystCiBody9weGEyeHhfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAgMyArKy0KIGh3L3Mz
OTB4L3MzOTAtdmlydGlvLmMgICAgICAgICAgICAgfCAgIDE0ICsrKysrKy0tLS0KIGh3L3NwYXBy
LmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEwICsrKysrLS0tCiBody9zcGFwcl9oY2Fs
bC5jICAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogaHcvc3BhcHJfcnRhcy5jICAgICAgICAg
ICAgICAgICAgICB8ICAgIDYgKystLS0KIGh3L3N1bjRtLmMgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgIDIxICsrKysrKysrLS0tLS0tLQogaHcvc3VuNHUuYyAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgMTUgKysrKysrKy0tLS0KIGh3L3hlbl9tYWNoaW5lX3B2LmMgICAgICAgICAgICAg
ICAgfCAgICA2ICsrLS0tCiBody94dGVuc2FfcGljLmMgICAgICAgICAgICAgICAgICAgIHwgICAg
OCArKystLS0KIGluY2x1ZGUvZXhlYy9jcHUtZGVmcy5oICAgICAgICAgICAgfCAgICAyIC0tCiBp
bmNsdWRlL3FvbS9jcHUuaCAgICAgICAgICAgICAgICAgIHwgICAgNCArKysKIGt2bS1hbGwuYyAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAyICstCiBxb20vY3B1LmMgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgMiArKwogdGFyZ2V0LWFscGhhL2NwdS5oICAgICAgICAgICAgICAg
ICB8ICAgIDQgKy0tCiB0YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMgICAgICAgICAgIHwgICAgMyAr
Ky0KIHRhcmdldC1hcm0vY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0
LWFybS9oZWxwZXIuYyAgICAgICAgICAgICAgICB8ICAgIDQgKystCiB0YXJnZXQtYXJtL29wX2hl
bHBlci5jICAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1jcmlzL2NwdS5oICAgICAgICAg
ICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LWNyaXMvaGVscGVyLmMgICAgICAgICAgICAgICB8
ICAgIDkgKysrKy0tLQogdGFyZ2V0LWNyaXMvdHJhbnNsYXRlLmMgICAgICAgICAgICB8ICAgIDMg
KystCiB0YXJnZXQtaTM4Ni9jcHUuYyAgICAgICAgICAgICAgICAgIHwgICAgMiArLQogdGFyZ2V0
LWkzODYvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgMjAgKysrKysrKystLS0tLS0tCiB0YXJn
ZXQtaTM4Ni9oZWxwZXIuYyAgICAgICAgICAgICAgIHwgICAxMiArKysrKy0tLS0KIHRhcmdldC1p
Mzg2L2t2bS5jICAgICAgICAgICAgICAgICAgfCAgIDUwICsrKysrKysrKysrKysrKysrKystLS0t
LS0tLS0tLS0tLS0tLQogdGFyZ2V0LWkzODYvbWFjaGluZS5jICAgICAgICAgICAgICB8ICAgIDIg
Ky0KIHRhcmdldC1pMzg2L21pc2NfaGVscGVyLmMgICAgICAgICAgfCAgIDIxICsrKysrKysrKyst
LS0tLQogdGFyZ2V0LWkzODYvc3ZtX2hlbHBlci5jICAgICAgICAgICB8ICAgIDkgKysrKy0tLQog
dGFyZ2V0LWxtMzIvY3B1LmggICAgICAgICAgICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtbG0z
Mi9vcF9oZWxwZXIuYyAgICAgICAgICAgIHwgICAgNCArKy0KIHRhcmdldC1tNjhrL2NwdS5oICAg
ICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LW02OGsvb3BfaGVscGVyLmMgICAgICAg
ICAgICB8ICAgIDQgKystCiB0YXJnZXQtbTY4ay9xcmVncy5kZWYgICAgICAgICAgICAgIHwgICAg
MSAtCiB0YXJnZXQtbTY4ay90cmFuc2xhdGUuYyAgICAgICAgICAgIHwgICAgOCArKysrKy0KIHRh
cmdldC1taWNyb2JsYXplL2NwdS5oICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LW1pcHMv
Y3B1LmggICAgICAgICAgICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtbWlwcy9vcF9oZWxwZXIu
YyAgICAgICAgICAgIHwgICAxMCArKysrKy0tLQogdGFyZ2V0LW1pcHMvdHJhbnNsYXRlLmMgICAg
ICAgICAgICB8ICAgIDQgKy0tCiB0YXJnZXQtb3BlbnJpc2MvY3B1LmggICAgICAgICAgICAgIHwg
ICAgNCArLS0KIHRhcmdldC1vcGVucmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMgfCAgICAzICsrLQog
dGFyZ2V0LW9wZW5yaXNjL3N5c19oZWxwZXIuYyAgICAgICB8ICAgIDMgKystCiB0YXJnZXQtcHBj
L2NwdS5oICAgICAgICAgICAgICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQtcHBjL2V4Y3BfaGVs
cGVyLmMgICAgICAgICAgIHwgICAyMiArKysrKysrKysrKy0tLS0tCiB0YXJnZXQtcHBjL2hlbHBl
cl9yZWdzLmggICAgICAgICAgIHwgICAxMSArKysrKy0tLQogdGFyZ2V0LXBwYy9rdm0uYyAgICAg
ICAgICAgICAgICAgICB8ICAgMTYgKysrKysrKy0tLS0tCiB0YXJnZXQtcHBjL3RyYW5zbGF0ZS5j
ICAgICAgICAgICAgIHwgICAgMyArKy0KIHRhcmdldC1zMzkweC9jcHUuYyAgICAgICAgICAgICAg
ICAgfCAgICA4ICsrKy0tLQogdGFyZ2V0LXMzOTB4L2NwdS5oICAgICAgICAgICAgICAgICB8ICAg
IDUgKystLQogdGFyZ2V0LXMzOTB4L2hlbHBlci5jICAgICAgICAgICAgICB8ICAgIDcgKysrLS0K
IHRhcmdldC1zaDQvY3B1LmggICAgICAgICAgICAgICAgICAgfCAgICA0ICstLQogdGFyZ2V0LXNo
NC9oZWxwZXIuYyAgICAgICAgICAgICAgICB8ICAgIDUgKystLQogdGFyZ2V0LXNoNC9vcF9oZWxw
ZXIuYyAgICAgICAgICAgICB8ICAgIDQgKystCiB0YXJnZXQtc3BhcmMvY3B1LmggICAgICAgICAg
ICAgICAgIHwgICAgNSArKy0tCiB0YXJnZXQtc3BhcmMvaGVscGVyLmMgICAgICAgICAgICAgIHwg
ICAgNCArKy0KIHRhcmdldC11bmljb3JlMzIvY3B1LmggICAgICAgICAgICAgfCAgICA0ICstLQog
dGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11LmMgICAgICAgICB8ICAgIDMgKystCiB0YXJnZXQteHRl
bnNhL29wX2hlbHBlci5jICAgICAgICAgIHwgICAgNSArKystCiB0cmFuc2xhdGUtYWxsLmMgICAg
ICAgICAgICAgICAgICAgIHwgICAxMCArKysrLS0tLQogeGVuLWFsbC5jICAgICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgMTAgKysrKystLS0KIDcwIERhdGVpZW4gZ2XDpG5kZXJ0LCAzMTkgWmVp
bGVuIGhpbnp1Z2Vmw7xndCgrKSwgMjI0IFplaWxlbiBlbnRmZXJudCgtKQoKZGlmZiAtLWdpdCBh
L2NwdS1leGVjLmMgYi9jcHUtZXhlYy5jCmluZGV4IGFmYmU0OTcuLmYxZGE0ZTQgMTAwNjQ0Ci0t
LSBhL2NwdS1leGVjLmMKKysrIGIvY3B1LWV4ZWMuYwpAQCAtMTg4LDEyICsxODgsMTIgQEAgaW50
IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogICAgIHVpbnQ4X3QgKnRjX3B0cjsKICAgICB0
Y2dfdGFyZ2V0X3Vsb25nIG5leHRfdGI7CiAKLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBp
ZiAoY3B1LT5oYWx0ZWQpIHsKICAgICAgICAgaWYgKCFjcHVfaGFzX3dvcmsoY3B1KSkgewogICAg
ICAgICAgICAgcmV0dXJuIEVYQ1BfSEFMVEVEOwogICAgICAgICB9CiAKLSAgICAgICAgZW52LT5o
YWx0ZWQgPSAwOworICAgICAgICBjcHUtPmhhbHRlZCA9IDA7CiAgICAgfQogCiAgICAgY3B1X3Np
bmdsZV9lbnYgPSBlbnY7CkBAIC0yNjMsMTQgKzI2MywxNCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJj
aFN0YXRlICplbnYpCiAKICAgICAgICAgICAgIG5leHRfdGIgPSAwOyAvKiBmb3JjZSBsb29rdXAg
b2YgZmlyc3QgVEIgKi8KICAgICAgICAgICAgIGZvcig7OykgewotICAgICAgICAgICAgICAgIGlu
dGVycnVwdF9yZXF1ZXN0ID0gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdDsKKyAgICAgICAgICAgICAg
ICBpbnRlcnJ1cHRfcmVxdWVzdCA9IGNwdS0+aW50ZXJydXB0X3JlcXVlc3Q7CiAgICAgICAgICAg
ICAgICAgaWYgKHVubGlrZWx5KGludGVycnVwdF9yZXF1ZXN0KSkgewogICAgICAgICAgICAgICAg
ICAgICBpZiAodW5saWtlbHkoZW52LT5zaW5nbGVzdGVwX2VuYWJsZWQgJiBTU1RFUF9OT0lSUSkp
IHsKICAgICAgICAgICAgICAgICAgICAgICAgIC8qIE1hc2sgb3V0IGV4dGVybmFsIGludGVycnVw
dHMgZm9yIHRoaXMgc3RlcC4gKi8KICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycnVwdF9y
ZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NTVEVQX01BU0s7CiAgICAgICAgICAgICAgICAgICAg
IH0KICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9ERUJVRykgewotICAgICAgICAgICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9ERUJVRzsKKyAgICAgICAgICAgICAgICAgICAgICAgIGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfREVCVUc7CiAgICAgICAgICAg
ICAgICAgICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfREVCVUc7CiAgICAgICAg
ICAgICAgICAgICAgICAgICBjcHVfbG9vcF9leGl0KGVudik7CiAgICAgICAgICAgICAgICAgICAg
IH0KQEAgLTI3OCw4ICsyNzgsOCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAg
ICAgZGVmaW5lZChUQVJHRVRfUFBDKSB8fCBkZWZpbmVkKFRBUkdFVF9BTFBIQSkgfHwgZGVmaW5l
ZChUQVJHRVRfQ1JJUykgfHwgXAogICAgIGRlZmluZWQoVEFSR0VUX01JQ1JPQkxBWkUpIHx8IGRl
ZmluZWQoVEFSR0VUX0xNMzIpIHx8IGRlZmluZWQoVEFSR0VUX1VOSUNPUkUzMikKICAgICAgICAg
ICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQUxUKSB7
Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVf
SU5URVJSVVBUX0hBTFQ7Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCA9IDE7
CisgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVf
SU5URVJSVVBUX0hBTFQ7CisgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmhhbHRlZCA9IDE7
CiAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExU
OwogICAgICAgICAgICAgICAgICAgICAgICAgY3B1X2xvb3BfZXhpdChlbnYpOwogICAgICAgICAg
ICAgICAgICAgICB9CkBAIC0yODcsNyArMjg3LDcgQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0
ZSAqZW52KQogI2lmIGRlZmluZWQoVEFSR0VUX0kzODYpCiAjaWYgIWRlZmluZWQoQ09ORklHX1VT
RVJfT05MWSkKICAgICAgICAgICAgICAgICAgICAgaWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BV
X0lOVEVSUlVQVF9QT0xMKSB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7CisgICAgICAgICAgICAgICAgICAgICAg
ICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7CiAgICAgICAg
ICAgICAgICAgICAgICAgICBhcGljX3BvbGxfaXJxKGVudi0+YXBpY19zdGF0ZSk7CiAgICAgICAg
ICAgICAgICAgICAgIH0KICNlbmRpZgpAQCAtMzA0LDE3ICszMDQsMTcgQEAgaW50IGNwdV9leGVj
KENQVUFyY2hTdGF0ZSAqZW52KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICEoZW52LT5o
ZmxhZ3MgJiBIRl9TTU1fTUFTSykpIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHVf
c3ZtX2NoZWNrX2ludGVyY2VwdF9wYXJhbShlbnYsIFNWTV9FWElUX1NNSSwKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwKTsKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5U
RVJSVVBUX1NNSTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9y
ZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1NNSTsKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBkb19zbW1fZW50ZXIoZW52KTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZXh0X3Ri
ID0gMDsKICAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxzZSBpZiAoKGludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9OTUkpICYmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICEoZW52LT5oZmxhZ3MyICYgSEYyX05NSV9NQVNLKSkgewotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfTk1J
OworICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0g
fkNQVV9JTlRFUlJVUFRfTk1JOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+aGZs
YWdzMiB8PSBIRjJfTk1JX01BU0s7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9faW50
ZXJydXB0X3g4Nl9oYXJkaXJxKGVudiwgRVhDUDAyX05NSSwgMSk7CiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAgICAgICAgICAgICAgICB9IGVsc2Ug
aWYgKGludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9NQ0UpIHsKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBU
X01DRTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0
ICY9IH5DUFVfSU5URVJSVVBUX01DRTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb19p
bnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBFWENQMTJfTUNISywgMCk7CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAgICAgICAgICAgICAgICAgICAgICB9IGVs
c2UgaWYgKChpbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKQEAgLTMy
Niw3ICszMjYsOCBAQCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaW50IGludG5vOwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNwdV9zdm1fY2hlY2tfaW50ZXJjZXB0X3BhcmFtKGVudiwgU1ZNX0VYSVRfSU5UUiwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwKTsK
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH4o
Q1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9WSVJRKTsKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH4oQ1BVX0lOVEVSUlVQVF9I
QVJEIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgQ1BVX0lOVEVSUlVQVF9WSVJRKTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bnRubyA9IGNwdV9nZXRfcGljX2ludGVycnVwdChlbnYpOwogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHFlbXVfbG9nX21hc2soQ1BVX0xPR19UQl9JTl9BU00sICJTZXJ2aWNpbmcgaGFyZHdh
cmUgSU5UPTB4JTAyeFxuIiwgaW50bm8pOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRv
X2ludGVycnVwdF94ODZfaGFyZGlycShlbnYsIGludG5vLCAxKTsKQEAgLTM0NCw3ICszNDUsNyBA
QCBpbnQgY3B1X2V4ZWMoQ1BVQXJjaFN0YXRlICplbnYpCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaW50bm8gPSBsZGxfcGh5cyhlbnYtPnZtX3ZtY2IgKyBvZmZzZXRvZihzdHJ1Y3Qgdm1j
YiwgY29udHJvbC5pbnRfdmVjdG9yKSk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcWVt
dV9sb2dfbWFzayhDUFVfTE9HX1RCX0lOX0FTTSwgIlNlcnZpY2luZyB2aXJ0dWFsIGhhcmR3YXJl
IElOVD0weCUwMnhcbiIsIGludG5vKTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb19p
bnRlcnJ1cHRfeDg2X2hhcmRpcnEoZW52LCBpbnRubywgMSk7Ci0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9WSVJROwor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQ
VV9JTlRFUlJVUFRfVklSUTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZXh0X3RiID0g
MDsKICNlbmRpZgogICAgICAgICAgICAgICAgICAgICAgICAgfQpAQCAtMzU1LDggKzM1Niw5IEBA
IGludCBjcHVfZXhlYyhDUFVBcmNoU3RhdGUgKmVudikKICAgICAgICAgICAgICAgICAgICAgfQog
ICAgICAgICAgICAgICAgICAgICBpZiAoaW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBU
X0hBUkQpIHsKICAgICAgICAgICAgICAgICAgICAgICAgIHBwY19od19pbnRlcnJ1cHQoZW52KTsK
LSAgICAgICAgICAgICAgICAgICAgICAgIGlmIChlbnYtPnBlbmRpbmdfaW50ZXJydXB0cyA9PSAw
KQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0g
fkNQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICAgICAgICAgICAgICAgICAgICAgIGlmIChlbnYtPnBl
bmRpbmdfaW50ZXJydXB0cyA9PSAwKSB7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3B1
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9IQVJEOworICAgICAgICAgICAg
ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICAgbmV4dF90YiA9IDA7CiAgICAg
ICAgICAgICAgICAgICAgIH0KICNlbGlmIGRlZmluZWQoVEFSR0VUX0xNMzIpCkBAIC01MzMsOCAr
NTM1LDggQEAgaW50IGNwdV9leGVjKENQVUFyY2hTdGF0ZSAqZW52KQogI2VuZGlmCiAgICAgICAg
ICAgICAgICAgICAgLyogRG9uJ3QgdXNlIHRoZSBjYWNoZWQgaW50ZXJydXB0X3JlcXVlc3QgdmFs
dWUsCiAgICAgICAgICAgICAgICAgICAgICAgZG9faW50ZXJydXB0IG1heSBoYXZlIHVwZGF0ZWQg
dGhlIEVYSVRUQiBmbGFnLiAqLwotICAgICAgICAgICAgICAgICAgICBpZiAoZW52LT5pbnRlcnJ1
cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfRVhJVFRCKSB7Ci0gICAgICAgICAgICAgICAgICAg
ICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAg
ICAgICAgICAgICAgICAgICAgaWYgKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX0VYSVRUQikgeworICAgICAgICAgICAgICAgICAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgICAgICAgICAgICAgICAgICAgICAv
KiBlbnN1cmUgdGhhdCBubyBUQiBqdW1wIHdpbGwgYmUgbW9kaWZpZWQgYXMKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZSBwcm9ncmFtIGZsb3cgd2FzIGNoYW5nZWQgKi8KICAgICAgICAg
ICAgICAgICAgICAgICAgIG5leHRfdGIgPSAwOwpkaWZmIC0tZ2l0IGEvY3B1cy5jIGIvY3B1cy5j
CmluZGV4IDQ2MzU1YzEuLjhkNDdiZmQgMTAwNjQ0Ci0tLSBhL2NwdXMuYworKysgYi9jcHVzLmMK
QEAgLTcyLDcgKzcyLDcgQEAgc3RhdGljIGJvb2wgY3B1X3RocmVhZF9pc19pZGxlKENQVUFyY2hT
dGF0ZSAqZW52KQogICAgIGlmIChjcHUtPnN0b3BwZWQgfHwgIXJ1bnN0YXRlX2lzX3J1bm5pbmco
KSkgewogICAgICAgICByZXR1cm4gdHJ1ZTsKICAgICB9Ci0gICAgaWYgKCFlbnYtPmhhbHRlZCB8
fCBxZW11X2NwdV9oYXNfd29yayhjcHUpIHx8CisgICAgaWYgKCFjcHUtPmhhbHRlZCB8fCBxZW11
X2NwdV9oYXNfd29yayhjcHUpIHx8CiAgICAgICAgIGt2bV9hc3luY19pbnRlcnJ1cHRzX2VuYWJs
ZWQoKSkgewogICAgICAgICByZXR1cm4gZmFsc2U7CiAgICAgfQpAQCAtMTE5OCw3ICsxMTk4LDcg
QEAgQ3B1SW5mb0xpc3QgKnFtcF9xdWVyeV9jcHVzKEVycm9yICoqZXJycCkKICAgICAgICAgaW5m
by0+dmFsdWUgPSBnX21hbGxvYzAoc2l6ZW9mKCppbmZvLT52YWx1ZSkpOwogICAgICAgICBpbmZv
LT52YWx1ZS0+Q1BVID0gY3B1LT5jcHVfaW5kZXg7CiAgICAgICAgIGluZm8tPnZhbHVlLT5jdXJy
ZW50ID0gKGVudiA9PSBmaXJzdF9jcHUpOwotICAgICAgICBpbmZvLT52YWx1ZS0+aGFsdGVkID0g
ZW52LT5oYWx0ZWQ7CisgICAgICAgIGluZm8tPnZhbHVlLT5oYWx0ZWQgPSBjcHUtPmhhbHRlZDsK
ICAgICAgICAgaW5mby0+dmFsdWUtPnRocmVhZF9pZCA9IGNwdS0+dGhyZWFkX2lkOwogI2lmIGRl
ZmluZWQoVEFSR0VUX0kzODYpCiAgICAgICAgIGluZm8tPnZhbHVlLT5oYXNfcGMgPSB0cnVlOwpk
aWZmIC0tZ2l0IGEvZXhlYy5jIGIvZXhlYy5jCmluZGV4IDg0ZTQzYmQuLmUxODBhZWMgMTAwNjQ0
Ci0tLSBhL2V4ZWMuYworKysgYi9leGVjLmMKQEAgLTIyMywxMiArMjIzLDEyIEBAIHZvaWQgY3B1
X2V4ZWNfaW5pdF9hbGwodm9pZCkKIAogc3RhdGljIGludCBjcHVfY29tbW9uX3Bvc3RfbG9hZCh2
b2lkICpvcGFxdWUsIGludCB2ZXJzaW9uX2lkKQogewotICAgIENQVUFyY2hTdGF0ZSAqZW52ID0g
b3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBvcGFxdWU7CiAKICAgICAvKiAweDAxIHdhcyBD
UFVfSU5URVJSVVBUX0VYSVQuIFRoaXMgbGluZSBjYW4gYmUgcmVtb3ZlZCB3aGVuIHRoZQogICAg
ICAgIHZlcnNpb25faWQgaXMgaW5jcmVhc2VkLiAqLwotICAgIGVudi0+aW50ZXJydXB0X3JlcXVl
c3QgJj0gfjB4MDE7Ci0gICAgdGxiX2ZsdXNoKGVudiwgMSk7CisgICAgY3B1LT5pbnRlcnJ1cHRf
cmVxdWVzdCAmPSB+MHgwMTsKKyAgICB0bGJfZmx1c2goY3B1LT5lbnZfcHRyLCAxKTsKIAogICAg
IHJldHVybiAwOwogfQpAQCAtMjQwLDggKzI0MCw4IEBAIHN0YXRpYyBjb25zdCBWTVN0YXRlRGVz
Y3JpcHRpb24gdm1zdGF0ZV9jcHVfY29tbW9uID0gewogICAgIC5taW5pbXVtX3ZlcnNpb25faWRf
b2xkID0gMSwKICAgICAucG9zdF9sb2FkID0gY3B1X2NvbW1vbl9wb3N0X2xvYWQsCiAgICAgLmZp
ZWxkcyAgICAgID0gKFZNU3RhdGVGaWVsZCBbXSkgewotICAgICAgICBWTVNUQVRFX1VJTlQzMiho
YWx0ZWQsIENQVUFyY2hTdGF0ZSksCi0gICAgICAgIFZNU1RBVEVfVUlOVDMyKGludGVycnVwdF9y
ZXF1ZXN0LCBDUFVBcmNoU3RhdGUpLAorICAgICAgICBWTVNUQVRFX1VJTlQzMihoYWx0ZWQsIENQ
VVN0YXRlKSwKKyAgICAgICAgVk1TVEFURV9VSU5UMzIoaW50ZXJydXB0X3JlcXVlc3QsIENQVVN0
YXRlKSwKICAgICAgICAgVk1TVEFURV9FTkRfT0ZfTElTVCgpCiAgICAgfQogfTsKQEAgLTI5Myw3
ICsyOTMsNyBAQCB2b2lkIGNwdV9leGVjX2luaXQoQ1BVQXJjaFN0YXRlICplbnYpCiAjaWYgZGVm
aW5lZChDT05GSUdfVVNFUl9PTkxZKQogICAgIGNwdV9saXN0X3VubG9jaygpOwogI2VuZGlmCi0g
ICAgdm1zdGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2NwdV9jb21tb24s
IGVudik7CisgICAgdm1zdGF0ZV9yZWdpc3RlcihOVUxMLCBjcHVfaW5kZXgsICZ2bXN0YXRlX2Nw
dV9jb21tb24sIGNwdSk7CiAjaWYgZGVmaW5lZChDUFVfU0FWRV9WRVJTSU9OKSAmJiAhZGVmaW5l
ZChDT05GSUdfVVNFUl9PTkxZKQogICAgIHJlZ2lzdGVyX3NhdmV2bShOVUxMLCAiY3B1IiwgY3B1
X2luZGV4LCBDUFVfU0FWRV9WRVJTSU9OLAogICAgICAgICAgICAgICAgICAgICBjcHVfc2F2ZSwg
Y3B1X2xvYWQsIGVudik7CkBAIC00OTQsNyArNDk0LDkgQEAgdm9pZCBjcHVfc2luZ2xlX3N0ZXAo
Q1BVQXJjaFN0YXRlICplbnYsIGludCBlbmFibGVkKQogCiB2b2lkIGNwdV9yZXNldF9pbnRlcnJ1
cHQoQ1BVQXJjaFN0YXRlICplbnYsIGludCBtYXNrKQogewotICAgIGVudi0+aW50ZXJydXB0X3Jl
cXVlc3QgJj0gfm1hc2s7CisgICAgQ1BVU3RhdGUgKmNwdSA9IEVOVl9HRVRfQ1BVKGVudik7CisK
KyAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5tYXNrOwogfQogCiB2b2lkIGNwdV9leGl0
KENQVUFyY2hTdGF0ZSAqZW52KQpkaWZmIC0tZ2l0IGEvZ2Ric3R1Yi5jIGIvZ2Ric3R1Yi5jCmlu
ZGV4IDMyZGZlYTkuLjg0NmRlMWMgMTAwNjQ0Ci0tLSBhL2dkYnN0dWIuYworKysgYi9nZGJzdHVi
LmMKQEAgLTI0MDgsNyArMjQwOCw3IEBAIHN0YXRpYyBpbnQgZ2RiX2hhbmRsZV9wYWNrZXQoR0RC
U3RhdGUgKnMsIGNvbnN0IGNoYXIgKmxpbmVfYnVmKQogICAgICAgICAgICAgICAgIGNwdV9zeW5j
aHJvbml6ZV9zdGF0ZShlbnYpOwogICAgICAgICAgICAgICAgIGxlbiA9IHNucHJpbnRmKChjaGFy
ICopbWVtX2J1Ziwgc2l6ZW9mKG1lbV9idWYpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICJDUFUjJWQgWyVzXSIsIGNwdS0+Y3B1X2luZGV4LAotICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGVudi0+aGFsdGVkID8gImhhbHRlZCAiIDogInJ1bm5pbmciKTsKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBjcHUtPmhhbHRlZCA/ICJoYWx0ZWQgIiA6ICJydW5uaW5n
Iik7CiAgICAgICAgICAgICAgICAgbWVtdG9oZXgoYnVmLCBtZW1fYnVmLCBsZW4pOwogICAgICAg
ICAgICAgICAgIHB1dF9wYWNrZXQocywgYnVmKTsKICAgICAgICAgICAgIH0KZGlmZiAtLWdpdCBh
L2h3L2xlb24zLmMgYi9ody9sZW9uMy5jCmluZGV4IGYxNmE4YmIuLmU5NzFkNWMgMTAwNjQ0Ci0t
LSBhL2h3L2xlb24zLmMKKysrIGIvaHcvbGVvbjMuYwpAQCAtNDksMTEgKzQ5LDEyIEBAIHR5cGVk
ZWYgc3RydWN0IFJlc2V0RGF0YSB7CiBzdGF0aWMgdm9pZCBtYWluX2NwdV9yZXNldCh2b2lkICpv
cGFxdWUpCiB7CiAgICAgUmVzZXREYXRhICpzICAgPSAoUmVzZXREYXRhICopb3BhcXVlOworICAg
IENQVVN0YXRlICpjcHUgPSBDUFUocy0+Y3B1KTsKICAgICBDUFVTUEFSQ1N0YXRlICAqZW52ID0g
JnMtPmNwdS0+ZW52OwogCi0gICAgY3B1X3Jlc2V0KENQVShzLT5jcHUpKTsKKyAgICBjcHVfcmVz
ZXQoY3B1KTsKIAotICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICBjcHUtPmhhbHRlZCA9IDA7CiAg
ICAgZW52LT5wYyAgICAgPSBzLT5lbnRyeTsKICAgICBlbnYtPm5wYyAgICA9IHMtPmVudHJ5ICsg
NDsKIH0KZGlmZiAtLWdpdCBhL2h3L29tYXAxLmMgYi9ody9vbWFwMS5jCmluZGV4IDYyM2IxMDEu
LmMzNmEzMzAgMTAwNjQ0Ci0tLSBhL2h3L29tYXAxLmMKKysrIGIvaHcvb21hcDEuYwpAQCAtMTcy
MSw2ICsxNzIxLDcgQEAgc3RhdGljIHVpbnQ2NF90IG9tYXBfY2xrZHNwX3JlYWQodm9pZCAqb3Bh
cXVlLCBod2FkZHIgYWRkciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln
bmVkIHNpemUpCiB7CiAgICAgc3RydWN0IG9tYXBfbXB1X3N0YXRlX3MgKnMgPSAoc3RydWN0IG9t
YXBfbXB1X3N0YXRlX3MgKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBDUFUocy0+Y3B1
KTsKIAogICAgIGlmIChzaXplICE9IDIpIHsKICAgICAgICAgcmV0dXJuIG9tYXBfYmFkd2lkdGhf
cmVhZDE2KG9wYXF1ZSwgYWRkcik7CkBAIC0xNzM3LDggKzE3MzgsOSBAQCBzdGF0aWMgdWludDY0
X3Qgb21hcF9jbGtkc3BfcmVhZCh2b2lkICpvcGFxdWUsIGh3YWRkciBhZGRyLAogICAgICAgICBy
ZXR1cm4gcy0+Y2xrbS5kc3BfcnN0Y3QyOwogCiAgICAgY2FzZSAweDE4OgkvKiBEU1BfU1lTU1Qg
Ki8KKyAgICAgICAgY3B1ID0gQ1BVKHMtPmNwdSk7CiAgICAgICAgIHJldHVybiAocy0+Y2xrbS5j
bG9ja2luZ19zY2hlbWUgPDwgMTEpIHwgcy0+Y2xrbS5jb2xkX3N0YXJ0IHwKLSAgICAgICAgICAg
ICAgICAocy0+Y3B1LT5lbnYuaGFsdGVkIDw8IDYpOyAgICAgIC8qIFF1aXRlIHVzZWxlc3MuLi4g
Ki8KKyAgICAgICAgICAgICAgICAoY3B1LT5oYWx0ZWQgPDwgNik7ICAgICAgLyogUXVpdGUgdXNl
bGVzcy4uLiAqLwogICAgIH0KIAogICAgIE9NQVBfQkFEX1JFRyhhZGRyKTsKQEAgLTM3NTQsOCAr
Mzc1Niw5IEBAIHN0YXRpYyB2b2lkIG9tYXBfc2V0dXBfZHNwX21hcHBpbmcoTWVtb3J5UmVnaW9u
ICpzeXN0ZW1fbWVtb3J5LAogdm9pZCBvbWFwX21wdV93YWtldXAodm9pZCAqb3BhcXVlLCBpbnQg
aXJxLCBpbnQgcmVxKQogewogICAgIHN0cnVjdCBvbWFwX21wdV9zdGF0ZV9zICptcHUgPSAoc3Ry
dWN0IG9tYXBfbXB1X3N0YXRlX3MgKikgb3BhcXVlOworICAgIENQVVN0YXRlICpjcHUgPSBDUFUo
bXB1LT5jcHUpOwogCi0gICAgaWYgKG1wdS0+Y3B1LT5lbnYuaGFsdGVkKSB7CisgICAgaWYgKGNw
dS0+aGFsdGVkKSB7CiAgICAgICAgIGNwdV9pbnRlcnJ1cHQoJm1wdS0+Y3B1LT5lbnYsIENQVV9J
TlRFUlJVUFRfRVhJVFRCKTsKICAgICB9CiB9CmRpZmYgLS1naXQgYS9ody9vcGVucmlzY190aW1l
ci5jIGIvaHcvb3BlbnJpc2NfdGltZXIuYwppbmRleCBkOTY1YmU3Li5mOWYxMTZhIDEwMDY0NAot
LS0gYS9ody9vcGVucmlzY190aW1lci5jCisrKyBiL2h3L29wZW5yaXNjX3RpbWVyLmMKQEAgLTcz
LDggKzczLDEwIEBAIHN0YXRpYyB2b2lkIG9wZW5yaXNjX3RpbWVyX2NiKHZvaWQgKm9wYXF1ZSkK
IAogICAgIGlmICgoY3B1LT5lbnYudHRtciAmIFRUTVJfSUUpICYmCiAgICAgICAgICBxZW11X3Rp
bWVyX2V4cGlyZWQoY3B1LT5lbnYudGltZXIsIHFlbXVfZ2V0X2Nsb2NrX25zKHZtX2Nsb2NrKSkp
IHsKKyAgICAgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CisKICAgICAgICAgY3B1LT5lbnYu
dHRtciB8PSBUVE1SX0lQOwotICAgICAgICBjcHUtPmVudi5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBD
UFVfSU5URVJSVVBUX1RJTUVSOworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BV
X0lOVEVSUlVQVF9USU1FUjsKICAgICB9CiAKICAgICBzd2l0Y2ggKGNwdS0+ZW52LnR0bXIgJiBU
VE1SX00pIHsKZGlmZiAtLWdpdCBhL2h3L3BwYy5jIGIvaHcvcHBjLmMKaW5kZXggOGNmYjg0Zi4u
ZTExZDJmOCAxMDA2NDQKLS0tIGEvaHcvcHBjLmMKKysrIGIvaHcvcHBjLmMKQEAgLTcyLDcgKzcy
LDcgQEAgdm9pZCBwcGNfc2V0X2lycShQb3dlclBDQ1BVICpjcHUsIGludCBuX0lSUSwgaW50IGxl
dmVsKQogCiAgICAgTE9HX0lSUSgiJXM6ICVwIG5fSVJRICVkIGxldmVsICVkID0+IHBlbmRpbmcg
JTA4IiBQUkl4MzIKICAgICAgICAgICAgICAgICAicmVxICUwOHhcbiIsIF9fZnVuY19fLCBlbnYs
IG5fSVJRLCBsZXZlbCwKLSAgICAgICAgICAgICAgICBlbnYtPnBlbmRpbmdfaW50ZXJydXB0cywg
ZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCk7CisgICAgICAgICAgICAgICAgZW52LT5wZW5kaW5nX2lu
dGVycnVwdHMsIENQVShjcHUpLT5pbnRlcnJ1cHRfcmVxdWVzdCk7CiB9CiAKIC8qIFBvd2VyUEMg
Nnh4IC8gN3h4IGludGVybmFsIElSUSBjb250cm9sbGVyICovCkBAIC04Nyw2ICs4Nyw4IEBAIHN0
YXRpYyB2b2lkIHBwYzZ4eF9zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVs
KQogICAgIGN1cl9sZXZlbCA9IChlbnYtPmlycV9pbnB1dF9zdGF0ZSA+PiBwaW4pICYgMTsKICAg
ICAvKiBEb24ndCBnZW5lcmF0ZSBzcHVyaW91cyBldmVudHMgKi8KICAgICBpZiAoKGN1cl9sZXZl
bCA9PSAxICYmIGxldmVsID09IDApIHx8IChjdXJfbGV2ZWwgPT0gMCAmJiBsZXZlbCAhPSAwKSkg
eworICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKKwogICAgICAgICBzd2l0Y2ggKHBp
bikgewogICAgICAgICBjYXNlIFBQQzZ4eF9JTlBVVF9UQkVOOgogICAgICAgICAgICAgLyogTGV2
ZWwgc2Vuc2l0aXZlIC0gYWN0aXZlIGhpZ2ggKi8KQEAgLTEyNiw3ICsxMjgsNyBAQCBzdGF0aWMg
dm9pZCBwcGM2eHhfc2V0X2lycSh2b2lkICpvcGFxdWUsIGludCBwaW4sIGludCBsZXZlbCkKICAg
ICAgICAgICAgIC8qIFhYWDogTm90ZSB0aGF0IHRoZSBvbmx5IHdheSB0byByZXN0YXJ0IHRoZSBD
UFUgaXMgdG8gcmVzZXQgaXQgKi8KICAgICAgICAgICAgIGlmIChsZXZlbCkgewogICAgICAgICAg
ICAgICAgIExPR19JUlEoIiVzOiBzdG9wIHRoZSBDUFVcbiIsIF9fZnVuY19fKTsKLSAgICAgICAg
ICAgICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7
CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBQUEM2eHhf
SU5QVVRfSFJFU0VUOgpAQCAtMTc0LDYgKzE3Niw4IEBAIHN0YXRpYyB2b2lkIHBwYzk3MF9zZXRf
aXJxKHZvaWQgKm9wYXF1ZSwgaW50IHBpbiwgaW50IGxldmVsKQogICAgIGN1cl9sZXZlbCA9IChl
bnYtPmlycV9pbnB1dF9zdGF0ZSA+PiBwaW4pICYgMTsKICAgICAvKiBEb24ndCBnZW5lcmF0ZSBz
cHVyaW91cyBldmVudHMgKi8KICAgICBpZiAoKGN1cl9sZXZlbCA9PSAxICYmIGxldmVsID09IDAp
IHx8IChjdXJfbGV2ZWwgPT0gMCAmJiBsZXZlbCAhPSAwKSkgeworICAgICAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUoY3B1KTsKKwogICAgICAgICBzd2l0Y2ggKHBpbikgewogICAgICAgICBjYXNlIFBQ
Qzk3MF9JTlBVVF9JTlQ6CiAgICAgICAgICAgICAvKiBMZXZlbCBzZW5zaXRpdmUgLSBhY3RpdmUg
aGlnaCAqLwpAQCAtMjAzLDExICsyMDcsMTEgQEAgc3RhdGljIHZvaWQgcHBjOTcwX3NldF9pcnEo
dm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwpCiAgICAgICAgICAgICAvKiBYWFg6IFRP
RE86IHJlbGF5IHRoZSBzaWduYWwgdG8gQ0tTVFBfT1VUIHBpbiAqLwogICAgICAgICAgICAgaWYg
KGxldmVsKSB7CiAgICAgICAgICAgICAgICAgTE9HX0lSUSgiJXM6IHN0b3AgdGhlIENQVVxuIiwg
X19mdW5jX18pOwotICAgICAgICAgICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgICAg
ICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAg
ICAgTE9HX0lSUSgiJXM6IHJlc3RhcnQgdGhlIENQVVxuIiwgX19mdW5jX18pOwotICAgICAgICAg
ICAgICAgIGVudi0+aGFsdGVkID0gMDsKLSAgICAgICAgICAgICAgICBxZW11X2NwdV9raWNrKENQ
VShjcHUpKTsKKyAgICAgICAgICAgICAgICBjcy0+aGFsdGVkID0gMDsKKyAgICAgICAgICAgICAg
ICBxZW11X2NwdV9raWNrKGNzKTsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGJyZWFrOwog
ICAgICAgICBjYXNlIFBQQzk3MF9JTlBVVF9IUkVTRVQ6CkBAIC0yOTUsNiArMjk5LDggQEAgc3Rh
dGljIHZvaWQgcHBjNDB4X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwp
CiAgICAgY3VyX2xldmVsID0gKGVudi0+aXJxX2lucHV0X3N0YXRlID4+IHBpbikgJiAxOwogICAg
IC8qIERvbid0IGdlbmVyYXRlIHNwdXJpb3VzIGV2ZW50cyAqLwogICAgIGlmICgoY3VyX2xldmVs
ID09IDEgJiYgbGV2ZWwgPT0gMCkgfHwgKGN1cl9sZXZlbCA9PSAwICYmIGxldmVsICE9IDApKSB7
CisgICAgICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOworCiAgICAgICAgIHN3aXRjaCAocGlu
KSB7CiAgICAgICAgIGNhc2UgUFBDNDB4X0lOUFVUX1JFU0VUX1NZUzoKICAgICAgICAgICAgIGlm
IChsZXZlbCkgewpAQCAtMzMyLDExICszMzgsMTEgQEAgc3RhdGljIHZvaWQgcHBjNDB4X3NldF9p
cnEodm9pZCAqb3BhcXVlLCBpbnQgcGluLCBpbnQgbGV2ZWwpCiAgICAgICAgICAgICAvKiBMZXZl
bCBzZW5zaXRpdmUgLSBhY3RpdmUgbG93ICovCiAgICAgICAgICAgICBpZiAobGV2ZWwpIHsKICAg
ICAgICAgICAgICAgICBMT0dfSVJRKCIlczogc3RvcCB0aGUgQ1BVXG4iLCBfX2Z1bmNfXyk7Ci0g
ICAgICAgICAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgICAgIGNzLT5oYWx0
ZWQgPSAxOwogICAgICAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgICAgICBMT0dfSVJRKCIl
czogcmVzdGFydCB0aGUgQ1BVXG4iLCBfX2Z1bmNfXyk7Ci0gICAgICAgICAgICAgICAgZW52LT5o
YWx0ZWQgPSAwOwotICAgICAgICAgICAgICAgIHFlbXVfY3B1X2tpY2soQ1BVKGNwdSkpOworICAg
ICAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAwOworICAgICAgICAgICAgICAgIHFlbXVfY3B1X2tp
Y2soY3MpOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2Ug
UFBDNDB4X0lOUFVUX0RFQlVHOgpkaWZmIC0tZ2l0IGEvaHcvcHBjL2U1MDAuYyBiL2h3L3BwYy9l
NTAwLmMKaW5kZXggNDUxNjgyYy4uZmVmOWM1ZCAxMDA2NDQKLS0tIGEvaHcvcHBjL2U1MDAuYwor
KysgYi9ody9wcGMvZTUwMC5jCkBAIC00MjAsMjYgKzQyMCwyOCBAQCBzdGF0aWMgdm9pZCBtbXVi
b29rZV9jcmVhdGVfaW5pdGlhbF9tYXBwaW5nKENQVVBQQ1N0YXRlICplbnYpCiBzdGF0aWMgdm9p
ZCBwcGNlNTAwX2NwdV9yZXNldF9zZWModm9pZCAqb3BhcXVlKQogewogICAgIFBvd2VyUENDUFUg
KmNwdSA9IG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVQUENT
dGF0ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgY3B1X3Jlc2V0KENQVShjcHUpKTsKKyAgICBj
cHVfcmVzZXQoY3MpOwogCiAgICAgLyogU2Vjb25kYXJ5IENQVSBzdGFydHMgaW4gaGFsdGVkIHN0
YXRlIGZvciBub3cuIE5lZWRzIHRvIGNoYW5nZSB3aGVuCiAgICAgICAgaW1wbGVtZW50aW5nIG5v
bi1rZXJuZWwgYm9vdC4gKi8KLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MtPmhhbHRlZCA9
IDE7CiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsKIH0KIAogc3RhdGljIHZv
aWQgcHBjZTUwMF9jcHVfcmVzZXQodm9pZCAqb3BhcXVlKQogewogICAgIFBvd2VyUENDUFUgKmNw
dSA9IG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVQUENTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogICAgIHN0cnVjdCBib290X2luZm8gKmJpID0gZW52LT5sb2Fk
X2luZm87CiAKLSAgICBjcHVfcmVzZXQoQ1BVKGNwdSkpOworICAgIGNwdV9yZXNldChjcyk7CiAK
ICAgICAvKiBTZXQgaW5pdGlhbCBndWVzdCBzdGF0ZS4gKi8KLSAgICBlbnYtPmhhbHRlZCA9IDA7
CisgICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgZW52LT5ncHJbMV0gPSAoMTY8PDIwKSAtIDg7CiAg
ICAgZW52LT5ncHJbM10gPSBiaS0+ZHRfYmFzZTsKICAgICBlbnYtPm5pcCA9IGJpLT5lbnRyeTsK
ZGlmZiAtLWdpdCBhL2h3L3BwY2U1MDBfc3Bpbi5jIGIvaHcvcHBjZTUwMF9zcGluLmMKaW5kZXgg
NWJkY2U1Mi4uMThjNWRiNCAxMDA2NDQKLS0tIGEvaHcvcHBjZTUwMF9zcGluLmMKKysrIGIvaHcv
cHBjZTUwMF9zcGluLmMKQEAgLTExMiw3ICsxMTIsNyBAQCBzdGF0aWMgdm9pZCBzcGluX2tpY2so
dm9pZCAqZGF0YSkKICAgICBtYXBfc3RhcnQgPSBsZHFfcCgmY3Vyc3Bpbi0+YWRkcikgJiB+KG1h
cF9zaXplIC0gMSk7CiAgICAgbW11Ym9va2VfY3JlYXRlX2luaXRpYWxfbWFwcGluZyhlbnYsIDAs
IG1hcF9zdGFydCwgbWFwX3NpemUpOwogCi0gICAgZW52LT5oYWx0ZWQgPSAwOworICAgIGNwdS0+
aGFsdGVkID0gMDsKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IC0xOwogICAgIGNwdS0+c3Rv
cHBlZCA9IGZhbHNlOwogICAgIHFlbXVfY3B1X2tpY2soY3B1KTsKZGlmZiAtLWdpdCBhL2h3L3B4
YTJ4eF9ncGlvLmMgYi9ody9weGEyeHhfZ3Bpby5jCmluZGV4IDA1ZDJhZDIuLmYwMGQxNTAgMTAw
NjQ0Ci0tLSBhL2h3L3B4YTJ4eF9ncGlvLmMKKysrIGIvaHcvcHhhMnh4X2dwaW8uYwpAQCAtOTMs
NiArOTMsNyBAQCBzdGF0aWMgY29uc3QgaW50IHB4YTJ4eF9ncGlvX3dha2VbUFhBMlhYX0dQSU9f
QkFOS1NdID0gewogc3RhdGljIHZvaWQgcHhhMnh4X2dwaW9fc2V0KHZvaWQgKm9wYXF1ZSwgaW50
IGxpbmUsIGludCBsZXZlbCkKIHsKICAgICBQWEEyeHhHUElPSW5mbyAqcyA9IChQWEEyeHhHUElP
SW5mbyAqKSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNwdSA9IENQVShzLT5jcHUpOwogICAgIGlu
dCBiYW5rOwogICAgIHVpbnQzMl90IG1hc2s7CiAKQEAgLTExOCw3ICsxMTksNyBAQCBzdGF0aWMg
dm9pZCBweGEyeHhfZ3Bpb19zZXQodm9pZCAqb3BhcXVlLCBpbnQgbGluZSwgaW50IGxldmVsKQog
ICAgICAgICBweGEyeHhfZ3Bpb19pcnFfdXBkYXRlKHMpOwogCiAgICAgLyogV2FrZS11cCBHUElP
cyAqLwotICAgIGlmIChzLT5jcHUtPmVudi5oYWx0ZWQgJiYgKG1hc2sgJiB+cy0+ZGlyW2Jhbmtd
ICYgcHhhMnh4X2dwaW9fd2FrZVtiYW5rXSkpIHsKKyAgICBpZiAoY3B1LT5oYWx0ZWQgJiYgKG1h
c2sgJiB+cy0+ZGlyW2JhbmtdICYgcHhhMnh4X2dwaW9fd2FrZVtiYW5rXSkpIHsKICAgICAgICAg
Y3B1X2ludGVycnVwdCgmcy0+Y3B1LT5lbnYsIENQVV9JTlRFUlJVUFRfRVhJVFRCKTsKICAgICB9
CiB9CmRpZmYgLS1naXQgYS9ody9weGEyeHhfcGljLmMgYi9ody9weGEyeHhfcGljLmMKaW5kZXgg
OTBiOGZlZi4uYzczZTcwOSAxMDA2NDQKLS0tIGEvaHcvcHhhMnh4X3BpYy5jCisrKyBiL2h3L3B4
YTJ4eF9waWMuYwpAQCAtNDYsOCArNDYsOSBAQCBzdGF0aWMgdm9pZCBweGEyeHhfcGljX3VwZGF0
ZSh2b2lkICpvcGFxdWUpCiB7CiAgICAgdWludDMyX3QgbWFza1syXTsKICAgICBQWEEyeHhQSUNT
dGF0ZSAqcyA9IChQWEEyeHhQSUNTdGF0ZSAqKSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNwdSA9
IENQVShzLT5jcHUpOwogCi0gICAgaWYgKHMtPmNwdS0+ZW52LmhhbHRlZCkgeworICAgIGlmIChj
cHUtPmhhbHRlZCkgewogICAgICAgICBtYXNrWzBdID0gcy0+aW50X3BlbmRpbmdbMF0gJiAocy0+
aW50X2VuYWJsZWRbMF0gfCBzLT5pbnRfaWRsZSk7CiAgICAgICAgIG1hc2tbMV0gPSBzLT5pbnRf
cGVuZGluZ1sxXSAmIChzLT5pbnRfZW5hYmxlZFsxXSB8IHMtPmludF9pZGxlKTsKICAgICAgICAg
aWYgKG1hc2tbMF0gfHwgbWFza1sxXSkgewpkaWZmIC0tZ2l0IGEvaHcvczM5MHgvczM5MC12aXJ0
aW8uYyBiL2h3L3MzOTB4L3MzOTAtdmlydGlvLmMKaW5kZXggZTI1YzMzMC4uY2EyNzViZCAxMDA2
NDQKLS0tIGEvaHcvczM5MHgvczM5MC12aXJ0aW8uYworKysgYi9ody9zMzkweC9zMzkwLXZpcnRp
by5jCkBAIC0xMzIsMjMgKzEzMiwyNSBAQCBzdGF0aWMgdW5zaWduZWQgczM5MF9ydW5uaW5nX2Nw
dXM7CiAKIHZvaWQgczM5MF9hZGRfcnVubmluZ19jcHUoUzM5MENQVSAqY3B1KQogeworICAgIENQ
VVN0YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVMzOTBYU3RhdGUgKmVudiA9ICZjcHUtPmVu
djsKIAotICAgIGlmIChlbnYtPmhhbHRlZCkgeworICAgIGlmIChjcy0+aGFsdGVkKSB7CiAgICAg
ICAgIHMzOTBfcnVubmluZ19jcHVzKys7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMDsKKyAgICAg
ICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgICAgIGVudi0+ZXhjZXB0aW9uX2luZGV4ID0gLTE7CiAg
ICAgfQogfQogCiB1bnNpZ25lZCBzMzkwX2RlbF9ydW5uaW5nX2NwdShTMzkwQ1BVICpjcHUpCiB7
CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAgQ1BVUzM5MFhTdGF0ZSAqZW52ID0g
JmNwdS0+ZW52OwogCi0gICAgaWYgKGVudi0+aGFsdGVkID09IDApIHsKKyAgICBpZiAoY3MtPmhh
bHRlZCA9PSAwKSB7CiAgICAgICAgIGFzc2VydChzMzkwX3J1bm5pbmdfY3B1cyA+PSAxKTsKICAg
ICAgICAgczM5MF9ydW5uaW5nX2NwdXMtLTsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAg
ICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQ
X0hMVDsKICAgICB9CiAgICAgcmV0dXJuIHMzOTBfcnVubmluZ19jcHVzOwpAQCAtMTgzLDExICsx
ODUsMTMgQEAgdm9pZCBzMzkwX2luaXRfY3B1cyhjb25zdCBjaGFyICpjcHVfbW9kZWwsIHVpbnQ4
X3QgKnN0b3JhZ2Vfa2V5cykKIAogICAgIGZvciAoaSA9IDA7IGkgPCBzbXBfY3B1czsgaSsrKSB7
CiAgICAgICAgIFMzOTBDUFUgKmNwdTsKKyAgICAgICAgQ1BVU3RhdGUgKmNzOwogCiAgICAgICAg
IGNwdSA9IGNwdV9zMzkweF9pbml0KGNwdV9tb2RlbCk7CisgICAgICAgIGNzID0gQ1BVKGNwdSk7
CiAKICAgICAgICAgaXBpX3N0YXRlc1tpXSA9IGNwdTsKLSAgICAgICAgY3B1LT5lbnYuaGFsdGVk
ID0gMTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgIGNwdS0+ZW52LmV4Y2VwdGlv
bl9pbmRleCA9IEVYQ1BfSExUOwogICAgICAgICBjcHUtPmVudi5zdG9yYWdlX2tleXMgPSBzdG9y
YWdlX2tleXM7CiAgICAgfQpkaWZmIC0tZ2l0IGEvaHcvc3BhcHIuYyBiL2h3L3NwYXByLmMKaW5k
ZXggZTg4YTI3YS4uZGE1MTgxYyAxMDA2NDQKLS0tIGEvaHcvc3BhcHIuYworKysgYi9ody9zcGFw
ci5jCkBAIC02MTYsNiArNjE2LDggQEAgc3RhdGljIHZvaWQgc3BhcHJfcmVzZXRfaHRhYihzUEFQ
UkVudmlyb25tZW50ICpzcGFwcikKIAogc3RhdGljIHZvaWQgcHBjX3NwYXByX3Jlc2V0KHZvaWQp
CiB7CisgICAgQ1BVU3RhdGUgKmZpcnN0X2NwdV9jcHU7CisKICAgICAvKiBSZXNldCB0aGUgaGFz
aCB0YWJsZSAmIHJlY2FsYyB0aGUgUk1BICovCiAgICAgc3BhcHJfcmVzZXRfaHRhYihzcGFwcik7
CiAKQEAgLTYyNiw5ICs2MjgsMTAgQEAgc3RhdGljIHZvaWQgcHBjX3NwYXByX3Jlc2V0KHZvaWQp
CiAgICAgICAgICAgICAgICAgICAgICAgIHNwYXByLT5ydGFzX3NpemUpOwogCiAgICAgLyogU2V0
IHVwIHRoZSBlbnRyeSBzdGF0ZSAqLworICAgIGZpcnN0X2NwdV9jcHUgPSBDUFUoZmlyc3RfY3B1
KTsKICAgICBmaXJzdF9jcHUtPmdwclszXSA9IHNwYXByLT5mZHRfYWRkcjsKICAgICBmaXJzdF9j
cHUtPmdwcls1XSA9IDA7Ci0gICAgZmlyc3RfY3B1LT5oYWx0ZWQgPSAwOworICAgIGZpcnN0X2Nw
dV9jcHUtPmhhbHRlZCA9IDA7CiAgICAgZmlyc3RfY3B1LT5uaXAgPSBzcGFwci0+ZW50cnlfcG9p
bnQ7CiAKIH0KQEAgLTYzNiwxNCArNjM5LDE1IEBAIHN0YXRpYyB2b2lkIHBwY19zcGFwcl9yZXNl
dCh2b2lkKQogc3RhdGljIHZvaWQgc3BhcHJfY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAg
ICBQb3dlclBDQ1BVICpjcHUgPSBvcGFxdWU7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7
CiAgICAgQ1BVUFBDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKIAotICAgIGNwdV9yZXNldChDUFUo
Y3B1KSk7CisgICAgY3B1X3Jlc2V0KGNzKTsKIAogICAgIC8qIEFsbCBDUFVzIHN0YXJ0IGhhbHRl
ZC4gIENQVTAgaXMgdW5oYWx0ZWQgZnJvbSB0aGUgbWFjaGluZSBsZXZlbAogICAgICAqIHJlc2V0
IGNvZGUgYW5kIHRoZSByZXN0IGFyZSBleHBsaWNpdGx5IHN0YXJ0ZWQgdXAgYnkgdGhlIGd1ZXN0
CiAgICAgICogdXNpbmcgYW4gUlRBUyBjYWxsICovCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAg
IGNzLT5oYWx0ZWQgPSAxOwogCiAgICAgZW52LT5zcHJbU1BSX0hJT1JdID0gMDsKIApkaWZmIC0t
Z2l0IGEvaHcvc3BhcHJfaGNhbGwuYyBiL2h3L3NwYXByX2hjYWxsLmMKaW5kZXggN2I4OTU5NC4u
NTMxNTAxYiAxMDA2NDQKLS0tIGEvaHcvc3BhcHJfaGNhbGwuYworKysgYi9ody9zcGFwcl9oY2Fs
bC5jCkBAIC01MTMsNyArNTEzLDcgQEAgc3RhdGljIHRhcmdldF91bG9uZyBoX2NlZGUoUG93ZXJQ
Q0NQVSAqY3B1LCBzUEFQUkVudmlyb25tZW50ICpzcGFwciwKICAgICBlbnYtPm1zciB8PSAoMVVM
TCA8PCBNU1JfRUUpOwogICAgIGhyZWdfY29tcHV0ZV9oZmxhZ3MoZW52KTsKICAgICBpZiAoIWNw
dV9oYXNfd29yayhjcykpIHsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICBjcy0+
aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsKICAg
ICAgICAgY3MtPmV4aXRfcmVxdWVzdCA9IDE7CiAgICAgfQpkaWZmIC0tZ2l0IGEvaHcvc3BhcHJf
cnRhcy5jIGIvaHcvc3BhcHJfcnRhcy5jCmluZGV4IDVlYzc4N2YuLmEyNGU4NTMgMTAwNjQ0Ci0t
LSBhL2h3L3NwYXByX3J0YXMuYworKysgYi9ody9zcGFwcl9ydGFzLmMKQEAgLTE0NSw3ICsxNDUs
NyBAQCBzdGF0aWMgdm9pZCBydGFzX3F1ZXJ5X2NwdV9zdG9wcGVkX3N0YXRlKHNQQVBSRW52aXJv
bm1lbnQgKnNwYXByLAogICAgICAgICAgICAgY29udGludWU7CiAgICAgICAgIH0KIAotICAgICAg
ICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICAgICAgaWYgKGNwdS0+aGFsdGVkKSB7CiAgICAgICAg
ICAgICBydGFzX3N0KHJldHMsIDEsIDApOwogICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAg
cnRhc19zdChyZXRzLCAxLCAyKTsKQEAgLTE4NCw3ICsxODQsNyBAQCBzdGF0aWMgdm9pZCBydGFz
X3N0YXJ0X2NwdShzUEFQUkVudmlyb25tZW50ICpzcGFwciwKICAgICAgICAgICAgIGNvbnRpbnVl
OwogICAgICAgICB9CiAKLSAgICAgICAgaWYgKCFlbnYtPmhhbHRlZCkgeworICAgICAgICBpZiAo
IWNwdS0+aGFsdGVkKSB7CiAgICAgICAgICAgICBydGFzX3N0KHJldHMsIDAsIC0xKTsKICAgICAg
ICAgICAgIHJldHVybjsKICAgICAgICAgfQpAQCAtMTk3LDcgKzE5Nyw3IEBAIHN0YXRpYyB2b2lk
IHJ0YXNfc3RhcnRfY3B1KHNQQVBSRW52aXJvbm1lbnQgKnNwYXByLAogICAgICAgICBlbnYtPm1z
ciA9ICgxVUxMIDw8IE1TUl9TRikgfCAoMVVMTCA8PCBNU1JfTUUpOwogICAgICAgICBlbnYtPm5p
cCA9IHN0YXJ0OwogICAgICAgICBlbnYtPmdwclszXSA9IHIzOwotICAgICAgICBlbnYtPmhhbHRl
ZCA9IDA7CisgICAgICAgIGNwdS0+aGFsdGVkID0gMDsKIAogICAgICAgICBxZW11X2NwdV9raWNr
KGNwdSk7CiAKZGlmZiAtLWdpdCBhL2h3L3N1bjRtLmMgYi9ody9zdW40bS5jCmluZGV4IDk5MDNm
NDQuLjQ1Zjk0NDEgMTAwNjQ0Ci0tLSBhL2h3L3N1bjRtLmMKKysrIGIvaHcvc3VuNG0uYwpAQCAt
MjU2LDEwICsyNTYsMTEgQEAgdm9pZCBjcHVfY2hlY2tfaXJxcyhDUFVTUEFSQ1N0YXRlICplbnYp
CiBzdGF0aWMgdm9pZCBjcHVfa2lja19pcnEoU1BBUkNDUFUgKmNwdSkKIHsKICAgICBDUFVTUEFS
Q1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAK
LSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgY3B1X2NoZWNr
X2lycXMoZW52KTsKLSAgICBxZW11X2NwdV9raWNrKENQVShjcHUpKTsKKyAgICBxZW11X2NwdV9r
aWNrKGNzKTsKIH0KIAogc3RhdGljIHZvaWQgY3B1X3NldF9pcnEodm9pZCAqb3BhcXVlLCBpbnQg
aXJxLCBpbnQgbGV2ZWwpCkBAIC0yODUsMTkgKzI4NiwxOSBAQCBzdGF0aWMgdm9pZCBkdW1teV9j
cHVfc2V0X2lycSh2b2lkICpvcGFxdWUsIGludCBpcnEsIGludCBsZXZlbCkKIHN0YXRpYyB2b2lk
IG1haW5fY3B1X3Jlc2V0KHZvaWQgKm9wYXF1ZSkKIHsKICAgICBTUEFSQ0NQVSAqY3B1ID0gb3Bh
cXVlOwotICAgIENQVVNQQVJDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUoY3B1KTsKIAotICAgIGNwdV9yZXNldChDUFUoY3B1KSk7Ci0gICAgZW52LT5oYWx0
ZWQgPSAwOworICAgIGNwdV9yZXNldChjcyk7CisgICAgY3MtPmhhbHRlZCA9IDA7CiB9CiAKIHN0
YXRpYyB2b2lkIHNlY29uZGFyeV9jcHVfcmVzZXQodm9pZCAqb3BhcXVlKQogewogICAgIFNQQVJD
Q1BVICpjcHUgPSBvcGFxdWU7Ci0gICAgQ1BVU1BBUkNTdGF0ZSAqZW52ID0gJmNwdS0+ZW52Owor
ICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOwogCi0gICAgY3B1X3Jlc2V0KENQVShjcHUpKTsK
LSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3B1X3Jlc2V0KGNzKTsKKyAgICBjcy0+aGFsdGVk
ID0gMTsKIH0KIAogc3RhdGljIHZvaWQgY3B1X2hhbHRfc2lnbmFsKHZvaWQgKm9wYXF1ZSwgaW50
IGlycSwgaW50IGxldmVsKQpAQCAtODI2LDYgKzgyNyw3IEBAIHN0YXRpYyBjb25zdCBUeXBlSW5m
byByYW1faW5mbyA9IHsKIHN0YXRpYyB2b2lkIGNwdV9kZXZpbml0KGNvbnN0IGNoYXIgKmNwdV9t
b2RlbCwgdW5zaWduZWQgaW50IGlkLAogICAgICAgICAgICAgICAgICAgICAgICAgdWludDY0X3Qg
cHJvbV9hZGRyLCBxZW11X2lycSAqKmNwdV9pcnFzKQogeworICAgIENQVVN0YXRlICpjczsKICAg
ICBTUEFSQ0NQVSAqY3B1OwogICAgIENQVVNQQVJDU3RhdGUgKmVudjsKIApAQCAtODQxLDcgKzg0
Myw4IEBAIHN0YXRpYyB2b2lkIGNwdV9kZXZpbml0KGNvbnN0IGNoYXIgKmNwdV9tb2RlbCwgdW5z
aWduZWQgaW50IGlkLAogICAgICAgICBxZW11X3JlZ2lzdGVyX3Jlc2V0KG1haW5fY3B1X3Jlc2V0
LCBjcHUpOwogICAgIH0gZWxzZSB7CiAgICAgICAgIHFlbXVfcmVnaXN0ZXJfcmVzZXQoc2Vjb25k
YXJ5X2NwdV9yZXNldCwgY3B1KTsKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAxOworICAgICAgICBj
cyA9IENQVShjcHUpOworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICB9CiAgICAgKmNwdV9p
cnFzID0gcWVtdV9hbGxvY2F0ZV9pcnFzKGNwdV9zZXRfaXJxLCBjcHUsIE1BWF9QSUxTKTsKICAg
ICBlbnYtPnByb21fYWRkciA9IHByb21fYWRkcjsKZGlmZiAtLWdpdCBhL2h3L3N1bjR1LmMgYi9o
dy9zdW40dS5jCmluZGV4IDlmYmRhMjkuLjA1NmJiNGQgMTAwNjQ0Ci0tLSBhL2h3L3N1bjR1LmMK
KysrIGIvaHcvc3VuNHUuYwpAQCAtMjU0LDYgKzI1NCw3IEBAIHN0YXRpYyB1aW50NjRfdCBzdW40
dV9sb2FkX2tlcm5lbChjb25zdCBjaGFyICprZXJuZWxfZmlsZW5hbWUsCiAKIHZvaWQgY3B1X2No
ZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogeworICAgIENQVVN0YXRlICpjczsKICAgICB1
aW50MzJfdCBwaWwgPSBlbnYtPnBpbF9pbiB8CiAgICAgICAgICAgICAgICAgICAoZW52LT5zb2Z0
aW50ICYgfihTT0ZUSU5UX1RJTUVSIHwgU09GVElOVF9TVElNRVIpKTsKIApAQCAtMjYxLDYgKzI2
Miw3IEBAIHZvaWQgY3B1X2NoZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogICAgIGlmIChl
bnYtPml2ZWNfc3RhdHVzICYgMHgyMCkgewogICAgICAgICByZXR1cm47CiAgICAgfQorICAgIGNz
ID0gQ1BVKHNwYXJjX2Vudl9nZXRfY3B1KGVudikpOwogICAgIC8qIGNoZWNrIGlmIFRNIG9yIFNN
IGluIFNPRlRJTlQgYXJlIHNldAogICAgICAgIHNldHRpbmcgdGhlc2UgYWxzbyBjYXVzZXMgaW50
ZXJydXB0IDE0ICovCiAgICAgaWYgKGVudi0+c29mdGludCAmIChTT0ZUSU5UX1RJTUVSIHwgU09G
VElOVF9TVElNRVIpKSB7CkBAIC0yNzAsNyArMjcyLDcgQEAgdm9pZCBjcHVfY2hlY2tfaXJxcyhD
UFVTUEFSQ1N0YXRlICplbnYpCiAgICAgLyogVGhlIGJpdCBjb3JyZXNwb25kaW5nIHRvIHBzcnBp
bCBpcyAoMTw8IHBzcnBpbCksIHRoZSBuZXh0IGJpdAogICAgICAgIGlzICgyIDw8IHBzcnBpbCku
ICovCiAgICAgaWYgKHBpbCA8ICgyIDw8IGVudi0+cHNycGlsKSl7Ci0gICAgICAgIGlmIChlbnYt
PmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSB7CisgICAgICAgIGlmIChj
cy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKICAgICAgICAgICAg
IENQVUlSUV9EUFJJTlRGKCJSZXNldCBDUFUgSVJRIChjdXJyZW50IGludGVycnVwdCAleClcbiIs
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9pbmRleCk7CiAgICAg
ICAgICAgICBlbnYtPmludGVycnVwdF9pbmRleCA9IDA7CkBAIC0zMDIsNyArMzA0LDcgQEAgdm9p
ZCBjcHVfY2hlY2tfaXJxcyhDUFVTUEFSQ1N0YXRlICplbnYpCiAgICAgICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgICAgICB9CiAgICAgICAgIH0KLSAgICB9IGVsc2UgaWYgKGVudi0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpIHsKKyAgICB9IGVsc2UgaWYgKGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgewogICAgICAgICBDUFVJUlFf
RFBSSU5URigiSW50ZXJydXB0cyBkaXNhYmxlZCwgcGlsPSUwOHggcGlsX2luPSUwOHggc29mdGlu
dD0lMDh4ICIKICAgICAgICAgICAgICAgICAgICAgICAgImN1cnJlbnQgaW50ZXJydXB0ICV4XG4i
LAogICAgICAgICAgICAgICAgICAgICAgICBwaWwsIGVudi0+cGlsX2luLCBlbnYtPnNvZnRpbnQs
IGVudi0+aW50ZXJydXB0X2luZGV4KTsKQEAgLTMxMywyMiArMzE1LDI1IEBAIHZvaWQgY3B1X2No
ZWNrX2lycXMoQ1BVU1BBUkNTdGF0ZSAqZW52KQogCiBzdGF0aWMgdm9pZCBjcHVfa2lja19pcnEo
U1BBUkNDUFUgKmNwdSkKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVT
UEFSQ1N0YXRlICplbnYgPSAmY3B1LT5lbnY7CiAKLSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAg
Y3MtPmhhbHRlZCA9IDA7CiAgICAgY3B1X2NoZWNrX2lycXMoZW52KTsKLSAgICBxZW11X2NwdV9r
aWNrKENQVShjcHUpKTsKKyAgICBxZW11X2NwdV9raWNrKGNzKTsKIH0KIAogc3RhdGljIHZvaWQg
Y3B1X3NldF9pdmVjX2lycSh2b2lkICpvcGFxdWUsIGludCBpcnEsIGludCBsZXZlbCkKIHsKICAg
ICBTUEFSQ0NQVSAqY3B1ID0gb3BhcXVlOwogICAgIENQVVNQQVJDU3RhdGUgKmVudiA9ICZjcHUt
PmVudjsKKyAgICBDUFVTdGF0ZSAqY3M7CiAKICAgICBpZiAobGV2ZWwpIHsKICAgICAgICAgaWYg
KCEoZW52LT5pdmVjX3N0YXR1cyAmIDB4MjApKSB7CiAgICAgICAgICAgICBDUFVJUlFfRFBSSU5U
RigiUmFpc2UgSVZFQyBJUlEgJWRcbiIsIGlycSk7Ci0gICAgICAgICAgICBlbnYtPmhhbHRlZCA9
IDA7CisgICAgICAgICAgICBjcyA9IENQVShjcHUpOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9
IDA7CiAgICAgICAgICAgICBlbnYtPmludGVycnVwdF9pbmRleCA9IFRUX0lWRUM7CiAgICAgICAg
ICAgICBlbnYtPml2ZWNfc3RhdHVzIHw9IDB4MjA7CiAgICAgICAgICAgICBlbnYtPml2ZWNfZGF0
YVswXSA9ICgweDFmIDw8IDYpIHwgaXJxOwpkaWZmIC0tZ2l0IGEvaHcveGVuX21hY2hpbmVfcHYu
YyBiL2h3L3hlbl9tYWNoaW5lX3B2LmMKaW5kZXggNjZlODk4MS4uNGZlYzRmYyAxMDA2NDQKLS0t
IGEvaHcveGVuX21hY2hpbmVfcHYuYworKysgYi9ody94ZW5fbWFjaGluZV9wdi5jCkBAIC0zNiw3
ICszNiw3IEBAIHN0YXRpYyB2b2lkIHhlbl9pbml0X3B2KFFFTVVNYWNoaW5lSW5pdEFyZ3MgKmFy
Z3MpCiAgICAgY29uc3QgY2hhciAqa2VybmVsX2NtZGxpbmUgPSBhcmdzLT5rZXJuZWxfY21kbGlu
ZTsKICAgICBjb25zdCBjaGFyICppbml0cmRfZmlsZW5hbWUgPSBhcmdzLT5pbml0cmRfZmlsZW5h
bWU7CiAgICAgWDg2Q1BVICpjcHU7Ci0gICAgQ1BVWDg2U3RhdGUgKmVudjsKKyAgICBDUFVTdGF0
ZSAqY3M7CiAgICAgRHJpdmVJbmZvICpkaW5mbzsKICAgICBpbnQgaTsKIApAQCAtNDksOCArNDks
OCBAQCBzdGF0aWMgdm9pZCB4ZW5faW5pdF9wdihRRU1VTWFjaGluZUluaXRBcmdzICphcmdzKQog
I2VuZGlmCiAgICAgfQogICAgIGNwdSA9IGNwdV94ODZfaW5pdChjcHVfbW9kZWwpOwotICAgIGVu
diA9ICZjcHUtPmVudjsKLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MgPSBDUFUoY3B1KTsK
KyAgICBjcy0+aGFsdGVkID0gMTsKIAogICAgIC8qIEluaXRpYWxpemUgYmFja2VuZCBjb3JlICYg
ZHJpdmVycyAqLwogICAgIGlmICh4ZW5fYmVfaW5pdCgpICE9IDApIHsKZGlmZiAtLWdpdCBhL2h3
L3h0ZW5zYV9waWMuYyBiL2h3L3h0ZW5zYV9waWMuYwppbmRleCA5N2QzNmJlLi5kY2ExNWI0IDEw
MDY0NAotLS0gYS9ody94dGVuc2FfcGljLmMKKysrIGIvaHcveHRlbnNhX3BpYy5jCkBAIC00Nyw2
ICs0Nyw3IEBAIHZvaWQgeHRlbnNhX2FkdmFuY2VfY2NvdW50KENQVVh0ZW5zYVN0YXRlICplbnYs
IHVpbnQzMl90IGQpCiAKIHZvaWQgY2hlY2tfaW50ZXJydXB0cyhDUFVYdGVuc2FTdGF0ZSAqZW52
KQogeworICAgIENQVVN0YXRlICpjcyA9IENQVSh4dGVuc2FfZW52X2dldF9jcHUoZW52KSk7CiAg
ICAgaW50IG1pbmxldmVsID0geHRlbnNhX2dldF9jaW50bGV2ZWwoZW52KTsKICAgICB1aW50MzJf
dCBpbnRfc2V0X2VuYWJsZWQgPSBlbnYtPnNyZWdzW0lOVFNFVF0gJiBlbnYtPnNyZWdzW0lOVEVO
QUJMRV07CiAgICAgaW50IGxldmVsOwpAQCAtNTQsNyArNTUsNyBAQCB2b2lkIGNoZWNrX2ludGVy
cnVwdHMoQ1BVWHRlbnNhU3RhdGUgKmVudikKICAgICAvKiBJZiB0aGUgQ1BVIGlzIGhhbHRlZCBh
ZHZhbmNlIENDT1VOVCBhY2NvcmRpbmcgdG8gdGhlIHZtX2Nsb2NrIHRpbWUKICAgICAgKiBlbGFw
c2VkIHNpbmNlIHRoZSBtb21lbnQgd2hlbiBpdCB3YXMgYWR2YW5jZWQgbGFzdCB0aW1lLgogICAg
ICAqLwotICAgIGlmIChlbnYtPmhhbHRlZCkgeworICAgIGlmIChjcy0+aGFsdGVkKSB7CiAgICAg
ICAgIGludDY0X3Qgbm93ID0gcWVtdV9nZXRfY2xvY2tfbnModm1fY2xvY2spOwogCiAgICAgICAg
IHh0ZW5zYV9hZHZhbmNlX2Njb3VudChlbnYsCkBAIC0xMjcsMTEgKzEyOCwxMiBAQCBzdGF0aWMg
dm9pZCB4dGVuc2FfY2NvbXBhcmVfY2Iodm9pZCAqb3BhcXVlKQogewogICAgIFh0ZW5zYUNQVSAq
Y3B1ID0gb3BhcXVlOwogICAgIENQVVh0ZW5zYVN0YXRlICplbnYgPSAmY3B1LT5lbnY7CisgICAg
Q1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAKLSAgICBpZiAoZW52LT5oYWx0ZWQpIHsKKyAgICBp
ZiAoY3MtPmhhbHRlZCkgewogICAgICAgICBlbnYtPmhhbHRfY2xvY2sgPSBxZW11X2dldF9jbG9j
a19ucyh2bV9jbG9jayk7CiAgICAgICAgIHh0ZW5zYV9hZHZhbmNlX2Njb3VudChlbnYsIGVudi0+
d2FrZV9jY291bnQgLSBlbnYtPnNyZWdzW0NDT1VOVF0pOwotICAgICAgICBpZiAoIWNwdV9oYXNf
d29yayhDUFUoY3B1KSkpIHsKKyAgICAgICAgaWYgKCFjcHVfaGFzX3dvcmsoY3MpKSB7CiAgICAg
ICAgICAgICBlbnYtPnNyZWdzW0NDT1VOVF0gPSBlbnYtPndha2VfY2NvdW50ICsgMTsKICAgICAg
ICAgICAgIHh0ZW5zYV9yZWFybV9jY29tcGFyZV90aW1lcihlbnYpOwogICAgICAgICB9CmRpZmYg
LS1naXQgYS9pbmNsdWRlL2V4ZWMvY3B1LWRlZnMuaCBiL2luY2x1ZGUvZXhlYy9jcHUtZGVmcy5o
CmluZGV4IDNkYzk2NTYuLjBhZTk2N2EgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvZXhlYy9jcHUtZGVm
cy5oCisrKyBiL2luY2x1ZGUvZXhlYy9jcHUtZGVmcy5oCkBAIC0xNTYsOCArMTU2LDYgQEAgdHlw
ZWRlZiBzdHJ1Y3QgQ1BVV2F0Y2hwb2ludCB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YWNjZXNzZWQgKi8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgdGFyZ2V0
X3Vsb25nIG1lbV9pb192YWRkcjsgLyogdGFyZ2V0IHZpcnR1YWwgYWRkciBhdCB3aGljaCB0aGUg
ICAgICBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWVtb3J5IHdhcyBh
Y2Nlc3NlZCAqLyAgICAgICAgICAgICBcCi0gICAgdWludDMyX3QgaGFsdGVkOyAvKiBOb256ZXJv
IGlmIHRoZSBDUFUgaXMgaW4gc3VzcGVuZCBzdGF0ZSAqLyAgICAgICBcCi0gICAgdWludDMyX3Qg
aW50ZXJydXB0X3JlcXVlc3Q7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgQ1BVX0NPTU1PTl9UTEIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBcCiAgICAgc3RydWN0IFRyYW5zbGF0aW9uQmxvY2sgKnRiX2pt
cF9jYWNoZVtUQl9KTVBfQ0FDSEVfU0laRV07ICAgICAgICAgICBcCiAgICAgLyogYnVmZmVyIGZv
ciB0ZW1wb3JhcmllcyBpbiB0aGUgY29kZSBnZW5lcmF0b3IgKi8gICAgICAgICAgICAgICAgICBc
CmRpZmYgLS1naXQgYS9pbmNsdWRlL3FvbS9jcHUuaCBiL2luY2x1ZGUvcW9tL2NwdS5oCmluZGV4
IDY1ZTI0ZDMuLjMyNTgxZmEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvcW9tL2NwdS5oCisrKyBiL2lu
Y2x1ZGUvcW9tL2NwdS5oCkBAIC03Miw2ICs3Miw4IEBAIHN0cnVjdCBrdm1fcnVuOwogICogQGhv
c3RfdGlkOiBIb3N0IHRocmVhZCBJRC4KICAqIEBydW5uaW5nOiAjdHJ1ZSBpZiBDUFUgaXMgY3Vy
cmVudGx5IHJ1bm5pbmcgKHVzZXJtb2RlKS4KICAqIEBjcmVhdGVkOiBJbmRpY2F0ZXMgd2hldGhl
ciB0aGUgQ1BVIHRocmVhZCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgY3JlYXRlZC4KKyAqIEBpbnRl
cnJ1cHRfcmVxdWVzdDogSW5kaWNhdGVzIGEgcGVuZGluZyBpbnRlcnJ1cHQgcmVxdWVzdC4KKyAq
IEBoYWx0ZWQ6IE5vbnplcm8gaWYgdGhlIENQVSBpcyBpbiBzdXNwZW5kZWQgc3RhdGUuCiAgKiBA
c3RvcDogSW5kaWNhdGVzIGEgcGVuZGluZyBzdG9wIHJlcXVlc3QuCiAgKiBAc3RvcHBlZDogSW5k
aWNhdGVzIHRoZSBDUFUgaGFzIGJlZW4gYXJ0aWZpY2lhbGx5IHN0b3BwZWQuCiAgKiBAZW52X3B0
cjogUG9pbnRlciB0byBzdWJjbGFzcy1zcGVjaWZpYyBDUFVBcmNoU3RhdGUgZmllbGQuCkBAIC0x
MDMsNiArMTA1LDcgQEAgc3RydWN0IENQVVN0YXRlIHsKICAgICBib29sIHN0b3A7CiAgICAgYm9v
bCBzdG9wcGVkOwogICAgIHZvbGF0aWxlIHNpZ19hdG9taWNfdCBleGl0X3JlcXVlc3Q7CisgICAg
dWludDMyX3QgaW50ZXJydXB0X3JlcXVlc3Q7CiAKICAgICB2b2lkICplbnZfcHRyOyAvKiBDUFVB
cmNoU3RhdGUgKi8KICAgICBzdHJ1Y3QgVHJhbnNsYXRpb25CbG9jayAqY3VycmVudF90YjsKQEAg
LTExNCw2ICsxMTcsNyBAQCBzdHJ1Y3QgQ1BVU3RhdGUgewogCiAgICAgLyogVE9ETyBNb3ZlIGNv
bW1vbiBmaWVsZHMgZnJvbSBDUFVBcmNoU3RhdGUgaGVyZS4gKi8KICAgICBpbnQgY3B1X2luZGV4
OyAvKiB1c2VkIGJ5IGFscGhhIFRDRyAqLworICAgIHVpbnQzMl90IGhhbHRlZDsgLyogdXNlZCBi
eSBhbHBoYSwgY3JpcywgcHBjIFRDRyAqLwogfTsKIAogCmRpZmYgLS1naXQgYS9rdm0tYWxsLmMg
Yi9rdm0tYWxsLmMKaW5kZXggNGRlY2ZkYy4uMmI3NjFlMCAxMDA2NDQKLS0tIGEva3ZtLWFsbC5j
CisrKyBiL2t2bS1hbGwuYwpAQCAtODMwLDcgKzgzMCw3IEBAIHN0YXRpYyB2b2lkIGt2bV9oYW5k
bGVfaW50ZXJydXB0KENQVUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKIHsKICAgICBDUFVTdGF0
ZSAqY3B1ID0gRU5WX0dFVF9DUFUoZW52KTsKIAotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3Qg
fD0gbWFzazsKKyAgICBjcHUtPmludGVycnVwdF9yZXF1ZXN0IHw9IG1hc2s7CiAKICAgICBpZiAo
IXFlbXVfY3B1X2lzX3NlbGYoY3B1KSkgewogICAgICAgICBxZW11X2NwdV9raWNrKGNwdSk7CmRp
ZmYgLS1naXQgYS9xb20vY3B1LmMgYi9xb20vY3B1LmMKaW5kZXggMGEyMTk0ZC4uMGFhOWJlNyAx
MDA2NDQKLS0tIGEvcW9tL2NwdS5jCisrKyBiL3FvbS9jcHUuYwpAQCAtMzMsNyArMzMsOSBAQCB2
b2lkIGNwdV9yZXNldChDUFVTdGF0ZSAqY3B1KQogc3RhdGljIHZvaWQgY3B1X2NvbW1vbl9yZXNl
dChDUFVTdGF0ZSAqY3B1KQogewogICAgIGNwdS0+ZXhpdF9yZXF1ZXN0ID0gMDsKKyAgICBjcHUt
PmludGVycnVwdF9yZXF1ZXN0ID0gMDsKICAgICBjcHUtPmN1cnJlbnRfdGIgPSBOVUxMOworICAg
IGNwdS0+aGFsdGVkID0gMDsKIH0KIAogT2JqZWN0Q2xhc3MgKmNwdV9jbGFzc19ieV9uYW1lKGNv
bnN0IGNoYXIgKnR5cGVuYW1lLCBjb25zdCBjaGFyICpjcHVfbW9kZWwpCmRpZmYgLS1naXQgYS90
YXJnZXQtYWxwaGEvY3B1LmggYi90YXJnZXQtYWxwaGEvY3B1LmgKaW5kZXggZjFkYjY1MS4uOTBm
NzhhYyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWFscGhhL2NwdS5oCisrKyBiL3RhcmdldC1hbHBoYS9j
cHUuaApAQCAtNTE3LDggKzUxNyw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBjcHVfc2V0X3RscyhD
UFVBbHBoYVN0YXRlICplbnYsIHRhcmdldF91bG9uZyBuZXd0bHMpCiAKIHN0YXRpYyBpbmxpbmUg
Ym9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVBbHBoYVN0YXRlICpl
bnYgPSAmQUxQSEFfQ1BVKGNwdSktPmVudjsKLQogICAgIC8qIEhlcmUgd2UgYXJlIGNoZWNraW5n
IHRvIHNlZSBpZiB0aGUgQ1BVIHNob3VsZCB3YWtlIHVwIGZyb20gSEFMVC4KICAgICAgICBXZSB3
aWxsIGhhdmUgZ290dGVuIGludG8gdGhpcyBzdGF0ZSBvbmx5IGZvciBXVElOVCBmcm9tIFBBTG1v
ZGUuICAqLwogICAgIC8qID8/PyBJJ20gbm90IHN1cmUgaG93IHRoZSBJUEwgc3RhdGUgd29ya3Mg
d2l0aCBXVElOVCB0byBrZWVwIGEgQ1BVCkBAIC01MjYsNyArNTI0LDcgQEAgc3RhdGljIGlubGlu
ZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAqY3B1KQogICAgICAgIGFzc3VtZSB0aGF0IGlm
IGEgQ1BVIHJlYWxseSB3YW50cyB0byBzdGF5IGFzbGVlcCwgaXQgd2lsbCBtYXNrCiAgICAgICAg
aW50ZXJydXB0cyBhdCB0aGUgY2hpcHNldCBsZXZlbCwgd2hpY2ggd2lsbCBwcmV2ZW50IHRoZXNl
IGJpdHMKICAgICAgICBmcm9tIGJlaW5nIHNldCBpbiB0aGUgZmlyc3QgcGxhY2UuICAqLwotICAg
IHJldHVybiBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRAorICAg
IHJldHVybiBjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ1BVX0lOVEVSUlVQVF9USU1FUgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ1BVX0lOVEVSUlVQVF9TTVAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IENQVV9JTlRFUlJVUFRfTUNI
Syk7CmRpZmYgLS1naXQgYS90YXJnZXQtYWxwaGEvdHJhbnNsYXRlLmMgYi90YXJnZXQtYWxwaGEv
dHJhbnNsYXRlLmMKaW5kZXggZjhmNzY5NS4uOTVhZTg4YSAxMDA2NDQKLS0tIGEvdGFyZ2V0LWFs
cGhhL3RyYW5zbGF0ZS5jCisrKyBiL3RhcmdldC1hbHBoYS90cmFuc2xhdGUuYwpAQCAtMTY4Niw3
ICsxNjg2LDggQEAgc3RhdGljIEV4aXRTdGF0dXMgZ2VuX210cHIoRGlzYXNDb250ZXh0ICpjdHgs
IGludCByYiwgaW50IHJlZ25vKQogICAgIGNhc2UgMjUzOgogICAgICAgICAvKiBXQUlUICovCiAg
ICAgICAgIHRtcCA9IHRjZ19jb25zdF9pNjQoMSk7Ci0gICAgICAgIHRjZ19nZW5fc3QzMl9pNjQo
dG1wLCBjcHVfZW52LCBvZmZzZXRvZihDUFVBbHBoYVN0YXRlLCBoYWx0ZWQpKTsKKyAgICAgICAg
dGNnX2dlbl9zdDMyX2k2NCh0bXAsIGNwdV9lbnYsIC1vZmZzZXRvZihBbHBoYUNQVSwgZW52KSAr
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZmZzZXRvZihDUFVTdGF0
ZSwgaGFsdGVkKSk7CiAgICAgICAgIHJldHVybiBnZW5fZXhjcChjdHgsIEVYQ1BfSExULCAwKTsK
IAogICAgIGNhc2UgMjUyOgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWFybS9jcHUuaCBiL3RhcmdldC1h
cm0vY3B1LmgKaW5kZXggMjkwMmJhNS4uN2M0NzQ2NyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWFybS9j
cHUuaAorKysgYi90YXJnZXQtYXJtL2NwdS5oCkBAIC03MjEsOSArNzIxLDcgQEAgc3RhdGljIGlu
bGluZSB2b2lkIGNwdV9nZXRfdGJfY3B1X3N0YXRlKENQVUFSTVN0YXRlICplbnYsIHRhcmdldF91
bG9uZyAqcGMsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNw
dSkKIHsKLSAgICBDUFVBUk1TdGF0ZSAqZW52ID0gJkFSTV9DUFUoY3B1KS0+ZW52OwotCi0gICAg
cmV0dXJuIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJgorICAgIHJldHVybiBjcHUtPmludGVycnVw
dF9yZXF1ZXN0ICYKICAgICAgICAgKENQVV9JTlRFUlJVUFRfRklRIHwgQ1BVX0lOVEVSUlVQVF9I
QVJEIHwgQ1BVX0lOVEVSUlVQVF9FWElUVEIpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtYXJt
L2hlbHBlci5jIGIvdGFyZ2V0LWFybS9oZWxwZXIuYwppbmRleCBlOTdlMWE1Li42NTUwOTNkIDEw
MDY0NAotLS0gYS90YXJnZXQtYXJtL2hlbHBlci5jCisrKyBiL3RhcmdldC1hcm0vaGVscGVyLmMK
QEAgLTE4MDIsNiArMTgwMiw3IEBAIHN0YXRpYyB2b2lkIGRvX2ludGVycnVwdF92N20oQ1BVQVJN
U3RhdGUgKmVudikKIC8qIEhhbmRsZSBhIENQVSBleGNlcHRpb24uICAqLwogdm9pZCBkb19pbnRl
cnJ1cHQoQ1BVQVJNU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CiAgICAgdWludDMy
X3QgYWRkcjsKICAgICB1aW50MzJfdCBtYXNrOwogICAgIGludCBuZXdfbW9kZTsKQEAgLTE5MDgs
NyArMTkwOSw4IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVUFSTVN0YXRlICplbnYpCiAgICAgfQog
ICAgIGVudi0+cmVnc1sxNF0gPSBlbnYtPnJlZ3NbMTVdICsgb2Zmc2V0OwogICAgIGVudi0+cmVn
c1sxNV0gPSBhZGRyOwotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQ
VF9FWElUVEI7CisgICAgY3MgPSBDUFUoYXJtX2Vudl9nZXRfY3B1KGVudikpOworICAgIGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKIH0KIAogLyogQ2hlY2sg
c2VjdGlvbi9wYWdlIGFjY2VzcyBwZXJtaXNzaW9ucy4KZGlmZiAtLWdpdCBhL3RhcmdldC1hcm0v
b3BfaGVscGVyLmMgYi90YXJnZXQtYXJtL29wX2hlbHBlci5jCmluZGV4IGE1MjIzMTMuLmE5MThl
NWIgMTAwNjQ0Ci0tLSBhL3RhcmdldC1hcm0vb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LWFybS9v
cF9oZWxwZXIuYwpAQCAtMjE4LDggKzIxOCwxMCBAQCB1aW50MzJfdCBIRUxQRVIodXNhdDE2KShD
UFVBUk1TdGF0ZSAqZW52LCB1aW50MzJfdCB4LCB1aW50MzJfdCBzaGlmdCkKIAogdm9pZCBIRUxQ
RVIod2ZpKShDUFVBUk1TdGF0ZSAqZW52KQogeworICAgIENQVVN0YXRlICpjcyA9IENQVShhcm1f
ZW52X2dldF9jcHUoZW52KSk7CisKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExU
OwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcy0+aGFsdGVkID0gMTsKICAgICBjcHVfbG9v
cF9leGl0KGVudik7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC1jcmlzL2NwdS5oIGIvdGFyZ2V0
LWNyaXMvY3B1LmgKaW5kZXggZWJmMmQ0MC4uMmZjN2M1YyAxMDA2NDQKLS0tIGEvdGFyZ2V0LWNy
aXMvY3B1LmgKKysrIGIvdGFyZ2V0LWNyaXMvY3B1LmgKQEAgLTI4OSw5ICsyODksNyBAQCB2b2lk
IGNyaXNfY3B1X2xpc3QoRklMRSAqZiwgZnByaW50Zl9mdW5jdGlvbiBjcHVfZnByaW50Zik7CiAK
IHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBD
UFVDUklTU3RhdGUgKmVudiA9ICZDUklTX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52
LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfCBDUFVfSU5URVJSVVBU
X05NSSk7CisgICAgcmV0dXJuIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQ
VF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9OTUkpOwogfQogCiAjaW5jbHVkZSAiZXhlYy9leGVjLWFs
bC5oIgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWNyaXMvaGVscGVyLmMgYi90YXJnZXQtY3Jpcy9oZWxw
ZXIuYwppbmRleCBkZTA0MTQzLi44ODVmNjdmIDEwMDY0NAotLS0gYS90YXJnZXQtY3Jpcy9oZWxw
ZXIuYworKysgYi90YXJnZXQtY3Jpcy9oZWxwZXIuYwpAQCAtNjYsNiArNjYsNyBAQCBzdGF0aWMg
dm9pZCBjcmlzX3NoaWZ0X2NjcyhDUFVDUklTU3RhdGUgKmVudikKIGludCBjcHVfY3Jpc19oYW5k
bGVfbW11X2ZhdWx0KENQVUNSSVNTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgYWRkcmVzcywgaW50
IHJ3LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IG1tdV9pZHgpCiB7CisgICAg
RChDUFVTdGF0ZSAqY3B1ID0gQ1BVKGNyaXNfZW52X2dldF9jcHUoZW52KSkpOwogICAgIHN0cnVj
dCBjcmlzX21tdV9yZXN1bHQgcmVzOwogICAgIGludCBwcm90LCBtaXNzOwogICAgIGludCByID0g
LTE7CkBAIC05OSw3ICsxMDAsNyBAQCBpbnQgY3B1X2NyaXNfaGFuZGxlX21tdV9mYXVsdChDUFVD
UklTU3RhdGUgKmVudiwgdGFyZ2V0X3Vsb25nIGFkZHJlc3MsIGludCBydywKICAgICB9CiAgICAg
aWYgKHIgPiAwKSB7CiAgICAgICAgIERfTE9HKCIlcyByZXR1cm5zICVkIGlycXJlcT0leCBhZGRy
PSV4IHBoeT0leCB2ZWM9JXggcGM9JXhcbiIsCi0gICAgICAgICAgICAgIF9fZnVuY19fLCByLCBl
bnYtPmludGVycnVwdF9yZXF1ZXN0LCBhZGRyZXNzLCByZXMucGh5LAorICAgICAgICAgICAgICBf
X2Z1bmNfXywgciwgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCwgYWRkcmVzcywgcmVzLnBoeSwKICAg
ICAgICAgICAgICAgcmVzLmJmX3ZlYywgZW52LT5wYyk7CiAgICAgfQogICAgIHJldHVybiByOwpA
QCAtMTA3LDExICsxMDgsMTIgQEAgaW50IGNwdV9jcmlzX2hhbmRsZV9tbXVfZmF1bHQoQ1BVQ1JJ
U1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBhZGRyZXNzLCBpbnQgcncsCiAKIHN0YXRpYyB2b2lk
IGRvX2ludGVycnVwdHYxMChDUFVDUklTU3RhdGUgKmVudikKIHsKKyAgICBEKENQVVN0YXRlICpj
cyA9IENQVShjcmlzX2Vudl9nZXRfY3B1KGVudikpKTsKICAgICBpbnQgZXhfdmVjID0gLTE7CiAK
ICAgICBEX0xPRygiZXhjZXB0aW9uIGluZGV4PSVkIGludGVycnVwdF9yZXE9JWRcbiIsCiAgICAg
ICAgICAgZW52LT5leGNlcHRpb25faW5kZXgsCi0gICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdCk7CisgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0KTsKIAogICAgIGFzc2VydCgh
KGVudi0+cHJlZ3NbUFJfQ0NTXSAmIFBGSVhfRkxBRykpOwogICAgIHN3aXRjaCAoZW52LT5leGNl
cHRpb25faW5kZXgpIHsKQEAgLTE2Miw2ICsxNjQsNyBAQCBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1
cHR2MTAoQ1BVQ1JJU1N0YXRlICplbnYpCiAKIHZvaWQgZG9faW50ZXJydXB0KENQVUNSSVNTdGF0
ZSAqZW52KQogeworICAgIEQoQ1BVU3RhdGUgKmNzID0gQ1BVKGNyaXNfZW52X2dldF9jcHUoZW52
KSkpOwogICAgIGludCBleF92ZWMgPSAtMTsKIAogICAgIGlmIChlbnYtPnByZWdzW1BSX1ZSXSA8
IDMyKSB7CkBAIC0xNzAsNyArMTczLDcgQEAgdm9pZCBkb19pbnRlcnJ1cHQoQ1BVQ1JJU1N0YXRl
ICplbnYpCiAKICAgICBEX0xPRygiZXhjZXB0aW9uIGluZGV4PSVkIGludGVycnVwdF9yZXE9JWRc
biIsCiAgICAgICAgICAgZW52LT5leGNlcHRpb25faW5kZXgsCi0gICAgICAgICAgZW52LT5pbnRl
cnJ1cHRfcmVxdWVzdCk7CisgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0KTsKIAogICAg
IHN3aXRjaCAoZW52LT5leGNlcHRpb25faW5kZXgpIHsKICAgICBjYXNlIEVYQ1BfQlJFQUs6CmRp
ZmYgLS1naXQgYS90YXJnZXQtY3Jpcy90cmFuc2xhdGUuYyBiL3RhcmdldC1jcmlzL3RyYW5zbGF0
ZS5jCmluZGV4IDE0YzE2N2YuLjRiNmQ2YzggMTAwNjQ0Ci0tLSBhL3RhcmdldC1jcmlzL3RyYW5z
bGF0ZS5jCisrKyBiL3RhcmdldC1jcmlzL3RyYW5zbGF0ZS5jCkBAIC0yODg4LDcgKzI4ODgsOCBA
QCBzdGF0aWMgaW50IGRlY19yZmVfZXRjKENQVUNSSVNTdGF0ZSAqZW52LCBEaXNhc0NvbnRleHQg
KmRjKQogICAgIGNyaXNfY2NfbWFzayhkYywgMCk7CiAKICAgICBpZiAoZGMtPm9wMiA9PSAxNSkg
ewotICAgICAgICB0X2dlbl9tb3ZfZW52X1ROKGhhbHRlZCwgdGNnX2NvbnN0X3RsKDEpKTsKKyAg
ICAgICAgdGNnX2dlbl9zdF9pMzIodGNnX2NvbnN0X2kzMigxKSwgY3B1X2VudiwKKyAgICAgICAg
ICAgICAgICAgICAgICAgLW9mZnNldG9mKENSSVNDUFUsIGVudikgKyBvZmZzZXRvZihDUFVTdGF0
ZSwgaGFsdGVkKSk7CiAgICAgICAgIHRjZ19nZW5fbW92aV90bChlbnZfcGMsIGRjLT5wYyArIDIp
OwogICAgICAgICB0X2dlbl9yYWlzZV9leGNlcHRpb24oRVhDUF9ITFQpOwogICAgICAgICByZXR1
cm4gMjsKZGlmZiAtLWdpdCBhL3RhcmdldC1pMzg2L2NwdS5jIGIvdGFyZ2V0LWkzODYvY3B1LmMK
aW5kZXggOWIxZjdkMS4uNTdiYTg0ZiAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvY3B1LmMKKysr
IGIvdGFyZ2V0LWkzODYvY3B1LmMKQEAgLTIwMTQsNyArMjAxNCw3IEBAIHN0YXRpYyB2b2lkIHg4
Nl9jcHVfcmVzZXQoQ1BVU3RhdGUgKnMpCiAgICAgICAgIGFwaWNfZGVzaWduYXRlX2JzcChlbnYt
PmFwaWNfc3RhdGUpOwogICAgIH0KIAotICAgIGVudi0+aGFsdGVkID0gIWNwdV9pc19ic3AoY3B1
KTsKKyAgICBzLT5oYWx0ZWQgPSAhY3B1X2lzX2JzcChjcHUpOwogI2VuZGlmCiB9CiAKZGlmZiAt
LWdpdCBhL3RhcmdldC1pMzg2L2NwdS5oIGIvdGFyZ2V0LWkzODYvY3B1LmgKaW5kZXggMGMxYzVj
NS4uYmY2ZTIxMCAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvY3B1LmgKKysrIGIvdGFyZ2V0LWkz
ODYvY3B1LmgKQEAgLTk2Nyw2ICs5NjcsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgY3B1X3g4Nl9s
b2FkX3NlZ19jYWNoZShDUFVYODZTdGF0ZSAqZW52LAogc3RhdGljIGlubGluZSB2b2lkIGNwdV94
ODZfbG9hZF9zZWdfY2FjaGVfc2lwaShYODZDUFUgKmNwdSwKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IHNpcGlfdmVjdG9yKQogeworICAgIENQVVN0
YXRlICpjcyA9IENQVShjcHUpOwogICAgIENQVVg4NlN0YXRlICplbnYgPSAmY3B1LT5lbnY7CiAK
ICAgICBlbnYtPmVpcCA9IDA7CkBAIC05NzQsNyArOTc1LDcgQEAgc3RhdGljIGlubGluZSB2b2lk
IGNwdV94ODZfbG9hZF9zZWdfY2FjaGVfc2lwaShYODZDUFUgKmNwdSwKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHNpcGlfdmVjdG9yIDw8IDEyLAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgZW52LT5zZWdzW1JfQ1NdLmxpbWl0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgZW52
LT5zZWdzW1JfQ1NdLmZsYWdzKTsKLSAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgY3MtPmhhbHRl
ZCA9IDA7CiB9CiAKIGludCBjcHVfeDg2X2dldF9kZXNjcl9kZWJ1ZyhDUFVYODZTdGF0ZSAqZW52
LCB1bnNpZ25lZCBpbnQgc2VsZWN0b3IsCkBAIC0xMTY2LDE3ICsxMTY3LDE4IEBAIHN0YXRpYyBp
bmxpbmUgdm9pZCBjcHVfY2xvbmVfcmVncyhDUFVYODZTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcg
bmV3c3ApCiAjaW5jbHVkZSAiaHcvYXBpYy5oIgogI2VuZGlmCiAKLXN0YXRpYyBpbmxpbmUgYm9v
bCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKK3N0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFz
X3dvcmsoQ1BVU3RhdGUgKmNzKQogewotICAgIENQVVg4NlN0YXRlICplbnYgPSAmWDg2X0NQVShj
cHUpLT5lbnY7CisgICAgWDg2Q1BVICpjcHUgPSBYODZfQ1BVKGNzKTsKKyAgICBDUFVYODZTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgcmV0dXJuICgoZW52LT5pbnRlcnJ1cHRfcmVxdWVz
dCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQ1BVX0lOVEVSUlVQVF9QT0xMKSkgJiYKKyAgICByZXR1cm4gKChjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9IQVJEIHwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9QT0xMKSkgJiYKICAgICAgICAgICAgIChl
bnYtPmVmbGFncyAmIElGX01BU0spKSB8fAotICAgICAgICAgICAoZW52LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmIChDUFVfSU5URVJSVVBUX05NSSB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIENQVV9JTlRFUlJVUFRfSU5JVCB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfU0lQSSB8Ci0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfTUNFKSk7CisgICAgICAgICAgIChjcy0+aW50
ZXJydXB0X3JlcXVlc3QgJiAoQ1BVX0lOVEVSUlVQVF9OTUkgfAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIENQVV9JTlRFUlJVUFRfSU5JVCB8CisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9TSVBJIHwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBDUFVfSU5URVJSVVBUX01DRSkpOwogfQogCiAjaW5jbHVk
ZSAiZXhlYy9leGVjLWFsbC5oIgpkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYvaGVscGVyLmMgYi90
YXJnZXQtaTM4Ni9oZWxwZXIuYwppbmRleCA4MmE3MzFjLi5iNDlhMGZjIDEwMDY0NAotLS0gYS90
YXJnZXQtaTM4Ni9oZWxwZXIuYworKysgYi90YXJnZXQtaTM4Ni9oZWxwZXIuYwpAQCAtMTgyLDYg
KzE4Miw3IEBAIGRvbmU6CiB2b2lkIGNwdV9kdW1wX3N0YXRlKENQVVg4NlN0YXRlICplbnYsIEZJ
TEUgKmYsIGZwcmludGZfZnVuY3Rpb24gY3B1X2ZwcmludGYsCiAgICAgICAgICAgICAgICAgICAg
IGludCBmbGFncykKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoeDg2X2Vudl9nZXRfY3B1KGVu
dikpOwogICAgIGludCBlZmxhZ3MsIGksIG5iOwogICAgIGNoYXIgY2Nfb3BfbmFtZVszMl07CiAg
ICAgc3RhdGljIGNvbnN0IGNoYXIgKnNlZ19uYW1lWzZdID0geyAiRVMiLCAiQ1MiLCAiU1MiLCAi
RFMiLCAiRlMiLCAiR1MiIH07CkBAIC0yMjUsNyArMjI2LDcgQEAgdm9pZCBjcHVfZHVtcF9zdGF0
ZShDUFVYODZTdGF0ZSAqZW52LCBGSUxFICpmLCBmcHJpbnRmX2Z1bmN0aW9uIGNwdV9mcHJpbnRm
LAogICAgICAgICAgICAgICAgICAgICAoZW52LT5oZmxhZ3MgPj4gSEZfSU5ISUJJVF9JUlFfU0hJ
RlQpICYgMSwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+YTIwX21hc2sgPj4gMjApICYgMSwK
ICAgICAgICAgICAgICAgICAgICAgKGVudi0+aGZsYWdzID4+IEhGX1NNTV9TSElGVCkgJiAxLAot
ICAgICAgICAgICAgICAgICAgICBlbnYtPmhhbHRlZCk7CisgICAgICAgICAgICAgICAgICAgIGNz
LT5oYWx0ZWQpOwogICAgIH0gZWxzZQogI2VuZGlmCiAgICAgewpAQCAtMjUyLDcgKzI1Myw3IEBA
IHZvaWQgY3B1X2R1bXBfc3RhdGUoQ1BVWDg2U3RhdGUgKmVudiwgRklMRSAqZiwgZnByaW50Zl9m
dW5jdGlvbiBjcHVfZnByaW50ZiwKICAgICAgICAgICAgICAgICAgICAgKGVudi0+aGZsYWdzID4+
IEhGX0lOSElCSVRfSVJRX1NISUZUKSAmIDEsCiAgICAgICAgICAgICAgICAgICAgIChlbnYtPmEy
MF9tYXNrID4+IDIwKSAmIDEsCiAgICAgICAgICAgICAgICAgICAgIChlbnYtPmhmbGFncyA+PiBI
Rl9TTU1fU0hJRlQpICYgMSwKLSAgICAgICAgICAgICAgICAgICAgZW52LT5oYWx0ZWQpOworICAg
ICAgICAgICAgICAgICAgICBjcy0+aGFsdGVkKTsKICAgICB9CiAKICAgICBmb3IoaSA9IDA7IGkg
PCA2OyBpKyspIHsKQEAgLTEyODEsMTIgKzEyODIsMTMgQEAgaW50IGNwdV94ODZfZ2V0X2Rlc2Ny
X2RlYnVnKENQVVg4NlN0YXRlICplbnYsIHVuc2lnbmVkIGludCBzZWxlY3RvciwKICNpZiAhZGVm
aW5lZChDT05GSUdfVVNFUl9PTkxZKQogdm9pZCBkb19jcHVfaW5pdChYODZDUFUgKmNwdSkKIHsK
KyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVYODZTdGF0ZSAqZW52ID0gJmNw
dS0+ZW52OwotICAgIGludCBzaXBpID0gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRF
UlJVUFRfU0lQSTsKKyAgICBpbnQgc2lwaSA9IGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9J
TlRFUlJVUFRfU0lQSTsKICAgICB1aW50NjRfdCBwYXQgPSBlbnYtPnBhdDsKIAotICAgIGNwdV9y
ZXNldChDUFUoY3B1KSk7Ci0gICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCA9IHNpcGk7CisgICAg
Y3B1X3Jlc2V0KGNzKTsKKyAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgPSBzaXBpOwogICAgIGVu
di0+cGF0ID0gcGF0OwogICAgIGFwaWNfaW5pdF9yZXNldChlbnYtPmFwaWNfc3RhdGUpOwogfQpk
aWZmIC0tZ2l0IGEvdGFyZ2V0LWkzODYva3ZtLmMgYi90YXJnZXQtaTM4Ni9rdm0uYwppbmRleCAw
Y2Y0MTNkLi5kZjMwZmE2IDEwMDY0NAotLS0gYS90YXJnZXQtaTM4Ni9rdm0uYworKysgYi90YXJn
ZXQtaTM4Ni9rdm0uYwpAQCAtMTQ2MCwxNyArMTQ2MCwxOCBAQCBzdGF0aWMgaW50IGt2bV9wdXRf
bXBfc3RhdGUoWDg2Q1BVICpjcHUpCiAKIHN0YXRpYyBpbnQga3ZtX2dldF9tcF9zdGF0ZShYODZD
UFUgKmNwdSkKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVYODZTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogICAgIHN0cnVjdCBrdm1fbXBfc3RhdGUgbXBfc3RhdGU7CiAg
ICAgaW50IHJldDsKIAotICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKENQVShjcHUpLCBLVk1fR0VU
X01QX1NUQVRFLCAmbXBfc3RhdGUpOworICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKGNzLCBLVk1f
R0VUX01QX1NUQVRFLCAmbXBfc3RhdGUpOwogICAgIGlmIChyZXQgPCAwKSB7CiAgICAgICAgIHJl
dHVybiByZXQ7CiAgICAgfQogICAgIGVudi0+bXBfc3RhdGUgPSBtcF9zdGF0ZS5tcF9zdGF0ZTsK
ICAgICBpZiAoa3ZtX2lycWNoaXBfaW5fa2VybmVsKCkpIHsKLSAgICAgICAgZW52LT5oYWx0ZWQg
PSAobXBfc3RhdGUubXBfc3RhdGUgPT0gS1ZNX01QX1NUQVRFX0hBTFRFRCk7CisgICAgICAgIGNz
LT5oYWx0ZWQgPSAobXBfc3RhdGUubXBfc3RhdGUgPT0gS1ZNX01QX1NUQVRFX0hBTFRFRCk7CiAg
ICAgfQogICAgIHJldHVybiAwOwogfQpAQCAtMTc2Miw4ICsxNzYzLDggQEAgdm9pZCBrdm1fYXJj
aF9wcmVfcnVuKENQVVN0YXRlICpjcHUsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAgICAgaW50IHJl
dDsKIAogICAgIC8qIEluamVjdCBOTUkgKi8KLSAgICBpZiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVz
dCAmIENQVV9JTlRFUlJVUFRfTk1JKSB7Ci0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3Qg
Jj0gfkNQVV9JTlRFUlJVUFRfTk1JOworICAgIGlmIChjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYg
Q1BVX0lOVEVSUlVQVF9OTUkpIHsKKyAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+
Q1BVX0lOVEVSUlVQVF9OTUk7CiAgICAgICAgIERQUklOVEYoImluamVjdGVkIE5NSVxuIik7CiAg
ICAgICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKGNwdSwgS1ZNX05NSSk7CiAgICAgICAgIGlmIChy
ZXQgPCAwKSB7CkBAIC0xNzc1LDE4ICsxNzc2LDE4IEBAIHZvaWQga3ZtX2FyY2hfcHJlX3J1bihD
UFVTdGF0ZSAqY3B1LCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogICAgIGlmICgha3ZtX2lycWNoaXBf
aW5fa2VybmVsKCkpIHsKICAgICAgICAgLyogRm9yY2UgdGhlIFZDUFUgb3V0IG9mIGl0cyBpbm5l
ciBsb29wIHRvIHByb2Nlc3MgYW55IElOSVQgcmVxdWVzdHMKICAgICAgICAgICogb3IgcGVuZGlu
ZyBUUFIgYWNjZXNzIHJlcG9ydHMuICovCi0gICAgICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICYKKyAgICAgICAgaWYgKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJgogICAgICAgICAgICAg
KENQVV9JTlRFUlJVUFRfSU5JVCB8IENQVV9JTlRFUlJVUFRfVFBSKSkgewogICAgICAgICAgICAg
Y3B1LT5leGl0X3JlcXVlc3QgPSAxOwogICAgICAgICB9CiAKICAgICAgICAgLyogVHJ5IHRvIGlu
amVjdCBhbiBpbnRlcnJ1cHQgaWYgdGhlIGd1ZXN0IGNhbiBhY2NlcHQgaXQgKi8KICAgICAgICAg
aWYgKHJ1bi0+cmVhZHlfZm9yX2ludGVycnVwdF9pbmplY3Rpb24gJiYKLSAgICAgICAgICAgIChl
bnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgICAgICAg
ICAgKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAg
ICAgICAgICAoZW52LT5lZmxhZ3MgJiBJRl9NQVNLKSkgewogICAgICAgICAgICAgaW50IGlycTsK
IAotICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9I
QVJEOworICAgICAgICAgICAgY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQ
VF9IQVJEOwogICAgICAgICAgICAgaXJxID0gY3B1X2dldF9waWNfaW50ZXJydXB0KGVudik7CiAg
ICAgICAgICAgICBpZiAoaXJxID49IDApIHsKICAgICAgICAgICAgICAgICBzdHJ1Y3Qga3ZtX2lu
dGVycnVwdCBpbnRyOwpAQCAtMTgwNiw3ICsxODA3LDcgQEAgdm9pZCBrdm1fYXJjaF9wcmVfcnVu
KENQVVN0YXRlICpjcHUsIHN0cnVjdCBrdm1fcnVuICpydW4pCiAgICAgICAgICAqIGludGVycnVw
dCwgcmVxdWVzdCBhbiBpbnRlcnJ1cHQgd2luZG93IGV4aXQuICBUaGlzIHdpbGwKICAgICAgICAg
ICogY2F1c2UgYSByZXR1cm4gdG8gdXNlcnNwYWNlIGFzIHNvb24gYXMgdGhlIGd1ZXN0IGlzIHJl
YWR5IHRvCiAgICAgICAgICAqIHJlY2VpdmUgaW50ZXJydXB0cy4gKi8KLSAgICAgICAgaWYgKChl
bnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSkgeworICAgICAgICBp
ZiAoKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpKSB7CiAgICAg
ICAgICAgICBydW4tPnJlcXVlc3RfaW50ZXJydXB0X3dpbmRvdyA9IDE7CiAgICAgICAgIH0gZWxz
ZSB7CiAgICAgICAgICAgICBydW4tPnJlcXVlc3RfaW50ZXJydXB0X3dpbmRvdyA9IDA7CkBAIC0x
ODM2LDExICsxODM3LDExIEBAIGludCBrdm1fYXJjaF9wcm9jZXNzX2FzeW5jX2V2ZW50cyhDUFVT
dGF0ZSAqY3MpCiAgICAgWDg2Q1BVICpjcHUgPSBYODZfQ1BVKGNzKTsKICAgICBDUFVYODZTdGF0
ZSAqZW52ID0gJmNwdS0+ZW52OwogCi0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBD
UFVfSU5URVJSVVBUX01DRSkgeworICAgIGlmIChjcy0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVf
SU5URVJSVVBUX01DRSkgewogICAgICAgICAvKiBXZSBtdXN0IG5vdCByYWlzZSBDUFVfSU5URVJS
VVBUX01DRSBpZiBpdCdzIG5vdCBzdXBwb3J0ZWQuICovCiAgICAgICAgIGFzc2VydChlbnYtPm1j
Z19jYXApOwogCi0gICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJV
UFRfTUNFOworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRf
TUNFOwogCiAgICAgICAgIGt2bV9jcHVfc3luY2hyb25pemVfc3RhdGUoZW52KTsKIApAQCAtMTg1
Myw3ICsxODU0LDcgQEAgaW50IGt2bV9hcmNoX3Byb2Nlc3NfYXN5bmNfZXZlbnRzKENQVVN0YXRl
ICpjcykKICAgICAgICAgZW52LT5leGNlcHRpb25faW5qZWN0ZWQgPSBFWENQMTJfTUNISzsKICAg
ICAgICAgZW52LT5oYXNfZXJyb3JfY29kZSA9IDA7CiAKLSAgICAgICAgZW52LT5oYWx0ZWQgPSAw
OworICAgICAgICBjcy0+aGFsdGVkID0gMDsKICAgICAgICAgaWYgKGt2bV9pcnFjaGlwX2luX2tl
cm5lbCgpICYmIGVudi0+bXBfc3RhdGUgPT0gS1ZNX01QX1NUQVRFX0hBTFRFRCkgewogICAgICAg
ICAgICAgZW52LT5tcF9zdGF0ZSA9IEtWTV9NUF9TVEFURV9SVU5OQUJMRTsKICAgICAgICAgfQpA
QCAtMTg2Myw0MSArMTg2NCw0MiBAQCBpbnQga3ZtX2FyY2hfcHJvY2Vzc19hc3luY19ldmVudHMo
Q1BVU3RhdGUgKmNzKQogICAgICAgICByZXR1cm4gMDsKICAgICB9CiAKLSAgICBpZiAoZW52LT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfUE9MTCkgewotICAgICAgICBlbnYtPmlu
dGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX1BPTEw7CisgICAgaWYgKGNzLT5pbnRl
cnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfUE9MTCkgeworICAgICAgICBjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfUE9MTDsKICAgICAgICAgYXBpY19wb2xsX2ly
cShlbnYtPmFwaWNfc3RhdGUpOwogICAgIH0KLSAgICBpZiAoKChlbnYtPmludGVycnVwdF9yZXF1
ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgIGlmICgoKGNzLT5pbnRlcnJ1cHRfcmVx
dWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRCkgJiYKICAgICAgICAgIChlbnYtPmVmbGFncyAmIElG
X01BU0spKSB8fAotICAgICAgICAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJV
UFRfTk1JKSkgewotICAgICAgICBlbnYtPmhhbHRlZCA9IDA7CisgICAgICAgIChjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX05NSSkpIHsKKyAgICAgICAgY3MtPmhhbHRlZCA9
IDA7CiAgICAgfQotICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQ
VF9JTklUKSB7CisgICAgaWYgKGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRf
SU5JVCkgewogICAgICAgICBrdm1fY3B1X3N5bmNocm9uaXplX3N0YXRlKGVudik7CiAgICAgICAg
IGRvX2NwdV9pbml0KGNwdSk7CiAgICAgfQotICAgIGlmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0
ICYgQ1BVX0lOVEVSUlVQVF9TSVBJKSB7CisgICAgaWYgKGNzLT5pbnRlcnJ1cHRfcmVxdWVzdCAm
IENQVV9JTlRFUlJVUFRfU0lQSSkgewogICAgICAgICBrdm1fY3B1X3N5bmNocm9uaXplX3N0YXRl
KGVudik7CiAgICAgICAgIGRvX2NwdV9zaXBpKGNwdSk7CiAgICAgfQotICAgIGlmIChlbnYtPmlu
dGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9UUFIpIHsKLSAgICAgICAgZW52LT5pbnRl
cnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9UUFI7CisgICAgaWYgKGNzLT5pbnRlcnJ1
cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfVFBSKSB7CisgICAgICAgIGNzLT5pbnRlcnJ1cHRf
cmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9UUFI7CiAgICAgICAgIGt2bV9jcHVfc3luY2hyb25p
emVfc3RhdGUoZW52KTsKICAgICAgICAgYXBpY19oYW5kbGVfdHByX2FjY2Vzc19yZXBvcnQoZW52
LT5hcGljX3N0YXRlLCBlbnYtPmVpcCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZW52LT50cHJfYWNjZXNzX3R5cGUpOwogICAgIH0KIAotICAgIHJldHVybiBlbnYtPmhh
bHRlZDsKKyAgICByZXR1cm4gY3MtPmhhbHRlZDsKIH0KIAogc3RhdGljIGludCBrdm1faGFuZGxl
X2hhbHQoWDg2Q1BVICpjcHUpCiB7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAgICAg
Q1BVWDg2U3RhdGUgKmVudiA9ICZjcHUtPmVudjsKIAotICAgIGlmICghKChlbnYtPmludGVycnVw
dF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgIGlmICghKChjcy0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCiAgICAgICAgICAgKGVudi0+ZWZs
YWdzICYgSUZfTUFTSykpICYmCi0gICAgICAgICEoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQ
VV9JTlRFUlJVUFRfTk1JKSkgewotICAgICAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgICAgICEo
Y3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9OTUkpKSB7CisgICAgICAgIGNz
LT5oYWx0ZWQgPSAxOwogICAgICAgICByZXR1cm4gRVhDUF9ITFQ7CiAgICAgfQogCmRpZmYgLS1n
aXQgYS90YXJnZXQtaTM4Ni9tYWNoaW5lLmMgYi90YXJnZXQtaTM4Ni9tYWNoaW5lLmMKaW5kZXgg
Yzk5ODRiOC4uYjgwYTVmNCAxMDA2NDQKLS0tIGEvdGFyZ2V0LWkzODYvbWFjaGluZS5jCisrKyBi
L3RhcmdldC1pMzg2L21hY2hpbmUuYwpAQCAtNDUzLDcgKzQ1Myw3IEBAIGNvbnN0IFZNU3RhdGVE
ZXNjcmlwdGlvbiB2bXN0YXRlX3g4Nl9jcHUgPSB7CiAgICAgICAgIFZNU1RBVEVfVUlOVDY0X1Yo
ZW52LnBhdCwgWDg2Q1BVLCA1KSwKICAgICAgICAgVk1TVEFURV9VSU5UMzJfVihlbnYuaGZsYWdz
MiwgWDg2Q1BVLCA1KSwKIAotICAgICAgICBWTVNUQVRFX1VJTlQzMl9URVNUKGVudi5oYWx0ZWQs
IFg4NkNQVSwgdmVyc2lvbl9pc181KSwKKyAgICAgICAgVk1TVEFURV9VSU5UMzJfVEVTVChwYXJl
bnRfb2JqLmhhbHRlZCwgWDg2Q1BVLCB2ZXJzaW9uX2lzXzUpLAogICAgICAgICBWTVNUQVRFX1VJ
TlQ2NF9WKGVudi52bV9oc2F2ZSwgWDg2Q1BVLCA1KSwKICAgICAgICAgVk1TVEFURV9VSU5UNjRf
VihlbnYudm1fdm1jYiwgWDg2Q1BVLCA1KSwKICAgICAgICAgVk1TVEFURV9VSU5UNjRfVihlbnYu
dHNjX29mZnNldCwgWDg2Q1BVLCA1KSwKZGlmZiAtLWdpdCBhL3RhcmdldC1pMzg2L21pc2NfaGVs
cGVyLmMgYi90YXJnZXQtaTM4Ni9taXNjX2hlbHBlci5jCmluZGV4IGI2ZDU3NDAuLmRmYmMwN2Ig
MTAwNjQ0Ci0tLSBhL3RhcmdldC1pMzg2L21pc2NfaGVscGVyLmMKKysrIGIvdGFyZ2V0LWkzODYv
bWlzY19oZWxwZXIuYwpAQCAtNTUzLDIwICs1NTMsMjUgQEAgdm9pZCBoZWxwZXJfcmRtc3IoQ1BV
WDg2U3RhdGUgKmVudikKIH0KICNlbmRpZgogCi1zdGF0aWMgdm9pZCBkb19obHQoQ1BVWDg2U3Rh
dGUgKmVudikKK3N0YXRpYyB2b2lkIGRvX2hsdChYODZDUFUgKmNwdSkKIHsKKyAgICBDUFVTdGF0
ZSAqY3MgPSBDUFUoY3B1KTsKKyAgICBDUFVYODZTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OworCiAg
ICAgZW52LT5oZmxhZ3MgJj0gfkhGX0lOSElCSVRfSVJRX01BU0s7IC8qIG5lZWRlZCBpZiBzdGkg
aXMganVzdCBiZWZvcmUgKi8KLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgY3MtPmhhbHRlZCA9
IDE7CiAgICAgZW52LT5leGNlcHRpb25faW5kZXggPSBFWENQX0hMVDsKICAgICBjcHVfbG9vcF9l
eGl0KGVudik7CiB9CiAKIHZvaWQgaGVscGVyX2hsdChDUFVYODZTdGF0ZSAqZW52LCBpbnQgbmV4
dF9laXBfYWRkZW5kKQogeworICAgIFg4NkNQVSAqY3B1ID0geDg2X2Vudl9nZXRfY3B1KGVudik7
CisKICAgICBjcHVfc3ZtX2NoZWNrX2ludGVyY2VwdF9wYXJhbShlbnYsIFNWTV9FWElUX0hMVCwg
MCk7CiAgICAgRUlQICs9IG5leHRfZWlwX2FkZGVuZDsKIAotICAgIGRvX2hsdChlbnYpOworICAg
IGRvX2hsdChjcHUpOwogfQogCiB2b2lkIGhlbHBlcl9tb25pdG9yKENQVVg4NlN0YXRlICplbnYs
IHRhcmdldF91bG9uZyBwdHIpCkBAIC01ODAsNyArNTg1LDggQEAgdm9pZCBoZWxwZXJfbW9uaXRv
cihDUFVYODZTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgcHRyKQogCiB2b2lkIGhlbHBlcl9td2Fp
dChDUFVYODZTdGF0ZSAqZW52LCBpbnQgbmV4dF9laXBfYWRkZW5kKQogewotICAgIENQVVN0YXRl
ICpjcHU7CisgICAgQ1BVU3RhdGUgKmNzOworICAgIFg4NkNQVSAqY3B1OwogCiAgICAgaWYgKCh1
aW50MzJfdClFQ1ggIT0gMCkgewogICAgICAgICByYWlzZV9leGNlcHRpb24oZW52LCBFWENQMERf
R1BGKTsKQEAgLTU4OCwxMyArNTk0LDE0IEBAIHZvaWQgaGVscGVyX213YWl0KENQVVg4NlN0YXRl
ICplbnYsIGludCBuZXh0X2VpcF9hZGRlbmQpCiAgICAgY3B1X3N2bV9jaGVja19pbnRlcmNlcHRf
cGFyYW0oZW52LCBTVk1fRVhJVF9NV0FJVCwgMCk7CiAgICAgRUlQICs9IG5leHRfZWlwX2FkZGVu
ZDsKIAotICAgIGNwdSA9IENQVSh4ODZfZW52X2dldF9jcHUoZW52KSk7CisgICAgY3B1ID0geDg2
X2Vudl9nZXRfY3B1KGVudik7CisgICAgY3MgPSBDUFUoY3B1KTsKICAgICAvKiBYWFg6IG5vdCBj
b21wbGV0ZSBidXQgbm90IGNvbXBsZXRlbHkgZXJyb25lb3VzICovCi0gICAgaWYgKGNwdS0+Y3B1
X2luZGV4ICE9IDAgfHwgZW52LT5uZXh0X2NwdSAhPSBOVUxMKSB7CisgICAgaWYgKGNzLT5jcHVf
aW5kZXggIT0gMCB8fCBlbnYtPm5leHRfY3B1ICE9IE5VTEwpIHsKICAgICAgICAgLyogbW9yZSB0
aGFuIG9uZSBDUFU6IGRvIG5vdCBzbGVlcCBiZWNhdXNlIGFub3RoZXIgQ1BVIG1heQogICAgICAg
ICAgICB3YWtlIHRoaXMgb25lICovCiAgICAgfSBlbHNlIHsKLSAgICAgICAgZG9faGx0KGVudik7
CisgICAgICAgIGRvX2hsdChjcHUpOwogICAgIH0KIH0KIApkaWZmIC0tZ2l0IGEvdGFyZ2V0LWkz
ODYvc3ZtX2hlbHBlci5jIGIvdGFyZ2V0LWkzODYvc3ZtX2hlbHBlci5jCmluZGV4IDNmMjQ2ZTku
LmM0NmEyMTMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1pMzg2L3N2bV9oZWxwZXIuYworKysgYi90YXJn
ZXQtaTM4Ni9zdm1faGVscGVyLmMKQEAgLTI3MSw3ICsyNzEsOSBAQCB2b2lkIGhlbHBlcl92bXJ1
bihDUFVYODZTdGF0ZSAqZW52LCBpbnQgYWZsYWcsIGludCBuZXh0X2VpcF9hZGRlbmQpCiAgICAg
ZW52LT5oZmxhZ3MyIHw9IEhGMl9HSUZfTUFTSzsKIAogICAgIGlmIChpbnRfY3RsICYgVl9JUlFf
TUFTSykgewotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRf
VklSUTsKKyAgICAgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKHg4Nl9lbnZfZ2V0X2NwdShlbnYpKTsK
KworICAgICAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9WSVJROwog
ICAgIH0KIAogICAgIC8qIG1heWJlIHdlIG5lZWQgdG8gaW5qZWN0IGFuIGV2ZW50ICovCkBAIC01
NDgsNiArNTUwLDcgQEAgdm9pZCBoZWxwZXJfc3ZtX2NoZWNrX2lvKENQVVg4NlN0YXRlICplbnYs
IHVpbnQzMl90IHBvcnQsIHVpbnQzMl90IHBhcmFtLAogLyogTm90ZTogY3VycmVudGx5IG9ubHkg
MzIgYml0cyBvZiBleGl0X2NvZGUgYXJlIHVzZWQgKi8KIHZvaWQgaGVscGVyX3ZtZXhpdChDUFVY
ODZTdGF0ZSAqZW52LCB1aW50MzJfdCBleGl0X2NvZGUsIHVpbnQ2NF90IGV4aXRfaW5mb18xKQog
eworICAgIENQVVN0YXRlICpjcyA9IENQVSh4ODZfZW52X2dldF9jcHUoZW52KSk7CiAgICAgdWlu
dDMyX3QgaW50X2N0bDsKIAogICAgIHFlbXVfbG9nX21hc2soQ1BVX0xPR19UQl9JTl9BU00sICJ2
bWV4aXQoJTA4eCwgJTAxNiIgUFJJeDY0ICIsICUwMTYiCkBAIC01OTQsNyArNTk3LDcgQEAgdm9p
ZCBoZWxwZXJfdm1leGl0KENQVVg4NlN0YXRlICplbnYsIHVpbnQzMl90IGV4aXRfY29kZSwgdWlu
dDY0X3QgZXhpdF9pbmZvXzEpCiAgICAgaW50X2N0bCA9IGxkbF9waHlzKGVudi0+dm1fdm1jYiAr
IG9mZnNldG9mKHN0cnVjdCB2bWNiLCBjb250cm9sLmludF9jdGwpKTsKICAgICBpbnRfY3RsICY9
IH4oVl9UUFJfTUFTSyB8IFZfSVJRX01BU0spOwogICAgIGludF9jdGwgfD0gZW52LT52X3RwciAm
IFZfVFBSX01BU0s7Ci0gICAgaWYgKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJS
VVBUX1ZJUlEpIHsKKyAgICBpZiAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQ
VF9WSVJRKSB7CiAgICAgICAgIGludF9jdGwgfD0gVl9JUlFfTUFTSzsKICAgICB9CiAgICAgc3Rs
X3BoeXMoZW52LT52bV92bWNiICsgb2Zmc2V0b2Yoc3RydWN0IHZtY2IsIGNvbnRyb2wuaW50X2N0
bCksIGludF9jdGwpOwpAQCAtNjE1LDcgKzYxOCw3IEBAIHZvaWQgaGVscGVyX3ZtZXhpdChDUFVY
ODZTdGF0ZSAqZW52LCB1aW50MzJfdCBleGl0X2NvZGUsIHVpbnQ2NF90IGV4aXRfaW5mb18xKQog
ICAgIGVudi0+aGZsYWdzICY9IH5IRl9TVk1JX01BU0s7CiAgICAgZW52LT5pbnRlcmNlcHQgPSAw
OwogICAgIGVudi0+aW50ZXJjZXB0X2V4Y2VwdGlvbnMgPSAwOwotICAgIGVudi0+aW50ZXJydXB0
X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfVklSUTsKKyAgICBjcy0+aW50ZXJydXB0X3JlcXVl
c3QgJj0gfkNQVV9JTlRFUlJVUFRfVklSUTsKICAgICBlbnYtPnRzY19vZmZzZXQgPSAwOwogCiAg
ICAgZW52LT5nZHQuYmFzZSAgPSBsZHFfcGh5cyhlbnYtPnZtX2hzYXZlICsgb2Zmc2V0b2Yoc3Ry
dWN0IHZtY2IsCmRpZmYgLS1naXQgYS90YXJnZXQtbG0zMi9jcHUuaCBiL3RhcmdldC1sbTMyL2Nw
dS5oCmluZGV4IGUwYmJlMDQuLjNkMzE4MWIgMTAwNjQ0Ci0tLSBhL3RhcmdldC1sbTMyL2NwdS5o
CisrKyBiL3RhcmdldC1sbTMyL2NwdS5oCkBAIC0yNTIsOSArMjUyLDcgQEAgc3RhdGljIGlubGlu
ZSB2b2lkIGNwdV9nZXRfdGJfY3B1X3N0YXRlKENQVUxNMzJTdGF0ZSAqZW52LCB0YXJnZXRfdWxv
bmcgKnBjLAogCiBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUp
CiB7Ci0gICAgQ1BVTE0zMlN0YXRlICplbnYgPSAmTE0zMl9DUFUoY3B1KS0+ZW52OwotCi0gICAg
cmV0dXJuIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CisgICAg
cmV0dXJuIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CiB9CiAK
ICNpbmNsdWRlICJleGVjL2V4ZWMtYWxsLmgiCmRpZmYgLS1naXQgYS90YXJnZXQtbG0zMi9vcF9o
ZWxwZXIuYyBiL3RhcmdldC1sbTMyL29wX2hlbHBlci5jCmluZGV4IDUzNDEwYjEuLmViYzk0YTAg
MTAwNjQ0Ci0tLSBhL3RhcmdldC1sbTMyL29wX2hlbHBlci5jCisrKyBiL3RhcmdldC1sbTMyL29w
X2hlbHBlci5jCkBAIC0yNSw3ICsyNSw5IEBAIHZvaWQgaGVscGVyX3JhaXNlX2V4Y2VwdGlvbihD
UFVMTTMyU3RhdGUgKmVudiwgdWludDMyX3QgaW5kZXgpCiAKIHZvaWQgaGVscGVyX2hsdChDUFVM
TTMyU3RhdGUgKmVudikKIHsKLSAgICBlbnYtPmhhbHRlZCA9IDE7CisgICAgQ1BVU3RhdGUgKmNz
ID0gQ1BVKGxtMzJfZW52X2dldF9jcHUoZW52KSk7CisKKyAgICBjcy0+aGFsdGVkID0gMTsKICAg
ICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9IEVYQ1BfSExUOwogICAgIGNwdV9sb29wX2V4aXQoZW52
KTsKIH0KZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL2NwdS5oIGIvdGFyZ2V0LW02OGsvY3B1LmgK
aW5kZXggMjY3MmVhZS4uYmIyZmJkNiAxMDA2NDQKLS0tIGEvdGFyZ2V0LW02OGsvY3B1LmgKKysr
IGIvdGFyZ2V0LW02OGsvY3B1LmgKQEAgLTI2NSw5ICsyNjUsNyBAQCBzdGF0aWMgaW5saW5lIHZv
aWQgY3B1X2dldF90Yl9jcHVfc3RhdGUoQ1BVTTY4S1N0YXRlICplbnYsIHRhcmdldF91bG9uZyAq
cGMsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsK
LSAgICBDUFVNNjhLU3RhdGUgKmVudiA9ICZNNjhLX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1
cm4gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKKyAgICByZXR1
cm4gY3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFSRDsKIH0KIAogI2lu
Y2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL29wX2hlbHBl
ci5jIGIvdGFyZ2V0LW02OGsvb3BfaGVscGVyLmMKaW5kZXggMTZkZjI0Yy4uZTExZjM0YiAxMDA2
NDQKLS0tIGEvdGFyZ2V0LW02OGsvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LW02OGsvb3BfaGVs
cGVyLmMKQEAgLTg0LDYgKzg0LDcgQEAgc3RhdGljIHZvaWQgZG9fcnRlKENQVU02OEtTdGF0ZSAq
ZW52KQogCiBzdGF0aWMgdm9pZCBkb19pbnRlcnJ1cHRfYWxsKENQVU02OEtTdGF0ZSAqZW52LCBp
bnQgaXNfaHcpCiB7CisgICAgQ1BVU3RhdGUgKmNzOwogICAgIHVpbnQzMl90IHNwOwogICAgIHVp
bnQzMl90IGZtdDsKICAgICB1aW50MzJfdCByZXRhZGRyOwpAQCAtMTA4LDcgKzEwOSw4IEBAIHN0
YXRpYyB2b2lkIGRvX2ludGVycnVwdF9hbGwoQ1BVTTY4S1N0YXRlICplbnYsIGludCBpc19odykK
ICAgICAgICAgICAgICAgICBkb19tNjhrX3NlbWlob3N0aW5nKGVudiwgZW52LT5kcmVnc1swXSk7
CiAgICAgICAgICAgICAgICAgcmV0dXJuOwogICAgICAgICAgICAgfQotICAgICAgICAgICAgZW52
LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgY3MgPSBDUFUobTY4a19lbnZfZ2V0X2NwdShlbnYp
KTsKKyAgICAgICAgICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgICAgICAgICAgZW52LT5leGNlcHRp
b25faW5kZXggPSBFWENQX0hMVDsKICAgICAgICAgICAgIGNwdV9sb29wX2V4aXQoZW52KTsKICAg
ICAgICAgICAgIHJldHVybjsKZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL3FyZWdzLmRlZiBiL3Rh
cmdldC1tNjhrL3FyZWdzLmRlZgppbmRleCA0OTQwMGM0Li40MjM1YjAyIDEwMDY0NAotLS0gYS90
YXJnZXQtbTY4ay9xcmVncy5kZWYKKysrIGIvdGFyZ2V0LW02OGsvcXJlZ3MuZGVmCkBAIC04LDYg
KzgsNSBAQCBERUZPMzIoQ0NfWCwgY2NfeCkKIERFRk8zMihESVYxLCBkaXYxKQogREVGTzMyKERJ
VjIsIGRpdjIpCiBERUZPMzIoRVhDRVBUSU9OLCBleGNlcHRpb25faW5kZXgpCi1ERUZPMzIoSEFM
VEVELCBoYWx0ZWQpCiBERUZPMzIoTUFDU1IsIG1hY3NyKQogREVGTzMyKE1BQ19NQVNLLCBtYWNf
bWFzaykKZGlmZiAtLWdpdCBhL3RhcmdldC1tNjhrL3RyYW5zbGF0ZS5jIGIvdGFyZ2V0LW02OGsv
dHJhbnNsYXRlLmMKaW5kZXggM2YxNDc4Yy4uNDBkZDBhMCAxMDA2NDQKLS0tIGEvdGFyZ2V0LW02
OGsvdHJhbnNsYXRlLmMKKysrIGIvdGFyZ2V0LW02OGsvdHJhbnNsYXRlLmMKQEAgLTQyLDYgKzQy
LDggQEAKICN1bmRlZiBERUZPNjQKICN1bmRlZiBERUZGNjQKIAorc3RhdGljIFRDR3ZfaTMyIGNw
dV9oYWx0ZWQ7CisKIHN0YXRpYyBUQ0d2X3B0ciBjcHVfZW52OwogCiBzdGF0aWMgY2hhciBjcHVf
cmVnX25hbWVzWzMqOCozICsgNSo0XTsKQEAgLTc2LDYgKzc4LDEwIEBAIHZvaWQgbTY4a190Y2df
aW5pdCh2b2lkKQogI3VuZGVmIERFRk82NAogI3VuZGVmIERFRkY2NAogCisgICAgY3B1X2hhbHRl
ZCA9IHRjZ19nbG9iYWxfbWVtX25ld19pMzIoVENHX0FSRUcwLAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC1vZmZzZXRvZihNNjhrQ1BVLCBlbnYpICsKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZmZzZXRvZihDUFVTdGF0ZSwgaGFsdGVk
KSwgIkhBTFRFRCIpOworCiAgICAgY3B1X2VudiA9IHRjZ19nbG9iYWxfcmVnX25ld19wdHIoVENH
X0FSRUcwLCAiZW52Iik7CiAKICAgICBwID0gY3B1X3JlZ19uYW1lczsKQEAgLTIwMjQsNyArMjAz
MCw3IEBAIERJU0FTX0lOU04oc3RvcCkKICAgICBzLT5wYyArPSAyOwogCiAgICAgZ2VuX3NldF9z
cl9pbShzLCBleHQsIDApOwotICAgIHRjZ19nZW5fbW92aV9pMzIoUVJFR19IQUxURUQsIDEpOwor
ICAgIHRjZ19nZW5fbW92aV9pMzIoY3B1X2hhbHRlZCwgMSk7CiAgICAgZ2VuX2V4Y2VwdGlvbihz
LCBzLT5wYywgRVhDUF9ITFQpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtbWljcm9ibGF6ZS9j
cHUuaCBiL3RhcmdldC1taWNyb2JsYXplL2NwdS5oCmluZGV4IGMzZGQ3ZjYuLjc1NDhhYTkgMTAw
NjQ0Ci0tLSBhL3RhcmdldC1taWNyb2JsYXplL2NwdS5oCisrKyBiL3RhcmdldC1taWNyb2JsYXpl
L2NwdS5oCkBAIC0zNzQsOSArMzc0LDcgQEAgdm9pZCBjcHVfdW5hc3NpZ25lZF9hY2Nlc3MoQ1BV
TUJTdGF0ZSAqZW52MSwgaHdhZGRyIGFkZHIsCiAKIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFz
X3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVNQlN0YXRlICplbnYgPSAmTUlDUk9CTEFa
RV9DUFUoY3B1KS0+ZW52OwotCi0gICAgcmV0dXJuIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiAo
Q1BVX0lOVEVSUlVQVF9IQVJEIHwgQ1BVX0lOVEVSUlVQVF9OTUkpOworICAgIHJldHVybiBjcHUt
PmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8IENQVV9JTlRFUlJVUFRf
Tk1JKTsKIH0KIAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIKZGlmZiAtLWdpdCBhL3Rhcmdl
dC1taXBzL2NwdS5oIGIvdGFyZ2V0LW1pcHMvY3B1LmgKaW5kZXggMGUxOThiMS4uNzQzNDA5OSAx
MDA2NDQKLS0tIGEvdGFyZ2V0LW1pcHMvY3B1LmgKKysrIGIvdGFyZ2V0LW1pcHMvY3B1LmgKQEAg
LTcxOSw3ICs3MTksNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRl
ICpjcHUpCiAgICAgLyogSXQgaXMgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50IGlmIG5vbi1lbmFi
bGVkIGludGVycnVwdHMKICAgICAgICB3YWtlLXVwIHRoZSBDUFUsIGhvd2V2ZXIgbW9zdCBvZiB0
aGUgaW1wbGVtZW50YXRpb25zIG9ubHkKICAgICAgICBjaGVjayBmb3IgaW50ZXJydXB0cyB0aGF0
IGNhbiBiZSB0YWtlbi4gKi8KLSAgICBpZiAoKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVf
SU5URVJSVVBUX0hBUkQpICYmCisgICAgaWYgKChjcHUtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BV
X0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAgICBjcHVfbWlwc19od19pbnRlcnJ1cHRzX3BlbmRp
bmcoZW52KSkgewogICAgICAgICBoYXNfd29yayA9IHRydWU7CiAgICAgfQpAQCAtNzI4LDcgKzcy
OCw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKICAg
ICBpZiAoZW52LT5DUDBfQ29uZmlnMyAmICgxIDw8IENQMEMzX01UKSkgewogICAgICAgICAvKiBU
aGUgUUVNVSBtb2RlbCB3aWxsIGlzc3VlIGFuIF9XQUtFIHJlcXVlc3Qgd2hlbmV2ZXIgdGhlIENQ
VXMKICAgICAgICAgICAgc2hvdWxkIGJlIHdva2VuIHVwLiAgKi8KLSAgICAgICAgaWYgKGVudi0+
aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1dBS0UpIHsKKyAgICAgICAgaWYgKGNw
dS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX1dBS0UpIHsKICAgICAgICAgICAg
IGhhc193b3JrID0gdHJ1ZTsKICAgICAgICAgfQogCmRpZmYgLS1naXQgYS90YXJnZXQtbWlwcy9v
cF9oZWxwZXIuYyBiL3RhcmdldC1taXBzL29wX2hlbHBlci5jCmluZGV4IDQ1Y2JiMmYuLjNhYjQz
NTYgMTAwNjQ0Ci0tLSBhL3RhcmdldC1taXBzL29wX2hlbHBlci5jCisrKyBiL3RhcmdldC1taXBz
L29wX2hlbHBlci5jCkBAIC01MTUsMTEgKzUxNSwxMiBAQCB2b2lkIGhlbHBlcl9zZG0oQ1BVTUlQ
U1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBhZGRyLCB0YXJnZXRfdWxvbmcgcmVnbGlzdCwKIC8q
IFNNUCBoZWxwZXJzLiAgKi8KIHN0YXRpYyBib29sIG1pcHNfdnBlX2lzX3dmaShNSVBTQ1BVICpj
KQogeworICAgIENQVVN0YXRlICpjcHUgPSBDUFUoYyk7CiAgICAgQ1BVTUlQU1N0YXRlICplbnYg
PSAmYy0+ZW52OwogCiAgICAgLyogSWYgdGhlIFZQRSBpcyBoYWx0ZWQgYnV0IG90aGVyd2lzZSBh
Y3RpdmUsIGl0IG1lYW5zIGl0J3Mgd2FpdGluZyBmb3IKICAgICAgICBhbiBpbnRlcnJ1cHQuICAq
LwotICAgIHJldHVybiBlbnYtPmhhbHRlZCAmJiBtaXBzX3ZwZV9hY3RpdmUoZW52KTsKKyAgICBy
ZXR1cm4gY3B1LT5oYWx0ZWQgJiYgbWlwc192cGVfYWN0aXZlKGVudik7CiB9CiAKIHN0YXRpYyBp
bmxpbmUgdm9pZCBtaXBzX3ZwZV93YWtlKENQVU1JUFNTdGF0ZSAqYykKQEAgLTUzMiwxMSArNTMz
LDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBtaXBzX3ZwZV93YWtlKENQVU1JUFNTdGF0ZSAqYykK
IAogc3RhdGljIGlubGluZSB2b2lkIG1pcHNfdnBlX3NsZWVwKE1JUFNDUFUgKmNwdSkKIHsKKyAg
ICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1KTsKICAgICBDUFVNSVBTU3RhdGUgKmMgPSAmY3B1LT5l
bnY7CiAKICAgICAvKiBUaGUgVlBFIHdhcyBzaHV0IG9mZiwgcmVhbGx5IGdvIHRvIGJlZC4KICAg
ICAgICBSZXNldCBhbnkgb2xkIF9XQUtFIHJlcXVlc3RzLiAgKi8KLSAgICBjLT5oYWx0ZWQgPSAx
OworICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgIGNwdV9yZXNldF9pbnRlcnJ1cHQoYywgQ1BVX0lO
VEVSUlVQVF9XQUtFKTsKIH0KIApAQCAtMjA5OSw3ICsyMTAxLDkgQEAgdm9pZCBoZWxwZXJfcG1v
bihDUFVNSVBTU3RhdGUgKmVudiwgaW50IGZ1bmN0aW9uKQogCiB2b2lkIGhlbHBlcl93YWl0KENQ
VU1JUFNTdGF0ZSAqZW52KQogewotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUobWlwc19lbnZfZ2V0X2NwdShlbnYpKTsKKworICAgIGNzLT5oYWx0ZWQgPSAxOwog
ICAgIGNwdV9yZXNldF9pbnRlcnJ1cHQoZW52LCBDUFVfSU5URVJSVVBUX1dBS0UpOwogICAgIGhl
bHBlcl9yYWlzZV9leGNlcHRpb24oZW52LCBFWENQX0hMVCk7CiB9CmRpZmYgLS1naXQgYS90YXJn
ZXQtbWlwcy90cmFuc2xhdGUuYyBiL3RhcmdldC1taXBzL3RyYW5zbGF0ZS5jCmluZGV4IGYxMGE1
MzMuLjAxY2VhNjkgMTAwNjQ0Ci0tLSBhL3RhcmdldC1taXBzL3RyYW5zbGF0ZS5jCisrKyBiL3Rh
cmdldC1taXBzL3RyYW5zbGF0ZS5jCkBAIC0xNjAxMiw3ICsxNjAxMiw3IEBAIHZvaWQgY3B1X3N0
YXRlX3Jlc2V0KENQVU1JUFNTdGF0ZSAqZW52KQogICAgICAgICAgICAgZW52LT50Y3NbaV0uQ1Aw
X1RDSGFsdCA9IDE7CiAgICAgICAgIH0KICAgICAgICAgZW52LT5hY3RpdmVfdGMuQ1AwX1RDSGFs
dCA9IDE7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7
CiAKICAgICAgICAgaWYgKGNzLT5jcHVfaW5kZXggPT0gMCkgewogICAgICAgICAgICAgLyogVlBF
MCBzdGFydHMgdXAgZW5hYmxlZC4gICovCkBAIC0xNjAyMCw3ICsxNjAyMCw3IEBAIHZvaWQgY3B1
X3N0YXRlX3Jlc2V0KENQVU1JUFNTdGF0ZSAqZW52KQogICAgICAgICAgICAgZW52LT5DUDBfVlBF
Q29uZjAgfD0gKDEgPDwgQ1AwVlBFQzBfTVZQKSB8ICgxIDw8IENQMFZQRUMwX1ZQQSk7CiAKICAg
ICAgICAgICAgIC8qIFRDMCBzdGFydHMgdXAgdW5oYWx0ZWQuICAqLwotICAgICAgICAgICAgZW52
LT5oYWx0ZWQgPSAwOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDA7CiAgICAgICAgICAgICBl
bnYtPmFjdGl2ZV90Yy5DUDBfVENIYWx0ID0gMDsKICAgICAgICAgICAgIGVudi0+dGNzWzBdLkNQ
MF9UQ0hhbHQgPSAwOwogICAgICAgICAgICAgLyogV2l0aCB0aHJlYWQgMCBhY3RpdmUuICAqLwpk
aWZmIC0tZ2l0IGEvdGFyZ2V0LW9wZW5yaXNjL2NwdS5oIGIvdGFyZ2V0LW9wZW5yaXNjL2NwdS5o
CmluZGV4IDRjZmQxYzcuLjY0MzcwYTMgMTAwNjQ0Ci0tLSBhL3RhcmdldC1vcGVucmlzYy9jcHUu
aAorKysgYi90YXJnZXQtb3BlbnJpc2MvY3B1LmgKQEAgLTQyMyw5ICs0MjMsNyBAQCBzdGF0aWMg
aW5saW5lIGludCBjcHVfbW11X2luZGV4KENQVU9wZW5SSVNDU3RhdGUgKmVudikKICNkZWZpbmUg
Q1BVX0lOVEVSUlVQVF9USU1FUiAgIENQVV9JTlRFUlJVUFRfVEdUX0lOVF8wCiBzdGF0aWMgaW5s
aW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVT3BlblJJU0NT
dGF0ZSAqZW52ID0gJk9QRU5SSVNDX0NQVShjcHUpLT5lbnY7Ci0KLSAgICByZXR1cm4gZW52LT5p
bnRlcnJ1cHRfcmVxdWVzdCAmIChDUFVfSU5URVJSVVBUX0hBUkQgfAorICAgIHJldHVybiBjcHUt
PmludGVycnVwdF9yZXF1ZXN0ICYgKENQVV9JTlRFUlJVUFRfSEFSRCB8CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgQ1BVX0lOVEVSUlVQVF9USU1FUik7CiB9CiAKZGlmZiAt
LWdpdCBhL3RhcmdldC1vcGVucmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMgYi90YXJnZXQtb3BlbnJp
c2MvaW50ZXJydXB0X2hlbHBlci5jCmluZGV4IGExNzY0NDEuLjg0NDY0OGYgMTAwNjQ0Ci0tLSBh
L3RhcmdldC1vcGVucmlzYy9pbnRlcnJ1cHRfaGVscGVyLmMKKysrIGIvdGFyZ2V0LW9wZW5yaXNj
L2ludGVycnVwdF9oZWxwZXIuYwpAQCAtMjQsNiArMjQsNyBAQAogdm9pZCBIRUxQRVIocmZlKShD
UFVPcGVuUklTQ1N0YXRlICplbnYpCiB7CiAgICAgT3BlblJJU0NDUFUgKmNwdSA9IG9wZW5yaXNj
X2Vudl9nZXRfY3B1KGVudik7CisgICAgQ1BVU3RhdGUgKmNzID0gQ1BVKGNwdSk7CiAjaWZuZGVm
IENPTkZJR19VU0VSX09OTFkKICAgICBpbnQgbmVlZF9mbHVzaF90bGIgPSAoY3B1LT5lbnYuc3Ig
JiAoU1JfU00gfCBTUl9JTUUgfCBTUl9ETUUpKSBeCiAgICAgICAgICAgICAgICAgICAgICAgICAg
KGNwdS0+ZW52LmVzciAmIChTUl9TTSB8IFNSX0lNRSB8IFNSX0RNRSkpOwpAQCAtNTMsNSArNTQs
NSBAQCB2b2lkIEhFTFBFUihyZmUpKENQVU9wZW5SSVNDU3RhdGUgKmVudikKICAgICAgICAgdGxi
X2ZsdXNoKCZjcHUtPmVudiwgMSk7CiAgICAgfQogI2VuZGlmCi0gICAgY3B1LT5lbnYuaW50ZXJy
dXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgY3MtPmludGVycnVwdF9y
ZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOwogfQpkaWZmIC0tZ2l0IGEvdGFyZ2V0LW9w
ZW5yaXNjL3N5c19oZWxwZXIuYyBiL3RhcmdldC1vcGVucmlzYy9zeXNfaGVscGVyLmMKaW5kZXgg
M2M1ZjQ1YS4uY2NjYmMwZSAxMDA2NDQKLS0tIGEvdGFyZ2V0LW9wZW5yaXNjL3N5c19oZWxwZXIu
YworKysgYi90YXJnZXQtb3BlbnJpc2Mvc3lzX2hlbHBlci5jCkBAIC0zMSw2ICszMSw3IEBAIHZv
aWQgSEVMUEVSKG10c3ByKShDUFVPcGVuUklTQ1N0YXRlICplbnYsCiAgICAgaW50IGlkeDsKIAog
ICAgIE9wZW5SSVNDQ1BVICpjcHUgPSBvcGVucmlzY19lbnZfZ2V0X2NwdShlbnYpOworICAgIENQ
VVN0YXRlICpjcyA9IENQVShjcHUpOwogCiAgICAgc3dpdGNoIChzcHIpIHsKICAgICBjYXNlIFRP
X1NQUigwLCAwKTogLyogVlIgKi8KQEAgLTEzMiw3ICsxMzMsNyBAQCB2b2lkIEhFTFBFUihtdHNw
cikoQ1BVT3BlblJJU0NTdGF0ZSAqZW52LAogICAgICAgICAgICAgICAgIGVudi0+dHRtciA9IChy
YiAmIH5UVE1SX0lQKSArIGlwOwogICAgICAgICAgICAgfSBlbHNlIHsgICAgLyogQ2xlYXIgSVAg
Yml0LiAgKi8KICAgICAgICAgICAgICAgICBlbnYtPnR0bXIgPSByYiAmIH5UVE1SX0lQOwotICAg
ICAgICAgICAgICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJj0gfkNQVV9JTlRFUlJVUFRfVElN
RVI7CisgICAgICAgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJS
VVBUX1RJTUVSOwogICAgICAgICAgICAgfQogCiAgICAgICAgICAgICBjcHVfb3BlbnJpc2NfY291
bnRfdXBkYXRlKGNwdSk7CmRpZmYgLS1naXQgYS90YXJnZXQtcHBjL2NwdS5oIGIvdGFyZ2V0LXBw
Yy9jcHUuaAppbmRleCAyMGY0NTY1Li5mNDVkN2EwIDEwMDY0NAotLS0gYS90YXJnZXQtcHBjL2Nw
dS5oCisrKyBiL3RhcmdldC1wcGMvY3B1LmgKQEAgLTIyMzEsOSArMjIzMSwxMCBAQCBleHRlcm4g
dm9pZCAoKmNwdV9wcGNfaHlwZXJjYWxsKShQb3dlclBDQ1BVICopOwogCiBzdGF0aWMgaW5saW5l
IGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVUFBDU3RhdGUgKmVu
diA9ICZQT1dFUlBDX0NQVShjcHUpLT5lbnY7CisgICAgUG93ZXJQQ0NQVSAqcHBjX2NwdSA9IFBP
V0VSUENfQ1BVKGNwdSk7CisgICAgQ1BVUFBDU3RhdGUgKmVudiA9ICZwcGNfY3B1LT5lbnY7CiAK
LSAgICByZXR1cm4gbXNyX2VlICYmIChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVS
UlVQVF9IQVJEKTsKKyAgICByZXR1cm4gbXNyX2VlICYmIChjcHUtPmludGVycnVwdF9yZXF1ZXN0
ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKTsKIH0KIAogI2luY2x1ZGUgImV4ZWMvZXhlYy1hbGwuaCIK
ZGlmZiAtLWdpdCBhL3RhcmdldC1wcGMvZXhjcF9oZWxwZXIuYyBiL3RhcmdldC1wcGMvZXhjcF9o
ZWxwZXIuYwppbmRleCAwYTFhYzg2Li43OWNlN2JmIDEwMDY0NAotLS0gYS90YXJnZXQtcHBjL2V4
Y3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LXBwYy9leGNwX2hlbHBlci5jCkBAIC02Niw2ICs2Niw3
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBkdW1wX3N5c2NhbGwoQ1BVUFBDU3RhdGUgKmVudikKIHN0
YXRpYyBpbmxpbmUgdm9pZCBwb3dlcnBjX2V4Y3AoUG93ZXJQQ0NQVSAqY3B1LCBpbnQgZXhjcF9t
b2RlbCwgaW50IGV4Y3ApCiB7CiAgICAgQ1BVUFBDU3RhdGUgKmVudiA9ICZjcHUtPmVudjsKKyAg
ICBDUFVTdGF0ZSAqY3M7CiAgICAgdGFyZ2V0X3Vsb25nIG1zciwgbmV3X21zciwgdmVjdG9yOwog
ICAgIGludCBzcnIwLCBzcnIxLCBhc3JyMCwgYXNycjE7CiAgICAgaW50IGxwZXMwLCBscGVzMSwg
bGV2OwpAQCAtMTMxLDggKzEzMiw5IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBwb3dlcnBjX2V4Y3Ao
UG93ZXJQQ0NQVSAqY3B1LCBpbnQgZXhjcF9tb2RlbCwgaW50IGV4Y3ApCiAgICAgICAgICAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJNYWNoaW5lIGNoZWNrIHdoaWxlIG5vdCBhbGxvd2VkLiAiCiAg
ICAgICAgICAgICAgICAgICAgICAgICAiRW50ZXJpbmcgY2hlY2tzdG9wIHN0YXRlXG4iKTsKICAg
ICAgICAgICAgIH0KLSAgICAgICAgICAgIGVudi0+aGFsdGVkID0gMTsKLSAgICAgICAgICAgIGVu
di0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgICAgICAg
ICBjcyA9IENQVShjcHUpOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7CisgICAgICAgICAg
ICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CiAgICAgICAg
IH0KICAgICAgICAgaWYgKDApIHsKICAgICAgICAgICAgIC8qIFhYWDogZmluZCBhIHN1aXRhYmxl
IGNvbmRpdGlvbiB0byBlbmFibGUgdGhlIGh5cGVydmlzb3IgbW9kZSAqLwpAQCAtNjYzLDExICs2
NjUsMTIgQEAgdm9pZCBwcGNfaHdfaW50ZXJydXB0KENQVVBQQ1N0YXRlICplbnYpCiB7CiAgICAg
UG93ZXJQQ0NQVSAqY3B1ID0gcHBjX2Vudl9nZXRfY3B1KGVudik7CiAgICAgaW50IGhkaWNlOwot
CiAjaWYgMAorICAgIENQVVN0YXRlICpjcyA9IENQVShjcHUpOworCiAgICAgcWVtdV9sb2dfbWFz
ayhDUFVfTE9HX0lOVCwgIiVzOiAlcCBwZW5kaW5nICUwOHggcmVxICUwOHggbWUgJWQgZWUgJWRc
biIsCi0gICAgICAgICAgICAgICAgX19mdW5jX18sIGVudiwgZW52LT5wZW5kaW5nX2ludGVycnVw
dHMsCi0gICAgICAgICAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCwgKGludCltc3JfbWUs
IChpbnQpbXNyX2VlKTsKKyAgICAgICAgICAgICAgICAgIF9fZnVuY19fLCBlbnYsIGVudi0+cGVu
ZGluZ19pbnRlcnJ1cHRzLAorICAgICAgICAgICAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0
LCAoaW50KW1zcl9tZSwgKGludCltc3JfZWUpOwogI2VuZGlmCiAgICAgLyogRXh0ZXJuYWwgcmVz
ZXQgKi8KICAgICBpZiAoZW52LT5wZW5kaW5nX2ludGVycnVwdHMgJiAoMSA8PCBQUENfSU5URVJS
VVBUX1JFU0VUKSkgewpAQCAtODA3LDkgKzgxMCwxMiBAQCB2b2lkIGhlbHBlcl9yYWlzZV9leGNl
cHRpb24oQ1BVUFBDU3RhdGUgKmVudiwgdWludDMyX3QgZXhjZXB0aW9uKQogI2lmICFkZWZpbmVk
KENPTkZJR19VU0VSX09OTFkpCiB2b2lkIGhlbHBlcl9zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVu
diwgdGFyZ2V0X3Vsb25nIHZhbCkKIHsKKyAgICBDUFVTdGF0ZSAqY3M7CisKICAgICB2YWwgPSBo
cmVnX3N0b3JlX21zcihlbnYsIHZhbCwgMCk7CiAgICAgaWYgKHZhbCAhPSAwKSB7Ci0gICAgICAg
IGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgICAg
IGNzID0gQ1BVKHBwY19lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICAgICAgY3MtPmludGVycnVwdF9y
ZXF1ZXN0IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOwogICAgICAgICBoZWxwZXJfcmFpc2VfZXhj
ZXB0aW9uKGVudiwgdmFsKTsKICAgICB9CiB9CkBAIC04MTcsNiArODIzLDggQEAgdm9pZCBoZWxw
ZXJfc3RvcmVfbXNyKENQVVBQQ1N0YXRlICplbnYsIHRhcmdldF91bG9uZyB2YWwpCiBzdGF0aWMg
aW5saW5lIHZvaWQgZG9fcmZpKENQVVBQQ1N0YXRlICplbnYsIHRhcmdldF91bG9uZyBuaXAsIHRh
cmdldF91bG9uZyBtc3IsCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldF91bG9uZyBt
c3JtLCBpbnQga2VlcF9tc3JoKQogeworICAgIENQVVN0YXRlICpjcyA9IENQVShwcGNfZW52X2dl
dF9jcHUoZW52KSk7CisKICNpZiBkZWZpbmVkKFRBUkdFVF9QUEM2NCkKICAgICBpZiAobXNyX2lz
XzY0Yml0KGVudiwgbXNyKSkgewogICAgICAgICBuaXAgPSAodWludDY0X3QpbmlwOwpAQCAtODQx
LDcgKzg0OSw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBkb19yZmkoQ1BVUFBDU3RhdGUgKmVudiwg
dGFyZ2V0X3Vsb25nIG5pcCwgdGFyZ2V0X3Vsb25nIG1zciwKICAgICAvKiBObyBuZWVkIHRvIHJh
aXNlIGFuIGV4Y2VwdGlvbiBoZXJlLAogICAgICAqIGFzIHJmaSBpcyBhbHdheXMgdGhlIGxhc3Qg
aW5zbiBvZiBhIFRCCiAgICAgICovCi0gICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCB8PSBDUFVf
SU5URVJSVVBUX0VYSVRUQjsKKyAgICBjcy0+aW50ZXJydXB0X3JlcXVlc3QgfD0gQ1BVX0lOVEVS
UlVQVF9FWElUVEI7CiB9CiAKIHZvaWQgaGVscGVyX3JmaShDUFVQUENTdGF0ZSAqZW52KQpkaWZm
IC0tZ2l0IGEvdGFyZ2V0LXBwYy9oZWxwZXJfcmVncy5oIGIvdGFyZ2V0LXBwYy9oZWxwZXJfcmVn
cy5oCmluZGV4IDNjOTg4NTAuLmE2ZDVlMmYgMTAwNjQ0Ci0tLSBhL3RhcmdldC1wcGMvaGVscGVy
X3JlZ3MuaAorKysgYi90YXJnZXQtcHBjL2hlbHBlcl9yZWdzLmgKQEAgLTY4LDEwICs2OCwxMyBA
QCBzdGF0aWMgaW5saW5lIGludCBocmVnX3N0b3JlX21zcihDUFVQUENTdGF0ZSAqZW52LCB0YXJn
ZXRfdWxvbmcgdmFsdWUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgYWx0
ZXJfaHYpCiB7CiAgICAgaW50IGV4Y3A7CisjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkK
KyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUocHBjX2Vudl9nZXRfY3B1KGVudikpOworI2VuZGlmCiAK
ICAgICBleGNwID0gMDsKICAgICB2YWx1ZSAmPSBlbnYtPm1zcl9tYXNrOwotI2lmICFkZWZpbmVk
IChDT05GSUdfVVNFUl9PTkxZKQorI2lmICFkZWZpbmVkKENPTkZJR19VU0VSX09OTFkpCiAgICAg
aWYgKCFhbHRlcl9odikgewogICAgICAgICAvKiBtdG1zciBjYW5ub3QgYWx0ZXIgdGhlIGh5cGVy
dmlzb3Igc3RhdGUgKi8KICAgICAgICAgdmFsdWUgJj0gfk1TUl9IVkI7CkBAIC04Miw3ICs4NSw3
IEBAIHN0YXRpYyBpbmxpbmUgaW50IGhyZWdfc3RvcmVfbXNyKENQVVBQQ1N0YXRlICplbnYsIHRh
cmdldF91bG9uZyB2YWx1ZSwKICAgICAgICAgLyogRmx1c2ggYWxsIHRsYiB3aGVuIGNoYW5naW5n
IHRyYW5zbGF0aW9uIG1vZGUgKi8KICAgICAgICAgdGxiX2ZsdXNoKGVudiwgMSk7CiAgICAgICAg
IGV4Y3AgPSBQT1dFUlBDX0VYQ1BfTk9ORTsKLSAgICAgICAgZW52LT5pbnRlcnJ1cHRfcmVxdWVz
dCB8PSBDUFVfSU5URVJSVVBUX0VYSVRUQjsKKyAgICAgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0
IHw9IENQVV9JTlRFUlJVUFRfRVhJVFRCOwogICAgIH0KICAgICBpZiAodW5saWtlbHkoKGVudi0+
ZmxhZ3MgJiBQT1dFUlBDX0ZMQUdfVEdQUikgJiYKICAgICAgICAgICAgICAgICAgKCh2YWx1ZSBe
IGVudi0+bXNyKSAmICgxIDw8IE1TUl9UR1BSKSkpKSB7CkBAIC05NiwxMCArOTksMTAgQEAgc3Rh
dGljIGlubGluZSBpbnQgaHJlZ19zdG9yZV9tc3IoQ1BVUFBDU3RhdGUgKmVudiwgdGFyZ2V0X3Vs
b25nIHZhbHVlLAogI2VuZGlmCiAgICAgZW52LT5tc3IgPSB2YWx1ZTsKICAgICBocmVnX2NvbXB1
dGVfaGZsYWdzKGVudik7Ci0jaWYgIWRlZmluZWQgKENPTkZJR19VU0VSX09OTFkpCisjaWYgIWRl
ZmluZWQoQ09ORklHX1VTRVJfT05MWSkKICAgICBpZiAodW5saWtlbHkobXNyX3BvdyA9PSAxKSkg
ewogICAgICAgICBpZiAoKCplbnYtPmNoZWNrX3BvdykoZW52KSkgewotICAgICAgICAgICAgZW52
LT5oYWx0ZWQgPSAxOworICAgICAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgICAgICBl
eGNwID0gRVhDUF9IQUxURUQ7CiAgICAgICAgIH0KICAgICB9CmRpZmYgLS1naXQgYS90YXJnZXQt
cHBjL2t2bS5jIGIvdGFyZ2V0LXBwYy9rdm0uYwppbmRleCA4ZTY0NDE2Li5mMGM0ODQzIDEwMDY0
NAotLS0gYS90YXJnZXQtcHBjL2t2bS5jCisrKyBiL3RhcmdldC1wcGMva3ZtLmMKQEAgLTc2MCw3
ICs3NjAsNyBAQCB2b2lkIGt2bV9hcmNoX3ByZV9ydW4oQ1BVU3RhdGUgKmNzLCBzdHJ1Y3Qga3Zt
X3J1biAqcnVuKQogICAgICAqIGludGVycnVwdCwgcmVzZXQsIGV0YykgaW4gUFBDLXNwZWNpZmlj
IGVudi0+aXJxX2lucHV0X3N0YXRlLiAqLwogICAgIGlmICghY2FwX2ludGVycnVwdF9sZXZlbCAm
JgogICAgICAgICBydW4tPnJlYWR5X2Zvcl9pbnRlcnJ1cHRfaW5qZWN0aW9uICYmCi0gICAgICAg
IChlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgorICAgICAg
ICAoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAg
ICAoZW52LT5pcnFfaW5wdXRfc3RhdGUgJiAoMTw8UFBDX0lOUFVUX0lOVCkpKQogICAgIHsKICAg
ICAgICAgLyogRm9yIG5vdyBLVk0gZGlzcmVnYXJkcyB0aGUgJ2lycScgYXJndW1lbnQuIEhvd2V2
ZXIsIGluIHRoZQpAQCAtNzkxLDE0ICs3OTEsMTYgQEAgdm9pZCBrdm1fYXJjaF9wb3N0X3J1bihD
UFVTdGF0ZSAqY3B1LCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogCiBpbnQga3ZtX2FyY2hfcHJvY2Vz
c19hc3luY19ldmVudHMoQ1BVU3RhdGUgKmNzKQogewotICAgIFBvd2VyUENDUFUgKmNwdSA9IFBP
V0VSUENfQ1BVKGNzKTsKLSAgICByZXR1cm4gY3B1LT5lbnYuaGFsdGVkOworICAgIHJldHVybiBj
cy0+aGFsdGVkOwogfQogCi1zdGF0aWMgaW50IGt2bXBwY19oYW5kbGVfaGFsdChDUFVQUENTdGF0
ZSAqZW52KQorc3RhdGljIGludCBrdm1wcGNfaGFuZGxlX2hhbHQoUG93ZXJQQ0NQVSAqY3B1KQog
ewotICAgIGlmICghKGVudi0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQp
ICYmIChtc3JfZWUpKSB7Ci0gICAgICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAq
Y3MgPSBDUFUoY3B1KTsKKyAgICBDUFVQUENTdGF0ZSAqZW52ID0gJmNwdS0+ZW52OworCisgICAg
aWYgKCEoY3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJiAobXNy
X2VlKSkgeworICAgICAgICBjcy0+aGFsdGVkID0gMTsKICAgICAgICAgZW52LT5leGNlcHRpb25f
aW5kZXggPSBFWENQX0hMVDsKICAgICB9CiAKQEAgLTg0MCw3ICs4NDIsNyBAQCBpbnQga3ZtX2Fy
Y2hfaGFuZGxlX2V4aXQoQ1BVU3RhdGUgKmNzLCBzdHJ1Y3Qga3ZtX3J1biAqcnVuKQogICAgICAg
ICBicmVhazsKICAgICBjYXNlIEtWTV9FWElUX0hMVDoKICAgICAgICAgZHByaW50ZigiaGFuZGxl
IGhhbHRcbiIpOwotICAgICAgICByZXQgPSBrdm1wcGNfaGFuZGxlX2hhbHQoZW52KTsKKyAgICAg
ICAgcmV0ID0ga3ZtcHBjX2hhbmRsZV9oYWx0KGNwdSk7CiAgICAgICAgIGJyZWFrOwogI2lmZGVm
IENPTkZJR19QU0VSSUVTCiAgICAgY2FzZSBLVk1fRVhJVF9QQVBSX0hDQUxMOgpkaWZmIC0tZ2l0
IGEvdGFyZ2V0LXBwYy90cmFuc2xhdGUuYyBiL3RhcmdldC1wcGMvdHJhbnNsYXRlLmMKaW5kZXgg
Zjg4NjQ0MS4uZDhjMmRkMSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXBwYy90cmFuc2xhdGUuYworKysg
Yi90YXJnZXQtcHBjL3RyYW5zbGF0ZS5jCkBAIC0zMTAyLDcgKzMxMDIsOCBAQCBzdGF0aWMgdm9p
ZCBnZW5fc3luYyhEaXNhc0NvbnRleHQgKmN0eCkKIHN0YXRpYyB2b2lkIGdlbl93YWl0KERpc2Fz
Q29udGV4dCAqY3R4KQogewogICAgIFRDR3ZfaTMyIHQwID0gdGNnX3RlbXBfbmV3X2kzMigpOwot
ICAgIHRjZ19nZW5fc3RfaTMyKHQwLCBjcHVfZW52LCBvZmZzZXRvZihDUFVQUENTdGF0ZSwgaGFs
dGVkKSk7CisgICAgdGNnX2dlbl9zdF9pMzIodDAsIGNwdV9lbnYsCisgICAgICAgICAgICAgICAg
ICAgLW9mZnNldG9mKFBvd2VyUENDUFUsIGVudikgKyBvZmZzZXRvZihDUFVTdGF0ZSwgaGFsdGVk
KSk7CiAgICAgdGNnX3RlbXBfZnJlZV9pMzIodDApOwogICAgIC8qIFN0b3AgdHJhbnNsYXRpb24s
IGFzIHRoZSBDUFUgaXMgc3VwcG9zZWQgdG8gc2xlZXAgZnJvbSBub3cgKi8KICAgICBnZW5fZXhj
ZXB0aW9uX2VycihjdHgsIEVYQ1BfSExULCAxKTsKZGlmZiAtLWdpdCBhL3RhcmdldC1zMzkweC9j
cHUuYyBiL3RhcmdldC1zMzkweC9jcHUuYwppbmRleCBiNzQ2NTQ3Li43MzhhMGFkIDEwMDY0NAot
LS0gYS90YXJnZXQtczM5MHgvY3B1LmMKKysrIGIvdGFyZ2V0LXMzOTB4L2NwdS5jCkBAIC04MCwx
MCArODAsMTAgQEAgc3RhdGljIHZvaWQgczM5MF9jcHVfcmVzZXQoQ1BVU3RhdGUgKnMpCiAgICAg
ZW52LT5jcmVnc1swXSA9IENSMF9SRVNFVDsKICAgICBlbnYtPmNyZWdzWzE0XSA9IENSMTRfUkVT
RVQ7CiAgICAgLyogc2V0IGhhbHRlZCB0byAxIHRvIG1ha2Ugc3VyZSB3ZSBjYW4gYWRkIHRoZSBj
cHUgaW4KLSAgICAgKiBzMzkwX2lwbF9jcHUgY29kZSwgd2hlcmUgZW52LT5oYWx0ZWQgaXMgc2V0
IGJhY2sgdG8gMAorICAgICAqIHMzOTBfaXBsX2NwdSBjb2RlLCB3aGVyZSBDUFVTdGF0ZTo6aGFs
dGVkIGlzIHNldCBiYWNrIHRvIDAKICAgICAgKiBhZnRlciBpbmNyZW1lbnRpbmcgdGhlIGNwdSBj
b3VudGVyICovCiAjaWYgIWRlZmluZWQoQ09ORklHX1VTRVJfT05MWSkKLSAgICBlbnYtPmhhbHRl
ZCA9IDE7CisgICAgcy0+aGFsdGVkID0gMTsKICNlbmRpZgogICAgIHRsYl9mbHVzaChlbnYsIDEp
OwogfQpAQCAtMTI5LDEwICsxMjksMTAgQEAgc3RhdGljIHZvaWQgczM5MF9jcHVfaW5pdGZuKE9i
amVjdCAqb2JqKQogICAgIGVudi0+dG9kX2Jhc2V0aW1lID0gMDsKICAgICBlbnYtPnRvZF90aW1l
ciA9IHFlbXVfbmV3X3RpbWVyX25zKHZtX2Nsb2NrLCBzMzkweF90b2RfdGltZXIsIGNwdSk7CiAg
ICAgZW52LT5jcHVfdGltZXIgPSBxZW11X25ld190aW1lcl9ucyh2bV9jbG9jaywgczM5MHhfY3B1
X3RpbWVyLCBjcHUpOwotICAgIC8qIHNldCBlbnYtPmhhbHRlZCBzdGF0ZSB0byAxIHRvIGF2b2lk
IGRlY3JlbWVudGluZyB0aGUgcnVubmluZworICAgIC8qIHNldCBDUFVTdGF0ZTo6aGFsdGVkIHN0
YXRlIHRvIDEgdG8gYXZvaWQgZGVjcmVtZW50aW5nIHRoZSBydW5uaW5nCiAgICAgICogY3B1IGNv
dW50ZXIgaW4gczM5MF9jcHVfcmVzZXQgdG8gYSBuZWdhdGl2ZSBudW1iZXIgYXQKICAgICAgKiBp
bml0aWFsIGlwbCAqLwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcy0+aGFsdGVkID0gMTsK
ICNlbmRpZgogICAgIGVudi0+Y3B1X251bSA9IGNwdV9udW0rKzsKICAgICBlbnYtPmV4dF9pbmRl
eCA9IC0xOwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXMzOTB4L2NwdS5oIGIvdGFyZ2V0LXMzOTB4L2Nw
dS5oCmluZGV4IGU0NTBkYjcuLjg5N2FjNTkgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zMzkweC9jcHUu
aAorKysgYi90YXJnZXQtczM5MHgvY3B1LmgKQEAgLTEwMzksOSArMTAzOSwxMCBAQCBzdGF0aWMg
aW5saW5lIHZvaWQgY3B1X2luamVjdF9jcndfbWNoayhTMzkwQ1BVICpjcHUpCiAKIHN0YXRpYyBp
bmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVTMzkwWFN0
YXRlICplbnYgPSAmUzM5MF9DUFUoY3B1KS0+ZW52OworICAgIFMzOTBDUFUgKnMzOTBfY3B1ID0g
UzM5MF9DUFUoY3B1KTsKKyAgICBDUFVTMzkwWFN0YXRlICplbnYgPSAmczM5MF9jcHUtPmVudjsK
IAotICAgIHJldHVybiAoZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAmIENQVV9JTlRFUlJVUFRfSEFS
RCkgJiYKKyAgICByZXR1cm4gKGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBU
X0hBUkQpICYmCiAgICAgICAgIChlbnYtPnBzdy5tYXNrICYgUFNXX01BU0tfRVhUKTsKIH0KIApk
aWZmIC0tZ2l0IGEvdGFyZ2V0LXMzOTB4L2hlbHBlci5jIGIvdGFyZ2V0LXMzOTB4L2hlbHBlci5j
CmluZGV4IDExODNiNDUuLmM4OGE1ODcgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zMzkweC9oZWxwZXIu
YworKysgYi90YXJnZXQtczM5MHgvaGVscGVyLmMKQEAgLTQzNyw2ICs0MzcsNyBAQCB2b2lkIGxv
YWRfcHN3KENQVVMzOTBYU3RhdGUgKmVudiwgdWludDY0X3QgbWFzaywgdWludDY0X3QgYWRkcikK
IHsKICAgICBpZiAobWFzayAmIFBTV19NQVNLX1dBSVQpIHsKICAgICAgICAgUzM5MENQVSAqY3B1
ID0gczM5MF9lbnZfZ2V0X2NwdShlbnYpOworICAgICAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoY3B1
KTsKICAgICAgICAgaWYgKCEobWFzayAmIChQU1dfTUFTS19JTyB8IFBTV19NQVNLX0VYVCB8IFBT
V19NQVNLX01DSEVDSykpKSB7CiAgICAgICAgICAgICBpZiAoczM5MF9kZWxfcnVubmluZ19jcHUo
Y3B1KSA9PSAwKSB7CiAjaWZuZGVmIENPTkZJR19VU0VSX09OTFkKQEAgLTQ0NCw3ICs0NDUsNyBA
QCB2b2lkIGxvYWRfcHN3KENQVVMzOTBYU3RhdGUgKmVudiwgdWludDY0X3QgbWFzaywgdWludDY0
X3QgYWRkcikKICNlbmRpZgogICAgICAgICAgICAgfQogICAgICAgICB9Ci0gICAgICAgIGVudi0+
aGFsdGVkID0gMTsKKyAgICAgICAgY3MtPmhhbHRlZCA9IDE7CiAgICAgICAgIGVudi0+ZXhjZXB0
aW9uX2luZGV4ID0gRVhDUF9ITFQ7CiAgICAgfQogCkBAIC03MzksNiArNzQwLDcgQEAgc3RhdGlj
IHZvaWQgZG9fbWNoa19pbnRlcnJ1cHQoQ1BVUzM5MFhTdGF0ZSAqZW52KQogdm9pZCBkb19pbnRl
cnJ1cHQoQ1BVUzM5MFhTdGF0ZSAqZW52KQogewogICAgIFMzOTBDUFUgKmNwdSA9IHMzOTBfZW52
X2dldF9jcHUoZW52KTsKKyAgICBDUFVTdGF0ZSAqY3M7CiAKICAgICBxZW11X2xvZ19tYXNrKENQ
VV9MT0dfSU5ULCAiJXM6ICVkIGF0IHBjPSUiIFBSSXg2NCAiXG4iLAogICAgICAgICAgICAgICAg
ICAgX19mdW5jX18sIGVudi0+ZXhjZXB0aW9uX2luZGV4LCBlbnYtPnBzdy5hZGRyKTsKQEAgLTc5
Nyw3ICs3OTksOCBAQCB2b2lkIGRvX2ludGVycnVwdChDUFVTMzkwWFN0YXRlICplbnYpCiAgICAg
ZW52LT5leGNlcHRpb25faW5kZXggPSAtMTsKIAogICAgIGlmICghZW52LT5wZW5kaW5nX2ludCkg
ewotICAgICAgICBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICY9IH5DUFVfSU5URVJSVVBUX0hBUkQ7
CisgICAgICAgIGNzID0gQ1BVKHMzOTBfZW52X2dldF9jcHUoZW52KSk7CisgICAgICAgIGNzLT5p
bnRlcnJ1cHRfcmVxdWVzdCAmPSB+Q1BVX0lOVEVSUlVQVF9IQVJEOwogICAgIH0KIH0KIApkaWZm
IC0tZ2l0IGEvdGFyZ2V0LXNoNC9jcHUuaCBiL3RhcmdldC1zaDQvY3B1LmgKaW5kZXggZjgwNTc3
OC4uNDk2NjM1NSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXNoNC9jcHUuaAorKysgYi90YXJnZXQtc2g0
L2NwdS5oCkBAIC0zNjksOSArMzY5LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGNwdV9nZXRfdGJf
Y3B1X3N0YXRlKENQVVNINFN0YXRlICplbnYsIHRhcmdldF91bG9uZyAqcGMsCiAKIHN0YXRpYyBp
bmxpbmUgYm9vbCBjcHVfaGFzX3dvcmsoQ1BVU3RhdGUgKmNwdSkKIHsKLSAgICBDUFVTSDRTdGF0
ZSAqZW52ID0gJlNVUEVSSF9DUFUoY3B1KS0+ZW52OwotCi0gICAgcmV0dXJuIGVudi0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CisgICAgcmV0dXJuIGNwdS0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQ7CiB9CiAKICNpbmNsdWRlICJleGVjL2V4
ZWMtYWxsLmgiCmRpZmYgLS1naXQgYS90YXJnZXQtc2g0L2hlbHBlci5jIGIvdGFyZ2V0LXNoNC9o
ZWxwZXIuYwppbmRleCBkZGViYzc4Li5mZDRlZmVlIDEwMDY0NAotLS0gYS90YXJnZXQtc2g0L2hl
bHBlci5jCisrKyBiL3RhcmdldC1zaDQvaGVscGVyLmMKQEAgLTc4LDkgKzc4LDEwIEBAIGludCBj
cHVfc2g0X2lzX2NhY2hlZChDUFVTSDRTdGF0ZSAqIGVudiwgdGFyZ2V0X3Vsb25nIGFkZHIpCiAj
ZGVmaW5lIE1NVV9EQUREUl9FUlJPUl9SRUFEICAgICAoLTEyKQogI2RlZmluZSBNTVVfREFERFJf
RVJST1JfV1JJVEUgICAgKC0xMykKIAotdm9pZCBkb19pbnRlcnJ1cHQoQ1BVU0g0U3RhdGUgKiBl
bnYpCit2b2lkIGRvX2ludGVycnVwdChDUFVTSDRTdGF0ZSAqZW52KQogewotICAgIGludCBkb19p
cnEgPSBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOworICAgIENQ
VVN0YXRlICpjcyA9IENQVShzaF9lbnZfZ2V0X2NwdShlbnYpKTsKKyAgICBpbnQgZG9faXJxID0g
Y3MtPmludGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEOwogICAgIGludCBkb19l
eHAsIGlycV92ZWN0b3IgPSBlbnYtPmV4Y2VwdGlvbl9pbmRleDsKIAogICAgIC8qIHByaW9yaXRp
emUgZXhjZXB0aW9ucyBvdmVyIGludGVycnVwdHMgKi8KZGlmZiAtLWdpdCBhL3RhcmdldC1zaDQv
b3BfaGVscGVyLmMgYi90YXJnZXQtc2g0L29wX2hlbHBlci5jCmluZGV4IDA5ZTNkMjMuLmU5NTVl
ODEgMTAwNjQ0Ci0tLSBhL3RhcmdldC1zaDQvb3BfaGVscGVyLmMKKysrIGIvdGFyZ2V0LXNoNC9v
cF9oZWxwZXIuYwpAQCAtMTAyLDcgKzEwMiw5IEBAIHZvaWQgaGVscGVyX2RlYnVnKENQVVNINFN0
YXRlICplbnYpCiAKIHZvaWQgaGVscGVyX3NsZWVwKENQVVNINFN0YXRlICplbnYpCiB7Ci0gICAg
ZW52LT5oYWx0ZWQgPSAxOworICAgIENQVVN0YXRlICpjcyA9IENQVShzaF9lbnZfZ2V0X2NwdShl
bnYpKTsKKworICAgIGNzLT5oYWx0ZWQgPSAxOwogICAgIGVudi0+aW5fc2xlZXAgPSAxOwogICAg
IHJhaXNlX2V4Y2VwdGlvbihlbnYsIEVYQ1BfSExULCAwKTsKIH0KZGlmZiAtLWdpdCBhL3Rhcmdl
dC1zcGFyYy9jcHUuaCBiL3RhcmdldC1zcGFyYy9jcHUuaAppbmRleCBhMmYyY2M4Li44YTJmOGRm
IDEwMDY0NAotLS0gYS90YXJnZXQtc3BhcmMvY3B1LmgKKysrIGIvdGFyZ2V0LXNwYXJjL2NwdS5o
CkBAIC03NjIsOSArNzYyLDEwIEBAIHN0YXRpYyBpbmxpbmUgYm9vbCB0Yl9hbV9lbmFibGVkKGlu
dCB0Yl9mbGFncykKIAogc3RhdGljIGlubGluZSBib29sIGNwdV9oYXNfd29yayhDUFVTdGF0ZSAq
Y3B1KQogewotICAgIENQVVNQQVJDU3RhdGUgKmVudjEgPSAmU1BBUkNfQ1BVKGNwdSktPmVudjsK
KyAgICBTUEFSQ0NQVSAqc3BhcmNfY3B1ID0gU1BBUkNfQ1BVKGNwdSk7CisgICAgQ1BVU1BBUkNT
dGF0ZSAqZW52MSA9ICZzcGFyY19jcHUtPmVudjsKIAotICAgIHJldHVybiAoZW52MS0+aW50ZXJy
dXB0X3JlcXVlc3QgJiBDUFVfSU5URVJSVVBUX0hBUkQpICYmCisgICAgcmV0dXJuIChjcHUtPmlu
dGVycnVwdF9yZXF1ZXN0ICYgQ1BVX0lOVEVSUlVQVF9IQVJEKSAmJgogICAgICAgICAgICBjcHVf
aW50ZXJydXB0c19lbmFibGVkKGVudjEpOwogfQogCmRpZmYgLS1naXQgYS90YXJnZXQtc3BhcmMv
aGVscGVyLmMgYi90YXJnZXQtc3BhcmMvaGVscGVyLmMKaW5kZXggNThlN2VmZS4uNTdjMjBhZiAx
MDA2NDQKLS0tIGEvdGFyZ2V0LXNwYXJjL2hlbHBlci5jCisrKyBiL3RhcmdldC1zcGFyYy9oZWxw
ZXIuYwpAQCAtMjI5LDcgKzIyOSw5IEBAIHRhcmdldF91bG9uZyBoZWxwZXJfdHN1YmNjdHYoQ1BV
U1BBUkNTdGF0ZSAqZW52LCB0YXJnZXRfdWxvbmcgc3JjMSwKICNpZm5kZWYgVEFSR0VUX1NQQVJD
NjQKIHZvaWQgaGVscGVyX3Bvd2VyX2Rvd24oQ1BVU1BBUkNTdGF0ZSAqZW52KQogewotICAgIGVu
di0+aGFsdGVkID0gMTsKKyAgICBDUFVTdGF0ZSAqY3MgPSBDUFUoc3BhcmNfZW52X2dldF9jcHUo
ZW52KSk7CisKKyAgICBjcy0+aGFsdGVkID0gMTsKICAgICBlbnYtPmV4Y2VwdGlvbl9pbmRleCA9
IEVYQ1BfSExUOwogICAgIGVudi0+cGMgPSBlbnYtPm5wYzsKICAgICBlbnYtPm5wYyA9IGVudi0+
cGMgKyA0OwpkaWZmIC0tZ2l0IGEvdGFyZ2V0LXVuaWNvcmUzMi9jcHUuaCBiL3RhcmdldC11bmlj
b3JlMzIvY3B1LmgKaW5kZXggYWU5YTlkNi4uNThmMWYyMCAxMDA2NDQKLS0tIGEvdGFyZ2V0LXVu
aWNvcmUzMi9jcHUuaAorKysgYi90YXJnZXQtdW5pY29yZTMyL2NwdS5oCkBAIC0xODEsOSArMTgx
LDcgQEAgdm9pZCBzd2l0Y2hfbW9kZShDUFVVbmlDb3JlMzJTdGF0ZSAqLCBpbnQpOwogCiBzdGF0
aWMgaW5saW5lIGJvb2wgY3B1X2hhc193b3JrKENQVVN0YXRlICpjcHUpCiB7Ci0gICAgQ1BVVW5p
Q29yZTMyU3RhdGUgKmVudiA9ICZVTklDT1JFMzJfQ1BVKGNwdSktPmVudjsKLQotICAgIHJldHVy
biBlbnYtPmludGVycnVwdF9yZXF1ZXN0ICYKKyAgICByZXR1cm4gY3B1LT5pbnRlcnJ1cHRfcmVx
dWVzdCAmCiAgICAgICAgIChDUFVfSU5URVJSVVBUX0hBUkQgfCBDUFVfSU5URVJSVVBUX0VYSVRU
Qik7CiB9CiAKZGlmZiAtLWdpdCBhL3RhcmdldC11bmljb3JlMzIvc29mdG1tdS5jIGIvdGFyZ2V0
LXVuaWNvcmUzMi9zb2Z0bW11LmMKaW5kZXggZmMyNzEwMC4uMWM0YzdmNSAxMDA2NDQKLS0tIGEv
dGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11LmMKKysrIGIvdGFyZ2V0LXVuaWNvcmUzMi9zb2Z0bW11
LmMKQEAgLTc0LDYgKzc0LDcgQEAgdm9pZCBzd2l0Y2hfbW9kZShDUFVVbmlDb3JlMzJTdGF0ZSAq
ZW52LCBpbnQgbW9kZSkKIC8qIEhhbmRsZSBhIENQVSBleGNlcHRpb24uICAqLwogdm9pZCBkb19p
bnRlcnJ1cHQoQ1BVVW5pQ29yZTMyU3RhdGUgKmVudikKIHsKKyAgICBDUFVTdGF0ZSAqY3MgPSBD
UFUodWMzMl9lbnZfZ2V0X2NwdShlbnYpKTsKICAgICB1aW50MzJfdCBhZGRyOwogICAgIGludCBu
ZXdfbW9kZTsKIApAQCAtMTEyLDcgKzExMyw3IEBAIHZvaWQgZG9faW50ZXJydXB0KENQVVVuaUNv
cmUzMlN0YXRlICplbnYpCiAgICAgLyogVGhlIFBDIGFscmVhZHkgcG9pbnRzIHRvIHRoZSBwcm9w
ZXIgaW5zdHJ1Y3Rpb24uICAqLwogICAgIGVudi0+cmVnc1szMF0gPSBlbnYtPnJlZ3NbMzFdOwog
ICAgIGVudi0+cmVnc1szMV0gPSBhZGRyOwotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0g
Q1BVX0lOVEVSUlVQVF9FWElUVEI7CisgICAgY3MtPmludGVycnVwdF9yZXF1ZXN0IHw9IENQVV9J
TlRFUlJVUFRfRVhJVFRCOwogfQogCiBzdGF0aWMgaW50IGdldF9waHlzX2FkZHJfdWN2MihDUFVV
bmlDb3JlMzJTdGF0ZSAqZW52LCB1aW50MzJfdCBhZGRyZXNzLApkaWZmIC0tZ2l0IGEvdGFyZ2V0
LXh0ZW5zYS9vcF9oZWxwZXIuYyBiL3RhcmdldC14dGVuc2Evb3BfaGVscGVyLmMKaW5kZXggMzgx
M2E3Mi4uMTAzNzEwMSAxMDA2NDQKLS0tIGEvdGFyZ2V0LXh0ZW5zYS9vcF9oZWxwZXIuYworKysg
Yi90YXJnZXQteHRlbnNhL29wX2hlbHBlci5jCkBAIC0zNzMsNiArMzczLDggQEAgdm9pZCBIRUxQ
RVIoZHVtcF9zdGF0ZSkoQ1BVWHRlbnNhU3RhdGUgKmVudikKIAogdm9pZCBIRUxQRVIod2FpdGkp
KENQVVh0ZW5zYVN0YXRlICplbnYsIHVpbnQzMl90IHBjLCB1aW50MzJfdCBpbnRsZXZlbCkKIHsK
KyAgICBDUFVTdGF0ZSAqY3B1OworCiAgICAgZW52LT5wYyA9IHBjOwogICAgIGVudi0+c3JlZ3Nb
UFNdID0gKGVudi0+c3JlZ3NbUFNdICYgflBTX0lOVExFVkVMKSB8CiAgICAgICAgIChpbnRsZXZl
bCA8PCBQU19JTlRMRVZFTF9TSElGVCk7CkBAIC0zODIsOCArMzg0LDkgQEAgdm9pZCBIRUxQRVIo
d2FpdGkpKENQVVh0ZW5zYVN0YXRlICplbnYsIHVpbnQzMl90IHBjLCB1aW50MzJfdCBpbnRsZXZl
bCkKICAgICAgICAgcmV0dXJuOwogICAgIH0KIAorICAgIGNwdSA9IENQVSh4dGVuc2FfZW52X2dl
dF9jcHUoZW52KSk7CiAgICAgZW52LT5oYWx0X2Nsb2NrID0gcWVtdV9nZXRfY2xvY2tfbnModm1f
Y2xvY2spOwotICAgIGVudi0+aGFsdGVkID0gMTsKKyAgICBjcHUtPmhhbHRlZCA9IDE7CiAgICAg
aWYgKHh0ZW5zYV9vcHRpb25fZW5hYmxlZChlbnYtPmNvbmZpZywgWFRFTlNBX09QVElPTl9USU1F
Ul9JTlRFUlJVUFQpKSB7CiAgICAgICAgIHh0ZW5zYV9yZWFybV9jY29tcGFyZV90aW1lcihlbnYp
OwogICAgIH0KZGlmZiAtLWdpdCBhL3RyYW5zbGF0ZS1hbGwuYyBiL3RyYW5zbGF0ZS1hbGwuYwpp
bmRleCBiNTBmYjg5Li5hZGE4ZDdlIDEwMDY0NAotLS0gYS90cmFuc2xhdGUtYWxsLmMKKysrIGIv
dHJhbnNsYXRlLWFsbC5jCkBAIC0xMDc3LDggKzEwNzcsOCBAQCB2b2lkIHRiX2ludmFsaWRhdGVf
cGh5c19wYWdlX3JhbmdlKHRiX3BhZ2VfYWRkcl90IHN0YXJ0LCB0Yl9wYWdlX2FkZHJfdCBlbmQs
CiAgICAgICAgICAgICB0Yl9waHlzX2ludmFsaWRhdGUodGIsIC0xKTsKICAgICAgICAgICAgIGlm
IChjcHUgIT0gTlVMTCkgewogICAgICAgICAgICAgICAgIGNwdS0+Y3VycmVudF90YiA9IHNhdmVk
X3RiOwotICAgICAgICAgICAgICAgIGlmIChlbnYgJiYgZW52LT5pbnRlcnJ1cHRfcmVxdWVzdCAm
JiBjcHUtPmN1cnJlbnRfdGIpIHsKLSAgICAgICAgICAgICAgICAgICAgY3B1X2ludGVycnVwdChl
bnYsIGVudi0+aW50ZXJydXB0X3JlcXVlc3QpOworICAgICAgICAgICAgICAgIGlmIChlbnYgJiYg
Y3B1LT5pbnRlcnJ1cHRfcmVxdWVzdCAmJiBjcHUtPmN1cnJlbnRfdGIpIHsKKyAgICAgICAgICAg
ICAgICAgICAgY3B1X2ludGVycnVwdChlbnYsIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QpOwogICAg
ICAgICAgICAgICAgIH0KICAgICAgICAgICAgIH0KICAgICAgICAgfQpAQCAtMTQ1Niw4ICsxNDU2
LDggQEAgc3RhdGljIHZvaWQgdGNnX2hhbmRsZV9pbnRlcnJ1cHQoQ1BVQXJjaFN0YXRlICplbnYs
IGludCBtYXNrKQogICAgIENQVVN0YXRlICpjcHUgPSBFTlZfR0VUX0NQVShlbnYpOwogICAgIGlu
dCBvbGRfbWFzazsKIAotICAgIG9sZF9tYXNrID0gZW52LT5pbnRlcnJ1cHRfcmVxdWVzdDsKLSAg
ICBlbnYtPmludGVycnVwdF9yZXF1ZXN0IHw9IG1hc2s7CisgICAgb2xkX21hc2sgPSBjcHUtPmlu
dGVycnVwdF9yZXF1ZXN0OworICAgIGNwdS0+aW50ZXJydXB0X3JlcXVlc3QgfD0gbWFzazsKIAog
ICAgIC8qCiAgICAgICogSWYgY2FsbGVkIGZyb20gaW90aHJlYWQgY29udGV4dCwgd2FrZSB0aGUg
dGFyZ2V0IGNwdSBpbgpAQCAtMTYyNSw3ICsxNjI1LDcgQEAgdm9pZCBjcHVfaW50ZXJydXB0KENQ
VUFyY2hTdGF0ZSAqZW52LCBpbnQgbWFzaykKIHsKICAgICBDUFVTdGF0ZSAqY3B1ID0gRU5WX0dF
VF9DUFUoZW52KTsKIAotICAgIGVudi0+aW50ZXJydXB0X3JlcXVlc3QgfD0gbWFzazsKKyAgICBj
cHUtPmludGVycnVwdF9yZXF1ZXN0IHw9IG1hc2s7CiAgICAgY3B1X3VubGlua190YihjcHUpOwog
fQogCmRpZmYgLS1naXQgYS94ZW4tYWxsLmMgYi94ZW4tYWxsLmMKaW5kZXggMTEwZjk1OC4uOGMw
NTg0MyAxMDA2NDQKLS0tIGEveGVuLWFsbC5jCisrKyBiL3hlbi1hbGwuYwpAQCAtNTc4LDE2ICs1
NzgsMTggQEAgdm9pZCBxbXBfeGVuX3NldF9nbG9iYWxfZGlydHlfbG9nKGJvb2wgZW5hYmxlLCBF
cnJvciAqKmVycnApCiAKIHN0YXRpYyB2b2lkIHhlbl9yZXNldF92Y3B1KHZvaWQgKm9wYXF1ZSkK
IHsKLSAgICBDUFVBcmNoU3RhdGUgKmVudiA9IG9wYXF1ZTsKKyAgICBDUFVTdGF0ZSAqY3B1ID0g
b3BhcXVlOwogCi0gICAgZW52LT5oYWx0ZWQgPSAxOworICAgIGNwdS0+aGFsdGVkID0gMTsKIH0K
IAogdm9pZCB4ZW5fdmNwdV9pbml0KHZvaWQpCiB7CiAgICAgaWYgKGZpcnN0X2NwdSAhPSBOVUxM
KSB7Ci0gICAgICAgIHFlbXVfcmVnaXN0ZXJfcmVzZXQoeGVuX3Jlc2V0X3ZjcHUsIGZpcnN0X2Nw
dSk7Ci0gICAgICAgIHhlbl9yZXNldF92Y3B1KGZpcnN0X2NwdSk7CisgICAgICAgIENQVVN0YXRl
ICpjcHUgPSBFTlZfR0VUX0NQVShmaXJzdF9jcHUpOworCisgICAgICAgIHFlbXVfcmVnaXN0ZXJf
cmVzZXQoeGVuX3Jlc2V0X3ZjcHUsIGNwdSk7CisgICAgICAgIHhlbl9yZXNldF92Y3B1KGNwdSk7
CiAgICAgfQogICAgIC8qIGlmIHJ0Y19jbG9jayBpcyBsZWZ0IHRvIGRlZmF1bHQgKGhvc3RfY2xv
Y2spLCBkaXNhYmxlIGl0ICovCiAgICAgaWYgKHJ0Y19jbG9jayA9PSBob3N0X2Nsb2NrKSB7Ci0t
IAoxLjcuMTAuNAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:01:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:01: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 1UA3IS-0004Lt-KA; Mon, 25 Feb 2013 19:01:08 +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 1UA3IQ-0004Li-Rr
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 19:01:07 +0000
Received: from [85.158.137.99:7219] by server-13.bemta-3.messagelabs.com id
	CD/13-20653-DE4BB215; Mon, 25 Feb 2013 19:01:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361818858!15675967!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6699 invoked from network); 25 Feb 2013 19:01:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 19:01:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PJ0oGf010860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 19:00: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
	r1PJ0ncn010254
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 19:00:50 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
	r1PJ0m2k022753; Mon, 25 Feb 2013 13:00:48 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 11:00:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 213C81C3935; Mon, 25 Feb 2013 14:00:46 -0500 (EST)
Date: Mon, 25 Feb 2013 14:00:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, jeremy@goop.org
Message-ID: <20130225190046.GA12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361811390.26546.205.camel@zakaz.uk.xensource.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>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > And also put my name behind the mainternship.
> 
> I think you could also safely remove Jeremy these days?

Jeremy, are you OK with me removing your name from it and
> 
> Maybe we should have a Linux style CREDITS file to retain the names of
> historical contributors/maintainers?

.. transferring it in a new CREDITS file?

> 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > ---
> >  MAINTAINERS | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0358a3e..e2252fc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
> >  
> >  LINUX (PV_OPS)
> >  M:	Jeremy Fitzhardinge <jeremy@goop.org>
> > +M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >  S:	Supported
> > -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> >  
> >  LINUX (XCP)
> >  M:	Ian Campbell <ian.campbell@citrix.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 Mon Feb 25 19:01:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:01: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 1UA3IS-0004Lt-KA; Mon, 25 Feb 2013 19:01:08 +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 1UA3IQ-0004Li-Rr
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 19:01:07 +0000
Received: from [85.158.137.99:7219] by server-13.bemta-3.messagelabs.com id
	CD/13-20653-DE4BB215; Mon, 25 Feb 2013 19:01:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361818858!15675967!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ1Njg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6699 invoked from network); 25 Feb 2013 19:01:00 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Feb 2013 19:01:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PJ0oGf010860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 19:00: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
	r1PJ0ncn010254
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 19:00:50 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
	r1PJ0m2k022753; Mon, 25 Feb 2013 13:00:48 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 11:00:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 213C81C3935; Mon, 25 Feb 2013 14:00:46 -0500 (EST)
Date: Mon, 25 Feb 2013 14:00:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, jeremy@goop.org
Message-ID: <20130225190046.GA12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361811390.26546.205.camel@zakaz.uk.xensource.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>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > And also put my name behind the mainternship.
> 
> I think you could also safely remove Jeremy these days?

Jeremy, are you OK with me removing your name from it and
> 
> Maybe we should have a Linux style CREDITS file to retain the names of
> historical contributors/maintainers?

.. transferring it in a new CREDITS file?

> 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> > ---
> >  MAINTAINERS | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0358a3e..e2252fc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
> >  
> >  LINUX (PV_OPS)
> >  M:	Jeremy Fitzhardinge <jeremy@goop.org>
> > +M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >  S:	Supported
> > -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> >  
> >  LINUX (XCP)
> >  M:	Ian Campbell <ian.campbell@citrix.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 Mon Feb 25 19:08:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 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 1UA3PT-0004cH-H3; Mon, 25 Feb 2013 19:08:23 +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 1UA3PS-0004cC-4Q
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:08:22 +0000
Received: from [193.109.254.147:35896] by server-7.bemta-14.messagelabs.com id
	C4/BD-13581-5A6BB215; Mon, 25 Feb 2013 19:08:21 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361819296!4035120!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzQ3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3600 invoked from network); 25 Feb 2013 19:08:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 19:08:17 -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 C8DAC1CBE;
	Mon, 25 Feb 2013 21:08:14 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6412EF4017; Mon, 25 Feb 2013 21:08:14 +0200 (EET)
Date: Mon, 25 Feb 2013 21:08:14 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130225190814.GB8912@reaktio.net>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
	<20130221124252.GR8912@reaktio.net>
	<20130225170321.GA11165@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130225170321.GA11165@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 25, 2013 at 12:03:21PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 02:42:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > > > Hello,
> > > > =

> > > > Does anyone know why loading xen-acpi-processor driver fails like t=
his?:
> > > > =

> > > > # modprobe xen-acpi-processor
> > > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el=
6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output=
 error
> > > > =

> > > > Using "modprobe -v" doesn't provide any more information about the =
problem.
> > > > Also there's nothing in dom0 kernel dmesg.
> > > > =

> > > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > > > Xen 4.2.1.
> > > > =

> > > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stab=
le version) =

> > > > with some additional Xen patches backported from later upstream ker=
nels. =

> > > > Any tips how to troubleshoot this? =

> > > =

> > > Rebuild the module and add this
> > > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-=
processor.c
> > > index 316df65..5d824a2 100644
> > > --- a/drivers/xen/xen-acpi-processor.c
> > > +++ b/drivers/xen/xen-acpi-processor.c
> > > @@ -16,6 +16,7 @@
> > >   * more details.
> > >   *
> > >   */
> > > +#define DEBUG 1
> > >  =

> > >  #include <linux/cpumask.h>
> > >  #include <linux/cpufreq.h>
> > > =

> > > =

> > > That should help in figuring it out.
> > > =

> > =

> > Ok, I'll do that.
> > =

> > Thanks!
> =

> The other thing is that I've been running with this compiled as '=3Dy' in=
stead
> of '=3Dm'!
> =

> That should temporarily fix it for you, but this does need to be fixed.
>

Actually it seems I'm getting the exact same problem even with CONFIG_XEN_A=
CPI_PROCESSOR=3Dy.

I guess I'll have to dig deeper into the ACPI code..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:08:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 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 1UA3PT-0004cH-H3; Mon, 25 Feb 2013 19:08:23 +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 1UA3PS-0004cC-4Q
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:08:22 +0000
Received: from [193.109.254.147:35896] by server-7.bemta-14.messagelabs.com id
	C4/BD-13581-5A6BB215; Mon, 25 Feb 2013 19:08:21 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361819296!4035120!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzQ3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3600 invoked from network); 25 Feb 2013 19:08:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 19:08:17 -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 C8DAC1CBE;
	Mon, 25 Feb 2013 21:08:14 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6412EF4017; Mon, 25 Feb 2013 21:08:14 +0200 (EET)
Date: Mon, 25 Feb 2013 21:08:14 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130225190814.GB8912@reaktio.net>
References: <20130221092434.GQ8912@reaktio.net>
	<20130221122913.GC6647@phenom.dumpdata.com>
	<20130221124252.GR8912@reaktio.net>
	<20130225170321.GA11165@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130225170321.GA11165@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Linux 3.4 dom0 kernel error loading
 xen-acpi-processor: Input/output 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="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, Feb 25, 2013 at 12:03:21PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 02:42:52PM +0200, Pasi K=E4rkk=E4inen wrote:
> > On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi K=E4rkk=E4inen wrote:
> > > > Hello,
> > > > =

> > > > Does anyone know why loading xen-acpi-processor driver fails like t=
his?:
> > > > =

> > > > # modprobe xen-acpi-processor
> > > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el=
6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output=
 error
> > > > =

> > > > Using "modprobe -v" doesn't provide any more information about the =
problem.
> > > > Also there's nothing in dom0 kernel dmesg.
> > > > =

> > > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. =

> > > > Xen 4.2.1.
> > > > =

> > > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stab=
le version) =

> > > > with some additional Xen patches backported from later upstream ker=
nels. =

> > > > Any tips how to troubleshoot this? =

> > > =

> > > Rebuild the module and add this
> > > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-=
processor.c
> > > index 316df65..5d824a2 100644
> > > --- a/drivers/xen/xen-acpi-processor.c
> > > +++ b/drivers/xen/xen-acpi-processor.c
> > > @@ -16,6 +16,7 @@
> > >   * more details.
> > >   *
> > >   */
> > > +#define DEBUG 1
> > >  =

> > >  #include <linux/cpumask.h>
> > >  #include <linux/cpufreq.h>
> > > =

> > > =

> > > That should help in figuring it out.
> > > =

> > =

> > Ok, I'll do that.
> > =

> > Thanks!
> =

> The other thing is that I've been running with this compiled as '=3Dy' in=
stead
> of '=3Dm'!
> =

> That should temporarily fix it for you, but this does need to be fixed.
>

Actually it seems I'm getting the exact same problem even with CONFIG_XEN_A=
CPI_PROCESSOR=3Dy.

I guess I'll have to dig deeper into the ACPI code..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:08:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:08: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 1UA3PZ-0004cg-TX; Mon, 25 Feb 2013 19:08:29 +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 1UA3PY-0004cX-JC
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 19:08:28 +0000
Received: from [85.158.143.99:63152] by server-1.bemta-4.messagelabs.com id
	D8/50-06203-BA6BB215; Mon, 25 Feb 2013 19:08:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361819305!22125167!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8194 invoked from network); 25 Feb 2013 19:08:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 19:08:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PJ7Mnp013181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 19:07:23 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
	r1PJ7MuZ022087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 19:07:22 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
	r1PJ7MuD002537; Mon, 25 Feb 2013 13:07:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 11:07:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9DEB41C3935; Mon, 25 Feb 2013 14:07:20 -0500 (EST)
Date: Mon, 25 Feb 2013 14:07:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, jeremy@goop.org
Message-ID: <20130225190720.GB12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361811390.26546.205.camel@zakaz.uk.xensource.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>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > And also put my name behind the mainternship.
> 
> I think you could also safely remove Jeremy these days?
> 
> Maybe we should have a Linux style CREDITS file to retain the names of
> historical contributors/maintainers?

Like this:

>From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 14:04:55 -0500
Subject: [PATCH] CREDITS: First checkin.

Adding Jeremy and moving him from the MAINTAINERS file.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 CREDITS     | 16 ++++++++++++++++
 MAINTAINERS |  1 -
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 CREDITS

diff --git a/CREDITS b/CREDITS
new file mode 100644
index 0000000..eaf05bf
--- /dev/null
+++ b/CREDITS
@@ -0,0 +1,16 @@
+    This is at least a partial credits-file of people that have
+    contributed to the Xen project.  It is sorted by name and
+    formatted to allow easy grepping and beautification by
+    scripts.  The fields are: name (N), email (E), web-address
+    (W), PGP key ID and fingerprint (P), description (D), and
+    snail-mail address (S).
+    Thanks,
+
+            Xen team
+----------
+
+N: Jeremy Fitzhardinge
+E: jeremy@goop.org
+W: http://www.goop.org/~jeremy
+P: 1B40B6D0
+D: Linux pvops

I didn't put his physical address b/c I don't know if he would like
it there?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:08:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:08: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 1UA3PZ-0004cg-TX; Mon, 25 Feb 2013 19:08:29 +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 1UA3PY-0004cX-JC
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 19:08:28 +0000
Received: from [85.158.143.99:63152] by server-1.bemta-4.messagelabs.com id
	D8/50-06203-BA6BB215; Mon, 25 Feb 2013 19:08:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361819305!22125167!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTY5MDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8194 invoked from network); 25 Feb 2013 19:08:27 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 19:08:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1PJ7Mnp013181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 25 Feb 2013 19:07:23 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
	r1PJ7MuZ022087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 25 Feb 2013 19:07:22 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
	r1PJ7MuD002537; Mon, 25 Feb 2013 13:07:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 11:07:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9DEB41C3935; Mon, 25 Feb 2013 14:07:20 -0500 (EST)
Date: Mon, 25 Feb 2013 14:07:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, jeremy@goop.org
Message-ID: <20130225190720.GB12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361811390.26546.205.camel@zakaz.uk.xensource.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>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > And also put my name behind the mainternship.
> 
> I think you could also safely remove Jeremy these days?
> 
> Maybe we should have a Linux style CREDITS file to retain the names of
> historical contributors/maintainers?

Like this:

>From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 25 Feb 2013 14:04:55 -0500
Subject: [PATCH] CREDITS: First checkin.

Adding Jeremy and moving him from the MAINTAINERS file.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 CREDITS     | 16 ++++++++++++++++
 MAINTAINERS |  1 -
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 CREDITS

diff --git a/CREDITS b/CREDITS
new file mode 100644
index 0000000..eaf05bf
--- /dev/null
+++ b/CREDITS
@@ -0,0 +1,16 @@
+    This is at least a partial credits-file of people that have
+    contributed to the Xen project.  It is sorted by name and
+    formatted to allow easy grepping and beautification by
+    scripts.  The fields are: name (N), email (E), web-address
+    (W), PGP key ID and fingerprint (P), description (D), and
+    snail-mail address (S).
+    Thanks,
+
+            Xen team
+----------
+
+N: Jeremy Fitzhardinge
+E: jeremy@goop.org
+W: http://www.goop.org/~jeremy
+P: 1B40B6D0
+D: Linux pvops

I didn't put his physical address b/c I don't know if he would like
it there?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:09:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:09: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 1UA3Py-0004fS-Ab; Mon, 25 Feb 2013 19:08: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 1UA3Pw-0004fG-Nf
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 19:08:53 +0000
Received: from [85.158.137.99:63114] by server-16.bemta-3.messagelabs.com id
	AB/2C-02727-FB6BB215; Mon, 25 Feb 2013 19:08:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361819326!14866239!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28975 invoked from network); 25 Feb 2013 19:08:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 19:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="1857403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 19:08: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.297.1; Mon, 25 Feb 2013 19:08:26 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UA3PW-0001NA-C9;
	Mon, 25 Feb 2013 19:08:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UA3PW-00066I-6C;
	Mon, 25 Feb 2013 19:08:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16657-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 19:08:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16657: 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 16657 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-qemut-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:09:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:09: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 1UA3Py-0004fS-Ab; Mon, 25 Feb 2013 19:08: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 1UA3Pw-0004fG-Nf
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 19:08:53 +0000
Received: from [85.158.137.99:63114] by server-16.bemta-3.messagelabs.com id
	AB/2C-02727-FB6BB215; Mon, 25 Feb 2013 19:08:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361819326!14866239!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28975 invoked from network); 25 Feb 2013 19:08:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 19:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="1857403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 19:08: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.297.1; Mon, 25 Feb 2013 19:08:26 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UA3PW-0001NA-C9;
	Mon, 25 Feb 2013 19:08:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UA3PW-00066I-6C;
	Mon, 25 Feb 2013 19:08:26 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16657-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 19:08:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16657: 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 16657 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16657/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-xl-multivcpu  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            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-qemut-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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4291b626cee8aff5d976c5829a79fceca9cff420
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 4291b626cee8aff5d976c5829a79fceca9cff420
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Fri Feb 22 18:16:54 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:34:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19: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 1UA3oh-0005iR-LV; Mon, 25 Feb 2013 19:34: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 1UA3og-0005iM-Br
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:34:26 +0000
Received: from [193.109.254.147:62806] by server-15.bemta-14.messagelabs.com
	id A9/E0-24599-1CCBB215; Mon, 25 Feb 2013 19:34:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361820862!1938227!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22861 invoked from network); 25 Feb 2013 19:34:24 -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;
	25 Feb 2013 19:34:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="9474469"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 19:34:22 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 14:34:21 -0500
Message-ID: <512BBCBC.8050404@citrix.com>
Date: Mon, 25 Feb 2013 19:34:20 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Don Slutz <Don@CloudSwitch.Com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
	<512BAEB3.4010708@CloudSwitch.Com>
In-Reply-To: <512BAEB3.4010708@CloudSwitch.Com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

On 25/02/13 18:34, Don Slutz wrote:
> 
> I did not find a fix/change to get_xen_vmcoreinfo() to call on 
> xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, ...
> 
> I found the following to work.
>     -Don Slutz
> 
>  From 2cabc018d7613b0d2ac487cbf2a2e9438a441a8d Mon Sep 17 00:00:00 2001
> From: Don Slutz <Don@CloudSwitch.com>
> Date: Fri, 22 Feb 2013 22:27:03 -0500
> Subject: [PATCH 1/2] Switch to use xc_kexec_get_range for 
> get_xen_vmcoreinfo.

Thanks.  I'll add this to my series.

David

> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
> ---
>   kexec/crashdump-xen.c |   20 ++++++++++++++++++++
>   kexec/crashdump.c     |    2 ++
>   2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
> index 56b0653..8179b72 100644
> --- a/kexec/crashdump-xen.c
> +++ b/kexec/crashdump-xen.c
> @@ -161,6 +161,26 @@ unsigned long xen_architecture(struct 
> crash_elf_info *elf_info)
>   }
> 
>   #ifdef HAVE_LIBXENCTRL
> +int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
> +{
> +       xc_interface *xc;
> +        int ret = 0;
> +
> +       xc = xc_interface_open(NULL, NULL, 0);
> +       if ( !xc ) {
> +               fprintf(stderr, "failed to open xen control interface.\n");
> +               return -1;
> +       }
> +
> +        ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, 0, len, 
> addr);
> +
> +       xc_interface_close(xc);
> +
> +        if (ret < 0)
> +            return -1;
> +        return 0;
> +}
> +
>   int xen_get_nr_phys_cpus(void)
>   {
>          xc_interface *xc;
> diff --git a/kexec/crashdump.c b/kexec/crashdump.c
> index 847d080..3d2c1b9 100644
> --- a/kexec/crashdump.c
> +++ b/kexec/crashdump.c
> @@ -142,7 +142,9 @@ int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
>          return get_vmcoreinfo("/sys/kernel/vmcoreinfo", addr, len);
>   }
> 
> +#ifndef HAVE_LIBXENCTRL
>   int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
>   {
>          return get_vmcoreinfo("/sys/hypervisor/vmcoreinfo", addr, len);
>   }
> +#endif


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:34:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19: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 1UA3oh-0005iR-LV; Mon, 25 Feb 2013 19:34: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 1UA3og-0005iM-Br
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:34:26 +0000
Received: from [193.109.254.147:62806] by server-15.bemta-14.messagelabs.com
	id A9/E0-24599-1CCBB215; Mon, 25 Feb 2013 19:34:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361820862!1938227!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22861 invoked from network); 25 Feb 2013 19:34:24 -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;
	25 Feb 2013 19:34:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="9474469"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 19:34:22 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 14:34:21 -0500
Message-ID: <512BBCBC.8050404@citrix.com>
Date: Mon, 25 Feb 2013 19:34:20 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Don Slutz <Don@CloudSwitch.Com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
	<512BAEB3.4010708@CloudSwitch.Com>
In-Reply-To: <512BAEB3.4010708@CloudSwitch.Com>
X-Originating-IP: [10.80.2.76]
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.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

On 25/02/13 18:34, Don Slutz wrote:
> 
> I did not find a fix/change to get_xen_vmcoreinfo() to call on 
> xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, ...
> 
> I found the following to work.
>     -Don Slutz
> 
>  From 2cabc018d7613b0d2ac487cbf2a2e9438a441a8d Mon Sep 17 00:00:00 2001
> From: Don Slutz <Don@CloudSwitch.com>
> Date: Fri, 22 Feb 2013 22:27:03 -0500
> Subject: [PATCH 1/2] Switch to use xc_kexec_get_range for 
> get_xen_vmcoreinfo.

Thanks.  I'll add this to my series.

David

> Signed-off-by: Don Slutz <Don@CloudSwitch.com>
> ---
>   kexec/crashdump-xen.c |   20 ++++++++++++++++++++
>   kexec/crashdump.c     |    2 ++
>   2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
> index 56b0653..8179b72 100644
> --- a/kexec/crashdump-xen.c
> +++ b/kexec/crashdump-xen.c
> @@ -161,6 +161,26 @@ unsigned long xen_architecture(struct 
> crash_elf_info *elf_info)
>   }
> 
>   #ifdef HAVE_LIBXENCTRL
> +int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
> +{
> +       xc_interface *xc;
> +        int ret = 0;
> +
> +       xc = xc_interface_open(NULL, NULL, 0);
> +       if ( !xc ) {
> +               fprintf(stderr, "failed to open xen control interface.\n");
> +               return -1;
> +       }
> +
> +        ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_VMCOREINFO, 0, len, 
> addr);
> +
> +       xc_interface_close(xc);
> +
> +        if (ret < 0)
> +            return -1;
> +        return 0;
> +}
> +
>   int xen_get_nr_phys_cpus(void)
>   {
>          xc_interface *xc;
> diff --git a/kexec/crashdump.c b/kexec/crashdump.c
> index 847d080..3d2c1b9 100644
> --- a/kexec/crashdump.c
> +++ b/kexec/crashdump.c
> @@ -142,7 +142,9 @@ int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
>          return get_vmcoreinfo("/sys/kernel/vmcoreinfo", addr, len);
>   }
> 
> +#ifndef HAVE_LIBXENCTRL
>   int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len)
>   {
>          return get_vmcoreinfo("/sys/hypervisor/vmcoreinfo", addr, len);
>   }
> +#endif


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:40:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:40: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 1UA3uZ-0005rF-Fz; Mon, 25 Feb 2013 19:40:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UA3uX-0005r7-7A
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:40:29 +0000
Received: from [193.109.254.147:57713] by server-9.bemta-14.messagelabs.com id
	06/21-30867-C2EBB215; Mon, 25 Feb 2013 19:40:28 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361821227!1938715!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11579 invoked from network); 25 Feb 2013 19:40:27 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-27.messagelabs.com with SMTP;
	25 Feb 2013 19:40:27 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 63263C56194;
	Mon, 25 Feb 2013 19:40:16 +0000 (GMT)
Date: Mon, 25 Feb 2013 19:40:15 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <676025980A510BB081BC128B@Ximines.local>
In-Reply-To: <20130225131248.GA78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 25 February 2013 13:12:48 +0000 Tim Deegan <tim@xen.org> wrote:

> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> Debian/Ubuntu.  That would be much more widely useful, for a similar
> amount of effort.

When I first did this, there were no Xen4.2 packages. Now both Ubuntu
raring and Debian Experimental have them.

However, that isn't the end of the story. If you want a lightweight
deb that doesn't take 39 years to build and is integrated into the
build system (because you are a developer), the minideb thing is
far easier (as it's just an extra make step), than debuild -us -uc -b,
dealing with all the debian/ubuntu patches that get applied to the
source, etc. etc.

The other point is that debian/ubuntu are ALWAYS going to be behind
unstable, so if you want an unstable set of packages (meaning
'means to install your developed code on a box that you
aren't compiling on), well, tough. We had this difficulty
when 4.2 *was* unstable - I wrote the minideb stuff precisely because
I couldn't get Ubuntu's 4.1/4.0 packaging to do sensible things.
And at the time Debian's "4.2" package did not appear to bear a
meaningful relationship to any source tree I could find. That's
not a criticism of either maintainer - I just wanted to make a
package from Unstable that worked.

Further, as Sylvain Munuat pointed out, the debian/ubuntu (certainly
ubuntu) packages are often incomplete. In 4.1 Ubuntu, various libraries
were missing, for instance. They are targeted at the user who wants
support from their distro, as opposed to the developer who is trying
to find an easy way to install a copy of xen he's developed.

On the other hand I can see the 'thin end of the wedge' argument.
Perhaps in the 'make deb' makefile (and the 'make minideb' thing
if you take that in) it should say in capital letters with asterisks
that this is a development package and no substitute for a distribution
install.

I'm not trying to displace proper debian/ubuntu packaging here. And
it's no skin off my nose either way really as we compile our own
stuff anyway so pulling it a changeset is not a huge amount of work.
I just thought it might be useful!

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:40:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:40: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 1UA3uZ-0005rF-Fz; Mon, 25 Feb 2013 19:40:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UA3uX-0005r7-7A
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:40:29 +0000
Received: from [193.109.254.147:57713] by server-9.bemta-14.messagelabs.com id
	06/21-30867-C2EBB215; Mon, 25 Feb 2013 19:40:28 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361821227!1938715!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11579 invoked from network); 25 Feb 2013 19:40:27 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-27.messagelabs.com with SMTP;
	25 Feb 2013 19:40:27 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 63263C56194;
	Mon, 25 Feb 2013 19:40:16 +0000 (GMT)
Date: Mon, 25 Feb 2013 19:40:15 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <676025980A510BB081BC128B@Ximines.local>
In-Reply-To: <20130225131248.GA78606@ocelot.phlegethon.org>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 25 February 2013 13:12:48 +0000 Tim Deegan <tim@xen.org> wrote:

> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
> Debian/Ubuntu.  That would be much more widely useful, for a similar
> amount of effort.

When I first did this, there were no Xen4.2 packages. Now both Ubuntu
raring and Debian Experimental have them.

However, that isn't the end of the story. If you want a lightweight
deb that doesn't take 39 years to build and is integrated into the
build system (because you are a developer), the minideb thing is
far easier (as it's just an extra make step), than debuild -us -uc -b,
dealing with all the debian/ubuntu patches that get applied to the
source, etc. etc.

The other point is that debian/ubuntu are ALWAYS going to be behind
unstable, so if you want an unstable set of packages (meaning
'means to install your developed code on a box that you
aren't compiling on), well, tough. We had this difficulty
when 4.2 *was* unstable - I wrote the minideb stuff precisely because
I couldn't get Ubuntu's 4.1/4.0 packaging to do sensible things.
And at the time Debian's "4.2" package did not appear to bear a
meaningful relationship to any source tree I could find. That's
not a criticism of either maintainer - I just wanted to make a
package from Unstable that worked.

Further, as Sylvain Munuat pointed out, the debian/ubuntu (certainly
ubuntu) packages are often incomplete. In 4.1 Ubuntu, various libraries
were missing, for instance. They are targeted at the user who wants
support from their distro, as opposed to the developer who is trying
to find an easy way to install a copy of xen he's developed.

On the other hand I can see the 'thin end of the wedge' argument.
Perhaps in the 'make deb' makefile (and the 'make minideb' thing
if you take that in) it should say in capital letters with asterisks
that this is a development package and no substitute for a distribution
install.

I'm not trying to displace proper debian/ubuntu packaging here. And
it's no skin off my nose either way really as we compile our own
stuff anyway so pulling it a changeset is not a huge amount of work.
I just thought it might be useful!

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:52:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:52: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 1UA45j-0006Hz-1z; Mon, 25 Feb 2013 19:52:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UA45g-0006H3-G9
	for Xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:52:00 +0000
Received: from [85.158.137.99:11905] by server-14.bemta-3.messagelabs.com id
	44/E4-23533-FD0CB215; Mon, 25 Feb 2013 19:51:59 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361821919!12895229!1
X-Originating-IP: [74.125.82.181]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27815 invoked from network); 25 Feb 2013 19:51:59 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 19:51:59 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so2794263wey.12
	for <Xen-devel@lists.xen.org>; Mon, 25 Feb 2013 11:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=zS7hk9iWQK9lBJ++ZOPjSYCHVOLfd5EE/POWEON3SrE=;
	b=l/EKIN7oZuxZ+IiXVf39R4jOpFXYfPd13KHz7M3VSeRAEnVYRwxbbS5QVpvuc1Sv4j
	CuCYlS1Z19MfRaHBdlIaDgkqY+owXPzzKeiameU0unPX5DVLfAyEmDVtZ2FKYap+CAvq
	00wu2wV3xNMwl9cK2uyLspxu046ljLIuc2IiKd9s7ZZUDaoKkGqSBOtKRDgEXikFDEPm
	ZK1pCjsODakF3roo4xOK6Iho9dMr3XjSAYpDUWguFnHKWUm+CRTAqzRbH3bZpt/nKANv
	4bEjgLwgKh75Hq89H+OdEnuvx9lAFboBIQRzSTyqSnOpOf0TK1w+kpJ7Yfv0SBJRBCFl
	8uEg==
MIME-Version: 1.0
X-Received: by 10.180.73.238 with SMTP id o14mr14543149wiv.32.1361821918977;
	Mon, 25 Feb 2013 11:51:58 -0800 (PST)
Received: by 10.216.94.74 with HTTP; Mon, 25 Feb 2013 11:51:58 -0800 (PST)
Date: Mon, 25 Feb 2013 11:51:58 -0800
Message-ID: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] When does Xen build 1:1 direct mapping of all physical
	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: multipart/mixed; boundary="===============3331669300957541520=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3331669300957541520==
Content-Type: multipart/alternative; boundary=f46d043c80daba602f04d691df88

--f46d043c80daba602f04d691df88
Content-Type: text/plain; charset=ISO-8859-1

Hi, all,
I assumed that Xen fills up the page table entires for 1:1 direct mapping
of all physical memory at start time, but I cannot find the code. Could
anyone tell me when Xen builds up pte for this mapping ?
Thanks,
-- 
Xinxin

--f46d043c80daba602f04d691df88
Content-Type: text/html; charset=ISO-8859-1

Hi, all,<div>I assumed that Xen fills up the page table entires for 1:1 direct mapping of all physical memory at start time, but I cannot find the code. Could anyone tell me when Xen builds up pte for this mapping ?<br clear="all">
<div>Thanks,</div>-- <br>Xinxin

</div>

--f46d043c80daba602f04d691df88--


--===============3331669300957541520==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3331669300957541520==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 19:52:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:52: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 1UA45j-0006Hz-1z; Mon, 25 Feb 2013 19:52:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UA45g-0006H3-G9
	for Xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:52:00 +0000
Received: from [85.158.137.99:11905] by server-14.bemta-3.messagelabs.com id
	44/E4-23533-FD0CB215; Mon, 25 Feb 2013 19:51:59 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361821919!12895229!1
X-Originating-IP: [74.125.82.181]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27815 invoked from network); 25 Feb 2013 19:51:59 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 19:51:59 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so2794263wey.12
	for <Xen-devel@lists.xen.org>; Mon, 25 Feb 2013 11:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=zS7hk9iWQK9lBJ++ZOPjSYCHVOLfd5EE/POWEON3SrE=;
	b=l/EKIN7oZuxZ+IiXVf39R4jOpFXYfPd13KHz7M3VSeRAEnVYRwxbbS5QVpvuc1Sv4j
	CuCYlS1Z19MfRaHBdlIaDgkqY+owXPzzKeiameU0unPX5DVLfAyEmDVtZ2FKYap+CAvq
	00wu2wV3xNMwl9cK2uyLspxu046ljLIuc2IiKd9s7ZZUDaoKkGqSBOtKRDgEXikFDEPm
	ZK1pCjsODakF3roo4xOK6Iho9dMr3XjSAYpDUWguFnHKWUm+CRTAqzRbH3bZpt/nKANv
	4bEjgLwgKh75Hq89H+OdEnuvx9lAFboBIQRzSTyqSnOpOf0TK1w+kpJ7Yfv0SBJRBCFl
	8uEg==
MIME-Version: 1.0
X-Received: by 10.180.73.238 with SMTP id o14mr14543149wiv.32.1361821918977;
	Mon, 25 Feb 2013 11:51:58 -0800 (PST)
Received: by 10.216.94.74 with HTTP; Mon, 25 Feb 2013 11:51:58 -0800 (PST)
Date: Mon, 25 Feb 2013 11:51:58 -0800
Message-ID: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] When does Xen build 1:1 direct mapping of all physical
	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: multipart/mixed; boundary="===============3331669300957541520=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3331669300957541520==
Content-Type: multipart/alternative; boundary=f46d043c80daba602f04d691df88

--f46d043c80daba602f04d691df88
Content-Type: text/plain; charset=ISO-8859-1

Hi, all,
I assumed that Xen fills up the page table entires for 1:1 direct mapping
of all physical memory at start time, but I cannot find the code. Could
anyone tell me when Xen builds up pte for this mapping ?
Thanks,
-- 
Xinxin

--f46d043c80daba602f04d691df88
Content-Type: text/html; charset=ISO-8859-1

Hi, all,<div>I assumed that Xen fills up the page table entires for 1:1 direct mapping of all physical memory at start time, but I cannot find the code. Could anyone tell me when Xen builds up pte for this mapping ?<br clear="all">
<div>Thanks,</div>-- <br>Xinxin

</div>

--f46d043c80daba602f04d691df88--


--===============3331669300957541520==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3331669300957541520==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 19:59:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:59: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 1UA4CW-0006cQ-0C; Mon, 25 Feb 2013 19:59:04 +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 1UA4CT-0006cJ-7V
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:59:01 +0000
Received: from [85.158.143.99:14690] by server-2.bemta-4.messagelabs.com id
	7C/41-12656-482CB215; Mon, 25 Feb 2013 19:59:00 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361822339!22129906!1
X-Originating-IP: [74.125.83.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20356 invoked from network); 25 Feb 2013 19:58:59 -0000
Received: from mail-ee0-f50.google.com (HELO mail-ee0-f50.google.com)
	(74.125.83.50)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 19:58:59 -0000
Received: by mail-ee0-f50.google.com with SMTP id e51so1701226eek.9
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 11:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=pPhVNUPfemWVyn+rJI5KMmEYnn4VGC8nY1x0/ND3AjQ=;
	b=TCXUxxEU1lrArKl/2rzJjiAEfLlEdx1u+iMh6corSG5fB5PKr71A4FEiPelDACVAs7
	Ia1u0PtJ/qIC1Li875sxPpgJzQYK9uTLz2vmPJuE+7aHF6YZ2XnZx1pEzorN4/gh9rtn
	lIvogm2C9fnZQ2M5KPVhC8AsOJr0G5tFVupHhYk80Yn6dQgt1HiTQTx21eJj7AZKj2dM
	WNEEnSvdfWGGyW1+RJVcukhC38DQUmbiIF6jBSR+7CVd7X8+XmkaM6K492C050F8rvaa
	rhSF/6xy3yYjVoFGV4En1ocPVW8pWdAcKr2GXct8EFg78eKhnLXrmIjwvSolxxqi6rdS
	twyQ==
MIME-Version: 1.0
X-Received: by 10.14.213.199 with SMTP id a47mr42275836eep.31.1361822339582;
	Mon, 25 Feb 2013 11:58:59 -0800 (PST)
Received: by 10.223.177.201 with HTTP; Mon, 25 Feb 2013 11:58:59 -0800 (PST)
In-Reply-To: <676025980A510BB081BC128B@Ximines.local>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
Date: Mon, 25 Feb 2013 11:58:59 -0800
Message-ID: <CAGU+auvcwUK=RmPybh-aPt+sZPJ_T--RKQB_VDevU1g5AzwMog@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 11:40 AM, Alex Bligh <alex@alex.org.uk> wrote:
>
>
> --On 25 February 2013 13:12:48 +0000 Tim Deegan <tim@xen.org> wrote:
>
>> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
>> Debian/Ubuntu.  That would be much more widely useful, for a similar
>> amount of effort.
>
>
> When I first did this, there were no Xen4.2 packages. Now both Ubuntu
> raring and Debian Experimental have them.
>
> However, that isn't the end of the story. If you want a lightweight
> deb that doesn't take 39 years to build and is integrated into the
> build system (because you are a developer), the minideb thing is
> far easier (as it's just an extra make step), than debuild -us -uc -b,
> dealing with all the debian/ubuntu patches that get applied to the
> source, etc. etc.
>
> The other point is that debian/ubuntu are ALWAYS going to be behind
> unstable, so if you want an unstable set of packages (meaning
> 'means to install your developed code on a box that you
> aren't compiling on), well, tough. We had this difficulty
> when 4.2 *was* unstable - I wrote the minideb stuff precisely because
> I couldn't get Ubuntu's 4.1/4.0 packaging to do sensible things.
> And at the time Debian's "4.2" package did not appear to bear a
> meaningful relationship to any source tree I could find. That's
> not a criticism of either maintainer - I just wanted to make a
> package from Unstable that worked.
>
> Further, as Sylvain Munuat pointed out, the debian/ubuntu (certainly
> ubuntu) packages are often incomplete. In 4.1 Ubuntu, various libraries
> were missing, for instance. They are targeted at the user who wants
> support from their distro, as opposed to the developer who is trying
> to find an easy way to install a copy of xen he's developed.
>
> On the other hand I can see the 'thin end of the wedge' argument.
> Perhaps in the 'make deb' makefile (and the 'make minideb' thing
> if you take that in) it should say in capital letters with asterisks
> that this is a development package and no substitute for a distribution
> install.
>
> I'm not trying to displace proper debian/ubuntu packaging here. And
> it's no skin off my nose either way really as we compile our own
> stuff anyway so pulling it a changeset is not a huge amount of work.
> I just thought it might be useful!

+1

I am in a similar situation as I want some of the patches from upstream.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 19:59:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 19:59: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 1UA4CW-0006cQ-0C; Mon, 25 Feb 2013 19:59:04 +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 1UA4CT-0006cJ-7V
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 19:59:01 +0000
Received: from [85.158.143.99:14690] by server-2.bemta-4.messagelabs.com id
	7C/41-12656-482CB215; Mon, 25 Feb 2013 19:59:00 +0000
X-Env-Sender: apxeng@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361822339!22129906!1
X-Originating-IP: [74.125.83.50]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20356 invoked from network); 25 Feb 2013 19:58:59 -0000
Received: from mail-ee0-f50.google.com (HELO mail-ee0-f50.google.com)
	(74.125.83.50)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 19:58:59 -0000
Received: by mail-ee0-f50.google.com with SMTP id e51so1701226eek.9
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 11:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=pPhVNUPfemWVyn+rJI5KMmEYnn4VGC8nY1x0/ND3AjQ=;
	b=TCXUxxEU1lrArKl/2rzJjiAEfLlEdx1u+iMh6corSG5fB5PKr71A4FEiPelDACVAs7
	Ia1u0PtJ/qIC1Li875sxPpgJzQYK9uTLz2vmPJuE+7aHF6YZ2XnZx1pEzorN4/gh9rtn
	lIvogm2C9fnZQ2M5KPVhC8AsOJr0G5tFVupHhYk80Yn6dQgt1HiTQTx21eJj7AZKj2dM
	WNEEnSvdfWGGyW1+RJVcukhC38DQUmbiIF6jBSR+7CVd7X8+XmkaM6K492C050F8rvaa
	rhSF/6xy3yYjVoFGV4En1ocPVW8pWdAcKr2GXct8EFg78eKhnLXrmIjwvSolxxqi6rdS
	twyQ==
MIME-Version: 1.0
X-Received: by 10.14.213.199 with SMTP id a47mr42275836eep.31.1361822339582;
	Mon, 25 Feb 2013 11:58:59 -0800 (PST)
Received: by 10.223.177.201 with HTTP; Mon, 25 Feb 2013 11:58:59 -0800 (PST)
In-Reply-To: <676025980A510BB081BC128B@Ximines.local>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
Date: Mon, 25 Feb 2013 11:58:59 -0800
Message-ID: <CAGU+auvcwUK=RmPybh-aPt+sZPJ_T--RKQB_VDevU1g5AzwMog@mail.gmail.com>
From: AP <apxeng@gmail.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 11:40 AM, Alex Bligh <alex@alex.org.uk> wrote:
>
>
> --On 25 February 2013 13:12:48 +0000 Tim Deegan <tim@xen.org> wrote:
>
>> Hrmn.  AFAICT what's really wanted here is a set of Xen 4.2 packages for
>> Debian/Ubuntu.  That would be much more widely useful, for a similar
>> amount of effort.
>
>
> When I first did this, there were no Xen4.2 packages. Now both Ubuntu
> raring and Debian Experimental have them.
>
> However, that isn't the end of the story. If you want a lightweight
> deb that doesn't take 39 years to build and is integrated into the
> build system (because you are a developer), the minideb thing is
> far easier (as it's just an extra make step), than debuild -us -uc -b,
> dealing with all the debian/ubuntu patches that get applied to the
> source, etc. etc.
>
> The other point is that debian/ubuntu are ALWAYS going to be behind
> unstable, so if you want an unstable set of packages (meaning
> 'means to install your developed code on a box that you
> aren't compiling on), well, tough. We had this difficulty
> when 4.2 *was* unstable - I wrote the minideb stuff precisely because
> I couldn't get Ubuntu's 4.1/4.0 packaging to do sensible things.
> And at the time Debian's "4.2" package did not appear to bear a
> meaningful relationship to any source tree I could find. That's
> not a criticism of either maintainer - I just wanted to make a
> package from Unstable that worked.
>
> Further, as Sylvain Munuat pointed out, the debian/ubuntu (certainly
> ubuntu) packages are often incomplete. In 4.1 Ubuntu, various libraries
> were missing, for instance. They are targeted at the user who wants
> support from their distro, as opposed to the developer who is trying
> to find an easy way to install a copy of xen he's developed.
>
> On the other hand I can see the 'thin end of the wedge' argument.
> Perhaps in the 'make deb' makefile (and the 'make minideb' thing
> if you take that in) it should say in capital letters with asterisks
> that this is a development package and no substitute for a distribution
> install.
>
> I'm not trying to displace proper debian/ubuntu packaging here. And
> it's no skin off my nose either way really as we compile our own
> stuff anyway so pulling it a changeset is not a huge amount of work.
> I just thought it might be useful!

+1

I am in a similar situation as I want some of the patches from upstream.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 20:16:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20:16: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 1UA4Sa-0007HI-LB; Mon, 25 Feb 2013 20:15: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 1UA4SZ-0007HD-C1
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 20:15:39 +0000
Received: from [85.158.143.99:12042] by server-1.bemta-4.messagelabs.com id
	C7/3A-06203-A66CB215; Mon, 25 Feb 2013 20:15:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361823336!23896712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26097 invoked from network); 25 Feb 2013 20:15:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 20:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="9484184"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 20:14:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 15:14:35 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA4RX-0007Px-Jy;
	Mon, 25 Feb 2013 20:14:35 +0000
Date: Mon, 25 Feb 2013 20:14:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <676025980A510BB081BC128B@Ximines.local>
Message-ID: <alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Alex Bligh wrote:
> However, that isn't the end of the story. If you want a lightweight
> deb that doesn't take 39 years to build and is integrated into the
> build system (because you are a developer), the minideb thing is
> far easier (as it's just an extra make step), than debuild -us -uc -b,
> dealing with all the debian/ubuntu patches that get applied to the
> source, etc. etc.

That's all good, but how does it compare to the deb target of the
xen-unstable build system?

I think we are not going to have two different deb build targets, so
given that we already have one, we would replace it only if your minideb
is better in some ways.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 20:16:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20:16: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 1UA4Sa-0007HI-LB; Mon, 25 Feb 2013 20:15: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 1UA4SZ-0007HD-C1
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 20:15:39 +0000
Received: from [85.158.143.99:12042] by server-1.bemta-4.messagelabs.com id
	C7/3A-06203-A66CB215; Mon, 25 Feb 2013 20:15:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361823336!23896712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEwNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26097 invoked from network); 25 Feb 2013 20:15:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 20:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="9484184"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	25 Feb 2013 20:14:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 25 Feb 2013 15:14:35 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UA4RX-0007Px-Jy;
	Mon, 25 Feb 2013 20:14:35 +0000
Date: Mon, 25 Feb 2013 20:14:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <676025980A510BB081BC128B@Ximines.local>
Message-ID: <alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Alex Bligh wrote:
> However, that isn't the end of the story. If you want a lightweight
> deb that doesn't take 39 years to build and is integrated into the
> build system (because you are a developer), the minideb thing is
> far easier (as it's just an extra make step), than debuild -us -uc -b,
> dealing with all the debian/ubuntu patches that get applied to the
> source, etc. etc.

That's all good, but how does it compare to the deb target of the
xen-unstable build system?

I think we are not going to have two different deb build targets, so
given that we already have one, we would replace it only if your minideb
is better in some ways.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 20:42:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20: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 1UA4rq-0007uD-1m; Mon, 25 Feb 2013 20:41:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UA4ro-0007u6-LG
	for Xen-devel@lists.xen.org; Mon, 25 Feb 2013 20:41:44 +0000
Received: from [193.109.254.147:43017] by server-5.bemta-14.messagelabs.com id
	88/61-21539-88CCB215; Mon, 25 Feb 2013 20:41:44 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361824901!4042703!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_00_10, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25731 invoked from network); 25 Feb 2013 20:41:41 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 20:41:41 -0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so3774234wid.6
	for <Xen-devel@lists.xen.org>; Mon, 25 Feb 2013 12:41:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=KUR/ohBxG/5nZJWoBnu3gl8BZyPpZLtCguw40QPcWeE=;
	b=cecJBViRBrns2DDCi/QzEI/yf++UGS9UXNcKr4FCkoZi0QqDfcM6Uy1kilWR3s9OmJ
	ICCDD6cT1vhZcBs8vLOThcId+8LGLq32q3oQFLEphuQtVFkCjZvGgUVVOHNwzaMs7VoW
	DtmWkzKYGRwP+4UQxerzAyZOIe15/WWLp2PqEGNg44Q3HQRJhwbY09DgmBynHV4ilmwM
	fDlnHRn003mrXkqrzH0wsRGyAMoH57qwMCTMqzjYJhoBEB7IvEMv7PpVecO1AOMmkIVV
	q/zOvRiPVZ3BkuJsHIZ0KzdXXEpqpqfr+HtMPlvJ/IcKBi034iWQd/TxhAOUn2g9gFqQ
	VX3g==
MIME-Version: 1.0
X-Received: by 10.180.14.233 with SMTP id s9mr14914417wic.25.1361824900973;
	Mon, 25 Feb 2013 12:41:40 -0800 (PST)
Received: by 10.216.94.74 with HTTP; Mon, 25 Feb 2013 12:41:40 -0800 (PST)
Date: Mon, 25 Feb 2013 12:41:40 -0800
Message-ID: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] The different between map_pages_to_xen and mfn_to_virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5209199629976252403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5209199629976252403==
Content-Type: multipart/alternative; boundary=f46d040fa03c78067a04d69291e5

--f46d040fa03c78067a04d69291e5
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I have some confusion about the purpose of the two functions.
map_pages_to_xen is to map machine page range in Xen virtual address space.
mfn_to_virt() is to convert between machine frame number and xen-heap
virtual address. So what is the difference? When I need to map some machine
pages to Xen space, which function should I use? Thanks,
-- 
Xinxin

--f46d040fa03c78067a04d69291e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I have some confusion about the purpose of the two functions. m=
ap_pages_to_xen is to map machine page range in Xen virtual address space. =
mfn_to_virt() is to convert between machine frame number and xen-heap virtu=
al address. So what is the difference? When I need to map some machine page=
s to Xen space, which function should I use? Thanks,=A0<br>
-- <br>Xinxin

</div>

--f46d040fa03c78067a04d69291e5--


--===============5209199629976252403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5209199629976252403==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 20:42:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20: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 1UA4rq-0007uD-1m; Mon, 25 Feb 2013 20:41:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UA4ro-0007u6-LG
	for Xen-devel@lists.xen.org; Mon, 25 Feb 2013 20:41:44 +0000
Received: from [193.109.254.147:43017] by server-5.bemta-14.messagelabs.com id
	88/61-21539-88CCB215; Mon, 25 Feb 2013 20:41:44 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361824901!4042703!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_00_10, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25731 invoked from network); 25 Feb 2013 20:41:41 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 20:41:41 -0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so3774234wid.6
	for <Xen-devel@lists.xen.org>; Mon, 25 Feb 2013 12:41:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=KUR/ohBxG/5nZJWoBnu3gl8BZyPpZLtCguw40QPcWeE=;
	b=cecJBViRBrns2DDCi/QzEI/yf++UGS9UXNcKr4FCkoZi0QqDfcM6Uy1kilWR3s9OmJ
	ICCDD6cT1vhZcBs8vLOThcId+8LGLq32q3oQFLEphuQtVFkCjZvGgUVVOHNwzaMs7VoW
	DtmWkzKYGRwP+4UQxerzAyZOIe15/WWLp2PqEGNg44Q3HQRJhwbY09DgmBynHV4ilmwM
	fDlnHRn003mrXkqrzH0wsRGyAMoH57qwMCTMqzjYJhoBEB7IvEMv7PpVecO1AOMmkIVV
	q/zOvRiPVZ3BkuJsHIZ0KzdXXEpqpqfr+HtMPlvJ/IcKBi034iWQd/TxhAOUn2g9gFqQ
	VX3g==
MIME-Version: 1.0
X-Received: by 10.180.14.233 with SMTP id s9mr14914417wic.25.1361824900973;
	Mon, 25 Feb 2013 12:41:40 -0800 (PST)
Received: by 10.216.94.74 with HTTP; Mon, 25 Feb 2013 12:41:40 -0800 (PST)
Date: Mon, 25 Feb 2013 12:41:40 -0800
Message-ID: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] The different between map_pages_to_xen and mfn_to_virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5209199629976252403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5209199629976252403==
Content-Type: multipart/alternative; boundary=f46d040fa03c78067a04d69291e5

--f46d040fa03c78067a04d69291e5
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I have some confusion about the purpose of the two functions.
map_pages_to_xen is to map machine page range in Xen virtual address space.
mfn_to_virt() is to convert between machine frame number and xen-heap
virtual address. So what is the difference? When I need to map some machine
pages to Xen space, which function should I use? Thanks,
-- 
Xinxin

--f46d040fa03c78067a04d69291e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>I have some confusion about the purpose of the two functions. m=
ap_pages_to_xen is to map machine page range in Xen virtual address space. =
mfn_to_virt() is to convert between machine frame number and xen-heap virtu=
al address. So what is the difference? When I need to map some machine page=
s to Xen space, which function should I use? Thanks,=A0<br>
-- <br>Xinxin

</div>

--f46d040fa03c78067a04d69291e5--


--===============5209199629976252403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5209199629976252403==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 20:46:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20:46: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 1UA4wK-0008Ed-TC; Mon, 25 Feb 2013 20:46:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UA4wJ-0008EW-7E
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 20:46:23 +0000
Received: from [85.158.143.99:51729] by server-1.bemta-4.messagelabs.com id
	19/95-06203-E9DCB215; Mon, 25 Feb 2013 20:46:22 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361825181!22328370!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 763 invoked from network); 25 Feb 2013 20:46:22 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-216.messagelabs.com with SMTP;
	25 Feb 2013 20:46:22 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 0C809C56194;
	Mon, 25 Feb 2013 20:46:10 +0000 (GMT)
Date: Mon, 25 Feb 2013 20:46:09 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <65A5A13AA7E2781D12DC1DA0@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
	<alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 25 February 2013 20:14:33 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 25 Feb 2013, Alex Bligh wrote:
>> However, that isn't the end of the story. If you want a lightweight
>> deb that doesn't take 39 years to build and is integrated into the
>> build system (because you are a developer), the minideb thing is
>> far easier (as it's just an extra make step), than debuild -us -uc -b,
>> dealing with all the debian/ubuntu patches that get applied to the
>> source, etc. etc.
>
> That's all good, but how does it compare to the deb target of the
> xen-unstable build system?

How does the minideb thing compare? It's exactly the same, except:

* it misses the files that aren't needed for a minimal xl based install.
  So, for instance, no header files.

* I made the init scripts do something useful (arguably this change
  should be brought over to the main debian target).

>From memory I copied mkdeb:

https://github.com/abligh/xen-4.2-live-migrate/blob/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74/tools/misc/mkdeb

and made this:

https://github.com/abligh/xen-4.2-live-migrate/blob/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74/minideb/mkdeb

> I think we are not going to have two different deb build targets, so
> given that we already have one, we would replace it only if your minideb
> is better in some ways.

Well, the init scripts work (though those could be copied across).
I suppose given they are so similar one route would be a 'what would
you like in your .deb' parameter (e.g. 'make deb SRC=0')

As I said, I'm really not that fussed as it 'works for me'.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 20:46:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20:46: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 1UA4wK-0008Ed-TC; Mon, 25 Feb 2013 20:46:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UA4wJ-0008EW-7E
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 20:46:23 +0000
Received: from [85.158.143.99:51729] by server-1.bemta-4.messagelabs.com id
	19/95-06203-E9DCB215; Mon, 25 Feb 2013 20:46:22 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361825181!22328370!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 763 invoked from network); 25 Feb 2013 20:46:22 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-216.messagelabs.com with SMTP;
	25 Feb 2013 20:46:22 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 0C809C56194;
	Mon, 25 Feb 2013 20:46:10 +0000 (GMT)
Date: Mon, 25 Feb 2013 20:46:09 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <65A5A13AA7E2781D12DC1DA0@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
	<alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 25 February 2013 20:14:33 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 25 Feb 2013, Alex Bligh wrote:
>> However, that isn't the end of the story. If you want a lightweight
>> deb that doesn't take 39 years to build and is integrated into the
>> build system (because you are a developer), the minideb thing is
>> far easier (as it's just an extra make step), than debuild -us -uc -b,
>> dealing with all the debian/ubuntu patches that get applied to the
>> source, etc. etc.
>
> That's all good, but how does it compare to the deb target of the
> xen-unstable build system?

How does the minideb thing compare? It's exactly the same, except:

* it misses the files that aren't needed for a minimal xl based install.
  So, for instance, no header files.

* I made the init scripts do something useful (arguably this change
  should be brought over to the main debian target).

>From memory I copied mkdeb:

https://github.com/abligh/xen-4.2-live-migrate/blob/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74/tools/misc/mkdeb

and made this:

https://github.com/abligh/xen-4.2-live-migrate/blob/ffbfc9394a74d0344be5982a5fed9aa9fa28ad74/minideb/mkdeb

> I think we are not going to have two different deb build targets, so
> given that we already have one, we would replace it only if your minideb
> is better in some ways.

Well, the init scripts work (though those could be copied across).
I suppose given they are so similar one route would be a 'what would
you like in your .deb' parameter (e.g. 'make deb SRC=0')

As I said, I'm really not that fussed as it 'works for me'.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 20:55:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20:55: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 1UA55K-0000Av-Uv; Mon, 25 Feb 2013 20:55:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>)
	id 1UA2ls-0001ya-1J; Mon, 25 Feb 2013 18:27:28 +0000
Received: from [193.109.254.147:52115] by server-2.bemta-14.messagelabs.com id
	52/E3-16277-F0DAB215; Mon, 25 Feb 2013 18:27:27 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361816845!2846180!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32314 invoked from network); 25 Feb 2013 18:27:25 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 18:27:25 -0000
Received: by mail-la0-f41.google.com with SMTP id fo12so3016878lab.28
	for <multiple recipients>; Mon, 25 Feb 2013 10:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=0/KKQuwkSTDaMUCbXz960Iev6E33gHckPTNTDE56nOw=;
	b=Qc0ewAPBBcUY4Ed6BEWzcZL5JkaSfKgJTF1WhMQKBapXR2Z5COYZXii9eNlEXjNq/6
	xFkRviaNJvvrU5ErL4LzAgyXLSnnaJd9Kx92/CkZQPC0a5L4wQodaVFjpCmrrmY3DO5q
	U+jsraiPbv4GykVlxY6kGqlS3CP9/DTpa4lNnD+i+R8Q+MC6bET53cFggo68IBHoTXtx
	Xhjfg/BTQg8Bo10DL/WAycmsEK+mVZtvW5lf4zQ0o9N5bobliorluSPtaL8jflJhq8PW
	iiiMAc6SI0qoL4yP0/s2bCesrUvfIiO9Li8jVAoV2nt+9ULuvF2jfzRMdXKMgyezv/Cn
	TTIg==
X-Received: by 10.152.125.239 with SMTP id mt15mr10803714lab.26.1361816844947; 
	Mon, 25 Feb 2013 10:27:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.22.198 with HTTP; Mon, 25 Feb 2013 10:26:43 -0800 (PST)
In-Reply-To: <1361786229.2109.15.camel@zion.uk.xensource.com>
References: <1361786229.2109.15.camel@zion.uk.xensource.com>
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 25 Feb 2013 10:26:43 -0800
Message-ID: <CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Mailman-Approved-At: Mon, 25 Feb 2013 20:55:41 +0000
Cc: xen-arm <xen-arm@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-api@lists.xen.org, Lars Kurth <lars.kurth@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6597134949379381719=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6597134949379381719==
Content-Type: multipart/alternative; boundary=f46d04426b664ad30904d690b195

--f46d04426b664ad30904d690b195
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 25, 2013 at 1:57 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> Hi all
>
> Just a quick reminder that today is Xen documentation day! Join us on
> freenode #xendocs to improve Xen documentation!
>
> *********************
> * Xen Document Days *
> *********************
>
> We have another Xen document day come up next Monday. Xen Document Days
> are for people who care about Xen Documentation and want to improve it.
> We introduced Documentation Days, because working on documentation in
> parallel with like minded-people, is just more fun than working alone!
> Everybody who can contribute is welcome to join!
>
> For a list of items that need work, check out the community maintained
> TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course,
> you can work on anything you like: the list just provides suggestions.
>
> How do I participate?
> =====================
>
> - Join us on IRC: freenode channel #xendocs
> - 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!
>
>
> Wei.
>

We have two Xen Document Days one week apart?


Grant McWilliams
http://grantmcwilliams.com/

Some people, when confronted with a problem, think "I know, I'll use
Windows."
Now they have two problems.

--f46d04426b664ad30904d690b195
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 1:57 AM, Wei Liu <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citrix.com</a>&gt;</s=
pan> wrote:<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">

Hi all<br>
<br>
Just a quick reminder that today is Xen documentation day! Join us on<br>
freenode #xendocs to improve Xen documentation!<br>
<br>
*********************<br>
* Xen Document Days *<br>
*********************<br>
<br>
We have another Xen document day come up next Monday. Xen Document Days<br>
are for people who care about Xen Documentation and want to improve it.<br>
We introduced Documentation Days, because working on documentation in<br>
parallel with like minded-people, is just more fun than working alone!<br>
Everybody who can contribute is welcome to join!<br>
<br>
For a list of items that need work, check out the community maintained<br>
TODO list (<a href=3D"http://wiki.xen.org/wiki/Xen_Document_Days/TODO" targ=
et=3D"_blank">http://wiki.xen.org/wiki/Xen_Document_Days/TODO</a>). Of cour=
se,<br>
you can work on anything you like: the list just provides suggestions.<br>
<br>
How do I participate?<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
- Join us on IRC: freenode channel #xendocs<br>
- Tell people what you intend to work on (to avoid doing something<br>
=C2=A0 somebody else is already working on)<br>
- Fix some documentation<br>
- Help others<br>
- And above all: have fun!<br>
<br>
<br>
Wei.<br></blockquote><div><br></div><div>We have two Xen Document Days one =
week apart?</div><div><br></div><div><br class=3D"Apple-interchange-newline=
">Grant McWilliams<br><a href=3D"http://grantmcwilliams.com/" target=3D"_bl=
ank">http://grantmcwilliams.com/</a><br>

<br>Some people, when confronted with a problem, think &quot;I know, I&#39;=
ll use Windows.&quot;=C2=A0<br>Now they have two problems.<br></div><div>=
=C2=A0</div></div>

--f46d04426b664ad30904d690b195--


--===============6597134949379381719==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6597134949379381719==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 20:55:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 20:55: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 1UA55K-0000Av-Uv; Mon, 25 Feb 2013 20:55:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>)
	id 1UA2ls-0001ya-1J; Mon, 25 Feb 2013 18:27:28 +0000
Received: from [193.109.254.147:52115] by server-2.bemta-14.messagelabs.com id
	52/E3-16277-F0DAB215; Mon, 25 Feb 2013 18:27:27 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1361816845!2846180!1
X-Originating-IP: [209.85.215.41]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32314 invoked from network); 25 Feb 2013 18:27:25 -0000
Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com)
	(209.85.215.41)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 18:27:25 -0000
Received: by mail-la0-f41.google.com with SMTP id fo12so3016878lab.28
	for <multiple recipients>; Mon, 25 Feb 2013 10:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=0/KKQuwkSTDaMUCbXz960Iev6E33gHckPTNTDE56nOw=;
	b=Qc0ewAPBBcUY4Ed6BEWzcZL5JkaSfKgJTF1WhMQKBapXR2Z5COYZXii9eNlEXjNq/6
	xFkRviaNJvvrU5ErL4LzAgyXLSnnaJd9Kx92/CkZQPC0a5L4wQodaVFjpCmrrmY3DO5q
	U+jsraiPbv4GykVlxY6kGqlS3CP9/DTpa4lNnD+i+R8Q+MC6bET53cFggo68IBHoTXtx
	Xhjfg/BTQg8Bo10DL/WAycmsEK+mVZtvW5lf4zQ0o9N5bobliorluSPtaL8jflJhq8PW
	iiiMAc6SI0qoL4yP0/s2bCesrUvfIiO9Li8jVAoV2nt+9ULuvF2jfzRMdXKMgyezv/Cn
	TTIg==
X-Received: by 10.152.125.239 with SMTP id mt15mr10803714lab.26.1361816844947; 
	Mon, 25 Feb 2013 10:27:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.22.198 with HTTP; Mon, 25 Feb 2013 10:26:43 -0800 (PST)
In-Reply-To: <1361786229.2109.15.camel@zion.uk.xensource.com>
References: <1361786229.2109.15.camel@zion.uk.xensource.com>
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 25 Feb 2013 10:26:43 -0800
Message-ID: <CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Mailman-Approved-At: Mon, 25 Feb 2013 20:55:41 +0000
Cc: xen-arm <xen-arm@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-api@lists.xen.org, Lars Kurth <lars.kurth@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [Xen-users] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============6597134949379381719=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6597134949379381719==
Content-Type: multipart/alternative; boundary=f46d04426b664ad30904d690b195

--f46d04426b664ad30904d690b195
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 25, 2013 at 1:57 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> Hi all
>
> Just a quick reminder that today is Xen documentation day! Join us on
> freenode #xendocs to improve Xen documentation!
>
> *********************
> * Xen Document Days *
> *********************
>
> We have another Xen document day come up next Monday. Xen Document Days
> are for people who care about Xen Documentation and want to improve it.
> We introduced Documentation Days, because working on documentation in
> parallel with like minded-people, is just more fun than working alone!
> Everybody who can contribute is welcome to join!
>
> For a list of items that need work, check out the community maintained
> TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course,
> you can work on anything you like: the list just provides suggestions.
>
> How do I participate?
> =====================
>
> - Join us on IRC: freenode channel #xendocs
> - 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!
>
>
> Wei.
>

We have two Xen Document Days one week apart?


Grant McWilliams
http://grantmcwilliams.com/

Some people, when confronted with a problem, think "I know, I'll use
Windows."
Now they have two problems.

--f46d04426b664ad30904d690b195
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 1:57 AM, Wei Liu <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citrix.com</a>&gt;</s=
pan> wrote:<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">

Hi all<br>
<br>
Just a quick reminder that today is Xen documentation day! Join us on<br>
freenode #xendocs to improve Xen documentation!<br>
<br>
*********************<br>
* Xen Document Days *<br>
*********************<br>
<br>
We have another Xen document day come up next Monday. Xen Document Days<br>
are for people who care about Xen Documentation and want to improve it.<br>
We introduced Documentation Days, because working on documentation in<br>
parallel with like minded-people, is just more fun than working alone!<br>
Everybody who can contribute is welcome to join!<br>
<br>
For a list of items that need work, check out the community maintained<br>
TODO list (<a href=3D"http://wiki.xen.org/wiki/Xen_Document_Days/TODO" targ=
et=3D"_blank">http://wiki.xen.org/wiki/Xen_Document_Days/TODO</a>). Of cour=
se,<br>
you can work on anything you like: the list just provides suggestions.<br>
<br>
How do I participate?<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
- Join us on IRC: freenode channel #xendocs<br>
- Tell people what you intend to work on (to avoid doing something<br>
=C2=A0 somebody else is already working on)<br>
- Fix some documentation<br>
- Help others<br>
- And above all: have fun!<br>
<br>
<br>
Wei.<br></blockquote><div><br></div><div>We have two Xen Document Days one =
week apart?</div><div><br></div><div><br class=3D"Apple-interchange-newline=
">Grant McWilliams<br><a href=3D"http://grantmcwilliams.com/" target=3D"_bl=
ank">http://grantmcwilliams.com/</a><br>

<br>Some people, when confronted with a problem, think &quot;I know, I&#39;=
ll use Windows.&quot;=C2=A0<br>Now they have two problems.<br></div><div>=
=C2=A0</div></div>

--f46d04426b664ad30904d690b195--


--===============6597134949379381719==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6597134949379381719==--


From xen-devel-bounces@lists.xen.org Mon Feb 25 21:34:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 21:34: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 1UA5gH-0001Gv-F4; Mon, 25 Feb 2013 21:33:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Suravee.Suthikulpanit@amd.com>) id 1UA5gF-0001Gq-Mo
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 21:33:51 +0000
Received: from [85.158.139.211:8202] by server-12.bemta-5.messagelabs.com id
	4D/66-11486-EB8DB215; Mon, 25 Feb 2013 21:33:50 +0000
X-Env-Sender: Suravee.Suthikulpanit@amd.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361828029!18269898!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28784 invoked from network); 25 Feb 2013 21:33:50 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-8.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Feb 2013 21:33:50 -0000
Received: from mail28-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Feb 2013 21:33:48 +0000
Received: from mail28-va3 (localhost [127.0.0.1])	by mail28-va3-R.bigfish.com
	(Postfix) with ESMTP id 7B6283C019C;
	Mon, 25 Feb 2013 21:33:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h1155h)
Received: from mail28-va3 (localhost.localdomain [127.0.0.1]) by mail28-va3
	(MessageSwitch) id 1361828025979746_20475;
	Mon, 25 Feb 2013 21:33:45 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.239])	by
	mail28-va3.bigfish.com (Postfix) with ESMTP id E072B40087;
	Mon, 25 Feb 2013 21:33:45 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Feb 2013 21:33:45 +0000
X-WSS-ID: 0MISP86-02-A4C-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 2FC04C808C;	Mon, 25 Feb 2013 15:33:42 -0600 (CST)
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;
	Mon, 25 Feb 2013 15:33:50 -0600
Received: from [10.236.48.55] (10.236.48.55) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server id 14.2.328.9;
	Mon, 25 Feb 2013 15:33:43 -0600
Message-ID: <512BD8B7.9080303@amd.com>
Date: Mon, 25 Feb 2013 15:33:43 -0600
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E9A02000078000BED52@nat28.tlf.novell.com>
In-Reply-To: <511E6E9A02000078000BED52@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/4] IOMMU,
	AMD Family15h Model10-1Fh erratum 746 Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Jan,

This patch looks good.  I have tested on the system I have and it does 
what it's supposed to.  Thank you for porting the patch over from Linux.

Suravee

On 2/15/2013 10:21 AM, Jan Beulich wrote:
> The IOMMU may stop processing page translations due to a perceived lack
> of credits for writing upstream peripheral page service request (PPR)
> or event logs. If the L2B miscellaneous clock gating feature is enabled
> the IOMMU does not properly register credits after the log request has
> completed, leading to a potential system hang.
>
> BIOSes are supposed to disable L2B micellaneous clock gating by setting
> L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
> patch corrects that for those which do not enable this workaround.
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -792,6 +792,42 @@ static bool_t __init set_iommu_interrupt
>       return 1;
>   }
>   
> +/*
> + * Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translations)
> + * Workaround:
> + *     BIOS should disable L2B micellaneous clock gating by setting
> + *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b
> + */
> +static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu)
> +{
> +    u32 value;
> +    u8 bus = PCI_BUS(iommu->bdf);
> +    u8 dev = PCI_SLOT(iommu->bdf);
> +    u8 func = PCI_FUNC(iommu->bdf);
> +
> +    if ( (boot_cpu_data.x86 != 0x15) ||
> +         (boot_cpu_data.x86_model < 0x10) ||
> +         (boot_cpu_data.x86_model > 0x1f) )
> +        return;
> +
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
> +    value = pci_conf_read32(iommu->seg, bus, dev, func, 0xf4);
> +
> +    if ( value & (1 << 2) )
> +        return;
> +
> +    /* Select NB indirect register 0x90 and enable writing */
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90 | (1 << 8));
> +
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf4, value | (1 << 2));
> +    printk(XENLOG_INFO
> +           "AMD-Vi: Applying erratum 746 workaround for IOMMU at %04x:%02x:%02x.%u\n",
> +           iommu->seg, bus, dev, func);
> +
> +    /* Clear the enable writing bit */
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
> +}
> +
>   static void enable_iommu(struct amd_iommu *iommu)
>   {
>       unsigned long flags;
> @@ -805,6 +841,8 @@ static void enable_iommu(struct amd_iomm
>           return;
>       }
>   
> +    amd_iommu_erratum_746_workaround(iommu);
> +
>       register_iommu_dev_table_in_mmio_space(iommu);
>       register_iommu_cmd_buffer_in_mmio_space(iommu);
>       register_iommu_event_log_in_mmio_space(iommu);
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 21:34:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 21:34: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 1UA5gH-0001Gv-F4; Mon, 25 Feb 2013 21:33:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Suravee.Suthikulpanit@amd.com>) id 1UA5gF-0001Gq-Mo
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 21:33:51 +0000
Received: from [85.158.139.211:8202] by server-12.bemta-5.messagelabs.com id
	4D/66-11486-EB8DB215; Mon, 25 Feb 2013 21:33:50 +0000
X-Env-Sender: Suravee.Suthikulpanit@amd.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361828029!18269898!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28784 invoked from network); 25 Feb 2013 21:33:50 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-8.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Feb 2013 21:33:50 -0000
Received: from mail28-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Feb 2013 21:33:48 +0000
Received: from mail28-va3 (localhost [127.0.0.1])	by mail28-va3-R.bigfish.com
	(Postfix) with ESMTP id 7B6283C019C;
	Mon, 25 Feb 2013 21:33:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2dh668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h1155h)
Received: from mail28-va3 (localhost.localdomain [127.0.0.1]) by mail28-va3
	(MessageSwitch) id 1361828025979746_20475;
	Mon, 25 Feb 2013 21:33:45 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.239])	by
	mail28-va3.bigfish.com (Postfix) with ESMTP id E072B40087;
	Mon, 25 Feb 2013 21:33:45 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server id
	14.1.225.23; Mon, 25 Feb 2013 21:33:45 +0000
X-WSS-ID: 0MISP86-02-A4C-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 2FC04C808C;	Mon, 25 Feb 2013 15:33:42 -0600 (CST)
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;
	Mon, 25 Feb 2013 15:33:50 -0600
Received: from [10.236.48.55] (10.236.48.55) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server id 14.2.328.9;
	Mon, 25 Feb 2013 15:33:43 -0600
Message-ID: <512BD8B7.9080303@amd.com>
Date: Mon, 25 Feb 2013 15:33:43 -0600
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E9A02000078000BED52@nat28.tlf.novell.com>
In-Reply-To: <511E6E9A02000078000BED52@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3/4] IOMMU,
	AMD Family15h Model10-1Fh erratum 746 Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Jan,

This patch looks good.  I have tested on the system I have and it does 
what it's supposed to.  Thank you for porting the patch over from Linux.

Suravee

On 2/15/2013 10:21 AM, Jan Beulich wrote:
> The IOMMU may stop processing page translations due to a perceived lack
> of credits for writing upstream peripheral page service request (PPR)
> or event logs. If the L2B miscellaneous clock gating feature is enabled
> the IOMMU does not properly register credits after the log request has
> completed, leading to a potential system hang.
>
> BIOSes are supposed to disable L2B micellaneous clock gating by setting
> L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
> patch corrects that for those which do not enable this workaround.
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -792,6 +792,42 @@ static bool_t __init set_iommu_interrupt
>       return 1;
>   }
>   
> +/*
> + * Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translations)
> + * Workaround:
> + *     BIOS should disable L2B micellaneous clock gating by setting
> + *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b
> + */
> +static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu)
> +{
> +    u32 value;
> +    u8 bus = PCI_BUS(iommu->bdf);
> +    u8 dev = PCI_SLOT(iommu->bdf);
> +    u8 func = PCI_FUNC(iommu->bdf);
> +
> +    if ( (boot_cpu_data.x86 != 0x15) ||
> +         (boot_cpu_data.x86_model < 0x10) ||
> +         (boot_cpu_data.x86_model > 0x1f) )
> +        return;
> +
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
> +    value = pci_conf_read32(iommu->seg, bus, dev, func, 0xf4);
> +
> +    if ( value & (1 << 2) )
> +        return;
> +
> +    /* Select NB indirect register 0x90 and enable writing */
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90 | (1 << 8));
> +
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf4, value | (1 << 2));
> +    printk(XENLOG_INFO
> +           "AMD-Vi: Applying erratum 746 workaround for IOMMU at %04x:%02x:%02x.%u\n",
> +           iommu->seg, bus, dev, func);
> +
> +    /* Clear the enable writing bit */
> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
> +}
> +
>   static void enable_iommu(struct amd_iommu *iommu)
>   {
>       unsigned long flags;
> @@ -805,6 +841,8 @@ static void enable_iommu(struct amd_iomm
>           return;
>       }
>   
> +    amd_iommu_erratum_746_workaround(iommu);
> +
>       register_iommu_dev_table_in_mmio_space(iommu);
>       register_iommu_cmd_buffer_in_mmio_space(iommu);
>       register_iommu_event_log_in_mmio_space(iommu);
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 22:12:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 22:12: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 1UA6HB-0002Sh-LF; Mon, 25 Feb 2013 22:12: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 1UA6HA-0002SO-GZ
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 22:12:00 +0000
Received: from [85.158.137.99:15168] by server-1.bemta-3.messagelabs.com id
	5B/D5-08955-FA1EB215; Mon, 25 Feb 2013 22:11:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361830300!14754254!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20208 invoked from network); 25 Feb 2013 22:11:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 22:11:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="1863308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 22:11: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.297.1; Mon, 25 Feb 2013 22:11:37 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UA6Gn-0002kl-Fg;
	Mon, 25 Feb 2013 22:11:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UA6Gm-0004Zd-Cy;
	Mon, 25 Feb 2013 22:11:36 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16678-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 22:11:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16678: 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 16678 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16678/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 16508

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-win  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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail in 16508 never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6743c50ca91da63de23ad52f037bf9eadacfb492
+ branch=xen-4.1-testing
+ revision=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.1-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.1-testing
+ xenversion=xen-4.1
+ xenversion=4.1
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 6743c50ca91da63de23ad52f037bf9eadacfb492:stable-4.1
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   b39efd3..6743c50  6743c50ca91da63de23ad52f037bf9eadacfb492 -> stable-4.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 22:12:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 22:12: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 1UA6HB-0002Sh-LF; Mon, 25 Feb 2013 22:12: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 1UA6HA-0002SO-GZ
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 22:12:00 +0000
Received: from [85.158.137.99:15168] by server-1.bemta-3.messagelabs.com id
	5B/D5-08955-FA1EB215; Mon, 25 Feb 2013 22:11:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361830300!14754254!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDIzOTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20208 invoked from network); 25 Feb 2013 22:11:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Feb 2013 22:11:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="1863308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Feb 2013 22:11: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.297.1; Mon, 25 Feb 2013 22:11:37 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UA6Gn-0002kl-Fg;
	Mon, 25 Feb 2013 22:11:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UA6Gm-0004Zd-Cy;
	Mon, 25 Feb 2013 22:11:36 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16678-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 25 Feb 2013 22:11:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16678: 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 16678 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16678/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 16508

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16230

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-win  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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail in 16508 never pass

version targeted for testing:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492
baseline version:
 xen                  b39efd3dff19c73db3c901bca8213b10034cdc9e

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6743c50ca91da63de23ad52f037bf9eadacfb492
+ branch=xen-4.1-testing
+ revision=6743c50ca91da63de23ad52f037bf9eadacfb492
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.1-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.1-testing
+ xenversion=xen-4.1
+ xenversion=4.1
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 6743c50ca91da63de23ad52f037bf9eadacfb492:stable-4.1
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   b39efd3..6743c50  6743c50ca91da63de23ad52f037bf9eadacfb492 -> stable-4.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 22:19:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 22:19: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 1UA6Na-0002dV-M1; Mon, 25 Feb 2013 22:18:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UA6NX-0002dQ-RM
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 22:18:36 +0000
Received: from [85.158.138.51:18304] by server-15.bemta-3.messagelabs.com id
	AD/11-25405-A33EB215; Mon, 25 Feb 2013 22:18:34 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361830713!28107267!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17071 invoked from network); 25 Feb 2013 22:18:33 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 22:18:33 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:60951 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 1UA6LX-0003EH-HS; Mon, 25 Feb 2013 23:16:32 +0100
Date: Mon, 25 Feb 2013 23:18:30 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <312569942.20130225231830@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0791EC21F164E2952"
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller not
	detected 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0791EC21F164E2952
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Konrad,

I can't get linux-3.9 rc0 to boot under xen-unstable.
It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.

I don't see a obvious error in the logs.

The same kernel boots fine on baremetal.
With linux 3.8 it boots fine under this version of xen-unstable.

Can you spot something from the logs or you have a hunch from where to start a bisect ?
(bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

--
Sander

Attached:
- Serial log with 3.9-rc0 kernel (missing sata)
- Serial log with 3.8 kernel (booting fine
- .config
------------0791EC21F164E2952
Content-Type: application/octet-stream;
 name="serial-log-3.8.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log-3.8.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAg
IF8gICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyAvICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8v
IF8gXCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8
ICdfIFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxf
fCB8IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98
ICAgIHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxf
X198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3Rh
YmxlIChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVi
dWc9eSBTYXQgRmViIDIzIDE5OjU4OjA5IENFVCAyMDEzDQooWEVOKSBMYXRlc3QgQ2hhbmdl
U2V0OiB1bmF2YWlsYWJsZQ0KKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0
LTE0K3NxdWVlemUxDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTEwMjRNLG1heDox
MDI0TSBsb2dsdmw9YWxsIGxvZ2x2bF9ndWVzdD1hbGwgY29uc29sZV90aW1lc3RhbXBzIHZn
YT1nZngtMTI4MHgxMDI0eDMyIGNwdWlkbGUgY3B1ZnJlcT14ZW4gbm9yZWJvb3QgZGVidWcg
bGFwaWM9ZGVidWcgYXBpY192ZXJib3NpdHk9ZGVidWcgYXBpYz1kZWJ1ZyBpb21tdT1vbix2
ZXJib3NlLGRlYnVnLGFtZC1pb21tdS1kZWJ1Zyxuby1hbWQtaW9tbXUtcGVyZGV2LWludHJl
bWFwIGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZpZGVvIGluZm9y
bWF0aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAyNCwgMzIgYnBw
DQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNl
Y29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMiBNQlIgc2ln
bmF0dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihY
RU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAw
MDAwMDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAwIC0gMDAwMDAw
MDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAwMCAtIDAwMDAw
MDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAw
MDAwMGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAw
MDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjllMDAwIC0gMDAw
MDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZlMDAwMCAtIDAw
MDAwMDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0g
MDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjEwMCwg
MDAxNCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwgMDA0OCAocjEg
TVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBG
QUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIxICBBNzY0MCBB
NzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTogRkFDUyBBRkY5
RTAwMCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAocjEgNzY0ME1T
IEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIEFG
RjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAgICAgICA5
NykNCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAgICBPRU1TTElD
ICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBBRkY5RTA0MCwg
MDA3MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0ZfMTAgICAgICAg
IDIgQU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAsIDAwMzggKHIx
IDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTog
SVZSUyBBRkY5QTczMCwgMDEwMCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAg
ICAgICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChyMSBBIE0gSSAg
UE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3RlbSBSQU06IDgx
OTFNQiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUg
MA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDog
UFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAz
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogTm9kZSAw
IFBYTSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYjAwMDAw
MDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAwMDAwDQooWEVO
KSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDhjNzAwMCAtIDI0ZDhjYTAw
MA0KKFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21h
aW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGZi
MDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2MTQ0aywgdG90
YWwgMTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBsaW5lbGVu
Z3RoPTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9ODo4
Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAw
ZmY3ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4
YXBpYycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIEFDUEk6IFBN
LVRpbWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2Nu
dFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgd2Fr
ZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTogTG9jYWwgQVBJ
QyBhZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFd
IGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElD
IHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lk
WzB4MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElDIHZlcnNpb24g
MTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVu
YWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQoo
WEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQooWEVOKSBQcm9j
ZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzUg
MDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRk
cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19p
ZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQooWEVOKSBB
Q1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRd
KQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhm
ZWMyMDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIg
KGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KKFhFTikgQUNQSTog
SVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJy
aWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgRW5hYmxp
bmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVOKSBBQ1BJOiBI
UEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUgaXMgbm90IGZv
dW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGlu
Zm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMp
DQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZiMDAwIChmZWUwMDAwMCkNCihY
RU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYTAwMCAoZmVjMDAwMDApDQooWEVO
KSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQ0KKFhFTikg
SVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNpbmcgc2NoZWR1
bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0ZWN0ZWQgMzIw
MC4xODkgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuDQoo
WEVOKSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4p
IFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAw
IGJ1c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQg
MDAwMCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxv
Y2sgYXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAg
U2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDEwMA0KKFhFTikgQU1E
LVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweDg5DQooWEVO
KSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBS
RDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIwMjAzMQ0KKFhFTikgQU1E
LVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9u
IDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4M2UgbGVu
IDB4ZDAgaWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDIN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTAgZmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhj
MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHgxOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGEwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4NDMgaWQgMHhiMDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJh
bmdlOiAweGIwOCAtPiAweGJmZiBhbGlhcyAweGIwMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgyOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDkwMCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODAwIGZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDggZmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg3
MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHg1MCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweDYwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4MiBpZCAweDU4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgzIGlkIDB4NTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9J
ZCBSYW5nZTogMHg1MDAgLT4gMHg1MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgyIGlkIDB4NjggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeTogdHlwZSAweDIgaWQgMHg0MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg4OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDkwIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDk4IGZsYWdzIDANCihYRU4pIEFNRC1WaTog
IERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4MiBpZCAweGEwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTEgZmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMyBmbGFncyAwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE0IGZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMCBpZCAwIGZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0MyBpZCAweDMwMCBmbGFn
cyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmIGFsaWFz
IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4
YTUgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHhhOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGE5IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgyIGlkIDB4MTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgzIGlkIDB4YjAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IFJhbmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBTcGVjaWFs
OiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBTcGVjaWFsOiAwMDAwOjAwOjAwLjEgdmFyaWV0eSAweDEgaGFuZGxlIDB4Nw0KKFhF
TikgSVZIRCBFcnJvcjogbm8gaW5mb3JtYXRpb24gZm9yIElPLUFQSUMgMHg2DQooWEVOKSBB
TUQtVmk6IElPTU1VIDAgRW5hYmxlZC4NCihYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFs
IHZlY3RvciBtYXANCihYRU4pIEFNRC1WaTogVXNpbmcgZ2xvYmFsIGludGVycnVwdCByZW1h
cCB0YWJsZSBpcyBub3QgcmVjb21tZW5kZWQgKHNlZSBYU0EtMzYpIQ0KKFhFTikgSS9PIHZp
cnR1YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhF
TikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4
MDA1MDAxMA0KKFhFTikgR2V0dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDAN
CihYRU4pIEdldHRpbmcgTFZUMTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUj
MA0KKFhFTikgRVNSIHZhbHVlIGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6
IDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBB
Q0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFw
aWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0y
MiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwg
Ny05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3
LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3
LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJ
TUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVO
KSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQ
SUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lz
dGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAw
OiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQoo
WEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6
IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0K
KFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhF
TikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAg
IDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYw
MDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAg
ICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExv
ZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4p
ICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhF
TikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihY
RU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQoo
WEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0K
KFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQ
SUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikg
Li4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAx
OiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmll
czogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4p
IC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAw
DQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5
IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGlu
Zw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihY
RU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4g
MDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJR
ODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhF
TikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAg
LT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQoo
WEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVw
dHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BV
IGNsb2NrIHNwZWVkIGlzIDMyMDAuMTI3MCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBj
bG9jayBzcGVlZCBpcyAyMDAuMDA3OSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAw
eGNjZDcNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMwXSBQbGF0Zm9ybSB0aW1lciBpcyAx
NC4zMThNSHogSFBFVA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEFsbG9jYXRlZCBj
b25zb2xlIHJpbmcgb2YgNjQgS2lCLg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEhW
TTogQVNJRHMgZW5hYmxlZC4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBTVk06IFN1
cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMx
XSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIy
OjMxXSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24NCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjIyOjMxXSAgLSBOZXh0LVJJUCBTYXZlZCBvbiAjVk1FWElUDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRlcg0K
KFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEhWTTogU1ZNIGVuYWJsZWQNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQ
KSBkZXRlY3RlZA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEhWTTogSEFQIHBhZ2Ug
c2l6ZXM6IDRrQiwgMk1CLCAxR0INCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjI5XSBtYXNr
ZWQgRXh0SU5UIG9uIENQVSMxDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gbWljcm9j
b2RlOiBDUFUxIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikg
WzIwMTMtMDItMjUgMjA6MjI6MjldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzINCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSBtaWNyb2NvZGU6IENQVTIgY29sbGVjdF9jcHVfaW5mbzog
cGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjoyOV0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIG1pY3JvY29k
ZTogQ1BVMyBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjI5XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM0DQooWEVOKSBbMjAx
My0wMi0yNSAyMDoyMjozMV0gbWljcm9jb2RlOiBDUFU0IGNvbGxlY3RfY3B1X2luZm86IHBh
dGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MjldIG1hc2tlZCBF
eHRJTlQgb24gQ1BVIzUNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBCcm91Z2h0IHVw
IDYgQ1BVcw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIG1pY3JvY29kZTogQ1BVNSBj
b2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjIyOjMxXSBIUEVUOiAzIHRpbWVycyAoMyB3aWxsIGJlIHVzZWQgZm9yIGJyb2FkY2Fz
dCkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0K
KFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0
byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMx
XSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1
cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBt
ZW1zej0weGRjODAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl9wYXJzZV9i
aW5hcnk6IHBoZHI6IHBhZGRyPTB4MWUwMDAwMCBtZW1zej0weGU0MGYwDQooWEVOKSBbMjAx
My0wMi0yNSAyMDoyMjozMV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWU1
MDAwIG1lbXN6PTB4MTNkYzANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfcGFy
c2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlZjkwMDAgbWVtc3o9MHhlMjUwMDANCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAw
MDAwMCAtPiAweDJkMWUwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfeGVu
X3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lP
TiA9ICJ4ZW4tMy4wIg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4
MWVmOTIxMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90
ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJs
ZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikg
WzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdl
bmVyaWMiDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gZWxmX3hlbl9wYXJzZV9ub3Rl
OiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6
MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9
IDB4ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94
ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozMV0gZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4
MDAwMDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdICAgICBlbGZfcGFkZHJfb2Zm
c2V0ID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gICAgIHZpcnRfb2Zmc2V0
ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMx
XSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MjI6MzFdICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgy
ZDFlMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gICAgIHZpcnRfZW50cnkgICAg
ICAgPSAweGZmZmZmZmZmODFlZjkyMTANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSAg
ICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MjI6MzFdICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwg
bHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgyZDFlMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozMV0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAwLT4wMDAwMDAw
MjQ0MDAwMDAwICgyNDI1MTYgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MjI6MzFdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjRmMzU0MDAwLT4wMDAw
MDAwMjRmZmZmYzAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gVklSVFVBTCBNRU1P
UlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIExvYWRlZCBr
ZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJkMWUwMDANCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjIyOjMxXSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MmQxZTAwMC0+ZmZm
ZmZmZmY4MzljOWMwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdICBQaHlzLU1hY2gg
bWFwOiBmZmZmZmZmZjgzOWNhMDAwLT5mZmZmZmZmZjgzYmNhMDAwDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozMV0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNiY2EwMDAtPmZmZmZm
ZmZmODNiY2E0YjQNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSAgUGFnZSB0YWJsZXM6
ICAgZmZmZmZmZmY4M2JjYjAwMC0+ZmZmZmZmZmY4M2JlZTAwMA0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgzYmVlMDAwLT5mZmZmZmZm
ZjgzYmVmMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIFRPVEFMOiAgICAgICAg
IGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjIyOjMxXSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWVmOTIxMA0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MjI6MzFdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MjI6MzFdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZm
ZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkYzgwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjIyOjMxXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFlMDAwMDAg
LT4gMHhmZmZmZmZmZjgxZWU0MGYwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxZWU1MDAwIC0+IDB4ZmZmZmZm
ZmY4MWVmOGRjMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl9sb2FkX2JpbmFy
eTogcGhkciAzIGF0IDB4ZmZmZmZmZmY4MWVmOTAwMCAtPiAweGZmZmZmZmZmODFmYjQwMDAN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAwLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDEwLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MTgsIHJvb3QgdGFibGUgPSAweDI0N2I2
MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgy
OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDMwLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NDgsIHJvb3Qg
dGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHg1MCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCByb290IHRhYmxlID0g
MHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4NjgsIHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYy
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkw
LCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4OTIsIHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDlhLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAsIHJvb3QgdGFibGUgPSAw
eDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhhMSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEzLCByb290IHRhYmxlID0gMHgyNDdiNjIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTQs
IHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHhhNSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE4LCByb290IHRh
YmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4YjAsIHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMiwgcm9vdCB0YWJsZSA9IDB4
MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4w
DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gc2V0dXAgMDAwMDowMDoxOC4wIGZvciBk
MCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoy
MjozMl0gc2V0dXAgMDAwMDowMDoxOC4xIGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDow
MDoxOC4yDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gc2V0dXAgMDAwMDowMDoxOC4y
IGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQt
Vmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoyMjozMl0gc2V0dXAgMDAwMDowMDoxOC4zIGZvciBkMCBmYWlsZWQgKC0xOSkNCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2Ug
MDAwMDowMDoxOC40DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gc2V0dXAgMDAwMDow
MDoxOC40IGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDQwMCwgcm9v
dCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDUwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMSwgcm9vdCB0YWJs
ZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDYwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgcm9vdCB0YWJsZSA9IDB4
MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDgwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYy
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEw
MCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweGIwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGMwMCwgcm9v
dCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjM0XSBJbml0aWFsIGxv
dyBtZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjM0XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjM0XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozNF0gWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAx
My0wMi0yNSAyMDoyMjozNF0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJM
LWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozNF0gRnJlZWQgMjQ4a0IgaW5pdCBtZW1vcnkuDQptYXBwaW5nIGtlcm5l
bCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBM
aW51eCB2ZXJzaW9uIDMuOC4wLTIwMTMwMjE5LXR0eSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkg
KGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBU
dWUgRmViIDE5IDA5OjUyOjEwIENFVCAyMDEzDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxp
bmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9Nzk0IHZp
ZGVvPXZlc2FmYiBhY3BpX2VuZm9yY2VfcmVzb3VyY2VzPWxheCByODE2OS51c2VfZGFjPTEg
ZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgeGVuLXBjaWJh
Y2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDU6MDAuKikoMDY6MDAuKikoMGE6MDEuKikg
ZGVidWcgbG9nbGV2ZWw9MTAga21lbWxlYWs9b24NClsgICAgMC4wMDAwMDBdIEZyZWVpbmcg
OWYtMTAwIHBmbiByYW5nZTogOTcgcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBdIFJlbGVh
c2VkIDk3IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCAzMjc4
ODkgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGluZyA0
MDAwMC00MDA2MSBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAwXSBl
ODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBY
ZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNhYmxl
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAw
MDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYwZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBd
IFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjEwMDAtMHgwMDAwMDAwMGFmZjhmZmZmXSB1bnVz
YWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAw
MDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAwMDAwYWZmZGZmZmZdIEFDUEkgTlZTDQpbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGFmZmUwMDAwLTB4MDAwMDAwMDBhZmZmZmZm
Zl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAw
MDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAw
ZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
WGVuOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDAyNGZmZmZmZmZdIHVudXNh
YmxlDQpbICAgIDAuMDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsg
ICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0K
WyAgICAwLjAwMDAwMF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJBTSBtYXA6DQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAw
MDAwOWVmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAw
MDAwOWYwMDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
dXNlcjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDNmZmZmZmZmXSB1c2Fi
bGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAw
MDAwMDBhZmY4ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMGFmZjkwMDAwLTB4MDAwMDAwMDBhZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAu
MDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAwMDAwYWZmZGZm
ZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmZl
MDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2Vy
OiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAwMC0weDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAw
MDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAw
MDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZmUwMDAwMC0weDAwMDAwMDAwZmZmZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAw
MC0weDAwMDAwMDAyNGZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBTTUJJT1Mg
Mi41IHByZXNlbnQuDQpbICAgIDAuMDAwMDAwXSBETUk6IE1TSSBNUy03NjQwLzg5MEZYQS1H
RDcwIChNUy03NjQwKSAgLCBCSU9TIFYxLjhCMSAwOS8xMy8yMDEwDQpbICAgIDAuMDAwMDAw
XSBlODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMGZmZmZdIHVzYWJsZSA9PT4g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92ZSBbbWVtIDB4MDAwYTAwMDAt
MHgwMDBmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5k
DQpbICAgIDAuMDAwMDAwXSBlODIwOiBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZu
ID0gMHg0MDAwMDAwMDANClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDog
W21lbSAweDAwMDAwMDAwLTB4MDM5YzlmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9y
eSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAwXSA5OTAwMCBzaXplIDI0NTc2DQpb
ICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgz
ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0g
cGFnZSA0aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1
cCB0byAweDNmZmZmZmZmIEAgW21lbSAweDAyYjFjMDAwLTB4MDJkMWRmZmZdDQpbICAgIDAu
MDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjZmMwMDAgLSAyZDFlMDAwDQpb
ICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJkMWUwMDAtMHgwMzljOWZmZl0NClsg
ICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjEwMCAwMDAxNCAodjAwIEFD
UElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQgMDAwMDAwMDBhZmY5MDAwMCAwMDA0
OCAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMGFmZjkwMjAwIDAwMDg0ICh2MDEgNzY0ME1T
IEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAgMDk0MjcgKHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAw
MDAxMDAgSU5UTCAyMDA1MTExNykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAw
MDBhZmY5ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGFm
ZjkwMzkwIDAwMDg4ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAw
OTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0Mg
KHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4w
MDAwMDBdIEFDUEk6IFNMSUMgMDAwMDAwMDBhZmY5MDQ2MCAwMDE3NiAodjAxIE1TSSAgICBP
RU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
T0VNQiAwMDAwMDAwMGFmZjllMDQwIDAwMDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAw
OTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAw
YWZmOWE1ZTAgMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAw
MDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAwMDAwMDBhZmY5YTZmMCAwMDAz
OCAodjAxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogSVZSUyAwMDAwMDAwMGFmZjlhNzMwIDAwMTAwICh2MDEgIEFNRCAg
ICAgUkQ4OTBTIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBTU0RUIDAwMDAwMDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAw
MDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMg
YWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYNClsg
ICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAweDAwMDAwMDAwMDAwMDAwMDAt
MHgwMDAwMDAwMDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2Rl
IDAgW21lbSAweDAwMDAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5PREVf
REFUQSBbbWVtIDB4M2ZmZjUwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIFpvbmUg
cmFuZ2VzOg0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMTAwMDAtMHgw
MGZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4
ZmZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAgIGVtcHR5DQpbICAgIDAuMDAw
MDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0g
RWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAwMTAwMDAtMHgwMDA5ZWZmZl0NClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6
IFttZW0gMHgwMDEwMDAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gT24gbm9kZSAw
IHRvdGFscGFnZXM6IDI2MjAzMQ0KWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogNjQgcGFn
ZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2IHBhZ2Vz
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTEzIHBhZ2VzLCBMSUZP
IGJhdGNoOjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogNDAzMiBwYWdlcyB1c2Vk
IGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogMjU0MDE2IHBhZ2Vz
LCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0
OiAweDgwOA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVl
MDAwMDANClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGlj
X2lkWzB4MDBdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJs
ZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19p
ZFsweDA0XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElP
QVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAg
MC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4
ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4
MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0KWyAgICAwLjAwMDAwMF0g
SU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMyMDAwMCwg
R1NJIDI0LTU1DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAwLjAwMDAw
MF0gQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAwLjAwMDAwMF0gQUNQSTog
SVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAwLjAwMDAwMF0gVXNpbmcgQUNQSSAoTUFE
VCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KWyAgICAwLjAwMDAwMF0g
c21wYm9vdDogQWxsb3dpbmcgNiBDUFVzLCAwIGhvdHBsdWcgQ1BVcw0KWyAgICAwLjAwMDAw
MF0gbnJfaXJxc19nc2k6IDcyDQpbICAgIDAuMDAwMDAwXSBlODIwOiBbbWVtIDB4YjAwMDAw
MDAtMHhmZWJmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kgZGV2aWNlcw0KWyAgICAwLjAwMDAw
MF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbg0KWyAgICAwLjAwMDAw
MF0gWGVuIHZlcnNpb246IDQuMy11bnN0YWJsZSAocHJlc2VydmUtQUQpDQpbICAgIDAuMDAw
MDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNrX2JpdHM6OCBucl9jcHVf
aWRzOjYgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAy
NyBwYWdlcy9jcHUgQGZmZmY4ODAwM2Y4MDAwMDAgczgxMzQ0IHI4MTkyIGQyMTA1NiB1MjYy
MTQ0DQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODEzNDQgcjgxOTIgZDIxMDU2IHUy
NjIxNDQgYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0g
MCAxIDIgMyA0IDUgLSAtIA0KWyAgICA0LjkwNzgyNF0gQnVpbHQgMSB6b25lbGlzdHMgaW4g
Tm9kZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMjU3OTI5
DQpbICAgIDQuOTA3ODI3XSBQb2xpY3kgem9uZTogRE1BMzINClsgICAgNC45MDc4MzZdIEtl
cm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9v
dCBybyB2ZXJib3NlIG1lbT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9k
ZXNldCB2Z2E9Nzk0IHZpZGVvPXZlc2FmYiBhY3BpX2VuZm9yY2VfcmVzb3VyY2VzPWxheCBy
ODE2OS51c2VfZGFjPTEgZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3Bh
cnQ9MTAgeGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDU6MDAuKikoMDY6
MDAuKikoMGE6MDEuKikgZGVidWcgbG9nbGV2ZWw9MTAga21lbWxlYWs9b24NClsgICAgNC45
MDgwMTZdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBi
eXRlcykNClsgICAgNC45MDgwMjJdIF9fZXhfdGFibGUgYWxyZWFkeSBzb3J0ZWQsIHNraXBw
aW5nIHNvcnQNClsgICAgNC45NTA5MDRdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4M2E2MDAw
MDAtMHgzZTYwMDAwMF0gKDY0TUIpIG1hcHBlZCBhdCBbZmZmZjg4MDAzYTYwMDAwMC1mZmZm
ODgwMDNlNWZmZmZmXQ0KWyAgICA0Ljk1NjIwMV0gTWVtb3J5OiA5MjIxMTZrLzEwNDg1NzZr
IGF2YWlsYWJsZSAoMTAwMzBrIGtlcm5lbCBjb2RlLCA0NTJrIGFic2VudCwgMTI2MDA4ayBy
ZXNlcnZlZCwgNTIxNmsgZGF0YSwgNzk2ayBpbml0KQ0KWyAgICA0Ljk1NjUzOF0gU0xVQjog
R2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWluT2JqZWN0cz0wLCBDUFVz
PTYsIE5vZGVzPTENClsgICAgNC45NTY2NTRdIFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBS
Q1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDQuOTU2NjU2XSAJUkNVIGR5bnRpY2staWRsZSBn
cmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQpbICAgIDQuOTU2NjU4XSAJ
QWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRlZCB3aXRoIHN0YWxscy4NClsgICAgNC45
NTY2NjBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQVVM9OCB0byBucl9jcHVf
aWRzPTYuDQpbICAgIDQuOTU2NzEwXSBOUl9JUlFTOjQzNTIgbnJfaXJxczoxMjcyIDE2DQpb
ICAgIDQuOTU2ODU3XSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9
MCBwb2xhcml0eT0xDQpbICAgIDQuOTU2ODYxXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA5IHRy
aWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDQuOTU2ODk3XSB4ZW46IC0tPiBwaXJxPTkg
LT4gaXJxPTkgKGdzaT05KQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzRdIElPQVBJQ1sw
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEg
QWN0aXZlOjEpDQpbICAgIDQuOTU2OTE2XSB4ZW46IGFjcGkgc2NpIDkNClsgICAgNC45NTY5
MjNdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpDQpbICAgIDQuOTU2OTMwXSB4
ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIgKGdzaT0yKQ0KWyAgICA0Ljk1NjkzN10geGVuOiAt
LT4gcGlycT0zIC0+IGlycT0zIChnc2k9MykNClsgICAgNC45NTY5NDNdIHhlbjogLS0+IHBp
cnE9NCAtPiBpcnE9NCAoZ3NpPTQpDQpbICAgIDQuOTU2OTUwXSB4ZW46IC0tPiBwaXJxPTUg
LT4gaXJxPTUgKGdzaT01KQ0KWyAgICA0Ljk1Njk1Nl0geGVuOiAtLT4gcGlycT02IC0+IGly
cT02IChnc2k9NikNClsgICAgNC45NTY5NjNdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAo
Z3NpPTcpDQpbICAgIDQuOTU2OTcwXSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04
KQ0KWyAgICA0Ljk1Njk3N10geGVuOiAtLT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkN
ClsgICAgNC45NTY5ODRdIHhlbjogLS0+IHBpcnE9MTEgLT4gaXJxPTExIChnc2k9MTEpDQpb
ICAgIDQuOTU2OTkwXSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0xMiAoZ3NpPTEyKQ0KWyAg
ICA0Ljk1Njk5N10geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMgKGdzaT0xMykNClsgICAg
NC45NTcwMDRdIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0IChnc2k9MTQpDQpbICAgIDQu
OTU3MDEwXSB4ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAoZ3NpPTE1KQ0KWyAgICA0Ljk1
NzA4NF0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQ0KWyAgICA0Ljk1NzA4
OV0gY29uc29sZSBbdHR5MF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQNClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBM
aW51eCB2ZXJzaW9uIDMuOC4wLTIwMTMwMjE5LXR0eSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkg
KGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBU
dWUgRmViIDE5IDA5OjUyOjEwIENFVCAyMDEzDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxp
bmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9Nzk0IHZp
ZGVvPXZlc2FmYiBhY3BpX2VuZm9yY2VfcmVzb3VyY2VzPWxheCByODE2OS51c2VfZGFjPTEg
ZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgeGVuLXBjaWJh
Y2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDU6MDAuKikoMDY6MDAuKikoMGE6MDEuKikg
ZGVidWcgbG9nbGV2ZWw9MTAga21lbWxlYWs9b24NClsgICAgMC4wMDAwMDBdIEZyZWVpbmcg
OWYtMTAwIHBmbiByYW5nZTogOTcgcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBdIDEtMSBt
YXBwaW5nIG9uIDlmLT4xMDANClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIGFmZjkw
LT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDk3IHBhZ2VzIG9mIHVudXNlZCBt
ZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCAzMjc4ODkgcGFnZShzKSB0byAxLTEgbWFwcGlu
Zw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGluZyA0MDAwMC00MDA2MSBwZm4gcmFuZ2U6IDk3
IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNp
Y2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFtt
ZW0gMHgwMDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQw
MDYwZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAw
NjEwMDAtMHgwMDAwMDAwMGFmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0
YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAw
MDAwYWZmZGZmZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAw
MDAwMGFmZmUwMDAwLTB4MDAwMDAwMDBhZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0w
eDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDEwMDAw
MDAwMC0weDAwMDAwMDAyNGZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBlODIw
OiByZW1vdmUgW21lbSAweDQwMDAwMDAwLTB4ZmZmZmZmZmZmZmZmZmZmZV0gdXNhYmxlDQpb
ICAgIDAuMDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsgICAgMC4w
MDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAw
LjAwMDAwMF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAu
MDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVm
ZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwOWYw
MDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDNmZmZmZmZmXSB1c2FibGUNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAwMDBh
ZmY4ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGFmZjkwMDAwLTB4MDAwMDAwMDBhZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAwMDAw
XSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAwMDAwYWZmZGZmZmZdIEFD
UEkgTlZTDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmZlMDAwMC0w
eDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVt
IDB4MDAwMDAwMDBmZWMwMDAwMC0weDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVkDQpbICAg
IDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAwMDAwZmVj
MjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBm
ZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1
c2VyOiBbbWVtIDB4MDAwMDAwMDBmZmUwMDAwMC0weDAwMDAwMDAwZmZmZmZmZmZdIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAw
MDAwMDAyNGZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBTTUJJT1MgMi41IHBy
ZXNlbnQuDQpbICAgIDAuMDAwMDAwXSBETUk6IE1TSSBNUy03NjQwLzg5MEZYQS1HRDcwIChN
Uy03NjQwKSAgLCBCSU9TIFYxLjhCMSAwOS8xMy8yMDEwDQpbICAgIDAuMDAwMDAwXSBlODIw
OiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMGZmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBm
ZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kDQpbICAg
IDAuMDAwMDAwXSBlODIwOiBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZuID0gMHg0
MDAwMDAwMDANClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDogW21lbSAw
eDAwMDAwMDAwLTB4MDM5YzlmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFt
cG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAwXSA5OTAwMCBzaXplIDI0NTc2DQpbICAgIDAu
MDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0gcGFnZSA0
aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAw
eDNmZmZmZmZmIEAgW21lbSAweDAyYjFjMDAwLTB4MDJkMWRmZmZdDQpbICAgIDAuMDAwMDAw
XSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjZmMwMDAgLSAyZDFlMDAwDQpbICAgIDAu
MDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJkMWUwMDAtMHgwMzljOWZmZl0NClsgICAgMC4w
MDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjEwMCAwMDAxNCAodjAwIEFDUElBTSkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQgMDAwMDAwMDBhZmY5MDAwMCAwMDA0OCAodjAx
IE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAw
MF0gQUNQSTogRkFDUCAwMDAwMDAwMGFmZjkwMjAwIDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQw
MTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RU
IDAwMDAwMDAwYWZmOTA1ZTAgMDk0MjcgKHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAg
SU5UTCAyMDA1MTExNykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDBhZmY5
ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGFmZjkwMzkw
IDAwMDg4ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3
NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBd
IEFDUEk6IFNMSUMgMDAwMDAwMDBhZmY5MDQ2MCAwMDE3NiAodjAxIE1TSSAgICBPRU1TTElD
ICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogT0VNQiAw
MDAwMDAwMGFmZjllMDQwIDAwMDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1T
RlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1
ZTAgMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAwMDAwMDBhZmY5YTZmMCAwMDAzOCAodjAx
IDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAw
MF0gQUNQSTogSVZSUyAwMDAwMDAwMGFmZjlhNzMwIDAwMTAwICh2MDEgIEFNRCAgICAgUkQ4
OTBTIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RU
IDAwMDAwMDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEg
QU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz
cyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYNClsgICAgMC4w
MDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAw
MDAwMDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21l
bSAweDAwMDAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5PREVfREFUQSBb
bWVtIDB4M2ZmZjUwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIFpvbmUgcmFuZ2Vz
Og0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMTAwMDAtMHgwMGZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZm
ZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAgIGVtcHR5DQpbICAgIDAuMDAwMDAwXSBN
b3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0gRWFybHkg
bWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4
MDAwMTAwMDAtMHgwMDA5ZWZmZl0NClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0g
MHgwMDEwMDAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gT24gbm9kZSAwIHRvdGFs
cGFnZXM6IDI2MjAzMQ0KWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogNjQgcGFnZXMgdXNl
ZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2IHBhZ2VzIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTEzIHBhZ2VzLCBMSUZPIGJhdGNo
OjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogNDAzMiBwYWdlcyB1c2VkIGZvciBt
ZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogMjU0MDE2IHBhZ2VzLCBMSUZP
IGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgw
OA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4
MDBdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAy
XSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0
XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0g
bGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAo
aWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAgMC4wMDAw
MDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAw
MDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFk
ZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0KWyAgICAwLjAwMDAwMF0gSU9BUElD
WzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgWyAgICA3Ljg2OTc2MV0gU2Vy
aWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZA0K
WyAgICA3Ljg3NDQ5Ml0gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9D
UlMNClsgICAgNy44NzUzNzRdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMw0KWyAg
ICA3Ljg3ODMyOV0gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45LjEg
KHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4NClsgICAgNy44
Nzg1NzJdIEhhbmdjaGVjazogVXNpbmcgZ2V0cmF3bW9ub3RvbmljKCkuDQpbICAgIDcuODc5
MjA5XSBbZHJtXSBJbml0aWFsaXplZCBkcm0gMS4xLjAgMjAwNjA4MTANClsgICAgNy44Nzk2
NTRdIFtkcm1dIFZHQUNPTiBkaXNhYmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcuDQpb
ICAgIDcuODgwOTU5XSBwY2liYWNrIDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgZGV2aWNlICgw
MDAwIC0+IDAwMDMpDQpbICAgIDcuODg3NjQ3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMiB0
cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICA3Ljg5NDI3N10gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDozMg0KWyAgICA3LjkwMTc2MF0gcGNpYmFjayAwMDAwOjA1OjAwLjA6IGVuYWJs
aW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAgNy45MDg1NTldIFtkcm1dIFN1cHBvcnRzIHZibGFu
ayB0aW1lc3RhbXAgY2FjaGluZyBSZXYgMSAoMTAuMTAuMjAxMCkuDQpbICAgIDcuOTE1MzM0
XSBbZHJtXSBObyBkcml2ZXIgc3VwcG9ydCBmb3IgdmJsYW5rIHRpbWVzdGFtcCBxdWVyeS4N
ClsgICAgNy45MjIxMjRdIFtkcm1dIEluaXRpYWxpemVkIHJhZGVvbiAxLjMzLjAgMjAwODA1
MjggZm9yIDAwMDA6MDU6MDAuMCBvbiBtaW5vciAwDQpbICAgIDcuOTQ5NTU3XSBicmQ6IG1v
ZHVsZSBsb2FkZWQNClsgICAgOC4wMzIxODBdIGxvb3A6IG1vZHVsZSBsb2FkZWQNClsgICAg
OC4wNDI0OTldIGFoY2kgMDAwMDowMDoxMS4wOiB2ZXJzaW9uIDMuMA0KWyAgICA4LjA0OTI4
OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsg
ICAgOC4wNTYwOThdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTE5IChnc2k9MTkpDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoyMjozOF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDYtMTkgLT4gMHhiOSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KWyAgICA4LjA2
MzI4MV0gYWhjaSAwMDAwOjAwOjExLjA6IEFIQ0kgMDAwMS4wMjAwIDMyIHNsb3RzIDQgcG9y
dHMgNiBHYnBzIDB4ZiBpbXBsIFNBVEEgbW9kZQ0KWyAgICA4LjA3MDA0Nl0gYWhjaSAwMDAw
OjAwOjExLjA6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gcG1wIHBp
byBzbHVtIHBhcnQgDQpbICAgIDguMDgzODkxXSBzY3NpMCA6IGFoY2kNClsgICAgOC4wOTE3
OTFdIHNjc2kxIDogYWhjaQ0KWyAgICA4LjA5OTQzNV0gc2NzaTIgOiBhaGNpDQpbICAgIDgu
MTA3MDQ4XSBzY3NpMyA6IGFoY2kNClsgICAgOC4xMTQxOTJdIGF0YTE6IFNBVEEgbWF4IFVE
TUEvMTMzIGFiYXIgbTEwMjRAMHhmOTZmZjAwMCBwb3J0IDB4Zjk2ZmYxMDAgaXJxIDEyMQ0K
WyAgICA4LjEyMDczNF0gYXRhMjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGY5
NmZmMDAwIHBvcnQgMHhmOTZmZjE4MCBpcnEgMTIxDQpbICAgIDguMTI3MTI0XSBhdGEzOiBT
QVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4Zjk2ZmYwMDAgcG9ydCAweGY5NmZmMjAw
IGlycSAxMjENClsgICAgOC4xMzM0MzFdIGF0YTQ6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIg
bTEwMjRAMHhmOTZmZjAwMCBwb3J0IDB4Zjk2ZmYyODAgaXJxIDEyMQ0KWyAgICA4LjE0MTA4
NV0gdHVuOiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNClsgICAgOC4x
NDcyNThdIHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNv
bW0uY29tPg0KWyAgICA4LjE1MzY3M10gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdv
cmsgRHJpdmVyIC0gdmVyc2lvbiA3LjMuMjEtazgtTkFQSQ0KWyAgICA4LjE1OTgyMV0gZTEw
MDA6IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KWyAgICA4
LjE2NjI2MV0gZTEwMDBlOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIDIu
MS40LWsNClsgICAgOC4xNzIzMDFdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDEy
IEludGVsIENvcnBvcmF0aW9uLg0KWyAgICA4LjE3ODczMF0gaWdiOiBJbnRlbChSKSBHaWdh
Yml0IEV0aGVybmV0IE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiA0LjEuMi1rDQpbICAgIDgu
MTg0NzMyXSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDEyIEludGVsIENvcnBvcmF0aW9u
Lg0KWyAgICA4LjE5MDkyMV0gaWdidmY6IEludGVsKFIpIEdpZ2FiaXQgVmlydHVhbCBGdW5j
dGlvbiBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gMi4wLjItaw0KWyAgICA4LjE5Njk2NF0g
aWdidmY6IENvcHlyaWdodCAoYykgMjAwOSAtIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24uDQpb
ICAgIDguMjAzNDYxXSByODE2OSBHaWdhYml0IEV0aGVybmV0IGRyaXZlciAyLjNMSy1OQVBJ
IGxvYWRlZA0KWyAgICA4LjIwOTcxN10geGVuOiByZWdpc3RlcmluZyBnc2kgNDYgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAgOC4yMTU4NzhdIHhlbjogLS0+IHBpcnE9NDYgLT4g
aXJxPTQ2IChnc2k9NDYpDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozOF0gSU9BUElDWzFd
OiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjIgLT4gMHhjOSAtPiBJUlEgNDYgTW9kZTox
IEFjdGl2ZToxKQ0KWyAgICA4LjIyMjEwM10gcjgxNjkgMDAwMDowOTowMC4wOiBlbmFibGlu
ZyBNZW0tV3ItSW52YWwNClsgICAgOC4yMjk3OTddIHI4MTY5IDAwMDA6MDk6MDAuMCBldGgw
OiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMTAyYzQwMDAsIDQwOjYxOjg2OmY0OjY3
OmQ5LCBYSUQgMDgxMDAwYzAgSVJRIDEyMg0KWyAgICA4LjIzNjA3NV0gcjgxNjkgMDAwMDow
OTowMC4wIGV0aDA6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6IDkyMDAgYnl0ZXMsIHR4IGNo
ZWNrc3VtbWluZzoga29dDQpbICAgIDguMjQyNjEzXSByODE2OSBHaWdhYml0IEV0aGVybmV0
IGRyaXZlciAyLjNMSy1OQVBJIGxvYWRlZA0KWyAgICA4LjI0ODk4MV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgNTEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgOC4yNTUzMTVdIHhl
bjogLS0+IHBpcnE9NTEgLT4gaXJxPTUxIChnc2k9NTEpDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozOF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhk
OSAtPiBJUlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KWyAgICA4LjI2MTYyMl0gcjgxNjkgMDAw
MDowODowMC4wOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsgICAgOC4yNjk1NThdIHI4MTY5
IDAwMDA6MDg6MDAuMCBldGgxOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMTAyYzYw
MDAsIDQwOjYxOjg2OmY0OjY3OmQ4LCBYSUQgMDgxMDAwYzAgSVJRIDEyMw0KWyAgICA4LjI3
NTk5OF0gcjgxNjkgMDAwMDowODowMC4wIGV0aDE6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6
IDkyMDAgYnl0ZXMsIHR4IGNoZWNrc3VtbWluZzoga29dDQpbICAgIDguMjgzMTMxXSBJbml0
aWFsaXNpbmcgWGVuIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVyLg0KWyAgICA4LjI5MjEwNl0g
ZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERy
aXZlcg0KWyAgICA4LjI5ODU3Ml0gZWhjaS1wY2k6IEVIQ0kgUENJIHBsYXRmb3JtIGRyaXZl
cg0KWyAgICA4LjMwNTAwMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAgOC4zMTE0NTBdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcN
ClsgICAgOC4zMTc5MzRdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgYnVzIG1h
c3RlcmluZw0KWyAgICA4LjMyNDU2MF0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBFSENJIEhv
c3QgQ29udHJvbGxlcg0KWyAgICA4LjMzMTcxNV0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBu
ZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDENClsgICAgOC4z
MzgyMDBdIFFVSVJLOiBFbmFibGUgQU1EIFBMTCBmaXgNClsgICAgOC4zNDQ2NzBdIGVoY2kt
cGNpIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMg
RUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpbICAgIDguMzUxMzE0XSBlaGNpLXBjaSAwMDAw
OjAwOjEyLjI6IGRlYnVnIHBvcnQgMQ0KWyAgICA4LjM1NzkzMF0gZWhjaS1wY2kgMDAwMDow
MDoxMi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsgICAgOC4zNjQ1ODRdIGVoY2ktcGNp
IDAwMDA6MDA6MTIuMjogaXJxIDE3LCBpbyBtZW0gMHhmOTZmZjQwMA0KWyAgICA4LjM3ODcx
OF0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0K
WyAgICA4LjM4NTU0NF0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KWyAgICA4LjM5MTkyMF0gdXNiIHVzYjE6IE5ldyBV
U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpb
ICAgIDguMzk4MjM1XSB1c2IgdXNiMTogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIN
ClsgICAgOC40MDQ2NzldIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLTIw
MTMwMjE5LXR0eSBlaGNpX2hjZA0KWyAgICA4LjQxMTA0NF0gdXNiIHVzYjE6IFNlcmlhbE51
bWJlcjogMDAwMDowMDoxMi4yDQpbICAgIDguNDE4ODYxXSBodWIgMS0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KWyAgICA4LjQyNTI5Ml0gaHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQN
ClsgICAgOC40MzI1ODddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDguNDM4NzUyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3DQpb
ICAgIDguNDQ1MDM0XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJsaW5nIGJ1cyBtYXN0
ZXJpbmcNClsgICAgOC40NTEzMDJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogRUhDSSBIb3N0
IENvbnRyb2xsZXINClsgICAgOC40NTc5NDJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogbmV3
IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyDQpbICAgIDguNDU4
Njk3XSBhdGE0OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkNClsg
ICAgOC40NTg3NjhdIGF0YTI6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wg
MzAwKQ0KWyAgICA4LjQ3NjU0Ml0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBhcHBseWluZyBB
TUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQNClsg
ICAgOC40ODI4NjFdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZGVidWcgcG9ydCAxDQpbICAg
IDguNDg5MjI0XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJsaW5nIE1lbS1Xci1JbnZh
bA0KWyAgICA4LjQ5NTUxOV0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBpcnEgMTcsIGlvIG1l
bSAweGY5NmZmODAwDQpbICAgIDguNTEyMDUwXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IFVT
QiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwDQpbICAgIDguNTE4NDY2XSB1c2IgdXNiMjogTmV3
IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpbICAg
IDguNTI0OTA4XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy
b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgOC41MzEzNjhdIHVzYiB1c2IyOiBQcm9k
dWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4LjUzNzkxOF0gdXNiIHVzYjI6IE1h
bnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAyMTktdHR5IGVoY2lfaGNkDQpbICAgIDgu
NTQ0NDkxXSB1c2IgdXNiMjogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEzLjINClsgICAgOC41
NTIwMDRdIGh1YiAyLTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDguNTU4NDI0XSBodWIg
Mi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICA4LjU2NTczNF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgOC41NzIwOTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAgOC41Nzg0MjNdIGVoY2ktcGNpIDAwMDA6
MDA6MTYuMjogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgICA4LjU4NDg0N10gZWhjaS1w
Y2kgMDAwMDowMDoxNi4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4LjU5MTU5Ml0g
ZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l
ZCBidXMgbnVtYmVyIDMNClsgICAgOC41OTc4MTddIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjog
YXBwbHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3Jr
YXJvdW5kDQpbICAgIDguNjA0MjAzXSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGRlYnVnIHBv
cnQgMQ0KWyAgICA4LjYxMDUxNV0gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBlbmFibGluZyBN
ZW0tV3ItSW52YWwNClsgICAgOC42MTY2ODNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogaXJx
IDE3LCBpbyBtZW0gMHhmOTZmZmMwMA0KWyAgICA4LjYyNTM3MF0gYXRhMzogU0FUQSBsaW5r
IHVwIDYuMCBHYnBzIChTU3RhdHVzIDEzMyBTQ29udHJvbCAzMDApDQpbICAgIDguNjMxNjI5
XSBhdGExOiBTQVRBIGxpbmsgdXAgMy4wIEdicHMgKFNTdGF0dXMgMTIzIFNDb250cm9sIDMw
MCkNClsgICAgOC42MzIwMzhdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFy
dGVkLCBFSENJIDEuMDANClsgICAgOC42MzI0MjddIHVzYiB1c2IzOiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAgOC42MzI0Mjhd
IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MQ0KWyAgICA4LjYzMjQzMF0gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kg
SG9zdCBDb250cm9sbGVyDQpbICAgIDguNjMyNDMxXSB1c2IgdXNiMzogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjguMC0yMDEzMDIxOS10dHkgZWhjaV9oY2QNClsgICAgOC42MzI0MzJdIHVz
YiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMg0KWyAgICA4LjYzMzkzMV0gaHVi
IDMtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgOC42MzM5ODFdIGh1YiAzLTA6MS4wOiA0
IHBvcnRzIGRldGVjdGVkDQpbICAgIDguNjM0Nzk1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAz
MSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICA4LjYzNDc5N10gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDozMQ0KWyAgICA4LjYzNDg0MV0gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBl
bmFibGluZyBidXMgbWFzdGVyaW5nDQpbICAgIDguNjM0ODQ5XSBlaGNpLXBjaSAwMDAwOjBi
OjAxLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDguNjM1NDc3XSBlaGNpLXBjaSAw
MDAwOjBiOjAxLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1i
ZXIgNA0KWyAgICA4LjYzNTc1NF0gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBpcnEgMzEsIGlv
IG1lbSAweGY5ZmZmYzAwDQpbICAgIDguNjQ1MzIwXSBlaGNpLXBjaSAwMDAwOjBiOjAxLjI6
IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwDQpbICAgIDguNjQ1NjEyXSB1c2IgdXNiNDog
TmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpb
ICAgIDguNjQ1NjEzXSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMs
IFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgOC42NDU2NTNdIHVzYiB1c2I0OiBQ
cm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4LjY0NTY1NF0gdXNiIHVzYjQ6
IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAyMTktdHR5IGVoY2lfaGNkDQpbICAg
IDguNjQ1NjU1XSB1c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjBiOjAxLjINClsgICAg
OC42NDcxMDFdIGh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDguNjQ3MTczXSBo
dWIgNC0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICA4LjY0ODY5Ml0gb2hjaV9oY2Q6
IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyDQpbICAgIDgu
NjQ4NzkyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICA4LjY0ODc5NV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgICA4LjY0
ODg1OF0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQpb
ICAgIDguNjQ4ODY2XSBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9s
bGVyDQpbICAgIDguNjQ5NDkyXSBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IG5ldyBVU0IgYnVz
IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgICA4LjY0OTc0Nl0gb2hj
aV9oY2QgMDAwMDowMDoxMi4wOiBpcnEgMTgsIGlvIG1lbSAweGY5NmZiMDAwDQpbICAgIDgu
NzA2MzcwXSB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAxDQpbICAgIDguNzA2MzcyXSB1c2IgdXNiNTogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgOC43
MDYzNzNdIHVzYiB1c2I1OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4
LjcwNjM3NF0gdXNiIHVzYjU6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAyMTkt
dHR5IG9oY2lfaGNkDQpbICAgIDguNzA2Mzc1XSB1c2IgdXNiNTogU2VyaWFsTnVtYmVyOiAw
MDAwOjAwOjEyLjANClsgICAgOC43MDgxMjFdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5k
DQpbICAgIDguNzA4MTgwXSBodWIgNS0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICA4
LjcwOTI3Nl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5
IDENClsgICAgOC43MDkyNzhdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAgOC43
MDkzMjVdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0K
WyAgICA4LjcwOTMzMl0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBPSENJIEhvc3QgQ29udHJv
bGxlcg0KWyAgICA4LjcxMDA1OV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBuZXcgVVNCIGJ1
cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDYNClsgICAgOC43MTAyNjhdIG9o
Y2lfaGNkIDAwMDA6MDA6MTMuMDogaXJxIDE4LCBpbyBtZW0gMHhmOTZmYzAwMA0KWyAgICA4
Ljc2NjE5Ml0gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi
LCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICA4Ljc2NjE5M10gdXNiIHVzYjY6IE5ldyBVU0IgZGV2
aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDgu
NzY2MTk0XSB1c2IgdXNiNjogUHJvZHVjdDogT0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAg
OC43NjYxOTVdIHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLTIwMTMwMjE5
LXR0eSBvaGNpX2hjZA0KWyAgICA4Ljc2NjE5Nl0gdXNiIHVzYjY6IFNlcmlhbE51bWJlcjog
MDAwMDowMDoxMy4wDQpbICAgIDguNzY3OTQxXSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3Vu
ZA0KWyAgICA4Ljc2Nzk5NF0gaHViIDYtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAg
OC43Njg5MTRdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0
eSAxDQpbICAgIDguNzY4OTE2XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDgu
NzY4OTYzXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcN
ClsgICAgOC43Njg5NzBdIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogT0hDSSBIb3N0IENvbnRy
b2xsZXINClsgICAgOC43Njk2ODldIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3DQpbICAgIDguNzY5OTAxXSBv
aGNpX2hjZCAwMDAwOjAwOjE0LjU6IGlycSAxOCwgaW8gbWVtIDB4Zjk2ZmQwMDANClsgICAg
OC44MjYyMTRdIHVzYiB1c2I3OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDENClsgICAgOC44MjYyMTVdIHVzYiB1c2I3OiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICA4
LjgyNjIxNl0gdXNiIHVzYjc6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAg
IDguODI2MjE3XSB1c2IgdXNiNzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC0yMDEzMDIx
OS10dHkgb2hjaV9oY2QNClsgICAgOC44MjYyMThdIHVzYiB1c2I3OiBTZXJpYWxOdW1iZXI6
IDAwMDA6MDA6MTQuNQ0KWyAgICA4LjgyNzc3NV0gaHViIDctMDoxLjA6IFVTQiBodWIgZm91
bmQNClsgICAgOC44Mjc4NDJdIGh1YiA3LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAg
IDguODI4NDczXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQ0KWyAgICA4LjgyODQ3NV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgICA4
LjgyODU1N10gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5n
DQpbICAgIDguODI4NTY1XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IE9IQ0kgSG9zdCBDb250
cm9sbGVyDQpbICAgIDguODI5MjY2XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IG5ldyBVU0Ig
YnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgOA0KWyAgICA4LjgyOTM2NF0g
b2hjaV9oY2QgMDAwMDowMDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGY5NmZlMDAwDQpbICAg
IDguODg2MjQwXSB1c2IgdXNiODogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFk
NmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDguODg2MjQxXSB1c2IgdXNiODogTmV3IFVTQiBk
ZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAg
OC44ODYyNDJdIHVzYiB1c2I4OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAg
ICA4Ljg4NjI0M10gdXNiIHVzYjg6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAy
MTktdHR5IG9oY2lfaGNkDQpbICAgIDguODg2MjQ0XSB1c2IgdXNiODogU2VyaWFsTnVtYmVy
OiAwMDAwOjAwOjE2LjANClsgICAgOC44ODc3MzldIGh1YiA4LTA6MS4wOiBVU0IgaHViIGZv
dW5kDQpbICAgIDguODg3NzkxXSBodWIgOC0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KWyAg
ICA4Ljg4ODgyMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMjkgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgOC44ODg4MjRdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjkNClsgICAg
OC44ODg4NjldIG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogZW5hYmxpbmcgYnVzIG1hc3Rlcmlu
Zw0KWyAgICA4Ljg4ODg3N10gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBPSENJIEhvc3QgQ29u
dHJvbGxlcg0KWyAgICA4Ljg4OTcyNF0gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBuZXcgVVNC
IGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkNClsgICAgOC44ODk5MjFd
IG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogaXJxIDI5LCBpbyBtZW0gMHhmOWZmZDAwMA0KWyAg
ICA4Ljk3MjE2MV0gdXNiIHVzYjk6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0x
ZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICA4Ljk3MjE2M10gdXNiIHVzYjk6IE5ldyBVU0Ig
ZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAg
IDguOTcyMTY0XSB1c2IgdXNiOTogUHJvZHVjdDogT0hDSSBIb3N0IENvbnRyb2xsZXINClsg
ICAgOC45NzIxNjVdIHVzYiB1c2I5OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLTIwMTMw
MjE5LXR0eSBvaGNpX2hjZA0KWyAgICA4Ljk3MjE2Nl0gdXNiIHVzYjk6IFNlcmlhbE51bWJl
cjogMDAwMDowYjowMS4wDQpbICAgIDguOTczOTAxXSBodWIgOS0wOjEuMDogVVNCIGh1YiBm
b3VuZA0KWyAgICA4Ljk3Mzk5OV0gaHViIDktMDoxLjA6IDMgcG9ydHMgZGV0ZWN0ZWQNClsg
ICAgOC45NzQ3NjBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMwIHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQpbICAgIDguOTc0NzYyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjMwDQpbICAg
IDguOTc0ODA1XSBvaGNpX2hjZCAwMDAwOjBiOjAxLjE6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJp
bmcNClsgICAgOC45NzQ4MTNdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMTogT0hDSSBIb3N0IENv
bnRyb2xsZXINClsgICAgOC45NzU0MDJdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMTogbmV3IFVT
QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxMA0KWyAgICA4Ljk3NTU4
M10gb2hjaV9oY2QgMDAwMDowYjowMS4xOiBpcnEgMzAsIGlvIG1lbSAweGY5ZmZlMDAwDQpb
ICAgIDkuMDU4ODAwXSB1c2IgdXNiMTA6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICA5LjA1ODgwMl0gdXNiIHVzYjFbICAgMTEu
MzU0NDYwXSBiaW86IGNyZWF0ZSBzbGFiIDxiaW8tMT4gYXQgMQ0KWyAgIDExLjc0MjExNV0g
RVhUNC1mcyAoZG0tMCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBt
b2RlLiBPcHRzOiAobnVsbCkNClsgICAxMy41ODQ3MTNdIHVkZXZbMTgzOF06IHN0YXJ0aW5n
IHZlcnNpb24gMTY0DQpbICAgMTQuNTY4OTQzXSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBV
RE1BLzEzMw0KWyAgIDE0LjU3NTA5NV0gYXRhMTogRUggY29tcGxldGUNClsgICAxNS4xODg1
ODldIGF0YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzDQpbICAgMTUuMTg4NTk3XSBh
dGExOiBFSCBjb21wbGV0ZQ0KWyAgIDE1LjkxNzkzMV0gRVhUNC1mcyAoZG0tMCk6IHJlLW1v
dW50ZWQuIE9wdHM6IChudWxsKQ0KWyAgIDE2LjI2OTY0OF0gRVhUNC1mcyAoZG0tMCk6IHJl
LW1vdW50ZWQuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDI3LjE1
OTcyMV0gQWRkaW5nIDIwOTcxNDhrIHN3YXAgb24gL2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0
amUtc3dhcC4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6MjA5NzE0OGsgDQpbICAg
MzYuMTUxMTI3XSBFWFQ0LWZzIChzZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3Jk
ZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAg
IDM2LjE5NTA5OF0gYnRyZnM6IG9wZW4gVVVJRD0iYjJkYWMyNTUtYTk2ZS00NzJlLTgwNmYt
NTY3OWUwMjY2ZjZlIiBmYWlsZWQNClsgICAzOC41MzY2NjFdIHI4MTY5IDAwMDA6MDg6MDAu
MCBldGgxOiBsaW5rIGRvd24NClsgICAzOC41NDM0MjNdIHI4MTY5IDAwMDA6MDg6MDAuMCBl
dGgxOiBsaW5rIGRvd24NClsgICAzOC43MDk4NzJdIHI4MTY5IDAwMDA6MDk6MDAuMCBldGgw
OiBsaW5rIGRvd24NClsgICAzOC43MDk5MzhdIHI4MTY5IDAwMDA6MDk6MDAuMCBldGgwOiBs
aW5rIGRvd24NClsgICA0MC4yMTkwNDddIHI4MTY5IDAwMDA6MDg6MDAuMCBldGgxOiBsaW5r
IHVwDQpbICAgNDAuMzgzMDE1XSByODE2OSAwMDAwOjA5OjAwLjAgZXRoMDogbGluayB1cA0K
WyAgIDYwLjMzOTg5MF0gRlc6IGlwbWFzcSwgRm9yd2FyZCAuLiBFb0M6IElOPWV0aDAgT1VU
PWV0aDAgTUFDPTQwOjYxOjg2OmY0OjY3OmQ5OjAwOjA4OmFlOjEwOjQ2OjYwOjA4OjAwIFNS
Qz04Mi4xNzMuOTcuMTUgRFNUPTg4LjE1OS44MC4xOSBMRU49NTggVE9TPTB4MDAgUFJFQz0w
eDAwIFRUTD0xMTUgSUQ9MjQwNTcgUFJPVE89VURQIFNQVD0xNjgwMCBEUFQ9MzQyODkgTEVO
PTM4IA0KWyAgIDY4LjE4MjI0OF0gc3NoZCAoNjQ0Nyk6IC9wcm9jLzY0NDcvb29tX2FkaiBp
cyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzY0NDcvb29tX3Njb3JlX2FkaiBpbnN0
ZWFkLg0KWyAgIDcyLjUxNzA1N10gRVhUNC1mcyAoZG0tMik6IG1vdW50ZWQgZmlsZXN5c3Rl
bSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91
bnQtcm8NClsgICA3Ni41NTY5MzldIEVYVDQtZnMgKGRtLTM2KTogbW91bnRlZCBmaWxlc3lz
dGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVt
b3VudC1ybw0KWyAgIDgwLjkyNTM1OF0gRVhUNC1mcyAoZG0tMzcpOiBtb3VudGVkIGZpbGVz
eXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1y
ZW1vdW50LXJvDQpbICAgODUuNDAyNjYyXSBFWFQ0LWZzIChkbS0zOCk6IG1vdW50ZWQgZmls
ZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3Jz
PXJlbW91bnQtcm8NClsgICA4OS44MTY3ODZdIEVYVDQtZnMgKGRtLTM5KTogbW91bnRlZCBm
aWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJv
cnM9cmVtb3VudC1ybw0KWyAgIDk2LjA1NzEwNF0gRVhUNC1mcyAoZG0tNDApOiBtb3VudGVk
IGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVy
cm9ycz1yZW1vdW50LXJvDQpbICAxMDAuODYyNDI0XSBFWFQ0LWZzIChzZGIxKTogbW91bnRl
ZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxl
cnJvcnM9cmVtb3VudC1ybw0K
------------0791EC21F164E2952
Content-Type: application/octet-stream;
 name="serial-log-3.9-rc0.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log-3.9-rc0.log"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyAv
ICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8vIF8g
XCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf
IFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8
IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98ICAg
IHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxl
IChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVidWc9
eSBTYXQgRmViIDIzIDE5OjU4OjA5IENFVCAyMDEzDQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0
OiB1bmF2YWlsYWJsZQ0KKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0
K3NxdWVlemUxDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTEwMjRNLG1heDoxMDI0
TSBsb2dsdmw9YWxsIGxvZ2x2bF9ndWVzdD1hbGwgY29uc29sZV90aW1lc3RhbXBzIHZnYT1n
ZngtMTI4MHgxMDI0eDMyIGNwdWlkbGUgY3B1ZnJlcT14ZW4gbm9yZWJvb3QgZGVidWcgbGFw
aWM9ZGVidWcgYXBpY192ZXJib3NpdHk9ZGVidWcgYXBpYz1kZWJ1ZyBpb21tdT1vbix2ZXJi
b3NlLGRlYnVnLGFtZC1pb21tdS1kZWJ1Zyxuby1hbWQtaW9tbXUtcGVyZGV2LWludHJlbWFw
IGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZpZGVvIGluZm9ybWF0
aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAyNCwgMzIgYnBwDQoo
WEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29u
ZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMiBNQlIgc2lnbmF0
dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihYRU4p
IFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAw
MDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAwIC0gMDAwMDAwMDAw
MDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAwMCAtIDAwMDAwMDAw
MDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAw
MGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAwMDAw
YWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjllMDAwIC0gMDAwMDAw
MDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZlMDAwMCAtIDAwMDAw
MDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAw
MDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjEwMCwgMDAx
NCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwgMDA0OCAocjEgTVNJ
ICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBGQUNQ
IEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAg
ICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIxICBBNzY0MCBBNzY0
MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTogRkFDUyBBRkY5RTAw
MCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAocjEgNzY0ME1TIEE3
NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIEFGRjkw
NDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykN
CihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAgICBPRU1TTElDICAy
MDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBBRkY5RTA0MCwgMDA3
MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBB
Q1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0ZfMTAgICAgICAgIDIg
QU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAsIDAwMzggKHIxIDc2
NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogSVZS
UyBBRkY5QTczMCwgMDEwMCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAgICAg
ICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChyMSBBIE0gSSAgUE9X
RVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3RlbSBSQU06IDgxOTFN
QiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0K
KFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhN
IDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+
IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5vZGUgMA0KKFhFTikg
U1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogTm9kZSAwIFBY
TSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYjAwMDAwMDAN
CihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAwMDAwDQooWEVOKSBO
VU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDg3NjAwMCAtIDI0ZDg3OTAwMA0K
KFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21haW4g
aGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGZiMDAw
MDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwg
MTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBsaW5lbGVuZ3Ro
PTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9ODo4Ojg6
OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3
ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4YXBp
YycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIEFDUEk6IFBNLVRp
bWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFs4
MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgd2FrZXVw
X3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBh
ZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxh
cGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZl
cnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4
MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElDIHZlcnNpb24gMTYN
CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJs
ZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQooWEVO
KSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNz
b3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzUgMDox
MCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVz
c1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCA2
LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQooWEVOKSBBQ1BJ
OiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0K
KFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMy
MDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly
cSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KKFhFTikgQUNQSTogSVJR
MCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRl
Lg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgRW5hYmxpbmcg
QVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVOKSBBQ1BJOiBIUEVU
IGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUgaXMgbm90IGZvdW5k
IQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y
bWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQoo
WEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZiMDAwIChmZWUwMDAwMCkNCihYRU4p
IG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYTAwMCAoZmVjMDAwMDApDQooWEVOKSBt
YXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQ0KKFhFTikgSVJR
IGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNpbmcgc2NoZWR1bGVy
OiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0ZWN0ZWQgMzIwMC4y
MDggTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuDQooWEVO
KSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4pIFBD
STogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1
c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAw
MCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxvY2sg
YXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAgU2ln
bmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDEwMA0KKFhFTikgQU1ELVZp
OiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweDg5DQooWEVOKSBB
TUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBSRDg5
MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIwMjAzMQ0KKFhFTikgQU1ELVZp
OiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9uIDAN
CihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4M2UgbGVuIDB4
ZDAgaWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBp
ZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTAgZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhjMDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHgxOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MiBpZCAweGEwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0
eXBlIDB4NDMgaWQgMHhiMDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdl
OiAweGIwOCAtPiAweGJmZiBhbGlhcyAweGIwMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeTogdHlwZSAweDIgaWQgMHgyOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDkwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODAwIGZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDggZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg3MDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg1MCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MiBpZCAweDYwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0
eXBlIDB4MiBpZCAweDU4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgzIGlkIDB4NTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBS
YW5nZTogMHg1MDAgLT4gMHg1MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgyIGlkIDB4NjggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAweDIgaWQgMHg0MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg4OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDkwIGZsYWdzIDANCihYRU4pIEFNRC1W
aTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDk4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweGEwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTEgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMyBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE0IGZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMCBpZCAwIGZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0MyBpZCAweDMwMCBmbGFncyAw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmIGFsaWFzIDB4
YTQNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTUg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHhhOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MiBpZCAweGE5IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5
cGUgMHgyIGlkIDB4MTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgzIGlkIDB4YjAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJh
bmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5
cGUgMCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5
cGUgMHg0OCBpZCAwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBTcGVjaWFsOiAw
MDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBTcGVjaWFsOiAwMDAwOjAwOjAwLjEgdmFyaWV0eSAweDEgaGFuZGxlIDB4Nw0KKFhFTikg
SVZIRCBFcnJvcjogbm8gaW5mb3JtYXRpb24gZm9yIElPLUFQSUMgMHg2DQooWEVOKSBBTUQt
Vmk6IElPTU1VIDAgRW5hYmxlZC4NCihYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFsIHZl
Y3RvciBtYXANCihYRU4pIEFNRC1WaTogVXNpbmcgZ2xvYmFsIGludGVycnVwdCByZW1hcCB0
YWJsZSBpcyBub3QgcmVjb21tZW5kZWQgKHNlZSBYU0EtMzYpIQ0KKFhFTikgSS9PIHZpcnR1
YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikg
R2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1
MDAxMA0KKFhFTikgR2V0dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihY
RU4pIEdldHRpbmcgTFZUMTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0K
KFhFTikgRVNSIHZhbHVlIGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6IDAN
CihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sg
bWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNp
ZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwg
Ni0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05
LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4
LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3
LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVS
OiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBu
dW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMg
IzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVy
czogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAw
NjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVO
KSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExU
UyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhF
TikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikg
Li4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDog
SU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAw
MDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6
IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQ
aHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikg
IDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4p
ICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVO
KSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhF
TikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihY
RU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQoo
WEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0K
KFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgN
CihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDYw
DQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2
OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVn
aXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMg
aWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4u
Li4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAw
MDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczog
MDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4u
Li4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVy
ICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQoo
WEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1h
c2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0K
KFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4p
IElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0
DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAg
LT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikg
SVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4g
MDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVO
KSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMu
DQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNs
b2NrIHNwZWVkIGlzIDMyMDAuMTIwMyBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9j
ayBzcGVlZCBpcyAyMDAuMDA3NCBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweGNj
ZDcNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBQbGF0Zm9ybSB0aW1lciBpcyAxNC4z
MThNSHogSFBFVA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEFsbG9jYXRlZCBjb25z
b2xlIHJpbmcgb2YgNjQgS2lCLg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEhWTTog
QVNJRHMgZW5hYmxlZC4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBTVk06IFN1cHBv
cnRlZCBhZHZhbmNlZCBmZWF0dXJlczoNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSAg
LSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5
XSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24NCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjEzOjQ5XSAgLSBOZXh0LVJJUCBTYXZlZCBvbiAjVk1FWElUDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRlcg0KKFhF
TikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEhWTTogU1ZNIGVuYWJsZWQNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBk
ZXRlY3RlZA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEhWTTogSEFQIHBhZ2Ugc2l6
ZXM6IDRrQiwgMk1CLCAxR0INCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ4XSBtYXNrZWQg
RXh0SU5UIG9uIENQVSMxDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gbWljcm9jb2Rl
OiBDUFUxIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MTM6NDhdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzINCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSBtaWNyb2NvZGU6IENQVTIgY29sbGVjdF9jcHVfaW5mbzogcGF0
Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OF0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIG1pY3JvY29kZTog
Q1BVMyBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ4XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM0DQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoxMzo0OV0gbWljcm9jb2RlOiBDUFU0IGNvbGxlY3RfY3B1X2luZm86IHBhdGNo
X2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDhdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzUNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBCcm91Z2h0IHVwIDYg
Q1BVcw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIG1pY3JvY29kZTogQ1BVNSBjb2xs
ZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjEzOjQ5XSBIUEVUOiAzIHRpbWVycyAoMyB3aWxsIGJlIHVzZWQgZm9yIGJyb2FkY2FzdCkN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhF
TikgWzIwMTMtMDItMjUgMjA6MTM6NDldIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBh
ZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBt
Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJ
QlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NDldICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NDldIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1z
ej0weGRjYzAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl9wYXJzZV9iaW5h
cnk6IHBoZHI6IHBhZGRyPTB4MWUwMDAwMCBtZW1zej0weGVhMGYwDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoxMzo0OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWViMDAw
IG1lbXN6PTB4MTQwNDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBlbGZfcGFyc2Vf
YmluYXJ5OiBwaGRyOiBwYWRkcj0weDFmMDAwMDAgbWVtc3o9MHhlNzAwMDANCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjEzOjQ5XSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAw
MCAtPiAweDJkNzAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6
NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVOKSBb
MjAxMy0wMi0yNSAyMDoxMzo0OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9
ICJ4ZW4tMy4wIg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5fcGFyc2Vf
bm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo0OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MWYw
MDFlMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTog
SFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjQ5XSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9w
YWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIg0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MTM6NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVy
aWMiDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiB1
bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDld
IGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9IDB4
ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5f
cGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo0OV0gZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw
MDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldICAgICBlbGZfcGFkZHJfb2Zmc2V0
ID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gICAgIHZpcnRfb2Zmc2V0ICAg
ICAgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSAg
ICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MTM6NDldICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyZDcw
MDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gICAgIHZpcnRfZW50cnkgICAgICAg
PSAweGZmZmZmZmZmODFmMDAxZTANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSAgICAg
cDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MTM6NDldICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNi
LCBwYWRkciAweDEwMDAwMDAgLT4gMHgyZDcwMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo1MF0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NTBdICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAwLT4wMDAwMDAwMjQ0
MDAwMDAwICgyNDI1MTYgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MTM6NTBdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjRmMzU0MDAwLT4wMDAwMDAw
MjRmZmZmYzAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gVklSVFVBTCBNRU1PUlkg
QVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gIExvYWRlZCBrZXJu
ZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJkNzAwMDANCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjEzOjUwXSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MmQ3MDAwMC0+ZmZmZmZm
ZmY4M2ExYmMwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdICBQaHlzLU1hY2ggbWFw
OiBmZmZmZmZmZjgzYTFjMDAwLT5mZmZmZmZmZjgzYzFjMDAwDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo1MF0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNjMWMwMDAtPmZmZmZmZmZm
ODNjMWM0YjQNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSAgUGFnZSB0YWJsZXM6ICAg
ZmZmZmZmZmY4M2MxZDAwMC0+ZmZmZmZmZmY4M2M0MDAwMA0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NTBdICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgzYzQwMDAwLT5mZmZmZmZmZjgz
YzQxMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gIFRPVEFMOiAgICAgICAgIGZm
ZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjEzOjUwXSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWYwMDFlMA0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MTM6NTBdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MTM6NTBdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4
MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkY2MwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEz
OjUwXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFlMDAwMDAgLT4g
MHhmZmZmZmZmZjgxZWVhMGYwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gZWxmX2xv
YWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxZWViMDAwIC0+IDB4ZmZmZmZmZmY4
MWVmZjA0MA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIGVsZl9sb2FkX2JpbmFyeTog
cGhkciAzIGF0IDB4ZmZmZmZmZmY4MWYwMDAwMCAtPiAweGZmZmZmZmZmODFmZmYwMDANCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAwLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4
MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDEwLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MTgsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDMwLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NDgsIHJvb3QgdGFi
bGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg1MCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCByb290IHRhYmxlID0gMHgy
NDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4NjgsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEz
OjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwLCBy
b290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4OTIsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0YWJs
ZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDlhLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAsIHJvb3QgdGFibGUgPSAweDI0
N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHhhMSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEzLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6
NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTQsIHJv
b3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhNSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE4LCByb290IHRhYmxl
ID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4YjAsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMiwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjUwXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4wDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gc2V0dXAgMDAwMDowMDoxOC4wIGZvciBkMCBm
YWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IE5vIGlv
bW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1
MF0gc2V0dXAgMDAwMDowMDoxOC4xIGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDox
OC4yDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MV0gc2V0dXAgMDAwMDowMDoxOC4yIGZv
ciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6
IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoxMzo1MV0gc2V0dXAgMDAwMDowMDoxOC4zIGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAw
MDowMDoxOC40DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MV0gc2V0dXAgMDAwMDowMDox
OC40IGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDQwMCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDUwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMSwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDYwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDgwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEz
OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweGIwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGMwMCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uZG9uZS4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUzXSBJbml0aWFsIGxvdyBt
ZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjUzXSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjUzXSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo1M10gWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoxMzo1M10gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEn
IHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo1M10gRnJlZWQgMjQ4a0IgaW5pdCBtZW1vcnkuDQptYXBwaW5nIGtlcm5lbCBp
bnRvIHBoeXNpY2FsIG1lbW9yeQ0KYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NClsgICAgMC4w
MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAwMDAw
MF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBMaW51
eCB2ZXJzaW9uIDMuOC4wLXJjMC0yMDEzMDIyNSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdj
YyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBNb24g
RmViIDI1IDIwOjMyOjQ0IENFVCAyMDEzDQpbICAgIDAuMDAwMDAwXSBGcmVlaW5nIDlmLTEw
MCBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGZyZWVkDQpbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCA5
NyBwYWdlcyBvZiB1bnVzZWQgbWVtb3J5DQpbICAgIDAuMDAwMDAwXSBTZXQgMzI3ODg5IHBh
Z2UocykgdG8gMS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFBvcHVsYXRpbmcgNDAwMDAt
NDAwNjEgcGZuIHJhbmdlOiA5NyBwYWdlcyBhZGRlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDog
QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVmZmZdIHVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZjAwMC0weDAwMDAwMDAwMDAw
ZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAw
MTAwMDAwLTB4MDAwMDAwMDA0MDA2MGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAwMDBhZmY4ZmZmZl0gdW51c2FibGUN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYWZmOTAwMDAtMHgwMDAwMDAw
MGFmZjlkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwYWZmOWUwMDAtMHgwMDAwMDAwMGFmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmZlMDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4
MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAwMDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAw
LjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBm
ZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAw
MDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjog
W21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0K
WyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBlbmFibGVkDQpbICAgIDAu
MDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNClsgICAg
MC4wMDAwMDBdIGU4MjA6IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAw
LjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAwMDll
ZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDlm
MDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6
IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0gdXNhYmxlDQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA0MDA2MTAwMC0weDAwMDAwMDAw
YWZmOGZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAw
MDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAw
MF0gdXNlcjogW21lbSAweDAwMDAwMDAwYWZmOWUwMDAtMHgwMDAwMDAwMGFmZmRmZmZmXSBB
Q1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwYWZmZTAwMDAt
MHgwMDAwMDAwMGFmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAwMDAwMGZl
YzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAw
ZmVlMDAwMDAtMHgwMDAwMDAwMGZlZTAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
dXNlcjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNl
cnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgw
MDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gU01CSU9TIDIuNSBw
cmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBNU0kgTVMtNzY0MC84OTBGWEEtR0Q3MCAo
TVMtNzY0MCkgICwgQklPUyBWMS44QjEgMDkvMTMvMjAxMA0KWyAgICAwLjAwMDAwMF0gZTgy
MDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXSB1c2FibGUgPT0+IHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAwLTB4MDAw
ZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZA0KWyAg
ICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3BmbiA9IDB4
NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTY2FubmluZyAxIGFyZWFzIGZvciBsb3cgbWVt
b3J5IGNvcnJ1cHRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBm
YjEwMCAwMDAxNCAodjAwIEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQgMDAw
MDAwMDBhZmY5MDAwMCAwMDA0OCAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZU
IDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMGFmZjkwMjAw
IDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAgMDk0MjcgKHYwMSAg
QTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNClsgICAgMC4wMDAwMDBd
IEFDUEk6IEZBQ1MgMDAwMDAwMDBhZmY5ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQ
STogQVBJQyAwMDAwMDAwMGFmZjkwMzkwIDAwMDg4ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIw
MTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAw
MDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAw
MDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNMSUMgMDAwMDAwMDBhZmY5MDQ2MCAw
MDE3NiAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogT0VNQiAwMDAwMDAwMGFmZjllMDQwIDAwMDcyICh2MDEgNzY0
ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1ZTAgMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAg
MDAwMDAwMDIgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAw
MDAwMDBhZmY5YTZmMCAwMDAzOCAodjAxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZU
IDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVZSUyAwMDAwMDAwMGFmZjlhNzMw
IDAwMTAwICh2MDEgIEFNRCAgICAgUkQ4OTBTIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBB
IE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBd
IEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBC
YXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAwXSA5OTAwMCBzaXpl
IDI0NTc2DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAw
MDAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgw
MDBmZmZmZl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzog
W21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDNm
ZTAwMDAwLTB4M2ZmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBdIEJSSyBbMHgwMjk2
NDAwMCwgMHgwMjk2NGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlf
bWFwcGluZzogW21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAg
W21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBdIEJS
SyBbMHgwMjk2NTAwMCwgMHgwMjk2NWZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gQlJL
IFsweDAyOTY2MDAwLCAweDAyOTY2ZmZmXSBQR1RBQkxFDQpbICAgIDAuMDAwMDAwXSBCUksg
WzB4MDI5NjcwMDAsIDB4MDI5NjdmZmZdIFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIEJSSyBb
MHgwMjk2ODAwMCwgMHgwMjk2OGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gaW5pdF9t
ZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSAgW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAw
MDBdIFJBTURJU0s6IFttZW0gMHgwMmQ3MDAwMC0weDAzYTFiZmZmXQ0KWyAgICAwLjAwMDAw
MF0gTlVNQSB0dXJuZWQgb2ZmDQpbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IFtt
ZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0NClsgICAgMC4wMDAw
MDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIFttZW0gMHgwMDAwMDAwMC0weDNmZmZmZmZmXQ0K
WyAgICAwLjAwMDAwMF0gICBOT0RFX0RBVEEgW21lbSAweDNmZTFhMDAwLTB4M2ZlMjRmZmZd
DQpbICAgIDAuMDAwMDAwXSBab25lIHJhbmdlczoNClsgICAgMC4wMDAwMDBdICAgRE1BICAg
ICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIERNQTMy
ICAgIFttZW0gMHgwMTAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBOb3Jt
YWwgICBlbXB0eQ0KWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNo
IG5vZGUNClsgICAgMC4wMDAwMDBdIEVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcw0KWyAgICAw
LjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMDAxMDAwLTB4MDAwOWVmZmZdDQpbICAg
IDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgzZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNjIwNDYNClsgICAgMC4wMDAw
MDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAw
MF0gICBETUEgem9uZTogMjEgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdICAgRE1B
IHpvbmU6IDM5OTggcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAwMDAwMF0gICBETUEz
MiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiB6b25lOiAyNTgwNDggcGFnZXMsIExJRk8gYmF0Y2g6MzENClsgICAgMC4wMDAwMDBd
IEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
b2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQp
DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsw
eDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
NF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
WyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAw
MDBdIGdzaV9iYXNlWzBdKQ0KWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDYs
IHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNClsgICAgMC4wMDAw
MDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFz
ZVsyNF0pDQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAz
MywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNClsgICAgMC4wMDAwMDBdIEFDUEk6
IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2Jh
bF9pcnEgOSBsb3cgbGV2ZWwpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkg
b3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUu
DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQpbICAgIDAu
MDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3Jt
YXRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZl
ZDAwMDAwDQpbICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA2IENQVXMsIDAgaG90
cGx1ZyBDUFVzDQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNzINClsgICAgMC4wMDAw
MDBdIGU4MjA6IFttZW0gMHhiMDAwMDAwMC0weGZlYmZmZmZmXSBhdmFpbGFibGUgZm9yIFBD
SSBkZXZpY2VzDQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu
ZWwgb24gWGVuDQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4zLXVuc3RhYmxlIChw
cmVzZXJ2ZS1BRCkNClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5y
X2NwdW1hc2tfYml0czo4IG5yX2NwdV9pZHM6NiBucl9ub2RlX2lkczoxDQpbICAgIDAuMDAw
MDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2VzL2NwdSBAZmZmZjg4MDAzZjgwMDAwMCBz
ODE5ODQgcjgxOTIgZDI0NTEyIHUyNjIxNDQNClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6
IHM4MTk4NCByODE5MiBkMjQ1MTIgdTI2MjE0NCBhbGxvYz0xKjIwOTcxNTINClsgICAgMC4w
MDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIDEgMiAzIDQgNSAtIC0gDQpbICAgIDQuMjQwMTU2
XSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBv
bi4gIFRvdGFsIHBhZ2VzOiAyNTc5MjkNClsgICAgNC4yNDAxNTldIFBvbGljeSB6b25lOiBE
TUEzMg0KWyAgICA0LjI0MDM0NV0gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3Jk
ZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KWyAgICA0LjI0MDM1MV0gX19leF90YWJsZSBhbHJlYWR5
IHNvcnRlZCwgc2tpcHBpbmcgc29ydA0KWyAgICA0LjI4MjY5OV0gc29mdHdhcmUgSU8gVExC
IFttZW0gMHgzYTYwMDAwMC0weDNlNjAwMDAwXSAoNjRNQikgbWFwcGVkIGF0IFtmZmZmODgw
MDNhNjAwMDAwLWZmZmY4ODAwM2U1ZmZmZmZdDQpbICAgIDQuMjg3OTE3XSBNZW1vcnk6IDky
MTc4NGsvMTA0ODU3NmsgYXZhaWxhYmxlICgxMDA0N2sga2VybmVsIGNvZGUsIDM5MmsgYWJz
ZW50LCAxMjY0MDBrIHJlc2VydmVkLCA1MjIwayBkYXRhLCAxMDcyayBpbml0KQ0KWyAgICA0
LjI4ODIyMV0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWlu
T2JqZWN0cz0wLCBDUFVzPTYsIE5vZGVzPTENClsgICAgNC4yODgzMzJdIFByZWVtcHRpYmxl
IGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDQuMjg4MzM0XSAJUkNV
IGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQpb
ICAgIDQuMjg4MzM2XSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRlZCB3aXRoIHN0
YWxscy4NClsgICAgNC4yODgzMzhdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQ
VVM9OCB0byBucl9jcHVfaWRzPTYuDQpbICAgIDQuMjg4Mzg0XSBOUl9JUlFTOjQzNTIgbnJf
aXJxczoxMjcyIDE2DQpbICAgIDQuMjg4NTIzXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFs
X2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0xDQpbICAgIDQuMjg4NTI2XSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSA5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDQuMjg4NTYwXSB4
ZW46IC0tPiBwaXJxPTkgLT4gaXJxPTkgKGdzaT05KQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MTM6NTNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAt
PiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQpbICAgIDQuMjg4NTgzXSB4ZW46IGFjcGkgc2Np
IDkNClsgICAgNC4yODg1OTBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpDQpb
ICAgIDQuMjg4NTk3XSB4ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIgKGdzaT0yKQ0KWyAgICA0
LjI4ODYwM10geGVuOiAtLT4gcGlycT0zIC0+IGlycT0zIChnc2k9MykNClsgICAgNC4yODg2
MTBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpDQpbICAgIDQuMjg4NjE2XSB4
ZW46IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQ0KWyAgICA0LjI4ODYyM10geGVuOiAt
LT4gcGlycT02IC0+IGlycT02IChnc2k9NikNClsgICAgNC4yODg2MjldIHhlbjogLS0+IHBp
cnE9NyAtPiBpcnE9NyAoZ3NpPTcpDQpbICAgIDQuMjg4NjM2XSB4ZW46IC0tPiBwaXJxPTgg
LT4gaXJxPTggKGdzaT04KQ0KWyAgICA0LjI4ODY0Ml0geGVuOiAtLT4gcGlycT0xMCAtPiBp
cnE9MTAgKGdzaT0xMCkNClsgICAgNC4yODg2NDldIHhlbjogLS0+IHBpcnE9MTEgLT4gaXJx
PTExIChnc2k9MTEpDQpbICAgIDQuMjg4NjU2XSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0x
MiAoZ3NpPTEyKQ0KWyAgICA0LjI4ODY2Ml0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMg
KGdzaT0xMykNClsgICAgNC4yODg2NjldIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0IChn
c2k9MTQpDQpbICAgIDQuMjg4Njc1XSB4ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAoZ3Np
PTE1KQ0KWyAgICA0LjI4ODc0Nl0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgy
NQ0KWyAgICA0LjI4ODc1MF0gY29uc29sZSBbdHR5MF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUg
ZGlzYWJsZWQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw
dXNldA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpb
ICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9uIDMuOC4wLXJjMC0yMDEzMDIyNSAocm9vdEBz
ZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAj
MSBTTVAgUFJFRU1QVCBNb24gRmViIDI1IDIwOjMyOjQ0IENFVCAyMDEzDQpbICAgIDAuMDAw
MDAwXSBGcmVlaW5nIDlmLTEwMCBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGZyZWVkDQpbICAgIDAu
MDAwMDAwXSAxLTEgbWFwcGluZyBvbiA5Zi0+MTAwDQpbICAgIDAuMDAwMDAwXSAxLTEgbWFw
cGluZyBvbiBhZmY5MC0+MTAwMDAwDQpbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCA5NyBwYWdl
cyBvZiB1bnVzZWQgbWVtb3J5DQpbICAgIDAuMDAwMDAwXSBTZXQgMzI3ODg5IHBhZ2Uocykg
dG8gMS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFBvcHVsYXRpbmcgNDAwMDAtNDAwNjEg
cGZuIHJhbmdlOiA5NyBwYWdlcyBhZGRlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogQklPUy1w
cm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZjAwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAw
LTB4MDAwMDAwMDA0MDA2MGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAwMDBhZmY4ZmZmZl0gdW51c2FibGUNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYWZmOTAwMDAtMHgwMDAwMDAwMGFmZjlk
ZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYWZm
OWUwMDAtMHgwMDAwMDAwMGFmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBhZmZlMDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4MDAwMDAw
MDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwZmVjMjAwMDAtMHgwMDAwMDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAw
LjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHg0MDAwMDAwMC0weGZmZmZmZmZmZmZmZmZm
ZmVdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBlbmFi
bGVkDQpbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBh
Y3RpdmUNClsgICAgMC4wMDAwMDBdIGU4MjA6IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0g
bWFwOg0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgw
MDAwMDAwMDAwMDllZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4w
MDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDAzZmZmZmZm
Zl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA0MDA2MTAw
MC0weDAwMDAwMDAwYWZmOGZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBb
bWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0K
WyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwYWZmOWUwMDAtMHgwMDAwMDAw
MGFmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAw
MDAwYWZmZTAwMDAtMHgwMDAwMDAwMGFmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAt
MHgwMDAwMDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZTAwZmZmXSByZXNlcnZlZA0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZm
ZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAx
MDAwMDAwMDAtMHgwMDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0g
U01CSU9TIDIuNSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBNU0kgTVMtNzY0MC84
OTBGWEEtR0Q3MCAoTVMtNzY0MCkgICwgQklPUyBWMS44QjEgMDkvMTMvMjAxMA0KWyAgICAw
LjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXSB1c2Fi
bGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAw
MGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRn
ZSBmb3VuZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9h
cmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTY2FubmluZyAxIGFyZWFz
IGZvciBsb3cgbWVtb3J5IGNvcnJ1cHRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAg
MDAwMDAwMDAwMDBmYjEwMCAwMDAxNCAodjAwIEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFD
UEk6IFJTRFQgMDAwMDAwMDBhZmY5MDAwMCAwMDA0OCAodjAxIE1TSSAgICBPRU1TTElDICAy
MDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAw
MDAwMGFmZjkwMjAwIDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAg
MDk0MjcgKHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNClsg
ICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDBhZmY5ZTAwMCAwMDA0MA0KWyAgICAw
LjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGFmZjkwMzkwIDAwMDg4ICh2MDEgNzY0ME1T
IEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAx
MDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNMSUMgMDAwMDAw
MDBhZmY5MDQ2MCAwMDE3NiAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAw
MDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogT0VNQiAwMDAwMDAwMGFmZjllMDQwIDAw
MDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1ZTAgMDAxMDggKHYwMyBBTUQg
ICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFD
UEk6IEhQRVQgMDAwMDAwMDBhZmY5YTZmMCAwMDAzOCAodjAxIDc2NDBNUyBPRU1IUEVUICAy
MDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVZSUyAwMDAw
MDAwMGFmZjlhNzMwIDAwMTAwICh2MDEgIEFNRCAgICAgUkQ4OTBTIDAwMjAyMDMxIEFNRCAg
MDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYWZmOWE4MzAg
MDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAg
IDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAw
XSA5OTAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5n
OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4
MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1v
cnlfbWFwcGluZzogW21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAw
XSAgW21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBd
IEJSSyBbMHgwMjk2NDAwMCwgMHgwMjk2NGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0g
aW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdDQpbICAg
IDAuMDAwMDAwXSAgW21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdIHBhZ2UgNGsNClsgICAg
MC4wMDAwMDBdIEJSSyBbMHgwMjk2NTAwMCwgMHgwMjk2NWZmZl0gUEdUQUJMRQ0KWyAgICAw
LjAwMDAwMF0gQlJLIFsweDAyOTY2MDAwLCAweDAyOTY2ZmZmXSBQR1RBQkxFDQpbICAgIDAu
MDAwMDAwXSBCUksgWzB4MDI5NjcwMDAsIDB4MDI5NjdmZmZdIFBHVEFCTEUNClsgICAgMC4w
MDAwMDBdIEJSSyBbMHgwMjk2ODAwMCwgMHgwMjk2OGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAw
MDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZd
DQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgNGsN
ClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IFttZW0gMHgwMmQ3MDAwMC0weDAzYTFiZmZmXQ0K
WyAgICAwLjAwMDAwMF0gTlVNQSB0dXJuZWQgb2ZmDQpbICAgIDAuMDAwMDAwXSBGYWtpbmcg
YSBub2RlIGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0N
ClsgICAgMC4wMDAwMDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIFttZW0gMHgwMDAwMDAwMC0w
eDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBOT0RFX0RBVEEgW21lbSAweDNmZTFhMDAw
LTB4M2ZlMjRmZmZdDQpbICAgIDAuMDAwMDAwXSBab25lIHJhbmdlczoNClsgICAgMC4wMDAw
MDBdICAgRE1BICAgICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSAgIERNQTMyICAgIFttZW0gMHgwMTAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjAw
MDAwMF0gICBOb3JtYWwgICBlbXB0eQ0KWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0
YXJ0IGZvciBlYWNoIG5vZGUNClsgICAgMC4wMDAwMDBdIEVhcmx5IG1lbW9yeSBub2RlIHJh
bmdlcw0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMDAxMDAwLTB4MDAw
OWVmZmZdDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgz
ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNjIwNDYN
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgWyAgICA3LjM0MTE5NF0gcGNpYmFjayAwMDAwOjA0OjAwLjA6IHJlc3RvcmluZyBjb25m
aWcgc3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwgd3JpdGluZyAweDEwYSkNClsg
ICAgNy4zNDc4MDhdIHBjaWJhY2sgMDAwMDowNDowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNw
YWNlIGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5nIDB4Zjk4ZmUwMDQpDQpbICAg
IDcuMzU0MzYzXSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFj
ZSBhdCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4MTApDQpbICAgIDcuMzYwODMx
XSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZz
ZXQgMHg0ICh3YXMgMHgxMDAwMDAsIHdyaXRpbmcgMHgxMDAxMDIpDQpbICAgIDcuMzY3Mzc5
XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAg
ICA3LjM3Mzc3N10geGVuOiAtLT4gcGlycT0zMyAtPiBpcnE9MzMgKGdzaT0zMykNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjU2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy05IC0+IDB4YTEgLT4gSVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkNClsgICAgNy40MDQ3
NjhdIHBjaWJhY2sgMDAwMDowNTowMC4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAw
MykNClsgICAgNy40MTEwNzFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMyIHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQpbICAgIDcuNDE3NDQ1XSB4ZW46IC0tPiBwaXJxPTMyIC0+IGlycT0z
MiAoZ3NpPTMyKQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTZdIElPQVBJQ1sxXTogU2V0
IFBDSSByb3V0aW5nIGVudHJ5ICg3LTggLT4gMHhhOSAtPiBJUlEgMzIgTW9kZToxIEFjdGl2
ZToxKQ0KWyAgICA3LjQ0ODExOF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDcgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDENClsgICAgNy40NTQ0NjJdIHhlbjogLS0+IHBpcnE9NDcgLT4gaXJx
PTQ3IChnc2k9NDcpDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1Nl0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhiMSAtPiBJUlEgNDcgTW9kZToxIEFj
dGl2ZToxKQ0KWyAgICA3LjY2NDY5MV0gcGNpYmFjayAwMDAwOjA2OjAwLjA6IHJlc3Rvcmlu
ZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwgd3JpdGluZyAweDEw
YSkNClsgICAgNy42NzExODNdIHBjaWJhY2sgMDAwMDowNjowMC4wOiByZXN0b3JpbmcgY29u
ZmlnIHNwYWNlIGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5nIDB4ZjlhMDAwMDQp
DQpbICAgIDcuNjc3NTk5XSBwY2liYWNrIDAwMDA6MDY6MDAuMDogcmVzdG9yaW5nIGNvbmZp
ZyBzcGFjZSBhdCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4MTApDQpbICAgIDcu
NjgzOTMyXSBwY2liYWNrIDAwMDA6MDY6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHg0ICh3YXMgMHgxMDAwMDAsIHdyaXRpbmcgMHgxMDAxMDYpDQpbICAgIDcu
NjkwNDQ0XSB4ZW4tcGNpYmFjazogYmFja2VuZCBpcyB2cGNpDQpbICAgIDcuNjk2NjUyXSBi
dXM6ICd4ZW4tYmFja2VuZCc6IGFkZCBkcml2ZXIgeGVuLXBjaWJhY2sNClsgICAgNy43MTU3
MjJdIGRldmljZTogJ3hlbiFwcml2Y21kJzogZGV2aWNlX2FkZA0KWyAgICA3LjcyMjA2MV0g
UE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6eGVuIXByaXZjbWQNClsgICAgNy43NjA0Mzhd
IGRldmljZTogJ3B0bXgnOiBkZXZpY2VfYWRkDQpbICAgIDcuNzY2ODIyXSBQTTogQWRkaW5n
IGluZm8gZm9yIE5vIEJ1czpwdG14DQpbICAgIDcuNzk4MTMyXSBkZXZpY2U6ICdodmMwJzog
ZGV2aWNlX2FkZA0KWyAgICA3LjgwNDM0MF0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6
aHZjMA0KWyAgICA3LjgxMDgxNV0gZGV2aWNlOiAnaHZjMSc6IGRldmljZV9hZGQNClsgICAg
Ny44MTcwMDddIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmh2YzENClsgICAgNy44MjM1
MjBdIGRldmljZTogJ2h2YzInOiBkZXZpY2VfYWRkDQpbICAgIDcuODI5NjI3XSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czpodmMyDQpbICAgIDcuODM1OTk3XSBkZXZpY2U6ICdodmMz
JzogZGV2aWNlX2FkZA0KWyAgICA3Ljg0MjA4OV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBC
dXM6aHZjMw0KWyAgICA3Ljg0ODM1MV0gZGV2aWNlOiAnaHZjNCc6IGRldmljZV9hZGQNClsg
ICAgNy44NTQ0NjNdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmh2YzQNClsgICAgNy44
NjA3MzFdIGRldmljZTogJ2h2YzUnOiBkZXZpY2VfYWRkDQpbICAgIDcuODY2NjgyXSBQTTog
QWRkaW5nIGluZm8gZm9yIE5vIEJ1czpodmM1DQpbICAgIDcuODcyOTAwXSBkZXZpY2U6ICdo
dmM2JzogZGV2aWNlX2FkZA0KWyAgICA3Ljg3ODgyM10gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6aHZjNg0KWyAgICA3Ljg4NDk2Ml0gZGV2aWNlOiAnaHZjNyc6IGRldmljZV9hZGQN
ClsgICAgNy44OTA4MDddIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmh2YzcNClsgICAg
Ny44OTY4NzhdIGJ1czogJ3hlbic6IGFkZCBkcml2ZXIgeGVuY29uc29sZQ0KWyAgICA3Ljkx
NDI2NV0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcg
ZW5hYmxlZA0KWyAgICA3LjkyMDA0OV0gYnVzOiAncG5wJzogYWRkIGRyaXZlciBzZXJpYWwN
ClsgICAgNy45MjU3NTJdIGJ1czogJ3BucCc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNo
ZWQgZGV2aWNlIDAwOjA2IHdpdGggZHJpdmVyIHNlcmlhbA0KWyAgICA3LjkzMTQ4OF0gYnVz
OiAncG5wJzogcmVhbGx5X3Byb2JlOiBwcm9iaW5nIGRyaXZlciBzZXJpYWwgd2l0aCBkZXZp
Y2UgMDA6MDYNClsgICAgNy45Mzc0NDRdIGRldmljZTogJ3R0eVMwJzogZGV2aWNlX2FkZA0K
WyAgICA3Ljk0MzUxM10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6dHR5UzANClsgICAg
Ny45NDk3MzhdIGRyaXZlcjogJzAwOjA2JzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZp
Y2UgJ3NlcmlhbCcNClsgICAgNy45NTU1MDJdIGJ1czogJ3BucCc6IHJlYWxseV9wcm9iZTog
Ym91bmQgZGV2aWNlIDAwOjA2IHRvIGRyaXZlciBzZXJpYWwNClsgICAgNy45NjE2MjNdIFJl
Z2lzdGVyaW5nIHBsYXRmb3JtIGRldmljZSAnc2VyaWFsODI1MCcuIFBhcmVudCBhdCBwbGF0
Zm9ybQ0KWyAgICA3Ljk2NzQzNl0gZGV2aWNlOiAnc2VyaWFsODI1MCc6IGRldmljZV9hZGQN
ClsgICAgNy45NzMyNDldIGJ1czogJ3BsYXRmb3JtJzogYWRkIGRldmljZSBzZXJpYWw4MjUw
DQpbICAgIDcuOTc5MTE3XSBQTTogQWRkaW5nIGluZm8gZm9yIHBsYXRmb3JtOnNlcmlhbDgy
NTANClsgICAgNy45ODUyNDhdIGRldmljZTogJ3R0eVMxJzogZGV2aWNlX2FkZA0KWyAgICA3
Ljk5MTIxM10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6dHR5UzENClsgICAgNy45OTc0
MjJdIGRldmljZTogJ3R0eVMyJzogZGV2aWNlX2FkZA0KWyAgICA4LjAwMzI2NV0gUE06IEFk
ZGluZyBpbmZvIGZvciBObyBCdXM6dHR5UzINClsgICAgOC4wMDkzODNdIGRldmljZTogJ3R0
eVMzJzogZGV2aWNlX2FkZA0KWyAgICA4LjAxNTI0M10gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6dHR5UzMNClsgICAgOC4wMjEyODRdIGJ1czogJ3BsYXRmb3JtJzogYWRkIGRyaXZl
ciBzZXJpYWw4MjUwDQpbICAgIDguMDI2ODU0XSBidXM6ICdwbGF0Zm9ybSc6IGRyaXZlcl9w
cm9iZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIHNlcmlhbDgyNTAgd2l0aCBkcml2ZXIgc2Vy
aWFsODI1MA0KWyAgICA4LjAzMjU4Nl0gYnVzOiAncGxhdGZvcm0nOiByZWFsbHlfcHJvYmU6
IHByb2JpbmcgZHJpdmVyIHNlcmlhbDgyNTAgd2l0aCBkZXZpY2Ugc2VyaWFsODI1MA0KWyAg
ICA4LjAzODM2M10gZHJpdmVyOiAnc2VyaWFsODI1MCc6IGRyaXZlcl9ib3VuZDogYm91bmQg
dG8gZGV2aWNlICdzZXJpYWw4MjUwJw0KWyAgICA4LjA0NDE5N10gYnVzOiAncGxhdGZvcm0n
OiByZWFsbHlfcHJvYmU6IGJvdW5kIGRldmljZSBzZXJpYWw4MjUwIHRvIGRyaXZlciBzZXJp
YWw4MjUwDQpbICAgIDguMDYyMTc2XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIHNlcmlhbA0K
WyAgICA4LjA5MTcyNF0gZGV2aWNlOiAnaHBldCc6IGRldmljZV9hZGQNClsgICAgOC4wOTc2
MzRdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmhwZXQNClsgICAgOC4xMDM4MzldIGJ1
czogJ2FjcGknOiBhZGQgZHJpdmVyIGhwZXQNClsgICAgOC4xMDk2MjBdIGJ1czogJ2FjcGkn
OiBkcml2ZXJfcHJvYmVfZGV2aWNlOiBtYXRjaGVkIGRldmljZSBQTlAwMTAzOjAwIHdpdGgg
ZHJpdmVyIGhwZXQNClsgICAgOC4xMTU1MjddIGJ1czogJ2FjcGknOiByZWFsbHlfcHJvYmU6
IHByb2JpbmcgZHJpdmVyIGhwZXQgd2l0aCBkZXZpY2UgUE5QMDEwMzowMA0KWyAgICA4LjEy
MTcyNl0gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9DUlMNClsgICAg
OC4xMjc2MzBdIGhwZXQ6IHByb2JlIG9mIFBOUDAxMDM6MDAgcmVqZWN0cyBtYXRjaCAtMTkN
ClsgICAgOC4xNDU4MTBdIGJ1czogJ3BsYXRmb3JtJzogYWRkIGRyaXZlciB0aW1lcmlvbWVt
X3JuZw0KWyAgICA4LjIwMTMzOV0gTGludXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpb
ICAgIDguMjE5ODI1XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIGFncGdhcnQtYW1kNjQNClsg
ICAgOC4yMjY0NDhdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjMyODU2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDowMC4wDQpbICAgIDguMjM5NTM0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4yNDYwNTddIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MDAuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjUyNzE4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDowMC4yDQpbICAgIDguMjU5NTE3XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjAwLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4yNjYyMjZdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTEuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjczMDA2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMS4wDQpbICAgIDguMjgwMDU0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjExLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4yODY4NThdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTIuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjkzNzY2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMi4wDQpbICAgIDguMzAwODAyXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEyLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zMDc3NDldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTIuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzE0ODI4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMi4yDQpbICAgIDguMzIxOTg5XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEyLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zMjkwMjJdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTMuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzM2MTg0XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMy4wDQpbICAgIDguMzQzNjA5XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEzLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zNTA4NTldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTMuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzU4MjMyXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMy4yDQpbICAgIDguMzY1NzQwXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEzLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zNzMyMzBdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzgwODUwXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC4wDQpbICAgIDguMzg4NjIyXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zOTYzMTVdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuMSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDA0MTYyXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC4xDQpbICAgIDguNDEyMTE2XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjEgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40MTk5NDddIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuMyB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDI3ODMxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC4zDQpbICAgIDguNDM1Nzg1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjMgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40NDM2MDhdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuNCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDUxNTQzXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC40DQpbICAgIDguNDU5NjIzXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjQgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40Njc1OTJdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuNSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDc1NjU2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC41DQpbICAgIDguNDgzODkwXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjUgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40OTIwMjRdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTYuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTAwMzQ4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNi4wDQpbICAgIDguNTA4ODQzXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE2LjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41MTcyODJdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTYuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTI1ODI2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNi4yDQpbICAgIDguNTM0NDcxXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE2LjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41NDI5OTNdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTUxNjU4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4wDQpbICAgIDguNTYwNTU1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41NjkyOTldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTc4MTI5XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4xDQpbICAgIDguNTg3MTU0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjEgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41OTU5NjhdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NjA0ODk4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4yDQpbICAgIDguNjEzOTU4XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC42MjI5ODFdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMyB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NjMyMTUyXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4zDQpbICAgIDguNjQxNTQxXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjMgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC42NTA4MDNdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguNCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NjYwMjE5XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC40DQpbICAgIDguNjY5NzU0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjQgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC42NzkxOThdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGM6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
Njg4Nzg4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYzowMC4wDQpbICAgIDguNjk4NDg2XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBjOjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43MDgwMjVdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGE6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NzE3NjQwXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYTowMC4wDQpbICAgIDguNzI3MzI0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBhOjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43MzY4NjBdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGI6MDEuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NzQ2NDcxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYjowMS4wDQpbICAgIDguNzU2MjI2XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBiOjAxLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43NjU3NjVdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGI6MDEuMSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
Nzc1Mzc1XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYjowMS4xDQpbICAgIDguNzg1MDQ1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBiOjAxLjEgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43OTQ1ODBdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGI6MDEuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODA0MTg4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYjowMS4yDQpbICAgIDguODEzODU1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBiOjAxLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC44MjMzODldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDk6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODMyOTkxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowOTowMC4wDQpbICAgIDguODQyNjY5XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjA5OjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC44NTIyMDFdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDg6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODYxODAxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowODowMC4wDQpbICAgIDguODcxNDczXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjA4OjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC44ODEwMDFdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDc6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODkwNTk4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowNzowMC4wDQpbICAgIDguOTAwMjY0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjA3OjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC45MDk4NDldIGJ1czogJ3BjaSc6IHJlbW92ZSBkcml2ZXIgYWdwZ2FydC1hbWQ2NA0K
WyAgICA4LjkxOTU0Ml0gZHJpdmVyOiAnYWdwZ2FydC1hbWQ2NCc6IGRyaXZlcl9yZWxlYXNl
DQpbICAgIDguOTQ3NjM4XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIGFncGdhcnQtaW50ZWwN
ClsgICAgOC45NzU2NzRdIEhhbmdjaGVjazogc3RhcnRpbmcgaGFuZ2NoZWNrIHRpbWVyIDAu
OS4xICh0aWNrIGlzIDE4MCBzZWNvbmRzLCBtYXJnaW4gaXMgNjAgc2Vjb25kcykuDQpbICAg
IDguOTg0ODkwXSBIYW5nY2hlY2s6IFVzaW5nIGdldHJhd21vbm90b25pYygpLg0KWyAgICA5
LjAxMjIwMl0gZGV2aWNlIGNsYXNzICdkcm0nOiByZWdpc3RlcmluZw0KWyAgICA5LjAyMTQz
OF0gW2RybV0gSW5pdGlhbGl6ZWQgZHJtIDEuMS4wIDIwMDYwODEwDQpbICAgIDkuMDQ4MDgx
XSBkZXZpY2U6ICd0dG0nOiBkZXZpY2VfYWRkDQpbICAgIDkuMDU2ODMxXSBQTTogQWRkaW5n
IGluZm8gZm9yIE5vIEJ1czp0dG0NClsgICAgOS4wODI4NDBdIFtkcm1dIFZHQUNPTiBkaXNh
YmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcuDQpbICAgIDkuMDkyNDgyXSBwY2liYWNr
IDAwMDA6MDU6MDAuMDogWyAgIDExLjIyMjU1Ml0gYnVzOiAncGNpJzogcmVhbGx5X3Byb2Jl
OiBib3VuZCBkZXZpY2UgMDAwMDowODowMC4wIHRvIGRyaXZlciByODE2OQ0KWyAgIDExLjI0
NDMzNF0gSW5pdGlhbGlzaW5nIFhlbiB2aXJ0dWFsIGV0aGVybmV0IGRyaXZlci4NClsgICAx
MS4yNTE1MzJdIGJ1czogJ3hlbic6IGFkZCBkcml2ZXIgdmlmDQpbICAgMTEuMjc0NDE4XSBi
dXM6ICd4ZW4tYmFja2VuZCc6IGFkZCBkcml2ZXIgdmlmDQpbICAgMTEuMzEwNzQ2XSBkZXZp
Y2UgY2xhc3MgJ3VzYm1vbic6IHJlZ2lzdGVyaW5nDQpbICAgMTEuMzE4NDI0XSBkZXZpY2U6
ICd1c2Jtb24wJzogZGV2aWNlX2FkZA0KWyAgIDExLjMyNTY1M10gUE06IEFkZGluZyBpbmZv
IGZvciBObyBCdXM6dXNibW9uMA0KWyAgIDExLjM0NzI0N10gZWhjaV9oY2Q6IFVTQiAyLjAg
J0VuaGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZlcg0KWyAgIDExLjM2ODUx
NV0gZWhjaS1wY2k6IEVIQ0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KWyAgIDExLjM3NTU2NF0g
YnVzOiAncGNpJzogYWRkIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDExLjM4MjU3OV0gYnVzOiAn
cGNpJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowMDoxMi4y
IHdpdGggZHJpdmVyIGVoY2ktcGNpDQpbICAgMTEuMzg5Njk3XSBidXM6ICdwY2knOiByZWFs
bHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2aWNlIDAwMDA6MDA6
MTIuMg0KWyAgIDExLjM5Njg2N10geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDENClsgICAxMS40MDM5ODBdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTcNClsgICAxMS40MTExMDddIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgYnVz
IG1hc3RlcmluZw0KWyAgIDExLjQxODE5Ml0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBFSENJ
IEhvc3QgQ29udHJvbGxlcg0KWyAgIDExLjQyNTM3Ml0gZGV2aWNlOiAndXNibW9uMSc6IGRl
dmljZV9hZGQNClsgICAxMS40MzI1ODBdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnVz
Ym1vbjENClsgICAxMS40Mzk4NDBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpbICAgMTEuNDQ2ODQ0XSBR
VUlSSzogRW5hYmxlIEFNRCBQTEwgZml4DQpbICAgMTEuNDUzNzUwXSBlaGNpLXBjaSAwMDAw
OjAwOjEyLjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVt
bXkgcWggd29ya2Fyb3VuZA0KWyAgIDExLjQ2MDg1Ml0gZWhjaS1wY2kgMDAwMDowMDoxMi4y
OiBkZWJ1ZyBwb3J0IDENClsgICAxMS40Njc5NDRdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjog
ZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTEuNDc1MDIwXSBlaGNpLXBjaSAwMDAwOjAw
OjEyLjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmY0MDANClsgICAxMS40OTEyOTZdIGVoY2kt
cGNpIDAwMDA6MDA6MTIuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDANClsgICAxMS40
OTg0MDVdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2Yiwg
aWRQcm9kdWN0PTAwMDINClsgICAxMS41MDUxNzZdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmlj
ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDExLjUx
MTk3M10gdXNiIHVzYjE6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgMTEu
NTE4NzI3XSB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAy
MjUgZWhjaV9oY2QNClsgICAxMS41MjU1NjJdIHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAw
MDA6MDA6MTIuMg0KWyAgIDExLjUzMjM1Ml0gZGV2aWNlOiAndXNiMSc6IGRldmljZV9hZGQN
ClsgICAxMS41Mzk0NzVdIGJ1czogJ3VzYic6IGFkZCBkZXZpY2UgdXNiMQ0KWyAgIDExLjU0
NjE3N10gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6dXNiMQ0KWyAgIDExLjU1MzAxOV0gYnVz
OiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgdXNiMSB3aXRo
IGRyaXZlciB1c2INClsgICAxMS41NTk1OTRdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTog
cHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNlIHVzYjENClsgICAxMS41NjYzMTJdIGRl
dmljZTogJzEtMDoxLjAnOiBkZXZpY2VfYWRkDQpbICAgMTEuNTcyODMxXSBidXM6ICd1c2In
OiBhZGQgZGV2aWNlIDEtMDoxLjANClsgICAxMS41NzkyOTddIFBNOiBBZGRpbmcgaW5mbyBm
b3IgdXNiOjEtMDoxLjANClsgICAxMS41ODU5MzhdIGJ1czogJ3VzYic6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDEtMDoxLjAgd2l0aCBkcml2ZXIgaHViDQpbICAg
MTEuNTkyNDEwXSBidXM6ICd1c2InOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGh1
YiB3aXRoIGRldmljZSAxLTA6MS4wDQpbICAgMTEuNTk4OTM0XSBodWIgMS0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KWyAgIDExLjYwNTQxMV0gaHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0
ZWQNClsgICAxMS42MTE5NjBdIGRldmljZTogJ3BvcnQxJzogZGV2aWNlX2FkZA0KWyAgIDEx
LjYxODM5Nl0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDENClsgICAxMS42MjQ2
OTVdIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2FkZA0KWyAgIDExLjYzMDkwM10gUE06IEFk
ZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsgICAxMS42MzcwMjNdIGRldmljZTogJ3Bv
cnQzJzogZGV2aWNlX2FkZA0KWyAgIDExLjY0MzA3M10gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6cG9ydDMNClsgICAxMS42NDkwNDZdIGRldmljZTogJ3BvcnQ0JzogZGV2aWNlX2Fk
ZA0KWyAgIDExLjY1NDkzOF0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDQNClsg
ICAxMS42NjA4MjBdIGRldmljZTogJ3BvcnQ1JzogZGV2aWNlX2FkZA0KWyAgIDExLjY2NjY3
OF0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDUNClsgICAxMS42NzI2MDRdIGRy
aXZlcjogJzEtMDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0K
WyAgIDExLjY3ODQ3OF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
MS0wOjEuMCB0byBkcml2ZXIgaHViDQpbICAgMTEuNjg0NDA2XSBkZXZpY2U6ICdlcF84MSc6
IGRldmljZV9hZGQNClsgICAxMS42OTAzMzJdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVz
OmVwXzgxDQpbICAgMTEuNjk2MTMxXSBkcml2ZXI6ICd1c2IxJzogZHJpdmVyX2JvdW5kOiBi
b3VuZCB0byBkZXZpY2UgJ3VzYicNClsgICAxMS43MDIwMTZdIGJ1czogJ3VzYic6IHJlYWxs
eV9wcm9iZTogYm91bmQgZGV2aWNlIHVzYjEgdG8gZHJpdmVyIHVzYg0KWyAgIDExLjcwNzkz
Ml0gZGV2aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTEuNzEzODYxXSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDExLjcxOTg4Ml0gZHJpdmVyOiAnMDAw
MDowMDoxMi4yJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ2VoY2ktcGNpJw0K
WyAgIDExLjcyNTg5N10gYnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
MDAwMDowMDoxMi4yIHRvIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDExLjczMTkzMV0gYnVzOiAn
cGNpJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowMDoxMy4y
IHdpdGggZHJpdmVyIGVoY2ktcGNpDQpbICAgMTEuNzM4MDAxXSBidXM6ICdwY2knOiByZWFs
bHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2aWNlIDAwMDA6MDA6
MTMuMg0KWyAgIDExLjc0NDE0NV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDENClsgICAxMS43NTAyMTddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTcNClsgICAxMS43NTY0NjldIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZW5hYmxpbmcgYnVz
IG1hc3RlcmluZw0KWyAgIDExLjc2MjU4Nl0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBFSENJ
IEhvc3QgQ29udHJvbGxlcg0KWyAgIDExLjc2ODc2M10gZGV2aWNlOiAndXNibW9uMic6IGRl
dmljZV9hZGQNClsgICAxMS43NzUwMDNdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnVz
Ym1vbjINClsgICAxMS43ODEzODBdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyDQpbICAgMTEuNzg3NDE1XSBl
aGNpLXBjaSAwMDAwOjAwOjEzLjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24t
Mi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDExLjc5MzUzN10gZWhjaS1wY2kg
MDAwMDowMDoxMy4yOiBkZWJ1ZyBwb3J0IDENClsgICAxMS43OTk2OTRdIGVoY2ktcGNpIDAw
MDA6MDA6MTMuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTEuODA1NzczXSBlaGNp
LXBjaSAwMDAwOjAwOjEzLjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmY4MDANClsgICAxMS44
MjEyOTddIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEu
MDANClsgICAxMS44Mjc0NzddIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRW
ZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxMS44MzM0NzFdIHVzYiB1c2IyOiBO
ZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9
MQ0KWyAgIDExLjgzOTQ1NF0gdXNiIHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9s
bGVyDQpbICAgMTEuODQ1MzE0XSB1c2IgdXNiMjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjgu
MC1yYzAtMjAxMzAyMjUgZWhjaV9oY2QNClsgICAxMS44NTExODldIHVzYiB1c2IyOiBTZXJp
YWxOdW1iZXI6IDAwMDA6MDA6MTMuMg0KWyAgIDExLjg1NzA4OF0gZGV2aWNlOiAndXNiMic6
IGRldmljZV9hZGQNClsgICAxMS44NjMyNThdIGJ1czogJ3VzYic6IGFkZCBkZXZpY2UgdXNi
Mg0KWyAgIDExLjg2OTIyMF0gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6dXNiMg0KWyAgIDEx
Ljg3NTM3NV0gYnVzOiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZp
Y2UgdXNiMiB3aXRoIGRyaXZlciB1c2INClsgICAxMS44ODEzMjldIGJ1czogJ3VzYic6IHJl
YWxseV9wcm9iZTogcHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNlIHVzYjINClsgICAx
MS44ODcyOTFdIGRldmljZTogJzItMDoxLjAnOiBkZXZpY2VfYWRkDQpbICAgMTEuODkzMjYz
XSBidXM6ICd1c2InOiBhZGQgZGV2aWNlIDItMDoxLjANClsgICAxMS44OTkxMjhdIFBNOiBB
ZGRpbmcgaW5mbyBmb3IgdXNiOjItMDoxLjANClsgICAxMS45MDUzNzldIGJ1czogJ3VzYic6
IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDItMDoxLjAgd2l0aCBkcml2
ZXIgaHViDQpbICAgMTEuOTExNDYzXSBidXM6ICd1c2InOiByZWFsbHlfcHJvYmU6IHByb2Jp
bmcgZHJpdmVyIGh1YiB3aXRoIGRldmljZSAyLTA6MS4wDQpbICAgMTEuOTE3NTQwXSBodWIg
Mi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDExLjkyMzU1Nl0gaHViIDItMDoxLjA6IDUg
cG9ydHMgZGV0ZWN0ZWQNClsgICAxMS45Mjk1MTVdIGRldmljZTogJ3BvcnQxJzogZGV2aWNl
X2FkZA0KWyAgIDExLjkzNTQwOV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDEN
ClsgICAxMS45NDEyNThdIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2FkZA0KWyAgIDExLjk0
NzEzNV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsgICAxMS45NDcxNThd
IGRldmljZTogJ3BvcnQzJzogZGV2aWNlX2FkZA0KWyAgIDExLjk0NzIwN10gUE06IEFkZGlu
ZyBpbmZvIGZvciBObyBCdXM6cG9ydDMNClsgICAxMS45NDcyMjldIGRldmljZTogJ3BvcnQ0
JzogZGV2aWNlX2FkZA0KWyAgIDExLjk0NzMxNV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBC
dXM6cG9ydDQNClsgICAxMS45NDczMzddIGRldmljZTogJ3BvcnQ1JzogZGV2aWNlX2FkZA0K
WyAgIDExLjk0NzM4NV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDUNClsgICAx
MS45NDc0OTZdIGRyaXZlcjogJzItMDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRl
dmljZSAnaHViJw0KWyAgIDExLjk0NzQ5OF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBi
b3VuZCBkZXZpY2UgMi0wOjEuMCB0byBkcml2ZXIgaHViDQpbICAgMTEuOTQ3NTE5XSBkZXZp
Y2U6ICdlcF84MSc6IGRldmljZV9hZGQNClsgICAxMS45NDc2MDldIFBNOiBBZGRpbmcgaW5m
byBmb3IgTm8gQnVzOmVwXzgxDQpbICAgMTEuOTQ3NjExXSBkcml2ZXI6ICd1c2IyJzogZHJp
dmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ3VzYicNClsgICAxMS45NDc2MTNdIGJ1czog
J3VzYic6IHJlYWxseV9wcm9iZTogYm91bmQgZGV2aWNlIHVzYjIgdG8gZHJpdmVyIHVzYg0K
WyAgIDExLjk0NzYzMF0gZGV2aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTEuOTQ3
NzA0XSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDExLjk0Nzc4N10g
ZHJpdmVyOiAnMDAwMDowMDoxMy4yJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2Ug
J2VoY2ktcGNpJw0KWyAgIDExLjk0Nzc5MV0gYnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBi
b3VuZCBkZXZpY2UgMDAwMDowMDoxMy4yIHRvIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDExLjk0
Nzc5OF0gYnVzOiAncGNpJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2Ug
MDAwMDowMDoxNi4yIHdpdGggZHJpdmVyIGVoY2ktcGNpDQpbICAgMTEuOTQ3Nzk4XSBidXM6
ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2
aWNlIDAwMDA6MDA6MTYuMg0KWyAgIDExLjk0Nzg1OF0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxMS45NDc4NjFdIEFscmVhZHkgc2V0
dXAgdGhlIEdTSSA6MTcNClsgICAxMS45NDc5MDJdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjog
ZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgIDExLjk0NzkwOV0gZWhjaS1wY2kgMDAwMDow
MDoxNi4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgIDExLjk0Nzk5NV0gZGV2aWNlOiAn
dXNibW9uMyc6IGRldmljZV9hZGQNClsgICAxMS45NDgzMDJdIFBNOiBBZGRpbmcgaW5mbyBm
b3IgTm8gQnVzOnVzYm1vbjMNClsgICAxMS45NDg4NjFdIGVoY2ktcGNpIDAwMDA6MDA6MTYu
MjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQpbICAg
MTEuOTQ4ODc3XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9T
QjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDExLjk0ODkw
NV0gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBkZWJ1ZyBwb3J0IDENClsgICAxMS45NDkwMjhd
IGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTEu
OTQ5MDU1XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmZj
MDANClsgICAxMi4xNzEzMThdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFy
dGVkLCBFSENJIDEuMDANClsgICAxMi4xNzczMjFdIHVzYiB1c2IzOiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxMi4xODMxNDRd
IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MQ0KWyAgIDEyLjE4ODk1Ml0gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kg
SG9zdCBDb250cm9sbGVyDQpbICAgMTIuMTk0Njc5XSB1c2IgdXNiMzogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjUgZWhjaV9oY2QNClsgICAxMi4yMDA0MjJdIHVz
YiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMg0KWyAgIDEyLjIwNjIwNl0gZGV2
aWNlOiAndXNiMyc6IGRldmljZV9hZGQNClsgICAxMi4yMTIyNzVdIGJ1czogJ3VzYic6IGFk
ZCBkZXZpY2UgdXNiMw0KWyAgIDEyLjIxODExNV0gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6
dXNiMw0KWyAgIDEyLjIyNDAxMl0gYnVzOiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTog
bWF0Y2hlZCBkZXZpY2UgdXNiMyB3aXRoIGRyaXZlciB1c2INClsgICAxMi4yMjk4MTddIGJ1
czogJ3VzYic6IHJlYWxseV9wcm9iZTogcHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNl
IHVzYjMNClsgICAxMi4yMzU2ODhdIGRldmljZTogJzMtMDoxLjAnOiBkZXZpY2VfYWRkDQpb
ICAgMTIuMjQxNDkwXSBidXM6ICd1c2InOiBhZGQgZGV2aWNlIDMtMDoxLjANClsgICAxMi4y
NDcyNjddIFBNOiBBZGRpbmcgaW5mbyBmb3IgdXNiOjMtMDoxLjANClsgICAxMi4yNTMyMzdd
IGJ1czogJ3VzYic6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDMtMDox
LjAgd2l0aCBkcml2ZXIgaHViDQpbICAgMTIuMjU5MTEzXSBidXM6ICd1c2InOiByZWFsbHlf
cHJvYmU6IHByb2JpbmcgZHJpdmVyIGh1YiB3aXRoIGRldmljZSAzLTA6MS4wDQpbICAgMTIu
MjY1MDc3XSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDEyLjI3MDk1OF0gaHVi
IDMtMDoxLjA6IDQgcG9ydHMgZGV0ZWN0ZWQNClsgICAxMi4yNzY4MjNdIGRldmljZTogJ3Bv
cnQxJzogZGV2aWNlX2FkZA0KWyAgIDEyLjI4MjU3NV0gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6cG9ydDENClsgICAxMi4yODgzMTldIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2Fk
ZA0KWyAgIDEyLjI5NDEwN10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsg
ICAxMi4yOTk3ODBdIGRldmljZTogJ3BvcnQzJzogZGV2aWNlX2FkZA0KWyAgIDEyLjMwNTQ2
MV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDMNClsgICAxMi4zMTEwNDJdIGRl
dmljZTogJ3BvcnQ0JzogZGV2aWNlX2FkZA0KWyAgIDEyLjMxNjY4MV0gUE06IEFkZGluZyBp
bmZvIGZvciBObyBCdXM6cG9ydDQNClsgICAxMi4zMjIzOTldIGRyaXZlcjogJzMtMDoxLjAn
OiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0KWyAgIDEyLjMyODA5OF0g
YnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMy0wOjEuMCB0byBkcml2
ZXIgaHViDQpbICAgMTIuMzMzODU1XSBkZXZpY2U6ICdlcF84MSc6IGRldmljZV9hZGQNClsg
ICAxMi4zMzk2OTBdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmVwXzgxDQpbICAgMTIu
MzQ1NDI2XSBkcml2ZXI6ICd1c2IzJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2Ug
J3VzYicNClsgICAxMi4zNTEyNTVdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTogYm91bmQg
ZGV2aWNlIHVzYjMgdG8gZHJpdmVyIHVzYg0KWyAgIDEyLjM1NzEzOV0gZGV2aWNlOiAnZXBf
MDAnOiBkZXZpY2VfYWRkDQpbICAgMTIuMzYzMDYwXSBQTTogQWRkaW5nIGluZm8gZm9yIE5v
IEJ1czplcF8wMA0KWyAgIDEyLjM2OTAyOV0gZHJpdmVyOiAnMDAwMDowMDoxNi4yJzogZHJp
dmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ2VoY2ktcGNpJw0KWyAgIDEyLjM3NTA0Ml0g
YnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMDAwMDowMDoxNi4yIHRv
IGRyaXZlciBlaGNpLXBjaQ0KWyAgIDEyLjM4MTA3MF0gYnVzOiAncGNpJzogZHJpdmVyX3By
b2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowYjowMS4yIHdpdGggZHJpdmVyIGVo
Y2ktcGNpDQpbICAgMTIuMzg3MTQzXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2Jp
bmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2aWNlIDAwMDA6MGI6MDEuMg0KWyAgIDEyLjM5
MzI2Nl0geGVuOiByZWdpc3RlcmluZyBnc2kgMzEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
ClsgICAxMi4zOTkzOTFdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzENClsgICAxMi40MDU1
MjJdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAg
IDEyLjQxMTYyMl0gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBFSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgIDEyLjQxNzc3NF0gZGV2aWNlOiAndXNibW9uNCc6IGRldmljZV9hZGQNClsgICAx
Mi40MjQwMDJdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnVzYm1vbjQNClsgICAxMi40
MzAyMzFdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwg
YXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgMTIuNDM2NTU5XSBlaGNpLXBjaSAwMDAwOjBi
OjAxLjI6IGlycSAzMSwgaW8gbWVtIDB4ZjlmZmZjMDANClsgICAxMi40NTEyNjldIGVoY2kt
cGNpIDAwMDA6MGI6MDEuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDANClsgICAxMi40
NTczNzldIHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2Yiwg
aWRQcm9kdWN0PTAwMDINClsgICAxMi40NjMzMzFdIHVzYiB1c2I0OiBOZXcgVVNCIGRldmlj
ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDEyLjQ2
OTI1NF0gdXNiIHVzYjQ6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgMTIu
NDc1MTU2XSB1c2IgdXNiNDogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAy
MjUgZWhjaV9oY2QNClsgICAxMi40ODExNzJdIHVzYiB1c2I0OiBTZXJpYWxOdW1iZXI6IDAw
MDA6MGI6MDEuMg0KWyAgIDEyLjQ4NzEyNF0gZGV2aWNlOiAndXNiNCc6IGRldmljZV9hZGQN
ClsgICAxMi40OTMzNzNdIGJ1czogJ3VzYic6IGFkZCBkZXZpY2UgdXNiNA0KWyAgIDEyLjQ5
OTMwMV0gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6dXNiNA0KWyAgIDEyLjUwNTM0NV0gYnVz
OiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgdXNiNCB3aXRo
IGRyaXZlciB1c2INClsgICAxMi41MTEyNDddIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTog
cHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNlIHVzYjQNClsgICAxMi41MTcyNzVdIGRl
dmljZTogJzQtMDoxLjAnOiBkZXZpY2VfYWRkDQpbICAgMTIuNTIzMjc5XSBidXM6ICd1c2In
OiBhZGQgZGV2aWNlIDQtMDoxLjANClsgICAxMi41MjkyNjVdIFBNOiBBZGRpbmcgaW5mbyBm
b3IgdXNiOjQtMDoxLjANClsgICAxMi41MzU0NzddIGJ1czogJ3VzYic6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDQtMDoxLjAgd2l0aCBkcml2ZXIgaHViDQpbICAg
MTIuNTQxNTg0XSBidXM6ICd1c2InOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGh1
YiB3aXRoIGRldmljZSA0LTA6MS4wDQpbICAgMTIuNTQ3NjM0XSBodWIgNC0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KWyAgIDEyLjU1MzYyMV0gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0
ZWQNClsgICAxMi41NTk2MTddIGRldmljZTogJ3BvcnQxJzogZGV2aWNlX2FkZA0KWyAgIDEy
LjU2NTUyNV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDENClsgICAxMi41NzE0
NzRdIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2FkZA0KWyAgIDEyLjU3NzQzNl0gUE06IEFk
ZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsgICAxMi41ODMzMDhdIGRldmljZTogJ3Bv
cnQzJzogZGV2aWNlX2FkZA0KWyAgIDEyLjU4OTIwNV0gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6cG9ydDMNClsgICAxMi41OTUwMTddIGRldmljZTogJ3BvcnQ0JzogZGV2aWNlX2Fk
ZA0KWyAgIDEyLjYwMDg3N10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDQNClsg
ICAxMi42MDY2ODBdIGRldmljZTogJ3BvcnQ1JzogZGV2aWNlX2FkZA0KWyAgIDEyLjYxMjQz
N10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDUNClsgICAxMi42MTgyNTRdIGRy
aXZlcjogJzQtMDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0K
WyAgIDEyLjYyMzk3MF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
NC0wOjEuMCB0byBkcml2ZXIgaHViDQpbICAgMTIuNjI5ODE0XSBkZXZpY2U6ICdlcF84MSc6
IGRldmljZV9hZGQNClsgICAxMi42MzU2ODFdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVz
OmVwXzgxDQpbICAgMTIuNjQxNDc4XSBkcml2ZXI6ICd1c2I0JzogZHJpdmVyX2JvdW5kOiBi
b3VuZCB0byBkZXZpY2UgJ3VzYicNClsgICAxMi42NDczNzFdIGJ1czogJ3VzYic6IHJlYWxs
eV9wcm9iZTogYm91bmQgZGV2aWNlIHVzYjQgdG8gZHJpdmVyIHVzYg0KWyAgIDEyLjY1MzMw
M10gZGV2aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTIuNjU5MzAwXSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDEyLjY2NTI4Nl0gZHJpdmVyOiAnMDAw
MDowYjowMS4yJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ2VoY2ktcGNpJw0K
WyAgIDEyLjY3MTMwN10gYnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
MDAwMDowYjowMS4yIHRvIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDEyLjY5MDAwOF0gb2hjaV9o
Y2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdlsgICAxNC4w
MDgwOTVdIGRldmljZTogJ3VzYm1vbjEyJzogZGV2aWNlX2FkZA0KWyAgIDE0LjAwODQwMl0g
UE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6dXNibW9uMTINClsgICAxNC4wMDg4ODVdIHho
Y2lfaGNkIDAwMDA6MDc6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQg
YnVzIG51bWJlciAxMg0KWyAgIDE0LjAwOTI5Nl0gdXNiIHVzYjEyOiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDMNClsgICAxNC4wMDkyOTdd
IHVzYiB1c2IxMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9Miwg
U2VyaWFsTnVtYmVyPTENClsgICAxNC4wMDkyOThdIHVzYiB1c2IxMjogUHJvZHVjdDogeEhD
SSBIb3N0IENvbnRyb2xsZXINClsgICAxNC4wMDkyOTldIHVzYiB1c2IxMjogTWFudWZhY3R1
cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjUgeGhjaV9oY2QNClsgICAxNC4wMDkzMDBd
IHVzYiB1c2IxMjogU2VyaWFsTnVtYmVyOiAwMDAwOjA3OjAwLjANClsgICAxNC4wMDkzMDld
IGRldmljZTogJ3VzYjEyJzogZGV2aWNlX2FkZA0KWyAgIDE0LjAwOTYwOV0gYnVzOiAndXNi
JzogYWRkIGRldmljZSB1c2IxMg0KWyAgIDE0LjAwOTY4M10gUE06IEFkZGluZyBpbmZvIGZv
ciB1c2I6dXNiMTINClsgICAxNC4wMTAxNTVdIGJ1czogJ3VzYic6IGRyaXZlcl9wcm9iZV9k
ZXZpY2U6IG1hdGNoZWQgZGV2aWNlIHVzYjEyIHdpdGggZHJpdmVyIHVzYg0KWyAgIDE0LjAx
MDE2MF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBwcm9iaW5nIGRyaXZlciB1c2Igd2l0
aCBkZXZpY2UgdXNiMTINClsgICAxNC4wMTAzMTVdIHhIQ0kgeGhjaV9hZGRfZW5kcG9pbnQg
Y2FsbGVkIGZvciByb290IGh1Yg0KWyAgIDE0LjAxMDMxOF0geEhDSSB4aGNpX2NoZWNrX2Jh
bmR3aWR0aCBjYWxsZWQgZm9yIHJvb3QgaHViDQpbICAgMTQuMDEwMzk1XSBkZXZpY2U6ICcx
Mi0wOjEuMCc6IGRldmljZV9hZGQNClsgICAxNC4wMTA0NzVdIGJ1czogJ3VzYic6IGFkZCBk
ZXZpY2UgMTItMDoxLjANClsgICAxNC4wMTA1MzBdIFBNOiBBZGRpbmcgaW5mbyBmb3IgdXNi
OjEyLTA6MS4wDQpbICAgMTQuMDExMDM0XSBidXM6ICd1c2InOiBkcml2ZXJfcHJvYmVfZGV2
aWNlOiBtYXRjaGVkIGRldmljZSAxMi0wOjEuMCB3aXRoIGRyaXZlciBodWINClsgICAxNC4w
MTEwMzhdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTogcHJvYmluZyBkcml2ZXIgaHViIHdp
dGggZGV2aWNlIDEyLTA6MS4wDQpbICAgMTQuMDExMjE4XSBodWIgMTItMDoxLjA6IFVTQiBo
dWIgZm91bmQNClsgICAxNC4wMTEyNzRdIGh1YiAxMi0wOjEuMDogMiBwb3J0cyBkZXRlY3Rl
ZA0KWyAgIDE0LjAxMTM2NV0gZGV2aWNlOiAncG9ydDEnOiBkZXZpY2VfYWRkDQpbICAgMTQu
MDExNDIwXSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czpwb3J0MQ0KWyAgIDE0LjAxMTQ0
NV0gZGV2aWNlOiAncG9ydDInOiBkZXZpY2VfYWRkDQpbICAgMTQuMDExNDk3XSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czpwb3J0Mg0KWyAgIDE0LjAxMTU2OF0gZHJpdmVyOiAnMTIt
MDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0KWyAgIDE0LjAx
MTU3MF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMTItMDoxLjAg
dG8gZHJpdmVyIGh1Yg0KWyAgIDE0LjAxMTU5MF0gZGV2aWNlOiAnZXBfODEnOiBkZXZpY2Vf
YWRkDQpbICAgMTQuMDExNjczXSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czplcF84MQ0K
WyAgIDE0LjAxMTY3Nl0gZHJpdmVyOiAndXNiMTInOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRv
IGRldmljZSAndXNiJw0KWyAgIDE0LjAxMTY3N10gYnVzOiAndXNiJzogcmVhbGx5X3Byb2Jl
OiBib3VuZCBkZXZpY2UgdXNiMTIgdG8gZHJpdmVyIHVzYg0KWyAgIDE0LjAxMTY5N10gZGV2
aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTQuMDExNzY1XSBQTTogQWRkaW5nIGlu
Zm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDE1LjAyMTU4M10gYnVzOiAndXNiJzogZHJpdmVy
X3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgNS01IHdpdGggZHJpdmVyIHVzYg0KWyAg
IDE1LjAyNzQwOF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBwcm9iaW5nIGRyaXZlciB1
c2Igd2l0aCBkZXZpY2UgNS01DQpbICAgMTUuMDM1Mjc5XSBkZXZpY2U6ICc1LTU6MS4wJzog
ZGV2aWNlX2FkZA0KWyAgIDE1LjAzNTM3M10gZHJpdmVyOiAnMDAwMDowNzowMC4wJzogZHJp
dmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ3hoY2lfaGNkJw0KWyAgIDE1LjAzNTM3Nl0g
YnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMDAwMDowNzowMC4wIHRv
IGRyaXZlciB4aGNpX2hjZA0KWyAgIDE1LjAzNjAxMV0gYnVzOiAndXNiJzogYWRkIGRyaXZl
ciB1c2JscA0KWyAgIDE1LjAzNjMwOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciB1c2JscA0KWyAgIDE1LjAzNjMxM10gSW5pdGlhbGl6aW5nIFVTQiBNYXNz
IFN0b3JhZ2UgZHJpdmVyLi4uDQpbICAgMTUuMDM2MzE1XSBidXM6ICd1c2InOiBhZGQgZHJp
dmVyIHVzYi1zdG9yYWdlDQpbICAgMTUuMDM2Nzg3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQpbICAgMTUuMDM2Nzg4XSBVU0IgTWFz
cyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4NClsgICAxNS4wMzcwMjhdIGJ1czogJ3Vz
Yi1zZXJpYWwnOiByZWdpc3RlcmVkDQpbICAgMTUuMDM3MDQ5XSBidXM6ICd1c2InOiBhZGQg
ZHJpdmVyIHVzYnNlcmlhbA0KWyAgIDE1LjAzNzI4MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JzZXJpYWwNClsgICAxNS4wMzcyOTNdIGJ1czogJ3Vz
Yic6IGFkZCBkcml2ZXIgY3AyMTB4DQpbICAgMTUuMDM3NTI4XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNwMjEweA0KWyAgIDE1LjAzNzU2MV0gYnVzOiAn
dXNiLXNlcmlhbCc6IGFkZCBkcml2ZXIgY3AyMTB4DQpbICAgMTUuMDM4MTM4XSB1c2JzZXJp
YWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBjcDIxMHgNClsgICAxNS4w
MzgxNjhdIGJ1czogJ3VzYic6IGFkZCBkcml2ZXIgY3lwcmVzc19tOA0KWyAgIDE1LjAzODYx
NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjeXByZXNzX204
DQpbICAgMTUuMDM4NjE3XSBidXM6ICd1c2Itc2VyaWFsJzogYWRkIGRyaXZlciBlYXJ0aG1h
dGUNClsgICAxNS4wMzg4MjBdIHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lz
dGVyZWQgZm9yIERlTG9ybWUgRWFydGhtYXRlIFVTQg0KWyAgIDE1LjAzODgyMl0gYnVzOiAn
dXNiLXNlcmlhbCc6IGFkZCBkcml2ZXIgY3lwaGlkY29tDQpbICAgMTUuMDM5MDQzXSB1c2Jz
ZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBISUQtPkNPTSBSUzIz
MiBBZGFwdGVyDQpbICAgMTUuMDM5MDQ2XSBidXM6ICd1c2Itc2VyaWFsJzogYWRkIGRyaXZl
ciBub2tpYWNhNDJ2Mg0KWyAgIDE1LjAzOTI2OF0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcg0KWyAgIDE1LjAz
OTI4N10gYnVzOiAndXNiJzogYWRkIGRyaXZlciBtb3M3NzIwDQpbICAgMTUuMDM5NTE3XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjANClsgICAx
NS4wMzk1MjBdIGJ1czogJ3VzYi1zZXJpYWwnOiBhZGQgZHJpdmVyIG1vc2NoaXA3NzIwDQpb
ICAgMTUuMDM5NzQzXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVk
IGZvciBNb3NjaGlwIDIgcG9ydCBhZGFwdGVyDQpbICAgMTUuMDM5NzYzXSBidXM6ICd1c2In
OiBhZGQgZHJpdmVyIG1vczc4NDANClsgICAxNS4wMzk5OTNdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzg0MA0KWyAgIDE1LjAzOTk5Nl0gYnVzOiAn
dXNiLXNlcmlhbCc6IGFkZCBkcml2ZXIgbW9zNzg0MA0KWyAgIDE1LjA0MDI0MV0gdXNic2Vy
aWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4
MjAgVVNCIFNlcmlhbCBEcml2ZXINClsgICAxNS4wNDAyNjBdIGJ1czogJ3BucCc6IGFkZCBk
cml2ZXIgaTgwNDIga2JkDQpbICAgMTUuMDQwNjY4XSBidXM6ICdwbnAnOiBhZGQgZHJpdmVy
IGk4MDQyIGF1eA0KWyAgIDE1LjA0MDg3Ml0gYnVzOiAncG5wJzogcmVtb3ZlIGRyaXZlciBp
ODA0MiBrYmQNClsgICAxNS4wNDEwMjddIGRyaXZlcjogJ2k4MDQyIGtiZCc6IGRyaXZlcl9y
ZWxlYXNlDQpbICAgMTUuMDQxMDM4XSBidXM6ICdwbnAnOiByZW1vdmUgZHJpdmVyIGk4MDQy
IGF1eA0KWyAgIDE1LjA0MTI2MF0gZHJpdmVyOiAnaTgwNDIgYXV4JzogZHJpdmVyX3JlbGVh
c2UNClsgICAxNS4wNDEyNjRdIGk4MDQyOiBQTlA6IE5vIFBTLzIgY29udHJvbGxlciBmb3Vu
ZC4gUHJvYmluZyBwb3J0cyBkaXJlY3RseS4NClsgICAxNS4wNDEzMTldIFJlZ2lzdGVyaW5n
IHBsYXRmb3JtIGRldmljZSAnaTgwNDInLiBQYXJlbnQgYXQgcGxhdGZvcm0NClsgICAxNS4w
NDEzMjNdIGRldmljZTogJ2k4MDQyJzogZGV2aWNlX2FkZA0KWyAgIDE1LjA0MTM0M10gYnVz
OiAncGxhdGZvcm0nOiBhZGQgZGV2aWNlIGk4MDQyDQpbICAgMTUuMDQxMzc1XSBQTTogQWRk
aW5nIGluZm8gZm9yIHBsYXRmb3JtOmk4MDQyDQpbICAgMTUuMDQxODA0XSBidXM6ICdwbGF0
Zm9ybSc6IGFkZCBkcml2ZXIgaTgwNDINClsgICAxNS4wNDE4MjhdIGJ1czogJ3BsYXRmb3Jt
JzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgaTgwNDIgd2l0aCBkcml2
ZXIgaTgwNDINClsgICAxNS4wNDE4MjhdIGJ1czogJ3BsYXRmb3JtJzogcmVhbGx5X3Byb2Jl
OiBwcm9iaW5nIGRyaXZlciBpODA0MiB3aXRoIGRldmljZSBpODA0Mg0KWyAgIDE1LjA0MjUy
OV0gc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQ0KWyAgIDE1LjA0
MjY0N10gZGV2aWNlOiAnc2VyaW8wJzogZGV2aWNlX2FkZA0KWyAgIDE1LjA0MjcxM10gYnVz
OiAnc2VyaW8nOiBhZGQgZGV2aWNlIHNlcmlvMA0KWyAgIDE1LjA0Mjc2N10gUE06IEFkZGlu
ZyBpbmZvIGZvciBzZXJpbzpzZXJpbzANClsgICAxNS4wNDI4NDBdIHNlcmlvOiBpODA0MiBB
VVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpbICAgMTUuMDQyODU3XSBkcml2ZXI6ICdp
ODA0Mic6IGRyaXZlcl9ib3VuZDogYm91bmQgdG8gZGV2aWNlICdpODA0MicNClsgICAxNS4w
NDI4NTldIGJ1czogJ3BsYXRmb3JtJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgaTgw
NDIgdG8gZHJpdmVyIGk4MDQyDQpbICAgMTUuMDQzMDY3XSBkZXZpY2U6ICdzZXJpbzEnOiBk
ZXZpY2VfYWRkDQpbICAgMTUuMDQzMTE5XSBidXM6ICdzZXJpbyc6IGFkZCBkZXZpY2Ugc2Vy
aW8xDQpbICAgMTUuMDQzMTg0XSBQTTogQWRkaW5nIGluZm8gZm9yIHNlcmlvOnNlcmlvMQ0K
WyAgIDE1LjA0MzMxOV0gZGV2aWNlOiAnbWljZSc6IGRldmljZV9hZGQNClsgICAxNS4wNDM1
NDddIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOm1pY2UNClsgICAxNS4wNDQwMjNdIG1v
dXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlDQpbICAgMTUu
MDQ0MDg2XSBkZXZpY2U6ICdldmVudDAnOiBkZXZpY2VfYWRkDQpbICAgMTUuMDQ0NDI1XSBQ
TTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czpldmVudDANClsgICAxNS4wNDQ3NjJdIGRldmlj
ZTogJ2V2ZW50MSc6IGRldmljZV9hZGQNClsgICAxNS4wNDQ5MjJdIFBNOiBBZGRpbmcgaW5m
byBmb3IgTm8gQnVzOmV2ZW50MQ0KWyAgIDE1LjA0NTM1M10gYnVzOiAnc2VyaW8nOiBhZGQg
ZHJpdmVyIGF0a2JkDQpbICAgMTUuMDQ1NjE0XSBidXM6ICdzZXJpbyc6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIHNlcmlvMCB3aXRoIGRyaXZlciBhdGtiZA0KWyAg
IDE1LjA0NTYxNV0gYnVzOiAnc2VyaW8nOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVy
IGF0a2JkIHdpdGggZGV2aWNlIHNlcmlvMA0KWyAgIDE1LjA0NTcxNV0gYnVzOiAnc2VyaW8n
OiBhZGQgZHJpdmVyIHBzbW91c2UNClsgICAxNS4wNDYwNjFdIGJ1czogJ3BucCc6IGFkZCBk
cml2ZXIgcnRjX2Ntb3MNClsgICAxNS4wNDYwODVdIGJ1czogJ3BucCc6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDAwOjAzIHdpdGggZHJpdmVyIHJ0Y19jbW9zDQpb
ICAgMTUuMDQ2MDg2XSBidXM6ICdwbnAnOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVy
IHJ0Y19jbW9zIHdpdGggZGV2aWNlIDAwOjAzDQpbICAgMTUuMDQ2MTM3XSBydGNfY21vcyAw
MDowMzogUlRDIGNhbiB3YWtlIGZyb20gUzQNClsgICAxNS4wNDY0OTFdIGRldmljZTogJ3J0
YzAnOiBkZXZpY2VfYWRkDQpbICAgMTUuMDQ2NzYzXSBQTTogQWRkaW5nIGluZm8gZm9yIE5v
IEJ1czpydGMwDQpbICAgMTUuMDQ3NDY5XSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJl
Z2lzdGVyZWQgcnRjX2Ntb3MgYXMgcnRjMA0KWyAgIDE1LjA0NzU4MF0gcnRjX2Ntb3MgMDA6
MDM6IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAg
MTUuMDQ3NTgxXSBkcml2ZXI6ICcwMDowMyc6IGRyaXZlcl9ib3VuZDogYm91bmQgdG8gZGV2
aWNlICdydGNfY21vcycNClsgICAxNS4wNDc1ODRdIGJ1czogJ3BucCc6IHJlYWxseV9wcm9i
ZTogYm91bmQgZGV2aWNlIDAwOjAzIHRvIGRyaXZlciBydGNfY21vcw0KWyAgIDE1LjA0Nzkx
M10gYnVzOiAnYWNwaSc6IGFkZCBkcml2ZXIgY21pDQpbICAgMTUuMDQ4MTYyXSBidXM6ICdw
Y2knOiBhZGQgZHJpdmVyIGFtZDc1Nl9zbWJ1cw0KWyAgIDE1LjA0ODU4OF0gYnVzOiAncGNp
JzogYWRkIGRyaXZlciBhbWQ4MTExX3NtYnVzMg0KWyAgIDE1LjA0ODgyM10gYnVzOiAncGNp
JzogYWRkIGRyaXZlciBpODAxX3NtYnVzDQpbICAgMTUuMDQ5MzAyXSBidXM6ICdwbGF0Zm9y
bSc6IGFkZCBkcml2ZXIgaXNjaF9zbWJ1cw0KWyAgIDE1LjA0OTQ5OF0gYnVzOiAncGNpJzog
YWRkIGRyaXZlciBwaWl4NF9zbWJ1cw0KWyAgIDE1LjA0OTUyM10gYnVzOiAncGNpJzogZHJp
dmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowMDoxNC4wIHdpdGggZHJp
dmVyIHBpaXg0X3NtYnVzDQpbICAgMTUuMDQ5NTIzXSBidXM6ICdwY2knOiByZWFsbHlfcHJv
YmU6IHByb2JpbmcgZHJpdmVyIHBpaXg0X3NtYnVzIHdpdGggZGV2aWNlIDAwMDA6MDA6MTQu
MA0KWyAgIDE1LjA0OTU5NV0gQUNQSSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDBiMDAtMHgw
MDAwMDAwMDAwMDAwYjA3IFN5c3RlbUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcU09SMSAx
ICgyMDEzMDExNy91dGFkZHJlc3MtMjUxKQ0KWyAgIDE1LjA0OTU5OF0gQUNQSTogVGhpcyBj
b25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1zIGFuZCBzeXN0ZW0gaW5zdGFiaWxp
dHkNClsgICAxNS4wNDk1OTldIEFDUEk6IElmIGFuIEFDUEkgZHJpdmVyIGlzIGF2YWlsYWJs
ZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNlIGl0IGluc3RlYWQgb2YgdGhlIG5h
dGl2ZSBkcml2ZXINClsgICAxNS4wNDk2MTNdIHBpaXg0X3NtYnVzIDAwMDA6MDA6MTQuMDog
U01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjAwLCByZXZpc2lvbiAwDQpbICAgMTUuMDQ5
NzIwXSBkZXZpY2U6ICdpMmMtMCc6IGRldmljZV9hZGQNClsgICAxNS4wNDk3NjRdIGJ1czog
J2kyYyc6IGFkZCBkZXZpY2UgaTJjLTANClsgICAxNS4wNDk3OTldIFBNOiBBZGRpbmcgaW5m
byBmb3IgaTJjOmkyYy0wDQpbICAgMTUuMDUwMjc2XSBkcml2ZXI6ICcwMDAwOjAwOjE0LjAn
OiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAncGlpeDRfc21idXMnDQpbICAgMTUu
MDUwMjg5XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IGJvdW5kIGRldmljZSAwMDAwOjAw
OjE0LjAgdG8gZHJpdmVyIHBpaXg0X3NtYnVzDQpbICAgMTUuMDUwODY2XSBidXM6ICdpMmMn
OiBhZGQgZHJpdmVyIG1zcDM0MDANClsgICAxNS4wNTEzMjhdIGJ1czogJ2kyYyc6IGFkZCBk
cml2ZXIgY3gyNTg0MA0KWyAgIDE1LjA1MTU0Nl0gYnVzOiAnaTJjJzogYWRkIGRyaXZlciBz
YWE3MTE1DQpbICAgMTUuMDUxNzcwXSBidXM6ICdpMmMnOiBhZGQgZHJpdmVyIGNzNTNsMzJh
DQpbICAgMTUuMDUyMDA5XSBidXM6ICdpMmMnOiBhZGQgZHJpdmVyIHdtODc3NQ0KWyAgIDE1
LjA1MjI1MF0gYnVzOiAnaTJjJzogYWRkIGRyaXZlciBpci1rYmQtaTJjDQpbICAgMTUuMDUy
NDgxXSBidXM6ICdpMmMnOiBhZGQgZHJpdmVyIHR1bmVyDQpbICAgMTguMTY1MzgxXSBwc21v
dXNlOiBwcm9iZSBvZiBzZXJpbzEgcmVqZWN0cyBtYXRjaCAtMTkNClsgICAxOC4xNjc4MzVd
IGJ1czogJ2hpZCc6IHJlZ2lzdGVyZWQNClsgICAxOC4xNjc4NDNdIGRldmljZSBjbGFzcyAn
aGlkcmF3JzogcmVnaXN0ZXJpbmcNClsgICAxOC4xNjgwNDJdIGhpZHJhdzogcmF3IEhJRCBl
dmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQ0KWyAgIDE4LjE2ODA2Nl0gYnVzOiAnaGlk
JzogYWRkIGRyaXZlciBoaWQtZ2VuZXJpYw0KWyAgIDE4LjE2ODMxMV0gYnVzOiAnaGlkJzog
YWRkIGRyaXZlciBhNHRlY2gNClsgICAxOC4xNjg1NTVdIGJ1czogJ2hpZCc6IGFkZCBkcml2
ZXIgYXBwbGUNClsgICAxOC4xNjg4MzVdIGJ1czogJ2hpZCc6IGFkZCBkcml2ZXIgYmVsa2lu
DQpbICAgMTguMTY5MDc0XSBidXM6ICdoaWQnOiBhZGQgZHJpdmVyIGNoZXJyeQ0KWyAgIDE4
LjE2OTMwN10gYnVzOiAnaGlkJzogYWRkIGRyaXZlciBjaGljb255DQpbICAgMTguMTY5NTI1
XSBidXM6ICdoaWQnOiBhZGQgZHJpdmVyIGN5cHJlc3MNClsgICAxOC4xNjk3MTRdIGJ1czog
J2hpZCc6IGFkZCBkcml2ZXIgZXprZXkNClsgICAxOC4xNjk5MzFdIGJ1czogJ2hpZCc6IGFk
ZCBkcml2ZXIga2Vuc2luZ3Rvbg0KWyAgIDE4LjE3MDE2MV0gYnVzOiAnaGlkJzogYWRkIGRy
aXZlciBsb2dpdGVjaA0KWyAgIDE4LjE3MDM5MV0gYnVzOiAnaGlkJzogYWRkIGRyaXZlciBt
aWNyb3NvZnQNClsgICAxOC4xNzA2NjRdIGJ1czogJ2hpZCc6IGFkZCBkcml2ZXIgbW9udGVy
ZXkNClsgICAxOC4xNzA5MDRdIGJ1czogJ3VzYic6IGFkZCBkcml2ZXIgdXNiaGlkDQpbICAg
MTguMTcxMzkwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVz
YmhpZA0KWyAgIDE4LjE3MTM5MV0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyDQpbICAg
MTguMTcxNTQ0XSBkZXZpY2U6ICd0aW1lcic6IGRldmljZV9hZGQNClsgICAxOC4xNzE5OTRd
IFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnRpbWVyDQpbICAgMTguMTcyODA5XSBkZXZp
Y2U6ICdzZXEnOiBkZXZpY2VfYWRkDQpbICAgMTguMTcyOTk3XSBQTTogQWRkaW5nIGluZm8g
Zm9yIE5vIEJ1czpzZXENClsgICAxOC4xNzM4NDhdIGRldmljZTogJ3NlcXVlbmNlcic6IGRl
dmljZV9hZGQNClsgICAxOC4xNzQwMzZdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnNl
cXVlbmNlcg0KWyAgIDE4LjE3NDcwN10gZGV2aWNlOiAnc2VxdWVuY2VyMic6IGRldmljZV9h
ZGQNClsgICAxOC4xNzQ4OTNdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnNlcXVlbmNl
cjINClsgICAxOC4xNzk3NzNdIGJ1czogJ3BjaSc6IGFkZCBkcml2ZXIgc25kX2NtaXBjaQ0K
WyAgIDE4LjE4MDUzM10gYnVzOiAncGNpJzogYWRkIGRyaXZlciBzbmRfaGRhX2ludGVsDQpb
ICAgMTguMTgxMTk5XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIHNuZF9veHlnZW4NClsgICAx
OC4xODE4NDddIGJ1czogJ3VzYic6IGFkZCBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgIDE4
LjE4MjM0NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQt
dXNiLWF1ZGlvDQpbICAgMTguMTgyMzUyXSBidXM6ICd1c2InOiBhZGQgZHJpdmVyIHNuZC11
YTEwMQ0KWyAgIDE4LjE4MjgxMV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBzbmQtdWExMDENClsgICAxOC4xODI4MTddIGJ1czogJ3VzYic6IGFkZCBkcml2
ZXIgc25kLXVzYi11c3gyeQ0KWyAgIDE4LjE4MzI4Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLXVzeDJ5DQpbICAgMTguMTgzMjg3XSBidXM6
ICd1c2InOiBhZGQgZHJpdmVyIHNuZC11c2ItY2FpYXENClsgICAxOC4xODM1ODddIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1jYWlhcQ0KWyAg
IDE4LjE4MzU5NV0gYnVzOiAndXNiJzogYWRkIGRyaXZlciBzbmQtdXNiLTZmaXJlDQpbICAg
MTguMTg0MDgxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNu
ZC11c2ItNmZpcmUNClsgICAxOC4xODQxNTNdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVU
TElOSyB2MC4zMC4NClsgICAxOC4xODQxNzldIG5mbmxfYWNjdDogcmVnaXN0ZXJpbmcgd2l0
aCBuZm5ldGxpbmsuDQpbICAgMTguMTg0MjU1XSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUu
MCAoNzMwMyBidWNrZXRzLCAyOTIxMiBtYXgpDQpbICAgMTguMTg2MDcyXSBjdG5ldGxpbmsg
djAuOTM6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KWyAgIDIxLjA1MzY5NF0gUE06
IEFkZGluZyBpbmZvIGZvciBObyBCdXM6ZXZlbnQzDQpbICAgMjEuMDU0NDM3XSBkZXZpY2Ug
Y2xhc3MgJ3VzYm1pc2MnOiByZWdpc3RlcmluZw0KWyAgIDIxLjA1NDg2NV0gZGV2aWNlOiAn
aGlkZGV2MCc6IGRldmljZV9hZGQNClsgICAyMS4wNTUzOTZdIFBNOiBBZGRpbmcgaW5mbyBm
b3IgTm8gQnVzOmhpZGRldjANClsgICAyMS4wNTYxNjBdIGRldmljZTogJ2hpZHJhdzEnOiBk
ZXZpY2VfYWRkDQpbICAgMjEuMDU2NjIwXSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czpo
aWRyYXcxDQpbICAgMjEuMDU3MTMyXSBsb2dpdGVjaCAwMDAzOjA0NkQ6QzUxNy4wMDAyOiBp
bnB1dCxoaWRkZXYwLGhpZHJhdzE6IFVTQiBISUQgdjEuMTAgTW91c2UgW0xvZ2l0ZWNoIFVT
QiBSZWNlaXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0zL2lucHV0MQ0KWyAgIDIxLjA1NzEz
NF0gZHJpdmVyOiAnMDAwMzowNDZEOkM1MTcuMDAwMic6IGRyaXZlcl9ib3VuZDogYm91bmQg
dG8gZGV2aWNlICdsb2dpdGVjaCcNClsgICAyMS4wNTcxNDVdIGJ1czogJ2hpZCc6IHJlYWxs
eV9wcm9iZTogYm91bmQgZGV2aWNlIDAwMDM6MDQ2RDpDNTE3LjAwMDIgdG8gZHJpdmVyIGxv
Z2l0ZWNoDQpbICAgMjEuMDU3MTUwXSBkcml2ZXI6ICc4LTM6MS4xJzogZHJpdmVyX2JvdW5k
OiBib3VuZCB0byBkZXZpY2UgJ3VzYmhpZCcNClsgICAyMS4wNTcxNTNdIGJ1czogJ3VzYic6
IHJlYWxseV9wcm9iZTogYm91bmQgZGV2aWNlIDgtMzoxLjEgdG8gZHJpdmVyIHVzYmhpZA0K
WyAgIDIxLjA1NzE3N10gZGV2aWNlOiAnZXBfODInOiBkZXZpY2VfYWRkDQpbICAgMjEuMDU3
Mjc0XSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czplcF84Mg0KWyAgIDIxLjA1NzI3N10g
ZHJpdmVyOiAnOC0zJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ3VzYicNClsg
ICAyMS4wNTcyODVdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTogYm91bmQgZGV2aWNlIDgt
MyB0byBkcml2ZXIgdXNiDQpbICAgMjEuMDU3MzIyXSBkZXZpY2U6ICdlcF8wMCc6IGRldmlj
ZV9hZGQNClsgICAyMS4wNTczOTVdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmVwXzAw
DQpbICAgMjEuNDg1MzMwXSBhc3luY193YWl0aW5nIEAgMQ0KWyAgIDIxLjQ5MjU1OF0gYXN5
bmNfY29udGludWluZyBAIDEgYWZ0ZXIgNCB1c2VjDQpbICAgMjEuNTAwMjQxXSBGcmVlaW5n
IHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMDcyayBmcmVlZA0KWyAgIDIxLjUwNzcxOV0gV3Jp
dGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBkYXRhOiAxNDMzNmsNClsgICAy
MS41MjEyMjNdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE4MGsgZnJlZWQNClsg
ICAyMS41Mjg2NjVdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDIwOGsgZnJlZWQN
ClsgICAyMS42MDU4NDRdIHVkZXZbMTUwMV06IHN0YXJ0aW5nIHZlcnNpb24gMTY0DQpbICAx
MjYuMzc5Nzk5XSBTUDUxMDAgVENPIHRpbWVyIFNQNTEwMCBUQ08gdGltZXI6IHNodXRkb3du
DQpbICAxMjYuMzg2NTE2XSBpMmMgaTJjLTA6IHNodXRkb3duDQpbICAxMjYuMzkzMDUwXSBz
ZXJpbyBzZXJpbzE6IHNodXRkb3duDQpbICAxMjYuMzk5NTIyXSBzZXJpbyBzZXJpbzA6IHNo
dXRkb3duDQpbICAxMjYuNDA1ODExXSBpODA0MiBpODA0Mjogc2h1dGRvd24NClsgIDEyNi40
MTI0MDFdIHN5c3RlbSAwMDowYzogc2h1dGRvd24NClsgIDEyNi40MTg1NjddIHN5c3RlbSAw
MDowYjogc2h1dGRvd24NClsgIDEyNi40MjQ2ODddIHN5c3RlbSAwMDowYTogc2h1dGRvd24N
ClsgIDEyNi40MzA3MjNdIHN5c3RlbSAwMDowOTogc2h1dGRvd24NClsgIDEyNi40MzY3MjVd
IHBucCAwMDowODogc2h1dGRvd24NClsgIDEyNi40NDI2NzZdIHN5c3RlbSAwMDowNzogc2h1
dGRvd24NClsgIDEyNi40NDg1MzldIHNlcmlhbCAwMDowNjogc2h1dGRvd24NClsgIDEyNi40
NTQzMzhdIHBucCAwMDowNTogc2h1dGRvd24NClsgIDEyNi40NjAwMTZdIHBucCAwMDowNDog
c2h1dGRvd24NClsgIDEyNi40NjU2NDVdIHJ0Y19jbW9zIDAwOjAzOiBzaHV0ZG93bg0KWyAg
MTI2LjQ3MTI3OV0gcG5wIDAwOjAyOiBzaHV0ZG93bg0KWyAgMTI2LjQ3Njc0NF0gc3lzdGVt
IDAwOjAxOiBzaHV0ZG93bg0KWyAgMTI2LjQ4MjEyOF0gc3lzdGVtIDAwOjAwOiBzaHV0ZG93
bg0KWyAgMTI2LjQ4NzM4NV0gcGNpYmFjayAwMDAwOjAzOjA2LjA6IHNodXRkb3duDQpbICAx
MjYuNDkyNTQ0XSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogc2h1dGRvd24NClsgIDEyNi40OTc2
NDNdIHBjaWJhY2sgMDAwMDowNTowMC4xOiBzaHV0ZG93bg0KWyAgMTI2LjUwMjczMF0gcGNp
YmFjayAwMDAwOjA1OjAwLjA6IHNodXRkb3duDQpbICAxMjYuNTA3NTE5XSBwY2liYWNrIDAw
MDA6MDY6MDAuMDogc2h1dGRvd24NClsgIDEyNi41MTIyMDZdIHhoY2lfaGNkIDAwMDA6MDc6
MDAuMDogc2h1dGRvd24NClsgIDEyNi41MzA5NzVdIHI4MTY5IDAwMDA6MDg6MDAuMDogc2h1
dGRvd24NClsgIDEyNi41MzU4ODBdIHI4MTY5IDAwMDA6MDk6MDAuMDogc2h1dGRvd24NClsg
IDEyNi41NDA3MTVdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogc2h1dGRvd24NClsgIDEyNi41
NDU0NDNdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMTogc2h1dGRvd24NClsgIDEyNi41NTAwMjVd
IG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogc2h1dGRvd24NClsgIDEyNi41NTQ1MTVdIHBjaSAw
MDAwOjBhOjAwLjA6IHNodXRkb3duDQpbICAxMjYuNTU4OTY2XSBwY2kgMDAwMDowYzowMC4w
OiBzaHV0ZG93bg0KWyAgMTI2LjU2MzE3M10gcGNpIDAwMDA6MDA6MTguNDogc2h1dGRvd24N
ClsgIDEyNi41NjcxOTddIGsxMHRlbXAgMDAwMDowMDoxOC4zOiBzaHV0ZG93bg0KWyAgMTI2
LjU3MTEyOV0gcGNpIDAwMDA6MDA6MTguMjogc2h1dGRvd24NClsgIDEyNi41NzQ5NzldIHBj
aSAwMDAwOjAwOjE4LjE6IHNodXRkb3duDQpbICAxMjYuNTc4NzI0XSBwY2kgMDAwMDowMDox
OC4wOiBzaHV0ZG93bg0KWyAgMTI2LjU4MjM1M10gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBz
aHV0ZG93bg0KWyAgMTI2LjU4NjQxOV0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBzaHV0ZG93
bg0KWyAgMTI2LjU5MDAwMl0gcGNpZXBvcnQgMDAwMDowMDoxNS4wOiBzaHV0ZG93bg0KWyAg
MTI2LjU5MzUxOV0gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBzaHV0ZG93bg0KWyAgMTI2LjU5
NjkzMl0gcGNpIDAwMDA6MDA6MTQuNDogc2h1dGRvd24NClsgIDEyNi42MDAzNDhdIHBjaSAw
MDAwOjAwOjE0LjM6IHNodXRkb3duDQpbICAxMjYuNjAzNjAxXSBwY2kgMDAwMDowMDoxNC4x
OiBzaHV0ZG93bg0KWyAgMTI2LjYwNjcxM10gcGlpeDRfc21idXMgMDAwMDowMDoxNC4wOiBz
aHV0ZG93bg0KWyAgMTI2LjYwOTg3M10gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBzaHV0ZG93
bg0KWyAgMTI2LjYxMzE1NV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBzaHV0ZG93bg0KWyAg
MTI2LjYxNjI3MV0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBzaHV0ZG93bg0KWyAgMTI2LjYy
MDIwN10gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBzaHV0ZG93bg0KWyAgMTI2LjYyMzEzOF0g
cGNpIDAwMDA6MDA6MTEuMDogc2h1dGRvd24NClsgIDEyNi42MjU5OTNdIHBjaWVwb3J0IDAw
MDA6MDA6MGQuMDogc2h1dGRvd24NClsgIDEyNi42Mjg5MDhdIHBjaWVwb3J0IDAwMDA6MDA6
MGIuMDogc2h1dGRvd24NClsgIDEyNi42MzE3MDBdIHBjaWVwb3J0IDAwMDA6MDA6MGEuMDog
c2h1dGRvd24NClsgIDEyNi42MzQ0MzFdIHBjaWVwb3J0IDAwMDA6MDA6MDkuMDogc2h1dGRv
d24NClsgIDEyNi42MzcwOTddIHBjaWVwb3J0IDAwMDA6MDA6MDYuMDogc2h1dGRvd24NClsg
IDEyNi42Mzk3NDddIHBjaWVwb3J0IDAwMDA6MDA6MDUuMDogc2h1dGRvd24NClsgIDEyNi42
NDIzMjldIHBjaWVwb3J0IDAwMDA6MDA6MDMuMDogc2h1dGRvd24NClsgIDEyNi42NDQ4MjBd
IHBjaWVwb3J0IDAwMDA6MDA6MDIuMDogc2h1dGRvd24NClsgIDEyNi42NDcyMDddIHBjaSAw
MDAwOjAwOjAwLjI6IHNodXRkb3duDQpbICAxMjYuNjQ5NTgyXSBwY2kgMDAwMDowMDowMC4w
OiBzaHV0ZG93bg0KWyAgMTI2LjY1NjM5MF0gRGlzYWJsaW5nIG5vbi1ib290IENQVXMgLi4u
DQpbICAxMjYuNjYzMTU5XSBkZXZpY2U6ICdtYWNoaW5lY2hlY2sxJzogZGV2aWNlX3VucmVn
aXN0ZXINClsgIDEyNi42NjU2MjFdIGJ1czogJ21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZp
Y2UgbWFjaGluZWNoZWNrMQ0KWyAgMTI2LjY2ODAzM10gUE06IFJlbW92aW5nIGluZm8gZm9y
IG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2sxDQpbICAxMjYuNzcxODc0XSBkZXZpY2U6ICdt
YWNoaW5lY2hlY2syJzogZGV2aWNlX3VucmVnaXN0ZXINClsgIDEyNi43NzQ2MTNdIGJ1czog
J21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZpY2UgbWFjaGluZWNoZWNrMg0KWyAgMTI2Ljc3
NzI1OF0gUE06IFJlbW92aW5nIGluZm8gZm9yIG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2sy
DQpbICAxMjYuODgxODczXSBkZXZpY2U6ICdtYWNoaW5lY2hlY2szJzogZGV2aWNlX3VucmVn
aXN0ZXINClsgIDEyNi44ODQ2NTRdIGJ1czogJ21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZp
Y2UgbWFjaGluZWNoZWNrMw0KWyAgMTI2Ljg4NzQ4Nl0gUE06IFJlbW92aW5nIGluZm8gZm9y
IG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2szDQpbICAxMjYuODkzMDk0XSBkZXZpY2U6ICdt
YWNoaW5lY2hlY2s0JzogZGV2aWNlX3VucmVnaXN0ZXINClsgIDEyNi44OTYwODZdIGJ1czog
J21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZpY2UgbWFjaGluZWNoZWNrNA0KWyAgMTI2Ljg5
OTA4NV0gUE06IFJlbW92aW5nIGluZm8gZm9yIG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2s0
DQpbICAxMjcuMDA1MjI2XSBkZXZpY2U6ICdtYWNoaW5lY2hlY2s1JzogZGV2aWNlX3VucmVn
aXN0ZXINClsgIDEyNy4wMDgzMDldIGJ1czogJ21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZp
Y2UgbWFjaGluZWNoZWNrNQ0KWyAgMTI3LjAxMTQ2OV0gUE06IFJlbW92aW5nIGluZm8gZm9y
IG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2s1DQpbICAxMjcuMDE0OTk1XSBSZXN0YXJ0aW5n
IHN5c3RlbS4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjE1OjU2XSBEb21haW4gMCBzaHV0ZG93
bjogcmVib290aW5nIG1hY2hpbmUuDQo=
------------0791EC21F164E2952
Content-Type: application/octet-stream;
 name=dotconfig
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=dotconfig

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4
L3g4Nl82NCAzLjguMC1yYzAtMjAxMzAyMjUgS2VybmVsIENvbmZpZ3VyYXRpb24KIwpDT05G
SUdfNjRCSVQ9eQpDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4Nj15CkNPTkZJR19JTlNUUlVD
VElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9GT1JNQVQ9ImVsZjY0LXg4Ni02NCIKQ09O
RklHX0FSQ0hfREVGQ09ORklHPSJhcmNoL3g4Ni9jb25maWdzL3g4Nl82NF9kZWZjb25maWci
CkNPTkZJR19MT0NLREVQX1NVUFBPUlQ9eQpDT05GSUdfU1RBQ0tUUkFDRV9TVVBQT1JUPXkK
Q09ORklHX0hBVkVfTEFURU5DWVRPUF9TVVBQT1JUPXkKQ09ORklHX01NVT15CkNPTkZJR19O
RUVEX0RNQV9NQVBfU1RBVEU9eQpDT05GSUdfTkVFRF9TR19ETUFfTEVOR1RIPXkKQ09ORklH
X0dFTkVSSUNfSVNBX0RNQT15CkNPTkZJR19HRU5FUklDX0JVRz15CkNPTkZJR19HRU5FUklD
X0JVR19SRUxBVElWRV9QT0lOVEVSUz15CkNPTkZJR19HRU5FUklDX0hXRUlHSFQ9eQpDT05G
SUdfQVJDSF9NQVlfSEFWRV9QQ19GREM9eQpDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklU
SE09eQpDT05GSUdfR0VORVJJQ19DQUxJQlJBVEVfREVMQVk9eQpDT05GSUdfQVJDSF9IQVNf
Q1BVX1JFTEFYPXkKQ09ORklHX0FSQ0hfSEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNI
X0hBU19DQUNIRV9MSU5FX1NJWkU9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX0FVVE9QUk9CRT15
CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVfQVJFQT15CkNPTkZJR19ORUVEX1BFUl9DUFVf
RU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVFRF9QRVJfQ1BVX1BBR0VfRklSU1RfQ0hV
Tks9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NTSUJMRT15CkNPTkZJR19BUkNIX1NV
U1BFTkRfUE9TU0lCTEU9eQpDT05GSUdfWk9ORV9ETUEzMj15CkNPTkZJR19BVURJVF9BUkNI
PXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1JWkVEX0lOTElOSU5HPXkKQ09ORklHX0FS
Q0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklHX0hBVkVfSU5URUxfVFhUPXkK
Q09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2X0hUPXkKQ09ORklHX0FSQ0hfSFdFSUdI
VF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1yZGkgLWZjYWxsLXNhdmVkLXJzaSAtZmNhbGwtc2F2
ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZjYWxsLXNhdmVkLXI4IC1mY2FsbC1zYXZlZC1y
OSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZlZC1yMTEiCkNPTkZJR19BUkNIX0NQVV9Q
Uk9CRV9SRUxFQVNFPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfVVBST0JFUz15CkNPTkZJR19E
RUZDT05GSUdfTElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9SRUxFQVNFLy5jb25maWciCkNP
TkZJR19JUlFfV09SSz15CkNPTkZJR19CVUlMRFRJTUVfRVhUQUJMRV9TT1JUPXkKCiMKIyBH
ZW5lcmFsIHNldHVwCiMKQ09ORklHX0VYUEVSSU1FTlRBTD15CkNPTkZJR19JTklUX0VOVl9B
UkdfTElNSVQ9MzIKQ09ORklHX0NST1NTX0NPTVBJTEU9IiIKQ09ORklHX0xPQ0FMVkVSU0lP
Tj0iIgojIENPTkZJR19MT0NBTFZFUlNJT05fQVVUTyBpcyBub3Qgc2V0CkNPTkZJR19IQVZF
X0tFUk5FTF9HWklQPXkKQ09ORklHX0hBVkVfS0VSTkVMX0JaSVAyPXkKQ09ORklHX0hBVkVf
S0VSTkVMX0xaTUE9eQpDT05GSUdfSEFWRV9LRVJORUxfWFo9eQpDT05GSUdfSEFWRV9LRVJO
RUxfTFpPPXkKQ09ORklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VSTkVMX0JaSVAyIGlz
IG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENPTkZJR19LRVJO
RUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBzZXQKQ09ORklH
X0RFRkFVTFRfSE9TVE5BTUU9Iihub25lKSIKQ09ORklHX1NXQVA9eQpDT05GSUdfU1lTVklQ
Qz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CiMgQ09ORklHX1BPU0lYX01RVUVVRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0ZIQU5ETEUgaXMgbm90IHNldApDT05GSUdfQVVESVQ9eQpDT05G
SUdfQVVESVRTWVNDQUxMPXkKQ09ORklHX0FVRElUX1dBVENIPXkKQ09ORklHX0FVRElUX1RS
RUU9eQojIENPTkZJR19BVURJVF9MT0dJTlVJRF9JTU1VVEFCTEUgaXMgbm90IHNldApDT05G
SUdfSEFWRV9HRU5FUklDX0hBUkRJUlFTPXkKCiMKIyBJUlEgc3Vic3lzdGVtCiMKQ09ORklH
X0dFTkVSSUNfSEFSRElSUVM9eQpDT05GSUdfR0VORVJJQ19JUlFfUFJPQkU9eQpDT05GSUdf
R0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19HRU5FUklDX1BFTkRJTkdfSVJRPXkKQ09ORklH
X0lSUV9ET01BSU49eQojIENPTkZJR19JUlFfRE9NQUlOX0RFQlVHIGlzIG5vdCBzZXQKQ09O
RklHX0lSUV9GT1JDRURfVEhSRUFESU5HPXkKQ09ORklHX1NQQVJTRV9JUlE9eQpDT05GSUdf
Q0xPQ0tTT1VSQ0VfV0FUQ0hET0c9eQpDT05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkK
Q09ORklHX0FMV0FZU19VU0VfUEVSU0lTVEVOVF9DTE9DSz15CkNPTkZJR19HRU5FUklDX1RJ
TUVfVlNZU0NBTEw9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UUz15CkNPTkZJR19HRU5F
UklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlJP
QURDQVNUPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfTUlOX0FESlVTVD15CkNPTkZJ
R19HRU5FUklDX0NNT1NfVVBEQVRFPXkKCiMKIyBUaW1lcnMgc3Vic3lzdGVtCiMKQ09ORklH
X1RJQ0tfT05FU0hPVD15CkNPTkZJR19OT19IWj15CkNPTkZJR19ISUdIX1JFU19USU1FUlM9
eQoKIwojIENQVS9UYXNrIHRpbWUgYW5kIHN0YXRzIGFjY291bnRpbmcKIwpDT05GSUdfVElD
S19DUFVfQUNDT1VOVElORz15CiMgQ09ORklHX1ZJUlRfQ1BVX0FDQ09VTlRJTkdfR0VOIGlz
IG5vdCBzZXQKIyBDT05GSUdfSVJRX1RJTUVfQUNDT1VOVElORyBpcyBub3Qgc2V0CkNPTkZJ
R19CU0RfUFJPQ0VTU19BQ0NUPXkKIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVF9WMyBpcyBu
b3Qgc2V0CkNPTkZJR19UQVNLU1RBVFM9eQpDT05GSUdfVEFTS19ERUxBWV9BQ0NUPXkKQ09O
RklHX1RBU0tfWEFDQ1Q9eQpDT05GSUdfVEFTS19JT19BQ0NPVU5USU5HPXkKCiMKIyBSQ1Ug
U3Vic3lzdGVtCiMKQ09ORklHX1RSRUVfUFJFRU1QVF9SQ1U9eQpDT05GSUdfUFJFRU1QVF9S
Q1U9eQpDT05GSUdfUkNVX1NUQUxMX0NPTU1PTj15CiMgQ09ORklHX1JDVV9VU0VSX1FTIGlz
IG5vdCBzZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKQ09ORklHX1JDVV9GQU5PVVRfTEVBRj0x
NgojIENPTkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQVNU
X05PX0haPXkKIyBDT05GSUdfVFJFRV9SQ1VfVFJBQ0UgaXMgbm90IHNldApDT05GSUdfUkNV
X0JPT1NUPXkKQ09ORklHX1JDVV9CT09TVF9QUklPPTEKQ09ORklHX1JDVV9CT09TVF9ERUxB
WT01MDAKIyBDT05GSUdfUkNVX05PQ0JfQ1BVIGlzIG5vdCBzZXQKQ09ORklHX0lLQ09ORklH
PXkKIyBDT05GSUdfSUtDT05GSUdfUFJPQyBpcyBub3Qgc2V0CkNPTkZJR19MT0dfQlVGX1NI
SUZUPTE4CkNPTkZJR19IQVZFX1VOU1RBQkxFX1NDSEVEX0NMT0NLPXkKQ09ORklHX0FSQ0hf
U1VQUE9SVFNfTlVNQV9CQUxBTkNJTkc9eQpDT05GSUdfQVJDSF9XQU5UU19QUk9UX05VTUFf
UFJPVF9OT05FPXkKIyBDT05GSUdfTlVNQV9CQUxBTkNJTkcgaXMgbm90IHNldApDT05GSUdf
Q0dST1VQUz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DR1JP
VVBfRlJFRVpFUj15CiMgQ09ORklHX0NHUk9VUF9ERVZJQ0UgaXMgbm90IHNldApDT05GSUdf
Q1BVU0VUUz15CkNPTkZJR19QUk9DX1BJRF9DUFVTRVQ9eQpDT05GSUdfQ0dST1VQX0NQVUFD
Q1Q9eQpDT05GSUdfUkVTT1VSQ0VfQ09VTlRFUlM9eQojIENPTkZJR19NRU1DRyBpcyBub3Qg
c2V0CiMgQ09ORklHX0NHUk9VUF9IVUdFVExCIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dST1VQ
X1BFUkYgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JP
VVBfU0NIRUQ9eQojIENPTkZJR19DRlNfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdf
UlRfR1JPVVBfU0NIRUQgaXMgbm90IHNldApDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklH
X0RFQlVHX0JMS19DR1JPVVAgaXMgbm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RP
UkUgaXMgbm90IHNldApDT05GSUdfTkFNRVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05G
SUdfSVBDX05TPXkKQ09ORklHX1BJRF9OUz15CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NI
RURfQVVUT0dST1VQPXkKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JFTEFZIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklH
X0lOSVRSQU1GU19TT1VSQ0U9IiIKQ09ORklHX1JEX0daSVA9eQpDT05GSUdfUkRfQlpJUDI9
eQpDT05GSUdfUkRfTFpNQT15CkNPTkZJR19SRF9YWj15CkNPTkZJR19SRF9MWk89eQojIENP
TkZJR19DQ19PUFRJTUlaRV9GT1JfU0laRSBpcyBub3Qgc2V0CkNPTkZJR19TWVNDVEw9eQpD
T05GSUdfQU5PTl9JTk9ERVM9eQojIENPTkZJR19FWFBFUlQgaXMgbm90IHNldApDT05GSUdf
SEFWRV9VSUQxNj15CkNPTkZJR19VSUQxNj15CiMgQ09ORklHX1NZU0NUTF9TWVNDQUxMIGlz
IG5vdCBzZXQKQ09ORklHX1NZU0NUTF9FWENFUFRJT05fVFJBQ0U9eQpDT05GSUdfS0FMTFNZ
TVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKQ09ORklHX0hPVFBMVUc9eQpDT05GSUdfUFJJ
TlRLPXkKQ09ORklHX0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19QQ1NQS1JfUExB
VEZPUk09eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfQkFTRV9GVUxM
PXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZEPXkKQ09O
RklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJR19B
SU89eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZF
TlRTPXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNP
TkZJR19QRVJGX0VWRU5UUz15CiMgQ09ORklHX0RFQlVHX1BFUkZfVVNFX1ZNQUxMT0MgaXMg
bm90IHNldApDT05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdfUENJX1FVSVJLUz15
CkNPTkZJR19TTFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NMQUIgaXMgbm90IHNldApDT05GSUdfU0xVQj15CiMgQ09ORklHX1BST0ZJTElO
RyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX09QUk9GSUxFPXkKQ09ORklHX09QUk9GSUxFX05N
SV9USU1FUj15CiMgQ09ORklHX0tQUk9CRVMgaXMgbm90IHNldApDT05GSUdfSlVNUF9MQUJF
TD15CkNPTkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklHX0FS
Q0hfVVNFX0JVSUxUSU5fQlNXQVA9eQpDT05GSUdfSEFWRV9JT1JFTUFQX1BST1Q9eQpDT05G
SUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JFUz15CkNPTkZJR19IQVZF
X09QVFBST0JFUz15CkNPTkZJR19IQVZFX0tQUk9CRVNfT05fRlRSQUNFPXkKQ09ORklHX0hB
VkVfQVJDSF9UUkFDRUhPT0s9eQpDT05GSUdfSEFWRV9ETUFfQVRUUlM9eQpDT05GSUdfVVNF
X0dFTkVSSUNfU01QX0hFTFBFUlM9eQpDT05GSUdfR0VORVJJQ19TTVBfSURMRV9USFJFQUQ9
eQpDT05GSUdfSEFWRV9SRUdTX0FORF9TVEFDS19BQ0NFU1NfQVBJPXkKQ09ORklHX0hBVkVf
RE1BX0FQSV9ERUJVRz15CkNPTkZJR19IQVZFX0hXX0JSRUFLUE9JTlQ9eQpDT05GSUdfSEFW
RV9NSVhFRF9CUkVBS1BPSU5UU19SRUdTPXkKQ09ORklHX0hBVkVfVVNFUl9SRVRVUk5fTk9U
SUZJRVI9eQpDT05GSUdfSEFWRV9QRVJGX0VWRU5UU19OTUk9eQpDT05GSUdfSEFWRV9QRVJG
X1JFR1M9eQpDT05GSUdfSEFWRV9QRVJGX1VTRVJfU1RBQ0tfRFVNUD15CkNPTkZJR19IQVZF
X0FSQ0hfSlVNUF9MQUJFTD15CkNPTkZJR19BUkNIX0hBVkVfTk1JX1NBRkVfQ01QWENIRz15
CkNPTkZJR19IQVZFX0FMSUdORURfU1RSVUNUX1BBR0U9eQpDT05GSUdfSEFWRV9DTVBYQ0hH
X0xPQ0FMPXkKQ09ORklHX0hBVkVfQ01QWENIR19ET1VCTEU9eQpDT05GSUdfQVJDSF9XQU5U
X0NPTVBBVF9JUENfUEFSU0VfVkVSU0lPTj15CkNPTkZJR19BUkNIX1dBTlRfT0xEX0NPTVBB
VF9JUEM9eQpDT05GSUdfSEFWRV9BUkNIX1NFQ0NPTVBfRklMVEVSPXkKQ09ORklHX1NFQ0NP
TVBfRklMVEVSPXkKQ09ORklHX0hBVkVfQ09OVEVYVF9UUkFDS0lORz15CkNPTkZJR19IQVZF
X0lSUV9USU1FX0FDQ09VTlRJTkc9eQpDT05GSUdfSEFWRV9BUkNIX1RSQU5TUEFSRU5UX0hV
R0VQQUdFPXkKQ09ORklHX01PRFVMRVNfVVNFX0VMRl9SRUxBPXkKQ09ORklHX09MRF9TSUdT
VVNQRU5EMz15CkNPTkZJR19DT01QQVRfT0xEX1NJR0FDVElPTj15CgojCiMgR0NPVi1iYXNl
ZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdfR0NPVl9LRVJORUwgaXMgbm90IHNldAoj
IENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVSRU5UIGlzIG5vdCBzZXQKQ09ORklHX1NM
QUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdfQkFTRV9TTUFMTD0wCkNPTkZJ
R19NT0RVTEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQgaXMgbm90IHNldApDT05G
SUdfTU9EVUxFX1VOTE9BRD15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90
IHNldAojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX01PRFVMRV9T
UkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0CiMgQ09ORklHX01PRFVMRV9TSUcgaXMgbm90IHNl
dApDT05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklHX0JMT0NLPXkKQ09ORklHX0JMS19ERVZf
QlNHPXkKIyBDT05GSUdfQkxLX0RFVl9CU0dMSUIgaXMgbm90IHNldApDT05GSUdfQkxLX0RF
Vl9JTlRFR1JJVFk9eQojIENPTkZJR19CTEtfREVWX1RIUk9UVExJTkcgaXMgbm90IHNldAoK
IwojIFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJT05fQURWQU5DRUQ9eQojIENP
TkZJR19BQ09STl9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfT1NGX1BBUlRJVElPTj15
CkNPTkZJR19BTUlHQV9QQVJUSVRJT049eQojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMg
bm90IHNldApDT05GSUdfTUFDX1BBUlRJVElPTj15CkNPTkZJR19NU0RPU19QQVJUSVRJT049
eQpDT05GSUdfQlNEX0RJU0tMQUJFTD15CkNPTkZJR19NSU5JWF9TVUJQQVJUSVRJT049eQpD
T05GSUdfU09MQVJJU19YODZfUEFSVElUSU9OPXkKQ09ORklHX1VOSVhXQVJFX0RJU0tMQUJF
TD15CiMgQ09ORklHX0xETV9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU0dJX1BBUlRJ
VElPTj15CiMgQ09ORklHX1VMVFJJWF9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU1VO
X1BBUlRJVElPTj15CkNPTkZJR19LQVJNQV9QQVJUSVRJT049eQpDT05GSUdfRUZJX1BBUlRJ
VElPTj15CiMgQ09ORklHX1NZU1Y2OF9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfQkxP
Q0tfQ09NUEFUPXkKCiMKIyBJTyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15
CkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKQ09ORklH
X0NGUV9HUk9VUF9JT1NDSEVEPXkKIyBDT05GSUdfREVGQVVMVF9ERUFETElORSBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RFRkFVTFRfTk9PUCBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKQ09ORklHX1VOSU5MSU5FX1NQSU5f
VU5MT0NLPXkKQ09ORklHX0ZSRUVaRVI9eQoKIwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0
dXJlcwojCkNPTkZJR19aT05FX0RNQT15CkNPTkZJR19TTVA9eQojIENPTkZJR19YODZfWDJB
UElDIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9NUFBBUlNFPXkKQ09ORklHX1g4Nl9FWFRFTkRF
RF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9WU01QIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2
X0lOVEVMX0xQU1MgaXMgbm90IHNldApDT05GSUdfWDg2X1NVUFBPUlRTX01FTU9SWV9GQUlM
VVJFPXkKQ09ORklHX1NDSEVEX09NSVRfRlJBTUVfUE9JTlRFUj15CkNPTkZJR19QQVJBVklS
VF9HVUVTVD15CiMgQ09ORklHX1BBUkFWSVJUX1RJTUVfQUNDT1VOVElORyBpcyBub3Qgc2V0
CkNPTkZJR19YRU49eQpDT05GSUdfWEVOX0RPTTA9eQpDT05GSUdfWEVOX1BSSVZJTEVHRURf
R1VFU1Q9eQpDT05GSUdfWEVOX1BWSFZNPXkKQ09ORklHX1hFTl9NQVhfRE9NQUlOX01FTU9S
WT01MDAKQ09ORklHX1hFTl9TQVZFX1JFU1RPUkU9eQpDT05GSUdfWEVOX0RFQlVHX0ZTPXkK
IyBDT05GSUdfS1ZNX0dVRVNUIGlzIG5vdCBzZXQKQ09ORklHX1BBUkFWSVJUPXkKIyBDT05G
SUdfUEFSQVZJUlRfU1BJTkxPQ0tTIGlzIG5vdCBzZXQKQ09ORklHX1BBUkFWSVJUX0NMT0NL
PXkKQ09ORklHX1BBUkFWSVJUX0RFQlVHPXkKQ09ORklHX05PX0JPT1RNRU09eQojIENPTkZJ
R19NRU1URVNUIGlzIG5vdCBzZXQKQ09ORklHX01LOD15CiMgQ09ORklHX01QU0MgaXMgbm90
IHNldAojIENPTkZJR19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJR19NQVRPTSBpcyBub3Qg
c2V0CiMgQ09ORklHX0dFTkVSSUNfQ1BVIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9JTlRFUk5P
REVfQ0FDSEVfU0hJRlQ9NgpDT05GSUdfWDg2X0wxX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4
Nl9JTlRFTF9VU0VSQ09QWT15CkNPTkZJR19YODZfVVNFX1BQUk9fQ0hFQ0tTVU09eQpDT05G
SUdfWDg2X1RTQz15CkNPTkZJR19YODZfQ01QWENIRzY0PXkKQ09ORklHX1g4Nl9DTU9WPXkK
Q09ORklHX1g4Nl9NSU5JTVVNX0NQVV9GQU1JTFk9NjQKQ09ORklHX1g4Nl9ERUJVR0NUTE1T
Uj15CkNPTkZJR19DUFVfU1VQX0lOVEVMPXkKQ09ORklHX0NQVV9TVVBfQU1EPXkKQ09ORklH
X0NQVV9TVVBfQ0VOVEFVUj15CkNPTkZJR19IUEVUX1RJTUVSPXkKQ09ORklHX0hQRVRfRU1V
TEFURV9SVEM9eQpDT05GSUdfRE1JPXkKQ09ORklHX0dBUlRfSU9NTVU9eQojIENPTkZJR19D
QUxHQVJZX0lPTU1VIGlzIG5vdCBzZXQKQ09ORklHX1NXSU9UTEI9eQpDT05GSUdfSU9NTVVf
SEVMUEVSPXkKIyBDT05GSUdfTUFYU01QIGlzIG5vdCBzZXQKQ09ORklHX05SX0NQVVM9OApD
T05GSUdfU0NIRURfU01UPXkKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfUFJFRU1QVF9O
T05FIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJFRU1QVF9WT0xVTlRBUlkgaXMgbm90IHNldApD
T05GSUdfUFJFRU1QVD15CkNPTkZJR19QUkVFTVBUX0NPVU5UPXkKQ09ORklHX1g4Nl9MT0NB
TF9BUElDPXkKQ09ORklHX1g4Nl9JT19BUElDPXkKQ09ORklHX1g4Nl9SRVJPVVRFX0ZPUl9C
Uk9LRU5fQk9PVF9JUlFTPXkKQ09ORklHX1g4Nl9NQ0U9eQpDT05GSUdfWDg2X01DRV9JTlRF
TD15CkNPTkZJR19YODZfTUNFX0FNRD15CkNPTkZJR19YODZfTUNFX1RIUkVTSE9MRD15CiMg
Q09ORklHX1g4Nl9NQ0VfSU5KRUNUIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9USEVSTUFMX1ZF
Q1RPUj15CiMgQ09ORklHX0k4SyBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JPQ09ERSBpcyBu
b3Qgc2V0CkNPTkZJR19YODZfTVNSPXkKQ09ORklHX1g4Nl9DUFVJRD15CkNPTkZJR19BUkNI
X1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX0FSQ0hfRE1BX0FERFJfVF82NEJJVD15CkNP
TkZJR19ESVJFQ1RfR0JQQUdFUz15CkNPTkZJR19OVU1BPXkKQ09ORklHX0FNRF9OVU1BPXkK
Q09ORklHX1g4Nl82NF9BQ1BJX05VTUE9eQpDT05GSUdfTk9ERVNfU1BBTl9PVEhFUl9OT0RF
Uz15CiMgQ09ORklHX05VTUFfRU1VIGlzIG5vdCBzZXQKQ09ORklHX05PREVTX1NISUZUPTgK
Q09ORklHX0FSQ0hfU1BBUlNFTUVNX0VOQUJMRT15CkNPTkZJR19BUkNIX1NQQVJTRU1FTV9E
RUZBVUxUPXkKQ09ORklHX0FSQ0hfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19BUkNI
X1BST0NfS0NPUkVfVEVYVD15CkNPTkZJR19JTExFR0FMX1BPSU5URVJfVkFMVUU9MHhkZWFk
MDAwMDAwMDAwMDAwCkNPTkZJR19TRUxFQ1RfTUVNT1JZX01PREVMPXkKQ09ORklHX1NQQVJT
RU1FTV9NQU5VQUw9eQpDT05GSUdfU1BBUlNFTUVNPXkKQ09ORklHX05FRURfTVVMVElQTEVf
Tk9ERVM9eQpDT05GSUdfSEFWRV9NRU1PUllfUFJFU0VOVD15CkNPTkZJR19TUEFSU0VNRU1f
RVhUUkVNRT15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUF9FTkFCTEU9eQpDT05GSUdfU1BB
UlNFTUVNX0FMTE9DX01FTV9NQVBfVE9HRVRIRVI9eQpDT05GSUdfU1BBUlNFTUVNX1ZNRU1N
QVA9eQpDT05GSUdfSEFWRV9NRU1CTE9DSz15CkNPTkZJR19IQVZFX01FTUJMT0NLX05PREVf
TUFQPXkKQ09ORklHX0FSQ0hfRElTQ0FSRF9NRU1CTE9DSz15CiMgQ09ORklHX01PVkFCTEVf
Tk9ERSBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfQk9PVE1FTV9JTkZPX05PREUgaXMgbm90
IHNldAojIENPTkZJR19NRU1PUllfSE9UUExVRyBpcyBub3Qgc2V0CkNPTkZJR19QQUdFRkxB
R1NfRVhURU5ERUQ9eQpDT05GSUdfU1BMSVRfUFRMT0NLX0NQVVM9OTk5OTk5CkNPTkZJR19D
T01QQUNUSU9OPXkKQ09ORklHX01JR1JBVElPTj15CkNPTkZJR19QSFlTX0FERFJfVF82NEJJ
VD15CkNPTkZJR19aT05FX0RNQV9GTEFHPTEKQ09ORklHX0JPVU5DRT15CkNPTkZJR19ORUVE
X0JPVU5DRV9QT09MPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX01NVV9OT1RJRklF
Uj15CiMgQ09ORklHX0tTTSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX01NQVBfTUlOX0FE
RFI9NDA5NgpDT05GSUdfQVJDSF9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CiMgQ09ORklH
X01FTU9SWV9GQUlMVVJFIGlzIG5vdCBzZXQKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdF
PXkKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdFX0FMV0FZUz15CiMgQ09ORklHX1RSQU5T
UEFSRU5UX0hVR0VQQUdFX01BRFZJU0UgaXMgbm90IHNldApDT05GSUdfQ1JPU1NfTUVNT1JZ
X0FUVEFDSD15CiMgQ09ORklHX0NMRUFOQ0FDSEUgaXMgbm90IHNldAojIENPTkZJR19GUk9O
VFNXQVAgaXMgbm90IHNldApDT05GSUdfWDg2X0NIRUNLX0JJT1NfQ09SUlVQVElPTj15CkNP
TkZJR19YODZfQk9PVFBBUkFNX01FTU9SWV9DT1JSVVBUSU9OX0NIRUNLPXkKQ09ORklHX1g4
Nl9SRVNFUlZFX0xPVz02NApDT05GSUdfTVRSUj15CkNPTkZJR19NVFJSX1NBTklUSVpFUj15
CkNPTkZJR19NVFJSX1NBTklUSVpFUl9FTkFCTEVfREVGQVVMVD0wCkNPTkZJR19NVFJSX1NB
TklUSVpFUl9TUEFSRV9SRUdfTlJfREVGQVVMVD0xCkNPTkZJR19YODZfUEFUPXkKQ09ORklH
X0FSQ0hfVVNFU19QR19VTkNBQ0hFRD15CkNPTkZJR19BUkNIX1JBTkRPTT15CkNPTkZJR19Y
ODZfU01BUD15CiMgQ09ORklHX0VGSSBpcyBub3Qgc2V0CkNPTkZJR19TRUNDT01QPXkKIyBD
T05GSUdfQ0NfU1RBQ0tQUk9URUNUT1IgaXMgbm90IHNldAojIENPTkZJR19IWl8xMDAgaXMg
bm90IHNldAojIENPTkZJR19IWl8yNTAgaXMgbm90IHNldApDT05GSUdfSFpfMzAwPXkKIyBD
T05GSUdfSFpfMTAwMCBpcyBub3Qgc2V0CkNPTkZJR19IWj0zMDAKQ09ORklHX1NDSEVEX0hS
VElDSz15CkNPTkZJR19LRVhFQz15CkNPTkZJR19DUkFTSF9EVU1QPXkKQ09ORklHX1BIWVNJ
Q0FMX1NUQVJUPTB4MTAwMDAwMApDT05GSUdfUkVMT0NBVEFCTEU9eQpDT05GSUdfUEhZU0lD
QUxfQUxJR049MHgxMDAwMDAwCkNPTkZJR19IT1RQTFVHX0NQVT15CiMgQ09ORklHX0JPT1RQ
QVJBTV9IT1RQTFVHX0NQVTAgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19IT1RQTFVHX0NQ
VTAgaXMgbm90IHNldAojIENPTkZJR19DT01QQVRfVkRTTyBpcyBub3Qgc2V0CiMgQ09ORklH
X0NNRExJTkVfQk9PTCBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX0VOQUJMRV9NRU1PUllfSE9U
UExVRz15CkNPTkZJR19VU0VfUEVSQ1BVX05VTUFfTk9ERV9JRD15CgojCiMgUG93ZXIgbWFu
YWdlbWVudCBhbmQgQUNQSSBvcHRpb25zCiMKIyBDT05GSUdfU1VTUEVORCBpcyBub3Qgc2V0
CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKIyBDT05GSUdfSElCRVJOQVRJT04gaXMg
bm90IHNldApDT05GSUdfUE1fU0xFRVA9eQpDT05GSUdfUE1fU0xFRVBfU01QPXkKIyBDT05G
SUdfUE1fQVVUT1NMRUVQIGlzIG5vdCBzZXQKIyBDT05GSUdfUE1fV0FLRUxPQ0tTIGlzIG5v
dCBzZXQKIyBDT05GSUdfUE1fUlVOVElNRSBpcyBub3Qgc2V0CkNPTkZJR19QTT15CkNPTkZJ
R19QTV9ERUJVRz15CiMgQ09ORklHX1BNX0FEVkFOQ0VEX0RFQlVHIGlzIG5vdCBzZXQKQ09O
RklHX1BNX1NMRUVQX0RFQlVHPXkKIyBDT05GSUdfUE1fVFJBQ0VfUlRDIGlzIG5vdCBzZXQK
Q09ORklHX0FDUEk9eQpDT05GSUdfQUNQSV9QUk9DRlM9eQojIENPTkZJR19BQ1BJX1BST0NG
U19QT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfRUNfREVCVUdGUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDUElfUFJPQ19FVkVOVCBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0FDPXkK
Q09ORklHX0FDUElfQkFUVEVSWT15CkNPTkZJR19BQ1BJX0JVVFRPTj15CkNPTkZJR19BQ1BJ
X1ZJREVPPXkKQ09ORklHX0FDUElfRkFOPXkKIyBDT05GSUdfQUNQSV9ET0NLIGlzIG5vdCBz
ZXQKQ09ORklHX0FDUElfSTJDPXkKQ09ORklHX0FDUElfUFJPQ0VTU09SPXkKQ09ORklHX0FD
UElfSE9UUExVR19DUFU9eQojIENPTkZJR19BQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SIGlz
IG5vdCBzZXQKQ09ORklHX0FDUElfVEhFUk1BTD15CkNPTkZJR19BQ1BJX05VTUE9eQpDT05G
SUdfQUNQSV9DVVNUT01fRFNEVF9GSUxFPSIiCiMgQ09ORklHX0FDUElfQ1VTVE9NX0RTRFQg
aXMgbm90IHNldAojIENPTkZJR19BQ1BJX0lOSVRSRF9UQUJMRV9PVkVSUklERSBpcyBub3Qg
c2V0CkNPTkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdfQUNQSV9ERUJVRyBp
cyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9QTV9USU1FUj15
CkNPTkZJR19BQ1BJX0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfU0JTIGlzIG5vdCBzZXQK
Q09ORklHX0FDUElfSEVEPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fTUVUSE9EIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQUNQSV9BUEVJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZJIGlzIG5vdCBz
ZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdfQ1BVX0ZSRVE9eQpDT05G
SUdfQ1BVX0ZSRVFfVEFCTEU9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTU1PTj15CiMgQ09O
RklHX0NQVV9GUkVRX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxU
X0dPVl9QRVJGT1JNQU5DRSBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dP
Vl9VU0VSU1BBQ0U9eQojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9PTkRFTUFORCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09WX0NPTlNFUlZBVElWRSBp
cyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9HT1ZfUEVSRk9STUFOQ0U9eQojIENPTkZJR19D
UFVfRlJFUV9HT1ZfUE9XRVJTQVZFIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9GUkVRX0dPVl9V
U0VSU1BBQ0U9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX09OREVNQU5EPXkKIyBDT05GSUdfQ1BV
X0ZSRVFfR09WX0NPTlNFUlZBVElWRSBpcyBub3Qgc2V0CgojCiMgeDg2IENQVSBmcmVxdWVu
Y3kgc2NhbGluZyBkcml2ZXJzCiMKIyBDT05GSUdfWDg2X0lOVEVMX1BTVEFURSBpcyBub3Qg
c2V0CkNPTkZJR19YODZfUENDX0NQVUZSRVE9eQpDT05GSUdfWDg2X0FDUElfQ1BVRlJFUT15
CkNPTkZJR19YODZfQUNQSV9DUFVGUkVRX0NQQj15CiMgQ09ORklHX1g4Nl9QT1dFUk5PV19L
OCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk8gaXMgbm90IHNl
dAojIENPTkZJR19YODZfUDRfQ0xPQ0tNT0QgaXMgbm90IHNldAoKIwojIHNoYXJlZCBvcHRp
b25zCiMKIyBDT05GSUdfWDg2X1NQRUVEU1RFUF9MSUIgaXMgbm90IHNldApDT05GSUdfQ1BV
X0lETEU9eQojIENPTkZJR19DUFVfSURMRV9NVUxUSVBMRV9EUklWRVJTIGlzIG5vdCBzZXQK
Q09ORklHX0NQVV9JRExFX0dPVl9MQURERVI9eQpDT05GSUdfQ1BVX0lETEVfR09WX01FTlU9
eQojIENPTkZJR19BUkNIX05FRURTX0NQVV9JRExFX0NPVVBMRUQgaXMgbm90IHNldAojIENP
TkZJR19JTlRFTF9JRExFIGlzIG5vdCBzZXQKCiMKIyBNZW1vcnkgcG93ZXIgc2F2aW5ncwoj
CiMgQ09ORklHX0k3MzAwX0lETEUgaXMgbm90IHNldAoKIwojIEJ1cyBvcHRpb25zIChQQ0kg
ZXRjLikKIwpDT05GSUdfUENJPXkKQ09ORklHX1BDSV9ESVJFQ1Q9eQpDT05GSUdfUENJX01N
Q09ORklHPXkKQ09ORklHX1BDSV9YRU49eQpDT05GSUdfUENJX0RPTUFJTlM9eQpDT05GSUdf
UENJRVBPUlRCVVM9eQpDT05GSUdfSE9UUExVR19QQ0lfUENJRT15CkNPTkZJR19QQ0lFQUVS
PXkKQ09ORklHX1BDSUVfRUNSQz15CkNPTkZJR19QQ0lFQUVSX0lOSkVDVD15CkNPTkZJR19Q
Q0lFQVNQTT15CkNPTkZJR19QQ0lFQVNQTV9ERUJVRz15CkNPTkZJR19QQ0lFQVNQTV9ERUZB
VUxUPXkKIyBDT05GSUdfUENJRUFTUE1fUE9XRVJTQVZFIGlzIG5vdCBzZXQKIyBDT05GSUdf
UENJRUFTUE1fUEVSRk9STUFOQ0UgaXMgbm90IHNldApDT05GSUdfQVJDSF9TVVBQT1JUU19N
U0k9eQpDT05GSUdfUENJX01TST15CkNPTkZJR19QQ0lfREVCVUc9eQpDT05GSUdfUENJX1JF
QUxMT0NfRU5BQkxFX0FVVE89eQojIENPTkZJR19QQ0lfU1RVQiBpcyBub3Qgc2V0CkNPTkZJ
R19YRU5fUENJREVWX0ZST05URU5EPXkKQ09ORklHX0hUX0lSUT15CkNPTkZJR19QQ0lfQVRT
PXkKQ09ORklHX1BDSV9JT1Y9eQpDT05GSUdfUENJX1BSST15CkNPTkZJR19QQ0lfUEFTSUQ9
eQpDT05GSUdfUENJX0lPQVBJQz15CkNPTkZJR19QQ0lfTEFCRUw9eQpDT05GSUdfSVNBX0RN
QV9BUEk9eQpDT05GSUdfQU1EX05CPXkKQ09ORklHX1BDQ0FSRD15CiMgQ09ORklHX1BDTUNJ
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0NBUkRCVVMgaXMgbm90IHNldAoKIwojIFBDLWNhcmQg
YnJpZGdlcwojCiMgQ09ORklHX1lFTlRBIGlzIG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJ
PXkKQ09ORklHX0hPVFBMVUdfUENJX0FDUEk9eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQSV9J
Qk09eQpDT05GSUdfSE9UUExVR19QQ0lfQ1BDST15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJ
X1pUNTU1MD15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJX0dFTkVSSUM9eQpDT05GSUdfSE9U
UExVR19QQ0lfU0hQQz15CiMgQ09ORklHX1JBUElESU8gaXMgbm90IHNldAoKIwojIEV4ZWN1
dGFibGUgZmlsZSBmb3JtYXRzIC8gRW11bGF0aW9ucwojCkNPTkZJR19CSU5GTVRfRUxGPXkK
Q09ORklHX0NPTVBBVF9CSU5GTVRfRUxGPXkKQ09ORklHX0FSQ0hfQklORk1UX0VMRl9SQU5E
T01JWkVfUElFPXkKQ09ORklHX0NPUkVfRFVNUF9ERUZBVUxUX0VMRl9IRUFERVJTPXkKIyBD
T05GSUdfSEFWRV9BT1VUIGlzIG5vdCBzZXQKQ09ORklHX0JJTkZNVF9NSVNDPXkKQ09ORklH
X0NPUkVEVU1QPXkKQ09ORklHX0lBMzJfRU1VTEFUSU9OPXkKIyBDT05GSUdfSUEzMl9BT1VU
IGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1gzMiBpcyBub3Qgc2V0CkNPTkZJR19DT01QQVQ9
eQpDT05GSUdfQ09NUEFUX0ZPUl9VNjRfQUxJR05NRU5UPXkKQ09ORklHX1NZU1ZJUENfQ09N
UEFUPXkKQ09ORklHX0tFWVNfQ09NUEFUPXkKQ09ORklHX0hBVkVfVEVYVF9QT0tFX1NNUD15
CkNPTkZJR19YODZfREVWX0RNQV9PUFM9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5n
IG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKIyBDT05GSUdfUEFDS0VUX0RJQUcgaXMgbm90
IHNldApDT05GSUdfVU5JWD15CiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qgc2V0CiMgQ09O
RklHX1hGUk1fVVNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9LRVkgaXMgbm90IHNldApD
T05GSUdfSU5FVD15CkNPTkZJR19JUF9NVUxUSUNBU1Q9eQpDT05GSUdfSVBfQURWQU5DRURf
Uk9VVEVSPXkKIyBDT05GSUdfSVBfRklCX1RSSUVfU1RBVFMgaXMgbm90IHNldApDT05GSUdf
SVBfTVVMVElQTEVfVEFCTEVTPXkKQ09ORklHX0lQX1JPVVRFX01VTFRJUEFUSD15CkNPTkZJ
R19JUF9ST1VURV9WRVJCT1NFPXkKQ09ORklHX0lQX1JPVVRFX0NMQVNTSUQ9eQpDT05GSUdf
SVBfUE5QPXkKQ09ORklHX0lQX1BOUF9ESENQPXkKQ09ORklHX0lQX1BOUF9CT09UUD15CkNP
TkZJR19JUF9QTlBfUkFSUD15CiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0lQR1JFX0RFTVVYIGlzIG5vdCBzZXQKQ09ORklHX0lQX01ST1VURT15CiMgQ09O
RklHX0lQX01ST1VURV9NVUxUSVBMRV9UQUJMRVMgaXMgbm90IHNldApDT05GSUdfSVBfUElN
U01fVjE9eQpDT05GSUdfSVBfUElNU01fVjI9eQojIENPTkZJR19BUlBEIGlzIG5vdCBzZXQK
Q09ORklHX1NZTl9DT09LSUVTPXkKIyBDT05GSUdfSU5FVF9BSCBpcyBub3Qgc2V0CiMgQ09O
RklHX0lORVRfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9JUENPTVAgaXMgbm90IHNl
dAojIENPTkZJR19JTkVUX1hGUk1fVFVOTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9U
VU5ORUwgaXMgbm90IHNldAojIENPTkZJR19JTkVUX1hGUk1fTU9ERV9UUkFOU1BPUlQgaXMg
bm90IHNldAojIENPTkZJR19JTkVUX1hGUk1fTU9ERV9UVU5ORUwgaXMgbm90IHNldAojIENP
TkZJR19JTkVUX1hGUk1fTU9ERV9CRUVUIGlzIG5vdCBzZXQKQ09ORklHX0lORVRfTFJPPXkK
IyBDT05GSUdfSU5FVF9ESUFHIGlzIG5vdCBzZXQKQ09ORklHX1RDUF9DT05HX0FEVkFOQ0VE
PXkKIyBDT05GSUdfVENQX0NPTkdfQklDIGlzIG5vdCBzZXQKQ09ORklHX1RDUF9DT05HX0NV
QklDPXkKIyBDT05GSUdfVENQX0NPTkdfV0VTVFdPT0QgaXMgbm90IHNldAojIENPTkZJR19U
Q1BfQ09OR19IVENQIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfSFNUQ1AgaXMgbm90
IHNldAojIENPTkZJR19UQ1BfQ09OR19IWUJMQSBpcyBub3Qgc2V0CiMgQ09ORklHX1RDUF9D
T05HX1ZFR0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfU0NBTEFCTEUgaXMgbm90
IHNldAojIENPTkZJR19UQ1BfQ09OR19MUCBpcyBub3Qgc2V0CiMgQ09ORklHX1RDUF9DT05H
X1ZFTk8gaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19ZRUFIIGlzIG5vdCBzZXQKIyBD
T05GSUdfVENQX0NPTkdfSUxMSU5PSVMgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9DVUJJ
Qz15CiMgQ09ORklHX0RFRkFVTFRfUkVOTyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX1RD
UF9DT05HPSJjdWJpYyIKIyBDT05GSUdfVENQX01ENVNJRyBpcyBub3Qgc2V0CiMgQ09ORklH
X0lQVjYgaXMgbm90IHNldApDT05GSUdfTkVUV09SS19TRUNNQVJLPXkKIyBDT05GSUdfTkVU
V09SS19QSFlfVElNRVNUQU1QSU5HIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUj15CiMg
Q09ORklHX05FVEZJTFRFUl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfQURW
QU5DRUQ9eQpDT05GSUdfQlJJREdFX05FVEZJTFRFUj15CgojCiMgQ29yZSBOZXRmaWx0ZXIg
Q29uZmlndXJhdGlvbgojCkNPTkZJR19ORVRGSUxURVJfTkVUTElOSz15CkNPTkZJR19ORVRG
SUxURVJfTkVUTElOS19BQ0NUPXkKQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFPXkK
Q09ORklHX05FVEZJTFRFUl9ORVRMSU5LX0xPRz15CkNPTkZJR19ORl9DT05OVFJBQ0s9eQpD
T05GSUdfTkZfQ09OTlRSQUNLX01BUks9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1NFQ01BUks9
eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NGUz15CkNPTkZJR19ORl9DT05OVFJBQ0tfRVZF
TlRTPXkKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RJTUVPVVQgaXMgbm90IHNldApDT05GSUdf
TkZfQ09OTlRSQUNLX1RJTUVTVEFNUD15CiMgQ09ORklHX05GX0NUX1BST1RPX0RDQ1AgaXMg
bm90IHNldApDT05GSUdfTkZfQ1RfUFJPVE9fR1JFPXkKIyBDT05GSUdfTkZfQ1RfUFJPVE9f
U0NUUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NUX1BST1RPX1VEUExJVEUgaXMgbm90IHNl
dAojIENPTkZJR19ORl9DT05OVFJBQ0tfQU1BTkRBIGlzIG5vdCBzZXQKQ09ORklHX05GX0NP
Tk5UUkFDS19GVFA9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0gzMjM9eQpDT05GSUdfTkZfQ09O
TlRSQUNLX0lSQz15CiMgQ09ORklHX05GX0NPTk5UUkFDS19ORVRCSU9TX05TIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NOTVAgaXMgbm90IHNldApDT05GSUdfTkZfQ09O
TlRSQUNLX1BQVFA9eQojIENPTkZJR19ORl9DT05OVFJBQ0tfU0FORSBpcyBub3Qgc2V0CkNP
TkZJR19ORl9DT05OVFJBQ0tfU0lQPXkKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RGVFAgaXMg
bm90IHNldApDT05GSUdfTkZfQ1RfTkVUTElOSz15CiMgQ09ORklHX05GX0NUX05FVExJTktf
VElNRU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFX0NU
IGlzIG5vdCBzZXQKQ09ORklHX05GX05BVD15CkNPTkZJR19ORl9OQVRfTkVFREVEPXkKIyBD
T05GSUdfTkZfTkFUX0FNQU5EQSBpcyBub3Qgc2V0CkNPTkZJR19ORl9OQVRfRlRQPXkKQ09O
RklHX05GX05BVF9JUkM9eQpDT05GSUdfTkZfTkFUX1NJUD15CiMgQ09ORklHX05GX05BVF9U
RlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1RQUk9YWSBpcyBub3Qgc2V0CkNP
TkZJR19ORVRGSUxURVJfWFRBQkxFUz15CgojCiMgWHRhYmxlcyBjb21iaW5lZCBtb2R1bGVz
CiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9DT05O
TUFSSz15CiMgQ09ORklHX05FVEZJTFRFUl9YVF9TRVQgaXMgbm90IHNldAoKIwojIFh0YWJs
ZXMgdGFyZ2V0cwojCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0FVRElUPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfQ0hFQ0tTVU09eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9DTEFTU0lGWT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5NQVJLPXkK
Q09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ09OTlNFQ01BUks9eQojIENPTkZJR19ORVRG
SUxURVJfWFRfVEFSR0VUX0NUIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJH
RVRfRFNDUD15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0hMPXkKIyBDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9ITUFSSyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRf
VEFSR0VUX0lETEVUSU1FUj15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0xPRz15CkNP
TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9ORVRNQVA9eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORkxPRz15CkNPTkZJ
R19ORVRGSUxURVJfWFRfVEFSR0VUX05GUVVFVUU9eQojIENPTkZJR19ORVRGSUxURVJfWFRf
VEFSR0VUX05PVFJBQ0sgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9S
QVRFRVNUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfUkVESVJFQ1Q9eQpDT05GSUdf
TkVURklMVEVSX1hUX1RBUkdFVF9URUU9eQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU
X1RSQUNFIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfU0VDTUFSSz15
CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RDUE1TUz15CiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfVENQT1BUU1RSSVAgaXMgbm90IHNldAoKIwojIFh0YWJsZXMgbWF0Y2hl
cwojCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQUREUlRZUEU9eQojIENPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfQlBGIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRD
SF9DTFVTVEVSPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9DT05OQllURVM9eQojIENPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfQ09OTkxBQkVMIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9D
T05OTElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5NQVJLPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJBQ0s9eQpDT05GSUdfTkVURklMVEVSX1hUX01B
VENIX0NQVT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRENDUD15CkNPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RT
Q1A9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VDTj15CkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfRVNQPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQ9eQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0hFTFBFUj15CkNPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfSEw9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0U9eQpDT05GSUdf
TkVURklMVEVSX1hUX01BVENIX0lQVlM9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xF
TkdUSD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQ9eQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX01BQz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz15CkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUPXkKQ09ORklHX05FVEZJTFRFUl9Y
VF9NQVRDSF9ORkFDQ1Q9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09TRj15CkNPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfT1dORVI9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X1BIWVNERVY9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEU9eQpDT05GSUdf
TkVURklMVEVSX1hUX01BVENIX1FVT1RBPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9S
QVRFRVNUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SRUFMTT15CkNPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfUkVDRU5UPXkKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1ND
VFAgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRFPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9TVEFUSVNUSUM9eQpDT05GSUdfTkVURklMVEVSX1hUX01B
VENIX1NUUklORz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVENQTVNTPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9USU1FPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9V
MzI9eQpDT05GSUdfSVBfU0VUPXkKQ09ORklHX0lQX1NFVF9NQVg9MjU2CkNPTkZJR19JUF9T
RVRfQklUTUFQX0lQPXkKQ09ORklHX0lQX1NFVF9CSVRNQVBfSVBNQUM9eQpDT05GSUdfSVBf
U0VUX0JJVE1BUF9QT1JUPXkKQ09ORklHX0lQX1NFVF9IQVNIX0lQPXkKQ09ORklHX0lQX1NF
VF9IQVNIX0lQUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9JUFBPUlRJUD15CkNPTkZJR19J
UF9TRVRfSEFTSF9JUFBPUlRORVQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUPXkKQ09ORklH
X0lQX1NFVF9IQVNIX05FVFBPUlQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUSUZBQ0U9eQpD
T05GSUdfSVBfU0VUX0xJU1RfU0VUPXkKQ09ORklHX0lQX1ZTPXkKIyBDT05GSUdfSVBfVlNf
REVCVUcgaXMgbm90IHNldApDT05GSUdfSVBfVlNfVEFCX0JJVFM9MTIKCiMKIyBJUFZTIHRy
YW5zcG9ydCBwcm90b2NvbCBsb2FkIGJhbGFuY2luZyBzdXBwb3J0CiMKIyBDT05GSUdfSVBf
VlNfUFJPVE9fVENQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fVURQIGlzIG5v
dCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fQUhfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdf
SVBfVlNfUFJPVE9fRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fQUggaXMg
bm90IHNldAojIENPTkZJR19JUF9WU19QUk9UT19TQ1RQIGlzIG5vdCBzZXQKCiMKIyBJUFZT
IHNjaGVkdWxlcgojCiMgQ09ORklHX0lQX1ZTX1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBf
VlNfV1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTEMgaXMgbm90IHNldAojIENPTkZJ
R19JUF9WU19XTEMgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19MQkxDIGlzIG5vdCBzZXQK
IyBDT05GSUdfSVBfVlNfTEJMQ1IgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19ESCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lQX1ZTX1NIIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfU0VE
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTlEgaXMgbm90IHNldAoKIwojIElQVlMgU0gg
c2NoZWR1bGVyCiMKQ09ORklHX0lQX1ZTX1NIX1RBQl9CSVRTPTgKCiMKIyBJUFZTIGFwcGxp
Y2F0aW9uIGhlbHBlcgojCkNPTkZJR19JUF9WU19ORkNUPXkKCiMKIyBJUDogTmV0ZmlsdGVy
IENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05GSUdfTkZfQ09O
TlRSQUNLX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkKIyBDT05G
SUdfSVBfTkZfUVVFVUUgaXMgbm90IHNldApDT05GSUdfSVBfTkZfSVBUQUJMRVM9eQpDT05G
SUdfSVBfTkZfTUFUQ0hfQUg9eQpDT05GSUdfSVBfTkZfTUFUQ0hfRUNOPXkKIyBDT05GSUdf
SVBfTkZfTUFUQ0hfUlBGSUxURVIgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTUFUQ0hfVFRM
PXkKQ09ORklHX0lQX05GX0ZJTFRFUj15CkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPXkK
Q09ORklHX0lQX05GX1RBUkdFVF9VTE9HPXkKQ09ORklHX05GX05BVF9JUFY0PXkKQ09ORklH
X0lQX05GX1RBUkdFVF9NQVNRVUVSQURFPXkKQ09ORklHX0lQX05GX1RBUkdFVF9ORVRNQVA9
eQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFRElSRUNUPXkKQ09ORklHX05GX05BVF9QUk9UT19H
UkU9eQpDT05GSUdfTkZfTkFUX1BQVFA9eQpDT05GSUdfTkZfTkFUX0gzMjM9eQpDT05GSUdf
SVBfTkZfTUFOR0xFPXkKIyBDT05GSUdfSVBfTkZfVEFSR0VUX0NMVVNURVJJUCBpcyBub3Qg
c2V0CiMgQ09ORklHX0lQX05GX1RBUkdFVF9FQ04gaXMgbm90IHNldAojIENPTkZJR19JUF9O
Rl9UQVJHRVRfVFRMIGlzIG5vdCBzZXQKQ09ORklHX0lQX05GX1JBVz15CiMgQ09ORklHX0lQ
X05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0CkNPTkZJR19CUklER0VfTkZfRUJUQUJMRVM9eQoj
IENPTkZJR19CUklER0VfRUJUX0JST1VURSBpcyBub3Qgc2V0CiMgQ09ORklHX0JSSURHRV9F
QlRfVF9GSUxURVIgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1RfTkFUIGlzIG5v
dCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF84MDJfMyBpcyBub3Qgc2V0CiMgQ09ORklHX0JS
SURHRV9FQlRfQU1PTkcgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX0FSUCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfSVAgaXMgbm90IHNldAojIENPTkZJR19CUklE
R0VfRUJUX0xJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9NQVJLIGlzIG5v
dCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9QS1RUWVBFIGlzIG5vdCBzZXQKIyBDT05GSUdf
QlJJREdFX0VCVF9TVFAgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1ZMQU4gaXMg
bm90IHNldAojIENPTkZJR19CUklER0VfRUJUX0FSUFJFUExZIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlJJREdFX0VCVF9ETkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9NQVJL
X1QgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1JFRElSRUNUIGlzIG5vdCBzZXQK
IyBDT05GSUdfQlJJREdFX0VCVF9TTkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VC
VF9MT0cgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1VMT0cgaXMgbm90IHNldAoj
IENPTkZJR19CUklER0VfRUJUX05GTE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfRENDUCBp
cyBub3Qgc2V0CiMgQ09ORklHX0lQX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19SRFMgaXMg
bm90IHNldAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9eQpDT05GSUdfQlJJREdF
PXkKQ09ORklHX0JSSURHRV9JR01QX1NOT09QSU5HPXkKQ09ORklHX0hBVkVfTkVUX0RTQT15
CiMgQ09ORklHX1ZMQU5fODAyMVEgaXMgbm90IHNldAojIENPTkZJR19ERUNORVQgaXMgbm90
IHNldApDT05GSUdfTExDPXkKIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQ
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBDT05GSUdfWDI1IGlz
IG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklHX1BIT05FVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lFRUU4MDIxNTQgaXMgbm90IHNldApDT05GSUdfTkVUX1NDSEVE
PXkKCiMKIyBRdWV1ZWluZy9TY2hlZHVsaW5nCiMKIyBDT05GSUdfTkVUX1NDSF9DQlEgaXMg
bm90IHNldAojIENPTkZJR19ORVRfU0NIX0hUQiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9T
Q0hfSEZTQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUFJJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9TQ0hfTVVMVElRIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9SRUQg
aXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1NGQiBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VF9TQ0hfU0ZRIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9URVFMIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1NDSF9UQkYgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0dSRUQg
aXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0RTTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9TQ0hfTkVURU0gaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0RSUiBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9TQ0hfTVFQUklPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ND
SF9DSE9LRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUUZRIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1NDSF9DT0RFTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfRlFfQ09E
RUwgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0lOR1JFU1MgaXMgbm90IHNldAojIENP
TkZJR19ORVRfU0NIX1BMVUcgaXMgbm90IHNldAoKIwojIENsYXNzaWZpY2F0aW9uCiMKQ09O
RklHX05FVF9DTFM9eQojIENPTkZJR19ORVRfQ0xTX0JBU0lDIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0NMU19UQ0lOREVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19ST1VURTQg
aXMgbm90IHNldAojIENPTkZJR19ORVRfQ0xTX0ZXIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X0NMU19VMzIgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0xTX1JTVlAgaXMgbm90IHNldAoj
IENPTkZJR19ORVRfQ0xTX1JTVlA2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19GTE9X
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19DR1JPVVAgaXMgbm90IHNldApDT05GSUdf
TkVUX0VNQVRDSD15CkNPTkZJR19ORVRfRU1BVENIX1NUQUNLPTMyCiMgQ09ORklHX05FVF9F
TUFUQ0hfQ01QIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0VNQVRDSF9OQllURSBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfVTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0VN
QVRDSF9NRVRBIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0VNQVRDSF9URVhUIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkVUX0VNQVRDSF9JUFNFVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfQ0xT
X0FDVD15CiMgQ09ORklHX05FVF9BQ1RfUE9MSUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X0FDVF9HQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0FDVF9NSVJSRUQgaXMgbm90IHNl
dAojIENPTkZJR19ORVRfQUNUX0lQVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfTkFU
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0FDVF9QRURJVCBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9BQ1RfU0lNUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfU0tCRURJVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfQ1NVTSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfU0NI
X0ZJRk89eQojIENPTkZJR19EQ0IgaXMgbm90IHNldAojIENPTkZJR19ETlNfUkVTT0xWRVIg
aXMgbm90IHNldAojIENPTkZJR19CQVRNQU5fQURWIGlzIG5vdCBzZXQKIyBDT05GSUdfT1BF
TlZTV0lUQ0ggaXMgbm90IHNldAojIENPTkZJR19WU09DS0VUUyBpcyBub3Qgc2V0CkNPTkZJ
R19SUFM9eQpDT05GSUdfUkZTX0FDQ0VMPXkKQ09ORklHX1hQUz15CiMgQ09ORklHX05FVFBS
SU9fQ0dST1VQIGlzIG5vdCBzZXQKQ09ORklHX0JRTD15CiMgQ09ORklHX0JQRl9KSVQgaXMg
bm90IHNldAoKIwojIE5ldHdvcmsgdGVzdGluZwojCiMgQ09ORklHX05FVF9QS1RHRU4gaXMg
bm90IHNldAojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldApDT05GSUdfQlQ9eQpDT05GSUdfQlRf
UkZDT01NPXkKQ09ORklHX0JUX1JGQ09NTV9UVFk9eQpDT05GSUdfQlRfQk5FUD15CkNPTkZJ
R19CVF9CTkVQX01DX0ZJTFRFUj15CkNPTkZJR19CVF9CTkVQX1BST1RPX0ZJTFRFUj15CkNP
TkZJR19CVF9ISURQPXkKCiMKIyBCbHVldG9vdGggZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdf
QlRfSENJQlRVU0I9eQpDT05GSUdfQlRfSENJVUFSVD15CkNPTkZJR19CVF9IQ0lVQVJUX0g0
PXkKQ09ORklHX0JUX0hDSVVBUlRfQkNTUD15CkNPTkZJR19CVF9IQ0lVQVJUX0FUSDNLPXkK
Q09ORklHX0JUX0hDSVVBUlRfTEw9eQpDT05GSUdfQlRfSENJVUFSVF8zV0lSRT15CkNPTkZJ
R19CVF9IQ0lCQ00yMDNYPXkKQ09ORklHX0JUX0hDSUJQQTEwWD15CkNPTkZJR19CVF9IQ0lC
RlVTQj15CkNPTkZJR19CVF9IQ0lWSENJPXkKQ09ORklHX0JUX01SVkw9eQpDT05GSUdfQlRf
QVRIM0s9eQojIENPTkZJR19BRl9SWFJQQyBpcyBub3Qgc2V0CkNPTkZJR19GSUJfUlVMRVM9
eQpDT05GSUdfV0lSRUxFU1M9eQojIENPTkZJR19DRkc4MDIxMSBpcyBub3Qgc2V0CiMgQ09O
RklHX0xJQjgwMjExIGlzIG5vdCBzZXQKCiMKIyBDRkc4MDIxMSBuZWVkcyB0byBiZSBlbmFi
bGVkIGZvciBNQUM4MDIxMQojCiMgQ09ORklHX1dJTUFYIGlzIG5vdCBzZXQKIyBDT05GSUdf
UkZLSUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUXzlQIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q0FJRiBpcyBub3Qgc2V0CkNPTkZJR19DRVBIX0xJQj15CiMgQ09ORklHX0NFUEhfTElCX1BS
RVRUWURFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUJfVVNFX0ROU19SRVNPTFZF
UiBpcyBub3Qgc2V0CiMgQ09ORklHX05GQyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0JQRl9K
SVQ9eQoKIwojIERldmljZSBEcml2ZXJzCiMKCiMKIyBHZW5lcmljIERyaXZlciBPcHRpb25z
CiMKQ09ORklHX1VFVkVOVF9IRUxQRVJfUEFUSD0iL3NiaW4vaG90cGx1ZyIKQ09ORklHX0RF
VlRNUEZTPXkKQ09ORklHX0RFVlRNUEZTX01PVU5UPXkKIyBDT05GSUdfU1RBTkRBTE9ORSBp
cyBub3Qgc2V0CiMgQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJTEQgaXMgbm90IHNldApD
T05GSUdfRldfTE9BREVSPXkKQ09ORklHX0ZJUk1XQVJFX0lOX0tFUk5FTD15CkNPTkZJR19F
WFRSQV9GSVJNV0FSRT0iIgpDT05GSUdfRldfTE9BREVSX1VTRVJfSEVMUEVSPXkKQ09ORklH
X0RFQlVHX0RSSVZFUj15CkNPTkZJR19ERUJVR19ERVZSRVM9eQpDT05GSUdfU1lTX0hZUEVS
VklTT1I9eQojIENPTkZJR19HRU5FUklDX0NQVV9ERVZJQ0VTIGlzIG5vdCBzZXQKQ09ORklH
X0RNQV9TSEFSRURfQlVGRkVSPXkKCiMKIyBCdXMgZGV2aWNlcwojCkNPTkZJR19DT05ORUNU
T1I9eQpDT05GSUdfUFJPQ19FVkVOVFM9eQojIENPTkZJR19NVEQgaXMgbm90IHNldAojIENP
TkZJR19QQVJQT1JUIGlzIG5vdCBzZXQKQ09ORklHX1BOUD15CkNPTkZJR19QTlBfREVCVUdf
TUVTU0FHRVM9eQoKIwojIFByb3RvY29scwojCkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JM
S19ERVY9eQojIENPTkZJR19CTEtfREVWX0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9QQ0lFU1NEX01USVAzMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JM
S19ERVZfREFDOTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9VTUVNIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E
RVZfTE9PUD15CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5UPTgKIyBDT05GSUdfQkxL
X0RFVl9DUllQVE9MT09QIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9EUkJEIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVW
X05WTUUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NYOCBpcyBub3Qgc2V0CkNPTkZJ
R19CTEtfREVWX1JBTT15CkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfQkxL
X0RFVl9SQU1fU0laRT0xNjM4NAojIENPTkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CiMg
Q09ORklHX0NEUk9NX1BLVENEVkQgaXMgbm90IHNldAojIENPTkZJR19BVEFfT1ZFUl9FVEgg
aXMgbm90IHNldApDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxL
REVWX0JBQ0tFTkQ9eQojIENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkxLX0RFVl9SQkQgaXMgbm90IHNldAoKIwojIE1pc2MgZGV2aWNlcwojCiMgQ09ORklHX1NF
TlNPUlNfTElTM0xWMDJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90
IHNldAojIENPTkZJR19JQk1fQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lOVEVMX01JRF9QVEkgaXMgbm90IHNldAojIENPTkZJR19TR0lf
SU9DNCBpcyBub3Qgc2V0CiMgQ09ORklHX1RJRk1fQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklH
X0lDUzkzMlM0MDEgaXMgbm90IHNldAojIENPTkZJR19BVE1FTF9TU0MgaXMgbm90IHNldAoj
IENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldAojIENPTkZJR19IUF9JTE8g
aXMgbm90IHNldAojIENPTkZJR19BUERTOTgwMkFMUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lT
TDI5MDAzIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNldAojIENPTkZJ
R19TRU5TT1JTX1RTTDI1NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc4MCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19BUERTOTkwWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90IHNl
dAojIENPTkZJR19EUzE2ODIgaXMgbm90IHNldAojIENPTkZJR19WTVdBUkVfQkFMTE9PTiBp
cyBub3Qgc2V0CiMgQ09ORklHX0JNUDA4NV9JMkMgaXMgbm90IHNldAojIENPTkZJR19QQ0hf
UEhVQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TV0lUQ0hfRlNBOTQ4MCBpcyBub3Qgc2V0
CiMgQ09ORklHX0MyUE9SVCBpcyBub3Qgc2V0CgojCiMgRUVQUk9NIHN1cHBvcnQKIwojIENP
TkZJR19FRVBST01fQVQyNCBpcyBub3Qgc2V0CiMgQ09ORklHX0VFUFJPTV9MRUdBQ1kgaXMg
bm90IHNldAojIENPTkZJR19FRVBST01fTUFYNjg3NSBpcyBub3Qgc2V0CiMgQ09ORklHX0VF
UFJPTV85M0NYNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NCNzEwX0NPUkUgaXMgbm90IHNldAoK
IwojIFRleGFzIEluc3RydW1lbnRzIHNoYXJlZCB0cmFuc3BvcnQgbGluZSBkaXNjaXBsaW5l
CiMKIyBDT05GSUdfU0VOU09SU19MSVMzX0kyQyBpcyBub3Qgc2V0CgojCiMgQWx0ZXJhIEZQ
R0EgZmlybXdhcmUgZG93bmxvYWQgbW9kdWxlCiMKQ09ORklHX0FMVEVSQV9TVEFQTD15CiMg
Q09ORklHX0lOVEVMX01FSSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNV0FSRV9WTUNJIGlzIG5v
dCBzZXQKQ09ORklHX0hBVkVfSURFPXkKIyBDT05GSUdfSURFIGlzIG5vdCBzZXQKCiMKIyBT
Q1NJIGRldmljZSBzdXBwb3J0CiMKQ09ORklHX1NDU0lfTU9EPXkKIyBDT05GSUdfUkFJRF9B
VFRSUyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJPXkKQ09ORklHX1NDU0lfRE1BPXkKIyBDT05G
SUdfU0NTSV9UR1QgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX05FVExJTksgaXMgbm90IHNl
dApDT05GSUdfU0NTSV9QUk9DX0ZTPXkKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywg
dGFwZSwgQ0QtUk9NKQojCkNPTkZJR19CTEtfREVWX1NEPXkKIyBDT05GSUdfQ0hSX0RFVl9T
VCBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0CkNPTkZJR19C
TEtfREVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX0NIUl9ERVZf
U0c9eQojIENPTkZJR19DSFJfREVWX1NDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTVVM
VElfTFVOIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfQ09OU1RBTlRTPXkKIyBDT05GSUdfU0NT
SV9MT0dHSU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQ0FOX0FTWU5DIGlzIG5vdCBz
ZXQKCiMKIyBTQ1NJIFRyYW5zcG9ydHMKIwpDT05GSUdfU0NTSV9TUElfQVRUUlM9eQojIENP
TkZJR19TQ1NJX0ZDX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JU0NTSV9BVFRS
UyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0FTX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0NTSV9TQVNfTElCU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TUlBfQVRUUlMg
aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0xPV0xFVkVMIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0NTSV9ESCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qg
c2V0CkNPTkZJR19BVEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApD
T05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9eQojIENPTkZJR19T
QVRBX1pQT0REIGlzIG5vdCBzZXQKQ09ORklHX1NBVEFfUE1QPXkKCiMKIyBDb250cm9sbGVy
cyB3aXRoIG5vbi1TRkYgbmF0aXZlIGludGVyZmFjZQojCkNPTkZJR19TQVRBX0FIQ0k9eQpD
T05GSUdfU0FUQV9BSENJX1BMQVRGT1JNPXkKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NBVEFfQUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NB
VEFfU0lMMjQgaXMgbm90IHNldAojIENPTkZJR19BVEFfU0ZGIGlzIG5vdCBzZXQKQ09ORklH
X01EPXkKIyBDT05GSUdfQkxLX0RFVl9NRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0RN
PXkKQ09ORklHX0RNX0RFQlVHPXkKQ09ORklHX0RNX0NSWVBUPXkKQ09ORklHX0RNX1NOQVBT
SE9UPXkKIyBDT05GSUdfRE1fVEhJTl9QUk9WSVNJT05JTkcgaXMgbm90IHNldApDT05GSUdf
RE1fTUlSUk9SPXkKIyBDT05GSUdfRE1fUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0xP
R19VU0VSU1BBQ0UgaXMgbm90IHNldApDT05GSUdfRE1fWkVSTz15CiMgQ09ORklHX0RNX01V
TFRJUEFUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQKIyBDT05G
SUdfRE1fVUVWRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fRkxBS0VZIGlzIG5vdCBzZXQK
IyBDT05GSUdfRE1fVkVSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFSR0VUX0NPUkUgaXMg
bm90IHNldAojIENPTkZJR19GVVNJT04gaXMgbm90IHNldAoKIwojIElFRUUgMTM5NCAoRmly
ZVdpcmUpIHN1cHBvcnQKIwojIENPTkZJR19GSVJFV0lSRSBpcyBub3Qgc2V0CiMgQ09ORklH
X0ZJUkVXSVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJR19JMk8gaXMgbm90IHNldAojIENP
TkZJR19NQUNJTlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJQ0VTPXkK
Q09ORklHX05FVF9DT1JFPXkKIyBDT05GSUdfQk9ORElORyBpcyBub3Qgc2V0CiMgQ09ORklH
X0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0ZDIGlzIG5vdCBzZXQKQ09ORklHX01JST15CiMgQ09ORklHX0lGQiBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9URUFNIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDVkxBTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1ZYTEFOIGlzIG5vdCBzZXQKQ09ORklHX05FVENPTlNPTEU9eQpD
T05GSUdfTkVUUE9MTD15CiMgQ09ORklHX05FVFBPTExfVFJBUCBpcyBub3Qgc2V0CkNPTkZJ
R19ORVRfUE9MTF9DT05UUk9MTEVSPXkKQ09ORklHX1RVTj15CkNPTkZJR19WRVRIPXkKIyBD
T05GSUdfQVJDTkVUIGlzIG5vdCBzZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMK
CiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJlIGRyaXZlcnMKIwojIENPTkZJ
R19ORVRfRFNBX01WODhFNlhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9EU0FfTVY4OEU2
MDYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTZYWFhfTkVFRF9QUFUgaXMg
bm90IHNldAojIENPTkZJR19ORVRfRFNBX01WODhFNjEzMSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9EU0FfTVY4OEU2MTIzXzYxXzY1IGlzIG5vdCBzZXQKQ09ORklHX0VUSEVSTkVUPXkK
IyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRP
Ul9BREFQVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9BTFRFT04gaXMgbm90
IHNldAojIENPTkZJR19ORVRfVkVORE9SX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9W
RU5ET1JfQVRIRVJPUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfQ0FERU5DRT15CiMgQ09ORklH
X0FSTV9BVDkxX0VUSEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDQiBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9WRU5ET1JfQlJPQURDT00gaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX0JST0NBREUgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0FMWEVEQV9YR01BQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQ0hFTFNJTyBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9WRU5ET1JfQ0lTQ08gaXMgbm90IHNldAojIENPTkZJR19ETkVUIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1ZFTkRPUl9ERUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X0RMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9FTVVMRVggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfVkVORE9SX0VYQVIgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX0hQIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfSU5URUw9eQojIENPTkZJR19F
MTAwIGlzIG5vdCBzZXQKQ09ORklHX0UxMDAwPXkKQ09ORklHX0UxMDAwRT15CkNPTkZJR19J
R0I9eQpDT05GSUdfSUdCX0hXTU9OPXkKQ09ORklHX0lHQlZGPXkKIyBDT05GSUdfSVhHQiBp
cyBub3Qgc2V0CiMgQ09ORklHX0lYR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVhHQkVWRiBp
cyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX0lQMTAwMCBp
cyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1Jf
TUFSVkVMTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfTUVMTEFOT1ggaXMgbm90
IHNldAojIENPTkZJR19ORVRfVkVORE9SX01JQ1JFTCBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VF9WRU5ET1JfTVlSSSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZFQUxOWCBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9WRU5ET1JfTkFUU0VNSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9PS0kgaXMgbm90IHNl
dAojIENPTkZJR19FVEhPQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9QQUNLRVRfRU5HSU5F
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9RTE9HSUMgaXMgbm90IHNldApDT05G
SUdfTkVUX1ZFTkRPUl9SRUFMVEVLPXkKIyBDT05GSUdfODEzOUNQIGlzIG5vdCBzZXQKIyBD
T05GSUdfODEzOVRPTyBpcyBub3Qgc2V0CkNPTkZJR19SODE2OT15CiMgQ09ORklHX05FVF9W
RU5ET1JfUkRDIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU0VFUT15CkNPTkZJR19O
RVRfVkVORE9SX1NJTEFOPXkKIyBDT05GSUdfU0M5MjAzMSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9WRU5ET1JfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZDIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1ZFTkRPUl9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9T
VE1JQ1JPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TVU4gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX1RFSFVUSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfVEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1ZJQSBpcyBub3Qgc2V0CkNP
TkZJR19ORVRfVkVORE9SX1dJWk5FVD15CiMgQ09ORklHX1dJWk5FVF9XNTEwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMg
bm90IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQjEwMDAg
aXMgbm90IHNldApDT05GSUdfUEhZTElCPXkKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJz
CiMKIyBDT05GSUdfQVQ4MDNYX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNRF9QSFkgaXMg
bm90IHNldAojIENPTkZJR19NQVJWRUxMX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RBVklD
T01fUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfUVNFTUlfUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0NJQ0FEQV9QSFkgaXMgbm90IHNldAoj
IENPTkZJR19WSVRFU1NFX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0NfUEhZIGlzIG5v
dCBzZXQKIyBDT05GSUdfQlJPQURDT01fUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQkNNODdY
WF9QSFkgaXMgbm90IHNldAojIENPTkZJR19JQ1BMVVNfUEhZIGlzIG5vdCBzZXQKQ09ORklH
X1JFQUxURUtfUEhZPXkKIyBDT05GSUdfTkFUSU9OQUxfUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xTSV9FVDEwMTFDX1BIWSBpcyBub3Qg
c2V0CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNldAojIENPTkZJR19GSVhFRF9QSFkg
aXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcgaXMgbm90IHNldAojIENPTkZJR19Q
UFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBVU0IgTmV0d29y
ayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfVVNCTkVUIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0lQSEVUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1dMQU4gaXMg
bm90IHNldAoKIwojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBzZWUg
dGhlIFdpTUFYIGRyaXZlcnMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldApDT05GSUdfWEVO
X05FVERFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQojIENPTkZJ
R19WTVhORVQzIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CgojCiMgSW5w
dXQgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQpDT05GSUdfSU5QVVRfRkZfTUVN
TEVTUz15CkNPTkZJR19JTlBVVF9QT0xMREVWPXkKQ09ORklHX0lOUFVUX1NQQVJTRUtNQVA9
eQojIENPTkZJR19JTlBVVF9NQVRSSVhLTUFQIGlzIG5vdCBzZXQKCiMKIyBVc2VybGFuZCBp
bnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01PVVNFREVWPXkKIyBDT05GSUdfSU5QVVRfTU9V
U0VERVZfUFNBVVggaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9
MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4CiMgQ09ORklHX0lOUFVU
X0pPWURFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRFVj15CiMgQ09ORklHX0lOUFVU
X0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19J
TlBVVF9LRVlCT0FSRD15CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODggaXMgbm90IHNldAoj
IENPTkZJR19LRVlCT0FSRF9BRFA1NTg5IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0FU
S0JEPXkKIyBDT05GSUdfS0VZQk9BUkRfUVQxMDcwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZ
Qk9BUkRfUVQyMTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTEtLQkQgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E2NDE2IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZ
Qk9BUkRfVENBODQxOCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMzMyBpcyBub3Qgc2V0CiMgQ09ORklHX0tF
WUJPQVJEX01BWDczNTkgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldAojIENPTkZJR19LRVlC
T0FSRF9ORVdUT04gaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMg
bm90IHNldAojIENPTkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklH
X0tFWUJPQVJEX1NVTktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1hUS0JEIGlz
IG5vdCBzZXQKQ09ORklHX0lOUFVUX01PVVNFPXkKQ09ORklHX01PVVNFX1BTMj15CkNPTkZJ
R19NT1VTRV9QUzJfQUxQUz15CkNPTkZJR19NT1VTRV9QUzJfTE9HSVBTMlBQPXkKQ09ORklH
X01PVVNFX1BTMl9TWU5BUFRJQ1M9eQpDT05GSUdfTU9VU0VfUFMyX0NZUFJFU1M9eQpDT05G
SUdfTU9VU0VfUFMyX0xJRkVCT09LPXkKQ09ORklHX01PVVNFX1BTMl9UUkFDS1BPSU5UPXkK
IyBDT05GSUdfTU9VU0VfUFMyX0VMQU5URUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0Vf
UFMyX1NFTlRFTElDIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfUFMyX1RPVUNIS0lUIGlz
IG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfU0VSSUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9V
U0VfQVBQTEVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX0JDTTU5NzQgaXMgbm90
IHNldAojIENPTkZJR19NT1VTRV9DWUFQQSBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1ZT
WFhYQUEgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TWU5BUFRJQ1NfSTJDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTU9VU0VfU1lOQVBUSUNTX1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
UFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1RBQkxFVD15CiMgQ09ORklH
X1RBQkxFVF9VU0JfQUNFQ0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFCTEVUX1VTQl9BSVBU
RUsgaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRfVVNCX0dUQ08gaXMgbm90IHNldAojIENP
TkZJR19UQUJMRVRfVVNCX0hBTldBTkcgaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRfVVNC
X0tCVEFCIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFCTEVUX1VTQl9XQUNPTSBpcyBub3Qgc2V0
CkNPTkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FENzg3
OSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FUTUVMX01YVCBpcyBub3Qgc2V0
CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMTMgaXMgbm90IHNldAojIENPTkZJR19UT1VD
SFNDUkVFTl9DWVRUU1BfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0RZ
TkFQUk8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9IQU1QU0hJUkUgaXMgbm90
IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9FRVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fRlVKSVRTVSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIx
MFggaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9HVU5aRSBpcyBub3Qgc2V0CiMg
Q09ORklHX1RPVUNIU0NSRUVOX0VMTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVO
X1dBQ09NX1c4MDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fV0FDT01fSTJD
IGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUFYMTE4MDEgaXMgbm90IHNldAoj
IENPTkZJR19UT1VDSFNDUkVFTl9NQ1M1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hT
Q1JFRU5fTU1TMTE0IGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTVRPVUNIIGlz
IG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fSU5FWElPIGlzIG5vdCBzZXQKIyBDT05G
SUdfVE9VQ0hTQ1JFRU5fTUs3MTIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9Q
RU5NT1VOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VEVF9GVDVYMDYgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UT1VDSFJJR0hUIGlzIG5vdCBzZXQKIyBD
T05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hXSU4gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFND
UkVFTl9QSVhDSVIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9VU0JfQ09NUE9T
SVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hJVDIxMyBpcyBub3Qg
c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQ19TRVJJTyBpcyBub3Qgc2V0CiMgQ09ORklH
X1RPVUNIU0NSRUVOX1RTQzIwMDcgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9T
VDEyMzIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBpcyBub3Qg
c2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSU5QVVRfQk1BMTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUENT
UEtSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTU1BODQ1MCBpcyBub3Qgc2V0CiMgQ09O
RklHX0lOUFVUX01QVTMwNTAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BUEFORUwgaXMg
bm90IHNldAojIENPTkZJR19JTlBVVF9BVExBU19CVE5TIGlzIG5vdCBzZXQKIyBDT05GSUdf
SU5QVVRfQVRJX1JFTU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9LRVlTUEFOX1JF
TU9URSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0tYVEo5IGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5QVVRfUE9XRVJNQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfWUVBTElOSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNMTA5IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5Q
VVRfVUlOUFVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUENGODU3NCBpcyBub3Qgc2V0
CiMgQ09ORklHX0lOUFVUX0FEWEwzNFggaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTUEz
MDAwIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1hFTl9LQkRERVZfRlJPTlRFTkQ9eQoKIwoj
IEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19TRVJJTz15CkNPTkZJR19TRVJJT19JODA0
Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPXkKIyBDT05GSUdfU0VSSU9fQ1Q4MkM3MTAgaXMg
bm90IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldApDT05GSUdfU0VSSU9f
TElCUFMyPXkKIyBDT05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSU9f
QUxURVJBX1BTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BTMk1VTFQgaXMgbm90IHNl
dAojIENPTkZJR19TRVJJT19BUkNfUFMyIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlQg
aXMgbm90IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1RUWT15CkNPTkZJ
R19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15CkNPTkZJR19WVF9DT05TT0xF
PXkKQ09ORklHX1ZUX0NPTlNPTEVfU0xFRVA9eQpDT05GSUdfSFdfQ09OU09MRT15CkNPTkZJ
R19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5JWDk4X1BUWVM9eQojIENPTkZJ
R19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVHQUNZ
X1BUWVMgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkKIyBDT05GSUdf
Uk9DS0VUUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NZQ0xBREVTIGlzIG5vdCBzZXQKIyBD
T05GSUdfTU9YQV9JTlRFTExJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01PWEFfU01BUlRJTyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NZTkNMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJ
TktNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NZTkNMSU5LX0dUIGlzIG5vdCBzZXQKIyBDT05G
SUdfTk9aT01JIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNJIGlzIG5vdCBzZXQKIyBDT05GSUdf
Tl9IRExDIGlzIG5vdCBzZXQKIyBDT05GSUdfTl9HU00gaXMgbm90IHNldAojIENPTkZJR19U
UkFDRV9TSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfREVWS01FTSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NUQUxEUlYgaXMgbm90IHNldAoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NF
UklBTF84MjUwPXkKQ09ORklHX1NFUklBTF84MjUwX1BOUD15CkNPTkZJR19TRVJJQUxfODI1
MF9DT05TT0xFPXkKQ09ORklHX0ZJWF9FQVJMWUNPTl9NRU09eQpDT05GSUdfU0VSSUFMXzgy
NTBfUENJPXkKQ09ORklHX1NFUklBTF84MjUwX05SX1VBUlRTPTMyCkNPTkZJR19TRVJJQUxf
ODI1MF9SVU5USU1FX1VBUlRTPTQKQ09ORklHX1NFUklBTF84MjUwX0VYVEVOREVEPXkKQ09O
RklHX1NFUklBTF84MjUwX01BTllfUE9SVFM9eQpDT05GSUdfU0VSSUFMXzgyNTBfU0hBUkVf
SVJRPXkKQ09ORklHX1NFUklBTF84MjUwX0RFVEVDVF9JUlE9eQpDT05GSUdfU0VSSUFMXzgy
NTBfUlNBPXkKIyBDT05GSUdfU0VSSUFMXzgyNTBfRFcgaXMgbm90IHNldAoKIwojIE5vbi04
MjUwIHNlcmlhbCBwb3J0IHN1cHBvcnQKIwojIENPTkZJR19TRVJJQUxfTUZEX0hTVSBpcyBu
b3Qgc2V0CkNPTkZJR19TRVJJQUxfQ09SRT15CkNPTkZJR19TRVJJQUxfQ09SRV9DT05TT0xF
PXkKIyBDT05GSUdfU0VSSUFMX0pTTSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9TQ0NO
WFAgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfVElNQkVSREFMRSBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFUklBTF9BTFRFUkFfSlRBR1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJ
QUxfQUxURVJBX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfUENIX1VBUlQgaXMg
bm90IHNldAojIENPTkZJR19TRVJJQUxfQVJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFM
X1JQMiBpcyBub3Qgc2V0CkNPTkZJR19IVkNfRFJJVkVSPXkKQ09ORklHX0hWQ19JUlE9eQpD
T05GSUdfSFZDX1hFTj15CkNPTkZJR19IVkNfWEVOX0ZST05URU5EPXkKIyBDT05GSUdfSVBN
SV9IQU5ETEVSIGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT15CkNPTkZJR19IV19SQU5E
T01fVElNRVJJT01FTT15CkNPTkZJR19IV19SQU5ET01fSU5URUw9eQpDT05GSUdfSFdfUkFO
RE9NX0FNRD15CkNPTkZJR19IV19SQU5ET01fVklBPXkKIyBDT05GSUdfTlZSQU0gaXMgbm90
IHNldAojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5v
dCBzZXQKIyBDT05GSUdfTVdBVkUgaXMgbm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlz
IG5vdCBzZXQKQ09ORklHX0hQRVQ9eQojIENPTkZJR19IUEVUX01NQVAgaXMgbm90IHNldApD
T05GSUdfSEFOR0NIRUNLX1RJTUVSPXkKIyBDT05GSUdfVENHX1RQTSBpcyBub3Qgc2V0CiMg
Q09ORklHX1RFTENMT0NLIGlzIG5vdCBzZXQKQ09ORklHX0RFVlBPUlQ9eQpDT05GSUdfSTJD
PXkKQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdfSTJDX0NPTVBBVD15CiMgQ09ORklH
X0kyQ19DSEFSREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX01VWCBpcyBub3Qgc2V0CkNP
TkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FMR09CSVQ9eQoKIwojIEkyQyBI
YXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgUEMgU01CdXMgaG9zdCBjb250cm9sbGVyIGRy
aXZlcnMKIwojIENPTkZJR19JMkNfQUxJMTUzNSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19B
TEkxNTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1WDMgaXMgbm90IHNldApDT05G
SUdfSTJDX0FNRDc1Nj15CiMgQ09ORklHX0kyQ19BTUQ3NTZfUzQ4ODIgaXMgbm90IHNldApD
T05GSUdfSTJDX0FNRDgxMTE9eQpDT05GSUdfSTJDX0k4MDE9eQpDT05GSUdfSTJDX0lTQ0g9
eQpDT05GSUdfSTJDX1BJSVg0PXkKIyBDT05GSUdfSTJDX05GT1JDRTIgaXMgbm90IHNldAoj
IENPTkZJR19JMkNfU0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM2MzAgaXMg
bm90IHNldAojIENPTkZJR19JMkNfU0lTOTZYIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1ZJ
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19WSUFQUk8gaXMgbm90IHNldAoKIwojIEFDUEkg
ZHJpdmVycwojCkNPTkZJR19JMkNfU0NNST15CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVy
cyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0RF
U0lHTldBUkVfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VHMjBUIGlzIG5vdCBzZXQK
IyBDT05GSUdfSTJDX0lOVEVMX01JRCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19PQ09SRVMg
aXMgbm90IHNldAojIENPTkZJR19JMkNfUENBX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05G
SUdfSTJDX1BYQV9QQ0kgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0lNVEVDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSTJDX1hJTElOWCBpcyBub3Qgc2V0CgojCiMgRXh0ZXJuYWwgSTJDL1NN
QnVzIGFkYXB0ZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19ESU9MQU5fVTJDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQgaXMgbm90IHNldAojIENPTkZJR19JMkNf
VEFPU19FVk0gaXMgbm90IHNldAojIENPTkZJR19JMkNfVElOWV9VU0IgaXMgbm90IHNldAoK
IwojIE90aGVyIEkyQy9TTUJ1cyBidXMgZHJpdmVycwojCiMgQ09ORklHX0kyQ19TVFVCIGlz
IG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19J
MkNfREVCVUdfQUxHTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMgbm90
IHNldAojIENPTkZJR19TUEkgaXMgbm90IHNldAojIENPTkZJR19IU0kgaXMgbm90IHNldAoK
IwojIFBQUyBzdXBwb3J0CiMKQ09ORklHX1BQUz15CiMgQ09ORklHX1BQU19ERUJVRyBpcyBu
b3Qgc2V0CgojCiMgUFBTIGNsaWVudHMgc3VwcG9ydAojCiMgQ09ORklHX1BQU19DTElFTlRf
S1RJTUVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBTX0NMSUVOVF9MRElTQyBpcyBub3Qgc2V0
CiMgQ09ORklHX1BQU19DTElFTlRfR1BJTyBpcyBub3Qgc2V0CgojCiMgUFBTIGdlbmVyYXRv
cnMgc3VwcG9ydAojCgojCiMgUFRQIGNsb2NrIHN1cHBvcnQKIwpDT05GSUdfUFRQXzE1ODhf
Q0xPQ0s9eQoKIwojIEVuYWJsZSBQSFlMSUIgYW5kIE5FVFdPUktfUEhZX1RJTUVTVEFNUElO
RyB0byBzZWUgdGhlIGFkZGl0aW9uYWwgY2xvY2tzLgojCiMgQ09ORklHX1BUUF8xNTg4X0NM
T0NLX1BDSCBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15
CiMgQ09ORklHX0dQSU9MSUIgaXMgbm90IHNldAojIENPTkZJR19XMSBpcyBub3Qgc2V0CkNP
TkZJR19QT1dFUl9TVVBQTFk9eQojIENPTkZJR19QT1dFUl9TVVBQTFlfREVCVUcgaXMgbm90
IHNldAojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19URVNUX1BPV0VS
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODAgaXMgbm90IHNldAojIENPTkZJ
R19CQVRURVJZX0RTMjc4MSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfRFMyNzgyIGlz
IG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9TQlMgaXMgbm90IHNldAojIENPTkZJR19CQVRU
RVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX01BWDE3MDQwIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBub3Qgc2V0CiMgQ09ORklHX0NI
QVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTFA4NzI3IGlzIG5v
dCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9CUTI0MTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hB
UkdFUl9TTUIzNDcgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0dPTERGSVNIIGlzIG5v
dCBzZXQKIyBDT05GSUdfUE9XRVJfUkVTRVQgaXMgbm90IHNldAojIENPTkZJR19QT1dFUl9B
VlMgaXMgbm90IHNldApDT05GSUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPXkKIyBDT05G
SUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMKIwoj
IENPTkZJR19TRU5TT1JTX0FCSVRVR1VSVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
QUJJVFVHVVJVMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19BRDc0MTggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FETTEwMjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjUgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FETTEwMjYgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FETTEwMjkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMzEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FETTkyNDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FEVDc0MTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0MTEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FEVDc0NjIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FEVDc0NzAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NzUgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FTQzc2MjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0s4VEVNUCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0sxMFRFTVA9eQpDT05GSUdfU0VO
U09SU19GQU0xNUhfUE9XRVI9eQojIENPTkZJR19TRU5TT1JTX0FTQjEwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0RT
NjIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX0k1S19BTUIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19GNzE4MDVG
PXkKQ09ORklHX1NFTlNPUlNfRjcxODgyRkc9eQpDT05GSUdfU0VOU09SU19GNzUzNzVTPXkK
IyBDT05GSUdfU0VOU09SU19GU0NITUQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0c3
NjBBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19ISUg2
MTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19DT1JFVEVNUCBpcyBub3Qgc2V0CkNP
TkZJR19TRU5TT1JTX0lUODc9eQpDT05GSUdfU0VOU09SU19KQzQyPXkKIyBDT05GSUdfU0VO
U09SU19MSU5FQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTYzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19MTTczIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19M
TTc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19MTTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19MTTg1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg3IGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19MVEM0MTUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjE1IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19MVEM0MjYxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQxIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTYxOSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTY2OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
TlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjM5IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19NQVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2Njk3IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzM2
MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CiMgQ09ORklHX1BNQlVTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
U0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19ETUUxNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19F
TUMxNDAzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMyMTAzIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19FTUM2VzIwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
U01TQzQ3TTEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xOTIgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N0IzOTcgaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX1NDSDU2WFhfQ09NTU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1
NjI3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NjM2IGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19BRFMxMDE1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFM3
ODI4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BTUM2ODIxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19JTkEyMDkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lOQTJY
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVEhNQzUwIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19UTVAxMDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RNUDQwMSBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVE1QNDIxIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19WSUFfQ1BVVEVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBNjg2
QSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19WVDgyMzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc4MUQg
aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5MUQgaXMgbm90IHNldAojIENPTkZJ
R19TRU5TT1JTX1c4Mzc5MkQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5MyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzNzk1IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19XODNMNzg1VFMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4M0w3ODZO
RyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzNjI3SEYgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX1c4MzYyN0VIRiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVBQ
TEVTTUMgaXMgbm90IHNldAoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19TRU5TT1JTX0FD
UElfUE9XRVI9eQojIENPTkZJR19TRU5TT1JTX0FUSzAxMTAgaXMgbm90IHNldApDT05GSUdf
VEhFUk1BTD15CkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxfREVGQVVM
VF9HT1ZfU1RFUF9XSVNFPXkKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9GQUlSX1NI
QVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9VU0VSX1NQQUNF
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkFJUl9TSEFSRSBpcyBub3Qgc2V0CkNPTkZJR19TVEVQ
X1dJU0U9eQojIENPTkZJR19VU0VSX1NQQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX1RI
RVJNQUwgaXMgbm90IHNldApDT05GSUdfV0FUQ0hET0c9eQpDT05GSUdfV0FUQ0hET0dfQ09S
RT15CiMgQ09ORklHX1dBVENIRE9HX05PV0FZT1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRv
ZyBEZXZpY2UgRHJpdmVycwojCiMgQ09ORklHX1NPRlRfV0FUQ0hET0cgaXMgbm90IHNldAoj
IENPTkZJR19BQ1FVSVJFX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEVkFOVEVDSF9XRFQg
aXMgbm90IHNldAojIENPTkZJR19BTElNMTUzNV9XRFQgaXMgbm90IHNldAojIENPTkZJR19B
TElNNzEwMV9XRFQgaXMgbm90IHNldAojIENPTkZJR19GNzE4MDhFX1dEVCBpcyBub3Qgc2V0
CkNPTkZJR19TUDUxMDBfVENPPXkKIyBDT05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0JDX0ZJVFBDMl9XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX0VVUk9URUNI
X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lCNzAwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lCTUFTUiBpcyBub3Qgc2V0CiMgQ09ORklHX1dBRkVSX1dEVCBpcyBub3Qgc2V0CiMgQ09O
RklHX0k2MzAwRVNCX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lFNlhYX1dEVCBpcyBub3Qg
c2V0CiMgQ09ORklHX0lUQ09fV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfSVQ4NzEyRl9XRFQg
aXMgbm90IHNldAojIENPTkZJR19JVDg3X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQX1dB
VENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0MxMjAwX1dEVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTlZfVENPIGlzIG5vdCBzZXQK
IyBDT05GSUdfNjBYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19TQkM4MzYwX1dEVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NQVTVfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU01TQ19TQ0gz
MTFYX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0MzN0I3ODdfV0RUIGlzIG5vdCBzZXQK
IyBDT05GSUdfVklBX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4MzYyN0hGX1dEVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1c4MzY5N0hGX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4MzY5
N1VHX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4Mzg3N0ZfV0RUIGlzIG5vdCBzZXQKIyBD
T05GSUdfVzgzOTc3Rl9XRFQgaXMgbm90IHNldAojIENPTkZJR19NQUNIWl9XRFQgaXMgbm90
IHNldAojIENPTkZJR19TQkNfRVBYX0MzX1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1hF
Tl9XRFQ9eQoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1BDSVBD
V0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19XRFRQQ0kgaXMgbm90IHNldAoKIwojIFVT
Qi1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1VTQlBDV0FUQ0hET0cgaXMgbm90
IHNldApDT05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxh
bmUKIwojIENPTkZJR19TU0IgaXMgbm90IHNldApDT05GSUdfQkNNQV9QT1NTSUJMRT15Cgoj
CiMgQnJvYWRjb20gc3BlY2lmaWMgQU1CQQojCiMgQ09ORklHX0JDTUEgaXMgbm90IHNldAoK
IwojIE11bHRpZnVuY3Rpb24gZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfTUZEX0NPUkU9eQoj
IENPTkZJR19NRkRfODhQTTg2MFggaXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTgwMCBp
cyBub3Qgc2V0CiMgQ09ORklHX01GRF84OFBNODA1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X1NNNTAxIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JUU1hfUENJIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUZEX1RJX0FNMzM1WF9UU0NBREMgaXMgbm90IHNldAojIENPTkZJR19IVENfUEFT
SUMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xNMzUzMyBpcyBub3Qgc2V0CiMgQ09ORklH
X1RQUzYxMDVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjUwN1ggaXMgbm90IHNldAojIENP
TkZJR19NRkRfVFBTNjUyMTcgaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjU4NlggaXMg
bm90IHNldAojIENPTkZJR19NRkRfVFBTODAwMzEgaXMgbm90IHNldAojIENPTkZJR19UV0w0
MDMwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19UV0w2MDQwX0NPUkUgaXMgbm90IHNldAoj
IENPTkZJR19NRkRfU1RNUEUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVEMzNTg5WCBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1NNU0Mg
aXMgbm90IHNldAojIENPTkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9EQTkwNTJfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1NSBpcyBub3Qgc2V0
CiMgQ09ORklHX1BNSUNfQURQNTUyMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9MUDg3ODgg
aXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYNzc2ODYgaXMgbm90IHNldAojIENPTkZJR19N
RkRfTUFYNzc2OTMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODkwNyBpcyBub3Qgc2V0
CiMgQ09ORklHX01GRF9NQVg4OTI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX01BWDg5OTcg
aXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODk5OCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9TRUNfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9BUklaT05BX0kyQyBpcyBub3Qg
c2V0CiMgQ09ORklHX01GRF9XTTg0MDAgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004MzFY
X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzNTBfSTJDIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUZEX1dNODk5NCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9QQ0Y1MDYzMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9NQzEzWFhYX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0FC
WDUwMF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NTNTUzNSBpcyBub3Qgc2V0CkNP
TkZJR19MUENfU0NIPXkKIyBDT05GSUdfTFBDX0lDSCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9SREMzMjFYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0pBTlpfQ01PRElPIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUZEX1ZYODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1dMMTI3M19D
T1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1MDkwIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX1JDNVQ1ODMgaXMgbm90IHNldAojIENPTkZJR19NRkRfUEFMTUFTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUZEX1ZJUEVSQk9BUkQgaXMgbm90IHNldAojIENPTkZJR19NRkRfUkVU
VSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9BUzM3MTEgaXMgbm90IHNldAojIENPTkZJR19S
RUdVTEFUT1IgaXMgbm90IHNldApDT05GSUdfTUVESUFfU1VQUE9SVD15CgojCiMgTXVsdGlt
ZWRpYSBjb3JlIHN1cHBvcnQKIwpDT05GSUdfTUVESUFfQ0FNRVJBX1NVUFBPUlQ9eQpDT05G
SUdfTUVESUFfQU5BTE9HX1RWX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfRElHSVRBTF9UVl9T
VVBQT1JUPXkKQ09ORklHX01FRElBX1JBRElPX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfUkNf
U1VQUE9SVD15CiMgQ09ORklHX01FRElBX0NPTlRST0xMRVIgaXMgbm90IHNldApDT05GSUdf
VklERU9fREVWPXkKQ09ORklHX1ZJREVPX1Y0TDI9eQpDT05GSUdfVklERU9fQURWX0RFQlVH
PXkKIyBDT05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBzZXQKQ09ORklH
X1ZJREVPX1RVTkVSPXkKQ09ORklHX1ZJREVPQlVGX0dFTj15CkNPTkZJR19WSURFT0JVRl9E
TUFfU0c9eQpDT05GSUdfVklERU9CVUZfRFZCPXkKIyBDT05GSUdfVklERU9fVjRMMl9JTlRf
REVWSUNFIGlzIG5vdCBzZXQKQ09ORklHX0RWQl9DT1JFPXkKQ09ORklHX0RWQl9ORVQ9eQoj
IENPTkZJR19UVFBDSV9FRVBST00gaXMgbm90IHNldApDT05GSUdfRFZCX01BWF9BREFQVEVS
Uz04CiMgQ09ORklHX0RWQl9EWU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0CgojCiMgTWVkaWEg
ZHJpdmVycwojCkNPTkZJR19SQ19DT1JFPXkKQ09ORklHX1JDX01BUD15CkNPTkZJR19SQ19E
RUNPREVSUz15CkNPTkZJR19MSVJDPXkKQ09ORklHX0lSX0xJUkNfQ09ERUM9eQpDT05GSUdf
SVJfTkVDX0RFQ09ERVI9eQpDT05GSUdfSVJfUkM1X0RFQ09ERVI9eQpDT05GSUdfSVJfUkM2
X0RFQ09ERVI9eQpDT05GSUdfSVJfSlZDX0RFQ09ERVI9eQpDT05GSUdfSVJfU09OWV9ERUNP
REVSPXkKQ09ORklHX0lSX1JDNV9TWl9ERUNPREVSPXkKQ09ORklHX0lSX1NBTllPX0RFQ09E
RVI9eQpDT05GSUdfSVJfTUNFX0tCRF9ERUNPREVSPXkKIyBDT05GSUdfUkNfREVWSUNFUyBp
cyBub3Qgc2V0CkNPTkZJR19NRURJQV9VU0JfU1VQUE9SVD15CgojCiMgV2ViY2FtIGRldmlj
ZXMKIwojIENPTkZJR19VU0JfVklERU9fQ0xBU1MgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
R1NQQ0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfUFdDIGlzIG5vdCBzZXQKIyBDT05GSUdf
VklERU9fQ1BJQTIgaXMgbm90IHNldAojIENPTkZJR19VU0JfWlIzNjRYWCBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TVEtXRUJDQU0gaXMgbm90IHNldAojIENPTkZJR19VU0JfUzIyNTUg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU045QzEwMiBpcyBub3Qgc2V0CgojCiMgQW5hbG9n
IFRWIFVTQiBkZXZpY2VzCiMKQ09ORklHX1ZJREVPX1BWUlVTQjI9eQpDT05GSUdfVklERU9f
UFZSVVNCMl9TWVNGUz15CkNPTkZJR19WSURFT19QVlJVU0IyX0RWQj15CiMgQ09ORklHX1ZJ
REVPX1BWUlVTQjJfREVCVUdJRkMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRFBWUiBp
cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RMRzIzMDAgaXMgbm90IHNldAojIENPTkZJR19W
SURFT19VU0JWSVNJT04gaXMgbm90IHNldAojIENPTkZJR19WSURFT19TVEsxMTYwIGlzIG5v
dCBzZXQKCiMKIyBBbmFsb2cvZGlnaXRhbCBUViBVU0IgZGV2aWNlcwojCiMgQ09ORklHX1ZJ
REVPX0FVMDgyOCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NYMjMxWFggaXMgbm90IHNl
dAojIENPTkZJR19WSURFT19UTTYwMDAgaXMgbm90IHNldAoKIwojIERpZ2l0YWwgVFYgVVNC
IGRldmljZXMKIwojIENPTkZJR19EVkJfVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX1VT
Ql9WMiBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9UVFVTQl9CVURHRVQgaXMgbm90IHNldAoj
IENPTkZJR19EVkJfVFRVU0JfREVDIGlzIG5vdCBzZXQKIyBDT05GSUdfU01TX1VTQl9EUlYg
aXMgbm90IHNldAojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09QX1VTQiBpcyBub3Qgc2V0Cgoj
CiMgV2ViY2FtLCBUViAoYW5hbG9nL2RpZ2l0YWwpIFVTQiBkZXZpY2VzCiMKIyBDT05GSUdf
VklERU9fRU0yOFhYIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1BDSV9TVVBQT1JUPXkKCiMK
IyBNZWRpYSBjYXB0dXJlIHN1cHBvcnQKIwoKIwojIE1lZGlhIGNhcHR1cmUvYW5hbG9nIFRW
IHN1cHBvcnQKIwojIENPTkZJR19WSURFT19JVlRWIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE
RU9fWk9SQU4gaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRVhJVU1fR0VNSU5JIGlzIG5v
dCBzZXQKIyBDT05GSUdfVklERU9fSEVYSVVNX09SSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdf
VklERU9fTVhCIGlzIG5vdCBzZXQKCiMKIyBNZWRpYSBjYXB0dXJlL2FuYWxvZy9oeWJyaWQg
VFYgc3VwcG9ydAojCiMgQ09ORklHX1ZJREVPX0NYMTggaXMgbm90IHNldAojIENPTkZJR19W
SURFT19DWDIzODg1IGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX0NYMjU4MjE9eQojIENPTkZJ
R19WSURFT19DWDI1ODIxX0FMU0EgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DWDg4IGlz
IG5vdCBzZXQKIyBDT05GSUdfVklERU9fQlQ4NDggaXMgbm90IHNldAojIENPTkZJR19WSURF
T19TQUE3MTM0IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fU0FBNzE2NCBpcyBub3Qgc2V0
CgojCiMgTWVkaWEgZGlnaXRhbCBUViBQQ0kgQWRhcHRlcnMKIwojIENPTkZJR19EVkJfQVY3
MTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JVREdFVF9DT1JFIGlzIG5vdCBzZXQKIyBD
T05GSUdfRFZCX0IyQzJfRkxFWENPUF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19EVkJfUExV
VE8yIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0RNMTEwNSBpcyBub3Qgc2V0CiMgQ09ORklH
X0RWQl9QVDEgaXMgbm90IHNldAojIENPTkZJR19NQU5USVNfQ09SRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0RWQl9OR0VORSBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9EREJSSURHRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1Y0TF9QTEFURk9STV9EUklWRVJTIGlzIG5vdCBzZXQKIyBDT05G
SUdfVjRMX01FTTJNRU1fRFJJVkVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1Y0TF9URVNUX0RS
SVZFUlMgaXMgbm90IHNldAoKIwojIFN1cHBvcnRlZCBNTUMvU0RJTyBhZGFwdGVycwojCiMg
Q09ORklHX1JBRElPX0FEQVBURVJTIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX0NYMjM0MVg9
eQpDT05GSUdfVklERU9fQlRDWD15CkNPTkZJR19WSURFT19UVkVFUFJPTT15CgojCiMgTWVk
aWEgYW5jaWxsYXJ5IGRyaXZlcnMgKHR1bmVycywgc2Vuc29ycywgaTJjLCBmcm9udGVuZHMp
CiMKQ09ORklHX01FRElBX1NVQkRSVl9BVVRPU0VMRUNUPXkKQ09ORklHX1ZJREVPX0lSX0ky
Qz15CgojCiMgQXVkaW8gZGVjb2RlcnMsIHByb2Nlc3NvcnMgYW5kIG1peGVycwojCkNPTkZJ
R19WSURFT19NU1AzNDAwPXkKQ09ORklHX1ZJREVPX0NTNTNMMzJBPXkKQ09ORklHX1ZJREVP
X1dNODc3NT15CgojCiMgUkRTIGRlY29kZXJzCiMKCiMKIyBWaWRlbyBkZWNvZGVycwojCkNP
TkZJR19WSURFT19TQUE3MTFYPXkKCiMKIyBWaWRlbyBhbmQgYXVkaW8gZGVjb2RlcnMKIwpD
T05GSUdfVklERU9fQ1gyNTg0MD15CgojCiMgVmlkZW8gZW5jb2RlcnMKIwoKIwojIENhbWVy
YSBzZW5zb3IgZGV2aWNlcwojCgojCiMgRmxhc2ggZGV2aWNlcwojCgojCiMgVmlkZW8gaW1w
cm92ZW1lbnQgY2hpcHMKIwoKIwojIE1pc2NlbGFuZW91cyBoZWxwZXIgY2hpcHMKIwoKIwoj
IFNlbnNvcnMgdXNlZCBvbiBzb2NfY2FtZXJhIGRyaXZlcgojCiMgQ09ORklHX01FRElBX0FU
VEFDSCBpcyBub3Qgc2V0CkNPTkZJR19NRURJQV9UVU5FUj15CkNPTkZJR19NRURJQV9UVU5F
Ul9TSU1QTEU9eQpDT05GSUdfTUVESUFfVFVORVJfVERBODI5MD15CkNPTkZJR19NRURJQV9U
VU5FUl9UREE4MjdYPXkKQ09ORklHX01FRElBX1RVTkVSX1REQTE4MjcxPXkKQ09ORklHX01F
RElBX1RVTkVSX1REQTk4ODc9eQpDT05GSUdfTUVESUFfVFVORVJfVEVBNTc2MT15CkNPTkZJ
R19NRURJQV9UVU5FUl9URUE1NzY3PXkKQ09ORklHX01FRElBX1RVTkVSX01UMjBYWD15CkNP
TkZJR19NRURJQV9UVU5FUl9YQzIwMjg9eQpDT05GSUdfTUVESUFfVFVORVJfWEM1MDAwPXkK
Q09ORklHX01FRElBX1RVTkVSX1hDNDAwMD15CkNPTkZJR19NRURJQV9UVU5FUl9NQzQ0Uzgw
Mz15CgojCiMgTXVsdGlzdGFuZGFyZCAoc2F0ZWxsaXRlKSBmcm9udGVuZHMKIwoKIwojIE11
bHRpc3RhbmRhcmQgKGNhYmxlICsgdGVycmVzdHJpYWwpIGZyb250ZW5kcwojCgojCiMgRFZC
LVMgKHNhdGVsbGl0ZSkgZnJvbnRlbmRzCiMKCiMKIyBEVkItVCAodGVycmVzdHJpYWwpIGZy
b250ZW5kcwojCkNPTkZJR19EVkJfVERBMTAwNDg9eQoKIwojIERWQi1DIChjYWJsZSkgZnJv
bnRlbmRzCiMKCiMKIyBBVFNDIChOb3J0aCBBbWVyaWNhbi9Lb3JlYW4gVGVycmVzdHJpYWwv
Q2FibGUgRFRWKSBmcm9udGVuZHMKIwpDT05GSUdfRFZCX0xHRFQzMzBYPXkKQ09ORklHX0RW
Ql9TNUgxNDA5PXkKQ09ORklHX0RWQl9TNUgxNDExPXkKCiMKIyBJU0RCLVQgKHRlcnJlc3Ry
aWFsKSBmcm9udGVuZHMKIwoKIwojIERpZ2l0YWwgdGVycmVzdHJpYWwgb25seSB0dW5lcnMv
UExMCiMKCiMKIyBTRUMgY29udHJvbCBkZXZpY2VzIGZvciBEVkItUwojCgojCiMgVG9vbHMg
dG8gZGV2ZWxvcCBuZXcgZnJvbnRlbmRzCiMKIyBDT05GSUdfRFZCX0RVTU1ZX0ZFIGlzIG5v
dCBzZXQKCiMKIyBHcmFwaGljcyBzdXBwb3J0CiMKQ09ORklHX0FHUD15CkNPTkZJR19BR1Bf
QU1ENjQ9eQpDT05GSUdfQUdQX0lOVEVMPXkKIyBDT05GSUdfQUdQX1NJUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FHUF9WSUEgaXMgbm90IHNldApDT05GSUdfVkdBX0FSQj15CkNPTkZJR19W
R0FfQVJCX01BWF9HUFVTPTE2CiMgQ09ORklHX1ZHQV9TV0lUQ0hFUk9PIGlzIG5vdCBzZXQK
Q09ORklHX0RSTT15CkNPTkZJR19EUk1fS01TX0hFTFBFUj15CiMgQ09ORklHX0RSTV9MT0FE
X0VESURfRklSTVdBUkUgaXMgbm90IHNldApDT05GSUdfRFJNX1RUTT15CiMgQ09ORklHX0RS
TV9UREZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1IxMjggaXMgbm90IHNldApDT05GSUdf
RFJNX1JBREVPTj15CkNPTkZJR19EUk1fUkFERU9OX0tNUz15CiMgQ09ORklHX0RSTV9OT1VW
RUFVIGlzIG5vdCBzZXQKCiMKIyBJMkMgZW5jb2RlciBvciBoZWxwZXIgY2hpcHMKIwpDT05G
SUdfRFJNX0kyQ19DSDcwMDY9eQpDT05GSUdfRFJNX0kyQ19TSUwxNjQ9eQpDT05GSUdfRFJN
X0k5MTU9eQpDT05GSUdfRFJNX0k5MTVfS01TPXkKIyBDT05GSUdfRFJNX01HQSBpcyBub3Qg
c2V0CiMgQ09ORklHX0RSTV9TSVMgaXMgbm90IHNldAojIENPTkZJR19EUk1fVklBIGlzIG5v
dCBzZXQKIyBDT05GSUdfRFJNX1NBVkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9WTVdH
RlggaXMgbm90IHNldAojIENPTkZJR19EUk1fR01BNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdf
RFJNX1VETCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9BU1QgaXMgbm90IHNldAojIENPTkZJ
R19EUk1fTUdBRzIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9DSVJSVVNfUUVNVSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZHQVNU
QVRFIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX09VVFBVVF9DT05UUk9MPXkKQ09ORklHX0ZC
PXkKIyBDT05GSUdfRklSTVdBUkVfRURJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0REQyBp
cyBub3Qgc2V0CkNPTkZJR19GQl9CT09UX1ZFU0FfU1VQUE9SVD15CkNPTkZJR19GQl9DRkJf
RklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVBPXkKQ09ORklHX0ZCX0NGQl9JTUFH
RUJMSVQ9eQojIENPTkZJR19GQl9DRkJfUkVWX1BJWEVMU19JTl9CWVRFIGlzIG5vdCBzZXQK
Q09ORklHX0ZCX1NZU19GSUxMUkVDVD15CkNPTkZJR19GQl9TWVNfQ09QWUFSRUE9eQpDT05G
SUdfRkJfU1lTX0lNQUdFQkxJVD15CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5ESUFOIGlzIG5v
dCBzZXQKQ09ORklHX0ZCX1NZU19GT1BTPXkKIyBDT05GSUdfRkJfV01UX0dFX1JPUFMgaXMg
bm90IHNldApDT05GSUdfRkJfREVGRVJSRURfSU89eQojIENPTkZJR19GQl9TVkdBTElCIGlz
IG5vdCBzZXQKIyBDT05GSUdfRkJfTUFDTU9ERVMgaXMgbm90IHNldAojIENPTkZJR19GQl9C
QUNLTElHSFQgaXMgbm90IHNldApDT05GSUdfRkJfTU9ERV9IRUxQRVJTPXkKQ09ORklHX0ZC
X1RJTEVCTElUVElORz15CgojCiMgRnJhbWUgYnVmZmVyIGhhcmR3YXJlIGRyaXZlcnMKIwoj
IENPTkZJR19GQl9DSVJSVVMgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTIgaXMgbm90IHNl
dAojIENPTkZJR19GQl9DWUJFUjIwMDAgaXMgbm90IHNldAojIENPTkZJR19GQl9BUkMgaXMg
bm90IHNldAojIENPTkZJR19GQl9BU0lMSUFOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0lN
U1RUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVkdBMTYgaXMgbm90IHNldAojIENPTkZJR19G
Ql9VVkVTQSBpcyBub3Qgc2V0CkNPTkZJR19GQl9WRVNBPXkKIyBDT05GSUdfRkJfTjQxMSBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZCX0hHQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1MxRDEz
WFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05GSUdf
RkJfUklWQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0k3NDAgaXMgbm90IHNldAojIENPTkZJ
R19GQl9MRTgwNTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTUFUUk9YIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkJfUkFERU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZMTI4IGlzIG5v
dCBzZXQKIyBDT05GSUdfRkJfQVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUzMgaXMgbm90
IHNldAojIENPTkZJR19GQl9TQVZBR0UgaXMgbm90IHNldAojIENPTkZJR19GQl9TSVMgaXMg
bm90IHNldAojIENPTkZJR19GQl9WSUEgaXMgbm90IHNldAojIENPTkZJR19GQl9ORU9NQUdJ
QyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0tZUk8gaXMgbm90IHNldAojIENPTkZJR19GQl8z
REZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVk9PRE9PMSBpcyBub3Qgc2V0CiMgQ09ORklH
X0ZCX1ZUODYyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1RSSURFTlQgaXMgbm90IHNldAoj
IENPTkZJR19GQl9BUksgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTMgaXMgbm90IHNldAoj
IENPTkZJR19GQl9DQVJNSU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfR0VPREUgaXMgbm90
IHNldAojIENPTkZJR19GQl9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBp
cyBub3Qgc2V0CkNPTkZJR19GQl9VREw9eQojIENPTkZJR19GQl9HT0xERklTSCBpcyBub3Qg
c2V0CiMgQ09ORklHX0ZCX1ZJUlRVQUwgaXMgbm90IHNldApDT05GSUdfWEVOX0ZCREVWX0ZS
T05URU5EPXkKIyBDT05GSUdfRkJfTUVUUk9OT01FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
TUI4NjJYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0JST0FEU0hFRVQgaXMgbm90IHNldAoj
IENPTkZJR19GQl9BVU9fSzE5MFggaXMgbm90IHNldAojIENPTkZJR19FWFlOT1NfVklERU8g
aXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0xDRF9TVVBQT1JUPXkKIyBDT05GSUdfTENE
X0NMQVNTX0RFVklDRSBpcyBub3Qgc2V0CkNPTkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNF
PXkKQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklDPXkKIyBDT05GSUdfQkFDS0xJR0hUX0FQUExF
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0FE
UDg4NzAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjMwIGlzIG5vdCBzZXQK
IyBDT05GSUdfQkFDS0xJR0hUX0xNMzYzOSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdI
VF9MUDg1NVggaXMgbm90IHNldAoKIwojIENvbnNvbGUgZGlzcGxheSBkcml2ZXIgc3VwcG9y
dAojCkNPTkZJR19WR0FfQ09OU09MRT15CkNPTkZJR19WR0FDT05fU09GVF9TQ1JPTExCQUNL
PXkKQ09ORklHX1ZHQUNPTl9TT0ZUX1NDUk9MTEJBQ0tfU0laRT02NApDT05GSUdfRFVNTVlf
Q09OU09MRT15CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVG
RkVSX0NPTlNPTEVfREVURUNUX1BSSU1BUlk9eQojIENPTkZJR19GUkFNRUJVRkZFUl9DT05T
T0xFX1JPVEFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRk9OVFMgaXMgbm90IHNldApDT05G
SUdfRk9OVF84eDg9eQpDT05GSUdfRk9OVF84eDE2PXkKQ09ORklHX0xPR089eQojIENPTkZJ
R19MT0dPX0xJTlVYX01PTk8gaXMgbm90IHNldAojIENPTkZJR19MT0dPX0xJTlVYX1ZHQTE2
IGlzIG5vdCBzZXQKQ09ORklHX0xPR09fTElOVVhfQ0xVVDIyND15CkNPTkZJR19TT1VORD15
CkNPTkZJR19TT1VORF9PU1NfQ09SRT15CkNPTkZJR19TT1VORF9PU1NfQ09SRV9QUkVDTEFJ
TT15CkNPTkZJR19TTkQ9eQpDT05GSUdfU05EX1RJTUVSPXkKQ09ORklHX1NORF9QQ009eQpD
T05GSUdfU05EX0hXREVQPXkKQ09ORklHX1NORF9SQVdNSURJPXkKQ09ORklHX1NORF9TRVFV
RU5DRVI9eQpDT05GSUdfU05EX1NFUV9EVU1NWT15CkNPTkZJR19TTkRfT1NTRU1VTD15CkNP
TkZJR19TTkRfTUlYRVJfT1NTPXkKQ09ORklHX1NORF9QQ01fT1NTPXkKQ09ORklHX1NORF9Q
Q01fT1NTX1BMVUdJTlM9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQpDT05GSUdfU05E
X0hSVElNRVI9eQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9eQpDT05GSUdfU05E
X0RZTkFNSUNfTUlOT1JTPXkKQ09ORklHX1NORF9TVVBQT1JUX09MRF9BUEk9eQpDT05GSUdf
U05EX1ZFUkJPU0VfUFJPQ0ZTPXkKIyBDT05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLIGlzIG5v
dCBzZXQKIyBDT05GSUdfU05EX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NORF9WTUFTVEVS
PXkKQ09ORklHX1NORF9LQ1RMX0pBQ0s9eQpDT05GSUdfU05EX0RNQV9TR0JVRj15CkNPTkZJ
R19TTkRfUkFXTUlESV9TRVE9eQpDT05GSUdfU05EX09QTDNfTElCX1NFUT15CiMgQ09ORklH
X1NORF9PUEw0X0xJQl9TRVEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU0JBV0VfU0VRIGlz
IG5vdCBzZXQKIyBDT05GSUdfU05EX0VNVTEwSzFfU0VRIGlzIG5vdCBzZXQKQ09ORklHX1NO
RF9NUFU0MDFfVUFSVD15CkNPTkZJR19TTkRfT1BMM19MSUI9eQpDT05GSUdfU05EX0RSSVZF
UlM9eQojIENPTkZJR19TTkRfUENTUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9EVU1NWSBp
cyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTE9PUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9W
SVJNSURJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX1NFUklBTF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBVNDAxIGlz
IG5vdCBzZXQKQ09ORklHX1NORF9QQ0k9eQojIENPTkZJR19TTkRfQUQxODg5IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU05EX0FMUzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTFM0MDAw
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FMSTU0NTEgaXMgbm90IHNldAojIENPTkZJR19T
TkRfQVNJSFBJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FUSUlYUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9BVElJWFBfTU9ERU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODEw
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVODgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO
RF9BVTg4MzAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVcyIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX0FaVDMzMjggaXMgbm90IHNldAojIENPTkZJR19TTkRfQlQ4N1ggaXMgbm90IHNl
dAojIENPTkZJR19TTkRfQ0EwMTA2IGlzIG5vdCBzZXQKQ09ORklHX1NORF9DTUlQQ0k9eQpD
T05GSUdfU05EX09YWUdFTl9MSUI9eQpDT05GSUdfU05EX09YWUdFTj15CiMgQ09ORklHX1NO
RF9DUzQyODEgaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1M0NlhYIGlzIG5vdCBzZXQKIyBD
T05GSUdfU05EX0NTNTUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzU1MzVBVURJTyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NORF9DVFhGSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E
QVJMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dJTkEyMCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NORF9MQVlMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0RBUkxBMjQgaXMgbm90
IHNldAojIENPTkZJR19TTkRfR0lOQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0xBWUxB
MjQgaXMgbm90IHNldAojIENPTkZJR19TTkRfTU9OQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NO
RF9NSUEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRUNITzNHIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX0lORElHTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJR09JTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NORF9JTkRJR09ESiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJ
R09JT1ggaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdPREpYIGlzIG5vdCBzZXQKIyBD
T05GSUdfU05EX0VNVTEwSzEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMVggaXMg
bm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9F
TlMxMzcxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VTMTkzOCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NORF9FUzE5NjggaXMgbm90IHNldAojIENPTkZJR19TTkRfRk04MDEgaXMgbm90IHNl
dApDT05GSUdfU05EX0hEQV9JTlRFTD15CkNPTkZJR19TTkRfSERBX1BSRUFMTE9DX1NJWkU9
NjQKQ09ORklHX1NORF9IREFfSFdERVA9eQojIENPTkZJR19TTkRfSERBX1JFQ09ORklHIGlz
IG5vdCBzZXQKIyBDT05GSUdfU05EX0hEQV9JTlBVVF9CRUVQIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX0hEQV9JTlBVVF9KQUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0hEQV9QQVRD
SF9MT0FERVIgaXMgbm90IHNldApDT05GSUdfU05EX0hEQV9DT0RFQ19SRUFMVEVLPXkKQ09O
RklHX1NORF9IREFfQ09ERUNfQU5BTE9HPXkKQ09ORklHX1NORF9IREFfQ09ERUNfU0lHTUFU
RUw9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19WSUE9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19I
RE1JPXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ0lSUlVTPXkKQ09ORklHX1NORF9IREFfQ09E
RUNfQ09ORVhBTlQ9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19DQTAxMTA9eQpDT05GSUdfU05E
X0hEQV9DT0RFQ19DQTAxMzI9eQojIENPTkZJR19TTkRfSERBX0NPREVDX0NBMDEzMl9EU1Ag
aXMgbm90IHNldApDT05GSUdfU05EX0hEQV9DT0RFQ19DTUVESUE9eQpDT05GSUdfU05EX0hE
QV9DT0RFQ19TSTMwNTQ9eQpDT05GSUdfU05EX0hEQV9HRU5FUklDPXkKQ09ORklHX1NORF9I
REFfUE9XRVJfU0FWRV9ERUZBVUxUPTAKIyBDT05GSUdfU05EX0hEU1AgaXMgbm90IHNldAoj
IENPTkZJR19TTkRfSERTUE0gaXMgbm90IHNldAojIENPTkZJR19TTkRfSUNFMTcxMiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9JQ0UxNzI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lO
VEVMOFgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lOVEVMOFgwTSBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9LT1JHMTIxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9MT0xBIGlzIG5v
dCBzZXQKIyBDT05GSUdfU05EX0xYNjQ2NEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01B
RVNUUk8zIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01JWEFSVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NORF9OTTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9QQ1hIUiBpcyBub3Qgc2V0
CiMgQ09ORklHX1NORF9SSVBUSURFIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JNRTMyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU05EX1JNRTk2IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JN
RTk2NTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09OSUNWSUJFUyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9UUklERU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1ZJQTgyWFggaXMg
bm90IHNldAojIENPTkZJR19TTkRfVklBODJYWF9NT0RFTSBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9WSVJUVU9TTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WWDIyMiBpcyBub3Qgc2V0
CiMgQ09ORklHX1NORF9ZTUZQQ0kgaXMgbm90IHNldApDT05GSUdfU05EX1VTQj15CkNPTkZJ
R19TTkRfVVNCX0FVRElPPXkKQ09ORklHX1NORF9VU0JfVUExMDE9eQpDT05GSUdfU05EX1VT
Ql9VU1gyWT15CkNPTkZJR19TTkRfVVNCX0NBSUFRPXkKQ09ORklHX1NORF9VU0JfQ0FJQVFf
SU5QVVQ9eQojIENPTkZJR19TTkRfVVNCX1VTMTIyTCBpcyBub3Qgc2V0CkNPTkZJR19TTkRf
VVNCXzZGSVJFPXkKIyBDT05GSUdfU05EX1NPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NPVU5E
X1BSSU1FIGlzIG5vdCBzZXQKCiMKIyBISUQgc3VwcG9ydAojCkNPTkZJR19ISUQ9eQojIENP
TkZJR19ISURfQkFUVEVSWV9TVFJFTkdUSCBpcyBub3Qgc2V0CkNPTkZJR19ISURSQVc9eQoj
IENPTkZJR19VSElEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9HRU5FUklDPXkKCiMKIyBTcGVj
aWFsIEhJRCBkcml2ZXJzCiMKQ09ORklHX0hJRF9BNFRFQ0g9eQojIENPTkZJR19ISURfQUNS
VVggaXMgbm90IHNldApDT05GSUdfSElEX0FQUExFPXkKIyBDT05GSUdfSElEX0FVUkVBTCBp
cyBub3Qgc2V0CkNPTkZJR19ISURfQkVMS0lOPXkKQ09ORklHX0hJRF9DSEVSUlk9eQpDT05G
SUdfSElEX0NISUNPTlk9eQojIENPTkZJR19ISURfUFJPRElLRVlTIGlzIG5vdCBzZXQKQ09O
RklHX0hJRF9DWVBSRVNTPXkKIyBDT05GSUdfSElEX0RSQUdPTlJJU0UgaXMgbm90IHNldAoj
IENPTkZJR19ISURfRU1TX0ZGIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0VMRUNPTSBpcyBu
b3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQojIENPTkZJR19ISURfSE9MVEVLIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSElEX0tFWVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0tZRSBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9VQ0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1dBTFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9JQ0FERSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5v
dCBzZXQKQ09ORklHX0hJRF9LRU5TSU5HVE9OPXkKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMg
bm90IHNldAojIENPTkZJR19ISURfTEVOT1ZPX1RQS0JEIGlzIG5vdCBzZXQKQ09ORklHX0hJ
RF9MT0dJVEVDSD15CiMgQ09ORklHX0hJRF9MT0dJVEVDSF9ESiBpcyBub3Qgc2V0CiMgQ09O
RklHX0xPR0lURUNIX0ZGIGlzIG5vdCBzZXQKIyBDT05GSUdfTE9HSVJVTUJMRVBBRDJfRkYg
aXMgbm90IHNldAojIENPTkZJR19MT0dJRzk0MF9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xP
R0lXSEVFTFNfRkYgaXMgbm90IHNldAojIENPTkZJR19ISURfTUFHSUNNT1VTRSBpcyBub3Qg
c2V0CkNPTkZJR19ISURfTUlDUk9TT0ZUPXkKQ09ORklHX0hJRF9NT05URVJFWT15CiMgQ09O
RklHX0hJRF9NVUxUSVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX05UUklHIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX09SVEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BBTlRI
RVJMT1JEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BFVEFMWU5YIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX1BJQ09MQ0QgaXMgbm90IHNldAojIENPTkZJR19ISURfUFJJTUFYIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX1BTM1JFTU9URSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9S
T0NDQVQgaXMgbm90IHNldAojIENPTkZJR19ISURfU0FJVEVLIGlzIG5vdCBzZXQKIyBDT05G
SUdfSElEX1NBTVNVTkcgaXMgbm90IHNldAojIENPTkZJR19ISURfU09OWSBpcyBub3Qgc2V0
CiMgQ09ORklHX0hJRF9TUEVFRExJTksgaXMgbm90IHNldAojIENPTkZJR19ISURfU1RFRUxT
RVJJRVMgaXMgbm90IHNldAojIENPTkZJR19ISURfU1VOUExVUyBpcyBub3Qgc2V0CiMgQ09O
RklHX0hJRF9HUkVFTkFTSUEgaXMgbm90IHNldAojIENPTkZJR19ISURfU01BUlRKT1lQTFVT
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RJVk8gaXMgbm90IHNldAojIENPTkZJR19ISURf
VE9QU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USElOR00gaXMgbm90IHNldAojIENP
TkZJR19ISURfVEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBQ09NIGlz
IG5vdCBzZXQKIyBDT05GSUdfSElEX1dJSU1PVEUgaXMgbm90IHNldAojIENPTkZJR19ISURf
WkVST1BMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldAoj
IENPTkZJR19ISURfU0VOU09SX0hVQiBpcyBub3Qgc2V0CgojCiMgVVNCIEhJRCBzdXBwb3J0
CiMKQ09ORklHX1VTQl9ISUQ9eQpDT05GSUdfSElEX1BJRD15CkNPTkZJR19VU0JfSElEREVW
PXkKCiMKIyBJMkMgSElEIHN1cHBvcnQKIwojIENPTkZJR19JMkNfSElEIGlzIG5vdCBzZXQK
Q09ORklHX1VTQl9BUkNIX0hBU19PSENJPXkKQ09ORklHX1VTQl9BUkNIX0hBU19FSENJPXkK
Q09ORklHX1VTQl9BUkNIX0hBU19YSENJPXkKQ09ORklHX1VTQl9TVVBQT1JUPXkKQ09ORklH
X1VTQl9DT01NT049eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQoj
IENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfVVNCX0FOTk9VTkNFX05FV19E
RVZJQ0VTPXkKCiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMKIyBDT05GSUdfVVNC
X0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RXQzMgaXMgbm90IHNl
dApDT05GSUdfVVNCX01PTj15CiMgQ09ORklHX1VTQl9XVVNCX0NCQUYgaXMgbm90IHNldAoK
IwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklHX1VTQl9DNjdYMDBf
SENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9YSENJX0hDRD15CiMgQ09ORklHX1VTQl9YSENJ
X0hDRF9ERUJVR0dJTkcgaXMgbm90IHNldApDT05GSUdfVVNCX0VIQ0lfSENEPXkKQ09ORklH
X1VTQl9FSENJX1JPT1RfSFVCX1RUPXkKQ09ORklHX1VTQl9FSENJX1RUX05FV1NDSEVEPXkK
Q09ORklHX1VTQl9FSENJX1BDST15CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9IQ0QgaXMgbm90
IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
SVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0QgaXMgbm90
IHNldApDT05GSUdfVVNCX09IQ0lfSENEPXkKIyBDT05GSUdfVVNCX09IQ0lfSENEX1BMQVRG
T1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0VIQ0lfSENEX1BMQVRGT1JNIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9ERVNDIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX09IQ0lfQklHX0VORElBTl9NTUlPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJ
X0xJVFRMRV9FTkRJQU49eQpDT05GSUdfVVNCX1VIQ0lfSENEPXkKIyBDT05GSUdfVVNCX1NM
ODExX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19IQ0QgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfQ0hJUElERUEgaXMgbm90IHNldAoKIwojIFVTQiBEZXZpY2UgQ2xh
c3MgZHJpdmVycwojCiMgQ09ORklHX1VTQl9BQ00gaXMgbm90IHNldApDT05GSUdfVVNCX1BS
SU5URVI9eQojIENPTkZJR19VU0JfV0RNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RNQyBp
cyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NUT1JBR0UgZGVwZW5kcyBvbiBTQ1NJIGJ1dCBC
TEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBuZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBI
ZWxwIGZvciBtb3JlIGluZm8KIwpDT05GSUdfVVNCX1NUT1JBR0U9eQojIENPTkZJR19VU0Jf
U1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1JFQUxURUsg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S
QUdFX0lTRDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NUT1JBR0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVN
UFNIT1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVE9SQUdFX0tBUk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVT
U19BVEFDQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0VORV9VQjYyNTAgaXMg
bm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJR19VU0JfTURDODAw
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01JQ1JPVEVLIGlzIG5vdCBzZXQKCiMKIyBVU0Ig
cG9ydCBkcml2ZXJzCiMKQ09ORklHX1VTQl9TRVJJQUw9eQojIENPTkZJR19VU0JfU0VSSUFM
X0NPTlNPTEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0dFTkVSSUMgaXMgbm90
IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0FJUkNBQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NFUklBTF9BUkszMTE2IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9CRUxL
SU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0NIMzQxIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NFUklBTF9XSElURUhFQVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX0RJR0lfQUNDRUxFUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX0NQMjEw
WD15CkNPTkZJR19VU0JfU0VSSUFMX0NZUFJFU1NfTTg9eQojIENPTkZJR19VU0JfU0VSSUFM
X0VNUEVHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9GVERJX1NJTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRlVOU09GVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TRVJJQUxfVklTT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lQQVEgaXMg
bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NFUklBTF9FREdFUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRURHRVBP
UlRfVEkgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0Y4MTIzMiBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TRVJJQUxfR0FSTUlOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF
UklBTF9JUFcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lVVSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTl9QREEgaXMgbm90IHNldAojIENPTkZJR19V
U0JfU0VSSUFMX0tFWVNQQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tMU0kg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tPQklMX1NDVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9TRVJJQUxfTUNUX1UyMzIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX01FVFJPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9TRVJJQUxfTU9TNzcyMD15CkNPTkZJ
R19VU0JfU0VSSUFMX01PUzc4NDA9eQojIENPTkZJR19VU0JfU0VSSUFMX01PVE9ST0xBIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9OQVZNQU4gaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU0VSSUFMX1BMMjMwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfT1RJ
Njg1OCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfUUNBVVggaXMgbm90IHNldAoj
IENPTkZJR19VU0JfU0VSSUFMX1FVQUxDT01NIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF
UklBTF9TUENQOFg1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9IUDRYIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TQUZFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NFUklBTF9TSUVNRU5TX01QSSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU0lF
UlJBV0lSRUxFU1MgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NZTUJPTCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfVEkgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
U0VSSUFMX0NZQkVSSkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfWElSQ09N
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9PUFRJT04gaXMgbm90IHNldAojIENP
TkZJR19VU0JfU0VSSUFMX09NTklORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFM
X09QVElDT04gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1ZJVk9QQVlfU0VSSUFM
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9YU0VOU19NVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9TRVJJQUxfWklPIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9a
VEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NTVTEwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9TRVJJQUxfUVQyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9E
RUJVRyBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwojCiMgQ09O
RklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FTUkyNiBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VWU0VHIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9M
RUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2MyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lE
TU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TSVNVU0JW
R0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEQgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
VFJBTkNFVklCUkFUT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfSU9XQVJSSU9SIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNJR0hU
RlcgaXMgbm90IHNldAojIENPTkZJR19VU0JfWVVSRVggaXMgbm90IHNldAojIENPTkZJR19V
U0JfRVpVU0JfRlgyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0hTSUNfVVNCMzUwMyBpcyBu
b3Qgc2V0CgojCiMgVVNCIFBoeXNpY2FsIExheWVyIGRyaXZlcnMKIwojIENPTkZJR19PTUFQ
X1VTQjMgaXMgbm90IHNldAojIENPTkZJR19PTUFQX0NPTlRST0xfVVNCIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfUkNBUl9QSFkg
aXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQKCiMKIyBPVEcgYW5k
IHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNCX1hDRUlWIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpDT05GSUdf
TEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xNMzUzMCBp
cyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVE
U19QQ0E5NTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDM5NDQgaXMgbm90IHNldAoj
IENPTkZJR19MRURTX0xQNTUyMSBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1NTIzIGlz
IG5vdCBzZXQKIyBDT05GSUdfTEVEU19DTEVWT19NQUlMIGlzIG5vdCBzZXQKIyBDT05GSUdf
TEVEU19QQ0E5NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5NjMzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTEVEU19CRDI4MDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX0lOVEVM
X1NTNDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfVENBNjUwNyBpcyBub3Qgc2V0CiMg
Q09ORklHX0xFRFNfTE0zNTV4IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19PVDIwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0xFRFNfQkxJTktNIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19U
UklHR0VSUyBpcyBub3Qgc2V0CgojCiMgTEVEIFRyaWdnZXJzCiMKIyBDT05GSUdfQUNDRVNT
SUJJTElUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkQgaXMgbm90IHNldAojIENP
TkZJR19FREFDIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNT
PXkKIyBDT05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMgaW50ZXJmYWNlcwoj
CkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9DPXkKQ09ORklH
X1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBkcml2
ZXJzCiMKIyBDT05GSUdfUlRDX0RSVl9EUzEzMDcgaXMgbm90IHNldAojIENPTkZJR19SVENf
RFJWX0RTMTM3NCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNjcyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUlRDX0RSVl9EUzMyMzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X01BWDY5MDAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JTNUMzNzIgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX0lTTDEyMDggaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X0lTTDEyMDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9YMTIwNSBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfUENGODUyMyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZf
UENGODU2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUENGODU4MyBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfTTQxVDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9C
UTMySyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUzM1MzkwQSBpcyBub3Qgc2V0CiMg
Q09ORklHX1JUQ19EUlZfRk0zMTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SWDg1
ODEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODAyNSBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUQ19EUlZfRU0zMDI3IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SVjMwMjlD
MiBpcyBub3Qgc2V0CgojCiMgU1BJIFJUQyBkcml2ZXJzCiMKCiMKIyBQbGF0Zm9ybSBSVEMg
ZHJpdmVycwojCkNPTkZJR19SVENfRFJWX0NNT1M9eQojIENPTkZJR19SVENfRFJWX0RTMTI4
NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNTExIGlzIG5vdCBzZXQKIyBDT05G
SUdfUlRDX0RSVl9EUzE1NTMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTc0MiBp
cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfU1RLMTdUQTggaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX000OFQ4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDM1IGlz
IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDhUNTkgaXMgbm90IHNldAojIENPTkZJR19S
VENfRFJWX01TTTYyNDIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRNDgwMiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUlA1QzAxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD
X0RSVl9WMzAyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMyNDA0IGlzIG5vdCBz
ZXQKCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwoKIwojIEhJRCBTZW5zb3IgUlRDIGRyaXZl
cnMKIwojIENPTkZJR19SVENfRFJWX0hJRF9TRU5TT1JfVElNRSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RNQURFVklDRVMgaXMgbm90IHNldAojIENPTkZJR19BVVhESVNQTEFZIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfVkZJTyBpcyBub3Qgc2V0Cgoj
CiMgVmlydGlvIGRyaXZlcnMKIwojIENPTkZJR19WSVJUSU9fUENJIGlzIG5vdCBzZXQKIyBD
T05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldAoKIwojIE1pY3Jvc29mdCBIeXBlci1WIGd1
ZXN0IHN1cHBvcnQKIwojIENPTkZJR19IWVBFUlYgaXMgbm90IHNldAoKIwojIFhlbiBkcml2
ZXIgc3VwcG9ydAojCkNPTkZJR19YRU5fQkFMTE9PTj15CkNPTkZJR19YRU5fU0NSVUJfUEFH
RVM9eQpDT05GSUdfWEVOX0RFVl9FVlRDSE49eQpDT05GSUdfWEVOX0JBQ0tFTkQ9eQpDT05G
SUdfWEVORlM9eQpDT05GSUdfWEVOX0NPTVBBVF9YRU5GUz15CkNPTkZJR19YRU5fU1lTX0hZ
UEVSVklTT1I9eQpDT05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD15CkNPTkZJR19YRU5fR05U
REVWPXkKQ09ORklHX1hFTl9HUkFOVF9ERVZfQUxMT0M9eQpDT05GSUdfU1dJT1RMQl9YRU49
eQpDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKQ09ORklHX1hFTl9QUklWQ01EPXkKIyBD
T05GSUdfWEVOX1NUVUIgaXMgbm90IHNldApDT05GSUdfWEVOX0FDUElfUFJPQ0VTU09SPXkK
Q09ORklHX1hFTl9NQ0VfTE9HPXkKQ09ORklHX1hFTl9IQVZFX1BWTU1VPXkKIyBDT05GSUdf
U1RBR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9QTEFURk9STV9ERVZJQ0VTIGlzIG5v
dCBzZXQKCiMKIyBIYXJkd2FyZSBTcGlubG9jayBkcml2ZXJzCiMKQ09ORklHX0NMS0VWVF9J
ODI1Mz15CkNPTkZJR19JODI1M19MT0NLPXkKQ09ORklHX0NMS0JMRF9JODI1Mz15CiMgQ09O
RklHX01BSUxCT1ggaXMgbm90IHNldApDT05GSUdfSU9NTVVfQVBJPXkKQ09ORklHX0lPTU1V
X1NVUFBPUlQ9eQpDT05GSUdfQU1EX0lPTU1VPXkKQ09ORklHX0FNRF9JT01NVV9TVEFUUz15
CkNPTkZJR19ETUFSX1RBQkxFPXkKQ09ORklHX0lOVEVMX0lPTU1VPXkKQ09ORklHX0lOVEVM
X0lPTU1VX0RFRkFVTFRfT049eQpDT05GSUdfSU5URUxfSU9NTVVfRkxPUFBZX1dBPXkKQ09O
RklHX0lSUV9SRU1BUD15CgojCiMgUmVtb3RlcHJvYyBkcml2ZXJzCiMKIyBDT05GSUdfU1RF
X01PREVNX1JQUk9DIGlzIG5vdCBzZXQKCiMKIyBScG1zZyBkcml2ZXJzCiMKIyBDT05GSUdf
VklSVF9EUklWRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfUE1fREVWRlJFUSBpcyBub3Qgc2V0
CiMgQ09ORklHX0VYVENPTiBpcyBub3Qgc2V0CiMgQ09ORklHX01FTU9SWSBpcyBub3Qgc2V0
CiMgQ09ORklHX0lJTyBpcyBub3Qgc2V0CiMgQ09ORklHX05UQiBpcyBub3Qgc2V0CiMgQ09O
RklHX1ZNRV9CVVMgaXMgbm90IHNldAojIENPTkZJR19QV00gaXMgbm90IHNldAojIENPTkZJ
R19JUEFDS19CVVMgaXMgbm90IHNldAoKIwojIEZpcm13YXJlIERyaXZlcnMKIwojIENPTkZJ
R19FREQgaXMgbm90IHNldApDT05GSUdfRklSTVdBUkVfTUVNTUFQPXkKIyBDT05GSUdfREVM
TF9SQlUgaXMgbm90IHNldAojIENPTkZJR19EQ0RCQVMgaXMgbm90IHNldApDT05GSUdfRE1J
SUQ9eQpDT05GSUdfRE1JX1NZU0ZTPXkKIyBDT05GSUdfSVNDU0lfSUJGVF9GSU5EIGlzIG5v
dCBzZXQKIyBDT05GSUdfR09PR0xFX0ZJUk1XQVJFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5
c3RlbXMKIwpDT05GSUdfRENBQ0hFX1dPUkRfQUNDRVNTPXkKIyBDT05GSUdfRVhUMl9GUyBp
cyBub3Qgc2V0CkNPTkZJR19FWFQzX0ZTPXkKIyBDT05GSUdfRVhUM19ERUZBVUxUU19UT19P
UkRFUkVEIGlzIG5vdCBzZXQKQ09ORklHX0VYVDNfRlNfWEFUVFI9eQpDT05GSUdfRVhUM19G
U19QT1NJWF9BQ0w9eQpDT05GSUdfRVhUM19GU19TRUNVUklUWT15CkNPTkZJR19FWFQ0X0ZT
PXkKQ09ORklHX0VYVDRfVVNFX0ZPUl9FWFQyMz15CiMgQ09ORklHX0VYVDRfRlNfUE9TSVhf
QUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUNF9GU19TRUNVUklUWSBpcyBub3Qgc2V0CkNP
TkZJR19FWFQ0X0RFQlVHPXkKQ09ORklHX0pCRD15CiMgQ09ORklHX0pCRF9ERUJVRyBpcyBu
b3Qgc2V0CkNPTkZJR19KQkQyPXkKQ09ORklHX0pCRDJfREVCVUc9eQpDT05GSUdfRlNfTUJD
QUNIRT15CiMgQ09ORklHX1JFSVNFUkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZTX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfWEZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0dGUzJfRlM9
eQpDT05GSUdfQlRSRlNfRlM9eQpDT05GSUdfQlRSRlNfRlNfUE9TSVhfQUNMPXkKIyBDT05G
SUdfQlRSRlNfRlNfQ0hFQ0tfSU5URUdSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfTklMRlMy
X0ZTIGlzIG5vdCBzZXQKQ09ORklHX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19GSUxFX0xPQ0tJ
Tkc9eQpDT05GSUdfRlNOT1RJRlk9eQpDT05GSUdfRE5PVElGWT15CkNPTkZJR19JTk9USUZZ
X1VTRVI9eQojIENPTkZJR19GQU5PVElGWSBpcyBub3Qgc2V0CkNPTkZJR19RVU9UQT15CkNP
TkZJR19RVU9UQV9ORVRMSU5LX0lOVEVSRkFDRT15CiMgQ09ORklHX1BSSU5UX1FVT1RBX1dB
Uk5JTkcgaXMgbm90IHNldAojIENPTkZJR19RVU9UQV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJ
R19RVU9UQV9UUkVFPXkKIyBDT05GSUdfUUZNVF9WMSBpcyBub3Qgc2V0CkNPTkZJR19RRk1U
X1YyPXkKQ09ORklHX1FVT1RBQ1RMPXkKQ09ORklHX1FVT1RBQ1RMX0NPTVBBVD15CkNPTkZJ
R19BVVRPRlM0X0ZTPXkKQ09ORklHX0ZVU0VfRlM9eQojIENPTkZJR19DVVNFIGlzIG5vdCBz
ZXQKQ09ORklHX0dFTkVSSUNfQUNMPXkKCiMKIyBDYWNoZXMKIwpDT05GSUdfRlNDQUNIRT15
CkNPTkZJR19GU0NBQ0hFX1NUQVRTPXkKQ09ORklHX0ZTQ0FDSEVfSElTVE9HUkFNPXkKIyBD
T05GSUdfRlNDQUNIRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTQ0FDSEVfT0JKRUNU
X0xJU1QgaXMgbm90IHNldAojIENPTkZJR19DQUNIRUZJTEVTIGlzIG5vdCBzZXQKCiMKIyBD
RC1ST00vRFZEIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0lTTzk2NjBfRlM9eQpDT05GSUdfSk9M
SUVUPXkKQ09ORklHX1pJU09GUz15CiMgQ09ORklHX1VERl9GUyBpcyBub3Qgc2V0CgojCiMg
RE9TL0ZBVC9OVCBGaWxlc3lzdGVtcwojCkNPTkZJR19GQVRfRlM9eQpDT05GSUdfTVNET1Nf
RlM9eQpDT05GSUdfVkZBVF9GUz15CkNPTkZJR19GQVRfREVGQVVMVF9DT0RFUEFHRT00MzcK
Q09ORklHX0ZBVF9ERUZBVUxUX0lPQ0hBUlNFVD0iaXNvODg1OS0xIgpDT05GSUdfTlRGU19G
Uz15CiMgQ09ORklHX05URlNfREVCVUcgaXMgbm90IHNldApDT05GSUdfTlRGU19SVz15Cgoj
CiMgUHNldWRvIGZpbGVzeXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJPQ19L
Q09SRT15CkNPTkZJR19QUk9DX1ZNQ09SRT15CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJ
R19QUk9DX1BBR0VfTU9OSVRPUj15CkNPTkZJR19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNP
TkZJR19UTVBGU19QT1NJWF9BQ0w9eQpDT05GSUdfVE1QRlNfWEFUVFI9eQpDT05GSUdfSFVH
RVRMQkZTPXkKQ09ORklHX0hVR0VUTEJfUEFHRT15CiMgQ09ORklHX0NPTkZJR0ZTX0ZTIGlz
IG5vdCBzZXQKIyBDT05GSUdfTUlTQ19GSUxFU1lTVEVNUyBpcyBub3Qgc2V0CkNPTkZJR19O
RVRXT1JLX0ZJTEVTWVNURU1TPXkKIyBDT05GSUdfTkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkZTRCBpcyBub3Qgc2V0CkNPTkZJR19DRVBIX0ZTPXkKIyBDT05GSUdfQ0lGUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0NPREFfRlMgaXMg
bm90IHNldAojIENPTkZJR19BRlNfRlMgaXMgbm90IHNldApDT05GSUdfTkxTPXkKQ09ORklH
X05MU19ERUZBVUxUPSJ1dGY4IgpDT05GSUdfTkxTX0NPREVQQUdFXzQzNz15CiMgQ09ORklH
X05MU19DT0RFUEFHRV83MzcgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MCBpcyBub3Qgc2V0CiMgQ09O
RklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf
ODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NyBpcyBub3Qgc2V0CiMg
Q09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB
R0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E
RVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NSBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldAojIENPTkZJR19OTFNf
Q09ERVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzNiBpcyBu
b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldAojIENPTkZJR19O
TFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfSVNPODg1OV84IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTAg
aXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBpcyBub3Qgc2V0CkNPTkZJ
R19OTFNfQVNDSUk9eQpDT05GSUdfTkxTX0lTTzg4NTlfMT15CiMgQ09ORklHX05MU19JU084
ODU5XzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8zIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzUg
aXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV82IGlzIG5vdCBzZXQKIyBDT05GSUdf
TkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90
IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xMyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J
U084ODU5XzE0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMTUgaXMgbm90IHNl
dAojIENPTkZJR19OTFNfS09JOF9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0tPSThfVSBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfUk9NQU4gaXMgbm90IHNldAojIENPTkZJR19O
TFNfTUFDX0NFTFRJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfQ0VOVEVVUk8gaXMg
bm90IHNldAojIENPTkZJR19OTFNfTUFDX0NST0FUSUFOIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkxTX01BQ19DWVJJTExJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfR0FFTElDIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19HUkVFSyBpcyBub3Qgc2V0CiMgQ09ORklHX05M
U19NQUNfSUNFTEFORCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfSU5VSVQgaXMgbm90
IHNldAojIENPTkZJR19OTFNfTUFDX1JPTUFOSUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X01BQ19UVVJLSVNIIGlzIG5vdCBzZXQKQ09ORklHX05MU19VVEY4PXkKCiMKIyBLZXJuZWwg
aGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JUPXkKQ09ORklHX1BSSU5U
S19USU1FPXkKQ09ORklHX0RFRkFVTFRfTUVTU0FHRV9MT0dMRVZFTD02CiMgQ09ORklHX0VO
QUJMRV9XQVJOX0RFUFJFQ0FURUQgaXMgbm90IHNldAojIENPTkZJR19FTkFCTEVfTVVTVF9D
SEVDSyBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKQ09ORklHX01BR0lDX1NZ
U1JRPXkKIyBDT05GSUdfU1RSSVBfQVNNX1NZTVMgaXMgbm90IHNldAojIENPTkZJR19SRUFE
QUJMRV9BU00gaXMgbm90IHNldAojIENPTkZJR19VTlVTRURfU1lNQk9MUyBpcyBub3Qgc2V0
CkNPTkZJR19ERUJVR19GUz15CiMgQ09ORklHX0hFQURFUlNfQ0hFQ0sgaXMgbm90IHNldAoj
IENPTkZJR19ERUJVR19TRUNUSU9OX01JU01BVENIIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVH
X0tFUk5FTD15CkNPTkZJR19ERUJVR19TSElSUT15CkNPTkZJR19MT0NLVVBfREVURUNUT1I9
eQpDT05GSUdfSEFSRExPQ0tVUF9ERVRFQ1RPUj15CiMgQ09ORklHX0JPT1RQQVJBTV9IQVJE
TE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklHX0JPT1RQQVJBTV9IQVJETE9DS1VQX1BB
TklDX1ZBTFVFPTAKIyBDT05GSUdfQk9PVFBBUkFNX1NPRlRMT0NLVVBfUEFOSUMgaXMgbm90
IHNldApDT05GSUdfQk9PVFBBUkFNX1NPRlRMT0NLVVBfUEFOSUNfVkFMVUU9MAojIENPTkZJ
R19QQU5JQ19PTl9PT1BTIGlzIG5vdCBzZXQKQ09ORklHX1BBTklDX09OX09PUFNfVkFMVUU9
MApDT05GSUdfREVURUNUX0hVTkdfVEFTSz15CkNPTkZJR19ERUZBVUxUX0hVTkdfVEFTS19U
SU1FT1VUPTEyMAojIENPTkZJR19CT09UUEFSQU1fSFVOR19UQVNLX1BBTklDIGlzIG5vdCBz
ZXQKQ09ORklHX0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUNfVkFMVUU9MAojIENPTkZJR19T
Q0hFRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ0hFRFNUQVRTPXkKQ09ORklHX1RJTUVS
X1NUQVRTPXkKIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NM
VUJfREVCVUdfT04gaXMgbm90IHNldAojIENPTkZJR19TTFVCX1NUQVRTIGlzIG5vdCBzZXQK
Q09ORklHX0hBVkVfREVCVUdfS01FTUxFQUs9eQpDT05GSUdfREVCVUdfS01FTUxFQUs9eQpD
T05GSUdfREVCVUdfS01FTUxFQUtfRUFSTFlfTE9HX1NJWkU9NDAwCiMgQ09ORklHX0RFQlVH
X0tNRU1MRUFLX1RFU1QgaXMgbm90IHNldApDT05GSUdfREVCVUdfS01FTUxFQUtfREVGQVVM
VF9PRkY9eQpDT05GSUdfREVCVUdfUFJFRU1QVD15CkNPTkZJR19ERUJVR19SVF9NVVRFWEVT
PXkKQ09ORklHX0RFQlVHX1BJX0xJU1Q9eQojIENPTkZJR19SVF9NVVRFWF9URVNURVIgaXMg
bm90IHNldApDT05GSUdfREVCVUdfU1BJTkxPQ0s9eQpDT05GSUdfREVCVUdfTVVURVhFUz15
CkNPTkZJR19ERUJVR19MT0NLX0FMTE9DPXkKQ09ORklHX1BST1ZFX0xPQ0tJTkc9eQpDT05G
SUdfTE9DS0RFUD15CiMgQ09ORklHX0xPQ0tfU1RBVCBpcyBub3Qgc2V0CkNPTkZJR19ERUJV
R19MT0NLREVQPXkKQ09ORklHX1RSQUNFX0lSUUZMQUdTPXkKIyBDT05GSUdfREVCVUdfQVRP
TUlDX1NMRUVQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS0lOR19BUElfU0VMRlRF
U1RTIGlzIG5vdCBzZXQKQ09ORklHX1NUQUNLVFJBQ0U9eQojIENPTkZJR19ERUJVR19TVEFD
S19VU0FHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0tPQkpFQ1QgaXMgbm90IHNldApD
T05GSUdfREVCVUdfQlVHVkVSQk9TRT15CkNPTkZJR19ERUJVR19JTkZPPXkKIyBDT05GSUdf
REVCVUdfSU5GT19SRURVQ0VEIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVk0gaXMgbm90
IHNldAojIENPTkZJR19ERUJVR19WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX1dS
SVRFQ09VTlQ9eQpDT05GSUdfREVCVUdfTUVNT1JZX0lOSVQ9eQpDT05GSUdfREVCVUdfTElT
VD15CiMgQ09ORklHX1RFU1RfTElTVF9TT1JUIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX1NH
PXkKIyBDT05GSUdfREVCVUdfTk9USUZJRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf
Q1JFREVOVElBTFMgaXMgbm90IHNldApDT05GSUdfQVJDSF9XQU5UX0ZSQU1FX1BPSU5URVJT
PXkKQ09ORklHX0ZSQU1FX1BPSU5URVI9eQojIENPTkZJR19CT09UX1BSSU5US19ERUxBWSBp
cyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1BST1ZFX1JDVSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BST1ZFX1JDVV9ERUxBWSBpcyBub3Qgc2V0CkNPTkZJR19TUEFS
U0VfUkNVX1BPSU5URVI9eQojIENPTkZJR19SQ1VfVE9SVFVSRV9URVNUIGlzIG5vdCBzZXQK
Q09ORklHX1JDVV9DUFVfU1RBTExfVElNRU9VVD02MApDT05GSUdfUkNVX0NQVV9TVEFMTF9W
RVJCT1NFPXkKQ09ORklHX1JDVV9DUFVfU1RBTExfSU5GTz15CiMgQ09ORklHX1JDVV9UUkFD
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tUUkFDRV9TRUxGX1RFU1QgaXMgbm90IHNldAoj
IENPTkZJR19ERUJVR19CTE9DS19FWFRfREVWVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVH
X0ZPUkNFX1dFQUtfUEVSX0NQVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BFUl9DUFVf
TUFQUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xLRFRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9U
SUZJRVJfRVJST1JfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkFVTFRfSU5KRUNU
SU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFURU5DWVRPUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0RFQlVHX1BBR0VBTExPQyBpcyBub3Qgc2V0CkNPTkZJR19VU0VSX1NUQUNLVFJBQ0VfU1VQ
UE9SVD15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNU
SU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX0ZQX1RFU1Q9
eQpDT05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRV9NQ09VTlRfVEVTVD15CkNPTkZJR19IQVZF
X0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0hBVkVfRFlOQU1JQ19GVFJBQ0VfV0lUSF9SRUdT
PXkKQ09ORklHX0hBVkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVND
QUxMX1RSQUNFUE9JTlRTPXkKQ09ORklHX0hBVkVfRkVOVFJZPXkKQ09ORklHX0hBVkVfQ19S
RUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0lOR19TVVBQT1JUPXkKIyBDT05GSUdfRlRSQUNF
IGlzIG5vdCBzZXQKIyBDT05GSUdfUkJUUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19J
TlRFUlZBTF9UUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19QUk9WSURFX09IQ0kxMzk0
X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19ERUJVRyBpcyBub3Qgc2V0
CkNPTkZJR19ETUFfQVBJX0RFQlVHPXkKIyBDT05GSUdfQVRPTUlDNjRfU0VMRlRFU1QgaXMg
bm90IHNldAojIENPTkZJR19TQU1QTEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJDSF9L
R0RCPXkKIyBDT05GSUdfS0dEQiBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfS01FTUNI
RUNLPXkKIyBDT05GSUdfS01FTUNIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9LU1RS
VE9YIGlzIG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZFUkJP
U0VfQk9PVFVQPXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BSSU5U
S19EQkdQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qg
c2V0CiMgQ09ORklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRB
PXkKIyBDT05GSUdfREVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJV
R19TRVRfTU9EVUxFX1JPTlggaXMgbm90IHNldAojIENPTkZJR19ERUJVR19OWF9URVNUIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVExCRkxVU0ggaXMgbm90IHNldApDT05GSUdfSU9N
TVVfREVCVUc9eQojIENPTkZJR19JT01NVV9TVFJFU1MgaXMgbm90IHNldApDT05GSUdfSU9N
TVVfTEVBSz15CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RF
TEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9f
REVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklH
X0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9O
RSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MApDT05GSUdfREVC
VUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMgbm90IHNldAojIENPTkZJ
R19PUFRJTUlaRV9JTkxJTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NUUklDVF9V
U0VSX0NPUFlfQ0hFQ0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk1JX1NFTEZURVNU
IGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMKQ09ORklHX0tFWVM9eQojIENP
TkZJR19FTkNSWVBURURfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWVNfREVCVUdfUFJP
Q19LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJQ1QgaXMg
bm90IHNldAojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZ
RlMgaXMgbm90IHNldAojIENPTkZJR19JTlRFTF9UWFQgaXMgbm90IHNldApDT05GSUdfREVG
QVVMVF9TRUNVUklUWV9EQUM9eQpDT05GSUdfREVGQVVMVF9TRUNVUklUWT0iIgpDT05GSUdf
Q1JZUFRPPXkKCiMKIyBDcnlwdG8gY29yZSBvciBoZWxwZXIKIwpDT05GSUdfQ1JZUFRPX0FM
R0FQST15CkNPTkZJR19DUllQVE9fQUxHQVBJMj15CkNPTkZJR19DUllQVE9fQUVBRD15CkNP
TkZJR19DUllQVE9fQUVBRDI9eQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUj15CkNPTkZJR19D
UllQVE9fQkxLQ0lQSEVSMj15CkNPTkZJR19DUllQVE9fSEFTSD15CkNPTkZJR19DUllQVE9f
SEFTSDI9eQpDT05GSUdfQ1JZUFRPX1JORz15CkNPTkZJR19DUllQVE9fUk5HMj15CkNPTkZJ
R19DUllQVE9fUENPTVA9eQpDT05GSUdfQ1JZUFRPX1BDT01QMj15CkNPTkZJR19DUllQVE9f
TUFOQUdFUj15CkNPTkZJR19DUllQVE9fTUFOQUdFUjI9eQojIENPTkZJR19DUllQVE9fVVNF
UiBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fTUFOQUdFUl9ESVNBQkxFX1RFU1RTPXkKQ09O
RklHX0NSWVBUT19HRjEyOE1VTD15CiMgQ09ORklHX0NSWVBUT19OVUxMIGlzIG5vdCBzZXQK
IyBDT05GSUdfQ1JZUFRPX1BDUllQVCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fV09SS1FV
RVVFPXkKQ09ORklHX0NSWVBUT19DUllQVEQ9eQpDT05GSUdfQ1JZUFRPX0FVVEhFTkM9eQoj
IENPTkZJR19DUllQVE9fVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fQUJMS19IRUxQ
RVJfWDg2PXkKQ09ORklHX0NSWVBUT19HTFVFX0hFTFBFUl9YODY9eQoKIwojIEF1dGhlbnRp
Y2F0ZWQgRW5jcnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0YQojCiMgQ09ORklHX0NSWVBU
T19DQ00gaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fR0NNIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1NFUUlWIGlzIG5vdCBzZXQKCiMKIyBCbG9jayBtb2RlcwojCkNPTkZJR19D
UllQVE9fQ0JDPXkKIyBDT05GSUdfQ1JZUFRPX0NUUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19DVFMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0VDQj15CkNPTkZJR19DUllQVE9f
TFJXPXkKIyBDT05GSUdfQ1JZUFRPX1BDQkMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1hU
Uz15CgojCiMgSGFzaCBtb2RlcwojCkNPTkZJR19DUllQVE9fSE1BQz15CiMgQ09ORklHX0NS
WVBUT19YQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1ZNQUMgaXMgbm90IHNldAoK
IwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKQ09ORklHX0NSWVBUT19DUkMz
MkNfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19DUkMzMkNfSU5URUw9eQojIENPTkZJR19DUllQ
VE9fR0hBU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTUQ0IGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19NRDU9eQojIENPTkZJR19DUllQVE9fTUlDSEFFTF9NSUMgaXMgbm90IHNl
dAojIENPTkZJR19DUllQVE9fUk1EMTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1JN
RDE2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19STUQyNTYgaXMgbm90IHNldAojIENP
TkZJR19DUllQVE9fUk1EMzIwIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19TSEExPXkKQ09O
RklHX0NSWVBUT19TSEExX1NTU0UzPXkKQ09ORklHX0NSWVBUT19TSEEyNTY9eQojIENPTkZJ
R19DUllQVE9fU0hBNTEyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1RHUjE5MiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NSWVBUT19XUDUxMiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU
T19HSEFTSF9DTE1VTF9OSV9JTlRFTCBpcyBub3Qgc2V0CgojCiMgQ2lwaGVycwojCkNPTkZJ
R19DUllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0PXkKQ09ORklHX0NSWVBU
T19BRVNfTklfSU5URUw9eQojIENPTkZJR19DUllQVE9fQU5VQklTIGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19BUkM0PXkKQ09ORklHX0NSWVBUT19CTE9XRklTSD15CkNPTkZJR19DUllQ
VE9fQkxPV0ZJU0hfQ09NTU9OPXkKQ09ORklHX0NSWVBUT19CTE9XRklTSF9YODZfNjQ9eQoj
IENPTkZJR19DUllQVE9fQ0FNRUxMSUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FN
RUxMSUFfWDg2XzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBTUVMTElBX0FFU05J
X0FWWF9YODZfNjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDUgaXMgbm90IHNl
dAojIENPTkZJR19DUllQVE9fQ0FTVDVfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CiMgQ09ORklH
X0NSWVBUT19DQVNUNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQVNUNl9BVlhfWDg2
XzY0IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19ERVM9eQojIENPTkZJR19DUllQVE9fRkNS
WVBUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0tIQVpBRCBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19TQUxTQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NBTFNBMjBf
WDg2XzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFRUQgaXMgbm90IHNldApDT05G
SUdfQ1JZUFRPX1NFUlBFTlQ9eQpDT05GSUdfQ1JZUFRPX1NFUlBFTlRfU1NFMl9YODZfNjQ9
eQojIENPTkZJR19DUllQVE9fU0VSUEVOVF9BVlhfWDg2XzY0IGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1RFQSBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fVFdPRklTSD15CkNPTkZJ
R19DUllQVE9fVFdPRklTSF9DT01NT049eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfWDg2XzY0
PXkKQ09ORklHX0NSWVBUT19UV09GSVNIX1g4Nl82NF8zV0FZPXkKIyBDT05GSUdfQ1JZUFRP
X1RXT0ZJU0hfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CgojCiMgQ29tcHJlc3Npb24KIwpDT05G
SUdfQ1JZUFRPX0RFRkxBVEU9eQpDT05GSUdfQ1JZUFRPX1pMSUI9eQpDT05GSUdfQ1JZUFRP
X0xaTz15CgojCiMgUmFuZG9tIE51bWJlciBHZW5lcmF0aW9uCiMKQ09ORklHX0NSWVBUT19B
TlNJX0NQUk5HPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0ggaXMgbm90IHNldAoj
IENPTkZJR19DUllQVE9fVVNFUl9BUElfU0tDSVBIRVIgaXMgbm90IHNldAojIENPTkZJR19D
UllQVE9fSFcgaXMgbm90IHNldAojIENPTkZJR19BU1lNTUVUUklDX0tFWV9UWVBFIGlzIG5v
dCBzZXQKQ09ORklHX0hBVkVfS1ZNPXkKIyBDT05GSUdfVklSVFVBTElaQVRJT04gaXMgbm90
IHNldAojIENPTkZJR19CSU5BUllfUFJJTlRGIGlzIG5vdCBzZXQKCiMKIyBMaWJyYXJ5IHJv
dXRpbmVzCiMKQ09ORklHX0JJVFJFVkVSU0U9eQpDT05GSUdfR0VORVJJQ19TVFJOQ1BZX0ZS
T01fVVNFUj15CkNPTkZJR19HRU5FUklDX1NUUk5MRU5fVVNFUj15CkNPTkZJR19HRU5FUklD
X0ZJTkRfRklSU1RfQklUPXkKQ09ORklHX0dFTkVSSUNfUENJX0lPTUFQPXkKQ09ORklHX0dF
TkVSSUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19JTz15CkNPTkZJR19QRVJDUFVfUldTRU09
eQojIENPTkZJR19DUkNfQ0NJVFQgaXMgbm90IHNldApDT05GSUdfQ1JDMTY9eQpDT05GSUdf
Q1JDX1QxMERJRj15CiMgQ09ORklHX0NSQ19JVFVfVCBpcyBub3Qgc2V0CkNPTkZJR19DUkMz
Mj15CkNPTkZJR19DUkMzMl9TRUxGVEVTVD15CkNPTkZJR19DUkMzMl9TTElDRUJZOD15CiMg
Q09ORklHX0NSQzMyX1NMSUNFQlk0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJfU0FSV0FU
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSQzMyX0JJVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
QzcgaXMgbm90IHNldApDT05GSUdfTElCQ1JDMzJDPXkKIyBDT05GSUdfQ1JDOCBpcyBub3Qg
c2V0CkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPXkKQ09ORklH
X0xaT19DT01QUkVTUz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19YWl9ERUM9
eQpDT05GSUdfWFpfREVDX1g4Nj15CkNPTkZJR19YWl9ERUNfUE9XRVJQQz15CkNPTkZJR19Y
Wl9ERUNfSUE2ND15CkNPTkZJR19YWl9ERUNfQVJNPXkKQ09ORklHX1haX0RFQ19BUk1USFVN
Qj15CkNPTkZJR19YWl9ERUNfU1BBUkM9eQpDT05GSUdfWFpfREVDX0JDSj15CiMgQ09ORklH
X1haX0RFQ19URVNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15CkNPTkZJ
R19ERUNPTVBSRVNTX0JaSVAyPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpNQT15CkNPTkZJR19E
RUNPTVBSRVNTX1haPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpPPXkKQ09ORklHX1RFWFRTRUFS
Q0g9eQpDT05GSUdfVEVYVFNFQVJDSF9LTVA9eQpDT05GSUdfVEVYVFNFQVJDSF9CTT15CkNP
TkZJR19URVhUU0VBUkNIX0ZTTT15CkNPTkZJR19IQVNfSU9NRU09eQpDT05GSUdfSEFTX0lP
UE9SVD15CkNPTkZJR19IQVNfRE1BPXkKQ09ORklHX0NIRUNLX1NJR05BVFVSRT15CkNPTkZJ
R19DUFVfUk1BUD15CkNPTkZJR19EUUw9eQpDT05GSUdfTkxBVFRSPXkKQ09ORklHX0FSQ0hf
SEFTX0FUT01JQzY0X0RFQ19JRl9QT1NJVElWRT15CkNPTkZJR19BVkVSQUdFPXkKIyBDT05G
SUdfQ09SRElDIGlzIG5vdCBzZXQKIyBDT05GSUdfRERSIGlzIG5vdCBzZXQK
------------0791EC21F164E2952
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0791EC21F164E2952--



From xen-devel-bounces@lists.xen.org Mon Feb 25 22:19:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 22:19: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 1UA6Na-0002dV-M1; Mon, 25 Feb 2013 22:18:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UA6NX-0002dQ-RM
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 22:18:36 +0000
Received: from [85.158.138.51:18304] by server-15.bemta-3.messagelabs.com id
	AD/11-25405-A33EB215; Mon, 25 Feb 2013 22:18:34 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361830713!28107267!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17071 invoked from network); 25 Feb 2013 22:18:33 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 22:18:33 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:60951 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 1UA6LX-0003EH-HS; Mon, 25 Feb 2013 23:16:32 +0100
Date: Mon, 25 Feb 2013 23:18:30 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <312569942.20130225231830@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0791EC21F164E2952"
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller not
	detected 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0791EC21F164E2952
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Konrad,

I can't get linux-3.9 rc0 to boot under xen-unstable.
It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.

I don't see a obvious error in the logs.

The same kernel boots fine on baremetal.
With linux 3.8 it boots fine under this version of xen-unstable.

Can you spot something from the logs or you have a hunch from where to start a bisect ?
(bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

--
Sander

Attached:
- Serial log with 3.9-rc0 kernel (missing sata)
- Serial log with 3.8 kernel (booting fine
- .config
------------0791EC21F164E2952
Content-Type: application/octet-stream;
 name="serial-log-3.8.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log-3.8.log"

77u/IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAg
IF8gICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyAvICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8v
IF8gXCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8
ICdfIFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxf
fCB8IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98
ICAgIHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxf
X198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3Rh
YmxlIChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVi
dWc9eSBTYXQgRmViIDIzIDE5OjU4OjA5IENFVCAyMDEzDQooWEVOKSBMYXRlc3QgQ2hhbmdl
U2V0OiB1bmF2YWlsYWJsZQ0KKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0
LTE0K3NxdWVlemUxDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTEwMjRNLG1heDox
MDI0TSBsb2dsdmw9YWxsIGxvZ2x2bF9ndWVzdD1hbGwgY29uc29sZV90aW1lc3RhbXBzIHZn
YT1nZngtMTI4MHgxMDI0eDMyIGNwdWlkbGUgY3B1ZnJlcT14ZW4gbm9yZWJvb3QgZGVidWcg
bGFwaWM9ZGVidWcgYXBpY192ZXJib3NpdHk9ZGVidWcgYXBpYz1kZWJ1ZyBpb21tdT1vbix2
ZXJib3NlLGRlYnVnLGFtZC1pb21tdS1kZWJ1Zyxuby1hbWQtaW9tbXUtcGVyZGV2LWludHJl
bWFwIGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZpZGVvIGluZm9y
bWF0aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAyNCwgMzIgYnBw
DQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNl
Y29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMiBNQlIgc2ln
bmF0dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihY
RU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAw
MDAwMDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAwIC0gMDAwMDAw
MDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAwMCAtIDAwMDAw
MDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAw
MDAwMGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAw
MDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjllMDAwIC0gMDAw
MDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZlMDAwMCAtIDAw
MDAwMDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAw
MDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0g
MDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjEwMCwg
MDAxNCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwgMDA0OCAocjEg
TVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBG
QUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIxICBBNzY0MCBB
NzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTogRkFDUyBBRkY5
RTAwMCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAocjEgNzY0ME1T
IEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIEFG
RjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAgICAgICA5
NykNCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAgICBPRU1TTElD
ICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBBRkY5RTA0MCwg
MDA3MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0ZfMTAgICAgICAg
IDIgQU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAsIDAwMzggKHIx
IDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTog
SVZSUyBBRkY5QTczMCwgMDEwMCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAg
ICAgICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChyMSBBIE0gSSAg
UE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3RlbSBSQU06IDgx
OTFNQiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUg
MA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDog
UFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAz
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogTm9kZSAw
IFBYTSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYjAwMDAw
MDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAwMDAwDQooWEVO
KSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDhjNzAwMCAtIDI0ZDhjYTAw
MA0KKFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21h
aW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGZi
MDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2MTQ0aywgdG90
YWwgMTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBsaW5lbGVu
Z3RoPTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9ODo4
Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAw
ZmY3ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4
YXBpYycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIEFDUEk6IFBN
LVRpbWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2Nu
dFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgd2Fr
ZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTogTG9jYWwgQVBJ
QyBhZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFd
IGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElD
IHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lk
WzB4MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElDIHZlcnNpb24g
MTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVu
YWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQoo
WEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQooWEVOKSBQcm9j
ZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzUg
MDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRk
cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19p
ZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQooWEVOKSBB
Q1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRd
KQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhm
ZWMyMDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIg
KGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KKFhFTikgQUNQSTog
SVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJy
aWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgRW5hYmxp
bmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVOKSBBQ1BJOiBI
UEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUgaXMgbm90IGZv
dW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGlu
Zm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMp
DQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZiMDAwIChmZWUwMDAwMCkNCihY
RU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYTAwMCAoZmVjMDAwMDApDQooWEVO
KSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQ0KKFhFTikg
SVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNpbmcgc2NoZWR1
bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0ZWN0ZWQgMzIw
MC4xODkgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuDQoo
WEVOKSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4p
IFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAw
IGJ1c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQg
MDAwMCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxv
Y2sgYXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAg
U2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDEwMA0KKFhFTikgQU1E
LVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweDg5DQooWEVO
KSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBS
RDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIwMjAzMQ0KKFhFTikgQU1E
LVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9u
IDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4M2UgbGVu
IDB4ZDAgaWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MyBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDIN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTAgZmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhj
MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHgxOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGEwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4NDMgaWQgMHhiMDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJh
bmdlOiAweGIwOCAtPiAweGJmZiBhbGlhcyAweGIwMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgyOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDkwMCBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODAwIGZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDggZmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg3
MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHg1MCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweDYwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
OiB0eXBlIDB4MiBpZCAweDU4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgzIGlkIDB4NTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9J
ZCBSYW5nZTogMHg1MDAgLT4gMHg1MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgyIGlkIDB4NjggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeTogdHlwZSAweDIgaWQgMHg0MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg4OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDkwIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDk4IGZsYWdzIDANCihYRU4pIEFNRC1WaTog
IERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5OiB0eXBlIDB4MiBpZCAweGEwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTEgZmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMyBmbGFncyAwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE0IGZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMCBpZCAwIGZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0MyBpZCAweDMwMCBmbGFn
cyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmIGFsaWFz
IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4
YTUgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHhhOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBl
IDB4MiBpZCAweGE5IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgyIGlkIDB4MTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHgzIGlkIDB4YjAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IFJhbmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBTcGVjaWFs
OiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTog
SVZIRCBTcGVjaWFsOiAwMDAwOjAwOjAwLjEgdmFyaWV0eSAweDEgaGFuZGxlIDB4Nw0KKFhF
TikgSVZIRCBFcnJvcjogbm8gaW5mb3JtYXRpb24gZm9yIElPLUFQSUMgMHg2DQooWEVOKSBB
TUQtVmk6IElPTU1VIDAgRW5hYmxlZC4NCihYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFs
IHZlY3RvciBtYXANCihYRU4pIEFNRC1WaTogVXNpbmcgZ2xvYmFsIGludGVycnVwdCByZW1h
cCB0YWJsZSBpcyBub3QgcmVjb21tZW5kZWQgKHNlZSBYU0EtMzYpIQ0KKFhFTikgSS9PIHZp
cnR1YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhF
TikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4
MDA1MDAxMA0KKFhFTikgR2V0dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDAN
CihYRU4pIEdldHRpbmcgTFZUMTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUj
MA0KKFhFTikgRVNSIHZhbHVlIGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6
IDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBB
Q0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFw
aWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0y
MiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwg
Ny05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3
LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3
LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJ
TUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVO
KSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQ
SUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lz
dGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAw
OiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQoo
WEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6
IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0K
KFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhF
TikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAg
IDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYw
MDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAg
ICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExv
ZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4p
ICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhF
TikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihY
RU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQoo
WEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0K
KFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQ
SUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikg
Li4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAx
OiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmll
czogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4p
IC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAw
DQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5
IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGlu
Zw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihY
RU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4g
MDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJR
ODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhF
TikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAg
LT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQoo
WEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVw
dHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BV
IGNsb2NrIHNwZWVkIGlzIDMyMDAuMTI3MCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBj
bG9jayBzcGVlZCBpcyAyMDAuMDA3OSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAw
eGNjZDcNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMwXSBQbGF0Zm9ybSB0aW1lciBpcyAx
NC4zMThNSHogSFBFVA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEFsbG9jYXRlZCBj
b25zb2xlIHJpbmcgb2YgNjQgS2lCLg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEhW
TTogQVNJRHMgZW5hYmxlZC4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBTVk06IFN1
cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMx
XSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIy
OjMxXSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24NCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjIyOjMxXSAgLSBOZXh0LVJJUCBTYXZlZCBvbiAjVk1FWElUDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRlcg0K
KFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEhWTTogU1ZNIGVuYWJsZWQNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQ
KSBkZXRlY3RlZA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIEhWTTogSEFQIHBhZ2Ug
c2l6ZXM6IDRrQiwgMk1CLCAxR0INCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjI5XSBtYXNr
ZWQgRXh0SU5UIG9uIENQVSMxDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gbWljcm9j
b2RlOiBDUFUxIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikg
WzIwMTMtMDItMjUgMjA6MjI6MjldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzINCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSBtaWNyb2NvZGU6IENQVTIgY29sbGVjdF9jcHVfaW5mbzog
cGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjoyOV0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIG1pY3JvY29k
ZTogQ1BVMyBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjI5XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM0DQooWEVOKSBbMjAx
My0wMi0yNSAyMDoyMjozMV0gbWljcm9jb2RlOiBDUFU0IGNvbGxlY3RfY3B1X2luZm86IHBh
dGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MjldIG1hc2tlZCBF
eHRJTlQgb24gQ1BVIzUNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBCcm91Z2h0IHVw
IDYgQ1BVcw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIG1pY3JvY29kZTogQ1BVNSBj
b2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjIyOjMxXSBIUEVUOiAzIHRpbWVycyAoMyB3aWxsIGJlIHVzZWQgZm9yIGJyb2FkY2Fz
dCkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0K
KFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0
byBhZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMx
XSBtY2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1
cCBJQlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBt
ZW1zej0weGRjODAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl9wYXJzZV9i
aW5hcnk6IHBoZHI6IHBhZGRyPTB4MWUwMDAwMCBtZW1zej0weGU0MGYwDQooWEVOKSBbMjAx
My0wMi0yNSAyMDoyMjozMV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWU1
MDAwIG1lbXN6PTB4MTNkYzANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfcGFy
c2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlZjkwMDAgbWVtc3o9MHhlMjUwMDANCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAw
MDAwMCAtPiAweDJkMWUwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfeGVu
X3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lP
TiA9ICJ4ZW4tMy4wIg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4
MWVmOTIxMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90
ZTogSFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJs
ZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikg
WzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdl
bmVyaWMiDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gZWxmX3hlbl9wYXJzZV9ub3Rl
OiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6
MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9
IDB4ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl94
ZW5fcGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozMV0gZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMxXSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4
MDAwMDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdICAgICBlbGZfcGFkZHJfb2Zm
c2V0ID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gICAgIHZpcnRfb2Zmc2V0
ICAgICAgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMx
XSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MjI6MzFdICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgy
ZDFlMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gICAgIHZpcnRfZW50cnkgICAg
ICAgPSAweGZmZmZmZmZmODFlZjkyMTANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSAg
ICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MjI6MzFdICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwg
bHNiLCBwYWRkciAweDEwMDAwMDAgLT4gMHgyZDFlMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozMV0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAwLT4wMDAwMDAw
MjQ0MDAwMDAwICgyNDI1MTYgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MjI6MzFdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjRmMzU0MDAwLT4wMDAw
MDAwMjRmZmZmYzAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gVklSVFVBTCBNRU1P
UlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIExvYWRlZCBr
ZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJkMWUwMDANCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjIyOjMxXSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MmQxZTAwMC0+ZmZm
ZmZmZmY4MzljOWMwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdICBQaHlzLU1hY2gg
bWFwOiBmZmZmZmZmZjgzOWNhMDAwLT5mZmZmZmZmZjgzYmNhMDAwDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozMV0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNiY2EwMDAtPmZmZmZm
ZmZmODNiY2E0YjQNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMxXSAgUGFnZSB0YWJsZXM6
ICAgZmZmZmZmZmY4M2JjYjAwMC0+ZmZmZmZmZmY4M2JlZTAwMA0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MjI6MzFdICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgzYmVlMDAwLT5mZmZmZmZm
ZjgzYmVmMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gIFRPVEFMOiAgICAgICAg
IGZmZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjIyOjMxXSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWVmOTIxMA0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MjI6MzFdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MjI6MzFdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZm
ZmY4MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkYzgwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjIyOjMxXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFlMDAwMDAg
LT4gMHhmZmZmZmZmZjgxZWU0MGYwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMV0gZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxZWU1MDAwIC0+IDB4ZmZmZmZm
ZmY4MWVmOGRjMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzFdIGVsZl9sb2FkX2JpbmFy
eTogcGhkciAzIGF0IDB4ZmZmZmZmZmY4MWVmOTAwMCAtPiAweGZmZmZmZmZmODFmYjQwMDAN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAwLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4Miwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDEwLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MTgsIHJvb3QgdGFibGUgPSAweDI0N2I2
MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgy
OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDMwLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NDgsIHJvb3Qg
dGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHg1MCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCByb290IHRhYmxlID0g
MHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4NjgsIHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYy
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkw
LCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4OTIsIHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDlhLCByb290IHRhYmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAsIHJvb3QgdGFibGUgPSAw
eDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhhMSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEzLCByb290IHRhYmxlID0gMHgyNDdiNjIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTQs
IHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHhhNSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE4LCByb290IHRh
YmxlID0gMHgyNDdiNjIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTMtMDItMjUgMjA6MjI6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4YjAsIHJvb3QgdGFibGUgPSAweDI0N2I2MjAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMiwgcm9vdCB0YWJsZSA9IDB4
MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4w
DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gc2V0dXAgMDAwMDowMDoxOC4wIGZvciBk
MCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoy
MjozMl0gc2V0dXAgMDAwMDowMDoxOC4xIGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDow
MDoxOC4yDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gc2V0dXAgMDAwMDowMDoxOC4y
IGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQt
Vmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoyMjozMl0gc2V0dXAgMDAwMDowMDoxOC4zIGZvciBkMCBmYWlsZWQgKC0xOSkNCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2Ug
MDAwMDowMDoxOC40DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozMl0gc2V0dXAgMDAwMDow
MDoxOC40IGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDQwMCwgcm9v
dCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDUwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMSwgcm9vdCB0YWJs
ZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDYwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgcm9vdCB0YWJsZSA9IDB4
MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDgwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYy
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEw
MCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweGIwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGMwMCwgcm9v
dCB0YWJsZSA9IDB4MjQ3YjYyMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjIyOjMyXSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjIyOjM0XSBJbml0aWFsIGxv
dyBtZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjIyOjM0XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjIyOjM0XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozNF0gWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAx
My0wMi0yNSAyMDoyMjozNF0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJM
LWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoyMjozNF0gRnJlZWQgMjQ4a0IgaW5pdCBtZW1vcnkuDQptYXBwaW5nIGtlcm5l
bCBpbnRvIHBoeXNpY2FsIG1lbW9yeQ0KYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBM
aW51eCB2ZXJzaW9uIDMuOC4wLTIwMTMwMjE5LXR0eSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkg
KGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBU
dWUgRmViIDE5IDA5OjUyOjEwIENFVCAyMDEzDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxp
bmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9Nzk0IHZp
ZGVvPXZlc2FmYiBhY3BpX2VuZm9yY2VfcmVzb3VyY2VzPWxheCByODE2OS51c2VfZGFjPTEg
ZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgeGVuLXBjaWJh
Y2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDU6MDAuKikoMDY6MDAuKikoMGE6MDEuKikg
ZGVidWcgbG9nbGV2ZWw9MTAga21lbWxlYWs9b24NClsgICAgMC4wMDAwMDBdIEZyZWVpbmcg
OWYtMTAwIHBmbiByYW5nZTogOTcgcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBdIFJlbGVh
c2VkIDk3IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCAzMjc4
ODkgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGluZyA0
MDAwMC00MDA2MSBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAwXSBl
ODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBY
ZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNhYmxl
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAw
MDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYwZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBd
IFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjEwMDAtMHgwMDAwMDAwMGFmZjhmZmZmXSB1bnVz
YWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAw
MDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAwMDAwYWZmZGZmZmZdIEFDUEkgTlZTDQpbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGFmZmUwMDAwLTB4MDAwMDAwMDBhZmZmZmZm
Zl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAw
MDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAw
ZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
WGVuOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDAyNGZmZmZmZmZdIHVudXNh
YmxlDQpbICAgIDAuMDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsg
ICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0K
WyAgICAwLjAwMDAwMF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJBTSBtYXA6DQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAw
MDAwOWVmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAw
MDAwOWYwMDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
dXNlcjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDNmZmZmZmZmXSB1c2Fi
bGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAw
MDAwMDBhZmY4ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMGFmZjkwMDAwLTB4MDAwMDAwMDBhZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAu
MDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAwMDAwYWZmZGZm
ZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmZl
MDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2Vy
OiBbbWVtIDB4MDAwMDAwMDBmZWMwMDAwMC0weDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAw
MDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAw
MDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZmUwMDAwMC0weDAwMDAwMDAwZmZmZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAw
MC0weDAwMDAwMDAyNGZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBTTUJJT1Mg
Mi41IHByZXNlbnQuDQpbICAgIDAuMDAwMDAwXSBETUk6IE1TSSBNUy03NjQwLzg5MEZYQS1H
RDcwIChNUy03NjQwKSAgLCBCSU9TIFYxLjhCMSAwOS8xMy8yMDEwDQpbICAgIDAuMDAwMDAw
XSBlODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMGZmZmZdIHVzYWJsZSA9PT4g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92ZSBbbWVtIDB4MDAwYTAwMDAt
MHgwMDBmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5k
DQpbICAgIDAuMDAwMDAwXSBlODIwOiBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZu
ID0gMHg0MDAwMDAwMDANClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDog
W21lbSAweDAwMDAwMDAwLTB4MDM5YzlmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9y
eSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAwXSA5OTAwMCBzaXplIDI0NTc2DQpb
ICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgz
ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0g
cGFnZSA0aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1
cCB0byAweDNmZmZmZmZmIEAgW21lbSAweDAyYjFjMDAwLTB4MDJkMWRmZmZdDQpbICAgIDAu
MDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjZmMwMDAgLSAyZDFlMDAwDQpb
ICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJkMWUwMDAtMHgwMzljOWZmZl0NClsg
ICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjEwMCAwMDAxNCAodjAwIEFD
UElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQgMDAwMDAwMDBhZmY5MDAwMCAwMDA0
OCAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMGFmZjkwMjAwIDAwMDg0ICh2MDEgNzY0ME1T
IEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAgMDk0MjcgKHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAw
MDAxMDAgSU5UTCAyMDA1MTExNykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAw
MDBhZmY5ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGFm
ZjkwMzkwIDAwMDg4ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAw
OTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0Mg
KHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4w
MDAwMDBdIEFDUEk6IFNMSUMgMDAwMDAwMDBhZmY5MDQ2MCAwMDE3NiAodjAxIE1TSSAgICBP
RU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
T0VNQiAwMDAwMDAwMGFmZjllMDQwIDAwMDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAw
OTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAw
YWZmOWE1ZTAgMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAw
MDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAwMDAwMDBhZmY5YTZmMCAwMDAz
OCAodjAxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogSVZSUyAwMDAwMDAwMGFmZjlhNzMwIDAwMTAwICh2MDEgIEFNRCAg
ICAgUkQ4OTBTIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBTU0RUIDAwMDAwMDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAw
MDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMg
YWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYNClsg
ICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAweDAwMDAwMDAwMDAwMDAwMDAt
MHgwMDAwMDAwMDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2Rl
IDAgW21lbSAweDAwMDAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5PREVf
REFUQSBbbWVtIDB4M2ZmZjUwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIFpvbmUg
cmFuZ2VzOg0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMTAwMDAtMHgw
MGZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4
ZmZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAgIGVtcHR5DQpbICAgIDAuMDAw
MDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0g
RWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAwMTAwMDAtMHgwMDA5ZWZmZl0NClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6
IFttZW0gMHgwMDEwMDAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gT24gbm9kZSAw
IHRvdGFscGFnZXM6IDI2MjAzMQ0KWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogNjQgcGFn
ZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2IHBhZ2Vz
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTEzIHBhZ2VzLCBMSUZP
IGJhdGNoOjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogNDAzMiBwYWdlcyB1c2Vk
IGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogMjU0MDE2IHBhZ2Vz
LCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0
OiAweDgwOA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVl
MDAwMDANClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGlj
X2lkWzB4MDBdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJs
ZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19p
ZFsweDA0XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElP
QVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAg
MC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4
ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4
MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0KWyAgICAwLjAwMDAwMF0g
SU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMyMDAwMCwg
R1NJIDI0LTU1DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAwLjAwMDAw
MF0gQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAwLjAwMDAwMF0gQUNQSTog
SVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KWyAgICAwLjAwMDAwMF0gVXNpbmcgQUNQSSAoTUFE
VCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KWyAgICAwLjAwMDAwMF0g
c21wYm9vdDogQWxsb3dpbmcgNiBDUFVzLCAwIGhvdHBsdWcgQ1BVcw0KWyAgICAwLjAwMDAw
MF0gbnJfaXJxc19nc2k6IDcyDQpbICAgIDAuMDAwMDAwXSBlODIwOiBbbWVtIDB4YjAwMDAw
MDAtMHhmZWJmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kgZGV2aWNlcw0KWyAgICAwLjAwMDAw
MF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhlbg0KWyAgICAwLjAwMDAw
MF0gWGVuIHZlcnNpb246IDQuMy11bnN0YWJsZSAocHJlc2VydmUtQUQpDQpbICAgIDAuMDAw
MDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNrX2JpdHM6OCBucl9jcHVf
aWRzOjYgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBFbWJlZGRlZCAy
NyBwYWdlcy9jcHUgQGZmZmY4ODAwM2Y4MDAwMDAgczgxMzQ0IHI4MTkyIGQyMTA1NiB1MjYy
MTQ0DQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODEzNDQgcjgxOTIgZDIxMDU2IHUy
NjIxNDQgYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0g
MCAxIDIgMyA0IDUgLSAtIA0KWyAgICA0LjkwNzgyNF0gQnVpbHQgMSB6b25lbGlzdHMgaW4g
Tm9kZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogMjU3OTI5
DQpbICAgIDQuOTA3ODI3XSBQb2xpY3kgem9uZTogRE1BMzINClsgICAgNC45MDc4MzZdIEtl
cm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9v
dCBybyB2ZXJib3NlIG1lbT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9k
ZXNldCB2Z2E9Nzk0IHZpZGVvPXZlc2FmYiBhY3BpX2VuZm9yY2VfcmVzb3VyY2VzPWxheCBy
ODE2OS51c2VfZGFjPTEgZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3Bh
cnQ9MTAgeGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDU6MDAuKikoMDY6
MDAuKikoMGE6MDEuKikgZGVidWcgbG9nbGV2ZWw9MTAga21lbWxlYWs9b24NClsgICAgNC45
MDgwMTZdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBi
eXRlcykNClsgICAgNC45MDgwMjJdIF9fZXhfdGFibGUgYWxyZWFkeSBzb3J0ZWQsIHNraXBw
aW5nIHNvcnQNClsgICAgNC45NTA5MDRdIHNvZnR3YXJlIElPIFRMQiBbbWVtIDB4M2E2MDAw
MDAtMHgzZTYwMDAwMF0gKDY0TUIpIG1hcHBlZCBhdCBbZmZmZjg4MDAzYTYwMDAwMC1mZmZm
ODgwMDNlNWZmZmZmXQ0KWyAgICA0Ljk1NjIwMV0gTWVtb3J5OiA5MjIxMTZrLzEwNDg1NzZr
IGF2YWlsYWJsZSAoMTAwMzBrIGtlcm5lbCBjb2RlLCA0NTJrIGFic2VudCwgMTI2MDA4ayBy
ZXNlcnZlZCwgNTIxNmsgZGF0YSwgNzk2ayBpbml0KQ0KWyAgICA0Ljk1NjUzOF0gU0xVQjog
R2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWluT2JqZWN0cz0wLCBDUFVz
PTYsIE5vZGVzPTENClsgICAgNC45NTY2NTRdIFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBS
Q1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDQuOTU2NjU2XSAJUkNVIGR5bnRpY2staWRsZSBn
cmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQpbICAgIDQuOTU2NjU4XSAJ
QWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRlZCB3aXRoIHN0YWxscy4NClsgICAgNC45
NTY2NjBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQVVM9OCB0byBucl9jcHVf
aWRzPTYuDQpbICAgIDQuOTU2NzEwXSBOUl9JUlFTOjQzNTIgbnJfaXJxczoxMjcyIDE2DQpb
ICAgIDQuOTU2ODU3XSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFsX2lycT05IHRyaWdnZXI9
MCBwb2xhcml0eT0xDQpbICAgIDQuOTU2ODYxXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA5IHRy
aWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDQuOTU2ODk3XSB4ZW46IC0tPiBwaXJxPTkg
LT4gaXJxPTkgKGdzaT05KQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MjI6MzRdIElPQVBJQ1sw
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEg
QWN0aXZlOjEpDQpbICAgIDQuOTU2OTE2XSB4ZW46IGFjcGkgc2NpIDkNClsgICAgNC45NTY5
MjNdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpDQpbICAgIDQuOTU2OTMwXSB4
ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIgKGdzaT0yKQ0KWyAgICA0Ljk1NjkzN10geGVuOiAt
LT4gcGlycT0zIC0+IGlycT0zIChnc2k9MykNClsgICAgNC45NTY5NDNdIHhlbjogLS0+IHBp
cnE9NCAtPiBpcnE9NCAoZ3NpPTQpDQpbICAgIDQuOTU2OTUwXSB4ZW46IC0tPiBwaXJxPTUg
LT4gaXJxPTUgKGdzaT01KQ0KWyAgICA0Ljk1Njk1Nl0geGVuOiAtLT4gcGlycT02IC0+IGly
cT02IChnc2k9NikNClsgICAgNC45NTY5NjNdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAo
Z3NpPTcpDQpbICAgIDQuOTU2OTcwXSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04
KQ0KWyAgICA0Ljk1Njk3N10geGVuOiAtLT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkN
ClsgICAgNC45NTY5ODRdIHhlbjogLS0+IHBpcnE9MTEgLT4gaXJxPTExIChnc2k9MTEpDQpb
ICAgIDQuOTU2OTkwXSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0xMiAoZ3NpPTEyKQ0KWyAg
ICA0Ljk1Njk5N10geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMgKGdzaT0xMykNClsgICAg
NC45NTcwMDRdIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0IChnc2k9MTQpDQpbICAgIDQu
OTU3MDEwXSB4ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAoZ3NpPTE1KQ0KWyAgICA0Ljk1
NzA4NF0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQ0KWyAgICA0Ljk1NzA4
OV0gY29uc29sZSBbdHR5MF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUgZGlzYWJsZWQNClsgICAg
MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAw
MDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBM
aW51eCB2ZXJzaW9uIDMuOC4wLTIwMTMwMjE5LXR0eSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkg
KGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBU
dWUgRmViIDE5IDA5OjUyOjEwIENFVCAyMDEzDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxp
bmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9Nzk0IHZp
ZGVvPXZlc2FmYiBhY3BpX2VuZm9yY2VfcmVzb3VyY2VzPWxheCByODE2OS51c2VfZGFjPTEg
ZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgeGVuLXBjaWJh
Y2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAuKikoMDU6MDAuKikoMDY6MDAuKikoMGE6MDEuKikg
ZGVidWcgbG9nbGV2ZWw9MTAga21lbWxlYWs9b24NClsgICAgMC4wMDAwMDBdIEZyZWVpbmcg
OWYtMTAwIHBmbiByYW5nZTogOTcgcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBdIDEtMSBt
YXBwaW5nIG9uIDlmLT4xMDANClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIGFmZjkw
LT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDk3IHBhZ2VzIG9mIHVudXNlZCBt
ZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCAzMjc4ODkgcGFnZShzKSB0byAxLTEgbWFwcGlu
Zw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGluZyA0MDAwMC00MDA2MSBwZm4gcmFuZ2U6IDk3
IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNp
Y2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFtt
ZW0gMHgwMDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQw
MDYwZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAw
NjEwMDAtMHgwMDAwMDAwMGFmZjhmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0
YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAw
MDAwYWZmZGZmZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAw
MDAwMGFmZmUwMDAwLTB4MDAwMDAwMDBhZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0w
eDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZm
ZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDEwMDAw
MDAwMC0weDAwMDAwMDAyNGZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBlODIw
OiByZW1vdmUgW21lbSAweDQwMDAwMDAwLTB4ZmZmZmZmZmZmZmZmZmZmZV0gdXNhYmxlDQpb
ICAgIDAuMDAwMDAwXSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsgICAgMC4w
MDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAw
LjAwMDAwMF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAu
MDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVm
ZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwOWYw
MDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjog
W21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDNmZmZmZmZmXSB1c2FibGUNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAwMDBh
ZmY4ZmZmZl0gdW51c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGFmZjkwMDAwLTB4MDAwMDAwMDBhZmY5ZGZmZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAwMDAw
XSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5ZTAwMC0weDAwMDAwMDAwYWZmZGZmZmZdIEFD
UEkgTlZTDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmZlMDAwMC0w
eDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVt
IDB4MDAwMDAwMDBmZWMwMDAwMC0weDAwMDAwMDAwZmVjMDBmZmZdIHJlc2VydmVkDQpbICAg
IDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAwMDAwZmVj
MjBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBm
ZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1
c2VyOiBbbWVtIDB4MDAwMDAwMDBmZmUwMDAwMC0weDAwMDAwMDAwZmZmZmZmZmZdIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAw
MDAwMDAyNGZmZmZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSBTTUJJT1MgMi41IHBy
ZXNlbnQuDQpbICAgIDAuMDAwMDAwXSBETUk6IE1TSSBNUy03NjQwLzg5MEZYQS1HRDcwIChN
Uy03NjQwKSAgLCBCSU9TIFYxLjhCMSAwOS8xMy8yMDEwDQpbICAgIDAuMDAwMDAwXSBlODIw
OiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4MDAwMGZmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBm
ZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdlIGZvdW5kDQpbICAg
IDAuMDAwMDAwXSBlODIwOiBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZuID0gMHg0
MDAwMDAwMDANClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDogW21lbSAw
eDAwMDAwMDAwLTB4MDM5YzlmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFt
cG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAwXSA5OTAwMCBzaXplIDI0NTc2DQpbICAgIDAu
MDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0gcGFnZSA0
aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAw
eDNmZmZmZmZmIEAgW21lbSAweDAyYjFjMDAwLTB4MDJkMWRmZmZdDQpbICAgIDAuMDAwMDAw
XSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjZmMwMDAgLSAyZDFlMDAwDQpbICAgIDAu
MDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJkMWUwMDAtMHgwMzljOWZmZl0NClsgICAgMC4w
MDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjEwMCAwMDAxNCAodjAwIEFDUElBTSkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQgMDAwMDAwMDBhZmY5MDAwMCAwMDA0OCAodjAx
IE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAw
MF0gQUNQSTogRkFDUCAwMDAwMDAwMGFmZjkwMjAwIDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQw
MTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RU
IDAwMDAwMDAwYWZmOTA1ZTAgMDk0MjcgKHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAg
SU5UTCAyMDA1MTExNykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDBhZmY5
ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGFmZjkwMzkw
IDAwMDg4ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3
NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBd
IEFDUEk6IFNMSUMgMDAwMDAwMDBhZmY5MDQ2MCAwMDE3NiAodjAxIE1TSSAgICBPRU1TTElD
ICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogT0VNQiAw
MDAwMDAwMGFmZjllMDQwIDAwMDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1T
RlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1
ZTAgMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAwMDAwMDBhZmY5YTZmMCAwMDAzOCAodjAx
IDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAw
MF0gQUNQSTogSVZSUyAwMDAwMDAwMGFmZjlhNzMwIDAwMTAwICh2MDEgIEFNRCAgICAgUkQ4
OTBTIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RU
IDAwMDAwMDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEg
QU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVz
cyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBOVU1BIHR1cm5lZCBvZmYNClsgICAgMC4w
MDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAw
MDAwMDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21l
bSAweDAwMDAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5PREVfREFUQSBb
bWVtIDB4M2ZmZjUwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIFpvbmUgcmFuZ2Vz
Og0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMTAwMDAtMHgwMGZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgW21lbSAweDAxMDAwMDAwLTB4ZmZmZmZm
ZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAgIGVtcHR5DQpbICAgIDAuMDAwMDAwXSBN
b3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0gRWFybHkg
bWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4
MDAwMTAwMDAtMHgwMDA5ZWZmZl0NClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0g
MHgwMDEwMDAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gT24gbm9kZSAwIHRvdGFs
cGFnZXM6IDI2MjAzMQ0KWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogNjQgcGFnZXMgdXNl
ZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2IHBhZ2VzIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTEzIHBhZ2VzLCBMSUZPIGJhdGNo
OjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogNDAzMiBwYWdlcyB1c2VkIGZvciBt
ZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9uZTogMjU0MDE2IHBhZ2VzLCBMSUZP
IGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgw
OA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAN
ClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4
MDBdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAy
XSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBd
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0
XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0g
bGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAo
aWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAgMC4wMDAw
MDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAw
MDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFk
ZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0KWyAgICAwLjAwMDAwMF0gSU9BUElD
WzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgWyAgICA3Ljg2OTc2MV0gU2Vy
aWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZA0K
WyAgICA3Ljg3NDQ5Ml0gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9D
UlMNClsgICAgNy44NzUzNzRdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMw0KWyAg
ICA3Ljg3ODMyOV0gSGFuZ2NoZWNrOiBzdGFydGluZyBoYW5nY2hlY2sgdGltZXIgMC45LjEg
KHRpY2sgaXMgMTgwIHNlY29uZHMsIG1hcmdpbiBpcyA2MCBzZWNvbmRzKS4NClsgICAgNy44
Nzg1NzJdIEhhbmdjaGVjazogVXNpbmcgZ2V0cmF3bW9ub3RvbmljKCkuDQpbICAgIDcuODc5
MjA5XSBbZHJtXSBJbml0aWFsaXplZCBkcm0gMS4xLjAgMjAwNjA4MTANClsgICAgNy44Nzk2
NTRdIFtkcm1dIFZHQUNPTiBkaXNhYmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcuDQpb
ICAgIDcuODgwOTU5XSBwY2liYWNrIDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgZGV2aWNlICgw
MDAwIC0+IDAwMDMpDQpbICAgIDcuODg3NjQ3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMiB0
cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICA3Ljg5NDI3N10gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDozMg0KWyAgICA3LjkwMTc2MF0gcGNpYmFjayAwMDAwOjA1OjAwLjA6IGVuYWJs
aW5nIGJ1cyBtYXN0ZXJpbmcNClsgICAgNy45MDg1NTldIFtkcm1dIFN1cHBvcnRzIHZibGFu
ayB0aW1lc3RhbXAgY2FjaGluZyBSZXYgMSAoMTAuMTAuMjAxMCkuDQpbICAgIDcuOTE1MzM0
XSBbZHJtXSBObyBkcml2ZXIgc3VwcG9ydCBmb3IgdmJsYW5rIHRpbWVzdGFtcCBxdWVyeS4N
ClsgICAgNy45MjIxMjRdIFtkcm1dIEluaXRpYWxpemVkIHJhZGVvbiAxLjMzLjAgMjAwODA1
MjggZm9yIDAwMDA6MDU6MDAuMCBvbiBtaW5vciAwDQpbICAgIDcuOTQ5NTU3XSBicmQ6IG1v
ZHVsZSBsb2FkZWQNClsgICAgOC4wMzIxODBdIGxvb3A6IG1vZHVsZSBsb2FkZWQNClsgICAg
OC4wNDI0OTldIGFoY2kgMDAwMDowMDoxMS4wOiB2ZXJzaW9uIDMuMA0KWyAgICA4LjA0OTI4
OF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsg
ICAgOC4wNTYwOThdIHhlbjogLS0+IHBpcnE9MTkgLT4gaXJxPTE5IChnc2k9MTkpDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoyMjozOF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDYtMTkgLT4gMHhiOSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KWyAgICA4LjA2
MzI4MV0gYWhjaSAwMDAwOjAwOjExLjA6IEFIQ0kgMDAwMS4wMjAwIDMyIHNsb3RzIDQgcG9y
dHMgNiBHYnBzIDB4ZiBpbXBsIFNBVEEgbW9kZQ0KWyAgICA4LjA3MDA0Nl0gYWhjaSAwMDAw
OjAwOjExLjA6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gcG1wIHBp
byBzbHVtIHBhcnQgDQpbICAgIDguMDgzODkxXSBzY3NpMCA6IGFoY2kNClsgICAgOC4wOTE3
OTFdIHNjc2kxIDogYWhjaQ0KWyAgICA4LjA5OTQzNV0gc2NzaTIgOiBhaGNpDQpbICAgIDgu
MTA3MDQ4XSBzY3NpMyA6IGFoY2kNClsgICAgOC4xMTQxOTJdIGF0YTE6IFNBVEEgbWF4IFVE
TUEvMTMzIGFiYXIgbTEwMjRAMHhmOTZmZjAwMCBwb3J0IDB4Zjk2ZmYxMDAgaXJxIDEyMQ0K
WyAgICA4LjEyMDczNF0gYXRhMjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGY5
NmZmMDAwIHBvcnQgMHhmOTZmZjE4MCBpcnEgMTIxDQpbICAgIDguMTI3MTI0XSBhdGEzOiBT
QVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4Zjk2ZmYwMDAgcG9ydCAweGY5NmZmMjAw
IGlycSAxMjENClsgICAgOC4xMzM0MzFdIGF0YTQ6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIg
bTEwMjRAMHhmOTZmZjAwMCBwb3J0IDB4Zjk2ZmYyODAgaXJxIDEyMQ0KWyAgICA4LjE0MTA4
NV0gdHVuOiBVbml2ZXJzYWwgVFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNClsgICAgOC4x
NDcyNThdIHR1bjogKEMpIDE5OTktMjAwNCBNYXggS3Jhc255YW5za3kgPG1heGtAcXVhbGNv
bW0uY29tPg0KWyAgICA4LjE1MzY3M10gZTEwMDA6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdv
cmsgRHJpdmVyIC0gdmVyc2lvbiA3LjMuMjEtazgtTkFQSQ0KWyAgICA4LjE1OTgyMV0gZTEw
MDA6IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KWyAgICA4
LjE2NjI2MV0gZTEwMDBlOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIDIu
MS40LWsNClsgICAgOC4xNzIzMDFdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDEy
IEludGVsIENvcnBvcmF0aW9uLg0KWyAgICA4LjE3ODczMF0gaWdiOiBJbnRlbChSKSBHaWdh
Yml0IEV0aGVybmV0IE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiA0LjEuMi1rDQpbICAgIDgu
MTg0NzMyXSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDEyIEludGVsIENvcnBvcmF0aW9u
Lg0KWyAgICA4LjE5MDkyMV0gaWdidmY6IEludGVsKFIpIEdpZ2FiaXQgVmlydHVhbCBGdW5j
dGlvbiBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gMi4wLjItaw0KWyAgICA4LjE5Njk2NF0g
aWdidmY6IENvcHlyaWdodCAoYykgMjAwOSAtIDIwMTIgSW50ZWwgQ29ycG9yYXRpb24uDQpb
ICAgIDguMjAzNDYxXSByODE2OSBHaWdhYml0IEV0aGVybmV0IGRyaXZlciAyLjNMSy1OQVBJ
IGxvYWRlZA0KWyAgICA4LjIwOTcxN10geGVuOiByZWdpc3RlcmluZyBnc2kgNDYgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAgOC4yMTU4NzhdIHhlbjogLS0+IHBpcnE9NDYgLT4g
aXJxPTQ2IChnc2k9NDYpDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoyMjozOF0gSU9BUElDWzFd
OiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjIgLT4gMHhjOSAtPiBJUlEgNDYgTW9kZTox
IEFjdGl2ZToxKQ0KWyAgICA4LjIyMjEwM10gcjgxNjkgMDAwMDowOTowMC4wOiBlbmFibGlu
ZyBNZW0tV3ItSW52YWwNClsgICAgOC4yMjk3OTddIHI4MTY5IDAwMDA6MDk6MDAuMCBldGgw
OiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMTAyYzQwMDAsIDQwOjYxOjg2OmY0OjY3
OmQ5LCBYSUQgMDgxMDAwYzAgSVJRIDEyMg0KWyAgICA4LjIzNjA3NV0gcjgxNjkgMDAwMDow
OTowMC4wIGV0aDA6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6IDkyMDAgYnl0ZXMsIHR4IGNo
ZWNrc3VtbWluZzoga29dDQpbICAgIDguMjQyNjEzXSByODE2OSBHaWdhYml0IEV0aGVybmV0
IGRyaXZlciAyLjNMSy1OQVBJIGxvYWRlZA0KWyAgICA4LjI0ODk4MV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgNTEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgOC4yNTUzMTVdIHhl
bjogLS0+IHBpcnE9NTEgLT4gaXJxPTUxIChnc2k9NTEpDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoyMjozOF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhk
OSAtPiBJUlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KWyAgICA4LjI2MTYyMl0gcjgxNjkgMDAw
MDowODowMC4wOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsgICAgOC4yNjk1NThdIHI4MTY5
IDAwMDA6MDg6MDAuMCBldGgxOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMTAyYzYw
MDAsIDQwOjYxOjg2OmY0OjY3OmQ4LCBYSUQgMDgxMDAwYzAgSVJRIDEyMw0KWyAgICA4LjI3
NTk5OF0gcjgxNjkgMDAwMDowODowMC4wIGV0aDE6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6
IDkyMDAgYnl0ZXMsIHR4IGNoZWNrc3VtbWluZzoga29dDQpbICAgIDguMjgzMTMxXSBJbml0
aWFsaXNpbmcgWGVuIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVyLg0KWyAgICA4LjI5MjEwNl0g
ZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERy
aXZlcg0KWyAgICA4LjI5ODU3Ml0gZWhjaS1wY2k6IEVIQ0kgUENJIHBsYXRmb3JtIGRyaXZl
cg0KWyAgICA4LjMwNTAwMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAgOC4zMTE0NTBdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcN
ClsgICAgOC4zMTc5MzRdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgYnVzIG1h
c3RlcmluZw0KWyAgICA4LjMyNDU2MF0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBFSENJIEhv
c3QgQ29udHJvbGxlcg0KWyAgICA4LjMzMTcxNV0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBu
ZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDENClsgICAgOC4z
MzgyMDBdIFFVSVJLOiBFbmFibGUgQU1EIFBMTCBmaXgNClsgICAgOC4zNDQ2NzBdIGVoY2kt
cGNpIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMg
RUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpbICAgIDguMzUxMzE0XSBlaGNpLXBjaSAwMDAw
OjAwOjEyLjI6IGRlYnVnIHBvcnQgMQ0KWyAgICA4LjM1NzkzMF0gZWhjaS1wY2kgMDAwMDow
MDoxMi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNClsgICAgOC4zNjQ1ODRdIGVoY2ktcGNp
IDAwMDA6MDA6MTIuMjogaXJxIDE3LCBpbyBtZW0gMHhmOTZmZjQwMA0KWyAgICA4LjM3ODcx
OF0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0K
WyAgICA4LjM4NTU0NF0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KWyAgICA4LjM5MTkyMF0gdXNiIHVzYjE6IE5ldyBV
U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpb
ICAgIDguMzk4MjM1XSB1c2IgdXNiMTogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIN
ClsgICAgOC40MDQ2NzldIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLTIw
MTMwMjE5LXR0eSBlaGNpX2hjZA0KWyAgICA4LjQxMTA0NF0gdXNiIHVzYjE6IFNlcmlhbE51
bWJlcjogMDAwMDowMDoxMi4yDQpbICAgIDguNDE4ODYxXSBodWIgMS0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KWyAgICA4LjQyNTI5Ml0gaHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQN
ClsgICAgOC40MzI1ODddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDguNDM4NzUyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3DQpb
ICAgIDguNDQ1MDM0XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJsaW5nIGJ1cyBtYXN0
ZXJpbmcNClsgICAgOC40NTEzMDJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogRUhDSSBIb3N0
IENvbnRyb2xsZXINClsgICAgOC40NTc5NDJdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogbmV3
IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyDQpbICAgIDguNDU4
Njk3XSBhdGE0OiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkNClsg
ICAgOC40NTg3NjhdIGF0YTI6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wg
MzAwKQ0KWyAgICA4LjQ3NjU0Ml0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBhcHBseWluZyBB
TUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQNClsg
ICAgOC40ODI4NjFdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZGVidWcgcG9ydCAxDQpbICAg
IDguNDg5MjI0XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJsaW5nIE1lbS1Xci1JbnZh
bA0KWyAgICA4LjQ5NTUxOV0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBpcnEgMTcsIGlvIG1l
bSAweGY5NmZmODAwDQpbICAgIDguNTEyMDUwXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IFVT
QiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwDQpbICAgIDguNTE4NDY2XSB1c2IgdXNiMjogTmV3
IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpbICAg
IDguNTI0OTA4XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy
b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgOC41MzEzNjhdIHVzYiB1c2IyOiBQcm9k
dWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4LjUzNzkxOF0gdXNiIHVzYjI6IE1h
bnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAyMTktdHR5IGVoY2lfaGNkDQpbICAgIDgu
NTQ0NDkxXSB1c2IgdXNiMjogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEzLjINClsgICAgOC41
NTIwMDRdIGh1YiAyLTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDguNTU4NDI0XSBodWIg
Mi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICA4LjU2NTczNF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgOC41NzIwOTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAgOC41Nzg0MjNdIGVoY2ktcGNpIDAwMDA6
MDA6MTYuMjogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgICA4LjU4NDg0N10gZWhjaS1w
Y2kgMDAwMDowMDoxNi4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4LjU5MTU5Ml0g
ZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l
ZCBidXMgbnVtYmVyIDMNClsgICAgOC41OTc4MTddIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjog
YXBwbHlpbmcgQU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3Jr
YXJvdW5kDQpbICAgIDguNjA0MjAzXSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGRlYnVnIHBv
cnQgMQ0KWyAgICA4LjYxMDUxNV0gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBlbmFibGluZyBN
ZW0tV3ItSW52YWwNClsgICAgOC42MTY2ODNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogaXJx
IDE3LCBpbyBtZW0gMHhmOTZmZmMwMA0KWyAgICA4LjYyNTM3MF0gYXRhMzogU0FUQSBsaW5r
IHVwIDYuMCBHYnBzIChTU3RhdHVzIDEzMyBTQ29udHJvbCAzMDApDQpbICAgIDguNjMxNjI5
XSBhdGExOiBTQVRBIGxpbmsgdXAgMy4wIEdicHMgKFNTdGF0dXMgMTIzIFNDb250cm9sIDMw
MCkNClsgICAgOC42MzIwMzhdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFy
dGVkLCBFSENJIDEuMDANClsgICAgOC42MzI0MjddIHVzYiB1c2IzOiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAgOC42MzI0Mjhd
IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MQ0KWyAgICA4LjYzMjQzMF0gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kg
SG9zdCBDb250cm9sbGVyDQpbICAgIDguNjMyNDMxXSB1c2IgdXNiMzogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjguMC0yMDEzMDIxOS10dHkgZWhjaV9oY2QNClsgICAgOC42MzI0MzJdIHVz
YiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMg0KWyAgICA4LjYzMzkzMV0gaHVi
IDMtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgOC42MzM5ODFdIGh1YiAzLTA6MS4wOiA0
IHBvcnRzIGRldGVjdGVkDQpbICAgIDguNjM0Nzk1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAz
MSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICA4LjYzNDc5N10gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDozMQ0KWyAgICA4LjYzNDg0MV0gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBl
bmFibGluZyBidXMgbWFzdGVyaW5nDQpbICAgIDguNjM0ODQ5XSBlaGNpLXBjaSAwMDAwOjBi
OjAxLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDguNjM1NDc3XSBlaGNpLXBjaSAw
MDAwOjBiOjAxLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1i
ZXIgNA0KWyAgICA4LjYzNTc1NF0gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBpcnEgMzEsIGlv
IG1lbSAweGY5ZmZmYzAwDQpbICAgIDguNjQ1MzIwXSBlaGNpLXBjaSAwMDAwOjBiOjAxLjI6
IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwDQpbICAgIDguNjQ1NjEyXSB1c2IgdXNiNDog
TmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpb
ICAgIDguNjQ1NjEzXSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMs
IFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgOC42NDU2NTNdIHVzYiB1c2I0OiBQ
cm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4LjY0NTY1NF0gdXNiIHVzYjQ6
IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAyMTktdHR5IGVoY2lfaGNkDQpbICAg
IDguNjQ1NjU1XSB1c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjBiOjAxLjINClsgICAg
OC42NDcxMDFdIGh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDguNjQ3MTczXSBo
dWIgNC0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICA4LjY0ODY5Ml0gb2hjaV9oY2Q6
IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVyDQpbICAgIDgu
NjQ4NzkyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICA4LjY0ODc5NV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgICA4LjY0
ODg1OF0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQpb
ICAgIDguNjQ4ODY2XSBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9s
bGVyDQpbICAgIDguNjQ5NDkyXSBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IG5ldyBVU0IgYnVz
IHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgICA4LjY0OTc0Nl0gb2hj
aV9oY2QgMDAwMDowMDoxMi4wOiBpcnEgMTgsIGlvIG1lbSAweGY5NmZiMDAwDQpbICAgIDgu
NzA2MzcwXSB1c2IgdXNiNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAxDQpbICAgIDguNzA2MzcyXSB1c2IgdXNiNTogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgOC43
MDYzNzNdIHVzYiB1c2I1OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICA4
LjcwNjM3NF0gdXNiIHVzYjU6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAyMTkt
dHR5IG9oY2lfaGNkDQpbICAgIDguNzA2Mzc1XSB1c2IgdXNiNTogU2VyaWFsTnVtYmVyOiAw
MDAwOjAwOjEyLjANClsgICAgOC43MDgxMjFdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5k
DQpbICAgIDguNzA4MTgwXSBodWIgNS0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICA4
LjcwOTI3Nl0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5
IDENClsgICAgOC43MDkyNzhdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAgOC43
MDkzMjVdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0K
WyAgICA4LjcwOTMzMl0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBPSENJIEhvc3QgQ29udHJv
bGxlcg0KWyAgICA4LjcxMDA1OV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBuZXcgVVNCIGJ1
cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDYNClsgICAgOC43MTAyNjhdIG9o
Y2lfaGNkIDAwMDA6MDA6MTMuMDogaXJxIDE4LCBpbyBtZW0gMHhmOTZmYzAwMA0KWyAgICA4
Ljc2NjE5Ml0gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi
LCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICA4Ljc2NjE5M10gdXNiIHVzYjY6IE5ldyBVU0IgZGV2
aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDgu
NzY2MTk0XSB1c2IgdXNiNjogUHJvZHVjdDogT0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAg
OC43NjYxOTVdIHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLTIwMTMwMjE5
LXR0eSBvaGNpX2hjZA0KWyAgICA4Ljc2NjE5Nl0gdXNiIHVzYjY6IFNlcmlhbE51bWJlcjog
MDAwMDowMDoxMy4wDQpbICAgIDguNzY3OTQxXSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3Vu
ZA0KWyAgICA4Ljc2Nzk5NF0gaHViIDYtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAg
OC43Njg5MTRdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0
eSAxDQpbICAgIDguNzY4OTE2XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDgu
NzY4OTYzXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcN
ClsgICAgOC43Njg5NzBdIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogT0hDSSBIb3N0IENvbnRy
b2xsZXINClsgICAgOC43Njk2ODldIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3DQpbICAgIDguNzY5OTAxXSBv
aGNpX2hjZCAwMDAwOjAwOjE0LjU6IGlycSAxOCwgaW8gbWVtIDB4Zjk2ZmQwMDANClsgICAg
OC44MjYyMTRdIHVzYiB1c2I3OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDENClsgICAgOC44MjYyMTVdIHVzYiB1c2I3OiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICA4
LjgyNjIxNl0gdXNiIHVzYjc6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAg
IDguODI2MjE3XSB1c2IgdXNiNzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC0yMDEzMDIx
OS10dHkgb2hjaV9oY2QNClsgICAgOC44MjYyMThdIHVzYiB1c2I3OiBTZXJpYWxOdW1iZXI6
IDAwMDA6MDA6MTQuNQ0KWyAgICA4LjgyNzc3NV0gaHViIDctMDoxLjA6IFVTQiBodWIgZm91
bmQNClsgICAgOC44Mjc4NDJdIGh1YiA3LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAg
IDguODI4NDczXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQ0KWyAgICA4LjgyODQ3NV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgICA4
LjgyODU1N10gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5n
DQpbICAgIDguODI4NTY1XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IE9IQ0kgSG9zdCBDb250
cm9sbGVyDQpbICAgIDguODI5MjY2XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IG5ldyBVU0Ig
YnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgOA0KWyAgICA4LjgyOTM2NF0g
b2hjaV9oY2QgMDAwMDowMDoxNi4wOiBpcnEgMTgsIGlvIG1lbSAweGY5NmZlMDAwDQpbICAg
IDguODg2MjQwXSB1c2IgdXNiODogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFk
NmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDguODg2MjQxXSB1c2IgdXNiODogTmV3IFVTQiBk
ZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAg
OC44ODYyNDJdIHVzYiB1c2I4OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAg
ICA4Ljg4NjI0M10gdXNiIHVzYjg6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtMjAxMzAy
MTktdHR5IG9oY2lfaGNkDQpbICAgIDguODg2MjQ0XSB1c2IgdXNiODogU2VyaWFsTnVtYmVy
OiAwMDAwOjAwOjE2LjANClsgICAgOC44ODc3MzldIGh1YiA4LTA6MS4wOiBVU0IgaHViIGZv
dW5kDQpbICAgIDguODg3NzkxXSBodWIgOC0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KWyAg
ICA4Ljg4ODgyMl0geGVuOiByZWdpc3RlcmluZyBnc2kgMjkgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgOC44ODg4MjRdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjkNClsgICAg
OC44ODg4NjldIG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogZW5hYmxpbmcgYnVzIG1hc3Rlcmlu
Zw0KWyAgICA4Ljg4ODg3N10gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBPSENJIEhvc3QgQ29u
dHJvbGxlcg0KWyAgICA4Ljg4OTcyNF0gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBuZXcgVVNC
IGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkNClsgICAgOC44ODk5MjFd
IG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogaXJxIDI5LCBpbyBtZW0gMHhmOWZmZDAwMA0KWyAg
ICA4Ljk3MjE2MV0gdXNiIHVzYjk6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0x
ZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICA4Ljk3MjE2M10gdXNiIHVzYjk6IE5ldyBVU0Ig
ZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAg
IDguOTcyMTY0XSB1c2IgdXNiOTogUHJvZHVjdDogT0hDSSBIb3N0IENvbnRyb2xsZXINClsg
ICAgOC45NzIxNjVdIHVzYiB1c2I5OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLTIwMTMw
MjE5LXR0eSBvaGNpX2hjZA0KWyAgICA4Ljk3MjE2Nl0gdXNiIHVzYjk6IFNlcmlhbE51bWJl
cjogMDAwMDowYjowMS4wDQpbICAgIDguOTczOTAxXSBodWIgOS0wOjEuMDogVVNCIGh1YiBm
b3VuZA0KWyAgICA4Ljk3Mzk5OV0gaHViIDktMDoxLjA6IDMgcG9ydHMgZGV0ZWN0ZWQNClsg
ICAgOC45NzQ3NjBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMwIHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQpbICAgIDguOTc0NzYyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjMwDQpbICAg
IDguOTc0ODA1XSBvaGNpX2hjZCAwMDAwOjBiOjAxLjE6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJp
bmcNClsgICAgOC45NzQ4MTNdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMTogT0hDSSBIb3N0IENv
bnRyb2xsZXINClsgICAgOC45NzU0MDJdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMTogbmV3IFVT
QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxMA0KWyAgICA4Ljk3NTU4
M10gb2hjaV9oY2QgMDAwMDowYjowMS4xOiBpcnEgMzAsIGlvIG1lbSAweGY5ZmZlMDAwDQpb
ICAgIDkuMDU4ODAwXSB1c2IgdXNiMTA6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICA5LjA1ODgwMl0gdXNiIHVzYjFbICAgMTEu
MzU0NDYwXSBiaW86IGNyZWF0ZSBzbGFiIDxiaW8tMT4gYXQgMQ0KWyAgIDExLjc0MjExNV0g
RVhUNC1mcyAoZG0tMCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBt
b2RlLiBPcHRzOiAobnVsbCkNClsgICAxMy41ODQ3MTNdIHVkZXZbMTgzOF06IHN0YXJ0aW5n
IHZlcnNpb24gMTY0DQpbICAgMTQuNTY4OTQzXSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBV
RE1BLzEzMw0KWyAgIDE0LjU3NTA5NV0gYXRhMTogRUggY29tcGxldGUNClsgICAxNS4xODg1
ODldIGF0YTEuMDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTMzDQpbICAgMTUuMTg4NTk3XSBh
dGExOiBFSCBjb21wbGV0ZQ0KWyAgIDE1LjkxNzkzMV0gRVhUNC1mcyAoZG0tMCk6IHJlLW1v
dW50ZWQuIE9wdHM6IChudWxsKQ0KWyAgIDE2LjI2OTY0OF0gRVhUNC1mcyAoZG0tMCk6IHJl
LW1vdW50ZWQuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDI3LjE1
OTcyMV0gQWRkaW5nIDIwOTcxNDhrIHN3YXAgb24gL2Rldi9tYXBwZXIvc2VydmVlcnN0ZXJ0
amUtc3dhcC4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6MjA5NzE0OGsgDQpbICAg
MzYuMTUxMTI3XSBFWFQ0LWZzIChzZGExKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3Jk
ZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAg
IDM2LjE5NTA5OF0gYnRyZnM6IG9wZW4gVVVJRD0iYjJkYWMyNTUtYTk2ZS00NzJlLTgwNmYt
NTY3OWUwMjY2ZjZlIiBmYWlsZWQNClsgICAzOC41MzY2NjFdIHI4MTY5IDAwMDA6MDg6MDAu
MCBldGgxOiBsaW5rIGRvd24NClsgICAzOC41NDM0MjNdIHI4MTY5IDAwMDA6MDg6MDAuMCBl
dGgxOiBsaW5rIGRvd24NClsgICAzOC43MDk4NzJdIHI4MTY5IDAwMDA6MDk6MDAuMCBldGgw
OiBsaW5rIGRvd24NClsgICAzOC43MDk5MzhdIHI4MTY5IDAwMDA6MDk6MDAuMCBldGgwOiBs
aW5rIGRvd24NClsgICA0MC4yMTkwNDddIHI4MTY5IDAwMDA6MDg6MDAuMCBldGgxOiBsaW5r
IHVwDQpbICAgNDAuMzgzMDE1XSByODE2OSAwMDAwOjA5OjAwLjAgZXRoMDogbGluayB1cA0K
WyAgIDYwLjMzOTg5MF0gRlc6IGlwbWFzcSwgRm9yd2FyZCAuLiBFb0M6IElOPWV0aDAgT1VU
PWV0aDAgTUFDPTQwOjYxOjg2OmY0OjY3OmQ5OjAwOjA4OmFlOjEwOjQ2OjYwOjA4OjAwIFNS
Qz04Mi4xNzMuOTcuMTUgRFNUPTg4LjE1OS44MC4xOSBMRU49NTggVE9TPTB4MDAgUFJFQz0w
eDAwIFRUTD0xMTUgSUQ9MjQwNTcgUFJPVE89VURQIFNQVD0xNjgwMCBEUFQ9MzQyODkgTEVO
PTM4IA0KWyAgIDY4LjE4MjI0OF0gc3NoZCAoNjQ0Nyk6IC9wcm9jLzY0NDcvb29tX2FkaiBp
cyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzY0NDcvb29tX3Njb3JlX2FkaiBpbnN0
ZWFkLg0KWyAgIDcyLjUxNzA1N10gRVhUNC1mcyAoZG0tMik6IG1vdW50ZWQgZmlsZXN5c3Rl
bSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91
bnQtcm8NClsgICA3Ni41NTY5MzldIEVYVDQtZnMgKGRtLTM2KTogbW91bnRlZCBmaWxlc3lz
dGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVt
b3VudC1ybw0KWyAgIDgwLjkyNTM1OF0gRVhUNC1mcyAoZG0tMzcpOiBtb3VudGVkIGZpbGVz
eXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1y
ZW1vdW50LXJvDQpbICAgODUuNDAyNjYyXSBFWFQ0LWZzIChkbS0zOCk6IG1vdW50ZWQgZmls
ZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3Jz
PXJlbW91bnQtcm8NClsgICA4OS44MTY3ODZdIEVYVDQtZnMgKGRtLTM5KTogbW91bnRlZCBm
aWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJv
cnM9cmVtb3VudC1ybw0KWyAgIDk2LjA1NzEwNF0gRVhUNC1mcyAoZG0tNDApOiBtb3VudGVk
IGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVy
cm9ycz1yZW1vdW50LXJvDQpbICAxMDAuODYyNDI0XSBFWFQ0LWZzIChzZGIxKTogbW91bnRl
ZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxl
cnJvcnM9cmVtb3VudC1ybw0K
------------0791EC21F164E2952
Content-Type: application/octet-stream;
 name="serial-log-3.9-rc0.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log-3.9-rc0.log"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyAv
ICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8vIF8g
XCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf
IFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8
IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98ICAg
IHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxl
IChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgZGVidWc9
eSBTYXQgRmViIDIzIDE5OjU4OjA5IENFVCAyMDEzDQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0
OiB1bmF2YWlsYWJsZQ0KKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0
K3NxdWVlemUxDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTEwMjRNLG1heDoxMDI0
TSBsb2dsdmw9YWxsIGxvZ2x2bF9ndWVzdD1hbGwgY29uc29sZV90aW1lc3RhbXBzIHZnYT1n
ZngtMTI4MHgxMDI0eDMyIGNwdWlkbGUgY3B1ZnJlcT14ZW4gbm9yZWJvb3QgZGVidWcgbGFw
aWM9ZGVidWcgYXBpY192ZXJib3NpdHk9ZGVidWcgYXBpYz1kZWJ1ZyBpb21tdT1vbix2ZXJi
b3NlLGRlYnVnLGFtZC1pb21tdS1kZWJ1Zyxuby1hbWQtaW9tbXUtcGVyZGV2LWludHJlbWFw
IGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZpZGVvIGluZm9ybWF0
aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAyNCwgMzIgYnBwDQoo
WEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAxIHNlY29u
ZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQgMiBNQlIgc2lnbmF0
dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMNCihYRU4p
IFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAw
MDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAwIC0gMDAwMDAwMDAw
MDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAwMCAtIDAwMDAwMDAw
MDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAw
MGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAwMCAtIDAwMDAwMDAw
YWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjllMDAwIC0gMDAwMDAw
MDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZlMDAwMCAtIDAwMDAw
MDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAw
MDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAw
MDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjEwMCwgMDAx
NCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwgMDA0OCAocjEgTVNJ
ICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBGQUNQ
IEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAg
ICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIxICBBNzY0MCBBNzY0
MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTogRkFDUyBBRkY5RTAw
MCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAocjEgNzY0ME1TIEE3
NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIEFGRjkw
NDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykN
CihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAgICBPRU1TTElDICAy
MDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBBRkY5RTA0MCwgMDA3
MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBB
Q1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0ZfMTAgICAgICAgIDIg
QU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAsIDAwMzggKHIxIDc2
NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogSVZS
UyBBRkY5QTczMCwgMDEwMCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAgICAg
ICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChyMSBBIE0gSSAgUE9X
RVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3RlbSBSQU06IDgxOTFN
QiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0K
KFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhN
IDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+
IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5vZGUgMA0KKFhFTikg
U1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogTm9kZSAwIFBY
TSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYjAwMDAwMDAN
CihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAwMDAwDQooWEVOKSBO
VU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDg3NjAwMCAtIDI0ZDg3OTAwMA0K
KFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21haW4g
aGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGZiMDAw
MDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwg
MTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBsaW5lbGVuZ3Ro
PTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9ODo4Ojg6
OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3
ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0YXRlIGlzICd4YXBp
YycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIEFDUEk6IFBNLVRp
bWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBTTEVFUCBJTkZPOiBwbTF4X2NudFs4
MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgd2FrZXVw
X3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTogTG9jYWwgQVBJQyBh
ZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxh
cGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAgMDoxMCBBUElDIHZl
cnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4
MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElDIHZlcnNpb24gMTYN
CihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lkWzB4MDJdIGVuYWJs
ZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVuYWJsZWQpDQooWEVO
KSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNz
b3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lk
WzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzUgMDox
MCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVz
c1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1swXTogYXBpY19pZCA2
LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQooWEVOKSBBQ1BJ
OiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3NpX2Jhc2VbMjRdKQ0K
KFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMy
MDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2ly
cSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KKFhFTikgQUNQSTogSVJR
MCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRl
Lg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgRW5hYmxpbmcg
QVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVOKSBBQ1BJOiBIUEVU
IGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUgaXMgbm90IGZvdW5k
IQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9y
bWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQoo
WEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZiMDAwIChmZWUwMDAwMCkNCihYRU4p
IG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYTAwMCAoZmVjMDAwMDApDQooWEVOKSBt
YXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQ0KKFhFTikgSVJR
IGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNpbmcgc2NoZWR1bGVy
OiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0ZWN0ZWQgMzIwMC4y
MDggTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJpbmcuDQooWEVO
KSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4pIFBD
STogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1
c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9yIHNlZ21lbnQgMDAw
MCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxvY2sg
YXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAgU2ln
bmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweDEwMA0KKFhFTikgQU1ELVZp
OiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweDg5DQooWEVOKSBB
TUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBSRDg5
MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIwMjAzMQ0KKFhFTikgQU1ELVZp
OiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9uIDAN
CihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4M2UgbGVuIDB4
ZDAgaWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBp
ZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MTAgZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhjMDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHgxOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MiBpZCAweGEwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0
eXBlIDB4NDMgaWQgMHhiMDggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdl
OiAweGIwOCAtPiAweGJmZiBhbGlhcyAweGIwMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeTogdHlwZSAweDIgaWQgMHgyOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDkwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4ODAwIGZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDggZmxhZ3Mg
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg3MDAg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHg1MCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MiBpZCAweDYwMCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0
eXBlIDB4MiBpZCAweDU4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgzIGlkIDB4NTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBS
YW5nZTogMHg1MDAgLT4gMHg1MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
IHR5cGUgMHgyIGlkIDB4NjggZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAweDIgaWQgMHg0MDAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHg4OCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDkwIGZsYWdzIDANCihYRU4pIEFNRC1W
aTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDk4IGZsYWdzIDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5OiB0eXBlIDB4MiBpZCAweGEwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTEgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMyBmbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweGE0IGZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMCBpZCAwIGZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0MyBpZCAweDMwMCBmbGFncyAw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmIGFsaWFzIDB4
YTQNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4YTUg
ZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHhhOCBmbGFncyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4
MiBpZCAweGE5IGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5
cGUgMHgyIGlkIDB4MTAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgzIGlkIDB4YjAgZmxhZ3MgMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJh
bmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5
cGUgMCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5
cGUgMHg0OCBpZCAwIGZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBTcGVjaWFsOiAw
MDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBTcGVjaWFsOiAwMDAwOjAwOjAwLjEgdmFyaWV0eSAweDEgaGFuZGxlIDB4Nw0KKFhFTikg
SVZIRCBFcnJvcjogbm8gaW5mb3JtYXRpb24gZm9yIElPLUFQSUMgMHg2DQooWEVOKSBBTUQt
Vmk6IElPTU1VIDAgRW5hYmxlZC4NCihYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFsIHZl
Y3RvciBtYXANCihYRU4pIEFNRC1WaTogVXNpbmcgZ2xvYmFsIGludGVycnVwdCByZW1hcCB0
YWJsZSBpcyBub3QgcmVjb21tZW5kZWQgKHNlZSBYU0EtMzYpIQ0KKFhFTikgSS9PIHZpcnR1
YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikg
R2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1
MDAxMA0KKFhFTikgR2V0dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihY
RU4pIEdldHRpbmcgTFZUMTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0K
KFhFTikgRVNSIHZhbHVlIGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4NCAgYWZ0ZXI6IDAN
CihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sg
bWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNp
ZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwg
Ni0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05
LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4
LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3
LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVS
OiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBu
dW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMg
IzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVy
czogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAw
NjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVO
KSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExU
UyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhF
TikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikg
Li4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDog
SU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAw
MDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6
IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQ
aHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAw
MCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikg
IDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4p
ICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVO
KSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhF
TikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihY
RU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQoo
WEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0K
KFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgN
CihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDYw
DQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2
OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVn
aXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMg
aWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4u
Li4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAw
MDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczog
MDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4u
Li4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVy
ICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQoo
WEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1h
c2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
NSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0K
KFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4p
IElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0
DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAg
LT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikg
SVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4g
MDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVO
KSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMu
DQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNs
b2NrIHNwZWVkIGlzIDMyMDAuMTIwMyBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9j
ayBzcGVlZCBpcyAyMDAuMDA3NCBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweGNj
ZDcNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBQbGF0Zm9ybSB0aW1lciBpcyAxNC4z
MThNSHogSFBFVA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEFsbG9jYXRlZCBjb25z
b2xlIHJpbmcgb2YgNjQgS2lCLg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEhWTTog
QVNJRHMgZW5hYmxlZC4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBTVk06IFN1cHBv
cnRlZCBhZHZhbmNlZCBmZWF0dXJlczoNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSAg
LSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5
XSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24NCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjEzOjQ5XSAgLSBOZXh0LVJJUCBTYXZlZCBvbiAjVk1FWElUDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gIC0gUGF1c2UtSW50ZXJjZXB0IEZpbHRlcg0KKFhF
TikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEhWTTogU1ZNIGVuYWJsZWQNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBk
ZXRlY3RlZA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIEhWTTogSEFQIHBhZ2Ugc2l6
ZXM6IDRrQiwgMk1CLCAxR0INCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ4XSBtYXNrZWQg
RXh0SU5UIG9uIENQVSMxDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gbWljcm9jb2Rl
OiBDUFUxIGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MTM6NDhdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzINCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSBtaWNyb2NvZGU6IENQVTIgY29sbGVjdF9jcHVfaW5mbzogcGF0
Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OF0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIG1pY3JvY29kZTog
Q1BVMyBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ4XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM0DQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoxMzo0OV0gbWljcm9jb2RlOiBDUFU0IGNvbGxlY3RfY3B1X2luZm86IHBhdGNo
X2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDhdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzUNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBCcm91Z2h0IHVwIDYg
Q1BVcw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIG1pY3JvY29kZTogQ1BVNSBjb2xs
ZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjEzOjQ5XSBIUEVUOiAzIHRpbWVycyAoMyB3aWxsIGJlIHVzZWQgZm9yIGJyb2FkY2FzdCkN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhF
TikgWzIwMTMtMDItMjUgMjA6MTM6NDldIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBh
ZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBt
Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJ
QlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NDldICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NDldIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1z
ej0weGRjYzAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl9wYXJzZV9iaW5h
cnk6IHBoZHI6IHBhZGRyPTB4MWUwMDAwMCBtZW1zej0weGVhMGYwDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoxMzo0OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWViMDAw
IG1lbXN6PTB4MTQwNDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBlbGZfcGFyc2Vf
YmluYXJ5OiBwaGRyOiBwYWRkcj0weDFmMDAwMDAgbWVtc3o9MHhlNzAwMDANCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjEzOjQ5XSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAw
MCAtPiAweDJkNzAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6
NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVOKSBb
MjAxMy0wMi0yNSAyMDoxMzo0OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9
ICJ4ZW4tMy4wIg0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5fcGFyc2Vf
bm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo0OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MWYw
MDFlMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTog
SFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjQ5XSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9w
YWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIg0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MTM6NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVy
aWMiDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiB1
bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDld
IGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9IDB4
ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldIGVsZl94ZW5f
cGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo0OV0gZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjQ5XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw
MDAwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NDldICAgICBlbGZfcGFkZHJfb2Zmc2V0
ID0gMHgwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gICAgIHZpcnRfb2Zmc2V0ICAg
ICAgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSAg
ICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MTM6NDldICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyZDcw
MDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo0OV0gICAgIHZpcnRfZW50cnkgICAgICAg
PSAweGZmZmZmZmZmODFmMDAxZTANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjQ5XSAgICAg
cDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MTM6NDldICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQooWEVO
KSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNi
LCBwYWRkciAweDEwMDAwMDAgLT4gMHgyZDcwMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo1MF0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NTBdICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAwLT4wMDAwMDAwMjQ0
MDAwMDAwICgyNDI1MTYgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MTM6NTBdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjRmMzU0MDAwLT4wMDAwMDAw
MjRmZmZmYzAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gVklSVFVBTCBNRU1PUlkg
QVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gIExvYWRlZCBrZXJu
ZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJkNzAwMDANCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjEzOjUwXSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MmQ3MDAwMC0+ZmZmZmZm
ZmY4M2ExYmMwMA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdICBQaHlzLU1hY2ggbWFw
OiBmZmZmZmZmZjgzYTFjMDAwLT5mZmZmZmZmZjgzYzFjMDAwDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo1MF0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNjMWMwMDAtPmZmZmZmZmZm
ODNjMWM0YjQNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSAgUGFnZSB0YWJsZXM6ICAg
ZmZmZmZmZmY4M2MxZDAwMC0+ZmZmZmZmZmY4M2M0MDAwMA0KKFhFTikgWzIwMTMtMDItMjUg
MjA6MTM6NTBdICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgzYzQwMDAwLT5mZmZmZmZmZjgz
YzQxMDAwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gIFRPVEFMOiAgICAgICAgIGZm
ZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIw
OjEzOjUwXSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWYwMDFlMA0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MTM6NTBdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIwMTMt
MDItMjUgMjA6MTM6NTBdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4
MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkY2MwMDANCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEz
OjUwXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFlMDAwMDAgLT4g
MHhmZmZmZmZmZjgxZWVhMGYwDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gZWxmX2xv
YWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxZWViMDAwIC0+IDB4ZmZmZmZmZmY4
MWVmZjA0MA0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIGVsZl9sb2FkX2JpbmFyeTog
cGhkciAzIGF0IDB4ZmZmZmZmZmY4MWYwMDAwMCAtPiAweGZmZmZmZmZmODFmZmYwMDANCihY
RU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAwLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4
MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAy
LTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDEwLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MTgsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDMwLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NDgsIHJvb3QgdGFi
bGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg1MCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCByb290IHRhYmxlID0gMHgy
NDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDIt
MjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4NjgsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEz
OjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwLCBy
b290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4OTIsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0YWJs
ZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDlhLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAsIHJvb3QgdGFibGUgPSAweDI0
N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHhhMSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEzLCByb290IHRhYmxlID0gMHgyNDdiMTEwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6
NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTQsIHJv
b3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHhhNSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE4LCByb290IHRhYmxl
ID0gMHgyNDdiMTEwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTMtMDItMjUgMjA6MTM6NTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4YjAsIHJvb3QgdGFibGUgPSAweDI0N2IxMTAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMiwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjUwXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4wDQoo
WEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MF0gc2V0dXAgMDAwMDowMDoxOC4wIGZvciBkMCBm
YWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUwXSBBTUQtVmk6IE5vIGlv
bW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1
MF0gc2V0dXAgMDAwMDowMDoxOC4xIGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDox
OC4yDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MV0gc2V0dXAgMDAwMDowMDoxOC4yIGZv
ciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6
IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMy0wMi0yNSAy
MDoxMzo1MV0gc2V0dXAgMDAwMDowMDoxOC4zIGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAw
MDowMDoxOC40DQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1MV0gc2V0dXAgMDAwMDowMDox
OC40IGZvciBkMCBmYWlsZWQgKC0xOSkNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDQwMCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDUwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMSwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDYwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDgwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEz
OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGEwMCwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweGIwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGMwMCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjExMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjUxXSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uZG9uZS4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjEzOjUzXSBJbml0aWFsIGxvdyBt
ZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsyMDEz
LTAyLTI1IDIwOjEzOjUzXSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEzLTAyLTI1
IDIwOjEzOjUzXSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMy0wMi0yNSAyMDox
Mzo1M10gWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAxMy0w
Mi0yNSAyMDoxMzo1M10gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEn
IHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMy0wMi0y
NSAyMDoxMzo1M10gRnJlZWQgMjQ4a0IgaW5pdCBtZW1vcnkuDQptYXBwaW5nIGtlcm5lbCBp
bnRvIHBoeXNpY2FsIG1lbW9yeQ0KYWJvdXQgdG8gZ2V0IHN0YXJ0ZWQuLi4NClsgICAgMC4w
MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdXNldA0KWyAgICAwLjAwMDAw
MF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpbICAgIDAuMDAwMDAwXSBMaW51
eCB2ZXJzaW9uIDMuOC4wLXJjMC0yMDEzMDIyNSAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdj
YyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBNb24g
RmViIDI1IDIwOjMyOjQ0IENFVCAyMDEzDQpbICAgIDAuMDAwMDAwXSBGcmVlaW5nIDlmLTEw
MCBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGZyZWVkDQpbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCA5
NyBwYWdlcyBvZiB1bnVzZWQgbWVtb3J5DQpbICAgIDAuMDAwMDAwXSBTZXQgMzI3ODg5IHBh
Z2UocykgdG8gMS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFBvcHVsYXRpbmcgNDAwMDAt
NDAwNjEgcGZuIHJhbmdlOiA5NyBwYWdlcyBhZGRlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDog
QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVmZmZdIHVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZjAwMC0weDAwMDAwMDAwMDAw
ZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAw
MTAwMDAwLTB4MDAwMDAwMDA0MDA2MGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46
IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAwMDBhZmY4ZmZmZl0gdW51c2FibGUN
ClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYWZmOTAwMDAtMHgwMDAwMDAw
MGFmZjlkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwYWZmOWUwMDAtMHgwMDAwMDAwMGFmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmZlMDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4
MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAwMDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAw
LjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBm
ZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAw
MDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjog
W21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0K
WyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBlbmFibGVkDQpbICAgIDAu
MDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNClsgICAg
MC4wMDAwMDBdIGU4MjA6IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAw
LjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAwMDll
ZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDlm
MDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6
IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0gdXNhYmxlDQpb
ICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA0MDA2MTAwMC0weDAwMDAwMDAw
YWZmOGZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAw
MDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAw
MF0gdXNlcjogW21lbSAweDAwMDAwMDAwYWZmOWUwMDAtMHgwMDAwMDAwMGFmZmRmZmZmXSBB
Q1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwYWZmZTAwMDAt
MHgwMDAwMDAwMGFmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAtMHgwMDAwMDAwMGZl
YzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAw
ZmVlMDAwMDAtMHgwMDAwMDAwMGZlZTAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
dXNlcjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNl
cnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgw
MDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gU01CSU9TIDIuNSBw
cmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBNU0kgTVMtNzY0MC84OTBGWEEtR0Q3MCAo
TVMtNzY0MCkgICwgQklPUyBWMS44QjEgMDkvMTMvMjAxMA0KWyAgICAwLjAwMDAwMF0gZTgy
MDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXSB1c2FibGUgPT0+IHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAwLTB4MDAw
ZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZA0KWyAg
ICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3BmbiA9IDB4
NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTY2FubmluZyAxIGFyZWFzIGZvciBsb3cgbWVt
b3J5IGNvcnJ1cHRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBm
YjEwMCAwMDAxNCAodjAwIEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFQgMDAw
MDAwMDBhZmY5MDAwMCAwMDA0OCAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZU
IDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMGFmZjkwMjAw
IDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAgMDk0MjcgKHYwMSAg
QTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNClsgICAgMC4wMDAwMDBd
IEFDUEk6IEZBQ1MgMDAwMDAwMDBhZmY5ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQ
STogQVBJQyAwMDAwMDAwMGFmZjkwMzkwIDAwMDg4ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIw
MTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAw
MDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNGVCAw
MDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNMSUMgMDAwMDAwMDBhZmY5MDQ2MCAw
MDE3NiAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogT0VNQiAwMDAwMDAwMGFmZjllMDQwIDAwMDcyICh2MDEgNzY0
ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1ZTAgMDAxMDggKHYwMyBBTUQgICAgRkFNX0ZfMTAg
MDAwMDAwMDIgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgMDAw
MDAwMDBhZmY5YTZmMCAwMDAzOCAodjAxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZU
IDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVZSUyAwMDAwMDAwMGFmZjlhNzMw
IDAwMTAwICh2MDEgIEFNRCAgICAgUkQ4OTBTIDAwMjAyMDMxIEFNRCAgMDAwMDAwMDApDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBB
IE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBd
IEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAwXSBC
YXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAwXSA5OTAwMCBzaXpl
IDI0NTc2DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAw
MDAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgw
MDBmZmZmZl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzog
W21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDNm
ZTAwMDAwLTB4M2ZmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBdIEJSSyBbMHgwMjk2
NDAwMCwgMHgwMjk2NGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlf
bWFwcGluZzogW21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAg
W21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBdIEJS
SyBbMHgwMjk2NTAwMCwgMHgwMjk2NWZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gQlJL
IFsweDAyOTY2MDAwLCAweDAyOTY2ZmZmXSBQR1RBQkxFDQpbICAgIDAuMDAwMDAwXSBCUksg
WzB4MDI5NjcwMDAsIDB4MDI5NjdmZmZdIFBHVEFCTEUNClsgICAgMC4wMDAwMDBdIEJSSyBb
MHgwMjk2ODAwMCwgMHgwMjk2OGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0gaW5pdF9t
ZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSAgW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAw
MDBdIFJBTURJU0s6IFttZW0gMHgwMmQ3MDAwMC0weDAzYTFiZmZmXQ0KWyAgICAwLjAwMDAw
MF0gTlVNQSB0dXJuZWQgb2ZmDQpbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2RlIGF0IFtt
ZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0NClsgICAgMC4wMDAw
MDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIFttZW0gMHgwMDAwMDAwMC0weDNmZmZmZmZmXQ0K
WyAgICAwLjAwMDAwMF0gICBOT0RFX0RBVEEgW21lbSAweDNmZTFhMDAwLTB4M2ZlMjRmZmZd
DQpbICAgIDAuMDAwMDAwXSBab25lIHJhbmdlczoNClsgICAgMC4wMDAwMDBdICAgRE1BICAg
ICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIERNQTMy
ICAgIFttZW0gMHgwMTAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBOb3Jt
YWwgICBlbXB0eQ0KWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNo
IG5vZGUNClsgICAgMC4wMDAwMDBdIEVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcw0KWyAgICAw
LjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMDAxMDAwLTB4MDAwOWVmZmZdDQpbICAg
IDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgzZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNjIwNDYNClsgICAgMC4wMDAw
MDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAw
MF0gICBETUEgem9uZTogMjEgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdICAgRE1B
IHpvbmU6IDM5OTggcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAwMDAwMF0gICBETUEz
MiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiB6b25lOiAyNTgwNDggcGFnZXMsIExJRk8gYmF0Y2g6MzENClsgICAgMC4wMDAwMDBd
IEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBM
b2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNClsgICAgMC4wMDAw
MDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQp
DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsw
eDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
NF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElD
IChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
WyAgICAwLjAwMDAwMF0gQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAw
MDBdIGdzaV9iYXNlWzBdKQ0KWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDYs
IHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNClsgICAgMC4wMDAw
MDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFz
ZVsyNF0pDQpbICAgIDAuMDAwMDAwXSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAz
MywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNClsgICAgMC4wMDAwMDBdIEFDUEk6
IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQpb
ICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2Jh
bF9pcnEgOSBsb3cgbGV2ZWwpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkg
b3ZlcnJpZGUuDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUu
DQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQpbICAgIDAu
MDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3Jt
YXRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZl
ZDAwMDAwDQpbICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA2IENQVXMsIDAgaG90
cGx1ZyBDUFVzDQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNzINClsgICAgMC4wMDAw
MDBdIGU4MjA6IFttZW0gMHhiMDAwMDAwMC0weGZlYmZmZmZmXSBhdmFpbGFibGUgZm9yIFBD
SSBkZXZpY2VzDQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu
ZWwgb24gWGVuDQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4zLXVuc3RhYmxlIChw
cmVzZXJ2ZS1BRCkNClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5y
X2NwdW1hc2tfYml0czo4IG5yX2NwdV9pZHM6NiBucl9ub2RlX2lkczoxDQpbICAgIDAuMDAw
MDAwXSBQRVJDUFU6IEVtYmVkZGVkIDI4IHBhZ2VzL2NwdSBAZmZmZjg4MDAzZjgwMDAwMCBz
ODE5ODQgcjgxOTIgZDI0NTEyIHUyNjIxNDQNClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6
IHM4MTk4NCByODE5MiBkMjQ1MTIgdTI2MjE0NCBhbGxvYz0xKjIwOTcxNTINClsgICAgMC4w
MDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIDEgMiAzIDQgNSAtIC0gDQpbICAgIDQuMjQwMTU2
XSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBv
bi4gIFRvdGFsIHBhZ2VzOiAyNTc5MjkNClsgICAgNC4yNDAxNTldIFBvbGljeSB6b25lOiBE
TUEzMg0KWyAgICA0LjI0MDM0NV0gUElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3Jk
ZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KWyAgICA0LjI0MDM1MV0gX19leF90YWJsZSBhbHJlYWR5
IHNvcnRlZCwgc2tpcHBpbmcgc29ydA0KWyAgICA0LjI4MjY5OV0gc29mdHdhcmUgSU8gVExC
IFttZW0gMHgzYTYwMDAwMC0weDNlNjAwMDAwXSAoNjRNQikgbWFwcGVkIGF0IFtmZmZmODgw
MDNhNjAwMDAwLWZmZmY4ODAwM2U1ZmZmZmZdDQpbICAgIDQuMjg3OTE3XSBNZW1vcnk6IDky
MTc4NGsvMTA0ODU3NmsgYXZhaWxhYmxlICgxMDA0N2sga2VybmVsIGNvZGUsIDM5MmsgYWJz
ZW50LCAxMjY0MDBrIHJlc2VydmVkLCA1MjIwayBkYXRhLCAxMDcyayBpbml0KQ0KWyAgICA0
LjI4ODIyMV0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWlu
T2JqZWN0cz0wLCBDUFVzPTYsIE5vZGVzPTENClsgICAgNC4yODgzMzJdIFByZWVtcHRpYmxl
IGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDQuMjg4MzM0XSAJUkNV
IGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQpb
ICAgIDQuMjg4MzM2XSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRlZCB3aXRoIHN0
YWxscy4NClsgICAgNC4yODgzMzhdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQ
VVM9OCB0byBucl9jcHVfaWRzPTYuDQpbICAgIDQuMjg4Mzg0XSBOUl9JUlFTOjQzNTIgbnJf
aXJxczoxMjcyIDE2DQpbICAgIDQuMjg4NTIzXSB4ZW46IHNjaSBvdmVycmlkZTogZ2xvYmFs
X2lycT05IHRyaWdnZXI9MCBwb2xhcml0eT0xDQpbICAgIDQuMjg4NTI2XSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSA5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDQuMjg4NTYwXSB4
ZW46IC0tPiBwaXJxPTkgLT4gaXJxPTkgKGdzaT05KQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6
MTM6NTNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAt
PiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQpbICAgIDQuMjg4NTgzXSB4ZW46IGFjcGkgc2Np
IDkNClsgICAgNC4yODg1OTBdIHhlbjogLS0+IHBpcnE9MSAtPiBpcnE9MSAoZ3NpPTEpDQpb
ICAgIDQuMjg4NTk3XSB4ZW46IC0tPiBwaXJxPTIgLT4gaXJxPTIgKGdzaT0yKQ0KWyAgICA0
LjI4ODYwM10geGVuOiAtLT4gcGlycT0zIC0+IGlycT0zIChnc2k9MykNClsgICAgNC4yODg2
MTBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3NpPTQpDQpbICAgIDQuMjg4NjE2XSB4
ZW46IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQ0KWyAgICA0LjI4ODYyM10geGVuOiAt
LT4gcGlycT02IC0+IGlycT02IChnc2k9NikNClsgICAgNC4yODg2MjldIHhlbjogLS0+IHBp
cnE9NyAtPiBpcnE9NyAoZ3NpPTcpDQpbICAgIDQuMjg4NjM2XSB4ZW46IC0tPiBwaXJxPTgg
LT4gaXJxPTggKGdzaT04KQ0KWyAgICA0LjI4ODY0Ml0geGVuOiAtLT4gcGlycT0xMCAtPiBp
cnE9MTAgKGdzaT0xMCkNClsgICAgNC4yODg2NDldIHhlbjogLS0+IHBpcnE9MTEgLT4gaXJx
PTExIChnc2k9MTEpDQpbICAgIDQuMjg4NjU2XSB4ZW46IC0tPiBwaXJxPTEyIC0+IGlycT0x
MiAoZ3NpPTEyKQ0KWyAgICA0LjI4ODY2Ml0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMg
KGdzaT0xMykNClsgICAgNC4yODg2NjldIHhlbjogLS0+IHBpcnE9MTQgLT4gaXJxPTE0IChn
c2k9MTQpDQpbICAgIDQuMjg4Njc1XSB4ZW46IC0tPiBwaXJxPTE1IC0+IGlycT0xNSAoZ3Np
PTE1KQ0KWyAgICA0LjI4ODc0Nl0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgy
NQ0KWyAgICA0LjI4ODc1MF0gY29uc29sZSBbdHR5MF0gZW5hYmxlZCwgYm9vdGNvbnNvbGUg
ZGlzYWJsZWQNClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNw
dXNldA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1DQpb
ICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9uIDMuOC4wLXJjMC0yMDEzMDIyNSAocm9vdEBz
ZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAj
MSBTTVAgUFJFRU1QVCBNb24gRmViIDI1IDIwOjMyOjQ0IENFVCAyMDEzDQpbICAgIDAuMDAw
MDAwXSBGcmVlaW5nIDlmLTEwMCBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGZyZWVkDQpbICAgIDAu
MDAwMDAwXSAxLTEgbWFwcGluZyBvbiA5Zi0+MTAwDQpbICAgIDAuMDAwMDAwXSAxLTEgbWFw
cGluZyBvbiBhZmY5MC0+MTAwMDAwDQpbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCA5NyBwYWdl
cyBvZiB1bnVzZWQgbWVtb3J5DQpbICAgIDAuMDAwMDAwXSBTZXQgMzI3ODg5IHBhZ2Uocykg
dG8gMS0xIG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIFBvcHVsYXRpbmcgNDAwMDAtNDAwNjEg
cGZuIHJhbmdlOiA5NyBwYWdlcyBhZGRlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogQklPUy1w
cm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZjAwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAw
LTB4MDAwMDAwMDA0MDA2MGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0g
MHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAwMDBhZmY4ZmZmZl0gdW51c2FibGUNClsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYWZmOTAwMDAtMHgwMDAwMDAwMGFmZjlk
ZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYWZm
OWUwMDAtMHgwMDAwMDAwMGFmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBhZmZlMDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4MDAwMDAw
MDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwZmVjMjAwMDAtMHgwMDAwMDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAw
LjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHg0MDAwMDAwMC0weGZmZmZmZmZmZmZmZmZm
ZmVdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBlbmFi
bGVkDQpbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBh
Y3RpdmUNClsgICAgMC4wMDAwMDBdIGU4MjA6IHVzZXItZGVmaW5lZCBwaHlzaWNhbCBSQU0g
bWFwOg0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgw
MDAwMDAwMDAwMDllZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4w
MDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDAzZmZmZmZm
Zl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDA0MDA2MTAw
MC0weDAwMDAwMDAwYWZmOGZmZmZdIHVudXNhYmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBb
bWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0K
WyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwYWZmOWUwMDAtMHgwMDAwMDAw
MGFmZmRmZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAw
MDAwYWZmZTAwMDAtMHgwMDAwMDAwMGFmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSBy
ZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMjAwMDAt
MHgwMDAwMDAwMGZlYzIwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZlZTAwZmZmXSByZXNlcnZlZA0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZm
ZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAx
MDAwMDAwMDAtMHgwMDAwMDAwMjRmZmZmZmZmXSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0g
U01CSU9TIDIuNSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBNU0kgTVMtNzY0MC84
OTBGWEEtR0Q3MCAoTVMtNzY0MCkgICwgQklPUyBWMS44QjEgMDkvMTMvMjAxMA0KWyAgICAw
LjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXSB1c2Fi
bGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAw
MGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRn
ZSBmb3VuZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9h
cmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBTY2FubmluZyAxIGFyZWFz
IGZvciBsb3cgbWVtb3J5IGNvcnJ1cHRpb24NClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAg
MDAwMDAwMDAwMDBmYjEwMCAwMDAxNCAodjAwIEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFD
UEk6IFJTRFQgMDAwMDAwMDBhZmY5MDAwMCAwMDA0OCAodjAxIE1TSSAgICBPRU1TTElDICAy
MDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAw
MDAwMGFmZjkwMjAwIDAwMDg0ICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAg
MDk0MjcgKHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNClsg
ICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDBhZmY5ZTAwMCAwMDA0MA0KWyAgICAw
LjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMGFmZjkwMzkwIDAwMDg4ICh2MDEgNzY0ME1T
IEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAx
MDA5MTMgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNMSUMgMDAwMDAw
MDBhZmY5MDQ2MCAwMDE3NiAodjAxIE1TSSAgICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUIDAw
MDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogT0VNQiAwMDAwMDAwMGFmZjllMDQwIDAw
MDcyICh2MDEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1ZTAgMDAxMDggKHYwMyBBTUQg
ICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkNClsgICAgMC4wMDAwMDBdIEFD
UEk6IEhQRVQgMDAwMDAwMDBhZmY5YTZmMCAwMDAzOCAodjAxIDc2NDBNUyBPRU1IUEVUICAy
MDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSVZSUyAwMDAw
MDAwMGFmZjlhNzMwIDAwMTAwICh2MDEgIEFNRCAgICAgUkQ4OTBTIDAwMjAyMDMxIEFNRCAg
MDAwMDAwMDApDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAwMDAwYWZmOWE4MzAg
MDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsg
ICAgMC4wMDAwMDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAg
IDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk5MDAw
XSA5OTAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5n
OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4
MDAwMDAwMDAtMHgwMDBmZmZmZl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1v
cnlfbWFwcGluZzogW21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAw
XSAgW21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZdIHBhZ2UgNGsNClsgICAgMC4wMDAwMDBd
IEJSSyBbMHgwMjk2NDAwMCwgMHgwMjk2NGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAwMDAwMF0g
aW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdDQpbICAg
IDAuMDAwMDAwXSAgW21lbSAweDNjMDAwMDAwLTB4M2ZkZmZmZmZdIHBhZ2UgNGsNClsgICAg
MC4wMDAwMDBdIEJSSyBbMHgwMjk2NTAwMCwgMHgwMjk2NWZmZl0gUEdUQUJMRQ0KWyAgICAw
LjAwMDAwMF0gQlJLIFsweDAyOTY2MDAwLCAweDAyOTY2ZmZmXSBQR1RBQkxFDQpbICAgIDAu
MDAwMDAwXSBCUksgWzB4MDI5NjcwMDAsIDB4MDI5NjdmZmZdIFBHVEFCTEUNClsgICAgMC4w
MDAwMDBdIEJSSyBbMHgwMjk2ODAwMCwgMHgwMjk2OGZmZl0gUEdUQUJMRQ0KWyAgICAwLjAw
MDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZd
DQpbICAgIDAuMDAwMDAwXSAgW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgNGsN
ClsgICAgMC4wMDAwMDBdIFJBTURJU0s6IFttZW0gMHgwMmQ3MDAwMC0weDAzYTFiZmZmXQ0K
WyAgICAwLjAwMDAwMF0gTlVNQSB0dXJuZWQgb2ZmDQpbICAgIDAuMDAwMDAwXSBGYWtpbmcg
YSBub2RlIGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0N
ClsgICAgMC4wMDAwMDBdIEluaXRtZW0gc2V0dXAgbm9kZSAwIFttZW0gMHgwMDAwMDAwMC0w
eDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBOT0RFX0RBVEEgW21lbSAweDNmZTFhMDAw
LTB4M2ZlMjRmZmZdDQpbICAgIDAuMDAwMDAwXSBab25lIHJhbmdlczoNClsgICAgMC4wMDAw
MDBdICAgRE1BICAgICAgW21lbSAweDAwMDAxMDAwLTB4MDBmZmZmZmZdDQpbICAgIDAuMDAw
MDAwXSAgIERNQTMyICAgIFttZW0gMHgwMTAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjAw
MDAwMF0gICBOb3JtYWwgICBlbXB0eQ0KWyAgICAwLjAwMDAwMF0gTW92YWJsZSB6b25lIHN0
YXJ0IGZvciBlYWNoIG5vZGUNClsgICAgMC4wMDAwMDBdIEVhcmx5IG1lbW9yeSBub2RlIHJh
bmdlcw0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMDAxMDAwLTB4MDAw
OWVmZmZdDQpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHgz
ZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNjIwNDYN
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgWyAgICA3LjM0MTE5NF0gcGNpYmFjayAwMDAwOjA0OjAwLjA6IHJlc3RvcmluZyBjb25m
aWcgc3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwgd3JpdGluZyAweDEwYSkNClsg
ICAgNy4zNDc4MDhdIHBjaWJhY2sgMDAwMDowNDowMC4wOiByZXN0b3JpbmcgY29uZmlnIHNw
YWNlIGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5nIDB4Zjk4ZmUwMDQpDQpbICAg
IDcuMzU0MzYzXSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFj
ZSBhdCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4MTApDQpbICAgIDcuMzYwODMx
XSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBhdCBvZmZz
ZXQgMHg0ICh3YXMgMHgxMDAwMDAsIHdyaXRpbmcgMHgxMDAxMDIpDQpbICAgIDcuMzY3Mzc5
XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAg
ICA3LjM3Mzc3N10geGVuOiAtLT4gcGlycT0zMyAtPiBpcnE9MzMgKGdzaT0zMykNCihYRU4p
IFsyMDEzLTAyLTI1IDIwOjEzOjU2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy05IC0+IDB4YTEgLT4gSVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkNClsgICAgNy40MDQ3
NjhdIHBjaWJhY2sgMDAwMDowNTowMC4wOiBlbmFibGluZyBkZXZpY2UgKDAwMDAgLT4gMDAw
MykNClsgICAgNy40MTEwNzFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMyIHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQpbICAgIDcuNDE3NDQ1XSB4ZW46IC0tPiBwaXJxPTMyIC0+IGlycT0z
MiAoZ3NpPTMyKQ0KKFhFTikgWzIwMTMtMDItMjUgMjA6MTM6NTZdIElPQVBJQ1sxXTogU2V0
IFBDSSByb3V0aW5nIGVudHJ5ICg3LTggLT4gMHhhOSAtPiBJUlEgMzIgTW9kZToxIEFjdGl2
ZToxKQ0KWyAgICA3LjQ0ODExOF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDcgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDENClsgICAgNy40NTQ0NjJdIHhlbjogLS0+IHBpcnE9NDcgLT4gaXJx
PTQ3IChnc2k9NDcpDQooWEVOKSBbMjAxMy0wMi0yNSAyMDoxMzo1Nl0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhiMSAtPiBJUlEgNDcgTW9kZToxIEFj
dGl2ZToxKQ0KWyAgICA3LjY2NDY5MV0gcGNpYmFjayAwMDAwOjA2OjAwLjA6IHJlc3Rvcmlu
ZyBjb25maWcgc3BhY2UgYXQgb2Zmc2V0IDB4M2MgKHdhcyAweDEwMCwgd3JpdGluZyAweDEw
YSkNClsgICAgNy42NzExODNdIHBjaWJhY2sgMDAwMDowNjowMC4wOiByZXN0b3JpbmcgY29u
ZmlnIHNwYWNlIGF0IG9mZnNldCAweDEwICh3YXMgMHg0LCB3cml0aW5nIDB4ZjlhMDAwMDQp
DQpbICAgIDcuNjc3NTk5XSBwY2liYWNrIDAwMDA6MDY6MDAuMDogcmVzdG9yaW5nIGNvbmZp
ZyBzcGFjZSBhdCBvZmZzZXQgMHhjICh3YXMgMHgwLCB3cml0aW5nIDB4MTApDQpbICAgIDcu
NjgzOTMyXSBwY2liYWNrIDAwMDA6MDY6MDAuMDogcmVzdG9yaW5nIGNvbmZpZyBzcGFjZSBh
dCBvZmZzZXQgMHg0ICh3YXMgMHgxMDAwMDAsIHdyaXRpbmcgMHgxMDAxMDYpDQpbICAgIDcu
NjkwNDQ0XSB4ZW4tcGNpYmFjazogYmFja2VuZCBpcyB2cGNpDQpbICAgIDcuNjk2NjUyXSBi
dXM6ICd4ZW4tYmFja2VuZCc6IGFkZCBkcml2ZXIgeGVuLXBjaWJhY2sNClsgICAgNy43MTU3
MjJdIGRldmljZTogJ3hlbiFwcml2Y21kJzogZGV2aWNlX2FkZA0KWyAgICA3LjcyMjA2MV0g
UE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6eGVuIXByaXZjbWQNClsgICAgNy43NjA0Mzhd
IGRldmljZTogJ3B0bXgnOiBkZXZpY2VfYWRkDQpbICAgIDcuNzY2ODIyXSBQTTogQWRkaW5n
IGluZm8gZm9yIE5vIEJ1czpwdG14DQpbICAgIDcuNzk4MTMyXSBkZXZpY2U6ICdodmMwJzog
ZGV2aWNlX2FkZA0KWyAgICA3LjgwNDM0MF0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6
aHZjMA0KWyAgICA3LjgxMDgxNV0gZGV2aWNlOiAnaHZjMSc6IGRldmljZV9hZGQNClsgICAg
Ny44MTcwMDddIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmh2YzENClsgICAgNy44MjM1
MjBdIGRldmljZTogJ2h2YzInOiBkZXZpY2VfYWRkDQpbICAgIDcuODI5NjI3XSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czpodmMyDQpbICAgIDcuODM1OTk3XSBkZXZpY2U6ICdodmMz
JzogZGV2aWNlX2FkZA0KWyAgICA3Ljg0MjA4OV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBC
dXM6aHZjMw0KWyAgICA3Ljg0ODM1MV0gZGV2aWNlOiAnaHZjNCc6IGRldmljZV9hZGQNClsg
ICAgNy44NTQ0NjNdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmh2YzQNClsgICAgNy44
NjA3MzFdIGRldmljZTogJ2h2YzUnOiBkZXZpY2VfYWRkDQpbICAgIDcuODY2NjgyXSBQTTog
QWRkaW5nIGluZm8gZm9yIE5vIEJ1czpodmM1DQpbICAgIDcuODcyOTAwXSBkZXZpY2U6ICdo
dmM2JzogZGV2aWNlX2FkZA0KWyAgICA3Ljg3ODgyM10gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6aHZjNg0KWyAgICA3Ljg4NDk2Ml0gZGV2aWNlOiAnaHZjNyc6IGRldmljZV9hZGQN
ClsgICAgNy44OTA4MDddIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmh2YzcNClsgICAg
Ny44OTY4NzhdIGJ1czogJ3hlbic6IGFkZCBkcml2ZXIgeGVuY29uc29sZQ0KWyAgICA3Ljkx
NDI2NV0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcg
ZW5hYmxlZA0KWyAgICA3LjkyMDA0OV0gYnVzOiAncG5wJzogYWRkIGRyaXZlciBzZXJpYWwN
ClsgICAgNy45MjU3NTJdIGJ1czogJ3BucCc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNo
ZWQgZGV2aWNlIDAwOjA2IHdpdGggZHJpdmVyIHNlcmlhbA0KWyAgICA3LjkzMTQ4OF0gYnVz
OiAncG5wJzogcmVhbGx5X3Byb2JlOiBwcm9iaW5nIGRyaXZlciBzZXJpYWwgd2l0aCBkZXZp
Y2UgMDA6MDYNClsgICAgNy45Mzc0NDRdIGRldmljZTogJ3R0eVMwJzogZGV2aWNlX2FkZA0K
WyAgICA3Ljk0MzUxM10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6dHR5UzANClsgICAg
Ny45NDk3MzhdIGRyaXZlcjogJzAwOjA2JzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZp
Y2UgJ3NlcmlhbCcNClsgICAgNy45NTU1MDJdIGJ1czogJ3BucCc6IHJlYWxseV9wcm9iZTog
Ym91bmQgZGV2aWNlIDAwOjA2IHRvIGRyaXZlciBzZXJpYWwNClsgICAgNy45NjE2MjNdIFJl
Z2lzdGVyaW5nIHBsYXRmb3JtIGRldmljZSAnc2VyaWFsODI1MCcuIFBhcmVudCBhdCBwbGF0
Zm9ybQ0KWyAgICA3Ljk2NzQzNl0gZGV2aWNlOiAnc2VyaWFsODI1MCc6IGRldmljZV9hZGQN
ClsgICAgNy45NzMyNDldIGJ1czogJ3BsYXRmb3JtJzogYWRkIGRldmljZSBzZXJpYWw4MjUw
DQpbICAgIDcuOTc5MTE3XSBQTTogQWRkaW5nIGluZm8gZm9yIHBsYXRmb3JtOnNlcmlhbDgy
NTANClsgICAgNy45ODUyNDhdIGRldmljZTogJ3R0eVMxJzogZGV2aWNlX2FkZA0KWyAgICA3
Ljk5MTIxM10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6dHR5UzENClsgICAgNy45OTc0
MjJdIGRldmljZTogJ3R0eVMyJzogZGV2aWNlX2FkZA0KWyAgICA4LjAwMzI2NV0gUE06IEFk
ZGluZyBpbmZvIGZvciBObyBCdXM6dHR5UzINClsgICAgOC4wMDkzODNdIGRldmljZTogJ3R0
eVMzJzogZGV2aWNlX2FkZA0KWyAgICA4LjAxNTI0M10gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6dHR5UzMNClsgICAgOC4wMjEyODRdIGJ1czogJ3BsYXRmb3JtJzogYWRkIGRyaXZl
ciBzZXJpYWw4MjUwDQpbICAgIDguMDI2ODU0XSBidXM6ICdwbGF0Zm9ybSc6IGRyaXZlcl9w
cm9iZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIHNlcmlhbDgyNTAgd2l0aCBkcml2ZXIgc2Vy
aWFsODI1MA0KWyAgICA4LjAzMjU4Nl0gYnVzOiAncGxhdGZvcm0nOiByZWFsbHlfcHJvYmU6
IHByb2JpbmcgZHJpdmVyIHNlcmlhbDgyNTAgd2l0aCBkZXZpY2Ugc2VyaWFsODI1MA0KWyAg
ICA4LjAzODM2M10gZHJpdmVyOiAnc2VyaWFsODI1MCc6IGRyaXZlcl9ib3VuZDogYm91bmQg
dG8gZGV2aWNlICdzZXJpYWw4MjUwJw0KWyAgICA4LjA0NDE5N10gYnVzOiAncGxhdGZvcm0n
OiByZWFsbHlfcHJvYmU6IGJvdW5kIGRldmljZSBzZXJpYWw4MjUwIHRvIGRyaXZlciBzZXJp
YWw4MjUwDQpbICAgIDguMDYyMTc2XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIHNlcmlhbA0K
WyAgICA4LjA5MTcyNF0gZGV2aWNlOiAnaHBldCc6IGRldmljZV9hZGQNClsgICAgOC4wOTc2
MzRdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmhwZXQNClsgICAgOC4xMDM4MzldIGJ1
czogJ2FjcGknOiBhZGQgZHJpdmVyIGhwZXQNClsgICAgOC4xMDk2MjBdIGJ1czogJ2FjcGkn
OiBkcml2ZXJfcHJvYmVfZGV2aWNlOiBtYXRjaGVkIGRldmljZSBQTlAwMTAzOjAwIHdpdGgg
ZHJpdmVyIGhwZXQNClsgICAgOC4xMTU1MjddIGJ1czogJ2FjcGknOiByZWFsbHlfcHJvYmU6
IHByb2JpbmcgZHJpdmVyIGhwZXQgd2l0aCBkZXZpY2UgUE5QMDEwMzowMA0KWyAgICA4LjEy
MTcyNl0gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9DUlMNClsgICAg
OC4xMjc2MzBdIGhwZXQ6IHByb2JlIG9mIFBOUDAxMDM6MDAgcmVqZWN0cyBtYXRjaCAtMTkN
ClsgICAgOC4xNDU4MTBdIGJ1czogJ3BsYXRmb3JtJzogYWRkIGRyaXZlciB0aW1lcmlvbWVt
X3JuZw0KWyAgICA4LjIwMTMzOV0gTGludXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpb
ICAgIDguMjE5ODI1XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIGFncGdhcnQtYW1kNjQNClsg
ICAgOC4yMjY0NDhdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjMyODU2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDowMC4wDQpbICAgIDguMjM5NTM0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4yNDYwNTddIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MDAuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjUyNzE4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDowMC4yDQpbICAgIDguMjU5NTE3XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjAwLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4yNjYyMjZdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTEuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjczMDA2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMS4wDQpbICAgIDguMjgwMDU0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjExLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4yODY4NThdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTIuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MjkzNzY2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMi4wDQpbICAgIDguMzAwODAyXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEyLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zMDc3NDldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTIuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzE0ODI4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMi4yDQpbICAgIDguMzIxOTg5XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEyLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zMjkwMjJdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTMuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzM2MTg0XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMy4wDQpbICAgIDguMzQzNjA5XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEzLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zNTA4NTldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTMuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzU4MjMyXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxMy4yDQpbICAgIDguMzY1NzQwXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjEzLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zNzMyMzBdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
MzgwODUwXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC4wDQpbICAgIDguMzg4NjIyXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC4zOTYzMTVdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuMSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDA0MTYyXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC4xDQpbICAgIDguNDEyMTE2XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjEgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40MTk5NDddIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuMyB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDI3ODMxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC4zDQpbICAgIDguNDM1Nzg1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjMgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40NDM2MDhdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuNCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDUxNTQzXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC40DQpbICAgIDguNDU5NjIzXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjQgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40Njc1OTJdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTQuNSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NDc1NjU2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNC41DQpbICAgIDguNDgzODkwXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE0LjUgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC40OTIwMjRdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTYuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTAwMzQ4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNi4wDQpbICAgIDguNTA4ODQzXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE2LjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41MTcyODJdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTYuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTI1ODI2XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxNi4yDQpbICAgIDguNTM0NDcxXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE2LjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41NDI5OTNdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTUxNjU4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4wDQpbICAgIDguNTYwNTU1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41NjkyOTldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NTc4MTI5XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4xDQpbICAgIDguNTg3MTU0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjEgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC41OTU5NjhdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NjA0ODk4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4yDQpbICAgIDguNjEzOTU4XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC42MjI5ODFdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguMyB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NjMyMTUyXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC4zDQpbICAgIDguNjQxNTQxXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjMgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC42NTA4MDNdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDA6MTguNCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NjYwMjE5XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowMDoxOC40DQpbICAgIDguNjY5NzU0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjAwOjE4LjQgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC42NzkxOThdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGM6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
Njg4Nzg4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYzowMC4wDQpbICAgIDguNjk4NDg2XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBjOjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43MDgwMjVdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGE6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NzE3NjQwXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYTowMC4wDQpbICAgIDguNzI3MzI0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBhOjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43MzY4NjBdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGI6MDEuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
NzQ2NDcxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYjowMS4wDQpbICAgIDguNzU2MjI2XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBiOjAxLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43NjU3NjVdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGI6MDEuMSB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
Nzc1Mzc1XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYjowMS4xDQpbICAgIDguNzg1MDQ1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBiOjAxLjEgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC43OTQ1ODBdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MGI6MDEuMiB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODA0MTg4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowYjowMS4yDQpbICAgIDguODEzODU1XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjBiOjAxLjIgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC44MjMzODldIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDk6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODMyOTkxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowOTowMC4wDQpbICAgIDguODQyNjY5XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjA5OjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC44NTIyMDFdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDg6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODYxODAxXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowODowMC4wDQpbICAgIDguODcxNDczXSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjA4OjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC44ODEwMDFdIGJ1czogJ3BjaSc6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQg
ZGV2aWNlIDAwMDA6MDc6MDAuMCB3aXRoIGRyaXZlciBhZ3BnYXJ0LWFtZDY0DQpbICAgIDgu
ODkwNTk4XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGFncGdh
cnQtYW1kNjQgd2l0aCBkZXZpY2UgMDAwMDowNzowMC4wDQpbICAgIDguOTAwMjY0XSBhZ3Bn
YXJ0LWFtZDY0OiBwcm9iZSBvZiAwMDAwOjA3OjAwLjAgcmVqZWN0cyBtYXRjaCAtMTkNClsg
ICAgOC45MDk4NDldIGJ1czogJ3BjaSc6IHJlbW92ZSBkcml2ZXIgYWdwZ2FydC1hbWQ2NA0K
WyAgICA4LjkxOTU0Ml0gZHJpdmVyOiAnYWdwZ2FydC1hbWQ2NCc6IGRyaXZlcl9yZWxlYXNl
DQpbICAgIDguOTQ3NjM4XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIGFncGdhcnQtaW50ZWwN
ClsgICAgOC45NzU2NzRdIEhhbmdjaGVjazogc3RhcnRpbmcgaGFuZ2NoZWNrIHRpbWVyIDAu
OS4xICh0aWNrIGlzIDE4MCBzZWNvbmRzLCBtYXJnaW4gaXMgNjAgc2Vjb25kcykuDQpbICAg
IDguOTg0ODkwXSBIYW5nY2hlY2s6IFVzaW5nIGdldHJhd21vbm90b25pYygpLg0KWyAgICA5
LjAxMjIwMl0gZGV2aWNlIGNsYXNzICdkcm0nOiByZWdpc3RlcmluZw0KWyAgICA5LjAyMTQz
OF0gW2RybV0gSW5pdGlhbGl6ZWQgZHJtIDEuMS4wIDIwMDYwODEwDQpbICAgIDkuMDQ4MDgx
XSBkZXZpY2U6ICd0dG0nOiBkZXZpY2VfYWRkDQpbICAgIDkuMDU2ODMxXSBQTTogQWRkaW5n
IGluZm8gZm9yIE5vIEJ1czp0dG0NClsgICAgOS4wODI4NDBdIFtkcm1dIFZHQUNPTiBkaXNh
YmxlIHJhZGVvbiBrZXJuZWwgbW9kZXNldHRpbmcuDQpbICAgIDkuMDkyNDgyXSBwY2liYWNr
IDAwMDA6MDU6MDAuMDogWyAgIDExLjIyMjU1Ml0gYnVzOiAncGNpJzogcmVhbGx5X3Byb2Jl
OiBib3VuZCBkZXZpY2UgMDAwMDowODowMC4wIHRvIGRyaXZlciByODE2OQ0KWyAgIDExLjI0
NDMzNF0gSW5pdGlhbGlzaW5nIFhlbiB2aXJ0dWFsIGV0aGVybmV0IGRyaXZlci4NClsgICAx
MS4yNTE1MzJdIGJ1czogJ3hlbic6IGFkZCBkcml2ZXIgdmlmDQpbICAgMTEuMjc0NDE4XSBi
dXM6ICd4ZW4tYmFja2VuZCc6IGFkZCBkcml2ZXIgdmlmDQpbICAgMTEuMzEwNzQ2XSBkZXZp
Y2UgY2xhc3MgJ3VzYm1vbic6IHJlZ2lzdGVyaW5nDQpbICAgMTEuMzE4NDI0XSBkZXZpY2U6
ICd1c2Jtb24wJzogZGV2aWNlX2FkZA0KWyAgIDExLjMyNTY1M10gUE06IEFkZGluZyBpbmZv
IGZvciBObyBCdXM6dXNibW9uMA0KWyAgIDExLjM0NzI0N10gZWhjaV9oY2Q6IFVTQiAyLjAg
J0VuaGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZlcg0KWyAgIDExLjM2ODUx
NV0gZWhjaS1wY2k6IEVIQ0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KWyAgIDExLjM3NTU2NF0g
YnVzOiAncGNpJzogYWRkIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDExLjM4MjU3OV0gYnVzOiAn
cGNpJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowMDoxMi4y
IHdpdGggZHJpdmVyIGVoY2ktcGNpDQpbICAgMTEuMzg5Njk3XSBidXM6ICdwY2knOiByZWFs
bHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2aWNlIDAwMDA6MDA6
MTIuMg0KWyAgIDExLjM5Njg2N10geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDENClsgICAxMS40MDM5ODBdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTcNClsgICAxMS40MTExMDddIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgYnVz
IG1hc3RlcmluZw0KWyAgIDExLjQxODE5Ml0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBFSENJ
IEhvc3QgQ29udHJvbGxlcg0KWyAgIDExLjQyNTM3Ml0gZGV2aWNlOiAndXNibW9uMSc6IGRl
dmljZV9hZGQNClsgICAxMS40MzI1ODBdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnVz
Ym1vbjENClsgICAxMS40Mzk4NDBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpbICAgMTEuNDQ2ODQ0XSBR
VUlSSzogRW5hYmxlIEFNRCBQTEwgZml4DQpbICAgMTEuNDUzNzUwXSBlaGNpLXBjaSAwMDAw
OjAwOjEyLjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVt
bXkgcWggd29ya2Fyb3VuZA0KWyAgIDExLjQ2MDg1Ml0gZWhjaS1wY2kgMDAwMDowMDoxMi4y
OiBkZWJ1ZyBwb3J0IDENClsgICAxMS40Njc5NDRdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjog
ZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTEuNDc1MDIwXSBlaGNpLXBjaSAwMDAwOjAw
OjEyLjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmY0MDANClsgICAxMS40OTEyOTZdIGVoY2kt
cGNpIDAwMDA6MDA6MTIuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDANClsgICAxMS40
OTg0MDVdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2Yiwg
aWRQcm9kdWN0PTAwMDINClsgICAxMS41MDUxNzZdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmlj
ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDExLjUx
MTk3M10gdXNiIHVzYjE6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgMTEu
NTE4NzI3XSB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAy
MjUgZWhjaV9oY2QNClsgICAxMS41MjU1NjJdIHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAw
MDA6MDA6MTIuMg0KWyAgIDExLjUzMjM1Ml0gZGV2aWNlOiAndXNiMSc6IGRldmljZV9hZGQN
ClsgICAxMS41Mzk0NzVdIGJ1czogJ3VzYic6IGFkZCBkZXZpY2UgdXNiMQ0KWyAgIDExLjU0
NjE3N10gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6dXNiMQ0KWyAgIDExLjU1MzAxOV0gYnVz
OiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgdXNiMSB3aXRo
IGRyaXZlciB1c2INClsgICAxMS41NTk1OTRdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTog
cHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNlIHVzYjENClsgICAxMS41NjYzMTJdIGRl
dmljZTogJzEtMDoxLjAnOiBkZXZpY2VfYWRkDQpbICAgMTEuNTcyODMxXSBidXM6ICd1c2In
OiBhZGQgZGV2aWNlIDEtMDoxLjANClsgICAxMS41NzkyOTddIFBNOiBBZGRpbmcgaW5mbyBm
b3IgdXNiOjEtMDoxLjANClsgICAxMS41ODU5MzhdIGJ1czogJ3VzYic6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDEtMDoxLjAgd2l0aCBkcml2ZXIgaHViDQpbICAg
MTEuNTkyNDEwXSBidXM6ICd1c2InOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGh1
YiB3aXRoIGRldmljZSAxLTA6MS4wDQpbICAgMTEuNTk4OTM0XSBodWIgMS0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KWyAgIDExLjYwNTQxMV0gaHViIDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0
ZWQNClsgICAxMS42MTE5NjBdIGRldmljZTogJ3BvcnQxJzogZGV2aWNlX2FkZA0KWyAgIDEx
LjYxODM5Nl0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDENClsgICAxMS42MjQ2
OTVdIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2FkZA0KWyAgIDExLjYzMDkwM10gUE06IEFk
ZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsgICAxMS42MzcwMjNdIGRldmljZTogJ3Bv
cnQzJzogZGV2aWNlX2FkZA0KWyAgIDExLjY0MzA3M10gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6cG9ydDMNClsgICAxMS42NDkwNDZdIGRldmljZTogJ3BvcnQ0JzogZGV2aWNlX2Fk
ZA0KWyAgIDExLjY1NDkzOF0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDQNClsg
ICAxMS42NjA4MjBdIGRldmljZTogJ3BvcnQ1JzogZGV2aWNlX2FkZA0KWyAgIDExLjY2NjY3
OF0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDUNClsgICAxMS42NzI2MDRdIGRy
aXZlcjogJzEtMDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0K
WyAgIDExLjY3ODQ3OF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
MS0wOjEuMCB0byBkcml2ZXIgaHViDQpbICAgMTEuNjg0NDA2XSBkZXZpY2U6ICdlcF84MSc6
IGRldmljZV9hZGQNClsgICAxMS42OTAzMzJdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVz
OmVwXzgxDQpbICAgMTEuNjk2MTMxXSBkcml2ZXI6ICd1c2IxJzogZHJpdmVyX2JvdW5kOiBi
b3VuZCB0byBkZXZpY2UgJ3VzYicNClsgICAxMS43MDIwMTZdIGJ1czogJ3VzYic6IHJlYWxs
eV9wcm9iZTogYm91bmQgZGV2aWNlIHVzYjEgdG8gZHJpdmVyIHVzYg0KWyAgIDExLjcwNzkz
Ml0gZGV2aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTEuNzEzODYxXSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDExLjcxOTg4Ml0gZHJpdmVyOiAnMDAw
MDowMDoxMi4yJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ2VoY2ktcGNpJw0K
WyAgIDExLjcyNTg5N10gYnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
MDAwMDowMDoxMi4yIHRvIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDExLjczMTkzMV0gYnVzOiAn
cGNpJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowMDoxMy4y
IHdpdGggZHJpdmVyIGVoY2ktcGNpDQpbICAgMTEuNzM4MDAxXSBidXM6ICdwY2knOiByZWFs
bHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2aWNlIDAwMDA6MDA6
MTMuMg0KWyAgIDExLjc0NDE0NV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmlu
ZyAwIHBvbGFyaXR5IDENClsgICAxMS43NTAyMTddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTcNClsgICAxMS43NTY0NjldIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogZW5hYmxpbmcgYnVz
IG1hc3RlcmluZw0KWyAgIDExLjc2MjU4Nl0gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBFSENJ
IEhvc3QgQ29udHJvbGxlcg0KWyAgIDExLjc2ODc2M10gZGV2aWNlOiAndXNibW9uMic6IGRl
dmljZV9hZGQNClsgICAxMS43NzUwMDNdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnVz
Ym1vbjINClsgICAxMS43ODEzODBdIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyDQpbICAgMTEuNzg3NDE1XSBl
aGNpLXBjaSAwMDAwOjAwOjEzLjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24t
Mi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDExLjc5MzUzN10gZWhjaS1wY2kg
MDAwMDowMDoxMy4yOiBkZWJ1ZyBwb3J0IDENClsgICAxMS43OTk2OTRdIGVoY2ktcGNpIDAw
MDA6MDA6MTMuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTEuODA1NzczXSBlaGNp
LXBjaSAwMDAwOjAwOjEzLjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmY4MDANClsgICAxMS44
MjEyOTddIGVoY2ktcGNpIDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEu
MDANClsgICAxMS44Mjc0NzddIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRW
ZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxMS44MzM0NzFdIHVzYiB1c2IyOiBO
ZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9
MQ0KWyAgIDExLjgzOTQ1NF0gdXNiIHVzYjI6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9s
bGVyDQpbICAgMTEuODQ1MzE0XSB1c2IgdXNiMjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjgu
MC1yYzAtMjAxMzAyMjUgZWhjaV9oY2QNClsgICAxMS44NTExODldIHVzYiB1c2IyOiBTZXJp
YWxOdW1iZXI6IDAwMDA6MDA6MTMuMg0KWyAgIDExLjg1NzA4OF0gZGV2aWNlOiAndXNiMic6
IGRldmljZV9hZGQNClsgICAxMS44NjMyNThdIGJ1czogJ3VzYic6IGFkZCBkZXZpY2UgdXNi
Mg0KWyAgIDExLjg2OTIyMF0gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6dXNiMg0KWyAgIDEx
Ljg3NTM3NV0gYnVzOiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZp
Y2UgdXNiMiB3aXRoIGRyaXZlciB1c2INClsgICAxMS44ODEzMjldIGJ1czogJ3VzYic6IHJl
YWxseV9wcm9iZTogcHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNlIHVzYjINClsgICAx
MS44ODcyOTFdIGRldmljZTogJzItMDoxLjAnOiBkZXZpY2VfYWRkDQpbICAgMTEuODkzMjYz
XSBidXM6ICd1c2InOiBhZGQgZGV2aWNlIDItMDoxLjANClsgICAxMS44OTkxMjhdIFBNOiBB
ZGRpbmcgaW5mbyBmb3IgdXNiOjItMDoxLjANClsgICAxMS45MDUzNzldIGJ1czogJ3VzYic6
IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDItMDoxLjAgd2l0aCBkcml2
ZXIgaHViDQpbICAgMTEuOTExNDYzXSBidXM6ICd1c2InOiByZWFsbHlfcHJvYmU6IHByb2Jp
bmcgZHJpdmVyIGh1YiB3aXRoIGRldmljZSAyLTA6MS4wDQpbICAgMTEuOTE3NTQwXSBodWIg
Mi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDExLjkyMzU1Nl0gaHViIDItMDoxLjA6IDUg
cG9ydHMgZGV0ZWN0ZWQNClsgICAxMS45Mjk1MTVdIGRldmljZTogJ3BvcnQxJzogZGV2aWNl
X2FkZA0KWyAgIDExLjkzNTQwOV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDEN
ClsgICAxMS45NDEyNThdIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2FkZA0KWyAgIDExLjk0
NzEzNV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsgICAxMS45NDcxNThd
IGRldmljZTogJ3BvcnQzJzogZGV2aWNlX2FkZA0KWyAgIDExLjk0NzIwN10gUE06IEFkZGlu
ZyBpbmZvIGZvciBObyBCdXM6cG9ydDMNClsgICAxMS45NDcyMjldIGRldmljZTogJ3BvcnQ0
JzogZGV2aWNlX2FkZA0KWyAgIDExLjk0NzMxNV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBC
dXM6cG9ydDQNClsgICAxMS45NDczMzddIGRldmljZTogJ3BvcnQ1JzogZGV2aWNlX2FkZA0K
WyAgIDExLjk0NzM4NV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDUNClsgICAx
MS45NDc0OTZdIGRyaXZlcjogJzItMDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRl
dmljZSAnaHViJw0KWyAgIDExLjk0NzQ5OF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBi
b3VuZCBkZXZpY2UgMi0wOjEuMCB0byBkcml2ZXIgaHViDQpbICAgMTEuOTQ3NTE5XSBkZXZp
Y2U6ICdlcF84MSc6IGRldmljZV9hZGQNClsgICAxMS45NDc2MDldIFBNOiBBZGRpbmcgaW5m
byBmb3IgTm8gQnVzOmVwXzgxDQpbICAgMTEuOTQ3NjExXSBkcml2ZXI6ICd1c2IyJzogZHJp
dmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ3VzYicNClsgICAxMS45NDc2MTNdIGJ1czog
J3VzYic6IHJlYWxseV9wcm9iZTogYm91bmQgZGV2aWNlIHVzYjIgdG8gZHJpdmVyIHVzYg0K
WyAgIDExLjk0NzYzMF0gZGV2aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTEuOTQ3
NzA0XSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDExLjk0Nzc4N10g
ZHJpdmVyOiAnMDAwMDowMDoxMy4yJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2Ug
J2VoY2ktcGNpJw0KWyAgIDExLjk0Nzc5MV0gYnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBi
b3VuZCBkZXZpY2UgMDAwMDowMDoxMy4yIHRvIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDExLjk0
Nzc5OF0gYnVzOiAncGNpJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2Ug
MDAwMDowMDoxNi4yIHdpdGggZHJpdmVyIGVoY2ktcGNpDQpbICAgMTEuOTQ3Nzk4XSBidXM6
ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2
aWNlIDAwMDA6MDA6MTYuMg0KWyAgIDExLjk0Nzg1OF0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAxMS45NDc4NjFdIEFscmVhZHkgc2V0
dXAgdGhlIEdTSSA6MTcNClsgICAxMS45NDc5MDJdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjog
ZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAgIDExLjk0NzkwOV0gZWhjaS1wY2kgMDAwMDow
MDoxNi4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgIDExLjk0Nzk5NV0gZGV2aWNlOiAn
dXNibW9uMyc6IGRldmljZV9hZGQNClsgICAxMS45NDgzMDJdIFBNOiBBZGRpbmcgaW5mbyBm
b3IgTm8gQnVzOnVzYm1vbjMNClsgICAxMS45NDg4NjFdIGVoY2ktcGNpIDAwMDA6MDA6MTYu
MjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQpbICAg
MTEuOTQ4ODc3XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGFwcGx5aW5nIEFNRCBTQjcwMC9T
QjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3VuZA0KWyAgIDExLjk0ODkw
NV0gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBkZWJ1ZyBwb3J0IDENClsgICAxMS45NDkwMjhd
IGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxpbmcgTWVtLVdyLUludmFsDQpbICAgMTEu
OTQ5MDU1XSBlaGNpLXBjaSAwMDAwOjAwOjE2LjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmZj
MDANClsgICAxMi4xNzEzMThdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFy
dGVkLCBFSENJIDEuMDANClsgICAxMi4xNzczMjFdIHVzYiB1c2IzOiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINClsgICAxMi4xODMxNDRd
IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MQ0KWyAgIDEyLjE4ODk1Ml0gdXNiIHVzYjM6IFByb2R1Y3Q6IEVIQ0kg
SG9zdCBDb250cm9sbGVyDQpbICAgMTIuMTk0Njc5XSB1c2IgdXNiMzogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjUgZWhjaV9oY2QNClsgICAxMi4yMDA0MjJdIHVz
YiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMg0KWyAgIDEyLjIwNjIwNl0gZGV2
aWNlOiAndXNiMyc6IGRldmljZV9hZGQNClsgICAxMi4yMTIyNzVdIGJ1czogJ3VzYic6IGFk
ZCBkZXZpY2UgdXNiMw0KWyAgIDEyLjIxODExNV0gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6
dXNiMw0KWyAgIDEyLjIyNDAxMl0gYnVzOiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTog
bWF0Y2hlZCBkZXZpY2UgdXNiMyB3aXRoIGRyaXZlciB1c2INClsgICAxMi4yMjk4MTddIGJ1
czogJ3VzYic6IHJlYWxseV9wcm9iZTogcHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNl
IHVzYjMNClsgICAxMi4yMzU2ODhdIGRldmljZTogJzMtMDoxLjAnOiBkZXZpY2VfYWRkDQpb
ICAgMTIuMjQxNDkwXSBidXM6ICd1c2InOiBhZGQgZGV2aWNlIDMtMDoxLjANClsgICAxMi4y
NDcyNjddIFBNOiBBZGRpbmcgaW5mbyBmb3IgdXNiOjMtMDoxLjANClsgICAxMi4yNTMyMzdd
IGJ1czogJ3VzYic6IGRyaXZlcl9wcm9iZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDMtMDox
LjAgd2l0aCBkcml2ZXIgaHViDQpbICAgMTIuMjU5MTEzXSBidXM6ICd1c2InOiByZWFsbHlf
cHJvYmU6IHByb2JpbmcgZHJpdmVyIGh1YiB3aXRoIGRldmljZSAzLTA6MS4wDQpbICAgMTIu
MjY1MDc3XSBodWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgIDEyLjI3MDk1OF0gaHVi
IDMtMDoxLjA6IDQgcG9ydHMgZGV0ZWN0ZWQNClsgICAxMi4yNzY4MjNdIGRldmljZTogJ3Bv
cnQxJzogZGV2aWNlX2FkZA0KWyAgIDEyLjI4MjU3NV0gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6cG9ydDENClsgICAxMi4yODgzMTldIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2Fk
ZA0KWyAgIDEyLjI5NDEwN10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsg
ICAxMi4yOTk3ODBdIGRldmljZTogJ3BvcnQzJzogZGV2aWNlX2FkZA0KWyAgIDEyLjMwNTQ2
MV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDMNClsgICAxMi4zMTEwNDJdIGRl
dmljZTogJ3BvcnQ0JzogZGV2aWNlX2FkZA0KWyAgIDEyLjMxNjY4MV0gUE06IEFkZGluZyBp
bmZvIGZvciBObyBCdXM6cG9ydDQNClsgICAxMi4zMjIzOTldIGRyaXZlcjogJzMtMDoxLjAn
OiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0KWyAgIDEyLjMyODA5OF0g
YnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMy0wOjEuMCB0byBkcml2
ZXIgaHViDQpbICAgMTIuMzMzODU1XSBkZXZpY2U6ICdlcF84MSc6IGRldmljZV9hZGQNClsg
ICAxMi4zMzk2OTBdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmVwXzgxDQpbICAgMTIu
MzQ1NDI2XSBkcml2ZXI6ICd1c2IzJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2Ug
J3VzYicNClsgICAxMi4zNTEyNTVdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTogYm91bmQg
ZGV2aWNlIHVzYjMgdG8gZHJpdmVyIHVzYg0KWyAgIDEyLjM1NzEzOV0gZGV2aWNlOiAnZXBf
MDAnOiBkZXZpY2VfYWRkDQpbICAgMTIuMzYzMDYwXSBQTTogQWRkaW5nIGluZm8gZm9yIE5v
IEJ1czplcF8wMA0KWyAgIDEyLjM2OTAyOV0gZHJpdmVyOiAnMDAwMDowMDoxNi4yJzogZHJp
dmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ2VoY2ktcGNpJw0KWyAgIDEyLjM3NTA0Ml0g
YnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMDAwMDowMDoxNi4yIHRv
IGRyaXZlciBlaGNpLXBjaQ0KWyAgIDEyLjM4MTA3MF0gYnVzOiAncGNpJzogZHJpdmVyX3By
b2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowYjowMS4yIHdpdGggZHJpdmVyIGVo
Y2ktcGNpDQpbICAgMTIuMzg3MTQzXSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IHByb2Jp
bmcgZHJpdmVyIGVoY2ktcGNpIHdpdGggZGV2aWNlIDAwMDA6MGI6MDEuMg0KWyAgIDEyLjM5
MzI2Nl0geGVuOiByZWdpc3RlcmluZyBnc2kgMzEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
ClsgICAxMi4zOTkzOTFdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzENClsgICAxMi40MDU1
MjJdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KWyAg
IDEyLjQxMTYyMl0gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBFSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgIDEyLjQxNzc3NF0gZGV2aWNlOiAndXNibW9uNCc6IGRldmljZV9hZGQNClsgICAx
Mi40MjQwMDJdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnVzYm1vbjQNClsgICAxMi40
MzAyMzFdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwg
YXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgMTIuNDM2NTU5XSBlaGNpLXBjaSAwMDAwOjBi
OjAxLjI6IGlycSAzMSwgaW8gbWVtIDB4ZjlmZmZjMDANClsgICAxMi40NTEyNjldIGVoY2kt
cGNpIDAwMDA6MGI6MDEuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDANClsgICAxMi40
NTczNzldIHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2Yiwg
aWRQcm9kdWN0PTAwMDINClsgICAxMi40NjMzMzFdIHVzYiB1c2I0OiBOZXcgVVNCIGRldmlj
ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgIDEyLjQ2
OTI1NF0gdXNiIHVzYjQ6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgMTIu
NDc1MTU2XSB1c2IgdXNiNDogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAy
MjUgZWhjaV9oY2QNClsgICAxMi40ODExNzJdIHVzYiB1c2I0OiBTZXJpYWxOdW1iZXI6IDAw
MDA6MGI6MDEuMg0KWyAgIDEyLjQ4NzEyNF0gZGV2aWNlOiAndXNiNCc6IGRldmljZV9hZGQN
ClsgICAxMi40OTMzNzNdIGJ1czogJ3VzYic6IGFkZCBkZXZpY2UgdXNiNA0KWyAgIDEyLjQ5
OTMwMV0gUE06IEFkZGluZyBpbmZvIGZvciB1c2I6dXNiNA0KWyAgIDEyLjUwNTM0NV0gYnVz
OiAndXNiJzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgdXNiNCB3aXRo
IGRyaXZlciB1c2INClsgICAxMi41MTEyNDddIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTog
cHJvYmluZyBkcml2ZXIgdXNiIHdpdGggZGV2aWNlIHVzYjQNClsgICAxMi41MTcyNzVdIGRl
dmljZTogJzQtMDoxLjAnOiBkZXZpY2VfYWRkDQpbICAgMTIuNTIzMjc5XSBidXM6ICd1c2In
OiBhZGQgZGV2aWNlIDQtMDoxLjANClsgICAxMi41MjkyNjVdIFBNOiBBZGRpbmcgaW5mbyBm
b3IgdXNiOjQtMDoxLjANClsgICAxMi41MzU0NzddIGJ1czogJ3VzYic6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDQtMDoxLjAgd2l0aCBkcml2ZXIgaHViDQpbICAg
MTIuNTQxNTg0XSBidXM6ICd1c2InOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVyIGh1
YiB3aXRoIGRldmljZSA0LTA6MS4wDQpbICAgMTIuNTQ3NjM0XSBodWIgNC0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KWyAgIDEyLjU1MzYyMV0gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0
ZWQNClsgICAxMi41NTk2MTddIGRldmljZTogJ3BvcnQxJzogZGV2aWNlX2FkZA0KWyAgIDEy
LjU2NTUyNV0gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDENClsgICAxMi41NzE0
NzRdIGRldmljZTogJ3BvcnQyJzogZGV2aWNlX2FkZA0KWyAgIDEyLjU3NzQzNl0gUE06IEFk
ZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDINClsgICAxMi41ODMzMDhdIGRldmljZTogJ3Bv
cnQzJzogZGV2aWNlX2FkZA0KWyAgIDEyLjU4OTIwNV0gUE06IEFkZGluZyBpbmZvIGZvciBO
byBCdXM6cG9ydDMNClsgICAxMi41OTUwMTddIGRldmljZTogJ3BvcnQ0JzogZGV2aWNlX2Fk
ZA0KWyAgIDEyLjYwMDg3N10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDQNClsg
ICAxMi42MDY2ODBdIGRldmljZTogJ3BvcnQ1JzogZGV2aWNlX2FkZA0KWyAgIDEyLjYxMjQz
N10gUE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6cG9ydDUNClsgICAxMi42MTgyNTRdIGRy
aXZlcjogJzQtMDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0K
WyAgIDEyLjYyMzk3MF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
NC0wOjEuMCB0byBkcml2ZXIgaHViDQpbICAgMTIuNjI5ODE0XSBkZXZpY2U6ICdlcF84MSc6
IGRldmljZV9hZGQNClsgICAxMi42MzU2ODFdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVz
OmVwXzgxDQpbICAgMTIuNjQxNDc4XSBkcml2ZXI6ICd1c2I0JzogZHJpdmVyX2JvdW5kOiBi
b3VuZCB0byBkZXZpY2UgJ3VzYicNClsgICAxMi42NDczNzFdIGJ1czogJ3VzYic6IHJlYWxs
eV9wcm9iZTogYm91bmQgZGV2aWNlIHVzYjQgdG8gZHJpdmVyIHVzYg0KWyAgIDEyLjY1MzMw
M10gZGV2aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTIuNjU5MzAwXSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDEyLjY2NTI4Nl0gZHJpdmVyOiAnMDAw
MDowYjowMS4yJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ2VoY2ktcGNpJw0K
WyAgIDEyLjY3MTMwN10gYnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2Ug
MDAwMDowYjowMS4yIHRvIGRyaXZlciBlaGNpLXBjaQ0KWyAgIDEyLjY5MDAwOF0gb2hjaV9o
Y2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdlsgICAxNC4w
MDgwOTVdIGRldmljZTogJ3VzYm1vbjEyJzogZGV2aWNlX2FkZA0KWyAgIDE0LjAwODQwMl0g
UE06IEFkZGluZyBpbmZvIGZvciBObyBCdXM6dXNibW9uMTINClsgICAxNC4wMDg4ODVdIHho
Y2lfaGNkIDAwMDA6MDc6MDAuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQg
YnVzIG51bWJlciAxMg0KWyAgIDE0LjAwOTI5Nl0gdXNiIHVzYjEyOiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDMNClsgICAxNC4wMDkyOTdd
IHVzYiB1c2IxMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9Miwg
U2VyaWFsTnVtYmVyPTENClsgICAxNC4wMDkyOThdIHVzYiB1c2IxMjogUHJvZHVjdDogeEhD
SSBIb3N0IENvbnRyb2xsZXINClsgICAxNC4wMDkyOTldIHVzYiB1c2IxMjogTWFudWZhY3R1
cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjUgeGhjaV9oY2QNClsgICAxNC4wMDkzMDBd
IHVzYiB1c2IxMjogU2VyaWFsTnVtYmVyOiAwMDAwOjA3OjAwLjANClsgICAxNC4wMDkzMDld
IGRldmljZTogJ3VzYjEyJzogZGV2aWNlX2FkZA0KWyAgIDE0LjAwOTYwOV0gYnVzOiAndXNi
JzogYWRkIGRldmljZSB1c2IxMg0KWyAgIDE0LjAwOTY4M10gUE06IEFkZGluZyBpbmZvIGZv
ciB1c2I6dXNiMTINClsgICAxNC4wMTAxNTVdIGJ1czogJ3VzYic6IGRyaXZlcl9wcm9iZV9k
ZXZpY2U6IG1hdGNoZWQgZGV2aWNlIHVzYjEyIHdpdGggZHJpdmVyIHVzYg0KWyAgIDE0LjAx
MDE2MF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBwcm9iaW5nIGRyaXZlciB1c2Igd2l0
aCBkZXZpY2UgdXNiMTINClsgICAxNC4wMTAzMTVdIHhIQ0kgeGhjaV9hZGRfZW5kcG9pbnQg
Y2FsbGVkIGZvciByb290IGh1Yg0KWyAgIDE0LjAxMDMxOF0geEhDSSB4aGNpX2NoZWNrX2Jh
bmR3aWR0aCBjYWxsZWQgZm9yIHJvb3QgaHViDQpbICAgMTQuMDEwMzk1XSBkZXZpY2U6ICcx
Mi0wOjEuMCc6IGRldmljZV9hZGQNClsgICAxNC4wMTA0NzVdIGJ1czogJ3VzYic6IGFkZCBk
ZXZpY2UgMTItMDoxLjANClsgICAxNC4wMTA1MzBdIFBNOiBBZGRpbmcgaW5mbyBmb3IgdXNi
OjEyLTA6MS4wDQpbICAgMTQuMDExMDM0XSBidXM6ICd1c2InOiBkcml2ZXJfcHJvYmVfZGV2
aWNlOiBtYXRjaGVkIGRldmljZSAxMi0wOjEuMCB3aXRoIGRyaXZlciBodWINClsgICAxNC4w
MTEwMzhdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTogcHJvYmluZyBkcml2ZXIgaHViIHdp
dGggZGV2aWNlIDEyLTA6MS4wDQpbICAgMTQuMDExMjE4XSBodWIgMTItMDoxLjA6IFVTQiBo
dWIgZm91bmQNClsgICAxNC4wMTEyNzRdIGh1YiAxMi0wOjEuMDogMiBwb3J0cyBkZXRlY3Rl
ZA0KWyAgIDE0LjAxMTM2NV0gZGV2aWNlOiAncG9ydDEnOiBkZXZpY2VfYWRkDQpbICAgMTQu
MDExNDIwXSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czpwb3J0MQ0KWyAgIDE0LjAxMTQ0
NV0gZGV2aWNlOiAncG9ydDInOiBkZXZpY2VfYWRkDQpbICAgMTQuMDExNDk3XSBQTTogQWRk
aW5nIGluZm8gZm9yIE5vIEJ1czpwb3J0Mg0KWyAgIDE0LjAxMTU2OF0gZHJpdmVyOiAnMTIt
MDoxLjAnOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAnaHViJw0KWyAgIDE0LjAx
MTU3MF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMTItMDoxLjAg
dG8gZHJpdmVyIGh1Yg0KWyAgIDE0LjAxMTU5MF0gZGV2aWNlOiAnZXBfODEnOiBkZXZpY2Vf
YWRkDQpbICAgMTQuMDExNjczXSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czplcF84MQ0K
WyAgIDE0LjAxMTY3Nl0gZHJpdmVyOiAndXNiMTInOiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRv
IGRldmljZSAndXNiJw0KWyAgIDE0LjAxMTY3N10gYnVzOiAndXNiJzogcmVhbGx5X3Byb2Jl
OiBib3VuZCBkZXZpY2UgdXNiMTIgdG8gZHJpdmVyIHVzYg0KWyAgIDE0LjAxMTY5N10gZGV2
aWNlOiAnZXBfMDAnOiBkZXZpY2VfYWRkDQpbICAgMTQuMDExNzY1XSBQTTogQWRkaW5nIGlu
Zm8gZm9yIE5vIEJ1czplcF8wMA0KWyAgIDE1LjAyMTU4M10gYnVzOiAndXNiJzogZHJpdmVy
X3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgNS01IHdpdGggZHJpdmVyIHVzYg0KWyAg
IDE1LjAyNzQwOF0gYnVzOiAndXNiJzogcmVhbGx5X3Byb2JlOiBwcm9iaW5nIGRyaXZlciB1
c2Igd2l0aCBkZXZpY2UgNS01DQpbICAgMTUuMDM1Mjc5XSBkZXZpY2U6ICc1LTU6MS4wJzog
ZGV2aWNlX2FkZA0KWyAgIDE1LjAzNTM3M10gZHJpdmVyOiAnMDAwMDowNzowMC4wJzogZHJp
dmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ3hoY2lfaGNkJw0KWyAgIDE1LjAzNTM3Nl0g
YnVzOiAncGNpJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgMDAwMDowNzowMC4wIHRv
IGRyaXZlciB4aGNpX2hjZA0KWyAgIDE1LjAzNjAxMV0gYnVzOiAndXNiJzogYWRkIGRyaXZl
ciB1c2JscA0KWyAgIDE1LjAzNjMwOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciB1c2JscA0KWyAgIDE1LjAzNjMxM10gSW5pdGlhbGl6aW5nIFVTQiBNYXNz
IFN0b3JhZ2UgZHJpdmVyLi4uDQpbICAgMTUuMDM2MzE1XSBidXM6ICd1c2InOiBhZGQgZHJp
dmVyIHVzYi1zdG9yYWdlDQpbICAgMTUuMDM2Nzg3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQpbICAgMTUuMDM2Nzg4XSBVU0IgTWFz
cyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4NClsgICAxNS4wMzcwMjhdIGJ1czogJ3Vz
Yi1zZXJpYWwnOiByZWdpc3RlcmVkDQpbICAgMTUuMDM3MDQ5XSBidXM6ICd1c2InOiBhZGQg
ZHJpdmVyIHVzYnNlcmlhbA0KWyAgIDE1LjAzNzI4MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JzZXJpYWwNClsgICAxNS4wMzcyOTNdIGJ1czogJ3Vz
Yic6IGFkZCBkcml2ZXIgY3AyMTB4DQpbICAgMTUuMDM3NTI4XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNwMjEweA0KWyAgIDE1LjAzNzU2MV0gYnVzOiAn
dXNiLXNlcmlhbCc6IGFkZCBkcml2ZXIgY3AyMTB4DQpbICAgMTUuMDM4MTM4XSB1c2JzZXJp
YWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBjcDIxMHgNClsgICAxNS4w
MzgxNjhdIGJ1czogJ3VzYic6IGFkZCBkcml2ZXIgY3lwcmVzc19tOA0KWyAgIDE1LjAzODYx
NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjeXByZXNzX204
DQpbICAgMTUuMDM4NjE3XSBidXM6ICd1c2Itc2VyaWFsJzogYWRkIGRyaXZlciBlYXJ0aG1h
dGUNClsgICAxNS4wMzg4MjBdIHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lz
dGVyZWQgZm9yIERlTG9ybWUgRWFydGhtYXRlIFVTQg0KWyAgIDE1LjAzODgyMl0gYnVzOiAn
dXNiLXNlcmlhbCc6IGFkZCBkcml2ZXIgY3lwaGlkY29tDQpbICAgMTUuMDM5MDQzXSB1c2Jz
ZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBISUQtPkNPTSBSUzIz
MiBBZGFwdGVyDQpbICAgMTUuMDM5MDQ2XSBidXM6ICd1c2Itc2VyaWFsJzogYWRkIGRyaXZl
ciBub2tpYWNhNDJ2Mg0KWyAgIDE1LjAzOTI2OF0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcg0KWyAgIDE1LjAz
OTI4N10gYnVzOiAndXNiJzogYWRkIGRyaXZlciBtb3M3NzIwDQpbICAgMTUuMDM5NTE3XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjANClsgICAx
NS4wMzk1MjBdIGJ1czogJ3VzYi1zZXJpYWwnOiBhZGQgZHJpdmVyIG1vc2NoaXA3NzIwDQpb
ICAgMTUuMDM5NzQzXSB1c2JzZXJpYWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVk
IGZvciBNb3NjaGlwIDIgcG9ydCBhZGFwdGVyDQpbICAgMTUuMDM5NzYzXSBidXM6ICd1c2In
OiBhZGQgZHJpdmVyIG1vczc4NDANClsgICAxNS4wMzk5OTNdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgbW9zNzg0MA0KWyAgIDE1LjAzOTk5Nl0gYnVzOiAn
dXNiLXNlcmlhbCc6IGFkZCBkcml2ZXIgbW9zNzg0MA0KWyAgIDE1LjA0MDI0MV0gdXNic2Vy
aWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4
MjAgVVNCIFNlcmlhbCBEcml2ZXINClsgICAxNS4wNDAyNjBdIGJ1czogJ3BucCc6IGFkZCBk
cml2ZXIgaTgwNDIga2JkDQpbICAgMTUuMDQwNjY4XSBidXM6ICdwbnAnOiBhZGQgZHJpdmVy
IGk4MDQyIGF1eA0KWyAgIDE1LjA0MDg3Ml0gYnVzOiAncG5wJzogcmVtb3ZlIGRyaXZlciBp
ODA0MiBrYmQNClsgICAxNS4wNDEwMjddIGRyaXZlcjogJ2k4MDQyIGtiZCc6IGRyaXZlcl9y
ZWxlYXNlDQpbICAgMTUuMDQxMDM4XSBidXM6ICdwbnAnOiByZW1vdmUgZHJpdmVyIGk4MDQy
IGF1eA0KWyAgIDE1LjA0MTI2MF0gZHJpdmVyOiAnaTgwNDIgYXV4JzogZHJpdmVyX3JlbGVh
c2UNClsgICAxNS4wNDEyNjRdIGk4MDQyOiBQTlA6IE5vIFBTLzIgY29udHJvbGxlciBmb3Vu
ZC4gUHJvYmluZyBwb3J0cyBkaXJlY3RseS4NClsgICAxNS4wNDEzMTldIFJlZ2lzdGVyaW5n
IHBsYXRmb3JtIGRldmljZSAnaTgwNDInLiBQYXJlbnQgYXQgcGxhdGZvcm0NClsgICAxNS4w
NDEzMjNdIGRldmljZTogJ2k4MDQyJzogZGV2aWNlX2FkZA0KWyAgIDE1LjA0MTM0M10gYnVz
OiAncGxhdGZvcm0nOiBhZGQgZGV2aWNlIGk4MDQyDQpbICAgMTUuMDQxMzc1XSBQTTogQWRk
aW5nIGluZm8gZm9yIHBsYXRmb3JtOmk4MDQyDQpbICAgMTUuMDQxODA0XSBidXM6ICdwbGF0
Zm9ybSc6IGFkZCBkcml2ZXIgaTgwNDINClsgICAxNS4wNDE4MjhdIGJ1czogJ3BsYXRmb3Jt
JzogZHJpdmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgaTgwNDIgd2l0aCBkcml2
ZXIgaTgwNDINClsgICAxNS4wNDE4MjhdIGJ1czogJ3BsYXRmb3JtJzogcmVhbGx5X3Byb2Jl
OiBwcm9iaW5nIGRyaXZlciBpODA0MiB3aXRoIGRldmljZSBpODA0Mg0KWyAgIDE1LjA0MjUy
OV0gc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQ0KWyAgIDE1LjA0
MjY0N10gZGV2aWNlOiAnc2VyaW8wJzogZGV2aWNlX2FkZA0KWyAgIDE1LjA0MjcxM10gYnVz
OiAnc2VyaW8nOiBhZGQgZGV2aWNlIHNlcmlvMA0KWyAgIDE1LjA0Mjc2N10gUE06IEFkZGlu
ZyBpbmZvIGZvciBzZXJpbzpzZXJpbzANClsgICAxNS4wNDI4NDBdIHNlcmlvOiBpODA0MiBB
VVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpbICAgMTUuMDQyODU3XSBkcml2ZXI6ICdp
ODA0Mic6IGRyaXZlcl9ib3VuZDogYm91bmQgdG8gZGV2aWNlICdpODA0MicNClsgICAxNS4w
NDI4NTldIGJ1czogJ3BsYXRmb3JtJzogcmVhbGx5X3Byb2JlOiBib3VuZCBkZXZpY2UgaTgw
NDIgdG8gZHJpdmVyIGk4MDQyDQpbICAgMTUuMDQzMDY3XSBkZXZpY2U6ICdzZXJpbzEnOiBk
ZXZpY2VfYWRkDQpbICAgMTUuMDQzMTE5XSBidXM6ICdzZXJpbyc6IGFkZCBkZXZpY2Ugc2Vy
aW8xDQpbICAgMTUuMDQzMTg0XSBQTTogQWRkaW5nIGluZm8gZm9yIHNlcmlvOnNlcmlvMQ0K
WyAgIDE1LjA0MzMxOV0gZGV2aWNlOiAnbWljZSc6IGRldmljZV9hZGQNClsgICAxNS4wNDM1
NDddIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOm1pY2UNClsgICAxNS4wNDQwMjNdIG1v
dXNlZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlDQpbICAgMTUu
MDQ0MDg2XSBkZXZpY2U6ICdldmVudDAnOiBkZXZpY2VfYWRkDQpbICAgMTUuMDQ0NDI1XSBQ
TTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czpldmVudDANClsgICAxNS4wNDQ3NjJdIGRldmlj
ZTogJ2V2ZW50MSc6IGRldmljZV9hZGQNClsgICAxNS4wNDQ5MjJdIFBNOiBBZGRpbmcgaW5m
byBmb3IgTm8gQnVzOmV2ZW50MQ0KWyAgIDE1LjA0NTM1M10gYnVzOiAnc2VyaW8nOiBhZGQg
ZHJpdmVyIGF0a2JkDQpbICAgMTUuMDQ1NjE0XSBidXM6ICdzZXJpbyc6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIHNlcmlvMCB3aXRoIGRyaXZlciBhdGtiZA0KWyAg
IDE1LjA0NTYxNV0gYnVzOiAnc2VyaW8nOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVy
IGF0a2JkIHdpdGggZGV2aWNlIHNlcmlvMA0KWyAgIDE1LjA0NTcxNV0gYnVzOiAnc2VyaW8n
OiBhZGQgZHJpdmVyIHBzbW91c2UNClsgICAxNS4wNDYwNjFdIGJ1czogJ3BucCc6IGFkZCBk
cml2ZXIgcnRjX2Ntb3MNClsgICAxNS4wNDYwODVdIGJ1czogJ3BucCc6IGRyaXZlcl9wcm9i
ZV9kZXZpY2U6IG1hdGNoZWQgZGV2aWNlIDAwOjAzIHdpdGggZHJpdmVyIHJ0Y19jbW9zDQpb
ICAgMTUuMDQ2MDg2XSBidXM6ICdwbnAnOiByZWFsbHlfcHJvYmU6IHByb2JpbmcgZHJpdmVy
IHJ0Y19jbW9zIHdpdGggZGV2aWNlIDAwOjAzDQpbICAgMTUuMDQ2MTM3XSBydGNfY21vcyAw
MDowMzogUlRDIGNhbiB3YWtlIGZyb20gUzQNClsgICAxNS4wNDY0OTFdIGRldmljZTogJ3J0
YzAnOiBkZXZpY2VfYWRkDQpbICAgMTUuMDQ2NzYzXSBQTTogQWRkaW5nIGluZm8gZm9yIE5v
IEJ1czpydGMwDQpbICAgMTUuMDQ3NDY5XSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJl
Z2lzdGVyZWQgcnRjX2Ntb3MgYXMgcnRjMA0KWyAgIDE1LjA0NzU4MF0gcnRjX2Ntb3MgMDA6
MDM6IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAg
MTUuMDQ3NTgxXSBkcml2ZXI6ICcwMDowMyc6IGRyaXZlcl9ib3VuZDogYm91bmQgdG8gZGV2
aWNlICdydGNfY21vcycNClsgICAxNS4wNDc1ODRdIGJ1czogJ3BucCc6IHJlYWxseV9wcm9i
ZTogYm91bmQgZGV2aWNlIDAwOjAzIHRvIGRyaXZlciBydGNfY21vcw0KWyAgIDE1LjA0Nzkx
M10gYnVzOiAnYWNwaSc6IGFkZCBkcml2ZXIgY21pDQpbICAgMTUuMDQ4MTYyXSBidXM6ICdw
Y2knOiBhZGQgZHJpdmVyIGFtZDc1Nl9zbWJ1cw0KWyAgIDE1LjA0ODU4OF0gYnVzOiAncGNp
JzogYWRkIGRyaXZlciBhbWQ4MTExX3NtYnVzMg0KWyAgIDE1LjA0ODgyM10gYnVzOiAncGNp
JzogYWRkIGRyaXZlciBpODAxX3NtYnVzDQpbICAgMTUuMDQ5MzAyXSBidXM6ICdwbGF0Zm9y
bSc6IGFkZCBkcml2ZXIgaXNjaF9zbWJ1cw0KWyAgIDE1LjA0OTQ5OF0gYnVzOiAncGNpJzog
YWRkIGRyaXZlciBwaWl4NF9zbWJ1cw0KWyAgIDE1LjA0OTUyM10gYnVzOiAncGNpJzogZHJp
dmVyX3Byb2JlX2RldmljZTogbWF0Y2hlZCBkZXZpY2UgMDAwMDowMDoxNC4wIHdpdGggZHJp
dmVyIHBpaXg0X3NtYnVzDQpbICAgMTUuMDQ5NTIzXSBidXM6ICdwY2knOiByZWFsbHlfcHJv
YmU6IHByb2JpbmcgZHJpdmVyIHBpaXg0X3NtYnVzIHdpdGggZGV2aWNlIDAwMDA6MDA6MTQu
MA0KWyAgIDE1LjA0OTU5NV0gQUNQSSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDBiMDAtMHgw
MDAwMDAwMDAwMDAwYjA3IFN5c3RlbUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcU09SMSAx
ICgyMDEzMDExNy91dGFkZHJlc3MtMjUxKQ0KWyAgIDE1LjA0OTU5OF0gQUNQSTogVGhpcyBj
b25mbGljdCBtYXkgY2F1c2UgcmFuZG9tIHByb2JsZW1zIGFuZCBzeXN0ZW0gaW5zdGFiaWxp
dHkNClsgICAxNS4wNDk1OTldIEFDUEk6IElmIGFuIEFDUEkgZHJpdmVyIGlzIGF2YWlsYWJs
ZSBmb3IgdGhpcyBkZXZpY2UsIHlvdSBzaG91bGQgdXNlIGl0IGluc3RlYWQgb2YgdGhlIG5h
dGl2ZSBkcml2ZXINClsgICAxNS4wNDk2MTNdIHBpaXg0X3NtYnVzIDAwMDA6MDA6MTQuMDog
U01CdXMgSG9zdCBDb250cm9sbGVyIGF0IDB4YjAwLCByZXZpc2lvbiAwDQpbICAgMTUuMDQ5
NzIwXSBkZXZpY2U6ICdpMmMtMCc6IGRldmljZV9hZGQNClsgICAxNS4wNDk3NjRdIGJ1czog
J2kyYyc6IGFkZCBkZXZpY2UgaTJjLTANClsgICAxNS4wNDk3OTldIFBNOiBBZGRpbmcgaW5m
byBmb3IgaTJjOmkyYy0wDQpbICAgMTUuMDUwMjc2XSBkcml2ZXI6ICcwMDAwOjAwOjE0LjAn
OiBkcml2ZXJfYm91bmQ6IGJvdW5kIHRvIGRldmljZSAncGlpeDRfc21idXMnDQpbICAgMTUu
MDUwMjg5XSBidXM6ICdwY2knOiByZWFsbHlfcHJvYmU6IGJvdW5kIGRldmljZSAwMDAwOjAw
OjE0LjAgdG8gZHJpdmVyIHBpaXg0X3NtYnVzDQpbICAgMTUuMDUwODY2XSBidXM6ICdpMmMn
OiBhZGQgZHJpdmVyIG1zcDM0MDANClsgICAxNS4wNTEzMjhdIGJ1czogJ2kyYyc6IGFkZCBk
cml2ZXIgY3gyNTg0MA0KWyAgIDE1LjA1MTU0Nl0gYnVzOiAnaTJjJzogYWRkIGRyaXZlciBz
YWE3MTE1DQpbICAgMTUuMDUxNzcwXSBidXM6ICdpMmMnOiBhZGQgZHJpdmVyIGNzNTNsMzJh
DQpbICAgMTUuMDUyMDA5XSBidXM6ICdpMmMnOiBhZGQgZHJpdmVyIHdtODc3NQ0KWyAgIDE1
LjA1MjI1MF0gYnVzOiAnaTJjJzogYWRkIGRyaXZlciBpci1rYmQtaTJjDQpbICAgMTUuMDUy
NDgxXSBidXM6ICdpMmMnOiBhZGQgZHJpdmVyIHR1bmVyDQpbICAgMTguMTY1MzgxXSBwc21v
dXNlOiBwcm9iZSBvZiBzZXJpbzEgcmVqZWN0cyBtYXRjaCAtMTkNClsgICAxOC4xNjc4MzVd
IGJ1czogJ2hpZCc6IHJlZ2lzdGVyZWQNClsgICAxOC4xNjc4NDNdIGRldmljZSBjbGFzcyAn
aGlkcmF3JzogcmVnaXN0ZXJpbmcNClsgICAxOC4xNjgwNDJdIGhpZHJhdzogcmF3IEhJRCBl
dmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQ0KWyAgIDE4LjE2ODA2Nl0gYnVzOiAnaGlk
JzogYWRkIGRyaXZlciBoaWQtZ2VuZXJpYw0KWyAgIDE4LjE2ODMxMV0gYnVzOiAnaGlkJzog
YWRkIGRyaXZlciBhNHRlY2gNClsgICAxOC4xNjg1NTVdIGJ1czogJ2hpZCc6IGFkZCBkcml2
ZXIgYXBwbGUNClsgICAxOC4xNjg4MzVdIGJ1czogJ2hpZCc6IGFkZCBkcml2ZXIgYmVsa2lu
DQpbICAgMTguMTY5MDc0XSBidXM6ICdoaWQnOiBhZGQgZHJpdmVyIGNoZXJyeQ0KWyAgIDE4
LjE2OTMwN10gYnVzOiAnaGlkJzogYWRkIGRyaXZlciBjaGljb255DQpbICAgMTguMTY5NTI1
XSBidXM6ICdoaWQnOiBhZGQgZHJpdmVyIGN5cHJlc3MNClsgICAxOC4xNjk3MTRdIGJ1czog
J2hpZCc6IGFkZCBkcml2ZXIgZXprZXkNClsgICAxOC4xNjk5MzFdIGJ1czogJ2hpZCc6IGFk
ZCBkcml2ZXIga2Vuc2luZ3Rvbg0KWyAgIDE4LjE3MDE2MV0gYnVzOiAnaGlkJzogYWRkIGRy
aXZlciBsb2dpdGVjaA0KWyAgIDE4LjE3MDM5MV0gYnVzOiAnaGlkJzogYWRkIGRyaXZlciBt
aWNyb3NvZnQNClsgICAxOC4xNzA2NjRdIGJ1czogJ2hpZCc6IGFkZCBkcml2ZXIgbW9udGVy
ZXkNClsgICAxOC4xNzA5MDRdIGJ1czogJ3VzYic6IGFkZCBkcml2ZXIgdXNiaGlkDQpbICAg
MTguMTcxMzkwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVz
YmhpZA0KWyAgIDE4LjE3MTM5MV0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyDQpbICAg
MTguMTcxNTQ0XSBkZXZpY2U6ICd0aW1lcic6IGRldmljZV9hZGQNClsgICAxOC4xNzE5OTRd
IFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnRpbWVyDQpbICAgMTguMTcyODA5XSBkZXZp
Y2U6ICdzZXEnOiBkZXZpY2VfYWRkDQpbICAgMTguMTcyOTk3XSBQTTogQWRkaW5nIGluZm8g
Zm9yIE5vIEJ1czpzZXENClsgICAxOC4xNzM4NDhdIGRldmljZTogJ3NlcXVlbmNlcic6IGRl
dmljZV9hZGQNClsgICAxOC4xNzQwMzZdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnNl
cXVlbmNlcg0KWyAgIDE4LjE3NDcwN10gZGV2aWNlOiAnc2VxdWVuY2VyMic6IGRldmljZV9h
ZGQNClsgICAxOC4xNzQ4OTNdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOnNlcXVlbmNl
cjINClsgICAxOC4xNzk3NzNdIGJ1czogJ3BjaSc6IGFkZCBkcml2ZXIgc25kX2NtaXBjaQ0K
WyAgIDE4LjE4MDUzM10gYnVzOiAncGNpJzogYWRkIGRyaXZlciBzbmRfaGRhX2ludGVsDQpb
ICAgMTguMTgxMTk5XSBidXM6ICdwY2knOiBhZGQgZHJpdmVyIHNuZF9veHlnZW4NClsgICAx
OC4xODE4NDddIGJ1czogJ3VzYic6IGFkZCBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgIDE4
LjE4MjM0NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQt
dXNiLWF1ZGlvDQpbICAgMTguMTgyMzUyXSBidXM6ICd1c2InOiBhZGQgZHJpdmVyIHNuZC11
YTEwMQ0KWyAgIDE4LjE4MjgxMV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBzbmQtdWExMDENClsgICAxOC4xODI4MTddIGJ1czogJ3VzYic6IGFkZCBkcml2
ZXIgc25kLXVzYi11c3gyeQ0KWyAgIDE4LjE4MzI4Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLXVzeDJ5DQpbICAgMTguMTgzMjg3XSBidXM6
ICd1c2InOiBhZGQgZHJpdmVyIHNuZC11c2ItY2FpYXENClsgICAxOC4xODM1ODddIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1jYWlhcQ0KWyAg
IDE4LjE4MzU5NV0gYnVzOiAndXNiJzogYWRkIGRyaXZlciBzbmQtdXNiLTZmaXJlDQpbICAg
MTguMTg0MDgxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNu
ZC11c2ItNmZpcmUNClsgICAxOC4xODQxNTNdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVU
TElOSyB2MC4zMC4NClsgICAxOC4xODQxNzldIG5mbmxfYWNjdDogcmVnaXN0ZXJpbmcgd2l0
aCBuZm5ldGxpbmsuDQpbICAgMTguMTg0MjU1XSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUu
MCAoNzMwMyBidWNrZXRzLCAyOTIxMiBtYXgpDQpbICAgMTguMTg2MDcyXSBjdG5ldGxpbmsg
djAuOTM6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KWyAgIDIxLjA1MzY5NF0gUE06
IEFkZGluZyBpbmZvIGZvciBObyBCdXM6ZXZlbnQzDQpbICAgMjEuMDU0NDM3XSBkZXZpY2Ug
Y2xhc3MgJ3VzYm1pc2MnOiByZWdpc3RlcmluZw0KWyAgIDIxLjA1NDg2NV0gZGV2aWNlOiAn
aGlkZGV2MCc6IGRldmljZV9hZGQNClsgICAyMS4wNTUzOTZdIFBNOiBBZGRpbmcgaW5mbyBm
b3IgTm8gQnVzOmhpZGRldjANClsgICAyMS4wNTYxNjBdIGRldmljZTogJ2hpZHJhdzEnOiBk
ZXZpY2VfYWRkDQpbICAgMjEuMDU2NjIwXSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czpo
aWRyYXcxDQpbICAgMjEuMDU3MTMyXSBsb2dpdGVjaCAwMDAzOjA0NkQ6QzUxNy4wMDAyOiBp
bnB1dCxoaWRkZXYwLGhpZHJhdzE6IFVTQiBISUQgdjEuMTAgTW91c2UgW0xvZ2l0ZWNoIFVT
QiBSZWNlaXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0zL2lucHV0MQ0KWyAgIDIxLjA1NzEz
NF0gZHJpdmVyOiAnMDAwMzowNDZEOkM1MTcuMDAwMic6IGRyaXZlcl9ib3VuZDogYm91bmQg
dG8gZGV2aWNlICdsb2dpdGVjaCcNClsgICAyMS4wNTcxNDVdIGJ1czogJ2hpZCc6IHJlYWxs
eV9wcm9iZTogYm91bmQgZGV2aWNlIDAwMDM6MDQ2RDpDNTE3LjAwMDIgdG8gZHJpdmVyIGxv
Z2l0ZWNoDQpbICAgMjEuMDU3MTUwXSBkcml2ZXI6ICc4LTM6MS4xJzogZHJpdmVyX2JvdW5k
OiBib3VuZCB0byBkZXZpY2UgJ3VzYmhpZCcNClsgICAyMS4wNTcxNTNdIGJ1czogJ3VzYic6
IHJlYWxseV9wcm9iZTogYm91bmQgZGV2aWNlIDgtMzoxLjEgdG8gZHJpdmVyIHVzYmhpZA0K
WyAgIDIxLjA1NzE3N10gZGV2aWNlOiAnZXBfODInOiBkZXZpY2VfYWRkDQpbICAgMjEuMDU3
Mjc0XSBQTTogQWRkaW5nIGluZm8gZm9yIE5vIEJ1czplcF84Mg0KWyAgIDIxLjA1NzI3N10g
ZHJpdmVyOiAnOC0zJzogZHJpdmVyX2JvdW5kOiBib3VuZCB0byBkZXZpY2UgJ3VzYicNClsg
ICAyMS4wNTcyODVdIGJ1czogJ3VzYic6IHJlYWxseV9wcm9iZTogYm91bmQgZGV2aWNlIDgt
MyB0byBkcml2ZXIgdXNiDQpbICAgMjEuMDU3MzIyXSBkZXZpY2U6ICdlcF8wMCc6IGRldmlj
ZV9hZGQNClsgICAyMS4wNTczOTVdIFBNOiBBZGRpbmcgaW5mbyBmb3IgTm8gQnVzOmVwXzAw
DQpbICAgMjEuNDg1MzMwXSBhc3luY193YWl0aW5nIEAgMQ0KWyAgIDIxLjQ5MjU1OF0gYXN5
bmNfY29udGludWluZyBAIDEgYWZ0ZXIgNCB1c2VjDQpbICAgMjEuNTAwMjQxXSBGcmVlaW5n
IHVudXNlZCBrZXJuZWwgbWVtb3J5OiAxMDcyayBmcmVlZA0KWyAgIDIxLjUwNzcxOV0gV3Jp
dGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBkYXRhOiAxNDMzNmsNClsgICAy
MS41MjEyMjNdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE4MGsgZnJlZWQNClsg
ICAyMS41Mjg2NjVdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDIwOGsgZnJlZWQN
ClsgICAyMS42MDU4NDRdIHVkZXZbMTUwMV06IHN0YXJ0aW5nIHZlcnNpb24gMTY0DQpbICAx
MjYuMzc5Nzk5XSBTUDUxMDAgVENPIHRpbWVyIFNQNTEwMCBUQ08gdGltZXI6IHNodXRkb3du
DQpbICAxMjYuMzg2NTE2XSBpMmMgaTJjLTA6IHNodXRkb3duDQpbICAxMjYuMzkzMDUwXSBz
ZXJpbyBzZXJpbzE6IHNodXRkb3duDQpbICAxMjYuMzk5NTIyXSBzZXJpbyBzZXJpbzA6IHNo
dXRkb3duDQpbICAxMjYuNDA1ODExXSBpODA0MiBpODA0Mjogc2h1dGRvd24NClsgIDEyNi40
MTI0MDFdIHN5c3RlbSAwMDowYzogc2h1dGRvd24NClsgIDEyNi40MTg1NjddIHN5c3RlbSAw
MDowYjogc2h1dGRvd24NClsgIDEyNi40MjQ2ODddIHN5c3RlbSAwMDowYTogc2h1dGRvd24N
ClsgIDEyNi40MzA3MjNdIHN5c3RlbSAwMDowOTogc2h1dGRvd24NClsgIDEyNi40MzY3MjVd
IHBucCAwMDowODogc2h1dGRvd24NClsgIDEyNi40NDI2NzZdIHN5c3RlbSAwMDowNzogc2h1
dGRvd24NClsgIDEyNi40NDg1MzldIHNlcmlhbCAwMDowNjogc2h1dGRvd24NClsgIDEyNi40
NTQzMzhdIHBucCAwMDowNTogc2h1dGRvd24NClsgIDEyNi40NjAwMTZdIHBucCAwMDowNDog
c2h1dGRvd24NClsgIDEyNi40NjU2NDVdIHJ0Y19jbW9zIDAwOjAzOiBzaHV0ZG93bg0KWyAg
MTI2LjQ3MTI3OV0gcG5wIDAwOjAyOiBzaHV0ZG93bg0KWyAgMTI2LjQ3Njc0NF0gc3lzdGVt
IDAwOjAxOiBzaHV0ZG93bg0KWyAgMTI2LjQ4MjEyOF0gc3lzdGVtIDAwOjAwOiBzaHV0ZG93
bg0KWyAgMTI2LjQ4NzM4NV0gcGNpYmFjayAwMDAwOjAzOjA2LjA6IHNodXRkb3duDQpbICAx
MjYuNDkyNTQ0XSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogc2h1dGRvd24NClsgIDEyNi40OTc2
NDNdIHBjaWJhY2sgMDAwMDowNTowMC4xOiBzaHV0ZG93bg0KWyAgMTI2LjUwMjczMF0gcGNp
YmFjayAwMDAwOjA1OjAwLjA6IHNodXRkb3duDQpbICAxMjYuNTA3NTE5XSBwY2liYWNrIDAw
MDA6MDY6MDAuMDogc2h1dGRvd24NClsgIDEyNi41MTIyMDZdIHhoY2lfaGNkIDAwMDA6MDc6
MDAuMDogc2h1dGRvd24NClsgIDEyNi41MzA5NzVdIHI4MTY5IDAwMDA6MDg6MDAuMDogc2h1
dGRvd24NClsgIDEyNi41MzU4ODBdIHI4MTY5IDAwMDA6MDk6MDAuMDogc2h1dGRvd24NClsg
IDEyNi41NDA3MTVdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogc2h1dGRvd24NClsgIDEyNi41
NDU0NDNdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMTogc2h1dGRvd24NClsgIDEyNi41NTAwMjVd
IG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogc2h1dGRvd24NClsgIDEyNi41NTQ1MTVdIHBjaSAw
MDAwOjBhOjAwLjA6IHNodXRkb3duDQpbICAxMjYuNTU4OTY2XSBwY2kgMDAwMDowYzowMC4w
OiBzaHV0ZG93bg0KWyAgMTI2LjU2MzE3M10gcGNpIDAwMDA6MDA6MTguNDogc2h1dGRvd24N
ClsgIDEyNi41NjcxOTddIGsxMHRlbXAgMDAwMDowMDoxOC4zOiBzaHV0ZG93bg0KWyAgMTI2
LjU3MTEyOV0gcGNpIDAwMDA6MDA6MTguMjogc2h1dGRvd24NClsgIDEyNi41NzQ5NzldIHBj
aSAwMDAwOjAwOjE4LjE6IHNodXRkb3duDQpbICAxMjYuNTc4NzI0XSBwY2kgMDAwMDowMDox
OC4wOiBzaHV0ZG93bg0KWyAgMTI2LjU4MjM1M10gZWhjaS1wY2kgMDAwMDowMDoxNi4yOiBz
aHV0ZG93bg0KWyAgMTI2LjU4NjQxOV0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBzaHV0ZG93
bg0KWyAgMTI2LjU5MDAwMl0gcGNpZXBvcnQgMDAwMDowMDoxNS4wOiBzaHV0ZG93bg0KWyAg
MTI2LjU5MzUxOV0gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBzaHV0ZG93bg0KWyAgMTI2LjU5
NjkzMl0gcGNpIDAwMDA6MDA6MTQuNDogc2h1dGRvd24NClsgIDEyNi42MDAzNDhdIHBjaSAw
MDAwOjAwOjE0LjM6IHNodXRkb3duDQpbICAxMjYuNjAzNjAxXSBwY2kgMDAwMDowMDoxNC4x
OiBzaHV0ZG93bg0KWyAgMTI2LjYwNjcxM10gcGlpeDRfc21idXMgMDAwMDowMDoxNC4wOiBz
aHV0ZG93bg0KWyAgMTI2LjYwOTg3M10gZWhjaS1wY2kgMDAwMDowMDoxMy4yOiBzaHV0ZG93
bg0KWyAgMTI2LjYxMzE1NV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBzaHV0ZG93bg0KWyAg
MTI2LjYxNjI3MV0gZWhjaS1wY2kgMDAwMDowMDoxMi4yOiBzaHV0ZG93bg0KWyAgMTI2LjYy
MDIwN10gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBzaHV0ZG93bg0KWyAgMTI2LjYyMzEzOF0g
cGNpIDAwMDA6MDA6MTEuMDogc2h1dGRvd24NClsgIDEyNi42MjU5OTNdIHBjaWVwb3J0IDAw
MDA6MDA6MGQuMDogc2h1dGRvd24NClsgIDEyNi42Mjg5MDhdIHBjaWVwb3J0IDAwMDA6MDA6
MGIuMDogc2h1dGRvd24NClsgIDEyNi42MzE3MDBdIHBjaWVwb3J0IDAwMDA6MDA6MGEuMDog
c2h1dGRvd24NClsgIDEyNi42MzQ0MzFdIHBjaWVwb3J0IDAwMDA6MDA6MDkuMDogc2h1dGRv
d24NClsgIDEyNi42MzcwOTddIHBjaWVwb3J0IDAwMDA6MDA6MDYuMDogc2h1dGRvd24NClsg
IDEyNi42Mzk3NDddIHBjaWVwb3J0IDAwMDA6MDA6MDUuMDogc2h1dGRvd24NClsgIDEyNi42
NDIzMjldIHBjaWVwb3J0IDAwMDA6MDA6MDMuMDogc2h1dGRvd24NClsgIDEyNi42NDQ4MjBd
IHBjaWVwb3J0IDAwMDA6MDA6MDIuMDogc2h1dGRvd24NClsgIDEyNi42NDcyMDddIHBjaSAw
MDAwOjAwOjAwLjI6IHNodXRkb3duDQpbICAxMjYuNjQ5NTgyXSBwY2kgMDAwMDowMDowMC4w
OiBzaHV0ZG93bg0KWyAgMTI2LjY1NjM5MF0gRGlzYWJsaW5nIG5vbi1ib290IENQVXMgLi4u
DQpbICAxMjYuNjYzMTU5XSBkZXZpY2U6ICdtYWNoaW5lY2hlY2sxJzogZGV2aWNlX3VucmVn
aXN0ZXINClsgIDEyNi42NjU2MjFdIGJ1czogJ21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZp
Y2UgbWFjaGluZWNoZWNrMQ0KWyAgMTI2LjY2ODAzM10gUE06IFJlbW92aW5nIGluZm8gZm9y
IG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2sxDQpbICAxMjYuNzcxODc0XSBkZXZpY2U6ICdt
YWNoaW5lY2hlY2syJzogZGV2aWNlX3VucmVnaXN0ZXINClsgIDEyNi43NzQ2MTNdIGJ1czog
J21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZpY2UgbWFjaGluZWNoZWNrMg0KWyAgMTI2Ljc3
NzI1OF0gUE06IFJlbW92aW5nIGluZm8gZm9yIG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2sy
DQpbICAxMjYuODgxODczXSBkZXZpY2U6ICdtYWNoaW5lY2hlY2szJzogZGV2aWNlX3VucmVn
aXN0ZXINClsgIDEyNi44ODQ2NTRdIGJ1czogJ21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZp
Y2UgbWFjaGluZWNoZWNrMw0KWyAgMTI2Ljg4NzQ4Nl0gUE06IFJlbW92aW5nIGluZm8gZm9y
IG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2szDQpbICAxMjYuODkzMDk0XSBkZXZpY2U6ICdt
YWNoaW5lY2hlY2s0JzogZGV2aWNlX3VucmVnaXN0ZXINClsgIDEyNi44OTYwODZdIGJ1czog
J21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZpY2UgbWFjaGluZWNoZWNrNA0KWyAgMTI2Ljg5
OTA4NV0gUE06IFJlbW92aW5nIGluZm8gZm9yIG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2s0
DQpbICAxMjcuMDA1MjI2XSBkZXZpY2U6ICdtYWNoaW5lY2hlY2s1JzogZGV2aWNlX3VucmVn
aXN0ZXINClsgIDEyNy4wMDgzMDldIGJ1czogJ21hY2hpbmVjaGVjayc6IHJlbW92ZSBkZXZp
Y2UgbWFjaGluZWNoZWNrNQ0KWyAgMTI3LjAxMTQ2OV0gUE06IFJlbW92aW5nIGluZm8gZm9y
IG1hY2hpbmVjaGVjazptYWNoaW5lY2hlY2s1DQpbICAxMjcuMDE0OTk1XSBSZXN0YXJ0aW5n
IHN5c3RlbS4NCihYRU4pIFsyMDEzLTAyLTI1IDIwOjE1OjU2XSBEb21haW4gMCBzaHV0ZG93
bjogcmVib290aW5nIG1hY2hpbmUuDQo=
------------0791EC21F164E2952
Content-Type: application/octet-stream;
 name=dotconfig
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename=dotconfig

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4
L3g4Nl82NCAzLjguMC1yYzAtMjAxMzAyMjUgS2VybmVsIENvbmZpZ3VyYXRpb24KIwpDT05G
SUdfNjRCSVQ9eQpDT05GSUdfWDg2XzY0PXkKQ09ORklHX1g4Nj15CkNPTkZJR19JTlNUUlVD
VElPTl9ERUNPREVSPXkKQ09ORklHX09VVFBVVF9GT1JNQVQ9ImVsZjY0LXg4Ni02NCIKQ09O
RklHX0FSQ0hfREVGQ09ORklHPSJhcmNoL3g4Ni9jb25maWdzL3g4Nl82NF9kZWZjb25maWci
CkNPTkZJR19MT0NLREVQX1NVUFBPUlQ9eQpDT05GSUdfU1RBQ0tUUkFDRV9TVVBQT1JUPXkK
Q09ORklHX0hBVkVfTEFURU5DWVRPUF9TVVBQT1JUPXkKQ09ORklHX01NVT15CkNPTkZJR19O
RUVEX0RNQV9NQVBfU1RBVEU9eQpDT05GSUdfTkVFRF9TR19ETUFfTEVOR1RIPXkKQ09ORklH
X0dFTkVSSUNfSVNBX0RNQT15CkNPTkZJR19HRU5FUklDX0JVRz15CkNPTkZJR19HRU5FUklD
X0JVR19SRUxBVElWRV9QT0lOVEVSUz15CkNPTkZJR19HRU5FUklDX0hXRUlHSFQ9eQpDT05G
SUdfQVJDSF9NQVlfSEFWRV9QQ19GREM9eQpDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklU
SE09eQpDT05GSUdfR0VORVJJQ19DQUxJQlJBVEVfREVMQVk9eQpDT05GSUdfQVJDSF9IQVNf
Q1BVX1JFTEFYPXkKQ09ORklHX0FSQ0hfSEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNI
X0hBU19DQUNIRV9MSU5FX1NJWkU9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX0FVVE9QUk9CRT15
CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVfQVJFQT15CkNPTkZJR19ORUVEX1BFUl9DUFVf
RU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVFRF9QRVJfQ1BVX1BBR0VfRklSU1RfQ0hV
Tks9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NTSUJMRT15CkNPTkZJR19BUkNIX1NV
U1BFTkRfUE9TU0lCTEU9eQpDT05GSUdfWk9ORV9ETUEzMj15CkNPTkZJR19BVURJVF9BUkNI
PXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1JWkVEX0lOTElOSU5HPXkKQ09ORklHX0FS
Q0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklHX0hBVkVfSU5URUxfVFhUPXkK
Q09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2X0hUPXkKQ09ORklHX0FSQ0hfSFdFSUdI
VF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1yZGkgLWZjYWxsLXNhdmVkLXJzaSAtZmNhbGwtc2F2
ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZjYWxsLXNhdmVkLXI4IC1mY2FsbC1zYXZlZC1y
OSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZlZC1yMTEiCkNPTkZJR19BUkNIX0NQVV9Q
Uk9CRV9SRUxFQVNFPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfVVBST0JFUz15CkNPTkZJR19E
RUZDT05GSUdfTElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9SRUxFQVNFLy5jb25maWciCkNP
TkZJR19JUlFfV09SSz15CkNPTkZJR19CVUlMRFRJTUVfRVhUQUJMRV9TT1JUPXkKCiMKIyBH
ZW5lcmFsIHNldHVwCiMKQ09ORklHX0VYUEVSSU1FTlRBTD15CkNPTkZJR19JTklUX0VOVl9B
UkdfTElNSVQ9MzIKQ09ORklHX0NST1NTX0NPTVBJTEU9IiIKQ09ORklHX0xPQ0FMVkVSU0lP
Tj0iIgojIENPTkZJR19MT0NBTFZFUlNJT05fQVVUTyBpcyBub3Qgc2V0CkNPTkZJR19IQVZF
X0tFUk5FTF9HWklQPXkKQ09ORklHX0hBVkVfS0VSTkVMX0JaSVAyPXkKQ09ORklHX0hBVkVf
S0VSTkVMX0xaTUE9eQpDT05GSUdfSEFWRV9LRVJORUxfWFo9eQpDT05GSUdfSEFWRV9LRVJO
RUxfTFpPPXkKQ09ORklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VSTkVMX0JaSVAyIGlz
IG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENPTkZJR19LRVJO
RUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBzZXQKQ09ORklH
X0RFRkFVTFRfSE9TVE5BTUU9Iihub25lKSIKQ09ORklHX1NXQVA9eQpDT05GSUdfU1lTVklQ
Qz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CiMgQ09ORklHX1BPU0lYX01RVUVVRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0ZIQU5ETEUgaXMgbm90IHNldApDT05GSUdfQVVESVQ9eQpDT05G
SUdfQVVESVRTWVNDQUxMPXkKQ09ORklHX0FVRElUX1dBVENIPXkKQ09ORklHX0FVRElUX1RS
RUU9eQojIENPTkZJR19BVURJVF9MT0dJTlVJRF9JTU1VVEFCTEUgaXMgbm90IHNldApDT05G
SUdfSEFWRV9HRU5FUklDX0hBUkRJUlFTPXkKCiMKIyBJUlEgc3Vic3lzdGVtCiMKQ09ORklH
X0dFTkVSSUNfSEFSRElSUVM9eQpDT05GSUdfR0VORVJJQ19JUlFfUFJPQkU9eQpDT05GSUdf
R0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19HRU5FUklDX1BFTkRJTkdfSVJRPXkKQ09ORklH
X0lSUV9ET01BSU49eQojIENPTkZJR19JUlFfRE9NQUlOX0RFQlVHIGlzIG5vdCBzZXQKQ09O
RklHX0lSUV9GT1JDRURfVEhSRUFESU5HPXkKQ09ORklHX1NQQVJTRV9JUlE9eQpDT05GSUdf
Q0xPQ0tTT1VSQ0VfV0FUQ0hET0c9eQpDT05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkK
Q09ORklHX0FMV0FZU19VU0VfUEVSU0lTVEVOVF9DTE9DSz15CkNPTkZJR19HRU5FUklDX1RJ
TUVfVlNZU0NBTEw9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UUz15CkNPTkZJR19HRU5F
UklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlJP
QURDQVNUPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfTUlOX0FESlVTVD15CkNPTkZJ
R19HRU5FUklDX0NNT1NfVVBEQVRFPXkKCiMKIyBUaW1lcnMgc3Vic3lzdGVtCiMKQ09ORklH
X1RJQ0tfT05FU0hPVD15CkNPTkZJR19OT19IWj15CkNPTkZJR19ISUdIX1JFU19USU1FUlM9
eQoKIwojIENQVS9UYXNrIHRpbWUgYW5kIHN0YXRzIGFjY291bnRpbmcKIwpDT05GSUdfVElD
S19DUFVfQUNDT1VOVElORz15CiMgQ09ORklHX1ZJUlRfQ1BVX0FDQ09VTlRJTkdfR0VOIGlz
IG5vdCBzZXQKIyBDT05GSUdfSVJRX1RJTUVfQUNDT1VOVElORyBpcyBub3Qgc2V0CkNPTkZJ
R19CU0RfUFJPQ0VTU19BQ0NUPXkKIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVF9WMyBpcyBu
b3Qgc2V0CkNPTkZJR19UQVNLU1RBVFM9eQpDT05GSUdfVEFTS19ERUxBWV9BQ0NUPXkKQ09O
RklHX1RBU0tfWEFDQ1Q9eQpDT05GSUdfVEFTS19JT19BQ0NPVU5USU5HPXkKCiMKIyBSQ1Ug
U3Vic3lzdGVtCiMKQ09ORklHX1RSRUVfUFJFRU1QVF9SQ1U9eQpDT05GSUdfUFJFRU1QVF9S
Q1U9eQpDT05GSUdfUkNVX1NUQUxMX0NPTU1PTj15CiMgQ09ORklHX1JDVV9VU0VSX1FTIGlz
IG5vdCBzZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKQ09ORklHX1JDVV9GQU5PVVRfTEVBRj0x
NgojIENPTkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQVNU
X05PX0haPXkKIyBDT05GSUdfVFJFRV9SQ1VfVFJBQ0UgaXMgbm90IHNldApDT05GSUdfUkNV
X0JPT1NUPXkKQ09ORklHX1JDVV9CT09TVF9QUklPPTEKQ09ORklHX1JDVV9CT09TVF9ERUxB
WT01MDAKIyBDT05GSUdfUkNVX05PQ0JfQ1BVIGlzIG5vdCBzZXQKQ09ORklHX0lLQ09ORklH
PXkKIyBDT05GSUdfSUtDT05GSUdfUFJPQyBpcyBub3Qgc2V0CkNPTkZJR19MT0dfQlVGX1NI
SUZUPTE4CkNPTkZJR19IQVZFX1VOU1RBQkxFX1NDSEVEX0NMT0NLPXkKQ09ORklHX0FSQ0hf
U1VQUE9SVFNfTlVNQV9CQUxBTkNJTkc9eQpDT05GSUdfQVJDSF9XQU5UU19QUk9UX05VTUFf
UFJPVF9OT05FPXkKIyBDT05GSUdfTlVNQV9CQUxBTkNJTkcgaXMgbm90IHNldApDT05GSUdf
Q0dST1VQUz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DR1JP
VVBfRlJFRVpFUj15CiMgQ09ORklHX0NHUk9VUF9ERVZJQ0UgaXMgbm90IHNldApDT05GSUdf
Q1BVU0VUUz15CkNPTkZJR19QUk9DX1BJRF9DUFVTRVQ9eQpDT05GSUdfQ0dST1VQX0NQVUFD
Q1Q9eQpDT05GSUdfUkVTT1VSQ0VfQ09VTlRFUlM9eQojIENPTkZJR19NRU1DRyBpcyBub3Qg
c2V0CiMgQ09ORklHX0NHUk9VUF9IVUdFVExCIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dST1VQ
X1BFUkYgaXMgbm90IHNldApDT05GSUdfQ0dST1VQX1NDSEVEPXkKQ09ORklHX0ZBSVJfR1JP
VVBfU0NIRUQ9eQojIENPTkZJR19DRlNfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdf
UlRfR1JPVVBfU0NIRUQgaXMgbm90IHNldApDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklH
X0RFQlVHX0JMS19DR1JPVVAgaXMgbm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RP
UkUgaXMgbm90IHNldApDT05GSUdfTkFNRVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05G
SUdfSVBDX05TPXkKQ09ORklHX1BJRF9OUz15CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NI
RURfQVVUT0dST1VQPXkKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CiMg
Q09ORklHX1JFTEFZIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklH
X0lOSVRSQU1GU19TT1VSQ0U9IiIKQ09ORklHX1JEX0daSVA9eQpDT05GSUdfUkRfQlpJUDI9
eQpDT05GSUdfUkRfTFpNQT15CkNPTkZJR19SRF9YWj15CkNPTkZJR19SRF9MWk89eQojIENP
TkZJR19DQ19PUFRJTUlaRV9GT1JfU0laRSBpcyBub3Qgc2V0CkNPTkZJR19TWVNDVEw9eQpD
T05GSUdfQU5PTl9JTk9ERVM9eQojIENPTkZJR19FWFBFUlQgaXMgbm90IHNldApDT05GSUdf
SEFWRV9VSUQxNj15CkNPTkZJR19VSUQxNj15CiMgQ09ORklHX1NZU0NUTF9TWVNDQUxMIGlz
IG5vdCBzZXQKQ09ORklHX1NZU0NUTF9FWENFUFRJT05fVFJBQ0U9eQpDT05GSUdfS0FMTFNZ
TVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKQ09ORklHX0hPVFBMVUc9eQpDT05GSUdfUFJJ
TlRLPXkKQ09ORklHX0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19QQ1NQS1JfUExB
VEZPUk09eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfQkFTRV9GVUxM
PXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZEPXkKQ09O
RklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJR19B
SU89eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZF
TlRTPXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNP
TkZJR19QRVJGX0VWRU5UUz15CiMgQ09ORklHX0RFQlVHX1BFUkZfVVNFX1ZNQUxMT0MgaXMg
bm90IHNldApDT05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdfUENJX1FVSVJLUz15
CkNPTkZJR19TTFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NMQUIgaXMgbm90IHNldApDT05GSUdfU0xVQj15CiMgQ09ORklHX1BST0ZJTElO
RyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX09QUk9GSUxFPXkKQ09ORklHX09QUk9GSUxFX05N
SV9USU1FUj15CiMgQ09ORklHX0tQUk9CRVMgaXMgbm90IHNldApDT05GSUdfSlVNUF9MQUJF
TD15CkNPTkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklHX0FS
Q0hfVVNFX0JVSUxUSU5fQlNXQVA9eQpDT05GSUdfSEFWRV9JT1JFTUFQX1BST1Q9eQpDT05G
SUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JFUz15CkNPTkZJR19IQVZF
X09QVFBST0JFUz15CkNPTkZJR19IQVZFX0tQUk9CRVNfT05fRlRSQUNFPXkKQ09ORklHX0hB
VkVfQVJDSF9UUkFDRUhPT0s9eQpDT05GSUdfSEFWRV9ETUFfQVRUUlM9eQpDT05GSUdfVVNF
X0dFTkVSSUNfU01QX0hFTFBFUlM9eQpDT05GSUdfR0VORVJJQ19TTVBfSURMRV9USFJFQUQ9
eQpDT05GSUdfSEFWRV9SRUdTX0FORF9TVEFDS19BQ0NFU1NfQVBJPXkKQ09ORklHX0hBVkVf
RE1BX0FQSV9ERUJVRz15CkNPTkZJR19IQVZFX0hXX0JSRUFLUE9JTlQ9eQpDT05GSUdfSEFW
RV9NSVhFRF9CUkVBS1BPSU5UU19SRUdTPXkKQ09ORklHX0hBVkVfVVNFUl9SRVRVUk5fTk9U
SUZJRVI9eQpDT05GSUdfSEFWRV9QRVJGX0VWRU5UU19OTUk9eQpDT05GSUdfSEFWRV9QRVJG
X1JFR1M9eQpDT05GSUdfSEFWRV9QRVJGX1VTRVJfU1RBQ0tfRFVNUD15CkNPTkZJR19IQVZF
X0FSQ0hfSlVNUF9MQUJFTD15CkNPTkZJR19BUkNIX0hBVkVfTk1JX1NBRkVfQ01QWENIRz15
CkNPTkZJR19IQVZFX0FMSUdORURfU1RSVUNUX1BBR0U9eQpDT05GSUdfSEFWRV9DTVBYQ0hH
X0xPQ0FMPXkKQ09ORklHX0hBVkVfQ01QWENIR19ET1VCTEU9eQpDT05GSUdfQVJDSF9XQU5U
X0NPTVBBVF9JUENfUEFSU0VfVkVSU0lPTj15CkNPTkZJR19BUkNIX1dBTlRfT0xEX0NPTVBB
VF9JUEM9eQpDT05GSUdfSEFWRV9BUkNIX1NFQ0NPTVBfRklMVEVSPXkKQ09ORklHX1NFQ0NP
TVBfRklMVEVSPXkKQ09ORklHX0hBVkVfQ09OVEVYVF9UUkFDS0lORz15CkNPTkZJR19IQVZF
X0lSUV9USU1FX0FDQ09VTlRJTkc9eQpDT05GSUdfSEFWRV9BUkNIX1RSQU5TUEFSRU5UX0hV
R0VQQUdFPXkKQ09ORklHX01PRFVMRVNfVVNFX0VMRl9SRUxBPXkKQ09ORklHX09MRF9TSUdT
VVNQRU5EMz15CkNPTkZJR19DT01QQVRfT0xEX1NJR0FDVElPTj15CgojCiMgR0NPVi1iYXNl
ZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdfR0NPVl9LRVJORUwgaXMgbm90IHNldAoj
IENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVSRU5UIGlzIG5vdCBzZXQKQ09ORklHX1NM
QUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdfQkFTRV9TTUFMTD0wCkNPTkZJ
R19NT0RVTEVTPXkKIyBDT05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQgaXMgbm90IHNldApDT05G
SUdfTU9EVUxFX1VOTE9BRD15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90
IHNldAojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBub3Qgc2V0CiMgQ09ORklHX01PRFVMRV9T
UkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0CiMgQ09ORklHX01PRFVMRV9TSUcgaXMgbm90IHNl
dApDT05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklHX0JMT0NLPXkKQ09ORklHX0JMS19ERVZf
QlNHPXkKIyBDT05GSUdfQkxLX0RFVl9CU0dMSUIgaXMgbm90IHNldApDT05GSUdfQkxLX0RF
Vl9JTlRFR1JJVFk9eQojIENPTkZJR19CTEtfREVWX1RIUk9UVExJTkcgaXMgbm90IHNldAoK
IwojIFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJT05fQURWQU5DRUQ9eQojIENP
TkZJR19BQ09STl9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfT1NGX1BBUlRJVElPTj15
CkNPTkZJR19BTUlHQV9QQVJUSVRJT049eQojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMg
bm90IHNldApDT05GSUdfTUFDX1BBUlRJVElPTj15CkNPTkZJR19NU0RPU19QQVJUSVRJT049
eQpDT05GSUdfQlNEX0RJU0tMQUJFTD15CkNPTkZJR19NSU5JWF9TVUJQQVJUSVRJT049eQpD
T05GSUdfU09MQVJJU19YODZfUEFSVElUSU9OPXkKQ09ORklHX1VOSVhXQVJFX0RJU0tMQUJF
TD15CiMgQ09ORklHX0xETV9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU0dJX1BBUlRJ
VElPTj15CiMgQ09ORklHX1VMVFJJWF9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU1VO
X1BBUlRJVElPTj15CkNPTkZJR19LQVJNQV9QQVJUSVRJT049eQpDT05GSUdfRUZJX1BBUlRJ
VElPTj15CiMgQ09ORklHX1NZU1Y2OF9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfQkxP
Q0tfQ09NUEFUPXkKCiMKIyBJTyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15
CkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKQ09ORklH
X0NGUV9HUk9VUF9JT1NDSEVEPXkKIyBDT05GSUdfREVGQVVMVF9ERUFETElORSBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RFRkFVTFRfTk9PUCBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKQ09ORklHX1VOSU5MSU5FX1NQSU5f
VU5MT0NLPXkKQ09ORklHX0ZSRUVaRVI9eQoKIwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0
dXJlcwojCkNPTkZJR19aT05FX0RNQT15CkNPTkZJR19TTVA9eQojIENPTkZJR19YODZfWDJB
UElDIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9NUFBBUlNFPXkKQ09ORklHX1g4Nl9FWFRFTkRF
RF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9WU01QIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2
X0lOVEVMX0xQU1MgaXMgbm90IHNldApDT05GSUdfWDg2X1NVUFBPUlRTX01FTU9SWV9GQUlM
VVJFPXkKQ09ORklHX1NDSEVEX09NSVRfRlJBTUVfUE9JTlRFUj15CkNPTkZJR19QQVJBVklS
VF9HVUVTVD15CiMgQ09ORklHX1BBUkFWSVJUX1RJTUVfQUNDT1VOVElORyBpcyBub3Qgc2V0
CkNPTkZJR19YRU49eQpDT05GSUdfWEVOX0RPTTA9eQpDT05GSUdfWEVOX1BSSVZJTEVHRURf
R1VFU1Q9eQpDT05GSUdfWEVOX1BWSFZNPXkKQ09ORklHX1hFTl9NQVhfRE9NQUlOX01FTU9S
WT01MDAKQ09ORklHX1hFTl9TQVZFX1JFU1RPUkU9eQpDT05GSUdfWEVOX0RFQlVHX0ZTPXkK
IyBDT05GSUdfS1ZNX0dVRVNUIGlzIG5vdCBzZXQKQ09ORklHX1BBUkFWSVJUPXkKIyBDT05G
SUdfUEFSQVZJUlRfU1BJTkxPQ0tTIGlzIG5vdCBzZXQKQ09ORklHX1BBUkFWSVJUX0NMT0NL
PXkKQ09ORklHX1BBUkFWSVJUX0RFQlVHPXkKQ09ORklHX05PX0JPT1RNRU09eQojIENPTkZJ
R19NRU1URVNUIGlzIG5vdCBzZXQKQ09ORklHX01LOD15CiMgQ09ORklHX01QU0MgaXMgbm90
IHNldAojIENPTkZJR19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJR19NQVRPTSBpcyBub3Qg
c2V0CiMgQ09ORklHX0dFTkVSSUNfQ1BVIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9JTlRFUk5P
REVfQ0FDSEVfU0hJRlQ9NgpDT05GSUdfWDg2X0wxX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4
Nl9JTlRFTF9VU0VSQ09QWT15CkNPTkZJR19YODZfVVNFX1BQUk9fQ0hFQ0tTVU09eQpDT05G
SUdfWDg2X1RTQz15CkNPTkZJR19YODZfQ01QWENIRzY0PXkKQ09ORklHX1g4Nl9DTU9WPXkK
Q09ORklHX1g4Nl9NSU5JTVVNX0NQVV9GQU1JTFk9NjQKQ09ORklHX1g4Nl9ERUJVR0NUTE1T
Uj15CkNPTkZJR19DUFVfU1VQX0lOVEVMPXkKQ09ORklHX0NQVV9TVVBfQU1EPXkKQ09ORklH
X0NQVV9TVVBfQ0VOVEFVUj15CkNPTkZJR19IUEVUX1RJTUVSPXkKQ09ORklHX0hQRVRfRU1V
TEFURV9SVEM9eQpDT05GSUdfRE1JPXkKQ09ORklHX0dBUlRfSU9NTVU9eQojIENPTkZJR19D
QUxHQVJZX0lPTU1VIGlzIG5vdCBzZXQKQ09ORklHX1NXSU9UTEI9eQpDT05GSUdfSU9NTVVf
SEVMUEVSPXkKIyBDT05GSUdfTUFYU01QIGlzIG5vdCBzZXQKQ09ORklHX05SX0NQVVM9OApD
T05GSUdfU0NIRURfU01UPXkKQ09ORklHX1NDSEVEX01DPXkKIyBDT05GSUdfUFJFRU1QVF9O
T05FIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJFRU1QVF9WT0xVTlRBUlkgaXMgbm90IHNldApD
T05GSUdfUFJFRU1QVD15CkNPTkZJR19QUkVFTVBUX0NPVU5UPXkKQ09ORklHX1g4Nl9MT0NB
TF9BUElDPXkKQ09ORklHX1g4Nl9JT19BUElDPXkKQ09ORklHX1g4Nl9SRVJPVVRFX0ZPUl9C
Uk9LRU5fQk9PVF9JUlFTPXkKQ09ORklHX1g4Nl9NQ0U9eQpDT05GSUdfWDg2X01DRV9JTlRF
TD15CkNPTkZJR19YODZfTUNFX0FNRD15CkNPTkZJR19YODZfTUNFX1RIUkVTSE9MRD15CiMg
Q09ORklHX1g4Nl9NQ0VfSU5KRUNUIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9USEVSTUFMX1ZF
Q1RPUj15CiMgQ09ORklHX0k4SyBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JPQ09ERSBpcyBu
b3Qgc2V0CkNPTkZJR19YODZfTVNSPXkKQ09ORklHX1g4Nl9DUFVJRD15CkNPTkZJR19BUkNI
X1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX0FSQ0hfRE1BX0FERFJfVF82NEJJVD15CkNP
TkZJR19ESVJFQ1RfR0JQQUdFUz15CkNPTkZJR19OVU1BPXkKQ09ORklHX0FNRF9OVU1BPXkK
Q09ORklHX1g4Nl82NF9BQ1BJX05VTUE9eQpDT05GSUdfTk9ERVNfU1BBTl9PVEhFUl9OT0RF
Uz15CiMgQ09ORklHX05VTUFfRU1VIGlzIG5vdCBzZXQKQ09ORklHX05PREVTX1NISUZUPTgK
Q09ORklHX0FSQ0hfU1BBUlNFTUVNX0VOQUJMRT15CkNPTkZJR19BUkNIX1NQQVJTRU1FTV9E
RUZBVUxUPXkKQ09ORklHX0FSQ0hfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19BUkNI
X1BST0NfS0NPUkVfVEVYVD15CkNPTkZJR19JTExFR0FMX1BPSU5URVJfVkFMVUU9MHhkZWFk
MDAwMDAwMDAwMDAwCkNPTkZJR19TRUxFQ1RfTUVNT1JZX01PREVMPXkKQ09ORklHX1NQQVJT
RU1FTV9NQU5VQUw9eQpDT05GSUdfU1BBUlNFTUVNPXkKQ09ORklHX05FRURfTVVMVElQTEVf
Tk9ERVM9eQpDT05GSUdfSEFWRV9NRU1PUllfUFJFU0VOVD15CkNPTkZJR19TUEFSU0VNRU1f
RVhUUkVNRT15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUF9FTkFCTEU9eQpDT05GSUdfU1BB
UlNFTUVNX0FMTE9DX01FTV9NQVBfVE9HRVRIRVI9eQpDT05GSUdfU1BBUlNFTUVNX1ZNRU1N
QVA9eQpDT05GSUdfSEFWRV9NRU1CTE9DSz15CkNPTkZJR19IQVZFX01FTUJMT0NLX05PREVf
TUFQPXkKQ09ORklHX0FSQ0hfRElTQ0FSRF9NRU1CTE9DSz15CiMgQ09ORklHX01PVkFCTEVf
Tk9ERSBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfQk9PVE1FTV9JTkZPX05PREUgaXMgbm90
IHNldAojIENPTkZJR19NRU1PUllfSE9UUExVRyBpcyBub3Qgc2V0CkNPTkZJR19QQUdFRkxB
R1NfRVhURU5ERUQ9eQpDT05GSUdfU1BMSVRfUFRMT0NLX0NQVVM9OTk5OTk5CkNPTkZJR19D
T01QQUNUSU9OPXkKQ09ORklHX01JR1JBVElPTj15CkNPTkZJR19QSFlTX0FERFJfVF82NEJJ
VD15CkNPTkZJR19aT05FX0RNQV9GTEFHPTEKQ09ORklHX0JPVU5DRT15CkNPTkZJR19ORUVE
X0JPVU5DRV9QT09MPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX01NVV9OT1RJRklF
Uj15CiMgQ09ORklHX0tTTSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX01NQVBfTUlOX0FE
RFI9NDA5NgpDT05GSUdfQVJDSF9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CiMgQ09ORklH
X01FTU9SWV9GQUlMVVJFIGlzIG5vdCBzZXQKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdF
PXkKQ09ORklHX1RSQU5TUEFSRU5UX0hVR0VQQUdFX0FMV0FZUz15CiMgQ09ORklHX1RSQU5T
UEFSRU5UX0hVR0VQQUdFX01BRFZJU0UgaXMgbm90IHNldApDT05GSUdfQ1JPU1NfTUVNT1JZ
X0FUVEFDSD15CiMgQ09ORklHX0NMRUFOQ0FDSEUgaXMgbm90IHNldAojIENPTkZJR19GUk9O
VFNXQVAgaXMgbm90IHNldApDT05GSUdfWDg2X0NIRUNLX0JJT1NfQ09SUlVQVElPTj15CkNP
TkZJR19YODZfQk9PVFBBUkFNX01FTU9SWV9DT1JSVVBUSU9OX0NIRUNLPXkKQ09ORklHX1g4
Nl9SRVNFUlZFX0xPVz02NApDT05GSUdfTVRSUj15CkNPTkZJR19NVFJSX1NBTklUSVpFUj15
CkNPTkZJR19NVFJSX1NBTklUSVpFUl9FTkFCTEVfREVGQVVMVD0wCkNPTkZJR19NVFJSX1NB
TklUSVpFUl9TUEFSRV9SRUdfTlJfREVGQVVMVD0xCkNPTkZJR19YODZfUEFUPXkKQ09ORklH
X0FSQ0hfVVNFU19QR19VTkNBQ0hFRD15CkNPTkZJR19BUkNIX1JBTkRPTT15CkNPTkZJR19Y
ODZfU01BUD15CiMgQ09ORklHX0VGSSBpcyBub3Qgc2V0CkNPTkZJR19TRUNDT01QPXkKIyBD
T05GSUdfQ0NfU1RBQ0tQUk9URUNUT1IgaXMgbm90IHNldAojIENPTkZJR19IWl8xMDAgaXMg
bm90IHNldAojIENPTkZJR19IWl8yNTAgaXMgbm90IHNldApDT05GSUdfSFpfMzAwPXkKIyBD
T05GSUdfSFpfMTAwMCBpcyBub3Qgc2V0CkNPTkZJR19IWj0zMDAKQ09ORklHX1NDSEVEX0hS
VElDSz15CkNPTkZJR19LRVhFQz15CkNPTkZJR19DUkFTSF9EVU1QPXkKQ09ORklHX1BIWVNJ
Q0FMX1NUQVJUPTB4MTAwMDAwMApDT05GSUdfUkVMT0NBVEFCTEU9eQpDT05GSUdfUEhZU0lD
QUxfQUxJR049MHgxMDAwMDAwCkNPTkZJR19IT1RQTFVHX0NQVT15CiMgQ09ORklHX0JPT1RQ
QVJBTV9IT1RQTFVHX0NQVTAgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19IT1RQTFVHX0NQ
VTAgaXMgbm90IHNldAojIENPTkZJR19DT01QQVRfVkRTTyBpcyBub3Qgc2V0CiMgQ09ORklH
X0NNRExJTkVfQk9PTCBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX0VOQUJMRV9NRU1PUllfSE9U
UExVRz15CkNPTkZJR19VU0VfUEVSQ1BVX05VTUFfTk9ERV9JRD15CgojCiMgUG93ZXIgbWFu
YWdlbWVudCBhbmQgQUNQSSBvcHRpb25zCiMKIyBDT05GSUdfU1VTUEVORCBpcyBub3Qgc2V0
CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKIyBDT05GSUdfSElCRVJOQVRJT04gaXMg
bm90IHNldApDT05GSUdfUE1fU0xFRVA9eQpDT05GSUdfUE1fU0xFRVBfU01QPXkKIyBDT05G
SUdfUE1fQVVUT1NMRUVQIGlzIG5vdCBzZXQKIyBDT05GSUdfUE1fV0FLRUxPQ0tTIGlzIG5v
dCBzZXQKIyBDT05GSUdfUE1fUlVOVElNRSBpcyBub3Qgc2V0CkNPTkZJR19QTT15CkNPTkZJ
R19QTV9ERUJVRz15CiMgQ09ORklHX1BNX0FEVkFOQ0VEX0RFQlVHIGlzIG5vdCBzZXQKQ09O
RklHX1BNX1NMRUVQX0RFQlVHPXkKIyBDT05GSUdfUE1fVFJBQ0VfUlRDIGlzIG5vdCBzZXQK
Q09ORklHX0FDUEk9eQpDT05GSUdfQUNQSV9QUk9DRlM9eQojIENPTkZJR19BQ1BJX1BST0NG
U19QT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfRUNfREVCVUdGUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDUElfUFJPQ19FVkVOVCBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0FDPXkK
Q09ORklHX0FDUElfQkFUVEVSWT15CkNPTkZJR19BQ1BJX0JVVFRPTj15CkNPTkZJR19BQ1BJ
X1ZJREVPPXkKQ09ORklHX0FDUElfRkFOPXkKIyBDT05GSUdfQUNQSV9ET0NLIGlzIG5vdCBz
ZXQKQ09ORklHX0FDUElfSTJDPXkKQ09ORklHX0FDUElfUFJPQ0VTU09SPXkKQ09ORklHX0FD
UElfSE9UUExVR19DUFU9eQojIENPTkZJR19BQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SIGlz
IG5vdCBzZXQKQ09ORklHX0FDUElfVEhFUk1BTD15CkNPTkZJR19BQ1BJX05VTUE9eQpDT05G
SUdfQUNQSV9DVVNUT01fRFNEVF9GSUxFPSIiCiMgQ09ORklHX0FDUElfQ1VTVE9NX0RTRFQg
aXMgbm90IHNldAojIENPTkZJR19BQ1BJX0lOSVRSRF9UQUJMRV9PVkVSUklERSBpcyBub3Qg
c2V0CkNPTkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdfQUNQSV9ERUJVRyBp
cyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9QTV9USU1FUj15
CkNPTkZJR19BQ1BJX0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfU0JTIGlzIG5vdCBzZXQK
Q09ORklHX0FDUElfSEVEPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fTUVUSE9EIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQUNQSV9BUEVJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZJIGlzIG5vdCBz
ZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdfQ1BVX0ZSRVE9eQpDT05G
SUdfQ1BVX0ZSRVFfVEFCTEU9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTU1PTj15CiMgQ09O
RklHX0NQVV9GUkVRX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxU
X0dPVl9QRVJGT1JNQU5DRSBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dP
Vl9VU0VSU1BBQ0U9eQojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9PTkRFTUFORCBp
cyBub3Qgc2V0CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09WX0NPTlNFUlZBVElWRSBp
cyBub3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9HT1ZfUEVSRk9STUFOQ0U9eQojIENPTkZJR19D
UFVfRlJFUV9HT1ZfUE9XRVJTQVZFIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9GUkVRX0dPVl9V
U0VSU1BBQ0U9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX09OREVNQU5EPXkKIyBDT05GSUdfQ1BV
X0ZSRVFfR09WX0NPTlNFUlZBVElWRSBpcyBub3Qgc2V0CgojCiMgeDg2IENQVSBmcmVxdWVu
Y3kgc2NhbGluZyBkcml2ZXJzCiMKIyBDT05GSUdfWDg2X0lOVEVMX1BTVEFURSBpcyBub3Qg
c2V0CkNPTkZJR19YODZfUENDX0NQVUZSRVE9eQpDT05GSUdfWDg2X0FDUElfQ1BVRlJFUT15
CkNPTkZJR19YODZfQUNQSV9DUFVGUkVRX0NQQj15CiMgQ09ORklHX1g4Nl9QT1dFUk5PV19L
OCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk8gaXMgbm90IHNl
dAojIENPTkZJR19YODZfUDRfQ0xPQ0tNT0QgaXMgbm90IHNldAoKIwojIHNoYXJlZCBvcHRp
b25zCiMKIyBDT05GSUdfWDg2X1NQRUVEU1RFUF9MSUIgaXMgbm90IHNldApDT05GSUdfQ1BV
X0lETEU9eQojIENPTkZJR19DUFVfSURMRV9NVUxUSVBMRV9EUklWRVJTIGlzIG5vdCBzZXQK
Q09ORklHX0NQVV9JRExFX0dPVl9MQURERVI9eQpDT05GSUdfQ1BVX0lETEVfR09WX01FTlU9
eQojIENPTkZJR19BUkNIX05FRURTX0NQVV9JRExFX0NPVVBMRUQgaXMgbm90IHNldAojIENP
TkZJR19JTlRFTF9JRExFIGlzIG5vdCBzZXQKCiMKIyBNZW1vcnkgcG93ZXIgc2F2aW5ncwoj
CiMgQ09ORklHX0k3MzAwX0lETEUgaXMgbm90IHNldAoKIwojIEJ1cyBvcHRpb25zIChQQ0kg
ZXRjLikKIwpDT05GSUdfUENJPXkKQ09ORklHX1BDSV9ESVJFQ1Q9eQpDT05GSUdfUENJX01N
Q09ORklHPXkKQ09ORklHX1BDSV9YRU49eQpDT05GSUdfUENJX0RPTUFJTlM9eQpDT05GSUdf
UENJRVBPUlRCVVM9eQpDT05GSUdfSE9UUExVR19QQ0lfUENJRT15CkNPTkZJR19QQ0lFQUVS
PXkKQ09ORklHX1BDSUVfRUNSQz15CkNPTkZJR19QQ0lFQUVSX0lOSkVDVD15CkNPTkZJR19Q
Q0lFQVNQTT15CkNPTkZJR19QQ0lFQVNQTV9ERUJVRz15CkNPTkZJR19QQ0lFQVNQTV9ERUZB
VUxUPXkKIyBDT05GSUdfUENJRUFTUE1fUE9XRVJTQVZFIGlzIG5vdCBzZXQKIyBDT05GSUdf
UENJRUFTUE1fUEVSRk9STUFOQ0UgaXMgbm90IHNldApDT05GSUdfQVJDSF9TVVBQT1JUU19N
U0k9eQpDT05GSUdfUENJX01TST15CkNPTkZJR19QQ0lfREVCVUc9eQpDT05GSUdfUENJX1JF
QUxMT0NfRU5BQkxFX0FVVE89eQojIENPTkZJR19QQ0lfU1RVQiBpcyBub3Qgc2V0CkNPTkZJ
R19YRU5fUENJREVWX0ZST05URU5EPXkKQ09ORklHX0hUX0lSUT15CkNPTkZJR19QQ0lfQVRT
PXkKQ09ORklHX1BDSV9JT1Y9eQpDT05GSUdfUENJX1BSST15CkNPTkZJR19QQ0lfUEFTSUQ9
eQpDT05GSUdfUENJX0lPQVBJQz15CkNPTkZJR19QQ0lfTEFCRUw9eQpDT05GSUdfSVNBX0RN
QV9BUEk9eQpDT05GSUdfQU1EX05CPXkKQ09ORklHX1BDQ0FSRD15CiMgQ09ORklHX1BDTUNJ
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0NBUkRCVVMgaXMgbm90IHNldAoKIwojIFBDLWNhcmQg
YnJpZGdlcwojCiMgQ09ORklHX1lFTlRBIGlzIG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJ
PXkKQ09ORklHX0hPVFBMVUdfUENJX0FDUEk9eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQSV9J
Qk09eQpDT05GSUdfSE9UUExVR19QQ0lfQ1BDST15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJ
X1pUNTU1MD15CkNPTkZJR19IT1RQTFVHX1BDSV9DUENJX0dFTkVSSUM9eQpDT05GSUdfSE9U
UExVR19QQ0lfU0hQQz15CiMgQ09ORklHX1JBUElESU8gaXMgbm90IHNldAoKIwojIEV4ZWN1
dGFibGUgZmlsZSBmb3JtYXRzIC8gRW11bGF0aW9ucwojCkNPTkZJR19CSU5GTVRfRUxGPXkK
Q09ORklHX0NPTVBBVF9CSU5GTVRfRUxGPXkKQ09ORklHX0FSQ0hfQklORk1UX0VMRl9SQU5E
T01JWkVfUElFPXkKQ09ORklHX0NPUkVfRFVNUF9ERUZBVUxUX0VMRl9IRUFERVJTPXkKIyBD
T05GSUdfSEFWRV9BT1VUIGlzIG5vdCBzZXQKQ09ORklHX0JJTkZNVF9NSVNDPXkKQ09ORklH
X0NPUkVEVU1QPXkKQ09ORklHX0lBMzJfRU1VTEFUSU9OPXkKIyBDT05GSUdfSUEzMl9BT1VU
IGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1gzMiBpcyBub3Qgc2V0CkNPTkZJR19DT01QQVQ9
eQpDT05GSUdfQ09NUEFUX0ZPUl9VNjRfQUxJR05NRU5UPXkKQ09ORklHX1NZU1ZJUENfQ09N
UEFUPXkKQ09ORklHX0tFWVNfQ09NUEFUPXkKQ09ORklHX0hBVkVfVEVYVF9QT0tFX1NNUD15
CkNPTkZJR19YODZfREVWX0RNQV9PUFM9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5n
IG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKIyBDT05GSUdfUEFDS0VUX0RJQUcgaXMgbm90
IHNldApDT05GSUdfVU5JWD15CiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qgc2V0CiMgQ09O
RklHX1hGUk1fVVNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9LRVkgaXMgbm90IHNldApD
T05GSUdfSU5FVD15CkNPTkZJR19JUF9NVUxUSUNBU1Q9eQpDT05GSUdfSVBfQURWQU5DRURf
Uk9VVEVSPXkKIyBDT05GSUdfSVBfRklCX1RSSUVfU1RBVFMgaXMgbm90IHNldApDT05GSUdf
SVBfTVVMVElQTEVfVEFCTEVTPXkKQ09ORklHX0lQX1JPVVRFX01VTFRJUEFUSD15CkNPTkZJ
R19JUF9ST1VURV9WRVJCT1NFPXkKQ09ORklHX0lQX1JPVVRFX0NMQVNTSUQ9eQpDT05GSUdf
SVBfUE5QPXkKQ09ORklHX0lQX1BOUF9ESENQPXkKQ09ORklHX0lQX1BOUF9CT09UUD15CkNP
TkZJR19JUF9QTlBfUkFSUD15CiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0lQR1JFX0RFTVVYIGlzIG5vdCBzZXQKQ09ORklHX0lQX01ST1VURT15CiMgQ09O
RklHX0lQX01ST1VURV9NVUxUSVBMRV9UQUJMRVMgaXMgbm90IHNldApDT05GSUdfSVBfUElN
U01fVjE9eQpDT05GSUdfSVBfUElNU01fVjI9eQojIENPTkZJR19BUlBEIGlzIG5vdCBzZXQK
Q09ORklHX1NZTl9DT09LSUVTPXkKIyBDT05GSUdfSU5FVF9BSCBpcyBub3Qgc2V0CiMgQ09O
RklHX0lORVRfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9JUENPTVAgaXMgbm90IHNl
dAojIENPTkZJR19JTkVUX1hGUk1fVFVOTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5FVF9U
VU5ORUwgaXMgbm90IHNldAojIENPTkZJR19JTkVUX1hGUk1fTU9ERV9UUkFOU1BPUlQgaXMg
bm90IHNldAojIENPTkZJR19JTkVUX1hGUk1fTU9ERV9UVU5ORUwgaXMgbm90IHNldAojIENP
TkZJR19JTkVUX1hGUk1fTU9ERV9CRUVUIGlzIG5vdCBzZXQKQ09ORklHX0lORVRfTFJPPXkK
IyBDT05GSUdfSU5FVF9ESUFHIGlzIG5vdCBzZXQKQ09ORklHX1RDUF9DT05HX0FEVkFOQ0VE
PXkKIyBDT05GSUdfVENQX0NPTkdfQklDIGlzIG5vdCBzZXQKQ09ORklHX1RDUF9DT05HX0NV
QklDPXkKIyBDT05GSUdfVENQX0NPTkdfV0VTVFdPT0QgaXMgbm90IHNldAojIENPTkZJR19U
Q1BfQ09OR19IVENQIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfSFNUQ1AgaXMgbm90
IHNldAojIENPTkZJR19UQ1BfQ09OR19IWUJMQSBpcyBub3Qgc2V0CiMgQ09ORklHX1RDUF9D
T05HX1ZFR0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfU0NBTEFCTEUgaXMgbm90
IHNldAojIENPTkZJR19UQ1BfQ09OR19MUCBpcyBub3Qgc2V0CiMgQ09ORklHX1RDUF9DT05H
X1ZFTk8gaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19ZRUFIIGlzIG5vdCBzZXQKIyBD
T05GSUdfVENQX0NPTkdfSUxMSU5PSVMgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9DVUJJ
Qz15CiMgQ09ORklHX0RFRkFVTFRfUkVOTyBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX1RD
UF9DT05HPSJjdWJpYyIKIyBDT05GSUdfVENQX01ENVNJRyBpcyBub3Qgc2V0CiMgQ09ORklH
X0lQVjYgaXMgbm90IHNldApDT05GSUdfTkVUV09SS19TRUNNQVJLPXkKIyBDT05GSUdfTkVU
V09SS19QSFlfVElNRVNUQU1QSU5HIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUj15CiMg
Q09ORklHX05FVEZJTFRFUl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfQURW
QU5DRUQ9eQpDT05GSUdfQlJJREdFX05FVEZJTFRFUj15CgojCiMgQ29yZSBOZXRmaWx0ZXIg
Q29uZmlndXJhdGlvbgojCkNPTkZJR19ORVRGSUxURVJfTkVUTElOSz15CkNPTkZJR19ORVRG
SUxURVJfTkVUTElOS19BQ0NUPXkKQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFPXkK
Q09ORklHX05FVEZJTFRFUl9ORVRMSU5LX0xPRz15CkNPTkZJR19ORl9DT05OVFJBQ0s9eQpD
T05GSUdfTkZfQ09OTlRSQUNLX01BUks9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1NFQ01BUks9
eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NGUz15CkNPTkZJR19ORl9DT05OVFJBQ0tfRVZF
TlRTPXkKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RJTUVPVVQgaXMgbm90IHNldApDT05GSUdf
TkZfQ09OTlRSQUNLX1RJTUVTVEFNUD15CiMgQ09ORklHX05GX0NUX1BST1RPX0RDQ1AgaXMg
bm90IHNldApDT05GSUdfTkZfQ1RfUFJPVE9fR1JFPXkKIyBDT05GSUdfTkZfQ1RfUFJPVE9f
U0NUUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NUX1BST1RPX1VEUExJVEUgaXMgbm90IHNl
dAojIENPTkZJR19ORl9DT05OVFJBQ0tfQU1BTkRBIGlzIG5vdCBzZXQKQ09ORklHX05GX0NP
Tk5UUkFDS19GVFA9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0gzMjM9eQpDT05GSUdfTkZfQ09O
TlRSQUNLX0lSQz15CiMgQ09ORklHX05GX0NPTk5UUkFDS19ORVRCSU9TX05TIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NOTVAgaXMgbm90IHNldApDT05GSUdfTkZfQ09O
TlRSQUNLX1BQVFA9eQojIENPTkZJR19ORl9DT05OVFJBQ0tfU0FORSBpcyBub3Qgc2V0CkNP
TkZJR19ORl9DT05OVFJBQ0tfU0lQPXkKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RGVFAgaXMg
bm90IHNldApDT05GSUdfTkZfQ1RfTkVUTElOSz15CiMgQ09ORklHX05GX0NUX05FVExJTktf
VElNRU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFX0NU
IGlzIG5vdCBzZXQKQ09ORklHX05GX05BVD15CkNPTkZJR19ORl9OQVRfTkVFREVEPXkKIyBD
T05GSUdfTkZfTkFUX0FNQU5EQSBpcyBub3Qgc2V0CkNPTkZJR19ORl9OQVRfRlRQPXkKQ09O
RklHX05GX05BVF9JUkM9eQpDT05GSUdfTkZfTkFUX1NJUD15CiMgQ09ORklHX05GX05BVF9U
RlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1RQUk9YWSBpcyBub3Qgc2V0CkNP
TkZJR19ORVRGSUxURVJfWFRBQkxFUz15CgojCiMgWHRhYmxlcyBjb21iaW5lZCBtb2R1bGVz
CiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9DT05O
TUFSSz15CiMgQ09ORklHX05FVEZJTFRFUl9YVF9TRVQgaXMgbm90IHNldAoKIwojIFh0YWJs
ZXMgdGFyZ2V0cwojCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0FVRElUPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfQ0hFQ0tTVU09eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9DTEFTU0lGWT15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5NQVJLPXkK
Q09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ09OTlNFQ01BUks9eQojIENPTkZJR19ORVRG
SUxURVJfWFRfVEFSR0VUX0NUIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJH
RVRfRFNDUD15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0hMPXkKIyBDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9ITUFSSyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfWFRf
VEFSR0VUX0lETEVUSU1FUj15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0xPRz15CkNP
TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX1RB
UkdFVF9ORVRNQVA9eQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORkxPRz15CkNPTkZJ
R19ORVRGSUxURVJfWFRfVEFSR0VUX05GUVVFVUU9eQojIENPTkZJR19ORVRGSUxURVJfWFRf
VEFSR0VUX05PVFJBQ0sgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9S
QVRFRVNUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfUkVESVJFQ1Q9eQpDT05GSUdf
TkVURklMVEVSX1hUX1RBUkdFVF9URUU9eQojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU
X1RSQUNFIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfU0VDTUFSSz15
CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RDUE1TUz15CiMgQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfVENQT1BUU1RSSVAgaXMgbm90IHNldAoKIwojIFh0YWJsZXMgbWF0Y2hl
cwojCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQUREUlRZUEU9eQojIENPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfQlBGIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRD
SF9DTFVTVEVSPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9DT05OQllURVM9eQojIENPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfQ09OTkxBQkVMIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9D
T05OTElNSVQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5NQVJLPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJBQ0s9eQpDT05GSUdfTkVURklMVEVSX1hUX01B
VENIX0NQVT15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRENDUD15CkNPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RT
Q1A9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VDTj15CkNPTkZJR19ORVRGSUxURVJf
WFRfTUFUQ0hfRVNQPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQ9eQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0hFTFBFUj15CkNPTkZJR19ORVRGSUxURVJfWFRf
TUFUQ0hfSEw9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0U9eQpDT05GSUdf
TkVURklMVEVSX1hUX01BVENIX0lQVlM9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xF
TkdUSD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTElNSVQ9eQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX01BQz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz15CkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTVVMVElQT1JUPXkKQ09ORklHX05FVEZJTFRFUl9Y
VF9NQVRDSF9ORkFDQ1Q9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09TRj15CkNPTkZJ
R19ORVRGSUxURVJfWFRfTUFUQ0hfT1dORVI9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI
X1BIWVNERVY9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEU9eQpDT05GSUdf
TkVURklMVEVSX1hUX01BVENIX1FVT1RBPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9S
QVRFRVNUPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SRUFMTT15CkNPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfUkVDRU5UPXkKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1ND
VFAgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRFPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9TVEFUSVNUSUM9eQpDT05GSUdfTkVURklMVEVSX1hUX01B
VENIX1NUUklORz15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVENQTVNTPXkKQ09ORklH
X05FVEZJTFRFUl9YVF9NQVRDSF9USU1FPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9V
MzI9eQpDT05GSUdfSVBfU0VUPXkKQ09ORklHX0lQX1NFVF9NQVg9MjU2CkNPTkZJR19JUF9T
RVRfQklUTUFQX0lQPXkKQ09ORklHX0lQX1NFVF9CSVRNQVBfSVBNQUM9eQpDT05GSUdfSVBf
U0VUX0JJVE1BUF9QT1JUPXkKQ09ORklHX0lQX1NFVF9IQVNIX0lQPXkKQ09ORklHX0lQX1NF
VF9IQVNIX0lQUE9SVD15CkNPTkZJR19JUF9TRVRfSEFTSF9JUFBPUlRJUD15CkNPTkZJR19J
UF9TRVRfSEFTSF9JUFBPUlRORVQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUPXkKQ09ORklH
X0lQX1NFVF9IQVNIX05FVFBPUlQ9eQpDT05GSUdfSVBfU0VUX0hBU0hfTkVUSUZBQ0U9eQpD
T05GSUdfSVBfU0VUX0xJU1RfU0VUPXkKQ09ORklHX0lQX1ZTPXkKIyBDT05GSUdfSVBfVlNf
REVCVUcgaXMgbm90IHNldApDT05GSUdfSVBfVlNfVEFCX0JJVFM9MTIKCiMKIyBJUFZTIHRy
YW5zcG9ydCBwcm90b2NvbCBsb2FkIGJhbGFuY2luZyBzdXBwb3J0CiMKIyBDT05GSUdfSVBf
VlNfUFJPVE9fVENQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fVURQIGlzIG5v
dCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fQUhfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdf
SVBfVlNfUFJPVE9fRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfUFJPVE9fQUggaXMg
bm90IHNldAojIENPTkZJR19JUF9WU19QUk9UT19TQ1RQIGlzIG5vdCBzZXQKCiMKIyBJUFZT
IHNjaGVkdWxlcgojCiMgQ09ORklHX0lQX1ZTX1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBf
VlNfV1JSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTEMgaXMgbm90IHNldAojIENPTkZJ
R19JUF9WU19XTEMgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19MQkxDIGlzIG5vdCBzZXQK
IyBDT05GSUdfSVBfVlNfTEJMQ1IgaXMgbm90IHNldAojIENPTkZJR19JUF9WU19ESCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lQX1ZTX1NIIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfU0VE
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlNfTlEgaXMgbm90IHNldAoKIwojIElQVlMgU0gg
c2NoZWR1bGVyCiMKQ09ORklHX0lQX1ZTX1NIX1RBQl9CSVRTPTgKCiMKIyBJUFZTIGFwcGxp
Y2F0aW9uIGhlbHBlcgojCkNPTkZJR19JUF9WU19ORkNUPXkKCiMKIyBJUDogTmV0ZmlsdGVy
IENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05GSUdfTkZfQ09O
TlRSQUNLX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkKIyBDT05G
SUdfSVBfTkZfUVVFVUUgaXMgbm90IHNldApDT05GSUdfSVBfTkZfSVBUQUJMRVM9eQpDT05G
SUdfSVBfTkZfTUFUQ0hfQUg9eQpDT05GSUdfSVBfTkZfTUFUQ0hfRUNOPXkKIyBDT05GSUdf
SVBfTkZfTUFUQ0hfUlBGSUxURVIgaXMgbm90IHNldApDT05GSUdfSVBfTkZfTUFUQ0hfVFRM
PXkKQ09ORklHX0lQX05GX0ZJTFRFUj15CkNPTkZJR19JUF9ORl9UQVJHRVRfUkVKRUNUPXkK
Q09ORklHX0lQX05GX1RBUkdFVF9VTE9HPXkKQ09ORklHX05GX05BVF9JUFY0PXkKQ09ORklH
X0lQX05GX1RBUkdFVF9NQVNRVUVSQURFPXkKQ09ORklHX0lQX05GX1RBUkdFVF9ORVRNQVA9
eQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFRElSRUNUPXkKQ09ORklHX05GX05BVF9QUk9UT19H
UkU9eQpDT05GSUdfTkZfTkFUX1BQVFA9eQpDT05GSUdfTkZfTkFUX0gzMjM9eQpDT05GSUdf
SVBfTkZfTUFOR0xFPXkKIyBDT05GSUdfSVBfTkZfVEFSR0VUX0NMVVNURVJJUCBpcyBub3Qg
c2V0CiMgQ09ORklHX0lQX05GX1RBUkdFVF9FQ04gaXMgbm90IHNldAojIENPTkZJR19JUF9O
Rl9UQVJHRVRfVFRMIGlzIG5vdCBzZXQKQ09ORklHX0lQX05GX1JBVz15CiMgQ09ORklHX0lQ
X05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0CkNPTkZJR19CUklER0VfTkZfRUJUQUJMRVM9eQoj
IENPTkZJR19CUklER0VfRUJUX0JST1VURSBpcyBub3Qgc2V0CiMgQ09ORklHX0JSSURHRV9F
QlRfVF9GSUxURVIgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1RfTkFUIGlzIG5v
dCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF84MDJfMyBpcyBub3Qgc2V0CiMgQ09ORklHX0JS
SURHRV9FQlRfQU1PTkcgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX0FSUCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JSSURHRV9FQlRfSVAgaXMgbm90IHNldAojIENPTkZJR19CUklE
R0VfRUJUX0xJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9NQVJLIGlzIG5v
dCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9QS1RUWVBFIGlzIG5vdCBzZXQKIyBDT05GSUdf
QlJJREdFX0VCVF9TVFAgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1ZMQU4gaXMg
bm90IHNldAojIENPTkZJR19CUklER0VfRUJUX0FSUFJFUExZIGlzIG5vdCBzZXQKIyBDT05G
SUdfQlJJREdFX0VCVF9ETkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VCVF9NQVJL
X1QgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1JFRElSRUNUIGlzIG5vdCBzZXQK
IyBDT05GSUdfQlJJREdFX0VCVF9TTkFUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX0VC
VF9MT0cgaXMgbm90IHNldAojIENPTkZJR19CUklER0VfRUJUX1VMT0cgaXMgbm90IHNldAoj
IENPTkZJR19CUklER0VfRUJUX05GTE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfRENDUCBp
cyBub3Qgc2V0CiMgQ09ORklHX0lQX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19SRFMgaXMg
bm90IHNldAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9eQpDT05GSUdfQlJJREdF
PXkKQ09ORklHX0JSSURHRV9JR01QX1NOT09QSU5HPXkKQ09ORklHX0hBVkVfTkVUX0RTQT15
CiMgQ09ORklHX1ZMQU5fODAyMVEgaXMgbm90IHNldAojIENPTkZJR19ERUNORVQgaXMgbm90
IHNldApDT05GSUdfTExDPXkKIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQ
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBDT05GSUdfWDI1IGlz
IG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklHX1BIT05FVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lFRUU4MDIxNTQgaXMgbm90IHNldApDT05GSUdfTkVUX1NDSEVE
PXkKCiMKIyBRdWV1ZWluZy9TY2hlZHVsaW5nCiMKIyBDT05GSUdfTkVUX1NDSF9DQlEgaXMg
bm90IHNldAojIENPTkZJR19ORVRfU0NIX0hUQiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9T
Q0hfSEZTQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUFJJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9TQ0hfTVVMVElRIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9SRUQg
aXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX1NGQiBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VF9TQ0hfU0ZRIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9URVFMIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1NDSF9UQkYgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0dSRUQg
aXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0RTTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9TQ0hfTkVURU0gaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0RSUiBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9TQ0hfTVFQUklPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ND
SF9DSE9LRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfUUZRIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1NDSF9DT0RFTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hfRlFfQ09E
RUwgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0NIX0lOR1JFU1MgaXMgbm90IHNldAojIENP
TkZJR19ORVRfU0NIX1BMVUcgaXMgbm90IHNldAoKIwojIENsYXNzaWZpY2F0aW9uCiMKQ09O
RklHX05FVF9DTFM9eQojIENPTkZJR19ORVRfQ0xTX0JBU0lDIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0NMU19UQ0lOREVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19ST1VURTQg
aXMgbm90IHNldAojIENPTkZJR19ORVRfQ0xTX0ZXIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X0NMU19VMzIgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0xTX1JTVlAgaXMgbm90IHNldAoj
IENPTkZJR19ORVRfQ0xTX1JTVlA2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19GTE9X
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0NMU19DR1JPVVAgaXMgbm90IHNldApDT05GSUdf
TkVUX0VNQVRDSD15CkNPTkZJR19ORVRfRU1BVENIX1NUQUNLPTMyCiMgQ09ORklHX05FVF9F
TUFUQ0hfQ01QIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0VNQVRDSF9OQllURSBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9FTUFUQ0hfVTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0VN
QVRDSF9NRVRBIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0VNQVRDSF9URVhUIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTkVUX0VNQVRDSF9JUFNFVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfQ0xT
X0FDVD15CiMgQ09ORklHX05FVF9BQ1RfUE9MSUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU
X0FDVF9HQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0FDVF9NSVJSRUQgaXMgbm90IHNl
dAojIENPTkZJR19ORVRfQUNUX0lQVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfTkFU
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0FDVF9QRURJVCBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9BQ1RfU0lNUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfU0tCRURJVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9BQ1RfQ1NVTSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfU0NI
X0ZJRk89eQojIENPTkZJR19EQ0IgaXMgbm90IHNldAojIENPTkZJR19ETlNfUkVTT0xWRVIg
aXMgbm90IHNldAojIENPTkZJR19CQVRNQU5fQURWIGlzIG5vdCBzZXQKIyBDT05GSUdfT1BF
TlZTV0lUQ0ggaXMgbm90IHNldAojIENPTkZJR19WU09DS0VUUyBpcyBub3Qgc2V0CkNPTkZJ
R19SUFM9eQpDT05GSUdfUkZTX0FDQ0VMPXkKQ09ORklHX1hQUz15CiMgQ09ORklHX05FVFBS
SU9fQ0dST1VQIGlzIG5vdCBzZXQKQ09ORklHX0JRTD15CiMgQ09ORklHX0JQRl9KSVQgaXMg
bm90IHNldAoKIwojIE5ldHdvcmsgdGVzdGluZwojCiMgQ09ORklHX05FVF9QS1RHRU4gaXMg
bm90IHNldAojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldApDT05GSUdfQlQ9eQpDT05GSUdfQlRf
UkZDT01NPXkKQ09ORklHX0JUX1JGQ09NTV9UVFk9eQpDT05GSUdfQlRfQk5FUD15CkNPTkZJ
R19CVF9CTkVQX01DX0ZJTFRFUj15CkNPTkZJR19CVF9CTkVQX1BST1RPX0ZJTFRFUj15CkNP
TkZJR19CVF9ISURQPXkKCiMKIyBCbHVldG9vdGggZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdf
QlRfSENJQlRVU0I9eQpDT05GSUdfQlRfSENJVUFSVD15CkNPTkZJR19CVF9IQ0lVQVJUX0g0
PXkKQ09ORklHX0JUX0hDSVVBUlRfQkNTUD15CkNPTkZJR19CVF9IQ0lVQVJUX0FUSDNLPXkK
Q09ORklHX0JUX0hDSVVBUlRfTEw9eQpDT05GSUdfQlRfSENJVUFSVF8zV0lSRT15CkNPTkZJ
R19CVF9IQ0lCQ00yMDNYPXkKQ09ORklHX0JUX0hDSUJQQTEwWD15CkNPTkZJR19CVF9IQ0lC
RlVTQj15CkNPTkZJR19CVF9IQ0lWSENJPXkKQ09ORklHX0JUX01SVkw9eQpDT05GSUdfQlRf
QVRIM0s9eQojIENPTkZJR19BRl9SWFJQQyBpcyBub3Qgc2V0CkNPTkZJR19GSUJfUlVMRVM9
eQpDT05GSUdfV0lSRUxFU1M9eQojIENPTkZJR19DRkc4MDIxMSBpcyBub3Qgc2V0CiMgQ09O
RklHX0xJQjgwMjExIGlzIG5vdCBzZXQKCiMKIyBDRkc4MDIxMSBuZWVkcyB0byBiZSBlbmFi
bGVkIGZvciBNQUM4MDIxMQojCiMgQ09ORklHX1dJTUFYIGlzIG5vdCBzZXQKIyBDT05GSUdf
UkZLSUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUXzlQIGlzIG5vdCBzZXQKIyBDT05GSUdf
Q0FJRiBpcyBub3Qgc2V0CkNPTkZJR19DRVBIX0xJQj15CiMgQ09ORklHX0NFUEhfTElCX1BS
RVRUWURFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUJfVVNFX0ROU19SRVNPTFZF
UiBpcyBub3Qgc2V0CiMgQ09ORklHX05GQyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0JQRl9K
SVQ9eQoKIwojIERldmljZSBEcml2ZXJzCiMKCiMKIyBHZW5lcmljIERyaXZlciBPcHRpb25z
CiMKQ09ORklHX1VFVkVOVF9IRUxQRVJfUEFUSD0iL3NiaW4vaG90cGx1ZyIKQ09ORklHX0RF
VlRNUEZTPXkKQ09ORklHX0RFVlRNUEZTX01PVU5UPXkKIyBDT05GSUdfU1RBTkRBTE9ORSBp
cyBub3Qgc2V0CiMgQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJTEQgaXMgbm90IHNldApD
T05GSUdfRldfTE9BREVSPXkKQ09ORklHX0ZJUk1XQVJFX0lOX0tFUk5FTD15CkNPTkZJR19F
WFRSQV9GSVJNV0FSRT0iIgpDT05GSUdfRldfTE9BREVSX1VTRVJfSEVMUEVSPXkKQ09ORklH
X0RFQlVHX0RSSVZFUj15CkNPTkZJR19ERUJVR19ERVZSRVM9eQpDT05GSUdfU1lTX0hZUEVS
VklTT1I9eQojIENPTkZJR19HRU5FUklDX0NQVV9ERVZJQ0VTIGlzIG5vdCBzZXQKQ09ORklH
X0RNQV9TSEFSRURfQlVGRkVSPXkKCiMKIyBCdXMgZGV2aWNlcwojCkNPTkZJR19DT05ORUNU
T1I9eQpDT05GSUdfUFJPQ19FVkVOVFM9eQojIENPTkZJR19NVEQgaXMgbm90IHNldAojIENP
TkZJR19QQVJQT1JUIGlzIG5vdCBzZXQKQ09ORklHX1BOUD15CkNPTkZJR19QTlBfREVCVUdf
TUVTU0FHRVM9eQoKIwojIFByb3RvY29scwojCkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JM
S19ERVY9eQojIENPTkZJR19CTEtfREVWX0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF
Vl9QQ0lFU1NEX01USVAzMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JM
S19ERVZfREFDOTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9VTUVNIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E
RVZfTE9PUD15CkNPTkZJR19CTEtfREVWX0xPT1BfTUlOX0NPVU5UPTgKIyBDT05GSUdfQkxL
X0RFVl9DUllQVE9MT09QIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9EUkJEIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVW
X05WTUUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NYOCBpcyBub3Qgc2V0CkNPTkZJ
R19CTEtfREVWX1JBTT15CkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfQkxL
X0RFVl9SQU1fU0laRT0xNjM4NAojIENPTkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CiMg
Q09ORklHX0NEUk9NX1BLVENEVkQgaXMgbm90IHNldAojIENPTkZJR19BVEFfT1ZFUl9FVEgg
aXMgbm90IHNldApDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxL
REVWX0JBQ0tFTkQ9eQojIENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkxLX0RFVl9SQkQgaXMgbm90IHNldAoKIwojIE1pc2MgZGV2aWNlcwojCiMgQ09ORklHX1NF
TlNPUlNfTElTM0xWMDJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90
IHNldAojIENPTkZJR19JQk1fQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBu
b3Qgc2V0CiMgQ09ORklHX0lOVEVMX01JRF9QVEkgaXMgbm90IHNldAojIENPTkZJR19TR0lf
SU9DNCBpcyBub3Qgc2V0CiMgQ09ORklHX1RJRk1fQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklH
X0lDUzkzMlM0MDEgaXMgbm90IHNldAojIENPTkZJR19BVE1FTF9TU0MgaXMgbm90IHNldAoj
IENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldAojIENPTkZJR19IUF9JTE8g
aXMgbm90IHNldAojIENPTkZJR19BUERTOTgwMkFMUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lT
TDI5MDAzIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNldAojIENPTkZJ
R19TRU5TT1JTX1RTTDI1NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc4MCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19BUERTOTkwWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90IHNl
dAojIENPTkZJR19EUzE2ODIgaXMgbm90IHNldAojIENPTkZJR19WTVdBUkVfQkFMTE9PTiBp
cyBub3Qgc2V0CiMgQ09ORklHX0JNUDA4NV9JMkMgaXMgbm90IHNldAojIENPTkZJR19QQ0hf
UEhVQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TV0lUQ0hfRlNBOTQ4MCBpcyBub3Qgc2V0
CiMgQ09ORklHX0MyUE9SVCBpcyBub3Qgc2V0CgojCiMgRUVQUk9NIHN1cHBvcnQKIwojIENP
TkZJR19FRVBST01fQVQyNCBpcyBub3Qgc2V0CiMgQ09ORklHX0VFUFJPTV9MRUdBQ1kgaXMg
bm90IHNldAojIENPTkZJR19FRVBST01fTUFYNjg3NSBpcyBub3Qgc2V0CiMgQ09ORklHX0VF
UFJPTV85M0NYNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NCNzEwX0NPUkUgaXMgbm90IHNldAoK
IwojIFRleGFzIEluc3RydW1lbnRzIHNoYXJlZCB0cmFuc3BvcnQgbGluZSBkaXNjaXBsaW5l
CiMKIyBDT05GSUdfU0VOU09SU19MSVMzX0kyQyBpcyBub3Qgc2V0CgojCiMgQWx0ZXJhIEZQ
R0EgZmlybXdhcmUgZG93bmxvYWQgbW9kdWxlCiMKQ09ORklHX0FMVEVSQV9TVEFQTD15CiMg
Q09ORklHX0lOVEVMX01FSSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNV0FSRV9WTUNJIGlzIG5v
dCBzZXQKQ09ORklHX0hBVkVfSURFPXkKIyBDT05GSUdfSURFIGlzIG5vdCBzZXQKCiMKIyBT
Q1NJIGRldmljZSBzdXBwb3J0CiMKQ09ORklHX1NDU0lfTU9EPXkKIyBDT05GSUdfUkFJRF9B
VFRSUyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJPXkKQ09ORklHX1NDU0lfRE1BPXkKIyBDT05G
SUdfU0NTSV9UR1QgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX05FVExJTksgaXMgbm90IHNl
dApDT05GSUdfU0NTSV9QUk9DX0ZTPXkKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywg
dGFwZSwgQ0QtUk9NKQojCkNPTkZJR19CTEtfREVWX1NEPXkKIyBDT05GSUdfQ0hSX0RFVl9T
VCBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0CkNPTkZJR19C
TEtfREVWX1NSPXkKQ09ORklHX0JMS19ERVZfU1JfVkVORE9SPXkKQ09ORklHX0NIUl9ERVZf
U0c9eQojIENPTkZJR19DSFJfREVWX1NDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTVVM
VElfTFVOIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfQ09OU1RBTlRTPXkKIyBDT05GSUdfU0NT
SV9MT0dHSU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQ0FOX0FTWU5DIGlzIG5vdCBz
ZXQKCiMKIyBTQ1NJIFRyYW5zcG9ydHMKIwpDT05GSUdfU0NTSV9TUElfQVRUUlM9eQojIENP
TkZJR19TQ1NJX0ZDX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JU0NTSV9BVFRS
UyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0FTX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0NTSV9TQVNfTElCU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TUlBfQVRUUlMg
aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0xPV0xFVkVMIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0NTSV9ESCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qg
c2V0CkNPTkZJR19BVEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApD
T05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9eQojIENPTkZJR19T
QVRBX1pQT0REIGlzIG5vdCBzZXQKQ09ORklHX1NBVEFfUE1QPXkKCiMKIyBDb250cm9sbGVy
cyB3aXRoIG5vbi1TRkYgbmF0aXZlIGludGVyZmFjZQojCkNPTkZJR19TQVRBX0FIQ0k9eQpD
T05GSUdfU0FUQV9BSENJX1BMQVRGT1JNPXkKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NBVEFfQUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NB
VEFfU0lMMjQgaXMgbm90IHNldAojIENPTkZJR19BVEFfU0ZGIGlzIG5vdCBzZXQKQ09ORklH
X01EPXkKIyBDT05GSUdfQkxLX0RFVl9NRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0RN
PXkKQ09ORklHX0RNX0RFQlVHPXkKQ09ORklHX0RNX0NSWVBUPXkKQ09ORklHX0RNX1NOQVBT
SE9UPXkKIyBDT05GSUdfRE1fVEhJTl9QUk9WSVNJT05JTkcgaXMgbm90IHNldApDT05GSUdf
RE1fTUlSUk9SPXkKIyBDT05GSUdfRE1fUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0xP
R19VU0VSU1BBQ0UgaXMgbm90IHNldApDT05GSUdfRE1fWkVSTz15CiMgQ09ORklHX0RNX01V
TFRJUEFUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQKIyBDT05G
SUdfRE1fVUVWRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfRE1fRkxBS0VZIGlzIG5vdCBzZXQK
IyBDT05GSUdfRE1fVkVSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFSR0VUX0NPUkUgaXMg
bm90IHNldAojIENPTkZJR19GVVNJT04gaXMgbm90IHNldAoKIwojIElFRUUgMTM5NCAoRmly
ZVdpcmUpIHN1cHBvcnQKIwojIENPTkZJR19GSVJFV0lSRSBpcyBub3Qgc2V0CiMgQ09ORklH
X0ZJUkVXSVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJR19JMk8gaXMgbm90IHNldAojIENP
TkZJR19NQUNJTlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJQ0VTPXkK
Q09ORklHX05FVF9DT1JFPXkKIyBDT05GSUdfQk9ORElORyBpcyBub3Qgc2V0CiMgQ09ORklH
X0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkVUX0ZDIGlzIG5vdCBzZXQKQ09ORklHX01JST15CiMgQ09ORklHX0lGQiBpcyBub3Qg
c2V0CiMgQ09ORklHX05FVF9URUFNIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDVkxBTiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1ZYTEFOIGlzIG5vdCBzZXQKQ09ORklHX05FVENPTlNPTEU9eQpD
T05GSUdfTkVUUE9MTD15CiMgQ09ORklHX05FVFBPTExfVFJBUCBpcyBub3Qgc2V0CkNPTkZJ
R19ORVRfUE9MTF9DT05UUk9MTEVSPXkKQ09ORklHX1RVTj15CkNPTkZJR19WRVRIPXkKIyBD
T05GSUdfQVJDTkVUIGlzIG5vdCBzZXQKCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJzCiMK
CiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJlIGRyaXZlcnMKIwojIENPTkZJ
R19ORVRfRFNBX01WODhFNlhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9EU0FfTVY4OEU2
MDYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTZYWFhfTkVFRF9QUFUgaXMg
bm90IHNldAojIENPTkZJR19ORVRfRFNBX01WODhFNjEzMSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9EU0FfTVY4OEU2MTIzXzYxXzY1IGlzIG5vdCBzZXQKQ09ORklHX0VUSEVSTkVUPXkK
IyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRP
Ul9BREFQVEVDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9BTFRFT04gaXMgbm90
IHNldAojIENPTkZJR19ORVRfVkVORE9SX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9W
RU5ET1JfQVRIRVJPUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfQ0FERU5DRT15CiMgQ09ORklH
X0FSTV9BVDkxX0VUSEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDQiBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9WRU5ET1JfQlJPQURDT00gaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX0JST0NBREUgaXMgbm90IHNldAojIENPTkZJR19ORVRfQ0FMWEVEQV9YR01BQyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfQ0hFTFNJTyBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9WRU5ET1JfQ0lTQ08gaXMgbm90IHNldAojIENPTkZJR19ETkVUIGlzIG5vdCBzZXQK
IyBDT05GSUdfTkVUX1ZFTkRPUl9ERUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9S
X0RMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9FTVVMRVggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfVkVORE9SX0VYQVIgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVO
RE9SX0hQIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfSU5URUw9eQojIENPTkZJR19F
MTAwIGlzIG5vdCBzZXQKQ09ORklHX0UxMDAwPXkKQ09ORklHX0UxMDAwRT15CkNPTkZJR19J
R0I9eQpDT05GSUdfSUdCX0hXTU9OPXkKQ09ORklHX0lHQlZGPXkKIyBDT05GSUdfSVhHQiBp
cyBub3Qgc2V0CiMgQ09ORklHX0lYR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVhHQkVWRiBp
cyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX0lQMTAwMCBp
cyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1Jf
TUFSVkVMTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfTUVMTEFOT1ggaXMgbm90
IHNldAojIENPTkZJR19ORVRfVkVORE9SX01JQ1JFTCBpcyBub3Qgc2V0CiMgQ09ORklHX05F
VF9WRU5ET1JfTVlSSSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZFQUxOWCBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9WRU5ET1JfTkFUU0VNSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9PS0kgaXMgbm90IHNl
dAojIENPTkZJR19FVEhPQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9QQUNLRVRfRU5HSU5F
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9RTE9HSUMgaXMgbm90IHNldApDT05G
SUdfTkVUX1ZFTkRPUl9SRUFMVEVLPXkKIyBDT05GSUdfODEzOUNQIGlzIG5vdCBzZXQKIyBD
T05GSUdfODEzOVRPTyBpcyBub3Qgc2V0CkNPTkZJR19SODE2OT15CiMgQ09ORklHX05FVF9W
RU5ET1JfUkRDIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU0VFUT15CkNPTkZJR19O
RVRfVkVORE9SX1NJTEFOPXkKIyBDT05GSUdfU0M5MjAzMSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9WRU5ET1JfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0ZDIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkVUX1ZFTkRPUl9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9T
VE1JQ1JPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TVU4gaXMgbm90IHNldAoj
IENPTkZJR19ORVRfVkVORE9SX1RFSFVUSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E
T1JfVEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1ZJQSBpcyBub3Qgc2V0CkNP
TkZJR19ORVRfVkVORE9SX1dJWk5FVD15CiMgQ09ORklHX1dJWk5FVF9XNTEwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMg
bm90IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9TQjEwMDAg
aXMgbm90IHNldApDT05GSUdfUEhZTElCPXkKCiMKIyBNSUkgUEhZIGRldmljZSBkcml2ZXJz
CiMKIyBDT05GSUdfQVQ4MDNYX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNRF9QSFkgaXMg
bm90IHNldAojIENPTkZJR19NQVJWRUxMX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0RBVklD
T01fUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfUVNFTUlfUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0NJQ0FEQV9QSFkgaXMgbm90IHNldAoj
IENPTkZJR19WSVRFU1NFX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0NfUEhZIGlzIG5v
dCBzZXQKIyBDT05GSUdfQlJPQURDT01fUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfQkNNODdY
WF9QSFkgaXMgbm90IHNldAojIENPTkZJR19JQ1BMVVNfUEhZIGlzIG5vdCBzZXQKQ09ORklH
X1JFQUxURUtfUEhZPXkKIyBDT05GSUdfTkFUSU9OQUxfUEhZIGlzIG5vdCBzZXQKIyBDT05G
SUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xTSV9FVDEwMTFDX1BIWSBpcyBub3Qg
c2V0CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNldAojIENPTkZJR19GSVhFRF9QSFkg
aXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcgaXMgbm90IHNldAojIENPTkZJR19Q
UFAgaXMgbm90IHNldAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBVU0IgTmV0d29y
ayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfVVNCTkVUIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0lQSEVUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1dMQU4gaXMg
bm90IHNldAoKIwojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0byBzZWUg
dGhlIFdpTUFYIGRyaXZlcnMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldApDT05GSUdfWEVO
X05FVERFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQojIENPTkZJ
R19WTVhORVQzIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CgojCiMgSW5w
dXQgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQpDT05GSUdfSU5QVVRfRkZfTUVN
TEVTUz15CkNPTkZJR19JTlBVVF9QT0xMREVWPXkKQ09ORklHX0lOUFVUX1NQQVJTRUtNQVA9
eQojIENPTkZJR19JTlBVVF9NQVRSSVhLTUFQIGlzIG5vdCBzZXQKCiMKIyBVc2VybGFuZCBp
bnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01PVVNFREVWPXkKIyBDT05GSUdfSU5QVVRfTU9V
U0VERVZfUFNBVVggaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9
MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4CiMgQ09ORklHX0lOUFVU
X0pPWURFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRFVj15CiMgQ09ORklHX0lOUFVU
X0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJpdmVycwojCkNPTkZJR19J
TlBVVF9LRVlCT0FSRD15CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODggaXMgbm90IHNldAoj
IENPTkZJR19LRVlCT0FSRF9BRFA1NTg5IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0FU
S0JEPXkKIyBDT05GSUdfS0VZQk9BUkRfUVQxMDcwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZ
Qk9BUkRfUVQyMTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTEtLQkQgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E2NDE2IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZ
Qk9BUkRfVENBODQxOCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMyMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0xNODMzMyBpcyBub3Qgc2V0CiMgQ09ORklHX0tF
WUJPQVJEX01BWDczNTkgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90
IHNldAojIENPTkZJR19LRVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldAojIENPTkZJR19LRVlC
T0FSRF9ORVdUT04gaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9PUEVOQ09SRVMgaXMg
bm90IHNldAojIENPTkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklH
X0tFWUJPQVJEX1NVTktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1hUS0JEIGlz
IG5vdCBzZXQKQ09ORklHX0lOUFVUX01PVVNFPXkKQ09ORklHX01PVVNFX1BTMj15CkNPTkZJ
R19NT1VTRV9QUzJfQUxQUz15CkNPTkZJR19NT1VTRV9QUzJfTE9HSVBTMlBQPXkKQ09ORklH
X01PVVNFX1BTMl9TWU5BUFRJQ1M9eQpDT05GSUdfTU9VU0VfUFMyX0NZUFJFU1M9eQpDT05G
SUdfTU9VU0VfUFMyX0xJRkVCT09LPXkKQ09ORklHX01PVVNFX1BTMl9UUkFDS1BPSU5UPXkK
IyBDT05GSUdfTU9VU0VfUFMyX0VMQU5URUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0Vf
UFMyX1NFTlRFTElDIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfUFMyX1RPVUNIS0lUIGlz
IG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfU0VSSUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9V
U0VfQVBQTEVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX0JDTTU5NzQgaXMgbm90
IHNldAojIENPTkZJR19NT1VTRV9DWUFQQSBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1ZT
WFhYQUEgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TWU5BUFRJQ1NfSTJDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTU9VU0VfU1lOQVBUSUNTX1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
UFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1RBQkxFVD15CiMgQ09ORklH
X1RBQkxFVF9VU0JfQUNFQ0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFCTEVUX1VTQl9BSVBU
RUsgaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRfVVNCX0dUQ08gaXMgbm90IHNldAojIENP
TkZJR19UQUJMRVRfVVNCX0hBTldBTkcgaXMgbm90IHNldAojIENPTkZJR19UQUJMRVRfVVNC
X0tCVEFCIGlzIG5vdCBzZXQKIyBDT05GSUdfVEFCTEVUX1VTQl9XQUNPTSBpcyBub3Qgc2V0
CkNPTkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FENzg3
OSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FUTUVMX01YVCBpcyBub3Qgc2V0
CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMTMgaXMgbm90IHNldAojIENPTkZJR19UT1VD
SFNDUkVFTl9DWVRUU1BfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0RZ
TkFQUk8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9IQU1QU0hJUkUgaXMgbm90
IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9FRVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V
Q0hTQ1JFRU5fRlVKSVRTVSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIx
MFggaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9HVU5aRSBpcyBub3Qgc2V0CiMg
Q09ORklHX1RPVUNIU0NSRUVOX0VMTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVO
X1dBQ09NX1c4MDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fV0FDT01fSTJD
IGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUFYMTE4MDEgaXMgbm90IHNldAoj
IENPTkZJR19UT1VDSFNDUkVFTl9NQ1M1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hT
Q1JFRU5fTU1TMTE0IGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTVRPVUNIIGlz
IG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fSU5FWElPIGlzIG5vdCBzZXQKIyBDT05G
SUdfVE9VQ0hTQ1JFRU5fTUs3MTIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9Q
RU5NT1VOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VEVF9GVDVYMDYgaXMg
bm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UT1VDSFJJR0hUIGlzIG5vdCBzZXQKIyBD
T05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hXSU4gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFND
UkVFTl9QSVhDSVIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9VU0JfQ09NUE9T
SVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hJVDIxMyBpcyBub3Qg
c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQ19TRVJJTyBpcyBub3Qgc2V0CiMgQ09ORklH
X1RPVUNIU0NSRUVOX1RTQzIwMDcgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9T
VDEyMzIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBpcyBub3Qg
c2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSU5QVVRfQk1BMTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUENT
UEtSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTU1BODQ1MCBpcyBub3Qgc2V0CiMgQ09O
RklHX0lOUFVUX01QVTMwNTAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BUEFORUwgaXMg
bm90IHNldAojIENPTkZJR19JTlBVVF9BVExBU19CVE5TIGlzIG5vdCBzZXQKIyBDT05GSUdf
SU5QVVRfQVRJX1JFTU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9LRVlTUEFOX1JF
TU9URSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0tYVEo5IGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5QVVRfUE9XRVJNQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfWUVBTElOSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNMTA5IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5Q
VVRfVUlOUFVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfUENGODU3NCBpcyBub3Qgc2V0
CiMgQ09ORklHX0lOUFVUX0FEWEwzNFggaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9DTUEz
MDAwIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1hFTl9LQkRERVZfRlJPTlRFTkQ9eQoKIwoj
IEhhcmR3YXJlIEkvTyBwb3J0cwojCkNPTkZJR19TRVJJTz15CkNPTkZJR19TRVJJT19JODA0
Mj15CkNPTkZJR19TRVJJT19TRVJQT1JUPXkKIyBDT05GSUdfU0VSSU9fQ1Q4MkM3MTAgaXMg
bm90IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldApDT05GSUdfU0VSSU9f
TElCUFMyPXkKIyBDT05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSU9f
QUxURVJBX1BTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BTMk1VTFQgaXMgbm90IHNl
dAojIENPTkZJR19TRVJJT19BUkNfUFMyIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlQg
aXMgbm90IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1RUWT15CkNPTkZJ
R19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15CkNPTkZJR19WVF9DT05TT0xF
PXkKQ09ORklHX1ZUX0NPTlNPTEVfU0xFRVA9eQpDT05GSUdfSFdfQ09OU09MRT15CkNPTkZJ
R19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5JWDk4X1BUWVM9eQojIENPTkZJ
R19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVHQUNZ
X1BUWVMgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkKIyBDT05GSUdf
Uk9DS0VUUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NZQ0xBREVTIGlzIG5vdCBzZXQKIyBD
T05GSUdfTU9YQV9JTlRFTExJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01PWEFfU01BUlRJTyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NZTkNMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJ
TktNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NZTkNMSU5LX0dUIGlzIG5vdCBzZXQKIyBDT05G
SUdfTk9aT01JIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNJIGlzIG5vdCBzZXQKIyBDT05GSUdf
Tl9IRExDIGlzIG5vdCBzZXQKIyBDT05GSUdfTl9HU00gaXMgbm90IHNldAojIENPTkZJR19U
UkFDRV9TSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfREVWS01FTSBpcyBub3Qgc2V0CiMgQ09O
RklHX1NUQUxEUlYgaXMgbm90IHNldAoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NF
UklBTF84MjUwPXkKQ09ORklHX1NFUklBTF84MjUwX1BOUD15CkNPTkZJR19TRVJJQUxfODI1
MF9DT05TT0xFPXkKQ09ORklHX0ZJWF9FQVJMWUNPTl9NRU09eQpDT05GSUdfU0VSSUFMXzgy
NTBfUENJPXkKQ09ORklHX1NFUklBTF84MjUwX05SX1VBUlRTPTMyCkNPTkZJR19TRVJJQUxf
ODI1MF9SVU5USU1FX1VBUlRTPTQKQ09ORklHX1NFUklBTF84MjUwX0VYVEVOREVEPXkKQ09O
RklHX1NFUklBTF84MjUwX01BTllfUE9SVFM9eQpDT05GSUdfU0VSSUFMXzgyNTBfU0hBUkVf
SVJRPXkKQ09ORklHX1NFUklBTF84MjUwX0RFVEVDVF9JUlE9eQpDT05GSUdfU0VSSUFMXzgy
NTBfUlNBPXkKIyBDT05GSUdfU0VSSUFMXzgyNTBfRFcgaXMgbm90IHNldAoKIwojIE5vbi04
MjUwIHNlcmlhbCBwb3J0IHN1cHBvcnQKIwojIENPTkZJR19TRVJJQUxfTUZEX0hTVSBpcyBu
b3Qgc2V0CkNPTkZJR19TRVJJQUxfQ09SRT15CkNPTkZJR19TRVJJQUxfQ09SRV9DT05TT0xF
PXkKIyBDT05GSUdfU0VSSUFMX0pTTSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9TQ0NO
WFAgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfVElNQkVSREFMRSBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFUklBTF9BTFRFUkFfSlRBR1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJ
QUxfQUxURVJBX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfUENIX1VBUlQgaXMg
bm90IHNldAojIENPTkZJR19TRVJJQUxfQVJDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFM
X1JQMiBpcyBub3Qgc2V0CkNPTkZJR19IVkNfRFJJVkVSPXkKQ09ORklHX0hWQ19JUlE9eQpD
T05GSUdfSFZDX1hFTj15CkNPTkZJR19IVkNfWEVOX0ZST05URU5EPXkKIyBDT05GSUdfSVBN
SV9IQU5ETEVSIGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT15CkNPTkZJR19IV19SQU5E
T01fVElNRVJJT01FTT15CkNPTkZJR19IV19SQU5ET01fSU5URUw9eQpDT05GSUdfSFdfUkFO
RE9NX0FNRD15CkNPTkZJR19IV19SQU5ET01fVklBPXkKIyBDT05GSUdfTlZSQU0gaXMgbm90
IHNldAojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5v
dCBzZXQKIyBDT05GSUdfTVdBVkUgaXMgbm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlz
IG5vdCBzZXQKQ09ORklHX0hQRVQ9eQojIENPTkZJR19IUEVUX01NQVAgaXMgbm90IHNldApD
T05GSUdfSEFOR0NIRUNLX1RJTUVSPXkKIyBDT05GSUdfVENHX1RQTSBpcyBub3Qgc2V0CiMg
Q09ORklHX1RFTENMT0NLIGlzIG5vdCBzZXQKQ09ORklHX0RFVlBPUlQ9eQpDT05GSUdfSTJD
PXkKQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdfSTJDX0NPTVBBVD15CiMgQ09ORklH
X0kyQ19DSEFSREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX01VWCBpcyBub3Qgc2V0CkNP
TkZJR19JMkNfSEVMUEVSX0FVVE89eQpDT05GSUdfSTJDX0FMR09CSVQ9eQoKIwojIEkyQyBI
YXJkd2FyZSBCdXMgc3VwcG9ydAojCgojCiMgUEMgU01CdXMgaG9zdCBjb250cm9sbGVyIGRy
aXZlcnMKIwojIENPTkZJR19JMkNfQUxJMTUzNSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19B
TEkxNTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1WDMgaXMgbm90IHNldApDT05G
SUdfSTJDX0FNRDc1Nj15CiMgQ09ORklHX0kyQ19BTUQ3NTZfUzQ4ODIgaXMgbm90IHNldApD
T05GSUdfSTJDX0FNRDgxMTE9eQpDT05GSUdfSTJDX0k4MDE9eQpDT05GSUdfSTJDX0lTQ0g9
eQpDT05GSUdfSTJDX1BJSVg0PXkKIyBDT05GSUdfSTJDX05GT1JDRTIgaXMgbm90IHNldAoj
IENPTkZJR19JMkNfU0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM2MzAgaXMg
bm90IHNldAojIENPTkZJR19JMkNfU0lTOTZYIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1ZJ
QSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19WSUFQUk8gaXMgbm90IHNldAoKIwojIEFDUEkg
ZHJpdmVycwojCkNPTkZJR19JMkNfU0NNST15CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVy
cyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0RF
U0lHTldBUkVfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VHMjBUIGlzIG5vdCBzZXQK
IyBDT05GSUdfSTJDX0lOVEVMX01JRCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19PQ09SRVMg
aXMgbm90IHNldAojIENPTkZJR19JMkNfUENBX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05G
SUdfSTJDX1BYQV9QQ0kgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0lNVEVDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSTJDX1hJTElOWCBpcyBub3Qgc2V0CgojCiMgRXh0ZXJuYWwgSTJDL1NN
QnVzIGFkYXB0ZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19ESU9MQU5fVTJDIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQgaXMgbm90IHNldAojIENPTkZJR19JMkNf
VEFPU19FVk0gaXMgbm90IHNldAojIENPTkZJR19JMkNfVElOWV9VU0IgaXMgbm90IHNldAoK
IwojIE90aGVyIEkyQy9TTUJ1cyBidXMgZHJpdmVycwojCiMgQ09ORklHX0kyQ19TVFVCIGlz
IG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19J
MkNfREVCVUdfQUxHTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMgbm90
IHNldAojIENPTkZJR19TUEkgaXMgbm90IHNldAojIENPTkZJR19IU0kgaXMgbm90IHNldAoK
IwojIFBQUyBzdXBwb3J0CiMKQ09ORklHX1BQUz15CiMgQ09ORklHX1BQU19ERUJVRyBpcyBu
b3Qgc2V0CgojCiMgUFBTIGNsaWVudHMgc3VwcG9ydAojCiMgQ09ORklHX1BQU19DTElFTlRf
S1RJTUVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBTX0NMSUVOVF9MRElTQyBpcyBub3Qgc2V0
CiMgQ09ORklHX1BQU19DTElFTlRfR1BJTyBpcyBub3Qgc2V0CgojCiMgUFBTIGdlbmVyYXRv
cnMgc3VwcG9ydAojCgojCiMgUFRQIGNsb2NrIHN1cHBvcnQKIwpDT05GSUdfUFRQXzE1ODhf
Q0xPQ0s9eQoKIwojIEVuYWJsZSBQSFlMSUIgYW5kIE5FVFdPUktfUEhZX1RJTUVTVEFNUElO
RyB0byBzZWUgdGhlIGFkZGl0aW9uYWwgY2xvY2tzLgojCiMgQ09ORklHX1BUUF8xNTg4X0NM
T0NLX1BDSCBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15
CiMgQ09ORklHX0dQSU9MSUIgaXMgbm90IHNldAojIENPTkZJR19XMSBpcyBub3Qgc2V0CkNP
TkZJR19QT1dFUl9TVVBQTFk9eQojIENPTkZJR19QT1dFUl9TVVBQTFlfREVCVUcgaXMgbm90
IHNldAojIENPTkZJR19QREFfUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19URVNUX1BPV0VS
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODAgaXMgbm90IHNldAojIENPTkZJ
R19CQVRURVJZX0RTMjc4MSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfRFMyNzgyIGlz
IG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9TQlMgaXMgbm90IHNldAojIENPTkZJR19CQVRU
RVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX01BWDE3MDQwIGlzIG5v
dCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBub3Qgc2V0CiMgQ09ORklHX0NI
QVJHRVJfTUFYODkwMyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTFA4NzI3IGlzIG5v
dCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9CUTI0MTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hB
UkdFUl9TTUIzNDcgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0dPTERGSVNIIGlzIG5v
dCBzZXQKIyBDT05GSUdfUE9XRVJfUkVTRVQgaXMgbm90IHNldAojIENPTkZJR19QT1dFUl9B
VlMgaXMgbm90IHNldApDT05GSUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPXkKIyBDT05G
SUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMKIwoj
IENPTkZJR19TRU5TT1JTX0FCSVRVR1VSVSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
QUJJVFVHVVJVMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19BRDc0MTggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FETTEwMjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjUgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FETTEwMjYgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FETTEwMjkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMzEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FETTkyNDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FEVDc0MTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0MTEgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FEVDc0NjIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0FEVDc0NzAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NzUgaXMgbm90IHNl
dAojIENPTkZJR19TRU5TT1JTX0FTQzc2MjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X0s4VEVNUCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0sxMFRFTVA9eQpDT05GSUdfU0VO
U09SU19GQU0xNUhfUE9XRVI9eQojIENPTkZJR19TRU5TT1JTX0FTQjEwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0RT
NjIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19EUzE2MjEgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX0k1S19BTUIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19GNzE4MDVG
PXkKQ09ORklHX1NFTlNPUlNfRjcxODgyRkc9eQpDT05GSUdfU0VOU09SU19GNzUzNzVTPXkK
IyBDT05GSUdfU0VOU09SU19GU0NITUQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0c3
NjBBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19ISUg2
MTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19DT1JFVEVNUCBpcyBub3Qgc2V0CkNP
TkZJR19TRU5TT1JTX0lUODc9eQpDT05GSUdfU0VOU09SU19KQzQyPXkKIyBDT05GSUdfU0VO
U09SU19MSU5FQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTYzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19MTTczIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19M
TTc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19MTTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S
U19MTTg1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg3IGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19MVEM0MTUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjE1IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19MVEM0MjYxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQxIGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTYxOSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTY2OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF
TlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjM5IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19NQVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2Njk3IGlzIG5v
dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO
U09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzM2
MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0CiMgQ09O
RklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CiMgQ09ORklHX1BNQlVTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
U0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19ETUUxNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19F
TUMxNDAzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMyMTAzIGlzIG5vdCBzZXQK
IyBDT05GSUdfU0VOU09SU19FTUM2VzIwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf
U01TQzQ3TTEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xOTIgaXMgbm90
IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N0IzOTcgaXMgbm90IHNldAojIENPTkZJR19T
RU5TT1JTX1NDSDU2WFhfQ09NTU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1
NjI3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NjM2IGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19BRFMxMDE1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFM3
ODI4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BTUM2ODIxIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0VOU09SU19JTkEyMDkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lOQTJY
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVEhNQzUwIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19UTVAxMDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RNUDQwMSBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVE1QNDIxIGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19WSUFfQ1BVVEVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBNjg2
QSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKIyBDT05G
SUdfU0VOU09SU19WVDgyMzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc4MUQg
aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5MUQgaXMgbm90IHNldAojIENPTkZJ
R19TRU5TT1JTX1c4Mzc5MkQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5MyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzNzk1IGlzIG5vdCBzZXQKIyBDT05GSUdf
U0VOU09SU19XODNMNzg1VFMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4M0w3ODZO
RyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzNjI3SEYgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX1c4MzYyN0VIRiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVBQ
TEVTTUMgaXMgbm90IHNldAoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19TRU5TT1JTX0FD
UElfUE9XRVI9eQojIENPTkZJR19TRU5TT1JTX0FUSzAxMTAgaXMgbm90IHNldApDT05GSUdf
VEhFUk1BTD15CkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxfREVGQVVM
VF9HT1ZfU1RFUF9XSVNFPXkKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9GQUlSX1NI
QVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9VU0VSX1NQQUNF
IGlzIG5vdCBzZXQKIyBDT05GSUdfRkFJUl9TSEFSRSBpcyBub3Qgc2V0CkNPTkZJR19TVEVQ
X1dJU0U9eQojIENPTkZJR19VU0VSX1NQQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX1RI
RVJNQUwgaXMgbm90IHNldApDT05GSUdfV0FUQ0hET0c9eQpDT05GSUdfV0FUQ0hET0dfQ09S
RT15CiMgQ09ORklHX1dBVENIRE9HX05PV0FZT1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRv
ZyBEZXZpY2UgRHJpdmVycwojCiMgQ09ORklHX1NPRlRfV0FUQ0hET0cgaXMgbm90IHNldAoj
IENPTkZJR19BQ1FVSVJFX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEVkFOVEVDSF9XRFQg
aXMgbm90IHNldAojIENPTkZJR19BTElNMTUzNV9XRFQgaXMgbm90IHNldAojIENPTkZJR19B
TElNNzEwMV9XRFQgaXMgbm90IHNldAojIENPTkZJR19GNzE4MDhFX1dEVCBpcyBub3Qgc2V0
CkNPTkZJR19TUDUxMDBfVENPPXkKIyBDT05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQKIyBD
T05GSUdfU0JDX0ZJVFBDMl9XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX0VVUk9URUNI
X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lCNzAwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklH
X0lCTUFTUiBpcyBub3Qgc2V0CiMgQ09ORklHX1dBRkVSX1dEVCBpcyBub3Qgc2V0CiMgQ09O
RklHX0k2MzAwRVNCX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lFNlhYX1dEVCBpcyBub3Qg
c2V0CiMgQ09ORklHX0lUQ09fV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfSVQ4NzEyRl9XRFQg
aXMgbm90IHNldAojIENPTkZJR19JVDg3X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQX1dB
VENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0MxMjAwX1dEVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTlZfVENPIGlzIG5vdCBzZXQK
IyBDT05GSUdfNjBYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19TQkM4MzYwX1dEVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NQVTVfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfU01TQ19TQ0gz
MTFYX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0MzN0I3ODdfV0RUIGlzIG5vdCBzZXQK
IyBDT05GSUdfVklBX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4MzYyN0hGX1dEVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1c4MzY5N0hGX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4MzY5
N1VHX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4Mzg3N0ZfV0RUIGlzIG5vdCBzZXQKIyBD
T05GSUdfVzgzOTc3Rl9XRFQgaXMgbm90IHNldAojIENPTkZJR19NQUNIWl9XRFQgaXMgbm90
IHNldAojIENPTkZJR19TQkNfRVBYX0MzX1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1hF
Tl9XRFQ9eQoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1BDSVBD
V0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19XRFRQQ0kgaXMgbm90IHNldAoKIwojIFVT
Qi1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1VTQlBDV0FUQ0hET0cgaXMgbm90
IHNldApDT05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxh
bmUKIwojIENPTkZJR19TU0IgaXMgbm90IHNldApDT05GSUdfQkNNQV9QT1NTSUJMRT15Cgoj
CiMgQnJvYWRjb20gc3BlY2lmaWMgQU1CQQojCiMgQ09ORklHX0JDTUEgaXMgbm90IHNldAoK
IwojIE11bHRpZnVuY3Rpb24gZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfTUZEX0NPUkU9eQoj
IENPTkZJR19NRkRfODhQTTg2MFggaXMgbm90IHNldAojIENPTkZJR19NRkRfODhQTTgwMCBp
cyBub3Qgc2V0CiMgQ09ORklHX01GRF84OFBNODA1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE
X1NNNTAxIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JUU1hfUENJIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUZEX1RJX0FNMzM1WF9UU0NBREMgaXMgbm90IHNldAojIENPTkZJR19IVENfUEFT
SUMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xNMzUzMyBpcyBub3Qgc2V0CiMgQ09ORklH
X1RQUzYxMDVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjUwN1ggaXMgbm90IHNldAojIENP
TkZJR19NRkRfVFBTNjUyMTcgaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjU4NlggaXMg
bm90IHNldAojIENPTkZJR19NRkRfVFBTODAwMzEgaXMgbm90IHNldAojIENPTkZJR19UV0w0
MDMwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19UV0w2MDQwX0NPUkUgaXMgbm90IHNldAoj
IENPTkZJR19NRkRfU1RNUEUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVEMzNTg5WCBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1NNU0Mg
aXMgbm90IHNldAojIENPTkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9EQTkwNTJfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1NSBpcyBub3Qgc2V0
CiMgQ09ORklHX1BNSUNfQURQNTUyMCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9MUDg3ODgg
aXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYNzc2ODYgaXMgbm90IHNldAojIENPTkZJR19N
RkRfTUFYNzc2OTMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODkwNyBpcyBub3Qgc2V0
CiMgQ09ORklHX01GRF9NQVg4OTI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX01BWDg5OTcg
aXMgbm90IHNldAojIENPTkZJR19NRkRfTUFYODk5OCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9TRUNfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9BUklaT05BX0kyQyBpcyBub3Qg
c2V0CiMgQ09ORklHX01GRF9XTTg0MDAgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004MzFY
X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzNTBfSTJDIGlzIG5vdCBzZXQKIyBD
T05GSUdfTUZEX1dNODk5NCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9QQ0Y1MDYzMyBpcyBu
b3Qgc2V0CiMgQ09ORklHX01GRF9NQzEzWFhYX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0FC
WDUwMF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NTNTUzNSBpcyBub3Qgc2V0CkNP
TkZJR19MUENfU0NIPXkKIyBDT05GSUdfTFBDX0lDSCBpcyBub3Qgc2V0CiMgQ09ORklHX01G
RF9SREMzMjFYIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0pBTlpfQ01PRElPIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUZEX1ZYODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1dMMTI3M19D
T1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1MDkwIGlzIG5vdCBzZXQKIyBDT05G
SUdfTUZEX1JDNVQ1ODMgaXMgbm90IHNldAojIENPTkZJR19NRkRfUEFMTUFTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTUZEX1ZJUEVSQk9BUkQgaXMgbm90IHNldAojIENPTkZJR19NRkRfUkVU
VSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9BUzM3MTEgaXMgbm90IHNldAojIENPTkZJR19S
RUdVTEFUT1IgaXMgbm90IHNldApDT05GSUdfTUVESUFfU1VQUE9SVD15CgojCiMgTXVsdGlt
ZWRpYSBjb3JlIHN1cHBvcnQKIwpDT05GSUdfTUVESUFfQ0FNRVJBX1NVUFBPUlQ9eQpDT05G
SUdfTUVESUFfQU5BTE9HX1RWX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfRElHSVRBTF9UVl9T
VVBQT1JUPXkKQ09ORklHX01FRElBX1JBRElPX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfUkNf
U1VQUE9SVD15CiMgQ09ORklHX01FRElBX0NPTlRST0xMRVIgaXMgbm90IHNldApDT05GSUdf
VklERU9fREVWPXkKQ09ORklHX1ZJREVPX1Y0TDI9eQpDT05GSUdfVklERU9fQURWX0RFQlVH
PXkKIyBDT05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBzZXQKQ09ORklH
X1ZJREVPX1RVTkVSPXkKQ09ORklHX1ZJREVPQlVGX0dFTj15CkNPTkZJR19WSURFT0JVRl9E
TUFfU0c9eQpDT05GSUdfVklERU9CVUZfRFZCPXkKIyBDT05GSUdfVklERU9fVjRMMl9JTlRf
REVWSUNFIGlzIG5vdCBzZXQKQ09ORklHX0RWQl9DT1JFPXkKQ09ORklHX0RWQl9ORVQ9eQoj
IENPTkZJR19UVFBDSV9FRVBST00gaXMgbm90IHNldApDT05GSUdfRFZCX01BWF9BREFQVEVS
Uz04CiMgQ09ORklHX0RWQl9EWU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0CgojCiMgTWVkaWEg
ZHJpdmVycwojCkNPTkZJR19SQ19DT1JFPXkKQ09ORklHX1JDX01BUD15CkNPTkZJR19SQ19E
RUNPREVSUz15CkNPTkZJR19MSVJDPXkKQ09ORklHX0lSX0xJUkNfQ09ERUM9eQpDT05GSUdf
SVJfTkVDX0RFQ09ERVI9eQpDT05GSUdfSVJfUkM1X0RFQ09ERVI9eQpDT05GSUdfSVJfUkM2
X0RFQ09ERVI9eQpDT05GSUdfSVJfSlZDX0RFQ09ERVI9eQpDT05GSUdfSVJfU09OWV9ERUNP
REVSPXkKQ09ORklHX0lSX1JDNV9TWl9ERUNPREVSPXkKQ09ORklHX0lSX1NBTllPX0RFQ09E
RVI9eQpDT05GSUdfSVJfTUNFX0tCRF9ERUNPREVSPXkKIyBDT05GSUdfUkNfREVWSUNFUyBp
cyBub3Qgc2V0CkNPTkZJR19NRURJQV9VU0JfU1VQUE9SVD15CgojCiMgV2ViY2FtIGRldmlj
ZXMKIwojIENPTkZJR19VU0JfVklERU9fQ0xBU1MgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
R1NQQ0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfUFdDIGlzIG5vdCBzZXQKIyBDT05GSUdf
VklERU9fQ1BJQTIgaXMgbm90IHNldAojIENPTkZJR19VU0JfWlIzNjRYWCBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TVEtXRUJDQU0gaXMgbm90IHNldAojIENPTkZJR19VU0JfUzIyNTUg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU045QzEwMiBpcyBub3Qgc2V0CgojCiMgQW5hbG9n
IFRWIFVTQiBkZXZpY2VzCiMKQ09ORklHX1ZJREVPX1BWUlVTQjI9eQpDT05GSUdfVklERU9f
UFZSVVNCMl9TWVNGUz15CkNPTkZJR19WSURFT19QVlJVU0IyX0RWQj15CiMgQ09ORklHX1ZJ
REVPX1BWUlVTQjJfREVCVUdJRkMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRFBWUiBp
cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RMRzIzMDAgaXMgbm90IHNldAojIENPTkZJR19W
SURFT19VU0JWSVNJT04gaXMgbm90IHNldAojIENPTkZJR19WSURFT19TVEsxMTYwIGlzIG5v
dCBzZXQKCiMKIyBBbmFsb2cvZGlnaXRhbCBUViBVU0IgZGV2aWNlcwojCiMgQ09ORklHX1ZJ
REVPX0FVMDgyOCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NYMjMxWFggaXMgbm90IHNl
dAojIENPTkZJR19WSURFT19UTTYwMDAgaXMgbm90IHNldAoKIwojIERpZ2l0YWwgVFYgVVNC
IGRldmljZXMKIwojIENPTkZJR19EVkJfVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX1VT
Ql9WMiBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9UVFVTQl9CVURHRVQgaXMgbm90IHNldAoj
IENPTkZJR19EVkJfVFRVU0JfREVDIGlzIG5vdCBzZXQKIyBDT05GSUdfU01TX1VTQl9EUlYg
aXMgbm90IHNldAojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09QX1VTQiBpcyBub3Qgc2V0Cgoj
CiMgV2ViY2FtLCBUViAoYW5hbG9nL2RpZ2l0YWwpIFVTQiBkZXZpY2VzCiMKIyBDT05GSUdf
VklERU9fRU0yOFhYIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1BDSV9TVVBQT1JUPXkKCiMK
IyBNZWRpYSBjYXB0dXJlIHN1cHBvcnQKIwoKIwojIE1lZGlhIGNhcHR1cmUvYW5hbG9nIFRW
IHN1cHBvcnQKIwojIENPTkZJR19WSURFT19JVlRWIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE
RU9fWk9SQU4gaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRVhJVU1fR0VNSU5JIGlzIG5v
dCBzZXQKIyBDT05GSUdfVklERU9fSEVYSVVNX09SSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdf
VklERU9fTVhCIGlzIG5vdCBzZXQKCiMKIyBNZWRpYSBjYXB0dXJlL2FuYWxvZy9oeWJyaWQg
VFYgc3VwcG9ydAojCiMgQ09ORklHX1ZJREVPX0NYMTggaXMgbm90IHNldAojIENPTkZJR19W
SURFT19DWDIzODg1IGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX0NYMjU4MjE9eQojIENPTkZJ
R19WSURFT19DWDI1ODIxX0FMU0EgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DWDg4IGlz
IG5vdCBzZXQKIyBDT05GSUdfVklERU9fQlQ4NDggaXMgbm90IHNldAojIENPTkZJR19WSURF
T19TQUE3MTM0IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fU0FBNzE2NCBpcyBub3Qgc2V0
CgojCiMgTWVkaWEgZGlnaXRhbCBUViBQQ0kgQWRhcHRlcnMKIwojIENPTkZJR19EVkJfQVY3
MTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JVREdFVF9DT1JFIGlzIG5vdCBzZXQKIyBD
T05GSUdfRFZCX0IyQzJfRkxFWENPUF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19EVkJfUExV
VE8yIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0RNMTEwNSBpcyBub3Qgc2V0CiMgQ09ORklH
X0RWQl9QVDEgaXMgbm90IHNldAojIENPTkZJR19NQU5USVNfQ09SRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0RWQl9OR0VORSBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9EREJSSURHRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1Y0TF9QTEFURk9STV9EUklWRVJTIGlzIG5vdCBzZXQKIyBDT05G
SUdfVjRMX01FTTJNRU1fRFJJVkVSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1Y0TF9URVNUX0RS
SVZFUlMgaXMgbm90IHNldAoKIwojIFN1cHBvcnRlZCBNTUMvU0RJTyBhZGFwdGVycwojCiMg
Q09ORklHX1JBRElPX0FEQVBURVJTIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX0NYMjM0MVg9
eQpDT05GSUdfVklERU9fQlRDWD15CkNPTkZJR19WSURFT19UVkVFUFJPTT15CgojCiMgTWVk
aWEgYW5jaWxsYXJ5IGRyaXZlcnMgKHR1bmVycywgc2Vuc29ycywgaTJjLCBmcm9udGVuZHMp
CiMKQ09ORklHX01FRElBX1NVQkRSVl9BVVRPU0VMRUNUPXkKQ09ORklHX1ZJREVPX0lSX0ky
Qz15CgojCiMgQXVkaW8gZGVjb2RlcnMsIHByb2Nlc3NvcnMgYW5kIG1peGVycwojCkNPTkZJ
R19WSURFT19NU1AzNDAwPXkKQ09ORklHX1ZJREVPX0NTNTNMMzJBPXkKQ09ORklHX1ZJREVP
X1dNODc3NT15CgojCiMgUkRTIGRlY29kZXJzCiMKCiMKIyBWaWRlbyBkZWNvZGVycwojCkNP
TkZJR19WSURFT19TQUE3MTFYPXkKCiMKIyBWaWRlbyBhbmQgYXVkaW8gZGVjb2RlcnMKIwpD
T05GSUdfVklERU9fQ1gyNTg0MD15CgojCiMgVmlkZW8gZW5jb2RlcnMKIwoKIwojIENhbWVy
YSBzZW5zb3IgZGV2aWNlcwojCgojCiMgRmxhc2ggZGV2aWNlcwojCgojCiMgVmlkZW8gaW1w
cm92ZW1lbnQgY2hpcHMKIwoKIwojIE1pc2NlbGFuZW91cyBoZWxwZXIgY2hpcHMKIwoKIwoj
IFNlbnNvcnMgdXNlZCBvbiBzb2NfY2FtZXJhIGRyaXZlcgojCiMgQ09ORklHX01FRElBX0FU
VEFDSCBpcyBub3Qgc2V0CkNPTkZJR19NRURJQV9UVU5FUj15CkNPTkZJR19NRURJQV9UVU5F
Ul9TSU1QTEU9eQpDT05GSUdfTUVESUFfVFVORVJfVERBODI5MD15CkNPTkZJR19NRURJQV9U
VU5FUl9UREE4MjdYPXkKQ09ORklHX01FRElBX1RVTkVSX1REQTE4MjcxPXkKQ09ORklHX01F
RElBX1RVTkVSX1REQTk4ODc9eQpDT05GSUdfTUVESUFfVFVORVJfVEVBNTc2MT15CkNPTkZJ
R19NRURJQV9UVU5FUl9URUE1NzY3PXkKQ09ORklHX01FRElBX1RVTkVSX01UMjBYWD15CkNP
TkZJR19NRURJQV9UVU5FUl9YQzIwMjg9eQpDT05GSUdfTUVESUFfVFVORVJfWEM1MDAwPXkK
Q09ORklHX01FRElBX1RVTkVSX1hDNDAwMD15CkNPTkZJR19NRURJQV9UVU5FUl9NQzQ0Uzgw
Mz15CgojCiMgTXVsdGlzdGFuZGFyZCAoc2F0ZWxsaXRlKSBmcm9udGVuZHMKIwoKIwojIE11
bHRpc3RhbmRhcmQgKGNhYmxlICsgdGVycmVzdHJpYWwpIGZyb250ZW5kcwojCgojCiMgRFZC
LVMgKHNhdGVsbGl0ZSkgZnJvbnRlbmRzCiMKCiMKIyBEVkItVCAodGVycmVzdHJpYWwpIGZy
b250ZW5kcwojCkNPTkZJR19EVkJfVERBMTAwNDg9eQoKIwojIERWQi1DIChjYWJsZSkgZnJv
bnRlbmRzCiMKCiMKIyBBVFNDIChOb3J0aCBBbWVyaWNhbi9Lb3JlYW4gVGVycmVzdHJpYWwv
Q2FibGUgRFRWKSBmcm9udGVuZHMKIwpDT05GSUdfRFZCX0xHRFQzMzBYPXkKQ09ORklHX0RW
Ql9TNUgxNDA5PXkKQ09ORklHX0RWQl9TNUgxNDExPXkKCiMKIyBJU0RCLVQgKHRlcnJlc3Ry
aWFsKSBmcm9udGVuZHMKIwoKIwojIERpZ2l0YWwgdGVycmVzdHJpYWwgb25seSB0dW5lcnMv
UExMCiMKCiMKIyBTRUMgY29udHJvbCBkZXZpY2VzIGZvciBEVkItUwojCgojCiMgVG9vbHMg
dG8gZGV2ZWxvcCBuZXcgZnJvbnRlbmRzCiMKIyBDT05GSUdfRFZCX0RVTU1ZX0ZFIGlzIG5v
dCBzZXQKCiMKIyBHcmFwaGljcyBzdXBwb3J0CiMKQ09ORklHX0FHUD15CkNPTkZJR19BR1Bf
QU1ENjQ9eQpDT05GSUdfQUdQX0lOVEVMPXkKIyBDT05GSUdfQUdQX1NJUyBpcyBub3Qgc2V0
CiMgQ09ORklHX0FHUF9WSUEgaXMgbm90IHNldApDT05GSUdfVkdBX0FSQj15CkNPTkZJR19W
R0FfQVJCX01BWF9HUFVTPTE2CiMgQ09ORklHX1ZHQV9TV0lUQ0hFUk9PIGlzIG5vdCBzZXQK
Q09ORklHX0RSTT15CkNPTkZJR19EUk1fS01TX0hFTFBFUj15CiMgQ09ORklHX0RSTV9MT0FE
X0VESURfRklSTVdBUkUgaXMgbm90IHNldApDT05GSUdfRFJNX1RUTT15CiMgQ09ORklHX0RS
TV9UREZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1IxMjggaXMgbm90IHNldApDT05GSUdf
RFJNX1JBREVPTj15CkNPTkZJR19EUk1fUkFERU9OX0tNUz15CiMgQ09ORklHX0RSTV9OT1VW
RUFVIGlzIG5vdCBzZXQKCiMKIyBJMkMgZW5jb2RlciBvciBoZWxwZXIgY2hpcHMKIwpDT05G
SUdfRFJNX0kyQ19DSDcwMDY9eQpDT05GSUdfRFJNX0kyQ19TSUwxNjQ9eQpDT05GSUdfRFJN
X0k5MTU9eQpDT05GSUdfRFJNX0k5MTVfS01TPXkKIyBDT05GSUdfRFJNX01HQSBpcyBub3Qg
c2V0CiMgQ09ORklHX0RSTV9TSVMgaXMgbm90IHNldAojIENPTkZJR19EUk1fVklBIGlzIG5v
dCBzZXQKIyBDT05GSUdfRFJNX1NBVkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9WTVdH
RlggaXMgbm90IHNldAojIENPTkZJR19EUk1fR01BNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdf
RFJNX1VETCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9BU1QgaXMgbm90IHNldAojIENPTkZJ
R19EUk1fTUdBRzIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9DSVJSVVNfUUVNVSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZHQVNU
QVRFIGlzIG5vdCBzZXQKQ09ORklHX1ZJREVPX09VVFBVVF9DT05UUk9MPXkKQ09ORklHX0ZC
PXkKIyBDT05GSUdfRklSTVdBUkVfRURJRCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0REQyBp
cyBub3Qgc2V0CkNPTkZJR19GQl9CT09UX1ZFU0FfU1VQUE9SVD15CkNPTkZJR19GQl9DRkJf
RklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVBPXkKQ09ORklHX0ZCX0NGQl9JTUFH
RUJMSVQ9eQojIENPTkZJR19GQl9DRkJfUkVWX1BJWEVMU19JTl9CWVRFIGlzIG5vdCBzZXQK
Q09ORklHX0ZCX1NZU19GSUxMUkVDVD15CkNPTkZJR19GQl9TWVNfQ09QWUFSRUE9eQpDT05G
SUdfRkJfU1lTX0lNQUdFQkxJVD15CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5ESUFOIGlzIG5v
dCBzZXQKQ09ORklHX0ZCX1NZU19GT1BTPXkKIyBDT05GSUdfRkJfV01UX0dFX1JPUFMgaXMg
bm90IHNldApDT05GSUdfRkJfREVGRVJSRURfSU89eQojIENPTkZJR19GQl9TVkdBTElCIGlz
IG5vdCBzZXQKIyBDT05GSUdfRkJfTUFDTU9ERVMgaXMgbm90IHNldAojIENPTkZJR19GQl9C
QUNLTElHSFQgaXMgbm90IHNldApDT05GSUdfRkJfTU9ERV9IRUxQRVJTPXkKQ09ORklHX0ZC
X1RJTEVCTElUVElORz15CgojCiMgRnJhbWUgYnVmZmVyIGhhcmR3YXJlIGRyaXZlcnMKIwoj
IENPTkZJR19GQl9DSVJSVVMgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTIgaXMgbm90IHNl
dAojIENPTkZJR19GQl9DWUJFUjIwMDAgaXMgbm90IHNldAojIENPTkZJR19GQl9BUkMgaXMg
bm90IHNldAojIENPTkZJR19GQl9BU0lMSUFOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0lN
U1RUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVkdBMTYgaXMgbm90IHNldAojIENPTkZJR19G
Ql9VVkVTQSBpcyBub3Qgc2V0CkNPTkZJR19GQl9WRVNBPXkKIyBDT05GSUdfRkJfTjQxMSBp
cyBub3Qgc2V0CiMgQ09ORklHX0ZCX0hHQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1MxRDEz
WFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05GSUdf
RkJfUklWQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0k3NDAgaXMgbm90IHNldAojIENPTkZJ
R19GQl9MRTgwNTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTUFUUk9YIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkJfUkFERU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZMTI4IGlzIG5v
dCBzZXQKIyBDT05GSUdfRkJfQVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUzMgaXMgbm90
IHNldAojIENPTkZJR19GQl9TQVZBR0UgaXMgbm90IHNldAojIENPTkZJR19GQl9TSVMgaXMg
bm90IHNldAojIENPTkZJR19GQl9WSUEgaXMgbm90IHNldAojIENPTkZJR19GQl9ORU9NQUdJ
QyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0tZUk8gaXMgbm90IHNldAojIENPTkZJR19GQl8z
REZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVk9PRE9PMSBpcyBub3Qgc2V0CiMgQ09ORklH
X0ZCX1ZUODYyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1RSSURFTlQgaXMgbm90IHNldAoj
IENPTkZJR19GQl9BUksgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTMgaXMgbm90IHNldAoj
IENPTkZJR19GQl9DQVJNSU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfR0VPREUgaXMgbm90
IHNldAojIENPTkZJR19GQl9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBp
cyBub3Qgc2V0CkNPTkZJR19GQl9VREw9eQojIENPTkZJR19GQl9HT0xERklTSCBpcyBub3Qg
c2V0CiMgQ09ORklHX0ZCX1ZJUlRVQUwgaXMgbm90IHNldApDT05GSUdfWEVOX0ZCREVWX0ZS
T05URU5EPXkKIyBDT05GSUdfRkJfTUVUUk9OT01FIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
TUI4NjJYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0JST0FEU0hFRVQgaXMgbm90IHNldAoj
IENPTkZJR19GQl9BVU9fSzE5MFggaXMgbm90IHNldAojIENPTkZJR19FWFlOT1NfVklERU8g
aXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0xDRF9TVVBQT1JUPXkKIyBDT05GSUdfTENE
X0NMQVNTX0RFVklDRSBpcyBub3Qgc2V0CkNPTkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNF
PXkKQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklDPXkKIyBDT05GSUdfQkFDS0xJR0hUX0FQUExF
IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qgc2V0CiMgQ09O
RklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0FE
UDg4NzAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjMwIGlzIG5vdCBzZXQK
IyBDT05GSUdfQkFDS0xJR0hUX0xNMzYzOSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tMSUdI
VF9MUDg1NVggaXMgbm90IHNldAoKIwojIENvbnNvbGUgZGlzcGxheSBkcml2ZXIgc3VwcG9y
dAojCkNPTkZJR19WR0FfQ09OU09MRT15CkNPTkZJR19WR0FDT05fU09GVF9TQ1JPTExCQUNL
PXkKQ09ORklHX1ZHQUNPTl9TT0ZUX1NDUk9MTEJBQ0tfU0laRT02NApDT05GSUdfRFVNTVlf
Q09OU09MRT15CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVG
RkVSX0NPTlNPTEVfREVURUNUX1BSSU1BUlk9eQojIENPTkZJR19GUkFNRUJVRkZFUl9DT05T
T0xFX1JPVEFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRk9OVFMgaXMgbm90IHNldApDT05G
SUdfRk9OVF84eDg9eQpDT05GSUdfRk9OVF84eDE2PXkKQ09ORklHX0xPR089eQojIENPTkZJ
R19MT0dPX0xJTlVYX01PTk8gaXMgbm90IHNldAojIENPTkZJR19MT0dPX0xJTlVYX1ZHQTE2
IGlzIG5vdCBzZXQKQ09ORklHX0xPR09fTElOVVhfQ0xVVDIyND15CkNPTkZJR19TT1VORD15
CkNPTkZJR19TT1VORF9PU1NfQ09SRT15CkNPTkZJR19TT1VORF9PU1NfQ09SRV9QUkVDTEFJ
TT15CkNPTkZJR19TTkQ9eQpDT05GSUdfU05EX1RJTUVSPXkKQ09ORklHX1NORF9QQ009eQpD
T05GSUdfU05EX0hXREVQPXkKQ09ORklHX1NORF9SQVdNSURJPXkKQ09ORklHX1NORF9TRVFV
RU5DRVI9eQpDT05GSUdfU05EX1NFUV9EVU1NWT15CkNPTkZJR19TTkRfT1NTRU1VTD15CkNP
TkZJR19TTkRfTUlYRVJfT1NTPXkKQ09ORklHX1NORF9QQ01fT1NTPXkKQ09ORklHX1NORF9Q
Q01fT1NTX1BMVUdJTlM9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQpDT05GSUdfU05E
X0hSVElNRVI9eQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9eQpDT05GSUdfU05E
X0RZTkFNSUNfTUlOT1JTPXkKQ09ORklHX1NORF9TVVBQT1JUX09MRF9BUEk9eQpDT05GSUdf
U05EX1ZFUkJPU0VfUFJPQ0ZTPXkKIyBDT05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLIGlzIG5v
dCBzZXQKIyBDT05GSUdfU05EX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NORF9WTUFTVEVS
PXkKQ09ORklHX1NORF9LQ1RMX0pBQ0s9eQpDT05GSUdfU05EX0RNQV9TR0JVRj15CkNPTkZJ
R19TTkRfUkFXTUlESV9TRVE9eQpDT05GSUdfU05EX09QTDNfTElCX1NFUT15CiMgQ09ORklH
X1NORF9PUEw0X0xJQl9TRVEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU0JBV0VfU0VRIGlz
IG5vdCBzZXQKIyBDT05GSUdfU05EX0VNVTEwSzFfU0VRIGlzIG5vdCBzZXQKQ09ORklHX1NO
RF9NUFU0MDFfVUFSVD15CkNPTkZJR19TTkRfT1BMM19MSUI9eQpDT05GSUdfU05EX0RSSVZF
UlM9eQojIENPTkZJR19TTkRfUENTUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9EVU1NWSBp
cyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTE9PUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9W
SVJNSURJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX1NFUklBTF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBVNDAxIGlz
IG5vdCBzZXQKQ09ORklHX1NORF9QQ0k9eQojIENPTkZJR19TTkRfQUQxODg5IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU05EX0FMUzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTFM0MDAw
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FMSTU0NTEgaXMgbm90IHNldAojIENPTkZJR19T
TkRfQVNJSFBJIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FUSUlYUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9BVElJWFBfTU9ERU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODEw
IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVODgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO
RF9BVTg4MzAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVcyIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX0FaVDMzMjggaXMgbm90IHNldAojIENPTkZJR19TTkRfQlQ4N1ggaXMgbm90IHNl
dAojIENPTkZJR19TTkRfQ0EwMTA2IGlzIG5vdCBzZXQKQ09ORklHX1NORF9DTUlQQ0k9eQpD
T05GSUdfU05EX09YWUdFTl9MSUI9eQpDT05GSUdfU05EX09YWUdFTj15CiMgQ09ORklHX1NO
RF9DUzQyODEgaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1M0NlhYIGlzIG5vdCBzZXQKIyBD
T05GSUdfU05EX0NTNTUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzU1MzVBVURJTyBp
cyBub3Qgc2V0CiMgQ09ORklHX1NORF9DVFhGSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E
QVJMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dJTkEyMCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NORF9MQVlMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0RBUkxBMjQgaXMgbm90
IHNldAojIENPTkZJR19TTkRfR0lOQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0xBWUxB
MjQgaXMgbm90IHNldAojIENPTkZJR19TTkRfTU9OQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NO
RF9NSUEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRUNITzNHIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX0lORElHTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJR09JTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1NORF9JTkRJR09ESiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJ
R09JT1ggaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdPREpYIGlzIG5vdCBzZXQKIyBD
T05GSUdfU05EX0VNVTEwSzEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMVggaXMg
bm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9F
TlMxMzcxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VTMTkzOCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NORF9FUzE5NjggaXMgbm90IHNldAojIENPTkZJR19TTkRfRk04MDEgaXMgbm90IHNl
dApDT05GSUdfU05EX0hEQV9JTlRFTD15CkNPTkZJR19TTkRfSERBX1BSRUFMTE9DX1NJWkU9
NjQKQ09ORklHX1NORF9IREFfSFdERVA9eQojIENPTkZJR19TTkRfSERBX1JFQ09ORklHIGlz
IG5vdCBzZXQKIyBDT05GSUdfU05EX0hEQV9JTlBVVF9CRUVQIGlzIG5vdCBzZXQKIyBDT05G
SUdfU05EX0hEQV9JTlBVVF9KQUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0hEQV9QQVRD
SF9MT0FERVIgaXMgbm90IHNldApDT05GSUdfU05EX0hEQV9DT0RFQ19SRUFMVEVLPXkKQ09O
RklHX1NORF9IREFfQ09ERUNfQU5BTE9HPXkKQ09ORklHX1NORF9IREFfQ09ERUNfU0lHTUFU
RUw9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19WSUE9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19I
RE1JPXkKQ09ORklHX1NORF9IREFfQ09ERUNfQ0lSUlVTPXkKQ09ORklHX1NORF9IREFfQ09E
RUNfQ09ORVhBTlQ9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19DQTAxMTA9eQpDT05GSUdfU05E
X0hEQV9DT0RFQ19DQTAxMzI9eQojIENPTkZJR19TTkRfSERBX0NPREVDX0NBMDEzMl9EU1Ag
aXMgbm90IHNldApDT05GSUdfU05EX0hEQV9DT0RFQ19DTUVESUE9eQpDT05GSUdfU05EX0hE
QV9DT0RFQ19TSTMwNTQ9eQpDT05GSUdfU05EX0hEQV9HRU5FUklDPXkKQ09ORklHX1NORF9I
REFfUE9XRVJfU0FWRV9ERUZBVUxUPTAKIyBDT05GSUdfU05EX0hEU1AgaXMgbm90IHNldAoj
IENPTkZJR19TTkRfSERTUE0gaXMgbm90IHNldAojIENPTkZJR19TTkRfSUNFMTcxMiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1NORF9JQ0UxNzI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lO
VEVMOFgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lOVEVMOFgwTSBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9LT1JHMTIxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9MT0xBIGlzIG5v
dCBzZXQKIyBDT05GSUdfU05EX0xYNjQ2NEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01B
RVNUUk8zIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01JWEFSVCBpcyBub3Qgc2V0CiMgQ09O
RklHX1NORF9OTTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9QQ1hIUiBpcyBub3Qgc2V0
CiMgQ09ORklHX1NORF9SSVBUSURFIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JNRTMyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU05EX1JNRTk2IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JN
RTk2NTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09OSUNWSUJFUyBpcyBub3Qgc2V0CiMg
Q09ORklHX1NORF9UUklERU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1ZJQTgyWFggaXMg
bm90IHNldAojIENPTkZJR19TTkRfVklBODJYWF9NT0RFTSBpcyBub3Qgc2V0CiMgQ09ORklH
X1NORF9WSVJUVU9TTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WWDIyMiBpcyBub3Qgc2V0
CiMgQ09ORklHX1NORF9ZTUZQQ0kgaXMgbm90IHNldApDT05GSUdfU05EX1VTQj15CkNPTkZJ
R19TTkRfVVNCX0FVRElPPXkKQ09ORklHX1NORF9VU0JfVUExMDE9eQpDT05GSUdfU05EX1VT
Ql9VU1gyWT15CkNPTkZJR19TTkRfVVNCX0NBSUFRPXkKQ09ORklHX1NORF9VU0JfQ0FJQVFf
SU5QVVQ9eQojIENPTkZJR19TTkRfVVNCX1VTMTIyTCBpcyBub3Qgc2V0CkNPTkZJR19TTkRf
VVNCXzZGSVJFPXkKIyBDT05GSUdfU05EX1NPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NPVU5E
X1BSSU1FIGlzIG5vdCBzZXQKCiMKIyBISUQgc3VwcG9ydAojCkNPTkZJR19ISUQ9eQojIENP
TkZJR19ISURfQkFUVEVSWV9TVFJFTkdUSCBpcyBub3Qgc2V0CkNPTkZJR19ISURSQVc9eQoj
IENPTkZJR19VSElEIGlzIG5vdCBzZXQKQ09ORklHX0hJRF9HRU5FUklDPXkKCiMKIyBTcGVj
aWFsIEhJRCBkcml2ZXJzCiMKQ09ORklHX0hJRF9BNFRFQ0g9eQojIENPTkZJR19ISURfQUNS
VVggaXMgbm90IHNldApDT05GSUdfSElEX0FQUExFPXkKIyBDT05GSUdfSElEX0FVUkVBTCBp
cyBub3Qgc2V0CkNPTkZJR19ISURfQkVMS0lOPXkKQ09ORklHX0hJRF9DSEVSUlk9eQpDT05G
SUdfSElEX0NISUNPTlk9eQojIENPTkZJR19ISURfUFJPRElLRVlTIGlzIG5vdCBzZXQKQ09O
RklHX0hJRF9DWVBSRVNTPXkKIyBDT05GSUdfSElEX0RSQUdPTlJJU0UgaXMgbm90IHNldAoj
IENPTkZJR19ISURfRU1TX0ZGIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0VMRUNPTSBpcyBu
b3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQojIENPTkZJR19ISURfSE9MVEVLIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSElEX0tFWVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0tZRSBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9VQ0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE
X1dBTFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9JQ0FERSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5v
dCBzZXQKQ09ORklHX0hJRF9LRU5TSU5HVE9OPXkKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMg
bm90IHNldAojIENPTkZJR19ISURfTEVOT1ZPX1RQS0JEIGlzIG5vdCBzZXQKQ09ORklHX0hJ
RF9MT0dJVEVDSD15CiMgQ09ORklHX0hJRF9MT0dJVEVDSF9ESiBpcyBub3Qgc2V0CiMgQ09O
RklHX0xPR0lURUNIX0ZGIGlzIG5vdCBzZXQKIyBDT05GSUdfTE9HSVJVTUJMRVBBRDJfRkYg
aXMgbm90IHNldAojIENPTkZJR19MT0dJRzk0MF9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xP
R0lXSEVFTFNfRkYgaXMgbm90IHNldAojIENPTkZJR19ISURfTUFHSUNNT1VTRSBpcyBub3Qg
c2V0CkNPTkZJR19ISURfTUlDUk9TT0ZUPXkKQ09ORklHX0hJRF9NT05URVJFWT15CiMgQ09O
RklHX0hJRF9NVUxUSVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX05UUklHIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX09SVEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BBTlRI
RVJMT1JEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1BFVEFMWU5YIGlzIG5vdCBzZXQKIyBD
T05GSUdfSElEX1BJQ09MQ0QgaXMgbm90IHNldAojIENPTkZJR19ISURfUFJJTUFYIGlzIG5v
dCBzZXQKIyBDT05GSUdfSElEX1BTM1JFTU9URSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9S
T0NDQVQgaXMgbm90IHNldAojIENPTkZJR19ISURfU0FJVEVLIGlzIG5vdCBzZXQKIyBDT05G
SUdfSElEX1NBTVNVTkcgaXMgbm90IHNldAojIENPTkZJR19ISURfU09OWSBpcyBub3Qgc2V0
CiMgQ09ORklHX0hJRF9TUEVFRExJTksgaXMgbm90IHNldAojIENPTkZJR19ISURfU1RFRUxT
RVJJRVMgaXMgbm90IHNldAojIENPTkZJR19ISURfU1VOUExVUyBpcyBub3Qgc2V0CiMgQ09O
RklHX0hJRF9HUkVFTkFTSUEgaXMgbm90IHNldAojIENPTkZJR19ISURfU01BUlRKT1lQTFVT
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RJVk8gaXMgbm90IHNldAojIENPTkZJR19ISURf
VE9QU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USElOR00gaXMgbm90IHNldAojIENP
TkZJR19ISURfVEhSVVNUTUFTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBQ09NIGlz
IG5vdCBzZXQKIyBDT05GSUdfSElEX1dJSU1PVEUgaXMgbm90IHNldAojIENPTkZJR19ISURf
WkVST1BMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldAoj
IENPTkZJR19ISURfU0VOU09SX0hVQiBpcyBub3Qgc2V0CgojCiMgVVNCIEhJRCBzdXBwb3J0
CiMKQ09ORklHX1VTQl9ISUQ9eQpDT05GSUdfSElEX1BJRD15CkNPTkZJR19VU0JfSElEREVW
PXkKCiMKIyBJMkMgSElEIHN1cHBvcnQKIwojIENPTkZJR19JMkNfSElEIGlzIG5vdCBzZXQK
Q09ORklHX1VTQl9BUkNIX0hBU19PSENJPXkKQ09ORklHX1VTQl9BUkNIX0hBU19FSENJPXkK
Q09ORklHX1VTQl9BUkNIX0hBU19YSENJPXkKQ09ORklHX1VTQl9TVVBQT1JUPXkKQ09ORklH
X1VTQl9DT01NT049eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQoj
IENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfVVNCX0FOTk9VTkNFX05FV19E
RVZJQ0VTPXkKCiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMKIyBDT05GSUdfVVNC
X0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RXQzMgaXMgbm90IHNl
dApDT05GSUdfVVNCX01PTj15CiMgQ09ORklHX1VTQl9XVVNCX0NCQUYgaXMgbm90IHNldAoK
IwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklHX1VTQl9DNjdYMDBf
SENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9YSENJX0hDRD15CiMgQ09ORklHX1VTQl9YSENJ
X0hDRF9ERUJVR0dJTkcgaXMgbm90IHNldApDT05GSUdfVVNCX0VIQ0lfSENEPXkKQ09ORklH
X1VTQl9FSENJX1JPT1RfSFVCX1RUPXkKQ09ORklHX1VTQl9FSENJX1RUX05FV1NDSEVEPXkK
Q09ORklHX1VTQl9FSENJX1BDST15CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9IQ0QgaXMgbm90
IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
SVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0QgaXMgbm90
IHNldApDT05GSUdfVVNCX09IQ0lfSENEPXkKIyBDT05GSUdfVVNCX09IQ0lfSENEX1BMQVRG
T1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0VIQ0lfSENEX1BMQVRGT1JNIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9ERVNDIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX09IQ0lfQklHX0VORElBTl9NTUlPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJ
X0xJVFRMRV9FTkRJQU49eQpDT05GSUdfVVNCX1VIQ0lfSENEPXkKIyBDT05GSUdfVVNCX1NM
ODExX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5N19IQ0QgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfQ0hJUElERUEgaXMgbm90IHNldAoKIwojIFVTQiBEZXZpY2UgQ2xh
c3MgZHJpdmVycwojCiMgQ09ORklHX1VTQl9BQ00gaXMgbm90IHNldApDT05GSUdfVVNCX1BS
SU5URVI9eQojIENPTkZJR19VU0JfV0RNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RNQyBp
cyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NUT1JBR0UgZGVwZW5kcyBvbiBTQ1NJIGJ1dCBC
TEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBuZWVkZWQ7IHNlZSBVU0JfU1RPUkFHRSBI
ZWxwIGZvciBtb3JlIGluZm8KIwpDT05GSUdfVVNCX1NUT1JBR0U9eQojIENPTkZJR19VU0Jf
U1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1JFQUxURUsg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S
QUdFX0lTRDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NUT1JBR0VfU0REUjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVN
UFNIT1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNl
dAojIENPTkZJR19VU0JfU1RPUkFHRV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TVE9SQUdFX0tBUk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVT
U19BVEFDQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0VORV9VQjYyNTAgaXMg
bm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJR19VU0JfTURDODAw
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01JQ1JPVEVLIGlzIG5vdCBzZXQKCiMKIyBVU0Ig
cG9ydCBkcml2ZXJzCiMKQ09ORklHX1VTQl9TRVJJQUw9eQojIENPTkZJR19VU0JfU0VSSUFM
X0NPTlNPTEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0dFTkVSSUMgaXMgbm90
IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0FJUkNBQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdf
VVNCX1NFUklBTF9BUkszMTE2IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9CRUxL
SU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0NIMzQxIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1NFUklBTF9XSElURUhFQVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX0RJR0lfQUNDRUxFUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX0NQMjEw
WD15CkNPTkZJR19VU0JfU0VSSUFMX0NZUFJFU1NfTTg9eQojIENPTkZJR19VU0JfU0VSSUFM
X0VNUEVHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9GVERJX1NJTyBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRlVOU09GVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9TRVJJQUxfVklTT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lQQVEgaXMg
bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NFUklBTF9FREdFUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRURHRVBP
UlRfVEkgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0Y4MTIzMiBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TRVJJQUxfR0FSTUlOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF
UklBTF9JUFcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lVVSBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTl9QREEgaXMgbm90IHNldAojIENPTkZJR19V
U0JfU0VSSUFMX0tFWVNQQU4gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tMU0kg
aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0tPQklMX1NDVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9TRVJJQUxfTUNUX1UyMzIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VS
SUFMX01FVFJPIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9TRVJJQUxfTU9TNzcyMD15CkNPTkZJ
R19VU0JfU0VSSUFMX01PUzc4NDA9eQojIENPTkZJR19VU0JfU0VSSUFMX01PVE9ST0xBIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9OQVZNQU4gaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU0VSSUFMX1BMMjMwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfT1RJ
Njg1OCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfUUNBVVggaXMgbm90IHNldAoj
IENPTkZJR19VU0JfU0VSSUFMX1FVQUxDT01NIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NF
UklBTF9TUENQOFg1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9IUDRYIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TQUZFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X1NFUklBTF9TSUVNRU5TX01QSSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU0lF
UlJBV0lSRUxFU1MgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NZTUJPTCBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfVEkgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
U0VSSUFMX0NZQkVSSkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfWElSQ09N
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9PUFRJT04gaXMgbm90IHNldAojIENP
TkZJR19VU0JfU0VSSUFMX09NTklORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFM
X09QVElDT04gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1ZJVk9QQVlfU0VSSUFM
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9YU0VOU19NVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9TRVJJQUxfWklPIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9a
VEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NTVTEwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9TRVJJQUxfUVQyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9E
RUJVRyBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwojCiMgQ09O
RklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FTUkyNiBpcyBub3Qgc2V0
CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VWU0VHIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9M
RUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2MyBpcyBu
b3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lE
TU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TSVNVU0JW
R0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEQgaXMgbm90IHNldAojIENPTkZJR19VU0Jf
VFJBTkNFVklCUkFUT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfSU9XQVJSSU9SIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNJR0hU
RlcgaXMgbm90IHNldAojIENPTkZJR19VU0JfWVVSRVggaXMgbm90IHNldAojIENPTkZJR19V
U0JfRVpVU0JfRlgyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0hTSUNfVVNCMzUwMyBpcyBu
b3Qgc2V0CgojCiMgVVNCIFBoeXNpY2FsIExheWVyIGRyaXZlcnMKIwojIENPTkZJR19PTUFQ
X1VTQjMgaXMgbm90IHNldAojIENPTkZJR19PTUFQX0NPTlRST0xfVVNCIGlzIG5vdCBzZXQK
IyBDT05GSUdfVVNCX0lTUDEzMDEgaXMgbm90IHNldAojIENPTkZJR19VU0JfUkNBUl9QSFkg
aXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQKCiMKIyBPVEcgYW5k
IHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNCX1hDRUlWIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5vdCBzZXQK
IyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9eQpDT05GSUdf
TEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xNMzUzMCBp
cyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVE
U19QQ0E5NTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDM5NDQgaXMgbm90IHNldAoj
IENPTkZJR19MRURTX0xQNTUyMSBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1NTIzIGlz
IG5vdCBzZXQKIyBDT05GSUdfTEVEU19DTEVWT19NQUlMIGlzIG5vdCBzZXQKIyBDT05GSUdf
TEVEU19QQ0E5NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5NjMzIGlzIG5vdCBz
ZXQKIyBDT05GSUdfTEVEU19CRDI4MDIgaXMgbm90IHNldAojIENPTkZJR19MRURTX0lOVEVM
X1NTNDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfVENBNjUwNyBpcyBub3Qgc2V0CiMg
Q09ORklHX0xFRFNfTE0zNTV4IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19PVDIwMCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0xFRFNfQkxJTktNIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19U
UklHR0VSUyBpcyBub3Qgc2V0CgojCiMgTEVEIFRyaWdnZXJzCiMKIyBDT05GSUdfQUNDRVNT
SUJJTElUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkQgaXMgbm90IHNldAojIENP
TkZJR19FREFDIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNT
PXkKIyBDT05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMgaW50ZXJmYWNlcwoj
CkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9DPXkKQ09ORklH
X1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBkcml2
ZXJzCiMKIyBDT05GSUdfUlRDX0RSVl9EUzEzMDcgaXMgbm90IHNldAojIENPTkZJR19SVENf
RFJWX0RTMTM3NCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNjcyIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUlRDX0RSVl9EUzMyMzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X01BWDY5MDAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JTNUMzNzIgaXMgbm90IHNl
dAojIENPTkZJR19SVENfRFJWX0lTTDEyMDggaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X0lTTDEyMDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9YMTIwNSBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfUENGODUyMyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZf
UENGODU2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUENGODU4MyBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfTTQxVDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9C
UTMySyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUzM1MzkwQSBpcyBub3Qgc2V0CiMg
Q09ORklHX1JUQ19EUlZfRk0zMTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SWDg1
ODEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODAyNSBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUQ19EUlZfRU0zMDI3IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SVjMwMjlD
MiBpcyBub3Qgc2V0CgojCiMgU1BJIFJUQyBkcml2ZXJzCiMKCiMKIyBQbGF0Zm9ybSBSVEMg
ZHJpdmVycwojCkNPTkZJR19SVENfRFJWX0NNT1M9eQojIENPTkZJR19SVENfRFJWX0RTMTI4
NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNTExIGlzIG5vdCBzZXQKIyBDT05G
SUdfUlRDX0RSVl9EUzE1NTMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTc0MiBp
cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfU1RLMTdUQTggaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX000OFQ4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDM1IGlz
IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDhUNTkgaXMgbm90IHNldAojIENPTkZJR19S
VENfRFJWX01TTTYyNDIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRNDgwMiBpcyBu
b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUlA1QzAxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD
X0RSVl9WMzAyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMyNDA0IGlzIG5vdCBz
ZXQKCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwoKIwojIEhJRCBTZW5zb3IgUlRDIGRyaXZl
cnMKIwojIENPTkZJR19SVENfRFJWX0hJRF9TRU5TT1JfVElNRSBpcyBub3Qgc2V0CiMgQ09O
RklHX0RNQURFVklDRVMgaXMgbm90IHNldAojIENPTkZJR19BVVhESVNQTEFZIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfVkZJTyBpcyBub3Qgc2V0Cgoj
CiMgVmlydGlvIGRyaXZlcnMKIwojIENPTkZJR19WSVJUSU9fUENJIGlzIG5vdCBzZXQKIyBD
T05GSUdfVklSVElPX01NSU8gaXMgbm90IHNldAoKIwojIE1pY3Jvc29mdCBIeXBlci1WIGd1
ZXN0IHN1cHBvcnQKIwojIENPTkZJR19IWVBFUlYgaXMgbm90IHNldAoKIwojIFhlbiBkcml2
ZXIgc3VwcG9ydAojCkNPTkZJR19YRU5fQkFMTE9PTj15CkNPTkZJR19YRU5fU0NSVUJfUEFH
RVM9eQpDT05GSUdfWEVOX0RFVl9FVlRDSE49eQpDT05GSUdfWEVOX0JBQ0tFTkQ9eQpDT05G
SUdfWEVORlM9eQpDT05GSUdfWEVOX0NPTVBBVF9YRU5GUz15CkNPTkZJR19YRU5fU1lTX0hZ
UEVSVklTT1I9eQpDT05GSUdfWEVOX1hFTkJVU19GUk9OVEVORD15CkNPTkZJR19YRU5fR05U
REVWPXkKQ09ORklHX1hFTl9HUkFOVF9ERVZfQUxMT0M9eQpDT05GSUdfU1dJT1RMQl9YRU49
eQpDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKQ09ORklHX1hFTl9QUklWQ01EPXkKIyBD
T05GSUdfWEVOX1NUVUIgaXMgbm90IHNldApDT05GSUdfWEVOX0FDUElfUFJPQ0VTU09SPXkK
Q09ORklHX1hFTl9NQ0VfTE9HPXkKQ09ORklHX1hFTl9IQVZFX1BWTU1VPXkKIyBDT05GSUdf
U1RBR0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9QTEFURk9STV9ERVZJQ0VTIGlzIG5v
dCBzZXQKCiMKIyBIYXJkd2FyZSBTcGlubG9jayBkcml2ZXJzCiMKQ09ORklHX0NMS0VWVF9J
ODI1Mz15CkNPTkZJR19JODI1M19MT0NLPXkKQ09ORklHX0NMS0JMRF9JODI1Mz15CiMgQ09O
RklHX01BSUxCT1ggaXMgbm90IHNldApDT05GSUdfSU9NTVVfQVBJPXkKQ09ORklHX0lPTU1V
X1NVUFBPUlQ9eQpDT05GSUdfQU1EX0lPTU1VPXkKQ09ORklHX0FNRF9JT01NVV9TVEFUUz15
CkNPTkZJR19ETUFSX1RBQkxFPXkKQ09ORklHX0lOVEVMX0lPTU1VPXkKQ09ORklHX0lOVEVM
X0lPTU1VX0RFRkFVTFRfT049eQpDT05GSUdfSU5URUxfSU9NTVVfRkxPUFBZX1dBPXkKQ09O
RklHX0lSUV9SRU1BUD15CgojCiMgUmVtb3RlcHJvYyBkcml2ZXJzCiMKIyBDT05GSUdfU1RF
X01PREVNX1JQUk9DIGlzIG5vdCBzZXQKCiMKIyBScG1zZyBkcml2ZXJzCiMKIyBDT05GSUdf
VklSVF9EUklWRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfUE1fREVWRlJFUSBpcyBub3Qgc2V0
CiMgQ09ORklHX0VYVENPTiBpcyBub3Qgc2V0CiMgQ09ORklHX01FTU9SWSBpcyBub3Qgc2V0
CiMgQ09ORklHX0lJTyBpcyBub3Qgc2V0CiMgQ09ORklHX05UQiBpcyBub3Qgc2V0CiMgQ09O
RklHX1ZNRV9CVVMgaXMgbm90IHNldAojIENPTkZJR19QV00gaXMgbm90IHNldAojIENPTkZJ
R19JUEFDS19CVVMgaXMgbm90IHNldAoKIwojIEZpcm13YXJlIERyaXZlcnMKIwojIENPTkZJ
R19FREQgaXMgbm90IHNldApDT05GSUdfRklSTVdBUkVfTUVNTUFQPXkKIyBDT05GSUdfREVM
TF9SQlUgaXMgbm90IHNldAojIENPTkZJR19EQ0RCQVMgaXMgbm90IHNldApDT05GSUdfRE1J
SUQ9eQpDT05GSUdfRE1JX1NZU0ZTPXkKIyBDT05GSUdfSVNDU0lfSUJGVF9GSU5EIGlzIG5v
dCBzZXQKIyBDT05GSUdfR09PR0xFX0ZJUk1XQVJFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5
c3RlbXMKIwpDT05GSUdfRENBQ0hFX1dPUkRfQUNDRVNTPXkKIyBDT05GSUdfRVhUMl9GUyBp
cyBub3Qgc2V0CkNPTkZJR19FWFQzX0ZTPXkKIyBDT05GSUdfRVhUM19ERUZBVUxUU19UT19P
UkRFUkVEIGlzIG5vdCBzZXQKQ09ORklHX0VYVDNfRlNfWEFUVFI9eQpDT05GSUdfRVhUM19G
U19QT1NJWF9BQ0w9eQpDT05GSUdfRVhUM19GU19TRUNVUklUWT15CkNPTkZJR19FWFQ0X0ZT
PXkKQ09ORklHX0VYVDRfVVNFX0ZPUl9FWFQyMz15CiMgQ09ORklHX0VYVDRfRlNfUE9TSVhf
QUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUNF9GU19TRUNVUklUWSBpcyBub3Qgc2V0CkNP
TkZJR19FWFQ0X0RFQlVHPXkKQ09ORklHX0pCRD15CiMgQ09ORklHX0pCRF9ERUJVRyBpcyBu
b3Qgc2V0CkNPTkZJR19KQkQyPXkKQ09ORklHX0pCRDJfREVCVUc9eQpDT05GSUdfRlNfTUJD
QUNIRT15CiMgQ09ORklHX1JFSVNFUkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZTX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfWEZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0dGUzJfRlM9
eQpDT05GSUdfQlRSRlNfRlM9eQpDT05GSUdfQlRSRlNfRlNfUE9TSVhfQUNMPXkKIyBDT05G
SUdfQlRSRlNfRlNfQ0hFQ0tfSU5URUdSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfTklMRlMy
X0ZTIGlzIG5vdCBzZXQKQ09ORklHX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19GSUxFX0xPQ0tJ
Tkc9eQpDT05GSUdfRlNOT1RJRlk9eQpDT05GSUdfRE5PVElGWT15CkNPTkZJR19JTk9USUZZ
X1VTRVI9eQojIENPTkZJR19GQU5PVElGWSBpcyBub3Qgc2V0CkNPTkZJR19RVU9UQT15CkNP
TkZJR19RVU9UQV9ORVRMSU5LX0lOVEVSRkFDRT15CiMgQ09ORklHX1BSSU5UX1FVT1RBX1dB
Uk5JTkcgaXMgbm90IHNldAojIENPTkZJR19RVU9UQV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJ
R19RVU9UQV9UUkVFPXkKIyBDT05GSUdfUUZNVF9WMSBpcyBub3Qgc2V0CkNPTkZJR19RRk1U
X1YyPXkKQ09ORklHX1FVT1RBQ1RMPXkKQ09ORklHX1FVT1RBQ1RMX0NPTVBBVD15CkNPTkZJ
R19BVVRPRlM0X0ZTPXkKQ09ORklHX0ZVU0VfRlM9eQojIENPTkZJR19DVVNFIGlzIG5vdCBz
ZXQKQ09ORklHX0dFTkVSSUNfQUNMPXkKCiMKIyBDYWNoZXMKIwpDT05GSUdfRlNDQUNIRT15
CkNPTkZJR19GU0NBQ0hFX1NUQVRTPXkKQ09ORklHX0ZTQ0FDSEVfSElTVE9HUkFNPXkKIyBD
T05GSUdfRlNDQUNIRV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTQ0FDSEVfT0JKRUNU
X0xJU1QgaXMgbm90IHNldAojIENPTkZJR19DQUNIRUZJTEVTIGlzIG5vdCBzZXQKCiMKIyBD
RC1ST00vRFZEIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0lTTzk2NjBfRlM9eQpDT05GSUdfSk9M
SUVUPXkKQ09ORklHX1pJU09GUz15CiMgQ09ORklHX1VERl9GUyBpcyBub3Qgc2V0CgojCiMg
RE9TL0ZBVC9OVCBGaWxlc3lzdGVtcwojCkNPTkZJR19GQVRfRlM9eQpDT05GSUdfTVNET1Nf
RlM9eQpDT05GSUdfVkZBVF9GUz15CkNPTkZJR19GQVRfREVGQVVMVF9DT0RFUEFHRT00MzcK
Q09ORklHX0ZBVF9ERUZBVUxUX0lPQ0hBUlNFVD0iaXNvODg1OS0xIgpDT05GSUdfTlRGU19G
Uz15CiMgQ09ORklHX05URlNfREVCVUcgaXMgbm90IHNldApDT05GSUdfTlRGU19SVz15Cgoj
CiMgUHNldWRvIGZpbGVzeXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJPQ19L
Q09SRT15CkNPTkZJR19QUk9DX1ZNQ09SRT15CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJ
R19QUk9DX1BBR0VfTU9OSVRPUj15CkNPTkZJR19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNP
TkZJR19UTVBGU19QT1NJWF9BQ0w9eQpDT05GSUdfVE1QRlNfWEFUVFI9eQpDT05GSUdfSFVH
RVRMQkZTPXkKQ09ORklHX0hVR0VUTEJfUEFHRT15CiMgQ09ORklHX0NPTkZJR0ZTX0ZTIGlz
IG5vdCBzZXQKIyBDT05GSUdfTUlTQ19GSUxFU1lTVEVNUyBpcyBub3Qgc2V0CkNPTkZJR19O
RVRXT1JLX0ZJTEVTWVNURU1TPXkKIyBDT05GSUdfTkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfTkZTRCBpcyBub3Qgc2V0CkNPTkZJR19DRVBIX0ZTPXkKIyBDT05GSUdfQ0lGUyBpcyBu
b3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0NPREFfRlMgaXMg
bm90IHNldAojIENPTkZJR19BRlNfRlMgaXMgbm90IHNldApDT05GSUdfTkxTPXkKQ09ORklH
X05MU19ERUZBVUxUPSJ1dGY4IgpDT05GSUdfTkxTX0NPREVQQUdFXzQzNz15CiMgQ09ORklH
X05MU19DT0RFUEFHRV83MzcgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1
IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MCBpcyBub3Qgc2V0CiMgQ09O
RklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf
ODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NyBpcyBub3Qgc2V0CiMg
Q09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB
R0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBpcyBub3Qgc2V0
CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E
RVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NSBpcyBub3Qg
c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldAojIENPTkZJR19OTFNf
Q09ERVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzNiBpcyBu
b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldAojIENPTkZJR19O
TFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMgbm90IHNldAojIENPTkZJ
R19OTFNfSVNPODg1OV84IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTAg
aXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBpcyBub3Qgc2V0CkNPTkZJ
R19OTFNfQVNDSUk9eQpDT05GSUdfTkxTX0lTTzg4NTlfMT15CiMgQ09ORklHX05MU19JU084
ODU5XzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8zIGlzIG5vdCBzZXQKIyBD
T05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzUg
aXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV82IGlzIG5vdCBzZXQKIyBDT05GSUdf
TkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90
IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xMyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J
U084ODU5XzE0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMTUgaXMgbm90IHNl
dAojIENPTkZJR19OTFNfS09JOF9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0tPSThfVSBp
cyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfUk9NQU4gaXMgbm90IHNldAojIENPTkZJR19O
TFNfTUFDX0NFTFRJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfQ0VOVEVVUk8gaXMg
bm90IHNldAojIENPTkZJR19OTFNfTUFDX0NST0FUSUFOIGlzIG5vdCBzZXQKIyBDT05GSUdf
TkxTX01BQ19DWVJJTExJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfR0FFTElDIGlz
IG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19HUkVFSyBpcyBub3Qgc2V0CiMgQ09ORklHX05M
U19NQUNfSUNFTEFORCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfSU5VSVQgaXMgbm90
IHNldAojIENPTkZJR19OTFNfTUFDX1JPTUFOSUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT
X01BQ19UVVJLSVNIIGlzIG5vdCBzZXQKQ09ORklHX05MU19VVEY4PXkKCiMKIyBLZXJuZWwg
aGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JUPXkKQ09ORklHX1BSSU5U
S19USU1FPXkKQ09ORklHX0RFRkFVTFRfTUVTU0FHRV9MT0dMRVZFTD02CiMgQ09ORklHX0VO
QUJMRV9XQVJOX0RFUFJFQ0FURUQgaXMgbm90IHNldAojIENPTkZJR19FTkFCTEVfTVVTVF9D
SEVDSyBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKQ09ORklHX01BR0lDX1NZ
U1JRPXkKIyBDT05GSUdfU1RSSVBfQVNNX1NZTVMgaXMgbm90IHNldAojIENPTkZJR19SRUFE
QUJMRV9BU00gaXMgbm90IHNldAojIENPTkZJR19VTlVTRURfU1lNQk9MUyBpcyBub3Qgc2V0
CkNPTkZJR19ERUJVR19GUz15CiMgQ09ORklHX0hFQURFUlNfQ0hFQ0sgaXMgbm90IHNldAoj
IENPTkZJR19ERUJVR19TRUNUSU9OX01JU01BVENIIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVH
X0tFUk5FTD15CkNPTkZJR19ERUJVR19TSElSUT15CkNPTkZJR19MT0NLVVBfREVURUNUT1I9
eQpDT05GSUdfSEFSRExPQ0tVUF9ERVRFQ1RPUj15CiMgQ09ORklHX0JPT1RQQVJBTV9IQVJE
TE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklHX0JPT1RQQVJBTV9IQVJETE9DS1VQX1BB
TklDX1ZBTFVFPTAKIyBDT05GSUdfQk9PVFBBUkFNX1NPRlRMT0NLVVBfUEFOSUMgaXMgbm90
IHNldApDT05GSUdfQk9PVFBBUkFNX1NPRlRMT0NLVVBfUEFOSUNfVkFMVUU9MAojIENPTkZJ
R19QQU5JQ19PTl9PT1BTIGlzIG5vdCBzZXQKQ09ORklHX1BBTklDX09OX09PUFNfVkFMVUU9
MApDT05GSUdfREVURUNUX0hVTkdfVEFTSz15CkNPTkZJR19ERUZBVUxUX0hVTkdfVEFTS19U
SU1FT1VUPTEyMAojIENPTkZJR19CT09UUEFSQU1fSFVOR19UQVNLX1BBTklDIGlzIG5vdCBz
ZXQKQ09ORklHX0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUNfVkFMVUU9MAojIENPTkZJR19T
Q0hFRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ0hFRFNUQVRTPXkKQ09ORklHX1RJTUVS
X1NUQVRTPXkKIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NM
VUJfREVCVUdfT04gaXMgbm90IHNldAojIENPTkZJR19TTFVCX1NUQVRTIGlzIG5vdCBzZXQK
Q09ORklHX0hBVkVfREVCVUdfS01FTUxFQUs9eQpDT05GSUdfREVCVUdfS01FTUxFQUs9eQpD
T05GSUdfREVCVUdfS01FTUxFQUtfRUFSTFlfTE9HX1NJWkU9NDAwCiMgQ09ORklHX0RFQlVH
X0tNRU1MRUFLX1RFU1QgaXMgbm90IHNldApDT05GSUdfREVCVUdfS01FTUxFQUtfREVGQVVM
VF9PRkY9eQpDT05GSUdfREVCVUdfUFJFRU1QVD15CkNPTkZJR19ERUJVR19SVF9NVVRFWEVT
PXkKQ09ORklHX0RFQlVHX1BJX0xJU1Q9eQojIENPTkZJR19SVF9NVVRFWF9URVNURVIgaXMg
bm90IHNldApDT05GSUdfREVCVUdfU1BJTkxPQ0s9eQpDT05GSUdfREVCVUdfTVVURVhFUz15
CkNPTkZJR19ERUJVR19MT0NLX0FMTE9DPXkKQ09ORklHX1BST1ZFX0xPQ0tJTkc9eQpDT05G
SUdfTE9DS0RFUD15CiMgQ09ORklHX0xPQ0tfU1RBVCBpcyBub3Qgc2V0CkNPTkZJR19ERUJV
R19MT0NLREVQPXkKQ09ORklHX1RSQUNFX0lSUUZMQUdTPXkKIyBDT05GSUdfREVCVUdfQVRP
TUlDX1NMRUVQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS0lOR19BUElfU0VMRlRF
U1RTIGlzIG5vdCBzZXQKQ09ORklHX1NUQUNLVFJBQ0U9eQojIENPTkZJR19ERUJVR19TVEFD
S19VU0FHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0tPQkpFQ1QgaXMgbm90IHNldApD
T05GSUdfREVCVUdfQlVHVkVSQk9TRT15CkNPTkZJR19ERUJVR19JTkZPPXkKIyBDT05GSUdf
REVCVUdfSU5GT19SRURVQ0VEIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVk0gaXMgbm90
IHNldAojIENPTkZJR19ERUJVR19WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX1dS
SVRFQ09VTlQ9eQpDT05GSUdfREVCVUdfTUVNT1JZX0lOSVQ9eQpDT05GSUdfREVCVUdfTElT
VD15CiMgQ09ORklHX1RFU1RfTElTVF9TT1JUIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX1NH
PXkKIyBDT05GSUdfREVCVUdfTk9USUZJRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf
Q1JFREVOVElBTFMgaXMgbm90IHNldApDT05GSUdfQVJDSF9XQU5UX0ZSQU1FX1BPSU5URVJT
PXkKQ09ORklHX0ZSQU1FX1BPSU5URVI9eQojIENPTkZJR19CT09UX1BSSU5US19ERUxBWSBp
cyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1BST1ZFX1JDVSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1BST1ZFX1JDVV9ERUxBWSBpcyBub3Qgc2V0CkNPTkZJR19TUEFS
U0VfUkNVX1BPSU5URVI9eQojIENPTkZJR19SQ1VfVE9SVFVSRV9URVNUIGlzIG5vdCBzZXQK
Q09ORklHX1JDVV9DUFVfU1RBTExfVElNRU9VVD02MApDT05GSUdfUkNVX0NQVV9TVEFMTF9W
RVJCT1NFPXkKQ09ORklHX1JDVV9DUFVfU1RBTExfSU5GTz15CiMgQ09ORklHX1JDVV9UUkFD
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0JBQ0tUUkFDRV9TRUxGX1RFU1QgaXMgbm90IHNldAoj
IENPTkZJR19ERUJVR19CTE9DS19FWFRfREVWVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVH
X0ZPUkNFX1dFQUtfUEVSX0NQVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1BFUl9DUFVf
TUFQUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xLRFRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTk9U
SUZJRVJfRVJST1JfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkFVTFRfSU5KRUNU
SU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFURU5DWVRPUCBpcyBub3Qgc2V0CiMgQ09ORklH
X0RFQlVHX1BBR0VBTExPQyBpcyBub3Qgc2V0CkNPTkZJR19VU0VSX1NUQUNLVFJBQ0VfU1VQ
UE9SVD15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNU
SU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX0ZQX1RFU1Q9
eQpDT05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRV9NQ09VTlRfVEVTVD15CkNPTkZJR19IQVZF
X0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0hBVkVfRFlOQU1JQ19GVFJBQ0VfV0lUSF9SRUdT
PXkKQ09ORklHX0hBVkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVND
QUxMX1RSQUNFUE9JTlRTPXkKQ09ORklHX0hBVkVfRkVOVFJZPXkKQ09ORklHX0hBVkVfQ19S
RUNPUkRNQ09VTlQ9eQpDT05GSUdfVFJBQ0lOR19TVVBQT1JUPXkKIyBDT05GSUdfRlRSQUNF
IGlzIG5vdCBzZXQKIyBDT05GSUdfUkJUUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19J
TlRFUlZBTF9UUkVFX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19QUk9WSURFX09IQ0kxMzk0
X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19ERUJVRyBpcyBub3Qgc2V0
CkNPTkZJR19ETUFfQVBJX0RFQlVHPXkKIyBDT05GSUdfQVRPTUlDNjRfU0VMRlRFU1QgaXMg
bm90IHNldAojIENPTkZJR19TQU1QTEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJDSF9L
R0RCPXkKIyBDT05GSUdfS0dEQiBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfS01FTUNI
RUNLPXkKIyBDT05GSUdfS01FTUNIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9LU1RS
VE9YIGlzIG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZFUkJP
U0VfQk9PVFVQPXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BSSU5U
S19EQkdQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qg
c2V0CiMgQ09ORklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRB
PXkKIyBDT05GSUdfREVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJV
R19TRVRfTU9EVUxFX1JPTlggaXMgbm90IHNldAojIENPTkZJR19ERUJVR19OWF9URVNUIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVExCRkxVU0ggaXMgbm90IHNldApDT05GSUdfSU9N
TVVfREVCVUc9eQojIENPTkZJR19JT01NVV9TVFJFU1MgaXMgbm90IHNldApDT05GSUdfSU9N
TVVfTEVBSz15CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RF
TEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9f
REVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklH
X0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBD
T05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9O
RSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MApDT05GSUdfREVC
VUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMgbm90IHNldAojIENPTkZJ
R19PUFRJTUlaRV9JTkxJTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NUUklDVF9V
U0VSX0NPUFlfQ0hFQ0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk1JX1NFTEZURVNU
IGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMKQ09ORklHX0tFWVM9eQojIENP
TkZJR19FTkNSWVBURURfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWVNfREVCVUdfUFJP
Q19LRVlTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJQ1QgaXMg
bm90IHNldAojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZ
RlMgaXMgbm90IHNldAojIENPTkZJR19JTlRFTF9UWFQgaXMgbm90IHNldApDT05GSUdfREVG
QVVMVF9TRUNVUklUWV9EQUM9eQpDT05GSUdfREVGQVVMVF9TRUNVUklUWT0iIgpDT05GSUdf
Q1JZUFRPPXkKCiMKIyBDcnlwdG8gY29yZSBvciBoZWxwZXIKIwpDT05GSUdfQ1JZUFRPX0FM
R0FQST15CkNPTkZJR19DUllQVE9fQUxHQVBJMj15CkNPTkZJR19DUllQVE9fQUVBRD15CkNP
TkZJR19DUllQVE9fQUVBRDI9eQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUj15CkNPTkZJR19D
UllQVE9fQkxLQ0lQSEVSMj15CkNPTkZJR19DUllQVE9fSEFTSD15CkNPTkZJR19DUllQVE9f
SEFTSDI9eQpDT05GSUdfQ1JZUFRPX1JORz15CkNPTkZJR19DUllQVE9fUk5HMj15CkNPTkZJ
R19DUllQVE9fUENPTVA9eQpDT05GSUdfQ1JZUFRPX1BDT01QMj15CkNPTkZJR19DUllQVE9f
TUFOQUdFUj15CkNPTkZJR19DUllQVE9fTUFOQUdFUjI9eQojIENPTkZJR19DUllQVE9fVVNF
UiBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fTUFOQUdFUl9ESVNBQkxFX1RFU1RTPXkKQ09O
RklHX0NSWVBUT19HRjEyOE1VTD15CiMgQ09ORklHX0NSWVBUT19OVUxMIGlzIG5vdCBzZXQK
IyBDT05GSUdfQ1JZUFRPX1BDUllQVCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fV09SS1FV
RVVFPXkKQ09ORklHX0NSWVBUT19DUllQVEQ9eQpDT05GSUdfQ1JZUFRPX0FVVEhFTkM9eQoj
IENPTkZJR19DUllQVE9fVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fQUJMS19IRUxQ
RVJfWDg2PXkKQ09ORklHX0NSWVBUT19HTFVFX0hFTFBFUl9YODY9eQoKIwojIEF1dGhlbnRp
Y2F0ZWQgRW5jcnlwdGlvbiB3aXRoIEFzc29jaWF0ZWQgRGF0YQojCiMgQ09ORklHX0NSWVBU
T19DQ00gaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fR0NNIGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1NFUUlWIGlzIG5vdCBzZXQKCiMKIyBCbG9jayBtb2RlcwojCkNPTkZJR19D
UllQVE9fQ0JDPXkKIyBDT05GSUdfQ1JZUFRPX0NUUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
WVBUT19DVFMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0VDQj15CkNPTkZJR19DUllQVE9f
TFJXPXkKIyBDT05GSUdfQ1JZUFRPX1BDQkMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1hU
Uz15CgojCiMgSGFzaCBtb2RlcwojCkNPTkZJR19DUllQVE9fSE1BQz15CiMgQ09ORklHX0NS
WVBUT19YQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1ZNQUMgaXMgbm90IHNldAoK
IwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKQ09ORklHX0NSWVBUT19DUkMz
MkNfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19DUkMzMkNfSU5URUw9eQojIENPTkZJR19DUllQ
VE9fR0hBU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTUQ0IGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19NRDU9eQojIENPTkZJR19DUllQVE9fTUlDSEFFTF9NSUMgaXMgbm90IHNl
dAojIENPTkZJR19DUllQVE9fUk1EMTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1JN
RDE2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19STUQyNTYgaXMgbm90IHNldAojIENP
TkZJR19DUllQVE9fUk1EMzIwIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19TSEExPXkKQ09O
RklHX0NSWVBUT19TSEExX1NTU0UzPXkKQ09ORklHX0NSWVBUT19TSEEyNTY9eQojIENPTkZJ
R19DUllQVE9fU0hBNTEyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1RHUjE5MiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NSWVBUT19XUDUxMiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU
T19HSEFTSF9DTE1VTF9OSV9JTlRFTCBpcyBub3Qgc2V0CgojCiMgQ2lwaGVycwojCkNPTkZJ
R19DUllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0PXkKQ09ORklHX0NSWVBU
T19BRVNfTklfSU5URUw9eQojIENPTkZJR19DUllQVE9fQU5VQklTIGlzIG5vdCBzZXQKQ09O
RklHX0NSWVBUT19BUkM0PXkKQ09ORklHX0NSWVBUT19CTE9XRklTSD15CkNPTkZJR19DUllQ
VE9fQkxPV0ZJU0hfQ09NTU9OPXkKQ09ORklHX0NSWVBUT19CTE9XRklTSF9YODZfNjQ9eQoj
IENPTkZJR19DUllQVE9fQ0FNRUxMSUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FN
RUxMSUFfWDg2XzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBTUVMTElBX0FFU05J
X0FWWF9YODZfNjQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDUgaXMgbm90IHNl
dAojIENPTkZJR19DUllQVE9fQ0FTVDVfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CiMgQ09ORklH
X0NSWVBUT19DQVNUNiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DQVNUNl9BVlhfWDg2
XzY0IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19ERVM9eQojIENPTkZJR19DUllQVE9fRkNS
WVBUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0tIQVpBRCBpcyBub3Qgc2V0CiMgQ09O
RklHX0NSWVBUT19TQUxTQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NBTFNBMjBf
WDg2XzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFRUQgaXMgbm90IHNldApDT05G
SUdfQ1JZUFRPX1NFUlBFTlQ9eQpDT05GSUdfQ1JZUFRPX1NFUlBFTlRfU1NFMl9YODZfNjQ9
eQojIENPTkZJR19DUllQVE9fU0VSUEVOVF9BVlhfWDg2XzY0IGlzIG5vdCBzZXQKIyBDT05G
SUdfQ1JZUFRPX1RFQSBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fVFdPRklTSD15CkNPTkZJ
R19DUllQVE9fVFdPRklTSF9DT01NT049eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfWDg2XzY0
PXkKQ09ORklHX0NSWVBUT19UV09GSVNIX1g4Nl82NF8zV0FZPXkKIyBDT05GSUdfQ1JZUFRP
X1RXT0ZJU0hfQVZYX1g4Nl82NCBpcyBub3Qgc2V0CgojCiMgQ29tcHJlc3Npb24KIwpDT05G
SUdfQ1JZUFRPX0RFRkxBVEU9eQpDT05GSUdfQ1JZUFRPX1pMSUI9eQpDT05GSUdfQ1JZUFRP
X0xaTz15CgojCiMgUmFuZG9tIE51bWJlciBHZW5lcmF0aW9uCiMKQ09ORklHX0NSWVBUT19B
TlNJX0NQUk5HPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0ggaXMgbm90IHNldAoj
IENPTkZJR19DUllQVE9fVVNFUl9BUElfU0tDSVBIRVIgaXMgbm90IHNldAojIENPTkZJR19D
UllQVE9fSFcgaXMgbm90IHNldAojIENPTkZJR19BU1lNTUVUUklDX0tFWV9UWVBFIGlzIG5v
dCBzZXQKQ09ORklHX0hBVkVfS1ZNPXkKIyBDT05GSUdfVklSVFVBTElaQVRJT04gaXMgbm90
IHNldAojIENPTkZJR19CSU5BUllfUFJJTlRGIGlzIG5vdCBzZXQKCiMKIyBMaWJyYXJ5IHJv
dXRpbmVzCiMKQ09ORklHX0JJVFJFVkVSU0U9eQpDT05GSUdfR0VORVJJQ19TVFJOQ1BZX0ZS
T01fVVNFUj15CkNPTkZJR19HRU5FUklDX1NUUk5MRU5fVVNFUj15CkNPTkZJR19HRU5FUklD
X0ZJTkRfRklSU1RfQklUPXkKQ09ORklHX0dFTkVSSUNfUENJX0lPTUFQPXkKQ09ORklHX0dF
TkVSSUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19JTz15CkNPTkZJR19QRVJDUFVfUldTRU09
eQojIENPTkZJR19DUkNfQ0NJVFQgaXMgbm90IHNldApDT05GSUdfQ1JDMTY9eQpDT05GSUdf
Q1JDX1QxMERJRj15CiMgQ09ORklHX0NSQ19JVFVfVCBpcyBub3Qgc2V0CkNPTkZJR19DUkMz
Mj15CkNPTkZJR19DUkMzMl9TRUxGVEVTVD15CkNPTkZJR19DUkMzMl9TTElDRUJZOD15CiMg
Q09ORklHX0NSQzMyX1NMSUNFQlk0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDMzJfU0FSV0FU
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSQzMyX0JJVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS
QzcgaXMgbm90IHNldApDT05GSUdfTElCQ1JDMzJDPXkKIyBDT05GSUdfQ1JDOCBpcyBub3Qg
c2V0CkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPXkKQ09ORklH
X0xaT19DT01QUkVTUz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19YWl9ERUM9
eQpDT05GSUdfWFpfREVDX1g4Nj15CkNPTkZJR19YWl9ERUNfUE9XRVJQQz15CkNPTkZJR19Y
Wl9ERUNfSUE2ND15CkNPTkZJR19YWl9ERUNfQVJNPXkKQ09ORklHX1haX0RFQ19BUk1USFVN
Qj15CkNPTkZJR19YWl9ERUNfU1BBUkM9eQpDT05GSUdfWFpfREVDX0JDSj15CiMgQ09ORklH
X1haX0RFQ19URVNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15CkNPTkZJ
R19ERUNPTVBSRVNTX0JaSVAyPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpNQT15CkNPTkZJR19E
RUNPTVBSRVNTX1haPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpPPXkKQ09ORklHX1RFWFRTRUFS
Q0g9eQpDT05GSUdfVEVYVFNFQVJDSF9LTVA9eQpDT05GSUdfVEVYVFNFQVJDSF9CTT15CkNP
TkZJR19URVhUU0VBUkNIX0ZTTT15CkNPTkZJR19IQVNfSU9NRU09eQpDT05GSUdfSEFTX0lP
UE9SVD15CkNPTkZJR19IQVNfRE1BPXkKQ09ORklHX0NIRUNLX1NJR05BVFVSRT15CkNPTkZJ
R19DUFVfUk1BUD15CkNPTkZJR19EUUw9eQpDT05GSUdfTkxBVFRSPXkKQ09ORklHX0FSQ0hf
SEFTX0FUT01JQzY0X0RFQ19JRl9QT1NJVElWRT15CkNPTkZJR19BVkVSQUdFPXkKIyBDT05G
SUdfQ09SRElDIGlzIG5vdCBzZXQKIyBDT05GSUdfRERSIGlzIG5vdCBzZXQK
------------0791EC21F164E2952
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0791EC21F164E2952--



From xen-devel-bounces@lists.xen.org Mon Feb 25 22:29:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 22: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 1UA6XZ-00032h-8Z; Mon, 25 Feb 2013 22:28:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UA6XY-00032c-LN
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 22:28:56 +0000
Received: from [85.158.143.99:16965] by server-3.bemta-4.messagelabs.com id
	D3/44-02186-7A5EB215; Mon, 25 Feb 2013 22:28:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361831335!23874610!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7712 invoked from network); 25 Feb 2013 22:28:55 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 22:28:55 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:60965 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 1UA6Va-0003HC-0e
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 23:26:54 +0100
Date: Mon, 25 Feb 2013 23:28:53 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1208255021.20130225232853@eikelenboom.it>
To: xen-devel <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Changeset / commit id not incorporated in build after
	switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)

Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.

So what would be wise:
   - just replace the changeset with the git commit sha-1 hash (always)
   - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
   - make a separate "commit" entry besides the changeset and leave one undefined

xen/Makefile currently has:

# compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
include/xen/compile.h: include/xen/compile.h.in .banner
        @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
            -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
            -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
            -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
            -e 's/@@hostname@@/$(shell hostname)/g' \
            -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
            -e 's/@@version@@/$(XEN_VERSION)/g' \
            -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
            -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
            -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
            < include/xen/compile.h.in > $@.new
        @grep \" .banner >> $@.new
        @grep -v \" .banner
        @mv -f $@.new $@

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 22:29:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 22: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 1UA6XZ-00032h-8Z; Mon, 25 Feb 2013 22:28:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UA6XY-00032c-LN
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 22:28:56 +0000
Received: from [85.158.143.99:16965] by server-3.bemta-4.messagelabs.com id
	D3/44-02186-7A5EB215; Mon, 25 Feb 2013 22:28:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361831335!23874610!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7712 invoked from network); 25 Feb 2013 22:28:55 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 22:28:55 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:60965 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 1UA6Va-0003HC-0e
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 23:26:54 +0100
Date: Mon, 25 Feb 2013 23:28:53 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1208255021.20130225232853@eikelenboom.it>
To: xen-devel <xen-devel@lists.xen.org>
MIME-Version: 1.0
Subject: [Xen-devel] Changeset / commit id not incorporated in build after
	switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)

Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.

So what would be wise:
   - just replace the changeset with the git commit sha-1 hash (always)
   - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
   - make a separate "commit" entry besides the changeset and leave one undefined

xen/Makefile currently has:

# compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
include/xen/compile.h: include/xen/compile.h.in .banner
        @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
            -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
            -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
            -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
            -e 's/@@hostname@@/$(shell hostname)/g' \
            -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
            -e 's/@@version@@/$(XEN_VERSION)/g' \
            -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
            -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
            -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
            < include/xen/compile.h.in > $@.new
        @grep \" .banner >> $@.new
        @grep -v \" .banner
        @mv -f $@.new $@

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 23:00:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 23:00: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 1UA72B-0004AZ-M1; Mon, 25 Feb 2013 23:00:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UA72A-0004AS-9b
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 23:00:34 +0000
Received: from [85.158.139.211:48194] by server-3.bemta-5.messagelabs.com id
	41/1D-17256-11DEB215; Mon, 25 Feb 2013 23:00:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361833232!19220748!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7627 invoked from network); 25 Feb 2013 23:00:32 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 23:00:32 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:61005 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 1UA6zz-0003QS-Iy; Mon, 25 Feb 2013 23:58:19 +0100
Date: Tue, 26 Feb 2013 00:00:19 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1701027415.20130226000019@eikelenboom.it>
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1208255021.20130225232853@eikelenboom.it>
References: <1208255021.20130225232853@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
	after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Sander,

Monday, February 25, 2013, 11:28:53 PM, you wrote:

> Date: Mon, 25 Feb 2013 23:28:53 +0100
> From: Sander Eikelenboom <linux@eikelenboom.it>
> Organization: Eikelenboom IT services
> X-Priority: 3 (Normal)
> Message-ID: <1208255021.20130225232853@eikelenboom.it>
> To: xen-devel <xen-devel@lists.xen.org>
> Subject: Changeset / commit id not incorporated in build after switch to git
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit

> Hi All,

> After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
> This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)

> Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.

> So what would be wise:
>    - just replace the changeset with the git commit sha-1 hash (always)
>    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
>    - make a separate "commit" entry besides the changeset and leave one undefined

> xen/Makefile currently has:

> # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> include/xen/compile.h: include/xen/compile.h.in .banner
>         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
>             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
>             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
>             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
>             -e 's/@@hostname@@/$(shell hostname)/g' \
>             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
>             -e 's/@@version@@/$(XEN_VERSION)/g' \
>             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
>             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
>             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
>             < include/xen/compile.h.in > $@.new
>         @grep \" .banner >> $@.new
>         @grep -v \" .banner
>         @mv -f $@.new $@

> --
> Sander



Perhaps use about the same as linux has in scripts/setlocalversion ?

scm_version()
{
        local short
        short=false

        cd "$srctree"
        if test -e .scmversion; then
                cat .scmversion
                return
        fi
        if test "$1" = "--short"; then
                short=true
        fi

        # Check for git and a git repo.
        if test -d .git && head=`git rev-parse --verify --short HEAD 2>/dev/null`; then

                # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
                # it, because this version is defined in the top level Makefile.
                if [ -z "`git describe --exact-match 2>/dev/null`" ]; then

                        # If only the short version is requested, don't bother
                        # running further git commands
                        if $short; then
                                echo "+"
                                return
                        fi
                        # If we are past a tagged commit (like
                        # "v2.6.30-rc5-302-g72357d5"), we pretty print it.
                        if atag="`git describe 2>/dev/null`"; then
                                echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'

                        # If we don't have a tag at all we print -g{commitish}.
                        else
                                printf '%s%s' -g $head
                        fi
                fi

                # Is this git on svn?
                if git config --get svn-remote.svn.url >/dev/null; then
                        printf -- '-svn%s' "`git svn find-rev $head`"
                fi

                # Update index only on r/w media
                [ -w . ] && git update-index --refresh --unmerged > /dev/null

                # Check for uncommitted changes
                if git diff-index --name-only HEAD | grep -qv "^scripts/package"; then
                        printf '%s' -dirty
                fi

                # All done with git
                return
        fi

        # Check for mercurial and a mercurial repo.
        if test -d .hg && hgid=`hg id 2>/dev/null`; then
                # Do we have an tagged version?  If so, latesttagdistance == 1
                if [ "`hg log -r . --template '{latesttagdistance}'`" == "1" ]; then
                        id=`hg log -r . --template '{latesttag}'`
                        printf '%s%s' -hg "$id"
                else
                        tag=`printf '%s' "$hgid" | cut -d' ' -f2`
                        if [ -z "$tag" -o "$tag" = tip ]; then
                                id=`printf '%s' "$hgid" | sed 's/[+ ].*//'`
                                printf '%s%s' -hg "$id"
                        fi
                fi

                # Are there uncommitted changes?
                # These are represented by + after the changeset id.
                case "$hgid" in
                        *+|*+\ *) printf '%s' -dirty ;;
                esac

                # All done with mercurial
                return
        fi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 23:00:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 23:00: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 1UA72B-0004AZ-M1; Mon, 25 Feb 2013 23:00:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UA72A-0004AS-9b
	for xen-devel@lists.xen.org; Mon, 25 Feb 2013 23:00:34 +0000
Received: from [85.158.139.211:48194] by server-3.bemta-5.messagelabs.com id
	41/1D-17256-11DEB215; Mon, 25 Feb 2013 23:00:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361833232!19220748!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7627 invoked from network); 25 Feb 2013 23:00:32 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-2.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Feb 2013 23:00:32 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:61005 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 1UA6zz-0003QS-Iy; Mon, 25 Feb 2013 23:58:19 +0100
Date: Tue, 26 Feb 2013 00:00:19 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1701027415.20130226000019@eikelenboom.it>
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1208255021.20130225232853@eikelenboom.it>
References: <1208255021.20130225232853@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
	after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Sander,

Monday, February 25, 2013, 11:28:53 PM, you wrote:

> Date: Mon, 25 Feb 2013 23:28:53 +0100
> From: Sander Eikelenboom <linux@eikelenboom.it>
> Organization: Eikelenboom IT services
> X-Priority: 3 (Normal)
> Message-ID: <1208255021.20130225232853@eikelenboom.it>
> To: xen-devel <xen-devel@lists.xen.org>
> Subject: Changeset / commit id not incorporated in build after switch to git
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit

> Hi All,

> After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
> This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)

> Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.

> So what would be wise:
>    - just replace the changeset with the git commit sha-1 hash (always)
>    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
>    - make a separate "commit" entry besides the changeset and leave one undefined

> xen/Makefile currently has:

> # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> include/xen/compile.h: include/xen/compile.h.in .banner
>         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
>             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
>             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
>             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
>             -e 's/@@hostname@@/$(shell hostname)/g' \
>             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
>             -e 's/@@version@@/$(XEN_VERSION)/g' \
>             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
>             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
>             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
>             < include/xen/compile.h.in > $@.new
>         @grep \" .banner >> $@.new
>         @grep -v \" .banner
>         @mv -f $@.new $@

> --
> Sander



Perhaps use about the same as linux has in scripts/setlocalversion ?

scm_version()
{
        local short
        short=false

        cd "$srctree"
        if test -e .scmversion; then
                cat .scmversion
                return
        fi
        if test "$1" = "--short"; then
                short=true
        fi

        # Check for git and a git repo.
        if test -d .git && head=`git rev-parse --verify --short HEAD 2>/dev/null`; then

                # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
                # it, because this version is defined in the top level Makefile.
                if [ -z "`git describe --exact-match 2>/dev/null`" ]; then

                        # If only the short version is requested, don't bother
                        # running further git commands
                        if $short; then
                                echo "+"
                                return
                        fi
                        # If we are past a tagged commit (like
                        # "v2.6.30-rc5-302-g72357d5"), we pretty print it.
                        if atag="`git describe 2>/dev/null`"; then
                                echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'

                        # If we don't have a tag at all we print -g{commitish}.
                        else
                                printf '%s%s' -g $head
                        fi
                fi

                # Is this git on svn?
                if git config --get svn-remote.svn.url >/dev/null; then
                        printf -- '-svn%s' "`git svn find-rev $head`"
                fi

                # Update index only on r/w media
                [ -w . ] && git update-index --refresh --unmerged > /dev/null

                # Check for uncommitted changes
                if git diff-index --name-only HEAD | grep -qv "^scripts/package"; then
                        printf '%s' -dirty
                fi

                # All done with git
                return
        fi

        # Check for mercurial and a mercurial repo.
        if test -d .hg && hgid=`hg id 2>/dev/null`; then
                # Do we have an tagged version?  If so, latesttagdistance == 1
                if [ "`hg log -r . --template '{latesttagdistance}'`" == "1" ]; then
                        id=`hg log -r . --template '{latesttag}'`
                        printf '%s%s' -hg "$id"
                else
                        tag=`printf '%s' "$hgid" | cut -d' ' -f2`
                        if [ -z "$tag" -o "$tag" = tip ]; then
                                id=`printf '%s' "$hgid" | sed 's/[+ ].*//'`
                                printf '%s%s' -hg "$id"
                        fi
                fi

                # Are there uncommitted changes?
                # These are represented by + after the changeset id.
                case "$hgid" in
                        *+|*+\ *) printf '%s' -dirty ;;
                esac

                # All done with mercurial
                return
        fi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Feb 25 23:34:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 23:34: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 1UA7Y8-0005L6-L7; Mon, 25 Feb 2013 23:33:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1UA7Y7-0005L1-Q0
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 23:33:36 +0000
Received: from [85.158.138.51:61663] by server-3.bemta-3.messagelabs.com id
	4B/E8-31070-AC4FB215; Mon, 25 Feb 2013 23:33:30 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361835208!29219645!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13259 invoked from network); 25 Feb 2013 23:33:29 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 23:33:29 -0000
Received: from saboo.goop.org (50-1-97-2.dedicated.static.sonic.net
	[50.1.97.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 8F6922F4;
	Mon, 25 Feb 2013 15:33:27 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id CA5AC207DB;
	Mon, 25 Feb 2013 15:33:25 -0800 (PST)
Message-ID: <512BF4C5.5090100@goop.org>
Date: Mon, 25 Feb 2013 15:33:25 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190046.GA12258@phenom.dumpdata.com>
In-Reply-To: <20130225190046.GA12258@phenom.dumpdata.com>
X-Enigmail-Version: 1.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/25/2013 11:00 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
>> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
>>> And also put my name behind the mainternship.
>> I think you could also safely remove Jeremy these days?
> Jeremy, are you OK with me removing your name from it and
>> Maybe we should have a Linux style CREDITS file to retain the names of
>> historical contributors/maintainers?
> .. transferring it in a new CREDITS file?

Yup, no problem.

    J

>
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>
>>> ---
>>>  MAINTAINERS | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 0358a3e..e2252fc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
>>>  
>>>  LINUX (PV_OPS)
>>>  M:	Jeremy Fitzhardinge <jeremy@goop.org>
>>> +M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>  S:	Supported
>>> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>>>  
>>>  LINUX (XCP)
>>>  M:	Ian Campbell <ian.campbell@citrix.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 Mon Feb 25 23:34:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 25 Feb 2013 23:34: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 1UA7Y8-0005L6-L7; Mon, 25 Feb 2013 23:33:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1UA7Y7-0005L1-Q0
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 23:33:36 +0000
Received: from [85.158.138.51:61663] by server-3.bemta-3.messagelabs.com id
	4B/E8-31070-AC4FB215; Mon, 25 Feb 2013 23:33:30 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361835208!29219645!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13259 invoked from network); 25 Feb 2013 23:33:29 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Feb 2013 23:33:29 -0000
Received: from saboo.goop.org (50-1-97-2.dedicated.static.sonic.net
	[50.1.97.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 8F6922F4;
	Mon, 25 Feb 2013 15:33:27 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id CA5AC207DB;
	Mon, 25 Feb 2013 15:33:25 -0800 (PST)
Message-ID: <512BF4C5.5090100@goop.org>
Date: Mon, 25 Feb 2013 15:33:25 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190046.GA12258@phenom.dumpdata.com>
In-Reply-To: <20130225190046.GA12258@phenom.dumpdata.com>
X-Enigmail-Version: 1.5
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/25/2013 11:00 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
>> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
>>> And also put my name behind the mainternship.
>> I think you could also safely remove Jeremy these days?
> Jeremy, are you OK with me removing your name from it and
>> Maybe we should have a Linux style CREDITS file to retain the names of
>> historical contributors/maintainers?
> .. transferring it in a new CREDITS file?

Yup, no problem.

    J

>
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>
>>> ---
>>>  MAINTAINERS | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 0358a3e..e2252fc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -193,8 +193,9 @@ F:	xen/include/xen/iommu.h
>>>  
>>>  LINUX (PV_OPS)
>>>  M:	Jeremy Fitzhardinge <jeremy@goop.org>
>>> +M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>  S:	Supported
>>> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>>>  
>>>  LINUX (XCP)
>>>  M:	Ian Campbell <ian.campbell@citrix.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 Feb 26 01:05:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 01:05: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 1UA8yC-0003SG-VU; Tue, 26 Feb 2013 01:04:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UA8yB-0003SB-PG
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 01:04:35 +0000
Received: from [85.158.143.99:26105] by server-1.bemta-4.messagelabs.com id
	AA/5D-06203-32A0C215; Tue, 26 Feb 2013 01:04:35 +0000
X-Env-Sender: sahilsuneja@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361840673!25824462!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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2716 invoked from network); 26 Feb 2013 01:04:34 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 01:04:34 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UA8y8-00057w-JI
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 17:04:32 -0800
Date: Mon, 25 Feb 2013 17:04:32 -0800 (PST)
From: sahilsuneja <sahilsuneja@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1361840672591-5714431.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Issues with Xenpaging in Xen-4.2.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,

I know Xenpaging is still at an experimental stage, but I still wanted to
test it out. Sadly, I could not get it to work reliably.

I have an AMD RVI enabled linux 3.2 host, and I am using linux 2.6.35-22 HVM
guests. After booting a few guests normally upto the host RAM limit, I do
the following to enable paging for a few guests:

/>/usr/lib/xen/bin/xenpaging -f /var/lib/xen/xenpaging/pagefile-hvm-guest -d
1 &
>xenstore-write /local/domain/1/memory/target-tot_pages $((1024*512))/

(here '1' is the dom_id and pagefile-hvm-guest is the backing paging file
for the hvm guest)

I am then able to boot more VMs and I can see the corresponding pagefiles
increase in size for the xenpaging enabled guests.

The problem is when I go back to the guests on which I enabled xenpaging, I
see the following errors when I run any basic commands like vim, top, less
/proc/meminfo:

/xc: error: Error populating page 100: Internal error
xc: error: Error loading 100 during page-in (22 = Invalid argument):
Internal error/

This happens even when there is paged-out memory from other guests to be
had, and the system is not out of RAM for paging in guest's memory.

It seems like a page-in error on gfn 100, but that is strange as, from I
what I gathered from the xenpaging code, policy_default.c starts paging only
after half of the guest's gfns : current_gfn = max_pages / 2 (inside
policy_default.c: policy_init())

I was expecting there to be other stability issues rather that this kind of
an error.

Could someone please help me understand this and let me know if I am doing
something incorrectly. 

Also, there do not seem to be any interesting messages in xm dmesg or in
/var/log/xen*.

Thanks,

Sahil Suneja
Ph.D. Student
University of Toronto



--
View this message in context: http://xen.1045712.n5.nabble.com/Issues-with-Xenpaging-in-Xen-4-2-1-tp5714431.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 Feb 26 01:05:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 01:05: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 1UA8yC-0003SG-VU; Tue, 26 Feb 2013 01:04:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UA8yB-0003SB-PG
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 01:04:35 +0000
Received: from [85.158.143.99:26105] by server-1.bemta-4.messagelabs.com id
	AA/5D-06203-32A0C215; Tue, 26 Feb 2013 01:04:35 +0000
X-Env-Sender: sahilsuneja@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361840673!25824462!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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2716 invoked from network); 26 Feb 2013 01:04:34 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 01:04:34 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UA8y8-00057w-JI
	for xen-devel@lists.xensource.com; Mon, 25 Feb 2013 17:04:32 -0800
Date: Mon, 25 Feb 2013 17:04:32 -0800 (PST)
From: sahilsuneja <sahilsuneja@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1361840672591-5714431.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Issues with Xenpaging in Xen-4.2.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,

I know Xenpaging is still at an experimental stage, but I still wanted to
test it out. Sadly, I could not get it to work reliably.

I have an AMD RVI enabled linux 3.2 host, and I am using linux 2.6.35-22 HVM
guests. After booting a few guests normally upto the host RAM limit, I do
the following to enable paging for a few guests:

/>/usr/lib/xen/bin/xenpaging -f /var/lib/xen/xenpaging/pagefile-hvm-guest -d
1 &
>xenstore-write /local/domain/1/memory/target-tot_pages $((1024*512))/

(here '1' is the dom_id and pagefile-hvm-guest is the backing paging file
for the hvm guest)

I am then able to boot more VMs and I can see the corresponding pagefiles
increase in size for the xenpaging enabled guests.

The problem is when I go back to the guests on which I enabled xenpaging, I
see the following errors when I run any basic commands like vim, top, less
/proc/meminfo:

/xc: error: Error populating page 100: Internal error
xc: error: Error loading 100 during page-in (22 = Invalid argument):
Internal error/

This happens even when there is paged-out memory from other guests to be
had, and the system is not out of RAM for paging in guest's memory.

It seems like a page-in error on gfn 100, but that is strange as, from I
what I gathered from the xenpaging code, policy_default.c starts paging only
after half of the guest's gfns : current_gfn = max_pages / 2 (inside
policy_default.c: policy_init())

I was expecting there to be other stability issues rather that this kind of
an error.

Could someone please help me understand this and let me know if I am doing
something incorrectly. 

Also, there do not seem to be any interesting messages in xm dmesg or in
/var/log/xen*.

Thanks,

Sahil Suneja
Ph.D. Student
University of Toronto



--
View this message in context: http://xen.1045712.n5.nabble.com/Issues-with-Xenpaging-in-Xen-4-2-1-tp5714431.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 Feb 26 02:12:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 02: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 1UAA1F-0005XL-7q; Tue, 26 Feb 2013 02:11:49 +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 1UAA1D-0005XG-9L
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 02:11:47 +0000
Received: from [85.158.137.99:49861] by server-14.bemta-3.messagelabs.com id
	49/9A-23533-2E91C215; Tue, 26 Feb 2013 02:11:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361844705!14901223!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 875 invoked from network); 26 Feb 2013 02:11:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 02:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="1870039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 02:11: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.297.1; Tue, 26 Feb 2013 02:11:45 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAA1B-0003z4-45;
	Tue, 26 Feb 2013 02:11:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAA1B-0004iY-0v;
	Tue, 26 Feb 2013 02:11:45 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16681-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 02:11:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16681: 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 16681 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1  8 guest-saverestore  fail REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore       fail pass in 16236
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install       fail pass in 16468
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot    fail in 16236 pass in 16681
 test-amd64-i386-xl-qemut-win-vcpus1 3 host-install(3) broken in 16236 pass in 16681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

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-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16236 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 16236 never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 02:12:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 02: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 1UAA1F-0005XL-7q; Tue, 26 Feb 2013 02:11:49 +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 1UAA1D-0005XG-9L
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 02:11:47 +0000
Received: from [85.158.137.99:49861] by server-14.bemta-3.messagelabs.com id
	49/9A-23533-2E91C215; Tue, 26 Feb 2013 02:11:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361844705!14901223!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 875 invoked from network); 26 Feb 2013 02:11:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 02:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; 
   d="scan'208";a="1870039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 02:11: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.297.1; Tue, 26 Feb 2013 02:11:45 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAA1B-0003z4-45;
	Tue, 26 Feb 2013 02:11:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAA1B-0004iY-0v;
	Tue, 26 Feb 2013 02:11:45 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16681-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 02:11:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16681: 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 16681 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win-vcpus1  8 guest-saverestore  fail REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-win-vcpus1  8 guest-saverestore       fail pass in 16236
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install       fail pass in 16468
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot    fail in 16236 pass in 16681
 test-amd64-i386-xl-qemut-win-vcpus1 3 host-install(3) broken in 16236 pass in 16681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

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-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-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-qemut-win7-amd64 13 guest-stop             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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16236 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop      fail in 16236 never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 03:07:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 03: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 1UAAsp-0006sK-UN; Tue, 26 Feb 2013 03:07:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAAso-0006sF-8f
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 03:07:10 +0000
Received: from [85.158.139.83:39318] by server-2.bemta-5.messagelabs.com id
	27/46-23989-CD62C215; Tue, 26 Feb 2013 03:07:08 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361848026!28955633!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ3MDU2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21992 invoked from network); 26 Feb 2013 03:07:07 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 03:07:07 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1Q372Et008436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 03:07: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
	r1Q372vJ004360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 03:07:02 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1Q371uL003242; Mon, 25 Feb 2013 21:07:01 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 19:07:01 -0800
Message-ID: <512C26F5.8020100@oracle.com>
Date: Tue, 26 Feb 2013 11:07:33 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: netdev@vger.kernel.org, konrad.wilk@oracle.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen
 network 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

What the version are these patches based on?
I tried v3.8-rc7 and 3.8-rc6, patch 3/8, 4/8 ... can not be merged 
successfully. Can you rebase it?

Thanks
Annie

On 2013-2-16 0:00, Wei Liu wrote:
> This patch series contains a small fix plus mechanical works for xen network
> driver.
>
>   * bug fix: don't bind kthread to specific cpu core
>   * allow host admin to unload netback
>   * multi-page ring support
>   * split event channels support
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 03:07:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 03: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 1UAAsp-0006sK-UN; Tue, 26 Feb 2013 03:07:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAAso-0006sF-8f
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 03:07:10 +0000
Received: from [85.158.139.83:39318] by server-2.bemta-5.messagelabs.com id
	27/46-23989-CD62C215; Tue, 26 Feb 2013 03:07:08 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1361848026!28955633!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ3MDU2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21992 invoked from network); 26 Feb 2013 03:07:07 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 03:07:07 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1Q372Et008436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 03:07: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
	r1Q372vJ004360
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 03:07:02 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1Q371uL003242; Mon, 25 Feb 2013 21:07:01 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 19:07:01 -0800
Message-ID: <512C26F5.8020100@oracle.com>
Date: Tue, 26 Feb 2013 11:07:33 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: netdev@vger.kernel.org, konrad.wilk@oracle.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen
 network 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

What the version are these patches based on?
I tried v3.8-rc7 and 3.8-rc6, patch 3/8, 4/8 ... can not be merged 
successfully. Can you rebase it?

Thanks
Annie

On 2013-2-16 0:00, Wei Liu wrote:
> This patch series contains a small fix plus mechanical works for xen network
> driver.
>
>   * bug fix: don't bind kthread to specific cpu core
>   * allow host admin to unload netback
>   * multi-page ring support
>   * split event channels support
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 03:34:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 03: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 1UABIP-0007ja-Pk; Tue, 26 Feb 2013 03:33:37 +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 1UABIN-0007jV-U5
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 03:33:36 +0000
Received: from [85.158.137.99:51924] by server-16.bemta-3.messagelabs.com id
	19/29-02727-F0D2C215; Tue, 26 Feb 2013 03:33:35 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361849574!14778612!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxOTc3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19967 invoked from network); 26 Feb 2013 03:32:55 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 03:32:55 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 25 Feb 2013 19:32:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,736,1355126400"; d="scan'208";a="295867772"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 25 Feb 2013 19:32:52 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 19:32:52 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.51]) by
	SHSMSX103.ccr.corp.intel.com ([10.239.4.69]) with mapi id
	14.01.0355.002; Tue, 26 Feb 2013 11:32:50 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
Thread-Index: AQHOEyPJ9tWSzP5xh0+Cca//iHZcEZiKN5CAgAE+f0A=
Date: Tue, 26 Feb 2013 03:32:49 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302251600180.5360@kaball.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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> Of Stefano Stabellini
> Sent: Tuesday, February 26, 2013 12:06 AM
> To: Hao, Xudong
> Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> afaerber@suse.de
> Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> base of PCI
> 
> On Mon, 25 Feb 2013, Xudong Hao wrote:
> > v2:
> > * Use "piix: " in the subject rather than "qemu: "
> > * Define TOM register as one byte
> > * Define default TOM value instead of hardcode 0xe0000000 in more that one
> place
> > * Use API pci_set_byte for pci config access
> > * Use dev->config instead of the indirect d->dev.config
> >
> > Define a TOM(top of memory) register to report the base of PCI memory,
> update
> > memory region dynamically. TOM register are defined to one byte in PCI
> configure
> > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > it requires bios set TOM with 16M-aligned.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> 
> The patch is OK from my POV, but I think that Ian raised a valid
> concern: we are supposed to emulate a real piece of hardware, maybe
> another mechanism (xenbus? hvmop?) to pass the information from
> hvmloader to QEMU would be a better fit than this.
> Otherwise at least we would need to advertize this feature somehow: if
> hvmloader can use it, the guest kernel can use it too...
> 
Hi, Ian and Stefano

Here adding this faking register in bios is a hack way. 
However, what we emulated is not full real piece of hardware at all times, the max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
The faking register is only effective by bios and device model. This register is reserved by host bridge, so guest can't access this register, guest kernel should handle well when accessing a reserved region. 

-Thanks
Xudong
> 
> 
> >  hw/pc.h       |  7 +++---
> >  hw/pc_piix.c  | 12 +++-------
> >  hw/piix_pci.c | 73
> +++++++++++++++++++++++++++++++++++++++++++----------------
> >  3 files changed, 59 insertions(+), 33 deletions(-)
> >
> > diff --git a/hw/pc.h b/hw/pc.h
> > index fbcf43d..62adcc5 100644
> > --- a/hw/pc.h
> > +++ b/hw/pc.h
> > @@ -129,15 +129,14 @@ extern int no_hpet;
> >  struct PCII440FXState;
> >  typedef struct PCII440FXState PCII440FXState;
> >
> > +#define I440FX_TOM     0xe0000000
> > +#define I440FX_XEN_TOM 0xf0000000
> > +
> >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> >                      ISABus **isa_bus, qemu_irq *pic,
> >                      MemoryRegion *address_space_mem,
> >                      MemoryRegion *address_space_io,
> >                      ram_addr_t ram_size,
> > -                    hwaddr pci_hole_start,
> > -                    hwaddr pci_hole_size,
> > -                    hwaddr pci_hole64_start,
> > -                    hwaddr pci_hole64_size,
> >                      MemoryRegion *pci_memory,
> >                      MemoryRegion *ram_memory);
> >
> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index 0a6923d..2eef510 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> >          kvmclock_create();
> >      }
> >
> > -    if (ram_size >= 0xe0000000 ) {
> > -        above_4g_mem_size = ram_size - 0xe0000000;
> > -        below_4g_mem_size = 0xe0000000;
> > +    if (ram_size >= I440FX_TOM) {
> > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > +        below_4g_mem_size = I440FX_TOM;
> >      } else {
> >          above_4g_mem_size = 0;
> >          below_4g_mem_size = ram_size;
> > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> *system_memory,
> >      if (pci_enabled) {
> >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> >                                system_memory, system_io,
> ram_size,
> > -                              below_4g_mem_size,
> > -                              0x100000000ULL -
> below_4g_mem_size,
> > -                              0x100000000ULL +
> above_4g_mem_size,
> > -                              (sizeof(hwaddr) == 4
> > -                               ? 0
> > -                               : ((uint64_t)1 << 62)),
> >                                pci_memory, ram_memory);
> >      } else {
> >          pci_bus = NULL;
> > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > index 3d79c73..3e5a25c 100644
> > --- a/hw/piix_pci.c
> > +++ b/hw/piix_pci.c
> > @@ -86,6 +86,14 @@ struct PCII440FXState {
> >  #define I440FX_PAM_SIZE 7
> >  #define I440FX_SMRAM    0x72
> >
> > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > + * is 1G, so it doesn't meet any popular virutal machines, so
> > + * define another register to report the base of PCI memory.
> > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > + * resevered for host bridge.
> > + * */
> > +#define I440FX_PCI_HOLE_BASE 0xb0
> > +
> >  static void piix3_set_irq(void *opaque, int pirq, int level);
> >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> pci_intx);
> >  static void piix3_write_config_xen(PCIDevice *dev,
> > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> pci_intx)
> >      return (pci_intx + slot_addend) & 3;
> >  }
> >
> > +
> > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > +{
> > +    ram_addr_t above_4g_mem_size;
> > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> pci_hole64_size;
> > +
> > +    pci_hole_start = pci_default_read_config(&f->dev,
> I440FX_PCI_HOLE_BASE, 1) << 24;
> > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > +
> > +    if (ram_size >= pci_hole_start) {
> > +        above_4g_mem_size = ram_size - pci_hole_start;
> > +    } else {
> > +        above_4g_mem_size = 0;
> > +    }
> > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > +
> > +    if (del) {
> > +        memory_region_del_subregion(f->system_memory,
> &f->pci_hole);
> > +        if (pci_hole64_size) {
> > +            memory_region_del_subregion(f->system_memory,
> &f->pci_hole_64bit);
> > +        }
> > +    }
> > +
> > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> f->pci_address_space,
> > +                             pci_hole_start, pci_hole_size);
> > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> &f->pci_hole);
> > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > +                             f->pci_address_space,
> > +                             pci_hole64_start, pci_hole64_size);
> > +    if (pci_hole64_size) {
> > +        memory_region_add_subregion(f->system_memory,
> pci_hole64_start,
> > +                                    &f->pci_hole_64bit);
> > +    }
> > +}
> > +
> > +
> >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> >  {
> >      int i;
> > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> >          range_covers_byte(address, len, I440FX_SMRAM)) {
> >          i440fx_update_memory_mappings(d);
> >      }
> > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > +        i440fx_update_pci_mem_hole(d, true);
> > +    }
> >  }
> >
> >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> >
> >      d->dev.config[I440FX_SMRAM] = 0x02;
> >
> > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> 24));
> > +
> >      cpu_smm_register(&i440fx_set_smm, d);
> >      return 0;
> >  }
> > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> *device_name,
> >                                    MemoryRegion
> *address_space_mem,
> >                                    MemoryRegion
> *address_space_io,
> >                                    ram_addr_t ram_size,
> > -                                  hwaddr pci_hole_start,
> > -                                  hwaddr pci_hole_size,
> > -                                  hwaddr pci_hole64_start,
> > -                                  hwaddr pci_hole64_size,
> >                                    MemoryRegion
> *pci_address_space,
> >                                    MemoryRegion *ram_memory)
> >  {
> > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> *device_name,
> >      f->system_memory = address_space_mem;
> >      f->pci_address_space = pci_address_space;
> >      f->ram_memory = ram_memory;
> > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> f->pci_address_space,
> > -                             pci_hole_start, pci_hole_size);
> > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> &f->pci_hole);
> > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > -                             f->pci_address_space,
> > -                             pci_hole64_start, pci_hole64_size);
> > -    if (pci_hole64_size) {
> > -        memory_region_add_subregion(f->system_memory,
> pci_hole64_start,
> > -                                    &f->pci_hole_64bit);
> > -    }
> >      memory_region_init_alias(&f->smram_region, "smram-region",
> >                               f->pci_address_space, 0xa0000,
> 0x20000);
> >      memory_region_add_subregion_overlap(f->system_memory,
> 0xa0000,
> > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> *device_name,
> >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> >
> >      i440fx_update_memory_mappings(f);
> > +    i440fx_update_pci_mem_hole(f, false);
> >
> >      return b;
> >  }
> > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> **pi440fx_state, int *piix3_devfn,
> >                      MemoryRegion *address_space_mem,
> >                      MemoryRegion *address_space_io,
> >                      ram_addr_t ram_size,
> > -                    hwaddr pci_hole_start,
> > -                    hwaddr pci_hole_size,
> > -                    hwaddr pci_hole64_start,
> > -                    hwaddr pci_hole64_size,
> >                      MemoryRegion *pci_memory, MemoryRegion
> *ram_memory)
> >
> >  {
> > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> int *piix3_devfn,
> >
> >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> pic,
> >                             address_space_mem, address_space_io,
> ram_size,
> > -                           pci_hole_start, pci_hole_size,
> > -                           pci_hole64_start, pci_hole64_size,
> >                             pci_memory, ram_memory);
> >      return b;
> >  }
> > --
> > 1.7.12.1
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 03:34:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 03: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 1UABIP-0007ja-Pk; Tue, 26 Feb 2013 03:33:37 +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 1UABIN-0007jV-U5
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 03:33:36 +0000
Received: from [85.158.137.99:51924] by server-16.bemta-3.messagelabs.com id
	19/29-02727-F0D2C215; Tue, 26 Feb 2013 03:33:35 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361849574!14778612!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMxOTc3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19967 invoked from network); 26 Feb 2013 03:32:55 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 03:32:55 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 25 Feb 2013 19:32:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,736,1355126400"; d="scan'208";a="295867772"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 25 Feb 2013 19:32:52 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 19:32:52 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.51]) by
	SHSMSX103.ccr.corp.intel.com ([10.239.4.69]) with mapi id
	14.01.0355.002; Tue, 26 Feb 2013 11:32:50 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Thread-Topic: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
Thread-Index: AQHOEyPJ9tWSzP5xh0+Cca//iHZcEZiKN5CAgAE+f0A=
Date: Tue, 26 Feb 2013 03:32:49 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1302251600180.5360@kaball.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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> Of Stefano Stabellini
> Sent: Tuesday, February 26, 2013 12:06 AM
> To: Hao, Xudong
> Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> afaerber@suse.de
> Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> base of PCI
> 
> On Mon, 25 Feb 2013, Xudong Hao wrote:
> > v2:
> > * Use "piix: " in the subject rather than "qemu: "
> > * Define TOM register as one byte
> > * Define default TOM value instead of hardcode 0xe0000000 in more that one
> place
> > * Use API pci_set_byte for pci config access
> > * Use dev->config instead of the indirect d->dev.config
> >
> > Define a TOM(top of memory) register to report the base of PCI memory,
> update
> > memory region dynamically. TOM register are defined to one byte in PCI
> configure
> > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > it requires bios set TOM with 16M-aligned.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> 
> The patch is OK from my POV, but I think that Ian raised a valid
> concern: we are supposed to emulate a real piece of hardware, maybe
> another mechanism (xenbus? hvmop?) to pass the information from
> hvmloader to QEMU would be a better fit than this.
> Otherwise at least we would need to advertize this feature somehow: if
> hvmloader can use it, the guest kernel can use it too...
> 
Hi, Ian and Stefano

Here adding this faking register in bios is a hack way. 
However, what we emulated is not full real piece of hardware at all times, the max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
The faking register is only effective by bios and device model. This register is reserved by host bridge, so guest can't access this register, guest kernel should handle well when accessing a reserved region. 

-Thanks
Xudong
> 
> 
> >  hw/pc.h       |  7 +++---
> >  hw/pc_piix.c  | 12 +++-------
> >  hw/piix_pci.c | 73
> +++++++++++++++++++++++++++++++++++++++++++----------------
> >  3 files changed, 59 insertions(+), 33 deletions(-)
> >
> > diff --git a/hw/pc.h b/hw/pc.h
> > index fbcf43d..62adcc5 100644
> > --- a/hw/pc.h
> > +++ b/hw/pc.h
> > @@ -129,15 +129,14 @@ extern int no_hpet;
> >  struct PCII440FXState;
> >  typedef struct PCII440FXState PCII440FXState;
> >
> > +#define I440FX_TOM     0xe0000000
> > +#define I440FX_XEN_TOM 0xf0000000
> > +
> >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> >                      ISABus **isa_bus, qemu_irq *pic,
> >                      MemoryRegion *address_space_mem,
> >                      MemoryRegion *address_space_io,
> >                      ram_addr_t ram_size,
> > -                    hwaddr pci_hole_start,
> > -                    hwaddr pci_hole_size,
> > -                    hwaddr pci_hole64_start,
> > -                    hwaddr pci_hole64_size,
> >                      MemoryRegion *pci_memory,
> >                      MemoryRegion *ram_memory);
> >
> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index 0a6923d..2eef510 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> >          kvmclock_create();
> >      }
> >
> > -    if (ram_size >= 0xe0000000 ) {
> > -        above_4g_mem_size = ram_size - 0xe0000000;
> > -        below_4g_mem_size = 0xe0000000;
> > +    if (ram_size >= I440FX_TOM) {
> > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > +        below_4g_mem_size = I440FX_TOM;
> >      } else {
> >          above_4g_mem_size = 0;
> >          below_4g_mem_size = ram_size;
> > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> *system_memory,
> >      if (pci_enabled) {
> >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> >                                system_memory, system_io,
> ram_size,
> > -                              below_4g_mem_size,
> > -                              0x100000000ULL -
> below_4g_mem_size,
> > -                              0x100000000ULL +
> above_4g_mem_size,
> > -                              (sizeof(hwaddr) == 4
> > -                               ? 0
> > -                               : ((uint64_t)1 << 62)),
> >                                pci_memory, ram_memory);
> >      } else {
> >          pci_bus = NULL;
> > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > index 3d79c73..3e5a25c 100644
> > --- a/hw/piix_pci.c
> > +++ b/hw/piix_pci.c
> > @@ -86,6 +86,14 @@ struct PCII440FXState {
> >  #define I440FX_PAM_SIZE 7
> >  #define I440FX_SMRAM    0x72
> >
> > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > + * is 1G, so it doesn't meet any popular virutal machines, so
> > + * define another register to report the base of PCI memory.
> > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > + * resevered for host bridge.
> > + * */
> > +#define I440FX_PCI_HOLE_BASE 0xb0
> > +
> >  static void piix3_set_irq(void *opaque, int pirq, int level);
> >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> pci_intx);
> >  static void piix3_write_config_xen(PCIDevice *dev,
> > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> pci_intx)
> >      return (pci_intx + slot_addend) & 3;
> >  }
> >
> > +
> > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > +{
> > +    ram_addr_t above_4g_mem_size;
> > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> pci_hole64_size;
> > +
> > +    pci_hole_start = pci_default_read_config(&f->dev,
> I440FX_PCI_HOLE_BASE, 1) << 24;
> > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > +
> > +    if (ram_size >= pci_hole_start) {
> > +        above_4g_mem_size = ram_size - pci_hole_start;
> > +    } else {
> > +        above_4g_mem_size = 0;
> > +    }
> > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > +
> > +    if (del) {
> > +        memory_region_del_subregion(f->system_memory,
> &f->pci_hole);
> > +        if (pci_hole64_size) {
> > +            memory_region_del_subregion(f->system_memory,
> &f->pci_hole_64bit);
> > +        }
> > +    }
> > +
> > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> f->pci_address_space,
> > +                             pci_hole_start, pci_hole_size);
> > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> &f->pci_hole);
> > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > +                             f->pci_address_space,
> > +                             pci_hole64_start, pci_hole64_size);
> > +    if (pci_hole64_size) {
> > +        memory_region_add_subregion(f->system_memory,
> pci_hole64_start,
> > +                                    &f->pci_hole_64bit);
> > +    }
> > +}
> > +
> > +
> >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> >  {
> >      int i;
> > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> >          range_covers_byte(address, len, I440FX_SMRAM)) {
> >          i440fx_update_memory_mappings(d);
> >      }
> > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > +        i440fx_update_pci_mem_hole(d, true);
> > +    }
> >  }
> >
> >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> >
> >      d->dev.config[I440FX_SMRAM] = 0x02;
> >
> > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> 24));
> > +
> >      cpu_smm_register(&i440fx_set_smm, d);
> >      return 0;
> >  }
> > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> *device_name,
> >                                    MemoryRegion
> *address_space_mem,
> >                                    MemoryRegion
> *address_space_io,
> >                                    ram_addr_t ram_size,
> > -                                  hwaddr pci_hole_start,
> > -                                  hwaddr pci_hole_size,
> > -                                  hwaddr pci_hole64_start,
> > -                                  hwaddr pci_hole64_size,
> >                                    MemoryRegion
> *pci_address_space,
> >                                    MemoryRegion *ram_memory)
> >  {
> > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> *device_name,
> >      f->system_memory = address_space_mem;
> >      f->pci_address_space = pci_address_space;
> >      f->ram_memory = ram_memory;
> > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> f->pci_address_space,
> > -                             pci_hole_start, pci_hole_size);
> > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> &f->pci_hole);
> > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > -                             f->pci_address_space,
> > -                             pci_hole64_start, pci_hole64_size);
> > -    if (pci_hole64_size) {
> > -        memory_region_add_subregion(f->system_memory,
> pci_hole64_start,
> > -                                    &f->pci_hole_64bit);
> > -    }
> >      memory_region_init_alias(&f->smram_region, "smram-region",
> >                               f->pci_address_space, 0xa0000,
> 0x20000);
> >      memory_region_add_subregion_overlap(f->system_memory,
> 0xa0000,
> > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> *device_name,
> >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> >
> >      i440fx_update_memory_mappings(f);
> > +    i440fx_update_pci_mem_hole(f, false);
> >
> >      return b;
> >  }
> > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> **pi440fx_state, int *piix3_devfn,
> >                      MemoryRegion *address_space_mem,
> >                      MemoryRegion *address_space_io,
> >                      ram_addr_t ram_size,
> > -                    hwaddr pci_hole_start,
> > -                    hwaddr pci_hole_size,
> > -                    hwaddr pci_hole64_start,
> > -                    hwaddr pci_hole64_size,
> >                      MemoryRegion *pci_memory, MemoryRegion
> *ram_memory)
> >
> >  {
> > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> int *piix3_devfn,
> >
> >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> pic,
> >                             address_space_mem, address_space_io,
> ram_size,
> > -                           pci_hole_start, pci_hole_size,
> > -                           pci_hole64_start, pci_hole64_size,
> >                             pci_memory, ram_memory);
> >      return b;
> >  }
> > --
> > 1.7.12.1
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 05:10:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 05:10: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 1UACoB-0002Ad-GF; Tue, 26 Feb 2013 05:10:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1UACoA-0002AY-2X
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 05:10:30 +0000
Received: from [85.158.137.99:31600] by server-16.bemta-3.messagelabs.com id
	73/59-02727-5C34C215; Tue, 26 Feb 2013 05:10:29 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361855426!17962899!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTYwNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25955 invoked from network); 26 Feb 2013 05:10:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 05:10:27 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 25 Feb 2013 21:10:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,737,1355126400"; d="scan'208";a="291800592"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga001.fm.intel.com with ESMTP; 25 Feb 2013 21:10:24 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 21:10:24 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Tue, 26 Feb 2013 13:10:22 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "Hao, Xudong" <xudong.hao@intel.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
Thread-Index: AQHOEyPJ9tWSzP5xh0+Cca//iHZcEZiKN5CAgAE+f0CAAB5SMA==
Date: Tue, 26 Feb 2013 05:10:21 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FF7C10B@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
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.  
Xiantao

> -----Original Message-----
> From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
> Of Hao, Xudong
> Sent: Tuesday, February 26, 2013 11:33 AM
> To: Stefano Stabellini; Ian Campbell
> Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
> devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> base of PCI
> 
> > -----Original Message-----
> > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> > Of Stefano Stabellini
> > Sent: Tuesday, February 26, 2013 12:06 AM
> > To: Hao, Xudong
> > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > afaerber@suse.de
> > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
> the
> > base of PCI
> >
> > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > v2:
> > > * Use "piix: " in the subject rather than "qemu: "
> > > * Define TOM register as one byte
> > > * Define default TOM value instead of hardcode 0xe0000000 in more that
> one
> > place
> > > * Use API pci_set_byte for pci config access
> > > * Use dev->config instead of the indirect d->dev.config
> > >
> > > Define a TOM(top of memory) register to report the base of PCI memory,
> > update
> > > memory region dynamically. TOM register are defined to one byte in PCI
> > configure
> > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > > it requires bios set TOM with 16M-aligned.
> > >
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> >
> > The patch is OK from my POV, but I think that Ian raised a valid
> > concern: we are supposed to emulate a real piece of hardware, maybe
> > another mechanism (xenbus? hvmop?) to pass the information from
> > hvmloader to QEMU would be a better fit than this.
> > Otherwise at least we would need to advertize this feature somehow: if
> > hvmloader can use it, the guest kernel can use it too...
> >
> Hi, Ian and Stefano
> 
> Here adding this faking register in bios is a hack way.
> However, what we emulated is not full real piece of hardware at all times, the
> max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> The faking register is only effective by bios and device model. This register is
> reserved by host bridge, so guest can't access this register, guest kernel should
> handle well when accessing a reserved region.
> 
> -Thanks
> Xudong
> >
> >
> > >  hw/pc.h       |  7 +++---
> > >  hw/pc_piix.c  | 12 +++-------
> > >  hw/piix_pci.c | 73
> > +++++++++++++++++++++++++++++++++++++++++++----------------
> > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/hw/pc.h b/hw/pc.h
> > > index fbcf43d..62adcc5 100644
> > > --- a/hw/pc.h
> > > +++ b/hw/pc.h
> > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > >  struct PCII440FXState;
> > >  typedef struct PCII440FXState PCII440FXState;
> > >
> > > +#define I440FX_TOM     0xe0000000
> > > +#define I440FX_XEN_TOM 0xf0000000
> > > +
> > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > >                      ISABus **isa_bus, qemu_irq *pic,
> > >                      MemoryRegion *address_space_mem,
> > >                      MemoryRegion *address_space_io,
> > >                      ram_addr_t ram_size,
> > > -                    hwaddr pci_hole_start,
> > > -                    hwaddr pci_hole_size,
> > > -                    hwaddr pci_hole64_start,
> > > -                    hwaddr pci_hole64_size,
> > >                      MemoryRegion *pci_memory,
> > >                      MemoryRegion *ram_memory);
> > >
> > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > index 0a6923d..2eef510 100644
> > > --- a/hw/pc_piix.c
> > > +++ b/hw/pc_piix.c
> > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> > >          kvmclock_create();
> > >      }
> > >
> > > -    if (ram_size >= 0xe0000000 ) {
> > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > -        below_4g_mem_size = 0xe0000000;
> > > +    if (ram_size >= I440FX_TOM) {
> > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > +        below_4g_mem_size = I440FX_TOM;
> > >      } else {
> > >          above_4g_mem_size = 0;
> > >          below_4g_mem_size = ram_size;
> > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > *system_memory,
> > >      if (pci_enabled) {
> > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > >                                system_memory, system_io,
> > ram_size,
> > > -                              below_4g_mem_size,
> > > -                              0x100000000ULL -
> > below_4g_mem_size,
> > > -                              0x100000000ULL +
> > above_4g_mem_size,
> > > -                              (sizeof(hwaddr) == 4
> > > -                               ? 0
> > > -                               : ((uint64_t)1 << 62)),
> > >                                pci_memory, ram_memory);
> > >      } else {
> > >          pci_bus = NULL;
> > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > index 3d79c73..3e5a25c 100644
> > > --- a/hw/piix_pci.c
> > > +++ b/hw/piix_pci.c
> > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > >  #define I440FX_PAM_SIZE 7
> > >  #define I440FX_SMRAM    0x72
> > >
> > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > + * define another register to report the base of PCI memory.
> > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > + * resevered for host bridge.
> > > + * */
> > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > +
> > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > pci_intx);
> > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> > pci_intx)
> > >      return (pci_intx + slot_addend) & 3;
> > >  }
> > >
> > > +
> > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > +{
> > > +    ram_addr_t above_4g_mem_size;
> > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > pci_hole64_size;
> > > +
> > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > +
> > > +    if (ram_size >= pci_hole_start) {
> > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > +    } else {
> > > +        above_4g_mem_size = 0;
> > > +    }
> > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > +
> > > +    if (del) {
> > > +        memory_region_del_subregion(f->system_memory,
> > &f->pci_hole);
> > > +        if (pci_hole64_size) {
> > > +            memory_region_del_subregion(f->system_memory,
> > &f->pci_hole_64bit);
> > > +        }
> > > +    }
> > > +
> > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > f->pci_address_space,
> > > +                             pci_hole_start, pci_hole_size);
> > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > &f->pci_hole);
> > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > +                             f->pci_address_space,
> > > +                             pci_hole64_start, pci_hole64_size);
> > > +    if (pci_hole64_size) {
> > > +        memory_region_add_subregion(f->system_memory,
> > pci_hole64_start,
> > > +                                    &f->pci_hole_64bit);
> > > +    }
> > > +}
> > > +
> > > +
> > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > >  {
> > >      int i;
> > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > >          i440fx_update_memory_mappings(d);
> > >      }
> > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > +        i440fx_update_pci_mem_hole(d, true);
> > > +    }
> > >  }
> > >
> > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > >
> > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > >
> > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> > 24));
> > > +
> > >      cpu_smm_register(&i440fx_set_smm, d);
> > >      return 0;
> > >  }
> > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> > *device_name,
> > >                                    MemoryRegion
> > *address_space_mem,
> > >                                    MemoryRegion
> > *address_space_io,
> > >                                    ram_addr_t ram_size,
> > > -                                  hwaddr pci_hole_start,
> > > -                                  hwaddr pci_hole_size,
> > > -                                  hwaddr pci_hole64_start,
> > > -                                  hwaddr pci_hole64_size,
> > >                                    MemoryRegion
> > *pci_address_space,
> > >                                    MemoryRegion *ram_memory)
> > >  {
> > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> > *device_name,
> > >      f->system_memory = address_space_mem;
> > >      f->pci_address_space = pci_address_space;
> > >      f->ram_memory = ram_memory;
> > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > f->pci_address_space,
> > > -                             pci_hole_start, pci_hole_size);
> > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > &f->pci_hole);
> > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > -                             f->pci_address_space,
> > > -                             pci_hole64_start, pci_hole64_size);
> > > -    if (pci_hole64_size) {
> > > -        memory_region_add_subregion(f->system_memory,
> > pci_hole64_start,
> > > -                                    &f->pci_hole_64bit);
> > > -    }
> > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > >                               f->pci_address_space, 0xa0000,
> > 0x20000);
> > >      memory_region_add_subregion_overlap(f->system_memory,
> > 0xa0000,
> > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > *device_name,
> > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > >
> > >      i440fx_update_memory_mappings(f);
> > > +    i440fx_update_pci_mem_hole(f, false);
> > >
> > >      return b;
> > >  }
> > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > **pi440fx_state, int *piix3_devfn,
> > >                      MemoryRegion *address_space_mem,
> > >                      MemoryRegion *address_space_io,
> > >                      ram_addr_t ram_size,
> > > -                    hwaddr pci_hole_start,
> > > -                    hwaddr pci_hole_size,
> > > -                    hwaddr pci_hole64_start,
> > > -                    hwaddr pci_hole64_size,
> > >                      MemoryRegion *pci_memory, MemoryRegion
> > *ram_memory)
> > >
> > >  {
> > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> > int *piix3_devfn,
> > >
> > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> > pic,
> > >                             address_space_mem, address_space_io,
> > ram_size,
> > > -                           pci_hole_start, pci_hole_size,
> > > -                           pci_hole64_start, pci_hole64_size,
> > >                             pci_memory, ram_memory);
> > >      return b;
> > >  }
> > > --
> > > 1.7.12.1
> > >
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 05:10:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 05:10: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 1UACoB-0002Ad-GF; Tue, 26 Feb 2013 05:10:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1UACoA-0002AY-2X
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 05:10:30 +0000
Received: from [85.158.137.99:31600] by server-16.bemta-3.messagelabs.com id
	73/59-02727-5C34C215; Tue, 26 Feb 2013 05:10:29 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361855426!17962899!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTYwNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25955 invoked from network); 26 Feb 2013 05:10:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 05:10:27 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 25 Feb 2013 21:10:25 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,737,1355126400"; d="scan'208";a="291800592"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga001.fm.intel.com with ESMTP; 25 Feb 2013 21:10:24 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 21:10:24 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Tue, 26 Feb 2013 13:10:22 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: "Hao, Xudong" <xudong.hao@intel.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
Thread-Index: AQHOEyPJ9tWSzP5xh0+Cca//iHZcEZiKN5CAgAE+f0CAAB5SMA==
Date: Tue, 26 Feb 2013 05:10:21 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FF7C10B@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
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.  
Xiantao

> -----Original Message-----
> From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
> Of Hao, Xudong
> Sent: Tuesday, February 26, 2013 11:33 AM
> To: Stefano Stabellini; Ian Campbell
> Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
> devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> base of PCI
> 
> > -----Original Message-----
> > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> > Of Stefano Stabellini
> > Sent: Tuesday, February 26, 2013 12:06 AM
> > To: Hao, Xudong
> > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > afaerber@suse.de
> > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
> the
> > base of PCI
> >
> > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > v2:
> > > * Use "piix: " in the subject rather than "qemu: "
> > > * Define TOM register as one byte
> > > * Define default TOM value instead of hardcode 0xe0000000 in more that
> one
> > place
> > > * Use API pci_set_byte for pci config access
> > > * Use dev->config instead of the indirect d->dev.config
> > >
> > > Define a TOM(top of memory) register to report the base of PCI memory,
> > update
> > > memory region dynamically. TOM register are defined to one byte in PCI
> > configure
> > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > > it requires bios set TOM with 16M-aligned.
> > >
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> >
> > The patch is OK from my POV, but I think that Ian raised a valid
> > concern: we are supposed to emulate a real piece of hardware, maybe
> > another mechanism (xenbus? hvmop?) to pass the information from
> > hvmloader to QEMU would be a better fit than this.
> > Otherwise at least we would need to advertize this feature somehow: if
> > hvmloader can use it, the guest kernel can use it too...
> >
> Hi, Ian and Stefano
> 
> Here adding this faking register in bios is a hack way.
> However, what we emulated is not full real piece of hardware at all times, the
> max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> The faking register is only effective by bios and device model. This register is
> reserved by host bridge, so guest can't access this register, guest kernel should
> handle well when accessing a reserved region.
> 
> -Thanks
> Xudong
> >
> >
> > >  hw/pc.h       |  7 +++---
> > >  hw/pc_piix.c  | 12 +++-------
> > >  hw/piix_pci.c | 73
> > +++++++++++++++++++++++++++++++++++++++++++----------------
> > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/hw/pc.h b/hw/pc.h
> > > index fbcf43d..62adcc5 100644
> > > --- a/hw/pc.h
> > > +++ b/hw/pc.h
> > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > >  struct PCII440FXState;
> > >  typedef struct PCII440FXState PCII440FXState;
> > >
> > > +#define I440FX_TOM     0xe0000000
> > > +#define I440FX_XEN_TOM 0xf0000000
> > > +
> > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > >                      ISABus **isa_bus, qemu_irq *pic,
> > >                      MemoryRegion *address_space_mem,
> > >                      MemoryRegion *address_space_io,
> > >                      ram_addr_t ram_size,
> > > -                    hwaddr pci_hole_start,
> > > -                    hwaddr pci_hole_size,
> > > -                    hwaddr pci_hole64_start,
> > > -                    hwaddr pci_hole64_size,
> > >                      MemoryRegion *pci_memory,
> > >                      MemoryRegion *ram_memory);
> > >
> > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > index 0a6923d..2eef510 100644
> > > --- a/hw/pc_piix.c
> > > +++ b/hw/pc_piix.c
> > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> > >          kvmclock_create();
> > >      }
> > >
> > > -    if (ram_size >= 0xe0000000 ) {
> > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > -        below_4g_mem_size = 0xe0000000;
> > > +    if (ram_size >= I440FX_TOM) {
> > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > +        below_4g_mem_size = I440FX_TOM;
> > >      } else {
> > >          above_4g_mem_size = 0;
> > >          below_4g_mem_size = ram_size;
> > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > *system_memory,
> > >      if (pci_enabled) {
> > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > >                                system_memory, system_io,
> > ram_size,
> > > -                              below_4g_mem_size,
> > > -                              0x100000000ULL -
> > below_4g_mem_size,
> > > -                              0x100000000ULL +
> > above_4g_mem_size,
> > > -                              (sizeof(hwaddr) == 4
> > > -                               ? 0
> > > -                               : ((uint64_t)1 << 62)),
> > >                                pci_memory, ram_memory);
> > >      } else {
> > >          pci_bus = NULL;
> > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > index 3d79c73..3e5a25c 100644
> > > --- a/hw/piix_pci.c
> > > +++ b/hw/piix_pci.c
> > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > >  #define I440FX_PAM_SIZE 7
> > >  #define I440FX_SMRAM    0x72
> > >
> > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > + * define another register to report the base of PCI memory.
> > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > + * resevered for host bridge.
> > > + * */
> > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > +
> > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > pci_intx);
> > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> > pci_intx)
> > >      return (pci_intx + slot_addend) & 3;
> > >  }
> > >
> > > +
> > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > +{
> > > +    ram_addr_t above_4g_mem_size;
> > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > pci_hole64_size;
> > > +
> > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > +
> > > +    if (ram_size >= pci_hole_start) {
> > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > +    } else {
> > > +        above_4g_mem_size = 0;
> > > +    }
> > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > +
> > > +    if (del) {
> > > +        memory_region_del_subregion(f->system_memory,
> > &f->pci_hole);
> > > +        if (pci_hole64_size) {
> > > +            memory_region_del_subregion(f->system_memory,
> > &f->pci_hole_64bit);
> > > +        }
> > > +    }
> > > +
> > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > f->pci_address_space,
> > > +                             pci_hole_start, pci_hole_size);
> > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > &f->pci_hole);
> > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > +                             f->pci_address_space,
> > > +                             pci_hole64_start, pci_hole64_size);
> > > +    if (pci_hole64_size) {
> > > +        memory_region_add_subregion(f->system_memory,
> > pci_hole64_start,
> > > +                                    &f->pci_hole_64bit);
> > > +    }
> > > +}
> > > +
> > > +
> > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > >  {
> > >      int i;
> > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > >          i440fx_update_memory_mappings(d);
> > >      }
> > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > +        i440fx_update_pci_mem_hole(d, true);
> > > +    }
> > >  }
> > >
> > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > >
> > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > >
> > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> > 24));
> > > +
> > >      cpu_smm_register(&i440fx_set_smm, d);
> > >      return 0;
> > >  }
> > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> > *device_name,
> > >                                    MemoryRegion
> > *address_space_mem,
> > >                                    MemoryRegion
> > *address_space_io,
> > >                                    ram_addr_t ram_size,
> > > -                                  hwaddr pci_hole_start,
> > > -                                  hwaddr pci_hole_size,
> > > -                                  hwaddr pci_hole64_start,
> > > -                                  hwaddr pci_hole64_size,
> > >                                    MemoryRegion
> > *pci_address_space,
> > >                                    MemoryRegion *ram_memory)
> > >  {
> > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> > *device_name,
> > >      f->system_memory = address_space_mem;
> > >      f->pci_address_space = pci_address_space;
> > >      f->ram_memory = ram_memory;
> > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > f->pci_address_space,
> > > -                             pci_hole_start, pci_hole_size);
> > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > &f->pci_hole);
> > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > -                             f->pci_address_space,
> > > -                             pci_hole64_start, pci_hole64_size);
> > > -    if (pci_hole64_size) {
> > > -        memory_region_add_subregion(f->system_memory,
> > pci_hole64_start,
> > > -                                    &f->pci_hole_64bit);
> > > -    }
> > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > >                               f->pci_address_space, 0xa0000,
> > 0x20000);
> > >      memory_region_add_subregion_overlap(f->system_memory,
> > 0xa0000,
> > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > *device_name,
> > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > >
> > >      i440fx_update_memory_mappings(f);
> > > +    i440fx_update_pci_mem_hole(f, false);
> > >
> > >      return b;
> > >  }
> > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > **pi440fx_state, int *piix3_devfn,
> > >                      MemoryRegion *address_space_mem,
> > >                      MemoryRegion *address_space_io,
> > >                      ram_addr_t ram_size,
> > > -                    hwaddr pci_hole_start,
> > > -                    hwaddr pci_hole_size,
> > > -                    hwaddr pci_hole64_start,
> > > -                    hwaddr pci_hole64_size,
> > >                      MemoryRegion *pci_memory, MemoryRegion
> > *ram_memory)
> > >
> > >  {
> > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> > int *piix3_devfn,
> > >
> > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> > pic,
> > >                             address_space_mem, address_space_io,
> > ram_size,
> > > -                           pci_hole_start, pci_hole_size,
> > > -                           pci_hole64_start, pci_hole64_size,
> > >                             pci_memory, ram_memory);
> > >      return b;
> > >  }
> > > --
> > > 1.7.12.1
> > >
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 05:36:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 05: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 1UADCM-000324-SJ; Tue, 26 Feb 2013 05:35:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1UADCL-00031z-BK
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 05:35:29 +0000
Received: from [85.158.137.99:57379] by server-1.bemta-3.messagelabs.com id
	F8/19-08955-0A94C215; Tue, 26 Feb 2013 05:35:28 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361856926!12941082!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTYwNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16890 invoked from network); 26 Feb 2013 05:35:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 05:35:27 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 25 Feb 2013 21:35:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,737,1355126400"; d="scan'208";a="295902614"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 25 Feb 2013 21:35:23 -0800
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 21:35:23 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 21:35:23 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Tue, 26 Feb 2013 13:35:21 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH] x86: fix CMCI injection
Thread-Index: AQHOE3glGkmB0VVxDUWw+N7PFYD8hpiLnOdw
Date: Tue, 26 Feb 2013 05:35:20 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A102960C9@SHSMSX101.ccr.corp.intel.com>
References: <512BA42602000078000C0D64@nat28.tlf.novell.com>
In-Reply-To: <512BA42602000078000C0D64@nat28.tlf.novell.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
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: fix CMCI injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tested-by: Yongjie Ren <yongjie.ren@intel.com>

Best Regards,
     Yongjie (Jay)


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, February 26, 2013 12:49 AM
> To: xen-devel
> Cc: Liu, Jinsong; Ren, Yongjie
> Subject: [PATCH] x86: fix CMCI injection
> 
> This fixes the wrong use of literal vector 0xF7 with an "int"
> instruction (invalidated by 25113:14609be41f36) and the fact that doing
> the injection via a software interrupt was never valid anyway (because
> cmci_interrupt() acks the LAPIC, which does the wrong thing if the
> interrupt didn't get delivered though it).
> 
> In order to do latter, the patch introduces send_IPI_self(), at once
> removing two opend coded uses of "genapic" in the IRQ handling code.
> 
> Reported-by: Yongjie Ren <yongjie.ren@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -34,6 +34,7 @@ bool_t __read_mostly mce_broadcast = 0;
>  bool_t is_mc_panic;
>  unsigned int __read_mostly nr_mce_banks;
>  unsigned int __read_mostly firstbank;
> +uint8_t __read_mostly cmci_apic_vector;
> 
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> @@ -1198,12 +1199,6 @@ static void x86_mc_mceinject(void *data)
>      __asm__ __volatile__("int $0x12");
>  }
> 
> -static void x86_cmci_inject(void *data)
> -{
> -    printk("Simulating CMCI on cpu %d\n", smp_processor_id());
> -    __asm__ __volatile__("int $0xf7");
> -}
> -
>  #if BITS_PER_LONG == 64
> 
>  #define ID2COOKIE(id) ((mctelem_cookie_t)(id))
> @@ -1479,11 +1474,15 @@ long
> do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
>              on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
>              break;
>          case XEN_MC_INJECT_TYPE_CMCI:
> -            if ( !cmci_support )
> +            if ( !cmci_apic_vector )
>                  ret = x86_mcerr(
>                      "No CMCI supported in platform\n", -EINVAL);
>              else
> -                on_selected_cpus(cpumap, x86_cmci_inject, NULL, 1);
> +            {
> +                if ( cpumask_test_cpu(smp_processor_id(), cpumap) )
> +                    send_IPI_self(cmci_apic_vector);
> +                send_IPI_mask(cpumap, cmci_apic_vector);
> +            }
>              break;
>          default:
>              ret = x86_mcerr("Wrong mca type\n", -EINVAL);
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -37,6 +37,8 @@ enum mcheck_type {
>  	mcheck_intel
>  };
> 
> +extern uint8_t cmci_apic_vector;
> +
>  /* Init functions */
>  enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
>  enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -644,7 +644,6 @@ static void intel_init_cmci(struct cpuin
>  {
>      u32 l, apic;
>      int cpu = smp_processor_id();
> -    static uint8_t cmci_apic_vector;
> 
>      if (!mce_available(c) || !cmci_support) {
>          if (opt_cpu_info)
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -646,7 +646,7 @@ void irq_move_cleanup_interrupt(struct c
>           * to myself.
>           */
>          if (irr  & (1 << (vector % 32))) {
> -            genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
> +            send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
>              TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
>                       irq, vector, smp_processor_id());
>              goto unlock;
> @@ -692,7 +692,7 @@ static void send_cleanup_vector(struct i
> 
>      cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask,
> &cpu_online_map);
>      desc->arch.move_cleanup_count =
> cpumask_weight(&cleanup_mask);
> -    genapic->send_IPI_mask(&cleanup_mask,
> IRQ_MOVE_CLEANUP_VECTOR);
> +    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
> 
>      desc->arch.move_in_progress = 0;
>  }
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -38,6 +38,11 @@ void send_IPI_mask(const cpumask_t *mask
>      genapic->send_IPI_mask(mask, vector);
>  }
> 
> +void send_IPI_self(int vector)
> +{
> +    genapic->send_IPI_self(vector);
> +}
> +
>  /*
>   *	Some notes on x86 processor bugs affecting SMP operation:
>   *
> --- a/xen/include/asm-x86/smp.h
> +++ b/xen/include/asm-x86/smp.h
> @@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
> 
>  void smp_send_nmi_allbutself(void);
> 
> -void  send_IPI_mask(const cpumask_t *mask, int vector);
> +void send_IPI_mask(const cpumask_t *, int vector);
> +void send_IPI_self(int vector);
> 
>  extern void (*mtrr_hook) (void);
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 05:36:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 05: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 1UADCM-000324-SJ; Tue, 26 Feb 2013 05:35:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1UADCL-00031z-BK
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 05:35:29 +0000
Received: from [85.158.137.99:57379] by server-1.bemta-3.messagelabs.com id
	F8/19-08955-0A94C215; Tue, 26 Feb 2013 05:35:28 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361856926!12941082!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MTYwNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16890 invoked from network); 26 Feb 2013 05:35:27 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 05:35:27 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 25 Feb 2013 21:35:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,737,1355126400"; d="scan'208";a="295902614"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 25 Feb 2013 21:35:23 -0800
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 21:35:23 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 25 Feb 2013 21:35:23 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Tue, 26 Feb 2013 13:35:21 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH] x86: fix CMCI injection
Thread-Index: AQHOE3glGkmB0VVxDUWw+N7PFYD8hpiLnOdw
Date: Tue, 26 Feb 2013 05:35:20 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A102960C9@SHSMSX101.ccr.corp.intel.com>
References: <512BA42602000078000C0D64@nat28.tlf.novell.com>
In-Reply-To: <512BA42602000078000C0D64@nat28.tlf.novell.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
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: fix CMCI injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tested-by: Yongjie Ren <yongjie.ren@intel.com>

Best Regards,
     Yongjie (Jay)


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, February 26, 2013 12:49 AM
> To: xen-devel
> Cc: Liu, Jinsong; Ren, Yongjie
> Subject: [PATCH] x86: fix CMCI injection
> 
> This fixes the wrong use of literal vector 0xF7 with an "int"
> instruction (invalidated by 25113:14609be41f36) and the fact that doing
> the injection via a software interrupt was never valid anyway (because
> cmci_interrupt() acks the LAPIC, which does the wrong thing if the
> interrupt didn't get delivered though it).
> 
> In order to do latter, the patch introduces send_IPI_self(), at once
> removing two opend coded uses of "genapic" in the IRQ handling code.
> 
> Reported-by: Yongjie Ren <yongjie.ren@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -34,6 +34,7 @@ bool_t __read_mostly mce_broadcast = 0;
>  bool_t is_mc_panic;
>  unsigned int __read_mostly nr_mce_banks;
>  unsigned int __read_mostly firstbank;
> +uint8_t __read_mostly cmci_apic_vector;
> 
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> @@ -1198,12 +1199,6 @@ static void x86_mc_mceinject(void *data)
>      __asm__ __volatile__("int $0x12");
>  }
> 
> -static void x86_cmci_inject(void *data)
> -{
> -    printk("Simulating CMCI on cpu %d\n", smp_processor_id());
> -    __asm__ __volatile__("int $0xf7");
> -}
> -
>  #if BITS_PER_LONG == 64
> 
>  #define ID2COOKIE(id) ((mctelem_cookie_t)(id))
> @@ -1479,11 +1474,15 @@ long
> do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
>              on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
>              break;
>          case XEN_MC_INJECT_TYPE_CMCI:
> -            if ( !cmci_support )
> +            if ( !cmci_apic_vector )
>                  ret = x86_mcerr(
>                      "No CMCI supported in platform\n", -EINVAL);
>              else
> -                on_selected_cpus(cpumap, x86_cmci_inject, NULL, 1);
> +            {
> +                if ( cpumask_test_cpu(smp_processor_id(), cpumap) )
> +                    send_IPI_self(cmci_apic_vector);
> +                send_IPI_mask(cpumap, cmci_apic_vector);
> +            }
>              break;
>          default:
>              ret = x86_mcerr("Wrong mca type\n", -EINVAL);
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -37,6 +37,8 @@ enum mcheck_type {
>  	mcheck_intel
>  };
> 
> +extern uint8_t cmci_apic_vector;
> +
>  /* Init functions */
>  enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
>  enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -644,7 +644,6 @@ static void intel_init_cmci(struct cpuin
>  {
>      u32 l, apic;
>      int cpu = smp_processor_id();
> -    static uint8_t cmci_apic_vector;
> 
>      if (!mce_available(c) || !cmci_support) {
>          if (opt_cpu_info)
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -646,7 +646,7 @@ void irq_move_cleanup_interrupt(struct c
>           * to myself.
>           */
>          if (irr  & (1 << (vector % 32))) {
> -            genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
> +            send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
>              TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
>                       irq, vector, smp_processor_id());
>              goto unlock;
> @@ -692,7 +692,7 @@ static void send_cleanup_vector(struct i
> 
>      cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask,
> &cpu_online_map);
>      desc->arch.move_cleanup_count =
> cpumask_weight(&cleanup_mask);
> -    genapic->send_IPI_mask(&cleanup_mask,
> IRQ_MOVE_CLEANUP_VECTOR);
> +    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
> 
>      desc->arch.move_in_progress = 0;
>  }
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -38,6 +38,11 @@ void send_IPI_mask(const cpumask_t *mask
>      genapic->send_IPI_mask(mask, vector);
>  }
> 
> +void send_IPI_self(int vector)
> +{
> +    genapic->send_IPI_self(vector);
> +}
> +
>  /*
>   *	Some notes on x86 processor bugs affecting SMP operation:
>   *
> --- a/xen/include/asm-x86/smp.h
> +++ b/xen/include/asm-x86/smp.h
> @@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
> 
>  void smp_send_nmi_allbutself(void);
> 
> -void  send_IPI_mask(const cpumask_t *mask, int vector);
> +void send_IPI_mask(const cpumask_t *, int vector);
> +void send_IPI_self(int vector);
> 
>  extern void (*mtrr_hook) (void);
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 05:53:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 05:53: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 1UADSw-0003d9-I3; Tue, 26 Feb 2013 05:52:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1UADSv-0003d4-Fz
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 05:52:37 +0000
Received: from [85.158.143.99:53987] by server-1.bemta-4.messagelabs.com id
	B9/38-06203-4AD4C215; Tue, 26 Feb 2013 05:52:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361857955!22367785!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15041 invoked from network); 26 Feb 2013 05:52:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 05:52:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,737,1355097600"; 
   d="scan'208";a="1876132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 05:52: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.297.1; Tue, 26 Feb 2013 05:52:35 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UADSt-00055U-6S;
	Tue, 26 Feb 2013 05:52:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UADSt-0003DP-5V;
	Tue, 26 Feb 2013 05:52:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1UADSt-0003DP-5V@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 05:52:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-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

branch xen-unstable
xen branch xen-unstable
job build-i386
test xen-build

Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Bug not present: fe47f73c59f566cc428038831c7d48b8f08bbc75


  commit 08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Author: Ian Campbell <ian.campbell@citrix.com>
  Date:   Fri Feb 22 08:57:59 2013 +0000
  
      xen: arm64: add to foreign struct checks
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 16657 fail [host=woodlouse] / 16720 ok.
Failure / basis pass flights: 16657 / 16720
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
Basis pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/staging/qemu-xen-unstable.git#3b7917bce51cdf433924d295edcfe84f407bd1f7-bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 git://xenbits.xen.org/xen.git#fe47f73c59f566cc428038831c7d48b8f08bbc75-4291b626cee8aff5d976c5829a79fceca9cff420
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/xen.git /export/home/osstest/repos/xen...
Initialized empty Git repository in /export/home/osstest/repos/xen/
updating cache /export/home/osstest/repos/git-cache xen...
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/xen.git /export/home/osstest/repos/xen...
Initialized empty Git repository in /export/home/osstest/repos/xen/
updating cache /export/home/osstest/repos/git-cache xen...
Loaded 3004 nodes in revision graph
Searching for test results:
 16226 [host=bush-cricket]
 16231 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16327 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16235 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16521 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16657 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16707 pass irrelevant
 16710 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16687 pass irrelevant
 16711 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16688 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16712 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16692 pass irrelevant
 16713 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16693 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16694 pass irrelevant
 16695 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16714 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16696 pass irrelevant
 16698 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16716 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
 16699 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 c95d4af5bb69a76d730c8be5369ba4822b9d2ec9
 16700 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 66e994a5e74f2a3782c0cc60d53412cefbff8e0d
 16717 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16702 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
 16705 pass irrelevant
 16719 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
 16706 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16720 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16721 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
Searching for interesting versions
 Result found: flight 16711 (pass), for basis pass
 Result found: flight 16712 (fail), for basis failure
 Repro found: flight 16713 (pass), for basis pass
 Repro found: flight 16714 (fail), for basis failure
 0 revisions at 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
No revisions left to test, checking graph state.
 Result found: flight 16711 (pass), for last pass
 Result found: flight 16716 (fail), for first failure
 Repro found: flight 16717 (pass), for last pass
 Repro found: flight 16719 (fail), for first failure
 Repro found: flight 16720 (pass), for last pass
 Repro found: flight 16721 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Bug not present: fe47f73c59f566cc428038831c7d48b8f08bbc75

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/xen.git /export/home/osstest/repos/xen...
Initialized empty Git repository in /export/home/osstest/repos/xen/
updating cache /export/home/osstest/repos/git-cache xen...

  commit 08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Author: Ian Campbell <ian.campbell@citrix.com>
  Date:   Fri Feb 22 08:57:59 2013 +0000
  
      xen: arm64: add to foreign struct checks
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
----------------------------------------
16721: tolerable ALL FAIL

flight 16721 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16721/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386                    4 xen-build               fail baseline untested


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 05:53:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 05:53: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 1UADSw-0003d9-I3; Tue, 26 Feb 2013 05:52:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1UADSv-0003d4-Fz
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 05:52:37 +0000
Received: from [85.158.143.99:53987] by server-1.bemta-4.messagelabs.com id
	B9/38-06203-4AD4C215; Tue, 26 Feb 2013 05:52:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361857955!22367785!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15041 invoked from network); 26 Feb 2013 05:52:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 05:52:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,737,1355097600"; 
   d="scan'208";a="1876132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 05:52: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.297.1; Tue, 26 Feb 2013 05:52:35 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UADSt-00055U-6S;
	Tue, 26 Feb 2013 05:52:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UADSt-0003DP-5V;
	Tue, 26 Feb 2013 05:52:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1UADSt-0003DP-5V@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 05:52:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-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

branch xen-unstable
xen branch xen-unstable
job build-i386
test xen-build

Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Bug not present: fe47f73c59f566cc428038831c7d48b8f08bbc75


  commit 08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Author: Ian Campbell <ian.campbell@citrix.com>
  Date:   Fri Feb 22 08:57:59 2013 +0000
  
      xen: arm64: add to foreign struct checks
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 16657 fail [host=woodlouse] / 16720 ok.
Failure / basis pass flights: 16657 / 16720
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
Basis pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/staging/qemu-xen-unstable.git#3b7917bce51cdf433924d295edcfe84f407bd1f7-bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de git://xenbits.xen.org/staging/qemu-upstream-unstable.git#e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01-e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 git://xenbits.xen.org/xen.git#fe47f73c59f566cc428038831c7d48b8f08bbc75-4291b626cee8aff5d976c5829a79fceca9cff420
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/xen.git /export/home/osstest/repos/xen...
Initialized empty Git repository in /export/home/osstest/repos/xen/
updating cache /export/home/osstest/repos/git-cache xen...
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/xen.git /export/home/osstest/repos/xen...
Initialized empty Git repository in /export/home/osstest/repos/xen/
updating cache /export/home/osstest/repos/git-cache xen...
Loaded 3004 nodes in revision graph
Searching for test results:
 16226 [host=bush-cricket]
 16231 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16327 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16235 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16521 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16657 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16707 pass irrelevant
 16710 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16687 pass irrelevant
 16711 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16688 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16712 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16692 pass irrelevant
 16713 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16693 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16694 pass irrelevant
 16695 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16714 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16696 pass irrelevant
 16698 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16716 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
 16699 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 c95d4af5bb69a76d730c8be5369ba4822b9d2ec9
 16700 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 66e994a5e74f2a3782c0cc60d53412cefbff8e0d
 16717 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16702 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
 16705 pass irrelevant
 16719 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
 16706 fail bd9e97271db5edc07e3e0d45bdf6ccd5a9bba3de e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 4291b626cee8aff5d976c5829a79fceca9cff420
 16720 pass 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
 16721 fail 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 08551b90080e0e9a60a6e7f2a7855aa970f0643f
Searching for interesting versions
 Result found: flight 16711 (pass), for basis pass
 Result found: flight 16712 (fail), for basis failure
 Repro found: flight 16713 (pass), for basis pass
 Repro found: flight 16714 (fail), for basis failure
 0 revisions at 3b7917bce51cdf433924d295edcfe84f407bd1f7 e6e112f5f1b8a9dde8dd037d6a48f621d8a6ca01 fe47f73c59f566cc428038831c7d48b8f08bbc75
No revisions left to test, checking graph state.
 Result found: flight 16711 (pass), for last pass
 Result found: flight 16716 (fail), for first failure
 Repro found: flight 16717 (pass), for last pass
 Repro found: flight 16719 (fail), for first failure
 Repro found: flight 16720 (pass), for last pass
 Repro found: flight 16721 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Bug not present: fe47f73c59f566cc428038831c7d48b8f08bbc75

using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/xen.git /export/home/osstest/repos/xen...
Initialized empty Git repository in /export/home/osstest/repos/xen/
updating cache /export/home/osstest/repos/git-cache xen...

  commit 08551b90080e0e9a60a6e7f2a7855aa970f0643f
  Author: Ian Campbell <ian.campbell@citrix.com>
  Date:   Fri Feb 22 08:57:59 2013 +0000
  
      xen: arm64: add to foreign struct checks
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
----------------------------------------
16721: tolerable ALL FAIL

flight 16721 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16721/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386                    4 xen-build               fail baseline untested


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 06:05:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 06: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 1UADeY-00043y-Qj; Tue, 26 Feb 2013 06:04:38 +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 1UADeX-00043t-EY
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 06:04:37 +0000
Received: from [85.158.139.83:40872] by server-9.bemta-5.messagelabs.com id
	61/1B-08547-4705C215; Tue, 26 Feb 2013 06:04:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361858675!21596939!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14044 invoked from network); 26 Feb 2013 06:04:35 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 06:04:35 -0000
Received: by mail-wg0-f47.google.com with SMTP id dr13so3016291wgb.26
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 22:04:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=W4lESLH7Te8XUBsGTLu+FosYfT1TopOjaEARpIkinTQ=;
	b=BoS28BIXRMj7o7RXjG0mdxQQR5sawWd5aHort6sEWNcMBTT02hzqloUWarxcPY1JdR
	4j34K5laGDC2y3o9rmU4hJlKuutzr9AVuklvi43aQ/4JlWYt9X7DDwMoM84l3ZHgCLcK
	YRGrjLgk0kxyvmQeQsAsiX3tqGYNQxj8Rd1Tc1NEmJgERcWzNAXH1IFN5b6svXvyK0hs
	9gBPF7Y6YLTNMUn7hl+yH4JnDQjHVE8a3JsiTWvitQm3oCrgYcPPIUgQ9E6DoHK5Wpy5
	n1QwhB9iFNE0LEnQB0sjCV09+iWHgrkBRtIxqrEyWJU+ezpJdHoJRPc6tQUdfDyhRU9d
	Mwkg==
X-Received: by 10.180.87.170 with SMTP id az10mr17115019wib.3.1361858675392;
	Mon, 25 Feb 2013 22:04:35 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id o8sm18950031wix.7.2013.02.25.22.04.33
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 22:04:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 26 Feb 2013 06:04:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD5200F0.4C9DF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: fix CMCI injection
Thread-Index: Ac4T5yUIw+k22lWZIEOFsetrnEhXsg==
In-Reply-To: <512BA42602000078000C0D64@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jinsong Liu <jinsong.liu@intel.com>, Yongjie Ren <yongjie.ren@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: fix CMCI injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 16:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> This fixes the wrong use of literal vector 0xF7 with an "int"
> instruction (invalidated by 25113:14609be41f36) and the fact that doing
> the injection via a software interrupt was never valid anyway (because
> cmci_interrupt() acks the LAPIC, which does the wrong thing if the
> interrupt didn't get delivered though it).
> 
> In order to do latter, the patch introduces send_IPI_self(), at once
> removing two opend coded uses of "genapic" in the IRQ handling code.
> 
> Reported-by: Yongjie Ren <yongjie.ren@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -34,6 +34,7 @@ bool_t __read_mostly mce_broadcast = 0;
>  bool_t is_mc_panic;
>  unsigned int __read_mostly nr_mce_banks;
>  unsigned int __read_mostly firstbank;
> +uint8_t __read_mostly cmci_apic_vector;
>  
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> @@ -1198,12 +1199,6 @@ static void x86_mc_mceinject(void *data)
>      __asm__ __volatile__("int $0x12");
>  }
>  
> -static void x86_cmci_inject(void *data)
> -{
> -    printk("Simulating CMCI on cpu %d\n", smp_processor_id());
> -    __asm__ __volatile__("int $0xf7");
> -}
> -
>  #if BITS_PER_LONG == 64
>  
>  #define ID2COOKIE(id) ((mctelem_cookie_t)(id))
> @@ -1479,11 +1474,15 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
>              on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
>              break;
>          case XEN_MC_INJECT_TYPE_CMCI:
> -            if ( !cmci_support )
> +            if ( !cmci_apic_vector )
>                  ret = x86_mcerr(
>                      "No CMCI supported in platform\n", -EINVAL);
>              else
> -                on_selected_cpus(cpumap, x86_cmci_inject, NULL, 1);
> +            {
> +                if ( cpumask_test_cpu(smp_processor_id(), cpumap) )
> +                    send_IPI_self(cmci_apic_vector);
> +                send_IPI_mask(cpumap, cmci_apic_vector);
> +            }
>              break;
>          default:
>              ret = x86_mcerr("Wrong mca type\n", -EINVAL);
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -37,6 +37,8 @@ enum mcheck_type {
> mcheck_intel
>  };
>  
> +extern uint8_t cmci_apic_vector;
> +
>  /* Init functions */
>  enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
>  enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -644,7 +644,6 @@ static void intel_init_cmci(struct cpuin
>  {
>      u32 l, apic;
>      int cpu = smp_processor_id();
> -    static uint8_t cmci_apic_vector;
>  
>      if (!mce_available(c) || !cmci_support) {
>          if (opt_cpu_info)
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -646,7 +646,7 @@ void irq_move_cleanup_interrupt(struct c
>           * to myself.
>           */
>          if (irr  & (1 << (vector % 32))) {
> -            genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
> +            send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
>              TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
>                       irq, vector, smp_processor_id());
>              goto unlock;
> @@ -692,7 +692,7 @@ static void send_cleanup_vector(struct i
>  
>      cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask, &cpu_online_map);
>      desc->arch.move_cleanup_count = cpumask_weight(&cleanup_mask);
> -    genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
> +    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
>  
>      desc->arch.move_in_progress = 0;
>  }
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -38,6 +38,11 @@ void send_IPI_mask(const cpumask_t *mask
>      genapic->send_IPI_mask(mask, vector);
>  }
>  
> +void send_IPI_self(int vector)
> +{
> +    genapic->send_IPI_self(vector);
> +}
> +
>  /*
>   * Some notes on x86 processor bugs affecting SMP operation:
>   *
> --- a/xen/include/asm-x86/smp.h
> +++ b/xen/include/asm-x86/smp.h
> @@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
>  
>  void smp_send_nmi_allbutself(void);
>  
> -void  send_IPI_mask(const cpumask_t *mask, int vector);
> +void send_IPI_mask(const cpumask_t *, int vector);
> +void send_IPI_self(int vector);
>  
>  extern void (*mtrr_hook) (void);
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 06:05:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 06: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 1UADeY-00043y-Qj; Tue, 26 Feb 2013 06:04:38 +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 1UADeX-00043t-EY
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 06:04:37 +0000
Received: from [85.158.139.83:40872] by server-9.bemta-5.messagelabs.com id
	61/1B-08547-4705C215; Tue, 26 Feb 2013 06:04:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361858675!21596939!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14044 invoked from network); 26 Feb 2013 06:04:35 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 06:04:35 -0000
Received: by mail-wg0-f47.google.com with SMTP id dr13so3016291wgb.26
	for <xen-devel@lists.xen.org>; Mon, 25 Feb 2013 22:04:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=W4lESLH7Te8XUBsGTLu+FosYfT1TopOjaEARpIkinTQ=;
	b=BoS28BIXRMj7o7RXjG0mdxQQR5sawWd5aHort6sEWNcMBTT02hzqloUWarxcPY1JdR
	4j34K5laGDC2y3o9rmU4hJlKuutzr9AVuklvi43aQ/4JlWYt9X7DDwMoM84l3ZHgCLcK
	YRGrjLgk0kxyvmQeQsAsiX3tqGYNQxj8Rd1Tc1NEmJgERcWzNAXH1IFN5b6svXvyK0hs
	9gBPF7Y6YLTNMUn7hl+yH4JnDQjHVE8a3JsiTWvitQm3oCrgYcPPIUgQ9E6DoHK5Wpy5
	n1QwhB9iFNE0LEnQB0sjCV09+iWHgrkBRtIxqrEyWJU+ezpJdHoJRPc6tQUdfDyhRU9d
	Mwkg==
X-Received: by 10.180.87.170 with SMTP id az10mr17115019wib.3.1361858675392;
	Mon, 25 Feb 2013 22:04:35 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id o8sm18950031wix.7.2013.02.25.22.04.33
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Mon, 25 Feb 2013 22:04:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 26 Feb 2013 06:04:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD5200F0.4C9DF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: fix CMCI injection
Thread-Index: Ac4T5yUIw+k22lWZIEOFsetrnEhXsg==
In-Reply-To: <512BA42602000078000C0D64@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jinsong Liu <jinsong.liu@intel.com>, Yongjie Ren <yongjie.ren@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86: fix CMCI injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 16:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> This fixes the wrong use of literal vector 0xF7 with an "int"
> instruction (invalidated by 25113:14609be41f36) and the fact that doing
> the injection via a software interrupt was never valid anyway (because
> cmci_interrupt() acks the LAPIC, which does the wrong thing if the
> interrupt didn't get delivered though it).
> 
> In order to do latter, the patch introduces send_IPI_self(), at once
> removing two opend coded uses of "genapic" in the IRQ handling code.
> 
> Reported-by: Yongjie Ren <yongjie.ren@intel.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -34,6 +34,7 @@ bool_t __read_mostly mce_broadcast = 0;
>  bool_t is_mc_panic;
>  unsigned int __read_mostly nr_mce_banks;
>  unsigned int __read_mostly firstbank;
> +uint8_t __read_mostly cmci_apic_vector;
>  
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
>  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> @@ -1198,12 +1199,6 @@ static void x86_mc_mceinject(void *data)
>      __asm__ __volatile__("int $0x12");
>  }
>  
> -static void x86_cmci_inject(void *data)
> -{
> -    printk("Simulating CMCI on cpu %d\n", smp_processor_id());
> -    __asm__ __volatile__("int $0xf7");
> -}
> -
>  #if BITS_PER_LONG == 64
>  
>  #define ID2COOKIE(id) ((mctelem_cookie_t)(id))
> @@ -1479,11 +1474,15 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_m
>              on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
>              break;
>          case XEN_MC_INJECT_TYPE_CMCI:
> -            if ( !cmci_support )
> +            if ( !cmci_apic_vector )
>                  ret = x86_mcerr(
>                      "No CMCI supported in platform\n", -EINVAL);
>              else
> -                on_selected_cpus(cpumap, x86_cmci_inject, NULL, 1);
> +            {
> +                if ( cpumask_test_cpu(smp_processor_id(), cpumap) )
> +                    send_IPI_self(cmci_apic_vector);
> +                send_IPI_mask(cpumap, cmci_apic_vector);
> +            }
>              break;
>          default:
>              ret = x86_mcerr("Wrong mca type\n", -EINVAL);
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -37,6 +37,8 @@ enum mcheck_type {
> mcheck_intel
>  };
>  
> +extern uint8_t cmci_apic_vector;
> +
>  /* Init functions */
>  enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
>  enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -644,7 +644,6 @@ static void intel_init_cmci(struct cpuin
>  {
>      u32 l, apic;
>      int cpu = smp_processor_id();
> -    static uint8_t cmci_apic_vector;
>  
>      if (!mce_available(c) || !cmci_support) {
>          if (opt_cpu_info)
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -646,7 +646,7 @@ void irq_move_cleanup_interrupt(struct c
>           * to myself.
>           */
>          if (irr  & (1 << (vector % 32))) {
> -            genapic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
> +            send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
>              TRACE_3D(TRC_HW_IRQ_MOVE_CLEANUP_DELAY,
>                       irq, vector, smp_processor_id());
>              goto unlock;
> @@ -692,7 +692,7 @@ static void send_cleanup_vector(struct i
>  
>      cpumask_and(&cleanup_mask, desc->arch.old_cpu_mask, &cpu_online_map);
>      desc->arch.move_cleanup_count = cpumask_weight(&cleanup_mask);
> -    genapic->send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
> +    send_IPI_mask(&cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
>  
>      desc->arch.move_in_progress = 0;
>  }
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -38,6 +38,11 @@ void send_IPI_mask(const cpumask_t *mask
>      genapic->send_IPI_mask(mask, vector);
>  }
>  
> +void send_IPI_self(int vector)
> +{
> +    genapic->send_IPI_self(vector);
> +}
> +
>  /*
>   * Some notes on x86 processor bugs affecting SMP operation:
>   *
> --- a/xen/include/asm-x86/smp.h
> +++ b/xen/include/asm-x86/smp.h
> @@ -29,7 +29,8 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
>  
>  void smp_send_nmi_allbutself(void);
>  
> -void  send_IPI_mask(const cpumask_t *mask, int vector);
> +void send_IPI_mask(const cpumask_t *, int vector);
> +void send_IPI_self(int vector);
>  
>  extern void (*mtrr_hook) (void);
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 06:52:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 06: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 1UAEO4-0005hE-UD; Tue, 26 Feb 2013 06:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAEO3-0005h4-9N
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 06:51:39 +0000
Received: from [85.158.137.99:47074] by server-14.bemta-3.messagelabs.com id
	D3/23-23533-A7B5C215; Tue, 26 Feb 2013 06:51:38 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361861495!12444328!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTgyNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13461 invoked from network); 26 Feb 2013 06:51:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 06:51:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1Q6pULA030365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 06:51:31 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
	r1Q6pUjA005397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 06:51:30 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
	r1Q6pUQq023135; Tue, 26 Feb 2013 00:51:30 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 22:51:29 -0800
Message-ID: <512C5B96.10204@oracle.com>
Date: Tue, 26 Feb 2013 14:52:06 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: netdev@vger.kernel.org, konrad.wilk@oracle.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-16 0:00, Wei Liu wrote:
> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> ---
>   drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
>   1 file changed, 174 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 8bd75a1..de73a71 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -67,9 +67,19 @@ struct netfront_cb {
>
>   #define GRANT_INVALID_REF	0
>
> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> +#define XENNET_MAX_RING_PAGES      (1U<<  XENNET_MAX_RING_PAGE_ORDER)
> +
> +
> +#define NET_TX_RING_SIZE(_nr_pages)			\
> +	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> +#define NET_RX_RING_SIZE(_nr_pages)			\
> +	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> +
> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +
> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)

Not using multi-page ring here?
In xennet_create_dev, gnttab_alloc_grant_references allocates 
TX_MAX_TARGET number of grant reference for tx. In 
xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of 
grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally 
different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although 
skb_entry_is_link helps to not release invalid grants, lots of null loop 
seems unnecessary. I think TX_MAX_TARGET should be changed into some 
variableconnected with np->tx_ring_pages. Or you intended to use one 
page ring here?

>
>   struct netfront_stats {
>   	u64			rx_packets;
> @@ -80,6 +90,11 @@ struct netfront_stats {
>   };
>
>   struct netfront_info {
> +	/* Statistics */
> +	struct netfront_stats __percpu *stats;
> +
> +	unsigned long rx_gso_checksum_fixup;
> +
>   	struct list_head list;
>   	struct net_device *netdev;
>
> @@ -90,7 +105,9 @@ struct netfront_info {
>
>   	spinlock_t   tx_lock;
>   	struct xen_netif_tx_front_ring tx;
> -	int tx_ring_ref;
> +	int tx_ring_ref[XENNET_MAX_RING_PAGES];
> +	unsigned int tx_ring_page_order;
> +	unsigned int tx_ring_pages;
>
>   	/*
>   	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> @@ -104,36 +121,33 @@ struct netfront_info {
>   	union skb_entry {
>   		struct sk_buff *skb;
>   		unsigned long link;
> -	} tx_skbs[NET_TX_RING_SIZE];
> +	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
>   	grant_ref_t gref_tx_head;
> -	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> +	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
>   	unsigned tx_skb_freelist;
>
>   	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
>   	struct xen_netif_rx_front_ring rx;
> -	int rx_ring_ref;
> +	int rx_ring_ref[XENNET_MAX_RING_PAGES];
> +	unsigned int rx_ring_page_order;
> +	unsigned int rx_ring_pages;
>
>   	/* Receive-ring batched refills. */
>   #define RX_MIN_TARGET 8
>   #define RX_DFL_MIN_TARGET 64
> -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE(1), 256)

Not using multi-page ring here?
(See comments of tx side above)

Thanks
Annie

>   	unsigned rx_min_target, rx_max_target, rx_target;
>   	struct sk_buff_head rx_batch;
>
>   	struct timer_list rx_refill_timer;
>
> -	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> +	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
>   	grant_ref_t gref_rx_head;
> -	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> -
> -	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> -	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> -	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> -
> -	/* Statistics */
> -	struct netfront_stats __percpu *stats;
> +	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
>
> -	unsigned long rx_gso_checksum_fixup;
> +	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> +	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> +	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
>   };
>
>   struct netfront_rx_info {
> @@ -171,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
>   	return id;
>   }
>
> -static int xennet_rxidx(RING_IDX idx)
> +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
>   {
> -	return idx&  (NET_RX_RING_SIZE - 1);
> +	return idx&  (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
>   }
>
>   static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>   					 RING_IDX ri)
>   {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>   	struct sk_buff *skb = np->rx_skbs[i];
>   	np->rx_skbs[i] = NULL;
>   	return skb;
> @@ -188,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>   static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
>   					    RING_IDX ri)
>   {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>   	grant_ref_t ref = np->grant_rx_ref[i];
>   	np->grant_rx_ref[i] = GRANT_INVALID_REF;
>   	return ref;
> @@ -301,7 +315,7 @@ no_skb:
>
>   		skb->dev = dev;
>
> -		id = xennet_rxidx(req_prod + i);
> +		id = xennet_rxidx(req_prod + i, np);
>
>   		BUG_ON(np->rx_skbs[id]);
>   		np->rx_skbs[id] = skb;
> @@ -653,7 +667,7 @@ static int xennet_close(struct net_device *dev)
>   static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
>   				grant_ref_t ref)
>   {
> -	int new = xennet_rxidx(np->rx.req_prod_pvt);
> +	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
>
>   	BUG_ON(np->rx_skbs[new]);
>   	np->rx_skbs[new] = skb;
> @@ -1109,7 +1123,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
>   	struct sk_buff *skb;
>   	int i;
>
> -	for (i = 0; i<  NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i<  NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
>   		/* Skip over entries which are actually freelist references */
>   		if (skb_entry_is_link(&np->tx_skbs[i]))
>   			continue;
> @@ -1143,7 +1157,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
>
>   	spin_lock_bh(&np->rx_lock);
>
> -	for (id = 0; id<  NET_RX_RING_SIZE; id++) {
> +	for (id = 0; id<  NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
>   		ref = np->grant_rx_ref[id];
>   		if (ref == GRANT_INVALID_REF) {
>   			unused++;
> @@ -1324,13 +1338,13 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
>
>   	/* Initialise tx_skbs as a free chain containing every entry. */
>   	np->tx_skb_freelist = 0;
> -	for (i = 0; i<  NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i<  XENNET_MAX_TX_RING_SIZE; i++) {
>   		skb_entry_set_link(&np->tx_skbs[i], i+1);
>   		np->grant_tx_ref[i] = GRANT_INVALID_REF;
>   	}
>
>   	/* Clear out rx_skbs */
> -	for (i = 0; i<  NET_RX_RING_SIZE; i++) {
> +	for (i = 0; i<  XENNET_MAX_RX_RING_SIZE; i++) {
>   		np->rx_skbs[i] = NULL;
>   		np->grant_rx_ref[i] = GRANT_INVALID_REF;
>   	}
> @@ -1428,13 +1442,6 @@ static int netfront_probe(struct xenbus_device *dev,
>   	return err;
>   }
>
> -static void xennet_end_access(int ref, void *page)
> -{
> -	/* This frees the page as a side-effect */
> -	if (ref != GRANT_INVALID_REF)
> -		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> -}
> -
>   static void xennet_disconnect_backend(struct netfront_info *info)
>   {
>   	/* Stop old i/f to prevent errors whilst we rebuild the state. */
> @@ -1448,12 +1455,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>   		unbind_from_irqhandler(info->netdev->irq, info->netdev);
>   	info->evtchn = info->netdev->irq = 0;
>
> -	/* End access and free the pages */
> -	xennet_end_access(info->tx_ring_ref, info->tx.sring);
> -	xennet_end_access(info->rx_ring_ref, info->rx.sring);
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
> +	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
> +
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
> +	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
>
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
>   	info->tx.sring = NULL;
>   	info->rx.sring = NULL;
>   }
> @@ -1501,11 +1508,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>   	struct xen_netif_tx_sring *txs;
>   	struct xen_netif_rx_sring *rxs;
>   	int err;
> -	int grefs[1];
>   	struct net_device *netdev = info->netdev;
> +	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> +	int i;
>
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
> +	for (i = 0; i<  XENNET_MAX_RING_PAGES; i++) {
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +		info->rx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
>   	info->rx.sring = NULL;
>   	info->tx.sring = NULL;
>   	netdev->irq = 0;
> @@ -1516,50 +1526,100 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>   		goto fail;
>   	}
>
> -	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-tx-ring-page-order", "%u",
> +			&max_tx_ring_page_order);
> +	if (err<  0) {
> +		info->tx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single tx ring\n");
> +	} else {
> +		if (max_tx_ring_page_order>  XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_info(&dev->dev,
> +				 "backend ring page order %d too large, clamp to %d\n",
> +				 max_tx_ring_page_order,
> +				 XENNET_MAX_RING_PAGE_ORDER);
> +			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
> +		info->tx_ring_page_order = max_tx_ring_page_order;
> +		dev_info(&dev->dev, "multi-page tx ring, order = %d\n",
> +			 info->tx_ring_page_order);
> +	}
> +	info->tx_ring_pages = (1U<<  info->tx_ring_page_order);
> +
> +	txs = (struct xen_netif_tx_sring *)
> +		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
> +				 info->tx_ring_page_order);
>   	if (!txs) {
>   		err = -ENOMEM;
>   		xenbus_dev_fatal(dev, err, "allocating tx ring page");
>   		goto fail;
>   	}
>   	SHARED_RING_INIT(txs);
> -	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> +	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
> +
> +	err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
> +				info->tx_ring_ref);
> +	if (err<  0)
> +		goto grant_tx_ring_fail;
>
> -	err = xenbus_grant_ring(dev, txs, 1, grefs);
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-rx-ring-page-order", "%u",
> +			&max_rx_ring_page_order);
>   	if (err<  0) {
> -		free_page((unsigned long)txs);
> -		goto fail;
> +		info->rx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single rx ring\n");
> +	} else {
> +		if (max_rx_ring_page_order>  XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_info(&dev->dev,
> +				 "backend ring page order %d too large, clamp to %d\n",
> +				 max_rx_ring_page_order,
> +				 XENNET_MAX_RING_PAGE_ORDER);
> +			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
> +		info->rx_ring_page_order = max_rx_ring_page_order;
> +		dev_info(&dev->dev, "multi-page rx ring, order = %d\n",
> +			 info->rx_ring_page_order);
>   	}
> +	info->rx_ring_pages = (1U<<  info->rx_ring_page_order);
>
> -	info->tx_ring_ref = grefs[0];
> -	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	rxs = (struct xen_netif_rx_sring *)
> +		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
> +				 info->rx_ring_page_order);
>   	if (!rxs) {
>   		err = -ENOMEM;
>   		xenbus_dev_fatal(dev, err, "allocating rx ring page");
> -		goto fail;
> +		goto alloc_rx_ring_fail;
>   	}
>   	SHARED_RING_INIT(rxs);
> -	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> +	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
>
> -	err = xenbus_grant_ring(dev, rxs, 1, grefs);
> -	if (err<  0) {
> -		free_page((unsigned long)rxs);
> -		goto fail;
> -	}
> -	info->rx_ring_ref = grefs[0];
> +	err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
> +				info->rx_ring_ref);
> +	if (err<  0)
> +		goto grant_rx_ring_fail;
>
>   	err = xenbus_alloc_evtchn(dev,&info->evtchn);
>   	if (err)
> -		goto fail;
> +		goto alloc_evtchn_fail;
>
>   	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
>   					0, netdev->name, netdev);
>   	if (err<  0)
> -		goto fail;
> +		goto bind_fail;
>   	netdev->irq = err;
>   	return 0;
>
> - fail:
> +bind_fail:
> +	xenbus_free_evtchn(dev, info->evtchn);
> +alloc_evtchn_fail:
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
> +grant_rx_ring_fail:
> +	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
> +alloc_rx_ring_fail:
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
> +grant_tx_ring_fail:
> +	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
> +fail:
>   	return err;
>   }
>
> @@ -1570,6 +1630,7 @@ static int talk_to_netback(struct xenbus_device *dev,
>   	const char *message;
>   	struct xenbus_transaction xbt;
>   	int err;
> +	int i;
>
>   	/* Create shared ring, alloc event channel. */
>   	err = setup_netfront(dev, info);
> @@ -1583,18 +1644,58 @@ again:
>   		goto destroy_ring;
>   	}
>
> -	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> -			    info->tx_ring_ref);
> -	if (err) {
> -		message = "writing tx ring-ref";
> -		goto abort_transaction;
> +	if (info->tx_ring_page_order == 0) {
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> +				    info->tx_ring_ref[0]);
> +		if (err) {
> +			message = "writing tx ring-ref";
> +			goto abort_transaction;
> +		}
> +	} else {
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
> +				    info->tx_ring_page_order);
> +		if (err) {
> +			message = "writing tx-ring-order";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i<  info->tx_ring_pages; i++) {
> +			char name[sizeof("tx-ring-ref")+3];
> +			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->tx_ring_ref[i]);
> +			if (err) {
> +				message = "writing tx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>   	}
> -	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> -			    info->rx_ring_ref);
> -	if (err) {
> -		message = "writing rx ring-ref";
> -		goto abort_transaction;
> +
> +	if (info->rx_ring_page_order == 0) {
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> +				    info->rx_ring_ref[0]);
> +		if (err) {
> +			message = "writing rx ring-ref";
> +			goto abort_transaction;
> +		}
> +	} else {
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
> +				    info->rx_ring_page_order);
> +		if (err) {
> +			message = "writing rx-ring-order";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i<  info->rx_ring_pages; i++) {
> +			char name[sizeof("rx-ring-ref")+3];
> +			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->rx_ring_ref[i]);
> +			if (err) {
> +				message = "writing rx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>   	}
> +
>   	err = xenbus_printf(xbt, dev->nodename,
>   			    "event-channel", "%u", info->evtchn);
>   	if (err) {
> @@ -1681,7 +1782,8 @@ static int xennet_connect(struct net_device *dev)
>   	xennet_release_tx_bufs(np);
>
>   	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
> -	for (requeue_idx = 0, i = 0; i<  NET_RX_RING_SIZE; i++) {
> +	for (requeue_idx = 0, i = 0; i<  NET_RX_RING_SIZE(np->rx_ring_pages);
> +	     i++) {
>   		skb_frag_t *frag;
>   		const struct page *page;
>   		if (!np->rx_skbs[i])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 06:52:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 06: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 1UAEO4-0005hE-UD; Tue, 26 Feb 2013 06:51:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAEO3-0005h4-9N
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 06:51:39 +0000
Received: from [85.158.137.99:47074] by server-14.bemta-3.messagelabs.com id
	D3/23-23533-A7B5C215; Tue, 26 Feb 2013 06:51:38 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361861495!12444328!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNTgyNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13461 invoked from network); 26 Feb 2013 06:51:37 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 06:51:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1Q6pULA030365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 06:51:31 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
	r1Q6pUjA005397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 06:51:30 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
	r1Q6pUQq023135; Tue, 26 Feb 2013 00:51:30 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 25 Feb 2013 22:51:29 -0800
Message-ID: <512C5B96.10204@oracle.com>
Date: Tue, 26 Feb 2013 14:52:06 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: netdev@vger.kernel.org, konrad.wilk@oracle.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-16 0:00, Wei Liu wrote:
> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> ---
>   drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
>   1 file changed, 174 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 8bd75a1..de73a71 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -67,9 +67,19 @@ struct netfront_cb {
>
>   #define GRANT_INVALID_REF	0
>
> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> +#define XENNET_MAX_RING_PAGES      (1U<<  XENNET_MAX_RING_PAGE_ORDER)
> +
> +
> +#define NET_TX_RING_SIZE(_nr_pages)			\
> +	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> +#define NET_RX_RING_SIZE(_nr_pages)			\
> +	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> +
> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +
> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)

Not using multi-page ring here?
In xennet_create_dev, gnttab_alloc_grant_references allocates 
TX_MAX_TARGET number of grant reference for tx. In 
xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of 
grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally 
different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although 
skb_entry_is_link helps to not release invalid grants, lots of null loop 
seems unnecessary. I think TX_MAX_TARGET should be changed into some 
variableconnected with np->tx_ring_pages. Or you intended to use one 
page ring here?

>
>   struct netfront_stats {
>   	u64			rx_packets;
> @@ -80,6 +90,11 @@ struct netfront_stats {
>   };
>
>   struct netfront_info {
> +	/* Statistics */
> +	struct netfront_stats __percpu *stats;
> +
> +	unsigned long rx_gso_checksum_fixup;
> +
>   	struct list_head list;
>   	struct net_device *netdev;
>
> @@ -90,7 +105,9 @@ struct netfront_info {
>
>   	spinlock_t   tx_lock;
>   	struct xen_netif_tx_front_ring tx;
> -	int tx_ring_ref;
> +	int tx_ring_ref[XENNET_MAX_RING_PAGES];
> +	unsigned int tx_ring_page_order;
> +	unsigned int tx_ring_pages;
>
>   	/*
>   	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> @@ -104,36 +121,33 @@ struct netfront_info {
>   	union skb_entry {
>   		struct sk_buff *skb;
>   		unsigned long link;
> -	} tx_skbs[NET_TX_RING_SIZE];
> +	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
>   	grant_ref_t gref_tx_head;
> -	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> +	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
>   	unsigned tx_skb_freelist;
>
>   	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
>   	struct xen_netif_rx_front_ring rx;
> -	int rx_ring_ref;
> +	int rx_ring_ref[XENNET_MAX_RING_PAGES];
> +	unsigned int rx_ring_page_order;
> +	unsigned int rx_ring_pages;
>
>   	/* Receive-ring batched refills. */
>   #define RX_MIN_TARGET 8
>   #define RX_DFL_MIN_TARGET 64
> -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE(1), 256)

Not using multi-page ring here?
(See comments of tx side above)

Thanks
Annie

>   	unsigned rx_min_target, rx_max_target, rx_target;
>   	struct sk_buff_head rx_batch;
>
>   	struct timer_list rx_refill_timer;
>
> -	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> +	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
>   	grant_ref_t gref_rx_head;
> -	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> -
> -	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> -	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> -	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> -
> -	/* Statistics */
> -	struct netfront_stats __percpu *stats;
> +	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
>
> -	unsigned long rx_gso_checksum_fixup;
> +	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> +	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> +	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
>   };
>
>   struct netfront_rx_info {
> @@ -171,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
>   	return id;
>   }
>
> -static int xennet_rxidx(RING_IDX idx)
> +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
>   {
> -	return idx&  (NET_RX_RING_SIZE - 1);
> +	return idx&  (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
>   }
>
>   static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>   					 RING_IDX ri)
>   {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>   	struct sk_buff *skb = np->rx_skbs[i];
>   	np->rx_skbs[i] = NULL;
>   	return skb;
> @@ -188,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>   static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
>   					    RING_IDX ri)
>   {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>   	grant_ref_t ref = np->grant_rx_ref[i];
>   	np->grant_rx_ref[i] = GRANT_INVALID_REF;
>   	return ref;
> @@ -301,7 +315,7 @@ no_skb:
>
>   		skb->dev = dev;
>
> -		id = xennet_rxidx(req_prod + i);
> +		id = xennet_rxidx(req_prod + i, np);
>
>   		BUG_ON(np->rx_skbs[id]);
>   		np->rx_skbs[id] = skb;
> @@ -653,7 +667,7 @@ static int xennet_close(struct net_device *dev)
>   static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
>   				grant_ref_t ref)
>   {
> -	int new = xennet_rxidx(np->rx.req_prod_pvt);
> +	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
>
>   	BUG_ON(np->rx_skbs[new]);
>   	np->rx_skbs[new] = skb;
> @@ -1109,7 +1123,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
>   	struct sk_buff *skb;
>   	int i;
>
> -	for (i = 0; i<  NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i<  NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
>   		/* Skip over entries which are actually freelist references */
>   		if (skb_entry_is_link(&np->tx_skbs[i]))
>   			continue;
> @@ -1143,7 +1157,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
>
>   	spin_lock_bh(&np->rx_lock);
>
> -	for (id = 0; id<  NET_RX_RING_SIZE; id++) {
> +	for (id = 0; id<  NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
>   		ref = np->grant_rx_ref[id];
>   		if (ref == GRANT_INVALID_REF) {
>   			unused++;
> @@ -1324,13 +1338,13 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
>
>   	/* Initialise tx_skbs as a free chain containing every entry. */
>   	np->tx_skb_freelist = 0;
> -	for (i = 0; i<  NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i<  XENNET_MAX_TX_RING_SIZE; i++) {
>   		skb_entry_set_link(&np->tx_skbs[i], i+1);
>   		np->grant_tx_ref[i] = GRANT_INVALID_REF;
>   	}
>
>   	/* Clear out rx_skbs */
> -	for (i = 0; i<  NET_RX_RING_SIZE; i++) {
> +	for (i = 0; i<  XENNET_MAX_RX_RING_SIZE; i++) {
>   		np->rx_skbs[i] = NULL;
>   		np->grant_rx_ref[i] = GRANT_INVALID_REF;
>   	}
> @@ -1428,13 +1442,6 @@ static int netfront_probe(struct xenbus_device *dev,
>   	return err;
>   }
>
> -static void xennet_end_access(int ref, void *page)
> -{
> -	/* This frees the page as a side-effect */
> -	if (ref != GRANT_INVALID_REF)
> -		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> -}
> -
>   static void xennet_disconnect_backend(struct netfront_info *info)
>   {
>   	/* Stop old i/f to prevent errors whilst we rebuild the state. */
> @@ -1448,12 +1455,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>   		unbind_from_irqhandler(info->netdev->irq, info->netdev);
>   	info->evtchn = info->netdev->irq = 0;
>
> -	/* End access and free the pages */
> -	xennet_end_access(info->tx_ring_ref, info->tx.sring);
> -	xennet_end_access(info->rx_ring_ref, info->rx.sring);
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
> +	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
> +
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
> +	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
>
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
>   	info->tx.sring = NULL;
>   	info->rx.sring = NULL;
>   }
> @@ -1501,11 +1508,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>   	struct xen_netif_tx_sring *txs;
>   	struct xen_netif_rx_sring *rxs;
>   	int err;
> -	int grefs[1];
>   	struct net_device *netdev = info->netdev;
> +	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> +	int i;
>
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
> +	for (i = 0; i<  XENNET_MAX_RING_PAGES; i++) {
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +		info->rx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
>   	info->rx.sring = NULL;
>   	info->tx.sring = NULL;
>   	netdev->irq = 0;
> @@ -1516,50 +1526,100 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>   		goto fail;
>   	}
>
> -	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-tx-ring-page-order", "%u",
> +			&max_tx_ring_page_order);
> +	if (err<  0) {
> +		info->tx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single tx ring\n");
> +	} else {
> +		if (max_tx_ring_page_order>  XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_info(&dev->dev,
> +				 "backend ring page order %d too large, clamp to %d\n",
> +				 max_tx_ring_page_order,
> +				 XENNET_MAX_RING_PAGE_ORDER);
> +			max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
> +		info->tx_ring_page_order = max_tx_ring_page_order;
> +		dev_info(&dev->dev, "multi-page tx ring, order = %d\n",
> +			 info->tx_ring_page_order);
> +	}
> +	info->tx_ring_pages = (1U<<  info->tx_ring_page_order);
> +
> +	txs = (struct xen_netif_tx_sring *)
> +		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
> +				 info->tx_ring_page_order);
>   	if (!txs) {
>   		err = -ENOMEM;
>   		xenbus_dev_fatal(dev, err, "allocating tx ring page");
>   		goto fail;
>   	}
>   	SHARED_RING_INIT(txs);
> -	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> +	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
> +
> +	err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
> +				info->tx_ring_ref);
> +	if (err<  0)
> +		goto grant_tx_ring_fail;
>
> -	err = xenbus_grant_ring(dev, txs, 1, grefs);
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-rx-ring-page-order", "%u",
> +			&max_rx_ring_page_order);
>   	if (err<  0) {
> -		free_page((unsigned long)txs);
> -		goto fail;
> +		info->rx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single rx ring\n");
> +	} else {
> +		if (max_rx_ring_page_order>  XENNET_MAX_RING_PAGE_ORDER) {
> +			dev_info(&dev->dev,
> +				 "backend ring page order %d too large, clamp to %d\n",
> +				 max_rx_ring_page_order,
> +				 XENNET_MAX_RING_PAGE_ORDER);
> +			max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> +		}
> +		info->rx_ring_page_order = max_rx_ring_page_order;
> +		dev_info(&dev->dev, "multi-page rx ring, order = %d\n",
> +			 info->rx_ring_page_order);
>   	}
> +	info->rx_ring_pages = (1U<<  info->rx_ring_page_order);
>
> -	info->tx_ring_ref = grefs[0];
> -	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	rxs = (struct xen_netif_rx_sring *)
> +		__get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
> +				 info->rx_ring_page_order);
>   	if (!rxs) {
>   		err = -ENOMEM;
>   		xenbus_dev_fatal(dev, err, "allocating rx ring page");
> -		goto fail;
> +		goto alloc_rx_ring_fail;
>   	}
>   	SHARED_RING_INIT(rxs);
> -	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> +	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
>
> -	err = xenbus_grant_ring(dev, rxs, 1, grefs);
> -	if (err<  0) {
> -		free_page((unsigned long)rxs);
> -		goto fail;
> -	}
> -	info->rx_ring_ref = grefs[0];
> +	err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
> +				info->rx_ring_ref);
> +	if (err<  0)
> +		goto grant_rx_ring_fail;
>
>   	err = xenbus_alloc_evtchn(dev,&info->evtchn);
>   	if (err)
> -		goto fail;
> +		goto alloc_evtchn_fail;
>
>   	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
>   					0, netdev->name, netdev);
>   	if (err<  0)
> -		goto fail;
> +		goto bind_fail;
>   	netdev->irq = err;
>   	return 0;
>
> - fail:
> +bind_fail:
> +	xenbus_free_evtchn(dev, info->evtchn);
> +alloc_evtchn_fail:
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
> +grant_rx_ring_fail:
> +	free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
> +alloc_rx_ring_fail:
> +	xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
> +grant_tx_ring_fail:
> +	free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
> +fail:
>   	return err;
>   }
>
> @@ -1570,6 +1630,7 @@ static int talk_to_netback(struct xenbus_device *dev,
>   	const char *message;
>   	struct xenbus_transaction xbt;
>   	int err;
> +	int i;
>
>   	/* Create shared ring, alloc event channel. */
>   	err = setup_netfront(dev, info);
> @@ -1583,18 +1644,58 @@ again:
>   		goto destroy_ring;
>   	}
>
> -	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> -			    info->tx_ring_ref);
> -	if (err) {
> -		message = "writing tx ring-ref";
> -		goto abort_transaction;
> +	if (info->tx_ring_page_order == 0) {
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> +				    info->tx_ring_ref[0]);
> +		if (err) {
> +			message = "writing tx ring-ref";
> +			goto abort_transaction;
> +		}
> +	} else {
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
> +				    info->tx_ring_page_order);
> +		if (err) {
> +			message = "writing tx-ring-order";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i<  info->tx_ring_pages; i++) {
> +			char name[sizeof("tx-ring-ref")+3];
> +			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->tx_ring_ref[i]);
> +			if (err) {
> +				message = "writing tx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>   	}
> -	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> -			    info->rx_ring_ref);
> -	if (err) {
> -		message = "writing rx ring-ref";
> -		goto abort_transaction;
> +
> +	if (info->rx_ring_page_order == 0) {
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> +				    info->rx_ring_ref[0]);
> +		if (err) {
> +			message = "writing rx ring-ref";
> +			goto abort_transaction;
> +		}
> +	} else {
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
> +				    info->rx_ring_page_order);
> +		if (err) {
> +			message = "writing rx-ring-order";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i<  info->rx_ring_pages; i++) {
> +			char name[sizeof("rx-ring-ref")+3];
> +			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->rx_ring_ref[i]);
> +			if (err) {
> +				message = "writing rx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>   	}
> +
>   	err = xenbus_printf(xbt, dev->nodename,
>   			    "event-channel", "%u", info->evtchn);
>   	if (err) {
> @@ -1681,7 +1782,8 @@ static int xennet_connect(struct net_device *dev)
>   	xennet_release_tx_bufs(np);
>
>   	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
> -	for (requeue_idx = 0, i = 0; i<  NET_RX_RING_SIZE; i++) {
> +	for (requeue_idx = 0, i = 0; i<  NET_RX_RING_SIZE(np->rx_ring_pages);
> +	     i++) {
>   		skb_frag_t *frag;
>   		const struct page *page;
>   		if (!np->rx_skbs[i])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 07:43:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 07: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 1UAFBi-0007Kx-3J; Tue, 26 Feb 2013 07:42:58 +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 1UAFBg-0007Ks-DZ
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 07:42:56 +0000
Received: from [85.158.137.99:45371] by server-6.bemta-3.messagelabs.com id
	0D/90-29959-F776C215; Tue, 26 Feb 2013 07:42:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361864574!17000882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7170 invoked from network); 26 Feb 2013 07:42:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 07:42:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 07:42:54 +0000
Message-Id: <512C758B02000078000C0F75@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 07:42:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Suravee Suthikulanit" <suravee.suthikulpanit@amd.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E9A02000078000BED52@nat28.tlf.novell.com>
	<512BD8B7.9080303@amd.com>
In-Reply-To: <512BD8B7.9080303@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 3/4] IOMMU,
 AMD Family15h Model10-1Fh erratum 746 Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 22:33, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote:
> This patch looks good.  I have tested on the system I have and it does 
> what it's supposed to.  Thank you for porting the patch over from Linux.

Thanks - I take this as an ack.

Jan

> On 2/15/2013 10:21 AM, Jan Beulich wrote:
>> The IOMMU may stop processing page translations due to a perceived lack
>> of credits for writing upstream peripheral page service request (PPR)
>> or event logs. If the L2B miscellaneous clock gating feature is enabled
>> the IOMMU does not properly register credits after the log request has
>> completed, leading to a potential system hang.
>>
>> BIOSes are supposed to disable L2B micellaneous clock gating by setting
>> L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
>> patch corrects that for those which do not enable this workaround.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>> +++ b/xen/drivers/passthrough/amd/iommu_init.c
>> @@ -792,6 +792,42 @@ static bool_t __init set_iommu_interrupt
>>       return 1;
>>   }
>>   
>> +/*
>> + * Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall 
> Translations)
>> + * Workaround:
>> + *     BIOS should disable L2B micellaneous clock gating by setting
>> + *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b
>> + */
>> +static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu)
>> +{
>> +    u32 value;
>> +    u8 bus = PCI_BUS(iommu->bdf);
>> +    u8 dev = PCI_SLOT(iommu->bdf);
>> +    u8 func = PCI_FUNC(iommu->bdf);
>> +
>> +    if ( (boot_cpu_data.x86 != 0x15) ||
>> +         (boot_cpu_data.x86_model < 0x10) ||
>> +         (boot_cpu_data.x86_model > 0x1f) )
>> +        return;
>> +
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
>> +    value = pci_conf_read32(iommu->seg, bus, dev, func, 0xf4);
>> +
>> +    if ( value & (1 << 2) )
>> +        return;
>> +
>> +    /* Select NB indirect register 0x90 and enable writing */
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90 | (1 << 8));
>> +
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf4, value | (1 << 2));
>> +    printk(XENLOG_INFO
>> +           "AMD-Vi: Applying erratum 746 workaround for IOMMU at 
> %04x:%02x:%02x.%u\n",
>> +           iommu->seg, bus, dev, func);
>> +
>> +    /* Clear the enable writing bit */
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
>> +}
>> +
>>   static void enable_iommu(struct amd_iommu *iommu)
>>   {
>>       unsigned long flags;
>> @@ -805,6 +841,8 @@ static void enable_iommu(struct amd_iomm
>>           return;
>>       }
>>   
>> +    amd_iommu_erratum_746_workaround(iommu);
>> +
>>       register_iommu_dev_table_in_mmio_space(iommu);
>>       register_iommu_cmd_buffer_in_mmio_space(iommu);
>>       register_iommu_event_log_in_mmio_space(iommu);
>>
>>
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 07:43:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 07: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 1UAFBi-0007Kx-3J; Tue, 26 Feb 2013 07:42:58 +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 1UAFBg-0007Ks-DZ
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 07:42:56 +0000
Received: from [85.158.137.99:45371] by server-6.bemta-3.messagelabs.com id
	0D/90-29959-F776C215; Tue, 26 Feb 2013 07:42:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361864574!17000882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7170 invoked from network); 26 Feb 2013 07:42:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 07:42:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 07:42:54 +0000
Message-Id: <512C758B02000078000C0F75@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 07:42:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Suravee Suthikulanit" <suravee.suthikulpanit@amd.com>
References: <511E6CAD02000078000BED19@nat28.tlf.novell.com>
	<511E6E9A02000078000BED52@nat28.tlf.novell.com>
	<512BD8B7.9080303@amd.com>
In-Reply-To: <512BD8B7.9080303@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Sherry Hurwitz <sherry.hurwitz@amd.com>
Subject: Re: [Xen-devel] [PATCH 3/4] IOMMU,
 AMD Family15h Model10-1Fh erratum 746 Workaround
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 22:33, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote:
> This patch looks good.  I have tested on the system I have and it does 
> what it's supposed to.  Thank you for porting the patch over from Linux.

Thanks - I take this as an ack.

Jan

> On 2/15/2013 10:21 AM, Jan Beulich wrote:
>> The IOMMU may stop processing page translations due to a perceived lack
>> of credits for writing upstream peripheral page service request (PPR)
>> or event logs. If the L2B miscellaneous clock gating feature is enabled
>> the IOMMU does not properly register credits after the log request has
>> completed, leading to a potential system hang.
>>
>> BIOSes are supposed to disable L2B micellaneous clock gating by setting
>> L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
>> patch corrects that for those which do not enable this workaround.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/drivers/passthrough/amd/iommu_init.c
>> +++ b/xen/drivers/passthrough/amd/iommu_init.c
>> @@ -792,6 +792,42 @@ static bool_t __init set_iommu_interrupt
>>       return 1;
>>   }
>>   
>> +/*
>> + * Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall 
> Translations)
>> + * Workaround:
>> + *     BIOS should disable L2B micellaneous clock gating by setting
>> + *     L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b
>> + */
>> +static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu)
>> +{
>> +    u32 value;
>> +    u8 bus = PCI_BUS(iommu->bdf);
>> +    u8 dev = PCI_SLOT(iommu->bdf);
>> +    u8 func = PCI_FUNC(iommu->bdf);
>> +
>> +    if ( (boot_cpu_data.x86 != 0x15) ||
>> +         (boot_cpu_data.x86_model < 0x10) ||
>> +         (boot_cpu_data.x86_model > 0x1f) )
>> +        return;
>> +
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
>> +    value = pci_conf_read32(iommu->seg, bus, dev, func, 0xf4);
>> +
>> +    if ( value & (1 << 2) )
>> +        return;
>> +
>> +    /* Select NB indirect register 0x90 and enable writing */
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90 | (1 << 8));
>> +
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf4, value | (1 << 2));
>> +    printk(XENLOG_INFO
>> +           "AMD-Vi: Applying erratum 746 workaround for IOMMU at 
> %04x:%02x:%02x.%u\n",
>> +           iommu->seg, bus, dev, func);
>> +
>> +    /* Clear the enable writing bit */
>> +    pci_conf_write32(iommu->seg, bus, dev, func, 0xf0, 0x90);
>> +}
>> +
>>   static void enable_iommu(struct amd_iommu *iommu)
>>   {
>>       unsigned long flags;
>> @@ -805,6 +841,8 @@ static void enable_iommu(struct amd_iomm
>>           return;
>>       }
>>   
>> +    amd_iommu_erratum_746_workaround(iommu);
>> +
>>       register_iommu_dev_table_in_mmio_space(iommu);
>>       register_iommu_cmd_buffer_in_mmio_space(iommu);
>>       register_iommu_event_log_in_mmio_space(iommu);
>>
>>
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:19:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAFkQ-0000QU-LT; Tue, 26 Feb 2013 08:18: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 1UAFkO-0000QJ-K2
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:18:48 +0000
Received: from [85.158.139.211:39531] by server-15.bemta-5.messagelabs.com id
	6E/BB-22815-7EF6C215; Tue, 26 Feb 2013 08:18:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361866725!17751569!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDExMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7772 invoked from network); 26 Feb 2013 08:18:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 08:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="9598402"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 08:18:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 03:18:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAFkK-0000ml-T2;
	Tue, 26 Feb 2013 08:18:44 +0000
Date: Tue, 26 Feb 2013 08:18:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <65A5A13AA7E2781D12DC1DA0@Ximines.local>
Message-ID: <alpine.DEB.2.02.1302260816460.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
	<alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
	<65A5A13AA7E2781D12DC1DA0@Ximines.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Alex Bligh wrote:
> Stefano,
> 
> --On 25 February 2013 20:14:33 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 25 Feb 2013, Alex Bligh wrote:
> >> However, that isn't the end of the story. If you want a lightweight
> >> deb that doesn't take 39 years to build and is integrated into the
> >> build system (because you are a developer), the minideb thing is
> >> far easier (as it's just an extra make step), than debuild -us -uc -b,
> >> dealing with all the debian/ubuntu patches that get applied to the
> >> source, etc. etc.
> >
> > That's all good, but how does it compare to the deb target of the
> > xen-unstable build system?
> 
> How does the minideb thing compare? It's exactly the same, except:
> 
> * it misses the files that aren't needed for a minimal xl based install.
>   So, for instance, no header files.
> 
> * I made the init scripts do something useful (arguably this change
>   should be brought over to the main debian target).

Could you "fix" the init scripts in the main debian target?
If we overlook the lack of header files, you'll have what you want and
we won't have to maintain two separate deb build targets.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:19:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAFkQ-0000QU-LT; Tue, 26 Feb 2013 08:18: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 1UAFkO-0000QJ-K2
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:18:48 +0000
Received: from [85.158.139.211:39531] by server-15.bemta-5.messagelabs.com id
	6E/BB-22815-7EF6C215; Tue, 26 Feb 2013 08:18:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361866725!17751569!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDExMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7772 invoked from network); 26 Feb 2013 08:18:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 08:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="9598402"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 08:18:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 03:18:45 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAFkK-0000ml-T2;
	Tue, 26 Feb 2013 08:18:44 +0000
Date: Tue, 26 Feb 2013 08:18:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <65A5A13AA7E2781D12DC1DA0@Ximines.local>
Message-ID: <alpine.DEB.2.02.1302260816460.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
	<alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
	<65A5A13AA7E2781D12DC1DA0@Ximines.local>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 25 Feb 2013, Alex Bligh wrote:
> Stefano,
> 
> --On 25 February 2013 20:14:33 +0000 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 25 Feb 2013, Alex Bligh wrote:
> >> However, that isn't the end of the story. If you want a lightweight
> >> deb that doesn't take 39 years to build and is integrated into the
> >> build system (because you are a developer), the minideb thing is
> >> far easier (as it's just an extra make step), than debuild -us -uc -b,
> >> dealing with all the debian/ubuntu patches that get applied to the
> >> source, etc. etc.
> >
> > That's all good, but how does it compare to the deb target of the
> > xen-unstable build system?
> 
> How does the minideb thing compare? It's exactly the same, except:
> 
> * it misses the files that aren't needed for a minimal xl based install.
>   So, for instance, no header files.
> 
> * I made the init scripts do something useful (arguably this change
>   should be brought over to the main debian target).

Could you "fix" the init scripts in the main debian target?
If we overlook the lack of header files, you'll have what you want and
we won't have to maintain two separate deb build targets.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:32:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAFx7-0000lW-DE; Tue, 26 Feb 2013 08:31:57 +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 1UAFx6-0000lR-18
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:31:56 +0000
Received: from [85.158.137.99:17294] by server-12.bemta-3.messagelabs.com id
	6E/80-05889-BF27C215; Tue, 26 Feb 2013 08:31:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361867514!17928454!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1831 invoked from network); 26 Feb 2013 08:31:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 08:31:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 08:31:53 +0000
Message-Id: <512C810402000078000C0FBB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 08:31:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xinxin Jin" <xinxinjin89@gmail.com>
References: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
In-Reply-To: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] When does Xen build 1:1 direct mapping of all
 physical 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

>>> On 25.02.13 at 20:51, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> I assumed that Xen fills up the page table entires for 1:1 direct mapping
> of all physical memory at start time, but I cannot find the code. Could
> anyone tell me when Xen builds up pte for this mapping ?

xen/arch/x86/mm.c:init_frametable()

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:32:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAFx7-0000lW-DE; Tue, 26 Feb 2013 08:31:57 +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 1UAFx6-0000lR-18
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:31:56 +0000
Received: from [85.158.137.99:17294] by server-12.bemta-3.messagelabs.com id
	6E/80-05889-BF27C215; Tue, 26 Feb 2013 08:31:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361867514!17928454!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1831 invoked from network); 26 Feb 2013 08:31:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 08:31:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 08:31:53 +0000
Message-Id: <512C810402000078000C0FBB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 08:31:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xinxin Jin" <xinxinjin89@gmail.com>
References: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
In-Reply-To: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] When does Xen build 1:1 direct mapping of all
 physical 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

>>> On 25.02.13 at 20:51, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> I assumed that Xen fills up the page table entires for 1:1 direct mapping
> of all physical memory at start time, but I cannot find the code. Could
> anyone tell me when Xen builds up pte for this mapping ?

xen/arch/x86/mm.c:init_frametable()

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:34:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAFyy-0000qW-Un; Tue, 26 Feb 2013 08:33:52 +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 1UAFyw-0000qP-P7
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:33:50 +0000
Received: from [85.158.137.99:48903] by server-14.bemta-3.messagelabs.com id
	0E/34-23533-9637C215; Tue, 26 Feb 2013 08:33:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361867624!15751652!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6420 invoked from network); 26 Feb 2013 08:33:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 08:33:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 08:33:44 +0000
Message-Id: <512C817502000078000C0FC8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 08:33:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xinxin Jin" <xinxinjin89@gmail.com>
References: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
In-Reply-To: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The different between map_pages_to_xen and
 mfn_to_virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 21:41, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> I have some confusion about the purpose of the two functions.
> map_pages_to_xen is to map machine page range in Xen virtual address space.
> mfn_to_virt() is to convert between machine frame number and xen-heap
> virtual address. So what is the difference? When I need to map some machine
> pages to Xen space, which function should I use? Thanks,

You describe the difference yourself - one function establishes a
mapping, while the other only does a translation assuming that
the 1:1 mapping for the given MFN was already established (at
boot time, or during memory hotplug processing).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:34:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAFyy-0000qW-Un; Tue, 26 Feb 2013 08:33:52 +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 1UAFyw-0000qP-P7
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:33:50 +0000
Received: from [85.158.137.99:48903] by server-14.bemta-3.messagelabs.com id
	0E/34-23533-9637C215; Tue, 26 Feb 2013 08:33:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361867624!15751652!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6420 invoked from network); 26 Feb 2013 08:33:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 08:33:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 08:33:44 +0000
Message-Id: <512C817502000078000C0FC8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 08:33:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xinxin Jin" <xinxinjin89@gmail.com>
References: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
In-Reply-To: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The different between map_pages_to_xen and
 mfn_to_virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 21:41, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> I have some confusion about the purpose of the two functions.
> map_pages_to_xen is to map machine page range in Xen virtual address space.
> mfn_to_virt() is to convert between machine frame number and xen-heap
> virtual address. So what is the difference? When I need to map some machine
> pages to Xen space, which function should I use? Thanks,

You describe the difference yourself - one function establishes a
mapping, while the other only does a translation assuming that
the 1:1 mapping for the given MFN was already established (at
boot time, or during memory hotplug processing).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:43:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAG7b-00016V-V5; Tue, 26 Feb 2013 08:42: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 1UAG7a-00016Q-Rk
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:42:46 +0000
Received: from [193.109.254.147:47954] by server-5.bemta-14.messagelabs.com id
	BA/90-21539-6857C215; Tue, 26 Feb 2013 08:42:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361868116!8959389!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16214 invoked from network); 26 Feb 2013 08:41:57 -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; 26 Feb 2013 08:41:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 08:41:56 +0000
Message-Id: <512C836102000078000C0FD7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 08:41:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
In-Reply-To: <312569942.20130225231830@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> I can't get linux-3.9 rc0 to boot under xen-unstable.
> It doesn't detect the s-ata controller, so it ends op with udev timing and 
> bailing out to busybox.
> 
> I don't see a obvious error in the logs.

Perhaps because the log is far from being complete? There's a huge
gap right before the first pciback message, yet that's quite likely
the relevant part.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:43:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08: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 1UAG7b-00016V-V5; Tue, 26 Feb 2013 08:42: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 1UAG7a-00016Q-Rk
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:42:46 +0000
Received: from [193.109.254.147:47954] by server-5.bemta-14.messagelabs.com id
	BA/90-21539-6857C215; Tue, 26 Feb 2013 08:42:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361868116!8959389!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ5ODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16214 invoked from network); 26 Feb 2013 08:41:57 -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; 26 Feb 2013 08:41:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 08:41:56 +0000
Message-Id: <512C836102000078000C0FD7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 08:41:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
In-Reply-To: <312569942.20130225231830@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> I can't get linux-3.9 rc0 to boot under xen-unstable.
> It doesn't detect the s-ata controller, so it ends op with udev timing and 
> bailing out to busybox.
> 
> I don't see a obvious error in the logs.

Perhaps because the log is far from being complete? There's a huge
gap right before the first pciback message, yet that's quite likely
the relevant part.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:55:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08:55: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 1UAGJy-0001JL-AX; Tue, 26 Feb 2013 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 <zhenzhong.duan@oracle.com>) id 1UAGJx-0001JG-DI
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:55:33 +0000
Received: from [85.158.139.83:50591] by server-6.bemta-5.messagelabs.com id
	90/07-21466-4887C215; Tue, 26 Feb 2013 08:55:32 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361868929!28986863!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ3MDU2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26320 invoked from network); 26 Feb 2013 08:55:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 08:55:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1Q8tKkL025019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 08:55:21 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
	r1Q8tJcO006863
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 08:55: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
	r1Q8tJHi032059; Tue, 26 Feb 2013 02:55:19 -0600
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 00:55:19 -0800
Message-ID: <512C78D2.8030903@oracle.com>
Date: Tue, 26 Feb 2013 16:56:50 +0800
From: DuanZhenzhong <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Joe Jin <joe.jin@oracle.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] passthroughed msix 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-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 maintainer,

Reprodue an bug on xen-unstable, it's an irq affinity issue for 
passthroughed msix device to uek1 pvhvm(2.6.32 stable).
I passthrough two mptsas devices(0000:0d:0.0, 0000:1f:0.0) to a pvhvm, 
irq affinity can't be changed.
Step to reproduce is as below:
1. xl -f pci-assignable-add 0000:0d:0.0; xl -f pci-assignable-add 
0000:1f:0.0
2.xm cr -c vm.cfg
[root@rac10box2 ~]# cat /proc/interrupts |grep mpt2sas0
 48:     340449          0          0          0          0 0          
0          0          0          0          0 0   PCI-MSI-edge      
mpt2sas0-msix0
[root@rac10box2 ~]# cat /proc/irq/48/smp_affinity
0fff
[root@rac10box2 ~]# echo 2>/proc/irq/48/smp_affinity
[root@rac10box2 ~]# cat /proc/irq/48/smp_affinity
0002
[root@rac10box2 ~]# cat /proc/interrupts |grep mpt
 48:     342051        0          0          0          0 0          
0          0          0          0          0 0   PCI-MSI-edge      
mpt2sas0-msix0
After change affinity to vcpu1, interrupt still happen on vcpu0. And 
sometimes we got "/No irq handler for vector (irq -1)/" and panic.
qemu-dm.log shows error:
pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 4f
pt_msix_update_one: Update msix entry 0 with pirq 4f gvec 59
pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 4e
pt_msix_update_one: Update msix entry 0 with pirq 4e gvec 69
pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
(fee00000 -> fee02000)
pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
(00004059 -> 00004071)

Can't reproduce with uek2(3.1 stable), but if I disable hvm_pirqs 
support in uek2, reproduce the same.
Test patch below:
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index a22ad4b..2d795d1 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@-400,7 +400,6 @int __init pci_xen_init(void)
.
 int __init pci_xen_hvm_init(void)
 {
-       if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
                return 0;
.
 #ifdef CONFIG_ACPI
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf28d69..64f6c6c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@-1536,8 +1536,6 @bool xen_hvm_need_lapic(void)
                return false;
        if (!xen_hvm_domain())
                return false;
-       if (xen_feature(XENFEAT_hvm_pirqs) && xen_have_vector_callback)
-               return false;
        return true;
 }
 EXPORT_SYMBOL_GPL(xen_hvm_need_lapic);

btw: can't reproduce too if disable msi support.
I'll upload what you need, just tell me.

thanks
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 08:55:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 08:55: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 1UAGJy-0001JL-AX; Tue, 26 Feb 2013 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 <zhenzhong.duan@oracle.com>) id 1UAGJx-0001JG-DI
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 08:55:33 +0000
Received: from [85.158.139.83:50591] by server-6.bemta-5.messagelabs.com id
	90/07-21466-4887C215; Tue, 26 Feb 2013 08:55:32 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361868929!28986863!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ3MDU2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26320 invoked from network); 26 Feb 2013 08:55:30 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 08:55:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1Q8tKkL025019
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 08:55:21 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
	r1Q8tJcO006863
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 08:55: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
	r1Q8tJHi032059; Tue, 26 Feb 2013 02:55:19 -0600
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 00:55:19 -0800
Message-ID: <512C78D2.8030903@oracle.com>
Date: Tue, 26 Feb 2013 16:56:50 +0800
From: DuanZhenzhong <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xen.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Joe Jin <joe.jin@oracle.com>,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] passthroughed msix 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-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 maintainer,

Reprodue an bug on xen-unstable, it's an irq affinity issue for 
passthroughed msix device to uek1 pvhvm(2.6.32 stable).
I passthrough two mptsas devices(0000:0d:0.0, 0000:1f:0.0) to a pvhvm, 
irq affinity can't be changed.
Step to reproduce is as below:
1. xl -f pci-assignable-add 0000:0d:0.0; xl -f pci-assignable-add 
0000:1f:0.0
2.xm cr -c vm.cfg
[root@rac10box2 ~]# cat /proc/interrupts |grep mpt2sas0
 48:     340449          0          0          0          0 0          
0          0          0          0          0 0   PCI-MSI-edge      
mpt2sas0-msix0
[root@rac10box2 ~]# cat /proc/irq/48/smp_affinity
0fff
[root@rac10box2 ~]# echo 2>/proc/irq/48/smp_affinity
[root@rac10box2 ~]# cat /proc/irq/48/smp_affinity
0002
[root@rac10box2 ~]# cat /proc/interrupts |grep mpt
 48:     342051        0          0          0          0 0          
0          0          0          0          0 0   PCI-MSI-edge      
mpt2sas0-msix0
After change affinity to vcpu1, interrupt still happen on vcpu0. And 
sometimes we got "/No irq handler for vector (irq -1)/" and panic.
qemu-dm.log shows error:
pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 4f
pt_msix_update_one: Update msix entry 0 with pirq 4f gvec 59
pt_msixctrl_reg_write: guest enabling MSI-X, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 4e
pt_msix_update_one: Update msix entry 0 with pirq 4e gvec 69
pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
(fee00000 -> fee02000)
pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
(00004059 -> 00004071)

Can't reproduce with uek2(3.1 stable), but if I disable hvm_pirqs 
support in uek2, reproduce the same.
Test patch below:
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index a22ad4b..2d795d1 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@-400,7 +400,6 @int __init pci_xen_init(void)
.
 int __init pci_xen_hvm_init(void)
 {
-       if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
                return 0;
.
 #ifdef CONFIG_ACPI
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf28d69..64f6c6c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@-1536,8 +1536,6 @bool xen_hvm_need_lapic(void)
                return false;
        if (!xen_hvm_domain())
                return false;
-       if (xen_feature(XENFEAT_hvm_pirqs) && xen_have_vector_callback)
-               return false;
        return true;
 }
 EXPORT_SYMBOL_GPL(xen_hvm_need_lapic);

btw: can't reproduce too if disable msi support.
I'll upload what you need, just tell me.

thanks
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:07:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAGVc-0001gX-BD; Tue, 26 Feb 2013 09:07: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 1UAGVb-0001gN-6v
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:07:35 +0000
Received: from [85.158.139.211:6524] by server-3.bemta-5.messagelabs.com id
	2E/F4-17256-65B7C215; Tue, 26 Feb 2013 09:07:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361869610!19335333!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26981 invoked from network); 26 Feb 2013 09:06:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:06:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1884738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 09:06:50 +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.297.1;
	Tue, 26 Feb 2013 09:06:49 +0000
Message-ID: <1361869609.11431.26.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Tue, 26 Feb 2013 09:06:49 +0000
In-Reply-To: <1361783984.26546.160.camel@zakaz.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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

This patch fixes the current build breakage, anyone want to ack or nack?

I'm about to cycle into the office, hopefully I can apply when I arrive.

Ian.

> > However, the problem in this case appears to be that the ARM structure size
> > has changed. If so, that needs to be fixed, or reference.size needs to be
> > updated.
> 
> The problem is the use of '#pragma pack(4)' when building the foreign
> headers on x86_32.
> 
> I think it is useful to keep checking all arches on every build, rather
> than splitting into x86 and arm checks, since that will help catch
> inadvertent cross-arch breakage.
> 
> 8<-------------------
> 
> 
> From a20962085ef8d4c3d55f830647cdcb496bc5ee4a Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 25 Feb 2013 09:11:04 +0000
> Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm
> 
> When building the foreign headers on x86_32 we use '#pragma pack(4)' and
> therefore need to explicitly align types which should be aligned to 8-byte
> boundaries.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/include/xen-foreign/mkheader.py |   14 ++++++++++----
>  1 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index 8a784d3..5bd6eec 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -20,15 +20,18 @@ footer = {};
>  inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
> -    "xen_pfn_t"     : "uint64_t",
> -    "xen_ulong_t"   : "uint64_t",
> +    "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
> +    "uint64_t"      : "__align8__ uint64_t",
>  };
>  header["arm32"] = """
>  #define __arm___ARM32 1
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
> +# define __align8__ __attribute__((aligned (8)))
>  #else
>  # define __DECL_REG(n64, n32) uint64_t n64
> +# define FIXME
>  #endif
>  """;
>  footer["arm32"] = """
> @@ -38,15 +41,18 @@ footer["arm32"] = """
>  inttypes["arm64"] = {
>      "unsigned long" : "__danger_unsigned_long_on_arm64",
>      "long"          : "__danger_long_on_arm64",
> -    "xen_pfn_t"     : "uint64_t",
> -    "xen_ulong_t"   : "uint64_t",
> +    "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
> +    "uint64_t"      : "__align8__ uint64_t",
>  };
>  header["arm64"] = """
>  #define __aarch64___ARM64 1
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
> +# define __align8__ __attribute__((aligned (8)))
>  #else
>  # define __DECL_REG(n64, n32) uint64_t n64
> +# define FIXME
>  #endif
>  """;
>  footer["arm64"] = """



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:07:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAGVc-0001gX-BD; Tue, 26 Feb 2013 09:07: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 1UAGVb-0001gN-6v
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:07:35 +0000
Received: from [85.158.139.211:6524] by server-3.bemta-5.messagelabs.com id
	2E/F4-17256-65B7C215; Tue, 26 Feb 2013 09:07:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361869610!19335333!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26981 invoked from network); 26 Feb 2013 09:06:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:06:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1884738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 09:06:50 +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.297.1;
	Tue, 26 Feb 2013 09:06:49 +0000
Message-ID: <1361869609.11431.26.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Tue, 26 Feb 2013 09:06:49 +0000
In-Reply-To: <1361783984.26546.160.camel@zakaz.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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

This patch fixes the current build breakage, anyone want to ack or nack?

I'm about to cycle into the office, hopefully I can apply when I arrive.

Ian.

> > However, the problem in this case appears to be that the ARM structure size
> > has changed. If so, that needs to be fixed, or reference.size needs to be
> > updated.
> 
> The problem is the use of '#pragma pack(4)' when building the foreign
> headers on x86_32.
> 
> I think it is useful to keep checking all arches on every build, rather
> than splitting into x86 and arm checks, since that will help catch
> inadvertent cross-arch breakage.
> 
> 8<-------------------
> 
> 
> From a20962085ef8d4c3d55f830647cdcb496bc5ee4a Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Mon, 25 Feb 2013 09:11:04 +0000
> Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm
> 
> When building the foreign headers on x86_32 we use '#pragma pack(4)' and
> therefore need to explicitly align types which should be aligned to 8-byte
> boundaries.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/include/xen-foreign/mkheader.py |   14 ++++++++++----
>  1 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
> index 8a784d3..5bd6eec 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -20,15 +20,18 @@ footer = {};
>  inttypes["arm32"] = {
>      "unsigned long" : "uint32_t",
>      "long"          : "uint32_t",
> -    "xen_pfn_t"     : "uint64_t",
> -    "xen_ulong_t"   : "uint64_t",
> +    "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
> +    "uint64_t"      : "__align8__ uint64_t",
>  };
>  header["arm32"] = """
>  #define __arm___ARM32 1
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
> +# define __align8__ __attribute__((aligned (8)))
>  #else
>  # define __DECL_REG(n64, n32) uint64_t n64
> +# define FIXME
>  #endif
>  """;
>  footer["arm32"] = """
> @@ -38,15 +41,18 @@ footer["arm32"] = """
>  inttypes["arm64"] = {
>      "unsigned long" : "__danger_unsigned_long_on_arm64",
>      "long"          : "__danger_long_on_arm64",
> -    "xen_pfn_t"     : "uint64_t",
> -    "xen_ulong_t"   : "uint64_t",
> +    "xen_pfn_t"     : "__align8__ uint64_t",
> +    "xen_ulong_t"   : "__align8__ uint64_t",
> +    "uint64_t"      : "__align8__ uint64_t",
>  };
>  header["arm64"] = """
>  #define __aarch64___ARM64 1
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
> +# define __align8__ __attribute__((aligned (8)))
>  #else
>  # define __DECL_REG(n64, n32) uint64_t n64
> +# define FIXME
>  #endif
>  """;
>  footer["arm64"] = """



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:28: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 1UAGph-00027M-BP; Tue, 26 Feb 2013 09:28:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1UAGpf-00027D-6S
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:28:19 +0000
Received: from [85.158.143.99:34779] by server-2.bemta-4.messagelabs.com id
	F4/A4-12656-2308C215; Tue, 26 Feb 2013 09:28:18 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361870778!25877034!1
X-Originating-IP: [209.85.128.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5801 invoked from network); 26 Feb 2013 09:26:19 -0000
Received: from mail-ve0-f181.google.com (HELO mail-ve0-f181.google.com)
	(209.85.128.181)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:26:19 -0000
Received: by mail-ve0-f181.google.com with SMTP id d10so3114823vea.40
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 01:26:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=zH1CQJEP7T2yzG+3D7VGEP2j7MNWTJf7C1YdMKSq83c=;
	b=TTWPKd2BQXltWTaTfezpR4wr02wdm7otbeIUw5BE8wrs9uGM31PKoMtavQxP0OaM7E
	EBLgKAFbJT3ITgIeclSXRDrZLekKp9r4mEBIvGS/6k3MvoUeHFDMiSnILJk4Ust+J4b8
	HY6Z32gqXc+tVfqyCqBIaCusg/PPy0LsRpWF304SWHL6QyyMJH7WeXEtUNRq8qjv6TOZ
	/t60l3xjJOtzBPZUXS9swOdxn7lD0uL+kEpQ3f4iXDQCa4lPjRdjqirPoTmgsVOMI2qE
	Eq+ZdFeETAUWnz32l8fQNpWv3+P0bSDlSvrk7KSmx7ZQ/c33rtyKXD9UBgnpMx/AIpm7
	6xzw==
X-Received: by 10.58.28.169 with SMTP id c9mr11476608veh.5.1361870777706; Tue,
	26 Feb 2013 01:26:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.1.37 with HTTP; Tue, 26 Feb 2013 01:25:57 -0800 (PST)
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Tue, 26 Feb 2013 10:25:57 +0100
X-Google-Sender-Auth: 4qsgg_qNhP64oDK7_mL3ugf1tOk
Message-ID: <CAAxhNBAEo_JkmBo4JJqznyy0LMy-cgP9gd9gvj56Zy6MAUWLHg@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] VNCDISPLAY max value in DOMu 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="===============2573067108585664001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2573067108585664001==
Content-Type: multipart/alternative; boundary=047d7b6da95aef9a1a04d69d3f18

--047d7b6da95aef9a1a04d69d3f18
Content-Type: text/plain; charset=ISO-8859-1

Hi,

What is the maximum value for VNCDISPLAY ?

I don't understand when I put 50, it works and VNC listen on 5950 but when
I put 40, 49 or 51 that doesn't work: VNC doesn't listen.

Thanks

Erwan

--047d7b6da95aef9a1a04d69d3f18
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>What is the maximum value for=
 VNCDISPLAY ?</div><div style><br></div><div style>I don&#39;t understand w=
hen I put 50, it works and VNC listen on 5950 but when I put 40, 49 or 51 t=
hat doesn&#39;t work: VNC doesn&#39;t listen.</div>

<div style><br></div><div style>Thanks=A0</div><div style><br></div><div st=
yle>Erwan</div></div>

--047d7b6da95aef9a1a04d69d3f18--


--===============2573067108585664001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2573067108585664001==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 09:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:28: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 1UAGph-00027M-BP; Tue, 26 Feb 2013 09:28:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1UAGpf-00027D-6S
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:28:19 +0000
Received: from [85.158.143.99:34779] by server-2.bemta-4.messagelabs.com id
	F4/A4-12656-2308C215; Tue, 26 Feb 2013 09:28:18 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361870778!25877034!1
X-Originating-IP: [209.85.128.181]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5801 invoked from network); 26 Feb 2013 09:26:19 -0000
Received: from mail-ve0-f181.google.com (HELO mail-ve0-f181.google.com)
	(209.85.128.181)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:26:19 -0000
Received: by mail-ve0-f181.google.com with SMTP id d10so3114823vea.40
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 01:26:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:sender:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=zH1CQJEP7T2yzG+3D7VGEP2j7MNWTJf7C1YdMKSq83c=;
	b=TTWPKd2BQXltWTaTfezpR4wr02wdm7otbeIUw5BE8wrs9uGM31PKoMtavQxP0OaM7E
	EBLgKAFbJT3ITgIeclSXRDrZLekKp9r4mEBIvGS/6k3MvoUeHFDMiSnILJk4Ust+J4b8
	HY6Z32gqXc+tVfqyCqBIaCusg/PPy0LsRpWF304SWHL6QyyMJH7WeXEtUNRq8qjv6TOZ
	/t60l3xjJOtzBPZUXS9swOdxn7lD0uL+kEpQ3f4iXDQCa4lPjRdjqirPoTmgsVOMI2qE
	Eq+ZdFeETAUWnz32l8fQNpWv3+P0bSDlSvrk7KSmx7ZQ/c33rtyKXD9UBgnpMx/AIpm7
	6xzw==
X-Received: by 10.58.28.169 with SMTP id c9mr11476608veh.5.1361870777706; Tue,
	26 Feb 2013 01:26:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.1.37 with HTTP; Tue, 26 Feb 2013 01:25:57 -0800 (PST)
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Tue, 26 Feb 2013 10:25:57 +0100
X-Google-Sender-Auth: 4qsgg_qNhP64oDK7_mL3ugf1tOk
Message-ID: <CAAxhNBAEo_JkmBo4JJqznyy0LMy-cgP9gd9gvj56Zy6MAUWLHg@mail.gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] VNCDISPLAY max value in DOMu 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="===============2573067108585664001=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2573067108585664001==
Content-Type: multipart/alternative; boundary=047d7b6da95aef9a1a04d69d3f18

--047d7b6da95aef9a1a04d69d3f18
Content-Type: text/plain; charset=ISO-8859-1

Hi,

What is the maximum value for VNCDISPLAY ?

I don't understand when I put 50, it works and VNC listen on 5950 but when
I put 40, 49 or 51 that doesn't work: VNC doesn't listen.

Thanks

Erwan

--047d7b6da95aef9a1a04d69d3f18
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div style>What is the maximum value for=
 VNCDISPLAY ?</div><div style><br></div><div style>I don&#39;t understand w=
hen I put 50, it works and VNC listen on 5950 but when I put 40, 49 or 51 t=
hat doesn&#39;t work: VNC doesn&#39;t listen.</div>

<div style><br></div><div style>Thanks=A0</div><div style><br></div><div st=
yle>Erwan</div></div>

--047d7b6da95aef9a1a04d69d3f18--


--===============2573067108585664001==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2573067108585664001==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 09:30:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:30: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 1UAGrd-0002E2-2t; Tue, 26 Feb 2013 09:30:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>)
	id 1UAEIB-000587-Hu; Tue, 26 Feb 2013 06:45:35 +0000
Received: from [85.158.139.83:43281] by server-10.bemta-5.messagelabs.com id
	96/C1-23714-E0A5C215; Tue, 26 Feb 2013 06:45:34 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361861132!25036484!1
X-Originating-IP: [209.85.215.44]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20161 invoked from network); 26 Feb 2013 06:45:33 -0000
Received: from mail-la0-f44.google.com (HELO mail-la0-f44.google.com)
	(209.85.215.44)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 06:45:33 -0000
Received: by mail-la0-f44.google.com with SMTP id eb20so3540543lab.3
	for <multiple recipients>; Mon, 25 Feb 2013 22:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=HO+cRTB0vq8Tn2Fx/Qwxm5me0O3Ex2oqtahvvepFLvM=;
	b=LhB7wawzwvuYecekrKiGDg7WLAtw98HlyXC2mbbrMUG718jvjUfzP4Uah6z54zt/yt
	13b9zIH0kw6WVOzJJcbvK86z6TYNTLeNs+mr3nMVc25DveuhqSIARksKXRq5z4uMVnz+
	01N0kiyFsYt03giKuSIvpgq5bSkuGJNiAAejDKlVCkebFh4Mxm6b2mQlV/VM/F6QIx2u
	TIbrR/8TxiXq0ty2da9EniSZAAIlpOLl3rnxkPPHR4hb7ctsaHrX7XOJUTelgWdS8JCv
	AF5+iEN8mMYV4vlPvbVGxHFfJQnLyPwx+/4iW2uvl9Q2ZrNhe5EhahIKZc1HrQNvBBUU
	2e4Q==
X-Received: by 10.152.108.1 with SMTP id hg1mr12250088lab.12.1361861132586;
	Mon, 25 Feb 2013 22:45:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.22.198 with HTTP; Mon, 25 Feb 2013 22:44:52 -0800 (PST)
In-Reply-To: <1361817094.2109.36.camel@zion.uk.xensource.com>
References: <1361786229.2109.15.camel@zion.uk.xensource.com>
	<CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
	<1361817094.2109.36.camel@zion.uk.xensource.com>
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 25 Feb 2013 22:44:52 -0800
Message-ID: <CAGnmK4zrwUrhgKYhrbcPknzWThmY5qGbSSV4P1TwE3jJpx+9pA@mail.gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Mailman-Approved-At: Tue, 26 Feb 2013 09:30:19 +0000
Cc: xen-arm <xen-arm@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	Lars Kurth <lars.kurth@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7387318219545461808=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7387318219545461808==
Content-Type: multipart/alternative; boundary=bcaec54ee2240a96e204d69b017d

--bcaec54ee2240a96e204d69b017d
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 25, 2013 at 10:31 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> On Mon, 2013-02-25 at 18:26 +0000, Grant McWilliams wrote:
> >
> > We have two Xen Document Days one week apart?
>
>
> No. We remind people of the Xen Docsday one week before. And we also
> send another email when it is happening. :-)
>
>
> Regards
> Wei.
>
>
> Oh, so it's the same message from a week ago? I'm not sure that was very
clear by reading it.
I missed it but it's not because of this, I was really busy writing
documentation... ;-)

Grant McWilliams

--bcaec54ee2240a96e204d69b017d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 10:31 AM, Wei Liu <span dir=3D"ltr">&lt;<a href=3D"=
mailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citrix.com</a>&gt;</=
span> wrote:<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"im">On Mon, 2013-02-25 at 18:26 +0000, Grant McWilliams wrote=
:<br>
&gt;<br>
&gt; We have two Xen Document Days one week apart?<br>
<br>
<br>
</div>No. We remind people of the Xen Docsday one week before. And we also<=
br>
send another email when it is happening. :-)<br>
<br>
<br>
Regards<br>
<span class=3D"HOEnZb"><font color=3D"#888888">Wei.<br>
<br>
<br>
</font></span></blockquote></div>Oh, so it&#39;s the same message from a we=
ek ago? I&#39;m not sure that was very clear by reading it.=C2=A0<div>I mis=
sed it but it&#39;s not because of this, I was really busy writing document=
ation... ;-)<br>

<div><br></div><div>Grant McWilliams</div></div>

--bcaec54ee2240a96e204d69b017d--


--===============7387318219545461808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7387318219545461808==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 09:30:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:30: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 1UAGrd-0002E2-2t; Tue, 26 Feb 2013 09:30:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>)
	id 1UAEIB-000587-Hu; Tue, 26 Feb 2013 06:45:35 +0000
Received: from [85.158.139.83:43281] by server-10.bemta-5.messagelabs.com id
	96/C1-23714-E0A5C215; Tue, 26 Feb 2013 06:45:34 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361861132!25036484!1
X-Originating-IP: [209.85.215.44]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20161 invoked from network); 26 Feb 2013 06:45:33 -0000
Received: from mail-la0-f44.google.com (HELO mail-la0-f44.google.com)
	(209.85.215.44)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 06:45:33 -0000
Received: by mail-la0-f44.google.com with SMTP id eb20so3540543lab.3
	for <multiple recipients>; Mon, 25 Feb 2013 22:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=HO+cRTB0vq8Tn2Fx/Qwxm5me0O3Ex2oqtahvvepFLvM=;
	b=LhB7wawzwvuYecekrKiGDg7WLAtw98HlyXC2mbbrMUG718jvjUfzP4Uah6z54zt/yt
	13b9zIH0kw6WVOzJJcbvK86z6TYNTLeNs+mr3nMVc25DveuhqSIARksKXRq5z4uMVnz+
	01N0kiyFsYt03giKuSIvpgq5bSkuGJNiAAejDKlVCkebFh4Mxm6b2mQlV/VM/F6QIx2u
	TIbrR/8TxiXq0ty2da9EniSZAAIlpOLl3rnxkPPHR4hb7ctsaHrX7XOJUTelgWdS8JCv
	AF5+iEN8mMYV4vlPvbVGxHFfJQnLyPwx+/4iW2uvl9Q2ZrNhe5EhahIKZc1HrQNvBBUU
	2e4Q==
X-Received: by 10.152.108.1 with SMTP id hg1mr12250088lab.12.1361861132586;
	Mon, 25 Feb 2013 22:45:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.22.198 with HTTP; Mon, 25 Feb 2013 22:44:52 -0800 (PST)
In-Reply-To: <1361817094.2109.36.camel@zion.uk.xensource.com>
References: <1361786229.2109.15.camel@zion.uk.xensource.com>
	<CAGnmK4zYfgRS2WBEiupNk73+9AmFF9Xy1hta90ChcHqaHeXARA@mail.gmail.com>
	<1361817094.2109.36.camel@zion.uk.xensource.com>
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 25 Feb 2013 22:44:52 -0800
Message-ID: <CAGnmK4zrwUrhgKYhrbcPknzWThmY5qGbSSV4P1TwE3jJpx+9pA@mail.gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
X-Mailman-Approved-At: Tue, 26 Feb 2013 09:30:19 +0000
Cc: xen-arm <xen-arm@lists.xen.org>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	Lars Kurth <lars.kurth@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Documentation Day: Feb 25th
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7387318219545461808=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7387318219545461808==
Content-Type: multipart/alternative; boundary=bcaec54ee2240a96e204d69b017d

--bcaec54ee2240a96e204d69b017d
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 25, 2013 at 10:31 AM, Wei Liu <wei.liu2@citrix.com> wrote:

> On Mon, 2013-02-25 at 18:26 +0000, Grant McWilliams wrote:
> >
> > We have two Xen Document Days one week apart?
>
>
> No. We remind people of the Xen Docsday one week before. And we also
> send another email when it is happening. :-)
>
>
> Regards
> Wei.
>
>
> Oh, so it's the same message from a week ago? I'm not sure that was very
clear by reading it.
I missed it but it's not because of this, I was really busy writing
documentation... ;-)

Grant McWilliams

--bcaec54ee2240a96e204d69b017d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 10:31 AM, Wei Liu <span dir=3D"ltr">&lt;<a href=3D"=
mailto:wei.liu2@citrix.com" target=3D"_blank">wei.liu2@citrix.com</a>&gt;</=
span> wrote:<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"im">On Mon, 2013-02-25 at 18:26 +0000, Grant McWilliams wrote=
:<br>
&gt;<br>
&gt; We have two Xen Document Days one week apart?<br>
<br>
<br>
</div>No. We remind people of the Xen Docsday one week before. And we also<=
br>
send another email when it is happening. :-)<br>
<br>
<br>
Regards<br>
<span class=3D"HOEnZb"><font color=3D"#888888">Wei.<br>
<br>
<br>
</font></span></blockquote></div>Oh, so it&#39;s the same message from a we=
ek ago? I&#39;m not sure that was very clear by reading it.=C2=A0<div>I mis=
sed it but it&#39;s not because of this, I was really busy writing document=
ation... ;-)<br>

<div><br></div><div>Grant McWilliams</div></div>

--bcaec54ee2240a96e204d69b017d--


--===============7387318219545461808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7387318219545461808==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 09:31:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAGsE-0002Gx-HX; Tue, 26 Feb 2013 09:30:58 +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 1UAGsC-0002Gb-PH
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:30:56 +0000
Received: from [85.158.143.99:27211] by server-2.bemta-4.messagelabs.com id
	67/18-12656-FC08C215; Tue, 26 Feb 2013 09:30:55 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361870894!17763797!1
X-Originating-IP: [62.94.10.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTYyID0+IDQ3NTQ=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18281 invoked from network); 26 Feb 2013 09:28:14 -0000
Received: from mp1-smtp-2.eutelia.it (HELO smtp.eutelia.it) (62.94.10.162)
	by server-16.tower-216.messagelabs.com with SMTP;
	26 Feb 2013 09:28:14 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id D4E94CB2D8;
	Tue, 26 Feb 2013 10:28:13 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Tue, 26 Feb 2013 10:28:06 +0100
Message-Id: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2] 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Changes from v1:
- Added on description that this make a build for testing only.
- Improved add/remove of main service.

I reposted this patch after one year because I see recent
interest of some users about complete Xen debian package.
I also thinks like Stefano and Ian it's more important help to
improve official package and make here only this small
improvements.
I'll done improvements of posts of one year ago except for
remove of services that I think is useful but the main
change for good testing deb are remove of version from name
and add of conf file.
I started testing experimental debian packages of qemu and
seabios 2 months ago, I'll do the patch to integrate them
into experimental xen package if no one will do it.
So there will finally be complete xen even in official deb.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/misc/mkdeb |   30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 2e40747..fe7e1b1 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -33,7 +33,7 @@ fi
 # 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
@@ -41,15 +41,33 @@ Maintainer: Unmaintained snapshot
 Section: admin
 Priority: optional
 Installed-Size: $(du -ks deb | cut -f1)
-Description: Xen hypervisor and tools, version $version
- This package contains the Xen hypervisor and associated tools, built
- from a source tree.  It is not a fully packaged and supported Xen, just
- the output of a xen "make dist" wrapped in a .deb to make it easy to
- uninstall.
+Description: Xen testing build, version $version
+ Warning: This is a custom testing build of Xen; it is not an
+ officially supported Debian package. Please not distribute.
+ It is just the output of a xen "make dist" wrapped in a .deb
+ to make it easy to update and 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
+insserv -r xendomains &&
+insserv -r xencommons
 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
-- 
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 Tue Feb 26 09:31:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAGsE-0002Gx-HX; Tue, 26 Feb 2013 09:30:58 +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 1UAGsC-0002Gb-PH
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:30:56 +0000
Received: from [85.158.143.99:27211] by server-2.bemta-4.messagelabs.com id
	67/18-12656-FC08C215; Tue, 26 Feb 2013 09:30:55 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361870894!17763797!1
X-Originating-IP: [62.94.10.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTYyID0+IDQ3NTQ=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18281 invoked from network); 26 Feb 2013 09:28:14 -0000
Received: from mp1-smtp-2.eutelia.it (HELO smtp.eutelia.it) (62.94.10.162)
	by server-16.tower-216.messagelabs.com with SMTP;
	26 Feb 2013 09:28:14 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id D4E94CB2D8;
	Tue, 26 Feb 2013 10:28:13 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Tue, 26 Feb 2013 10:28:06 +0100
Message-Id: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v2] 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

Changes from v1:
- Added on description that this make a build for testing only.
- Improved add/remove of main service.

I reposted this patch after one year because I see recent
interest of some users about complete Xen debian package.
I also thinks like Stefano and Ian it's more important help to
improve official package and make here only this small
improvements.
I'll done improvements of posts of one year ago except for
remove of services that I think is useful but the main
change for good testing deb are remove of version from name
and add of conf file.
I started testing experimental debian packages of qemu and
seabios 2 months ago, I'll do the patch to integrate them
into experimental xen package if no one will do it.
So there will finally be complete xen even in official deb.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/misc/mkdeb |   30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 2e40747..fe7e1b1 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -33,7 +33,7 @@ fi
 # 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
@@ -41,15 +41,33 @@ Maintainer: Unmaintained snapshot
 Section: admin
 Priority: optional
 Installed-Size: $(du -ks deb | cut -f1)
-Description: Xen hypervisor and tools, version $version
- This package contains the Xen hypervisor and associated tools, built
- from a source tree.  It is not a fully packaged and supported Xen, just
- the output of a xen "make dist" wrapped in a .deb to make it easy to
- uninstall.
+Description: Xen testing build, version $version
+ Warning: This is a custom testing build of Xen; it is not an
+ officially supported Debian package. Please not distribute.
+ It is just the output of a xen "make dist" wrapped in a .deb
+ to make it easy to update and 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
+insserv -r xendomains &&
+insserv -r xencommons
 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
-- 
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 Tue Feb 26 09:34:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:34: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 1UAGvo-0002Zy-6Z; Tue, 26 Feb 2013 09:34:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1UAGvm-0002Zs-WA
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 09:34:39 +0000
Received: from [193.109.254.147:5772] by server-7.bemta-14.messagelabs.com id
	4B/FB-13581-EA18C215; Tue, 26 Feb 2013 09:34:38 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361871228!6333868!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31292 invoked from network); 26 Feb 2013 09:33:49 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:33:49 -0000
Received: by mail-vc0-f174.google.com with SMTP id n11so2324043vch.19
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 01:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:from:sender:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=AIMoY9GhkpilXxoVd/2MJktnguiUBd+oaU9E7D+q7kw=;
	b=CVqPtNegctv7jkYUVhdVwpdR2XrJXdjrYR5ziFj/HD+sO7i3motlDjqr0eS03R1KoV
	VmIj21toXW3k47K1gxofejDjS0l2DHzSdjFR8kgyzRnNPcID7tMgWHMIkolUwusNRk00
	X034lRJ79F9/riRYeG4bv2bnTq+BnkZj7+pWTvzmXIuh/y091jnWvohyEtUUmiMy/dVx
	CSOsIWapi9WBuoGa5blFZSYQ3jzSF2X9+imBR7GYGhfnyMoQZ1gV8aP2Db165XjuizRX
	ZqWNrEgDIMWOr5QUfXbenwOLMtUzb0nIfBC/5KRf3jcRoHvAmtAJZXjLHtQW8/Vpc9zO
	0VZA==
X-Received: by 10.220.149.81 with SMTP id s17mr11287864vcv.31.1361871227771;
	Tue, 26 Feb 2013 01:33:47 -0800 (PST)
Mime-Version: 1.0
Received: by 10.58.1.37 with HTTP; Tue, 26 Feb 2013 01:25:57 -0800 (PST)
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Tue, 26 Feb 2013 10:33:41 +0100
X-Google-Sender-Auth: HQ8ScAD7yVB4aAE3Ls76Gs0alQI
Message-ID: <5851129022887059365@unknownmsgid>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] VNCDISPLAY max value in DOMu 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

Hi,

What is the maximum value for VNCDISPLAY ?

I don't understand when I put 50, it works and VNC listen on 5950 but
when I put 40, 49 or 51 that doesn't work: VNC doesn't listen.

Thanks

Erwan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:34:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:34: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 1UAGvo-0002Zy-6Z; Tue, 26 Feb 2013 09:34:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erigollot52@gmail.com>) id 1UAGvm-0002Zs-WA
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 09:34:39 +0000
Received: from [193.109.254.147:5772] by server-7.bemta-14.messagelabs.com id
	4B/FB-13581-EA18C215; Tue, 26 Feb 2013 09:34:38 +0000
X-Env-Sender: erigollot52@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361871228!6333868!1
X-Originating-IP: [209.85.220.174]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31292 invoked from network); 26 Feb 2013 09:33:49 -0000
Received: from mail-vc0-f174.google.com (HELO mail-vc0-f174.google.com)
	(209.85.220.174)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:33:49 -0000
Received: by mail-vc0-f174.google.com with SMTP id n11so2324043vch.19
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 01:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:from:sender:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=AIMoY9GhkpilXxoVd/2MJktnguiUBd+oaU9E7D+q7kw=;
	b=CVqPtNegctv7jkYUVhdVwpdR2XrJXdjrYR5ziFj/HD+sO7i3motlDjqr0eS03R1KoV
	VmIj21toXW3k47K1gxofejDjS0l2DHzSdjFR8kgyzRnNPcID7tMgWHMIkolUwusNRk00
	X034lRJ79F9/riRYeG4bv2bnTq+BnkZj7+pWTvzmXIuh/y091jnWvohyEtUUmiMy/dVx
	CSOsIWapi9WBuoGa5blFZSYQ3jzSF2X9+imBR7GYGhfnyMoQZ1gV8aP2Db165XjuizRX
	ZqWNrEgDIMWOr5QUfXbenwOLMtUzb0nIfBC/5KRf3jcRoHvAmtAJZXjLHtQW8/Vpc9zO
	0VZA==
X-Received: by 10.220.149.81 with SMTP id s17mr11287864vcv.31.1361871227771;
	Tue, 26 Feb 2013 01:33:47 -0800 (PST)
Mime-Version: 1.0
Received: by 10.58.1.37 with HTTP; Tue, 26 Feb 2013 01:25:57 -0800 (PST)
From: Erwan RIGOLLOT <erwan@rigollot.me>
Date: Tue, 26 Feb 2013 10:33:41 +0100
X-Google-Sender-Auth: HQ8ScAD7yVB4aAE3Ls76Gs0alQI
Message-ID: <5851129022887059365@unknownmsgid>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] VNCDISPLAY max value in DOMu 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

Hi,

What is the maximum value for VNCDISPLAY ?

I don't understand when I put 50, it works and VNC listen on 5950 but
when I put 40, 49 or 51 that doesn't work: VNC doesn't listen.

Thanks

Erwan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:48:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:48: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 1UAH8N-0002pk-HH; Tue, 26 Feb 2013 09:47: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 1UAH8M-0002pf-Uh
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:47:39 +0000
Received: from [193.109.254.147:65234] by server-12.bemta-14.messagelabs.com
	id DF/75-32582-AB48C215; Tue, 26 Feb 2013 09:47:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361871932!8968442!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11448 invoked from network); 26 Feb 2013 09:45:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:45:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1886890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 09:45: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.297.1;
	Tue, 26 Feb 2013 09:45:31 +0000
Message-ID: <1361871929.26546.225.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Feb 2013 09:45:29 +0000
In-Reply-To: <20130225190720.GB12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> > On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > > And also put my name behind the mainternship.
> > 
> > I think you could also safely remove Jeremy these days?
> > 
> > Maybe we should have a Linux style CREDITS file to retain the names of
> > historical contributors/maintainers?
> 
> Like this:
> 
> From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 25 Feb 2013 14:04:55 -0500
> Subject: [PATCH] CREDITS: First checkin.
> 
> Adding Jeremy and moving him from the MAINTAINERS file.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  CREDITS     | 16 ++++++++++++++++
>  MAINTAINERS |  1 -
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 CREDITS
> 
> diff --git a/CREDITS b/CREDITS
> new file mode 100644
> index 0000000..eaf05bf
> --- /dev/null
> +++ b/CREDITS
> @@ -0,0 +1,16 @@
> +    This is at least a partial credits-file of people that have
> +    contributed to the Xen project.  It is sorted by name and
> +    formatted to allow easy grepping and beautification by
> +    scripts.  The fields are: name (N), email (E), web-address
> +    (W), PGP key ID and fingerprint (P), description (D), and
> +    snail-mail address (S).
> +    Thanks,
> +
> +            Xen team
> +----------
> +
> +N: Jeremy Fitzhardinge
> +E: jeremy@goop.org
> +W: http://www.goop.org/~jeremy
> +P: 1B40B6D0
> +D: Linux pvops
> 
> I didn't put his physical address b/c I don't know if he would like
> it there?

I don't think I would want mine in there, seems like a bit on an
anachronism anyhow ;-).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:48:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:48: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 1UAH8N-0002pk-HH; Tue, 26 Feb 2013 09:47: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 1UAH8M-0002pf-Uh
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:47:39 +0000
Received: from [193.109.254.147:65234] by server-12.bemta-14.messagelabs.com
	id DF/75-32582-AB48C215; Tue, 26 Feb 2013 09:47:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361871932!8968442!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11448 invoked from network); 26 Feb 2013 09:45:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 09:45:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1886890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 09:45: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.297.1;
	Tue, 26 Feb 2013 09:45:31 +0000
Message-ID: <1361871929.26546.225.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Feb 2013 09:45:29 +0000
In-Reply-To: <20130225190720.GB12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> > On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > > And also put my name behind the mainternship.
> > 
> > I think you could also safely remove Jeremy these days?
> > 
> > Maybe we should have a Linux style CREDITS file to retain the names of
> > historical contributors/maintainers?
> 
> Like this:
> 
> From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 25 Feb 2013 14:04:55 -0500
> Subject: [PATCH] CREDITS: First checkin.
> 
> Adding Jeremy and moving him from the MAINTAINERS file.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  CREDITS     | 16 ++++++++++++++++
>  MAINTAINERS |  1 -
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 CREDITS
> 
> diff --git a/CREDITS b/CREDITS
> new file mode 100644
> index 0000000..eaf05bf
> --- /dev/null
> +++ b/CREDITS
> @@ -0,0 +1,16 @@
> +    This is at least a partial credits-file of people that have
> +    contributed to the Xen project.  It is sorted by name and
> +    formatted to allow easy grepping and beautification by
> +    scripts.  The fields are: name (N), email (E), web-address
> +    (W), PGP key ID and fingerprint (P), description (D), and
> +    snail-mail address (S).
> +    Thanks,
> +
> +            Xen team
> +----------
> +
> +N: Jeremy Fitzhardinge
> +E: jeremy@goop.org
> +W: http://www.goop.org/~jeremy
> +P: 1B40B6D0
> +D: Linux pvops
> 
> I didn't put his physical address b/c I don't know if he would like
> it there?

I don't think I would want mine in there, seems like a bit on an
anachronism anyhow ;-).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:52:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:52: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 1UAHDC-0002z6-7t; Tue, 26 Feb 2013 09:52:38 +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 1UAHDA-0002z0-VO
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 09:52:37 +0000
Received: from [85.158.143.99:14230] by server-3.bemta-4.messagelabs.com id
	50/71-02186-4E58C215; Tue, 26 Feb 2013 09:52:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361872355!28744861!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21552 invoked from network); 26 Feb 2013 09:52:35 -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; 26 Feb 2013 09:52:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAHD8-000OSn-Nf; Tue, 26 Feb 2013 09:52:34 +0000
Date: Tue, 26 Feb 2013 09:52:34 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226095234.GA93966@ocelot.phlegethon.org>
References: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
	<512C817502000078000C0FC8@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512C817502000078000C0FC8@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Xinxin Jin <xinxinjin89@gmail.com>, Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The different between map_pages_to_xen and
	mfn_to_virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:33 +0000 on 26 Feb (1361867621), Jan Beulich wrote:
> >>> On 25.02.13 at 21:41, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> > I have some confusion about the purpose of the two functions.
> > map_pages_to_xen is to map machine page range in Xen virtual address space.
> > mfn_to_virt() is to convert between machine frame number and xen-heap
> > virtual address. So what is the difference? When I need to map some machine
> > pages to Xen space, which function should I use? Thanks,
> 
> You describe the difference yourself - one function establishes a
> mapping, while the other only does a translation assuming that
> the 1:1 mapping for the given MFN was already established (at
> boot time, or during memory hotplug processing).

Also, if the pages you're trying to map are ordinary RAM, you should use
map_domain_page() to map them and unmap_domain_page() when you're done.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:52:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09:52: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 1UAHDC-0002z6-7t; Tue, 26 Feb 2013 09:52:38 +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 1UAHDA-0002z0-VO
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 09:52:37 +0000
Received: from [85.158.143.99:14230] by server-3.bemta-4.messagelabs.com id
	50/71-02186-4E58C215; Tue, 26 Feb 2013 09:52:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361872355!28744861!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21552 invoked from network); 26 Feb 2013 09:52:35 -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; 26 Feb 2013 09:52:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAHD8-000OSn-Nf; Tue, 26 Feb 2013 09:52:34 +0000
Date: Tue, 26 Feb 2013 09:52:34 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226095234.GA93966@ocelot.phlegethon.org>
References: <CAJJWZcwDLc6KLqBDxxRERPNBaydKpoST5ngfmp7gGU3MjgBPuw@mail.gmail.com>
	<512C817502000078000C0FC8@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512C817502000078000C0FC8@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Xinxin Jin <xinxinjin89@gmail.com>, Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The different between map_pages_to_xen and
	mfn_to_virt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:33 +0000 on 26 Feb (1361867621), Jan Beulich wrote:
> >>> On 25.02.13 at 21:41, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> > I have some confusion about the purpose of the two functions.
> > map_pages_to_xen is to map machine page range in Xen virtual address space.
> > mfn_to_virt() is to convert between machine frame number and xen-heap
> > virtual address. So what is the difference? When I need to map some machine
> > pages to Xen space, which function should I use? Thanks,
> 
> You describe the difference yourself - one function establishes a
> mapping, while the other only does a translation assuming that
> the 1:1 mapping for the given MFN was already established (at
> boot time, or during memory hotplug processing).

Also, if the pages you're trying to map are ordinary RAM, you should use
map_domain_page() to map them and unmap_domain_page() when you're done.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:55:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAHFJ-00037A-P2; Tue, 26 Feb 2013 09:54:49 +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 1UAHFI-000372-Ef
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:54:48 +0000
Received: from [85.158.139.83:65219] by server-6.bemta-5.messagelabs.com id
	7F/9A-21466-7668C215; Tue, 26 Feb 2013 09:54:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361872486!23813835!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23328 invoked from network); 26 Feb 2013 09:54:47 -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; 26 Feb 2013 09:54:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 09:54:07 +0000
Message-Id: <512C944A02000078000C1027@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 09:54:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
In-Reply-To: <1361869609.11431.26.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: IanJackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 26.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> This patch fixes the current build breakage, anyone want to ack or nack?

Looks almost fine to me, but probably one of the other ARM guys
would want to ack this anyway.

>> --- a/tools/include/xen-foreign/mkheader.py
>> +++ b/tools/include/xen-foreign/mkheader.py
>> @@ -20,15 +20,18 @@ footer = {};
>>  inttypes["arm32"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>> -    "xen_pfn_t"     : "uint64_t",
>> -    "xen_ulong_t"   : "uint64_t",
>> +    "xen_pfn_t"     : "__align8__ uint64_t",
>> +    "xen_ulong_t"   : "__align8__ uint64_t",
>> +    "uint64_t"      : "__align8__ uint64_t",
>>  };
>>  header["arm32"] = """
>>  #define __arm___ARM32 1
>>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
>> +# define __align8__ __attribute__((aligned (8)))

Using __aligned__ here would probably be a tiny bit more safe (I
do realize that x86-64 already uses the same construct you use).

>>  #else
>>  # define __DECL_REG(n64, n32) uint64_t n64
>> +# define FIXME

Did you mean

# define __align8__ FIXME

(also further down)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:55:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAHFJ-00037A-P2; Tue, 26 Feb 2013 09:54:49 +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 1UAHFI-000372-Ef
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:54:48 +0000
Received: from [85.158.139.83:65219] by server-6.bemta-5.messagelabs.com id
	7F/9A-21466-7668C215; Tue, 26 Feb 2013 09:54:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361872486!23813835!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23328 invoked from network); 26 Feb 2013 09:54:47 -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; 26 Feb 2013 09:54:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 09:54:07 +0000
Message-Id: <512C944A02000078000C1027@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 09:54:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
In-Reply-To: <1361869609.11431.26.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: IanJackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 26.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> This patch fixes the current build breakage, anyone want to ack or nack?

Looks almost fine to me, but probably one of the other ARM guys
would want to ack this anyway.

>> --- a/tools/include/xen-foreign/mkheader.py
>> +++ b/tools/include/xen-foreign/mkheader.py
>> @@ -20,15 +20,18 @@ footer = {};
>>  inttypes["arm32"] = {
>>      "unsigned long" : "uint32_t",
>>      "long"          : "uint32_t",
>> -    "xen_pfn_t"     : "uint64_t",
>> -    "xen_ulong_t"   : "uint64_t",
>> +    "xen_pfn_t"     : "__align8__ uint64_t",
>> +    "xen_ulong_t"   : "__align8__ uint64_t",
>> +    "uint64_t"      : "__align8__ uint64_t",
>>  };
>>  header["arm32"] = """
>>  #define __arm___ARM32 1
>>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
>> +# define __align8__ __attribute__((aligned (8)))

Using __aligned__ here would probably be a tiny bit more safe (I
do realize that x86-64 already uses the same construct you use).

>>  #else
>>  # define __DECL_REG(n64, n32) uint64_t n64
>> +# define FIXME

Did you mean

# define __align8__ FIXME

(also further down)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:58:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAHIP-0003Gn-Cl; Tue, 26 Feb 2013 09:58: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 1UAHIN-0003Gg-Gj
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:57:59 +0000
Received: from [85.158.138.51:12787] by server-6.bemta-3.messagelabs.com id
	B1/B2-29959-6278C215; Tue, 26 Feb 2013 09:57:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361872678!23806643!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODQ4NjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODQ4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15488 invoked from network); 26 Feb 2013 09:57:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with SMTP;
	26 Feb 2013 09:57:58 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDXwY/Qymc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-073-142.pools.arcor-ip.net [84.57.73.142])
	by smtp.strato.de (jorabe mo22) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R041f9p1Q9PEdi ;
	Tue, 26 Feb 2013 10:57:58 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 2C1FB1884C; Tue, 26 Feb 2013 10:57:57 +0100 (CET)
Date: Tue, 26 Feb 2013 10:57:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: sahilsuneja <sahilsuneja@gmail.com>
Message-ID: <20130226095756.GA26163@aepfle.de>
References: <1361840672591-5714431.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361840672591-5714431.post@n5.nabble.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Issues with Xenpaging in Xen-4.2.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 Mon, Feb 25, sahilsuneja wrote:

> I know Xenpaging is still at an experimental stage, but I still wanted to
> test it out. Sadly, I could not get it to work reliably.
> 
> I have an AMD RVI enabled linux 3.2 host, and I am using linux 2.6.35-22 HVM

The pvops kernel may not have all required changes to run xenpaging in
dom0. Maybe 3.8 already has these changes. If in doubt try the
SLES/openSuSE kernels as dom0, their backend drivers can deal with paged
granttable entries.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 09:58:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 09: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 1UAHIP-0003Gn-Cl; Tue, 26 Feb 2013 09:58: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 1UAHIN-0003Gg-Gj
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 09:57:59 +0000
Received: from [85.158.138.51:12787] by server-6.bemta-3.messagelabs.com id
	B1/B2-29959-6278C215; Tue, 26 Feb 2013 09:57:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361872678!23806643!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODQ4NjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA1ODQ4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15488 invoked from network); 26 Feb 2013 09:57:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with SMTP;
	26 Feb 2013 09:57:58 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDXwY/Qymc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-073-142.pools.arcor-ip.net [84.57.73.142])
	by smtp.strato.de (jorabe mo22) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R041f9p1Q9PEdi ;
	Tue, 26 Feb 2013 10:57:58 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 2C1FB1884C; Tue, 26 Feb 2013 10:57:57 +0100 (CET)
Date: Tue, 26 Feb 2013 10:57:56 +0100
From: Olaf Hering <olaf@aepfle.de>
To: sahilsuneja <sahilsuneja@gmail.com>
Message-ID: <20130226095756.GA26163@aepfle.de>
References: <1361840672591-5714431.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361840672591-5714431.post@n5.nabble.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Issues with Xenpaging in Xen-4.2.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 Mon, Feb 25, sahilsuneja wrote:

> I know Xenpaging is still at an experimental stage, but I still wanted to
> test it out. Sadly, I could not get it to work reliably.
> 
> I have an AMD RVI enabled linux 3.2 host, and I am using linux 2.6.35-22 HVM

The pvops kernel may not have all required changes to run xenpaging in
dom0. Maybe 3.8 already has these changes. If in doubt try the
SLES/openSuSE kernels as dom0, their backend drivers can deal with paged
granttable entries.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:08:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:08: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 1UAHSP-0003ZY-IN; Tue, 26 Feb 2013 10:08:21 +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 1UAHSO-0003ZT-71
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:08:20 +0000
Received: from [85.158.139.83:47590] by server-5.bemta-5.messagelabs.com id
	4A/B0-02762-3998C215; Tue, 26 Feb 2013 10:08:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361873297!28967409!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25627 invoked from network); 26 Feb 2013 10:08:18 -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; 26 Feb 2013 10:08:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 10:08:17 +0000
Message-Id: <512C979E02000078000C105F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 10:08:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "DuanZhenzhong" <zhenzhong.duan@oracle.com>
References: <512C78D2.8030903@oracle.com>
In-Reply-To: <512C78D2.8030903@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix 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

>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
> (fee00000 -> fee02000)
> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
> (00004059 -> 00004071)

If you look at the code issuing this message, the situation is
pretty clear (and I think it as described already in the past,
albeit I have no link at hand): qemu lacks proper emulation of
the mask bit. pci_msix_write() looks at the physical one, yet
when the guest sets the virtual mask bit, nothing is being
done at all to make the hypervisor also mask the physical
entry:

    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
            xen_pt_msix_update_one(s, entry_nr);
        }
    }

There's probably quite a bit of code to be written to make this
work.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:08:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:08: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 1UAHSP-0003ZY-IN; Tue, 26 Feb 2013 10:08:21 +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 1UAHSO-0003ZT-71
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:08:20 +0000
Received: from [85.158.139.83:47590] by server-5.bemta-5.messagelabs.com id
	4A/B0-02762-3998C215; Tue, 26 Feb 2013 10:08:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361873297!28967409!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25627 invoked from network); 26 Feb 2013 10:08:18 -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; 26 Feb 2013 10:08:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 10:08:17 +0000
Message-Id: <512C979E02000078000C105F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 10:08:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "DuanZhenzhong" <zhenzhong.duan@oracle.com>
References: <512C78D2.8030903@oracle.com>
In-Reply-To: <512C78D2.8030903@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix 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

>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
> (fee00000 -> fee02000)
> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled 
> (00004059 -> 00004071)

If you look at the code issuing this message, the situation is
pretty clear (and I think it as described already in the past,
albeit I have no link at hand): qemu lacks proper emulation of
the mask bit. pci_msix_write() looks at the physical one, yet
when the guest sets the virtual mask bit, nothing is being
done at all to make the hypervisor also mask the physical
entry:

    if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
        if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
            xen_pt_msix_update_one(s, entry_nr);
        }
    }

There's probably quite a bit of code to be written to make this
work.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:12:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:12: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 1UAHWR-0003k1-7r; Tue, 26 Feb 2013 10:12:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAHWO-0003jt-7I
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:12:30 +0000
Received: from [85.158.139.211:38834] by server-9.bemta-5.messagelabs.com id
	45/40-08547-B8A8C215; Tue, 26 Feb 2013 10:12:27 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361873491!18650813!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23422 invoked from network); 26 Feb 2013 10:11:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-206.messagelabs.com with SMTP;
	26 Feb 2013 10:11:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 24DD4C56198;
	Tue, 26 Feb 2013 10:11:19 +0000 (GMT)
Date: Tue, 26 Feb 2013 10:11:18 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <55967B6AC9B16C9D2393DD0E@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302260816460.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
	<alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
	<65A5A13AA7E2781D12DC1DA0@Ximines.local>
	<alpine.DEB.2.02.1302260816460.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 26 February 2013 08:18:41 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> Could you "fix" the init scripts in the main debian target?
> If we overlook the lack of header files, you'll have what you want and
> we won't have to maintain two separate deb build targets.

Sure I can fix them. That doesn't however get me what I use the
target for (happy to do it anyway though).

The 'mini' in 'minideb' was precisely so it didn't install
everything. In my case I'm installing into a ramdisk so space
matters. How about having flags set on the target which would allow
different things in (xend / no xend, dev headers / no dev headers)?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:12:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:12: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 1UAHWR-0003k1-7r; Tue, 26 Feb 2013 10:12:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAHWO-0003jt-7I
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:12:30 +0000
Received: from [85.158.139.211:38834] by server-9.bemta-5.messagelabs.com id
	45/40-08547-B8A8C215; Tue, 26 Feb 2013 10:12:27 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361873491!18650813!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23422 invoked from network); 26 Feb 2013 10:11:31 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-12.tower-206.messagelabs.com with SMTP;
	26 Feb 2013 10:11:31 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 24DD4C56198;
	Tue, 26 Feb 2013 10:11:19 +0000 (GMT)
Date: Tue, 26 Feb 2013 10:11:18 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <55967B6AC9B16C9D2393DD0E@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302260816460.5360@kaball.uk.xensource.com>
References: <73B7FEB65DB959FF75707D5A@nimrod.local>
	<20130222174010.GC40494@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302221756290.22997@kaball.uk.xensource.com>
	<044C88EAD95AA5B1839F9185@nimrod.local>
	<CAGU+auuw0QJ3dwLUBTOFxxJ+UCTaL7uZQO9hLCod7AVR5mhccw@mail.gmail.com>
	<alpine.DEB.2.02.1302251241350.5360@kaball.uk.xensource.com>
	<20130225131248.GA78606@ocelot.phlegethon.org>
	<676025980A510BB081BC128B@Ximines.local>
	<alpine.DEB.2.02.1302252012270.5360@kaball.uk.xensource.com>
	<65A5A13AA7E2781D12DC1DA0@Ximines.local>
	<alpine.DEB.2.02.1302260816460.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Xen4.2 debian packaging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 26 February 2013 08:18:41 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> Could you "fix" the init scripts in the main debian target?
> If we overlook the lack of header files, you'll have what you want and
> we won't have to maintain two separate deb build targets.

Sure I can fix them. That doesn't however get me what I use the
target for (happy to do it anyway though).

The 'mini' in 'minideb' was precisely so it didn't install
everything. In my case I'm installing into a ramdisk so space
matters. How about having flags set on the target which would allow
different things in (xend / no xend, dev headers / no dev headers)?

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:13:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UAHX0-0003nD-Qx; Tue, 26 Feb 2013 10:13: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 1UAHWy-0003mv-Px
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 10:13:05 +0000
Received: from [85.158.139.83:40670] by server-8.bemta-5.messagelabs.com id
	33/6E-05790-FAA8C215; Tue, 26 Feb 2013 10:13:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361873567!25074254!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28291 invoked from network); 26 Feb 2013 10:12:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 10:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1888785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 10: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.297.1;
	Tue, 26 Feb 2013 10:12:47 +0000
Message-ID: <1361873566.26546.249.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Feb 2013 10:12:46 +0000
In-Reply-To: <512C944A02000078000C1027@nat28.tlf.novell.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
	<512C944A02000078000C1027@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 Tue, 2013-02-26 at 09:54 +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > This patch fixes the current build breakage, anyone want to ack or nack?
> 
> Looks almost fine to me, but probably one of the other ARM guys
> would want to ack this anyway.

Actually at this point I would rather just get the build fixed, since it
is blocking quite a large staging push.

I'll commit in about half an hour unless someone objects.

> >> --- a/tools/include/xen-foreign/mkheader.py
> >> +++ b/tools/include/xen-foreign/mkheader.py
> >> @@ -20,15 +20,18 @@ footer = {};
> >>  inttypes["arm32"] = {
> >>      "unsigned long" : "uint32_t",
> >>      "long"          : "uint32_t",
> >> -    "xen_pfn_t"     : "uint64_t",
> >> -    "xen_ulong_t"   : "uint64_t",
> >> +    "xen_pfn_t"     : "__align8__ uint64_t",
> >> +    "xen_ulong_t"   : "__align8__ uint64_t",
> >> +    "uint64_t"      : "__align8__ uint64_t",
> >>  };
> >>  header["arm32"] = """
> >>  #define __arm___ARM32 1
> >>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> >>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
> >> +# define __align8__ __attribute__((aligned (8)))
> 
> Using __aligned__ here would probably be a tiny bit more safe (I
> do realize that x86-64 already uses the same construct you use).

Yes I copied x86-64 here deliberately.

> >>  #else
> >>  # define __DECL_REG(n64, n32) uint64_t n64
> >> +# define FIXME
> 
> Did you mean
> 
> # define __align8__ FIXME
> 
> (also further down)?

Oh yes, silly me.

Ian.

8<--------------------------------

>From 8a2ab328c96bd71855595633b14fb7adc5cc0cc9 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 25 Feb 2013 09:11:04 +0000
Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm

When building the foreign headers on x86_32 we use '#pragma pack(4)' and
therefore need to explicitly align types which should be aligned to 8-byte
boundaries.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Fix #define FIXME -> #define __align8__ FIXME
---
 tools/include/xen-foreign/mkheader.py |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 8a784d3..b19292f 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -20,15 +20,18 @@ footer = {};
 inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define __align8__ FIXME
 #endif
 """;
 footer["arm32"] = """
@@ -38,15 +41,18 @@ footer["arm32"] = """
 inttypes["arm64"] = {
     "unsigned long" : "__danger_unsigned_long_on_arm64",
     "long"          : "__danger_long_on_arm64",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define __align8__ FIXME
 #endif
 """;
 footer["arm64"] = """
-- 
1.7.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 Feb 26 10:13:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UAHX0-0003nD-Qx; Tue, 26 Feb 2013 10:13: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 1UAHWy-0003mv-Px
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 10:13:05 +0000
Received: from [85.158.139.83:40670] by server-8.bemta-5.messagelabs.com id
	33/6E-05790-FAA8C215; Tue, 26 Feb 2013 10:13:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361873567!25074254!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28291 invoked from network); 26 Feb 2013 10:12:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 10:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1888785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 10: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.297.1;
	Tue, 26 Feb 2013 10:12:47 +0000
Message-ID: <1361873566.26546.249.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Feb 2013 10:12:46 +0000
In-Reply-To: <512C944A02000078000C1027@nat28.tlf.novell.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
	<512C944A02000078000C1027@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 Tue, 2013-02-26 at 09:54 +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > This patch fixes the current build breakage, anyone want to ack or nack?
> 
> Looks almost fine to me, but probably one of the other ARM guys
> would want to ack this anyway.

Actually at this point I would rather just get the build fixed, since it
is blocking quite a large staging push.

I'll commit in about half an hour unless someone objects.

> >> --- a/tools/include/xen-foreign/mkheader.py
> >> +++ b/tools/include/xen-foreign/mkheader.py
> >> @@ -20,15 +20,18 @@ footer = {};
> >>  inttypes["arm32"] = {
> >>      "unsigned long" : "uint32_t",
> >>      "long"          : "uint32_t",
> >> -    "xen_pfn_t"     : "uint64_t",
> >> -    "xen_ulong_t"   : "uint64_t",
> >> +    "xen_pfn_t"     : "__align8__ uint64_t",
> >> +    "xen_ulong_t"   : "__align8__ uint64_t",
> >> +    "uint64_t"      : "__align8__ uint64_t",
> >>  };
> >>  header["arm32"] = """
> >>  #define __arm___ARM32 1
> >>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> >>  # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
> >> +# define __align8__ __attribute__((aligned (8)))
> 
> Using __aligned__ here would probably be a tiny bit more safe (I
> do realize that x86-64 already uses the same construct you use).

Yes I copied x86-64 here deliberately.

> >>  #else
> >>  # define __DECL_REG(n64, n32) uint64_t n64
> >> +# define FIXME
> 
> Did you mean
> 
> # define __align8__ FIXME
> 
> (also further down)?

Oh yes, silly me.

Ian.

8<--------------------------------

>From 8a2ab328c96bd71855595633b14fb7adc5cc0cc9 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Mon, 25 Feb 2013 09:11:04 +0000
Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm

When building the foreign headers on x86_32 we use '#pragma pack(4)' and
therefore need to explicitly align types which should be aligned to 8-byte
boundaries.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Fix #define FIXME -> #define __align8__ FIXME
---
 tools/include/xen-foreign/mkheader.py |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 8a784d3..b19292f 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -20,15 +20,18 @@ footer = {};
 inttypes["arm32"] = {
     "unsigned long" : "uint32_t",
     "long"          : "uint32_t",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm32"] = """
 #define __arm___ARM32 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define __align8__ FIXME
 #endif
 """;
 footer["arm32"] = """
@@ -38,15 +41,18 @@ footer["arm32"] = """
 inttypes["arm64"] = {
     "unsigned long" : "__danger_unsigned_long_on_arm64",
     "long"          : "__danger_long_on_arm64",
-    "xen_pfn_t"     : "uint64_t",
-    "xen_ulong_t"   : "uint64_t",
+    "xen_pfn_t"     : "__align8__ uint64_t",
+    "xen_ulong_t"   : "__align8__ uint64_t",
+    "uint64_t"      : "__align8__ uint64_t",
 };
 header["arm64"] = """
 #define __aarch64___ARM64 1
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; }
+# define __align8__ __attribute__((aligned (8)))
 #else
 # define __DECL_REG(n64, n32) uint64_t n64
+# define __align8__ FIXME
 #endif
 """;
 footer["arm64"] = """
-- 
1.7.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 Feb 26 10:20:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:20: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 1UAHdt-00045T-N0; Tue, 26 Feb 2013 10:20: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 1UAHds-00045O-7U
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:20:12 +0000
Received: from [85.158.139.83:58067] by server-5.bemta-5.messagelabs.com id
	04/68-02762-B5C8C215; Tue, 26 Feb 2013 10:20:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361874009!28970518!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3828 invoked from network); 26 Feb 2013 10:20:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 10:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1889175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 10:20: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.297.1;
	Tue, 26 Feb 2013 10:20:09 +0000
Message-ID: <1361874007.26546.255.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 26 Feb 2013 10:20:07 +0000
In-Reply-To: <1701027415.20130226000019@eikelenboom.it>
References: <1208255021.20130225232853@eikelenboom.it>
	<1701027415.20130226000019@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
 after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
> Hello Sander,

Talking to yourself is a sign of something or other I think ;-)

> Monday, February 25, 2013, 11:28:53 PM, you wrote:
> 
> > Date: Mon, 25 Feb 2013 23:28:53 +0100
> > From: Sander Eikelenboom <linux@eikelenboom.it>
> > Organization: Eikelenboom IT services
> > X-Priority: 3 (Normal)
> > Message-ID: <1208255021.20130225232853@eikelenboom.it>
> > To: xen-devel <xen-devel@lists.xen.org>
> > Subject: Changeset / commit id not incorporated in build after switch to git
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> 
> > Hi All,
> 
> > After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)
> 
> > Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.
> 
> > So what would be wise:
> >    - just replace the changeset with the git commit sha-1 hash (always)
> >    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
> >    - make a separate "commit" entry besides the changeset and leave one undefined
> 
> > xen/Makefile currently has:
> 
> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> > include/xen/compile.h: include/xen/compile.h.in .banner
> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
> >             -e 's/@@hostname@@/$(shell hostname)/g' \
> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
> >             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> >             < include/xen/compile.h.in > $@.new
> >         @grep \" .banner >> $@.new
> >         @grep -v \" .banner
> >         @mv -f $@.new $@
> 
> > --
> > Sander
> 
> 
> 
> Perhaps use about the same as linux has in scripts/setlocalversion ?

This is what I was going to suggest. Actually, I had it in mind we
already did something like!

Anyway, I think including whatever information the VCS we are building
from supplied is the right answer and the way Linux does it seems useful
and appropriate (e.g. using the tag name, appending -dirty etc).

If we can also extend that to do something sensible in the tarball case
then even better!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:20:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:20: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 1UAHdt-00045T-N0; Tue, 26 Feb 2013 10:20: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 1UAHds-00045O-7U
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:20:12 +0000
Received: from [85.158.139.83:58067] by server-5.bemta-5.messagelabs.com id
	04/68-02762-B5C8C215; Tue, 26 Feb 2013 10:20:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361874009!28970518!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3828 invoked from network); 26 Feb 2013 10:20:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 10:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1889175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 10:20: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.297.1;
	Tue, 26 Feb 2013 10:20:09 +0000
Message-ID: <1361874007.26546.255.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 26 Feb 2013 10:20:07 +0000
In-Reply-To: <1701027415.20130226000019@eikelenboom.it>
References: <1208255021.20130225232853@eikelenboom.it>
	<1701027415.20130226000019@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
 after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
> Hello Sander,

Talking to yourself is a sign of something or other I think ;-)

> Monday, February 25, 2013, 11:28:53 PM, you wrote:
> 
> > Date: Mon, 25 Feb 2013 23:28:53 +0100
> > From: Sander Eikelenboom <linux@eikelenboom.it>
> > Organization: Eikelenboom IT services
> > X-Priority: 3 (Normal)
> > Message-ID: <1208255021.20130225232853@eikelenboom.it>
> > To: xen-devel <xen-devel@lists.xen.org>
> > Subject: Changeset / commit id not incorporated in build after switch to git
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> 
> > Hi All,
> 
> > After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)
> 
> > Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.
> 
> > So what would be wise:
> >    - just replace the changeset with the git commit sha-1 hash (always)
> >    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
> >    - make a separate "commit" entry besides the changeset and leave one undefined
> 
> > xen/Makefile currently has:
> 
> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> > include/xen/compile.h: include/xen/compile.h.in .banner
> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
> >             -e 's/@@hostname@@/$(shell hostname)/g' \
> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
> >             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> >             < include/xen/compile.h.in > $@.new
> >         @grep \" .banner >> $@.new
> >         @grep -v \" .banner
> >         @mv -f $@.new $@
> 
> > --
> > Sander
> 
> 
> 
> Perhaps use about the same as linux has in scripts/setlocalversion ?

This is what I was going to suggest. Actually, I had it in mind we
already did something like!

Anyway, I think including whatever information the VCS we are building
from supplied is the right answer and the way Linux does it seems useful
and appropriate (e.g. using the tag name, appending -dirty etc).

If we can also extend that to do something sensible in the tarball case
then even better!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:31: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 1UAHos-0004Uz-Fs; Tue, 26 Feb 2013 10:31:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAHoq-0004Ur-R8
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:31:33 +0000
Received: from [85.158.137.99:59457] by server-10.bemta-3.messagelabs.com id
	A6/F1-10609-FFE8C215; Tue, 26 Feb 2013 10:31:27 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361874665!12489484!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31726 invoked from network); 26 Feb 2013 10:31:05 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 10:31:05 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:52243 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 1UAHmO-0005tM-Ty; Tue, 26 Feb 2013 11:29:01 +0100
Date: Tue, 26 Feb 2013 11:31:01 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1855874747.20130226113101@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361874007.26546.255.camel@zakaz.uk.xensource.com>
References: <1208255021.20130225232853@eikelenboom.it>
	<1701027415.20130226000019@eikelenboom.it>
	<1361874007.26546.255.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
	after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, February 26, 2013, 11:20:07 AM, you wrote:

> On Mon, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
>> Hello Sander,

> Talking to yourself is a sign of something or other I think ;-)

primarily hitting the send button a bit before my thoughts actually ended :-p (at least i hope)


>> Monday, February 25, 2013, 11:28:53 PM, you wrote:
>> 
>> > Date: Mon, 25 Feb 2013 23:28:53 +0100
>> > From: Sander Eikelenboom <linux@eikelenboom.it>
>> > Organization: Eikelenboom IT services
>> > X-Priority: 3 (Normal)
>> > Message-ID: <1208255021.20130225232853@eikelenboom.it>
>> > To: xen-devel <xen-devel@lists.xen.org>
>> > Subject: Changeset / commit id not incorporated in build after switch to git
>> > MIME-Version: 1.0
>> > Content-Type: text/plain; charset=us-ascii
>> > Content-Transfer-Encoding: 7bit
>> 
>> > Hi All,
>> 
>> > After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
>> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)
>> 
>> > Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.
>> 
>> > So what would be wise:
>> >    - just replace the changeset with the git commit sha-1 hash (always)
>> >    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
>> >    - make a separate "commit" entry besides the changeset and leave one undefined
>> 
>> > xen/Makefile currently has:
>> 
>> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
>> > include/xen/compile.h: include/xen/compile.h.in .banner
>> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
>> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
>> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
>> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
>> >             -e 's/@@hostname@@/$(shell hostname)/g' \
>> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
>> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
>> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
>> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
>> >             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
>> >             < include/xen/compile.h.in > $@.new
>> >         @grep \" .banner >> $@.new
>> >         @grep -v \" .banner
>> >         @mv -f $@.new $@
>> 
>> > --
>> > Sander
>> 
>> 
>> 
>> Perhaps use about the same as linux has in scripts/setlocalversion ?

> This is what I was going to suggest. Actually, I had it in mind we
> already did something like!

> Anyway, I think including whatever information the VCS we are building
> from supplied is the right answer and the way Linux does it seems useful
> and appropriate (e.g. using the tag name, appending -dirty etc).

> If we can also extend that to do something sensible in the tarball case
> then even better!

Not much info to get form a extracted tarball i'm afraid ?
Or one should include some extra versioning in the tarball itself and in that case you don't know if its "dirty" or not, just a "based on tarball with changeset/commit"

Since in that case it will describe something more/else than a mecurial changeset,
question is should the name "changeset" also be replaced by some more general naming ?



> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:31:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10:31: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 1UAHos-0004Uz-Fs; Tue, 26 Feb 2013 10:31:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAHoq-0004Ur-R8
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:31:33 +0000
Received: from [85.158.137.99:59457] by server-10.bemta-3.messagelabs.com id
	A6/F1-10609-FFE8C215; Tue, 26 Feb 2013 10:31:27 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361874665!12489484!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31726 invoked from network); 26 Feb 2013 10:31:05 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 10:31:05 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:52243 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 1UAHmO-0005tM-Ty; Tue, 26 Feb 2013 11:29:01 +0100
Date: Tue, 26 Feb 2013 11:31:01 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1855874747.20130226113101@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361874007.26546.255.camel@zakaz.uk.xensource.com>
References: <1208255021.20130225232853@eikelenboom.it>
	<1701027415.20130226000019@eikelenboom.it>
	<1361874007.26546.255.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
	after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, February 26, 2013, 11:20:07 AM, you wrote:

> On Mon, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
>> Hello Sander,

> Talking to yourself is a sign of something or other I think ;-)

primarily hitting the send button a bit before my thoughts actually ended :-p (at least i hope)


>> Monday, February 25, 2013, 11:28:53 PM, you wrote:
>> 
>> > Date: Mon, 25 Feb 2013 23:28:53 +0100
>> > From: Sander Eikelenboom <linux@eikelenboom.it>
>> > Organization: Eikelenboom IT services
>> > X-Priority: 3 (Normal)
>> > Message-ID: <1208255021.20130225232853@eikelenboom.it>
>> > To: xen-devel <xen-devel@lists.xen.org>
>> > Subject: Changeset / commit id not incorporated in build after switch to git
>> > MIME-Version: 1.0
>> > Content-Type: text/plain; charset=us-ascii
>> > Content-Transfer-Encoding: 7bit
>> 
>> > Hi All,
>> 
>> > After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
>> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)
>> 
>> > Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.
>> 
>> > So what would be wise:
>> >    - just replace the changeset with the git commit sha-1 hash (always)
>> >    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
>> >    - make a separate "commit" entry besides the changeset and leave one undefined
>> 
>> > xen/Makefile currently has:
>> 
>> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
>> > include/xen/compile.h: include/xen/compile.h.in .banner
>> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
>> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
>> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
>> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
>> >             -e 's/@@hostname@@/$(shell hostname)/g' \
>> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
>> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
>> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
>> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
>> >             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
>> >             < include/xen/compile.h.in > $@.new
>> >         @grep \" .banner >> $@.new
>> >         @grep -v \" .banner
>> >         @mv -f $@.new $@
>> 
>> > --
>> > Sander
>> 
>> 
>> 
>> Perhaps use about the same as linux has in scripts/setlocalversion ?

> This is what I was going to suggest. Actually, I had it in mind we
> already did something like!

> Anyway, I think including whatever information the VCS we are building
> from supplied is the right answer and the way Linux does it seems useful
> and appropriate (e.g. using the tag name, appending -dirty etc).

> If we can also extend that to do something sensible in the tarball case
> then even better!

Not much info to get form a extracted tarball i'm afraid ?
Or one should include some extra versioning in the tarball itself and in that case you don't know if its "dirty" or not, just a "based on tarball with changeset/commit"

Since in that case it will describe something more/else than a mecurial changeset,
question is should the name "changeset" also be replaced by some more general naming ?



> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:45:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10: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 1UAI1y-0004qL-UC; Tue, 26 Feb 2013 10:45: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 1UAI1y-0004qG-3v
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:45:06 +0000
Received: from [193.109.254.147:56634] by server-11.bemta-14.messagelabs.com
	id C3/EC-30685-1329C215; Tue, 26 Feb 2013 10:45:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361875465!9041238!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3784 invoked from network); 26 Feb 2013 10:44:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 10:44:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1890830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 10:44: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.297.1;
	Tue, 26 Feb 2013 10:44:25 +0000
Message-ID: <1361875463.26546.262.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 26 Feb 2013 10:44:23 +0000
In-Reply-To: <1855874747.20130226113101@eikelenboom.it>
References: <1208255021.20130225232853@eikelenboom.it>
	<1701027415.20130226000019@eikelenboom.it>
	<1361874007.26546.255.camel@zakaz.uk.xensource.com>
	<1855874747.20130226113101@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
 after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 10:31 +0000, Sander Eikelenboom wrote:
> Tuesday, February 26, 2013, 11:20:07 AM, you wrote:
> 
> > On Mon, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
> >> Hello Sander,
> 
> > Talking to yourself is a sign of something or other I think ;-)
> 
> primarily hitting the send button a bit before my thoughts actually ended :-p (at least i hope)

;-)

> 
> 
> >> Monday, February 25, 2013, 11:28:53 PM, you wrote:
> >> 
> >> > Date: Mon, 25 Feb 2013 23:28:53 +0100
> >> > From: Sander Eikelenboom <linux@eikelenboom.it>
> >> > Organization: Eikelenboom IT services
> >> > X-Priority: 3 (Normal)
> >> > Message-ID: <1208255021.20130225232853@eikelenboom.it>
> >> > To: xen-devel <xen-devel@lists.xen.org>
> >> > Subject: Changeset / commit id not incorporated in build after switch to git
> >> > MIME-Version: 1.0
> >> > Content-Type: text/plain; charset=us-ascii
> >> > Content-Transfer-Encoding: 7bit
> >> 
> >> > Hi All,
> >> 
> >> > After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
> >> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)
> >> 
> >> > Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.
> >> 
> >> > So what would be wise:
> >> >    - just replace the changeset with the git commit sha-1 hash (always)
> >> >    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
> >> >    - make a separate "commit" entry besides the changeset and leave one undefined
> >> 
> >> > xen/Makefile currently has:
> >> 
> >> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> >> > include/xen/compile.h: include/xen/compile.h.in .banner
> >> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> >> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
> >> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
> >> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
> >> >             -e 's/@@hostname@@/$(shell hostname)/g' \
> >> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
> >> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
> >> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
> >> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
> >> >             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> >> >             < include/xen/compile.h.in > $@.new
> >> >         @grep \" .banner >> $@.new
> >> >         @grep -v \" .banner
> >> >         @mv -f $@.new $@
> >> 
> >> > --
> >> > Sander
> >> 
> >> 
> >> 
> >> Perhaps use about the same as linux has in scripts/setlocalversion ?
> 
> > This is what I was going to suggest. Actually, I had it in mind we
> > already did something like!
> 
> > Anyway, I think including whatever information the VCS we are building
> > from supplied is the right answer and the way Linux does it seems useful
> > and appropriate (e.g. using the tag name, appending -dirty etc).
> 
> > If we can also extend that to do something sensible in the tarball case
> > then even better!
> 
> Not much info to get form a extracted tarball i'm afraid ?

I think we used "hg archive" in the past and expect we will use "git
archive" in the future to generate the tarballs, which I think causes a
magic .{git,hg}foo to be dropped into the resulting tarball. I noticed
that Linux's set_version checks for .scmversion which I suppose might be
the same thing?

> Or one should include some extra versioning in the tarball itself and
> in that case you don't know if its "dirty" or not, just a "based on
> tarball with changeset/commit"

Yes, I don't think we can track dirtyness in this case, but we can at
least note that it was "tarball based on foo".

> Since in that case it will describe something more/else than a mecurial changeset,
> question is should the name "changeset" also be replaced by some more general naming ?

I think that would be a fair bit of unnecessary churn for only a
moderate amount of benefit (I'm sure people can cope with the word
changeset meaning something a bit more generic).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 10:45:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 10: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 1UAI1y-0004qL-UC; Tue, 26 Feb 2013 10:45: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 1UAI1y-0004qG-3v
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 10:45:06 +0000
Received: from [193.109.254.147:56634] by server-11.bemta-14.messagelabs.com
	id C3/EC-30685-1329C215; Tue, 26 Feb 2013 10:45:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1361875465!9041238!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3784 invoked from network); 26 Feb 2013 10:44:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 10:44:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1890830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 10:44: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.297.1;
	Tue, 26 Feb 2013 10:44:25 +0000
Message-ID: <1361875463.26546.262.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 26 Feb 2013 10:44:23 +0000
In-Reply-To: <1855874747.20130226113101@eikelenboom.it>
References: <1208255021.20130225232853@eikelenboom.it>
	<1701027415.20130226000019@eikelenboom.it>
	<1361874007.26546.255.camel@zakaz.uk.xensource.com>
	<1855874747.20130226113101@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Changeset / commit id not incorporated in build
 after switch to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 10:31 +0000, Sander Eikelenboom wrote:
> Tuesday, February 26, 2013, 11:20:07 AM, you wrote:
> 
> > On Mon, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
> >> Hello Sander,
> 
> > Talking to yourself is a sign of something or other I think ;-)
> 
> primarily hitting the send button a bit before my thoughts actually ended :-p (at least i hope)

;-)

> 
> 
> >> Monday, February 25, 2013, 11:28:53 PM, you wrote:
> >> 
> >> > Date: Mon, 25 Feb 2013 23:28:53 +0100
> >> > From: Sander Eikelenboom <linux@eikelenboom.it>
> >> > Organization: Eikelenboom IT services
> >> > X-Priority: 3 (Normal)
> >> > Message-ID: <1208255021.20130225232853@eikelenboom.it>
> >> > To: xen-devel <xen-devel@lists.xen.org>
> >> > Subject: Changeset / commit id not incorporated in build after switch to git
> >> > MIME-Version: 1.0
> >> > Content-Type: text/plain; charset=us-ascii
> >> > Content-Transfer-Encoding: 7bit
> >> 
> >> > Hi All,
> >> 
> >> > After the switching from mercurial to git, the changeset isn't incorporated anymore in the build.
> >> > This makes error reports possibly a bit less verbose (xl dmesg, serial logs and xl info now omit the changeset (or commit) info)
> >> 
> >> > Git doesn't have the concept of changesets afaik and mercurial is, while deprecated, still used as mirror.
> >> 
> >> > So what would be wise:
> >> >    - just replace the changeset with the git commit sha-1 hash (always)
> >> >    - use changeset when a mercurial tree is detected or the last git commit sha-1 (and date ?) when a git tree is detected
> >> >    - make a separate "commit" entry besides the changeset and leave one undefined
> >> 
> >> > xen/Makefile currently has:
> >> 
> >> > # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> >> > include/xen/compile.h: include/xen/compile.h.in .banner
> >> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> >> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
> >> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
> >> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
> >> >             -e 's/@@hostname@@/$(shell hostname)/g' \
> >> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | head -1)!g' \
> >> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
> >> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
> >> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
> >> >             -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> >> >             < include/xen/compile.h.in > $@.new
> >> >         @grep \" .banner >> $@.new
> >> >         @grep -v \" .banner
> >> >         @mv -f $@.new $@
> >> 
> >> > --
> >> > Sander
> >> 
> >> 
> >> 
> >> Perhaps use about the same as linux has in scripts/setlocalversion ?
> 
> > This is what I was going to suggest. Actually, I had it in mind we
> > already did something like!
> 
> > Anyway, I think including whatever information the VCS we are building
> > from supplied is the right answer and the way Linux does it seems useful
> > and appropriate (e.g. using the tag name, appending -dirty etc).
> 
> > If we can also extend that to do something sensible in the tarball case
> > then even better!
> 
> Not much info to get form a extracted tarball i'm afraid ?

I think we used "hg archive" in the past and expect we will use "git
archive" in the future to generate the tarballs, which I think causes a
magic .{git,hg}foo to be dropped into the resulting tarball. I noticed
that Linux's set_version checks for .scmversion which I suppose might be
the same thing?

> Or one should include some extra versioning in the tarball itself and
> in that case you don't know if its "dirty" or not, just a "based on
> tarball with changeset/commit"

Yes, I don't think we can track dirtyness in this case, but we can at
least note that it was "tarball based on foo".

> Since in that case it will describe something more/else than a mecurial changeset,
> question is should the name "changeset" also be replaced by some more general naming ?

I think that would be a fair bit of unnecessary churn for only a
moderate amount of benefit (I'm sure people can cope with the word
changeset meaning something a bit more generic).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:12:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11:12: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 1UAIRo-0005Bd-MF; Tue, 26 Feb 2013 11:11: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 1UAIRn-0005BY-9V
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 11:11:47 +0000
Received: from [85.158.139.83:58108] by server-10.bemta-5.messagelabs.com id
	12/4B-23714-2789C215; Tue, 26 Feb 2013 11:11:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361877105!28982990!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32328 invoked from network); 26 Feb 2013 11:11:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 11:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1892825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 11:11: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.297.1; Tue, 26 Feb 2013 11:11:44 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAIRk-0006pm-Lg;
	Tue, 26 Feb 2013 11:11:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAIRk-0003z3-Kh;
	Tue, 26 Feb 2013 11:11:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16690-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 11:11:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16690: 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 16690 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16690/

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. 16228
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16228

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 16228
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 16228

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-qemut-win    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-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Feb 25 13:20:22 2013 +0100

    x86_32: fix acpi_dmar_init()
    
    map_pages_to_xen() can't be used here on x86_32, need to use up to 2
    newly introduced fixmap entries for this instead.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:12:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11:12: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 1UAIRo-0005Bd-MF; Tue, 26 Feb 2013 11:11: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 1UAIRn-0005BY-9V
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 11:11:47 +0000
Received: from [85.158.139.83:58108] by server-10.bemta-5.messagelabs.com id
	12/4B-23714-2789C215; Tue, 26 Feb 2013 11:11:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361877105!28982990!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32328 invoked from network); 26 Feb 2013 11:11:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 11:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="1892825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 11:11: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.297.1; Tue, 26 Feb 2013 11:11:44 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAIRk-0006pm-Lg;
	Tue, 26 Feb 2013 11:11:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAIRk-0003z3-Kh;
	Tue, 26 Feb 2013 11:11:44 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16690-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 11:11:44 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16690: 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 16690 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16690/

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. 16228
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16228

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 16228
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 16228

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-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-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-qemut-win    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-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Feb 25 13:20:22 2013 +0100

    x86_32: fix acpi_dmar_init()
    
    map_pages_to_xen() can't be used here on x86_32, need to use up to 2
    newly introduced fixmap entries for this instead.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:26:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11: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 1UAIfu-0005Ok-KD; Tue, 26 Feb 2013 11:26:22 +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 1UAIfs-0005Of-P6
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:26:20 +0000
Received: from [85.158.143.99:47277] by server-3.bemta-4.messagelabs.com id
	47/7D-02186-CDB9C215; Tue, 26 Feb 2013 11:26:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361877973!29292890!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30221 invoked from network); 26 Feb 2013 11:26:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 11:26:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="9632729"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 11:26:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 06:26:11 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAIfj-0003qT-It;
	Tue, 26 Feb 2013 11:26:11 +0000
Message-ID: <512C9BD2.70903@eu.citrix.com>
Date: Tue, 26 Feb 2013 11:26:10 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
In-Reply-To: <512B594E02000078000C0BD1@nat28.tlf.novell.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/25/2013 11:30 AM, Jan Beulich wrote:
>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>> --- a/xen/common/sched_credit.c
>>>>> +++ b/xen/common/sched_credit.c
>>>>>
>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>>   {
>>>>>       s_time_t delta;
>>>>> +    uint64_t val;
>>>>>       unsigned int credits;
>>>>>
>>>>>       /* Assert svc is current */
>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>>       if ( (delta = now - svc->start_time) <= 0 )
>>>>>           return;
>>>>>
>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
>> MILLISECS(1);
>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>>> +    credits = val;
>>>>> +    ASSERT(credits == val);
>>>>
>>>> I may be missing something, but how can the assert ever be false, given
>>>> the assignment right before it?
>>>
>>> val being wider than credit, this checks that there was no truncation.
>>
>> ASSERT(val <= UINT_MAX);
>>
>> Would be clearer.
>
> A matter of taste perhaps...

I have a taste for coders having to keep as little state in their head 
as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
to think about the size of the variables.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:26:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11: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 1UAIfu-0005Ok-KD; Tue, 26 Feb 2013 11:26:22 +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 1UAIfs-0005Of-P6
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:26:20 +0000
Received: from [85.158.143.99:47277] by server-3.bemta-4.messagelabs.com id
	47/7D-02186-CDB9C215; Tue, 26 Feb 2013 11:26:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361877973!29292890!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30221 invoked from network); 26 Feb 2013 11:26:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 11:26:15 -0000
X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; 
   d="scan'208";a="9632729"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 11:26:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 06:26:11 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAIfj-0003qT-It;
	Tue, 26 Feb 2013 11:26:11 +0000
Message-ID: <512C9BD2.70903@eu.citrix.com>
Date: Tue, 26 Feb 2013 11:26:10 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
In-Reply-To: <512B594E02000078000C0BD1@nat28.tlf.novell.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/25/2013 11:30 AM, Jan Beulich wrote:
>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>> --- a/xen/common/sched_credit.c
>>>>> +++ b/xen/common/sched_credit.c
>>>>>
>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>>   {
>>>>>       s_time_t delta;
>>>>> +    uint64_t val;
>>>>>       unsigned int credits;
>>>>>
>>>>>       /* Assert svc is current */
>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>>       if ( (delta = now - svc->start_time) <= 0 )
>>>>>           return;
>>>>>
>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
>> MILLISECS(1);
>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>>> +    credits = val;
>>>>> +    ASSERT(credits == val);
>>>>
>>>> I may be missing something, but how can the assert ever be false, given
>>>> the assignment right before it?
>>>
>>> val being wider than credit, this checks that there was no truncation.
>>
>> ASSERT(val <= UINT_MAX);
>>
>> Would be clearer.
>
> A matter of taste perhaps...

I have a taste for coders having to keep as little state in their head 
as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
to think about the size of the variables.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:33:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11:33: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 1UAImW-0005aL-HU; Tue, 26 Feb 2013 11:33:12 +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 1UAImU-0005aG-OX
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:33:10 +0000
Received: from [85.158.139.83:9356] by server-5.bemta-5.messagelabs.com id
	1B/0D-02762-57D9C215; Tue, 26 Feb 2013 11:33:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361878387!24643487!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7421 invoked from network); 26 Feb 2013 11:33:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 11:33:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9157579"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 11:33:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 06:33:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAImQ-0003wV-Sj;
	Tue, 26 Feb 2013 11:33:06 +0000
Message-ID: <1361878386.2109.42.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Tue, 26 Feb 2013 11:33:06 +0000
In-Reply-To: <512C26F5.8020100@oracle.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<512C26F5.8020100@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen
 network 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, 2013-02-26 at 03:07 +0000, ANNIE LI wrote:
> What the version are these patches based on?
> I tried v3.8-rc7 and 3.8-rc6, patch 3/8, 4/8 ... can not be merged 
> successfully. Can you rebase it?
> 

IIRC we had some XSA patches after this series. Or I just developed it
on top of a old branch. I will rebase it soon.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:33:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11:33: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 1UAImW-0005aL-HU; Tue, 26 Feb 2013 11:33:12 +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 1UAImU-0005aG-OX
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:33:10 +0000
Received: from [85.158.139.83:9356] by server-5.bemta-5.messagelabs.com id
	1B/0D-02762-57D9C215; Tue, 26 Feb 2013 11:33:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361878387!24643487!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7421 invoked from network); 26 Feb 2013 11:33:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 11:33:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9157579"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 11:33:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 06:33:07 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAImQ-0003wV-Sj;
	Tue, 26 Feb 2013 11:33:06 +0000
Message-ID: <1361878386.2109.42.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Tue, 26 Feb 2013 11:33:06 +0000
In-Reply-To: <512C26F5.8020100@oracle.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<512C26F5.8020100@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen
 network 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, 2013-02-26 at 03:07 +0000, ANNIE LI wrote:
> What the version are these patches based on?
> I tried v3.8-rc7 and 3.8-rc6, patch 3/8, 4/8 ... can not be merged 
> successfully. Can you rebase it?
> 

IIRC we had some XSA patches after this series. Or I just developed it
on top of a old branch. I will rebase it soon.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:47:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11:47: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 1UAIzZ-0005n8-22; Tue, 26 Feb 2013 11:46:41 +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 1UAIzY-0005n3-4S
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:46:40 +0000
Received: from [85.158.139.211:5272] by server-15.bemta-5.messagelabs.com id
	FE/25-22815-F90AC215; Tue, 26 Feb 2013 11:46:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361879197!19375885!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10867 invoked from network); 26 Feb 2013 11:46:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 11:46:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 11:46:37 +0000
Message-Id: <512CAEA902000078000C10BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 11:46:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
In-Reply-To: <512C9BD2.70903@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:26, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 02/25/2013 11:30 AM, Jan Beulich wrote:
>>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>>> --- a/xen/common/sched_credit.c
>>>>>> +++ b/xen/common/sched_credit.c
>>>>>>
>>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>>>   {
>>>>>>       s_time_t delta;
>>>>>> +    uint64_t val;
>>>>>>       unsigned int credits;
>>>>>>
>>>>>>       /* Assert svc is current */
>>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>>>       if ( (delta = now - svc->start_time) <= 0 )
>>>>>>           return;
>>>>>>
>>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
>>> MILLISECS(1);
>>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>>>> +    credits = val;
>>>>>> +    ASSERT(credits == val);
>>>>>
>>>>> I may be missing something, but how can the assert ever be false, given
>>>>> the assignment right before it?
>>>>
>>>> val being wider than credit, this checks that there was no truncation.
>>>
>>> ASSERT(val <= UINT_MAX);
>>>
>>> Would be clearer.
>>
>> A matter of taste perhaps...
> 
> I have a taste for coders having to keep as little state in their head 
> as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
> to think about the size of the variables.

Okay, assuming this is the only thing you dislike, I'll change it then
and re-submit.

But for the record - using UINT_MAX here will get things out of
sync the moment the type of "credits" changes, whereas with
the way I had coded it this would be taken care of implicitly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:47:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11:47: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 1UAIzZ-0005n8-22; Tue, 26 Feb 2013 11:46:41 +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 1UAIzY-0005n3-4S
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:46:40 +0000
Received: from [85.158.139.211:5272] by server-15.bemta-5.messagelabs.com id
	FE/25-22815-F90AC215; Tue, 26 Feb 2013 11:46:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361879197!19375885!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10867 invoked from network); 26 Feb 2013 11:46:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 11:46:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 11:46:37 +0000
Message-Id: <512CAEA902000078000C10BF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 11:46:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
In-Reply-To: <512C9BD2.70903@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:26, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 02/25/2013 11:30 AM, Jan Beulich wrote:
>>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>>> --- a/xen/common/sched_credit.c
>>>>>> +++ b/xen/common/sched_credit.c
>>>>>>
>>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>>>   {
>>>>>>       s_time_t delta;
>>>>>> +    uint64_t val;
>>>>>>       unsigned int credits;
>>>>>>
>>>>>>       /* Assert svc is current */
>>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>>>       if ( (delta = now - svc->start_time) <= 0 )
>>>>>>           return;
>>>>>>
>>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
>>> MILLISECS(1);
>>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>>>> +    credits = val;
>>>>>> +    ASSERT(credits == val);
>>>>>
>>>>> I may be missing something, but how can the assert ever be false, given
>>>>> the assignment right before it?
>>>>
>>>> val being wider than credit, this checks that there was no truncation.
>>>
>>> ASSERT(val <= UINT_MAX);
>>>
>>> Would be clearer.
>>
>> A matter of taste perhaps...
> 
> I have a taste for coders having to keep as little state in their head 
> as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
> to think about the size of the variables.

Okay, assuming this is the only thing you dislike, I'll change it then
and re-submit.

But for the record - using UINT_MAX here will get things out of
sync the moment the type of "credits" changes, whereas with
the way I had coded it this would be taken care of implicitly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11: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 1UAJ6u-0005wh-24; Tue, 26 Feb 2013 11:54:16 +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 1UAJ6s-0005wc-95
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:54:14 +0000
Received: from [85.158.137.99:50653] by server-1.bemta-3.messagelabs.com id
	04/CF-08955-562AC215; Tue, 26 Feb 2013 11:54:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361879554!17975284!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28941 invoked from network); 26 Feb 2013 11:52:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 11:52:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAJ5B-000OjV-LH; Tue, 26 Feb 2013 11:52:29 +0000
Date: Tue, 26 Feb 2013 11:52:29 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226115229.GB93966@ocelot.phlegethon.org>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CAEA902000078000C10BF@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:46 +0000 on 26 Feb (1361879193), Jan Beulich wrote:
> >>> On 26.02.13 at 12:26, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > On 02/25/2013 11:30 AM, Jan Beulich wrote:
> >>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
> >>> On 25/02/13 09:29, Jan Beulich wrote:
> >>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> >>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
> >>>>>> --- a/xen/common/sched_credit.c
> >>>>>> +++ b/xen/common/sched_credit.c
> >>>>>>
> >>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
> >>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
> >>>>>>   {
> >>>>>>       s_time_t delta;
> >>>>>> +    uint64_t val;
> >>>>>>       unsigned int credits;
> >>>>>>
> >>>>>>       /* Assert svc is current */
> >>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
> >>>>>>       if ( (delta = now - svc->start_time) <= 0 )
> >>>>>>           return;
> >>>>>>
> >>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
> >>> MILLISECS(1);
> >>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> >>>>>> +    svc->residual = do_div(val, MILLISECS(1));
> >>>>>> +    credits = val;
> >>>>>> +    ASSERT(credits == val);
> >>>>>
> >>>>> I may be missing something, but how can the assert ever be false, given
> >>>>> the assignment right before it?
> >>>>
> >>>> val being wider than credit, this checks that there was no truncation.
> >>>
> >>> ASSERT(val <= UINT_MAX);
> >>>
> >>> Would be clearer.
> >>
> >> A matter of taste perhaps...
> > 
> > I have a taste for coders having to keep as little state in their head 
> > as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
> > to think about the size of the variables.
> 
> Okay, assuming this is the only thing you dislike, I'll change it then
> and re-submit.
> 
> But for the record - using UINT_MAX here will get things out of
> sync the moment the type of "credits" changes, whereas with
> the way I had coded it this would be taken care of implicitly.

How about ASSERT(((typeof credits) val) == val) before the assignment?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 11:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 11: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 1UAJ6u-0005wh-24; Tue, 26 Feb 2013 11:54:16 +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 1UAJ6s-0005wc-95
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 11:54:14 +0000
Received: from [85.158.137.99:50653] by server-1.bemta-3.messagelabs.com id
	04/CF-08955-562AC215; Tue, 26 Feb 2013 11:54:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361879554!17975284!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28941 invoked from network); 26 Feb 2013 11:52:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 11:52:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAJ5B-000OjV-LH; Tue, 26 Feb 2013 11:52:29 +0000
Date: Tue, 26 Feb 2013 11:52:29 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226115229.GB93966@ocelot.phlegethon.org>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CAEA902000078000C10BF@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:46 +0000 on 26 Feb (1361879193), Jan Beulich wrote:
> >>> On 26.02.13 at 12:26, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > On 02/25/2013 11:30 AM, Jan Beulich wrote:
> >>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
> >>> On 25/02/13 09:29, Jan Beulich wrote:
> >>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> >>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
> >>>>>> --- a/xen/common/sched_credit.c
> >>>>>> +++ b/xen/common/sched_credit.c
> >>>>>>
> >>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
> >>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
> >>>>>>   {
> >>>>>>       s_time_t delta;
> >>>>>> +    uint64_t val;
> >>>>>>       unsigned int credits;
> >>>>>>
> >>>>>>       /* Assert svc is current */
> >>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
> >>>>>>       if ( (delta = now - svc->start_time) <= 0 )
> >>>>>>           return;
> >>>>>>
> >>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
> >>> MILLISECS(1);
> >>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> >>>>>> +    svc->residual = do_div(val, MILLISECS(1));
> >>>>>> +    credits = val;
> >>>>>> +    ASSERT(credits == val);
> >>>>>
> >>>>> I may be missing something, but how can the assert ever be false, given
> >>>>> the assignment right before it?
> >>>>
> >>>> val being wider than credit, this checks that there was no truncation.
> >>>
> >>> ASSERT(val <= UINT_MAX);
> >>>
> >>> Would be clearer.
> >>
> >> A matter of taste perhaps...
> > 
> > I have a taste for coders having to keep as little state in their head 
> > as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
> > to think about the size of the variables.
> 
> Okay, assuming this is the only thing you dislike, I'll change it then
> and re-submit.
> 
> But for the record - using UINT_MAX here will get things out of
> sync the moment the type of "credits" changes, whereas with
> the way I had coded it this would be taken care of implicitly.

How about ASSERT(((typeof credits) val) == val) before the assignment?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:01:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJDE-0006Bo-Qp; Tue, 26 Feb 2013 12:00:48 +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 1UAJDC-0006Bb-T6
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:00:47 +0000
Received: from [85.158.139.83:58747] by server-6.bemta-5.messagelabs.com id
	19/18-21466-DE3AC215; Tue, 26 Feb 2013 12:00:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361880043!24649026!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20042 invoked from network); 26 Feb 2013 12:00:44 -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;
	26 Feb 2013 12:00:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9641052"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:00:22 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:00:21 -0500
Message-ID: <512CA3D3.3040002@citrix.com>
Date: Tue, 26 Feb 2013 12:00:19 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
In-Reply-To: <20130226115229.GB93966@ocelot.phlegethon.org>
X-Originating-IP: [10.80.2.76]
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 11:52, Tim Deegan wrote:
> At 11:46 +0000 on 26 Feb (1361879193), Jan Beulich wrote:
>>>>> On 26.02.13 at 12:26, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>>> On 02/25/2013 11:30 AM, Jan Beulich wrote:
>>>>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>>>>> +    ASSERT(credits == val);
>>>>>>>
>>>>>>> I may be missing something, but how can the assert ever be false, given
>>>>>>> the assignment right before it?
>>>>>>
>>>>>> val being wider than credit, this checks that there was no truncation.
>>>>>
>>>>> ASSERT(val <= UINT_MAX);
>>>>>
>>>>> Would be clearer.
>>>>
>>>> A matter of taste perhaps...
>>>
>>> I have a taste for coders having to keep as little state in their head 
>>> as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
>>> to think about the size of the variables.
>>
>> Okay, assuming this is the only thing you dislike, I'll change it then
>> and re-submit.
>>
>> But for the record - using UINT_MAX here will get things out of
>> sync the moment the type of "credits" changes, whereas with
>> the way I had coded it this would be taken care of implicitly.
> 
> How about ASSERT(((typeof credits) val) == val) before the assignment?

FWIW, this works for me.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:01:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJDE-0006Bo-Qp; Tue, 26 Feb 2013 12:00:48 +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 1UAJDC-0006Bb-T6
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:00:47 +0000
Received: from [85.158.139.83:58747] by server-6.bemta-5.messagelabs.com id
	19/18-21466-DE3AC215; Tue, 26 Feb 2013 12:00:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361880043!24649026!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20042 invoked from network); 26 Feb 2013 12:00:44 -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;
	26 Feb 2013 12:00:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9641052"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:00:22 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:00:21 -0500
Message-ID: <512CA3D3.3040002@citrix.com>
Date: Tue, 26 Feb 2013 12:00:19 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
In-Reply-To: <20130226115229.GB93966@ocelot.phlegethon.org>
X-Originating-IP: [10.80.2.76]
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 11:52, Tim Deegan wrote:
> At 11:46 +0000 on 26 Feb (1361879193), Jan Beulich wrote:
>>>>> On 26.02.13 at 12:26, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>>> On 02/25/2013 11:30 AM, Jan Beulich wrote:
>>>>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>>>>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>>>>> +    ASSERT(credits == val);
>>>>>>>
>>>>>>> I may be missing something, but how can the assert ever be false, given
>>>>>>> the assignment right before it?
>>>>>>
>>>>>> val being wider than credit, this checks that there was no truncation.
>>>>>
>>>>> ASSERT(val <= UINT_MAX);
>>>>>
>>>>> Would be clearer.
>>>>
>>>> A matter of taste perhaps...
>>>
>>> I have a taste for coders having to keep as little state in their head 
>>> as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
>>> to think about the size of the variables.
>>
>> Okay, assuming this is the only thing you dislike, I'll change it then
>> and re-submit.
>>
>> But for the record - using UINT_MAX here will get things out of
>> sync the moment the type of "credits" changes, whereas with
>> the way I had coded it this would be taken care of implicitly.
> 
> How about ASSERT(((typeof credits) val) == val) before the assignment?

FWIW, this works for me.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJL8-0006VM-4b; Tue, 26 Feb 2013 12:08:58 +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 1UAJL7-0006VH-2M
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:08:57 +0000
Received: from [85.158.137.99:30572] by server-9.bemta-3.messagelabs.com id
	43/34-09484-4D5AC215; Tue, 26 Feb 2013 12:08:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361880526!18040151!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26904 invoked from network); 26 Feb 2013 12:08:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9167573"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:08:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:08:15 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAJKR-0004Tv-0c;
	Tue, 26 Feb 2013 12:08:15 +0000
Message-ID: <512CA5AE.4090002@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:08:14 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<51236654.3050709@citrix.com>
In-Reply-To: <51236654.3050709@citrix.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

T24gMDIvMTkvMjAxMyAxMTo0NyBBTSwgQW5kcmV3IENvb3BlciB3cm90ZToKPiBPbiAxOS8wMi8x
MyAwOToyOCwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+IE9uIDE4LjAyLjEzIGF0IDE5OjExLCBB
bmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiB3cm90ZToKPj4+IEhlbGxv
LAo+Pj4KPj4+IE91ciB0ZXN0aW5nIGhhcyBkaXNjb3ZlcmVkIGEgY3Jhc2ggKHBhZ2VmYXVsdCBh
dCAweDAwMDAwMDAwMDAwMDAwMDgpCj4+PiB3aGljaCBJIGhhdmUgdHJhY2tlZCBkb3duIHRvIGJh
ZCBfX3J1bnFfcmVtb3ZlKCkgaW4gY3NjaGVkX3ZjcHVfc2xlZXAoKQo+Pj4gaW4gc2NoZWRfY3Jl
ZGl0LmMgKGJlY2F1c2UgYSBzdGF0aWMgZnVuY3Rpb24gb2YgdGhlIHNhbWUgbmFtZSBhbHNvCj4+
PiBleGlzdHMgaW4gc2NoZWRfY3JlZGl0Mi5jLCB3aGljaCBjb25mdXNlZCBtYXR0ZXJzIHRvIHN0
YXJ0IHdpdGgpCj4+Pgo+Pj4gVGhlIHRlc3QgY2FzZSB3YXMgYSBsb29wIG9mIGxvY2FsaG9zdCBt
aWdyYXRlIG9mIGEgMXZjcHUgSFZNIHdpbjgKPj4+IGRvbWFpbi4gIFRoZSB0ZXN0IGNhc2UgaXRz
ZWxmIGhhcyBwYXNzZWQgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCBvbiB0aGUKPj4+IHNhbWUgWGVu
IGNvZGViYXNlIChYZW4tNC4xLjMpLCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdmVyeSByYXJlLiAg
VGhlcmUKPj4+IGRvZXMgbm90IGFwcGVhciB0byBiZSBhbnkgcmVsZXZhbnQgY2hhbmdlcyBiZXR3
ZWVuIHRoZSB2ZXJzaW9uIG9mIFhlbiBpbgo+Pj4gdGhlIHRlc3QgYW5kIHhlbi00LjEtdGVzdGlu
Zy4KPj4+Cj4+PiBUaGUgZmFpbHVyZSBpdHNlbGYgaXMgYmVjYXVzZSBvZiBhIFhFTl9ET01DVExf
c2NoZWR1bGVyX29wICh0cmFjZSBiZWxvdykKPj4+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBW
Q1BVIG9mIHRoZSBtaWdyYXRpbmcgZG9tYWluLgo+Pj4KPj4+IChYRU4pIFhlbiBjYWxsIHRyYWNl
Ogo+Pj4gKFhFTikgICAgICAgWzxmZmZmODJjNDgwMTE2YTE0Pl0gY3NjaGVkX3ZjcHVfc2xlZXAr
MHg0NC8weDcwCj4+PiAoWEVOKSAgICAgIDBbPGZmZmY4MmM0ODAxMjAxMTc+XSB2Y3B1X3NsZWVw
X25vc3luYysweGU3LzB4M2IwCj4+PiAoWEVOKSAgICAgMTJbPGZmZmY4MmM0ODAxMjAzZTk+XSB2
Y3B1X3NsZWVwX3N5bmMrMHg5LzB4NTAKPj4+IChYRU4pICAgICAxNFs8ZmZmZjgyYzQ4MDExZmQ0
Yz5dIHNjaGVkX2FkanVzdCsweGFjLzB4MjMwCj4+PiAoWEVOKSAgICAgMjRbPGZmZmY4MmM0ODAx
MDJiYzE+XSBkb19kb21jdGwrMHg3MzEvMHgxMTMwCj4+PiAoWEVOKSAgICAgNjRbPGZmZmY4MmM0
ODAyMDEzYzQ+XSBjb21wYXRfaHlwZXJjYWxsKzB4NzQvMHg4MAo+Pj4KPj4+IFRoZSByZWxldmFu
dCBwYXJ0IG9mIGNzY2hlZF92Y3B1X3NsZWVwKCkgaXMKPj4+Cj4+PiAgICAgIGVsc2UgaWYgKCBf
X3ZjcHVfb25fcnVucShzdmMpICkKPj4+ICAgICAgICAgIF9fcnVucV9yZW1vdmUoc3ZjKTsKPj4+
Cj4+PiB3aGljaCBkaXNhc3NlbWJsZXMgdG8KPj4+Cj4+PiBmZmZmODJjNDgwMTE2YTAxOiAgICAg
ICA0OSA4YiAxMCAgICAgICAgICAgICAgICBtb3YgICAgKCVyOCksJXJkeAo+Pj4gZmZmZjgyYzQ4
MDExNmEwNDogICAgICAgNGMgMzkgYzIgICAgICAgICAgICAgICAgY21wICAgICVyOCwlcmR4Cj4+
PiBmZmZmODJjNDgwMTE2YTA3OiAgICAgICA3NSAwNyAgICAgICAgICAgICAgICAgICBqbmUgICAg
ZmZmZjgyYzQ4MDExNmExMAo+Pj4gPGNzY2hlZF92Y3B1X3NsZWVwKzB4NDA+Cj4+PiBmZmZmODJj
NDgwMTE2YTA5OiAgICAgICBmMyBjMyAgICAgICAgICAgICAgICAgICByZXB6IHJldHEKPj4+IGZm
ZmY4MmM0ODAxMTZhMGI6ICAgICAgIDBmIDFmIDQ0IDAwIDAwICAgICAgICAgIG5vcGwgICAweDAo
JXJheCwlcmF4LDEpCj4+PiBmZmZmODJjNDgwMTE2YTEwOiAgICAgICA0OSA4YiA0MCAwOCAgICAg
ICAgICAgICBtb3YgICAgMHg4KCVyOCksJXJheAo+Pj4gZmZmZjgyYzQ4MDExNmExNDogICAgICAg
NDggODkgNDIgMDggICAgICAgICAgICAgbW92ICAgICVyYXgsMHg4KCVyZHgpICMKPj4+IDwtIFBh
Z2VmYXVsdCBoZXJlCj4+PiBmZmZmODJjNDgwMTE2YTE4OiAgICAgICA0OCA4OSAxMCAgICAgICAg
ICAgICAgICBtb3YgICAgJXJkeCwoJXJheCkKPj4+IGZmZmY4MmM0ODAxMTZhMWI6ICAgICAgIDRk
IDg5IDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAlcjgsMHg4KCVyOCkKPj4+IGZmZmY4MmM0ODAx
MTZhMWY6ICAgICAgIDRkIDg5IDAwICAgICAgICAgICAgICAgIG1vdiAgICAlcjgsKCVyOCkKPj4+
Cj4+PiBUaGUgcmVsZXZhbnQgY3Jhc2ggcmVnaXN0ZXJzIGZyb20gdGhlIHBhZ2VmYXVsdCBhcmU6
Cj4+PiByYXg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+IHJkeDogMDAwMDAwMDAwMDAwMDAwMAo+Pj4g
ICByODogZmZmZjgzMDgwYzg5ZWQ5MAo+Pj4KPj4+IElmIEkgYW0gcmVhZGluZyB0aGUgY29kZSBj
b3JyZWN0bHksIHRoaXMgbWVhbnMgdGhhdCBydW5xLT5uZXh0IGlzIE5VTEwsCj4+PiBzbyB3ZSBm
YWlsIGxpc3RfZW1wdHkoKSBhbmQgZXJyb25lb3VzbHkgcGFzcyBfX3ZjcHVfb25fcnVucSgpLiAg
V2UgdGhlbgo+Pj4gZmFpbCB3aXRoIGEgZmF1bHQgd2hlbiB0cnlpbmcgdG8gdXBkYXRlIHJ1bnEt
PnByZXYsIHdoaWNoIGlzIGFsc28gTlVMTC4KPj4+Cj4+PiBUaGUgb25seSBwbGFjZSBJIGNhbiBz
cG90IGluIHRoZSBjb2RlIHdoZXJlIHRoZSBydW5xLT57bmV4dCxwcmV2fSBjb3VsZAo+Pj4gY29u
Y2VpdmFibHkgYmUgTlVMTCBpcyBpbiBjc2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBt
ZW1zZXQoKSBhbmQKPj4+IElOSVRfTElTVF9IRUFEKCkuICBUaGlzIGlzIGxvZ2ljYWxseSBzZW5z
aWJsZSBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZQo+Pj4gbG9jYWxob3N0IG1pZ3JhdGUgbG9vcCwg
YW5kIEkgY2FudCBpbW1lZGlhdGVseSBzZWUgYW55dGhpbmcgdG8gcHJldmVudAo+Pj4gdGhpcyBy
YWNlIGhhcHBlbmluZy4KPj4gQnV0IHRoYXQgZG9lc24ndCBtYWtlIHNlbnNlOiBjc2NoZWRfYWxs
b2NfdmRhdGEoKSBkb2Vzbid0IHN0b3JlCj4+IHN2YyBpbnRvIHZjLT5zY2hlZF9wcml2OyB0aGF0
J3MgYmVpbmcgZG9uZSBieSB0aGUgZ2VuZXJpYwo+PiBzY2hlZHVsZXIgY29kZSBvbmNlIHRoZSBh
Y3RvciByZXR1cm5zLgo+Cj4gRCdvaCB5ZXMgLSBJIG92ZXJsb29rZWQgdGhhdC4KPgo+Pgo+PiBT
byBJJ2QgcmF0aGVyIHN1c3BlY3QgYSBzdGFsZSBwb2ludGVyIGJlaW5nIHVzZWQsIHdoaWNoIGlz
IGVhc2lseQo+PiBwb3NzaWJsZSB3aGVuIHJhY2luZyB3aXRoIHNjaGVkX21vdmVfZG9tYWluKCkg
KGFzIG9wcG9zZWQgdG8KPj4gc2NoZWR1bGVfY3B1X3N3aXRjaCgpLCB3aGVyZSB0aGUgbmV3IHBv
aW50ZXIgZ2V0cyBzdG9yZWQKPj4gX2JlZm9yZV8gZGUtYWxsb2NhdGluZyB0aGUgb2xkIG9uZSku
Cj4KPj4KPj4gSG93ZXZlciwgc2NoZWRfbW92ZV9kb21haW4oKSAoYXMgd2VsbCBhcyBzY2hlZHVs
ZV9jcHVfc3dpdGNoKCkpCj4+IGdldCBjYWxsZWQgb25seSBmcm9tIENQVSBwb29scyBjb2RlLCBh
bmQgSSB3b3VsZCBndWVzcyBDUFUgcG9vbHMKPj4gYXJlbid0IGludm9sdmVkIGhlcmUsIGFuZCB5
b3UgZG9uJ3QgaW4gcGFyYWxsZWwgc29mdCBvZmZsaW5lL29ubGluZQo+PiBwQ1BVLXMgKGFzIEkn
bSBzdXJlIHlvdSBvdGhlcndpc2Ugd291bGQgaGF2ZSBtZW50aW9uZWQgaXQpLgo+Pgo+PiBCdXQg
d2FpdCAtIGxpYnhsX19kb21haW5fbWFrZSgpIF91bmNvbmRpdGlvbmFsbHlfIGNhbGxzCj4+IHhj
X2NwdXBvb2xfbW92ZWRvbWFpbigpLCBhcyBkb2VzIFhlbmREb21haW5JbmZvJ3MKPj4gX2NvbnN0
cnVjdERvbWFpbigpLiBUaGUgcmVhc29uIGZvciB0aGlzIGVzY2FwZXMgbWUgLSBKw7xyZ2VuPyBZ
ZXQKPj4gSSdkIGV4cGVjdCB0aGUgcG9vbCBJRCBtYXRjaGluZyBjaGVjayB0byBzaG9ydCBjdXQg
dGhlIHJlc3VsdGluZwo+PiBzeXNjdGwsIGkuZS4gc2NoZWRfbW92ZV9kb21haW4oKSBvdWdodCB0
byBub3QgYmUgcmVhY2hlZCBhbnl3YXkKPj4gKHdvcnRoIHZlcmlmeWluZyBvZiBjb3Vyc2UpLgo+
Pgo+PiBUaGUgcmFjZSB0aGVyZSBuZXZlcnRoZWxlc3Mgb3VnaHQgdG8gYmUgZml4ZWQuCj4+Cj4+
IEphbgo+Cj4gT3VyIHRvb2xzdGFjayBob29rcyBkaXJlY3RseSBpbnRvIGxpYnhjIGFuZCBpcyBj
b21wbGV0ZWx5IGlnbm9yYW50IG9mCj4gY3B1cG9vbHMuICBMb29raW5nIGF0IHRoZSBjcmFzaCBt
b3JlIGNsb3NlbHksIGl0IG1pZ2h0IGJlIGEgcmFjZSBlbHNld2hlcmUKPgo+IEFub3RoZXIgZG9t
MCB2Y3B1IGlzIGluIGFuIEhWTU9QX3RyYWNrX2RpcnR5X3ZyYW0gaHlwZXJjYWxsLCBhbmQgdGhl
Cj4gYXNzb2NpYXRlZCBYZW4gc3RhY2sgdHJhY2UgaXMKPgo+IFtmZmZmODJjNDgwMTc3N2IyXSB0
aW1lX2NhbGlicmF0aW9uX3N0ZF9yZW5kZXp2b3VzKzB4YjIvMHhjMAo+ICAgZmZmZjgyYzQ4MDE3
MmQxMiAgX19zbXBfY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQrMHg2Mi8weGIwCj4gICBmZmZmODJj
NDgwMTczMzllICBzbXBfY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQrMHg0ZS8weDkwCj4gICBmZmZm
ODJjNDgwMTRhNjVhICBjYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDJhLzB4MzAKPiAgIGZmZmY4
MmM0ODAxMjIzYjIgIF9zcGluX2xvY2srMHgxMi8weDIwCj4gICBmZmZmODJjNDgwMTczNGFiICBm
bHVzaF9hcmVhX21hc2srMHhjYi8weDFjMAo+ICAgZmZmZjgyYzQ4MDFjODYyYSAgcGFnaW5nX2xv
Z19kaXJ0eV9yYW5nZSsweDNhLzB4NzgwCj4gICBmZmZmODJjNDgwMTIxZWE4ICBjcHVtYXNrX3Jh
aXNlX3NvZnRpcnErMHg3OC8weDgwCj4gICBmZmZmODJjNDgwMTE3ZWQzICBjc2NoZWRfdmNwdV93
YWtlKzB4MTkzLzB4NDIwCj4gICBmZmZmODJjNDgwMTRhNWZhICBldmVudF9jaGVja19pbnRlcnJ1
cHQrMHgyYS8weDMwCj4gICBmZmZmODJjNDgwMWYyMWM3ICBoYXBfdHJhY2tfZGlydHlfdnJhbSsw
eDEzNy8weDFjMAo+ICAgZmZmZjgyYzQ4MDFhZDNmZCAgZG9faHZtX29wKzB4MTZkZC8weDFmNTAK
PiAgIGZmZmY4MmM0ODAxMDYyNTEgIGV2dGNobl9zZW5kKzB4YTEvMHgxNjAKPiAgIGZmZmY4MmM0
ODAxMDZkMzYgIGRvX2V2ZW50X2NoYW5uZWxfb3ArMHg4NzYvMHhmZDAKPiAgIGZmZmY4MmM0ODAx
ZjkwMjcgIGNvbXBhdF91cGRhdGVfZGVzY3JpcHRvcisweDI3LzB4MzAKPiAgIGZmZmY4MmM0ODAx
MzU0ZjggIGNvbXBhdF9tdWx0aWNhbGwrMHgxOTgvMHgzODAKPiAgIGZmZmY4MmM0ODAxNGE1ZmEg
IGV2ZW50X2NoZWNrX2ludGVycnVwdCsweDJhLzB4MzAKPiAgIGZmZmY4MmM0ODAyMDEzYzQgIGNv
bXBhdF9oeXBlcmNhbGwrMHg3NC8weDgwCj4KPiB0aGUgaGFwX3RyYWNrX2RpcnR5X3ZyYW0oKSBh
bmQgcGFnaW5nX2xvZ19kaXJ0eV9yYW5nZSgpIGFyZSBwYXJ0IG9mIHRoZQo+IHNhbWUgbG9naWNh
bCBjYWxsIHRyYWNlLCBidXQgaXQgYXBwZWFycyB0aGF0IHdlIGhhdmUgdGFrZW4gYW4KPiBldmVu
dF9jaGVja19pbnRlcnJ1cHQoKSBpbiB0aGUgbWlkZGxlIGFuZCBjYWxsZWQgc2NoZWR1bGUoKSBv
ZmYgdGhlCj4gYm90dG9tIG9mIGl0LCBjYWxsaW5nIGNzY2hlZF92Y3B1X3dha2UoKS4KPgo+IEkg
YW0gY3VycmVudGx5IHRyeWluZyB0byByZWFzb24gYXMgdG8gd2hldGhlciBpdCBpcyBwb3NzaWJs
ZSBmb3IgYSByYWNlCj4gYmV0d2VlbiBjc2NoZWRfdmNwdV97c2xlZXAsd2FrZX0oKSBjb3VsZCBy
ZXN1bHQgaW4gdGhlIHNlZW4gY3Jhc2gsIGJ1dAo+IGl0IGNlcnRhaW5seSBsb29rcyBsaWtlIGEg
c21va2luZyBndW4uCgpBbnkgbW9yZSBwcm9ncmVzcyBvbiB0aGlzIG9uZT8KCkluIHRoZW9yeSBh
bGwgb2YgdGhvc2Ugc2hvdWxkIGJlIG1hZGUgbXV0dWFsbHkgZXhjbHVzaXZlIGJ5IGhvbGRpbmcg
dGhlIApsb2NrIG9mIHRoZSBydW5xdWV1ZSBvbiB3aGljaCB0aGUgVkNQVSBpcyBydW5uaW5nLgoK
QW55IGNoYW5jZSB0aGVyZSdzIGEgcmFjZSB3aXRoIHRoZSBhc3NpZ25tZW50IG9mIHRoZSB2Y3B1
IC0tIHRoYXQgaXMsIGEgCnJhY2UgaW4gdmNwdV9zY2hlZHVsZV9sb2NrKCkgc3VjaCB0aGF0IHNv
bWVvbmUgZW5kcyB1cCBncmFiYmluZyB0aGUgCndyb25nIGxvY2s/CgpJIHRoaW5rIHRoYXQgaW4g
dGhlb3J5IG9uY2UgeW91IGNhbGwgSU5JVF9MSVNUX0hFQUQsIG5vbmUgb2YgdGhvc2UgCnBvaW50
ZXJzIHNob3VsZCBldmVyIGJlIHNldCB0byB6ZXJvOyBpZiBvbmUgZXZlciB3ZXJlIGl0IG1pZ2h0
IGdldCAKcGFzc2VkIGFyb3VuZCBhIGJpdCBiZWZvcmUgYWN0dWFsbHkgYmVpbmcgZm9sbG93ZWQu
ICBBbnkgY2hhbmNlIHRoZXJlJ3MgCnNvbWV0aGluZyB1bmluaXRpYWxpemVkIHNvbWV3aGVyZT8K
CkFuZCBvZiBjb3Vyc2UsIGlmIGFsbCBlbHNlIGZhaWxzLCB0aGVyZSdzIGdvb2Qgb2xkLWZhc2hp
b25lZCBtZW1vcnkgCmNsb2JiZXJpbmcgYXMgYSBwb3NzaWJpbGl0eS4uLgoKICAtR2VvcmdlCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJL8-0006VM-4b; Tue, 26 Feb 2013 12:08:58 +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 1UAJL7-0006VH-2M
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:08:57 +0000
Received: from [85.158.137.99:30572] by server-9.bemta-3.messagelabs.com id
	43/34-09484-4D5AC215; Tue, 26 Feb 2013 12:08:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361880526!18040151!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26904 invoked from network); 26 Feb 2013 12:08:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9167573"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:08:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:08:15 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAJKR-0004Tv-0c;
	Tue, 26 Feb 2013 12:08:15 +0000
Message-ID: <512CA5AE.4090002@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:08:14 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Andrew Cooper <andrew.cooper3@citrix.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<51236654.3050709@citrix.com>
In-Reply-To: <51236654.3050709@citrix.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

T24gMDIvMTkvMjAxMyAxMTo0NyBBTSwgQW5kcmV3IENvb3BlciB3cm90ZToKPiBPbiAxOS8wMi8x
MyAwOToyOCwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+IE9uIDE4LjAyLjEzIGF0IDE5OjExLCBB
bmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPiB3cm90ZToKPj4+IEhlbGxv
LAo+Pj4KPj4+IE91ciB0ZXN0aW5nIGhhcyBkaXNjb3ZlcmVkIGEgY3Jhc2ggKHBhZ2VmYXVsdCBh
dCAweDAwMDAwMDAwMDAwMDAwMDgpCj4+PiB3aGljaCBJIGhhdmUgdHJhY2tlZCBkb3duIHRvIGJh
ZCBfX3J1bnFfcmVtb3ZlKCkgaW4gY3NjaGVkX3ZjcHVfc2xlZXAoKQo+Pj4gaW4gc2NoZWRfY3Jl
ZGl0LmMgKGJlY2F1c2UgYSBzdGF0aWMgZnVuY3Rpb24gb2YgdGhlIHNhbWUgbmFtZSBhbHNvCj4+
PiBleGlzdHMgaW4gc2NoZWRfY3JlZGl0Mi5jLCB3aGljaCBjb25mdXNlZCBtYXR0ZXJzIHRvIHN0
YXJ0IHdpdGgpCj4+Pgo+Pj4gVGhlIHRlc3QgY2FzZSB3YXMgYSBsb29wIG9mIGxvY2FsaG9zdCBt
aWdyYXRlIG9mIGEgMXZjcHUgSFZNIHdpbjgKPj4+IGRvbWFpbi4gIFRoZSB0ZXN0IGNhc2UgaXRz
ZWxmIGhhcyBwYXNzZWQgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCBvbiB0aGUKPj4+IHNhbWUgWGVu
IGNvZGViYXNlIChYZW4tNC4xLjMpLCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdmVyeSByYXJlLiAg
VGhlcmUKPj4+IGRvZXMgbm90IGFwcGVhciB0byBiZSBhbnkgcmVsZXZhbnQgY2hhbmdlcyBiZXR3
ZWVuIHRoZSB2ZXJzaW9uIG9mIFhlbiBpbgo+Pj4gdGhlIHRlc3QgYW5kIHhlbi00LjEtdGVzdGlu
Zy4KPj4+Cj4+PiBUaGUgZmFpbHVyZSBpdHNlbGYgaXMgYmVjYXVzZSBvZiBhIFhFTl9ET01DVExf
c2NoZWR1bGVyX29wICh0cmFjZSBiZWxvdykKPj4+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBW
Q1BVIG9mIHRoZSBtaWdyYXRpbmcgZG9tYWluLgo+Pj4KPj4+IChYRU4pIFhlbiBjYWxsIHRyYWNl
Ogo+Pj4gKFhFTikgICAgICAgWzxmZmZmODJjNDgwMTE2YTE0Pl0gY3NjaGVkX3ZjcHVfc2xlZXAr
MHg0NC8weDcwCj4+PiAoWEVOKSAgICAgIDBbPGZmZmY4MmM0ODAxMjAxMTc+XSB2Y3B1X3NsZWVw
X25vc3luYysweGU3LzB4M2IwCj4+PiAoWEVOKSAgICAgMTJbPGZmZmY4MmM0ODAxMjAzZTk+XSB2
Y3B1X3NsZWVwX3N5bmMrMHg5LzB4NTAKPj4+IChYRU4pICAgICAxNFs8ZmZmZjgyYzQ4MDExZmQ0
Yz5dIHNjaGVkX2FkanVzdCsweGFjLzB4MjMwCj4+PiAoWEVOKSAgICAgMjRbPGZmZmY4MmM0ODAx
MDJiYzE+XSBkb19kb21jdGwrMHg3MzEvMHgxMTMwCj4+PiAoWEVOKSAgICAgNjRbPGZmZmY4MmM0
ODAyMDEzYzQ+XSBjb21wYXRfaHlwZXJjYWxsKzB4NzQvMHg4MAo+Pj4KPj4+IFRoZSByZWxldmFu
dCBwYXJ0IG9mIGNzY2hlZF92Y3B1X3NsZWVwKCkgaXMKPj4+Cj4+PiAgICAgIGVsc2UgaWYgKCBf
X3ZjcHVfb25fcnVucShzdmMpICkKPj4+ICAgICAgICAgIF9fcnVucV9yZW1vdmUoc3ZjKTsKPj4+
Cj4+PiB3aGljaCBkaXNhc3NlbWJsZXMgdG8KPj4+Cj4+PiBmZmZmODJjNDgwMTE2YTAxOiAgICAg
ICA0OSA4YiAxMCAgICAgICAgICAgICAgICBtb3YgICAgKCVyOCksJXJkeAo+Pj4gZmZmZjgyYzQ4
MDExNmEwNDogICAgICAgNGMgMzkgYzIgICAgICAgICAgICAgICAgY21wICAgICVyOCwlcmR4Cj4+
PiBmZmZmODJjNDgwMTE2YTA3OiAgICAgICA3NSAwNyAgICAgICAgICAgICAgICAgICBqbmUgICAg
ZmZmZjgyYzQ4MDExNmExMAo+Pj4gPGNzY2hlZF92Y3B1X3NsZWVwKzB4NDA+Cj4+PiBmZmZmODJj
NDgwMTE2YTA5OiAgICAgICBmMyBjMyAgICAgICAgICAgICAgICAgICByZXB6IHJldHEKPj4+IGZm
ZmY4MmM0ODAxMTZhMGI6ICAgICAgIDBmIDFmIDQ0IDAwIDAwICAgICAgICAgIG5vcGwgICAweDAo
JXJheCwlcmF4LDEpCj4+PiBmZmZmODJjNDgwMTE2YTEwOiAgICAgICA0OSA4YiA0MCAwOCAgICAg
ICAgICAgICBtb3YgICAgMHg4KCVyOCksJXJheAo+Pj4gZmZmZjgyYzQ4MDExNmExNDogICAgICAg
NDggODkgNDIgMDggICAgICAgICAgICAgbW92ICAgICVyYXgsMHg4KCVyZHgpICMKPj4+IDwtIFBh
Z2VmYXVsdCBoZXJlCj4+PiBmZmZmODJjNDgwMTE2YTE4OiAgICAgICA0OCA4OSAxMCAgICAgICAg
ICAgICAgICBtb3YgICAgJXJkeCwoJXJheCkKPj4+IGZmZmY4MmM0ODAxMTZhMWI6ICAgICAgIDRk
IDg5IDQwIDA4ICAgICAgICAgICAgIG1vdiAgICAlcjgsMHg4KCVyOCkKPj4+IGZmZmY4MmM0ODAx
MTZhMWY6ICAgICAgIDRkIDg5IDAwICAgICAgICAgICAgICAgIG1vdiAgICAlcjgsKCVyOCkKPj4+
Cj4+PiBUaGUgcmVsZXZhbnQgY3Jhc2ggcmVnaXN0ZXJzIGZyb20gdGhlIHBhZ2VmYXVsdCBhcmU6
Cj4+PiByYXg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+IHJkeDogMDAwMDAwMDAwMDAwMDAwMAo+Pj4g
ICByODogZmZmZjgzMDgwYzg5ZWQ5MAo+Pj4KPj4+IElmIEkgYW0gcmVhZGluZyB0aGUgY29kZSBj
b3JyZWN0bHksIHRoaXMgbWVhbnMgdGhhdCBydW5xLT5uZXh0IGlzIE5VTEwsCj4+PiBzbyB3ZSBm
YWlsIGxpc3RfZW1wdHkoKSBhbmQgZXJyb25lb3VzbHkgcGFzcyBfX3ZjcHVfb25fcnVucSgpLiAg
V2UgdGhlbgo+Pj4gZmFpbCB3aXRoIGEgZmF1bHQgd2hlbiB0cnlpbmcgdG8gdXBkYXRlIHJ1bnEt
PnByZXYsIHdoaWNoIGlzIGFsc28gTlVMTC4KPj4+Cj4+PiBUaGUgb25seSBwbGFjZSBJIGNhbiBz
cG90IGluIHRoZSBjb2RlIHdoZXJlIHRoZSBydW5xLT57bmV4dCxwcmV2fSBjb3VsZAo+Pj4gY29u
Y2VpdmFibHkgYmUgTlVMTCBpcyBpbiBjc2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBt
ZW1zZXQoKSBhbmQKPj4+IElOSVRfTElTVF9IRUFEKCkuICBUaGlzIGlzIGxvZ2ljYWxseSBzZW5z
aWJsZSBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZQo+Pj4gbG9jYWxob3N0IG1pZ3JhdGUgbG9vcCwg
YW5kIEkgY2FudCBpbW1lZGlhdGVseSBzZWUgYW55dGhpbmcgdG8gcHJldmVudAo+Pj4gdGhpcyBy
YWNlIGhhcHBlbmluZy4KPj4gQnV0IHRoYXQgZG9lc24ndCBtYWtlIHNlbnNlOiBjc2NoZWRfYWxs
b2NfdmRhdGEoKSBkb2Vzbid0IHN0b3JlCj4+IHN2YyBpbnRvIHZjLT5zY2hlZF9wcml2OyB0aGF0
J3MgYmVpbmcgZG9uZSBieSB0aGUgZ2VuZXJpYwo+PiBzY2hlZHVsZXIgY29kZSBvbmNlIHRoZSBh
Y3RvciByZXR1cm5zLgo+Cj4gRCdvaCB5ZXMgLSBJIG92ZXJsb29rZWQgdGhhdC4KPgo+Pgo+PiBT
byBJJ2QgcmF0aGVyIHN1c3BlY3QgYSBzdGFsZSBwb2ludGVyIGJlaW5nIHVzZWQsIHdoaWNoIGlz
IGVhc2lseQo+PiBwb3NzaWJsZSB3aGVuIHJhY2luZyB3aXRoIHNjaGVkX21vdmVfZG9tYWluKCkg
KGFzIG9wcG9zZWQgdG8KPj4gc2NoZWR1bGVfY3B1X3N3aXRjaCgpLCB3aGVyZSB0aGUgbmV3IHBv
aW50ZXIgZ2V0cyBzdG9yZWQKPj4gX2JlZm9yZV8gZGUtYWxsb2NhdGluZyB0aGUgb2xkIG9uZSku
Cj4KPj4KPj4gSG93ZXZlciwgc2NoZWRfbW92ZV9kb21haW4oKSAoYXMgd2VsbCBhcyBzY2hlZHVs
ZV9jcHVfc3dpdGNoKCkpCj4+IGdldCBjYWxsZWQgb25seSBmcm9tIENQVSBwb29scyBjb2RlLCBh
bmQgSSB3b3VsZCBndWVzcyBDUFUgcG9vbHMKPj4gYXJlbid0IGludm9sdmVkIGhlcmUsIGFuZCB5
b3UgZG9uJ3QgaW4gcGFyYWxsZWwgc29mdCBvZmZsaW5lL29ubGluZQo+PiBwQ1BVLXMgKGFzIEkn
bSBzdXJlIHlvdSBvdGhlcndpc2Ugd291bGQgaGF2ZSBtZW50aW9uZWQgaXQpLgo+Pgo+PiBCdXQg
d2FpdCAtIGxpYnhsX19kb21haW5fbWFrZSgpIF91bmNvbmRpdGlvbmFsbHlfIGNhbGxzCj4+IHhj
X2NwdXBvb2xfbW92ZWRvbWFpbigpLCBhcyBkb2VzIFhlbmREb21haW5JbmZvJ3MKPj4gX2NvbnN0
cnVjdERvbWFpbigpLiBUaGUgcmVhc29uIGZvciB0aGlzIGVzY2FwZXMgbWUgLSBKw7xyZ2VuPyBZ
ZXQKPj4gSSdkIGV4cGVjdCB0aGUgcG9vbCBJRCBtYXRjaGluZyBjaGVjayB0byBzaG9ydCBjdXQg
dGhlIHJlc3VsdGluZwo+PiBzeXNjdGwsIGkuZS4gc2NoZWRfbW92ZV9kb21haW4oKSBvdWdodCB0
byBub3QgYmUgcmVhY2hlZCBhbnl3YXkKPj4gKHdvcnRoIHZlcmlmeWluZyBvZiBjb3Vyc2UpLgo+
Pgo+PiBUaGUgcmFjZSB0aGVyZSBuZXZlcnRoZWxlc3Mgb3VnaHQgdG8gYmUgZml4ZWQuCj4+Cj4+
IEphbgo+Cj4gT3VyIHRvb2xzdGFjayBob29rcyBkaXJlY3RseSBpbnRvIGxpYnhjIGFuZCBpcyBj
b21wbGV0ZWx5IGlnbm9yYW50IG9mCj4gY3B1cG9vbHMuICBMb29raW5nIGF0IHRoZSBjcmFzaCBt
b3JlIGNsb3NlbHksIGl0IG1pZ2h0IGJlIGEgcmFjZSBlbHNld2hlcmUKPgo+IEFub3RoZXIgZG9t
MCB2Y3B1IGlzIGluIGFuIEhWTU9QX3RyYWNrX2RpcnR5X3ZyYW0gaHlwZXJjYWxsLCBhbmQgdGhl
Cj4gYXNzb2NpYXRlZCBYZW4gc3RhY2sgdHJhY2UgaXMKPgo+IFtmZmZmODJjNDgwMTc3N2IyXSB0
aW1lX2NhbGlicmF0aW9uX3N0ZF9yZW5kZXp2b3VzKzB4YjIvMHhjMAo+ICAgZmZmZjgyYzQ4MDE3
MmQxMiAgX19zbXBfY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQrMHg2Mi8weGIwCj4gICBmZmZmODJj
NDgwMTczMzllICBzbXBfY2FsbF9mdW5jdGlvbl9pbnRlcnJ1cHQrMHg0ZS8weDkwCj4gICBmZmZm
ODJjNDgwMTRhNjVhICBjYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDJhLzB4MzAKPiAgIGZmZmY4
MmM0ODAxMjIzYjIgIF9zcGluX2xvY2srMHgxMi8weDIwCj4gICBmZmZmODJjNDgwMTczNGFiICBm
bHVzaF9hcmVhX21hc2srMHhjYi8weDFjMAo+ICAgZmZmZjgyYzQ4MDFjODYyYSAgcGFnaW5nX2xv
Z19kaXJ0eV9yYW5nZSsweDNhLzB4NzgwCj4gICBmZmZmODJjNDgwMTIxZWE4ICBjcHVtYXNrX3Jh
aXNlX3NvZnRpcnErMHg3OC8weDgwCj4gICBmZmZmODJjNDgwMTE3ZWQzICBjc2NoZWRfdmNwdV93
YWtlKzB4MTkzLzB4NDIwCj4gICBmZmZmODJjNDgwMTRhNWZhICBldmVudF9jaGVja19pbnRlcnJ1
cHQrMHgyYS8weDMwCj4gICBmZmZmODJjNDgwMWYyMWM3ICBoYXBfdHJhY2tfZGlydHlfdnJhbSsw
eDEzNy8weDFjMAo+ICAgZmZmZjgyYzQ4MDFhZDNmZCAgZG9faHZtX29wKzB4MTZkZC8weDFmNTAK
PiAgIGZmZmY4MmM0ODAxMDYyNTEgIGV2dGNobl9zZW5kKzB4YTEvMHgxNjAKPiAgIGZmZmY4MmM0
ODAxMDZkMzYgIGRvX2V2ZW50X2NoYW5uZWxfb3ArMHg4NzYvMHhmZDAKPiAgIGZmZmY4MmM0ODAx
ZjkwMjcgIGNvbXBhdF91cGRhdGVfZGVzY3JpcHRvcisweDI3LzB4MzAKPiAgIGZmZmY4MmM0ODAx
MzU0ZjggIGNvbXBhdF9tdWx0aWNhbGwrMHgxOTgvMHgzODAKPiAgIGZmZmY4MmM0ODAxNGE1ZmEg
IGV2ZW50X2NoZWNrX2ludGVycnVwdCsweDJhLzB4MzAKPiAgIGZmZmY4MmM0ODAyMDEzYzQgIGNv
bXBhdF9oeXBlcmNhbGwrMHg3NC8weDgwCj4KPiB0aGUgaGFwX3RyYWNrX2RpcnR5X3ZyYW0oKSBh
bmQgcGFnaW5nX2xvZ19kaXJ0eV9yYW5nZSgpIGFyZSBwYXJ0IG9mIHRoZQo+IHNhbWUgbG9naWNh
bCBjYWxsIHRyYWNlLCBidXQgaXQgYXBwZWFycyB0aGF0IHdlIGhhdmUgdGFrZW4gYW4KPiBldmVu
dF9jaGVja19pbnRlcnJ1cHQoKSBpbiB0aGUgbWlkZGxlIGFuZCBjYWxsZWQgc2NoZWR1bGUoKSBv
ZmYgdGhlCj4gYm90dG9tIG9mIGl0LCBjYWxsaW5nIGNzY2hlZF92Y3B1X3dha2UoKS4KPgo+IEkg
YW0gY3VycmVudGx5IHRyeWluZyB0byByZWFzb24gYXMgdG8gd2hldGhlciBpdCBpcyBwb3NzaWJs
ZSBmb3IgYSByYWNlCj4gYmV0d2VlbiBjc2NoZWRfdmNwdV97c2xlZXAsd2FrZX0oKSBjb3VsZCBy
ZXN1bHQgaW4gdGhlIHNlZW4gY3Jhc2gsIGJ1dAo+IGl0IGNlcnRhaW5seSBsb29rcyBsaWtlIGEg
c21va2luZyBndW4uCgpBbnkgbW9yZSBwcm9ncmVzcyBvbiB0aGlzIG9uZT8KCkluIHRoZW9yeSBh
bGwgb2YgdGhvc2Ugc2hvdWxkIGJlIG1hZGUgbXV0dWFsbHkgZXhjbHVzaXZlIGJ5IGhvbGRpbmcg
dGhlIApsb2NrIG9mIHRoZSBydW5xdWV1ZSBvbiB3aGljaCB0aGUgVkNQVSBpcyBydW5uaW5nLgoK
QW55IGNoYW5jZSB0aGVyZSdzIGEgcmFjZSB3aXRoIHRoZSBhc3NpZ25tZW50IG9mIHRoZSB2Y3B1
IC0tIHRoYXQgaXMsIGEgCnJhY2UgaW4gdmNwdV9zY2hlZHVsZV9sb2NrKCkgc3VjaCB0aGF0IHNv
bWVvbmUgZW5kcyB1cCBncmFiYmluZyB0aGUgCndyb25nIGxvY2s/CgpJIHRoaW5rIHRoYXQgaW4g
dGhlb3J5IG9uY2UgeW91IGNhbGwgSU5JVF9MSVNUX0hFQUQsIG5vbmUgb2YgdGhvc2UgCnBvaW50
ZXJzIHNob3VsZCBldmVyIGJlIHNldCB0byB6ZXJvOyBpZiBvbmUgZXZlciB3ZXJlIGl0IG1pZ2h0
IGdldCAKcGFzc2VkIGFyb3VuZCBhIGJpdCBiZWZvcmUgYWN0dWFsbHkgYmVpbmcgZm9sbG93ZWQu
ICBBbnkgY2hhbmNlIHRoZXJlJ3MgCnNvbWV0aGluZyB1bmluaXRpYWxpemVkIHNvbWV3aGVyZT8K
CkFuZCBvZiBjb3Vyc2UsIGlmIGFsbCBlbHNlIGZhaWxzLCB0aGVyZSdzIGdvb2Qgb2xkLWZhc2hp
b25lZCBtZW1vcnkgCmNsb2JiZXJpbmcgYXMgYSBwb3NzaWJpbGl0eS4uLgoKICAtR2VvcmdlCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:23:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:23: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 1UAJYU-0006sf-TV; Tue, 26 Feb 2013 12:22:46 +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 1UAJYT-0006sZ-Hm
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:22:45 +0000
Received: from [85.158.139.83:4999] by server-14.bemta-5.messagelabs.com id
	CF/18-13158-419AC215; Tue, 26 Feb 2013 12:22:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361881358!21794316!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12020 invoked from network); 26 Feb 2013 12:22:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:22:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1897268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 12:22: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.297.1; Tue, 26 Feb 2013 12:22:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAJYM-0007Ck-0s; Tue, 26 Feb 2013 12:22:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAJYL-0001Sl-TM;
	Tue, 26 Feb 2013 12:22:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.43277.818583.404109@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 12:22:37 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361873566.26546.249.camel@zakaz.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
	<512C944A02000078000C1027@nat28.tlf.novell.com>
	<1361873566.26546.249.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL"):
> I'll commit in about half an hour unless someone objects.

I've done 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 Feb 26 12:23:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:23: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 1UAJYU-0006sf-TV; Tue, 26 Feb 2013 12:22:46 +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 1UAJYT-0006sZ-Hm
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:22:45 +0000
Received: from [85.158.139.83:4999] by server-14.bemta-5.messagelabs.com id
	CF/18-13158-419AC215; Tue, 26 Feb 2013 12:22:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361881358!21794316!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12020 invoked from network); 26 Feb 2013 12:22:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:22:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1897268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 12:22: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.297.1; Tue, 26 Feb 2013 12:22:38 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAJYM-0007Ck-0s; Tue, 26 Feb 2013 12:22:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAJYL-0001Sl-TM;
	Tue, 26 Feb 2013 12:22:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.43277.818583.404109@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 12:22:37 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361873566.26546.249.camel@zakaz.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
	<512C944A02000078000C1027@nat28.tlf.novell.com>
	<1361873566.26546.249.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL"):
> I'll commit in about half an hour unless someone objects.

I've done 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 Feb 26 12:24:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJZn-0006xU-Cf; Tue, 26 Feb 2013 12:24: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 1UAJZm-0006xN-6r
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:24:06 +0000
Received: from [85.158.138.51:42679] by server-16.bemta-3.messagelabs.com id
	E2/76-02727-569AC215; Tue, 26 Feb 2013 12:24:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361881443!19511161!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1536 invoked from network); 26 Feb 2013 12:24:04 -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;
	26 Feb 2013 12:24:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9649620"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:24:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:24:02 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UAJZi-0004iJ-6S;
	Tue, 26 Feb 2013 12:24:02 +0000
Message-ID: <1361881287.7099.0.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 26 Feb 2013 12:21:27 +0000
In-Reply-To: <512CA3D3.3040002@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
> On 26/02/13 11:52, Tim Deegan wrote:
> > How about ASSERT(((typeof credits) val) == val) before the assignment?

Why not just
	ASSERT(credits == val); /* Ensure we haven't truncated val */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:24:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJZn-0006xU-Cf; Tue, 26 Feb 2013 12:24: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 1UAJZm-0006xN-6r
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:24:06 +0000
Received: from [85.158.138.51:42679] by server-16.bemta-3.messagelabs.com id
	E2/76-02727-569AC215; Tue, 26 Feb 2013 12:24:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361881443!19511161!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1536 invoked from network); 26 Feb 2013 12:24:04 -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;
	26 Feb 2013 12:24:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9649620"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:24:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:24:02 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UAJZi-0004iJ-6S;
	Tue, 26 Feb 2013 12:24:02 +0000
Message-ID: <1361881287.7099.0.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 26 Feb 2013 12:21:27 +0000
In-Reply-To: <512CA3D3.3040002@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
> On 26/02/13 11:52, Tim Deegan wrote:
> > How about ASSERT(((typeof credits) val) == val) before the assignment?

Why not just
	ASSERT(credits == val); /* Ensure we haven't truncated val */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:26:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:26: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 1UAJbu-00076F-UD; Tue, 26 Feb 2013 12:26: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 1UAJbt-000768-PO
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:26:18 +0000
Received: from [85.158.143.99:29372] by server-3.bemta-4.messagelabs.com id
	B0/10-02186-9E9AC215; Tue, 26 Feb 2013 12:26:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361881575!21661811!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5359 invoked from network); 26 Feb 2013 12:26:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:26:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1897465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 12:26: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.297.1; Tue, 26 Feb 2013 12:26:15 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAJbr-0007Kf-1Y;
	Tue, 26 Feb 2013 12:26:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAJbr-0000Rc-14;
	Tue, 26 Feb 2013 12:26:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16701-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:26:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16701: regressions - trouble:
	blocked/fail/pass/preparing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 16701 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16701/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  2 hosts-allocate        running [st=running!]
 test-amd64-amd64-xl-sedf      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-sedf-pin  2 hosts-allocate           running [st=running!]
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-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-xl-multivcpu  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            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-qemut-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 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-qemut-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-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-qemut-rhel6hvm-intel  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-xl-qemut-win7-amd64  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-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  642087032876b8805d8d645a6fbbe8a71ed0ef15
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                              preparing
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-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-amd64-amd64-xl-sedf-pin                                 preparing
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     preparing
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 642087032876b8805d8d645a6fbbe8a71ed0ef15
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Feb 25 16:45:14 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:26:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:26: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 1UAJbu-00076F-UD; Tue, 26 Feb 2013 12:26: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 1UAJbt-000768-PO
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:26:18 +0000
Received: from [85.158.143.99:29372] by server-3.bemta-4.messagelabs.com id
	B0/10-02186-9E9AC215; Tue, 26 Feb 2013 12:26:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1361881575!21661811!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5359 invoked from network); 26 Feb 2013 12:26:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:26:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1897465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 12:26: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.297.1; Tue, 26 Feb 2013 12:26:15 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAJbr-0007Kf-1Y;
	Tue, 26 Feb 2013 12:26:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAJbr-0000Rc-14;
	Tue, 26 Feb 2013 12:26:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16701-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:26:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16701: regressions - trouble:
	blocked/fail/pass/preparing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 16701 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16701/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel  2 hosts-allocate        running [st=running!]
 test-amd64-amd64-xl-sedf      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-sedf-pin  2 hosts-allocate           running [st=running!]
 build-i386                    4 xen-build                 fail REGR. vs. 16226
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-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-xl-multivcpu  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            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-qemut-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 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-qemut-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-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-qemut-rhel6hvm-intel  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-xl-qemut-win7-amd64  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-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  642087032876b8805d8d645a6fbbe8a71ed0ef15
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                              preparing
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-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-amd64-amd64-xl-sedf-pin                                 preparing
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     preparing
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 642087032876b8805d8d645a6fbbe8a71ed0ef15
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Feb 25 16:45:14 2013 +0000

    QEMU_TAG update
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:35:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJk7-0007PQ-5h; Tue, 26 Feb 2013 12:34: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 1UAJk5-0007PL-RZ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:34:45 +0000
Received: from [85.158.139.83:28017] by server-6.bemta-5.messagelabs.com id
	DC/D7-21466-4EBAC215; Tue, 26 Feb 2013 12:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361881908!26268418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22659 invoked from network); 26 Feb 2013 12:31:49 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:31:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9651071"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:29:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:29:48 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UAJfI-0004mq-Fm;
	Tue, 26 Feb 2013 12:29:48 +0000
Message-ID: <1361881634.7099.1.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:27:14 +0000
In-Reply-To: <20780.43277.818583.404109@mariner.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
	<512C944A02000078000C1027@nat28.tlf.novell.com>
	<1361873566.26546.249.camel@zakaz.uk.xensource.com>
	<20780.43277.818583.404109@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 Tue, 2013-02-26 at 12:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL"):
> > I'll commit in about half an hour unless someone objects.
> 
> I've done this.

Thanks I got tied up in a meeting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:35:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAJk7-0007PQ-5h; Tue, 26 Feb 2013 12:34: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 1UAJk5-0007PL-RZ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:34:45 +0000
Received: from [85.158.139.83:28017] by server-6.bemta-5.messagelabs.com id
	DC/D7-21466-4EBAC215; Tue, 26 Feb 2013 12:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361881908!26268418!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22659 invoked from network); 26 Feb 2013 12:31:49 -0000
Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:31:49 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9651071"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:29:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:29:48 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UAJfI-0004mq-Fm;
	Tue, 26 Feb 2013 12:29:48 +0000
Message-ID: <1361881634.7099.1.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:27:14 +0000
In-Reply-To: <20780.43277.818583.404109@mariner.uk.xensource.com>
References: <CD4E9E36.4C83D%keir.xen@gmail.com>
	<1361783984.26546.160.camel@zakaz.uk.xensource.com>
	<1361869609.11431.26.camel@dagon.hellion.org.uk>
	<512C944A02000078000C1027@nat28.tlf.novell.com>
	<1361873566.26546.249.camel@zakaz.uk.xensource.com>
	<20780.43277.818583.404109@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16231: 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 Tue, 2013-02-26 at 12:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL"):
> > I'll commit in about half an hour unless someone objects.
> 
> I've done this.

Thanks I got tied up in a meeting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:38:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:38: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 1UAJnj-0007Vg-Qf; Tue, 26 Feb 2013 12:38:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1UAJni-0007VZ-VJ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:38:31 +0000
Received: from [85.158.139.83:3350] by server-4.bemta-5.messagelabs.com id
	70/C1-01980-5CCAC215; Tue, 26 Feb 2013 12:38:29 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361882199!29263583!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10557 invoked from network); 26 Feb 2013 12:36:39 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted
	SMTP; 26 Feb 2013 12:36:39 -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 1UAJlt-0004fx-ET; Tue, 26 Feb 2013 13:36:37 +0100
Date: Tue, 26 Feb 2013 13:36:36 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130223011800.GA2465@phenom.dumpdata.com>
Message-ID: <alpine.LFD.2.02.1302261320120.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.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: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Regression introduced with
 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot
 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 Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> 
> I don't know if this is b/c the Xen code is missing something or
> expects something that never happend. I hadn't looked at your
> patch in any detail (was going to do that on Monday).
> 
> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
> this is I what get:
> [    0.133081] cpu 1 spinlock event irq 71
> [    0.134049] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
> [    0.205154] Brought up 2 CPUs
> [    0.205156] smpboot: Total of 2 processors activated (16021.74 BogoMIPS)
> 
> [   28.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
> [   28.134000] Modules linked in:
> [   28.134000] CPU 0 
> [   28.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
> [   28.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0

So the migration thread loops in stop_machine_cpu_stop(). Now the
interesting question is what work was scheduled for that cpu.

The main difference between the old code and the new one, is that the
thread is created earlier and not detroyed on cpu offline.

Could you add some instrumentation, so we can see what kind of cpu
stop work is scheduled and from where?

Thanks,

	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:38:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:38: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 1UAJnj-0007Vg-Qf; Tue, 26 Feb 2013 12:38:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1UAJni-0007VZ-VJ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:38:31 +0000
Received: from [85.158.139.83:3350] by server-4.bemta-5.messagelabs.com id
	70/C1-01980-5CCAC215; Tue, 26 Feb 2013 12:38:29 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361882199!29263583!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10557 invoked from network); 26 Feb 2013 12:36:39 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted
	SMTP; 26 Feb 2013 12:36:39 -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 1UAJlt-0004fx-ET; Tue, 26 Feb 2013 13:36:37 +0100
Date: Tue, 26 Feb 2013 13:36:36 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130223011800.GA2465@phenom.dumpdata.com>
Message-ID: <alpine.LFD.2.02.1302261320120.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.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: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Regression introduced with
 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot
 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 Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> 
> I don't know if this is b/c the Xen code is missing something or
> expects something that never happend. I hadn't looked at your
> patch in any detail (was going to do that on Monday).
> 
> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
> this is I what get:
> [    0.133081] cpu 1 spinlock event irq 71
> [    0.134049] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
> [    0.205154] Brought up 2 CPUs
> [    0.205156] smpboot: Total of 2 processors activated (16021.74 BogoMIPS)
> 
> [   28.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
> [   28.134000] Modules linked in:
> [   28.134000] CPU 0 
> [   28.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
> [   28.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0

So the migration thread loops in stop_machine_cpu_stop(). Now the
interesting question is what work was scheduled for that cpu.

The main difference between the old code and the new one, is that the
thread is created earlier and not detroyed on cpu offline.

Could you add some instrumentation, so we can see what kind of cpu
stop work is scheduled and from where?

Thanks,

	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:44:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:44: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 1UAJtL-0007qG-70; Tue, 26 Feb 2013 12:44: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 1UAJtJ-0007q9-KE
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:44:17 +0000
Received: from [85.158.139.211:8658] by server-12.bemta-5.messagelabs.com id
	74/F8-11486-02EAC215; Tue, 26 Feb 2013 12:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361882656!18390349!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12005 invoked from network); 26 Feb 2013 12:44:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1898320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 12: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.297.1; Tue, 26 Feb 2013 12:44:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAJtH-0007Q6-T2;
	Tue, 26 Feb 2013 12:44:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAJtH-0005eL-RW;
	Tue, 26 Feb 2013 12:44:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16697-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:44:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16697: 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 16697 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16697/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:44:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:44: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 1UAJtL-0007qG-70; Tue, 26 Feb 2013 12:44: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 1UAJtJ-0007q9-KE
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:44:17 +0000
Received: from [85.158.139.211:8658] by server-12.bemta-5.messagelabs.com id
	74/F8-11486-02EAC215; Tue, 26 Feb 2013 12:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361882656!18390349!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12005 invoked from network); 26 Feb 2013 12:44:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 12:44:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1898320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 12: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.297.1; Tue, 26 Feb 2013 12:44:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAJtH-0007Q6-T2;
	Tue, 26 Feb 2013 12:44:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAJtH-0005eL-RW;
	Tue, 26 Feb 2013 12:44:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16697-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:44:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16697: 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 16697 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16697/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:45:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:45: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 1UAJuW-0007uP-Lw; Tue, 26 Feb 2013 12:45:32 +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 1UAJuV-0007uD-5s
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:45:31 +0000
Received: from [193.109.254.147:34613] by server-8.bemta-14.messagelabs.com id
	B5/60-17325-A6EAC215; Tue, 26 Feb 2013 12:45:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361882140!4596723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5482 invoked from network); 26 Feb 2013 12:35:45 -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;
	26 Feb 2013 12:35:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9652307"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:35:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:35:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAJkx-0004rZ-SX;
	Tue, 26 Feb 2013 12:35:39 +0000
Message-ID: <1361882139.2109.52.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Tue, 26 Feb 2013 12:35:39 +0000
In-Reply-To: <512C5B96.10204@oracle.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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 Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> 
> On 2013-2-16 0:00, Wei Liu wrote:
> > Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> > ---
> >   drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
> >   1 file changed, 174 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 8bd75a1..de73a71 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -67,9 +67,19 @@ struct netfront_cb {
> >
> >   #define GRANT_INVALID_REF   0
> >
> > -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> > -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> > -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> > +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> > +#define XENNET_MAX_RING_PAGES      (1U<<  XENNET_MAX_RING_PAGE_ORDER)
> > +
> > +
> > +#define NET_TX_RING_SIZE(_nr_pages)                  \
> > +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> > +#define NET_RX_RING_SIZE(_nr_pages)                  \
> > +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> > +
> > +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +
> > +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> 
> Not using multi-page ring here?
> In xennet_create_dev, gnttab_alloc_grant_references allocates
> TX_MAX_TARGET number of grant reference for tx. In
> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> skb_entry_is_link helps to not release invalid grants, lots of null loop
> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> variableconnected with np->tx_ring_pages. Or you intended to use one
> page ring here?
> 

Looking back my history, this limitation was introduced because if we
have a multi-page backend and single page frontend, the backend skb
processing could overlap.

I agree with you that this limit should be variable, but as we still use
M:N model, the safe option is to cap this limit to 1 page.

Another option is to check validity of skbs before processing them. I
will look into that as well.

The same reason applies to the RX ring as well.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:45:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:45: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 1UAJuW-0007uP-Lw; Tue, 26 Feb 2013 12:45:32 +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 1UAJuV-0007uD-5s
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:45:31 +0000
Received: from [193.109.254.147:34613] by server-8.bemta-14.messagelabs.com id
	B5/60-17325-A6EAC215; Tue, 26 Feb 2013 12:45:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361882140!4596723!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5482 invoked from network); 26 Feb 2013 12:35:45 -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;
	26 Feb 2013 12:35:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9652307"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:35:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:35:40 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAJkx-0004rZ-SX;
	Tue, 26 Feb 2013 12:35:39 +0000
Message-ID: <1361882139.2109.52.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Tue, 26 Feb 2013 12:35:39 +0000
In-Reply-To: <512C5B96.10204@oracle.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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 Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> 
> On 2013-2-16 0:00, Wei Liu wrote:
> > Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> > ---
> >   drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
> >   1 file changed, 174 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 8bd75a1..de73a71 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -67,9 +67,19 @@ struct netfront_cb {
> >
> >   #define GRANT_INVALID_REF   0
> >
> > -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> > -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> > -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> > +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> > +#define XENNET_MAX_RING_PAGES      (1U<<  XENNET_MAX_RING_PAGE_ORDER)
> > +
> > +
> > +#define NET_TX_RING_SIZE(_nr_pages)                  \
> > +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> > +#define NET_RX_RING_SIZE(_nr_pages)                  \
> > +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> > +
> > +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +
> > +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> 
> Not using multi-page ring here?
> In xennet_create_dev, gnttab_alloc_grant_references allocates
> TX_MAX_TARGET number of grant reference for tx. In
> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> skb_entry_is_link helps to not release invalid grants, lots of null loop
> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> variableconnected with np->tx_ring_pages. Or you intended to use one
> page ring here?
> 

Looking back my history, this limitation was introduced because if we
have a multi-page backend and single page frontend, the backend skb
processing could overlap.

I agree with you that this limit should be variable, but as we still use
M:N model, the safe option is to cap this limit to 1 page.

Another option is to check validity of skbs before processing them. I
will look into that as well.

The same reason applies to the RX ring as well.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:51:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:51: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 1UAK02-0008IJ-Fk; Tue, 26 Feb 2013 12:51: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 1UAK01-0008IE-Hw
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:51:13 +0000
Received: from [85.158.138.51:19773] by server-7.bemta-3.messagelabs.com id
	C4/CC-10367-0CFAC215; Tue, 26 Feb 2013 12:51:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361883071!10598548!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4745 invoked from network); 26 Feb 2013 12:51:12 -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; 26 Feb 2013 12:51:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 12:51:11 +0000
Message-Id: <512CBDCD02000078000C1122@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 12:51:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Ian Campbell" <ian.campbell@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
In-Reply-To: <1361881287.7099.0.camel@hastur.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:21, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
>> On 26/02/13 11:52, Tim Deegan wrote:
>> > How about ASSERT(((typeof credits) val) == val) before the assignment?
> 
> Why not just
> 	ASSERT(credits == val); /* Ensure we haven't truncated val */

I.e. just want em to add a comment? That's certainly fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:51:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:51: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 1UAK02-0008IJ-Fk; Tue, 26 Feb 2013 12:51: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 1UAK01-0008IE-Hw
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:51:13 +0000
Received: from [85.158.138.51:19773] by server-7.bemta-3.messagelabs.com id
	C4/CC-10367-0CFAC215; Tue, 26 Feb 2013 12:51:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1361883071!10598548!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4745 invoked from network); 26 Feb 2013 12:51:12 -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; 26 Feb 2013 12:51:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 12:51:11 +0000
Message-Id: <512CBDCD02000078000C1122@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 12:51:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Ian Campbell" <ian.campbell@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
In-Reply-To: <1361881287.7099.0.camel@hastur.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:21, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
>> On 26/02/13 11:52, Tim Deegan wrote:
>> > How about ASSERT(((typeof credits) val) == val) before the assignment?
> 
> Why not just
> 	ASSERT(credits == val); /* Ensure we haven't truncated val */

I.e. just want em to add a comment? That's certainly fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:56:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:56: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 1UAK4X-0008S9-9s; Tue, 26 Feb 2013 12:55: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 1UAK4W-0008S2-LW
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:55:52 +0000
Received: from [85.158.138.51:61513] by server-8.bemta-3.messagelabs.com id
	65/54-25687-7D0BC215; Tue, 26 Feb 2013 12:55:51 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361883314!23848340!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 486 invoked from network); 26 Feb 2013 12:55:16 -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;
	26 Feb 2013 12:55:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9179766"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:54:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:54:14 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAK2w-00055t-Ge;
	Tue, 26 Feb 2013 12:54:14 +0000
Message-ID: <512CB075.7050202@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:54:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
In-Reply-To: <1361881287.7099.0.camel@hastur.hellion.org.uk>
Cc: Dario Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/26/2013 12:21 PM, Ian Campbell wrote:
> On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
>> On 26/02/13 11:52, Tim Deegan wrote:
>>> How about ASSERT(((typeof credits) val) == val) before the assignment?
>
> Why not just
> 	ASSERT(credits == val); /* Ensure we haven't truncated val */

I prefer this one to having "typeof credits" in the ASSERT.  The main 
thing is just to minimize the amount of effort a programmer has to 
expend trying to figure out what's going on, so he can spend it on 
something else. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:56:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:56: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 1UAK4X-0008S9-9s; Tue, 26 Feb 2013 12:55: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 1UAK4W-0008S2-LW
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:55:52 +0000
Received: from [85.158.138.51:61513] by server-8.bemta-3.messagelabs.com id
	65/54-25687-7D0BC215; Tue, 26 Feb 2013 12:55:51 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361883314!23848340!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 486 invoked from network); 26 Feb 2013 12:55:16 -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;
	26 Feb 2013 12:55:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9179766"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:54:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:54:14 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAK2w-00055t-Ge;
	Tue, 26 Feb 2013 12:54:14 +0000
Message-ID: <512CB075.7050202@eu.citrix.com>
Date: Tue, 26 Feb 2013 12:54:13 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
In-Reply-To: <1361881287.7099.0.camel@hastur.hellion.org.uk>
Cc: Dario Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/26/2013 12:21 PM, Ian Campbell wrote:
> On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
>> On 26/02/13 11:52, Tim Deegan wrote:
>>> How about ASSERT(((typeof credits) val) == val) before the assignment?
>
> Why not just
> 	ASSERT(credits == val); /* Ensure we haven't truncated val */

I prefer this one to having "typeof credits" in the ASSERT.  The main 
thing is just to minimize the amount of effort a programmer has to 
expend trying to figure out what's going on, so he can spend it on 
something else. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:58:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAK6v-00009J-TI; Tue, 26 Feb 2013 12:58:21 +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 1UAK6v-00009C-1t
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:58:21 +0000
Received: from [193.109.254.147:61583] by server-13.bemta-14.messagelabs.com
	id 8C/DF-30639-C61BC215; Tue, 26 Feb 2013 12:58:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361883498!9099096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3519 invoked from network); 26 Feb 2013 12:58:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 12:58:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 12:57:23 +0000
Message-Id: <512CBF3E02000078000C1136@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 12:57:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-16690-mainreport@xen.org>
In-Reply-To: <osstest-16690-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 16690: 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 26.02.13 at 12:11, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 16690 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16690/ 
> 
> 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. 16228
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 16228

The kernel build didn't even start when these failed, yet the
real reason for the failure also isn't clear to me. Trying to glue
together the matching pieces, I think is goes like this:

make[2]: Entering directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
set -e ; \
	if [ ! -e linux-2.6.18-xen.hg/.hg ] ; then \
	    __repo=http://xenbits.xen.org/linux-2.6.18-xen.hg ; \
	    if [ -d ${__repo} ] ; then \
	        echo "Linking ${__repo} to linux-2.6.18-xen.hg." ; \
	        ln -s ${__repo} linux-2.6.18-xen.hg ; \
	    else \
	        echo "Cloning ${__repo} to linux-2.6.18-xen.hg." ; \
	        hg clone ${__repo#file://} linux-2.6.18-xen.hg ; \
	    fi ; \
	else \
	    __parent=$(hg -R linux-2.6.18-xen.hg path default) ; \
	    echo "Pulling changes from ${__parent} into linux-2.6.18-xen.hg." ; \
	    hg -R linux-2.6.18-xen.hg pull ${__parent} ; \
	fi
Cloning http://xenbits.xen.org/linux-2.6.18-xen.hg to linux-2.6.18-xen.hg.
...
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: Connection reset by peer
make[2]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 255
make[1]: *** [linux-2.6-xen-install] Error 2
make: *** [install-kernels] Error 1
make[1]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'

The odd thing being that neither 4.1 nor master had similar
problems in their tests. Do we simply need to wait for another
run?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:58:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12: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 1UAK6v-00009J-TI; Tue, 26 Feb 2013 12:58:21 +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 1UAK6v-00009C-1t
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 12:58:21 +0000
Received: from [193.109.254.147:61583] by server-13.bemta-14.messagelabs.com
	id 8C/DF-30639-C61BC215; Tue, 26 Feb 2013 12:58:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361883498!9099096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3519 invoked from network); 26 Feb 2013 12:58:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 12:58:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 12:57:23 +0000
Message-Id: <512CBF3E02000078000C1136@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 12:57:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-16690-mainreport@xen.org>
In-Reply-To: <osstest-16690-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 16690: 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 26.02.13 at 12:11, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 16690 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16690/ 
> 
> 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. 16228
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 16228

The kernel build didn't even start when these failed, yet the
real reason for the failure also isn't clear to me. Trying to glue
together the matching pieces, I think is goes like this:

make[2]: Entering directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
set -e ; \
	if [ ! -e linux-2.6.18-xen.hg/.hg ] ; then \
	    __repo=http://xenbits.xen.org/linux-2.6.18-xen.hg ; \
	    if [ -d ${__repo} ] ; then \
	        echo "Linking ${__repo} to linux-2.6.18-xen.hg." ; \
	        ln -s ${__repo} linux-2.6.18-xen.hg ; \
	    else \
	        echo "Cloning ${__repo} to linux-2.6.18-xen.hg." ; \
	        hg clone ${__repo#file://} linux-2.6.18-xen.hg ; \
	    fi ; \
	else \
	    __parent=$(hg -R linux-2.6.18-xen.hg path default) ; \
	    echo "Pulling changes from ${__parent} into linux-2.6.18-xen.hg." ; \
	    hg -R linux-2.6.18-xen.hg pull ${__parent} ; \
	fi
Cloning http://xenbits.xen.org/linux-2.6.18-xen.hg to linux-2.6.18-xen.hg.
...
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: Connection reset by peer
make[2]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 255
make[1]: *** [linux-2.6-xen-install] Error 2
make: *** [install-kernels] Error 1
make[1]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'

The odd thing being that neither 4.1 nor master had similar
problems in their tests. Do we simply need to wait for another
run?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:59:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:59: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 1UAK7f-0000Ds-GY; Tue, 26 Feb 2013 12:59:07 +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 1UAK7e-0000Df-79
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:59:06 +0000
Received: from [193.109.254.147:65098] by server-7.bemta-14.messagelabs.com id
	8C/74-13581-991BC215; Tue, 26 Feb 2013 12:59:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361883502!4598228!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 545 invoked from network); 26 Feb 2013 12:58:24 -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;
	26 Feb 2013 12:58:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9658193"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:58:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:58:22 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAK6w-000592-14;
	Tue, 26 Feb 2013 12:58:22 +0000
Date: Tue, 26 Feb 2013 12:58:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Changes from v1:
> - Added on description that this make a build for testing only.
> - Improved add/remove of main service.
> 
> I reposted this patch after one year because I see recent
> interest of some users about complete Xen debian package.
> I also thinks like Stefano and Ian it's more important help to
> improve official package and make here only this small
> improvements.
> I'll done improvements of posts of one year ago except for
> remove of services that I think is useful but the main
> change for good testing deb are remove of version from name
> and add of conf file.
> I started testing experimental debian packages of qemu and
> seabios 2 months ago, I'll do the patch to integrate them
> into experimental xen package if no one will do it.
> So there will finally be complete xen even in official deb.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>  tools/misc/mkdeb |   30 ++++++++++++++++++++++++------
>  1 file changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 2e40747..fe7e1b1 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -33,7 +33,7 @@ fi
>  # 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
> @@ -41,15 +41,33 @@ Maintainer: Unmaintained snapshot
>  Section: admin
>  Priority: optional
>  Installed-Size: $(du -ks deb | cut -f1)
> -Description: Xen hypervisor and tools, version $version
> - This package contains the Xen hypervisor and associated tools, built
> - from a source tree.  It is not a fully packaged and supported Xen, just
> - the output of a xen "make dist" wrapped in a .deb to make it easy to
> - uninstall.
> +Description: Xen testing build, version $version
> + Warning: This is a custom testing build of Xen; it is not an
> + officially supported Debian package. Please not distribute.
> + It is just the output of a xen "make dist" wrapped in a .deb
> + to make it easy to update and 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
> +insserv -r xendomains &&
> +insserv -r xencommons
>  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

All the changes look good to me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 12:59:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 12:59: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 1UAK7f-0000Ds-GY; Tue, 26 Feb 2013 12:59:07 +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 1UAK7e-0000Df-79
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 12:59:06 +0000
Received: from [193.109.254.147:65098] by server-7.bemta-14.messagelabs.com id
	8C/74-13581-991BC215; Tue, 26 Feb 2013 12:59:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1361883502!4598228!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 545 invoked from network); 26 Feb 2013 12:58:24 -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;
	26 Feb 2013 12:58:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9658193"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 12:58:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 07:58:22 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAK6w-000592-14;
	Tue, 26 Feb 2013 12:58:22 +0000
Date: Tue, 26 Feb 2013 12:58:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
Message-ID: <alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
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>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Changes from v1:
> - Added on description that this make a build for testing only.
> - Improved add/remove of main service.
> 
> I reposted this patch after one year because I see recent
> interest of some users about complete Xen debian package.
> I also thinks like Stefano and Ian it's more important help to
> improve official package and make here only this small
> improvements.
> I'll done improvements of posts of one year ago except for
> remove of services that I think is useful but the main
> change for good testing deb are remove of version from name
> and add of conf file.
> I started testing experimental debian packages of qemu and
> seabios 2 months ago, I'll do the patch to integrate them
> into experimental xen package if no one will do it.
> So there will finally be complete xen even in official deb.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>  tools/misc/mkdeb |   30 ++++++++++++++++++++++++------
>  1 file changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 2e40747..fe7e1b1 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -33,7 +33,7 @@ fi
>  # 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
> @@ -41,15 +41,33 @@ Maintainer: Unmaintained snapshot
>  Section: admin
>  Priority: optional
>  Installed-Size: $(du -ks deb | cut -f1)
> -Description: Xen hypervisor and tools, version $version
> - This package contains the Xen hypervisor and associated tools, built
> - from a source tree.  It is not a fully packaged and supported Xen, just
> - the output of a xen "make dist" wrapped in a .deb to make it easy to
> - uninstall.
> +Description: Xen testing build, version $version
> + Warning: This is a custom testing build of Xen; it is not an
> + officially supported Debian package. Please not distribute.
> + It is just the output of a xen "make dist" wrapped in a .deb
> + to make it easy to update and 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
> +insserv -r xendomains &&
> +insserv -r xencommons
>  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

All the changes look good to me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:07:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:07: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 1UAKFR-0000dN-M4; Tue, 26 Feb 2013 13:07:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAKFQ-0000dI-MS
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:07:08 +0000
Received: from [85.158.137.99:33483] by server-9.bemta-3.messagelabs.com id
	73/D0-09484-B73BC215; Tue, 26 Feb 2013 13:07:07 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361884027!13039072!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_32,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 26 Feb 2013 13:07:07 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 13:07:07 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:53103 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 1UAKDN-0006fM-3Z; Tue, 26 Feb 2013 14:05:01 +0100
Date: Tue, 26 Feb 2013 14:07:02 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <894977724.20130226140702@eikelenboom.it>
To: Thomas Gleixner <tglx@linutronix.de>
In-Reply-To: <alpine.LFD.2.02.1302261320120.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.com>
	<alpine.LFD.2.02.1302261320120.22263@ionos>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regression introduced with
	14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use
	smpboot 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


Tuesday, February 26, 2013, 1:36:36 PM, you wrote:

> On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>> 
>> I don't know if this is b/c the Xen code is missing something or
>> expects something that never happend. I hadn't looked at your
>> patch in any detail (was going to do that on Monday).
>> 
>> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)

Hmm i'm seeing this booting on baremetal as well.
(see http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00836.html)

>> this is I what get:
>> [    0.133081] cpu 1 spinlock event irq 71
>> [    0.134049] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
>> [    0.205154] Brought up 2 CPUs
>> [    0.205156] smpboot: Total of 2 processors activated (16021.74 BogoMIPS)
>> 
>> [   28.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
>> [   28.134000] Modules linked in:
>> [   28.134000] CPU 0 
>> [   28.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
>> [   28.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0

> So the migration thread loops in stop_machine_cpu_stop(). Now the
> interesting question is what work was scheduled for that cpu.

> The main difference between the old code and the new one, is that the
> thread is created earlier and not detroyed on cpu offline.

> Could you add some instrumentation, so we can see what kind of cpu
> stop work is scheduled and from where?

> Thanks,

>         tglx




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:07:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:07: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 1UAKFR-0000dN-M4; Tue, 26 Feb 2013 13:07:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAKFQ-0000dI-MS
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:07:08 +0000
Received: from [85.158.137.99:33483] by server-9.bemta-3.messagelabs.com id
	73/D0-09484-B73BC215; Tue, 26 Feb 2013 13:07:07 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361884027!13039072!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_32,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 26 Feb 2013 13:07:07 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 13:07:07 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:53103 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 1UAKDN-0006fM-3Z; Tue, 26 Feb 2013 14:05:01 +0100
Date: Tue, 26 Feb 2013 14:07:02 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <894977724.20130226140702@eikelenboom.it>
To: Thomas Gleixner <tglx@linutronix.de>
In-Reply-To: <alpine.LFD.2.02.1302261320120.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.com>
	<alpine.LFD.2.02.1302261320120.22263@ionos>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regression introduced with
	14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use
	smpboot 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


Tuesday, February 26, 2013, 1:36:36 PM, you wrote:

> On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>> 
>> I don't know if this is b/c the Xen code is missing something or
>> expects something that never happend. I hadn't looked at your
>> patch in any detail (was going to do that on Monday).
>> 
>> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)

Hmm i'm seeing this booting on baremetal as well.
(see http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00836.html)

>> this is I what get:
>> [    0.133081] cpu 1 spinlock event irq 71
>> [    0.134049] smpboot: Booting Node   0, Processors  #1[    0.008000] installing Xen timer for CPU 1
>> [    0.205154] Brought up 2 CPUs
>> [    0.205156] smpboot: Total of 2 processors activated (16021.74 BogoMIPS)
>> 
>> [   28.134000] BUG: soft lockup - CPU#0 stuck for 23s! [migration/0:8]
>> [   28.134000] Modules linked in:
>> [   28.134000] CPU 0 
>> [   28.134000] Pid: 8, comm: migration/0 Tainted: G        W    3.8.0upstream-06472-g6661875-dirty #1 Xen HVM domU
>> [   28.134000] RIP: 0010:[<ffffffff8110711b>]  [<ffffffff8110711b>] stop_machine_cpu_stop+0x7b/0xf0

> So the migration thread loops in stop_machine_cpu_stop(). Now the
> interesting question is what work was scheduled for that cpu.

> The main difference between the old code and the new one, is that the
> thread is created earlier and not detroyed on cpu offline.

> Could you add some instrumentation, so we can see what kind of cpu
> stop work is scheduled and from where?

> Thanks,

>         tglx




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:10:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13: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 1UAKI9-0000j8-8Y; Tue, 26 Feb 2013 13:09: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 1UAKI7-0000j1-Rn
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:09:55 +0000
Received: from [85.158.139.83:24273] by server-2.bemta-5.messagelabs.com id
	2E/CF-23989-224BC215; Tue, 26 Feb 2013 13:09:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361884179!29270911!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28554 invoked from network); 26 Feb 2013 13:09:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1899554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 13:09: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.297.1;
	Tue, 26 Feb 2013 13:09:19 +0000
Message-ID: <1361884158.26546.291.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 13:09:18 +0000
In-Reply-To: <alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > +cat >deb/DEBIAN/postrm <<EOF
> > +#!/bin/bash -e
> > +insserv -r xendomains &&
> > +insserv -r xencommons
[...]
> All the changes look good to me

This one certainly isn't, calling insserv directly in a pre/post inst is
not the correct Debian interface to use.

Better to call update-rc.d I think, or use dh_installinit (and grow a
build time dependency on debhelper).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:10:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13: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 1UAKI9-0000j8-8Y; Tue, 26 Feb 2013 13:09: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 1UAKI7-0000j1-Rn
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:09:55 +0000
Received: from [85.158.139.83:24273] by server-2.bemta-5.messagelabs.com id
	2E/CF-23989-224BC215; Tue, 26 Feb 2013 13:09:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361884179!29270911!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28554 invoked from network); 26 Feb 2013 13:09:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1899554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 13:09: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.297.1;
	Tue, 26 Feb 2013 13:09:19 +0000
Message-ID: <1361884158.26546.291.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 13:09:18 +0000
In-Reply-To: <alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > +cat >deb/DEBIAN/postrm <<EOF
> > +#!/bin/bash -e
> > +insserv -r xendomains &&
> > +insserv -r xencommons
[...]
> All the changes look good to me

This one certainly isn't, calling insserv directly in a pre/post inst is
not the correct Debian interface to use.

Better to call update-rc.d I think, or use dh_installinit (and grow a
build time dependency on debhelper).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:11:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:11: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 1UAKJi-0000rc-OP; Tue, 26 Feb 2013 13:11: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 1UAKJh-0000rQ-3W
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:11:33 +0000
Received: from [85.158.143.99:14869] by server-3.bemta-4.messagelabs.com id
	52/D6-02186-484BC215; Tue, 26 Feb 2013 13:11:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361884207!21737522!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9829 invoked from network); 26 Feb 2013 13:10:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1899589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 13:10: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.297.1;
	Tue, 26 Feb 2013 13:10:07 +0000
Message-ID: <1361884205.26546.292.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Feb 2013 13:10:05 +0000
In-Reply-To: <512CBDCD02000078000C1122@nat28.tlf.novell.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
	<512CBDCD02000078000C1122@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 12:51 +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 13:21, Ian Campbell <ian.campbell@citrix.com> wrote:
> > On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
> >> On 26/02/13 11:52, Tim Deegan wrote:
> >> > How about ASSERT(((typeof credits) val) == val) before the assignment?
> > 
> > Why not just
> > 	ASSERT(credits == val); /* Ensure we haven't truncated val */
> 
> I.e. just want em to add a comment?

That's right s/val/credits/ depending on what the ASSERT is really doing
(I didn't go back and 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 Feb 26 13:11:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:11: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 1UAKJi-0000rc-OP; Tue, 26 Feb 2013 13:11: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 1UAKJh-0000rQ-3W
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:11:33 +0000
Received: from [85.158.143.99:14869] by server-3.bemta-4.messagelabs.com id
	52/D6-02186-484BC215; Tue, 26 Feb 2013 13:11:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361884207!21737522!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9829 invoked from network); 26 Feb 2013 13:10:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1899589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 13:10: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.297.1;
	Tue, 26 Feb 2013 13:10:07 +0000
Message-ID: <1361884205.26546.292.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 26 Feb 2013 13:10:05 +0000
In-Reply-To: <512CBDCD02000078000C1122@nat28.tlf.novell.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
	<512CBDCD02000078000C1122@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 12:51 +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 13:21, Ian Campbell <ian.campbell@citrix.com> wrote:
> > On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
> >> On 26/02/13 11:52, Tim Deegan wrote:
> >> > How about ASSERT(((typeof credits) val) == val) before the assignment?
> > 
> > Why not just
> > 	ASSERT(credits == val); /* Ensure we haven't truncated val */
> 
> I.e. just want em to add a comment?

That's right s/val/credits/ depending on what the ASSERT is really doing
(I didn't go back and 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 Feb 26 13:13:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13: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 1UAKLF-00013a-Sc; Tue, 26 Feb 2013 13: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 1UAKLE-00013L-Lw
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:13:08 +0000
Received: from [85.158.143.99:39335] by server-1.bemta-4.messagelabs.com id
	DA/F0-06203-3E4BC215; Tue, 26 Feb 2013 13:13:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361884371!18856528!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23346 invoked from network); 26 Feb 2013 13:12:53 -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;
	26 Feb 2013 13:12:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9185551"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 13:12:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 08:12:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAKKw-0005LA-JH;
	Tue, 26 Feb 2013 13:12:50 +0000
Date: Tue, 26 Feb 2013 13:12:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361884158.26546.291.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Ian Campbell wrote:
> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > > +cat >deb/DEBIAN/postrm <<EOF
> > > +#!/bin/bash -e
> > > +insserv -r xendomains &&
> > > +insserv -r xencommons
> [...]
> > All the changes look good to me
> 
> This one certainly isn't, calling insserv directly in a pre/post inst is
> not the correct Debian interface to use.
> 
> Better to call update-rc.d I think, or use dh_installinit (and grow a
> build time dependency on debhelper).

I am _very_ ignorant in deb packaging, but this wiki

http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

states:

"In Debian releases prior to 6.0, a service could be added with update-rc.d:

update-rc.d mydaemon defaults

Starting with Debian 6.0, the insserv command is used instead, if dependency-based booting is enabled:

insserv mydaemon"

but maybe this is the recommended thing to do for sysadmins, not for
packagers?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:13:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13: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 1UAKLF-00013a-Sc; Tue, 26 Feb 2013 13: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 1UAKLE-00013L-Lw
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:13:08 +0000
Received: from [85.158.143.99:39335] by server-1.bemta-4.messagelabs.com id
	DA/F0-06203-3E4BC215; Tue, 26 Feb 2013 13:13:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361884371!18856528!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23346 invoked from network); 26 Feb 2013 13:12:53 -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;
	26 Feb 2013 13:12:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9185551"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 13:12:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 08:12:50 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAKKw-0005LA-JH;
	Tue, 26 Feb 2013 13:12:50 +0000
Date: Tue, 26 Feb 2013 13:12:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1361884158.26546.291.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Ian Campbell wrote:
> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > > +cat >deb/DEBIAN/postrm <<EOF
> > > +#!/bin/bash -e
> > > +insserv -r xendomains &&
> > > +insserv -r xencommons
> [...]
> > All the changes look good to me
> 
> This one certainly isn't, calling insserv directly in a pre/post inst is
> not the correct Debian interface to use.
> 
> Better to call update-rc.d I think, or use dh_installinit (and grow a
> build time dependency on debhelper).

I am _very_ ignorant in deb packaging, but this wiki

http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

states:

"In Debian releases prior to 6.0, a service could be added with update-rc.d:

update-rc.d mydaemon defaults

Starting with Debian 6.0, the insserv command is used instead, if dependency-based booting is enabled:

insserv mydaemon"

but maybe this is the recommended thing to do for sysadmins, not for
packagers?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:18:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13: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 1UAKQa-0001Rg-M8; Tue, 26 Feb 2013 13:18: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 1UAKQY-0001RW-C5
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:18:38 +0000
Received: from [85.158.143.99:52000] by server-3.bemta-4.messagelabs.com id
	FB/3F-02186-D26BC215; Tue, 26 Feb 2013 13:18:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361884716!22255329!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 26 Feb 2013 13:18:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:18:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1900053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 13:18: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.297.1;
	Tue, 26 Feb 2013 13:18:36 +0000
Message-ID: <1361884713.26546.296.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 13:18:33 +0000
In-Reply-To: <alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 13:12 +0000, Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Ian Campbell wrote:
> > On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > > > +cat >deb/DEBIAN/postrm <<EOF
> > > > +#!/bin/bash -e
> > > > +insserv -r xendomains &&
> > > > +insserv -r xencommons
> > [...]
> > > All the changes look good to me
> > 
> > This one certainly isn't, calling insserv directly in a pre/post inst is
> > not the correct Debian interface to use.
> > 
> > Better to call update-rc.d I think, or use dh_installinit (and grow a
> > build time dependency on debhelper).
> 
> I am _very_ ignorant in deb packaging, but this wiki
> [...]
>  maybe this is the recommended thing to do for sysadmins, not for
> packagers?

AIUI, yes. The document to refer to for anything to do with Debian
Packaging is the Debian Policy Manual: 
        http://www.debian.org/doc/debian-policy/

In this case: 
        http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
        
        Maintainers should use the abstraction layer provided by the
        update-rc.d and invoke-rc.d programs to deal with initscripts in
        their packages' scripts such as postinst, prerm and postrm.
        
        Directly managing the /etc/rc?.d links and directly invoking
        the /etc/init.d/ initscripts should be done only by packages
        providing the initscript subsystem (such as sysv-rc and
        file-rc). 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:18:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13: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 1UAKQa-0001Rg-M8; Tue, 26 Feb 2013 13:18: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 1UAKQY-0001RW-C5
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 13:18:38 +0000
Received: from [85.158.143.99:52000] by server-3.bemta-4.messagelabs.com id
	FB/3F-02186-D26BC215; Tue, 26 Feb 2013 13:18:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1361884716!22255329!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4481 invoked from network); 26 Feb 2013 13:18:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:18:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1900053"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 13:18: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.297.1;
	Tue, 26 Feb 2013 13:18:36 +0000
Message-ID: <1361884713.26546.296.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 13:18:33 +0000
In-Reply-To: <alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 13:12 +0000, Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Ian Campbell wrote:
> > On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > > > +cat >deb/DEBIAN/postrm <<EOF
> > > > +#!/bin/bash -e
> > > > +insserv -r xendomains &&
> > > > +insserv -r xencommons
> > [...]
> > > All the changes look good to me
> > 
> > This one certainly isn't, calling insserv directly in a pre/post inst is
> > not the correct Debian interface to use.
> > 
> > Better to call update-rc.d I think, or use dh_installinit (and grow a
> > build time dependency on debhelper).
> 
> I am _very_ ignorant in deb packaging, but this wiki
> [...]
>  maybe this is the recommended thing to do for sysadmins, not for
> packagers?

AIUI, yes. The document to refer to for anything to do with Debian
Packaging is the Debian Policy Manual: 
        http://www.debian.org/doc/debian-policy/

In this case: 
        http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
        
        Maintainers should use the abstraction layer provided by the
        update-rc.d and invoke-rc.d programs to deal with initscripts in
        their packages' scripts such as postinst, prerm and postrm.
        
        Directly managing the /etc/rc?.d links and directly invoking
        the /etc/init.d/ initscripts should be done only by packages
        providing the initscript subsystem (such as sysv-rc and
        file-rc). 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:45:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:45: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 1UAKqW-0001rO-2l; Tue, 26 Feb 2013 13:45:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UAKqV-0001rJ-01
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:45:27 +0000
Received: from [85.158.138.51:38384] by server-10.bemta-3.messagelabs.com id
	84/ED-10609-37CBC215; Tue, 26 Feb 2013 13:45:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361886312!19528504!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14553 invoked from network); 26 Feb 2013 13:45:22 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9199699"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 13:44:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 08:44:10 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UAKpF-0005mk-UY;
	Tue, 26 Feb 2013 13:44:10 +0000
Message-ID: <512CBC29.9020404@citrix.com>
Date: Tue, 26 Feb 2013 13:44:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<51236654.3050709@citrix.com> <512CA5AE.4090002@eu.citrix.com>
In-Reply-To: <512CA5AE.4090002@eu.citrix.com>
X-Enigmail-Version: 1.4
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMjYvMDIvMTMgMTI6MDgsIEdlb3JnZSBEdW5sYXAgd3JvdGU6Cj4gT24gMDIvMTkvMjAxMyAx
MTo0NyBBTSwgQW5kcmV3IENvb3BlciB3cm90ZToKPj4gT24gMTkvMDIvMTMgMDk6MjgsIEphbiBC
ZXVsaWNoIHdyb3RlOgo+Pj4+Pj4gT24gMTguMDIuMTMgYXQgMTk6MTEsIEFuZHJldyBDb29wZXIg
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4+IEhlbGxvLAo+Pj4+Cj4+Pj4g
T3VyIHRlc3RpbmcgaGFzIGRpc2NvdmVyZWQgYSBjcmFzaCAocGFnZWZhdWx0IGF0IDB4MDAwMDAw
MDAwMDAwMDAwOCkKPj4+PiB3aGljaCBJIGhhdmUgdHJhY2tlZCBkb3duIHRvIGJhZCBfX3J1bnFf
cmVtb3ZlKCkgaW4gY3NjaGVkX3ZjcHVfc2xlZXAoKQo+Pj4+IGluIHNjaGVkX2NyZWRpdC5jIChi
ZWNhdXNlIGEgc3RhdGljIGZ1bmN0aW9uIG9mIHRoZSBzYW1lIG5hbWUgYWxzbwo+Pj4+IGV4aXN0
cyBpbiBzY2hlZF9jcmVkaXQyLmMsIHdoaWNoIGNvbmZ1c2VkIG1hdHRlcnMgdG8gc3RhcnQgd2l0
aCkKPj4+Pgo+Pj4+IFRoZSB0ZXN0IGNhc2Ugd2FzIGEgbG9vcCBvZiBsb2NhbGhvc3QgbWlncmF0
ZSBvZiBhIDF2Y3B1IEhWTSB3aW44Cj4+Pj4gZG9tYWluLiAgVGhlIHRlc3QgY2FzZSBpdHNlbGYg
aGFzIHBhc3NlZCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IG9uIHRoZQo+Pj4+IHNhbWUgWGVuIGNv
ZGViYXNlIChYZW4tNC4xLjMpLCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdmVyeSByYXJlLiAgVGhl
cmUKPj4+PiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYW55IHJlbGV2YW50IGNoYW5nZXMgYmV0d2Vl
biB0aGUgdmVyc2lvbiBvZiBYZW4gaW4KPj4+PiB0aGUgdGVzdCBhbmQgeGVuLTQuMS10ZXN0aW5n
Lgo+Pj4+Cj4+Pj4gVGhlIGZhaWx1cmUgaXRzZWxmIGlzIGJlY2F1c2Ugb2YgYSBYRU5fRE9NQ1RM
X3NjaGVkdWxlcl9vcCAodHJhY2UgYmVsb3cpCj4+Pj4gZnJvbSBkb20wLCB0YXJnZXRpbmcgdGhl
IFZDUFUgb2YgdGhlIG1pZ3JhdGluZyBkb21haW4uCj4+Pj4KPj4+PiAoWEVOKSBYZW4gY2FsbCB0
cmFjZToKPj4+PiAoWEVOKSAgICAgICBbPGZmZmY4MmM0ODAxMTZhMTQ+XSBjc2NoZWRfdmNwdV9z
bGVlcCsweDQ0LzB4NzAKPj4+PiAoWEVOKSAgICAgIDBbPGZmZmY4MmM0ODAxMjAxMTc+XSB2Y3B1
X3NsZWVwX25vc3luYysweGU3LzB4M2IwCj4+Pj4gKFhFTikgICAgIDEyWzxmZmZmODJjNDgwMTIw
M2U5Pl0gdmNwdV9zbGVlcF9zeW5jKzB4OS8weDUwCj4+Pj4gKFhFTikgICAgIDE0WzxmZmZmODJj
NDgwMTFmZDRjPl0gc2NoZWRfYWRqdXN0KzB4YWMvMHgyMzAKPj4+PiAoWEVOKSAgICAgMjRbPGZm
ZmY4MmM0ODAxMDJiYzE+XSBkb19kb21jdGwrMHg3MzEvMHgxMTMwCj4+Pj4gKFhFTikgICAgIDY0
WzxmZmZmODJjNDgwMjAxM2M0Pl0gY29tcGF0X2h5cGVyY2FsbCsweDc0LzB4ODAKPj4+Pgo+Pj4+
IFRoZSByZWxldmFudCBwYXJ0IG9mIGNzY2hlZF92Y3B1X3NsZWVwKCkgaXMKPj4+Pgo+Pj4+ICAg
ICAgZWxzZSBpZiAoIF9fdmNwdV9vbl9ydW5xKHN2YykgKQo+Pj4+ICAgICAgICAgIF9fcnVucV9y
ZW1vdmUoc3ZjKTsKPj4+Pgo+Pj4+IHdoaWNoIGRpc2Fzc2VtYmxlcyB0bwo+Pj4+Cj4+Pj4gZmZm
ZjgyYzQ4MDExNmEwMTogICAgICAgNDkgOGIgMTAgICAgICAgICAgICAgICAgbW92ICAgICglcjgp
LCVyZHgKPj4+PiBmZmZmODJjNDgwMTE2YTA0OiAgICAgICA0YyAzOSBjMiAgICAgICAgICAgICAg
ICBjbXAgICAgJXI4LCVyZHgKPj4+PiBmZmZmODJjNDgwMTE2YTA3OiAgICAgICA3NSAwNyAgICAg
ICAgICAgICAgICAgICBqbmUgICAgZmZmZjgyYzQ4MDExNmExMAo+Pj4+IDxjc2NoZWRfdmNwdV9z
bGVlcCsweDQwPgo+Pj4+IGZmZmY4MmM0ODAxMTZhMDk6ICAgICAgIGYzIGMzICAgICAgICAgICAg
ICAgICAgIHJlcHogcmV0cQo+Pj4+IGZmZmY4MmM0ODAxMTZhMGI6ICAgICAgIDBmIDFmIDQ0IDAw
IDAwICAgICAgICAgIG5vcGwgICAweDAoJXJheCwlcmF4LDEpCj4+Pj4gZmZmZjgyYzQ4MDExNmEx
MDogICAgICAgNDkgOGIgNDAgMDggICAgICAgICAgICAgbW92ICAgIDB4OCglcjgpLCVyYXgKPj4+
PiBmZmZmODJjNDgwMTE2YTE0OiAgICAgICA0OCA4OSA0MiAwOCAgICAgICAgICAgICBtb3YgICAg
JXJheCwweDgoJXJkeCkgIwo+Pj4+IDwtIFBhZ2VmYXVsdCBoZXJlCj4+Pj4gZmZmZjgyYzQ4MDEx
NmExODogICAgICAgNDggODkgMTAgICAgICAgICAgICAgICAgbW92ICAgICVyZHgsKCVyYXgpCj4+
Pj4gZmZmZjgyYzQ4MDExNmExYjogICAgICAgNGQgODkgNDAgMDggICAgICAgICAgICAgbW92ICAg
ICVyOCwweDgoJXI4KQo+Pj4+IGZmZmY4MmM0ODAxMTZhMWY6ICAgICAgIDRkIDg5IDAwICAgICAg
ICAgICAgICAgIG1vdiAgICAlcjgsKCVyOCkKPj4+Pgo+Pj4+IFRoZSByZWxldmFudCBjcmFzaCBy
ZWdpc3RlcnMgZnJvbSB0aGUgcGFnZWZhdWx0IGFyZToKPj4+PiByYXg6IDAwMDAwMDAwMDAwMDAw
MDAKPj4+PiByZHg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+PiAgIHI4OiBmZmZmODMwODBjODllZDkw
Cj4+Pj4KPj4+PiBJZiBJIGFtIHJlYWRpbmcgdGhlIGNvZGUgY29ycmVjdGx5LCB0aGlzIG1lYW5z
IHRoYXQgcnVucS0+bmV4dCBpcyBOVUxMLAo+Pj4+IHNvIHdlIGZhaWwgbGlzdF9lbXB0eSgpIGFu
ZCBlcnJvbmVvdXNseSBwYXNzIF9fdmNwdV9vbl9ydW5xKCkuICBXZSB0aGVuCj4+Pj4gZmFpbCB3
aXRoIGEgZmF1bHQgd2hlbiB0cnlpbmcgdG8gdXBkYXRlIHJ1bnEtPnByZXYsIHdoaWNoIGlzIGFs
c28gTlVMTC4KPj4+Pgo+Pj4+IFRoZSBvbmx5IHBsYWNlIEkgY2FuIHNwb3QgaW4gdGhlIGNvZGUg
d2hlcmUgdGhlIHJ1bnEtPntuZXh0LHByZXZ9IGNvdWxkCj4+Pj4gY29uY2VpdmFibHkgYmUgTlVM
TCBpcyBpbiBjc2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBtZW1zZXQoKSBhbmQKPj4+
PiBJTklUX0xJU1RfSEVBRCgpLiAgVGhpcyBpcyBsb2dpY2FsbHkgc2Vuc2libGUgaW4gY29tYmlu
YXRpb24gd2l0aCB0aGUKPj4+PiBsb2NhbGhvc3QgbWlncmF0ZSBsb29wLCBhbmQgSSBjYW50IGlt
bWVkaWF0ZWx5IHNlZSBhbnl0aGluZyB0byBwcmV2ZW50Cj4+Pj4gdGhpcyByYWNlIGhhcHBlbmlu
Zy4KPj4+IEJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVkX2FsbG9jX3ZkYXRhKCkg
ZG9lc24ndCBzdG9yZQo+Pj4gc3ZjIGludG8gdmMtPnNjaGVkX3ByaXY7IHRoYXQncyBiZWluZyBk
b25lIGJ5IHRoZSBnZW5lcmljCj4+PiBzY2hlZHVsZXIgY29kZSBvbmNlIHRoZSBhY3RvciByZXR1
cm5zLgo+Pgo+PiBEJ29oIHllcyAtIEkgb3Zlcmxvb2tlZCB0aGF0Lgo+Pgo+Pj4KPj4+IFNvIEkn
ZCByYXRoZXIgc3VzcGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwgd2hpY2ggaXMgZWFz
aWx5Cj4+PiBwb3NzaWJsZSB3aGVuIHJhY2luZyB3aXRoIHNjaGVkX21vdmVfZG9tYWluKCkgKGFz
IG9wcG9zZWQgdG8KPj4+IHNjaGVkdWxlX2NwdV9zd2l0Y2goKSwgd2hlcmUgdGhlIG5ldyBwb2lu
dGVyIGdldHMgc3RvcmVkCj4+PiBfYmVmb3JlXyBkZS1hbGxvY2F0aW5nIHRoZSBvbGQgb25lKS4K
Pj4KPj4+Cj4+PiBIb3dldmVyLCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyB3ZWxsIGFzIHNjaGVk
dWxlX2NwdV9zd2l0Y2goKSkKPj4+IGdldCBjYWxsZWQgb25seSBmcm9tIENQVSBwb29scyBjb2Rl
LCBhbmQgSSB3b3VsZCBndWVzcyBDUFUgcG9vbHMKPj4+IGFyZW4ndCBpbnZvbHZlZCBoZXJlLCBh
bmQgeW91IGRvbid0IGluIHBhcmFsbGVsIHNvZnQgb2ZmbGluZS9vbmxpbmUKPj4+IHBDUFUtcyAo
YXMgSSdtIHN1cmUgeW91IG90aGVyd2lzZSB3b3VsZCBoYXZlIG1lbnRpb25lZCBpdCkuCj4+Pgo+
Pj4gQnV0IHdhaXQgLSBsaWJ4bF9fZG9tYWluX21ha2UoKSBfdW5jb25kaXRpb25hbGx5XyBjYWxs
cwo+Pj4geGNfY3B1cG9vbF9tb3ZlZG9tYWluKCksIGFzIGRvZXMgWGVuZERvbWFpbkluZm8ncwo+
Pj4gX2NvbnN0cnVjdERvbWFpbigpLiBUaGUgcmVhc29uIGZvciB0aGlzIGVzY2FwZXMgbWUgLSBK
w7xyZ2VuPyBZZXQKPj4+IEknZCBleHBlY3QgdGhlIHBvb2wgSUQgbWF0Y2hpbmcgY2hlY2sgdG8g
c2hvcnQgY3V0IHRoZSByZXN1bHRpbmcKPj4+IHN5c2N0bCwgaS5lLiBzY2hlZF9tb3ZlX2RvbWFp
bigpIG91Z2h0IHRvIG5vdCBiZSByZWFjaGVkIGFueXdheQo+Pj4gKHdvcnRoIHZlcmlmeWluZyBv
ZiBjb3Vyc2UpLgo+Pj4KPj4+IFRoZSByYWNlIHRoZXJlIG5ldmVydGhlbGVzcyBvdWdodCB0byBi
ZSBmaXhlZC4KPj4+Cj4+PiBKYW4KPj4KPj4gT3VyIHRvb2xzdGFjayBob29rcyBkaXJlY3RseSBp
bnRvIGxpYnhjIGFuZCBpcyBjb21wbGV0ZWx5IGlnbm9yYW50IG9mCj4+IGNwdXBvb2xzLiAgTG9v
a2luZyBhdCB0aGUgY3Jhc2ggbW9yZSBjbG9zZWx5LCBpdCBtaWdodCBiZSBhIHJhY2UgZWxzZXdo
ZXJlCj4+Cj4+IEFub3RoZXIgZG9tMCB2Y3B1IGlzIGluIGFuIEhWTU9QX3RyYWNrX2RpcnR5X3Zy
YW0gaHlwZXJjYWxsLCBhbmQgdGhlCj4+IGFzc29jaWF0ZWQgWGVuIHN0YWNrIHRyYWNlIGlzCj4+
Cj4+IFtmZmZmODJjNDgwMTc3N2IyXSB0aW1lX2NhbGlicmF0aW9uX3N0ZF9yZW5kZXp2b3VzKzB4
YjIvMHhjMAo+PiAgIGZmZmY4MmM0ODAxNzJkMTIgIF9fc21wX2NhbGxfZnVuY3Rpb25faW50ZXJy
dXB0KzB4NjIvMHhiMAo+PiAgIGZmZmY4MmM0ODAxNzMzOWUgIHNtcF9jYWxsX2Z1bmN0aW9uX2lu
dGVycnVwdCsweDRlLzB4OTAKPj4gICBmZmZmODJjNDgwMTRhNjVhICBjYWxsX2Z1bmN0aW9uX2lu
dGVycnVwdCsweDJhLzB4MzAKPj4gICBmZmZmODJjNDgwMTIyM2IyICBfc3Bpbl9sb2NrKzB4MTIv
MHgyMAo+PiAgIGZmZmY4MmM0ODAxNzM0YWIgIGZsdXNoX2FyZWFfbWFzaysweGNiLzB4MWMwCj4+
ICAgZmZmZjgyYzQ4MDFjODYyYSAgcGFnaW5nX2xvZ19kaXJ0eV9yYW5nZSsweDNhLzB4NzgwCj4+
ICAgZmZmZjgyYzQ4MDEyMWVhOCAgY3B1bWFza19yYWlzZV9zb2Z0aXJxKzB4NzgvMHg4MAo+PiAg
IGZmZmY4MmM0ODAxMTdlZDMgIGNzY2hlZF92Y3B1X3dha2UrMHgxOTMvMHg0MjAKPj4gICBmZmZm
ODJjNDgwMTRhNWZhICBldmVudF9jaGVja19pbnRlcnJ1cHQrMHgyYS8weDMwCj4+ICAgZmZmZjgy
YzQ4MDFmMjFjNyAgaGFwX3RyYWNrX2RpcnR5X3ZyYW0rMHgxMzcvMHgxYzAKPj4gICBmZmZmODJj
NDgwMWFkM2ZkICBkb19odm1fb3ArMHgxNmRkLzB4MWY1MAo+PiAgIGZmZmY4MmM0ODAxMDYyNTEg
IGV2dGNobl9zZW5kKzB4YTEvMHgxNjAKPj4gICBmZmZmODJjNDgwMTA2ZDM2ICBkb19ldmVudF9j
aGFubmVsX29wKzB4ODc2LzB4ZmQwCj4+ICAgZmZmZjgyYzQ4MDFmOTAyNyAgY29tcGF0X3VwZGF0
ZV9kZXNjcmlwdG9yKzB4MjcvMHgzMAo+PiAgIGZmZmY4MmM0ODAxMzU0ZjggIGNvbXBhdF9tdWx0
aWNhbGwrMHgxOTgvMHgzODAKPj4gICBmZmZmODJjNDgwMTRhNWZhICBldmVudF9jaGVja19pbnRl
cnJ1cHQrMHgyYS8weDMwCj4+ICAgZmZmZjgyYzQ4MDIwMTNjNCAgY29tcGF0X2h5cGVyY2FsbCsw
eDc0LzB4ODAKPj4KPj4gdGhlIGhhcF90cmFja19kaXJ0eV92cmFtKCkgYW5kIHBhZ2luZ19sb2df
ZGlydHlfcmFuZ2UoKSBhcmUgcGFydCBvZiB0aGUKPj4gc2FtZSBsb2dpY2FsIGNhbGwgdHJhY2Us
IGJ1dCBpdCBhcHBlYXJzIHRoYXQgd2UgaGF2ZSB0YWtlbiBhbgo+PiBldmVudF9jaGVja19pbnRl
cnJ1cHQoKSBpbiB0aGUgbWlkZGxlIGFuZCBjYWxsZWQgc2NoZWR1bGUoKSBvZmYgdGhlCj4+IGJv
dHRvbSBvZiBpdCwgY2FsbGluZyBjc2NoZWRfdmNwdV93YWtlKCkuCj4+Cj4+IEkgYW0gY3VycmVu
dGx5IHRyeWluZyB0byByZWFzb24gYXMgdG8gd2hldGhlciBpdCBpcyBwb3NzaWJsZSBmb3IgYSBy
YWNlCj4+IGJldHdlZW4gY3NjaGVkX3ZjcHVfe3NsZWVwLHdha2V9KCkgY291bGQgcmVzdWx0IGlu
IHRoZSBzZWVuIGNyYXNoLCBidXQKPj4gaXQgY2VydGFpbmx5IGxvb2tzIGxpa2UgYSBzbW9raW5n
IGd1bi4KPgo+IEFueSBtb3JlIHByb2dyZXNzIG9uIHRoaXMgb25lPwo+Cj4gSW4gdGhlb3J5IGFs
bCBvZiB0aG9zZSBzaG91bGQgYmUgbWFkZSBtdXR1YWxseSBleGNsdXNpdmUgYnkgaG9sZGluZyB0
aGUgCj4gbG9jayBvZiB0aGUgcnVucXVldWUgb24gd2hpY2ggdGhlIFZDUFUgaXMgcnVubmluZy4K
Pgo+IEFueSBjaGFuY2UgdGhlcmUncyBhIHJhY2Ugd2l0aCB0aGUgYXNzaWdubWVudCBvZiB0aGUg
dmNwdSAtLSB0aGF0IGlzLCBhIAo+IHJhY2UgaW4gdmNwdV9zY2hlZHVsZV9sb2NrKCkgc3VjaCB0
aGF0IHNvbWVvbmUgZW5kcyB1cCBncmFiYmluZyB0aGUgCj4gd3JvbmcgbG9jaz8KPgo+IEkgdGhp
bmsgdGhhdCBpbiB0aGVvcnkgb25jZSB5b3UgY2FsbCBJTklUX0xJU1RfSEVBRCwgbm9uZSBvZiB0
aG9zZSAKPiBwb2ludGVycyBzaG91bGQgZXZlciBiZSBzZXQgdG8gemVybzsgaWYgb25lIGV2ZXIg
d2VyZSBpdCBtaWdodCBnZXQgCj4gcGFzc2VkIGFyb3VuZCBhIGJpdCBiZWZvcmUgYWN0dWFsbHkg
YmVpbmcgZm9sbG93ZWQuICBBbnkgY2hhbmNlIHRoZXJlJ3MgCj4gc29tZXRoaW5nIHVuaW5pdGlh
bGl6ZWQgc29tZXdoZXJlPwo+Cj4gQW5kIG9mIGNvdXJzZSwgaWYgYWxsIGVsc2UgZmFpbHMsIHRo
ZXJlJ3MgZ29vZCBvbGQtZmFzaGlvbmVkIG1lbW9yeSAKPiBjbG9iYmVyaW5nIGFzIGEgcG9zc2li
aWxpdHkuLi4KPgo+ICAgLUdlb3JnZQoKTm8gbW9yZSBwcm9ncmVzcyBJIGFtIGFmcmFpZCAtIE90
aGVyIG1vcmUgZWFzaWx5IHJlcHJvZHVjaWJsZSBidWdzIGNhbWUgdXAuCgpJIGRpZCBpZGVudGlm
eSBhbm90aGVyIHRpY2tldCBpbiBvdXIgc3lzdGVtIHdoaWNoIGdvdCBtaXMtY2xhc2lmaWVkLAp3
aGljaCBhcHBlYXJzIHRvIGJlIHRoZSBzYW1lL3NpbWlsYXIgcmFjZSBjb25kaXRpb24KCihYRU4p
IFhlbiBCVUcgYXQgc2NoZWRfY3JlZGl0LmM6MjA0CihYRU4pIC0tLS1bIFhlbi00LjEuMyAgeDg2
XzY0ICBkZWJ1Zz1uICBOb3QgdGFpbnRlZCBdLS0tLQooWEVOKSBDUFU6ICAgIDExCihYRU4pIFJJ
UDogICAgZTAwODpbPGZmZmY4MmM0ODAxMTdiYmI+XSBjc2NoZWRfdmNwdV93YWtlKzB4M2NiLzB4
M2YwCihYRU4pIFJGTEFHUzogMDAwMDAwMDAwMDAxMDAwMyAgIENPTlRFWFQ6IGh5cGVydmlzb3IK
KFhFTikgcmF4OiBmZmZmODMwOTk0YjM3NDM4ICAgcmJ4OiBmZmZmODMwOTk0YjM2MDAwICAgcmN4
OiBmZmZmODMwODM2YWQxZDYwCihYRU4pIHJkeDogZmZmZjgzMDk5NGIzNjAwMCAgIHJzaTogMDAw
MDAwMDAwMDAwMDAwMCAgIHJkaTogZmZmZjgyYzQ4MDJjYjdjMAooWEVOKSByYnA6IGZmZmY4MzBh
OTMzNDNmMjAgICByc3A6IGZmZmY4MzA4MzZhOTdkODAgICByODogIGZmZmY4MzBhOTMzNDNmMjAK
KFhFTikgcjk6ICAwMDAwMDAwMDAwMDAwMDBiICAgcjEwOiAwMDAwMDAwMDAwMDAwMDBiICAgcjEx
OiBmZmZmODJjNDgwMmJhMGUwCihYRU4pIHIxMjogZmZmZjgzMDk5NGIzNzUwMCAgIHIxMzogMDAw
MDAxYjE2NjI1N2ViYSAgIHIxNDogZmZmZjgyYzQ4MDJjYjdjMAooWEVOKSByMTU6IGZmZmY4MmM0
ODAyYmEwZTAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDI2ZjAK
KFhFTikgY3IzOiAwMDAwMDAwYTkyNzIxMDAwICAgY3IyOiAwMDAwMDAwMDA4ZWU3ZGM4CihYRU4p
IGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAgICBj
czogZTAwOAooWEVOKSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDgzNmE5N2Q4MDoK
KFhFTikgICAgZmZmZjgzMDBiZTZiZjdkMCAwMDAwMDAwMGZlZDAwMGYwIGZmZmY4MmM0ODAxNGEx
MzAgMDAwMDAwMDAwMDAwMDAwMAooWEVOKSAgICBmZmZmODMwODM2YTk3ZjE4IGZmZmY4MzA4MzZh
OTgwMTAgZmZmZjgyYzQ4MDE0OWRkYSBmZmZmODMwOTk0YjM2MDAwCihYRU4pICAgIGZmZmY4MzAw
YmU2YWEwMDAgZmZmZjgzMDk5NGIzNzUwMCAwMDAwMDFiMTY2MjU3ZWJhIGZmZmY4MmM0ODAyY2I3
YzAKKFhFTikgICAgZmZmZjgyYzQ4MDJiYTBlMCBmZmZmODJjNDgwMTIwNmUwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDI4NgooWEVOKSAgICAwMDAwMDFiMTMyMDAwOWYxIDAwMDAwMDAw
MDAwMDAwMDMgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwCihYRU4pICAgIGZmZmY4
MzAwYmU2YWEwMDAgZmZmZjgzMDBiZTZhYjc5MCBmZmZmODJjNDgwMWI3NjIwIGZmZmY4MzA0NTAx
YTcwMTAKKFhFTikgICAgZmZmZjgzMDQ1MDFhNzAxMCBmZmZmODJjNDgwMTRmMTNkIGZmZmY4MzAw
YmU2YWI3OTAgZmZmZjgzMDBiZTZhYjc5MAooWEVOKSAgICAwMDAwMDFiMTY2MjU3ZGU0IGZmZmY4
MmM0ODAxYjc2NDIgZmZmZjgzMDgzNmE5ZTEwMCBmZmZmODJjNDgwMTIzODhjCihYRU4pICAgIGZm
ZmY4MzAwYmU2YWI3ZDAgZmZmZjgzMDgzNmE5ZTEwMCBmZmZmODMwNDUwMWE3MDE4IGZmZmY4MmM0
ODAxMjNkMzUKKFhFTikgICAgZmZmZjgyYzQ4MDFhZjQ4NiAwMDAwMDAwMDAwMDAwMDBiIGZmZmZm
ZmZmZmZmZmZmZmYgZmZmZjgzMDgzNmE5N2YxOAooWEVOKSAgICBmZmZmODJjNDgwMmE4NTAwIGZm
ZmY4MmM0ODAyYWM1MDAgMDAwMDAxYjE2NjI1NDMxZCBmZmZmODJjNDgwMTIxNmI1CihYRU4pICAg
IGZmZmY4MzA4MzZhOTdmMTggZmZmZjgzMDBiZjJmMDAwMCBmZmZmODMwMGJlNzRjMDAwIGZmZmY4
MmM0ODAyYmEwZTAKKFhFTikgICAgZmZmZjgzMDgzNmE5ZTA2MCBmZmZmODJjNDgwMTRmZGM1IDAw
MDAwMDAwMDAwMDAwMGIgMDAwMDAwMDAwMDAwMDA4ZAooWEVOKSAgICBmZmZmZmZmZmZmZmZmZmZl
IGZmZmZmZjAwN2I0MTEyMjggZmZmZmZmMDA3YjQxMTIwMCBmZmZmZmZmZWJhNGMxYjkwCihYRU4p
ICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MDQ0YjhjMCBmZmZmZmYwMDdiNTgzZTEwIGZm
ZmZmZjAwN2I1ODNlODgKKFhFTikgICAgZmZmZmZmZmViYTRjMWQxMCAwMDAwMDAwMDAwMDAwM2U4
IDAwMDAwMDAwMDAwZjQyNDAgMDAwMDAwMDAwMDAwMDAwMAooWEVOKSAgICAwMDAwMDAwMDAwMDAw
MDAxIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwNmQwMDAwMDAwMCBmZmZmZmZmZjgwNzM3MWM2CihY
RU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDI0NiBmZmZmZmZmZWJhNGMxYjkw
IDAwMDAwMDAwMDAwMDAwMDAKKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMAooWEVOKSAgICAwMDAwMDAwMDAw
MDAwMDBiIGZmZmY4MzAwYmYyZjAwMDAgMDAwMDAwNDNiNjdkMjg4MCAwMDAwMDAwMDAwMDAwMDAw
CihYRU4pIFhlbiBjYWxsIHRyYWNlOgooWEVOKSAgICAgICBbPGZmZmY4MmM0ODAxMTdiYmI+XSBj
c2NoZWRfdmNwdV93YWtlKzB4M2NiLzB4M2YwCihYRU4pICAgICAgMls8ZmZmZjgyYzQ4MDE0YTEz
MD5dIHNtcF9hcGljX3RpbWVyX2ludGVycnVwdCsweDUwLzB4OTAKKFhFTikgICAgICA2WzxmZmZm
ODJjNDgwMTQ5ZGRhPl0gYXBpY190aW1lcl9pbnRlcnJ1cHQrMHgyYS8weDMwCihYRU4pICAgICAx
M1s8ZmZmZjgyYzQ4MDEyMDZlMD5dIHZjcHVfd2FrZSsweDE4MC8weDYwMAooWEVOKSAgICAgMjJb
PGZmZmY4MmM0ODAxYjc2MjA+XSBwdF90aW1lcl9mbisweDAvMHgzMAooWEVOKSAgICAgMjVbPGZm
ZmY4MmM0ODAxNGYxM2Q+XSB2Y3B1X2tpY2srMHgxZC8weDgwCihYRU4pICAgICAyOVs8ZmZmZjgy
YzQ4MDFiNzY0Mj5dIHB0X3RpbWVyX2ZuKzB4MjIvMHgzMAooWEVOKSAgICAgMzFbPGZmZmY4MmM0
ODAxMjM4OGM+XSBleGVjdXRlX3RpbWVyKzB4NGMvMHg3MAooWEVOKSAgICAgMzVbPGZmZmY4MmM0
ODAxMjNkMzU+XSB0aW1lcl9zb2Z0aXJxX2FjdGlvbisweDg1LzB4MjIwCihYRU4pICAgICAzNls8
ZmZmZjgyYzQ4MDFhZjQ4Nj5dIGh2bV92Y3B1X2hhc19wZW5kaW5nX2lycSsweDc2LzB4ZDAKKFhF
TikgICAgIDQzWzxmZmZmODJjNDgwMTIxNmI1Pl0gX19kb19zb2Z0aXJxKzB4NjUvMHg5MAooWEVO
KSAgICAgNDlbPGZmZmY4MmM0ODAxNGZkYzU+XSBpZGxlX2xvb3ArMHgyNS8weDUwCihYRU4pICAg
CihYRU4pCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKFhF
TikgUGFuaWMgb24gQ1BVIDExOgooWEVOKSBYZW4gQlVHIGF0IHNjaGVkX2NyZWRpdC5jOjIwNAoo
WEVOKSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCgpUaGUgYnVnIGlu
IHF1ZXN0aW9uIGlzIEJVR19PTiggY3B1ICE9IHN2Yy0+dmNwdS0+cHJvY2Vzc29yICk7CgpUaGlz
IGlzIHN1c3BjaW91cyBhcywgbGlrZSBiZWZvcmUsIHRoZXJlIGlzIGFuIExBUElDLXRyaWdnZXJl
ZCBpbnRlcnJ1cHQKaW4gdGhlIG1pZGRsZSBvZiBhIHNjaGVkdWxpbmcgY29kZXBhdGguICBBZ2Fp
biwgaXQgaGFzIGJlZW4gc2VlbiBvbmx5Cm9uY2UgdGhyb3VnaCBtdWx0aXBsZSBjeWNsZXMgb2Yg
dGVzdGluZy4KCklmIHlvdSBoYXZlIGFueSBpZGVhcyB0aGVuIGZhbnRhc3RpYywgYnV0IEkgaGF2
ZSBub3QgZm9yZ290dGVuIGFib3V0IGl0Ci0ganVzdCBoYWQgb3RoZXIgc3R1ZmYgY29tZSB1cC4g
IEkgd2lsbCBnZXQgYmFjayB0byBpdCBhdCBzb21lIHBvaW50IQoKfkFuZHJldwoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:45:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:45: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 1UAKqW-0001rO-2l; Tue, 26 Feb 2013 13:45:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UAKqV-0001rJ-01
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:45:27 +0000
Received: from [85.158.138.51:38384] by server-10.bemta-3.messagelabs.com id
	84/ED-10609-37CBC215; Tue, 26 Feb 2013 13:45:23 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361886312!19528504!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14553 invoked from network); 26 Feb 2013 13:45:22 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 13:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9199699"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 13:44:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 08:44:10 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UAKpF-0005mk-UY;
	Tue, 26 Feb 2013 13:44:10 +0000
Message-ID: <512CBC29.9020404@citrix.com>
Date: Tue, 26 Feb 2013 13:44:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<51236654.3050709@citrix.com> <512CA5AE.4090002@eu.citrix.com>
In-Reply-To: <512CA5AE.4090002@eu.citrix.com>
X-Enigmail-Version: 1.4
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMjYvMDIvMTMgMTI6MDgsIEdlb3JnZSBEdW5sYXAgd3JvdGU6Cj4gT24gMDIvMTkvMjAxMyAx
MTo0NyBBTSwgQW5kcmV3IENvb3BlciB3cm90ZToKPj4gT24gMTkvMDIvMTMgMDk6MjgsIEphbiBC
ZXVsaWNoIHdyb3RlOgo+Pj4+Pj4gT24gMTguMDIuMTMgYXQgMTk6MTEsIEFuZHJldyBDb29wZXIg
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOgo+Pj4+IEhlbGxvLAo+Pj4+Cj4+Pj4g
T3VyIHRlc3RpbmcgaGFzIGRpc2NvdmVyZWQgYSBjcmFzaCAocGFnZWZhdWx0IGF0IDB4MDAwMDAw
MDAwMDAwMDAwOCkKPj4+PiB3aGljaCBJIGhhdmUgdHJhY2tlZCBkb3duIHRvIGJhZCBfX3J1bnFf
cmVtb3ZlKCkgaW4gY3NjaGVkX3ZjcHVfc2xlZXAoKQo+Pj4+IGluIHNjaGVkX2NyZWRpdC5jIChi
ZWNhdXNlIGEgc3RhdGljIGZ1bmN0aW9uIG9mIHRoZSBzYW1lIG5hbWUgYWxzbwo+Pj4+IGV4aXN0
cyBpbiBzY2hlZF9jcmVkaXQyLmMsIHdoaWNoIGNvbmZ1c2VkIG1hdHRlcnMgdG8gc3RhcnQgd2l0
aCkKPj4+Pgo+Pj4+IFRoZSB0ZXN0IGNhc2Ugd2FzIGEgbG9vcCBvZiBsb2NhbGhvc3QgbWlncmF0
ZSBvZiBhIDF2Y3B1IEhWTSB3aW44Cj4+Pj4gZG9tYWluLiAgVGhlIHRlc3QgY2FzZSBpdHNlbGYg
aGFzIHBhc3NlZCBtYW55IHRpbWVzIGluIHRoZSBwYXN0IG9uIHRoZQo+Pj4+IHNhbWUgWGVuIGNv
ZGViYXNlIChYZW4tNC4xLjMpLCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdmVyeSByYXJlLiAgVGhl
cmUKPj4+PiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYW55IHJlbGV2YW50IGNoYW5nZXMgYmV0d2Vl
biB0aGUgdmVyc2lvbiBvZiBYZW4gaW4KPj4+PiB0aGUgdGVzdCBhbmQgeGVuLTQuMS10ZXN0aW5n
Lgo+Pj4+Cj4+Pj4gVGhlIGZhaWx1cmUgaXRzZWxmIGlzIGJlY2F1c2Ugb2YgYSBYRU5fRE9NQ1RM
X3NjaGVkdWxlcl9vcCAodHJhY2UgYmVsb3cpCj4+Pj4gZnJvbSBkb20wLCB0YXJnZXRpbmcgdGhl
IFZDUFUgb2YgdGhlIG1pZ3JhdGluZyBkb21haW4uCj4+Pj4KPj4+PiAoWEVOKSBYZW4gY2FsbCB0
cmFjZToKPj4+PiAoWEVOKSAgICAgICBbPGZmZmY4MmM0ODAxMTZhMTQ+XSBjc2NoZWRfdmNwdV9z
bGVlcCsweDQ0LzB4NzAKPj4+PiAoWEVOKSAgICAgIDBbPGZmZmY4MmM0ODAxMjAxMTc+XSB2Y3B1
X3NsZWVwX25vc3luYysweGU3LzB4M2IwCj4+Pj4gKFhFTikgICAgIDEyWzxmZmZmODJjNDgwMTIw
M2U5Pl0gdmNwdV9zbGVlcF9zeW5jKzB4OS8weDUwCj4+Pj4gKFhFTikgICAgIDE0WzxmZmZmODJj
NDgwMTFmZDRjPl0gc2NoZWRfYWRqdXN0KzB4YWMvMHgyMzAKPj4+PiAoWEVOKSAgICAgMjRbPGZm
ZmY4MmM0ODAxMDJiYzE+XSBkb19kb21jdGwrMHg3MzEvMHgxMTMwCj4+Pj4gKFhFTikgICAgIDY0
WzxmZmZmODJjNDgwMjAxM2M0Pl0gY29tcGF0X2h5cGVyY2FsbCsweDc0LzB4ODAKPj4+Pgo+Pj4+
IFRoZSByZWxldmFudCBwYXJ0IG9mIGNzY2hlZF92Y3B1X3NsZWVwKCkgaXMKPj4+Pgo+Pj4+ICAg
ICAgZWxzZSBpZiAoIF9fdmNwdV9vbl9ydW5xKHN2YykgKQo+Pj4+ICAgICAgICAgIF9fcnVucV9y
ZW1vdmUoc3ZjKTsKPj4+Pgo+Pj4+IHdoaWNoIGRpc2Fzc2VtYmxlcyB0bwo+Pj4+Cj4+Pj4gZmZm
ZjgyYzQ4MDExNmEwMTogICAgICAgNDkgOGIgMTAgICAgICAgICAgICAgICAgbW92ICAgICglcjgp
LCVyZHgKPj4+PiBmZmZmODJjNDgwMTE2YTA0OiAgICAgICA0YyAzOSBjMiAgICAgICAgICAgICAg
ICBjbXAgICAgJXI4LCVyZHgKPj4+PiBmZmZmODJjNDgwMTE2YTA3OiAgICAgICA3NSAwNyAgICAg
ICAgICAgICAgICAgICBqbmUgICAgZmZmZjgyYzQ4MDExNmExMAo+Pj4+IDxjc2NoZWRfdmNwdV9z
bGVlcCsweDQwPgo+Pj4+IGZmZmY4MmM0ODAxMTZhMDk6ICAgICAgIGYzIGMzICAgICAgICAgICAg
ICAgICAgIHJlcHogcmV0cQo+Pj4+IGZmZmY4MmM0ODAxMTZhMGI6ICAgICAgIDBmIDFmIDQ0IDAw
IDAwICAgICAgICAgIG5vcGwgICAweDAoJXJheCwlcmF4LDEpCj4+Pj4gZmZmZjgyYzQ4MDExNmEx
MDogICAgICAgNDkgOGIgNDAgMDggICAgICAgICAgICAgbW92ICAgIDB4OCglcjgpLCVyYXgKPj4+
PiBmZmZmODJjNDgwMTE2YTE0OiAgICAgICA0OCA4OSA0MiAwOCAgICAgICAgICAgICBtb3YgICAg
JXJheCwweDgoJXJkeCkgIwo+Pj4+IDwtIFBhZ2VmYXVsdCBoZXJlCj4+Pj4gZmZmZjgyYzQ4MDEx
NmExODogICAgICAgNDggODkgMTAgICAgICAgICAgICAgICAgbW92ICAgICVyZHgsKCVyYXgpCj4+
Pj4gZmZmZjgyYzQ4MDExNmExYjogICAgICAgNGQgODkgNDAgMDggICAgICAgICAgICAgbW92ICAg
ICVyOCwweDgoJXI4KQo+Pj4+IGZmZmY4MmM0ODAxMTZhMWY6ICAgICAgIDRkIDg5IDAwICAgICAg
ICAgICAgICAgIG1vdiAgICAlcjgsKCVyOCkKPj4+Pgo+Pj4+IFRoZSByZWxldmFudCBjcmFzaCBy
ZWdpc3RlcnMgZnJvbSB0aGUgcGFnZWZhdWx0IGFyZToKPj4+PiByYXg6IDAwMDAwMDAwMDAwMDAw
MDAKPj4+PiByZHg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+PiAgIHI4OiBmZmZmODMwODBjODllZDkw
Cj4+Pj4KPj4+PiBJZiBJIGFtIHJlYWRpbmcgdGhlIGNvZGUgY29ycmVjdGx5LCB0aGlzIG1lYW5z
IHRoYXQgcnVucS0+bmV4dCBpcyBOVUxMLAo+Pj4+IHNvIHdlIGZhaWwgbGlzdF9lbXB0eSgpIGFu
ZCBlcnJvbmVvdXNseSBwYXNzIF9fdmNwdV9vbl9ydW5xKCkuICBXZSB0aGVuCj4+Pj4gZmFpbCB3
aXRoIGEgZmF1bHQgd2hlbiB0cnlpbmcgdG8gdXBkYXRlIHJ1bnEtPnByZXYsIHdoaWNoIGlzIGFs
c28gTlVMTC4KPj4+Pgo+Pj4+IFRoZSBvbmx5IHBsYWNlIEkgY2FuIHNwb3QgaW4gdGhlIGNvZGUg
d2hlcmUgdGhlIHJ1bnEtPntuZXh0LHByZXZ9IGNvdWxkCj4+Pj4gY29uY2VpdmFibHkgYmUgTlVM
TCBpcyBpbiBjc2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBtZW1zZXQoKSBhbmQKPj4+
PiBJTklUX0xJU1RfSEVBRCgpLiAgVGhpcyBpcyBsb2dpY2FsbHkgc2Vuc2libGUgaW4gY29tYmlu
YXRpb24gd2l0aCB0aGUKPj4+PiBsb2NhbGhvc3QgbWlncmF0ZSBsb29wLCBhbmQgSSBjYW50IGlt
bWVkaWF0ZWx5IHNlZSBhbnl0aGluZyB0byBwcmV2ZW50Cj4+Pj4gdGhpcyByYWNlIGhhcHBlbmlu
Zy4KPj4+IEJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVkX2FsbG9jX3ZkYXRhKCkg
ZG9lc24ndCBzdG9yZQo+Pj4gc3ZjIGludG8gdmMtPnNjaGVkX3ByaXY7IHRoYXQncyBiZWluZyBk
b25lIGJ5IHRoZSBnZW5lcmljCj4+PiBzY2hlZHVsZXIgY29kZSBvbmNlIHRoZSBhY3RvciByZXR1
cm5zLgo+Pgo+PiBEJ29oIHllcyAtIEkgb3Zlcmxvb2tlZCB0aGF0Lgo+Pgo+Pj4KPj4+IFNvIEkn
ZCByYXRoZXIgc3VzcGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwgd2hpY2ggaXMgZWFz
aWx5Cj4+PiBwb3NzaWJsZSB3aGVuIHJhY2luZyB3aXRoIHNjaGVkX21vdmVfZG9tYWluKCkgKGFz
IG9wcG9zZWQgdG8KPj4+IHNjaGVkdWxlX2NwdV9zd2l0Y2goKSwgd2hlcmUgdGhlIG5ldyBwb2lu
dGVyIGdldHMgc3RvcmVkCj4+PiBfYmVmb3JlXyBkZS1hbGxvY2F0aW5nIHRoZSBvbGQgb25lKS4K
Pj4KPj4+Cj4+PiBIb3dldmVyLCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyB3ZWxsIGFzIHNjaGVk
dWxlX2NwdV9zd2l0Y2goKSkKPj4+IGdldCBjYWxsZWQgb25seSBmcm9tIENQVSBwb29scyBjb2Rl
LCBhbmQgSSB3b3VsZCBndWVzcyBDUFUgcG9vbHMKPj4+IGFyZW4ndCBpbnZvbHZlZCBoZXJlLCBh
bmQgeW91IGRvbid0IGluIHBhcmFsbGVsIHNvZnQgb2ZmbGluZS9vbmxpbmUKPj4+IHBDUFUtcyAo
YXMgSSdtIHN1cmUgeW91IG90aGVyd2lzZSB3b3VsZCBoYXZlIG1lbnRpb25lZCBpdCkuCj4+Pgo+
Pj4gQnV0IHdhaXQgLSBsaWJ4bF9fZG9tYWluX21ha2UoKSBfdW5jb25kaXRpb25hbGx5XyBjYWxs
cwo+Pj4geGNfY3B1cG9vbF9tb3ZlZG9tYWluKCksIGFzIGRvZXMgWGVuZERvbWFpbkluZm8ncwo+
Pj4gX2NvbnN0cnVjdERvbWFpbigpLiBUaGUgcmVhc29uIGZvciB0aGlzIGVzY2FwZXMgbWUgLSBK
w7xyZ2VuPyBZZXQKPj4+IEknZCBleHBlY3QgdGhlIHBvb2wgSUQgbWF0Y2hpbmcgY2hlY2sgdG8g
c2hvcnQgY3V0IHRoZSByZXN1bHRpbmcKPj4+IHN5c2N0bCwgaS5lLiBzY2hlZF9tb3ZlX2RvbWFp
bigpIG91Z2h0IHRvIG5vdCBiZSByZWFjaGVkIGFueXdheQo+Pj4gKHdvcnRoIHZlcmlmeWluZyBv
ZiBjb3Vyc2UpLgo+Pj4KPj4+IFRoZSByYWNlIHRoZXJlIG5ldmVydGhlbGVzcyBvdWdodCB0byBi
ZSBmaXhlZC4KPj4+Cj4+PiBKYW4KPj4KPj4gT3VyIHRvb2xzdGFjayBob29rcyBkaXJlY3RseSBp
bnRvIGxpYnhjIGFuZCBpcyBjb21wbGV0ZWx5IGlnbm9yYW50IG9mCj4+IGNwdXBvb2xzLiAgTG9v
a2luZyBhdCB0aGUgY3Jhc2ggbW9yZSBjbG9zZWx5LCBpdCBtaWdodCBiZSBhIHJhY2UgZWxzZXdo
ZXJlCj4+Cj4+IEFub3RoZXIgZG9tMCB2Y3B1IGlzIGluIGFuIEhWTU9QX3RyYWNrX2RpcnR5X3Zy
YW0gaHlwZXJjYWxsLCBhbmQgdGhlCj4+IGFzc29jaWF0ZWQgWGVuIHN0YWNrIHRyYWNlIGlzCj4+
Cj4+IFtmZmZmODJjNDgwMTc3N2IyXSB0aW1lX2NhbGlicmF0aW9uX3N0ZF9yZW5kZXp2b3VzKzB4
YjIvMHhjMAo+PiAgIGZmZmY4MmM0ODAxNzJkMTIgIF9fc21wX2NhbGxfZnVuY3Rpb25faW50ZXJy
dXB0KzB4NjIvMHhiMAo+PiAgIGZmZmY4MmM0ODAxNzMzOWUgIHNtcF9jYWxsX2Z1bmN0aW9uX2lu
dGVycnVwdCsweDRlLzB4OTAKPj4gICBmZmZmODJjNDgwMTRhNjVhICBjYWxsX2Z1bmN0aW9uX2lu
dGVycnVwdCsweDJhLzB4MzAKPj4gICBmZmZmODJjNDgwMTIyM2IyICBfc3Bpbl9sb2NrKzB4MTIv
MHgyMAo+PiAgIGZmZmY4MmM0ODAxNzM0YWIgIGZsdXNoX2FyZWFfbWFzaysweGNiLzB4MWMwCj4+
ICAgZmZmZjgyYzQ4MDFjODYyYSAgcGFnaW5nX2xvZ19kaXJ0eV9yYW5nZSsweDNhLzB4NzgwCj4+
ICAgZmZmZjgyYzQ4MDEyMWVhOCAgY3B1bWFza19yYWlzZV9zb2Z0aXJxKzB4NzgvMHg4MAo+PiAg
IGZmZmY4MmM0ODAxMTdlZDMgIGNzY2hlZF92Y3B1X3dha2UrMHgxOTMvMHg0MjAKPj4gICBmZmZm
ODJjNDgwMTRhNWZhICBldmVudF9jaGVja19pbnRlcnJ1cHQrMHgyYS8weDMwCj4+ICAgZmZmZjgy
YzQ4MDFmMjFjNyAgaGFwX3RyYWNrX2RpcnR5X3ZyYW0rMHgxMzcvMHgxYzAKPj4gICBmZmZmODJj
NDgwMWFkM2ZkICBkb19odm1fb3ArMHgxNmRkLzB4MWY1MAo+PiAgIGZmZmY4MmM0ODAxMDYyNTEg
IGV2dGNobl9zZW5kKzB4YTEvMHgxNjAKPj4gICBmZmZmODJjNDgwMTA2ZDM2ICBkb19ldmVudF9j
aGFubmVsX29wKzB4ODc2LzB4ZmQwCj4+ICAgZmZmZjgyYzQ4MDFmOTAyNyAgY29tcGF0X3VwZGF0
ZV9kZXNjcmlwdG9yKzB4MjcvMHgzMAo+PiAgIGZmZmY4MmM0ODAxMzU0ZjggIGNvbXBhdF9tdWx0
aWNhbGwrMHgxOTgvMHgzODAKPj4gICBmZmZmODJjNDgwMTRhNWZhICBldmVudF9jaGVja19pbnRl
cnJ1cHQrMHgyYS8weDMwCj4+ICAgZmZmZjgyYzQ4MDIwMTNjNCAgY29tcGF0X2h5cGVyY2FsbCsw
eDc0LzB4ODAKPj4KPj4gdGhlIGhhcF90cmFja19kaXJ0eV92cmFtKCkgYW5kIHBhZ2luZ19sb2df
ZGlydHlfcmFuZ2UoKSBhcmUgcGFydCBvZiB0aGUKPj4gc2FtZSBsb2dpY2FsIGNhbGwgdHJhY2Us
IGJ1dCBpdCBhcHBlYXJzIHRoYXQgd2UgaGF2ZSB0YWtlbiBhbgo+PiBldmVudF9jaGVja19pbnRl
cnJ1cHQoKSBpbiB0aGUgbWlkZGxlIGFuZCBjYWxsZWQgc2NoZWR1bGUoKSBvZmYgdGhlCj4+IGJv
dHRvbSBvZiBpdCwgY2FsbGluZyBjc2NoZWRfdmNwdV93YWtlKCkuCj4+Cj4+IEkgYW0gY3VycmVu
dGx5IHRyeWluZyB0byByZWFzb24gYXMgdG8gd2hldGhlciBpdCBpcyBwb3NzaWJsZSBmb3IgYSBy
YWNlCj4+IGJldHdlZW4gY3NjaGVkX3ZjcHVfe3NsZWVwLHdha2V9KCkgY291bGQgcmVzdWx0IGlu
IHRoZSBzZWVuIGNyYXNoLCBidXQKPj4gaXQgY2VydGFpbmx5IGxvb2tzIGxpa2UgYSBzbW9raW5n
IGd1bi4KPgo+IEFueSBtb3JlIHByb2dyZXNzIG9uIHRoaXMgb25lPwo+Cj4gSW4gdGhlb3J5IGFs
bCBvZiB0aG9zZSBzaG91bGQgYmUgbWFkZSBtdXR1YWxseSBleGNsdXNpdmUgYnkgaG9sZGluZyB0
aGUgCj4gbG9jayBvZiB0aGUgcnVucXVldWUgb24gd2hpY2ggdGhlIFZDUFUgaXMgcnVubmluZy4K
Pgo+IEFueSBjaGFuY2UgdGhlcmUncyBhIHJhY2Ugd2l0aCB0aGUgYXNzaWdubWVudCBvZiB0aGUg
dmNwdSAtLSB0aGF0IGlzLCBhIAo+IHJhY2UgaW4gdmNwdV9zY2hlZHVsZV9sb2NrKCkgc3VjaCB0
aGF0IHNvbWVvbmUgZW5kcyB1cCBncmFiYmluZyB0aGUgCj4gd3JvbmcgbG9jaz8KPgo+IEkgdGhp
bmsgdGhhdCBpbiB0aGVvcnkgb25jZSB5b3UgY2FsbCBJTklUX0xJU1RfSEVBRCwgbm9uZSBvZiB0
aG9zZSAKPiBwb2ludGVycyBzaG91bGQgZXZlciBiZSBzZXQgdG8gemVybzsgaWYgb25lIGV2ZXIg
d2VyZSBpdCBtaWdodCBnZXQgCj4gcGFzc2VkIGFyb3VuZCBhIGJpdCBiZWZvcmUgYWN0dWFsbHkg
YmVpbmcgZm9sbG93ZWQuICBBbnkgY2hhbmNlIHRoZXJlJ3MgCj4gc29tZXRoaW5nIHVuaW5pdGlh
bGl6ZWQgc29tZXdoZXJlPwo+Cj4gQW5kIG9mIGNvdXJzZSwgaWYgYWxsIGVsc2UgZmFpbHMsIHRo
ZXJlJ3MgZ29vZCBvbGQtZmFzaGlvbmVkIG1lbW9yeSAKPiBjbG9iYmVyaW5nIGFzIGEgcG9zc2li
aWxpdHkuLi4KPgo+ICAgLUdlb3JnZQoKTm8gbW9yZSBwcm9ncmVzcyBJIGFtIGFmcmFpZCAtIE90
aGVyIG1vcmUgZWFzaWx5IHJlcHJvZHVjaWJsZSBidWdzIGNhbWUgdXAuCgpJIGRpZCBpZGVudGlm
eSBhbm90aGVyIHRpY2tldCBpbiBvdXIgc3lzdGVtIHdoaWNoIGdvdCBtaXMtY2xhc2lmaWVkLAp3
aGljaCBhcHBlYXJzIHRvIGJlIHRoZSBzYW1lL3NpbWlsYXIgcmFjZSBjb25kaXRpb24KCihYRU4p
IFhlbiBCVUcgYXQgc2NoZWRfY3JlZGl0LmM6MjA0CihYRU4pIC0tLS1bIFhlbi00LjEuMyAgeDg2
XzY0ICBkZWJ1Zz1uICBOb3QgdGFpbnRlZCBdLS0tLQooWEVOKSBDUFU6ICAgIDExCihYRU4pIFJJ
UDogICAgZTAwODpbPGZmZmY4MmM0ODAxMTdiYmI+XSBjc2NoZWRfdmNwdV93YWtlKzB4M2NiLzB4
M2YwCihYRU4pIFJGTEFHUzogMDAwMDAwMDAwMDAxMDAwMyAgIENPTlRFWFQ6IGh5cGVydmlzb3IK
KFhFTikgcmF4OiBmZmZmODMwOTk0YjM3NDM4ICAgcmJ4OiBmZmZmODMwOTk0YjM2MDAwICAgcmN4
OiBmZmZmODMwODM2YWQxZDYwCihYRU4pIHJkeDogZmZmZjgzMDk5NGIzNjAwMCAgIHJzaTogMDAw
MDAwMDAwMDAwMDAwMCAgIHJkaTogZmZmZjgyYzQ4MDJjYjdjMAooWEVOKSByYnA6IGZmZmY4MzBh
OTMzNDNmMjAgICByc3A6IGZmZmY4MzA4MzZhOTdkODAgICByODogIGZmZmY4MzBhOTMzNDNmMjAK
KFhFTikgcjk6ICAwMDAwMDAwMDAwMDAwMDBiICAgcjEwOiAwMDAwMDAwMDAwMDAwMDBiICAgcjEx
OiBmZmZmODJjNDgwMmJhMGUwCihYRU4pIHIxMjogZmZmZjgzMDk5NGIzNzUwMCAgIHIxMzogMDAw
MDAxYjE2NjI1N2ViYSAgIHIxNDogZmZmZjgyYzQ4MDJjYjdjMAooWEVOKSByMTU6IGZmZmY4MmM0
ODAyYmEwZTAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDI2ZjAK
KFhFTikgY3IzOiAwMDAwMDAwYTkyNzIxMDAwICAgY3IyOiAwMDAwMDAwMDA4ZWU3ZGM4CihYRU4p
IGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IDAwMDAgICBj
czogZTAwOAooWEVOKSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDgzNmE5N2Q4MDoK
KFhFTikgICAgZmZmZjgzMDBiZTZiZjdkMCAwMDAwMDAwMGZlZDAwMGYwIGZmZmY4MmM0ODAxNGEx
MzAgMDAwMDAwMDAwMDAwMDAwMAooWEVOKSAgICBmZmZmODMwODM2YTk3ZjE4IGZmZmY4MzA4MzZh
OTgwMTAgZmZmZjgyYzQ4MDE0OWRkYSBmZmZmODMwOTk0YjM2MDAwCihYRU4pICAgIGZmZmY4MzAw
YmU2YWEwMDAgZmZmZjgzMDk5NGIzNzUwMCAwMDAwMDFiMTY2MjU3ZWJhIGZmZmY4MmM0ODAyY2I3
YzAKKFhFTikgICAgZmZmZjgyYzQ4MDJiYTBlMCBmZmZmODJjNDgwMTIwNmUwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDI4NgooWEVOKSAgICAwMDAwMDFiMTMyMDAwOWYxIDAwMDAwMDAw
MDAwMDAwMDMgMDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwCihYRU4pICAgIGZmZmY4
MzAwYmU2YWEwMDAgZmZmZjgzMDBiZTZhYjc5MCBmZmZmODJjNDgwMWI3NjIwIGZmZmY4MzA0NTAx
YTcwMTAKKFhFTikgICAgZmZmZjgzMDQ1MDFhNzAxMCBmZmZmODJjNDgwMTRmMTNkIGZmZmY4MzAw
YmU2YWI3OTAgZmZmZjgzMDBiZTZhYjc5MAooWEVOKSAgICAwMDAwMDFiMTY2MjU3ZGU0IGZmZmY4
MmM0ODAxYjc2NDIgZmZmZjgzMDgzNmE5ZTEwMCBmZmZmODJjNDgwMTIzODhjCihYRU4pICAgIGZm
ZmY4MzAwYmU2YWI3ZDAgZmZmZjgzMDgzNmE5ZTEwMCBmZmZmODMwNDUwMWE3MDE4IGZmZmY4MmM0
ODAxMjNkMzUKKFhFTikgICAgZmZmZjgyYzQ4MDFhZjQ4NiAwMDAwMDAwMDAwMDAwMDBiIGZmZmZm
ZmZmZmZmZmZmZmYgZmZmZjgzMDgzNmE5N2YxOAooWEVOKSAgICBmZmZmODJjNDgwMmE4NTAwIGZm
ZmY4MmM0ODAyYWM1MDAgMDAwMDAxYjE2NjI1NDMxZCBmZmZmODJjNDgwMTIxNmI1CihYRU4pICAg
IGZmZmY4MzA4MzZhOTdmMTggZmZmZjgzMDBiZjJmMDAwMCBmZmZmODMwMGJlNzRjMDAwIGZmZmY4
MmM0ODAyYmEwZTAKKFhFTikgICAgZmZmZjgzMDgzNmE5ZTA2MCBmZmZmODJjNDgwMTRmZGM1IDAw
MDAwMDAwMDAwMDAwMGIgMDAwMDAwMDAwMDAwMDA4ZAooWEVOKSAgICBmZmZmZmZmZmZmZmZmZmZl
IGZmZmZmZjAwN2I0MTEyMjggZmZmZmZmMDA3YjQxMTIwMCBmZmZmZmZmZWJhNGMxYjkwCihYRU4p
ICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MDQ0YjhjMCBmZmZmZmYwMDdiNTgzZTEwIGZm
ZmZmZjAwN2I1ODNlODgKKFhFTikgICAgZmZmZmZmZmViYTRjMWQxMCAwMDAwMDAwMDAwMDAwM2U4
IDAwMDAwMDAwMDAwZjQyNDAgMDAwMDAwMDAwMDAwMDAwMAooWEVOKSAgICAwMDAwMDAwMDAwMDAw
MDAxIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwNmQwMDAwMDAwMCBmZmZmZmZmZjgwNzM3MWM2CihY
RU4pICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDI0NiBmZmZmZmZmZWJhNGMxYjkw
IDAwMDAwMDAwMDAwMDAwMDAKKFhFTikgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMAooWEVOKSAgICAwMDAwMDAwMDAw
MDAwMDBiIGZmZmY4MzAwYmYyZjAwMDAgMDAwMDAwNDNiNjdkMjg4MCAwMDAwMDAwMDAwMDAwMDAw
CihYRU4pIFhlbiBjYWxsIHRyYWNlOgooWEVOKSAgICAgICBbPGZmZmY4MmM0ODAxMTdiYmI+XSBj
c2NoZWRfdmNwdV93YWtlKzB4M2NiLzB4M2YwCihYRU4pICAgICAgMls8ZmZmZjgyYzQ4MDE0YTEz
MD5dIHNtcF9hcGljX3RpbWVyX2ludGVycnVwdCsweDUwLzB4OTAKKFhFTikgICAgICA2WzxmZmZm
ODJjNDgwMTQ5ZGRhPl0gYXBpY190aW1lcl9pbnRlcnJ1cHQrMHgyYS8weDMwCihYRU4pICAgICAx
M1s8ZmZmZjgyYzQ4MDEyMDZlMD5dIHZjcHVfd2FrZSsweDE4MC8weDYwMAooWEVOKSAgICAgMjJb
PGZmZmY4MmM0ODAxYjc2MjA+XSBwdF90aW1lcl9mbisweDAvMHgzMAooWEVOKSAgICAgMjVbPGZm
ZmY4MmM0ODAxNGYxM2Q+XSB2Y3B1X2tpY2srMHgxZC8weDgwCihYRU4pICAgICAyOVs8ZmZmZjgy
YzQ4MDFiNzY0Mj5dIHB0X3RpbWVyX2ZuKzB4MjIvMHgzMAooWEVOKSAgICAgMzFbPGZmZmY4MmM0
ODAxMjM4OGM+XSBleGVjdXRlX3RpbWVyKzB4NGMvMHg3MAooWEVOKSAgICAgMzVbPGZmZmY4MmM0
ODAxMjNkMzU+XSB0aW1lcl9zb2Z0aXJxX2FjdGlvbisweDg1LzB4MjIwCihYRU4pICAgICAzNls8
ZmZmZjgyYzQ4MDFhZjQ4Nj5dIGh2bV92Y3B1X2hhc19wZW5kaW5nX2lycSsweDc2LzB4ZDAKKFhF
TikgICAgIDQzWzxmZmZmODJjNDgwMTIxNmI1Pl0gX19kb19zb2Z0aXJxKzB4NjUvMHg5MAooWEVO
KSAgICAgNDlbPGZmZmY4MmM0ODAxNGZkYzU+XSBpZGxlX2xvb3ArMHgyNS8weDUwCihYRU4pICAg
CihYRU4pCihYRU4pICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKFhF
TikgUGFuaWMgb24gQ1BVIDExOgooWEVOKSBYZW4gQlVHIGF0IHNjaGVkX2NyZWRpdC5jOjIwNAoo
WEVOKSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCgpUaGUgYnVnIGlu
IHF1ZXN0aW9uIGlzIEJVR19PTiggY3B1ICE9IHN2Yy0+dmNwdS0+cHJvY2Vzc29yICk7CgpUaGlz
IGlzIHN1c3BjaW91cyBhcywgbGlrZSBiZWZvcmUsIHRoZXJlIGlzIGFuIExBUElDLXRyaWdnZXJl
ZCBpbnRlcnJ1cHQKaW4gdGhlIG1pZGRsZSBvZiBhIHNjaGVkdWxpbmcgY29kZXBhdGguICBBZ2Fp
biwgaXQgaGFzIGJlZW4gc2VlbiBvbmx5Cm9uY2UgdGhyb3VnaCBtdWx0aXBsZSBjeWNsZXMgb2Yg
dGVzdGluZy4KCklmIHlvdSBoYXZlIGFueSBpZGVhcyB0aGVuIGZhbnRhc3RpYywgYnV0IEkgaGF2
ZSBub3QgZm9yZ290dGVuIGFib3V0IGl0Ci0ganVzdCBoYWQgb3RoZXIgc3R1ZmYgY29tZSB1cC4g
IEkgd2lsbCBnZXQgYmFjayB0byBpdCBhdCBzb21lIHBvaW50IQoKfkFuZHJldwoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:46:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:46: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 1UAKrb-0001uP-NS; Tue, 26 Feb 2013 13:46:35 +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 1UAKrZ-0001uD-PQ
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:46:33 +0000
Received: from [85.158.143.99:6080] by server-3.bemta-4.messagelabs.com id
	D2/1E-02186-9BCBC215; Tue, 26 Feb 2013 13:46:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361886390!17813788!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27617 invoked from network); 26 Feb 2013 13:46:31 -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; 26 Feb 2013 13:46:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAKrR-000P1L-Gp; Tue, 26 Feb 2013 13:46:25 +0000
Date: Tue, 26 Feb 2013 13:46:25 +0000
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20130226134625.GC93966@ocelot.phlegethon.org>
References: <1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
	<512CB075.7050202@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CB075.7050202@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:54 +0000 on 26 Feb (1361883253), George Dunlap wrote:
> On 02/26/2013 12:21 PM, Ian Campbell wrote:
> >On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
> >>On 26/02/13 11:52, Tim Deegan wrote:
> >>>How about ASSERT(((typeof credits) val) == val) before the assignment?
> >
> >Why not just
> >	ASSERT(credits == val); /* Ensure we haven't truncated val */
> 
> I prefer this one to having "typeof credits" in the ASSERT.  The main 
> thing is just to minimize the amount of effort a programmer has to 
> expend trying to figure out what's going on, so he can spend it on 
> something else. :-)

Quite.  It occurred to me afterwards that we could have a FITS_IN()
macro for that purpose.  Or, as mentioned, a comment. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:46:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:46: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 1UAKrb-0001uP-NS; Tue, 26 Feb 2013 13:46:35 +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 1UAKrZ-0001uD-PQ
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:46:33 +0000
Received: from [85.158.143.99:6080] by server-3.bemta-4.messagelabs.com id
	D2/1E-02186-9BCBC215; Tue, 26 Feb 2013 13:46:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361886390!17813788!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27617 invoked from network); 26 Feb 2013 13:46:31 -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; 26 Feb 2013 13:46:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAKrR-000P1L-Gp; Tue, 26 Feb 2013 13:46:25 +0000
Date: Tue, 26 Feb 2013 13:46:25 +0000
From: Tim Deegan <tim@xen.org>
To: George Dunlap <george.dunlap@eu.citrix.com>
Message-ID: <20130226134625.GC93966@ocelot.phlegethon.org>
References: <1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
	<512C9BD2.70903@eu.citrix.com>
	<512CAEA902000078000C10BF@nat28.tlf.novell.com>
	<20130226115229.GB93966@ocelot.phlegethon.org>
	<512CA3D3.3040002@citrix.com>
	<1361881287.7099.0.camel@hastur.hellion.org.uk>
	<512CB075.7050202@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CB075.7050202@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:54 +0000 on 26 Feb (1361883253), George Dunlap wrote:
> On 02/26/2013 12:21 PM, Ian Campbell wrote:
> >On Tue, 2013-02-26 at 12:00 +0000, David Vrabel wrote:
> >>On 26/02/13 11:52, Tim Deegan wrote:
> >>>How about ASSERT(((typeof credits) val) == val) before the assignment?
> >
> >Why not just
> >	ASSERT(credits == val); /* Ensure we haven't truncated val */
> 
> I prefer this one to having "typeof credits" in the ASSERT.  The main 
> thing is just to minimize the amount of effort a programmer has to 
> expend trying to figure out what's going on, so he can spend it on 
> something else. :-)

Quite.  It occurred to me afterwards that we could have a FITS_IN()
macro for that purpose.  Or, as mentioned, a comment. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:54:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:54: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 1UAKyl-0002Cz-KU; Tue, 26 Feb 2013 13:53:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <don@cloudswitch.com>) id 1UAKyj-0002Cp-Hw
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:53:57 +0000
Received: from [85.158.137.99:64818] by server-2.bemta-3.messagelabs.com id
	BB/3E-25961-47EBC215; Tue, 26 Feb 2013 13:53:56 +0000
X-Env-Sender: don@cloudswitch.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361886833!17318386!1
X-Originating-IP: [206.225.164.217]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjIyNS4xNjQuMjE3ID0+IDkwMDc0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2279 invoked from network); 26 Feb 2013 13:53:54 -0000
Received: from hub021-nj-2.exch021.serverdata.net (HELO
	hub021-nj-2.exch021.serverdata.net) (206.225.164.217)
	by server-11.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Feb 2013 13:53:54 -0000
Received: from don-lt.don.CloudSwitch.com (72.74.68.135) by
	east.exch021.serverdata.net (10.240.4.34) with Microsoft SMTP Server
	(TLS) id 14.2.318.1; Tue, 26 Feb 2013 05:53:53 -0800
Message-ID: <512CBE70.2000902@CloudSwitch.com>
Date: Tue, 26 Feb 2013 08:53:52 -0500
From: Don Slutz <Don@CloudSwitch.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
	<1361469460-18771-4-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361469460-18771-4-git-send-email-david.vrabel@citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] kexec/xen: use libxc to get location of
 crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/21/13 12:57, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Use xc_kexec_get_range(KEXEC_RANGE_MA_CPU) instead of parsing
> /proc/iomem (which is only populated by non-upstream ("classic") Xen
> kernels).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>   kexec/crashdump-xen.c |   61 ++++++++++++++++++++++++++++---------------------
>   1 files changed, 35 insertions(+), 26 deletions(-)
>
> diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
> index ff4706c..13335a5 100644
> --- a/kexec/crashdump-xen.c
> +++ b/kexec/crashdump-xen.c
> @@ -163,42 +163,51 @@ unsigned long xen_architecture(struct crash_elf_info *elf_info)
>   	return machine;
>   }
>   
> -static int xen_crash_note_callback(void *UNUSED(data), int nr,
> -				   char *UNUSED(str),
> -				   unsigned long base,
> -				   unsigned long length)
> -{
> -	struct crash_note_info *note = xen_phys_notes + nr;
> -
> -	note->base = base;
> -	note->length = length;
> -
> -	return 0;
> -}
> -
> +#ifdef HAVE_LIBXENCTRL
>   int xen_get_nr_phys_cpus(void)
>   {
> -	char *match = "Crash note\n";
> -	int cpus, n;
> +	xc_interface *xc;
> +	int cpu;
>   
>   	if (xen_phys_cpus)
>   		return xen_phys_cpus;
>   
> -	if ((cpus = kexec_iomem_for_each_line(match, NULL, NULL))) {
> -		n = sizeof(struct crash_note_info) * cpus;
> -		xen_phys_notes = malloc(n);
> -		if (!xen_phys_notes) {
> -			fprintf(stderr, "failed to allocate xen_phys_notes.\n");
> +	xc = xc_interface_open(NULL, NULL, 0);
> +	if ( !xc ) {
> +		fprintf(stderr, "failed to open xen control interface.\n");
> +		return -1;
> +	}
> +
> +	for (cpu = 0;; cpu++) {
This code does work.  Not sure why you did not use xc_physinfo() to get 
the number of cpus that there is data for and remove the need for 
calling realloc.
> +		uint64_t size, start;
> +		int ret;
> +
> +		ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_CPU, cpu, &size, &start);
> +		if (ret < 0)
> +			break;
> +
> +		xen_phys_notes = realloc(xen_phys_notes,
> +					 sizeof(*xen_phys_notes) * (cpu + 1));
> +		if (xen_phys_notes == NULL)
>   			return -1;
> -		}
> -		memset(xen_phys_notes, 0, n);
> -		kexec_iomem_for_each_line(match,
> -					  xen_crash_note_callback, NULL);
> -		xen_phys_cpus = cpus;
> +
> +		xen_phys_notes[cpu].base = start;
> +		xen_phys_notes[cpu].length = size;
>   	}
>   
> -	return cpus;
> +	xc_interface_close(xc);
> +
> +	xen_phys_cpus = cpu;
> +
> +	return cpu;
>   }
> +#else
> +int xen_get_nr_phys_cpus(void)
> +{
> +	return -1;
> +}
> +#endif
> +
>   
>   int xen_get_note(int cpu, uint64_t *addr, uint64_t *len)
>   {
    -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 13:54:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 13:54: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 1UAKyl-0002Cz-KU; Tue, 26 Feb 2013 13:53:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <don@cloudswitch.com>) id 1UAKyj-0002Cp-Hw
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 13:53:57 +0000
Received: from [85.158.137.99:64818] by server-2.bemta-3.messagelabs.com id
	BB/3E-25961-47EBC215; Tue, 26 Feb 2013 13:53:56 +0000
X-Env-Sender: don@cloudswitch.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361886833!17318386!1
X-Originating-IP: [206.225.164.217]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjIyNS4xNjQuMjE3ID0+IDkwMDc0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2279 invoked from network); 26 Feb 2013 13:53:54 -0000
Received: from hub021-nj-2.exch021.serverdata.net (HELO
	hub021-nj-2.exch021.serverdata.net) (206.225.164.217)
	by server-11.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Feb 2013 13:53:54 -0000
Received: from don-lt.don.CloudSwitch.com (72.74.68.135) by
	east.exch021.serverdata.net (10.240.4.34) with Microsoft SMTP Server
	(TLS) id 14.2.318.1; Tue, 26 Feb 2013 05:53:53 -0800
Message-ID: <512CBE70.2000902@CloudSwitch.com>
Date: Tue, 26 Feb 2013 08:53:52 -0500
From: Don Slutz <Don@CloudSwitch.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1361469460-18771-1-git-send-email-david.vrabel@citrix.com>
	<1361469460-18771-4-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361469460-18771-4-git-send-email-david.vrabel@citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/4] kexec/xen: use libxc to get location of
 crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/21/13 12:57, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Use xc_kexec_get_range(KEXEC_RANGE_MA_CPU) instead of parsing
> /proc/iomem (which is only populated by non-upstream ("classic") Xen
> kernels).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>   kexec/crashdump-xen.c |   61 ++++++++++++++++++++++++++++---------------------
>   1 files changed, 35 insertions(+), 26 deletions(-)
>
> diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
> index ff4706c..13335a5 100644
> --- a/kexec/crashdump-xen.c
> +++ b/kexec/crashdump-xen.c
> @@ -163,42 +163,51 @@ unsigned long xen_architecture(struct crash_elf_info *elf_info)
>   	return machine;
>   }
>   
> -static int xen_crash_note_callback(void *UNUSED(data), int nr,
> -				   char *UNUSED(str),
> -				   unsigned long base,
> -				   unsigned long length)
> -{
> -	struct crash_note_info *note = xen_phys_notes + nr;
> -
> -	note->base = base;
> -	note->length = length;
> -
> -	return 0;
> -}
> -
> +#ifdef HAVE_LIBXENCTRL
>   int xen_get_nr_phys_cpus(void)
>   {
> -	char *match = "Crash note\n";
> -	int cpus, n;
> +	xc_interface *xc;
> +	int cpu;
>   
>   	if (xen_phys_cpus)
>   		return xen_phys_cpus;
>   
> -	if ((cpus = kexec_iomem_for_each_line(match, NULL, NULL))) {
> -		n = sizeof(struct crash_note_info) * cpus;
> -		xen_phys_notes = malloc(n);
> -		if (!xen_phys_notes) {
> -			fprintf(stderr, "failed to allocate xen_phys_notes.\n");
> +	xc = xc_interface_open(NULL, NULL, 0);
> +	if ( !xc ) {
> +		fprintf(stderr, "failed to open xen control interface.\n");
> +		return -1;
> +	}
> +
> +	for (cpu = 0;; cpu++) {
This code does work.  Not sure why you did not use xc_physinfo() to get 
the number of cpus that there is data for and remove the need for 
calling realloc.
> +		uint64_t size, start;
> +		int ret;
> +
> +		ret = xc_kexec_get_range(xc, KEXEC_RANGE_MA_CPU, cpu, &size, &start);
> +		if (ret < 0)
> +			break;
> +
> +		xen_phys_notes = realloc(xen_phys_notes,
> +					 sizeof(*xen_phys_notes) * (cpu + 1));
> +		if (xen_phys_notes == NULL)
>   			return -1;
> -		}
> -		memset(xen_phys_notes, 0, n);
> -		kexec_iomem_for_each_line(match,
> -					  xen_crash_note_callback, NULL);
> -		xen_phys_cpus = cpus;
> +
> +		xen_phys_notes[cpu].base = start;
> +		xen_phys_notes[cpu].length = size;
>   	}
>   
> -	return cpus;
> +	xc_interface_close(xc);
> +
> +	xen_phys_cpus = cpu;
> +
> +	return cpu;
>   }
> +#else
> +int xen_get_nr_phys_cpus(void)
> +{
> +	return -1;
> +}
> +#endif
> +
>   
>   int xen_get_note(int cpu, uint64_t *addr, uint64_t *len)
>   {
    -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:09:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALD1-0002UX-Mo; Tue, 26 Feb 2013 14:08:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <don@cloudswitch.com>) id 1UALD0-0002UM-8p
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:08:42 +0000
Received: from [85.158.139.83:20697] by server-16.bemta-5.messagelabs.com id
	F6/59-02543-9E1CC215; Tue, 26 Feb 2013 14:08:41 +0000
X-Env-Sender: don@cloudswitch.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361887719!29039702!1
X-Originating-IP: [206.225.164.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjIyNS4xNjQuMjIyID0+IDc4Mzkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16810 invoked from network); 26 Feb 2013 14:08:40 -0000
Received: from hub021-nj-6.exch021.serverdata.net (HELO
	hub021-nj-6.exch021.serverdata.net) (206.225.164.222)
	by server-12.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Feb 2013 14:08:40 -0000
Received: from don-lt.don.CloudSwitch.com (72.74.68.135) by
	east.exch021.serverdata.net (10.240.4.93) with Microsoft SMTP Server
	(TLS) id 14.2.318.1; Tue, 26 Feb 2013 05:58:35 -0800
Message-ID: <512CBF8B.2090008@CloudSwitch.com>
Date: Tue, 26 Feb 2013 08:58:35 -0500
From: Don Slutz <Don@CloudSwitch.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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-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/21/13 12:48, David Vrabel wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image.  This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
>
> The first patch is a simple clean-up.
>
> The second patch allows hypercall structures to be ABI compatible
> between 32- and 64-bit guests (by reusing stuff present for domctls
> and sysctls).  This seems better than having to keep adding compat
> handling for new hypercalls etc.
>
> Patch 3 introduces the new ABI.
>
> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
> the new code.
>
> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
> SHUTDOWN_crash.
>
> Patches 7 and 8 add the libxc API for the kexec calls.
>
> The required patch series for kexec-tools will be posted shortly.
>
> David
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I have tested this patch set on a Fedora 17 dom0 with kernels:

3.7.3-101.fc17.x86_64
3.6.5-1.fc17.x86_64

So:

Tested-by: Don Slutz <Don@CloudSwitch.com>

    -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:09:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALD1-0002UX-Mo; Tue, 26 Feb 2013 14:08:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <don@cloudswitch.com>) id 1UALD0-0002UM-8p
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:08:42 +0000
Received: from [85.158.139.83:20697] by server-16.bemta-5.messagelabs.com id
	F6/59-02543-9E1CC215; Tue, 26 Feb 2013 14:08:41 +0000
X-Env-Sender: don@cloudswitch.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361887719!29039702!1
X-Originating-IP: [206.225.164.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA2LjIyNS4xNjQuMjIyID0+IDc4Mzkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16810 invoked from network); 26 Feb 2013 14:08:40 -0000
Received: from hub021-nj-6.exch021.serverdata.net (HELO
	hub021-nj-6.exch021.serverdata.net) (206.225.164.222)
	by server-12.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Feb 2013 14:08:40 -0000
Received: from don-lt.don.CloudSwitch.com (72.74.68.135) by
	east.exch021.serverdata.net (10.240.4.93) with Microsoft SMTP Server
	(TLS) id 14.2.318.1; Tue, 26 Feb 2013 05:58:35 -0800
Message-ID: <512CBF8B.2090008@CloudSwitch.com>
Date: Tue, 26 Feb 2013 08:58:35 -0500
From: Don Slutz <Don@CloudSwitch.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1361468894-18655-1-git-send-email-david.vrabel@citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>, kexec@lists.infradead.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use
 with pv-ops 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-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/21/13 12:48, David Vrabel wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image.  This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
>
> The first patch is a simple clean-up.
>
> The second patch allows hypercall structures to be ABI compatible
> between 32- and 64-bit guests (by reusing stuff present for domctls
> and sysctls).  This seems better than having to keep adding compat
> handling for new hypercalls etc.
>
> Patch 3 introduces the new ABI.
>
> Patch 4 and 5 nearly completely reimplement the kexec load, unload and
> exec sub-ops.  The old load_v1 sub-op is then implemented on top of
> the new code.
>
> Patch 6 calls the kexec image when dom0 crashes.  This avoids having
> to alter dom0 kernels to do a exec sub-op call on crash -- an existing
> SHUTDOWN_crash.
>
> Patches 7 and 8 add the libxc API for the kexec calls.
>
> The required patch series for kexec-tools will be posted shortly.
>
> David
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I have tested this patch set on a Fedora 17 dom0 with kernels:

3.7.3-101.fc17.x86_64
3.6.5-1.fc17.x86_64

So:

Tested-by: Don Slutz <Don@CloudSwitch.com>

    -Don Slutz

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:17:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALLE-0002ti-QK; Tue, 26 Feb 2013 14:17:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1UALLC-0002ta-Nh
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 14:17:10 +0000
Received: from [85.158.143.99:58820] by server-2.bemta-4.messagelabs.com id
	17/3D-12656-5E3CC215; Tue, 26 Feb 2013 14:17:09 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361888205!29330028!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28160 invoked from network); 26 Feb 2013 14:16:45 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 14:16:45 -0000
Received: by mail-ee0-f43.google.com with SMTP id c50so2326271eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 06:16:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=bMdFv3yjytfiZmV+ceq326SWzW0Upv0xgm6qMBzrSdE=;
	b=pRf217zVPJnUTICczmMGpIZ6k2eu/ttJWxWnvbp35ZDdF7JjS5nr3MX1vvtFDMfuoN
	phLiEKy/wiNABGLp6OSmYFovpNwihhwfWTz98Fhq1jR+SzxeqbDxGdDa6gPlDy2KVnw0
	NV/JIiiBrNWBLUEa/Fo2rZM3gXnOBIHazF81vn6hbywpYuayKqlihNLw6xve0QXglFJI
	w2FfJkGsphd7Y0dvEElq/unQESkVrg8V5KYZ9lnO5EsY4uvd6tTSZhpXgBkgbIEXc6hI
	lH7pIZ8fxvdtbDKXutJ2NF6hfNbsV0X7BkUI5nTfcYJiNBOaekznGXSZ7nOyeJHt1V6a
	6GCA==
X-Received: by 10.14.206.132 with SMTP id l4mr50000495eeo.38.1361888204924;
	Tue, 26 Feb 2013 06:16:44 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id a1sm1720049eep.2.2013.02.26.06.16.42
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 06:16:44 -0800 (PST)
Message-ID: <512CC3CC.2010505@heliman.it>
Date: Tue, 26 Feb 2013 15:16:44 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361884713.26546.296.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQlqk2JzTULbcbu1ueOXGdiqpUxg5gaY0kY5C+8tAa9N5xTnlnALZ42rgq939mYkzwG4DBc1
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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-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

Il 26/02/2013 14:18, Ian Campbell ha scritto:
> On Tue, 2013-02-26 at 13:12 +0000, Stefano Stabellini wrote:
>> On Tue, 26 Feb 2013, Ian Campbell wrote:
>>> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
>>>>> +cat >deb/DEBIAN/postrm <<EOF
>>>>> +#!/bin/bash -e
>>>>> +insserv -r xendomains &&
>>>>> +insserv -r xencommons
>>> [...]
>>>> All the changes look good to me
>>> This one certainly isn't, calling insserv directly in a pre/post inst is
>>> not the correct Debian interface to use.
>>>
>>> Better to call update-rc.d I think, or use dh_installinit (and grow a
>>> build time dependency on debhelper).
>> I am _very_ ignorant in deb packaging, but this wiki
>> [...]
>>   maybe this is the recommended thing to do for sysadmins, not for
>> packagers?
> AIUI, yes. The document to refer to for anything to do with Debian
> Packaging is the Debian Policy Manual:
>          http://www.debian.org/doc/debian-policy/
>
> In this case:
>          http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
>          
>          Maintainers should use the abstraction layer provided by the
>          update-rc.d and invoke-rc.d programs to deal with initscripts in
>          their packages' scripts such as postinst, prerm and postrm.
>          
>          Directly managing the /etc/rc?.d links and directly invoking
>          the /etc/init.d/ initscripts should be done only by packages
>          providing the initscript subsystem (such as sysv-rc and
>          file-rc).
>
> Ian.
>
Sorry, Ian is right on this. I learned how to create deb packages 
according to the standards in the last months, I had better double check 
the patch.
I'll redo init with update-rc.d in next patch version.
The debian folder with compliance of deb policy 3.9.4 is probably loss 
of time that I can better use helping the official package.
Are there other important things to do in "make deb"? Probably is 
sufficent, I used it for my testing system for one year for hundreds of 
fast test build without problem.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:17:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALLE-0002ti-QK; Tue, 26 Feb 2013 14:17:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1UALLC-0002ta-Nh
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 14:17:10 +0000
Received: from [85.158.143.99:58820] by server-2.bemta-4.messagelabs.com id
	17/3D-12656-5E3CC215; Tue, 26 Feb 2013 14:17:09 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361888205!29330028!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28160 invoked from network); 26 Feb 2013 14:16:45 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 14:16:45 -0000
Received: by mail-ee0-f43.google.com with SMTP id c50so2326271eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 06:16:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=bMdFv3yjytfiZmV+ceq326SWzW0Upv0xgm6qMBzrSdE=;
	b=pRf217zVPJnUTICczmMGpIZ6k2eu/ttJWxWnvbp35ZDdF7JjS5nr3MX1vvtFDMfuoN
	phLiEKy/wiNABGLp6OSmYFovpNwihhwfWTz98Fhq1jR+SzxeqbDxGdDa6gPlDy2KVnw0
	NV/JIiiBrNWBLUEa/Fo2rZM3gXnOBIHazF81vn6hbywpYuayKqlihNLw6xve0QXglFJI
	w2FfJkGsphd7Y0dvEElq/unQESkVrg8V5KYZ9lnO5EsY4uvd6tTSZhpXgBkgbIEXc6hI
	lH7pIZ8fxvdtbDKXutJ2NF6hfNbsV0X7BkUI5nTfcYJiNBOaekznGXSZ7nOyeJHt1V6a
	6GCA==
X-Received: by 10.14.206.132 with SMTP id l4mr50000495eeo.38.1361888204924;
	Tue, 26 Feb 2013 06:16:44 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id a1sm1720049eep.2.2013.02.26.06.16.42
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 06:16:44 -0800 (PST)
Message-ID: <512CC3CC.2010505@heliman.it>
Date: Tue, 26 Feb 2013 15:16:44 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361884713.26546.296.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQlqk2JzTULbcbu1ueOXGdiqpUxg5gaY0kY5C+8tAa9N5xTnlnALZ42rgq939mYkzwG4DBc1
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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-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

Il 26/02/2013 14:18, Ian Campbell ha scritto:
> On Tue, 2013-02-26 at 13:12 +0000, Stefano Stabellini wrote:
>> On Tue, 26 Feb 2013, Ian Campbell wrote:
>>> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
>>>>> +cat >deb/DEBIAN/postrm <<EOF
>>>>> +#!/bin/bash -e
>>>>> +insserv -r xendomains &&
>>>>> +insserv -r xencommons
>>> [...]
>>>> All the changes look good to me
>>> This one certainly isn't, calling insserv directly in a pre/post inst is
>>> not the correct Debian interface to use.
>>>
>>> Better to call update-rc.d I think, or use dh_installinit (and grow a
>>> build time dependency on debhelper).
>> I am _very_ ignorant in deb packaging, but this wiki
>> [...]
>>   maybe this is the recommended thing to do for sysadmins, not for
>> packagers?
> AIUI, yes. The document to refer to for anything to do with Debian
> Packaging is the Debian Policy Manual:
>          http://www.debian.org/doc/debian-policy/
>
> In this case:
>          http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
>          
>          Maintainers should use the abstraction layer provided by the
>          update-rc.d and invoke-rc.d programs to deal with initscripts in
>          their packages' scripts such as postinst, prerm and postrm.
>          
>          Directly managing the /etc/rc?.d links and directly invoking
>          the /etc/init.d/ initscripts should be done only by packages
>          providing the initscript subsystem (such as sysv-rc and
>          file-rc).
>
> Ian.
>
Sorry, Ian is right on this. I learned how to create deb packages 
according to the standards in the last months, I had better double check 
the patch.
I'll redo init with update-rc.d in next patch version.
The debian folder with compliance of deb policy 3.9.4 is probably loss 
of time that I can better use helping the official package.
Are there other important things to do in "make deb"? Probably is 
sufficent, I used it for my testing system for one year for hundreds of 
fast test build without problem.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:20:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALNu-00034J-Kh; Tue, 26 Feb 2013 14:19:58 +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 1UALNt-00033s-3b
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:19:57 +0000
Received: from [85.158.138.51:46843] by server-15.bemta-3.messagelabs.com id
	78/DE-25405-C84CC215; Tue, 26 Feb 2013 14:19:56 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361888368!19959404!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26092 invoked from network); 26 Feb 2013 14:19:29 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 14:19:29 -0000
Received: by mail-wg0-f45.google.com with SMTP id dq12so3385258wgb.0
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 06:19:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TY1r3/l47g2jlI8TGcLTGIf7JANICLteUUYNEp702aY=;
	b=ds4MzYJ0FKUUYdTo2J9I3SXeDDGPdx5m7e5I/B7UXHgJTlKb7qosaxHOn9nOPB50zJ
	C2JPSCAA//WrwAL/rkZbqePjB9X1SuzIo+4qY8TdXJx6JYCEQhG++8/XqowbmIJx6dJJ
	XOj0whb8Yd7KMbn6kTvC7HmulsQQtuwKgXLPYt3fxxTVTjICLhegJf2Yd8d7YPUbgMSa
	HIYyPjmV54MT+/kWhJCkrvtXFaHbq9tJWMEErFH1sy5sxtA4i6OC5fvK4HSoK9P1ZZ8Z
	9W8+cHAM3LJOIn1plhuvJ6deRg1SMZStHcRaPF5Wl0IFdi92YVV2pSIPqwaRvAAul+zl
	WlYg==
MIME-Version: 1.0
X-Received: by 10.194.60.195 with SMTP id j3mr26685278wjr.33.1361888368787;
	Tue, 26 Feb 2013 06:19:28 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Tue, 26 Feb 2013 06:19:28 -0800 (PST)
In-Reply-To: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
References: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
Date: Tue, 26 Feb 2013 14:19:28 +0000
X-Google-Sender-Auth: gg1NU1kTzXK4W5ndl0ZiaMjroBw
Message-ID: <CAFLBxZbRnBy5AFXw6_9mvRt+svA7j3f6hB2YqOQBL7z3LpV0rw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Igor Pavlikevich <ipavlikevich@gmail.com>
Content-Type: multipart/mixed; boundary=047d7b86e2f8720c1504d6a158b3
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: fix race condition in csched_vcpu
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--047d7b86e2f8720c1504d6a158b3
Content-Type: multipart/alternative; boundary=047d7b86e2f8720c1204d6a158b1

--047d7b86e2f8720c1204d6a158b1
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 25, 2013 at 8:20 AM, Igor Pavlikevich <ipavlikevich@gmail.com>wrote:

> When vcpu stops yielding, it's possible to overwrite
> CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_YIELD.
>
>  332.970218393 -------x d1v1 runstate_continue d1v1 running->running
> ]332.970248371 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>  yielding, flags=0x0002
> ]332.970251968 -------x d1v1
> clearing 0x0002, flags=0
>  332.970252175 -------x d1v1 runstate_continue d1v1 running->running
> ]332.970282574 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>  yielding, flags=0x0002
> ]332.970283068 x------| d32767v0
> entering csched_acct(), d1v1 flags=0x0002
> ]332.970285763 x------| d32767v0   28003(2:8:3) 2 [ 1 1 ]
>  calling vcpu_pause_nosync() for d1v1
> ]332.970286647 -------x d1v1
> clearing 0x0002, flags=0
> ]332.970286771 x------| d32767v0
> flags |= CSCHED_FLAG_VCPU_PARKED, flags=0x0003
> ]332.970286990 -------x d1v1   2800e(2:8:e) 2 [ 1 1cacfca ]
> ]332.970287122 -------x d1v1   2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]
> ]332.970287242 -------x d1v1   2800a(2:8:a) 4 [ 1 1 7fff 7 ]
> exiting schedule(), flags=0
>  332.970287417 -------x d1v1 runstate_change d1v1 running->offline
>  332.970287629 -------x d?v? runstate_change d32767v7 runnable->running
> ]332.970288397 x------- d32767v0
> exiting csched_acct(), flags=0x0003
> ]332.995349690 x------- d32767v0
> entering csched_acct(), d1v1 flags=0x0000, flag lost.
> ]332.995352170 x------- d32767v0   28003(2:8:3) 2 [ 1 1 ]
>  calling vcpu_pause_nosync() for d1v1 again
>
> From this moment d1v1 has extra +1 in pause_count, so it goes offline
> right after credit>prv->credits_per_tslice forever.
>

Good catch -- I guess we don't really test the scheduler "cap"
functionality enough to catch this one.

Unfortunately I think the real problem is that the ->flags field should be
uniformly using the atomic bit operations.

Can you try the attached patch and see if it works for you?

 -George

--047d7b86e2f8720c1204d6a158b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Feb 25, 2013 at 8:20 AM, Igor Pavlikevich <span di=
r=3D"ltr">&lt;<a href=3D"mailto:ipavlikevich@gmail.com" target=3D"_blank">i=
pavlikevich@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">When vcpu stops yielding, it&#39;s possible =
to overwrite CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_Y=
IELD.<br>

<br>
=A0332.970218393 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970248371 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970251968 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
=A0332.970252175 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970282574 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970283068 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0002<br>
]332.970285763 x------| d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1<br>
]332.970286647 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
]332.970286771 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags |=3D CSCHED_FLAG_VCPU_PARKED, fla=
gs=3D0x0003<br>
]332.970286990 -------x d1v1 =A0 2800e(2:8:e) 2 [ 1 1cacfca ]<br>
]332.970287122 -------x d1v1 =A0 2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]<b=
r>
]332.970287242 -------x d1v1 =A0 2800a(2:8:a) 4 [ 1 1 7fff 7 ] =A0 =A0 =A0 =
=A0 =A0 exiting schedule(), flags=3D0<br>
=A0332.970287417 -------x d1v1 runstate_change d1v1 running-&gt;offline<br>
=A0332.970287629 -------x d?v? runstate_change d32767v7 runnable-&gt;runnin=
g<br>
]332.970288397 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exiting csched_acct(), flags=3D0x0003<b=
r>
]332.995349690 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0000, flag lost.<br>
]332.995352170 x------- d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1 again<br>
<br>
>From this moment d1v1 has extra +1 in pause_count, so it goes offline right=
 after credit&gt;prv-&gt;credits_per_tslice forever.<br></blockquote><div><=
br></div><div>Good catch -- I guess we don&#39;t really test the scheduler =
&quot;cap&quot; functionality enough to catch this one.<br>
<br></div><div>Unfortunately I think the real problem is that the -&gt;flag=
s field should be uniformly using the atomic bit operations.<br><br>Can you=
 try the attached patch and see if it works for you?<br><br></div><div>
=A0-George<br></div><div>=A0<br></div></div><br></div></div>

--047d7b86e2f8720c1204d6a158b1--
--047d7b86e2f8720c1504d6a158b3
Content-Type: application/octet-stream; name="credit-atomic-flags.diff"
Content-Disposition: attachment; filename="credit-atomic-flags.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hdn55tqt0

Y29tbWl0IGM3MmFiYmNmNzFmMTJhZTVlOWM1ZGRhNGE4NWJjZTIzZGJmNDg2OGYKQXV0aG9yOiBH
ZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+CkRhdGU6ICAgVHVlIEZl
YiAyNiAxMjo0NDo0OCAyMDEzICswMDAwCgogICAgY3JlZGl0MTogVXNlIGF0b21pYyBiaXQgb3Bl
cmF0aW9ucyBmb3IgdGhlIGZsYWdzIHN0cnVjdHVyZQogICAgCiAgICBUaGUgZmxhZ3Mgc3RydWN0
dXJlIGlzIG5vdCBwcm90ZWN0ZWQgYnkgbG9ja3MgKG9yIG1vcmUgcHJlY2lzZWx5LAogICAgaXQg
aXMgcHJvdGVjdGVkIHVzaW5nIGFuIGluY29uc2lzdGVudCBzZXQgb2YgbG9ja3MpOyB3ZSB0aGVy
ZWZvcmUgbmVlZAogICAgdG8gbWFrZSBzdXJlIHRoYXQgYWxsIGFjY2Vzc2VzIGFyZSBhdG9taWMt
c2FmZS4gIFRoaXMgaXMgcGFydGljdWxhcnkKICAgIGltcG9ydGFudCBpbiB0aGUgY2FzZSBvZiB0
aGUgUEFSS0VEIGZsYWcsIHdoaWNoIGlmIGNsb2JiZXJlZCB3aGlsZQogICAgY2hhbmdpbmcgdGhl
IFlJRUxEIGJpdCB3aWxsIGxlYXZlIGEgdmNwdSB3ZWRnZWQgaW4gYW4gb2ZmbGluZSBzdGF0ZS4K
ICAgIAogICAgVXNpbmcgdGhlIGF0b21pYyBiaXRvcHMgYWxzbyByZXF1aXJlcyB1cyB0byBjaGFu
Z2UgdGhlIHNpemUgb2YgdGhlICJmbGFncyIKICAgIGVsZW1lbnQuCiAgICAKICAgIFNwb3R0ZWQt
Ynk6IElnb3IgUGF2bGlrZXZpY2ggPGlwYXZsaWtldmljaEBnbWFpbC5jb20+CiAgICBTaWduZWQt
b2ZmLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYyBiL3hlbi9jb21tb24vc2NoZWRfY3Jl
ZGl0LmMKaW5kZXggZGYyZDA3Ni4uZWNkYmQ3NiAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9zY2hl
ZF9jcmVkaXQuYworKysgYi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCkBAIC00Niw4ICs0Niw4
IEBACiAvKgogICogRmxhZ3MKICAqLwotI2RlZmluZSBDU0NIRURfRkxBR19WQ1BVX1BBUktFRCAg
ICAweDAwMDEgIC8qIFZDUFUgb3ZlciBjYXBwZWQgY3JlZGl0cyAqLwotI2RlZmluZSBDU0NIRURf
RkxBR19WQ1BVX1lJRUxEICAgICAweDAwMDIgIC8qIFZDUFUgeWllbGRpbmcgKi8KKyNkZWZpbmUg
Q1NDSEVEX0ZMQUdfVkNQVV9QQVJLRUQgICAgMHgwICAvKiBWQ1BVIG92ZXIgY2FwcGVkIGNyZWRp
dHMgKi8KKyNkZWZpbmUgQ1NDSEVEX0ZMQUdfVkNQVV9ZSUVMRCAgICAgMHgxICAvKiBWQ1BVIHlp
ZWxkaW5nICovCiAKIAogLyoKQEAgLTEzNyw3ICsxMzcsNyBAQCBzdHJ1Y3QgY3NjaGVkX3ZjcHUg
ewogICAgIHN0cnVjdCB2Y3B1ICp2Y3B1OwogICAgIGF0b21pY190IGNyZWRpdDsKICAgICBzX3Rp
bWVfdCBzdGFydF90aW1lOyAgIC8qIFdoZW4gd2Ugd2VyZSBzY2hlZHVsZWQgKHVzZWQgZm9yIGNy
ZWRpdCkgKi8KLSAgICB1aW50MTZfdCBmbGFnczsKKyAgICB1bnNpZ25lZCBmbGFnczsKICAgICBp
bnQxNl90IHByaTsKICNpZmRlZiBDU0NIRURfU1RBVFMKICAgICBzdHJ1Y3QgewpAQCAtMjIwLDcg
KzIyMCw3IEBAIF9fcnVucV9pbnNlcnQodW5zaWduZWQgaW50IGNwdSwgc3RydWN0IGNzY2hlZF92
Y3B1ICpzdmMpCiAgICAgLyogSWYgdGhlIHZjcHUgeWllbGRlZCwgdHJ5IHRvIHB1dCBpdCBiZWhp
bmQgb25lIGxvd2VyLXByaW9yaXR5CiAgICAgICogcnVubmFibGUgdmNwdSBpZiB3ZSBjYW4uICBU
aGUgbmV4dCBydW5xX3NvcnQgd2lsbCBicmluZyBpdCBmb3J3YXJkCiAgICAgICogd2l0aGluIDMw
bXMgaWYgdGhlIHF1ZXVlIHRvbyBsb25nLiAqLwotICAgIGlmICggc3ZjLT5mbGFncyAmIENTQ0hF
RF9GTEFHX1ZDUFVfWUlFTEQKKyAgICBpZiAoIHRlc3RfYml0KENTQ0hFRF9GTEFHX1ZDUFVfWUlF
TEQsICZzdmMtPmZsYWdzKQogICAgICAgICAgJiYgX19ydW5xX2VsZW0oaXRlciktPnByaSA+IENT
Q0hFRF9QUklfSURMRSApCiAgICAgewogICAgICAgICBpdGVyPWl0ZXItPm5leHQ7CkBAIC04MTEs
NyArODExLDcgQEAgY3NjaGVkX3ZjcHVfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMs
IHN0cnVjdCB2Y3B1ICp2YykKICAgICAgKiB0aG9zZS4KICAgICAgKi8KICAgICBpZiAoIHN2Yy0+
cHJpID09IENTQ0hFRF9QUklfVFNfVU5ERVIgJiYKLSAgICAgICAgICEoc3ZjLT5mbGFncyAmIENT
Q0hFRF9GTEFHX1ZDUFVfUEFSS0VEKSApCisgICAgICAgICAhdGVzdF9iaXQoQ1NDSEVEX0ZMQUdf
VkNQVV9QQVJLRUQsICZzdmMtPmZsYWdzKSApCiAgICAgewogICAgICAgICBzdmMtPnByaSA9IENT
Q0hFRF9QUklfVFNfQk9PU1Q7CiAgICAgfQpAQCAtODI0LDEwICs4MjQsMTAgQEAgY3NjaGVkX3Zj
cHVfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCB2Y3B1ICp2YykKIHN0
YXRpYyB2b2lkCiBjc2NoZWRfdmNwdV95aWVsZChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMs
IHN0cnVjdCB2Y3B1ICp2YykKIHsKLSAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKiBjb25zdCBzdiA9
IENTQ0hFRF9WQ1BVKHZjKTsKKyAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKiBjb25zdCBzdmMgPSBD
U0NIRURfVkNQVSh2Yyk7CiAKICAgICAvKiBMZXQgdGhlIHNjaGVkdWxlciBrbm93IHRoYXQgdGhp
cyB2Y3B1IGlzIHRyeWluZyB0byB5aWVsZCAqLwotICAgIHN2LT5mbGFncyB8PSBDU0NIRURfRkxB
R19WQ1BVX1lJRUxEOworICAgIHNldF9iaXQoQ1NDSEVEX0ZMQUdfVkNQVV9ZSUVMRCwgJnN2Yy0+
ZmxhZ3MpOwogfQogCiBzdGF0aWMgaW50CkBAIC0xMTUxLDExICsxMTUxLDEwIEBAIGNzY2hlZF9h
Y2N0KHZvaWQqIGR1bW15KQogICAgICAgICAgICAgICAgIC8qIFBhcmsgcnVubmluZyBWQ1BVcyBv
ZiBjYXBwZWQtb3V0IGRvbWFpbnMgKi8KICAgICAgICAgICAgICAgICBpZiAoIHNkb20tPmNhcCAh
PSAwVSAmJgogICAgICAgICAgICAgICAgICAgICAgY3JlZGl0IDwgLWNyZWRpdF9jYXAgJiYKLSAg
ICAgICAgICAgICAgICAgICAgICEoc3ZjLT5mbGFncyAmIENTQ0hFRF9GTEFHX1ZDUFVfUEFSS0VE
KSApCisgICAgICAgICAgICAgICAgICAgICAhdGVzdF9hbmRfc2V0X2JpdChDU0NIRURfRkxBR19W
Q1BVX1BBUktFRCwgJnN2Yy0+ZmxhZ3MpICkKICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAg
ICAgICAgICAgIFNDSEVEX1NUQVRfQ1JBTksodmNwdV9wYXJrKTsKICAgICAgICAgICAgICAgICAg
ICAgdmNwdV9wYXVzZV9ub3N5bmMoc3ZjLT52Y3B1KTsKLSAgICAgICAgICAgICAgICAgICAgc3Zj
LT5mbGFncyB8PSBDU0NIRURfRkxBR19WQ1BVX1BBUktFRDsKICAgICAgICAgICAgICAgICB9CiAK
ICAgICAgICAgICAgICAgICAvKiBMb3dlciBib3VuZCBvbiBjcmVkaXRzICovCkBAIC0xMTcxLDcg
KzExNzAsNyBAQCBjc2NoZWRfYWNjdCh2b2lkKiBkdW1teSkKICAgICAgICAgICAgICAgICBzdmMt
PnByaSA9IENTQ0hFRF9QUklfVFNfVU5ERVI7CiAKICAgICAgICAgICAgICAgICAvKiBVbnBhcmsg
YW55IGNhcHBlZCBkb21haW5zIHdob3NlIGNyZWRpdHMgZ28gcG9zaXRpdmUgKi8KLSAgICAgICAg
ICAgICAgICBpZiAoIHN2Yy0+ZmxhZ3MgJiBDU0NIRURfRkxBR19WQ1BVX1BBUktFRCkKKyAgICAg
ICAgICAgICAgICBpZiAoIHRlc3RfYW5kX2NsZWFyX2JpdChDU0NIRURfRkxBR19WQ1BVX1BBUktF
RCwgJnN2Yy0+ZmxhZ3MpICkKICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAg
IC8qCiAgICAgICAgICAgICAgICAgICAgICAqIEl0J3MgaW1wb3J0YW50IHRvIHVuc2V0IHRoZSBm
bGFnIEFGVEVSIHRoZSB1bnBhdXNlKCkKQEAgLTExODAsNyArMTE3OSw2IEBAIGNzY2hlZF9hY2N0
KHZvaWQqIGR1bW15KQogICAgICAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAgICAgICAg
ICAgU0NIRURfU1RBVF9DUkFOSyh2Y3B1X3VucGFyayk7CiAgICAgICAgICAgICAgICAgICAgIHZj
cHVfdW5wYXVzZShzdmMtPnZjcHUpOwotICAgICAgICAgICAgICAgICAgICBzdmMtPmZsYWdzICY9
IH5DU0NIRURfRkxBR19WQ1BVX1BBUktFRDsKICAgICAgICAgICAgICAgICB9CiAKICAgICAgICAg
ICAgICAgICAvKiBVcHBlciBib3VuZCBvbiBjcmVkaXRzIG1lYW5zIFZDUFUgc3RvcHMgZWFybmlu
ZyAqLwpAQCAtMTQ0Miw4ICsxNDQwLDcgQEAgY3NjaGVkX3NjaGVkdWxlKAogICAgIC8qCiAgICAg
ICogQ2xlYXIgWUlFTEQgZmxhZyBiZWZvcmUgc2NoZWR1bGluZyBvdXQKICAgICAgKi8KLSAgICBp
ZiAoIHNjdXJyLT5mbGFncyAmIENTQ0hFRF9GTEFHX1ZDUFVfWUlFTEQgKQotICAgICAgICBzY3Vy
ci0+ZmxhZ3MgJj0gfihDU0NIRURfRkxBR19WQ1BVX1lJRUxEKTsKKyAgICBjbGVhcl9iaXQoQ1ND
SEVEX0ZMQUdfVkNQVV9ZSUVMRCwgJnNjdXJyLT5mbGFncyk7CiAKICAgICAvKgogICAgICAqIFNN
UCBMb2FkIGJhbGFuY2U6Cg==
--047d7b86e2f8720c1504d6a158b3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b86e2f8720c1504d6a158b3--


From xen-devel-bounces@lists.xen.org Tue Feb 26 14:20:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALNu-00034J-Kh; Tue, 26 Feb 2013 14:19:58 +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 1UALNt-00033s-3b
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:19:57 +0000
Received: from [85.158.138.51:46843] by server-15.bemta-3.messagelabs.com id
	78/DE-25405-C84CC215; Tue, 26 Feb 2013 14:19:56 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1361888368!19959404!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26092 invoked from network); 26 Feb 2013 14:19:29 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 14:19:29 -0000
Received: by mail-wg0-f45.google.com with SMTP id dq12so3385258wgb.0
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 06:19:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TY1r3/l47g2jlI8TGcLTGIf7JANICLteUUYNEp702aY=;
	b=ds4MzYJ0FKUUYdTo2J9I3SXeDDGPdx5m7e5I/B7UXHgJTlKb7qosaxHOn9nOPB50zJ
	C2JPSCAA//WrwAL/rkZbqePjB9X1SuzIo+4qY8TdXJx6JYCEQhG++8/XqowbmIJx6dJJ
	XOj0whb8Yd7KMbn6kTvC7HmulsQQtuwKgXLPYt3fxxTVTjICLhegJf2Yd8d7YPUbgMSa
	HIYyPjmV54MT+/kWhJCkrvtXFaHbq9tJWMEErFH1sy5sxtA4i6OC5fvK4HSoK9P1ZZ8Z
	9W8+cHAM3LJOIn1plhuvJ6deRg1SMZStHcRaPF5Wl0IFdi92YVV2pSIPqwaRvAAul+zl
	WlYg==
MIME-Version: 1.0
X-Received: by 10.194.60.195 with SMTP id j3mr26685278wjr.33.1361888368787;
	Tue, 26 Feb 2013 06:19:28 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Tue, 26 Feb 2013 06:19:28 -0800 (PST)
In-Reply-To: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
References: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
Date: Tue, 26 Feb 2013 14:19:28 +0000
X-Google-Sender-Auth: gg1NU1kTzXK4W5ndl0ZiaMjroBw
Message-ID: <CAFLBxZbRnBy5AFXw6_9mvRt+svA7j3f6hB2YqOQBL7z3LpV0rw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Igor Pavlikevich <ipavlikevich@gmail.com>
Content-Type: multipart/mixed; boundary=047d7b86e2f8720c1504d6a158b3
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: fix race condition in csched_vcpu
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--047d7b86e2f8720c1504d6a158b3
Content-Type: multipart/alternative; boundary=047d7b86e2f8720c1204d6a158b1

--047d7b86e2f8720c1204d6a158b1
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 25, 2013 at 8:20 AM, Igor Pavlikevich <ipavlikevich@gmail.com>wrote:

> When vcpu stops yielding, it's possible to overwrite
> CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_YIELD.
>
>  332.970218393 -------x d1v1 runstate_continue d1v1 running->running
> ]332.970248371 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>  yielding, flags=0x0002
> ]332.970251968 -------x d1v1
> clearing 0x0002, flags=0
>  332.970252175 -------x d1v1 runstate_continue d1v1 running->running
> ]332.970282574 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>  yielding, flags=0x0002
> ]332.970283068 x------| d32767v0
> entering csched_acct(), d1v1 flags=0x0002
> ]332.970285763 x------| d32767v0   28003(2:8:3) 2 [ 1 1 ]
>  calling vcpu_pause_nosync() for d1v1
> ]332.970286647 -------x d1v1
> clearing 0x0002, flags=0
> ]332.970286771 x------| d32767v0
> flags |= CSCHED_FLAG_VCPU_PARKED, flags=0x0003
> ]332.970286990 -------x d1v1   2800e(2:8:e) 2 [ 1 1cacfca ]
> ]332.970287122 -------x d1v1   2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]
> ]332.970287242 -------x d1v1   2800a(2:8:a) 4 [ 1 1 7fff 7 ]
> exiting schedule(), flags=0
>  332.970287417 -------x d1v1 runstate_change d1v1 running->offline
>  332.970287629 -------x d?v? runstate_change d32767v7 runnable->running
> ]332.970288397 x------- d32767v0
> exiting csched_acct(), flags=0x0003
> ]332.995349690 x------- d32767v0
> entering csched_acct(), d1v1 flags=0x0000, flag lost.
> ]332.995352170 x------- d32767v0   28003(2:8:3) 2 [ 1 1 ]
>  calling vcpu_pause_nosync() for d1v1 again
>
> From this moment d1v1 has extra +1 in pause_count, so it goes offline
> right after credit>prv->credits_per_tslice forever.
>

Good catch -- I guess we don't really test the scheduler "cap"
functionality enough to catch this one.

Unfortunately I think the real problem is that the ->flags field should be
uniformly using the atomic bit operations.

Can you try the attached patch and see if it works for you?

 -George

--047d7b86e2f8720c1204d6a158b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Feb 25, 2013 at 8:20 AM, Igor Pavlikevich <span di=
r=3D"ltr">&lt;<a href=3D"mailto:ipavlikevich@gmail.com" target=3D"_blank">i=
pavlikevich@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">When vcpu stops yielding, it&#39;s possible =
to overwrite CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_Y=
IELD.<br>

<br>
=A0332.970218393 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970248371 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970251968 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
=A0332.970252175 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970282574 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970283068 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0002<br>
]332.970285763 x------| d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1<br>
]332.970286647 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
]332.970286771 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags |=3D CSCHED_FLAG_VCPU_PARKED, fla=
gs=3D0x0003<br>
]332.970286990 -------x d1v1 =A0 2800e(2:8:e) 2 [ 1 1cacfca ]<br>
]332.970287122 -------x d1v1 =A0 2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]<b=
r>
]332.970287242 -------x d1v1 =A0 2800a(2:8:a) 4 [ 1 1 7fff 7 ] =A0 =A0 =A0 =
=A0 =A0 exiting schedule(), flags=3D0<br>
=A0332.970287417 -------x d1v1 runstate_change d1v1 running-&gt;offline<br>
=A0332.970287629 -------x d?v? runstate_change d32767v7 runnable-&gt;runnin=
g<br>
]332.970288397 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exiting csched_acct(), flags=3D0x0003<b=
r>
]332.995349690 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0000, flag lost.<br>
]332.995352170 x------- d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1 again<br>
<br>
>From this moment d1v1 has extra +1 in pause_count, so it goes offline right=
 after credit&gt;prv-&gt;credits_per_tslice forever.<br></blockquote><div><=
br></div><div>Good catch -- I guess we don&#39;t really test the scheduler =
&quot;cap&quot; functionality enough to catch this one.<br>
<br></div><div>Unfortunately I think the real problem is that the -&gt;flag=
s field should be uniformly using the atomic bit operations.<br><br>Can you=
 try the attached patch and see if it works for you?<br><br></div><div>
=A0-George<br></div><div>=A0<br></div></div><br></div></div>

--047d7b86e2f8720c1204d6a158b1--
--047d7b86e2f8720c1504d6a158b3
Content-Type: application/octet-stream; name="credit-atomic-flags.diff"
Content-Disposition: attachment; filename="credit-atomic-flags.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hdn55tqt0

Y29tbWl0IGM3MmFiYmNmNzFmMTJhZTVlOWM1ZGRhNGE4NWJjZTIzZGJmNDg2OGYKQXV0aG9yOiBH
ZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+CkRhdGU6ICAgVHVlIEZl
YiAyNiAxMjo0NDo0OCAyMDEzICswMDAwCgogICAgY3JlZGl0MTogVXNlIGF0b21pYyBiaXQgb3Bl
cmF0aW9ucyBmb3IgdGhlIGZsYWdzIHN0cnVjdHVyZQogICAgCiAgICBUaGUgZmxhZ3Mgc3RydWN0
dXJlIGlzIG5vdCBwcm90ZWN0ZWQgYnkgbG9ja3MgKG9yIG1vcmUgcHJlY2lzZWx5LAogICAgaXQg
aXMgcHJvdGVjdGVkIHVzaW5nIGFuIGluY29uc2lzdGVudCBzZXQgb2YgbG9ja3MpOyB3ZSB0aGVy
ZWZvcmUgbmVlZAogICAgdG8gbWFrZSBzdXJlIHRoYXQgYWxsIGFjY2Vzc2VzIGFyZSBhdG9taWMt
c2FmZS4gIFRoaXMgaXMgcGFydGljdWxhcnkKICAgIGltcG9ydGFudCBpbiB0aGUgY2FzZSBvZiB0
aGUgUEFSS0VEIGZsYWcsIHdoaWNoIGlmIGNsb2JiZXJlZCB3aGlsZQogICAgY2hhbmdpbmcgdGhl
IFlJRUxEIGJpdCB3aWxsIGxlYXZlIGEgdmNwdSB3ZWRnZWQgaW4gYW4gb2ZmbGluZSBzdGF0ZS4K
ICAgIAogICAgVXNpbmcgdGhlIGF0b21pYyBiaXRvcHMgYWxzbyByZXF1aXJlcyB1cyB0byBjaGFu
Z2UgdGhlIHNpemUgb2YgdGhlICJmbGFncyIKICAgIGVsZW1lbnQuCiAgICAKICAgIFNwb3R0ZWQt
Ynk6IElnb3IgUGF2bGlrZXZpY2ggPGlwYXZsaWtldmljaEBnbWFpbC5jb20+CiAgICBTaWduZWQt
b2ZmLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYyBiL3hlbi9jb21tb24vc2NoZWRfY3Jl
ZGl0LmMKaW5kZXggZGYyZDA3Ni4uZWNkYmQ3NiAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9zY2hl
ZF9jcmVkaXQuYworKysgYi94ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCkBAIC00Niw4ICs0Niw4
IEBACiAvKgogICogRmxhZ3MKICAqLwotI2RlZmluZSBDU0NIRURfRkxBR19WQ1BVX1BBUktFRCAg
ICAweDAwMDEgIC8qIFZDUFUgb3ZlciBjYXBwZWQgY3JlZGl0cyAqLwotI2RlZmluZSBDU0NIRURf
RkxBR19WQ1BVX1lJRUxEICAgICAweDAwMDIgIC8qIFZDUFUgeWllbGRpbmcgKi8KKyNkZWZpbmUg
Q1NDSEVEX0ZMQUdfVkNQVV9QQVJLRUQgICAgMHgwICAvKiBWQ1BVIG92ZXIgY2FwcGVkIGNyZWRp
dHMgKi8KKyNkZWZpbmUgQ1NDSEVEX0ZMQUdfVkNQVV9ZSUVMRCAgICAgMHgxICAvKiBWQ1BVIHlp
ZWxkaW5nICovCiAKIAogLyoKQEAgLTEzNyw3ICsxMzcsNyBAQCBzdHJ1Y3QgY3NjaGVkX3ZjcHUg
ewogICAgIHN0cnVjdCB2Y3B1ICp2Y3B1OwogICAgIGF0b21pY190IGNyZWRpdDsKICAgICBzX3Rp
bWVfdCBzdGFydF90aW1lOyAgIC8qIFdoZW4gd2Ugd2VyZSBzY2hlZHVsZWQgKHVzZWQgZm9yIGNy
ZWRpdCkgKi8KLSAgICB1aW50MTZfdCBmbGFnczsKKyAgICB1bnNpZ25lZCBmbGFnczsKICAgICBp
bnQxNl90IHByaTsKICNpZmRlZiBDU0NIRURfU1RBVFMKICAgICBzdHJ1Y3QgewpAQCAtMjIwLDcg
KzIyMCw3IEBAIF9fcnVucV9pbnNlcnQodW5zaWduZWQgaW50IGNwdSwgc3RydWN0IGNzY2hlZF92
Y3B1ICpzdmMpCiAgICAgLyogSWYgdGhlIHZjcHUgeWllbGRlZCwgdHJ5IHRvIHB1dCBpdCBiZWhp
bmQgb25lIGxvd2VyLXByaW9yaXR5CiAgICAgICogcnVubmFibGUgdmNwdSBpZiB3ZSBjYW4uICBU
aGUgbmV4dCBydW5xX3NvcnQgd2lsbCBicmluZyBpdCBmb3J3YXJkCiAgICAgICogd2l0aGluIDMw
bXMgaWYgdGhlIHF1ZXVlIHRvbyBsb25nLiAqLwotICAgIGlmICggc3ZjLT5mbGFncyAmIENTQ0hF
RF9GTEFHX1ZDUFVfWUlFTEQKKyAgICBpZiAoIHRlc3RfYml0KENTQ0hFRF9GTEFHX1ZDUFVfWUlF
TEQsICZzdmMtPmZsYWdzKQogICAgICAgICAgJiYgX19ydW5xX2VsZW0oaXRlciktPnByaSA+IENT
Q0hFRF9QUklfSURMRSApCiAgICAgewogICAgICAgICBpdGVyPWl0ZXItPm5leHQ7CkBAIC04MTEs
NyArODExLDcgQEAgY3NjaGVkX3ZjcHVfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMs
IHN0cnVjdCB2Y3B1ICp2YykKICAgICAgKiB0aG9zZS4KICAgICAgKi8KICAgICBpZiAoIHN2Yy0+
cHJpID09IENTQ0hFRF9QUklfVFNfVU5ERVIgJiYKLSAgICAgICAgICEoc3ZjLT5mbGFncyAmIENT
Q0hFRF9GTEFHX1ZDUFVfUEFSS0VEKSApCisgICAgICAgICAhdGVzdF9iaXQoQ1NDSEVEX0ZMQUdf
VkNQVV9QQVJLRUQsICZzdmMtPmZsYWdzKSApCiAgICAgewogICAgICAgICBzdmMtPnByaSA9IENT
Q0hFRF9QUklfVFNfQk9PU1Q7CiAgICAgfQpAQCAtODI0LDEwICs4MjQsMTAgQEAgY3NjaGVkX3Zj
cHVfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCB2Y3B1ICp2YykKIHN0
YXRpYyB2b2lkCiBjc2NoZWRfdmNwdV95aWVsZChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMs
IHN0cnVjdCB2Y3B1ICp2YykKIHsKLSAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKiBjb25zdCBzdiA9
IENTQ0hFRF9WQ1BVKHZjKTsKKyAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKiBjb25zdCBzdmMgPSBD
U0NIRURfVkNQVSh2Yyk7CiAKICAgICAvKiBMZXQgdGhlIHNjaGVkdWxlciBrbm93IHRoYXQgdGhp
cyB2Y3B1IGlzIHRyeWluZyB0byB5aWVsZCAqLwotICAgIHN2LT5mbGFncyB8PSBDU0NIRURfRkxB
R19WQ1BVX1lJRUxEOworICAgIHNldF9iaXQoQ1NDSEVEX0ZMQUdfVkNQVV9ZSUVMRCwgJnN2Yy0+
ZmxhZ3MpOwogfQogCiBzdGF0aWMgaW50CkBAIC0xMTUxLDExICsxMTUxLDEwIEBAIGNzY2hlZF9h
Y2N0KHZvaWQqIGR1bW15KQogICAgICAgICAgICAgICAgIC8qIFBhcmsgcnVubmluZyBWQ1BVcyBv
ZiBjYXBwZWQtb3V0IGRvbWFpbnMgKi8KICAgICAgICAgICAgICAgICBpZiAoIHNkb20tPmNhcCAh
PSAwVSAmJgogICAgICAgICAgICAgICAgICAgICAgY3JlZGl0IDwgLWNyZWRpdF9jYXAgJiYKLSAg
ICAgICAgICAgICAgICAgICAgICEoc3ZjLT5mbGFncyAmIENTQ0hFRF9GTEFHX1ZDUFVfUEFSS0VE
KSApCisgICAgICAgICAgICAgICAgICAgICAhdGVzdF9hbmRfc2V0X2JpdChDU0NIRURfRkxBR19W
Q1BVX1BBUktFRCwgJnN2Yy0+ZmxhZ3MpICkKICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAg
ICAgICAgICAgIFNDSEVEX1NUQVRfQ1JBTksodmNwdV9wYXJrKTsKICAgICAgICAgICAgICAgICAg
ICAgdmNwdV9wYXVzZV9ub3N5bmMoc3ZjLT52Y3B1KTsKLSAgICAgICAgICAgICAgICAgICAgc3Zj
LT5mbGFncyB8PSBDU0NIRURfRkxBR19WQ1BVX1BBUktFRDsKICAgICAgICAgICAgICAgICB9CiAK
ICAgICAgICAgICAgICAgICAvKiBMb3dlciBib3VuZCBvbiBjcmVkaXRzICovCkBAIC0xMTcxLDcg
KzExNzAsNyBAQCBjc2NoZWRfYWNjdCh2b2lkKiBkdW1teSkKICAgICAgICAgICAgICAgICBzdmMt
PnByaSA9IENTQ0hFRF9QUklfVFNfVU5ERVI7CiAKICAgICAgICAgICAgICAgICAvKiBVbnBhcmsg
YW55IGNhcHBlZCBkb21haW5zIHdob3NlIGNyZWRpdHMgZ28gcG9zaXRpdmUgKi8KLSAgICAgICAg
ICAgICAgICBpZiAoIHN2Yy0+ZmxhZ3MgJiBDU0NIRURfRkxBR19WQ1BVX1BBUktFRCkKKyAgICAg
ICAgICAgICAgICBpZiAoIHRlc3RfYW5kX2NsZWFyX2JpdChDU0NIRURfRkxBR19WQ1BVX1BBUktF
RCwgJnN2Yy0+ZmxhZ3MpICkKICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAg
IC8qCiAgICAgICAgICAgICAgICAgICAgICAqIEl0J3MgaW1wb3J0YW50IHRvIHVuc2V0IHRoZSBm
bGFnIEFGVEVSIHRoZSB1bnBhdXNlKCkKQEAgLTExODAsNyArMTE3OSw2IEBAIGNzY2hlZF9hY2N0
KHZvaWQqIGR1bW15KQogICAgICAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAgICAgICAg
ICAgU0NIRURfU1RBVF9DUkFOSyh2Y3B1X3VucGFyayk7CiAgICAgICAgICAgICAgICAgICAgIHZj
cHVfdW5wYXVzZShzdmMtPnZjcHUpOwotICAgICAgICAgICAgICAgICAgICBzdmMtPmZsYWdzICY9
IH5DU0NIRURfRkxBR19WQ1BVX1BBUktFRDsKICAgICAgICAgICAgICAgICB9CiAKICAgICAgICAg
ICAgICAgICAvKiBVcHBlciBib3VuZCBvbiBjcmVkaXRzIG1lYW5zIFZDUFUgc3RvcHMgZWFybmlu
ZyAqLwpAQCAtMTQ0Miw4ICsxNDQwLDcgQEAgY3NjaGVkX3NjaGVkdWxlKAogICAgIC8qCiAgICAg
ICogQ2xlYXIgWUlFTEQgZmxhZyBiZWZvcmUgc2NoZWR1bGluZyBvdXQKICAgICAgKi8KLSAgICBp
ZiAoIHNjdXJyLT5mbGFncyAmIENTQ0hFRF9GTEFHX1ZDUFVfWUlFTEQgKQotICAgICAgICBzY3Vy
ci0+ZmxhZ3MgJj0gfihDU0NIRURfRkxBR19WQ1BVX1lJRUxEKTsKKyAgICBjbGVhcl9iaXQoQ1ND
SEVEX0ZMQUdfVkNQVV9ZSUVMRCwgJnNjdXJyLT5mbGFncyk7CiAKICAgICAvKgogICAgICAqIFNN
UCBMb2FkIGJhbGFuY2U6Cg==
--047d7b86e2f8720c1504d6a158b3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--047d7b86e2f8720c1504d6a158b3--


From xen-devel-bounces@lists.xen.org Tue Feb 26 14:24:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14:24: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 1UALRj-0003SC-GA; Tue, 26 Feb 2013 14:23:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UALRh-0003S4-Bj
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 14:23:53 +0000
Received: from [85.158.137.99:57585] by server-5.bemta-3.messagelabs.com id
	E2/FC-04457-875CC215; Tue, 26 Feb 2013 14:23:52 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361888582!17326775!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25818 invoked from network); 26 Feb 2013 14:23:02 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-11.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 14:23:02 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 964D0C56194;
	Tue, 26 Feb 2013 14:22:50 +0000 (GMT)
Date: Tue, 26 Feb 2013 14:22:50 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <4BE608E4A7BFE5F8FDF9008B@Ximines.local>
In-Reply-To: <1361884158.26546.291.camel@zakaz.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	fantonifabio@tiscali.it, Alex Bligh <alex@alex.org.uk>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 26 February 2013 13:09:18 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
>> > +cat >deb/DEBIAN/postrm <<EOF
>> > +#!/bin/bash -e
>> > +insserv -r xendomains &&
>> > +insserv -r xencommons
> [...]
>> All the changes look good to me
>
> This one certainly isn't, calling insserv directly in a pre/post inst is
> not the correct Debian interface to use.
>
> Better to call update-rc.d I think, or use dh_installinit (and grow a
> build time dependency on debhelper).

Or better yet, put a .init file in your debian directory and use the
normal dh_tools to do it.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:24:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14:24: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 1UALRj-0003SC-GA; Tue, 26 Feb 2013 14:23:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UALRh-0003S4-Bj
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 14:23:53 +0000
Received: from [85.158.137.99:57585] by server-5.bemta-3.messagelabs.com id
	E2/FC-04457-875CC215; Tue, 26 Feb 2013 14:23:52 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361888582!17326775!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25818 invoked from network); 26 Feb 2013 14:23:02 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-11.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 14:23:02 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 964D0C56194;
	Tue, 26 Feb 2013 14:22:50 +0000 (GMT)
Date: Tue, 26 Feb 2013 14:22:50 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <4BE608E4A7BFE5F8FDF9008B@Ximines.local>
In-Reply-To: <1361884158.26546.291.camel@zakaz.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	fantonifabio@tiscali.it, Alex Bligh <alex@alex.org.uk>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 26 February 2013 13:09:18 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
>> > +cat >deb/DEBIAN/postrm <<EOF
>> > +#!/bin/bash -e
>> > +insserv -r xendomains &&
>> > +insserv -r xencommons
> [...]
>> All the changes look good to me
>
> This one certainly isn't, calling insserv directly in a pre/post inst is
> not the correct Debian interface to use.
>
> Better to call update-rc.d I think, or use dh_installinit (and grow a
> build time dependency on debhelper).

Or better yet, put a .init file in your debian directory and use the
normal dh_tools to do it.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:24:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALRv-0003TC-SR; Tue, 26 Feb 2013 14:24:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Robert.VanVossen@dornerworks.com>)
	id 1UALRv-0003Sv-1b
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:24:07 +0000
Received: from [193.109.254.147:6239] by server-9.bemta-14.messagelabs.com id
	BE/57-30867-685CC215; Tue, 26 Feb 2013 14:24:06 +0000
X-Env-Sender: Robert.VanVossen@dornerworks.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361888626!9008884!1
X-Originating-IP: [12.207.209.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23732 invoked from network); 26 Feb 2013 14:23:48 -0000
Received: from unknown (HELO mail.dornerworks.com) (12.207.209.148)
	by server-8.tower-27.messagelabs.com with SMTP;
	26 Feb 2013 14:23:48 -0000
Received: from QUIMBY.dw.local ([::1]) by Quimby.dw.local ([::1]) with mapi id
	14.02.0247.003; Tue, 26 Feb 2013 09:23:45 -0500
From: Robert VanVossen <Robert.VanVossen@dornerworks.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Incorrect Prototypes
Thread-Index: Ac4ULOFJODTAtcbUQ3SXitaluNGGUA==
Date: Tue, 26 Feb 2013 14:23:43 +0000
Message-ID: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.27.12.29]
MIME-Version: 1.0
Subject: [Xen-devel] Incorrect Prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2380386579896181461=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2380386579896181461==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_"

--_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

do_kexec_op and compat_set_timer_op are both prototyped in xen/include/xen/=
hypercall.h, but are different than their implemented functions. This appea=
rs to be a bug.

do_kexec_op:
xen/common/kexec.c: 889
long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
{
    return do_kexec_op_internal(op, uarg, 0);
}

xen/include/xen/hypercall.h: 126
extern long
do_kexec_op(
    unsigned long op,
    int arg1,
    XEN_GUEST_HANDLE(void) arg);



compat_set_timer_op:
xen/common/compat/schedule.c: 38
int compat_set_timer_op(u32 lo, s32 hi)
{
    return do_set_timer_op(((s64)hi << 32) | lo);
}

xen/include/xen/hypercall.h:175
extern int
compat_set_timer_op(
    s_time_t timeout);

Thanks,
Robbie VanVossen

--_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_
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 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@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";}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:"Cambria","serif";
	color:#4F81BD;}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	page-break-after:avoid;
	font-size:11.0pt;
	font-family:"Cambria","serif";
	color:#4F81BD;}
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.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
	{mso-style-priority:1;
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;}
.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">do_kexec_op and compat_set_timer_op are both prototy=
ped in xen/include/xen/hypercall.h, but are different than their implemente=
d functions. This appears to be a bug.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><u>do_kexec_op:</u></b> <br>
<b>xen/common/kexec.c: 889</b><o:p></o:p></p>
<p class=3D"MsoNormal">long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(=
void) uarg)<o:p></o:p></p>
<p class=3D"MsoNormal">{<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; return do_kexec_op_internal(op, u=
arg, 0);<o:p></o:p></p>
<p class=3D"MsoNormal">}<o:p></o:p></p>
<p class=3D"MsoNormal"><br>
<b>xen/include/xen/hypercall.h: 126</b> <o:p></o:p></p>
<p class=3D"MsoNormal">extern long<o:p></o:p></p>
<p class=3D"MsoNormal">do_kexec_op(<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; unsigned long op,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; int arg1,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; XEN_GUEST_HANDLE(void) arg);<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"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><u>compat_set_timer_op:<o:p></o:p></u></b></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">xen/common/compat/schedule.c: 38</span=
>
<o:p></o:p></b></p>
<p class=3D"MsoNormal">int compat_set_timer_op(u32 lo, s32 hi)<o:p></o:p></=
p>
<p class=3D"MsoNormal">{<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; return do_set_timer_op(((s64)hi &=
lt;&lt; 32) | lo);<o:p></o:p></p>
<p class=3D"MsoNormal">}<o:p></o:p></p>
<p class=3D"MsoNormal"><br>
<b><span style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans=
-serif&quot;">xen/include/xen/hypercall.h:175<o:p></o:p></span></b></p>
<p class=3D"MsoNormal">extern int<o:p></o:p></p>
<p class=3D"MsoNormal">compat_set_timer_op(<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; s_time_t timeout);<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">Robbie VanVossen<o:p></o:p></p>
</div>
</body>
</html>

--_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_--


--===============2380386579896181461==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2380386579896181461==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 14:24:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14: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 1UALRv-0003TC-SR; Tue, 26 Feb 2013 14:24:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Robert.VanVossen@dornerworks.com>)
	id 1UALRv-0003Sv-1b
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:24:07 +0000
Received: from [193.109.254.147:6239] by server-9.bemta-14.messagelabs.com id
	BE/57-30867-685CC215; Tue, 26 Feb 2013 14:24:06 +0000
X-Env-Sender: Robert.VanVossen@dornerworks.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361888626!9008884!1
X-Originating-IP: [12.207.209.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23732 invoked from network); 26 Feb 2013 14:23:48 -0000
Received: from unknown (HELO mail.dornerworks.com) (12.207.209.148)
	by server-8.tower-27.messagelabs.com with SMTP;
	26 Feb 2013 14:23:48 -0000
Received: from QUIMBY.dw.local ([::1]) by Quimby.dw.local ([::1]) with mapi id
	14.02.0247.003; Tue, 26 Feb 2013 09:23:45 -0500
From: Robert VanVossen <Robert.VanVossen@dornerworks.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Incorrect Prototypes
Thread-Index: Ac4ULOFJODTAtcbUQ3SXitaluNGGUA==
Date: Tue, 26 Feb 2013 14:23:43 +0000
Message-ID: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.27.12.29]
MIME-Version: 1.0
Subject: [Xen-devel] Incorrect Prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2380386579896181461=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2380386579896181461==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_"

--_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

do_kexec_op and compat_set_timer_op are both prototyped in xen/include/xen/=
hypercall.h, but are different than their implemented functions. This appea=
rs to be a bug.

do_kexec_op:
xen/common/kexec.c: 889
long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
{
    return do_kexec_op_internal(op, uarg, 0);
}

xen/include/xen/hypercall.h: 126
extern long
do_kexec_op(
    unsigned long op,
    int arg1,
    XEN_GUEST_HANDLE(void) arg);



compat_set_timer_op:
xen/common/compat/schedule.c: 38
int compat_set_timer_op(u32 lo, s32 hi)
{
    return do_set_timer_op(((s64)hi << 32) | lo);
}

xen/include/xen/hypercall.h:175
extern int
compat_set_timer_op(
    s_time_t timeout);

Thanks,
Robbie VanVossen

--_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_
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 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@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";}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:"Cambria","serif";
	color:#4F81BD;}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	page-break-after:avoid;
	font-size:11.0pt;
	font-family:"Cambria","serif";
	color:#4F81BD;}
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.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
	{mso-style-priority:1;
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;}
.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">do_kexec_op and compat_set_timer_op are both prototy=
ped in xen/include/xen/hypercall.h, but are different than their implemente=
d functions. This appears to be a bug.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><u>do_kexec_op:</u></b> <br>
<b>xen/common/kexec.c: 889</b><o:p></o:p></p>
<p class=3D"MsoNormal">long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(=
void) uarg)<o:p></o:p></p>
<p class=3D"MsoNormal">{<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; return do_kexec_op_internal(op, u=
arg, 0);<o:p></o:p></p>
<p class=3D"MsoNormal">}<o:p></o:p></p>
<p class=3D"MsoNormal"><br>
<b>xen/include/xen/hypercall.h: 126</b> <o:p></o:p></p>
<p class=3D"MsoNormal">extern long<o:p></o:p></p>
<p class=3D"MsoNormal">do_kexec_op(<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; unsigned long op,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; int arg1,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; XEN_GUEST_HANDLE(void) arg);<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"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><u>compat_set_timer_op:<o:p></o:p></u></b></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">xen/common/compat/schedule.c: 38</span=
>
<o:p></o:p></b></p>
<p class=3D"MsoNormal">int compat_set_timer_op(u32 lo, s32 hi)<o:p></o:p></=
p>
<p class=3D"MsoNormal">{<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; return do_set_timer_op(((s64)hi &=
lt;&lt; 32) | lo);<o:p></o:p></p>
<p class=3D"MsoNormal">}<o:p></o:p></p>
<p class=3D"MsoNormal"><br>
<b><span style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans=
-serif&quot;">xen/include/xen/hypercall.h:175<o:p></o:p></span></b></p>
<p class=3D"MsoNormal">extern int<o:p></o:p></p>
<p class=3D"MsoNormal">compat_set_timer_op(<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; s_time_t timeout);<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">Robbie VanVossen<o:p></o:p></p>
</div>
</body>
</html>

--_000_30A36F55D047B4489EC149857F230F426DAF57CBQuimbydwlocal_--


--===============2380386579896181461==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2380386579896181461==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 14:25:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14:25: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 1UALSb-0003Xw-AW; Tue, 26 Feb 2013 14:24:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UALSZ-0003Xi-Me
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 14:24:47 +0000
Received: from [85.158.138.51:35261] by server-1.bemta-3.messagelabs.com id
	CB/63-08955-AA5CC215; Tue, 26 Feb 2013 14:24:42 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361888637!21544211!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17116 invoked from network); 26 Feb 2013 14:23:58 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-174.messagelabs.com with SMTP;
	26 Feb 2013 14:23:58 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 72B75C56194;
	Tue, 26 Feb 2013 14:23:56 +0000 (GMT)
Date: Tue, 26 Feb 2013 14:23:56 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <931493278BD056D168E0B849@Ximines.local>
In-Reply-To: <512CC3CC.2010505@heliman.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	fantonifabio@tiscali.it
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 26 February 2013 15:16:44 +0100 Fabio Fantoni 
<fabio.fantoni@heliman.it> wrote:

> Sorry, Ian is right on this. I learned how to create deb packages
> according to the standards in the last months, I had better double check
> the patch.
> I'll redo init with update-rc.d in next patch version.

Feel free to steal the code from my minideb patch.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:25:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14:25: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 1UALSb-0003Xw-AW; Tue, 26 Feb 2013 14:24:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UALSZ-0003Xi-Me
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 14:24:47 +0000
Received: from [85.158.138.51:35261] by server-1.bemta-3.messagelabs.com id
	CB/63-08955-AA5CC215; Tue, 26 Feb 2013 14:24:42 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361888637!21544211!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17116 invoked from network); 26 Feb 2013 14:23:58 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-14.tower-174.messagelabs.com with SMTP;
	26 Feb 2013 14:23:58 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 72B75C56194;
	Tue, 26 Feb 2013 14:23:56 +0000 (GMT)
Date: Tue, 26 Feb 2013 14:23:56 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <931493278BD056D168E0B849@Ximines.local>
In-Reply-To: <512CC3CC.2010505@heliman.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	fantonifabio@tiscali.it
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 26 February 2013 15:16:44 +0100 Fabio Fantoni 
<fabio.fantoni@heliman.it> wrote:

> Sorry, Ian is right on this. I learned how to create deb packages
> according to the standards in the last months, I had better double check
> the patch.
> I'll redo init with update-rc.d in next patch version.

Feel free to steal the code from my minideb patch.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 14:37:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14:37: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 1UALel-0003wt-L5; Tue, 26 Feb 2013 14:37:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UALej-0003wj-HC
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:37:22 +0000
Received: from [193.109.254.147:55574] by server-8.bemta-14.messagelabs.com id
	9D/AE-17325-0A8CC215; Tue, 26 Feb 2013 14:37:20 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361889169!9373647!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10085 invoked from network); 26 Feb 2013 14:32:50 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 14:32:50 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>) id 1UALaK-0006Uj-W2
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:32:49 +0100
Message-ID: <512CC78B.4080606@mfiala.net>
Date: Tue, 26 Feb 2013 15:32:43 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Content-Type: multipart/mixed; boundary="------------000701080103080604050800"
Subject: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------000701080103080604050800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hallo,

I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
without problem. When I run reboot or shutdown -r now, system correctly
shutdowns all runlevels and then system crashed, see crash_output.txt.
I have the same problem with kernel linux 3.2.37. When I shudown system
(halt), then it is without problem. I have tested kernel 3.7.5 without
xen hypervisor, it was without problems. Required debug informations
(http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
Could you please help me with this problem?

Thanks

Michal


--------------000701080103080604050800
Content-Type: application/x-compressed-tar;
 name="debug.tgz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="debug.tgz"

H4sIADTFLFEAA+RcW3PbyI7Os38FTu1D5FlLZvOmy66nRrc42rFsjeRkcjbjUlFky+IxRerw
4sip/PgFmheRlGxLcs5WbS1nEptN4CO6G40GGmAsPovuz9/9Sy8Jr7qm0U9W16T8z/R6x2TG
FKYyJHwnMcbU+jvQ/rVixVcUhIYP8C40Qt94ge615/9HL0vM/zxynGnAfdtwpqbnBp7Dp14U
rqKwFq7Dt76DJlhX1d3zL2uKpMqb+WdIx+qKJr8D6Wd08LXr//n8A3Q8L7Tde3j/hbug1mQ4
B8d2o3VVqdVrWnVh+BZ3ufX+BH7CdeLj26CysKQz6fQEPtgOD56CkC8hfFpxsANYz4MzWBl+
aIe258bN0rqhnDxw3+UOnK+5W7v/Dpa3lKZLvrxQL8+WxrqlXiZNxnr6aK6i4EKNG8TNdGW7
kGj2RRg+SSfpjektZaC/LhjTZEk6a7iMuvp1GDmhPUNxq9yZn8F/SmsmFLaFvzTrDbmBv2hy
3Wr8egbBIjRmF9Ja5oZUb5wBd0P/6SLluDtZelbkcDjfNbBAQ3JxbvHH88Ay9IKU2c3i0ZRK
UiWYvwG9doavOcPfVMtkugSzp5AHdycn8Bf8dQ7n0+kU8L8pAvyAH/g//qS2vwAn+wfi0i/n
QA3vRWtMRfTT6SndCapzQTidnscthEEUP/ABNU4F1fn0/K/pX4j+g+7xD710+qMyPZ3SRT9/
7KdKJ5Uv/etTILV85H5A2oDqWWNQ+W3pzWynZn4/hcq9aULlEgfc8+BjOqRqTa8psGI1xlCZ
bF6ValpNPo3bT+E24qAk8FcGDlUI3YXh3vMJD1sQucajYTvGzOEJDS0RxzMs7rfg8voTXI4/
dUCqNevJ8663XBquReuGt96qmdmNyRL4z7bFPbDduecvDVoVreQBfL5s05oJ+ToE1AcODVQG
7QzmnhtCY830jLDTP+/1urDk4cKzgha4nsv/A/q9QQ/QrrnBnPsQ2ksUX4KAowhWkPIKIno7
MoXg89C3+SMO8oybRhRwbAWCTh4YTvISsHjIzZBbCU7PDsydnfjgRTh2DIadMQT2vWuEkc+D
4lMFpejluSEI/cjMU6KeVHlDlmDcHsLSWGX4UumCar6pyampEgU036fbPKzMM7PkufQST0aQ
51GYKXhQXu7j6O3gSkgKXNpMcLW7owFYRmjsYotpNmxm2s/nX8a3h2L+Otecl7mY9CrXhiTl
kiU14yoOIXWzBeNJb0SkH6QPKhk1SVYRXoZe/+oKoEj7ZdK7FbRMUhtE2yZaltDCqD+ddJWN
SckexHdFrA/4Azo9RWWs2yWsD4SlHIXVI7kQi3UlMsz1ui69LNfg+vYKZPR8JXSEtuSaCLkU
gSXh8BWet0eDrnguqbT3SExvHz0Gk1F3HGNpfZXepb0i9wtYH0f92xhLV8TcKI2jsXrDdiKX
Xie5mHY81rD74TLGajbFeCrdo7H+7OEeGGP1CIspx+vf5Cqdx47UyPT+OKz+eCLGXlaaMskl
198wj/0UqyPGS2seP16d/jjBwhUhxv54ufqD6/9KsIRcrHk81m131E7Wvi70Xs/bnMOwRt1E
JxhaEIHVP14nxu1kDfUU6qPSPb6Pk8QmqWpsk/REv9D09JFnNBrCuDsE9CFiw53aJElHq9RM
sSaxu46bbAswYpNkfdiBCuo9qzPWlB86KWHPWxro2iy4scKNG715w7EDdBtwKcM32woXoMgw
s8N0/x75nsmDwPPh3yTQW0yJDVvq+slsmw4B9iPclw5X736E+9Ip+p6E+9KhDd2PcF86dd/B
ZvsSqvuONtu3z8q+hPvSaXsS7kun1Pck3JdOae5JuC+duu9gs30J1RdHe3BD7V+luxYYK9uc
2hagzUnJFPkMDMtCnzHAoHXOY5f1DC4nA5CqslIEYTkQ9gKIMs9AFLmqaUUUOYciv4BS36Do
arWRxnh9Fz1VOicR/aVgq4U2c/EU1AA+BfRAgcH5jXicmjSxC4fk4VKUZrsYHNlpOPSnFzmW
iKi4KyjWskC2MDYNKdoLue9HKwq4MJhZ0QtMwyX6GU9YrFqCFb8/MBecjgQwSJ0MR9D1uWWH
MElboWKKlsw+J+EZyJok1aQGBmAfv8MqneAUe0CmG9ExoPX8JwgWho+36dN1EGL8PCX7joGz
EMN0w3U4DezvFEuucecCCo0FXUAt9Qw45A58vq3iw2i18nySZWXccyBeJFUfOmcgD/Evdtmp
/Syuiet5K4zY3dD3nPJA5uhw+5LEXjUygiBc+F50v8hN1y6WPyIeoTSDeJ7jMPV56kE2w+Ns
hp+nnuC4I3Z/lChUsEWLuvdo+2FE22zh3WlAVo37FKvumDvGOnvWjynBsv1YJ/o3A9ykcY+2
PbFmDPNh6qG+eu7fUpbrdudqcH2Jy6sqFHcw/iML2qu/JjpJPO3u78mRQGpEHCOkQF4cOPi0
NJhaU1iD9I+ChoTsffs9qiMqI8qDgLF2uXQA4MADf4IF6hWtyNTJcRzPNEj45AAFfCHBHJcx
/G5nuvB5+AUXSKY7hvVouCb+MufxwUNrM16iX8Ph4AYMk1ZFaYBLhLejMS0Py/u2edBfh9y1
EH1EKnobz1wFZ/F0Q/M5Bq1ubOvA4m5oz200UVD5PBr0tqnhejjYNA4n42Tuqomk6FihUm0o
PrnYtdC3xexeRvh78uzjZ3Tk2pNBb0ujxBMcrZIeiWY6afuGGgntILCDMO4gDXflY3t0Wj76
iVnao+cX6ktTbji4UFwc8Ue+a94PVJP/hVd0hLEIIVoButjd0ad0Xfzyyy9wddPu0bLp3Qzb
g2uQqDGdJjrqhPicu0WbD07iGTjB7IwOqFdGqMgppVjJZcpRu5+Qr2hHg/T8WSKhpbUc36SL
8OPfJ4Nu+wqG/eHN+O/QHo/b15f9Yf/6tlV4i0HrqoabHaQHOnJywlT9NW1RsgMd/F3GMEDM
dEAbGe5WRroyUzX+PBjffnr51Vd03GplXZwnV4Olr85ait0S+1UNfGNp2cFDjlF+jZH28urQ
MBfi8PBFxkaBcRIafijOJmmQoExWYlRnavZGWg2xNW+VGFmZkRm5N9J5NO2o5kP5jYKsyDjL
Md7e3LavWlm4mJFJ2300C33EqaGJ6vXG/ckkPx0GvsFMyYS+LIwAR3BtL6MlqPA5p/4T049m
M1o7H3zO4xCy9hOuvKeCK9LxvqXeCtrrfwJu3jxY0E4U8BCMkNIkpKtCRVPmSWjVUOnuHf5I
+tb3fQ+NL3kuaOZclDnthLCdOcprL1wIwzdGDa869tJGRd8JcJqzAhORa0WlWUUhrU60Brh4
RLLrffd2fFU13gu5udgjxUIKcD9G5YxZ8B6NRYpIw4l+nCo9dESonXS/dpL6FUnuDJ1KD1ao
57YpjumJ6MSYeTHgPRdKRbsiDepX0hB0DMV1l46u/V34ePdo4lbogc2CpwAojcHDwxjK1FeU
Gds45cUMWYVSZL/5xj9wPpUk57NJCVGqp5QBUsrwxQzN3hm3EgqNM/WmyauMFGjuoqFx7xGx
2Ugs3pym4jk+kRmoJhmFHLdcV/SG9BICumvcoO0HSev19GXo20RuRM3JXJa4JjijOYZKcErz
zKoMEsUoM4y8VYTOGckaS1llqmzV5ZKwGwlwn9kWlrIwLegMbiZVDCcebTLkmdZl2ZkSE6pz
C75iP3B5SqWrWmhqWmh57iBOHewJY2zDCAN2B2neYj8gVpYHp5TPD5QnTRAVYBQ2O1ieNGdU
BNIMAZTljPZEEmmkPFJi4w8TKc0s5YD4UUBpsikHND8GKMs/bYCETrPDJi1eB3kYWVIyeWgV
7gK6/oLO/pqbUcgp/ylyXRRik3dMKVCMK8jn3Fq3Q1o8INfqwu1E07Zljq89aF+OYObbFjoR
c0qS7l6GjhGEU1q+F+QPxquZMtGGby6y9jQht2XxdmAI7T0AgjakaWyfponZ2ZrsqoCNF9Ih
/PnJ3cxqGaGYVsy0SZqrEjXQMfijtMkv7uROE40ZNyUcqaEtuLdP5FO9iR+kd8+gi9RjCo1r
UWUMtzgpTkE+Sts5yIPQe3nZszyzFCclX5S9lJV8TvZJQXZFoIs05U4GESznGShviQ0ib/nm
oRQZzAK6xlVq0F7r7D7oIqdZQNcVoQaU23wz+hfKchbR6yS7yHa+GV3kPQvozaaYKMp/vhld
ZEKL6Bahi4zo22f1qqwzM6mxWbxvRBfntDl0kTWlBGz9p+hMv4w+E+Mu8qhvRhcZ1QI6LWsp
zqy+fWQox1pEF7KLXOub0UXWNT+rlH2lBr1gko9EF3nYAjpafIHe/xkaSZnZPLpkKZIoJvgZ
IzMpmWyRs0WTraf6vm/Stuw2fBq2IYx8iqq8+XwrUDEexHEYuFRMhqHyqw7587suxX/EjaEh
Rn4CUNqx7z8PAHB90+tPe+3bdrbfI7HOX2P8b8/lcbQSbIUZIM70xbWRhWV9Shy6nVyKnOdi
WQ8yt3RHB+IzQjjMXxl6jyIj9J36ISJydPB84HQ2ReNYpu8bvvOUHnmIgY47vy2PeIhNrZ2d
TyKrvdiyQOhZv20H2yHu2mhYvRXpgcENhqV+SKmjhtTYTXwlfIqKYa7sqW19pem5Q681zvbR
Lbmy8Sn2MwtuG0EuIMhHIChFGeTDEdSiDEcgaEUZ1MMR9KIMRyDUizLohyM0ijIcgdAsytA4
HMEoynAEwqwog3E4glmU4QgEqygDOxyBF2U4AmFelEE5GIFJRRmOQCjZB+1whJJ9OAKhZB/q
hyOU7MMRCCX70DwcoWQfjkAo2YfZ4Qgl+3AEQtE+aAhoxec1+0MUDYTWPAKiaCE04wiIoonQ
ZkdAFG2EZh4BUTQSmnUERNFKaPxwCLloJrT5fhDT6+EgD0MHfAv7fgGcjtoc2w1JvLtnIOJq
I6hkfkdSXPR1U+d0B/eBPZ0ZAf8qbcO8sXJqD6FYSShRN5UTSpGfleroUqw9xJJLYtVLYunq
s2IdXdu1W6zr2+lk3J3efB5DZRYhL+DfU8olSnDveDPDETcyWHOH/jynCs/jNPM4zVi9REJx
CyquoxGH+ZVhu3d7KmIBKvAyPXdu30d+XOyT+zbmhaMr20r8aN2oY7BI49oSQ2MJ2jJnsFzR
t2YtUVzzTRS5yaKg4QwasPDClRPdxwUOO8+NE7c//SAFvX4rOzLPvrES/Rl1B2DxR9vcjlrS
7xNXhm+k9Tffs9IAwK5/4Vtdzn001kq/GlslWYNqu7c1yiJIna64b66iFlyPp9ipSQs76/pT
bFoawcOUapU3Tahq6R3FOeKWbeXT+mMEakF/OeOUKQNZiRNn54gAv4kUekNiiqULBgh0VWMy
+A0qobBkpkkqRFRlXZcFtCbVmK4rOu6Ynch2QmAiSHTsIKT6Qow3MeLyfIv7ZyC+kbPDJxCp
V1EK5dYAbr0QI1IhRAuofFtpNgrYTUoDOrb5JKBbSQybJ6mjAfk9Hn3z+LxqDKbSsh8NelQ2
sEhqJenrSVuUCElNHSqiPy1QzlD56noj/rjxtICBPsh0ytfTmN9wfG5YTxCICq8zCB7sOA1O
DXk+Bf2ndWA8ouiJv5AWNM4eqVLxLC5mFBVLcS1jxt1UdfIZAm8eijoojFJvrzpZoKs09VTl
cXa1ROcrujrsnIrkK1WehfA10wBBf5fCy1JdVVG4oYjpaSDkJo7Fw7kmN5oq0x9yy6dSZxI2
PKQTYvEznNemxupENqPsETboGlNPc/AabY6Tq0+dFlxyN0Co4IJpZ/DxT1xe9+4FfQVxQwN/
IVVx5Ie2ezP7BzfD4ALtJ634CyQgdUO2PKyGsB9t7lNuKM73dj+BvVw5fImCCPNUK9CjLgma
tDyN5onwYe57y3QlXuBCC73cyrtQCyg6HW2Np4PxH5OWqmhiVaJlxRVJB8RMz9Hq5KmvKcEX
mDZ4aCR8mwoiN/b4ogkoyf099R1WnmP4uIoupDyGLicY5CUIoGb2mOlyQ6eKA6HvLZwRx4t8
+lTz3+PPMzNKyqOjDqXlil9pnWSe64YKjYGWo6IFtItKaYpkGeqvI+qUyQTGBZZkYHEUQcpR
aw2kDgOztVUHLBXrgHM8dZqsLurHzI9rBCzuGE/gUEFtRSwydKxw9zWciAPOvUm1BAgc18sl
svj8nxF3zadaDVGljUoqpOB3sLIt+lC2hdhzI3Jw64kX/dJ2qaKohbQsx9MgZ6YnPrfGN5oL
vtOOaLIqNxqZJWGowiquYAWta9GYyGhxKCQakEmvPg8o6zJT1QyweQay1KwzVLwyHlMVRid6
kRu+hKfpORbRqZfLZwzTDHMczbryIgfVlHznm7lUZdZEzRN70yitzMjVn/ZaOWVRZUVvpMQZ
Tdcjq1ci1BScwqWJWk/6lhRoB+goDbt9dDbchyBHjMvoDq6MIIw9H7DJgG5s/+8dwL1QlIiS
A6zSjxe4ree5yQ1Uxc8yf+jMpnMnChYG/fsXC3uO+rZZn7g/0NFCWr1DPleuUDQg1Xwol+vU
JU1NPS4xRD56NfGnERJDJWE5Dx1tNC5C8gRw58cNyvHMB8DOuCGQW8iknNvc1Jsoyoj7wstz
TQ59Igzoc/VcIbwuBp5KvB1QNfo0ezT8BJaP8qJLkO1W4iXBpqgAzSTZrBetB8tRq7oSC852
Cs7kHG1DbbyCnKNGQRJkeTdyM0erkBQvIis5ak2px8jKTmRZz9E2aPPNlfGqRSeXyXIdwdDR
CZerOc5B+n3b95wqMLlOJzxrDw2EEYUe+ea4zJynxB7OqI4QDYL5EETLJbXMIzcuC8kwNFmj
cwS8jMc1xBdaC1nSGPmYMOycB9zMkdfJpbn0DexV8plA/LLs+xwMiJ+8KFdPoslNOsrK8ezs
jaYwOmW57t/StwP3VPNN3yNQLYuHOxzMjaWNXWN6jqNBZ0MicvmAgQsOl4l7KRUzohVM/tUP
y+OB+z5MTQXFARzak9GQlDWN1sHeFBdqaKGzkIZiKlEzucId2M+k2hAjNa2aLmW/h92b6w+D
S6EbVvxtovC5v4rITKqKoCTLeOXqmDb1SxWKl05z8HpDLcO/ApFWLpG33scgKQNr6KqegsUx
XzG+E/1kQnqSIvkiIceuZ+y9/2Hvyn/bRpL1/Jy/gsg8YJO82OZ9ZJ8fQFOUxbWuESnHkyCP
0BkLsSVDtJPMf79V3TyalyzPDhbYhwowk4jd9bGP6urqYnd/q7u77JxmthP/PfcY2EJqsTmf
r9EXLrTA0S3UgvlmBw4LeM+P0EPgE0r/A09O5P9lu2azzIoJ4wMy72ebpQluVLJSfyqYhH4R
U8ksp6rhvT/lnOwjmgPKUc7poENdzqlDCjiyllbNaWLwPc2Z7d//ugMv7fY+k3xTCL4VJC2n
KpmAgAaF2q8W6Av+UUAJYg6KpZtX2DIuHoXBmwG/gKXDlq35WzTcyGI0ZC+mzrqEpmkNEtqp
LMWhN+anSHD8JoIQzGHOwde4X7/CmJg9Nr1RZy7z5+5mf88mhIunr18+ZDsKcO8Zw2Kbct9K
4LBBw8CqYCcMLg3UH/3BNNSBh5lggQ3/L7mmPKOFX654xje5UxDKUmgIRTJlJW82PgDS8BCq
vHAcDqyXsHNVU8B3Mkrj5nYHhjXdGPdjs13ufqSLCcT+u7RZS9sVNtFs/8d7CS8weY0jYrtb
7JPXbMM2tFoOD/iasKMgkCa49/6Co3+GB5D4psmcaMsiWqVp6AiyQpZKh8cjWG68VUgWcoMt
+ILjNBaS+fKaCYARgSUF+ADCywRpG+edY6Q3Oyn9GI/ff7XZWkRxbOVFKNqKoSzWloCiKbgg
fAnKnJdlKZYFYJwXoSz5ylv8ugwgun1kq3KUdJ/BuoJiGtZxKPkXdmHz8byKZmtHtjJHW9r1
UFqBpss40I5HW6+WeoqG/9TLaJZp8LLlSDJ4HXwUFArMVVAV5GxYgNfklGY5RZQz8TNcSU5t
e58uyDlyqmOinNosp4lyWjpOCjmt7X2GKGdYlXZRWtvFFOVsrVJOZdEmJ4whHbdF1eSsZjn7
RF4UooZmyI4oan/AJX6zqFMWdVSt1IvOAdHZiTwvRMERUUsdOTsgKsrZFn6XL72ytWGFoloy
CyKWGmjVJrf8glPQ/HHPd16jUwqLpcJSW4qNC0NEy8fPBEMWyWMeh4e50UPvjJ0gfoMfzAR5
VUMXvCTfJiR9RadbmClt6Gvr0GSjNE02unxirYTJxjbB7T082RRbcyG3ZVSnC719suEvE6Qd
o2rAWqS5UU230GslU2Nbil418AdRdI5iVFA03X4JislRrAqKUZt8D6LYHMWpoFjo+B6PMuMo
8wqKYxgvQVkUU4OAYivHoqSTTLFwWVrVScaRdV20KfqBaUFXRDlb1itybeZdF6YTB1bu1fe1
mWldE+UMVa3JNU8LujCdOKrOYtLZANZfaAAc1UG/vCR/tAGAwWRq7QZAvmg0ANpaGP2gMYpx
ePRrayG3VXMWtXXr6NcKRdDxFjdLqCiKvaChQF639Yr8sQ2lK+CgKu0NpTQ3lCU0FECY+B3t
UENZayG3bVZ9K6u9oSyhoVSVWfW8otYLG0pVbdmpyB/dUKrFAp1FQxXXTsDq7pv0uX+FHyrf
4O0NkibpkiGZkiUpiqTo0jvFEIph288iKY1I7wCqhASLfeUZJLWtTAAkvZPf5zs58hiGDks1
67kCanXYdzlugaRq9nNIuoj0rlLCAgmmJOMZJONPVFW3Vf0ZWLMM+66lgIZtq88gWUf1KrhO
OCR/rrZnczzxj1/es08SPODJn6bRaKEylo6xbRA8eaEgNAIMjO9fZ7P9/EO6f4AfSWV1+cA9
sDlzP99zTy853+z+G6a597sf2/zfGAtOzvFKVAHbwPVvhs1uf10KqWxUZamp6ciG4sMuSTYY
txTfX8g6Gg7n0AuD9PMMxukaYq46TgdqLdaZLJKmYKcOTrCl1HI/JfPmzKbm4PHH+WK3xy/3
RUh3u/rBwy3rGbQmb3PMuE4EaUd5ifTt07yQVVQM9LXJpp1YvFYQZF+5hEAPM4IYHQLlrMaF
dFi8OqC4ITs1z74/7qQF62hupn8Wm0Ygr4nbHh62D6A32zEHxh4Rcth2Q9h5+9DUuKYj40LG
zbYhsAMQGPTGfUcf8m8SuoXfO75koXBUFVjVZSEMm4cMbAt3n80Sab5abWvnXgFCQxVpgbA5
xPoZCAPHbTOEw0vhKM9AWPhxoAVC5RD4YecQhIMRsjYI/aAsNGPr62F5yAJK+MHmEIQmt75+
MeORrdkzEDp+U22DcDjE/DCEiZ/62yCWHOJwVyi23V4KHlxbzA9D4Hf1EoQtlsI+LGs4arvs
4qCsputlRXQ+NH1L0Vbpt5QDUOD7ayWoeQGlF1DZ6uYglG2YJahlAaWti1IdAWVqFT1d5VDL
tVME9hxZeRbKsstQ6wJKK5Zv+DXiOSjAUivG7wM/US4pdnVXHmQX3EBmKEvm8GnbYBAdW0dD
lx/pWc82d+k9XZh1u/iDfwiV0IvNDlS9lU6k2Xy3f2TXzRVQZjm4pODsqnzI93kmDzjxLHZ3
dxu++y9rlYWdt8rCZr2Fh+vXuLPmiwDv6KWgoHo0fNHoC7kF3pBl3ZGb4C/ciWTCWxK8AB2a
JkN1ClRHRBUQLacaxTwiSgtyjlONtjI5qfzppLF+VjkmYODOhnrI9wBYqVoMTDL1+eaxWjmF
faaqd3ZrcykFrtLYXDy899LgtCGrsmk3ybU2l6Bt62pzqaqlvwSsVK0DzaUadhX3iAg6yLHv
oi+NoINcXYeYXK0efAJYy/UPKoasqcZxIGljLAvdWdZaVtPNKtgRMX2QMy2nEkI+IqYPcrZj
vTymb8i6opQGzHEhcpArB99yubbGKi5RWa5qjQVzm/kSMOHbk70+oIaGWi7k0Z8OQNSUzSbR
P1U/w3Yay/Gv1s+sfJA57juFgZc56E1ybeVZW4VLUDO5lmqXWuroTzsgapYisbnoEY3cUA7m
bx4Pdmwj22zv3Z/46gWiFRchE/1T9bNttT7CD4AdWz9HMV/w0UqQ02yxckeG30HOLLXnkeF3
kLP1atj+iPC7oeAlDi8Pv4OcxtzL5rWzoQkZjWMzWmzpfkRGx2pftosZFQsjES0ZbUPI6OBE
f0RGVTkSESZL8/lteGohAC4P6G/kjaVVgtv7NsktCByzS1p5L9mabZty6cgFA7XYPkMEnYP2
N6KZhqEVhzdsPJOg24Zl1rBsxZIZFt4qm+Ek+e43vP5PLHlaSvZe9g4RSsdIBoPar7a7htgM
5DFxj/K0M27eiI23OmWF1t+ntUiLTFxpxJVGXGnElUZcacSV9pwUcaURVxpxpZWwiCuNuNKI
K4240ogrjbjSiCuNuNKIK4240ogrjbjSsgTiSitEiCuNuNLSIUhcaUPiSiOuNOJKI6404krj
QsSVRlxpxJXGxYgr7Uh54kojrjTiSiOuNOJKE9CJK4240ogrjbjSiCuNuNKIK4240ogrjbjS
WhGIK4240ogrjbjSZOJKK4pFXGmpJHGlEVcacaURVxpxpRFXGnGlEVcacaURVxpxpRFXGnGl
cXjiSiOuNOJKI6404kojrjTiSkvliCuNuNKIK4240ogrjbjSiCuNuNKIK4240ogrjbjSiCuN
yxJXGnGlsXzElUZcacSVVsgSVxpxpRFXGnGlCbjElUZcacSVJsgRVxpxpUnElUZcacSVRlxp
xJX2b+VK+0xkaUSWRmRpRJZGZGlElvacFJGlEVkakaWVsIgsjcjSiCyNyNKILI3I0ogsjcjS
iCyNyNKILI3I0rIEIksrRIgsjcjS0iFIZGlDIksjsjQiSyOyNCJL40JElkZkaUSWxsWILO1I
eSJLI7I0IksjsjQiSxPQiSyNyNKILI3I0ogsjcjSiCyNyNKILI3I0loRiCyNyNKILI3I0mQi
SyuKRWRpqSSRpRFZGpGlEVkakaURWRqRpRFZGpGlEVkakaURWRqRpXF4IksjsjQiSyOyNCJL
I7I0IktL5YgsjcjSiCyNyNKILI3I0ogsjcjSiCyNyNKILI3I0ogsjcsSWRqRpbF8RJZGZGlE
llbIElkakaURWRqRpQm4RJZGZGlElibIEVkakaVJRJZGZGlElkZkaUSW9m8mS2Mo6ikoAPvI
s7FlXcUTMlno747tPc3v4tJODQd9Nxbuwnv3Ts1T/QOLc+GJr5PkAe9tnIYXWdhr+3Q/Bwgz
3Zy2ul1s4ttFjmY6lomb5EtoQ0ATINjr30ub5fUK7NL+XDZVHX+O97vl0+LxHJxERcBzUDsO
4eGpjO1XaJrBeo9nPjIc4316ieWQlfncLEBtFbezlUBTKUABn10KH3d7vPu0m254FUR13NtX
Eh3Mtk/rGaN6gj5xv+8W0FuChKk6FQmxXB/Y9VV4F8qJUG0oIsZZFslGkXAn4PwkSYuUgYBN
RZay0cNqO/FAccAdtPGmanYdB/YNDND0zkl+deWbn7YZm/pb6fONP5SRe+0d3/aPmc/wOAXe
dfoKVGj3TfpSTt0/bXniO/bvsx28db9Id2Kygxbsbme84THLgpHMtgw58M/Vdp20vxZ6+GDi
2cPjYemz5Pa+PQMePGhLXK7mT1+ldUH/15YxPcfQnjPMO6ShOsJ9lqy27Erz1c9NkhaChTak
7Hb3J74tvgryccZvwMdIc5aFX2ycHpKBMVwt1OqRiaRFZnHn7BgMOwKS3p7NEz5PI+9LFcJ9
etzxrw4Su7P96Q7v7xTB0ymiv/vKjm9c7+6e7lc4XECP91U4D+MrKIVXMd8J7ZlILOtZAhb1
bJ0svp3+xB3tN92QZUqr8FdkEEozWd1nHSyWpFLm6cMy7bvV4+LsHkx1rZFwEw/Pk/yYPeQ9
2qZN9cpXmymddYRLc/Hc6T1ubK1nzkbfUwINfgf9sGX7iPfLeta71WzLqvJ9ti/Gu6BkG3ZC
8ezx/qEYzG1qBYW532xnSF+w2C3xCahQ98SuKVEmkB0eY7yAn9OjVTa7u6Ha5skKr5VFxdrh
8IfibjICi+UKfFh+xT6713hzdwejAKX20J/ppnaUXD+htWb2bMzurWXbbFc/H/ezOD0xmrxP
f6c3DufPJbzpKE3Z4YmyPOW0NNzX0Eg/ZlCCN2f4Df6MKV/6LP/HaXL7ltXwozsZBsPLD1J0
u+JcFNL9jF2nDC+cY9s8rk5Z5aGptrg77Bs7WQLu2L8o3NAbuN1gCzqFViS91Lit476t/pjv
wFpwdseWXsa70tPM2cW+ifT5KallvEC9Tk1H8ZHubodpkqSo1iks3U6VM7sqKOEOcxTEr2yr
hD8qJGSQ+L6ZFQjHvXi+2y7lEnxyN/ueXhuPadmkiH9Wj7cy/k8pcBsG+D2STIIqzGDw8PPw
B6aOrN0WT6Bq9xUxdqd/w6AXTM4MCo3uCwxEZn14bLiSPxGs9f0DK8zpMnM4q5lLR/j2UAIo
VuoTfl1tV3u2mV+UCYYBrAR8bFIm8rRNryXXDjT7Pm303H6l6zFIKFo87RG+Vx87JJOSxL4R
VURxwDM2bTyPeArrlDNVP1KNUnvEVUgEaZ3roT/B3J7Av9pyzGd4+pRPQMsZmKeaxS0syWxz
p85n7Rnun8B0n7DbzNomlu3q8cdu/+3Q1JLDbfcPNaDcUDOHABsC7egwGsOTDZ5R+9v2EWfD
1d/aYSFDbdpJT8Yls710ImmM2vWUqwIStbZBgd+I/jASwghNV5SSb6ySJWbE+IzXhpPOPMuW
TviPmW7wbGG2v0Ooyv99/uy+5L9GZU5u6w5klvh983OzOlnsD+gvc2pe/UJ//h//YeulM8Ya
zd3SmMdH/sp3YJzO1HX8W7EMWfwb/6VYuvqLosJS2pI1TVZ/kRXdVPVfJPmvLETbnyccuJL0
C3hf+9mBfM+l/4f++fXVr2xFWBwiTv0BJK6COefvUmckDUcRknVHp5CZBSXOeEyiSqeR3t3i
iedLX/36ih9ghfwXQXT+R/bzhkGUfhc/gmEYTaZeFIyGccf3Rh1/UiSOptF4GsXd0WTgRuev
V3drUz+BEp2Y+ussjzvxeiDZ5T/PX+O1IVjqM67eSVqDGFwE/iSX7I+8q44/jsPpeDyaCAUO
I9e7iiau59fTeu61H/fdyB96v0ejBuHBYFr8GPp+J+4M3HjgjhE28itp4SVL7vvDy6hXpF36
Q38SeHEQupheT7iYXjY+jCc+FC6AMo5HeMHvJKxn6330g8ueUGTWhAP3d165sRd3O16ROvkY
+oP4xutdup1O7PYvR5Mg6g3quJ7bDy4mUEfojr77ewW/54Z4EQsr4E1DGnShO+1HcdDp+02i
rteDhg+G0CfBp8YcAO5OoU8mowu/0mGhH03H8dif8FwT3630Q5bkDy7gVzeYhFHs9abDq5Z8
Y/fSb87GyxNc+JOhy7R6PArD4KJWqXAajv1hpyH50wgqyW4LFkSmMCqZYA2G6V8Yj8ZRMICW
6cCQgmaC1WZbzo6PioI1cPswBipNxa6FjqOb2gCOw8G4/KymQ6lmxV63716G569P1mhpTvB+
pOXJfrmRyg+S6oPlz8qDRfWBXfntVH4rcvWBUrYUrPNQQ1ARfTesd0vaSlOWSxg+uY0BLQzB
Gp3dbeZnPKyWnP3XdOgOcsyz04qp4S07+S3+OJoIulJ/cjEN+h3oSD/2byIX1CIOuXV5hfb7
klnsO/51p7C3/g2oZYDkZ25ftKygMf7wGuqFRR6ASdbULNGbgNrF3mgwDkD1Xos20e1fg9kA
zcXHv0oNCWyYoX+NZJbI2yTW8goUHxTo8lMwrmhWmnIBKWpzUv+TaOvElJtPbRKjIqH86rzo
4nvFUlcz4NsPpd98Oizd1CSZVeuNwgg15Pz1G9wk/jZv8PCjK7RT+Ht4HYy92gP824uEzgWr
EdzEg9+m/tRvflqI5CXt9twhWNeGYjLzUrE2KA8GomqDPrpRyQixh9HE98U38af90WUwnAZg
kWBSZNrcpjT51OROOngFV6bwuC073+FeKHxD9urECSOrMhGISWFv9LGegvYY7CbmKI9RcEA8
MKxRDyaOTsmyhmN3EvplCQ8di3A0BRneWp1R1RaLWfB2+npZmA24rvVBPtcigH8NQ76h8kIi
NyjPZJmM3I7nhtHhbIMABn7nH9PGfIMRWswOd3BY17F9mklT70WBdxXDHAedIEANR3FPHOQw
kYA5DVlDTHKFAPN9Fs2Sb+yWnpwWOMG7TNJASuU9bL73vNF0GPGOy3UUO5a1cpHcoJ4XYQcV
yfPBXELGSESopsXXWgNC5IZX6PoJHYWPuJOUYYoJNw3PglG5Fqwx8NK7sKF9YTDGkCYWdQzP
BuMoZnfpNRgxeB5PQ3BufgsbqoCpXXcI7vi5qdcfgvvqds8VswyXpvlQnaj1nV1QO971jVmy
qsTMG2/MElyl1+bUiw32B/S/C6M96Ebnil0yOVNYePAJFhzLDtd0YQxfTkbTcSg2IX/EvaeG
l6XJXSjxJ7aGqQteB16TBcTrCX1RPVCn4jHYTZ5SLRU+LqsIjBNuS5iG8OGSv37gD7zLxqZL
4XrTSx+vPjuQBfyLbnudWQsWpem6wSQupxR4XbA3MAt9DDpRr1krIlG2MctF/yp9dXOZe753
xZY/2DDRaNLU6DgZg/H2RA9vClZuKPzGiVf8jV0i/h76Ef+dv5rrErpH7cUDm95FJxyGpAf2
stM03tL1U6nGoD/Mp5s0N4rn5UsAnK/YKqkBuupIwCAdAiysu0sVYS5l1DZdw5yuCGv47KdY
RXhJnM5eraWAt3j+mC2S2PgWPDkQC38fCG0Nc8W4Ly56xxPo4JLnLCT6/S6MhYnoGnnh+GoS
j2F1jOGEijfZmnoB3nzcnYpTcHca+cIC1h+PxNQwuBy6/a4wHNgEJj5g86n4IOzBGBW6JBiV
ugKXpJ1GPeFlB/Q4dwXYxJCGZ+p3/UkuzJgezpQwNxczRhkifXg94I9Eo5I3ZhD/Ng0mV8Iz
vAmWG8fSeIcVhhuBi3HVPBb67kWTegBWyRx2g35l9h7xp60eZZYuBJPSJ3g5O+8UQd/yxV7+
gn9MB+MYiuc36S+MtOrykL3V73YDL8BGg/VgH1QBrYGHDoLwronfLByAwmKcCBKrAaerRoFW
pLbiMd+TDbXeaHRVScQ4lBtFYj/D7JO7eLD6j3t+f9wYUsJEDNykLnIFeeJfgoM07PDAWtog
sTsOmkowDnItEtN6H0GJfJfb9UraILiBdi6SQ/bGSibm3UCDTSdDcDiioBuIClAdSagkTakN
wOw5Q+fV60wH1ZUva/dCoWrBq2uulKHbhSl8MMZYWxUhVSYeLGXBm0qOVI4v1FvSOqNpPRD1
0WVjnI1TnPH4iiaLATTkHfU7Qv66MqQL4qoqVJL9G9+7rlaCh2B8D+FjGKyR2Edtz7mOFQ5s
dVjV/fyWYTHE1RwOXvSIyk08GHWmfViN4IjAyQVn6Dwq442uT+aMWznb8LPfrTd3fDGSGxTM
lla+0RaWFsI4FLxRz8fiNBpI9yIYdoXYB7hNA5yYxDHPJq9wgAtIuVKRkoPIHvFFLqiP2zTT
pHmmQ0yvNksqmieKyKkehY1VTsXDiZdHlvrNjZPlbPTzQwzED1zvn5R9bXPbuJLuX1HNp3Oq
dnYs2ZaVveVbBfFFQsQ3E6Re8oXlcTQT10lsX9s5u/n3F90gRQDsprxTlUmEfggCINDobjS6
1zKzPtnSleg7EWqpnH3EKk4kLQP3wlcVrUpZHWwUfuECzlExxmb16+Vob6yirCQKOCLciixw
hWGhRZSsx1D7jIp7urUWU7kSDqGvsxKlHK1TDxRVZ6pCrcMTBNByQ6k2HutKtSy6b1S9JB5R
eaJbodBITJBr/eROrzSn2t7SGKaj7VcrSXe9TqpSN2n02TqjGrQRZSooQhQz7wK73Hwx+i6c
fy2jPNmz8ol6+HYEm7Etf8ncKA5ZnltbR1caajaaOFO7owTxnd2oztjYPTBij2SehAaMPNW+
9/a3h7/+38mCiccNemkWMkMWoDvtGtAMHTaDlj5GI5/d6VUXcQ/bRPdpZIimYXoF5rvM3jV6
Rd0s4VPQU7yIDJalv4734BVifafuZMaa6f6ZSFrg/ukWRvsqykI4PuoVjNPYA2ALkcGH4w6k
04GE1hHy8gDadVLbmo2ZCnkqK90nOIRoT/4sAVqUYitBsa4j5ViwTpTzhrB9ZK0L/UMLE+mF
W6JVsq0WsFe6Od2bbOp2vU3dolTsoRqhP5Dp3e31xYUNUEZ8RCXeGTN4Px5jxfTOstHaC7aB
6EnXaWKAYK6gaZageRaiLG+WeV4Zzc02tlTeW3vaZkGXFyqg+DQosDOnclHlKVnFyQ5b1Mw0
wimB2VDNSaqxic1tyEDyhMJkyj+wF2HooncFnmepxtYugIDyK5xQNbbhoGtYgqJbkBcHlwbS
VqE1GWPSUXXqkou5/gre+qtU4Ba0vfIcEMBivfVWrt7Q0jpFi3Gsd9jkYBk7AYATLqiSVFlr
C9B6iZpuDItFGg4LAzipq20JtogqXyXFsiitwddAS3dWr0JbNVnpHUjzZcfrQCsAuvgwWtxE
GVg/tdp06Ni7xVJ2Mq8SSwU3jxj1z1oCp9QqLi9SqV0XFqVW+ztbdJZnzqLuyrd5ormQbik5
1VsUM81R+wEl0psFYD8fFJZRmestAs1lyzLfaKYCS7pxj5RwbgTRoMD/5F2x88m7QlCG1DpP
HPmvr+hzFHA9qrQSoEV4rZAFmgvaj8vFhmIbMihz8KOxRbW2yG9yT3Aa3ReDqoecIxaDEbBX
Aa6oopZWJahUFeuDVvTDsGwq3yvI+O2Axk+SQ1nqDjerJehhts21trdf3WyvpPVVgLAiHgVt
nHBgp0UBGNRmYPQEPCw5ylxsHnZ5oNFWcb/XfL9dUV4Pe/JglbXKbgL9bDd3reYMzAN4GrCB
zaDR4oz1vEz0XqtnRrvfN1uR1NEt3Ea+7+Jv4n+9/jzyqr6dqchqQVGsoQRXGM2aKlmAPa0d
x45xoUnGvEQvVhXZ9hprtPZVqf9Bkbb6f2AI8we0R6DjSmNaWzRVvorgi47UNWyepx46xdil
xnnMTFepAlGG9uP2zg89bu3UpNixitAv5iQO2u1NtPhWVEZlAJ562nlQgQg8XU2uSuEWjay0
Tmpt4O2305N+omU9e1EbOVBLNbX1MYHtW9ayXr5S6YiegF/PnBeH5S3egHUnPSvT+sPZUpjD
waHFhjqkQleXtj5RVQLdF3oLdRJpxRxEHPIlcZlnFThpMOwZJZMGEh7AgUNZF+5nAQjsKSBF
pl0jeqB53N+VtCwETob5zhJA0qp0PgD81uJxprVPrcUwjTOapz3yWqLSSj6o4Nhln1/rEdXy
uNse5awDrRHbzQAFWVU1acQ35jpnrANjIwULN25ntCHsSzO9uKAM+1+a2fWFXaEuuXShXi10
Nbe6Glc+WZfgLWBZBMA8aYlOpVBrz7ILK06CtKG7pJWJU276jl5GIIxULgs7PYQC8fChln0A
D7gdHqNsQ5WTnQ1SVPhhqlHHFfhtDTf1+JRllFFoygYZFfdBZIG4oRv9+Pm/j6+TH3g1FPLw
oYaMwbueX8Dy9WabOlvfRmrsW8dIUEOSZCmMqtV/tN5vkuKgaaOSKLK/QVvS6uG9kJjiISzS
aCkybXZiE6GuxwFK0IVTiqUUqfcyzikABshaYiCUwHYeO522ivVevovoVYGoKDCviikvjVM9
5gxj8AoR8BUvNWOMXInbIddV5dkZoTgWGV9lqMeWp7Z+MwwLQIgsUsk1qBXt3AeCWmkFuQlV
SAnTpiOJnnLgv9kcIlHeXvht9r+j1+hAc7sk50R1PRE6Jc5rmN5DhF6fI51VS3oeIpFzhLB7
nWoRKB+BLVclbZYwc6OIJElVsVPeOWFBSjuThXHy9nDvH3WgCl1GdzSv0kTpuSH2jQFOBeKl
OuHg/FmLmeGgGSa16eQFOdPb/b/h0qrdCnmj94bBqxCx/PnW8a3JPyCezPH94T//adntA2vZ
wlc36ohb1iXscksdOxk+igYu9/Q8AvHHCFo972tZPzwDEIrv6GLhzi8o0myhpNd2+wCvYSJA
efysLWO5mgXoVJrhw8jJwH7HNwxhWreE6x0Z6RrlSYvK+yqmwK4UTMmoG7S7ne+p7GAZwQWN
lYGEIx+U/vROZukJlWtjhnqMb59Ttcy39MCBkdR9uhBKhsPnMXEVXYV3EtNeEnEP1FEzXrrV
gu5C7cn9xOPmowlnTElZFiiAhXQOpNYFPVVL3fxQ5oOlGv3P8eGnibGDV3HN5eq3yR+T6AdG
5jCyR6fUyCxOKziitYS31geFIOH86gmt/AsuVIWM7BrgsArO7zsNB8DrSISer505Ts5raqm1
r0mlbaGEml2xUorLWWv3886ckOJX7hiT9pcz4sWnIyh3PMDqVYOppDPNWupo63XuP7mJDmpQ
iH0Gy4Re8ptoeCIC6wimZ164rnOdZJmZi8+YXvzF+5xa891E3okFlGh+LCjOBCeLNhp+c9h9
bDt6wS+83OQVgWHasdlBoaqXurOJDGgTJWKMjk5zP1NJpb+w0moHvfGDc6Eeb6LhMrN9QmVh
LDGtA3c/W4rTmXODZk5a+NCwIqNlZGiBLOQYcQXrQk/WPVd3iq9mtvqC4kbqoLXiPN9I1zYH
nW4E7TKKtEjRDZWmpTBreTp+kKrOMtLbCyGGOmiS+dagKxlzRM5IWT548C4OuYwiipsgKinz
QYOY2V4FBYihK9IR4URcknvOiRzUS7ShDx/cRara5Yz8eUKtId7bOEKdhxy0ED8O2UYrQa+q
EwQ8U/0bKUNUcqYtWs+ixYsTQqsZ9KQ9IWSiVfdcUhrd6bTeH/eOUHrv98jdO25/e/j55+PD
b/YHTcNrZcuustjOXf6xneOJrmC4HAIMZwE7b8yDjF8ysLomJL2LYOLO9eq2WoMlek3783s+
upbhbaks5uzCmnNL3UON8oI5ter9tvtrnafDCh92s6fjGLe+3ZxpBHuuZDX4grqsmZNiH5Iz
MGmjrac6FNHg6bFxAvqKMc2aD9EdEKANjF6PBjjYJPpNBo6TwZSYitIxt3ekYn1ApVvvpmlB
ey5o6Mll0H7eFLJaTo+wWGYny5UyXEVOzUbzhHztWqDRkirksWXux/c163/pxe93zCXiFSFu
D/agePNvtC8dMrHvpGXgLZ9l4Bm8oUubwfjbxPb7UC+2YUPTl0M2nrd0T20cfG5OCh4AcV6w
0AqdrfMmDJhdxwapoDoPqkM4yqFXhdM4oXXekN7HHFw88tITaH05uzyPkoyVwAHpCYKnGYzL
pvvds5Gx7T978ZEuKJF9YNQUJ446390bM+czUUvOJoxPr9M6Agf7PSWd9xBzgft0KWN/Ckv7
489HCKLR3h2n+IJWptoFR5Ggpy3Zqfn9/vXv47tjA3Oeq0S5AikaLuee6V6P7lxvPv5AIpSS
MS00kA+03fnwA6HiVisBXtPbFwn9X7UCDIto7j0zCTq8y3EJwMgXbxFZbCoZbVcWD3aBUTxo
qZzLGoXX6A/2uN+2x6oLilSpc53SKC0Bqap0178z/TGi4sh6qoI1Hkj7kg4BC5JacRozBc/T
lHbUJ8FZtjxUkWLGpUeZoA3nUCND3IO6rX20FwV9N5iA8vslgY22/GVICv+h1W2wUUAfQFFQ
xj5AQNdCrXHsP/wAOsZ9GE3pFQROFlq3sC+hEBg/cBAFOTuLUhGcoZ+ZYUbSN0rQWM+z+AOy
7AmdK1qnpKA77nCNAI9Y7ij0+qD0FP4wfFMBf/ko/K7OK0YIHII/zKlbeCQSykuHhAbeiTEB
8uXfEWQb6Wq0ts78+dHuAPPP6MNZAm22lQ+jvXP+MWx9SUeRkQWEmeJIWzXYt2TxXx/QFWOw
5pQCVeUrRjkbIaE/wMlkb7dIwzh10VBlcRJgvefavZSxxloQjj/bmLIwI3wWWFWkQQYR/p1A
U9pJONFn5/DWIda+SBU3Gd5s3F6xb9Oq2yqJhuNykoBRemBUFQc6PkCd8FNxJhgAlWI3QhVl
MTS/tNPv3/P/7QSc8xPQjukHjvnc/Jl/YAJZmKiW86vzMGjgeRSIkOdR5P7sIKC75vSP7Vv6
gb6dmfk2kuMrc2uajLV7uD7mowtkzk3z+diU69cObYHtzGZxEy1HjYK8gAlclrPDlCFj9JfM
mbOoaLU2mZE7naqso03Tl4FJUK5S3UK4R+cFLMCzGSWIareJyJrFxWzqXMnrS5vVtqQ7HGr2
QZ4OJYlzXKB/cnsWfXInKpHQmvB+dk0PmSjo27M73Y2R88dinWfcrhlFEQzANcWIYTi76DLI
zu5+Hn8eH5/+/qO9YOm5JLX4JljSXkkdfV3R3TjRY8VKLAgoSkkfCXUAFJbHG1Ey/l4dXcXj
jVTxeP1VdMdaRQxgyYreSF+da2GoxmwpCNF/R6xVyVRSsjK9Gcm7s4MdrPMNK9kh4u7MWME9
mPHBiu8+ANLcoIx4gdRMHe/igJm/3yFH6V+PD8NDBC1o+IYTKIJ7/7xYjYgqkFkY0Wu/w+Ci
pbfeDhIz20BL5iTl0xvUlncu6AD0TnJqQZKPt2EYJ8oCRKkbzLAvM37qcLPNqbElBpzZu4eg
ieccaGyAWkga8fphhwHnG6aHMAQi8DU7KDJqMN9EgKy40G0dIJXlGCcAiCzGq9ACwyi9iEas
1YhQcuRzIGCzPFtJ4Jm4/TUuY8fVIgwoz8EwUxiLDQKl2uilFjQExoAg25AXUbZVO6m/JVFp
aftNlTGGGnTuHRY+EwCuyE/85Z3jxbIs4uazOzi2W9bk/fj2TuylxaZaRazxDdRvjEBEAtYi
LUXIcO6A8SmXJXNatmTcmrWYui8ZwW8nIVIvw453MhU0ayzjjWQClECnPzHx6ISkd9MgKsA8
x+zlMeWKg8527SfrJJ/QpNkLXx//baJK9LGCHx/a4knuu9bVJriXMV3CTaH17W8mAde35/eX
7z/74MVhtK3Swj247cqaFCIGkLIyHG8muR22oijNO2NZphj/wwtOGu8w/IwTpaGDyqyNndPT
4AahOCGsIMbqoJr1QXdrK5V7Zda6J9/GY6SnAPgrqrWuNYQAkrEru548yLvE9tbSyOHmWx4U
M8+I3X1xrTF393hPg9Jd2HCD8lQ0Wy20Qp+TkfmKzL4Yk7WRKvUGolR7hbYLdIGJPm0vy6xw
L6q0EW8cNtEGwYn5kIxABr9upULdfFlczvb0MsL4jcVdwy3olhxIpcYw6Fgqgk9z+gJYB6lT
RszsAEG+wxMcJoqLASVOaBa7FC86YuCM2wVReXkoqjyh46qcelEurWUAv5o24Ar67Xt+wN1T
2XL8W2RbxqjZAdSeDkjR0UtBD1wQlnkKO0AQbpkbJ5Vocr0JNhET5RN87PVrbB97YnwsFFwV
M474g2aux4ehXBJXRyDJF7F8VZRpjqEgwvtlsr2Y0TXLZdoIRY9NsRYZF6XDhLpIZdgUFXPb
ZgWu/wEtdVcyTtFhnKRGWZDkqi4h2UHJc7Z10ciE3nm3LVOGCxQ5vQkXeCBSM7FiZz5nMg78
kWZx6eTt5wtkArNH21CaT5fBnpbyg+XN9GLQZRNe+vg/928T+fT2/vrzB4a2fPt2D/mm3l/v
n97gTZPvj0/HyVf9pR9f4J/dxijA2nk/iYuVgBSAPzCN5tfn/36CXJmtU0bPG00IudC1goXD
9qhAyVPC21NXu8+qieDLZ1dSCj0PMN4itXsG9lUXfNwNOwQl1cqR67GsdWJhqjSbTXzaC7DR
bWtN3KN/6PH6139M3u9fjv8xCcLf9fexrkWdGIcb03ddmlJaEOvIuSKj8ZzqLIfsVZXgYRva
2+XpZSuyCQHNbswHAMNLk9RkYDAA6H+D2OJuxEhJ8tWKO3xCgApAvleHLKBnRtXNyjdvVii4
fNdG3XSrjIPh9HAREv9/BqSE+ghEi6GK8Zk2mLIYna1wXT3RYozrIW/mKWfKRSpGXMGYyPzL
g/1qeWnw46Crc6Bltp99BLPXw58zu2c04yvoZu7lrtnr/3CVcyO2LpQYfHX94Kc9Izd1gNEP
JfxbXh5ZBH6bPIAMbkYb0AIgNsw46NOZWj5djQHS7Wg3022djnzDsNDC04ze58z7wadXT7sR
RBmkijZAptFKIP/Ooh2nBZ8wEKQloDwFTwjd0cE8SItqNjoAdazWwcgXWEOACSYCOc7yWkF+
Dlo/bkWBYstOdM0vYvpZpDBrZ5TQxBnTnHYD3F9OP01HuhwJxlZm+GldgXRkruPysBUXmL5j
uSOzThZj3BpidYzMSE0XUyaYhWHBFWOxNdRDen0ZLPTCpG2KbQPpCY3EO5wPzXS2GGnEXaJV
7pGvBPQz/DUpxioIg8tP1/8zTr+gJQ1DZ6/wGwkoPcP/inRxcTEd3QhHFlU8PjrhyNTKVWjm
iPACo/Q6lc0lQMXKjMAS0vd6AaF1sGUOMYvL0paigOSq/AqKCry72d5kwEylmL8Yc94/PT/9
ruJ48nT//vjvY58M2JJnsNZ14NcKRWTkS6TqLgfT+YyZ2aahEHMJauExSiYz6pgQaXF8Enh1
Bx78nrXJm0PI/mT1qld6Qi2JhUxuKHz7neJi2ZjG7bmmLVMj1pvGAfsiW4gwu0n4saQcGTTI
n7MUGRN2HxApbYxGWjZCA51NKpqNd99ijMiwSCRu6cMcJNbJyPffypHPs5VVpNRQZys+PuAF
TkSmBYaYcgY7IJZCaQUhoO3ALaRitmtDrvTnHqUXi/kNPSEQEKTh/GqMrq6vZzTjP9Evz9Fp
Nd7QDwV7AIqAKBaMiwDO56K6nI9UD/Sx7gN9P2OsGicAfYkG6bJazKbn6CMN+IxRFUcakIpS
q0/00kGA1u2DcYDMPgvmSNEA1OLmako7cCBAy/QsWzEALVVyrBABmlnOLmZjXwLYKac7IADO
hjjJ3ABCJtoJ8pBgOmOkqJZO78GGCJHXSgxhOwKSyZwRkYoxFofEKldruRwZwKqUccIIesUY
q0PiTmbLPBsaPAuZ//789P2Xz+4GPA7ZxEXDhfIwM3V8jphZNjJAOWf+NF/3ix+3zTnP+uv+
+/c/7x/+Nflj8v349/3Dr8nX08GXxxK5oCVAbE+C+Gbwals4NFQ50VNNAqgwqiL34F0TIEib
oIQ7TQOx9MKpBkqmw5Ih6Oraubpt4kFAzJKWSCuoXQhPwSg8aXsKQQ3C6eTCEehCImaQTcTD
EKI2TVKZKNqEgPYT1VpCXPF8KyE9BGeCC1P0RGBkME1lzDCa8iVyYyhAVaOjgn1MBH1/QBPN
uSpHjRPhBfWwqZr3eOklTtTTXTnG/B/XyrsZbpx8oyiaTC8/XU3+ET++Hnf6zz8pU3wsywgO
xem6W6LWNxQTC4AxtaQikBmwvCYsJeT4ID6C3tbao1jXEcfN3wVcDTwqf1gDVqcp3Zzortay
2hf+SkhDHq6n0gmAJEe87KqIORvTPQbPTdqqsvcofYX6XypP3Ls+bWIx+71QBCEHOIcmpOvf
Van/YZ+jV7VzhLjlzuVE6XuUmlkCLgz9yUrPcbsBh/C7WTTwMzLW++YyYE7ELIwIRaE55llY
UkWMFGWjGGHchkCTc2ZCdiCTGjV3mNzyitLmwGjsnEh4tqzuO8hVnl061YG1+VxjdTsCEfLO
WoFI9lEomv0qZaI8WpUF6yhRI36THUyqgAaFnMeu9XR4/lOG/kkVBYJIWCOOih1qz+gOFmbN
LZqW3sVG77kIHYUWiq0tGH/auVlWTtQ1/bPh7r9r2pYJm7Jf0bwHCEzIDaAw1dm9XMyuGbO7
LHzB60T6zF+P6ioeU19smMaILD/7RUFbGnGp7VCHkhbx4kgk2dmXZKJSEXOMYMO2MmSEbguV
b+iKIC4nvxbaeGZRtpJc/IP+FXcDi/0QA7f+qsi567vQAgBzBgekKqdiCJWL6fwTw885BcyC
qIgJ/2ljJLdTOiDGYMTYWe1H0xFf/Q5ToV5+FlafbWgVrWtGr7FRZxGcfmdBdvILx4LjMGSC
MMqCUYfQx3XJBMsu1odELjsTpZaQJrqkc3QgNC9RLS4u9/AYLV9opYKjtRyEpYdCS4ngeMTQ
72Ats9QEAhQytEDq3VWw5NZ+yNJhnrHEToTgAUG6uNnzQyaDIqkVS27XO0s30bQFP6yq0lsY
Y1pM4FStml5Mp3wHDadmyTEm52QfDmXeLGW1FIxqVxTMcUtCRIKo1fLktyy+3r+8e5NT07Wo
VNFMAYgbseMkYyAXEFeupvkR0MsqWUyv6S0U6PoPt26BLIs19/adxymNZ9UThkXdPYK/8j+G
cTT/OXl/1ujj5P1bhyJW7I7hweB8Z3Szcy56LYpw0dume02kraZShYS++vTy8531o5JZUXuh
0nRBE8cQ1d7353YgoBgZj1an2OQJ2ZgMB16tqYB0gkAbzrO34+t3CIB/Oi968xoJftEq8nxo
XUpTKOEGzqRhSi8vPcj72+nF7Gocc7i9mS/8933OD178AoccbclWRtslcRnJfJ6Bw7nz5CY6
LHNRWhaxrkRvDpulMz9OlGSzYbxZT5As2lWM5nfCwE0KsBswSeE6mKryndgxNpweVWdnGwX+
3rS35gmyr7xahp/QMujlmIdBzYgirfvaV0H6cpAK9d9FQRHVIdOKtQzoJ2UcLZ1U0D0Nb3Z3
6ZZ7hn2iR5olaYWdsR32749Ar5I0z7XeltfBesNc0jEwFZVScOlhASCKIomwohGQ3m6vP93Q
38wgtmq/3wtaCGtb0o0psG2auXVLDyJc0EqugeA1aC5kLAKgP2Z985PIxJT2nhThzZQ58WuZ
Ima9HwGIKhGqWVZMLLgOBFHX07yKmDvGHVfA1FsGOdYoiBufcpGTDeagZR7OdmAQQTq9+DRC
r/GvsV6F++RydPSCVFzSMrOhw86oV74XRh7Z6Pr+9Su6Hcs/8onvFapnuRWEGn9qrf3iauYX
6v/7MXcMIagWs+CGOYExkCIAjkG03ZC1yG94kPcYd/HfUEEQLUXjVey/Wc3AwE4iViKNSB/y
4Nv96/0DRKnonfY7EcOJbI5WVBOU1QRQt9jetuoAVJmfWma9I9F9MQR0D51k4hBt/NOiKaqD
f1eqgOwFXThUiU47nIO+OXfCSpjPo2V5y/HH8SnPwZjAxqAODkEiQua9ab4XxgaWMLZBRMC9
btaN7ZAF7LrsiMxdzY7crBjTYv4lZyw1knE2y5p1mDAGgGbF3N+AXQ/yjLu9wEm4CZ5ffvUT
b4P5Sn8433nD3TXSXysJy+2gTnV8fbz/PjSot995YfJdDQvd2142YTBptQLWRKJMDvp346Tx
c+pz3LYsQlY2tf7kTpZPi9wmSWoxVxSESHdnUVOR6dkO+T1oOl7Dc3Nu2GRzzMrTS3Xyr8qe
n36HMj36OOh4lEGchbWPp3HYrBWVDLIFuAdUVqH1DfxKPzPTriWrIMgYVbxF6MFeRmUomMjl
LarlxJ8rsYIP8wHoORjc/DmH2Uu9gveaww+QHU/dBu1BoMVndZnz9aDASaLTFhDJWCBDVLPW
fDDxI/GAIUhksr1ZSe3RADHnjlSGUyS72WWwaAcX7sOcizUErwX5JY9jqvu7PsFeb5frCk3u
KJl7LGQA83K49gQnh2tfvJV2EtRtKZzXl5efmPhKIE1L7uAu3XGZfbSI0H5jqheFe0aISY5T
T8XuqSJbmfyKgzirPb8O9J+C4eVRgkm7iYbAnuzJTnLGOO5yqW/UMDNWUSiKoxSuX/gJ+jf4
tNy/P7++WU8ZalVMHr4/P/zLJ7Q2H1cFn/z+f7E+y9zTV9Aag/6z31ww681Oa2/oiYPGwVUh
c2Pn7YUxU0Sbo2gHaZz7mK8pYZI3I0BsKdFmvUvde65YoKcvrYIbqrnjHKwJY2BmHJUJi1d3
y1MsZVWv6pIOezpA0WasDrZZVBEn23SQ6cVZTCzS6fV6JA9gB5TXEEOc/jynym6mi4tr+kzQ
xixmMeMy34JgVzvbdLlMBSf+9JCCu8TQQarFzSggFfvpp3FIVgUmb7bkHbNbaBEsbi6ZG+Q2
5mo2/kol1fX1J9q18oRJVXB1kzKXCxzQ8vJMF1Wwvp7v98TF9QFUbwAQ8ODs99O4+WLO+FF3
mGo6m453YKu1z8txyG5xOZ/drMcnpgFFZ1Bo81Hp8Nolev+NLX5M6Hh2mYlqczFlVOk2NTvN
IQlBoasaThJypaTJDGv0gOenx4e3iXr8/vjw/DRZ3j/86+X7/ZNzD0EpKubMMkjFoLrl6/P9
14fnH5O3l+MDBI+aaFbhOLTDY4MxS39+f3/86+fTA+wYI4d8IBqznmhAVOk1c4dmrZcmZLwL
aG4KD1cpo1+K5f76Yngf3G0WuKEzIeqKgPX+BZrk7Ia62jIMLjn3bqB/FtmXJkhzLqoNYLb7
xTXdsjJaQb43hlWlUahXcJsFcfDNVq/3L99g7hByh1hRPi/bFdw2WFpmDVMAnFXv+rW6nc77
OoBoYhNpsZbxByo5pRfzpNWJWjIRB1YCQwXTRBlGeZPXFRrbcvRpI4GMm160P2S5MtWQgCWm
gl2tqyYJQmp8BzhMbdBqDdZFqbfn7xhoQK/Yzht5eHYF4zjQzXUhaOUqjyHMFDjtLZ0ULDRd
bzZfIis3ODpCkkpnXhO+4GstUQ2at5a28iBDLcbbNdVr0oFWl3ae1CdOBhxHa9fwwMCsAXhx
BacGjqAHpUFJHoYhDXj84IEaTr6ZJ5ZRspGZ0yFweyvLg1+mNZzMLzQ3VfwX6iFZ5VnJXX0C
SJRqeYrU/ID4ZRMd/ErXORzesxXqJ/jzDAQc+NbUAX/BF+g7rfozV47wux7KQbYpB1DtZLYm
HVpN0zMls5WXNhooScBvu0iPsnyba62OPjdDiO4YNYu68ib8TLP5jh7TUgXQyzrVO2khwtkY
avXp6mKMvltHUTIyG9DrCNa1O/dSMHGUw3mCxuPxqaAZpKSleKBq1jYyzwqtDOrlkeRM6ADE
RJVIDoxTHQL0WkqYK+lIL9nAakAu8yBgYgGu8ZK8HOuBEqmqGR8SpOtlzhOLKOK9URFRZ+CF
wy8WOJ/TYg0tPWMNYDj/nB9Gq6nklt6rkJgXKmKiLSJ9XdaqSgWbuQRAcN9htAlfDqFgL6ph
R1AybrwoQCf/G3J3Ae8Wf4fR88UqaBGOjwaUoa1iLVSTOxeLHVLEk/YDUrvPu4VGi2LqWAdu
O10YWiC8J7NMb7wB5IfbNf3dhlPkqeN3EO2ff77hgPVJb/vdFuo9ZEIzCYguljPBWwDGKX9A
22HXliKmP9Tz27t1zdty53AqCeY3ey10c7EmAAKD7AMsctSSHXmiKy8h/IueS03F+0UhsIIM
XTsM+cwC8309m16si9HWSlVMp/P9WczNfLzXgNEa6kjHc6bjXfnpUvx4zz+ExDqXIPZmWlsA
wxjj+0qBU0/j8qGJrKokatHuXK+ZPqpkMZ2Ojl+5EPP59aebURBY9rQAP1RVYQa3RlCMkEyp
qbgWA37M9IaUcbwS10/IP1sRJocsr6L/mmDvtS4nVpFWoV+OT1/fJlqbxpgYf/58n/RBtCY/
7n91dt3772/Pkz+Pk6fj8evx6/9BO65d0/r4/QVyn09+QIrJx6e/nl3u2uIGn8EUj1zLs1Gt
L+lZXCgqEQta7bJxsd4VuRMEGydVyN3ZtWH634yAYKNUGJaM74cPY9RxG/a5TvFe4lmgSETN
BKu0YRDtnhXjbOBGlMw9axvV6ipwpTU4/z20ptbUy/nseni9FtaT/HH/N7iPEoERcasJg8XI
V0KJ1ps9p6q9a2Nu6wZ+XafH3N2SeT5K5Zz2OGmpM/oCLLKHsK6Y7OWmaVsV8eumlPn1yIgk
0SqvWFUHESOsLxnZ6LrPHhxugjltSTMwNFHyW1iI/mwsPa5CiX5+/PiBah7qrZC7EYujKJX+
a7vipzMTDgAZbQm+Mlu5LFkDGXYl34lSfw8eUXGps8xmDgYeJp49AA51yRxc4CT7gsO1n5Gz
uPj26+3x4f77JLn/BS5Mw2mMYYM1lJ/GKxGuiIuZebWagCPy6/H7/fsRHJL/er2HmJgP7z9f
HetxlhdGWAsiSUd3qXc0B0lTxnkzSgfejd3LtOCr54Xl0gG/jP2sk4RhfhND0QKjbd6kgokk
gxgTTVWpK27rQFRejZJBZ15595JPrateH//+27/fEmhhXsmlTLib2lL/P5NLQbrLR6E4WcrK
I3BFYLhvP/98+/X2fvxhX6nVyM4ZDMMjOlcTgcglrm6JkJOiSYNo8FyKLg+0gcQAUvybqLqs
gsYcE1sF3Vftzdm6cB1UORfEA+iDxpshgbsZhE89PKG/d3waCb8cApsSxZ5ru13e1DLC26V8
E8vtgGkYE2chsaVf3YjrhV6CWkL74dG8GoM0HwwWlIdqOlvQG5UFuWYO32zINb0hWJCbK5rR
dBBVbaY3laCjQ3eg9GpRnWkwQJjDGBtyTUtrJ4hK57MzLV7eXS0uxiFlcR0wh1IdZHt5wYRA
6gdvdnVxNZgRz0+/Q/ZU8sOHqehtAKcK+1JmKUCUnXAoiPUxpEPuqreByFxUXKQecCJr2DA+
YD5laKLej272zOnXNnYJ2KHto2Z+z9QWsJXgYsrGoGnJvtLamlceXp/fnv96n6x/vRxff99O
/v55fHunDsdMhoBBDfvjE3uGg/HITXjsntlAoQpKOOpq4+xbBGA00bYK1t4D/V2pvjD2njVZ
GynKIMGBRdN/lrUinOWAuMrgptbtD6esBE8gaCj0LOiJaifzKlm6znjwhP4w9n0vpzatU2+D
1DEHQDHsOQnjNqcq4QdX7p5czE+Wj4ZYRHAZDzKPcccYcf1ZVqr+CGTkHsa6MClX6NUiMqFy
8DQceQlEsdkUIuRDEnXuButQFJRzVBRFRfcKZwTAi2HHOEaDwbgS5WjLTDiqZlmNJTfBtwQp
k0yl5TdM7FMIll8yCSz3+fS6wQtI9KAYm/5Y+zvIHeOigfpJs0pdHc+9hKFeHp/QU27AuoNk
oxcvxky4tHxD4WcDjoXWzYNks0zCATJP01q3QfpFAyM03ItGElGEqXLdeX8ibak7HJp7l2ZC
2/cdzaZgXjHYK6CuMDJJJ8g8GDYwTvKiODQ7Jx6pLO/gcg9xW7I8/nh+P768Pj90Izz5R7TX
3EtC0nSR/NNxcqkiiJQf6UkDMt2wspcfb39/oB7YJKigQ/3CRY4Sl0yYgmgPMXk4vScvGdmf
2wBTSHbDNGSXDnoZd3kJCKN8FFKKxSlRjm6duc7awWPZbEXp3UhJkqZc0n6PYRAuBcWDwlTK
0JVh5EjkdhPeXS5jSPiT0Qr+Ks9Xen12jSfG4ftxMlCNwkAE66jZ5XClFPUxq7v7atZ4ypIp
avYQv5772AYhKX8ZTb1sYvcdl91q0Spk3uiGRKV9waF9xLzSawsSilzJvW48zRc7lIqC2o8I
1kOu/EZdca+8+tArr7hXuiBO7fzsXu3VP8egMw87Y8GQZGqJX9xRmyKpIsiGxsy+zwNSt+cg
wZFPdAmfh31/dugAwVyMABJvel/Fasa1f1mNdC6TycijXINPHxG2HnvqxDKJcD9zbrPFKssr
GVvOMaFfIE1BUyv3/kUsDIF4Ow50XwP+7LKWOBcxev4IpzQtUDMJNgigQXCzyFCrMnLqvovT
qtlOKTxSZl5LgyoZlvTp1U9aUpXHyl2eMdwbduddUBMxiYP7h2+uxhcrnPxDJGZn+QNSMAGb
HHBJrRp8ms8vnFZ8zhMZWS39okFuo+ow9uaV0UZz9Ucsqj+yin6ZpjkvSpV+winZ+hD43Ykc
YKsC7en26vKGoss8WEOkhur2t8e358Xi+tPv09+s9VAN1oqxyLwdf359nvxFtbhPhWMXbNpL
Xdbs06Xb1Pc5tal6CzTzwn0I+gPH85IO5+5ZsgYZ9kx6vXHOYzCDfa3TW+qVXldL+y1tEbbN
mYr4F8cy4Xo5Mgnd5ipKXVE05NmUiHlahLFAOeqaf1CTMB4Oxzcj/tHlSHN4klZbGUpQipRL
W3NXC7VmiNs9/7ZUZvqDM8Q8HRmXgqfdZfurUeqcp5ZjLy3gZJG5iXhQW+6xmptpeiOA4Mve
ZOuIsctR4LfNofG3E1vRlDD7IBKvfLjaMZfRDLyhDYhABAbf2uvDjOxcCzJ5LAHktD10fw27
EhJ98ehUZErY2K268afpuNUu3wFKK9VlEfi/m5Vr6G9LeQkHM5ySXzqQ3mYoYfBB0aUrAvIu
EhutLoFTFn1+jqi6CARjx0A6rwYgGTtDW5IN/QOvUClzkpcFBbcm9BYoeEbKrZfEnkOJ6jbM
299+vv+1+M2mdFtso7dYZ2LZtJtL+taRC7qhTfoOaHFNRcbwIDO2IdxNCQ/0gdYumMtdHohZ
1y6I+aguiD598UBMXnUX9JEhYHIieCD6gMUBfWKSN7ggJriZV9MHxunT1QfatGDi9ABIS64g
BzaLc9NsamIo0G/QREr6B4xQgZTu6ureOaWLB9O5I/BTokOc7yc/GToE//06BL9cOgT/UU59
P9+Z6fneMEkoALLJ5aJhovl2ZNpyBeRUBCCycHFFW0QQQYT8MxCtjNZcZNAOVOaikudedihl
wkXA6kArwQbJOkG08srES24RMgBnHSb0dYfJaibKljN85zpV1eVGKipfPSDqKl50bg6b4+vT
8fvk2/3Dv0we+U55wUgrsryLE7FSQ5M46v3m6r9lgmgVwjarNQjnJuvklSXLZ2D6RluBxhdl
FIgqIp0xDDCtVdVgnAFLOdWivanidnZxZcXUSwXkSNOyaUnbjVVVygKyA0NCNkb6zSBqH9CX
eUIaWvFSuysfrSNIjK5MO2m7LT6lTL5o0NlSuII6AjVyKC3XY+wMXU2ek8dRDr3ZiqSObi+s
QUjq1jG+4e4mA2Ig7nV9hZy7bRsxsKNwwhmboI1NGdQNhqcjI02Yx/WfNgOaPYVMWnQw4mPC
NctwcwqMYL5/W73zIRwK8WJoFqSXh4g/GK4lyuvqdm6NTrIJKyrEB1jR4LFg0wYh8lcEjktc
Z+YLI6jkqKtSaNH7I5i4QC+X0dc0KSY4p4DdPYUYgX4tztN6JeZ2XEiEgPVEmKwGWluAYVV+
JZoTOxf3oDBoazNVW3aUElJOrKzB678cvoKe75BhJIzQ2x2yZcARGs4Nevm0XR7LdSLg2G8E
IapcVzG/0gs2iVnXRMwojNlL5rz/ohIp3IHnFhJO6s0qXHojaMr1OuhYX29W0m9qNpqTVUyc
dmByAfoM0MFq4Ny+yzwI+X1r+zwKQlG1zN05prDKm3C5orXw7kDUTyVmdwwcQ5gVJHOTvKWp
DkXUXOwXF5ptMbQovJ3StBr/fTujqVmeRbeXAxq+zD4v7QmMo+8JUfMJZ04YeCvJBjsDqtXE
vs8Q/yWVX8AfMJGZMf+3cckefr4+vv+ybie1t83fWoq1kQtlriTjBXK1lnF1e3XTt3FVwk6j
IsqhEMJCOrMgQ7tghFdf2SiurZbemmw5YHeUpVdjpODEyEzbUewokTvoxKPxak9mNmrHv2+L
CIbSTEe9/e2ksu8h6wfYaixuaLiBG3bMlMEqLg5+6d5J+YlFxZ1fYpgLMFPr5h1+hLybDMHr
r5f358kD3Dx5fp18O35/Ob5aXhIIbkSycjwdnOLZsFwLNGThELpMNgHExi55yvAhMBKRhUNo
ma2GhQWc6gyLtWis5c5hS9pyNweMIcG+TlnAnAebUCqURoH5KqKWVTydLTh31RaT1ZxVqusT
k4CrpYPt9a6O6oh4P/5FSdHdp6urtV69xJOkD634+f7t+PT++IBu69HTA8wxiDqC+TfF29vz
wyOSwvv3e/s4rGsOc6+rG61xsoru5ND1b4leQD+ev9qux937llTXAs6S2JFJ06chRsGSqDEp
6TsIpy+4pJXElr5339g6Or19Y3q1TgXVrf2Zt2w911NzRPj49/HtfThwZXA5CwbrxRQPk+50
38+38XqLJrwarsDwmqhIC1lrgR6zoz0q01Avr3MIxpTYI2ZMrr0ecTmj7KLdtFyL6aBfUNgo
paJLijRzU//1hOspY8RuF+WqnH4aReyKM1XgN2qCRDOlJpPmUw5mRfD48s31qes4PcXkdCkK
j4x91EJRLxzgsnopR1agloCviEbobXcXS+6IwcV8oLWBgJxHTGQAD/Oh6lRFG89sQCO2+w9W
NjpjEcBU5iJD8oPGgx3HR2zW4ougBeBuMotECcYv34V8oMdsBIUTvSy4/I0uRK/JaPahNxr4
x75IFY1OlGqXn5uaLeQj73KQzSWXEcGD0x1pgyH9eHk9vr3pjZzYs7W4m3DRnlrIFy7iZLc9
fhn6/Jf3T1+ff0yynz/+PL6aPLH373QLRKZkExQl40JkCWyovvMHjR5QtWLoGHhNb+xaCk/T
CDQT0GRQP+MU283WCt4MDq6Y5RKD9NhLT8PIN23XuYIgCvTkXspMlK0CPgwYkTz++Xr/+mvy
+vzz/fHJuZqF+oOtVyylVs/B79ZSU9ogUaC5Z1pTgesJaec2RkCSKGOo4EoK/qK6J0vbdNfR
i0CCkcD2gO1IbLHLt7SGFciKlpKD6dwHV9OLUNJxgIAsq7ph6rr0lAVdQFqDXEAig2h5WBCP
Ggq34hEiyh2/AAGxZExemvr/2bva5rSRZb1fnV8xVfslKVmOJF6MOcne4s0J94LNAnZybyqV
EpLAOgGJlURin19/u2ckECCBEC8Ge1y7QQhpZtSa6Xme7pnuaOcRjFcG5eJui/LP4SjHfZKo
DeZWYv5fbN5I9tOPcuW/I0dH5wcNnBw2ceGpRftpBy1zIRhFgwt36p9uSt27MKtGA257rrdU
/w6t/Ltp+ItsgzEchIqZWvWwrfVrunyrW78Pldxo3/1YWswKg5sGeYgU4W27GoNdq9U5hfPH
yj/d6E0G74fuWDMvvEdv9cUp/yT4y2ez+Clf5qTwpyRlZUXK5v/A+KEZOStlspk/JDkjKfk/
iLSX1iz8TVxPdQj5w1M9R11x3brfT/RPkoqSdCGxsD89x9QHRpHULc8YwqztjG02Z5KvBvxT
y72v0DAjl6TarCvkrWP8ItLluzdnnWCncpFUjeEwCMEi5ZTCmzM/mFAR05qIpGmMRFKeuE0V
rndEGhiw8qQNDfrTl/rNvUgwAKRl22ORtFSn5uBVnjEem9YAjmrttkiu4e6yUhaBXrowMz2K
0AZ4QxO3SCrqWCD5fPPzf0RyV70OXRsUVsXwDY2PfThP/uqWerbjieTD9KDpH/zFqvrQoh9+
LSgax5mMvSKB9pASnfoMHWNs19t/EwkeVx2rPXNoeqYBrfl2JX0ntUcKf8jbX8o70rZhYLYw
8MXbztD2xHfnpNmpEwluPQO5we3Fs6b62FKfhraqE+SfvSfPcM9J60G1vOuJpRHpnDRUz7C0
J9KQXPIhn7Xg94ZMPsgTF8o5qz16XRWk1S7XBHLdaBugCUS/Am9YPGObzAk8iu2gzGzHMTQP
Y4iLNCHCteqpQxQd/biz/D2Pho6FnLWHj/qto4skqGbaMpGUJo+t3w6Wwl4hXh/9OHC2bah6
2/hndpY1EV5l8QzbRF/XnaUFh7Q9/klsEtw7q7GLiahbhkXb2LB+UklSQf8J8oJ+Bq9Juch9
6r6Hyr+YuvdAHrPnpNRpNakUG3JYquQD8NxAqlkm1QpaglpN6IQTZ+yYriGQRqOkeSBNgZR/
39ie4FeNMqYFQ/9Eqer/Iu1KmQA2po85PQ1vyAC9YloiguRRZfhT9F9f58nSHuBsUGVp4kGb
4T4YPV+gF9Iz7IjVSYXGnnJi/bTs39b0KeHxu0yAXVYXdjysi1Sx+eYvAwttDkZYqn8AhWJP
xSchcOtcD4Hv004i4Df/qNWsQXtqlgrtbnfuTdfEy4OS4HVEnMZm440giH/qVYJTwjl+Z8NZ
xEN8pzj2pwNEKVJKMTSobuqaIwMGYRER/8Ag5Ur1PDgH4hLgDXbb4jm5LV9fQ6/04OX5fZmU
2vXr3/psXMSUm5MmLg7wnDRyw0WLc0UHrzRUKusJUGpXdQaGB3DZ+sk6YnHWE2uoUWi1pmpp
hsguwOKxJ7BePTI9GC7OwLSK8AjOSB2S2zHlM9aAPbZfTtPWzb5p6OHyZsed2w4rdHYKVLVo
jMYPqmuCHhDzennam1AaE3jrlhe+iDSMX8aQXQqV/jNRh+Z/6CThi84Q50+DbnANmdW7dF6J
ujiDggVRhX+A3oE7tsUl/WqAfm3Zv4HiNVVLHRgjbC9ujsNXmIFar4fqwKVdjPX4Th3+keF/
haoO/xE/SqMSXvO2Kgnn8PM5/HxezTzAkIYPzR7qAsxz00mmKqGCs/te2/VovxdZBgYs3xh+
lOBDU4cGHOBvS43GFOK/5O/kHnq27bDguBiOu25hpAj6wDBdVj/CYFBgYPyCchqGBV818uG/
/louLptNWlyWFiez4jIxxemJW5cJFyepkcUphcTFsdYprDi5QIt7gxBFBoiCG/+TIxTcc4l3
BHPvbNqV1SlyIW/Hjj0QzT7oHfLNH1m6odm68f3dPHIREJ4IM+QiJEIuwgJyEZaQi3Ao5OJP
bUUED3Q7EY4xg3TM/4A8g4npzVkZWwKT2wh4/UfUxS6Iw9LpN+UcY9LYDmhjKIx9NzRxyEr+
CAgGM9f1jAfT0qevCjV6H/4XKdzv9/tvzkBctvO0eKGu0SskUdcu+316Ycsx+oanPdDkJqPI
uyT/T7/y7w6d8EvpBE9AXF/SvpDTyVcgH8LyBZHRptCZEgoyvSfBf9c3dr1Top0CukjwbhgW
m9YNSqXlmNAZtO4Iga6hTY/9A+wesy9QcM1a1ihZUIOrUfj89Xm4HmBn0c8cI8BYmoAWlN8r
oEfdn+xcPtszKRIo6ToOoiLpGwaopKsCoQ44Jv03CPBcXMU3fRsKIf6kPXtBO0fG6FU5JDIW
SAj0+B8hZCxsiYxDj3NAZCwHyLgQjYvnMfHEGpqARQzdF2n+cLhY2AEunsf+cgwqFqaoWPBR
sbAxKhanqFg8UVQsrEPF+dyIomJF3iUsLnBQzEHxbkCxzIoraRrOMD6Ww9SaLHoWzGqVDtWE
HUe7B5nqAutXZVQBINq2oZsA4CrwAj3/+G7seo6hjnB8kNoAp66K5wxxdkY9QG8X/ZJR1S2X
LG5X8hLwL7Bn1H9hv9VR64DopiEEoSl3NaoAq40WDKJqrQPaDg+vK/APbUD31j8o9RCf3FmP
9Bs09PEWMGhTHfbpHbVKu+LPLmxyqYDSsociraPp/kxchzCtQ1hdhxDUIbDn+OV4tBKBViJg
JQJWIgSVCPEPIgSVCKsepMKE1X6k00JZ1Wmr4LPawIO2PRzav9Bq6Ws7aiybTr20ACoJWoDg
FyAEBQjTAoSgACFcAD5mqdamffLadACDstfZsmnwQ4RS5+jIhAtAnHBQw+nx4Sf7/vAzChfu
msvlWHF/yle75nln/o4QP8qaaZGJC/h+rJm0Nwc8UN4dD+xxHpiOB8oLPFDeMQ8sBDywn4YH
yos8UOY8cD88sMd54EvhgQrngZwHch7IeSDngZwHch7IeeBx80Blh/5AhfsDU/LA7AIPzO6U
B8JPUya3OQ8M3x06twceKL56HqgfhAcKr4sHPs9KuUw0Dyw8Mw8U9rJObnE1YNw6OWH1OrnO
kNK3s5LnWWUPbgMhM9DWbDfgSjhdB1njafr52fZaw8lgJh76LFgX+TN3zgB7A+UKXfoCRsqX
f9H5zcFHxO5CuURQMUqQjdkiCTfgGhEPrR+UpltFFVMZ6RUKhD636g50B6QRlQfKHGdTm99a
ctvvn/st9o+xWUKoJawBTJy+Hp01AC+eNWFa87Qtc8WcVR6QpgHtCzdYoA3Eog3Otznf5nyb
823Otznf5nz7Wfi2sju+rXG+nY5vZxb4dmZjvt1f5XfV/RW0up7C78r59uH4dp/7XV+K3zV3
GL49g//H43ctcL/r4XngzPDCeSDngZwHch7IeSDngYl5YGaHfteMipWEf4OJwuDcMB03zC1w
wxz3xb5GbpiRT94XKxwfN3weX+xlNDeU89wZexhnbJ47Y7kzljtjOQnnJJyTcE7COQk/DhIO
OIR0KJkgoOppJHV1mISL+1QBesH4nNx39R9NIC7nQVkhLfkaIztGkLZlBsRmskcq64HjJ6nQ
x9g39xzGUeRhHGdhHCMCHFLiMj0fjuO4JNUlRiROGZG41l12EpEbV2LhOaAbj1nnLluHgzcL
kbgG/vLQiOkAsD85KOkmhyk2pNqWqEA1Pw3tHsiTTsAunxRe4KQg8EmBTwp8Unjhk4K8Pnxq
JS9J779eXhEXJg3DJdqDOQa9MueeuzcdD2oI+wLolJDbv69u/ZRwSr66/IKvLv8qfXVHGz/n
lML1P4vjCzPA7TUo6WVcvH55Rbz+3U7pz+j5Wh+QJn24/iPyyaSBHEn9Mjxk/xFBkEUdWzhF
x0yhsNkijqu4RRzydBGHGLuII7OwiCPGSXRSHo/Edaz2eIjLHo8VlTyDx2PjAvbi8cgUnsXv
J+zT75fANyLngeng1DyxMIc0KhSNPfsQJZmc98DUGEgN7gRIMuU6m5q/9sB1DmP+EsJc5w1g
0AEKTCoSn3aoHtH7hX4PNBR5m8+KoMrOiQVAYxxiG+/INxeY0Uc5/32pk+ZOch7Q5vS6GK/X
hbBelxb+5vS733PlvfRc5fX1XDFZz9V4z91Jz1VB5951yin7K9ypQJMeGJKheQiju+/MyKRI
5Fvtc6X+ff9dev0i8QRdWljs0iOY9yajrTr1mkSESia+3+u032eUNf3+fzbs90ryfp+5zKXu
+eLmPT8H2L2KiU4JAoUiKZfaH2Vi9/vQ/3CVR8T6Z7gDTZ9ThH1tQEschpyuKTfutqipRmBn
AK4U8SsF89dBu7utWNhiPGjmjwdNZ0NI24mBNhTbnI2a3gFMsy9rG8Xlgmn2kptmuWn2hEyz
O/C2ConyRSXPowqCXJ1FVdx2t/pRb0g4NbNssFR+x0lU97NS/sQNspmL3PGYZFNbK3OrrZVX
G25/U3cEMtOTqxQQ8yRNspsvQhdXm2RFvgh9ZpJNYq7ULi53ivsLHPenw/2FBdyv7TalkcHQ
uqj306S2LUjzuF8v9I8H9wsc978C3F+Ixv2r1mPkZMXaN/LfT5yqzRdkvKhIVRz5c+SfDPlf
cuTPkT9H/mmQv75Pp5nMnWapnGZKvNPM4E6zY3OaGWudZgWlILGEwYzIsGGhzrFjmXyD4QAg
kgK5A1PkZ1kPsYoH6ws8WJ/nwRnlRB1gG2uTo3SB5dYAKjos+jAsoEUpbEqNViU8jaRYN3RM
42QH80VERJmVgR1oKAcWieWNJBclCV5FzXtAXebNzfRlB6i8Zo/mXsuN4X31HJgfgIM1c5cw
YX8yB1C/NysDVJkR+zrkfq53mGVcx2bZWzOvZ3Ix8/qVrEpzi8Ci5vR8Fid1/35l4f7ehvdn
F+7Xkt5fexwDlcUi2rdNerOfJp18033m/N2/QcnlI2BItnDMa9bkGBCCI84EaE5ajq1PNI/S
TapN2dcbdWSEhtNsCC0OHTSXGKou2tbwiQDJH+puETn1t9bNd+yqHrEmox4dm5XmFY4++msT
fgV5TfoADwDKkHq1SDIyyUgko5BMgV5zP1MLrq8WANZc319eKBd+MfdyxCXVzr0sKYX7VrV9
cV9ryxf+tUrEtTet/1XYr5mIX1vNrsx+zUbd27yf0zfsylxUi7r1m3qF/Z6P+r3SBLoL/xX0
bE6RgyN6Q/v+O8FZz/mF5hkYqtpPF9TvwLYBQygZNlbfuu+I418Ed9UsPRJ3Ri5TLKRfphhl
aIA6xK9LZo9LWgnbC39vaB48vsfi+SH+zc7wL/vDnlguRfwoR1arLViyk4UJSBRMMxussshn
5w3Y0zCAS6EPw6bt2Y6qhAEEtjBtC1PTdtiwvj4Xww62Ha60cUvRNm4lydoWZc7CLexuy+Eh
MjGk3HCYwJhcSh5yccdmZL6X7yDm45dt/RRXWj+3Cr4n7MH6KcRsRduH9VNYsH4K8VvRNNpD
fJLSAcoJ4+eGgi1Cubx4JYk9WZQ1Uc6KkiIq2nIhfsg9BmDLEyC2dPBFxrzM+yH4/HAVGM/W
MoYoG3XsFs8ardp9BZBn2+iDjvsIPdhySavUhRHsPJVNz/2IWKrk9FAGj6iBv7TbGYV+AE7H
D1kp0JeFBiy8EqAszJAf6eUz8Au0BGAq3c5G4URFKvpNgNpuA6yAMxy+C9S5UDU06990cpzG
0VzfFNINDuAT5k56F2tcAG8w5CBZaCnpVt6DJNB8MmvzjTGwA4chmXuAxUiHGSZm2k40noGy
hqtxvyG+mc/QY3BKnFIz4BoUTo0wyL8b0vpANqFPwC0UYqCtj0Iz9jXOEugNMgHFljnFPjzF
Li9S7EIsxda3pNjGlhS7n55iX8mcYnOKzSk2p9icYnOKzSl2FMXmVJVT1ddLVZcnV05VOVWN
oKrKy/UGP8Milq28wdk4qipt6Q2WtvQGS9t4gyVOVTlV5VR1F1RV5FR1x1RVSEBVhZ1RVWEN
VRU4VX2VVJV7gznF5hT71Ci2wSk2p9iJKfbL9AYfOcVe8gbnYyn2lt5gaUtvsLSNN5hTbE6x
OcXmFJtTbE6xOcXm3mBOVTlVnaOqfU5VOVVNQlUzzBvcLtWrpDdx56hqA5BJwx6YGnlPOk+j
nmm7/vemMVDpLZ1ShyiKVCDfug8TSzecnj30vvsbtuWIDdvA8Srk86UstUjTtEzytk8fyLJB
Kg+m5r7SJI1rPMXZuXggGPcA372LZBCTR8zY34xuynN0U+8nTjIRoqyZhTIKUqIyfBa6zFv1
ON4KI2/TeCXxvBWwiyJE81ZxnreKPm8Vd5jcIl9IhfSz0lUCqB8THFA4Qqgv7h7q7zZL8zwQ
Lsyg/sGTOR4C6Bf2BvQTh+k7rCeN+9F2QU70OCvcHUsFTlyQ1hANO/bEgef1nsYGhbi/TTht
wetnYYxgineMi2WzSJzFZ4tMQIt1aLHr//MrLT5y2KijLFh85n7MRFVLaZ3Cad1R0LpDRuNL
TusMBv//lK+Wf9M2YGtXQTn55d+yfvrFIbTSUmlgsTY8HEJjgO8UdgJW8Zgb6m2pXUcoBB8M
n1zfV+hLAJVxYzx6BCd4FmBI8i/DOS58WXAF+QQIdkyvi6YfI6AQMBPpP1zVBR5SYDwkHEWt
bVgG/Ei6hvYA/MAePFEb9gXpfL68zNFw5QCkf5uAPsm3Vuc7z/2+HGi83umicp4MvSKFnvMR
1wpzEdeueORxdnCckceP14MXF7cxcUDfyMmdBfa9Wh3Y93IxJHuQwZWGZd9fOPakjEtEmE3f
XMNEmAk6TpK+JKJhG0RvD2iYsIqGLbCvvUVvT8a+IiKbR/KviTVEwWFedngJ029bE7Fji9u+
OftKk7V+HQXbLFs9X8vIHUSHZxLJk6y/XCaxNq73FYfTh4fTV3NwWl2A0709wWmjz+E0h9MJ
4XRvQzhdtX9bIUC9/zxHwn7zHB0EKSddkrQdUp4wCyxHy3tDy0nzCm2GmhOmFUqAnqGH0LUI
VOFHoVyOrTm2PiFsvbj46nixtcyx9bNia22/pur+5Ram6i1ygxwAW+89M8jrxdY6x9YnYoWW
TwNbixxbc2zNsfWRY2vhJLD1cditY/YklDRc8x5k/MINDrjRgWbrq3RojR1Hu4cep/u7uMqo
sEA+bUM3HV/C/nHgAAY1ANKkK+9xHT/iFpzT6O2CXzJq4+WSxS1KTsIf1HS2eTGUPfBbq1U+
BhJxbLvB15AIdY5E9LiBPmV6wRM00B9g5f8CidjLYtYlEgFK4T38L371VcMRLHnZ1yaDlbwC
Hh8UXr/tOU+L+wy2sd8L3H5/uhyDr3bhrOFYWcNprJs/Cov8G6nHEDMgD6JBp4QOhAgqvFW1
qcLhI6khZXdsy9Rc0qHbTqF/e/oF+aRIktFW5iEzKy8oZKN09M8IqHeejh7g89usRPdwj0yY
jwr+sfr4bps9q7IcE3rJh7azHPbR+1CbcXtZjWAva3B/or2s8+GbjMU2xJVRaEbtZP0wsVTX
NQeWof8V2s26vH1KW4Fj5UgcK+wWx4rrceybTL8oFWB8sRFDYCIyxw8wGw2jUnZ/NeCfWu49
nDOIeUn+btXZPCj5u74v58fRcgnBoGL4djFmmTgbVOJeBpW4N5ZKBXm1tSBlLkgUpJpWkGzA
BcakOwuX3XORMpHKOxMp76W+SJWdiVThImUizexMpBkuUhRpL60uncWeCcSKcArl4HLJMsmm
7KwdY6SOH/CLaumko8Fl2sNY1VHQfXMw8W/j4p4Tt5a2I4M20LDSQJ4cEgQCTQkJuEDjBJoS
EHCBxgk0n37uGsBvhh4w/8rU2BOU6HthQIToNuUyn8r8MuWsFi1WLlQQqs7nrl0LlM9dOxYo
n7t2LNADzl3cIkNlbqS2G7LQq7ZDPtsjg5QGaKyPFOlq39ALkaJMWobTR+c0upU1XMti4CKO
lIIMF9a0LdOzacTa1yrf/jYWmVjNcGrWgj2uGIxYUTZbOCW/I23b9vxVIY9hoSYL17rNQiq6
XEpMvVzK3/YghpdLiaHlUmKCmKxbL5HabTCg6VIofwGRtGKJ1I4Dsu5390XEg0WujBJXrYzy
9UVKrLtaX5Q6XGdwncF1xgvVGSnp3Eqd4a99PFXLGVcfXH1w9ZFMfaR0baZRH6divODqg6sP
rj6SqY/s4dTHqSyd4uqDqw+uPpKpj9zh1MepLBPk6oOrD64+kqmPfXheY9RH9iDqQzhyn5Ys
7cWn5ScfJZKYIV0oEjfLBouRudGJ622ut1+Q3gYdsg8/1yodwi1PXIdwHfKydMg+/F4wYG7b
IW85xx5cb3C98bL0xj4cXot6g+MNrje43nhZemMfnq5VnIW7u7gO4TrkZemQfbi7VukQ7vPi
OoTrkJelQ/bh81rkLxx7cL3B9cbL0hspoz1spDc43uB6g+uNl6Q35LTrParVdv2Wr5lBGWbS
yrCt0KSSp6FT9y7E9MEK2hiFwLNpOp5AGUfEKnitgQpAttnUsv17YoJ+UkHL4LWOZlsWzB1+
QAgq+DWbj1+FfHNb990YOfthuXlvDks7JUVOImqZi9oXdVZazpGcgE4AKAirYQqHKSyT1akY
9571TFgQo3D8qZPDSc6yUjjJWVaeT3JGv+8uyVk41zHPlOyIGyc5W60S5q/PxyUpVqb5xQSW
XwxbOM0vRpMTS5mF5MRneAv08enbUAhBRhQ+tZx+7Gox/dhsiNLsxcKa7MVKLr8dRd1f9uLT
oajT7MWFuaxbBZ+gNuQVKcU+yPkYgipMCarACKoQT1DblfJU/UxPCwfJXxzHVtfkFvt/9q7+
OW0e+ffX8Ffovp25630TiCS/c0+emwSSNndNm4Okz810MozwCzAFm7FNXu6vv13ZEGOThNCk
16SinRZk7Wq1Wn12V5at7jiVGlwcYQdKzg7vPOl8XHGg3YcoPR3PBoX8HfuCbUn9yzfNf0S9
gkk3YKb88bcsHsAuornIRZx5w6jBbM42SVGAIzzJSbYPoJm0EWJaE68lD3j6cHocgzlgXNEa
DmTrC9eWS0s+B8FOLnH+HcXaLkiSCZCpM8fRWwGw8q0Ii5YXsiyx2cJbiQM86Kwo8LYUEFlL
BSEaSEyFAVpaKILfhbUi+JV/Oz05hFZAN9B+p/tllODBTgtOMGArirE3SIintB63JVbt4O+s
g5JnDmT1BQjdcQCcPGmNHLTaxdPfth88tHp7gT138DWNiTxYjrOnPLXaVufLPcH5cv6THy26
vXwk03Z+JNP2Ex4tOj8U7wsYNqQUGMbCsLkwRWW6gR2GiLe9J/14x78EPh/9EH665Le//15l
x/435y7Xa8947nK5j7r9is8R3H7s6ePrnyN4R0dezOnj9dI5gvU7Tx/31p5UmpxULJ9UYuWk
4vlh5m+ZU71mr92ULpviWVPMzpp66ExxzLf5E+bbXOXbG+bbvJRvc5Vv/5L5tqHy7deSb2ur
821mqoT7xyTcukq4VcKtEm6VcKuEWyXcKuFWCffPkXBrT5hwawIbKV4DR+GrJHyzJFwrJeGa
SsJ/ySTcevFJ+LZKwrMk3FI3vf+nObimcnCVg6scXOXgKgdXObjKwVUO/rPk4PzpcnBX5dub
5dt6Kd/WVb79S+bbzovPt9VN7zzfdn5Mvn3PU9C/dr7NVb6t8m2Vb6t8W+XbKt9W+bbKt3+O
fNvY9HUl8yOTTsR0h3w583onkLfszHkVUPKnfVz+f/VeKK7eC/UT5EPqvVBrvRfqgVh4KdC9
O2ZdqvZQHGzQmYyDjbXC4AfC30UmqALgRwXAuXPY8NyVRWwo0ZYISDXfj6M+6FM64J/45UDK
KWzsFLaVU1BOQTmF1+wUrKBJ7U0zhn+dHs/fYPbLv+QQFel8tyJfyslDz6xIsakisxW9ebBy
HsJMV7aZq3TDUztXqFRZaa7SDYPpFSp9Ka/sf3aVbni+2wqVvpS3mT+zSvvfc+R3HM+m6UKt
D7wK9tfT7IbG2vUnYjrEH5hHd12o5g6nkCOBioLRYJaTKXUvqdvd1JABDVxsdK5PFRLMFbph
SKAUepdCNwwIlELvUuhzHJeUc5zf72rLTaNK5wudb3jUzB1qVUoFpXrKdz21QpXvemKFKt/1
xAr9gb5LrchInfsbrxvGEW6Bi2LyIZr4+fEnP+0tzWfX4uZn9axU5IozN/BWy6+q3+B7VmTu
RIaXtlqgDvFTm7XUffmHDvHL8GLDWPd+vNjvKsxQmKEw45Vixobp3L2Yke+8eakrZwo+FHwo
+FgPPja8tbkJfLyUxQsFHwo+FHysBx/6j4OPl7J1SsGHgg8FH+vBh/Hj4OOlbBNU8KHgQ8HH
evDxHHde74AP/YfAx/ZPfk+L0We5p4UvG8IXHtC6Rs6AJT6qNd+MrBadFG4r3H5FuA0Y8hz3
ue7DELXypDBEYcjrwpDnuO8FE+Zzp3C3XMUeCjcUbrwu3HiOG15l3FDxhsINhRuvCzee407X
fTmLut2lMERhyOvCkOe43XUfhqh7XgpDFIa8Lgx5jnte5fxFxR4KNxRuvC7c2PBtD4/CDRVv
KNxQuPGacINtut+j3e4cf1Z7ZlCH2qY67PDT1rH/QjD12ZW4+csKOvgWgjRaOmx0xbsKftUX
FYBu9Y11+6/ZCPBJAMpg3diNwhB8R/5CCKn4Bx4+/iX0a3y37d6h5/y13Mqai9reMEVeR9VM
qTpX9Rv1eaUfz+/PBruDeNZvgO0Hz9IGRimmruP/zDJo8X95OrHJzTeMM6bBH51bbyjjlqm9
IfRZpCl9ZkkqYkLewDyKxT31Hrr+Qj9vydlwlBD4K0giMFMlC2MggH14Gh25GgE+vvfDb/Ko
uh2EWpIOfSxKo4hACuj1o+hb7S0Zpum0ubt7dXXVGMiLjSge7HqRu+uHu/N6iy/1a9tsXE/G
f5+KON1jf3aHYrrH6Fuo38PvHDgeB+QmmhEBsB1CNj1LELgXssiXLeP1EFOhoT+eEjf2s1M/
UuxYMBr7O1gDWCXDaDb2wCNDBjlOZQ/mkjTI/hiAORSYH41vdpYqLRTSyDWUDkUK/FBvoTue
edC0VJHUCVQm0IEZHqsnfU+jVvP8QCA3WkuzM1GIUUvAX4kxqddn4Ff2GHxJMJ/bY8zglMLP
qyj29mz4MpWnmO+FEdZJI1BRDWSdjEJJnnMEvZGcJcoejf0aNJaCtP/2Q6I3ONkl41E4u65r
Dath1Ici9vzQ92oxLlK8G3p0h/619jZX6+61HzYG/4GOTGhv4k/29Pc7E3Hd1N/nReK6d+lO
Z8menhXIHz1wVrW3k8ibQbO7q1oj2Nrerudf7iaeMJ+gvXlv99L0hi5+uNGEE/wnV+eOHbLa
07WFnHcuB6LSxCP6vlrw4aVL7x443tCsBb96zJcH7/vHrix+ub3y8C0JyhaC8obZ0Ow6yLGm
gOAFTh4p3G0bFaHeZlKttPa3q809jIBR/VEWuzbJ6oGGH122k5kOiEwuR5NmkO4hzDR/YLyV
+X83FsmwBygynaWN9Dp92jbu9/8cPX/u/3VGGdRjus6p8v8/4nP86fisSbrgvtxhnhLFs3Cc
nWBl1vLL2ZnrZJq9CNJPpKc7O+yckGQ0ADdUI/8PyUokkxUyjlws+Uqib+Ri6crl6Hrk190Y
UrFGo7FURVxihRjccTQBPwaTqFSj7QtcvMxcu/C8EbpWcHbJlZiSZCog8SrznDebJMMKu3MI
a6JA9iOapgm5BB+Li7To1D1/GvuuXKnH8OJqBLld30eq2J9El1AMrgApg1k6i/0GXjkd+wJY
YrTkX4Ol9MAzQN7oJTv5bzQz4LgoJxBbza+AnIUrjSXhEVvdfIuHJ6D9qu6gKtYEOMrBxbun
JlaF4juVFabTirIWF6EJkDZ+sAESxtPKeJyHE1wLkZf9FKKbbzI6y1Lo5E5WE4iPwnoYeXcP
cCBGY94Xd4vTF+5sLGRzD0kO4oyjQR2+lWoc4PtNsYYXXYVgARCCBWh1/ZjiZQIWmsAo3cj2
4pE3kJfW5hKFXs6ng0YmRRmLS5hrQQxTQl7PmGEdQvx0SPEfRl6kWQej2L8SIMGa+hlHJRMa
R9EUupQdar98qWBVmbYK13b76P9LjS7X8EQqdj1q0crgLdcD3d4LUhKZcgkr5jacpemim6j0
j9FgBLhJvkRjSB3yo7njrNVF7TbW/vglIX8mX97nTOW9JBxQnAXzTCTJjnTFx5kJx0qfIpLM
3CHJR6NByFl8Q/6CGdNf5MgcSWqU8U9/ymQ8GoWjZAgcHyPsYoAhK7qs9NrP+GCgdIUZnYs3
vPKcDvlmo5YXfz0/a12UWZxliY9kA2YrQMYlx1Sq/k8w8jWr5i4IZgl4O3kn0BXusAI6ODtz
C7hlWsQxSD+9ehSOb25na4FmV14nt9fnnPP/vxJiMt6wdMc0zQuglBMsBybg38hq2A3N1Jlp
XOAU0ZryRhD5+pZdkO7JKSnU0RzgciIj5wQj4m9ymjclngDXQk3DoRekdXpOaJHeNOwLcjry
msRxHHtH2k8T+iCn0ZnACQrX3pP88wf+U4qG3+rZ8uhx6DayM70OERw7FqfX3i798seZQwst
2hT7fXzaJD7VaPPrb0H+sRnlwnb03y8IWVmaZe+QQmAo4/f8iR8PcCB7cabFbXpt6bv0mhvF
9hwD2+vK9ni/KXnalGlmXzM8YRNyePRx/3030zGlunlLazANdNbZ//f84u2HdA4Kpbms0OkW
lN6KbnHhFTtvaBTU3WmvZNg9XlXaPi4yFJ7tem6BoW5bwPDgtELKSIfaqxhSp1paYGiaGjBk
tFTJ8DwoZasYMl4qdQOnwNA2UUKmVfUCpXqZoQlyM+M+CU2qw7Q4ggGTlaxA49RgAeL5Oyz4
K4HBXIyyZ0ry/Mq3cAwX7+GtMRC2hbzBODXSzs2CHM6/tDoFzdigFwr1Cgx02wEGnVwlViBM
xwr6mqchqbYgZZoB8zFjuKwDnUMPCwyB5QVpd8rjgaTtzqrxaHfK47HcRVtzkKG2ktRctmn4
B0utUl29yNCCzlzM3yE/R45301tISYcIiaMwiMhiWCwRaH2HwkWRfFsutmxI3G+5cxtmTDcV
7rdmoVS3+QUpd8C5HRgGRqIxo9rFxTfGNd0wrVueMJiswJPbkLI6plNiwfk9PCvKtg1uFeXM
G12zkcy0OdW4bt/ydKiFJoax1VkMoVNBLQ4gXxU8heMBeP69DJ+3oMkBpa/1gtiOzo0VfPqO
5FNl4AA9K9Ibjl2mN5xAMyV9tsBSINdMoC9itmNZrEIvmB5IenCUvczMgJb5ASI+L1I7ell6
06eebUjqXiyuegmEMD0MQoCDsSw8mDNiwBI549S1MuG96Uw266DMXC/SSUtdpqMiYDRrthfk
lCYtCWxRvUJJTc/1mKQcD3oy457LyxjSF8klZJcEtq1+1t9JiIs+vTDq+ddTCMpxvGWXrSIL
W1slQVCSYBbeJQOjzKww4IbmSgY4yXuYEPbiWQjkwgXyoEjO7LLOoX2PaVUN9NzpDCXQyhJo
CJSlUbdsx5IsII7pZUsZSMtl/wu0hraC1vDp3N4gMOuBAOMe3l2dinSIXGzk4hW4WBSdB4Tk
TWLbAGr4lwaEBURHkCC2R3ROnIDYGglswjRiWfgFqnGduAbp20S4xOLEZkR3ie0QPyC+DThK
HIMEHtY0TQKe0wUMMYjuEUcQx0bmZp9IKMK/rkt+64vfl8r8PvEM4ppIF5h4SWRXoSldNsWJ
7xKd4Xdgf9svk1tURmxPGJZZ6MZB5RCXkd/KIdnvhWqWA2BXr9e/EojaSRrLXFpoliMs1tcd
h3m8Ty6gQoHGQXnDKPXngexXdEQXkLeO0nkCBamyP5mmPbl9g7BbaovjVDg4f98kCaQHEFhj
cH41xKUFkUaTkTvnuotcJXhk2F7goaNLXCMqtywL1bBu/N2+I/4u8LMte7VzALeqO2Uj98zA
83J8ynvr9/qzAQyZjpNEDwr0MJ2rsAoRQokeIVUgKJtFdLR1jZdneOD2aYaqIG/k9qaQZCY9
dxbHfohW00eMhRC8wMVkFccAEbvJchkQ23Ge+n4vEWCT137Ym6Z+7zKb94hazC+ws5yKUIDj
jpmzc2G40IqxZxK6S5hjO2YZNkElnIqMvkTOxbKbtRymV5r3ufB9ST4LJ2Law9QZxuRyInBM
+j6wsPwiDwgRKjw0mFwFHkCcIDVOQqdIqztl2KO+YDwbUZwtvQnQ4/zF8WTF+euYVqVdnTtW
7nQmmbOTnsYtktlWpUkdJrEoNomqpqI09hhrV7Sli3lPPfRvI+lgJdg4vEjKeQXfPdOlfUk6
jWGWoVfTsZeGXqDTnEocpPc5Y/MmB3E0m84b1tG8+sVmDbMy43zO3KyzUTRNegBq6A/Fsj+0
qaWX3anpM6/vzRvGVQEgtDFy84uETsUPA6EeZCaF0yGnZGhJRfUyalc8+BzhK7HjWhhvM63q
1YGlba3L0rQqLOV6xXdHuDazq3D0iAjX5pRW7PgREa7NmVWxrLUjXBuziM0jXADyipGsE+Ha
HPKZjSJcm9tOBS3Wj3BtjZrVkPxRES4Mt74iwlw/wrU1SMw3j3BtzXDKWPDICNfWqlnRuhEu
5Px61Xk/NsK1deaw74yNIA7AOH2N2MjWTVzbfLLYyNZti6+OjWyD6mX7fExsBGk+WzEh14yN
bENzKrb5iDDENoyKL35EGGIbVsU2Hjc1DIdVs0duGM7KqeE6palhMl4J6nTR13nJsZt9Xnbs
Jq9EMGs5dlz3/g7HDgn3ho7dtFk101zHsZuOXW1yLcduscrywPc6djCYp3bsllWN7jZx7BDR
rwoQ1nXsDmWsoq1HOHZnxSrQ+o7dobq9Yiav69gdalZiuHUcu0Nto0K3lmN3QLnfsXTlMFbx
io907A7TrIrhPAa9HGbolVBufcfuMKsyox/p2AE9K3Hyuo4d0NBYQbumY892/4QRmeBTE7d3
Tsd+kGabBUbJYruQekjgJX6y/X/eZOTJd58//ea/Nw/s/4MI0NDn+/91qmvGG1zp07ja//cj
Pm/JYuwJbzBW654cHH/uwncL10ATP0wbNcchSRrPXNwWlJDIdWdTuc3J1A0te3q7UTuT24xE
Suj1wZHOWzC0jVrtgwg9KKbX7X1Kd0j75JikN1NoikG8zlj+6PfnwxPc/O6OgpFLzuB6beuD
L/BN/LivpS1S0cTHw/cJPcAlafhygHfACLMIp4QeEobr1IXW0LAKrcF3rudtyd4dh/KxLtxC
WNv6ArFYFDdvNylgUZzAtSZhDa1h1rY6frYPCkTxm4Q6u+AlOGW8tpUfHQCF10fy3t5WB3d6
THzSHf0H6po6+XYAhZ9P8gKbOVwWtSAJEW7qx6MkHbkJ9vC4u48btRaP3EMRPsZaLvp0Wi6S
nYKy2XQQg95wKOalyVB40RWOFj7jMR5HVxkF5khyZ1mrXebWhd5mrwQgMpUqXT5sVyj+IaYi
BGMhwTiaTm/kgyNnUTIc9QWokJOTgyUK8m6Ei+ra8K9AazS48X+7mklBK3P6xI+zbVO4Seg+
spz5+mRaA6gs/sjGbKrDoPk3/QgSx3sJHFm/mz2IcS9nXdZsvd/fnUTgYi9hFkb3U1BJsd86
rZjEefcAnPJAuDcrLUOO4nyCZc9DlqrhGxxkOXSyPgpH6UjuE5zv01xlBtnZGb58nibFB4A9
MOR41J+t4n9+eFQWWkrW8S9Hi5lWnMBsaQIzmMBWPoHzxz2XpvCJCGeBkPi0PJFP48gD3CKf
xATmXnnzUWGif4IOdjMNoXD5AH6aTfrI0Wl9OH1v/KO2dX5+3G4SvQV/ICysU/BXdR0iurpN
DVo/cFpUP9ItzdD3a1t/iG9+fTaVgJa3nW+0Bv7/PF8wh+970DyIijbg/e0EsHiMAu9V5T0S
k9H4pixuQW98GWZ3iDPHPcSvA2m/m6gu36Z1q7B9yitqajRanywK+SS3P1NqnQOXfQgYcTFm
cI/M2pLMGow1z4UGjEwSMJv1JM4U3RHuN3Iib9vl5LWtjxBdwxBk/uzxo35nJySM4hjjY7jQ
dlcEALz5UIOpj2+Wr8zf2bdU2PXdGT7gRebP8p5nb/SobYFfLHa9mXu2zM988EeDYdoknJzX
tjKRyecgt7NWFHuSU3IrKz6RLEa46nU49vHpNPRay6Z45xDpS0Ok7+Ad62yI8o09APhLg9QF
jYPO2r5MTTLpW6fnbD5KLWg/Bk0syG9tGx/VLo+yfKC7toWTr20RahIqA4CjI3J0QA4PyMER
NClbgvpNOeXQ62csiblD5KQiurGzeKiaWNDkWAyk5z06PSfvjsaR3Fhaly/nIfhcHonCujsc
TRF4v5wckndfRnE6A7knGDD51wB8aEl4uQ1X2xhNy+3LS5dOu3DtVMA8TiAGWL521m2Rd2cY
MPy3vWPtbRtH3tf0V/BjFmi6IkU9HBwOp5fb3MZJECfZHg6Hwk3dNNisHdjOXrvYH3/zICVS
dtJ6Y/R8toXA0QwpkfMmKWoEA9Ff722+ACzq9c/FPne8Hh1NbIIFum+G9/30ZUqbcQfmK0be
7XsFVOnxsoa4/jQE2xh+vh7ez0x58TYV+0Xv7G3x5nUKczoe56EHr101BZ2zI+jmKTNDEFRv
4vUq9qszYCS+Y2738sKYgzpycY7UcFop0qLJYAQc8Ql6bRl1czd+DzQNRzgMYUKyNiGDCUCz
IekI0dI7vQJicJ3YvByC29ofJ+osuzCtDWYcuYZiZtsDmR2EsdgP44P3oAf3i6VXHHf7b6DN
4+7xJZw82lTZN8oh6P2JOo7v069Xtdd7C4TCD1D2aTS+G9988St036JewG92VdEAGU4vTs/d
xqctoaD+9WeTIZgD6Gb/qFc2ZExNDfVEFaG4ElQZ3n08mGKaAsS8uQAO9h7uZrcHdhffDSl1
D3Ta+LpfTd4En/U5Ctq8VvQervzFiBpLa/dsDjL+/fMfyDPgf9ylXEUHKsZ9M+LvMFmJgtdv
focrx3czENQhDTqvXmBqJXyp944zKx2KBN+s7WHN3uAzJ4Y6FDD0NMiCtxbYAhXZAuuZz8b3
D3c4MnopKu4uDAl4zH0o/np6eSFOu6J/VhV/g5gjRUEbyNmLkvNO0HEfq0UF4BmPw0UF82G2
FYMej05ng8nssasoEUaBzgbf82LQ0ESIC5KnrYFTnQUTlliTcVxjHjSacrAu4M1QO6yH4Hvh
1OEzxDqwMvD6aLcUKfaq0SdMsPFBGN96+7uJIRxIf3STcJisGn5okisJTWoXmnahaReadqHp
/z40HX1AX7xcXAofi0v6sbgU7eLSk3Ep8aZMyUsh7VScmfnVmDTHmNHH25uHiSk1PHnJ1ehy
hI7xUYyAwcTp/ZCrgoB6tOf4Z5hkEs3jh5tPNCc2t6LMV/gW994R2Cluj/xgFivtWiWo5O2v
D7+2sP16fap/nvUoshH36/mrcztbwZndGlWu4QpTktqEpOimuH6fdjiSPKuigMvYeXMhrg2T
po2vb/EZMEyjD0V68J/BF3zZ8GBQFwx90cj/mWjUqkQTQQhYIBuLXgPhXI4aT7CkfNT/TD7h
4/LJB9e/fLtwgkekE6y7ePx44Ykl3Hm0dfVoeufR1tqjRTuPtn4eLfXGaGnztISShxecDLS9
fmCZJM6HH4cwKIfhnxXVeH48W9du7sadPRmPhs404Jtu1kwaWjcr8wMZiY9DmNXQAwjoPRdc
0WNFRPh0yy2lW20G3dk1vU2dP0zF/mU//8GjHRA+0eE2Eq23kWg3ykgVN2QfjSgzzdCvHi9X
PVk5S49OLt4hEY8zc57+FTGWpfQUM9PluNNZrnq2XPV8uerFctXL5apXm2Fb5/840JGnAydm
w8t84OhuHclyQ8ZGy5C8IcOiZUjekBERjAQ7Ym4YaFaoCSPjKAoy+h4T0IHrwg4fOt5MAFy5
bO03w6/o+Fzw5mdnxVG9t+Vz2l5zt6v3l1N6BJD9Nri945Xp4+HoZvbpUByPRzcLl7LDV6G4
wq1z92Z/GK4/9yqTeNPfU+fRI59Lj1ovetRz6QnXi57wufTomh4ZrwNB+rkEResloOi59MRr
JqC50X5N0qJRXu7vwAV3EjXb9UV/hok6p/j8EU+ENDsxmTk1Wh2K6F+4X/Hfzq2Tyr81dyV4
oi9F64KmL0YY3nqYOKU9BFNc9yIYOndydZ713hXH54dCFHfDAX3YYCKmwxlvdKdy3HU9mNKD
a3x0abL2N/cBas5+Pi/fVSd0l/F0iPmS+emwuB9Mp5iy3+136ffb3dpK25+PB6ObB3x87+lR
jQWFup7ccttdKrdqYdbSqGFbfXqIq+R7w9Efl/0/bqfjNI06B7JWtbsvolmBs9ccinb1pvfS
f4lCgpRUaEcHdmeH2TWRTSaDL+5KopELbzg+nYjeePZpOKH98y/2LqfDugbf4NH1Pn5wWy/3
2cVH/PLiNa3tJXEqXuf2eoeP9dNqHEGc1abS7JTlz/UA15R2qW7tPIc5b2jfHTHE8oUv9oho
56G4pH2539qRizHIgj/ah0//BdAImobL/xYZa4M0S61xmGrRA1pRF0R3cE0DpPKo18NH8TMS
P0nAot9lUrzYywejX0SNb42nzOCpPDfREYibgStC8YyuP03GozFMvO1XvfBNhPzhIw7TcDOE
WbKVYRjanQvuxqggKKpA5yH+n9srkCZVJ8y6kbdNIFBSafhp7RDohZ0wV6+TIH8THPzzTUcA
UedA1CE+erCWD32jnRSi3StPtHJzRKvWXLT6O4tWbY5ow/UWbRl8Z9GGmyNavd6iLbrfWbR6
PUV7MjYpaJox0+NSVnNSjlYh5flnor443WNOnE2BI84G6Ylz/rDirFt+TKi2gifTaCNlGm+1
TOONlGmy1TJNNlKm6VbLNN0AmYZzMu1stUw7GylTGWyzTLPNlKncZpnmmylTtc0yLdZTpl9f
etBtQebrvhYcf+elh3JzRLvua8Hfe8Gw2hzRrvlasE6+s2i7myPa9V4L7hTf+eGcXNPnrkuN
n6I5KW/1WrBc0weuz5TpVq8FyzV90vpMmW71WrBc00esz5TpVq8Fy014thrPyXSr14LlJjxb
nZfpVq8Fy014trpAptu8Fiw34dnqAplu8Vqwn6VYdkCm0pcpy7I3uL+H25nE8JSga4Kp+4ST
Kt79GPRexanG/OK8ywf1+MZmkw9pq3O9+Xqx8iAPKMuc1QHlkyFXSIZ8kgwVhAvJkCp6NiHK
350eKud7AvXm8/YbGjZZGpjBEE1sKj4MMeGX96aEiv0745cKUvtywhmg2XYXvBL3Eb8+yybw
U9EX+z/ZjPEmPZjoz75QCr++l4u9TiqnXgHVR6oQ/bvBb0OXlRggT67g+vGEXwzAHlhvYLJa
U4bvxUoWBEWWiv2jH09/wI8Z8IIR6PrgGkQGaqVoh30+fhh9GExugU6mZ/JwD/cf3w0mtNU+
o/cyxJtbzOjSVLiY3N7cDCcmsQimK3dLrTEOXA77b9tp6X4LYsQssw5y/q3AOlPJzYSS1J8c
FUIuMHZj8SyPCl8/GA1njQ7UCVzJT5E7HCFPMWw9TB1GwnEYyMMgAOl4NMjV0qBWR4N6nAbp
06BWS0O4OhrChTSoBXIIV0uDXh0N+nEaWnLQz6ThW4/HaShvp4uJiPyeRuvb09jvaby+PU38
nibr29PU7+lcToy6qwve24P6ndXZ5nl2VH6Vsn7Wt9H2bjj5sxYaLvAy2TMpqSAOfvhA6UQx
NdFXKaFqf5aA9wsImMsg8hXRzaUQeap+3n5tDnOc2Xcdv+37TrkUQYGps/EkMGm0/T/3g1L+
+E+hZsp4uQ9KBfThqECUtrVuhb8qFUH0dOOtz6zgo6slqS2VoRZOutBgKAJNv7FIAzp3/W6h
WrMPiBdpslSDhRJRgg3CSUIkJdLQBlxQpVCV0PxZLQmMgCsCKXRYIxpWANjp0pe3HBAH7Hsx
1JJNeVw2IFSEiYbmm9FnvEIYpew1CC06pW2sRHl0KgcM6jZUTJ2RIqPWDUhS0wSW1LbqMIis
7tqE7N1FwgTeyjZvVbScNIGn3QI71WZuiL2IMmRFTBVABt0CmQvsyWsEnsSZAyrUp4BEVhnC
gRM1QlrmR7lhngdC8wkLMNJ0O0CkogGlSDoOCH3GtvGrWowIRcgd16Jg0ekGhLbDiEGknLgd
xk15CELLDMh9k3kNMuWysAjQyFTI0gEDVDoEU5YkKolqEChpCzIjVNiAWFpiG8CoyOgJ6HUD
gr2lxKhIJF20tLLD3GVEQN3A6rFpDG3GgkCoLhlEf0XlujLlAGqyI+RrbO6uqhpkyhWZOoiJ
GwMtrUGsnhmwVva8QaBSFw2oSeAF9JDkG+ClKA/QK+IiuLCUrDeJjXKkmjXDGkHEV4B2sorg
twtCYUCJ5tqAoIwJg5jmne4bpLacfNdT9qXa9rW8eYUklifMK1R1d5DV0LmOQbAKy6ABUYXD
BlTWvAgRcnXVgJoMoAZTdCbIhsfIDVfkTkKil3xyEpq2kN5SRJUow6Z1UvhSO2ET/EcokgL1
jY0K6GnAlJWxwxrFd5EElrYZckbaqrXOTTwgRB0JdAe/eQE3xW8zMtgEBjTcjrFwt7p7deLd
DK5gO4jIyvDq1KveZSfWrUuZ8jhwqociVg6oRUlmH4fsDup4YBAUMpBCZd1F4oBG0ng75ZAS
WpD4xqDxyoqNihFYniPfAeRWwUxrEBlVMMjuBE26NOUemzMv/hLI8mgQpV9eNuMnBHOjJS5C
O+WJf7UhlK/Q2m9dG0Y1YNM2Uq791nPrXVywvhr1yvgXtzx80p3oFdmXfsq+uuT4dc6uG20+
rRHGxFBPbJwIZAOSP0GvQzjmRhk4YGCYoCMj525p7CsyBmc6Y6OUC8JJhkMB5HVkwn3GKh8Z
wZbEX22HRqViEHlNokPvScbM1ZEFNci8YDBhT5roGmFYhKAdiGjZgKQBVW4QTGqVOaAix0us
C0jLaBRYIySNEmuwHmMyGDpaRgj4jSvndqQ/CCZGKrpgkK1eURRA+0oMX8Hp1yBG04iqp/TR
HtT9Iq4R2EaRG5DvXhQNyDInRkV2IoG3q0Hwrx0aKhSGjR3jvQwiFVlly1mmpQNqkccsc0Bw
SMoTU84hKU8bELlOjWn0d1VixYAIUVFjT9lXtCL7ip6yryqv+4PRFzpYGgSbRFU1oOZhG4Bd
Dgkoz46DkBSBahDMrXBAMAgzKDSIkIICgcycsuuAMJIMjH0RQgJCmnLJfVMNCNOQilUadUaS
llW6KYe+V1EDQqyq4ho0nkUZpe02Md2C4E21U4o6040cRIHDNtZh4zmSBqRYhZRDULR85Wlm
LD1H05Qa+6rLJY2iYJRrRlFZA4LMZM5gPRGQlSlnUmThgDTQtyD2ShM7CcGtq6ABzWA6RI7l
djhcNQjsG43hoIemMe2AGiYpTLlBQOuRKTekxA0oaQpDvGJEM7vtGINyQd2AmJDLddG56cxT
9hXPTeWXNi8wSJD7E+bldIdZ7fUv9cECeQdaEzWDJGBWg+Ahd4Fe0sR+6YDGWAyiw1onGlBR
jKlBXNoAkAd7iIhFyFpjp3BhtwFlw0o7gHEXYtLWQoyTuvYb12F4osAOhqwcfrtsNybJGVbr
ZRfnp2/h5Op19uNVDhp6dNp/aR/diavwVfrzqdsxP8eZUmr55anKLk9VxjZ8nWr9OY1XstU4
OHQZLMcX8Hgxh29pBG58R2B4ZM7NApGRjTYLPgFPL5U9Z1Pj84SWBOwVtNZmSkgXzHlGwwE+
z8l67RUFVjQlJVY05xVWNOdd0mlzhaSKXIK/lT1XWNGch+TO7BXYQVsSYUVzHlNFPk+4mrmC
3Isp6VBFafylNHR4+lScXb7iDzW8kj6IpoS7LSycyTZirkbYRug2Imoj4jYiaSPSNqIz17Fg
DjPXV9nubN6uks/VaJOTt8nJ2+TkbXLyNjl5m5y8TU4+R04+Rw5ugHHyGHZbaQmTl8Ju86nA
lE4/igvK6fjiL7tjd+yO3bE7dsfu2B27Y3esxfFf7P7H6gAoBQA=
--------------000701080103080604050800
Content-Type: text/plain; charset=UTF-8;
 name="crash_output.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="crash_output.txt"

INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
 * Stopping local
 [ ok ]
 * Stopping vixie-cron ...
 [ ok ]
 * Saving random seed ...
 [ ok ]
 * Deactivating additional swap space ...
 [ ok ]
 * Stopping sshd ...
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Stopping Xen control daemon ...
 [ ok ]
 * Stoping xenconsoled daemon ...
 [ ok ]
 * Stopping... ...
 [ ok ]
 * Stopping ntpd ...
 [ ok ]
 * Stopping xenstored daemon ...
 [ ok ]
 * Stopping nrpe ...
 [ ok ]
 * Unmounting network filesystems ...
 [ ok ]
 * Stopping munin-node ...
 [ ok ]
 * Stopping fail2ban ...
 [ ok ]
 * Stopping bacula file daemon ...
 [ ok ]
 * Stopping syslog-ng ...
 [ ok ]
 * Bringing down interface br0
 *   Destroying bridge br0 ...
 [ ok ]
 * Bringing down interface bond0
 *   Removing slaves from bond0 ...
 *     eth0 eth1 
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Stopping firewall ...
 [ ok ]
 * Bringing down interface lo
 * Unmounting loop devices
 * Unmounting filesystems
 *   Unmounting /boot ...
 [ ok ]
 *   Unmounting /data/d0700 ...
 [ ok ]
 *   Unmounting /var ...
 [ ok ]
 * Deactivating swap devices ...
 [ ok ]
 * Shutting down the Logical Volume Manager
 *   Shutting Down LVs & VGs ...
  Command failed with status code 2.
  No such command.  Try 'help'.
 * Failed
 [ !! ]
 * Finished Shutting down the Logical Volume Manager
 * Stopping udev ...
 [ ok ]
 * Setting hardware clock using the system clock [UTC] ...
 [ ok ]
 * Terminating remaining processes ...
 [ ok ]
 * Killing remaining processes ...
 [ ok ]
 * Saving dependency cache ...
 [ ok ]
 * Remounting remaining filesystems read-only ...
 *   Remounting / read only ...
 [ ok ]
 [ ok ]
[  612.749666] Restarting system.
[  618.364165] int3: 0000 [#1] SMP 
[  618.364396] Modules linked in: bonding
[  618.364590] CPU 0 
[  618.364658] Pid: 9998, comm: reboot Tainted: G        W    3.7.5-hardened #4 Dell Inc. PowerEdge R720xd/0VWT90
[  618.364806] RIP: e030:[<ffffffff8102a894>]  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
[  618.364956] RSP: e02b:ffff880136b35da8  EFLAGS: 00000046
[  618.365130] RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffffff8172ad90
[  618.365308] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81ad8cdc
[  618.365487] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
[  618.365663] R10: 00000000000005dd R11: 0000000000000000 R12: 0000000000000cf9
[  618.365867] R13: ffffffff8172ad90 R14: 0000000000000061 R15: 0000000000000000
[  618.366045] FS:  00007f32051f0700(0000) GS:ffff88013d600000(0000) knlGS:0000000000000000
[  618.366317] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[  618.366489] CR2: 00007fa697fb3d30 CR3: 0000000135590000 CR4: 0000000000042660
[  618.366664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  618.366839] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  618.367013] Process reboot (pid: 9998, threadinfo ffff880137af3b90, task ffff880137af3780)
[  618.367288] Stack:
[  618.367482]  0000000000000009 0000000081045315 0000000000000000 0000000001234567
[  618.368001]  0000000028121969 0000000000000022 0000000000000000 0000000000000000
[  618.368527]  0000000001234567 0000000028121969 0000000000000022 00007f3205203248
[  618.369079] Call Trace:
[  618.369250]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
[  618.369425]  [<ffffffff8102aab9>] ? machine_restart+0x9/0x10
[  618.369598]  [<ffffffff81059f36>] ? kernel_restart+0x36/0x50
[  618.369771]  [<ffffffff8105a14f>] ? sys_reboot+0x1ef/0x220
[  618.369945]  [<ffffffff816e0d85>] ? _raw_spin_lock+0x5/0x10
[  618.370117]  [<ffffffff81120c76>] ? dput+0x196/0x240
[  618.370288]  [<ffffffff8110af10>] ? __fput+0x160/0x220
[  618.370488]  [<ffffffff8106dcd1>] ? lg_local_lock+0x11/0x20
[  618.370663]  [<ffffffff811287b5>] ? mntput_no_expire+0x25/0x170
[  618.370838]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.371016]  [<ffffffff8106253c>] ? task_work_run+0xac/0xf0
[  618.371187]  [<ffffffff8106dd13>] ? lg_local_lock_cpu+0x13/0x20
[  618.371364]  [<ffffffff816e7897>] ? int_signal+0x12/0x17
[  618.371534]  [<ffffffff816e75e0>] ? system_call_fastpath+0x18/0x1d
[  618.371707] Code: 88 ff ff 0f 1f 40 00 8d 42 9f 83 f8 13 77 f8 ff 24 c5 b8 ac 72 81 4c 89 ef e8 99 95 fd ff 66 90 c7 05 4d 9a 98 00 6b 00 00 00 cc <ba> 6b 00 00 00 eb d5 c6 05 f6 6b ab 00 01 44 89 e2 ec 41 89 c7 
[  618.376270] RIP  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
[  618.376604]  RSP <ffff880136b35da8>
[  618.376799] ---[ end trace ba379a71b4991d2b ]---
[  618.376970] note: reboot[9998] exited with preempt_count 1
[  618.377238] BUG: scheduling while atomic: reboot/9998/0x10000001
[  618.377413] Modules linked in: bonding
[  618.377704] Pid: 9998, comm: reboot Tainted: G      D W    3.7.5-hardened #4
[  618.377878] Call Trace:
[  618.378049]  [<ffffffff816d6fdd>] ? __schedule_bug+0x42/0x4f
[  618.378253]  [<ffffffff816e00ff>] ? __schedule+0x5af/0x640
[  618.378432]  [<ffffffff810fcb06>] ? alloc_pages_current+0xb6/0x130
[  618.378611]  [<ffffffff81004661>] ? __raw_callee_save_xen_pte_val+0x11/0x1e
[  618.378792]  [<ffffffff81070296>] ? __cond_resched+0x16/0x20
[  618.378968]  [<ffffffff816e020a>] ? _cond_resched+0x2a/0x40
[  618.379142]  [<ffffffff810e2aee>] ? unmap_single_vma+0x4be/0x7e0
[  618.379320]  [<ffffffff810e3604>] ? unmap_vmas+0x44/0x90
[  618.379494]  [<ffffffff810ea12f>] ? exit_mmap+0x7f/0x150
[  618.379670]  [<ffffffff81042975>] ? mmput+0x25/0xc0
[  618.379874]  [<ffffffff810491da>] ? exit_mm+0x10a/0x130
[  618.380052]  [<ffffffff8104a604>] ? do_exit+0x174/0x920
[  618.380224]  [<ffffffff816d6c0b>] ? printk+0x4f/0x54
[  618.380395]  [<ffffffff8104b211>] ? do_group_exit+0x41/0xb0
[  618.380569]  [<ffffffff816e21ca>] ? oops_end+0xaa/0xf0
[  618.380746]  [<ffffffff816e1dbd>] ? do_int3+0x8d/0xe0
[  618.380916]  [<ffffffff816e14fe>] ? xen_int3+0x1e/0x30
[  618.381086]  [<ffffffff8102a894>] ? native_machine_emergency_restart+0x74/0x250
[  618.381387]  [<ffffffff8102a887>] ? native_machine_emergency_restart+0x67/0x250
[  618.381658]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
[  618.381832]  [<ffffffff8102aab9>] ? machine_restart+0x9/0x10
[  618.382004]  [<ffffffff81059f36>] ? kernel_restart+0x36/0x50
[  618.382175]  [<ffffffff8105a14f>] ? sys_reboot+0x1ef/0x220
[  618.382345]  [<ffffffff816e0d85>] ? _raw_spin_lock+0x5/0x10
[  618.382516]  [<ffffffff81120c76>] ? dput+0x196/0x240
[  618.382685]  [<ffffffff8110af10>] ? __fput+0x160/0x220
[  618.382890]  [<ffffffff8106dcd1>] ? lg_local_lock+0x11/0x20
[  618.383067]  [<ffffffff811287b5>] ? mntput_no_expire+0x25/0x170
[  618.383247]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.383426]  [<ffffffff8106253c>] ? task_work_run+0xac/0xf0
[  618.383599]  [<ffffffff8106dd13>] ? lg_local_lock_cpu+0x13/0x20
[  618.383771]  [<ffffffff816e7897>] ? int_signal+0x12/0x17
[  618.383943]  [<ffffffff816e75e0>] ? system_call_fastpath+0x18/0x1d
[  618.384191] BUG: scheduling while atomic: reboot/9998/0x10000001
[  618.384364] Modules linked in: bonding
[  618.384696] Pid: 9998, comm: reboot Tainted: G      D W    3.7.5-hardened #4
[  618.384872] Call Trace:
[  618.385040]  [<ffffffff816d6fdd>] ? __schedule_bug+0x42/0x4f
[  618.385215]  [<ffffffff816e00ff>] ? __schedule+0x5af/0x640
[  618.385397]  [<ffffffff81070296>] ? __cond_resched+0x16/0x20
[  618.385570]  [<ffffffff816e020a>] ? _cond_resched+0x2a/0x40
[  618.385743]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.385918]  [<ffffffff81062559>] ? task_work_run+0xc9/0xf0
[  618.386121]  [<ffffffff8104ab42>] ? do_exit+0x6b2/0x920
[  618.386294]  [<ffffffff816d6c0b>] ? printk+0x4f/0x54
[  618.386465]  [<ffffffff8104b211>] ? do_group_exit+0x41/0xb0
[  618.386639]  [<ffffffff816e21ca>] ? oops_end+0xaa/0xf0
[  618.386814]  [<ffffffff816e1dbd>] ? do_int3+0x8d/0xe0
[  618.386989]  [<ffffffff816e14fe>] ? xen_int3+0x1e/0x30
[  618.387163]  [<ffffffff8102a894>] ? native_machine_emergency_restart+0x74/0x250
[  618.387437]  [<ffffffff8102a887>] ? native_machine_emergency_restart+0x67/0x250
[  618.387752]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
[  618.387928]  [<ffffffff8102aab9>] ? machine_restart+0x9/0x10
[  618.390113]  [<ffffffff81059f36>] ? kernel_restart+0x36/0x50
[  618.390288]  [<ffffffff8105a14f>] ? sys_reboot+0x1ef/0x220
[  618.390480]  [<ffffffff816e0d85>] ? _raw_spin_lock+0x5/0x10
[  618.390686]  [<ffffffff81120c76>] ? dput+0x196/0x240
[  618.390856]  [<ffffffff8110af10>] ? __fput+0x160/0x220
[  618.391028]  [<ffffffff8106dcd1>] ? lg_local_lock+0x11/0x20
[  618.391199]  [<ffffffff811287b5>] ? mntput_no_expire+0x25/0x170
[  618.391372]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.391544]  [<ffffffff8106253c>] ? task_work_run+0xac/0xf0
[  618.391714]  [<ffffffff8106dd13>] ? lg_local_lock_cpu+0x13/0x20
[  618.391887]  [<ffffffff816e7897>] ? int_signal+0x12/0x17
[  618.392057]  [<ffffffff816e75e0>] ? system_call_fastpath+0x18/0x1d
INIT: no more processes left in this runlevel

--------------000701080103080604050800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000701080103080604050800--


From xen-devel-bounces@lists.xen.org Tue Feb 26 14:37:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 14:37: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 1UALel-0003wt-L5; Tue, 26 Feb 2013 14:37:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UALej-0003wj-HC
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 14:37:22 +0000
Received: from [193.109.254.147:55574] by server-8.bemta-14.messagelabs.com id
	9D/AE-17325-0A8CC215; Tue, 26 Feb 2013 14:37:20 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361889169!9373647!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10085 invoked from network); 26 Feb 2013 14:32:50 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 14:32:50 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>) id 1UALaK-0006Uj-W2
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:32:49 +0100
Message-ID: <512CC78B.4080606@mfiala.net>
Date: Tue, 26 Feb 2013 15:32:43 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Content-Type: multipart/mixed; boundary="------------000701080103080604050800"
Subject: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------000701080103080604050800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hallo,

I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
without problem. When I run reboot or shutdown -r now, system correctly
shutdowns all runlevels and then system crashed, see crash_output.txt.
I have the same problem with kernel linux 3.2.37. When I shudown system
(halt), then it is without problem. I have tested kernel 3.7.5 without
xen hypervisor, it was without problems. Required debug informations
(http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
Could you please help me with this problem?

Thanks

Michal


--------------000701080103080604050800
Content-Type: application/x-compressed-tar;
 name="debug.tgz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="debug.tgz"

H4sIADTFLFEAA+RcW3PbyI7Os38FTu1D5FlLZvOmy66nRrc42rFsjeRkcjbjUlFky+IxRerw
4sip/PgFmheRlGxLcs5WbS1nEptN4CO6G40GGmAsPovuz9/9Sy8Jr7qm0U9W16T8z/R6x2TG
FKYyJHwnMcbU+jvQ/rVixVcUhIYP8C40Qt94ge615/9HL0vM/zxynGnAfdtwpqbnBp7Dp14U
rqKwFq7Dt76DJlhX1d3zL2uKpMqb+WdIx+qKJr8D6Wd08LXr//n8A3Q8L7Tde3j/hbug1mQ4
B8d2o3VVqdVrWnVh+BZ3ufX+BH7CdeLj26CysKQz6fQEPtgOD56CkC8hfFpxsANYz4MzWBl+
aIe258bN0rqhnDxw3+UOnK+5W7v/Dpa3lKZLvrxQL8+WxrqlXiZNxnr6aK6i4EKNG8TNdGW7
kGj2RRg+SSfpjektZaC/LhjTZEk6a7iMuvp1GDmhPUNxq9yZn8F/SmsmFLaFvzTrDbmBv2hy
3Wr8egbBIjRmF9Ja5oZUb5wBd0P/6SLluDtZelbkcDjfNbBAQ3JxbvHH88Ay9IKU2c3i0ZRK
UiWYvwG9doavOcPfVMtkugSzp5AHdycn8Bf8dQ7n0+kU8L8pAvyAH/g//qS2vwAn+wfi0i/n
QA3vRWtMRfTT6SndCapzQTidnscthEEUP/ABNU4F1fn0/K/pX4j+g+7xD710+qMyPZ3SRT9/
7KdKJ5Uv/etTILV85H5A2oDqWWNQ+W3pzWynZn4/hcq9aULlEgfc8+BjOqRqTa8psGI1xlCZ
bF6ValpNPo3bT+E24qAk8FcGDlUI3YXh3vMJD1sQucajYTvGzOEJDS0RxzMs7rfg8voTXI4/
dUCqNevJ8663XBquReuGt96qmdmNyRL4z7bFPbDduecvDVoVreQBfL5s05oJ+ToE1AcODVQG
7QzmnhtCY830jLDTP+/1urDk4cKzgha4nsv/A/q9QQ/QrrnBnPsQ2ksUX4KAowhWkPIKIno7
MoXg89C3+SMO8oybRhRwbAWCTh4YTvISsHjIzZBbCU7PDsydnfjgRTh2DIadMQT2vWuEkc+D
4lMFpejluSEI/cjMU6KeVHlDlmDcHsLSWGX4UumCar6pyampEgU036fbPKzMM7PkufQST0aQ
51GYKXhQXu7j6O3gSkgKXNpMcLW7owFYRmjsYotpNmxm2s/nX8a3h2L+Otecl7mY9CrXhiTl
kiU14yoOIXWzBeNJb0SkH6QPKhk1SVYRXoZe/+oKoEj7ZdK7FbRMUhtE2yZaltDCqD+ddJWN
SckexHdFrA/4Azo9RWWs2yWsD4SlHIXVI7kQi3UlMsz1ui69LNfg+vYKZPR8JXSEtuSaCLkU
gSXh8BWet0eDrnguqbT3SExvHz0Gk1F3HGNpfZXepb0i9wtYH0f92xhLV8TcKI2jsXrDdiKX
Xie5mHY81rD74TLGajbFeCrdo7H+7OEeGGP1CIspx+vf5Cqdx47UyPT+OKz+eCLGXlaaMskl
198wj/0UqyPGS2seP16d/jjBwhUhxv54ufqD6/9KsIRcrHk81m131E7Wvi70Xs/bnMOwRt1E
JxhaEIHVP14nxu1kDfUU6qPSPb6Pk8QmqWpsk/REv9D09JFnNBrCuDsE9CFiw53aJElHq9RM
sSaxu46bbAswYpNkfdiBCuo9qzPWlB86KWHPWxro2iy4scKNG715w7EDdBtwKcM32woXoMgw
s8N0/x75nsmDwPPh3yTQW0yJDVvq+slsmw4B9iPclw5X736E+9Ip+p6E+9KhDd2PcF86dd/B
ZvsSqvuONtu3z8q+hPvSaXsS7kun1Pck3JdOae5JuC+duu9gs30J1RdHe3BD7V+luxYYK9uc
2hagzUnJFPkMDMtCnzHAoHXOY5f1DC4nA5CqslIEYTkQ9gKIMs9AFLmqaUUUOYciv4BS36Do
arWRxnh9Fz1VOicR/aVgq4U2c/EU1AA+BfRAgcH5jXicmjSxC4fk4VKUZrsYHNlpOPSnFzmW
iKi4KyjWskC2MDYNKdoLue9HKwq4MJhZ0QtMwyX6GU9YrFqCFb8/MBecjgQwSJ0MR9D1uWWH
MElboWKKlsw+J+EZyJok1aQGBmAfv8MqneAUe0CmG9ExoPX8JwgWho+36dN1EGL8PCX7joGz
EMN0w3U4DezvFEuucecCCo0FXUAt9Qw45A58vq3iw2i18nySZWXccyBeJFUfOmcgD/Evdtmp
/Syuiet5K4zY3dD3nPJA5uhw+5LEXjUygiBc+F50v8hN1y6WPyIeoTSDeJ7jMPV56kE2w+Ns
hp+nnuC4I3Z/lChUsEWLuvdo+2FE22zh3WlAVo37FKvumDvGOnvWjynBsv1YJ/o3A9ykcY+2
PbFmDPNh6qG+eu7fUpbrdudqcH2Jy6sqFHcw/iML2qu/JjpJPO3u78mRQGpEHCOkQF4cOPi0
NJhaU1iD9I+ChoTsffs9qiMqI8qDgLF2uXQA4MADf4IF6hWtyNTJcRzPNEj45AAFfCHBHJcx
/G5nuvB5+AUXSKY7hvVouCb+MufxwUNrM16iX8Ph4AYMk1ZFaYBLhLejMS0Py/u2edBfh9y1
EH1EKnobz1wFZ/F0Q/M5Bq1ubOvA4m5oz200UVD5PBr0tqnhejjYNA4n42Tuqomk6FihUm0o
PrnYtdC3xexeRvh78uzjZ3Tk2pNBb0ujxBMcrZIeiWY6afuGGgntILCDMO4gDXflY3t0Wj76
iVnao+cX6ktTbji4UFwc8Ue+a94PVJP/hVd0hLEIIVoButjd0ad0Xfzyyy9wddPu0bLp3Qzb
g2uQqDGdJjrqhPicu0WbD07iGTjB7IwOqFdGqMgppVjJZcpRu5+Qr2hHg/T8WSKhpbUc36SL
8OPfJ4Nu+wqG/eHN+O/QHo/b15f9Yf/6tlV4i0HrqoabHaQHOnJywlT9NW1RsgMd/F3GMEDM
dEAbGe5WRroyUzX+PBjffnr51Vd03GplXZwnV4Olr85ait0S+1UNfGNp2cFDjlF+jZH28urQ
MBfi8PBFxkaBcRIafijOJmmQoExWYlRnavZGWg2xNW+VGFmZkRm5N9J5NO2o5kP5jYKsyDjL
Md7e3LavWlm4mJFJ2300C33EqaGJ6vXG/ckkPx0GvsFMyYS+LIwAR3BtL6MlqPA5p/4T049m
M1o7H3zO4xCy9hOuvKeCK9LxvqXeCtrrfwJu3jxY0E4U8BCMkNIkpKtCRVPmSWjVUOnuHf5I
+tb3fQ+NL3kuaOZclDnthLCdOcprL1wIwzdGDa869tJGRd8JcJqzAhORa0WlWUUhrU60Brh4
RLLrffd2fFU13gu5udgjxUIKcD9G5YxZ8B6NRYpIw4l+nCo9dESonXS/dpL6FUnuDJ1KD1ao
57YpjumJ6MSYeTHgPRdKRbsiDepX0hB0DMV1l46u/V34ePdo4lbogc2CpwAojcHDwxjK1FeU
Gds45cUMWYVSZL/5xj9wPpUk57NJCVGqp5QBUsrwxQzN3hm3EgqNM/WmyauMFGjuoqFx7xGx
2Ugs3pym4jk+kRmoJhmFHLdcV/SG9BICumvcoO0HSev19GXo20RuRM3JXJa4JjijOYZKcErz
zKoMEsUoM4y8VYTOGckaS1llqmzV5ZKwGwlwn9kWlrIwLegMbiZVDCcebTLkmdZl2ZkSE6pz
C75iP3B5SqWrWmhqWmh57iBOHewJY2zDCAN2B2neYj8gVpYHp5TPD5QnTRAVYBQ2O1ieNGdU
BNIMAZTljPZEEmmkPFJi4w8TKc0s5YD4UUBpsikHND8GKMs/bYCETrPDJi1eB3kYWVIyeWgV
7gK6/oLO/pqbUcgp/ylyXRRik3dMKVCMK8jn3Fq3Q1o8INfqwu1E07Zljq89aF+OYObbFjoR
c0qS7l6GjhGEU1q+F+QPxquZMtGGby6y9jQht2XxdmAI7T0AgjakaWyfponZ2ZrsqoCNF9Ih
/PnJ3cxqGaGYVsy0SZqrEjXQMfijtMkv7uROE40ZNyUcqaEtuLdP5FO9iR+kd8+gi9RjCo1r
UWUMtzgpTkE+Sts5yIPQe3nZszyzFCclX5S9lJV8TvZJQXZFoIs05U4GESznGShviQ0ib/nm
oRQZzAK6xlVq0F7r7D7oIqdZQNcVoQaU23wz+hfKchbR6yS7yHa+GV3kPQvozaaYKMp/vhld
ZEKL6Bahi4zo22f1qqwzM6mxWbxvRBfntDl0kTWlBGz9p+hMv4w+E+Mu8qhvRhcZ1QI6LWsp
zqy+fWQox1pEF7KLXOub0UXWNT+rlH2lBr1gko9EF3nYAjpafIHe/xkaSZnZPLpkKZIoJvgZ
IzMpmWyRs0WTraf6vm/Stuw2fBq2IYx8iqq8+XwrUDEexHEYuFRMhqHyqw7587suxX/EjaEh
Rn4CUNqx7z8PAHB90+tPe+3bdrbfI7HOX2P8b8/lcbQSbIUZIM70xbWRhWV9Shy6nVyKnOdi
WQ8yt3RHB+IzQjjMXxl6jyIj9J36ISJydPB84HQ2ReNYpu8bvvOUHnmIgY47vy2PeIhNrZ2d
TyKrvdiyQOhZv20H2yHu2mhYvRXpgcENhqV+SKmjhtTYTXwlfIqKYa7sqW19pem5Q681zvbR
Lbmy8Sn2MwtuG0EuIMhHIChFGeTDEdSiDEcgaEUZ1MMR9KIMRyDUizLohyM0ijIcgdAsytA4
HMEoynAEwqwog3E4glmU4QgEqygDOxyBF2U4AmFelEE5GIFJRRmOQCjZB+1whJJ9OAKhZB/q
hyOU7MMRCCX70DwcoWQfjkAo2YfZ4Qgl+3AEQtE+aAhoxec1+0MUDYTWPAKiaCE04wiIoonQ
ZkdAFG2EZh4BUTQSmnUERNFKaPxwCLloJrT5fhDT6+EgD0MHfAv7fgGcjtoc2w1JvLtnIOJq
I6hkfkdSXPR1U+d0B/eBPZ0ZAf8qbcO8sXJqD6FYSShRN5UTSpGfleroUqw9xJJLYtVLYunq
s2IdXdu1W6zr2+lk3J3efB5DZRYhL+DfU8olSnDveDPDETcyWHOH/jynCs/jNPM4zVi9REJx
CyquoxGH+ZVhu3d7KmIBKvAyPXdu30d+XOyT+zbmhaMr20r8aN2oY7BI49oSQ2MJ2jJnsFzR
t2YtUVzzTRS5yaKg4QwasPDClRPdxwUOO8+NE7c//SAFvX4rOzLPvrES/Rl1B2DxR9vcjlrS
7xNXhm+k9Tffs9IAwK5/4Vtdzn001kq/GlslWYNqu7c1yiJIna64b66iFlyPp9ipSQs76/pT
bFoawcOUapU3Tahq6R3FOeKWbeXT+mMEakF/OeOUKQNZiRNn54gAv4kUekNiiqULBgh0VWMy
+A0qobBkpkkqRFRlXZcFtCbVmK4rOu6Ynch2QmAiSHTsIKT6Qow3MeLyfIv7ZyC+kbPDJxCp
V1EK5dYAbr0QI1IhRAuofFtpNgrYTUoDOrb5JKBbSQybJ6mjAfk9Hn3z+LxqDKbSsh8NelQ2
sEhqJenrSVuUCElNHSqiPy1QzlD56noj/rjxtICBPsh0ytfTmN9wfG5YTxCICq8zCB7sOA1O
DXk+Bf2ndWA8ouiJv5AWNM4eqVLxLC5mFBVLcS1jxt1UdfIZAm8eijoojFJvrzpZoKs09VTl
cXa1ROcrujrsnIrkK1WehfA10wBBf5fCy1JdVVG4oYjpaSDkJo7Fw7kmN5oq0x9yy6dSZxI2
PKQTYvEznNemxupENqPsETboGlNPc/AabY6Tq0+dFlxyN0Co4IJpZ/DxT1xe9+4FfQVxQwN/
IVVx5Ie2ezP7BzfD4ALtJ634CyQgdUO2PKyGsB9t7lNuKM73dj+BvVw5fImCCPNUK9CjLgma
tDyN5onwYe57y3QlXuBCC73cyrtQCyg6HW2Np4PxH5OWqmhiVaJlxRVJB8RMz9Hq5KmvKcEX
mDZ4aCR8mwoiN/b4ogkoyf099R1WnmP4uIoupDyGLicY5CUIoGb2mOlyQ6eKA6HvLZwRx4t8
+lTz3+PPMzNKyqOjDqXlil9pnWSe64YKjYGWo6IFtItKaYpkGeqvI+qUyQTGBZZkYHEUQcpR
aw2kDgOztVUHLBXrgHM8dZqsLurHzI9rBCzuGE/gUEFtRSwydKxw9zWciAPOvUm1BAgc18sl
svj8nxF3zadaDVGljUoqpOB3sLIt+lC2hdhzI3Jw64kX/dJ2qaKohbQsx9MgZ6YnPrfGN5oL
vtOOaLIqNxqZJWGowiquYAWta9GYyGhxKCQakEmvPg8o6zJT1QyweQay1KwzVLwyHlMVRid6
kRu+hKfpORbRqZfLZwzTDHMczbryIgfVlHznm7lUZdZEzRN70yitzMjVn/ZaOWVRZUVvpMQZ
Tdcjq1ci1BScwqWJWk/6lhRoB+goDbt9dDbchyBHjMvoDq6MIIw9H7DJgG5s/+8dwL1QlIiS
A6zSjxe4ree5yQ1Uxc8yf+jMpnMnChYG/fsXC3uO+rZZn7g/0NFCWr1DPleuUDQg1Xwol+vU
JU1NPS4xRD56NfGnERJDJWE5Dx1tNC5C8gRw58cNyvHMB8DOuCGQW8iknNvc1Jsoyoj7wstz
TQ59Igzoc/VcIbwuBp5KvB1QNfo0ezT8BJaP8qJLkO1W4iXBpqgAzSTZrBetB8tRq7oSC852
Cs7kHG1DbbyCnKNGQRJkeTdyM0erkBQvIis5ak2px8jKTmRZz9E2aPPNlfGqRSeXyXIdwdDR
CZerOc5B+n3b95wqMLlOJzxrDw2EEYUe+ea4zJynxB7OqI4QDYL5EETLJbXMIzcuC8kwNFmj
cwS8jMc1xBdaC1nSGPmYMOycB9zMkdfJpbn0DexV8plA/LLs+xwMiJ+8KFdPoslNOsrK8ezs
jaYwOmW57t/StwP3VPNN3yNQLYuHOxzMjaWNXWN6jqNBZ0MicvmAgQsOl4l7KRUzohVM/tUP
y+OB+z5MTQXFARzak9GQlDWN1sHeFBdqaKGzkIZiKlEzucId2M+k2hAjNa2aLmW/h92b6w+D
S6EbVvxtovC5v4rITKqKoCTLeOXqmDb1SxWKl05z8HpDLcO/ApFWLpG33scgKQNr6KqegsUx
XzG+E/1kQnqSIvkiIceuZ+y9/2Hvyn/bRpL1/Jy/gsg8YJO82OZ9ZJ8fQFOUxbWuESnHkyCP
0BkLsSVDtJPMf79V3TyalyzPDhbYhwowk4jd9bGP6urqYnd/q7u77JxmthP/PfcY2EJqsTmf
r9EXLrTA0S3UgvlmBw4LeM+P0EPgE0r/A09O5P9lu2azzIoJ4wMy72ebpQluVLJSfyqYhH4R
U8ksp6rhvT/lnOwjmgPKUc7poENdzqlDCjiyllbNaWLwPc2Z7d//ugMv7fY+k3xTCL4VJC2n
KpmAgAaF2q8W6Av+UUAJYg6KpZtX2DIuHoXBmwG/gKXDlq35WzTcyGI0ZC+mzrqEpmkNEtqp
LMWhN+anSHD8JoIQzGHOwde4X7/CmJg9Nr1RZy7z5+5mf88mhIunr18+ZDsKcO8Zw2Kbct9K
4LBBw8CqYCcMLg3UH/3BNNSBh5lggQ3/L7mmPKOFX654xje5UxDKUmgIRTJlJW82PgDS8BCq
vHAcDqyXsHNVU8B3Mkrj5nYHhjXdGPdjs13ufqSLCcT+u7RZS9sVNtFs/8d7CS8weY0jYrtb
7JPXbMM2tFoOD/iasKMgkCa49/6Co3+GB5D4psmcaMsiWqVp6AiyQpZKh8cjWG68VUgWcoMt
+ILjNBaS+fKaCYARgSUF+ADCywRpG+edY6Q3Oyn9GI/ff7XZWkRxbOVFKNqKoSzWloCiKbgg
fAnKnJdlKZYFYJwXoSz5ylv8ugwgun1kq3KUdJ/BuoJiGtZxKPkXdmHz8byKZmtHtjJHW9r1
UFqBpss40I5HW6+WeoqG/9TLaJZp8LLlSDJ4HXwUFArMVVAV5GxYgNfklGY5RZQz8TNcSU5t
e58uyDlyqmOinNosp4lyWjpOCjmt7X2GKGdYlXZRWtvFFOVsrVJOZdEmJ4whHbdF1eSsZjn7
RF4UooZmyI4oan/AJX6zqFMWdVSt1IvOAdHZiTwvRMERUUsdOTsgKsrZFn6XL72ytWGFoloy
CyKWGmjVJrf8glPQ/HHPd16jUwqLpcJSW4qNC0NEy8fPBEMWyWMeh4e50UPvjJ0gfoMfzAR5
VUMXvCTfJiR9RadbmClt6Gvr0GSjNE02unxirYTJxjbB7T082RRbcyG3ZVSnC719suEvE6Qd
o2rAWqS5UU230GslU2Nbil418AdRdI5iVFA03X4JislRrAqKUZt8D6LYHMWpoFjo+B6PMuMo
8wqKYxgvQVkUU4OAYivHoqSTTLFwWVrVScaRdV20KfqBaUFXRDlb1itybeZdF6YTB1bu1fe1
mWldE+UMVa3JNU8LujCdOKrOYtLZANZfaAAc1UG/vCR/tAGAwWRq7QZAvmg0ANpaGP2gMYpx
ePRrayG3VXMWtXXr6NcKRdDxFjdLqCiKvaChQF639Yr8sQ2lK+CgKu0NpTQ3lCU0FECY+B3t
UENZayG3bVZ9K6u9oSyhoVSVWfW8otYLG0pVbdmpyB/dUKrFAp1FQxXXTsDq7pv0uX+FHyrf
4O0NkibpkiGZkiUpiqTo0jvFEIph288iKY1I7wCqhASLfeUZJLWtTAAkvZPf5zs58hiGDks1
67kCanXYdzlugaRq9nNIuoj0rlLCAgmmJOMZJONPVFW3Vf0ZWLMM+66lgIZtq88gWUf1KrhO
OCR/rrZnczzxj1/es08SPODJn6bRaKEylo6xbRA8eaEgNAIMjO9fZ7P9/EO6f4AfSWV1+cA9
sDlzP99zTy853+z+G6a597sf2/zfGAtOzvFKVAHbwPVvhs1uf10KqWxUZamp6ciG4sMuSTYY
txTfX8g6Gg7n0AuD9PMMxukaYq46TgdqLdaZLJKmYKcOTrCl1HI/JfPmzKbm4PHH+WK3xy/3
RUh3u/rBwy3rGbQmb3PMuE4EaUd5ifTt07yQVVQM9LXJpp1YvFYQZF+5hEAPM4IYHQLlrMaF
dFi8OqC4ITs1z74/7qQF62hupn8Wm0Ygr4nbHh62D6A32zEHxh4Rcth2Q9h5+9DUuKYj40LG
zbYhsAMQGPTGfUcf8m8SuoXfO75koXBUFVjVZSEMm4cMbAt3n80Sab5abWvnXgFCQxVpgbA5
xPoZCAPHbTOEw0vhKM9AWPhxoAVC5RD4YecQhIMRsjYI/aAsNGPr62F5yAJK+MHmEIQmt75+
MeORrdkzEDp+U22DcDjE/DCEiZ/62yCWHOJwVyi23V4KHlxbzA9D4Hf1EoQtlsI+LGs4arvs
4qCsputlRXQ+NH1L0Vbpt5QDUOD7ayWoeQGlF1DZ6uYglG2YJahlAaWti1IdAWVqFT1d5VDL
tVME9hxZeRbKsstQ6wJKK5Zv+DXiOSjAUivG7wM/US4pdnVXHmQX3EBmKEvm8GnbYBAdW0dD
lx/pWc82d+k9XZh1u/iDfwiV0IvNDlS9lU6k2Xy3f2TXzRVQZjm4pODsqnzI93kmDzjxLHZ3
dxu++y9rlYWdt8rCZr2Fh+vXuLPmiwDv6KWgoHo0fNHoC7kF3pBl3ZGb4C/ciWTCWxK8AB2a
JkN1ClRHRBUQLacaxTwiSgtyjlONtjI5qfzppLF+VjkmYODOhnrI9wBYqVoMTDL1+eaxWjmF
faaqd3ZrcykFrtLYXDy899LgtCGrsmk3ybU2l6Bt62pzqaqlvwSsVK0DzaUadhX3iAg6yLHv
oi+NoINcXYeYXK0efAJYy/UPKoasqcZxIGljLAvdWdZaVtPNKtgRMX2QMy2nEkI+IqYPcrZj
vTymb8i6opQGzHEhcpArB99yubbGKi5RWa5qjQVzm/kSMOHbk70+oIaGWi7k0Z8OQNSUzSbR
P1U/w3Yay/Gv1s+sfJA57juFgZc56E1ybeVZW4VLUDO5lmqXWuroTzsgapYisbnoEY3cUA7m
bx4Pdmwj22zv3Z/46gWiFRchE/1T9bNttT7CD4AdWz9HMV/w0UqQ02yxckeG30HOLLXnkeF3
kLP1atj+iPC7oeAlDi8Pv4OcxtzL5rWzoQkZjWMzWmzpfkRGx2pftosZFQsjES0ZbUPI6OBE
f0RGVTkSESZL8/lteGohAC4P6G/kjaVVgtv7NsktCByzS1p5L9mabZty6cgFA7XYPkMEnYP2
N6KZhqEVhzdsPJOg24Zl1rBsxZIZFt4qm+Ek+e43vP5PLHlaSvZe9g4RSsdIBoPar7a7htgM
5DFxj/K0M27eiI23OmWF1t+ntUiLTFxpxJVGXGnElUZcacSV9pwUcaURVxpxpZWwiCuNuNKI
K4240ogrjbjSiCuNuNKIK4240ogrjbjSsgTiSitEiCuNuNLSIUhcaUPiSiOuNOJKI6404krj
QsSVRlxpxJXGxYgr7Uh54kojrjTiSiOuNOJKE9CJK4240ogrjbjSiCuNuNKIK4240ogrjbjS
WhGIK4240ogrjbjSZOJKK4pFXGmpJHGlEVcacaURVxpxpRFXGnGlEVcacaURVxpxpRFXGnGl
cXjiSiOuNOJKI6404kojrjTiSkvliCuNuNKIK4240ogrjbjSiCuNuNKIK4240ogrjbjSiCuN
yxJXGnGlsXzElUZcacSVVsgSVxpxpRFXGnGlCbjElUZcacSVJsgRVxpxpUnElUZcacSVRlxp
xJX2b+VK+0xkaUSWRmRpRJZGZGlElvacFJGlEVkakaWVsIgsjcjSiCyNyNKILI3I0ogsjcjS
iCyNyNKILI3I0rIEIksrRIgsjcjS0iFIZGlDIksjsjQiSyOyNCJL40JElkZkaUSWxsWILO1I
eSJLI7I0IksjsjQiSxPQiSyNyNKILI3I0ogsjcjSiCyNyNKILI3I0loRiCyNyNKILI3I0mQi
SyuKRWRpqSSRpRFZGpGlEVkakaURWRqRpRFZGpGlEVkakaURWRqRpXF4IksjsjQiSyOyNCJL
I7I0IktL5YgsjcjSiCyNyNKILI3I0ogsjcjSiCyNyNKILI3I0ogsjcsSWRqRpbF8RJZGZGlE
llbIElkakaURWRqRpQm4RJZGZGlElibIEVkakaVJRJZGZGlElkZkaUSW9m8mS2Mo6ikoAPvI
s7FlXcUTMlno747tPc3v4tJODQd9Nxbuwnv3Ts1T/QOLc+GJr5PkAe9tnIYXWdhr+3Q/Bwgz
3Zy2ul1s4ttFjmY6lomb5EtoQ0ATINjr30ub5fUK7NL+XDZVHX+O97vl0+LxHJxERcBzUDsO
4eGpjO1XaJrBeo9nPjIc4316ieWQlfncLEBtFbezlUBTKUABn10KH3d7vPu0m254FUR13NtX
Eh3Mtk/rGaN6gj5xv+8W0FuChKk6FQmxXB/Y9VV4F8qJUG0oIsZZFslGkXAn4PwkSYuUgYBN
RZay0cNqO/FAccAdtPGmanYdB/YNDND0zkl+deWbn7YZm/pb6fONP5SRe+0d3/aPmc/wOAXe
dfoKVGj3TfpSTt0/bXniO/bvsx28db9Id2Kygxbsbme84THLgpHMtgw58M/Vdp20vxZ6+GDi
2cPjYemz5Pa+PQMePGhLXK7mT1+ldUH/15YxPcfQnjPMO6ShOsJ9lqy27Erz1c9NkhaChTak
7Hb3J74tvgryccZvwMdIc5aFX2ycHpKBMVwt1OqRiaRFZnHn7BgMOwKS3p7NEz5PI+9LFcJ9
etzxrw4Su7P96Q7v7xTB0ymiv/vKjm9c7+6e7lc4XECP91U4D+MrKIVXMd8J7ZlILOtZAhb1
bJ0svp3+xB3tN92QZUqr8FdkEEozWd1nHSyWpFLm6cMy7bvV4+LsHkx1rZFwEw/Pk/yYPeQ9
2qZN9cpXmymddYRLc/Hc6T1ubK1nzkbfUwINfgf9sGX7iPfLeta71WzLqvJ9ti/Gu6BkG3ZC
8ezx/qEYzG1qBYW532xnSF+w2C3xCahQ98SuKVEmkB0eY7yAn9OjVTa7u6Ha5skKr5VFxdrh
8IfibjICi+UKfFh+xT6713hzdwejAKX20J/ppnaUXD+htWb2bMzurWXbbFc/H/ezOD0xmrxP
f6c3DufPJbzpKE3Z4YmyPOW0NNzX0Eg/ZlCCN2f4Df6MKV/6LP/HaXL7ltXwozsZBsPLD1J0
u+JcFNL9jF2nDC+cY9s8rk5Z5aGptrg77Bs7WQLu2L8o3NAbuN1gCzqFViS91Lit476t/pjv
wFpwdseWXsa70tPM2cW+ifT5KallvEC9Tk1H8ZHubodpkqSo1iks3U6VM7sqKOEOcxTEr2yr
hD8qJGSQ+L6ZFQjHvXi+2y7lEnxyN/ueXhuPadmkiH9Wj7cy/k8pcBsG+D2STIIqzGDw8PPw
B6aOrN0WT6Bq9xUxdqd/w6AXTM4MCo3uCwxEZn14bLiSPxGs9f0DK8zpMnM4q5lLR/j2UAIo
VuoTfl1tV3u2mV+UCYYBrAR8bFIm8rRNryXXDjT7Pm303H6l6zFIKFo87RG+Vx87JJOSxL4R
VURxwDM2bTyPeArrlDNVP1KNUnvEVUgEaZ3roT/B3J7Av9pyzGd4+pRPQMsZmKeaxS0syWxz
p85n7Rnun8B0n7DbzNomlu3q8cdu/+3Q1JLDbfcPNaDcUDOHABsC7egwGsOTDZ5R+9v2EWfD
1d/aYSFDbdpJT8Yls710ImmM2vWUqwIStbZBgd+I/jASwghNV5SSb6ySJWbE+IzXhpPOPMuW
TviPmW7wbGG2v0Ooyv99/uy+5L9GZU5u6w5klvh983OzOlnsD+gvc2pe/UJ//h//YeulM8Ya
zd3SmMdH/sp3YJzO1HX8W7EMWfwb/6VYuvqLosJS2pI1TVZ/kRXdVPVfJPmvLETbnyccuJL0
C3hf+9mBfM+l/4f++fXVr2xFWBwiTv0BJK6COefvUmckDUcRknVHp5CZBSXOeEyiSqeR3t3i
iedLX/36ih9ghfwXQXT+R/bzhkGUfhc/gmEYTaZeFIyGccf3Rh1/UiSOptF4GsXd0WTgRuev
V3drUz+BEp2Y+ussjzvxeiDZ5T/PX+O1IVjqM67eSVqDGFwE/iSX7I+8q44/jsPpeDyaCAUO
I9e7iiau59fTeu61H/fdyB96v0ejBuHBYFr8GPp+J+4M3HjgjhE28itp4SVL7vvDy6hXpF36
Q38SeHEQupheT7iYXjY+jCc+FC6AMo5HeMHvJKxn6330g8ueUGTWhAP3d165sRd3O16ROvkY
+oP4xutdup1O7PYvR5Mg6g3quJ7bDy4mUEfojr77ewW/54Z4EQsr4E1DGnShO+1HcdDp+02i
rteDhg+G0CfBp8YcAO5OoU8mowu/0mGhH03H8dif8FwT3630Q5bkDy7gVzeYhFHs9abDq5Z8
Y/fSb87GyxNc+JOhy7R6PArD4KJWqXAajv1hpyH50wgqyW4LFkSmMCqZYA2G6V8Yj8ZRMICW
6cCQgmaC1WZbzo6PioI1cPswBipNxa6FjqOb2gCOw8G4/KymQ6lmxV63716G569P1mhpTvB+
pOXJfrmRyg+S6oPlz8qDRfWBXfntVH4rcvWBUrYUrPNQQ1ARfTesd0vaSlOWSxg+uY0BLQzB
Gp3dbeZnPKyWnP3XdOgOcsyz04qp4S07+S3+OJoIulJ/cjEN+h3oSD/2byIX1CIOuXV5hfb7
klnsO/51p7C3/g2oZYDkZ25ftKygMf7wGuqFRR6ASdbULNGbgNrF3mgwDkD1Xos20e1fg9kA
zcXHv0oNCWyYoX+NZJbI2yTW8goUHxTo8lMwrmhWmnIBKWpzUv+TaOvElJtPbRKjIqH86rzo
4nvFUlcz4NsPpd98Oizd1CSZVeuNwgg15Pz1G9wk/jZv8PCjK7RT+Ht4HYy92gP824uEzgWr
EdzEg9+m/tRvflqI5CXt9twhWNeGYjLzUrE2KA8GomqDPrpRyQixh9HE98U38af90WUwnAZg
kWBSZNrcpjT51OROOngFV6bwuC073+FeKHxD9urECSOrMhGISWFv9LGegvYY7CbmKI9RcEA8
MKxRDyaOTsmyhmN3EvplCQ8di3A0BRneWp1R1RaLWfB2+npZmA24rvVBPtcigH8NQ76h8kIi
NyjPZJmM3I7nhtHhbIMABn7nH9PGfIMRWswOd3BY17F9mklT70WBdxXDHAedIEANR3FPHOQw
kYA5DVlDTHKFAPN9Fs2Sb+yWnpwWOMG7TNJASuU9bL73vNF0GPGOy3UUO5a1cpHcoJ4XYQcV
yfPBXELGSESopsXXWgNC5IZX6PoJHYWPuJOUYYoJNw3PglG5Fqwx8NK7sKF9YTDGkCYWdQzP
BuMoZnfpNRgxeB5PQ3BufgsbqoCpXXcI7vi5qdcfgvvqds8VswyXpvlQnaj1nV1QO971jVmy
qsTMG2/MElyl1+bUiw32B/S/C6M96Ebnil0yOVNYePAJFhzLDtd0YQxfTkbTcSg2IX/EvaeG
l6XJXSjxJ7aGqQteB16TBcTrCX1RPVCn4jHYTZ5SLRU+LqsIjBNuS5iG8OGSv37gD7zLxqZL
4XrTSx+vPjuQBfyLbnudWQsWpem6wSQupxR4XbA3MAt9DDpRr1krIlG2MctF/yp9dXOZe753
xZY/2DDRaNLU6DgZg/H2RA9vClZuKPzGiVf8jV0i/h76Ef+dv5rrErpH7cUDm95FJxyGpAf2
stM03tL1U6nGoD/Mp5s0N4rn5UsAnK/YKqkBuupIwCAdAiysu0sVYS5l1DZdw5yuCGv47KdY
RXhJnM5eraWAt3j+mC2S2PgWPDkQC38fCG0Nc8W4Ly56xxPo4JLnLCT6/S6MhYnoGnnh+GoS
j2F1jOGEijfZmnoB3nzcnYpTcHca+cIC1h+PxNQwuBy6/a4wHNgEJj5g86n4IOzBGBW6JBiV
ugKXpJ1GPeFlB/Q4dwXYxJCGZ+p3/UkuzJgezpQwNxczRhkifXg94I9Eo5I3ZhD/Ng0mV8Iz
vAmWG8fSeIcVhhuBi3HVPBb67kWTegBWyRx2g35l9h7xp60eZZYuBJPSJ3g5O+8UQd/yxV7+
gn9MB+MYiuc36S+MtOrykL3V73YDL8BGg/VgH1QBrYGHDoLwronfLByAwmKcCBKrAaerRoFW
pLbiMd+TDbXeaHRVScQ4lBtFYj/D7JO7eLD6j3t+f9wYUsJEDNykLnIFeeJfgoM07PDAWtog
sTsOmkowDnItEtN6H0GJfJfb9UraILiBdi6SQ/bGSibm3UCDTSdDcDiioBuIClAdSagkTakN
wOw5Q+fV60wH1ZUva/dCoWrBq2uulKHbhSl8MMZYWxUhVSYeLGXBm0qOVI4v1FvSOqNpPRD1
0WVjnI1TnPH4iiaLATTkHfU7Qv66MqQL4qoqVJL9G9+7rlaCh2B8D+FjGKyR2Edtz7mOFQ5s
dVjV/fyWYTHE1RwOXvSIyk08GHWmfViN4IjAyQVn6Dwq442uT+aMWznb8LPfrTd3fDGSGxTM
lla+0RaWFsI4FLxRz8fiNBpI9yIYdoXYB7hNA5yYxDHPJq9wgAtIuVKRkoPIHvFFLqiP2zTT
pHmmQ0yvNksqmieKyKkehY1VTsXDiZdHlvrNjZPlbPTzQwzED1zvn5R9bXPbuJLuX1HNp3Oq
dnYs2ZaVveVbBfFFQsQ3E6Re8oXlcTQT10lsX9s5u/n3F90gRQDsprxTlUmEfggCINDobjS6
1zKzPtnSleg7EWqpnH3EKk4kLQP3wlcVrUpZHWwUfuECzlExxmb16+Vob6yirCQKOCLciixw
hWGhRZSsx1D7jIp7urUWU7kSDqGvsxKlHK1TDxRVZ6pCrcMTBNByQ6k2HutKtSy6b1S9JB5R
eaJbodBITJBr/eROrzSn2t7SGKaj7VcrSXe9TqpSN2n02TqjGrQRZSooQhQz7wK73Hwx+i6c
fy2jPNmz8ol6+HYEm7Etf8ncKA5ZnltbR1caajaaOFO7owTxnd2oztjYPTBij2SehAaMPNW+
9/a3h7/+38mCiccNemkWMkMWoDvtGtAMHTaDlj5GI5/d6VUXcQ/bRPdpZIimYXoF5rvM3jV6
Rd0s4VPQU7yIDJalv4734BVifafuZMaa6f6ZSFrg/ukWRvsqykI4PuoVjNPYA2ALkcGH4w6k
04GE1hHy8gDadVLbmo2ZCnkqK90nOIRoT/4sAVqUYitBsa4j5ViwTpTzhrB9ZK0L/UMLE+mF
W6JVsq0WsFe6Od2bbOp2vU3dolTsoRqhP5Dp3e31xYUNUEZ8RCXeGTN4Px5jxfTOstHaC7aB
6EnXaWKAYK6gaZageRaiLG+WeV4Zzc02tlTeW3vaZkGXFyqg+DQosDOnclHlKVnFyQ5b1Mw0
wimB2VDNSaqxic1tyEDyhMJkyj+wF2HooncFnmepxtYugIDyK5xQNbbhoGtYgqJbkBcHlwbS
VqE1GWPSUXXqkou5/gre+qtU4Ba0vfIcEMBivfVWrt7Q0jpFi3Gsd9jkYBk7AYATLqiSVFlr
C9B6iZpuDItFGg4LAzipq20JtogqXyXFsiitwddAS3dWr0JbNVnpHUjzZcfrQCsAuvgwWtxE
GVg/tdp06Ni7xVJ2Mq8SSwU3jxj1z1oCp9QqLi9SqV0XFqVW+ztbdJZnzqLuyrd5ormQbik5
1VsUM81R+wEl0psFYD8fFJZRmestAs1lyzLfaKYCS7pxj5RwbgTRoMD/5F2x88m7QlCG1DpP
HPmvr+hzFHA9qrQSoEV4rZAFmgvaj8vFhmIbMihz8KOxRbW2yG9yT3Aa3ReDqoecIxaDEbBX
Aa6oopZWJahUFeuDVvTDsGwq3yvI+O2Axk+SQ1nqDjerJehhts21trdf3WyvpPVVgLAiHgVt
nHBgp0UBGNRmYPQEPCw5ylxsHnZ5oNFWcb/XfL9dUV4Pe/JglbXKbgL9bDd3reYMzAN4GrCB
zaDR4oz1vEz0XqtnRrvfN1uR1NEt3Ea+7+Jv4n+9/jzyqr6dqchqQVGsoQRXGM2aKlmAPa0d
x45xoUnGvEQvVhXZ9hprtPZVqf9Bkbb6f2AI8we0R6DjSmNaWzRVvorgi47UNWyepx46xdil
xnnMTFepAlGG9uP2zg89bu3UpNixitAv5iQO2u1NtPhWVEZlAJ562nlQgQg8XU2uSuEWjay0
Tmpt4O2305N+omU9e1EbOVBLNbX1MYHtW9ayXr5S6YiegF/PnBeH5S3egHUnPSvT+sPZUpjD
waHFhjqkQleXtj5RVQLdF3oLdRJpxRxEHPIlcZlnFThpMOwZJZMGEh7AgUNZF+5nAQjsKSBF
pl0jeqB53N+VtCwETob5zhJA0qp0PgD81uJxprVPrcUwjTOapz3yWqLSSj6o4Nhln1/rEdXy
uNse5awDrRHbzQAFWVU1acQ35jpnrANjIwULN25ntCHsSzO9uKAM+1+a2fWFXaEuuXShXi10
Nbe6Glc+WZfgLWBZBMA8aYlOpVBrz7ILK06CtKG7pJWJU276jl5GIIxULgs7PYQC8fChln0A
D7gdHqNsQ5WTnQ1SVPhhqlHHFfhtDTf1+JRllFFoygYZFfdBZIG4oRv9+Pm/j6+TH3g1FPLw
oYaMwbueX8Dy9WabOlvfRmrsW8dIUEOSZCmMqtV/tN5vkuKgaaOSKLK/QVvS6uG9kJjiISzS
aCkybXZiE6GuxwFK0IVTiqUUqfcyzikABshaYiCUwHYeO522ivVevovoVYGoKDCviikvjVM9
5gxj8AoR8BUvNWOMXInbIddV5dkZoTgWGV9lqMeWp7Z+MwwLQIgsUsk1qBXt3AeCWmkFuQlV
SAnTpiOJnnLgv9kcIlHeXvht9r+j1+hAc7sk50R1PRE6Jc5rmN5DhF6fI51VS3oeIpFzhLB7
nWoRKB+BLVclbZYwc6OIJElVsVPeOWFBSjuThXHy9nDvH3WgCl1GdzSv0kTpuSH2jQFOBeKl
OuHg/FmLmeGgGSa16eQFOdPb/b/h0qrdCnmj94bBqxCx/PnW8a3JPyCezPH94T//adntA2vZ
wlc36ohb1iXscksdOxk+igYu9/Q8AvHHCFo972tZPzwDEIrv6GLhzi8o0myhpNd2+wCvYSJA
efysLWO5mgXoVJrhw8jJwH7HNwxhWreE6x0Z6RrlSYvK+yqmwK4UTMmoG7S7ne+p7GAZwQWN
lYGEIx+U/vROZukJlWtjhnqMb59Ttcy39MCBkdR9uhBKhsPnMXEVXYV3EtNeEnEP1FEzXrrV
gu5C7cn9xOPmowlnTElZFiiAhXQOpNYFPVVL3fxQ5oOlGv3P8eGnibGDV3HN5eq3yR+T6AdG
5jCyR6fUyCxOKziitYS31geFIOH86gmt/AsuVIWM7BrgsArO7zsNB8DrSISer505Ts5raqm1
r0mlbaGEml2xUorLWWv3886ckOJX7hiT9pcz4sWnIyh3PMDqVYOppDPNWupo63XuP7mJDmpQ
iH0Gy4Re8ptoeCIC6wimZ164rnOdZJmZi8+YXvzF+5xa891E3okFlGh+LCjOBCeLNhp+c9h9
bDt6wS+83OQVgWHasdlBoaqXurOJDGgTJWKMjk5zP1NJpb+w0moHvfGDc6Eeb6LhMrN9QmVh
LDGtA3c/W4rTmXODZk5a+NCwIqNlZGiBLOQYcQXrQk/WPVd3iq9mtvqC4kbqoLXiPN9I1zYH
nW4E7TKKtEjRDZWmpTBreTp+kKrOMtLbCyGGOmiS+dagKxlzRM5IWT548C4OuYwiipsgKinz
QYOY2V4FBYihK9IR4URcknvOiRzUS7ShDx/cRara5Yz8eUKtId7bOEKdhxy0ED8O2UYrQa+q
EwQ8U/0bKUNUcqYtWs+ixYsTQqsZ9KQ9IWSiVfdcUhrd6bTeH/eOUHrv98jdO25/e/j55+PD
b/YHTcNrZcuustjOXf6xneOJrmC4HAIMZwE7b8yDjF8ysLomJL2LYOLO9eq2WoMlek3783s+
upbhbaks5uzCmnNL3UON8oI5ter9tvtrnafDCh92s6fjGLe+3ZxpBHuuZDX4grqsmZNiH5Iz
MGmjrac6FNHg6bFxAvqKMc2aD9EdEKANjF6PBjjYJPpNBo6TwZSYitIxt3ekYn1ApVvvpmlB
ey5o6Mll0H7eFLJaTo+wWGYny5UyXEVOzUbzhHztWqDRkirksWXux/c163/pxe93zCXiFSFu
D/agePNvtC8dMrHvpGXgLZ9l4Bm8oUubwfjbxPb7UC+2YUPTl0M2nrd0T20cfG5OCh4AcV6w
0AqdrfMmDJhdxwapoDoPqkM4yqFXhdM4oXXekN7HHFw88tITaH05uzyPkoyVwAHpCYKnGYzL
pvvds5Gx7T978ZEuKJF9YNQUJ446390bM+czUUvOJoxPr9M6Agf7PSWd9xBzgft0KWN/Ckv7
489HCKLR3h2n+IJWptoFR5Ggpy3Zqfn9/vXv47tjA3Oeq0S5AikaLuee6V6P7lxvPv5AIpSS
MS00kA+03fnwA6HiVisBXtPbFwn9X7UCDIto7j0zCTq8y3EJwMgXbxFZbCoZbVcWD3aBUTxo
qZzLGoXX6A/2uN+2x6oLilSpc53SKC0Bqap0178z/TGi4sh6qoI1Hkj7kg4BC5JacRozBc/T
lHbUJ8FZtjxUkWLGpUeZoA3nUCND3IO6rX20FwV9N5iA8vslgY22/GVICv+h1W2wUUAfQFFQ
xj5AQNdCrXHsP/wAOsZ9GE3pFQROFlq3sC+hEBg/cBAFOTuLUhGcoZ+ZYUbSN0rQWM+z+AOy
7AmdK1qnpKA77nCNAI9Y7ij0+qD0FP4wfFMBf/ko/K7OK0YIHII/zKlbeCQSykuHhAbeiTEB
8uXfEWQb6Wq0ts78+dHuAPPP6MNZAm22lQ+jvXP+MWx9SUeRkQWEmeJIWzXYt2TxXx/QFWOw
5pQCVeUrRjkbIaE/wMlkb7dIwzh10VBlcRJgvefavZSxxloQjj/bmLIwI3wWWFWkQQYR/p1A
U9pJONFn5/DWIda+SBU3Gd5s3F6xb9Oq2yqJhuNykoBRemBUFQc6PkCd8FNxJhgAlWI3QhVl
MTS/tNPv3/P/7QSc8xPQjukHjvnc/Jl/YAJZmKiW86vzMGjgeRSIkOdR5P7sIKC75vSP7Vv6
gb6dmfk2kuMrc2uajLV7uD7mowtkzk3z+diU69cObYHtzGZxEy1HjYK8gAlclrPDlCFj9JfM
mbOoaLU2mZE7naqso03Tl4FJUK5S3UK4R+cFLMCzGSWIareJyJrFxWzqXMnrS5vVtqQ7HGr2
QZ4OJYlzXKB/cnsWfXInKpHQmvB+dk0PmSjo27M73Y2R88dinWfcrhlFEQzANcWIYTi76DLI
zu5+Hn8eH5/+/qO9YOm5JLX4JljSXkkdfV3R3TjRY8VKLAgoSkkfCXUAFJbHG1Ey/l4dXcXj
jVTxeP1VdMdaRQxgyYreSF+da2GoxmwpCNF/R6xVyVRSsjK9Gcm7s4MdrPMNK9kh4u7MWME9
mPHBiu8+ANLcoIx4gdRMHe/igJm/3yFH6V+PD8NDBC1o+IYTKIJ7/7xYjYgqkFkY0Wu/w+Ci
pbfeDhIz20BL5iTl0xvUlncu6AD0TnJqQZKPt2EYJ8oCRKkbzLAvM37qcLPNqbElBpzZu4eg
ieccaGyAWkga8fphhwHnG6aHMAQi8DU7KDJqMN9EgKy40G0dIJXlGCcAiCzGq9ACwyi9iEas
1YhQcuRzIGCzPFtJ4Jm4/TUuY8fVIgwoz8EwUxiLDQKl2uilFjQExoAg25AXUbZVO6m/JVFp
aftNlTGGGnTuHRY+EwCuyE/85Z3jxbIs4uazOzi2W9bk/fj2TuylxaZaRazxDdRvjEBEAtYi
LUXIcO6A8SmXJXNatmTcmrWYui8ZwW8nIVIvw453MhU0ayzjjWQClECnPzHx6ISkd9MgKsA8
x+zlMeWKg8527SfrJJ/QpNkLXx//baJK9LGCHx/a4knuu9bVJriXMV3CTaH17W8mAde35/eX
7z/74MVhtK3Swj247cqaFCIGkLIyHG8muR22oijNO2NZphj/wwtOGu8w/IwTpaGDyqyNndPT
4AahOCGsIMbqoJr1QXdrK5V7Zda6J9/GY6SnAPgrqrWuNYQAkrEru548yLvE9tbSyOHmWx4U
M8+I3X1xrTF393hPg9Jd2HCD8lQ0Wy20Qp+TkfmKzL4Yk7WRKvUGolR7hbYLdIGJPm0vy6xw
L6q0EW8cNtEGwYn5kIxABr9upULdfFlczvb0MsL4jcVdwy3olhxIpcYw6Fgqgk9z+gJYB6lT
RszsAEG+wxMcJoqLASVOaBa7FC86YuCM2wVReXkoqjyh46qcelEurWUAv5o24Ar67Xt+wN1T
2XL8W2RbxqjZAdSeDkjR0UtBD1wQlnkKO0AQbpkbJ5Vocr0JNhET5RN87PVrbB97YnwsFFwV
M474g2aux4ehXBJXRyDJF7F8VZRpjqEgwvtlsr2Y0TXLZdoIRY9NsRYZF6XDhLpIZdgUFXPb
ZgWu/wEtdVcyTtFhnKRGWZDkqi4h2UHJc7Z10ciE3nm3LVOGCxQ5vQkXeCBSM7FiZz5nMg78
kWZx6eTt5wtkArNH21CaT5fBnpbyg+XN9GLQZRNe+vg/928T+fT2/vrzB4a2fPt2D/mm3l/v
n97gTZPvj0/HyVf9pR9f4J/dxijA2nk/iYuVgBSAPzCN5tfn/36CXJmtU0bPG00IudC1goXD
9qhAyVPC21NXu8+qieDLZ1dSCj0PMN4itXsG9lUXfNwNOwQl1cqR67GsdWJhqjSbTXzaC7DR
bWtN3KN/6PH6139M3u9fjv8xCcLf9fexrkWdGIcb03ddmlJaEOvIuSKj8ZzqLIfsVZXgYRva
2+XpZSuyCQHNbswHAMNLk9RkYDAA6H+D2OJuxEhJ8tWKO3xCgApAvleHLKBnRtXNyjdvVii4
fNdG3XSrjIPh9HAREv9/BqSE+ghEi6GK8Zk2mLIYna1wXT3RYozrIW/mKWfKRSpGXMGYyPzL
g/1qeWnw46Crc6Bltp99BLPXw58zu2c04yvoZu7lrtnr/3CVcyO2LpQYfHX94Kc9Izd1gNEP
JfxbXh5ZBH6bPIAMbkYb0AIgNsw46NOZWj5djQHS7Wg3022djnzDsNDC04ze58z7wadXT7sR
RBmkijZAptFKIP/Ooh2nBZ8wEKQloDwFTwjd0cE8SItqNjoAdazWwcgXWEOACSYCOc7yWkF+
Dlo/bkWBYstOdM0vYvpZpDBrZ5TQxBnTnHYD3F9OP01HuhwJxlZm+GldgXRkruPysBUXmL5j
uSOzThZj3BpidYzMSE0XUyaYhWHBFWOxNdRDen0ZLPTCpG2KbQPpCY3EO5wPzXS2GGnEXaJV
7pGvBPQz/DUpxioIg8tP1/8zTr+gJQ1DZ6/wGwkoPcP/inRxcTEd3QhHFlU8PjrhyNTKVWjm
iPACo/Q6lc0lQMXKjMAS0vd6AaF1sGUOMYvL0paigOSq/AqKCry72d5kwEylmL8Yc94/PT/9
ruJ48nT//vjvY58M2JJnsNZ14NcKRWTkS6TqLgfT+YyZ2aahEHMJauExSiYz6pgQaXF8Enh1
Bx78nrXJm0PI/mT1qld6Qi2JhUxuKHz7neJi2ZjG7bmmLVMj1pvGAfsiW4gwu0n4saQcGTTI
n7MUGRN2HxApbYxGWjZCA51NKpqNd99ijMiwSCRu6cMcJNbJyPffypHPs5VVpNRQZys+PuAF
TkSmBYaYcgY7IJZCaQUhoO3ALaRitmtDrvTnHqUXi/kNPSEQEKTh/GqMrq6vZzTjP9Evz9Fp
Nd7QDwV7AIqAKBaMiwDO56K6nI9UD/Sx7gN9P2OsGicAfYkG6bJazKbn6CMN+IxRFUcakIpS
q0/00kGA1u2DcYDMPgvmSNEA1OLmako7cCBAy/QsWzEALVVyrBABmlnOLmZjXwLYKac7IADO
hjjJ3ABCJtoJ8pBgOmOkqJZO78GGCJHXSgxhOwKSyZwRkYoxFofEKldruRwZwKqUccIIesUY
q0PiTmbLPBsaPAuZ//789P2Xz+4GPA7ZxEXDhfIwM3V8jphZNjJAOWf+NF/3ix+3zTnP+uv+
+/c/7x/+Nflj8v349/3Dr8nX08GXxxK5oCVAbE+C+Gbwals4NFQ50VNNAqgwqiL34F0TIEib
oIQ7TQOx9MKpBkqmw5Ih6Oraubpt4kFAzJKWSCuoXQhPwSg8aXsKQQ3C6eTCEehCImaQTcTD
EKI2TVKZKNqEgPYT1VpCXPF8KyE9BGeCC1P0RGBkME1lzDCa8iVyYyhAVaOjgn1MBH1/QBPN
uSpHjRPhBfWwqZr3eOklTtTTXTnG/B/XyrsZbpx8oyiaTC8/XU3+ET++Hnf6zz8pU3wsywgO
xem6W6LWNxQTC4AxtaQikBmwvCYsJeT4ID6C3tbao1jXEcfN3wVcDTwqf1gDVqcp3Zzortay
2hf+SkhDHq6n0gmAJEe87KqIORvTPQbPTdqqsvcofYX6XypP3Ls+bWIx+71QBCEHOIcmpOvf
Van/YZ+jV7VzhLjlzuVE6XuUmlkCLgz9yUrPcbsBh/C7WTTwMzLW++YyYE7ELIwIRaE55llY
UkWMFGWjGGHchkCTc2ZCdiCTGjV3mNzyitLmwGjsnEh4tqzuO8hVnl061YG1+VxjdTsCEfLO
WoFI9lEomv0qZaI8WpUF6yhRI36THUyqgAaFnMeu9XR4/lOG/kkVBYJIWCOOih1qz+gOFmbN
LZqW3sVG77kIHYUWiq0tGH/auVlWTtQ1/bPh7r9r2pYJm7Jf0bwHCEzIDaAw1dm9XMyuGbO7
LHzB60T6zF+P6ioeU19smMaILD/7RUFbGnGp7VCHkhbx4kgk2dmXZKJSEXOMYMO2MmSEbguV
b+iKIC4nvxbaeGZRtpJc/IP+FXcDi/0QA7f+qsi567vQAgBzBgekKqdiCJWL6fwTw885BcyC
qIgJ/2ljJLdTOiDGYMTYWe1H0xFf/Q5ToV5+FlafbWgVrWtGr7FRZxGcfmdBdvILx4LjMGSC
MMqCUYfQx3XJBMsu1odELjsTpZaQJrqkc3QgNC9RLS4u9/AYLV9opYKjtRyEpYdCS4ngeMTQ
72Ats9QEAhQytEDq3VWw5NZ+yNJhnrHEToTgAUG6uNnzQyaDIqkVS27XO0s30bQFP6yq0lsY
Y1pM4FStml5Mp3wHDadmyTEm52QfDmXeLGW1FIxqVxTMcUtCRIKo1fLktyy+3r+8e5NT07Wo
VNFMAYgbseMkYyAXEFeupvkR0MsqWUyv6S0U6PoPt26BLIs19/adxymNZ9UThkXdPYK/8j+G
cTT/OXl/1ujj5P1bhyJW7I7hweB8Z3Szcy56LYpw0dume02kraZShYS++vTy8531o5JZUXuh
0nRBE8cQ1d7353YgoBgZj1an2OQJ2ZgMB16tqYB0gkAbzrO34+t3CIB/Oi968xoJftEq8nxo
XUpTKOEGzqRhSi8vPcj72+nF7Gocc7i9mS/8933OD178AoccbclWRtslcRnJfJ6Bw7nz5CY6
LHNRWhaxrkRvDpulMz9OlGSzYbxZT5As2lWM5nfCwE0KsBswSeE6mKryndgxNpweVWdnGwX+
3rS35gmyr7xahp/QMujlmIdBzYgirfvaV0H6cpAK9d9FQRHVIdOKtQzoJ2UcLZ1U0D0Nb3Z3
6ZZ7hn2iR5olaYWdsR32749Ar5I0z7XeltfBesNc0jEwFZVScOlhASCKIomwohGQ3m6vP93Q
38wgtmq/3wtaCGtb0o0psG2auXVLDyJc0EqugeA1aC5kLAKgP2Z985PIxJT2nhThzZQ58WuZ
Ima9HwGIKhGqWVZMLLgOBFHX07yKmDvGHVfA1FsGOdYoiBufcpGTDeagZR7OdmAQQTq9+DRC
r/GvsV6F++RydPSCVFzSMrOhw86oV74XRh7Z6Pr+9Su6Hcs/8onvFapnuRWEGn9qrf3iauYX
6v/7MXcMIagWs+CGOYExkCIAjkG03ZC1yG94kPcYd/HfUEEQLUXjVey/Wc3AwE4iViKNSB/y
4Nv96/0DRKnonfY7EcOJbI5WVBOU1QRQt9jetuoAVJmfWma9I9F9MQR0D51k4hBt/NOiKaqD
f1eqgOwFXThUiU47nIO+OXfCSpjPo2V5y/HH8SnPwZjAxqAODkEiQua9ab4XxgaWMLZBRMC9
btaN7ZAF7LrsiMxdzY7crBjTYv4lZyw1knE2y5p1mDAGgGbF3N+AXQ/yjLu9wEm4CZ5ffvUT
b4P5Sn8433nD3TXSXysJy+2gTnV8fbz/PjSot995YfJdDQvd2142YTBptQLWRKJMDvp346Tx
c+pz3LYsQlY2tf7kTpZPi9wmSWoxVxSESHdnUVOR6dkO+T1oOl7Dc3Nu2GRzzMrTS3Xyr8qe
n36HMj36OOh4lEGchbWPp3HYrBWVDLIFuAdUVqH1DfxKPzPTriWrIMgYVbxF6MFeRmUomMjl
LarlxJ8rsYIP8wHoORjc/DmH2Uu9gveaww+QHU/dBu1BoMVndZnz9aDASaLTFhDJWCBDVLPW
fDDxI/GAIUhksr1ZSe3RADHnjlSGUyS72WWwaAcX7sOcizUErwX5JY9jqvu7PsFeb5frCk3u
KJl7LGQA83K49gQnh2tfvJV2EtRtKZzXl5efmPhKIE1L7uAu3XGZfbSI0H5jqheFe0aISY5T
T8XuqSJbmfyKgzirPb8O9J+C4eVRgkm7iYbAnuzJTnLGOO5yqW/UMDNWUSiKoxSuX/gJ+jf4
tNy/P7++WU8ZalVMHr4/P/zLJ7Q2H1cFn/z+f7E+y9zTV9Aag/6z31ww681Oa2/oiYPGwVUh
c2Pn7YUxU0Sbo2gHaZz7mK8pYZI3I0BsKdFmvUvde65YoKcvrYIbqrnjHKwJY2BmHJUJi1d3
y1MsZVWv6pIOezpA0WasDrZZVBEn23SQ6cVZTCzS6fV6JA9gB5TXEEOc/jynym6mi4tr+kzQ
xixmMeMy34JgVzvbdLlMBSf+9JCCu8TQQarFzSggFfvpp3FIVgUmb7bkHbNbaBEsbi6ZG+Q2
5mo2/kol1fX1J9q18oRJVXB1kzKXCxzQ8vJMF1Wwvp7v98TF9QFUbwAQ8ODs99O4+WLO+FF3
mGo6m453YKu1z8txyG5xOZ/drMcnpgFFZ1Bo81Hp8Nolev+NLX5M6Hh2mYlqczFlVOk2NTvN
IQlBoasaThJypaTJDGv0gOenx4e3iXr8/vjw/DRZ3j/86+X7/ZNzD0EpKubMMkjFoLrl6/P9
14fnH5O3l+MDBI+aaFbhOLTDY4MxS39+f3/86+fTA+wYI4d8IBqznmhAVOk1c4dmrZcmZLwL
aG4KD1cpo1+K5f76Yngf3G0WuKEzIeqKgPX+BZrk7Ia62jIMLjn3bqB/FtmXJkhzLqoNYLb7
xTXdsjJaQb43hlWlUahXcJsFcfDNVq/3L99g7hByh1hRPi/bFdw2WFpmDVMAnFXv+rW6nc77
OoBoYhNpsZbxByo5pRfzpNWJWjIRB1YCQwXTRBlGeZPXFRrbcvRpI4GMm160P2S5MtWQgCWm
gl2tqyYJQmp8BzhMbdBqDdZFqbfn7xhoQK/Yzht5eHYF4zjQzXUhaOUqjyHMFDjtLZ0ULDRd
bzZfIis3ODpCkkpnXhO+4GstUQ2at5a28iBDLcbbNdVr0oFWl3ae1CdOBhxHa9fwwMCsAXhx
BacGjqAHpUFJHoYhDXj84IEaTr6ZJ5ZRspGZ0yFweyvLg1+mNZzMLzQ3VfwX6iFZ5VnJXX0C
SJRqeYrU/ID4ZRMd/ErXORzesxXqJ/jzDAQc+NbUAX/BF+g7rfozV47wux7KQbYpB1DtZLYm
HVpN0zMls5WXNhooScBvu0iPsnyba62OPjdDiO4YNYu68ib8TLP5jh7TUgXQyzrVO2khwtkY
avXp6mKMvltHUTIyG9DrCNa1O/dSMHGUw3mCxuPxqaAZpKSleKBq1jYyzwqtDOrlkeRM6ADE
RJVIDoxTHQL0WkqYK+lIL9nAakAu8yBgYgGu8ZK8HOuBEqmqGR8SpOtlzhOLKOK9URFRZ+CF
wy8WOJ/TYg0tPWMNYDj/nB9Gq6nklt6rkJgXKmKiLSJ9XdaqSgWbuQRAcN9htAlfDqFgL6ph
R1AybrwoQCf/G3J3Ae8Wf4fR88UqaBGOjwaUoa1iLVSTOxeLHVLEk/YDUrvPu4VGi2LqWAdu
O10YWiC8J7NMb7wB5IfbNf3dhlPkqeN3EO2ff77hgPVJb/vdFuo9ZEIzCYguljPBWwDGKX9A
22HXliKmP9Tz27t1zdty53AqCeY3ey10c7EmAAKD7AMsctSSHXmiKy8h/IueS03F+0UhsIIM
XTsM+cwC8309m16si9HWSlVMp/P9WczNfLzXgNEa6kjHc6bjXfnpUvx4zz+ExDqXIPZmWlsA
wxjj+0qBU0/j8qGJrKokatHuXK+ZPqpkMZ2Ojl+5EPP59aebURBY9rQAP1RVYQa3RlCMkEyp
qbgWA37M9IaUcbwS10/IP1sRJocsr6L/mmDvtS4nVpFWoV+OT1/fJlqbxpgYf/58n/RBtCY/
7n91dt3772/Pkz+Pk6fj8evx6/9BO65d0/r4/QVyn09+QIrJx6e/nl3u2uIGn8EUj1zLs1Gt
L+lZXCgqEQta7bJxsd4VuRMEGydVyN3ZtWH634yAYKNUGJaM74cPY9RxG/a5TvFe4lmgSETN
BKu0YRDtnhXjbOBGlMw9axvV6ipwpTU4/z20ptbUy/nseni9FtaT/HH/N7iPEoERcasJg8XI
V0KJ1ps9p6q9a2Nu6wZ+XafH3N2SeT5K5Zz2OGmpM/oCLLKHsK6Y7OWmaVsV8eumlPn1yIgk
0SqvWFUHESOsLxnZ6LrPHhxugjltSTMwNFHyW1iI/mwsPa5CiX5+/PiBah7qrZC7EYujKJX+
a7vipzMTDgAZbQm+Mlu5LFkDGXYl34lSfw8eUXGps8xmDgYeJp49AA51yRxc4CT7gsO1n5Gz
uPj26+3x4f77JLn/BS5Mw2mMYYM1lJ/GKxGuiIuZebWagCPy6/H7/fsRHJL/er2HmJgP7z9f
HetxlhdGWAsiSUd3qXc0B0lTxnkzSgfejd3LtOCr54Xl0gG/jP2sk4RhfhND0QKjbd6kgokk
gxgTTVWpK27rQFRejZJBZ15595JPrateH//+27/fEmhhXsmlTLib2lL/P5NLQbrLR6E4WcrK
I3BFYLhvP/98+/X2fvxhX6nVyM4ZDMMjOlcTgcglrm6JkJOiSYNo8FyKLg+0gcQAUvybqLqs
gsYcE1sF3Vftzdm6cB1UORfEA+iDxpshgbsZhE89PKG/d3waCb8cApsSxZ5ru13e1DLC26V8
E8vtgGkYE2chsaVf3YjrhV6CWkL74dG8GoM0HwwWlIdqOlvQG5UFuWYO32zINb0hWJCbK5rR
dBBVbaY3laCjQ3eg9GpRnWkwQJjDGBtyTUtrJ4hK57MzLV7eXS0uxiFlcR0wh1IdZHt5wYRA
6gdvdnVxNZgRz0+/Q/ZU8sOHqehtAKcK+1JmKUCUnXAoiPUxpEPuqreByFxUXKQecCJr2DA+
YD5laKLej272zOnXNnYJ2KHto2Z+z9QWsJXgYsrGoGnJvtLamlceXp/fnv96n6x/vRxff99O
/v55fHunDsdMhoBBDfvjE3uGg/HITXjsntlAoQpKOOpq4+xbBGA00bYK1t4D/V2pvjD2njVZ
GynKIMGBRdN/lrUinOWAuMrgptbtD6esBE8gaCj0LOiJaifzKlm6znjwhP4w9n0vpzatU2+D
1DEHQDHsOQnjNqcq4QdX7p5czE+Wj4ZYRHAZDzKPcccYcf1ZVqr+CGTkHsa6MClX6NUiMqFy
8DQceQlEsdkUIuRDEnXuButQFJRzVBRFRfcKZwTAi2HHOEaDwbgS5WjLTDiqZlmNJTfBtwQp
k0yl5TdM7FMIll8yCSz3+fS6wQtI9KAYm/5Y+zvIHeOigfpJs0pdHc+9hKFeHp/QU27AuoNk
oxcvxky4tHxD4WcDjoXWzYNks0zCATJP01q3QfpFAyM03ItGElGEqXLdeX8ibak7HJp7l2ZC
2/cdzaZgXjHYK6CuMDJJJ8g8GDYwTvKiODQ7Jx6pLO/gcg9xW7I8/nh+P768Pj90Izz5R7TX
3EtC0nSR/NNxcqkiiJQf6UkDMt2wspcfb39/oB7YJKigQ/3CRY4Sl0yYgmgPMXk4vScvGdmf
2wBTSHbDNGSXDnoZd3kJCKN8FFKKxSlRjm6duc7awWPZbEXp3UhJkqZc0n6PYRAuBcWDwlTK
0JVh5EjkdhPeXS5jSPiT0Qr+Ks9Xen12jSfG4ftxMlCNwkAE66jZ5XClFPUxq7v7atZ4ypIp
avYQv5772AYhKX8ZTb1sYvcdl91q0Spk3uiGRKV9waF9xLzSawsSilzJvW48zRc7lIqC2o8I
1kOu/EZdca+8+tArr7hXuiBO7fzsXu3VP8egMw87Y8GQZGqJX9xRmyKpIsiGxsy+zwNSt+cg
wZFPdAmfh31/dugAwVyMABJvel/Fasa1f1mNdC6TycijXINPHxG2HnvqxDKJcD9zbrPFKssr
GVvOMaFfIE1BUyv3/kUsDIF4Ow50XwP+7LKWOBcxev4IpzQtUDMJNgigQXCzyFCrMnLqvovT
qtlOKTxSZl5LgyoZlvTp1U9aUpXHyl2eMdwbduddUBMxiYP7h2+uxhcrnPxDJGZn+QNSMAGb
HHBJrRp8ms8vnFZ8zhMZWS39okFuo+ow9uaV0UZz9Ucsqj+yin6ZpjkvSpV+winZ+hD43Ykc
YKsC7en26vKGoss8WEOkhur2t8e358Xi+tPv09+s9VAN1oqxyLwdf359nvxFtbhPhWMXbNpL
Xdbs06Xb1Pc5tal6CzTzwn0I+gPH85IO5+5ZsgYZ9kx6vXHOYzCDfa3TW+qVXldL+y1tEbbN
mYr4F8cy4Xo5Mgnd5ipKXVE05NmUiHlahLFAOeqaf1CTMB4Oxzcj/tHlSHN4klZbGUpQipRL
W3NXC7VmiNs9/7ZUZvqDM8Q8HRmXgqfdZfurUeqcp5ZjLy3gZJG5iXhQW+6xmptpeiOA4Mve
ZOuIsctR4LfNofG3E1vRlDD7IBKvfLjaMZfRDLyhDYhABAbf2uvDjOxcCzJ5LAHktD10fw27
EhJ98ehUZErY2K268afpuNUu3wFKK9VlEfi/m5Vr6G9LeQkHM5ySXzqQ3mYoYfBB0aUrAvIu
EhutLoFTFn1+jqi6CARjx0A6rwYgGTtDW5IN/QOvUClzkpcFBbcm9BYoeEbKrZfEnkOJ6jbM
299+vv+1+M2mdFtso7dYZ2LZtJtL+taRC7qhTfoOaHFNRcbwIDO2IdxNCQ/0gdYumMtdHohZ
1y6I+aguiD598UBMXnUX9JEhYHIieCD6gMUBfWKSN7ggJriZV9MHxunT1QfatGDi9ABIS64g
BzaLc9NsamIo0G/QREr6B4xQgZTu6ureOaWLB9O5I/BTokOc7yc/GToE//06BL9cOgT/UU59
P9+Z6fneMEkoALLJ5aJhovl2ZNpyBeRUBCCycHFFW0QQQYT8MxCtjNZcZNAOVOaikudedihl
wkXA6kArwQbJOkG08srES24RMgBnHSb0dYfJaibKljN85zpV1eVGKipfPSDqKl50bg6b4+vT
8fvk2/3Dv0we+U55wUgrsryLE7FSQ5M46v3m6r9lgmgVwjarNQjnJuvklSXLZ2D6RluBxhdl
FIgqIp0xDDCtVdVgnAFLOdWivanidnZxZcXUSwXkSNOyaUnbjVVVygKyA0NCNkb6zSBqH9CX
eUIaWvFSuysfrSNIjK5MO2m7LT6lTL5o0NlSuII6AjVyKC3XY+wMXU2ek8dRDr3ZiqSObi+s
QUjq1jG+4e4mA2Ig7nV9hZy7bRsxsKNwwhmboI1NGdQNhqcjI02Yx/WfNgOaPYVMWnQw4mPC
NctwcwqMYL5/W73zIRwK8WJoFqSXh4g/GK4lyuvqdm6NTrIJKyrEB1jR4LFg0wYh8lcEjktc
Z+YLI6jkqKtSaNH7I5i4QC+X0dc0KSY4p4DdPYUYgX4tztN6JeZ2XEiEgPVEmKwGWluAYVV+
JZoTOxf3oDBoazNVW3aUElJOrKzB678cvoKe75BhJIzQ2x2yZcARGs4Nevm0XR7LdSLg2G8E
IapcVzG/0gs2iVnXRMwojNlL5rz/ohIp3IHnFhJO6s0qXHojaMr1OuhYX29W0m9qNpqTVUyc
dmByAfoM0MFq4Ny+yzwI+X1r+zwKQlG1zN05prDKm3C5orXw7kDUTyVmdwwcQ5gVJHOTvKWp
DkXUXOwXF5ptMbQovJ3StBr/fTujqVmeRbeXAxq+zD4v7QmMo+8JUfMJZ04YeCvJBjsDqtXE
vs8Q/yWVX8AfMJGZMf+3cckefr4+vv+ybie1t83fWoq1kQtlriTjBXK1lnF1e3XTt3FVwk6j
IsqhEMJCOrMgQ7tghFdf2SiurZbemmw5YHeUpVdjpODEyEzbUewokTvoxKPxak9mNmrHv2+L
CIbSTEe9/e2ksu8h6wfYaixuaLiBG3bMlMEqLg5+6d5J+YlFxZ1fYpgLMFPr5h1+hLybDMHr
r5f358kD3Dx5fp18O35/Ob5aXhIIbkSycjwdnOLZsFwLNGThELpMNgHExi55yvAhMBKRhUNo
ma2GhQWc6gyLtWis5c5hS9pyNweMIcG+TlnAnAebUCqURoH5KqKWVTydLTh31RaT1ZxVqusT
k4CrpYPt9a6O6oh4P/5FSdHdp6urtV69xJOkD634+f7t+PT++IBu69HTA8wxiDqC+TfF29vz
wyOSwvv3e/s4rGsOc6+rG61xsoru5ND1b4leQD+ev9qux937llTXAs6S2JFJ06chRsGSqDEp
6TsIpy+4pJXElr5339g6Or19Y3q1TgXVrf2Zt2w911NzRPj49/HtfThwZXA5CwbrxRQPk+50
38+38XqLJrwarsDwmqhIC1lrgR6zoz0q01Avr3MIxpTYI2ZMrr0ecTmj7KLdtFyL6aBfUNgo
paJLijRzU//1hOspY8RuF+WqnH4aReyKM1XgN2qCRDOlJpPmUw5mRfD48s31qes4PcXkdCkK
j4x91EJRLxzgsnopR1agloCviEbobXcXS+6IwcV8oLWBgJxHTGQAD/Oh6lRFG89sQCO2+w9W
NjpjEcBU5iJD8oPGgx3HR2zW4ougBeBuMotECcYv34V8oMdsBIUTvSy4/I0uRK/JaPahNxr4
x75IFY1OlGqXn5uaLeQj73KQzSWXEcGD0x1pgyH9eHk9vr3pjZzYs7W4m3DRnlrIFy7iZLc9
fhn6/Jf3T1+ff0yynz/+PL6aPLH373QLRKZkExQl40JkCWyovvMHjR5QtWLoGHhNb+xaCk/T
CDQT0GRQP+MU283WCt4MDq6Y5RKD9NhLT8PIN23XuYIgCvTkXspMlK0CPgwYkTz++Xr/+mvy
+vzz/fHJuZqF+oOtVyylVs/B79ZSU9ogUaC5Z1pTgesJaec2RkCSKGOo4EoK/qK6J0vbdNfR
i0CCkcD2gO1IbLHLt7SGFciKlpKD6dwHV9OLUNJxgIAsq7ph6rr0lAVdQFqDXEAig2h5WBCP
Ggq34hEiyh2/AAGxZExemvr/2bva5rSRZb1fnV8xVfslKVmOJF6MOcne4s0J94LNAnZybyqV
EpLAOgGJlURin19/u2ckECCBEC8Ge1y7QQhpZtSa6Xme7pnuaOcRjFcG5eJui/LP4SjHfZKo
DeZWYv5fbN5I9tOPcuW/I0dH5wcNnBw2ceGpRftpBy1zIRhFgwt36p9uSt27MKtGA257rrdU
/w6t/Ltp+ItsgzEchIqZWvWwrfVrunyrW78Pldxo3/1YWswKg5sGeYgU4W27GoNdq9U5hfPH
yj/d6E0G74fuWDMvvEdv9cUp/yT4y2ez+Clf5qTwpyRlZUXK5v/A+KEZOStlspk/JDkjKfk/
iLSX1iz8TVxPdQj5w1M9R11x3brfT/RPkoqSdCGxsD89x9QHRpHULc8YwqztjG02Z5KvBvxT
y72v0DAjl6TarCvkrWP8ItLluzdnnWCncpFUjeEwCMEi5ZTCmzM/mFAR05qIpGmMRFKeuE0V
rndEGhiw8qQNDfrTl/rNvUgwAKRl22ORtFSn5uBVnjEem9YAjmrttkiu4e6yUhaBXrowMz2K
0AZ4QxO3SCrqWCD5fPPzf0RyV70OXRsUVsXwDY2PfThP/uqWerbjieTD9KDpH/zFqvrQoh9+
LSgax5mMvSKB9pASnfoMHWNs19t/EwkeVx2rPXNoeqYBrfl2JX0ntUcKf8jbX8o70rZhYLYw
8MXbztD2xHfnpNmpEwluPQO5we3Fs6b62FKfhraqE+SfvSfPcM9J60G1vOuJpRHpnDRUz7C0
J9KQXPIhn7Xg94ZMPsgTF8o5qz16XRWk1S7XBHLdaBugCUS/Am9YPGObzAk8iu2gzGzHMTQP
Y4iLNCHCteqpQxQd/biz/D2Pho6FnLWHj/qto4skqGbaMpGUJo+t3w6Wwl4hXh/9OHC2bah6
2/hndpY1EV5l8QzbRF/XnaUFh7Q9/klsEtw7q7GLiahbhkXb2LB+UklSQf8J8oJ+Bq9Juch9
6r6Hyr+YuvdAHrPnpNRpNakUG3JYquQD8NxAqlkm1QpaglpN6IQTZ+yYriGQRqOkeSBNgZR/
39ie4FeNMqYFQ/9Eqer/Iu1KmQA2po85PQ1vyAC9YloiguRRZfhT9F9f58nSHuBsUGVp4kGb
4T4YPV+gF9Iz7IjVSYXGnnJi/bTs39b0KeHxu0yAXVYXdjysi1Sx+eYvAwttDkZYqn8AhWJP
xSchcOtcD4Hv004i4Df/qNWsQXtqlgrtbnfuTdfEy4OS4HVEnMZm440giH/qVYJTwjl+Z8NZ
xEN8pzj2pwNEKVJKMTSobuqaIwMGYRER/8Ag5Ur1PDgH4hLgDXbb4jm5LV9fQ6/04OX5fZmU
2vXr3/psXMSUm5MmLg7wnDRyw0WLc0UHrzRUKusJUGpXdQaGB3DZ+sk6YnHWE2uoUWi1pmpp
hsguwOKxJ7BePTI9GC7OwLSK8AjOSB2S2zHlM9aAPbZfTtPWzb5p6OHyZsed2w4rdHYKVLVo
jMYPqmuCHhDzennam1AaE3jrlhe+iDSMX8aQXQqV/jNRh+Z/6CThi84Q50+DbnANmdW7dF6J
ujiDggVRhX+A3oE7tsUl/WqAfm3Zv4HiNVVLHRgjbC9ujsNXmIFar4fqwKVdjPX4Th3+keF/
haoO/xE/SqMSXvO2Kgnn8PM5/HxezTzAkIYPzR7qAsxz00mmKqGCs/te2/VovxdZBgYs3xh+
lOBDU4cGHOBvS43GFOK/5O/kHnq27bDguBiOu25hpAj6wDBdVj/CYFBgYPyCchqGBV818uG/
/louLptNWlyWFiez4jIxxemJW5cJFyepkcUphcTFsdYprDi5QIt7gxBFBoiCG/+TIxTcc4l3
BHPvbNqV1SlyIW/Hjj0QzT7oHfLNH1m6odm68f3dPHIREJ4IM+QiJEIuwgJyEZaQi3Ao5OJP
bUUED3Q7EY4xg3TM/4A8g4npzVkZWwKT2wh4/UfUxS6Iw9LpN+UcY9LYDmhjKIx9NzRxyEr+
CAgGM9f1jAfT0qevCjV6H/4XKdzv9/tvzkBctvO0eKGu0SskUdcu+316Ycsx+oanPdDkJqPI
uyT/T7/y7w6d8EvpBE9AXF/SvpDTyVcgH8LyBZHRptCZEgoyvSfBf9c3dr1Top0CukjwbhgW
m9YNSqXlmNAZtO4Iga6hTY/9A+wesy9QcM1a1ihZUIOrUfj89Xm4HmBn0c8cI8BYmoAWlN8r
oEfdn+xcPtszKRIo6ToOoiLpGwaopKsCoQ44Jv03CPBcXMU3fRsKIf6kPXtBO0fG6FU5JDIW
SAj0+B8hZCxsiYxDj3NAZCwHyLgQjYvnMfHEGpqARQzdF2n+cLhY2AEunsf+cgwqFqaoWPBR
sbAxKhanqFg8UVQsrEPF+dyIomJF3iUsLnBQzEHxbkCxzIoraRrOMD6Ww9SaLHoWzGqVDtWE
HUe7B5nqAutXZVQBINq2oZsA4CrwAj3/+G7seo6hjnB8kNoAp66K5wxxdkY9QG8X/ZJR1S2X
LG5X8hLwL7Bn1H9hv9VR64DopiEEoSl3NaoAq40WDKJqrQPaDg+vK/APbUD31j8o9RCf3FmP
9Bs09PEWMGhTHfbpHbVKu+LPLmxyqYDSsociraPp/kxchzCtQ1hdhxDUIbDn+OV4tBKBViJg
JQJWIgSVCPEPIgSVCKsepMKE1X6k00JZ1Wmr4LPawIO2PRzav9Bq6Ws7aiybTr20ACoJWoDg
FyAEBQjTAoSgACFcAD5mqdamffLadACDstfZsmnwQ4RS5+jIhAtAnHBQw+nx4Sf7/vAzChfu
msvlWHF/yle75nln/o4QP8qaaZGJC/h+rJm0Nwc8UN4dD+xxHpiOB8oLPFDeMQ8sBDywn4YH
yos8UOY8cD88sMd54EvhgQrngZwHch7IeSDngZwHch7IeeBx80Blh/5AhfsDU/LA7AIPzO6U
B8JPUya3OQ8M3x06twceKL56HqgfhAcKr4sHPs9KuUw0Dyw8Mw8U9rJObnE1YNw6OWH1OrnO
kNK3s5LnWWUPbgMhM9DWbDfgSjhdB1njafr52fZaw8lgJh76LFgX+TN3zgB7A+UKXfoCRsqX
f9H5zcFHxO5CuURQMUqQjdkiCTfgGhEPrR+UpltFFVMZ6RUKhD636g50B6QRlQfKHGdTm99a
ctvvn/st9o+xWUKoJawBTJy+Hp01AC+eNWFa87Qtc8WcVR6QpgHtCzdYoA3Eog3Otznf5nyb
823Otznf5nz7Wfi2sju+rXG+nY5vZxb4dmZjvt1f5XfV/RW0up7C78r59uH4dp/7XV+K3zV3
GL49g//H43ctcL/r4XngzPDCeSDngZwHch7IeSDngYl5YGaHfteMipWEf4OJwuDcMB03zC1w
wxz3xb5GbpiRT94XKxwfN3weX+xlNDeU89wZexhnbJ47Y7kzljtjOQnnJJyTcE7COQk/DhIO
OIR0KJkgoOppJHV1mISL+1QBesH4nNx39R9NIC7nQVkhLfkaIztGkLZlBsRmskcq64HjJ6nQ
x9g39xzGUeRhHGdhHCMCHFLiMj0fjuO4JNUlRiROGZG41l12EpEbV2LhOaAbj1nnLluHgzcL
kbgG/vLQiOkAsD85KOkmhyk2pNqWqEA1Pw3tHsiTTsAunxRe4KQg8EmBTwp8Unjhk4K8Pnxq
JS9J779eXhEXJg3DJdqDOQa9MueeuzcdD2oI+wLolJDbv69u/ZRwSr66/IKvLv8qfXVHGz/n
lML1P4vjCzPA7TUo6WVcvH55Rbz+3U7pz+j5Wh+QJn24/iPyyaSBHEn9Mjxk/xFBkEUdWzhF
x0yhsNkijqu4RRzydBGHGLuII7OwiCPGSXRSHo/Edaz2eIjLHo8VlTyDx2PjAvbi8cgUnsXv
J+zT75fANyLngeng1DyxMIc0KhSNPfsQJZmc98DUGEgN7gRIMuU6m5q/9sB1DmP+EsJc5w1g
0AEKTCoSn3aoHtH7hX4PNBR5m8+KoMrOiQVAYxxiG+/INxeY0Uc5/32pk+ZOch7Q5vS6GK/X
hbBelxb+5vS733PlvfRc5fX1XDFZz9V4z91Jz1VB5951yin7K9ypQJMeGJKheQiju+/MyKRI
5Fvtc6X+ff9dev0i8QRdWljs0iOY9yajrTr1mkSESia+3+u032eUNf3+fzbs90ryfp+5zKXu
+eLmPT8H2L2KiU4JAoUiKZfaH2Vi9/vQ/3CVR8T6Z7gDTZ9ThH1tQEschpyuKTfutqipRmBn
AK4U8SsF89dBu7utWNhiPGjmjwdNZ0NI24mBNhTbnI2a3gFMsy9rG8Xlgmn2kptmuWn2hEyz
O/C2ConyRSXPowqCXJ1FVdx2t/pRb0g4NbNssFR+x0lU97NS/sQNspmL3PGYZFNbK3OrrZVX
G25/U3cEMtOTqxQQ8yRNspsvQhdXm2RFvgh9ZpJNYq7ULi53ivsLHPenw/2FBdyv7TalkcHQ
uqj306S2LUjzuF8v9I8H9wsc978C3F+Ixv2r1mPkZMXaN/LfT5yqzRdkvKhIVRz5c+SfDPlf
cuTPkT9H/mmQv75Pp5nMnWapnGZKvNPM4E6zY3OaGWudZgWlILGEwYzIsGGhzrFjmXyD4QAg
kgK5A1PkZ1kPsYoH6ws8WJ/nwRnlRB1gG2uTo3SB5dYAKjos+jAsoEUpbEqNViU8jaRYN3RM
42QH80VERJmVgR1oKAcWieWNJBclCV5FzXtAXebNzfRlB6i8Zo/mXsuN4X31HJgfgIM1c5cw
YX8yB1C/NysDVJkR+zrkfq53mGVcx2bZWzOvZ3Ix8/qVrEpzi8Ci5vR8Fid1/35l4f7ehvdn
F+7Xkt5fexwDlcUi2rdNerOfJp18033m/N2/QcnlI2BItnDMa9bkGBCCI84EaE5ajq1PNI/S
TapN2dcbdWSEhtNsCC0OHTSXGKou2tbwiQDJH+puETn1t9bNd+yqHrEmox4dm5XmFY4++msT
fgV5TfoADwDKkHq1SDIyyUgko5BMgV5zP1MLrq8WANZc319eKBd+MfdyxCXVzr0sKYX7VrV9
cV9ryxf+tUrEtTet/1XYr5mIX1vNrsx+zUbd27yf0zfsylxUi7r1m3qF/Z6P+r3SBLoL/xX0
bE6RgyN6Q/v+O8FZz/mF5hkYqtpPF9TvwLYBQygZNlbfuu+I418Ed9UsPRJ3Ri5TLKRfphhl
aIA6xK9LZo9LWgnbC39vaB48vsfi+SH+zc7wL/vDnlguRfwoR1arLViyk4UJSBRMMxussshn
5w3Y0zCAS6EPw6bt2Y6qhAEEtjBtC1PTdtiwvj4Xww62Ha60cUvRNm4lydoWZc7CLexuy+Eh
MjGk3HCYwJhcSh5yccdmZL6X7yDm45dt/RRXWj+3Cr4n7MH6KcRsRduH9VNYsH4K8VvRNNpD
fJLSAcoJ4+eGgi1Cubx4JYk9WZQ1Uc6KkiIq2nIhfsg9BmDLEyC2dPBFxrzM+yH4/HAVGM/W
MoYoG3XsFs8ardp9BZBn2+iDjvsIPdhySavUhRHsPJVNz/2IWKrk9FAGj6iBv7TbGYV+AE7H
D1kp0JeFBiy8EqAszJAf6eUz8Au0BGAq3c5G4URFKvpNgNpuA6yAMxy+C9S5UDU06990cpzG
0VzfFNINDuAT5k56F2tcAG8w5CBZaCnpVt6DJNB8MmvzjTGwA4chmXuAxUiHGSZm2k40noGy
hqtxvyG+mc/QY3BKnFIz4BoUTo0wyL8b0vpANqFPwC0UYqCtj0Iz9jXOEugNMgHFljnFPjzF
Li9S7EIsxda3pNjGlhS7n55iX8mcYnOKzSk2p9icYnOKzSl2FMXmVJVT1ddLVZcnV05VOVWN
oKrKy/UGP8Milq28wdk4qipt6Q2WtvQGS9t4gyVOVTlV5VR1F1RV5FR1x1RVSEBVhZ1RVWEN
VRU4VX2VVJV7gznF5hT71Ci2wSk2p9iJKfbL9AYfOcVe8gbnYyn2lt5gaUtvsLSNN5hTbE6x
OcXmFJtTbE6xOcXm3mBOVTlVnaOqfU5VOVVNQlUzzBvcLtWrpDdx56hqA5BJwx6YGnlPOk+j
nmm7/vemMVDpLZ1ShyiKVCDfug8TSzecnj30vvsbtuWIDdvA8Srk86UstUjTtEzytk8fyLJB
Kg+m5r7SJI1rPMXZuXggGPcA372LZBCTR8zY34xuynN0U+8nTjIRoqyZhTIKUqIyfBa6zFv1
ON4KI2/TeCXxvBWwiyJE81ZxnreKPm8Vd5jcIl9IhfSz0lUCqB8THFA4Qqgv7h7q7zZL8zwQ
Lsyg/sGTOR4C6Bf2BvQTh+k7rCeN+9F2QU70OCvcHUsFTlyQ1hANO/bEgef1nsYGhbi/TTht
wetnYYxgineMi2WzSJzFZ4tMQIt1aLHr//MrLT5y2KijLFh85n7MRFVLaZ3Cad1R0LpDRuNL
TusMBv//lK+Wf9M2YGtXQTn55d+yfvrFIbTSUmlgsTY8HEJjgO8UdgJW8Zgb6m2pXUcoBB8M
n1zfV+hLAJVxYzx6BCd4FmBI8i/DOS58WXAF+QQIdkyvi6YfI6AQMBPpP1zVBR5SYDwkHEWt
bVgG/Ei6hvYA/MAePFEb9gXpfL68zNFw5QCkf5uAPsm3Vuc7z/2+HGi83umicp4MvSKFnvMR
1wpzEdeueORxdnCckceP14MXF7cxcUDfyMmdBfa9Wh3Y93IxJHuQwZWGZd9fOPakjEtEmE3f
XMNEmAk6TpK+JKJhG0RvD2iYsIqGLbCvvUVvT8a+IiKbR/KviTVEwWFedngJ029bE7Fji9u+
OftKk7V+HQXbLFs9X8vIHUSHZxLJk6y/XCaxNq73FYfTh4fTV3NwWl2A0709wWmjz+E0h9MJ
4XRvQzhdtX9bIUC9/zxHwn7zHB0EKSddkrQdUp4wCyxHy3tDy0nzCm2GmhOmFUqAnqGH0LUI
VOFHoVyOrTm2PiFsvbj46nixtcyx9bNia22/pur+5Ram6i1ygxwAW+89M8jrxdY6x9YnYoWW
TwNbixxbc2zNsfWRY2vhJLD1cditY/YklDRc8x5k/MINDrjRgWbrq3RojR1Hu4cep/u7uMqo
sEA+bUM3HV/C/nHgAAY1ANKkK+9xHT/iFpzT6O2CXzJq4+WSxS1KTsIf1HS2eTGUPfBbq1U+
BhJxbLvB15AIdY5E9LiBPmV6wRM00B9g5f8CidjLYtYlEgFK4T38L371VcMRLHnZ1yaDlbwC
Hh8UXr/tOU+L+wy2sd8L3H5/uhyDr3bhrOFYWcNprJs/Cov8G6nHEDMgD6JBp4QOhAgqvFW1
qcLhI6khZXdsy9Rc0qHbTqF/e/oF+aRIktFW5iEzKy8oZKN09M8IqHeejh7g89usRPdwj0yY
jwr+sfr4bps9q7IcE3rJh7azHPbR+1CbcXtZjWAva3B/or2s8+GbjMU2xJVRaEbtZP0wsVTX
NQeWof8V2s26vH1KW4Fj5UgcK+wWx4rrceybTL8oFWB8sRFDYCIyxw8wGw2jUnZ/NeCfWu49
nDOIeUn+btXZPCj5u74v58fRcgnBoGL4djFmmTgbVOJeBpW4N5ZKBXm1tSBlLkgUpJpWkGzA
BcakOwuX3XORMpHKOxMp76W+SJWdiVThImUizexMpBkuUhRpL60uncWeCcSKcArl4HLJMsmm
7KwdY6SOH/CLaumko8Fl2sNY1VHQfXMw8W/j4p4Tt5a2I4M20LDSQJ4cEgQCTQkJuEDjBJoS
EHCBxgk0n37uGsBvhh4w/8rU2BOU6HthQIToNuUyn8r8MuWsFi1WLlQQqs7nrl0LlM9dOxYo
n7t2LNADzl3cIkNlbqS2G7LQq7ZDPtsjg5QGaKyPFOlq39ALkaJMWobTR+c0upU1XMti4CKO
lIIMF9a0LdOzacTa1yrf/jYWmVjNcGrWgj2uGIxYUTZbOCW/I23b9vxVIY9hoSYL17rNQiq6
XEpMvVzK3/YghpdLiaHlUmKCmKxbL5HabTCg6VIofwGRtGKJ1I4Dsu5390XEg0WujBJXrYzy
9UVKrLtaX5Q6XGdwncF1xgvVGSnp3Eqd4a99PFXLGVcfXH1w9ZFMfaR0baZRH6divODqg6sP
rj6SqY/s4dTHqSyd4uqDqw+uPpKpj9zh1MepLBPk6oOrD64+kqmPfXheY9RH9iDqQzhyn5Ys
7cWn5ScfJZKYIV0oEjfLBouRudGJ622ut1+Q3gYdsg8/1yodwi1PXIdwHfKydMg+/F4wYG7b
IW85xx5cb3C98bL0xj4cXot6g+MNrje43nhZemMfnq5VnIW7u7gO4TrkZemQfbi7VukQ7vPi
OoTrkJelQ/bh81rkLxx7cL3B9cbL0hspoz1spDc43uB6g+uNl6Q35LTrParVdv2Wr5lBGWbS
yrCt0KSSp6FT9y7E9MEK2hiFwLNpOp5AGUfEKnitgQpAttnUsv17YoJ+UkHL4LWOZlsWzB1+
QAgq+DWbj1+FfHNb990YOfthuXlvDks7JUVOImqZi9oXdVZazpGcgE4AKAirYQqHKSyT1akY
9571TFgQo3D8qZPDSc6yUjjJWVaeT3JGv+8uyVk41zHPlOyIGyc5W60S5q/PxyUpVqb5xQSW
XwxbOM0vRpMTS5mF5MRneAv08enbUAhBRhQ+tZx+7Gox/dhsiNLsxcKa7MVKLr8dRd1f9uLT
oajT7MWFuaxbBZ+gNuQVKcU+yPkYgipMCarACKoQT1DblfJU/UxPCwfJXxzHVtfkFvt/9q7+
OW0e+ffX8Ffovp25630TiCS/c0+emwSSNndNm4Okz810MozwCzAFm7FNXu6vv13ZEGOThNCk
16SinRZk7Wq1Wn12V5at7jiVGlwcYQdKzg7vPOl8XHGg3YcoPR3PBoX8HfuCbUn9yzfNf0S9
gkk3YKb88bcsHsAuornIRZx5w6jBbM42SVGAIzzJSbYPoJm0EWJaE68lD3j6cHocgzlgXNEa
DmTrC9eWS0s+B8FOLnH+HcXaLkiSCZCpM8fRWwGw8q0Ii5YXsiyx2cJbiQM86Kwo8LYUEFlL
BSEaSEyFAVpaKILfhbUi+JV/Oz05hFZAN9B+p/tllODBTgtOMGArirE3SIintB63JVbt4O+s
g5JnDmT1BQjdcQCcPGmNHLTaxdPfth88tHp7gT138DWNiTxYjrOnPLXaVufLPcH5cv6THy26
vXwk03Z+JNP2Ex4tOj8U7wsYNqQUGMbCsLkwRWW6gR2GiLe9J/14x78EPh/9EH665Le//15l
x/435y7Xa8947nK5j7r9is8R3H7s6ePrnyN4R0dezOnj9dI5gvU7Tx/31p5UmpxULJ9UYuWk
4vlh5m+ZU71mr92ULpviWVPMzpp66ExxzLf5E+bbXOXbG+bbvJRvc5Vv/5L5tqHy7deSb2ur
821mqoT7xyTcukq4VcKtEm6VcKuEWyXcKuFWCffPkXBrT5hwawIbKV4DR+GrJHyzJFwrJeGa
SsJ/ySTcevFJ+LZKwrMk3FI3vf+nObimcnCVg6scXOXgKgdXObjKwVUO/rPk4PzpcnBX5dub
5dt6Kd/WVb79S+bbzovPt9VN7zzfdn5Mvn3PU9C/dr7NVb6t8m2Vb6t8W+XbKt9W+bbKt3+O
fNvY9HUl8yOTTsR0h3w583onkLfszHkVUPKnfVz+f/VeKK7eC/UT5EPqvVBrvRfqgVh4KdC9
O2ZdqvZQHGzQmYyDjbXC4AfC30UmqALgRwXAuXPY8NyVRWwo0ZYISDXfj6M+6FM64J/45UDK
KWzsFLaVU1BOQTmF1+wUrKBJ7U0zhn+dHs/fYPbLv+QQFel8tyJfyslDz6xIsakisxW9ebBy
HsJMV7aZq3TDUztXqFRZaa7SDYPpFSp9Ka/sf3aVbni+2wqVvpS3mT+zSvvfc+R3HM+m6UKt
D7wK9tfT7IbG2vUnYjrEH5hHd12o5g6nkCOBioLRYJaTKXUvqdvd1JABDVxsdK5PFRLMFbph
SKAUepdCNwwIlELvUuhzHJeUc5zf72rLTaNK5wudb3jUzB1qVUoFpXrKdz21QpXvemKFKt/1
xAr9gb5LrchInfsbrxvGEW6Bi2LyIZr4+fEnP+0tzWfX4uZn9axU5IozN/BWy6+q3+B7VmTu
RIaXtlqgDvFTm7XUffmHDvHL8GLDWPd+vNjvKsxQmKEw45Vixobp3L2Yke+8eakrZwo+FHwo
+FgPPja8tbkJfLyUxQsFHwo+FHysBx/6j4OPl7J1SsGHgg8FH+vBh/Hj4OOlbBNU8KHgQ8HH
evDxHHde74AP/YfAx/ZPfk+L0We5p4UvG8IXHtC6Rs6AJT6qNd+MrBadFG4r3H5FuA0Y8hz3
ue7DELXypDBEYcjrwpDnuO8FE+Zzp3C3XMUeCjcUbrwu3HiOG15l3FDxhsINhRuvCzee407X
fTmLut2lMERhyOvCkOe43XUfhqh7XgpDFIa8Lgx5jnte5fxFxR4KNxRuvC7c2PBtD4/CDRVv
KNxQuPGacINtut+j3e4cf1Z7ZlCH2qY67PDT1rH/QjD12ZW4+csKOvgWgjRaOmx0xbsKftUX
FYBu9Y11+6/ZCPBJAMpg3diNwhB8R/5CCKn4Bx4+/iX0a3y37d6h5/y13Mqai9reMEVeR9VM
qTpX9Rv1eaUfz+/PBruDeNZvgO0Hz9IGRimmruP/zDJo8X95OrHJzTeMM6bBH51bbyjjlqm9
IfRZpCl9ZkkqYkLewDyKxT31Hrr+Qj9vydlwlBD4K0giMFMlC2MggH14Gh25GgE+vvfDb/Ko
uh2EWpIOfSxKo4hACuj1o+hb7S0Zpum0ubt7dXXVGMiLjSge7HqRu+uHu/N6iy/1a9tsXE/G
f5+KON1jf3aHYrrH6Fuo38PvHDgeB+QmmhEBsB1CNj1LELgXssiXLeP1EFOhoT+eEjf2s1M/
UuxYMBr7O1gDWCXDaDb2wCNDBjlOZQ/mkjTI/hiAORSYH41vdpYqLRTSyDWUDkUK/FBvoTue
edC0VJHUCVQm0IEZHqsnfU+jVvP8QCA3WkuzM1GIUUvAX4kxqddn4Ff2GHxJMJ/bY8zglMLP
qyj29mz4MpWnmO+FEdZJI1BRDWSdjEJJnnMEvZGcJcoejf0aNJaCtP/2Q6I3ONkl41E4u65r
Dath1Ici9vzQ92oxLlK8G3p0h/619jZX6+61HzYG/4GOTGhv4k/29Pc7E3Hd1N/nReK6d+lO
Z8menhXIHz1wVrW3k8ibQbO7q1oj2Nrerudf7iaeMJ+gvXlv99L0hi5+uNGEE/wnV+eOHbLa
07WFnHcuB6LSxCP6vlrw4aVL7x443tCsBb96zJcH7/vHrix+ub3y8C0JyhaC8obZ0Ow6yLGm
gOAFTh4p3G0bFaHeZlKttPa3q809jIBR/VEWuzbJ6oGGH122k5kOiEwuR5NmkO4hzDR/YLyV
+X83FsmwBygynaWN9Dp92jbu9/8cPX/u/3VGGdRjus6p8v8/4nP86fisSbrgvtxhnhLFs3Cc
nWBl1vLL2ZnrZJq9CNJPpKc7O+yckGQ0ADdUI/8PyUokkxUyjlws+Uqib+Ri6crl6Hrk190Y
UrFGo7FURVxihRjccTQBPwaTqFSj7QtcvMxcu/C8EbpWcHbJlZiSZCog8SrznDebJMMKu3MI
a6JA9iOapgm5BB+Li7To1D1/GvuuXKnH8OJqBLld30eq2J9El1AMrgApg1k6i/0GXjkd+wJY
YrTkX4Ol9MAzQN7oJTv5bzQz4LgoJxBbza+AnIUrjSXhEVvdfIuHJ6D9qu6gKtYEOMrBxbun
JlaF4juVFabTirIWF6EJkDZ+sAESxtPKeJyHE1wLkZf9FKKbbzI6y1Lo5E5WE4iPwnoYeXcP
cCBGY94Xd4vTF+5sLGRzD0kO4oyjQR2+lWoc4PtNsYYXXYVgARCCBWh1/ZjiZQIWmsAo3cj2
4pE3kJfW5hKFXs6ng0YmRRmLS5hrQQxTQl7PmGEdQvx0SPEfRl6kWQej2L8SIMGa+hlHJRMa
R9EUupQdar98qWBVmbYK13b76P9LjS7X8EQqdj1q0crgLdcD3d4LUhKZcgkr5jacpemim6j0
j9FgBLhJvkRjSB3yo7njrNVF7TbW/vglIX8mX97nTOW9JBxQnAXzTCTJjnTFx5kJx0qfIpLM
3CHJR6NByFl8Q/6CGdNf5MgcSWqU8U9/ymQ8GoWjZAgcHyPsYoAhK7qs9NrP+GCgdIUZnYs3
vPKcDvlmo5YXfz0/a12UWZxliY9kA2YrQMYlx1Sq/k8w8jWr5i4IZgl4O3kn0BXusAI6ODtz
C7hlWsQxSD+9ehSOb25na4FmV14nt9fnnPP/vxJiMt6wdMc0zQuglBMsBybg38hq2A3N1Jlp
XOAU0ZryRhD5+pZdkO7JKSnU0RzgciIj5wQj4m9ymjclngDXQk3DoRekdXpOaJHeNOwLcjry
msRxHHtH2k8T+iCn0ZnACQrX3pP88wf+U4qG3+rZ8uhx6DayM70OERw7FqfX3i798seZQwst
2hT7fXzaJD7VaPPrb0H+sRnlwnb03y8IWVmaZe+QQmAo4/f8iR8PcCB7cabFbXpt6bv0mhvF
9hwD2+vK9ni/KXnalGlmXzM8YRNyePRx/3030zGlunlLazANdNbZ//f84u2HdA4Kpbms0OkW
lN6KbnHhFTtvaBTU3WmvZNg9XlXaPi4yFJ7tem6BoW5bwPDgtELKSIfaqxhSp1paYGiaGjBk
tFTJ8DwoZasYMl4qdQOnwNA2UUKmVfUCpXqZoQlyM+M+CU2qw7Q4ggGTlaxA49RgAeL5Oyz4
K4HBXIyyZ0ry/Mq3cAwX7+GtMRC2hbzBODXSzs2CHM6/tDoFzdigFwr1Cgx02wEGnVwlViBM
xwr6mqchqbYgZZoB8zFjuKwDnUMPCwyB5QVpd8rjgaTtzqrxaHfK47HcRVtzkKG2ktRctmn4
B0utUl29yNCCzlzM3yE/R45301tISYcIiaMwiMhiWCwRaH2HwkWRfFsutmxI3G+5cxtmTDcV
7rdmoVS3+QUpd8C5HRgGRqIxo9rFxTfGNd0wrVueMJiswJPbkLI6plNiwfk9PCvKtg1uFeXM
G12zkcy0OdW4bt/ydKiFJoax1VkMoVNBLQ4gXxU8heMBeP69DJ+3oMkBpa/1gtiOzo0VfPqO
5FNl4AA9K9Ibjl2mN5xAMyV9tsBSINdMoC9itmNZrEIvmB5IenCUvczMgJb5ASI+L1I7ell6
06eebUjqXiyuegmEMD0MQoCDsSw8mDNiwBI549S1MuG96Uw266DMXC/SSUtdpqMiYDRrthfk
lCYtCWxRvUJJTc/1mKQcD3oy457LyxjSF8klZJcEtq1+1t9JiIs+vTDq+ddTCMpxvGWXrSIL
W1slQVCSYBbeJQOjzKww4IbmSgY4yXuYEPbiWQjkwgXyoEjO7LLOoX2PaVUN9NzpDCXQyhJo
CJSlUbdsx5IsII7pZUsZSMtl/wu0hraC1vDp3N4gMOuBAOMe3l2dinSIXGzk4hW4WBSdB4Tk
TWLbAGr4lwaEBURHkCC2R3ROnIDYGglswjRiWfgFqnGduAbp20S4xOLEZkR3ie0QPyC+DThK
HIMEHtY0TQKe0wUMMYjuEUcQx0bmZp9IKMK/rkt+64vfl8r8PvEM4ppIF5h4SWRXoSldNsWJ
7xKd4Xdgf9svk1tURmxPGJZZ6MZB5RCXkd/KIdnvhWqWA2BXr9e/EojaSRrLXFpoliMs1tcd
h3m8Ty6gQoHGQXnDKPXngexXdEQXkLeO0nkCBamyP5mmPbl9g7BbaovjVDg4f98kCaQHEFhj
cH41xKUFkUaTkTvnuotcJXhk2F7goaNLXCMqtywL1bBu/N2+I/4u8LMte7VzALeqO2Uj98zA
83J8ynvr9/qzAQyZjpNEDwr0MJ2rsAoRQokeIVUgKJtFdLR1jZdneOD2aYaqIG/k9qaQZCY9
dxbHfohW00eMhRC8wMVkFccAEbvJchkQ23Ge+n4vEWCT137Ym6Z+7zKb94hazC+ws5yKUIDj
jpmzc2G40IqxZxK6S5hjO2YZNkElnIqMvkTOxbKbtRymV5r3ufB9ST4LJ2Law9QZxuRyInBM
+j6wsPwiDwgRKjw0mFwFHkCcIDVOQqdIqztl2KO+YDwbUZwtvQnQ4/zF8WTF+euYVqVdnTtW
7nQmmbOTnsYtktlWpUkdJrEoNomqpqI09hhrV7Sli3lPPfRvI+lgJdg4vEjKeQXfPdOlfUk6
jWGWoVfTsZeGXqDTnEocpPc5Y/MmB3E0m84b1tG8+sVmDbMy43zO3KyzUTRNegBq6A/Fsj+0
qaWX3anpM6/vzRvGVQEgtDFy84uETsUPA6EeZCaF0yGnZGhJRfUyalc8+BzhK7HjWhhvM63q
1YGlba3L0rQqLOV6xXdHuDazq3D0iAjX5pRW7PgREa7NmVWxrLUjXBuziM0jXADyipGsE+Ha
HPKZjSJcm9tOBS3Wj3BtjZrVkPxRES4Mt74iwlw/wrU1SMw3j3BtzXDKWPDICNfWqlnRuhEu
5Px61Xk/NsK1deaw74yNIA7AOH2N2MjWTVzbfLLYyNZti6+OjWyD6mX7fExsBGk+WzEh14yN
bENzKrb5iDDENoyKL35EGGIbVsU2Hjc1DIdVs0duGM7KqeE6palhMl4J6nTR13nJsZt9Xnbs
Jq9EMGs5dlz3/g7HDgn3ho7dtFk101zHsZuOXW1yLcduscrywPc6djCYp3bsllWN7jZx7BDR
rwoQ1nXsDmWsoq1HOHZnxSrQ+o7dobq9Yiav69gdalZiuHUcu0Nto0K3lmN3QLnfsXTlMFbx
io907A7TrIrhPAa9HGbolVBufcfuMKsyox/p2AE9K3Hyuo4d0NBYQbumY892/4QRmeBTE7d3
Tsd+kGabBUbJYruQekjgJX6y/X/eZOTJd58//ea/Nw/s/4MI0NDn+/91qmvGG1zp07ja//cj
Pm/JYuwJbzBW654cHH/uwncL10ATP0wbNcchSRrPXNwWlJDIdWdTuc3J1A0te3q7UTuT24xE
Suj1wZHOWzC0jVrtgwg9KKbX7X1Kd0j75JikN1NoikG8zlj+6PfnwxPc/O6OgpFLzuB6beuD
L/BN/LivpS1S0cTHw/cJPcAlafhygHfACLMIp4QeEobr1IXW0LAKrcF3rudtyd4dh/KxLtxC
WNv6ArFYFDdvNylgUZzAtSZhDa1h1rY6frYPCkTxm4Q6u+AlOGW8tpUfHQCF10fy3t5WB3d6
THzSHf0H6po6+XYAhZ9P8gKbOVwWtSAJEW7qx6MkHbkJ9vC4u48btRaP3EMRPsZaLvp0Wi6S
nYKy2XQQg95wKOalyVB40RWOFj7jMR5HVxkF5khyZ1mrXebWhd5mrwQgMpUqXT5sVyj+IaYi
BGMhwTiaTm/kgyNnUTIc9QWokJOTgyUK8m6Ei+ra8K9AazS48X+7mklBK3P6xI+zbVO4Seg+
spz5+mRaA6gs/sjGbKrDoPk3/QgSx3sJHFm/mz2IcS9nXdZsvd/fnUTgYi9hFkb3U1BJsd86
rZjEefcAnPJAuDcrLUOO4nyCZc9DlqrhGxxkOXSyPgpH6UjuE5zv01xlBtnZGb58nibFB4A9
MOR41J+t4n9+eFQWWkrW8S9Hi5lWnMBsaQIzmMBWPoHzxz2XpvCJCGeBkPi0PJFP48gD3CKf
xATmXnnzUWGif4IOdjMNoXD5AH6aTfrI0Wl9OH1v/KO2dX5+3G4SvQV/ICysU/BXdR0iurpN
DVo/cFpUP9ItzdD3a1t/iG9+fTaVgJa3nW+0Bv7/PF8wh+970DyIijbg/e0EsHiMAu9V5T0S
k9H4pixuQW98GWZ3iDPHPcSvA2m/m6gu36Z1q7B9yitqajRanywK+SS3P1NqnQOXfQgYcTFm
cI/M2pLMGow1z4UGjEwSMJv1JM4U3RHuN3Iib9vl5LWtjxBdwxBk/uzxo35nJySM4hjjY7jQ
dlcEALz5UIOpj2+Wr8zf2bdU2PXdGT7gRebP8p5nb/SobYFfLHa9mXu2zM988EeDYdoknJzX
tjKRyecgt7NWFHuSU3IrKz6RLEa46nU49vHpNPRay6Z45xDpS0Ok7+Ad62yI8o09APhLg9QF
jYPO2r5MTTLpW6fnbD5KLWg/Bk0syG9tGx/VLo+yfKC7toWTr20RahIqA4CjI3J0QA4PyMER
NClbgvpNOeXQ62csiblD5KQiurGzeKiaWNDkWAyk5z06PSfvjsaR3Fhaly/nIfhcHonCujsc
TRF4v5wckndfRnE6A7knGDD51wB8aEl4uQ1X2xhNy+3LS5dOu3DtVMA8TiAGWL521m2Rd2cY
MPy3vWPtbRtH3tf0V/BjFmi6IkU9HBwOp5fb3MZJECfZHg6Hwk3dNNisHdjOXrvYH3/zICVS
dtJ6Y/R8toXA0QwpkfMmKWoEA9Ff722+ACzq9c/FPne8Hh1NbIIFum+G9/30ZUqbcQfmK0be
7XsFVOnxsoa4/jQE2xh+vh7ez0x58TYV+0Xv7G3x5nUKczoe56EHr101BZ2zI+jmKTNDEFRv
4vUq9qszYCS+Y2738sKYgzpycY7UcFop0qLJYAQc8Ql6bRl1czd+DzQNRzgMYUKyNiGDCUCz
IekI0dI7vQJicJ3YvByC29ofJ+osuzCtDWYcuYZiZtsDmR2EsdgP44P3oAf3i6VXHHf7b6DN
4+7xJZw82lTZN8oh6P2JOo7v069Xtdd7C4TCD1D2aTS+G9988St036JewG92VdEAGU4vTs/d
xqctoaD+9WeTIZgD6Gb/qFc2ZExNDfVEFaG4ElQZ3n08mGKaAsS8uQAO9h7uZrcHdhffDSl1
D3Ta+LpfTd4En/U5Ctq8VvQervzFiBpLa/dsDjL+/fMfyDPgf9ylXEUHKsZ9M+LvMFmJgtdv
focrx3czENQhDTqvXmBqJXyp944zKx2KBN+s7WHN3uAzJ4Y6FDD0NMiCtxbYAhXZAuuZz8b3
D3c4MnopKu4uDAl4zH0o/np6eSFOu6J/VhV/g5gjRUEbyNmLkvNO0HEfq0UF4BmPw0UF82G2
FYMej05ng8nssasoEUaBzgbf82LQ0ESIC5KnrYFTnQUTlliTcVxjHjSacrAu4M1QO6yH4Hvh
1OEzxDqwMvD6aLcUKfaq0SdMsPFBGN96+7uJIRxIf3STcJisGn5okisJTWoXmnahaReadqHp
/z40HX1AX7xcXAofi0v6sbgU7eLSk3Ep8aZMyUsh7VScmfnVmDTHmNHH25uHiSk1PHnJ1ehy
hI7xUYyAwcTp/ZCrgoB6tOf4Z5hkEs3jh5tPNCc2t6LMV/gW994R2Cluj/xgFivtWiWo5O2v
D7+2sP16fap/nvUoshH36/mrcztbwZndGlWu4QpTktqEpOimuH6fdjiSPKuigMvYeXMhrg2T
po2vb/EZMEyjD0V68J/BF3zZ8GBQFwx90cj/mWjUqkQTQQhYIBuLXgPhXI4aT7CkfNT/TD7h
4/LJB9e/fLtwgkekE6y7ePx44Ykl3Hm0dfVoeufR1tqjRTuPtn4eLfXGaGnztISShxecDLS9
fmCZJM6HH4cwKIfhnxXVeH48W9du7sadPRmPhs404Jtu1kwaWjcr8wMZiY9DmNXQAwjoPRdc
0WNFRPh0yy2lW20G3dk1vU2dP0zF/mU//8GjHRA+0eE2Eq23kWg3ykgVN2QfjSgzzdCvHi9X
PVk5S49OLt4hEY8zc57+FTGWpfQUM9PluNNZrnq2XPV8uerFctXL5apXm2Fb5/840JGnAydm
w8t84OhuHclyQ8ZGy5C8IcOiZUjekBERjAQ7Ym4YaFaoCSPjKAoy+h4T0IHrwg4fOt5MAFy5
bO03w6/o+Fzw5mdnxVG9t+Vz2l5zt6v3l1N6BJD9Nri945Xp4+HoZvbpUByPRzcLl7LDV6G4
wq1z92Z/GK4/9yqTeNPfU+fRI59Lj1ovetRz6QnXi57wufTomh4ZrwNB+rkEResloOi59MRr
JqC50X5N0qJRXu7vwAV3EjXb9UV/hok6p/j8EU+ENDsxmTk1Wh2K6F+4X/Hfzq2Tyr81dyV4
oi9F64KmL0YY3nqYOKU9BFNc9yIYOndydZ713hXH54dCFHfDAX3YYCKmwxlvdKdy3HU9mNKD
a3x0abL2N/cBas5+Pi/fVSd0l/F0iPmS+emwuB9Mp5iy3+136ffb3dpK25+PB6ObB3x87+lR
jQWFup7ccttdKrdqYdbSqGFbfXqIq+R7w9Efl/0/bqfjNI06B7JWtbsvolmBs9ccinb1pvfS
f4lCgpRUaEcHdmeH2TWRTSaDL+5KopELbzg+nYjeePZpOKH98y/2LqfDugbf4NH1Pn5wWy/3
2cVH/PLiNa3tJXEqXuf2eoeP9dNqHEGc1abS7JTlz/UA15R2qW7tPIc5b2jfHTHE8oUv9oho
56G4pH2539qRizHIgj/ah0//BdAImobL/xYZa4M0S61xmGrRA1pRF0R3cE0DpPKo18NH8TMS
P0nAot9lUrzYywejX0SNb42nzOCpPDfREYibgStC8YyuP03GozFMvO1XvfBNhPzhIw7TcDOE
WbKVYRjanQvuxqggKKpA5yH+n9srkCZVJ8y6kbdNIFBSafhp7RDohZ0wV6+TIH8THPzzTUcA
UedA1CE+erCWD32jnRSi3StPtHJzRKvWXLT6O4tWbY5ow/UWbRl8Z9GGmyNavd6iLbrfWbR6
PUV7MjYpaJox0+NSVnNSjlYh5flnor443WNOnE2BI84G6Ylz/rDirFt+TKi2gifTaCNlGm+1
TOONlGmy1TJNNlKm6VbLNN0AmYZzMu1stUw7GylTGWyzTLPNlKncZpnmmylTtc0yLdZTpl9f
etBtQebrvhYcf+elh3JzRLvua8Hfe8Gw2hzRrvlasE6+s2i7myPa9V4L7hTf+eGcXNPnrkuN
n6I5KW/1WrBc0weuz5TpVq8FyzV90vpMmW71WrBc00esz5TpVq8Fy014thrPyXSr14LlJjxb
nZfpVq8Fy014trpAptu8Fiw34dnqAplu8Vqwn6VYdkCm0pcpy7I3uL+H25nE8JSga4Kp+4ST
Kt79GPRexanG/OK8ywf1+MZmkw9pq3O9+Xqx8iAPKMuc1QHlkyFXSIZ8kgwVhAvJkCp6NiHK
350eKud7AvXm8/YbGjZZGpjBEE1sKj4MMeGX96aEiv0745cKUvtywhmg2XYXvBL3Eb8+yybw
U9EX+z/ZjPEmPZjoz75QCr++l4u9TiqnXgHVR6oQ/bvBb0OXlRggT67g+vGEXwzAHlhvYLJa
U4bvxUoWBEWWiv2jH09/wI8Z8IIR6PrgGkQGaqVoh30+fhh9GExugU6mZ/JwD/cf3w0mtNU+
o/cyxJtbzOjSVLiY3N7cDCcmsQimK3dLrTEOXA77b9tp6X4LYsQssw5y/q3AOlPJzYSS1J8c
FUIuMHZj8SyPCl8/GA1njQ7UCVzJT5E7HCFPMWw9TB1GwnEYyMMgAOl4NMjV0qBWR4N6nAbp
06BWS0O4OhrChTSoBXIIV0uDXh0N+nEaWnLQz6ThW4/HaShvp4uJiPyeRuvb09jvaby+PU38
nibr29PU7+lcToy6qwve24P6ndXZ5nl2VH6Vsn7Wt9H2bjj5sxYaLvAy2TMpqSAOfvhA6UQx
NdFXKaFqf5aA9wsImMsg8hXRzaUQeap+3n5tDnOc2Xcdv+37TrkUQYGps/EkMGm0/T/3g1L+
+E+hZsp4uQ9KBfThqECUtrVuhb8qFUH0dOOtz6zgo6slqS2VoRZOutBgKAJNv7FIAzp3/W6h
WrMPiBdpslSDhRJRgg3CSUIkJdLQBlxQpVCV0PxZLQmMgCsCKXRYIxpWANjp0pe3HBAH7Hsx
1JJNeVw2IFSEiYbmm9FnvEIYpew1CC06pW2sRHl0KgcM6jZUTJ2RIqPWDUhS0wSW1LbqMIis
7tqE7N1FwgTeyjZvVbScNIGn3QI71WZuiL2IMmRFTBVABt0CmQvsyWsEnsSZAyrUp4BEVhnC
gRM1QlrmR7lhngdC8wkLMNJ0O0CkogGlSDoOCH3GtvGrWowIRcgd16Jg0ekGhLbDiEGknLgd
xk15CELLDMh9k3kNMuWysAjQyFTI0gEDVDoEU5YkKolqEChpCzIjVNiAWFpiG8CoyOgJ6HUD
gr2lxKhIJF20tLLD3GVEQN3A6rFpDG3GgkCoLhlEf0XlujLlAGqyI+RrbO6uqhpkyhWZOoiJ
GwMtrUGsnhmwVva8QaBSFw2oSeAF9JDkG+ClKA/QK+IiuLCUrDeJjXKkmjXDGkHEV4B2sorg
twtCYUCJ5tqAoIwJg5jmne4bpLacfNdT9qXa9rW8eYUklifMK1R1d5DV0LmOQbAKy6ABUYXD
BlTWvAgRcnXVgJoMoAZTdCbIhsfIDVfkTkKil3xyEpq2kN5SRJUow6Z1UvhSO2ET/EcokgL1
jY0K6GnAlJWxwxrFd5EElrYZckbaqrXOTTwgRB0JdAe/eQE3xW8zMtgEBjTcjrFwt7p7deLd
DK5gO4jIyvDq1KveZSfWrUuZ8jhwqociVg6oRUlmH4fsDup4YBAUMpBCZd1F4oBG0ng75ZAS
WpD4xqDxyoqNihFYniPfAeRWwUxrEBlVMMjuBE26NOUemzMv/hLI8mgQpV9eNuMnBHOjJS5C
O+WJf7UhlK/Q2m9dG0Y1YNM2Uq791nPrXVywvhr1yvgXtzx80p3oFdmXfsq+uuT4dc6uG20+
rRHGxFBPbJwIZAOSP0GvQzjmRhk4YGCYoCMj525p7CsyBmc6Y6OUC8JJhkMB5HVkwn3GKh8Z
wZbEX22HRqViEHlNokPvScbM1ZEFNci8YDBhT5roGmFYhKAdiGjZgKQBVW4QTGqVOaAix0us
C0jLaBRYIySNEmuwHmMyGDpaRgj4jSvndqQ/CCZGKrpgkK1eURRA+0oMX8Hp1yBG04iqp/TR
HtT9Iq4R2EaRG5DvXhQNyDInRkV2IoG3q0Hwrx0aKhSGjR3jvQwiFVlly1mmpQNqkccsc0Bw
SMoTU84hKU8bELlOjWn0d1VixYAIUVFjT9lXtCL7ip6yryqv+4PRFzpYGgSbRFU1oOZhG4Bd
Dgkoz46DkBSBahDMrXBAMAgzKDSIkIICgcycsuuAMJIMjH0RQgJCmnLJfVMNCNOQilUadUaS
llW6KYe+V1EDQqyq4ho0nkUZpe02Md2C4E21U4o6040cRIHDNtZh4zmSBqRYhZRDULR85Wlm
LD1H05Qa+6rLJY2iYJRrRlFZA4LMZM5gPRGQlSlnUmThgDTQtyD2ShM7CcGtq6ABzWA6RI7l
djhcNQjsG43hoIemMe2AGiYpTLlBQOuRKTekxA0oaQpDvGJEM7vtGINyQd2AmJDLddG56cxT
9hXPTeWXNi8wSJD7E+bldIdZ7fUv9cECeQdaEzWDJGBWg+Ahd4Fe0sR+6YDGWAyiw1onGlBR
jKlBXNoAkAd7iIhFyFpjp3BhtwFlw0o7gHEXYtLWQoyTuvYb12F4osAOhqwcfrtsNybJGVbr
ZRfnp2/h5Op19uNVDhp6dNp/aR/diavwVfrzqdsxP8eZUmr55anKLk9VxjZ8nWr9OY1XstU4
OHQZLMcX8Hgxh29pBG58R2B4ZM7NApGRjTYLPgFPL5U9Z1Pj84SWBOwVtNZmSkgXzHlGwwE+
z8l67RUFVjQlJVY05xVWNOdd0mlzhaSKXIK/lT1XWNGch+TO7BXYQVsSYUVzHlNFPk+4mrmC
3Isp6VBFafylNHR4+lScXb7iDzW8kj6IpoS7LSycyTZirkbYRug2Imoj4jYiaSPSNqIz17Fg
DjPXV9nubN6uks/VaJOTt8nJ2+TkbXLyNjl5m5y8TU4+R04+Rw5ugHHyGHZbaQmTl8Ju86nA
lE4/igvK6fjiL7tjd+yO3bE7dsfu2B27Y3esxfFf7P7H6gAoBQA=
--------------000701080103080604050800
Content-Type: text/plain; charset=UTF-8;
 name="crash_output.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="crash_output.txt"

INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
 * Stopping local
 [ ok ]
 * Stopping vixie-cron ...
 [ ok ]
 * Saving random seed ...
 [ ok ]
 * Deactivating additional swap space ...
 [ ok ]
 * Stopping sshd ...
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Stopping Xen control daemon ...
 [ ok ]
 * Stoping xenconsoled daemon ...
 [ ok ]
 * Stopping... ...
 [ ok ]
 * Stopping ntpd ...
 [ ok ]
 * Stopping xenstored daemon ...
 [ ok ]
 * Stopping nrpe ...
 [ ok ]
 * Unmounting network filesystems ...
 [ ok ]
 * Stopping munin-node ...
 [ ok ]
 * Stopping fail2ban ...
 [ ok ]
 * Stopping bacula file daemon ...
 [ ok ]
 * Stopping syslog-ng ...
 [ ok ]
 * Bringing down interface br0
 *   Destroying bridge br0 ...
 [ ok ]
 * Bringing down interface bond0
 *   Removing slaves from bond0 ...
 *     eth0 eth1 
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Stopping firewall ...
 [ ok ]
 * Bringing down interface lo
 * Unmounting loop devices
 * Unmounting filesystems
 *   Unmounting /boot ...
 [ ok ]
 *   Unmounting /data/d0700 ...
 [ ok ]
 *   Unmounting /var ...
 [ ok ]
 * Deactivating swap devices ...
 [ ok ]
 * Shutting down the Logical Volume Manager
 *   Shutting Down LVs & VGs ...
  Command failed with status code 2.
  No such command.  Try 'help'.
 * Failed
 [ !! ]
 * Finished Shutting down the Logical Volume Manager
 * Stopping udev ...
 [ ok ]
 * Setting hardware clock using the system clock [UTC] ...
 [ ok ]
 * Terminating remaining processes ...
 [ ok ]
 * Killing remaining processes ...
 [ ok ]
 * Saving dependency cache ...
 [ ok ]
 * Remounting remaining filesystems read-only ...
 *   Remounting / read only ...
 [ ok ]
 [ ok ]
[  612.749666] Restarting system.
[  618.364165] int3: 0000 [#1] SMP 
[  618.364396] Modules linked in: bonding
[  618.364590] CPU 0 
[  618.364658] Pid: 9998, comm: reboot Tainted: G        W    3.7.5-hardened #4 Dell Inc. PowerEdge R720xd/0VWT90
[  618.364806] RIP: e030:[<ffffffff8102a894>]  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
[  618.364956] RSP: e02b:ffff880136b35da8  EFLAGS: 00000046
[  618.365130] RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffffff8172ad90
[  618.365308] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81ad8cdc
[  618.365487] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
[  618.365663] R10: 00000000000005dd R11: 0000000000000000 R12: 0000000000000cf9
[  618.365867] R13: ffffffff8172ad90 R14: 0000000000000061 R15: 0000000000000000
[  618.366045] FS:  00007f32051f0700(0000) GS:ffff88013d600000(0000) knlGS:0000000000000000
[  618.366317] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[  618.366489] CR2: 00007fa697fb3d30 CR3: 0000000135590000 CR4: 0000000000042660
[  618.366664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  618.366839] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  618.367013] Process reboot (pid: 9998, threadinfo ffff880137af3b90, task ffff880137af3780)
[  618.367288] Stack:
[  618.367482]  0000000000000009 0000000081045315 0000000000000000 0000000001234567
[  618.368001]  0000000028121969 0000000000000022 0000000000000000 0000000000000000
[  618.368527]  0000000001234567 0000000028121969 0000000000000022 00007f3205203248
[  618.369079] Call Trace:
[  618.369250]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
[  618.369425]  [<ffffffff8102aab9>] ? machine_restart+0x9/0x10
[  618.369598]  [<ffffffff81059f36>] ? kernel_restart+0x36/0x50
[  618.369771]  [<ffffffff8105a14f>] ? sys_reboot+0x1ef/0x220
[  618.369945]  [<ffffffff816e0d85>] ? _raw_spin_lock+0x5/0x10
[  618.370117]  [<ffffffff81120c76>] ? dput+0x196/0x240
[  618.370288]  [<ffffffff8110af10>] ? __fput+0x160/0x220
[  618.370488]  [<ffffffff8106dcd1>] ? lg_local_lock+0x11/0x20
[  618.370663]  [<ffffffff811287b5>] ? mntput_no_expire+0x25/0x170
[  618.370838]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.371016]  [<ffffffff8106253c>] ? task_work_run+0xac/0xf0
[  618.371187]  [<ffffffff8106dd13>] ? lg_local_lock_cpu+0x13/0x20
[  618.371364]  [<ffffffff816e7897>] ? int_signal+0x12/0x17
[  618.371534]  [<ffffffff816e75e0>] ? system_call_fastpath+0x18/0x1d
[  618.371707] Code: 88 ff ff 0f 1f 40 00 8d 42 9f 83 f8 13 77 f8 ff 24 c5 b8 ac 72 81 4c 89 ef e8 99 95 fd ff 66 90 c7 05 4d 9a 98 00 6b 00 00 00 cc <ba> 6b 00 00 00 eb d5 c6 05 f6 6b ab 00 01 44 89 e2 ec 41 89 c7 
[  618.376270] RIP  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
[  618.376604]  RSP <ffff880136b35da8>
[  618.376799] ---[ end trace ba379a71b4991d2b ]---
[  618.376970] note: reboot[9998] exited with preempt_count 1
[  618.377238] BUG: scheduling while atomic: reboot/9998/0x10000001
[  618.377413] Modules linked in: bonding
[  618.377704] Pid: 9998, comm: reboot Tainted: G      D W    3.7.5-hardened #4
[  618.377878] Call Trace:
[  618.378049]  [<ffffffff816d6fdd>] ? __schedule_bug+0x42/0x4f
[  618.378253]  [<ffffffff816e00ff>] ? __schedule+0x5af/0x640
[  618.378432]  [<ffffffff810fcb06>] ? alloc_pages_current+0xb6/0x130
[  618.378611]  [<ffffffff81004661>] ? __raw_callee_save_xen_pte_val+0x11/0x1e
[  618.378792]  [<ffffffff81070296>] ? __cond_resched+0x16/0x20
[  618.378968]  [<ffffffff816e020a>] ? _cond_resched+0x2a/0x40
[  618.379142]  [<ffffffff810e2aee>] ? unmap_single_vma+0x4be/0x7e0
[  618.379320]  [<ffffffff810e3604>] ? unmap_vmas+0x44/0x90
[  618.379494]  [<ffffffff810ea12f>] ? exit_mmap+0x7f/0x150
[  618.379670]  [<ffffffff81042975>] ? mmput+0x25/0xc0
[  618.379874]  [<ffffffff810491da>] ? exit_mm+0x10a/0x130
[  618.380052]  [<ffffffff8104a604>] ? do_exit+0x174/0x920
[  618.380224]  [<ffffffff816d6c0b>] ? printk+0x4f/0x54
[  618.380395]  [<ffffffff8104b211>] ? do_group_exit+0x41/0xb0
[  618.380569]  [<ffffffff816e21ca>] ? oops_end+0xaa/0xf0
[  618.380746]  [<ffffffff816e1dbd>] ? do_int3+0x8d/0xe0
[  618.380916]  [<ffffffff816e14fe>] ? xen_int3+0x1e/0x30
[  618.381086]  [<ffffffff8102a894>] ? native_machine_emergency_restart+0x74/0x250
[  618.381387]  [<ffffffff8102a887>] ? native_machine_emergency_restart+0x67/0x250
[  618.381658]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
[  618.381832]  [<ffffffff8102aab9>] ? machine_restart+0x9/0x10
[  618.382004]  [<ffffffff81059f36>] ? kernel_restart+0x36/0x50
[  618.382175]  [<ffffffff8105a14f>] ? sys_reboot+0x1ef/0x220
[  618.382345]  [<ffffffff816e0d85>] ? _raw_spin_lock+0x5/0x10
[  618.382516]  [<ffffffff81120c76>] ? dput+0x196/0x240
[  618.382685]  [<ffffffff8110af10>] ? __fput+0x160/0x220
[  618.382890]  [<ffffffff8106dcd1>] ? lg_local_lock+0x11/0x20
[  618.383067]  [<ffffffff811287b5>] ? mntput_no_expire+0x25/0x170
[  618.383247]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.383426]  [<ffffffff8106253c>] ? task_work_run+0xac/0xf0
[  618.383599]  [<ffffffff8106dd13>] ? lg_local_lock_cpu+0x13/0x20
[  618.383771]  [<ffffffff816e7897>] ? int_signal+0x12/0x17
[  618.383943]  [<ffffffff816e75e0>] ? system_call_fastpath+0x18/0x1d
[  618.384191] BUG: scheduling while atomic: reboot/9998/0x10000001
[  618.384364] Modules linked in: bonding
[  618.384696] Pid: 9998, comm: reboot Tainted: G      D W    3.7.5-hardened #4
[  618.384872] Call Trace:
[  618.385040]  [<ffffffff816d6fdd>] ? __schedule_bug+0x42/0x4f
[  618.385215]  [<ffffffff816e00ff>] ? __schedule+0x5af/0x640
[  618.385397]  [<ffffffff81070296>] ? __cond_resched+0x16/0x20
[  618.385570]  [<ffffffff816e020a>] ? _cond_resched+0x2a/0x40
[  618.385743]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.385918]  [<ffffffff81062559>] ? task_work_run+0xc9/0xf0
[  618.386121]  [<ffffffff8104ab42>] ? do_exit+0x6b2/0x920
[  618.386294]  [<ffffffff816d6c0b>] ? printk+0x4f/0x54
[  618.386465]  [<ffffffff8104b211>] ? do_group_exit+0x41/0xb0
[  618.386639]  [<ffffffff816e21ca>] ? oops_end+0xaa/0xf0
[  618.386814]  [<ffffffff816e1dbd>] ? do_int3+0x8d/0xe0
[  618.386989]  [<ffffffff816e14fe>] ? xen_int3+0x1e/0x30
[  618.387163]  [<ffffffff8102a894>] ? native_machine_emergency_restart+0x74/0x250
[  618.387437]  [<ffffffff8102a887>] ? native_machine_emergency_restart+0x67/0x250
[  618.387752]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
[  618.387928]  [<ffffffff8102aab9>] ? machine_restart+0x9/0x10
[  618.390113]  [<ffffffff81059f36>] ? kernel_restart+0x36/0x50
[  618.390288]  [<ffffffff8105a14f>] ? sys_reboot+0x1ef/0x220
[  618.390480]  [<ffffffff816e0d85>] ? _raw_spin_lock+0x5/0x10
[  618.390686]  [<ffffffff81120c76>] ? dput+0x196/0x240
[  618.390856]  [<ffffffff8110af10>] ? __fput+0x160/0x220
[  618.391028]  [<ffffffff8106dcd1>] ? lg_local_lock+0x11/0x20
[  618.391199]  [<ffffffff811287b5>] ? mntput_no_expire+0x25/0x170
[  618.391372]  [<ffffffff8106dcf1>] ? lg_local_unlock+0x11/0x20
[  618.391544]  [<ffffffff8106253c>] ? task_work_run+0xac/0xf0
[  618.391714]  [<ffffffff8106dd13>] ? lg_local_lock_cpu+0x13/0x20
[  618.391887]  [<ffffffff816e7897>] ? int_signal+0x12/0x17
[  618.392057]  [<ffffffff816e75e0>] ? system_call_fastpath+0x18/0x1d
INIT: no more processes left in this runlevel

--------------000701080103080604050800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000701080103080604050800--


From xen-devel-bounces@lists.xen.org Tue Feb 26 15:01:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:01: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 1UAM25-0004Uo-ML; Tue, 26 Feb 2013 15:01:29 +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 1UAM23-0004Uh-S9
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:01:28 +0000
Received: from [85.158.137.99:48002] by server-13.bemta-3.messagelabs.com id
	2D/9B-20653-83ECC215; Tue, 26 Feb 2013 15:01:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361890842!14858256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11967 invoked from network); 26 Feb 2013 15:00:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:00:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9702000"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 15:00:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 10:00:42 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAM1J-0006ru-KB;
	Tue, 26 Feb 2013 15:00:41 +0000
Message-ID: <512CCE19.8070304@eu.citrix.com>
Date: Tue, 26 Feb 2013 15:00:41 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
In-Reply-To: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/18/2013 12:37 PM, Jan Beulich wrote:
> This should help with under-accounting of vCPU-s running for extremly
> short periods of time, but becoming runnable again at a high frequency.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The changes to credit1 look good, and I'm fine with a patch having those 
(and a commented ASSERT) go in.

Credit2 I'm not so happy with, because the names "t2c" and "c2t" imply 
(at least to me) that they are only converting, not changing anything; 
particularly in the way that t2c is called.  At the moment everything 
will work fine, but it's just laying a trap for someone in the future. :-)

I've got a patch in my queue dealing with this section already -- why 
don't you apply just the sched_credit.c part of the patch, and I'll take 
the credit2 part of your patch and rework it so it satisfies me.

  -George



>
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -19,6 +19,7 @@
>   #include <xen/sched-if.h>
>   #include <xen/softirq.h>
>   #include <asm/atomic.h>
> +#include <asm/div64.h>
>   #include <xen/errno.h>
>   #include <xen/keyhandler.h>
>   #include <xen/trace.h>
> @@ -136,6 +137,7 @@ struct csched_vcpu {
>       struct csched_dom *sdom;
>       struct vcpu *vcpu;
>       atomic_t credit;
> +    unsigned int residual;
>       s_time_t start_time;   /* When we were scheduled (used for credit) */
>       uint16_t flags;
>       int16_t pri;
> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>   {
>       s_time_t delta;
> +    uint64_t val;
>       unsigned int credits;
>
>       /* Assert svc is current */
> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>       if ( (delta = now - svc->start_time) <= 0 )
>           return;
>
> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> +    svc->residual = do_div(val, MILLISECS(1));
> +    credits = val;
> +    ASSERT(credits == val);
>       atomic_sub(credits, &svc->credit);
>       svc->start_time += (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;
>   }
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -21,7 +21,7 @@
>   #include <xen/perfc.h>
>   #include <xen/sched-if.h>
>   #include <xen/softirq.h>
> -#include <asm/atomic.h>
> +#include <asm/div64.h>
>   #include <xen/errno.h>
>   #include <xen/trace.h>
>   #include <xen/cpu.h>
> @@ -205,7 +205,7 @@ struct csched_runqueue_data {
>
>       struct list_head runq; /* Ordered list of runnable vms */
>       struct list_head svc;  /* List of all vcpus assigned to this runqueue */
> -    int max_weight;
> +    unsigned int max_weight;
>
>       cpumask_t idle,        /* Currently idle */
>           tickled;           /* Another cpu in the queue is already targeted for this one */
> @@ -244,7 +244,8 @@ struct csched_vcpu {
>       struct csched_dom *sdom;
>       struct vcpu *vcpu;
>
> -    int weight;
> +    unsigned int weight;
> +    unsigned int residual;
>
>       int credit;
>       s_time_t start_time; /* When we were scheduled (used for credit) */
> @@ -275,12 +276,15 @@ struct csched_dom {
>    */
>   static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
>   {
> -    return time * rqd->max_weight / svc->weight;
> +    uint64_t val = time * rqd->max_weight + svc->residual;
> +
> +    svc->residual = do_div(val, svc->weight);
> +    return val;
>   }
>
>   static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
>   {
> -    return credit * svc->weight / rqd->max_weight;
> +    return (credit * svc->weight - svc->residual) / rqd->max_weight;
>   }
>
>   /*
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:01:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:01: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 1UAM25-0004Uo-ML; Tue, 26 Feb 2013 15:01:29 +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 1UAM23-0004Uh-S9
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:01:28 +0000
Received: from [85.158.137.99:48002] by server-13.bemta-3.messagelabs.com id
	2D/9B-20653-83ECC215; Tue, 26 Feb 2013 15:01:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361890842!14858256!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11967 invoked from network); 26 Feb 2013 15:00:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:00:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9702000"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 15:00:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 10:00:42 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAM1J-0006ru-KB;
	Tue, 26 Feb 2013 15:00:41 +0000
Message-ID: <512CCE19.8070304@eu.citrix.com>
Date: Tue, 26 Feb 2013 15:00:41 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
In-Reply-To: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/18/2013 12:37 PM, Jan Beulich wrote:
> This should help with under-accounting of vCPU-s running for extremly
> short periods of time, but becoming runnable again at a high frequency.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The changes to credit1 look good, and I'm fine with a patch having those 
(and a commented ASSERT) go in.

Credit2 I'm not so happy with, because the names "t2c" and "c2t" imply 
(at least to me) that they are only converting, not changing anything; 
particularly in the way that t2c is called.  At the moment everything 
will work fine, but it's just laying a trap for someone in the future. :-)

I've got a patch in my queue dealing with this section already -- why 
don't you apply just the sched_credit.c part of the patch, and I'll take 
the credit2 part of your patch and rework it so it satisfies me.

  -George



>
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -19,6 +19,7 @@
>   #include <xen/sched-if.h>
>   #include <xen/softirq.h>
>   #include <asm/atomic.h>
> +#include <asm/div64.h>
>   #include <xen/errno.h>
>   #include <xen/keyhandler.h>
>   #include <xen/trace.h>
> @@ -136,6 +137,7 @@ struct csched_vcpu {
>       struct csched_dom *sdom;
>       struct vcpu *vcpu;
>       atomic_t credit;
> +    unsigned int residual;
>       s_time_t start_time;   /* When we were scheduled (used for credit) */
>       uint16_t flags;
>       int16_t pri;
> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>   {
>       s_time_t delta;
> +    uint64_t val;
>       unsigned int credits;
>
>       /* Assert svc is current */
> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>       if ( (delta = now - svc->start_time) <= 0 )
>           return;
>
> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);
> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
> +    svc->residual = do_div(val, MILLISECS(1));
> +    credits = val;
> +    ASSERT(credits == val);
>       atomic_sub(credits, &svc->credit);
>       svc->start_time += (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;
>   }
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -21,7 +21,7 @@
>   #include <xen/perfc.h>
>   #include <xen/sched-if.h>
>   #include <xen/softirq.h>
> -#include <asm/atomic.h>
> +#include <asm/div64.h>
>   #include <xen/errno.h>
>   #include <xen/trace.h>
>   #include <xen/cpu.h>
> @@ -205,7 +205,7 @@ struct csched_runqueue_data {
>
>       struct list_head runq; /* Ordered list of runnable vms */
>       struct list_head svc;  /* List of all vcpus assigned to this runqueue */
> -    int max_weight;
> +    unsigned int max_weight;
>
>       cpumask_t idle,        /* Currently idle */
>           tickled;           /* Another cpu in the queue is already targeted for this one */
> @@ -244,7 +244,8 @@ struct csched_vcpu {
>       struct csched_dom *sdom;
>       struct vcpu *vcpu;
>
> -    int weight;
> +    unsigned int weight;
> +    unsigned int residual;
>
>       int credit;
>       s_time_t start_time; /* When we were scheduled (used for credit) */
> @@ -275,12 +276,15 @@ struct csched_dom {
>    */
>   static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
>   {
> -    return time * rqd->max_weight / svc->weight;
> +    uint64_t val = time * rqd->max_weight + svc->residual;
> +
> +    svc->residual = do_div(val, svc->weight);
> +    return val;
>   }
>
>   static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
>   {
> -    return credit * svc->weight / rqd->max_weight;
> +    return (credit * svc->weight - svc->residual) / rqd->max_weight;
>   }
>
>   /*
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:04:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:04: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 1UAM4G-0004cl-6v; Tue, 26 Feb 2013 15:03:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1UAM4E-0004cb-Ii
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:03:42 +0000
Received: from [85.158.139.83:46683] by server-16.bemta-5.messagelabs.com id
	52/F1-02543-DCECC215; Tue, 26 Feb 2013 15:03:41 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361891021!21833389!1
X-Originating-IP: [74.125.83.52]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30002 invoked from network); 26 Feb 2013 15:03:41 -0000
Received: from mail-ee0-f52.google.com (HELO mail-ee0-f52.google.com)
	(74.125.83.52)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:03:41 -0000
Received: by mail-ee0-f52.google.com with SMTP id b15so2255825eek.25
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 07:03:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=PKhaUuDB+QkDYV3MMaz27QwjB2M/+0ekGhqSVxLLDrM=;
	b=DklhiEGusBEfRlQQaZwDFoDqpkKs8ioxxzTTd8/8Kd9IQI/G7TQy/upbPj7RPdykG1
	ZqSdPqkN6TZT1bGntmC/R2DSRj44uuTEqG0nOedmkeXxgPHKYfjfFL2Wbq3fjYkZ+ZHL
	V+VCLtjziqiCpZhBHOdmWwhCOrP1OQPO1eoa2ILMwVVF0KW1G88SM2OLXIXOhA47pDlm
	p8CLHYWo8PFN73VTRZIwgnPN6QimVXQW8HX6QltDuMxYzh+KbOdgBDk+v4cV6Lt+5+we
	jvUuMPfyOayFuhmLsni2JTnrxLLWn34jrRR9dPJjfQuO7SXlMuwzUDVG0vVT7iWKTz1m
	3uww==
X-Received: by 10.14.175.70 with SMTP id y46mr50578233eel.6.1361891001782;
	Tue, 26 Feb 2013 07:03:21 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id s3sm1920501eem.4.2013.02.26.07.03.19
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 07:03:20 -0800 (PST)
Message-ID: <512CCEB9.3060109@heliman.it>
Date: Tue, 26 Feb 2013 16:03:21 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Alex Bligh <alex@alex.org.uk>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it>
	<931493278BD056D168E0B849@Ximines.local>
In-Reply-To: <931493278BD056D168E0B849@Ximines.local>
X-Gm-Message-State: ALoCoQlyFV16C0n+FoEpHSWmuYgdhyIesuEKIrWIqlcY1MgGIo6HFx3/mE9PCtBf6IuQLcYOnYmm
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	fantonifabio@tiscali.it
Subject: Re: [Xen-devel] [PATCH v2] 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-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

Il 26/02/2013 15:23, Alex Bligh ha scritto:
>
>
> --On 26 February 2013 15:16:44 +0100 Fabio Fantoni 
> <fabio.fantoni@heliman.it> wrote:
>
>> Sorry, Ian is right on this. I learned how to create deb packages
>> according to the standards in the last months, I had better double check
>> the patch.
>> I'll redo init with update-rc.d in next patch version.
>
> Feel free to steal the code from my minideb patch.
>
Your package is using debhelper and devscripts, here I'll do only 
minimal deb for "make dist" that seem sufficent for devel/testing.
About your package for production use is very important  to remove 
version from name to make it correctly upgradable.
If you want to do complete xen package to add for example in ubuntu 
launchpad until debian official will be complete, these can be useful:
- use seabios of debian repository using this patch (already tested and 
working):
http://anonscm.debian.org/viewvc/pkg-xen/trunk/xen/debian/patches/tools-firmware-seabios-packaged.diff?view=markup
- use upstream qemu 1.3 or 1.4 from repository (patch to do), I already 
tested qemu package from debian experimental manually, is full working 
and with also spice and usbredir included (missed for now on upstream 
xen build of qemu-xen)

I think the best thing is test and help official debian package, if I 
remember well was:
svn co svn://svn.debian.org/pkg-xen/trunk
# Put the debian folder into xen souce folder
# Use quilt for update patches if you use earlier version
fakeroot debian/rules debian/control # to generate control file
debuild -i -b -us -uc # To test the build

When I have sufficent time I'll help it.

@Ian or Stefano:
About use upstream qemu from debian package on xen debian package:
Do I need to only remove the build (similar to seabios packaged patch) 
or may I also need to patch libxl/xm?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:04:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:04: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 1UAM4G-0004cl-6v; Tue, 26 Feb 2013 15:03:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1UAM4E-0004cb-Ii
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:03:42 +0000
Received: from [85.158.139.83:46683] by server-16.bemta-5.messagelabs.com id
	52/F1-02543-DCECC215; Tue, 26 Feb 2013 15:03:41 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361891021!21833389!1
X-Originating-IP: [74.125.83.52]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30002 invoked from network); 26 Feb 2013 15:03:41 -0000
Received: from mail-ee0-f52.google.com (HELO mail-ee0-f52.google.com)
	(74.125.83.52)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:03:41 -0000
Received: by mail-ee0-f52.google.com with SMTP id b15so2255825eek.25
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 07:03:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=PKhaUuDB+QkDYV3MMaz27QwjB2M/+0ekGhqSVxLLDrM=;
	b=DklhiEGusBEfRlQQaZwDFoDqpkKs8ioxxzTTd8/8Kd9IQI/G7TQy/upbPj7RPdykG1
	ZqSdPqkN6TZT1bGntmC/R2DSRj44uuTEqG0nOedmkeXxgPHKYfjfFL2Wbq3fjYkZ+ZHL
	V+VCLtjziqiCpZhBHOdmWwhCOrP1OQPO1eoa2ILMwVVF0KW1G88SM2OLXIXOhA47pDlm
	p8CLHYWo8PFN73VTRZIwgnPN6QimVXQW8HX6QltDuMxYzh+KbOdgBDk+v4cV6Lt+5+we
	jvUuMPfyOayFuhmLsni2JTnrxLLWn34jrRR9dPJjfQuO7SXlMuwzUDVG0vVT7iWKTz1m
	3uww==
X-Received: by 10.14.175.70 with SMTP id y46mr50578233eel.6.1361891001782;
	Tue, 26 Feb 2013 07:03:21 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id s3sm1920501eem.4.2013.02.26.07.03.19
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 07:03:20 -0800 (PST)
Message-ID: <512CCEB9.3060109@heliman.it>
Date: Tue, 26 Feb 2013 16:03:21 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Alex Bligh <alex@alex.org.uk>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it>
	<931493278BD056D168E0B849@Ximines.local>
In-Reply-To: <931493278BD056D168E0B849@Ximines.local>
X-Gm-Message-State: ALoCoQlyFV16C0n+FoEpHSWmuYgdhyIesuEKIrWIqlcY1MgGIo6HFx3/mE9PCtBf6IuQLcYOnYmm
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	fantonifabio@tiscali.it
Subject: Re: [Xen-devel] [PATCH v2] 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-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

Il 26/02/2013 15:23, Alex Bligh ha scritto:
>
>
> --On 26 February 2013 15:16:44 +0100 Fabio Fantoni 
> <fabio.fantoni@heliman.it> wrote:
>
>> Sorry, Ian is right on this. I learned how to create deb packages
>> according to the standards in the last months, I had better double check
>> the patch.
>> I'll redo init with update-rc.d in next patch version.
>
> Feel free to steal the code from my minideb patch.
>
Your package is using debhelper and devscripts, here I'll do only 
minimal deb for "make dist" that seem sufficent for devel/testing.
About your package for production use is very important  to remove 
version from name to make it correctly upgradable.
If you want to do complete xen package to add for example in ubuntu 
launchpad until debian official will be complete, these can be useful:
- use seabios of debian repository using this patch (already tested and 
working):
http://anonscm.debian.org/viewvc/pkg-xen/trunk/xen/debian/patches/tools-firmware-seabios-packaged.diff?view=markup
- use upstream qemu 1.3 or 1.4 from repository (patch to do), I already 
tested qemu package from debian experimental manually, is full working 
and with also spice and usbredir included (missed for now on upstream 
xen build of qemu-xen)

I think the best thing is test and help official debian package, if I 
remember well was:
svn co svn://svn.debian.org/pkg-xen/trunk
# Put the debian folder into xen souce folder
# Use quilt for update patches if you use earlier version
fakeroot debian/rules debian/control # to generate control file
debuild -i -b -us -uc # To test the build

When I have sufficent time I'll help it.

@Ian or Stefano:
About use upstream qemu from debian package on xen debian package:
Do I need to only remove the build (similar to seabios packaged patch) 
or may I also need to patch libxl/xm?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:07:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAM88-0004mJ-SF; Tue, 26 Feb 2013 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 <JBeulich@suse.com>) id 1UAM88-0004mE-5s
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:07:44 +0000
Received: from [85.158.138.51:39692] by server-4.bemta-3.messagelabs.com id
	BD/68-17521-FBFCC215; Tue, 26 Feb 2013 15:07:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361891249!27915388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8578 invoked from network); 26 Feb 2013 15:07:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:07:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 15:07:29 +0000
Message-Id: <512CDDC002000078000C11E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:07:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<512CCE19.8070304@eu.citrix.com>
In-Reply-To: <512CCE19.8070304@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:00, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 02/18/2013 12:37 PM, Jan Beulich wrote:
>> This should help with under-accounting of vCPU-s running for extremly
>> short periods of time, but becoming runnable again at a high frequency.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> The changes to credit1 look good, and I'm fine with a patch having those 
> (and a commented ASSERT) go in.
> 
> Credit2 I'm not so happy with, because the names "t2c" and "c2t" imply 
> (at least to me) that they are only converting, not changing anything; 
> particularly in the way that t2c is called.  At the moment everything 
> will work fine, but it's just laying a trap for someone in the future. :-)
> 
> I've got a patch in my queue dealing with this section already -- why 
> don't you apply just the sched_credit.c part of the patch, and I'll take 
> the credit2 part of your patch and rework it so it satisfies me.

That's fine with me of course.

May I take the above as a pre-ack to a patch modified accordingly?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:07:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAM88-0004mJ-SF; Tue, 26 Feb 2013 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 <JBeulich@suse.com>) id 1UAM88-0004mE-5s
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:07:44 +0000
Received: from [85.158.138.51:39692] by server-4.bemta-3.messagelabs.com id
	BD/68-17521-FBFCC215; Tue, 26 Feb 2013 15:07:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361891249!27915388!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8578 invoked from network); 26 Feb 2013 15:07:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:07:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 15:07:29 +0000
Message-Id: <512CDDC002000078000C11E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:07:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<512CCE19.8070304@eu.citrix.com>
In-Reply-To: <512CCE19.8070304@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:00, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 02/18/2013 12:37 PM, Jan Beulich wrote:
>> This should help with under-accounting of vCPU-s running for extremly
>> short periods of time, but becoming runnable again at a high frequency.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> The changes to credit1 look good, and I'm fine with a patch having those 
> (and a commented ASSERT) go in.
> 
> Credit2 I'm not so happy with, because the names "t2c" and "c2t" imply 
> (at least to me) that they are only converting, not changing anything; 
> particularly in the way that t2c is called.  At the moment everything 
> will work fine, but it's just laying a trap for someone in the future. :-)
> 
> I've got a patch in my queue dealing with this section already -- why 
> don't you apply just the sched_credit.c part of the patch, and I'll take 
> the credit2 part of your patch and rework it so it satisfies me.

That's fine with me of course.

May I take the above as a pre-ack to a patch modified accordingly?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:12:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:12: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 1UAMCl-00052c-KP; Tue, 26 Feb 2013 15:12:31 +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 1UAMCk-00052W-P5
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:12:31 +0000
Received: from [85.158.137.99:10593] by server-11.bemta-3.messagelabs.com id
	56/AB-10249-9D0DC215; Tue, 26 Feb 2013 15:12:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361891530!18152462!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21950 invoked from network); 26 Feb 2013 15:12:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:12:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9232119"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 15:11:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 10:11:10 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAMBR-00071G-SA;
	Tue, 26 Feb 2013 15:11:09 +0000
Message-ID: <512CD08D.7010504@eu.citrix.com>
Date: Tue, 26 Feb 2013 15:11:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<512CCE19.8070304@eu.citrix.com>
	<512CDDC002000078000C11E3@nat28.tlf.novell.com>
In-Reply-To: <512CDDC002000078000C11E3@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/26/2013 03:07 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 16:00, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> On 02/18/2013 12:37 PM, Jan Beulich wrote:
>>> This should help with under-accounting of vCPU-s running for extremly
>>> short periods of time, but becoming runnable again at a high frequency.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> The changes to credit1 look good, and I'm fine with a patch having those
>> (and a commented ASSERT) go in.
>>
>> Credit2 I'm not so happy with, because the names "t2c" and "c2t" imply
>> (at least to me) that they are only converting, not changing anything;
>> particularly in the way that t2c is called.  At the moment everything
>> will work fine, but it's just laying a trap for someone in the future. :-)
>>
>> I've got a patch in my queue dealing with this section already -- why
>> don't you apply just the sched_credit.c part of the patch, and I'll take
>> the credit2 part of your patch and rework it so it satisfies me.
>
> That's fine with me of course.
>
> May I take the above as a pre-ack to a patch modified accordingly?

Yes, I suppose that's fine. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:12:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:12: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 1UAMCl-00052c-KP; Tue, 26 Feb 2013 15:12:31 +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 1UAMCk-00052W-P5
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:12:31 +0000
Received: from [85.158.137.99:10593] by server-11.bemta-3.messagelabs.com id
	56/AB-10249-9D0DC215; Tue, 26 Feb 2013 15:12:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361891530!18152462!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21950 invoked from network); 26 Feb 2013 15:12:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:12:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="9232119"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 15:11:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 10:11:10 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<george.dunlap@eu.citrix.com>)	id 1UAMBR-00071G-SA;
	Tue, 26 Feb 2013 15:11:09 +0000
Message-ID: <512CD08D.7010504@eu.citrix.com>
Date: Tue, 26 Feb 2013 15:11:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<512CCE19.8070304@eu.citrix.com>
	<512CDDC002000078000C11E3@nat28.tlf.novell.com>
In-Reply-To: <512CDDC002000078000C11E3@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/26/2013 03:07 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 16:00, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> On 02/18/2013 12:37 PM, Jan Beulich wrote:
>>> This should help with under-accounting of vCPU-s running for extremly
>>> short periods of time, but becoming runnable again at a high frequency.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> The changes to credit1 look good, and I'm fine with a patch having those
>> (and a commented ASSERT) go in.
>>
>> Credit2 I'm not so happy with, because the names "t2c" and "c2t" imply
>> (at least to me) that they are only converting, not changing anything;
>> particularly in the way that t2c is called.  At the moment everything
>> will work fine, but it's just laying a trap for someone in the future. :-)
>>
>> I've got a patch in my queue dealing with this section already -- why
>> don't you apply just the sched_credit.c part of the patch, and I'll take
>> the credit2 part of your patch and rework it so it satisfies me.
>
> That's fine with me of course.
>
> May I take the above as a pre-ack to a patch modified accordingly?

Yes, I suppose that's fine. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:13:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMDk-00056F-3V; Tue, 26 Feb 2013 15:13: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 1UAMDi-000564-Pc
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:13:31 +0000
Received: from [85.158.138.51:22698] by server-9.bemta-3.messagelabs.com id
	46/03-09484-511DC215; Tue, 26 Feb 2013 15:13:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361891552!20406933!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28035 invoked from network); 26 Feb 2013 15:12:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:12:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1906875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 15:12: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.297.1;
	Tue, 26 Feb 2013 15:12:32 +0000
Message-ID: <1361891550.26546.301.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Tue, 26 Feb 2013 15:12:30 +0000
In-Reply-To: <512CCEB9.3060109@heliman.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it> <931493278BD056D168E0B849@Ximines.local>
	<512CCEB9.3060109@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
> @Ian or Stefano:
> About use upstream qemu from debian package on xen debian package:
> Do I need to only remove the build (similar to seabios packaged patch)
> or may I also need to patch libxl/xm?

Probably you'd need to patch libxl (but not xm) too.

On my todo list I have an action to make the configure script understand
--with-system-qemu=PATH, which would disable the qemu-xen build and
cause libxl to use $PATH (default /usr/bin/qemu?) instead
of /usr/lib/xen/bin/blah. If someone else were to get there first that
would be awesome!

./configure --(enable|disable)-qemu-traditional (i.e. just turn the
build off and on) would be quite useful too I think. As would making
libxl handle the absence of either a little more gracefully.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:13:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMDk-00056F-3V; Tue, 26 Feb 2013 15:13: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 1UAMDi-000564-Pc
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:13:31 +0000
Received: from [85.158.138.51:22698] by server-9.bemta-3.messagelabs.com id
	46/03-09484-511DC215; Tue, 26 Feb 2013 15:13:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361891552!20406933!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28035 invoked from network); 26 Feb 2013 15:12:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:12:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; 
   d="scan'208";a="1906875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 15:12: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.297.1;
	Tue, 26 Feb 2013 15:12:32 +0000
Message-ID: <1361891550.26546.301.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Tue, 26 Feb 2013 15:12:30 +0000
In-Reply-To: <512CCEB9.3060109@heliman.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it> <931493278BD056D168E0B849@Ximines.local>
	<512CCEB9.3060109@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
> @Ian or Stefano:
> About use upstream qemu from debian package on xen debian package:
> Do I need to only remove the build (similar to seabios packaged patch)
> or may I also need to patch libxl/xm?

Probably you'd need to patch libxl (but not xm) too.

On my todo list I have an action to make the configure script understand
--with-system-qemu=PATH, which would disable the qemu-xen build and
cause libxl to use $PATH (default /usr/bin/qemu?) instead
of /usr/lib/xen/bin/blah. If someone else were to get there first that
would be awesome!

./configure --(enable|disable)-qemu-traditional (i.e. just turn the
build off and on) would be quite useful too I think. As would making
libxl handle the absence of either a little more gracefully.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:21:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UAMKn-0005Oh-0n; Tue, 26 Feb 2013 15:20:49 +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 1UAMKk-0005Oc-Uk
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:20:47 +0000
Received: from [85.158.139.211:19705] by server-3.bemta-5.messagelabs.com id
	25/FA-17256-EC2DC215; Tue, 26 Feb 2013 15:20:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361892043!18715314!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5897 invoked from network); 26 Feb 2013 15:20:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:20:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QFKeod014195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 15:20: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
	r1QFKevm023827
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 15:20: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
	r1QFKdqp019411; Tue, 26 Feb 2013 09:20:39 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 07:20:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8BD421C3935; Tue, 26 Feb 2013 10:20:38 -0500 (EST)
Date: Tue, 26 Feb 2013 10:20:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130226152038.GA15154@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <312569942.20130225231830@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Mon, Feb 25, 2013 at 11:18:30PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> I can't get linux-3.9 rc0 to boot under xen-unstable.
> It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.
> 
> I don't see a obvious error in the logs.
> 
> The same kernel boots fine on baremetal.
> With linux 3.8 it boots fine under this version of xen-unstable.
> 
> Can you spot something from the logs or you have a hunch from where to start a bisect ?
> (bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

There are at least two pitfalls - the
14e568e78f6f80ca1e27256641ddf524c7dbdc51 (which you can revert) and you need
to make sure you have 0cc9129d75ef8993702d97ab0e49542c15ac6ab9
if you end up in the merge 2ef14f465b9e096531343f5b734cffc5f759f4a6
("Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")


> 
> 3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

Interestingly I can reproduce it on my F1A75-M box as well.

With baremetal I get:
[   12.701221] ahci 0000:00:11.0: version 3.0
[   12.701424] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 528175 usecs
[   12.712999] ahci 0000:00:11.0: irq 46 for MSI/MSI-X
[   12.717967] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[   12.726132] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
[   12.735405] scsi0 : ahci
[   12.738087] scsi1 : ahci
[   12.740734] scsi2 : ahci
[   12.743511] scsi3 : ahci
[   12.746278] scsi4 : ahci
[   12.748930] scsi5 : ahci

And when booting under Xen 4.1 (note, no IOMMU):

[   19.178696] ahci 0000:00:11.0: version 3.0
[   19.178721] xen: registering gsi 19 triggering 0 polarity 1
[   19.178743] xen: --> pirq=19 -> irq=19 (gsi=19)
[   19.179040] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[   19.179043] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
[   19.241748] ahci: probe of 0000:00:11.0 failed with error -22
[   19.249124] initcall ahci_pci_driver_init+0x0/0x1000 [ahci] returned 0 after 460418 usecs

Had you tried to checkout right before this mega update from Jeff Garzik:

ab78265 Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
21fbd58 Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
d9978ec Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
==> 77be36d Merge tag 'stable/for-linus-3.9-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

And seeing if that works?
> 
> --
> Sander
> 
> Attached:
> - Serial log with 3.9-rc0 kernel (missing sata)
> - Serial log with 3.8 kernel (booting fine
> - .config





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:21:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UAMKn-0005Oh-0n; Tue, 26 Feb 2013 15:20:49 +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 1UAMKk-0005Oc-Uk
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:20:47 +0000
Received: from [85.158.139.211:19705] by server-3.bemta-5.messagelabs.com id
	25/FA-17256-EC2DC215; Tue, 26 Feb 2013 15:20:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361892043!18715314!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5897 invoked from network); 26 Feb 2013 15:20:45 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:20:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QFKeod014195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 15:20: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
	r1QFKevm023827
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 15:20: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
	r1QFKdqp019411; Tue, 26 Feb 2013 09:20:39 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 07:20:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8BD421C3935; Tue, 26 Feb 2013 10:20:38 -0500 (EST)
Date: Tue, 26 Feb 2013 10:20:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130226152038.GA15154@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <312569942.20130225231830@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Mon, Feb 25, 2013 at 11:18:30PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> I can't get linux-3.9 rc0 to boot under xen-unstable.
> It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.
> 
> I don't see a obvious error in the logs.
> 
> The same kernel boots fine on baremetal.
> With linux 3.8 it boots fine under this version of xen-unstable.
> 
> Can you spot something from the logs or you have a hunch from where to start a bisect ?
> (bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

There are at least two pitfalls - the
14e568e78f6f80ca1e27256641ddf524c7dbdc51 (which you can revert) and you need
to make sure you have 0cc9129d75ef8993702d97ab0e49542c15ac6ab9
if you end up in the merge 2ef14f465b9e096531343f5b734cffc5f759f4a6
("Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")


> 
> 3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

Interestingly I can reproduce it on my F1A75-M box as well.

With baremetal I get:
[   12.701221] ahci 0000:00:11.0: version 3.0
[   12.701424] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 528175 usecs
[   12.712999] ahci 0000:00:11.0: irq 46 for MSI/MSI-X
[   12.717967] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[   12.726132] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
[   12.735405] scsi0 : ahci
[   12.738087] scsi1 : ahci
[   12.740734] scsi2 : ahci
[   12.743511] scsi3 : ahci
[   12.746278] scsi4 : ahci
[   12.748930] scsi5 : ahci

And when booting under Xen 4.1 (note, no IOMMU):

[   19.178696] ahci 0000:00:11.0: version 3.0
[   19.178721] xen: registering gsi 19 triggering 0 polarity 1
[   19.178743] xen: --> pirq=19 -> irq=19 (gsi=19)
[   19.179040] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[   19.179043] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
[   19.241748] ahci: probe of 0000:00:11.0 failed with error -22
[   19.249124] initcall ahci_pci_driver_init+0x0/0x1000 [ahci] returned 0 after 460418 usecs

Had you tried to checkout right before this mega update from Jeff Garzik:

ab78265 Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
21fbd58 Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
d9978ec Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
==> 77be36d Merge tag 'stable/for-linus-3.9-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

And seeing if that works?
> 
> --
> Sander
> 
> Attached:
> - Serial log with 3.9-rc0 kernel (missing sata)
> - Serial log with 3.8 kernel (booting fine
> - .config





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:28:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:28: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 1UAMRq-0005au-Tn; Tue, 26 Feb 2013 15:28:06 +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 1UAMRp-0005ap-Qj
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:28:06 +0000
Received: from [193.109.254.147:39354] by server-10.bemta-14.messagelabs.com
	id 6A/3E-12679-584DC215; Tue, 26 Feb 2013 15:28:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361892441!6085870!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13164 invoked from network); 26 Feb 2013 15:27:22 -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; 26 Feb 2013 15:27:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAMR5-000PFR-GN; Tue, 26 Feb 2013 15:27:19 +0000
Date: Tue, 26 Feb 2013 15:27:19 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226152719.GD93966@ocelot.phlegethon.org>
References: <512B844C02000078000C0C75@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512B844C02000078000C0C75@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XENMEM_maximum_gpfn return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:33 +0000 on 25 Feb (1361802812), Jan Beulich wrote:
> This coming from a shared info field, it has to be assumed to possibly
> have any value. In particular, our kernels don't set up this field at all
> if running as Dom0 and kexec isn't enabled (along with not setting up
> the P2M frame lists, as that's simply wasted memory in that case).
> 
> So, with this being a guest provided value, we apparently have two
> problems: do_memory_op()'s "rc" variable is only of type "int", thus
> potentially truncating the result of domain_get_maximum_gpfn()
> (considering that we now support 16Tb, an 8Tb+ guest ought to
> be possible, and such would have a max GPFN with 32 significant
> bits). And zero or a very large number being returned by the latter
> will generally be mistaken as an error code by the caller of the
> hypercall.
> 
> So, along with promoting "rc" to long, I'm considering enforcing a
> sane lower bound on domain_get_maximum_gpfn()'s return value,
> using d->tot_pages (under the assumption that each page would
> have a representation in the physical map, and hence the
> physical map can't reasonably be smaller than this). That would
> overcome the subtraction of 1 done there for PV guests to
> convert 0 to -1 (i.e. -EPERM). Similarly, a sane upper bound
> ought to be enforced (to avoid collisions with the -E range).
> 
> Other thoughts? Is such a behavioral change acceptable for an
> existing interface?

The new behaviour seems sensible but I'm a little worried about changing
the behaviour of an existing call.  I'd be inclined to add a new
hypercall that DTRT and leave the old one, deprecated.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:28:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:28: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 1UAMRq-0005au-Tn; Tue, 26 Feb 2013 15:28:06 +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 1UAMRp-0005ap-Qj
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:28:06 +0000
Received: from [193.109.254.147:39354] by server-10.bemta-14.messagelabs.com
	id 6A/3E-12679-584DC215; Tue, 26 Feb 2013 15:28:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1361892441!6085870!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13164 invoked from network); 26 Feb 2013 15:27:22 -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; 26 Feb 2013 15:27:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAMR5-000PFR-GN; Tue, 26 Feb 2013 15:27:19 +0000
Date: Tue, 26 Feb 2013 15:27:19 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226152719.GD93966@ocelot.phlegethon.org>
References: <512B844C02000078000C0C75@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512B844C02000078000C0C75@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XENMEM_maximum_gpfn return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:33 +0000 on 25 Feb (1361802812), Jan Beulich wrote:
> This coming from a shared info field, it has to be assumed to possibly
> have any value. In particular, our kernels don't set up this field at all
> if running as Dom0 and kexec isn't enabled (along with not setting up
> the P2M frame lists, as that's simply wasted memory in that case).
> 
> So, with this being a guest provided value, we apparently have two
> problems: do_memory_op()'s "rc" variable is only of type "int", thus
> potentially truncating the result of domain_get_maximum_gpfn()
> (considering that we now support 16Tb, an 8Tb+ guest ought to
> be possible, and such would have a max GPFN with 32 significant
> bits). And zero or a very large number being returned by the latter
> will generally be mistaken as an error code by the caller of the
> hypercall.
> 
> So, along with promoting "rc" to long, I'm considering enforcing a
> sane lower bound on domain_get_maximum_gpfn()'s return value,
> using d->tot_pages (under the assumption that each page would
> have a representation in the physical map, and hence the
> physical map can't reasonably be smaller than this). That would
> overcome the subtraction of 1 done there for PV guests to
> convert 0 to -1 (i.e. -EPERM). Similarly, a sane upper bound
> ought to be enforced (to avoid collisions with the -E range).
> 
> Other thoughts? Is such a behavioral change acceptable for an
> existing interface?

The new behaviour seems sensible but I'm a little worried about changing
the behaviour of an existing call.  I'd be inclined to add a new
hypercall that DTRT and leave the old one, deprecated.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:33:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:33: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 1UAMWa-0005oq-QQ; Tue, 26 Feb 2013 15:33:00 +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 1UAMWY-0005of-L6
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:32:59 +0000
Received: from [85.158.137.99:45718] by server-12.bemta-3.messagelabs.com id
	98/48-05889-9A5DC215; Tue, 26 Feb 2013 15:32:57 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361892761!17105464!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9647 invoked from network); 26 Feb 2013 15:32:42 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 15:32:42 -0000
Received: from p5b2e1b98.dip.t-dialin.net ([91.46.27.152] 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 1UAMWF-00010G-UD; Tue, 26 Feb 2013 15:32:40 +0000
Message-ID: <512CD595.2000502@canonical.com>
Date: Tue, 26 Feb 2013 16:32:37 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com>
In-Reply-To: <512B2A7C.1050906@canonical.com>
X-Enigmail-Version: 1.4.6
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7892278221739760396=="
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)
--===============7892278221739760396==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig702C1BC490730E0C45CB5F36"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig702C1BC490730E0C45CB5F36
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 25.02.2013 10:10, Stefan Bader wrote:
> On 25.02.2013 04:15, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>>> Hi Konrad,
>>>
>>> Hey Stefan,
>>>>
>>>> here is another one from the hm-what? department:
>>>
>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
>>> he has been tracking a similar one with mcelog.
>>>>
>>>> Colin discovered that running the attached program with the fork
>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or=

>>>> iomem) this triggers the following weird messages:=20
>>>>
>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>>> [ 6824.453776] ------------[ cut here ]------------
>>>> [ 6824.453796] WARNING: at
>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>>> mmap-example Tainted: GF=20
>>>> 3.8.0-6-generic #13-Ubuntu
>>>> [ 6824.453926] Call Trace:
>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]=

>>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>>
>>>> I found that this is related to your bandaid patch
>>>>
>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>>
>>>>     xen/pat: Disable PAT support for now.
>>>>
>>>> I just do not understand how this happens. From the trace it seems
>>>> the fork=20
>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
>>>> maybe the=20
>>>> warning is just related to this. So primarily the question is how on=

>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>>> cleared from the supported=20
>>>> mask by the patch, so somehow I would think nothing should be able
>>>> to set it...=20
>>>> But apparently not so.
>>>> Not sure it is a big deal since I never saw this in normal operation=

>>>> and it=20
>>>> seems to be ok when unapping before doing the fork. It is just plain=

>>>> odd.=20
>>>
>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow th=
e
>>> ranges are swapped or not correct. Jinsong, could you shed some light=

>>> on what you have found so far?
>>>
>>
>> Yes, Sander once also reported a similar weird warning when start mcel=
og daemon, as attached.
>>
>> Basically, it occurs when mcelog user daemon start,=20
>> do_fork
>>   --> copy_process
>>     --> dup_mm
>>       --> dup_mmap
>>         --> copy_page_range
>>           --> track_pfn_copy
>>             --> reserve_pfn_range

So that makes it clearer as this will do

reserve_memtype(...)
--> pat_x_mtrr_type
  --> mtrr_type_lookup
    --> __mtrr_type_lookup

And that can return -1/0xff in case of mtrr not being enabled/initialized=
=2E Which
is not the case (given there are no messages for it in dmesg). This is no=
t equal
to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.

It looks like the problem starts early in reserve_memtype:

        if (!pat_enabled) {
                /* This is identical to page table setting without PAT */=

                if (new_type) {
                        if (req_type =3D=3D _PAGE_CACHE_WC)
                                *new_type =3D _PAGE_CACHE_UC_MINUS;
                        else
                                *new_type =3D req_type & _PAGE_CACHE_MASK=
;
                }
                return 0;
        }

This would be what we want, but only clearing the PWT and PCD flags from =
the
supported flags is not changing pat_enabled (which is 1 when PAT support =
is
compiled into the kernel). Unfortunately the variable is local and since =
there
are not any messages about PAT in dmesg I would say pat_init() is not cal=
led
either. Which might be used to disable PAT support by clearing the CPU fe=
ature
flag.
Right now it seems the only work-around that message appearing is to user=

"nopat" on the kernel command line.

-Stefan


>>               --> line 624: flags !=3D want_flags
>> It comes from different memory types of page table (_PAGE_CACHE_WB) an=
d mtrr (_PAGE_CACHE_UC_MINUS).
>>
>> However, why it get different memory types from page table and mtrr is=
 still unclear, reproducing the bug is difficult and unstable.
>>
>> Thanks,
>=20
> Ok, so this seems to take the same code paths. As for the test program,=
 it fails
> on duplicating some mmap on a fork. The test program does this all the =
time
> (except the backtrace warning which is warn_once).
> So you say, the UC- comes from the MTRR side... Hm, have to look at tha=
t.
>=20





--------------enig702C1BC490730E0C45CB5F36
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLNWVAAoJEOhnXe7L7s6jMMkQAI+RHToAV3w5uVYrmwUhqfP5
gi2zt8EqweOJpOBrLXUJewYP+viNWEphM5fpx9atcD99AaekRshCu8p0QtHqZXGs
W/GfgKX+PyY3BxxI+ftH55nby+L2lYjuUVqVU43l4zhk+8M4LI9FAR5A/CafRhKG
XoyzFt/maW4DJWvn0UeTe9JkeIgAd8Itgid3J8d+lUhynEVakLWpHTKbj6lbROjV
+9nHBYfGM5HGyF/d/JRLN51QVzlfgFvuwnDZ4onPazuPMPT+OSOvE/tiNtIPWNJS
mP+iubmMEzCsSu7ImRbQKGu43EgF/BykRkHcxkF3myYDUG5EKncTi2ozDGSm1Pd1
m9d9iCX+kqVq74pa7f1l9URzEM4NdmIlYa47K4U6rI/uybN2MzLEGoIJN1bmdMts
r+ELDVWTwTXHVWOb4mh3BHFS7B0/9WRTq7x4ROBpC+lUqgfQN2Xuky7KDGiNLryq
NZ8UScMx5MNv1fd16Lm6BQl1nCOthWqZoxFOpbIzROlEOSXWuxzlDMQ3inO6v4cj
BNqSqECh+2kGmKW+kPrbuhOS6cRirzVID23SxpU+PeAqMm0ZzhvrM5o/G0eh2g80
MJP2X103SmzUcwBx9Uhh/sYXdc1Pp6Ka2iZhTfnSnAN/Y5s82xZayTTLNxs7FRa8
lKmFmtC7ckt9KWj9azWY
=TeT7
-----END PGP SIGNATURE-----

--------------enig702C1BC490730E0C45CB5F36--


--===============7892278221739760396==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7892278221739760396==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 15:33:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:33: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 1UAMWa-0005oq-QQ; Tue, 26 Feb 2013 15:33:00 +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 1UAMWY-0005of-L6
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:32:59 +0000
Received: from [85.158.137.99:45718] by server-12.bemta-3.messagelabs.com id
	98/48-05889-9A5DC215; Tue, 26 Feb 2013 15:32:57 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1361892761!17105464!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9647 invoked from network); 26 Feb 2013 15:32:42 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-217.messagelabs.com with SMTP;
	26 Feb 2013 15:32:42 -0000
Received: from p5b2e1b98.dip.t-dialin.net ([91.46.27.152] 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 1UAMWF-00010G-UD; Tue, 26 Feb 2013 15:32:40 +0000
Message-ID: <512CD595.2000502@canonical.com>
Date: Tue, 26 Feb 2013 16:32:37 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com>
In-Reply-To: <512B2A7C.1050906@canonical.com>
X-Enigmail-Version: 1.4.6
Cc: Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============7892278221739760396=="
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)
--===============7892278221739760396==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig702C1BC490730E0C45CB5F36"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig702C1BC490730E0C45CB5F36
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 25.02.2013 10:10, Stefan Bader wrote:
> On 25.02.2013 04:15, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>>> Hi Konrad,
>>>
>>> Hey Stefan,
>>>>
>>>> here is another one from the hm-what? department:
>>>
>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
>>> he has been tracking a similar one with mcelog.
>>>>
>>>> Colin discovered that running the attached program with the fork
>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or=

>>>> iomem) this triggers the following weird messages:=20
>>>>
>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>>> [ 6824.453776] ------------[ cut here ]------------
>>>> [ 6824.453796] WARNING: at
>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>>> mmap-example Tainted: GF=20
>>>> 3.8.0-6-generic #13-Ubuntu
>>>> [ 6824.453926] Call Trace:
>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]=

>>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>>
>>>> I found that this is related to your bandaid patch
>>>>
>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>>
>>>>     xen/pat: Disable PAT support for now.
>>>>
>>>> I just do not understand how this happens. From the trace it seems
>>>> the fork=20
>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
>>>> maybe the=20
>>>> warning is just related to this. So primarily the question is how on=

>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>>> cleared from the supported=20
>>>> mask by the patch, so somehow I would think nothing should be able
>>>> to set it...=20
>>>> But apparently not so.
>>>> Not sure it is a big deal since I never saw this in normal operation=

>>>> and it=20
>>>> seems to be ok when unapping before doing the fork. It is just plain=

>>>> odd.=20
>>>
>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow th=
e
>>> ranges are swapped or not correct. Jinsong, could you shed some light=

>>> on what you have found so far?
>>>
>>
>> Yes, Sander once also reported a similar weird warning when start mcel=
og daemon, as attached.
>>
>> Basically, it occurs when mcelog user daemon start,=20
>> do_fork
>>   --> copy_process
>>     --> dup_mm
>>       --> dup_mmap
>>         --> copy_page_range
>>           --> track_pfn_copy
>>             --> reserve_pfn_range

So that makes it clearer as this will do

reserve_memtype(...)
--> pat_x_mtrr_type
  --> mtrr_type_lookup
    --> __mtrr_type_lookup

And that can return -1/0xff in case of mtrr not being enabled/initialized=
=2E Which
is not the case (given there are no messages for it in dmesg). This is no=
t equal
to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.

It looks like the problem starts early in reserve_memtype:

        if (!pat_enabled) {
                /* This is identical to page table setting without PAT */=

                if (new_type) {
                        if (req_type =3D=3D _PAGE_CACHE_WC)
                                *new_type =3D _PAGE_CACHE_UC_MINUS;
                        else
                                *new_type =3D req_type & _PAGE_CACHE_MASK=
;
                }
                return 0;
        }

This would be what we want, but only clearing the PWT and PCD flags from =
the
supported flags is not changing pat_enabled (which is 1 when PAT support =
is
compiled into the kernel). Unfortunately the variable is local and since =
there
are not any messages about PAT in dmesg I would say pat_init() is not cal=
led
either. Which might be used to disable PAT support by clearing the CPU fe=
ature
flag.
Right now it seems the only work-around that message appearing is to user=

"nopat" on the kernel command line.

-Stefan


>>               --> line 624: flags !=3D want_flags
>> It comes from different memory types of page table (_PAGE_CACHE_WB) an=
d mtrr (_PAGE_CACHE_UC_MINUS).
>>
>> However, why it get different memory types from page table and mtrr is=
 still unclear, reproducing the bug is difficult and unstable.
>>
>> Thanks,
>=20
> Ok, so this seems to take the same code paths. As for the test program,=
 it fails
> on duplicating some mmap on a fork. The test program does this all the =
time
> (except the backtrace warning which is warn_once).
> So you say, the UC- comes from the MTRR side... Hm, have to look at tha=
t.
>=20





--------------enig702C1BC490730E0C45CB5F36
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLNWVAAoJEOhnXe7L7s6jMMkQAI+RHToAV3w5uVYrmwUhqfP5
gi2zt8EqweOJpOBrLXUJewYP+viNWEphM5fpx9atcD99AaekRshCu8p0QtHqZXGs
W/GfgKX+PyY3BxxI+ftH55nby+L2lYjuUVqVU43l4zhk+8M4LI9FAR5A/CafRhKG
XoyzFt/maW4DJWvn0UeTe9JkeIgAd8Itgid3J8d+lUhynEVakLWpHTKbj6lbROjV
+9nHBYfGM5HGyF/d/JRLN51QVzlfgFvuwnDZ4onPazuPMPT+OSOvE/tiNtIPWNJS
mP+iubmMEzCsSu7ImRbQKGu43EgF/BykRkHcxkF3myYDUG5EKncTi2ozDGSm1Pd1
m9d9iCX+kqVq74pa7f1l9URzEM4NdmIlYa47K4U6rI/uybN2MzLEGoIJN1bmdMts
r+ELDVWTwTXHVWOb4mh3BHFS7B0/9WRTq7x4ROBpC+lUqgfQN2Xuky7KDGiNLryq
NZ8UScMx5MNv1fd16Lm6BQl1nCOthWqZoxFOpbIzROlEOSXWuxzlDMQ3inO6v4cj
BNqSqECh+2kGmKW+kPrbuhOS6cRirzVID23SxpU+PeAqMm0ZzhvrM5o/G0eh2g80
MJP2X103SmzUcwBx9Uhh/sYXdc1Pp6Ka2iZhTfnSnAN/Y5s82xZayTTLNxs7FRa8
lKmFmtC7ckt9KWj9azWY
=TeT7
-----END PGP SIGNATURE-----

--------------enig702C1BC490730E0C45CB5F36--


--===============7892278221739760396==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7892278221739760396==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 15:40:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMdq-0005yq-OP; Tue, 26 Feb 2013 15:40:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1UAMdo-0005yl-IO
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:40:28 +0000
Received: from [85.158.137.99:27397] by server-15.bemta-3.messagelabs.com id
	EF/B1-25405-B67DC215; Tue, 26 Feb 2013 15:40:27 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361893202!18091736!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25143 invoked from network); 26 Feb 2013 15:40:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:40:02 -0000
Received: by mail-ee0-f45.google.com with SMTP id b57so2530498eek.32
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 07:40:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=eumBMTiqktrvjMuTaVTi7dJEI2tFhgqK6PLIIeiuGV8=;
	b=k5eruhUwFr0vwQpl/z6Mapqmb9rohvzfwr4xWxp7g99K7m0QkA6JjZdEUYiM4jydxX
	3eEFcnzlkVc090afK7/CRawZeekVxDx3eC0fzsB+nQVIcF2sN/GezZv/aAPxaeT6vEk2
	ajoGrMhexlWjepOTNtEQWMJpJVXGhaDlnJs1HutAgjVNqSW0+qa4diaqtjOJqkvbI/0d
	kVIQMd+le5ZioDYvRpConz4fo1XCzMVLcOF8wIdTrwElWqqf3tSotl9mGK9Ch8j9gAnE
	PeOG+FcbyQIn9gq/k/Z46vsN/Y8a0HBEnQhbAKCvKDdYDOEhLsPTP2Vf/w2u7NbM+qDo
	U+sw==
X-Received: by 10.14.194.198 with SMTP id m46mr50788483een.8.1361893201707;
	Tue, 26 Feb 2013 07:40:01 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id f47sm2049170eep.13.2013.02.26.07.39.59
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 07:40:00 -0800 (PST)
Message-ID: <512CD750.8030103@heliman.it>
Date: Tue, 26 Feb 2013 16:40:00 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it>
	<931493278BD056D168E0B849@Ximines.local>
	<512CCEB9.3060109@heliman.it>
	<1361891550.26546.301.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361891550.26546.301.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQltQHAZN3Kh7LIlKJ0K1xM0Yy6E+jxo3vCeILmlH2T7KdYBAv3hsT5f3SKEobDAdu7zvDQ+
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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-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

Il 26/02/2013 16:12, Ian Campbell ha scritto:
> On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
>> @Ian or Stefano:
>> About use upstream qemu from debian package on xen debian package:
>> Do I need to only remove the build (similar to seabios packaged patch)
>> or may I also need to patch libxl/xm?
> Probably you'd need to patch libxl (but not xm) too.
>
> On my todo list I have an action to make the configure script understand
> --with-system-qemu=PATH, which would disable the qemu-xen build and
> cause libxl to use $PATH (default /usr/bin/qemu?) instead
> of /usr/lib/xen/bin/blah. If someone else were to get there first that
> would be awesome!
>
> ./configure --(enable|disable)-qemu-traditional (i.e. just turn the
> build off and on) would be quite useful too I think. As would making
> libxl handle the absence of either a little more gracefully.
>
> Ian.
>
Thanks for the info, your idea for upstream xen instead is better than 
mine on debian patches.
Unfortunately for the moment I not have sufficent time to do this task.
The default qemu probably is good /usr/bin/qemu-system-x86_64, tested 
and full working on debian (not know about different distros), 
/usr/bin/qemu link to i386 which has some bugs (for example one or more 
important/critical with spice, that seem present also in other distros).
Following your indication it would be useful to add also the options to 
use system seabios for example --with-system-seabios=PATH, which is 
faster to do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:40:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMdq-0005yq-OP; Tue, 26 Feb 2013 15:40:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fabio.fantoni@heliman.it>) id 1UAMdo-0005yl-IO
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:40:28 +0000
Received: from [85.158.137.99:27397] by server-15.bemta-3.messagelabs.com id
	EF/B1-25405-B67DC215; Tue, 26 Feb 2013 15:40:27 +0000
X-Env-Sender: fabio.fantoni@heliman.it
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361893202!18091736!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25143 invoked from network); 26 Feb 2013 15:40:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:40:02 -0000
Received: by mail-ee0-f45.google.com with SMTP id b57so2530498eek.32
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 07:40:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received: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=eumBMTiqktrvjMuTaVTi7dJEI2tFhgqK6PLIIeiuGV8=;
	b=k5eruhUwFr0vwQpl/z6Mapqmb9rohvzfwr4xWxp7g99K7m0QkA6JjZdEUYiM4jydxX
	3eEFcnzlkVc090afK7/CRawZeekVxDx3eC0fzsB+nQVIcF2sN/GezZv/aAPxaeT6vEk2
	ajoGrMhexlWjepOTNtEQWMJpJVXGhaDlnJs1HutAgjVNqSW0+qa4diaqtjOJqkvbI/0d
	kVIQMd+le5ZioDYvRpConz4fo1XCzMVLcOF8wIdTrwElWqqf3tSotl9mGK9Ch8j9gAnE
	PeOG+FcbyQIn9gq/k/Z46vsN/Y8a0HBEnQhbAKCvKDdYDOEhLsPTP2Vf/w2u7NbM+qDo
	U+sw==
X-Received: by 10.14.194.198 with SMTP id m46mr50788483een.8.1361893201707;
	Tue, 26 Feb 2013 07:40:01 -0800 (PST)
Received: from [192.168.1.15] (ip-124-113.sn2.eutelia.it. [83.211.124.113])
	by mx.google.com with ESMTPS id f47sm2049170eep.13.2013.02.26.07.39.59
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 07:40:00 -0800 (PST)
Message-ID: <512CD750.8030103@heliman.it>
Date: Tue, 26 Feb 2013 16:40:00 +0100
From: Fabio Fantoni <fabio.fantoni@heliman.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it>
	<931493278BD056D168E0B849@Ximines.local>
	<512CCEB9.3060109@heliman.it>
	<1361891550.26546.301.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361891550.26546.301.camel@zakaz.uk.xensource.com>
X-Gm-Message-State: ALoCoQltQHAZN3Kh7LIlKJ0K1xM0Yy6E+jxo3vCeILmlH2T7KdYBAv3hsT5f3SKEobDAdu7zvDQ+
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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-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

Il 26/02/2013 16:12, Ian Campbell ha scritto:
> On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
>> @Ian or Stefano:
>> About use upstream qemu from debian package on xen debian package:
>> Do I need to only remove the build (similar to seabios packaged patch)
>> or may I also need to patch libxl/xm?
> Probably you'd need to patch libxl (but not xm) too.
>
> On my todo list I have an action to make the configure script understand
> --with-system-qemu=PATH, which would disable the qemu-xen build and
> cause libxl to use $PATH (default /usr/bin/qemu?) instead
> of /usr/lib/xen/bin/blah. If someone else were to get there first that
> would be awesome!
>
> ./configure --(enable|disable)-qemu-traditional (i.e. just turn the
> build off and on) would be quite useful too I think. As would making
> libxl handle the absence of either a little more gracefully.
>
> Ian.
>
Thanks for the info, your idea for upstream xen instead is better than 
mine on debian patches.
Unfortunately for the moment I not have sufficent time to do this task.
The default qemu probably is good /usr/bin/qemu-system-x86_64, tested 
and full working on debian (not know about different distros), 
/usr/bin/qemu link to i386 which has some bugs (for example one or more 
important/critical with spice, that seem present also in other distros).
Following your indication it would be useful to add also the options to 
use system seabios for example --with-system-seabios=PATH, which is 
faster to do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:43:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:43: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 1UAMgk-000665-Bo; Tue, 26 Feb 2013 15:43:30 +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 1UAMgj-00065w-8n
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:43:29 +0000
Received: from [193.109.254.147:33845] by server-14.bemta-14.messagelabs.com
	id 7F/32-02031-028DC215; Tue, 26 Feb 2013 15:43:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361893405!9115364!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23547 invoked from network); 26 Feb 2013 15:43:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:43:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9719119"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 15:43:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 10:43:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAMgV-0007Uk-TG;
	Tue, 26 Feb 2013 15:43:15 +0000
Date: Tue, 26 Feb 2013 15:43:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
In-Reply-To: <B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "mst@redhat.com" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Hao,
	Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Right, I think that reading as 0xff and write once would be important
improvements for this patch.

I would like to see a document somewhere (maybe just a text file under
xen-unstable/docs/misc) with a list of deviations of the i440fx we
emulate and the real one.

Other than that, it would be OK for me.

On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.
> Xiantao
> 
> > -----Original Message-----
> > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
> > Of Hao, Xudong
> > Sent: Tuesday, February 26, 2013 11:33 AM
> > To: Stefano Stabellini; Ian Campbell
> > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
> > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> > base of PCI
> >
> > > -----Original Message-----
> > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> > > Of Stefano Stabellini
> > > Sent: Tuesday, February 26, 2013 12:06 AM
> > > To: Hao, Xudong
> > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > > afaerber@suse.de
> > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
> > the
> > > base of PCI
> > >
> > > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > > v2:
> > > > * Use "piix: " in the subject rather than "qemu: "
> > > > * Define TOM register as one byte
> > > > * Define default TOM value instead of hardcode 0xe0000000 in more that
> > one
> > > place
> > > > * Use API pci_set_byte for pci config access
> > > > * Use dev->config instead of the indirect d->dev.config
> > > >
> > > > Define a TOM(top of memory) register to report the base of PCI memory,
> > > update
> > > > memory region dynamically. TOM register are defined to one byte in PCI
> > > configure
> > > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > > > it requires bios set TOM with 16M-aligned.
> > > >
> > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > >
> > > The patch is OK from my POV, but I think that Ian raised a valid
> > > concern: we are supposed to emulate a real piece of hardware, maybe
> > > another mechanism (xenbus? hvmop?) to pass the information from
> > > hvmloader to QEMU would be a better fit than this.
> > > Otherwise at least we would need to advertize this feature somehow: if
> > > hvmloader can use it, the guest kernel can use it too...
> > >
> > Hi, Ian and Stefano
> >
> > Here adding this faking register in bios is a hack way.
> > However, what we emulated is not full real piece of hardware at all times, the
> > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> > The faking register is only effective by bios and device model. This register is
> > reserved by host bridge, so guest can't access this register, guest kernel should
> > handle well when accessing a reserved region.
> >
> > -Thanks
> > Xudong
> > >
> > >
> > > >  hw/pc.h       |  7 +++---
> > > >  hw/pc_piix.c  | 12 +++-------
> > > >  hw/piix_pci.c | 73
> > > +++++++++++++++++++++++++++++++++++++++++++----------------
> > > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > > >
> > > > diff --git a/hw/pc.h b/hw/pc.h
> > > > index fbcf43d..62adcc5 100644
> > > > --- a/hw/pc.h
> > > > +++ b/hw/pc.h
> > > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > > >  struct PCII440FXState;
> > > >  typedef struct PCII440FXState PCII440FXState;
> > > >
> > > > +#define I440FX_TOM     0xe0000000
> > > > +#define I440FX_XEN_TOM 0xf0000000
> > > > +
> > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > > >                      ISABus **isa_bus, qemu_irq *pic,
> > > >                      MemoryRegion *address_space_mem,
> > > >                      MemoryRegion *address_space_io,
> > > >                      ram_addr_t ram_size,
> > > > -                    hwaddr pci_hole_start,
> > > > -                    hwaddr pci_hole_size,
> > > > -                    hwaddr pci_hole64_start,
> > > > -                    hwaddr pci_hole64_size,
> > > >                      MemoryRegion *pci_memory,
> > > >                      MemoryRegion *ram_memory);
> > > >
> > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > > index 0a6923d..2eef510 100644
> > > > --- a/hw/pc_piix.c
> > > > +++ b/hw/pc_piix.c
> > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> > > >          kvmclock_create();
> > > >      }
> > > >
> > > > -    if (ram_size >= 0xe0000000 ) {
> > > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > > -        below_4g_mem_size = 0xe0000000;
> > > > +    if (ram_size >= I440FX_TOM) {
> > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > > +        below_4g_mem_size = I440FX_TOM;
> > > >      } else {
> > > >          above_4g_mem_size = 0;
> > > >          below_4g_mem_size = ram_size;
> > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > > *system_memory,
> > > >      if (pci_enabled) {
> > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > > >                                system_memory, system_io,
> > > ram_size,
> > > > -                              below_4g_mem_size,
> > > > -                              0x100000000ULL -
> > > below_4g_mem_size,
> > > > -                              0x100000000ULL +
> > > above_4g_mem_size,
> > > > -                              (sizeof(hwaddr) == 4
> > > > -                               ? 0
> > > > -                               : ((uint64_t)1 << 62)),
> > > >                                pci_memory, ram_memory);
> > > >      } else {
> > > >          pci_bus = NULL;
> > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > > index 3d79c73..3e5a25c 100644
> > > > --- a/hw/piix_pci.c
> > > > +++ b/hw/piix_pci.c
> > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > > >  #define I440FX_PAM_SIZE 7
> > > >  #define I440FX_SMRAM    0x72
> > > >
> > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > > + * define another register to report the base of PCI memory.
> > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > > + * resevered for host bridge.
> > > > + * */
> > > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > > +
> > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > > pci_intx);
> > > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> > > pci_intx)
> > > >      return (pci_intx + slot_addend) & 3;
> > > >  }
> > > >
> > > > +
> > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > > +{
> > > > +    ram_addr_t above_4g_mem_size;
> > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > > pci_hole64_size;
> > > > +
> > > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > > +
> > > > +    if (ram_size >= pci_hole_start) {
> > > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > > +    } else {
> > > > +        above_4g_mem_size = 0;
> > > > +    }
> > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > > +
> > > > +    if (del) {
> > > > +        memory_region_del_subregion(f->system_memory,
> > > &f->pci_hole);
> > > > +        if (pci_hole64_size) {
> > > > +            memory_region_del_subregion(f->system_memory,
> > > &f->pci_hole_64bit);
> > > > +        }
> > > > +    }
> > > > +
> > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > f->pci_address_space,
> > > > +                             pci_hole_start, pci_hole_size);
> > > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > &f->pci_hole);
> > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > +                             f->pci_address_space,
> > > > +                             pci_hole64_start, pci_hole64_size);
> > > > +    if (pci_hole64_size) {
> > > > +        memory_region_add_subregion(f->system_memory,
> > > pci_hole64_start,
> > > > +                                    &f->pci_hole_64bit);
> > > > +    }
> > > > +}
> > > > +
> > > > +
> > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > > >  {
> > > >      int i;
> > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > > >          i440fx_update_memory_mappings(d);
> > > >      }
> > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > > +        i440fx_update_pci_mem_hole(d, true);
> > > > +    }
> > > >  }
> > > >
> > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > > >
> > > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > > >
> > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> > > 24));
> > > > +
> > > >      cpu_smm_register(&i440fx_set_smm, d);
> > > >      return 0;
> > > >  }
> > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> > > *device_name,
> > > >                                    MemoryRegion
> > > *address_space_mem,
> > > >                                    MemoryRegion
> > > *address_space_io,
> > > >                                    ram_addr_t ram_size,
> > > > -                                  hwaddr pci_hole_start,
> > > > -                                  hwaddr pci_hole_size,
> > > > -                                  hwaddr pci_hole64_start,
> > > > -                                  hwaddr pci_hole64_size,
> > > >                                    MemoryRegion
> > > *pci_address_space,
> > > >                                    MemoryRegion *ram_memory)
> > > >  {
> > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> > > *device_name,
> > > >      f->system_memory = address_space_mem;
> > > >      f->pci_address_space = pci_address_space;
> > > >      f->ram_memory = ram_memory;
> > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > f->pci_address_space,
> > > > -                             pci_hole_start, pci_hole_size);
> > > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > &f->pci_hole);
> > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > -                             f->pci_address_space,
> > > > -                             pci_hole64_start, pci_hole64_size);
> > > > -    if (pci_hole64_size) {
> > > > -        memory_region_add_subregion(f->system_memory,
> > > pci_hole64_start,
> > > > -                                    &f->pci_hole_64bit);
> > > > -    }
> > > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > > >                               f->pci_address_space, 0xa0000,
> > > 0x20000);
> > > >      memory_region_add_subregion_overlap(f->system_memory,
> > > 0xa0000,
> > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > > *device_name,
> > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > > >
> > > >      i440fx_update_memory_mappings(f);
> > > > +    i440fx_update_pci_mem_hole(f, false);
> > > >
> > > >      return b;
> > > >  }
> > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > > **pi440fx_state, int *piix3_devfn,
> > > >                      MemoryRegion *address_space_mem,
> > > >                      MemoryRegion *address_space_io,
> > > >                      ram_addr_t ram_size,
> > > > -                    hwaddr pci_hole_start,
> > > > -                    hwaddr pci_hole_size,
> > > > -                    hwaddr pci_hole64_start,
> > > > -                    hwaddr pci_hole64_size,
> > > >                      MemoryRegion *pci_memory, MemoryRegion
> > > *ram_memory)
> > > >
> > > >  {
> > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> > > int *piix3_devfn,
> > > >
> > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> > > pic,
> > > >                             address_space_mem, address_space_io,
> > > ram_size,
> > > > -                           pci_hole_start, pci_hole_size,
> > > > -                           pci_hole64_start, pci_hole64_size,
> > > >                             pci_memory, ram_memory);
> > > >      return b;
> > > >  }
> > > > --
> > > > 1.7.12.1
> > > >
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:43:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:43: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 1UAMgk-000665-Bo; Tue, 26 Feb 2013 15:43:30 +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 1UAMgj-00065w-8n
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:43:29 +0000
Received: from [193.109.254.147:33845] by server-14.bemta-14.messagelabs.com
	id 7F/32-02031-028DC215; Tue, 26 Feb 2013 15:43:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361893405!9115364!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23547 invoked from network); 26 Feb 2013 15:43:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:43:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9719119"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 15:43:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 10:43:16 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAMgV-0007Uk-TG;
	Tue, 26 Feb 2013 15:43:15 +0000
Date: Tue, 26 Feb 2013 15:43:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
In-Reply-To: <B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "mst@redhat.com" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Hao,
	Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Right, I think that reading as 0xff and write once would be important
improvements for this patch.

I would like to see a document somewhere (maybe just a text file under
xen-unstable/docs/misc) with a list of deviations of the i440fx we
emulate and the real one.

Other than that, it would be OK for me.

On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.
> Xiantao
> 
> > -----Original Message-----
> > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
> > Of Hao, Xudong
> > Sent: Tuesday, February 26, 2013 11:33 AM
> > To: Stefano Stabellini; Ian Campbell
> > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
> > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> > base of PCI
> >
> > > -----Original Message-----
> > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> > > Of Stefano Stabellini
> > > Sent: Tuesday, February 26, 2013 12:06 AM
> > > To: Hao, Xudong
> > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > > afaerber@suse.de
> > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
> > the
> > > base of PCI
> > >
> > > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > > v2:
> > > > * Use "piix: " in the subject rather than "qemu: "
> > > > * Define TOM register as one byte
> > > > * Define default TOM value instead of hardcode 0xe0000000 in more that
> > one
> > > place
> > > > * Use API pci_set_byte for pci config access
> > > > * Use dev->config instead of the indirect d->dev.config
> > > >
> > > > Define a TOM(top of memory) register to report the base of PCI memory,
> > > update
> > > > memory region dynamically. TOM register are defined to one byte in PCI
> > > configure
> > > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > > > it requires bios set TOM with 16M-aligned.
> > > >
> > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > >
> > > The patch is OK from my POV, but I think that Ian raised a valid
> > > concern: we are supposed to emulate a real piece of hardware, maybe
> > > another mechanism (xenbus? hvmop?) to pass the information from
> > > hvmloader to QEMU would be a better fit than this.
> > > Otherwise at least we would need to advertize this feature somehow: if
> > > hvmloader can use it, the guest kernel can use it too...
> > >
> > Hi, Ian and Stefano
> >
> > Here adding this faking register in bios is a hack way.
> > However, what we emulated is not full real piece of hardware at all times, the
> > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> > The faking register is only effective by bios and device model. This register is
> > reserved by host bridge, so guest can't access this register, guest kernel should
> > handle well when accessing a reserved region.
> >
> > -Thanks
> > Xudong
> > >
> > >
> > > >  hw/pc.h       |  7 +++---
> > > >  hw/pc_piix.c  | 12 +++-------
> > > >  hw/piix_pci.c | 73
> > > +++++++++++++++++++++++++++++++++++++++++++----------------
> > > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > > >
> > > > diff --git a/hw/pc.h b/hw/pc.h
> > > > index fbcf43d..62adcc5 100644
> > > > --- a/hw/pc.h
> > > > +++ b/hw/pc.h
> > > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > > >  struct PCII440FXState;
> > > >  typedef struct PCII440FXState PCII440FXState;
> > > >
> > > > +#define I440FX_TOM     0xe0000000
> > > > +#define I440FX_XEN_TOM 0xf0000000
> > > > +
> > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > > >                      ISABus **isa_bus, qemu_irq *pic,
> > > >                      MemoryRegion *address_space_mem,
> > > >                      MemoryRegion *address_space_io,
> > > >                      ram_addr_t ram_size,
> > > > -                    hwaddr pci_hole_start,
> > > > -                    hwaddr pci_hole_size,
> > > > -                    hwaddr pci_hole64_start,
> > > > -                    hwaddr pci_hole64_size,
> > > >                      MemoryRegion *pci_memory,
> > > >                      MemoryRegion *ram_memory);
> > > >
> > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > > index 0a6923d..2eef510 100644
> > > > --- a/hw/pc_piix.c
> > > > +++ b/hw/pc_piix.c
> > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> > > >          kvmclock_create();
> > > >      }
> > > >
> > > > -    if (ram_size >= 0xe0000000 ) {
> > > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > > -        below_4g_mem_size = 0xe0000000;
> > > > +    if (ram_size >= I440FX_TOM) {
> > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > > +        below_4g_mem_size = I440FX_TOM;
> > > >      } else {
> > > >          above_4g_mem_size = 0;
> > > >          below_4g_mem_size = ram_size;
> > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > > *system_memory,
> > > >      if (pci_enabled) {
> > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > > >                                system_memory, system_io,
> > > ram_size,
> > > > -                              below_4g_mem_size,
> > > > -                              0x100000000ULL -
> > > below_4g_mem_size,
> > > > -                              0x100000000ULL +
> > > above_4g_mem_size,
> > > > -                              (sizeof(hwaddr) == 4
> > > > -                               ? 0
> > > > -                               : ((uint64_t)1 << 62)),
> > > >                                pci_memory, ram_memory);
> > > >      } else {
> > > >          pci_bus = NULL;
> > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > > index 3d79c73..3e5a25c 100644
> > > > --- a/hw/piix_pci.c
> > > > +++ b/hw/piix_pci.c
> > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > > >  #define I440FX_PAM_SIZE 7
> > > >  #define I440FX_SMRAM    0x72
> > > >
> > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > > + * define another register to report the base of PCI memory.
> > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > > + * resevered for host bridge.
> > > > + * */
> > > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > > +
> > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > > pci_intx);
> > > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> > > pci_intx)
> > > >      return (pci_intx + slot_addend) & 3;
> > > >  }
> > > >
> > > > +
> > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > > +{
> > > > +    ram_addr_t above_4g_mem_size;
> > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > > pci_hole64_size;
> > > > +
> > > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > > +
> > > > +    if (ram_size >= pci_hole_start) {
> > > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > > +    } else {
> > > > +        above_4g_mem_size = 0;
> > > > +    }
> > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > > +
> > > > +    if (del) {
> > > > +        memory_region_del_subregion(f->system_memory,
> > > &f->pci_hole);
> > > > +        if (pci_hole64_size) {
> > > > +            memory_region_del_subregion(f->system_memory,
> > > &f->pci_hole_64bit);
> > > > +        }
> > > > +    }
> > > > +
> > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > f->pci_address_space,
> > > > +                             pci_hole_start, pci_hole_size);
> > > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > &f->pci_hole);
> > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > +                             f->pci_address_space,
> > > > +                             pci_hole64_start, pci_hole64_size);
> > > > +    if (pci_hole64_size) {
> > > > +        memory_region_add_subregion(f->system_memory,
> > > pci_hole64_start,
> > > > +                                    &f->pci_hole_64bit);
> > > > +    }
> > > > +}
> > > > +
> > > > +
> > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > > >  {
> > > >      int i;
> > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > > >          i440fx_update_memory_mappings(d);
> > > >      }
> > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > > +        i440fx_update_pci_mem_hole(d, true);
> > > > +    }
> > > >  }
> > > >
> > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > > >
> > > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > > >
> > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> > > 24));
> > > > +
> > > >      cpu_smm_register(&i440fx_set_smm, d);
> > > >      return 0;
> > > >  }
> > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> > > *device_name,
> > > >                                    MemoryRegion
> > > *address_space_mem,
> > > >                                    MemoryRegion
> > > *address_space_io,
> > > >                                    ram_addr_t ram_size,
> > > > -                                  hwaddr pci_hole_start,
> > > > -                                  hwaddr pci_hole_size,
> > > > -                                  hwaddr pci_hole64_start,
> > > > -                                  hwaddr pci_hole64_size,
> > > >                                    MemoryRegion
> > > *pci_address_space,
> > > >                                    MemoryRegion *ram_memory)
> > > >  {
> > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> > > *device_name,
> > > >      f->system_memory = address_space_mem;
> > > >      f->pci_address_space = pci_address_space;
> > > >      f->ram_memory = ram_memory;
> > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > f->pci_address_space,
> > > > -                             pci_hole_start, pci_hole_size);
> > > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > &f->pci_hole);
> > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > -                             f->pci_address_space,
> > > > -                             pci_hole64_start, pci_hole64_size);
> > > > -    if (pci_hole64_size) {
> > > > -        memory_region_add_subregion(f->system_memory,
> > > pci_hole64_start,
> > > > -                                    &f->pci_hole_64bit);
> > > > -    }
> > > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > > >                               f->pci_address_space, 0xa0000,
> > > 0x20000);
> > > >      memory_region_add_subregion_overlap(f->system_memory,
> > > 0xa0000,
> > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > > *device_name,
> > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > > >
> > > >      i440fx_update_memory_mappings(f);
> > > > +    i440fx_update_pci_mem_hole(f, false);
> > > >
> > > >      return b;
> > > >  }
> > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > > **pi440fx_state, int *piix3_devfn,
> > > >                      MemoryRegion *address_space_mem,
> > > >                      MemoryRegion *address_space_io,
> > > >                      ram_addr_t ram_size,
> > > > -                    hwaddr pci_hole_start,
> > > > -                    hwaddr pci_hole_size,
> > > > -                    hwaddr pci_hole64_start,
> > > > -                    hwaddr pci_hole64_size,
> > > >                      MemoryRegion *pci_memory, MemoryRegion
> > > *ram_memory)
> > > >
> > > >  {
> > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> > > int *piix3_devfn,
> > > >
> > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> > > pic,
> > > >                             address_space_mem, address_space_io,
> > > ram_size,
> > > > -                           pci_hole_start, pci_hole_size,
> > > > -                           pci_hole64_start, pci_hole64_size,
> > > >                             pci_memory, ram_memory);
> > > >      return b;
> > > >  }
> > > > --
> > > > 1.7.12.1
> > > >
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:45: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 1UAMi2-0006Bg-9U; Tue, 26 Feb 2013 15:44:50 +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 1UAMi0-0006BS-PC
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:44:49 +0000
Received: from [85.158.137.99:57737] by server-16.bemta-3.messagelabs.com id
	83/39-02727-B68DC215; Tue, 26 Feb 2013 15:44:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361893467!15850923!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20619 invoked from network); 26 Feb 2013 15:44:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:44:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 15:44:26 +0000
Message-Id: <512CE66802000078000C1237@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:44:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part85B5F548.0__="
Subject: [Xen-devel] [PATCH v2] credit1: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part85B5F548.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This should help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
v2: Comment ASSERT() and drop credit2 portion upon George's request.

--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -19,6 +19,7 @@
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
 #include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/keyhandler.h>
 #include <xen/trace.h>
@@ -136,6 +137,7 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
     atomic_t credit;
+    unsigned int residual;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
     uint16_t flags;
     int16_t pri;
@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
+    uint64_t val;
     unsigned int credits;
=20
     /* Assert svc is current */
@@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
     if ( (delta =3D now - svc->start_time) <=3D 0 )
         return;
=20
-    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / =
MILLISECS(1);
+    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
+    svc->residual =3D do_div(val, MILLISECS(1));
+    credits =3D val;
+    ASSERT(credits =3D=3D val); /* make sure we haven't truncated val */
     atomic_sub(credits, &svc->credit);
     svc->start_time +=3D (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSE=
C;
 }




--=__Part85B5F548.0__=
Content-Type: text/plain; name="sched-credit1-residual.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sched-credit1-residual.patch"

credit1: track residual from divisions done during accounting=0A=0AThis =
should help with under-accounting of vCPU-s running for extremly=0Ashort =
periods of time, but becoming runnable again at a high frequency.=0A=0ASign=
ed-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: George Dunlap =
<george.dunlap@eu.citrix.com>=0A---=0Av2: Comment ASSERT() and drop =
credit2 portion upon George's request.=0A=0A--- a/xen/common/sched_credit.c=
=0A+++ b/xen/common/sched_credit.c=0A@@ -19,6 +19,7 @@=0A #include =
<xen/sched-if.h>=0A #include <xen/softirq.h>=0A #include <asm/atomic.h>=0A+=
#include <asm/div64.h>=0A #include <xen/errno.h>=0A #include <xen/keyhandle=
r.h>=0A #include <xen/trace.h>=0A@@ -136,6 +137,7 @@ struct csched_vcpu =
{=0A     struct csched_dom *sdom;=0A     struct vcpu *vcpu;=0A     =
atomic_t credit;=0A+    unsigned int residual;=0A     s_time_t start_time; =
  /* When we were scheduled (used for credit) */=0A     uint16_t flags;=0A =
    int16_t pri;=0A@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu =
*svc)=0A static void burn_credits(struct csched_vcpu *svc, s_time_t =
now)=0A {=0A     s_time_t delta;=0A+    uint64_t val;=0A     unsigned int =
credits;=0A =0A     /* Assert svc is current */=0A@@ -250,7 +253,10 @@ =
static void burn_credits(struct csched_v=0A     if ( (delta =3D now - =
svc->start_time) <=3D 0 )=0A         return;=0A =0A-    credits =3D =
(delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);=0A+    =
val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;=0A+    svc->residu=
al =3D do_div(val, MILLISECS(1));=0A+    credits =3D val;=0A+    ASSERT(cre=
dits =3D=3D val); /* make sure we haven't truncated val */=0A     =
atomic_sub(credits, &svc->credit);=0A     svc->start_time +=3D (credits * =
MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;=0A }=0A
--=__Part85B5F548.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

--=__Part85B5F548.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 15:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:45: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 1UAMi2-0006Bg-9U; Tue, 26 Feb 2013 15:44:50 +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 1UAMi0-0006BS-PC
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:44:49 +0000
Received: from [85.158.137.99:57737] by server-16.bemta-3.messagelabs.com id
	83/39-02727-B68DC215; Tue, 26 Feb 2013 15:44:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361893467!15850923!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20619 invoked from network); 26 Feb 2013 15:44:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:44:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 15:44:26 +0000
Message-Id: <512CE66802000078000C1237@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:44:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part85B5F548.0__="
Subject: [Xen-devel] [PATCH v2] credit1: track residual from divisions done
 during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part85B5F548.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This should help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
---
v2: Comment ASSERT() and drop credit2 portion upon George's request.

--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -19,6 +19,7 @@
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
 #include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/keyhandler.h>
 #include <xen/trace.h>
@@ -136,6 +137,7 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
     atomic_t credit;
+    unsigned int residual;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
     uint16_t flags;
     int16_t pri;
@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
+    uint64_t val;
     unsigned int credits;
=20
     /* Assert svc is current */
@@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
     if ( (delta =3D now - svc->start_time) <=3D 0 )
         return;
=20
-    credits =3D (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / =
MILLISECS(1);
+    val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
+    svc->residual =3D do_div(val, MILLISECS(1));
+    credits =3D val;
+    ASSERT(credits =3D=3D val); /* make sure we haven't truncated val */
     atomic_sub(credits, &svc->credit);
     svc->start_time +=3D (credits * MILLISECS(1)) / CSCHED_CREDITS_PER_MSE=
C;
 }




--=__Part85B5F548.0__=
Content-Type: text/plain; name="sched-credit1-residual.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sched-credit1-residual.patch"

credit1: track residual from divisions done during accounting=0A=0AThis =
should help with under-accounting of vCPU-s running for extremly=0Ashort =
periods of time, but becoming runnable again at a high frequency.=0A=0ASign=
ed-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: George Dunlap =
<george.dunlap@eu.citrix.com>=0A---=0Av2: Comment ASSERT() and drop =
credit2 portion upon George's request.=0A=0A--- a/xen/common/sched_credit.c=
=0A+++ b/xen/common/sched_credit.c=0A@@ -19,6 +19,7 @@=0A #include =
<xen/sched-if.h>=0A #include <xen/softirq.h>=0A #include <asm/atomic.h>=0A+=
#include <asm/div64.h>=0A #include <xen/errno.h>=0A #include <xen/keyhandle=
r.h>=0A #include <xen/trace.h>=0A@@ -136,6 +137,7 @@ struct csched_vcpu =
{=0A     struct csched_dom *sdom;=0A     struct vcpu *vcpu;=0A     =
atomic_t credit;=0A+    unsigned int residual;=0A     s_time_t start_time; =
  /* When we were scheduled (used for credit) */=0A     uint16_t flags;=0A =
    int16_t pri;=0A@@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu =
*svc)=0A static void burn_credits(struct csched_vcpu *svc, s_time_t =
now)=0A {=0A     s_time_t delta;=0A+    uint64_t val;=0A     unsigned int =
credits;=0A =0A     /* Assert svc is current */=0A@@ -250,7 +253,10 @@ =
static void burn_credits(struct csched_v=0A     if ( (delta =3D now - =
svc->start_time) <=3D 0 )=0A         return;=0A =0A-    credits =3D =
(delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) / MILLISECS(1);=0A+    =
val =3D delta * CSCHED_CREDITS_PER_MSEC + svc->residual;=0A+    svc->residu=
al =3D do_div(val, MILLISECS(1));=0A+    credits =3D val;=0A+    ASSERT(cre=
dits =3D=3D val); /* make sure we haven't truncated val */=0A     =
atomic_sub(credits, &svc->credit);=0A     svc->start_time +=3D (credits * =
MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;=0A }=0A
--=__Part85B5F548.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

--=__Part85B5F548.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 15:49:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMmL-0006Pv-1Y; Tue, 26 Feb 2013 15:49: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 1UAMmJ-0006Pn-M4
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:49:15 +0000
Received: from [193.109.254.147:51357] by server-2.bemta-14.messagelabs.com id
	AB/19-16277-B79DC215; Tue, 26 Feb 2013 15:49:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361893754!2531554!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14836 invoked from network); 26 Feb 2013 15:49:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:49:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1908907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 15: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.297.1;
	Tue, 26 Feb 2013 15:49:14 +0000
Message-ID: <1361893752.26546.303.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Tue, 26 Feb 2013 15:49:12 +0000
In-Reply-To: <512CD750.8030103@heliman.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it> <931493278BD056D168E0B849@Ximines.local>
	<512CCEB9.3060109@heliman.it>
	<1361891550.26546.301.camel@zakaz.uk.xensource.com>
	<512CD750.8030103@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 15:40 +0000, Fabio Fantoni wrote:
> Il 26/02/2013 16:12, Ian Campbell ha scritto:
> > On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
> >> @Ian or Stefano:
> >> About use upstream qemu from debian package on xen debian package:
> >> Do I need to only remove the build (similar to seabios packaged patch)
> >> or may I also need to patch libxl/xm?
> > Probably you'd need to patch libxl (but not xm) too.
> >
> > On my todo list I have an action to make the configure script understand
> > --with-system-qemu=PATH, which would disable the qemu-xen build and
> > cause libxl to use $PATH (default /usr/bin/qemu?) instead
> > of /usr/lib/xen/bin/blah. If someone else were to get there first that
> > would be awesome!
> >
> > ./configure --(enable|disable)-qemu-traditional (i.e. just turn the
> > build off and on) would be quite useful too I think. As would making
> > libxl handle the absence of either a little more gracefully.
> >
> > Ian.
> >
> Thanks for the info, your idea for upstream xen instead is better than 
> mine on debian patches.
> Unfortunately for the moment I not have sufficent time to do this task.

No worries, it'll sit on my list until I get to it ;-)

> The default qemu probably is good /usr/bin/qemu-system-x86_64, tested 
> and full working on debian (not know about different distros), 
> /usr/bin/qemu link to i386 which has some bugs (for example one or more 
> important/critical with spice, that seem present also in other distros).
> Following your indication it would be useful to add also the options to 
> use system seabios for example --with-system-seabios=PATH, which is 
> faster to do.

Yes, that would be useful too. Sigh, that's another entry on the TODO
list ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:49:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMmL-0006Pv-1Y; Tue, 26 Feb 2013 15:49: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 1UAMmJ-0006Pn-M4
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 15:49:15 +0000
Received: from [193.109.254.147:51357] by server-2.bemta-14.messagelabs.com id
	AB/19-16277-B79DC215; Tue, 26 Feb 2013 15:49:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361893754!2531554!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14836 invoked from network); 26 Feb 2013 15:49:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:49:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1908907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 15: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.297.1;
	Tue, 26 Feb 2013 15:49:14 +0000
Message-ID: <1361893752.26546.303.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fabio Fantoni <fabio.fantoni@heliman.it>
Date: Tue, 26 Feb 2013 15:49:12 +0000
In-Reply-To: <512CD750.8030103@heliman.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302261257060.5360@kaball.uk.xensource.com>
	<1361884158.26546.291.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1302261310500.5360@kaball.uk.xensource.com>
	<1361884713.26546.296.camel@zakaz.uk.xensource.com>
	<512CC3CC.2010505@heliman.it> <931493278BD056D168E0B849@Ximines.local>
	<512CCEB9.3060109@heliman.it>
	<1361891550.26546.301.camel@zakaz.uk.xensource.com>
	<512CD750.8030103@heliman.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 15:40 +0000, Fabio Fantoni wrote:
> Il 26/02/2013 16:12, Ian Campbell ha scritto:
> > On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
> >> @Ian or Stefano:
> >> About use upstream qemu from debian package on xen debian package:
> >> Do I need to only remove the build (similar to seabios packaged patch)
> >> or may I also need to patch libxl/xm?
> > Probably you'd need to patch libxl (but not xm) too.
> >
> > On my todo list I have an action to make the configure script understand
> > --with-system-qemu=PATH, which would disable the qemu-xen build and
> > cause libxl to use $PATH (default /usr/bin/qemu?) instead
> > of /usr/lib/xen/bin/blah. If someone else were to get there first that
> > would be awesome!
> >
> > ./configure --(enable|disable)-qemu-traditional (i.e. just turn the
> > build off and on) would be quite useful too I think. As would making
> > libxl handle the absence of either a little more gracefully.
> >
> > Ian.
> >
> Thanks for the info, your idea for upstream xen instead is better than 
> mine on debian patches.
> Unfortunately for the moment I not have sufficent time to do this task.

No worries, it'll sit on my list until I get to it ;-)

> The default qemu probably is good /usr/bin/qemu-system-x86_64, tested 
> and full working on debian (not know about different distros), 
> /usr/bin/qemu link to i386 which has some bugs (for example one or more 
> important/critical with spice, that seem present also in other distros).
> Following your indication it would be useful to add also the options to 
> use system seabios for example --with-system-seabios=PATH, which is 
> faster to do.

Yes, that would be useful too. Sigh, that's another entry on the TODO
list ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:51:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMo7-0006WA-Hq; Tue, 26 Feb 2013 15:51: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 1UAMo5-0006Vv-9n
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:51:05 +0000
Received: from [85.158.137.99:20324] by server-12.bemta-3.messagelabs.com id
	29/2C-05889-8E9DC215; Tue, 26 Feb 2013 15:51:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361893858!18208144!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26332 invoked from network); 26 Feb 2013 15:50:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1909005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 15:50: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.297.1;
	Tue, 26 Feb 2013 15:50:38 +0000
Message-ID: <1361893836.26546.304.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 15:50:36 +0000
In-Reply-To: <alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>, "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Given that Xen has at least two other mechanisms (xenstore and
hvmparams) for passing this sort of information around I'm not sure why
hacking the emulated i440fx device should be the preferred option.

On Tue, 2013-02-26 at 15:43 +0000, Stefano Stabellini wrote:
> Right, I think that reading as 0xff and write once would be important
> improvements for this patch.
> 
> I would like to see a document somewhere (maybe just a text file under
> xen-unstable/docs/misc) with a list of deviations of the i440fx we
> emulate and the real one.
> 
> Other than that, it would be OK for me.
> 
> On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> > For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.
> > Xiantao
> >
> > > -----Original Message-----
> > > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> > > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
> > > Of Hao, Xudong
> > > Sent: Tuesday, February 26, 2013 11:33 AM
> > > To: Stefano Stabellini; Ian Campbell
> > > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
> > > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> > > base of PCI
> > >
> > > > -----Original Message-----
> > > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> > > > Of Stefano Stabellini
> > > > Sent: Tuesday, February 26, 2013 12:06 AM
> > > > To: Hao, Xudong
> > > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > > > afaerber@suse.de
> > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
> > > the
> > > > base of PCI
> > > >
> > > > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > > > v2:
> > > > > * Use "piix: " in the subject rather than "qemu: "
> > > > > * Define TOM register as one byte
> > > > > * Define default TOM value instead of hardcode 0xe0000000 in more that
> > > one
> > > > place
> > > > > * Use API pci_set_byte for pci config access
> > > > > * Use dev->config instead of the indirect d->dev.config
> > > > >
> > > > > Define a TOM(top of memory) register to report the base of PCI memory,
> > > > update
> > > > > memory region dynamically. TOM register are defined to one byte in PCI
> > > > configure
> > > > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > > > > it requires bios set TOM with 16M-aligned.
> > > > >
> > > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > >
> > > > The patch is OK from my POV, but I think that Ian raised a valid
> > > > concern: we are supposed to emulate a real piece of hardware, maybe
> > > > another mechanism (xenbus? hvmop?) to pass the information from
> > > > hvmloader to QEMU would be a better fit than this.
> > > > Otherwise at least we would need to advertize this feature somehow: if
> > > > hvmloader can use it, the guest kernel can use it too...
> > > >
> > > Hi, Ian and Stefano
> > >
> > > Here adding this faking register in bios is a hack way.
> > > However, what we emulated is not full real piece of hardware at all times, the
> > > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> > > The faking register is only effective by bios and device model. This register is
> > > reserved by host bridge, so guest can't access this register, guest kernel should
> > > handle well when accessing a reserved region.
> > >
> > > -Thanks
> > > Xudong
> > > >
> > > >
> > > > >  hw/pc.h       |  7 +++---
> > > > >  hw/pc_piix.c  | 12 +++-------
> > > > >  hw/piix_pci.c | 73
> > > > +++++++++++++++++++++++++++++++++++++++++++----------------
> > > > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > > > >
> > > > > diff --git a/hw/pc.h b/hw/pc.h
> > > > > index fbcf43d..62adcc5 100644
> > > > > --- a/hw/pc.h
> > > > > +++ b/hw/pc.h
> > > > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > > > >  struct PCII440FXState;
> > > > >  typedef struct PCII440FXState PCII440FXState;
> > > > >
> > > > > +#define I440FX_TOM     0xe0000000
> > > > > +#define I440FX_XEN_TOM 0xf0000000
> > > > > +
> > > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > > > >                      ISABus **isa_bus, qemu_irq *pic,
> > > > >                      MemoryRegion *address_space_mem,
> > > > >                      MemoryRegion *address_space_io,
> > > > >                      ram_addr_t ram_size,
> > > > > -                    hwaddr pci_hole_start,
> > > > > -                    hwaddr pci_hole_size,
> > > > > -                    hwaddr pci_hole64_start,
> > > > > -                    hwaddr pci_hole64_size,
> > > > >                      MemoryRegion *pci_memory,
> > > > >                      MemoryRegion *ram_memory);
> > > > >
> > > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > > > index 0a6923d..2eef510 100644
> > > > > --- a/hw/pc_piix.c
> > > > > +++ b/hw/pc_piix.c
> > > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> > > > >          kvmclock_create();
> > > > >      }
> > > > >
> > > > > -    if (ram_size >= 0xe0000000 ) {
> > > > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > > > -        below_4g_mem_size = 0xe0000000;
> > > > > +    if (ram_size >= I440FX_TOM) {
> > > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > > > +        below_4g_mem_size = I440FX_TOM;
> > > > >      } else {
> > > > >          above_4g_mem_size = 0;
> > > > >          below_4g_mem_size = ram_size;
> > > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > > > *system_memory,
> > > > >      if (pci_enabled) {
> > > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > > > >                                system_memory, system_io,
> > > > ram_size,
> > > > > -                              below_4g_mem_size,
> > > > > -                              0x100000000ULL -
> > > > below_4g_mem_size,
> > > > > -                              0x100000000ULL +
> > > > above_4g_mem_size,
> > > > > -                              (sizeof(hwaddr) == 4
> > > > > -                               ? 0
> > > > > -                               : ((uint64_t)1 << 62)),
> > > > >                                pci_memory, ram_memory);
> > > > >      } else {
> > > > >          pci_bus = NULL;
> > > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > > > index 3d79c73..3e5a25c 100644
> > > > > --- a/hw/piix_pci.c
> > > > > +++ b/hw/piix_pci.c
> > > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > > > >  #define I440FX_PAM_SIZE 7
> > > > >  #define I440FX_SMRAM    0x72
> > > > >
> > > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > > > + * define another register to report the base of PCI memory.
> > > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > > > + * resevered for host bridge.
> > > > > + * */
> > > > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > > > +
> > > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > > > pci_intx);
> > > > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> > > > pci_intx)
> > > > >      return (pci_intx + slot_addend) & 3;
> > > > >  }
> > > > >
> > > > > +
> > > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > > > +{
> > > > > +    ram_addr_t above_4g_mem_size;
> > > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > > > pci_hole64_size;
> > > > > +
> > > > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > > > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > > > +
> > > > > +    if (ram_size >= pci_hole_start) {
> > > > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > > > +    } else {
> > > > > +        above_4g_mem_size = 0;
> > > > > +    }
> > > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > > > +
> > > > > +    if (del) {
> > > > > +        memory_region_del_subregion(f->system_memory,
> > > > &f->pci_hole);
> > > > > +        if (pci_hole64_size) {
> > > > > +            memory_region_del_subregion(f->system_memory,
> > > > &f->pci_hole_64bit);
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > f->pci_address_space,
> > > > > +                             pci_hole_start, pci_hole_size);
> > > > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > > &f->pci_hole);
> > > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > +                             f->pci_address_space,
> > > > > +                             pci_hole64_start, pci_hole64_size);
> > > > > +    if (pci_hole64_size) {
> > > > > +        memory_region_add_subregion(f->system_memory,
> > > > pci_hole64_start,
> > > > > +                                    &f->pci_hole_64bit);
> > > > > +    }
> > > > > +}
> > > > > +
> > > > > +
> > > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > > > >  {
> > > > >      int i;
> > > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> > > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > > > >          i440fx_update_memory_mappings(d);
> > > > >      }
> > > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > > > +        i440fx_update_pci_mem_hole(d, true);
> > > > > +    }
> > > > >  }
> > > > >
> > > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > > > >
> > > > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > > > >
> > > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> > > > 24));
> > > > > +
> > > > >      cpu_smm_register(&i440fx_set_smm, d);
> > > > >      return 0;
> > > > >  }
> > > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> > > > *device_name,
> > > > >                                    MemoryRegion
> > > > *address_space_mem,
> > > > >                                    MemoryRegion
> > > > *address_space_io,
> > > > >                                    ram_addr_t ram_size,
> > > > > -                                  hwaddr pci_hole_start,
> > > > > -                                  hwaddr pci_hole_size,
> > > > > -                                  hwaddr pci_hole64_start,
> > > > > -                                  hwaddr pci_hole64_size,
> > > > >                                    MemoryRegion
> > > > *pci_address_space,
> > > > >                                    MemoryRegion *ram_memory)
> > > > >  {
> > > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> > > > *device_name,
> > > > >      f->system_memory = address_space_mem;
> > > > >      f->pci_address_space = pci_address_space;
> > > > >      f->ram_memory = ram_memory;
> > > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > f->pci_address_space,
> > > > > -                             pci_hole_start, pci_hole_size);
> > > > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > > &f->pci_hole);
> > > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > -                             f->pci_address_space,
> > > > > -                             pci_hole64_start, pci_hole64_size);
> > > > > -    if (pci_hole64_size) {
> > > > > -        memory_region_add_subregion(f->system_memory,
> > > > pci_hole64_start,
> > > > > -                                    &f->pci_hole_64bit);
> > > > > -    }
> > > > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > > > >                               f->pci_address_space, 0xa0000,
> > > > 0x20000);
> > > > >      memory_region_add_subregion_overlap(f->system_memory,
> > > > 0xa0000,
> > > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > > > *device_name,
> > > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > > > >
> > > > >      i440fx_update_memory_mappings(f);
> > > > > +    i440fx_update_pci_mem_hole(f, false);
> > > > >
> > > > >      return b;
> > > > >  }
> > > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > > > **pi440fx_state, int *piix3_devfn,
> > > > >                      MemoryRegion *address_space_mem,
> > > > >                      MemoryRegion *address_space_io,
> > > > >                      ram_addr_t ram_size,
> > > > > -                    hwaddr pci_hole_start,
> > > > > -                    hwaddr pci_hole_size,
> > > > > -                    hwaddr pci_hole64_start,
> > > > > -                    hwaddr pci_hole64_size,
> > > > >                      MemoryRegion *pci_memory, MemoryRegion
> > > > *ram_memory)
> > > > >
> > > > >  {
> > > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> > > > int *piix3_devfn,
> > > > >
> > > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> > > > pic,
> > > > >                             address_space_mem, address_space_io,
> > > > ram_size,
> > > > > -                           pci_hole_start, pci_hole_size,
> > > > > -                           pci_hole64_start, pci_hole64_size,
> > > > >                             pci_memory, ram_memory);
> > > > >      return b;
> > > > >  }
> > > > > --
> > > > > 1.7.12.1
> > > > >
> > >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:51:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15: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 1UAMo7-0006WA-Hq; Tue, 26 Feb 2013 15:51: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 1UAMo5-0006Vv-9n
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:51:05 +0000
Received: from [85.158.137.99:20324] by server-12.bemta-3.messagelabs.com id
	29/2C-05889-8E9DC215; Tue, 26 Feb 2013 15:51:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361893858!18208144!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26332 invoked from network); 26 Feb 2013 15:50:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 15:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1909005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 15:50: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.297.1;
	Tue, 26 Feb 2013 15:50:38 +0000
Message-ID: <1361893836.26546.304.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 15:50:36 +0000
In-Reply-To: <alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>, "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Given that Xen has at least two other mechanisms (xenstore and
hvmparams) for passing this sort of information around I'm not sure why
hacking the emulated i440fx device should be the preferred option.

On Tue, 2013-02-26 at 15:43 +0000, Stefano Stabellini wrote:
> Right, I think that reading as 0xff and write once would be important
> improvements for this patch.
> 
> I would like to see a document somewhere (maybe just a text file under
> xen-unstable/docs/misc) with a list of deviations of the i440fx we
> emulate and the real one.
> 
> Other than that, it would be OK for me.
> 
> On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> > For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.
> > Xiantao
> >
> > > -----Original Message-----
> > > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> > > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
> > > Of Hao, Xudong
> > > Sent: Tuesday, February 26, 2013 11:33 AM
> > > To: Stefano Stabellini; Ian Campbell
> > > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
> > > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
> > > base of PCI
> > >
> > > > -----Original Message-----
> > > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> > > > Of Stefano Stabellini
> > > > Sent: Tuesday, February 26, 2013 12:06 AM
> > > > To: Hao, Xudong
> > > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > > > afaerber@suse.de
> > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
> > > the
> > > > base of PCI
> > > >
> > > > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > > > v2:
> > > > > * Use "piix: " in the subject rather than "qemu: "
> > > > > * Define TOM register as one byte
> > > > > * Define default TOM value instead of hardcode 0xe0000000 in more that
> > > one
> > > > place
> > > > > * Use API pci_set_byte for pci config access
> > > > > * Use dev->config instead of the indirect d->dev.config
> > > > >
> > > > > Define a TOM(top of memory) register to report the base of PCI memory,
> > > > update
> > > > > memory region dynamically. TOM register are defined to one byte in PCI
> > > > configure
> > > > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> > > > > it requires bios set TOM with 16M-aligned.
> > > > >
> > > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > >
> > > > The patch is OK from my POV, but I think that Ian raised a valid
> > > > concern: we are supposed to emulate a real piece of hardware, maybe
> > > > another mechanism (xenbus? hvmop?) to pass the information from
> > > > hvmloader to QEMU would be a better fit than this.
> > > > Otherwise at least we would need to advertize this feature somehow: if
> > > > hvmloader can use it, the guest kernel can use it too...
> > > >
> > > Hi, Ian and Stefano
> > >
> > > Here adding this faking register in bios is a hack way.
> > > However, what we emulated is not full real piece of hardware at all times, the
> > > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> > > The faking register is only effective by bios and device model. This register is
> > > reserved by host bridge, so guest can't access this register, guest kernel should
> > > handle well when accessing a reserved region.
> > >
> > > -Thanks
> > > Xudong
> > > >
> > > >
> > > > >  hw/pc.h       |  7 +++---
> > > > >  hw/pc_piix.c  | 12 +++-------
> > > > >  hw/piix_pci.c | 73
> > > > +++++++++++++++++++++++++++++++++++++++++++----------------
> > > > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > > > >
> > > > > diff --git a/hw/pc.h b/hw/pc.h
> > > > > index fbcf43d..62adcc5 100644
> > > > > --- a/hw/pc.h
> > > > > +++ b/hw/pc.h
> > > > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > > > >  struct PCII440FXState;
> > > > >  typedef struct PCII440FXState PCII440FXState;
> > > > >
> > > > > +#define I440FX_TOM     0xe0000000
> > > > > +#define I440FX_XEN_TOM 0xf0000000
> > > > > +
> > > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > > > >                      ISABus **isa_bus, qemu_irq *pic,
> > > > >                      MemoryRegion *address_space_mem,
> > > > >                      MemoryRegion *address_space_io,
> > > > >                      ram_addr_t ram_size,
> > > > > -                    hwaddr pci_hole_start,
> > > > > -                    hwaddr pci_hole_size,
> > > > > -                    hwaddr pci_hole64_start,
> > > > > -                    hwaddr pci_hole64_size,
> > > > >                      MemoryRegion *pci_memory,
> > > > >                      MemoryRegion *ram_memory);
> > > > >
> > > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > > > index 0a6923d..2eef510 100644
> > > > > --- a/hw/pc_piix.c
> > > > > +++ b/hw/pc_piix.c
> > > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
> > > > >          kvmclock_create();
> > > > >      }
> > > > >
> > > > > -    if (ram_size >= 0xe0000000 ) {
> > > > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > > > -        below_4g_mem_size = 0xe0000000;
> > > > > +    if (ram_size >= I440FX_TOM) {
> > > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > > > +        below_4g_mem_size = I440FX_TOM;
> > > > >      } else {
> > > > >          above_4g_mem_size = 0;
> > > > >          below_4g_mem_size = ram_size;
> > > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > > > *system_memory,
> > > > >      if (pci_enabled) {
> > > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > > > >                                system_memory, system_io,
> > > > ram_size,
> > > > > -                              below_4g_mem_size,
> > > > > -                              0x100000000ULL -
> > > > below_4g_mem_size,
> > > > > -                              0x100000000ULL +
> > > > above_4g_mem_size,
> > > > > -                              (sizeof(hwaddr) == 4
> > > > > -                               ? 0
> > > > > -                               : ((uint64_t)1 << 62)),
> > > > >                                pci_memory, ram_memory);
> > > > >      } else {
> > > > >          pci_bus = NULL;
> > > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > > > index 3d79c73..3e5a25c 100644
> > > > > --- a/hw/piix_pci.c
> > > > > +++ b/hw/piix_pci.c
> > > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > > > >  #define I440FX_PAM_SIZE 7
> > > > >  #define I440FX_SMRAM    0x72
> > > > >
> > > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > > > + * define another register to report the base of PCI memory.
> > > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > > > + * resevered for host bridge.
> > > > > + * */
> > > > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > > > +
> > > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > > > pci_intx);
> > > > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
> > > > pci_intx)
> > > > >      return (pci_intx + slot_addend) & 3;
> > > > >  }
> > > > >
> > > > > +
> > > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > > > +{
> > > > > +    ram_addr_t above_4g_mem_size;
> > > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > > > pci_hole64_size;
> > > > > +
> > > > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > > > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > > > +
> > > > > +    if (ram_size >= pci_hole_start) {
> > > > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > > > +    } else {
> > > > > +        above_4g_mem_size = 0;
> > > > > +    }
> > > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > > > +
> > > > > +    if (del) {
> > > > > +        memory_region_del_subregion(f->system_memory,
> > > > &f->pci_hole);
> > > > > +        if (pci_hole64_size) {
> > > > > +            memory_region_del_subregion(f->system_memory,
> > > > &f->pci_hole_64bit);
> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > f->pci_address_space,
> > > > > +                             pci_hole_start, pci_hole_size);
> > > > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > > &f->pci_hole);
> > > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > +                             f->pci_address_space,
> > > > > +                             pci_hole64_start, pci_hole64_size);
> > > > > +    if (pci_hole64_size) {
> > > > > +        memory_region_add_subregion(f->system_memory,
> > > > pci_hole64_start,
> > > > > +                                    &f->pci_hole_64bit);
> > > > > +    }
> > > > > +}
> > > > > +
> > > > > +
> > > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > > > >  {
> > > > >      int i;
> > > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
> > > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > > > >          i440fx_update_memory_mappings(d);
> > > > >      }
> > > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > > > +        i440fx_update_pci_mem_hole(d, true);
> > > > > +    }
> > > > >  }
> > > > >
> > > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > > > >
> > > > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > > > >
> > > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
> > > > 24));
> > > > > +
> > > > >      cpu_smm_register(&i440fx_set_smm, d);
> > > > >      return 0;
> > > > >  }
> > > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
> > > > *device_name,
> > > > >                                    MemoryRegion
> > > > *address_space_mem,
> > > > >                                    MemoryRegion
> > > > *address_space_io,
> > > > >                                    ram_addr_t ram_size,
> > > > > -                                  hwaddr pci_hole_start,
> > > > > -                                  hwaddr pci_hole_size,
> > > > > -                                  hwaddr pci_hole64_start,
> > > > > -                                  hwaddr pci_hole64_size,
> > > > >                                    MemoryRegion
> > > > *pci_address_space,
> > > > >                                    MemoryRegion *ram_memory)
> > > > >  {
> > > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
> > > > *device_name,
> > > > >      f->system_memory = address_space_mem;
> > > > >      f->pci_address_space = pci_address_space;
> > > > >      f->ram_memory = ram_memory;
> > > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > f->pci_address_space,
> > > > > -                             pci_hole_start, pci_hole_size);
> > > > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
> > > > &f->pci_hole);
> > > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > -                             f->pci_address_space,
> > > > > -                             pci_hole64_start, pci_hole64_size);
> > > > > -    if (pci_hole64_size) {
> > > > > -        memory_region_add_subregion(f->system_memory,
> > > > pci_hole64_start,
> > > > > -                                    &f->pci_hole_64bit);
> > > > > -    }
> > > > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > > > >                               f->pci_address_space, 0xa0000,
> > > > 0x20000);
> > > > >      memory_region_add_subregion_overlap(f->system_memory,
> > > > 0xa0000,
> > > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > > > *device_name,
> > > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > > > >
> > > > >      i440fx_update_memory_mappings(f);
> > > > > +    i440fx_update_pci_mem_hole(f, false);
> > > > >
> > > > >      return b;
> > > > >  }
> > > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > > > **pi440fx_state, int *piix3_devfn,
> > > > >                      MemoryRegion *address_space_mem,
> > > > >                      MemoryRegion *address_space_io,
> > > > >                      ram_addr_t ram_size,
> > > > > -                    hwaddr pci_hole_start,
> > > > > -                    hwaddr pci_hole_size,
> > > > > -                    hwaddr pci_hole64_start,
> > > > > -                    hwaddr pci_hole64_size,
> > > > >                      MemoryRegion *pci_memory, MemoryRegion
> > > > *ram_memory)
> > > > >
> > > > >  {
> > > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> > > > int *piix3_devfn,
> > > > >
> > > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
> > > > pic,
> > > > >                             address_space_mem, address_space_io,
> > > > ram_size,
> > > > > -                           pci_hole_start, pci_hole_size,
> > > > > -                           pci_hole64_start, pci_hole64_size,
> > > > >                             pci_memory, ram_memory);
> > > > >      return b;
> > > > >  }
> > > > > --
> > > > > 1.7.12.1
> > > > >
> > >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:55:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:55: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 1UAMsU-0006lY-8Q; Tue, 26 Feb 2013 15:55:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAMsS-0006lP-1R
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:55:36 +0000
Received: from [85.158.143.99:48704] by server-3.bemta-4.messagelabs.com id
	A9/8D-02186-7FADC215; Tue, 26 Feb 2013 15:55:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361894124!19536975!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27390 invoked from network); 26 Feb 2013 15:55:25 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-8.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 15:55:25 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:56666 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 1UAMqF-0007Sx-N9; Tue, 26 Feb 2013 16:53:19 +0100
Date: Tue, 26 Feb 2013 16:55:21 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <118595702.20130226165521@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130226152038.GA15154@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<20130226152038.GA15154@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Tuesday, February 26, 2013, 4:20:38 PM, you wrote:

> On Mon, Feb 25, 2013 at 11:18:30PM +0100, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>> It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.
>> 
>> I don't see a obvious error in the logs.
>> 
>> The same kernel boots fine on baremetal.
>> With linux 3.8 it boots fine under this version of xen-unstable.
>> 
>> Can you spot something from the logs or you have a hunch from where to start a bisect ?
>> (bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

> There are at least two pitfalls - the
> 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (which you can revert) and you need
> to make sure you have 0cc9129d75ef8993702d97ab0e49542c15ac6ab9
> if you end up in the merge 2ef14f465b9e096531343f5b734cffc5f759f4a6
> ("Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")


>> 
>> 3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

> Interestingly I can reproduce it on my F1A75-M box as well.

> With baremetal I get:
> [   12.701221] ahci 0000:00:11.0: version 3.0
> [   12.701424] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 528175 usecs
> [   12.712999] ahci 0000:00:11.0: irq 46 for MSI/MSI-X
> [   12.717967] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   12.726132] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   12.735405] scsi0 : ahci
> [   12.738087] scsi1 : ahci
> [   12.740734] scsi2 : ahci
> [   12.743511] scsi3 : ahci
> [   12.746278] scsi4 : ahci
> [   12.748930] scsi5 : ahci

> And when booting under Xen 4.1 (note, no IOMMU):

> [   19.178696] ahci 0000:00:11.0: version 3.0
> [   19.178721] xen: registering gsi 19 triggering 0 polarity 1
> [   19.178743] xen: --> pirq=19 -> irq=19 (gsi=19)
> [   19.179040] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   19.179043] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   19.241748] ahci: probe of 0000:00:11.0 failed with error -22
> [   19.249124] initcall ahci_pci_driver_init+0x0/0x1000 [ahci] returned 0 after 460418 usecs

> Had you tried to checkout right before this mega update from Jeff Garzik:

> ab78265 Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
> 21fbd58 Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> d9978ec Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
==>> 77be36d Merge tag 'stable/for-linus-3.9-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

> And seeing if that works?

Hmm that's worth the try, one of the changes seems to be to try to enable multiple msi per device, somehow that sounds like something that could blow up under xen.
Compiling now ..

>> 
>> --
>> Sander
>> 
>> Attached:
>> - Serial log with 3.9-rc0 kernel (missing sata)
>> - Serial log with 3.8 kernel (booting fine
>> - .config







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:55:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:55: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 1UAMsU-0006lY-8Q; Tue, 26 Feb 2013 15:55:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAMsS-0006lP-1R
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:55:36 +0000
Received: from [85.158.143.99:48704] by server-3.bemta-4.messagelabs.com id
	A9/8D-02186-7FADC215; Tue, 26 Feb 2013 15:55:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361894124!19536975!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27390 invoked from network); 26 Feb 2013 15:55:25 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-8.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 15:55:25 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:56666 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 1UAMqF-0007Sx-N9; Tue, 26 Feb 2013 16:53:19 +0100
Date: Tue, 26 Feb 2013 16:55:21 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <118595702.20130226165521@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130226152038.GA15154@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<20130226152038.GA15154@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Tuesday, February 26, 2013, 4:20:38 PM, you wrote:

> On Mon, Feb 25, 2013 at 11:18:30PM +0100, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>> It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.
>> 
>> I don't see a obvious error in the logs.
>> 
>> The same kernel boots fine on baremetal.
>> With linux 3.8 it boots fine under this version of xen-unstable.
>> 
>> Can you spot something from the logs or you have a hunch from where to start a bisect ?
>> (bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

> There are at least two pitfalls - the
> 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (which you can revert) and you need
> to make sure you have 0cc9129d75ef8993702d97ab0e49542c15ac6ab9
> if you end up in the merge 2ef14f465b9e096531343f5b734cffc5f759f4a6
> ("Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")


>> 
>> 3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

> Interestingly I can reproduce it on my F1A75-M box as well.

> With baremetal I get:
> [   12.701221] ahci 0000:00:11.0: version 3.0
> [   12.701424] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 528175 usecs
> [   12.712999] ahci 0000:00:11.0: irq 46 for MSI/MSI-X
> [   12.717967] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   12.726132] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   12.735405] scsi0 : ahci
> [   12.738087] scsi1 : ahci
> [   12.740734] scsi2 : ahci
> [   12.743511] scsi3 : ahci
> [   12.746278] scsi4 : ahci
> [   12.748930] scsi5 : ahci

> And when booting under Xen 4.1 (note, no IOMMU):

> [   19.178696] ahci 0000:00:11.0: version 3.0
> [   19.178721] xen: registering gsi 19 triggering 0 polarity 1
> [   19.178743] xen: --> pirq=19 -> irq=19 (gsi=19)
> [   19.179040] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   19.179043] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   19.241748] ahci: probe of 0000:00:11.0 failed with error -22
> [   19.249124] initcall ahci_pci_driver_init+0x0/0x1000 [ahci] returned 0 after 460418 usecs

> Had you tried to checkout right before this mega update from Jeff Garzik:

> ab78265 Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
> 21fbd58 Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> d9978ec Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
==>> 77be36d Merge tag 'stable/for-linus-3.9-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

> And seeing if that works?

Hmm that's worth the try, one of the changes seems to be to try to enable multiple msi per device, somehow that sounds like something that could blow up under xen.
Compiling now ..

>> 
>> --
>> Sander
>> 
>> Attached:
>> - Serial log with 3.9-rc0 kernel (missing sata)
>> - Serial log with 3.8 kernel (booting fine
>> - .config







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:59:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:59: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 1UAMvf-0006v1-0P; Tue, 26 Feb 2013 15:58: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 1UAMve-0006ur-7V
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:58:54 +0000
Received: from [85.158.137.99:34953] by server-12.bemta-3.messagelabs.com id
	47/3D-05889-DBBDC215; Tue, 26 Feb 2013 15:58:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361894332!18095905!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6045 invoked from network); 26 Feb 2013 15:58:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:58:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 15:58:51 +0000
Message-Id: <512CE92B02000078000C1256@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:56:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH v2 0/3] x86: per-domain mapping 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 main goal being the re-work of the hypercall argument translation
area management, this series first breaks out per-domain mapping
management into its own set of functions, in order to then use this
for setting up the translation areas in per-domain space.

While doing this I also realized that it's pointless for the
map_domain_page() code to track L1 page table pointers in a
separate Xen heap page - we can equally well use the linear
page table for the manipulations needed here.

1: introduce create_perdomain_mapping()
2: rework hypercall argument translation area setup
3: use linear L1 page table for map_domain_page() page table manipulation

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 15:59:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 15:59: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 1UAMvf-0006v1-0P; Tue, 26 Feb 2013 15:58: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 1UAMve-0006ur-7V
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 15:58:54 +0000
Received: from [85.158.137.99:34953] by server-12.bemta-3.messagelabs.com id
	47/3D-05889-DBBDC215; Tue, 26 Feb 2013 15:58:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361894332!18095905!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6045 invoked from network); 26 Feb 2013 15:58:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 15:58:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 15:58:51 +0000
Message-Id: <512CE92B02000078000C1256@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:56:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH v2 0/3] x86: per-domain mapping 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 main goal being the re-work of the hypercall argument translation
area management, this series first breaks out per-domain mapping
management into its own set of functions, in order to then use this
for setting up the translation areas in per-domain space.

While doing this I also realized that it's pointless for the
map_domain_page() code to track L1 page table pointers in a
separate Xen heap page - we can equally well use the linear
page table for the manipulations needed here.

1: introduce create_perdomain_mapping()
2: rework hypercall argument translation area setup
3: use linear L1 page table for map_domain_page() page table manipulation

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:00:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAMwn-0007HN-Hg; Tue, 26 Feb 2013 16:00:05 +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 1UAMwm-00079A-57
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:00:04 +0000
Received: from [193.109.254.147:64482] by server-11.bemta-14.messagelabs.com
	id 35/12-30685-30CDC215; Tue, 26 Feb 2013 16:00:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361894402!9751776!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29880 invoked from network); 26 Feb 2013 16:00:02 -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; 26 Feb 2013 16:00:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:00:02 +0000
Message-Id: <512CEA0F02000078000C1261@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:59:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert VanVossen" <Robert.VanVossen@dornerworks.com>
References: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
In-Reply-To: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Incorrect Prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:23, Robert VanVossen <Robert.VanVossen@dornerworks.com> wrote:
> do_kexec_op and compat_set_timer_op are both prototyped in 
> xen/include/xen/hypercall.h, but are different than their implemented 
> functions. This appears to be a bug.

Care to send a patch?

Jan

> do_kexec_op:
> xen/common/kexec.c: 889
> long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> {
>     return do_kexec_op_internal(op, uarg, 0);
> }
> 
> xen/include/xen/hypercall.h: 126
> extern long
> do_kexec_op(
>     unsigned long op,
>     int arg1,
>     XEN_GUEST_HANDLE(void) arg);
> 
> 
> 
> compat_set_timer_op:
> xen/common/compat/schedule.c: 38
> int compat_set_timer_op(u32 lo, s32 hi)
> {
>     return do_set_timer_op(((s64)hi << 32) | lo);
> }
> 
> xen/include/xen/hypercall.h:175
> extern int
> compat_set_timer_op(
>     s_time_t timeout);
> 
> Thanks,
> Robbie VanVossen




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:00:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAMwn-0007HN-Hg; Tue, 26 Feb 2013 16:00:05 +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 1UAMwm-00079A-57
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:00:04 +0000
Received: from [193.109.254.147:64482] by server-11.bemta-14.messagelabs.com
	id 35/12-30685-30CDC215; Tue, 26 Feb 2013 16:00:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361894402!9751776!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29880 invoked from network); 26 Feb 2013 16:00:02 -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; 26 Feb 2013 16:00:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:00:02 +0000
Message-Id: <512CEA0F02000078000C1261@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 15:59:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Robert VanVossen" <Robert.VanVossen@dornerworks.com>
References: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
In-Reply-To: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Incorrect Prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:23, Robert VanVossen <Robert.VanVossen@dornerworks.com> wrote:
> do_kexec_op and compat_set_timer_op are both prototyped in 
> xen/include/xen/hypercall.h, but are different than their implemented 
> functions. This appears to be a bug.

Care to send a patch?

Jan

> do_kexec_op:
> xen/common/kexec.c: 889
> long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
> {
>     return do_kexec_op_internal(op, uarg, 0);
> }
> 
> xen/include/xen/hypercall.h: 126
> extern long
> do_kexec_op(
>     unsigned long op,
>     int arg1,
>     XEN_GUEST_HANDLE(void) arg);
> 
> 
> 
> compat_set_timer_op:
> xen/common/compat/schedule.c: 38
> int compat_set_timer_op(u32 lo, s32 hi)
> {
>     return do_set_timer_op(((s64)hi << 32) | lo);
> }
> 
> xen/include/xen/hypercall.h:175
> extern int
> compat_set_timer_op(
>     s_time_t timeout);
> 
> Thanks,
> Robbie VanVossen




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:05:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:05: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 1UAN2C-0007i3-Fe; Tue, 26 Feb 2013 16:05:40 +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 1UAN2B-0007hy-5Q
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:05:39 +0000
Received: from [85.158.139.211:4859] by server-10.bemta-5.messagelabs.com id
	66/AD-23714-25DDC215; Tue, 26 Feb 2013 16:05:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361894735!15394248!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10510 invoked from network); 26 Feb 2013 16:05:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:05:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:05:34 +0000
Message-Id: <512CEB5C02000078000C1272@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:05:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>
References: <512CC78B.4080606@mfiala.net>
In-Reply-To: <512CC78B.4080606@mfiala.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
> without problem. When I run reboot or shutdown -r now, system correctly
> shutdowns all runlevels and then system crashed, see crash_output.txt.
> I have the same problem with kernel linux 3.2.37. When I shudown system
> (halt), then it is without problem. I have tested kernel 3.7.5 without
> xen hypervisor, it was without problems. Required debug informations
> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
> Could you please help me with this problem?

It's apparently going the triple fault path, and load_idt() under Xen
doesn't do what the code here expects (i.e. that reboot method
just can't work under Xen). Are you overriding the reboot type on
the kernel command line?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:05:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:05: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 1UAN2C-0007i3-Fe; Tue, 26 Feb 2013 16:05:40 +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 1UAN2B-0007hy-5Q
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:05:39 +0000
Received: from [85.158.139.211:4859] by server-10.bemta-5.messagelabs.com id
	66/AD-23714-25DDC215; Tue, 26 Feb 2013 16:05:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361894735!15394248!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10510 invoked from network); 26 Feb 2013 16:05:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:05:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:05:34 +0000
Message-Id: <512CEB5C02000078000C1272@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:05:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>
References: <512CC78B.4080606@mfiala.net>
In-Reply-To: <512CC78B.4080606@mfiala.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
> without problem. When I run reboot or shutdown -r now, system correctly
> shutdowns all runlevels and then system crashed, see crash_output.txt.
> I have the same problem with kernel linux 3.2.37. When I shudown system
> (halt), then it is without problem. I have tested kernel 3.7.5 without
> xen hypervisor, it was without problems. Required debug informations
> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
> Could you please help me with this problem?

It's apparently going the triple fault path, and load_idt() under Xen
doesn't do what the code here expects (i.e. that reboot method
just can't work under Xen). Are you overriding the reboot type on
the kernel command line?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:06:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN3H-0007kY-Ui; Tue, 26 Feb 2013 16:06:47 +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 1UAN3H-0007kQ-1V
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:06:47 +0000
Received: from [85.158.139.211:2153] by server-15.bemta-5.messagelabs.com id
	57/0C-22815-69DDC215; Tue, 26 Feb 2013 16:06:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361894805!19193479!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24878 invoked from network); 26 Feb 2013 16:06:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:06:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:06:45 +0000
Message-Id: <512CEBA302000078000C127A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:06:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512CE92B02000078000C1256@nat28.tlf.novell.com>
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4B7B3B83.0__="
Subject: [Xen-devel] [PATCH v2 2/3] x86: rework hypercall argument
 translation area 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>
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.

--=__Part4B7B3B83.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... using the new per-domain mapping management functions, adding
destroy_perdomain_mapping() to the previously introduced pair.

Rather than using an order-1 Xen heap allocation, use (currently 2)
individual domain heap pages to populate space in the per-domain
mapping area.

Also fix a benign off-by-one mistake in is_compat_arg_xlat_range().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5657,6 +5657,59 @@ int create_perdomain_mapping(struct doma
     return rc;
 }
=20
+void destroy_perdomain_mapping(struct domain *d, unsigned long va,
+                               unsigned int nr)
+{
+    const l3_pgentry_t *l3tab, *pl3e;
+
+    ASSERT(va >=3D PERDOMAIN_VIRT_START &&
+           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
+    ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
+
+    if ( !d->arch.perdomain_l3_pg )
+        return;
+
+    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+    pl3e =3D l3tab + l3_table_offset(va);
+
+    if ( l3e_get_flags(*pl3e) & _PAGE_PRESENT )
+    {
+        const l2_pgentry_t *l2tab =3D map_domain_page(l3e_get_pfn(*pl3e));=

+        const l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);
+        unsigned int i =3D l1_table_offset(va);
+
+        while ( nr )
+        {
+            if ( l2e_get_flags(*pl2e) & _PAGE_PRESENT )
+            {
+                l1_pgentry_t *l1tab =3D map_domain_page(l2e_get_pfn(*pl2e)=
);
+
+                for ( ; nr && i < L1_PAGETABLE_ENTRIES; --nr, ++i )
+                {
+                    if ( (l1e_get_flags(l1tab[i]) &
+                          (_PAGE_PRESENT | _PAGE_AVAIL0)) =3D=3D
+                         (_PAGE_PRESENT | _PAGE_AVAIL0) )
+                        free_domheap_page(l1e_get_page(l1tab[i]));
+                    l1tab[i] =3D l1e_empty();
+                }
+
+                unmap_domain_page(l1tab);
+            }
+            else if ( nr + i < L1_PAGETABLE_ENTRIES )
+                break;
+            else
+                nr -=3D L1_PAGETABLE_ENTRIES - i;
+
+            ++pl2e;
+            i =3D 0;
+        }
+
+        unmap_domain_page(l2tab);
+    }
+
+    unmap_domain_page(l3tab);
+}
+
 void free_perdomain_mappings(struct domain *d)
 {
     l3_pgentry_t *l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -6,8 +6,8 @@
  * Copyright 2002 Andi Kleen <ak@suse.de>
  */
=20
-#include <xen/config.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <asm/uaccess.h>
=20
 unsigned long __copy_to_user_ll(void __user *to, const void *from, =
unsigned n)
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -832,27 +832,17 @@ void __init zap_low_mappings(void)
                      __PAGE_HYPERVISOR);
 }
=20
-void *compat_arg_xlat_virt_base(void)
-{
-    return current->arch.compat_arg_xlat;
-}
-
 int setup_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
-
-    v->arch.compat_arg_xlat =3D alloc_xenheap_pages(order,
-                                                  MEMF_node(vcpu_to_node(v=
)));
-
-    return v->arch.compat_arg_xlat ? 0 : -ENOMEM;
+    return create_perdomain_mapping(v->domain, ARG_XLAT_START(v),
+                                    PFN_UP(COMPAT_ARG_XLAT_SIZE),
+                                    NULL, NIL(struct page_info *));
 }
=20
 void free_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
-
-    free_xenheap_pages(v->arch.compat_arg_xlat, order);
-    v->arch.compat_arg_xlat =3D NULL;
+    destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v),
+                              PFN_UP(COMPAT_ARG_XLAT_SIZE));
 }
=20
 void cleanup_frame_table(struct mem_hotadd_info *info)
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]
 /* Slot 260: per-domain mappings (including map cache). */
 #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
 #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER=
))
-#define PERDOMAIN_SLOTS         2
+#define PERDOMAIN_SLOTS         3
 #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
                                  (PERDOMAIN_SLOT_MBYTES << 20))
 /* Slot 261: machine-to-phys conversion table (256GB). */
@@ -311,6 +311,13 @@ extern unsigned long xen_phys_start;
 #define MAPCACHE_VIRT_END        (MAPCACHE_VIRT_START + \
                                   MAPCACHE_ENTRIES * PAGE_SIZE)
=20
+/* Argument translation area. The third per-domain-mapping sub-area. */
+#define ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(2)
+/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 =
pages): */
+#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)
+#define ARG_XLAT_START(v)        \
+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
+
 #define ELFSIZE 64
=20
 #define ARCH_CRASH_SAVE_VMCOREINFO
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -442,9 +442,6 @@ struct arch_vcpu
=20
     /* A secondary copy of the vcpu time info. */
     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
-
-    void *compat_arg_xlat;
-
 } __cacheline_aligned;
=20
 /* Shorthands to improve code legibility. */
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -579,6 +579,8 @@ int map_ldt_shadow_page(unsigned int);
 int create_perdomain_mapping(struct domain *, unsigned long va,
                              unsigned int nr, l1_pgentry_t **,
                              struct page_info **);
+void destroy_perdomain_mapping(struct domain *, unsigned long va,
+                               unsigned int nr);
 void free_perdomain_mappings(struct domain *);
=20
 extern int memory_add(unsigned long spfn, unsigned long epfn, unsigned =
int pxm);
--- a/xen/include/asm-x86/x86_64/uaccess.h
+++ b/xen/include/asm-x86/x86_64/uaccess.h
@@ -1,16 +1,15 @@
 #ifndef __X86_64_UACCESS_H
 #define __X86_64_UACCESS_H
=20
-#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()
+#define COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))
 #define COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)
 struct vcpu;
-void *compat_arg_xlat_virt_base(void);
 int setup_compat_arg_xlat(struct vcpu *v);
 void free_compat_arg_xlat(struct vcpu *v);
 #define is_compat_arg_xlat_range(addr, size) ({                           =
    \
     unsigned long __off;                                                  =
    \
     __off =3D (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_=
BASE; \
-    (__off <=3D COMPAT_ARG_XLAT_SIZE) &&                                  =
      \
+    (__off < COMPAT_ARG_XLAT_SIZE) &&                                     =
    \
     ((__off + (unsigned long)(size)) <=3D COMPAT_ARG_XLAT_SIZE);          =
      \
 })
=20



--=__Part4B7B3B83.0__=
Content-Type: text/plain; name="x86-map-arg-xlat-area.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-arg-xlat-area.patch"

x86: rework hypercall argument translation area setup=0A=0A... using the =
new per-domain mapping management functions, adding=0Adestroy_perdomain_map=
ping() to the previously introduced pair.=0A=0ARather than using an =
order-1 Xen heap allocation, use (currently 2)=0Aindividual domain heap =
pages to populate space in the per-domain=0Amapping area.=0A=0AAlso fix a =
benign off-by-one mistake in is_compat_arg_xlat_range().=0A=0ASigned-off-by=
: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mm.c=0A+++ =
b/xen/arch/x86/mm.c=0A@@ -5657,6 +5657,59 @@ int create_perdomain_mapping(s=
truct doma=0A     return rc;=0A }=0A =0A+void destroy_perdomain_mapping(str=
uct domain *d, unsigned long va,=0A+                               =
unsigned int nr)=0A+{=0A+    const l3_pgentry_t *l3tab, *pl3e;=0A+=0A+    =
ASSERT(va >=3D PERDOMAIN_VIRT_START &&=0A+           va < PERDOMAIN_VIRT_SL=
OT(PERDOMAIN_SLOTS));=0A+    ASSERT(!l3_table_offset(va ^ (va + nr * =
PAGE_SIZE - 1)));=0A+=0A+    if ( !d->arch.perdomain_l3_pg )=0A+        =
return;=0A+=0A+    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);=0A=
+    pl3e =3D l3tab + l3_table_offset(va);=0A+=0A+    if ( l3e_get_flags(*p=
l3e) & _PAGE_PRESENT )=0A+    {=0A+        const l2_pgentry_t *l2tab =3D =
map_domain_page(l3e_get_pfn(*pl3e));=0A+        const l2_pgentry_t *pl2e =
=3D l2tab + l2_table_offset(va);=0A+        unsigned int i =3D l1_table_off=
set(va);=0A+=0A+        while ( nr )=0A+        {=0A+            if ( =
l2e_get_flags(*pl2e) & _PAGE_PRESENT )=0A+            {=0A+                =
l1_pgentry_t *l1tab =3D map_domain_page(l2e_get_pfn(*pl2e));=0A+=0A+       =
         for ( ; nr && i < L1_PAGETABLE_ENTRIES; --nr, ++i )=0A+           =
     {=0A+                    if ( (l1e_get_flags(l1tab[i]) &=0A+          =
                (_PAGE_PRESENT | _PAGE_AVAIL0)) =3D=3D=0A+                 =
        (_PAGE_PRESENT | _PAGE_AVAIL0) )=0A+                        =
free_domheap_page(l1e_get_page(l1tab[i]));=0A+                    l1tab[i] =
=3D l1e_empty();=0A+                }=0A+=0A+                unmap_domain_p=
age(l1tab);=0A+            }=0A+            else if ( nr + i < L1_PAGETABLE=
_ENTRIES )=0A+                break;=0A+            else=0A+               =
 nr -=3D L1_PAGETABLE_ENTRIES - i;=0A+=0A+            ++pl2e;=0A+          =
  i =3D 0;=0A+        }=0A+=0A+        unmap_domain_page(l2tab);=0A+    =
}=0A+=0A+    unmap_domain_page(l3tab);=0A+}=0A+=0A void free_perdomain_mapp=
ings(struct domain *d)=0A {=0A     l3_pgentry_t *l3tab =3D __map_domain_pag=
e(d->arch.perdomain_l3_pg);=0A--- a/xen/arch/x86/usercopy.c=0A+++ =
b/xen/arch/x86/usercopy.c=0A@@ -6,8 +6,8 @@=0A  * Copyright 2002 Andi =
Kleen <ak@suse.de>=0A  */=0A =0A-#include <xen/config.h>=0A #include =
<xen/lib.h>=0A+#include <xen/sched.h>=0A #include <asm/uaccess.h>=0A =0A =
unsigned long __copy_to_user_ll(void __user *to, const void *from, =
unsigned n)=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ b/xen/arch/x86/x86_64/mm=
.c=0A@@ -832,27 +832,17 @@ void __init zap_low_mappings(void)=0A           =
           __PAGE_HYPERVISOR);=0A }=0A =0A-void *compat_arg_xlat_virt_base(=
void)=0A-{=0A-    return current->arch.compat_arg_xlat;=0A-}=0A-=0A int =
setup_compat_arg_xlat(struct vcpu *v)=0A {=0A-    unsigned int order =3D =
get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=0A-=0A-    v->arch.compat_arg_x=
lat =3D alloc_xenheap_pages(order,=0A-                                     =
             MEMF_node(vcpu_to_node(v)));=0A-=0A-    return v->arch.compat_=
arg_xlat ? 0 : -ENOMEM;=0A+    return create_perdomain_mapping(v->domain, =
ARG_XLAT_START(v),=0A+                                    PFN_UP(COMPAT_ARG=
_XLAT_SIZE),=0A+                                    NULL, NIL(struct =
page_info *));=0A }=0A =0A void free_compat_arg_xlat(struct vcpu *v)=0A =
{=0A-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=
=0A-=0A-    free_xenheap_pages(v->arch.compat_arg_xlat, order);=0A-    =
v->arch.compat_arg_xlat =3D NULL;=0A+    destroy_perdomain_mapping(v->domai=
n, ARG_XLAT_START(v),=0A+                              PFN_UP(COMPAT_ARG_XL=
AT_SIZE));=0A }=0A =0A void cleanup_frame_table(struct mem_hotadd_info =
*info)=0A--- a/xen/include/asm-x86/config.h=0A+++ b/xen/include/asm-x86/con=
fig.h=0A@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]=0A /* =
Slot 260: per-domain mappings (including map cache). */=0A #define =
PERDOMAIN_VIRT_START    (PML4_ADDR(260))=0A #define PERDOMAIN_SLOT_MBYTES  =
 (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))=0A-#define PERDOMAIN_SLOTS   =
      2=0A+#define PERDOMAIN_SLOTS         3=0A #define PERDOMAIN_VIRT_SLOT=
(s)  (PERDOMAIN_VIRT_START + (s) * \=0A                                  =
(PERDOMAIN_SLOT_MBYTES << 20))=0A /* Slot 261: machine-to-phys conversion =
table (256GB). */=0A@@ -311,6 +311,13 @@ extern unsigned long xen_phys_star=
t;=0A #define MAPCACHE_VIRT_END        (MAPCACHE_VIRT_START + \=0A         =
                          MAPCACHE_ENTRIES * PAGE_SIZE)=0A =0A+/* Argument =
translation area. The third per-domain-mapping sub-area. */=0A+#define =
ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(2)=0A+/* Allow for at least =
one guard page (COMPAT_ARG_XLAT_SIZE being 2 pages): */=0A+#define =
ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)=0A+#define ARG_XLAT_START(v)     =
   \=0A+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))=0A+=
=0A #define ELFSIZE 64=0A =0A #define ARCH_CRASH_SAVE_VMCOREINFO=0A--- =
a/xen/include/asm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ =
-442,9 +442,6 @@ struct arch_vcpu=0A =0A     /* A secondary copy of the =
vcpu time info. */=0A     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_gues=
t;=0A-=0A-    void *compat_arg_xlat;=0A-=0A } __cacheline_aligned;=0A =0A =
/* Shorthands to improve code legibility. */=0A--- a/xen/include/asm-x86/mm=
.h=0A+++ b/xen/include/asm-x86/mm.h=0A@@ -579,6 +579,8 @@ int map_ldt_shado=
w_page(unsigned int);=0A int create_perdomain_mapping(struct domain *, =
unsigned long va,=0A                              unsigned int nr, =
l1_pgentry_t **,=0A                              struct page_info =
**);=0A+void destroy_perdomain_mapping(struct domain *, unsigned long =
va,=0A+                               unsigned int nr);=0A void free_perdom=
ain_mappings(struct domain *);=0A =0A extern int memory_add(unsigned long =
spfn, unsigned long epfn, unsigned int pxm);=0A--- a/xen/include/asm-x86/x8=
6_64/uaccess.h=0A+++ b/xen/include/asm-x86/x86_64/uaccess.h=0A@@ -1,16 =
+1,15 @@=0A #ifndef __X86_64_UACCESS_H=0A #define __X86_64_UACCESS_H=0A =
=0A-#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()=0A+#defin=
e COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))=0A #define =
COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)=0A struct vcpu;=0A-void *compat_arg=
_xlat_virt_base(void);=0A int setup_compat_arg_xlat(struct vcpu *v);=0A =
void free_compat_arg_xlat(struct vcpu *v);=0A #define is_compat_arg_xlat_ra=
nge(addr, size) ({                               \=0A     unsigned long =
__off;                                                      \=0A     __off =
=3D (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_BASE; =
\=0A-    (__off <=3D COMPAT_ARG_XLAT_SIZE) &&                              =
          \=0A+    (__off < COMPAT_ARG_XLAT_SIZE) &&                       =
                  \=0A     ((__off + (unsigned long)(size)) <=3D COMPAT_ARG=
_XLAT_SIZE);                \=0A })=0A =0A
--=__Part4B7B3B83.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

--=__Part4B7B3B83.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 16:06:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN3H-0007kY-Ui; Tue, 26 Feb 2013 16:06:47 +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 1UAN3H-0007kQ-1V
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:06:47 +0000
Received: from [85.158.139.211:2153] by server-15.bemta-5.messagelabs.com id
	57/0C-22815-69DDC215; Tue, 26 Feb 2013 16:06:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361894805!19193479!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24878 invoked from network); 26 Feb 2013 16:06:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:06:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:06:45 +0000
Message-Id: <512CEBA302000078000C127A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:06:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512CE92B02000078000C1256@nat28.tlf.novell.com>
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4B7B3B83.0__="
Subject: [Xen-devel] [PATCH v2 2/3] x86: rework hypercall argument
 translation area 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>
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.

--=__Part4B7B3B83.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... using the new per-domain mapping management functions, adding
destroy_perdomain_mapping() to the previously introduced pair.

Rather than using an order-1 Xen heap allocation, use (currently 2)
individual domain heap pages to populate space in the per-domain
mapping area.

Also fix a benign off-by-one mistake in is_compat_arg_xlat_range().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5657,6 +5657,59 @@ int create_perdomain_mapping(struct doma
     return rc;
 }
=20
+void destroy_perdomain_mapping(struct domain *d, unsigned long va,
+                               unsigned int nr)
+{
+    const l3_pgentry_t *l3tab, *pl3e;
+
+    ASSERT(va >=3D PERDOMAIN_VIRT_START &&
+           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
+    ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
+
+    if ( !d->arch.perdomain_l3_pg )
+        return;
+
+    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+    pl3e =3D l3tab + l3_table_offset(va);
+
+    if ( l3e_get_flags(*pl3e) & _PAGE_PRESENT )
+    {
+        const l2_pgentry_t *l2tab =3D map_domain_page(l3e_get_pfn(*pl3e));=

+        const l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);
+        unsigned int i =3D l1_table_offset(va);
+
+        while ( nr )
+        {
+            if ( l2e_get_flags(*pl2e) & _PAGE_PRESENT )
+            {
+                l1_pgentry_t *l1tab =3D map_domain_page(l2e_get_pfn(*pl2e)=
);
+
+                for ( ; nr && i < L1_PAGETABLE_ENTRIES; --nr, ++i )
+                {
+                    if ( (l1e_get_flags(l1tab[i]) &
+                          (_PAGE_PRESENT | _PAGE_AVAIL0)) =3D=3D
+                         (_PAGE_PRESENT | _PAGE_AVAIL0) )
+                        free_domheap_page(l1e_get_page(l1tab[i]));
+                    l1tab[i] =3D l1e_empty();
+                }
+
+                unmap_domain_page(l1tab);
+            }
+            else if ( nr + i < L1_PAGETABLE_ENTRIES )
+                break;
+            else
+                nr -=3D L1_PAGETABLE_ENTRIES - i;
+
+            ++pl2e;
+            i =3D 0;
+        }
+
+        unmap_domain_page(l2tab);
+    }
+
+    unmap_domain_page(l3tab);
+}
+
 void free_perdomain_mappings(struct domain *d)
 {
     l3_pgentry_t *l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -6,8 +6,8 @@
  * Copyright 2002 Andi Kleen <ak@suse.de>
  */
=20
-#include <xen/config.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <asm/uaccess.h>
=20
 unsigned long __copy_to_user_ll(void __user *to, const void *from, =
unsigned n)
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -832,27 +832,17 @@ void __init zap_low_mappings(void)
                      __PAGE_HYPERVISOR);
 }
=20
-void *compat_arg_xlat_virt_base(void)
-{
-    return current->arch.compat_arg_xlat;
-}
-
 int setup_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
-
-    v->arch.compat_arg_xlat =3D alloc_xenheap_pages(order,
-                                                  MEMF_node(vcpu_to_node(v=
)));
-
-    return v->arch.compat_arg_xlat ? 0 : -ENOMEM;
+    return create_perdomain_mapping(v->domain, ARG_XLAT_START(v),
+                                    PFN_UP(COMPAT_ARG_XLAT_SIZE),
+                                    NULL, NIL(struct page_info *));
 }
=20
 void free_compat_arg_xlat(struct vcpu *v)
 {
-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);
-
-    free_xenheap_pages(v->arch.compat_arg_xlat, order);
-    v->arch.compat_arg_xlat =3D NULL;
+    destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v),
+                              PFN_UP(COMPAT_ARG_XLAT_SIZE));
 }
=20
 void cleanup_frame_table(struct mem_hotadd_info *info)
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]
 /* Slot 260: per-domain mappings (including map cache). */
 #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
 #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER=
))
-#define PERDOMAIN_SLOTS         2
+#define PERDOMAIN_SLOTS         3
 #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
                                  (PERDOMAIN_SLOT_MBYTES << 20))
 /* Slot 261: machine-to-phys conversion table (256GB). */
@@ -311,6 +311,13 @@ extern unsigned long xen_phys_start;
 #define MAPCACHE_VIRT_END        (MAPCACHE_VIRT_START + \
                                   MAPCACHE_ENTRIES * PAGE_SIZE)
=20
+/* Argument translation area. The third per-domain-mapping sub-area. */
+#define ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(2)
+/* Allow for at least one guard page (COMPAT_ARG_XLAT_SIZE being 2 =
pages): */
+#define ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)
+#define ARG_XLAT_START(v)        \
+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
+
 #define ELFSIZE 64
=20
 #define ARCH_CRASH_SAVE_VMCOREINFO
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -442,9 +442,6 @@ struct arch_vcpu
=20
     /* A secondary copy of the vcpu time info. */
     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
-
-    void *compat_arg_xlat;
-
 } __cacheline_aligned;
=20
 /* Shorthands to improve code legibility. */
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -579,6 +579,8 @@ int map_ldt_shadow_page(unsigned int);
 int create_perdomain_mapping(struct domain *, unsigned long va,
                              unsigned int nr, l1_pgentry_t **,
                              struct page_info **);
+void destroy_perdomain_mapping(struct domain *, unsigned long va,
+                               unsigned int nr);
 void free_perdomain_mappings(struct domain *);
=20
 extern int memory_add(unsigned long spfn, unsigned long epfn, unsigned =
int pxm);
--- a/xen/include/asm-x86/x86_64/uaccess.h
+++ b/xen/include/asm-x86/x86_64/uaccess.h
@@ -1,16 +1,15 @@
 #ifndef __X86_64_UACCESS_H
 #define __X86_64_UACCESS_H
=20
-#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()
+#define COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))
 #define COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)
 struct vcpu;
-void *compat_arg_xlat_virt_base(void);
 int setup_compat_arg_xlat(struct vcpu *v);
 void free_compat_arg_xlat(struct vcpu *v);
 #define is_compat_arg_xlat_range(addr, size) ({                           =
    \
     unsigned long __off;                                                  =
    \
     __off =3D (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_=
BASE; \
-    (__off <=3D COMPAT_ARG_XLAT_SIZE) &&                                  =
      \
+    (__off < COMPAT_ARG_XLAT_SIZE) &&                                     =
    \
     ((__off + (unsigned long)(size)) <=3D COMPAT_ARG_XLAT_SIZE);          =
      \
 })
=20



--=__Part4B7B3B83.0__=
Content-Type: text/plain; name="x86-map-arg-xlat-area.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-arg-xlat-area.patch"

x86: rework hypercall argument translation area setup=0A=0A... using the =
new per-domain mapping management functions, adding=0Adestroy_perdomain_map=
ping() to the previously introduced pair.=0A=0ARather than using an =
order-1 Xen heap allocation, use (currently 2)=0Aindividual domain heap =
pages to populate space in the per-domain=0Amapping area.=0A=0AAlso fix a =
benign off-by-one mistake in is_compat_arg_xlat_range().=0A=0ASigned-off-by=
: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/mm.c=0A+++ =
b/xen/arch/x86/mm.c=0A@@ -5657,6 +5657,59 @@ int create_perdomain_mapping(s=
truct doma=0A     return rc;=0A }=0A =0A+void destroy_perdomain_mapping(str=
uct domain *d, unsigned long va,=0A+                               =
unsigned int nr)=0A+{=0A+    const l3_pgentry_t *l3tab, *pl3e;=0A+=0A+    =
ASSERT(va >=3D PERDOMAIN_VIRT_START &&=0A+           va < PERDOMAIN_VIRT_SL=
OT(PERDOMAIN_SLOTS));=0A+    ASSERT(!l3_table_offset(va ^ (va + nr * =
PAGE_SIZE - 1)));=0A+=0A+    if ( !d->arch.perdomain_l3_pg )=0A+        =
return;=0A+=0A+    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);=0A=
+    pl3e =3D l3tab + l3_table_offset(va);=0A+=0A+    if ( l3e_get_flags(*p=
l3e) & _PAGE_PRESENT )=0A+    {=0A+        const l2_pgentry_t *l2tab =3D =
map_domain_page(l3e_get_pfn(*pl3e));=0A+        const l2_pgentry_t *pl2e =
=3D l2tab + l2_table_offset(va);=0A+        unsigned int i =3D l1_table_off=
set(va);=0A+=0A+        while ( nr )=0A+        {=0A+            if ( =
l2e_get_flags(*pl2e) & _PAGE_PRESENT )=0A+            {=0A+                =
l1_pgentry_t *l1tab =3D map_domain_page(l2e_get_pfn(*pl2e));=0A+=0A+       =
         for ( ; nr && i < L1_PAGETABLE_ENTRIES; --nr, ++i )=0A+           =
     {=0A+                    if ( (l1e_get_flags(l1tab[i]) &=0A+          =
                (_PAGE_PRESENT | _PAGE_AVAIL0)) =3D=3D=0A+                 =
        (_PAGE_PRESENT | _PAGE_AVAIL0) )=0A+                        =
free_domheap_page(l1e_get_page(l1tab[i]));=0A+                    l1tab[i] =
=3D l1e_empty();=0A+                }=0A+=0A+                unmap_domain_p=
age(l1tab);=0A+            }=0A+            else if ( nr + i < L1_PAGETABLE=
_ENTRIES )=0A+                break;=0A+            else=0A+               =
 nr -=3D L1_PAGETABLE_ENTRIES - i;=0A+=0A+            ++pl2e;=0A+          =
  i =3D 0;=0A+        }=0A+=0A+        unmap_domain_page(l2tab);=0A+    =
}=0A+=0A+    unmap_domain_page(l3tab);=0A+}=0A+=0A void free_perdomain_mapp=
ings(struct domain *d)=0A {=0A     l3_pgentry_t *l3tab =3D __map_domain_pag=
e(d->arch.perdomain_l3_pg);=0A--- a/xen/arch/x86/usercopy.c=0A+++ =
b/xen/arch/x86/usercopy.c=0A@@ -6,8 +6,8 @@=0A  * Copyright 2002 Andi =
Kleen <ak@suse.de>=0A  */=0A =0A-#include <xen/config.h>=0A #include =
<xen/lib.h>=0A+#include <xen/sched.h>=0A #include <asm/uaccess.h>=0A =0A =
unsigned long __copy_to_user_ll(void __user *to, const void *from, =
unsigned n)=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ b/xen/arch/x86/x86_64/mm=
.c=0A@@ -832,27 +832,17 @@ void __init zap_low_mappings(void)=0A           =
           __PAGE_HYPERVISOR);=0A }=0A =0A-void *compat_arg_xlat_virt_base(=
void)=0A-{=0A-    return current->arch.compat_arg_xlat;=0A-}=0A-=0A int =
setup_compat_arg_xlat(struct vcpu *v)=0A {=0A-    unsigned int order =3D =
get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=0A-=0A-    v->arch.compat_arg_x=
lat =3D alloc_xenheap_pages(order,=0A-                                     =
             MEMF_node(vcpu_to_node(v)));=0A-=0A-    return v->arch.compat_=
arg_xlat ? 0 : -ENOMEM;=0A+    return create_perdomain_mapping(v->domain, =
ARG_XLAT_START(v),=0A+                                    PFN_UP(COMPAT_ARG=
_XLAT_SIZE),=0A+                                    NULL, NIL(struct =
page_info *));=0A }=0A =0A void free_compat_arg_xlat(struct vcpu *v)=0A =
{=0A-    unsigned int order =3D get_order_from_bytes(COMPAT_ARG_XLAT_SIZE);=
=0A-=0A-    free_xenheap_pages(v->arch.compat_arg_xlat, order);=0A-    =
v->arch.compat_arg_xlat =3D NULL;=0A+    destroy_perdomain_mapping(v->domai=
n, ARG_XLAT_START(v),=0A+                              PFN_UP(COMPAT_ARG_XL=
AT_SIZE));=0A }=0A =0A void cleanup_frame_table(struct mem_hotadd_info =
*info)=0A--- a/xen/include/asm-x86/config.h=0A+++ b/xen/include/asm-x86/con=
fig.h=0A@@ -212,7 +212,7 @@ extern unsigned char boot_edid_info[128]=0A /* =
Slot 260: per-domain mappings (including map cache). */=0A #define =
PERDOMAIN_VIRT_START    (PML4_ADDR(260))=0A #define PERDOMAIN_SLOT_MBYTES  =
 (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORDER))=0A-#define PERDOMAIN_SLOTS   =
      2=0A+#define PERDOMAIN_SLOTS         3=0A #define PERDOMAIN_VIRT_SLOT=
(s)  (PERDOMAIN_VIRT_START + (s) * \=0A                                  =
(PERDOMAIN_SLOT_MBYTES << 20))=0A /* Slot 261: machine-to-phys conversion =
table (256GB). */=0A@@ -311,6 +311,13 @@ extern unsigned long xen_phys_star=
t;=0A #define MAPCACHE_VIRT_END        (MAPCACHE_VIRT_START + \=0A         =
                          MAPCACHE_ENTRIES * PAGE_SIZE)=0A =0A+/* Argument =
translation area. The third per-domain-mapping sub-area. */=0A+#define =
ARG_XLAT_VIRT_START      PERDOMAIN_VIRT_SLOT(2)=0A+/* Allow for at least =
one guard page (COMPAT_ARG_XLAT_SIZE being 2 pages): */=0A+#define =
ARG_XLAT_VA_SHIFT        (2 + PAGE_SHIFT)=0A+#define ARG_XLAT_START(v)     =
   \=0A+    (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))=0A+=
=0A #define ELFSIZE 64=0A =0A #define ARCH_CRASH_SAVE_VMCOREINFO=0A--- =
a/xen/include/asm-x86/domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ =
-442,9 +442,6 @@ struct arch_vcpu=0A =0A     /* A secondary copy of the =
vcpu time info. */=0A     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_gues=
t;=0A-=0A-    void *compat_arg_xlat;=0A-=0A } __cacheline_aligned;=0A =0A =
/* Shorthands to improve code legibility. */=0A--- a/xen/include/asm-x86/mm=
.h=0A+++ b/xen/include/asm-x86/mm.h=0A@@ -579,6 +579,8 @@ int map_ldt_shado=
w_page(unsigned int);=0A int create_perdomain_mapping(struct domain *, =
unsigned long va,=0A                              unsigned int nr, =
l1_pgentry_t **,=0A                              struct page_info =
**);=0A+void destroy_perdomain_mapping(struct domain *, unsigned long =
va,=0A+                               unsigned int nr);=0A void free_perdom=
ain_mappings(struct domain *);=0A =0A extern int memory_add(unsigned long =
spfn, unsigned long epfn, unsigned int pxm);=0A--- a/xen/include/asm-x86/x8=
6_64/uaccess.h=0A+++ b/xen/include/asm-x86/x86_64/uaccess.h=0A@@ -1,16 =
+1,15 @@=0A #ifndef __X86_64_UACCESS_H=0A #define __X86_64_UACCESS_H=0A =
=0A-#define COMPAT_ARG_XLAT_VIRT_BASE compat_arg_xlat_virt_base()=0A+#defin=
e COMPAT_ARG_XLAT_VIRT_BASE ((void *)ARG_XLAT_START(current))=0A #define =
COMPAT_ARG_XLAT_SIZE      (2*PAGE_SIZE)=0A struct vcpu;=0A-void *compat_arg=
_xlat_virt_base(void);=0A int setup_compat_arg_xlat(struct vcpu *v);=0A =
void free_compat_arg_xlat(struct vcpu *v);=0A #define is_compat_arg_xlat_ra=
nge(addr, size) ({                               \=0A     unsigned long =
__off;                                                      \=0A     __off =
=3D (unsigned long)(addr) - (unsigned long)COMPAT_ARG_XLAT_VIRT_BASE; =
\=0A-    (__off <=3D COMPAT_ARG_XLAT_SIZE) &&                              =
          \=0A+    (__off < COMPAT_ARG_XLAT_SIZE) &&                       =
                  \=0A     ((__off + (unsigned long)(size)) <=3D COMPAT_ARG=
_XLAT_SIZE);                \=0A })=0A =0A
--=__Part4B7B3B83.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

--=__Part4B7B3B83.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 16:07:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN3V-0007m2-Cj; Tue, 26 Feb 2013 16:07:01 +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 1UAN3T-0007lh-Ro
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:07:00 +0000
Received: from [85.158.139.211:3057] by server-11.bemta-5.messagelabs.com id
	C4/52-27486-3ADDC215; Tue, 26 Feb 2013 16:06:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361894817!19421073!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26687 invoked from network); 26 Feb 2013 16:06:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:06:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:06:12 +0000
Message-Id: <512CEB8302000078000C1276@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:06:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512CE92B02000078000C1256@nat28.tlf.novell.com>
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAB9BDB63.0__="
Subject: [Xen-devel] [PATCH v2 1/3] x86: introduce create_perdomain_mapping()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartAB9BDB63.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... as well as free_perdomain_mappings(), and use them to carry out the
existing per-domain mapping setup/teardown. This at once makes the
setup of the first sub-range PV domain specific (with idle domains also
excluded), as the GDT/LDT mapping area is needed only for those.

Also fix an improperly scaled BUILD_BUG_ON() expression in
mapcache_domain_init().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -372,37 +372,16 @@ int switch_compat(struct domain *d)
 int vcpu_initialise(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
-    unsigned int idx;
     int rc;
=20
     v->arch.flags =3D TF_kernel_mode;
=20
-    idx =3D perdomain_pt_idx(v);
-    if ( !d->arch.perdomain_pts[idx] )
-    {
-        void *pt;
-        l2_pgentry_t *l2tab;
-
-        pt =3D alloc_xenheap_pages(0, MEMF_node(vcpu_to_node(v)));
-        if ( !pt )
-            return -ENOMEM;
-        clear_page(pt);
-        d->arch.perdomain_pts[idx] =3D pt;
-
-        l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[0]);
-        l2tab[l2_table_offset(PERDOMAIN_VIRT_START) + idx]
-            =3D l2e_from_paddr(__pa(pt), __PAGE_HYPERVISOR);
-        unmap_domain_page(l2tab);
-    }
-
     rc =3D mapcache_vcpu_init(v);
     if ( rc )
         return rc;
=20
     paging_vcpu_init(v);
=20
-    v->arch.perdomain_ptes =3D perdomain_ptes(d, v);
-
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
@@ -420,6 +399,12 @@ int vcpu_initialise(struct vcpu *v)
=20
     if ( !is_idle_domain(d) )
     {
+        rc =3D create_perdomain_mapping(d, GDT_VIRT_START(v),
+                                      1 << GDT_LDT_VCPU_SHIFT,
+                                      d->arch.pv_domain.gdt_ldt_l1tab, =
NULL);
+        if ( rc )
+            goto done;
+
         BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
                      PAGE_SIZE);
         v->arch.pv_vcpu.trap_ctxt =3D xzalloc_array(struct trap_info,
@@ -478,8 +463,6 @@ void vcpu_destroy(struct vcpu *v)
=20
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
-    struct page_info *pg;
-    l3_pgentry_t *l3tab;
     int i, paging_initialised =3D 0;
     int rc =3D -ENOMEM;
=20
@@ -510,29 +493,24 @@ int arch_domain_create(struct domain *d,
                d->domain_id);
     }
=20
-    BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.perdomain_pts)
-                 !=3D PAGE_SIZE);
-    d->arch.perdomain_pts =3D
-        alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-    if ( !d->arch.perdomain_pts )
-        goto fail;
-    clear_page(d->arch.perdomain_pts);
-
-    pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
-    if ( pg =3D=3D NULL )
-        goto fail;
-    d->arch.perdomain_l2_pg[0] =3D pg;
-    clear_domain_page(page_to_mfn(pg));
+    if ( is_hvm_domain(d) )
+        rc =3D create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, =
NULL);
+    else if ( is_idle_domain(d) )
+        rc =3D 0;
+    else
+    {
+        d->arch.pv_domain.gdt_ldt_l1tab =3D
+            alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
+        if ( !d->arch.pv_domain.gdt_ldt_l1tab )
+            goto fail;
+        clear_page(d->arch.pv_domain.gdt_ldt_l1tab);
=20
-    pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
-    if ( pg =3D=3D NULL )
+        rc =3D create_perdomain_mapping(d, GDT_LDT_VIRT_START,
+                                      GDT_LDT_MBYTES << (20 - PAGE_SHIFT),=

+                                      NULL, NULL);
+    }
+    if ( rc )
         goto fail;
-    d->arch.perdomain_l3_pg =3D pg;
-    l3tab =3D __map_domain_page(pg);
-    clear_page(l3tab);
-    l3tab[l3_table_offset(PERDOMAIN_VIRT_START)] =3D
-        l3e_from_page(d->arch.perdomain_l2_pg[0], __PAGE_HYPERVISOR);
-    unmap_domain_page(l3tab);
=20
     mapcache_domain_init(d);
=20
@@ -608,19 +586,14 @@ int arch_domain_create(struct domain *d,
     if ( paging_initialised )
         paging_final_teardown(d);
     mapcache_domain_exit(d);
-    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)
-        if ( d->arch.perdomain_l2_pg[i] )
-            free_domheap_page(d->arch.perdomain_l2_pg[i]);
-    if ( d->arch.perdomain_l3_pg )
-        free_domheap_page(d->arch.perdomain_l3_pg);
-    free_xenheap_page(d->arch.perdomain_pts);
+    free_perdomain_mappings(d);
+    if ( !is_hvm_domain(d) )
+        free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
     return rc;
 }
=20
 void arch_domain_destroy(struct domain *d)
 {
-    unsigned int i;
-
     if ( is_hvm_domain(d) )
         hvm_domain_destroy(d);
     else
@@ -634,13 +607,9 @@ void arch_domain_destroy(struct domain *
=20
     mapcache_domain_exit(d);
=20
-    for ( i =3D 0; i < PDPT_L2_ENTRIES; ++i )
-        free_xenheap_page(d->arch.perdomain_pts[i]);
-    free_xenheap_page(d->arch.perdomain_pts);
-    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)
-        if ( d->arch.perdomain_l2_pg[i] )
-            free_domheap_page(d->arch.perdomain_l2_pg[i]);
-    free_domheap_page(d->arch.perdomain_l3_pg);
+    free_perdomain_mappings(d);
+    if ( !is_hvm_domain(d) )
+        free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
=20
     free_xenheap_page(d->shared_info);
     cleanup_domain_irq_mapping(d);
@@ -1515,10 +1484,11 @@ static void __context_switch(void)
     if ( need_full_gdt(n) )
     {
         unsigned long mfn =3D virt_to_mfn(gdt);
+        l1_pgentry_t *pl1e =3D gdt_ldt_ptes(n->domain, n);
         unsigned int i;
+
         for ( i =3D 0; i < NR_RESERVED_GDT_PAGES; i++ )
-            l1e_write(n->arch.perdomain_ptes +
-                      FIRST_RESERVED_GDT_PAGE + i,
+            l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,
                       l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR));
     }
=20
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -243,10 +243,7 @@ void copy_domain_page(unsigned long dmfn
 int mapcache_domain_init(struct domain *d)
 {
     struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;
-    l3_pgentry_t *l3tab;
-    l2_pgentry_t *l2tab;
-    unsigned int i, bitmap_pages, memf =3D MEMF_node(domain_to_node(d));
-    unsigned long *end;
+    unsigned int bitmap_pages;
=20
     if ( is_hvm_domain(d) || is_idle_domain(d) )
         return 0;
@@ -256,48 +253,23 @@ int mapcache_domain_init(struct domain *
         return 0;
 #endif
=20
-    dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES + =
1);
-    d->arch.perdomain_l2_pg[MAPCACHE_SLOT] =3D alloc_domheap_page(NULL, =
memf);
-    if ( !dcache->l1tab || !d->arch.perdomain_l2_pg[MAPCACHE_SLOT] )
+    dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);
+    if ( !dcache->l1tab )
         return -ENOMEM;
=20
-    clear_domain_page(page_to_mfn(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]))=
;
-    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
-    l3tab[l3_table_offset(MAPCACHE_VIRT_START)] =3D
-        l3e_from_page(d->arch.perdomain_l2_pg[MAPCACHE_SLOT],
-                      __PAGE_HYPERVISOR);
-    unmap_domain_page(l3tab);
-
-    l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]);
-
-    BUILD_BUG_ON(MAPCACHE_VIRT_END + 3 +
-                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
) >
+    BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
+                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
)) >
                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20));
     bitmap_pages =3D PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
);
     dcache->inuse =3D (void *)MAPCACHE_VIRT_END + PAGE_SIZE;
     dcache->garbage =3D dcache->inuse +
                       (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
-    end =3D dcache->garbage + bitmap_pages * PAGE_SIZE / sizeof(long);
-
-    for ( i =3D l2_table_offset((unsigned long)dcache->inuse);
-          i <=3D l2_table_offset((unsigned long)(end - 1)); ++i )
-    {
-        ASSERT(i <=3D MAPCACHE_L2_ENTRIES);
-        dcache->l1tab[i] =3D alloc_xenheap_pages(0, memf);
-        if ( !dcache->l1tab[i] )
-        {
-            unmap_domain_page(l2tab);
-            return -ENOMEM;
-        }
-        clear_page(dcache->l1tab[i]);
-        l2tab[i] =3D l2e_from_paddr(__pa(dcache->l1tab[i]), __PAGE_HYPERVI=
SOR);
-    }
-
-    unmap_domain_page(l2tab);
=20
     spin_lock_init(&dcache->lock);
=20
-    return 0;
+    return create_perdomain_mapping(d, (unsigned long)dcache->inuse,
+                                    2 * bitmap_pages + 1,
+                                    NIL(l1_pgentry_t *), NULL);
 }
=20
 void mapcache_domain_exit(struct domain *d)
@@ -307,94 +279,41 @@ void mapcache_domain_exit(struct domain=20
     if ( is_hvm_domain(d) )
         return;
=20
-    if ( dcache->l1tab )
-    {
-        unsigned long i;
-
-        for ( i =3D (unsigned long)dcache->inuse; ; i +=3D PAGE_SIZE )
-        {
-            l1_pgentry_t *pl1e;
-
-            if ( l2_table_offset(i) > MAPCACHE_L2_ENTRIES ||
-                 !dcache->l1tab[l2_table_offset(i)] )
-                break;
-
-            pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)=
];
-            if ( l1e_get_flags(*pl1e) )
-                free_domheap_page(l1e_get_page(*pl1e));
-        }
-
-        for ( i =3D 0; i < MAPCACHE_L2_ENTRIES + 1; ++i )
-            free_xenheap_page(dcache->l1tab[i]);
-
-        xfree(dcache->l1tab);
-    }
+    xfree(dcache->l1tab);
 }
=20
 int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
     struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;
-    l2_pgentry_t *l2tab;
     unsigned long i;
-    unsigned int memf =3D MEMF_node(vcpu_to_node(v));
+    unsigned int ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
+    unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
=20
     if ( is_hvm_vcpu(v) || !dcache->l1tab )
         return 0;
=20
-    l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]);
-
-    while ( dcache->entries < d->max_vcpus * MAPCACHE_VCPU_ENTRIES )
+    if ( ents > dcache->entries )
     {
-        unsigned int ents =3D dcache->entries + MAPCACHE_VCPU_ENTRIES;
-        l1_pgentry_t *pl1e;
-
         /* Populate page tables. */
-        if ( !dcache->l1tab[i =3D mapcache_l2_entry(ents - 1)] )
-        {
-            dcache->l1tab[i] =3D alloc_xenheap_pages(0, memf);
-            if ( !dcache->l1tab[i] )
-            {
-                unmap_domain_page(l2tab);
-                return -ENOMEM;
-            }
-            clear_page(dcache->l1tab[i]);
-            l2tab[i] =3D l2e_from_paddr(__pa(dcache->l1tab[i]),
-                                      __PAGE_HYPERVISOR);
-        }
+        int rc =3D create_perdomain_mapping(d, MAPCACHE_VIRT_START,
+                                          d->max_vcpus * MAPCACHE_VCPU_ENT=
RIES,
+                                          dcache->l1tab, NULL);
=20
         /* Populate bit maps. */
-        i =3D (unsigned long)(dcache->inuse + BITS_TO_LONGS(ents));
-        pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)];
-        if ( !l1e_get_flags(*pl1e) )
-        {
-            struct page_info *pg =3D alloc_domheap_page(NULL, memf);
+        if ( !rc )
+            rc =3D create_perdomain_mapping(d, (unsigned long)dcache->inus=
e,
+                                          nr, NULL, NIL(struct page_info =
*));
+        if ( !rc )
+            rc =3D create_perdomain_mapping(d, (unsigned long)dcache->garb=
age,
+                                          nr, NULL, NIL(struct page_info =
*));
=20
-            if ( pg )
-            {
-                clear_domain_page(page_to_mfn(pg));
-                *pl1e =3D l1e_from_page(pg, __PAGE_HYPERVISOR);
-                pg =3D alloc_domheap_page(NULL, memf);
-            }
-            if ( !pg )
-            {
-                unmap_domain_page(l2tab);
-                return -ENOMEM;
-            }
-
-            i =3D (unsigned long)(dcache->garbage + BITS_TO_LONGS(ents));
-            pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)=
];
-            ASSERT(!l1e_get_flags(*pl1e));
-
-            clear_domain_page(page_to_mfn(pg));
-            *pl1e =3D l1e_from_page(pg, __PAGE_HYPERVISOR);
-        }
+        if ( rc )
+            return rc;
=20
         dcache->entries =3D ents;
     }
=20
-    unmap_domain_page(l2tab);
-
     /* Mark all maphash entries as not in use. */
     BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES);
     for ( i =3D 0; i < MAPHASH_ENTRIES; i++ )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -511,6 +511,7 @@ void update_cr3(struct vcpu *v)
=20
 static void invalidate_shadow_ldt(struct vcpu *v, int flush)
 {
+    l1_pgentry_t *pl1e;
     int i;
     unsigned long pfn;
     struct page_info *page;
@@ -523,12 +524,13 @@ static void invalidate_shadow_ldt(struct
         goto out;
=20
     v->arch.pv_vcpu.shadow_ldt_mapcnt =3D 0;
+    pl1e =3D gdt_ldt_ptes(v->domain, v);
=20
     for ( i =3D 16; i < 32; i++ )
     {
-        pfn =3D l1e_get_pfn(v->arch.perdomain_ptes[i]);
+        pfn =3D l1e_get_pfn(pl1e[i]);
         if ( pfn =3D=3D 0 ) continue;
-        l1e_write(&v->arch.perdomain_ptes[i], l1e_empty());
+        l1e_write(&pl1e[i], l1e_empty());
         page =3D mfn_to_page(pfn);
         ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
         ASSERT_PAGE_IS_DOMAIN(page, v->domain);
@@ -596,7 +598,7 @@ int map_ldt_shadow_page(unsigned int off
     nl1e =3D l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | =
_PAGE_RW);
=20
     spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock);
-    l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e);
+    l1e_write(&gdt_ldt_ptes(d, v)[off + 16], nl1e);
     v->arch.pv_vcpu.shadow_ldt_mapcnt++;
     spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock);
=20
@@ -4073,15 +4075,17 @@ long do_update_va_mapping_otherdomain(un
=20
 void destroy_gdt(struct vcpu *v)
 {
+    l1_pgentry_t *pl1e;
     int i;
     unsigned long pfn;
=20
     v->arch.pv_vcpu.gdt_ents =3D 0;
+    pl1e =3D gdt_ldt_ptes(v->domain, v);
     for ( i =3D 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
     {
-        if ( (pfn =3D l1e_get_pfn(v->arch.perdomain_ptes[i])) !=3D 0 )
+        if ( (pfn =3D l1e_get_pfn(pl1e[i])) !=3D 0 )
             put_page_and_type(mfn_to_page(pfn));
-        l1e_write(&v->arch.perdomain_ptes[i], l1e_empty());
+        l1e_write(&pl1e[i], l1e_empty());
         v->arch.pv_vcpu.gdt_frames[i] =3D 0;
     }
 }
@@ -4092,6 +4096,7 @@ long set_gdt(struct vcpu *v,=20
              unsigned int entries)
 {
     struct domain *d =3D v->domain;
+    l1_pgentry_t *pl1e;
     /* NB. There are 512 8-byte entries per GDT page. */
     int i, nr_pages =3D (entries + 511) / 512;
     unsigned long mfn, *pfns;
@@ -4124,11 +4129,11 @@ long set_gdt(struct vcpu *v,=20
=20
     /* Install the new GDT. */
     v->arch.pv_vcpu.gdt_ents =3D entries;
+    pl1e =3D gdt_ldt_ptes(d, v);
     for ( i =3D 0; i < nr_pages; i++ )
     {
         v->arch.pv_vcpu.gdt_frames[i] =3D frames[i];
-        l1e_write(&v->arch.perdomain_ptes[i],
-                  l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
+        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
     }
=20
     xfree(pfns);
@@ -5528,6 +5533,175 @@ void __iomem *ioremap(paddr_t pa, size_t
     return (void __force __iomem *)va;
 }
=20
+int create_perdomain_mapping(struct domain *d, unsigned long va,
+                             unsigned int nr, l1_pgentry_t **pl1tab,
+                             struct page_info **ppg)
+{
+    struct page_info *pg;
+    l3_pgentry_t *l3tab;
+    l2_pgentry_t *l2tab;
+    l1_pgentry_t *l1tab;
+    unsigned int memf =3D MEMF_node(domain_to_node(d));
+    int rc =3D 0;
+
+    ASSERT(va >=3D PERDOMAIN_VIRT_START &&
+           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
+
+    if ( !d->arch.perdomain_l3_pg )
+    {
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        l3tab =3D __map_domain_page(pg);
+        clear_page(l3tab);
+        d->arch.perdomain_l3_pg =3D pg;
+        if ( !nr )
+        {
+            unmap_domain_page(l3tab);
+            return 0;
+        }
+    }
+    else if ( !nr )
+        return 0;
+    else
+        l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+
+    ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
+
+    if ( !(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT) )
+    {
+        pg =3D alloc_domheap_page(NULL, memf);
+        if ( !pg )
+        {
+            unmap_domain_page(l3tab);
+            return -ENOMEM;
+        }
+        l2tab =3D __map_domain_page(pg);
+        clear_page(l2tab);
+        l3tab[l3_table_offset(va)] =3D l3e_from_page(pg, __PAGE_HYPERVISOR=
);
+    }
+    else
+        l2tab =3D map_domain_page(l3e_get_pfn(l3tab[l3_table_offset(va)]))=
;
+
+    unmap_domain_page(l3tab);
+
+    if ( !pl1tab && !ppg )
+    {
+        unmap_domain_page(l2tab);
+        return 0;
+    }
+
+    for ( l1tab =3D NULL; !rc && nr--; )
+    {
+        l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);
+
+        if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
+        {
+            if ( pl1tab && !IS_NIL(pl1tab) )
+            {
+                l1tab =3D alloc_xenheap_pages(0, memf);
+                if ( !l1tab )
+                {
+                    rc =3D -ENOMEM;
+                    break;
+                }
+                ASSERT(!pl1tab[l2_table_offset(va)]);
+                pl1tab[l2_table_offset(va)] =3D l1tab;
+                pg =3D virt_to_page(l1tab);
+            }
+            else
+            {
+                pg =3D alloc_domheap_page(NULL, memf);
+                if ( !pg )
+                {
+                    rc =3D -ENOMEM;
+                    break;
+                }
+                l1tab =3D __map_domain_page(pg);
+            }
+            clear_page(l1tab);
+            *pl2e =3D l2e_from_page(pg, __PAGE_HYPERVISOR);
+        }
+        else if ( !l1tab )
+            l1tab =3D map_domain_page(l2e_get_pfn(*pl2e));
+
+        if ( ppg &&
+             !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) =
)
+        {
+            pg =3D alloc_domheap_page(NULL, memf);
+            if ( pg )
+            {
+                clear_domain_page(page_to_mfn(pg));
+                if ( !IS_NIL(ppg) )
+                    *ppg++ =3D pg;
+                l1tab[l1_table_offset(va)] =3D
+                    l1e_from_page(pg, __PAGE_HYPERVISOR | _PAGE_AVAIL0);
+                l2e_add_flags(*pl2e, _PAGE_AVAIL0);
+            }
+            else
+                rc =3D -ENOMEM;
+        }
+
+        va +=3D PAGE_SIZE;
+        if ( rc || !nr || !l1_table_offset(va) )
+        {
+            /* Note that this is a no-op for the alloc_xenheap_page() =
case. */
+            unmap_domain_page(l1tab);
+            l1tab =3D NULL;
+        }
+    }
+
+    ASSERT(!l1tab);
+    unmap_domain_page(l2tab);
+
+    return rc;
+}
+
+void free_perdomain_mappings(struct domain *d)
+{
+    l3_pgentry_t *l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+    unsigned int i;
+
+    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)
+        if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )
+        {
+            struct page_info *l2pg =3D l3e_get_page(l3tab[i]);
+            l2_pgentry_t *l2tab =3D __map_domain_page(l2pg);
+            unsigned int j;
+
+            for ( j =3D 0; j < L2_PAGETABLE_ENTRIES; ++j )
+                if ( l2e_get_flags(l2tab[j]) & _PAGE_PRESENT )
+                {
+                    struct page_info *l1pg =3D l2e_get_page(l2tab[j]);
+
+                    if ( l2e_get_flags(l2tab[j]) & _PAGE_AVAIL0 )
+                    {
+                        l1_pgentry_t *l1tab =3D __map_domain_page(l1pg);
+                        unsigned int k;
+
+                        for ( k =3D 0; k < L1_PAGETABLE_ENTRIES; ++k )
+                            if ( (l1e_get_flags(l1tab[k]) &
+                                  (_PAGE_PRESENT | _PAGE_AVAIL0)) =3D=3D
+                                 (_PAGE_PRESENT | _PAGE_AVAIL0) )
+                                free_domheap_page(l1e_get_page(l1tab[k]));=

+
+                        unmap_domain_page(l1tab);
+                    }
+
+                    if ( is_xen_heap_page(l1pg) )
+                        free_xenheap_page(page_to_virt(l1pg));
+                    else
+                        free_domheap_page(l1pg);
+                }
+
+            unmap_domain_page(l2tab);
+            free_domheap_page(l2pg);
+        }
+
+    unmap_domain_page(l3tab);
+    free_domheap_page(d->arch.perdomain_l3_pg);
+}
+
 #ifdef MEMORY_GUARD
=20
 void memguard_init(void)
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -304,19 +304,13 @@ extern unsigned long xen_phys_start;
 #define LDT_VIRT_START(v)    \
     (GDT_VIRT_START(v) + (64*1024))
=20
-/* map_domain_page() map cache. The last per-domain-mapping sub-area. */
+/* map_domain_page() map cache. The second per-domain-mapping sub-area. =
*/
 #define MAPCACHE_VCPU_ENTRIES    (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEV=
ELS)
 #define MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)
-#define MAPCACHE_SLOT            (PERDOMAIN_SLOTS - 1)
-#define MAPCACHE_VIRT_START      PERDOMAIN_VIRT_SLOT(MAPCACHE_SLOT)
+#define MAPCACHE_VIRT_START      PERDOMAIN_VIRT_SLOT(1)
 #define MAPCACHE_VIRT_END        (MAPCACHE_VIRT_START + \
                                   MAPCACHE_ENTRIES * PAGE_SIZE)
=20
-#define PDPT_L1_ENTRIES       \
-    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)
-#define PDPT_L2_ENTRIES       \
-    ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)
-
 #define ELFSIZE 64
=20
 #define ARCH_CRASH_SAVE_VMCOREINFO
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -223,6 +223,8 @@ struct time_scale {
=20
 struct pv_domain
 {
+    l1_pgentry_t **gdt_ldt_l1tab;
+
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
@@ -241,8 +243,6 @@ struct pv_domain
=20
 struct arch_domain
 {
-    void **perdomain_pts;
-    struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];
     struct page_info *perdomain_l3_pg;
=20
     unsigned int hv_compat_vstart;
@@ -318,10 +318,10 @@ struct arch_domain
 #define has_arch_pdevs(d)    (!list_empty(&(d)->arch.pdev_list))
 #define has_arch_mmios(d)    (!rangeset_is_empty((d)->iomem_caps))
=20
-#define perdomain_pt_idx(v) \
+#define gdt_ldt_pt_idx(v) \
       ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
-#define perdomain_ptes(d, v) \
-    ((l1_pgentry_t *)(d)->arch.perdomain_pts[perdomain_pt_idx(v)] + \
+#define gdt_ldt_ptes(d, v) \
+    ((d)->arch.pv_domain.gdt_ldt_l1tab[gdt_ldt_pt_idx(v)] + \
      (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & (L1_PAGETABLE_ENTRIES - 1)))
=20
 struct pv_vcpu
@@ -406,12 +406,6 @@ struct arch_vcpu
         struct hvm_vcpu hvm_vcpu;
     };
=20
-    /*
-     * Every domain has a L1 pagetable of its own. Per-domain mappings
-     * are put in this table (eg. the current GDT is mapped here).
-     */
-    l1_pgentry_t *perdomain_ptes;
-
     pagetable_t guest_table_user;       /* (MFN) x86/64 user-space =
pagetable */
     pagetable_t guest_table;            /* (MFN) guest notion of cr3 */
     /* guest_table holds a ref to the page, and also a type-count unless
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -573,6 +573,14 @@ int donate_page(
=20
 int map_ldt_shadow_page(unsigned int);
=20
+#define NIL(type) ((type *)NULL - 1)
+#define IS_NIL(ptr) (!((ptr) + 1))
+
+int create_perdomain_mapping(struct domain *, unsigned long va,
+                             unsigned int nr, l1_pgentry_t **,
+                             struct page_info **);
+void free_perdomain_mappings(struct domain *);
+
 extern int memory_add(unsigned long spfn, unsigned long epfn, unsigned =
int pxm);
=20
 void domain_set_alloc_bitsize(struct domain *d);



--=__PartAB9BDB63.0__=
Content-Type: text/plain; name="x86-map-perdomain-page.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-perdomain-page.patch"

x86: introduce create_perdomain_mapping()=0A=0A... as well as free_perdomai=
n_mappings(), and use them to carry out the=0Aexisting per-domain mapping =
setup/teardown. This at once makes the=0Asetup of the first sub-range PV =
domain specific (with idle domains also=0Aexcluded), as the GDT/LDT =
mapping area is needed only for those.=0A=0AAlso fix an improperly scaled =
BUILD_BUG_ON() expression in=0Amapcache_domain_init().=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -372,37 +372,16 @@ int switch_compat(struct =
domain *d)=0A int vcpu_initialise(struct vcpu *v)=0A {=0A     struct =
domain *d =3D v->domain;=0A-    unsigned int idx;=0A     int rc;=0A =0A    =
 v->arch.flags =3D TF_kernel_mode;=0A =0A-    idx =3D perdomain_pt_idx(v);=
=0A-    if ( !d->arch.perdomain_pts[idx] )=0A-    {=0A-        void =
*pt;=0A-        l2_pgentry_t *l2tab;=0A-=0A-        pt =3D alloc_xenheap_pa=
ges(0, MEMF_node(vcpu_to_node(v)));=0A-        if ( !pt )=0A-            =
return -ENOMEM;=0A-        clear_page(pt);=0A-        d->arch.perdomain_pts=
[idx] =3D pt;=0A-=0A-        l2tab =3D __map_domain_page(d->arch.perdomain_=
l2_pg[0]);=0A-        l2tab[l2_table_offset(PERDOMAIN_VIRT_START) + =
idx]=0A-            =3D l2e_from_paddr(__pa(pt), __PAGE_HYPERVISOR);=0A-   =
     unmap_domain_page(l2tab);=0A-    }=0A-=0A     rc =3D mapcache_vcpu_ini=
t(v);=0A     if ( rc )=0A         return rc;=0A =0A     paging_vcpu_init(v)=
;=0A =0A-    v->arch.perdomain_ptes =3D perdomain_ptes(d, v);=0A-=0A     =
if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )=0A         return rc;=0A =0A@@ =
-420,6 +399,12 @@ int vcpu_initialise(struct vcpu *v)=0A =0A     if ( =
!is_idle_domain(d) )=0A     {=0A+        rc =3D create_perdomain_mapping(d,=
 GDT_VIRT_START(v),=0A+                                      1 << =
GDT_LDT_VCPU_SHIFT,=0A+                                      d->arch.pv_dom=
ain.gdt_ldt_l1tab, NULL);=0A+        if ( rc )=0A+            goto =
done;=0A+=0A         BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap=
_ctxt) >=0A                      PAGE_SIZE);=0A         v->arch.pv_vcpu.tra=
p_ctxt =3D xzalloc_array(struct trap_info,=0A@@ -478,8 +463,6 @@ void =
vcpu_destroy(struct vcpu *v)=0A =0A int arch_domain_create(struct domain =
*d, unsigned int domcr_flags)=0A {=0A-    struct page_info *pg;=0A-    =
l3_pgentry_t *l3tab;=0A     int i, paging_initialised =3D 0;=0A     int rc =
=3D -ENOMEM;=0A =0A@@ -510,29 +493,24 @@ int arch_domain_create(struct =
domain *d,=0A                d->domain_id);=0A     }=0A =0A-    BUILD_BUG_O=
N(PDPT_L2_ENTRIES * sizeof(*d->arch.perdomain_pts)=0A-                 =
!=3D PAGE_SIZE);=0A-    d->arch.perdomain_pts =3D=0A-        alloc_xenheap_=
pages(0, MEMF_node(domain_to_node(d)));=0A-    if ( !d->arch.perdomain_pts =
)=0A-        goto fail;=0A-    clear_page(d->arch.perdomain_pts);=0A-=0A-  =
  pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));=0A-    if =
( pg =3D=3D NULL )=0A-        goto fail;=0A-    d->arch.perdomain_l2_pg[0] =
=3D pg;=0A-    clear_domain_page(page_to_mfn(pg));=0A+    if ( is_hvm_domai=
n(d) )=0A+        rc =3D create_perdomain_mapping(d, PERDOMAIN_VIRT_START, =
0, NULL, NULL);=0A+    else if ( is_idle_domain(d) )=0A+        rc =3D =
0;=0A+    else=0A+    {=0A+        d->arch.pv_domain.gdt_ldt_l1tab =3D=0A+ =
           alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));=0A+       =
 if ( !d->arch.pv_domain.gdt_ldt_l1tab )=0A+            goto fail;=0A+     =
   clear_page(d->arch.pv_domain.gdt_ldt_l1tab);=0A =0A-    pg =3D =
alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));=0A-    if ( pg =
=3D=3D NULL )=0A+        rc =3D create_perdomain_mapping(d, GDT_LDT_VIRT_ST=
ART,=0A+                                      GDT_LDT_MBYTES << (20 - =
PAGE_SHIFT),=0A+                                      NULL, NULL);=0A+    =
}=0A+    if ( rc )=0A         goto fail;=0A-    d->arch.perdomain_l3_pg =
=3D pg;=0A-    l3tab =3D __map_domain_page(pg);=0A-    clear_page(l3tab);=
=0A-    l3tab[l3_table_offset(PERDOMAIN_VIRT_START)] =3D=0A-        =
l3e_from_page(d->arch.perdomain_l2_pg[0], __PAGE_HYPERVISOR);=0A-    =
unmap_domain_page(l3tab);=0A =0A     mapcache_domain_init(d);=0A =0A@@ =
-608,19 +586,14 @@ int arch_domain_create(struct domain *d,=0A     if ( =
paging_initialised )=0A         paging_final_teardown(d);=0A     mapcache_d=
omain_exit(d);=0A-    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)=0A-        =
if ( d->arch.perdomain_l2_pg[i] )=0A-            free_domheap_page(d->arch.=
perdomain_l2_pg[i]);=0A-    if ( d->arch.perdomain_l3_pg )=0A-        =
free_domheap_page(d->arch.perdomain_l3_pg);=0A-    free_xenheap_page(d->arc=
h.perdomain_pts);=0A+    free_perdomain_mappings(d);=0A+    if ( !is_hvm_do=
main(d) )=0A+        free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);=0A=
     return rc;=0A }=0A =0A void arch_domain_destroy(struct domain *d)=0A =
{=0A-    unsigned int i;=0A-=0A     if ( is_hvm_domain(d) )=0A         =
hvm_domain_destroy(d);=0A     else=0A@@ -634,13 +607,9 @@ void arch_domain_=
destroy(struct domain *=0A =0A     mapcache_domain_exit(d);=0A =0A-    for =
( i =3D 0; i < PDPT_L2_ENTRIES; ++i )=0A-        free_xenheap_page(d->arch.=
perdomain_pts[i]);=0A-    free_xenheap_page(d->arch.perdomain_pts);=0A-    =
for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)=0A-        if ( d->arch.perdomain_=
l2_pg[i] )=0A-            free_domheap_page(d->arch.perdomain_l2_pg[i]);=0A=
-    free_domheap_page(d->arch.perdomain_l3_pg);=0A+    free_perdomain_mapp=
ings(d);=0A+    if ( !is_hvm_domain(d) )=0A+        free_xenheap_page(d->ar=
ch.pv_domain.gdt_ldt_l1tab);=0A =0A     free_xenheap_page(d->shared_info);=
=0A     cleanup_domain_irq_mapping(d);=0A@@ -1515,10 +1484,11 @@ static =
void __context_switch(void)=0A     if ( need_full_gdt(n) )=0A     {=0A     =
    unsigned long mfn =3D virt_to_mfn(gdt);=0A+        l1_pgentry_t *pl1e =
=3D gdt_ldt_ptes(n->domain, n);=0A         unsigned int i;=0A+=0A         =
for ( i =3D 0; i < NR_RESERVED_GDT_PAGES; i++ )=0A-            l1e_write(n-=
>arch.perdomain_ptes +=0A-                      FIRST_RESERVED_GDT_PAGE + =
i,=0A+            l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,=0A         =
              l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR));=0A     }=0A =
=0A--- a/xen/arch/x86/domain_page.c=0A+++ b/xen/arch/x86/domain_page.c=0A@@=
 -243,10 +243,7 @@ void copy_domain_page(unsigned long dmfn=0A int =
mapcache_domain_init(struct domain *d)=0A {=0A     struct mapcache_domain =
*dcache =3D &d->arch.pv_domain.mapcache;=0A-    l3_pgentry_t *l3tab;=0A-   =
 l2_pgentry_t *l2tab;=0A-    unsigned int i, bitmap_pages, memf =3D =
MEMF_node(domain_to_node(d));=0A-    unsigned long *end;=0A+    unsigned =
int bitmap_pages;=0A =0A     if ( is_hvm_domain(d) || is_idle_domain(d) =
)=0A         return 0;=0A@@ -256,48 +253,23 @@ int mapcache_domain_init(str=
uct domain *=0A         return 0;=0A #endif=0A =0A-    dcache->l1tab =3D =
xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES + 1);=0A-    d->arch.perd=
omain_l2_pg[MAPCACHE_SLOT] =3D alloc_domheap_page(NULL, memf);=0A-    if ( =
!dcache->l1tab || !d->arch.perdomain_l2_pg[MAPCACHE_SLOT] )=0A+    =
dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);=0A+  =
  if ( !dcache->l1tab )=0A         return -ENOMEM;=0A =0A-    clear_domain_=
page(page_to_mfn(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]));=0A-    l3tab =
=3D __map_domain_page(d->arch.perdomain_l3_pg);=0A-    l3tab[l3_table_offse=
t(MAPCACHE_VIRT_START)] =3D=0A-        l3e_from_page(d->arch.perdomain_l2_p=
g[MAPCACHE_SLOT],=0A-                      __PAGE_HYPERVISOR);=0A-    =
unmap_domain_page(l3tab);=0A-=0A-    l2tab =3D __map_domain_page(d->arch.pe=
rdomain_l2_pg[MAPCACHE_SLOT]);=0A-=0A-    BUILD_BUG_ON(MAPCACHE_VIRT_END + =
3 +=0A-                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * =
sizeof(long)) >=0A+    BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 =
+=0A+                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * =
sizeof(long))) >=0A                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_=
MBYTES << 20));=0A     bitmap_pages =3D PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRI=
ES) * sizeof(long));=0A     dcache->inuse =3D (void *)MAPCACHE_VIRT_END + =
PAGE_SIZE;=0A     dcache->garbage =3D dcache->inuse +=0A                   =
    (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);=0A-    end =3D =
dcache->garbage + bitmap_pages * PAGE_SIZE / sizeof(long);=0A-=0A-    for =
( i =3D l2_table_offset((unsigned long)dcache->inuse);=0A-          i <=3D =
l2_table_offset((unsigned long)(end - 1)); ++i )=0A-    {=0A-        =
ASSERT(i <=3D MAPCACHE_L2_ENTRIES);=0A-        dcache->l1tab[i] =3D =
alloc_xenheap_pages(0, memf);=0A-        if ( !dcache->l1tab[i] )=0A-      =
  {=0A-            unmap_domain_page(l2tab);=0A-            return =
-ENOMEM;=0A-        }=0A-        clear_page(dcache->l1tab[i]);=0A-        =
l2tab[i] =3D l2e_from_paddr(__pa(dcache->l1tab[i]), __PAGE_HYPERVISOR);=0A-=
    }=0A-=0A-    unmap_domain_page(l2tab);=0A =0A     spin_lock_init(&dcach=
e->lock);=0A =0A-    return 0;=0A+    return create_perdomain_mapping(d, =
(unsigned long)dcache->inuse,=0A+                                    2 * =
bitmap_pages + 1,=0A+                                    NIL(l1_pgentry_t =
*), NULL);=0A }=0A =0A void mapcache_domain_exit(struct domain *d)=0A@@ =
-307,94 +279,41 @@ void mapcache_domain_exit(struct domain =0A     if ( =
is_hvm_domain(d) )=0A         return;=0A =0A-    if ( dcache->l1tab )=0A-  =
  {=0A-        unsigned long i;=0A-=0A-        for ( i =3D (unsigned =
long)dcache->inuse; ; i +=3D PAGE_SIZE )=0A-        {=0A-            =
l1_pgentry_t *pl1e;=0A-=0A-            if ( l2_table_offset(i) > MAPCACHE_L=
2_ENTRIES ||=0A-                 !dcache->l1tab[l2_table_offset(i)] )=0A-  =
              break;=0A-=0A-            pl1e =3D &dcache->l1tab[l2_table_of=
fset(i)][l1_table_offset(i)];=0A-            if ( l1e_get_flags(*pl1e) =
)=0A-                free_domheap_page(l1e_get_page(*pl1e));=0A-        =
}=0A-=0A-        for ( i =3D 0; i < MAPCACHE_L2_ENTRIES + 1; ++i )=0A-     =
       free_xenheap_page(dcache->l1tab[i]);=0A-=0A-        xfree(dcache->l1=
tab);=0A-    }=0A+    xfree(dcache->l1tab);=0A }=0A =0A int mapcache_vcpu_i=
nit(struct vcpu *v)=0A {=0A     struct domain *d =3D v->domain;=0A     =
struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;=0A-    =
l2_pgentry_t *l2tab;=0A     unsigned long i;=0A-    unsigned int memf =3D =
MEMF_node(vcpu_to_node(v));=0A+    unsigned int ents =3D d->max_vcpus * =
MAPCACHE_VCPU_ENTRIES;=0A+    unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents=
) * sizeof(long));=0A =0A     if ( is_hvm_vcpu(v) || !dcache->l1tab )=0A   =
      return 0;=0A =0A-    l2tab =3D __map_domain_page(d->arch.perdomain_l2=
_pg[MAPCACHE_SLOT]);=0A-=0A-    while ( dcache->entries < d->max_vcpus * =
MAPCACHE_VCPU_ENTRIES )=0A+    if ( ents > dcache->entries )=0A     {=0A-  =
      unsigned int ents =3D dcache->entries + MAPCACHE_VCPU_ENTRIES;=0A-   =
     l1_pgentry_t *pl1e;=0A-=0A         /* Populate page tables. */=0A-    =
    if ( !dcache->l1tab[i =3D mapcache_l2_entry(ents - 1)] )=0A-        =
{=0A-            dcache->l1tab[i] =3D alloc_xenheap_pages(0, memf);=0A-    =
        if ( !dcache->l1tab[i] )=0A-            {=0A-                =
unmap_domain_page(l2tab);=0A-                return -ENOMEM;=0A-           =
 }=0A-            clear_page(dcache->l1tab[i]);=0A-            l2tab[i] =
=3D l2e_from_paddr(__pa(dcache->l1tab[i]),=0A-                             =
         __PAGE_HYPERVISOR);=0A-        }=0A+        int rc =3D create_perd=
omain_mapping(d, MAPCACHE_VIRT_START,=0A+                                  =
        d->max_vcpus * MAPCACHE_VCPU_ENTRIES,=0A+                          =
                dcache->l1tab, NULL);=0A =0A         /* Populate bit maps. =
*/=0A-        i =3D (unsigned long)(dcache->inuse + BITS_TO_LONGS(ents));=
=0A-        pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)]=
;=0A-        if ( !l1e_get_flags(*pl1e) )=0A-        {=0A-            =
struct page_info *pg =3D alloc_domheap_page(NULL, memf);=0A+        if ( =
!rc )=0A+            rc =3D create_perdomain_mapping(d, (unsigned =
long)dcache->inuse,=0A+                                          nr, NULL, =
NIL(struct page_info *));=0A+        if ( !rc )=0A+            rc =3D =
create_perdomain_mapping(d, (unsigned long)dcache->garbage,=0A+            =
                              nr, NULL, NIL(struct page_info *));=0A =0A-  =
          if ( pg )=0A-            {=0A-                clear_domain_page(p=
age_to_mfn(pg));=0A-                *pl1e =3D l1e_from_page(pg, __PAGE_HYPE=
RVISOR);=0A-                pg =3D alloc_domheap_page(NULL, memf);=0A-     =
       }=0A-            if ( !pg )=0A-            {=0A-                =
unmap_domain_page(l2tab);=0A-                return -ENOMEM;=0A-           =
 }=0A-=0A-            i =3D (unsigned long)(dcache->garbage + BITS_TO_LONGS=
(ents));=0A-            pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_tabl=
e_offset(i)];=0A-            ASSERT(!l1e_get_flags(*pl1e));=0A-=0A-        =
    clear_domain_page(page_to_mfn(pg));=0A-            *pl1e =3D l1e_from_p=
age(pg, __PAGE_HYPERVISOR);=0A-        }=0A+        if ( rc )=0A+          =
  return rc;=0A =0A         dcache->entries =3D ents;=0A     }=0A =0A-    =
unmap_domain_page(l2tab);=0A-=0A     /* Mark all maphash entries as not in =
use. */=0A     BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES);=0A    =
 for ( i =3D 0; i < MAPHASH_ENTRIES; i++ )=0A--- a/xen/arch/x86/mm.c=0A+++ =
b/xen/arch/x86/mm.c=0A@@ -511,6 +511,7 @@ void update_cr3(struct vcpu =
*v)=0A =0A static void invalidate_shadow_ldt(struct vcpu *v, int flush)=0A =
{=0A+    l1_pgentry_t *pl1e;=0A     int i;=0A     unsigned long pfn;=0A    =
 struct page_info *page;=0A@@ -523,12 +524,13 @@ static void invalidate_sha=
dow_ldt(struct=0A         goto out;=0A =0A     v->arch.pv_vcpu.shadow_ldt_m=
apcnt =3D 0;=0A+    pl1e =3D gdt_ldt_ptes(v->domain, v);=0A =0A     for ( =
i =3D 16; i < 32; i++ )=0A     {=0A-        pfn =3D l1e_get_pfn(v->arch.per=
domain_ptes[i]);=0A+        pfn =3D l1e_get_pfn(pl1e[i]);=0A         if ( =
pfn =3D=3D 0 ) continue;=0A-        l1e_write(&v->arch.perdomain_ptes[i], =
l1e_empty());=0A+        l1e_write(&pl1e[i], l1e_empty());=0A         page =
=3D mfn_to_page(pfn);=0A         ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_pag=
e);=0A         ASSERT_PAGE_IS_DOMAIN(page, v->domain);=0A@@ -596,7 +598,7 =
@@ int map_ldt_shadow_page(unsigned int off=0A     nl1e =3D l1e_from_pfn(pa=
ge_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);=0A =0A     spin_lock(&v->a=
rch.pv_vcpu.shadow_ldt_lock);=0A-    l1e_write(&v->arch.perdomain_ptes[off =
+ 16], nl1e);=0A+    l1e_write(&gdt_ldt_ptes(d, v)[off + 16], nl1e);=0A    =
 v->arch.pv_vcpu.shadow_ldt_mapcnt++;=0A     spin_unlock(&v->arch.pv_vcpu.s=
hadow_ldt_lock);=0A =0A@@ -4073,15 +4075,17 @@ long do_update_va_mapping_ot=
herdomain(un=0A =0A void destroy_gdt(struct vcpu *v)=0A {=0A+    l1_pgentry=
_t *pl1e;=0A     int i;=0A     unsigned long pfn;=0A =0A     v->arch.pv_vcp=
u.gdt_ents =3D 0;=0A+    pl1e =3D gdt_ldt_ptes(v->domain, v);=0A     for ( =
i =3D 0; i < FIRST_RESERVED_GDT_PAGE; i++ )=0A     {=0A-        if ( (pfn =
=3D l1e_get_pfn(v->arch.perdomain_ptes[i])) !=3D 0 )=0A+        if ( (pfn =
=3D l1e_get_pfn(pl1e[i])) !=3D 0 )=0A             put_page_and_type(mfn_to_=
page(pfn));=0A-        l1e_write(&v->arch.perdomain_ptes[i], l1e_empty());=
=0A+        l1e_write(&pl1e[i], l1e_empty());=0A         v->arch.pv_vcpu.gd=
t_frames[i] =3D 0;=0A     }=0A }=0A@@ -4092,6 +4096,7 @@ long set_gdt(struc=
t vcpu *v, =0A              unsigned int entries)=0A {=0A     struct =
domain *d =3D v->domain;=0A+    l1_pgentry_t *pl1e;=0A     /* NB. There =
are 512 8-byte entries per GDT page. */=0A     int i, nr_pages =3D =
(entries + 511) / 512;=0A     unsigned long mfn, *pfns;=0A@@ -4124,11 =
+4129,11 @@ long set_gdt(struct vcpu *v, =0A =0A     /* Install the new =
GDT. */=0A     v->arch.pv_vcpu.gdt_ents =3D entries;=0A+    pl1e =3D =
gdt_ldt_ptes(d, v);=0A     for ( i =3D 0; i < nr_pages; i++ )=0A     {=0A  =
       v->arch.pv_vcpu.gdt_frames[i] =3D frames[i];=0A-        l1e_write(&v=
->arch.perdomain_ptes[i],=0A-                  l1e_from_pfn(frames[i], =
__PAGE_HYPERVISOR));=0A+        l1e_write(&pl1e[i], l1e_from_pfn(frames[i],=
 __PAGE_HYPERVISOR));=0A     }=0A =0A     xfree(pfns);=0A@@ -5528,6 =
+5533,175 @@ void __iomem *ioremap(paddr_t pa, size_t=0A     return (void =
__force __iomem *)va;=0A }=0A =0A+int create_perdomain_mapping(struct =
domain *d, unsigned long va,=0A+                             unsigned int =
nr, l1_pgentry_t **pl1tab,=0A+                             struct =
page_info **ppg)=0A+{=0A+    struct page_info *pg;=0A+    l3_pgentry_t =
*l3tab;=0A+    l2_pgentry_t *l2tab;=0A+    l1_pgentry_t *l1tab;=0A+    =
unsigned int memf =3D MEMF_node(domain_to_node(d));=0A+    int rc =3D =
0;=0A+=0A+    ASSERT(va >=3D PERDOMAIN_VIRT_START &&=0A+           va < =
PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));=0A+=0A+    if ( !d->arch.perdomain_l=
3_pg )=0A+    {=0A+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain=
_to_node(d)));=0A+        if ( !pg )=0A+            return -ENOMEM;=0A+    =
    l3tab =3D __map_domain_page(pg);=0A+        clear_page(l3tab);=0A+     =
   d->arch.perdomain_l3_pg =3D pg;=0A+        if ( !nr )=0A+        {=0A+  =
          unmap_domain_page(l3tab);=0A+            return 0;=0A+        =
}=0A+    }=0A+    else if ( !nr )=0A+        return 0;=0A+    else=0A+     =
   l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);=0A+=0A+    =
ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));=0A+=0A+    if ( =
!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT) )=0A+    =
{=0A+        pg =3D alloc_domheap_page(NULL, memf);=0A+        if ( !pg =
)=0A+        {=0A+            unmap_domain_page(l3tab);=0A+            =
return -ENOMEM;=0A+        }=0A+        l2tab =3D __map_domain_page(pg);=0A=
+        clear_page(l2tab);=0A+        l3tab[l3_table_offset(va)] =3D =
l3e_from_page(pg, __PAGE_HYPERVISOR);=0A+    }=0A+    else=0A+        =
l2tab =3D map_domain_page(l3e_get_pfn(l3tab[l3_table_offset(va)]));=0A+=0A+=
    unmap_domain_page(l3tab);=0A+=0A+    if ( !pl1tab && !ppg )=0A+    =
{=0A+        unmap_domain_page(l2tab);=0A+        return 0;=0A+    =
}=0A+=0A+    for ( l1tab =3D NULL; !rc && nr--; )=0A+    {=0A+        =
l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);=0A+=0A+        if ( =
!(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )=0A+        {=0A+            if ( =
pl1tab && !IS_NIL(pl1tab) )=0A+            {=0A+                l1tab =3D =
alloc_xenheap_pages(0, memf);=0A+                if ( !l1tab )=0A+         =
       {=0A+                    rc =3D -ENOMEM;=0A+                    =
break;=0A+                }=0A+                ASSERT(!pl1tab[l2_table_offs=
et(va)]);=0A+                pl1tab[l2_table_offset(va)] =3D l1tab;=0A+    =
            pg =3D virt_to_page(l1tab);=0A+            }=0A+            =
else=0A+            {=0A+                pg =3D alloc_domheap_page(NULL, =
memf);=0A+                if ( !pg )=0A+                {=0A+              =
      rc =3D -ENOMEM;=0A+                    break;=0A+                =
}=0A+                l1tab =3D __map_domain_page(pg);=0A+            }=0A+ =
           clear_page(l1tab);=0A+            *pl2e =3D l2e_from_page(pg, =
__PAGE_HYPERVISOR);=0A+        }=0A+        else if ( !l1tab )=0A+         =
   l1tab =3D map_domain_page(l2e_get_pfn(*pl2e));=0A+=0A+        if ( ppg =
&&=0A+             !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRES=
ENT) )=0A+        {=0A+            pg =3D alloc_domheap_page(NULL, =
memf);=0A+            if ( pg )=0A+            {=0A+                =
clear_domain_page(page_to_mfn(pg));=0A+                if ( !IS_NIL(ppg) =
)=0A+                    *ppg++ =3D pg;=0A+                l1tab[l1_table_o=
ffset(va)] =3D=0A+                    l1e_from_page(pg, __PAGE_HYPERVISOR =
| _PAGE_AVAIL0);=0A+                l2e_add_flags(*pl2e, _PAGE_AVAIL0);=0A+=
            }=0A+            else=0A+                rc =3D -ENOMEM;=0A+   =
     }=0A+=0A+        va +=3D PAGE_SIZE;=0A+        if ( rc || !nr || =
!l1_table_offset(va) )=0A+        {=0A+            /* Note that this is a =
no-op for the alloc_xenheap_page() case. */=0A+            unmap_domain_pag=
e(l1tab);=0A+            l1tab =3D NULL;=0A+        }=0A+    }=0A+=0A+    =
ASSERT(!l1tab);=0A+    unmap_domain_page(l2tab);=0A+=0A+    return =
rc;=0A+}=0A+=0A+void free_perdomain_mappings(struct domain *d)=0A+{=0A+    =
l3_pgentry_t *l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);=0A+    =
unsigned int i;=0A+=0A+    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)=0A+    =
    if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )=0A+        {=0A+        =
    struct page_info *l2pg =3D l3e_get_page(l3tab[i]);=0A+            =
l2_pgentry_t *l2tab =3D __map_domain_page(l2pg);=0A+            unsigned =
int j;=0A+=0A+            for ( j =3D 0; j < L2_PAGETABLE_ENTRIES; ++j =
)=0A+                if ( l2e_get_flags(l2tab[j]) & _PAGE_PRESENT )=0A+    =
            {=0A+                    struct page_info *l1pg =3D l2e_get_pag=
e(l2tab[j]);=0A+=0A+                    if ( l2e_get_flags(l2tab[j]) & =
_PAGE_AVAIL0 )=0A+                    {=0A+                        =
l1_pgentry_t *l1tab =3D __map_domain_page(l1pg);=0A+                       =
 unsigned int k;=0A+=0A+                        for ( k =3D 0; k < =
L1_PAGETABLE_ENTRIES; ++k )=0A+                            if ( (l1e_get_fl=
ags(l1tab[k]) &=0A+                                  (_PAGE_PRESENT | =
_PAGE_AVAIL0)) =3D=3D=0A+                                 (_PAGE_PRESENT | =
_PAGE_AVAIL0) )=0A+                                free_domheap_page(l1e_ge=
t_page(l1tab[k]));=0A+=0A+                        unmap_domain_page(l1tab);=
=0A+                    }=0A+=0A+                    if ( is_xen_heap_page(=
l1pg) )=0A+                        free_xenheap_page(page_to_virt(l1pg));=
=0A+                    else=0A+                        free_domheap_page(l=
1pg);=0A+                }=0A+=0A+            unmap_domain_page(l2tab);=0A+=
            free_domheap_page(l2pg);=0A+        }=0A+=0A+    unmap_domain_p=
age(l3tab);=0A+    free_domheap_page(d->arch.perdomain_l3_pg);=0A+}=0A+=0A =
#ifdef MEMORY_GUARD=0A =0A void memguard_init(void)=0A--- a/xen/include/asm=
-x86/config.h=0A+++ b/xen/include/asm-x86/config.h=0A@@ -304,19 +304,13 @@ =
extern unsigned long xen_phys_start;=0A #define LDT_VIRT_START(v)    \=0A  =
   (GDT_VIRT_START(v) + (64*1024))=0A =0A-/* map_domain_page() map cache. =
The last per-domain-mapping sub-area. */=0A+/* map_domain_page() map =
cache. The second per-domain-mapping sub-area. */=0A #define MAPCACHE_VCPU_=
ENTRIES    (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS)=0A #define =
MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)=0A-#define=
 MAPCACHE_SLOT            (PERDOMAIN_SLOTS - 1)=0A-#define MAPCACHE_VIRT_ST=
ART      PERDOMAIN_VIRT_SLOT(MAPCACHE_SLOT)=0A+#define MAPCACHE_VIRT_START =
     PERDOMAIN_VIRT_SLOT(1)=0A #define MAPCACHE_VIRT_END        (MAPCACHE_V=
IRT_START + \=0A                                   MAPCACHE_ENTRIES * =
PAGE_SIZE)=0A =0A-#define PDPT_L1_ENTRIES       \=0A-    ((PERDOMAIN_VIRT_S=
LOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> PAGE_SHIFT)=0A-#define =
PDPT_L2_ENTRIES       \=0A-    ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) =
- 1) >> PAGETABLE_ORDER)=0A-=0A #define ELFSIZE 64=0A =0A #define =
ARCH_CRASH_SAVE_VMCOREINFO=0A--- a/xen/include/asm-x86/domain.h=0A+++ =
b/xen/include/asm-x86/domain.h=0A@@ -223,6 +223,8 @@ struct time_scale =
{=0A =0A struct pv_domain=0A {=0A+    l1_pgentry_t **gdt_ldt_l1tab;=0A+=0A =
    /* Shared page for notifying that explicit PIRQ EOI is required. */=0A =
    unsigned long *pirq_eoi_map;=0A     unsigned long pirq_eoi_map_mfn;=0A@=
@ -241,8 +243,6 @@ struct pv_domain=0A =0A struct arch_domain=0A {=0A-    =
void **perdomain_pts;=0A-    struct page_info *perdomain_l2_pg[PERDOMAIN_SL=
OTS];=0A     struct page_info *perdomain_l3_pg;=0A =0A     unsigned int =
hv_compat_vstart;=0A@@ -318,10 +318,10 @@ struct arch_domain=0A #define =
has_arch_pdevs(d)    (!list_empty(&(d)->arch.pdev_list))=0A #define =
has_arch_mmios(d)    (!rangeset_is_empty((d)->iomem_caps))=0A =0A-#define =
perdomain_pt_idx(v) \=0A+#define gdt_ldt_pt_idx(v) \=0A       ((v)->vcpu_id=
 >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))=0A-#define perdomain_ptes(d, =
v) \=0A-    ((l1_pgentry_t *)(d)->arch.perdomain_pts[perdomain_pt_idx(v)] =
+ \=0A+#define gdt_ldt_ptes(d, v) \=0A+    ((d)->arch.pv_domain.gdt_ldt_l1t=
ab[gdt_ldt_pt_idx(v)] + \=0A      (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & =
(L1_PAGETABLE_ENTRIES - 1)))=0A =0A struct pv_vcpu=0A@@ -406,12 +406,6 @@ =
struct arch_vcpu=0A         struct hvm_vcpu hvm_vcpu;=0A     };=0A =0A-    =
/*=0A-     * Every domain has a L1 pagetable of its own. Per-domain =
mappings=0A-     * are put in this table (eg. the current GDT is mapped =
here).=0A-     */=0A-    l1_pgentry_t *perdomain_ptes;=0A-=0A     =
pagetable_t guest_table_user;       /* (MFN) x86/64 user-space pagetable =
*/=0A     pagetable_t guest_table;            /* (MFN) guest notion of cr3 =
*/=0A     /* guest_table holds a ref to the page, and also a type-count =
unless=0A--- a/xen/include/asm-x86/mm.h=0A+++ b/xen/include/asm-x86/mm.h=0A=
@@ -573,6 +573,14 @@ int donate_page(=0A =0A int map_ldt_shadow_page(unsign=
ed int);=0A =0A+#define NIL(type) ((type *)NULL - 1)=0A+#define IS_NIL(ptr)=
 (!((ptr) + 1))=0A+=0A+int create_perdomain_mapping(struct domain *, =
unsigned long va,=0A+                             unsigned int nr, =
l1_pgentry_t **,=0A+                             struct page_info =
**);=0A+void free_perdomain_mappings(struct domain *);=0A+=0A extern int =
memory_add(unsigned long spfn, unsigned long epfn, unsigned int pxm);=0A =
=0A void domain_set_alloc_bitsize(struct domain *d);=0A
--=__PartAB9BDB63.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

--=__PartAB9BDB63.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 16:07:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN3V-0007m2-Cj; Tue, 26 Feb 2013 16:07:01 +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 1UAN3T-0007lh-Ro
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:07:00 +0000
Received: from [85.158.139.211:3057] by server-11.bemta-5.messagelabs.com id
	C4/52-27486-3ADDC215; Tue, 26 Feb 2013 16:06:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361894817!19421073!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26687 invoked from network); 26 Feb 2013 16:06:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:06:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:06:12 +0000
Message-Id: <512CEB8302000078000C1276@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:06:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512CE92B02000078000C1256@nat28.tlf.novell.com>
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAB9BDB63.0__="
Subject: [Xen-devel] [PATCH v2 1/3] x86: introduce create_perdomain_mapping()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartAB9BDB63.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... as well as free_perdomain_mappings(), and use them to carry out the
existing per-domain mapping setup/teardown. This at once makes the
setup of the first sub-range PV domain specific (with idle domains also
excluded), as the GDT/LDT mapping area is needed only for those.

Also fix an improperly scaled BUILD_BUG_ON() expression in
mapcache_domain_init().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -372,37 +372,16 @@ int switch_compat(struct domain *d)
 int vcpu_initialise(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
-    unsigned int idx;
     int rc;
=20
     v->arch.flags =3D TF_kernel_mode;
=20
-    idx =3D perdomain_pt_idx(v);
-    if ( !d->arch.perdomain_pts[idx] )
-    {
-        void *pt;
-        l2_pgentry_t *l2tab;
-
-        pt =3D alloc_xenheap_pages(0, MEMF_node(vcpu_to_node(v)));
-        if ( !pt )
-            return -ENOMEM;
-        clear_page(pt);
-        d->arch.perdomain_pts[idx] =3D pt;
-
-        l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[0]);
-        l2tab[l2_table_offset(PERDOMAIN_VIRT_START) + idx]
-            =3D l2e_from_paddr(__pa(pt), __PAGE_HYPERVISOR);
-        unmap_domain_page(l2tab);
-    }
-
     rc =3D mapcache_vcpu_init(v);
     if ( rc )
         return rc;
=20
     paging_vcpu_init(v);
=20
-    v->arch.perdomain_ptes =3D perdomain_ptes(d, v);
-
     if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )
         return rc;
=20
@@ -420,6 +399,12 @@ int vcpu_initialise(struct vcpu *v)
=20
     if ( !is_idle_domain(d) )
     {
+        rc =3D create_perdomain_mapping(d, GDT_VIRT_START(v),
+                                      1 << GDT_LDT_VCPU_SHIFT,
+                                      d->arch.pv_domain.gdt_ldt_l1tab, =
NULL);
+        if ( rc )
+            goto done;
+
         BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
                      PAGE_SIZE);
         v->arch.pv_vcpu.trap_ctxt =3D xzalloc_array(struct trap_info,
@@ -478,8 +463,6 @@ void vcpu_destroy(struct vcpu *v)
=20
 int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 {
-    struct page_info *pg;
-    l3_pgentry_t *l3tab;
     int i, paging_initialised =3D 0;
     int rc =3D -ENOMEM;
=20
@@ -510,29 +493,24 @@ int arch_domain_create(struct domain *d,
                d->domain_id);
     }
=20
-    BUILD_BUG_ON(PDPT_L2_ENTRIES * sizeof(*d->arch.perdomain_pts)
-                 !=3D PAGE_SIZE);
-    d->arch.perdomain_pts =3D
-        alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-    if ( !d->arch.perdomain_pts )
-        goto fail;
-    clear_page(d->arch.perdomain_pts);
-
-    pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
-    if ( pg =3D=3D NULL )
-        goto fail;
-    d->arch.perdomain_l2_pg[0] =3D pg;
-    clear_domain_page(page_to_mfn(pg));
+    if ( is_hvm_domain(d) )
+        rc =3D create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, =
NULL);
+    else if ( is_idle_domain(d) )
+        rc =3D 0;
+    else
+    {
+        d->arch.pv_domain.gdt_ldt_l1tab =3D
+            alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
+        if ( !d->arch.pv_domain.gdt_ldt_l1tab )
+            goto fail;
+        clear_page(d->arch.pv_domain.gdt_ldt_l1tab);
=20
-    pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
-    if ( pg =3D=3D NULL )
+        rc =3D create_perdomain_mapping(d, GDT_LDT_VIRT_START,
+                                      GDT_LDT_MBYTES << (20 - PAGE_SHIFT),=

+                                      NULL, NULL);
+    }
+    if ( rc )
         goto fail;
-    d->arch.perdomain_l3_pg =3D pg;
-    l3tab =3D __map_domain_page(pg);
-    clear_page(l3tab);
-    l3tab[l3_table_offset(PERDOMAIN_VIRT_START)] =3D
-        l3e_from_page(d->arch.perdomain_l2_pg[0], __PAGE_HYPERVISOR);
-    unmap_domain_page(l3tab);
=20
     mapcache_domain_init(d);
=20
@@ -608,19 +586,14 @@ int arch_domain_create(struct domain *d,
     if ( paging_initialised )
         paging_final_teardown(d);
     mapcache_domain_exit(d);
-    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)
-        if ( d->arch.perdomain_l2_pg[i] )
-            free_domheap_page(d->arch.perdomain_l2_pg[i]);
-    if ( d->arch.perdomain_l3_pg )
-        free_domheap_page(d->arch.perdomain_l3_pg);
-    free_xenheap_page(d->arch.perdomain_pts);
+    free_perdomain_mappings(d);
+    if ( !is_hvm_domain(d) )
+        free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
     return rc;
 }
=20
 void arch_domain_destroy(struct domain *d)
 {
-    unsigned int i;
-
     if ( is_hvm_domain(d) )
         hvm_domain_destroy(d);
     else
@@ -634,13 +607,9 @@ void arch_domain_destroy(struct domain *
=20
     mapcache_domain_exit(d);
=20
-    for ( i =3D 0; i < PDPT_L2_ENTRIES; ++i )
-        free_xenheap_page(d->arch.perdomain_pts[i]);
-    free_xenheap_page(d->arch.perdomain_pts);
-    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)
-        if ( d->arch.perdomain_l2_pg[i] )
-            free_domheap_page(d->arch.perdomain_l2_pg[i]);
-    free_domheap_page(d->arch.perdomain_l3_pg);
+    free_perdomain_mappings(d);
+    if ( !is_hvm_domain(d) )
+        free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
=20
     free_xenheap_page(d->shared_info);
     cleanup_domain_irq_mapping(d);
@@ -1515,10 +1484,11 @@ static void __context_switch(void)
     if ( need_full_gdt(n) )
     {
         unsigned long mfn =3D virt_to_mfn(gdt);
+        l1_pgentry_t *pl1e =3D gdt_ldt_ptes(n->domain, n);
         unsigned int i;
+
         for ( i =3D 0; i < NR_RESERVED_GDT_PAGES; i++ )
-            l1e_write(n->arch.perdomain_ptes +
-                      FIRST_RESERVED_GDT_PAGE + i,
+            l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,
                       l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR));
     }
=20
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -243,10 +243,7 @@ void copy_domain_page(unsigned long dmfn
 int mapcache_domain_init(struct domain *d)
 {
     struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;
-    l3_pgentry_t *l3tab;
-    l2_pgentry_t *l2tab;
-    unsigned int i, bitmap_pages, memf =3D MEMF_node(domain_to_node(d));
-    unsigned long *end;
+    unsigned int bitmap_pages;
=20
     if ( is_hvm_domain(d) || is_idle_domain(d) )
         return 0;
@@ -256,48 +253,23 @@ int mapcache_domain_init(struct domain *
         return 0;
 #endif
=20
-    dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES + =
1);
-    d->arch.perdomain_l2_pg[MAPCACHE_SLOT] =3D alloc_domheap_page(NULL, =
memf);
-    if ( !dcache->l1tab || !d->arch.perdomain_l2_pg[MAPCACHE_SLOT] )
+    dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);
+    if ( !dcache->l1tab )
         return -ENOMEM;
=20
-    clear_domain_page(page_to_mfn(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]))=
;
-    l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
-    l3tab[l3_table_offset(MAPCACHE_VIRT_START)] =3D
-        l3e_from_page(d->arch.perdomain_l2_pg[MAPCACHE_SLOT],
-                      __PAGE_HYPERVISOR);
-    unmap_domain_page(l3tab);
-
-    l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]);
-
-    BUILD_BUG_ON(MAPCACHE_VIRT_END + 3 +
-                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
) >
+    BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
+                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
)) >
                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20));
     bitmap_pages =3D PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
);
     dcache->inuse =3D (void *)MAPCACHE_VIRT_END + PAGE_SIZE;
     dcache->garbage =3D dcache->inuse +
                       (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);
-    end =3D dcache->garbage + bitmap_pages * PAGE_SIZE / sizeof(long);
-
-    for ( i =3D l2_table_offset((unsigned long)dcache->inuse);
-          i <=3D l2_table_offset((unsigned long)(end - 1)); ++i )
-    {
-        ASSERT(i <=3D MAPCACHE_L2_ENTRIES);
-        dcache->l1tab[i] =3D alloc_xenheap_pages(0, memf);
-        if ( !dcache->l1tab[i] )
-        {
-            unmap_domain_page(l2tab);
-            return -ENOMEM;
-        }
-        clear_page(dcache->l1tab[i]);
-        l2tab[i] =3D l2e_from_paddr(__pa(dcache->l1tab[i]), __PAGE_HYPERVI=
SOR);
-    }
-
-    unmap_domain_page(l2tab);
=20
     spin_lock_init(&dcache->lock);
=20
-    return 0;
+    return create_perdomain_mapping(d, (unsigned long)dcache->inuse,
+                                    2 * bitmap_pages + 1,
+                                    NIL(l1_pgentry_t *), NULL);
 }
=20
 void mapcache_domain_exit(struct domain *d)
@@ -307,94 +279,41 @@ void mapcache_domain_exit(struct domain=20
     if ( is_hvm_domain(d) )
         return;
=20
-    if ( dcache->l1tab )
-    {
-        unsigned long i;
-
-        for ( i =3D (unsigned long)dcache->inuse; ; i +=3D PAGE_SIZE )
-        {
-            l1_pgentry_t *pl1e;
-
-            if ( l2_table_offset(i) > MAPCACHE_L2_ENTRIES ||
-                 !dcache->l1tab[l2_table_offset(i)] )
-                break;
-
-            pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)=
];
-            if ( l1e_get_flags(*pl1e) )
-                free_domheap_page(l1e_get_page(*pl1e));
-        }
-
-        for ( i =3D 0; i < MAPCACHE_L2_ENTRIES + 1; ++i )
-            free_xenheap_page(dcache->l1tab[i]);
-
-        xfree(dcache->l1tab);
-    }
+    xfree(dcache->l1tab);
 }
=20
 int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
     struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;
-    l2_pgentry_t *l2tab;
     unsigned long i;
-    unsigned int memf =3D MEMF_node(vcpu_to_node(v));
+    unsigned int ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
+    unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
=20
     if ( is_hvm_vcpu(v) || !dcache->l1tab )
         return 0;
=20
-    l2tab =3D __map_domain_page(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]);
-
-    while ( dcache->entries < d->max_vcpus * MAPCACHE_VCPU_ENTRIES )
+    if ( ents > dcache->entries )
     {
-        unsigned int ents =3D dcache->entries + MAPCACHE_VCPU_ENTRIES;
-        l1_pgentry_t *pl1e;
-
         /* Populate page tables. */
-        if ( !dcache->l1tab[i =3D mapcache_l2_entry(ents - 1)] )
-        {
-            dcache->l1tab[i] =3D alloc_xenheap_pages(0, memf);
-            if ( !dcache->l1tab[i] )
-            {
-                unmap_domain_page(l2tab);
-                return -ENOMEM;
-            }
-            clear_page(dcache->l1tab[i]);
-            l2tab[i] =3D l2e_from_paddr(__pa(dcache->l1tab[i]),
-                                      __PAGE_HYPERVISOR);
-        }
+        int rc =3D create_perdomain_mapping(d, MAPCACHE_VIRT_START,
+                                          d->max_vcpus * MAPCACHE_VCPU_ENT=
RIES,
+                                          dcache->l1tab, NULL);
=20
         /* Populate bit maps. */
-        i =3D (unsigned long)(dcache->inuse + BITS_TO_LONGS(ents));
-        pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)];
-        if ( !l1e_get_flags(*pl1e) )
-        {
-            struct page_info *pg =3D alloc_domheap_page(NULL, memf);
+        if ( !rc )
+            rc =3D create_perdomain_mapping(d, (unsigned long)dcache->inus=
e,
+                                          nr, NULL, NIL(struct page_info =
*));
+        if ( !rc )
+            rc =3D create_perdomain_mapping(d, (unsigned long)dcache->garb=
age,
+                                          nr, NULL, NIL(struct page_info =
*));
=20
-            if ( pg )
-            {
-                clear_domain_page(page_to_mfn(pg));
-                *pl1e =3D l1e_from_page(pg, __PAGE_HYPERVISOR);
-                pg =3D alloc_domheap_page(NULL, memf);
-            }
-            if ( !pg )
-            {
-                unmap_domain_page(l2tab);
-                return -ENOMEM;
-            }
-
-            i =3D (unsigned long)(dcache->garbage + BITS_TO_LONGS(ents));
-            pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)=
];
-            ASSERT(!l1e_get_flags(*pl1e));
-
-            clear_domain_page(page_to_mfn(pg));
-            *pl1e =3D l1e_from_page(pg, __PAGE_HYPERVISOR);
-        }
+        if ( rc )
+            return rc;
=20
         dcache->entries =3D ents;
     }
=20
-    unmap_domain_page(l2tab);
-
     /* Mark all maphash entries as not in use. */
     BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES);
     for ( i =3D 0; i < MAPHASH_ENTRIES; i++ )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -511,6 +511,7 @@ void update_cr3(struct vcpu *v)
=20
 static void invalidate_shadow_ldt(struct vcpu *v, int flush)
 {
+    l1_pgentry_t *pl1e;
     int i;
     unsigned long pfn;
     struct page_info *page;
@@ -523,12 +524,13 @@ static void invalidate_shadow_ldt(struct
         goto out;
=20
     v->arch.pv_vcpu.shadow_ldt_mapcnt =3D 0;
+    pl1e =3D gdt_ldt_ptes(v->domain, v);
=20
     for ( i =3D 16; i < 32; i++ )
     {
-        pfn =3D l1e_get_pfn(v->arch.perdomain_ptes[i]);
+        pfn =3D l1e_get_pfn(pl1e[i]);
         if ( pfn =3D=3D 0 ) continue;
-        l1e_write(&v->arch.perdomain_ptes[i], l1e_empty());
+        l1e_write(&pl1e[i], l1e_empty());
         page =3D mfn_to_page(pfn);
         ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
         ASSERT_PAGE_IS_DOMAIN(page, v->domain);
@@ -596,7 +598,7 @@ int map_ldt_shadow_page(unsigned int off
     nl1e =3D l1e_from_pfn(page_to_mfn(page), l1e_get_flags(l1e) | =
_PAGE_RW);
=20
     spin_lock(&v->arch.pv_vcpu.shadow_ldt_lock);
-    l1e_write(&v->arch.perdomain_ptes[off + 16], nl1e);
+    l1e_write(&gdt_ldt_ptes(d, v)[off + 16], nl1e);
     v->arch.pv_vcpu.shadow_ldt_mapcnt++;
     spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock);
=20
@@ -4073,15 +4075,17 @@ long do_update_va_mapping_otherdomain(un
=20
 void destroy_gdt(struct vcpu *v)
 {
+    l1_pgentry_t *pl1e;
     int i;
     unsigned long pfn;
=20
     v->arch.pv_vcpu.gdt_ents =3D 0;
+    pl1e =3D gdt_ldt_ptes(v->domain, v);
     for ( i =3D 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
     {
-        if ( (pfn =3D l1e_get_pfn(v->arch.perdomain_ptes[i])) !=3D 0 )
+        if ( (pfn =3D l1e_get_pfn(pl1e[i])) !=3D 0 )
             put_page_and_type(mfn_to_page(pfn));
-        l1e_write(&v->arch.perdomain_ptes[i], l1e_empty());
+        l1e_write(&pl1e[i], l1e_empty());
         v->arch.pv_vcpu.gdt_frames[i] =3D 0;
     }
 }
@@ -4092,6 +4096,7 @@ long set_gdt(struct vcpu *v,=20
              unsigned int entries)
 {
     struct domain *d =3D v->domain;
+    l1_pgentry_t *pl1e;
     /* NB. There are 512 8-byte entries per GDT page. */
     int i, nr_pages =3D (entries + 511) / 512;
     unsigned long mfn, *pfns;
@@ -4124,11 +4129,11 @@ long set_gdt(struct vcpu *v,=20
=20
     /* Install the new GDT. */
     v->arch.pv_vcpu.gdt_ents =3D entries;
+    pl1e =3D gdt_ldt_ptes(d, v);
     for ( i =3D 0; i < nr_pages; i++ )
     {
         v->arch.pv_vcpu.gdt_frames[i] =3D frames[i];
-        l1e_write(&v->arch.perdomain_ptes[i],
-                  l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
+        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR));
     }
=20
     xfree(pfns);
@@ -5528,6 +5533,175 @@ void __iomem *ioremap(paddr_t pa, size_t
     return (void __force __iomem *)va;
 }
=20
+int create_perdomain_mapping(struct domain *d, unsigned long va,
+                             unsigned int nr, l1_pgentry_t **pl1tab,
+                             struct page_info **ppg)
+{
+    struct page_info *pg;
+    l3_pgentry_t *l3tab;
+    l2_pgentry_t *l2tab;
+    l1_pgentry_t *l1tab;
+    unsigned int memf =3D MEMF_node(domain_to_node(d));
+    int rc =3D 0;
+
+    ASSERT(va >=3D PERDOMAIN_VIRT_START &&
+           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
+
+    if ( !d->arch.perdomain_l3_pg )
+    {
+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+        if ( !pg )
+            return -ENOMEM;
+        l3tab =3D __map_domain_page(pg);
+        clear_page(l3tab);
+        d->arch.perdomain_l3_pg =3D pg;
+        if ( !nr )
+        {
+            unmap_domain_page(l3tab);
+            return 0;
+        }
+    }
+    else if ( !nr )
+        return 0;
+    else
+        l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+
+    ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
+
+    if ( !(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT) )
+    {
+        pg =3D alloc_domheap_page(NULL, memf);
+        if ( !pg )
+        {
+            unmap_domain_page(l3tab);
+            return -ENOMEM;
+        }
+        l2tab =3D __map_domain_page(pg);
+        clear_page(l2tab);
+        l3tab[l3_table_offset(va)] =3D l3e_from_page(pg, __PAGE_HYPERVISOR=
);
+    }
+    else
+        l2tab =3D map_domain_page(l3e_get_pfn(l3tab[l3_table_offset(va)]))=
;
+
+    unmap_domain_page(l3tab);
+
+    if ( !pl1tab && !ppg )
+    {
+        unmap_domain_page(l2tab);
+        return 0;
+    }
+
+    for ( l1tab =3D NULL; !rc && nr--; )
+    {
+        l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);
+
+        if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
+        {
+            if ( pl1tab && !IS_NIL(pl1tab) )
+            {
+                l1tab =3D alloc_xenheap_pages(0, memf);
+                if ( !l1tab )
+                {
+                    rc =3D -ENOMEM;
+                    break;
+                }
+                ASSERT(!pl1tab[l2_table_offset(va)]);
+                pl1tab[l2_table_offset(va)] =3D l1tab;
+                pg =3D virt_to_page(l1tab);
+            }
+            else
+            {
+                pg =3D alloc_domheap_page(NULL, memf);
+                if ( !pg )
+                {
+                    rc =3D -ENOMEM;
+                    break;
+                }
+                l1tab =3D __map_domain_page(pg);
+            }
+            clear_page(l1tab);
+            *pl2e =3D l2e_from_page(pg, __PAGE_HYPERVISOR);
+        }
+        else if ( !l1tab )
+            l1tab =3D map_domain_page(l2e_get_pfn(*pl2e));
+
+        if ( ppg &&
+             !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) =
)
+        {
+            pg =3D alloc_domheap_page(NULL, memf);
+            if ( pg )
+            {
+                clear_domain_page(page_to_mfn(pg));
+                if ( !IS_NIL(ppg) )
+                    *ppg++ =3D pg;
+                l1tab[l1_table_offset(va)] =3D
+                    l1e_from_page(pg, __PAGE_HYPERVISOR | _PAGE_AVAIL0);
+                l2e_add_flags(*pl2e, _PAGE_AVAIL0);
+            }
+            else
+                rc =3D -ENOMEM;
+        }
+
+        va +=3D PAGE_SIZE;
+        if ( rc || !nr || !l1_table_offset(va) )
+        {
+            /* Note that this is a no-op for the alloc_xenheap_page() =
case. */
+            unmap_domain_page(l1tab);
+            l1tab =3D NULL;
+        }
+    }
+
+    ASSERT(!l1tab);
+    unmap_domain_page(l2tab);
+
+    return rc;
+}
+
+void free_perdomain_mappings(struct domain *d)
+{
+    l3_pgentry_t *l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);
+    unsigned int i;
+
+    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)
+        if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )
+        {
+            struct page_info *l2pg =3D l3e_get_page(l3tab[i]);
+            l2_pgentry_t *l2tab =3D __map_domain_page(l2pg);
+            unsigned int j;
+
+            for ( j =3D 0; j < L2_PAGETABLE_ENTRIES; ++j )
+                if ( l2e_get_flags(l2tab[j]) & _PAGE_PRESENT )
+                {
+                    struct page_info *l1pg =3D l2e_get_page(l2tab[j]);
+
+                    if ( l2e_get_flags(l2tab[j]) & _PAGE_AVAIL0 )
+                    {
+                        l1_pgentry_t *l1tab =3D __map_domain_page(l1pg);
+                        unsigned int k;
+
+                        for ( k =3D 0; k < L1_PAGETABLE_ENTRIES; ++k )
+                            if ( (l1e_get_flags(l1tab[k]) &
+                                  (_PAGE_PRESENT | _PAGE_AVAIL0)) =3D=3D
+                                 (_PAGE_PRESENT | _PAGE_AVAIL0) )
+                                free_domheap_page(l1e_get_page(l1tab[k]));=

+
+                        unmap_domain_page(l1tab);
+                    }
+
+                    if ( is_xen_heap_page(l1pg) )
+                        free_xenheap_page(page_to_virt(l1pg));
+                    else
+                        free_domheap_page(l1pg);
+                }
+
+            unmap_domain_page(l2tab);
+            free_domheap_page(l2pg);
+        }
+
+    unmap_domain_page(l3tab);
+    free_domheap_page(d->arch.perdomain_l3_pg);
+}
+
 #ifdef MEMORY_GUARD
=20
 void memguard_init(void)
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -304,19 +304,13 @@ extern unsigned long xen_phys_start;
 #define LDT_VIRT_START(v)    \
     (GDT_VIRT_START(v) + (64*1024))
=20
-/* map_domain_page() map cache. The last per-domain-mapping sub-area. */
+/* map_domain_page() map cache. The second per-domain-mapping sub-area. =
*/
 #define MAPCACHE_VCPU_ENTRIES    (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEV=
ELS)
 #define MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)
-#define MAPCACHE_SLOT            (PERDOMAIN_SLOTS - 1)
-#define MAPCACHE_VIRT_START      PERDOMAIN_VIRT_SLOT(MAPCACHE_SLOT)
+#define MAPCACHE_VIRT_START      PERDOMAIN_VIRT_SLOT(1)
 #define MAPCACHE_VIRT_END        (MAPCACHE_VIRT_START + \
                                   MAPCACHE_ENTRIES * PAGE_SIZE)
=20
-#define PDPT_L1_ENTRIES       \
-    ((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> =
PAGE_SHIFT)
-#define PDPT_L2_ENTRIES       \
-    ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) - 1) >> PAGETABLE_ORDER)
-
 #define ELFSIZE 64
=20
 #define ARCH_CRASH_SAVE_VMCOREINFO
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -223,6 +223,8 @@ struct time_scale {
=20
 struct pv_domain
 {
+    l1_pgentry_t **gdt_ldt_l1tab;
+
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
@@ -241,8 +243,6 @@ struct pv_domain
=20
 struct arch_domain
 {
-    void **perdomain_pts;
-    struct page_info *perdomain_l2_pg[PERDOMAIN_SLOTS];
     struct page_info *perdomain_l3_pg;
=20
     unsigned int hv_compat_vstart;
@@ -318,10 +318,10 @@ struct arch_domain
 #define has_arch_pdevs(d)    (!list_empty(&(d)->arch.pdev_list))
 #define has_arch_mmios(d)    (!rangeset_is_empty((d)->iomem_caps))
=20
-#define perdomain_pt_idx(v) \
+#define gdt_ldt_pt_idx(v) \
       ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
-#define perdomain_ptes(d, v) \
-    ((l1_pgentry_t *)(d)->arch.perdomain_pts[perdomain_pt_idx(v)] + \
+#define gdt_ldt_ptes(d, v) \
+    ((d)->arch.pv_domain.gdt_ldt_l1tab[gdt_ldt_pt_idx(v)] + \
      (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & (L1_PAGETABLE_ENTRIES - 1)))
=20
 struct pv_vcpu
@@ -406,12 +406,6 @@ struct arch_vcpu
         struct hvm_vcpu hvm_vcpu;
     };
=20
-    /*
-     * Every domain has a L1 pagetable of its own. Per-domain mappings
-     * are put in this table (eg. the current GDT is mapped here).
-     */
-    l1_pgentry_t *perdomain_ptes;
-
     pagetable_t guest_table_user;       /* (MFN) x86/64 user-space =
pagetable */
     pagetable_t guest_table;            /* (MFN) guest notion of cr3 */
     /* guest_table holds a ref to the page, and also a type-count unless
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -573,6 +573,14 @@ int donate_page(
=20
 int map_ldt_shadow_page(unsigned int);
=20
+#define NIL(type) ((type *)NULL - 1)
+#define IS_NIL(ptr) (!((ptr) + 1))
+
+int create_perdomain_mapping(struct domain *, unsigned long va,
+                             unsigned int nr, l1_pgentry_t **,
+                             struct page_info **);
+void free_perdomain_mappings(struct domain *);
+
 extern int memory_add(unsigned long spfn, unsigned long epfn, unsigned =
int pxm);
=20
 void domain_set_alloc_bitsize(struct domain *d);



--=__PartAB9BDB63.0__=
Content-Type: text/plain; name="x86-map-perdomain-page.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-perdomain-page.patch"

x86: introduce create_perdomain_mapping()=0A=0A... as well as free_perdomai=
n_mappings(), and use them to carry out the=0Aexisting per-domain mapping =
setup/teardown. This at once makes the=0Asetup of the first sub-range PV =
domain specific (with idle domains also=0Aexcluded), as the GDT/LDT =
mapping area is needed only for those.=0A=0AAlso fix an improperly scaled =
BUILD_BUG_ON() expression in=0Amapcache_domain_init().=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/domain.c=0A+++ =
b/xen/arch/x86/domain.c=0A@@ -372,37 +372,16 @@ int switch_compat(struct =
domain *d)=0A int vcpu_initialise(struct vcpu *v)=0A {=0A     struct =
domain *d =3D v->domain;=0A-    unsigned int idx;=0A     int rc;=0A =0A    =
 v->arch.flags =3D TF_kernel_mode;=0A =0A-    idx =3D perdomain_pt_idx(v);=
=0A-    if ( !d->arch.perdomain_pts[idx] )=0A-    {=0A-        void =
*pt;=0A-        l2_pgentry_t *l2tab;=0A-=0A-        pt =3D alloc_xenheap_pa=
ges(0, MEMF_node(vcpu_to_node(v)));=0A-        if ( !pt )=0A-            =
return -ENOMEM;=0A-        clear_page(pt);=0A-        d->arch.perdomain_pts=
[idx] =3D pt;=0A-=0A-        l2tab =3D __map_domain_page(d->arch.perdomain_=
l2_pg[0]);=0A-        l2tab[l2_table_offset(PERDOMAIN_VIRT_START) + =
idx]=0A-            =3D l2e_from_paddr(__pa(pt), __PAGE_HYPERVISOR);=0A-   =
     unmap_domain_page(l2tab);=0A-    }=0A-=0A     rc =3D mapcache_vcpu_ini=
t(v);=0A     if ( rc )=0A         return rc;=0A =0A     paging_vcpu_init(v)=
;=0A =0A-    v->arch.perdomain_ptes =3D perdomain_ptes(d, v);=0A-=0A     =
if ( (rc =3D vcpu_init_fpu(v)) !=3D 0 )=0A         return rc;=0A =0A@@ =
-420,6 +399,12 @@ int vcpu_initialise(struct vcpu *v)=0A =0A     if ( =
!is_idle_domain(d) )=0A     {=0A+        rc =3D create_perdomain_mapping(d,=
 GDT_VIRT_START(v),=0A+                                      1 << =
GDT_LDT_VCPU_SHIFT,=0A+                                      d->arch.pv_dom=
ain.gdt_ldt_l1tab, NULL);=0A+        if ( rc )=0A+            goto =
done;=0A+=0A         BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap=
_ctxt) >=0A                      PAGE_SIZE);=0A         v->arch.pv_vcpu.tra=
p_ctxt =3D xzalloc_array(struct trap_info,=0A@@ -478,8 +463,6 @@ void =
vcpu_destroy(struct vcpu *v)=0A =0A int arch_domain_create(struct domain =
*d, unsigned int domcr_flags)=0A {=0A-    struct page_info *pg;=0A-    =
l3_pgentry_t *l3tab;=0A     int i, paging_initialised =3D 0;=0A     int rc =
=3D -ENOMEM;=0A =0A@@ -510,29 +493,24 @@ int arch_domain_create(struct =
domain *d,=0A                d->domain_id);=0A     }=0A =0A-    BUILD_BUG_O=
N(PDPT_L2_ENTRIES * sizeof(*d->arch.perdomain_pts)=0A-                 =
!=3D PAGE_SIZE);=0A-    d->arch.perdomain_pts =3D=0A-        alloc_xenheap_=
pages(0, MEMF_node(domain_to_node(d)));=0A-    if ( !d->arch.perdomain_pts =
)=0A-        goto fail;=0A-    clear_page(d->arch.perdomain_pts);=0A-=0A-  =
  pg =3D alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));=0A-    if =
( pg =3D=3D NULL )=0A-        goto fail;=0A-    d->arch.perdomain_l2_pg[0] =
=3D pg;=0A-    clear_domain_page(page_to_mfn(pg));=0A+    if ( is_hvm_domai=
n(d) )=0A+        rc =3D create_perdomain_mapping(d, PERDOMAIN_VIRT_START, =
0, NULL, NULL);=0A+    else if ( is_idle_domain(d) )=0A+        rc =3D =
0;=0A+    else=0A+    {=0A+        d->arch.pv_domain.gdt_ldt_l1tab =3D=0A+ =
           alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));=0A+       =
 if ( !d->arch.pv_domain.gdt_ldt_l1tab )=0A+            goto fail;=0A+     =
   clear_page(d->arch.pv_domain.gdt_ldt_l1tab);=0A =0A-    pg =3D =
alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));=0A-    if ( pg =
=3D=3D NULL )=0A+        rc =3D create_perdomain_mapping(d, GDT_LDT_VIRT_ST=
ART,=0A+                                      GDT_LDT_MBYTES << (20 - =
PAGE_SHIFT),=0A+                                      NULL, NULL);=0A+    =
}=0A+    if ( rc )=0A         goto fail;=0A-    d->arch.perdomain_l3_pg =
=3D pg;=0A-    l3tab =3D __map_domain_page(pg);=0A-    clear_page(l3tab);=
=0A-    l3tab[l3_table_offset(PERDOMAIN_VIRT_START)] =3D=0A-        =
l3e_from_page(d->arch.perdomain_l2_pg[0], __PAGE_HYPERVISOR);=0A-    =
unmap_domain_page(l3tab);=0A =0A     mapcache_domain_init(d);=0A =0A@@ =
-608,19 +586,14 @@ int arch_domain_create(struct domain *d,=0A     if ( =
paging_initialised )=0A         paging_final_teardown(d);=0A     mapcache_d=
omain_exit(d);=0A-    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)=0A-        =
if ( d->arch.perdomain_l2_pg[i] )=0A-            free_domheap_page(d->arch.=
perdomain_l2_pg[i]);=0A-    if ( d->arch.perdomain_l3_pg )=0A-        =
free_domheap_page(d->arch.perdomain_l3_pg);=0A-    free_xenheap_page(d->arc=
h.perdomain_pts);=0A+    free_perdomain_mappings(d);=0A+    if ( !is_hvm_do=
main(d) )=0A+        free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);=0A=
     return rc;=0A }=0A =0A void arch_domain_destroy(struct domain *d)=0A =
{=0A-    unsigned int i;=0A-=0A     if ( is_hvm_domain(d) )=0A         =
hvm_domain_destroy(d);=0A     else=0A@@ -634,13 +607,9 @@ void arch_domain_=
destroy(struct domain *=0A =0A     mapcache_domain_exit(d);=0A =0A-    for =
( i =3D 0; i < PDPT_L2_ENTRIES; ++i )=0A-        free_xenheap_page(d->arch.=
perdomain_pts[i]);=0A-    free_xenheap_page(d->arch.perdomain_pts);=0A-    =
for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)=0A-        if ( d->arch.perdomain_=
l2_pg[i] )=0A-            free_domheap_page(d->arch.perdomain_l2_pg[i]);=0A=
-    free_domheap_page(d->arch.perdomain_l3_pg);=0A+    free_perdomain_mapp=
ings(d);=0A+    if ( !is_hvm_domain(d) )=0A+        free_xenheap_page(d->ar=
ch.pv_domain.gdt_ldt_l1tab);=0A =0A     free_xenheap_page(d->shared_info);=
=0A     cleanup_domain_irq_mapping(d);=0A@@ -1515,10 +1484,11 @@ static =
void __context_switch(void)=0A     if ( need_full_gdt(n) )=0A     {=0A     =
    unsigned long mfn =3D virt_to_mfn(gdt);=0A+        l1_pgentry_t *pl1e =
=3D gdt_ldt_ptes(n->domain, n);=0A         unsigned int i;=0A+=0A         =
for ( i =3D 0; i < NR_RESERVED_GDT_PAGES; i++ )=0A-            l1e_write(n-=
>arch.perdomain_ptes +=0A-                      FIRST_RESERVED_GDT_PAGE + =
i,=0A+            l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,=0A         =
              l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR));=0A     }=0A =
=0A--- a/xen/arch/x86/domain_page.c=0A+++ b/xen/arch/x86/domain_page.c=0A@@=
 -243,10 +243,7 @@ void copy_domain_page(unsigned long dmfn=0A int =
mapcache_domain_init(struct domain *d)=0A {=0A     struct mapcache_domain =
*dcache =3D &d->arch.pv_domain.mapcache;=0A-    l3_pgentry_t *l3tab;=0A-   =
 l2_pgentry_t *l2tab;=0A-    unsigned int i, bitmap_pages, memf =3D =
MEMF_node(domain_to_node(d));=0A-    unsigned long *end;=0A+    unsigned =
int bitmap_pages;=0A =0A     if ( is_hvm_domain(d) || is_idle_domain(d) =
)=0A         return 0;=0A@@ -256,48 +253,23 @@ int mapcache_domain_init(str=
uct domain *=0A         return 0;=0A #endif=0A =0A-    dcache->l1tab =3D =
xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES + 1);=0A-    d->arch.perd=
omain_l2_pg[MAPCACHE_SLOT] =3D alloc_domheap_page(NULL, memf);=0A-    if ( =
!dcache->l1tab || !d->arch.perdomain_l2_pg[MAPCACHE_SLOT] )=0A+    =
dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);=0A+  =
  if ( !dcache->l1tab )=0A         return -ENOMEM;=0A =0A-    clear_domain_=
page(page_to_mfn(d->arch.perdomain_l2_pg[MAPCACHE_SLOT]));=0A-    l3tab =
=3D __map_domain_page(d->arch.perdomain_l3_pg);=0A-    l3tab[l3_table_offse=
t(MAPCACHE_VIRT_START)] =3D=0A-        l3e_from_page(d->arch.perdomain_l2_p=
g[MAPCACHE_SLOT],=0A-                      __PAGE_HYPERVISOR);=0A-    =
unmap_domain_page(l3tab);=0A-=0A-    l2tab =3D __map_domain_page(d->arch.pe=
rdomain_l2_pg[MAPCACHE_SLOT]);=0A-=0A-    BUILD_BUG_ON(MAPCACHE_VIRT_END + =
3 +=0A-                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * =
sizeof(long)) >=0A+    BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 =
+=0A+                 2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * =
sizeof(long))) >=0A                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_=
MBYTES << 20));=0A     bitmap_pages =3D PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRI=
ES) * sizeof(long));=0A     dcache->inuse =3D (void *)MAPCACHE_VIRT_END + =
PAGE_SIZE;=0A     dcache->garbage =3D dcache->inuse +=0A                   =
    (bitmap_pages + 1) * PAGE_SIZE / sizeof(long);=0A-    end =3D =
dcache->garbage + bitmap_pages * PAGE_SIZE / sizeof(long);=0A-=0A-    for =
( i =3D l2_table_offset((unsigned long)dcache->inuse);=0A-          i <=3D =
l2_table_offset((unsigned long)(end - 1)); ++i )=0A-    {=0A-        =
ASSERT(i <=3D MAPCACHE_L2_ENTRIES);=0A-        dcache->l1tab[i] =3D =
alloc_xenheap_pages(0, memf);=0A-        if ( !dcache->l1tab[i] )=0A-      =
  {=0A-            unmap_domain_page(l2tab);=0A-            return =
-ENOMEM;=0A-        }=0A-        clear_page(dcache->l1tab[i]);=0A-        =
l2tab[i] =3D l2e_from_paddr(__pa(dcache->l1tab[i]), __PAGE_HYPERVISOR);=0A-=
    }=0A-=0A-    unmap_domain_page(l2tab);=0A =0A     spin_lock_init(&dcach=
e->lock);=0A =0A-    return 0;=0A+    return create_perdomain_mapping(d, =
(unsigned long)dcache->inuse,=0A+                                    2 * =
bitmap_pages + 1,=0A+                                    NIL(l1_pgentry_t =
*), NULL);=0A }=0A =0A void mapcache_domain_exit(struct domain *d)=0A@@ =
-307,94 +279,41 @@ void mapcache_domain_exit(struct domain =0A     if ( =
is_hvm_domain(d) )=0A         return;=0A =0A-    if ( dcache->l1tab )=0A-  =
  {=0A-        unsigned long i;=0A-=0A-        for ( i =3D (unsigned =
long)dcache->inuse; ; i +=3D PAGE_SIZE )=0A-        {=0A-            =
l1_pgentry_t *pl1e;=0A-=0A-            if ( l2_table_offset(i) > MAPCACHE_L=
2_ENTRIES ||=0A-                 !dcache->l1tab[l2_table_offset(i)] )=0A-  =
              break;=0A-=0A-            pl1e =3D &dcache->l1tab[l2_table_of=
fset(i)][l1_table_offset(i)];=0A-            if ( l1e_get_flags(*pl1e) =
)=0A-                free_domheap_page(l1e_get_page(*pl1e));=0A-        =
}=0A-=0A-        for ( i =3D 0; i < MAPCACHE_L2_ENTRIES + 1; ++i )=0A-     =
       free_xenheap_page(dcache->l1tab[i]);=0A-=0A-        xfree(dcache->l1=
tab);=0A-    }=0A+    xfree(dcache->l1tab);=0A }=0A =0A int mapcache_vcpu_i=
nit(struct vcpu *v)=0A {=0A     struct domain *d =3D v->domain;=0A     =
struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;=0A-    =
l2_pgentry_t *l2tab;=0A     unsigned long i;=0A-    unsigned int memf =3D =
MEMF_node(vcpu_to_node(v));=0A+    unsigned int ents =3D d->max_vcpus * =
MAPCACHE_VCPU_ENTRIES;=0A+    unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents=
) * sizeof(long));=0A =0A     if ( is_hvm_vcpu(v) || !dcache->l1tab )=0A   =
      return 0;=0A =0A-    l2tab =3D __map_domain_page(d->arch.perdomain_l2=
_pg[MAPCACHE_SLOT]);=0A-=0A-    while ( dcache->entries < d->max_vcpus * =
MAPCACHE_VCPU_ENTRIES )=0A+    if ( ents > dcache->entries )=0A     {=0A-  =
      unsigned int ents =3D dcache->entries + MAPCACHE_VCPU_ENTRIES;=0A-   =
     l1_pgentry_t *pl1e;=0A-=0A         /* Populate page tables. */=0A-    =
    if ( !dcache->l1tab[i =3D mapcache_l2_entry(ents - 1)] )=0A-        =
{=0A-            dcache->l1tab[i] =3D alloc_xenheap_pages(0, memf);=0A-    =
        if ( !dcache->l1tab[i] )=0A-            {=0A-                =
unmap_domain_page(l2tab);=0A-                return -ENOMEM;=0A-           =
 }=0A-            clear_page(dcache->l1tab[i]);=0A-            l2tab[i] =
=3D l2e_from_paddr(__pa(dcache->l1tab[i]),=0A-                             =
         __PAGE_HYPERVISOR);=0A-        }=0A+        int rc =3D create_perd=
omain_mapping(d, MAPCACHE_VIRT_START,=0A+                                  =
        d->max_vcpus * MAPCACHE_VCPU_ENTRIES,=0A+                          =
                dcache->l1tab, NULL);=0A =0A         /* Populate bit maps. =
*/=0A-        i =3D (unsigned long)(dcache->inuse + BITS_TO_LONGS(ents));=
=0A-        pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_table_offset(i)]=
;=0A-        if ( !l1e_get_flags(*pl1e) )=0A-        {=0A-            =
struct page_info *pg =3D alloc_domheap_page(NULL, memf);=0A+        if ( =
!rc )=0A+            rc =3D create_perdomain_mapping(d, (unsigned =
long)dcache->inuse,=0A+                                          nr, NULL, =
NIL(struct page_info *));=0A+        if ( !rc )=0A+            rc =3D =
create_perdomain_mapping(d, (unsigned long)dcache->garbage,=0A+            =
                              nr, NULL, NIL(struct page_info *));=0A =0A-  =
          if ( pg )=0A-            {=0A-                clear_domain_page(p=
age_to_mfn(pg));=0A-                *pl1e =3D l1e_from_page(pg, __PAGE_HYPE=
RVISOR);=0A-                pg =3D alloc_domheap_page(NULL, memf);=0A-     =
       }=0A-            if ( !pg )=0A-            {=0A-                =
unmap_domain_page(l2tab);=0A-                return -ENOMEM;=0A-           =
 }=0A-=0A-            i =3D (unsigned long)(dcache->garbage + BITS_TO_LONGS=
(ents));=0A-            pl1e =3D &dcache->l1tab[l2_table_offset(i)][l1_tabl=
e_offset(i)];=0A-            ASSERT(!l1e_get_flags(*pl1e));=0A-=0A-        =
    clear_domain_page(page_to_mfn(pg));=0A-            *pl1e =3D l1e_from_p=
age(pg, __PAGE_HYPERVISOR);=0A-        }=0A+        if ( rc )=0A+          =
  return rc;=0A =0A         dcache->entries =3D ents;=0A     }=0A =0A-    =
unmap_domain_page(l2tab);=0A-=0A     /* Mark all maphash entries as not in =
use. */=0A     BUILD_BUG_ON(MAPHASHENT_NOTINUSE < MAPCACHE_ENTRIES);=0A    =
 for ( i =3D 0; i < MAPHASH_ENTRIES; i++ )=0A--- a/xen/arch/x86/mm.c=0A+++ =
b/xen/arch/x86/mm.c=0A@@ -511,6 +511,7 @@ void update_cr3(struct vcpu =
*v)=0A =0A static void invalidate_shadow_ldt(struct vcpu *v, int flush)=0A =
{=0A+    l1_pgentry_t *pl1e;=0A     int i;=0A     unsigned long pfn;=0A    =
 struct page_info *page;=0A@@ -523,12 +524,13 @@ static void invalidate_sha=
dow_ldt(struct=0A         goto out;=0A =0A     v->arch.pv_vcpu.shadow_ldt_m=
apcnt =3D 0;=0A+    pl1e =3D gdt_ldt_ptes(v->domain, v);=0A =0A     for ( =
i =3D 16; i < 32; i++ )=0A     {=0A-        pfn =3D l1e_get_pfn(v->arch.per=
domain_ptes[i]);=0A+        pfn =3D l1e_get_pfn(pl1e[i]);=0A         if ( =
pfn =3D=3D 0 ) continue;=0A-        l1e_write(&v->arch.perdomain_ptes[i], =
l1e_empty());=0A+        l1e_write(&pl1e[i], l1e_empty());=0A         page =
=3D mfn_to_page(pfn);=0A         ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_pag=
e);=0A         ASSERT_PAGE_IS_DOMAIN(page, v->domain);=0A@@ -596,7 +598,7 =
@@ int map_ldt_shadow_page(unsigned int off=0A     nl1e =3D l1e_from_pfn(pa=
ge_to_mfn(page), l1e_get_flags(l1e) | _PAGE_RW);=0A =0A     spin_lock(&v->a=
rch.pv_vcpu.shadow_ldt_lock);=0A-    l1e_write(&v->arch.perdomain_ptes[off =
+ 16], nl1e);=0A+    l1e_write(&gdt_ldt_ptes(d, v)[off + 16], nl1e);=0A    =
 v->arch.pv_vcpu.shadow_ldt_mapcnt++;=0A     spin_unlock(&v->arch.pv_vcpu.s=
hadow_ldt_lock);=0A =0A@@ -4073,15 +4075,17 @@ long do_update_va_mapping_ot=
herdomain(un=0A =0A void destroy_gdt(struct vcpu *v)=0A {=0A+    l1_pgentry=
_t *pl1e;=0A     int i;=0A     unsigned long pfn;=0A =0A     v->arch.pv_vcp=
u.gdt_ents =3D 0;=0A+    pl1e =3D gdt_ldt_ptes(v->domain, v);=0A     for ( =
i =3D 0; i < FIRST_RESERVED_GDT_PAGE; i++ )=0A     {=0A-        if ( (pfn =
=3D l1e_get_pfn(v->arch.perdomain_ptes[i])) !=3D 0 )=0A+        if ( (pfn =
=3D l1e_get_pfn(pl1e[i])) !=3D 0 )=0A             put_page_and_type(mfn_to_=
page(pfn));=0A-        l1e_write(&v->arch.perdomain_ptes[i], l1e_empty());=
=0A+        l1e_write(&pl1e[i], l1e_empty());=0A         v->arch.pv_vcpu.gd=
t_frames[i] =3D 0;=0A     }=0A }=0A@@ -4092,6 +4096,7 @@ long set_gdt(struc=
t vcpu *v, =0A              unsigned int entries)=0A {=0A     struct =
domain *d =3D v->domain;=0A+    l1_pgentry_t *pl1e;=0A     /* NB. There =
are 512 8-byte entries per GDT page. */=0A     int i, nr_pages =3D =
(entries + 511) / 512;=0A     unsigned long mfn, *pfns;=0A@@ -4124,11 =
+4129,11 @@ long set_gdt(struct vcpu *v, =0A =0A     /* Install the new =
GDT. */=0A     v->arch.pv_vcpu.gdt_ents =3D entries;=0A+    pl1e =3D =
gdt_ldt_ptes(d, v);=0A     for ( i =3D 0; i < nr_pages; i++ )=0A     {=0A  =
       v->arch.pv_vcpu.gdt_frames[i] =3D frames[i];=0A-        l1e_write(&v=
->arch.perdomain_ptes[i],=0A-                  l1e_from_pfn(frames[i], =
__PAGE_HYPERVISOR));=0A+        l1e_write(&pl1e[i], l1e_from_pfn(frames[i],=
 __PAGE_HYPERVISOR));=0A     }=0A =0A     xfree(pfns);=0A@@ -5528,6 =
+5533,175 @@ void __iomem *ioremap(paddr_t pa, size_t=0A     return (void =
__force __iomem *)va;=0A }=0A =0A+int create_perdomain_mapping(struct =
domain *d, unsigned long va,=0A+                             unsigned int =
nr, l1_pgentry_t **pl1tab,=0A+                             struct =
page_info **ppg)=0A+{=0A+    struct page_info *pg;=0A+    l3_pgentry_t =
*l3tab;=0A+    l2_pgentry_t *l2tab;=0A+    l1_pgentry_t *l1tab;=0A+    =
unsigned int memf =3D MEMF_node(domain_to_node(d));=0A+    int rc =3D =
0;=0A+=0A+    ASSERT(va >=3D PERDOMAIN_VIRT_START &&=0A+           va < =
PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));=0A+=0A+    if ( !d->arch.perdomain_l=
3_pg )=0A+    {=0A+        pg =3D alloc_domheap_page(NULL, MEMF_node(domain=
_to_node(d)));=0A+        if ( !pg )=0A+            return -ENOMEM;=0A+    =
    l3tab =3D __map_domain_page(pg);=0A+        clear_page(l3tab);=0A+     =
   d->arch.perdomain_l3_pg =3D pg;=0A+        if ( !nr )=0A+        {=0A+  =
          unmap_domain_page(l3tab);=0A+            return 0;=0A+        =
}=0A+    }=0A+    else if ( !nr )=0A+        return 0;=0A+    else=0A+     =
   l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);=0A+=0A+    =
ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));=0A+=0A+    if ( =
!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT) )=0A+    =
{=0A+        pg =3D alloc_domheap_page(NULL, memf);=0A+        if ( !pg =
)=0A+        {=0A+            unmap_domain_page(l3tab);=0A+            =
return -ENOMEM;=0A+        }=0A+        l2tab =3D __map_domain_page(pg);=0A=
+        clear_page(l2tab);=0A+        l3tab[l3_table_offset(va)] =3D =
l3e_from_page(pg, __PAGE_HYPERVISOR);=0A+    }=0A+    else=0A+        =
l2tab =3D map_domain_page(l3e_get_pfn(l3tab[l3_table_offset(va)]));=0A+=0A+=
    unmap_domain_page(l3tab);=0A+=0A+    if ( !pl1tab && !ppg )=0A+    =
{=0A+        unmap_domain_page(l2tab);=0A+        return 0;=0A+    =
}=0A+=0A+    for ( l1tab =3D NULL; !rc && nr--; )=0A+    {=0A+        =
l2_pgentry_t *pl2e =3D l2tab + l2_table_offset(va);=0A+=0A+        if ( =
!(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )=0A+        {=0A+            if ( =
pl1tab && !IS_NIL(pl1tab) )=0A+            {=0A+                l1tab =3D =
alloc_xenheap_pages(0, memf);=0A+                if ( !l1tab )=0A+         =
       {=0A+                    rc =3D -ENOMEM;=0A+                    =
break;=0A+                }=0A+                ASSERT(!pl1tab[l2_table_offs=
et(va)]);=0A+                pl1tab[l2_table_offset(va)] =3D l1tab;=0A+    =
            pg =3D virt_to_page(l1tab);=0A+            }=0A+            =
else=0A+            {=0A+                pg =3D alloc_domheap_page(NULL, =
memf);=0A+                if ( !pg )=0A+                {=0A+              =
      rc =3D -ENOMEM;=0A+                    break;=0A+                =
}=0A+                l1tab =3D __map_domain_page(pg);=0A+            }=0A+ =
           clear_page(l1tab);=0A+            *pl2e =3D l2e_from_page(pg, =
__PAGE_HYPERVISOR);=0A+        }=0A+        else if ( !l1tab )=0A+         =
   l1tab =3D map_domain_page(l2e_get_pfn(*pl2e));=0A+=0A+        if ( ppg =
&&=0A+             !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRES=
ENT) )=0A+        {=0A+            pg =3D alloc_domheap_page(NULL, =
memf);=0A+            if ( pg )=0A+            {=0A+                =
clear_domain_page(page_to_mfn(pg));=0A+                if ( !IS_NIL(ppg) =
)=0A+                    *ppg++ =3D pg;=0A+                l1tab[l1_table_o=
ffset(va)] =3D=0A+                    l1e_from_page(pg, __PAGE_HYPERVISOR =
| _PAGE_AVAIL0);=0A+                l2e_add_flags(*pl2e, _PAGE_AVAIL0);=0A+=
            }=0A+            else=0A+                rc =3D -ENOMEM;=0A+   =
     }=0A+=0A+        va +=3D PAGE_SIZE;=0A+        if ( rc || !nr || =
!l1_table_offset(va) )=0A+        {=0A+            /* Note that this is a =
no-op for the alloc_xenheap_page() case. */=0A+            unmap_domain_pag=
e(l1tab);=0A+            l1tab =3D NULL;=0A+        }=0A+    }=0A+=0A+    =
ASSERT(!l1tab);=0A+    unmap_domain_page(l2tab);=0A+=0A+    return =
rc;=0A+}=0A+=0A+void free_perdomain_mappings(struct domain *d)=0A+{=0A+    =
l3_pgentry_t *l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg);=0A+    =
unsigned int i;=0A+=0A+    for ( i =3D 0; i < PERDOMAIN_SLOTS; ++i)=0A+    =
    if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )=0A+        {=0A+        =
    struct page_info *l2pg =3D l3e_get_page(l3tab[i]);=0A+            =
l2_pgentry_t *l2tab =3D __map_domain_page(l2pg);=0A+            unsigned =
int j;=0A+=0A+            for ( j =3D 0; j < L2_PAGETABLE_ENTRIES; ++j =
)=0A+                if ( l2e_get_flags(l2tab[j]) & _PAGE_PRESENT )=0A+    =
            {=0A+                    struct page_info *l1pg =3D l2e_get_pag=
e(l2tab[j]);=0A+=0A+                    if ( l2e_get_flags(l2tab[j]) & =
_PAGE_AVAIL0 )=0A+                    {=0A+                        =
l1_pgentry_t *l1tab =3D __map_domain_page(l1pg);=0A+                       =
 unsigned int k;=0A+=0A+                        for ( k =3D 0; k < =
L1_PAGETABLE_ENTRIES; ++k )=0A+                            if ( (l1e_get_fl=
ags(l1tab[k]) &=0A+                                  (_PAGE_PRESENT | =
_PAGE_AVAIL0)) =3D=3D=0A+                                 (_PAGE_PRESENT | =
_PAGE_AVAIL0) )=0A+                                free_domheap_page(l1e_ge=
t_page(l1tab[k]));=0A+=0A+                        unmap_domain_page(l1tab);=
=0A+                    }=0A+=0A+                    if ( is_xen_heap_page(=
l1pg) )=0A+                        free_xenheap_page(page_to_virt(l1pg));=
=0A+                    else=0A+                        free_domheap_page(l=
1pg);=0A+                }=0A+=0A+            unmap_domain_page(l2tab);=0A+=
            free_domheap_page(l2pg);=0A+        }=0A+=0A+    unmap_domain_p=
age(l3tab);=0A+    free_domheap_page(d->arch.perdomain_l3_pg);=0A+}=0A+=0A =
#ifdef MEMORY_GUARD=0A =0A void memguard_init(void)=0A--- a/xen/include/asm=
-x86/config.h=0A+++ b/xen/include/asm-x86/config.h=0A@@ -304,19 +304,13 @@ =
extern unsigned long xen_phys_start;=0A #define LDT_VIRT_START(v)    \=0A  =
   (GDT_VIRT_START(v) + (64*1024))=0A =0A-/* map_domain_page() map cache. =
The last per-domain-mapping sub-area. */=0A+/* map_domain_page() map =
cache. The second per-domain-mapping sub-area. */=0A #define MAPCACHE_VCPU_=
ENTRIES    (CONFIG_PAGING_LEVELS * CONFIG_PAGING_LEVELS)=0A #define =
MAPCACHE_ENTRIES         (MAX_VIRT_CPUS * MAPCACHE_VCPU_ENTRIES)=0A-#define=
 MAPCACHE_SLOT            (PERDOMAIN_SLOTS - 1)=0A-#define MAPCACHE_VIRT_ST=
ART      PERDOMAIN_VIRT_SLOT(MAPCACHE_SLOT)=0A+#define MAPCACHE_VIRT_START =
     PERDOMAIN_VIRT_SLOT(1)=0A #define MAPCACHE_VIRT_END        (MAPCACHE_V=
IRT_START + \=0A                                   MAPCACHE_ENTRIES * =
PAGE_SIZE)=0A =0A-#define PDPT_L1_ENTRIES       \=0A-    ((PERDOMAIN_VIRT_S=
LOT(PERDOMAIN_SLOTS - 1) - PERDOMAIN_VIRT_START) >> PAGE_SHIFT)=0A-#define =
PDPT_L2_ENTRIES       \=0A-    ((PDPT_L1_ENTRIES + (1 << PAGETABLE_ORDER) =
- 1) >> PAGETABLE_ORDER)=0A-=0A #define ELFSIZE 64=0A =0A #define =
ARCH_CRASH_SAVE_VMCOREINFO=0A--- a/xen/include/asm-x86/domain.h=0A+++ =
b/xen/include/asm-x86/domain.h=0A@@ -223,6 +223,8 @@ struct time_scale =
{=0A =0A struct pv_domain=0A {=0A+    l1_pgentry_t **gdt_ldt_l1tab;=0A+=0A =
    /* Shared page for notifying that explicit PIRQ EOI is required. */=0A =
    unsigned long *pirq_eoi_map;=0A     unsigned long pirq_eoi_map_mfn;=0A@=
@ -241,8 +243,6 @@ struct pv_domain=0A =0A struct arch_domain=0A {=0A-    =
void **perdomain_pts;=0A-    struct page_info *perdomain_l2_pg[PERDOMAIN_SL=
OTS];=0A     struct page_info *perdomain_l3_pg;=0A =0A     unsigned int =
hv_compat_vstart;=0A@@ -318,10 +318,10 @@ struct arch_domain=0A #define =
has_arch_pdevs(d)    (!list_empty(&(d)->arch.pdev_list))=0A #define =
has_arch_mmios(d)    (!rangeset_is_empty((d)->iomem_caps))=0A =0A-#define =
perdomain_pt_idx(v) \=0A+#define gdt_ldt_pt_idx(v) \=0A       ((v)->vcpu_id=
 >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))=0A-#define perdomain_ptes(d, =
v) \=0A-    ((l1_pgentry_t *)(d)->arch.perdomain_pts[perdomain_pt_idx(v)] =
+ \=0A+#define gdt_ldt_ptes(d, v) \=0A+    ((d)->arch.pv_domain.gdt_ldt_l1t=
ab[gdt_ldt_pt_idx(v)] + \=0A      (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & =
(L1_PAGETABLE_ENTRIES - 1)))=0A =0A struct pv_vcpu=0A@@ -406,12 +406,6 @@ =
struct arch_vcpu=0A         struct hvm_vcpu hvm_vcpu;=0A     };=0A =0A-    =
/*=0A-     * Every domain has a L1 pagetable of its own. Per-domain =
mappings=0A-     * are put in this table (eg. the current GDT is mapped =
here).=0A-     */=0A-    l1_pgentry_t *perdomain_ptes;=0A-=0A     =
pagetable_t guest_table_user;       /* (MFN) x86/64 user-space pagetable =
*/=0A     pagetable_t guest_table;            /* (MFN) guest notion of cr3 =
*/=0A     /* guest_table holds a ref to the page, and also a type-count =
unless=0A--- a/xen/include/asm-x86/mm.h=0A+++ b/xen/include/asm-x86/mm.h=0A=
@@ -573,6 +573,14 @@ int donate_page(=0A =0A int map_ldt_shadow_page(unsign=
ed int);=0A =0A+#define NIL(type) ((type *)NULL - 1)=0A+#define IS_NIL(ptr)=
 (!((ptr) + 1))=0A+=0A+int create_perdomain_mapping(struct domain *, =
unsigned long va,=0A+                             unsigned int nr, =
l1_pgentry_t **,=0A+                             struct page_info =
**);=0A+void free_perdomain_mappings(struct domain *);=0A+=0A extern int =
memory_add(unsigned long spfn, unsigned long epfn, unsigned int pxm);=0A =
=0A void domain_set_alloc_bitsize(struct domain *d);=0A
--=__PartAB9BDB63.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

--=__PartAB9BDB63.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 16:07:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN3x-0007pd-4S; Tue, 26 Feb 2013 16:07:29 +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 1UAN3v-0007pG-1W
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:07:27 +0000
Received: from [85.158.139.211:10861] by server-8.bemta-5.messagelabs.com id
	E1/1E-05790-CBDDC215; Tue, 26 Feb 2013 16:07:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361894843!15394685!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20087 invoked from network); 26 Feb 2013 16:07:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:07:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:07:23 +0000
Message-Id: <512CEBCA02000078000C127E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:07:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512CE92B02000078000C1256@nat28.tlf.novell.com>
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part625212AA.0__="
Subject: [Xen-devel] [PATCH v2 3/3] x86: use linear L1 page table for
 map_domain_page() page table manipulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part625212AA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This saves allocation of a Xen heap page for tracking the L1 page table
pointers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -585,7 +585,6 @@ int arch_domain_create(struct domain *d,
     free_xenheap_page(d->shared_info);
     if ( paging_initialised )
         paging_final_teardown(d);
-    mapcache_domain_exit(d);
     free_perdomain_mappings(d);
     if ( !is_hvm_domain(d) )
         free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
@@ -605,8 +604,6 @@ void arch_domain_destroy(struct domain *
=20
     paging_final_teardown(d);
=20
-    mapcache_domain_exit(d);
-
     free_perdomain_mappings(d);
     if ( !is_hvm_domain(d) )
         free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -53,9 +53,8 @@ void __init mapcache_override_current(st
=20
 #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER)
 #define MAPCACHE_L2_ENTRIES (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1)
-#define DCACHE_L1ENT(dc, idx) \
-    ((dc)->l1tab[(idx) >> PAGETABLE_ORDER] \
-                [(idx) & ((1 << PAGETABLE_ORDER) - 1)])
+#define MAPCACHE_L1ENT(idx) \
+    __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_paddr(=
idx))]
=20
 void *map_domain_page(unsigned long mfn)
 {
@@ -77,7 +76,7 @@ void *map_domain_page(unsigned long mfn)
=20
     dcache =3D &v->domain->arch.pv_domain.mapcache;
     vcache =3D &v->arch.pv_vcpu.mapcache;
-    if ( !dcache->l1tab )
+    if ( !dcache->inuse )
         return mfn_to_virt(mfn);
=20
     perfc_incr(map_domain_page_count);
@@ -91,7 +90,7 @@ void *map_domain_page(unsigned long mfn)
         ASSERT(idx < dcache->entries);
         hashent->refcnt++;
         ASSERT(hashent->refcnt);
-        ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, idx)) =3D=3D mfn);
+        ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) =3D=3D mfn);
         goto out;
     }
=20
@@ -131,9 +130,8 @@ void *map_domain_page(unsigned long mfn)
                 if ( hashent->idx !=3D MAPHASHENT_NOTINUSE && !hashent->re=
fcnt )
                 {
                     idx =3D hashent->idx;
-                    ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, idx)) =3D=3D
-                           hashent->mfn);
-                    l1e_write(&DCACHE_L1ENT(dcache, idx), l1e_empty());
+                    ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) =3D=3D =
hashent->mfn);
+                    l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty());
                     hashent->idx =3D MAPHASHENT_NOTINUSE;
                     hashent->mfn =3D ~0UL;
                     break;
@@ -156,8 +154,7 @@ void *map_domain_page(unsigned long mfn)
=20
     spin_unlock(&dcache->lock);
=20
-    l1e_write(&DCACHE_L1ENT(dcache, idx),
-              l1e_from_pfn(mfn, __PAGE_HYPERVISOR));
+    l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_pfn(mfn, __PAGE_HYPERVISOR));=

=20
  out:
     local_irq_restore(flags);
@@ -181,10 +178,10 @@ void unmap_domain_page(const void *ptr)
     ASSERT(v && !is_hvm_vcpu(v));
=20
     dcache =3D &v->domain->arch.pv_domain.mapcache;
-    ASSERT(dcache->l1tab);
+    ASSERT(dcache->inuse);
=20
     idx =3D PFN_DOWN(va - MAPCACHE_VIRT_START);
-    mfn =3D l1e_get_pfn(DCACHE_L1ENT(dcache, idx));
+    mfn =3D l1e_get_pfn(MAPCACHE_L1ENT(idx));
     hashent =3D &v->arch.pv_vcpu.mapcache.hash[MAPHASH_HASHFN(mfn)];
=20
     local_irq_save(flags);
@@ -200,9 +197,9 @@ void unmap_domain_page(const void *ptr)
         if ( hashent->idx !=3D MAPHASHENT_NOTINUSE )
         {
             /* /First/, zap the PTE. */
-            ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, hashent->idx)) =3D=3D
+            ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(hashent->idx)) =3D=3D
                    hashent->mfn);
-            l1e_write(&DCACHE_L1ENT(dcache, hashent->idx), l1e_empty());
+            l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty());
             /* /Second/, mark as garbage. */
             set_bit(hashent->idx, dcache->garbage);
         }
@@ -214,7 +211,7 @@ void unmap_domain_page(const void *ptr)
     else
     {
         /* /First/, zap the PTE. */
-        l1e_write(&DCACHE_L1ENT(dcache, idx), l1e_empty());
+        l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty());
         /* /Second/, mark as garbage. */
         set_bit(idx, dcache->garbage);
     }
@@ -253,10 +250,6 @@ int mapcache_domain_init(struct domain *
         return 0;
 #endif
=20
-    dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);
-    if ( !dcache->l1tab )
-        return -ENOMEM;
-
     BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
                  2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
)) >
                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20));
@@ -272,16 +265,6 @@ int mapcache_domain_init(struct domain *
                                     NIL(l1_pgentry_t *), NULL);
 }
=20
-void mapcache_domain_exit(struct domain *d)
-{
-    struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;
-
-    if ( is_hvm_domain(d) )
-        return;
-
-    xfree(dcache->l1tab);
-}
-
 int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
@@ -290,7 +273,7 @@ int mapcache_vcpu_init(struct vcpu *v)
     unsigned int ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
     unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
=20
-    if ( is_hvm_vcpu(v) || !dcache->l1tab )
+    if ( is_hvm_vcpu(v) || !dcache->inuse )
         return 0;
=20
     if ( ents > dcache->entries )
@@ -298,7 +281,7 @@ int mapcache_vcpu_init(struct vcpu *v)
         /* Populate page tables. */
         int rc =3D create_perdomain_mapping(d, MAPCACHE_VIRT_START,
                                           d->max_vcpus * MAPCACHE_VCPU_ENT=
RIES,
-                                          dcache->l1tab, NULL);
+                                          NIL(l1_pgentry_t *), NULL);
=20
         /* Populate bit maps. */
         if ( !rc )
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -53,8 +53,7 @@ struct mapcache_vcpu {
 };
=20
 struct mapcache_domain {
-    /* The PTEs that provide the mappings, and a cursor into the array. =
*/
-    l1_pgentry_t **l1tab;
+    /* The number of array entries, and a cursor into the array. */
     unsigned int entries;
     unsigned int cursor;
=20
@@ -71,7 +70,6 @@ struct mapcache_domain {
 };
=20
 int mapcache_domain_init(struct domain *);
-void mapcache_domain_exit(struct domain *);
 int mapcache_vcpu_init(struct vcpu *);
 void mapcache_override_current(struct vcpu *);
=20



--=__Part625212AA.0__=
Content-Type: text/plain; name="x86-map-domain-page-use-linear-l1.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-domain-page-use-linear-l1.patch"

x86: use linear L1 page table for map_domain_page() page table manipulation=
=0A=0AThis saves allocation of a Xen heap page for tracking the L1 page =
table=0Apointers.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -585,7 =
+585,6 @@ int arch_domain_create(struct domain *d,=0A     free_xenheap_page=
(d->shared_info);=0A     if ( paging_initialised )=0A         paging_final_=
teardown(d);=0A-    mapcache_domain_exit(d);=0A     free_perdomain_mappings=
(d);=0A     if ( !is_hvm_domain(d) )=0A         free_xenheap_page(d->arch.p=
v_domain.gdt_ldt_l1tab);=0A@@ -605,8 +604,6 @@ void arch_domain_destroy(str=
uct domain *=0A =0A     paging_final_teardown(d);=0A =0A-    mapcache_domai=
n_exit(d);=0A-=0A     free_perdomain_mappings(d);=0A     if ( !is_hvm_domai=
n(d) )=0A         free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);=0A---=
 a/xen/arch/x86/domain_page.c=0A+++ b/xen/arch/x86/domain_page.c=0A@@ =
-53,9 +53,8 @@ void __init mapcache_override_current(st=0A =0A #define =
mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER)=0A #define MAPCACHE_L2_ENTRIE=
S (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1)=0A-#define DCACHE_L1ENT(dc,=
 idx) \=0A-    ((dc)->l1tab[(idx) >> PAGETABLE_ORDER] \=0A-                =
[(idx) & ((1 << PAGETABLE_ORDER) - 1)])=0A+#define MAPCACHE_L1ENT(idx) =
\=0A+    __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + =
pfn_to_paddr(idx))]=0A =0A void *map_domain_page(unsigned long mfn)=0A =
{=0A@@ -77,7 +76,7 @@ void *map_domain_page(unsigned long mfn)=0A =0A     =
dcache =3D &v->domain->arch.pv_domain.mapcache;=0A     vcache =3D =
&v->arch.pv_vcpu.mapcache;=0A-    if ( !dcache->l1tab )=0A+    if ( =
!dcache->inuse )=0A         return mfn_to_virt(mfn);=0A =0A     perfc_incr(=
map_domain_page_count);=0A@@ -91,7 +90,7 @@ void *map_domain_page(unsigned =
long mfn)=0A         ASSERT(idx < dcache->entries);=0A         hashent->ref=
cnt++;=0A         ASSERT(hashent->refcnt);=0A-        ASSERT(l1e_get_pfn(DC=
ACHE_L1ENT(dcache, idx)) =3D=3D mfn);=0A+        ASSERT(l1e_get_pfn(MAPCACH=
E_L1ENT(idx)) =3D=3D mfn);=0A         goto out;=0A     }=0A =0A@@ -131,9 =
+130,8 @@ void *map_domain_page(unsigned long mfn)=0A                 if ( =
hashent->idx !=3D MAPHASHENT_NOTINUSE && !hashent->refcnt )=0A             =
    {=0A                     idx =3D hashent->idx;=0A-                    =
ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, idx)) =3D=3D=0A-                   =
        hashent->mfn);=0A-                    l1e_write(&DCACHE_L1ENT(dcach=
e, idx), l1e_empty());=0A+                    ASSERT(l1e_get_pfn(MAPCACHE_L=
1ENT(idx)) =3D=3D hashent->mfn);=0A+                    l1e_write(&MAPCACHE=
_L1ENT(idx), l1e_empty());=0A                     hashent->idx =3D =
MAPHASHENT_NOTINUSE;=0A                     hashent->mfn =3D ~0UL;=0A      =
               break;=0A@@ -156,8 +154,7 @@ void *map_domain_page(unsigned =
long mfn)=0A =0A     spin_unlock(&dcache->lock);=0A =0A-    l1e_write(&DCAC=
HE_L1ENT(dcache, idx),=0A-              l1e_from_pfn(mfn, __PAGE_HYPERVISOR=
));=0A+    l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_pfn(mfn, __PAGE_HYPERVI=
SOR));=0A =0A  out:=0A     local_irq_restore(flags);=0A@@ -181,10 +178,10 =
@@ void unmap_domain_page(const void *ptr)=0A     ASSERT(v && !is_hvm_vcpu(=
v));=0A =0A     dcache =3D &v->domain->arch.pv_domain.mapcache;=0A-    =
ASSERT(dcache->l1tab);=0A+    ASSERT(dcache->inuse);=0A =0A     idx =3D =
PFN_DOWN(va - MAPCACHE_VIRT_START);=0A-    mfn =3D l1e_get_pfn(DCACHE_L1ENT=
(dcache, idx));=0A+    mfn =3D l1e_get_pfn(MAPCACHE_L1ENT(idx));=0A     =
hashent =3D &v->arch.pv_vcpu.mapcache.hash[MAPHASH_HASHFN(mfn)];=0A =0A    =
 local_irq_save(flags);=0A@@ -200,9 +197,9 @@ void unmap_domain_page(const =
void *ptr)=0A         if ( hashent->idx !=3D MAPHASHENT_NOTINUSE )=0A      =
   {=0A             /* /First/, zap the PTE. */=0A-            ASSERT(l1e_g=
et_pfn(DCACHE_L1ENT(dcache, hashent->idx)) =3D=3D=0A+            ASSERT(l1e=
_get_pfn(MAPCACHE_L1ENT(hashent->idx)) =3D=3D=0A                    =
hashent->mfn);=0A-            l1e_write(&DCACHE_L1ENT(dcache, hashent->idx)=
, l1e_empty());=0A+            l1e_write(&MAPCACHE_L1ENT(hashent->idx), =
l1e_empty());=0A             /* /Second/, mark as garbage. */=0A           =
  set_bit(hashent->idx, dcache->garbage);=0A         }=0A@@ -214,7 +211,7 =
@@ void unmap_domain_page(const void *ptr)=0A     else=0A     {=0A         =
/* /First/, zap the PTE. */=0A-        l1e_write(&DCACHE_L1ENT(dcache, =
idx), l1e_empty());=0A+        l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty())=
;=0A         /* /Second/, mark as garbage. */=0A         set_bit(idx, =
dcache->garbage);=0A     }=0A@@ -253,10 +250,6 @@ int mapcache_domain_init(=
struct domain *=0A         return 0;=0A #endif=0A =0A-    dcache->l1tab =
=3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);=0A-    if ( =
!dcache->l1tab )=0A-        return -ENOMEM;=0A-=0A     BUILD_BUG_ON(MAPCACH=
E_VIRT_END + PAGE_SIZE * (3 +=0A                  2 * PFN_UP(BITS_TO_LONGS(=
MAPCACHE_ENTRIES) * sizeof(long))) >=0A                  MAPCACHE_VIRT_STAR=
T + (PERDOMAIN_SLOT_MBYTES << 20));=0A@@ -272,16 +265,6 @@ int mapcache_dom=
ain_init(struct domain *=0A                                     NIL(l1_pgen=
try_t *), NULL);=0A }=0A =0A-void mapcache_domain_exit(struct domain =
*d)=0A-{=0A-    struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapca=
che;=0A-=0A-    if ( is_hvm_domain(d) )=0A-        return;=0A-=0A-    =
xfree(dcache->l1tab);=0A-}=0A-=0A int mapcache_vcpu_init(struct vcpu =
*v)=0A {=0A     struct domain *d =3D v->domain;=0A@@ -290,7 +273,7 @@ int =
mapcache_vcpu_init(struct vcpu *v)=0A     unsigned int ents =3D d->max_vcpu=
s * MAPCACHE_VCPU_ENTRIES;=0A     unsigned int nr =3D PFN_UP(BITS_TO_LONGS(=
ents) * sizeof(long));=0A =0A-    if ( is_hvm_vcpu(v) || !dcache->l1tab =
)=0A+    if ( is_hvm_vcpu(v) || !dcache->inuse )=0A         return 0;=0A =
=0A     if ( ents > dcache->entries )=0A@@ -298,7 +281,7 @@ int mapcache_vc=
pu_init(struct vcpu *v)=0A         /* Populate page tables. */=0A         =
int rc =3D create_perdomain_mapping(d, MAPCACHE_VIRT_START,=0A             =
                              d->max_vcpus * MAPCACHE_VCPU_ENTRIES,=0A-    =
                                      dcache->l1tab, NULL);=0A+            =
                              NIL(l1_pgentry_t *), NULL);=0A =0A         =
/* Populate bit maps. */=0A         if ( !rc )=0A--- a/xen/include/asm-x86/=
domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ -53,8 +53,7 @@ struct =
mapcache_vcpu {=0A };=0A =0A struct mapcache_domain {=0A-    /* The PTEs =
that provide the mappings, and a cursor into the array. */=0A-    =
l1_pgentry_t **l1tab;=0A+    /* The number of array entries, and a cursor =
into the array. */=0A     unsigned int entries;=0A     unsigned int =
cursor;=0A =0A@@ -71,7 +70,6 @@ struct mapcache_domain {=0A };=0A =0A int =
mapcache_domain_init(struct domain *);=0A-void mapcache_domain_exit(struct =
domain *);=0A int mapcache_vcpu_init(struct vcpu *);=0A void mapcache_overr=
ide_current(struct vcpu *);=0A =0A
--=__Part625212AA.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

--=__Part625212AA.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 16:07:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN3x-0007pd-4S; Tue, 26 Feb 2013 16:07:29 +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 1UAN3v-0007pG-1W
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:07:27 +0000
Received: from [85.158.139.211:10861] by server-8.bemta-5.messagelabs.com id
	E1/1E-05790-CBDDC215; Tue, 26 Feb 2013 16:07:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361894843!15394685!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20087 invoked from network); 26 Feb 2013 16:07:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:07:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:07:23 +0000
Message-Id: <512CEBCA02000078000C127E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:07:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <512CE92B02000078000C1256@nat28.tlf.novell.com>
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part625212AA.0__="
Subject: [Xen-devel] [PATCH v2 3/3] x86: use linear L1 page table for
 map_domain_page() page table manipulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part625212AA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This saves allocation of a Xen heap page for tracking the L1 page table
pointers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -585,7 +585,6 @@ int arch_domain_create(struct domain *d,
     free_xenheap_page(d->shared_info);
     if ( paging_initialised )
         paging_final_teardown(d);
-    mapcache_domain_exit(d);
     free_perdomain_mappings(d);
     if ( !is_hvm_domain(d) )
         free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
@@ -605,8 +604,6 @@ void arch_domain_destroy(struct domain *
=20
     paging_final_teardown(d);
=20
-    mapcache_domain_exit(d);
-
     free_perdomain_mappings(d);
     if ( !is_hvm_domain(d) )
         free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -53,9 +53,8 @@ void __init mapcache_override_current(st
=20
 #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER)
 #define MAPCACHE_L2_ENTRIES (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1)
-#define DCACHE_L1ENT(dc, idx) \
-    ((dc)->l1tab[(idx) >> PAGETABLE_ORDER] \
-                [(idx) & ((1 << PAGETABLE_ORDER) - 1)])
+#define MAPCACHE_L1ENT(idx) \
+    __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_paddr(=
idx))]
=20
 void *map_domain_page(unsigned long mfn)
 {
@@ -77,7 +76,7 @@ void *map_domain_page(unsigned long mfn)
=20
     dcache =3D &v->domain->arch.pv_domain.mapcache;
     vcache =3D &v->arch.pv_vcpu.mapcache;
-    if ( !dcache->l1tab )
+    if ( !dcache->inuse )
         return mfn_to_virt(mfn);
=20
     perfc_incr(map_domain_page_count);
@@ -91,7 +90,7 @@ void *map_domain_page(unsigned long mfn)
         ASSERT(idx < dcache->entries);
         hashent->refcnt++;
         ASSERT(hashent->refcnt);
-        ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, idx)) =3D=3D mfn);
+        ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) =3D=3D mfn);
         goto out;
     }
=20
@@ -131,9 +130,8 @@ void *map_domain_page(unsigned long mfn)
                 if ( hashent->idx !=3D MAPHASHENT_NOTINUSE && !hashent->re=
fcnt )
                 {
                     idx =3D hashent->idx;
-                    ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, idx)) =3D=3D
-                           hashent->mfn);
-                    l1e_write(&DCACHE_L1ENT(dcache, idx), l1e_empty());
+                    ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) =3D=3D =
hashent->mfn);
+                    l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty());
                     hashent->idx =3D MAPHASHENT_NOTINUSE;
                     hashent->mfn =3D ~0UL;
                     break;
@@ -156,8 +154,7 @@ void *map_domain_page(unsigned long mfn)
=20
     spin_unlock(&dcache->lock);
=20
-    l1e_write(&DCACHE_L1ENT(dcache, idx),
-              l1e_from_pfn(mfn, __PAGE_HYPERVISOR));
+    l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_pfn(mfn, __PAGE_HYPERVISOR));=

=20
  out:
     local_irq_restore(flags);
@@ -181,10 +178,10 @@ void unmap_domain_page(const void *ptr)
     ASSERT(v && !is_hvm_vcpu(v));
=20
     dcache =3D &v->domain->arch.pv_domain.mapcache;
-    ASSERT(dcache->l1tab);
+    ASSERT(dcache->inuse);
=20
     idx =3D PFN_DOWN(va - MAPCACHE_VIRT_START);
-    mfn =3D l1e_get_pfn(DCACHE_L1ENT(dcache, idx));
+    mfn =3D l1e_get_pfn(MAPCACHE_L1ENT(idx));
     hashent =3D &v->arch.pv_vcpu.mapcache.hash[MAPHASH_HASHFN(mfn)];
=20
     local_irq_save(flags);
@@ -200,9 +197,9 @@ void unmap_domain_page(const void *ptr)
         if ( hashent->idx !=3D MAPHASHENT_NOTINUSE )
         {
             /* /First/, zap the PTE. */
-            ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, hashent->idx)) =3D=3D
+            ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(hashent->idx)) =3D=3D
                    hashent->mfn);
-            l1e_write(&DCACHE_L1ENT(dcache, hashent->idx), l1e_empty());
+            l1e_write(&MAPCACHE_L1ENT(hashent->idx), l1e_empty());
             /* /Second/, mark as garbage. */
             set_bit(hashent->idx, dcache->garbage);
         }
@@ -214,7 +211,7 @@ void unmap_domain_page(const void *ptr)
     else
     {
         /* /First/, zap the PTE. */
-        l1e_write(&DCACHE_L1ENT(dcache, idx), l1e_empty());
+        l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty());
         /* /Second/, mark as garbage. */
         set_bit(idx, dcache->garbage);
     }
@@ -253,10 +250,6 @@ int mapcache_domain_init(struct domain *
         return 0;
 #endif
=20
-    dcache->l1tab =3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);
-    if ( !dcache->l1tab )
-        return -ENOMEM;
-
     BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 +
                  2 * PFN_UP(BITS_TO_LONGS(MAPCACHE_ENTRIES) * sizeof(long)=
)) >
                  MAPCACHE_VIRT_START + (PERDOMAIN_SLOT_MBYTES << 20));
@@ -272,16 +265,6 @@ int mapcache_domain_init(struct domain *
                                     NIL(l1_pgentry_t *), NULL);
 }
=20
-void mapcache_domain_exit(struct domain *d)
-{
-    struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapcache;
-
-    if ( is_hvm_domain(d) )
-        return;
-
-    xfree(dcache->l1tab);
-}
-
 int mapcache_vcpu_init(struct vcpu *v)
 {
     struct domain *d =3D v->domain;
@@ -290,7 +273,7 @@ int mapcache_vcpu_init(struct vcpu *v)
     unsigned int ents =3D d->max_vcpus * MAPCACHE_VCPU_ENTRIES;
     unsigned int nr =3D PFN_UP(BITS_TO_LONGS(ents) * sizeof(long));
=20
-    if ( is_hvm_vcpu(v) || !dcache->l1tab )
+    if ( is_hvm_vcpu(v) || !dcache->inuse )
         return 0;
=20
     if ( ents > dcache->entries )
@@ -298,7 +281,7 @@ int mapcache_vcpu_init(struct vcpu *v)
         /* Populate page tables. */
         int rc =3D create_perdomain_mapping(d, MAPCACHE_VIRT_START,
                                           d->max_vcpus * MAPCACHE_VCPU_ENT=
RIES,
-                                          dcache->l1tab, NULL);
+                                          NIL(l1_pgentry_t *), NULL);
=20
         /* Populate bit maps. */
         if ( !rc )
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -53,8 +53,7 @@ struct mapcache_vcpu {
 };
=20
 struct mapcache_domain {
-    /* The PTEs that provide the mappings, and a cursor into the array. =
*/
-    l1_pgentry_t **l1tab;
+    /* The number of array entries, and a cursor into the array. */
     unsigned int entries;
     unsigned int cursor;
=20
@@ -71,7 +70,6 @@ struct mapcache_domain {
 };
=20
 int mapcache_domain_init(struct domain *);
-void mapcache_domain_exit(struct domain *);
 int mapcache_vcpu_init(struct vcpu *);
 void mapcache_override_current(struct vcpu *);
=20



--=__Part625212AA.0__=
Content-Type: text/plain; name="x86-map-domain-page-use-linear-l1.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-map-domain-page-use-linear-l1.patch"

x86: use linear L1 page table for map_domain_page() page table manipulation=
=0A=0AThis saves allocation of a Xen heap page for tracking the L1 page =
table=0Apointers.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -585,7 =
+585,6 @@ int arch_domain_create(struct domain *d,=0A     free_xenheap_page=
(d->shared_info);=0A     if ( paging_initialised )=0A         paging_final_=
teardown(d);=0A-    mapcache_domain_exit(d);=0A     free_perdomain_mappings=
(d);=0A     if ( !is_hvm_domain(d) )=0A         free_xenheap_page(d->arch.p=
v_domain.gdt_ldt_l1tab);=0A@@ -605,8 +604,6 @@ void arch_domain_destroy(str=
uct domain *=0A =0A     paging_final_teardown(d);=0A =0A-    mapcache_domai=
n_exit(d);=0A-=0A     free_perdomain_mappings(d);=0A     if ( !is_hvm_domai=
n(d) )=0A         free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);=0A---=
 a/xen/arch/x86/domain_page.c=0A+++ b/xen/arch/x86/domain_page.c=0A@@ =
-53,9 +53,8 @@ void __init mapcache_override_current(st=0A =0A #define =
mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER)=0A #define MAPCACHE_L2_ENTRIE=
S (mapcache_l2_entry(MAPCACHE_ENTRIES - 1) + 1)=0A-#define DCACHE_L1ENT(dc,=
 idx) \=0A-    ((dc)->l1tab[(idx) >> PAGETABLE_ORDER] \=0A-                =
[(idx) & ((1 << PAGETABLE_ORDER) - 1)])=0A+#define MAPCACHE_L1ENT(idx) =
\=0A+    __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + =
pfn_to_paddr(idx))]=0A =0A void *map_domain_page(unsigned long mfn)=0A =
{=0A@@ -77,7 +76,7 @@ void *map_domain_page(unsigned long mfn)=0A =0A     =
dcache =3D &v->domain->arch.pv_domain.mapcache;=0A     vcache =3D =
&v->arch.pv_vcpu.mapcache;=0A-    if ( !dcache->l1tab )=0A+    if ( =
!dcache->inuse )=0A         return mfn_to_virt(mfn);=0A =0A     perfc_incr(=
map_domain_page_count);=0A@@ -91,7 +90,7 @@ void *map_domain_page(unsigned =
long mfn)=0A         ASSERT(idx < dcache->entries);=0A         hashent->ref=
cnt++;=0A         ASSERT(hashent->refcnt);=0A-        ASSERT(l1e_get_pfn(DC=
ACHE_L1ENT(dcache, idx)) =3D=3D mfn);=0A+        ASSERT(l1e_get_pfn(MAPCACH=
E_L1ENT(idx)) =3D=3D mfn);=0A         goto out;=0A     }=0A =0A@@ -131,9 =
+130,8 @@ void *map_domain_page(unsigned long mfn)=0A                 if ( =
hashent->idx !=3D MAPHASHENT_NOTINUSE && !hashent->refcnt )=0A             =
    {=0A                     idx =3D hashent->idx;=0A-                    =
ASSERT(l1e_get_pfn(DCACHE_L1ENT(dcache, idx)) =3D=3D=0A-                   =
        hashent->mfn);=0A-                    l1e_write(&DCACHE_L1ENT(dcach=
e, idx), l1e_empty());=0A+                    ASSERT(l1e_get_pfn(MAPCACHE_L=
1ENT(idx)) =3D=3D hashent->mfn);=0A+                    l1e_write(&MAPCACHE=
_L1ENT(idx), l1e_empty());=0A                     hashent->idx =3D =
MAPHASHENT_NOTINUSE;=0A                     hashent->mfn =3D ~0UL;=0A      =
               break;=0A@@ -156,8 +154,7 @@ void *map_domain_page(unsigned =
long mfn)=0A =0A     spin_unlock(&dcache->lock);=0A =0A-    l1e_write(&DCAC=
HE_L1ENT(dcache, idx),=0A-              l1e_from_pfn(mfn, __PAGE_HYPERVISOR=
));=0A+    l1e_write(&MAPCACHE_L1ENT(idx), l1e_from_pfn(mfn, __PAGE_HYPERVI=
SOR));=0A =0A  out:=0A     local_irq_restore(flags);=0A@@ -181,10 +178,10 =
@@ void unmap_domain_page(const void *ptr)=0A     ASSERT(v && !is_hvm_vcpu(=
v));=0A =0A     dcache =3D &v->domain->arch.pv_domain.mapcache;=0A-    =
ASSERT(dcache->l1tab);=0A+    ASSERT(dcache->inuse);=0A =0A     idx =3D =
PFN_DOWN(va - MAPCACHE_VIRT_START);=0A-    mfn =3D l1e_get_pfn(DCACHE_L1ENT=
(dcache, idx));=0A+    mfn =3D l1e_get_pfn(MAPCACHE_L1ENT(idx));=0A     =
hashent =3D &v->arch.pv_vcpu.mapcache.hash[MAPHASH_HASHFN(mfn)];=0A =0A    =
 local_irq_save(flags);=0A@@ -200,9 +197,9 @@ void unmap_domain_page(const =
void *ptr)=0A         if ( hashent->idx !=3D MAPHASHENT_NOTINUSE )=0A      =
   {=0A             /* /First/, zap the PTE. */=0A-            ASSERT(l1e_g=
et_pfn(DCACHE_L1ENT(dcache, hashent->idx)) =3D=3D=0A+            ASSERT(l1e=
_get_pfn(MAPCACHE_L1ENT(hashent->idx)) =3D=3D=0A                    =
hashent->mfn);=0A-            l1e_write(&DCACHE_L1ENT(dcache, hashent->idx)=
, l1e_empty());=0A+            l1e_write(&MAPCACHE_L1ENT(hashent->idx), =
l1e_empty());=0A             /* /Second/, mark as garbage. */=0A           =
  set_bit(hashent->idx, dcache->garbage);=0A         }=0A@@ -214,7 +211,7 =
@@ void unmap_domain_page(const void *ptr)=0A     else=0A     {=0A         =
/* /First/, zap the PTE. */=0A-        l1e_write(&DCACHE_L1ENT(dcache, =
idx), l1e_empty());=0A+        l1e_write(&MAPCACHE_L1ENT(idx), l1e_empty())=
;=0A         /* /Second/, mark as garbage. */=0A         set_bit(idx, =
dcache->garbage);=0A     }=0A@@ -253,10 +250,6 @@ int mapcache_domain_init(=
struct domain *=0A         return 0;=0A #endif=0A =0A-    dcache->l1tab =
=3D xzalloc_array(l1_pgentry_t *, MAPCACHE_L2_ENTRIES);=0A-    if ( =
!dcache->l1tab )=0A-        return -ENOMEM;=0A-=0A     BUILD_BUG_ON(MAPCACH=
E_VIRT_END + PAGE_SIZE * (3 +=0A                  2 * PFN_UP(BITS_TO_LONGS(=
MAPCACHE_ENTRIES) * sizeof(long))) >=0A                  MAPCACHE_VIRT_STAR=
T + (PERDOMAIN_SLOT_MBYTES << 20));=0A@@ -272,16 +265,6 @@ int mapcache_dom=
ain_init(struct domain *=0A                                     NIL(l1_pgen=
try_t *), NULL);=0A }=0A =0A-void mapcache_domain_exit(struct domain =
*d)=0A-{=0A-    struct mapcache_domain *dcache =3D &d->arch.pv_domain.mapca=
che;=0A-=0A-    if ( is_hvm_domain(d) )=0A-        return;=0A-=0A-    =
xfree(dcache->l1tab);=0A-}=0A-=0A int mapcache_vcpu_init(struct vcpu =
*v)=0A {=0A     struct domain *d =3D v->domain;=0A@@ -290,7 +273,7 @@ int =
mapcache_vcpu_init(struct vcpu *v)=0A     unsigned int ents =3D d->max_vcpu=
s * MAPCACHE_VCPU_ENTRIES;=0A     unsigned int nr =3D PFN_UP(BITS_TO_LONGS(=
ents) * sizeof(long));=0A =0A-    if ( is_hvm_vcpu(v) || !dcache->l1tab =
)=0A+    if ( is_hvm_vcpu(v) || !dcache->inuse )=0A         return 0;=0A =
=0A     if ( ents > dcache->entries )=0A@@ -298,7 +281,7 @@ int mapcache_vc=
pu_init(struct vcpu *v)=0A         /* Populate page tables. */=0A         =
int rc =3D create_perdomain_mapping(d, MAPCACHE_VIRT_START,=0A             =
                              d->max_vcpus * MAPCACHE_VCPU_ENTRIES,=0A-    =
                                      dcache->l1tab, NULL);=0A+            =
                              NIL(l1_pgentry_t *), NULL);=0A =0A         =
/* Populate bit maps. */=0A         if ( !rc )=0A--- a/xen/include/asm-x86/=
domain.h=0A+++ b/xen/include/asm-x86/domain.h=0A@@ -53,8 +53,7 @@ struct =
mapcache_vcpu {=0A };=0A =0A struct mapcache_domain {=0A-    /* The PTEs =
that provide the mappings, and a cursor into the array. */=0A-    =
l1_pgentry_t **l1tab;=0A+    /* The number of array entries, and a cursor =
into the array. */=0A     unsigned int entries;=0A     unsigned int =
cursor;=0A =0A@@ -71,7 +70,6 @@ struct mapcache_domain {=0A };=0A =0A int =
mapcache_domain_init(struct domain *);=0A-void mapcache_domain_exit(struct =
domain *);=0A int mapcache_vcpu_init(struct vcpu *);=0A void mapcache_overr=
ide_current(struct vcpu *);=0A =0A
--=__Part625212AA.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

--=__Part625212AA.0__=--


From xen-devel-bounces@lists.xen.org Tue Feb 26 16:10:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN6i-00089A-Ok; Tue, 26 Feb 2013 16:10: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 1UAN6h-000890-Q5
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:10:20 +0000
Received: from [85.158.139.211:24930] by server-15.bemta-5.messagelabs.com id
	26/55-22815-B6EDC215; Tue, 26 Feb 2013 16:10:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361895018!15395229!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32369 invoked from network); 26 Feb 2013 16:10:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:10:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:10: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.297.1; Tue, 26 Feb 2013 16:10:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAN6e-0008CZ-Uq; Tue, 26 Feb 2013 16:10:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAN6e-0001i0-Ns;
	Tue, 26 Feb 2013 16:10:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.56936.286553.55976@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:10:16 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512CBF3E02000078000C1136@nat28.tlf.novell.com>
References: <osstest-16690-mainreport@xen.org>
	<512CBF3E02000078000C1136@nat28.tlf.novell.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-testing test] 16690: 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

Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 16690: regressions - FAIL"):
> The kernel build didn't even start when these failed, yet the
> real reason for the failure also isn't clear to me. Trying to glue
> together the matching pieces, I think is goes like this:
> 
...
> Cloning http://xenbits.xen.org/linux-2.6.18-xen.hg to linux-2.6.18-xen.hg.
> ...
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> transaction abort!
> rollback completed
> abort: Connection reset by peer
> make[2]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
> make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 255
> make[1]: *** [linux-2.6-xen-install] Error 2
> make: *** [install-kernels] Error 1
> make[1]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
> 
> The odd thing being that neither 4.1 nor master had similar
> problems in their tests. Do we simply need to wait for another
> run?

This is indeed odd.  I'm hoping it's a network glitch and that hg is
simply printing its messages in a funny order.  In which case the next
run ought to work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:10:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UAN6i-00089A-Ok; Tue, 26 Feb 2013 16:10: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 1UAN6h-000890-Q5
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:10:20 +0000
Received: from [85.158.139.211:24930] by server-15.bemta-5.messagelabs.com id
	26/55-22815-B6EDC215; Tue, 26 Feb 2013 16:10:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361895018!15395229!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32369 invoked from network); 26 Feb 2013 16:10:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:10:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:10: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.297.1; Tue, 26 Feb 2013 16:10:17 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAN6e-0008CZ-Uq; Tue, 26 Feb 2013 16:10:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAN6e-0001i0-Ns;
	Tue, 26 Feb 2013 16:10:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.56936.286553.55976@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:10:16 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512CBF3E02000078000C1136@nat28.tlf.novell.com>
References: <osstest-16690-mainreport@xen.org>
	<512CBF3E02000078000C1136@nat28.tlf.novell.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-testing test] 16690: 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

Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 16690: regressions - FAIL"):
> The kernel build didn't even start when these failed, yet the
> real reason for the failure also isn't clear to me. Trying to glue
> together the matching pieces, I think is goes like this:
> 
...
> Cloning http://xenbits.xen.org/linux-2.6.18-xen.hg to linux-2.6.18-xen.hg.
> ...
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> transaction abort!
> rollback completed
> abort: Connection reset by peer
> make[2]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
> make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 255
> make[1]: *** [linux-2.6-xen-install] Error 2
> make: *** [install-kernels] Error 1
> make[1]: Leaving directory `/home/osstest/build.16690.build-i386-oldkern/xen-unstable'
> 
> The odd thing being that neither 4.1 nor master had similar
> problems in their tests. Do we simply need to wait for another
> run?

This is indeed odd.  I'm hoping it's a network glitch and that hg is
simply printing its messages in a funny order.  In which case the next
run ought to work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:14:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANAk-0008Tj-G3; Tue, 26 Feb 2013 16:14: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 1UANAj-0008Td-5p
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:14:29 +0000
Received: from [85.158.137.99:62990] by server-10.bemta-3.messagelabs.com id
	4B/D6-10609-46FDC215; Tue, 26 Feb 2013 16:14:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361895266!17351467!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7432 invoked from network); 26 Feb 2013 16:14:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16: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.297.1; Tue, 26 Feb 2013 16:14:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANAg-0008DA-2Q; Tue, 26 Feb 2013 16:14:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANAf-0001ie-T1;
	Tue, 26 Feb 2013 16:14:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.57185.786644.525993@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:14:25 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th	e bootup
	section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

S29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB0byBYODYg
UFYgTU1VIFdpa2kgdjJdIEV4cGFuZCB0aCBlIGJvb3R1cCBzZWN0aW9uIHRvIGluY2x1ZGUgRUxG
IGFuZCBtZW1vcnkgbGF5b3V0Iik6Cj4gdjI6IEludGVncmF0ZSBJYW4ncyBjb21tZW50cy4KClRo
ZXJlIGFyZSBzb21lIGZvcm1hdHRpbmcgb2RkaXRpZXMgaW4gdGhpczoKCj4gKwo+ICtXaGVuIGd1
ZXN0IGhhcyBzdGFydGVkLCB0aGUga2VybmVsIGltYWdlIGlzIHJlYWQgYW5kIHRoZSBFTEYgKFBU
X05PVEUpIHByb2dyYW0gaXMKClRoaXMgbGluZSBpcyB0b28gbG9uZyBmb3IgYSAudHh0IGZpbGU7
IGl0IHNob3VkbCBiZSA3MCBvciBtYXliZSA3NS4KVGhpcyBpcyBhIHByb2JsZW0gdGhyb3VnaG91
dCB0aGUgZmlsZS4KCj4gK3BhcnNlZC5UaGUgaHlwZXJ2aXNvciBsb29rcyBpbiB0aGUgLm5vdGUg
c2VjdGlvbnMKCkFuZCBoZXJlIGlzIGEgbWlzc2luZyBwc3BhY2UuCgo+ICtjYW4gc3VwcG9ydCwg
YW5kIHRoZSBsb2NhdGlvbiBvZiB0aGUgaHlwZXJjYWxsIHBhZ2UuIFRoZXJlIGFyZSB0d28gdmFy
aWFudHMgb2YgdGhpczoKPiArCj4gKzsgYSkuIEEg4oCcLm5vdGUuWGVu4oCdIHNlY3Rpb24gaW4g
RUxGIGhlYWRlciBjb25mb3JtaW5nIHRvIHRoZSBFTEYgUFRfTk9URSBmb3JtYXQuCgpXaGF0J3Mg
dGhlIHNlbWljb2xvbiBmb3IgPwoKWW91ciBmaWxlIGhhcyBzb21lIGtpbmQgb2YgaGlnaC1iaXQt
c2V0IGNoYXJhY3RlcnMgaW4gaXQgd2hpY2ggSSBkb24ndAp0aGluayBhcmUgZGVzaXJhYmxlIGhl
cmUgPwoKSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:14:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANAk-0008Tj-G3; Tue, 26 Feb 2013 16:14: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 1UANAj-0008Td-5p
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:14:29 +0000
Received: from [85.158.137.99:62990] by server-10.bemta-3.messagelabs.com id
	4B/D6-10609-46FDC215; Tue, 26 Feb 2013 16:14:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361895266!17351467!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7432 invoked from network); 26 Feb 2013 16:14:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16: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.297.1; Tue, 26 Feb 2013 16:14:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANAg-0008DA-2Q; Tue, 26 Feb 2013 16:14:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANAf-0001ie-T1;
	Tue, 26 Feb 2013 16:14:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.57185.786644.525993@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:14:25 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.campbel@citrix.com
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th	e bootup
	section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

S29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB0byBYODYg
UFYgTU1VIFdpa2kgdjJdIEV4cGFuZCB0aCBlIGJvb3R1cCBzZWN0aW9uIHRvIGluY2x1ZGUgRUxG
IGFuZCBtZW1vcnkgbGF5b3V0Iik6Cj4gdjI6IEludGVncmF0ZSBJYW4ncyBjb21tZW50cy4KClRo
ZXJlIGFyZSBzb21lIGZvcm1hdHRpbmcgb2RkaXRpZXMgaW4gdGhpczoKCj4gKwo+ICtXaGVuIGd1
ZXN0IGhhcyBzdGFydGVkLCB0aGUga2VybmVsIGltYWdlIGlzIHJlYWQgYW5kIHRoZSBFTEYgKFBU
X05PVEUpIHByb2dyYW0gaXMKClRoaXMgbGluZSBpcyB0b28gbG9uZyBmb3IgYSAudHh0IGZpbGU7
IGl0IHNob3VkbCBiZSA3MCBvciBtYXliZSA3NS4KVGhpcyBpcyBhIHByb2JsZW0gdGhyb3VnaG91
dCB0aGUgZmlsZS4KCj4gK3BhcnNlZC5UaGUgaHlwZXJ2aXNvciBsb29rcyBpbiB0aGUgLm5vdGUg
c2VjdGlvbnMKCkFuZCBoZXJlIGlzIGEgbWlzc2luZyBwc3BhY2UuCgo+ICtjYW4gc3VwcG9ydCwg
YW5kIHRoZSBsb2NhdGlvbiBvZiB0aGUgaHlwZXJjYWxsIHBhZ2UuIFRoZXJlIGFyZSB0d28gdmFy
aWFudHMgb2YgdGhpczoKPiArCj4gKzsgYSkuIEEg4oCcLm5vdGUuWGVu4oCdIHNlY3Rpb24gaW4g
RUxGIGhlYWRlciBjb25mb3JtaW5nIHRvIHRoZSBFTEYgUFRfTk9URSBmb3JtYXQuCgpXaGF0J3Mg
dGhlIHNlbWljb2xvbiBmb3IgPwoKWW91ciBmaWxlIGhhcyBzb21lIGtpbmQgb2YgaGlnaC1iaXQt
c2V0IGNoYXJhY3RlcnMgaW4gaXQgd2hpY2ggSSBkb24ndAp0aGluayBhcmUgZGVzaXJhYmxlIGhl
cmUgPwoKSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:17:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANDY-00009r-4f; Tue, 26 Feb 2013 16:17: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 1UANDW-00009h-BQ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:17:22 +0000
Received: from [85.158.139.83:17773] by server-1.bemta-5.messagelabs.com id
	04/A3-14063-110EC215; Tue, 26 Feb 2013 16:17:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361895400!25150930!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22079 invoked from network); 26 Feb 2013 16:16:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16: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.297.1; Tue, 26 Feb 2013 16:16:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANCp-0008Df-Si; Tue, 26 Feb 2013 16:16:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANCp-0001kq-O5;
	Tue, 26 Feb 2013 16:16:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.57319.498343.911556@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:16:39 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20130225170034.GB10673@phenom.dumpdata.com>
References: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
	<1361810590.26546.196.camel@zakaz.uk.xensource.com>
	<20130225170034.GB10673@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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] [PATCH] libxl: Made it possible to use 'timer='delay_for_missed_ticks'"):
> On Mon, Feb 25, 2013 at 04:43:10PM +0000, Ian Campbell wrote:
> > Doh! That was very likely a brainfart by me...
> 
> And by me in the git commit description :-(

Heh.

> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 25 Feb 2013 11:30:18 -0500
> Subject: [PATCH] libxl: Made it possible to use
>  'timer='delay_for_missed_ticks'
> 
> The assertion only allows values of 1 (no_delay_for_missed_ticks)
> up to 3 (one_missed_tick_pending). It should be possible to
> use the value of 0 (delay_for_missed_ticks) for the timer configuration
> option.
> 
> Acked-by: Ian Campbell <ian.cambell@citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, 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 Feb 26 16:17:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANDY-00009r-4f; Tue, 26 Feb 2013 16:17: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 1UANDW-00009h-BQ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:17:22 +0000
Received: from [85.158.139.83:17773] by server-1.bemta-5.messagelabs.com id
	04/A3-14063-110EC215; Tue, 26 Feb 2013 16:17:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361895400!25150930!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22079 invoked from network); 26 Feb 2013 16:16:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16: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.297.1; Tue, 26 Feb 2013 16:16:40 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANCp-0008Df-Si; Tue, 26 Feb 2013 16:16:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANCp-0001kq-O5;
	Tue, 26 Feb 2013 16:16:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.57319.498343.911556@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:16:39 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20130225170034.GB10673@phenom.dumpdata.com>
References: <1361810010-10340-1-git-send-email-konrad.wilk@oracle.com>
	<1361810590.26546.196.camel@zakaz.uk.xensource.com>
	<20130225170034.GB10673@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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: Made it possible to use
 'timer='delay_for_missed_ticks'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] [PATCH] libxl: Made it possible to use 'timer='delay_for_missed_ticks'"):
> On Mon, Feb 25, 2013 at 04:43:10PM +0000, Ian Campbell wrote:
> > Doh! That was very likely a brainfart by me...
> 
> And by me in the git commit description :-(

Heh.

> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 25 Feb 2013 11:30:18 -0500
> Subject: [PATCH] libxl: Made it possible to use
>  'timer='delay_for_missed_ticks'
> 
> The assertion only allows values of 1 (no_delay_for_missed_ticks)
> up to 3 (one_missed_tick_pending). It should be possible to
> use the value of 0 (delay_for_missed_ticks) for the timer configuration
> option.
> 
> Acked-by: Ian Campbell <ian.cambell@citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied, 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 Feb 26 16:28:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:28: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 1UANNq-0000Qw-J6; Tue, 26 Feb 2013 16:28: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 1UANNo-0000Qr-HS
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:28:00 +0000
Received: from [85.158.137.99:39951] by server-12.bemta-3.messagelabs.com id
	D4/E9-05889-F82EC215; Tue, 26 Feb 2013 16:27:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361896078!12569723!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12170 invoked from network); 26 Feb 2013 16:27:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:27:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:27: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.297.1; Tue, 26 Feb 2013 16:27:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANNm-0008KU-9P; Tue, 26 Feb 2013 16:27:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANNm-0001lj-3S;
	Tue, 26 Feb 2013 16:27:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.57998.10366.750860@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:27:58 +0000
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH v2] tools: Improve make deb"):
> Changes from v1:
> - Added on description that this make a build for testing only.
> - Improved add/remove of main service.

I'm not convinced that this is a good idea.

Firstly, the point of the "make deb" target is not to provide a
proper, fully featured, Debian binary package.  That work should be
done in Debian.

The point of our `make deb' is to provide a simple way for people
using Debian-derived systems to get the bits onto their disk and
remove them again afterwards.

> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 2e40747..fe7e1b1 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -33,7 +33,7 @@ fi
>  # Fill in the debian boilerplate
>  mkdir -p deb/DEBIAN
>  cat >deb/DEBIAN/control <<EOF
> -Package: xen-upstream-$version
> +Package: xen-upstream

I don't object to this change because they're not coinstallable
anyway.

> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF

This is fine too IMO but it should be done with
"find -type f" rather than listing these files explicitly.

> +cat >deb/DEBIAN/postinst <<EOF
> +#!/bin/bash -e
> +insserv xencommons &&
> +insserv xendomains
> +EOF
> +cat >deb/DEBIAN/postrm <<EOF
> +#!/bin/bash -e
> +insserv -r xendomains &&
> +insserv -r xencommons
>  EOF

I do object to these.  "Getting the bits onto your system" doesn't
include automatically starting the daemons.

(Others have pointed out that this isn't the way to do it, anyway.)

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 Feb 26 16:28:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:28: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 1UANNq-0000Qw-J6; Tue, 26 Feb 2013 16:28: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 1UANNo-0000Qr-HS
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:28:00 +0000
Received: from [85.158.137.99:39951] by server-12.bemta-3.messagelabs.com id
	D4/E9-05889-F82EC215; Tue, 26 Feb 2013 16:27:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361896078!12569723!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12170 invoked from network); 26 Feb 2013 16:27:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:27:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:27: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.297.1; Tue, 26 Feb 2013 16:27:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANNm-0008KU-9P; Tue, 26 Feb 2013 16:27:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANNm-0001lj-3S;
	Tue, 26 Feb 2013 16:27:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.57998.10366.750860@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:27:58 +0000
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH v2] tools: Improve make deb"):
> Changes from v1:
> - Added on description that this make a build for testing only.
> - Improved add/remove of main service.

I'm not convinced that this is a good idea.

Firstly, the point of the "make deb" target is not to provide a
proper, fully featured, Debian binary package.  That work should be
done in Debian.

The point of our `make deb' is to provide a simple way for people
using Debian-derived systems to get the bits onto their disk and
remove them again afterwards.

> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 2e40747..fe7e1b1 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -33,7 +33,7 @@ fi
>  # Fill in the debian boilerplate
>  mkdir -p deb/DEBIAN
>  cat >deb/DEBIAN/control <<EOF
> -Package: xen-upstream-$version
> +Package: xen-upstream

I don't object to this change because they're not coinstallable
anyway.

> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF

This is fine too IMO but it should be done with
"find -type f" rather than listing these files explicitly.

> +cat >deb/DEBIAN/postinst <<EOF
> +#!/bin/bash -e
> +insserv xencommons &&
> +insserv xendomains
> +EOF
> +cat >deb/DEBIAN/postrm <<EOF
> +#!/bin/bash -e
> +insserv -r xendomains &&
> +insserv -r xencommons
>  EOF

I do object to these.  "Getting the bits onto your system" doesn't
include automatically starting the daemons.

(Others have pointed out that this isn't the way to do it, anyway.)

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 Feb 26 16:28:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANNy-0000Ri-5d; Tue, 26 Feb 2013 16:28: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 1UANNw-0000Ra-Bu
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:28:08 +0000
Received: from [85.158.139.83:14448] by server-5.bemta-5.messagelabs.com id
	1B/D6-02762-792EC215; Tue, 26 Feb 2013 16:28:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361896086!25153169!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9148 invoked from network); 26 Feb 2013 16:28:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:28:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:28: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.297.1;
	Tue, 26 Feb 2013 16:28:06 +0000
Message-ID: <1361896085.26546.307.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Feb 2013 16:28:05 +0000
In-Reply-To: <20130225190720.GB12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> > On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > > And also put my name behind the mainternship.
> > 
> > I think you could also safely remove Jeremy these days?
> > 
> > Maybe we should have a Linux style CREDITS file to retain the names of
> > historical contributors/maintainers?
> 
> Like this:
> 
> From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 25 Feb 2013 14:04:55 -0500
> Subject: [PATCH] CREDITS: First checkin.
> 
> Adding Jeremy and moving him from the MAINTAINERS file.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  CREDITS     | 16 ++++++++++++++++
>  MAINTAINERS |  1 -

This hunk bit wasn't in the patch and didn't make it into the commit
IanJ just made?

>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 CREDITS
> 
> diff --git a/CREDITS b/CREDITS
> new file mode 100644
> index 0000000..eaf05bf
> --- /dev/null
> +++ b/CREDITS
> @@ -0,0 +1,16 @@
> +    This is at least a partial credits-file of people that have
> +    contributed to the Xen project.  It is sorted by name and
> +    formatted to allow easy grepping and beautification by
> +    scripts.  The fields are: name (N), email (E), web-address
> +    (W), PGP key ID and fingerprint (P), description (D), and
> +    snail-mail address (S).
> +    Thanks,
> +
> +            Xen team
> +----------
> +
> +N: Jeremy Fitzhardinge
> +E: jeremy@goop.org
> +W: http://www.goop.org/~jeremy
> +P: 1B40B6D0
> +D: Linux pvops
> 
> I didn't put his physical address b/c I don't know if he would like
> it there?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:28:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANNy-0000Ri-5d; Tue, 26 Feb 2013 16:28: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 1UANNw-0000Ra-Bu
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:28:08 +0000
Received: from [85.158.139.83:14448] by server-5.bemta-5.messagelabs.com id
	1B/D6-02762-792EC215; Tue, 26 Feb 2013 16:28:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361896086!25153169!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9148 invoked from network); 26 Feb 2013 16:28:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:28:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1910934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:28: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.297.1;
	Tue, 26 Feb 2013 16:28:06 +0000
Message-ID: <1361896085.26546.307.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Feb 2013 16:28:05 +0000
In-Reply-To: <20130225190720.GB12258@phenom.dumpdata.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
> > On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
> > > And also put my name behind the mainternship.
> > 
> > I think you could also safely remove Jeremy these days?
> > 
> > Maybe we should have a Linux style CREDITS file to retain the names of
> > historical contributors/maintainers?
> 
> Like this:
> 
> From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 25 Feb 2013 14:04:55 -0500
> Subject: [PATCH] CREDITS: First checkin.
> 
> Adding Jeremy and moving him from the MAINTAINERS file.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  CREDITS     | 16 ++++++++++++++++
>  MAINTAINERS |  1 -

This hunk bit wasn't in the patch and didn't make it into the commit
IanJ just made?

>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 CREDITS
> 
> diff --git a/CREDITS b/CREDITS
> new file mode 100644
> index 0000000..eaf05bf
> --- /dev/null
> +++ b/CREDITS
> @@ -0,0 +1,16 @@
> +    This is at least a partial credits-file of people that have
> +    contributed to the Xen project.  It is sorted by name and
> +    formatted to allow easy grepping and beautification by
> +    scripts.  The fields are: name (N), email (E), web-address
> +    (W), PGP key ID and fingerprint (P), description (D), and
> +    snail-mail address (S).
> +    Thanks,
> +
> +            Xen team
> +----------
> +
> +N: Jeremy Fitzhardinge
> +E: jeremy@goop.org
> +W: http://www.goop.org/~jeremy
> +P: 1B40B6D0
> +D: Linux pvops
> 
> I didn't put his physical address b/c I don't know if he would like
> it there?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:29:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:29: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 1UANOp-0000WY-Kh; Tue, 26 Feb 2013 16:29:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UANOo-0000WO-Ry
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:29:02 +0000
Received: from [85.158.139.83:27322] by server-6.bemta-5.messagelabs.com id
	03/C1-21466-EC2EC215; Tue, 26 Feb 2013 16:29:02 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361896141!25153318!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14181 invoked from network); 26 Feb 2013 16:29:01 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 16:29:01 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UANOm-0004sR-1L; Tue, 26 Feb 2013 17:29:00 +0100
Message-ID: <512CE2C6.3040907@mfiala.net>
Date: Tue, 26 Feb 2013 17:28:54 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
In-Reply-To: <512CEB5C02000078000C1272@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 kernel command line from grub.conf

kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
console=com2,vga com2=115200,8n1
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0

I have not modified reboot type.

On 02/26/2013 05:05 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>> without problem. When I run reboot or shutdown -r now, system correctly
>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>> I have the same problem with kernel linux 3.2.37. When I shudown system
>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>> xen hypervisor, it was without problems. Required debug informations
>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>> Could you please help me with this problem?
> 
> It's apparently going the triple fault path, and load_idt() under Xen
> doesn't do what the code here expects (i.e. that reboot method
> just can't work under Xen). Are you overriding the reboot type on
> the kernel command line?
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:29:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:29: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 1UANOp-0000WY-Kh; Tue, 26 Feb 2013 16:29:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UANOo-0000WO-Ry
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:29:02 +0000
Received: from [85.158.139.83:27322] by server-6.bemta-5.messagelabs.com id
	03/C1-21466-EC2EC215; Tue, 26 Feb 2013 16:29:02 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361896141!25153318!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14181 invoked from network); 26 Feb 2013 16:29:01 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-6.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 16:29:01 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UANOm-0004sR-1L; Tue, 26 Feb 2013 17:29:00 +0100
Message-ID: <512CE2C6.3040907@mfiala.net>
Date: Tue, 26 Feb 2013 17:28:54 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
In-Reply-To: <512CEB5C02000078000C1272@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 kernel command line from grub.conf

kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
console=com2,vga com2=115200,8n1
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0

I have not modified reboot type.

On 02/26/2013 05:05 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>> without problem. When I run reboot or shutdown -r now, system correctly
>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>> I have the same problem with kernel linux 3.2.37. When I shudown system
>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>> xen hypervisor, it was without problems. Required debug informations
>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>> Could you please help me with this problem?
> 
> It's apparently going the triple fault path, and load_idt() under Xen
> doesn't do what the code here expects (i.e. that reboot method
> just can't work under Xen). Are you overriding the reboot type on
> the kernel command line?
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:34:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UANTj-0000v2-DT; Tue, 26 Feb 2013 16:34:07 +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 1UANTi-0000uw-2g
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:34:06 +0000
Received: from [85.158.139.83:44319] by server-4.bemta-5.messagelabs.com id
	4D/32-01980-DF3EC215; Tue, 26 Feb 2013 16:34:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361896409!26318635!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20862 invoked from network); 26 Feb 2013 16:33:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:33:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:33:29 +0000
Message-Id: <512CF1E702000078000C12C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:33:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
In-Reply-To: <512CE2C6.3040907@mfiala.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:

Please don't top post.

> The kernel command line from grub.conf
> 
> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
> console=com2,vga com2=115200,8n1
> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
> 
> I have not modified reboot type.

And did you check your full boot log for an info-level message like

"%s series board detected. Selecting %s-method for reboot.\n"

Jan

> On 02/26/2013 05:05 PM, Jan Beulich wrote:
>>>>> On 26.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
>>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>>> without problem. When I run reboot or shutdown -r now, system correctly
>>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>>> I have the same problem with kernel linux 3.2.37. When I shudown system
>>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>>> xen hypervisor, it was without problems. Required debug informations
>>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>>> Could you please help me with this problem?
>> 
>> It's apparently going the triple fault path, and load_idt() under Xen
>> doesn't do what the code here expects (i.e. that reboot method
>> just can't work under Xen). Are you overriding the reboot type on
>> the kernel command line?
>> 
>> Jan
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:34:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UANTj-0000v2-DT; Tue, 26 Feb 2013 16:34:07 +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 1UANTi-0000uw-2g
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:34:06 +0000
Received: from [85.158.139.83:44319] by server-4.bemta-5.messagelabs.com id
	4D/32-01980-DF3EC215; Tue, 26 Feb 2013 16:34:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361896409!26318635!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20862 invoked from network); 26 Feb 2013 16:33:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:33:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:33:29 +0000
Message-Id: <512CF1E702000078000C12C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:33:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
In-Reply-To: <512CE2C6.3040907@mfiala.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:

Please don't top post.

> The kernel command line from grub.conf
> 
> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
> console=com2,vga com2=115200,8n1
> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
> 
> I have not modified reboot type.

And did you check your full boot log for an info-level message like

"%s series board detected. Selecting %s-method for reboot.\n"

Jan

> On 02/26/2013 05:05 PM, Jan Beulich wrote:
>>>>> On 26.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
>>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>>> without problem. When I run reboot or shutdown -r now, system correctly
>>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>>> I have the same problem with kernel linux 3.2.37. When I shudown system
>>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>>> xen hypervisor, it was without problems. Required debug informations
>>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>>> Could you please help me with this problem?
>> 
>> It's apparently going the triple fault path, and load_idt() under Xen
>> doesn't do what the code here expects (i.e. that reboot method
>> just can't work under Xen). Are you overriding the reboot type on
>> the kernel command line?
>> 
>> Jan
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:42:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:42: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 1UANc2-00018u-FO; Tue, 26 Feb 2013 16:42:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UANc1-00018p-0O
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:42:41 +0000
Received: from [193.109.254.147:9310] by server-4.bemta-14.messagelabs.com id
	99/4E-20719-006EC215; Tue, 26 Feb 2013 16:42:40 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361896838!4168953!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12747 invoked from network); 26 Feb 2013 16:40:39 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 16:40:39 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UANa2-0002uy-EI; Tue, 26 Feb 2013 17:40:38 +0100
Message-ID: <512CE581.7020308@mfiala.net>
Date: Tue, 26 Feb 2013 17:40:33 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
In-Reply-To: <512CF1E702000078000C12C7@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/26/2013 05:33 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
> 
> Please don't top post.
> 
>> The kernel command line from grub.conf
>>
>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
>> console=com2,vga com2=115200,8n1
>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
>>
>> I have not modified reboot type.
> 
> And did you check your full boot log for an info-level message like
> 
> "%s series board detected. Selecting %s-method for reboot.\n"

I have only checked normal boot log, see attachment in my first mail.
How can I enable info-level message?

> 
> Jan
> 
>> On 02/26/2013 05:05 PM, Jan Beulich wrote:
>>>>>> On 26.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
>>>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>>>> without problem. When I run reboot or shutdown -r now, system correctly
>>>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>>>> I have the same problem with kernel linux 3.2.37. When I shudown system
>>>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>>>> xen hypervisor, it was without problems. Required debug informations
>>>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>>>> Could you please help me with this problem?
>>>
>>> It's apparently going the triple fault path, and load_idt() under Xen
>>> doesn't do what the code here expects (i.e. that reboot method
>>> just can't work under Xen). Are you overriding the reboot type on
>>> the kernel command line?
>>>
>>> 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 Tue Feb 26 16:42:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:42: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 1UANc2-00018u-FO; Tue, 26 Feb 2013 16:42:42 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UANc1-00018p-0O
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:42:41 +0000
Received: from [193.109.254.147:9310] by server-4.bemta-14.messagelabs.com id
	99/4E-20719-006EC215; Tue, 26 Feb 2013 16:42:40 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-6.tower-27.messagelabs.com!1361896838!4168953!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12747 invoked from network); 26 Feb 2013 16:40:39 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-6.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 16:40:39 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UANa2-0002uy-EI; Tue, 26 Feb 2013 17:40:38 +0100
Message-ID: <512CE581.7020308@mfiala.net>
Date: Tue, 26 Feb 2013 17:40:33 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
In-Reply-To: <512CF1E702000078000C12C7@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/26/2013 05:33 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
> 
> Please don't top post.
> 
>> The kernel command line from grub.conf
>>
>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
>> console=com2,vga com2=115200,8n1
>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
>>
>> I have not modified reboot type.
> 
> And did you check your full boot log for an info-level message like
> 
> "%s series board detected. Selecting %s-method for reboot.\n"

I have only checked normal boot log, see attachment in my first mail.
How can I enable info-level message?

> 
> Jan
> 
>> On 02/26/2013 05:05 PM, Jan Beulich wrote:
>>>>>> On 26.02.13 at 15:32, Michal Fiala <fiala@mfiala.net> wrote:
>>>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>>>> without problem. When I run reboot or shutdown -r now, system correctly
>>>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>>>> I have the same problem with kernel linux 3.2.37. When I shudown system
>>>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>>>> xen hypervisor, it was without problems. Required debug informations
>>>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>>>> Could you please help me with this problem?
>>>
>>> It's apparently going the triple fault path, and load_idt() under Xen
>>> doesn't do what the code here expects (i.e. that reboot method
>>> just can't work under Xen). Are you overriding the reboot type on
>>> the kernel command line?
>>>
>>> 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 Tue Feb 26 16:43:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:43: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 1UANcw-0001Bj-UV; Tue, 26 Feb 2013 16:43:38 +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 1UANcv-0001Ba-Ob
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:43:37 +0000
Received: from [85.158.137.99:25763] by server-15.bemta-3.messagelabs.com id
	9F/AF-25405-836EC215; Tue, 26 Feb 2013 16:43:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361897016!13083501!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18385 invoked from network); 26 Feb 2013 16:43:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:43:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1911570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:42: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.297.1; Tue, 26 Feb 2013 16:42:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANbw-0008Nu-Qm; Tue, 26 Feb 2013 16:42:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANbw-0001mh-MO;
	Tue, 26 Feb 2013 16:42:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.58876.591829.819409@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:42:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361896085.26546.307.camel@zakaz.uk.xensource.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
	<1361896085.26546.307.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="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] MAINTAINERS: Provide proper URL to the upstream Linux development tree for Xen."):
> On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  CREDITS     | 16 ++++++++++++++++
> >  MAINTAINERS |  1 -
> 
> This hunk bit wasn't in the patch and didn't make it into the commit
> IanJ just made?

I haven't made any commit to CREDITS or MAINTAINERS...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:43:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:43: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 1UANcw-0001Bj-UV; Tue, 26 Feb 2013 16:43:38 +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 1UANcv-0001Ba-Ob
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:43:37 +0000
Received: from [85.158.137.99:25763] by server-15.bemta-3.messagelabs.com id
	9F/AF-25405-836EC215; Tue, 26 Feb 2013 16:43:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361897016!13083501!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18385 invoked from network); 26 Feb 2013 16:43:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:43:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1911570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:42: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.297.1; Tue, 26 Feb 2013 16:42:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UANbw-0008Nu-Qm; Tue, 26 Feb 2013 16:42:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UANbw-0001mh-MO;
	Tue, 26 Feb 2013 16:42:36 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.58876.591829.819409@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 16:42:36 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361896085.26546.307.camel@zakaz.uk.xensource.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
	<1361896085.26546.307.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="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] MAINTAINERS: Provide proper URL to the upstream Linux development tree for Xen."):
> On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  CREDITS     | 16 ++++++++++++++++
> >  MAINTAINERS |  1 -
> 
> This hunk bit wasn't in the patch and didn't make it into the commit
> IanJ just made?

I haven't made any commit to CREDITS or MAINTAINERS...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:44:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANdU-0001F9-Cu; Tue, 26 Feb 2013 16:44: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 1UANdS-0001Eu-PJ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:44:10 +0000
Received: from [85.158.139.211:37112] by server-4.bemta-5.messagelabs.com id
	F3/63-01980-956EC215; Tue, 26 Feb 2013 16:44:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361897049!18447960!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2535 invoked from network); 26 Feb 2013 16:44:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:44:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1911610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:44: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.297.1;
	Tue, 26 Feb 2013 16:44:09 +0000
Message-ID: <1361897047.26546.308.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 16:44:07 +0000
In-Reply-To: <20780.58876.591829.819409@mariner.uk.xensource.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
	<1361896085.26546.307.camel@zakaz.uk.xensource.com>
	<20780.58876.591829.819409@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 16:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the upstream Linux development tree for Xen."):
> > On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  CREDITS     | 16 ++++++++++++++++
> > >  MAINTAINERS |  1 -
> > 
> > This hunk bit wasn't in the patch and didn't make it into the commit
> > IanJ just made?
> 
> I haven't made any commit to CREDITS or MAINTAINERS...

Sorry, it was actually Keir.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:44:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANdU-0001F9-Cu; Tue, 26 Feb 2013 16:44: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 1UANdS-0001Eu-PJ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:44:10 +0000
Received: from [85.158.139.211:37112] by server-4.bemta-5.messagelabs.com id
	F3/63-01980-956EC215; Tue, 26 Feb 2013 16:44:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361897049!18447960!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2535 invoked from network); 26 Feb 2013 16:44:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:44:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1911610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 16:44: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.297.1;
	Tue, 26 Feb 2013 16:44:09 +0000
Message-ID: <1361897047.26546.308.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 16:44:07 +0000
In-Reply-To: <20780.58876.591829.819409@mariner.uk.xensource.com>
References: <1361810165-10431-1-git-send-email-konrad.wilk@oracle.com>
	<1361811390.26546.205.camel@zakaz.uk.xensource.com>
	<20130225190720.GB12258@phenom.dumpdata.com>
	<1361896085.26546.307.camel@zakaz.uk.xensource.com>
	<20780.58876.591829.819409@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 16:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the upstream Linux development tree for Xen."):
> > On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  CREDITS     | 16 ++++++++++++++++
> > >  MAINTAINERS |  1 -
> > 
> > This hunk bit wasn't in the patch and didn't make it into the commit
> > IanJ just made?
> 
> I haven't made any commit to CREDITS or MAINTAINERS...

Sorry, it was actually Keir.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:45:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:45: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 1UANeQ-0001LL-Rc; Tue, 26 Feb 2013 16:45: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 1UANeP-0001Kz-KD
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:45:09 +0000
Received: from [85.158.139.211:26521] by server-3.bemta-5.messagelabs.com id
	89/31-17256-496EC215; Tue, 26 Feb 2013 16:45:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361897106!18448163!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6938 invoked from network); 26 Feb 2013 16:45:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:45:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9266945"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 16:45:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 11:45:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UANeL-0008Js-34;
	Tue, 26 Feb 2013 16:45:05 +0000
Date: Tue, 26 Feb 2013 16:45:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20780.57998.10366.750860@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Ian Jackson wrote:
> Firstly, the point of the "make deb" target is not to provide a
> proper, fully featured, Debian binary package.  That work should be
> done in Debian.

If we are allowing people to build a deb package from xen-unstable we
should do it right.
Also there are many reasons why somebody would want to rebuild his
own Xen package from xen-unstable instead of the deb source.


> I do object to these.  "Getting the bits onto your system" doesn't
> include automatically starting the daemons.

No matter what we think the objective of the deb target is, it cannot be
an excuse to do only half of the job.
Even if it is just for testing, I would want the init scripts to
be started automatically on my testbox, why should I do that manually?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:45:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:45: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 1UANeQ-0001LL-Rc; Tue, 26 Feb 2013 16:45: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 1UANeP-0001Kz-KD
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:45:09 +0000
Received: from [85.158.139.211:26521] by server-3.bemta-5.messagelabs.com id
	89/31-17256-496EC215; Tue, 26 Feb 2013 16:45:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361897106!18448163!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6938 invoked from network); 26 Feb 2013 16:45:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:45:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9266945"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 16:45:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 11:45:05 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UANeL-0008Js-34;
	Tue, 26 Feb 2013 16:45:05 +0000
Date: Tue, 26 Feb 2013 16:45:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20780.57998.10366.750860@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Ian Jackson wrote:
> Firstly, the point of the "make deb" target is not to provide a
> proper, fully featured, Debian binary package.  That work should be
> done in Debian.

If we are allowing people to build a deb package from xen-unstable we
should do it right.
Also there are many reasons why somebody would want to rebuild his
own Xen package from xen-unstable instead of the deb source.


> I do object to these.  "Getting the bits onto your system" doesn't
> include automatically starting the daemons.

No matter what we think the objective of the deb target is, it cannot be
an excuse to do only half of the job.
Even if it is just for testing, I would want the init scripts to
be started automatically on my testbox, why should I do that manually?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:52:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANkp-0001jV-Ni; Tue, 26 Feb 2013 16:51:47 +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 1UANko-0001jQ-GT
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:51:46 +0000
Received: from [85.158.139.83:39001] by server-5.bemta-5.messagelabs.com id
	B7/6D-02762-128EC215; Tue, 26 Feb 2013 16:51:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361897503!21859760!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2478 invoked from network); 26 Feb 2013 16:51:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:51:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:51:43 +0000
Message-Id: <512CF62C02000078000C12F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:51:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
In-Reply-To: <512CE581.7020308@mfiala.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:40, Michal Fiala <fiala@mfiala.net> wrote:
> On 02/26/2013 05:33 PM, Jan Beulich wrote:
>>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
>> 
>> Please don't top post.
>> 
>>> The kernel command line from grub.conf
>>>
>>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
>>> console=com2,vga com2=115200,8n1
>>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
>>>
>>> I have not modified reboot type.
>> 
>> And did you check your full boot log for an info-level message like
>> 
>> "%s series board detected. Selecting %s-method for reboot.\n"
> 
> I have only checked normal boot log, see attachment in my first mail.
> How can I enable info-level message?

Looks like this has info level messages enabled, and I can't see any
such message there. So I guess you'll have to add a few printk()-s
to arch/x86/kernel/reboot.c:native_machine_emergency_restart().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:52:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANkp-0001jV-Ni; Tue, 26 Feb 2013 16:51:47 +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 1UANko-0001jQ-GT
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:51:46 +0000
Received: from [85.158.139.83:39001] by server-5.bemta-5.messagelabs.com id
	B7/6D-02762-128EC215; Tue, 26 Feb 2013 16:51:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361897503!21859760!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUwNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2478 invoked from network); 26 Feb 2013 16:51:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 16:51:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 26 Feb 2013 16:51:43 +0000
Message-Id: <512CF62C02000078000C12F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Tue, 26 Feb 2013 16:51:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
In-Reply-To: <512CE581.7020308@mfiala.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:40, Michal Fiala <fiala@mfiala.net> wrote:
> On 02/26/2013 05:33 PM, Jan Beulich wrote:
>>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
>> 
>> Please don't top post.
>> 
>>> The kernel command line from grub.conf
>>>
>>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
>>> console=com2,vga com2=115200,8n1
>>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
>>>
>>> I have not modified reboot type.
>> 
>> And did you check your full boot log for an info-level message like
>> 
>> "%s series board detected. Selecting %s-method for reboot.\n"
> 
> I have only checked normal boot log, see attachment in my first mail.
> How can I enable info-level message?

Looks like this has info level messages enabled, and I can't see any
such message there. So I guess you'll have to add a few printk()-s
to arch/x86/kernel/reboot.c:native_machine_emergency_restart().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:52:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:52: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 1UANll-0001mC-6M; Tue, 26 Feb 2013 16:52:45 +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 1UANlj-0001m0-LF
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:52:43 +0000
Received: from [85.158.137.99:29823] by server-13.bemta-3.messagelabs.com id
	2C/71-20653-A58EC215; Tue, 26 Feb 2013 16:52:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361897562!12573769!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31787 invoked from network); 26 Feb 2013 16:52:42 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:52:42 -0000
Received: by mail-wg0-f53.google.com with SMTP id fn15so3695007wgb.32
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 08:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=BX9Vxc1Jg3sboxDNpTikCJ7QFdUwyjwSQe1n8xvqqlQ=;
	b=T+p2NWBk24EfwU2YY8g/e4afyts/LKo1poszxpwu708LzXtvX7eK8Du/bKWVJcgJwP
	0OyDwV19l+13UBQsbXPJaLF56J4Ef8LUa2Xqrg039Tu1GYga4kwst/cpfjBDLs0htS/z
	bhtEJZ0c/z8gk/UxFunP0LHm/uBkJH0yqOD1Sm6OA5+KuNBvz6JdlsoA9T3n9lFOz2wX
	AI0LR7GKgm2wokFIevRzu7hS5fMsxZbns+qVcJVTDqowBscEx8MO/5i9DEt0Y4UCdVn2
	ED22zwFbafT1xxFjlEqKRpoqSfe04o4ybADOFUdVFvhcD61ZQw0fePDefJxRBuVSHYef
	Zipw==
X-Received: by 10.181.12.103 with SMTP id ep7mr20691963wid.12.1361897561797;
	Tue, 26 Feb 2013 08:52:41 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id eo1sm22156866wib.8.2013.02.26.08.52.35
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 08:52:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 26 Feb 2013 16:52:33 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <CD5298D1.5C7D0%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
	upstream Linux development tree for Xen.
Thread-Index: Ac4UQavqw7idL/PJLkC07Iw8VU6TcQ==
In-Reply-To: <1361896085.26546.307.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/02/2013 16:28, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
>> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
>>> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
>>>> And also put my name behind the mainternship.
>>> 
>>> I think you could also safely remove Jeremy these days?
>>> 
>>> Maybe we should have a Linux style CREDITS file to retain the names of
>>> historical contributors/maintainers?
>> 
>> Like this:
>> 
>> From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date: Mon, 25 Feb 2013 14:04:55 -0500
>> Subject: [PATCH] CREDITS: First checkin.
>> 
>> Adding Jeremy and moving him from the MAINTAINERS file.
>> 
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  CREDITS     | 16 ++++++++++++++++
>>  MAINTAINERS |  1 -
> 
> This hunk bit wasn't in the patch and didn't make it into the commit
> IanJ just made?

I missed that (I checked it in). Fixed now.

 -- Keir

>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>  create mode 100644 CREDITS
>> 
>> diff --git a/CREDITS b/CREDITS
>> new file mode 100644
>> index 0000000..eaf05bf
>> --- /dev/null
>> +++ b/CREDITS
>> @@ -0,0 +1,16 @@
>> +    This is at least a partial credits-file of people that have
>> +    contributed to the Xen project.  It is sorted by name and
>> +    formatted to allow easy grepping and beautification by
>> +    scripts.  The fields are: name (N), email (E), web-address
>> +    (W), PGP key ID and fingerprint (P), description (D), and
>> +    snail-mail address (S).
>> +    Thanks,
>> +
>> +            Xen team
>> +----------
>> +
>> +N: Jeremy Fitzhardinge
>> +E: jeremy@goop.org
>> +W: http://www.goop.org/~jeremy
>> +P: 1B40B6D0
>> +D: Linux pvops
>> 
>> I didn't put his physical address b/c I don't know if he would like
>> it there?
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 16:52:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:52: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 1UANll-0001mC-6M; Tue, 26 Feb 2013 16:52:45 +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 1UANlj-0001m0-LF
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 16:52:43 +0000
Received: from [85.158.137.99:29823] by server-13.bemta-3.messagelabs.com id
	2C/71-20653-A58EC215; Tue, 26 Feb 2013 16:52:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361897562!12573769!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31787 invoked from network); 26 Feb 2013 16:52:42 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:52:42 -0000
Received: by mail-wg0-f53.google.com with SMTP id fn15so3695007wgb.32
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 08:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=BX9Vxc1Jg3sboxDNpTikCJ7QFdUwyjwSQe1n8xvqqlQ=;
	b=T+p2NWBk24EfwU2YY8g/e4afyts/LKo1poszxpwu708LzXtvX7eK8Du/bKWVJcgJwP
	0OyDwV19l+13UBQsbXPJaLF56J4Ef8LUa2Xqrg039Tu1GYga4kwst/cpfjBDLs0htS/z
	bhtEJZ0c/z8gk/UxFunP0LHm/uBkJH0yqOD1Sm6OA5+KuNBvz6JdlsoA9T3n9lFOz2wX
	AI0LR7GKgm2wokFIevRzu7hS5fMsxZbns+qVcJVTDqowBscEx8MO/5i9DEt0Y4UCdVn2
	ED22zwFbafT1xxFjlEqKRpoqSfe04o4ybADOFUdVFvhcD61ZQw0fePDefJxRBuVSHYef
	Zipw==
X-Received: by 10.181.12.103 with SMTP id ep7mr20691963wid.12.1361897561797;
	Tue, 26 Feb 2013 08:52:41 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id eo1sm22156866wib.8.2013.02.26.08.52.35
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 08:52:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 26 Feb 2013 16:52:33 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <CD5298D1.5C7D0%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
	upstream Linux development tree for Xen.
Thread-Index: Ac4UQavqw7idL/PJLkC07Iw8VU6TcQ==
In-Reply-To: <1361896085.26546.307.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] MAINTAINERS: Provide proper URL to the
 upstream Linux development tree 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/02/2013 16:28, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Mon, 2013-02-25 at 19:07 +0000, Konrad Rzeszutek Wilk wrote:
>> On Mon, Feb 25, 2013 at 04:56:30PM +0000, Ian Campbell wrote:
>>> On Mon, 2013-02-25 at 16:36 +0000, Konrad Rzeszutek Wilk wrote:
>>>> And also put my name behind the mainternship.
>>> 
>>> I think you could also safely remove Jeremy these days?
>>> 
>>> Maybe we should have a Linux style CREDITS file to retain the names of
>>> historical contributors/maintainers?
>> 
>> Like this:
>> 
>> From b9c7cead3b2fec155548436ec46e0dabbb74e33b Mon Sep 17 00:00:00 2001
>> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date: Mon, 25 Feb 2013 14:04:55 -0500
>> Subject: [PATCH] CREDITS: First checkin.
>> 
>> Adding Jeremy and moving him from the MAINTAINERS file.
>> 
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  CREDITS     | 16 ++++++++++++++++
>>  MAINTAINERS |  1 -
> 
> This hunk bit wasn't in the patch and didn't make it into the commit
> IanJ just made?

I missed that (I checked it in). Fixed now.

 -- Keir

>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>  create mode 100644 CREDITS
>> 
>> diff --git a/CREDITS b/CREDITS
>> new file mode 100644
>> index 0000000..eaf05bf
>> --- /dev/null
>> +++ b/CREDITS
>> @@ -0,0 +1,16 @@
>> +    This is at least a partial credits-file of people that have
>> +    contributed to the Xen project.  It is sorted by name and
>> +    formatted to allow easy grepping and beautification by
>> +    scripts.  The fields are: name (N), email (E), web-address
>> +    (W), PGP key ID and fingerprint (P), description (D), and
>> +    snail-mail address (S).
>> +    Thanks,
>> +
>> +            Xen team
>> +----------
>> +
>> +N: Jeremy Fitzhardinge
>> +E: jeremy@goop.org
>> +W: http://www.goop.org/~jeremy
>> +P: 1B40B6D0
>> +D: Linux pvops
>> 
>> I didn't put his physical address b/c I don't know if he would like
>> it there?
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 16:57:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:57: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 1UANqG-00023Y-4K; Tue, 26 Feb 2013 16:57: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 1UANqE-00023P-Jm
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:57:22 +0000
Received: from [85.158.138.51:27152] by server-13.bemta-3.messagelabs.com id
	07/0A-20653-179EC215; Tue, 26 Feb 2013 16:57:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361897839!20426788!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20778 invoked from network); 26 Feb 2013 16:57:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 16:57:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QGuHLx002404
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 16:56:19 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
	r1QGuGK4024493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 16:56:17 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
	r1QGuGuu006135; Tue, 26 Feb 2013 10:56:16 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 08:56:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E85FF1C3935; Tue, 26 Feb 2013 11:56:14 -0500 (EST)
Date: Tue, 26 Feb 2013 11:56:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Michal Fiala <fiala@mfiala.net>
Message-ID: <20130226165614.GA22422@phenom.dumpdata.com>
References: <512CC78B.4080606@mfiala.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CC78B.4080606@mfiala.net>
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
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 03:32:43PM +0100, Michal Fiala wrote:
> Hallo,
> 
> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
> without problem. When I run reboot or shutdown -r now, system correctly
> shutdowns all runlevels and then system crashed, see crash_output.txt.
> I have the same problem with kernel linux 3.2.37. When I shudown system
> (halt), then it is without problem. I have tested kernel 3.7.5 without
> xen hypervisor, it was without problems. Required debug informations
> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
> Could you please help me with this problem?
> 
> Thanks
> 
> Michal
> 


> INIT: Switching to runlevel: 6
> INIT: Sending processes the TERM signal
>  * Stopping local
>  [ ok ]
>  * Stopping vixie-cron ...
>  [ ok ]
>  * Saving random seed ...
>  [ ok ]
>  * Deactivating additional swap space ...
>  [ ok ]
>  * Stopping sshd ...
>  [ ok ]
>  * Use of the opts variable is deprecated and will be
>  * removed in the future.
>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>  * Stopping Xen control daemon ...
>  [ ok ]
>  * Stoping xenconsoled daemon ...
>  [ ok ]
>  * Stopping... ...
>  [ ok ]
>  * Stopping ntpd ...
>  [ ok ]
>  * Stopping xenstored daemon ...
>  [ ok ]
>  * Stopping nrpe ...
>  [ ok ]
>  * Unmounting network filesystems ...
>  [ ok ]
>  * Stopping munin-node ...
>  [ ok ]
>  * Stopping fail2ban ...
>  [ ok ]
>  * Stopping bacula file daemon ...
>  [ ok ]
>  * Stopping syslog-ng ...
>  [ ok ]
>  * Bringing down interface br0
>  *   Destroying bridge br0 ...
>  [ ok ]
>  * Bringing down interface bond0
>  *   Removing slaves from bond0 ...
>  *     eth0 eth1 
>  [ ok ]
>  * Use of the opts variable is deprecated and will be
>  * removed in the future.
>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>  * Stopping firewall ...
>  [ ok ]
>  * Bringing down interface lo
>  * Unmounting loop devices
>  * Unmounting filesystems
>  *   Unmounting /boot ...
>  [ ok ]
>  *   Unmounting /data/d0700 ...
>  [ ok ]
>  *   Unmounting /var ...
>  [ ok ]
>  * Deactivating swap devices ...
>  [ ok ]
>  * Shutting down the Logical Volume Manager
>  *   Shutting Down LVs & VGs ...
>   Command failed with status code 2.
>   No such command.  Try 'help'.
>  * Failed
>  [ !! ]
>  * Finished Shutting down the Logical Volume Manager
>  * Stopping udev ...
>  [ ok ]
>  * Setting hardware clock using the system clock [UTC] ...
>  [ ok ]
>  * Terminating remaining processes ...
>  [ ok ]
>  * Killing remaining processes ...
>  [ ok ]
>  * Saving dependency cache ...
>  [ ok ]
>  * Remounting remaining filesystems read-only ...
>  *   Remounting / read only ...
>  [ ok ]
>  [ ok ]
> [  612.749666] Restarting system.
> [  618.364165] int3: 0000 [#1] SMP 
> [  618.364396] Modules linked in: bonding
> [  618.364590] CPU 0 
> [  618.364658] Pid: 9998, comm: reboot Tainted: G        W    3.7.5-hardened #4 Dell Inc. PowerEdge R720xd/0VWT90
> [  618.364806] RIP: e030:[<ffffffff8102a894>]  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
> [  618.364956] RSP: e02b:ffff880136b35da8  EFLAGS: 00000046
> [  618.365130] RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffffff8172ad90
> [  618.365308] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81ad8cdc
> [  618.365487] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> [  618.365663] R10: 00000000000005dd R11: 0000000000000000 R12: 0000000000000cf9
> [  618.365867] R13: ffffffff8172ad90 R14: 0000000000000061 R15: 0000000000000000
> [  618.366045] FS:  00007f32051f0700(0000) GS:ffff88013d600000(0000) knlGS:0000000000000000
> [  618.366317] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  618.366489] CR2: 00007fa697fb3d30 CR3: 0000000135590000 CR4: 0000000000042660
> [  618.366664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  618.366839] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  618.367013] Process reboot (pid: 9998, threadinfo ffff880137af3b90, task ffff880137af3780)
> [  618.367288] Stack:
> [  618.367482]  0000000000000009 0000000081045315 0000000000000000 0000000001234567
> [  618.368001]  0000000028121969 0000000000000022 0000000000000000 0000000000000000
> [  618.368527]  0000000001234567 0000000028121969 0000000000000022 00007f3205203248
> [  618.369079] Call Trace:
> [  618.369250]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40

native machine restart? It should have been xen_restart!

Can you attach the full bootup serial log please?

What distro is this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:57:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16:57: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 1UANqG-00023Y-4K; Tue, 26 Feb 2013 16:57: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 1UANqE-00023P-Jm
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:57:22 +0000
Received: from [85.158.138.51:27152] by server-13.bemta-3.messagelabs.com id
	07/0A-20653-179EC215; Tue, 26 Feb 2013 16:57:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1361897839!20426788!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20778 invoked from network); 26 Feb 2013 16:57:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 16:57:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QGuHLx002404
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 16:56:19 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
	r1QGuGK4024493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 16:56:17 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
	r1QGuGuu006135; Tue, 26 Feb 2013 10:56:16 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 08:56:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E85FF1C3935; Tue, 26 Feb 2013 11:56:14 -0500 (EST)
Date: Tue, 26 Feb 2013 11:56:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Michal Fiala <fiala@mfiala.net>
Message-ID: <20130226165614.GA22422@phenom.dumpdata.com>
References: <512CC78B.4080606@mfiala.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CC78B.4080606@mfiala.net>
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
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 03:32:43PM +0100, Michal Fiala wrote:
> Hallo,
> 
> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
> without problem. When I run reboot or shutdown -r now, system correctly
> shutdowns all runlevels and then system crashed, see crash_output.txt.
> I have the same problem with kernel linux 3.2.37. When I shudown system
> (halt), then it is without problem. I have tested kernel 3.7.5 without
> xen hypervisor, it was without problems. Required debug informations
> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
> Could you please help me with this problem?
> 
> Thanks
> 
> Michal
> 


> INIT: Switching to runlevel: 6
> INIT: Sending processes the TERM signal
>  * Stopping local
>  [ ok ]
>  * Stopping vixie-cron ...
>  [ ok ]
>  * Saving random seed ...
>  [ ok ]
>  * Deactivating additional swap space ...
>  [ ok ]
>  * Stopping sshd ...
>  [ ok ]
>  * Use of the opts variable is deprecated and will be
>  * removed in the future.
>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>  * Stopping Xen control daemon ...
>  [ ok ]
>  * Stoping xenconsoled daemon ...
>  [ ok ]
>  * Stopping... ...
>  [ ok ]
>  * Stopping ntpd ...
>  [ ok ]
>  * Stopping xenstored daemon ...
>  [ ok ]
>  * Stopping nrpe ...
>  [ ok ]
>  * Unmounting network filesystems ...
>  [ ok ]
>  * Stopping munin-node ...
>  [ ok ]
>  * Stopping fail2ban ...
>  [ ok ]
>  * Stopping bacula file daemon ...
>  [ ok ]
>  * Stopping syslog-ng ...
>  [ ok ]
>  * Bringing down interface br0
>  *   Destroying bridge br0 ...
>  [ ok ]
>  * Bringing down interface bond0
>  *   Removing slaves from bond0 ...
>  *     eth0 eth1 
>  [ ok ]
>  * Use of the opts variable is deprecated and will be
>  * removed in the future.
>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>  * Stopping firewall ...
>  [ ok ]
>  * Bringing down interface lo
>  * Unmounting loop devices
>  * Unmounting filesystems
>  *   Unmounting /boot ...
>  [ ok ]
>  *   Unmounting /data/d0700 ...
>  [ ok ]
>  *   Unmounting /var ...
>  [ ok ]
>  * Deactivating swap devices ...
>  [ ok ]
>  * Shutting down the Logical Volume Manager
>  *   Shutting Down LVs & VGs ...
>   Command failed with status code 2.
>   No such command.  Try 'help'.
>  * Failed
>  [ !! ]
>  * Finished Shutting down the Logical Volume Manager
>  * Stopping udev ...
>  [ ok ]
>  * Setting hardware clock using the system clock [UTC] ...
>  [ ok ]
>  * Terminating remaining processes ...
>  [ ok ]
>  * Killing remaining processes ...
>  [ ok ]
>  * Saving dependency cache ...
>  [ ok ]
>  * Remounting remaining filesystems read-only ...
>  *   Remounting / read only ...
>  [ ok ]
>  [ ok ]
> [  612.749666] Restarting system.
> [  618.364165] int3: 0000 [#1] SMP 
> [  618.364396] Modules linked in: bonding
> [  618.364590] CPU 0 
> [  618.364658] Pid: 9998, comm: reboot Tainted: G        W    3.7.5-hardened #4 Dell Inc. PowerEdge R720xd/0VWT90
> [  618.364806] RIP: e030:[<ffffffff8102a894>]  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
> [  618.364956] RSP: e02b:ffff880136b35da8  EFLAGS: 00000046
> [  618.365130] RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffffff8172ad90
> [  618.365308] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81ad8cdc
> [  618.365487] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> [  618.365663] R10: 00000000000005dd R11: 0000000000000000 R12: 0000000000000cf9
> [  618.365867] R13: ffffffff8172ad90 R14: 0000000000000061 R15: 0000000000000000
> [  618.366045] FS:  00007f32051f0700(0000) GS:ffff88013d600000(0000) knlGS:0000000000000000
> [  618.366317] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  618.366489] CR2: 00007fa697fb3d30 CR3: 0000000135590000 CR4: 0000000000042660
> [  618.366664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  618.366839] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  618.367013] Process reboot (pid: 9998, threadinfo ffff880137af3b90, task ffff880137af3780)
> [  618.367288] Stack:
> [  618.367482]  0000000000000009 0000000081045315 0000000000000000 0000000001234567
> [  618.368001]  0000000028121969 0000000000000022 0000000000000000 0000000000000000
> [  618.368527]  0000000001234567 0000000028121969 0000000000000022 00007f3205203248
> [  618.369079] Call Trace:
> [  618.369250]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40

native machine restart? It should have been xen_restart!

Can you attach the full bootup serial log please?

What distro is this?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 16:59:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANsU-0002BO-Mo; Tue, 26 Feb 2013 16:59:42 +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 1UANsT-0002BG-UT
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:59:42 +0000
Received: from [85.158.139.211:23507] by server-13.bemta-5.messagelabs.com id
	03/2A-16871-DF9EC215; Tue, 26 Feb 2013 16:59:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361897980!18440668!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13096 invoked from network); 26 Feb 2013 16:59:40 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:59:40 -0000
Received: by mail-wi0-f174.google.com with SMTP id hi8so5169315wib.1
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 08:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Qofs2iXP9bfWahdLolwNzijyBzkYxOoMYinT9Y07b/c=;
	b=ukXSQqd7t0e32fHhCihxEgk0r9P75AsbKsBbYGKcLvlRmvlrsGXVQ/6XVxI2AW74eR
	GiGmldlzgTi5RqQ97MymbzrMDZv2o4Im28ORU+STRLE03S8GuygHQNuZ3foJAuTBv5di
	RzsXBcju7A+JlLR1XTjVyIkwGvTXQ6wGiFJ9CP7wf2ZoDkJHBy/dX05+fBwcaoDMh/6S
	xKhLDfMloaLr4+McjgQOpf8FRP9Fd8lfS4ntIubtnPmTihvkcS7hXK0J9jl3upSLq9Ng
	iEfaj+nawZNVUWqg3GlvqXxTpt4860dJKr/fSpf3nfGtHclwC1Yp/pieysVT1uSVexgQ
	jn6A==
X-Received: by 10.180.80.34 with SMTP id o2mr21347741wix.0.1361897980323;
	Tue, 26 Feb 2013 08:59:40 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id bj9sm22211556wib.4.2013.02.26.08.59.38
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 08:59:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 26 Feb 2013 16:59:31 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD529A73.5C7E6%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 0/3] x86: per-domain mapping adjustments
Thread-Index: Ac4UQqUP3e6aGcOub0esEKrxTJIl2w==
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH v2 0/3] x86: per-domain mapping 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

On 26/02/2013 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:

> The main goal being the re-work of the hypercall argument translation
> area management, this series first breaks out per-domain mapping
> management into its own set of functions, in order to then use this
> for setting up the translation areas in per-domain space.
> 
> While doing this I also realized that it's pointless for the
> map_domain_page() code to track L1 page table pointers in a
> separate Xen heap page - we can equally well use the linear
> page table for the manipulations needed here.
> 
> 1: introduce create_perdomain_mapping()
> 2: rework hypercall argument translation area setup
> 3: use linear L1 page table for map_domain_page() page table manipulation
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 16:59:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 16: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 1UANsU-0002BO-Mo; Tue, 26 Feb 2013 16:59:42 +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 1UANsT-0002BG-UT
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 16:59:42 +0000
Received: from [85.158.139.211:23507] by server-13.bemta-5.messagelabs.com id
	03/2A-16871-DF9EC215; Tue, 26 Feb 2013 16:59:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361897980!18440668!1
X-Originating-IP: [209.85.212.174]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13096 invoked from network); 26 Feb 2013 16:59:40 -0000
Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com)
	(209.85.212.174)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 16:59:40 -0000
Received: by mail-wi0-f174.google.com with SMTP id hi8so5169315wib.1
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 08:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:user-agent:date:subject:from:to:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Qofs2iXP9bfWahdLolwNzijyBzkYxOoMYinT9Y07b/c=;
	b=ukXSQqd7t0e32fHhCihxEgk0r9P75AsbKsBbYGKcLvlRmvlrsGXVQ/6XVxI2AW74eR
	GiGmldlzgTi5RqQ97MymbzrMDZv2o4Im28ORU+STRLE03S8GuygHQNuZ3foJAuTBv5di
	RzsXBcju7A+JlLR1XTjVyIkwGvTXQ6wGiFJ9CP7wf2ZoDkJHBy/dX05+fBwcaoDMh/6S
	xKhLDfMloaLr4+McjgQOpf8FRP9Fd8lfS4ntIubtnPmTihvkcS7hXK0J9jl3upSLq9Ng
	iEfaj+nawZNVUWqg3GlvqXxTpt4860dJKr/fSpf3nfGtHclwC1Yp/pieysVT1uSVexgQ
	jn6A==
X-Received: by 10.180.80.34 with SMTP id o2mr21347741wix.0.1361897980323;
	Tue, 26 Feb 2013 08:59:40 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id bj9sm22211556wib.4.2013.02.26.08.59.38
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 26 Feb 2013 08:59:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Tue, 26 Feb 2013 16:59:31 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CD529A73.5C7E6%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2 0/3] x86: per-domain mapping adjustments
Thread-Index: Ac4UQqUP3e6aGcOub0esEKrxTJIl2w==
In-Reply-To: <512CE92B02000078000C1256@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH v2 0/3] x86: per-domain mapping 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

On 26/02/2013 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:

> The main goal being the re-work of the hypercall argument translation
> area management, this series first breaks out per-domain mapping
> management into its own set of functions, in order to then use this
> for setting up the translation areas in per-domain space.
> 
> While doing this I also realized that it's pointless for the
> map_domain_page() code to track L1 page table pointers in a
> separate Xen heap page - we can equally well use the linear
> page table for the manipulations needed here.
> 
> 1: introduce create_perdomain_mapping()
> 2: rework hypercall argument translation area setup
> 3: use linear L1 page table for map_domain_page() page table manipulation
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 26 17:03:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:03: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 1UANwN-0002Qf-ER; Tue, 26 Feb 2013 17:03: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 1UANwM-0002QY-AH
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:03:42 +0000
Received: from [85.158.143.99:29189] by server-1.bemta-4.messagelabs.com id
	2A/69-06203-DEAEC215; Tue, 26 Feb 2013 17:03:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361898219!29289885!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18978 invoked from network); 26 Feb 2013 17:03:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 17:03:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QH3Xpq032242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:03:34 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
	r1QH3WbD014546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:03:33 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
	r1QH3Vtc021520; Tue, 26 Feb 2013 11:03:32 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:03:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A79F61C3935; Tue, 26 Feb 2013 12:03:30 -0500 (EST)
Date: Tue, 26 Feb 2013 12:03:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130226170330.GB22422@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CD595.2000502@canonical.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>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
> On 25.02.2013 10:10, Stefan Bader wrote:
> > On 25.02.2013 04:15, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> >>>> Hi Konrad,
> >>>
> >>> Hey Stefan,
> >>>>
> >>>> here is another one from the hm-what? department:
> >>>
> >>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> >>> he has been tracking a similar one with mcelog.
> >>>>
> >>>> Colin discovered that running the attached program with the fork
> >>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
> >>>> iomem) this triggers the following weird messages: 
> >>>>
> >>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
> >>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
> >>>> [ 6824.453776] ------------[ cut here ]------------
> >>>> [ 6824.453796] WARNING: at
> >>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> >>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
> >>>> mmap-example Tainted: GF 
> >>>> 3.8.0-6-generic #13-Ubuntu
> >>>> [ 6824.453926] Call Trace:
> >>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> >>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> >>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> >>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> >>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> >>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> >>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> >>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> >>>> [ 6824.454027]  [<ffffffff81056d9f>]
> >>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038] 
> >>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048] 
> >>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060] 
> >>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069] 
> >>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
> >>>> ---[ end trace 4918cdd0a4c9fea4 ]--- 
> >>>>
> >>>> I found that this is related to your bandaid patch
> >>>>
> >>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> >>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>> Date:   Fri Feb 10 09:16:27 2012 -0500
> >>>>
> >>>>     xen/pat: Disable PAT support for now.
> >>>>
> >>>> I just do not understand how this happens. From the trace it seems
> >>>> the fork 
> >>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
> >>>> maybe the 
> >>>> warning is just related to this. So primarily the question is how on
> >>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
> >>>> cleared from the supported 
> >>>> mask by the patch, so somehow I would think nothing should be able
> >>>> to set it... 
> >>>> But apparently not so.
> >>>> Not sure it is a big deal since I never saw this in normal operation
> >>>> and it 
> >>>> seems to be ok when unapping before doing the fork. It is just plain
> >>>> odd. 
> >>>
> >>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> >>> ranges are swapped or not correct. Jinsong, could you shed some light
> >>> on what you have found so far?
> >>>
> >>
> >> Yes, Sander once also reported a similar weird warning when start mcelog daemon, as attached.
> >>
> >> Basically, it occurs when mcelog user daemon start, 
> >> do_fork
> >>   --> copy_process
> >>     --> dup_mm
> >>       --> dup_mmap
> >>         --> copy_page_range
> >>           --> track_pfn_copy
> >>             --> reserve_pfn_range
> 
> So that makes it clearer as this will do
> 
> reserve_memtype(...)
> --> pat_x_mtrr_type
>   --> mtrr_type_lookup
>     --> __mtrr_type_lookup
> 
> And that can return -1/0xff in case of mtrr not being enabled/initialized. Which
> is not the case (given there are no messages for it in dmesg). This is not equal
> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
> 
> It looks like the problem starts early in reserve_memtype:
> 
>         if (!pat_enabled) {
>                 /* This is identical to page table setting without PAT */
>                 if (new_type) {
>                         if (req_type == _PAGE_CACHE_WC)
>                                 *new_type = _PAGE_CACHE_UC_MINUS;
>                         else
>                                 *new_type = req_type & _PAGE_CACHE_MASK;
>                 }
>                 return 0;
>         }
> 
> This would be what we want, but only clearing the PWT and PCD flags from the
> supported flags is not changing pat_enabled (which is 1 when PAT support is
> compiled into the kernel). Unfortunately the variable is local and since there
> are not any messages about PAT in dmesg I would say pat_init() is not called
> either. Which might be used to disable PAT support by clearing the CPU feature
> flag.

Hm, so:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 39928d1..9ac70c5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
 
        cpuid_leaf1_edx_mask =
                ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
                  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
 
        if (!xen_initial_domain())



should do it right? Let me check on the troublesome machine I saw
it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:03:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:03: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 1UANwN-0002Qf-ER; Tue, 26 Feb 2013 17:03: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 1UANwM-0002QY-AH
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:03:42 +0000
Received: from [85.158.143.99:29189] by server-1.bemta-4.messagelabs.com id
	2A/69-06203-DEAEC215; Tue, 26 Feb 2013 17:03:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361898219!29289885!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18978 invoked from network); 26 Feb 2013 17:03:41 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 17:03:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QH3Xpq032242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:03:34 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
	r1QH3WbD014546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:03:33 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
	r1QH3Vtc021520; Tue, 26 Feb 2013 11:03:32 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:03:31 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A79F61C3935; Tue, 26 Feb 2013 12:03:30 -0500 (EST)
Date: Tue, 26 Feb 2013 12:03:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130226170330.GB22422@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CD595.2000502@canonical.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>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
> On 25.02.2013 10:10, Stefan Bader wrote:
> > On 25.02.2013 04:15, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> >>>> Hi Konrad,
> >>>
> >>> Hey Stefan,
> >>>>
> >>>> here is another one from the hm-what? department:
> >>>
> >>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> >>> he has been tracking a similar one with mcelog.
> >>>>
> >>>> Colin discovered that running the attached program with the fork
> >>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
> >>>> iomem) this triggers the following weird messages: 
> >>>>
> >>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
> >>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
> >>>> [ 6824.453776] ------------[ cut here ]------------
> >>>> [ 6824.453796] WARNING: at
> >>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> >>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
> >>>> mmap-example Tainted: GF 
> >>>> 3.8.0-6-generic #13-Ubuntu
> >>>> [ 6824.453926] Call Trace:
> >>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> >>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> >>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> >>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> >>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> >>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> >>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> >>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> >>>> [ 6824.454027]  [<ffffffff81056d9f>]
> >>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038] 
> >>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048] 
> >>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060] 
> >>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069] 
> >>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
> >>>> ---[ end trace 4918cdd0a4c9fea4 ]--- 
> >>>>
> >>>> I found that this is related to your bandaid patch
> >>>>
> >>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> >>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>> Date:   Fri Feb 10 09:16:27 2012 -0500
> >>>>
> >>>>     xen/pat: Disable PAT support for now.
> >>>>
> >>>> I just do not understand how this happens. From the trace it seems
> >>>> the fork 
> >>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
> >>>> maybe the 
> >>>> warning is just related to this. So primarily the question is how on
> >>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
> >>>> cleared from the supported 
> >>>> mask by the patch, so somehow I would think nothing should be able
> >>>> to set it... 
> >>>> But apparently not so.
> >>>> Not sure it is a big deal since I never saw this in normal operation
> >>>> and it 
> >>>> seems to be ok when unapping before doing the fork. It is just plain
> >>>> odd. 
> >>>
> >>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> >>> ranges are swapped or not correct. Jinsong, could you shed some light
> >>> on what you have found so far?
> >>>
> >>
> >> Yes, Sander once also reported a similar weird warning when start mcelog daemon, as attached.
> >>
> >> Basically, it occurs when mcelog user daemon start, 
> >> do_fork
> >>   --> copy_process
> >>     --> dup_mm
> >>       --> dup_mmap
> >>         --> copy_page_range
> >>           --> track_pfn_copy
> >>             --> reserve_pfn_range
> 
> So that makes it clearer as this will do
> 
> reserve_memtype(...)
> --> pat_x_mtrr_type
>   --> mtrr_type_lookup
>     --> __mtrr_type_lookup
> 
> And that can return -1/0xff in case of mtrr not being enabled/initialized. Which
> is not the case (given there are no messages for it in dmesg). This is not equal
> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
> 
> It looks like the problem starts early in reserve_memtype:
> 
>         if (!pat_enabled) {
>                 /* This is identical to page table setting without PAT */
>                 if (new_type) {
>                         if (req_type == _PAGE_CACHE_WC)
>                                 *new_type = _PAGE_CACHE_UC_MINUS;
>                         else
>                                 *new_type = req_type & _PAGE_CACHE_MASK;
>                 }
>                 return 0;
>         }
> 
> This would be what we want, but only clearing the PWT and PCD flags from the
> supported flags is not changing pat_enabled (which is 1 when PAT support is
> compiled into the kernel). Unfortunately the variable is local and since there
> are not any messages about PAT in dmesg I would say pat_init() is not called
> either. Which might be used to disable PAT support by clearing the CPU feature
> flag.

Hm, so:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 39928d1..9ac70c5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
 
        cpuid_leaf1_edx_mask =
                ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
                  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
 
        if (!xen_initial_domain())



should do it right? Let me check on the troublesome machine I saw
it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:05:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UANyE-0002WG-VA; Tue, 26 Feb 2013 17:05: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 1UANyD-0002W7-SO
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:05:38 +0000
Received: from [85.158.139.83:10076] by server-16.bemta-5.messagelabs.com id
	6B/EE-02543-16BEC215; Tue, 26 Feb 2013 17:05:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361898328!26325538!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3472 invoked from network); 26 Feb 2013 17:05:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:05:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QH5NpW015338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:05:23 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
	r1QH5M44019125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:05:22 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1QH5MwR014415; Tue, 26 Feb 2013 11:05:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:05:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D4AB1C3935; Tue, 26 Feb 2013 12:05:20 -0500 (EST)
Date: Tue, 26 Feb 2013 12:05:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226170520.GC22422@phenom.dumpdata.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
	<20780.57185.786644.525993@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.57185.786644.525993@mariner.uk.xensource.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, ian.campbel@citrix.com
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup
 section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCBGZWIgMjYsIDIwMTMgYXQgMDQ6MTQ6MjVQTSArMDAwMCwgSWFuIEphY2tzb24gd3Jv
dGU6Cj4gS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB0
byBYODYgUFYgTU1VIFdpa2kgdjJdIEV4cGFuZCB0aCBlIGJvb3R1cCBzZWN0aW9uIHRvIGluY2x1
ZGUgRUxGIGFuZCBtZW1vcnkgbGF5b3V0Iik6Cj4gPiB2MjogSW50ZWdyYXRlIElhbidzIGNvbW1l
bnRzLgo+IAo+IFRoZXJlIGFyZSBzb21lIGZvcm1hdHRpbmcgb2RkaXRpZXMgaW4gdGhpczoKPiAK
PiA+ICsKPiA+ICtXaGVuIGd1ZXN0IGhhcyBzdGFydGVkLCB0aGUga2VybmVsIGltYWdlIGlzIHJl
YWQgYW5kIHRoZSBFTEYgKFBUX05PVEUpIHByb2dyYW0gaXMKPiAKPiBUaGlzIGxpbmUgaXMgdG9v
IGxvbmcgZm9yIGEgLnR4dCBmaWxlOyBpdCBzaG91ZGwgYmUgNzAgb3IgbWF5YmUgNzUuCj4gVGhp
cyBpcyBhIHByb2JsZW0gdGhyb3VnaG91dCB0aGUgZmlsZS4KCkh1aD8gVGhpcyBnb2VzIG9uIHRo
ZSBXaWtpIHNvIEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCB0byB3b3JyeSBhYm91dCB0aGF0LgoK
PiAKPiA+ICtwYXJzZWQuVGhlIGh5cGVydmlzb3IgbG9va3MgaW4gdGhlIC5ub3RlIHNlY3Rpb25z
Cj4gCj4gQW5kIGhlcmUgaXMgYSBtaXNzaW5nIHBzcGFjZS4KPiAKPiA+ICtjYW4gc3VwcG9ydCwg
YW5kIHRoZSBsb2NhdGlvbiBvZiB0aGUgaHlwZXJjYWxsIHBhZ2UuIFRoZXJlIGFyZSB0d28gdmFy
aWFudHMgb2YgdGhpczoKPiA+ICsKPiA+ICs7IGEpLiBBIOKAnC5ub3RlLlhlbuKAnSBzZWN0aW9u
IGluIEVMRiBoZWFkZXIgY29uZm9ybWluZyB0byB0aGUgRUxGIFBUX05PVEUgZm9ybWF0Lgo+IAo+
IFdoYXQncyB0aGUgc2VtaWNvbG9uIGZvciA/CgpGb3IgV2lraS4KPiAKPiBZb3VyIGZpbGUgaGFz
IHNvbWUga2luZCBvZiBoaWdoLWJpdC1zZXQgY2hhcmFjdGVycyBpbiBpdCB3aGljaCBJIGRvbid0
Cj4gdGhpbmsgYXJlIGRlc2lyYWJsZSBoZXJlID8KCk5vdCBzdXJlIHdoeSB0aGV5IHNob3cgdXAs
IGJ1dCB0aGV5IGFyZSBPSyBpbiB0aGUgV2lraS4KPiAKPiBJYW4uCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:05:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 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 1UANyE-0002WG-VA; Tue, 26 Feb 2013 17:05: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 1UANyD-0002W7-SO
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:05:38 +0000
Received: from [85.158.139.83:10076] by server-16.bemta-5.messagelabs.com id
	6B/EE-02543-16BEC215; Tue, 26 Feb 2013 17:05:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361898328!26325538!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3472 invoked from network); 26 Feb 2013 17:05:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:05:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QH5NpW015338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:05:23 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
	r1QH5M44019125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:05:22 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1QH5MwR014415; Tue, 26 Feb 2013 11:05:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:05:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D4AB1C3935; Tue, 26 Feb 2013 12:05:20 -0500 (EST)
Date: Tue, 26 Feb 2013 12:05:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226170520.GC22422@phenom.dumpdata.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
	<20780.57185.786644.525993@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.57185.786644.525993@mariner.uk.xensource.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, ian.campbel@citrix.com
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup
 section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gVHVlLCBGZWIgMjYsIDIwMTMgYXQgMDQ6MTQ6MjVQTSArMDAwMCwgSWFuIEphY2tzb24gd3Jv
dGU6Cj4gS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyaXRlcyAoIltYZW4tZGV2ZWxdIFtQQVRDSCB0
byBYODYgUFYgTU1VIFdpa2kgdjJdIEV4cGFuZCB0aCBlIGJvb3R1cCBzZWN0aW9uIHRvIGluY2x1
ZGUgRUxGIGFuZCBtZW1vcnkgbGF5b3V0Iik6Cj4gPiB2MjogSW50ZWdyYXRlIElhbidzIGNvbW1l
bnRzLgo+IAo+IFRoZXJlIGFyZSBzb21lIGZvcm1hdHRpbmcgb2RkaXRpZXMgaW4gdGhpczoKPiAK
PiA+ICsKPiA+ICtXaGVuIGd1ZXN0IGhhcyBzdGFydGVkLCB0aGUga2VybmVsIGltYWdlIGlzIHJl
YWQgYW5kIHRoZSBFTEYgKFBUX05PVEUpIHByb2dyYW0gaXMKPiAKPiBUaGlzIGxpbmUgaXMgdG9v
IGxvbmcgZm9yIGEgLnR4dCBmaWxlOyBpdCBzaG91ZGwgYmUgNzAgb3IgbWF5YmUgNzUuCj4gVGhp
cyBpcyBhIHByb2JsZW0gdGhyb3VnaG91dCB0aGUgZmlsZS4KCkh1aD8gVGhpcyBnb2VzIG9uIHRo
ZSBXaWtpIHNvIEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCB0byB3b3JyeSBhYm91dCB0aGF0LgoK
PiAKPiA+ICtwYXJzZWQuVGhlIGh5cGVydmlzb3IgbG9va3MgaW4gdGhlIC5ub3RlIHNlY3Rpb25z
Cj4gCj4gQW5kIGhlcmUgaXMgYSBtaXNzaW5nIHBzcGFjZS4KPiAKPiA+ICtjYW4gc3VwcG9ydCwg
YW5kIHRoZSBsb2NhdGlvbiBvZiB0aGUgaHlwZXJjYWxsIHBhZ2UuIFRoZXJlIGFyZSB0d28gdmFy
aWFudHMgb2YgdGhpczoKPiA+ICsKPiA+ICs7IGEpLiBBIOKAnC5ub3RlLlhlbuKAnSBzZWN0aW9u
IGluIEVMRiBoZWFkZXIgY29uZm9ybWluZyB0byB0aGUgRUxGIFBUX05PVEUgZm9ybWF0Lgo+IAo+
IFdoYXQncyB0aGUgc2VtaWNvbG9uIGZvciA/CgpGb3IgV2lraS4KPiAKPiBZb3VyIGZpbGUgaGFz
IHNvbWUga2luZCBvZiBoaWdoLWJpdC1zZXQgY2hhcmFjdGVycyBpbiBpdCB3aGljaCBJIGRvbid0
Cj4gdGhpbmsgYXJlIGRlc2lyYWJsZSBoZXJlID8KCk5vdCBzdXJlIHdoeSB0aGV5IHNob3cgdXAs
IGJ1dCB0aGV5IGFyZSBPSyBpbiB0aGUgV2lraS4KPiAKPiBJYW4uCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:08:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO1B-0002iq-If; Tue, 26 Feb 2013 17:08: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 1UAO19-0002ia-Lj
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:08:39 +0000
Received: from [85.158.137.99:36315] by server-14.bemta-3.messagelabs.com id
	C7/54-23533-51CEC215; Tue, 26 Feb 2013 17:08:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361898515!15868481!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25640 invoked from network); 26 Feb 2013 17:08:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1912905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:08: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.297.1; Tue, 26 Feb 2013 17:08:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAO14-0008RX-Kb; Tue, 26 Feb 2013 17:08:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAO14-0001py-GH;
	Tue, 26 Feb 2013 17:08:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.60434.402629.740920@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:08:34 +0000
To: Jan Beulich <JBeulich@suse.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Keir Fraser <keir.xen@gmail.com>, "Tim
	(Xen.org)" <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361598228-25041-1-git-send-email-xi@mit.edu>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xi Wang <xi@mit.edu>, xen-devel@lists.xen.org
Subject: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86: fix
	null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in intel_get_extended_msrs()"):
> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.

Really I think we shouldn't be writing out these kind of memsets.
They're too error-prone.  We should have a macro, perhaps like this:

  #define FILLZERO(object) memset(&(object), 0, sizeof(object))

Likewise a copy macro.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:08:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO1B-0002iq-If; Tue, 26 Feb 2013 17:08: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 1UAO19-0002ia-Lj
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:08:39 +0000
Received: from [85.158.137.99:36315] by server-14.bemta-3.messagelabs.com id
	C7/54-23533-51CEC215; Tue, 26 Feb 2013 17:08:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361898515!15868481!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25640 invoked from network); 26 Feb 2013 17:08:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:08:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1912905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:08: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.297.1; Tue, 26 Feb 2013 17:08:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAO14-0008RX-Kb; Tue, 26 Feb 2013 17:08:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAO14-0001py-GH;
	Tue, 26 Feb 2013 17:08:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.60434.402629.740920@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:08:34 +0000
To: Jan Beulich <JBeulich@suse.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>, Keir Fraser <keir.xen@gmail.com>, "Tim
	(Xen.org)" <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361598228-25041-1-git-send-email-xi@mit.edu>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xi Wang <xi@mit.edu>, xen-devel@lists.xen.org
Subject: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86: fix
	null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in intel_get_extended_msrs()"):
> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.

Really I think we shouldn't be writing out these kind of memsets.
They're too error-prone.  We should have a macro, perhaps like this:

  #define FILLZERO(object) memset(&(object), 0, sizeof(object))

Likewise a copy macro.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:09:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO1l-0002mE-0p; Tue, 26 Feb 2013 17:09: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 1UAO1j-0002m1-LZ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:09:15 +0000
Received: from [85.158.139.83:26017] by server-13.bemta-5.messagelabs.com id
	CA/2D-16871-A3CEC215; Tue, 26 Feb 2013 17:09:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361898554!27286953!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23481 invoked from network); 26 Feb 2013 17:09:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:09:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1912916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:09: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.297.1;
	Tue, 26 Feb 2013 17:09:13 +0000
Message-ID: <1361898552.26546.317.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 17:09:12 +0000
In-Reply-To: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 16:45 +0000, Stefano Stabellini wrote:
> Also there are many reasons why somebody would want to rebuild his
> own Xen package from xen-unstable instead of the deb source.

Nothing is stopping them doing this, but the deb target in the xen tree
is not aimed at them.

> > I do object to these.  "Getting the bits onto your system" doesn't
> > include automatically starting the daemons.
> 
> No matter what we think the objective of the deb target is, it cannot be
> an excuse to do only half of the job.

The current deb target does exactly what it was intended to do, no more
and no less. It does not do half a job at its intended goal. Note that
it's goal is not and never was to provide a completely usable package
for end users.

> Even if it is just for testing, I would want the init scripts to
> be started automatically on my testbox, why should I do that manually?

Because the deb target is a "removable tarball" nothing more. Do you
expect that a tarball would do this?

Do you expect that this deb package should also frob your bootloader
configuration? What about setting up bridged networking? Where do we
draw the line?

If we cannot agree on this then I propose we remove the existing deb
target, since I don't think a full and proper .deb (or .rpm or ebuild or
xxx) packaging has any place in the main Xen tree, that is what the
distros are for. Otherwise we are going to be constantly rehashing these
same old arguments -- we've already been over this more than once in
this very thread!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:09:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO1l-0002mE-0p; Tue, 26 Feb 2013 17:09: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 1UAO1j-0002m1-LZ
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:09:15 +0000
Received: from [85.158.139.83:26017] by server-13.bemta-5.messagelabs.com id
	CA/2D-16871-A3CEC215; Tue, 26 Feb 2013 17:09:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361898554!27286953!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23481 invoked from network); 26 Feb 2013 17:09:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:09:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1912916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:09: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.297.1;
	Tue, 26 Feb 2013 17:09:13 +0000
Message-ID: <1361898552.26546.317.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 17:09:12 +0000
In-Reply-To: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 16:45 +0000, Stefano Stabellini wrote:
> Also there are many reasons why somebody would want to rebuild his
> own Xen package from xen-unstable instead of the deb source.

Nothing is stopping them doing this, but the deb target in the xen tree
is not aimed at them.

> > I do object to these.  "Getting the bits onto your system" doesn't
> > include automatically starting the daemons.
> 
> No matter what we think the objective of the deb target is, it cannot be
> an excuse to do only half of the job.

The current deb target does exactly what it was intended to do, no more
and no less. It does not do half a job at its intended goal. Note that
it's goal is not and never was to provide a completely usable package
for end users.

> Even if it is just for testing, I would want the init scripts to
> be started automatically on my testbox, why should I do that manually?

Because the deb target is a "removable tarball" nothing more. Do you
expect that a tarball would do this?

Do you expect that this deb package should also frob your bootloader
configuration? What about setting up bridged networking? Where do we
draw the line?

If we cannot agree on this then I propose we remove the existing deb
target, since I don't think a full and proper .deb (or .rpm or ebuild or
xxx) packaging has any place in the main Xen tree, that is what the
distros are for. Otherwise we are going to be constantly rehashing these
same old arguments -- we've already been over this more than once in
this very thread!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:10:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:10: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 1UAO2R-0002rt-2m; Tue, 26 Feb 2013 17:09: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 1UAO2P-0002rU-OF
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:09:57 +0000
Received: from [85.158.137.99:9415] by server-5.bemta-3.messagelabs.com id
	F2/27-04457-56CEC215; Tue, 26 Feb 2013 17:09:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361898596!13472103!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6094 invoked from network); 26 Feb 2013 17:09:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1912949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:09: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.297.1; Tue, 26 Feb 2013 17:09:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAO2O-0008Rr-6q; Tue, 26 Feb 2013 17:09:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAO2N-0001qE-Vr;
	Tue, 26 Feb 2013 17:09:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.60511.375340.303132@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:09:51 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130226170520.GC22422@phenom.dumpdata.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
	<20780.57185.786644.525993@mariner.uk.xensource.com>
	<20130226170520.GC22422@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>,
	"ian.campbel@citrix.com" <ian.campbel@citrix.com>
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup
 section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup section to include ELF and memory layout"):
> On Tue, Feb 26, 2013 at 04:14:25PM +0000, Ian Jackson wrote:
> > This line is too long for a .txt file; it shoudl be 70 or maybe 75.
> > This is a problem throughout the file.
> 
> Huh? This goes on the Wiki so I am not sure if we need to worry about that.

Oh sorry, I'm confused.  I saw ".txt" in your patch and thought this
was a patch to a file in the Xen tree's docs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:10:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:10: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 1UAO2R-0002rt-2m; Tue, 26 Feb 2013 17:09: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 1UAO2P-0002rU-OF
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:09:57 +0000
Received: from [85.158.137.99:9415] by server-5.bemta-3.messagelabs.com id
	F2/27-04457-56CEC215; Tue, 26 Feb 2013 17:09:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361898596!13472103!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6094 invoked from network); 26 Feb 2013 17:09:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1912949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:09: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.297.1; Tue, 26 Feb 2013 17:09:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAO2O-0008Rr-6q; Tue, 26 Feb 2013 17:09:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAO2N-0001qE-Vr;
	Tue, 26 Feb 2013 17:09:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.60511.375340.303132@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:09:51 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130226170520.GC22422@phenom.dumpdata.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
	<20780.57185.786644.525993@mariner.uk.xensource.com>
	<20130226170520.GC22422@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>,
	"ian.campbel@citrix.com" <ian.campbel@citrix.com>
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup
 section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup section to include ELF and memory layout"):
> On Tue, Feb 26, 2013 at 04:14:25PM +0000, Ian Jackson wrote:
> > This line is too long for a .txt file; it shoudl be 70 or maybe 75.
> > This is a problem throughout the file.
> 
> Huh? This goes on the Wiki so I am not sure if we need to worry about that.

Oh sorry, I'm confused.  I saw ".txt" in your patch and thought this
was a patch to a file in the Xen tree's docs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:10: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 1UAO2L-0002qx-Ly; Tue, 26 Feb 2013 17:09:53 +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 1UAO2K-0002qj-Cc
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:09:52 +0000
Received: from [193.109.254.147:57018] by server-1.bemta-14.messagelabs.com id
	F3/08-29874-F5CEC215; Tue, 26 Feb 2013 17:09:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361898590!2544391!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14707 invoked from network); 26 Feb 2013 17:09:51 -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; 26 Feb 2013 17:09:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAO2G-000PVH-46; Tue, 26 Feb 2013 17:09:48 +0000
Date: Tue, 26 Feb 2013 17:09:48 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130226170948.GE93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 16:45 +0000 on 26 Feb (1361897101), Stefano Stabellini wrote:
> > I do object to these.  "Getting the bits onto your system" doesn't
> > include automatically starting the daemons.
> 
> No matter what we think the objective of the deb target is, it cannot be
> an excuse to do only half of the job.

Speaking as its author, I know what the objective is: to unpack what
'make install' would do, and remove it again afterwards.  The fact that
it uses a .deb package for that is unfortunate, because it leads people
to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
manifest for uninstalling.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:10:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:10: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 1UAO2L-0002qx-Ly; Tue, 26 Feb 2013 17:09:53 +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 1UAO2K-0002qj-Cc
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:09:52 +0000
Received: from [193.109.254.147:57018] by server-1.bemta-14.messagelabs.com id
	F3/08-29874-F5CEC215; Tue, 26 Feb 2013 17:09:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361898590!2544391!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14707 invoked from network); 26 Feb 2013 17:09:51 -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; 26 Feb 2013 17:09:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAO2G-000PVH-46; Tue, 26 Feb 2013 17:09:48 +0000
Date: Tue, 26 Feb 2013 17:09:48 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130226170948.GE93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 16:45 +0000 on 26 Feb (1361897101), Stefano Stabellini wrote:
> > I do object to these.  "Getting the bits onto your system" doesn't
> > include automatically starting the daemons.
> 
> No matter what we think the objective of the deb target is, it cannot be
> an excuse to do only half of the job.

Speaking as its author, I know what the objective is: to unpack what
'make install' would do, and remove it again afterwards.  The fact that
it uses a .deb package for that is unfortunate, because it leads people
to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
manifest for uninstalling.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:12:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO4e-0003Bi-Ko; Tue, 26 Feb 2013 17:12:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1UAO4c-0003BO-Pe
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:12:15 +0000
Received: from [85.158.139.211:23906] by server-14.bemta-5.messagelabs.com id
	7B/43-13158-EECEC215; Tue, 26 Feb 2013 17:12:14 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361898708!18442756!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11908 invoked from network); 26 Feb 2013 17:11:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-206.messagelabs.com with SMTP;
	26 Feb 2013 17:11:53 -0000
Received: from p5b2e1b98.dip.t-dialin.net ([91.46.27.152] 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 1UAO49-0004Ps-Fu; Tue, 26 Feb 2013 17:11:45 +0000
Message-ID: <512CECCE.3070305@canonical.com>
Date: Tue, 26 Feb 2013 18:11:42 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
In-Reply-To: <20130226170330.GB22422@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.6
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2439896911099820513=="
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)
--===============2439896911099820513==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig351F714F7D60569A30F41ADA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig351F714F7D60569A30F41ADA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
>> On 25.02.2013 10:10, Stefan Bader wrote:
>>> On 25.02.2013 04:15, Liu, Jinsong wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>>>>> Hi Konrad,
>>>>>
>>>>> Hey Stefan,
>>>>>>
>>>>>> here is another one from the hm-what? department:
>>>>>
>>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as=

>>>>> he has been tracking a similar one with mcelog.
>>>>>>
>>>>>> Colin discovered that running the attached program with the fork
>>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that =
or
>>>>>> iomem) this triggers the following weird messages:=20
>>>>>>
>>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>>>>> [ 6824.453776] ------------[ cut here ]------------
>>>>>> [ 6824.453796] WARNING: at
>>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>>>>> mmap-example Tainted: GF=20
>>>>>> 3.8.0-6-generic #13-Ubuntu
>>>>>> [ 6824.453926] Call Trace:
>>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc=
0
>>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.45407=
6]
>>>>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>>>>
>>>>>> I found that this is related to your bandaid patch
>>>>>>
>>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>>>>
>>>>>>     xen/pat: Disable PAT support for now.
>>>>>>
>>>>>> I just do not understand how this happens. From the trace it seems=

>>>>>> the fork=20
>>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). S=
o
>>>>>> maybe the=20
>>>>>> warning is just related to this. So primarily the question is how =
on
>>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>>>>> cleared from the supported=20
>>>>>> mask by the patch, so somehow I would think nothing should be able=

>>>>>> to set it...=20
>>>>>> But apparently not so.
>>>>>> Not sure it is a big deal since I never saw this in normal operati=
on
>>>>>> and it=20
>>>>>> seems to be ok when unapping before doing the fork. It is just pla=
in
>>>>>> odd.=20
>>>>>
>>>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow =
the
>>>>> ranges are swapped or not correct. Jinsong, could you shed some lig=
ht
>>>>> on what you have found so far?
>>>>>
>>>>
>>>> Yes, Sander once also reported a similar weird warning when start mc=
elog daemon, as attached.
>>>>
>>>> Basically, it occurs when mcelog user daemon start,=20
>>>> do_fork
>>>>   --> copy_process
>>>>     --> dup_mm
>>>>       --> dup_mmap
>>>>         --> copy_page_range
>>>>           --> track_pfn_copy
>>>>             --> reserve_pfn_range
>>
>> So that makes it clearer as this will do
>>
>> reserve_memtype(...)
>> --> pat_x_mtrr_type
>>   --> mtrr_type_lookup
>>     --> __mtrr_type_lookup
>>
>> And that can return -1/0xff in case of mtrr not being enabled/initiali=
zed. Which
>> is not the case (given there are no messages for it in dmesg). This is=
 not equal
>> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
>>
>> It looks like the problem starts early in reserve_memtype:
>>
>>         if (!pat_enabled) {
>>                 /* This is identical to page table setting without PAT=
 */
>>                 if (new_type) {
>>                         if (req_type =3D=3D _PAGE_CACHE_WC)
>>                                 *new_type =3D _PAGE_CACHE_UC_MINUS;
>>                         else
>>                                 *new_type =3D req_type & _PAGE_CACHE_M=
ASK;
>>                 }
>>                 return 0;
>>         }
>>
>> This would be what we want, but only clearing the PWT and PCD flags fr=
om the
>> supported flags is not changing pat_enabled (which is 1 when PAT suppo=
rt is
>> compiled into the kernel). Unfortunately the variable is local and sin=
ce there
>> are not any messages about PAT in dmesg I would say pat_init() is not =
called
>> either. Which might be used to disable PAT support by clearing the CPU=
 feature
>> flag.
>=20
> Hm, so:
>=20
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 39928d1..9ac70c5 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
> =20
>         cpuid_leaf1_edx_mask =3D
>                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
>                   (1 << X86_FEATURE_ACC));   /* thermal monitoring */
> =20
>         if (!xen_initial_domain())
>=20
>=20
>=20
> should do it right? Let me check on the troublesome machine I saw
> it.
>=20
I could try it as well but somehow my reading of pat_init() is that if th=
at
would have been called at all, there should be some message about PAT in =
dmesg.
And normal dom0 boots do not show anything.

It looks like pat_init only gets called from two places in mtrr code, and=
 that
probably is not done in dom0 either. So clearing the feature is one step,=
 but I
would think that also there needs to be a call to pat_init...

-Stefan


--------------enig351F714F7D60569A30F41ADA
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLOzOAAoJEOhnXe7L7s6jwmoQAIGRjO0yPCkqAZ1TvZBGMAoG
t3L7kymQruKXs9oE2sDUokBJDUdwaU9T/V20LXhwimHdix4ax96dew+p6NEyZXYS
zydb2/TjcgAWD1rvgon1CpwKVTwXJdDG1xuo1WWr2B5KALwfiBHJhXnUqH5vi6Ar
qRCigw5HwfNyx6pxG3WYR7Lb9fFBfzufbJ/+UzFKDwGbmrNAscwrzxhs3HUNhoR2
wWuST+Fjkilc02ZyVzPuJh0mMScKvq3z+czBJxsQzUyGgbChaTswvRSkIYN3x6Mm
NuQp6b39TEbyQ1k2ZXq0ijpM6XczEObUEToQ6yPoVd2UU3nsDQiOiXSIPmDpmfF2
teJF0pQj9Vw2Q89rZuiUBFR6yJtyUlGlCR+HiuUBnC04tuoeZeK68dOYSfk44oHn
lGoWgcqOowzuQfTCiTh0ZxvM9CwaeSAJY3kQxHRzUocGAVIQLi9NJinR9CmytbPv
G1BA6+ClOOQhWawhoCfYw/iEkzdmRByhQvgO5NcG2DjKwJSejmiu+E2Ka5USv0AO
N1Ra1YyFwxwGvyhDkLmkzj3xQWUHIHTmZasj/vd5CQPE2UPMS+7+1hTXQdvJXF/w
mxqhU56jEr/cOsWMYSt+vqz9Mucj4ka1o7H2nnWDRw2qMn3DoNQ35+o52XDjBXQU
mFc6hxyfo+lyWYLOQBRo
=OAQR
-----END PGP SIGNATURE-----

--------------enig351F714F7D60569A30F41ADA--


--===============2439896911099820513==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2439896911099820513==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:12:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO4e-0003Bi-Ko; Tue, 26 Feb 2013 17:12:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1UAO4c-0003BO-Pe
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:12:15 +0000
Received: from [85.158.139.211:23906] by server-14.bemta-5.messagelabs.com id
	7B/43-13158-EECEC215; Tue, 26 Feb 2013 17:12:14 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361898708!18442756!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11908 invoked from network); 26 Feb 2013 17:11:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-206.messagelabs.com with SMTP;
	26 Feb 2013 17:11:53 -0000
Received: from p5b2e1b98.dip.t-dialin.net ([91.46.27.152] 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 1UAO49-0004Ps-Fu; Tue, 26 Feb 2013 17:11:45 +0000
Message-ID: <512CECCE.3070305@canonical.com>
Date: Tue, 26 Feb 2013 18:11:42 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
In-Reply-To: <20130226170330.GB22422@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.6
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2439896911099820513=="
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)
--===============2439896911099820513==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig351F714F7D60569A30F41ADA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig351F714F7D60569A30F41ADA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
>> On 25.02.2013 10:10, Stefan Bader wrote:
>>> On 25.02.2013 04:15, Liu, Jinsong wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>>>>> Hi Konrad,
>>>>>
>>>>> Hey Stefan,
>>>>>>
>>>>>> here is another one from the hm-what? department:
>>>>>
>>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as=

>>>>> he has been tracking a similar one with mcelog.
>>>>>>
>>>>>> Colin discovered that running the attached program with the fork
>>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that =
or
>>>>>> iomem) this triggers the following weird messages:=20
>>>>>>
>>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>>>>> [ 6824.453776] ------------[ cut here ]------------
>>>>>> [ 6824.453796] WARNING: at
>>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>>>>> mmap-example Tainted: GF=20
>>>>>> 3.8.0-6-generic #13-Ubuntu
>>>>>> [ 6824.453926] Call Trace:
>>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc=
0
>>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
>>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
>>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.45407=
6]
>>>>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>>>>
>>>>>> I found that this is related to your bandaid patch
>>>>>>
>>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>>>>
>>>>>>     xen/pat: Disable PAT support for now.
>>>>>>
>>>>>> I just do not understand how this happens. From the trace it seems=

>>>>>> the fork=20
>>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). S=
o
>>>>>> maybe the=20
>>>>>> warning is just related to this. So primarily the question is how =
on
>>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>>>>> cleared from the supported=20
>>>>>> mask by the patch, so somehow I would think nothing should be able=

>>>>>> to set it...=20
>>>>>> But apparently not so.
>>>>>> Not sure it is a big deal since I never saw this in normal operati=
on
>>>>>> and it=20
>>>>>> seems to be ok when unapping before doing the fork. It is just pla=
in
>>>>>> odd.=20
>>>>>
>>>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow =
the
>>>>> ranges are swapped or not correct. Jinsong, could you shed some lig=
ht
>>>>> on what you have found so far?
>>>>>
>>>>
>>>> Yes, Sander once also reported a similar weird warning when start mc=
elog daemon, as attached.
>>>>
>>>> Basically, it occurs when mcelog user daemon start,=20
>>>> do_fork
>>>>   --> copy_process
>>>>     --> dup_mm
>>>>       --> dup_mmap
>>>>         --> copy_page_range
>>>>           --> track_pfn_copy
>>>>             --> reserve_pfn_range
>>
>> So that makes it clearer as this will do
>>
>> reserve_memtype(...)
>> --> pat_x_mtrr_type
>>   --> mtrr_type_lookup
>>     --> __mtrr_type_lookup
>>
>> And that can return -1/0xff in case of mtrr not being enabled/initiali=
zed. Which
>> is not the case (given there are no messages for it in dmesg). This is=
 not equal
>> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
>>
>> It looks like the problem starts early in reserve_memtype:
>>
>>         if (!pat_enabled) {
>>                 /* This is identical to page table setting without PAT=
 */
>>                 if (new_type) {
>>                         if (req_type =3D=3D _PAGE_CACHE_WC)
>>                                 *new_type =3D _PAGE_CACHE_UC_MINUS;
>>                         else
>>                                 *new_type =3D req_type & _PAGE_CACHE_M=
ASK;
>>                 }
>>                 return 0;
>>         }
>>
>> This would be what we want, but only clearing the PWT and PCD flags fr=
om the
>> supported flags is not changing pat_enabled (which is 1 when PAT suppo=
rt is
>> compiled into the kernel). Unfortunately the variable is local and sin=
ce there
>> are not any messages about PAT in dmesg I would say pat_init() is not =
called
>> either. Which might be used to disable PAT support by clearing the CPU=
 feature
>> flag.
>=20
> Hm, so:
>=20
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 39928d1..9ac70c5 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
> =20
>         cpuid_leaf1_edx_mask =3D
>                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
>                   (1 << X86_FEATURE_ACC));   /* thermal monitoring */
> =20
>         if (!xen_initial_domain())
>=20
>=20
>=20
> should do it right? Let me check on the troublesome machine I saw
> it.
>=20
I could try it as well but somehow my reading of pat_init() is that if th=
at
would have been called at all, there should be some message about PAT in =
dmesg.
And normal dom0 boots do not show anything.

It looks like pat_init only gets called from two places in mtrr code, and=
 that
probably is not done in dom0 either. So clearing the feature is one step,=
 but I
would think that also there needs to be a call to pat_init...

-Stefan


--------------enig351F714F7D60569A30F41ADA
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLOzOAAoJEOhnXe7L7s6jwmoQAIGRjO0yPCkqAZ1TvZBGMAoG
t3L7kymQruKXs9oE2sDUokBJDUdwaU9T/V20LXhwimHdix4ax96dew+p6NEyZXYS
zydb2/TjcgAWD1rvgon1CpwKVTwXJdDG1xuo1WWr2B5KALwfiBHJhXnUqH5vi6Ar
qRCigw5HwfNyx6pxG3WYR7Lb9fFBfzufbJ/+UzFKDwGbmrNAscwrzxhs3HUNhoR2
wWuST+Fjkilc02ZyVzPuJh0mMScKvq3z+czBJxsQzUyGgbChaTswvRSkIYN3x6Mm
NuQp6b39TEbyQ1k2ZXq0ijpM6XczEObUEToQ6yPoVd2UU3nsDQiOiXSIPmDpmfF2
teJF0pQj9Vw2Q89rZuiUBFR6yJtyUlGlCR+HiuUBnC04tuoeZeK68dOYSfk44oHn
lGoWgcqOowzuQfTCiTh0ZxvM9CwaeSAJY3kQxHRzUocGAVIQLi9NJinR9CmytbPv
G1BA6+ClOOQhWawhoCfYw/iEkzdmRByhQvgO5NcG2DjKwJSejmiu+E2Ka5USv0AO
N1Ra1YyFwxwGvyhDkLmkzj3xQWUHIHTmZasj/vd5CQPE2UPMS+7+1hTXQdvJXF/w
mxqhU56jEr/cOsWMYSt+vqz9Mucj4ka1o7H2nnWDRw2qMn3DoNQ35+o52XDjBXQU
mFc6hxyfo+lyWYLOQBRo
=OAQR
-----END PGP SIGNATURE-----

--------------enig351F714F7D60569A30F41ADA--


--===============2439896911099820513==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2439896911099820513==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:13:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO5J-0003Hu-A9; Tue, 26 Feb 2013 17:12:57 +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 1UAO5G-0003HZ-70
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:12:54 +0000
Received: from [193.109.254.147:33154] by server-13.bemta-14.messagelabs.com
	id EE/9A-30639-51DEC215; Tue, 26 Feb 2013 17:12:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361898744!2544830!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23321 invoked from network); 26 Feb 2013 17:12:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1913078"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:12: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.297.1; Tue, 26 Feb 2013 17:12:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAO4m-0008SJ-0L; Tue, 26 Feb 2013 17:12:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAO4l-0001qR-SC;
	Tue, 26 Feb 2013 17:12:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.60663.630676.707241@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:12:23 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226170948.GE93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Speaking as its author, I know what the objective is: to unpack what
> 'make install' would do, and remove it again afterwards.  The fact that
> it uses a .deb package for that is unfortunate, because it leads people
> to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
> manifest for uninstalling.

I think we should fix this problem by improving the documentation.

>From a technical point of view, a .deb is definitely the right thing.

And I do think that there is a plausible argument that the config
files ought not to be just blatted over the top of your system.  (If
"make install" does that then there's the same argument there - I
don't think "make install" should trash existing config.)

If you _want_ the config files trashed on deinstallation dpkg --purge IYF

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:13:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO5J-0003Hu-A9; Tue, 26 Feb 2013 17:12:57 +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 1UAO5G-0003HZ-70
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:12:54 +0000
Received: from [193.109.254.147:33154] by server-13.bemta-14.messagelabs.com
	id EE/9A-30639-51DEC215; Tue, 26 Feb 2013 17:12:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361898744!2544830!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23321 invoked from network); 26 Feb 2013 17:12:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1913078"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:12: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.297.1; Tue, 26 Feb 2013 17:12:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAO4m-0008SJ-0L; Tue, 26 Feb 2013 17:12:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAO4l-0001qR-SC;
	Tue, 26 Feb 2013 17:12:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.60663.630676.707241@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:12:23 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226170948.GE93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Speaking as its author, I know what the objective is: to unpack what
> 'make install' would do, and remove it again afterwards.  The fact that
> it uses a .deb package for that is unfortunate, because it leads people
> to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
> manifest for uninstalling.

I think we should fix this problem by improving the documentation.

>From a technical point of view, a .deb is definitely the right thing.

And I do think that there is a plausible argument that the config
files ought not to be just blatted over the top of your system.  (If
"make install" does that then there's the same argument there - I
don't think "make install" should trash existing config.)

If you _want_ the config files trashed on deinstallation dpkg --purge IYF

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:16:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO8i-0003hk-7d; Tue, 26 Feb 2013 17:16:28 +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 1UAO8g-0003hX-L9
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:16:26 +0000
Received: from [85.158.139.83:51504] by server-14.bemta-5.messagelabs.com id
	4A/5A-13158-9EDEC215; Tue, 26 Feb 2013 17:16:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361898983!29323466!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32009 invoked from network); 26 Feb 2013 17:16:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:16:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9754925"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:16:22 -0500
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 1UAO8c-0000I6-4l;
	Tue, 26 Feb 2013 17:16:22 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Feb 2013 17:08:17 +0000
Message-ID: <1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Original-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 804049e..189b56a 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
 
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue */
-    int max_weight;
+    unsigned int max_weight;
 
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
 
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
 
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -271,16 +272,24 @@ struct csched_dom {
 
 /*
  * Time-to-credit, credit-to-time.
+ * 
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
+                          struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val = time * rqd->max_weight + svc->residual;
+
+    svc->residual = do_div(val, svc->weight);
+    svc->credit -= val;
 }
 
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
 {
-    return credit * svc->weight / rqd->max_weight;
+    return (credit * svc->weight) / rqd->max_weight;
 }
 
 /*
@@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t
     delta = now - svc->start_time;
 
     if ( delta > 0 ) {
-        /* This will round down; should we consider rounding up...? */
-        svc->credit -= t2c(rqd, delta, svc);
+        t2c_update(rqd, delta, svc);
         svc->start_time = now;
 
         d2printk("b d%dv%d c%d\n",
-- 
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 Tue Feb 26 17:16:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAO8i-0003hk-7d; Tue, 26 Feb 2013 17:16:28 +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 1UAO8g-0003hX-L9
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:16:26 +0000
Received: from [85.158.139.83:51504] by server-14.bemta-5.messagelabs.com id
	4A/5A-13158-9EDEC215; Tue, 26 Feb 2013 17:16:25 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361898983!29323466!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32009 invoked from network); 26 Feb 2013 17:16:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:16:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9754925"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:16:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:16:22 -0500
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 1UAO8c-0000I6-4l;
	Tue, 26 Feb 2013 17:16:22 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Feb 2013 17:08:17 +0000
Message-ID: <1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Original-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 804049e..189b56a 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
 
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue */
-    int max_weight;
+    unsigned int max_weight;
 
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
 
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
 
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -271,16 +272,24 @@ struct csched_dom {
 
 /*
  * Time-to-credit, credit-to-time.
+ * 
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
+                          struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val = time * rqd->max_weight + svc->residual;
+
+    svc->residual = do_div(val, svc->weight);
+    svc->credit -= val;
 }
 
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
 {
-    return credit * svc->weight / rqd->max_weight;
+    return (credit * svc->weight) / rqd->max_weight;
 }
 
 /*
@@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t
     delta = now - svc->start_time;
 
     if ( delta > 0 ) {
-        /* This will round down; should we consider rounding up...? */
-        svc->credit -= t2c(rqd, delta, svc);
+        t2c_update(rqd, delta, svc);
         svc->start_time = now;
 
         d2printk("b d%dv%d c%d\n",
-- 
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 Tue Feb 26 17:16:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:16: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 1UAO8l-0003iN-La; Tue, 26 Feb 2013 17:16: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 1UAO8k-0003i4-7D
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:16:30 +0000
Received: from [85.158.139.211:15340] by server-15.bemta-5.messagelabs.com id
	15/D5-22815-DEDEC215; Tue, 26 Feb 2013 17:16:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361898985!19309913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4402 invoked from network); 26 Feb 2013 17:16:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9277430"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:16:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:16:16 -0500
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 1UAO8W-0000I6-4A;
	Tue, 26 Feb 2013 17:16:16 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Feb 2013 17:08:16 +0000
Message-ID: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen,
	credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen,credit2: Avoid extra c2t calcuation in csched_runtime

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b0af010..804049e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 static s_time_t
 csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
+    s_time_t time; 
+    int rt_credit; /* Proposed runtime measured in credits */
     struct csched_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
         return CSCHED_MAX_TIMER;
 
-    /* Basic time */
-    time = c2t(rqd, snext->credit, snext);
+    /* General algorithm:
+     * 1) Run until snext's credit will be 0
+     * 2) But if someone is waiting, run until snext's credit is equal
+     * to his
+     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
+     */
+
+    /* 1) Basic time: Run until credit is 0. */
+    rt_credit = snext->credit;
 
-    /* Next guy on runqueue */
+    /* 2) If there's someone waiting whose credit is positive,
+     * run until your credit ~= his */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
-        s_time_t ntime;
+        struct csched_vcpu *swait = __runq_elem(runq->next);
 
-        if ( ! is_idle_vcpu(svc->vcpu) )
+        if ( ! is_idle_vcpu(swait->vcpu)
+             && swait->credit > 0 )
         {
-            ntime = c2t(rqd, snext->credit - svc->credit, snext);
-
-            if ( time > ntime )
-                time = ntime;
+            rt_credit = snext->credit - swait->credit;
         }
     }
 
+    /*
+     * snext is about to be scheduled; so:
+     *
+     * 1. if snext->credit were less than 0 when it was taken off the
+     * runqueue, then csched_schedule() should have called
+     * reset_credit().  So at this point snext->credit must be greater
+     * than 0.
+     *
+     * 2. snext's credit must be greater than or equal to anyone else
+     * in the queue, so snext->credit - swait->credit must be greater
+     * than or equal to 0.
+     */
+    ASSERT(rt_credit >= 0);
+
+    /* FIXME: See if we can eliminate this conversion if we know time
+     * will be outside (MIN,MAX).  Probably requires pre-calculating
+     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
+     * at a different rate. */
+    time = c2t(rqd, rt_credit, snext);
+
     /* Check limits */
     if ( time < CSCHED_MIN_TIMER )
         time = CSCHED_MIN_TIMER;
-- 
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 Tue Feb 26 17:16:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:16: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 1UAO8l-0003iN-La; Tue, 26 Feb 2013 17:16: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 1UAO8k-0003i4-7D
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:16:30 +0000
Received: from [85.158.139.211:15340] by server-15.bemta-5.messagelabs.com id
	15/D5-22815-DEDEC215; Tue, 26 Feb 2013 17:16:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361898985!19309913!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4402 invoked from network); 26 Feb 2013 17:16:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9277430"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:16:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:16:16 -0500
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 1UAO8W-0000I6-4A;
	Tue, 26 Feb 2013 17:16:16 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 26 Feb 2013 17:08:16 +0000
Message-ID: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] xen,
	credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
xen,credit2: Avoid extra c2t calcuation in csched_runtime

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b0af010..804049e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 static s_time_t
 csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
+    s_time_t time; 
+    int rt_credit; /* Proposed runtime measured in credits */
     struct csched_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
         return CSCHED_MAX_TIMER;
 
-    /* Basic time */
-    time = c2t(rqd, snext->credit, snext);
+    /* General algorithm:
+     * 1) Run until snext's credit will be 0
+     * 2) But if someone is waiting, run until snext's credit is equal
+     * to his
+     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
+     */
+
+    /* 1) Basic time: Run until credit is 0. */
+    rt_credit = snext->credit;
 
-    /* Next guy on runqueue */
+    /* 2) If there's someone waiting whose credit is positive,
+     * run until your credit ~= his */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
-        s_time_t ntime;
+        struct csched_vcpu *swait = __runq_elem(runq->next);
 
-        if ( ! is_idle_vcpu(svc->vcpu) )
+        if ( ! is_idle_vcpu(swait->vcpu)
+             && swait->credit > 0 )
         {
-            ntime = c2t(rqd, snext->credit - svc->credit, snext);
-
-            if ( time > ntime )
-                time = ntime;
+            rt_credit = snext->credit - swait->credit;
         }
     }
 
+    /*
+     * snext is about to be scheduled; so:
+     *
+     * 1. if snext->credit were less than 0 when it was taken off the
+     * runqueue, then csched_schedule() should have called
+     * reset_credit().  So at this point snext->credit must be greater
+     * than 0.
+     *
+     * 2. snext's credit must be greater than or equal to anyone else
+     * in the queue, so snext->credit - swait->credit must be greater
+     * than or equal to 0.
+     */
+    ASSERT(rt_credit >= 0);
+
+    /* FIXME: See if we can eliminate this conversion if we know time
+     * will be outside (MIN,MAX).  Probably requires pre-calculating
+     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
+     * at a different rate. */
+    time = c2t(rqd, rt_credit, snext);
+
     /* Check limits */
     if ( time < CSCHED_MIN_TIMER )
         time = CSCHED_MIN_TIMER;
-- 
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 Tue Feb 26 17:18:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:18: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 1UAOAy-00040P-FC; Tue, 26 Feb 2013 17:18:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UAOAw-000409-68
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:18:46 +0000
Received: from [85.158.139.211:35808] by server-12.bemta-5.messagelabs.com id
	B4/98-11486-57EEC215; Tue, 26 Feb 2013 17:18:45 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361899119!19434303!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14938 invoked from network); 26 Feb 2013 17:18:39 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:18:39 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UAOAo-0006qE-IL; Tue, 26 Feb 2013 18:18:38 +0100
Message-ID: <512CEE69.8070408@mfiala.net>
Date: Tue, 26 Feb 2013 18:18:33 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <512CC78B.4080606@mfiala.net>
	<20130226165614.GA22422@phenom.dumpdata.com>
In-Reply-To: <20130226165614.GA22422@phenom.dumpdata.com>
X-Enigmail-Version: 1.5
Content-Type: multipart/mixed; boundary="------------000609010708080401060703"
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------000609010708080401060703
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/26/2013 05:56 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 03:32:43PM +0100, Michal Fiala wrote:
>> Hallo,
>>
>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>> without problem. When I run reboot or shutdown -r now, system correctly
>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>> I have the same problem with kernel linux 3.2.37. When I shudown system
>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>> xen hypervisor, it was without problems. Required debug informations
>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>> Could you please help me with this problem?
>>
>> Thanks
>>
>> Michal
>>
> 
> 
>> INIT: Switching to runlevel: 6
>> INIT: Sending processes the TERM signal
>>  * Stopping local
>>  [ ok ]
>>  * Stopping vixie-cron ...
>>  [ ok ]
>>  * Saving random seed ...
>>  [ ok ]
>>  * Deactivating additional swap space ...
>>  [ ok ]
>>  * Stopping sshd ...
>>  [ ok ]
>>  * Use of the opts variable is deprecated and will be
>>  * removed in the future.
>>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>>  * Stopping Xen control daemon ...
>>  [ ok ]
>>  * Stoping xenconsoled daemon ...
>>  [ ok ]
>>  * Stopping... ...
>>  [ ok ]
>>  * Stopping ntpd ...
>>  [ ok ]
>>  * Stopping xenstored daemon ...
>>  [ ok ]
>>  * Stopping nrpe ...
>>  [ ok ]
>>  * Unmounting network filesystems ...
>>  [ ok ]
>>  * Stopping munin-node ...
>>  [ ok ]
>>  * Stopping fail2ban ...
>>  [ ok ]
>>  * Stopping bacula file daemon ...
>>  [ ok ]
>>  * Stopping syslog-ng ...
>>  [ ok ]
>>  * Bringing down interface br0
>>  *   Destroying bridge br0 ...
>>  [ ok ]
>>  * Bringing down interface bond0
>>  *   Removing slaves from bond0 ...
>>  *     eth0 eth1 
>>  [ ok ]
>>  * Use of the opts variable is deprecated and will be
>>  * removed in the future.
>>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>>  * Stopping firewall ...
>>  [ ok ]
>>  * Bringing down interface lo
>>  * Unmounting loop devices
>>  * Unmounting filesystems
>>  *   Unmounting /boot ...
>>  [ ok ]
>>  *   Unmounting /data/d0700 ...
>>  [ ok ]
>>  *   Unmounting /var ...
>>  [ ok ]
>>  * Deactivating swap devices ...
>>  [ ok ]
>>  * Shutting down the Logical Volume Manager
>>  *   Shutting Down LVs & VGs ...
>>   Command failed with status code 2.
>>   No such command.  Try 'help'.
>>  * Failed
>>  [ !! ]
>>  * Finished Shutting down the Logical Volume Manager
>>  * Stopping udev ...
>>  [ ok ]
>>  * Setting hardware clock using the system clock [UTC] ...
>>  [ ok ]
>>  * Terminating remaining processes ...
>>  [ ok ]
>>  * Killing remaining processes ...
>>  [ ok ]
>>  * Saving dependency cache ...
>>  [ ok ]
>>  * Remounting remaining filesystems read-only ...
>>  *   Remounting / read only ...
>>  [ ok ]
>>  [ ok ]
>> [  612.749666] Restarting system.
>> [  618.364165] int3: 0000 [#1] SMP 
>> [  618.364396] Modules linked in: bonding
>> [  618.364590] CPU 0 
>> [  618.364658] Pid: 9998, comm: reboot Tainted: G        W    3.7.5-hardened #4 Dell Inc. PowerEdge R720xd/0VWT90
>> [  618.364806] RIP: e030:[<ffffffff8102a894>]  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
>> [  618.364956] RSP: e02b:ffff880136b35da8  EFLAGS: 00000046
>> [  618.365130] RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffffff8172ad90
>> [  618.365308] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81ad8cdc
>> [  618.365487] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
>> [  618.365663] R10: 00000000000005dd R11: 0000000000000000 R12: 0000000000000cf9
>> [  618.365867] R13: ffffffff8172ad90 R14: 0000000000000061 R15: 0000000000000000
>> [  618.366045] FS:  00007f32051f0700(0000) GS:ffff88013d600000(0000) knlGS:0000000000000000
>> [  618.366317] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  618.366489] CR2: 00007fa697fb3d30 CR3: 0000000135590000 CR4: 0000000000042660
>> [  618.366664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  618.366839] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  618.367013] Process reboot (pid: 9998, threadinfo ffff880137af3b90, task ffff880137af3780)
>> [  618.367288] Stack:
>> [  618.367482]  0000000000000009 0000000081045315 0000000000000000 0000000001234567
>> [  618.368001]  0000000028121969 0000000000000022 0000000000000000 0000000000000000
>> [  618.368527]  0000000001234567 0000000028121969 0000000000000022 00007f3205203248
>> [  618.369079] Call Trace:
>> [  618.369250]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
> 
> native machine restart? It should have been xen_restart!

Boot xen.gz, dom0 kernel, login to console as a root, run reboot.

> 
> Can you attach the full bootup serial log please?

see attachment, it is also included in my first mail in tgz package.

> 
> What distro is this?

Gentoo Base System release 2.1

> 

Now I am playing with kernel reboot parameter, I have tried
reboot=b, restart also with some problems.

[  110.416591] Restarting system.
(XEN) mm.c:2518:d0 Bad type (saw 7400000000000001 != exp
4000000000000000) for )
(XEN) mm.c:2846:d0 Error while installing new baseptr 102c09b
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    000b:[<0000000000099220>]
(XEN) RFLAGS: 0000000000010292   EM: 1   CONTEXT: pv guest
(XEN) rax: ffff880000098000   rbx: 0000000000000000   rcx: ffffffff81b08640
(XEN) rdx: 0000000000000000   rsi: 0000000000000006   rdi: 0000000000000000
(XEN) rbp: 0000000000000000   rsp: 0000000034147d98   r8:  000000000000000a
(XEN) r9:  0000000000000000   r10: 00000000000005e0   r11: 00000000000005df
(XEN) r12: 0000000000000cf9   r13: ffffffff8172ad90   r14: 0000000000000062
(XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000426f0
(XEN) cr3: 00000008fd86a000   cr2: 0000000000099220
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: 000b
(XEN) Guest stack trace from rsp=0000000034147d98:
(XEN)   Fault while accessing guest memory.
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

--------------000609010708080401060703
Content-Type: text/plain; charset=UTF-8;
 name="full_serial_console_output.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="full_serial_console_output.txt"

  Booting 'Xen 4.2 / linux-3.7.5-hardened'
                                                                    
root (hd0,0)
 Filesystem type is xfs, partition type 0x83
kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0
console=com2 com2=115200,8n1
   [Multiboot-elf, <0x100000:0x197828:0x527d8>, shtab=0x2ea078, entry=0x100000]
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
   [Multiboot-module @ 0x2eb000, 0x4dc160 bytes]

 \ \/ /___ _ __   | || |  |___ \  / |
  \  // _ \ '_ \  | || |_   __) | | |
  /  \  __/ | | | |__   _| / __/ _| |
 /_/\_\___|_| |_|    |_|(_)_____(_)_|
                                     
(XEN) Xen version 4.2.1 (@mobil.cz) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Tue 3
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0 console=c1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e000 (usable)
(XEN)  0000000000100000 - 00000000bd2f0000 (usable)
(XEN)  00000000bd2f0000 - 00000000bd31c000 (reserved)
(XEN)  00000000bd31c000 - 00000000bd35b000 (ACPI data)
(XEN)  00000000bd35b000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000002040000000 (usable)
(XEN) ACPI: RSDP 000F0F40, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1048, 00A4 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BD3411CC, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BD31C000, 7760 (r1 DELL   PE_SC3          1 INTL 20110211)
(XEN) ACPI: FACS BD343000, 0040
(XEN) ACPI: APIC BD340478, 016A (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BD3405E4, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BD340638, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BD340674, 0158 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BD340990, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BD3409D0, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BD340B08, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BD323920, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BD323B90, 059C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BD323760, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BD323790, 0190 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BD341164, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: PC__ BD3410F4, 006E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BD340D30, 03C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BD344000, 7624 (r1 INTEL  PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 131026MB (134171192kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
(XEN) IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) ERST table is invalid
(XEN) Would not enable x2APIC due to interrupt remapping cannot be enabled.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2500.081 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) 'A' pressed -> using normal key handling
(XEN) Allocated console ring of 64 KiB.
(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, 1GB
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) Brought up 24 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2000000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000102c000000->0000001030000000 (1032192 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82000000
(XEN)  Init. ramdisk: ffffffff82000000->ffffffff82000000
(XEN)  Phys-Mach map: ffffffff82000000->ffffffff82800000
(XEN)  Start info:    ffffffff82800000->ffffffff828004b4
(XEN)  Page tables:   ffffffff82801000->ffffffff8281a000
(XEN)  Boot stack:    ffffffff8281a000->ffffffff8281b000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a281c0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ....................................................................
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.5-hardened (root@rajvir3) (gcc version 4.6.3 (Gentoo Hardene3
[    0.000000] Command line: root=/dev/sda6 console=tty0 console=hvc0
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing bd2f0-100000 pfn range: 273680 pages freed
[    0.000000] Released 273778 pages of unused memory
[    0.000000] Set 273778 page(s) to 1-1 mapping
[    0.000000] Populating 100000-142d72 pfn range: 273778 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bd2effff] usable
[    0.000000] Xen: [mem 0x00000000bd2f0000-0x00000000bd31bfff] reserved
[    0.000000] Xen: [mem 0x00000000bd31c000-0x00000000bd35afff] ACPI data
[    0.000000] Xen: [mem 0x00000000bd35b000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000142d71fff] usable
[    0.000000] Xen: [mem 0x0000000142d72000-0x000000203fffffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x142d72 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbd2f0 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0xbd2effff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: RSDP 00000000000f0f40 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000f1048 000A4 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: FACP 00000000bd3411cc 000F4 (v03 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: DSDT 00000000bd31c000 07760 (v01 DELL   PE_SC3   00000001 INTL 20110211)
[    0.000000] ACPI: FACS 00000000bd343000 00040
[    0.000000] ACPI: APIC 00000000bd340478 0016A (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SPCR 00000000bd3405e4 00050 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HPET 00000000bd340638 00038 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: XMAR 00000000bd340674 00158 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: MCFG 00000000bd340990 0003C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: WD__ 00000000bd3409d0 00134 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SLIC 00000000bd340b08 00024 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: ERST 00000000bd323920 00270 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HEST 00000000bd323b90 0059C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: BERT 00000000bd323760 00030 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: EINJ 00000000bd323790 00190 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: TCPA 00000000bd341164 00064 (v02 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: PC__ 00000000bd3410f4 0006E (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SRAT 00000000bd340d30 003C0 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SSDT 00000000bd344000 07624 (v01 INTEL  PPM RCM  80000001 INTL 20061109)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000142d71fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x142d71fff]
[    0.000000]   NODE_DATA [mem 0x142d6e000-0x142d71fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x142d71fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0xbd2effff]
[    0.000000]   node   0: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x26] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x28] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x2a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x27] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x09] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x29] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x0b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x2b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x59] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x5b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x5d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x5f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[64])
[    0.000000] IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 32 CPUs, 8 hotplug CPUs
[    0.000000] e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88013d600000 s64512 r8192 d21504 u131072
[   50.166367] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1026398
[   50.166369] Policy zone: Normal
[   50.166371] Kernel command line: root=/dev/sda6 console=tty0 console=hvc0
[   50.166402] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   50.166406] __ex_table already sorted, skipping sort
[   50.166434] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[   50.194619] software IO TLB [mem 0x139600000-0x13d5fffff] (64MB) mapped at [ffff8801396000]
[   50.207444] Memory: 4029096k/5289416k available (7106k kernel code, 1095176k absent, 16514)
[   50.207520] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[   50.207550] Hierarchical RCU implementation.
[   50.207551]  RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=4.
[   50.207560] NR_IRQS:4352 nr_irqs:1024 16
[   50.207625] xen: sci override: global_irq=9 trigger=0 polarity=0
[   50.207662] xen: acpi sci 9
[   50.216286] Console: colour VGA+ 80x25
[   50.237789] console [tty0] enabled
[   50.238195] console [hvc0] enabled
[   50.238390] installing Xen timer for CPU 0
[   50.238580] tsc: Detected 2500.080 MHz processor
[   50.238751] Calibrating delay loop (skipped), value calculated using timer frequency.. 500)
[   50.239096] pid_max: default: 32768 minimum: 501
[   50.239801] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   50.240915] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   50.241431] Mount-cache hash table entries: 256
[   50.241801] Initializing cgroup subsys cpuacct
[   50.241973] Initializing cgroup subsys freezer
[   50.242199] CPU: Physical Processor ID: 0
[   50.242368] CPU: Processor Core ID: 0
[   50.242536] mce: CPU supports 2 MCE banks
[   50.242766] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[   50.242766] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[   50.242766] tlb_flushall_shift: 5
[   50.243423] Freeing SMP alternatives: 32k freed
[    0.007054] ACPI: Core revision 20120913
[    0.009510] cpu 0 spinlock event irq 105
[    0.009693] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events.
[    0.010286] installing Xen timer for CPU 1
[    0.010463] cpu 1 spinlock event irq 112
[    0.010848] installing Xen timer for CPU 2
[    0.011023] cpu 2 spinlock event irq 119
[    0.011363] installing Xen timer for CPU 3
[    0.011537] cpu 3 spinlock event irq 126
[    0.011844] Brought up 4 CPUs
[    0.012277] devtmpfs: initialized
[    0.012713] xor: automatically using best checksumming function:
[    0.052559]    avx       : 22051.000 MB/sec
[    0.052734] Grant tables using version 2 layout.
[    0.052912] Grant table initialized
[    0.053118] NET: Registered protocol family 16
[    0.053816] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.054090] ACPI: bus type pci registered
[    0.055403] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base)
[    0.055684] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.086464] PCI: Using configuration type 1 for base access
[    0.086664] PCI: Dell System detected, enabling pci=bfsort.
[    0.094712] bio: create slab <bio-0> at 0
[    0.161842] raid6: sse2x1    7662 MB/s
[    0.230644] raid6: sse2x2    9538 MB/s
[    0.299461] raid6: sse2x4   10973 MB/s
[    0.299628] raid6: using algorithm sse2x4 (10973 MB/s)
[    0.299798] raid6: using ssse3x2 recovery algorithm
[    0.299998] ACPI: Added _OSI(Module Device)
[    0.300165] ACPI: Added _OSI(Processor Device)
[    0.300333] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302429] ACPI: Added _OSI(Processor Aggregator Device)
[    0.304560] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.305551] ACPI: Interpreter enabled
[    0.305722] ACPI: (supports S0 S5)
[    0.306015] ACPI: Using IOAPIC for interrupt routing
[    0.312565] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and reg
[    0.331230] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3d])
[    0.332414] PCI host bridge to bus 0000:00
[    0.332646] pci_bus 0000:00: root bus resource [bus 00-3d]
[    0.332813] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    0.332981] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    0.333150] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    0.333319] pci_bus 0000:00: root bus resource [io  0x0d00-0x1fff]
[    0.333486] pci_bus 0000:00: root bus resource [io  0xe000-0xffff]
[    0.333657] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.333831] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xdfffffff]
[    0.334022] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff]
[    0.337651] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.338352] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.338605] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.339050] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.339313] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.339571] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.339830] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.343411] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.353509] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.359232] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.366425] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.368708] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.370402] pci 0000:00:1e.0: PCI bridge to [bus 0d] (subtractive decode)
[    0.371866]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.372334]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.384347] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 40-7e])
[    0.386540] PCI host bridge to bus 0000:40
[    0.386753] pci_bus 0000:40: root bus resource [bus 40-7e]
[    0.386951] pci_bus 0000:40: root bus resource [io  0x2000-0x3fff]
[    0.387149] pci_bus 0000:40: root bus resource [io  0x4000-0x5fff]
[    0.387348] pci_bus 0000:40: root bus resource [io  0x6000-0x7fff]
[    0.387546] pci_bus 0000:40: root bus resource [io  0x8000-0x9fff]
[    0.387744] pci_bus 0000:40: root bus resource [io  0xa000-0xbfff]
[    0.387955] pci_bus 0000:40: root bus resource [io  0xc000-0xdfff]
[    0.388155] pci_bus 0000:40: root bus resource [mem 0xd0000000-0xd7ffffff]
[    0.390449] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.390804] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.391159] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.391522] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.392451]  pci0000:40: Requesting ACPI _OSC control (0x1d)
[    0.392929]  pci0000:40: ACPI _OSC control (0x1d) granted
[    0.395163] ACPI: PCI Root Bridge [P0B1] (domain 0000 [bus 3f])
[    0.395515] PCI host bridge to bus 0000:3f
[    0.395713] pci_bus 0000:3f: root bus resource [bus 3f]
[    0.404007]  pci0000:3f: Requesting ACPI _OSC control (0x1d)
[    0.404484]  pci0000:3f: ACPI _OSC control (0x1d) granted
[    0.413321] ACPI: PCI Root Bridge [P1B1] (domain 0000 [bus 7f])
[    0.413667] PCI host bridge to bus 0000:7f
[    0.413862] pci_bus 0000:7f: root bus resource [bus 7f]
[    0.422347]  pci0000:7f: Requesting ACPI _OSC control (0x1d)
[    0.422809]  pci0000:7f: ACPI _OSC control (0x1d) granted
[    0.427766] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 11 14 *15)
[    0.428866] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 11 *14 15)
[    0.429941] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.431276] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *11 14 15)
[    0.432386] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 11 14 15)
[    0.433485] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.434824] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 *6 7 11 14 15)
[    0.435882] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 11 *14 15)
[    0.437121] xen/balloon: Initialising balloon driver.
[    0.437493] xen-balloon: Initialising balloon driver.
[    0.438249] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.438581] vgaarb: loaded
[    0.438766] vgaarb: bridge control possible 0000:0b:00.0
[    0.439309] SCSI subsystem initialized
[    0.439512] ACPI: bus type scsi registered
[    0.440271] ACPI: bus type usb registered
[    0.440639] usbcore: registered new interface driver usbfs
[    0.440919] usbcore: registered new interface driver hub
[    0.441261] usbcore: registered new device driver usb
[    0.441973] PCI: Using ACPI for IRQ routing
[    0.465197] Switching to clocksource xen
[    0.465669] pnp: PnP ACPI init
[    0.465880] ACPI: bus type pnp registered
[    0.469008] Already setup the GSI :3
[    0.470110] system 00:07: [io  0x0800-0x087f] has been reserved
[    0.470312] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.470521] system 00:07: [io  0x0900-0x091f] has been reserved
[    0.470718] system 00:07: [io  0x0920-0x0923] has been reserved
[    0.470914] system 00:07: [io  0x0924] has been reserved
[    0.471108] system 00:07: [io  0x0370-0x0377] has been reserved
[    0.471304] system 00:07: [io  0x0ca0-0x0ca7] has been reserved
[    0.471499] system 00:07: [io  0x0ca9-0x0cab] has been reserved
[    0.471695] system 00:07: [io  0x0cad-0x0caf] has been reserved
[    0.471889] system 00:07: [io  0x0cb0-0x0cbf] has been reserved
[    0.472398] system 00:08: [io  0x0ca8] has been reserved
[    0.472592] system 00:08: [io  0x0cac] has been reserved
[    0.473441] system 00:09: [mem 0xe0000000-0xe3efffff] has been reserved
[    0.475223] system 00:0b: [mem 0xe4000000-0xe7ffffff] has been reserved
[    0.475856] system 00:0d: [mem 0xe3f00000-0xe3ffffff] has been reserved
[    0.476308] system 00:0e: [mem 0xdf900000-0xdf901fff] has been reserved
[    0.476788] system 00:0f: [mem 0xd3000000-0xd3001fff] has been reserved
[    0.477672] pnp: PnP ACPI: found 18 devices
[    0.477866] ACPI: ACPI bus type pnp unregistered
[    0.498410] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    0.498625] pci 0000:01:00.1: address space collision: [mem 0xdc800000-0xdc83ffff pref] co]
[    0.498943] pci 0000:02:00.1: address space collision: [mem 0xdc000000-0xdc03ffff pref] co]
[    0.500490] pci 0000:02:00.1: BAR 6: assigned [mem 0xd9000000-0xd903ffff pref]
[    0.500793] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.500995] pci 0000:00:01.0:   bridge window [mem 0xdc000000-0xdc7fffff]
[    0.501202] pci 0000:00:01.0:   bridge window [mem 0xd9000000-0xd90fffff 64bit pref]
[    0.501560] pci 0000:01:00.1: BAR 6: assigned [mem 0xd9100000-0xd913ffff pref]
[    0.501866] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.502068] pci 0000:00:01.1:   bridge window [mem 0xdc800000-0xdcffffff]
[    0.502274] pci 0000:00:01.1:   bridge window [mem 0xd9100000-0xd91fffff 64bit pref]
[    0.502584] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.502798] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.502995] pci 0000:00:02.2:   bridge window [io  0xf000-0xffff]
[    0.503255] pci 0000:00:02.2:   bridge window [mem 0xdd000000-0xddffffff]
[    0.503465] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.503679] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.503897] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.504112] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.504449] pci 0000:0a:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.504756] pci 0000:0a:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.505249] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.505606] pci 0000:09:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.505899] pci 0000:09:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.506411] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.506744] pci 0000:09:01.0:   bridge window [mem 0xdf700000-0xdf7fffff]
[    0.507286] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.507604] pci 0000:08:00.0:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.507889] pci 0000:08:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.508423] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.508625] pci 0000:00:1c.7:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.508827] pci 0000:00:1c.7:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.509162] pci 0000:00:1e.0: PCI bridge to [bus 0d]
[    0.509385] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.509623] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.509844] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.510064] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.510366] Already setup the GSI :53
[    0.510566] Already setup the GSI :53
[    0.510780] Already setup the GSI :53
[    0.510978] Already setup the GSI :53
[    0.511773] Already setup the GSI :85
[    0.511974] Already setup the GSI :85
[    0.512173] Already setup the GSI :85
[    0.512556] NET: Registered protocol family 2
[    0.515017] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.517734] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.518170] TCP: Hash tables configured (established 524288 bind 65536)
[    0.518421] TCP: reno registered
[    0.518636] UDP hash table entries: 2048 (order: 4, 65536 bytes)
  Booting 'Xen 4.2 / linux-3.7.5-hardened'
                                                                    
root (hd0,0)
 Filesystem type is xfs, partition type 0x83
kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0
console=com2 com2=115200,8n1
   [Multiboot-elf, <0x100000:0x197828:0x527d8>, shtab=0x2ea078, entry=0x100000]
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
   [Multiboot-module @ 0x2eb000, 0x4dc160 bytes]

 \ \/ /___ _ __   | || |  |___ \  / |
  \  // _ \ '_ \  | || |_   __) | | |
  /  \  __/ | | | |__   _| / __/ _| |
 /_/\_\___|_| |_|    |_|(_)_____(_)_|
                                     
(XEN) Xen version 4.2.1 (@mobil.cz) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Tue 3
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0 console=c1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e000 (usable)
(XEN)  0000000000100000 - 00000000bd2f0000 (usable)
(XEN)  00000000bd2f0000 - 00000000bd31c000 (reserved)
(XEN)  00000000bd31c000 - 00000000bd35b000 (ACPI data)
(XEN)  00000000bd35b000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000002040000000 (usable)
(XEN) ACPI: RSDP 000F0F40, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1048, 00A4 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BD3411CC, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BD31C000, 7760 (r1 DELL   PE_SC3          1 INTL 20110211)
(XEN) ACPI: FACS BD343000, 0040
(XEN) ACPI: APIC BD340478, 016A (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BD3405E4, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BD340638, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BD340674, 0158 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BD340990, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BD3409D0, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BD340B08, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BD323920, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BD323B90, 059C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BD323760, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BD323790, 0190 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BD341164, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: PC__ BD3410F4, 006E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BD340D30, 03C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BD344000, 7624 (r1 INTEL  PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 131026MB (134171192kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
(XEN) IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) ERST table is invalid
(XEN) Would not enable x2APIC due to interrupt remapping cannot be enabled.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2500.081 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) 'A' pressed -> using normal key handling
(XEN) Allocated console ring of 64 KiB.
(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, 1GB
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) Brought up 24 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2000000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000102c000000->0000001030000000 (1032192 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82000000
(XEN)  Init. ramdisk: ffffffff82000000->ffffffff82000000
(XEN)  Phys-Mach map: ffffffff82000000->ffffffff82800000
(XEN)  Start info:    ffffffff82800000->ffffffff828004b4
(XEN)  Page tables:   ffffffff82801000->ffffffff8281a000
(XEN)  Boot stack:    ffffffff8281a000->ffffffff8281b000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a281c0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ....................................................................
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.5-hardened (root@rajvir3) (gcc version 4.6.3 (Gentoo Hardene3
[    0.000000] Command line: root=/dev/sda6 console=tty0 console=hvc0
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing bd2f0-100000 pfn range: 273680 pages freed
[    0.000000] Released 273778 pages of unused memory
[    0.000000] Set 273778 page(s) to 1-1 mapping
[    0.000000] Populating 100000-142d72 pfn range: 273778 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bd2effff] usable
[    0.000000] Xen: [mem 0x00000000bd2f0000-0x00000000bd31bfff] reserved
[    0.000000] Xen: [mem 0x00000000bd31c000-0x00000000bd35afff] ACPI data
[    0.000000] Xen: [mem 0x00000000bd35b000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000142d71fff] usable
[    0.000000] Xen: [mem 0x0000000142d72000-0x000000203fffffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x142d72 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbd2f0 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0xbd2effff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: RSDP 00000000000f0f40 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000f1048 000A4 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: FACP 00000000bd3411cc 000F4 (v03 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: DSDT 00000000bd31c000 07760 (v01 DELL   PE_SC3   00000001 INTL 20110211)
[    0.000000] ACPI: FACS 00000000bd343000 00040
[    0.000000] ACPI: APIC 00000000bd340478 0016A (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SPCR 00000000bd3405e4 00050 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HPET 00000000bd340638 00038 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: XMAR 00000000bd340674 00158 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: MCFG 00000000bd340990 0003C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: WD__ 00000000bd3409d0 00134 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SLIC 00000000bd340b08 00024 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: ERST 00000000bd323920 00270 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HEST 00000000bd323b90 0059C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: BERT 00000000bd323760 00030 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: EINJ 00000000bd323790 00190 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: TCPA 00000000bd341164 00064 (v02 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: PC__ 00000000bd3410f4 0006E (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SRAT 00000000bd340d30 003C0 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SSDT 00000000bd344000 07624 (v01 INTEL  PPM RCM  80000001 INTL 20061109)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000142d71fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x142d71fff]
[    0.000000]   NODE_DATA [mem 0x142d6e000-0x142d71fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x142d71fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0xbd2effff]
[    0.000000]   node   0: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x26] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x28] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x2a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x27] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x09] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x29] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x0b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x2b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x59] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x5b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x5d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x5f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[64])
[    0.000000] IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 32 CPUs, 8 hotplug CPUs
[    0.000000] e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88013d600000 s64512 r8192 d21504 u131072
[   50.166367] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1026398
[   50.166369] Policy zone: Normal
[   50.166371] Kernel command line: root=/dev/sda6 console=tty0 console=hvc0
[   50.166402] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   50.166406] __ex_table already sorted, skipping sort
[   50.166434] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[   50.194619] software IO TLB [mem 0x139600000-0x13d5fffff] (64MB) mapped at [ffff8801396000]
[   50.207444] Memory: 4029096k/5289416k available (7106k kernel code, 1095176k absent, 16514)
[   50.207520] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[   50.207550] Hierarchical RCU implementation.
[   50.207551]  RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=4.
[   50.207560] NR_IRQS:4352 nr_irqs:1024 16
[   50.207625] xen: sci override: global_irq=9 trigger=0 polarity=0
[   50.207662] xen: acpi sci 9
[   50.216286] Console: colour VGA+ 80x25
[   50.237789] console [tty0] enabled
[   50.238195] console [hvc0] enabled
[   50.238390] installing Xen timer for CPU 0
[   50.238580] tsc: Detected 2500.080 MHz processor
[   50.238751] Calibrating delay loop (skipped), value calculated using timer frequency.. 500)
[   50.239096] pid_max: default: 32768 minimum: 501
[   50.239801] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   50.240915] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   50.241431] Mount-cache hash table entries: 256
[   50.241801] Initializing cgroup subsys cpuacct
[   50.241973] Initializing cgroup subsys freezer
[   50.242199] CPU: Physical Processor ID: 0
[   50.242368] CPU: Processor Core ID: 0
[   50.242536] mce: CPU supports 2 MCE banks
[   50.242766] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[   50.242766] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[   50.242766] tlb_flushall_shift: 5
[   50.243423] Freeing SMP alternatives: 32k freed
[    0.007054] ACPI: Core revision 20120913
[    0.009510] cpu 0 spinlock event irq 105
[    0.009693] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events.
[    0.010286] installing Xen timer for CPU 1
[    0.010463] cpu 1 spinlock event irq 112
[    0.010848] installing Xen timer for CPU 2
[    0.011023] cpu 2 spinlock event irq 119
[    0.011363] installing Xen timer for CPU 3
[    0.011537] cpu 3 spinlock event irq 126
[    0.011844] Brought up 4 CPUs
[    0.012277] devtmpfs: initialized
[    0.012713] xor: automatically using best checksumming function:
[    0.052559]    avx       : 22051.000 MB/sec
[    0.052734] Grant tables using version 2 layout.
[    0.052912] Grant table initialized
[    0.053118] NET: Registered protocol family 16
[    0.053816] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.054090] ACPI: bus type pci registered
[    0.055403] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base)
[    0.055684] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.086464] PCI: Using configuration type 1 for base access
[    0.086664] PCI: Dell System detected, enabling pci=bfsort.
[    0.094712] bio: create slab <bio-0> at 0
[    0.161842] raid6: sse2x1    7662 MB/s
[    0.230644] raid6: sse2x2    9538 MB/s
[    0.299461] raid6: sse2x4   10973 MB/s
[    0.299628] raid6: using algorithm sse2x4 (10973 MB/s)
[    0.299798] raid6: using ssse3x2 recovery algorithm
[    0.299998] ACPI: Added _OSI(Module Device)
[    0.300165] ACPI: Added _OSI(Processor Device)
[    0.300333] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302429] ACPI: Added _OSI(Processor Aggregator Device)
[    0.304560] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.305551] ACPI: Interpreter enabled
[    0.305722] ACPI: (supports S0 S5)
[    0.306015] ACPI: Using IOAPIC for interrupt routing
[    0.312565] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and reg
[    0.331230] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3d])
[    0.332414] PCI host bridge to bus 0000:00
[    0.332646] pci_bus 0000:00: root bus resource [bus 00-3d]
[    0.332813] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    0.332981] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    0.333150] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    0.333319] pci_bus 0000:00: root bus resource [io  0x0d00-0x1fff]
[    0.333486] pci_bus 0000:00: root bus resource [io  0xe000-0xffff]
[    0.333657] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.333831] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xdfffffff]
[    0.334022] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff]
[    0.337651] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.338352] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.338605] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.339050] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.339313] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.339571] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.339830] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.343411] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.353509] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.359232] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.366425] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.368708] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.370402] pci 0000:00:1e.0: PCI bridge to [bus 0d] (subtractive decode)
[    0.371866]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.372334]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.384347] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 40-7e])
[    0.386540] PCI host bridge to bus 0000:40
[    0.386753] pci_bus 0000:40: root bus resource [bus 40-7e]
[    0.386951] pci_bus 0000:40: root bus resource [io  0x2000-0x3fff]
[    0.387149] pci_bus 0000:40: root bus resource [io  0x4000-0x5fff]
[    0.387348] pci_bus 0000:40: root bus resource [io  0x6000-0x7fff]
[    0.387546] pci_bus 0000:40: root bus resource [io  0x8000-0x9fff]
[    0.387744] pci_bus 0000:40: root bus resource [io  0xa000-0xbfff]
[    0.387955] pci_bus 0000:40: root bus resource [io  0xc000-0xdfff]
[    0.388155] pci_bus 0000:40: root bus resource [mem 0xd0000000-0xd7ffffff]
[    0.390449] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.390804] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.391159] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.391522] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.392451]  pci0000:40: Requesting ACPI _OSC control (0x1d)
[    0.392929]  pci0000:40: ACPI _OSC control (0x1d) granted
[    0.395163] ACPI: PCI Root Bridge [P0B1] (domain 0000 [bus 3f])
[    0.395515] PCI host bridge to bus 0000:3f
[    0.395713] pci_bus 0000:3f: root bus resource [bus 3f]
[    0.404007]  pci0000:3f: Requesting ACPI _OSC control (0x1d)
[    0.404484]  pci0000:3f: ACPI _OSC control (0x1d) granted
[    0.413321] ACPI: PCI Root Bridge [P1B1] (domain 0000 [bus 7f])
[    0.413667] PCI host bridge to bus 0000:7f
[    0.413862] pci_bus 0000:7f: root bus resource [bus 7f]
[    0.422347]  pci0000:7f: Requesting ACPI _OSC control (0x1d)
[    0.422809]  pci0000:7f: ACPI _OSC control (0x1d) granted
[    0.427766] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 11 14 *15)
[    0.428866] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 11 *14 15)
[    0.429941] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.431276] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *11 14 15)
[    0.432386] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 11 14 15)
[    0.433485] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.434824] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 *6 7 11 14 15)
[    0.435882] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 11 *14 15)
[    0.437121] xen/balloon: Initialising balloon driver.
[    0.437493] xen-balloon: Initialising balloon driver.
[    0.438249] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.438581] vgaarb: loaded
[    0.438766] vgaarb: bridge control possible 0000:0b:00.0
[    0.439309] SCSI subsystem initialized
[    0.439512] ACPI: bus type scsi registered
[    0.440271] ACPI: bus type usb registered
[    0.440639] usbcore: registered new interface driver usbfs
[    0.440919] usbcore: registered new interface driver hub
[    0.441261] usbcore: registered new device driver usb
[    0.441973] PCI: Using ACPI for IRQ routing
[    0.465197] Switching to clocksource xen
[    0.465669] pnp: PnP ACPI init
[    0.465880] ACPI: bus type pnp registered
[    0.469008] Already setup the GSI :3
[    0.470110] system 00:07: [io  0x0800-0x087f] has been reserved
[    0.470312] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.470521] system 00:07: [io  0x0900-0x091f] has been reserved
[    0.470718] system 00:07: [io  0x0920-0x0923] has been reserved
[    0.470914] system 00:07: [io  0x0924] has been reserved
[    0.471108] system 00:07: [io  0x0370-0x0377] has been reserved
[    0.471304] system 00:07: [io  0x0ca0-0x0ca7] has been reserved
[    0.471499] system 00:07: [io  0x0ca9-0x0cab] has been reserved
[    0.471695] system 00:07: [io  0x0cad-0x0caf] has been reserved
[    0.471889] system 00:07: [io  0x0cb0-0x0cbf] has been reserved
[    0.472398] system 00:08: [io  0x0ca8] has been reserved
[    0.472592] system 00:08: [io  0x0cac] has been reserved
[    0.473441] system 00:09: [mem 0xe0000000-0xe3efffff] has been reserved
[    0.475223] system 00:0b: [mem 0xe4000000-0xe7ffffff] has been reserved
[    0.475856] system 00:0d: [mem 0xe3f00000-0xe3ffffff] has been reserved
[    0.476308] system 00:0e: [mem 0xdf900000-0xdf901fff] has been reserved
[    0.476788] system 00:0f: [mem 0xd3000000-0xd3001fff] has been reserved
[    0.477672] pnp: PnP ACPI: found 18 devices
[    0.477866] ACPI: ACPI bus type pnp unregistered
[    0.498410] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    0.498625] pci 0000:01:00.1: address space collision: [mem 0xdc800000-0xdc83ffff pref] co]
[    0.498943] pci 0000:02:00.1: address space collision: [mem 0xdc000000-0xdc03ffff pref] co]
[    0.500490] pci 0000:02:00.1: BAR 6: assigned [mem 0xd9000000-0xd903ffff pref]
[    0.500793] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.500995] pci 0000:00:01.0:   bridge window [mem 0xdc000000-0xdc7fffff]
[    0.501202] pci 0000:00:01.0:   bridge window [mem 0xd9000000-0xd90fffff 64bit pref]
[    0.501560] pci 0000:01:00.1: BAR 6: assigned [mem 0xd9100000-0xd913ffff pref]
[    0.501866] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.502068] pci 0000:00:01.1:   bridge window [mem 0xdc800000-0xdcffffff]
[    0.502274] pci 0000:00:01.1:   bridge window [mem 0xd9100000-0xd91fffff 64bit pref]
[    0.502584] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.502798] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.502995] pci 0000:00:02.2:   bridge window [io  0xf000-0xffff]
[    0.503255] pci 0000:00:02.2:   bridge window [mem 0xdd000000-0xddffffff]
[    0.503465] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.503679] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.503897] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.504112] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.504449] pci 0000:0a:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.504756] pci 0000:0a:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.505249] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.505606] pci 0000:09:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.505899] pci 0000:09:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.506411] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.506744] pci 0000:09:01.0:   bridge window [mem 0xdf700000-0xdf7fffff]
[    0.507286] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.507604] pci 0000:08:00.0:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.507889] pci 0000:08:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.508423] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.508625] pci 0000:00:1c.7:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.508827] pci 0000:00:1c.7:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.509162] pci 0000:00:1e.0: PCI bridge to [bus 0d]
[    0.509385] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.509623] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.509844] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.510064] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.510366] Already setup the GSI :53
[    0.510566] Already setup the GSI :53
[    0.510780] Already setup the GSI :53
[    0.510978] Already setup the GSI :53
[    0.511773] Already setup the GSI :85
[    0.511974] Already setup the GSI :85
[    0.512173] Already setup the GSI :85
[    0.512556] NET: Registered protocol family 2
[    0.515017] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.517734] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.518170] TCP: Hash tables configured (established 524288 bind 65536)
[    0.518421] TCP: reno registered
[    0.518636] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[  Booting 'Xen 4.2 / linux-3.7.5-hardened'
                                                                    
root (hd0,0)
 Filesystem type is xfs, partition type 0x83
kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0
console=com2 com2=115200,8n1
   [Multiboot-elf, <0x100000:0x197828:0x527d8>, shtab=0x2ea078, entry=0x100000]
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
   [Multiboot-module @ 0x2eb000, 0x4dc160 bytes]

 \ \/ /___ _ __   | || |  |___ \  / |
  \  // _ \ '_ \  | || |_   __) | | |
  /  \  __/ | | | |__   _| / __/ _| |
 /_/\_\___|_| |_|    |_|(_)_____(_)_|
                                     
(XEN) Xen version 4.2.1 (@mobil.cz) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Tue 3
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0 console=c1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e000 (usable)
(XEN)  0000000000100000 - 00000000bd2f0000 (usable)
(XEN)  00000000bd2f0000 - 00000000bd31c000 (reserved)
(XEN)  00000000bd31c000 - 00000000bd35b000 (ACPI data)
(XEN)  00000000bd35b000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000002040000000 (usable)
(XEN) ACPI: RSDP 000F0F40, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1048, 00A4 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BD3411CC, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BD31C000, 7760 (r1 DELL   PE_SC3          1 INTL 20110211)
(XEN) ACPI: FACS BD343000, 0040
(XEN) ACPI: APIC BD340478, 016A (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BD3405E4, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BD340638, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BD340674, 0158 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BD340990, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BD3409D0, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BD340B08, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BD323920, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BD323B90, 059C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BD323760, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BD323790, 0190 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BD341164, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: PC__ BD3410F4, 006E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BD340D30, 03C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BD344000, 7624 (r1 INTEL  PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 131026MB (134171192kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
(XEN) IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) ERST table is invalid
(XEN) Would not enable x2APIC due to interrupt remapping cannot be enabled.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2500.081 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) 'A' pressed -> using normal key handling
(XEN) Allocated console ring of 64 KiB.
(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, 1GB
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) Brought up 24 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2000000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000102c000000->0000001030000000 (1032192 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82000000
(XEN)  Init. ramdisk: ffffffff82000000->ffffffff82000000
(XEN)  Phys-Mach map: ffffffff82000000->ffffffff82800000
(XEN)  Start info:    ffffffff82800000->ffffffff828004b4
(XEN)  Page tables:   ffffffff82801000->ffffffff8281a000
(XEN)  Boot stack:    ffffffff8281a000->ffffffff8281b000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a281c0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ....................................................................
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.5-hardened (root@rajvir3) (gcc version 4.6.3 (Gentoo Hardene3
[    0.000000] Command line: root=/dev/sda6 console=tty0 console=hvc0
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing bd2f0-100000 pfn range: 273680 pages freed
[    0.000000] Released 273778 pages of unused memory
[    0.000000] Set 273778 page(s) to 1-1 mapping
[    0.000000] Populating 100000-142d72 pfn range: 273778 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bd2effff] usable
[    0.000000] Xen: [mem 0x00000000bd2f0000-0x00000000bd31bfff] reserved
[    0.000000] Xen: [mem 0x00000000bd31c000-0x00000000bd35afff] ACPI data
[    0.000000] Xen: [mem 0x00000000bd35b000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000142d71fff] usable
[    0.000000] Xen: [mem 0x0000000142d72000-0x000000203fffffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x142d72 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbd2f0 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0xbd2effff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: RSDP 00000000000f0f40 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000f1048 000A4 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: FACP 00000000bd3411cc 000F4 (v03 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: DSDT 00000000bd31c000 07760 (v01 DELL   PE_SC3   00000001 INTL 20110211)
[    0.000000] ACPI: FACS 00000000bd343000 00040
[    0.000000] ACPI: APIC 00000000bd340478 0016A (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SPCR 00000000bd3405e4 00050 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HPET 00000000bd340638 00038 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: XMAR 00000000bd340674 00158 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: MCFG 00000000bd340990 0003C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: WD__ 00000000bd3409d0 00134 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SLIC 00000000bd340b08 00024 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: ERST 00000000bd323920 00270 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HEST 00000000bd323b90 0059C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: BERT 00000000bd323760 00030 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: EINJ 00000000bd323790 00190 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: TCPA 00000000bd341164 00064 (v02 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: PC__ 00000000bd3410f4 0006E (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SRAT 00000000bd340d30 003C0 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SSDT 00000000bd344000 07624 (v01 INTEL  PPM RCM  80000001 INTL 20061109)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000142d71fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x142d71fff]
[    0.000000]   NODE_DATA [mem 0x142d6e000-0x142d71fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x142d71fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0xbd2effff]
[    0.000000]   node   0: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x26] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x28] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x2a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x27] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x09] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x29] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x0b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x2b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x59] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x5b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x5d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x5f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[64])
[    0.000000] IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 32 CPUs, 8 hotplug CPUs
[    0.000000] e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88013d600000 s64512 r8192 d21504 u131072
[   50.166367] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1026398
[   50.166369] Policy zone: Normal
[   50.166371] Kernel command line: root=/dev/sda6 console=tty0 console=hvc0
[   50.166402] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   50.166406] __ex_table already sorted, skipping sort
[   50.166434] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[   50.194619] software IO TLB [mem 0x139600000-0x13d5fffff] (64MB) mapped at [ffff8801396000]
[   50.207444] Memory: 4029096k/5289416k available (7106k kernel code, 1095176k absent, 16514)
[   50.207520] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[   50.207550] Hierarchical RCU implementation.
[   50.207551]  RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=4.
[   50.207560] NR_IRQS:4352 nr_irqs:1024 16
[   50.207625] xen: sci override: global_irq=9 trigger=0 polarity=0
[   50.207662] xen: acpi sci 9
[   50.216286] Console: colour VGA+ 80x25
[   50.237789] console [tty0] enabled
[   50.238195] console [hvc0] enabled
[   50.238390] installing Xen timer for CPU 0
[   50.238580] tsc: Detected 2500.080 MHz processor
[   50.238751] Calibrating delay loop (skipped), value calculated using timer frequency.. 500)
[   50.239096] pid_max: default: 32768 minimum: 501
[   50.239801] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   50.240915] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   50.241431] Mount-cache hash table entries: 256
[   50.241801] Initializing cgroup subsys cpuacct
[   50.241973] Initializing cgroup subsys freezer
[   50.242199] CPU: Physical Processor ID: 0
[   50.242368] CPU: Processor Core ID: 0
[   50.242536] mce: CPU supports 2 MCE banks
[   50.242766] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[   50.242766] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[   50.242766] tlb_flushall_shift: 5
[   50.243423] Freeing SMP alternatives: 32k freed
[    0.007054] ACPI: Core revision 20120913
[    0.009510] cpu 0 spinlock event irq 105
[    0.009693] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events.
[    0.010286] installing Xen timer for CPU 1
[    0.010463] cpu 1 spinlock event irq 112
[    0.010848] installing Xen timer for CPU 2
[    0.011023] cpu 2 spinlock event irq 119
[    0.011363] installing Xen timer for CPU 3
[    0.011537] cpu 3 spinlock event irq 126
[    0.011844] Brought up 4 CPUs
[    0.012277] devtmpfs: initialized
[    0.012713] xor: automatically using best checksumming function:
[    0.052559]    avx       : 22051.000 MB/sec
[    0.052734] Grant tables using version 2 layout.
[    0.052912] Grant table initialized
[    0.053118] NET: Registered protocol family 16
[    0.053816] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.054090] ACPI: bus type pci registered
[    0.055403] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base)
[    0.055684] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.086464] PCI: Using configuration type 1 for base access
[    0.086664] PCI: Dell System detected, enabling pci=bfsort.
[    0.094712] bio: create slab <bio-0> at 0
[    0.161842] raid6: sse2x1    7662 MB/s
[    0.230644] raid6: sse2x2    9538 MB/s
[    0.299461] raid6: sse2x4   10973 MB/s
[    0.299628] raid6: using algorithm sse2x4 (10973 MB/s)
[    0.299798] raid6: using ssse3x2 recovery algorithm
[    0.299998] ACPI: Added _OSI(Module Device)
[    0.300165] ACPI: Added _OSI(Processor Device)
[    0.300333] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302429] ACPI: Added _OSI(Processor Aggregator Device)
[    0.304560] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.305551] ACPI: Interpreter enabled
[    0.305722] ACPI: (supports S0 S5)
[    0.306015] ACPI: Using IOAPIC for interrupt routing
[    0.312565] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and reg
[    0.331230] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3d])
[    0.332414] PCI host bridge to bus 0000:00
[    0.332646] pci_bus 0000:00: root bus resource [bus 00-3d]
[    0.332813] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    0.332981] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    0.333150] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    0.333319] pci_bus 0000:00: root bus resource [io  0x0d00-0x1fff]
[    0.333486] pci_bus 0000:00: root bus resource [io  0xe000-0xffff]
[    0.333657] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.333831] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xdfffffff]
[    0.334022] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff]
[    0.337651] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.338352] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.338605] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.339050] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.339313] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.339571] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.339830] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.343411] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.353509] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.359232] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.366425] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.368708] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.370402] pci 0000:00:1e.0: PCI bridge to [bus 0d] (subtractive decode)
[    0.371866]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.372334]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.384347] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 40-7e])
[    0.386540] PCI host bridge to bus 0000:40
[    0.386753] pci_bus 0000:40: root bus resource [bus 40-7e]
[    0.386951] pci_bus 0000:40: root bus resource [io  0x2000-0x3fff]
[    0.387149] pci_bus 0000:40: root bus resource [io  0x4000-0x5fff]
[    0.387348] pci_bus 0000:40: root bus resource [io  0x6000-0x7fff]
[    0.387546] pci_bus 0000:40: root bus resource [io  0x8000-0x9fff]
[    0.387744] pci_bus 0000:40: root bus resource [io  0xa000-0xbfff]
[    0.387955] pci_bus 0000:40: root bus resource [io  0xc000-0xdfff]
[    0.388155] pci_bus 0000:40: root bus resource [mem 0xd0000000-0xd7ffffff]
[    0.390449] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.390804] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.391159] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.391522] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.392451]  pci0000:40: Requesting ACPI _OSC control (0x1d)
[    0.392929]  pci0000:40: ACPI _OSC control (0x1d) granted
[    0.395163] ACPI: PCI Root Bridge [P0B1] (domain 0000 [bus 3f])
[    0.395515] PCI host bridge to bus 0000:3f
[    0.395713] pci_bus 0000:3f: root bus resource [bus 3f]
[    0.404007]  pci0000:3f: Requesting ACPI _OSC control (0x1d)
[    0.404484]  pci0000:3f: ACPI _OSC control (0x1d) granted
[    0.413321] ACPI: PCI Root Bridge [P1B1] (domain 0000 [bus 7f])
[    0.413667] PCI host bridge to bus 0000:7f
[    0.413862] pci_bus 0000:7f: root bus resource [bus 7f]
[    0.422347]  pci0000:7f: Requesting ACPI _OSC control (0x1d)
[    0.422809]  pci0000:7f: ACPI _OSC control (0x1d) granted
[    0.427766] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 11 14 *15)
[    0.428866] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 11 *14 15)
[    0.429941] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.431276] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *11 14 15)
[    0.432386] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 11 14 15)
[    0.433485] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.434824] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 *6 7 11 14 15)
[    0.435882] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 11 *14 15)
[    0.437121] xen/balloon: Initialising balloon driver.
[    0.437493] xen-balloon: Initialising balloon driver.
[    0.438249] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.438581] vgaarb: loaded
[    0.438766] vgaarb: bridge control possible 0000:0b:00.0
[    0.439309] SCSI subsystem initialized
[    0.439512] ACPI: bus type scsi registered
[    0.440271] ACPI: bus type usb registered
[    0.440639] usbcore: registered new interface driver usbfs
[    0.440919] usbcore: registered new interface driver hub
[    0.441261] usbcore: registered new device driver usb
[    0.441973] PCI: Using ACPI for IRQ routing
[    0.465197] Switching to clocksource xen
[    0.465669] pnp: PnP ACPI init
[    0.465880] ACPI: bus type pnp registered
[    0.469008] Already setup the GSI :3
[    0.470110] system 00:07: [io  0x0800-0x087f] has been reserved
[    0.470312] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.470521] system 00:07: [io  0x0900-0x091f] has been reserved
[    0.470718] system 00:07: [io  0x0920-0x0923] has been reserved
[    0.470914] system 00:07: [io  0x0924] has been reserved
[    0.471108] system 00:07: [io  0x0370-0x0377] has been reserved
[    0.471304] system 00:07: [io  0x0ca0-0x0ca7] has been reserved
[    0.471499] system 00:07: [io  0x0ca9-0x0cab] has been reserved
[    0.471695] system 00:07: [io  0x0cad-0x0caf] has been reserved
[    0.471889] system 00:07: [io  0x0cb0-0x0cbf] has been reserved
[    0.472398] system 00:08: [io  0x0ca8] has been reserved
[    0.472592] system 00:08: [io  0x0cac] has been reserved
[    0.473441] system 00:09: [mem 0xe0000000-0xe3efffff] has been reserved
[    0.475223] system 00:0b: [mem 0xe4000000-0xe7ffffff] has been reserved
[    0.475856] system 00:0d: [mem 0xe3f00000-0xe3ffffff] has been reserved
[    0.476308] system 00:0e: [mem 0xdf900000-0xdf901fff] has been reserved
[    0.476788] system 00:0f: [mem 0xd3000000-0xd3001fff] has been reserved
[    0.477672] pnp: PnP ACPI: found 18 devices
[    0.477866] ACPI: ACPI bus type pnp unregistered
[    0.498410] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    0.498625] pci 0000:01:00.1: address space collision: [mem 0xdc800000-0xdc83ffff pref] co]
[    0.498943] pci 0000:02:00.1: address space collision: [mem 0xdc000000-0xdc03ffff pref] co]
[    0.500490] pci 0000:02:00.1: BAR 6: assigned [mem 0xd9000000-0xd903ffff pref]
[    0.500793] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.500995] pci 0000:00:01.0:   bridge window [mem 0xdc000000-0xdc7fffff]
[    0.501202] pci 0000:00:01.0:   bridge window [mem 0xd9000000-0xd90fffff 64bit pref]
[    0.501560] pci 0000:01:00.1: BAR 6: assigned [mem 0xd9100000-0xd913ffff pref]
[    0.501866] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.502068] pci 0000:00:01.1:   bridge window [mem 0xdc800000-0xdcffffff]
[    0.502274] pci 0000:00:01.1:   bridge window [mem 0xd9100000-0xd91fffff 64bit pref]
[    0.502584] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.502798] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.502995] pci 0000:00:02.2:   bridge window [io  0xf000-0xffff]
[    0.503255] pci 0000:00:02.2:   bridge window [mem 0xdd000000-0xddffffff]
[    0.503465] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.503679] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.503897] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.504112] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.504449] pci 0000:0a:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.504756] pci 0000:0a:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.505249] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.505606] pci 0000:09:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.505899] pci 0000:09:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.506411] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.506744] pci 0000:09:01.0:   bridge window [mem 0xdf700000-0xdf7fffff]
[    0.507286] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.507604] pci 0000:08:00.0:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.507889] pci 0000:08:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.508423] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.508625] pci 0000:00:1c.7:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.508827] pci 0000:00:1c.7:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.509162] pci 0000:00:1e.0: PCI bridge to [bus 0d]
[    0.509385] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.509623] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.509844] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.510064] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.510366] Already setup the GSI :53
[    0.510566] Already setup the GSI :53
[    0.510780] Already setup the GSI :53
[    0.510978] Already setup the GSI :53
[    0.511773] Already setup the GSI :85
[    0.511974] Already setup the GSI :85
[    0.512173] Already setup the GSI :85
[    0.512556] NET: Registered protocol family 2
[    0.515017] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.517734] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.518170] TCP: Hash tables configured (established 524288 bind 65536)
[    0.518421] TCP: reno registered
[    0.518636] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ [    2.117929] i8042: No controller found
[    3.599100] usb 1-1.6.4: new high-speed USB device number 6 using ehci_hcd
[    3.697696] usb 1-1.6.4: New USB device found, idVendor=0624, idProduct=0251
[    3.697917] usb 1-1.6.4: New USB device strings: Mfr=4, Product=5, SerialNumber=6
[    3.698233] usb 1-1.6.4: Product: Mass Storage Function
[    3.698428] usb 1-1.6.4: Manufacturer: Avocent
[    3.698629] usb 1-1.6.4: SerialNumber: 20111109-1
[    3.699825] scsi1 : usb-storage 1-1.6.4:1.0
   OpenRC 0.11.8 is starting up Gentoo Linux (x86_64) [XEN0]

 * Mounting /proc ...
 [ ok ]
 * Mounting /run ...
 * /run/openrc: creating directory
 * /run/lock: creating directory
 * Mounting xenfs ...
 [ ok ]
 * Mounting /dev ...
 [ ok ]
 * Mounting /dev/pts ...
 [ ok ]
 * Mounting /dev/shm ...
 [ ok ]
 * Mounting /sys ...
 [ ok ]
 * Mounting debug filesystem ...
 [ ok ]
 * Mounting cgroup filesystem ...
 [ ok ]
 * Starting udev ...
 [ ok ]
 * Populating /dev with existing devices through uevents ...
 [ ok ]
 * Waiting for uevents to be processed ...
 [ ok ]
 * Setting system clock using the hardware clock [UTC] ...
 [ ok ]
 * Autoloaded 0 module(s)
 * Setting up the Logical Volume Manager ...
 [ ok ]
 * Checking local filesystems  ...
/sbin/fsck.xfs: XFS file system.
/sbin/fsck.xfs: XFS file system.
/sbin/fsck.xfs: XFS file system.
 [ ok ]
 * Remounting filesystems ...
 [ ok ]
 * Updating /etc/mtab ...
 [ ok ]
 * Activating swap devices ...
 [ ok ]
 * Mounting local filesystems ...
 [ ok ]
 * Configuring kernel parameters ...
 [ ok ]
 * Creating user login records ...
 [ ok ]
 * Cleaning /var/run ...
 [ ok ]
 * Wiping /tmp directory ...
 [ ok ]
 * Setting terminal encoding [UTF-8] ...
 [ ok ]
 * Setting console font [default8x16] ...
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Starting firewall (/root/bin/firewall/firewall.sh) ...
WARNING: The state match is obsolete. Use conntrack instead.
WARNING: The state match is obsolete. Use conntrack instead.
 [ ok ]
 * Setting hostname to rajvir3 ...
 [ ok ]
 * Setting keyboard mode [UTF-8] ...
 [ ok ]
 * Loading key mappings [us] ...
 [ ok ]
 * Bringing up interface lo
 *   127.0.0.1/8 ...
 [ ok ]
 *   Adding routes
 *     127.0.0.0/8 via 127.0.0.1 ...
 [ ok ]
 * Bringing up interface bond0
 *   Adding slaves to bond0 ...
 *     eth0 eth1
 [ ok ]
 [ ok ]
 * Mounting misc binary format filesystem ...
 [ ok ]
 * Loading custom binary format handlers ...
 [ ok ]
 * Activating additional swap space ...
 [ ok ]
 * setting up tmpfiles.d entries ...
 [ ok ]
 * Initializing random number generator ...
 [ ok ]
INIT: Entering runlevel: 3
 * Bringing up interface br0
 *   Creating bridge br0 ...
 *   Adding ports to br0
 *     bond0 ...
 [ ok ]
 *   192.168.241.125/24 ...
 [ ok ]
 *   Adding routes
 *     default via 192.168.241.1 ...
 [ ok ]
 * Starting syslog-ng ...
 [ ok ]
 * Starting bacula file daemon ...
 [ ok ]
 * Starting fail2ban ...
 [ ok ]
 * Starting munin-node ...
 [ ok ]
 * Mounting network filesystems ...
 [ ok ]
 * Starting nrpe ...
 [ ok ]
 * Setting clock via the NTP client 'ntpdate' ...
 [ ok ]
 * Starting ntpd ...
 [ ok ]
 * Calling sar - 30 sec. interval ...
 [ ok ]
 * Starting xenstored daemon ...
 * Setting domain0 name record
 [ ok ]
 * Starting xenconsoled daemon ...
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Starting Xen control daemon ...
^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A [ ok ]
 * Starting sshd ...
 [ ok ]
 * Starting vixie-cron ...
 [ ok ]
 * Starting local

--------------000609010708080401060703
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000609010708080401060703--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:18:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:18: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 1UAOAy-00040P-FC; Tue, 26 Feb 2013 17:18:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UAOAw-000409-68
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:18:46 +0000
Received: from [85.158.139.211:35808] by server-12.bemta-5.messagelabs.com id
	B4/98-11486-57EEC215; Tue, 26 Feb 2013 17:18:45 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361899119!19434303!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14938 invoked from network); 26 Feb 2013 17:18:39 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:18:39 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UAOAo-0006qE-IL; Tue, 26 Feb 2013 18:18:38 +0100
Message-ID: <512CEE69.8070408@mfiala.net>
Date: Tue, 26 Feb 2013 18:18:33 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <512CC78B.4080606@mfiala.net>
	<20130226165614.GA22422@phenom.dumpdata.com>
In-Reply-To: <20130226165614.GA22422@phenom.dumpdata.com>
X-Enigmail-Version: 1.5
Content-Type: multipart/mixed; boundary="------------000609010708080401060703"
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------000609010708080401060703
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/26/2013 05:56 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 03:32:43PM +0100, Michal Fiala wrote:
>> Hallo,
>>
>> I have updated system to xen 4.2.1, linux kernel 3.7.5. System boots
>> without problem. When I run reboot or shutdown -r now, system correctly
>> shutdowns all runlevels and then system crashed, see crash_output.txt.
>> I have the same problem with kernel linux 3.2.37. When I shudown system
>> (halt), then it is without problem. I have tested kernel 3.7.5 without
>> xen hypervisor, it was without problems. Required debug informations
>> (http://wiki.xen.org/wiki/XenParavirtOpsHelp) in attachment.
>> Could you please help me with this problem?
>>
>> Thanks
>>
>> Michal
>>
> 
> 
>> INIT: Switching to runlevel: 6
>> INIT: Sending processes the TERM signal
>>  * Stopping local
>>  [ ok ]
>>  * Stopping vixie-cron ...
>>  [ ok ]
>>  * Saving random seed ...
>>  [ ok ]
>>  * Deactivating additional swap space ...
>>  [ ok ]
>>  * Stopping sshd ...
>>  [ ok ]
>>  * Use of the opts variable is deprecated and will be
>>  * removed in the future.
>>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>>  * Stopping Xen control daemon ...
>>  [ ok ]
>>  * Stoping xenconsoled daemon ...
>>  [ ok ]
>>  * Stopping... ...
>>  [ ok ]
>>  * Stopping ntpd ...
>>  [ ok ]
>>  * Stopping xenstored daemon ...
>>  [ ok ]
>>  * Stopping nrpe ...
>>  [ ok ]
>>  * Unmounting network filesystems ...
>>  [ ok ]
>>  * Stopping munin-node ...
>>  [ ok ]
>>  * Stopping fail2ban ...
>>  [ ok ]
>>  * Stopping bacula file daemon ...
>>  [ ok ]
>>  * Stopping syslog-ng ...
>>  [ ok ]
>>  * Bringing down interface br0
>>  *   Destroying bridge br0 ...
>>  [ ok ]
>>  * Bringing down interface bond0
>>  *   Removing slaves from bond0 ...
>>  *     eth0 eth1 
>>  [ ok ]
>>  * Use of the opts variable is deprecated and will be
>>  * removed in the future.
>>  * Please use extra_commands, extra_started_commands or extra_stopped_commands.
>>  * Stopping firewall ...
>>  [ ok ]
>>  * Bringing down interface lo
>>  * Unmounting loop devices
>>  * Unmounting filesystems
>>  *   Unmounting /boot ...
>>  [ ok ]
>>  *   Unmounting /data/d0700 ...
>>  [ ok ]
>>  *   Unmounting /var ...
>>  [ ok ]
>>  * Deactivating swap devices ...
>>  [ ok ]
>>  * Shutting down the Logical Volume Manager
>>  *   Shutting Down LVs & VGs ...
>>   Command failed with status code 2.
>>   No such command.  Try 'help'.
>>  * Failed
>>  [ !! ]
>>  * Finished Shutting down the Logical Volume Manager
>>  * Stopping udev ...
>>  [ ok ]
>>  * Setting hardware clock using the system clock [UTC] ...
>>  [ ok ]
>>  * Terminating remaining processes ...
>>  [ ok ]
>>  * Killing remaining processes ...
>>  [ ok ]
>>  * Saving dependency cache ...
>>  [ ok ]
>>  * Remounting remaining filesystems read-only ...
>>  *   Remounting / read only ...
>>  [ ok ]
>>  [ ok ]
>> [  612.749666] Restarting system.
>> [  618.364165] int3: 0000 [#1] SMP 
>> [  618.364396] Modules linked in: bonding
>> [  618.364590] CPU 0 
>> [  618.364658] Pid: 9998, comm: reboot Tainted: G        W    3.7.5-hardened #4 Dell Inc. PowerEdge R720xd/0VWT90
>> [  618.364806] RIP: e030:[<ffffffff8102a894>]  [<ffffffff8102a894>] native_machine_emergency_restart+0x74/0x250
>> [  618.364956] RSP: e02b:ffff880136b35da8  EFLAGS: 00000046
>> [  618.365130] RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffffff8172ad90
>> [  618.365308] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81ad8cdc
>> [  618.365487] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
>> [  618.365663] R10: 00000000000005dd R11: 0000000000000000 R12: 0000000000000cf9
>> [  618.365867] R13: ffffffff8172ad90 R14: 0000000000000061 R15: 0000000000000000
>> [  618.366045] FS:  00007f32051f0700(0000) GS:ffff88013d600000(0000) knlGS:0000000000000000
>> [  618.366317] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  618.366489] CR2: 00007fa697fb3d30 CR3: 0000000135590000 CR4: 0000000000042660
>> [  618.366664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  618.366839] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  618.367013] Process reboot (pid: 9998, threadinfo ffff880137af3b90, task ffff880137af3780)
>> [  618.367288] Stack:
>> [  618.367482]  0000000000000009 0000000081045315 0000000000000000 0000000001234567
>> [  618.368001]  0000000028121969 0000000000000022 0000000000000000 0000000000000000
>> [  618.368527]  0000000001234567 0000000028121969 0000000000000022 00007f3205203248
>> [  618.369079] Call Trace:
>> [  618.369250]  [<ffffffff8102aa9d>] ? native_machine_restart+0x2d/0x40
> 
> native machine restart? It should have been xen_restart!

Boot xen.gz, dom0 kernel, login to console as a root, run reboot.

> 
> Can you attach the full bootup serial log please?

see attachment, it is also included in my first mail in tgz package.

> 
> What distro is this?

Gentoo Base System release 2.1

> 

Now I am playing with kernel reboot parameter, I have tried
reboot=b, restart also with some problems.

[  110.416591] Restarting system.
(XEN) mm.c:2518:d0 Bad type (saw 7400000000000001 != exp
4000000000000000) for )
(XEN) mm.c:2846:d0 Error while installing new baseptr 102c09b
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.2.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    000b:[<0000000000099220>]
(XEN) RFLAGS: 0000000000010292   EM: 1   CONTEXT: pv guest
(XEN) rax: ffff880000098000   rbx: 0000000000000000   rcx: ffffffff81b08640
(XEN) rdx: 0000000000000000   rsi: 0000000000000006   rdi: 0000000000000000
(XEN) rbp: 0000000000000000   rsp: 0000000034147d98   r8:  000000000000000a
(XEN) r9:  0000000000000000   r10: 00000000000005e0   r11: 00000000000005df
(XEN) r12: 0000000000000cf9   r13: ffffffff8172ad90   r14: 0000000000000062
(XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000426f0
(XEN) cr3: 00000008fd86a000   cr2: 0000000000099220
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: 000b
(XEN) Guest stack trace from rsp=0000000034147d98:
(XEN)   Fault while accessing guest memory.
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

--------------000609010708080401060703
Content-Type: text/plain; charset=UTF-8;
 name="full_serial_console_output.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="full_serial_console_output.txt"

  Booting 'Xen 4.2 / linux-3.7.5-hardened'
                                                                    
root (hd0,0)
 Filesystem type is xfs, partition type 0x83
kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0
console=com2 com2=115200,8n1
   [Multiboot-elf, <0x100000:0x197828:0x527d8>, shtab=0x2ea078, entry=0x100000]
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
   [Multiboot-module @ 0x2eb000, 0x4dc160 bytes]

 \ \/ /___ _ __   | || |  |___ \  / |
  \  // _ \ '_ \  | || |_   __) | | |
  /  \  __/ | | | |__   _| / __/ _| |
 /_/\_\___|_| |_|    |_|(_)_____(_)_|
                                     
(XEN) Xen version 4.2.1 (@mobil.cz) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Tue 3
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0 console=c1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e000 (usable)
(XEN)  0000000000100000 - 00000000bd2f0000 (usable)
(XEN)  00000000bd2f0000 - 00000000bd31c000 (reserved)
(XEN)  00000000bd31c000 - 00000000bd35b000 (ACPI data)
(XEN)  00000000bd35b000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000002040000000 (usable)
(XEN) ACPI: RSDP 000F0F40, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1048, 00A4 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BD3411CC, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BD31C000, 7760 (r1 DELL   PE_SC3          1 INTL 20110211)
(XEN) ACPI: FACS BD343000, 0040
(XEN) ACPI: APIC BD340478, 016A (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BD3405E4, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BD340638, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BD340674, 0158 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BD340990, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BD3409D0, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BD340B08, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BD323920, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BD323B90, 059C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BD323760, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BD323790, 0190 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BD341164, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: PC__ BD3410F4, 006E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BD340D30, 03C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BD344000, 7624 (r1 INTEL  PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 131026MB (134171192kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
(XEN) IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) ERST table is invalid
(XEN) Would not enable x2APIC due to interrupt remapping cannot be enabled.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2500.081 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) 'A' pressed -> using normal key handling
(XEN) Allocated console ring of 64 KiB.
(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, 1GB
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) Brought up 24 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2000000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000102c000000->0000001030000000 (1032192 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82000000
(XEN)  Init. ramdisk: ffffffff82000000->ffffffff82000000
(XEN)  Phys-Mach map: ffffffff82000000->ffffffff82800000
(XEN)  Start info:    ffffffff82800000->ffffffff828004b4
(XEN)  Page tables:   ffffffff82801000->ffffffff8281a000
(XEN)  Boot stack:    ffffffff8281a000->ffffffff8281b000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a281c0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ....................................................................
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.5-hardened (root@rajvir3) (gcc version 4.6.3 (Gentoo Hardene3
[    0.000000] Command line: root=/dev/sda6 console=tty0 console=hvc0
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing bd2f0-100000 pfn range: 273680 pages freed
[    0.000000] Released 273778 pages of unused memory
[    0.000000] Set 273778 page(s) to 1-1 mapping
[    0.000000] Populating 100000-142d72 pfn range: 273778 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bd2effff] usable
[    0.000000] Xen: [mem 0x00000000bd2f0000-0x00000000bd31bfff] reserved
[    0.000000] Xen: [mem 0x00000000bd31c000-0x00000000bd35afff] ACPI data
[    0.000000] Xen: [mem 0x00000000bd35b000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000142d71fff] usable
[    0.000000] Xen: [mem 0x0000000142d72000-0x000000203fffffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x142d72 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbd2f0 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0xbd2effff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: RSDP 00000000000f0f40 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000f1048 000A4 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: FACP 00000000bd3411cc 000F4 (v03 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: DSDT 00000000bd31c000 07760 (v01 DELL   PE_SC3   00000001 INTL 20110211)
[    0.000000] ACPI: FACS 00000000bd343000 00040
[    0.000000] ACPI: APIC 00000000bd340478 0016A (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SPCR 00000000bd3405e4 00050 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HPET 00000000bd340638 00038 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: XMAR 00000000bd340674 00158 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: MCFG 00000000bd340990 0003C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: WD__ 00000000bd3409d0 00134 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SLIC 00000000bd340b08 00024 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: ERST 00000000bd323920 00270 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HEST 00000000bd323b90 0059C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: BERT 00000000bd323760 00030 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: EINJ 00000000bd323790 00190 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: TCPA 00000000bd341164 00064 (v02 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: PC__ 00000000bd3410f4 0006E (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SRAT 00000000bd340d30 003C0 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SSDT 00000000bd344000 07624 (v01 INTEL  PPM RCM  80000001 INTL 20061109)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000142d71fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x142d71fff]
[    0.000000]   NODE_DATA [mem 0x142d6e000-0x142d71fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x142d71fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0xbd2effff]
[    0.000000]   node   0: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x26] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x28] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x2a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x27] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x09] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x29] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x0b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x2b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x59] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x5b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x5d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x5f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[64])
[    0.000000] IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 32 CPUs, 8 hotplug CPUs
[    0.000000] e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88013d600000 s64512 r8192 d21504 u131072
[   50.166367] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1026398
[   50.166369] Policy zone: Normal
[   50.166371] Kernel command line: root=/dev/sda6 console=tty0 console=hvc0
[   50.166402] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   50.166406] __ex_table already sorted, skipping sort
[   50.166434] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[   50.194619] software IO TLB [mem 0x139600000-0x13d5fffff] (64MB) mapped at [ffff8801396000]
[   50.207444] Memory: 4029096k/5289416k available (7106k kernel code, 1095176k absent, 16514)
[   50.207520] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[   50.207550] Hierarchical RCU implementation.
[   50.207551]  RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=4.
[   50.207560] NR_IRQS:4352 nr_irqs:1024 16
[   50.207625] xen: sci override: global_irq=9 trigger=0 polarity=0
[   50.207662] xen: acpi sci 9
[   50.216286] Console: colour VGA+ 80x25
[   50.237789] console [tty0] enabled
[   50.238195] console [hvc0] enabled
[   50.238390] installing Xen timer for CPU 0
[   50.238580] tsc: Detected 2500.080 MHz processor
[   50.238751] Calibrating delay loop (skipped), value calculated using timer frequency.. 500)
[   50.239096] pid_max: default: 32768 minimum: 501
[   50.239801] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   50.240915] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   50.241431] Mount-cache hash table entries: 256
[   50.241801] Initializing cgroup subsys cpuacct
[   50.241973] Initializing cgroup subsys freezer
[   50.242199] CPU: Physical Processor ID: 0
[   50.242368] CPU: Processor Core ID: 0
[   50.242536] mce: CPU supports 2 MCE banks
[   50.242766] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[   50.242766] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[   50.242766] tlb_flushall_shift: 5
[   50.243423] Freeing SMP alternatives: 32k freed
[    0.007054] ACPI: Core revision 20120913
[    0.009510] cpu 0 spinlock event irq 105
[    0.009693] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events.
[    0.010286] installing Xen timer for CPU 1
[    0.010463] cpu 1 spinlock event irq 112
[    0.010848] installing Xen timer for CPU 2
[    0.011023] cpu 2 spinlock event irq 119
[    0.011363] installing Xen timer for CPU 3
[    0.011537] cpu 3 spinlock event irq 126
[    0.011844] Brought up 4 CPUs
[    0.012277] devtmpfs: initialized
[    0.012713] xor: automatically using best checksumming function:
[    0.052559]    avx       : 22051.000 MB/sec
[    0.052734] Grant tables using version 2 layout.
[    0.052912] Grant table initialized
[    0.053118] NET: Registered protocol family 16
[    0.053816] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.054090] ACPI: bus type pci registered
[    0.055403] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base)
[    0.055684] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.086464] PCI: Using configuration type 1 for base access
[    0.086664] PCI: Dell System detected, enabling pci=bfsort.
[    0.094712] bio: create slab <bio-0> at 0
[    0.161842] raid6: sse2x1    7662 MB/s
[    0.230644] raid6: sse2x2    9538 MB/s
[    0.299461] raid6: sse2x4   10973 MB/s
[    0.299628] raid6: using algorithm sse2x4 (10973 MB/s)
[    0.299798] raid6: using ssse3x2 recovery algorithm
[    0.299998] ACPI: Added _OSI(Module Device)
[    0.300165] ACPI: Added _OSI(Processor Device)
[    0.300333] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302429] ACPI: Added _OSI(Processor Aggregator Device)
[    0.304560] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.305551] ACPI: Interpreter enabled
[    0.305722] ACPI: (supports S0 S5)
[    0.306015] ACPI: Using IOAPIC for interrupt routing
[    0.312565] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and reg
[    0.331230] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3d])
[    0.332414] PCI host bridge to bus 0000:00
[    0.332646] pci_bus 0000:00: root bus resource [bus 00-3d]
[    0.332813] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    0.332981] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    0.333150] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    0.333319] pci_bus 0000:00: root bus resource [io  0x0d00-0x1fff]
[    0.333486] pci_bus 0000:00: root bus resource [io  0xe000-0xffff]
[    0.333657] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.333831] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xdfffffff]
[    0.334022] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff]
[    0.337651] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.338352] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.338605] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.339050] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.339313] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.339571] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.339830] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.343411] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.353509] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.359232] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.366425] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.368708] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.370402] pci 0000:00:1e.0: PCI bridge to [bus 0d] (subtractive decode)
[    0.371866]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.372334]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.384347] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 40-7e])
[    0.386540] PCI host bridge to bus 0000:40
[    0.386753] pci_bus 0000:40: root bus resource [bus 40-7e]
[    0.386951] pci_bus 0000:40: root bus resource [io  0x2000-0x3fff]
[    0.387149] pci_bus 0000:40: root bus resource [io  0x4000-0x5fff]
[    0.387348] pci_bus 0000:40: root bus resource [io  0x6000-0x7fff]
[    0.387546] pci_bus 0000:40: root bus resource [io  0x8000-0x9fff]
[    0.387744] pci_bus 0000:40: root bus resource [io  0xa000-0xbfff]
[    0.387955] pci_bus 0000:40: root bus resource [io  0xc000-0xdfff]
[    0.388155] pci_bus 0000:40: root bus resource [mem 0xd0000000-0xd7ffffff]
[    0.390449] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.390804] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.391159] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.391522] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.392451]  pci0000:40: Requesting ACPI _OSC control (0x1d)
[    0.392929]  pci0000:40: ACPI _OSC control (0x1d) granted
[    0.395163] ACPI: PCI Root Bridge [P0B1] (domain 0000 [bus 3f])
[    0.395515] PCI host bridge to bus 0000:3f
[    0.395713] pci_bus 0000:3f: root bus resource [bus 3f]
[    0.404007]  pci0000:3f: Requesting ACPI _OSC control (0x1d)
[    0.404484]  pci0000:3f: ACPI _OSC control (0x1d) granted
[    0.413321] ACPI: PCI Root Bridge [P1B1] (domain 0000 [bus 7f])
[    0.413667] PCI host bridge to bus 0000:7f
[    0.413862] pci_bus 0000:7f: root bus resource [bus 7f]
[    0.422347]  pci0000:7f: Requesting ACPI _OSC control (0x1d)
[    0.422809]  pci0000:7f: ACPI _OSC control (0x1d) granted
[    0.427766] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 11 14 *15)
[    0.428866] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 11 *14 15)
[    0.429941] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.431276] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *11 14 15)
[    0.432386] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 11 14 15)
[    0.433485] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.434824] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 *6 7 11 14 15)
[    0.435882] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 11 *14 15)
[    0.437121] xen/balloon: Initialising balloon driver.
[    0.437493] xen-balloon: Initialising balloon driver.
[    0.438249] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.438581] vgaarb: loaded
[    0.438766] vgaarb: bridge control possible 0000:0b:00.0
[    0.439309] SCSI subsystem initialized
[    0.439512] ACPI: bus type scsi registered
[    0.440271] ACPI: bus type usb registered
[    0.440639] usbcore: registered new interface driver usbfs
[    0.440919] usbcore: registered new interface driver hub
[    0.441261] usbcore: registered new device driver usb
[    0.441973] PCI: Using ACPI for IRQ routing
[    0.465197] Switching to clocksource xen
[    0.465669] pnp: PnP ACPI init
[    0.465880] ACPI: bus type pnp registered
[    0.469008] Already setup the GSI :3
[    0.470110] system 00:07: [io  0x0800-0x087f] has been reserved
[    0.470312] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.470521] system 00:07: [io  0x0900-0x091f] has been reserved
[    0.470718] system 00:07: [io  0x0920-0x0923] has been reserved
[    0.470914] system 00:07: [io  0x0924] has been reserved
[    0.471108] system 00:07: [io  0x0370-0x0377] has been reserved
[    0.471304] system 00:07: [io  0x0ca0-0x0ca7] has been reserved
[    0.471499] system 00:07: [io  0x0ca9-0x0cab] has been reserved
[    0.471695] system 00:07: [io  0x0cad-0x0caf] has been reserved
[    0.471889] system 00:07: [io  0x0cb0-0x0cbf] has been reserved
[    0.472398] system 00:08: [io  0x0ca8] has been reserved
[    0.472592] system 00:08: [io  0x0cac] has been reserved
[    0.473441] system 00:09: [mem 0xe0000000-0xe3efffff] has been reserved
[    0.475223] system 00:0b: [mem 0xe4000000-0xe7ffffff] has been reserved
[    0.475856] system 00:0d: [mem 0xe3f00000-0xe3ffffff] has been reserved
[    0.476308] system 00:0e: [mem 0xdf900000-0xdf901fff] has been reserved
[    0.476788] system 00:0f: [mem 0xd3000000-0xd3001fff] has been reserved
[    0.477672] pnp: PnP ACPI: found 18 devices
[    0.477866] ACPI: ACPI bus type pnp unregistered
[    0.498410] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    0.498625] pci 0000:01:00.1: address space collision: [mem 0xdc800000-0xdc83ffff pref] co]
[    0.498943] pci 0000:02:00.1: address space collision: [mem 0xdc000000-0xdc03ffff pref] co]
[    0.500490] pci 0000:02:00.1: BAR 6: assigned [mem 0xd9000000-0xd903ffff pref]
[    0.500793] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.500995] pci 0000:00:01.0:   bridge window [mem 0xdc000000-0xdc7fffff]
[    0.501202] pci 0000:00:01.0:   bridge window [mem 0xd9000000-0xd90fffff 64bit pref]
[    0.501560] pci 0000:01:00.1: BAR 6: assigned [mem 0xd9100000-0xd913ffff pref]
[    0.501866] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.502068] pci 0000:00:01.1:   bridge window [mem 0xdc800000-0xdcffffff]
[    0.502274] pci 0000:00:01.1:   bridge window [mem 0xd9100000-0xd91fffff 64bit pref]
[    0.502584] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.502798] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.502995] pci 0000:00:02.2:   bridge window [io  0xf000-0xffff]
[    0.503255] pci 0000:00:02.2:   bridge window [mem 0xdd000000-0xddffffff]
[    0.503465] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.503679] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.503897] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.504112] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.504449] pci 0000:0a:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.504756] pci 0000:0a:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.505249] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.505606] pci 0000:09:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.505899] pci 0000:09:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.506411] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.506744] pci 0000:09:01.0:   bridge window [mem 0xdf700000-0xdf7fffff]
[    0.507286] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.507604] pci 0000:08:00.0:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.507889] pci 0000:08:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.508423] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.508625] pci 0000:00:1c.7:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.508827] pci 0000:00:1c.7:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.509162] pci 0000:00:1e.0: PCI bridge to [bus 0d]
[    0.509385] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.509623] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.509844] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.510064] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.510366] Already setup the GSI :53
[    0.510566] Already setup the GSI :53
[    0.510780] Already setup the GSI :53
[    0.510978] Already setup the GSI :53
[    0.511773] Already setup the GSI :85
[    0.511974] Already setup the GSI :85
[    0.512173] Already setup the GSI :85
[    0.512556] NET: Registered protocol family 2
[    0.515017] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.517734] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.518170] TCP: Hash tables configured (established 524288 bind 65536)
[    0.518421] TCP: reno registered
[    0.518636] UDP hash table entries: 2048 (order: 4, 65536 bytes)
  Booting 'Xen 4.2 / linux-3.7.5-hardened'
                                                                    
root (hd0,0)
 Filesystem type is xfs, partition type 0x83
kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0
console=com2 com2=115200,8n1
   [Multiboot-elf, <0x100000:0x197828:0x527d8>, shtab=0x2ea078, entry=0x100000]
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
   [Multiboot-module @ 0x2eb000, 0x4dc160 bytes]

 \ \/ /___ _ __   | || |  |___ \  / |
  \  // _ \ '_ \  | || |_   __) | | |
  /  \  __/ | | | |__   _| / __/ _| |
 /_/\_\___|_| |_|    |_|(_)_____(_)_|
                                     
(XEN) Xen version 4.2.1 (@mobil.cz) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Tue 3
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0 console=c1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e000 (usable)
(XEN)  0000000000100000 - 00000000bd2f0000 (usable)
(XEN)  00000000bd2f0000 - 00000000bd31c000 (reserved)
(XEN)  00000000bd31c000 - 00000000bd35b000 (ACPI data)
(XEN)  00000000bd35b000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000002040000000 (usable)
(XEN) ACPI: RSDP 000F0F40, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1048, 00A4 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BD3411CC, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BD31C000, 7760 (r1 DELL   PE_SC3          1 INTL 20110211)
(XEN) ACPI: FACS BD343000, 0040
(XEN) ACPI: APIC BD340478, 016A (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BD3405E4, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BD340638, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BD340674, 0158 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BD340990, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BD3409D0, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BD340B08, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BD323920, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BD323B90, 059C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BD323760, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BD323790, 0190 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BD341164, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: PC__ BD3410F4, 006E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BD340D30, 03C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BD344000, 7624 (r1 INTEL  PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 131026MB (134171192kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
(XEN) IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) ERST table is invalid
(XEN) Would not enable x2APIC due to interrupt remapping cannot be enabled.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2500.081 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) 'A' pressed -> using normal key handling
(XEN) Allocated console ring of 64 KiB.
(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, 1GB
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) Brought up 24 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2000000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000102c000000->0000001030000000 (1032192 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82000000
(XEN)  Init. ramdisk: ffffffff82000000->ffffffff82000000
(XEN)  Phys-Mach map: ffffffff82000000->ffffffff82800000
(XEN)  Start info:    ffffffff82800000->ffffffff828004b4
(XEN)  Page tables:   ffffffff82801000->ffffffff8281a000
(XEN)  Boot stack:    ffffffff8281a000->ffffffff8281b000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a281c0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ....................................................................
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.5-hardened (root@rajvir3) (gcc version 4.6.3 (Gentoo Hardene3
[    0.000000] Command line: root=/dev/sda6 console=tty0 console=hvc0
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing bd2f0-100000 pfn range: 273680 pages freed
[    0.000000] Released 273778 pages of unused memory
[    0.000000] Set 273778 page(s) to 1-1 mapping
[    0.000000] Populating 100000-142d72 pfn range: 273778 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bd2effff] usable
[    0.000000] Xen: [mem 0x00000000bd2f0000-0x00000000bd31bfff] reserved
[    0.000000] Xen: [mem 0x00000000bd31c000-0x00000000bd35afff] ACPI data
[    0.000000] Xen: [mem 0x00000000bd35b000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000142d71fff] usable
[    0.000000] Xen: [mem 0x0000000142d72000-0x000000203fffffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x142d72 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbd2f0 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0xbd2effff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: RSDP 00000000000f0f40 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000f1048 000A4 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: FACP 00000000bd3411cc 000F4 (v03 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: DSDT 00000000bd31c000 07760 (v01 DELL   PE_SC3   00000001 INTL 20110211)
[    0.000000] ACPI: FACS 00000000bd343000 00040
[    0.000000] ACPI: APIC 00000000bd340478 0016A (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SPCR 00000000bd3405e4 00050 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HPET 00000000bd340638 00038 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: XMAR 00000000bd340674 00158 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: MCFG 00000000bd340990 0003C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: WD__ 00000000bd3409d0 00134 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SLIC 00000000bd340b08 00024 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: ERST 00000000bd323920 00270 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HEST 00000000bd323b90 0059C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: BERT 00000000bd323760 00030 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: EINJ 00000000bd323790 00190 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: TCPA 00000000bd341164 00064 (v02 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: PC__ 00000000bd3410f4 0006E (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SRAT 00000000bd340d30 003C0 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SSDT 00000000bd344000 07624 (v01 INTEL  PPM RCM  80000001 INTL 20061109)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000142d71fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x142d71fff]
[    0.000000]   NODE_DATA [mem 0x142d6e000-0x142d71fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x142d71fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0xbd2effff]
[    0.000000]   node   0: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x26] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x28] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x2a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x27] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x09] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x29] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x0b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x2b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x59] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x5b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x5d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x5f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[64])
[    0.000000] IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 32 CPUs, 8 hotplug CPUs
[    0.000000] e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88013d600000 s64512 r8192 d21504 u131072
[   50.166367] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1026398
[   50.166369] Policy zone: Normal
[   50.166371] Kernel command line: root=/dev/sda6 console=tty0 console=hvc0
[   50.166402] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   50.166406] __ex_table already sorted, skipping sort
[   50.166434] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[   50.194619] software IO TLB [mem 0x139600000-0x13d5fffff] (64MB) mapped at [ffff8801396000]
[   50.207444] Memory: 4029096k/5289416k available (7106k kernel code, 1095176k absent, 16514)
[   50.207520] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[   50.207550] Hierarchical RCU implementation.
[   50.207551]  RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=4.
[   50.207560] NR_IRQS:4352 nr_irqs:1024 16
[   50.207625] xen: sci override: global_irq=9 trigger=0 polarity=0
[   50.207662] xen: acpi sci 9
[   50.216286] Console: colour VGA+ 80x25
[   50.237789] console [tty0] enabled
[   50.238195] console [hvc0] enabled
[   50.238390] installing Xen timer for CPU 0
[   50.238580] tsc: Detected 2500.080 MHz processor
[   50.238751] Calibrating delay loop (skipped), value calculated using timer frequency.. 500)
[   50.239096] pid_max: default: 32768 minimum: 501
[   50.239801] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   50.240915] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   50.241431] Mount-cache hash table entries: 256
[   50.241801] Initializing cgroup subsys cpuacct
[   50.241973] Initializing cgroup subsys freezer
[   50.242199] CPU: Physical Processor ID: 0
[   50.242368] CPU: Processor Core ID: 0
[   50.242536] mce: CPU supports 2 MCE banks
[   50.242766] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[   50.242766] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[   50.242766] tlb_flushall_shift: 5
[   50.243423] Freeing SMP alternatives: 32k freed
[    0.007054] ACPI: Core revision 20120913
[    0.009510] cpu 0 spinlock event irq 105
[    0.009693] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events.
[    0.010286] installing Xen timer for CPU 1
[    0.010463] cpu 1 spinlock event irq 112
[    0.010848] installing Xen timer for CPU 2
[    0.011023] cpu 2 spinlock event irq 119
[    0.011363] installing Xen timer for CPU 3
[    0.011537] cpu 3 spinlock event irq 126
[    0.011844] Brought up 4 CPUs
[    0.012277] devtmpfs: initialized
[    0.012713] xor: automatically using best checksumming function:
[    0.052559]    avx       : 22051.000 MB/sec
[    0.052734] Grant tables using version 2 layout.
[    0.052912] Grant table initialized
[    0.053118] NET: Registered protocol family 16
[    0.053816] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.054090] ACPI: bus type pci registered
[    0.055403] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base)
[    0.055684] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.086464] PCI: Using configuration type 1 for base access
[    0.086664] PCI: Dell System detected, enabling pci=bfsort.
[    0.094712] bio: create slab <bio-0> at 0
[    0.161842] raid6: sse2x1    7662 MB/s
[    0.230644] raid6: sse2x2    9538 MB/s
[    0.299461] raid6: sse2x4   10973 MB/s
[    0.299628] raid6: using algorithm sse2x4 (10973 MB/s)
[    0.299798] raid6: using ssse3x2 recovery algorithm
[    0.299998] ACPI: Added _OSI(Module Device)
[    0.300165] ACPI: Added _OSI(Processor Device)
[    0.300333] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302429] ACPI: Added _OSI(Processor Aggregator Device)
[    0.304560] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.305551] ACPI: Interpreter enabled
[    0.305722] ACPI: (supports S0 S5)
[    0.306015] ACPI: Using IOAPIC for interrupt routing
[    0.312565] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and reg
[    0.331230] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3d])
[    0.332414] PCI host bridge to bus 0000:00
[    0.332646] pci_bus 0000:00: root bus resource [bus 00-3d]
[    0.332813] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    0.332981] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    0.333150] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    0.333319] pci_bus 0000:00: root bus resource [io  0x0d00-0x1fff]
[    0.333486] pci_bus 0000:00: root bus resource [io  0xe000-0xffff]
[    0.333657] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.333831] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xdfffffff]
[    0.334022] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff]
[    0.337651] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.338352] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.338605] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.339050] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.339313] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.339571] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.339830] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.343411] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.353509] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.359232] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.366425] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.368708] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.370402] pci 0000:00:1e.0: PCI bridge to [bus 0d] (subtractive decode)
[    0.371866]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.372334]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.384347] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 40-7e])
[    0.386540] PCI host bridge to bus 0000:40
[    0.386753] pci_bus 0000:40: root bus resource [bus 40-7e]
[    0.386951] pci_bus 0000:40: root bus resource [io  0x2000-0x3fff]
[    0.387149] pci_bus 0000:40: root bus resource [io  0x4000-0x5fff]
[    0.387348] pci_bus 0000:40: root bus resource [io  0x6000-0x7fff]
[    0.387546] pci_bus 0000:40: root bus resource [io  0x8000-0x9fff]
[    0.387744] pci_bus 0000:40: root bus resource [io  0xa000-0xbfff]
[    0.387955] pci_bus 0000:40: root bus resource [io  0xc000-0xdfff]
[    0.388155] pci_bus 0000:40: root bus resource [mem 0xd0000000-0xd7ffffff]
[    0.390449] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.390804] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.391159] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.391522] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.392451]  pci0000:40: Requesting ACPI _OSC control (0x1d)
[    0.392929]  pci0000:40: ACPI _OSC control (0x1d) granted
[    0.395163] ACPI: PCI Root Bridge [P0B1] (domain 0000 [bus 3f])
[    0.395515] PCI host bridge to bus 0000:3f
[    0.395713] pci_bus 0000:3f: root bus resource [bus 3f]
[    0.404007]  pci0000:3f: Requesting ACPI _OSC control (0x1d)
[    0.404484]  pci0000:3f: ACPI _OSC control (0x1d) granted
[    0.413321] ACPI: PCI Root Bridge [P1B1] (domain 0000 [bus 7f])
[    0.413667] PCI host bridge to bus 0000:7f
[    0.413862] pci_bus 0000:7f: root bus resource [bus 7f]
[    0.422347]  pci0000:7f: Requesting ACPI _OSC control (0x1d)
[    0.422809]  pci0000:7f: ACPI _OSC control (0x1d) granted
[    0.427766] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 11 14 *15)
[    0.428866] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 11 *14 15)
[    0.429941] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.431276] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *11 14 15)
[    0.432386] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 11 14 15)
[    0.433485] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.434824] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 *6 7 11 14 15)
[    0.435882] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 11 *14 15)
[    0.437121] xen/balloon: Initialising balloon driver.
[    0.437493] xen-balloon: Initialising balloon driver.
[    0.438249] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.438581] vgaarb: loaded
[    0.438766] vgaarb: bridge control possible 0000:0b:00.0
[    0.439309] SCSI subsystem initialized
[    0.439512] ACPI: bus type scsi registered
[    0.440271] ACPI: bus type usb registered
[    0.440639] usbcore: registered new interface driver usbfs
[    0.440919] usbcore: registered new interface driver hub
[    0.441261] usbcore: registered new device driver usb
[    0.441973] PCI: Using ACPI for IRQ routing
[    0.465197] Switching to clocksource xen
[    0.465669] pnp: PnP ACPI init
[    0.465880] ACPI: bus type pnp registered
[    0.469008] Already setup the GSI :3
[    0.470110] system 00:07: [io  0x0800-0x087f] has been reserved
[    0.470312] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.470521] system 00:07: [io  0x0900-0x091f] has been reserved
[    0.470718] system 00:07: [io  0x0920-0x0923] has been reserved
[    0.470914] system 00:07: [io  0x0924] has been reserved
[    0.471108] system 00:07: [io  0x0370-0x0377] has been reserved
[    0.471304] system 00:07: [io  0x0ca0-0x0ca7] has been reserved
[    0.471499] system 00:07: [io  0x0ca9-0x0cab] has been reserved
[    0.471695] system 00:07: [io  0x0cad-0x0caf] has been reserved
[    0.471889] system 00:07: [io  0x0cb0-0x0cbf] has been reserved
[    0.472398] system 00:08: [io  0x0ca8] has been reserved
[    0.472592] system 00:08: [io  0x0cac] has been reserved
[    0.473441] system 00:09: [mem 0xe0000000-0xe3efffff] has been reserved
[    0.475223] system 00:0b: [mem 0xe4000000-0xe7ffffff] has been reserved
[    0.475856] system 00:0d: [mem 0xe3f00000-0xe3ffffff] has been reserved
[    0.476308] system 00:0e: [mem 0xdf900000-0xdf901fff] has been reserved
[    0.476788] system 00:0f: [mem 0xd3000000-0xd3001fff] has been reserved
[    0.477672] pnp: PnP ACPI: found 18 devices
[    0.477866] ACPI: ACPI bus type pnp unregistered
[    0.498410] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    0.498625] pci 0000:01:00.1: address space collision: [mem 0xdc800000-0xdc83ffff pref] co]
[    0.498943] pci 0000:02:00.1: address space collision: [mem 0xdc000000-0xdc03ffff pref] co]
[    0.500490] pci 0000:02:00.1: BAR 6: assigned [mem 0xd9000000-0xd903ffff pref]
[    0.500793] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.500995] pci 0000:00:01.0:   bridge window [mem 0xdc000000-0xdc7fffff]
[    0.501202] pci 0000:00:01.0:   bridge window [mem 0xd9000000-0xd90fffff 64bit pref]
[    0.501560] pci 0000:01:00.1: BAR 6: assigned [mem 0xd9100000-0xd913ffff pref]
[    0.501866] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.502068] pci 0000:00:01.1:   bridge window [mem 0xdc800000-0xdcffffff]
[    0.502274] pci 0000:00:01.1:   bridge window [mem 0xd9100000-0xd91fffff 64bit pref]
[    0.502584] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.502798] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.502995] pci 0000:00:02.2:   bridge window [io  0xf000-0xffff]
[    0.503255] pci 0000:00:02.2:   bridge window [mem 0xdd000000-0xddffffff]
[    0.503465] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.503679] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.503897] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.504112] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.504449] pci 0000:0a:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.504756] pci 0000:0a:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.505249] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.505606] pci 0000:09:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.505899] pci 0000:09:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.506411] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.506744] pci 0000:09:01.0:   bridge window [mem 0xdf700000-0xdf7fffff]
[    0.507286] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.507604] pci 0000:08:00.0:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.507889] pci 0000:08:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.508423] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.508625] pci 0000:00:1c.7:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.508827] pci 0000:00:1c.7:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.509162] pci 0000:00:1e.0: PCI bridge to [bus 0d]
[    0.509385] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.509623] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.509844] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.510064] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.510366] Already setup the GSI :53
[    0.510566] Already setup the GSI :53
[    0.510780] Already setup the GSI :53
[    0.510978] Already setup the GSI :53
[    0.511773] Already setup the GSI :85
[    0.511974] Already setup the GSI :85
[    0.512173] Already setup the GSI :85
[    0.512556] NET: Registered protocol family 2
[    0.515017] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.517734] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.518170] TCP: Hash tables configured (established 524288 bind 65536)
[    0.518421] TCP: reno registered
[    0.518636] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[  Booting 'Xen 4.2 / linux-3.7.5-hardened'
                                                                    
root (hd0,0)
 Filesystem type is xfs, partition type 0x83
kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0
console=com2 com2=115200,8n1
   [Multiboot-elf, <0x100000:0x197828:0x527d8>, shtab=0x2ea078, entry=0x100000]
module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
   [Multiboot-module @ 0x2eb000, 0x4dc160 bytes]

 \ \/ /___ _ __   | || |  |___ \  / |
  \  // _ \ '_ \  | || |_   __) | | |
  /  \  __/ | | | |__   _| / __/ _| |
 /_/\_\___|_| |_|    |_|(_)_____(_)_|
                                     
(XEN) Xen version 4.2.1 (@mobil.cz) (gcc (Gentoo Hardened 4.6.3 p1.11, pie-0.5.2) 4.6.3) Tue 3
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin console=tty0 console=c1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e000 (usable)
(XEN)  0000000000100000 - 00000000bd2f0000 (usable)
(XEN)  00000000bd2f0000 - 00000000bd31c000 (reserved)
(XEN)  00000000bd31c000 - 00000000bd35b000 (ACPI data)
(XEN)  00000000bd35b000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fe000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000002040000000 (usable)
(XEN) ACPI: RSDP 000F0F40, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1048, 00A4 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: FACP BD3411CC, 00F4 (r3 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DSDT BD31C000, 7760 (r1 DELL   PE_SC3          1 INTL 20110211)
(XEN) ACPI: FACS BD343000, 0040
(XEN) ACPI: APIC BD340478, 016A (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SPCR BD3405E4, 0050 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HPET BD340638, 0038 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: DMAR BD340674, 0158 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: MCFG BD340990, 003C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: WD__ BD3409D0, 0134 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SLIC BD340B08, 0024 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: ERST BD323920, 0270 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: HEST BD323B90, 059C (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: BERT BD323760, 0030 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: EINJ BD323790, 0190 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: TCPA BD341164, 0064 (r2 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: PC__ BD3410F4, 006E (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SRAT BD340D30, 03C0 (r1 DELL   PE_SC3          1 DELL        1)
(XEN) ACPI: SSDT BD344000, 7624 (r1 INTEL  PPM RCM  80000001 INTL 20061109)
(XEN) System RAM: 131026MB (134171192kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Processor #0 6:13 APIC version 21
(XEN) Processor #32 6:13 APIC version 21
(XEN) Processor #2 6:13 APIC version 21
(XEN) Processor #34 6:13 APIC version 21
(XEN) Processor #4 6:13 APIC version 21
(XEN) Processor #36 6:13 APIC version 21
(XEN) Processor #6 6:13 APIC version 21
(XEN) Processor #38 6:13 APIC version 21
(XEN) Processor #8 6:13 APIC version 21
(XEN) Processor #40 6:13 APIC version 21
(XEN) Processor #10 6:13 APIC version 21
(XEN) Processor #42 6:13 APIC version 21
(XEN) Processor #1 6:13 APIC version 21
(XEN) Processor #33 6:13 APIC version 21
(XEN) Processor #3 6:13 APIC version 21
(XEN) Processor #35 6:13 APIC version 21
(XEN) Processor #5 6:13 APIC version 21
(XEN) Processor #37 6:13 APIC version 21
(XEN) Processor #7 6:13 APIC version 21
(XEN) Processor #39 6:13 APIC version 21
(XEN) Processor #9 6:13 APIC version 21
(XEN) Processor #41 6:13 APIC version 21
(XEN) Processor #11 6:13 APIC version 21
(XEN) Processor #43 6:13 APIC version 21
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
(XEN) IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) ERST table is invalid
(XEN) Would not enable x2APIC due to interrupt remapping cannot be enabled.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2500.081 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) 'A' pressed -> using normal key handling
(XEN) Allocated console ring of 64 KiB.
(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, 1GB
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) 'A' pressed -> using alternative key handling
(XEN) 'A' pressed -> using normal key handling
(XEN) Brought up 24 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2000000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000102c000000->0000001030000000 (1032192 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82000000
(XEN)  Init. ramdisk: ffffffff82000000->ffffffff82000000
(XEN)  Phys-Mach map: ffffffff82000000->ffffffff82800000
(XEN)  Start info:    ffffffff82800000->ffffffff828004b4
(XEN)  Page tables:   ffffffff82801000->ffffffff8281a000
(XEN)  Boot stack:    ffffffff8281a000->ffffffff8281b000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff81a281c0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: ....................................................................
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 240kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.5-hardened (root@rajvir3) (gcc version 4.6.3 (Gentoo Hardene3
[    0.000000] Command line: root=/dev/sda6 console=tty0 console=hvc0
[    0.000000] Freeing 9e-100 pfn range: 98 pages freed
[    0.000000] Freeing bd2f0-100000 pfn range: 273680 pages freed
[    0.000000] Released 273778 pages of unused memory
[    0.000000] Set 273778 page(s) to 1-1 mapping
[    0.000000] Populating 100000-142d72 pfn range: 273778 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009dfff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000bd2effff] usable
[    0.000000] Xen: [mem 0x00000000bd2f0000-0x00000000bd31bfff] reserved
[    0.000000] Xen: [mem 0x00000000bd31c000-0x00000000bd35afff] ACPI data
[    0.000000] Xen: [mem 0x00000000bd35b000-0x00000000bfffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x0000000142d71fff] usable
[    0.000000] Xen: [mem 0x0000000142d72000-0x000000203fffffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x142d72 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0xbd2f0 max_arch_pfn = 0x400000000
[    0.000000] init_memory_mapping: [mem 0x00000000-0xbd2effff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: RSDP 00000000000f0f40 00024 (v02 DELL  )
[    0.000000] ACPI: XSDT 00000000000f1048 000A4 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: FACP 00000000bd3411cc 000F4 (v03 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: DSDT 00000000bd31c000 07760 (v01 DELL   PE_SC3   00000001 INTL 20110211)
[    0.000000] ACPI: FACS 00000000bd343000 00040
[    0.000000] ACPI: APIC 00000000bd340478 0016A (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SPCR 00000000bd3405e4 00050 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HPET 00000000bd340638 00038 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: XMAR 00000000bd340674 00158 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: MCFG 00000000bd340990 0003C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: WD__ 00000000bd3409d0 00134 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SLIC 00000000bd340b08 00024 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: ERST 00000000bd323920 00270 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: HEST 00000000bd323b90 0059C (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: BERT 00000000bd323760 00030 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: EINJ 00000000bd323790 00190 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: TCPA 00000000bd341164 00064 (v02 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: PC__ 00000000bd3410f4 0006E (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SRAT 00000000bd340d30 003C0 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.000000] ACPI: SSDT 00000000bd344000 07624 (v01 INTEL  PPM RCM  80000001 INTL 20061109)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x0000000142d71fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x142d71fff]
[    0.000000]   NODE_DATA [mem 0x142d6e000-0x142d71fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x142d71fff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009dfff]
[    0.000000]   node   0: [mem 0x00100000-0xbd2effff]
[    0.000000]   node   0: [mem 0x100000000-0x142d71fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x20] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x22] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x26] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x28] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x2a] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x21] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x23] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x25] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x27] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x09] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x29] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x0b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x2b] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x59] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x5b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x5d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x5f] disabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec3f000] gsi_base[32])
[    0.000000] IOAPIC[1]: apic_id 1, version 32, address 0xfec3f000, GSI 32-55
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec7f000] gsi_base[64])
[    0.000000] IOAPIC[2]: apic_id 2, version 32, address 0xfec7f000, GSI 64-87
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 32 CPUs, 8 hotplug CPUs
[    0.000000] e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:32 nr_node_ids:1
[    0.000000] PERCPU: Embedded 23 pages/cpu @ffff88013d600000 s64512 r8192 d21504 u131072
[   50.166367] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1026398
[   50.166369] Policy zone: Normal
[   50.166371] Kernel command line: root=/dev/sda6 console=tty0 console=hvc0
[   50.166402] PID hash table entries: 4096 (order: 3, 32768 bytes)
[   50.166406] __ex_table already sorted, skipping sort
[   50.166434] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[   50.194619] software IO TLB [mem 0x139600000-0x13d5fffff] (64MB) mapped at [ffff8801396000]
[   50.207444] Memory: 4029096k/5289416k available (7106k kernel code, 1095176k absent, 16514)
[   50.207520] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[   50.207550] Hierarchical RCU implementation.
[   50.207551]  RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=4.
[   50.207560] NR_IRQS:4352 nr_irqs:1024 16
[   50.207625] xen: sci override: global_irq=9 trigger=0 polarity=0
[   50.207662] xen: acpi sci 9
[   50.216286] Console: colour VGA+ 80x25
[   50.237789] console [tty0] enabled
[   50.238195] console [hvc0] enabled
[   50.238390] installing Xen timer for CPU 0
[   50.238580] tsc: Detected 2500.080 MHz processor
[   50.238751] Calibrating delay loop (skipped), value calculated using timer frequency.. 500)
[   50.239096] pid_max: default: 32768 minimum: 501
[   50.239801] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   50.240915] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   50.241431] Mount-cache hash table entries: 256
[   50.241801] Initializing cgroup subsys cpuacct
[   50.241973] Initializing cgroup subsys freezer
[   50.242199] CPU: Physical Processor ID: 0
[   50.242368] CPU: Processor Core ID: 0
[   50.242536] mce: CPU supports 2 MCE banks
[   50.242766] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[   50.242766] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[   50.242766] tlb_flushall_shift: 5
[   50.243423] Freeing SMP alternatives: 32k freed
[    0.007054] ACPI: Core revision 20120913
[    0.009510] cpu 0 spinlock event irq 105
[    0.009693] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events.
[    0.010286] installing Xen timer for CPU 1
[    0.010463] cpu 1 spinlock event irq 112
[    0.010848] installing Xen timer for CPU 2
[    0.011023] cpu 2 spinlock event irq 119
[    0.011363] installing Xen timer for CPU 3
[    0.011537] cpu 3 spinlock event irq 126
[    0.011844] Brought up 4 CPUs
[    0.012277] devtmpfs: initialized
[    0.012713] xor: automatically using best checksumming function:
[    0.052559]    avx       : 22051.000 MB/sec
[    0.052734] Grant tables using version 2 layout.
[    0.052912] Grant table initialized
[    0.053118] NET: Registered protocol family 16
[    0.053816] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.054090] ACPI: bus type pci registered
[    0.055403] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base)
[    0.055684] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.086464] PCI: Using configuration type 1 for base access
[    0.086664] PCI: Dell System detected, enabling pci=bfsort.
[    0.094712] bio: create slab <bio-0> at 0
[    0.161842] raid6: sse2x1    7662 MB/s
[    0.230644] raid6: sse2x2    9538 MB/s
[    0.299461] raid6: sse2x4   10973 MB/s
[    0.299628] raid6: using algorithm sse2x4 (10973 MB/s)
[    0.299798] raid6: using ssse3x2 recovery algorithm
[    0.299998] ACPI: Added _OSI(Module Device)
[    0.300165] ACPI: Added _OSI(Processor Device)
[    0.300333] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302429] ACPI: Added _OSI(Processor Aggregator Device)
[    0.304560] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.305551] ACPI: Interpreter enabled
[    0.305722] ACPI: (supports S0 S5)
[    0.306015] ACPI: Using IOAPIC for interrupt routing
[    0.312565] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and reg
[    0.331230] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3d])
[    0.332414] PCI host bridge to bus 0000:00
[    0.332646] pci_bus 0000:00: root bus resource [bus 00-3d]
[    0.332813] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    0.332981] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    0.333150] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    0.333319] pci_bus 0000:00: root bus resource [io  0x0d00-0x1fff]
[    0.333486] pci_bus 0000:00: root bus resource [io  0xe000-0xffff]
[    0.333657] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.333831] pci_bus 0000:00: root bus resource [mem 0xd8000000-0xdfffffff]
[    0.334022] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff]
[    0.337651] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.338352] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.338605] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.339050] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.339313] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.339571] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.339830] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.343411] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.353509] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.359232] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.366425] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.368708] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.370402] pci 0000:00:1e.0: PCI bridge to [bus 0d] (subtractive decode)
[    0.371866]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.372334]  pci0000:00: ACPI _OSC control (0x1d) granted
[    0.384347] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 40-7e])
[    0.386540] PCI host bridge to bus 0000:40
[    0.386753] pci_bus 0000:40: root bus resource [bus 40-7e]
[    0.386951] pci_bus 0000:40: root bus resource [io  0x2000-0x3fff]
[    0.387149] pci_bus 0000:40: root bus resource [io  0x4000-0x5fff]
[    0.387348] pci_bus 0000:40: root bus resource [io  0x6000-0x7fff]
[    0.387546] pci_bus 0000:40: root bus resource [io  0x8000-0x9fff]
[    0.387744] pci_bus 0000:40: root bus resource [io  0xa000-0xbfff]
[    0.387955] pci_bus 0000:40: root bus resource [io  0xc000-0xdfff]
[    0.388155] pci_bus 0000:40: root bus resource [mem 0xd0000000-0xd7ffffff]
[    0.390449] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.390804] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.391159] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.391522] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.392451]  pci0000:40: Requesting ACPI _OSC control (0x1d)
[    0.392929]  pci0000:40: ACPI _OSC control (0x1d) granted
[    0.395163] ACPI: PCI Root Bridge [P0B1] (domain 0000 [bus 3f])
[    0.395515] PCI host bridge to bus 0000:3f
[    0.395713] pci_bus 0000:3f: root bus resource [bus 3f]
[    0.404007]  pci0000:3f: Requesting ACPI _OSC control (0x1d)
[    0.404484]  pci0000:3f: ACPI _OSC control (0x1d) granted
[    0.413321] ACPI: PCI Root Bridge [P1B1] (domain 0000 [bus 7f])
[    0.413667] PCI host bridge to bus 0000:7f
[    0.413862] pci_bus 0000:7f: root bus resource [bus 7f]
[    0.422347]  pci0000:7f: Requesting ACPI _OSC control (0x1d)
[    0.422809]  pci0000:7f: ACPI _OSC control (0x1d) granted
[    0.427766] ACPI: PCI Interrupt Link [LK00] (IRQs 3 4 5 6 7 11 14 *15)
[    0.428866] ACPI: PCI Interrupt Link [LK01] (IRQs 3 4 5 6 7 11 *14 15)
[    0.429941] ACPI: PCI Interrupt Link [LK02] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.431276] ACPI: PCI Interrupt Link [LK03] (IRQs 3 4 5 6 7 *11 14 15)
[    0.432386] ACPI: PCI Interrupt Link [LK04] (IRQs 3 4 *5 6 7 11 14 15)
[    0.433485] ACPI: PCI Interrupt Link [LK05] (IRQs 3 4 5 6 7 11 14 15) *0, disabled.
[    0.434824] ACPI: PCI Interrupt Link [LK06] (IRQs 3 4 5 *6 7 11 14 15)
[    0.435882] ACPI: PCI Interrupt Link [LK07] (IRQs 3 4 5 6 7 11 *14 15)
[    0.437121] xen/balloon: Initialising balloon driver.
[    0.437493] xen-balloon: Initialising balloon driver.
[    0.438249] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.438581] vgaarb: loaded
[    0.438766] vgaarb: bridge control possible 0000:0b:00.0
[    0.439309] SCSI subsystem initialized
[    0.439512] ACPI: bus type scsi registered
[    0.440271] ACPI: bus type usb registered
[    0.440639] usbcore: registered new interface driver usbfs
[    0.440919] usbcore: registered new interface driver hub
[    0.441261] usbcore: registered new device driver usb
[    0.441973] PCI: Using ACPI for IRQ routing
[    0.465197] Switching to clocksource xen
[    0.465669] pnp: PnP ACPI init
[    0.465880] ACPI: bus type pnp registered
[    0.469008] Already setup the GSI :3
[    0.470110] system 00:07: [io  0x0800-0x087f] has been reserved
[    0.470312] system 00:07: [io  0x0880-0x08ff] has been reserved
[    0.470521] system 00:07: [io  0x0900-0x091f] has been reserved
[    0.470718] system 00:07: [io  0x0920-0x0923] has been reserved
[    0.470914] system 00:07: [io  0x0924] has been reserved
[    0.471108] system 00:07: [io  0x0370-0x0377] has been reserved
[    0.471304] system 00:07: [io  0x0ca0-0x0ca7] has been reserved
[    0.471499] system 00:07: [io  0x0ca9-0x0cab] has been reserved
[    0.471695] system 00:07: [io  0x0cad-0x0caf] has been reserved
[    0.471889] system 00:07: [io  0x0cb0-0x0cbf] has been reserved
[    0.472398] system 00:08: [io  0x0ca8] has been reserved
[    0.472592] system 00:08: [io  0x0cac] has been reserved
[    0.473441] system 00:09: [mem 0xe0000000-0xe3efffff] has been reserved
[    0.475223] system 00:0b: [mem 0xe4000000-0xe7ffffff] has been reserved
[    0.475856] system 00:0d: [mem 0xe3f00000-0xe3ffffff] has been reserved
[    0.476308] system 00:0e: [mem 0xdf900000-0xdf901fff] has been reserved
[    0.476788] system 00:0f: [mem 0xd3000000-0xd3001fff] has been reserved
[    0.477672] pnp: PnP ACPI: found 18 devices
[    0.477866] ACPI: ACPI bus type pnp unregistered
[    0.498410] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    0.498625] pci 0000:01:00.1: address space collision: [mem 0xdc800000-0xdc83ffff pref] co]
[    0.498943] pci 0000:02:00.1: address space collision: [mem 0xdc000000-0xdc03ffff pref] co]
[    0.500490] pci 0000:02:00.1: BAR 6: assigned [mem 0xd9000000-0xd903ffff pref]
[    0.500793] pci 0000:00:01.0: PCI bridge to [bus 02]
[    0.500995] pci 0000:00:01.0:   bridge window [mem 0xdc000000-0xdc7fffff]
[    0.501202] pci 0000:00:01.0:   bridge window [mem 0xd9000000-0xd90fffff 64bit pref]
[    0.501560] pci 0000:01:00.1: BAR 6: assigned [mem 0xd9100000-0xd913ffff pref]
[    0.501866] pci 0000:00:01.1: PCI bridge to [bus 01]
[    0.502068] pci 0000:00:01.1:   bridge window [mem 0xdc800000-0xdcffffff]
[    0.502274] pci 0000:00:01.1:   bridge window [mem 0xd9100000-0xd91fffff 64bit pref]
[    0.502584] pci 0000:00:02.0: PCI bridge to [bus 04]
[    0.502798] pci 0000:00:02.2: PCI bridge to [bus 03]
[    0.502995] pci 0000:00:02.2:   bridge window [io  0xf000-0xffff]
[    0.503255] pci 0000:00:02.2:   bridge window [mem 0xdd000000-0xddffffff]
[    0.503465] pci 0000:00:03.0: PCI bridge to [bus 05]
[    0.503679] pci 0000:00:11.0: PCI bridge to [bus 06]
[    0.503897] pci 0000:00:1c.0: PCI bridge to [bus 07]
[    0.504112] pci 0000:0a:00.0: PCI bridge to [bus 0b]
[    0.504449] pci 0000:0a:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.504756] pci 0000:0a:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.505249] pci 0000:09:00.0: PCI bridge to [bus 0a-0b]
[    0.505606] pci 0000:09:00.0:   bridge window [mem 0xde000000-0xdeffffff]
[    0.505899] pci 0000:09:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.506411] pci 0000:09:01.0: PCI bridge to [bus 0c]
[    0.506744] pci 0000:09:01.0:   bridge window [mem 0xdf700000-0xdf7fffff]
[    0.507286] pci 0000:08:00.0: PCI bridge to [bus 09-0c]
[    0.507604] pci 0000:08:00.0:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.507889] pci 0000:08:00.0:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.508423] pci 0000:00:1c.7: PCI bridge to [bus 08-0c]
[    0.508625] pci 0000:00:1c.7:   bridge window [mem 0xde000000-0xdf7fffff]
[    0.508827] pci 0000:00:1c.7:   bridge window [mem 0xd8000000-0xd8ffffff 64bit pref]
[    0.509162] pci 0000:00:1e.0: PCI bridge to [bus 0d]
[    0.509385] pci 0000:40:01.0: PCI bridge to [bus 41]
[    0.509623] pci 0000:40:02.0: PCI bridge to [bus 42]
[    0.509844] pci 0000:40:03.0: PCI bridge to [bus 43]
[    0.510064] pci 0000:40:03.2: PCI bridge to [bus 44]
[    0.510366] Already setup the GSI :53
[    0.510566] Already setup the GSI :53
[    0.510780] Already setup the GSI :53
[    0.510978] Already setup the GSI :53
[    0.511773] Already setup the GSI :85
[    0.511974] Already setup the GSI :85
[    0.512173] Already setup the GSI :85
[    0.512556] NET: Registered protocol family 2
[    0.515017] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.517734] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.518170] TCP: Hash tables configured (established 524288 bind 65536)
[    0.518421] TCP: reno registered
[    0.518636] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ [    2.117929] i8042: No controller found
[    3.599100] usb 1-1.6.4: new high-speed USB device number 6 using ehci_hcd
[    3.697696] usb 1-1.6.4: New USB device found, idVendor=0624, idProduct=0251
[    3.697917] usb 1-1.6.4: New USB device strings: Mfr=4, Product=5, SerialNumber=6
[    3.698233] usb 1-1.6.4: Product: Mass Storage Function
[    3.698428] usb 1-1.6.4: Manufacturer: Avocent
[    3.698629] usb 1-1.6.4: SerialNumber: 20111109-1
[    3.699825] scsi1 : usb-storage 1-1.6.4:1.0
   OpenRC 0.11.8 is starting up Gentoo Linux (x86_64) [XEN0]

 * Mounting /proc ...
 [ ok ]
 * Mounting /run ...
 * /run/openrc: creating directory
 * /run/lock: creating directory
 * Mounting xenfs ...
 [ ok ]
 * Mounting /dev ...
 [ ok ]
 * Mounting /dev/pts ...
 [ ok ]
 * Mounting /dev/shm ...
 [ ok ]
 * Mounting /sys ...
 [ ok ]
 * Mounting debug filesystem ...
 [ ok ]
 * Mounting cgroup filesystem ...
 [ ok ]
 * Starting udev ...
 [ ok ]
 * Populating /dev with existing devices through uevents ...
 [ ok ]
 * Waiting for uevents to be processed ...
 [ ok ]
 * Setting system clock using the hardware clock [UTC] ...
 [ ok ]
 * Autoloaded 0 module(s)
 * Setting up the Logical Volume Manager ...
 [ ok ]
 * Checking local filesystems  ...
/sbin/fsck.xfs: XFS file system.
/sbin/fsck.xfs: XFS file system.
/sbin/fsck.xfs: XFS file system.
 [ ok ]
 * Remounting filesystems ...
 [ ok ]
 * Updating /etc/mtab ...
 [ ok ]
 * Activating swap devices ...
 [ ok ]
 * Mounting local filesystems ...
 [ ok ]
 * Configuring kernel parameters ...
 [ ok ]
 * Creating user login records ...
 [ ok ]
 * Cleaning /var/run ...
 [ ok ]
 * Wiping /tmp directory ...
 [ ok ]
 * Setting terminal encoding [UTF-8] ...
 [ ok ]
 * Setting console font [default8x16] ...
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Starting firewall (/root/bin/firewall/firewall.sh) ...
WARNING: The state match is obsolete. Use conntrack instead.
WARNING: The state match is obsolete. Use conntrack instead.
 [ ok ]
 * Setting hostname to rajvir3 ...
 [ ok ]
 * Setting keyboard mode [UTF-8] ...
 [ ok ]
 * Loading key mappings [us] ...
 [ ok ]
 * Bringing up interface lo
 *   127.0.0.1/8 ...
 [ ok ]
 *   Adding routes
 *     127.0.0.0/8 via 127.0.0.1 ...
 [ ok ]
 * Bringing up interface bond0
 *   Adding slaves to bond0 ...
 *     eth0 eth1
 [ ok ]
 [ ok ]
 * Mounting misc binary format filesystem ...
 [ ok ]
 * Loading custom binary format handlers ...
 [ ok ]
 * Activating additional swap space ...
 [ ok ]
 * setting up tmpfiles.d entries ...
 [ ok ]
 * Initializing random number generator ...
 [ ok ]
INIT: Entering runlevel: 3
 * Bringing up interface br0
 *   Creating bridge br0 ...
 *   Adding ports to br0
 *     bond0 ...
 [ ok ]
 *   192.168.241.125/24 ...
 [ ok ]
 *   Adding routes
 *     default via 192.168.241.1 ...
 [ ok ]
 * Starting syslog-ng ...
 [ ok ]
 * Starting bacula file daemon ...
 [ ok ]
 * Starting fail2ban ...
 [ ok ]
 * Starting munin-node ...
 [ ok ]
 * Mounting network filesystems ...
 [ ok ]
 * Starting nrpe ...
 [ ok ]
 * Setting clock via the NTP client 'ntpdate' ...
 [ ok ]
 * Starting ntpd ...
 [ ok ]
 * Calling sar - 30 sec. interval ...
 [ ok ]
 * Starting xenstored daemon ...
 * Setting domain0 name record
 [ ok ]
 * Starting xenconsoled daemon ...
 [ ok ]
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Starting Xen control daemon ...
^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A [ ok ]
 * Starting sshd ...
 [ ok ]
 * Starting vixie-cron ...
 [ ok ]
 * Starting local

--------------000609010708080401060703
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000609010708080401060703--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:20:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOCN-00049b-7b; Tue, 26 Feb 2013 17:20:15 +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 1UAOCM-00049Q-7b
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:20:14 +0000
Received: from [85.158.139.83:33328] by server-5.bemta-5.messagelabs.com id
	8B/29-02762-DCEEC215; Tue, 26 Feb 2013 17:20:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361899212!28383943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18951 invoked from network); 26 Feb 2013 17:20:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 17:20:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAOCH-000PXl-Pd; Tue, 26 Feb 2013 17:20:09 +0000
Date: Tue, 26 Feb 2013 17:20:09 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226172009.GF93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.60663.630676.707241@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > Speaking as its author, I know what the objective is: to unpack what
> > 'make install' would do, and remove it again afterwards.  The fact that
> > it uses a .deb package for that is unfortunate, because it leads people
> > to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
> > manifest for uninstalling.
> 
> I think we should fix this problem by improving the documentation.
> 
> From a technical point of view, a .deb is definitely the right thing.
> 
> And I do think that there is a plausible argument that the config
> files ought not to be just blatted over the top of your system.  (If
> "make install" does that then there's the same argument there - I
> don't think "make install" should trash existing config.)

AFAIK 'make install' does; certainly some room for improvement in that
are.  In 'make deb' treating config files as normal data is deliberate.
I don't want remnants of old tests contaminating my new install - that
was the whole point.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:20:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOCN-00049b-7b; Tue, 26 Feb 2013 17:20:15 +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 1UAOCM-00049Q-7b
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:20:14 +0000
Received: from [85.158.139.83:33328] by server-5.bemta-5.messagelabs.com id
	8B/29-02762-DCEEC215; Tue, 26 Feb 2013 17:20:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1361899212!28383943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18951 invoked from network); 26 Feb 2013 17:20:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 17:20:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAOCH-000PXl-Pd; Tue, 26 Feb 2013 17:20:09 +0000
Date: Tue, 26 Feb 2013 17:20:09 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226172009.GF93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.60663.630676.707241@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > Speaking as its author, I know what the objective is: to unpack what
> > 'make install' would do, and remove it again afterwards.  The fact that
> > it uses a .deb package for that is unfortunate, because it leads people
> > to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
> > manifest for uninstalling.
> 
> I think we should fix this problem by improving the documentation.
> 
> From a technical point of view, a .deb is definitely the right thing.
> 
> And I do think that there is a plausible argument that the config
> files ought not to be just blatted over the top of your system.  (If
> "make install" does that then there's the same argument there - I
> don't think "make install" should trash existing config.)

AFAIK 'make install' does; certainly some room for improvement in that
are.  In 'make deb' treating config files as normal data is deliberate.
I don't want remnants of old tests contaminating my new install - that
was the whole point.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:21:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAODo-0004LV-NG; Tue, 26 Feb 2013 17:21: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 1UAODn-0004LE-0v
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:21:43 +0000
Received: from [85.158.139.83:11139] by server-1.bemta-5.messagelabs.com id
	7F/6E-14063-62FEC215; Tue, 26 Feb 2013 17:21:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361899286!29062300!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7700 invoked from network); 26 Feb 2013 17:21:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1913373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:21: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.297.1; Tue, 26 Feb 2013 17:21:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAODV-0008Uz-TT; Tue, 26 Feb 2013 17:21:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAODV-0001s7-Mo;
	Tue, 26 Feb 2013 17:21:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.61205.534627.629612@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:21:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1359984925.7743.35.camel@zakaz.uk.xensource.com>
References: <201302020848.r128mpBb021273@wind.enjellic.com>
	<1359984925.7743.35.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] Migration issues with 4.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

Ian Campbell writes ("Re: [Xen-devel] Migration issues with 4.1."):
> On Sat, 2013-02-02 at 08:48 +0000, Dr. Greg Wettstein wrote:
> > migration receiver stream contained unexpected data instead of ready message
> 
> Can you patch (lib)xl to print this unexpected data?

This is a good idea, or run it under strace.

> > (command run was: exec ./xen-migrate rainbow xl migrate-receive )
> 
> What happens if you run this by hand? I wonder if it is asking for a
> password or printing a message about accepting host keys or something
> and confusing the xl migration protocol.

It's slightly at least subtle, because this message ...

> > migration target: Ready to receive domain.

... is printed by the receiving copy of xl to its stderr.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:21:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAODo-0004LV-NG; Tue, 26 Feb 2013 17:21: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 1UAODn-0004LE-0v
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:21:43 +0000
Received: from [85.158.139.83:11139] by server-1.bemta-5.messagelabs.com id
	7F/6E-14063-62FEC215; Tue, 26 Feb 2013 17:21:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1361899286!29062300!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7700 invoked from network); 26 Feb 2013 17:21:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1913373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:21: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.297.1; Tue, 26 Feb 2013 17:21:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAODV-0008Uz-TT; Tue, 26 Feb 2013 17:21:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAODV-0001s7-Mo;
	Tue, 26 Feb 2013 17:21:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.61205.534627.629612@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:21:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1359984925.7743.35.camel@zakaz.uk.xensource.com>
References: <201302020848.r128mpBb021273@wind.enjellic.com>
	<1359984925.7743.35.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] Migration issues with 4.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

Ian Campbell writes ("Re: [Xen-devel] Migration issues with 4.1."):
> On Sat, 2013-02-02 at 08:48 +0000, Dr. Greg Wettstein wrote:
> > migration receiver stream contained unexpected data instead of ready message
> 
> Can you patch (lib)xl to print this unexpected data?

This is a good idea, or run it under strace.

> > (command run was: exec ./xen-migrate rainbow xl migrate-receive )
> 
> What happens if you run this by hand? I wonder if it is asking for a
> password or printing a message about accepting host keys or something
> and confusing the xl migration protocol.

It's slightly at least subtle, because this message ...

> > migration target: Ready to receive domain.

... is printed by the receiving copy of xl to its stderr.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:22:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOEJ-0004U7-5a; Tue, 26 Feb 2013 17:22: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 1UAOEH-0004Sl-Ii
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:22:13 +0000
Received: from [85.158.143.99:45397] by server-3.bemta-4.messagelabs.com id
	B3/59-02186-44FEC215; Tue, 26 Feb 2013 17:22:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361899328!22516361!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5978 invoked from network); 26 Feb 2013 17:22:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:22:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1913389"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:22: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.297.1; Tue, 26 Feb 2013 17:22:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOE7-0008V5-Sz; Tue, 26 Feb 2013 17:22:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOE7-0001sG-PB;
	Tue, 26 Feb 2013 17:22:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.61241.624841.117585@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:22:01 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226172009.GF93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > And I do think that there is a plausible argument that the config
> > files ought not to be just blatted over the top of your system.  (If
> > "make install" does that then there's the same argument there - I
> > don't think "make install" should trash existing config.)
> 
> AFAIK 'make install' does; certainly some room for improvement in that
> are.  In 'make deb' treating config files as normal data is deliberate.
> I don't want remnants of old tests contaminating my new install - that
> was the whole point.

If you say dpkg --purge they will be entirely removed, even if marked
as conffiles.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:22:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOEJ-0004U7-5a; Tue, 26 Feb 2013 17:22: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 1UAOEH-0004Sl-Ii
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:22:13 +0000
Received: from [85.158.143.99:45397] by server-3.bemta-4.messagelabs.com id
	B3/59-02186-44FEC215; Tue, 26 Feb 2013 17:22:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361899328!22516361!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5978 invoked from network); 26 Feb 2013 17:22:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:22:11 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1913389"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:22: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.297.1; Tue, 26 Feb 2013 17:22:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOE7-0008V5-Sz; Tue, 26 Feb 2013 17:22:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOE7-0001sG-PB;
	Tue, 26 Feb 2013 17:22:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.61241.624841.117585@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:22:01 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226172009.GF93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > And I do think that there is a plausible argument that the config
> > files ought not to be just blatted over the top of your system.  (If
> > "make install" does that then there's the same argument there - I
> > don't think "make install" should trash existing config.)
> 
> AFAIK 'make install' does; certainly some room for improvement in that
> are.  In 'make deb' treating config files as normal data is deliberate.
> I don't want remnants of old tests contaminating my new install - that
> was the whole point.

If you say dpkg --purge they will be entirely removed, even if marked
as conffiles.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:25:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:25: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 1UAOHf-0004pj-Sr; Tue, 26 Feb 2013 17:25: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 1UAOHf-0004pY-4O
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:25:43 +0000
Received: from [85.158.143.99:34065] by server-3.bemta-4.messagelabs.com id
	2B/FB-02186-610FC215; Tue, 26 Feb 2013 17:25:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361899527!21792612!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29681 invoked from network); 26 Feb 2013 17:25:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 17:25:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAOHN-000PZo-KB; Tue, 26 Feb 2013 17:25:25 +0000
Date: Tue, 26 Feb 2013 17:25:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226172525.GG93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.61241.624841.117585@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > And I do think that there is a plausible argument that the config
> > > files ought not to be just blatted over the top of your system.  (If
> > > "make install" does that then there's the same argument there - I
> > > don't think "make install" should trash existing config.)
> > 
> > AFAIK 'make install' does; certainly some room for improvement in that
> > are.  In 'make deb' treating config files as normal data is deliberate.
> > I don't want remnants of old tests contaminating my new install - that
> > was the whole point.
> 
> If you say dpkg --purge they will be entirely removed, even if marked
> as conffiles.

Yes, but that assumes that the default behaviour shouuld be to leave
them around, which I dispute.  Again, using .deb leads to thinking about
how a real package would behave. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:25:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:25: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 1UAOHf-0004pj-Sr; Tue, 26 Feb 2013 17:25: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 1UAOHf-0004pY-4O
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:25:43 +0000
Received: from [85.158.143.99:34065] by server-3.bemta-4.messagelabs.com id
	2B/FB-02186-610FC215; Tue, 26 Feb 2013 17:25:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1361899527!21792612!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29681 invoked from network); 26 Feb 2013 17:25:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 17:25:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAOHN-000PZo-KB; Tue, 26 Feb 2013 17:25:25 +0000
Date: Tue, 26 Feb 2013 17:25:25 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226172525.GG93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.61241.624841.117585@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > And I do think that there is a plausible argument that the config
> > > files ought not to be just blatted over the top of your system.  (If
> > > "make install" does that then there's the same argument there - I
> > > don't think "make install" should trash existing config.)
> > 
> > AFAIK 'make install' does; certainly some room for improvement in that
> > are.  In 'make deb' treating config files as normal data is deliberate.
> > I don't want remnants of old tests contaminating my new install - that
> > was the whole point.
> 
> If you say dpkg --purge they will be entirely removed, even if marked
> as conffiles.

Yes, but that assumes that the default behaviour shouuld be to leave
them around, which I dispute.  Again, using .deb leads to thinking about
how a real package would behave. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:33:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:33: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 1UAOPC-00059D-V8; Tue, 26 Feb 2013 17:33:30 +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 1UAOPB-000596-MW
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:33:29 +0000
Received: from [85.158.143.99:15487] by server-3.bemta-4.messagelabs.com id
	67/02-02186-9E1FC215; Tue, 26 Feb 2013 17:33:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361900007!22518119!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31938 invoked from network); 26 Feb 2013 17:33: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;
	26 Feb 2013 17:33:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9282643"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:33:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:33:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAOP3-0000Xk-D1;
	Tue, 26 Feb 2013 17:33:21 +0000
Date: Tue, 26 Feb 2013 17:33:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226172525.GG93966@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Tim Deegan wrote:
> At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > And I do think that there is a plausible argument that the config
> > > > files ought not to be just blatted over the top of your system.  (If
> > > > "make install" does that then there's the same argument there - I
> > > > don't think "make install" should trash existing config.)
> > > 
> > > AFAIK 'make install' does; certainly some room for improvement in that
> > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > I don't want remnants of old tests contaminating my new install - that
> > > was the whole point.
> > 
> > If you say dpkg --purge they will be entirely removed, even if marked
> > as conffiles.
> 
> Yes, but that assumes that the default behaviour shouuld be to leave
> them around, which I dispute.  Again, using .deb leads to thinking about
> how a real package would behave. :)

Maybe we should produce a tgz instead (plain or Slackware style).
I wouldn't want to create wrong expectations: it is better to build no
packages than building "broken" packages. (Of course I still think the
best choice would be to produce good packages.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:33:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:33: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 1UAOPC-00059D-V8; Tue, 26 Feb 2013 17:33:30 +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 1UAOPB-000596-MW
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:33:29 +0000
Received: from [85.158.143.99:15487] by server-3.bemta-4.messagelabs.com id
	67/02-02186-9E1FC215; Tue, 26 Feb 2013 17:33:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1361900007!22518119!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31938 invoked from network); 26 Feb 2013 17:33: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;
	26 Feb 2013 17:33:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9282643"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:33:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:33:21 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAOP3-0000Xk-D1;
	Tue, 26 Feb 2013 17:33:21 +0000
Date: Tue, 26 Feb 2013 17:33:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226172525.GG93966@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Tim Deegan wrote:
> At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > And I do think that there is a plausible argument that the config
> > > > files ought not to be just blatted over the top of your system.  (If
> > > > "make install" does that then there's the same argument there - I
> > > > don't think "make install" should trash existing config.)
> > > 
> > > AFAIK 'make install' does; certainly some room for improvement in that
> > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > I don't want remnants of old tests contaminating my new install - that
> > > was the whole point.
> > 
> > If you say dpkg --purge they will be entirely removed, even if marked
> > as conffiles.
> 
> Yes, but that assumes that the default behaviour shouuld be to leave
> them around, which I dispute.  Again, using .deb leads to thinking about
> how a real package would behave. :)

Maybe we should produce a tgz instead (plain or Slackware style).
I wouldn't want to create wrong expectations: it is better to build no
packages than building "broken" packages. (Of course I still think the
best choice would be to produce good packages.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:38:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOTR-0005IN-LF; Tue, 26 Feb 2013 17:37:53 +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 1UAOTP-0005IH-T1
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:37:52 +0000
Received: from [85.158.137.99:45690] by server-10.bemta-3.messagelabs.com id
	59/B3-10609-AE2FC215; Tue, 26 Feb 2013 17:37:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361900266!17366795!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31314 invoked from network); 26 Feb 2013 17:37:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:37:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17: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.297.1; Tue, 26 Feb 2013 17:37:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOTJ-0000Be-Sm; Tue, 26 Feb 2013 17:37:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOTJ-0002VH-Nu;
	Tue, 26 Feb 2013 17:37:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62185.634588.412741@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:37:45 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
References: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
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] tools/xc: update tty detection
	in	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xc: update tty detection in stdiostream_progress"):
> tools/xc: update tty detection in stdiostream_progress
> 
> As suggested by IanJ:
> Check isatty only once to preserve the errno of ->progress users, and to
> reduce the noice in strace output.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Thanks.  But how did you test this ?  It doesn't compile.

Also I think it would be better to name the struct member something
other than "isatty" since that's also the function name.  In theory it
should be OK but in practice I worry about compiler warnings etc.

How about "tty" ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:38:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOTR-0005IN-LF; Tue, 26 Feb 2013 17:37:53 +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 1UAOTP-0005IH-T1
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:37:52 +0000
Received: from [85.158.137.99:45690] by server-10.bemta-3.messagelabs.com id
	59/B3-10609-AE2FC215; Tue, 26 Feb 2013 17:37:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361900266!17366795!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31314 invoked from network); 26 Feb 2013 17:37:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:37:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17: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.297.1; Tue, 26 Feb 2013 17:37:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOTJ-0000Be-Sm; Tue, 26 Feb 2013 17:37:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOTJ-0002VH-Nu;
	Tue, 26 Feb 2013 17:37:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62185.634588.412741@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:37:45 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
References: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
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] tools/xc: update tty detection
	in	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xc: update tty detection in stdiostream_progress"):
> tools/xc: update tty detection in stdiostream_progress
> 
> As suggested by IanJ:
> Check isatty only once to preserve the errno of ->progress users, and to
> reduce the noice in strace output.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Thanks.  But how did you test this ?  It doesn't compile.

Also I think it would be better to name the struct member something
other than "isatty" since that's also the function name.  In theory it
should be OK but in practice I worry about compiler warnings etc.

How about "tty" ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:38:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:38: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 1UAOTV-0005Ij-2M; Tue, 26 Feb 2013 17:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UAOTS-0005IV-Vw
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:37:55 +0000
Received: from [85.158.139.83:56673] by server-8.bemta-5.messagelabs.com id
	BE/83-05790-2F2FC215; Tue, 26 Feb 2013 17:37:54 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361900272!29088659!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3104 invoked from network); 26 Feb 2013 17:37:52 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:37:52 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>) id 1UAOTP-0000PN-Lu
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 18:37:51 +0100
Message-ID: <512CF2EA.9080308@mfiala.net>
Date: Tue, 26 Feb 2013 18:37:46 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
In-Reply-To: <512CF62C02000078000C12F1@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Content-Type: multipart/mixed; boundary="------------080007080505040303060707"
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------080007080505040303060707
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/26/2013 05:51 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 17:40, Michal Fiala <fiala@mfiala.net> wrote:
>> On 02/26/2013 05:33 PM, Jan Beulich wrote:
>>>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
>>>
>>> Please don't top post.
>>>
>>>> The kernel command line from grub.conf
>>>>
>>>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
>>>> console=com2,vga com2=115200,8n1
>>>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
>>>>
>>>> I have not modified reboot type.
>>>
>>> And did you check your full boot log for an info-level message like
>>>
>>> "%s series board detected. Selecting %s-method for reboot.\n"
>>
>> I have only checked normal boot log, see attachment in my first mail.
>> How can I enable info-level message?
> 
> Looks like this has info level messages enabled, and I can't see any
> such message there. So I guess you'll have to add a few printk()-s
> to arch/x86/kernel/reboot.c:native_machine_emergency_restart().
> 
> Jan

What informations are you interested in? I have attached reboot.c from
my kernel. Could you please patch it and I will deploy it.

Michal

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

--------------080007080505040303060707
Content-Type: text/x-csrc;
 name="reboot.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="reboot.c"

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

#include <linux/module.h>
#include <linux/reboot.h>
#include <linux/init.h>
#include <linux/pm.h>
#include <linux/efi.h>
#include <linux/dmi.h>
#include <linux/sched.h>
#include <linux/tboot.h>
#include <linux/delay.h>
#include <acpi/reboot.h>
#include <asm/io.h>
#include <asm/apic.h>
#include <asm/desc.h>
#include <asm/hpet.h>
#include <asm/pgtable.h>
#include <asm/proto.h>
#include <asm/reboot_fixups.h>
#include <asm/reboot.h>
#include <asm/pci_x86.h>
#include <asm/virtext.h>
#include <asm/cpu.h>
#include <asm/nmi.h>
#include <asm/smp.h>

#include <linux/ctype.h>
#include <linux/mc146818rtc.h>
#include <asm/realmode.h>
#include <asm/x86_init.h>

/*
 * Power off function, if any
 */
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);

static const struct desc_ptr no_idt = {};
static unsigned short reboot_mode;
enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;

/*
 * This variable is used privately to keep track of whether or not
 * reboot_type is still set to its default value (i.e., reboot= hasn't
 * been set on the command line).  This is needed so that we can
 * suppress DMI scanning for reboot quirks.  Without it, it's
 * impossible to override a faulty reboot quirk without recompiling.
 */
static int reboot_default = 1;

#ifdef CONFIG_SMP
static int reboot_cpu = -1;
#endif

/*
 * This is set if we need to go through the 'emergency' path.
 * When machine_emergency_restart() is called, we may be on
 * an inconsistent state and won't be able to do a clean cleanup
 */
static int reboot_emergency;

/* This is set by the PCI code if either type 1 or type 2 PCI is detected */
bool port_cf9_safe = false;

/*
 * reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci]
 * warm   Don't set the cold reboot flag
 * cold   Set the cold reboot flag
 * bios   Reboot by jumping through the BIOS
 * smp    Reboot by executing reset on BSP or other CPU
 * triple Force a triple fault (init)
 * kbd    Use the keyboard controller. cold reset (default)
 * acpi   Use the RESET_REG in the FADT
 * efi    Use efi reset_system runtime service
 * pci    Use the so-called "PCI reset register", CF9
 * force  Avoid anything that could hang.
 */
static int __init reboot_setup(char *str)
{
	for (;;) {
		/*
		 * Having anything passed on the command line via
		 * reboot= will cause us to disable DMI checking
		 * below.
		 */
		reboot_default = 0;

		switch (*str) {
		case 'w':
			reboot_mode = 0x1234;
			break;

		case 'c':
			reboot_mode = 0;
			break;

#ifdef CONFIG_SMP
		case 's':
			if (isdigit(*(str+1))) {
				reboot_cpu = (int) (*(str+1) - '0');
				if (isdigit(*(str+2)))
					reboot_cpu = reboot_cpu*10 + (int)(*(str+2) - '0');
			}
			/*
			 * We will leave sorting out the final value
			 * when we are ready to reboot, since we might not
			 * have detected BSP APIC ID or smp_num_cpu
			 */
			break;
#endif /* CONFIG_SMP */

		case 'b':
		case 'a':
		case 'k':
		case 't':
		case 'e':
		case 'p':
			reboot_type = *str;
			break;

		case 'f':
			reboot_force = 1;
			break;
		}

		str = strchr(str, ',');
		if (str)
			str++;
		else
			break;
	}
	return 1;
}

__setup("reboot=", reboot_setup);


/*
 * Reboot options and system auto-detection code provided by
 * Dell Inc. so their systems "just work". :-)
 */

/*
 * Some machines require the "reboot=b" or "reboot=k"  commandline options,
 * this quirk makes that automatic.
 */
static int __init set_bios_reboot(const struct dmi_system_id *d)
{
	if (reboot_type != BOOT_BIOS) {
		reboot_type = BOOT_BIOS;
		pr_info("%s series board detected. Selecting %s-method for reboots.\n",
			"BIOS", d->ident);
	}
	return 0;
}

void __noreturn machine_real_restart(unsigned int type)
{

#if defined(CONFIG_X86_32) && (defined(CONFIG_PAX_KERNEXEC) || defined(CONFIG_PAX_MEMORY_UDEREF))
	struct desc_struct *gdt;
#endif

	local_irq_disable();

	/*
	 * Write zero to CMOS register number 0x0f, which the BIOS POST
	 * routine will recognize as telling it to do a proper reboot.  (Well
	 * that's what this book in front of me says -- it may only apply to
	 * the Phoenix BIOS though, it's not clear).  At the same time,
	 * disable NMIs by setting the top bit in the CMOS address register,
	 * as we're about to do peculiar things to the CPU.  I'm not sure if
	 * `outb_p' is needed instead of just `outb'.  Use it to be on the
	 * safe side.  (Yes, CMOS_WRITE does outb_p's. -  Paul G.)
	 */
	spin_lock(&rtc_lock);
	CMOS_WRITE(0x00, 0x8f);
	spin_unlock(&rtc_lock);

	/*
	 * Switch back to the initial page table.
	 */
#ifdef CONFIG_X86_32
	load_cr3(initial_page_table);
#else
	write_cr3(real_mode_header->trampoline_pgd);
#endif

	/* Jump to the identity-mapped low memory code */
#ifdef CONFIG_X86_32

#if defined(CONFIG_PAX_KERNEXEC) || defined(CONFIG_PAX_MEMORY_UDEREF)
	gdt = get_cpu_gdt_table(smp_processor_id());
	pax_open_kernel();
#ifdef CONFIG_PAX_MEMORY_UDEREF
	gdt[GDT_ENTRY_KERNEL_DS].type = 3;
	gdt[GDT_ENTRY_KERNEL_DS].limit = 0xf;
	loadsegment(ds, __KERNEL_DS);
	loadsegment(es, __KERNEL_DS);
	loadsegment(ss, __KERNEL_DS);
#endif
#ifdef CONFIG_PAX_KERNEXEC
	gdt[GDT_ENTRY_KERNEL_CS].base0 = 0;
	gdt[GDT_ENTRY_KERNEL_CS].base1 = 0;
	gdt[GDT_ENTRY_KERNEL_CS].base2 = 0;
	gdt[GDT_ENTRY_KERNEL_CS].limit0 = 0xffff;
	gdt[GDT_ENTRY_KERNEL_CS].limit = 0xf;
	gdt[GDT_ENTRY_KERNEL_CS].g = 1;
#endif
	pax_close_kernel();
#endif

	asm volatile("ljmpl *%0" : :
		     "rm" (real_mode_header->machine_real_restart_asm),
		     "a" (type));
#else
	asm volatile("ljmpl *%0" : :
		     "m" (real_mode_header->machine_real_restart_asm),
		     "D" (type));
#endif
	unreachable();
}
#ifdef CONFIG_APM_MODULE
EXPORT_SYMBOL(machine_real_restart);
#endif

/*
 * Some Apple MacBook and MacBookPro's needs reboot=p to be able to reboot
 */
static int __init set_pci_reboot(const struct dmi_system_id *d)
{
	if (reboot_type != BOOT_CF9) {
		reboot_type = BOOT_CF9;
		pr_info("%s series board detected. Selecting %s-method for reboots.\n",
			"PCI", d->ident);
	}
	return 0;
}

static int __init set_kbd_reboot(const struct dmi_system_id *d)
{
	if (reboot_type != BOOT_KBD) {
		reboot_type = BOOT_KBD;
		pr_info("%s series board detected. Selecting %s-method for reboot.\n",
			"KBD", d->ident);
	}
	return 0;
}

/*
 * This is a single dmi_table handling all reboot quirks.
 */
static struct dmi_system_id __initdata reboot_dmi_table[] = {
	{	/* Handle problems with rebooting on Dell E520's */
		.callback = set_bios_reboot,
		.ident = "Dell E520",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM061"),
		},
	},
	{	/* Handle problems with rebooting on Dell 1300's */
		.callback = set_bios_reboot,
		.ident = "Dell PowerEdge 1300",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 1300/"),
		},
	},
	{	/* Handle problems with rebooting on Dell 300's */
		.callback = set_bios_reboot,
		.ident = "Dell PowerEdge 300",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 300/"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 745's SFF */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 745",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 745's DFF */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 745",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
			DMI_MATCH(DMI_BOARD_NAME, "0MM599"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 745 with 0KW626 */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 745",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
			DMI_MATCH(DMI_BOARD_NAME, "0KW626"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 330 with 0KP561 */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 330",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 330"),
			DMI_MATCH(DMI_BOARD_NAME, "0KP561"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 360 with 0T656F */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 360",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 360"),
			DMI_MATCH(DMI_BOARD_NAME, "0T656F"),
		},
	},
	{	/* Handle problems with rebooting on Dell OptiPlex 760 with 0G919G */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 760",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 760"),
			DMI_MATCH(DMI_BOARD_NAME, "0G919G"),
		},
	},
	{	/* Handle problems with rebooting on Dell 2400's */
		.callback = set_bios_reboot,
		.ident = "Dell PowerEdge 2400",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 2400"),
		},
	},
	{	/* Handle problems with rebooting on Dell T5400's */
		.callback = set_bios_reboot,
		.ident = "Dell Precision T5400",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation T5400"),
		},
	},
	{	/* Handle problems with rebooting on Dell T7400's */
		.callback = set_bios_reboot,
		.ident = "Dell Precision T7400",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation T7400"),
		},
	},
	{	/* Handle problems with rebooting on HP laptops */
		.callback = set_bios_reboot,
		.ident = "HP Compaq Laptop",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
			DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"),
		},
	},
	{	/* Handle problems with rebooting on Dell XPS710 */
		.callback = set_bios_reboot,
		.ident = "Dell XPS710",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell XPS710"),
		},
	},
	{	/* Handle problems with rebooting on Dell DXP061 */
		.callback = set_bios_reboot,
		.ident = "Dell DXP061",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell DXP061"),
		},
	},
	{	/* Handle problems with rebooting on Sony VGN-Z540N */
		.callback = set_bios_reboot,
		.ident = "Sony VGN-Z540N",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "VGN-Z540N"),
		},
	},
	{	/* Handle problems with rebooting on ASUS P4S800 */
		.callback = set_bios_reboot,
		.ident = "ASUS P4S800",
		.matches = {
			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
			DMI_MATCH(DMI_BOARD_NAME, "P4S800"),
		},
	},

	{	/* Handle reboot issue on Acer Aspire one */
		.callback = set_kbd_reboot,
		.ident = "Acer Aspire One A110",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
			DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
		},
	},
	{	/* Handle problems with rebooting on Apple MacBook5 */
		.callback = set_pci_reboot,
		.ident = "Apple MacBook5",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "MacBook5"),
		},
	},
	{	/* Handle problems with rebooting on Apple MacBookPro5 */
		.callback = set_pci_reboot,
		.ident = "Apple MacBookPro5",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro5"),
		},
	},
	{	/* Handle problems with rebooting on Apple Macmini3,1 */
		.callback = set_pci_reboot,
		.ident = "Apple Macmini3,1",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Macmini3,1"),
		},
	},
	{	/* Handle problems with rebooting on the iMac9,1. */
		.callback = set_pci_reboot,
		.ident = "Apple iMac9,1",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "iMac9,1"),
		},
	},
	{	/* Handle problems with rebooting on the Latitude E6320. */
		.callback = set_pci_reboot,
		.ident = "Dell Latitude E6320",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6320"),
		},
	},
	{	/* Handle problems with rebooting on the Latitude E5420. */
		.callback = set_pci_reboot,
		.ident = "Dell Latitude E5420",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"),
		},
	},
	{	/* Handle problems with rebooting on the Latitude E6420. */
		.callback = set_pci_reboot,
		.ident = "Dell Latitude E6420",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6420"),
		},
	},
	{	/* Handle problems with rebooting on the OptiPlex 990. */
		.callback = set_pci_reboot,
		.ident = "Dell OptiPlex 990",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 990"),
		},
	},
	{	/* Handle problems with rebooting on the Precision M6600. */
		.callback = set_pci_reboot,
		.ident = "Dell OptiPlex 990",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
		},
	},
	{ }
};

static int __init reboot_init(void)
{
	/*
	 * Only do the DMI check if reboot_type hasn't been overridden
	 * on the command line
	 */
	if (reboot_default)
		dmi_check_system(reboot_dmi_table);
	return 0;
}
core_initcall(reboot_init);

static inline void kb_wait(void)
{
	int i;

	for (i = 0; i < 0x10000; i++) {
		if ((inb(0x64) & 0x02) == 0)
			break;
		udelay(2);
	}
}

static void vmxoff_nmi(int cpu, struct pt_regs *regs)
{
	cpu_emergency_vmxoff();
}

/* Use NMIs as IPIs to tell all CPUs to disable virtualization */
static void emergency_vmx_disable_all(void)
{
	/* Just make sure we won't change CPUs while doing this */
	local_irq_disable();

	/*
	 * We need to disable VMX on all CPUs before rebooting, otherwise
	 * we risk hanging up the machine, because the CPU ignore INIT
	 * signals when VMX is enabled.
	 *
	 * We can't take any locks and we may be on an inconsistent
	 * state, so we use NMIs as IPIs to tell the other CPUs to disable
	 * VMX and halt.
	 *
	 * For safety, we will avoid running the nmi_shootdown_cpus()
	 * stuff unnecessarily, but we don't have a way to check
	 * if other CPUs have VMX enabled. So we will call it only if the
	 * CPU we are running on has VMX enabled.
	 *
	 * We will miss cases where VMX is not enabled on all CPUs. This
	 * shouldn't do much harm because KVM always enable VMX on all
	 * CPUs anyway. But we can miss it on the small window where KVM
	 * is still enabling VMX.
	 */
	if (cpu_has_vmx() && cpu_vmx_enabled()) {
		/* Disable VMX on this CPU. */
		cpu_vmxoff();

		/* Halt and disable VMX on the other CPUs */
		nmi_shootdown_cpus(vmxoff_nmi);

	}
}


void __attribute__((weak)) mach_reboot_fixups(void)
{
}

/*
 * Windows compatible x86 hardware expects the following on reboot:
 *
 * 1) If the FADT has the ACPI reboot register flag set, try it
 * 2) If still alive, write to the keyboard controller
 * 3) If still alive, write to the ACPI reboot register again
 * 4) If still alive, write to the keyboard controller again
 *
 * If the machine is still alive at this stage, it gives up. We default to
 * following the same pattern, except that if we're still alive after (4) we'll
 * try to force a triple fault and then cycle between hitting the keyboard
 * controller and doing that
 */
static void __noreturn native_machine_emergency_restart(void)
{
	int i;
	int attempt = 0;
	int orig_reboot_type = reboot_type;

	if (reboot_emergency)
		emergency_vmx_disable_all();

	tboot_shutdown(TB_SHUTDOWN_REBOOT);

	/* Tell the BIOS if we want cold or warm reboot */
	*((unsigned short *)__va(0x472)) = reboot_mode;

	for (;;) {
		/* Could also try the reset bit in the Hammer NB */
		switch (reboot_type) {
		case BOOT_KBD:
			mach_reboot_fixups(); /* For board specific fixups */

			for (i = 0; i < 10; i++) {
				kb_wait();
				udelay(50);
				outb(0xfe, 0x64); /* Pulse reset low */
				udelay(50);
			}
			if (attempt == 0 && orig_reboot_type == BOOT_ACPI) {
				attempt = 1;
				reboot_type = BOOT_ACPI;
			} else {
				reboot_type = BOOT_TRIPLE;
			}
			break;

		case BOOT_TRIPLE:
			load_idt(&no_idt);
			__asm__ __volatile__("int3");

			reboot_type = BOOT_KBD;
			break;

		case BOOT_BIOS:
			machine_real_restart(MRR_BIOS);

			reboot_type = BOOT_KBD;
			break;

		case BOOT_ACPI:
			acpi_reboot();
			reboot_type = BOOT_KBD;
			break;

		case BOOT_EFI:
			if (efi_enabled)
				efi.reset_system(reboot_mode ?
						 EFI_RESET_WARM :
						 EFI_RESET_COLD,
						 EFI_SUCCESS, 0, NULL);
			reboot_type = BOOT_KBD;
			break;

		case BOOT_CF9:
			port_cf9_safe = true;
			/* Fall through */

		case BOOT_CF9_COND:
			if (port_cf9_safe) {
				u8 cf9 = inb(0xcf9) & ~6;
				outb(cf9|2, 0xcf9); /* Request hard reset */
				udelay(50);
				outb(cf9|6, 0xcf9); /* Actually do the reset */
				udelay(50);
			}
			reboot_type = BOOT_KBD;
			break;
		}
	}
}

void native_machine_shutdown(void)
{
	/* Stop the cpus and apics */
#ifdef CONFIG_SMP

	/* The boot cpu is always logical cpu 0 */
	int reboot_cpu_id = 0;

	/* See if there has been given a command line override */
	if ((reboot_cpu != -1) && (reboot_cpu < nr_cpu_ids) &&
		cpu_online(reboot_cpu))
		reboot_cpu_id = reboot_cpu;

	/* Make certain the cpu I'm about to reboot on is online */
	if (!cpu_online(reboot_cpu_id))
		reboot_cpu_id = smp_processor_id();

	/* Make certain I only run on the appropriate processor */
	set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));

	/*
	 * O.K Now that I'm on the appropriate processor, stop all of the
	 * others. Also disable the local irq to not receive the per-cpu
	 * timer interrupt which may trigger scheduler's load balance.
	 */
	local_irq_disable();
	stop_other_cpus();
#endif

	lapic_shutdown();

#ifdef CONFIG_X86_IO_APIC
	disable_IO_APIC();
#endif

#ifdef CONFIG_HPET_TIMER
	hpet_disable();
#endif

#ifdef CONFIG_X86_64
	x86_platform.iommu_shutdown();
#endif
}

static void __noreturn __machine_emergency_restart(int emergency)
{
	reboot_emergency = emergency;
	machine_ops.emergency_restart();
}

static void __noreturn native_machine_restart(char *__unused)
{
	pr_notice("machine restart\n");

	if (!reboot_force)
		machine_shutdown();
	__machine_emergency_restart(0);
}

static void __noreturn native_machine_halt(void)
{
	/* Stop other cpus and apics */
	machine_shutdown();

	tboot_shutdown(TB_SHUTDOWN_HALT);

	stop_this_cpu(NULL);
}

static void __noreturn native_machine_power_off(void)
{
	if (pm_power_off) {
		if (!reboot_force)
			machine_shutdown();
		pm_power_off();
	}
	/* A fallback in case there is no PM info available */
	tboot_shutdown(TB_SHUTDOWN_HALT);
	unreachable();
}

struct machine_ops machine_ops = {
	.power_off = native_machine_power_off,
	.shutdown = native_machine_shutdown,
	.emergency_restart = native_machine_emergency_restart,
	.restart = native_machine_restart,
	.halt = native_machine_halt,
#ifdef CONFIG_KEXEC
	.crash_shutdown = native_machine_crash_shutdown,
#endif
};

void machine_power_off(void)
{
	machine_ops.power_off();
}

void machine_shutdown(void)
{
	machine_ops.shutdown();
}

void machine_emergency_restart(void)
{
	__machine_emergency_restart(1);
}

void machine_restart(char *cmd)
{
	machine_ops.restart(cmd);
}

void machine_halt(void)
{
	machine_ops.halt();
}

#ifdef CONFIG_KEXEC
void machine_crash_shutdown(struct pt_regs *regs)
{
	machine_ops.crash_shutdown(regs);
}
#endif


#if defined(CONFIG_SMP)

/* This keeps a track of which one is crashing cpu. */
static int crashing_cpu;
static nmi_shootdown_cb shootdown_callback;

static atomic_t waiting_for_crash_ipi;

static int crash_nmi_callback(unsigned int val, struct pt_regs *regs)
{
	int cpu;

	cpu = raw_smp_processor_id();

	/*
	 * Don't do anything if this handler is invoked on crashing cpu.
	 * Otherwise, system will completely hang. Crashing cpu can get
	 * an NMI if system was initially booted with nmi_watchdog parameter.
	 */
	if (cpu == crashing_cpu)
		return NMI_HANDLED;
	local_irq_disable();

	shootdown_callback(cpu, regs);

	atomic_dec(&waiting_for_crash_ipi);
	/* Assume hlt works */
	halt();
	for (;;)
		cpu_relax();

	return NMI_HANDLED;
}

static void smp_send_nmi_allbutself(void)
{
	apic->send_IPI_allbutself(NMI_VECTOR);
}

/*
 * Halt all other CPUs, calling the specified function on each of them
 *
 * This function can be used to halt all other CPUs on crash
 * or emergency reboot time. The function passed as parameter
 * will be called inside a NMI handler on all CPUs.
 */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
	unsigned long msecs;
	local_irq_disable();

	/* Make a note of crashing cpu. Will be used in NMI callback. */
	crashing_cpu = safe_smp_processor_id();

	shootdown_callback = callback;

	atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
	/* Would it be better to replace the trap vector here? */
	if (register_nmi_handler(NMI_LOCAL, crash_nmi_callback,
				 NMI_FLAG_FIRST, "crash"))
		return;		/* Return what? */
	/*
	 * Ensure the new callback function is set before sending
	 * out the NMI
	 */
	wmb();

	smp_send_nmi_allbutself();

	msecs = 1000; /* Wait at most a second for the other cpus to stop */
	while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
		mdelay(1);
		msecs--;
	}

	/* Leave the nmi callback set */
}
#else /* !CONFIG_SMP */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
	/* No other CPUs to shoot down */
}
#endif

--------------080007080505040303060707
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080007080505040303060707--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:38:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:38: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 1UAOTV-0005Ij-2M; Tue, 26 Feb 2013 17:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UAOTS-0005IV-Vw
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:37:55 +0000
Received: from [85.158.139.83:56673] by server-8.bemta-5.messagelabs.com id
	BE/83-05790-2F2FC215; Tue, 26 Feb 2013 17:37:54 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361900272!29088659!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3104 invoked from network); 26 Feb 2013 17:37:52 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:37:52 -0000
Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232]
	helo=[192.168.95.34])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>) id 1UAOTP-0000PN-Lu
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 18:37:51 +0100
Message-ID: <512CF2EA.9080308@mfiala.net>
Date: Tue, 26 Feb 2013 18:37:46 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
In-Reply-To: <512CF62C02000078000C12F1@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Content-Type: multipart/mixed; boundary="------------080007080505040303060707"
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------080007080505040303060707
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/26/2013 05:51 PM, Jan Beulich wrote:
>>>> On 26.02.13 at 17:40, Michal Fiala <fiala@mfiala.net> wrote:
>> On 02/26/2013 05:33 PM, Jan Beulich wrote:
>>>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
>>>
>>> Please don't top post.
>>>
>>>> The kernel command line from grub.conf
>>>>
>>>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
>>>> console=com2,vga com2=115200,8n1
>>>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
>>>>
>>>> I have not modified reboot type.
>>>
>>> And did you check your full boot log for an info-level message like
>>>
>>> "%s series board detected. Selecting %s-method for reboot.\n"
>>
>> I have only checked normal boot log, see attachment in my first mail.
>> How can I enable info-level message?
> 
> Looks like this has info level messages enabled, and I can't see any
> such message there. So I guess you'll have to add a few printk()-s
> to arch/x86/kernel/reboot.c:native_machine_emergency_restart().
> 
> Jan

What informations are you interested in? I have attached reboot.c from
my kernel. Could you please patch it and I will deploy it.

Michal

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

--------------080007080505040303060707
Content-Type: text/x-csrc;
 name="reboot.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="reboot.c"

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

#include <linux/module.h>
#include <linux/reboot.h>
#include <linux/init.h>
#include <linux/pm.h>
#include <linux/efi.h>
#include <linux/dmi.h>
#include <linux/sched.h>
#include <linux/tboot.h>
#include <linux/delay.h>
#include <acpi/reboot.h>
#include <asm/io.h>
#include <asm/apic.h>
#include <asm/desc.h>
#include <asm/hpet.h>
#include <asm/pgtable.h>
#include <asm/proto.h>
#include <asm/reboot_fixups.h>
#include <asm/reboot.h>
#include <asm/pci_x86.h>
#include <asm/virtext.h>
#include <asm/cpu.h>
#include <asm/nmi.h>
#include <asm/smp.h>

#include <linux/ctype.h>
#include <linux/mc146818rtc.h>
#include <asm/realmode.h>
#include <asm/x86_init.h>

/*
 * Power off function, if any
 */
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);

static const struct desc_ptr no_idt = {};
static unsigned short reboot_mode;
enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;

/*
 * This variable is used privately to keep track of whether or not
 * reboot_type is still set to its default value (i.e., reboot= hasn't
 * been set on the command line).  This is needed so that we can
 * suppress DMI scanning for reboot quirks.  Without it, it's
 * impossible to override a faulty reboot quirk without recompiling.
 */
static int reboot_default = 1;

#ifdef CONFIG_SMP
static int reboot_cpu = -1;
#endif

/*
 * This is set if we need to go through the 'emergency' path.
 * When machine_emergency_restart() is called, we may be on
 * an inconsistent state and won't be able to do a clean cleanup
 */
static int reboot_emergency;

/* This is set by the PCI code if either type 1 or type 2 PCI is detected */
bool port_cf9_safe = false;

/*
 * reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci]
 * warm   Don't set the cold reboot flag
 * cold   Set the cold reboot flag
 * bios   Reboot by jumping through the BIOS
 * smp    Reboot by executing reset on BSP or other CPU
 * triple Force a triple fault (init)
 * kbd    Use the keyboard controller. cold reset (default)
 * acpi   Use the RESET_REG in the FADT
 * efi    Use efi reset_system runtime service
 * pci    Use the so-called "PCI reset register", CF9
 * force  Avoid anything that could hang.
 */
static int __init reboot_setup(char *str)
{
	for (;;) {
		/*
		 * Having anything passed on the command line via
		 * reboot= will cause us to disable DMI checking
		 * below.
		 */
		reboot_default = 0;

		switch (*str) {
		case 'w':
			reboot_mode = 0x1234;
			break;

		case 'c':
			reboot_mode = 0;
			break;

#ifdef CONFIG_SMP
		case 's':
			if (isdigit(*(str+1))) {
				reboot_cpu = (int) (*(str+1) - '0');
				if (isdigit(*(str+2)))
					reboot_cpu = reboot_cpu*10 + (int)(*(str+2) - '0');
			}
			/*
			 * We will leave sorting out the final value
			 * when we are ready to reboot, since we might not
			 * have detected BSP APIC ID or smp_num_cpu
			 */
			break;
#endif /* CONFIG_SMP */

		case 'b':
		case 'a':
		case 'k':
		case 't':
		case 'e':
		case 'p':
			reboot_type = *str;
			break;

		case 'f':
			reboot_force = 1;
			break;
		}

		str = strchr(str, ',');
		if (str)
			str++;
		else
			break;
	}
	return 1;
}

__setup("reboot=", reboot_setup);


/*
 * Reboot options and system auto-detection code provided by
 * Dell Inc. so their systems "just work". :-)
 */

/*
 * Some machines require the "reboot=b" or "reboot=k"  commandline options,
 * this quirk makes that automatic.
 */
static int __init set_bios_reboot(const struct dmi_system_id *d)
{
	if (reboot_type != BOOT_BIOS) {
		reboot_type = BOOT_BIOS;
		pr_info("%s series board detected. Selecting %s-method for reboots.\n",
			"BIOS", d->ident);
	}
	return 0;
}

void __noreturn machine_real_restart(unsigned int type)
{

#if defined(CONFIG_X86_32) && (defined(CONFIG_PAX_KERNEXEC) || defined(CONFIG_PAX_MEMORY_UDEREF))
	struct desc_struct *gdt;
#endif

	local_irq_disable();

	/*
	 * Write zero to CMOS register number 0x0f, which the BIOS POST
	 * routine will recognize as telling it to do a proper reboot.  (Well
	 * that's what this book in front of me says -- it may only apply to
	 * the Phoenix BIOS though, it's not clear).  At the same time,
	 * disable NMIs by setting the top bit in the CMOS address register,
	 * as we're about to do peculiar things to the CPU.  I'm not sure if
	 * `outb_p' is needed instead of just `outb'.  Use it to be on the
	 * safe side.  (Yes, CMOS_WRITE does outb_p's. -  Paul G.)
	 */
	spin_lock(&rtc_lock);
	CMOS_WRITE(0x00, 0x8f);
	spin_unlock(&rtc_lock);

	/*
	 * Switch back to the initial page table.
	 */
#ifdef CONFIG_X86_32
	load_cr3(initial_page_table);
#else
	write_cr3(real_mode_header->trampoline_pgd);
#endif

	/* Jump to the identity-mapped low memory code */
#ifdef CONFIG_X86_32

#if defined(CONFIG_PAX_KERNEXEC) || defined(CONFIG_PAX_MEMORY_UDEREF)
	gdt = get_cpu_gdt_table(smp_processor_id());
	pax_open_kernel();
#ifdef CONFIG_PAX_MEMORY_UDEREF
	gdt[GDT_ENTRY_KERNEL_DS].type = 3;
	gdt[GDT_ENTRY_KERNEL_DS].limit = 0xf;
	loadsegment(ds, __KERNEL_DS);
	loadsegment(es, __KERNEL_DS);
	loadsegment(ss, __KERNEL_DS);
#endif
#ifdef CONFIG_PAX_KERNEXEC
	gdt[GDT_ENTRY_KERNEL_CS].base0 = 0;
	gdt[GDT_ENTRY_KERNEL_CS].base1 = 0;
	gdt[GDT_ENTRY_KERNEL_CS].base2 = 0;
	gdt[GDT_ENTRY_KERNEL_CS].limit0 = 0xffff;
	gdt[GDT_ENTRY_KERNEL_CS].limit = 0xf;
	gdt[GDT_ENTRY_KERNEL_CS].g = 1;
#endif
	pax_close_kernel();
#endif

	asm volatile("ljmpl *%0" : :
		     "rm" (real_mode_header->machine_real_restart_asm),
		     "a" (type));
#else
	asm volatile("ljmpl *%0" : :
		     "m" (real_mode_header->machine_real_restart_asm),
		     "D" (type));
#endif
	unreachable();
}
#ifdef CONFIG_APM_MODULE
EXPORT_SYMBOL(machine_real_restart);
#endif

/*
 * Some Apple MacBook and MacBookPro's needs reboot=p to be able to reboot
 */
static int __init set_pci_reboot(const struct dmi_system_id *d)
{
	if (reboot_type != BOOT_CF9) {
		reboot_type = BOOT_CF9;
		pr_info("%s series board detected. Selecting %s-method for reboots.\n",
			"PCI", d->ident);
	}
	return 0;
}

static int __init set_kbd_reboot(const struct dmi_system_id *d)
{
	if (reboot_type != BOOT_KBD) {
		reboot_type = BOOT_KBD;
		pr_info("%s series board detected. Selecting %s-method for reboot.\n",
			"KBD", d->ident);
	}
	return 0;
}

/*
 * This is a single dmi_table handling all reboot quirks.
 */
static struct dmi_system_id __initdata reboot_dmi_table[] = {
	{	/* Handle problems with rebooting on Dell E520's */
		.callback = set_bios_reboot,
		.ident = "Dell E520",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM061"),
		},
	},
	{	/* Handle problems with rebooting on Dell 1300's */
		.callback = set_bios_reboot,
		.ident = "Dell PowerEdge 1300",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 1300/"),
		},
	},
	{	/* Handle problems with rebooting on Dell 300's */
		.callback = set_bios_reboot,
		.ident = "Dell PowerEdge 300",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 300/"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 745's SFF */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 745",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 745's DFF */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 745",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
			DMI_MATCH(DMI_BOARD_NAME, "0MM599"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 745 with 0KW626 */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 745",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
			DMI_MATCH(DMI_BOARD_NAME, "0KW626"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 330 with 0KP561 */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 330",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 330"),
			DMI_MATCH(DMI_BOARD_NAME, "0KP561"),
		},
	},
	{	/* Handle problems with rebooting on Dell Optiplex 360 with 0T656F */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 360",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 360"),
			DMI_MATCH(DMI_BOARD_NAME, "0T656F"),
		},
	},
	{	/* Handle problems with rebooting on Dell OptiPlex 760 with 0G919G */
		.callback = set_bios_reboot,
		.ident = "Dell OptiPlex 760",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 760"),
			DMI_MATCH(DMI_BOARD_NAME, "0G919G"),
		},
	},
	{	/* Handle problems with rebooting on Dell 2400's */
		.callback = set_bios_reboot,
		.ident = "Dell PowerEdge 2400",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 2400"),
		},
	},
	{	/* Handle problems with rebooting on Dell T5400's */
		.callback = set_bios_reboot,
		.ident = "Dell Precision T5400",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation T5400"),
		},
	},
	{	/* Handle problems with rebooting on Dell T7400's */
		.callback = set_bios_reboot,
		.ident = "Dell Precision T7400",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation T7400"),
		},
	},
	{	/* Handle problems with rebooting on HP laptops */
		.callback = set_bios_reboot,
		.ident = "HP Compaq Laptop",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
			DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"),
		},
	},
	{	/* Handle problems with rebooting on Dell XPS710 */
		.callback = set_bios_reboot,
		.ident = "Dell XPS710",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell XPS710"),
		},
	},
	{	/* Handle problems with rebooting on Dell DXP061 */
		.callback = set_bios_reboot,
		.ident = "Dell DXP061",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell DXP061"),
		},
	},
	{	/* Handle problems with rebooting on Sony VGN-Z540N */
		.callback = set_bios_reboot,
		.ident = "Sony VGN-Z540N",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
			DMI_MATCH(DMI_PRODUCT_NAME, "VGN-Z540N"),
		},
	},
	{	/* Handle problems with rebooting on ASUS P4S800 */
		.callback = set_bios_reboot,
		.ident = "ASUS P4S800",
		.matches = {
			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
			DMI_MATCH(DMI_BOARD_NAME, "P4S800"),
		},
	},

	{	/* Handle reboot issue on Acer Aspire one */
		.callback = set_kbd_reboot,
		.ident = "Acer Aspire One A110",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
			DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
		},
	},
	{	/* Handle problems with rebooting on Apple MacBook5 */
		.callback = set_pci_reboot,
		.ident = "Apple MacBook5",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "MacBook5"),
		},
	},
	{	/* Handle problems with rebooting on Apple MacBookPro5 */
		.callback = set_pci_reboot,
		.ident = "Apple MacBookPro5",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro5"),
		},
	},
	{	/* Handle problems with rebooting on Apple Macmini3,1 */
		.callback = set_pci_reboot,
		.ident = "Apple Macmini3,1",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Macmini3,1"),
		},
	},
	{	/* Handle problems with rebooting on the iMac9,1. */
		.callback = set_pci_reboot,
		.ident = "Apple iMac9,1",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "iMac9,1"),
		},
	},
	{	/* Handle problems with rebooting on the Latitude E6320. */
		.callback = set_pci_reboot,
		.ident = "Dell Latitude E6320",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6320"),
		},
	},
	{	/* Handle problems with rebooting on the Latitude E5420. */
		.callback = set_pci_reboot,
		.ident = "Dell Latitude E5420",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"),
		},
	},
	{	/* Handle problems with rebooting on the Latitude E6420. */
		.callback = set_pci_reboot,
		.ident = "Dell Latitude E6420",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6420"),
		},
	},
	{	/* Handle problems with rebooting on the OptiPlex 990. */
		.callback = set_pci_reboot,
		.ident = "Dell OptiPlex 990",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 990"),
		},
	},
	{	/* Handle problems with rebooting on the Precision M6600. */
		.callback = set_pci_reboot,
		.ident = "Dell OptiPlex 990",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
		},
	},
	{ }
};

static int __init reboot_init(void)
{
	/*
	 * Only do the DMI check if reboot_type hasn't been overridden
	 * on the command line
	 */
	if (reboot_default)
		dmi_check_system(reboot_dmi_table);
	return 0;
}
core_initcall(reboot_init);

static inline void kb_wait(void)
{
	int i;

	for (i = 0; i < 0x10000; i++) {
		if ((inb(0x64) & 0x02) == 0)
			break;
		udelay(2);
	}
}

static void vmxoff_nmi(int cpu, struct pt_regs *regs)
{
	cpu_emergency_vmxoff();
}

/* Use NMIs as IPIs to tell all CPUs to disable virtualization */
static void emergency_vmx_disable_all(void)
{
	/* Just make sure we won't change CPUs while doing this */
	local_irq_disable();

	/*
	 * We need to disable VMX on all CPUs before rebooting, otherwise
	 * we risk hanging up the machine, because the CPU ignore INIT
	 * signals when VMX is enabled.
	 *
	 * We can't take any locks and we may be on an inconsistent
	 * state, so we use NMIs as IPIs to tell the other CPUs to disable
	 * VMX and halt.
	 *
	 * For safety, we will avoid running the nmi_shootdown_cpus()
	 * stuff unnecessarily, but we don't have a way to check
	 * if other CPUs have VMX enabled. So we will call it only if the
	 * CPU we are running on has VMX enabled.
	 *
	 * We will miss cases where VMX is not enabled on all CPUs. This
	 * shouldn't do much harm because KVM always enable VMX on all
	 * CPUs anyway. But we can miss it on the small window where KVM
	 * is still enabling VMX.
	 */
	if (cpu_has_vmx() && cpu_vmx_enabled()) {
		/* Disable VMX on this CPU. */
		cpu_vmxoff();

		/* Halt and disable VMX on the other CPUs */
		nmi_shootdown_cpus(vmxoff_nmi);

	}
}


void __attribute__((weak)) mach_reboot_fixups(void)
{
}

/*
 * Windows compatible x86 hardware expects the following on reboot:
 *
 * 1) If the FADT has the ACPI reboot register flag set, try it
 * 2) If still alive, write to the keyboard controller
 * 3) If still alive, write to the ACPI reboot register again
 * 4) If still alive, write to the keyboard controller again
 *
 * If the machine is still alive at this stage, it gives up. We default to
 * following the same pattern, except that if we're still alive after (4) we'll
 * try to force a triple fault and then cycle between hitting the keyboard
 * controller and doing that
 */
static void __noreturn native_machine_emergency_restart(void)
{
	int i;
	int attempt = 0;
	int orig_reboot_type = reboot_type;

	if (reboot_emergency)
		emergency_vmx_disable_all();

	tboot_shutdown(TB_SHUTDOWN_REBOOT);

	/* Tell the BIOS if we want cold or warm reboot */
	*((unsigned short *)__va(0x472)) = reboot_mode;

	for (;;) {
		/* Could also try the reset bit in the Hammer NB */
		switch (reboot_type) {
		case BOOT_KBD:
			mach_reboot_fixups(); /* For board specific fixups */

			for (i = 0; i < 10; i++) {
				kb_wait();
				udelay(50);
				outb(0xfe, 0x64); /* Pulse reset low */
				udelay(50);
			}
			if (attempt == 0 && orig_reboot_type == BOOT_ACPI) {
				attempt = 1;
				reboot_type = BOOT_ACPI;
			} else {
				reboot_type = BOOT_TRIPLE;
			}
			break;

		case BOOT_TRIPLE:
			load_idt(&no_idt);
			__asm__ __volatile__("int3");

			reboot_type = BOOT_KBD;
			break;

		case BOOT_BIOS:
			machine_real_restart(MRR_BIOS);

			reboot_type = BOOT_KBD;
			break;

		case BOOT_ACPI:
			acpi_reboot();
			reboot_type = BOOT_KBD;
			break;

		case BOOT_EFI:
			if (efi_enabled)
				efi.reset_system(reboot_mode ?
						 EFI_RESET_WARM :
						 EFI_RESET_COLD,
						 EFI_SUCCESS, 0, NULL);
			reboot_type = BOOT_KBD;
			break;

		case BOOT_CF9:
			port_cf9_safe = true;
			/* Fall through */

		case BOOT_CF9_COND:
			if (port_cf9_safe) {
				u8 cf9 = inb(0xcf9) & ~6;
				outb(cf9|2, 0xcf9); /* Request hard reset */
				udelay(50);
				outb(cf9|6, 0xcf9); /* Actually do the reset */
				udelay(50);
			}
			reboot_type = BOOT_KBD;
			break;
		}
	}
}

void native_machine_shutdown(void)
{
	/* Stop the cpus and apics */
#ifdef CONFIG_SMP

	/* The boot cpu is always logical cpu 0 */
	int reboot_cpu_id = 0;

	/* See if there has been given a command line override */
	if ((reboot_cpu != -1) && (reboot_cpu < nr_cpu_ids) &&
		cpu_online(reboot_cpu))
		reboot_cpu_id = reboot_cpu;

	/* Make certain the cpu I'm about to reboot on is online */
	if (!cpu_online(reboot_cpu_id))
		reboot_cpu_id = smp_processor_id();

	/* Make certain I only run on the appropriate processor */
	set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));

	/*
	 * O.K Now that I'm on the appropriate processor, stop all of the
	 * others. Also disable the local irq to not receive the per-cpu
	 * timer interrupt which may trigger scheduler's load balance.
	 */
	local_irq_disable();
	stop_other_cpus();
#endif

	lapic_shutdown();

#ifdef CONFIG_X86_IO_APIC
	disable_IO_APIC();
#endif

#ifdef CONFIG_HPET_TIMER
	hpet_disable();
#endif

#ifdef CONFIG_X86_64
	x86_platform.iommu_shutdown();
#endif
}

static void __noreturn __machine_emergency_restart(int emergency)
{
	reboot_emergency = emergency;
	machine_ops.emergency_restart();
}

static void __noreturn native_machine_restart(char *__unused)
{
	pr_notice("machine restart\n");

	if (!reboot_force)
		machine_shutdown();
	__machine_emergency_restart(0);
}

static void __noreturn native_machine_halt(void)
{
	/* Stop other cpus and apics */
	machine_shutdown();

	tboot_shutdown(TB_SHUTDOWN_HALT);

	stop_this_cpu(NULL);
}

static void __noreturn native_machine_power_off(void)
{
	if (pm_power_off) {
		if (!reboot_force)
			machine_shutdown();
		pm_power_off();
	}
	/* A fallback in case there is no PM info available */
	tboot_shutdown(TB_SHUTDOWN_HALT);
	unreachable();
}

struct machine_ops machine_ops = {
	.power_off = native_machine_power_off,
	.shutdown = native_machine_shutdown,
	.emergency_restart = native_machine_emergency_restart,
	.restart = native_machine_restart,
	.halt = native_machine_halt,
#ifdef CONFIG_KEXEC
	.crash_shutdown = native_machine_crash_shutdown,
#endif
};

void machine_power_off(void)
{
	machine_ops.power_off();
}

void machine_shutdown(void)
{
	machine_ops.shutdown();
}

void machine_emergency_restart(void)
{
	__machine_emergency_restart(1);
}

void machine_restart(char *cmd)
{
	machine_ops.restart(cmd);
}

void machine_halt(void)
{
	machine_ops.halt();
}

#ifdef CONFIG_KEXEC
void machine_crash_shutdown(struct pt_regs *regs)
{
	machine_ops.crash_shutdown(regs);
}
#endif


#if defined(CONFIG_SMP)

/* This keeps a track of which one is crashing cpu. */
static int crashing_cpu;
static nmi_shootdown_cb shootdown_callback;

static atomic_t waiting_for_crash_ipi;

static int crash_nmi_callback(unsigned int val, struct pt_regs *regs)
{
	int cpu;

	cpu = raw_smp_processor_id();

	/*
	 * Don't do anything if this handler is invoked on crashing cpu.
	 * Otherwise, system will completely hang. Crashing cpu can get
	 * an NMI if system was initially booted with nmi_watchdog parameter.
	 */
	if (cpu == crashing_cpu)
		return NMI_HANDLED;
	local_irq_disable();

	shootdown_callback(cpu, regs);

	atomic_dec(&waiting_for_crash_ipi);
	/* Assume hlt works */
	halt();
	for (;;)
		cpu_relax();

	return NMI_HANDLED;
}

static void smp_send_nmi_allbutself(void)
{
	apic->send_IPI_allbutself(NMI_VECTOR);
}

/*
 * Halt all other CPUs, calling the specified function on each of them
 *
 * This function can be used to halt all other CPUs on crash
 * or emergency reboot time. The function passed as parameter
 * will be called inside a NMI handler on all CPUs.
 */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
	unsigned long msecs;
	local_irq_disable();

	/* Make a note of crashing cpu. Will be used in NMI callback. */
	crashing_cpu = safe_smp_processor_id();

	shootdown_callback = callback;

	atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
	/* Would it be better to replace the trap vector here? */
	if (register_nmi_handler(NMI_LOCAL, crash_nmi_callback,
				 NMI_FLAG_FIRST, "crash"))
		return;		/* Return what? */
	/*
	 * Ensure the new callback function is set before sending
	 * out the NMI
	 */
	wmb();

	smp_send_nmi_allbutself();

	msecs = 1000; /* Wait at most a second for the other cpus to stop */
	while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
		mdelay(1);
		msecs--;
	}

	/* Leave the nmi callback set */
}
#else /* !CONFIG_SMP */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
	/* No other CPUs to shoot down */
}
#endif

--------------080007080505040303060707
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080007080505040303060707--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:40:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOVR-0005WH-Qx; Tue, 26 Feb 2013 17:39:57 +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 1UAOVQ-0005W4-6x
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:39:56 +0000
Received: from [193.109.254.147:30643] by server-3.bemta-14.messagelabs.com id
	4B/E2-22141-B63FC215; Tue, 26 Feb 2013 17:39:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361900394!9642535!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22757 invoked from network); 26 Feb 2013 17:39:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:39: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.297.1;
	Tue, 26 Feb 2013 17:39:54 +0000
Message-ID: <1361900393.26546.319.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 17:39:53 +0000
In-Reply-To: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, Fabio
	Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 17:33 +0000, Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Tim Deegan wrote:
> > At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > > And I do think that there is a plausible argument that the config
> > > > > files ought not to be just blatted over the top of your system.  (If
> > > > > "make install" does that then there's the same argument there - I
> > > > > don't think "make install" should trash existing config.)
> > > > 
> > > > AFAIK 'make install' does; certainly some room for improvement in that
> > > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > > I don't want remnants of old tests contaminating my new install - that
> > > > was the whole point.
> > > 
> > > If you say dpkg --purge they will be entirely removed, even if marked
> > > as conffiles.
> > 
> > Yes, but that assumes that the default behaviour shouuld be to leave
> > them around, which I dispute.  Again, using .deb leads to thinking about
> > how a real package would behave. :)
> 
> Maybe we should produce a tgz instead (plain or Slackware style).
> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages. (Of course I still think the
> best choice would be to produce good packages.)

I think you have massively underestimated the development effort and
maintenance burden of producing good packages. Again: That is what the
distros do, and they do it well and in a far more scalable fashion than
we ever could.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:40:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOVR-0005WH-Qx; Tue, 26 Feb 2013 17:39:57 +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 1UAOVQ-0005W4-6x
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:39:56 +0000
Received: from [193.109.254.147:30643] by server-3.bemta-14.messagelabs.com id
	4B/E2-22141-B63FC215; Tue, 26 Feb 2013 17:39:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361900394!9642535!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22757 invoked from network); 26 Feb 2013 17:39:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914320"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:39: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.297.1;
	Tue, 26 Feb 2013 17:39:54 +0000
Message-ID: <1361900393.26546.319.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 26 Feb 2013 17:39:53 +0000
In-Reply-To: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, Fabio
	Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 17:33 +0000, Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Tim Deegan wrote:
> > At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > > And I do think that there is a plausible argument that the config
> > > > > files ought not to be just blatted over the top of your system.  (If
> > > > > "make install" does that then there's the same argument there - I
> > > > > don't think "make install" should trash existing config.)
> > > > 
> > > > AFAIK 'make install' does; certainly some room for improvement in that
> > > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > > I don't want remnants of old tests contaminating my new install - that
> > > > was the whole point.
> > > 
> > > If you say dpkg --purge they will be entirely removed, even if marked
> > > as conffiles.
> > 
> > Yes, but that assumes that the default behaviour shouuld be to leave
> > them around, which I dispute.  Again, using .deb leads to thinking about
> > how a real package would behave. :)
> 
> Maybe we should produce a tgz instead (plain or Slackware style).
> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages. (Of course I still think the
> best choice would be to produce good packages.)

I think you have massively underestimated the development effort and
maintenance burden of producing good packages. Again: That is what the
distros do, and they do it well and in a far more scalable fashion than
we ever could.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:41:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:41: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 1UAOWO-0005cR-Gv; Tue, 26 Feb 2013 17:40: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 1UAOWM-0005c7-NX
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:40:54 +0000
Received: from [85.158.139.83:24503] by server-10.bemta-5.messagelabs.com id
	91/73-23714-6A3FC215; Tue, 26 Feb 2013 17:40:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361900453!27292927!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17798 invoked from network); 26 Feb 2013 17:40:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:40:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 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.297.1; Tue, 26 Feb 2013 17:40:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOWB-0000Ex-Oe; Tue, 26 Feb 2013 17:40:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOWB-0002Wy-K0;
	Tue, 26 Feb 2013 17:40:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62363.486434.797437@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:40:43 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.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>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Maybe we should produce a tgz instead (plain or Slackware style).

This fails to solve the problem Tim was trying to solve, which is
to make it easy to remove previous versions.

> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages. (Of course I still think the
> best choice would be to produce good packages.)

I think we can engage in better expectations management.  Perhaps we
could rename the target.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:41:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:41: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 1UAOWO-0005cR-Gv; Tue, 26 Feb 2013 17:40: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 1UAOWM-0005c7-NX
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:40:54 +0000
Received: from [85.158.139.83:24503] by server-10.bemta-5.messagelabs.com id
	91/73-23714-6A3FC215; Tue, 26 Feb 2013 17:40:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361900453!27292927!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17798 invoked from network); 26 Feb 2013 17:40:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:40:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 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.297.1; Tue, 26 Feb 2013 17:40:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOWB-0000Ex-Oe; Tue, 26 Feb 2013 17:40:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOWB-0002Wy-K0;
	Tue, 26 Feb 2013 17:40:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62363.486434.797437@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:40:43 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.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>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Maybe we should produce a tgz instead (plain or Slackware style).

This fails to solve the problem Tim was trying to solve, which is
to make it easy to remove previous versions.

> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages. (Of course I still think the
> best choice would be to produce good packages.)

I think we can engage in better expectations management.  Perhaps we
could rename the target.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:42:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOYC-0005rG-1M; Tue, 26 Feb 2013 17:42:48 +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 1UAOYA-0005qo-VM
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:42:47 +0000
Received: from [85.158.139.83:38530] by server-6.bemta-5.messagelabs.com id
	41/5B-21466-614FC215; Tue, 26 Feb 2013 17:42:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361900564!25167356!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18296 invoked from network); 26 Feb 2013 17:42:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:42:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QHgcOj031601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:42:39 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
	r1QHgc8d027715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:42:38 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
	r1QHgb6R021279; Tue, 26 Feb 2013 11:42:37 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:42:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 88B371C3935; Tue, 26 Feb 2013 12:42:36 -0500 (EST)
Date: Tue, 26 Feb 2013 12:42:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226174236.GB23731@phenom.dumpdata.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
	<20780.57185.786644.525993@mariner.uk.xensource.com>
	<20130226170520.GC22422@phenom.dumpdata.com>
	<20780.60511.375340.303132@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.60511.375340.303132@mariner.uk.xensource.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>,
	"ian.campbel@citrix.com" <ian.campbel@citrix.com>
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup
 section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 05:09:51PM +0000, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup section to include ELF and memory layout"):
> > On Tue, Feb 26, 2013 at 04:14:25PM +0000, Ian Jackson wrote:
> > > This line is too long for a .txt file; it shoudl be 70 or maybe 75.
> > > This is a problem throughout the file.
> > 
> > Huh? This goes on the Wiki so I am not sure if we need to worry about that.
> 
> Oh sorry, I'm confused.  I saw ".txt" in your patch and thought this
> was a patch to a file in the Xen tree's docs.

Sorry - I didn't know how else to do this. This "patch" to the Wiki
content was easier to make then putting in the changes in the Wiki and
then asking folks to look there.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:42:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOYC-0005rG-1M; Tue, 26 Feb 2013 17:42:48 +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 1UAOYA-0005qo-VM
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:42:47 +0000
Received: from [85.158.139.83:38530] by server-6.bemta-5.messagelabs.com id
	41/5B-21466-614FC215; Tue, 26 Feb 2013 17:42:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1361900564!25167356!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18296 invoked from network); 26 Feb 2013 17:42:45 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:42:45 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QHgcOj031601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:42:39 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
	r1QHgc8d027715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:42:38 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
	r1QHgb6R021279; Tue, 26 Feb 2013 11:42:37 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:42:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 88B371C3935; Tue, 26 Feb 2013 12:42:36 -0500 (EST)
Date: Tue, 26 Feb 2013 12:42:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130226174236.GB23731@phenom.dumpdata.com>
References: <1361809680-10075-1-git-send-email-konrad.wilk@oracle.com>
	<1361809680-10075-2-git-send-email-konrad.wilk@oracle.com>
	<20780.57185.786644.525993@mariner.uk.xensource.com>
	<20130226170520.GC22422@phenom.dumpdata.com>
	<20780.60511.375340.303132@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.60511.375340.303132@mariner.uk.xensource.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>,
	"ian.campbel@citrix.com" <ian.campbel@citrix.com>
Subject: Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup
 section to include ELF and memory layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 05:09:51PM +0000, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH to X86 PV MMU Wiki v2] Expand th e bootup section to include ELF and memory layout"):
> > On Tue, Feb 26, 2013 at 04:14:25PM +0000, Ian Jackson wrote:
> > > This line is too long for a .txt file; it shoudl be 70 or maybe 75.
> > > This is a problem throughout the file.
> > 
> > Huh? This goes on the Wiki so I am not sure if we need to worry about that.
> 
> Oh sorry, I'm confused.  I saw ".txt" in your patch and thought this
> was a patch to a file in the Xen tree's docs.

Sorry - I didn't know how else to do this. This "patch" to the Wiki
content was easier to make then putting in the changes in the Wiki and
then asking folks to look there.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:43:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:43: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 1UAOYp-0005wH-Ff; Tue, 26 Feb 2013 17:43:27 +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 1UAOYn-0005w1-MH
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:43:25 +0000
Received: from [85.158.137.99:30908] by server-1.bemta-3.messagelabs.com id
	8A/5A-08955-C34FC215; Tue, 26 Feb 2013 17:43:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361900602!15060625!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7927 invoked from network); 26 Feb 2013 17:43:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:43:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QHhFKV032525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:43:16 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
	r1QHhEEq022839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:43:15 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
	r1QHhELq021783; Tue, 26 Feb 2013 11:43:14 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:43:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2388E1C3935; Tue, 26 Feb 2013 12:43:13 -0500 (EST)
Date: Tue, 26 Feb 2013 12:43:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130226174313.GC23731@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
	<512CECCE.3070305@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CECCE.3070305@canonical.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>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 06:11:42PM +0100, Stefan Bader wrote:
> On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
> >> On 25.02.2013 10:10, Stefan Bader wrote:
> >>> On 25.02.2013 04:15, Liu, Jinsong wrote:
> >>>> Konrad Rzeszutek Wilk wrote:
> >>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> >>>>>> Hi Konrad,
> >>>>>
> >>>>> Hey Stefan,
> >>>>>>
> >>>>>> here is another one from the hm-what? department:
> >>>>>
> >>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> >>>>> he has been tracking a similar one with mcelog.
> >>>>>>
> >>>>>> Colin discovered that running the attached program with the fork
> >>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
> >>>>>> iomem) this triggers the following weird messages: 
> >>>>>>
> >>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
> >>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
> >>>>>> [ 6824.453776] ------------[ cut here ]------------
> >>>>>> [ 6824.453796] WARNING: at
> >>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> >>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
> >>>>>> mmap-example Tainted: GF 
> >>>>>> 3.8.0-6-generic #13-Ubuntu
> >>>>>> [ 6824.453926] Call Trace:
> >>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> >>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> >>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> >>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> >>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> >>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> >>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> >>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> >>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
> >>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038] 
> >>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048] 
> >>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060] 
> >>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069] 
> >>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
> >>>>>> ---[ end trace 4918cdd0a4c9fea4 ]--- 
> >>>>>>
> >>>>>> I found that this is related to your bandaid patch
> >>>>>>
> >>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> >>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
> >>>>>>
> >>>>>>     xen/pat: Disable PAT support for now.
> >>>>>>
> >>>>>> I just do not understand how this happens. From the trace it seems
> >>>>>> the fork 
> >>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
> >>>>>> maybe the 
> >>>>>> warning is just related to this. So primarily the question is how on
> >>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
> >>>>>> cleared from the supported 
> >>>>>> mask by the patch, so somehow I would think nothing should be able
> >>>>>> to set it... 
> >>>>>> But apparently not so.
> >>>>>> Not sure it is a big deal since I never saw this in normal operation
> >>>>>> and it 
> >>>>>> seems to be ok when unapping before doing the fork. It is just plain
> >>>>>> odd. 
> >>>>>
> >>>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> >>>>> ranges are swapped or not correct. Jinsong, could you shed some light
> >>>>> on what you have found so far?
> >>>>>
> >>>>
> >>>> Yes, Sander once also reported a similar weird warning when start mcelog daemon, as attached.
> >>>>
> >>>> Basically, it occurs when mcelog user daemon start, 
> >>>> do_fork
> >>>>   --> copy_process
> >>>>     --> dup_mm
> >>>>       --> dup_mmap
> >>>>         --> copy_page_range
> >>>>           --> track_pfn_copy
> >>>>             --> reserve_pfn_range
> >>
> >> So that makes it clearer as this will do
> >>
> >> reserve_memtype(...)
> >> --> pat_x_mtrr_type
> >>   --> mtrr_type_lookup
> >>     --> __mtrr_type_lookup
> >>
> >> And that can return -1/0xff in case of mtrr not being enabled/initialized. Which
> >> is not the case (given there are no messages for it in dmesg). This is not equal
> >> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
> >>
> >> It looks like the problem starts early in reserve_memtype:
> >>
> >>         if (!pat_enabled) {
> >>                 /* This is identical to page table setting without PAT */
> >>                 if (new_type) {
> >>                         if (req_type == _PAGE_CACHE_WC)
> >>                                 *new_type = _PAGE_CACHE_UC_MINUS;
> >>                         else
> >>                                 *new_type = req_type & _PAGE_CACHE_MASK;
> >>                 }
> >>                 return 0;
> >>         }
> >>
> >> This would be what we want, but only clearing the PWT and PCD flags from the
> >> supported flags is not changing pat_enabled (which is 1 when PAT support is
> >> compiled into the kernel). Unfortunately the variable is local and since there
> >> are not any messages about PAT in dmesg I would say pat_init() is not called
> >> either. Which might be used to disable PAT support by clearing the CPU feature
> >> flag.
> > 
> > Hm, so:
> > 
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index 39928d1..9ac70c5 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
> >  
> >         cpuid_leaf1_edx_mask =
> >                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> > +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
> >                   (1 << X86_FEATURE_ACC));   /* thermal monitoring */
> >  
> >         if (!xen_initial_domain())
> > 
> > 
> > 
> > should do it right? Let me check on the troublesome machine I saw
> > it.
> > 
> I could try it as well but somehow my reading of pat_init() is that if that
> would have been called at all, there should be some message about PAT in dmesg.
> And normal dom0 boots do not show anything.
> 
> It looks like pat_init only gets called from two places in mtrr code, and that
> probably is not done in dom0 either. So clearing the feature is one step, but I
> would think that also there needs to be a call to pat_init...

So how about this super-complex patch:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 39928d1..c8e1c7b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -67,6 +67,7 @@
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
+#include <asm/pat.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1417,7 +1418,14 @@ asmlinkage void __init xen_start_kernel(void)
 	 */
 	acpi_numa = -1;
 #endif
-
+#ifdef CONFIG_X86_PAT
+	/*
+	 * For right now disable the PAT. We should remove this once
+	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
+	 * (xen/pat: Disable PAT support for now) is reverted.
+	 */
+	pat_enabled = 0;
+#endif
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];

trying it out now.
> 
> -Stefan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:43:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:43: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 1UAOYp-0005wH-Ff; Tue, 26 Feb 2013 17:43:27 +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 1UAOYn-0005w1-MH
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:43:25 +0000
Received: from [85.158.137.99:30908] by server-1.bemta-3.messagelabs.com id
	8A/5A-08955-C34FC215; Tue, 26 Feb 2013 17:43:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361900602!15060625!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7927 invoked from network); 26 Feb 2013 17:43:24 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:43:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QHhFKV032525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:43:16 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
	r1QHhEEq022839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:43:15 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
	r1QHhELq021783; Tue, 26 Feb 2013 11:43:14 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:43:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2388E1C3935; Tue, 26 Feb 2013 12:43:13 -0500 (EST)
Date: Tue, 26 Feb 2013 12:43:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130226174313.GC23731@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
	<512CECCE.3070305@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CECCE.3070305@canonical.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>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 06:11:42PM +0100, Stefan Bader wrote:
> On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
> >> On 25.02.2013 10:10, Stefan Bader wrote:
> >>> On 25.02.2013 04:15, Liu, Jinsong wrote:
> >>>> Konrad Rzeszutek Wilk wrote:
> >>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> >>>>>> Hi Konrad,
> >>>>>
> >>>>> Hey Stefan,
> >>>>>>
> >>>>>> here is another one from the hm-what? department:
> >>>>>
> >>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> >>>>> he has been tracking a similar one with mcelog.
> >>>>>>
> >>>>>> Colin discovered that running the attached program with the fork
> >>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
> >>>>>> iomem) this triggers the following weird messages: 
> >>>>>>
> >>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
> >>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
> >>>>>> [ 6824.453776] ------------[ cut here ]------------
> >>>>>> [ 6824.453796] WARNING: at
> >>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> >>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
> >>>>>> mmap-example Tainted: GF 
> >>>>>> 3.8.0-6-generic #13-Ubuntu
> >>>>>> [ 6824.453926] Call Trace:
> >>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> >>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> >>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> >>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> >>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> >>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> >>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> >>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> >>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
> >>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038] 
> >>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048] 
> >>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060] 
> >>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069] 
> >>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
> >>>>>> ---[ end trace 4918cdd0a4c9fea4 ]--- 
> >>>>>>
> >>>>>> I found that this is related to your bandaid patch
> >>>>>>
> >>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> >>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
> >>>>>>
> >>>>>>     xen/pat: Disable PAT support for now.
> >>>>>>
> >>>>>> I just do not understand how this happens. From the trace it seems
> >>>>>> the fork 
> >>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
> >>>>>> maybe the 
> >>>>>> warning is just related to this. So primarily the question is how on
> >>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
> >>>>>> cleared from the supported 
> >>>>>> mask by the patch, so somehow I would think nothing should be able
> >>>>>> to set it... 
> >>>>>> But apparently not so.
> >>>>>> Not sure it is a big deal since I never saw this in normal operation
> >>>>>> and it 
> >>>>>> seems to be ok when unapping before doing the fork. It is just plain
> >>>>>> odd. 
> >>>>>
> >>>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> >>>>> ranges are swapped or not correct. Jinsong, could you shed some light
> >>>>> on what you have found so far?
> >>>>>
> >>>>
> >>>> Yes, Sander once also reported a similar weird warning when start mcelog daemon, as attached.
> >>>>
> >>>> Basically, it occurs when mcelog user daemon start, 
> >>>> do_fork
> >>>>   --> copy_process
> >>>>     --> dup_mm
> >>>>       --> dup_mmap
> >>>>         --> copy_page_range
> >>>>           --> track_pfn_copy
> >>>>             --> reserve_pfn_range
> >>
> >> So that makes it clearer as this will do
> >>
> >> reserve_memtype(...)
> >> --> pat_x_mtrr_type
> >>   --> mtrr_type_lookup
> >>     --> __mtrr_type_lookup
> >>
> >> And that can return -1/0xff in case of mtrr not being enabled/initialized. Which
> >> is not the case (given there are no messages for it in dmesg). This is not equal
> >> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
> >>
> >> It looks like the problem starts early in reserve_memtype:
> >>
> >>         if (!pat_enabled) {
> >>                 /* This is identical to page table setting without PAT */
> >>                 if (new_type) {
> >>                         if (req_type == _PAGE_CACHE_WC)
> >>                                 *new_type = _PAGE_CACHE_UC_MINUS;
> >>                         else
> >>                                 *new_type = req_type & _PAGE_CACHE_MASK;
> >>                 }
> >>                 return 0;
> >>         }
> >>
> >> This would be what we want, but only clearing the PWT and PCD flags from the
> >> supported flags is not changing pat_enabled (which is 1 when PAT support is
> >> compiled into the kernel). Unfortunately the variable is local and since there
> >> are not any messages about PAT in dmesg I would say pat_init() is not called
> >> either. Which might be used to disable PAT support by clearing the CPU feature
> >> flag.
> > 
> > Hm, so:
> > 
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index 39928d1..9ac70c5 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
> >  
> >         cpuid_leaf1_edx_mask =
> >                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> > +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
> >                   (1 << X86_FEATURE_ACC));   /* thermal monitoring */
> >  
> >         if (!xen_initial_domain())
> > 
> > 
> > 
> > should do it right? Let me check on the troublesome machine I saw
> > it.
> > 
> I could try it as well but somehow my reading of pat_init() is that if that
> would have been called at all, there should be some message about PAT in dmesg.
> And normal dom0 boots do not show anything.
> 
> It looks like pat_init only gets called from two places in mtrr code, and that
> probably is not done in dom0 either. So clearing the feature is one step, but I
> would think that also there needs to be a call to pat_init...

So how about this super-complex patch:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 39928d1..c8e1c7b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -67,6 +67,7 @@
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
+#include <asm/pat.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1417,7 +1418,14 @@ asmlinkage void __init xen_start_kernel(void)
 	 */
 	acpi_numa = -1;
 #endif
-
+#ifdef CONFIG_X86_PAT
+	/*
+	 * For right now disable the PAT. We should remove this once
+	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
+	 * (xen/pat: Disable PAT support for now) is reverted.
+	 */
+	pat_enabled = 0;
+#endif
 	/* Don't do the full vcpu_info placement stuff until we have a
 	   possible map and a non-dummy shared_info. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];

trying it out now.
> 
> -Stefan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:44:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:44: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 1UAOZt-000657-VV; Tue, 26 Feb 2013 17:44: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 1UAOZs-00064i-Ag
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:44:32 +0000
Received: from [193.109.254.147:12892] by server-15.bemta-14.messagelabs.com
	id CE/F9-24599-F74FC215; Tue, 26 Feb 2013 17:44:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361900660!9130780!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13219 invoked from network); 26 Feb 2013 17:44:21 -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; 26 Feb 2013 17:44:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAOZf-000Pdd-QE; Tue, 26 Feb 2013 17:44:19 +0000
Date: Tue, 26 Feb 2013 17:44:19 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130226174419.GH93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 17:33 +0000 on 26 Feb (1361899998), Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Tim Deegan wrote:
> > At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > > And I do think that there is a plausible argument that the config
> > > > > files ought not to be just blatted over the top of your system.  (If
> > > > > "make install" does that then there's the same argument there - I
> > > > > don't think "make install" should trash existing config.)
> > > > 
> > > > AFAIK 'make install' does; certainly some room for improvement in that
> > > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > > I don't want remnants of old tests contaminating my new install - that
> > > > was the whole point.
> > > 
> > > If you say dpkg --purge they will be entirely removed, even if marked
> > > as conffiles.
> > 
> > Yes, but that assumes that the default behaviour shouuld be to leave
> > them around, which I dispute.  Again, using .deb leads to thinking about
> > how a real package would behave. :)
> 
> Maybe we should produce a tgz instead (plain or Slackware style).
> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages.

That's fair.  The existing deb target is just the configuration that I
find useful, and perhaps no more reasonable than anyone else's personal
preference.  I'm happy to take my ball and go home; I can use the mkdeb
script from my home directory just as well. :)

> (Of course I still think the
> best choice would be to produce good packages.)

Sure, but that's a lot more work than I've seen in any of these patches
so far.  Are you volunteering?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:44:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:44: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 1UAOZt-000657-VV; Tue, 26 Feb 2013 17:44: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 1UAOZs-00064i-Ag
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:44:32 +0000
Received: from [193.109.254.147:12892] by server-15.bemta-14.messagelabs.com
	id CE/F9-24599-F74FC215; Tue, 26 Feb 2013 17:44:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361900660!9130780!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13219 invoked from network); 26 Feb 2013 17:44:21 -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; 26 Feb 2013 17:44:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAOZf-000Pdd-QE; Tue, 26 Feb 2013 17:44:19 +0000
Date: Tue, 26 Feb 2013 17:44:19 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20130226174419.GH93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 17:33 +0000 on 26 Feb (1361899998), Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Tim Deegan wrote:
> > At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > > And I do think that there is a plausible argument that the config
> > > > > files ought not to be just blatted over the top of your system.  (If
> > > > > "make install" does that then there's the same argument there - I
> > > > > don't think "make install" should trash existing config.)
> > > > 
> > > > AFAIK 'make install' does; certainly some room for improvement in that
> > > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > > I don't want remnants of old tests contaminating my new install - that
> > > > was the whole point.
> > > 
> > > If you say dpkg --purge they will be entirely removed, even if marked
> > > as conffiles.
> > 
> > Yes, but that assumes that the default behaviour shouuld be to leave
> > them around, which I dispute.  Again, using .deb leads to thinking about
> > how a real package would behave. :)
> 
> Maybe we should produce a tgz instead (plain or Slackware style).
> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages.

That's fair.  The existing deb target is just the configuration that I
find useful, and perhaps no more reasonable than anyone else's personal
preference.  I'm happy to take my ball and go home; I can use the mkdeb
script from my home directory just as well. :)

> (Of course I still think the
> best choice would be to produce good packages.)

Sure, but that's a lot more work than I've seen in any of these patches
so far.  Are you volunteering?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:44:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:44: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 1UAOa1-00066X-Cb; Tue, 26 Feb 2013 17:44:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1UAOa0-00066M-Jq
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:44:40 +0000
Received: from [85.158.139.83:57217] by server-14.bemta-5.messagelabs.com id
	43/17-13158-784FC215; Tue, 26 Feb 2013 17:44:39 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361900675!29107362!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_32,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24177 invoked from network); 26 Feb 2013 17:44:35 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:44:35 -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 1UAOZu-0006Ic-Nc; Tue, 26 Feb 2013 18:44:34 +0100
Date: Tue, 26 Feb 2013 18:44:33 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <894977724.20130226140702@eikelenboom.it>
Message-ID: <alpine.LFD.2.02.1302261843240.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.com>
	<alpine.LFD.2.02.1302261320120.22263@ionos>
	<894977724.20130226140702@eikelenboom.it>
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: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regression introduced with
 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot
 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, 26 Feb 2013, Sander Eikelenboom wrote:
> Tuesday, February 26, 2013, 1:36:36 PM, you wrote:
> > On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> >> 
> >> I don't know if this is b/c the Xen code is missing something or
> >> expects something that never happend. I hadn't looked at your
> >> patch in any detail (was going to do that on Monday).
> >> 
> >> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
> 
> Hmm i'm seeing this booting on baremetal as well.
> (see http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00836.html)

Ok. I decoded it with the help of Konrad. Does the patch below work
for you as well?

Thanks,

	tglx

Index: linux-2.6/include/linux/smpboot.h
===================================================================
--- linux-2.6.orig/include/linux/smpboot.h
+++ linux-2.6/include/linux/smpboot.h
@@ -24,6 +24,9 @@ struct smpboot_thread_data;
  *			parked (cpu offline)
  * @unpark:		Optional unpark function, called when the thread is
  *			unparked (cpu online)
+ * @pre_unpark:		Optional unpark function, called before the thread is
+ *			unparked (cpu online). This is not guaranteed to be
+ *			called on the target cpu of the thread. Careful!
  * @selfparking:	Thread is not parked by the park function.
  * @thread_comm:	The base name of the thread
  */
@@ -37,6 +40,7 @@ struct smp_hotplug_thread {
 	void				(*cleanup)(unsigned int cpu, bool online);
 	void				(*park)(unsigned int cpu);
 	void				(*unpark)(unsigned int cpu);
+	void				(*pre_unpark)(unsigned int cpu);
 	bool				selfparking;
 	const char			*thread_comm;
 };
Index: linux-2.6/kernel/smpboot.c
===================================================================
--- linux-2.6.orig/kernel/smpboot.c
+++ linux-2.6/kernel/smpboot.c
@@ -209,6 +209,8 @@ static void smpboot_unpark_thread(struct
 {
 	struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
 
+	if (ht->pre_unpark)
+		ht->pre_unpark(cpu);
 	kthread_unpark(tsk);
 }
 
Index: linux-2.6/kernel/stop_machine.c
===================================================================
--- linux-2.6.orig/kernel/stop_machine.c
+++ linux-2.6/kernel/stop_machine.c
@@ -336,7 +336,7 @@ static struct smp_hotplug_thread cpu_sto
 	.create			= cpu_stop_create,
 	.setup			= cpu_stop_unpark,
 	.park			= cpu_stop_park,
-	.unpark			= cpu_stop_unpark,
+	.pre_unpark		= cpu_stop_unpark,
 	.selfparking		= true,
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:44:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:44: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 1UAOa1-00066X-Cb; Tue, 26 Feb 2013 17:44:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tglx@linutronix.de>) id 1UAOa0-00066M-Jq
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:44:40 +0000
Received: from [85.158.139.83:57217] by server-14.bemta-5.messagelabs.com id
	43/17-13158-784FC215; Tue, 26 Feb 2013 17:44:39 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361900675!29107362!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_32,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24177 invoked from network); 26 Feb 2013 17:44:35 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:44:35 -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 1UAOZu-0006Ic-Nc; Tue, 26 Feb 2013 18:44:34 +0100
Date: Tue, 26 Feb 2013 18:44:33 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <894977724.20130226140702@eikelenboom.it>
Message-ID: <alpine.LFD.2.02.1302261843240.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.com>
	<alpine.LFD.2.02.1302261320120.22263@ionos>
	<894977724.20130226140702@eikelenboom.it>
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: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regression introduced with
 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot
 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, 26 Feb 2013, Sander Eikelenboom wrote:
> Tuesday, February 26, 2013, 1:36:36 PM, you wrote:
> > On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> >> 
> >> I don't know if this is b/c the Xen code is missing something or
> >> expects something that never happend. I hadn't looked at your
> >> patch in any detail (was going to do that on Monday).
> >> 
> >> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
> 
> Hmm i'm seeing this booting on baremetal as well.
> (see http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00836.html)

Ok. I decoded it with the help of Konrad. Does the patch below work
for you as well?

Thanks,

	tglx

Index: linux-2.6/include/linux/smpboot.h
===================================================================
--- linux-2.6.orig/include/linux/smpboot.h
+++ linux-2.6/include/linux/smpboot.h
@@ -24,6 +24,9 @@ struct smpboot_thread_data;
  *			parked (cpu offline)
  * @unpark:		Optional unpark function, called when the thread is
  *			unparked (cpu online)
+ * @pre_unpark:		Optional unpark function, called before the thread is
+ *			unparked (cpu online). This is not guaranteed to be
+ *			called on the target cpu of the thread. Careful!
  * @selfparking:	Thread is not parked by the park function.
  * @thread_comm:	The base name of the thread
  */
@@ -37,6 +40,7 @@ struct smp_hotplug_thread {
 	void				(*cleanup)(unsigned int cpu, bool online);
 	void				(*park)(unsigned int cpu);
 	void				(*unpark)(unsigned int cpu);
+	void				(*pre_unpark)(unsigned int cpu);
 	bool				selfparking;
 	const char			*thread_comm;
 };
Index: linux-2.6/kernel/smpboot.c
===================================================================
--- linux-2.6.orig/kernel/smpboot.c
+++ linux-2.6/kernel/smpboot.c
@@ -209,6 +209,8 @@ static void smpboot_unpark_thread(struct
 {
 	struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
 
+	if (ht->pre_unpark)
+		ht->pre_unpark(cpu);
 	kthread_unpark(tsk);
 }
 
Index: linux-2.6/kernel/stop_machine.c
===================================================================
--- linux-2.6.orig/kernel/stop_machine.c
+++ linux-2.6/kernel/stop_machine.c
@@ -336,7 +336,7 @@ static struct smp_hotplug_thread cpu_sto
 	.create			= cpu_stop_create,
 	.setup			= cpu_stop_unpark,
 	.park			= cpu_stop_park,
-	.unpark			= cpu_stop_unpark,
+	.pre_unpark		= cpu_stop_unpark,
 	.selfparking		= true,
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:46:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAObc-0006U6-38; Tue, 26 Feb 2013 17:46:20 +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 1UAOba-0006Tp-CD
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:46:18 +0000
Received: from [193.109.254.147:21752] by server-14.bemta-14.messagelabs.com
	id 1D/A8-02031-9E4FC215; Tue, 26 Feb 2013 17:46:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361900770!9765860!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15821 invoked from network); 26 Feb 2013 17:46:11 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:46:11 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:57178 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 1UAOZP-00080A-7z; Tue, 26 Feb 2013 18:44:03 +0100
Date: Tue, 26 Feb 2013 18:46:05 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1164014103.20130226184605@eikelenboom.it>
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226172009.GF93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
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>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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


Tuesday, February 26, 2013, 6:20:09 PM, you wrote:

> At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
>> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
>> > Speaking as its author, I know what the objective is: to unpack what
>> > 'make install' would do, and remove it again afterwards.  The fact that
>> > it uses a .deb package for that is unfortunate, because it leads people
>> > to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
>> > manifest for uninstalling.
>> 
>> I think we should fix this problem by improving the documentation.
>> 
>> From a technical point of view, a .deb is definitely the right thing.
>> 
>> And I do think that there is a plausible argument that the config
>> files ought not to be just blatted over the top of your system.  (If
>> "make install" does that then there's the same argument there - I
>> don't think "make install" should trash existing config.)

> AFAIK 'make install' does; certainly some room for improvement in that
> are.  In 'make deb' treating config files as normal data is deliberate.
> I don't want remnants of old tests contaminating my new install - that
> was the whole point.

Would a option to ./configure to enable/disable the install of config and initfiles on make install (or a seperate build target for config files) make sense ?

--
Sander


> Tim.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:46:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAObc-0006U6-38; Tue, 26 Feb 2013 17:46:20 +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 1UAOba-0006Tp-CD
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:46:18 +0000
Received: from [193.109.254.147:21752] by server-14.bemta-14.messagelabs.com
	id 1D/A8-02031-9E4FC215; Tue, 26 Feb 2013 17:46:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361900770!9765860!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15821 invoked from network); 26 Feb 2013 17:46:11 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 17:46:11 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:57178 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 1UAOZP-00080A-7z; Tue, 26 Feb 2013 18:44:03 +0100
Date: Tue, 26 Feb 2013 18:46:05 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1164014103.20130226184605@eikelenboom.it>
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20130226172009.GF93966@ocelot.phlegethon.org>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
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>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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


Tuesday, February 26, 2013, 6:20:09 PM, you wrote:

> At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
>> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
>> > Speaking as its author, I know what the objective is: to unpack what
>> > 'make install' would do, and remove it again afterwards.  The fact that
>> > it uses a .deb package for that is unfortunate, because it leads people
>> > to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
>> > manifest for uninstalling.
>> 
>> I think we should fix this problem by improving the documentation.
>> 
>> From a technical point of view, a .deb is definitely the right thing.
>> 
>> And I do think that there is a plausible argument that the config
>> files ought not to be just blatted over the top of your system.  (If
>> "make install" does that then there's the same argument there - I
>> don't think "make install" should trash existing config.)

> AFAIK 'make install' does; certainly some room for improvement in that
> are.  In 'make deb' treating config files as normal data is deliberate.
> I don't want remnants of old tests contaminating my new install - that
> was the whole point.

Would a option to ./configure to enable/disable the install of config and initfiles on make install (or a seperate build target for config files) make sense ?

--
Sander


> Tim.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:49:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:49: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 1UAOeC-0006nX-Np; Tue, 26 Feb 2013 17:49: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 1UAOeA-0006nJ-No
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:48:58 +0000
Received: from [85.158.139.211:12048] by server-2.bemta-5.messagelabs.com id
	EC/5A-23989-985FC215; Tue, 26 Feb 2013 17:48:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361900937!19212060!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31315 invoked from network); 26 Feb 2013 17:48:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:48:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:48: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.297.1; Tue, 26 Feb 2013 17:48:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOe8-0000IC-TC; Tue, 26 Feb 2013 17:48:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOe8-0002a5-PG;
	Tue, 26 Feb 2013 17:48:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62856.681142.29523@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:48:56 +0000
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9f7e5ef02139a2e1844e.1361668187@localhost.localdomain>
References: <9f7e5ef02139a2e1844e.1361668187@localhost.localdomain>
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: Fix not initialized variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Marek Marczykowski writes ("[Xen-devel] [PATCH] libxl: Fix not initialized variable"):
> libxl: Fix not initialized variable
> 
> It is used for result domid from libxl__domain_make, but actually this function
> have assert on an initial value.
> 
> This patch is intended for xen-4.1 only - 4.2 and later have reworked this
> part of code already containing the fix.

Applied to 4.1-staging, 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 Feb 26 17:49:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:49: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 1UAOeC-0006nX-Np; Tue, 26 Feb 2013 17:49: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 1UAOeA-0006nJ-No
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 17:48:58 +0000
Received: from [85.158.139.211:12048] by server-2.bemta-5.messagelabs.com id
	EC/5A-23989-985FC215; Tue, 26 Feb 2013 17:48:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361900937!19212060!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31315 invoked from network); 26 Feb 2013 17:48:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:48:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:48: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.297.1; Tue, 26 Feb 2013 17:48:56 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOe8-0000IC-TC; Tue, 26 Feb 2013 17:48:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOe8-0002a5-PG;
	Tue, 26 Feb 2013 17:48:56 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62856.681142.29523@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:48:56 +0000
To: Marek Marczykowski <marmarek@invisiblethingslab.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9f7e5ef02139a2e1844e.1361668187@localhost.localdomain>
References: <9f7e5ef02139a2e1844e.1361668187@localhost.localdomain>
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: Fix not initialized variable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Marek Marczykowski writes ("[Xen-devel] [PATCH] libxl: Fix not initialized variable"):
> libxl: Fix not initialized variable
> 
> It is used for result domid from libxl__domain_make, but actually this function
> have assert on an initial value.
> 
> This patch is intended for xen-4.1 only - 4.2 and later have reworked this
> part of code already containing the fix.

Applied to 4.1-staging, 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 Feb 26 17:51:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOg5-0006vm-BA; Tue, 26 Feb 2013 17:50: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 1UAOg4-0006vf-5b
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:50:56 +0000
Received: from [85.158.139.83:22545] by server-9.bemta-5.messagelabs.com id
	10/2B-08547-FF5FC215; Tue, 26 Feb 2013 17:50:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361901054!29090042!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7632 invoked from network); 26 Feb 2013 17:50:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:50: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.297.1; Tue, 26 Feb 2013 17:50:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOfn-0000JF-3X; Tue, 26 Feb 2013 17:50:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOfm-0002aJ-VG;
	Tue, 26 Feb 2013 17:50:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62952.761357.405408@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:50:32 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1164014103.20130226184605@eikelenboom.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<1164014103.20130226184605@eikelenboom.it>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Would a option to ./configure to enable/disable the install of
> config and initfiles on make install (or a seperate build target for
> config files) make sense ?

No.  What this target needs is simplicitly and lack of argument.

I'd rather have a version that unconditionally overwrote things in
/etc than one with a bunch of knobs to twiddle in configure, or any of
the other exciting features proposed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:51:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOg5-0006vm-BA; Tue, 26 Feb 2013 17:50: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 1UAOg4-0006vf-5b
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:50:56 +0000
Received: from [85.158.139.83:22545] by server-9.bemta-5.messagelabs.com id
	10/2B-08547-FF5FC215; Tue, 26 Feb 2013 17:50:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361901054!29090042!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7632 invoked from network); 26 Feb 2013 17:50:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 17:50:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1914912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 17:50: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.297.1; Tue, 26 Feb 2013 17:50:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAOfn-0000JF-3X; Tue, 26 Feb 2013 17:50:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAOfm-0002aJ-VG;
	Tue, 26 Feb 2013 17:50:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20780.62952.761357.405408@mariner.uk.xensource.com>
Date: Tue, 26 Feb 2013 17:50:32 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1164014103.20130226184605@eikelenboom.it>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<1164014103.20130226184605@eikelenboom.it>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Subject: Re: [Xen-devel] [PATCH v2] 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

Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Would a option to ./configure to enable/disable the install of
> config and initfiles on make install (or a seperate build target for
> config files) make sense ?

No.  What this target needs is simplicitly and lack of argument.

I'd rather have a version that unconditionally overwrote things in
/etc than one with a bunch of knobs to twiddle in configure, or any of
the other exciting features proposed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:53:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOim-0007C0-Us; Tue, 26 Feb 2013 17:53:44 +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 1UAOil-0007Bs-PT
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:53:44 +0000
Received: from [85.158.137.99:17058] by server-9.bemta-3.messagelabs.com id
	90/01-09484-2A6FC215; Tue, 26 Feb 2013 17:53:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361901215!12582739!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17300 invoked from network); 26 Feb 2013 17:53:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:53:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QHrTWZ032220
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:53:30 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
	r1QHrTvE013629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:53:29 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
	r1QHrTeS021013; Tue, 26 Feb 2013 11:53:29 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:53:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8C9AC1C3935; Tue, 26 Feb 2013 12:53:27 -0500 (EST)
Date: Tue, 26 Feb 2013 12:53:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130226175327.GA21952@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
	<512CECCE.3070305@canonical.com>
	<20130226174313.GC23731@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130226174313.GC23731@phenom.dumpdata.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>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 12:43:13PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 06:11:42PM +0100, Stefan Bader wrote:
> > On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
> > >> On 25.02.2013 10:10, Stefan Bader wrote:
> > >>> On 25.02.2013 04:15, Liu, Jinsong wrote:
> > >>>> Konrad Rzeszutek Wilk wrote:
> > >>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> > >>>>>> Hi Konrad,
> > >>>>>
> > >>>>> Hey Stefan,
> > >>>>>>
> > >>>>>> here is another one from the hm-what? department:
> > >>>>>
> > >>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> > >>>>> he has been tracking a similar one with mcelog.
> > >>>>>>
> > >>>>>> Colin discovered that running the attached program with the fork
> > >>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
> > >>>>>> iomem) this triggers the following weird messages: 
> > >>>>>>
> > >>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
> > >>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
> > >>>>>> [ 6824.453776] ------------[ cut here ]------------
> > >>>>>> [ 6824.453796] WARNING: at
> > >>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> > >>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
> > >>>>>> mmap-example Tainted: GF 
> > >>>>>> 3.8.0-6-generic #13-Ubuntu
> > >>>>>> [ 6824.453926] Call Trace:
> > >>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> > >>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> > >>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> > >>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> > >>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> > >>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> > >>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> > >>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> > >>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
> > >>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038] 
> > >>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048] 
> > >>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060] 
> > >>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069] 
> > >>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
> > >>>>>> ---[ end trace 4918cdd0a4c9fea4 ]--- 
> > >>>>>>
> > >>>>>> I found that this is related to your bandaid patch
> > >>>>>>
> > >>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> > >>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
> > >>>>>>
> > >>>>>>     xen/pat: Disable PAT support for now.
> > >>>>>>
> > >>>>>> I just do not understand how this happens. From the trace it seems
> > >>>>>> the fork 
> > >>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
> > >>>>>> maybe the 
> > >>>>>> warning is just related to this. So primarily the question is how on
> > >>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
> > >>>>>> cleared from the supported 
> > >>>>>> mask by the patch, so somehow I would think nothing should be able
> > >>>>>> to set it... 
> > >>>>>> But apparently not so.
> > >>>>>> Not sure it is a big deal since I never saw this in normal operation
> > >>>>>> and it 
> > >>>>>> seems to be ok when unapping before doing the fork. It is just plain
> > >>>>>> odd. 
> > >>>>>
> > >>>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> > >>>>> ranges are swapped or not correct. Jinsong, could you shed some light
> > >>>>> on what you have found so far?
> > >>>>>
> > >>>>
> > >>>> Yes, Sander once also reported a similar weird warning when start mcelog daemon, as attached.
> > >>>>
> > >>>> Basically, it occurs when mcelog user daemon start, 
> > >>>> do_fork
> > >>>>   --> copy_process
> > >>>>     --> dup_mm
> > >>>>       --> dup_mmap
> > >>>>         --> copy_page_range
> > >>>>           --> track_pfn_copy
> > >>>>             --> reserve_pfn_range
> > >>
> > >> So that makes it clearer as this will do
> > >>
> > >> reserve_memtype(...)
> > >> --> pat_x_mtrr_type
> > >>   --> mtrr_type_lookup
> > >>     --> __mtrr_type_lookup
> > >>
> > >> And that can return -1/0xff in case of mtrr not being enabled/initialized. Which
> > >> is not the case (given there are no messages for it in dmesg). This is not equal
> > >> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
> > >>
> > >> It looks like the problem starts early in reserve_memtype:
> > >>
> > >>         if (!pat_enabled) {
> > >>                 /* This is identical to page table setting without PAT */
> > >>                 if (new_type) {
> > >>                         if (req_type == _PAGE_CACHE_WC)
> > >>                                 *new_type = _PAGE_CACHE_UC_MINUS;
> > >>                         else
> > >>                                 *new_type = req_type & _PAGE_CACHE_MASK;
> > >>                 }
> > >>                 return 0;
> > >>         }
> > >>
> > >> This would be what we want, but only clearing the PWT and PCD flags from the
> > >> supported flags is not changing pat_enabled (which is 1 when PAT support is
> > >> compiled into the kernel). Unfortunately the variable is local and since there
> > >> are not any messages about PAT in dmesg I would say pat_init() is not called
> > >> either. Which might be used to disable PAT support by clearing the CPU feature
> > >> flag.
> > > 
> > > Hm, so:
> > > 
> > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > index 39928d1..9ac70c5 100644
> > > --- a/arch/x86/xen/enlighten.c
> > > +++ b/arch/x86/xen/enlighten.c
> > > @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
> > >  
> > >         cpuid_leaf1_edx_mask =
> > >                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> > > +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
> > >                   (1 << X86_FEATURE_ACC));   /* thermal monitoring */
> > >  
> > >         if (!xen_initial_domain())
> > > 
> > > 
> > > 
> > > should do it right? Let me check on the troublesome machine I saw
> > > it.
> > > 
> > I could try it as well but somehow my reading of pat_init() is that if that
> > would have been called at all, there should be some message about PAT in dmesg.
> > And normal dom0 boots do not show anything.
> > 
> > It looks like pat_init only gets called from two places in mtrr code, and that
> > probably is not done in dom0 either. So clearing the feature is one step, but I
> > would think that also there needs to be a call to pat_init...
> 
> So how about this super-complex patch:
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 39928d1..c8e1c7b 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -67,6 +67,7 @@
>  #include <asm/hypervisor.h>
>  #include <asm/mwait.h>
>  #include <asm/pci_x86.h>
> +#include <asm/pat.h>
>  
>  #ifdef CONFIG_ACPI
>  #include <linux/acpi.h>
> @@ -1417,7 +1418,14 @@ asmlinkage void __init xen_start_kernel(void)
>  	 */
>  	acpi_numa = -1;
>  #endif
> -
> +#ifdef CONFIG_X86_PAT
> +	/*
> +	 * For right now disable the PAT. We should remove this once
> +	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> +	 * (xen/pat: Disable PAT support for now) is reverted.
> +	 */
> +	pat_enabled = 0;
> +#endif
>  	/* Don't do the full vcpu_info placement stuff until we have a
>  	   possible map and a non-dummy shared_info. */
>  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> 
> trying it out now.

Seems to work for me with the mcelog that kept on failing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:53:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOim-0007C0-Us; Tue, 26 Feb 2013 17:53:44 +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 1UAOil-0007Bs-PT
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:53:44 +0000
Received: from [85.158.137.99:17058] by server-9.bemta-3.messagelabs.com id
	90/01-09484-2A6FC215; Tue, 26 Feb 2013 17:53:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361901215!12582739!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17300 invoked from network); 26 Feb 2013 17:53:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 17:53:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QHrTWZ032220
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 17:53:30 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
	r1QHrTvE013629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 17:53:29 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
	r1QHrTeS021013; Tue, 26 Feb 2013 11:53:29 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 09:53:28 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8C9AC1C3935; Tue, 26 Feb 2013 12:53:27 -0500 (EST)
Date: Tue, 26 Feb 2013 12:53:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20130226175327.GA21952@phenom.dumpdata.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
	<512CECCE.3070305@canonical.com>
	<20130226174313.GC23731@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130226174313.GC23731@phenom.dumpdata.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>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 12:43:13PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 06:11:42PM +0100, Stefan Bader wrote:
> > On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
> > >> On 25.02.2013 10:10, Stefan Bader wrote:
> > >>> On 25.02.2013 04:15, Liu, Jinsong wrote:
> > >>>> Konrad Rzeszutek Wilk wrote:
> > >>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
> > >>>>>> Hi Konrad,
> > >>>>>
> > >>>>> Hey Stefan,
> > >>>>>>
> > >>>>>> here is another one from the hm-what? department:
> > >>>>>
> > >>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong as
> > >>>>> he has been tracking a similar one with mcelog.
> > >>>>>>
> > >>>>>> Colin discovered that running the attached program with the fork
> > >>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be that or
> > >>>>>> iomem) this triggers the following weird messages: 
> > >>>>>>
> > >>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
> > >>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
> > >>>>>> [ 6824.453776] ------------[ cut here ]------------
> > >>>>>> [ 6824.453796] WARNING: at
> > >>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
> > >>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
> > >>>>>> mmap-example Tainted: GF 
> > >>>>>> 3.8.0-6-generic #13-Ubuntu
> > >>>>>> [ 6824.453926] Call Trace:
> > >>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
> > >>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
> > >>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
> > >>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
> > >>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
> > >>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
> > >>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
> > >>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
> > >>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
> > >>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038] 
> > >>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048] 
> > >>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060] 
> > >>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069] 
> > >>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.454076]
> > >>>>>> ---[ end trace 4918cdd0a4c9fea4 ]--- 
> > >>>>>>
> > >>>>>> I found that this is related to your bandaid patch
> > >>>>>>
> > >>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> > >>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
> > >>>>>>
> > >>>>>>     xen/pat: Disable PAT support for now.
> > >>>>>>
> > >>>>>> I just do not understand how this happens. From the trace it seems
> > >>>>>> the fork 
> > >>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure). So
> > >>>>>> maybe the 
> > >>>>>> warning is just related to this. So primarily the question is how on
> > >>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
> > >>>>>> cleared from the supported 
> > >>>>>> mask by the patch, so somehow I would think nothing should be able
> > >>>>>> to set it... 
> > >>>>>> But apparently not so.
> > >>>>>> Not sure it is a big deal since I never saw this in normal operation
> > >>>>>> and it 
> > >>>>>> seems to be ok when unapping before doing the fork. It is just plain
> > >>>>>> odd. 
> > >>>>>
> > >>>>> Jinsong mentioned that there is some oddity with the MTRR. Somehow the
> > >>>>> ranges are swapped or not correct. Jinsong, could you shed some light
> > >>>>> on what you have found so far?
> > >>>>>
> > >>>>
> > >>>> Yes, Sander once also reported a similar weird warning when start mcelog daemon, as attached.
> > >>>>
> > >>>> Basically, it occurs when mcelog user daemon start, 
> > >>>> do_fork
> > >>>>   --> copy_process
> > >>>>     --> dup_mm
> > >>>>       --> dup_mmap
> > >>>>         --> copy_page_range
> > >>>>           --> track_pfn_copy
> > >>>>             --> reserve_pfn_range
> > >>
> > >> So that makes it clearer as this will do
> > >>
> > >> reserve_memtype(...)
> > >> --> pat_x_mtrr_type
> > >>   --> mtrr_type_lookup
> > >>     --> __mtrr_type_lookup
> > >>
> > >> And that can return -1/0xff in case of mtrr not being enabled/initialized. Which
> > >> is not the case (given there are no messages for it in dmesg). This is not equal
> > >> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
> > >>
> > >> It looks like the problem starts early in reserve_memtype:
> > >>
> > >>         if (!pat_enabled) {
> > >>                 /* This is identical to page table setting without PAT */
> > >>                 if (new_type) {
> > >>                         if (req_type == _PAGE_CACHE_WC)
> > >>                                 *new_type = _PAGE_CACHE_UC_MINUS;
> > >>                         else
> > >>                                 *new_type = req_type & _PAGE_CACHE_MASK;
> > >>                 }
> > >>                 return 0;
> > >>         }
> > >>
> > >> This would be what we want, but only clearing the PWT and PCD flags from the
> > >> supported flags is not changing pat_enabled (which is 1 when PAT support is
> > >> compiled into the kernel). Unfortunately the variable is local and since there
> > >> are not any messages about PAT in dmesg I would say pat_init() is not called
> > >> either. Which might be used to disable PAT support by clearing the CPU feature
> > >> flag.
> > > 
> > > Hm, so:
> > > 
> > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > index 39928d1..9ac70c5 100644
> > > --- a/arch/x86/xen/enlighten.c
> > > +++ b/arch/x86/xen/enlighten.c
> > > @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
> > >  
> > >         cpuid_leaf1_edx_mask =
> > >                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> > > +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
> > >                   (1 << X86_FEATURE_ACC));   /* thermal monitoring */
> > >  
> > >         if (!xen_initial_domain())
> > > 
> > > 
> > > 
> > > should do it right? Let me check on the troublesome machine I saw
> > > it.
> > > 
> > I could try it as well but somehow my reading of pat_init() is that if that
> > would have been called at all, there should be some message about PAT in dmesg.
> > And normal dom0 boots do not show anything.
> > 
> > It looks like pat_init only gets called from two places in mtrr code, and that
> > probably is not done in dom0 either. So clearing the feature is one step, but I
> > would think that also there needs to be a call to pat_init...
> 
> So how about this super-complex patch:
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 39928d1..c8e1c7b 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -67,6 +67,7 @@
>  #include <asm/hypervisor.h>
>  #include <asm/mwait.h>
>  #include <asm/pci_x86.h>
> +#include <asm/pat.h>
>  
>  #ifdef CONFIG_ACPI
>  #include <linux/acpi.h>
> @@ -1417,7 +1418,14 @@ asmlinkage void __init xen_start_kernel(void)
>  	 */
>  	acpi_numa = -1;
>  #endif
> -
> +#ifdef CONFIG_X86_PAT
> +	/*
> +	 * For right now disable the PAT. We should remove this once
> +	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> +	 * (xen/pat: Disable PAT support for now) is reverted.
> +	 */
> +	pat_enabled = 0;
> +#endif
>  	/* Don't do the full vcpu_info placement stuff until we have a
>  	   possible map and a non-dummy shared_info. */
>  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> 
> trying it out now.

Seems to work for me with the mcelog that kept on failing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:57:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOlv-0007LK-MQ; Tue, 26 Feb 2013 17:56:59 +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 1UAOlt-0007LC-QP
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:56:58 +0000
Received: from [85.158.138.51:20300] by server-2.bemta-3.messagelabs.com id
	EA/0D-25961-467FC215; Tue, 26 Feb 2013 17:56:52 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361901406!28262125!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31143 invoked from network); 26 Feb 2013 17:56:46 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-174.messagelabs.com with SMTP;
	26 Feb 2013 17:56:46 -0000
Received: from p5b2e1b98.dip.t-dialin.net ([91.46.27.152] 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 1UAOlg-0005kn-14; Tue, 26 Feb 2013 17:56:44 +0000
Message-ID: <512CF759.1010503@canonical.com>
Date: Tue, 26 Feb 2013 18:56:41 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
	<512CECCE.3070305@canonical.com>
	<20130226174313.GC23731@phenom.dumpdata.com>
	<20130226175327.GA21952@phenom.dumpdata.com>
In-Reply-To: <20130226175327.GA21952@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.6
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1902807241865819900=="
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)
--===============1902807241865819900==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig25DFEBF830B8867C67C7D171"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig25DFEBF830B8867C67C7D171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26.02.2013 18:53, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 12:43:13PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Feb 26, 2013 at 06:11:42PM +0100, Stefan Bader wrote:
>>> On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
>>>> On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
>>>>> On 25.02.2013 10:10, Stefan Bader wrote:
>>>>>> On 25.02.2013 04:15, Liu, Jinsong wrote:
>>>>>>> Konrad Rzeszutek Wilk wrote:
>>>>>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>>>>>>>> Hi Konrad,
>>>>>>>>
>>>>>>>> Hey Stefan,
>>>>>>>>>
>>>>>>>>> here is another one from the hm-what? department:
>>>>>>>>
>>>>>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong=
 as
>>>>>>>> he has been tracking a similar one with mcelog.
>>>>>>>>>
>>>>>>>>> Colin discovered that running the attached program with the for=
k
>>>>>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be th=
at or
>>>>>>>>> iomem) this triggers the following weird messages:=20
>>>>>>>>>
>>>>>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>>>>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>>>>>>>> [ 6824.453776] ------------[ cut here ]------------
>>>>>>>>> [ 6824.453796] WARNING: at
>>>>>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>>>>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>>>>>>>> mmap-example Tainted: GF=20
>>>>>>>>> 3.8.0-6-generic #13-Ubuntu
>>>>>>>>> [ 6824.453926] Call Trace:
>>>>>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/=
0xc0
>>>>>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x=
20
>>>>>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>>>>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x10=
0
>>>>>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>>>>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>>>>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>>>>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>>>>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>>>>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>>>>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>>>>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>>>>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>>>>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.45=
4076]
>>>>>>>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>>>>>>>
>>>>>>>>> I found that this is related to your bandaid patch
>>>>>>>>>
>>>>>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>>>>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>>>>>>>
>>>>>>>>>     xen/pat: Disable PAT support for now.
>>>>>>>>>
>>>>>>>>> I just do not understand how this happens. From the trace it se=
ems
>>>>>>>>> the fork=20
>>>>>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure)=
=2E So
>>>>>>>>> maybe the=20
>>>>>>>>> warning is just related to this. So primarily the question is h=
ow on
>>>>>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>>>>>>>> cleared from the supported=20
>>>>>>>>> mask by the patch, so somehow I would think nothing should be a=
ble
>>>>>>>>> to set it...=20
>>>>>>>>> But apparently not so.
>>>>>>>>> Not sure it is a big deal since I never saw this in normal oper=
ation
>>>>>>>>> and it=20
>>>>>>>>> seems to be ok when unapping before doing the fork. It is just =
plain
>>>>>>>>> odd.=20
>>>>>>>>
>>>>>>>> Jinsong mentioned that there is some oddity with the MTRR. Someh=
ow the
>>>>>>>> ranges are swapped or not correct. Jinsong, could you shed some =
light
>>>>>>>> on what you have found so far?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, Sander once also reported a similar weird warning when start=
 mcelog daemon, as attached.
>>>>>>>
>>>>>>> Basically, it occurs when mcelog user daemon start,=20
>>>>>>> do_fork
>>>>>>>   --> copy_process
>>>>>>>     --> dup_mm
>>>>>>>       --> dup_mmap
>>>>>>>         --> copy_page_range
>>>>>>>           --> track_pfn_copy
>>>>>>>             --> reserve_pfn_range
>>>>>
>>>>> So that makes it clearer as this will do
>>>>>
>>>>> reserve_memtype(...)
>>>>> --> pat_x_mtrr_type
>>>>>   --> mtrr_type_lookup
>>>>>     --> __mtrr_type_lookup
>>>>>
>>>>> And that can return -1/0xff in case of mtrr not being enabled/initi=
alized. Which
>>>>> is not the case (given there are no messages for it in dmesg). This=
 is not equal
>>>>> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
>>>>>
>>>>> It looks like the problem starts early in reserve_memtype:
>>>>>
>>>>>         if (!pat_enabled) {
>>>>>                 /* This is identical to page table setting without =
PAT */
>>>>>                 if (new_type) {
>>>>>                         if (req_type =3D=3D _PAGE_CACHE_WC)
>>>>>                                 *new_type =3D _PAGE_CACHE_UC_MINUS;=

>>>>>                         else
>>>>>                                 *new_type =3D req_type & _PAGE_CACH=
E_MASK;
>>>>>                 }
>>>>>                 return 0;
>>>>>         }
>>>>>
>>>>> This would be what we want, but only clearing the PWT and PCD flags=
 from the
>>>>> supported flags is not changing pat_enabled (which is 1 when PAT su=
pport is
>>>>> compiled into the kernel). Unfortunately the variable is local and =
since there
>>>>> are not any messages about PAT in dmesg I would say pat_init() is n=
ot called
>>>>> either. Which might be used to disable PAT support by clearing the =
CPU feature
>>>>> flag.
>>>>
>>>> Hm, so:
>>>>
>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>>> index 39928d1..9ac70c5 100644
>>>> --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
>>>> =20
>>>>         cpuid_leaf1_edx_mask =3D
>>>>                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>>>> +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
>>>>                   (1 << X86_FEATURE_ACC));   /* thermal monitoring *=
/
>>>> =20
>>>>         if (!xen_initial_domain())
>>>>
>>>>
>>>>
>>>> should do it right? Let me check on the troublesome machine I saw
>>>> it.
>>>>
>>> I could try it as well but somehow my reading of pat_init() is that i=
f that
>>> would have been called at all, there should be some message about PAT=
 in dmesg.
>>> And normal dom0 boots do not show anything.
>>>
>>> It looks like pat_init only gets called from two places in mtrr code,=
 and that
>>> probably is not done in dom0 either. So clearing the feature is one s=
tep, but I
>>> would think that also there needs to be a call to pat_init...
>>
>> So how about this super-complex patch:
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 39928d1..c8e1c7b 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -67,6 +67,7 @@
>>  #include <asm/hypervisor.h>
>>  #include <asm/mwait.h>
>>  #include <asm/pci_x86.h>
>> +#include <asm/pat.h>
>> =20
>>  #ifdef CONFIG_ACPI
>>  #include <linux/acpi.h>
>> @@ -1417,7 +1418,14 @@ asmlinkage void __init xen_start_kernel(void)
>>  	 */
>>  	acpi_numa =3D -1;
>>  #endif
>> -
>> +#ifdef CONFIG_X86_PAT
>> +	/*
>> +	 * For right now disable the PAT. We should remove this once
>> +	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>> +	 * (xen/pat: Disable PAT support for now) is reverted.
>> +	 */
>> +	pat_enabled =3D 0;
>> +#endif
>>  	/* Don't do the full vcpu_info placement stuff until we have a
>>  	   possible map and a non-dummy shared_info. */
>>  	per_cpu(xen_vcpu, 0) =3D &HYPERVISOR_shared_info->vcpu_info[0];
>>
>> trying it out now.
>=20
> Seems to work for me with the mcelog that kept on failing.
>=20
Yeah, would need to compile it but that looks to be a good solution. Some=
what
missed the fact that pat_enabled is actually exported in pat.h. Sometimes=
 the
obvious is so blanked out. :-P

-Stefan


--------------enig25DFEBF830B8867C67C7D171
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLPdaAAoJEOhnXe7L7s6jk7sQAJkFKBON0hna3EHocDoHrkQe
0GL31GIpGK7eUSt+WsiYOyZyEGDIBnrORqgrQ8O7CYoI1T+8I/oHiIHzKaAim3o1
AK/kFCf/atyS3UjFaNADP8uwdUK+2FcVLvDLJXlATCZlnnvUtfQa1+vhN7qVDIOZ
fP7efVBHG4IttM8J7+VbJsf/5EUkwPh+Lh+uea2Vg8+XcKqN+4z0QaD3XsIYhifN
zhKGsb2RNGdvWvpxnQd+xJ9e2qTpsfhYAZtD8qY6yOuwkdKw3IMxgYCSUiCIHRey
ATUl2SEaCG9M9l4Xn449KOcF+qvjOMA0FXeXsaGtrM9rteo4wPo9Acv0R7v+UTAa
llpJ96K80TOjuMfOFnXCZaTLsHAFvw+ItsH5V9KI5QK7/HuSTicAQQ4UiZ6GErr8
7MaWqIBdlimXZHDTgfR7+VZX5jThwIgeBiVhpKp3ak1Duase7P+elCzuKP8kP/b3
y3jFc7Xy4QenCXizd7wMDY0kwS2p1XbTswlCohscq2uvAIYY5xH4ArRv3j/ZzEKp
peJA9VnMX+udXx+z+XJdTlgoM8fj5ofFl79cgmAT/OCnEEF8KVdRn4j4C67KGoXH
t7JpNlNwSthQ/IAuKYn4x2SkCrw4NaJnbjlfdW4mB3nPZvoTtnqZskKNH59NQ9ir
ImkoNEQKxA6z/dv+x2vC
=pLSU
-----END PGP SIGNATURE-----

--------------enig25DFEBF830B8867C67C7D171--


--===============1902807241865819900==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1902807241865819900==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:57:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17: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 1UAOlv-0007LK-MQ; Tue, 26 Feb 2013 17:56:59 +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 1UAOlt-0007LC-QP
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:56:58 +0000
Received: from [85.158.138.51:20300] by server-2.bemta-3.messagelabs.com id
	EA/0D-25961-467FC215; Tue, 26 Feb 2013 17:56:52 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361901406!28262125!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31143 invoked from network); 26 Feb 2013 17:56:46 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-174.messagelabs.com with SMTP;
	26 Feb 2013 17:56:46 -0000
Received: from p5b2e1b98.dip.t-dialin.net ([91.46.27.152] 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 1UAOlg-0005kn-14; Tue, 26 Feb 2013 17:56:44 +0000
Message-ID: <512CF759.1010503@canonical.com>
Date: Tue, 26 Feb 2013 18:56:41 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <51277888.50908@canonical.com>
	<20130222145316.GB8017@phenom.dumpdata.com>
	<DE8DF0795D48FD4CA783C40EC82923354092DD@SHSMSX101.ccr.corp.intel.com>
	<512B2A7C.1050906@canonical.com> <512CD595.2000502@canonical.com>
	<20130226170330.GB22422@phenom.dumpdata.com>
	<512CECCE.3070305@canonical.com>
	<20130226174313.GC23731@phenom.dumpdata.com>
	<20130226175327.GA21952@phenom.dumpdata.com>
In-Reply-To: <20130226175327.GA21952@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.6
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>,
	Colin Ian King <colin.king@canonical.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] PATastic fun
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============1902807241865819900=="
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)
--===============1902807241865819900==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig25DFEBF830B8867C67C7D171"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig25DFEBF830B8867C67C7D171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26.02.2013 18:53, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 26, 2013 at 12:43:13PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Feb 26, 2013 at 06:11:42PM +0100, Stefan Bader wrote:
>>> On 26.02.2013 18:03, Konrad Rzeszutek Wilk wrote:
>>>> On Tue, Feb 26, 2013 at 04:32:37PM +0100, Stefan Bader wrote:
>>>>> On 25.02.2013 10:10, Stefan Bader wrote:
>>>>>> On 25.02.2013 04:15, Liu, Jinsong wrote:
>>>>>>> Konrad Rzeszutek Wilk wrote:
>>>>>>>> On Fri, Feb 22, 2013 at 02:54:16PM +0100, Stefan Bader wrote:
>>>>>>>>> Hi Konrad,
>>>>>>>>
>>>>>>>> Hey Stefan,
>>>>>>>>>
>>>>>>>>> here is another one from the hm-what? department:
>>>>>>>>
>>>>>>>> Heh - the really good-bug-hunting one. Lets also include Jinsong=
 as
>>>>>>>> he has been tracking a similar one with mcelog.
>>>>>>>>>
>>>>>>>>> Colin discovered that running the attached program with the for=
k
>>>>>>>>> active (e.g. "./mmap-example -f 0x10000", the address can be th=
at or
>>>>>>>>> iomem) this triggers the following weird messages:=20
>>>>>>>>>
>>>>>>>>> [ 6824.453724] mmap-example:3481 map pfn expected mapping type
>>>>>>>>> write-back for [mem 0x00010000-0x00010fff], got uncached-minus
>>>>>>>>> [ 6824.453776] ------------[ cut here ]------------
>>>>>>>>> [ 6824.453796] WARNING: at
>>>>>>>>> /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
>>>>>>>>> untrack_pfn+0xb8/0xd0() ... [ 6824.453920] Pid: 3481, comm:
>>>>>>>>> mmap-example Tainted: GF=20
>>>>>>>>> 3.8.0-6-generic #13-Ubuntu
>>>>>>>>> [ 6824.453926] Call Trace:
>>>>>>>>> [ 6824.453944]  [<ffffffff8105879f>] warn_slowpath_common+0x7f/=
0xc0
>>>>>>>>> [ 6824.453954]  [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x=
20
>>>>>>>>> [ 6824.453963]  [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
>>>>>>>>> [ 6824.453975]  [<ffffffff81156c1c>] unmap_single_vma+0xac/0x10=
0
>>>>>>>>> [ 6824.453985]  [<ffffffff81157459>] unmap_vmas+0x49/0x90
>>>>>>>>> [ 6824.453995]  [<ffffffff8115f808>] exit_mmap+0x98/0x170
>>>>>>>>> [ 6824.454007]  [<ffffffff810559a4>] mmput+0x64/0x100
>>>>>>>>> [ 6824.454017]  [<ffffffff810560f5>] dup_mm+0x445/0x660
>>>>>>>>> [ 6824.454027]  [<ffffffff81056d9f>]
>>>>>>>>> copy_process.part.22+0xa5f/0x1510 [ 6824.454038]=20
>>>>>>>>> [<ffffffff81057931>] do_fork+0x91/0x350 [ 6824.454048]=20
>>>>>>>>> [<ffffffff81057c76>] sys_clone+0x16/0x20 [ 6824.454060]=20
>>>>>>>>> [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [ 6824.454069]=20
>>>>>>>>> [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f [ 6824.45=
4076]
>>>>>>>>> ---[ end trace 4918cdd0a4c9fea4 ]---=20
>>>>>>>>>
>>>>>>>>> I found that this is related to your bandaid patch
>>>>>>>>>
>>>>>>>>> commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>>>>>>>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>>>>> Date:   Fri Feb 10 09:16:27 2012 -0500
>>>>>>>>>
>>>>>>>>>     xen/pat: Disable PAT support for now.
>>>>>>>>>
>>>>>>>>> I just do not understand how this happens. From the trace it se=
ems
>>>>>>>>> the fork=20
>>>>>>>>> fails when duplicating the VMAs (dup_mm calls mmput on failure)=
=2E So
>>>>>>>>> maybe the=20
>>>>>>>>> warning is just related to this. So primarily the question is h=
ow on
>>>>>>>>> fork the _PAGE_PCD bit can become set? That and _PAGE_PWT are
>>>>>>>>> cleared from the supported=20
>>>>>>>>> mask by the patch, so somehow I would think nothing should be a=
ble
>>>>>>>>> to set it...=20
>>>>>>>>> But apparently not so.
>>>>>>>>> Not sure it is a big deal since I never saw this in normal oper=
ation
>>>>>>>>> and it=20
>>>>>>>>> seems to be ok when unapping before doing the fork. It is just =
plain
>>>>>>>>> odd.=20
>>>>>>>>
>>>>>>>> Jinsong mentioned that there is some oddity with the MTRR. Someh=
ow the
>>>>>>>> ranges are swapped or not correct. Jinsong, could you shed some =
light
>>>>>>>> on what you have found so far?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, Sander once also reported a similar weird warning when start=
 mcelog daemon, as attached.
>>>>>>>
>>>>>>> Basically, it occurs when mcelog user daemon start,=20
>>>>>>> do_fork
>>>>>>>   --> copy_process
>>>>>>>     --> dup_mm
>>>>>>>       --> dup_mmap
>>>>>>>         --> copy_page_range
>>>>>>>           --> track_pfn_copy
>>>>>>>             --> reserve_pfn_range
>>>>>
>>>>> So that makes it clearer as this will do
>>>>>
>>>>> reserve_memtype(...)
>>>>> --> pat_x_mtrr_type
>>>>>   --> mtrr_type_lookup
>>>>>     --> __mtrr_type_lookup
>>>>>
>>>>> And that can return -1/0xff in case of mtrr not being enabled/initi=
alized. Which
>>>>> is not the case (given there are no messages for it in dmesg). This=
 is not equal
>>>>> to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
>>>>>
>>>>> It looks like the problem starts early in reserve_memtype:
>>>>>
>>>>>         if (!pat_enabled) {
>>>>>                 /* This is identical to page table setting without =
PAT */
>>>>>                 if (new_type) {
>>>>>                         if (req_type =3D=3D _PAGE_CACHE_WC)
>>>>>                                 *new_type =3D _PAGE_CACHE_UC_MINUS;=

>>>>>                         else
>>>>>                                 *new_type =3D req_type & _PAGE_CACH=
E_MASK;
>>>>>                 }
>>>>>                 return 0;
>>>>>         }
>>>>>
>>>>> This would be what we want, but only clearing the PWT and PCD flags=
 from the
>>>>> supported flags is not changing pat_enabled (which is 1 when PAT su=
pport is
>>>>> compiled into the kernel). Unfortunately the variable is local and =
since there
>>>>> are not any messages about PAT in dmesg I would say pat_init() is n=
ot called
>>>>> either. Which might be used to disable PAT support by clearing the =
CPU feature
>>>>> flag.
>>>>
>>>> Hm, so:
>>>>
>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>>> index 39928d1..9ac70c5 100644
>>>> --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -379,6 +379,7 @@ static void __init xen_init_cpuid_mask(void)
>>>> =20
>>>>         cpuid_leaf1_edx_mask =3D
>>>>                 ~((1 << X86_FEATURE_MTRR) |  /* disable MTRR */
>>>> +                 (1 << X86_FEATURE_PAT) |   /* disable PAT */
>>>>                   (1 << X86_FEATURE_ACC));   /* thermal monitoring *=
/
>>>> =20
>>>>         if (!xen_initial_domain())
>>>>
>>>>
>>>>
>>>> should do it right? Let me check on the troublesome machine I saw
>>>> it.
>>>>
>>> I could try it as well but somehow my reading of pat_init() is that i=
f that
>>> would have been called at all, there should be some message about PAT=
 in dmesg.
>>> And normal dom0 boots do not show anything.
>>>
>>> It looks like pat_init only gets called from two places in mtrr code,=
 and that
>>> probably is not done in dom0 either. So clearing the feature is one s=
tep, but I
>>> would think that also there needs to be a call to pat_init...
>>
>> So how about this super-complex patch:
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 39928d1..c8e1c7b 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -67,6 +67,7 @@
>>  #include <asm/hypervisor.h>
>>  #include <asm/mwait.h>
>>  #include <asm/pci_x86.h>
>> +#include <asm/pat.h>
>> =20
>>  #ifdef CONFIG_ACPI
>>  #include <linux/acpi.h>
>> @@ -1417,7 +1418,14 @@ asmlinkage void __init xen_start_kernel(void)
>>  	 */
>>  	acpi_numa =3D -1;
>>  #endif
>> -
>> +#ifdef CONFIG_X86_PAT
>> +	/*
>> +	 * For right now disable the PAT. We should remove this once
>> +	 * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
>> +	 * (xen/pat: Disable PAT support for now) is reverted.
>> +	 */
>> +	pat_enabled =3D 0;
>> +#endif
>>  	/* Don't do the full vcpu_info placement stuff until we have a
>>  	   possible map and a non-dummy shared_info. */
>>  	per_cpu(xen_vcpu, 0) =3D &HYPERVISOR_shared_info->vcpu_info[0];
>>
>> trying it out now.
>=20
> Seems to work for me with the mcelog that kept on failing.
>=20
Yeah, would need to compile it but that looks to be a good solution. Some=
what
missed the fact that pat_enabled is actually exported in pat.h. Sometimes=
 the
obvious is so blanked out. :-P

-Stefan


--------------enig25DFEBF830B8867C67C7D171
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLPdaAAoJEOhnXe7L7s6jk7sQAJkFKBON0hna3EHocDoHrkQe
0GL31GIpGK7eUSt+WsiYOyZyEGDIBnrORqgrQ8O7CYoI1T+8I/oHiIHzKaAim3o1
AK/kFCf/atyS3UjFaNADP8uwdUK+2FcVLvDLJXlATCZlnnvUtfQa1+vhN7qVDIOZ
fP7efVBHG4IttM8J7+VbJsf/5EUkwPh+Lh+uea2Vg8+XcKqN+4z0QaD3XsIYhifN
zhKGsb2RNGdvWvpxnQd+xJ9e2qTpsfhYAZtD8qY6yOuwkdKw3IMxgYCSUiCIHRey
ATUl2SEaCG9M9l4Xn449KOcF+qvjOMA0FXeXsaGtrM9rteo4wPo9Acv0R7v+UTAa
llpJ96K80TOjuMfOFnXCZaTLsHAFvw+ItsH5V9KI5QK7/HuSTicAQQ4UiZ6GErr8
7MaWqIBdlimXZHDTgfR7+VZX5jThwIgeBiVhpKp3ak1Duase7P+elCzuKP8kP/b3
y3jFc7Xy4QenCXizd7wMDY0kwS2p1XbTswlCohscq2uvAIYY5xH4ArRv3j/ZzEKp
peJA9VnMX+udXx+z+XJdTlgoM8fj5ofFl79cgmAT/OCnEEF8KVdRn4j4C67KGoXH
t7JpNlNwSthQ/IAuKYn4x2SkCrw4NaJnbjlfdW4mB3nPZvoTtnqZskKNH59NQ9ir
ImkoNEQKxA6z/dv+x2vC
=pLSU
-----END PGP SIGNATURE-----

--------------enig25DFEBF830B8867C67C7D171--


--===============1902807241865819900==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1902807241865819900==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 17:58:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:58: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 1UAOmx-0007Q1-HL; Tue, 26 Feb 2013 17:58:03 +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 1UAOmw-0007Po-8q
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:58:02 +0000
Received: from [193.109.254.147:27357] by server-10.bemta-14.messagelabs.com
	id CE/C4-12679-9A7FC215; Tue, 26 Feb 2013 17:58:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361901479!9040038!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21378 invoked from network); 26 Feb 2013 17:58:00 -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;
	26 Feb 2013 17:58:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9290798"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:57:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:57:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAOms-0000u7-Ks;
	Tue, 26 Feb 2013 17:57:58 +0000
Date: Tue, 26 Feb 2013 17:57:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20780.62363.486434.797437@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > Maybe we should produce a tgz instead (plain or Slackware style).
> 
> This fails to solve the problem Tim was trying to solve, which is
> to make it easy to remove previous versions.

That is true.
However Slackware can install and remove them (even though I understand
not many people are going to benefit from it).
alien can convert those tgz into a deb or an rpm. Overall it certainly
wouldn't be an improvement for Debian users, but after all they are not
the target anyway.


> > I wouldn't want to create wrong expectations: it is better to build no
> > packages than building "broken" packages. (Of course I still think the
> > best choice would be to produce good packages.)
> 
> I think we can engage in better expectations management.  Perhaps we
> could rename the target.

Right, that would be a step forward. Something that make it clear that
it isn't a proper deb. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 17:58:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 17:58: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 1UAOmx-0007Q1-HL; Tue, 26 Feb 2013 17:58:03 +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 1UAOmw-0007Po-8q
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 17:58:02 +0000
Received: from [193.109.254.147:27357] by server-10.bemta-14.messagelabs.com
	id CE/C4-12679-9A7FC215; Tue, 26 Feb 2013 17:58:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1361901479!9040038!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQyNTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21378 invoked from network); 26 Feb 2013 17:58:00 -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;
	26 Feb 2013 17:58:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="9290798"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	26 Feb 2013 17:57:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 26 Feb 2013 12:57:59 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAOms-0000u7-Ks;
	Tue, 26 Feb 2013 17:57:58 +0000
Date: Tue, 26 Feb 2013 17:57:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20780.62363.486434.797437@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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, 26 Feb 2013, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > Maybe we should produce a tgz instead (plain or Slackware style).
> 
> This fails to solve the problem Tim was trying to solve, which is
> to make it easy to remove previous versions.

That is true.
However Slackware can install and remove them (even though I understand
not many people are going to benefit from it).
alien can convert those tgz into a deb or an rpm. Overall it certainly
wouldn't be an improvement for Debian users, but after all they are not
the target anyway.


> > I wouldn't want to create wrong expectations: it is better to build no
> > packages than building "broken" packages. (Of course I still think the
> > best choice would be to produce good packages.)
> 
> I think we can engage in better expectations management.  Perhaps we
> could rename the target.

Right, that would be a step forward. Something that make it clear that
it isn't a proper deb. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 18:04:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 18:04: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 1UAOtC-0007nH-DJ; Tue, 26 Feb 2013 18:04:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Robert.VanVossen@dornerworks.com>)
	id 1UAOtA-0007nC-Nn
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 18:04:28 +0000
Received: from [193.109.254.147:33805] by server-16.bemta-14.messagelabs.com
	id AD/52-25906-C29FC215; Tue, 26 Feb 2013 18:04:28 +0000
X-Env-Sender: Robert.VanVossen@dornerworks.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361901831!9132793!1
X-Originating-IP: [12.207.209.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1272 invoked from network); 26 Feb 2013 18:03:52 -0000
Received: from unknown (HELO mail.dornerworks.com) (12.207.209.148)
	by server-4.tower-27.messagelabs.com with SMTP;
	26 Feb 2013 18:03:52 -0000
Received: from QUIMBY.dw.local ([::1]) by Quimby.dw.local ([::1]) with mapi id
	14.02.0247.003; Tue, 26 Feb 2013 13:03:50 -0500
From: Robert VanVossen <Robert.VanVossen@dornerworks.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] Incorrect Prototypes
Thread-Index: Ac4ULOFJODTAtcbUQ3SXitaluNGGUAAN1uKAAAYp0UA=
Date: Tue, 26 Feb 2013 18:03:49 +0000
Message-ID: <30A36F55D047B4489EC149857F230F426DAF5A19@Quimby.dw.local>
References: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
	<512CEA0F02000078000C1261@nat28.tlf.novell.com>
In-Reply-To: <512CEA0F02000078000C1261@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.27.12.29]
Content-Type: multipart/mixed;
	boundary="_002_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Incorrect Prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Patch is attached.

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com]=20
Sent: Tuesday, February 26, 2013 11:00 AM
To: Robert VanVossen
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Incorrect Prototypes

>>> On 26.02.13 at 15:23, Robert VanVossen <Robert.VanVossen@dornerworks.co=
m> wrote:
> do_kexec_op and compat_set_timer_op are both prototyped in=20
> xen/include/xen/hypercall.h, but are different than their implemented=20
> functions. This appears to be a bug.

Care to send a patch?

Jan

> do_kexec_op:
> xen/common/kexec.c: 889
> long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg) {
>     return do_kexec_op_internal(op, uarg, 0); }
>=20
> xen/include/xen/hypercall.h: 126
> extern long
> do_kexec_op(
>     unsigned long op,
>     int arg1,
>     XEN_GUEST_HANDLE(void) arg);
>=20
>=20
>=20
> compat_set_timer_op:
> xen/common/compat/schedule.c: 38
> int compat_set_timer_op(u32 lo, s32 hi) {
>     return do_set_timer_op(((s64)hi << 32) | lo); }
>=20
> xen/include/xen/hypercall.h:175
> extern int
> compat_set_timer_op(
>     s_time_t timeout);
>=20
> Thanks,
> Robbie VanVossen




--_002_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_
Content-Type: application/octet-stream; name="hypercall_prototypes.patch"
Content-Description: hypercall_prototypes.patch
Content-Disposition: attachment; filename="hypercall_prototypes.patch";
	size=758; creation-date="Tue, 26 Feb 2013 18:02:33 GMT";
	modification-date="Tue, 26 Feb 2013 18:02:33 GMT"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgNjZmNTYzYmU0MWQ5MGI0ODBlYjk5ZTNlODQy
ZDRlOWFiMjYwODYxYwpDaGFuZ2VkIGFyZ3VtZW50cyBvZiBkb19rZXhlY19vcCBhbmQgY29tcGF0
X3NldF90aW1lcl9vcCBwcm90b3R5cGVzIHRvIG1hdGNoIHRoZSBhY3R1YWwgZnVuY3Rpb25zLgoK
U2lnbmVkLW9mZi1ieTogUm9iYmllIFZhblZvc3NlbiA8cm9iZXJ0LnZhbnZvc3NlbkBkb3JuZXJ3
b3Jrcy5jb20+CgpkaWZmIC1yIDY2ZjU2M2JlNDFkOSB4ZW4vaW5jbHVkZS94ZW4vaHlwZXJjYWxs
LmgKLS0tIGEveGVuL2luY2x1ZGUveGVuL2h5cGVyY2FsbC5oCVR1ZSBGZWIgMTkgMTA6NDk6NTMg
MjAxMyArMDEwMAorKysgYi94ZW4vaW5jbHVkZS94ZW4vaHlwZXJjYWxsLmgJVHVlIEZlYiAyNiAx
Mjo1ODo0MiAyMDEzIC0wNTAwCkBAIC0xMjYsOCArMTI2LDcgQEAgZG9faHZtX29wKAogZXh0ZXJu
IGxvbmcKIGRvX2tleGVjX29wKAogICAgIHVuc2lnbmVkIGxvbmcgb3AsCi0gICAgaW50IGFyZzEs
Ci0gICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpOworICAgIFhFTl9HVUVTVF9I
QU5ETEVfUEFSQU0odm9pZCkgdWFyZyk7CiAKIGV4dGVybiBsb25nCiBkb194c21fb3AoCkBAIC0x
NzQsNyArMTczLDggQEAgY29tcGF0X3NjaGVkX29wKAogCiBleHRlcm4gaW50CiBjb21wYXRfc2V0
X3RpbWVyX29wKAotICAgIHNfdGltZV90IHRpbWVvdXQpOworICAgIHUzMiBsbywKKyAgICBzMzIg
aGkpOwogCiAjZW5kaWYKIAo=

--_002_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_--


From xen-devel-bounces@lists.xen.org Tue Feb 26 18:04:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 18:04: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 1UAOtC-0007nH-DJ; Tue, 26 Feb 2013 18:04:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Robert.VanVossen@dornerworks.com>)
	id 1UAOtA-0007nC-Nn
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 18:04:28 +0000
Received: from [193.109.254.147:33805] by server-16.bemta-14.messagelabs.com
	id AD/52-25906-C29FC215; Tue, 26 Feb 2013 18:04:28 +0000
X-Env-Sender: Robert.VanVossen@dornerworks.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361901831!9132793!1
X-Originating-IP: [12.207.209.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1272 invoked from network); 26 Feb 2013 18:03:52 -0000
Received: from unknown (HELO mail.dornerworks.com) (12.207.209.148)
	by server-4.tower-27.messagelabs.com with SMTP;
	26 Feb 2013 18:03:52 -0000
Received: from QUIMBY.dw.local ([::1]) by Quimby.dw.local ([::1]) with mapi id
	14.02.0247.003; Tue, 26 Feb 2013 13:03:50 -0500
From: Robert VanVossen <Robert.VanVossen@dornerworks.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] Incorrect Prototypes
Thread-Index: Ac4ULOFJODTAtcbUQ3SXitaluNGGUAAN1uKAAAYp0UA=
Date: Tue, 26 Feb 2013 18:03:49 +0000
Message-ID: <30A36F55D047B4489EC149857F230F426DAF5A19@Quimby.dw.local>
References: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
	<512CEA0F02000078000C1261@nat28.tlf.novell.com>
In-Reply-To: <512CEA0F02000078000C1261@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [172.27.12.29]
Content-Type: multipart/mixed;
	boundary="_002_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Incorrect Prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Patch is attached.

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com]=20
Sent: Tuesday, February 26, 2013 11:00 AM
To: Robert VanVossen
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Incorrect Prototypes

>>> On 26.02.13 at 15:23, Robert VanVossen <Robert.VanVossen@dornerworks.co=
m> wrote:
> do_kexec_op and compat_set_timer_op are both prototyped in=20
> xen/include/xen/hypercall.h, but are different than their implemented=20
> functions. This appears to be a bug.

Care to send a patch?

Jan

> do_kexec_op:
> xen/common/kexec.c: 889
> long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg) {
>     return do_kexec_op_internal(op, uarg, 0); }
>=20
> xen/include/xen/hypercall.h: 126
> extern long
> do_kexec_op(
>     unsigned long op,
>     int arg1,
>     XEN_GUEST_HANDLE(void) arg);
>=20
>=20
>=20
> compat_set_timer_op:
> xen/common/compat/schedule.c: 38
> int compat_set_timer_op(u32 lo, s32 hi) {
>     return do_set_timer_op(((s64)hi << 32) | lo); }
>=20
> xen/include/xen/hypercall.h:175
> extern int
> compat_set_timer_op(
>     s_time_t timeout);
>=20
> Thanks,
> Robbie VanVossen




--_002_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_
Content-Type: application/octet-stream; name="hypercall_prototypes.patch"
Content-Description: hypercall_prototypes.patch
Content-Disposition: attachment; filename="hypercall_prototypes.patch";
	size=758; creation-date="Tue, 26 Feb 2013 18:02:33 GMT";
	modification-date="Tue, 26 Feb 2013 18:02:33 GMT"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgNjZmNTYzYmU0MWQ5MGI0ODBlYjk5ZTNlODQy
ZDRlOWFiMjYwODYxYwpDaGFuZ2VkIGFyZ3VtZW50cyBvZiBkb19rZXhlY19vcCBhbmQgY29tcGF0
X3NldF90aW1lcl9vcCBwcm90b3R5cGVzIHRvIG1hdGNoIHRoZSBhY3R1YWwgZnVuY3Rpb25zLgoK
U2lnbmVkLW9mZi1ieTogUm9iYmllIFZhblZvc3NlbiA8cm9iZXJ0LnZhbnZvc3NlbkBkb3JuZXJ3
b3Jrcy5jb20+CgpkaWZmIC1yIDY2ZjU2M2JlNDFkOSB4ZW4vaW5jbHVkZS94ZW4vaHlwZXJjYWxs
LmgKLS0tIGEveGVuL2luY2x1ZGUveGVuL2h5cGVyY2FsbC5oCVR1ZSBGZWIgMTkgMTA6NDk6NTMg
MjAxMyArMDEwMAorKysgYi94ZW4vaW5jbHVkZS94ZW4vaHlwZXJjYWxsLmgJVHVlIEZlYiAyNiAx
Mjo1ODo0MiAyMDEzIC0wNTAwCkBAIC0xMjYsOCArMTI2LDcgQEAgZG9faHZtX29wKAogZXh0ZXJu
IGxvbmcKIGRvX2tleGVjX29wKAogICAgIHVuc2lnbmVkIGxvbmcgb3AsCi0gICAgaW50IGFyZzEs
Ci0gICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpOworICAgIFhFTl9HVUVTVF9I
QU5ETEVfUEFSQU0odm9pZCkgdWFyZyk7CiAKIGV4dGVybiBsb25nCiBkb194c21fb3AoCkBAIC0x
NzQsNyArMTczLDggQEAgY29tcGF0X3NjaGVkX29wKAogCiBleHRlcm4gaW50CiBjb21wYXRfc2V0
X3RpbWVyX29wKAotICAgIHNfdGltZV90IHRpbWVvdXQpOworICAgIHUzMiBsbywKKyAgICBzMzIg
aGkpOwogCiAjZW5kaWYKIAo=

--_002_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_30A36F55D047B4489EC149857F230F426DAF5A19Quimbydwlocal_--


From xen-devel-bounces@lists.xen.org Tue Feb 26 19:33:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 19:33: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 1UAQH1-0000QL-Mz; Tue, 26 Feb 2013 19:33:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aliguori@us.ibm.com>) id 1UAQH0-0000QG-1d
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 19:33:10 +0000
Received: from [85.158.138.51:35707] by server-16.bemta-3.messagelabs.com id
	E6/39-02727-5FD0D215; Tue, 26 Feb 2013 19:33:09 +0000
X-Env-Sender: aliguori@us.ibm.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361907183!29402950!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAzNDgwMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6069 invoked from network); 26 Feb 2013 19:33:07 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 19:33:07 -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.xen.org> from <aliguori@us.ibm.com>;
	Wed, 27 Feb 2013 05:28:16 +1000
Received: from d23dlp03.au.ibm.com (202.81.31.214)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 27 Feb 2013 05:28:15 +1000
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120])
	by d23dlp03.au.ibm.com (Postfix) with ESMTP id 15F223578050
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:32:58 +1100 (EST)
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
	r1QJKTJ810486112
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:20:30 +1100
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
	r1QJWuCW027671
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:32:56 +1100
Received: from titi.na.relay.ibm.com (titi.austin.ibm.com [9.41.105.125])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	r1QJWoIE027607; Wed, 27 Feb 2013 06:32:52 +1100
From: Anthony Liguori <aliguori@us.ibm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1361893836.26546.304.camel@zakaz.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
	<1361893836.26546.304.camel@zakaz.uk.xensource.com>
User-Agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Tue, 26 Feb 2013 13:32:49 -0600
Message-ID: <87vc9ean1a.fsf@codemonkey.ws>
MIME-Version: 1.0
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13022619-7014-0000-0000-000002A46C68
Cc: "mst@redhat.com" <mst@redhat.com>, "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
	to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> Given that Xen has at least two other mechanisms (xenstore and
> hvmparams) for passing this sort of information around I'm not sure why
> hacking the emulated i440fx device should be the preferred option.

And QEMU also provides the fw_cfg interface with this information.

Regards,

Anthony Liguori

>
> On Tue, 2013-02-26 at 15:43 +0000, Stefano Stabellini wrote:
>> Right, I think that reading as 0xff and write once would be important
>> improvements for this patch.
>> 
>> I would like to see a document somewhere (maybe just a text file under
>> xen-unstable/docs/misc) with a list of deviations of the i440fx we
>> emulate and the real one.
>> 
>> Other than that, it would be OK for me.
>> 
>> On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
>> > For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.
>> > Xiantao
>> >
>> > > -----Original Message-----
>> > > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
>> > > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
>> > > Of Hao, Xudong
>> > > Sent: Tuesday, February 26, 2013 11:33 AM
>> > > To: Stefano Stabellini; Ian Campbell
>> > > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
>> > > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
>> > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
>> > > base of PCI
>> > >
>> > > > -----Original Message-----
>> > > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
>> > > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
>> > > > Of Stefano Stabellini
>> > > > Sent: Tuesday, February 26, 2013 12:06 AM
>> > > > To: Hao, Xudong
>> > > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
>> > > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
>> > > > afaerber@suse.de
>> > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
>> > > the
>> > > > base of PCI
>> > > >
>> > > > On Mon, 25 Feb 2013, Xudong Hao wrote:
>> > > > > v2:
>> > > > > * Use "piix: " in the subject rather than "qemu: "
>> > > > > * Define TOM register as one byte
>> > > > > * Define default TOM value instead of hardcode 0xe0000000 in more that
>> > > one
>> > > > place
>> > > > > * Use API pci_set_byte for pci config access
>> > > > > * Use dev->config instead of the indirect d->dev.config
>> > > > >
>> > > > > Define a TOM(top of memory) register to report the base of PCI memory,
>> > > > update
>> > > > > memory region dynamically. TOM register are defined to one byte in PCI
>> > > > configure
>> > > > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
>> > > > > it requires bios set TOM with 16M-aligned.
>> > > > >
>> > > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
>> > > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
>> > > >
>> > > > The patch is OK from my POV, but I think that Ian raised a valid
>> > > > concern: we are supposed to emulate a real piece of hardware, maybe
>> > > > another mechanism (xenbus? hvmop?) to pass the information from
>> > > > hvmloader to QEMU would be a better fit than this.
>> > > > Otherwise at least we would need to advertize this feature somehow: if
>> > > > hvmloader can use it, the guest kernel can use it too...
>> > > >
>> > > Hi, Ian and Stefano
>> > >
>> > > Here adding this faking register in bios is a hack way.
>> > > However, what we emulated is not full real piece of hardware at all times, the
>> > > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
>> > > The faking register is only effective by bios and device model. This register is
>> > > reserved by host bridge, so guest can't access this register, guest kernel should
>> > > handle well when accessing a reserved region.
>> > >
>> > > -Thanks
>> > > Xudong
>> > > >
>> > > >
>> > > > >  hw/pc.h       |  7 +++---
>> > > > >  hw/pc_piix.c  | 12 +++-------
>> > > > >  hw/piix_pci.c | 73
>> > > > +++++++++++++++++++++++++++++++++++++++++++----------------
>> > > > >  3 files changed, 59 insertions(+), 33 deletions(-)
>> > > > >
>> > > > > diff --git a/hw/pc.h b/hw/pc.h
>> > > > > index fbcf43d..62adcc5 100644
>> > > > > --- a/hw/pc.h
>> > > > > +++ b/hw/pc.h
>> > > > > @@ -129,15 +129,14 @@ extern int no_hpet;
>> > > > >  struct PCII440FXState;
>> > > > >  typedef struct PCII440FXState PCII440FXState;
>> > > > >
>> > > > > +#define I440FX_TOM     0xe0000000
>> > > > > +#define I440FX_XEN_TOM 0xf0000000
>> > > > > +
>> > > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>> > > > >                      ISABus **isa_bus, qemu_irq *pic,
>> > > > >                      MemoryRegion *address_space_mem,
>> > > > >                      MemoryRegion *address_space_io,
>> > > > >                      ram_addr_t ram_size,
>> > > > > -                    hwaddr pci_hole_start,
>> > > > > -                    hwaddr pci_hole_size,
>> > > > > -                    hwaddr pci_hole64_start,
>> > > > > -                    hwaddr pci_hole64_size,
>> > > > >                      MemoryRegion *pci_memory,
>> > > > >                      MemoryRegion *ram_memory);
>> > > > >
>> > > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> > > > > index 0a6923d..2eef510 100644
>> > > > > --- a/hw/pc_piix.c
>> > > > > +++ b/hw/pc_piix.c
>> > > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
>> > > > >          kvmclock_create();
>> > > > >      }
>> > > > >
>> > > > > -    if (ram_size >= 0xe0000000 ) {
>> > > > > -        above_4g_mem_size = ram_size - 0xe0000000;
>> > > > > -        below_4g_mem_size = 0xe0000000;
>> > > > > +    if (ram_size >= I440FX_TOM) {
>> > > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
>> > > > > +        below_4g_mem_size = I440FX_TOM;
>> > > > >      } else {
>> > > > >          above_4g_mem_size = 0;
>> > > > >          below_4g_mem_size = ram_size;
>> > > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
>> > > > *system_memory,
>> > > > >      if (pci_enabled) {
>> > > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>> > > > >                                system_memory, system_io,
>> > > > ram_size,
>> > > > > -                              below_4g_mem_size,
>> > > > > -                              0x100000000ULL -
>> > > > below_4g_mem_size,
>> > > > > -                              0x100000000ULL +
>> > > > above_4g_mem_size,
>> > > > > -                              (sizeof(hwaddr) == 4
>> > > > > -                               ? 0
>> > > > > -                               : ((uint64_t)1 << 62)),
>> > > > >                                pci_memory, ram_memory);
>> > > > >      } else {
>> > > > >          pci_bus = NULL;
>> > > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
>> > > > > index 3d79c73..3e5a25c 100644
>> > > > > --- a/hw/piix_pci.c
>> > > > > +++ b/hw/piix_pci.c
>> > > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
>> > > > >  #define I440FX_PAM_SIZE 7
>> > > > >  #define I440FX_SMRAM    0x72
>> > > > >
>> > > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
>> > > > > + * is 1G, so it doesn't meet any popular virutal machines, so
>> > > > > + * define another register to report the base of PCI memory.
>> > > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
>> > > > > + * resevered for host bridge.
>> > > > > + * */
>> > > > > +#define I440FX_PCI_HOLE_BASE 0xb0
>> > > > > +
>> > > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
>> > > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
>> > > > pci_intx);
>> > > > >  static void piix3_write_config_xen(PCIDevice *dev,
>> > > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
>> > > > pci_intx)
>> > > > >      return (pci_intx + slot_addend) & 3;
>> > > > >  }
>> > > > >
>> > > > > +
>> > > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
>> > > > > +{
>> > > > > +    ram_addr_t above_4g_mem_size;
>> > > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
>> > > > pci_hole64_size;
>> > > > > +
>> > > > > +    pci_hole_start = pci_default_read_config(&f->dev,
>> > > > I440FX_PCI_HOLE_BASE, 1) << 24;
>> > > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
>> > > > > +
>> > > > > +    if (ram_size >= pci_hole_start) {
>> > > > > +        above_4g_mem_size = ram_size - pci_hole_start;
>> > > > > +    } else {
>> > > > > +        above_4g_mem_size = 0;
>> > > > > +    }
>> > > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
>> > > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
>> > > > > +
>> > > > > +    if (del) {
>> > > > > +        memory_region_del_subregion(f->system_memory,
>> > > > &f->pci_hole);
>> > > > > +        if (pci_hole64_size) {
>> > > > > +            memory_region_del_subregion(f->system_memory,
>> > > > &f->pci_hole_64bit);
>> > > > > +        }
>> > > > > +    }
>> > > > > +
>> > > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
>> > > > f->pci_address_space,
>> > > > > +                             pci_hole_start, pci_hole_size);
>> > > > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
>> > > > &f->pci_hole);
>> > > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
>> > > > > +                             f->pci_address_space,
>> > > > > +                             pci_hole64_start, pci_hole64_size);
>> > > > > +    if (pci_hole64_size) {
>> > > > > +        memory_region_add_subregion(f->system_memory,
>> > > > pci_hole64_start,
>> > > > > +                                    &f->pci_hole_64bit);
>> > > > > +    }
>> > > > > +}
>> > > > > +
>> > > > > +
>> > > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
>> > > > >  {
>> > > > >      int i;
>> > > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
>> > > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
>> > > > >          i440fx_update_memory_mappings(d);
>> > > > >      }
>> > > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
>> > > > > +        i440fx_update_pci_mem_hole(d, true);
>> > > > > +    }
>> > > > >  }
>> > > > >
>> > > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
>> > > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
>> > > > >
>> > > > >      d->dev.config[I440FX_SMRAM] = 0x02;
>> > > > >
>> > > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
>> > > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
>> > > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
>> > > > 24));
>> > > > > +
>> > > > >      cpu_smm_register(&i440fx_set_smm, d);
>> > > > >      return 0;
>> > > > >  }
>> > > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
>> > > > *device_name,
>> > > > >                                    MemoryRegion
>> > > > *address_space_mem,
>> > > > >                                    MemoryRegion
>> > > > *address_space_io,
>> > > > >                                    ram_addr_t ram_size,
>> > > > > -                                  hwaddr pci_hole_start,
>> > > > > -                                  hwaddr pci_hole_size,
>> > > > > -                                  hwaddr pci_hole64_start,
>> > > > > -                                  hwaddr pci_hole64_size,
>> > > > >                                    MemoryRegion
>> > > > *pci_address_space,
>> > > > >                                    MemoryRegion *ram_memory)
>> > > > >  {
>> > > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
>> > > > *device_name,
>> > > > >      f->system_memory = address_space_mem;
>> > > > >      f->pci_address_space = pci_address_space;
>> > > > >      f->ram_memory = ram_memory;
>> > > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
>> > > > f->pci_address_space,
>> > > > > -                             pci_hole_start, pci_hole_size);
>> > > > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
>> > > > &f->pci_hole);
>> > > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
>> > > > > -                             f->pci_address_space,
>> > > > > -                             pci_hole64_start, pci_hole64_size);
>> > > > > -    if (pci_hole64_size) {
>> > > > > -        memory_region_add_subregion(f->system_memory,
>> > > > pci_hole64_start,
>> > > > > -                                    &f->pci_hole_64bit);
>> > > > > -    }
>> > > > >      memory_region_init_alias(&f->smram_region, "smram-region",
>> > > > >                               f->pci_address_space, 0xa0000,
>> > > > 0x20000);
>> > > > >      memory_region_add_subregion_overlap(f->system_memory,
>> > > > 0xa0000,
>> > > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
>> > > > *device_name,
>> > > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
>> > > > >
>> > > > >      i440fx_update_memory_mappings(f);
>> > > > > +    i440fx_update_pci_mem_hole(f, false);
>> > > > >
>> > > > >      return b;
>> > > > >  }
>> > > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
>> > > > **pi440fx_state, int *piix3_devfn,
>> > > > >                      MemoryRegion *address_space_mem,
>> > > > >                      MemoryRegion *address_space_io,
>> > > > >                      ram_addr_t ram_size,
>> > > > > -                    hwaddr pci_hole_start,
>> > > > > -                    hwaddr pci_hole_size,
>> > > > > -                    hwaddr pci_hole64_start,
>> > > > > -                    hwaddr pci_hole64_size,
>> > > > >                      MemoryRegion *pci_memory, MemoryRegion
>> > > > *ram_memory)
>> > > > >
>> > > > >  {
>> > > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
>> > > > int *piix3_devfn,
>> > > > >
>> > > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
>> > > > pic,
>> > > > >                             address_space_mem, address_space_io,
>> > > > ram_size,
>> > > > > -                           pci_hole_start, pci_hole_size,
>> > > > > -                           pci_hole64_start, pci_hole64_size,
>> > > > >                             pci_memory, ram_memory);
>> > > > >      return b;
>> > > > >  }
>> > > > > --
>> > > > > 1.7.12.1
>> > > > >
>> > >
>> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 19:33:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 19:33: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 1UAQH1-0000QL-Mz; Tue, 26 Feb 2013 19:33:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aliguori@us.ibm.com>) id 1UAQH0-0000QG-1d
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 19:33:10 +0000
Received: from [85.158.138.51:35707] by server-16.bemta-3.messagelabs.com id
	E6/39-02727-5FD0D215; Tue, 26 Feb 2013 19:33:09 +0000
X-Env-Sender: aliguori@us.ibm.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361907183!29402950!1
X-Originating-IP: [202.81.31.148]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0OCA9PiAzNDgwMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6069 invoked from network); 26 Feb 2013 19:33:07 -0000
Received: from e23smtp06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.31.148)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 19:33:07 -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.xen.org> from <aliguori@us.ibm.com>;
	Wed, 27 Feb 2013 05:28:16 +1000
Received: from d23dlp03.au.ibm.com (202.81.31.214)
	by e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 27 Feb 2013 05:28:15 +1000
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120])
	by d23dlp03.au.ibm.com (Postfix) with ESMTP id 15F223578050
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:32:58 +1100 (EST)
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
	r1QJKTJ810486112
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:20:30 +1100
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
	r1QJWuCW027671
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:32:56 +1100
Received: from titi.na.relay.ibm.com (titi.austin.ibm.com [9.41.105.125])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	r1QJWoIE027607; Wed, 27 Feb 2013 06:32:52 +1100
From: Anthony Liguori <aliguori@us.ibm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1361893836.26546.304.camel@zakaz.uk.xensource.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
	<1361893836.26546.304.camel@zakaz.uk.xensource.com>
User-Agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Tue, 26 Feb 2013 13:32:49 -0600
Message-ID: <87vc9ean1a.fsf@codemonkey.ws>
MIME-Version: 1.0
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13022619-7014-0000-0000-000002A46C68
Cc: "mst@redhat.com" <mst@redhat.com>, "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
	to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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> writes:

> Given that Xen has at least two other mechanisms (xenstore and
> hvmparams) for passing this sort of information around I'm not sure why
> hacking the emulated i440fx device should be the preferred option.

And QEMU also provides the fw_cfg interface with this information.

Regards,

Anthony Liguori

>
> On Tue, 2013-02-26 at 15:43 +0000, Stefano Stabellini wrote:
>> Right, I think that reading as 0xff and write once would be important
>> improvements for this patch.
>> 
>> I would like to see a document somewhere (maybe just a text file under
>> xen-unstable/docs/misc) with a list of deviations of the i440fx we
>> emulate and the real one.
>> 
>> Other than that, it would be OK for me.
>> 
>> On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
>> > For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with Qemu should break this hardware rule.  Maybe we can implement this register as a write-only one, so that OS can't see its existence.   If OS reads this register, Qemu always return 0xff, and for any write operations to this register, it may impact hardware's behavior.  This conforms to the behavior of OS accessing a reserved register.
>> > Xiantao
>> >
>> > > -----Original Message-----
>> > > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
>> > > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On Behalf
>> > > Of Hao, Xudong
>> > > Sent: Tuesday, February 26, 2013 11:33 AM
>> > > To: Stefano Stabellini; Ian Campbell
>> > > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org; xen-
>> > > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
>> > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the
>> > > base of PCI
>> > >
>> > > > -----Original Message-----
>> > > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
>> > > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
>> > > > Of Stefano Stabellini
>> > > > Sent: Tuesday, February 26, 2013 12:06 AM
>> > > > To: Hao, Xudong
>> > > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
>> > > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
>> > > > afaerber@suse.de
>> > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
>> > > the
>> > > > base of PCI
>> > > >
>> > > > On Mon, 25 Feb 2013, Xudong Hao wrote:
>> > > > > v2:
>> > > > > * Use "piix: " in the subject rather than "qemu: "
>> > > > > * Define TOM register as one byte
>> > > > > * Define default TOM value instead of hardcode 0xe0000000 in more that
>> > > one
>> > > > place
>> > > > > * Use API pci_set_byte for pci config access
>> > > > > * Use dev->config instead of the indirect d->dev.config
>> > > > >
>> > > > > Define a TOM(top of memory) register to report the base of PCI memory,
>> > > > update
>> > > > > memory region dynamically. TOM register are defined to one byte in PCI
>> > > > configure
>> > > > > space, because that only upper 4 bit of PCI memory takes effect for Xen, so
>> > > > > it requires bios set TOM with 16M-aligned.
>> > > > >
>> > > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
>> > > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
>> > > >
>> > > > The patch is OK from my POV, but I think that Ian raised a valid
>> > > > concern: we are supposed to emulate a real piece of hardware, maybe
>> > > > another mechanism (xenbus? hvmop?) to pass the information from
>> > > > hvmloader to QEMU would be a better fit than this.
>> > > > Otherwise at least we would need to advertize this feature somehow: if
>> > > > hvmloader can use it, the guest kernel can use it too...
>> > > >
>> > > Hi, Ian and Stefano
>> > >
>> > > Here adding this faking register in bios is a hack way.
>> > > However, what we emulated is not full real piece of hardware at all times, the
>> > > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
>> > > The faking register is only effective by bios and device model. This register is
>> > > reserved by host bridge, so guest can't access this register, guest kernel should
>> > > handle well when accessing a reserved region.
>> > >
>> > > -Thanks
>> > > Xudong
>> > > >
>> > > >
>> > > > >  hw/pc.h       |  7 +++---
>> > > > >  hw/pc_piix.c  | 12 +++-------
>> > > > >  hw/piix_pci.c | 73
>> > > > +++++++++++++++++++++++++++++++++++++++++++----------------
>> > > > >  3 files changed, 59 insertions(+), 33 deletions(-)
>> > > > >
>> > > > > diff --git a/hw/pc.h b/hw/pc.h
>> > > > > index fbcf43d..62adcc5 100644
>> > > > > --- a/hw/pc.h
>> > > > > +++ b/hw/pc.h
>> > > > > @@ -129,15 +129,14 @@ extern int no_hpet;
>> > > > >  struct PCII440FXState;
>> > > > >  typedef struct PCII440FXState PCII440FXState;
>> > > > >
>> > > > > +#define I440FX_TOM     0xe0000000
>> > > > > +#define I440FX_XEN_TOM 0xf0000000
>> > > > > +
>> > > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>> > > > >                      ISABus **isa_bus, qemu_irq *pic,
>> > > > >                      MemoryRegion *address_space_mem,
>> > > > >                      MemoryRegion *address_space_io,
>> > > > >                      ram_addr_t ram_size,
>> > > > > -                    hwaddr pci_hole_start,
>> > > > > -                    hwaddr pci_hole_size,
>> > > > > -                    hwaddr pci_hole64_start,
>> > > > > -                    hwaddr pci_hole64_size,
>> > > > >                      MemoryRegion *pci_memory,
>> > > > >                      MemoryRegion *ram_memory);
>> > > > >
>> > > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> > > > > index 0a6923d..2eef510 100644
>> > > > > --- a/hw/pc_piix.c
>> > > > > +++ b/hw/pc_piix.c
>> > > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
>> > > > >          kvmclock_create();
>> > > > >      }
>> > > > >
>> > > > > -    if (ram_size >= 0xe0000000 ) {
>> > > > > -        above_4g_mem_size = ram_size - 0xe0000000;
>> > > > > -        below_4g_mem_size = 0xe0000000;
>> > > > > +    if (ram_size >= I440FX_TOM) {
>> > > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
>> > > > > +        below_4g_mem_size = I440FX_TOM;
>> > > > >      } else {
>> > > > >          above_4g_mem_size = 0;
>> > > > >          below_4g_mem_size = ram_size;
>> > > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
>> > > > *system_memory,
>> > > > >      if (pci_enabled) {
>> > > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>> > > > >                                system_memory, system_io,
>> > > > ram_size,
>> > > > > -                              below_4g_mem_size,
>> > > > > -                              0x100000000ULL -
>> > > > below_4g_mem_size,
>> > > > > -                              0x100000000ULL +
>> > > > above_4g_mem_size,
>> > > > > -                              (sizeof(hwaddr) == 4
>> > > > > -                               ? 0
>> > > > > -                               : ((uint64_t)1 << 62)),
>> > > > >                                pci_memory, ram_memory);
>> > > > >      } else {
>> > > > >          pci_bus = NULL;
>> > > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
>> > > > > index 3d79c73..3e5a25c 100644
>> > > > > --- a/hw/piix_pci.c
>> > > > > +++ b/hw/piix_pci.c
>> > > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
>> > > > >  #define I440FX_PAM_SIZE 7
>> > > > >  #define I440FX_SMRAM    0x72
>> > > > >
>> > > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
>> > > > > + * is 1G, so it doesn't meet any popular virutal machines, so
>> > > > > + * define another register to report the base of PCI memory.
>> > > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
>> > > > > + * resevered for host bridge.
>> > > > > + * */
>> > > > > +#define I440FX_PCI_HOLE_BASE 0xb0
>> > > > > +
>> > > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
>> > > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
>> > > > pci_intx);
>> > > > >  static void piix3_write_config_xen(PCIDevice *dev,
>> > > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int
>> > > > pci_intx)
>> > > > >      return (pci_intx + slot_addend) & 3;
>> > > > >  }
>> > > > >
>> > > > > +
>> > > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
>> > > > > +{
>> > > > > +    ram_addr_t above_4g_mem_size;
>> > > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
>> > > > pci_hole64_size;
>> > > > > +
>> > > > > +    pci_hole_start = pci_default_read_config(&f->dev,
>> > > > I440FX_PCI_HOLE_BASE, 1) << 24;
>> > > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
>> > > > > +
>> > > > > +    if (ram_size >= pci_hole_start) {
>> > > > > +        above_4g_mem_size = ram_size - pci_hole_start;
>> > > > > +    } else {
>> > > > > +        above_4g_mem_size = 0;
>> > > > > +    }
>> > > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
>> > > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
>> > > > > +
>> > > > > +    if (del) {
>> > > > > +        memory_region_del_subregion(f->system_memory,
>> > > > &f->pci_hole);
>> > > > > +        if (pci_hole64_size) {
>> > > > > +            memory_region_del_subregion(f->system_memory,
>> > > > &f->pci_hole_64bit);
>> > > > > +        }
>> > > > > +    }
>> > > > > +
>> > > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
>> > > > f->pci_address_space,
>> > > > > +                             pci_hole_start, pci_hole_size);
>> > > > > +    memory_region_add_subregion(f->system_memory, pci_hole_start,
>> > > > &f->pci_hole);
>> > > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
>> > > > > +                             f->pci_address_space,
>> > > > > +                             pci_hole64_start, pci_hole64_size);
>> > > > > +    if (pci_hole64_size) {
>> > > > > +        memory_region_add_subregion(f->system_memory,
>> > > > pci_hole64_start,
>> > > > > +                                    &f->pci_hole_64bit);
>> > > > > +    }
>> > > > > +}
>> > > > > +
>> > > > > +
>> > > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
>> > > > >  {
>> > > > >      int i;
>> > > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice *dev,
>> > > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
>> > > > >          i440fx_update_memory_mappings(d);
>> > > > >      }
>> > > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
>> > > > > +        i440fx_update_pci_mem_hole(d, true);
>> > > > > +    }
>> > > > >  }
>> > > > >
>> > > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
>> > > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
>> > > > >
>> > > > >      d->dev.config[I440FX_SMRAM] = 0x02;
>> > > > >
>> > > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
>> > > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
>> > > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE, (uint8_t)(addr >>
>> > > > 24));
>> > > > > +
>> > > > >      cpu_smm_register(&i440fx_set_smm, d);
>> > > > >      return 0;
>> > > > >  }
>> > > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const char
>> > > > *device_name,
>> > > > >                                    MemoryRegion
>> > > > *address_space_mem,
>> > > > >                                    MemoryRegion
>> > > > *address_space_io,
>> > > > >                                    ram_addr_t ram_size,
>> > > > > -                                  hwaddr pci_hole_start,
>> > > > > -                                  hwaddr pci_hole_size,
>> > > > > -                                  hwaddr pci_hole64_start,
>> > > > > -                                  hwaddr pci_hole64_size,
>> > > > >                                    MemoryRegion
>> > > > *pci_address_space,
>> > > > >                                    MemoryRegion *ram_memory)
>> > > > >  {
>> > > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const char
>> > > > *device_name,
>> > > > >      f->system_memory = address_space_mem;
>> > > > >      f->pci_address_space = pci_address_space;
>> > > > >      f->ram_memory = ram_memory;
>> > > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
>> > > > f->pci_address_space,
>> > > > > -                             pci_hole_start, pci_hole_size);
>> > > > > -    memory_region_add_subregion(f->system_memory, pci_hole_start,
>> > > > &f->pci_hole);
>> > > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
>> > > > > -                             f->pci_address_space,
>> > > > > -                             pci_hole64_start, pci_hole64_size);
>> > > > > -    if (pci_hole64_size) {
>> > > > > -        memory_region_add_subregion(f->system_memory,
>> > > > pci_hole64_start,
>> > > > > -                                    &f->pci_hole_64bit);
>> > > > > -    }
>> > > > >      memory_region_init_alias(&f->smram_region, "smram-region",
>> > > > >                               f->pci_address_space, 0xa0000,
>> > > > 0x20000);
>> > > > >      memory_region_add_subregion_overlap(f->system_memory,
>> > > > 0xa0000,
>> > > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
>> > > > *device_name,
>> > > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
>> > > > >
>> > > > >      i440fx_update_memory_mappings(f);
>> > > > > +    i440fx_update_pci_mem_hole(f, false);
>> > > > >
>> > > > >      return b;
>> > > > >  }
>> > > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
>> > > > **pi440fx_state, int *piix3_devfn,
>> > > > >                      MemoryRegion *address_space_mem,
>> > > > >                      MemoryRegion *address_space_io,
>> > > > >                      ram_addr_t ram_size,
>> > > > > -                    hwaddr pci_hole_start,
>> > > > > -                    hwaddr pci_hole_size,
>> > > > > -                    hwaddr pci_hole64_start,
>> > > > > -                    hwaddr pci_hole64_size,
>> > > > >                      MemoryRegion *pci_memory, MemoryRegion
>> > > > *ram_memory)
>> > > > >
>> > > > >  {
>> > > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
>> > > > int *piix3_devfn,
>> > > > >
>> > > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn, isa_bus,
>> > > > pic,
>> > > > >                             address_space_mem, address_space_io,
>> > > > ram_size,
>> > > > > -                           pci_hole_start, pci_hole_size,
>> > > > > -                           pci_hole64_start, pci_hole64_size,
>> > > > >                             pci_memory, ram_memory);
>> > > > >      return b;
>> > > > >  }
>> > > > > --
>> > > > > 1.7.12.1
>> > > > >
>> > >
>> >


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 19:56:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 19:56: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 1UAQdc-000121-SW; Tue, 26 Feb 2013 19:56: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 1UAQdb-00011e-Cn
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 19:56:31 +0000
Received: from [85.158.139.211:54274] by server-4.bemta-5.messagelabs.com id
	1E/94-01980-E631D215; Tue, 26 Feb 2013 19:56:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361908589!19427674!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6258 invoked from network); 26 Feb 2013 19:56:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 19:56:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1919486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 19:56: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.297.1; Tue, 26 Feb 2013 19:56:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAQdZ-00016w-Dl;
	Tue, 26 Feb 2013 19:56:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAQdY-0001VH-SY;
	Tue, 26 Feb 2013 19:56:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16740-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 19:56:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16740: 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 16740 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16740/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 16228
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 16228

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
+ revision=b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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.2-testing b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
+ branch=xen-4.2-testing
+ revision=b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : osstest@xenbits.xensource.com:/home/xen/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.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.2-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.2-testing
+ xenversion=xen-4.2
+ xenversion=4.2
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git b5445b141f6809dd4fa3ee4a11926eab6fc1f50c:stable-4.2
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6140126..b5445b1  b5445b141f6809dd4fa3ee4a11926eab6fc1f50c -> stable-4.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 19:56:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 19:56: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 1UAQdc-000121-SW; Tue, 26 Feb 2013 19:56: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 1UAQdb-00011e-Cn
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 19:56:31 +0000
Received: from [85.158.139.211:54274] by server-4.bemta-5.messagelabs.com id
	1E/94-01980-E631D215; Tue, 26 Feb 2013 19:56:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361908589!19427674!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6258 invoked from network); 26 Feb 2013 19:56:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 19:56:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; 
   d="scan'208";a="1919486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 19:56: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.297.1; Tue, 26 Feb 2013 19:56:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAQdZ-00016w-Dl;
	Tue, 26 Feb 2013 19:56:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAQdY-0001VH-SY;
	Tue, 26 Feb 2013 19:56:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16740-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 19:56:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 16740: 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 16740 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16740/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 16228
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 16228

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    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-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemut-win  13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
baseline version:
 xen                  61401264eb00fae4ee4efc8e9a5067449283207b

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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.2-testing
+ revision=b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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.2-testing b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
+ branch=xen-4.2-testing
+ revision=b5445b141f6809dd4fa3ee4a11926eab6fc1f50c
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : osstest@xenbits.xensource.com:/home/xen/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.2-testing
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.2-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.2-testing
+ xenversion=xen-4.2
+ xenversion=4.2
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git b5445b141f6809dd4fa3ee4a11926eab6fc1f50c:stable-4.2
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6140126..b5445b1  b5445b141f6809dd4fa3ee4a11926eab6fc1f50c -> stable-4.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 20:34:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 20:34: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 1UARDn-0002PI-ON; Tue, 26 Feb 2013 20:33:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UARDm-0002PD-Mk
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 20:33:54 +0000
Received: from [85.158.138.51:61135] by server-8.bemta-3.messagelabs.com id
	39/E7-25687-C2C1D215; Tue, 26 Feb 2013 20:33:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361910827!29260606!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_32,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17686 invoked from network); 26 Feb 2013 20:33:47 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 20:33:47 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:49970 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 1UARBb-0000Qx-B2; Tue, 26 Feb 2013 21:31:39 +0100
Date: Tue, 26 Feb 2013 21:33:41 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <114314748.20130226213341@eikelenboom.it>
To: Thomas Gleixner <tglx@linutronix.de>
In-Reply-To: <alpine.LFD.2.02.1302261843240.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.com>
	<alpine.LFD.2.02.1302261320120.22263@ionos>
	<894977724.20130226140702@eikelenboom.it>
	<alpine.LFD.2.02.1302261843240.22263@ionos>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regression introduced with
	14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use
	smpboot 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


Tuesday, February 26, 2013, 6:44:33 PM, you wrote:

> On Tue, 26 Feb 2013, Sander Eikelenboom wrote:
>> Tuesday, February 26, 2013, 1:36:36 PM, you wrote:
>> > On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>> >> 
>> >> I don't know if this is b/c the Xen code is missing something or
>> >> expects something that never happend. I hadn't looked at your
>> >> patch in any detail (was going to do that on Monday).
>> >> 
>> >> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
>> 
>> Hmm i'm seeing this booting on baremetal as well.
>> (see http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00836.html)

> Ok. I decoded it with the help of Konrad. Does the patch below work
> for you as well?

Did a few reboots and yes it seems to work here as well !
Thx

--
Sander

> Thanks,

>         tglx

> Index: linux-2.6/include/linux/smpboot.h
> ===================================================================
> --- linux-2.6.orig/include/linux/smpboot.h
> +++ linux-2.6/include/linux/smpboot.h
> @@ -24,6 +24,9 @@ struct smpboot_thread_data;
>   *                     parked (cpu offline)
>   * @unpark:            Optional unpark function, called when the thread is
>   *                     unparked (cpu online)
> + * @pre_unpark:                Optional unpark function, called before the thread is
> + *                     unparked (cpu online). This is not guaranteed to be
> + *                     called on the target cpu of the thread. Careful!
>   * @selfparking:       Thread is not parked by the park function.
>   * @thread_comm:       The base name of the thread
>   */
> @@ -37,6 +40,7 @@ struct smp_hotplug_thread {
>         void                            (*cleanup)(unsigned int cpu, bool online);
>         void                            (*park)(unsigned int cpu);
>         void                            (*unpark)(unsigned int cpu);
> +       void                            (*pre_unpark)(unsigned int cpu);
>         bool                            selfparking;
>         const char                      *thread_comm;
>  };
> Index: linux-2.6/kernel/smpboot.c
> ===================================================================
> --- linux-2.6.orig/kernel/smpboot.c
> +++ linux-2.6/kernel/smpboot.c
> @@ -209,6 +209,8 @@ static void smpboot_unpark_thread(struct
>  {
>         struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
>  
+       if (ht->>pre_unpark)
+               ht->>pre_unpark(cpu);
>         kthread_unpark(tsk);
>  }
>  
> Index: linux-2.6/kernel/stop_machine.c
> ===================================================================
> --- linux-2.6.orig/kernel/stop_machine.c
> +++ linux-2.6/kernel/stop_machine.c
> @@ -336,7 +336,7 @@ static struct smp_hotplug_thread cpu_sto
>         .create                 = cpu_stop_create,
>         .setup                  = cpu_stop_unpark,
>         .park                   = cpu_stop_park,
> -       .unpark                 = cpu_stop_unpark,
> +       .pre_unpark             = cpu_stop_unpark,
>         .selfparking            = true,
>  };
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 20:34:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 20:34: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 1UARDn-0002PI-ON; Tue, 26 Feb 2013 20:33:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UARDm-0002PD-Mk
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 20:33:54 +0000
Received: from [85.158.138.51:61135] by server-8.bemta-3.messagelabs.com id
	39/E7-25687-C2C1D215; Tue, 26 Feb 2013 20:33:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361910827!29260606!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_32,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17686 invoked from network); 26 Feb 2013 20:33:47 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-4.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 20:33:47 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:49970 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 1UARBb-0000Qx-B2; Tue, 26 Feb 2013 21:31:39 +0100
Date: Tue, 26 Feb 2013 21:33:41 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <114314748.20130226213341@eikelenboom.it>
To: Thomas Gleixner <tglx@linutronix.de>
In-Reply-To: <alpine.LFD.2.02.1302261843240.22263@ionos>
References: <20130223011800.GA2465@phenom.dumpdata.com>
	<alpine.LFD.2.02.1302261320120.22263@ionos>
	<894977724.20130226140702@eikelenboom.it>
	<alpine.LFD.2.02.1302261843240.22263@ionos>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regression introduced with
	14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use
	smpboot 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


Tuesday, February 26, 2013, 6:44:33 PM, you wrote:

> On Tue, 26 Feb 2013, Sander Eikelenboom wrote:
>> Tuesday, February 26, 2013, 1:36:36 PM, you wrote:
>> > On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
>> >> 
>> >> I don't know if this is b/c the Xen code is missing something or
>> >> expects something that never happend. I hadn't looked at your
>> >> patch in any detail (was going to do that on Monday).
>> >> 
>> >> Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
>> 
>> Hmm i'm seeing this booting on baremetal as well.
>> (see http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00836.html)

> Ok. I decoded it with the help of Konrad. Does the patch below work
> for you as well?

Did a few reboots and yes it seems to work here as well !
Thx

--
Sander

> Thanks,

>         tglx

> Index: linux-2.6/include/linux/smpboot.h
> ===================================================================
> --- linux-2.6.orig/include/linux/smpboot.h
> +++ linux-2.6/include/linux/smpboot.h
> @@ -24,6 +24,9 @@ struct smpboot_thread_data;
>   *                     parked (cpu offline)
>   * @unpark:            Optional unpark function, called when the thread is
>   *                     unparked (cpu online)
> + * @pre_unpark:                Optional unpark function, called before the thread is
> + *                     unparked (cpu online). This is not guaranteed to be
> + *                     called on the target cpu of the thread. Careful!
>   * @selfparking:       Thread is not parked by the park function.
>   * @thread_comm:       The base name of the thread
>   */
> @@ -37,6 +40,7 @@ struct smp_hotplug_thread {
>         void                            (*cleanup)(unsigned int cpu, bool online);
>         void                            (*park)(unsigned int cpu);
>         void                            (*unpark)(unsigned int cpu);
> +       void                            (*pre_unpark)(unsigned int cpu);
>         bool                            selfparking;
>         const char                      *thread_comm;
>  };
> Index: linux-2.6/kernel/smpboot.c
> ===================================================================
> --- linux-2.6.orig/kernel/smpboot.c
> +++ linux-2.6/kernel/smpboot.c
> @@ -209,6 +209,8 @@ static void smpboot_unpark_thread(struct
>  {
>         struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
>  
+       if (ht->>pre_unpark)
+               ht->>pre_unpark(cpu);
>         kthread_unpark(tsk);
>  }
>  
> Index: linux-2.6/kernel/stop_machine.c
> ===================================================================
> --- linux-2.6.orig/kernel/stop_machine.c
> +++ linux-2.6/kernel/stop_machine.c
> @@ -336,7 +336,7 @@ static struct smp_hotplug_thread cpu_sto
>         .create                 = cpu_stop_create,
>         .setup                  = cpu_stop_unpark,
>         .park                   = cpu_stop_park,
> -       .unpark                 = cpu_stop_unpark,
> +       .pre_unpark             = cpu_stop_unpark,
>         .selfparking            = true,
>  };
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 20:51:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 20:51: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 1UARTw-0002d9-BU; Tue, 26 Feb 2013 20:50:36 +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 1UARTu-0002d4-BD
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 20:50:34 +0000
Received: from [85.158.137.99:19169] by server-14.bemta-3.messagelabs.com id
	0E/05-23533-9102D215; Tue, 26 Feb 2013 20:50:33 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361911832!18201982!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2376 invoked from network); 26 Feb 2013 20:50:32 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 20:50:32 -0000
Received: by mail-lb0-f173.google.com with SMTP id gf7so3488682lbb.32
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 12:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:content-type;
	bh=bI2DM2aKdVXIoSwe+GVDvCyy8QeDVZzrSsqfyYLnxWw=;
	b=WdutniMB22Rfir4n51brfNHAlKOxm3wEnFKSEgJMv1YNqbRQsiZH1y0yPB97+6dldx
	L/iCI7L8VJ89cnF+qa9fG03s0b+wbFCRt3W1Sczjqcv6QICpRDzBKZyy6px4HQViAICU
	xClYXckqI1RN5+JfdejjcBurdMSiRPv0hfP7AVsGbleb4CpPvyzrexP8jgAui/QKD4Ih
	ekQrpktTWG62DLZP/QxYwyWRda7Syt+z6waHIytG/BfRTkioFKHY5rGmXepYDuZ1lw3c
	hQRjoGWGr3JQRLdhVTZreRd4sO6lZxYhG+F3wKWcPfIpaaw44OT/8IFZ0IK7sdMGdEHY
	Huew==
MIME-Version: 1.0
X-Received: by 10.152.123.34 with SMTP id lx2mr14875314lab.52.1361911831727;
	Tue, 26 Feb 2013 12:50:31 -0800 (PST)
Received: by 10.112.136.131 with HTTP; Tue, 26 Feb 2013 12:50:31 -0800 (PST)
In-Reply-To: <E1UAQgp-0004rV-FS@xenbits.xen.org>
References: <E1UAQgp-0004rV-FS@xenbits.xen.org>
Date: Wed, 27 Feb 2013 04:50:31 +0800
Message-ID: <CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-changelog] [xen stable-4.2]
	QEMU_UPSTREAM_REVISION update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Just a question below.


On Wed, Feb 27, 2013 at 3:59 AM,  <patchbot@xen.org> wrote:
> commit a667d82549e99e9bd409a351964c2da6e64eb68c
> Author:     Ian Jackson <ian.jackson@eu.citrix.com>
> AuthorDate: Fri Feb 22 17:57:45 2013 +0000
> Commit:     Ian Jackson <Ian.Jackson@eu.citrix.com>
> CommitDate: Fri Feb 22 17:57:45 2013 +0000
>
>     QEMU_UPSTREAM_REVISION update
> ---
>  Config.mk |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Config.mk b/Config.mk
> index ead4da2..dd07341 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -203,7 +203,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-4.2-testing.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  endif
>  OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.2.1
> +QEMU_UPSTREAM_REVISION ?= eccc68722696864fc4823f048c7be58d11281b97

Is the above commit id updated in
git://xenbits.xen.org/qemu-upstream-4.2-testing.git ?  From
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=summary
I can't see any git commit id related to
eccc68722696864fc4823f048c7be58d11281b97 or I am wrong about it?

Thanks.

Kindest regards,
Giam Teck Choon



>  SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
>  # Sun Mar 11 09:27:07 2012 -0400
>  # Update version to 1.6.3.2
> --
> generated by git-patchbot for /home/xen/git/xen.git#stable-4.2
>
> _______________________________________________
> Xen-changelog mailing list
> Xen-changelog@lists.xen.org
> http://lists.xensource.com/xen-changelog

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 20:51:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 20:51: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 1UARTw-0002d9-BU; Tue, 26 Feb 2013 20:50:36 +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 1UARTu-0002d4-BD
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 20:50:34 +0000
Received: from [85.158.137.99:19169] by server-14.bemta-3.messagelabs.com id
	0E/05-23533-9102D215; Tue, 26 Feb 2013 20:50:33 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361911832!18201982!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2376 invoked from network); 26 Feb 2013 20:50:32 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 20:50:32 -0000
Received: by mail-lb0-f173.google.com with SMTP id gf7so3488682lbb.32
	for <xen-devel@lists.xensource.com>;
	Tue, 26 Feb 2013 12:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:content-type;
	bh=bI2DM2aKdVXIoSwe+GVDvCyy8QeDVZzrSsqfyYLnxWw=;
	b=WdutniMB22Rfir4n51brfNHAlKOxm3wEnFKSEgJMv1YNqbRQsiZH1y0yPB97+6dldx
	L/iCI7L8VJ89cnF+qa9fG03s0b+wbFCRt3W1Sczjqcv6QICpRDzBKZyy6px4HQViAICU
	xClYXckqI1RN5+JfdejjcBurdMSiRPv0hfP7AVsGbleb4CpPvyzrexP8jgAui/QKD4Ih
	ekQrpktTWG62DLZP/QxYwyWRda7Syt+z6waHIytG/BfRTkioFKHY5rGmXepYDuZ1lw3c
	hQRjoGWGr3JQRLdhVTZreRd4sO6lZxYhG+F3wKWcPfIpaaw44OT/8IFZ0IK7sdMGdEHY
	Huew==
MIME-Version: 1.0
X-Received: by 10.152.123.34 with SMTP id lx2mr14875314lab.52.1361911831727;
	Tue, 26 Feb 2013 12:50:31 -0800 (PST)
Received: by 10.112.136.131 with HTTP; Tue, 26 Feb 2013 12:50:31 -0800 (PST)
In-Reply-To: <E1UAQgp-0004rV-FS@xenbits.xen.org>
References: <E1UAQgp-0004rV-FS@xenbits.xen.org>
Date: Wed, 27 Feb 2013 04:50:31 +0800
Message-ID: <CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-changelog] [xen stable-4.2]
	QEMU_UPSTREAM_REVISION update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Just a question below.


On Wed, Feb 27, 2013 at 3:59 AM,  <patchbot@xen.org> wrote:
> commit a667d82549e99e9bd409a351964c2da6e64eb68c
> Author:     Ian Jackson <ian.jackson@eu.citrix.com>
> AuthorDate: Fri Feb 22 17:57:45 2013 +0000
> Commit:     Ian Jackson <Ian.Jackson@eu.citrix.com>
> CommitDate: Fri Feb 22 17:57:45 2013 +0000
>
>     QEMU_UPSTREAM_REVISION update
> ---
>  Config.mk |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Config.mk b/Config.mk
> index ead4da2..dd07341 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -203,7 +203,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-4.2-testing.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  endif
>  OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.2.1
> +QEMU_UPSTREAM_REVISION ?= eccc68722696864fc4823f048c7be58d11281b97

Is the above commit id updated in
git://xenbits.xen.org/qemu-upstream-4.2-testing.git ?  From
http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=summary
I can't see any git commit id related to
eccc68722696864fc4823f048c7be58d11281b97 or I am wrong about it?

Thanks.

Kindest regards,
Giam Teck Choon



>  SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
>  # Sun Mar 11 09:27:07 2012 -0400
>  # Update version to 1.6.3.2
> --
> generated by git-patchbot for /home/xen/git/xen.git#stable-4.2
>
> _______________________________________________
> Xen-changelog mailing list
> Xen-changelog@lists.xen.org
> http://lists.xensource.com/xen-changelog

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 20:56:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 20: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 1UARZU-0002p3-5N; Tue, 26 Feb 2013 20:56:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UARZS-0002ox-Fb
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 20:56:18 +0000
Received: from [85.158.138.51:35396] by server-11.bemta-3.messagelabs.com id
	A3/04-10249-1712D215; Tue, 26 Feb 2013 20:56:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361912176!27965815!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4248 invoked from network); 26 Feb 2013 20:56:16 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 20:56:16 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:50100 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 1UARXO-0000XG-AO; Tue, 26 Feb 2013 21:54:10 +0100
Date: Tue, 26 Feb 2013 21:56:12 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <934044508.20130226215612@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130226152038.GA15154@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<20130226152038.GA15154@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Tuesday, February 26, 2013, 4:20:38 PM, you wrote:

> On Mon, Feb 25, 2013 at 11:18:30PM +0100, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>> It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.
>> 
>> I don't see a obvious error in the logs.
>> 
>> The same kernel boots fine on baremetal.
>> With linux 3.8 it boots fine under this version of xen-unstable.
>> 
>> Can you spot something from the logs or you have a hunch from where to start a bisect ?
>> (bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

> There are at least two pitfalls - the
> 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (which you can revert) and you need
> to make sure you have 0cc9129d75ef8993702d97ab0e49542c15ac6ab9
> if you end up in the merge 2ef14f465b9e096531343f5b734cffc5f759f4a6
> ("Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")


>> 
>> 3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

> Interestingly I can reproduce it on my F1A75-M box as well.

> With baremetal I get:
> [   12.701221] ahci 0000:00:11.0: version 3.0
> [   12.701424] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 528175 usecs
> [   12.712999] ahci 0000:00:11.0: irq 46 for MSI/MSI-X
> [   12.717967] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   12.726132] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   12.735405] scsi0 : ahci
> [   12.738087] scsi1 : ahci
> [   12.740734] scsi2 : ahci
> [   12.743511] scsi3 : ahci
> [   12.746278] scsi4 : ahci
> [   12.748930] scsi5 : ahci

> And when booting under Xen 4.1 (note, no IOMMU):

> [   19.178696] ahci 0000:00:11.0: version 3.0
> [   19.178721] xen: registering gsi 19 triggering 0 polarity 1
> [   19.178743] xen: --> pirq=19 -> irq=19 (gsi=19)
> [   19.179040] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   19.179043] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   19.241748] ahci: probe of 0000:00:11.0 failed with error -22
> [   19.249124] initcall ahci_pci_driver_init+0x0/0x1000 [ahci] returned 0 after 460418 usecs

> Had you tried to checkout right before this mega update from Jeff Garzik:

> ab78265 Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
> 21fbd58 Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> d9978ec Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
==>> 77be36d Merge tag 'stable/for-linus-3.9-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

> And seeing if that works?

Ok reverting to just before the libata merge doesn't help. Time to start digging further back ...


>> 
>> --
>> Sander
>> 
>> Attached:
>> - Serial log with 3.9-rc0 kernel (missing sata)
>> - Serial log with 3.8 kernel (booting fine
>> - .config







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 20:56:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 20: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 1UARZU-0002p3-5N; Tue, 26 Feb 2013 20:56:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UARZS-0002ox-Fb
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 20:56:18 +0000
Received: from [85.158.138.51:35396] by server-11.bemta-3.messagelabs.com id
	A3/04-10249-1712D215; Tue, 26 Feb 2013 20:56:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1361912176!27965815!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4248 invoked from network); 26 Feb 2013 20:56:16 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Feb 2013 20:56:16 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:50100 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 1UARXO-0000XG-AO; Tue, 26 Feb 2013 21:54:10 +0100
Date: Tue, 26 Feb 2013 21:56:12 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <934044508.20130226215612@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130226152038.GA15154@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<20130226152038.GA15154@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Tuesday, February 26, 2013, 4:20:38 PM, you wrote:

> On Mon, Feb 25, 2013 at 11:18:30PM +0100, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>> It doesn't detect the s-ata controller, so it ends op with udev timing and bailing out to busybox.
>> 
>> I don't see a obvious error in the logs.
>> 
>> The same kernel boots fine on baremetal.
>> With linux 3.8 it boots fine under this version of xen-unstable.
>> 
>> Can you spot something from the logs or you have a hunch from where to start a bisect ?
>> (bisecting could be a problem due to multiple boot issues and entangled patchsets i presume ..)

> There are at least two pitfalls - the
> 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (which you can revert) and you need
> to make sure you have 0cc9129d75ef8993702d97ab0e49542c15ac6ab9
> if you end up in the merge 2ef14f465b9e096531343f5b734cffc5f759f4a6
> ("Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")


>> 
>> 3.9-rc0 last commit is: ab7826595e9ec51a51f622c5fc91e2f59440481a   Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6

> Interestingly I can reproduce it on my F1A75-M box as well.

> With baremetal I get:
> [   12.701221] ahci 0000:00:11.0: version 3.0
> [   12.701424] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 528175 usecs
> [   12.712999] ahci 0000:00:11.0: irq 46 for MSI/MSI-X
> [   12.717967] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   12.726132] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   12.735405] scsi0 : ahci
> [   12.738087] scsi1 : ahci
> [   12.740734] scsi2 : ahci
> [   12.743511] scsi3 : ahci
> [   12.746278] scsi4 : ahci
> [   12.748930] scsi5 : ahci

> And when booting under Xen 4.1 (note, no IOMMU):

> [   19.178696] ahci 0000:00:11.0: version 3.0
> [   19.178721] xen: registering gsi 19 triggering 0 polarity 1
> [   19.178743] xen: --> pirq=19 -> irq=19 (gsi=19)
> [   19.179040] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [   19.179043] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   19.241748] ahci: probe of 0000:00:11.0 failed with error -22
> [   19.249124] initcall ahci_pci_driver_init+0x0/0x1000 [ahci] returned 0 after 460418 usecs

> Had you tried to checkout right before this mega update from Jeff Garzik:

> ab78265 Merge tag 'mfd-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
> 21fbd58 Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> d9978ec Merge tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
==>> 77be36d Merge tag 'stable/for-linus-3.9-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

> And seeing if that works?

Ok reverting to just before the libata merge doesn't help. Time to start digging further back ...


>> 
>> --
>> Sander
>> 
>> Attached:
>> - Serial log with 3.9-rc0 kernel (missing sata)
>> - Serial log with 3.8 kernel (booting fine
>> - .config







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 21:33:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 21: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 1UAS9F-0003NF-Ng; Tue, 26 Feb 2013 21:33: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 1UAS9D-0003NA-P1
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 21:33:16 +0000
Received: from [85.158.143.99:59235] by server-1.bemta-4.messagelabs.com id
	C0/C8-06203-A1A2D215; Tue, 26 Feb 2013 21:33:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361914394!26012323!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23004 invoked from network); 26 Feb 2013 21:33:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 21:33:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; 
   d="scan'208";a="1922756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 21:33: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.297.1; Tue, 26 Feb 2013 21:33:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAS9B-0001cE-PP;
	Tue, 26 Feb 2013 21:33:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAS9B-0006aW-Kp;
	Tue, 26 Feb 2013 21:33:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16745-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 21:33:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16745: 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 16745 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16745/

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. 15418
 test-amd64-i386-xl-qemut-win-vcpus1 8 guest-saverestore fail in 16681 REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 16681
 test-amd64-amd64-xl           9 guest-start                 fail pass in 16681
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 16681
 test-amd64-i386-qemut-win-vcpus1 8 guest-saverestore fail in 16681 pass in 16236
 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail in 16681 pass in 16745
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot    fail in 16236 pass in 16681
 test-amd64-i386-xl-qemut-win-vcpus1 3 host-install(3) broken in 16236 pass in 16681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemut-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-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  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-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-xl-qemut-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-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-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  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1    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-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 16681 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 16681 never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop     fail in 16681 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 16681 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 16681 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 16681 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 16681 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 16681 never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 16681 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail in 16681 never pass
 test-amd64-i386-qemut-win    16 leak-check/check      fail in 16681 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 16681 never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16236 never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 21:33:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 21: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 1UAS9F-0003NF-Ng; Tue, 26 Feb 2013 21:33: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 1UAS9D-0003NA-P1
	for xen-devel@lists.xensource.com; Tue, 26 Feb 2013 21:33:16 +0000
Received: from [85.158.143.99:59235] by server-1.bemta-4.messagelabs.com id
	C0/C8-06203-A1A2D215; Tue, 26 Feb 2013 21:33:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361914394!26012323!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23004 invoked from network); 26 Feb 2013 21:33:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 21:33:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; 
   d="scan'208";a="1922756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Feb 2013 21:33: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.297.1; Tue, 26 Feb 2013 21:33:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAS9B-0001cE-PP;
	Tue, 26 Feb 2013 21:33:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAS9B-0006aW-Kp;
	Tue, 26 Feb 2013 21:33:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16745-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 26 Feb 2013 21:33:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 16745: 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 16745 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16745/

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. 15418
 test-amd64-i386-xl-qemut-win-vcpus1 8 guest-saverestore fail in 16681 REGR. vs. 15418

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                 fail pass in 16681
 test-amd64-amd64-xl           9 guest-start                 fail pass in 16681
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 16681
 test-amd64-i386-qemut-win-vcpus1 8 guest-saverestore fail in 16681 pass in 16236
 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail in 16681 pass in 16745
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot    fail in 16236 pass in 16681
 test-amd64-i386-xl-qemut-win-vcpus1 3 host-install(3) broken in 16236 pass in 16681

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 15418
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15418

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemut-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-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  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-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-xl-qemut-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-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-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  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1    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-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 16681 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 16681 never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop     fail in 16681 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 16681 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 16681 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 16681 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 16681 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 16681 never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail in 16681 never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail in 16681 never pass
 test-amd64-i386-qemut-win    16 leak-check/check      fail in 16681 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 16681 never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check  fail in 16236 never pass

version targeted for testing:
 linux                21d69845e411bfcee426070af5416ddfba350529
baseline version:
 linux                e1c63f9f42393f7c1dc072db7e0d54e599e96b46

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 22:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22: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 1UASaH-0003iV-5M; Tue, 26 Feb 2013 22:01:13 +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 1UASaF-0003hw-2T
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:01:11 +0000
Received: from [85.158.143.99:38224] by server-2.bemta-4.messagelabs.com id
	AC/45-12656-6A03D215; Tue, 26 Feb 2013 22:01:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361916066!19582904!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7723 invoked from network); 26 Feb 2013 22:01:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 22:01:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QM14eq011567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 22:01: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
	r1QM13j3013841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 22:01:03 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
	r1QM12Oo011462; Tue, 26 Feb 2013 16:01:02 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 14:01:02 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DBDD51C3935; Tue, 26 Feb 2013 17:01:00 -0500 (EST)
Date: Tue, 26 Feb 2013 17:01:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226220100.GA22418@phenom.dumpdata.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CF62C02000078000C12F1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Michal Fiala <fiala@mfiala.net>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 04:51:39PM +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 17:40, Michal Fiala <fiala@mfiala.net> wrote:
> > On 02/26/2013 05:33 PM, Jan Beulich wrote:
> >>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
> >> 
> >> Please don't top post.
> >> 
> >>> The kernel command line from grub.conf
> >>>
> >>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
> >>> console=com2,vga com2=115200,8n1
> >>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
> >>>
> >>> I have not modified reboot type.
> >> 
> >> And did you check your full boot log for an info-level message like
> >> 
> >> "%s series board detected. Selecting %s-method for reboot.\n"
> > 
> > I have only checked normal boot log, see attachment in my first mail.
> > How can I enable info-level message?
> 
> Looks like this has info level messages enabled, and I can't see any
> such message there. So I guess you'll have to add a few printk()-s
> to arch/x86/kernel/reboot.c:native_machine_emergency_restart().

The thing is is that native_machine_emergency_restart is not suppose
to be called. The baremetal machine_ops has that, but we over-write
it with our own and he should get:

         .emergency_restart = xen_emergency_restart,

! So how did his .emergency_restart value get over-written by
native_machine_emergency_restart?

> 
> 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 Tue Feb 26 22:01:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22: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 1UASaH-0003iV-5M; Tue, 26 Feb 2013 22:01:13 +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 1UASaF-0003hw-2T
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:01:11 +0000
Received: from [85.158.143.99:38224] by server-2.bemta-4.messagelabs.com id
	AC/45-12656-6A03D215; Tue, 26 Feb 2013 22:01:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361916066!19582904!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjAwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7723 invoked from network); 26 Feb 2013 22:01:08 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 22:01:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QM14eq011567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 22:01: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
	r1QM13j3013841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 22:01:03 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
	r1QM12Oo011462; Tue, 26 Feb 2013 16:01:02 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 14:01:02 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DBDD51C3935; Tue, 26 Feb 2013 17:01:00 -0500 (EST)
Date: Tue, 26 Feb 2013 17:01:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130226220100.GA22418@phenom.dumpdata.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512CF62C02000078000C12F1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Michal Fiala <fiala@mfiala.net>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, 2013 at 04:51:39PM +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 17:40, Michal Fiala <fiala@mfiala.net> wrote:
> > On 02/26/2013 05:33 PM, Jan Beulich wrote:
> >>>>> On 26.02.13 at 17:28, Michal Fiala <fiala@mfiala.net> wrote:
> >> 
> >> Please don't top post.
> >> 
> >>> The kernel command line from grub.conf
> >>>
> >>> kernel /xen.gz dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin
> >>> console=com2,vga com2=115200,8n1
> >>> module /linux-3.7.5-hardened root=/dev/sda6 console=tty0 console=hvc0
> >>>
> >>> I have not modified reboot type.
> >> 
> >> And did you check your full boot log for an info-level message like
> >> 
> >> "%s series board detected. Selecting %s-method for reboot.\n"
> > 
> > I have only checked normal boot log, see attachment in my first mail.
> > How can I enable info-level message?
> 
> Looks like this has info level messages enabled, and I can't see any
> such message there. So I guess you'll have to add a few printk()-s
> to arch/x86/kernel/reboot.c:native_machine_emergency_restart().

The thing is is that native_machine_emergency_restart is not suppose
to be called. The baremetal machine_ops has that, but we over-write
it with our own and he should get:

         .emergency_restart = xen_emergency_restart,

! So how did his .emergency_restart value get over-written by
native_machine_emergency_restart?

> 
> 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 Tue Feb 26 22:24:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22: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 1UASvy-00043E-Bh; Tue, 26 Feb 2013 22:23:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UASvw-000439-Oh
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:23:36 +0000
Received: from [85.158.143.99:8090] by server-2.bemta-4.messagelabs.com id
	47/DB-12656-7E53D215; Tue, 26 Feb 2013 22:23:35 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361917414!28879483!1
X-Originating-IP: [209.85.128.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16775 invoked from network); 26 Feb 2013 22:23:35 -0000
Received: from mail-ve0-f171.google.com (HELO mail-ve0-f171.google.com)
	(209.85.128.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 22:23:35 -0000
Received: by mail-ve0-f171.google.com with SMTP id b10so4399434vea.16
	for <Xen-devel@lists.xen.org>; Tue, 26 Feb 2013 14:23:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=M356C5jtmBTAgUBvWR7HpJKeOZYQR8y0AAoHRsSblzc=;
	b=nXbFL5IWohUdCQcMvL1LwIo5AEeJ8wnTB/toG0veXBwwy8bZex0+Xi3R3KSA3VEiDj
	ooeQtjsqqATi0o44z4vIu25MH912HzR+pXZZviKkx8c3dNamzH5nPAKJ0m3JZKUPaoQn
	FA5XFmjNQo4ZZ2C3rZaRuyqHwH39pSZx8vtS6C6WbGyPV2D694LZUBUGj78hUG6jLma2
	48lqVrIqEKfB0rXHgCchQr1Mqqxt6RX1iDDaNU43B+xwidm7pDg4YdP7DBSItYHf1/5G
	bJ8xBcHKn2SxHEfvMxSL0ggrSU9lW1F2Jnxp6Y+irLrciPwaD0llNaTMynZttakyACyF
	qBLw==
MIME-Version: 1.0
X-Received: by 10.52.64.208 with SMTP id q16mr10877208vds.93.1361917413778;
	Tue, 26 Feb 2013 14:23:33 -0800 (PST)
Received: by 10.58.231.2 with HTTP; Tue, 26 Feb 2013 14:23:33 -0800 (PST)
In-Reply-To: <512C810402000078000C0FBB@nat28.tlf.novell.com>
References: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
	<512C810402000078000C0FBB@nat28.tlf.novell.com>
Date: Tue, 26 Feb 2013 14:23:33 -0800
Message-ID: <CAJJWZcxLuk-L6RzL6pJrUfbzqbaMvF+6G1mBTJRO1KZ95RBYaw@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] When does Xen build 1:1 direct mapping of all
 physical 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: multipart/mixed; boundary="===============1189284550634428119=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1189284550634428119==
Content-Type: multipart/alternative; boundary=bcaec5016125a9729404d6a81b33

--bcaec5016125a9729404d6a81b33
Content-Type: text/plain; charset=ISO-8859-1

Hi Jan, I think init_frametable() is to initialize frame table, whose
virtual address starts at FRAMETABLE_VIRT_START ? How about the direct 1:1
mapping of all of machine memroy whose virtual address start at
DIRECTMAP_VIRT_START?
Thanks,

On Tue, Feb 26, 2013 at 12:31 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 25.02.13 at 20:51, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> > I assumed that Xen fills up the page table entires for 1:1 direct mapping
> > of all physical memory at start time, but I cannot find the code. Could
> > anyone tell me when Xen builds up pte for this mapping ?
>
> xen/arch/x86/mm.c:init_frametable()
>
> Jan
>
>


-- 
Xinxin

--bcaec5016125a9729404d6a81b33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Jan, I think init_frametable() is to initialize frame table, whose virtu=
al address starts at FRAMETABLE_VIRT_START ? How about the direct 1:1 mappi=
ng of all of machine memroy whose virtual address start at DIRECTMAP_VIRT_S=
TART?<div>
Thanks,<br><br><div class=3D"gmail_quote">On Tue, Feb 26, 2013 at 12:31 AM,=
 Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" tar=
get=3D"_blank">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;padd=
ing-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 25.02.13 at 20:51, Xinxin Jin &lt;<a href=
=3D"mailto:xinxinjin89@gmail.com">xinxinjin89@gmail.com</a>&gt; wrote:<br>
&gt; I assumed that Xen fills up the page table entires for 1:1 direct mapp=
ing<br>
&gt; of all physical memory at start time, but I cannot find the code. Coul=
d<br>
&gt; anyone tell me when Xen builds up pte for this mapping ?<br>
<br>
</div>xen/arch/x86/mm.c:init_frametable()<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Xinxin
</div>

--bcaec5016125a9729404d6a81b33--


--===============1189284550634428119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1189284550634428119==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 22:24:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22: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 1UASvy-00043E-Bh; Tue, 26 Feb 2013 22:23:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UASvw-000439-Oh
	for Xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:23:36 +0000
Received: from [85.158.143.99:8090] by server-2.bemta-4.messagelabs.com id
	47/DB-12656-7E53D215; Tue, 26 Feb 2013 22:23:35 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361917414!28879483!1
X-Originating-IP: [209.85.128.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16775 invoked from network); 26 Feb 2013 22:23:35 -0000
Received: from mail-ve0-f171.google.com (HELO mail-ve0-f171.google.com)
	(209.85.128.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 22:23:35 -0000
Received: by mail-ve0-f171.google.com with SMTP id b10so4399434vea.16
	for <Xen-devel@lists.xen.org>; Tue, 26 Feb 2013 14:23:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=M356C5jtmBTAgUBvWR7HpJKeOZYQR8y0AAoHRsSblzc=;
	b=nXbFL5IWohUdCQcMvL1LwIo5AEeJ8wnTB/toG0veXBwwy8bZex0+Xi3R3KSA3VEiDj
	ooeQtjsqqATi0o44z4vIu25MH912HzR+pXZZviKkx8c3dNamzH5nPAKJ0m3JZKUPaoQn
	FA5XFmjNQo4ZZ2C3rZaRuyqHwH39pSZx8vtS6C6WbGyPV2D694LZUBUGj78hUG6jLma2
	48lqVrIqEKfB0rXHgCchQr1Mqqxt6RX1iDDaNU43B+xwidm7pDg4YdP7DBSItYHf1/5G
	bJ8xBcHKn2SxHEfvMxSL0ggrSU9lW1F2Jnxp6Y+irLrciPwaD0llNaTMynZttakyACyF
	qBLw==
MIME-Version: 1.0
X-Received: by 10.52.64.208 with SMTP id q16mr10877208vds.93.1361917413778;
	Tue, 26 Feb 2013 14:23:33 -0800 (PST)
Received: by 10.58.231.2 with HTTP; Tue, 26 Feb 2013 14:23:33 -0800 (PST)
In-Reply-To: <512C810402000078000C0FBB@nat28.tlf.novell.com>
References: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
	<512C810402000078000C0FBB@nat28.tlf.novell.com>
Date: Tue, 26 Feb 2013 14:23:33 -0800
Message-ID: <CAJJWZcxLuk-L6RzL6pJrUfbzqbaMvF+6G1mBTJRO1KZ95RBYaw@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] When does Xen build 1:1 direct mapping of all
 physical 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: multipart/mixed; boundary="===============1189284550634428119=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1189284550634428119==
Content-Type: multipart/alternative; boundary=bcaec5016125a9729404d6a81b33

--bcaec5016125a9729404d6a81b33
Content-Type: text/plain; charset=ISO-8859-1

Hi Jan, I think init_frametable() is to initialize frame table, whose
virtual address starts at FRAMETABLE_VIRT_START ? How about the direct 1:1
mapping of all of machine memroy whose virtual address start at
DIRECTMAP_VIRT_START?
Thanks,

On Tue, Feb 26, 2013 at 12:31 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 25.02.13 at 20:51, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> > I assumed that Xen fills up the page table entires for 1:1 direct mapping
> > of all physical memory at start time, but I cannot find the code. Could
> > anyone tell me when Xen builds up pte for this mapping ?
>
> xen/arch/x86/mm.c:init_frametable()
>
> Jan
>
>


-- 
Xinxin

--bcaec5016125a9729404d6a81b33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Jan, I think init_frametable() is to initialize frame table, whose virtu=
al address starts at FRAMETABLE_VIRT_START ? How about the direct 1:1 mappi=
ng of all of machine memroy whose virtual address start at DIRECTMAP_VIRT_S=
TART?<div>
Thanks,<br><br><div class=3D"gmail_quote">On Tue, Feb 26, 2013 at 12:31 AM,=
 Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" tar=
get=3D"_blank">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;padd=
ing-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 25.02.13 at 20:51, Xinxin Jin &lt;<a href=
=3D"mailto:xinxinjin89@gmail.com">xinxinjin89@gmail.com</a>&gt; wrote:<br>
&gt; I assumed that Xen fills up the page table entires for 1:1 direct mapp=
ing<br>
&gt; of all physical memory at start time, but I cannot find the code. Coul=
d<br>
&gt; anyone tell me when Xen builds up pte for this mapping ?<br>
<br>
</div>xen/arch/x86/mm.c:init_frametable()<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Xinxin
</div>

--bcaec5016125a9729404d6a81b33--


--===============1189284550634428119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1189284550634428119==--


From xen-devel-bounces@lists.xen.org Tue Feb 26 22:25:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22:25: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 1UASxV-00046h-Rm; Tue, 26 Feb 2013 22:25:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1UASxU-00046Y-S3
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:25:12 +0000
Received: from [85.158.137.99:22148] by server-14.bemta-3.messagelabs.com id
	19/89-23533-3463D215; Tue, 26 Feb 2013 22:25:07 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361917505!17396774!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30866 invoked from network); 26 Feb 2013 22:25:06 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 22:25:06 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 356A5544F2; Tue, 26 Feb 2013 23:25:03 +0100 (CET)
Date: Tue, 26 Feb 2013 23:25:02 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: xen-devel@lists.xen.org
Message-ID: <20130226222502.GB27098@waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xen.org
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1357303220.14291.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] pv-grub: Support bzip2,
 xz and lzo compressed 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 Fri, Jan 04, 2013 at 12:40:20PM +0000, Ian Campbell wrote:
> On Fri, 2013-01-04 at 12:33 +0000, Bastian Blank wrote:
> > Is there a reason not to use the implementations used by the hypervisor?
> Decompressing a potentially untrusted compressed file in the context of
> the hypervisor would open you up to all sorts of security issues. One of
> the points of pv-grub is that the untrusted code runs only with guest
> privileges.

This was not what I meant, but you realized that already.

Anyway, I have some not really nice patches that integrate the
hypervisor bzip2, lzma, xz and lzo code into pv-grub. gzip is not
handled via this code path.

Bastian

-- 
Insufficient facts always invite danger.
		-- Spock, "Space Seed", stardate 3141.9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 22:25:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22:25: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 1UASxV-00046h-Rm; Tue, 26 Feb 2013 22:25:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1UASxU-00046Y-S3
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:25:12 +0000
Received: from [85.158.137.99:22148] by server-14.bemta-3.messagelabs.com id
	19/89-23533-3463D215; Tue, 26 Feb 2013 22:25:07 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361917505!17396774!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30866 invoked from network); 26 Feb 2013 22:25:06 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 22:25:06 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 356A5544F2; Tue, 26 Feb 2013 23:25:03 +0100 (CET)
Date: Tue, 26 Feb 2013 23:25:02 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: xen-devel@lists.xen.org
Message-ID: <20130226222502.GB27098@waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xen.org
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1357303220.14291.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] [PATCH] pv-grub: Support bzip2,
 xz and lzo compressed 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 Fri, Jan 04, 2013 at 12:40:20PM +0000, Ian Campbell wrote:
> On Fri, 2013-01-04 at 12:33 +0000, Bastian Blank wrote:
> > Is there a reason not to use the implementations used by the hypervisor?
> Decompressing a potentially untrusted compressed file in the context of
> the hypervisor would open you up to all sorts of security issues. One of
> the points of pv-grub is that the untrusted code runs only with guest
> privileges.

This was not what I meant, but you realized that already.

Anyway, I have some not really nice patches that integrate the
hypervisor bzip2, lzma, xz and lzo code into pv-grub. gzip is not
handled via this code path.

Bastian

-- 
Insufficient facts always invite danger.
		-- Spock, "Space Seed", stardate 3141.9

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 22:31:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22: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 1UAT3F-0004O4-MN; Tue, 26 Feb 2013 22:31:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1UAT3D-0004Mn-Qa
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:31:08 +0000
Received: from [85.158.137.99:60048] by server-4.bemta-3.messagelabs.com id
	A9/78-17521-6A73D215; Tue, 26 Feb 2013 22:31:02 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361917859!15090469!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7760 invoked from network); 26 Feb 2013 22:30:59 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 22:30:59 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 60988544F2; Tue, 26 Feb 2013 23:30:58 +0100 (CET)
Date: Tue, 26 Feb 2013 23:30:57 +0100
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130226223057.GC27098@waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130226222502.GB27098@waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [RFC] libxc: Move compression support into own 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

Move the existing decompression methods into its own file.

Signed-off-by: Bastian Blank <waldi@debian.org>

diff -r 66f563be41d9 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Tue Feb 19 10:49:53 2013 +0100
+++ b/tools/libxc/Makefile	Tue Feb 26 19:23:05 2013 +0100
@@ -58,6 +58,7 @@
 GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y                 += xc_dom_elfloader.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_bzimageloader.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_dom_decompress.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
@@ -182,8 +183,8 @@
 zlib-options = $(ZLIB)
 endif
 
-xc_dom_bzimageloader.o: CFLAGS += $(call zlib-options,D)
-xc_dom_bzimageloader.opic: CFLAGS += $(call zlib-options,D)
+xc_dom_decompress.o: CFLAGS += $(call zlib-options,D)
+xc_dom_decompress.opic: CFLAGS += $(call zlib-options,D)
 
 libxenguest.so.$(MAJOR).$(MINOR): COMPRESSION_LIBS = $(call zlib-options,l)
 libxenguest.so.$(MAJOR).$(MINOR): $(GUEST_PIC_OBJS) libxenctrl.so
diff -r 66f563be41d9 tools/libxc/xc_dom.h
--- a/tools/libxc/xc_dom.h	Tue Feb 19 10:49:53 2013 +0100
+++ b/tools/libxc/xc_dom.h	Tue Feb 26 19:23:05 2013 +0100
@@ -293,6 +293,17 @@
 void xc_dom_unmap_one(struct xc_dom_image *dom, xen_pfn_t pfn);
 void xc_dom_unmap_all(struct xc_dom_image *dom);
 
+int xc_try_bzip2_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_gzip_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_lzma_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_lzo1x_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_xz_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+
 static inline void *xc_dom_seg_to_ptr(struct xc_dom_image *dom,
                                       struct xc_dom_seg *seg)
 {
diff -r 66f563be41d9 tools/libxc/xc_dom_bzimageloader.c
--- a/tools/libxc/xc_dom_bzimageloader.c	Tue Feb 19 10:49:53 2013 +0100
+++ b/tools/libxc/xc_dom_bzimageloader.c	Tue Feb 26 19:23:05 2013 +0100
@@ -35,533 +35,6 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
-#if defined(HAVE_BZLIB)
-
-#include <bzlib.h>
-
-static int xc_try_bzip2_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    bz_stream stream;
-    int ret;
-    char *out_buf;
-    char *tmp_buf;
-    int retval = -1;
-    unsigned int outsize;
-    uint64_t total;
-
-    stream.bzalloc = NULL;
-    stream.bzfree = NULL;
-    stream.opaque = NULL;
-
-    if ( dom->kernel_size == 0)
-    {
-        DOMPRINTF("BZIP2: Input is 0 size");
-        return -1;
-    }
-
-    ret = BZ2_bzDecompressInit(&stream, 0, 0);
-    if ( ret != BZ_OK )
-    {
-        DOMPRINTF("BZIP2: Error initting stream");
-        return -1;
-    }
-
-    /* sigh.  We don't know up-front how much memory we are going to need
-     * for the output buffer.  Allocate the output buffer to be equal
-     * the input buffer to start, and we'll realloc as needed.
-     */
-    outsize = dom->kernel_size;
-
-    /*
-     * stream.avail_in and outsize are unsigned int, while kernel_size
-     * is a size_t. Check we aren't overflowing.
-     */
-    if ( outsize != dom->kernel_size )
-    {
-        DOMPRINTF("BZIP2: Input too large");
-        goto bzip2_cleanup;
-    }
-
-    out_buf = malloc(outsize);
-    if ( out_buf == NULL )
-    {
-        DOMPRINTF("BZIP2: Failed to alloc memory");
-        goto bzip2_cleanup;
-    }
-
-    stream.next_in = dom->kernel_blob;
-    stream.avail_in = dom->kernel_size;
-
-    stream.next_out = out_buf;
-    stream.avail_out = dom->kernel_size;
-
-    for ( ; ; )
-    {
-        ret = BZ2_bzDecompress(&stream);
-        if ( ret == BZ_STREAM_END )
-        {
-            DOMPRINTF("BZIP2: Saw data stream end");
-            retval = 0;
-            break;
-        }
-        if ( ret != BZ_OK )
-        {
-            DOMPRINTF("BZIP2: error %d", ret);
-            free(out_buf);
-            goto bzip2_cleanup;
-        }
-
-        if ( stream.avail_out == 0 )
-        {
-            /* Protect against output buffer overflow */
-            if ( outsize > UINT_MAX / 2 )
-            {
-                DOMPRINTF("BZIP2: output buffer overflow");
-                free(out_buf);
-                goto bzip2_cleanup;
-            }
-
-            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
-            {
-                DOMPRINTF("BZIP2: output too large");
-                free(out_buf);
-                goto bzip2_cleanup;
-            }
-
-            tmp_buf = realloc(out_buf, outsize * 2);
-            if ( tmp_buf == NULL )
-            {
-                DOMPRINTF("BZIP2: Failed to realloc memory");
-                free(out_buf);
-                goto bzip2_cleanup;
-            }
-            out_buf = tmp_buf;
-
-            stream.next_out = out_buf + outsize;
-            stream.avail_out = (outsize * 2) - outsize;
-            outsize *= 2;
-        }
-        else if ( stream.avail_in == 0 )
-        {
-            /*
-             * If there is output buffer available then this indicates
-             * that BZ2_bzDecompress would like more input data to be
-             * provided.  However our complete input buffer is in
-             * memory and provided upfront so if avail_in is zero this
-             * actually indicates a truncated input.
-             */
-            DOMPRINTF("BZIP2: not enough input");
-            free(out_buf);
-            goto bzip2_cleanup;
-        }
-    }
-
-    total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
-
-    DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
-              __FUNCTION__, *size, (long unsigned int) total);
-
-    *blob = out_buf;
-    *size = total;
-
- bzip2_cleanup:
-    BZ2_bzDecompressEnd(&stream);
-
-    return retval;
-}
-
-#else /* !defined(HAVE_BZLIB) */
-
-static int xc_try_bzip2_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: BZIP2 decompress support unavailable",
-              __FUNCTION__);
-    return -1;
-}
-
-#endif
-
-#if defined(HAVE_LZMA)
-
-#include <lzma.h>
-
-static int _xc_try_lzma_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size,
-    lzma_stream *stream, const char *what)
-{
-    lzma_ret ret;
-    lzma_action action = LZMA_RUN;
-    unsigned char *out_buf;
-    unsigned char *tmp_buf;
-    int retval = -1;
-    size_t outsize;
-    const char *msg;
-
-    if ( dom->kernel_size == 0)
-    {
-        DOMPRINTF("%s: Input is 0 size", what);
-        return -1;
-    }
-
-    /* sigh.  We don't know up-front how much memory we are going to need
-     * for the output buffer.  Allocate the output buffer to be equal
-     * the input buffer to start, and we'll realloc as needed.
-     */
-    outsize = dom->kernel_size;
-    out_buf = malloc(outsize);
-    if ( out_buf == NULL )
-    {
-        DOMPRINTF("%s: Failed to alloc memory", what);
-        goto lzma_cleanup;
-    }
-
-    stream->next_in = dom->kernel_blob;
-    stream->avail_in = dom->kernel_size;
-
-    stream->next_out = out_buf;
-    stream->avail_out = dom->kernel_size;
-
-    for ( ; ; )
-    {
-        ret = lzma_code(stream, action);
-        if ( ret == LZMA_STREAM_END )
-        {
-            DOMPRINTF("%s: Saw data stream end", what);
-            retval = 0;
-            break;
-        }
-        if ( ret != LZMA_OK )
-        {
-            switch ( ret )
-            {
-            case LZMA_MEM_ERROR:
-                msg = strerror(ENOMEM);
-                break;
-
-            case LZMA_MEMLIMIT_ERROR:
-                msg = "Memory usage limit reached";
-                break;
-
-            case LZMA_FORMAT_ERROR:
-                msg = "File format not recognized";
-                break;
-
-            case LZMA_OPTIONS_ERROR:
-                // FIXME: Better message?
-                msg = "Unsupported compression options";
-                break;
-
-            case LZMA_DATA_ERROR:
-                msg = "File is corrupt";
-                break;
-
-            case LZMA_BUF_ERROR:
-                msg = "Unexpected end of input";
-                break;
-
-            default:
-                msg = "Internal program error (bug)";
-                break;
-            }
-            DOMPRINTF("%s: %s decompression error: %s",
-                      __FUNCTION__, what, msg);
-            free(out_buf);
-            goto lzma_cleanup;
-        }
-
-        if ( stream->avail_out == 0 )
-        {
-            /* Protect against output buffer overflow */
-            if ( outsize > SIZE_MAX / 2 )
-            {
-                DOMPRINTF("%s: output buffer overflow", what);
-                free(out_buf);
-                goto lzma_cleanup;
-            }
-
-            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
-            {
-                DOMPRINTF("%s: output too large", what);
-                free(out_buf);
-                goto lzma_cleanup;
-            }
-
-            tmp_buf = realloc(out_buf, outsize * 2);
-            if ( tmp_buf == NULL )
-            {
-                DOMPRINTF("%s: Failed to realloc memory", what);
-                free(out_buf);
-                goto lzma_cleanup;
-            }
-            out_buf = tmp_buf;
-
-            stream->next_out = out_buf + outsize;
-            stream->avail_out = (outsize * 2) - outsize;
-            outsize *= 2;
-        }
-    }
-
-    DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
-              __FUNCTION__, what, *size, (size_t)stream->total_out);
-
-    *blob = out_buf;
-    *size = stream->total_out;
-
- lzma_cleanup:
-    lzma_end(stream);
-
-    return retval;
-}
-
-/* 128 Mb is the minimum size (half-way) documented to work for all inputs. */
-#define LZMA_BLOCK_SIZE (128*1024*1024)
-
-static int xc_try_xz_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    lzma_stream stream = LZMA_STREAM_INIT;
-
-    if ( lzma_stream_decoder(&stream, LZMA_BLOCK_SIZE, 0) != LZMA_OK )
-    {
-        DOMPRINTF("XZ: Failed to init decoder");
-        return -1;
-    }
-
-    return _xc_try_lzma_decode(dom, blob, size, &stream, "XZ");
-}
-
-static int xc_try_lzma_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    lzma_stream stream = LZMA_STREAM_INIT;
-
-    if ( lzma_alone_decoder(&stream, LZMA_BLOCK_SIZE) != LZMA_OK )
-    {
-        DOMPRINTF("LZMA: Failed to init decoder");
-        return -1;
-    }
-
-    return _xc_try_lzma_decode(dom, blob, size, &stream, "LZMA");
-}
-
-#else /* !defined(HAVE_LZMA) */
-
-static int xc_try_xz_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: XZ decompress support unavailable",
-              __FUNCTION__);
-    return -1;
-}
-
-static int xc_try_lzma_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: LZMA decompress support unavailable",
-              __FUNCTION__);
-    return -1;
-}
-
-#endif
-
-#if defined(HAVE_LZO1X)
-
-#include <lzo/lzo1x.h>
-
-#define LZOP_HEADER_HAS_FILTER 0x00000800
-#define LZOP_MAX_BLOCK_SIZE (64*1024*1024)
-
-static inline uint_fast16_t lzo_read_16(const unsigned char *buf)
-{
-    return buf[1] | (buf[0] << 8);
-}
-
-static inline uint_fast32_t lzo_read_32(const unsigned char *buf)
-{
-    return lzo_read_16(buf + 2) | ((uint32_t)lzo_read_16(buf) << 16);
-}
-
-static int xc_try_lzo1x_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    int ret;
-    const unsigned char *cur = dom->kernel_blob;
-    unsigned char *out_buf = NULL;
-    size_t left = dom->kernel_size;
-    const char *msg;
-    unsigned version;
-    static const unsigned char magic[] = {
-        0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a
-    };
-
-    /*
-     * lzo_uint should match size_t. Check that this is the case to be
-     * sure we won't overflow various lzo_uint fields.
-     */
-    XC_BUILD_BUG_ON(sizeof(lzo_uint) != sizeof(size_t));
-
-    ret = lzo_init();
-    if ( ret != LZO_E_OK )
-    {
-        DOMPRINTF("LZO1x: Failed to init library (%d)\n", ret);
-        return -1;
-    }
-
-    if ( left < 16 || memcmp(cur, magic, 9) )
-    {
-        DOMPRINTF("LZO1x: Unrecognized magic\n");
-        return -1;
-    }
-
-    /* get version (2bytes), skip library version (2),
-     * 'need to be extracted' version (2) and method (1) */
-    version = lzo_read_16(cur + 9);
-    cur += 16;
-    left -= 16;
-
-    if ( version >= 0x0940 )
-    {
-        /* skip level */
-        ++cur;
-        if ( left )
-            --left;
-    }
-
-    if ( left >= 4 && (lzo_read_32(cur) & LZOP_HEADER_HAS_FILTER) )
-        ret = 8; /* flags + filter info */
-    else
-        ret = 4; /* flags */
-
-    /* skip mode and mtime_low */
-    ret += 8;
-    if ( version >= 0x0940 )
-        ret += 4; /* skip mtime_high */
-
-    /* don't care about the file name, and skip checksum */
-    if ( left > ret )
-        ret += 1 + cur[ret] + 4;
-
-    if ( left < ret )
-    {
-        DOMPRINTF("LZO1x: Incomplete header\n");
-        return -1;
-    }
-    cur += ret;
-    left -= ret;
-
-    for ( *size = 0; ; )
-    {
-        lzo_uint src_len, dst_len, out_len;
-        unsigned char *tmp_buf;
-
-        msg = "Short input";
-        if ( left < 4 )
-            break;
-
-        dst_len = lzo_read_32(cur);
-        if ( !dst_len )
-            return 0;
-
-        if ( dst_len > LZOP_MAX_BLOCK_SIZE )
-        {
-            msg = "Block size too large";
-            break;
-        }
-
-        if ( left < 12 )
-            break;
-
-        src_len = lzo_read_32(cur + 4);
-        cur += 12; /* also skip block checksum info */
-        left -= 12;
-
-        msg = "Bad source length";
-        if ( src_len <= 0 || src_len > dst_len || src_len > left )
-            break;
-
-        msg = "Output buffer overflow";
-        if ( *size > SIZE_MAX - dst_len )
-            break;
-
-        msg = "Decompressed image too large";
-        if ( xc_dom_kernel_check_size(dom, *size + dst_len) )
-            break;
-
-        msg = "Failed to (re)alloc memory";
-        tmp_buf = realloc(out_buf, *size + dst_len);
-        if ( tmp_buf == NULL )
-            break;
-
-        out_buf = tmp_buf;
-        out_len = dst_len;
-
-        ret = lzo1x_decompress_safe(cur, src_len,
-                                    out_buf + *size, &out_len, NULL);
-        switch ( ret )
-        {
-        case LZO_E_OK:
-            msg = "Input underrun";
-            if ( out_len != dst_len )
-                break;
-
-            *blob = out_buf;
-            *size += out_len;
-            cur += src_len;
-            left -= src_len;
-            continue;
-
-        case LZO_E_INPUT_NOT_CONSUMED:
-            msg = "Unconsumed input";
-            break;
-
-        case LZO_E_OUTPUT_OVERRUN:
-            msg = "Output overrun";
-            break;
-
-        case LZO_E_INPUT_OVERRUN:
-            msg = "Input overrun";
-            break;
-
-        case LZO_E_LOOKBEHIND_OVERRUN:
-            msg = "Look-behind overrun";
-            break;
-
-        case LZO_E_EOF_NOT_FOUND:
-            msg = "No EOF marker";
-            break;
-
-        case LZO_E_ERROR:
-            msg = "General error";
-            break;
-
-        default:
-            msg = "Internal program error (bug)";
-            break;
-        }
-
-        break;
-    }
-
-    free(out_buf);
-    DOMPRINTF("LZO1x decompression error: %s\n", msg);
-
-    return -1;
-}
-
-#else /* !defined(HAVE_LZO1X) */
-
-static int xc_try_lzo1x_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: LZO1x decompress support unavailable\n",
-                  __FUNCTION__);
-    return -1;
-}
-
-#endif
-
 struct setup_header {
     uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
     uint8_t  setup_sects;
diff -r 66f563be41d9 tools/libxc/xc_dom_decompress.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress.c	Tue Feb 26 19:23:05 2013 +0100
@@ -0,0 +1,567 @@
+/*
+ * Xen decompression wrapper
+ *
+ * This library 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 of the License.
+ *
+ * This library 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.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * written 2006 by Gerd Hoffmann <kraxel@suse.de>.
+ * written 2007 by Jeremy Fitzhardinge <jeremy@xensource.com>
+ * written 2008 by Ian Campbell <ijc@hellion.org.uk>
+ * written 2009 by Chris Lalancette <clalance@redhat.com>
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#if defined(HAVE_BZLIB)
+
+#include <bzlib.h>
+
+int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    bz_stream stream;
+    int ret;
+    char *out_buf;
+    char *tmp_buf;
+    int retval = -1;
+    unsigned int outsize;
+    uint64_t total;
+
+    stream.bzalloc = NULL;
+    stream.bzfree = NULL;
+    stream.opaque = NULL;
+
+    if ( dom->kernel_size == 0)
+    {
+        DOMPRINTF("BZIP2: Input is 0 size");
+        return -1;
+    }
+
+    ret = BZ2_bzDecompressInit(&stream, 0, 0);
+    if ( ret != BZ_OK )
+    {
+        DOMPRINTF("BZIP2: Error initting stream");
+        return -1;
+    }
+
+    /* sigh.  We don't know up-front how much memory we are going to need
+     * for the output buffer.  Allocate the output buffer to be equal
+     * the input buffer to start, and we'll realloc as needed.
+     */
+    outsize = dom->kernel_size;
+
+    /*
+     * stream.avail_in and outsize are unsigned int, while kernel_size
+     * is a size_t. Check we aren't overflowing.
+     */
+    if ( outsize != dom->kernel_size )
+    {
+        DOMPRINTF("BZIP2: Input too large");
+        goto bzip2_cleanup;
+    }
+
+    out_buf = malloc(outsize);
+    if ( out_buf == NULL )
+    {
+        DOMPRINTF("BZIP2: Failed to alloc memory");
+        goto bzip2_cleanup;
+    }
+
+    stream.next_in = dom->kernel_blob;
+    stream.avail_in = dom->kernel_size;
+
+    stream.next_out = out_buf;
+    stream.avail_out = dom->kernel_size;
+
+    for ( ; ; )
+    {
+        ret = BZ2_bzDecompress(&stream);
+        if ( ret == BZ_STREAM_END )
+        {
+            DOMPRINTF("BZIP2: Saw data stream end");
+            retval = 0;
+            break;
+        }
+        if ( ret != BZ_OK )
+        {
+            DOMPRINTF("BZIP2: error %d", ret);
+            free(out_buf);
+            goto bzip2_cleanup;
+        }
+
+        if ( stream.avail_out == 0 )
+        {
+            /* Protect against output buffer overflow */
+            if ( outsize > UINT_MAX / 2 )
+            {
+                DOMPRINTF("BZIP2: output buffer overflow");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                DOMPRINTF("BZIP2: output too large");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+
+            tmp_buf = realloc(out_buf, outsize * 2);
+            if ( tmp_buf == NULL )
+            {
+                DOMPRINTF("BZIP2: Failed to realloc memory");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+            out_buf = tmp_buf;
+
+            stream.next_out = out_buf + outsize;
+            stream.avail_out = (outsize * 2) - outsize;
+            outsize *= 2;
+        }
+        else if ( stream.avail_in == 0 )
+        {
+            /*
+             * If there is output buffer available then this indicates
+             * that BZ2_bzDecompress would like more input data to be
+             * provided.  However our complete input buffer is in
+             * memory and provided upfront so if avail_in is zero this
+             * actually indicates a truncated input.
+             */
+            DOMPRINTF("BZIP2: not enough input");
+            free(out_buf);
+            goto bzip2_cleanup;
+        }
+    }
+
+    total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
+
+    DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
+              __FUNCTION__, *size, (long unsigned int) total);
+
+    *blob = out_buf;
+    *size = total;
+
+ bzip2_cleanup:
+    BZ2_bzDecompressEnd(&stream);
+
+    return retval;
+}
+
+#else /* !defined(HAVE_BZLIB) */
+
+int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: BZIP2 decompress support unavailable",
+              __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+#if defined(HAVE_LZMA)
+
+#include <lzma.h>
+
+static int _xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size,
+    lzma_stream *stream, const char *what)
+{
+    lzma_ret ret;
+    lzma_action action = LZMA_RUN;
+    unsigned char *out_buf;
+    unsigned char *tmp_buf;
+    int retval = -1;
+    size_t outsize;
+    const char *msg;
+
+    if ( dom->kernel_size == 0)
+    {
+        DOMPRINTF("%s: Input is 0 size", what);
+        return -1;
+    }
+
+    /* sigh.  We don't know up-front how much memory we are going to need
+     * for the output buffer.  Allocate the output buffer to be equal
+     * the input buffer to start, and we'll realloc as needed.
+     */
+    outsize = dom->kernel_size;
+    out_buf = malloc(outsize);
+    if ( out_buf == NULL )
+    {
+        DOMPRINTF("%s: Failed to alloc memory", what);
+        goto lzma_cleanup;
+    }
+
+    stream->next_in = dom->kernel_blob;
+    stream->avail_in = dom->kernel_size;
+
+    stream->next_out = out_buf;
+    stream->avail_out = dom->kernel_size;
+
+    for ( ; ; )
+    {
+        ret = lzma_code(stream, action);
+        if ( ret == LZMA_STREAM_END )
+        {
+            DOMPRINTF("%s: Saw data stream end", what);
+            retval = 0;
+            break;
+        }
+        if ( ret != LZMA_OK )
+        {
+            switch ( ret )
+            {
+            case LZMA_MEM_ERROR:
+                msg = strerror(ENOMEM);
+                break;
+
+            case LZMA_MEMLIMIT_ERROR:
+                msg = "Memory usage limit reached";
+                break;
+
+            case LZMA_FORMAT_ERROR:
+                msg = "File format not recognized";
+                break;
+
+            case LZMA_OPTIONS_ERROR:
+                // FIXME: Better message?
+                msg = "Unsupported compression options";
+                break;
+
+            case LZMA_DATA_ERROR:
+                msg = "File is corrupt";
+                break;
+
+            case LZMA_BUF_ERROR:
+                msg = "Unexpected end of input";
+                break;
+
+            default:
+                msg = "Internal program error (bug)";
+                break;
+            }
+            DOMPRINTF("%s: %s decompression error: %s",
+                      __FUNCTION__, what, msg);
+            free(out_buf);
+            goto lzma_cleanup;
+        }
+
+        if ( stream->avail_out == 0 )
+        {
+            /* Protect against output buffer overflow */
+            if ( outsize > SIZE_MAX / 2 )
+            {
+                DOMPRINTF("%s: output buffer overflow", what);
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                DOMPRINTF("%s: output too large", what);
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+
+            tmp_buf = realloc(out_buf, outsize * 2);
+            if ( tmp_buf == NULL )
+            {
+                DOMPRINTF("%s: Failed to realloc memory", what);
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+            out_buf = tmp_buf;
+
+            stream->next_out = out_buf + outsize;
+            stream->avail_out = (outsize * 2) - outsize;
+            outsize *= 2;
+        }
+    }
+
+    DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
+              __FUNCTION__, what, *size, (size_t)stream->total_out);
+
+    *blob = out_buf;
+    *size = stream->total_out;
+
+ lzma_cleanup:
+    lzma_end(stream);
+
+    return retval;
+}
+
+/* 128 Mb is the minimum size (half-way) documented to work for all inputs. */
+#define LZMA_BLOCK_SIZE (128*1024*1024)
+
+int xc_try_xz_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    lzma_stream stream = LZMA_STREAM_INIT;
+
+    if ( lzma_stream_decoder(&stream, LZMA_BLOCK_SIZE, 0) != LZMA_OK )
+    {
+        DOMPRINTF("XZ: Failed to init decoder");
+        return -1;
+    }
+
+    return _xc_try_lzma_decode(dom, blob, size, &stream, "XZ");
+}
+
+int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    lzma_stream stream = LZMA_STREAM_INIT;
+
+    if ( lzma_alone_decoder(&stream, LZMA_BLOCK_SIZE) != LZMA_OK )
+    {
+        DOMPRINTF("LZMA: Failed to init decoder");
+        return -1;
+    }
+
+    return _xc_try_lzma_decode(dom, blob, size, &stream, "LZMA");
+}
+
+#else /* !defined(HAVE_LZMA) */
+
+int xc_try_xz_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: XZ decompress support unavailable",
+              __FUNCTION__);
+    return -1;
+}
+
+int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: LZMA decompress support unavailable",
+              __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+#if defined(HAVE_LZO1X)
+
+#include <lzo/lzo1x.h>
+
+#define LZOP_HEADER_HAS_FILTER 0x00000800
+#define LZOP_MAX_BLOCK_SIZE (64*1024*1024)
+
+static inline uint_fast16_t lzo_read_16(const unsigned char *buf)
+{
+    return buf[1] | (buf[0] << 8);
+}
+
+static inline uint_fast32_t lzo_read_32(const unsigned char *buf)
+{
+    return lzo_read_16(buf + 2) | ((uint32_t)lzo_read_16(buf) << 16);
+}
+
+int xc_try_lzo1x_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    int ret;
+    const unsigned char *cur = dom->kernel_blob;
+    unsigned char *out_buf = NULL;
+    size_t left = dom->kernel_size;
+    const char *msg;
+    unsigned version;
+    static const unsigned char magic[] = {
+        0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a
+    };
+
+    /*
+     * lzo_uint should match size_t. Check that this is the case to be
+     * sure we won't overflow various lzo_uint fields.
+     */
+    XC_BUILD_BUG_ON(sizeof(lzo_uint) != sizeof(size_t));
+
+    ret = lzo_init();
+    if ( ret != LZO_E_OK )
+    {
+        DOMPRINTF("LZO1x: Failed to init library (%d)\n", ret);
+        return -1;
+    }
+
+    if ( left < 16 || memcmp(cur, magic, 9) )
+    {
+        DOMPRINTF("LZO1x: Unrecognized magic\n");
+        return -1;
+    }
+
+    /* get version (2bytes), skip library version (2),
+     * 'need to be extracted' version (2) and method (1) */
+    version = lzo_read_16(cur + 9);
+    cur += 16;
+    left -= 16;
+
+    if ( version >= 0x0940 )
+    {
+        /* skip level */
+        ++cur;
+        if ( left )
+            --left;
+    }
+
+    if ( left >= 4 && (lzo_read_32(cur) & LZOP_HEADER_HAS_FILTER) )
+        ret = 8; /* flags + filter info */
+    else
+        ret = 4; /* flags */
+
+    /* skip mode and mtime_low */
+    ret += 8;
+    if ( version >= 0x0940 )
+        ret += 4; /* skip mtime_high */
+
+    /* don't care about the file name, and skip checksum */
+    if ( left > ret )
+        ret += 1 + cur[ret] + 4;
+
+    if ( left < ret )
+    {
+        DOMPRINTF("LZO1x: Incomplete header\n");
+        return -1;
+    }
+    cur += ret;
+    left -= ret;
+
+    for ( *size = 0; ; )
+    {
+        lzo_uint src_len, dst_len, out_len;
+        unsigned char *tmp_buf;
+
+        msg = "Short input";
+        if ( left < 4 )
+            break;
+
+        dst_len = lzo_read_32(cur);
+        if ( !dst_len )
+            return 0;
+
+        if ( dst_len > LZOP_MAX_BLOCK_SIZE )
+        {
+            msg = "Block size too large";
+            break;
+        }
+
+        if ( left < 12 )
+            break;
+
+        src_len = lzo_read_32(cur + 4);
+        cur += 12; /* also skip block checksum info */
+        left -= 12;
+
+        msg = "Bad source length";
+        if ( src_len <= 0 || src_len > dst_len || src_len > left )
+            break;
+
+        msg = "Output buffer overflow";
+        if ( *size > SIZE_MAX - dst_len )
+            break;
+
+        msg = "Decompressed image too large";
+        if ( xc_dom_kernel_check_size(dom, *size + dst_len) )
+            break;
+
+        msg = "Failed to (re)alloc memory";
+        tmp_buf = realloc(out_buf, *size + dst_len);
+        if ( tmp_buf == NULL )
+            break;
+
+        out_buf = tmp_buf;
+        out_len = dst_len;
+
+        ret = lzo1x_decompress_safe(cur, src_len,
+                                    out_buf + *size, &out_len, NULL);
+        switch ( ret )
+        {
+        case LZO_E_OK:
+            msg = "Input underrun";
+            if ( out_len != dst_len )
+                break;
+
+            *blob = out_buf;
+            *size += out_len;
+            cur += src_len;
+            left -= src_len;
+            continue;
+
+        case LZO_E_INPUT_NOT_CONSUMED:
+            msg = "Unconsumed input";
+            break;
+
+        case LZO_E_OUTPUT_OVERRUN:
+            msg = "Output overrun";
+            break;
+
+        case LZO_E_INPUT_OVERRUN:
+            msg = "Input overrun";
+            break;
+
+        case LZO_E_LOOKBEHIND_OVERRUN:
+            msg = "Look-behind overrun";
+            break;
+
+        case LZO_E_EOF_NOT_FOUND:
+            msg = "No EOF marker";
+            break;
+
+        case LZO_E_ERROR:
+            msg = "General error";
+            break;
+
+        default:
+            msg = "Internal program error (bug)";
+            break;
+        }
+
+        break;
+    }
+
+    free(out_buf);
+    DOMPRINTF("LZO1x decompression error: %s\n", msg);
+
+    return -1;
+}
+
+#else /* !defined(HAVE_LZO1X) */
+
+int xc_try_lzo1x_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: LZO1x decompress support unavailable\n",
+                  __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 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 Tue Feb 26 22:31:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22: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 1UAT3F-0004O4-MN; Tue, 26 Feb 2013 22:31:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1UAT3D-0004Mn-Qa
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:31:08 +0000
Received: from [85.158.137.99:60048] by server-4.bemta-3.messagelabs.com id
	A9/78-17521-6A73D215; Tue, 26 Feb 2013 22:31:02 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1361917859!15090469!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7760 invoked from network); 26 Feb 2013 22:30:59 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 22:30:59 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 60988544F2; Tue, 26 Feb 2013 23:30:58 +0100 (CET)
Date: Tue, 26 Feb 2013 23:30:57 +0100
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130226223057.GC27098@waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130226222502.GB27098@waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [RFC] libxc: Move compression support into own 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

Move the existing decompression methods into its own file.

Signed-off-by: Bastian Blank <waldi@debian.org>

diff -r 66f563be41d9 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Tue Feb 19 10:49:53 2013 +0100
+++ b/tools/libxc/Makefile	Tue Feb 26 19:23:05 2013 +0100
@@ -58,6 +58,7 @@
 GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y                 += xc_dom_elfloader.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_bzimageloader.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_dom_decompress.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
@@ -182,8 +183,8 @@
 zlib-options = $(ZLIB)
 endif
 
-xc_dom_bzimageloader.o: CFLAGS += $(call zlib-options,D)
-xc_dom_bzimageloader.opic: CFLAGS += $(call zlib-options,D)
+xc_dom_decompress.o: CFLAGS += $(call zlib-options,D)
+xc_dom_decompress.opic: CFLAGS += $(call zlib-options,D)
 
 libxenguest.so.$(MAJOR).$(MINOR): COMPRESSION_LIBS = $(call zlib-options,l)
 libxenguest.so.$(MAJOR).$(MINOR): $(GUEST_PIC_OBJS) libxenctrl.so
diff -r 66f563be41d9 tools/libxc/xc_dom.h
--- a/tools/libxc/xc_dom.h	Tue Feb 19 10:49:53 2013 +0100
+++ b/tools/libxc/xc_dom.h	Tue Feb 26 19:23:05 2013 +0100
@@ -293,6 +293,17 @@
 void xc_dom_unmap_one(struct xc_dom_image *dom, xen_pfn_t pfn);
 void xc_dom_unmap_all(struct xc_dom_image *dom);
 
+int xc_try_bzip2_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_gzip_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_lzma_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_lzo1x_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+int xc_try_xz_decode(struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+
 static inline void *xc_dom_seg_to_ptr(struct xc_dom_image *dom,
                                       struct xc_dom_seg *seg)
 {
diff -r 66f563be41d9 tools/libxc/xc_dom_bzimageloader.c
--- a/tools/libxc/xc_dom_bzimageloader.c	Tue Feb 19 10:49:53 2013 +0100
+++ b/tools/libxc/xc_dom_bzimageloader.c	Tue Feb 26 19:23:05 2013 +0100
@@ -35,533 +35,6 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 
-#if defined(HAVE_BZLIB)
-
-#include <bzlib.h>
-
-static int xc_try_bzip2_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    bz_stream stream;
-    int ret;
-    char *out_buf;
-    char *tmp_buf;
-    int retval = -1;
-    unsigned int outsize;
-    uint64_t total;
-
-    stream.bzalloc = NULL;
-    stream.bzfree = NULL;
-    stream.opaque = NULL;
-
-    if ( dom->kernel_size == 0)
-    {
-        DOMPRINTF("BZIP2: Input is 0 size");
-        return -1;
-    }
-
-    ret = BZ2_bzDecompressInit(&stream, 0, 0);
-    if ( ret != BZ_OK )
-    {
-        DOMPRINTF("BZIP2: Error initting stream");
-        return -1;
-    }
-
-    /* sigh.  We don't know up-front how much memory we are going to need
-     * for the output buffer.  Allocate the output buffer to be equal
-     * the input buffer to start, and we'll realloc as needed.
-     */
-    outsize = dom->kernel_size;
-
-    /*
-     * stream.avail_in and outsize are unsigned int, while kernel_size
-     * is a size_t. Check we aren't overflowing.
-     */
-    if ( outsize != dom->kernel_size )
-    {
-        DOMPRINTF("BZIP2: Input too large");
-        goto bzip2_cleanup;
-    }
-
-    out_buf = malloc(outsize);
-    if ( out_buf == NULL )
-    {
-        DOMPRINTF("BZIP2: Failed to alloc memory");
-        goto bzip2_cleanup;
-    }
-
-    stream.next_in = dom->kernel_blob;
-    stream.avail_in = dom->kernel_size;
-
-    stream.next_out = out_buf;
-    stream.avail_out = dom->kernel_size;
-
-    for ( ; ; )
-    {
-        ret = BZ2_bzDecompress(&stream);
-        if ( ret == BZ_STREAM_END )
-        {
-            DOMPRINTF("BZIP2: Saw data stream end");
-            retval = 0;
-            break;
-        }
-        if ( ret != BZ_OK )
-        {
-            DOMPRINTF("BZIP2: error %d", ret);
-            free(out_buf);
-            goto bzip2_cleanup;
-        }
-
-        if ( stream.avail_out == 0 )
-        {
-            /* Protect against output buffer overflow */
-            if ( outsize > UINT_MAX / 2 )
-            {
-                DOMPRINTF("BZIP2: output buffer overflow");
-                free(out_buf);
-                goto bzip2_cleanup;
-            }
-
-            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
-            {
-                DOMPRINTF("BZIP2: output too large");
-                free(out_buf);
-                goto bzip2_cleanup;
-            }
-
-            tmp_buf = realloc(out_buf, outsize * 2);
-            if ( tmp_buf == NULL )
-            {
-                DOMPRINTF("BZIP2: Failed to realloc memory");
-                free(out_buf);
-                goto bzip2_cleanup;
-            }
-            out_buf = tmp_buf;
-
-            stream.next_out = out_buf + outsize;
-            stream.avail_out = (outsize * 2) - outsize;
-            outsize *= 2;
-        }
-        else if ( stream.avail_in == 0 )
-        {
-            /*
-             * If there is output buffer available then this indicates
-             * that BZ2_bzDecompress would like more input data to be
-             * provided.  However our complete input buffer is in
-             * memory and provided upfront so if avail_in is zero this
-             * actually indicates a truncated input.
-             */
-            DOMPRINTF("BZIP2: not enough input");
-            free(out_buf);
-            goto bzip2_cleanup;
-        }
-    }
-
-    total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
-
-    DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
-              __FUNCTION__, *size, (long unsigned int) total);
-
-    *blob = out_buf;
-    *size = total;
-
- bzip2_cleanup:
-    BZ2_bzDecompressEnd(&stream);
-
-    return retval;
-}
-
-#else /* !defined(HAVE_BZLIB) */
-
-static int xc_try_bzip2_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: BZIP2 decompress support unavailable",
-              __FUNCTION__);
-    return -1;
-}
-
-#endif
-
-#if defined(HAVE_LZMA)
-
-#include <lzma.h>
-
-static int _xc_try_lzma_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size,
-    lzma_stream *stream, const char *what)
-{
-    lzma_ret ret;
-    lzma_action action = LZMA_RUN;
-    unsigned char *out_buf;
-    unsigned char *tmp_buf;
-    int retval = -1;
-    size_t outsize;
-    const char *msg;
-
-    if ( dom->kernel_size == 0)
-    {
-        DOMPRINTF("%s: Input is 0 size", what);
-        return -1;
-    }
-
-    /* sigh.  We don't know up-front how much memory we are going to need
-     * for the output buffer.  Allocate the output buffer to be equal
-     * the input buffer to start, and we'll realloc as needed.
-     */
-    outsize = dom->kernel_size;
-    out_buf = malloc(outsize);
-    if ( out_buf == NULL )
-    {
-        DOMPRINTF("%s: Failed to alloc memory", what);
-        goto lzma_cleanup;
-    }
-
-    stream->next_in = dom->kernel_blob;
-    stream->avail_in = dom->kernel_size;
-
-    stream->next_out = out_buf;
-    stream->avail_out = dom->kernel_size;
-
-    for ( ; ; )
-    {
-        ret = lzma_code(stream, action);
-        if ( ret == LZMA_STREAM_END )
-        {
-            DOMPRINTF("%s: Saw data stream end", what);
-            retval = 0;
-            break;
-        }
-        if ( ret != LZMA_OK )
-        {
-            switch ( ret )
-            {
-            case LZMA_MEM_ERROR:
-                msg = strerror(ENOMEM);
-                break;
-
-            case LZMA_MEMLIMIT_ERROR:
-                msg = "Memory usage limit reached";
-                break;
-
-            case LZMA_FORMAT_ERROR:
-                msg = "File format not recognized";
-                break;
-
-            case LZMA_OPTIONS_ERROR:
-                // FIXME: Better message?
-                msg = "Unsupported compression options";
-                break;
-
-            case LZMA_DATA_ERROR:
-                msg = "File is corrupt";
-                break;
-
-            case LZMA_BUF_ERROR:
-                msg = "Unexpected end of input";
-                break;
-
-            default:
-                msg = "Internal program error (bug)";
-                break;
-            }
-            DOMPRINTF("%s: %s decompression error: %s",
-                      __FUNCTION__, what, msg);
-            free(out_buf);
-            goto lzma_cleanup;
-        }
-
-        if ( stream->avail_out == 0 )
-        {
-            /* Protect against output buffer overflow */
-            if ( outsize > SIZE_MAX / 2 )
-            {
-                DOMPRINTF("%s: output buffer overflow", what);
-                free(out_buf);
-                goto lzma_cleanup;
-            }
-
-            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
-            {
-                DOMPRINTF("%s: output too large", what);
-                free(out_buf);
-                goto lzma_cleanup;
-            }
-
-            tmp_buf = realloc(out_buf, outsize * 2);
-            if ( tmp_buf == NULL )
-            {
-                DOMPRINTF("%s: Failed to realloc memory", what);
-                free(out_buf);
-                goto lzma_cleanup;
-            }
-            out_buf = tmp_buf;
-
-            stream->next_out = out_buf + outsize;
-            stream->avail_out = (outsize * 2) - outsize;
-            outsize *= 2;
-        }
-    }
-
-    DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
-              __FUNCTION__, what, *size, (size_t)stream->total_out);
-
-    *blob = out_buf;
-    *size = stream->total_out;
-
- lzma_cleanup:
-    lzma_end(stream);
-
-    return retval;
-}
-
-/* 128 Mb is the minimum size (half-way) documented to work for all inputs. */
-#define LZMA_BLOCK_SIZE (128*1024*1024)
-
-static int xc_try_xz_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    lzma_stream stream = LZMA_STREAM_INIT;
-
-    if ( lzma_stream_decoder(&stream, LZMA_BLOCK_SIZE, 0) != LZMA_OK )
-    {
-        DOMPRINTF("XZ: Failed to init decoder");
-        return -1;
-    }
-
-    return _xc_try_lzma_decode(dom, blob, size, &stream, "XZ");
-}
-
-static int xc_try_lzma_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    lzma_stream stream = LZMA_STREAM_INIT;
-
-    if ( lzma_alone_decoder(&stream, LZMA_BLOCK_SIZE) != LZMA_OK )
-    {
-        DOMPRINTF("LZMA: Failed to init decoder");
-        return -1;
-    }
-
-    return _xc_try_lzma_decode(dom, blob, size, &stream, "LZMA");
-}
-
-#else /* !defined(HAVE_LZMA) */
-
-static int xc_try_xz_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: XZ decompress support unavailable",
-              __FUNCTION__);
-    return -1;
-}
-
-static int xc_try_lzma_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: LZMA decompress support unavailable",
-              __FUNCTION__);
-    return -1;
-}
-
-#endif
-
-#if defined(HAVE_LZO1X)
-
-#include <lzo/lzo1x.h>
-
-#define LZOP_HEADER_HAS_FILTER 0x00000800
-#define LZOP_MAX_BLOCK_SIZE (64*1024*1024)
-
-static inline uint_fast16_t lzo_read_16(const unsigned char *buf)
-{
-    return buf[1] | (buf[0] << 8);
-}
-
-static inline uint_fast32_t lzo_read_32(const unsigned char *buf)
-{
-    return lzo_read_16(buf + 2) | ((uint32_t)lzo_read_16(buf) << 16);
-}
-
-static int xc_try_lzo1x_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    int ret;
-    const unsigned char *cur = dom->kernel_blob;
-    unsigned char *out_buf = NULL;
-    size_t left = dom->kernel_size;
-    const char *msg;
-    unsigned version;
-    static const unsigned char magic[] = {
-        0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a
-    };
-
-    /*
-     * lzo_uint should match size_t. Check that this is the case to be
-     * sure we won't overflow various lzo_uint fields.
-     */
-    XC_BUILD_BUG_ON(sizeof(lzo_uint) != sizeof(size_t));
-
-    ret = lzo_init();
-    if ( ret != LZO_E_OK )
-    {
-        DOMPRINTF("LZO1x: Failed to init library (%d)\n", ret);
-        return -1;
-    }
-
-    if ( left < 16 || memcmp(cur, magic, 9) )
-    {
-        DOMPRINTF("LZO1x: Unrecognized magic\n");
-        return -1;
-    }
-
-    /* get version (2bytes), skip library version (2),
-     * 'need to be extracted' version (2) and method (1) */
-    version = lzo_read_16(cur + 9);
-    cur += 16;
-    left -= 16;
-
-    if ( version >= 0x0940 )
-    {
-        /* skip level */
-        ++cur;
-        if ( left )
-            --left;
-    }
-
-    if ( left >= 4 && (lzo_read_32(cur) & LZOP_HEADER_HAS_FILTER) )
-        ret = 8; /* flags + filter info */
-    else
-        ret = 4; /* flags */
-
-    /* skip mode and mtime_low */
-    ret += 8;
-    if ( version >= 0x0940 )
-        ret += 4; /* skip mtime_high */
-
-    /* don't care about the file name, and skip checksum */
-    if ( left > ret )
-        ret += 1 + cur[ret] + 4;
-
-    if ( left < ret )
-    {
-        DOMPRINTF("LZO1x: Incomplete header\n");
-        return -1;
-    }
-    cur += ret;
-    left -= ret;
-
-    for ( *size = 0; ; )
-    {
-        lzo_uint src_len, dst_len, out_len;
-        unsigned char *tmp_buf;
-
-        msg = "Short input";
-        if ( left < 4 )
-            break;
-
-        dst_len = lzo_read_32(cur);
-        if ( !dst_len )
-            return 0;
-
-        if ( dst_len > LZOP_MAX_BLOCK_SIZE )
-        {
-            msg = "Block size too large";
-            break;
-        }
-
-        if ( left < 12 )
-            break;
-
-        src_len = lzo_read_32(cur + 4);
-        cur += 12; /* also skip block checksum info */
-        left -= 12;
-
-        msg = "Bad source length";
-        if ( src_len <= 0 || src_len > dst_len || src_len > left )
-            break;
-
-        msg = "Output buffer overflow";
-        if ( *size > SIZE_MAX - dst_len )
-            break;
-
-        msg = "Decompressed image too large";
-        if ( xc_dom_kernel_check_size(dom, *size + dst_len) )
-            break;
-
-        msg = "Failed to (re)alloc memory";
-        tmp_buf = realloc(out_buf, *size + dst_len);
-        if ( tmp_buf == NULL )
-            break;
-
-        out_buf = tmp_buf;
-        out_len = dst_len;
-
-        ret = lzo1x_decompress_safe(cur, src_len,
-                                    out_buf + *size, &out_len, NULL);
-        switch ( ret )
-        {
-        case LZO_E_OK:
-            msg = "Input underrun";
-            if ( out_len != dst_len )
-                break;
-
-            *blob = out_buf;
-            *size += out_len;
-            cur += src_len;
-            left -= src_len;
-            continue;
-
-        case LZO_E_INPUT_NOT_CONSUMED:
-            msg = "Unconsumed input";
-            break;
-
-        case LZO_E_OUTPUT_OVERRUN:
-            msg = "Output overrun";
-            break;
-
-        case LZO_E_INPUT_OVERRUN:
-            msg = "Input overrun";
-            break;
-
-        case LZO_E_LOOKBEHIND_OVERRUN:
-            msg = "Look-behind overrun";
-            break;
-
-        case LZO_E_EOF_NOT_FOUND:
-            msg = "No EOF marker";
-            break;
-
-        case LZO_E_ERROR:
-            msg = "General error";
-            break;
-
-        default:
-            msg = "Internal program error (bug)";
-            break;
-        }
-
-        break;
-    }
-
-    free(out_buf);
-    DOMPRINTF("LZO1x decompression error: %s\n", msg);
-
-    return -1;
-}
-
-#else /* !defined(HAVE_LZO1X) */
-
-static int xc_try_lzo1x_decode(
-    struct xc_dom_image *dom, void **blob, size_t *size)
-{
-    DOMPRINTF("%s: LZO1x decompress support unavailable\n",
-                  __FUNCTION__);
-    return -1;
-}
-
-#endif
-
 struct setup_header {
     uint8_t  _pad0[0x1f1];  /* skip uninteresting stuff */
     uint8_t  setup_sects;
diff -r 66f563be41d9 tools/libxc/xc_dom_decompress.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress.c	Tue Feb 26 19:23:05 2013 +0100
@@ -0,0 +1,567 @@
+/*
+ * Xen decompression wrapper
+ *
+ * This library 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 of the License.
+ *
+ * This library 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.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * written 2006 by Gerd Hoffmann <kraxel@suse.de>.
+ * written 2007 by Jeremy Fitzhardinge <jeremy@xensource.com>
+ * written 2008 by Ian Campbell <ijc@hellion.org.uk>
+ * written 2009 by Chris Lalancette <clalance@redhat.com>
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+
+#if defined(HAVE_BZLIB)
+
+#include <bzlib.h>
+
+int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    bz_stream stream;
+    int ret;
+    char *out_buf;
+    char *tmp_buf;
+    int retval = -1;
+    unsigned int outsize;
+    uint64_t total;
+
+    stream.bzalloc = NULL;
+    stream.bzfree = NULL;
+    stream.opaque = NULL;
+
+    if ( dom->kernel_size == 0)
+    {
+        DOMPRINTF("BZIP2: Input is 0 size");
+        return -1;
+    }
+
+    ret = BZ2_bzDecompressInit(&stream, 0, 0);
+    if ( ret != BZ_OK )
+    {
+        DOMPRINTF("BZIP2: Error initting stream");
+        return -1;
+    }
+
+    /* sigh.  We don't know up-front how much memory we are going to need
+     * for the output buffer.  Allocate the output buffer to be equal
+     * the input buffer to start, and we'll realloc as needed.
+     */
+    outsize = dom->kernel_size;
+
+    /*
+     * stream.avail_in and outsize are unsigned int, while kernel_size
+     * is a size_t. Check we aren't overflowing.
+     */
+    if ( outsize != dom->kernel_size )
+    {
+        DOMPRINTF("BZIP2: Input too large");
+        goto bzip2_cleanup;
+    }
+
+    out_buf = malloc(outsize);
+    if ( out_buf == NULL )
+    {
+        DOMPRINTF("BZIP2: Failed to alloc memory");
+        goto bzip2_cleanup;
+    }
+
+    stream.next_in = dom->kernel_blob;
+    stream.avail_in = dom->kernel_size;
+
+    stream.next_out = out_buf;
+    stream.avail_out = dom->kernel_size;
+
+    for ( ; ; )
+    {
+        ret = BZ2_bzDecompress(&stream);
+        if ( ret == BZ_STREAM_END )
+        {
+            DOMPRINTF("BZIP2: Saw data stream end");
+            retval = 0;
+            break;
+        }
+        if ( ret != BZ_OK )
+        {
+            DOMPRINTF("BZIP2: error %d", ret);
+            free(out_buf);
+            goto bzip2_cleanup;
+        }
+
+        if ( stream.avail_out == 0 )
+        {
+            /* Protect against output buffer overflow */
+            if ( outsize > UINT_MAX / 2 )
+            {
+                DOMPRINTF("BZIP2: output buffer overflow");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                DOMPRINTF("BZIP2: output too large");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+
+            tmp_buf = realloc(out_buf, outsize * 2);
+            if ( tmp_buf == NULL )
+            {
+                DOMPRINTF("BZIP2: Failed to realloc memory");
+                free(out_buf);
+                goto bzip2_cleanup;
+            }
+            out_buf = tmp_buf;
+
+            stream.next_out = out_buf + outsize;
+            stream.avail_out = (outsize * 2) - outsize;
+            outsize *= 2;
+        }
+        else if ( stream.avail_in == 0 )
+        {
+            /*
+             * If there is output buffer available then this indicates
+             * that BZ2_bzDecompress would like more input data to be
+             * provided.  However our complete input buffer is in
+             * memory and provided upfront so if avail_in is zero this
+             * actually indicates a truncated input.
+             */
+            DOMPRINTF("BZIP2: not enough input");
+            free(out_buf);
+            goto bzip2_cleanup;
+        }
+    }
+
+    total = (((uint64_t)stream.total_out_hi32) << 32) | stream.total_out_lo32;
+
+    DOMPRINTF("%s: BZIP2 decompress OK, 0x%zx -> 0x%lx",
+              __FUNCTION__, *size, (long unsigned int) total);
+
+    *blob = out_buf;
+    *size = total;
+
+ bzip2_cleanup:
+    BZ2_bzDecompressEnd(&stream);
+
+    return retval;
+}
+
+#else /* !defined(HAVE_BZLIB) */
+
+int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: BZIP2 decompress support unavailable",
+              __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+#if defined(HAVE_LZMA)
+
+#include <lzma.h>
+
+static int _xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size,
+    lzma_stream *stream, const char *what)
+{
+    lzma_ret ret;
+    lzma_action action = LZMA_RUN;
+    unsigned char *out_buf;
+    unsigned char *tmp_buf;
+    int retval = -1;
+    size_t outsize;
+    const char *msg;
+
+    if ( dom->kernel_size == 0)
+    {
+        DOMPRINTF("%s: Input is 0 size", what);
+        return -1;
+    }
+
+    /* sigh.  We don't know up-front how much memory we are going to need
+     * for the output buffer.  Allocate the output buffer to be equal
+     * the input buffer to start, and we'll realloc as needed.
+     */
+    outsize = dom->kernel_size;
+    out_buf = malloc(outsize);
+    if ( out_buf == NULL )
+    {
+        DOMPRINTF("%s: Failed to alloc memory", what);
+        goto lzma_cleanup;
+    }
+
+    stream->next_in = dom->kernel_blob;
+    stream->avail_in = dom->kernel_size;
+
+    stream->next_out = out_buf;
+    stream->avail_out = dom->kernel_size;
+
+    for ( ; ; )
+    {
+        ret = lzma_code(stream, action);
+        if ( ret == LZMA_STREAM_END )
+        {
+            DOMPRINTF("%s: Saw data stream end", what);
+            retval = 0;
+            break;
+        }
+        if ( ret != LZMA_OK )
+        {
+            switch ( ret )
+            {
+            case LZMA_MEM_ERROR:
+                msg = strerror(ENOMEM);
+                break;
+
+            case LZMA_MEMLIMIT_ERROR:
+                msg = "Memory usage limit reached";
+                break;
+
+            case LZMA_FORMAT_ERROR:
+                msg = "File format not recognized";
+                break;
+
+            case LZMA_OPTIONS_ERROR:
+                // FIXME: Better message?
+                msg = "Unsupported compression options";
+                break;
+
+            case LZMA_DATA_ERROR:
+                msg = "File is corrupt";
+                break;
+
+            case LZMA_BUF_ERROR:
+                msg = "Unexpected end of input";
+                break;
+
+            default:
+                msg = "Internal program error (bug)";
+                break;
+            }
+            DOMPRINTF("%s: %s decompression error: %s",
+                      __FUNCTION__, what, msg);
+            free(out_buf);
+            goto lzma_cleanup;
+        }
+
+        if ( stream->avail_out == 0 )
+        {
+            /* Protect against output buffer overflow */
+            if ( outsize > SIZE_MAX / 2 )
+            {
+                DOMPRINTF("%s: output buffer overflow", what);
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+
+            if ( xc_dom_kernel_check_size(dom, outsize * 2) )
+            {
+                DOMPRINTF("%s: output too large", what);
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+
+            tmp_buf = realloc(out_buf, outsize * 2);
+            if ( tmp_buf == NULL )
+            {
+                DOMPRINTF("%s: Failed to realloc memory", what);
+                free(out_buf);
+                goto lzma_cleanup;
+            }
+            out_buf = tmp_buf;
+
+            stream->next_out = out_buf + outsize;
+            stream->avail_out = (outsize * 2) - outsize;
+            outsize *= 2;
+        }
+    }
+
+    DOMPRINTF("%s: %s decompress OK, 0x%zx -> 0x%zx",
+              __FUNCTION__, what, *size, (size_t)stream->total_out);
+
+    *blob = out_buf;
+    *size = stream->total_out;
+
+ lzma_cleanup:
+    lzma_end(stream);
+
+    return retval;
+}
+
+/* 128 Mb is the minimum size (half-way) documented to work for all inputs. */
+#define LZMA_BLOCK_SIZE (128*1024*1024)
+
+int xc_try_xz_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    lzma_stream stream = LZMA_STREAM_INIT;
+
+    if ( lzma_stream_decoder(&stream, LZMA_BLOCK_SIZE, 0) != LZMA_OK )
+    {
+        DOMPRINTF("XZ: Failed to init decoder");
+        return -1;
+    }
+
+    return _xc_try_lzma_decode(dom, blob, size, &stream, "XZ");
+}
+
+int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    lzma_stream stream = LZMA_STREAM_INIT;
+
+    if ( lzma_alone_decoder(&stream, LZMA_BLOCK_SIZE) != LZMA_OK )
+    {
+        DOMPRINTF("LZMA: Failed to init decoder");
+        return -1;
+    }
+
+    return _xc_try_lzma_decode(dom, blob, size, &stream, "LZMA");
+}
+
+#else /* !defined(HAVE_LZMA) */
+
+int xc_try_xz_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: XZ decompress support unavailable",
+              __FUNCTION__);
+    return -1;
+}
+
+int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: LZMA decompress support unavailable",
+              __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+#if defined(HAVE_LZO1X)
+
+#include <lzo/lzo1x.h>
+
+#define LZOP_HEADER_HAS_FILTER 0x00000800
+#define LZOP_MAX_BLOCK_SIZE (64*1024*1024)
+
+static inline uint_fast16_t lzo_read_16(const unsigned char *buf)
+{
+    return buf[1] | (buf[0] << 8);
+}
+
+static inline uint_fast32_t lzo_read_32(const unsigned char *buf)
+{
+    return lzo_read_16(buf + 2) | ((uint32_t)lzo_read_16(buf) << 16);
+}
+
+int xc_try_lzo1x_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    int ret;
+    const unsigned char *cur = dom->kernel_blob;
+    unsigned char *out_buf = NULL;
+    size_t left = dom->kernel_size;
+    const char *msg;
+    unsigned version;
+    static const unsigned char magic[] = {
+        0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a
+    };
+
+    /*
+     * lzo_uint should match size_t. Check that this is the case to be
+     * sure we won't overflow various lzo_uint fields.
+     */
+    XC_BUILD_BUG_ON(sizeof(lzo_uint) != sizeof(size_t));
+
+    ret = lzo_init();
+    if ( ret != LZO_E_OK )
+    {
+        DOMPRINTF("LZO1x: Failed to init library (%d)\n", ret);
+        return -1;
+    }
+
+    if ( left < 16 || memcmp(cur, magic, 9) )
+    {
+        DOMPRINTF("LZO1x: Unrecognized magic\n");
+        return -1;
+    }
+
+    /* get version (2bytes), skip library version (2),
+     * 'need to be extracted' version (2) and method (1) */
+    version = lzo_read_16(cur + 9);
+    cur += 16;
+    left -= 16;
+
+    if ( version >= 0x0940 )
+    {
+        /* skip level */
+        ++cur;
+        if ( left )
+            --left;
+    }
+
+    if ( left >= 4 && (lzo_read_32(cur) & LZOP_HEADER_HAS_FILTER) )
+        ret = 8; /* flags + filter info */
+    else
+        ret = 4; /* flags */
+
+    /* skip mode and mtime_low */
+    ret += 8;
+    if ( version >= 0x0940 )
+        ret += 4; /* skip mtime_high */
+
+    /* don't care about the file name, and skip checksum */
+    if ( left > ret )
+        ret += 1 + cur[ret] + 4;
+
+    if ( left < ret )
+    {
+        DOMPRINTF("LZO1x: Incomplete header\n");
+        return -1;
+    }
+    cur += ret;
+    left -= ret;
+
+    for ( *size = 0; ; )
+    {
+        lzo_uint src_len, dst_len, out_len;
+        unsigned char *tmp_buf;
+
+        msg = "Short input";
+        if ( left < 4 )
+            break;
+
+        dst_len = lzo_read_32(cur);
+        if ( !dst_len )
+            return 0;
+
+        if ( dst_len > LZOP_MAX_BLOCK_SIZE )
+        {
+            msg = "Block size too large";
+            break;
+        }
+
+        if ( left < 12 )
+            break;
+
+        src_len = lzo_read_32(cur + 4);
+        cur += 12; /* also skip block checksum info */
+        left -= 12;
+
+        msg = "Bad source length";
+        if ( src_len <= 0 || src_len > dst_len || src_len > left )
+            break;
+
+        msg = "Output buffer overflow";
+        if ( *size > SIZE_MAX - dst_len )
+            break;
+
+        msg = "Decompressed image too large";
+        if ( xc_dom_kernel_check_size(dom, *size + dst_len) )
+            break;
+
+        msg = "Failed to (re)alloc memory";
+        tmp_buf = realloc(out_buf, *size + dst_len);
+        if ( tmp_buf == NULL )
+            break;
+
+        out_buf = tmp_buf;
+        out_len = dst_len;
+
+        ret = lzo1x_decompress_safe(cur, src_len,
+                                    out_buf + *size, &out_len, NULL);
+        switch ( ret )
+        {
+        case LZO_E_OK:
+            msg = "Input underrun";
+            if ( out_len != dst_len )
+                break;
+
+            *blob = out_buf;
+            *size += out_len;
+            cur += src_len;
+            left -= src_len;
+            continue;
+
+        case LZO_E_INPUT_NOT_CONSUMED:
+            msg = "Unconsumed input";
+            break;
+
+        case LZO_E_OUTPUT_OVERRUN:
+            msg = "Output overrun";
+            break;
+
+        case LZO_E_INPUT_OVERRUN:
+            msg = "Input overrun";
+            break;
+
+        case LZO_E_LOOKBEHIND_OVERRUN:
+            msg = "Look-behind overrun";
+            break;
+
+        case LZO_E_EOF_NOT_FOUND:
+            msg = "No EOF marker";
+            break;
+
+        case LZO_E_ERROR:
+            msg = "General error";
+            break;
+
+        default:
+            msg = "Internal program error (bug)";
+            break;
+        }
+
+        break;
+    }
+
+    free(out_buf);
+    DOMPRINTF("LZO1x decompression error: %s\n", msg);
+
+    return -1;
+}
+
+#else /* !defined(HAVE_LZO1X) */
+
+int xc_try_lzo1x_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    DOMPRINTF("%s: LZO1x decompress support unavailable\n",
+                  __FUNCTION__);
+    return -1;
+}
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 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 Tue Feb 26 22:33:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22:33: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 1UAT4v-0004Tl-Dg; Tue, 26 Feb 2013 22:32:53 +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 1UAT4u-0004TX-7a
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:32:52 +0000
Received: from [85.158.143.99:39858] by server-1.bemta-4.messagelabs.com id
	BA/1A-06203-3183D215; Tue, 26 Feb 2013 22:32:51 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361917969!28409710!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15940 invoked from network); 26 Feb 2013 22:32:50 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 22:32:50 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 5D965544F2; Tue, 26 Feb 2013 23:32:49 +0100 (CET)
Date: Tue, 26 Feb 2013 23:32:49 +0100
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130226223249.GD27098@waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130226222502.GB27098@waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 trusted decompressors based on hypervisor code.
This are used in mini-os by pv-grub.

Signed-off-by: Bastian Blank <waldi@debian.org>

diff -r efdc4bbfdd20 stubdom/Makefile
--- a/stubdom/Makefile	Tue Feb 26 19:42:36 2013 +0100
+++ b/stubdom/Makefile	Tue Feb 26 23:20:22 2013 +0100
@@ -328,7 +328,7 @@
 .PHONY: libxc
 libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a
 libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib
-	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH)
 
  libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a
 
diff -r efdc4bbfdd20 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Tue Feb 26 19:42:36 2013 +0100
+++ b/tools/libxc/Makefile	Tue Feb 26 23:20:22 2013 +0100
@@ -58,7 +58,6 @@
 GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y                 += xc_dom_elfloader.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_bzimageloader.c
-GUEST_SRCS-$(CONFIG_X86)     += xc_dom_decompress.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
@@ -69,6 +68,16 @@
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
+ifeq ($(CONFIG_LIBXC_MINIOS),y)
+GUEST_SRCS-y                 += xc_dom_decompress_trusted.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_bzip2.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzma.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzo1x.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_xz.c
+else
+GUEST_SRCS-y                 += xc_dom_decompress.c
+endif
+
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
 -include $(XEN_TARGET_ARCH)/Makefile
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,49 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+struct xc_dom_image *trusted_dom;
+static unsigned char *output_blob;
+static unsigned int output_size;
+
+static void trusted_error(const char *msg)
+{
+    xc_dom_panic(trusted_dom->xch, XC_INVALID_KERNEL, "%s", msg);
+}
+
+static int trusted_flush(void *src, unsigned int size)
+{
+    void *n = realloc(output_blob, output_size + size);
+    if (!n)
+        return -1;
+    output_blob = n;
+
+    memcpy(&output_blob[output_size], src, size);
+    output_size += size;
+    return size;
+}
+
+int xc_dom_decompress_trusted_decompress(
+    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    int ret;
+
+    trusted_dom = dom;
+    output_blob = NULL;
+    output_size = 0;
+
+    ret = fn(dom->kernel_blob, dom->kernel_size, NULL, trusted_flush, NULL, NULL, trusted_error);
+
+    if (ret)
+        free(output_blob);
+    else {
+        *blob = output_blob;
+        *size = output_size;
+    }
+
+    return ret;
+}
+
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted.h	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,12 @@
+#include "xc_dom.h"
+
+typedef int decompress_fn(unsigned char *inbuf, unsigned int len,
+                          int (*fill)(void*, unsigned int),
+                          int (*flush)(void*, unsigned int),
+                          unsigned char *outbuf, unsigned int *posp,
+                          void (*error)(const char *x));
+
+int xc_dom_decompress_trusted_decompress(
+    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_bzip2.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_bzip2.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,14 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+#include "../../xen/common/bunzip2.c"
+
+int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(bunzip2, dom, blob, size);
+}
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzma.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_lzma.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,14 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+#include "../../xen/common/unlzma.c"
+
+int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(unlzma, dom, blob, size);
+}
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzo1x.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_lzo1x.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,15 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+#include "../../xen/common/lzo.c"
+#include "../../xen/common/unlzo.c"
+
+int xc_try_lzo1x_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(unlzo, dom, blob, size);
+}
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_xz.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_xz.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,17 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+// TODO
+#define XZ_DEC_X86
+
+#include "../../xen/common/unxz.c"
+
+int xc_try_xz_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(unxz, dom, blob, size);
+}
diff -r efdc4bbfdd20 xen/common/decompress.h
--- a/xen/common/decompress.h	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/decompress.h	Tue Feb 26 23:20:22 2013 +0100
@@ -1,3 +1,5 @@
+#ifdef __XEN__
+
 #include <xen/config.h>
 #include <xen/cache.h>
 #include <xen/decompress.h>
@@ -15,3 +17,14 @@
 
 #define large_malloc xmalloc_bytes
 #define large_free xfree
+
+#else
+
+#define STATIC static
+#define INIT
+#define INITDATA
+
+#define large_malloc malloc
+#define large_free free
+
+#endif
diff -r efdc4bbfdd20 xen/common/lzo.c
--- a/xen/common/lzo.c	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/lzo.c	Tue Feb 26 23:20:22 2013 +0100
@@ -68,7 +68,19 @@
  *  Richard Purdie <rpurdie@openedhand.com>
  */
 
+#ifndef __MINIOS__
 #include <xen/types.h>
+#else
+#include <stdint.h>
+
+typedef uint32_t u32;
+typedef uint16_t u16;
+
+#define likely(a) a
+#define noinline
+#define unlikely(a) a
+#endif
+
 #include <xen/lzo.h>
 #define get_unaligned(_p) (*(_p))
 #define put_unaligned(_val,_p) (*(_p)=_val)
diff -r efdc4bbfdd20 xen/common/unlzma.c
--- a/xen/common/unlzma.c	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/unlzma.c	Tue Feb 26 23:20:22 2013 +0100
@@ -54,7 +54,9 @@
  * Copyright (c) 1999-2005  Igor Pavlov
  */
 
+#ifndef __MINIOS__
 #include <xen/compiler.h>
+#endif
 
 #define LZMA_IOBUF_SIZE	0x10000
 
diff -r efdc4bbfdd20 xen/common/unlzo.c
--- a/xen/common/unlzo.c	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/unlzo.c	Tue Feb 26 23:20:22 2013 +0100
@@ -32,7 +32,43 @@
 
 #include "decompress.h"
 #include <xen/lzo.h>
+
+#ifndef __MINIOS__
 #include <asm/byteorder.h>
+#else
+#include <endian.h>
+#include <stdint.h>
+
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+
+static inline u16 be16_to_cpup(const u16 *p)
+{
+	u16 v = *p;
+#if BYTE_ORDER == LITTLE_ENDIAN
+	return (((v & 0x00ffU) << 8) |
+                ((v & 0xff00U) >> 8));
+#else
+	return v;
+#endif
+}
+
+static inline u32 be32_to_cpup(const u32 *p)
+{
+	u32 v = *p;
+#if BYTE_ORDER == LITTLE_ENDIAN
+	return (((v & 0x000000ffUL) << 24) |
+                ((v & 0x0000ff00UL) <<  8) |
+                ((v & 0x00ff0000UL) >>  8) |
+                ((v & 0xff000000UL) >> 24));
+#else
+	return v;
+#endif
+}
+
+#define unlikely(a) a
+#endif
 
 #if 1 /* ndef CONFIG_??? */
 static inline u16 INIT get_unaligned_be16(void *p)
diff -r efdc4bbfdd20 xen/common/xz/private.h
--- a/xen/common/xz/private.h	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/xz/private.h	Tue Feb 26 23:20:22 2013 +0100
@@ -10,8 +10,53 @@
 #ifndef XZ_PRIVATE_H
 #define XZ_PRIVATE_H
 
+#ifndef __MINIOS__
 #include <xen/kernel.h>
 #include <asm/byteorder.h>
+#else
+#include <endian.h>
+#include <stddef.h>
+#include <stdint.h>
+
+typedef char bool_t;
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint32_t __le32;
+
+static inline u32 cpu_to_le32(const u32 v)
+{
+#if BYTE_ORDER == BIG_ENDIAN
+	return (((v & 0x000000ffUL) << 24) |
+	        ((v & 0x0000ff00UL) <<  8) |
+	        ((v & 0x00ff0000UL) >>  8) |
+	        ((v & 0xff000000UL) >> 24));
+#else  
+	return v;
+#endif
+}
+
+static inline u32 le32_to_cpup(const u32 *p)
+{
+	return cpu_to_le32(*p);
+}
+
+#define min(x,y) ({ \
+        const typeof(x) _x = (x);       \
+        const typeof(y) _y = (y);       \
+        (void) (&_x == &_y);            \
+        _x < _y ? _x : _y; })
+
+#define min_t(type,x,y) \
+        ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
+#define max_t(type,x,y) \
+        ({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
+
+#define __force
+#define always_inline
+
+#endif
+
 #define get_le32(p) le32_to_cpup((const uint32_t *)(p))
 
 #if 1 /* ndef CONFIG_??? */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 22:33:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22:33: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 1UAT4v-0004Tl-Dg; Tue, 26 Feb 2013 22:32:53 +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 1UAT4u-0004TX-7a
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:32:52 +0000
Received: from [85.158.143.99:39858] by server-1.bemta-4.messagelabs.com id
	BA/1A-06203-3183D215; Tue, 26 Feb 2013 22:32:51 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361917969!28409710!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15940 invoked from network); 26 Feb 2013 22:32:50 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 22:32:50 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 5D965544F2; Tue, 26 Feb 2013 23:32:49 +0100 (CET)
Date: Tue, 26 Feb 2013 23:32:49 +0100
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130226223249.GD27098@waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130226222502.GB27098@waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 trusted decompressors based on hypervisor code.
This are used in mini-os by pv-grub.

Signed-off-by: Bastian Blank <waldi@debian.org>

diff -r efdc4bbfdd20 stubdom/Makefile
--- a/stubdom/Makefile	Tue Feb 26 19:42:36 2013 +0100
+++ b/stubdom/Makefile	Tue Feb 26 23:20:22 2013 +0100
@@ -328,7 +328,7 @@
 .PHONY: libxc
 libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a
 libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib
-	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH)
 
  libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a
 
diff -r efdc4bbfdd20 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Tue Feb 26 19:42:36 2013 +0100
+++ b/tools/libxc/Makefile	Tue Feb 26 23:20:22 2013 +0100
@@ -58,7 +58,6 @@
 GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y                 += xc_dom_elfloader.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_dom_bzimageloader.c
-GUEST_SRCS-$(CONFIG_X86)     += xc_dom_decompress.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
@@ -69,6 +68,16 @@
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
 
+ifeq ($(CONFIG_LIBXC_MINIOS),y)
+GUEST_SRCS-y                 += xc_dom_decompress_trusted.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_bzip2.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzma.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzo1x.c
+GUEST_SRCS-y                 += xc_dom_decompress_trusted_xz.c
+else
+GUEST_SRCS-y                 += xc_dom_decompress.c
+endif
+
 OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
 
 -include $(XEN_TARGET_ARCH)/Makefile
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,49 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+struct xc_dom_image *trusted_dom;
+static unsigned char *output_blob;
+static unsigned int output_size;
+
+static void trusted_error(const char *msg)
+{
+    xc_dom_panic(trusted_dom->xch, XC_INVALID_KERNEL, "%s", msg);
+}
+
+static int trusted_flush(void *src, unsigned int size)
+{
+    void *n = realloc(output_blob, output_size + size);
+    if (!n)
+        return -1;
+    output_blob = n;
+
+    memcpy(&output_blob[output_size], src, size);
+    output_size += size;
+    return size;
+}
+
+int xc_dom_decompress_trusted_decompress(
+    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    int ret;
+
+    trusted_dom = dom;
+    output_blob = NULL;
+    output_size = 0;
+
+    ret = fn(dom->kernel_blob, dom->kernel_size, NULL, trusted_flush, NULL, NULL, trusted_error);
+
+    if (ret)
+        free(output_blob);
+    else {
+        *blob = output_blob;
+        *size = output_size;
+    }
+
+    return ret;
+}
+
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted.h	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,12 @@
+#include "xc_dom.h"
+
+typedef int decompress_fn(unsigned char *inbuf, unsigned int len,
+                          int (*fill)(void*, unsigned int),
+                          int (*flush)(void*, unsigned int),
+                          unsigned char *outbuf, unsigned int *posp,
+                          void (*error)(const char *x));
+
+int xc_dom_decompress_trusted_decompress(
+    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
+    __attribute__((visibility("hidden")));
+
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_bzip2.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_bzip2.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,14 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+#include "../../xen/common/bunzip2.c"
+
+int xc_try_bzip2_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(bunzip2, dom, blob, size);
+}
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzma.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_lzma.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,14 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+#include "../../xen/common/unlzma.c"
+
+int xc_try_lzma_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(unlzma, dom, blob, size);
+}
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzo1x.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_lzo1x.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,15 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+#include "../../xen/common/lzo.c"
+#include "../../xen/common/unlzo.c"
+
+int xc_try_lzo1x_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(unlzo, dom, blob, size);
+}
diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_xz.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxc/xc_dom_decompress_trusted_xz.c	Tue Feb 26 23:20:22 2013 +0100
@@ -0,0 +1,17 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <inttypes.h>
+
+#include "xg_private.h"
+#include "xc_dom_decompress_trusted.h"
+
+// TODO
+#define XZ_DEC_X86
+
+#include "../../xen/common/unxz.c"
+
+int xc_try_xz_decode(
+    struct xc_dom_image *dom, void **blob, size_t *size)
+{
+    return xc_dom_decompress_trusted_decompress(unxz, dom, blob, size);
+}
diff -r efdc4bbfdd20 xen/common/decompress.h
--- a/xen/common/decompress.h	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/decompress.h	Tue Feb 26 23:20:22 2013 +0100
@@ -1,3 +1,5 @@
+#ifdef __XEN__
+
 #include <xen/config.h>
 #include <xen/cache.h>
 #include <xen/decompress.h>
@@ -15,3 +17,14 @@
 
 #define large_malloc xmalloc_bytes
 #define large_free xfree
+
+#else
+
+#define STATIC static
+#define INIT
+#define INITDATA
+
+#define large_malloc malloc
+#define large_free free
+
+#endif
diff -r efdc4bbfdd20 xen/common/lzo.c
--- a/xen/common/lzo.c	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/lzo.c	Tue Feb 26 23:20:22 2013 +0100
@@ -68,7 +68,19 @@
  *  Richard Purdie <rpurdie@openedhand.com>
  */
 
+#ifndef __MINIOS__
 #include <xen/types.h>
+#else
+#include <stdint.h>
+
+typedef uint32_t u32;
+typedef uint16_t u16;
+
+#define likely(a) a
+#define noinline
+#define unlikely(a) a
+#endif
+
 #include <xen/lzo.h>
 #define get_unaligned(_p) (*(_p))
 #define put_unaligned(_val,_p) (*(_p)=_val)
diff -r efdc4bbfdd20 xen/common/unlzma.c
--- a/xen/common/unlzma.c	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/unlzma.c	Tue Feb 26 23:20:22 2013 +0100
@@ -54,7 +54,9 @@
  * Copyright (c) 1999-2005  Igor Pavlov
  */
 
+#ifndef __MINIOS__
 #include <xen/compiler.h>
+#endif
 
 #define LZMA_IOBUF_SIZE	0x10000
 
diff -r efdc4bbfdd20 xen/common/unlzo.c
--- a/xen/common/unlzo.c	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/unlzo.c	Tue Feb 26 23:20:22 2013 +0100
@@ -32,7 +32,43 @@
 
 #include "decompress.h"
 #include <xen/lzo.h>
+
+#ifndef __MINIOS__
 #include <asm/byteorder.h>
+#else
+#include <endian.h>
+#include <stdint.h>
+
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+
+static inline u16 be16_to_cpup(const u16 *p)
+{
+	u16 v = *p;
+#if BYTE_ORDER == LITTLE_ENDIAN
+	return (((v & 0x00ffU) << 8) |
+                ((v & 0xff00U) >> 8));
+#else
+	return v;
+#endif
+}
+
+static inline u32 be32_to_cpup(const u32 *p)
+{
+	u32 v = *p;
+#if BYTE_ORDER == LITTLE_ENDIAN
+	return (((v & 0x000000ffUL) << 24) |
+                ((v & 0x0000ff00UL) <<  8) |
+                ((v & 0x00ff0000UL) >>  8) |
+                ((v & 0xff000000UL) >> 24));
+#else
+	return v;
+#endif
+}
+
+#define unlikely(a) a
+#endif
 
 #if 1 /* ndef CONFIG_??? */
 static inline u16 INIT get_unaligned_be16(void *p)
diff -r efdc4bbfdd20 xen/common/xz/private.h
--- a/xen/common/xz/private.h	Tue Feb 26 19:42:36 2013 +0100
+++ b/xen/common/xz/private.h	Tue Feb 26 23:20:22 2013 +0100
@@ -10,8 +10,53 @@
 #ifndef XZ_PRIVATE_H
 #define XZ_PRIVATE_H
 
+#ifndef __MINIOS__
 #include <xen/kernel.h>
 #include <asm/byteorder.h>
+#else
+#include <endian.h>
+#include <stddef.h>
+#include <stdint.h>
+
+typedef char bool_t;
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint32_t __le32;
+
+static inline u32 cpu_to_le32(const u32 v)
+{
+#if BYTE_ORDER == BIG_ENDIAN
+	return (((v & 0x000000ffUL) << 24) |
+	        ((v & 0x0000ff00UL) <<  8) |
+	        ((v & 0x00ff0000UL) >>  8) |
+	        ((v & 0xff000000UL) >> 24));
+#else  
+	return v;
+#endif
+}
+
+static inline u32 le32_to_cpup(const u32 *p)
+{
+	return cpu_to_le32(*p);
+}
+
+#define min(x,y) ({ \
+        const typeof(x) _x = (x);       \
+        const typeof(y) _y = (y);       \
+        (void) (&_x == &_y);            \
+        _x < _y ? _x : _y; })
+
+#define min_t(type,x,y) \
+        ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
+#define max_t(type,x,y) \
+        ({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
+
+#define __force
+#define always_inline
+
+#endif
+
 #define get_le32(p) le32_to_cpup((const uint32_t *)(p))
 
 #if 1 /* ndef CONFIG_??? */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 22:57:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22:57: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 1UATSP-0004vL-Qh; Tue, 26 Feb 2013 22:57:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UATSN-0004vD-Qv
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:57:08 +0000
Received: from [85.158.138.51:64608] by server-9.bemta-3.messagelabs.com id
	37/24-09484-EBD3D215; Tue, 26 Feb 2013 22:57:02 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361919417!29272226!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4157 invoked from network); 26 Feb 2013 22:57:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 22:57:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QMul55019036
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 22:56:48 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
	r1QMulOG026800
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 22:56:47 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
	r1QMukM3017182; Tue, 26 Feb 2013 16:56:47 -0600
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-157.usdhcp.oraclecorp.com.com
	(/10.152.55.156) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 14:56:46 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com
Date: Tue, 26 Feb 2013 17:56:10 -0500
Message-Id: <1361919370-18058-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.2
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is
	set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 CONFIG_DEBUG_PAGEALLOC is set page table updates made by
kernel_map_pages() are not made visible (via TLB flush) immediately if lazy
MMU is on. In environments that support lazy MMU (e.g. Xen) this may lead to
fatal page faults, for example, when zap_pte_range() needs to allocate pages
in __tlb_remove_page() -> tlb_next_batch().

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/mm/pageattr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index ca1f1c2..7b3216e 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
 	 * but that can deadlock->flush only current cpu:
 	 */
 	__flush_tlb_all();
+
+	arch_flush_lazy_mmu_mode();
 }
 
 #ifdef CONFIG_HIBERNATION
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 22:57:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 22:57: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 1UATSP-0004vL-Qh; Tue, 26 Feb 2013 22:57:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UATSN-0004vD-Qv
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 22:57:08 +0000
Received: from [85.158.138.51:64608] by server-9.bemta-3.messagelabs.com id
	37/24-09484-EBD3D215; Tue, 26 Feb 2013 22:57:02 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361919417!29272226!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjQ4ODM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4157 invoked from network); 26 Feb 2013 22:57:01 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Feb 2013 22:57:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QMul55019036
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 22:56:48 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
	r1QMulOG026800
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 22:56:47 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
	r1QMukM3017182; Tue, 26 Feb 2013 16:56:47 -0600
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-157.usdhcp.oraclecorp.com.com
	(/10.152.55.156) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 14:56:46 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com
Date: Tue, 26 Feb 2013 17:56:10 -0500
Message-Id: <1361919370-18058-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.2
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is
	set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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 CONFIG_DEBUG_PAGEALLOC is set page table updates made by
kernel_map_pages() are not made visible (via TLB flush) immediately if lazy
MMU is on. In environments that support lazy MMU (e.g. Xen) this may lead to
fatal page faults, for example, when zap_pte_range() needs to allocate pages
in __tlb_remove_page() -> tlb_next_batch().

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/mm/pageattr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index ca1f1c2..7b3216e 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
 	 * but that can deadlock->flush only current cpu:
 	 */
 	__flush_tlb_all();
+
+	arch_flush_lazy_mmu_mode();
 }
 
 #ifdef CONFIG_HIBERNATION
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 23:40:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 23: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 1UAU84-0005OA-Gb; Tue, 26 Feb 2013 23:40:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1UAU83-0005O5-G3
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 23:40:11 +0000
Received: from [85.158.143.99:28241] by server-2.bemta-4.messagelabs.com id
	0E/40-12656-AD74D215; Tue, 26 Feb 2013 23:40:10 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361922008!29329798!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2855 invoked from network); 26 Feb 2013 23:40:09 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 23:40:09 -0000
Received: from hanvin-mobl6.amr.corp.intel.com ([192.55.54.42])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1QNcv4t025435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 15:38:58 -0800
Message-ID: <512D478C.4030503@zytor.com>
Date: Tue, 26 Feb 2013 15:38:52 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1361919370-18058-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1361919370-18058-1-git-send-email-boris.ostrovsky@oracle.com>
X-Enigmail-Version: 1.5
Cc: tglx@linutronix.de, mingo@redhat.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/26/2013 02:56 PM, Boris Ostrovsky wrote:
> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> kernel_map_pages() are not made visible (via TLB flush) immediately if lazy
> MMU is on. In environments that support lazy MMU (e.g. Xen) this may lead to
> fatal page faults, for example, when zap_pte_range() needs to allocate pages
> in __tlb_remove_page() -> tlb_next_batch().
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/mm/pageattr.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index ca1f1c2..7b3216e 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
>  	 * but that can deadlock->flush only current cpu:
>  	 */
>  	__flush_tlb_all();
> +
> +	arch_flush_lazy_mmu_mode();
>  }
>  
>  #ifdef CONFIG_HIBERNATION
> 

This sounds like a critical fix, i.e. a -stable candidate.  Am I correct?

	-hpa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 23:40:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 23: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 1UAU84-0005OA-Gb; Tue, 26 Feb 2013 23:40:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1UAU83-0005O5-G3
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 23:40:11 +0000
Received: from [85.158.143.99:28241] by server-2.bemta-4.messagelabs.com id
	0E/40-12656-AD74D215; Tue, 26 Feb 2013 23:40:10 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361922008!29329798!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2855 invoked from network); 26 Feb 2013 23:40:09 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 23:40:09 -0000
Received: from hanvin-mobl6.amr.corp.intel.com ([192.55.54.42])
	(authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1QNcv4t025435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 15:38:58 -0800
Message-ID: <512D478C.4030503@zytor.com>
Date: Tue, 26 Feb 2013 15:38:52 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <1361919370-18058-1-git-send-email-boris.ostrovsky@oracle.com>
In-Reply-To: <1361919370-18058-1-git-send-email-boris.ostrovsky@oracle.com>
X-Enigmail-Version: 1.5
Cc: tglx@linutronix.de, mingo@redhat.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/26/2013 02:56 PM, Boris Ostrovsky wrote:
> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> kernel_map_pages() are not made visible (via TLB flush) immediately if lazy
> MMU is on. In environments that support lazy MMU (e.g. Xen) this may lead to
> fatal page faults, for example, when zap_pte_range() needs to allocate pages
> in __tlb_remove_page() -> tlb_next_batch().
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/mm/pageattr.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index ca1f1c2..7b3216e 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
>  	 * but that can deadlock->flush only current cpu:
>  	 */
>  	__flush_tlb_all();
> +
> +	arch_flush_lazy_mmu_mode();
>  }
>  
>  #ifdef CONFIG_HIBERNATION
> 

This sounds like a critical fix, i.e. a -stable candidate.  Am I correct?

	-hpa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 23:58:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 23: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 1UAUP7-0005qX-R6; Tue, 26 Feb 2013 23:57:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UAUP6-0005qQ-6I
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 23:57:48 +0000
Received: from [85.158.143.99:10099] by server-3.bemta-4.messagelabs.com id
	2D/83-02186-BFB4D215; Tue, 26 Feb 2013 23:57:47 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361923065!29331088!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUwMzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8033 invoked from network); 26 Feb 2013 23:57:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 23:57:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QNvaBV006538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 23:57: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
	r1QNvau0017312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 23:57:36 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
	r1QNvZUQ028900; Tue, 26 Feb 2013 17:57:35 -0600
MIME-Version: 1.0
Message-ID: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
Date: Tue, 26 Feb 2013 15:57:35 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <hpa@zytor.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: tglx@linutronix.de, mingo@redhat.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


----- hpa@zytor.com wrote:

> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> > When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> > kernel_map_pages() are not made visible (via TLB flush) immediately
> if lazy
> > MMU is on. In environments that support lazy MMU (e.g. Xen) this may
> lead to
> > fatal page faults, for example, when zap_pte_range() needs to
> allocate pages
> > in __tlb_remove_page() -> tlb_next_batch().
> > 
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > ---
> >  arch/x86/mm/pageattr.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > index ca1f1c2..7b3216e 100644
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/mm/pageattr.c
> > @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int
> numpages, int enable)
> >  	 * but that can deadlock->flush only current cpu:
> >  	 */
> >  	__flush_tlb_all();
> > +
> > +	arch_flush_lazy_mmu_mode();
> >  }
> >  
> >  #ifdef CONFIG_HIBERNATION
> > 
> 
> This sounds like a critical fix, i.e. a -stable candidate.  Am I
> correct?

I considered copying stable but then I decided that this is a debugging feature
--- kernel_map_pages() is only defined if CONFIG_DEBUG_PAGEALLOC is set and my
thinking was that stable kernels usually don't do this.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Feb 26 23:58:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 26 Feb 2013 23: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 1UAUP7-0005qX-R6; Tue, 26 Feb 2013 23:57:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UAUP6-0005qQ-6I
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 23:57:48 +0000
Received: from [85.158.143.99:10099] by server-3.bemta-4.messagelabs.com id
	2D/83-02186-BFB4D215; Tue, 26 Feb 2013 23:57:47 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361923065!29331088!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUwMzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8033 invoked from network); 26 Feb 2013 23:57:46 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Feb 2013 23:57:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1QNvaBV006538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 26 Feb 2013 23:57: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
	r1QNvau0017312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 26 Feb 2013 23:57:36 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
	r1QNvZUQ028900; Tue, 26 Feb 2013 17:57:35 -0600
MIME-Version: 1.0
Message-ID: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
Date: Tue, 26 Feb 2013 15:57:35 -0800 (PST)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: <hpa@zytor.com>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: tglx@linutronix.de, mingo@redhat.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


----- hpa@zytor.com wrote:

> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> > When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> > kernel_map_pages() are not made visible (via TLB flush) immediately
> if lazy
> > MMU is on. In environments that support lazy MMU (e.g. Xen) this may
> lead to
> > fatal page faults, for example, when zap_pte_range() needs to
> allocate pages
> > in __tlb_remove_page() -> tlb_next_batch().
> > 
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > ---
> >  arch/x86/mm/pageattr.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > index ca1f1c2..7b3216e 100644
> > --- a/arch/x86/mm/pageattr.c
> > +++ b/arch/x86/mm/pageattr.c
> > @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int
> numpages, int enable)
> >  	 * but that can deadlock->flush only current cpu:
> >  	 */
> >  	__flush_tlb_all();
> > +
> > +	arch_flush_lazy_mmu_mode();
> >  }
> >  
> >  #ifdef CONFIG_HIBERNATION
> > 
> 
> This sounds like a critical fix, i.e. a -stable candidate.  Am I
> correct?

I considered copying stable but then I decided that this is a debugging feature
--- kernel_map_pages() is only defined if CONFIG_DEBUG_PAGEALLOC is set and my
thinking was that stable kernels usually don't do this.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 02:18:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 02: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 1UAWb5-0003Zm-Q3; Wed, 27 Feb 2013 02:18: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 1UAWb3-0003Zc-Ik
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 02:18:17 +0000
Received: from [85.158.143.99:42496] by server-1.bemta-4.messagelabs.com id
	CC/80-06203-8EC6D215; Wed, 27 Feb 2013 02:18:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361931496!28898094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25206 invoked from network); 27 Feb 2013 02:18:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 02:18:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,744,1355097600"; 
   d="scan'208";a="1930305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 02:18: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.297.1; Wed, 27 Feb 2013 02:18:15 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAWb1-00032T-56;
	Wed, 27 Feb 2013 02:18:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAWb0-00074m-OT;
	Wed, 27 Feb 2013 02:18:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16747-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 02:18:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16747: 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 16747 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16747/

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. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  9 guest-start              fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-qemut-win-vcpus1 16 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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  84fa23bc6cb949fcc5d510bcaa8905d04205c916
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 84fa23bc6cb949fcc5d510bcaa8905d04205c916
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Tue Feb 26 10:12:46 2013 +0000

    tools: foreign: ensure 64 bit values are properly aligned for arm
    
    When building the foreign headers on x86_32 we use '#pragma pack(4)' and
    therefore need to explicitly align types which should be aligned to 8-byte
    boundaries.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 02:18:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 02: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 1UAWb5-0003Zm-Q3; Wed, 27 Feb 2013 02:18: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 1UAWb3-0003Zc-Ik
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 02:18:17 +0000
Received: from [85.158.143.99:42496] by server-1.bemta-4.messagelabs.com id
	CC/80-06203-8EC6D215; Wed, 27 Feb 2013 02:18:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361931496!28898094!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25206 invoked from network); 27 Feb 2013 02:18:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 02:18:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,744,1355097600"; 
   d="scan'208";a="1930305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 02:18: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.297.1; Wed, 27 Feb 2013 02:18:15 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAWb1-00032T-56;
	Wed, 27 Feb 2013 02:18:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAWb0-00074m-OT;
	Wed, 27 Feb 2013 02:18:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16747-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 02:18:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16747: 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 16747 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16747/

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. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  9 guest-start              fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-qemut-win-vcpus1 16 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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  84fa23bc6cb949fcc5d510bcaa8905d04205c916
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 84fa23bc6cb949fcc5d510bcaa8905d04205c916
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Tue Feb 26 10:12:46 2013 +0000

    tools: foreign: ensure 64 bit values are properly aligned for arm
    
    When building the foreign headers on x86_32 we use '#pragma pack(4)' and
    therefore need to explicitly align types which should be aligned to 8-byte
    boundaries.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 04:20:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 04:20: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 1UAYUn-00050X-7u; Wed, 27 Feb 2013 04:19: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 1UAYUm-00050S-0f
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 04:19:56 +0000
Received: from [85.158.137.99:4436] by server-11.bemta-3.messagelabs.com id
	90/A1-10249-B698D215; Wed, 27 Feb 2013 04:19:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361938794!15930989!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 27 Feb 2013 04:19:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 04:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,744,1355097600"; 
   d="scan'208";a="1932177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 04:19: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.297.1; Wed, 27 Feb 2013 04:19:54 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAYUk-0003dT-0V;
	Wed, 27 Feb 2013 04:19:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAYUj-0001H4-V6;
	Wed, 27 Feb 2013 04:19:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16749-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 04:19:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16749: 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 16749 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16749/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 04:20:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 04:20: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 1UAYUn-00050X-7u; Wed, 27 Feb 2013 04:19: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 1UAYUm-00050S-0f
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 04:19:56 +0000
Received: from [85.158.137.99:4436] by server-11.bemta-3.messagelabs.com id
	90/A1-10249-B698D215; Wed, 27 Feb 2013 04:19:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361938794!15930989!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 27 Feb 2013 04:19:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 04:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,744,1355097600"; 
   d="scan'208";a="1932177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 04:19: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.297.1; Wed, 27 Feb 2013 04:19:54 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAYUk-0003dT-0V;
	Wed, 27 Feb 2013 04:19:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAYUj-0001H4-V6;
	Wed, 27 Feb 2013 04:19:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-16749-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 04:19:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16749: 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 16749 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16749/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           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-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 05:50:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 05:50: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 1UAZtz-0005yr-Jk; Wed, 27 Feb 2013 05:50:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1UAZtx-0005ym-5m
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 05:50:01 +0000
Received: from [85.158.143.99:11936] by server-1.bemta-4.messagelabs.com id
	6A/44-06203-88E9D215; Wed, 27 Feb 2013 05:50:00 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361944197!17920428!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjE0ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27764 invoked from network); 27 Feb 2013 05:49:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 05:49:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1R5npgK014314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 05:49:52 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
	r1R5noTl015557
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 05:49:50 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
	r1R5no5I012944; Tue, 26 Feb 2013 23:49:50 -0600
Received: from [192.168.1.100] (/117.79.232.237)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 21:49:49 -0800
Message-ID: <512D9E86.1080907@oracle.com>
Date: Wed, 27 Feb 2013 13:49:58 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512C78D2.8030903@oracle.com>
	<512C979E02000078000C105F@nat28.tlf.novell.com>
In-Reply-To: <512C979E02000078000C105F@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.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 2013-02-26 18:08, Jan Beulich wrote:
>>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>> (fee00000 -> fee02000)
>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>> (00004059 -> 00004071)
> If you look at the code issuing this message, the situation is
> pretty clear (and I think it as described already in the past,
> albeit I have no link at hand): qemu lacks proper emulation of
> the mask bit. pci_msix_write() looks at the physical one, yet
> when the guest sets the virtual mask bit, nothing is being
> done at all to make the hypervisor also mask the physical
> entry:
>
>      if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
>          if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>              xen_pt_msix_update_one(s, entry_nr);
>          }
>      }
>
> There's probably quite a bit of code to be written to make this
> work.
Is there plan of fixing it?

thanks
zduan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 05:50:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 05:50: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 1UAZtz-0005yr-Jk; Wed, 27 Feb 2013 05:50:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1UAZtx-0005ym-5m
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 05:50:01 +0000
Received: from [85.158.143.99:11936] by server-1.bemta-4.messagelabs.com id
	6A/44-06203-88E9D215; Wed, 27 Feb 2013 05:50:00 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361944197!17920428!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjE0ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27764 invoked from network); 27 Feb 2013 05:49:59 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 05:49:59 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1R5npgK014314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 05:49:52 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
	r1R5noTl015557
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 05:49:50 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
	r1R5no5I012944; Tue, 26 Feb 2013 23:49:50 -0600
Received: from [192.168.1.100] (/117.79.232.237)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 21:49:49 -0800
Message-ID: <512D9E86.1080907@oracle.com>
Date: Wed, 27 Feb 2013 13:49:58 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512C78D2.8030903@oracle.com>
	<512C979E02000078000C105F@nat28.tlf.novell.com>
In-Reply-To: <512C979E02000078000C105F@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.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 2013-02-26 18:08, Jan Beulich wrote:
>>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>> (fee00000 -> fee02000)
>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>> (00004059 -> 00004071)
> If you look at the code issuing this message, the situation is
> pretty clear (and I think it as described already in the past,
> albeit I have no link at hand): qemu lacks proper emulation of
> the mask bit. pci_msix_write() looks at the physical one, yet
> when the guest sets the virtual mask bit, nothing is being
> done at all to make the hypervisor also mask the physical
> entry:
>
>      if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
>          if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>              xen_pt_msix_update_one(s, entry_nr);
>          }
>      }
>
> There's probably quite a bit of code to be written to make this
> work.
Is there plan of fixing it?

thanks
zduan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 06:20:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 06: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 1UAaMy-0006Ol-Cq; Wed, 27 Feb 2013 06:20:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1UAaMx-0006Og-GE
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 06:19:59 +0000
Received: from [85.158.139.83:49868] by server-5.bemta-5.messagelabs.com id
	7F/C1-02762-E85AD215; Wed, 27 Feb 2013 06:19:58 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361945997!29174726!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4OTA1NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24678 invoked from network); 27 Feb 2013 06:19:57 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 06:19:57 -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;
	b=cKyy/nyzBcr68IrrQ3CCShcjLkgDKzbZjTU42szR0FNNQ1sY0VhmwG5P
	RxbwnIud/Ewhun7YwQfuukfRgfLCHCQwDD8XqQT2l0OZpOJPDKyIbV7ib
	sDADobP2qJevDaXVlerUF2yQDtPRoFUHIQnURRVoROG+4N3szy4bsvNL6
	cZfHxgzjn31fSnC87Qr3mTX/EcU1XKbFOaISzwk7gF8d4JR9p0JdTMv+E
	1wFCvX250iLjPWsJ1bHXWqgJ22yw1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361945998; x=1393481998;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=VglSHrqZduhyeBQ2WMZ/C4WzAk79CylVBA3XqPW/EgE=;
	b=T8yg0gE0zF+oNVEZZTKnaxcBW7rKhQk2pnOvnBfN/EAGBRbj5XPgF4jd
	HGbsVD/7QZOOz3jzahm0dqonT83VcjqtQ8o9U5YTdCdkb25n6ZLc6DEAi
	GK9VFXYCu+jxbVG/+/AuZB4qbPaARh9FcmPHOXsIDqbumN3QcKQAt8vmW
	WcBQxJvhUVU9cVoGFN/C0ufZVXXXRvvp2H8svJUXrB4QUZt15CFGuvS3R
	WE8PzBYGTMwRi5hnOfcZ6iqsuCH7h;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; d="scan'208";a="138142048"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Feb 2013 07:19:57 +0100
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; 
   d="scan'208";a="5101195"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 07:19:57 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id AA423969A0F;
	Wed, 27 Feb 2013 07:19:56 +0100 (CET)
Message-ID: <512DA58C.4060604@ts.fujitsu.com>
Date: Wed, 27 Feb 2013 07:19:56 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
In-Reply-To: <512353E502000078000BF521@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------080704080807040407000602"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------080704080807040407000602
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 19.02.2013 10:28, Jan Beulich wrote:
>>>> On 18.02.13 at 19:11, Andrew Cooper<andrew.cooper3@citrix.com>  wrot=
e:
>> Hello,
>>
>> Our testing has discovered a crash (pagefault at 0x0000000000000008)
>> which I have tracked down to bad __runq_remove() in csched_vcpu_sleep(=
)
>> in sched_credit.c (because a static function of the same name also
>> exists in sched_credit2.c, which confused matters to start with)
>>
>> The test case was a loop of localhost migrate of a 1vcpu HVM win8
>> domain.  The test case itself has passed many times in the past on the
>> same Xen codebase (Xen-4.1.3), indicating that it is very rare.  There
>> does not appear to be any relevant changes between the version of Xen =
in
>> the test and xen-4.1-testing.
>>
>> The failure itself is because of a XEN_DOMCTL_scheduler_op (trace belo=
w)
>> from dom0, targeting the VCPU of the migrating domain.
>>
>> (XEN) Xen call trace:
>> (XEN)       [<ffff82c480116a14>] csched_vcpu_sleep+0x44/0x70
>> (XEN)      0[<ffff82c480120117>] vcpu_sleep_nosync+0xe7/0x3b0
>> (XEN)     12[<ffff82c4801203e9>] vcpu_sleep_sync+0x9/0x50
>> (XEN)     14[<ffff82c48011fd4c>] sched_adjust+0xac/0x230
>> (XEN)     24[<ffff82c480102bc1>] do_domctl+0x731/0x1130
>> (XEN)     64[<ffff82c4802013c4>] compat_hypercall+0x74/0x80
>>
>> The relevant part of csched_vcpu_sleep() is
>>
>>      else if ( __vcpu_on_runq(svc) )
>>          __runq_remove(svc);
>>
>> which disassembles to
>>
>> ffff82c480116a01:       49 8b 10                mov    (%r8),%rdx
>> ffff82c480116a04:       4c 39 c2                cmp    %r8,%rdx
>> ffff82c480116a07:       75 07                   jne    ffff82c480116a1=
0
>> <csched_vcpu_sleep+0x40>
>> ffff82c480116a09:       f3 c3                   repz retq
>> ffff82c480116a0b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1=
)
>> ffff82c480116a10:       49 8b 40 08             mov    0x8(%r8),%rax
>> ffff82c480116a14:       48 89 42 08             mov    %rax,0x8(%rdx) =
#
>> <- Pagefault here
>> ffff82c480116a18:       48 89 10                mov    %rdx,(%rax)
>> ffff82c480116a1b:       4d 89 40 08             mov    %r8,0x8(%r8)
>> ffff82c480116a1f:       4d 89 00                mov    %r8,(%r8)
>>
>> The relevant crash registers from the pagefault are:
>> rax: 0000000000000000
>> rdx: 0000000000000000
>>   r8: ffff83080c89ed90
>>
>> If I am reading the code correctly, this means that runq->next is NULL=
,
>> so we fail list_empty() and erroneously pass __vcpu_on_runq().  We the=
n
>> fail with a fault when trying to update runq->prev, which is also NULL=
.
>>
>> The only place I can spot in the code where the runq->{next,prev} coul=
d
>> conceivably be NULL is in csched_alloc_vdata() between the memset() an=
d
>> INIT_LIST_HEAD().  This is logically sensible in combination with the
>> localhost migrate loop, and I cant immediately see anything to prevent
>> this race happening.
>
> But that doesn't make sense: csched_alloc_vdata() doesn't store
> svc into vc->sched_priv; that's being done by the generic
> scheduler code once the actor returns.
>
> So I'd rather suspect a stale pointer being used, which is easily
> possible when racing with sched_move_domain() (as opposed to
> schedule_cpu_switch(), where the new pointer gets stored
> _before_ de-allocating the old one).
>
> However, sched_move_domain() (as well as schedule_cpu_switch())
> get called only from CPU pools code, and I would guess CPU pools
> aren't involved here, and you don't in parallel soft offline/online
> pCPU-s (as I'm sure you otherwise would have mentioned it).
>
> But wait - libxl__domain_make() _unconditionally_ calls
> xc_cpupool_movedomain(), as does XendDomainInfo's
> _constructDomain(). The reason for this escapes me - J=C3=BCrgen? Yet
> I'd expect the pool ID matching check to short cut the resulting
> sysctl, i.e. sched_move_domain() ought to not be reached anyway
> (worth verifying of course).
>
> The race there nevertheless ought to be fixed.

Something like the attached patch?

Not tested thoroughly yet.


Juergen

--=20
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujits=
u.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.=
html

--------------080704080807040407000602
Content-Type: text/x-patch;
 name="movedom.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="movedom.patch"

Avoid stale pointer when moving domain to another cpupool

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e xen/common/schedule.c
--- a/xen/common/schedule.c     Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/schedule.c     Wed Feb 27 06:50:51 2013 +0100
@@ -231,12 +231,14 @@ int sched_move_domain(struct domain *d, 
     unsigned int new_p;
     void **vcpu_priv;
     void *domdata;
+    struct scheduler *old_ops;
+    void *old_domdata;
 
     domdata = SCHED_OP(c->sched, alloc_domdata, d);
     if ( domdata == NULL )
         return -ENOMEM;
 
-    vcpu_priv = xzalloc_array(void *, d->max_vcpus);
+    vcpu_priv = xzalloc_array(void *, d->max_vcpus * 2);
     if ( vcpu_priv == NULL )
     {
         SCHED_OP(c->sched, free_domdata, domdata);
@@ -257,18 +259,13 @@ int sched_move_domain(struct domain *d, 
             SCHED_OP(c->sched, free_domdata, domdata);
             return -ENOMEM;
         }
+        vcpu_priv[d->max_vcpus + v->vcpu_id] = v->sched_priv;
     }
 
     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);
+    old_ops = DOM2OP(d);
+    old_domdata = d->sched_priv;
 
     d->cpupool = c;
     d->sched_priv = domdata;
@@ -289,6 +286,15 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(c->sched, insert_vcpu, v);
     }
+
+    for_each_vcpu ( d, v )
+    {
+        SCHED_OP(old_ops, remove_vcpu, v);
+        SCHED_OP(old_ops, free_vdata, vcpu_priv[d->max_vcpus + v->vcpu_id]);
+        v->sched_priv = NULL;
+    }
+
+    SCHED_OP(old_ops, free_domdata, old_domdata);
 
     domain_update_node_affinity(d);


--------------080704080807040407000602
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080704080807040407000602--


From xen-devel-bounces@lists.xen.org Wed Feb 27 06:20:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 06: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 1UAaMy-0006Ol-Cq; Wed, 27 Feb 2013 06:20:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1UAaMx-0006Og-GE
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 06:19:59 +0000
Received: from [85.158.139.83:49868] by server-5.bemta-5.messagelabs.com id
	7F/C1-02762-E85AD215; Wed, 27 Feb 2013 06:19:58 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361945997!29174726!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4OTA1NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24678 invoked from network); 27 Feb 2013 06:19:57 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 06:19:57 -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;
	b=cKyy/nyzBcr68IrrQ3CCShcjLkgDKzbZjTU42szR0FNNQ1sY0VhmwG5P
	RxbwnIud/Ewhun7YwQfuukfRgfLCHCQwDD8XqQT2l0OZpOJPDKyIbV7ib
	sDADobP2qJevDaXVlerUF2yQDtPRoFUHIQnURRVoROG+4N3szy4bsvNL6
	cZfHxgzjn31fSnC87Qr3mTX/EcU1XKbFOaISzwk7gF8d4JR9p0JdTMv+E
	1wFCvX250iLjPWsJ1bHXWqgJ22yw1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361945998; x=1393481998;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=VglSHrqZduhyeBQ2WMZ/C4WzAk79CylVBA3XqPW/EgE=;
	b=T8yg0gE0zF+oNVEZZTKnaxcBW7rKhQk2pnOvnBfN/EAGBRbj5XPgF4jd
	HGbsVD/7QZOOz3jzahm0dqonT83VcjqtQ8o9U5YTdCdkb25n6ZLc6DEAi
	GK9VFXYCu+jxbVG/+/AuZB4qbPaARh9FcmPHOXsIDqbumN3QcKQAt8vmW
	WcBQxJvhUVU9cVoGFN/C0ufZVXXXRvvp2H8svJUXrB4QUZt15CFGuvS3R
	WE8PzBYGTMwRi5hnOfcZ6iqsuCH7h;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; d="scan'208";a="138142048"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Feb 2013 07:19:57 +0100
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; 
   d="scan'208";a="5101195"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 07:19:57 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id AA423969A0F;
	Wed, 27 Feb 2013 07:19:56 +0100 (CET)
Message-ID: <512DA58C.4060604@ts.fujitsu.com>
Date: Wed, 27 Feb 2013 07:19:56 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
In-Reply-To: <512353E502000078000BF521@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------080704080807040407000602"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------080704080807040407000602
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 19.02.2013 10:28, Jan Beulich wrote:
>>>> On 18.02.13 at 19:11, Andrew Cooper<andrew.cooper3@citrix.com>  wrot=
e:
>> Hello,
>>
>> Our testing has discovered a crash (pagefault at 0x0000000000000008)
>> which I have tracked down to bad __runq_remove() in csched_vcpu_sleep(=
)
>> in sched_credit.c (because a static function of the same name also
>> exists in sched_credit2.c, which confused matters to start with)
>>
>> The test case was a loop of localhost migrate of a 1vcpu HVM win8
>> domain.  The test case itself has passed many times in the past on the
>> same Xen codebase (Xen-4.1.3), indicating that it is very rare.  There
>> does not appear to be any relevant changes between the version of Xen =
in
>> the test and xen-4.1-testing.
>>
>> The failure itself is because of a XEN_DOMCTL_scheduler_op (trace belo=
w)
>> from dom0, targeting the VCPU of the migrating domain.
>>
>> (XEN) Xen call trace:
>> (XEN)       [<ffff82c480116a14>] csched_vcpu_sleep+0x44/0x70
>> (XEN)      0[<ffff82c480120117>] vcpu_sleep_nosync+0xe7/0x3b0
>> (XEN)     12[<ffff82c4801203e9>] vcpu_sleep_sync+0x9/0x50
>> (XEN)     14[<ffff82c48011fd4c>] sched_adjust+0xac/0x230
>> (XEN)     24[<ffff82c480102bc1>] do_domctl+0x731/0x1130
>> (XEN)     64[<ffff82c4802013c4>] compat_hypercall+0x74/0x80
>>
>> The relevant part of csched_vcpu_sleep() is
>>
>>      else if ( __vcpu_on_runq(svc) )
>>          __runq_remove(svc);
>>
>> which disassembles to
>>
>> ffff82c480116a01:       49 8b 10                mov    (%r8),%rdx
>> ffff82c480116a04:       4c 39 c2                cmp    %r8,%rdx
>> ffff82c480116a07:       75 07                   jne    ffff82c480116a1=
0
>> <csched_vcpu_sleep+0x40>
>> ffff82c480116a09:       f3 c3                   repz retq
>> ffff82c480116a0b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1=
)
>> ffff82c480116a10:       49 8b 40 08             mov    0x8(%r8),%rax
>> ffff82c480116a14:       48 89 42 08             mov    %rax,0x8(%rdx) =
#
>> <- Pagefault here
>> ffff82c480116a18:       48 89 10                mov    %rdx,(%rax)
>> ffff82c480116a1b:       4d 89 40 08             mov    %r8,0x8(%r8)
>> ffff82c480116a1f:       4d 89 00                mov    %r8,(%r8)
>>
>> The relevant crash registers from the pagefault are:
>> rax: 0000000000000000
>> rdx: 0000000000000000
>>   r8: ffff83080c89ed90
>>
>> If I am reading the code correctly, this means that runq->next is NULL=
,
>> so we fail list_empty() and erroneously pass __vcpu_on_runq().  We the=
n
>> fail with a fault when trying to update runq->prev, which is also NULL=
.
>>
>> The only place I can spot in the code where the runq->{next,prev} coul=
d
>> conceivably be NULL is in csched_alloc_vdata() between the memset() an=
d
>> INIT_LIST_HEAD().  This is logically sensible in combination with the
>> localhost migrate loop, and I cant immediately see anything to prevent
>> this race happening.
>
> But that doesn't make sense: csched_alloc_vdata() doesn't store
> svc into vc->sched_priv; that's being done by the generic
> scheduler code once the actor returns.
>
> So I'd rather suspect a stale pointer being used, which is easily
> possible when racing with sched_move_domain() (as opposed to
> schedule_cpu_switch(), where the new pointer gets stored
> _before_ de-allocating the old one).
>
> However, sched_move_domain() (as well as schedule_cpu_switch())
> get called only from CPU pools code, and I would guess CPU pools
> aren't involved here, and you don't in parallel soft offline/online
> pCPU-s (as I'm sure you otherwise would have mentioned it).
>
> But wait - libxl__domain_make() _unconditionally_ calls
> xc_cpupool_movedomain(), as does XendDomainInfo's
> _constructDomain(). The reason for this escapes me - J=C3=BCrgen? Yet
> I'd expect the pool ID matching check to short cut the resulting
> sysctl, i.e. sched_move_domain() ought to not be reached anyway
> (worth verifying of course).
>
> The race there nevertheless ought to be fixed.

Something like the attached patch?

Not tested thoroughly yet.


Juergen

--=20
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujits=
u.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.=
html

--------------080704080807040407000602
Content-Type: text/x-patch;
 name="movedom.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="movedom.patch"

Avoid stale pointer when moving domain to another cpupool

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e xen/common/schedule.c
--- a/xen/common/schedule.c     Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/schedule.c     Wed Feb 27 06:50:51 2013 +0100
@@ -231,12 +231,14 @@ int sched_move_domain(struct domain *d, 
     unsigned int new_p;
     void **vcpu_priv;
     void *domdata;
+    struct scheduler *old_ops;
+    void *old_domdata;
 
     domdata = SCHED_OP(c->sched, alloc_domdata, d);
     if ( domdata == NULL )
         return -ENOMEM;
 
-    vcpu_priv = xzalloc_array(void *, d->max_vcpus);
+    vcpu_priv = xzalloc_array(void *, d->max_vcpus * 2);
     if ( vcpu_priv == NULL )
     {
         SCHED_OP(c->sched, free_domdata, domdata);
@@ -257,18 +259,13 @@ int sched_move_domain(struct domain *d, 
             SCHED_OP(c->sched, free_domdata, domdata);
             return -ENOMEM;
         }
+        vcpu_priv[d->max_vcpus + v->vcpu_id] = v->sched_priv;
     }
 
     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);
+    old_ops = DOM2OP(d);
+    old_domdata = d->sched_priv;
 
     d->cpupool = c;
     d->sched_priv = domdata;
@@ -289,6 +286,15 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(c->sched, insert_vcpu, v);
     }
+
+    for_each_vcpu ( d, v )
+    {
+        SCHED_OP(old_ops, remove_vcpu, v);
+        SCHED_OP(old_ops, free_vdata, vcpu_priv[d->max_vcpus + v->vcpu_id]);
+        v->sched_priv = NULL;
+    }
+
+    SCHED_OP(old_ops, free_domdata, old_domdata);
 
     domain_update_node_affinity(d);


--------------080704080807040407000602
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080704080807040407000602--


From xen-devel-bounces@lists.xen.org Wed Feb 27 06:29:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 06:29: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 1UAaVO-0006ap-En; Wed, 27 Feb 2013 06:28:42 +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 1UAaVM-0006ak-PW
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 06:28:41 +0000
Received: from [85.158.137.99:47418] by server-11.bemta-3.messagelabs.com id
	11/45-01263-397AD215; Wed, 27 Feb 2013 06:28:35 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361946514!17434646!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4OTA1NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1936 invoked from network); 27 Feb 2013 06:28:34 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 06:28:34 -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;
	b=sUeIcsn2yBOVgp7luDzDJOrSkqHIZUvFU08D1hMbMCo+1aEZDr+2lFzu
	D8pSTPcFCtqp+ixLgGKOzSpoLxkzFRp2sm2WCullTKgRFf2Eq9XAQWCQj
	dOR7bd0abqRSlB+T0GTnh3uQIGW/MnEoOzNXIuy2OHl8gqO4mpx0gGRWX
	k9YMvkcd3+wxNqxD9Vh4FT3E7HoWh9GYQUqa144VA7psFp+JCJP/S7fwc
	RtodAYavKlYKs8lW5AtCplnTe/gDR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361946514; x=1393482514;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=uBeKHX0BZ2RQYjL2hX+G2VSWdt3a4pChI9+MvXqChaw=;
	b=KDOyuibF4heE/wSTSkbuXRaY7wlJMDDCzP0g+86p+2WcD2U6IuGT7Ry9
	52hjbTgwLHGLU1AuP2+V9DM9GOlCwmubIQQt9NihgzuvS/p+Um7uUHzKo
	UyCYzU6dpFKEYldYmcPmVGfK5TLWB3TEq2DLS+afSPPGtcb7/PV+jDy26
	LxE2KyNiPMDZbTJZk1V7tCXlDD7SRFoaeTZMn1yJJ9J9Fq/W92ABfzXcI
	ol0gdnjH26lSyPTJ4fT730pO+cnR+;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; d="scan'208";a="138142607"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Feb 2013 07:28:12 +0100
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; 
   d="scan'208";a="5101560"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 07:28:12 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B166696C29A;
	Wed, 27 Feb 2013 07:28:11 +0100 (CET)
Message-ID: <512DA77B.90001@ts.fujitsu.com>
Date: Wed, 27 Feb 2013 07:28:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<512DA58C.4060604@ts.fujitsu.com>
In-Reply-To: <512DA58C.4060604@ts.fujitsu.com>
Content-Type: multipart/mixed; boundary="------------000006070305000104040700"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------000006070305000104040700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 27.02.2013 07:19, Juergen Gross wrote:
> On 19.02.2013 10:28, Jan Beulich wrote:
>>>>> On 18.02.13 at 19:11, Andrew Cooper<andrew.cooper3@citrix.com> wrot=
e:
>>> Hello,
>>>
>>> Our testing has discovered a crash (pagefault at 0x0000000000000008)
>>> which I have tracked down to bad __runq_remove() in csched_vcpu_sleep=
()
>>> in sched_credit.c (because a static function of the same name also
>>> exists in sched_credit2.c, which confused matters to start with)
>>>
>>> The test case was a loop of localhost migrate of a 1vcpu HVM win8
>>> domain. The test case itself has passed many times in the past on the
>>> same Xen codebase (Xen-4.1.3), indicating that it is very rare. There
>>> does not appear to be any relevant changes between the version of Xen=
 in
>>> the test and xen-4.1-testing.
>>>
>>> The failure itself is because of a XEN_DOMCTL_scheduler_op (trace bel=
ow)
>>> from dom0, targeting the VCPU of the migrating domain.
>>>
>>> (XEN) Xen call trace:
>>> (XEN) [<ffff82c480116a14>] csched_vcpu_sleep+0x44/0x70
>>> (XEN) 0[<ffff82c480120117>] vcpu_sleep_nosync+0xe7/0x3b0
>>> (XEN) 12[<ffff82c4801203e9>] vcpu_sleep_sync+0x9/0x50
>>> (XEN) 14[<ffff82c48011fd4c>] sched_adjust+0xac/0x230
>>> (XEN) 24[<ffff82c480102bc1>] do_domctl+0x731/0x1130
>>> (XEN) 64[<ffff82c4802013c4>] compat_hypercall+0x74/0x80
>>>
>>> The relevant part of csched_vcpu_sleep() is
>>>
>>> else if ( __vcpu_on_runq(svc) )
>>> __runq_remove(svc);
>>>
>>> which disassembles to
>>>
>>> ffff82c480116a01: 49 8b 10 mov (%r8),%rdx
>>> ffff82c480116a04: 4c 39 c2 cmp %r8,%rdx
>>> ffff82c480116a07: 75 07 jne ffff82c480116a10
>>> <csched_vcpu_sleep+0x40>
>>> ffff82c480116a09: f3 c3 repz retq
>>> ffff82c480116a0b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
>>> ffff82c480116a10: 49 8b 40 08 mov 0x8(%r8),%rax
>>> ffff82c480116a14: 48 89 42 08 mov %rax,0x8(%rdx) #
>>> <- Pagefault here
>>> ffff82c480116a18: 48 89 10 mov %rdx,(%rax)
>>> ffff82c480116a1b: 4d 89 40 08 mov %r8,0x8(%r8)
>>> ffff82c480116a1f: 4d 89 00 mov %r8,(%r8)
>>>
>>> The relevant crash registers from the pagefault are:
>>> rax: 0000000000000000
>>> rdx: 0000000000000000
>>> r8: ffff83080c89ed90
>>>
>>> If I am reading the code correctly, this means that runq->next is NUL=
L,
>>> so we fail list_empty() and erroneously pass __vcpu_on_runq(). We the=
n
>>> fail with a fault when trying to update runq->prev, which is also NUL=
L.
>>>
>>> The only place I can spot in the code where the runq->{next,prev} cou=
ld
>>> conceivably be NULL is in csched_alloc_vdata() between the memset() a=
nd
>>> INIT_LIST_HEAD(). This is logically sensible in combination with the
>>> localhost migrate loop, and I cant immediately see anything to preven=
t
>>> this race happening.
>>
>> But that doesn't make sense: csched_alloc_vdata() doesn't store
>> svc into vc->sched_priv; that's being done by the generic
>> scheduler code once the actor returns.
>>
>> So I'd rather suspect a stale pointer being used, which is easily
>> possible when racing with sched_move_domain() (as opposed to
>> schedule_cpu_switch(), where the new pointer gets stored
>> _before_ de-allocating the old one).
>>
>> However, sched_move_domain() (as well as schedule_cpu_switch())
>> get called only from CPU pools code, and I would guess CPU pools
>> aren't involved here, and you don't in parallel soft offline/online
>> pCPU-s (as I'm sure you otherwise would have mentioned it).
>>
>> But wait - libxl__domain_make() _unconditionally_ calls
>> xc_cpupool_movedomain(), as does XendDomainInfo's
>> _constructDomain(). The reason for this escapes me - J=FCrgen? Yet
>> I'd expect the pool ID matching check to short cut the resulting
>> sysctl, i.e. sched_move_domain() ought to not be reached anyway
>> (worth verifying of course).
>>
>> The race there nevertheless ought to be fixed.
>
> Something like the attached patch?
>
> Not tested thoroughly yet.

Argh. Sent an old version, sorry. This one should be better.

Juergen

--=20
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujits=
u.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.=
html

--------------000006070305000104040700
Content-Type: text/x-patch;
 name="movedom.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="movedom.patch"

Avoid stale pointer when moving domain to another cpupool

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e xen/common/schedule.c
--- a/xen/common/schedule.c     Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/schedule.c     Wed Feb 27 07:16:05 2013 +0100
@@ -231,12 +231,14 @@ int sched_move_domain(struct domain *d, 
     unsigned int new_p;
     void **vcpu_priv;
     void *domdata;
+    struct scheduler *old_ops;
+    void *old_domdata;
 
     domdata = SCHED_OP(c->sched, alloc_domdata, d);
     if ( domdata == NULL )
         return -ENOMEM;
 
-    vcpu_priv = xzalloc_array(void *, d->max_vcpus);
+    vcpu_priv = xzalloc_array(void *, d->max_vcpus * 2);
     if ( vcpu_priv == NULL )
     {
         SCHED_OP(c->sched, free_domdata, domdata);
@@ -257,18 +259,18 @@ int sched_move_domain(struct domain *d, 
             SCHED_OP(c->sched, free_domdata, domdata);
             return -ENOMEM;
         }
+        vcpu_priv[d->max_vcpus + v->vcpu_id] = v->sched_priv;
     }
 
     domain_pause(d);
 
+    old_ops = DOM2OP(d);
+    old_domdata = d->sched_priv;
+
     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;
@@ -289,6 +291,13 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(c->sched, insert_vcpu, v);
     }
+
+    for_each_vcpu ( d, v )
+    {
+        SCHED_OP(old_ops, free_vdata, vcpu_priv[d->max_vcpus + v->vcpu_id]);
+    }
+
+    SCHED_OP(old_ops, free_domdata, old_domdata);
 
     domain_update_node_affinity(d);


--------------000006070305000104040700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000006070305000104040700--


From xen-devel-bounces@lists.xen.org Wed Feb 27 06:29:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 06:29: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 1UAaVO-0006ap-En; Wed, 27 Feb 2013 06:28:42 +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 1UAaVM-0006ak-PW
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 06:28:41 +0000
Received: from [85.158.137.99:47418] by server-11.bemta-3.messagelabs.com id
	11/45-01263-397AD215; Wed, 27 Feb 2013 06:28:35 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361946514!17434646!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4OTA1NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1936 invoked from network); 27 Feb 2013 06:28:34 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 06:28:34 -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;
	b=sUeIcsn2yBOVgp7luDzDJOrSkqHIZUvFU08D1hMbMCo+1aEZDr+2lFzu
	D8pSTPcFCtqp+ixLgGKOzSpoLxkzFRp2sm2WCullTKgRFf2Eq9XAQWCQj
	dOR7bd0abqRSlB+T0GTnh3uQIGW/MnEoOzNXIuy2OHl8gqO4mpx0gGRWX
	k9YMvkcd3+wxNqxD9Vh4FT3E7HoWh9GYQUqa144VA7psFp+JCJP/S7fwc
	RtodAYavKlYKs8lW5AtCplnTe/gDR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361946514; x=1393482514;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to;
	bh=uBeKHX0BZ2RQYjL2hX+G2VSWdt3a4pChI9+MvXqChaw=;
	b=KDOyuibF4heE/wSTSkbuXRaY7wlJMDDCzP0g+86p+2WcD2U6IuGT7Ry9
	52hjbTgwLHGLU1AuP2+V9DM9GOlCwmubIQQt9NihgzuvS/p+Um7uUHzKo
	UyCYzU6dpFKEYldYmcPmVGfK5TLWB3TEq2DLS+afSPPGtcb7/PV+jDy26
	LxE2KyNiPMDZbTJZk1V7tCXlDD7SRFoaeTZMn1yJJ9J9Fq/W92ABfzXcI
	ol0gdnjH26lSyPTJ4fT730pO+cnR+;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; d="scan'208";a="138142607"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Feb 2013 07:28:12 +0100
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; 
   d="scan'208";a="5101560"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 07:28:12 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B166696C29A;
	Wed, 27 Feb 2013 07:28:11 +0100 (CET)
Message-ID: <512DA77B.90001@ts.fujitsu.com>
Date: Wed, 27 Feb 2013 07:28:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<512DA58C.4060604@ts.fujitsu.com>
In-Reply-To: <512DA58C.4060604@ts.fujitsu.com>
Content-Type: multipart/mixed; boundary="------------000006070305000104040700"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.
--------------000006070305000104040700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 27.02.2013 07:19, Juergen Gross wrote:
> On 19.02.2013 10:28, Jan Beulich wrote:
>>>>> On 18.02.13 at 19:11, Andrew Cooper<andrew.cooper3@citrix.com> wrot=
e:
>>> Hello,
>>>
>>> Our testing has discovered a crash (pagefault at 0x0000000000000008)
>>> which I have tracked down to bad __runq_remove() in csched_vcpu_sleep=
()
>>> in sched_credit.c (because a static function of the same name also
>>> exists in sched_credit2.c, which confused matters to start with)
>>>
>>> The test case was a loop of localhost migrate of a 1vcpu HVM win8
>>> domain. The test case itself has passed many times in the past on the
>>> same Xen codebase (Xen-4.1.3), indicating that it is very rare. There
>>> does not appear to be any relevant changes between the version of Xen=
 in
>>> the test and xen-4.1-testing.
>>>
>>> The failure itself is because of a XEN_DOMCTL_scheduler_op (trace bel=
ow)
>>> from dom0, targeting the VCPU of the migrating domain.
>>>
>>> (XEN) Xen call trace:
>>> (XEN) [<ffff82c480116a14>] csched_vcpu_sleep+0x44/0x70
>>> (XEN) 0[<ffff82c480120117>] vcpu_sleep_nosync+0xe7/0x3b0
>>> (XEN) 12[<ffff82c4801203e9>] vcpu_sleep_sync+0x9/0x50
>>> (XEN) 14[<ffff82c48011fd4c>] sched_adjust+0xac/0x230
>>> (XEN) 24[<ffff82c480102bc1>] do_domctl+0x731/0x1130
>>> (XEN) 64[<ffff82c4802013c4>] compat_hypercall+0x74/0x80
>>>
>>> The relevant part of csched_vcpu_sleep() is
>>>
>>> else if ( __vcpu_on_runq(svc) )
>>> __runq_remove(svc);
>>>
>>> which disassembles to
>>>
>>> ffff82c480116a01: 49 8b 10 mov (%r8),%rdx
>>> ffff82c480116a04: 4c 39 c2 cmp %r8,%rdx
>>> ffff82c480116a07: 75 07 jne ffff82c480116a10
>>> <csched_vcpu_sleep+0x40>
>>> ffff82c480116a09: f3 c3 repz retq
>>> ffff82c480116a0b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
>>> ffff82c480116a10: 49 8b 40 08 mov 0x8(%r8),%rax
>>> ffff82c480116a14: 48 89 42 08 mov %rax,0x8(%rdx) #
>>> <- Pagefault here
>>> ffff82c480116a18: 48 89 10 mov %rdx,(%rax)
>>> ffff82c480116a1b: 4d 89 40 08 mov %r8,0x8(%r8)
>>> ffff82c480116a1f: 4d 89 00 mov %r8,(%r8)
>>>
>>> The relevant crash registers from the pagefault are:
>>> rax: 0000000000000000
>>> rdx: 0000000000000000
>>> r8: ffff83080c89ed90
>>>
>>> If I am reading the code correctly, this means that runq->next is NUL=
L,
>>> so we fail list_empty() and erroneously pass __vcpu_on_runq(). We the=
n
>>> fail with a fault when trying to update runq->prev, which is also NUL=
L.
>>>
>>> The only place I can spot in the code where the runq->{next,prev} cou=
ld
>>> conceivably be NULL is in csched_alloc_vdata() between the memset() a=
nd
>>> INIT_LIST_HEAD(). This is logically sensible in combination with the
>>> localhost migrate loop, and I cant immediately see anything to preven=
t
>>> this race happening.
>>
>> But that doesn't make sense: csched_alloc_vdata() doesn't store
>> svc into vc->sched_priv; that's being done by the generic
>> scheduler code once the actor returns.
>>
>> So I'd rather suspect a stale pointer being used, which is easily
>> possible when racing with sched_move_domain() (as opposed to
>> schedule_cpu_switch(), where the new pointer gets stored
>> _before_ de-allocating the old one).
>>
>> However, sched_move_domain() (as well as schedule_cpu_switch())
>> get called only from CPU pools code, and I would guess CPU pools
>> aren't involved here, and you don't in parallel soft offline/online
>> pCPU-s (as I'm sure you otherwise would have mentioned it).
>>
>> But wait - libxl__domain_make() _unconditionally_ calls
>> xc_cpupool_movedomain(), as does XendDomainInfo's
>> _constructDomain(). The reason for this escapes me - J=FCrgen? Yet
>> I'd expect the pool ID matching check to short cut the resulting
>> sysctl, i.e. sched_move_domain() ought to not be reached anyway
>> (worth verifying of course).
>>
>> The race there nevertheless ought to be fixed.
>
> Something like the attached patch?
>
> Not tested thoroughly yet.

Argh. Sent an old version, sorry. This one should be better.

Juergen

--=20
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujits=
u.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.=
html

--------------000006070305000104040700
Content-Type: text/x-patch;
 name="movedom.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="movedom.patch"

Avoid stale pointer when moving domain to another cpupool

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e xen/common/schedule.c
--- a/xen/common/schedule.c     Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/schedule.c     Wed Feb 27 07:16:05 2013 +0100
@@ -231,12 +231,14 @@ int sched_move_domain(struct domain *d, 
     unsigned int new_p;
     void **vcpu_priv;
     void *domdata;
+    struct scheduler *old_ops;
+    void *old_domdata;
 
     domdata = SCHED_OP(c->sched, alloc_domdata, d);
     if ( domdata == NULL )
         return -ENOMEM;
 
-    vcpu_priv = xzalloc_array(void *, d->max_vcpus);
+    vcpu_priv = xzalloc_array(void *, d->max_vcpus * 2);
     if ( vcpu_priv == NULL )
     {
         SCHED_OP(c->sched, free_domdata, domdata);
@@ -257,18 +259,18 @@ int sched_move_domain(struct domain *d, 
             SCHED_OP(c->sched, free_domdata, domdata);
             return -ENOMEM;
         }
+        vcpu_priv[d->max_vcpus + v->vcpu_id] = v->sched_priv;
     }
 
     domain_pause(d);
 
+    old_ops = DOM2OP(d);
+    old_domdata = d->sched_priv;
+
     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;
@@ -289,6 +291,13 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(c->sched, insert_vcpu, v);
     }
+
+    for_each_vcpu ( d, v )
+    {
+        SCHED_OP(old_ops, free_vdata, vcpu_priv[d->max_vcpus + v->vcpu_id]);
+    }
+
+    SCHED_OP(old_ops, free_domdata, old_domdata);
 
     domain_update_node_affinity(d);


--------------000006070305000104040700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000006070305000104040700--


From xen-devel-bounces@lists.xen.org Wed Feb 27 07:21:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 07:21: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 1UAbKO-0008HA-F6; Wed, 27 Feb 2013 07:21: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 1UAbKM-0008H5-RA
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 07:21:23 +0000
Received: from [85.158.137.99:3297] by server-10.bemta-3.messagelabs.com id
	0A/72-19664-DE3BD215; Wed, 27 Feb 2013 07:21:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361949665!15946993!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24863 invoked from network); 27 Feb 2013 07:21:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 07:21:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1936775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 07: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.297.1; Wed, 27 Feb 2013 07:21:04 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAbK4-0004aZ-Mc;
	Wed, 27 Feb 2013 07:21:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAbK4-0008MD-I1;
	Wed, 27 Feb 2013 07:21:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16753-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 07:21:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16753: 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 16753 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16753/

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. 16678

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16678
 test-amd64-i386-xl-qemut-win-vcpus1 12 guest-localmigrate/x10  fail like 16234

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-win  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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
baseline version:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Marek Marczykowski <marmarek@invisiblethingslab.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
Author: Marek Marczykowski <marmarek@invisiblethingslab.com>
Date:   Sun Feb 24 01:22:00 2013 +0000

    libxl: Fix uninitialized variable in libxl_create_stubdom
    
    It is used for result domid from libxl__domain_make, but actually this
    function have assert on an initial value.
    
    This patch is intended for xen-4.1 only - 4.2 and later have reworked
    this part of code already containing the fix.
    
    Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 07:21:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 07:21: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 1UAbKO-0008HA-F6; Wed, 27 Feb 2013 07:21: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 1UAbKM-0008H5-RA
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 07:21:23 +0000
Received: from [85.158.137.99:3297] by server-10.bemta-3.messagelabs.com id
	0A/72-19664-DE3BD215; Wed, 27 Feb 2013 07:21:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361949665!15946993!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24863 invoked from network); 27 Feb 2013 07:21:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 07:21:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1936775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 07: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.297.1; Wed, 27 Feb 2013 07:21:04 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAbK4-0004aZ-Mc;
	Wed, 27 Feb 2013 07:21:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAbK4-0008MD-I1;
	Wed, 27 Feb 2013 07:21:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16753-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 07:21:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16753: 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 16753 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16753/

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. 16678

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16678
 test-amd64-i386-xl-qemut-win-vcpus1 12 guest-localmigrate/x10  fail like 16234

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemut-win  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-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
baseline version:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Marek Marczykowski <marmarek@invisiblethingslab.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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 1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
Author: Marek Marczykowski <marmarek@invisiblethingslab.com>
Date:   Sun Feb 24 01:22:00 2013 +0000

    libxl: Fix uninitialized variable in libxl_create_stubdom
    
    It is used for result domid from libxl__domain_make, but actually this
    function have assert on an initial value.
    
    This patch is intended for xen-4.1 only - 4.2 and later have reworked
    this part of code already containing the fix.
    
    Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 07:38:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 07: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 1UAbaL-0008VB-6r; Wed, 27 Feb 2013 07:37:53 +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 1UAbaJ-0008V6-NU
	for Xen-devel@lists.xen.org; Wed, 27 Feb 2013 07:37:52 +0000
Received: from [85.158.139.211:47406] by server-8.bemta-5.messagelabs.com id
	B3/5B-05790-EC7BD215; Wed, 27 Feb 2013 07:37:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361950670!19511848!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31088 invoked from network); 27 Feb 2013 07:37:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 07:37:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 07:37:49 +0000
Message-Id: <512DC5DA02000078000C153B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 07:37:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xinxin Jin" <xinxinjin89@gmail.com>
References: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
	<512C810402000078000C0FBB@nat28.tlf.novell.com>
	<CAJJWZcxLuk-L6RzL6pJrUfbzqbaMvF+6G1mBTJRO1KZ95RBYaw@mail.gmail.com>
In-Reply-To: <CAJJWZcxLuk-L6RzL6pJrUfbzqbaMvF+6G1mBTJRO1KZ95RBYaw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] When does Xen build 1:1 direct mapping of all
 physical 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

>>> On 26.02.13 at 23:23, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> Hi Jan, I think init_frametable() is to initialize frame table, whose
> virtual address starts at FRAMETABLE_VIRT_START ? How about the direct 1:1
> mapping of all of machine memroy whose virtual address start at
> DIRECTMAP_VIRT_START?

Oh, sorry, yes, this isn't the direct mapping.

Check the calls to map_pages_to_xen() in __start_xen() for the
direct mapping.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 07:38:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 07: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 1UAbaL-0008VB-6r; Wed, 27 Feb 2013 07:37:53 +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 1UAbaJ-0008V6-NU
	for Xen-devel@lists.xen.org; Wed, 27 Feb 2013 07:37:52 +0000
Received: from [85.158.139.211:47406] by server-8.bemta-5.messagelabs.com id
	B3/5B-05790-EC7BD215; Wed, 27 Feb 2013 07:37:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1361950670!19511848!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31088 invoked from network); 27 Feb 2013 07:37:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 07:37:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 07:37:49 +0000
Message-Id: <512DC5DA02000078000C153B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 07:37:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Xinxin Jin" <xinxinjin89@gmail.com>
References: <CAJJWZcxEHg=aCxWb=HPrv8WovORbJegRi6gtTpva8DspddFcog@mail.gmail.com>
	<512C810402000078000C0FBB@nat28.tlf.novell.com>
	<CAJJWZcxLuk-L6RzL6pJrUfbzqbaMvF+6G1mBTJRO1KZ95RBYaw@mail.gmail.com>
In-Reply-To: <CAJJWZcxLuk-L6RzL6pJrUfbzqbaMvF+6G1mBTJRO1KZ95RBYaw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] When does Xen build 1:1 direct mapping of all
 physical 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

>>> On 26.02.13 at 23:23, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> Hi Jan, I think init_frametable() is to initialize frame table, whose
> virtual address starts at FRAMETABLE_VIRT_START ? How about the direct 1:1
> mapping of all of machine memroy whose virtual address start at
> DIRECTMAP_VIRT_START?

Oh, sorry, yes, this isn't the direct mapping.

Check the calls to map_pages_to_xen() in __start_xen() for the
direct mapping.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 07:39:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 07:39: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 1UAbbb-00007D-Np; Wed, 27 Feb 2013 07:39:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAbba-000071-9i
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 07:39:10 +0000
Received: from [85.158.143.99:46235] by server-3.bemta-4.messagelabs.com id
	DF/77-02186-D18BD215; Wed, 27 Feb 2013 07:39:09 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361950747!17932389!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUwMzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23054 invoked from network); 27 Feb 2013 07:39:09 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 07:39:09 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1R7d5Wt025712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 07:39:05 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
	r1R7d48I020985
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 07:39:05 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
	r1R7d4Yb007634; Wed, 27 Feb 2013 01:39:04 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 23:39:04 -0800
Message-ID: <512DB83A.6050503@oracle.com>
Date: Wed, 27 Feb 2013 15:39:38 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
In-Reply-To: <1361882139.2109.52.camel@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-26 20:35, Wei Liu wrote:
> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
>> On 2013-2-16 0:00, Wei Liu wrote:
>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
>>> ---
>>>    drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
>>>    1 file changed, 174 insertions(+), 72 deletions(-)
>>>
>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>> index 8bd75a1..de73a71 100644
>>> --- a/drivers/net/xen-netfront.c
>>> +++ b/drivers/net/xen-netfront.c
>>> @@ -67,9 +67,19 @@ struct netfront_cb {
>>>
>>>    #define GRANT_INVALID_REF   0
>>>
>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
>>> +#define XENNET_MAX_RING_PAGES      (1U<<   XENNET_MAX_RING_PAGE_ORDER)
>>> +
>>> +
>>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
>>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
>>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
>>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
>>> +
>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>> +
>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
>> Not using multi-page ring here?
>> In xennet_create_dev, gnttab_alloc_grant_references allocates
>> TX_MAX_TARGET number of grant reference for tx. In
>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
>> skb_entry_is_link helps to not release invalid grants, lots of null loop
>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
>> variableconnected with np->tx_ring_pages. Or you intended to use one
>> page ring here?
>>
> Looking back my history, this limitation was introduced because if we
> have a multi-page backend and single page frontend, the backend skb
> processing could overlap.

I did not see the overlap you mentioned here in netback. Although 
netback supports multi-page, netback->vif still uses single page if the 
frontend only supports single page. Netfront and netback negotiate this 
through xenstore in your 5/8 patch. The requests and response should not 
have any overlap between netback and netfront. Am I missing something?

>
> I agree with you that this limit should be variable, but as we still use
> M:N model, the safe option is to cap this limit to 1 page.

Yes, M:N model is still used here. But the share ring should be same for 
netback->vif and netfront.

Thanks
Annie

>
> Another option is to check validity of skbs before processing them. I
> will look into that as well.
>
> The same reason applies to the RX ring as well.
>
>
> Wei.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 07:39:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 07:39: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 1UAbbb-00007D-Np; Wed, 27 Feb 2013 07:39:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAbba-000071-9i
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 07:39:10 +0000
Received: from [85.158.143.99:46235] by server-3.bemta-4.messagelabs.com id
	DF/77-02186-D18BD215; Wed, 27 Feb 2013 07:39:09 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1361950747!17932389!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUwMzQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23054 invoked from network); 27 Feb 2013 07:39:09 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 07:39:09 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1R7d5Wt025712
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 07:39:05 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
	r1R7d48I020985
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 07:39:05 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
	r1R7d4Yb007634; Wed, 27 Feb 2013 01:39:04 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 26 Feb 2013 23:39:04 -0800
Message-ID: <512DB83A.6050503@oracle.com>
Date: Wed, 27 Feb 2013 15:39:38 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
In-Reply-To: <1361882139.2109.52.camel@zion.uk.xensource.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-26 20:35, Wei Liu wrote:
> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
>> On 2013-2-16 0:00, Wei Liu wrote:
>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
>>> ---
>>>    drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
>>>    1 file changed, 174 insertions(+), 72 deletions(-)
>>>
>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>> index 8bd75a1..de73a71 100644
>>> --- a/drivers/net/xen-netfront.c
>>> +++ b/drivers/net/xen-netfront.c
>>> @@ -67,9 +67,19 @@ struct netfront_cb {
>>>
>>>    #define GRANT_INVALID_REF   0
>>>
>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
>>> +#define XENNET_MAX_RING_PAGES      (1U<<   XENNET_MAX_RING_PAGE_ORDER)
>>> +
>>> +
>>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
>>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
>>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
>>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
>>> +
>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>> +
>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
>> Not using multi-page ring here?
>> In xennet_create_dev, gnttab_alloc_grant_references allocates
>> TX_MAX_TARGET number of grant reference for tx. In
>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
>> skb_entry_is_link helps to not release invalid grants, lots of null loop
>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
>> variableconnected with np->tx_ring_pages. Or you intended to use one
>> page ring here?
>>
> Looking back my history, this limitation was introduced because if we
> have a multi-page backend and single page frontend, the backend skb
> processing could overlap.

I did not see the overlap you mentioned here in netback. Although 
netback supports multi-page, netback->vif still uses single page if the 
frontend only supports single page. Netfront and netback negotiate this 
through xenstore in your 5/8 patch. The requests and response should not 
have any overlap between netback and netfront. Am I missing something?

>
> I agree with you that this limit should be variable, but as we still use
> M:N model, the safe option is to cap this limit to 1 page.

Yes, M:N model is still used here. But the share ring should be same for 
netback->vif and netfront.

Thanks
Annie

>
> Another option is to check validity of skbs before processing them. I
> will look into that as well.
>
> The same reason applies to the RX ring as well.
>
>
> Wei.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:32:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08:32: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 1UAcQh-0001DJ-Fj; Wed, 27 Feb 2013 08:31:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luokain@gmail.com>) id 1UAVw1-0002eo-Cp
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 01:35:53 +0000
Received: from [85.158.143.99:9956] by server-1.bemta-4.messagelabs.com id
	3F/E0-06203-8F26D215; Wed, 27 Feb 2013 01:35:52 +0000
X-Env-Sender: luokain@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361928950!29338813!1
X-Originating-IP: [209.85.219.66]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4461 invoked from network); 27 Feb 2013 01:35:51 -0000
Received: from mail-oa0-f66.google.com (HELO mail-oa0-f66.google.com)
	(209.85.219.66)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 01:35:51 -0000
Received: by mail-oa0-f66.google.com with SMTP id h2so26479oag.9
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 17:35:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=iOZ5jKYF9YUf/U7HzppSA6zb2JxdqR9yC66zx3XOtrE=;
	b=OTOYIafUXJRetO66oALDyCJviVvqhUjWD20XqQvpk4trq8gIjdWLRMyJjLnvMAZOPJ
	1shg8fsWpXASwVnKapoNb/CJxVtyaGZbbRbj+DQcGOkWlpna1OF2uEaUgWxHrVN418AO
	m50r79CPTOWT/n8BHaq4JXQ5Naabic/qAyt1qsKw0OnJz+J7nPlj3kd12DPVH5kEqAE5
	2Z3IcQGTsAnZAR/hVKfQ44Ba2VrDV6t+bTteCLuq1PHxvRLrD4ECeo8AxkK53E3LsLlq
	6h4nQLrw2wAjBA6dCnRHteSazUu1ehHa3+r+8nnshpui3RZLGSpBRAZpiO3hUYnKlXqP
	YVAA==
MIME-Version: 1.0
X-Received: by 10.182.157.104 with SMTP id wl8mr351920obb.79.1361928950127;
	Tue, 26 Feb 2013 17:35:50 -0800 (PST)
Received: by 10.76.153.33 with HTTP; Tue, 26 Feb 2013 17:35:49 -0800 (PST)
Date: Wed, 27 Feb 2013 09:35:49 +0800
Message-ID: <CAN71wUJfN3bj4avk0Ggc9myarow7G=vxyz5wQDwgrvsxO-cJQQ@mail.gmail.com>
From: Kai Luo <luokain@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 27 Feb 2013 08:31:58 +0000
Subject: [Xen-devel] A question about VM's access 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: multipart/mixed; boundary="===============1658168695553040682=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1658168695553040682==
Content-Type: multipart/alternative; boundary=f46d044281a048303904d6aacb4e

--f46d044281a048303904d6aacb4e
Content-Type: text/plain; charset=ISO-8859-1

Hi:
     For a HVM I kown the Xen Hypervisor  maintains a set of shadow
pages,may be 2 levels or 4 levels.Under normal conditions ,without xen,a
process wants to  access memory,the system will read CR3 to find the
physical address of the page tables,then find the physical address of the
next level,then the next,that will be multiple memory access(ignoring the
TLB).My question is,when the system runs as a domain of xen, whether it is
needed to triger a VM-EXIT when the system wants to find the physical
address of next level of page table,if so when a guest want to access
memory there will be VM-EXIT many times,if not how the system knows the
address of next level of page tables ?
    Thank you for your answering!

Jeap

--f46d044281a048303904d6aacb4e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi:<div>=A0 =A0 =A0For a HVM I kown the Xen Hypervisor =A0maintains a set o=
f shadow pages,may be 2 levels or 4 levels.Under normal conditions ,without=
 xen,a process wants to =A0access memory,the system will read CR3 to find t=
he physical address of the page tables,then find the physical address of th=
e next level,then the next,that will be multiple memory access(ignoring the=
 TLB).My question is,when the system runs as a domain of xen, whether it is=
 needed to triger a VM-EXIT when the system wants to find the physical addr=
ess of next level of page table,if so when a guest want to access memory th=
ere will be VM-EXIT many times,if not how the system knows the address of n=
ext level of page tables ?</div>
<div>=A0 =A0 Thank you for your answering!</div><div><br></div><div>Jeap</d=
iv>

--f46d044281a048303904d6aacb4e--


--===============1658168695553040682==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1658168695553040682==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 08:32:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08:32: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 1UAcQh-0001DJ-Fj; Wed, 27 Feb 2013 08:31:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <luokain@gmail.com>) id 1UAVw1-0002eo-Cp
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 01:35:53 +0000
Received: from [85.158.143.99:9956] by server-1.bemta-4.messagelabs.com id
	3F/E0-06203-8F26D215; Wed, 27 Feb 2013 01:35:52 +0000
X-Env-Sender: luokain@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361928950!29338813!1
X-Originating-IP: [209.85.219.66]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4461 invoked from network); 27 Feb 2013 01:35:51 -0000
Received: from mail-oa0-f66.google.com (HELO mail-oa0-f66.google.com)
	(209.85.219.66)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 01:35:51 -0000
Received: by mail-oa0-f66.google.com with SMTP id h2so26479oag.9
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 17:35:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=iOZ5jKYF9YUf/U7HzppSA6zb2JxdqR9yC66zx3XOtrE=;
	b=OTOYIafUXJRetO66oALDyCJviVvqhUjWD20XqQvpk4trq8gIjdWLRMyJjLnvMAZOPJ
	1shg8fsWpXASwVnKapoNb/CJxVtyaGZbbRbj+DQcGOkWlpna1OF2uEaUgWxHrVN418AO
	m50r79CPTOWT/n8BHaq4JXQ5Naabic/qAyt1qsKw0OnJz+J7nPlj3kd12DPVH5kEqAE5
	2Z3IcQGTsAnZAR/hVKfQ44Ba2VrDV6t+bTteCLuq1PHxvRLrD4ECeo8AxkK53E3LsLlq
	6h4nQLrw2wAjBA6dCnRHteSazUu1ehHa3+r+8nnshpui3RZLGSpBRAZpiO3hUYnKlXqP
	YVAA==
MIME-Version: 1.0
X-Received: by 10.182.157.104 with SMTP id wl8mr351920obb.79.1361928950127;
	Tue, 26 Feb 2013 17:35:50 -0800 (PST)
Received: by 10.76.153.33 with HTTP; Tue, 26 Feb 2013 17:35:49 -0800 (PST)
Date: Wed, 27 Feb 2013 09:35:49 +0800
Message-ID: <CAN71wUJfN3bj4avk0Ggc9myarow7G=vxyz5wQDwgrvsxO-cJQQ@mail.gmail.com>
From: Kai Luo <luokain@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 27 Feb 2013 08:31:58 +0000
Subject: [Xen-devel] A question about VM's access 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: multipart/mixed; boundary="===============1658168695553040682=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1658168695553040682==
Content-Type: multipart/alternative; boundary=f46d044281a048303904d6aacb4e

--f46d044281a048303904d6aacb4e
Content-Type: text/plain; charset=ISO-8859-1

Hi:
     For a HVM I kown the Xen Hypervisor  maintains a set of shadow
pages,may be 2 levels or 4 levels.Under normal conditions ,without xen,a
process wants to  access memory,the system will read CR3 to find the
physical address of the page tables,then find the physical address of the
next level,then the next,that will be multiple memory access(ignoring the
TLB).My question is,when the system runs as a domain of xen, whether it is
needed to triger a VM-EXIT when the system wants to find the physical
address of next level of page table,if so when a guest want to access
memory there will be VM-EXIT many times,if not how the system knows the
address of next level of page tables ?
    Thank you for your answering!

Jeap

--f46d044281a048303904d6aacb4e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi:<div>=A0 =A0 =A0For a HVM I kown the Xen Hypervisor =A0maintains a set o=
f shadow pages,may be 2 levels or 4 levels.Under normal conditions ,without=
 xen,a process wants to =A0access memory,the system will read CR3 to find t=
he physical address of the page tables,then find the physical address of th=
e next level,then the next,that will be multiple memory access(ignoring the=
 TLB).My question is,when the system runs as a domain of xen, whether it is=
 needed to triger a VM-EXIT when the system wants to find the physical addr=
ess of next level of page table,if so when a guest want to access memory th=
ere will be VM-EXIT many times,if not how the system knows the address of n=
ext level of page tables ?</div>
<div>=A0 =A0 Thank you for your answering!</div><div><br></div><div>Jeap</d=
iv>

--f46d044281a048303904d6aacb4e--


--===============1658168695553040682==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1658168695553040682==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 08:32:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08: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 1UAcQp-0001Df-TJ; Wed, 27 Feb 2013 08:32:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ipavlikevich@gmail.com>) id 1UAPLu-0008I5-Nl
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 18:34:11 +0000
Received: from [85.158.139.83:16635] by server-5.bemta-5.messagelabs.com id
	D9/08-02762-1200D215; Tue, 26 Feb 2013 18:34:09 +0000
X-Env-Sender: ipavlikevich@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361903647!29095808!1
X-Originating-IP: [209.85.210.178]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27250 invoked from network); 26 Feb 2013 18:34:08 -0000
Received: from mail-ia0-f178.google.com (HELO mail-ia0-f178.google.com)
	(209.85.210.178)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 18:34:08 -0000
Received: by mail-ia0-f178.google.com with SMTP id y26so3811064iab.9
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 10:34:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Q7BrMn9qIuKHqTALa122rv+MFnu2WEfL98H4F2XX3dA=;
	b=gc6+zj/uRzIWD4Ntn2GBZlFwF8lTdpzf/ib35H7VIg7H6w0lndlfrjWgu9YTWSgVut
	9CaZ+cpoGfZFYG0HT8lunnfymQ9j4Ulw6Bz9Nf44I7DrPq0uuhNeI142OnlS+4GMEcjW
	6eV68LJPXk08sCWaeJs8oK5g4FHQLQ1vSoLNIQ4a+r3mbDBIWTV6mAMJm8VIuQmiFNg4
	BwGKmkUkm/UKcTDsXHjHk3G1L38CRTNNderilBEiGB3MMoqdz8dJ4+dFwqiSqQHaWdCh
	uxVlEunjGhzmdnLglyKpSi6Ci8Vr6mIkvgLcWsoSjPmOadVxpSMEzEiATHT3Qnk/3pzB
	yGqA==
MIME-Version: 1.0
X-Received: by 10.50.57.131 with SMTP id i3mr5889925igq.29.1361903647011; Tue,
	26 Feb 2013 10:34:07 -0800 (PST)
Received: by 10.43.47.202 with HTTP; Tue, 26 Feb 2013 10:34:06 -0800 (PST)
In-Reply-To: <CAFLBxZbRnBy5AFXw6_9mvRt+svA7j3f6hB2YqOQBL7z3LpV0rw@mail.gmail.com>
References: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
	<CAFLBxZbRnBy5AFXw6_9mvRt+svA7j3f6hB2YqOQBL7z3LpV0rw@mail.gmail.com>
Date: Tue, 26 Feb 2013 22:34:06 +0400
Message-ID: <CA+O_+Ex6O=rnRkD8Li1id27CgAN6RnhB8E=NCMEYq9ZJzDZ48A@mail.gmail.com>
From: Igor Pavlikevich <ipavlikevich@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
X-Mailman-Approved-At: Wed, 27 Feb 2013 08:32:07 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: fix race condition in csched_vcpu
	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: multipart/mixed; boundary="===============1190172331924257694=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1190172331924257694==
Content-Type: multipart/alternative; boundary=14dae9340fad193b7204d6a4e720

--14dae9340fad193b7204d6a4e720
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 6:19 PM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:

> On Mon, Feb 25, 2013 at 8:20 AM, Igor Pavlikevich <ipavlikevich@gmail.com>wrote:
>
>> When vcpu stops yielding, it's possible to overwrite
>> CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_YIELD.
>>
>>  332.970218393 -------x d1v1 runstate_continue d1v1 running->running
>> ]332.970248371 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>>  yielding, flags=0x0002
>> ]332.970251968 -------x d1v1
>> clearing 0x0002, flags=0
>>  332.970252175 -------x d1v1 runstate_continue d1v1 running->running
>> ]332.970282574 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>>  yielding, flags=0x0002
>> ]332.970283068 x------| d32767v0
>> entering csched_acct(), d1v1 flags=0x0002
>> ]332.970285763 x------| d32767v0   28003(2:8:3) 2 [ 1 1 ]
>>  calling vcpu_pause_nosync() for d1v1
>> ]332.970286647 -------x d1v1
>> clearing 0x0002, flags=0
>> ]332.970286771 x------| d32767v0
>> flags |= CSCHED_FLAG_VCPU_PARKED, flags=0x0003
>> ]332.970286990 -------x d1v1   2800e(2:8:e) 2 [ 1 1cacfca ]
>> ]332.970287122 -------x d1v1   2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]
>> ]332.970287242 -------x d1v1   2800a(2:8:a) 4 [ 1 1 7fff 7 ]
>> exiting schedule(), flags=0
>>  332.970287417 -------x d1v1 runstate_change d1v1 running->offline
>>  332.970287629 -------x d?v? runstate_change d32767v7 runnable->running
>> ]332.970288397 x------- d32767v0
>> exiting csched_acct(), flags=0x0003
>> ]332.995349690 x------- d32767v0
>> entering csched_acct(), d1v1 flags=0x0000, flag lost.
>> ]332.995352170 x------- d32767v0   28003(2:8:3) 2 [ 1 1 ]
>>  calling vcpu_pause_nosync() for d1v1 again
>>
>> From this moment d1v1 has extra +1 in pause_count, so it goes offline
>> right after credit>prv->credits_per_tslice forever.
>>
>
> Good catch -- I guess we don't really test the scheduler "cap"
> functionality enough to catch this one.
>
> Unfortunately I think the real problem is that the ->flags field should be
> uniformly using the atomic bit operations.
>
> Can you try the attached patch and see if it works for you?
>
>
Thanks for help, your patch works well.

--14dae9340fad193b7204d6a4e720
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Feb 26, 2013 at 6:19 PM, George Dunlap <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:George.Dunlap@eu.citrix.com" target=3D"_blank">George.Dunlap@eu=
.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 dir=3D"ltr"><div class=3D"im">On Mon, F=
eb 25, 2013 at 8:20 AM, Igor Pavlikevich <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:ipavlikevich@gmail.com" target=3D"_blank">ipavlikevich@gmail.com</a>&=
gt;</span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"i=
m">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">When vcpu stops yielding, it&#39;s possible =
to overwrite CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_Y=
IELD.<br>


<br>
=A0332.970218393 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970248371 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970251968 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
=A0332.970252175 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970282574 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970283068 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0002<br>
]332.970285763 x------| d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1<br>
]332.970286647 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
]332.970286771 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags |=3D CSCHED_FLAG_VCPU_PARKED, fla=
gs=3D0x0003<br>
]332.970286990 -------x d1v1 =A0 2800e(2:8:e) 2 [ 1 1cacfca ]<br>
]332.970287122 -------x d1v1 =A0 2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]<b=
r>
]332.970287242 -------x d1v1 =A0 2800a(2:8:a) 4 [ 1 1 7fff 7 ] =A0 =A0 =A0 =
=A0 =A0 exiting schedule(), flags=3D0<br>
=A0332.970287417 -------x d1v1 runstate_change d1v1 running-&gt;offline<br>
=A0332.970287629 -------x d?v? runstate_change d32767v7 runnable-&gt;runnin=
g<br>
]332.970288397 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exiting csched_acct(), flags=3D0x0003<b=
r>
]332.995349690 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0000, flag lost.<br>
]332.995352170 x------- d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1 again<br>
<br>
>From this moment d1v1 has extra +1 in pause_count, so it goes offline right=
 after credit&gt;prv-&gt;credits_per_tslice forever.<br></blockquote><div><=
br></div></div><div>Good catch -- I guess we don&#39;t really test the sche=
duler &quot;cap&quot; functionality enough to catch this one.<br>

<br></div><div>Unfortunately I think the real problem is that the -&gt;flag=
s field should be uniformly using the atomic bit operations.<br><br>Can you=
 try the attached patch and see if it works for you?<span class=3D"HOEnZb">=
<font color=3D"#888888"><br>
<br></font></span></div></div></div></div></blockquote><div><br></div><div>=
Thanks for help, your patch works well. <br></div></div></div></div>

--14dae9340fad193b7204d6a4e720--


--===============1190172331924257694==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1190172331924257694==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 08:32:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08: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 1UAcQp-0001Df-TJ; Wed, 27 Feb 2013 08:32:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ipavlikevich@gmail.com>) id 1UAPLu-0008I5-Nl
	for xen-devel@lists.xen.org; Tue, 26 Feb 2013 18:34:11 +0000
Received: from [85.158.139.83:16635] by server-5.bemta-5.messagelabs.com id
	D9/08-02762-1200D215; Tue, 26 Feb 2013 18:34:09 +0000
X-Env-Sender: ipavlikevich@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1361903647!29095808!1
X-Originating-IP: [209.85.210.178]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27250 invoked from network); 26 Feb 2013 18:34:08 -0000
Received: from mail-ia0-f178.google.com (HELO mail-ia0-f178.google.com)
	(209.85.210.178)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Feb 2013 18:34:08 -0000
Received: by mail-ia0-f178.google.com with SMTP id y26so3811064iab.9
	for <xen-devel@lists.xen.org>; Tue, 26 Feb 2013 10:34:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:in-reply-to:references:date:message-id
	:subject:from:to:cc:content-type;
	bh=Q7BrMn9qIuKHqTALa122rv+MFnu2WEfL98H4F2XX3dA=;
	b=gc6+zj/uRzIWD4Ntn2GBZlFwF8lTdpzf/ib35H7VIg7H6w0lndlfrjWgu9YTWSgVut
	9CaZ+cpoGfZFYG0HT8lunnfymQ9j4Ulw6Bz9Nf44I7DrPq0uuhNeI142OnlS+4GMEcjW
	6eV68LJPXk08sCWaeJs8oK5g4FHQLQ1vSoLNIQ4a+r3mbDBIWTV6mAMJm8VIuQmiFNg4
	BwGKmkUkm/UKcTDsXHjHk3G1L38CRTNNderilBEiGB3MMoqdz8dJ4+dFwqiSqQHaWdCh
	uxVlEunjGhzmdnLglyKpSi6Ci8Vr6mIkvgLcWsoSjPmOadVxpSMEzEiATHT3Qnk/3pzB
	yGqA==
MIME-Version: 1.0
X-Received: by 10.50.57.131 with SMTP id i3mr5889925igq.29.1361903647011; Tue,
	26 Feb 2013 10:34:07 -0800 (PST)
Received: by 10.43.47.202 with HTTP; Tue, 26 Feb 2013 10:34:06 -0800 (PST)
In-Reply-To: <CAFLBxZbRnBy5AFXw6_9mvRt+svA7j3f6hB2YqOQBL7z3LpV0rw@mail.gmail.com>
References: <4d2fb69d362be0cf33d9.1361780455@backup2.adv.ru>
	<CAFLBxZbRnBy5AFXw6_9mvRt+svA7j3f6hB2YqOQBL7z3LpV0rw@mail.gmail.com>
Date: Tue, 26 Feb 2013 22:34:06 +0400
Message-ID: <CA+O_+Ex6O=rnRkD8Li1id27CgAN6RnhB8E=NCMEYq9ZJzDZ48A@mail.gmail.com>
From: Igor Pavlikevich <ipavlikevich@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
X-Mailman-Approved-At: Wed, 27 Feb 2013 08:32:07 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] credit: fix race condition in csched_vcpu
	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: multipart/mixed; boundary="===============1190172331924257694=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1190172331924257694==
Content-Type: multipart/alternative; boundary=14dae9340fad193b7204d6a4e720

--14dae9340fad193b7204d6a4e720
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 6:19 PM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:

> On Mon, Feb 25, 2013 at 8:20 AM, Igor Pavlikevich <ipavlikevich@gmail.com>wrote:
>
>> When vcpu stops yielding, it's possible to overwrite
>> CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_YIELD.
>>
>>  332.970218393 -------x d1v1 runstate_continue d1v1 running->running
>> ]332.970248371 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>>  yielding, flags=0x0002
>> ]332.970251968 -------x d1v1
>> clearing 0x0002, flags=0
>>  332.970252175 -------x d1v1 runstate_continue d1v1 running->running
>> ]332.970282574 -------x d1v1   28005(2:8:5) 2 [ 1 1 ]
>>  yielding, flags=0x0002
>> ]332.970283068 x------| d32767v0
>> entering csched_acct(), d1v1 flags=0x0002
>> ]332.970285763 x------| d32767v0   28003(2:8:3) 2 [ 1 1 ]
>>  calling vcpu_pause_nosync() for d1v1
>> ]332.970286647 -------x d1v1
>> clearing 0x0002, flags=0
>> ]332.970286771 x------| d32767v0
>> flags |= CSCHED_FLAG_VCPU_PARKED, flags=0x0003
>> ]332.970286990 -------x d1v1   2800e(2:8:e) 2 [ 1 1cacfca ]
>> ]332.970287122 -------x d1v1   2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]
>> ]332.970287242 -------x d1v1   2800a(2:8:a) 4 [ 1 1 7fff 7 ]
>> exiting schedule(), flags=0
>>  332.970287417 -------x d1v1 runstate_change d1v1 running->offline
>>  332.970287629 -------x d?v? runstate_change d32767v7 runnable->running
>> ]332.970288397 x------- d32767v0
>> exiting csched_acct(), flags=0x0003
>> ]332.995349690 x------- d32767v0
>> entering csched_acct(), d1v1 flags=0x0000, flag lost.
>> ]332.995352170 x------- d32767v0   28003(2:8:3) 2 [ 1 1 ]
>>  calling vcpu_pause_nosync() for d1v1 again
>>
>> From this moment d1v1 has extra +1 in pause_count, so it goes offline
>> right after credit>prv->credits_per_tslice forever.
>>
>
> Good catch -- I guess we don't really test the scheduler "cap"
> functionality enough to catch this one.
>
> Unfortunately I think the real problem is that the ->flags field should be
> uniformly using the atomic bit operations.
>
> Can you try the attached patch and see if it works for you?
>
>
Thanks for help, your patch works well.

--14dae9340fad193b7204d6a4e720
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Feb 26, 2013 at 6:19 PM, George Dunlap <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:George.Dunlap@eu.citrix.com" target=3D"_blank">George.Dunlap@eu=
.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 dir=3D"ltr"><div class=3D"im">On Mon, F=
eb 25, 2013 at 8:20 AM, Igor Pavlikevich <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:ipavlikevich@gmail.com" target=3D"_blank">ipavlikevich@gmail.com</a>&=
gt;</span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"i=
m">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">When vcpu stops yielding, it&#39;s possible =
to overwrite CSCHED_FLAG_VCPU_PARKED flag after clearing CSCHED_FLAG_VCPU_Y=
IELD.<br>


<br>
=A0332.970218393 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970248371 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970251968 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
=A0332.970252175 -------x d1v1 runstate_continue d1v1 running-&gt;running<b=
r>
]332.970282574 -------x d1v1 =A0 28005(2:8:5) 2 [ 1 1 ] =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0yielding, flags=3D0x0002<br>
]332.970283068 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0002<br>
]332.970285763 x------| d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1<br>
]332.970286647 -------x d1v1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clearing 0x0002, flags=3D0<br>
]332.970286771 x------| d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags |=3D CSCHED_FLAG_VCPU_PARKED, fla=
gs=3D0x0003<br>
]332.970286990 -------x d1v1 =A0 2800e(2:8:e) 2 [ 1 1cacfca ]<br>
]332.970287122 -------x d1v1 =A0 2800f(2:8:f) 3 [ 7fff 1cacfca ffffffff ]<b=
r>
]332.970287242 -------x d1v1 =A0 2800a(2:8:a) 4 [ 1 1 7fff 7 ] =A0 =A0 =A0 =
=A0 =A0 exiting schedule(), flags=3D0<br>
=A0332.970287417 -------x d1v1 runstate_change d1v1 running-&gt;offline<br>
=A0332.970287629 -------x d?v? runstate_change d32767v7 runnable-&gt;runnin=
g<br>
]332.970288397 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exiting csched_acct(), flags=3D0x0003<b=
r>
]332.995349690 x------- d32767v0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entering csched_acct(), d1v1 flags=3D0x=
0000, flag lost.<br>
]332.995352170 x------- d32767v0 =A0 28003(2:8:3) 2 [ 1 1 ] =A0 =A0 =A0 =A0=
 =A0 =A0 =A0calling vcpu_pause_nosync() for d1v1 again<br>
<br>
>From this moment d1v1 has extra +1 in pause_count, so it goes offline right=
 after credit&gt;prv-&gt;credits_per_tslice forever.<br></blockquote><div><=
br></div></div><div>Good catch -- I guess we don&#39;t really test the sche=
duler &quot;cap&quot; functionality enough to catch this one.<br>

<br></div><div>Unfortunately I think the real problem is that the -&gt;flag=
s field should be uniformly using the atomic bit operations.<br><br>Can you=
 try the attached patch and see if it works for you?<span class=3D"HOEnZb">=
<font color=3D"#888888"><br>
<br></font></span></div></div></div></div></blockquote><div><br></div><div>=
Thanks for help, your patch works well. <br></div></div></div></div>

--14dae9340fad193b7204d6a4e720--


--===============1190172331924257694==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1190172331924257694==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 08:35:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08:35: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 1UAcUH-0001SE-1g; Wed, 27 Feb 2013 08:35:41 +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 1UAcUF-0001S7-NE
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 08:35:39 +0000
Received: from [85.158.139.211:23636] by server-12.bemta-5.messagelabs.com id
	96/21-11486-A55CD215; Wed, 27 Feb 2013 08:35:38 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361954135!18529467!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25760 invoked from network); 27 Feb 2013 08:35:38 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 08:35:38 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1UAcU8-0001uF-1C
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 19:35:32 +1100
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 id
	14.01.0438.000; Wed, 27 Feb 2013 19:35:31 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: constructing packets for testing
Thread-Index: Ac4UxS0vfqeM/m90TCSKC30GKItr0Q==
Date: Wed, 27 Feb 2013 08:35:30 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3573176D@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19672.001
x-tm-as-result: No--36.746600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] constructing packets for 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

Someone has reported a problem with GPLPV that I can't replicate, most likely because the layout on the ring is different resulting in a different set of buffers passed to windows. I can replay a tcpdump capture, but that doesn't end up amounting to the same thing.

Is there a tool around to do this or would I need to write my own?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:35:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08:35: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 1UAcUH-0001SE-1g; Wed, 27 Feb 2013 08:35:41 +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 1UAcUF-0001S7-NE
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 08:35:39 +0000
Received: from [85.158.139.211:23636] by server-12.bemta-5.messagelabs.com id
	96/21-11486-A55CD215; Wed, 27 Feb 2013 08:35:38 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361954135!18529467!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25760 invoked from network); 27 Feb 2013 08:35:38 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 08:35:38 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1UAcU8-0001uF-1C
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 19:35:32 +1100
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 id
	14.01.0438.000; Wed, 27 Feb 2013 19:35:31 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: constructing packets for testing
Thread-Index: Ac4UxS0vfqeM/m90TCSKC30GKItr0Q==
Date: Wed, 27 Feb 2013 08:35:30 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B3573176D@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19672.001
x-tm-as-result: No--36.746600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] constructing packets for 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

Someone has reported a problem with GPLPV that I can't replicate, most likely because the layout on the ring is different resulting in a different set of buffers passed to windows. I can replay a tcpdump capture, but that doesn't end up amounting to the same thing.

Is there a tool around to do this or would I need to write my own?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:36:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08:36: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 1UAcUT-0001TQ-Pn; Wed, 27 Feb 2013 08:35:53 +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 1UAcUR-0001T8-Py
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 08:35:51 +0000
Received: from [85.158.139.211:28388] by server-11.bemta-5.messagelabs.com id
	4F/98-27486-765CD215; Wed, 27 Feb 2013 08:35:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1361954149!19341631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5974 invoked from network); 27 Feb 2013 08:35:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 08:35:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 08:35:49 +0000
Message-Id: <512DD37102000078000C1569@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 08:35:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
	<20130226220100.GA22418@phenom.dumpdata.com>
In-Reply-To: <20130226220100.GA22418@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 23:01, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The thing is is that native_machine_emergency_restart is not suppose
> to be called. The baremetal machine_ops has that, but we over-write
> it with our own and he should get:
> 
>          .emergency_restart = xen_emergency_restart,
> 
> ! So how did his .emergency_restart value get over-written by
> native_machine_emergency_restart?

Indeed. So perhaps the -hardened tag indicates some patching
having gone on that we're unaware of. Michal - without knowing
what your kernel does, I don't think we can really help. And
please remember that this is xen-devel, not xen-users, so we
expect you to be able to do at least a minimal share of the work
needed to find out what is going on. First step would probably
be to try plain 3.7.5 (or subsequent 3.7.x).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:36:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08:36: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 1UAcUT-0001TQ-Pn; Wed, 27 Feb 2013 08:35:53 +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 1UAcUR-0001T8-Py
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 08:35:51 +0000
Received: from [85.158.139.211:28388] by server-11.bemta-5.messagelabs.com id
	4F/98-27486-765CD215; Wed, 27 Feb 2013 08:35:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1361954149!19341631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5974 invoked from network); 27 Feb 2013 08:35:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 08:35:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 08:35:49 +0000
Message-Id: <512DD37102000078000C1569@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 08:35:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Michal Fiala" <fiala@mfiala.net>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
	<20130226220100.GA22418@phenom.dumpdata.com>
In-Reply-To: <20130226220100.GA22418@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 23:01, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The thing is is that native_machine_emergency_restart is not suppose
> to be called. The baremetal machine_ops has that, but we over-write
> it with our own and he should get:
> 
>          .emergency_restart = xen_emergency_restart,
> 
> ! So how did his .emergency_restart value get over-written by
> native_machine_emergency_restart?

Indeed. So perhaps the -hardened tag indicates some patching
having gone on that we're unaware of. Michal - without knowing
what your kernel does, I don't think we can really help. And
please remember that this is xen-devel, not xen-users, so we
expect you to be able to do at least a minimal share of the work
needed to find out what is going on. First step would probably
be to try plain 3.7.5 (or subsequent 3.7.x).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:37:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08: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 1UAcVP-0001bi-AV; Wed, 27 Feb 2013 08:36:51 +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 1UAcVO-0001bN-3Z
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 08:36:50 +0000
Received: from [85.158.139.211:48790] by server-16.bemta-5.messagelabs.com id
	35/EA-02543-1A5CD215; Wed, 27 Feb 2013 08:36:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361954208!19397601!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9419 invoked from network); 27 Feb 2013 08:36:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 08:36:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 08:36:47 +0000
Message-Id: <512DD3AD02000078000C156C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 08:36:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <zhenzhong.duan@oracle.com>
References: <512C78D2.8030903@oracle.com>
	<512C979E02000078000C105F@nat28.tlf.novell.com>
	<512D9E86.1080907@oracle.com>
In-Reply-To: <512D9E86.1080907@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix 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

>>> On 27.02.13 at 06:49, Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:

> On 2013-02-26 18:08, Jan Beulich wrote:
>>>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>> (fee00000 -> fee02000)
>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>> (00004059 -> 00004071)
>> If you look at the code issuing this message, the situation is
>> pretty clear (and I think it as described already in the past,
>> albeit I have no link at hand): qemu lacks proper emulation of
>> the mask bit. pci_msix_write() looks at the physical one, yet
>> when the guest sets the virtual mask bit, nothing is being
>> done at all to make the hypervisor also mask the physical
>> entry:
>>
>>      if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
>>          if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>>              xen_pt_msix_update_one(s, entry_nr);
>>          }
>>      }
>>
>> There's probably quite a bit of code to be written to make this
>> work.
> Is there plan of fixing it?

I'm not aware of anyone working on this, or having planned to.
Want to take a shot?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:37:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08: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 1UAcVP-0001bi-AV; Wed, 27 Feb 2013 08:36:51 +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 1UAcVO-0001bN-3Z
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 08:36:50 +0000
Received: from [85.158.139.211:48790] by server-16.bemta-5.messagelabs.com id
	35/EA-02543-1A5CD215; Wed, 27 Feb 2013 08:36:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361954208!19397601!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9419 invoked from network); 27 Feb 2013 08:36:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 08:36:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 08:36:47 +0000
Message-Id: <512DD3AD02000078000C156C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 08:36:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <zhenzhong.duan@oracle.com>
References: <512C78D2.8030903@oracle.com>
	<512C979E02000078000C105F@nat28.tlf.novell.com>
	<512D9E86.1080907@oracle.com>
In-Reply-To: <512D9E86.1080907@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix 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

>>> On 27.02.13 at 06:49, Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:

> On 2013-02-26 18:08, Jan Beulich wrote:
>>>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>> (fee00000 -> fee02000)
>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>> (00004059 -> 00004071)
>> If you look at the code issuing this message, the situation is
>> pretty clear (and I think it as described already in the past,
>> albeit I have no link at hand): qemu lacks proper emulation of
>> the mask bit. pci_msix_write() looks at the physical one, yet
>> when the guest sets the virtual mask bit, nothing is being
>> done at all to make the hypervisor also mask the physical
>> entry:
>>
>>      if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
>>          if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>>              xen_pt_msix_update_one(s, entry_nr);
>>          }
>>      }
>>
>> There's probably quite a bit of code to be written to make this
>> work.
> Is there plan of fixing it?

I'm not aware of anyone working on this, or having planned to.
Want to take a shot?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:51:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08: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 1UAcix-00021E-P0; Wed, 27 Feb 2013 08:50:51 +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 1UAciv-000219-QS
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 08:50:49 +0000
Received: from [85.158.139.83:65211] by server-12.bemta-5.messagelabs.com id
	3A/DE-11486-9E8CD215; Wed, 27 Feb 2013 08:50:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361955038!21827845!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12250 invoked from network); 27 Feb 2013 08:50:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 08:50:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 08:50:37 +0000
Message-Id: <512DD6EB02000078000C159C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 08:50:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>,"Tim(Xen.org)" <tim@xen.org>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
In-Reply-To: <20780.60434.402629.740920@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xi Wang <xi@mit.edu>, xen-devel@lists.xen.org
Subject: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86: fix
 null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in 
> intel_get_extended_msrs()"):
>> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
>> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.
> 
> Really I think we shouldn't be writing out these kind of memsets.
> They're too error-prone.  We should have a macro, perhaps like this:
> 
>   #define FILLZERO(object) memset(&(object), 0, sizeof(object))
> 
> Likewise a copy macro.

Unfortunately that wouldn't be usable in all cases (arrays passed
to functions), and hence I'm not really confident this would be a
good move. But yes, I considered what you suggest a number of
times already, but dropped the idea each time because of its lack
of general applicability.

I'm afraid we just have to live with the bad side effects of the
power C provides.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 08:51:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 08: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 1UAcix-00021E-P0; Wed, 27 Feb 2013 08:50:51 +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 1UAciv-000219-QS
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 08:50:49 +0000
Received: from [85.158.139.83:65211] by server-12.bemta-5.messagelabs.com id
	3A/DE-11486-9E8CD215; Wed, 27 Feb 2013 08:50:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361955038!21827845!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12250 invoked from network); 27 Feb 2013 08:50:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 08:50:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 08:50:37 +0000
Message-Id: <512DD6EB02000078000C159C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 08:50:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>,"Tim(Xen.org)" <tim@xen.org>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
In-Reply-To: <20780.60434.402629.740920@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xi Wang <xi@mit.edu>, xen-devel@lists.xen.org
Subject: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86: fix
 null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in 
> intel_get_extended_msrs()"):
>> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
>> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.
> 
> Really I think we shouldn't be writing out these kind of memsets.
> They're too error-prone.  We should have a macro, perhaps like this:
> 
>   #define FILLZERO(object) memset(&(object), 0, sizeof(object))
> 
> Likewise a copy macro.

Unfortunately that wouldn't be usable in all cases (arrays passed
to functions), and hence I'm not really confident this would be a
good move. But yes, I considered what you suggest a number of
times already, but dropped the idea each time because of its lack
of general applicability.

I'm afraid we just have to live with the bad side effects of the
power C provides.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:13:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:13: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 1UAd49-0002jj-QE; Wed, 27 Feb 2013 09:12:45 +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 1UAd48-0002jc-CV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:12:44 +0000
Received: from [85.158.137.99:52524] by server-13.bemta-3.messagelabs.com id
	90/90-25744-B0ECD215; Wed, 27 Feb 2013 09:12:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361956358!13194154!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28870 invoked from network); 27 Feb 2013 09:12:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:12:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:12:38 +0000
Message-Id: <512DDC1402000078000C15B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:12:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<512DA58C.4060604@ts.fujitsu.com> <512DA77B.90001@ts.fujitsu.com>
In-Reply-To: <512DA77B.90001@ts.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI3LjAyLjEzIGF0IDA3OjI4LCBKdWVyZ2VuIEdyb3NzIDxqdWVyZ2VuLmdyb3NzQHRz
LmZ1aml0c3UuY29tPiB3cm90ZToKPiBPbiAyNy4wMi4yMDEzIDA3OjE5LCBKdWVyZ2VuIEdyb3Nz
IHdyb3RlOgo+PiBPbiAxOS4wMi4yMDEzIDEwOjI4LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+
IE9uIDE4LjAyLjEzIGF0IDE5OjExLCBBbmRyZXcgQ29vcGVyPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+IHdyb3RlOgo+Pj4+IEhlbGxvLAo+Pj4+Cj4+Pj4gT3VyIHRlc3RpbmcgaGFzIGRpc2Nv
dmVyZWQgYSBjcmFzaCAocGFnZWZhdWx0IGF0IDB4MDAwMDAwMDAwMDAwMDAwOCkKPj4+PiB3aGlj
aCBJIGhhdmUgdHJhY2tlZCBkb3duIHRvIGJhZCBfX3J1bnFfcmVtb3ZlKCkgaW4gY3NjaGVkX3Zj
cHVfc2xlZXAoKQo+Pj4+IGluIHNjaGVkX2NyZWRpdC5jIChiZWNhdXNlIGEgc3RhdGljIGZ1bmN0
aW9uIG9mIHRoZSBzYW1lIG5hbWUgYWxzbwo+Pj4+IGV4aXN0cyBpbiBzY2hlZF9jcmVkaXQyLmMs
IHdoaWNoIGNvbmZ1c2VkIG1hdHRlcnMgdG8gc3RhcnQgd2l0aCkKPj4+Pgo+Pj4+IFRoZSB0ZXN0
IGNhc2Ugd2FzIGEgbG9vcCBvZiBsb2NhbGhvc3QgbWlncmF0ZSBvZiBhIDF2Y3B1IEhWTSB3aW44
Cj4+Pj4gZG9tYWluLiBUaGUgdGVzdCBjYXNlIGl0c2VsZiBoYXMgcGFzc2VkIG1hbnkgdGltZXMg
aW4gdGhlIHBhc3Qgb24gdGhlCj4+Pj4gc2FtZSBYZW4gY29kZWJhc2UgKFhlbi00LjEuMyksIGlu
ZGljYXRpbmcgdGhhdCBpdCBpcyB2ZXJ5IHJhcmUuIFRoZXJlCj4+Pj4gZG9lcyBub3QgYXBwZWFy
IHRvIGJlIGFueSByZWxldmFudCBjaGFuZ2VzIGJldHdlZW4gdGhlIHZlcnNpb24gb2YgWGVuIGlu
Cj4+Pj4gdGhlIHRlc3QgYW5kIHhlbi00LjEtdGVzdGluZy4KPj4+Pgo+Pj4+IFRoZSBmYWlsdXJl
IGl0c2VsZiBpcyBiZWNhdXNlIG9mIGEgWEVOX0RPTUNUTF9zY2hlZHVsZXJfb3AgKHRyYWNlIGJl
bG93KQo+Pj4+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBWQ1BVIG9mIHRoZSBtaWdyYXRpbmcg
ZG9tYWluLgo+Pj4+Cj4+Pj4gKFhFTikgWGVuIGNhbGwgdHJhY2U6Cj4+Pj4gKFhFTikgWzxmZmZm
ODJjNDgwMTE2YTE0Pl0gY3NjaGVkX3ZjcHVfc2xlZXArMHg0NC8weDcwCj4+Pj4gKFhFTikgMFs8
ZmZmZjgyYzQ4MDEyMDExNz5dIHZjcHVfc2xlZXBfbm9zeW5jKzB4ZTcvMHgzYjAKPj4+PiAoWEVO
KSAxMls8ZmZmZjgyYzQ4MDEyMDNlOT5dIHZjcHVfc2xlZXBfc3luYysweDkvMHg1MAo+Pj4+IChY
RU4pIDE0WzxmZmZmODJjNDgwMTFmZDRjPl0gc2NoZWRfYWRqdXN0KzB4YWMvMHgyMzAKPj4+PiAo
WEVOKSAyNFs8ZmZmZjgyYzQ4MDEwMmJjMT5dIGRvX2RvbWN0bCsweDczMS8weDExMzAKPj4+PiAo
WEVOKSA2NFs8ZmZmZjgyYzQ4MDIwMTNjND5dIGNvbXBhdF9oeXBlcmNhbGwrMHg3NC8weDgwCj4+
Pj4KPj4+PiBUaGUgcmVsZXZhbnQgcGFydCBvZiBjc2NoZWRfdmNwdV9zbGVlcCgpIGlzCj4+Pj4K
Pj4+PiBlbHNlIGlmICggX192Y3B1X29uX3J1bnEoc3ZjKSApCj4+Pj4gX19ydW5xX3JlbW92ZShz
dmMpOwo+Pj4+Cj4+Pj4gd2hpY2ggZGlzYXNzZW1ibGVzIHRvCj4+Pj4KPj4+PiBmZmZmODJjNDgw
MTE2YTAxOiA0OSA4YiAxMCBtb3YgKCVyOCksJXJkeAo+Pj4+IGZmZmY4MmM0ODAxMTZhMDQ6IDRj
IDM5IGMyIGNtcCAlcjgsJXJkeAo+Pj4+IGZmZmY4MmM0ODAxMTZhMDc6IDc1IDA3IGpuZSBmZmZm
ODJjNDgwMTE2YTEwCj4+Pj4gPGNzY2hlZF92Y3B1X3NsZWVwKzB4NDA+Cj4+Pj4gZmZmZjgyYzQ4
MDExNmEwOTogZjMgYzMgcmVweiByZXRxCj4+Pj4gZmZmZjgyYzQ4MDExNmEwYjogMGYgMWYgNDQg
MDAgMDAgbm9wbCAweDAoJXJheCwlcmF4LDEpCj4+Pj4gZmZmZjgyYzQ4MDExNmExMDogNDkgOGIg
NDAgMDggbW92IDB4OCglcjgpLCVyYXgKPj4+PiBmZmZmODJjNDgwMTE2YTE0OiA0OCA4OSA0MiAw
OCBtb3YgJXJheCwweDgoJXJkeCkgIwo+Pj4+IDwtIFBhZ2VmYXVsdCBoZXJlCj4+Pj4gZmZmZjgy
YzQ4MDExNmExODogNDggODkgMTAgbW92ICVyZHgsKCVyYXgpCj4+Pj4gZmZmZjgyYzQ4MDExNmEx
YjogNGQgODkgNDAgMDggbW92ICVyOCwweDgoJXI4KQo+Pj4+IGZmZmY4MmM0ODAxMTZhMWY6IDRk
IDg5IDAwIG1vdiAlcjgsKCVyOCkKPj4+Pgo+Pj4+IFRoZSByZWxldmFudCBjcmFzaCByZWdpc3Rl
cnMgZnJvbSB0aGUgcGFnZWZhdWx0IGFyZToKPj4+PiByYXg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+
PiByZHg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+PiByODogZmZmZjgzMDgwYzg5ZWQ5MAo+Pj4+Cj4+
Pj4gSWYgSSBhbSByZWFkaW5nIHRoZSBjb2RlIGNvcnJlY3RseSwgdGhpcyBtZWFucyB0aGF0IHJ1
bnEtPm5leHQgaXMgTlVMTCwKPj4+PiBzbyB3ZSBmYWlsIGxpc3RfZW1wdHkoKSBhbmQgZXJyb25l
b3VzbHkgcGFzcyBfX3ZjcHVfb25fcnVucSgpLiBXZSB0aGVuCj4+Pj4gZmFpbCB3aXRoIGEgZmF1
bHQgd2hlbiB0cnlpbmcgdG8gdXBkYXRlIHJ1bnEtPnByZXYsIHdoaWNoIGlzIGFsc28gTlVMTC4K
Pj4+Pgo+Pj4+IFRoZSBvbmx5IHBsYWNlIEkgY2FuIHNwb3QgaW4gdGhlIGNvZGUgd2hlcmUgdGhl
IHJ1bnEtPntuZXh0LHByZXZ9IGNvdWxkCj4+Pj4gY29uY2VpdmFibHkgYmUgTlVMTCBpcyBpbiBj
c2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBtZW1zZXQoKSBhbmQKPj4+PiBJTklUX0xJ
U1RfSEVBRCgpLiBUaGlzIGlzIGxvZ2ljYWxseSBzZW5zaWJsZSBpbiBjb21iaW5hdGlvbiB3aXRo
IHRoZQo+Pj4+IGxvY2FsaG9zdCBtaWdyYXRlIGxvb3AsIGFuZCBJIGNhbnQgaW1tZWRpYXRlbHkg
c2VlIGFueXRoaW5nIHRvIHByZXZlbnQKPj4+PiB0aGlzIHJhY2UgaGFwcGVuaW5nLgo+Pj4KPj4+
IEJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVkX2FsbG9jX3ZkYXRhKCkgZG9lc24n
dCBzdG9yZQo+Pj4gc3ZjIGludG8gdmMtPnNjaGVkX3ByaXY7IHRoYXQncyBiZWluZyBkb25lIGJ5
IHRoZSBnZW5lcmljCj4+PiBzY2hlZHVsZXIgY29kZSBvbmNlIHRoZSBhY3RvciByZXR1cm5zLgo+
Pj4KPj4+IFNvIEknZCByYXRoZXIgc3VzcGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwg
d2hpY2ggaXMgZWFzaWx5Cj4+PiBwb3NzaWJsZSB3aGVuIHJhY2luZyB3aXRoIHNjaGVkX21vdmVf
ZG9tYWluKCkgKGFzIG9wcG9zZWQgdG8KPj4+IHNjaGVkdWxlX2NwdV9zd2l0Y2goKSwgd2hlcmUg
dGhlIG5ldyBwb2ludGVyIGdldHMgc3RvcmVkCj4+PiBfYmVmb3JlXyBkZS1hbGxvY2F0aW5nIHRo
ZSBvbGQgb25lKS4KPj4+Cj4+PiBIb3dldmVyLCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyB3ZWxs
IGFzIHNjaGVkdWxlX2NwdV9zd2l0Y2goKSkKPj4+IGdldCBjYWxsZWQgb25seSBmcm9tIENQVSBw
b29scyBjb2RlLCBhbmQgSSB3b3VsZCBndWVzcyBDUFUgcG9vbHMKPj4+IGFyZW4ndCBpbnZvbHZl
ZCBoZXJlLCBhbmQgeW91IGRvbid0IGluIHBhcmFsbGVsIHNvZnQgb2ZmbGluZS9vbmxpbmUKPj4+
IHBDUFUtcyAoYXMgSSdtIHN1cmUgeW91IG90aGVyd2lzZSB3b3VsZCBoYXZlIG1lbnRpb25lZCBp
dCkuCj4+Pgo+Pj4gQnV0IHdhaXQgLSBsaWJ4bF9fZG9tYWluX21ha2UoKSBfdW5jb25kaXRpb25h
bGx5XyBjYWxscwo+Pj4geGNfY3B1cG9vbF9tb3ZlZG9tYWluKCksIGFzIGRvZXMgWGVuZERvbWFp
bkluZm8ncwo+Pj4gX2NvbnN0cnVjdERvbWFpbigpLiBUaGUgcmVhc29uIGZvciB0aGlzIGVzY2Fw
ZXMgbWUgLSBKw7xyZ2VuPyBZZXQKPj4+IEknZCBleHBlY3QgdGhlIHBvb2wgSUQgbWF0Y2hpbmcg
Y2hlY2sgdG8gc2hvcnQgY3V0IHRoZSByZXN1bHRpbmcKPj4+IHN5c2N0bCwgaS5lLiBzY2hlZF9t
b3ZlX2RvbWFpbigpIG91Z2h0IHRvIG5vdCBiZSByZWFjaGVkIGFueXdheQo+Pj4gKHdvcnRoIHZl
cmlmeWluZyBvZiBjb3Vyc2UpLgo+Pj4KPj4+IFRoZSByYWNlIHRoZXJlIG5ldmVydGhlbGVzcyBv
dWdodCB0byBiZSBmaXhlZC4KPj4KPj4gU29tZXRoaW5nIGxpa2UgdGhlIGF0dGFjaGVkIHBhdGNo
Pwo+Pgo+PiBOb3QgdGVzdGVkIHRob3JvdWdobHkgeWV0Lgo+IAo+IEFyZ2guIFNlbnQgYW4gb2xk
IHZlcnNpb24sIHNvcnJ5LiBUaGlzIG9uZSBzaG91bGQgYmUgYmV0dGVyLgoKU29ydCBvZi4gSSB3
YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBieSBzdG9yaW5nIGp1c3QgYSBzaW5nbGUKIm9s
ZCIgcG9pbnRlciB0ZW1wb3JhcmlseSBpbnNpZGUgdGhlIGxhc3QgbG9vcCBhbmQgbW92aW5nIHRo
ZQpmcmVlX3ZkYXRhIGludm9jYXRpb24gdG8gdGhlIGVuZCBvZiB0aGlzIHNhbWUgbGFzdCBsb29w
IHdvdWxkCmVxdWFsbHkgd2VsbCB0YWtlIGNhcmUgb2YgaXQsIHdpdGhvdXQgaW5jcmVhc2luZyBz
dG9yYWdlCnJlcXVpcmVtZW50cyAoYW5kIGhlbmNlIGFsc28gaW5jcmVhc2luZyB0aGUgcmlzayBv
ZiBmYWlsdXJlKSwKYW5kIHdpdGhvdXQgeWV0IGFub3RoZXIgZm9yX2VhY2hfdmNwdSgpIGxvb3Au
CgpPciwgaWYgZ29pbmcgeW91ciByb3V0ZSwgeW91IHdvdWxkIHdhbnQgdG8gbW92ZSB0aGUgZmlu
YWwgZnJlZWluZwpvcGVyYXRpb25zIHBhc3QgdGhlIGRvbWFpbl91bnBhdXNlKCkgSSB0aGluayAo
d2hpY2ggY291bGQgYmUKZG9uZSBldmVuIHdpdGggdGhlIGFwcHJvYWNoIHN1Z2dlc3RlZCBhYm92
ZSwgYnkgcHV0dGluZyB0aGUKdG8tYmUtZnJlZWQgcG9pbnRlciBiYWNrIGludG8gdGhlIHNhbWUg
dmNwdV9wcml2W10gc2xvdCkuCgpBbmQgdGhlbiwgaWYgeW91IGFscmVhZHkgaGF2ZSB0byBjYWNo
ZSBET00yT1AoKSBpbiBhIGxvY2FsCnZhcmlhYmxlLCB5b3Ugc2hvdWxkIG9mIGNvdXJzZSBjb252
ZXJ0IHRoZSByZW1haW5pbmcgdXNlIG9mClZDUFUyT1AoKSB0byB1c2UgdGhlIGNhY2hlZCBjb3B5
ICh0aGUgdHdvIHVzZXMgb2YgdGhlIGxhdHRlcgp3ZXJlIGJvZ3VzIGFueXdheSwgYXMgdGhlIHNp
bXBsZXIgRE9NMk9QKCkgd291bGQgaGF2ZQpkb25lOyBzaW1pbGFybHkgaW4gc2NoZWRfaW5pdF92
Y3B1KCkpLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:13:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:13: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 1UAd49-0002jj-QE; Wed, 27 Feb 2013 09:12:45 +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 1UAd48-0002jc-CV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:12:44 +0000
Received: from [85.158.137.99:52524] by server-13.bemta-3.messagelabs.com id
	90/90-25744-B0ECD215; Wed, 27 Feb 2013 09:12:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361956358!13194154!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyMTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28870 invoked from network); 27 Feb 2013 09:12:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:12:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:12:38 +0000
Message-Id: <512DDC1402000078000C15B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:12:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <51226EBB.3030503@citrix.com>
	<512353E502000078000BF521@nat28.tlf.novell.com>
	<512DA58C.4060604@ts.fujitsu.com> <512DA77B.90001@ts.fujitsu.com>
In-Reply-To: <512DA77B.90001@ts.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Race condition with scheduler runqueues
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI3LjAyLjEzIGF0IDA3OjI4LCBKdWVyZ2VuIEdyb3NzIDxqdWVyZ2VuLmdyb3NzQHRz
LmZ1aml0c3UuY29tPiB3cm90ZToKPiBPbiAyNy4wMi4yMDEzIDA3OjE5LCBKdWVyZ2VuIEdyb3Nz
IHdyb3RlOgo+PiBPbiAxOS4wMi4yMDEzIDEwOjI4LCBKYW4gQmV1bGljaCB3cm90ZToKPj4+Pj4+
IE9uIDE4LjAyLjEzIGF0IDE5OjExLCBBbmRyZXcgQ29vcGVyPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+IHdyb3RlOgo+Pj4+IEhlbGxvLAo+Pj4+Cj4+Pj4gT3VyIHRlc3RpbmcgaGFzIGRpc2Nv
dmVyZWQgYSBjcmFzaCAocGFnZWZhdWx0IGF0IDB4MDAwMDAwMDAwMDAwMDAwOCkKPj4+PiB3aGlj
aCBJIGhhdmUgdHJhY2tlZCBkb3duIHRvIGJhZCBfX3J1bnFfcmVtb3ZlKCkgaW4gY3NjaGVkX3Zj
cHVfc2xlZXAoKQo+Pj4+IGluIHNjaGVkX2NyZWRpdC5jIChiZWNhdXNlIGEgc3RhdGljIGZ1bmN0
aW9uIG9mIHRoZSBzYW1lIG5hbWUgYWxzbwo+Pj4+IGV4aXN0cyBpbiBzY2hlZF9jcmVkaXQyLmMs
IHdoaWNoIGNvbmZ1c2VkIG1hdHRlcnMgdG8gc3RhcnQgd2l0aCkKPj4+Pgo+Pj4+IFRoZSB0ZXN0
IGNhc2Ugd2FzIGEgbG9vcCBvZiBsb2NhbGhvc3QgbWlncmF0ZSBvZiBhIDF2Y3B1IEhWTSB3aW44
Cj4+Pj4gZG9tYWluLiBUaGUgdGVzdCBjYXNlIGl0c2VsZiBoYXMgcGFzc2VkIG1hbnkgdGltZXMg
aW4gdGhlIHBhc3Qgb24gdGhlCj4+Pj4gc2FtZSBYZW4gY29kZWJhc2UgKFhlbi00LjEuMyksIGlu
ZGljYXRpbmcgdGhhdCBpdCBpcyB2ZXJ5IHJhcmUuIFRoZXJlCj4+Pj4gZG9lcyBub3QgYXBwZWFy
IHRvIGJlIGFueSByZWxldmFudCBjaGFuZ2VzIGJldHdlZW4gdGhlIHZlcnNpb24gb2YgWGVuIGlu
Cj4+Pj4gdGhlIHRlc3QgYW5kIHhlbi00LjEtdGVzdGluZy4KPj4+Pgo+Pj4+IFRoZSBmYWlsdXJl
IGl0c2VsZiBpcyBiZWNhdXNlIG9mIGEgWEVOX0RPTUNUTF9zY2hlZHVsZXJfb3AgKHRyYWNlIGJl
bG93KQo+Pj4+IGZyb20gZG9tMCwgdGFyZ2V0aW5nIHRoZSBWQ1BVIG9mIHRoZSBtaWdyYXRpbmcg
ZG9tYWluLgo+Pj4+Cj4+Pj4gKFhFTikgWGVuIGNhbGwgdHJhY2U6Cj4+Pj4gKFhFTikgWzxmZmZm
ODJjNDgwMTE2YTE0Pl0gY3NjaGVkX3ZjcHVfc2xlZXArMHg0NC8weDcwCj4+Pj4gKFhFTikgMFs8
ZmZmZjgyYzQ4MDEyMDExNz5dIHZjcHVfc2xlZXBfbm9zeW5jKzB4ZTcvMHgzYjAKPj4+PiAoWEVO
KSAxMls8ZmZmZjgyYzQ4MDEyMDNlOT5dIHZjcHVfc2xlZXBfc3luYysweDkvMHg1MAo+Pj4+IChY
RU4pIDE0WzxmZmZmODJjNDgwMTFmZDRjPl0gc2NoZWRfYWRqdXN0KzB4YWMvMHgyMzAKPj4+PiAo
WEVOKSAyNFs8ZmZmZjgyYzQ4MDEwMmJjMT5dIGRvX2RvbWN0bCsweDczMS8weDExMzAKPj4+PiAo
WEVOKSA2NFs8ZmZmZjgyYzQ4MDIwMTNjND5dIGNvbXBhdF9oeXBlcmNhbGwrMHg3NC8weDgwCj4+
Pj4KPj4+PiBUaGUgcmVsZXZhbnQgcGFydCBvZiBjc2NoZWRfdmNwdV9zbGVlcCgpIGlzCj4+Pj4K
Pj4+PiBlbHNlIGlmICggX192Y3B1X29uX3J1bnEoc3ZjKSApCj4+Pj4gX19ydW5xX3JlbW92ZShz
dmMpOwo+Pj4+Cj4+Pj4gd2hpY2ggZGlzYXNzZW1ibGVzIHRvCj4+Pj4KPj4+PiBmZmZmODJjNDgw
MTE2YTAxOiA0OSA4YiAxMCBtb3YgKCVyOCksJXJkeAo+Pj4+IGZmZmY4MmM0ODAxMTZhMDQ6IDRj
IDM5IGMyIGNtcCAlcjgsJXJkeAo+Pj4+IGZmZmY4MmM0ODAxMTZhMDc6IDc1IDA3IGpuZSBmZmZm
ODJjNDgwMTE2YTEwCj4+Pj4gPGNzY2hlZF92Y3B1X3NsZWVwKzB4NDA+Cj4+Pj4gZmZmZjgyYzQ4
MDExNmEwOTogZjMgYzMgcmVweiByZXRxCj4+Pj4gZmZmZjgyYzQ4MDExNmEwYjogMGYgMWYgNDQg
MDAgMDAgbm9wbCAweDAoJXJheCwlcmF4LDEpCj4+Pj4gZmZmZjgyYzQ4MDExNmExMDogNDkgOGIg
NDAgMDggbW92IDB4OCglcjgpLCVyYXgKPj4+PiBmZmZmODJjNDgwMTE2YTE0OiA0OCA4OSA0MiAw
OCBtb3YgJXJheCwweDgoJXJkeCkgIwo+Pj4+IDwtIFBhZ2VmYXVsdCBoZXJlCj4+Pj4gZmZmZjgy
YzQ4MDExNmExODogNDggODkgMTAgbW92ICVyZHgsKCVyYXgpCj4+Pj4gZmZmZjgyYzQ4MDExNmEx
YjogNGQgODkgNDAgMDggbW92ICVyOCwweDgoJXI4KQo+Pj4+IGZmZmY4MmM0ODAxMTZhMWY6IDRk
IDg5IDAwIG1vdiAlcjgsKCVyOCkKPj4+Pgo+Pj4+IFRoZSByZWxldmFudCBjcmFzaCByZWdpc3Rl
cnMgZnJvbSB0aGUgcGFnZWZhdWx0IGFyZToKPj4+PiByYXg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+
PiByZHg6IDAwMDAwMDAwMDAwMDAwMDAKPj4+PiByODogZmZmZjgzMDgwYzg5ZWQ5MAo+Pj4+Cj4+
Pj4gSWYgSSBhbSByZWFkaW5nIHRoZSBjb2RlIGNvcnJlY3RseSwgdGhpcyBtZWFucyB0aGF0IHJ1
bnEtPm5leHQgaXMgTlVMTCwKPj4+PiBzbyB3ZSBmYWlsIGxpc3RfZW1wdHkoKSBhbmQgZXJyb25l
b3VzbHkgcGFzcyBfX3ZjcHVfb25fcnVucSgpLiBXZSB0aGVuCj4+Pj4gZmFpbCB3aXRoIGEgZmF1
bHQgd2hlbiB0cnlpbmcgdG8gdXBkYXRlIHJ1bnEtPnByZXYsIHdoaWNoIGlzIGFsc28gTlVMTC4K
Pj4+Pgo+Pj4+IFRoZSBvbmx5IHBsYWNlIEkgY2FuIHNwb3QgaW4gdGhlIGNvZGUgd2hlcmUgdGhl
IHJ1bnEtPntuZXh0LHByZXZ9IGNvdWxkCj4+Pj4gY29uY2VpdmFibHkgYmUgTlVMTCBpcyBpbiBj
c2NoZWRfYWxsb2NfdmRhdGEoKSBiZXR3ZWVuIHRoZSBtZW1zZXQoKSBhbmQKPj4+PiBJTklUX0xJ
U1RfSEVBRCgpLiBUaGlzIGlzIGxvZ2ljYWxseSBzZW5zaWJsZSBpbiBjb21iaW5hdGlvbiB3aXRo
IHRoZQo+Pj4+IGxvY2FsaG9zdCBtaWdyYXRlIGxvb3AsIGFuZCBJIGNhbnQgaW1tZWRpYXRlbHkg
c2VlIGFueXRoaW5nIHRvIHByZXZlbnQKPj4+PiB0aGlzIHJhY2UgaGFwcGVuaW5nLgo+Pj4KPj4+
IEJ1dCB0aGF0IGRvZXNuJ3QgbWFrZSBzZW5zZTogY3NjaGVkX2FsbG9jX3ZkYXRhKCkgZG9lc24n
dCBzdG9yZQo+Pj4gc3ZjIGludG8gdmMtPnNjaGVkX3ByaXY7IHRoYXQncyBiZWluZyBkb25lIGJ5
IHRoZSBnZW5lcmljCj4+PiBzY2hlZHVsZXIgY29kZSBvbmNlIHRoZSBhY3RvciByZXR1cm5zLgo+
Pj4KPj4+IFNvIEknZCByYXRoZXIgc3VzcGVjdCBhIHN0YWxlIHBvaW50ZXIgYmVpbmcgdXNlZCwg
d2hpY2ggaXMgZWFzaWx5Cj4+PiBwb3NzaWJsZSB3aGVuIHJhY2luZyB3aXRoIHNjaGVkX21vdmVf
ZG9tYWluKCkgKGFzIG9wcG9zZWQgdG8KPj4+IHNjaGVkdWxlX2NwdV9zd2l0Y2goKSwgd2hlcmUg
dGhlIG5ldyBwb2ludGVyIGdldHMgc3RvcmVkCj4+PiBfYmVmb3JlXyBkZS1hbGxvY2F0aW5nIHRo
ZSBvbGQgb25lKS4KPj4+Cj4+PiBIb3dldmVyLCBzY2hlZF9tb3ZlX2RvbWFpbigpIChhcyB3ZWxs
IGFzIHNjaGVkdWxlX2NwdV9zd2l0Y2goKSkKPj4+IGdldCBjYWxsZWQgb25seSBmcm9tIENQVSBw
b29scyBjb2RlLCBhbmQgSSB3b3VsZCBndWVzcyBDUFUgcG9vbHMKPj4+IGFyZW4ndCBpbnZvbHZl
ZCBoZXJlLCBhbmQgeW91IGRvbid0IGluIHBhcmFsbGVsIHNvZnQgb2ZmbGluZS9vbmxpbmUKPj4+
IHBDUFUtcyAoYXMgSSdtIHN1cmUgeW91IG90aGVyd2lzZSB3b3VsZCBoYXZlIG1lbnRpb25lZCBp
dCkuCj4+Pgo+Pj4gQnV0IHdhaXQgLSBsaWJ4bF9fZG9tYWluX21ha2UoKSBfdW5jb25kaXRpb25h
bGx5XyBjYWxscwo+Pj4geGNfY3B1cG9vbF9tb3ZlZG9tYWluKCksIGFzIGRvZXMgWGVuZERvbWFp
bkluZm8ncwo+Pj4gX2NvbnN0cnVjdERvbWFpbigpLiBUaGUgcmVhc29uIGZvciB0aGlzIGVzY2Fw
ZXMgbWUgLSBKw7xyZ2VuPyBZZXQKPj4+IEknZCBleHBlY3QgdGhlIHBvb2wgSUQgbWF0Y2hpbmcg
Y2hlY2sgdG8gc2hvcnQgY3V0IHRoZSByZXN1bHRpbmcKPj4+IHN5c2N0bCwgaS5lLiBzY2hlZF9t
b3ZlX2RvbWFpbigpIG91Z2h0IHRvIG5vdCBiZSByZWFjaGVkIGFueXdheQo+Pj4gKHdvcnRoIHZl
cmlmeWluZyBvZiBjb3Vyc2UpLgo+Pj4KPj4+IFRoZSByYWNlIHRoZXJlIG5ldmVydGhlbGVzcyBv
dWdodCB0byBiZSBmaXhlZC4KPj4KPj4gU29tZXRoaW5nIGxpa2UgdGhlIGF0dGFjaGVkIHBhdGNo
Pwo+Pgo+PiBOb3QgdGVzdGVkIHRob3JvdWdobHkgeWV0Lgo+IAo+IEFyZ2guIFNlbnQgYW4gb2xk
IHZlcnNpb24sIHNvcnJ5LiBUaGlzIG9uZSBzaG91bGQgYmUgYmV0dGVyLgoKU29ydCBvZi4gSSB3
YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBieSBzdG9yaW5nIGp1c3QgYSBzaW5nbGUKIm9s
ZCIgcG9pbnRlciB0ZW1wb3JhcmlseSBpbnNpZGUgdGhlIGxhc3QgbG9vcCBhbmQgbW92aW5nIHRo
ZQpmcmVlX3ZkYXRhIGludm9jYXRpb24gdG8gdGhlIGVuZCBvZiB0aGlzIHNhbWUgbGFzdCBsb29w
IHdvdWxkCmVxdWFsbHkgd2VsbCB0YWtlIGNhcmUgb2YgaXQsIHdpdGhvdXQgaW5jcmVhc2luZyBz
dG9yYWdlCnJlcXVpcmVtZW50cyAoYW5kIGhlbmNlIGFsc28gaW5jcmVhc2luZyB0aGUgcmlzayBv
ZiBmYWlsdXJlKSwKYW5kIHdpdGhvdXQgeWV0IGFub3RoZXIgZm9yX2VhY2hfdmNwdSgpIGxvb3Au
CgpPciwgaWYgZ29pbmcgeW91ciByb3V0ZSwgeW91IHdvdWxkIHdhbnQgdG8gbW92ZSB0aGUgZmlu
YWwgZnJlZWluZwpvcGVyYXRpb25zIHBhc3QgdGhlIGRvbWFpbl91bnBhdXNlKCkgSSB0aGluayAo
d2hpY2ggY291bGQgYmUKZG9uZSBldmVuIHdpdGggdGhlIGFwcHJvYWNoIHN1Z2dlc3RlZCBhYm92
ZSwgYnkgcHV0dGluZyB0aGUKdG8tYmUtZnJlZWQgcG9pbnRlciBiYWNrIGludG8gdGhlIHNhbWUg
dmNwdV9wcml2W10gc2xvdCkuCgpBbmQgdGhlbiwgaWYgeW91IGFscmVhZHkgaGF2ZSB0byBjYWNo
ZSBET00yT1AoKSBpbiBhIGxvY2FsCnZhcmlhYmxlLCB5b3Ugc2hvdWxkIG9mIGNvdXJzZSBjb252
ZXJ0IHRoZSByZW1haW5pbmcgdXNlIG9mClZDUFUyT1AoKSB0byB1c2UgdGhlIGNhY2hlZCBjb3B5
ICh0aGUgdHdvIHVzZXMgb2YgdGhlIGxhdHRlcgp3ZXJlIGJvZ3VzIGFueXdheSwgYXMgdGhlIHNp
bXBsZXIgRE9NMk9QKCkgd291bGQgaGF2ZQpkb25lOyBzaW1pbGFybHkgaW4gc2NoZWRfaW5pdF92
Y3B1KCkpLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:24:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:24: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 1UAdFE-0002we-0s; Wed, 27 Feb 2013 09:24:12 +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 1UAdFB-0002wZ-Uv
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 09:24:10 +0000
Received: from [85.158.143.99:33562] by server-1.bemta-4.messagelabs.com id
	8D/4A-06203-9B0DD215; Wed, 27 Feb 2013 09:24:09 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361957047!19650210!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg5NjA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19072 invoked from network); 27 Feb 2013 09:24:08 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 09:24:08 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Feb 2013 01:22:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="268419892"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2013 01:24:06 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 01:24:06 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 17:24:04 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: Xen mce bugfix
Thread-Index: Ac4UzC8vqZTiEd/FTjyR1sPJXJqZrw==
Date: Wed, 27 Feb 2013 09:24:04 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C458@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_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>
Subject: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This work around an issue when test via xen-mceinj tools.

when inject simulated error via xen-mceinj tools,
status ADDRV/MISCV bits are simulated hence there is
potential risk of #GP if h/w not really support MCi_ADDR/MISC.
We temporarily work around by not clean them until we have
clean solution.

Reported-by: Ren Yongjie <yongjie.ren@intel.com>
Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>

diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 00:34:22 2013 +0800
@@ -144,10 +144,19 @@
=20
     status =3D mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
=20
+/*
+ * TODO: when inject simulated error via xen-mceinj tools,
+ * status ADDRV/MISCV bits are simulated hence there is
+ * potential risk of #GP if h/w not really support MCi_ADDR/MISC.
+ * We temporary work around by not clean them until we have
+ * clean solution.
+ */
+#if 0
     if (status & MCi_STATUS_ADDRV)
         mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
     if (status & MCi_STATUS_MISCV)
         mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
+#endif
=20
     mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
 }=

--_002_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen-mce-bugfix.patch"
Content-Description: xen-mce-bugfix.patch
Content-Disposition: attachment; filename="xen-mce-bugfix.patch"; size=1200;
	creation-date="Wed, 27 Feb 2013 08:57:50 GMT";
	modification-date="Wed, 27 Feb 2013 16:48:06 GMT"
Content-Transfer-Encoding: base64

VGhpcyB3b3JrIGFyb3VuZCBhbiBpc3N1ZSB3aGVuIHRlc3QgdmlhIHhlbi1tY2VpbmogdG9vbHMu
Cgp3aGVuIGluamVjdCBzaW11bGF0ZWQgZXJyb3IgdmlhIHhlbi1tY2VpbmogdG9vbHMsCnN0YXR1
cyBBRERSVi9NSVNDViBiaXRzIGFyZSBzaW11bGF0ZWQgaGVuY2UgdGhlcmUgaXMKcG90ZW50aWFs
IHJpc2sgb2YgI0dQIGlmIGgvdyBub3QgcmVhbGx5IHN1cHBvcnQgTUNpX0FERFIvTUlTQy4KV2Ug
dGVtcG9yYXJpbHkgd29yayBhcm91bmQgYnkgbm90IGNsZWFuIHRoZW0gdW50aWwgd2UgaGF2ZQpj
bGVhbiBzb2x1dGlvbi4KClJlcG9ydGVkLWJ5OiBSZW4gWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50
ZWwuY29tPgpTaW5nZWQtb2ZmLWJ5OiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29t
PgoKZGlmZiAtciBlODRhNzlkMTFkN2EgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmMKLS0t
IGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmMJVGh1IE5vdiAwMSAwMTo0MTowMyAyMDEy
ICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZS5jCVRodSBGZWIgMjggMDA6
MzQ6MjIgMjAxMyArMDgwMApAQCAtMTQ0LDEwICsxNDQsMTkgQEAKIAogICAgIHN0YXR1cyA9IG1j
YV9yZG1zcihNU1JfSUEzMl9NQ3hfU1RBVFVTKGJhbmtudW0pKTsKIAorLyoKKyAqIFRPRE86IHdo
ZW4gaW5qZWN0IHNpbXVsYXRlZCBlcnJvciB2aWEgeGVuLW1jZWluaiB0b29scywKKyAqIHN0YXR1
cyBBRERSVi9NSVNDViBiaXRzIGFyZSBzaW11bGF0ZWQgaGVuY2UgdGhlcmUgaXMKKyAqIHBvdGVu
dGlhbCByaXNrIG9mICNHUCBpZiBoL3cgbm90IHJlYWxseSBzdXBwb3J0IE1DaV9BRERSL01JU0Mu
CisgKiBXZSB0ZW1wb3Jhcnkgd29yayBhcm91bmQgYnkgbm90IGNsZWFuIHRoZW0gdW50aWwgd2Ug
aGF2ZQorICogY2xlYW4gc29sdXRpb24uCisgKi8KKyNpZiAwCiAgICAgaWYgKHN0YXR1cyAmIE1D
aV9TVEFUVVNfQUREUlYpCiAgICAgICAgIG1jYV93cm1zcihNU1JfSUEzMl9NQ3hfQUREUihiYW5r
bnVtKSwgMHgwVUxMKTsKICAgICBpZiAoc3RhdHVzICYgTUNpX1NUQVRVU19NSVNDVikKICAgICAg
ICAgbWNhX3dybXNyKE1TUl9JQTMyX01DeF9NSVNDKGJhbmtudW0pLCAweDBVTEwpOworI2VuZGlm
CiAKICAgICBtY2Ffd3Jtc3IoTVNSX0lBMzJfTUN4X1NUQVRVUyhiYW5rbnVtKSwgMHgwVUxMKTsK
IH0K

--_002_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 27 09:24:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:24: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 1UAdFE-0002we-0s; Wed, 27 Feb 2013 09:24:12 +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 1UAdFB-0002wZ-Uv
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 09:24:10 +0000
Received: from [85.158.143.99:33562] by server-1.bemta-4.messagelabs.com id
	8D/4A-06203-9B0DD215; Wed, 27 Feb 2013 09:24:09 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361957047!19650210!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg5NjA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19072 invoked from network); 27 Feb 2013 09:24:08 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 09:24:08 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Feb 2013 01:22:42 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="268419892"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2013 01:24:06 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 01:24:06 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 17:24:04 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: Xen mce bugfix
Thread-Index: Ac4UzC8vqZTiEd/FTjyR1sPJXJqZrw==
Date: Wed, 27 Feb 2013 09:24:04 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C458@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_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>
Subject: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This work around an issue when test via xen-mceinj tools.

when inject simulated error via xen-mceinj tools,
status ADDRV/MISCV bits are simulated hence there is
potential risk of #GP if h/w not really support MCi_ADDR/MISC.
We temporarily work around by not clean them until we have
clean solution.

Reported-by: Ren Yongjie <yongjie.ren@intel.com>
Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>

diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 00:34:22 2013 +0800
@@ -144,10 +144,19 @@
=20
     status =3D mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
=20
+/*
+ * TODO: when inject simulated error via xen-mceinj tools,
+ * status ADDRV/MISCV bits are simulated hence there is
+ * potential risk of #GP if h/w not really support MCi_ADDR/MISC.
+ * We temporary work around by not clean them until we have
+ * clean solution.
+ */
+#if 0
     if (status & MCi_STATUS_ADDRV)
         mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
     if (status & MCi_STATUS_MISCV)
         mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
+#endif
=20
     mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
 }=

--_002_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="xen-mce-bugfix.patch"
Content-Description: xen-mce-bugfix.patch
Content-Disposition: attachment; filename="xen-mce-bugfix.patch"; size=1200;
	creation-date="Wed, 27 Feb 2013 08:57:50 GMT";
	modification-date="Wed, 27 Feb 2013 16:48:06 GMT"
Content-Transfer-Encoding: base64

VGhpcyB3b3JrIGFyb3VuZCBhbiBpc3N1ZSB3aGVuIHRlc3QgdmlhIHhlbi1tY2VpbmogdG9vbHMu
Cgp3aGVuIGluamVjdCBzaW11bGF0ZWQgZXJyb3IgdmlhIHhlbi1tY2VpbmogdG9vbHMsCnN0YXR1
cyBBRERSVi9NSVNDViBiaXRzIGFyZSBzaW11bGF0ZWQgaGVuY2UgdGhlcmUgaXMKcG90ZW50aWFs
IHJpc2sgb2YgI0dQIGlmIGgvdyBub3QgcmVhbGx5IHN1cHBvcnQgTUNpX0FERFIvTUlTQy4KV2Ug
dGVtcG9yYXJpbHkgd29yayBhcm91bmQgYnkgbm90IGNsZWFuIHRoZW0gdW50aWwgd2UgaGF2ZQpj
bGVhbiBzb2x1dGlvbi4KClJlcG9ydGVkLWJ5OiBSZW4gWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50
ZWwuY29tPgpTaW5nZWQtb2ZmLWJ5OiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29t
PgoKZGlmZiAtciBlODRhNzlkMTFkN2EgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmMKLS0t
IGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmMJVGh1IE5vdiAwMSAwMTo0MTowMyAyMDEy
ICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZS5jCVRodSBGZWIgMjggMDA6
MzQ6MjIgMjAxMyArMDgwMApAQCAtMTQ0LDEwICsxNDQsMTkgQEAKIAogICAgIHN0YXR1cyA9IG1j
YV9yZG1zcihNU1JfSUEzMl9NQ3hfU1RBVFVTKGJhbmtudW0pKTsKIAorLyoKKyAqIFRPRE86IHdo
ZW4gaW5qZWN0IHNpbXVsYXRlZCBlcnJvciB2aWEgeGVuLW1jZWluaiB0b29scywKKyAqIHN0YXR1
cyBBRERSVi9NSVNDViBiaXRzIGFyZSBzaW11bGF0ZWQgaGVuY2UgdGhlcmUgaXMKKyAqIHBvdGVu
dGlhbCByaXNrIG9mICNHUCBpZiBoL3cgbm90IHJlYWxseSBzdXBwb3J0IE1DaV9BRERSL01JU0Mu
CisgKiBXZSB0ZW1wb3Jhcnkgd29yayBhcm91bmQgYnkgbm90IGNsZWFuIHRoZW0gdW50aWwgd2Ug
aGF2ZQorICogY2xlYW4gc29sdXRpb24uCisgKi8KKyNpZiAwCiAgICAgaWYgKHN0YXR1cyAmIE1D
aV9TVEFUVVNfQUREUlYpCiAgICAgICAgIG1jYV93cm1zcihNU1JfSUEzMl9NQ3hfQUREUihiYW5r
bnVtKSwgMHgwVUxMKTsKICAgICBpZiAoc3RhdHVzICYgTUNpX1NUQVRVU19NSVNDVikKICAgICAg
ICAgbWNhX3dybXNyKE1TUl9JQTMyX01DeF9NSVNDKGJhbmtudW0pLCAweDBVTEwpOworI2VuZGlm
CiAKICAgICBtY2Ffd3Jtc3IoTVNSX0lBMzJfTUN4X1NUQVRVUyhiYW5rbnVtKSwgMHgwVUxMKTsK
IH0K

--_002_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233540C458SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 27 09:25:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09: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 1UAdGh-00030w-H1; Wed, 27 Feb 2013 09:25:43 +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 1UAdGg-00030p-Nm
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:25:43 +0000
Received: from [85.158.137.99:26521] by server-1.bemta-3.messagelabs.com id
	65/49-13706-111DD215; Wed, 27 Feb 2013 09:25:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361957123!14982531!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8980 invoked from network); 27 Feb 2013 09:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 09:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1941669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 09:25:24 +0000
Received: from [127.0.0.1] (10.80.16.66) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Wed, 27 Feb 2013 09:25:23 +0000
Message-ID: <1361957122.11431.40.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Feb 2013 09:25:22 +0000
In-Reply-To: <512DD6EB02000078000C159C@nat28.tlf.novell.com>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
	<512DD6EB02000078000C159C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir.xen@gmail.com>, Xi Wang <xi@mit.edu>
Subject: Re: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86:
 fix null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 08:50 +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 18:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in 
> > intel_get_extended_msrs()"):
> >> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
> >> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.
> > 
> > Really I think we shouldn't be writing out these kind of memsets.
> > They're too error-prone.  We should have a macro, perhaps like this:
> > 
> >   #define FILLZERO(object) memset(&(object), 0, sizeof(object))
> > 
> > Likewise a copy macro.
> 
> Unfortunately that wouldn't be usable in all cases (arrays passed
> to functions), and hence I'm not really confident this would be a
> good move. But yes, I considered what you suggest a number of
> times already, but dropped the idea each time because of its lack
> of general applicability.
> 
> I'm afraid we just have to live with the bad side effects of the
> power C provides.

In this specific case perhaps x86_mcinfo_reserve() should zero the
buffer instead of each caller having to do the right thing? Most callers
have a memset, a couple immediately fill in the buffer instead of
zeroing it, but this isn't a hot path, is 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 Feb 27 09:25:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09: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 1UAdGh-00030w-H1; Wed, 27 Feb 2013 09:25:43 +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 1UAdGg-00030p-Nm
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:25:43 +0000
Received: from [85.158.137.99:26521] by server-1.bemta-3.messagelabs.com id
	65/49-13706-111DD215; Wed, 27 Feb 2013 09:25:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1361957123!14982531!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8980 invoked from network); 27 Feb 2013 09:25:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 09:25:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1941669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 09:25:24 +0000
Received: from [127.0.0.1] (10.80.16.66) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Wed, 27 Feb 2013 09:25:23 +0000
Message-ID: <1361957122.11431.40.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Feb 2013 09:25:22 +0000
In-Reply-To: <512DD6EB02000078000C159C@nat28.tlf.novell.com>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
	<512DD6EB02000078000C159C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir.xen@gmail.com>, Xi Wang <xi@mit.edu>
Subject: Re: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86:
 fix null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 08:50 +0000, Jan Beulich wrote:
> >>> On 26.02.13 at 18:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in 
> > intel_get_extended_msrs()"):
> >> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
> >> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.
> > 
> > Really I think we shouldn't be writing out these kind of memsets.
> > They're too error-prone.  We should have a macro, perhaps like this:
> > 
> >   #define FILLZERO(object) memset(&(object), 0, sizeof(object))
> > 
> > Likewise a copy macro.
> 
> Unfortunately that wouldn't be usable in all cases (arrays passed
> to functions), and hence I'm not really confident this would be a
> good move. But yes, I considered what you suggest a number of
> times already, but dropped the idea each time because of its lack
> of general applicability.
> 
> I'm afraid we just have to live with the bad side effects of the
> power C provides.

In this specific case perhaps x86_mcinfo_reserve() should zero the
buffer instead of each caller having to do the right thing? Most callers
have a memset, a couple immediately fill in the buffer instead of
zeroing it, but this isn't a hot path, is 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 Feb 27 09:35:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:35: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 1UAdPd-0003WY-Ap; Wed, 27 Feb 2013 09:34:57 +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 1UAdPa-0003WT-VG
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:34:55 +0000
Received: from [85.158.137.99:16562] by server-14.bemta-3.messagelabs.com id
	16/0A-27076-E33DD215; Wed, 27 Feb 2013 09:34:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361957678!17467149!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14397 invoked from network); 27 Feb 2013 09:34:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:34:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:34:38 +0000
Message-Id: <512DE13A02000078000C15DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:34:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
In-Reply-To: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen,
 credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> csched_runtime() needs to call the ct2() function to change credits
> into time.  The c2t() function, however, is expensive, as it requires
> an integer division.
> 
> c2t() was being called twice, once for the main vcpu's credit and once
> for the difference between its credit and the next in the queue.  But
> this is unnecessary; by calculating in "credit" first, we can make it
> so that we just do one conversion later in the algorithm.
> 
> This also adds more documentation describing the intended algorithm,
> along with a relevant assertion..
> 
> The effect of the new code should be the same as the old code.
> 
> v2:
>  - Change rt_credit into an int
>  - ASSERT() that rt_credit > 0, with explanation
> 
> Spotted-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
(apart from the redundant description below)

> xen,credit2: Avoid extra c2t calcuation in csched_runtime
> 
> csched_runtime() needs to call the ct2() function to change credits
> into time.  The c2t() function, however, is expensive, as it requires
> an integer division.
> 
> c2t() was being called twice, once for the main vcpu's credit and once
> for the difference between its credit and the next in the queue.  But
> this is unnecessary; by calculating in "credit" first, we can make it
> so that we just do one conversion later in the algorithm.
> 
> This also adds more documentation describing the intended algorithm,
> along with a relevant assertion..
> 
> The effect of the new code should be the same as the old code.
> 
> v2:
>  - Change rt_credit into an int
>  - ASSERT() that rt_credit > 0, with explanation
> 
> Spotted-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
>  1 file changed, 37 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index b0af010..804049e 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, 
> struct domain *dom)
>  static s_time_t
>  csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu 
> *snext)
>  {
> -    s_time_t time = CSCHED_MAX_TIMER;
> +    s_time_t time; 
> +    int rt_credit; /* Proposed runtime measured in credits */
>      struct csched_runqueue_data *rqd = RQD(ops, cpu);
>      struct list_head *runq = &rqd->runq;
>  
>      if ( is_idle_vcpu(snext->vcpu) )
>          return CSCHED_MAX_TIMER;
>  
> -    /* Basic time */
> -    time = c2t(rqd, snext->credit, snext);
> +    /* General algorithm:
> +     * 1) Run until snext's credit will be 0
> +     * 2) But if someone is waiting, run until snext's credit is equal
> +     * to his
> +     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
> +     */
> +
> +    /* 1) Basic time: Run until credit is 0. */
> +    rt_credit = snext->credit;
>  
> -    /* Next guy on runqueue */
> +    /* 2) If there's someone waiting whose credit is positive,
> +     * run until your credit ~= his */
>      if ( ! list_empty(runq) )
>      {
> -        struct csched_vcpu *svc = __runq_elem(runq->next);
> -        s_time_t ntime;
> +        struct csched_vcpu *swait = __runq_elem(runq->next);
>  
> -        if ( ! is_idle_vcpu(svc->vcpu) )
> +        if ( ! is_idle_vcpu(swait->vcpu)
> +             && swait->credit > 0 )
>          {
> -            ntime = c2t(rqd, snext->credit - svc->credit, snext);
> -
> -            if ( time > ntime )
> -                time = ntime;
> +            rt_credit = snext->credit - swait->credit;
>          }
>      }
>  
> +    /*
> +     * snext is about to be scheduled; so:
> +     *
> +     * 1. if snext->credit were less than 0 when it was taken off the
> +     * runqueue, then csched_schedule() should have called
> +     * reset_credit().  So at this point snext->credit must be greater
> +     * than 0.
> +     *
> +     * 2. snext's credit must be greater than or equal to anyone else
> +     * in the queue, so snext->credit - swait->credit must be greater
> +     * than or equal to 0.
> +     */
> +    ASSERT(rt_credit >= 0);
> +
> +    /* FIXME: See if we can eliminate this conversion if we know time
> +     * will be outside (MIN,MAX).  Probably requires pre-calculating
> +     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
> +     * at a different rate. */
> +    time = c2t(rqd, rt_credit, snext);
> +
>      /* Check limits */
>      if ( time < CSCHED_MIN_TIMER )
>          time = CSCHED_MIN_TIMER;
> -- 
> 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 Wed Feb 27 09:35:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:35: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 1UAdPd-0003WY-Ap; Wed, 27 Feb 2013 09:34:57 +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 1UAdPa-0003WT-VG
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:34:55 +0000
Received: from [85.158.137.99:16562] by server-14.bemta-3.messagelabs.com id
	16/0A-27076-E33DD215; Wed, 27 Feb 2013 09:34:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361957678!17467149!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14397 invoked from network); 27 Feb 2013 09:34:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:34:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:34:38 +0000
Message-Id: <512DE13A02000078000C15DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:34:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
In-Reply-To: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] xen,
 credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> csched_runtime() needs to call the ct2() function to change credits
> into time.  The c2t() function, however, is expensive, as it requires
> an integer division.
> 
> c2t() was being called twice, once for the main vcpu's credit and once
> for the difference between its credit and the next in the queue.  But
> this is unnecessary; by calculating in "credit" first, we can make it
> so that we just do one conversion later in the algorithm.
> 
> This also adds more documentation describing the intended algorithm,
> along with a relevant assertion..
> 
> The effect of the new code should be the same as the old code.
> 
> v2:
>  - Change rt_credit into an int
>  - ASSERT() that rt_credit > 0, with explanation
> 
> Spotted-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
(apart from the redundant description below)

> xen,credit2: Avoid extra c2t calcuation in csched_runtime
> 
> csched_runtime() needs to call the ct2() function to change credits
> into time.  The c2t() function, however, is expensive, as it requires
> an integer division.
> 
> c2t() was being called twice, once for the main vcpu's credit and once
> for the difference between its credit and the next in the queue.  But
> this is unnecessary; by calculating in "credit" first, we can make it
> so that we just do one conversion later in the algorithm.
> 
> This also adds more documentation describing the intended algorithm,
> along with a relevant assertion..
> 
> The effect of the new code should be the same as the old code.
> 
> v2:
>  - Change rt_credit into an int
>  - ASSERT() that rt_credit > 0, with explanation
> 
> Spotted-by: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
>  1 file changed, 37 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index b0af010..804049e 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, 
> struct domain *dom)
>  static s_time_t
>  csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu 
> *snext)
>  {
> -    s_time_t time = CSCHED_MAX_TIMER;
> +    s_time_t time; 
> +    int rt_credit; /* Proposed runtime measured in credits */
>      struct csched_runqueue_data *rqd = RQD(ops, cpu);
>      struct list_head *runq = &rqd->runq;
>  
>      if ( is_idle_vcpu(snext->vcpu) )
>          return CSCHED_MAX_TIMER;
>  
> -    /* Basic time */
> -    time = c2t(rqd, snext->credit, snext);
> +    /* General algorithm:
> +     * 1) Run until snext's credit will be 0
> +     * 2) But if someone is waiting, run until snext's credit is equal
> +     * to his
> +     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
> +     */
> +
> +    /* 1) Basic time: Run until credit is 0. */
> +    rt_credit = snext->credit;
>  
> -    /* Next guy on runqueue */
> +    /* 2) If there's someone waiting whose credit is positive,
> +     * run until your credit ~= his */
>      if ( ! list_empty(runq) )
>      {
> -        struct csched_vcpu *svc = __runq_elem(runq->next);
> -        s_time_t ntime;
> +        struct csched_vcpu *swait = __runq_elem(runq->next);
>  
> -        if ( ! is_idle_vcpu(svc->vcpu) )
> +        if ( ! is_idle_vcpu(swait->vcpu)
> +             && swait->credit > 0 )
>          {
> -            ntime = c2t(rqd, snext->credit - svc->credit, snext);
> -
> -            if ( time > ntime )
> -                time = ntime;
> +            rt_credit = snext->credit - swait->credit;
>          }
>      }
>  
> +    /*
> +     * snext is about to be scheduled; so:
> +     *
> +     * 1. if snext->credit were less than 0 when it was taken off the
> +     * runqueue, then csched_schedule() should have called
> +     * reset_credit().  So at this point snext->credit must be greater
> +     * than 0.
> +     *
> +     * 2. snext's credit must be greater than or equal to anyone else
> +     * in the queue, so snext->credit - swait->credit must be greater
> +     * than or equal to 0.
> +     */
> +    ASSERT(rt_credit >= 0);
> +
> +    /* FIXME: See if we can eliminate this conversion if we know time
> +     * will be outside (MIN,MAX).  Probably requires pre-calculating
> +     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
> +     * at a different rate. */
> +    time = c2t(rqd, rt_credit, snext);
> +
>      /* Check limits */
>      if ( time < CSCHED_MIN_TIMER )
>          time = CSCHED_MIN_TIMER;
> -- 
> 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 Wed Feb 27 09:41:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:41: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 1UAdVc-0003kJ-5K; Wed, 27 Feb 2013 09:41:08 +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 1UAdVa-0003k8-Pa
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:41:06 +0000
Received: from [85.158.137.99:13631] by server-16.bemta-3.messagelabs.com id
	FB/ED-20692-EA4DD215; Wed, 27 Feb 2013 09:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361958050!12679604!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6338 invoked from network); 27 Feb 2013 09:40:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:40:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:40:50 +0000
Message-Id: <512DE2AF02000078000C15F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:40:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
In-Reply-To: <1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> @@ -271,16 +272,24 @@ struct csched_dom {
>  
>  /*
>   * Time-to-credit, credit-to-time.
> + * 
> + * We keep track of the "residual" time to make sure that frequent short
> + * schedules still get accounted for in the end.
> + *
>   * FIXME: Do pre-calculated division?
>   */
> -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
> +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
> +                          struct csched_vcpu *svc)
>  {
> -    return time * rqd->max_weight / svc->weight;
> +    uint64_t val = time * rqd->max_weight + svc->residual;
> +
> +    svc->residual = do_div(val, svc->weight);
> +    svc->credit -= val;
>  }
>  
>  static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
>  {
> -    return credit * svc->weight / rqd->max_weight;
> +    return (credit * svc->weight) / rqd->max_weight;

So you dropped the subtraction of svc->residual here - why?

And if indeed intended, the insertion of parentheses here could be
dropped?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:41:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:41: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 1UAdVc-0003kJ-5K; Wed, 27 Feb 2013 09:41:08 +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 1UAdVa-0003k8-Pa
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:41:06 +0000
Received: from [85.158.137.99:13631] by server-16.bemta-3.messagelabs.com id
	FB/ED-20692-EA4DD215; Wed, 27 Feb 2013 09:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361958050!12679604!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6338 invoked from network); 27 Feb 2013 09:40:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:40:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:40:50 +0000
Message-Id: <512DE2AF02000078000C15F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:40:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
In-Reply-To: <1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> @@ -271,16 +272,24 @@ struct csched_dom {
>  
>  /*
>   * Time-to-credit, credit-to-time.
> + * 
> + * We keep track of the "residual" time to make sure that frequent short
> + * schedules still get accounted for in the end.
> + *
>   * FIXME: Do pre-calculated division?
>   */
> -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
> +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
> +                          struct csched_vcpu *svc)
>  {
> -    return time * rqd->max_weight / svc->weight;
> +    uint64_t val = time * rqd->max_weight + svc->residual;
> +
> +    svc->residual = do_div(val, svc->weight);
> +    svc->credit -= val;
>  }
>  
>  static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
>  {
> -    return credit * svc->weight / rqd->max_weight;
> +    return (credit * svc->weight) / rqd->max_weight;

So you dropped the subtraction of svc->residual here - why?

And if indeed intended, the insertion of parentheses here could be
dropped?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:50:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:50: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 1UAde8-00040h-6H; Wed, 27 Feb 2013 09:49:56 +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 1UAde6-00040c-U0
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:49:55 +0000
Received: from [193.109.254.147:12712] by server-15.bemta-14.messagelabs.com
	id 32/90-24599-2C6DD215; Wed, 27 Feb 2013 09:49:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361958593!9715785!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26352 invoked from network); 27 Feb 2013 09:49:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:49:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:49:52 +0000
Message-Id: <512DE4CF02000078000C15FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:49:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chen Gang" <gang.chen@asianux.com>,<konrad.wilk@oracle.com>
References: <512D90F2.9070200@asianux.com>
In-Reply-To: <512D90F2.9070200@asianux.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dgdegra@tycho.nsa.gov, stefano.stabellini@eu.citrix.com,
	xen-devel <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 05:52, Chen Gang <gang.chen@asianux.com> wrote:

>   if call xen_vbd_translate failed, the preq.dev will be not initialized.
>   so use blkif->vbd.pdevice instead (still better to print relative info).
> 
> Signed-off-by: Chen Gang <gang.chen@asianux.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  drivers/block/xen-blkback/blkback.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index de1f319..6d1cc3d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -904,7 +904,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  		pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on dev=%04x\n",
>  			 operation == READ ? "read" : "write",
>  			 preq.sector_number,
> -			 preq.sector_number + preq.nr_sects, preq.dev);
> +			 preq.sector_number + preq.nr_sects,
> +			 blkif->vbd.pdevice);
>  		goto fail_response;
>  	}
>  
> -- 
> 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 Wed Feb 27 09:50:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:50: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 1UAde8-00040h-6H; Wed, 27 Feb 2013 09:49:56 +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 1UAde6-00040c-U0
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:49:55 +0000
Received: from [193.109.254.147:12712] by server-15.bemta-14.messagelabs.com
	id 32/90-24599-2C6DD215; Wed, 27 Feb 2013 09:49:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361958593!9715785!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26352 invoked from network); 27 Feb 2013 09:49:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:49:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:49:52 +0000
Message-Id: <512DE4CF02000078000C15FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:49:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chen Gang" <gang.chen@asianux.com>,<konrad.wilk@oracle.com>
References: <512D90F2.9070200@asianux.com>
In-Reply-To: <512D90F2.9070200@asianux.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dgdegra@tycho.nsa.gov, stefano.stabellini@eu.citrix.com,
	xen-devel <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 05:52, Chen Gang <gang.chen@asianux.com> wrote:

>   if call xen_vbd_translate failed, the preq.dev will be not initialized.
>   so use blkif->vbd.pdevice instead (still better to print relative info).
> 
> Signed-off-by: Chen Gang <gang.chen@asianux.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  drivers/block/xen-blkback/blkback.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index de1f319..6d1cc3d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -904,7 +904,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  		pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on dev=%04x\n",
>  			 operation == READ ? "read" : "write",
>  			 preq.sector_number,
> -			 preq.sector_number + preq.nr_sects, preq.dev);
> +			 preq.sector_number + preq.nr_sects,
> +			 blkif->vbd.pdevice);
>  		goto fail_response;
>  	}
>  
> -- 
> 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 Wed Feb 27 09:50:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:50: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 1UAdeG-000414-Oj; Wed, 27 Feb 2013 09:50:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1UAdeE-00040v-6S
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:50:02 +0000
Received: from [85.158.139.211:21499] by server-3.bemta-5.messagelabs.com id
	B3/D4-17256-9C6DD215; Wed, 27 Feb 2013 09:50:01 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361958568!18553594!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU5Njc2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 27 Feb 2013 09:49:31 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-206.messagelabs.com with SMTP;
	27 Feb 2013 09:49:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 27 Feb 2013 01:49:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="206808739"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 27 Feb 2013 01:49:26 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 01:49:25 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 17:49:23 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
Thread-Index: AQHOFDkE9tWSzP5xh0+Cca//iHZcEZiNdHoA
Date: Wed, 27 Feb 2013 09:49:23 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440343F776@SHSMSX101.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
	<1361893836.26546.304.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361893836.26546.304.camel@zakaz.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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>, "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Given that Xen has at least two other mechanisms (xenstore and
> hvmparams) for passing this sort of information around I'm not sure why
> hacking the emulated i440fx device should be the preferred option.

Actually, even in hardware,  I believe there are many registers which are implemented with write-once attributes, and they are only used by firmware and reserved for OS.   In addition,  with this change,  it can benefit all VMMs (not just Xen) which use Qemu as device model.  If adopt xenstore way, perhaps other VMMs also have to write similar and duplicate logic for the same purpose.  
Xiantao 


> On Tue, 2013-02-26 at 15:43 +0000, Stefano Stabellini wrote:
> > Right, I think that reading as 0xff and write once would be important
> > improvements for this patch.
> >
> > I would like to see a document somewhere (maybe just a text file under
> > xen-unstable/docs/misc) with a list of deviations of the i440fx we
> > emulate and the real one.

> > Other than that, it would be OK for me.
> >
> > On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> > > For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing
> with Qemu should break this hardware rule.  Maybe we can implement this
> register as a write-only one, so that OS can't see its existence.   If OS reads this
> register, Qemu always return 0xff, and for any write operations to this register,
> it may impact hardware's behavior.  This conforms to the behavior of OS
> accessing a reserved register.
> > > Xiantao
> > >
> > > > -----Original Message-----
> > > > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> > > > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On
> Behalf
> > > > Of Hao, Xudong
> > > > Sent: Tuesday, February 26, 2013 11:33 AM
> > > > To: Stefano Stabellini; Ian Campbell
> > > > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org;
> xen-
> > > > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to
> report the
> > > > base of PCI
> > > >
> > > > > -----Original Message-----
> > > > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > > > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On
> Behalf
> > > > > Of Stefano Stabellini
> > > > > Sent: Tuesday, February 26, 2013 12:06 AM
> > > > > To: Hao, Xudong
> > > > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > > > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > > > > afaerber@suse.de
> > > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to
> report
> > > > the
> > > > > base of PCI
> > > > >
> > > > > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > > > > v2:
> > > > > > * Use "piix: " in the subject rather than "qemu: "
> > > > > > * Define TOM register as one byte
> > > > > > * Define default TOM value instead of hardcode 0xe0000000 in more
> that
> > > > one
> > > > > place
> > > > > > * Use API pci_set_byte for pci config access
> > > > > > * Use dev->config instead of the indirect d->dev.config
> > > > > >
> > > > > > Define a TOM(top of memory) register to report the base of PCI
> memory,
> > > > > update
> > > > > > memory region dynamically. TOM register are defined to one byte in
> PCI
> > > > > configure
> > > > > > space, because that only upper 4 bit of PCI memory takes effect for
> Xen, so
> > > > > > it requires bios set TOM with 16M-aligned.
> > > > > >
> > > > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > > >
> > > > > The patch is OK from my POV, but I think that Ian raised a valid
> > > > > concern: we are supposed to emulate a real piece of hardware, maybe
> > > > > another mechanism (xenbus? hvmop?) to pass the information from
> > > > > hvmloader to QEMU would be a better fit than this.
> > > > > Otherwise at least we would need to advertize this feature somehow: if
> > > > > hvmloader can use it, the guest kernel can use it too...
> > > > >
> > > > Hi, Ian and Stefano
> > > >
> > > > Here adding this faking register in bios is a hack way.
> > > > However, what we emulated is not full real piece of hardware at all times,
> the
> > > > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> > > > The faking register is only effective by bios and device model. This
> register is
> > > > reserved by host bridge, so guest can't access this register, guest kernel
> should
> > > > handle well when accessing a reserved region.
> > > >
> > > > -Thanks
> > > > Xudong
> > > > >
> > > > >
> > > > > >  hw/pc.h       |  7 +++---
> > > > > >  hw/pc_piix.c  | 12 +++-------
> > > > > >  hw/piix_pci.c | 73
> > > > > +++++++++++++++++++++++++++++++++++++++++++----------------
> > > > > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > > > > >
> > > > > > diff --git a/hw/pc.h b/hw/pc.h
> > > > > > index fbcf43d..62adcc5 100644
> > > > > > --- a/hw/pc.h
> > > > > > +++ b/hw/pc.h
> > > > > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > > > > >  struct PCII440FXState;
> > > > > >  typedef struct PCII440FXState PCII440FXState;
> > > > > >
> > > > > > +#define I440FX_TOM     0xe0000000
> > > > > > +#define I440FX_XEN_TOM 0xf0000000
> > > > > > +
> > > > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > > > > >                      ISABus **isa_bus, qemu_irq *pic,
> > > > > >                      MemoryRegion *address_space_mem,
> > > > > >                      MemoryRegion *address_space_io,
> > > > > >                      ram_addr_t ram_size,
> > > > > > -                    hwaddr pci_hole_start,
> > > > > > -                    hwaddr pci_hole_size,
> > > > > > -                    hwaddr pci_hole64_start,
> > > > > > -                    hwaddr pci_hole64_size,
> > > > > >                      MemoryRegion *pci_memory,
> > > > > >                      MemoryRegion *ram_memory);
> > > > > >
> > > > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > > > > index 0a6923d..2eef510 100644
> > > > > > --- a/hw/pc_piix.c
> > > > > > +++ b/hw/pc_piix.c
> > > > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion
> *system_memory,
> > > > > >          kvmclock_create();
> > > > > >      }
> > > > > >
> > > > > > -    if (ram_size >= 0xe0000000 ) {
> > > > > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > > > > -        below_4g_mem_size = 0xe0000000;
> > > > > > +    if (ram_size >= I440FX_TOM) {
> > > > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > > > > +        below_4g_mem_size = I440FX_TOM;
> > > > > >      } else {
> > > > > >          above_4g_mem_size = 0;
> > > > > >          below_4g_mem_size = ram_size;
> > > > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > > > > *system_memory,
> > > > > >      if (pci_enabled) {
> > > > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > > > > >                                system_memory, system_io,
> > > > > ram_size,
> > > > > > -                              below_4g_mem_size,
> > > > > > -                              0x100000000ULL -
> > > > > below_4g_mem_size,
> > > > > > -                              0x100000000ULL +
> > > > > above_4g_mem_size,
> > > > > > -                              (sizeof(hwaddr) == 4
> > > > > > -                               ? 0
> > > > > > -                               : ((uint64_t)1 << 62)),
> > > > > >                                pci_memory, ram_memory);
> > > > > >      } else {
> > > > > >          pci_bus = NULL;
> > > > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > > > > index 3d79c73..3e5a25c 100644
> > > > > > --- a/hw/piix_pci.c
> > > > > > +++ b/hw/piix_pci.c
> > > > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > > > > >  #define I440FX_PAM_SIZE 7
> > > > > >  #define I440FX_SMRAM    0x72
> > > > > >
> > > > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > > > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > > > > + * define another register to report the base of PCI memory.
> > > > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > > > > + * resevered for host bridge.
> > > > > > + * */
> > > > > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > > > > +
> > > > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > > > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > > > > pci_intx);
> > > > > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice
> *pci_dev, int
> > > > > pci_intx)
> > > > > >      return (pci_intx + slot_addend) & 3;
> > > > > >  }
> > > > > >
> > > > > > +
> > > > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > > > > +{
> > > > > > +    ram_addr_t above_4g_mem_size;
> > > > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > > > > pci_hole64_size;
> > > > > > +
> > > > > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > > > > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > > > > +
> > > > > > +    if (ram_size >= pci_hole_start) {
> > > > > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > > > > +    } else {
> > > > > > +        above_4g_mem_size = 0;
> > > > > > +    }
> > > > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > > > > +
> > > > > > +    if (del) {
> > > > > > +        memory_region_del_subregion(f->system_memory,
> > > > > &f->pci_hole);
> > > > > > +        if (pci_hole64_size) {
> > > > > > +            memory_region_del_subregion(f->system_memory,
> > > > > &f->pci_hole_64bit);
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > > f->pci_address_space,
> > > > > > +                             pci_hole_start, pci_hole_size);
> > > > > > +    memory_region_add_subregion(f->system_memory,
> pci_hole_start,
> > > > > &f->pci_hole);
> > > > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > > +                             f->pci_address_space,
> > > > > > +                             pci_hole64_start, pci_hole64_size);
> > > > > > +    if (pci_hole64_size) {
> > > > > > +        memory_region_add_subregion(f->system_memory,
> > > > > pci_hole64_start,
> > > > > > +                                    &f->pci_hole_64bit);
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > > +
> > > > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > > > > >  {
> > > > > >      int i;
> > > > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice
> *dev,
> > > > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > > > > >          i440fx_update_memory_mappings(d);
> > > > > >      }
> > > > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > > > > +        i440fx_update_pci_mem_hole(d, true);
> > > > > > +    }
> > > > > >  }
> > > > > >
> > > > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > > > > >
> > > > > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > > > > >
> > > > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE,
> (uint8_t)(addr >>
> > > > > 24));
> > > > > > +
> > > > > >      cpu_smm_register(&i440fx_set_smm, d);
> > > > > >      return 0;
> > > > > >  }
> > > > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const
> char
> > > > > *device_name,
> > > > > >                                    MemoryRegion
> > > > > *address_space_mem,
> > > > > >                                    MemoryRegion
> > > > > *address_space_io,
> > > > > >                                    ram_addr_t ram_size,
> > > > > > -                                  hwaddr pci_hole_start,
> > > > > > -                                  hwaddr pci_hole_size,
> > > > > > -                                  hwaddr pci_hole64_start,
> > > > > > -                                  hwaddr pci_hole64_size,
> > > > > >                                    MemoryRegion
> > > > > *pci_address_space,
> > > > > >                                    MemoryRegion *ram_memory)
> > > > > >  {
> > > > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const
> char
> > > > > *device_name,
> > > > > >      f->system_memory = address_space_mem;
> > > > > >      f->pci_address_space = pci_address_space;
> > > > > >      f->ram_memory = ram_memory;
> > > > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > > f->pci_address_space,
> > > > > > -                             pci_hole_start, pci_hole_size);
> > > > > > -    memory_region_add_subregion(f->system_memory,
> pci_hole_start,
> > > > > &f->pci_hole);
> > > > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > > -                             f->pci_address_space,
> > > > > > -                             pci_hole64_start, pci_hole64_size);
> > > > > > -    if (pci_hole64_size) {
> > > > > > -        memory_region_add_subregion(f->system_memory,
> > > > > pci_hole64_start,
> > > > > > -                                    &f->pci_hole_64bit);
> > > > > > -    }
> > > > > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > > > > >                               f->pci_address_space, 0xa0000,
> > > > > 0x20000);
> > > > > >      memory_region_add_subregion_overlap(f->system_memory,
> > > > > 0xa0000,
> > > > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > > > > *device_name,
> > > > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > > > > >
> > > > > >      i440fx_update_memory_mappings(f);
> > > > > > +    i440fx_update_pci_mem_hole(f, false);
> > > > > >
> > > > > >      return b;
> > > > > >  }
> > > > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > > > > **pi440fx_state, int *piix3_devfn,
> > > > > >                      MemoryRegion *address_space_mem,
> > > > > >                      MemoryRegion *address_space_io,
> > > > > >                      ram_addr_t ram_size,
> > > > > > -                    hwaddr pci_hole_start,
> > > > > > -                    hwaddr pci_hole_size,
> > > > > > -                    hwaddr pci_hole64_start,
> > > > > > -                    hwaddr pci_hole64_size,
> > > > > >                      MemoryRegion *pci_memory, MemoryRegion
> > > > > *ram_memory)
> > > > > >
> > > > > >  {
> > > > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState
> **pi440fx_state,
> > > > > int *piix3_devfn,
> > > > > >
> > > > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn,
> isa_bus,
> > > > > pic,
> > > > > >                             address_space_mem, address_space_io,
> > > > > ram_size,
> > > > > > -                           pci_hole_start, pci_hole_size,
> > > > > > -                           pci_hole64_start, pci_hole64_size,
> > > > > >                             pci_memory, ram_memory);
> > > > > >      return b;
> > > > > >  }
> > > > > > --
> > > > > > 1.7.12.1
> > > > > >
> > > >
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:50:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09:50: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 1UAdeG-000414-Oj; Wed, 27 Feb 2013 09:50:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1UAdeE-00040v-6S
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:50:02 +0000
Received: from [85.158.139.211:21499] by server-3.bemta-5.messagelabs.com id
	B3/D4-17256-9C6DD215; Wed, 27 Feb 2013 09:50:01 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361958568!18553594!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU5Njc2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 27 Feb 2013 09:49:31 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-206.messagelabs.com with SMTP;
	27 Feb 2013 09:49:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 27 Feb 2013 01:49:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="206808739"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 27 Feb 2013 01:49:26 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 01:49:25 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 17:49:23 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
Thread-Index: AQHOFDkE9tWSzP5xh0+Cca//iHZcEZiNdHoA
Date: Wed, 27 Feb 2013 09:49:23 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A483456440343F776@SHSMSX101.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
	<1361893836.26546.304.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361893836.26546.304.camel@zakaz.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: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>, "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Given that Xen has at least two other mechanisms (xenstore and
> hvmparams) for passing this sort of information around I'm not sure why
> hacking the emulated i440fx device should be the preferred option.

Actually, even in hardware,  I believe there are many registers which are implemented with write-once attributes, and they are only used by firmware and reserved for OS.   In addition,  with this change,  it can benefit all VMMs (not just Xen) which use Qemu as device model.  If adopt xenstore way, perhaps other VMMs also have to write similar and duplicate logic for the same purpose.  
Xiantao 


> On Tue, 2013-02-26 at 15:43 +0000, Stefano Stabellini wrote:
> > Right, I think that reading as 0xff and write once would be important
> > improvements for this patch.
> >
> > I would like to see a document somewhere (maybe just a text file under
> > xen-unstable/docs/misc) with a list of deviations of the i440fx we
> > emulate and the real one.

> > Other than that, it would be OK for me.
> >
> > On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> > > For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing
> with Qemu should break this hardware rule.  Maybe we can implement this
> register as a write-only one, so that OS can't see its existence.   If OS reads this
> register, Qemu always return 0xff, and for any write operations to this register,
> it may impact hardware's behavior.  This conforms to the behavior of OS
> accessing a reserved register.
> > > Xiantao
> > >
> > > > -----Original Message-----
> > > > From: qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org
> > > > [mailto:qemu-devel-bounces+xiantao.zhang=intel.com@nongnu.org] On
> Behalf
> > > > Of Hao, Xudong
> > > > Sent: Tuesday, February 26, 2013 11:33 AM
> > > > To: Stefano Stabellini; Ian Campbell
> > > > Cc: aliguori@us.ibm.com; mst@redhat.com; qemu-devel@nongnu.org;
> xen-
> > > > devel@lists.xen.org; JBeulich@suse.com; afaerber@suse.de
> > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to
> report the
> > > > base of PCI
> > > >
> > > > > -----Original Message-----
> > > > > From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> > > > > [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On
> Behalf
> > > > > Of Stefano Stabellini
> > > > > Sent: Tuesday, February 26, 2013 12:06 AM
> > > > > To: Hao, Xudong
> > > > > Cc: aliguori@us.ibm.com; Stefano Stabellini; mst@redhat.com;
> > > > > qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> > > > > afaerber@suse.de
> > > > > Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to
> report
> > > > the
> > > > > base of PCI
> > > > >
> > > > > On Mon, 25 Feb 2013, Xudong Hao wrote:
> > > > > > v2:
> > > > > > * Use "piix: " in the subject rather than "qemu: "
> > > > > > * Define TOM register as one byte
> > > > > > * Define default TOM value instead of hardcode 0xe0000000 in more
> that
> > > > one
> > > > > place
> > > > > > * Use API pci_set_byte for pci config access
> > > > > > * Use dev->config instead of the indirect d->dev.config
> > > > > >
> > > > > > Define a TOM(top of memory) register to report the base of PCI
> memory,
> > > > > update
> > > > > > memory region dynamically. TOM register are defined to one byte in
> PCI
> > > > > configure
> > > > > > space, because that only upper 4 bit of PCI memory takes effect for
> Xen, so
> > > > > > it requires bios set TOM with 16M-aligned.
> > > > > >
> > > > > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > > > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > > >
> > > > > The patch is OK from my POV, but I think that Ian raised a valid
> > > > > concern: we are supposed to emulate a real piece of hardware, maybe
> > > > > another mechanism (xenbus? hvmop?) to pass the information from
> > > > > hvmloader to QEMU would be a better fit than this.
> > > > > Otherwise at least we would need to advertize this feature somehow: if
> > > > > hvmloader can use it, the guest kernel can use it too...
> > > > >
> > > > Hi, Ian and Stefano
> > > >
> > > > Here adding this faking register in bios is a hack way.
> > > > However, what we emulated is not full real piece of hardware at all times,
> the
> > > > max of TOM for i440fx is 1G, and we already adjust the TOM in qemu.
> > > > The faking register is only effective by bios and device model. This
> register is
> > > > reserved by host bridge, so guest can't access this register, guest kernel
> should
> > > > handle well when accessing a reserved region.
> > > >
> > > > -Thanks
> > > > Xudong
> > > > >
> > > > >
> > > > > >  hw/pc.h       |  7 +++---
> > > > > >  hw/pc_piix.c  | 12 +++-------
> > > > > >  hw/piix_pci.c | 73
> > > > > +++++++++++++++++++++++++++++++++++++++++++----------------
> > > > > >  3 files changed, 59 insertions(+), 33 deletions(-)
> > > > > >
> > > > > > diff --git a/hw/pc.h b/hw/pc.h
> > > > > > index fbcf43d..62adcc5 100644
> > > > > > --- a/hw/pc.h
> > > > > > +++ b/hw/pc.h
> > > > > > @@ -129,15 +129,14 @@ extern int no_hpet;
> > > > > >  struct PCII440FXState;
> > > > > >  typedef struct PCII440FXState PCII440FXState;
> > > > > >
> > > > > > +#define I440FX_TOM     0xe0000000
> > > > > > +#define I440FX_XEN_TOM 0xf0000000
> > > > > > +
> > > > > >  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
> > > > > >                      ISABus **isa_bus, qemu_irq *pic,
> > > > > >                      MemoryRegion *address_space_mem,
> > > > > >                      MemoryRegion *address_space_io,
> > > > > >                      ram_addr_t ram_size,
> > > > > > -                    hwaddr pci_hole_start,
> > > > > > -                    hwaddr pci_hole_size,
> > > > > > -                    hwaddr pci_hole64_start,
> > > > > > -                    hwaddr pci_hole64_size,
> > > > > >                      MemoryRegion *pci_memory,
> > > > > >                      MemoryRegion *ram_memory);
> > > > > >
> > > > > > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > > > > > index 0a6923d..2eef510 100644
> > > > > > --- a/hw/pc_piix.c
> > > > > > +++ b/hw/pc_piix.c
> > > > > > @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion
> *system_memory,
> > > > > >          kvmclock_create();
> > > > > >      }
> > > > > >
> > > > > > -    if (ram_size >= 0xe0000000 ) {
> > > > > > -        above_4g_mem_size = ram_size - 0xe0000000;
> > > > > > -        below_4g_mem_size = 0xe0000000;
> > > > > > +    if (ram_size >= I440FX_TOM) {
> > > > > > +        above_4g_mem_size = ram_size - I440FX_TOM;
> > > > > > +        below_4g_mem_size = I440FX_TOM;
> > > > > >      } else {
> > > > > >          above_4g_mem_size = 0;
> > > > > >          below_4g_mem_size = ram_size;
> > > > > > @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion
> > > > > *system_memory,
> > > > > >      if (pci_enabled) {
> > > > > >          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
> > > > > >                                system_memory, system_io,
> > > > > ram_size,
> > > > > > -                              below_4g_mem_size,
> > > > > > -                              0x100000000ULL -
> > > > > below_4g_mem_size,
> > > > > > -                              0x100000000ULL +
> > > > > above_4g_mem_size,
> > > > > > -                              (sizeof(hwaddr) == 4
> > > > > > -                               ? 0
> > > > > > -                               : ((uint64_t)1 << 62)),
> > > > > >                                pci_memory, ram_memory);
> > > > > >      } else {
> > > > > >          pci_bus = NULL;
> > > > > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > > > > > index 3d79c73..3e5a25c 100644
> > > > > > --- a/hw/piix_pci.c
> > > > > > +++ b/hw/piix_pci.c
> > > > > > @@ -86,6 +86,14 @@ struct PCII440FXState {
> > > > > >  #define I440FX_PAM_SIZE 7
> > > > > >  #define I440FX_SMRAM    0x72
> > > > > >
> > > > > > +/* The maximum vaule of TOM(top of memory) register in I440FX
> > > > > > + * is 1G, so it doesn't meet any popular virutal machines, so
> > > > > > + * define another register to report the base of PCI memory.
> > > > > > + * Use one byte 0xb0 for the upper 8 bit, they are originally
> > > > > > + * resevered for host bridge.
> > > > > > + * */
> > > > > > +#define I440FX_PCI_HOLE_BASE 0xb0
> > > > > > +
> > > > > >  static void piix3_set_irq(void *opaque, int pirq, int level);
> > > > > >  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int
> > > > > pci_intx);
> > > > > >  static void piix3_write_config_xen(PCIDevice *dev,
> > > > > > @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice
> *pci_dev, int
> > > > > pci_intx)
> > > > > >      return (pci_intx + slot_addend) & 3;
> > > > > >  }
> > > > > >
> > > > > > +
> > > > > > +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> > > > > > +{
> > > > > > +    ram_addr_t above_4g_mem_size;
> > > > > > +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start,
> > > > > pci_hole64_size;
> > > > > > +
> > > > > > +    pci_hole_start = pci_default_read_config(&f->dev,
> > > > > I440FX_PCI_HOLE_BASE, 1) << 24;
> > > > > > +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> > > > > > +
> > > > > > +    if (ram_size >= pci_hole_start) {
> > > > > > +        above_4g_mem_size = ram_size - pci_hole_start;
> > > > > > +    } else {
> > > > > > +        above_4g_mem_size = 0;
> > > > > > +    }
> > > > > > +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> > > > > > +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> > > > > > +
> > > > > > +    if (del) {
> > > > > > +        memory_region_del_subregion(f->system_memory,
> > > > > &f->pci_hole);
> > > > > > +        if (pci_hole64_size) {
> > > > > > +            memory_region_del_subregion(f->system_memory,
> > > > > &f->pci_hole_64bit);
> > > > > > +        }
> > > > > > +    }
> > > > > > +
> > > > > > +    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > > f->pci_address_space,
> > > > > > +                             pci_hole_start, pci_hole_size);
> > > > > > +    memory_region_add_subregion(f->system_memory,
> pci_hole_start,
> > > > > &f->pci_hole);
> > > > > > +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > > +                             f->pci_address_space,
> > > > > > +                             pci_hole64_start, pci_hole64_size);
> > > > > > +    if (pci_hole64_size) {
> > > > > > +        memory_region_add_subregion(f->system_memory,
> > > > > pci_hole64_start,
> > > > > > +                                    &f->pci_hole_64bit);
> > > > > > +    }
> > > > > > +}
> > > > > > +
> > > > > > +
> > > > > >  static void i440fx_update_memory_mappings(PCII440FXState *d)
> > > > > >  {
> > > > > >      int i;
> > > > > > @@ -136,6 +181,9 @@ static void i440fx_write_config(PCIDevice
> *dev,
> > > > > >          range_covers_byte(address, len, I440FX_SMRAM)) {
> > > > > >          i440fx_update_memory_mappings(d);
> > > > > >      }
> > > > > > +    if (range_covers_byte(address, len, I440FX_PCI_HOLE_BASE)) {
> > > > > > +        i440fx_update_pci_mem_hole(d, true);
> > > > > > +    }
> > > > > >  }
> > > > > >
> > > > > >  static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
> > > > > > @@ -203,6 +251,10 @@ static int i440fx_initfn(PCIDevice *dev)
> > > > > >
> > > > > >      d->dev.config[I440FX_SMRAM] = 0x02;
> > > > > >
> > > > > > +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> > > > > > +    uint32_t addr = xen_enabled() ? I440FX_XEN_TOM : I440FX_TOM;
> > > > > > +    pci_set_byte(dev->config + I440FX_PCI_HOLE_BASE,
> (uint8_t)(addr >>
> > > > > 24));
> > > > > > +
> > > > > >      cpu_smm_register(&i440fx_set_smm, d);
> > > > > >      return 0;
> > > > > >  }
> > > > > > @@ -214,10 +266,6 @@ static PCIBus *i440fx_common_init(const
> char
> > > > > *device_name,
> > > > > >                                    MemoryRegion
> > > > > *address_space_mem,
> > > > > >                                    MemoryRegion
> > > > > *address_space_io,
> > > > > >                                    ram_addr_t ram_size,
> > > > > > -                                  hwaddr pci_hole_start,
> > > > > > -                                  hwaddr pci_hole_size,
> > > > > > -                                  hwaddr pci_hole64_start,
> > > > > > -                                  hwaddr pci_hole64_size,
> > > > > >                                    MemoryRegion
> > > > > *pci_address_space,
> > > > > >                                    MemoryRegion *ram_memory)
> > > > > >  {
> > > > > > @@ -244,16 +292,6 @@ static PCIBus *i440fx_common_init(const
> char
> > > > > *device_name,
> > > > > >      f->system_memory = address_space_mem;
> > > > > >      f->pci_address_space = pci_address_space;
> > > > > >      f->ram_memory = ram_memory;
> > > > > > -    memory_region_init_alias(&f->pci_hole, "pci-hole",
> > > > > f->pci_address_space,
> > > > > > -                             pci_hole_start, pci_hole_size);
> > > > > > -    memory_region_add_subregion(f->system_memory,
> pci_hole_start,
> > > > > &f->pci_hole);
> > > > > > -    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> > > > > > -                             f->pci_address_space,
> > > > > > -                             pci_hole64_start, pci_hole64_size);
> > > > > > -    if (pci_hole64_size) {
> > > > > > -        memory_region_add_subregion(f->system_memory,
> > > > > pci_hole64_start,
> > > > > > -                                    &f->pci_hole_64bit);
> > > > > > -    }
> > > > > >      memory_region_init_alias(&f->smram_region, "smram-region",
> > > > > >                               f->pci_address_space, 0xa0000,
> > > > > 0x20000);
> > > > > >      memory_region_add_subregion_overlap(f->system_memory,
> > > > > 0xa0000,
> > > > > > @@ -295,6 +333,7 @@ static PCIBus *i440fx_common_init(const char
> > > > > *device_name,
> > > > > >      (*pi440fx_state)->dev.config[0x57]=ram_size;
> > > > > >
> > > > > >      i440fx_update_memory_mappings(f);
> > > > > > +    i440fx_update_pci_mem_hole(f, false);
> > > > > >
> > > > > >      return b;
> > > > > >  }
> > > > > > @@ -304,10 +343,6 @@ PCIBus *i440fx_init(PCII440FXState
> > > > > **pi440fx_state, int *piix3_devfn,
> > > > > >                      MemoryRegion *address_space_mem,
> > > > > >                      MemoryRegion *address_space_io,
> > > > > >                      ram_addr_t ram_size,
> > > > > > -                    hwaddr pci_hole_start,
> > > > > > -                    hwaddr pci_hole_size,
> > > > > > -                    hwaddr pci_hole64_start,
> > > > > > -                    hwaddr pci_hole64_size,
> > > > > >                      MemoryRegion *pci_memory, MemoryRegion
> > > > > *ram_memory)
> > > > > >
> > > > > >  {
> > > > > > @@ -315,8 +350,6 @@ PCIBus *i440fx_init(PCII440FXState
> **pi440fx_state,
> > > > > int *piix3_devfn,
> > > > > >
> > > > > >      b = i440fx_common_init("i440FX", pi440fx_state, piix3_devfn,
> isa_bus,
> > > > > pic,
> > > > > >                             address_space_mem, address_space_io,
> > > > > ram_size,
> > > > > > -                           pci_hole_start, pci_hole_size,
> > > > > > -                           pci_hole64_start, pci_hole64_size,
> > > > > >                             pci_memory, ram_memory);
> > > > > >      return b;
> > > > > >  }
> > > > > > --
> > > > > > 1.7.12.1
> > > > > >
> > > >
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 09:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09: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 1UAdiK-0004IP-JR; Wed, 27 Feb 2013 09:54:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1UAdiJ-0004II-9s
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 09:54:15 +0000
Received: from [193.109.254.147:40514] by server-1.bemta-14.messagelabs.com id
	10/E3-29874-6C7DD215; Wed, 27 Feb 2013 09:54:14 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361958851!9201590!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDIwMTc5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16734 invoked from network); 27 Feb 2013 09:54:11 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 09:54: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:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=HhxaH7eRezaud+T8m/8BXpQYNPCytjib0qhZA9GYY4qlt/lEPdbRZj+r
	NNWuXeYzovgAmbYGZka2AyzIYSSqmzYlFdLN0Y7QuwlPw0gp6ktIOxYIR
	KFh6UJNDQBwBJYXXOs4gACbB3c/stQDYYmU7tULlrbxN4BgP6L9JmBsah
	xny3NkB13WpE6imelUIysq2AQWfganD0K8RQmBktXKY8I9mHJI7f2QASu
	YvqfJmRME0Zx+JaCE3VWH5cEFgJIR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361958851; x=1393494851;
	h=mime-version:subject:message-id:date:from:to;
	bh=iseTBsEtXVZ6MIKR5Hfr0YKyp1AxoC+zMxls8S9zP1c=;
	b=uKRzTxzXa+ghzfCYFNwLgncI9iUAJ+7wpsLBcI3UVsqWpqkA7bPIW0Ov
	Cwx7rwlGRiSi3c5z5g5e8lNAxFEX0fOcDfJ5Q5DmCpxZ49yDth7aF++XQ
	6oJr91wv3tLFfcKyXBiMY8YOAYSdqwYEwjPLvFTfM8DUYTAo//VoMFJ2D
	ONLQrfaEQ8QWSTjUn7f8QL7pnOwJZOmGTbJH9wph0LB5LaHzvUBVSO17H
	lkmmpZm8qGR9XaCnCTBKv3coDxANb;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; d="scan'208";a="117148631"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 27 Feb 2013 10:53:54 +0100
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; 
   d="scan'208";a="5128749"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 10:53:53 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id A14FA971313;
	Wed, 27 Feb 2013 10:53:54 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============1161369283527318403=="
MIME-Version: 1.0
X-Mercurial-Node: 04071eb1f2d29de3497f88b860b0584ca25e284e
Message-Id: <04071eb1f2d29de3497f.1361958220@nehalem1>
Date: Wed, 27 Feb 2013 10:43:40 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] (V2) Avoid stale pointer when moving domain to
	another cpupool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--===============1161369283527318403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.

Changes since V1:
- don't use an an own loop for freeing vcpu_data
- free old domain data after unpausing the domain
- simplify sched_init_vcpu (DOM2OP instead VCPU2OP)

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


1 file changed, 14 insertions(+), 6 deletions(-)
xen/common/schedule.c |   20 ++++++++++++++------



--===============1161369283527318403==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1361958197 -3600
# Node ID 04071eb1f2d29de3497f88b860b0584ca25e284e
# Parent  1d8c65aee03eaf15ce8ee50deb781b4308302b77
(V2) Avoid stale pointer when moving domain to another cpupool

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.

Changes since V1:
- don't use an an own loop for freeing vcpu_data
- free old domain data after unpausing the domain
- simplify sched_init_vcpu (DOM2OP instead VCPU2OP)

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e -r 04071eb1f2d2 xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/schedule.c	Wed Feb 27 10:43:17 2013 +0100
@@ -220,7 +220,7 @@ int sched_init_vcpu(struct vcpu *v, unsi
     if ( v->sched_priv == NULL )
         return 1;
 
-    SCHED_OP(VCPU2OP(v), insert_vcpu, v);
+    SCHED_OP(DOM2OP(d), insert_vcpu, v);
 
     return 0;
 }
@@ -231,6 +231,9 @@ int sched_move_domain(struct domain *d, 
     unsigned int new_p;
     void **vcpu_priv;
     void *domdata;
+    void *vcpudata;
+    struct scheduler *old_ops;
+    void *old_domdata;
 
     domdata = SCHED_OP(c->sched, alloc_domdata, d);
     if ( domdata == NULL )
@@ -261,14 +264,13 @@ int sched_move_domain(struct domain *d, 
 
     domain_pause(d);
 
+    old_ops = DOM2OP(d);
+    old_domdata = d->sched_priv;
+
     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(old_ops, remove_vcpu, v);
     }
-
-    SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
 
     d->cpupool = c;
     d->sched_priv = domdata;
@@ -276,6 +278,8 @@ int sched_move_domain(struct domain *d, 
     new_p = cpumask_first(c->cpu_valid);
     for_each_vcpu ( d, v )
     {
+        vcpudata = v->sched_priv;
+
         migrate_timer(&v->periodic_timer, new_p);
         migrate_timer(&v->singleshot_timer, new_p);
         migrate_timer(&v->poll_timer, new_p);
@@ -288,11 +292,15 @@ int sched_move_domain(struct domain *d, 
         new_p = cpumask_cycle(new_p, c->cpu_valid);
 
         SCHED_OP(c->sched, insert_vcpu, v);
+
+        SCHED_OP(old_ops, free_vdata, vcpudata);
     }
 
     domain_update_node_affinity(d);
 
     domain_unpause(d);
+
+    SCHED_OP(old_ops, free_domdata, old_domdata);
 
     xfree(vcpu_priv);
 

--===============1161369283527318403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1161369283527318403==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 09:54:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09: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 1UAdiK-0004IP-JR; Wed, 27 Feb 2013 09:54:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1UAdiJ-0004II-9s
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 09:54:15 +0000
Received: from [193.109.254.147:40514] by server-1.bemta-14.messagelabs.com id
	10/E3-29874-6C7DD215; Wed, 27 Feb 2013 09:54:14 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1361958851!9201590!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDIwMTc5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16734 invoked from network); 27 Feb 2013 09:54:11 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 09:54: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:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=HhxaH7eRezaud+T8m/8BXpQYNPCytjib0qhZA9GYY4qlt/lEPdbRZj+r
	NNWuXeYzovgAmbYGZka2AyzIYSSqmzYlFdLN0Y7QuwlPw0gp6ktIOxYIR
	KFh6UJNDQBwBJYXXOs4gACbB3c/stQDYYmU7tULlrbxN4BgP6L9JmBsah
	xny3NkB13WpE6imelUIysq2AQWfganD0K8RQmBktXKY8I9mHJI7f2QASu
	YvqfJmRME0Zx+JaCE3VWH5cEFgJIR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361958851; x=1393494851;
	h=mime-version:subject:message-id:date:from:to;
	bh=iseTBsEtXVZ6MIKR5Hfr0YKyp1AxoC+zMxls8S9zP1c=;
	b=uKRzTxzXa+ghzfCYFNwLgncI9iUAJ+7wpsLBcI3UVsqWpqkA7bPIW0Ov
	Cwx7rwlGRiSi3c5z5g5e8lNAxFEX0fOcDfJ5Q5DmCpxZ49yDth7aF++XQ
	6oJr91wv3tLFfcKyXBiMY8YOAYSdqwYEwjPLvFTfM8DUYTAo//VoMFJ2D
	ONLQrfaEQ8QWSTjUn7f8QL7pnOwJZOmGTbJH9wph0LB5LaHzvUBVSO17H
	lkmmpZm8qGR9XaCnCTBKv3coDxANb;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; d="scan'208";a="117148631"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 27 Feb 2013 10:53:54 +0100
X-IronPort-AV: E=Sophos;i="4.84,746,1355094000"; 
   d="scan'208";a="5128749"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 10:53:53 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id A14FA971313;
	Wed, 27 Feb 2013 10:53:54 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============1161369283527318403=="
MIME-Version: 1.0
X-Mercurial-Node: 04071eb1f2d29de3497f88b860b0584ca25e284e
Message-Id: <04071eb1f2d29de3497f.1361958220@nehalem1>
Date: Wed, 27 Feb 2013 10:43:40 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] (V2) Avoid stale pointer when moving domain to
	another cpupool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--===============1161369283527318403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.

Changes since V1:
- don't use an an own loop for freeing vcpu_data
- free old domain data after unpausing the domain
- simplify sched_init_vcpu (DOM2OP instead VCPU2OP)

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


1 file changed, 14 insertions(+), 6 deletions(-)
xen/common/schedule.c |   20 ++++++++++++++------



--===============1161369283527318403==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1361958197 -3600
# Node ID 04071eb1f2d29de3497f88b860b0584ca25e284e
# Parent  1d8c65aee03eaf15ce8ee50deb781b4308302b77
(V2) Avoid stale pointer when moving domain to another cpupool

When a domain is moved to another cpupool the scheduler private data pointers
in vcpu and domain structures must never point to an already freed memory
area.

While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.

Changes since V1:
- don't use an an own loop for freeing vcpu_data
- free old domain data after unpausing the domain
- simplify sched_init_vcpu (DOM2OP instead VCPU2OP)

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e -r 04071eb1f2d2 xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/schedule.c	Wed Feb 27 10:43:17 2013 +0100
@@ -220,7 +220,7 @@ int sched_init_vcpu(struct vcpu *v, unsi
     if ( v->sched_priv == NULL )
         return 1;
 
-    SCHED_OP(VCPU2OP(v), insert_vcpu, v);
+    SCHED_OP(DOM2OP(d), insert_vcpu, v);
 
     return 0;
 }
@@ -231,6 +231,9 @@ int sched_move_domain(struct domain *d, 
     unsigned int new_p;
     void **vcpu_priv;
     void *domdata;
+    void *vcpudata;
+    struct scheduler *old_ops;
+    void *old_domdata;
 
     domdata = SCHED_OP(c->sched, alloc_domdata, d);
     if ( domdata == NULL )
@@ -261,14 +264,13 @@ int sched_move_domain(struct domain *d, 
 
     domain_pause(d);
 
+    old_ops = DOM2OP(d);
+    old_domdata = d->sched_priv;
+
     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(old_ops, remove_vcpu, v);
     }
-
-    SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
 
     d->cpupool = c;
     d->sched_priv = domdata;
@@ -276,6 +278,8 @@ int sched_move_domain(struct domain *d, 
     new_p = cpumask_first(c->cpu_valid);
     for_each_vcpu ( d, v )
     {
+        vcpudata = v->sched_priv;
+
         migrate_timer(&v->periodic_timer, new_p);
         migrate_timer(&v->singleshot_timer, new_p);
         migrate_timer(&v->poll_timer, new_p);
@@ -288,11 +292,15 @@ int sched_move_domain(struct domain *d, 
         new_p = cpumask_cycle(new_p, c->cpu_valid);
 
         SCHED_OP(c->sched, insert_vcpu, v);
+
+        SCHED_OP(old_ops, free_vdata, vcpudata);
     }
 
     domain_update_node_affinity(d);
 
     domain_unpause(d);
+
+    SCHED_OP(old_ops, free_domdata, old_domdata);
 
     xfree(vcpu_priv);
 

--===============1161369283527318403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1161369283527318403==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 09:58:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09: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 1UAdm3-0004Si-9s; Wed, 27 Feb 2013 09:58:07 +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 1UAdm1-0004Sc-Lh
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:58:05 +0000
Received: from [85.158.139.211:39243] by server-10.bemta-5.messagelabs.com id
	12/3B-23714-CA8DD215; Wed, 27 Feb 2013 09:58:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361959077!17845611!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32048 invoked from network); 27 Feb 2013 09:57:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:57:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:57:57 +0000
Message-Id: <512DE6B302000078000C1631@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:57:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chen Gang" <gang.chen@asianux.com>
References: <512D90F2.9070200@asianux.com>
In-Reply-To: <512D90F2.9070200@asianux.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 05:52, Chen Gang <gang.chen@asianux.com> wrote:
>   if call xen_vbd_translate failed, the preq.dev will be not initialized.
>   so use blkif->vbd.pdevice instead (still better to print relative info).

You also could have mentioned that even before commit 
01c681d4c70d64cb72142a2823f27c4146a02e63 the value printed
here was bogus, as it was the guest provided value from
req->u.rw.handle rather than the actual device.

Jan

> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
>  drivers/block/xen-blkback/blkback.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index de1f319..6d1cc3d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -904,7 +904,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  		pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on dev=%04x\n",
>  			 operation == READ ? "read" : "write",
>  			 preq.sector_number,
> -			 preq.sector_number + preq.nr_sects, preq.dev);
> +			 preq.sector_number + preq.nr_sects,
> +			 blkif->vbd.pdevice);
>  		goto fail_response;
>  	}
>  
> -- 
> 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 Wed Feb 27 09:58:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 09: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 1UAdm3-0004Si-9s; Wed, 27 Feb 2013 09:58:07 +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 1UAdm1-0004Sc-Lh
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 09:58:05 +0000
Received: from [85.158.139.211:39243] by server-10.bemta-5.messagelabs.com id
	12/3B-23714-CA8DD215; Wed, 27 Feb 2013 09:58:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1361959077!17845611!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32048 invoked from network); 27 Feb 2013 09:57:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 09:57:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 09:57:57 +0000
Message-Id: <512DE6B302000078000C1631@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 09:57:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chen Gang" <gang.chen@asianux.com>
References: <512D90F2.9070200@asianux.com>
In-Reply-To: <512D90F2.9070200@asianux.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 05:52, Chen Gang <gang.chen@asianux.com> wrote:
>   if call xen_vbd_translate failed, the preq.dev will be not initialized.
>   so use blkif->vbd.pdevice instead (still better to print relative info).

You also could have mentioned that even before commit 
01c681d4c70d64cb72142a2823f27c4146a02e63 the value printed
here was bogus, as it was the guest provided value from
req->u.rw.handle rather than the actual device.

Jan

> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
>  drivers/block/xen-blkback/blkback.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index de1f319..6d1cc3d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -904,7 +904,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  		pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on dev=%04x\n",
>  			 operation == READ ? "read" : "write",
>  			 preq.sector_number,
> -			 preq.sector_number + preq.nr_sects, preq.dev);
> +			 preq.sector_number + preq.nr_sects,
> +			 blkif->vbd.pdevice);
>  		goto fail_response;
>  	}
>  
> -- 
> 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 Wed Feb 27 10:03:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAdqb-0004mz-4F; Wed, 27 Feb 2013 10:02: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 1UAdqZ-0004mr-T5
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:02:48 +0000
Received: from [85.158.137.99:54799] by server-10.bemta-3.messagelabs.com id
	EC/4D-19664-6C9DD215; Wed, 27 Feb 2013 10:02:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361959363!18145486!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25126 invoked from network); 27 Feb 2013 10:02:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:02:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:02:29 +0000
Message-Id: <512DE7C202000078000C164D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:02:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> This work around an issue when test via xen-mceinj tools.
> 
> when inject simulated error via xen-mceinj tools,
> status ADDRV/MISCV bits are simulated hence there is
> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
> We temporarily work around by not clean them until we have
> clean solution.

Excuse me, but - no. Changing the behavior for real MCE-s (which
you added) for the benefit of fixing injection is a no-go IMO. Or
are you telling us that after all that earlier change of yours is not
really necessary (in which case we could as well revert it).

Jan

> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> 
> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 00:34:22 2013 +0800
> @@ -144,10 +144,19 @@
>  
>      status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
>  
> +/*
> + * TODO: when inject simulated error via xen-mceinj tools,
> + * status ADDRV/MISCV bits are simulated hence there is
> + * potential risk of #GP if h/w not really support MCi_ADDR/MISC.
> + * We temporary work around by not clean them until we have
> + * clean solution.
> + */
> +#if 0
>      if (status & MCi_STATUS_ADDRV)
>          mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>      if (status & MCi_STATUS_MISCV)
>          mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
> +#endif
>  
>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
>  }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:03:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAdqb-0004mz-4F; Wed, 27 Feb 2013 10:02: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 1UAdqZ-0004mr-T5
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:02:48 +0000
Received: from [85.158.137.99:54799] by server-10.bemta-3.messagelabs.com id
	EC/4D-19664-6C9DD215; Wed, 27 Feb 2013 10:02:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361959363!18145486!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25126 invoked from network); 27 Feb 2013 10:02:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:02:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:02:29 +0000
Message-Id: <512DE7C202000078000C164D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:02:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> This work around an issue when test via xen-mceinj tools.
> 
> when inject simulated error via xen-mceinj tools,
> status ADDRV/MISCV bits are simulated hence there is
> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
> We temporarily work around by not clean them until we have
> clean solution.

Excuse me, but - no. Changing the behavior for real MCE-s (which
you added) for the benefit of fixing injection is a no-go IMO. Or
are you telling us that after all that earlier change of yours is not
really necessary (in which case we could as well revert it).

Jan

> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> 
> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 00:34:22 2013 +0800
> @@ -144,10 +144,19 @@
>  
>      status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
>  
> +/*
> + * TODO: when inject simulated error via xen-mceinj tools,
> + * status ADDRV/MISCV bits are simulated hence there is
> + * potential risk of #GP if h/w not really support MCi_ADDR/MISC.
> + * We temporary work around by not clean them until we have
> + * clean solution.
> + */
> +#if 0
>      if (status & MCi_STATUS_ADDRV)
>          mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>      if (status & MCi_STATUS_MISCV)
>          mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
> +#endif
>  
>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
>  }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:08:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAdw8-00050K-UD; Wed, 27 Feb 2013 10:08:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UAdw7-00050F-Mx
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:08:31 +0000
Received: from [85.158.143.99:12453] by server-3.bemta-4.messagelabs.com id
	28/5B-02186-E1BDD215; Wed, 27 Feb 2013 10:08:30 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361959709!19660846!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26641 invoked from network); 27 Feb 2013 10:08:29 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-8.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 10:08:29 -0000
Received: from x42d006.rwe-services.cz ([89.250.109.6] helo=[10.233.14.67])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UAdw1-0001hl-5R; Wed, 27 Feb 2013 11:08:25 +0100
Message-ID: <512DDB13.5000105@mfiala.net>
Date: Wed, 27 Feb 2013 11:08:19 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
	<20130226220100.GA22418@phenom.dumpdata.com>
	<512DD37102000078000C1569@nat28.tlf.novell.com>
In-Reply-To: <512DD37102000078000C1569@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Cc: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/27/2013 09:35 AM, Jan Beulich wrote:
>>>> On 26.02.13 at 23:01, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> The thing is is that native_machine_emergency_restart is not suppose
>> to be called. The baremetal machine_ops has that, but we over-write
>> it with our own and he should get:
>>
>>          .emergency_restart = xen_emergency_restart,
>>
>> ! So how did his .emergency_restart value get over-written by
>> native_machine_emergency_restart?
> 
> Indeed. So perhaps the -hardened tag indicates some patching
> having gone on that we're unaware of. Michal - without knowing
> what your kernel does, I don't think we can really help. And
> please remember that this is xen-devel, not xen-users, so we
> expect you to be able to do at least a minimal share of the work
> needed to find out what is going on. First step would probably
> be to try plain 3.7.5 (or subsequent 3.7.x).
> 
> Jan
> 

We are using gentoo hardened sources (kernel). Hardened-sources is based
on the official Linux kernel and is targeted at our users running Gentoo
on server systems. It provides patches for the various subprojects of
Gentoo Hardened (such as support for LSM/SELinux and grsecurity),
together with stability/security-enhancements.
See http://www.gentoo.org/doc/en/gentoo-kernel.xml

I will try gentoo-sources (lightly patched to fix security problems,
kernel bugs, and to increase compatibility with the more uncommon system
architectures) and vanilla-sources (official kernel sources released on
http://www.kernel.org/)

Thanks

Michal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:08:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAdw8-00050K-UD; Wed, 27 Feb 2013 10:08:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fiala@mfiala.net>) id 1UAdw7-00050F-Mx
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:08:31 +0000
Received: from [85.158.143.99:12453] by server-3.bemta-4.messagelabs.com id
	28/5B-02186-E1BDD215; Wed, 27 Feb 2013 10:08:30 +0000
X-Env-Sender: fiala@mfiala.net
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361959709!19660846!1
X-Originating-IP: [194.79.52.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26641 invoked from network); 27 Feb 2013 10:08:29 -0000
Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12)
	by server-8.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 10:08:29 -0000
Received: from x42d006.rwe-services.cz ([89.250.109.6] helo=[10.233.14.67])
	by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.69) (envelope-from <fiala@mfiala.net>)
	id 1UAdw1-0001hl-5R; Wed, 27 Feb 2013 11:08:25 +0100
Message-ID: <512DDB13.5000105@mfiala.net>
Date: Wed, 27 Feb 2013 11:08:19 +0100
From: Michal Fiala <fiala@mfiala.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
	<20130226220100.GA22418@phenom.dumpdata.com>
	<512DD37102000078000C1569@nat28.tlf.novell.com>
In-Reply-To: <512DD37102000078000C1569@nat28.tlf.novell.com>
X-Enigmail-Version: 1.5
Cc: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/27/2013 09:35 AM, Jan Beulich wrote:
>>>> On 26.02.13 at 23:01, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> The thing is is that native_machine_emergency_restart is not suppose
>> to be called. The baremetal machine_ops has that, but we over-write
>> it with our own and he should get:
>>
>>          .emergency_restart = xen_emergency_restart,
>>
>> ! So how did his .emergency_restart value get over-written by
>> native_machine_emergency_restart?
> 
> Indeed. So perhaps the -hardened tag indicates some patching
> having gone on that we're unaware of. Michal - without knowing
> what your kernel does, I don't think we can really help. And
> please remember that this is xen-devel, not xen-users, so we
> expect you to be able to do at least a minimal share of the work
> needed to find out what is going on. First step would probably
> be to try plain 3.7.5 (or subsequent 3.7.x).
> 
> Jan
> 

We are using gentoo hardened sources (kernel). Hardened-sources is based
on the official Linux kernel and is targeted at our users running Gentoo
on server systems. It provides patches for the various subprojects of
Gentoo Hardened (such as support for LSM/SELinux and grsecurity),
together with stability/security-enhancements.
See http://www.gentoo.org/doc/en/gentoo-kernel.xml

I will try gentoo-sources (lightly patched to fix security problems,
kernel bugs, and to increase compatibility with the more uncommon system
architectures) and vanilla-sources (official kernel sources released on
http://www.kernel.org/)

Thanks

Michal

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:09:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:09: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 1UAdwT-00051a-Aq; Wed, 27 Feb 2013 10:08:53 +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 1UAdwR-00051Q-DG
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:08:51 +0000
Received: from [85.158.139.211:40542] by server-8.bemta-5.messagelabs.com id
	C0/DB-05790-23BDD215; Wed, 27 Feb 2013 10:08:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361959693!19416469!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22975 invoked from network); 27 Feb 2013 10:08:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:08:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:08:13 +0000
Message-Id: <512DE91A02000078000C1667@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:08:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <04071eb1f2d29de3497f.1361958220@nehalem1>
In-Reply-To: <04071eb1f2d29de3497f.1361958220@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] (V2) Avoid stale pointer when moving domain
 to another cpupool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 10:43, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> When a domain is moved to another cpupool the scheduler private data pointers
> in vcpu and domain structures must never point to an already freed memory
> area.
> 
> While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.
> 
> Changes since V1:
> - don't use an an own loop for freeing vcpu_data
> - free old domain data after unpausing the domain
> - simplify sched_init_vcpu (DOM2OP instead VCPU2OP)
> 
> Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

Looks good to me now, but will want to be ack-ed by George.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:09:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:09: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 1UAdwT-00051a-Aq; Wed, 27 Feb 2013 10:08:53 +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 1UAdwR-00051Q-DG
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:08:51 +0000
Received: from [85.158.139.211:40542] by server-8.bemta-5.messagelabs.com id
	C0/DB-05790-23BDD215; Wed, 27 Feb 2013 10:08:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361959693!19416469!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22975 invoked from network); 27 Feb 2013 10:08:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:08:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:08:13 +0000
Message-Id: <512DE91A02000078000C1667@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:08:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <04071eb1f2d29de3497f.1361958220@nehalem1>
In-Reply-To: <04071eb1f2d29de3497f.1361958220@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] (V2) Avoid stale pointer when moving domain
 to another cpupool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 10:43, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> When a domain is moved to another cpupool the scheduler private data pointers
> in vcpu and domain structures must never point to an already freed memory
> area.
> 
> While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.
> 
> Changes since V1:
> - don't use an an own loop for freeing vcpu_data
> - free old domain data after unpausing the domain
> - simplify sched_init_vcpu (DOM2OP instead VCPU2OP)
> 
> Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

Looks good to me now, but will want to be ack-ed by George.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:29:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:29: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 1UAeGN-0005RQ-Is; Wed, 27 Feb 2013 10:29:27 +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 1UAeGM-0005RL-BC
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:29:26 +0000
Received: from [85.158.139.83:50096] by server-15.bemta-5.messagelabs.com id
	3C/34-22815-500ED215; Wed, 27 Feb 2013 10:29:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361960960!23969566!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 27 Feb 2013 10:29:21 -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; 27 Feb 2013 10:29:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:29:20 +0000
Message-Id: <512DEE0D02000078000C167E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:29:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
	<512DD6EB02000078000C159C@nat28.tlf.novell.com>
	<1361957122.11431.40.camel@dagon.hellion.org.uk>
In-Reply-To: <1361957122.11431.40.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim\(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir.xen@gmail.com>, Xi Wang <xi@mit.edu>
Subject: Re: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86:
 fix null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-27 at 08:50 +0000, Jan Beulich wrote:
>> >>> On 26.02.13 at 18:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> > Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in 
>> > intel_get_extended_msrs()"):
>> >> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
>> >> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.
>> > 
>> > Really I think we shouldn't be writing out these kind of memsets.
>> > They're too error-prone.  We should have a macro, perhaps like this:
>> > 
>> >   #define FILLZERO(object) memset(&(object), 0, sizeof(object))
>> > 
>> > Likewise a copy macro.
>> 
>> Unfortunately that wouldn't be usable in all cases (arrays passed
>> to functions), and hence I'm not really confident this would be a
>> good move. But yes, I considered what you suggest a number of
>> times already, but dropped the idea each time because of its lack
>> of general applicability.
>> 
>> I'm afraid we just have to live with the bad side effects of the
>> power C provides.
> 
> In this specific case perhaps x86_mcinfo_reserve() should zero the
> buffer instead of each caller having to do the right thing? Most callers
> have a memset, a couple immediately fill in the buffer instead of
> zeroing it, but this isn't a hot path, is it?

Yes, I think we should. I'll prepare a patch. Nevertheless, the
original patch is desirable to have as a separate one, as that's
what I would prefer for backporting.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:29:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:29: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 1UAeGN-0005RQ-Is; Wed, 27 Feb 2013 10:29:27 +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 1UAeGM-0005RL-BC
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:29:26 +0000
Received: from [85.158.139.83:50096] by server-15.bemta-5.messagelabs.com id
	3C/34-22815-500ED215; Wed, 27 Feb 2013 10:29:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361960960!23969566!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 27 Feb 2013 10:29:21 -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; 27 Feb 2013 10:29:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:29:20 +0000
Message-Id: <512DEE0D02000078000C167E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:29:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
	<512DD6EB02000078000C159C@nat28.tlf.novell.com>
	<1361957122.11431.40.camel@dagon.hellion.org.uk>
In-Reply-To: <1361957122.11431.40.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim\(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir.xen@gmail.com>, Xi Wang <xi@mit.edu>
Subject: Re: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86:
 fix null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 10:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-27 at 08:50 +0000, Jan Beulich wrote:
>> >>> On 26.02.13 at 18:08, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> > Xi Wang writes ("[Xen-devel] [PATCH] x86: fix null pointer dereference in 
>> > intel_get_extended_msrs()"):
>> >> `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent
>> >> null pointer dereference.  Replace `&mc_ext' with `mc_ext'.
>> > 
>> > Really I think we shouldn't be writing out these kind of memsets.
>> > They're too error-prone.  We should have a macro, perhaps like this:
>> > 
>> >   #define FILLZERO(object) memset(&(object), 0, sizeof(object))
>> > 
>> > Likewise a copy macro.
>> 
>> Unfortunately that wouldn't be usable in all cases (arrays passed
>> to functions), and hence I'm not really confident this would be a
>> good move. But yes, I considered what you suggest a number of
>> times already, but dropped the idea each time because of its lack
>> of general applicability.
>> 
>> I'm afraid we just have to live with the bad side effects of the
>> power C provides.
> 
> In this specific case perhaps x86_mcinfo_reserve() should zero the
> buffer instead of each caller having to do the right thing? Most callers
> have a memset, a couple immediately fill in the buffer instead of
> zeroing it, but this isn't a hot path, is it?

Yes, I think we should. I'll prepare a patch. Nevertheless, the
original patch is desirable to have as a separate one, as that's
what I would prefer for backporting.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:34:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:34: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 1UAeKy-0005eE-Bn; Wed, 27 Feb 2013 10:34: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 1UAeKx-0005e7-0N
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:34:11 +0000
Received: from [85.158.137.99:42553] by server-16.bemta-3.messagelabs.com id
	A1/BF-20692-221ED215; Wed, 27 Feb 2013 10:34:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361961245!12692898!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32698 invoked from network); 27 Feb 2013 10:34:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:34:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1945867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 10:34: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.297.1; Wed, 27 Feb 2013 10:34:05 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAeKq-0005cQ-QT;
	Wed, 27 Feb 2013 10:34:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAeKq-0004Wb-La;
	Wed, 27 Feb 2013 10:34:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16754-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 10:34:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16754: 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 16754 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16754/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226
 build-i386-pvops              4 kernel-build              fail REGR. vs. 16226
 build-i386                    4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-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-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            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-qemut-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 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-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-win-vcpus1  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-qemut-rhel6hvm-intel  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-xl-qemut-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 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-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 6c7bb5a198de5cfd3f720e2376c7aa184d61329e
Author: Keir Fraser <keir@xen.org>
Date:   Tue Feb 26 16:51:28 2013 +0000

    MAINTAINERS: Remove Jeremy from pv_ops maintainer list.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:34:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:34: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 1UAeKy-0005eE-Bn; Wed, 27 Feb 2013 10:34: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 1UAeKx-0005e7-0N
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:34:11 +0000
Received: from [85.158.137.99:42553] by server-16.bemta-3.messagelabs.com id
	A1/BF-20692-221ED215; Wed, 27 Feb 2013 10:34:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361961245!12692898!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32698 invoked from network); 27 Feb 2013 10:34:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:34:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1945867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 10:34: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.297.1; Wed, 27 Feb 2013 10:34:05 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAeKq-0005cQ-QT;
	Wed, 27 Feb 2013 10:34:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAeKq-0004Wb-La;
	Wed, 27 Feb 2013 10:34:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16754-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 10:34:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16754: 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 16754 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16754/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 16226
 build-i386-pvops              4 kernel-build              fail REGR. vs. 16226
 build-i386                    4 xen-build                 fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

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-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-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            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-qemut-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 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-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-win-vcpus1  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-qemut-rhel6hvm-intel  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-xl-qemut-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-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-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win     1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 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-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-qemut-win-vcpus1                             blocked 
 test-amd64-i386-xl-qemut-win-vcpus1                          blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    blocked 
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 6c7bb5a198de5cfd3f720e2376c7aa184d61329e
Author: Keir Fraser <keir@xen.org>
Date:   Tue Feb 26 16:51:28 2013 +0000

    MAINTAINERS: Remove Jeremy from pv_ops maintainer list.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:38:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAePE-0005oT-6y; Wed, 27 Feb 2013 10:38:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAePB-0005oO-Q6
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:38:34 +0000
Received: from [85.158.139.83:14439] by server-14.bemta-5.messagelabs.com id
	13/C1-13158-822ED215; Wed, 27 Feb 2013 10:38:32 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361961473!17909643!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1NjQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13856 invoked from network); 27 Feb 2013 10:37:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-182.messagelabs.com with SMTP;
	27 Feb 2013 10:37:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 27 Feb 2013 02:37:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="262036323"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 27 Feb 2013 02:37:51 -0800
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 02:37:50 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 02:37:50 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 18:37:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFNGLqZTiEd/FTjyR1sPJXJqZr5iNfaZQ
Date: Wed, 27 Feb 2013 10:37:42 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
In-Reply-To: <512DE7C202000078000C164D@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> This work around an issue when test via xen-mceinj tools.
>> 
>> when inject simulated error via xen-mceinj tools,
>> status ADDRV/MISCV bits are simulated hence there is
>> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>> We temporarily work around by not clean them until we have
>> clean solution.
> 
> Excuse me, but - no. Changing the behavior for real MCE-s (which
> you added) for the benefit of fixing injection is a no-go IMO. Or
> are you telling us that after all that earlier change of yours is not
> really necessary (in which case we could as well revert it).
> 
> Jan
> 

The reason of the former patch to clear MCi_ADDR/MISC is that it's recommended by Intel SDM:
		LOG MCA REGISTER:
		SAVE IA32_MCi_STATUS;
		If MISCV in IA32_MCi_STATUS
		THEN
			SAVE IA32_MCi_MISC;
		FI;
		IF ADDRV in IA32_MCi_STATUS
		THEN
			SAVE IA32_MCi_ADDR;
		FI;
		IF CLEAR_MC_BANK = TRUE
		THEN
			SET all 0 to IA32_MCi_STATUS;
		If MISCV in IA32_MCi_STATUS
		THEN
			SET all 0 to IA32_MCi_MISC;
		FI;
		IF ADDRV in IA32_MCi_STATUS
		THEN
			SET all 0 to IA32_MCi_ADDR;
		FI;

For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real error occur (which indicated by MCi_STATUS), so only clear MCi_STATUS at mce handler is an acceptable work around -- after all, to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.

Thanks,
Jinsong

>> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
>> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
>> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 00:34:22 2013 +0800
>> @@ -144,10 +144,19 @@ 
>> 
>>      status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
>> 
>> +/*
>> + * TODO: when inject simulated error via xen-mceinj tools,
>> + * status ADDRV/MISCV bits are simulated hence there is
>> + * potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>> + * We temporary work around by not clean them until we have + *
>> clean solution. + */
>> +#if 0
>>      if (status & MCi_STATUS_ADDRV)
>>          mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>>      if (status & MCi_STATUS_MISCV)
>>          mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL); +#endif
>> 
>>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
>>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:38:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAePE-0005oT-6y; Wed, 27 Feb 2013 10:38:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAePB-0005oO-Q6
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:38:34 +0000
Received: from [85.158.139.83:14439] by server-14.bemta-5.messagelabs.com id
	13/C1-13158-822ED215; Wed, 27 Feb 2013 10:38:32 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361961473!17909643!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1NjQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13856 invoked from network); 27 Feb 2013 10:37:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-182.messagelabs.com with SMTP;
	27 Feb 2013 10:37:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 27 Feb 2013 02:37:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="262036323"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 27 Feb 2013 02:37:51 -0800
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 02:37:50 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 02:37:50 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 18:37:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFNGLqZTiEd/FTjyR1sPJXJqZr5iNfaZQ
Date: Wed, 27 Feb 2013 10:37:42 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
In-Reply-To: <512DE7C202000078000C164D@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> This work around an issue when test via xen-mceinj tools.
>> 
>> when inject simulated error via xen-mceinj tools,
>> status ADDRV/MISCV bits are simulated hence there is
>> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>> We temporarily work around by not clean them until we have
>> clean solution.
> 
> Excuse me, but - no. Changing the behavior for real MCE-s (which
> you added) for the benefit of fixing injection is a no-go IMO. Or
> are you telling us that after all that earlier change of yours is not
> really necessary (in which case we could as well revert it).
> 
> Jan
> 

The reason of the former patch to clear MCi_ADDR/MISC is that it's recommended by Intel SDM:
		LOG MCA REGISTER:
		SAVE IA32_MCi_STATUS;
		If MISCV in IA32_MCi_STATUS
		THEN
			SAVE IA32_MCi_MISC;
		FI;
		IF ADDRV in IA32_MCi_STATUS
		THEN
			SAVE IA32_MCi_ADDR;
		FI;
		IF CLEAR_MC_BANK = TRUE
		THEN
			SET all 0 to IA32_MCi_STATUS;
		If MISCV in IA32_MCi_STATUS
		THEN
			SET all 0 to IA32_MCi_MISC;
		FI;
		IF ADDRV in IA32_MCi_STATUS
		THEN
			SET all 0 to IA32_MCi_ADDR;
		FI;

For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real error occur (which indicated by MCi_STATUS), so only clear MCi_STATUS at mce handler is an acceptable work around -- after all, to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.

Thanks,
Jinsong

>> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
>> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
>> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 00:34:22 2013 +0800
>> @@ -144,10 +144,19 @@ 
>> 
>>      status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
>> 
>> +/*
>> + * TODO: when inject simulated error via xen-mceinj tools,
>> + * status ADDRV/MISCV bits are simulated hence there is
>> + * potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>> + * We temporary work around by not clean them until we have + *
>> clean solution. + */
>> +#if 0
>>      if (status & MCi_STATUS_ADDRV)
>>          mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>>      if (status & MCi_STATUS_MISCV)
>>          mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL); +#endif
>> 
>>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
>>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:46:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAeWB-0006Ia-6D; Wed, 27 Feb 2013 10:45:47 +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 1UAeW9-0006IS-FC
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:45:45 +0000
Received: from [85.158.137.99:42601] by server-2.bemta-3.messagelabs.com id
	16/20-05208-8D3ED215; Wed, 27 Feb 2013 10:45:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361961942!18343823!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18252 invoked from network); 27 Feb 2013 10:45:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:45:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:45:36 +0000
Message-Id: <512DF1DF02000078000C16A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:45:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chen Gang" <gang.chen@asianux.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
	<512DE213.3050001@asianux.com>
In-Reply-To: <512DE213.3050001@asianux.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI3LjAyLjEzIGF0IDExOjM4LCBDaGVuIEdhbmcgPGdhbmcuY2hlbkBhc2lhbnV4LmNv
bT4gd3JvdGU6Cj4g5LqOIDIwMTPlubQwMuaciDI35pelIDE3OjU3LCBKYW4gQmV1bGljaCDlhpnp
gZM6Cj4+IFlvdSBhbHNvIGNvdWxkIGhhdmUgbWVudGlvbmVkIHRoYXQgZXZlbiBiZWZvcmUgY29t
bWl0IAo+PiAwMWM2ODFkNGM3MGQ2NGNiNzIxNDJhMjgyM2YyN2M0MTQ2YTAyZTYzIHRoZSB2YWx1
ZSBwcmludGVkCj4+IGhlcmUgd2FzIGJvZ3VzLCBhcyBpdCB3YXMgdGhlIGd1ZXN0IHByb3ZpZGVk
IHZhbHVlIGZyb20KPj4gcmVxLT51LnJ3LmhhbmRsZSByYXRoZXIgdGhhbiB0aGUgYWN0dWFsIGRl
dmljZS4KPiAKPiAgIHBhcmRvbiA/Cj4gCj4gICBJIGd1ZXNzIHdoYXQgeW91IHNhaWQgaXMgOgo+
ICAgICBteSBwYXRjaCBzZWVtcyBvaywgYnV0IHRoZSBjb21tZW50cyBuZWVkIGltcHJvdmluZy4K
PiAgICAgbmVlZCBhZGQgImFkZGl0aW9uYWwgaW5mbyIgaW4gY29tbWVudHM6Cj4gICAgICAgImJl
Zm9yZSBjb21taXQgMDFjNjgxZDRjNzBkNjRjYjcyMTQyYTI4MjNmMjdjNDE0NmEwMmU2Mwo+ICAg
ICAgICB0aGUgdmFsdWUgcHJpbnRlZCBoZXJlIHdhcyBib2d1cywgYXMgaXQgd2FzIHRoZSBndWVz
dAo+ICAgICAgICBwcm92aWRlZCB2YWx1ZSBmcm9tIHJlcS0+dS5ydy5oYW5kbGUgcmF0aGVyIHRo
YW4gdGhlCj4gICAgICAgIGFjdHVhbCBkZXZpY2UiLgo+IAo+ICAgaXMgaXQgY29ycmVjdCA/CgpZ
ZXMgKGFuZCB5b3UgbWlnaHQgaGF2ZSBtaXNzZWQgdGhlIEFDSyB0aGF0IEkgaGFkIGFscmVhZHkg
c2VudApiZWZvcmUgdGhpcyByZXBseSAtIHRoYXQgbWFpbCBnb3QgYm91bmNlZCBmb3IgeW91ciBh
ZGRyZXNzKS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:46:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAeWB-0006Ia-6D; Wed, 27 Feb 2013 10:45:47 +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 1UAeW9-0006IS-FC
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:45:45 +0000
Received: from [85.158.137.99:42601] by server-2.bemta-3.messagelabs.com id
	16/20-05208-8D3ED215; Wed, 27 Feb 2013 10:45:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361961942!18343823!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18252 invoked from network); 27 Feb 2013 10:45:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:45:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:45:36 +0000
Message-Id: <512DF1DF02000078000C16A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:45:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chen Gang" <gang.chen@asianux.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
	<512DE213.3050001@asianux.com>
In-Reply-To: <512DE213.3050001@asianux.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI3LjAyLjEzIGF0IDExOjM4LCBDaGVuIEdhbmcgPGdhbmcuY2hlbkBhc2lhbnV4LmNv
bT4gd3JvdGU6Cj4g5LqOIDIwMTPlubQwMuaciDI35pelIDE3OjU3LCBKYW4gQmV1bGljaCDlhpnp
gZM6Cj4+IFlvdSBhbHNvIGNvdWxkIGhhdmUgbWVudGlvbmVkIHRoYXQgZXZlbiBiZWZvcmUgY29t
bWl0IAo+PiAwMWM2ODFkNGM3MGQ2NGNiNzIxNDJhMjgyM2YyN2M0MTQ2YTAyZTYzIHRoZSB2YWx1
ZSBwcmludGVkCj4+IGhlcmUgd2FzIGJvZ3VzLCBhcyBpdCB3YXMgdGhlIGd1ZXN0IHByb3ZpZGVk
IHZhbHVlIGZyb20KPj4gcmVxLT51LnJ3LmhhbmRsZSByYXRoZXIgdGhhbiB0aGUgYWN0dWFsIGRl
dmljZS4KPiAKPiAgIHBhcmRvbiA/Cj4gCj4gICBJIGd1ZXNzIHdoYXQgeW91IHNhaWQgaXMgOgo+
ICAgICBteSBwYXRjaCBzZWVtcyBvaywgYnV0IHRoZSBjb21tZW50cyBuZWVkIGltcHJvdmluZy4K
PiAgICAgbmVlZCBhZGQgImFkZGl0aW9uYWwgaW5mbyIgaW4gY29tbWVudHM6Cj4gICAgICAgImJl
Zm9yZSBjb21taXQgMDFjNjgxZDRjNzBkNjRjYjcyMTQyYTI4MjNmMjdjNDE0NmEwMmU2Mwo+ICAg
ICAgICB0aGUgdmFsdWUgcHJpbnRlZCBoZXJlIHdhcyBib2d1cywgYXMgaXQgd2FzIHRoZSBndWVz
dAo+ICAgICAgICBwcm92aWRlZCB2YWx1ZSBmcm9tIHJlcS0+dS5ydy5oYW5kbGUgcmF0aGVyIHRo
YW4gdGhlCj4gICAgICAgIGFjdHVhbCBkZXZpY2UiLgo+IAo+ICAgaXMgaXQgY29ycmVjdCA/CgpZ
ZXMgKGFuZCB5b3UgbWlnaHQgaGF2ZSBtaXNzZWQgdGhlIEFDSyB0aGF0IEkgaGFkIGFscmVhZHkg
c2VudApiZWZvcmUgdGhpcyByZXBseSAtIHRoYXQgbWFpbCBnb3QgYm91bmNlZCBmb3IgeW91ciBh
ZGRyZXNzKS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:46:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAeWr-0006LW-Kw; Wed, 27 Feb 2013 10:46:29 +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 1UAeWq-0006LK-RV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:46:29 +0000
Received: from [85.158.137.99:60712] by server-1.bemta-3.messagelabs.com id
	7B/90-13706-304ED215; Wed, 27 Feb 2013 10:46:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361961982!13208453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28825 invoked from network); 27 Feb 2013 10:46:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:46:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:46:08 +0000
Message-Id: <512DF1FE02000078000C16A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:46:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part093978FE.0__="
Subject: [Xen-devel] [PATCH] x86: make x86_mcinfo_reserve() clear its result
	buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part093978FE.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... instead of all but one of its callers.

Also adjust the corresponding sizeof() expressions to specify the
pointed-to type of the result variable rather than the literal type
(so that a type change of the variable will imply the size to get
adjusted too).

Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -62,14 +62,13 @@ amd_f10_handler(struct mc_info *mi, uint
 	if (!(status & MCi_STATUS_MISCV))
 		return NULL;
=20
-	mc_ext =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));
+	mc_ext =3D x86_mcinfo_reserve(mi, sizeof(*mc_ext));
 	if (!mc_ext)
 	{
 		mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
 		return NULL;
 	}
=20
-	memset(mc_ext, 0, sizeof(*mc_ext));
 	mc_ext->common.type =3D MC_TYPE_EXTENDED;
 	mc_ext->common.size =3D sizeof(*mc_ext);
 	mc_ext->mc_msrs =3D 3;
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -13,14 +13,12 @@ mci_action_add_pageoffline(int bank, str
     if (!mi)
         return NULL;
=20
-    rec =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_recovery));
+    rec =3D x86_mcinfo_reserve(mi, sizeof(*rec));
     if (!rec) {
         mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
         return NULL;
     }
=20
-    memset(rec, 0, sizeof(struct mcinfo_recovery));
-
     rec->common.type =3D MC_TYPE_RECOVERY;
     rec->common.size =3D sizeof(*rec);
     rec->mc_bank =3D bank;
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -200,14 +200,13 @@ static void mca_init_bank(enum mca_sourc
     if (!mi)
         return;
=20
-    mib =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+    mib =3D x86_mcinfo_reserve(mi, sizeof(*mib));
     if (!mib)
     {
         mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
         return;
     }
=20
-    memset(mib, 0, sizeof (struct mcinfo_bank));
     mib->mc_status =3D mca_rdmsr(MSR_IA32_MCx_STATUS(bank));
=20
     mib->common.type =3D MC_TYPE_BANK;
@@ -247,7 +246,6 @@ static int mca_init_global(uint32_t flag
     struct domain *d;
=20
     /* Set global information */
-    memset(mig, 0, sizeof (struct mcinfo_global));
     mig->common.type =3D MC_TYPE_GLOBAL;
     mig->common.size =3D sizeof (struct mcinfo_global);
     status =3D mca_rdmsr(MSR_IA32_MCG_STATUS);
@@ -349,7 +347,7 @@ mcheck_mca_logout(enum mca_source who, s
             if ( (mctc =3D mctelem_reserve(which)) !=3D NULL ) {
                 mci =3D mctelem_dataptr(mctc);
                 mcinfo_clear(mci);
-                mig =3D x86_mcinfo_reserve(mci, sizeof(struct mcinfo_globa=
l));
+                mig =3D x86_mcinfo_reserve(mci, sizeof(*mig));
                 /* mc_info should at least hold up the global information =
*/
                 ASSERT(mig);
                 mca_init_global(mc_flags, mig);
@@ -820,7 +818,7 @@ void *x86_mcinfo_reserve(struct mc_info=20
     /* there's enough space. add entry. */
     x86_mcinfo_nentries(mi)++;
=20
-    return mic_index;
+    return memset(mic_index, 0, size);
 }
=20
 void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -192,7 +192,7 @@ intel_get_extended_msrs(struct mcinfo_gl
             !(mig->mc_gstatus & MCG_STATUS_EIPV))
         return NULL;
=20
-    mc_ext =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));
+    mc_ext =3D x86_mcinfo_reserve(mi, sizeof(*mc_ext));
     if (!mc_ext)
     {
         mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
@@ -200,7 +200,6 @@ intel_get_extended_msrs(struct mcinfo_gl
     }
=20
     /* this function will called when CAP(9).MCG_EXT_P =3D 1 */
-    memset(mc_ext, 0, sizeof(*mc_ext));
     mc_ext->common.type =3D MC_TYPE_EXTENDED;
     mc_ext->common.size =3D sizeof(struct mcinfo_extended);
=20




--=__Part093978FE.0__=
Content-Type: text/plain; name="x86-mcinfo-reserve-clear.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mcinfo-reserve-clear.patch"

x86: make x86_mcinfo_reserve() clear its result buffer=0A=0A... instead of =
all but one of its callers.=0A=0AAlso adjust the corresponding sizeof() =
expressions to specify the=0Apointed-to type of the result variable rather =
than the literal type=0A(so that a type change of the variable will imply =
the size to get=0Aadjusted too).=0A=0ASuggested-by: Ian Campbell <Ian.Campb=
ell@citrix.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/cpu/mcheck/amd_f10.c=0A+++ b/xen/arch/x86/cpu/mcheck/amd_f10=
.c=0A@@ -62,14 +62,13 @@ amd_f10_handler(struct mc_info *mi, uint=0A 	if =
(!(status & MCi_STATUS_MISCV))=0A 		return NULL;=0A =0A-	=
mc_ext =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));=0A+	=
mc_ext =3D x86_mcinfo_reserve(mi, sizeof(*mc_ext));=0A 	if (!mc_ext)=0A 	=
{=0A 		mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;=0A 		=
return NULL;=0A 	}=0A =0A-	memset(mc_ext, 0, sizeof(*mc_ext));=
=0A 	mc_ext->common.type =3D MC_TYPE_EXTENDED;=0A 	mc_ext->common.size=
 =3D sizeof(*mc_ext);=0A 	mc_ext->mc_msrs =3D 3;=0A--- a/xen/arch/x86=
/cpu/mcheck/mcaction.c=0A+++ b/xen/arch/x86/cpu/mcheck/mcaction.c=0A@@ =
-13,14 +13,12 @@ mci_action_add_pageoffline(int bank, str=0A     if =
(!mi)=0A         return NULL;=0A =0A-    rec =3D x86_mcinfo_reserve(mi, =
sizeof(struct mcinfo_recovery));=0A+    rec =3D x86_mcinfo_reserve(mi, =
sizeof(*rec));=0A     if (!rec) {=0A         mi->flags |=3D MCINFO_FLAGS_UN=
COMPLETE;=0A         return NULL;=0A     }=0A =0A-    memset(rec, 0, =
sizeof(struct mcinfo_recovery));=0A-=0A     rec->common.type =3D MC_TYPE_RE=
COVERY;=0A     rec->common.size =3D sizeof(*rec);=0A     rec->mc_bank =3D =
bank;=0A--- a/xen/arch/x86/cpu/mcheck/mce.c=0A+++ b/xen/arch/x86/cpu/mcheck=
/mce.c=0A@@ -200,14 +200,13 @@ static void mca_init_bank(enum mca_sourc=0A =
    if (!mi)=0A         return;=0A =0A-    mib =3D x86_mcinfo_reserve(mi, =
sizeof(struct mcinfo_bank));=0A+    mib =3D x86_mcinfo_reserve(mi, =
sizeof(*mib));=0A     if (!mib)=0A     {=0A         mi->flags |=3D =
MCINFO_FLAGS_UNCOMPLETE;=0A         return;=0A     }=0A =0A-    memset(mib,=
 0, sizeof (struct mcinfo_bank));=0A     mib->mc_status =3D mca_rdmsr(MSR_I=
A32_MCx_STATUS(bank));=0A =0A     mib->common.type =3D MC_TYPE_BANK;=0A@@ =
-247,7 +246,6 @@ static int mca_init_global(uint32_t flag=0A     struct =
domain *d;=0A =0A     /* Set global information */=0A-    memset(mig, 0, =
sizeof (struct mcinfo_global));=0A     mig->common.type =3D MC_TYPE_GLOBAL;=
=0A     mig->common.size =3D sizeof (struct mcinfo_global);=0A     status =
=3D mca_rdmsr(MSR_IA32_MCG_STATUS);=0A@@ -349,7 +347,7 @@ mcheck_mca_logout=
(enum mca_source who, s=0A             if ( (mctc =3D mctelem_reserve(which=
)) !=3D NULL ) {=0A                 mci =3D mctelem_dataptr(mctc);=0A      =
           mcinfo_clear(mci);=0A-                mig =3D x86_mcinfo_reserve=
(mci, sizeof(struct mcinfo_global));=0A+                mig =3D x86_mcinfo_=
reserve(mci, sizeof(*mig));=0A                 /* mc_info should at least =
hold up the global information */=0A                 ASSERT(mig);=0A       =
          mca_init_global(mc_flags, mig);=0A@@ -820,7 +818,7 @@ void =
*x86_mcinfo_reserve(struct mc_info =0A     /* there's enough space. add =
entry. */=0A     x86_mcinfo_nentries(mi)++;=0A =0A-    return mic_index;=0A=
+    return memset(mic_index, 0, size);=0A }=0A =0A void *x86_mcinfo_add(st=
ruct mc_info *mi, void *mcinfo)=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=
=0A+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c=0A@@ -192,7 +192,7 @@ =
intel_get_extended_msrs(struct mcinfo_gl=0A             !(mig->mc_gstatus =
& MCG_STATUS_EIPV))=0A         return NULL;=0A =0A-    mc_ext =3D =
x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));=0A+    mc_ext =3D =
x86_mcinfo_reserve(mi, sizeof(*mc_ext));=0A     if (!mc_ext)=0A     {=0A   =
      mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;=0A@@ -200,7 +200,6 @@ =
intel_get_extended_msrs(struct mcinfo_gl=0A     }=0A =0A     /* this =
function will called when CAP(9).MCG_EXT_P =3D 1 */=0A-    memset(mc_ext, =
0, sizeof(*mc_ext));=0A     mc_ext->common.type =3D MC_TYPE_EXTENDED;=0A   =
  mc_ext->common.size =3D sizeof(struct mcinfo_extended);=0A =0A
--=__Part093978FE.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

--=__Part093978FE.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:46:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAeWr-0006LW-Kw; Wed, 27 Feb 2013 10:46:29 +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 1UAeWq-0006LK-RV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:46:29 +0000
Received: from [85.158.137.99:60712] by server-1.bemta-3.messagelabs.com id
	7B/90-13706-304ED215; Wed, 27 Feb 2013 10:46:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361961982!13208453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28825 invoked from network); 27 Feb 2013 10:46:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:46:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:46:08 +0000
Message-Id: <512DF1FE02000078000C16A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:46:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part093978FE.0__="
Subject: [Xen-devel] [PATCH] x86: make x86_mcinfo_reserve() clear its result
	buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part093978FE.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... instead of all but one of its callers.

Also adjust the corresponding sizeof() expressions to specify the
pointed-to type of the result variable rather than the literal type
(so that a type change of the variable will imply the size to get
adjusted too).

Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -62,14 +62,13 @@ amd_f10_handler(struct mc_info *mi, uint
 	if (!(status & MCi_STATUS_MISCV))
 		return NULL;
=20
-	mc_ext =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));
+	mc_ext =3D x86_mcinfo_reserve(mi, sizeof(*mc_ext));
 	if (!mc_ext)
 	{
 		mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
 		return NULL;
 	}
=20
-	memset(mc_ext, 0, sizeof(*mc_ext));
 	mc_ext->common.type =3D MC_TYPE_EXTENDED;
 	mc_ext->common.size =3D sizeof(*mc_ext);
 	mc_ext->mc_msrs =3D 3;
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -13,14 +13,12 @@ mci_action_add_pageoffline(int bank, str
     if (!mi)
         return NULL;
=20
-    rec =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_recovery));
+    rec =3D x86_mcinfo_reserve(mi, sizeof(*rec));
     if (!rec) {
         mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
         return NULL;
     }
=20
-    memset(rec, 0, sizeof(struct mcinfo_recovery));
-
     rec->common.type =3D MC_TYPE_RECOVERY;
     rec->common.size =3D sizeof(*rec);
     rec->mc_bank =3D bank;
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -200,14 +200,13 @@ static void mca_init_bank(enum mca_sourc
     if (!mi)
         return;
=20
-    mib =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+    mib =3D x86_mcinfo_reserve(mi, sizeof(*mib));
     if (!mib)
     {
         mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
         return;
     }
=20
-    memset(mib, 0, sizeof (struct mcinfo_bank));
     mib->mc_status =3D mca_rdmsr(MSR_IA32_MCx_STATUS(bank));
=20
     mib->common.type =3D MC_TYPE_BANK;
@@ -247,7 +246,6 @@ static int mca_init_global(uint32_t flag
     struct domain *d;
=20
     /* Set global information */
-    memset(mig, 0, sizeof (struct mcinfo_global));
     mig->common.type =3D MC_TYPE_GLOBAL;
     mig->common.size =3D sizeof (struct mcinfo_global);
     status =3D mca_rdmsr(MSR_IA32_MCG_STATUS);
@@ -349,7 +347,7 @@ mcheck_mca_logout(enum mca_source who, s
             if ( (mctc =3D mctelem_reserve(which)) !=3D NULL ) {
                 mci =3D mctelem_dataptr(mctc);
                 mcinfo_clear(mci);
-                mig =3D x86_mcinfo_reserve(mci, sizeof(struct mcinfo_globa=
l));
+                mig =3D x86_mcinfo_reserve(mci, sizeof(*mig));
                 /* mc_info should at least hold up the global information =
*/
                 ASSERT(mig);
                 mca_init_global(mc_flags, mig);
@@ -820,7 +818,7 @@ void *x86_mcinfo_reserve(struct mc_info=20
     /* there's enough space. add entry. */
     x86_mcinfo_nentries(mi)++;
=20
-    return mic_index;
+    return memset(mic_index, 0, size);
 }
=20
 void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -192,7 +192,7 @@ intel_get_extended_msrs(struct mcinfo_gl
             !(mig->mc_gstatus & MCG_STATUS_EIPV))
         return NULL;
=20
-    mc_ext =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));
+    mc_ext =3D x86_mcinfo_reserve(mi, sizeof(*mc_ext));
     if (!mc_ext)
     {
         mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;
@@ -200,7 +200,6 @@ intel_get_extended_msrs(struct mcinfo_gl
     }
=20
     /* this function will called when CAP(9).MCG_EXT_P =3D 1 */
-    memset(mc_ext, 0, sizeof(*mc_ext));
     mc_ext->common.type =3D MC_TYPE_EXTENDED;
     mc_ext->common.size =3D sizeof(struct mcinfo_extended);
=20




--=__Part093978FE.0__=
Content-Type: text/plain; name="x86-mcinfo-reserve-clear.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mcinfo-reserve-clear.patch"

x86: make x86_mcinfo_reserve() clear its result buffer=0A=0A... instead of =
all but one of its callers.=0A=0AAlso adjust the corresponding sizeof() =
expressions to specify the=0Apointed-to type of the result variable rather =
than the literal type=0A(so that a type change of the variable will imply =
the size to get=0Aadjusted too).=0A=0ASuggested-by: Ian Campbell <Ian.Campb=
ell@citrix.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/cpu/mcheck/amd_f10.c=0A+++ b/xen/arch/x86/cpu/mcheck/amd_f10=
.c=0A@@ -62,14 +62,13 @@ amd_f10_handler(struct mc_info *mi, uint=0A 	if =
(!(status & MCi_STATUS_MISCV))=0A 		return NULL;=0A =0A-	=
mc_ext =3D x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));=0A+	=
mc_ext =3D x86_mcinfo_reserve(mi, sizeof(*mc_ext));=0A 	if (!mc_ext)=0A 	=
{=0A 		mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;=0A 		=
return NULL;=0A 	}=0A =0A-	memset(mc_ext, 0, sizeof(*mc_ext));=
=0A 	mc_ext->common.type =3D MC_TYPE_EXTENDED;=0A 	mc_ext->common.size=
 =3D sizeof(*mc_ext);=0A 	mc_ext->mc_msrs =3D 3;=0A--- a/xen/arch/x86=
/cpu/mcheck/mcaction.c=0A+++ b/xen/arch/x86/cpu/mcheck/mcaction.c=0A@@ =
-13,14 +13,12 @@ mci_action_add_pageoffline(int bank, str=0A     if =
(!mi)=0A         return NULL;=0A =0A-    rec =3D x86_mcinfo_reserve(mi, =
sizeof(struct mcinfo_recovery));=0A+    rec =3D x86_mcinfo_reserve(mi, =
sizeof(*rec));=0A     if (!rec) {=0A         mi->flags |=3D MCINFO_FLAGS_UN=
COMPLETE;=0A         return NULL;=0A     }=0A =0A-    memset(rec, 0, =
sizeof(struct mcinfo_recovery));=0A-=0A     rec->common.type =3D MC_TYPE_RE=
COVERY;=0A     rec->common.size =3D sizeof(*rec);=0A     rec->mc_bank =3D =
bank;=0A--- a/xen/arch/x86/cpu/mcheck/mce.c=0A+++ b/xen/arch/x86/cpu/mcheck=
/mce.c=0A@@ -200,14 +200,13 @@ static void mca_init_bank(enum mca_sourc=0A =
    if (!mi)=0A         return;=0A =0A-    mib =3D x86_mcinfo_reserve(mi, =
sizeof(struct mcinfo_bank));=0A+    mib =3D x86_mcinfo_reserve(mi, =
sizeof(*mib));=0A     if (!mib)=0A     {=0A         mi->flags |=3D =
MCINFO_FLAGS_UNCOMPLETE;=0A         return;=0A     }=0A =0A-    memset(mib,=
 0, sizeof (struct mcinfo_bank));=0A     mib->mc_status =3D mca_rdmsr(MSR_I=
A32_MCx_STATUS(bank));=0A =0A     mib->common.type =3D MC_TYPE_BANK;=0A@@ =
-247,7 +246,6 @@ static int mca_init_global(uint32_t flag=0A     struct =
domain *d;=0A =0A     /* Set global information */=0A-    memset(mig, 0, =
sizeof (struct mcinfo_global));=0A     mig->common.type =3D MC_TYPE_GLOBAL;=
=0A     mig->common.size =3D sizeof (struct mcinfo_global);=0A     status =
=3D mca_rdmsr(MSR_IA32_MCG_STATUS);=0A@@ -349,7 +347,7 @@ mcheck_mca_logout=
(enum mca_source who, s=0A             if ( (mctc =3D mctelem_reserve(which=
)) !=3D NULL ) {=0A                 mci =3D mctelem_dataptr(mctc);=0A      =
           mcinfo_clear(mci);=0A-                mig =3D x86_mcinfo_reserve=
(mci, sizeof(struct mcinfo_global));=0A+                mig =3D x86_mcinfo_=
reserve(mci, sizeof(*mig));=0A                 /* mc_info should at least =
hold up the global information */=0A                 ASSERT(mig);=0A       =
          mca_init_global(mc_flags, mig);=0A@@ -820,7 +818,7 @@ void =
*x86_mcinfo_reserve(struct mc_info =0A     /* there's enough space. add =
entry. */=0A     x86_mcinfo_nentries(mi)++;=0A =0A-    return mic_index;=0A=
+    return memset(mic_index, 0, size);=0A }=0A =0A void *x86_mcinfo_add(st=
ruct mc_info *mi, void *mcinfo)=0A--- a/xen/arch/x86/cpu/mcheck/mce_intel.c=
=0A+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c=0A@@ -192,7 +192,7 @@ =
intel_get_extended_msrs(struct mcinfo_gl=0A             !(mig->mc_gstatus =
& MCG_STATUS_EIPV))=0A         return NULL;=0A =0A-    mc_ext =3D =
x86_mcinfo_reserve(mi, sizeof(struct mcinfo_extended));=0A+    mc_ext =3D =
x86_mcinfo_reserve(mi, sizeof(*mc_ext));=0A     if (!mc_ext)=0A     {=0A   =
      mi->flags |=3D MCINFO_FLAGS_UNCOMPLETE;=0A@@ -200,7 +200,6 @@ =
intel_get_extended_msrs(struct mcinfo_gl=0A     }=0A =0A     /* this =
function will called when CAP(9).MCG_EXT_P =3D 1 */=0A-    memset(mc_ext, =
0, sizeof(*mc_ext));=0A     mc_ext->common.type =3D MC_TYPE_EXTENDED;=0A   =
  mc_ext->common.size =3D sizeof(struct mcinfo_extended);=0A =0A
--=__Part093978FE.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

--=__Part093978FE.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:52:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:52: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 1UAecc-0006jj-HK; Wed, 27 Feb 2013 10:52:26 +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 1UAecb-0006jZ-0a
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:52:25 +0000
Received: from [85.158.137.99:23464] by server-9.bemta-3.messagelabs.com id
	7E/11-32531-865ED215; Wed, 27 Feb 2013 10:52:24 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361962220!13593706!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQ3NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7372 invoked from network); 27 Feb 2013 10:50:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-217.messagelabs.com with SMTP;
	27 Feb 2013 10:50:21 -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 r1RAoAGZ029977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 05:50:17 -0500
Received: from redhat.com (vpn1-7-172.ams2.redhat.com [10.36.7.172])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id r1RAo7cD021569; Wed, 27 Feb 2013 05:50:08 -0500
Date: Wed, 27 Feb 2013 12:50:24 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20130227105024.GB13054@redhat.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: aliguori@us.ibm.com, stefano.stabellini@eu.citrix.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	JBeulich@suse.com, afaerber@suse.de,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 02:53:37PM +0800, Xudong Hao wrote:
> v2:
> * Use "piix: " in the subject rather than "qemu: "
> * Define TOM register as one byte
> * Define default TOM value instead of hardcode 0xe0000000 in more that one place
> * Use API pci_set_byte for pci config access
> * Use dev->config instead of the indirect d->dev.config
> 
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically. TOM register are defined to one byte in PCI configure
> space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> it requires bios set TOM with 16M-aligned.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

Could you supply some motivation for this patch?

> ---
>  hw/pc.h       |  7 +++---
>  hw/pc_piix.c  | 12 +++-------
>  hw/piix_pci.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------------
>  3 files changed, 59 insertions(+), 33 deletions(-)
> 
> diff --git a/hw/pc.h b/hw/pc.h
> index fbcf43d..62adcc5 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -129,15 +129,14 @@ extern int no_hpet;
>  struct PCII440FXState;
>  typedef struct PCII440FXState PCII440FXState;
>  
> +#define I440FX_TOM     0xe0000000
> +#define I440FX_XEN_TOM 0xf0000000
> +
>  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>                      ISABus **isa_bus, qemu_irq *pic,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory,
>                      MemoryRegion *ram_memory);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0a6923d..2eef510 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
>          kvmclock_create();
>      }
>  
> -    if (ram_size >= 0xe0000000 ) {
> -        above_4g_mem_size = ram_size - 0xe0000000;
> -        below_4g_mem_size = 0xe0000000;
> +    if (ram_size >= I440FX_TOM) {
> +        above_4g_mem_size = ram_size - I440FX_TOM;
> +        below_4g_mem_size = I440FX_TOM;
>      } else {
>          above_4g_mem_size = 0;
>          below_4g_mem_size = ram_size;
> @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>                                system_memory, system_io, ram_size,
> -                              below_4g_mem_size,
> -                              0x100000000ULL - below_4g_mem_size,
> -                              0x100000000ULL + above_4g_mem_size,
> -                              (sizeof(hwaddr) == 4
> -                               ? 0
> -                               : ((uint64_t)1 << 62)),
>                                pci_memory, ram_memory);
>      } else {
>          pci_bus = NULL;
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3d79c73..3e5a25c 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -86,6 +86,14 @@ struct PCII440FXState {
>  #define I440FX_PAM_SIZE 7
>  #define I440FX_SMRAM    0x72
>  
> +/* The maximum vaule of TOM(top of memory) register in I440FX
> + * is 1G, so it doesn't meet any popular virutal machines, so
> + * define another register to report the base of PCI memory.
> + * Use one byte 0xb0 for the upper 8 bit, they are originally
> + * resevered for host bridge.
> + * */
> +#define I440FX_PCI_HOLE_BASE 0xb0

Do you have to use a fixed address? As others said, it's a hack.
How about adding a special device for this hackery?

> +
>  static void piix3_set_irq(void *opaque, int pirq, int level);
>  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
>  static void piix3_write_config_xen(PCIDevice *dev,
> @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> +
> +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> +{
> +    ram_addr_t above_4g_mem_size;
> +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
> +
> +    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 1) << 24;
> +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> +
> +    if (ram_size >= pci_hole_start) {
> +        above_4g_mem_size = ram_size - pci_hole_start;
> +    } else {
> +        above_4g_mem_size = 0;
> +    }
> +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> +
> +    if (del) {
> +        memory_region_del_subregion(f->system_memory, &f->pci_hole);
> +        if (pci_hole64_size) {
> +            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
> +        }
> +    }
> +
> +    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> +                             pci_hole_start, pci_hole_size);
> +    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> +                             f->pci_address_space,
> +                             pci_hole64_start, pci_hole64_size);
> +    if (pci_hole64_size) {
> +        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> +                                    &f->pci_hole_64bit);
> +    }
> +}
> +
> +

If you do things like this, won't ACPI tables become incorrect?

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:52:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:52: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 1UAecc-0006jj-HK; Wed, 27 Feb 2013 10:52:26 +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 1UAecb-0006jZ-0a
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:52:25 +0000
Received: from [85.158.137.99:23464] by server-9.bemta-3.messagelabs.com id
	7E/11-32531-865ED215; Wed, 27 Feb 2013 10:52:24 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1361962220!13593706!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQ3NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7372 invoked from network); 27 Feb 2013 10:50:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-217.messagelabs.com with SMTP;
	27 Feb 2013 10:50:21 -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 r1RAoAGZ029977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 05:50:17 -0500
Received: from redhat.com (vpn1-7-172.ams2.redhat.com [10.36.7.172])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with SMTP
	id r1RAo7cD021569; Wed, 27 Feb 2013 05:50:08 -0500
Date: Wed, 27 Feb 2013 12:50:24 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20130227105024.GB13054@redhat.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: aliguori@us.ibm.com, stefano.stabellini@eu.citrix.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	JBeulich@suse.com, afaerber@suse.de,
	Xiantao Zhang <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH v2] piix: define a TOM register to report
	the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 25, 2013 at 02:53:37PM +0800, Xudong Hao wrote:
> v2:
> * Use "piix: " in the subject rather than "qemu: "
> * Define TOM register as one byte
> * Define default TOM value instead of hardcode 0xe0000000 in more that one place
> * Use API pci_set_byte for pci config access
> * Use dev->config instead of the indirect d->dev.config
> 
> Define a TOM(top of memory) register to report the base of PCI memory, update
> memory region dynamically. TOM register are defined to one byte in PCI configure
> space, because that only upper 4 bit of PCI memory takes effect for Xen, so
> it requires bios set TOM with 16M-aligned.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

Could you supply some motivation for this patch?

> ---
>  hw/pc.h       |  7 +++---
>  hw/pc_piix.c  | 12 +++-------
>  hw/piix_pci.c | 73 +++++++++++++++++++++++++++++++++++++++++++----------------
>  3 files changed, 59 insertions(+), 33 deletions(-)
> 
> diff --git a/hw/pc.h b/hw/pc.h
> index fbcf43d..62adcc5 100644
> --- a/hw/pc.h
> +++ b/hw/pc.h
> @@ -129,15 +129,14 @@ extern int no_hpet;
>  struct PCII440FXState;
>  typedef struct PCII440FXState PCII440FXState;
>  
> +#define I440FX_TOM     0xe0000000
> +#define I440FX_XEN_TOM 0xf0000000
> +
>  PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
>                      ISABus **isa_bus, qemu_irq *pic,
>                      MemoryRegion *address_space_mem,
>                      MemoryRegion *address_space_io,
>                      ram_addr_t ram_size,
> -                    hwaddr pci_hole_start,
> -                    hwaddr pci_hole_size,
> -                    hwaddr pci_hole64_start,
> -                    hwaddr pci_hole64_size,
>                      MemoryRegion *pci_memory,
>                      MemoryRegion *ram_memory);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 0a6923d..2eef510 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -93,9 +93,9 @@ static void pc_init1(MemoryRegion *system_memory,
>          kvmclock_create();
>      }
>  
> -    if (ram_size >= 0xe0000000 ) {
> -        above_4g_mem_size = ram_size - 0xe0000000;
> -        below_4g_mem_size = 0xe0000000;
> +    if (ram_size >= I440FX_TOM) {
> +        above_4g_mem_size = ram_size - I440FX_TOM;
> +        below_4g_mem_size = I440FX_TOM;
>      } else {
>          above_4g_mem_size = 0;
>          below_4g_mem_size = ram_size;
> @@ -130,12 +130,6 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pci_bus = i440fx_init(&i440fx_state, &piix3_devfn, &isa_bus, gsi,
>                                system_memory, system_io, ram_size,
> -                              below_4g_mem_size,
> -                              0x100000000ULL - below_4g_mem_size,
> -                              0x100000000ULL + above_4g_mem_size,
> -                              (sizeof(hwaddr) == 4
> -                               ? 0
> -                               : ((uint64_t)1 << 62)),
>                                pci_memory, ram_memory);
>      } else {
>          pci_bus = NULL;
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 3d79c73..3e5a25c 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -86,6 +86,14 @@ struct PCII440FXState {
>  #define I440FX_PAM_SIZE 7
>  #define I440FX_SMRAM    0x72
>  
> +/* The maximum vaule of TOM(top of memory) register in I440FX
> + * is 1G, so it doesn't meet any popular virutal machines, so
> + * define another register to report the base of PCI memory.
> + * Use one byte 0xb0 for the upper 8 bit, they are originally
> + * resevered for host bridge.
> + * */
> +#define I440FX_PCI_HOLE_BASE 0xb0

Do you have to use a fixed address? As others said, it's a hack.
How about adding a special device for this hackery?

> +
>  static void piix3_set_irq(void *opaque, int pirq, int level);
>  static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
>  static void piix3_write_config_xen(PCIDevice *dev,
> @@ -101,6 +109,43 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> +
> +static void i440fx_update_pci_mem_hole(PCII440FXState *f, bool del)
> +{
> +    ram_addr_t above_4g_mem_size;
> +    hwaddr pci_hole_start, pci_hole_size, pci_hole64_start, pci_hole64_size;
> +
> +    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 1) << 24;
> +    pci_hole_size = 0x100000000ULL - pci_hole_start;
> +
> +    if (ram_size >= pci_hole_start) {
> +        above_4g_mem_size = ram_size - pci_hole_start;
> +    } else {
> +        above_4g_mem_size = 0;
> +    }
> +    pci_hole64_start = 0x100000000ULL + above_4g_mem_size;
> +    pci_hole64_size = sizeof(hwaddr) == 4 ? 0 : ((uint64_t)1 << 62);
> +
> +    if (del) {
> +        memory_region_del_subregion(f->system_memory, &f->pci_hole);
> +        if (pci_hole64_size) {
> +            memory_region_del_subregion(f->system_memory, &f->pci_hole_64bit);
> +        }
> +    }
> +
> +    memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
> +                             pci_hole_start, pci_hole_size);
> +    memory_region_add_subregion(f->system_memory, pci_hole_start, &f->pci_hole);
> +    memory_region_init_alias(&f->pci_hole_64bit, "pci-hole64",
> +                             f->pci_address_space,
> +                             pci_hole64_start, pci_hole64_size);
> +    if (pci_hole64_size) {
> +        memory_region_add_subregion(f->system_memory, pci_hole64_start,
> +                                    &f->pci_hole_64bit);
> +    }
> +}
> +
> +

If you do things like this, won't ACPI tables become incorrect?

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAedS-0006o3-WB; Wed, 27 Feb 2013 10:53:19 +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 1UAedR-0006np-OS
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:53:17 +0000
Received: from [193.109.254.147:5996] by server-6.bemta-14.messagelabs.com id
	32/EF-12010-D95ED215; Wed, 27 Feb 2013 10:53:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361962157!9727809!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24175 invoked from network); 27 Feb 2013 10:49:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:49:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:49:17 +0000
Message-Id: <512DF2BA02000078000C16B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:49:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <512B844C02000078000C0C75@nat28.tlf.novell.com>
	<20130226152719.GD93966@ocelot.phlegethon.org>
In-Reply-To: <20130226152719.GD93966@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XENMEM_maximum_gpfn return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:27, Tim Deegan <tim@xen.org> wrote:
> At 14:33 +0000 on 25 Feb (1361802812), Jan Beulich wrote:
>> This coming from a shared info field, it has to be assumed to possibly
>> have any value. In particular, our kernels don't set up this field at all
>> if running as Dom0 and kexec isn't enabled (along with not setting up
>> the P2M frame lists, as that's simply wasted memory in that case).
>> 
>> So, with this being a guest provided value, we apparently have two
>> problems: do_memory_op()'s "rc" variable is only of type "int", thus
>> potentially truncating the result of domain_get_maximum_gpfn()
>> (considering that we now support 16Tb, an 8Tb+ guest ought to
>> be possible, and such would have a max GPFN with 32 significant
>> bits). And zero or a very large number being returned by the latter
>> will generally be mistaken as an error code by the caller of the
>> hypercall.
>> 
>> So, along with promoting "rc" to long, I'm considering enforcing a
>> sane lower bound on domain_get_maximum_gpfn()'s return value,
>> using d->tot_pages (under the assumption that each page would
>> have a representation in the physical map, and hence the
>> physical map can't reasonably be smaller than this). That would
>> overcome the subtraction of 1 done there for PV guests to
>> convert 0 to -1 (i.e. -EPERM). Similarly, a sane upper bound
>> ought to be enforced (to avoid collisions with the -E range).
>> 
>> Other thoughts? Is such a behavioral change acceptable for an
>> existing interface?
> 
> The new behaviour seems sensible but I'm a little worried about changing
> the behaviour of an existing call.  I'd be inclined to add a new
> hypercall that DTRT and leave the old one, deprecated.

So I think this should be two steps then - fix the current call (so
that it doesn't return -1 (== -EPERM) anymore when the field is
zero, and so it doesn't truncate big values anymore) and, should
it ever turn out necessary, add a new one returning a sanitized
value.

I'll send a patch for the first part in a minute, but I'll leave the
second step open as I think the context in which the problem
was observed (xen-mceinj) is actually in need of fixing itself (i.e.
should not be using this call).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:53:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAedS-0006o3-WB; Wed, 27 Feb 2013 10:53:19 +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 1UAedR-0006np-OS
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:53:17 +0000
Received: from [193.109.254.147:5996] by server-6.bemta-14.messagelabs.com id
	32/EF-12010-D95ED215; Wed, 27 Feb 2013 10:53:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361962157!9727809!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24175 invoked from network); 27 Feb 2013 10:49:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:49:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:49:17 +0000
Message-Id: <512DF2BA02000078000C16B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:49:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <512B844C02000078000C0C75@nat28.tlf.novell.com>
	<20130226152719.GD93966@ocelot.phlegethon.org>
In-Reply-To: <20130226152719.GD93966@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XENMEM_maximum_gpfn return value
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 16:27, Tim Deegan <tim@xen.org> wrote:
> At 14:33 +0000 on 25 Feb (1361802812), Jan Beulich wrote:
>> This coming from a shared info field, it has to be assumed to possibly
>> have any value. In particular, our kernels don't set up this field at all
>> if running as Dom0 and kexec isn't enabled (along with not setting up
>> the P2M frame lists, as that's simply wasted memory in that case).
>> 
>> So, with this being a guest provided value, we apparently have two
>> problems: do_memory_op()'s "rc" variable is only of type "int", thus
>> potentially truncating the result of domain_get_maximum_gpfn()
>> (considering that we now support 16Tb, an 8Tb+ guest ought to
>> be possible, and such would have a max GPFN with 32 significant
>> bits). And zero or a very large number being returned by the latter
>> will generally be mistaken as an error code by the caller of the
>> hypercall.
>> 
>> So, along with promoting "rc" to long, I'm considering enforcing a
>> sane lower bound on domain_get_maximum_gpfn()'s return value,
>> using d->tot_pages (under the assumption that each page would
>> have a representation in the physical map, and hence the
>> physical map can't reasonably be smaller than this). That would
>> overcome the subtraction of 1 done there for PV guests to
>> convert 0 to -1 (i.e. -EPERM). Similarly, a sane upper bound
>> ought to be enforced (to avoid collisions with the -E range).
>> 
>> Other thoughts? Is such a behavioral change acceptable for an
>> existing interface?
> 
> The new behaviour seems sensible but I'm a little worried about changing
> the behaviour of an existing call.  I'd be inclined to add a new
> hypercall that DTRT and leave the old one, deprecated.

So I think this should be two steps then - fix the current call (so
that it doesn't return -1 (== -EPERM) anymore when the field is
zero, and so it doesn't truncate big values anymore) and, should
it ever turn out necessary, add a new one returning a sanitized
value.

I'll send a patch for the first part in a minute, but I'll leave the
second step open as I think the context in which the problem
was observed (xen-mceinj) is actually in need of fixing itself (i.e.
should not be using this call).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:54:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:54: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 1UAeeK-0006vF-Kz; Wed, 27 Feb 2013 10:54:12 +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 1UAeeI-0006up-VU
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:54:11 +0000
Received: from [85.158.139.83:25220] by server-8.bemta-5.messagelabs.com id
	87/62-05790-2D5ED215; Wed, 27 Feb 2013 10:54:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361962449!23975137!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2793 invoked from network); 27 Feb 2013 10:54:09 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:54:09 -0000
Received: by mail-wi0-f178.google.com with SMTP id hq4so458690wib.17
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Feb 2013 02:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=AHCDHGjH/3bPehqUCYl+m3FTscqGZCqm4X6izqlFkqU=;
	b=rcyayJyGeeERyDc15yAme6U9XP7Nu0a1+LF0tP66YBuymTAr24Eh+Gn2NtgxsgMe2A
	Jh0PNjtObdkV20S/utPCS6SNiSvPq6lKwffny/1DS5K1BfnAkYBb/bmFz91QfY3OX43m
	RILSa+6Kkp8QI3wHP3vppI8mmPtL2xfDYS83QB7oNRAns/jneDWOKm0aBbNqBUxukr4x
	CDjVb4wuQWVXluM49Ynlw9oHPAu1HMR8GAQBZuLRbgUha8A+z0pU0P1OFN12LJCXEPc7
	eKGcr0fhyjIDR9FxMX1zo99Z0U8X1ve+KtUvsI9S6tuzOr51dFH8Zin94F797XYdDp5a
	76Gw==
MIME-Version: 1.0
X-Received: by 10.194.171.74 with SMTP id as10mr3054471wjc.0.1361962442884;
	Wed, 27 Feb 2013 02:54:02 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 02:54:02 -0800 (PST)
In-Reply-To: <1361900393.26546.319.camel@zakaz.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
Date: Wed, 27 Feb 2013 10:54:02 +0000
X-Google-Sender-Auth: 1FAkU3zW1ayEBnEp6IjlMeCfdyo
Message-ID: <CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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="===============3205790946474730938=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3205790946474730938==
Content-Type: multipart/alternative; boundary=089e013c6c0e9b0f6404d6b29771

--089e013c6c0e9b0f6404d6b29771
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 5:39 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> > Maybe we should produce a tgz instead (plain or Slackware style).
> > I wouldn't want to create wrong expectations: it is better to build no
> > packages than building "broken" packages. (Of course I still think the
> > best choice would be to produce good packages.)
>
> I think you have massively underestimated the development effort and
> maintenance burden of producing good packages. Again: That is what the
> distros do, and they do it well and in a far more scalable fashion than
> we ever could.
>


I can see the point of both sides -- we (at least the active developers)
don't want to get into real package management.  The point of keeping the
.deb as an "easy way to add and remove a tarball" is to avoid raising
expectations that we are going to maintain such a thing.

On the other hand, there is clearly a definite need for such a thing.
Saying "Debian or Ubuntu should be doing the packaging" is just not right
thinking IMHO.  We *want* (and *need*) to have active users to be using our
releases as soon as they come out, rather than waiting N years for them to
trickle through the Debian and Ubuntu packaging systems.  As has been said
before, building the Debian package involves all kinds of complications
regarding custom patches and so on.

What about this: We obviously have users who are keen to have this
functionality, and in fact who have made local versions of such
functionality to use themselves.  If one of them is willing to step up and
officially maintain such functionality (which would include responding to
bugs and updating things on a regular basis), then I think we should
consider accepting such a patch.  If it ever becomes unmaintained, then
we'll take it out.  That way the core devs won't have to be involved in
package management, but early-adopters will have the benefit of being able
to use Xen more easily.

In any case I would suggest keeping the current .deb target but renaming it
to something like "testdeb", to emphasize "this is for testing purposes
only".

Thoughts?
 -George

--089e013c6c0e9b0f6404d6b29771
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 26, 2013 at 5:39 PM, Ian Campbell <span dir=3D=
"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.=
Campbell@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<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">&gt;=
 Maybe we should produce a tgz instead (plain or Slackware style).<br>
&gt; I wouldn&#39;t want to create wrong expectations: it is better to buil=
d no<br>
&gt; packages than building &quot;broken&quot; packages. (Of course I still=
 think the<br>
&gt; best choice would be to produce good packages.)<br>
<br>
</div></div>I think you have massively underestimated the development effor=
t and<br>
maintenance burden of producing good packages. Again: That is what the<br>
distros do, and they do it well and in a far more scalable fashion than<br>
we ever could.<br></blockquote><br></div><br></div><div class=3D"gmail_extr=
a">I can see the point of both sides -- we (at least the active developers)=
 don&#39;t want to get into real package management.=A0 The point of keepin=
g the .deb as an &quot;easy way to add and remove a tarball&quot; is to avo=
id raising expectations that we are going to maintain such a thing.<br>
<br>On the other hand, there is clearly a definite need for such a thing.=
=A0 Saying &quot;Debian or Ubuntu should be doing the packaging&quot; is ju=
st not right thinking IMHO.=A0 We *want* (and *need*) to have active users =
to be using our releases as soon as they come out, rather than waiting N ye=
ars for them to trickle through the Debian and Ubuntu packaging systems.=A0=
 As has been said before, building the Debian package involves all kinds of=
 complications regarding custom patches and so on.<br>
<br></div><div class=3D"gmail_extra">What about this: We obviously have use=
rs who are keen to have this functionality, and in fact who have made local=
 versions of such functionality to use themselves.=A0 If one of them is wil=
ling to step up and officially maintain such functionality (which would inc=
lude responding to bugs and updating things on a regular basis), then I thi=
nk we should consider accepting such a patch.=A0 If it ever becomes unmaint=
ained, then we&#39;ll take it out.=A0 That way the core devs won&#39;t have=
 to be involved in package management, but early-adopters will have the ben=
efit of being able to use Xen more easily.<br>
<br></div><div class=3D"gmail_extra">In any case I would suggest keeping th=
e current .deb target but renaming it to something like &quot;testdeb&quot;=
, to emphasize &quot;this is for testing purposes only&quot;.<br></div><div=
 class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Thoughts?<br></div><div class=3D"gmail=
_extra">=A0-George<br></div></div>

--089e013c6c0e9b0f6404d6b29771--


--===============3205790946474730938==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3205790946474730938==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:54:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10:54: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 1UAeeK-0006vF-Kz; Wed, 27 Feb 2013 10:54:12 +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 1UAeeI-0006up-VU
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:54:11 +0000
Received: from [85.158.139.83:25220] by server-8.bemta-5.messagelabs.com id
	87/62-05790-2D5ED215; Wed, 27 Feb 2013 10:54:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361962449!23975137!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2793 invoked from network); 27 Feb 2013 10:54:09 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:54:09 -0000
Received: by mail-wi0-f178.google.com with SMTP id hq4so458690wib.17
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Feb 2013 02:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=AHCDHGjH/3bPehqUCYl+m3FTscqGZCqm4X6izqlFkqU=;
	b=rcyayJyGeeERyDc15yAme6U9XP7Nu0a1+LF0tP66YBuymTAr24Eh+Gn2NtgxsgMe2A
	Jh0PNjtObdkV20S/utPCS6SNiSvPq6lKwffny/1DS5K1BfnAkYBb/bmFz91QfY3OX43m
	RILSa+6Kkp8QI3wHP3vppI8mmPtL2xfDYS83QB7oNRAns/jneDWOKm0aBbNqBUxukr4x
	CDjVb4wuQWVXluM49Ynlw9oHPAu1HMR8GAQBZuLRbgUha8A+z0pU0P1OFN12LJCXEPc7
	eKGcr0fhyjIDR9FxMX1zo99Z0U8X1ve+KtUvsI9S6tuzOr51dFH8Zin94F797XYdDp5a
	76Gw==
MIME-Version: 1.0
X-Received: by 10.194.171.74 with SMTP id as10mr3054471wjc.0.1361962442884;
	Wed, 27 Feb 2013 02:54:02 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 02:54:02 -0800 (PST)
In-Reply-To: <1361900393.26546.319.camel@zakaz.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
Date: Wed, 27 Feb 2013 10:54:02 +0000
X-Google-Sender-Auth: 1FAkU3zW1ayEBnEp6IjlMeCfdyo
Message-ID: <CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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="===============3205790946474730938=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3205790946474730938==
Content-Type: multipart/alternative; boundary=089e013c6c0e9b0f6404d6b29771

--089e013c6c0e9b0f6404d6b29771
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 5:39 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> > Maybe we should produce a tgz instead (plain or Slackware style).
> > I wouldn't want to create wrong expectations: it is better to build no
> > packages than building "broken" packages. (Of course I still think the
> > best choice would be to produce good packages.)
>
> I think you have massively underestimated the development effort and
> maintenance burden of producing good packages. Again: That is what the
> distros do, and they do it well and in a far more scalable fashion than
> we ever could.
>


I can see the point of both sides -- we (at least the active developers)
don't want to get into real package management.  The point of keeping the
.deb as an "easy way to add and remove a tarball" is to avoid raising
expectations that we are going to maintain such a thing.

On the other hand, there is clearly a definite need for such a thing.
Saying "Debian or Ubuntu should be doing the packaging" is just not right
thinking IMHO.  We *want* (and *need*) to have active users to be using our
releases as soon as they come out, rather than waiting N years for them to
trickle through the Debian and Ubuntu packaging systems.  As has been said
before, building the Debian package involves all kinds of complications
regarding custom patches and so on.

What about this: We obviously have users who are keen to have this
functionality, and in fact who have made local versions of such
functionality to use themselves.  If one of them is willing to step up and
officially maintain such functionality (which would include responding to
bugs and updating things on a regular basis), then I think we should
consider accepting such a patch.  If it ever becomes unmaintained, then
we'll take it out.  That way the core devs won't have to be involved in
package management, but early-adopters will have the benefit of being able
to use Xen more easily.

In any case I would suggest keeping the current .deb target but renaming it
to something like "testdeb", to emphasize "this is for testing purposes
only".

Thoughts?
 -George

--089e013c6c0e9b0f6404d6b29771
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 26, 2013 at 5:39 PM, Ian Campbell <span dir=3D=
"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_blank">Ian.=
Campbell@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<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">&gt;=
 Maybe we should produce a tgz instead (plain or Slackware style).<br>
&gt; I wouldn&#39;t want to create wrong expectations: it is better to buil=
d no<br>
&gt; packages than building &quot;broken&quot; packages. (Of course I still=
 think the<br>
&gt; best choice would be to produce good packages.)<br>
<br>
</div></div>I think you have massively underestimated the development effor=
t and<br>
maintenance burden of producing good packages. Again: That is what the<br>
distros do, and they do it well and in a far more scalable fashion than<br>
we ever could.<br></blockquote><br></div><br></div><div class=3D"gmail_extr=
a">I can see the point of both sides -- we (at least the active developers)=
 don&#39;t want to get into real package management.=A0 The point of keepin=
g the .deb as an &quot;easy way to add and remove a tarball&quot; is to avo=
id raising expectations that we are going to maintain such a thing.<br>
<br>On the other hand, there is clearly a definite need for such a thing.=
=A0 Saying &quot;Debian or Ubuntu should be doing the packaging&quot; is ju=
st not right thinking IMHO.=A0 We *want* (and *need*) to have active users =
to be using our releases as soon as they come out, rather than waiting N ye=
ars for them to trickle through the Debian and Ubuntu packaging systems.=A0=
 As has been said before, building the Debian package involves all kinds of=
 complications regarding custom patches and so on.<br>
<br></div><div class=3D"gmail_extra">What about this: We obviously have use=
rs who are keen to have this functionality, and in fact who have made local=
 versions of such functionality to use themselves.=A0 If one of them is wil=
ling to step up and officially maintain such functionality (which would inc=
lude responding to bugs and updating things on a regular basis), then I thi=
nk we should consider accepting such a patch.=A0 If it ever becomes unmaint=
ained, then we&#39;ll take it out.=A0 That way the core devs won&#39;t have=
 to be involved in package management, but early-adopters will have the ben=
efit of being able to use Xen more easily.<br>
<br></div><div class=3D"gmail_extra">In any case I would suggest keeping th=
e current .deb target but renaming it to something like &quot;testdeb&quot;=
, to emphasize &quot;this is for testing purposes only&quot;.<br></div><div=
 class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Thoughts?<br></div><div class=3D"gmail=
_extra">=A0-George<br></div></div>

--089e013c6c0e9b0f6404d6b29771--


--===============3205790946474730938==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3205790946474730938==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:57:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAegv-00079n-8H; Wed, 27 Feb 2013 10:56: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 1UAegt-00079U-GD
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:56:51 +0000
Received: from [193.109.254.147:41458] by server-14.bemta-14.messagelabs.com
	id E6/10-02031-276ED215; Wed, 27 Feb 2013 10:56:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361962379!9487945!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19323 invoked from network); 27 Feb 2013 10:53:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:53:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:52:59 +0000
Message-Id: <512DF39A02000078000C16CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:52:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6B5B1A9A.0__="
Subject: [Xen-devel] [PATCH] x86: make certain memory sub-ops return valid
	values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part6B5B1A9A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When a domain's shared info field "max_pfn" is zero,
domain_get_maximum_gpfn() so far returned ULONG_MAX, which
do_memory_op() in turn converted to -1 (i.e. -EPERM). Make the former
always return a sensible number (i.e. zero if the field was zero) and
have the latter no longer truncate return values.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -433,7 +433,7 @@ unsigned long domain_get_maximum_gpfn(st
     if ( is_hvm_domain(d) )
         return p2m_get_hostp2m(d)->max_mapped_pfn;
     /* NB. PV guests specify nr_pfns rather than max_pfn so we adjust =
here. */
-    return arch_get_max_pfn(d) - 1;
+    return (arch_get_max_pfn(d) ?: 1) - 1;
 }
=20
 void share_xen_page_with_guest(
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -15,7 +15,8 @@ CHECK_TYPE(domid);
=20
 int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) =
compat)
 {
-    int rc, split, op =3D cmd & MEMOP_CMD_MASK;
+    int split, op =3D cmd & MEMOP_CMD_MASK;
+    long rc;
     unsigned int start_extent =3D cmd >> MEMOP_EXTENT_SHIFT;
=20
     do
@@ -204,7 +205,7 @@ int compat_memory_op(unsigned int cmd, X
=20
         rc =3D do_memory_op(cmd, nat.hnd);
         if ( rc < 0 )
-            return rc;
+            break;
=20
         cmd =3D 0;
         if ( hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )
@@ -326,5 +327,11 @@ int compat_memory_op(unsigned int cmd, X
                 __HYPERVISOR_memory_op, "ih", cmd, compat);
     } while ( split > 0 );
=20
+    if ( unlikely(rc > INT_MAX) )
+        return INT_MAX;
+
+    if ( unlikely(rc < INT_MIN) )
+        return INT_MIN;
+
     return rc;
 }
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
-    int rc, op;
+    long rc;
     unsigned int address_bits;
     unsigned long start_extent;
     struct xen_memory_reservation reservation;
     struct memop_args args;
     domid_t domid;
-
-    op =3D cmd & MEMOP_CMD_MASK;
+    int op =3D cmd & MEMOP_CMD_MASK;
=20
     switch ( op )
     {




--=__Part6B5B1A9A.0__=
Content-Type: text/plain; name="x86-get-maximum-gpfn.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get-maximum-gpfn.patch"

x86: make certain memory sub-ops return valid values=0A=0AWhen a domain's =
shared info field "max_pfn" is zero,=0Adomain_get_maximum_gpfn() so far =
returned ULONG_MAX, which=0Ado_memory_op() in turn converted to -1 (i.e. =
-EPERM). Make the former=0Aalways return a sensible number (i.e. zero if =
the field was zero) and=0Ahave the latter no longer truncate return =
values.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -433,7 +433,7 @@ =
unsigned long domain_get_maximum_gpfn(st=0A     if ( is_hvm_domain(d) )=0A =
        return p2m_get_hostp2m(d)->max_mapped_pfn;=0A     /* NB. PV guests =
specify nr_pfns rather than max_pfn so we adjust here. */=0A-    return =
arch_get_max_pfn(d) - 1;=0A+    return (arch_get_max_pfn(d) ?: 1) - 1;=0A =
}=0A =0A void share_xen_page_with_guest(=0A--- a/xen/common/compat/memory.c=
=0A+++ b/xen/common/compat/memory.c=0A@@ -15,7 +15,8 @@ CHECK_TYPE(domid);=
=0A =0A int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void)=
 compat)=0A {=0A-    int rc, split, op =3D cmd & MEMOP_CMD_MASK;=0A+    =
int split, op =3D cmd & MEMOP_CMD_MASK;=0A+    long rc;=0A     unsigned =
int start_extent =3D cmd >> MEMOP_EXTENT_SHIFT;=0A =0A     do=0A@@ -204,7 =
+205,7 @@ int compat_memory_op(unsigned int cmd, X=0A =0A         rc =3D =
do_memory_op(cmd, nat.hnd);=0A         if ( rc < 0 )=0A-            return =
rc;=0A+            break;=0A =0A         cmd =3D 0;=0A         if ( =
hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )=0A@@ -326,5 =
+327,11 @@ int compat_memory_op(unsigned int cmd, X=0A                 =
__HYPERVISOR_memory_op, "ih", cmd, compat);=0A     } while ( split > 0 =
);=0A =0A+    if ( unlikely(rc > INT_MAX) )=0A+        return INT_MAX;=0A+=
=0A+    if ( unlikely(rc < INT_MIN) )=0A+        return INT_MIN;=0A+=0A    =
 return rc;=0A }=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A=
@@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA=0A long =
do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)=0A {=0A  =
   struct domain *d;=0A-    int rc, op;=0A+    long rc;=0A     unsigned =
int address_bits;=0A     unsigned long start_extent;=0A     struct =
xen_memory_reservation reservation;=0A     struct memop_args args;=0A     =
domid_t domid;=0A-=0A-    op =3D cmd & MEMOP_CMD_MASK;=0A+    int op =3D =
cmd & MEMOP_CMD_MASK;=0A =0A     switch ( op )=0A     {=0A
--=__Part6B5B1A9A.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

--=__Part6B5B1A9A.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:57:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAegv-00079n-8H; Wed, 27 Feb 2013 10:56: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 1UAegt-00079U-GD
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:56:51 +0000
Received: from [193.109.254.147:41458] by server-14.bemta-14.messagelabs.com
	id E6/10-02031-276ED215; Wed, 27 Feb 2013 10:56:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361962379!9487945!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19323 invoked from network); 27 Feb 2013 10:53:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:53:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:52:59 +0000
Message-Id: <512DF39A02000078000C16CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:52:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6B5B1A9A.0__="
Subject: [Xen-devel] [PATCH] x86: make certain memory sub-ops return valid
	values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__Part6B5B1A9A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When a domain's shared info field "max_pfn" is zero,
domain_get_maximum_gpfn() so far returned ULONG_MAX, which
do_memory_op() in turn converted to -1 (i.e. -EPERM). Make the former
always return a sensible number (i.e. zero if the field was zero) and
have the latter no longer truncate return values.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -433,7 +433,7 @@ unsigned long domain_get_maximum_gpfn(st
     if ( is_hvm_domain(d) )
         return p2m_get_hostp2m(d)->max_mapped_pfn;
     /* NB. PV guests specify nr_pfns rather than max_pfn so we adjust =
here. */
-    return arch_get_max_pfn(d) - 1;
+    return (arch_get_max_pfn(d) ?: 1) - 1;
 }
=20
 void share_xen_page_with_guest(
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -15,7 +15,8 @@ CHECK_TYPE(domid);
=20
 int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) =
compat)
 {
-    int rc, split, op =3D cmd & MEMOP_CMD_MASK;
+    int split, op =3D cmd & MEMOP_CMD_MASK;
+    long rc;
     unsigned int start_extent =3D cmd >> MEMOP_EXTENT_SHIFT;
=20
     do
@@ -204,7 +205,7 @@ int compat_memory_op(unsigned int cmd, X
=20
         rc =3D do_memory_op(cmd, nat.hnd);
         if ( rc < 0 )
-            return rc;
+            break;
=20
         cmd =3D 0;
         if ( hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )
@@ -326,5 +327,11 @@ int compat_memory_op(unsigned int cmd, X
                 __HYPERVISOR_memory_op, "ih", cmd, compat);
     } while ( split > 0 );
=20
+    if ( unlikely(rc > INT_MAX) )
+        return INT_MAX;
+
+    if ( unlikely(rc < INT_MIN) )
+        return INT_MIN;
+
     return rc;
 }
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
-    int rc, op;
+    long rc;
     unsigned int address_bits;
     unsigned long start_extent;
     struct xen_memory_reservation reservation;
     struct memop_args args;
     domid_t domid;
-
-    op =3D cmd & MEMOP_CMD_MASK;
+    int op =3D cmd & MEMOP_CMD_MASK;
=20
     switch ( op )
     {




--=__Part6B5B1A9A.0__=
Content-Type: text/plain; name="x86-get-maximum-gpfn.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get-maximum-gpfn.patch"

x86: make certain memory sub-ops return valid values=0A=0AWhen a domain's =
shared info field "max_pfn" is zero,=0Adomain_get_maximum_gpfn() so far =
returned ULONG_MAX, which=0Ado_memory_op() in turn converted to -1 (i.e. =
-EPERM). Make the former=0Aalways return a sensible number (i.e. zero if =
the field was zero) and=0Ahave the latter no longer truncate return =
values.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -433,7 +433,7 @@ =
unsigned long domain_get_maximum_gpfn(st=0A     if ( is_hvm_domain(d) )=0A =
        return p2m_get_hostp2m(d)->max_mapped_pfn;=0A     /* NB. PV guests =
specify nr_pfns rather than max_pfn so we adjust here. */=0A-    return =
arch_get_max_pfn(d) - 1;=0A+    return (arch_get_max_pfn(d) ?: 1) - 1;=0A =
}=0A =0A void share_xen_page_with_guest(=0A--- a/xen/common/compat/memory.c=
=0A+++ b/xen/common/compat/memory.c=0A@@ -15,7 +15,8 @@ CHECK_TYPE(domid);=
=0A =0A int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void)=
 compat)=0A {=0A-    int rc, split, op =3D cmd & MEMOP_CMD_MASK;=0A+    =
int split, op =3D cmd & MEMOP_CMD_MASK;=0A+    long rc;=0A     unsigned =
int start_extent =3D cmd >> MEMOP_EXTENT_SHIFT;=0A =0A     do=0A@@ -204,7 =
+205,7 @@ int compat_memory_op(unsigned int cmd, X=0A =0A         rc =3D =
do_memory_op(cmd, nat.hnd);=0A         if ( rc < 0 )=0A-            return =
rc;=0A+            break;=0A =0A         cmd =3D 0;=0A         if ( =
hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )=0A@@ -326,5 =
+327,11 @@ int compat_memory_op(unsigned int cmd, X=0A                 =
__HYPERVISOR_memory_op, "ih", cmd, compat);=0A     } while ( split > 0 =
);=0A =0A+    if ( unlikely(rc > INT_MAX) )=0A+        return INT_MAX;=0A+=
=0A+    if ( unlikely(rc < INT_MIN) )=0A+        return INT_MIN;=0A+=0A    =
 return rc;=0A }=0A--- a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A=
@@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA=0A long =
do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)=0A {=0A  =
   struct domain *d;=0A-    int rc, op;=0A+    long rc;=0A     unsigned =
int address_bits;=0A     unsigned long start_extent;=0A     struct =
xen_memory_reservation reservation;=0A     struct memop_args args;=0A     =
domid_t domid;=0A-=0A-    op =3D cmd & MEMOP_CMD_MASK;=0A+    int op =3D =
cmd & MEMOP_CMD_MASK;=0A =0A     switch ( op )=0A     {=0A
--=__Part6B5B1A9A.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

--=__Part6B5B1A9A.0__=--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:57:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAeh5-0007As-LI; Wed, 27 Feb 2013 10:57: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 1UAeh3-0007Ad-VN
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:57:02 +0000
Received: from [85.158.138.51:39499] by server-11.bemta-3.messagelabs.com id
	83/3C-01263-D76ED215; Wed, 27 Feb 2013 10:57:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361962615!23430662!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2800 invoked from network); 27 Feb 2013 10:56:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:56:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1947091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 10:56: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.297.1;
	Wed, 27 Feb 2013 10:56:55 +0000
Message-ID: <1361962613.26546.342.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 10:56:53 +0000
In-Reply-To: <osstest-16747-mainreport@xen.org>
References: <osstest-16747-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16747: 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 Wed, 2013-02-27 at 02:18 +0000, xen.org wrote:
> flight 16747 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16747/
> 
> 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. 16226

This is the
        requesting all changes
        adding changesets
        adding manifests
        adding file changes
        transaction abort!
        rollback completed
        abort: Connection reset by peer
        make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 255
we saw earlier.

16754 also failed with 3 errors which look network / repo clone related.
Two of those look like timeouts during a git clone, the other is
apparently a network timeout during configure.

I've just killed a bunch (~30) of stale git-daemon processes (mostly
dating to the end of Jan, start of Feb) on xenbits. This may help but
these stale git-daemon processes are something we need to keep an eye on
now that we have switched fully to git...

Ian

> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
>  test-amd64-amd64-xl-sedf-pin  9 guest-start              fail blocked in 16226
>  test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-qemut-win-vcpus1 16 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-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
>  test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
>  test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
>  test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
>  test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
> 
> version targeted for testing:
>  xen                  84fa23bc6cb949fcc5d510bcaa8905d04205c916
> baseline version:
>  xen                  fb034f42648ecac835a1666def468f673edd2725
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Ian Campbell <ian.campbell@citrix.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
>  test-amd64-i386-qemut-rhel6hvm-amd                           pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemut-win7-amd64                         fail    
>  test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           pass    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-qemut-win-vcpus1                             fail    
>  test-amd64-i386-xl-qemut-win-vcpus1                          fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-amd64-amd64-qemut-win                                   fail    
>  test-amd64-i386-qemut-win                                    fail    
>  test-amd64-amd64-xl-qemut-win                                fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-amd64-i386-xend-qemut-winxpsp3                          fail    
>  test-amd64-amd64-xl-qemut-winxpsp3                           fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-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 84fa23bc6cb949fcc5d510bcaa8905d04205c916
> Author: Ian Campbell <Ian.Campbell@citrix.com>
> Date:   Tue Feb 26 10:12:46 2013 +0000
> 
>     tools: foreign: ensure 64 bit values are properly aligned for arm
>     
>     When building the foreign headers on x86_32 we use '#pragma pack(4)' and
>     therefore need to explicitly align types which should be aligned to 8-byte
>     boundaries.
>     
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> (qemu changes not included)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 10:57:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAeh5-0007As-LI; Wed, 27 Feb 2013 10:57: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 1UAeh3-0007Ad-VN
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:57:02 +0000
Received: from [85.158.138.51:39499] by server-11.bemta-3.messagelabs.com id
	83/3C-01263-D76ED215; Wed, 27 Feb 2013 10:57:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361962615!23430662!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2800 invoked from network); 27 Feb 2013 10:56:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:56:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1947091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 10:56: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.297.1;
	Wed, 27 Feb 2013 10:56:55 +0000
Message-ID: <1361962613.26546.342.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 10:56:53 +0000
In-Reply-To: <osstest-16747-mainreport@xen.org>
References: <osstest-16747-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16747: 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 Wed, 2013-02-27 at 02:18 +0000, xen.org wrote:
> flight 16747 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16747/
> 
> 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. 16226

This is the
        requesting all changes
        adding changesets
        adding manifests
        adding file changes
        transaction abort!
        rollback completed
        abort: Connection reset by peer
        make[2]: *** [linux-2.6.18-xen.hg/.valid-src] Error 255
we saw earlier.

16754 also failed with 3 errors which look network / repo clone related.
Two of those look like timeouts during a git clone, the other is
apparently a network timeout during configure.

I've just killed a bunch (~30) of stale git-daemon processes (mostly
dating to the end of Jan, start of Feb) on xenbits. This may help but
these stale git-daemon processes are something we need to keep an eye on
now that we have switched fully to git...

Ian

> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
>  test-amd64-amd64-xl-sedf-pin  9 guest-start              fail blocked in 16226
>  test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-qemut-win-vcpus1 16 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-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
>  test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
>  test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
>  test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
>  test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
> 
> version targeted for testing:
>  xen                  84fa23bc6cb949fcc5d510bcaa8905d04205c916
> baseline version:
>  xen                  fb034f42648ecac835a1666def468f673edd2725
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Ian Campbell <ian.campbell@citrix.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass    
>  build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
>  test-amd64-i386-qemut-rhel6hvm-amd                           pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemut-win7-amd64                         fail    
>  test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  test-amd64-i386-xl-multivcpu                                 pass    
>  test-amd64-amd64-pair                                        pass    
>  test-amd64-i386-pair                                         pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-i386-pv                                           pass    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-qemut-win-vcpus1                             fail    
>  test-amd64-i386-xl-qemut-win-vcpus1                          fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-amd64-amd64-qemut-win                                   fail    
>  test-amd64-i386-qemut-win                                    fail    
>  test-amd64-amd64-xl-qemut-win                                fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-amd64-i386-xend-qemut-winxpsp3                          fail    
>  test-amd64-amd64-xl-qemut-winxpsp3                           fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-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 84fa23bc6cb949fcc5d510bcaa8905d04205c916
> Author: Ian Campbell <Ian.Campbell@citrix.com>
> Date:   Tue Feb 26 10:12:46 2013 +0000
> 
>     tools: foreign: ensure 64 bit values are properly aligned for arm
>     
>     When building the foreign headers on x86_32 we use '#pragma pack(4)' and
>     therefore need to explicitly align types which should be aligned to 8-byte
>     boundaries.
>     
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> (qemu changes not included)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 10:57:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAehh-0007HU-3U; Wed, 27 Feb 2013 10:57:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAehf-0007HA-Ld
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:57:39 +0000
Received: from [85.158.137.99:40606] by server-10.bemta-3.messagelabs.com id
	D8/CD-19664-2A6ED215; Wed, 27 Feb 2013 10:57:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361962657!12699231!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6269 invoked from network); 27 Feb 2013 10:57:38 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 10:57:38 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:49967 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 1UAefX-0002BV-Ut; Wed, 27 Feb 2013 11:55:27 +0100
Date: Wed, 27 Feb 2013 11:57:33 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <38125304.20130227115733@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512C836102000078000C0FD7@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Tuesday, February 26, 2013, 9:41:53 AM, you wrote:

>>>> On 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>> It doesn't detect the s-ata controller, so it ends op with udev timing and 
>> bailing out to busybox.
>> 
>> I don't see a obvious error in the logs.

> Perhaps because the log is far from being complete? There's a huge
> gap right before the first pciback message, yet that's quite likely
> the relevant part.

Hi Jan / Konrad,

Tried bisecting, but that ended up no where, so back to the logs...

With v3.9-rc0 + xen, it's indeed missing a part of the log:
  [    4.141328] Brought up 6 CPUs
  [    4.142654] Grant tables using version 2 layout.
  [    4.142676] Grant table initialized
  [    4.142813] NET: Registered protocol family 16
  [    4.145343] node 0 link 0: io port [1000, ffffff]
  [    4.145354] TOM: 00000000b0000000 aka 2816M
  [    4.145360] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
  [    4.145373] node 0 link 0: mmio [e0000000, efffffff] ==> none
  [    4.145381] node 0 link 0: mmio [f0000000, ffffffff]
  [    4.145388] node 0 link 0: mmio [a0000, bffff]
  [    4.145395] node 0 link 0: mmio [b0000000, dfffffff]
  [    4.145401] TOM2: 0000000250000000 aka 9472M
  [    4.145406] bus: [bus 00-07] on node 0 link 0
  [    4.145411] bus: 00 [io  0x0000-0xffff]
  [    4.145415] bus: 00 [mem 0xf0000000-0xffffffff]
  [    4.145420] bus: 00 [mem 0x000a0000-0x000bffff]
  [    4.145424] bus: 00 [mem 0xb0000000-0xdfffffff]
  [    4.145429] bus: 00 [mem 0x250000000-0xfcffffffff]
  [    4.145702] ACPI: bus type pci registered
  [    4.146801] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
  [    4.146812] PCI: not using MMCONFIG
  [    4.146817] PCI: Using configuration type 1 for base access
  [    4.146822] PCI: Using configuration type 1 for extended access
  [    4.191935] bio: create slab <bio-0> at 0
  [    4.192623] ACPI: Added _OSI(Module Device)
  [    4.192630] ACPI: Added _OSI(Processor Device)
  [    4.192636] ACPI: Added _OSI(3.0 _SCP Extensions)
  [    4.192642] ACPI: Added _OSI(Processor Aggregator Device)
  [    4.195958] ACPI: EC: Look up EC in DSDT
  [    4.199659] ACPI: Executed 3 blocks of module-level executable AML code
  [    4.204162] ACPI: Interpreter enabled
  [    4.204170] ACPI: (supports S0 S5)
  [    4.204181] ACPI: Using IOAPIC for interrupt routing
  [    4.204219] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
  [    4.205800] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboa[    7.107382] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001


The line in the serial-log also seems to be truncated somehow and the rest of the info missing ..

When booting v3.9-rc0 Baremetal the complete pci enumeration seems to be in between:

[    0.288861] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.288867] PCI: not using MMCONFIG
[    0.288872] PCI: Using configuration type 1 for base access
[    0.288875] PCI: Using configuration type 1 for extended access
[    0.360826] bio: create slab <bio-0> at 0
[    0.361873] ACPI: Added _OSI(Module Device)
[    0.361883] ACPI: Added _OSI(Processor Device)
[    0.361891] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.361899] ACPI: Added _OSI(Processor Aggregator Device)
[    0.365516] ACPI: EC: Look up EC in DSDT
[    0.373572] ACPI: Executed 3 blocks of module-level executable AML code
[    0.452047] ACPI: Interpreter enabled
[    0.452052] ACPI: (supports S0 S5)
[    0.452077] ACPI: Using IOAPIC for interrupt routing
[    0.452249] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.465175] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[    0.479870] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.605451] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.609907] acpi PNP0A03:00: Requesting ACPI _OSC control (0x1d)
[    0.613973] acpi PNP0A03:00: ACPI _OSC control (0x1d) granted
[    0.617005] PCI host bridge to bus 0000:00
[    0.617027] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.617037] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.617046] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.617055] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.617064] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
[    0.617073] pci_bus 0000:00: root bus resource [mem 0xb0000000-0xdfffffff]
[    0.617081] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff]
[    0.617094] pci_bus 0000:00: scanning bus


Tried booting with pci=nommconf,nocrs but to no avail.
Are there any other boot options i could try to narrow it down ?

--
Sander

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:57:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAehh-0007HU-3U; Wed, 27 Feb 2013 10:57:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAehf-0007HA-Ld
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:57:39 +0000
Received: from [85.158.137.99:40606] by server-10.bemta-3.messagelabs.com id
	D8/CD-19664-2A6ED215; Wed, 27 Feb 2013 10:57:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-217.messagelabs.com!1361962657!12699231!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6269 invoked from network); 27 Feb 2013 10:57:38 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-3.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 10:57:38 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:49967 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 1UAefX-0002BV-Ut; Wed, 27 Feb 2013 11:55:27 +0100
Date: Wed, 27 Feb 2013 11:57:33 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <38125304.20130227115733@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512C836102000078000C0FD7@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Tuesday, February 26, 2013, 9:41:53 AM, you wrote:

>>>> On 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>> It doesn't detect the s-ata controller, so it ends op with udev timing and 
>> bailing out to busybox.
>> 
>> I don't see a obvious error in the logs.

> Perhaps because the log is far from being complete? There's a huge
> gap right before the first pciback message, yet that's quite likely
> the relevant part.

Hi Jan / Konrad,

Tried bisecting, but that ended up no where, so back to the logs...

With v3.9-rc0 + xen, it's indeed missing a part of the log:
  [    4.141328] Brought up 6 CPUs
  [    4.142654] Grant tables using version 2 layout.
  [    4.142676] Grant table initialized
  [    4.142813] NET: Registered protocol family 16
  [    4.145343] node 0 link 0: io port [1000, ffffff]
  [    4.145354] TOM: 00000000b0000000 aka 2816M
  [    4.145360] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
  [    4.145373] node 0 link 0: mmio [e0000000, efffffff] ==> none
  [    4.145381] node 0 link 0: mmio [f0000000, ffffffff]
  [    4.145388] node 0 link 0: mmio [a0000, bffff]
  [    4.145395] node 0 link 0: mmio [b0000000, dfffffff]
  [    4.145401] TOM2: 0000000250000000 aka 9472M
  [    4.145406] bus: [bus 00-07] on node 0 link 0
  [    4.145411] bus: 00 [io  0x0000-0xffff]
  [    4.145415] bus: 00 [mem 0xf0000000-0xffffffff]
  [    4.145420] bus: 00 [mem 0x000a0000-0x000bffff]
  [    4.145424] bus: 00 [mem 0xb0000000-0xdfffffff]
  [    4.145429] bus: 00 [mem 0x250000000-0xfcffffffff]
  [    4.145702] ACPI: bus type pci registered
  [    4.146801] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
  [    4.146812] PCI: not using MMCONFIG
  [    4.146817] PCI: Using configuration type 1 for base access
  [    4.146822] PCI: Using configuration type 1 for extended access
  [    4.191935] bio: create slab <bio-0> at 0
  [    4.192623] ACPI: Added _OSI(Module Device)
  [    4.192630] ACPI: Added _OSI(Processor Device)
  [    4.192636] ACPI: Added _OSI(3.0 _SCP Extensions)
  [    4.192642] ACPI: Added _OSI(Processor Aggregator Device)
  [    4.195958] ACPI: EC: Look up EC in DSDT
  [    4.199659] ACPI: Executed 3 blocks of module-level executable AML code
  [    4.204162] ACPI: Interpreter enabled
  [    4.204170] ACPI: (supports S0 S5)
  [    4.204181] ACPI: Using IOAPIC for interrupt routing
  [    4.204219] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
  [    4.205800] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboa[    7.107382] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001


The line in the serial-log also seems to be truncated somehow and the rest of the info missing ..

When booting v3.9-rc0 Baremetal the complete pci enumeration seems to be in between:

[    0.288861] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.288867] PCI: not using MMCONFIG
[    0.288872] PCI: Using configuration type 1 for base access
[    0.288875] PCI: Using configuration type 1 for extended access
[    0.360826] bio: create slab <bio-0> at 0
[    0.361873] ACPI: Added _OSI(Module Device)
[    0.361883] ACPI: Added _OSI(Processor Device)
[    0.361891] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.361899] ACPI: Added _OSI(Processor Aggregator Device)
[    0.365516] ACPI: EC: Look up EC in DSDT
[    0.373572] ACPI: Executed 3 blocks of module-level executable AML code
[    0.452047] ACPI: Interpreter enabled
[    0.452052] ACPI: (supports S0 S5)
[    0.452077] ACPI: Using IOAPIC for interrupt routing
[    0.452249] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.465175] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[    0.479870] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.605451] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.609907] acpi PNP0A03:00: Requesting ACPI _OSC control (0x1d)
[    0.613973] acpi PNP0A03:00: ACPI _OSC control (0x1d) granted
[    0.617005] PCI host bridge to bus 0000:00
[    0.617027] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.617037] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.617046] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.617055] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.617064] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
[    0.617073] pci_bus 0000:00: root bus resource [mem 0xb0000000-0xdfffffff]
[    0.617081] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff]
[    0.617094] pci_bus 0000:00: scanning bus


Tried booting with pci=nommconf,nocrs but to no avail.
Are there any other boot options i could try to narrow it down ?

--
Sander

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 10:58:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAein-0007VQ-Op; Wed, 27 Feb 2013 10:58:49 +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 1UAeil-0007V1-Sl
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:58:48 +0000
Received: from [193.109.254.147:55362] by server-13.bemta-14.messagelabs.com
	id 54/6C-30639-7E6ED215; Wed, 27 Feb 2013 10:58:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361962626!2639286!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12872 invoked from network); 27 Feb 2013 10:57:07 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:57:07 -0000
Received: by mail-wg0-f53.google.com with SMTP id fn15so328374wgb.8
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Feb 2013 02:57:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ez1+HM3cRzsjaRRH2qOILrHQKcbXPjyvbqKfzxnYSDY=;
	b=JWkQpkutrFjbViHII0qwK5gRJtP/jIE3PJ1GXqriLxsTDqd1orL79cbkz29DijWv6Y
	EILTK74ZLTnT8359Kbf3dOC0FU8gPs3DHE6JMqAn9SLgs28MHwbJVChO9tXaj34IUEGw
	F+d+8Qkor+UhAcIgkPWo3lhS4Omdg+s9S0iRC6BU5ZZeB7BVrWaOvGGOVkgMmD+8J5wV
	WSWrg6+gDBSOt0NBR+S/aAjiAL5r2LLU1s9Vym1R+Ht7pwjECJ+KYone7zla7p5qebcX
	fhVbXpF8xbZ4UYMBQjKz1pRwpTwqPorTlIqxh8cm2HTO1YibImA5JdsBnkwdM/3So9KT
	EsYw==
MIME-Version: 1.0
X-Received: by 10.180.98.232 with SMTP id el8mr25487583wib.22.1361962622930;
	Wed, 27 Feb 2013 02:57:02 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 02:57:02 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
Date: Wed, 27 Feb 2013 10:57:02 +0000
X-Google-Sender-Auth: y9ECEXH3aNHY4FeGM7h0TqerC6o
Message-ID: <CAFLBxZbpFN+U5SB8mv+g2Xyrf6Ukf=XMdOLaFR9+=OZvB-KFyw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] 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="===============6683383921589758897=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6683383921589758897==
Content-Type: multipart/alternative; boundary=f46d0442885e565c7b04d6b2a22e

--f46d0442885e565c7b04d6b2a22e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 5:57 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

>
> > I think we can engage in better expectations management.  Perhaps we
> > could rename the target.
>
> Right, that would be a step forward. Something that make it clear that
> it isn't a proper deb.
>


Right -- the description in the .deb file already tries to make clear that
"this is not a proper deb"; "make testdeb" or something like that would
hopefully make it more obvious.  ("make tardeb" maybe?)

That still won't change the fact that this is a bit of functionality that
lots of people really want.

 -George

--f46d0442885e565c7b04d6b2a22e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 26, 2013 at 5:57 PM, Stefano Stabellini <span =
dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com" target=
=3D"_blank">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><div =
class=3D"gmail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class=3D=
"im">
&gt; I think we can engage in better expectations management. =A0Perhaps we=
<br>
&gt; could rename the target.<br>
<br>
</div>Right, that would be a step forward. Something that make it clear tha=
t<br>
it isn&#39;t a proper deb.<br></blockquote><br></div><br></div><div class=
=3D"gmail_extra">Right -- the description in the .deb file already tries to=
 make clear that &quot;this is not a proper deb&quot;; &quot;make testdeb&q=
uot; or something like that would hopefully make it more obvious.=A0 (&quot=
;make tardeb&quot; maybe?)<br>
<br></div><div class=3D"gmail_extra">That still won&#39;t change the fact t=
hat this is a bit of functionality that lots of people really want.<br></di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=A0-Georg=
e<br>
</div><div class=3D"gmail_extra"><br></div></div>

--f46d0442885e565c7b04d6b2a22e--


--===============6683383921589758897==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6683383921589758897==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 10:58:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 10: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 1UAein-0007VQ-Op; Wed, 27 Feb 2013 10:58:49 +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 1UAeil-0007V1-Sl
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 10:58:48 +0000
Received: from [193.109.254.147:55362] by server-13.bemta-14.messagelabs.com
	id 54/6C-30639-7E6ED215; Wed, 27 Feb 2013 10:58:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361962626!2639286!1
X-Originating-IP: [74.125.82.53]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12872 invoked from network); 27 Feb 2013 10:57:07 -0000
Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com)
	(74.125.82.53)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 10:57:07 -0000
Received: by mail-wg0-f53.google.com with SMTP id fn15so328374wgb.8
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Feb 2013 02:57:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ez1+HM3cRzsjaRRH2qOILrHQKcbXPjyvbqKfzxnYSDY=;
	b=JWkQpkutrFjbViHII0qwK5gRJtP/jIE3PJ1GXqriLxsTDqd1orL79cbkz29DijWv6Y
	EILTK74ZLTnT8359Kbf3dOC0FU8gPs3DHE6JMqAn9SLgs28MHwbJVChO9tXaj34IUEGw
	F+d+8Qkor+UhAcIgkPWo3lhS4Omdg+s9S0iRC6BU5ZZeB7BVrWaOvGGOVkgMmD+8J5wV
	WSWrg6+gDBSOt0NBR+S/aAjiAL5r2LLU1s9Vym1R+Ht7pwjECJ+KYone7zla7p5qebcX
	fhVbXpF8xbZ4UYMBQjKz1pRwpTwqPorTlIqxh8cm2HTO1YibImA5JdsBnkwdM/3So9KT
	EsYw==
MIME-Version: 1.0
X-Received: by 10.180.98.232 with SMTP id el8mr25487583wib.22.1361962622930;
	Wed, 27 Feb 2013 02:57:02 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 02:57:02 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
Date: Wed, 27 Feb 2013 10:57:02 +0000
X-Google-Sender-Auth: y9ECEXH3aNHY4FeGM7h0TqerC6o
Message-ID: <CAFLBxZbpFN+U5SB8mv+g2Xyrf6Ukf=XMdOLaFR9+=OZvB-KFyw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v2] 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="===============6683383921589758897=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6683383921589758897==
Content-Type: multipart/alternative; boundary=f46d0442885e565c7b04d6b2a22e

--f46d0442885e565c7b04d6b2a22e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 5:57 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

>
> > I think we can engage in better expectations management.  Perhaps we
> > could rename the target.
>
> Right, that would be a step forward. Something that make it clear that
> it isn't a proper deb.
>


Right -- the description in the .deb file already tries to make clear that
"this is not a proper deb"; "make testdeb" or something like that would
hopefully make it more obvious.  ("make tardeb" maybe?)

That still won't change the fact that this is a bit of functionality that
lots of people really want.

 -George

--f46d0442885e565c7b04d6b2a22e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 26, 2013 at 5:57 PM, Stefano Stabellini <span =
dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.com" target=
=3D"_blank">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><div =
class=3D"gmail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class=3D=
"im">
&gt; I think we can engage in better expectations management. =A0Perhaps we=
<br>
&gt; could rename the target.<br>
<br>
</div>Right, that would be a step forward. Something that make it clear tha=
t<br>
it isn&#39;t a proper deb.<br></blockquote><br></div><br></div><div class=
=3D"gmail_extra">Right -- the description in the .deb file already tries to=
 make clear that &quot;this is not a proper deb&quot;; &quot;make testdeb&q=
uot; or something like that would hopefully make it more obvious.=A0 (&quot=
;make tardeb&quot; maybe?)<br>
<br></div><div class=3D"gmail_extra">That still won&#39;t change the fact t=
hat this is a bit of functionality that lots of people really want.<br></di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=A0-Georg=
e<br>
</div><div class=3D"gmail_extra"><br></div></div>

--f46d0442885e565c7b04d6b2a22e--


--===============6683383921589758897==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6683383921589758897==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 11:01:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:01: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 1UAeks-0007km-B2; Wed, 27 Feb 2013 11:00:58 +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 1UAekr-0007kb-0M
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:00:57 +0000
Received: from [85.158.137.99:46762] by server-3.bemta-3.messagelabs.com id
	5D/E5-26934-667ED215; Wed, 27 Feb 2013 11:00:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361962849!18236180!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16280 invoked from network); 27 Feb 2013 11:00:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 11:00:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:58:49 +0000
Message-Id: <512DF4F602000078000C16E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:58:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 27.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> This work around an issue when test via xen-mceinj tools.
>>> 
>>> when inject simulated error via xen-mceinj tools,
>>> status ADDRV/MISCV bits are simulated hence there is
>>> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>>> We temporarily work around by not clean them until we have
>>> clean solution.
>> 
>> Excuse me, but - no. Changing the behavior for real MCE-s (which
>> you added) for the benefit of fixing injection is a no-go IMO. Or
>> are you telling us that after all that earlier change of yours is not
>> really necessary (in which case we could as well revert it).
>> 
>> Jan
>> 
> 
> The reason of the former patch to clear MCi_ADDR/MISC is that it's 
> recommended by Intel SDM:
> 		LOG MCA REGISTER:
> 		SAVE IA32_MCi_STATUS;
> 		If MISCV in IA32_MCi_STATUS
> 		THEN
> 			SAVE IA32_MCi_MISC;
> 		FI;
> 		IF ADDRV in IA32_MCi_STATUS
> 		THEN
> 			SAVE IA32_MCi_ADDR;
> 		FI;
> 		IF CLEAR_MC_BANK = TRUE
> 		THEN
> 			SET all 0 to IA32_MCi_STATUS;
> 		If MISCV in IA32_MCi_STATUS
> 		THEN
> 			SET all 0 to IA32_MCi_MISC;
> 		FI;
> 		IF ADDRV in IA32_MCi_STATUS
> 		THEN
> 			SET all 0 to IA32_MCi_ADDR;
> 		FI;
> 
> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real error 
> occur (which indicated by MCi_STATUS), so only clear MCi_STATUS at mce 
> handler is an acceptable work around -- after all, to read MCi_ADDR/MISC is 
> pointless if MCi_STATUS is 0.

So then what - revert your original patch (and ignore the SDM)?
I'm not in favor of this...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:01:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:01: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 1UAeks-0007km-B2; Wed, 27 Feb 2013 11:00:58 +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 1UAekr-0007kb-0M
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:00:57 +0000
Received: from [85.158.137.99:46762] by server-3.bemta-3.messagelabs.com id
	5D/E5-26934-667ED215; Wed, 27 Feb 2013 11:00:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1361962849!18236180!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16280 invoked from network); 27 Feb 2013 11:00:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 11:00:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 10:58:49 +0000
Message-Id: <512DF4F602000078000C16E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 10:58:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 27.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> This work around an issue when test via xen-mceinj tools.
>>> 
>>> when inject simulated error via xen-mceinj tools,
>>> status ADDRV/MISCV bits are simulated hence there is
>>> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>>> We temporarily work around by not clean them until we have
>>> clean solution.
>> 
>> Excuse me, but - no. Changing the behavior for real MCE-s (which
>> you added) for the benefit of fixing injection is a no-go IMO. Or
>> are you telling us that after all that earlier change of yours is not
>> really necessary (in which case we could as well revert it).
>> 
>> Jan
>> 
> 
> The reason of the former patch to clear MCi_ADDR/MISC is that it's 
> recommended by Intel SDM:
> 		LOG MCA REGISTER:
> 		SAVE IA32_MCi_STATUS;
> 		If MISCV in IA32_MCi_STATUS
> 		THEN
> 			SAVE IA32_MCi_MISC;
> 		FI;
> 		IF ADDRV in IA32_MCi_STATUS
> 		THEN
> 			SAVE IA32_MCi_ADDR;
> 		FI;
> 		IF CLEAR_MC_BANK = TRUE
> 		THEN
> 			SET all 0 to IA32_MCi_STATUS;
> 		If MISCV in IA32_MCi_STATUS
> 		THEN
> 			SET all 0 to IA32_MCi_MISC;
> 		FI;
> 		IF ADDRV in IA32_MCi_STATUS
> 		THEN
> 			SET all 0 to IA32_MCi_ADDR;
> 		FI;
> 
> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real error 
> occur (which indicated by MCi_STATUS), so only clear MCi_STATUS at mce 
> handler is an acceptable work around -- after all, to read MCi_ADDR/MISC is 
> pointless if MCi_STATUS is 0.

So then what - revert your original patch (and ignore the SDM)?
I'm not in favor of this...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:06:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAeqF-00085Z-47; Wed, 27 Feb 2013 11:06: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 1UAeqD-00085U-Lq
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:06:29 +0000
Received: from [85.158.139.83:43264] by server-16.bemta-5.messagelabs.com id
	EE/26-02543-4B8ED215; Wed, 27 Feb 2013 11:06:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361963188!29227989!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6948 invoked from network); 27 Feb 2013 11:06:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:06:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1947578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:06: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.297.1;
	Wed, 27 Feb 2013 11:06:28 +0000
Message-ID: <1361963183.26546.347.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 11:06:23 +0000
In-Reply-To: <CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
References: <E1UAQgp-0004rV-FS@xenbits.xen.org>
	<CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-changelog] [xen stable-4.2]
 QEMU_UPSTREAM_REVISION update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 20:50 +0000, Teck Choon Giam wrote:
> Hi,
> 
> Just a question below.
> 
> 
> On Wed, Feb 27, 2013 at 3:59 AM,  <patchbot@xen.org> wrote:
> > commit a667d82549e99e9bd409a351964c2da6e64eb68c
> > Author:     Ian Jackson <ian.jackson@eu.citrix.com>
> > AuthorDate: Fri Feb 22 17:57:45 2013 +0000
> > Commit:     Ian Jackson <Ian.Jackson@eu.citrix.com>
> > CommitDate: Fri Feb 22 17:57:45 2013 +0000
> >
> >     QEMU_UPSTREAM_REVISION update
> > ---
> >  Config.mk |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Config.mk b/Config.mk
> > index ead4da2..dd07341 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -203,7 +203,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-4.2-testing.git
> >  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> >  endif
> >  OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871
> > -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.2.1
> > +QEMU_UPSTREAM_REVISION ?= eccc68722696864fc4823f048c7be58d11281b97
> 
> Is the above commit id updated in
> git://xenbits.xen.org/qemu-upstream-4.2-testing.git ?  From
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=summary
> I can't see any git commit id related to
> eccc68722696864fc4823f048c7be58d11281b97 or I am wrong about it?

Commits are made to the staging tree
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.2-testing.git;a=summary and should be pushed when automated testing has passed. However this seems to have not happened here. CCing Ian.


> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon
> 
> 
> 
> >  SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
> >  # Sun Mar 11 09:27:07 2012 -0400
> >  # Update version to 1.6.3.2
> > --
> > generated by git-patchbot for /home/xen/git/xen.git#stable-4.2
> >
> > _______________________________________________
> > Xen-changelog mailing list
> > Xen-changelog@lists.xen.org
> > http://lists.xensource.com/xen-changelog
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 11:06:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAeqF-00085Z-47; Wed, 27 Feb 2013 11:06: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 1UAeqD-00085U-Lq
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:06:29 +0000
Received: from [85.158.139.83:43264] by server-16.bemta-5.messagelabs.com id
	EE/26-02543-4B8ED215; Wed, 27 Feb 2013 11:06:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1361963188!29227989!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6948 invoked from network); 27 Feb 2013 11:06:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:06:28 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1947578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:06: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.297.1;
	Wed, 27 Feb 2013 11:06:28 +0000
Message-ID: <1361963183.26546.347.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 11:06:23 +0000
In-Reply-To: <CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
References: <E1UAQgp-0004rV-FS@xenbits.xen.org>
	<CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-changelog] [xen stable-4.2]
 QEMU_UPSTREAM_REVISION update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 20:50 +0000, Teck Choon Giam wrote:
> Hi,
> 
> Just a question below.
> 
> 
> On Wed, Feb 27, 2013 at 3:59 AM,  <patchbot@xen.org> wrote:
> > commit a667d82549e99e9bd409a351964c2da6e64eb68c
> > Author:     Ian Jackson <ian.jackson@eu.citrix.com>
> > AuthorDate: Fri Feb 22 17:57:45 2013 +0000
> > Commit:     Ian Jackson <Ian.Jackson@eu.citrix.com>
> > CommitDate: Fri Feb 22 17:57:45 2013 +0000
> >
> >     QEMU_UPSTREAM_REVISION update
> > ---
> >  Config.mk |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Config.mk b/Config.mk
> > index ead4da2..dd07341 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -203,7 +203,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-4.2-testing.git
> >  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> >  endif
> >  OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871
> > -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.2.1
> > +QEMU_UPSTREAM_REVISION ?= eccc68722696864fc4823f048c7be58d11281b97
> 
> Is the above commit id updated in
> git://xenbits.xen.org/qemu-upstream-4.2-testing.git ?  From
> http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=summary
> I can't see any git commit id related to
> eccc68722696864fc4823f048c7be58d11281b97 or I am wrong about it?

Commits are made to the staging tree
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.2-testing.git;a=summary and should be pushed when automated testing has passed. However this seems to have not happened here. CCing Ian.


> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon
> 
> 
> 
> >  SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.2
> >  # Sun Mar 11 09:27:07 2012 -0400
> >  # Update version to 1.6.3.2
> > --
> > generated by git-patchbot for /home/xen/git/xen.git#stable-4.2
> >
> > _______________________________________________
> > Xen-changelog mailing list
> > Xen-changelog@lists.xen.org
> > http://lists.xensource.com/xen-changelog
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 11:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:07: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 1UAer3-00088h-L7; Wed, 27 Feb 2013 11:07:21 +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 1UAer2-00088W-HV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:07:20 +0000
Received: from [85.158.137.99:65294] by server-5.bemta-3.messagelabs.com id
	D7/2A-30636-7E8ED215; Wed, 27 Feb 2013 11:07:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361963214!17487806!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24582 invoked from network); 27 Feb 2013 11:06:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1947601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:06: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.297.1;
	Wed, 27 Feb 2013 11:06:54 +0000
Message-ID: <1361963213.26546.348.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Date: Wed, 27 Feb 2013 11:06:53 +0000
In-Reply-To: <B6C2EB9186482D47BD0C5A9A483456440343F776@SHSMSX101.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
	<1361893836.26546.304.camel@zakaz.uk.xensource.com>
	<B6C2EB9186482D47BD0C5A9A483456440343F776@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Hao,
	Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 not sure about qemu-devel but on xen-devel the policy is not to top
post so please could you avoid doping so.

On Wed, 2013-02-27 at 09:49 +0000, Zhang, Xiantao wrote:
> > Given that Xen has at least two other mechanisms (xenstore and
> > hvmparams) for passing this sort of information around I'm not sure why
> > hacking the emulated i440fx device should be the preferred option.
> 
> Actually, even in hardware,  I believe there are many registers which
> are implemented with write-once attributes, and they are only used by
> firmware and reserved for OS.

The i440fx does not have this register (be it write once or otherwise),
which is my actual point -- you are adding a magic property to the
emulation of this device which the real hardware doesn't have. It isn't
really relevant that other hardware could implement write once
registers, that's obviously the case.

> In addition,  with this change,  it can benefit all VMMs (not just
> Xen) which use Qemu as device model.  If adopt xenstore way, perhaps
> other VMMs also have to write similar and duplicate logic for the same
> purpose.

Which other VMM? AIUI qemu/kvm doesn't have a requirement to communicate
this information from the VMM to qemu because qemu is the VMM and
controls all of the hardware resources.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:07:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:07: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 1UAer3-00088h-L7; Wed, 27 Feb 2013 11:07:21 +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 1UAer2-00088W-HV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:07:20 +0000
Received: from [85.158.137.99:65294] by server-5.bemta-3.messagelabs.com id
	D7/2A-30636-7E8ED215; Wed, 27 Feb 2013 11:07:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361963214!17487806!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24582 invoked from network); 27 Feb 2013 11:06:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1947601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:06: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.297.1;
	Wed, 27 Feb 2013 11:06:54 +0000
Message-ID: <1361963213.26546.348.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Date: Wed, 27 Feb 2013 11:06:53 +0000
In-Reply-To: <B6C2EB9186482D47BD0C5A9A483456440343F776@SHSMSX101.ccr.corp.intel.com>
References: <1361775217-3454-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1302251600180.5360@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FF7C10B@SHSMSX102.ccr.corp.intel.com>
	<B6C2EB9186482D47BD0C5A9A483456440343CD1C@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1302261540160.5360@kaball.uk.xensource.com>
	<1361893836.26546.304.camel@zakaz.uk.xensource.com>
	<B6C2EB9186482D47BD0C5A9A483456440343F776@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"mst@redhat.com" <mst@redhat.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Hao,
	Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"afaerber@suse.de" <afaerber@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2] piix: define a TOM register
 to report the base of PCI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 not sure about qemu-devel but on xen-devel the policy is not to top
post so please could you avoid doping so.

On Wed, 2013-02-27 at 09:49 +0000, Zhang, Xiantao wrote:
> > Given that Xen has at least two other mechanisms (xenstore and
> > hvmparams) for passing this sort of information around I'm not sure why
> > hacking the emulated i440fx device should be the preferred option.
> 
> Actually, even in hardware,  I believe there are many registers which
> are implemented with write-once attributes, and they are only used by
> firmware and reserved for OS.

The i440fx does not have this register (be it write once or otherwise),
which is my actual point -- you are adding a magic property to the
emulation of this device which the real hardware doesn't have. It isn't
really relevant that other hardware could implement write once
registers, that's obviously the case.

> In addition,  with this change,  it can benefit all VMMs (not just
> Xen) which use Qemu as device model.  If adopt xenstore way, perhaps
> other VMMs also have to write similar and duplicate logic for the same
> purpose.

Which other VMM? AIUI qemu/kvm doesn't have a requirement to communicate
this information from the VMM to qemu because qemu is the VMM and
controls all of the hardware resources.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:08:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:08: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 1UAesE-0008FR-5l; Wed, 27 Feb 2013 11:08: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 1UAesC-0008FH-0K
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:08:32 +0000
Received: from [85.158.143.99:62155] by server-2.bemta-4.messagelabs.com id
	92/82-12656-F29ED215; Wed, 27 Feb 2013 11:08:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361963194!24193003!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1346 invoked from network); 27 Feb 2013 11:06:35 -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; 27 Feb 2013 11:06:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 11:06:34 +0000
Message-Id: <512DF6C702000078000C1708@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 11:06:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
In-Reply-To: <38125304.20130227115733@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 27.02.13 at 11:57, Sander Eikelenboom <linux@eikelenboom.it> wrote:

> Tuesday, February 26, 2013, 9:41:53 AM, you wrote:
> 
>>>>> On 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>>> It doesn't detect the s-ata controller, so it ends op with udev timing and 
>>> bailing out to busybox.
>>> 
>>> I don't see a obvious error in the logs.
> 
>> Perhaps because the log is far from being complete? There's a huge
>> gap right before the first pciback message, yet that's quite likely
>> the relevant part.
> 
> Hi Jan / Konrad,
> 
> Tried bisecting, but that ended up no where, so back to the logs...
> 
> With v3.9-rc0 + xen, it's indeed missing a part of the log:
>   [    4.141328] Brought up 6 CPUs
>   [    4.142654] Grant tables using version 2 layout.
>   [    4.142676] Grant table initialized
>   [    4.142813] NET: Registered protocol family 16
>   [    4.145343] node 0 link 0: io port [1000, ffffff]
>   [    4.145354] TOM: 00000000b0000000 aka 2816M
>   [    4.145360] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
>   [    4.145373] node 0 link 0: mmio [e0000000, efffffff] ==> none
>   [    4.145381] node 0 link 0: mmio [f0000000, ffffffff]
>   [    4.145388] node 0 link 0: mmio [a0000, bffff]
>   [    4.145395] node 0 link 0: mmio [b0000000, dfffffff]
>   [    4.145401] TOM2: 0000000250000000 aka 9472M
>   [    4.145406] bus: [bus 00-07] on node 0 link 0
>   [    4.145411] bus: 00 [io  0x0000-0xffff]
>   [    4.145415] bus: 00 [mem 0xf0000000-0xffffffff]
>   [    4.145420] bus: 00 [mem 0x000a0000-0x000bffff]
>   [    4.145424] bus: 00 [mem 0xb0000000-0xdfffffff]
>   [    4.145429] bus: 00 [mem 0x250000000-0xfcffffffff]
>   [    4.145702] ACPI: bus type pci registered
>   [    4.146801] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 
> 0xe0000000-0xefffffff] (base 0xe0000000)
>   [    4.146812] PCI: not using MMCONFIG
>   [    4.146817] PCI: Using configuration type 1 for base access
>   [    4.146822] PCI: Using configuration type 1 for extended access
>   [    4.191935] bio: create slab <bio-0> at 0
>   [    4.192623] ACPI: Added _OSI(Module Device)
>   [    4.192630] ACPI: Added _OSI(Processor Device)
>   [    4.192636] ACPI: Added _OSI(3.0 _SCP Extensions)
>   [    4.192642] ACPI: Added _OSI(Processor Aggregator Device)
>   [    4.195958] ACPI: EC: Look up EC in DSDT
>   [    4.199659] ACPI: Executed 3 blocks of module-level executable AML code
>   [    4.204162] ACPI: Interpreter enabled
>   [    4.204170] ACPI: (supports S0 S5)
>   [    4.204181] ACPI: Using IOAPIC for interrupt routing
>   [    4.204219] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 
> 0xe0000000-0xefffffff] (base 0xe0000000)
>   [    4.205800] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in 
> ACPI motherboa[    7.107382] usb usb5: New USB device found, idVendor=1d6b, 
> idProduct=0001
> 
> 
> The line in the serial-log also seems to be truncated somehow and the rest of 
> the info missing ..
> 
> When booting v3.9-rc0 Baremetal the complete pci enumeration seems to be in 
> between:
> ...
> Tried booting with pci=nommconf,nocrs but to no avail.
> Are there any other boot options i could try to narrow it down ?

You first of all want to make sure you get a complete log.
"sync_console" or "serial_tx_buffer=<size>" are your friends...

But then again I would guess it's not bus enumeration related.
Did the multiple-MSI-vectors suspicion lead nowhere?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:08:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:08: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 1UAesE-0008FR-5l; Wed, 27 Feb 2013 11:08: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 1UAesC-0008FH-0K
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:08:32 +0000
Received: from [85.158.143.99:62155] by server-2.bemta-4.messagelabs.com id
	92/82-12656-F29ED215; Wed, 27 Feb 2013 11:08:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361963194!24193003!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1346 invoked from network); 27 Feb 2013 11:06:35 -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; 27 Feb 2013 11:06:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 11:06:34 +0000
Message-Id: <512DF6C702000078000C1708@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 11:06:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
In-Reply-To: <38125304.20130227115733@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 27.02.13 at 11:57, Sander Eikelenboom <linux@eikelenboom.it> wrote:

> Tuesday, February 26, 2013, 9:41:53 AM, you wrote:
> 
>>>>> On 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>>> It doesn't detect the s-ata controller, so it ends op with udev timing and 
>>> bailing out to busybox.
>>> 
>>> I don't see a obvious error in the logs.
> 
>> Perhaps because the log is far from being complete? There's a huge
>> gap right before the first pciback message, yet that's quite likely
>> the relevant part.
> 
> Hi Jan / Konrad,
> 
> Tried bisecting, but that ended up no where, so back to the logs...
> 
> With v3.9-rc0 + xen, it's indeed missing a part of the log:
>   [    4.141328] Brought up 6 CPUs
>   [    4.142654] Grant tables using version 2 layout.
>   [    4.142676] Grant table initialized
>   [    4.142813] NET: Registered protocol family 16
>   [    4.145343] node 0 link 0: io port [1000, ffffff]
>   [    4.145354] TOM: 00000000b0000000 aka 2816M
>   [    4.145360] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
>   [    4.145373] node 0 link 0: mmio [e0000000, efffffff] ==> none
>   [    4.145381] node 0 link 0: mmio [f0000000, ffffffff]
>   [    4.145388] node 0 link 0: mmio [a0000, bffff]
>   [    4.145395] node 0 link 0: mmio [b0000000, dfffffff]
>   [    4.145401] TOM2: 0000000250000000 aka 9472M
>   [    4.145406] bus: [bus 00-07] on node 0 link 0
>   [    4.145411] bus: 00 [io  0x0000-0xffff]
>   [    4.145415] bus: 00 [mem 0xf0000000-0xffffffff]
>   [    4.145420] bus: 00 [mem 0x000a0000-0x000bffff]
>   [    4.145424] bus: 00 [mem 0xb0000000-0xdfffffff]
>   [    4.145429] bus: 00 [mem 0x250000000-0xfcffffffff]
>   [    4.145702] ACPI: bus type pci registered
>   [    4.146801] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 
> 0xe0000000-0xefffffff] (base 0xe0000000)
>   [    4.146812] PCI: not using MMCONFIG
>   [    4.146817] PCI: Using configuration type 1 for base access
>   [    4.146822] PCI: Using configuration type 1 for extended access
>   [    4.191935] bio: create slab <bio-0> at 0
>   [    4.192623] ACPI: Added _OSI(Module Device)
>   [    4.192630] ACPI: Added _OSI(Processor Device)
>   [    4.192636] ACPI: Added _OSI(3.0 _SCP Extensions)
>   [    4.192642] ACPI: Added _OSI(Processor Aggregator Device)
>   [    4.195958] ACPI: EC: Look up EC in DSDT
>   [    4.199659] ACPI: Executed 3 blocks of module-level executable AML code
>   [    4.204162] ACPI: Interpreter enabled
>   [    4.204170] ACPI: (supports S0 S5)
>   [    4.204181] ACPI: Using IOAPIC for interrupt routing
>   [    4.204219] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 
> 0xe0000000-0xefffffff] (base 0xe0000000)
>   [    4.205800] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in 
> ACPI motherboa[    7.107382] usb usb5: New USB device found, idVendor=1d6b, 
> idProduct=0001
> 
> 
> The line in the serial-log also seems to be truncated somehow and the rest of 
> the info missing ..
> 
> When booting v3.9-rc0 Baremetal the complete pci enumeration seems to be in 
> between:
> ...
> Tried booting with pci=nommconf,nocrs but to no avail.
> Are there any other boot options i could try to narrow it down ?

You first of all want to make sure you get a complete log.
"sync_console" or "serial_tx_buffer=<size>" are your friends...

But then again I would guess it's not bus enumeration related.
Did the multiple-MSI-vectors suspicion lead nowhere?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:09:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:09: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 1UAesv-0008KO-LG; Wed, 27 Feb 2013 11:09:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAesu-0008KB-U9
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:09:17 +0000
Received: from [85.158.139.83:16179] by server-10.bemta-5.messagelabs.com id
	7B/66-23714-C59ED215; Wed, 27 Feb 2013 11:09:16 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361963327!17916209!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU5Njc2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23817 invoked from network); 27 Feb 2013 11:08:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-182.messagelabs.com with SMTP;
	27 Feb 2013 11:08:48 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 27 Feb 2013 03:08:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="262050404"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by azsmga001.ch.intel.com with ESMTP; 27 Feb 2013 03:08:46 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 03:08:46 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX103.ccr.corp.intel.com ([10.239.4.69]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 19:08:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFNlqqZTiEd/FTjyR1sPJXJqZr5iNilNA
Date: Wed, 27 Feb 2013 11:08:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
In-Reply-To: <512DF4F602000078000C16E3@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 27.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> This work around an issue when test via xen-mceinj tools.
>>>> 
>>>> when inject simulated error via xen-mceinj tools,
>>>> status ADDRV/MISCV bits are simulated hence there is
>>>> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>>>> We temporarily work around by not clean them until we have
>>>> clean solution.
>>> 
>>> Excuse me, but - no. Changing the behavior for real MCE-s (which
>>> you added) for the benefit of fixing injection is a no-go IMO. Or
>>> are you telling us that after all that earlier change of yours is
>>> not really necessary (in which case we could as well revert it).
>>> 
>>> Jan
>>> 
>> 
>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>> 		recommended by Intel SDM: LOG MCA REGISTER:
>> 		SAVE IA32_MCi_STATUS;
>> 		If MISCV in IA32_MCi_STATUS
>> 		THEN
>> 			SAVE IA32_MCi_MISC;
>> 		FI;
>> 		IF ADDRV in IA32_MCi_STATUS
>> 		THEN
>> 			SAVE IA32_MCi_ADDR;
>> 		FI;
>> 		IF CLEAR_MC_BANK = TRUE
>> 		THEN
>> 			SET all 0 to IA32_MCi_STATUS;
>> 		If MISCV in IA32_MCi_STATUS
>> 		THEN
>> 			SET all 0 to IA32_MCi_MISC;
>> 		FI;
>> 		IF ADDRV in IA32_MCi_STATUS
>> 		THEN
>> 			SET all 0 to IA32_MCi_ADDR;
>> 		FI;
>> 
>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>> error occur (which indicated by MCi_STATUS), so only clear
>> MCi_STATUS at mce handler is an acceptable work around -- after all,
>> to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
> 
> So then what - revert your original patch (and ignore the SDM)?
> I'm not in favor of this...
> 
> Jan

Not revert entire 23327, but only use this patch to revert MCi_ADDR/MISC clear.

I also agree it's not good, but currently seems we don't have a simple and clean way to fix it, except we spend much time to to update xen-mceinj *tools* -- even so it's low-priority?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:09:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:09: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 1UAesv-0008KO-LG; Wed, 27 Feb 2013 11:09:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAesu-0008KB-U9
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:09:17 +0000
Received: from [85.158.139.83:16179] by server-10.bemta-5.messagelabs.com id
	7B/66-23714-C59ED215; Wed, 27 Feb 2013 11:09:16 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1361963327!17916209!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjU5Njc2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23817 invoked from network); 27 Feb 2013 11:08:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-8.tower-182.messagelabs.com with SMTP;
	27 Feb 2013 11:08:48 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 27 Feb 2013 03:08:47 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,746,1355126400"; d="scan'208";a="262050404"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by azsmga001.ch.intel.com with ESMTP; 27 Feb 2013 03:08:46 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 03:08:46 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX103.ccr.corp.intel.com ([10.239.4.69]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 19:08:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFNlqqZTiEd/FTjyR1sPJXJqZr5iNilNA
Date: Wed, 27 Feb 2013 11:08:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
In-Reply-To: <512DF4F602000078000C16E3@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 27.02.13 at 10:24, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> This work around an issue when test via xen-mceinj tools.
>>>> 
>>>> when inject simulated error via xen-mceinj tools,
>>>> status ADDRV/MISCV bits are simulated hence there is
>>>> potential risk of #GP if h/w not really support MCi_ADDR/MISC.
>>>> We temporarily work around by not clean them until we have
>>>> clean solution.
>>> 
>>> Excuse me, but - no. Changing the behavior for real MCE-s (which
>>> you added) for the benefit of fixing injection is a no-go IMO. Or
>>> are you telling us that after all that earlier change of yours is
>>> not really necessary (in which case we could as well revert it).
>>> 
>>> Jan
>>> 
>> 
>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>> 		recommended by Intel SDM: LOG MCA REGISTER:
>> 		SAVE IA32_MCi_STATUS;
>> 		If MISCV in IA32_MCi_STATUS
>> 		THEN
>> 			SAVE IA32_MCi_MISC;
>> 		FI;
>> 		IF ADDRV in IA32_MCi_STATUS
>> 		THEN
>> 			SAVE IA32_MCi_ADDR;
>> 		FI;
>> 		IF CLEAR_MC_BANK = TRUE
>> 		THEN
>> 			SET all 0 to IA32_MCi_STATUS;
>> 		If MISCV in IA32_MCi_STATUS
>> 		THEN
>> 			SET all 0 to IA32_MCi_MISC;
>> 		FI;
>> 		IF ADDRV in IA32_MCi_STATUS
>> 		THEN
>> 			SET all 0 to IA32_MCi_ADDR;
>> 		FI;
>> 
>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>> error occur (which indicated by MCi_STATUS), so only clear
>> MCi_STATUS at mce handler is an acceptable work around -- after all,
>> to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
> 
> So then what - revert your original patch (and ignore the SDM)?
> I'm not in favor of this...
> 
> Jan

Not revert entire 23327, but only use this patch to revert MCi_ADDR/MISC clear.

I also agree it's not good, but currently seems we don't have a simple and clean way to fix it, except we spend much time to to update xen-mceinj *tools* -- even so it's low-priority?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:15:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAeyx-0000IB-In; Wed, 27 Feb 2013 11:15:31 +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 1UAeyv-0000I6-T5
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:15:30 +0000
Received: from [85.158.139.211:6400] by server-11.bemta-5.messagelabs.com id
	F0/21-27486-1DAED215; Wed, 27 Feb 2013 11:15:29 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361963727!19533341!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1714 invoked from network); 27 Feb 2013 11:15:27 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 11:15:27 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id C885B4008FF;
	Wed, 27 Feb 2013 12:15:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id AzYVlb0i0POu; Wed, 27 Feb 2013 12:15:24 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 9A57C4007E4;
	Wed, 27 Feb 2013 12:15:23 +0100 (CET)
Message-ID: <512DEAC9.2040002@tiscali.it>
Date: Wed, 27 Feb 2013 12:15:21 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============6394681732118377062=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============6394681732118377062==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010207010605010906040309"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms010207010605010906040309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/02/2013 23:26, James Harper ha scritto:
>> I have tried to build gplpv from source with makedist.bat but it gave =
me
>> some errors about files not found.
>> I saw that latest commits were big. Is there something incomplete and
>> must I wait other commits before build it?
> It's possible I missed a commit but I can't see any missing files.
>
> Can you post the output of makedist?
>
> But yes the latest commits involve a pretty major change and I haven't =
tested save/restore yet so that is probably more broken than before.
>
>> I would like to see if new build fix network not working after restore=

>> on windows domUs using upstream qemu.
>> Dom0 is wheezy with xen-unstable from source.
>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
>> error on xen for now, probably is problem of gplpv with qemu upstream.=

>> Linux hvm domUs seem not have that problem, tested with quantal (ubunt=
u
>> 12.10) and network works also after restore.
>> If you need more details and tests tell me and I'll post it.

Are there news about this problem? This is the last critical problem=20
remained with upstream qemu on my tests and only present with windows dom=
U.
I saw another related post days ago with probably same problem you can't =

reproduce.
http://lists.xen.org/archives/html/xen-users/2013-02/msg00278.html
Do you need more details about my dom0 and domU xl cfg?

>>
>> Another problem present on both traditional/upstream qemu  with
>> older/new xen and  older/new gplpv is domU's time not correctly update=
d
>> after restore (it remains the time at the save operation), this is a b=
ig
>> problem with windows domUs (DC and client) in a windows domain where
>> the time source is DC by default.
> I noticed that recently. I can't think how it could be a GPLPV bug thou=
gh.
>
>
> James
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2899 / Database dei virus: 2639/6101 -  Data di rilasc=
io: 13/02/2013
>
>
>



--------------ms010207010605010906040309
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyNzExMTUyMVowIwYJKoZIhvcNAQkEMRYEFKzMoFZre8c+gU1IZpf1/aop
jdaXMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAH3XQ44k9CiQ3rw3+gQEweTup
pTaxcVKxPp8mskM7ON3mBp+vcky15UpFQt7Ce1fFXwQLv9N3+Gqqb4s9yCqfCeRI2gJTFMFB
mzm4bzCYXP11Mko1knls52qI9xIEpLR7lY0ASci9M2ZJzCrb89lTZQMqWojFd+qQWRgrp6YU
k1ybP3LaguPlsWq1wmUAWalUMoD7Rw1CEMWAvY6biNq7ejPZsMjIB3MUcLV9XcM6ZbX2GqU7
j2S5GfIwLfTMpj4Fff3g5bO05XZnqCnMeOn+d7MhbExv6jOfzRcx650qlad2QjWYEjiOtHjB
dFlrEByGp4ia+2j2ARXmmlDu08zfmQAAAAAAAA==
--------------ms010207010605010906040309--


--===============6394681732118377062==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6394681732118377062==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 11:15:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAeyx-0000IB-In; Wed, 27 Feb 2013 11:15:31 +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 1UAeyv-0000I6-T5
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:15:30 +0000
Received: from [85.158.139.211:6400] by server-11.bemta-5.messagelabs.com id
	F0/21-27486-1DAED215; Wed, 27 Feb 2013 11:15:29 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1361963727!19533341!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1714 invoked from network); 27 Feb 2013 11:15:27 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 11:15:27 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id C885B4008FF;
	Wed, 27 Feb 2013 12:15:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id AzYVlb0i0POu; Wed, 27 Feb 2013 12:15:24 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 9A57C4007E4;
	Wed, 27 Feb 2013 12:15:23 +0100 (CET)
Message-ID: <512DEAC9.2040002@tiscali.it>
Date: Wed, 27 Feb 2013 12:15:21 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <511BA0D7.8070809@tiscali.it>
	<6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B35671CE8@BITCOM1.int.sbss.com.au>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV questions
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="===============6394681732118377062=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============6394681732118377062==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010207010605010906040309"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms010207010605010906040309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 13/02/2013 23:26, James Harper ha scritto:
>> I have tried to build gplpv from source with makedist.bat but it gave =
me
>> some errors about files not found.
>> I saw that latest commits were big. Is there something incomplete and
>> must I wait other commits before build it?
> It's possible I missed a commit but I can't see any missing files.
>
> Can you post the output of makedist?
>
> But yes the latest commits involve a pretty major change and I haven't =
tested save/restore yet so that is probably more broken than before.
>
>> I would like to see if new build fix network not working after restore=

>> on windows domUs using upstream qemu.
>> Dom0 is wheezy with xen-unstable from source.
>> Tested with Windows 7 pro 64 bit with gplpv 0.11.0.357, I not found
>> error on xen for now, probably is problem of gplpv with qemu upstream.=

>> Linux hvm domUs seem not have that problem, tested with quantal (ubunt=
u
>> 12.10) and network works also after restore.
>> If you need more details and tests tell me and I'll post it.

Are there news about this problem? This is the last critical problem=20
remained with upstream qemu on my tests and only present with windows dom=
U.
I saw another related post days ago with probably same problem you can't =

reproduce.
http://lists.xen.org/archives/html/xen-users/2013-02/msg00278.html
Do you need more details about my dom0 and domU xl cfg?

>>
>> Another problem present on both traditional/upstream qemu  with
>> older/new xen and  older/new gplpv is domU's time not correctly update=
d
>> after restore (it remains the time at the save operation), this is a b=
ig
>> problem with windows domUs (DC and client) in a windows domain where
>> the time source is DC by default.
> I noticed that recently. I can't think how it could be a GPLPV bug thou=
gh.
>
>
> James
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2013.0.2899 / Database dei virus: 2639/6101 -  Data di rilasc=
io: 13/02/2013
>
>
>



--------------ms010207010605010906040309
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyNzExMTUyMVowIwYJKoZIhvcNAQkEMRYEFKzMoFZre8c+gU1IZpf1/aop
jdaXMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAH3XQ44k9CiQ3rw3+gQEweTup
pTaxcVKxPp8mskM7ON3mBp+vcky15UpFQt7Ce1fFXwQLv9N3+Gqqb4s9yCqfCeRI2gJTFMFB
mzm4bzCYXP11Mko1knls52qI9xIEpLR7lY0ASci9M2ZJzCrb89lTZQMqWojFd+qQWRgrp6YU
k1ybP3LaguPlsWq1wmUAWalUMoD7Rw1CEMWAvY6biNq7ejPZsMjIB3MUcLV9XcM6ZbX2GqU7
j2S5GfIwLfTMpj4Fff3g5bO05XZnqCnMeOn+d7MhbExv6jOfzRcx650qlad2QjWYEjiOtHjB
dFlrEByGp4ia+2j2ARXmmlDu08zfmQAAAAAAAA==
--------------ms010207010605010906040309--


--===============6394681732118377062==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6394681732118377062==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 11:17:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAf0J-0000O9-E7; Wed, 27 Feb 2013 11:16:55 +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 1UAf0H-0000O0-QW
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:16:54 +0000
Received: from [85.158.138.51:18707] by server-13.bemta-3.messagelabs.com id
	49/89-25744-02BED215; Wed, 27 Feb 2013 11:16:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361963801!28377515!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28283 invoked from network); 27 Feb 2013 11:16:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:16:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1948122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11: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.297.1;
	Wed, 27 Feb 2013 11:16:41 +0000
Message-ID: <1361963799.26546.353.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 27 Feb 2013 11:16:39 +0000
In-Reply-To: <CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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 Wed, 2013-02-27 at 10:54 +0000, George Dunlap wrote:
> What about this: We obviously have users who are keen to have this
> functionality, and in fact who have made local versions of such
> functionality to use themselves.  If one of them is willing to step up
> and officially maintain such functionality (which would include
> responding to bugs and updating things on a regular basis), then I
> think we should consider accepting such a patch.  If it ever becomes
> unmaintained, then we'll take it out.  That way the core devs won't
> have to be involved in package management, but early-adopters will
> have the benefit of being able to use Xen more easily. 

IMHO the right way to provide this is for that someone to provide
regular snapshot packages based on the distro packaging. Even better
would be to work with the distro package maintainers and use the
facilities which they provide e.g. Debian's Experimental distro. This
has the added advantages of helping the distros to have 4.3 packages
more quickly after 4.3 is released as well as helping the distro instead
of duplicating their effort.

Of course this is all just hand waving unless someone steps, and when
they do it is up to them how they achieve the 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 Feb 27 11:17:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAf0J-0000O9-E7; Wed, 27 Feb 2013 11:16:55 +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 1UAf0H-0000O0-QW
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:16:54 +0000
Received: from [85.158.138.51:18707] by server-13.bemta-3.messagelabs.com id
	49/89-25744-02BED215; Wed, 27 Feb 2013 11:16:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1361963801!28377515!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28283 invoked from network); 27 Feb 2013 11:16:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:16:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1948122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11: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.297.1;
	Wed, 27 Feb 2013 11:16:41 +0000
Message-ID: <1361963799.26546.353.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 27 Feb 2013 11:16:39 +0000
In-Reply-To: <CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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 Wed, 2013-02-27 at 10:54 +0000, George Dunlap wrote:
> What about this: We obviously have users who are keen to have this
> functionality, and in fact who have made local versions of such
> functionality to use themselves.  If one of them is willing to step up
> and officially maintain such functionality (which would include
> responding to bugs and updating things on a regular basis), then I
> think we should consider accepting such a patch.  If it ever becomes
> unmaintained, then we'll take it out.  That way the core devs won't
> have to be involved in package management, but early-adopters will
> have the benefit of being able to use Xen more easily. 

IMHO the right way to provide this is for that someone to provide
regular snapshot packages based on the distro packaging. Even better
would be to work with the distro package maintainers and use the
facilities which they provide e.g. Debian's Experimental distro. This
has the added advantages of helping the distros to have 4.3 packages
more quickly after 4.3 is released as well as helping the distro instead
of duplicating their effort.

Of course this is all just hand waving unless someone steps, and when
they do it is up to them how they achieve the 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 Feb 27 11:19:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAf2x-0000Xy-0o; Wed, 27 Feb 2013 11:19: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 1UAf2v-0000Xo-0W
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:19:37 +0000
Received: from [85.158.137.99:56866] by server-4.bemta-3.messagelabs.com id
	FF/E8-21470-8CBED215; Wed, 27 Feb 2013 11:19:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361963956!12867274!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29965 invoked from network); 27 Feb 2013 11:19:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:19:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1948214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:19: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.297.1;
	Wed, 27 Feb 2013 11:19:17 +0000
Message-ID: <1361963955.26546.354.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Feb 2013 11:19:15 +0000
In-Reply-To: <alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, Fabio
	Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 17:57 +0000, Stefano Stabellini wrote:
> 
> > I think we can engage in better expectations management.  Perhaps we
> > could rename the target.
> 
> Right, that would be a step forward. Something that make it clear that
> it isn't a proper deb. 


8<------

>From 9ca6f044bae834ec991e7a8c83623344f4701f87 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 11:16:47 +0000
Subject: [PATCH] build: rename deb target as debball

"debball" by analogy with "tarball". Attempt to clarify the purpose of this
target in the comment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 2d3ed82..32efb70 100644
--- a/Makefile
+++ b/Makefile
@@ -137,9 +137,11 @@ world:
 	$(MAKE) kdelete
 	$(MAKE) dist
 
-# Package a build in a .deb file
-.PHONY: deb
-deb: dist
+# Package a build in a debball file, that is inside a .deb format
+# container to allow for easy and clean removal. This is not intended
+# to be a full featured policy compliant .deb package.
+.PHONY: debball
+debball: dist
 	fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen xenversion | grep -v :)
 
 # clean doesn't do a kclean
-- 
1.7.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 Feb 27 11:19:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAf2x-0000Xy-0o; Wed, 27 Feb 2013 11:19: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 1UAf2v-0000Xo-0W
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:19:37 +0000
Received: from [85.158.137.99:56866] by server-4.bemta-3.messagelabs.com id
	FF/E8-21470-8CBED215; Wed, 27 Feb 2013 11:19:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1361963956!12867274!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29965 invoked from network); 27 Feb 2013 11:19:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:19:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; 
   d="scan'208";a="1948214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:19: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.297.1;
	Wed, 27 Feb 2013 11:19:17 +0000
Message-ID: <1361963955.26546.354.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 27 Feb 2013 11:19:15 +0000
In-Reply-To: <alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>, Fabio
	Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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, 2013-02-26 at 17:57 +0000, Stefano Stabellini wrote:
> 
> > I think we can engage in better expectations management.  Perhaps we
> > could rename the target.
> 
> Right, that would be a step forward. Something that make it clear that
> it isn't a proper deb. 


8<------

>From 9ca6f044bae834ec991e7a8c83623344f4701f87 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 11:16:47 +0000
Subject: [PATCH] build: rename deb target as debball

"debball" by analogy with "tarball". Attempt to clarify the purpose of this
target in the comment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 2d3ed82..32efb70 100644
--- a/Makefile
+++ b/Makefile
@@ -137,9 +137,11 @@ world:
 	$(MAKE) kdelete
 	$(MAKE) dist
 
-# Package a build in a .deb file
-.PHONY: deb
-deb: dist
+# Package a build in a debball file, that is inside a .deb format
+# container to allow for easy and clean removal. This is not intended
+# to be a full featured policy compliant .deb package.
+.PHONY: debball
+debball: dist
 	fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen xenversion | grep -v :)
 
 # clean doesn't do a kclean
-- 
1.7.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 Feb 27 11:34:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAfHK-0000vC-Ox; Wed, 27 Feb 2013 11:34:30 +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 1UAfHI-0000v7-HL
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:34:28 +0000
Received: from [85.158.137.99:26265] by server-6.bemta-3.messagelabs.com id
	AB/35-11048-34FED215; Wed, 27 Feb 2013 11:34:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361964866!15997788!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9897 invoked from network); 27 Feb 2013 11:34:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 11:34:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 11:34:26 +0000
Message-Id: <512DFD5102000078000C1764@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 11:34:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:08, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>>> 		recommended by Intel SDM: LOG MCA REGISTER:
>>> 		SAVE IA32_MCi_STATUS;
>>> 		If MISCV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SAVE IA32_MCi_MISC;
>>> 		FI;
>>> 		IF ADDRV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SAVE IA32_MCi_ADDR;
>>> 		FI;
>>> 		IF CLEAR_MC_BANK = TRUE
>>> 		THEN
>>> 			SET all 0 to IA32_MCi_STATUS;
>>> 		If MISCV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SET all 0 to IA32_MCi_MISC;
>>> 		FI;
>>> 		IF ADDRV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SET all 0 to IA32_MCi_ADDR;
>>> 		FI;
>>> 
>>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>>> error occur (which indicated by MCi_STATUS), so only clear
>>> MCi_STATUS at mce handler is an acceptable work around -- after all,
>>> to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
>> 
>> So then what - revert your original patch (and ignore the SDM)?
>> I'm not in favor of this...
> 
> Not revert entire 23327, but only use this patch to revert MCi_ADDR/MISC 
> clear.
> 
> I also agree it's not good, but currently seems we don't have a simple and 
> clean way to fix it, except we spend much time to to update xen-mceinj *tools* 
> -- even so it's low-priority?

No, fixing the tool seems unnecessary for this problem, all we
need is a way to avoid the problematic MSR writes when finishing
an injected MCE. That's fully contained to the hypervisor.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:34:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAfHK-0000vC-Ox; Wed, 27 Feb 2013 11:34:30 +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 1UAfHI-0000v7-HL
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:34:28 +0000
Received: from [85.158.137.99:26265] by server-6.bemta-3.messagelabs.com id
	AB/35-11048-34FED215; Wed, 27 Feb 2013 11:34:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1361964866!15997788!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9897 invoked from network); 27 Feb 2013 11:34:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 11:34:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 11:34:26 +0000
Message-Id: <512DFD5102000078000C1764@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 11:34:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:08, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>>> 		recommended by Intel SDM: LOG MCA REGISTER:
>>> 		SAVE IA32_MCi_STATUS;
>>> 		If MISCV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SAVE IA32_MCi_MISC;
>>> 		FI;
>>> 		IF ADDRV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SAVE IA32_MCi_ADDR;
>>> 		FI;
>>> 		IF CLEAR_MC_BANK = TRUE
>>> 		THEN
>>> 			SET all 0 to IA32_MCi_STATUS;
>>> 		If MISCV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SET all 0 to IA32_MCi_MISC;
>>> 		FI;
>>> 		IF ADDRV in IA32_MCi_STATUS
>>> 		THEN
>>> 			SET all 0 to IA32_MCi_ADDR;
>>> 		FI;
>>> 
>>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>>> error occur (which indicated by MCi_STATUS), so only clear
>>> MCi_STATUS at mce handler is an acceptable work around -- after all,
>>> to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
>> 
>> So then what - revert your original patch (and ignore the SDM)?
>> I'm not in favor of this...
> 
> Not revert entire 23327, but only use this patch to revert MCi_ADDR/MISC 
> clear.
> 
> I also agree it's not good, but currently seems we don't have a simple and 
> clean way to fix it, except we spend much time to to update xen-mceinj *tools* 
> -- even so it's low-priority?

No, fixing the tool seems unnecessary for this problem, all we
need is a way to avoid the problematic MSR writes when finishing
an injected MCE. That's fully contained to the hypervisor.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:36:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:36: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 1UAfIk-0000zZ-94; Wed, 27 Feb 2013 11:35:58 +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 1UAfIi-0000zS-GH
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:35:56 +0000
Received: from [85.158.139.83:62936] by server-5.bemta-5.messagelabs.com id
	A5/1F-02762-B9FED215; Wed, 27 Feb 2013 11:35:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361964942!24851107!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11926 invoked from network); 27 Feb 2013 11:35:42 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:35:42 -0000
Received: by mail-wi0-f173.google.com with SMTP id hq4so6112509wib.0
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 03:35:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UXHUEahwX3MmNNI1e7zw6CqRAlmylN76bLWILBOrjKY=;
	b=GUPloeJoc7Rc1WRhmjU/VRh00S22S3QAgsZjEiFnQ3hEDd+yJRN94+FEiTwl/zVzDp
	d1vj3vN/7wceW5Hcr0qTIZ/MyY/5aXJC1yY4qGlezDyeNwTQzaoqrgjr8CkVCqeR7CJU
	aVyHr30sgCt48eOJzowiPcEDKjl0YwaxOtIpU4HZwDLdSMbFlYDkPFndbpuw/Qej9P+Q
	hYZT5gweEvDGhIBT2CPhOTyDpJCpBlWgThSphrK7GZSTXNIx+DBQipNrk67UNPUyuoDX
	Zu1BxwdEJJkvF5mpIO/YTaozWrzhpS7MAfna7fDNXI2kxHhuuMgXihmP8Wr5lwXs18vM
	KXug==
MIME-Version: 1.0
X-Received: by 10.180.105.67 with SMTP id gk3mr3118138wib.31.1361964941649;
	Wed, 27 Feb 2013 03:35:41 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 03:35:41 -0800 (PST)
In-Reply-To: <512DE2AF02000078000C15F0@nat28.tlf.novell.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
	<512DE2AF02000078000C15F0@nat28.tlf.novell.com>
Date: Wed, 27 Feb 2013 11:35:41 +0000
X-Google-Sender-Auth: IN8VwKcODYpVGkWcSeGseWsBkJA
Message-ID: <CAFLBxZZBQvknu+Mfqz02d5ZeazVDUpVqDCP52CHr1nHR14tdQw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5408244348717991511=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5408244348717991511==
Content-Type: multipart/alternative; boundary=f46d04426a228b2d6e04d6b32cde

--f46d04426a228b2d6e04d6b32cde
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 26.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com>
> wrote:
> > @@ -271,16 +272,24 @@ struct csched_dom {
> >
> >  /*
> >   * Time-to-credit, credit-to-time.
> > + *
> > + * We keep track of the "residual" time to make sure that frequent short
> > + * schedules still get accounted for in the end.
> > + *
> >   * FIXME: Do pre-calculated division?
> >   */
> > -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
> struct csched_vcpu *svc)
> > +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
> > +                          struct csched_vcpu *svc)
> >  {
> > -    return time * rqd->max_weight / svc->weight;
> > +    uint64_t val = time * rqd->max_weight + svc->residual;
> > +
> > +    svc->residual = do_div(val, svc->weight);
> > +    svc->credit -= val;
> >  }
> >
> >  static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
> struct csched_vcpu *svc)
> >  {
> > -    return credit * svc->weight / rqd->max_weight;
> > +    return (credit * svc->weight) / rqd->max_weight;
>
> So you dropped the subtraction of svc->residual here - why?
>
> And if indeed intended, the insertion of parentheses here could be
> dropped?
>

Well for one I think the equation was wrong -- the residual is units of
"time", so you should have subtracted the residual after dividing by
max_weight.  (From a mathematical perspective, svc->weight /
rqd->max_weight is the ratio that changes units of "credit" into units of
"time; if we were using floating point ops I might put parentheses around
that ratio to make it more clear that's what's going on.)

I had originally thought that there was no real need to subtract the time
off the end -- we don't do it for credit1, after all, and as long as we're
adding up the residuals it will all "come out in the wash", so to speak.
But on further reflection I think it's probably not a bad idea.  I'll
respin the patch with the modified equation.

 -George

--f46d04426a228b2d6e04d6b32cde
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <span dir=3D"=
ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@su=
se.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">
<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">&gt;&gt;&gt; On 26.02.13 a=
t 18:08, George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt; wrote:<br>

&gt; @@ -271,16 +272,24 @@ struct csched_dom {<br>
&gt;<br>
&gt; =A0/*<br>
&gt; =A0 * Time-to-credit, credit-to-time.<br>
&gt; + *<br>
&gt; + * We keep track of the &quot;residual&quot; time to make sure that f=
requent short<br>
&gt; + * schedules still get accounted for in the end.<br>
&gt; + *<br>
&gt; =A0 * FIXME: Do pre-calculated division?<br>
&gt; =A0 */<br>
&gt; -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, =
struct csched_vcpu *svc)<br>
&gt; +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t tim=
e,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct csched_vcp=
u *svc)<br>
&gt; =A0{<br>
&gt; - =A0 =A0return time * rqd-&gt;max_weight / svc-&gt;weight;<br>
&gt; + =A0 =A0uint64_t val =3D time * rqd-&gt;max_weight + svc-&gt;residual=
;<br>
&gt; +<br>
&gt; + =A0 =A0svc-&gt;residual =3D do_div(val, svc-&gt;weight);<br>
&gt; + =A0 =A0svc-&gt;credit -=3D val;<br>
&gt; =A0}<br>
&gt;<br>
&gt; =A0static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t cred=
it, struct csched_vcpu *svc)<br>
&gt; =A0{<br>
&gt; - =A0 =A0return credit * svc-&gt;weight / rqd-&gt;max_weight;<br>
&gt; + =A0 =A0return (credit * svc-&gt;weight) / rqd-&gt;max_weight;<br>
<br>
</div>So you dropped the subtraction of svc-&gt;residual here - why?<br>
<br>
And if indeed intended, the insertion of parentheses here could be<br>
dropped?<br></blockquote><br></div>Well for one I think the equation was wr=
ong -- the residual is units of &quot;time&quot;, so you should have subtra=
cted the residual after dividing by max_weight.=A0 (From a mathematical per=
spective, svc-&gt;weight / rqd-&gt;max_weight is the ratio that changes uni=
ts of &quot;credit&quot; into units of &quot;time; if we were using floatin=
g point ops I might put parentheses around that ratio to make it more clear=
 that&#39;s what&#39;s going on.)=A0 <br>
<br>I had originally thought that there was no real need to subtract the ti=
me off the end -- we don&#39;t do it for credit1, after all, and as long as=
 we&#39;re adding up the residuals it will all &quot;come out in the wash&q=
uot;, so to speak.=A0 But on further reflection I think it&#39;s probably n=
ot a bad idea.=A0 I&#39;ll respin the patch with the modified equation.<br>
<br></div><div class=3D"gmail_extra">=A0-George<br></div><div class=3D"gmai=
l_extra"><br></div></div>

--f46d04426a228b2d6e04d6b32cde--


--===============5408244348717991511==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5408244348717991511==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 11:36:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11:36: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 1UAfIk-0000zZ-94; Wed, 27 Feb 2013 11:35:58 +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 1UAfIi-0000zS-GH
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:35:56 +0000
Received: from [85.158.139.83:62936] by server-5.bemta-5.messagelabs.com id
	A5/1F-02762-B9FED215; Wed, 27 Feb 2013 11:35:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1361964942!24851107!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11926 invoked from network); 27 Feb 2013 11:35:42 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:35:42 -0000
Received: by mail-wi0-f173.google.com with SMTP id hq4so6112509wib.0
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 03:35:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UXHUEahwX3MmNNI1e7zw6CqRAlmylN76bLWILBOrjKY=;
	b=GUPloeJoc7Rc1WRhmjU/VRh00S22S3QAgsZjEiFnQ3hEDd+yJRN94+FEiTwl/zVzDp
	d1vj3vN/7wceW5Hcr0qTIZ/MyY/5aXJC1yY4qGlezDyeNwTQzaoqrgjr8CkVCqeR7CJU
	aVyHr30sgCt48eOJzowiPcEDKjl0YwaxOtIpU4HZwDLdSMbFlYDkPFndbpuw/Qej9P+Q
	hYZT5gweEvDGhIBT2CPhOTyDpJCpBlWgThSphrK7GZSTXNIx+DBQipNrk67UNPUyuoDX
	Zu1BxwdEJJkvF5mpIO/YTaozWrzhpS7MAfna7fDNXI2kxHhuuMgXihmP8Wr5lwXs18vM
	KXug==
MIME-Version: 1.0
X-Received: by 10.180.105.67 with SMTP id gk3mr3118138wib.31.1361964941649;
	Wed, 27 Feb 2013 03:35:41 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 03:35:41 -0800 (PST)
In-Reply-To: <512DE2AF02000078000C15F0@nat28.tlf.novell.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
	<512DE2AF02000078000C15F0@nat28.tlf.novell.com>
Date: Wed, 27 Feb 2013 11:35:41 +0000
X-Google-Sender-Auth: IN8VwKcODYpVGkWcSeGseWsBkJA
Message-ID: <CAFLBxZZBQvknu+Mfqz02d5ZeazVDUpVqDCP52CHr1nHR14tdQw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5408244348717991511=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5408244348717991511==
Content-Type: multipart/alternative; boundary=f46d04426a228b2d6e04d6b32cde

--f46d04426a228b2d6e04d6b32cde
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 26.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com>
> wrote:
> > @@ -271,16 +272,24 @@ struct csched_dom {
> >
> >  /*
> >   * Time-to-credit, credit-to-time.
> > + *
> > + * We keep track of the "residual" time to make sure that frequent short
> > + * schedules still get accounted for in the end.
> > + *
> >   * FIXME: Do pre-calculated division?
> >   */
> > -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
> struct csched_vcpu *svc)
> > +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
> > +                          struct csched_vcpu *svc)
> >  {
> > -    return time * rqd->max_weight / svc->weight;
> > +    uint64_t val = time * rqd->max_weight + svc->residual;
> > +
> > +    svc->residual = do_div(val, svc->weight);
> > +    svc->credit -= val;
> >  }
> >
> >  static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
> struct csched_vcpu *svc)
> >  {
> > -    return credit * svc->weight / rqd->max_weight;
> > +    return (credit * svc->weight) / rqd->max_weight;
>
> So you dropped the subtraction of svc->residual here - why?
>
> And if indeed intended, the insertion of parentheses here could be
> dropped?
>

Well for one I think the equation was wrong -- the residual is units of
"time", so you should have subtracted the residual after dividing by
max_weight.  (From a mathematical perspective, svc->weight /
rqd->max_weight is the ratio that changes units of "credit" into units of
"time; if we were using floating point ops I might put parentheses around
that ratio to make it more clear that's what's going on.)

I had originally thought that there was no real need to subtract the time
off the end -- we don't do it for credit1, after all, and as long as we're
adding up the residuals it will all "come out in the wash", so to speak.
But on further reflection I think it's probably not a bad idea.  I'll
respin the patch with the modified equation.

 -George

--f46d04426a228b2d6e04d6b32cde
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <span dir=3D"=
ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@su=
se.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">
<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">&gt;&gt;&gt; On 26.02.13 a=
t 18:08, George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt; wrote:<br>

&gt; @@ -271,16 +272,24 @@ struct csched_dom {<br>
&gt;<br>
&gt; =A0/*<br>
&gt; =A0 * Time-to-credit, credit-to-time.<br>
&gt; + *<br>
&gt; + * We keep track of the &quot;residual&quot; time to make sure that f=
requent short<br>
&gt; + * schedules still get accounted for in the end.<br>
&gt; + *<br>
&gt; =A0 * FIXME: Do pre-calculated division?<br>
&gt; =A0 */<br>
&gt; -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, =
struct csched_vcpu *svc)<br>
&gt; +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t tim=
e,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct csched_vcp=
u *svc)<br>
&gt; =A0{<br>
&gt; - =A0 =A0return time * rqd-&gt;max_weight / svc-&gt;weight;<br>
&gt; + =A0 =A0uint64_t val =3D time * rqd-&gt;max_weight + svc-&gt;residual=
;<br>
&gt; +<br>
&gt; + =A0 =A0svc-&gt;residual =3D do_div(val, svc-&gt;weight);<br>
&gt; + =A0 =A0svc-&gt;credit -=3D val;<br>
&gt; =A0}<br>
&gt;<br>
&gt; =A0static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t cred=
it, struct csched_vcpu *svc)<br>
&gt; =A0{<br>
&gt; - =A0 =A0return credit * svc-&gt;weight / rqd-&gt;max_weight;<br>
&gt; + =A0 =A0return (credit * svc-&gt;weight) / rqd-&gt;max_weight;<br>
<br>
</div>So you dropped the subtraction of svc-&gt;residual here - why?<br>
<br>
And if indeed intended, the insertion of parentheses here could be<br>
dropped?<br></blockquote><br></div>Well for one I think the equation was wr=
ong -- the residual is units of &quot;time&quot;, so you should have subtra=
cted the residual after dividing by max_weight.=A0 (From a mathematical per=
spective, svc-&gt;weight / rqd-&gt;max_weight is the ratio that changes uni=
ts of &quot;credit&quot; into units of &quot;time; if we were using floatin=
g point ops I might put parentheses around that ratio to make it more clear=
 that&#39;s what&#39;s going on.)=A0 <br>
<br>I had originally thought that there was no real need to subtract the ti=
me off the end -- we don&#39;t do it for credit1, after all, and as long as=
 we&#39;re adding up the residuals it will all &quot;come out in the wash&q=
uot;, so to speak.=A0 But on further reflection I think it&#39;s probably n=
ot a bad idea.=A0 I&#39;ll respin the patch with the modified equation.<br>
<br></div><div class=3D"gmail_extra">=A0-George<br></div><div class=3D"gmai=
l_extra"><br></div></div>

--f46d04426a228b2d6e04d6b32cde--


--===============5408244348717991511==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5408244348717991511==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 11:47:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAfTT-0001He-Ix; Wed, 27 Feb 2013 11:47:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAfTP-0001HZ-Vd
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:47:02 +0000
Received: from [85.158.137.99:25825] by server-14.bemta-3.messagelabs.com id
	2C/12-27076-332FD215; Wed, 27 Feb 2013 11:46:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361965614!18310278!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30312 invoked from network); 27 Feb 2013 11:46:54 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-14.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 11:46:54 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:50086 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 1UAfRD-0002UF-Jn; Wed, 27 Feb 2013 12:44:44 +0100
Date: Wed, 27 Feb 2013 12:46:48 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1769529756.20130227124648@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512DF6C702000078000C1708@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0FB1ED1493275D29B"
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0FB1ED1493275D29B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

=0D=0AWednesday, February 27, 2013, 12:06:31 PM, you wrote:

>>>> On 27.02.13 at 11:57, Sander Eikelenboom <linux@eikelenboom.it> wrote:

>> Tuesday, February 26, 2013, 9:41:53 AM, you wrote:
>>=20
>>>>>> On 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrot=
e:
>>>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>>>> It doesn't detect the s-ata controller, so it ends op with udev timing=
 and=20
>>>> bailing out to busybox.
>>>>=20
>>>> I don't see a obvious error in the logs.
>>=20
>>> Perhaps because the log is far from being complete? There's a huge
>>> gap right before the first pciback message, yet that's quite likely
>>> the relevant part.
>>=20
>> Hi Jan / Konrad,
>>=20
>> Tried bisecting, but that ended up no where, so back to the logs...
>>=20
>> With v3.9-rc0 + xen, it's indeed missing a part of the log:
>>   [    4.141328] Brought up 6 CPUs
>>   [    4.142654] Grant tables using version 2 layout.
>>   [    4.142676] Grant table initialized
>>   [    4.142813] NET: Registered protocol family 16
>>   [    4.145343] node 0 link 0: io port [1000, ffffff]
>>   [    4.145354] TOM: 00000000b0000000 aka 2816M
>>   [    4.145360] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
>>   [    4.145373] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none
>>   [    4.145381] node 0 link 0: mmio [f0000000, ffffffff]
>>   [    4.145388] node 0 link 0: mmio [a0000, bffff]
>>   [    4.145395] node 0 link 0: mmio [b0000000, dfffffff]
>>   [    4.145401] TOM2: 0000000250000000 aka 9472M
>>   [    4.145406] bus: [bus 00-07] on node 0 link 0
>>   [    4.145411] bus: 00 [io  0x0000-0xffff]
>>   [    4.145415] bus: 00 [mem 0xf0000000-0xffffffff]
>>   [    4.145420] bus: 00 [mem 0x000a0000-0x000bffff]
>>   [    4.145424] bus: 00 [mem 0xb0000000-0xdfffffff]
>>   [    4.145429] bus: 00 [mem 0x250000000-0xfcffffffff]
>>   [    4.145702] ACPI: bus type pci registered
>>   [    4.146801] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem=20
>> 0xe0000000-0xefffffff] (base 0xe0000000)
>>   [    4.146812] PCI: not using MMCONFIG
>>   [    4.146817] PCI: Using configuration type 1 for base access
>>   [    4.146822] PCI: Using configuration type 1 for extended access
>>   [    4.191935] bio: create slab <bio-0> at 0
>>   [    4.192623] ACPI: Added _OSI(Module Device)
>>   [    4.192630] ACPI: Added _OSI(Processor Device)
>>   [    4.192636] ACPI: Added _OSI(3.0 _SCP Extensions)
>>   [    4.192642] ACPI: Added _OSI(Processor Aggregator Device)
>>   [    4.195958] ACPI: EC: Look up EC in DSDT
>>   [    4.199659] ACPI: Executed 3 blocks of module-level executable AML =
code
>>   [    4.204162] ACPI: Interpreter enabled
>>   [    4.204170] ACPI: (supports S0 S5)
>>   [    4.204181] ACPI: Using IOAPIC for interrupt routing
>>   [    4.204219] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem=20
>> 0xe0000000-0xefffffff] (base 0xe0000000)
>>   [    4.205800] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved i=
n=20
>> ACPI motherboa[    7.107382] usb usb5: New USB device found, idVendor=3D=
1d6b,=20
>> idProduct=3D0001
>>=20
>>=20
>> The line in the serial-log also seems to be truncated somehow and the re=
st of=20
>> the info missing ..
>>=20
>> When booting v3.9-rc0 Baremetal the complete pci enumeration seems to be=
 in=20
>> between:
>> ...
>> Tried booting with pci=3Dnommconf,nocrs but to no avail.
>> Are there any other boot options i could try to narrow it down ?

> You first of all want to make sure you get a complete log.
> "sync_console" or "serial_tx_buffer=3D<size>" are your friends...

Ah that worked :-)

Complete serial log and lspci-v38 attached.

Sata device is: 00:11.0

From=20the log i see:

  [   16.132653] pci 0000:00:11.0: [1002:4390] type 00 class 0x01018f
  [   16.150679] pci 0000:00:11.0: calling quirk_no_ata_d3+0x0/0x10
  [   16.168365] pci 0000:00:11.0: reg 10: [io  0x7000-0x7007]
  [   16.184733] pci 0000:00:11.0: reg 14: [io  0x6000-0x6003]
  [   16.201116] pci 0000:00:11.0: reg 18: [io  0x5000-0x5007]
  [   16.217491] pci 0000:00:11.0: reg 1c: [io  0x3000-0x3003]
  [   16.233868] pci 0000:00:11.0: reg 20: [io  0x2000-0x200f]
  [   16.250249] pci 0000:00:11.0: reg 24: [mem 0xf96ff000-0xf96ff3ff]
  [   16.268714] pci 0000:00:11.0: calling quirk_amd_ide_mode+0x0/0xe0
  [   16.287163] pci 0000:00:11.0: set SATA to AHCI mode

<snip>

  [   21.524945] pci 0000:00:11.0: BAR 0: reserving [io  0x7000-0x7007 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.550163] pci 0000:00:11.0: BAR 1: reserving [io  0x6000-0x6003 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.575411] pci 0000:00:11.0: BAR 2: reserving [io  0x5000-0x5007 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.600648] pci 0000:00:11.0: BAR 3: reserving [io  0x3000-0x3003 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.625849] pci 0000:00:11.0: BAR 4: reserving [io  0x2000-0x200f flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.651069] pci 0000:00:11.0: BAR 5: reserving [mem 0xf96ff000-0xf96ff=
3ff flags 0x40200] (d=3D0, p=3D0)

<snip>

  [   24.957481] pci 0000:00:11.0: calling quirk_msi_intx_disable_ati_bug+0=
x0/0x50

<snip>

  [   89.189428] ahci 0000:00:11.0: version 3.0
  [   89.207872] xen: registering gsi 19 triggering 0 polarity 1
  [   89.230656] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19)
  (XEN) [2013-02-27 11:21:21] IOAPIC[0]: Set PCI routing entry (6-19 -> 0xa=
9 -> IRQ 19 Mode:1 Active:1)
  [   89.277231] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps =
0xf impl SATA mode
  [   89.307529] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p=
mp pio slum part=20
  [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22


> But then again I would guess it's not bus enumeration related.
> Did the multiple-MSI-vectors suspicion lead nowhere?

> Jan


------------0FB1ED1493275D29B
Content-Type: text/plain;
 name="lspci-v38.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-v38.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikKCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4
OTAgTm9ydGhicmlkZ2Ugb25seSBzaW5nbGUgc2xvdCBQQ0ktZSBHRlggSHlkcmEgcGFydCBb
MTAwMjo1YTExXQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNF
TD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5UeC0K
CUNhcGFiaWxpdGllczogW2YwXSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsKCUNhcGFiaWxpdGllczogW2M0XSBIeXBlclRyYW5zcG9ydDogU2xhdmUgb3Ig
UHJpbWFyeSBJbnRlcmZhY2UKCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENudD0yMCBN
YXN0SG9zdC0gRGVmRGlyLSBEVUwtCgkJTGluayBDb250cm9sIDA6IENGbEUtIENTVC0gQ0ZF
LSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElzb2NFbi0gTFNFbi0gRXh0
Q1RMLSA2NGItCgkJTGluayBDb25maWcgMDogTUxXST0xNmJpdCBEd0ZjSW4tIE1MV089MTZi
aXQgRHdGY091dC0gTFdJPTE2Yml0IER3RmNJbkVuLSBMV089MTZiaXQgRHdGY091dEVuLQoJ
CUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5pdC0gRU9DKyBU
WE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQoJCUxpbmsgQ29uZmln
IDE6IE1MV0k9OGJpdCBEd0ZjSW4tIE1MV089OGJpdCBEd0ZjT3V0LSBMV0k9OGJpdCBEd0Zj
SW5Fbi0gTFdPPThiaXQgRHdGY091dEVuLQoJCVJldmlzaW9uIElEOiAzLjAwCgkJTGluayBG
cmVxdWVuY3kgMDogW2JdCgkJTGluayBFcnJvciAwOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQoJCUxpbmsgRnJlcXVlbmN5IENhcGFiaWxpdHkgMDogMjAwTUh6KyAzMDBNSHotIDQw
ME1IeisgNTAwTUh6LSA2MDBNSHorIDgwME1IeisgMS4wR0h6KyAxLjJHSHorIDEuNEdIei0g
MS42R0h6LSBWZW5kLQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNvY0ZDKyBMRFRTVE9QKyBD
UkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQoJCUxpbmsgRnJlcXVlbmN5IDE6IDIwME1IegoJ
CUxpbmsgRXJyb3IgMTogPFByb3QtIDxPdmZsLSA8RU9DLSBDVExUbS0KCQlMaW5rIEZyZXF1
ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0MDBNSHotIDUwME1Iei0gNjAw
TUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHotIDEuNkdIei0gVmVuZC0KCQlF
cnJvciBIYW5kbGluZzogUEZsRS0gT0ZsRS0gUEZFLSBPRkUtIEVPQ0ZFLSBSRkUtIENSQ0ZF
LSBTRVJSRkUtIENGLSBSRS0gUE5GRS0gT05GRS0gRU9DTkZFLSBSTkZFLSBDUkNORkUtIFNF
UlJORkUtCgkJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlIFVwcGVyOiAwMC0w
MAoJCUJ1cyBOdW1iZXI6IDAwCglDYXBhYmlsaXRpZXM6IFs0MF0gSHlwZXJUcmFuc3BvcnQ6
IFJldHJ5IE1vZGUKCUNhcGFiaWxpdGllczogWzU0XSBIeXBlclRyYW5zcG9ydDogVW5pdElE
IENsdW1waW5nCglDYXBhYmlsaXRpZXM6IFs5Y10gSHlwZXJUcmFuc3BvcnQ6ICMxYQoJQ2Fw
YWJpbGl0aWVzOiBbNzBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzQgTWFza2FibGUtIDY0Yml0
LQoJCUFkZHJlc3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCgowMDowMC4yIEdlbmVyaWMgc3lz
dGVtIHBlcmlwaGVyYWwgWzA4MDZdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDk5MCBJL08g
TWVtb3J5IE1hbmFnZW1lbnQgVW5pdCAoSU9NTVUpIFsxMDAyOjVhMjNdCglTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEOTkwIEkvTyBNZW1vcnkgTWFuYWdlbWVudCBVbml0
IChJT01NVSkgWzEwMDI6NWEyM10KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNw
ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh
c3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy
RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEg
MTAKCUNhcGFiaWxpdGllczogWzQwXSBTZWN1cmUgZGV2aWNlIDw/PgoJQ2FwYWJpbGl0aWVz
OiBbNTRdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJl
c3M6IDAwMDAwMDAwMDAwMDEwMDAgIERhdGE6IDAwMjgKCUNhcGFiaWxpdGllczogWzY0XSBI
eXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsKCjAwOjAyLjAgUENJ
IGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kg
YnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAw
MCBbTm9ybWFsIGRlY29kZV0pCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0
QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJS
LSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBw
cmltYXJ5PTAwLCBzZWNvbmRhcnk9MGMsIHN1Ym9yZGluYXRlPTBjLCBzZWMtbGF0ZW5jeT0w
CglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGUwMDAtMDAwMGVmZmYKCU1lbW9yeSBiZWhpbmQg
YnJpZGdlOiBmYTAwMDAwMC1mZTlmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQg
YnJpZGdlOiAwMDAwMDAwMGQwMDAwMDAwLTAwMDAwMDAwZGZmZmZmZmYKCVNlY29uZGFyeSBz
dGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJS
KyBOb0lTQS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBT
ZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCsp
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCsp
LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJ
RGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0g
VW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5v
U25vb3ArCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJ
CURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQ
d3ItIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4
OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBT
dXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xv
Y2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4OCwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210
KyBBQldNZ210LQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQ
d3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQoJCQlTbG90ICMxLCBQb3dlckxpbWl0IDI1LjAw
MFc7IEludGVybG9jay0gTm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdy
Rmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9s
OiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJ
CVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVz
RGV0KyBJbnRlcmxvY2stCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKwoJ
CVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJ
bnRFbmEtIENSU1Zpc2libGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQ
TUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJCURldkNhcDI6IENvbXBs
ZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKwoJCURldkN0
bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJ
RndkLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlh
bmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQgoJCQkgVHJh
bnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29t
cGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIKCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0K
CQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE1MQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1
YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdCglDYXBh
YmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4
ZWQrCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlv
bjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/PgoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBB
Y2Nlc3MgQ29udHJvbCBTZXJ2aWNlcwoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBS
ZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRy
YW5zKwoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWVwb3J0CgowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3Bw
IHBvcnQgQykgWzEwMDI6NWExN10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJQ29u
dHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9v
cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog
Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt
IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENh
Y2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTBh
LCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAw
MDBmMDAwLTAwMDAwZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZm
ZmYKCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAw
MC0wMDAwMDAwMDAwMGZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0g
PFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+
UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQt
IERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2
ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEg
UE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThd
IEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQ
YXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8
MXVzCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczog
Q29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEy
OCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29y
ckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2Fw
OglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5
IEwwIDwxdXMsIEwxIDw4dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05v
dCsKCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0
cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQt
IEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBU
cmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdC0gQUJXTWdtdC0KCQlTbHRDYXA6CUF0
dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlz
ZS0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwr
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJ
bmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0
bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFu
Z2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsKCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJs
ZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJv
b3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1
cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFC
Q0QsIFRpbWVvdXREaXMrIEFSSUZ3ZCsKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6
IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwyOiBUYXJnZXQg
TGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3Rh
YmxlIERlLWVtcGhhc2lzOiAtMy41ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9w
ZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1Mt
CgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBE
ZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFi
bGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxNTkKCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dp
ZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKwoJQ2FwYWJpbGl0aWVzOiBbMTAw
IHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAx
MCA8Pz4KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMK
CQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVw
c3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysKCQlBQ1NDdGw6CVNyY1ZhbGlk
KyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3ND
dHJsLSBEaXJlY3RUcmFucy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydAoKMDA6
MDUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJ
IHRvIFBDSSBicmlkZ2UgKFBDSSBleHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChw
cm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlIrIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIy
Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS
Ui0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
CglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wOSwgc3Vib3JkaW5hdGU9MDksIHNlYy1s
YXRlbmN5PTAKCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZDAwMC0wMDAwZGZmZgoJTWVtb3J5
IGJlaGluZCBicmlkZ2U6IGY5ZTAwMDAwLWY5ZWZmZmZmCglQcmVmZXRjaGFibGUgbWVtb3J5
IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwY2ZmMDAwMDAtMDAwMDAwMDBjZmZmZmZmZgoJU2Vj
b25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQoJQnJpZGdlQ3RsOiBQYXJp
dHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJCVByaURp
c2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCss
RDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0
IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWcrIFJCRSsgRkxS
ZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwt
IEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzCgkJCUNs
b2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZl
KyBCV01nbXQrIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0
dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzUsIFBvd2VyTGlt
aXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxlOiBBdHRu
QnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctCgkJ
CUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRl
cmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENw
bHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5r
U3RhdGUrCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0
YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQoJCVJv
b3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCgkJRGV2Q2Fw
MjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2Qr
CgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBUaW1lb3V0
RGlzLSBBUklGd2QtCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRl
ckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRC
CgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9k
aWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBo
YXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVk
QgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0LQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRhOiA0MTYxCglDYXBhYmlsaXRpZXM6
IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEx
MV0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5h
YmxlKyBGaXhlZCsKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIElu
Zm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglDYXBhYmlsaXRpZXM6IFsx
OTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrCgkJQUNTQ3RsOglTcmNWYWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBD
bXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMtCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4KwoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5j
eTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDgsIHN1Ym9yZGluYXRlPTA4LCBzZWMtbGF0ZW5jeT0wCglJL08gYmVoaW5kIGJy
aWRnZTogMDAwMGMwMDAtMDAwMGNmZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAw
MC1mOWRmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAw
MGNmZTAwMDAwLTAwMDAwMDAwY2ZlZmZmZmYKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt
IDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBN
QWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNj
VG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5h
Z2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJy
ZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRp
ZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZD
YXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0
bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJ
CVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0YToJQ29yckVy
ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0K
CQlMbmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEs
IExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RS
ZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2Fi
bGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBBQldNZ210LQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9jay0g
Tm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNE
ZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25v
d24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJU3RhdHVz
OiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2st
CgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKwoJCVJvb3RDdGw6IEVyckNv
cnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2li
bGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwg
UE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDog
UmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKwoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQoJCUxua0N0bDI6
IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0s
IFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQgoJCQkgVHJhbnNtaXQgTWFyZ2luOiBO
b3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxp
YW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBD
dXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIKCUNhcGFiaWxpdGllczogW2EwXSBN
U0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0KCQlBZGRyZXNzOiBmZWUz
ZjAwYyAgRGF0YTogNDE2OQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRl
Y2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdCglDYXBhYmlsaXRpZXM6IFtiOF0g
SHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9
MSBMZW49MDEwIDw/PgoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBT
ZXJ2aWNlcwoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRS
ZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKwoJCUFDU0N0bDoJ
U3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2Qr
IEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVw
b3J0CgowMDowOS4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBS
RDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgSCkgWzEwMDI6
NWExY10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURG
LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv
cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA3LCBzdWJvcmRpbmF0ZT0w
Nywgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZm
CglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjljMDAwMDAtZjljZmZmZmYKCVByZWZldGNoYWJs
ZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAwMDAwMGZm
ZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VD
dGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkIt
CgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4t
CglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFn
czogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDIt
LEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBS
b290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRl
cywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZysg
UkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50
RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVh
ZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnIt
IFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICM0LCBTcGVl
ZCA1R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4
dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsKCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysK
CQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxu
a1N0YToJU3BlZWQgNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBN
UkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzksIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxl
OiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtD
aGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwt
IENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0
KyBMaW5rU3RhdGUrCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0g
RXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxl
LQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCgkJ
RGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBB
UklGd2QrCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBU
aW1lb3V0RGlzLSBBUklGd2QtCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9z
LCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczog
LTMuNWRCCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVu
dGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBE
ZS1lbXBoYXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6
IC0zLjVkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFz
a2FibGUtIDY0Yml0LQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRhOiA0MTcxCglDYXBhYmls
aXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEw
MDI6NWExMV0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBp
bmcgRW5hYmxlKyBGaXhlZCsKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNp
ZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglDYXBhYmlsaXRp
ZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzCgkJQUNTQ2FwOglTcmNWYWxp
ZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNz
Q3RybC0gRGlyZWN0VHJhbnMrCgkJQUNTQ3RsOglTcmNWYWxpZCsgVHJhbnNCbGstIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMt
CglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjBhLjAgUENJIGJyaWRnZSBb
MDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChl
eHRlcm5hbCBnZngxIHBvcnQgQSkgWzEwMDI6NWExZF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5U
eCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh
dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGlu
ZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlh
MDAwMDAtZjliZmZmZmYKCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAw
MDAwMDBmZmYwMDAwMC0wMDAwMDAwMDAwMGZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1I
ei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZH
QS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0g
RGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIg
TWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4
Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czog
RDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJp
bGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJ
RGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBz
IDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNv
cnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1Bl
bmQtCgkJTG5rQ2FwOglQb3J0ICM1LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBM
MHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0g
TExBY3RSZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz
IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0
V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0
aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBBQldNZ210
LQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhv
dFBsdWctIFN1cnByaXNlLQoJCQlTbG90ICMyLCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVy
bG9jay0gTm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwt
IFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5k
IFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKwoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUgUmVxSUQg
MDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJCURldkNhcDI6IENvbXBsZXRpb24gVGlt
ZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKwoJCURldkN0bDI6IENvbXBs
ZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQoJCUxu
a0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNw
ZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQgoJCQkgVHJhbnNtaXQgTWFy
Z2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0g
Q29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtT
dGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCCglDYXBhYmlsaXRpZXM6IFth
MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczog
ZmVlM2YwMGMgIERhdGE6IDQxNzkKCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFU
SSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQoJQ2FwYWJpbGl0aWVzOiBb
YjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKwoJQ2FwYWJp
bGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEg
UmV2PTEgTGVuPTAxMCA8Pz4KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRy
b2wgU2VydmljZXMKCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysKCQlBQ1ND
dGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFt
RndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBw
Y2llcG9ydAoKMDA6MGIuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJ
bmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKE5CLVNCIGxpbmspIFsxMDAyOjVhMWZdIChw
cm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlIrIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIy
Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS
Ui0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
CglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1s
YXRlbmN5PTAKCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZgoJTWVtb3J5
IGJlaGluZCBicmlkZ2U6IGY5OTAwMDAwLWY5OWZmZmZmCglQcmVmZXRjaGFibGUgbWVtb3J5
IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwYjAwMDAwMDAtMDAwMDAwMDBiZmZmZmZmZgoJU2Vj
b25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQoJQnJpZGdlQ3RsOiBQYXJp
dHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJCVByaURp
c2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCss
RDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0
IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWcrIFJCRSsgRkxS
ZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwt
IEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0g
QXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0KCQkJU2xvdCAjNSwgUG93ZXJM
aW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0
dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0K
CQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93ZXItIElu
dGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21k
Q3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExp
bmtTdGF0ZSsKCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJG
YXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJ
Um9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZD
YXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3
ZCsKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVv
dXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVu
dGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41
ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJN
b2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVt
cGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMu
NWRCCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxODEKCUNhcGFiaWxpdGll
czogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1
YTExXQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBF
bmFibGUrIEZpeGVkKwoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMg
SW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4KCUNhcGFiaWxpdGllczog
WzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMKCQlBQ1NDYXA6CVNyY1ZhbGlkKyBU
cmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJs
LSBEaXJlY3RUcmFucysKCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIr
IENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydAoKMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVy
bmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4KwoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5j
eTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDQsIHN1Ym9yZGluYXRlPTA0LCBzZWMtbGF0ZW5jeT0wCglJL08gYmVoaW5kIGJy
aWRnZTogMDAwMGYwMDAtMDAwMDBmZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTgwMDAw
MC1mOThmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAw
MGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQr
IDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBN
QWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNj
VG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5h
Z2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJy
ZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRp
ZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZD
YXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0
bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJ
CVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0YToJQ29yckVy
ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0K
CQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEs
IExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RS
ZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2Fi
bGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCA1R1QvcywgV2lkdGggeDEsIFRy
RXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdCsKCQlTbHRD
YXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBT
dXJwcmlzZS0KCQkJU2xvdCAjNCwgUG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5v
Q29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0
LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3du
LCBQd3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czog
QXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJ
CQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsKCQlSb290Q3RsOiBFcnJDb3Jy
ZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxl
LQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJh
bmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZCsKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRp
bWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwyOiBU
YXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBT
ZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9y
bWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFu
Y2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3Vy
cmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJ
OiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlM2Yw
MGMgIERhdGE6IDQxODkKCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNo
bm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5
cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKwoJQ2FwYWJpbGl0aWVz
OiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEg
TGVuPTAxMCA8Pz4KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2Vy
dmljZXMKCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVk
aXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysKCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9y
dAoKMDA6MTEuMCBTQVRBIGNvbnRyb2xsZXIgWzAxMDZdOiBBVEkgVGVjaG5vbG9naWVzIElu
YyBTQjd4MC9TQjh4MC9TQjl4MCBTQVRBIENvbnRyb2xsZXIgW0lERSBtb2RlXSBbMTAwMjo0
MzkwXSAocmV2IDQwKSAocHJvZy1pZiAwMSBbQUhDSSAxLjBdKQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQoJQ29u
dHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9v
cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog
Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRv
IElSUSAxMjEKCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQoJUmVnaW9u
IDE6IEkvTyBwb3J0cyBhdCA2MDAwIFtzaXplPTRdCglSZWdpb24gMjogSS9PIHBvcnRzIGF0
IDUwMDAgW3NpemU9OF0KCVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQoJ
UmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCAyMDAwIFtzaXplPTE2XQoJUmVnaW9uIDU6IE1lbW9y
eSBhdCBmOTZmZjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xS10KCUNh
cGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS80IE1hc2thYmxlLSA2NGJp
dCsKCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAxMDBjICBEYXRhOiA0MWMxCglDYXBhYmlsaXRp
ZXM6IFs3MF0gU0FUQSBIQkEgdjEuMCBJbkNmZ1NwYWNlCglDYXBhYmlsaXRpZXM6IFthNF0g
UENJIEFkdmFuY2VkIEZlYXR1cmVzCgkJQUZDYXA6IFRQKyBGTFIrCgkJQUZDdHJsOiBGTFIt
CgkJQUZTdGF0dXM6IFRQLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGFoY2kKCjAwOjEyLjAg
VVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4
MC9TQjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBb
T0hDSV0pCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4g
RGV2aWNlIFsxNDYyOjc2NDBdCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0
QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtCglMYXRlbmN5OiA2NCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50
ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4CglSZWdpb24gMDogTWVtb3J5IGF0IGY5
NmZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IG9oY2lfaGNkCgowMDoxMi4yIFVTQiBjb250cm9sbGVyIFswYzAzXTog
QVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kgQ29udHJv
bGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pCglTdWJzeXN0ZW06IE1pY3Jv
LVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBD
YXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0
LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiA2NCwg
Q2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8g
SVJRIDE3CglSZWdpb24gMDogTWVtb3J5IGF0IGY5NmZmNDAwICgzMi1iaXQsIG5vbi1wcmVm
ZXRjaGFibGUpIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGllczogW2MwXSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50
PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCgkJQnJpZGdlOiBQTS0g
QjMrCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTAK
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpLXBjaQoKMDA6MTMuMCBVU0IgY29udHJvbGxl
ciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBP
SENJMCBDb250cm9sbGVyIFsxMDAyOjQzOTddIChwcm9nLWlmIDEwIFtPSENJXSkKCVN1YnN5
c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6
NzY0MF0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
VisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgt
CglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk
aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh
dGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgMTgKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk2ZmMwMDAgKDMyLWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglLZXJuZWwgZHJpdmVyIGluIHVzZTog
b2hjaV9oY2QKCjAwOjEzLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgRUhDSSBDb250cm9sbGVyIFsxMDAyOjQz
OTZdIChwcm9nLWlmIDIwIFtFSENJXSkKCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5h
dGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0KCUNvbnRyb2w6IEkvTy0gTWVt
KyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHorIFVE
Ri0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxN
QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNp
emU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMTcKCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk2ZmY4MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MjU2XQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAy
CgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCss
RDErLEQyKyxEM2hvdCssRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVu
YWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCQlCcmlkZ2U6IFBNLSBCMysKCUNhcGFiaWxp
dGllczogW2U0XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBlMAoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IGVoY2ktcGNpCgowMDoxNC4wIFNNQnVzIFswYzA1XTogQVRJIFRlY2hub2xv
Z2llcyBJbmMgU0J4MDAgU01CdXMgQ29udHJvbGxlciBbMTAwMjo0Mzg1XSAocmV2IDQxKQoJ
Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1
czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IHBpaXg0X3NtYnVzCgowMDoxNC4xIElERSBpbnRlcmZhY2UgWzAxMDFd
OiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBJREUgQ29udHJvbGxl
ciBbMTAwMjo0MzljXSAocmV2IDQwKSAocHJvZy1pZiA4YSBbTWFzdGVyIFNlY1AgUHJpUF0p
CglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNl
IFsxNDYyOjc2NDBdCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMAoJUmVn
aW9uIDA6IEkvTyBwb3J0cyBhdCAwMWYwIFtzaXplPThdCglSZWdpb24gMTogSS9PIHBvcnRz
IGF0IDAzZjQgW3NpemU9MV0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgMDE3MCBbc2l6ZT04
XQoJUmVnaW9uIDM6IEkvTyBwb3J0cyBhdCAwMzc0IFtzaXplPTFdCglSZWdpb24gNDogSS9P
IHBvcnRzIGF0IGZmMDAgW3NpemU9MTZdCgowMDoxNC4zIElTQSBicmlkZ2UgWzA2MDFdOiBB
VEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMgaG9zdCBjb250cm9s
bGVyIFsxMDAyOjQzOWRdIChyZXYgNDApCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJu
YXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdCglDb250cm9sOiBJL08rIE1l
bSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUrIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0
ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBV
REYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwCgowMDoxNC40IFBDSSBi
cmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQngwMCBQQ0kgdG8gUENJIEJy
aWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAwMSBbU3VidHJhY3RpdmUgZGVj
b2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgt
CglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk
aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh
dGVuY3k6IDY0CglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMywgc3Vib3JkaW5hdGU9
MDMsIHNlYy1sYXRlbmN5PTY0CglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGEwMDAtMDAwMGFm
ZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZgoJUHJlZmV0Y2hh
YmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZgoJU2Vjb25kYXJ5
IHN0YXR1czogNjZNSHotIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0
LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eSsg
U0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rt
ci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCgowMDoxNC41IFVT
QiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAv
U0I5eDAgVVNCIE9IQ0kyIENvbnRyb2xsZXIgWzEwMDI6NDM5OV0gKHByb2ctaWYgMTAgW09I
Q0ldKQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIy
Qi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnIt
IERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJS
LSBJTlR4LQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVy
cnVwdDogcGluIEMgcm91dGVkIHRvIElSUSAxOAoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTZm
ZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10KCUtlcm5lbCBkcml2
ZXIgaW4gdXNlOiBvaGNpX2hjZAoKMDA6MTUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRl
Y2hub2xvZ2llcyBJbmMgU0I3MDAvU0I4MDAvU0I5MDAgUENJIHRvIFBDSSBicmlkZ2UgKFBD
SUUgcG9ydCAwKSBbMTAwMjo0M2EwXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pCglD
b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwg
Q2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9
MDIsIHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wCglJL08gYmVoaW5kIGJyaWRnZTog
MDAwMGYwMDAtMDAwMDBmZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBm
ZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAwMGZmZjAw
MDAwLTAwMDAwMDAwMDAwZmZmZmYKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJC
LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJS
LSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQt
ID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3Rh
dC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50
IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBt
QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs1
OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx
IDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz
OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxvYWQg
MTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlMbmtD
YXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBM
YXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJl
cCsgQndOb3QrCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMt
IEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIHVua25vd24sIFdpZHRoIHgxNiwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQoJCQlTbG90ICMzMiwgUG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVz
RGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtu
b3duLCBQd3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1
czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldC0gSW50ZXJsb2Nr
LQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQtIExpbmtTdGF0ZS0KCQlSb290Q3RsOiBFcnJD
b3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNp
YmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAs
IFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6
IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZC0KCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQgoJCQkgVHJhbnNtaXQgTWFyZ2lu
OiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29t
cGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEy
OiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCCglDYXBhYmlsaXRpZXM6IFthMF0g
TVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrCgkJQWRkcmVzczogMDAw
MDAwMDBmZWUzZjAwYyAgRGF0YTogNDE5MQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3Rl
bTogQVRJIFRlY2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjAwMDBdCglDYXBhYmlsaXRp
ZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/PgoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
CgowMDoxNi4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
U0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHBy
b2ctaWYgMTAgW09IQ0ldKQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwg
Q28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01h
c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0g
U0VSUisgRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQg
Ynl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxOAoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOTZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZAoKMDA6MTYuMiBVU0IgY29udHJvbGxl
ciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBF
SENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQoJU3Vic3lz
dGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3
NjQwXQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
KyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0K
CVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRp
dW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEIg
cm91dGVkIHRvIElSUSAxNwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTZmZmMwMCAoMzItYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdCglDYXBhYmlsaXRpZXM6IFtjMF0gUG93
ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisg
QXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQoJCVN0YXR1
czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJCUJy
aWRnZTogUE0tIEIzKwoJQ2FwYWJpbGl0aWVzOiBbZTRdIERlYnVnIHBvcnQ6IEJBUj0xIG9m
ZnNldD0wMGUwCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhjaS1wY2kKCjAwOjE4LjAgSG9z
dCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAx
MGggUHJvY2Vzc29yIEh5cGVyVHJhbnNwb3J0IENvbmZpZ3VyYXRpb24gWzEwMjI6MTIwMF0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglDYXBhYmlsaXRp
ZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3IgU2Vjb25kYXJ5IEludGVyZmFjZQoJ
CUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBIb3N0SGlk
ZSsgU2xhdmUtIDxFT0NFcnItIERVTC0KCQlMaW5rIENvbnRyb2w6IENGbEUtIENTVC0gQ0ZF
LSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElzb2NFbi0gTFNFbisgRXh0
Q1RMLSA2NGItCgkJTGluayBDb25maWc6IE1MV0k9MTZiaXQgRHdGY0luLSBNTFdPPTE2Yml0
IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0IER3RmNPdXRFbi0KCQlS
ZXZpc2lvbiBJRDogMy4wMAoJCUxpbmsgRnJlcXVlbmN5OiBbYl0KCQlMaW5rIEVycm9yOiA8
UHJvdC0gPE92ZmwtIDxFT0MtIENUTFRtLQoJCUxpbmsgRnJlcXVlbmN5IENhcGFiaWxpdHk6
IDIwME1IeisgMzAwTUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4MDBNSHorIDEuMEdI
eisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0gVmVuZC0KCQlGZWF0dXJlIENhcGFiaWxpdHk6
IElzb2NGQysgTERUU1RPUCsgQ1JDVE0tIEVDVExULSA2NGJBKyBVSURSRC0gRXh0UlMtIFVD
bmZFLQoKMDA6MTguMSBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERldmlj
ZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgQWRkcmVzcyBNYXAgWzEwMjI6MTIwMV0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0
dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCgowMDoxOC4yIEhv
c3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkg
MTBoIFByb2Nlc3NvciBEUkFNIENvbnRyb2xsZXIgWzEwMjI6MTIwMl0KCUNvbnRyb2w6IEkv
Ty0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVy
ci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcC0gNjZN
SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCgowMDoxOC4zIEhvc3QgYnJpZGdlIFsw
NjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3Nv
ciBNaXNjZWxsYW5lb3VzIENvbnRyb2wgWzEwMjI6MTIwM10KCUNvbnRyb2w6IEkvTy0gTWVt
LSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglDYXBhYmlsaXRpZXM6IFtmMF0gU2VjdXJlIGRl
dmljZSA8Pz4KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBrMTB0ZW1wCgowMDoxOC40IEhvc3Qg
YnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBo
IFByb2Nlc3NvciBMaW5rIENvbnRyb2wgWzEwMjI6MTIwNF0KCUNvbnRyb2w6IEkvTy0gTWVt
LSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcC0gNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCgowMzowNi4wIE11bHRpbWVkaWEgYXVkaW8gY29u
dHJvbGxlciBbMDQwMV06IEMtTWVkaWEgRWxlY3Ryb25pY3MgSW5jIENNODczOCBbMTNmNjow
MTExXSAocmV2IDEwKQoJU3Vic3lzdGVtOiBDLU1lZGlhIEVsZWN0cm9uaWNzIEluYyBDTUk4
NzM4L0MzRFggUENJIEF1ZGlvIERldmljZSBbMTNmNjowMTExXQoJQ29udHJvbDogSS9PKyBN
ZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0g
VURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQgKDUwMG5zIG1pbiwg
NjAwMG5zIG1heCkKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAyMgoJUmVnaW9u
IDA6IEkvTyBwb3J0cyBhdCBhODAwIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGllczogW2MwXSBQ
b3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQy
KyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3Rh
dHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglL
ZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoKMDQ6MDAuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IE5FQyBDb3Jwb3JhdGlvbiB1UEQ3MjAyMDAgVVNCIDMuMCBIb3N0IENvbnRyb2xs
ZXIgWzEwMzM6MDE5NF0gKHJldiAwMykgKHByb2ctaWYgMzAgW1hIQ0ldKQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo0MjU3
XQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6
IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVk
IHRvIElSUSA0MAoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOThmZTAwMCAoNjQtYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT04S10KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5h
Z2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJy
ZW50PTM3NW1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxp
dGllczogWzcwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsKCQlB
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs5
MF0gTVNJLVg6IEVuYWJsZSsgQ291bnQ9OCBNYXNrZWQtCgkJVmVjdG9yIHRhYmxlOiBCQVI9
MCBvZmZzZXQ9MDAwMDEwMDAKCQlQQkE6IEJBUj0wIG9mZnNldD0wMDAwMTA4MAoJQ2FwYWJp
bGl0aWVzOiBbYTBdIEV4cHJlc3MgKHYyKSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9u
LUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRG
dW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk
UmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0g
VW5zdXBwUmVxLSBBdXhQd3IrIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVk
IDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDR1cywgTDEgdW5s
aW1pdGVkCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCgkJTG5rQ3Rs
OglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D
bGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNKyBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0K
CQlMbmtTdGE6CVNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
KyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENvbXBsZXRpb24gVGlt
ZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcysKCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtDdGwyOiBUYXJnZXQg
TGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3Rh
YmxlIERlLWVtcGhhc2lzOiAtNmRCCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVy
YXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJ
CQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQgoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNl
ZCBFcnJvciBSZXBvcnRpbmcKCQlVRVN0YToJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRU
Ty0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEt
IEFDU1Zpb2wtCgkJVUVNc2s6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0
QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9s
LQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBV
bnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJQ0VT
dGE6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRh
bEVycisKCQlDRU1zazoJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVv
dXQtIE5vbkZhdGFsRXJyKwoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdl
bkNhcC0gQ0dlbkVuLSBDaGtDYXAtIENoa0VuLQoJQ2FwYWJpbGl0aWVzOiBbMTQwIHYxXSBE
ZXZpY2UgU2VyaWFsIE51bWJlciBmZi1mZi1mZi1mZi1mZi1mZi1mZi1mZgoJQ2FwYWJpbGl0
aWVzOiBbMTUwIHYxXSAjMTgKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrCgowNTow
MC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBBVEkgVGVjaG5vbG9naWVz
IEluYyBOSSBUdXJrcyBbQU1EIFJhZGVvbiBIRCA2NTAwXSBbMTAwMjo2NzU5XSAocHJvZy1p
ZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vic3lzdGVtOiBQQyBQYXJ0bmVyIExpbWl0ZWQg
RGV2aWNlIFsxNzRiOmUxOTNdCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJS
LSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50ZXJy
dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDMyCglSZWdpb24gMDogTWVtb3J5IGF0IGIwMDAw
MDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MjU2TV0KCVJlZ2lvbiAyOiBNZW1v
cnkgYXQgZjk5YzAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTI4S10K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYjAwMCBbc2l6ZT0yNTZdCglFeHBhbnNpb24gUk9N
IGF0IGY5OWEwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10KCUNhcGFiaWxpdGllczogWzUw
XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEr
IEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
CglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJ
IDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVu
Y3kgTDBzIDw0dXMsIEwxIHVubGltaXRlZAoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQt
IFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVj
dGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkKyBFeHRU
YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRl
cywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0g
RmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0
ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEww
IDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
CgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJh
aW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBB
dXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnItIFRy
YWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENv
bXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysKCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjog
Tm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBs
aWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjog
Q3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1T
STogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAwMDAw
MDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9y
IFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglDYXBh
YmlsaXRpZXM6IFsxNTAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglE
TFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9G
LSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVT
LSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRM
UC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0g
RkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JD
LSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0g
Um9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFkVExQ
LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglG
aXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4t
CglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoKMDU6MDAuMSBBdWRpbyBkZXZpY2Ug
WzA0MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6YWE5MF0KCVN1YnN5
c3RlbTogUEMgUGFydG5lciBMaW1pdGVkIERldmljZSBbMTc0YjphYTkwXQoJQ29udHJvbDog
SS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUludGVycnVwdDogcGluIEIgcm91
dGVkIHRvIElSUSAzMwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTlmYzAwMCAoNjQtYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTE2S10KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0p
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwg
TVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIDw0dXMsIEwxIHVubGltaXRlZAoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5J
bmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29y
cmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkKyBF
eHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBi
eXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVy
ci0gRmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQ
b3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5
IEwwIDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndO
b3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50
LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnIt
IFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysKCQlEZXZDdGwy
OiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtD
dGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVl
ZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdp
bjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENv
bXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBd
IE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAw
MDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVu
ZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglD
YXBhYmlsaXRpZXM6IFsxNTAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3Rh
OglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBS
eE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBT
REVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFs
ZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRM
UC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBF
Q1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExM
UC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFk
VExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2Fw
OglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hr
RW4tCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoKMDY6MDAuMCBNdWx0aW1lZGlh
IHZpZGVvIGNvbnRyb2xsZXIgWzA0MDBdOiBDb25leGFudCBTeXN0ZW1zLCBJbmMuIERldmlj
ZSBbMTRmMTo4MjEwXQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDog
cGluIEEgcm91dGVkIHRvIElSUSA0NwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWEwMDAwMCAo
NjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yTV0KCUNhcGFiaWxpdGllczogWzQw
XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlF
eHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0
bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3Vw
cG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29w
KwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDJ1cywgTDEgPDR1cwoJCQlDbG9ja1BNLSBTdXJw
cmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0
IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9z
LCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBB
QldNZ210LQoJQ2FwYWJpbGl0aWVzOiBbODBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAz
CgkJRmxhZ3M6IFBNRUNsay0gRFNJKyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCss
RDErLEQyKyxEM2hvdCssRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVu
YWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzkwXSBWaXRhbCBQ
cm9kdWN0IERhdGEKCQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDIsIHdpbGwgbm90
IGRlY29kZSBtb3JlLgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6
IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5n
CgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54
Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNr
OglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBS
eE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsg
U0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1h
bGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQ
LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4
RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisK
CQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hr
Q2FwLSBDaGtFbi0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBDaGFubmVsCgkJ
Q2FwczoJTFBFVkM9MSBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKCQlBcmI6CUZpeGVk
KyBXUlIzMisgV1JSNjQrIFdSUjEyOC0KCQlDdHJsOglBcmJTZWxlY3Q9V1JSNjQKCQlTdGF0
dXM6CUluUHJvZ3Jlc3MtCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQwXSA8Pz4KCQlW
QzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQoJ
CQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQoJ
CQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmCgkJCVN0YXR1
czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtCgkJVkMxOglDYXBzOglQQVRPZmZzZXQ9MDAg
TWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdS
UjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0KCQkJQ3RybDoJRW5hYmxlLSBJRD0xIEFy
YlNlbGVjdD1GaXhlZCBUQy9WQz0wMAoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dy
ZXNzLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sKCjA3OjAwLjAgVVNCIGNvbnRy
b2xsZXIgWzBjMDNdOiBORUMgQ29ycG9yYXRpb24gdVBENzIwMjAwIFVTQiAzLjAgSG9zdCBD
b250cm9sbGVyIFsxMDMzOjAxOTRdIChyZXYgMDMpIChwcm9nLWlmIDMwIFtYSENJXSkKCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgNDgKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjljZmUwMDAgKDY0LWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9OEtdCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93
ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0g
QXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3Rh
dHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglD
YXBhYmlsaXRpZXM6IFs3MF0gTVNJOiBFbmFibGUtIENvdW50PTEvOCBNYXNrYWJsZS0gNjRi
aXQrCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0
aWVzOiBbOTBdIE1TSS1YOiBFbmFibGUrIENvdW50PTggTWFza2VkLQoJCVZlY3RvciB0YWJs
ZTogQkFSPTAgb2Zmc2V0PTAwMDAxMDAwCgkJUEJBOiBCQVI9MCBvZmZzZXQ9MDAwMDEwODAK
CUNhcGFiaWxpdGllczogW2EwXSBFeHByZXNzICh2MikgRW5kcG9pbnQsIE1TSSAwMAoJCURl
dkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1
bmxpbWl0ZWQsIEwxIHVubGltaXRlZAoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3
ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFi
bGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRUYWct
IFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0gRmF0
YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyKyBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMw
LCBTcGVlZCA1R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw0dXMs
IEwxIHVubGltaXRlZAoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJ
CUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWlu
LSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTSsgQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtCgkJTG5rU3RhOglTcGVlZCA1R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0g
U2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCQlEZXZDYXAyOiBDb21wbGV0
aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQsIFRpbWVvdXREaXMrCgkJRGV2Q3RsMjogQ29t
cGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtCgkJTG5rQ3RsMjog
VGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwg
U2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQgoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3Jt
YWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5j
ZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJy
ZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIKCUNhcGFiaWxpdGllczogWzEwMCB2MV0g
QWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1At
IENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVu
c3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRP
LSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0g
QUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0
QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9s
LQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0g
Tm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVy
LSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6
IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtFbi0KCUNhcGFiaWxpdGllczogWzE0
MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgZmYtZmYtZmYtZmYtZmYtZmYtZmYtZmYKCUNh
cGFiaWxpdGllczogWzE1MCB2MV0gIzE4CglLZXJuZWwgZHJpdmVyIGluIHVzZTogeGhjaV9o
Y2QKCjA4OjAwLjAgRXRoZXJuZXQgY29udHJvbGxlciBbMDIwMF06IFJlYWx0ZWsgU2VtaWNv
bmR1Y3RvciBDby4sIEx0ZC4gUlRMODExMS84MTY4QiBQQ0kgRXhwcmVzcyBHaWdhYml0IEV0
aGVybmV0IGNvbnRyb2xsZXIgWzEwZWM6ODE2OF0gKHJldiAwMykKCVN1YnN5c3RlbTogTWlj
cm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6
IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0
LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBD
YWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJ
UlEgMTIzCglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGM4MDAgW3NpemU9MjU2XQoJUmVnaW9u
IDI6IE1lbW9yeSBhdCBjZmVmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRL
XQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmVmODAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUp
IFtzaXplPTE2S10KCUV4cGFuc2lvbiBST00gYXQgZjlkZTAwMDAgW2Rpc2FibGVkXSBbc2l6
ZT0xMjhLXQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAz
CgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQw
KyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTog
RW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAwMDAwMDAw
ZmVlMDEwMGMgIERhdGE6IDQxMjIKCUNhcGFiaWxpdGllczogWzcwXSBFeHByZXNzICh2Mikg
RW5kcG9pbnQsIE1TSSAwMQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2NHVzCgkJCUV4dFRhZy0gQXR0bkJ0
bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJy
b3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3AtCgkJCU1heFBheWxv
YWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVycisg
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3IrIFRyYW5zUGVuZC0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwg
TGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFj
dFJlcC0gQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWRE
aXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtCgkJ
RGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlz
KwoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0
RGlzLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBs
aWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQgoJCQkgVHJh
bnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29t
cGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCCglDYXBhYmls
aXRpZXM6IFthY10gTVNJLVg6IEVuYWJsZS0gQ291bnQ9NCBNYXNrZWQtCgkJVmVjdG9yIHRh
YmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDAKCQlQQkE6IEJBUj00IG9mZnNldD0wMDAwMDgw
MAoJQ2FwYWJpbGl0aWVzOiBbY2NdIFZpdGFsIFByb2R1Y3QgRGF0YQoJCVVua25vd24gc21h
bGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2RlIG1vcmUuCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglETFAtIFNE
RVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxm
VExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAt
IEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNS
Qy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBD
bXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1
cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnIrIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92
ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRE
TExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJzdCBF
cnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tCglDYXBh
YmlsaXRpZXM6IFsxNDAgdjFdIFZpcnR1YWwgQ2hhbm5lbAoJCUNhcHM6CUxQRVZDPTAgUmVm
Q2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBX
UlIxMjgtCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkCgkJU3RhdHVzOglJblByb2dyZXNzLQoJ
CVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMt
CgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYt
CgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYKCQkJU3Rh
dHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0KCUNhcGFiaWxpdGllczogWzE2MCB2MV0g
RGV2aWNlIFNlcmlhbCBOdW1iZXIgMDMtMDAtMDAtMDAtNjgtNGMtZTAtMDAKCUtlcm5lbCBk
cml2ZXIgaW4gdXNlOiByODE2OQoKMDk6MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyIFswMjAw
XTogUmVhbHRlayBTZW1pY29uZHVjdG9yIENvLiwgTHRkLiBSVEw4MTExLzgxNjhCIFBDSSBF
eHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQgY29udHJvbGxlciBbMTBlYzo4MTY4XSAocmV2IDAz
KQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmlj
ZSBbMTQ2Mjo3NjQwXQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0g
RGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDog
cGluIEEgcm91dGVkIHRvIElSUSAxMjIKCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgZDgwMCBb
c2l6ZT0yNTZdCglSZWdpb24gMjogTWVtb3J5IGF0IGNmZmZmMDAwICg2NC1iaXQsIHByZWZl
dGNoYWJsZSkgW3NpemU9NEtdCglSZWdpb24gNDogTWVtb3J5IGF0IGNmZmY4MDAwICg2NC1i
aXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZLXQoJRXhwYW5zaW9uIFJPTSBhdCBmOWVlMDAw
MCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3Vy
cmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrCgkJ
QWRkcmVzczogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFkMQoJQ2FwYWJpbGl0aWVzOiBb
NzBdIEV4cHJlc3MgKHYyKSBFbmRwb2ludCwgTVNJIDAxCgkJRGV2Q2FwOglNYXhQYXlsb2Fk
IDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJucywgTDEgPDY0dXMK
CQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlE
ZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBV
bnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNDA5NiBieXRlcwoJ
CURldlN0YToJQ29yckVycisgVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQ
d3IrIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzCgkJCUNsb2Nr
UE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBC
V01nbXQtIEFCV01nbXQtCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3Vw
cG9ydGVkLCBUaW1lb3V0RGlzKwoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1
cyB0byA1MG1zLCBUaW1lb3V0RGlzLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAy
LjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBo
YXNpczogLTZkQgoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdl
LCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFu
Y2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExl
dmVsOiAtNmRCCglDYXBhYmlsaXRpZXM6IFthY10gTVNJLVg6IEVuYWJsZS0gQ291bnQ9NCBN
YXNrZWQtCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDAKCQlQQkE6IEJB
Uj00IG9mZnNldD0wMDAwMDgwMAoJQ2FwYWJpbGl0aWVzOiBbY2NdIFZpdGFsIFByb2R1Y3Qg
RGF0YQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2Rl
IG1vcmUuCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGlu
ZwoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVu
eENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1z
azoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0g
UnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFAr
IFNERVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBN
YWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnIrIEJhZFRM
UC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglS
eEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIr
CgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENo
a0NhcCsgQ2hrRW4tCglDYXBhYmlsaXRpZXM6IFsxNDAgdjFdIFZpcnR1YWwgQ2hhbm5lbAoJ
CUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xCgkJQXJiOglGaXhl
ZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkCgkJU3Rh
dHVzOglJblByb2dyZXNzLQoJCVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90
cz0xIFJlalNub29wVHJhbnMtCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4
LSBUV1JSMTI4LSBXUlIyNTYtCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4
ZWQgVEMvVkM9ZmYKCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0KCUNhcGFi
aWxpdGllczogWzE2MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgMDQtMDAtMDAtMDAtNjgt
NGMtZTAtMDAKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQoKMGE6MDAuMCBQQ0kgYnJp
ZGdlIFswNjA0XTogVGV4YXMgSW5zdHJ1bWVudHMgWElPMjAwMChBKS9YSU8yMjAwQSBQQ0kg
RXhwcmVzcy10by1QQ0kgQnJpZGdlIFsxMDRjOjgyMzFdIChyZXYgMDMpIChwcm9nLWlmIDAw
IFtOb3JtYWwgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglCdXM6IHBy
aW1hcnk9MGEsIHNlY29uZGFyeT0wYiwgc3Vib3JkaW5hdGU9MGIsIHNlYy1sYXRlbmN5PTY0
CglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYKCU1lbW9yeSBiZWhpbmQg
YnJpZGdlOiBmOWYwMDAwMC1mOWZmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQg
YnJpZGdlOiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYKCVNlY29uZGFyeSBz
dGF0dXM6IDY2TUh6LSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydCsgPFNFUlItIDxQRVJSLQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNF
UlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJCVByaURpc2NUbXIt
IFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2FwYWJpbGl0aWVz
OiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xk
LSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0KCQlCcmlkZ2U6IFBNLSBCMysKCUNhcGFiaWxpdGllczogWzYwXSBNU0k6IEVuYWJs
ZS0gQ291bnQ9MS8xNiBNYXNrYWJsZS0gNjRiaXQrCgkJQWRkcmVzczogMDAwMDAwMDAwMDAw
MDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVzOiBbODBdIFN1YnN5c3RlbTogR2FtbWFn
cmFwaHgsIEluYy4gKG9yIG1pc3NpbmcgSUQpIERldmljZSBbMDAwMDowMDAwXQoJQ2FwYWJp
bGl0aWVzOiBbOTBdIEV4cHJlc3MgKHYxKSBQQ0kvUENJLVggQnJpZGdlLCBNU0kgMDAKCQlE
ZXZDYXA6CU1heFBheWxvYWQgNTEyIGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDR1cywgTDEgPDY0dXMKCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJC
RS0gRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24t
RmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1
bmMtIEF1eFB3ci0gTm9Tbm9vcCsgQnJDb25mUnRyeS0KCQkJTWF4UGF5bG9hZCAxMjggYnl0
ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnIr
IEZhdGFsRXJyLSBVbnN1cHBSZXErIEF1eFB3cisgVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9y
dCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEww
IDwxdXMsIEwxIDwxNnVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
CgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0K
CQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxu
a1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg
RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2
YW5jZWQgRXJyb3IgUmVwb3J0aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENt
cGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3Vw
UmVxKyBBQ1NWaW9sLQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBD
bXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNT
VmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJy
dC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJ
CUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9u
RmF0YWxFcnItCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBU
aW1lb3V0LSBOb25GYXRhbEVyci0KCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDE0
LCBHZW5DYXArIENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0KCjBiOjAxLjAgVVNCIGNvbnRyb2xs
ZXIgWzBjMDNdOiBORUMgQ29ycG9yYXRpb24gVVNCIFsxMDMzOjAwMzVdIChyZXYgNDMpIChw
cm9nLWlmIDEwIFtPSENJXSkKCVN1YnN5c3RlbTogTkVDIENvcnBvcmF0aW9uIEhhbWEgVVNC
IDIuMCBDYXJkQnVzIFsxMDMzOjAwMzVdCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkIt
IFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS
Ui0gPFBFUlItIElOVHgtCglMYXRlbmN5OiA2NCAoMjUwbnMgbWluLCAxMDUwMG5zIG1heCks
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRv
IElSUSAyOQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZDAwMCAoMzItYml0LCBub24tcHJl
ZmV0Y2hhYmxlKSBbc2l6ZT00S10KCUNhcGFiaWxpdGllczogWzQwXSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50
PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogb2hjaV9oY2QKCjBiOjAxLjEgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBORUMg
Q29ycG9yYXRpb24gVVNCIFsxMDMzOjAwMzVdIChyZXYgNDMpIChwcm9nLWlmIDEwIFtPSENJ
XSkKCVN1YnN5c3RlbTogTkVDIENvcnBvcmF0aW9uIEhhbWEgVVNCIDIuMCBDYXJkQnVzIFsx
MDMzOjAwMzVdCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJ
TlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
CglMYXRlbmN5OiA2NCAoMjUwbnMgbWluLCAxMDUwMG5zIG1heCksIENhY2hlIExpbmUgU2l6
ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAzMAoJUmVnaW9u
IDA6IE1lbW9yeSBhdCBmOWZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6
ZT00S10KCUNhcGFiaWxpdGllczogWzQwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJ
CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFi
bGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9o
Y2QKCjBiOjAxLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBORUMgQ29ycG9yYXRpb24gVVNC
IDIuMCBbMTAzMzowMGUwXSAocmV2IDA0KSAocHJvZy1pZiAyMCBbRUhDSV0pCglTdWJzeXN0
ZW06IERldmljZSBbMTgzODoxMDc0XQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt
IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQgKDQwMDBucyBtaW4sIDg1MDBucyBtYXgpLCBD
YWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJ
UlEgMzEKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZmZjMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9MjU2XQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1l
bnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9
MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29m
dFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBlaGNpLXBjaQoKMGM6MDAuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVyIFsw
MzAwXTogblZpZGlhIENvcnBvcmF0aW9uIEc5OCBbR2VGb3JjZSA4NDAwIEdTXSBbMTBkZTow
NmU0XSAocmV2IGExKSAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vic3lzdGVt
OiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjgyNjZdCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2
TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9y
dC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGlu
ZSBTaXplOiA2NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEwCglS
ZWdpb24gMDogTWVtb3J5IGF0IGZkMDAwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp
IFtzaXplPTE2TV0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZDAwMDAwMDAgKDY0LWJpdCwgcHJl
ZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQoJUmVnaW9uIDM6IE1lbW9yeSBhdCBmYTAwMDAwMCAo
NjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dCglSZWdpb24gNTogSS9PIHBv
cnRzIGF0IGU4MDAgW3NpemU9MTI4XQoJRXhwYW5zaW9uIFJPTSBhdCBmZTllMDAwMCBbZGlz
YWJsZWRdIFtzaXplPTEyOEtdCglDYXBhYmlsaXRpZXM6IFs2MF0gUG93ZXIgTWFuYWdlbWVu
dCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0w
bUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0
UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBb
NjhdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6
IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzc4XSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0
ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw0dXMKCQkJRXh0VGFn
KyBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJ
TWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BN
IEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDwxdXMKCQkJQ2xvY2tQTS0gU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiAxMjgg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BN
LSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms
IFdpZHRoIHg4LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFC
V01nbXQtCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbAoJCUNhcHM6
CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xCgkJQXJiOglGaXhlZC0gV1JS
MzItIFdSUjY0LSBXUlIxMjgtCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkCgkJU3RhdHVzOglJ
blByb2dyZXNzLQoJCVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJl
alNub29wVHJhbnMtCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JS
MTI4LSBXUlIyNTYtCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMv
VkM9ZmYKCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0KCUNhcGFiaWxpdGll
czogWzEyOCB2MV0gUG93ZXIgQnVkZ2V0aW5nIDw/PgoJQ2FwYWJpbGl0aWVzOiBbNjAwIHYx
XSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAyNCA8
Pz4KCg==
------------0FB1ED1493275D29B
Content-Type: application/octet-stream;
 name="v39sync.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="v39sync.log"

ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9fX19fICAgICAgICAgICAgICAgICAgICBf
ICAgICAgICBfICAgICBfICAgICAgDQogIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19f
IC8gICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyANCiAgIFwgIC8v
IF8gXCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8
ICdfIFx8IHwvIF8gXA0KICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98IF9fXykgfF9ffCB8
X3wgfCB8IHwgXF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vDQogIC9fL1xfXF9fX3xffCB8
X3wgICAgfF98KF8pX19fXy8gICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98
XF9fX3wNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIChYRU4pIFhlbiB2ZXJzaW9uIDQuMy11
bnN0YWJsZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40LjUtOCkgNC40LjUp
IGRlYnVnPXkgVHVlIEZlYiAyNiAxMTozMTowOSBDRVQgMjAxMw0KIChYRU4pIExhdGVzdCBD
aGFuZ2VTZXQ6IHVuYXZhaWxhYmxlDQogKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hy
b25vdXMuDQogKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3NxdWVl
emUxDQogKFhFTikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9n
bHZsPWFsbCBsb2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyBzeW5jX2NvbnNv
bGUgdmdhPWdmeC0xMjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBk
ZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11
PW9uLHZlcmJvc2UsZGVidWcsYW1kLWlvbW11LWRlYnVnLG5vLWFtZC1pb21tdS1wZXJkZXYt
aW50cmVtYXAgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2EsY29tMQ0KIChYRU4pIFZpZGVv
IGluZm9ybWF0aW9uOg0KIChYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQs
IDMyIGJwcA0KIChYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRp
bWU6IDEgc2Vjb25kcw0KIChYRU4pIERpc2MgaW5mb3JtYXRpb246DQogKFhFTikgIEZvdW5k
IDIgTUJSIHNpZ25hdHVyZXMNCiAoWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3Ry
dWN0dXJlcw0KIChYRU4pIFhlbi1lODIwIFJBTSBtYXA6DQogKFhFTikgIDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDlmMDAwICh1c2FibGUpDQogKFhFTikgIDAwMDAwMDAwMDAw
OWYwMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkNCiAoWEVOKSAgMDAwMDAwMDAw
MDBlNDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KIChYRU4pICAwMDAwMDAw
MDAwMTAwMDAwIC0gMDAwMDAwMDBhZmY5MDAwMCAodXNhYmxlKQ0KIChYRU4pICAwMDAwMDAw
MGFmZjkwMDAwIC0gMDAwMDAwMDBhZmY5ZTAwMCAoQUNQSSBkYXRhKQ0KIChYRU4pICAwMDAw
MDAwMGFmZjllMDAwIC0gMDAwMDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQogKFhFTikgIDAw
MDAwMDAwYWZmZTAwMDAgLSAwMDAwMDAwMGIwMDAwMDAwIChyZXNlcnZlZCkNCiAoWEVOKSAg
MDAwMDAwMDBmZmUwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KIChYRU4p
ICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KIChYRU4p
IEFDUEk6IFJTRFAgMDAwRkIxMDAsIDAwMTQgKHIwIEFDUElBTSkNCiAoWEVOKSBBQ1BJOiBS
U0RUIEFGRjkwMDAwLCAwMDQ4IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykNCiAoWEVOKSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMg
QTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCiAoWEVOKSBBQ1BJOiBEU0RUIEFG
RjkwNUUwLCA5NDI3IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAgSU5UTCAyMDA1MTEx
NykNCiAoWEVOKSBBQ1BJOiBGQUNTIEFGRjlFMDAwLCAwMDQwDQogKFhFTikgQUNQSTogQVBJ
QyBBRkY5MDM5MCwgMDA4OCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAg
ICAgOTcpDQogKFhFTikgQUNQSTogTUNGRyBBRkY5MDQyMCwgMDAzQyAocjEgNzY0ME1TIE9F
TU1DRkcgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQogKFhFTikgQUNQSTogU0xJQyBBRkY5
MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcp
DQogKFhFTikgQUNQSTogT0VNQiBBRkY5RTA0MCwgMDA3MiAocjEgNzY0ME1TIEE3NjQwMTAw
IDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQogKFhFTikgQUNQSTogU1JBVCBBRkY5QTVFMCwg
MDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEpDQogKFhF
TikgQUNQSTogSFBFVCBBRkY5QTZGMCwgMDAzOCAocjEgNzY0ME1TIE9FTUhQRVQgIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpDQogKFhFTikgQUNQSTogSVZSUyBBRkY5QTczMCwgMDEwMCAo
cjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAgICAgICAgIDApDQogKFhFTikgQUNQ
STogU1NEVCBBRkY5QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAxIEFN
RCAgICAgICAgIDEpDQogKFhFTikgU3lzdGVtIFJBTTogODE5MU1CICg4Mzg3Nzcya0IpDQog
KFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0KIChYRU4pIFNSQVQ6IFBY
TSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCiAoWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDIg
LT4gTm9kZSAwDQogKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+IE5vZGUgMA0KIChY
RU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCiAoWEVOKSBTUkFUOiBQWE0g
MCAtPiBBUElDIDUgLT4gTm9kZSAwDQogKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDAtYTAw
MDANCiAoWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWIwMDAwMDAwDQogKFhFTikg
U1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC0yNTAwMDAwMDANCiAoWEVOKSBOVU1BOiBB
bGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDg4MjAwMCAtIDI0ZDg4NTAwMA0KIChYRU4p
IE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KIChYRU4pIERvbWFpbiBoZWFw
IGluaXRpYWxpc2VkDQogKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGZiMDAwMDAw
LCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwgMTQz
MzZrDQogKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01
MTIwLCBmb250IDh4MTYNCiAoWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04Ojg6ODo4
LCBzaGlmdD0yNDoxNjo4OjANCiAoWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3
ODANCiAoWEVOKSBETUkgcHJlc2VudC4NCiAoWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMgJ3hh
cGljJw0KIChYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCiAoWEVOKSBBQ1BJOiBQ
TS1UaW1lciBJTyBQb3J0OiAweDgwOA0KIChYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhf
Y250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdDQogKFhFTikgQUNQSTogICAgICAgICAgICAg
d2FrZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KIChYRU4pIEFDUEk6IExvY2Fs
IEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQogKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCiAoWEVOKSBQcm9jZXNzb3IgIzAgMDox
MCBBUElDIHZlcnNpb24gMTYNCiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBs
YXBpY19pZFsweDAxXSBlbmFibGVkKQ0KIChYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMg
dmVyc2lvbiAxNg0KIChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lk
WzB4MDJdIGVuYWJsZWQpDQogKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQogKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10g
ZW5hYmxlZCkNCiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCiAo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVk
KQ0KIChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KIChYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQogKFhF
TikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQogKFhFTikgQUNQSTogSU9B
UElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KIChYRU4p
IElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAs
IEdTSSAwLTIzDQogKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVj
MjAwMDBdIGdzaV9iYXNlWzI0XSkNCiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVy
c2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNCiAoWEVOKSBBQ1BJOiBJ
TlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KIChY
RU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxv
dyBsZXZlbCkNCiAoWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQogKFhFTikg
QUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLg0KIChYRU4pIEFDUEk6IElSUTkgdXNlZCBi
eSBvdmVycmlkZS4NCiAoWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcg
MiBJL08gQVBJQ3MNCiAoWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQw
MDAwMA0KIChYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCiAoWEVOKSBVc2luZyBBQ1BJIChN
QURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCiAoWEVOKSBTTVA6IEFs
bG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQogKFhFTikgbWFwcGVkIEFQSUMgdG8g
ZmZmZjgyYzNmZmRmYjAwMCAoZmVlMDAwMDApDQogKFhFTikgbWFwcGVkIElPQVBJQyB0byBm
ZmZmODJjM2ZmZGZhMDAwIChmZWMwMDAwMCkNCiAoWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZm
ZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQ0KIChYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwg
MTExMiBNU0kvTVNJLVgNCiAoWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2No
ZWR1bGVyIChjcmVkaXQpDQogKFhFTikgRGV0ZWN0ZWQgMzIwMC4xOTggTUh6IHByb2Nlc3Nv
ci4NCiAoWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KIChYRU4pIEFNRCBGYW0xMGgg
bWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KIChYRU4pIFBDSTogTUNGRyBjb25m
aWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYN
CiAoWEVOKSBQQ0k6IE5vdCB1c2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZm
DQogKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kgY2FwYWJpbGl0eSBibG9jayBhdCAweDU0DQog
KFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KIChYRU4pIEFNRC1WaTogIFNpZ25hdHVyZSBJ
VlJTDQogKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4MTAwDQogKFhFTikgQU1ELVZpOiAgUmV2
aXNpb24gMHgxDQogKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHg4OQ0KIChYRU4pIEFNRC1W
aTogIE9FTV9JZCBBTUQgIA0KIChYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBSRDg5MFMN
CiAoWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCiAoWEVOKSBBTUQtVmk6
ICBDcmVhdG9yX0lkIEFNRCANCiAoWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9uIDAN
CiAoWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBmbGFncyAweDNlIGxlbiAw
eGQwIGlkIDB4Mg0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgz
IGlkIDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDIN
CiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDEwIGZs
YWdzIDANCiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAw
eGMwMCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHgxOCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhMDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHg0MyBpZCAweGIwOCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweGIwOCAtPiAweGJmZiBhbGlhcyAweGIwMA0KIChYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MjggZmxhZ3MgMA0KIChYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4OTAwIGZsYWdzIDANCiAo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdz
IDANCiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDgw
MCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHg0OCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHg3MDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgyIGlkIDB4NTAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjAwIGZsYWdzIDANCiAoWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDU4IGZsYWdzIDANCiAoWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDUwMCBmbGFncyAwDQogKFhF
TikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDUwMCAtPiAweDUwMQ0KIChYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjggZmxhZ3MgMA0KIChYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDAwIGZsYWdzIDAN
CiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDg4IGZs
YWdzIDANCiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAw
eDkwIGZsYWdzIDANCiAoWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5
Mg0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTgg
ZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQog
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMCBmbGFn
cyAweGQ3DQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHhhMSBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHhhMyBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhNCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHg0MyBpZCAweDMwMCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDMwMCAtPiAweDNmZiBhbGlhcyAweGE0DQogKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhNSBmbGFncyAwDQogKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhOCBmbGFncyAwDQogKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhOSBmbGFncyAw
DQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAg
ZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlk
IDB4YjAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhiMCAtPiAw
eGIyDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxh
Z3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAw
IGZsYWdzIDB4ZDcNCiAoWEVOKSBBTUQtVmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDoxNC4w
IHZhcmlldHkgMHgyIGhhbmRsZSAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBTcGVjaWFs
OiAwMDAwOjAwOjAwLjEgdmFyaWV0eSAweDEgaGFuZGxlIDB4Nw0KIChYRU4pIElWSEQgRXJy
b3I6IG5vIGluZm9ybWF0aW9uIGZvciBJTy1BUElDIDB4Ng0KIChYRU4pIEFNRC1WaTogSU9N
TVUgMCBFbmFibGVkLg0KIChYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFsIHZlY3RvciBt
YXANCiAoWEVOKSBBTUQtVmk6IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUg
aXMgbm90IHJlY29tbWVuZGVkIChzZWUgWFNBLTM2KSENCiAoWEVOKSBJL08gdmlydHVhbGlz
YXRpb24gZW5hYmxlZA0KIChYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KIChYRU4pIEdl
dHRpbmcgVkVSU0lPTjogODAwNTAwMTANCiAoWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUw
MDEwDQogKFhFTikgR2V0dGluZyBJRDogMA0KIChYRU4pIEdldHRpbmcgTFZUMDogNzAwDQog
KFhFTikgR2V0dGluZyBMVlQxOiA0MDANCiAoWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUj
MA0KIChYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAweDQgIGFmdGVy
OiAwDQogKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzDQogKFhFTikgIC0+IFVzaW5nIG5l
dyBBQ0sgbWV0aG9kDQogKFhFTikgaW5pdCBJT19BUElDIElSUXMNCiAoWEVOKSAgSU8tQVBJ
QyAoYXBpY2lkLXBpbikgNi0wLCA2LTE2LCA2LTE3LCA2LTE4LCA2LTE5LCA2LTIwLCA2LTIx
LCA2LTIyLCA2LTIzLCA3LTAsIDctMSwgNy0yLCA3LTMsIDctNCwgNy01LCA3LTYsIDctNywg
Ny04LCA3LTksIDctMTAsIDctMTEsIDctMTIsIDctMTMsIDctMTQsIDctMTUsIDctMTYsIDct
MTcsIDctMTgsIDctMTksIDctMjAsIDctMjEsIDctMjIsIDctMjMsIDctMjQsIDctMjUsIDct
MjYsIDctMjcsIDctMjgsIDctMjksIDctMzAsIDctMzEgbm90IGNvbm5lY3RlZC4NCiAoWEVO
KSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0x
DQogKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCiAoWEVOKSBudW1iZXIg
b2YgSU8tQVBJQyAjNiByZWdpc3RlcnM6IDI0Lg0KIChYRU4pIG51bWJlciBvZiBJTy1BUElD
ICM3IHJlZ2lzdGVyczogMzIuDQogKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uDQogKFhFTikgSU8gQVBJQyAjNi4uLi4uLg0KIChYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBB
UElDIGlkOiAwNg0KIChYRU4pIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBUeXBlOiAwDQogKFhF
TikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCiAoWEVOKSAuLi4uIHJlZ2lzdGVy
ICMwMTogMDAxNzgwMjENCiAoWEVOKSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBl
bnRyaWVzOiAwMDE3DQogKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDEN
CiAoWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KIChYRU4pIC4u
Li4gcmVnaXN0ZXIgIzAyOiAwNjAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRy
YXRpb246IDA2DQogKFhFTikgLi4uLiByZWdpc3RlciAjMDM6IDA3MDAwMDAwDQogKFhFTikg
Li4uLi4uLiAgICAgOiBCb290IERUICAgIDogMA0KIChYRU4pIC4uLi4gSVJRIHJlZGlyZWN0
aW9uIHRhYmxlOg0KIChYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQg
RGVzdCBEZWxpIFZlY3Q6ICAgDQogKFhFTikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAg
IDAgICAwICAgIDEgICAgMSAgICAzMA0KIChYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAw
ICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQogKFhFTikgIDAzIDAwMSAwMSAgMCAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgMzgNCiAoWEVOKSAgMDQgMDAxIDAxICAwICAgIDAg
ICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KIChYRU4pICAwNSAwMDEgMDEgIDAgICAg
MCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQogKFhFTikgIDA2IDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDgNCiAoWEVOKSAgMDcgMDAxIDAxICAw
ICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KIChYRU4pICAwOCAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4DQogKFhFTikgIDA5IDAwMSAw
MSAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNjANCiAoWEVOKSAgMGEgMDAx
IDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0KIChYRU4pICAwYiAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwDQogKFhFTikgIDBj
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzgNCiAoWEVOKSAg
MGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4OA0KIChYRU4p
ICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwDQogKFhF
TikgIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTgNCiAo
WEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
IChYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KIChYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQogKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KIChYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQogKFhFTikgSU8gQVBJQyAjNy4uLi4uLg0KIChYRU4pIC4uLi4gcmVn
aXN0ZXIgIzAwOiAwNzAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElD
IGlkOiAwNw0KIChYRU4pIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBUeXBlOiAwDQogKFhFTikg
Li4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCiAoWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MTogMDAxRjgwMjENCiAoWEVOKSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRy
aWVzOiAwMDFGDQogKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCiAo
WEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KIChYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAyOiAwMDAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRp
b246IDAwDQogKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQogKFhFTikgIE5S
IExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCiAo
WEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
IChYRU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogKFhFTikgIDAyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KIChYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQogKFhFTikgIDA1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KIChYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQogKFhFTikgIDA4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDBiIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDBlIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMGYgMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAxMCAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDExIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMTIgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAxMyAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDE0IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMTUgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAxNiAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDE3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAg
MTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4p
ICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhF
TikgIDFhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
IChYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogKFhFTikgIDFkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KIChYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQogKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nDQogKFhFTikgSVJR
IHRvIHBpbiBtYXBwaW5nczoNCiAoWEVOKSBJUlEyNDAgLT4gMDoyDQogKFhFTikgSVJRNDgg
LT4gMDoxDQogKFhFTikgSVJRNTYgLT4gMDozDQogKFhFTikgSVJRMjQxIC0+IDA6NA0KIChY
RU4pIElSUTY0IC0+IDA6NQ0KIChYRU4pIElSUTcyIC0+IDA6Ng0KIChYRU4pIElSUTgwIC0+
IDA6Nw0KIChYRU4pIElSUTg4IC0+IDA6OA0KIChYRU4pIElSUTk2IC0+IDA6OQ0KIChYRU4p
IElSUTEwNCAtPiAwOjEwDQogKFhFTikgSVJRMTEyIC0+IDA6MTENCiAoWEVOKSBJUlExMjAg
LT4gMDoxMg0KIChYRU4pIElSUTEzNiAtPiAwOjEzDQogKFhFTikgSVJRMTQ0IC0+IDA6MTQN
CiAoWEVOKSBJUlExNTIgLT4gMDoxNQ0KIChYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLiBkb25lLg0KIChYRU4pIFVzaW5nIGxvY2FsIEFQSUMgdGltZXIgaW50
ZXJydXB0cy4NCiAoWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KIChYRU4pIC4u
Li4uIENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE2MjYgTUh6Lg0KIChYRU4pIC4uLi4uIGhv
c3QgYnVzIGNsb2NrIHNwZWVkIGlzIDIwMC4wMTAwIE1Iei4NCiAoWEVOKSAuLi4uLiBidXNf
c2NhbGUgPSAweGNjZDcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0gUGxhdGZvcm0g
dGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0g
QWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MTk6NTJdIEhWTTogQVNJRHMgZW5hYmxlZC4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Ml0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MTk6NTJdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjE5OjUyXSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVh
bGlzYXRpb24NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0gIC0gTmV4dC1SSVAgU2F2
ZWQgb24gI1ZNRVhJVA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUyXSAgLSBQYXVzZS1J
bnRlcmNlcHQgRmlsdGVyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTJdIEhWTTogU1ZN
IGVuYWJsZWQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0gSFZNOiBIYXJkd2FyZSBB
c3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Ml0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFHQg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjE5OjUxXSBtYXNrZWQgRXh0SU5UIG9uIENQVSMxDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MTk6NTNdIG1pY3JvY29kZTogQ1BVMSBjb2xsZWN0X2NwdV9pbmZvOiBwYXRj
aF9pZD0weDEwMDAwYmYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1MV0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUzXSBtaWNyb2NvZGU6
IENQVTIgY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MTk6NTFdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1M10gbWljcm9jb2RlOiBDUFUzIGNvbGxlY3RfY3B1X2luZm86IHBh
dGNoX2lkPTB4MTAwMDBiZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUxXSBtYXNrZWQg
RXh0SU5UIG9uIENQVSM0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIG1pY3JvY29k
ZTogQ1BVNCBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToxOTo1MV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjE5OjUzXSBCcm91Z2h0IHVwIDYgQ1BVcw0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjE5OjUzXSBtaWNyb2NvZGU6IENQVTUgY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hf
aWQ9MHgxMDAwMGJmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIEhQRVQ6IDMgdGlt
ZXJzICgzIHdpbGwgYmUgdXNlZCBmb3IgYnJvYWRjYXN0KQ0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjE5OjUzXSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjUzXSBNQ0E6IFVzZSBodyB0aHJlc2hvbGRpbmcgdG8gYWRqdXN0IHBvbGxpbmcgZnJl
cXVlbmN5DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIG1jaGVja19wb2xsOiBNYWNo
aW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToxOTo1M10gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwg
SUJTQ1RMID0gMHhmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUzXSAqKiog
TE9BRElORyBET01BSU4gMCAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1M10gZWxm
X3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZGM5MDAwDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBh
ZGRyPTB4MWUwMDAwMCBtZW1zej0weGVhMGYwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6
NTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVlYjAwMCBtZW1zej0weDE0
MDQwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBo
ZHI6IHBhZGRyPTB4MWYwMDAwMCBtZW1zej0weGU2YjAwMA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjE5OjUzXSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDJk
NmIwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1M10gZWxmX3hlbl9wYXJzZV9ub3Rl
OiBHVUVTVF9PUyA9ICJsaW51eCINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1M10gZWxm
X3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToxOTo1M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4t
My4wIg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUzXSBlbGZfeGVuX3BhcnNlX25vdGU6
IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjUzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxZjAwMWUw
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFlQ
RVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToxOTo1M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFn
ZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYiINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MTk6NTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVy
aWMiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdIGVsZl94ZW5fcGFyc2Vfbm90ZTog
dW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1
NF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjE5OjU0XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9
IDB4ZmZmZjgwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSBlbGZf
eGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjE5OjU0XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZm
ZmY4MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgZWxmX3BhZGRy
X29mZnNldCA9IDB4MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9v
ZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjU0XSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZm
ZmZmZmY4MmQ2YjAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9l
bnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWYwMDFlMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjU0XSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBj
b21wYXQzMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgRG9tMCBrZXJuZWw6IDY0
LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJkNmIwMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToxOTo1NF0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDI0MDAw
MDAwMC0+MDAwMDAwMDI0NDAwMDAwMCAoMjQyNTE2IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAy
NGYzNTQwMDAtPjAwMDAwMDAyNGZmZmZjMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1
NF0gVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgyZDZi
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBJbml0LiByYW1kaXNrOiBmZmZm
ZmZmZjgyZDZiMDAwLT5mZmZmZmZmZjgzYTE2YzAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgzYTE3MDAwLT5mZmZmZmZmZjgzYzE3
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBTdGFydCBpbmZvOiAgICBmZmZm
ZmZmZjgzYzE3MDAwLT5mZmZmZmZmZjgzYzE3NGI0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzYzE4MDAwLT5mZmZmZmZmZjgzYzNi
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBCb290IHN0YWNrOiAgICBmZmZm
ZmZmZjgzYzNiMDAwLT5mZmZmZmZmZjgzYzNjMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjg0MDAw
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBFTlRSWSBBRERSRVNTOiBmZmZm
ZmZmZjgxZjAwMWUwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdIERvbTAgaGFzIG1h
eGltdW0gNiBWQ1BVcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSBlbGZfbG9hZF9i
aW5hcnk6IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxZGM5
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdIGVsZl9sb2FkX2JpbmFyeTogcGhk
ciAxIGF0IDB4ZmZmZmZmZmY4MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZWEwZjANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToxOTo1NF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhm
ZmZmZmZmZjgxZWViMDAwIC0+IDB4ZmZmZmZmZmY4MWVmZjA0MA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjE5OjU0XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODFm
MDAwMDAgLT4gMHhmZmZmZmZmZjgxZmZlMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6
NTVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDAsIHJvb3Qg
dGFibGUgPSAweDI0N2IxZTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MTk6NTVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgxMCwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgxOCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgzMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MCwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHg1OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg2OCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MCwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHg5Miwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg5YSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMSwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHhhMywgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHhhNSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhOCwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHhiMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMiwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToxOTo1Nl0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBzZXR1cCAwMDAwOjAwOjE4LjAgZm9yIGQw
IGZhaWxlZCAoLTE5KQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTZdIHNldHVwIDAwMDA6MDA6MTguMSBmb3IgZDAgZmFpbGVkICgtMTkpDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MTk6NTZdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAw
OjAwOjE4LjINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gc2V0dXAgMDAwMDowMDox
OC4yIGZvciBkMCBmYWlsZWQgKC0xOSkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0g
QU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjE5OjU2XSBzZXR1cCAwMDAwOjAwOjE4LjMgZm9yIGQwIGZhaWxlZCAoLTE5
KQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBBTUQtVmk6IE5vIGlvbW11IGZvciBk
ZXZpY2UgMDAwMDowMDoxOC40DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTZdIHNldHVw
IDAwMDA6MDA6MTguNCBmb3IgZDAgZmFpbGVkICgtMTkpDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MTk6NTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
NDAwLCByb290IHRhYmxlID0gMHgyNDdiMWUwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MDEs
IHJvb3QgdGFibGUgPSAweDI0N2IxZTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4NjAwLCByb290IHRhYmxlID0gMHgyNDdiMWUwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgcm9v
dCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg4MDAsIHJvb3QgdGFibGUgPSAweDI0N2IxZTAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTddIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4OTAwLCByb290IHRh
YmxlID0gMHgyNDdiMWUwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjE5OjU3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGEwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1N10gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMDAsIHJvb3QgdGFibGUg
PSAweDI0N2IxZTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MTk6NTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4YzAwLCByb290IHRhYmxlID0gMHgyNDdiMWUwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU3XSBTY3J1YmJpbmcg
RnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4NCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToxOTo1OV0gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQw
MDAgcGFnZXMuDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTldIFN0ZC4gTG9nbGV2ZWw6
IEFsbA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU5XSBHdWVzdCBMb2dsZXZlbDogQWxs
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTldICoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1OV0g
KioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjE5OjU5XSAqKioqKioqIFRoaXMgb3B0aW9uIGlzIGludGVuZGVk
IHRvIGFpZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MTk6NTldICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNocm9ub3VzbHkg
ZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1OV0gKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0
ZW5jaWVzIGFuZCBhZmZlY3QNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1OV0gKioqKioq
KiB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVkIGZvciBwcm9kdWN0aW9uIHVz
ZSENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1OV0gKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU5
XSAzLi4uIDIuLi4gMS4uLiANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDowMl0gWGVuIGlz
IHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6
MDJdICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1l
cyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjAy
XSBGcmVlZCAyNDhrQiBpbml0IG1lbW9yeS4NCiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp
Y2FsIG1lbW9yeQ0KIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MDJdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4g
MHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQogWyAgICAwLjAwMDAwMF0gSW5pdGlh
bGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQogIFsgICAgMC4wMDAwMDBdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGNwdQ0KICBbICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9u
IDMuOC4wLXJjMC0yMDEzMDIyNyAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9u
IDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBXZWQgRmViIDI3IDA5
OjQ5OjQ1IENFVCAyMDEzDQogIFsgICAgMC4wMDAwMDBdIENvbW1hbmQgbGluZTogcm9vdD0v
ZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJvIHZlcmJvc2UgbWVtPTEwMjRNIGNv
bnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT03OTQgdmlkZW89dmVzYWZi
IG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTANCiAgWyAg
ICAwLjAwMDAwMF0gRnJlZWluZyA5Zi0xMDAgcGZuIHJhbmdlOiA5NyBwYWdlcyBmcmVlZA0K
ICBbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiA5Zi0+MTAwDQogIFsgICAgMC4wMDAw
MDBdIDEtMSBtYXBwaW5nIG9uIGFmZjkwLT4xMDAwMDANCiAgWyAgICAwLjAwMDAwMF0gUmVs
ZWFzZWQgOTcgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQ0KICBbICAgIDAuMDAwMDAwXSBTZXQg
MzI3ODg5IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcNCiAgWyAgICAwLjAwMDAwMF0gUG9wdWxh
dGluZyA0MDAwMC00MDA2MSBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGFkZGVkDQogIFsgICAgMC4w
MDAwMDBdIGU4MjA6IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoNCiAgWyAgICAw
LjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVm
ZmZdIHVzYWJsZQ0KICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDlm
MDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNCiAgWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwNDAwNjBmZmZdIHVzYWJsZQ0K
ICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAw
MDBhZmY4ZmZmZl0gdW51c2FibGUNCiAgWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0KICBbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGFmZjllMDAwLTB4MDAwMDAwMDBhZmZkZmZm
Zl0gQUNQSSBOVlMNCiAgWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmZl
MDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVkDQogIFsgICAgMC4wMDAwMDBdIFhl
bjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZl
ZA0KICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAw
MDAwMDBmZWMyMGZmZl0gcmVzZXJ2ZWQNCiAgWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJlc2VydmVkDQogIFsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZm
ZmZmXSByZXNlcnZlZA0KICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMTAw
MDAwMDAwLTB4MDAwMDAwMDI0ZmZmZmZmZl0gdW51c2FibGUNCiAgWyAgICAwLjAwMDAwMF0g
ZTgyMDogcmVtb3ZlIFttZW0gMHg0MDAwMDAwMC0weGZmZmZmZmZmZmZmZmZmZmVdIHVzYWJs
ZQ0KICBbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBh
Y3RpdmUNCiAgWyAgICAwLjAwMDAwMF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJB
TSBtYXA6DQogIFsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAw
LTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNhYmxlDQogIFsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNCiAg
WyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAw
MDNmZmZmZmZmXSB1c2FibGUNCiAgWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAw
MDAwNDAwNjEwMDAtMHgwMDAwMDAwMGFmZjhmZmZmXSB1bnVzYWJsZQ0KICBbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZd
IEFDUEkgZGF0YQ0KICBbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5
ZTAwMC0weDAwMDAwMDAwYWZmZGZmZmZdIEFDUEkgTlZTDQogIFsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGFmZmUwMDAwLTB4MDAwMDAwMDBhZmZmZmZmZl0gcmVzZXJ2
ZWQNCiAgWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgw
MDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KICBbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVt
IDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQogIFsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNCiAgWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAw
MDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KICBbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDAyNGZmZmZmZmZd
IHVudXNhYmxlDQogIFsgICAgMC4wMDAwMDBdIFNNQklPUyAyLjUgcHJlc2VudC4NCiAgWyAg
ICAwLjAwMDAwMF0gRE1JOiBNU0kgTVMtNzY0MC84OTBGWEEtR0Q3MCAoTVMtNzY0MCkgICwg
QklPUyBWMS44QjEgMDkvMTMvMjAxMA0KICBbICAgIDAuMDAwMDAwXSBlODIwOiB1cGRhdGUg
W21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2ZWQNCiAgWyAg
ICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgwMDBhMDAwMC0weDAwMGZmZmZmXSB1
c2FibGUNCiAgWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZA0KICBbICAgIDAu
MDAwMDAwXSBlODIwOiBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAw
MDAwMDANCiAgWyAgICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9y
eSBjb3JydXB0aW9uDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBm
YjEwMCAwMDAxNCAodjAwIEFDUElBTSkNCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEVCAw
MDAwMDAwMGFmZjkwMDAwIDAwMDQ4ICh2MDEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1T
RlQgMDAwMDAwOTcpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAwMDAwMDBhZmY5
MDIwMCAwMDA4NCAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3
KQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAgMDk0Mjcg
KHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNCiAgWyAgICAw
LjAwMDAwMF0gQUNQSTogRkFDUyAwMDAwMDAwMGFmZjllMDAwIDAwMDQwDQogIFsgICAgMC4w
MDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBhZmY5MDM5MCAwMDA4OCAodjAxIDc2NDBNUyBB
NzY0MDEwMCAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAx
MDA5MTMgTVNGVCAwMDAwMDA5NykNCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogU0xJQyAwMDAw
MDAwMGFmZjkwNDYwIDAwMTc2ICh2MDEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDBhZmY5ZTA0
MCAwMDA3MiAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0K
ICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1ZTAgMDAxMDggKHYw
MyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkNCiAgWyAgICAwLjAw
MDAwMF0gQUNQSTogSFBFVCAwMDAwMDAwMGFmZjlhNmYwIDAwMDM4ICh2MDEgNzY0ME1TIE9F
TUhQRVQgIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6
IElWUlMgMDAwMDAwMDBhZmY5YTczMCAwMDEwMCAodjAxICBBTUQgICAgIFJEODkwUyAwMDIw
MjAzMSBBTUQgIDAwMDAwMDAwKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAw
MDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAw
MDAwMDAwMSkNCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4
ZmVlMDAwMDANCiAgWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBb
ZmZmZjg4MDAwMDA5OTAwMF0gOTkwMDAgc2l6ZSAyNDU3Ng0KICBbICAgIDAuMDAwMDAwXSBp
bml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0NCiAgWyAg
ICAwLjAwMDAwMF0gIFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZmXSBwYWdlIDRrDQogIFsg
ICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgzZmUwMDAwMC0weDNm
ZmZmZmZmXQ0KICBbICAgIDAuMDAwMDAwXSAgW21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZd
IHBhZ2UgNGsNCiAgWyAgICAwLjAwMDAwMF0gQlJLIFsweDAyOTVmMDAwLCAweDAyOTVmZmZm
XSBQR1RBQkxFDQogIFsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0g
MHgzYzAwMDAwMC0weDNmZGZmZmZmXQ0KICBbICAgIDAuMDAwMDAwXSAgW21lbSAweDNjMDAw
MDAwLTB4M2ZkZmZmZmZdIHBhZ2UgNGsNCiAgWyAgICAwLjAwMDAwMF0gQlJLIFsweDAyOTYw
MDAwLCAweDAyOTYwZmZmXSBQR1RBQkxFDQogIFsgICAgMC4wMDAwMDBdIEJSSyBbMHgwMjk2
MTAwMCwgMHgwMjk2MWZmZl0gUEdUQUJMRQ0KICBbICAgIDAuMDAwMDAwXSBCUksgWzB4MDI5
NjIwMDAsIDB4MDI5NjJmZmZdIFBHVEFCTEUNCiAgWyAgICAwLjAwMDAwMF0gQlJLIFsweDAy
OTYzMDAwLCAweDAyOTYzZmZmXSBQR1RBQkxFDQogIFsgICAgMC4wMDAwMDBdIGluaXRfbWVt
b3J5X21hcHBpbmc6IFttZW0gMHgwMDEwMDAwMC0weDNiZmZmZmZmXQ0KICBbICAgIDAuMDAw
MDAwXSAgW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgNGsNCiAgWyAgICAwLjAw
MDAwMF0gUkFNRElTSzogW21lbSAweDAyZDZiMDAwLTB4MDNhMTZmZmZdDQogIFsgICAgMC4w
MDAwMDBdIE5VTUEgdHVybmVkIG9mZg0KICBbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2Rl
IGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0NCiAgWyAg
ICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAwMDAwLTB4M2Zm
ZmZmZmZdDQogIFsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgzZmUxYTAwMC0w
eDNmZTI0ZmZmXQ0KICBbICAgIDAuMDAwMDAwXSBab25lIHJhbmdlczoNCiAgWyAgICAwLjAw
MDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMDEwMDAtMHgwMGZmZmZmZl0NCiAgWyAgICAw
LjAwMDAwMF0gICBETUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NCiAgWyAg
ICAwLjAwMDAwMF0gICBOb3JtYWwgICBlbXB0eQ0KICBbICAgIDAuMDAwMDAwXSBNb3ZhYmxl
IHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KICBbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1v
cnkgbm9kZSByYW5nZXMNCiAgWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAw
MDAxMDAwLTB4MDAwOWVmZmZdDQogIFsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0g
MHgwMDEwMDAwMC0weDNmZmZmZmZmXQ0KICBbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90
YWxwYWdlczogMjYyMDQ2DQogIFsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2Vz
IHVzZWQgZm9yIG1lbW1hcA0KICBbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAyMSBwYWdl
cyByZXNlcnZlZA0KICBbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTk4IHBhZ2VzLCBM
SUZPIGJhdGNoOjANCiAgWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MDMyIHBhZ2Vz
IHVzZWQgZm9yIG1lbW1hcA0KICBbICAgIDAuMDAwMDAwXSAgIERNQTMyIHpvbmU6IDI1ODA0
OCBwYWdlcywgTElGTyBiYXRjaDozMQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBQTS1UaW1l
ciBJTyBQb3J0OiAweDgwOA0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFk
ZHJlc3MgMHhmZWUwMDAwMA0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KICBbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAyXSBl
bmFibGVkKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBs
YXBpY19pZFsweDAzXSBlbmFibGVkKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KICBbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
ICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMw
MDAwMF0gZ3NpX2Jhc2VbMF0pDQogIFsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19p
ZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQogIFsgICAg
MC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBn
c2lfYmFzZVsyNF0pDQogIFsgICAgMC4wMDAwMDBdIElPQVBJQ1sxXTogYXBpY19pZCA3LCB2
ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC01NQ0KICBbICAgIDAuMDAw
MDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBk
ZmwgZGZsKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6
IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMiB1
c2VkIGJ5IG92ZXJyaWRlLg0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkg
b3ZlcnJpZGUuDQogIFsgICAgMC4wMDAwMDBdIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAg
Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVU
IGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KICBbICAgIDAuMDAwMDAwXSBzbXBib290
OiBBbGxvd2luZyA2IENQVXMsIDAgaG90cGx1ZyBDUFVzDQogIFsgICAgMC4wMDAwMDBdIG5y
X2lycXNfZ3NpOiA3Mg0KICBbICAgIDAuMDAwMDAwXSBlODIwOiBbbWVtIDB4YjAwMDAwMDAt
MHhmZWJmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kgZGV2aWNlcw0KICBbICAgIDAuMDAwMDAw
XSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuDQogIFsgICAgMC4wMDAw
MDBdIFhlbiB2ZXJzaW9uOiA0LjMtdW5zdGFibGUgKHByZXNlcnZlLUFEKQ0KICBbICAgIDAu
MDAwMDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNrX2JpdHM6OCBucl9j
cHVfaWRzOjYgbnJfbm9kZV9pZHM6MQ0KICBbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVk
ZGVkIDI4IHBhZ2VzL2NwdSBAZmZmZjg4MDAzZjgwMDAwMCBzODE5ODQgcjgxOTIgZDI0NTEy
IHUyNjIxNDQNCiAgWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogczgxOTg0IHI4MTkyIGQy
NDUxMiB1MjYyMTQ0IGFsbG9jPTEqMjA5NzE1Mg0KICBbICAgIDAuMDAwMDAwXSBwY3B1LWFs
bG9jOiBbMF0gMCAxIDIgMyA0IDUgLSAtIA0KICBbICAgMTAuNjI4NDM5XSBCdWlsdCAxIHpv
bmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBh
Z2VzOiAyNTc5MjkNCiAgWyAgIDEwLjYyODQ0MV0gUG9saWN5IHpvbmU6IERNQTMyDQogIFsg
ICAxMC42Mjg0NDhdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2Vy
dmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIG1lbT0xMDI0TSBjb25zb2xlPWh2YzAgY29u
c29sZT10dHkwIG5vbW9kZXNldCB2Z2E9Nzk0IHZpZGVvPXZlc2FmYiBtYXhfbG9vcD01MCBs
b29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xldmVsPTEwDQogIFsgICAxMC42Mjg1NzldIFBJ
RCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykNCiAg
WyAgIDEwLjYyODU4NV0gX19leF90YWJsZSBhbHJlYWR5IHNvcnRlZCwgc2tpcHBpbmcgc29y
dA0KICBbICAgMTAuNjcwODUwXSBzb2Z0d2FyZSBJTyBUTEIgW21lbSAweDNhNjAwMDAwLTB4
M2U2MDAwMDBdICg2NE1CKSBtYXBwZWQgYXQgW2ZmZmY4ODAwM2E2MDAwMDAtZmZmZjg4MDAz
ZTVmZmZmZl0NCiAgWyAgIDEwLjY3NTk4M10gTWVtb3J5OiA5MjE4MDRrLzEwNDg1NzZrIGF2
YWlsYWJsZSAoOTk1N2sga2VybmVsIGNvZGUsIDM5MmsgYWJzZW50LCAxMjYzODBrIHJlc2Vy
dmVkLCA1MzEwayBkYXRhLCAxMDY4ayBpbml0KQ0KICBbICAgMTAuNjc2Mjk1XSBTTFVCOiBH
ZW5zbGFicz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9
NiwgTm9kZXM9MQ0KICBbICAgMTAuNjc2NDA1XSBQcmVlbXB0aWJsZSBoaWVyYXJjaGljYWwg
UkNVIGltcGxlbWVudGF0aW9uLg0KICBbICAgMTAuNjc2NDA3XSAJUkNVIGR5bnRpY2staWRs
ZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQogIFsgICAxMC42NzY0
MDhdIAlBZGRpdGlvbmFsIHBlci1DUFUgaW5mbyBwcmludGVkIHdpdGggc3RhbGxzLg0KICBb
ICAgMTAuNjc2NDA5XSAJUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8g
bnJfY3B1X2lkcz02Lg0KICBbICAgMTAuNjc2NDU2XSBOUl9JUlFTOjQzNTIgbnJfaXJxczox
MjcyIDE2DQogIFsgICAxMC42NzY1OTZdIHhlbjogc2NpIG92ZXJyaWRlOiBnbG9iYWxfaXJx
PTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENCiAgWyAgIDEwLjY3NjU5OF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMTAuNjc2NjMzXSB4
ZW46IC0tPiBwaXJxPTkgLT4gaXJxPTkgKGdzaT05KQ0KICBbICAgMTAuNzAyNDE4XSB4ZW46
IGFjcGkgc2NpIDkNCiAgWyAgIDEwLjcwMjQzMV0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0x
IChnc2k9MSkNCiAgWyAgIDEwLjcwMjQzN10geGVuOiAtLT4gcGlycT0yIC0+IGlycT0yIChn
c2k9MikNCiAgWyAgIDEwLjcwMjQ0M10geGVuOiAtLT4gcGlycT0zIC0+IGlycT0zIChnc2k9
MykNCiAgWyAgIDEwLjcwMjQ0OV0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkN
CiAgWyAgIDEwLjcwMjQ1NV0geGVuOiAtLT4gcGlycT01IC0+IGlycT01IChnc2k9NSkNCiAg
WyAgIDEwLjcwMjQ2Ml0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikNCiAgWyAg
IDEwLjcwMjQ2OF0geGVuOiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykNCiAgWyAgIDEw
LjcwMjQ3NF0geGVuOiAtLT4gcGlycT04IC0+IGlycT04IChnc2k9OCkNCiAgWyAgIDEwLjcw
MjQ4MF0geGVuOiAtLT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkNCiAgWyAgIDEwLjcw
MjQ4Nl0geGVuOiAtLT4gcGlycT0xMSAtPiBpcnE9MTEgKGdzaT0xMSkNCiAgWyAgIDEwLjcw
MjQ5Ml0geGVuOiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdzaT0xMikNCiAgWyAgIDEwLjcw
MjQ5OF0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMgKGdzaT0xMykNCiAgWyAgIDEwLjcw
MjUwNF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQgKGdzaT0xNCkNCiAgWyAgIDEwLjcw
MjUxMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkNCiAgWyAgIDEwLjcw
MjYxNV0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQ0KICBbICAgMTAuNzA0
MDkxXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkDQogIFsgICAxMy4zNTg4OTJdIGNvbnNvbGUg
W2h2YzBdIGVuYWJsZWQNCiAgWyAgIDEzLjM2OTI5NF0gTG9jayBkZXBlbmRlbmN5IHZhbGlk
YXRvcjogQ29weXJpZ2h0IChjKSAyMDA2IFJlZCBIYXQsIEluYy4sIEluZ28gTW9sbmFyDQog
IFsgICAxMy4zOTI2ODldIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOA0KICBbICAg
MTMuNDA1MTY4XSAuLi4gTUFYX0xPQ0tfREVQVEg6ICAgICAgICAgIDQ4DQogIFsgICAxMy40
MTc5MDhdIC4uLiBNQVhfTE9DS0RFUF9LRVlTOiAgICAgICAgODE5MQ0KICBbICAgMTMuNDMx
MTY2XSAuLi4gQ0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYNCiAgWyAgIDEzLjQ0NDQy
NV0gLi4uIE1BWF9MT0NLREVQX0VOVFJJRVM6ICAgICAxNjM4NA0KICBbICAgMTMuNDU3OTQ0
XSAuLi4gTUFYX0xPQ0tERVBfQ0hBSU5TOiAgICAgIDMyNzY4DQogIFsgICAxMy40NzE0NjVd
IC4uLiBDSEFJTkhBU0hfU0laRTogICAgICAgICAgMTYzODQNCiAgWyAgIDEzLjQ4NDk4NF0g
IG1lbW9yeSB1c2VkIGJ5IGxvY2sgZGVwZW5kZW5jeSBpbmZvOiA1ODU1IGtCDQogIFsgICAx
My41MDEzNjJdICBwZXIgdGFzay1zdHJ1Y3QgbWVtb3J5IGZvb3RwcmludDogMTkyMCBieXRl
cw0KICBbICAgMTMuNTE3NzQyXSBrbWVtbGVhazogS2VybmVsIG1lbW9yeSBsZWFrIGRldGVj
dG9yIGRpc2FibGVkDQogIFsgICAxMy41MzQ0NDBdIFhlbjogdXNpbmcgdmNwdW9wIHRpbWVy
IGludGVyZmFjZQ0KICBbICAgMTMuNTQ3NjgwXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3Ig
Q1BVIDANCiAgWyAgIDEzLjU2MDIxMV0gdHNjOiBEZXRlY3RlZCAzMjAwLjE5OCBNSHogcHJv
Y2Vzc29yDQogIFsgICAxMy41NzQyNDZdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBw
ZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDY0MDIuMDcg
Qm9nb01JUFMgKGxwaj0xMDY2NzMyNikNCiAgWyAgIDEzLjYwNjQzMl0gcGlkX21heDogZGVm
YXVsdDogMzI3NjggbWluaW11bTogMzAxDQogIFsgICAxMy42MjA3NTFdIERlbnRyeSBjYWNo
ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMp
DQogIFsgICAxMy42NDIzODVdIElub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1
MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpDQogIFsgICAxMy42NjI5ODJdIE1vdW50LWNh
Y2hlIGhhc2ggdGFibGUgZW50cmllczogMjU2DQogIFsgICAxMy42NzcyNDNdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QNCiAgWyAgIDEzLjY5MDI4Nl0gSW5pdGlhbGl6
aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcg0KICBbICAgMTMuNzAzODEwXSBJbml0aWFsaXpp
bmcgY2dyb3VwIHN1YnN5cyBibGtpbw0KICBbICAgMTMuNzE2ODYxXSB0c2VnOiAwMDAwMDAw
MDAwDQogIFsgICAxMy43MjU2NjddIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwDQog
IFsgICAxMy43Mzc4NTRdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDANCiAgWyAgIDEzLjc0
OTAzNV0gbWNlOiBDUFUgc3VwcG9ydHMgMiBNQ0UgYmFua3MNCiAgWyAgIDEzLjc2MTI2MV0g
TFZUIG9mZnNldCAwIGFzc2lnbmVkIGZvciB2ZWN0b3IgMHhmOQ0KICBbICAgMTMuNzc1NTUz
XSBbRmlybXdhcmUgQnVnXTogY3B1IDAsIHRyeSB0byB1c2UgQVBJQzUwMCAoTFZUIG9mZnNl
dCAwKSBmb3IgdmVjdG9yIDB4ZjksIGJ1dCB0aGUgcmVnaXN0ZXIgaXMgYWxyZWFkeSBpbiB1
c2UgZm9yIHZlY3RvciAweDAgb24gdGhpcyBjcHUNCiAgWyAgIDEzLjgxNTMzMF0gW0Zpcm13
YXJlIEJ1Z106IGNwdSAwLCBmYWlsZWQgdG8gc2V0dXAgdGhyZXNob2xkIGludGVycnVwdCBm
b3IgYmFuayA0LCBibG9jayAwIChNU1IwMDAwMDQxMz0weGMwMDgwMDAwMDEwMDAwMDApDQog
IFsgICAxMy44NDg4NzRdIExhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIg
MTYsIDRNQiA4DQogIFsgICAxMy44NDg4NzRdIExhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0
S0IgNTEyLCAyTUIgMTI4LCA0TUIgNjQNCiAgWyAgIDEzLjg0ODg3NF0gdGxiX2ZsdXNoYWxs
X3NoaWZ0OiA0DQogIFsgICAxMy44OTM0MTJdIEZyZWVpbmcgU01QIGFsdGVybmF0aXZlczog
MzJrIGZyZWVkDQogIFsgICAxMy45MDc3ODBdIEFDUEk6IENvcmUgcmV2aXNpb24gMjAxMzAx
MTcNCiAgWyAgIDEzLjkyMzA5NV0gQUNQSTogQWxsIEFDUEkgVGFibGVzIHN1Y2Nlc3NmdWxs
eSBhY3F1aXJlZA0KICBbICAgMTMuOTQwODk1XSBQZXJmb3JtYW5jZSBFdmVudHM6IChYRU4p
IFsyMDEzLTAyLTI3IDExOjIwOjA1XSB0cmFwcy5jOjI0OTU6ZDAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4
MDAwMDAwMDAwMDAwZmZmZi4NCiBCcm9rZW4gUE1VIGhhcmR3YXJlIGRldGVjdGVkLCB1c2lu
ZyBzb2Z0d2FyZSBldmVudHMgb25seS4NCiAgWyAgIDEzLjk5OTQyM10gRmFpbGVkIHRvIGFj
Y2VzcyBwZXJmY3RyIG1zciAoTVNSIGMwMDEwMDA0IGlzIDApDQogIFsgICAxNC4wMzA5MTRd
IE5NSSB3YXRjaGRvZzogZGlzYWJsZWQgKGNwdTApOiBoYXJkd2FyZSBldmVudHMgbm90IGVu
YWJsZWQNCiAgWyAgIDE0LjA1MDQyMF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAx
DQogIFsgICAxNC4wNjI3ODFdIFNNUCBhbHRlcm5hdGl2ZXM6IGxvY2tkZXA6IGZpeGluZyB1
cCBhbHRlcm5hdGl2ZXMNCiAgWyAgIDE0LjA4MDIxNl0gW0Zpcm13YXJlIEJ1Z106IGNwdSAx
LCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBvZmZzZXQgMCkgZm9yIHZlY3RvciAweGY5LCBi
dXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkgaW4gdXNlIGZvciB2ZWN0b3IgMHgwIG9uIHRo
aXMgY3B1DQogIFsgICAxNC4wODAyMThdIFtGaXJtd2FyZSBCdWddOiBjcHUgMSwgZmFpbGVk
IHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1cHQgZm9yIGJhbmsgNCwgYmxvY2sgMCAoTVNS
MDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAwKQ0KICBbICAgMTQuMDgwNTM1XSBpbnN0YWxs
aW5nIFhlbiB0aW1lciBmb3IgQ1BVIDINCiAgWyAgIDE0LjE2NjA2Nl0gW0Zpcm13YXJlIEJ1
Z106IGNwdSAyLCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBvZmZzZXQgMCkgZm9yIHZlY3Rv
ciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkgaW4gdXNlIGZvciB2ZWN0b3Ig
MHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC4xNjYwNjldIFtGaXJtd2FyZSBCdWddOiBjcHUg
MiwgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1cHQgZm9yIGJhbmsgNCwgYmxv
Y2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAwKQ0KICBbICAgMTQuMTY2MzM2
XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMNCiAgWyAgIDE0LjI1MTk0Nl0gW0Zp
cm13YXJlIEJ1Z106IGNwdSAzLCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBvZmZzZXQgMCkg
Zm9yIHZlY3RvciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkgaW4gdXNlIGZv
ciB2ZWN0b3IgMHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC4yNTE5NDhdIFtGaXJtd2FyZSBC
dWddOiBjcHUgMywgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1cHQgZm9yIGJh
bmsgNCwgYmxvY2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAwKQ0KICBbICAg
MTQuMjUyMTk2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDQNCiAgWyAgIDE0LjMz
Nzc3NF0gW0Zpcm13YXJlIEJ1Z106IGNwdSA0LCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBv
ZmZzZXQgMCkgZm9yIHZlY3RvciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkg
aW4gdXNlIGZvciB2ZWN0b3IgMHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC4zMzc3NzddIFtG
aXJtd2FyZSBCdWddOiBjcHUgNCwgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1
cHQgZm9yIGJhbmsgNCwgYmxvY2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAw
KQ0KICBbICAgMTQuMzM4MDM4XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDUNCiAg
WyAgIDE0LjQyMzYyOF0gW0Zpcm13YXJlIEJ1Z106IGNwdSA1LCB0cnkgdG8gdXNlIEFQSUM1
MDAgKExWVCBvZmZzZXQgMCkgZm9yIHZlY3RvciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlz
IGFscmVhZHkgaW4gdXNlIGZvciB2ZWN0b3IgMHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC40
MjM2MzBdIFtGaXJtd2FyZSBCdWddOiBjcHUgNSwgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9s
ZCBpbnRlcnJ1cHQgZm9yIGJhbmsgNCwgYmxvY2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAw
MDAxMDAwMDAwKQ0KICBbICAgMTQuNDIzNjkzXSBCcm91Z2h0IHVwIDYgQ1BVcw0KICBbICAg
MTQuNTA3MTIxXSBHcmFudCB0YWJsZXMgdXNpbmcgdmVyc2lvbiAyIGxheW91dC4NCiAgWyAg
IDE0LjUyMDY5OF0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQNCiAgWyAgIDE0LjUzMTQ3OV0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNg0KICBbICAgMTQuNTQ3NDM3XSBu
b2RlIDAgbGluayAwOiBpbyBwb3J0IFsxMDAwLCBmZmZmZmZdDQogIFsgICAxNC41NjEyNzZd
IFRPTTogMDAwMDAwMDBiMDAwMDAwMCBha2EgMjgxNk0NCiAgWyAgIDE0LjU3NDAxMF0gRmFt
IDEwaCBtbWNvbmYgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdDQogIFsgICAxNC41ODk2
MDBdIG5vZGUgMCBsaW5rIDA6IG1taW8gW2UwMDAwMDAwLCBlZmZmZmZmZl0gPT0+IG5vbmUN
CiAgWyAgIDE0LjYwNzAxMV0gbm9kZSAwIGxpbmsgMDogbW1pbyBbZjAwMDAwMDAsIGZmZmZm
ZmZmXQ0KICBbICAgMTQuNjIyMDg5XSBub2RlIDAgbGluayAwOiBtbWlvIFthMDAwMCwgYmZm
ZmZdDQogIFsgICAxNC42MzU2MDddIG5vZGUgMCBsaW5rIDA6IG1taW8gW2IwMDAwMDAwLCBk
ZmZmZmZmZl0NCiAgWyAgIDE0LjY1MDY4Nl0gVE9NMjogMDAwMDAwMDI1MDAwMDAwMCBha2Eg
OTQ3Mk0NCiAgWyAgIDE0LjY2MzY5OF0gYnVzOiBbYnVzIDAwLTA3XSBvbiBub2RlIDAgbGlu
ayAwDQogIFsgICAxNC42NzY5NTBdIGJ1czogMDAgW2lvICAweDAwMDAtMHhmZmZmXQ0KICBb
ICAgMTQuNjg4NjQ5XSBidXM6IDAwIFttZW0gMHhmMDAwMDAwMC0weGZmZmZmZmZmXQ0KICBb
ICAgMTQuNzAyNDI3XSBidXM6IDAwIFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KICBb
ICAgMTQuNzE2MjA2XSBidXM6IDAwIFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0KICBb
ICAgMTQuNzI5OTg3XSBidXM6IDAwIFttZW0gMHgyNTAwMDAwMDAtMHhmY2ZmZmZmZmZmXQ0K
ICBbICAgMTQuNzQ0ODUyXSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZA0KICBbICAg
MTQuNzU3Nzc3XSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBh
dCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkNCiAgWyAg
IDE0Ljc4NTM3OV0gUENJOiBub3QgdXNpbmcgTU1DT05GSUcNCiAgWyAgIDE0Ljc5NjAzNV0g
UENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MNCiAgWyAg
IDE0LjgxMjk0Ml0gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgZXh0ZW5k
ZWQgYWNjZXNzDQogIFsgICAxNC44NzU5NzhdIGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBh
dCAwDQogIFsgICAxNC44ODgzNDRdIEFDUEk6IEFkZGVkIF9PU0koTW9kdWxlIERldmljZSkN
CiAgWyAgIDE0LjkwMDYwNV0gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgRGV2aWNlKQ0K
ICBbICAgMTQuOTE0MTIyXSBBQ1BJOiBBZGRlZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMp
DQogIFsgICAxNC45Mjg0MjddIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIEFnZ3JlZ2F0
b3IgRGV2aWNlKQ0KICBbICAgMTQuOTQ4MTI5XSBBQ1BJOiBFQzogTG9vayB1cCBFQyBpbiBE
U0RUDQogIFsgICAxNC45NjMyMjVdIEFDUEk6IEV4ZWN1dGVkIDMgYmxvY2tzIG9mIG1vZHVs
ZS1sZXZlbCBleGVjdXRhYmxlIEFNTCBjb2RlDQogIFsgICAxNC45ODcyNDJdIEFDUEk6IElu
dGVycHJldGVyIGVuYWJsZWQNCiAgWyAgIDE0Ljk5Nzk0N10gQUNQSTogKHN1cHBvcnRzIFMw
IFM1KQ0KICBbICAgMTUuMDA4MzM1XSBBQ1BJOiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVw
dCByb3V0aW5nDQogIFsgICAxNS4wMjM0NTRdIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAw
MDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAw
eGUwMDAwMDAwKQ0KICBbICAgMTUuMDUzMDc5XSBQQ0k6IE1NQ09ORklHIGF0IFttZW0gMHhl
MDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZlZCBpbiBBQ1BJIG1vdGhlcmJvYXJkIHJlc291
cmNlcw0KICBbICAgMTUuMTE1MTA0XSBQQ0k6IFVzaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3Mg
ZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3JzIiBhbmQgcmVwb3J0IGEg
YnVnDQogIFsgICAxNS4xODA1ODJdIEFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJMF0gKGRv
bWFpbiAwMDAwIFtidXMgMDAtZmZdKQ0KICBbICAgMTUuMTk5MTAwXSBhY3BpIFBOUDBBMDM6
MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpDQogIFsgICAxNS4yMTcy
MTNdIGFjcGkgUE5QMEEwMzowMDogQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpIGdyYW50ZWQN
CiAgWyAgIDE1LjIzNDg1Nl0gUENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQogIFsg
ICAxNS4yNDY5MzBdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2J1cyAw
MC1mZl0NCiAgWyAgIDE1LjI2MzU3N10gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNv
dXJjZSBbaW8gIDB4MDAwMC0weDBjZjddDQogIFsgICAxNS4yODIyODRdIHBjaV9idXMgMDAw
MDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQ0KICBbICAgMTUu
MzAxMDExXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBh
MDAwMC0weDAwMGJmZmZmXQ0KICBbICAgMTUuMzIxODAxXSBwY2lfYnVzIDAwMDA6MDA6IHJv
b3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXQ0KICBbICAgMTUu
MzQyNjEwXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhiMDAw
MDAwMC0weGRmZmZmZmZmXQ0KICBbICAgMTUuMzYzNDA1XSBwY2lfYnVzIDAwMDA6MDA6IHJv
b3QgYnVzIHJlc291cmNlIFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0KICBbICAgMTUu
Mzg0MjE2XSBwY2lfYnVzIDAwMDA6MDA6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTUuMzk2NDU5
XSBwY2kgMDAwMDowMDowMC4wOiBbMTAwMjo1YTExXSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAw
DQogIFsgICAxNS40MTQ2MjFdIHBjaSAwMDAwOjAwOjAwLjA6IGNhbGxpbmcgcXVpcmtfbW1p
b19hbHdheXNfb24rMHgwLzB4MTANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMA0KIFsgICAxNS40NDg2MjJdIHBjaSAwMDAwOjAw
OjAwLjI6IFsxMDAyOjVhMjNdIHR5cGUgMDAgY2xhc3MgMHgwODA2MDANCiAgKFhFTikgWzIw
MTMtMDItMjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMg0KIFsgICAx
NS40ODE2MDldIHBjaSAwMDAwOjAwOjAyLjA6IFsxMDAyOjVhMTZdIHR5cGUgMDEgY2xhc3Mg
MHgwNjA0MDANCiAgWyAgIDE1LjQ5OTcyNV0gcGNpIDAwMDA6MDA6MDIuMDogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE1LjUxODEyNl0gcGNpIDAwMDA6
MDA6MDIuMDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTUuNTMwODgwXSBwY2kgMDAwMDowMDow
Mi4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMA0KIFsgICAxNS41NjI5
OTddIHBjaSAwMDAwOjAwOjAzLjA6IFsxMDAyOjVhMTddIHR5cGUgMDEgY2xhc3MgMHgwNjA0
MDANCiAgWyAgIDE1LjU4MTEzMV0gcGNpIDAwMDA6MDA6MDMuMDogUE1FIyBzdXBwb3J0ZWQg
ZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE1LjU5OTUwOV0gcGNpIDAwMDA6MDA6MDMu
MDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTUuNjEyMjgxXSBwY2kgMDAwMDowMDowMy4wOiBT
eXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6
MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDMuMA0KIFsgICAxNS42NDQzODVdIHBj
aSAwMDAwOjAwOjA1LjA6IFsxMDAyOjVhMTldIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAg
WyAgIDE1LjY2MjUwNF0gcGNpIDAwMDA6MDA6MDUuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE
MCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE1LjY4MDg4NF0gcGNpIDAwMDA6MDA6MDUuMDogUE1F
IyBkaXNhYmxlZA0KICBbICAgMTUuNjkzNjYxXSBwY2kgMDAwMDowMDowNS4wOiBTeXN0ZW0g
d2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDdd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDUuMA0KIFsgICAxNS43MjU3NDVdIHBjaSAwMDAw
OjAwOjA2LjA6IFsxMDAyOjVhMWFdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1
Ljc0Mzg4MF0gcGNpIDAwMDA6MDA6MDYuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQNCiAgWyAgIDE1Ljc2MjI1OF0gcGNpIDAwMDA6MDA6MDYuMDogUE1FIyBkaXNh
YmxlZA0KICBbICAgMTUuNzc1MDM5XSBwY2kgMDAwMDowMDowNi4wOiBTeXN0ZW0gd2FrZXVw
IGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MDYuMA0KIFsgICAxNS44MDcxMzddIHBjaSAwMDAwOjAwOjA5
LjA6IFsxMDAyOjVhMWNdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1LjgyNTI1
NF0gcGNpIDAwMDA6MDA6MDkuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2Nv
bGQNCiAgWyAgIDE1Ljg0MzYzM10gcGNpIDAwMDA6MDA6MDkuMDogUE1FIyBkaXNhYmxlZA0K
ICBbICAgMTUuODU2NDIzXSBwY2kgMDAwMDowMDowOS4wOiBTeXN0ZW0gd2FrZXVwIGRpc2Fi
bGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MDkuMA0KIFsgICAxNS44ODg0OTVdIHBjaSAwMDAwOjAwOjBhLjA6IFsx
MDAyOjVhMWRdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1LjkwNjYyOV0gcGNp
IDAwMDA6MDA6MGEuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAg
WyAgIDE1LjkyNTAwOV0gcGNpIDAwMDA6MDA6MGEuMDogUE1FIyBkaXNhYmxlZA0KICBbICAg
MTUuOTM3ODAxXSBwY2kgMDAwMDowMDowYS4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5
IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MGEuMA0KIFsgICAxNS45NzAwMDldIHBjaSAwMDAwOjAwOjBiLjA6IFsxMDAyOjVh
MWZdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1Ljk4ODAxMl0gcGNpIDAwMDA6
MDA6MGIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE2
LjAwNjM5MF0gcGNpIDAwMDA6MDA6MGIuMDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTYuMDE5
MTgyXSBwY2kgMDAwMDowMDowYi4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MGIuMA0KIFsgICAxNi4wNTEyNjddIHBjaSAwMDAwOjAwOjBkLjA6IFsxMDAyOjVhMWVdIHR5
cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE2LjA2OTM3OV0gcGNpIDAwMDA6MDA6MGQu
MDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE2LjA4Nzc1
OF0gcGNpIDAwMDA6MDA6MGQuMDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTYuMTAwNTU3XSBw
Y2kgMDAwMDowMDowZC4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhF
TikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGQuMA0K
IFsgICAxNi4xMzI2NTNdIHBjaSAwMDAwOjAwOjExLjA6IFsxMDAyOjQzOTBdIHR5cGUgMDAg
Y2xhc3MgMHgwMTAxOGYNCiAgWyAgIDE2LjE1MDY3OV0gcGNpIDAwMDA6MDA6MTEuMDogY2Fs
bGluZyBxdWlya19ub19hdGFfZDMrMHgwLzB4MTANCiAgWyAgIDE2LjE2ODM2NV0gcGNpIDAw
MDA6MDA6MTEuMDogcmVnIDEwOiBbaW8gIDB4NzAwMC0weDcwMDddDQogIFsgICAxNi4xODQ3
MzNdIHBjaSAwMDAwOjAwOjExLjA6IHJlZyAxNDogW2lvICAweDYwMDAtMHg2MDAzXQ0KICBb
ICAgMTYuMjAxMTE2XSBwY2kgMDAwMDowMDoxMS4wOiByZWcgMTg6IFtpbyAgMHg1MDAwLTB4
NTAwN10NCiAgWyAgIDE2LjIxNzQ5MV0gcGNpIDAwMDA6MDA6MTEuMDogcmVnIDFjOiBbaW8g
IDB4MzAwMC0weDMwMDNdDQogIFsgICAxNi4yMzM4NjhdIHBjaSAwMDAwOjAwOjExLjA6IHJl
ZyAyMDogW2lvICAweDIwMDAtMHgyMDBmXQ0KICBbICAgMTYuMjUwMjQ5XSBwY2kgMDAwMDow
MDoxMS4wOiByZWcgMjQ6IFttZW0gMHhmOTZmZjAwMC0weGY5NmZmM2ZmXQ0KICBbICAgMTYu
MjY4NzE0XSBwY2kgMDAwMDowMDoxMS4wOiBjYWxsaW5nIHF1aXJrX2FtZF9pZGVfbW9kZSsw
eDAvMHhlMA0KICBbICAgMTYuMjg3MTYzXSBwY2kgMDAwMDowMDoxMS4wOiBzZXQgU0FUQSB0
byBBSENJIG1vZGUNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTEuMA0KIFsgICAxNi4zMTY5NDRdIHBjaSAwMDAwOjAwOjEyLjA6IFsx
MDAyOjQzOTddIHR5cGUgMDAgY2xhc3MgMHgwYzAzMTANCiAgWyAgIDE2LjMzNTAxMl0gcGNp
IDAwMDA6MDA6MTIuMDogcmVnIDEwOiBbbWVtIDB4Zjk2ZmIwMDAtMHhmOTZmYmZmZl0NCiAg
WyAgIDE2LjM1MzYwN10gcGNpIDAwMDA6MDA6MTIuMDogU3lzdGVtIHdha2V1cCBkaXNhYmxl
ZCBieSBBQ1BJDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA4XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjEyLjANCiBbICAgMTYuMzg1NTkyXSBwY2kgMDAwMDowMDoxMi4yOiBbMTAw
Mjo0Mzk2XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzIwDQogIFsgICAxNi40MDM2NTNdIHBjaSAw
MDAwOjAwOjEyLjI6IHJlZyAxMDogW21lbSAweGY5NmZmNDAwLTB4Zjk2ZmY0ZmZdDQogIFsg
ICAxNi40MjIyMTJdIHBjaSAwMDAwOjAwOjEyLjI6IHN1cHBvcnRzIEQxIEQyDQogIFsgICAx
Ni40MzUwODVdIHBjaSAwMDAwOjAwOjEyLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEg
RDIgRDNob3QNCiAgWyAgIDE2LjQ1MzI5NV0gcGNpIDAwMDA6MDA6MTIuMjogUE1FIyBkaXNh
YmxlZA0KICBbICAgMTYuNDY2MTAzXSBwY2kgMDAwMDowMDoxMi4yOiBTeXN0ZW0gd2FrZXVw
IGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTIuMg0KIFsgICAxNi40OTgxNzJdIHBjaSAwMDAwOjAwOjEz
LjA6IFsxMDAyOjQzOTddIHR5cGUgMDAgY2xhc3MgMHgwYzAzMTANCiAgWyAgIDE2LjUxNjIx
OF0gcGNpIDAwMDA6MDA6MTMuMDogcmVnIDEwOiBbbWVtIDB4Zjk2ZmMwMDAtMHhmOTZmY2Zm
Zl0NCiAgWyAgIDE2LjUzNDgyMl0gcGNpIDAwMDA6MDA6MTMuMDogU3lzdGVtIHdha2V1cCBk
aXNhYmxlZCBieSBBQ1BJDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA4XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjEzLjANCiBbICAgMTYuNTY2ODMyXSBwY2kgMDAwMDowMDoxMy4y
OiBbMTAwMjo0Mzk2XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzIwDQogIFsgICAxNi41ODQ4OTVd
IHBjaSAwMDAwOjAwOjEzLjI6IHJlZyAxMDogW21lbSAweGY5NmZmODAwLTB4Zjk2ZmY4ZmZd
DQogIFsgICAxNi42MDM0NTNdIHBjaSAwMDAwOjAwOjEzLjI6IHN1cHBvcnRzIEQxIEQyDQog
IFsgICAxNi42MTYzMjddIHBjaSAwMDAwOjAwOjEzLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20g
RDAgRDEgRDIgRDNob3QNCiAgWyAgIDE2LjYzNDUzNV0gcGNpIDAwMDA6MDA6MTMuMjogUE1F
IyBkaXNhYmxlZA0KICBbICAgMTYuNjQ3MzQ5XSBwY2kgMDAwMDowMDoxMy4yOiBTeXN0ZW0g
d2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMuMg0KIFsgICAxNi42Nzk0MTNdIHBjaSAwMDAw
OjAwOjE0LjA6IFsxMDAyOjQzODVdIHR5cGUgMDAgY2xhc3MgMHgwYzA1MDANCiAgWyAgIDE2
LjY5NzQ0N10gcGNpIDAwMDA6MDA6MTQuMDogY2FsbGluZyBzYjYwMF9kaXNhYmxlX2hwZXRf
YmFyKzB4MC8weDUwDQogIFsgICAxNi43MTcwMzRdIHBjaSAwMDAwOjAwOjE0LjA6IGNhbGxp
bmcgZm9yY2VfZGlzYWJsZV9ocGV0X21zaSsweDAvMHgxMA0KICAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMDowOF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wDQogWyAgIDE2Ljc1MTQw
MV0gcGNpIDAwMDA6MDA6MTQuMTogWzEwMDI6NDM5Y10gdHlwZSAwMCBjbGFzcyAweDAxMDE4
YQ0KICBbICAgMTYuNzY5NDYwXSBwY2kgMDAwMDowMDoxNC4xOiBjYWxsaW5nIHF1aXJrX25v
X2F0YV9kMysweDAvMHgxMA0KICBbICAgMTYuNzg3MTU5XSBwY2kgMDAwMDowMDoxNC4xOiBy
ZWcgMTA6IFtpbyAgMHgwMDAwLTB4MDAwN10NCiAgWyAgIDE2LjgwMzUyN10gcGNpIDAwMDA6
MDA6MTQuMTogcmVnIDE0OiBbaW8gIDB4MDAwMC0weDAwMDNdDQogIFsgICAxNi44MTk5MTRd
IHBjaSAwMDAwOjAwOjE0LjE6IHJlZyAxODogW2lvICAweDAwMDAtMHgwMDA3XQ0KICBbICAg
MTYuODM2Mjg0XSBwY2kgMDAwMDowMDoxNC4xOiByZWcgMWM6IFtpbyAgMHgwMDAwLTB4MDAw
M10NCiAgWyAgIDE2Ljg1MjY2M10gcGNpIDAwMDA6MDA6MTQuMTogcmVnIDIwOiBbaW8gIDB4
ZmYwMC0weGZmMGZdDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA4XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE0LjENCiBbICAgMTYuODg0MDA3XSBwY2kgMDAwMDowMDoxNC4zOiBb
MTAwMjo0MzlkXSB0eXBlIDAwIGNsYXNzIDB4MDYwMTAwDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIwOjA4XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMNCiBbICAgMTYuOTE3MDEz
XSBwY2kgMDAwMDowMDoxNC40OiBbMTAwMjo0Mzg0XSB0eXBlIDAxIGNsYXNzIDB4MDYwNDAx
DQogIFsgICAxNi45MzUxODRdIHBjaSAwMDAwOjAwOjE0LjQ6IFN5c3RlbSB3YWtldXAgZGlz
YWJsZWQgYnkgQUNQSQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDowOF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxNC40DQogWyAgIDE2Ljk2NzE5OF0gcGNpIDAwMDA6MDA6MTQuNTog
WzEwMDI6NDM5OV0gdHlwZSAwMCBjbGFzcyAweDBjMDMxMA0KICBbICAgMTYuOTg1MjY0XSBw
Y2kgMDAwMDowMDoxNC41OiByZWcgMTA6IFttZW0gMHhmOTZmZDAwMC0weGY5NmZkZmZmXQ0K
ICBbICAgMTcuMDAzODc4XSBwY2kgMDAwMDowMDoxNC41OiBTeXN0ZW0gd2FrZXVwIGRpc2Fi
bGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTQuNQ0KIFsgICAxNy4wMzU4NDZdIHBjaSAwMDAwOjAwOjE1LjA6IFsx
MDAyOjQzYTBdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE3LjA1Mzk5Nl0gcGNp
IDAwMDA6MDA6MTUuMDogc3VwcG9ydHMgRDEgRDINCiAgWyAgIDE3LjA2Njk5M10gcGNpIDAw
MDA6MDA6MTUuMDogU3lzdGVtIHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJDQogIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE1LjANCiBbICAg
MTcuMDk5MDI2XSBwY2kgMDAwMDowMDoxNi4wOiBbMTAwMjo0Mzk3XSB0eXBlIDAwIGNsYXNz
IDB4MGMwMzEwDQogIFsgICAxNy4xMTcwNzRdIHBjaSAwMDAwOjAwOjE2LjA6IHJlZyAxMDog
W21lbSAweGY5NmZlMDAwLTB4Zjk2ZmVmZmZdDQogIFsgICAxNy4xMzU2ODddIHBjaSAwMDAw
OjAwOjE2LjA6IFN5c3RlbSB3YWtldXAgZGlzYWJsZWQgYnkgQUNQSQ0KICAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMDowOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQogWyAgIDE3
LjE2NzY2OF0gcGNpIDAwMDA6MDA6MTYuMjogWzEwMDI6NDM5Nl0gdHlwZSAwMCBjbGFzcyAw
eDBjMDMyMA0KICBbICAgMTcuMTg1NzE4XSBwY2kgMDAwMDowMDoxNi4yOiByZWcgMTA6IFtt
ZW0gMHhmOTZmZmMwMC0weGY5NmZmY2ZmXQ0KICBbICAgMTcuMjA0Mjc3XSBwY2kgMDAwMDow
MDoxNi4yOiBzdXBwb3J0cyBEMSBEMg0KICBbICAgMTcuMjE3MTUwXSBwY2kgMDAwMDowMDox
Ni4yOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQogIFsgICAxNy4yMzUz
NTldIHBjaSAwMDAwOjAwOjE2LjI6IFBNRSMgZGlzYWJsZWQNCiAgWyAgIDE3LjI0ODE3OF0g
cGNpIDAwMDA6MDA6MTYuMjogU3lzdGVtIHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJDQogIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjIN
CiBbICAgMTcuMjgwMjQxXSBwY2kgMDAwMDowMDoxOC4wOiBbMTAyMjoxMjAwXSB0eXBlIDAw
IGNsYXNzIDB4MDYwMDAwDQogIFsgICAxNy4yOTgyNjddIHBjaSAwMDAwOjAwOjE4LjA6IGNh
bGxpbmcgcXVpcmtfbW1pb19hbHdheXNfb24rMHgwLzB4MTANCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMA0KIFsgICAxNy4zMzIy
MTNdIHBjaSAwMDAwOjAwOjE4LjE6IFsxMDIyOjEyMDFdIHR5cGUgMDAgY2xhc3MgMHgwNjAw
MDANCiAgWyAgIDE3LjM1MDI2NF0gcGNpIDAwMDA6MDA6MTguMTogY2FsbGluZyBxdWlya19t
bWlvX2Fsd2F5c19vbisweDAvMHgxMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDowOV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xDQogWyAgIDE3LjM4NDIxMl0gcGNpIDAwMDA6
MDA6MTguMjogWzEwMjI6MTIwMl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMA0KICBbICAgMTcu
NDAyMjcwXSBwY2kgMDAwMDowMDoxOC4yOiBjYWxsaW5nIHF1aXJrX21taW9fYWx3YXlzX29u
KzB4MC8weDEwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE4LjINCiBbICAgMTcuNDM2MTk5XSBwY2kgMDAwMDowMDoxOC4zOiBbMTAy
MjoxMjAzXSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwDQogIFsgICAxNy40NTQyNTldIHBjaSAw
MDAwOjAwOjE4LjM6IGNhbGxpbmcgcXVpcmtfbW1pb19hbHdheXNfb24rMHgwLzB4MTANCiAg
KFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTgu
Mw0KIFsgICAxNy40ODgyMDRdIHBjaSAwMDAwOjAwOjE4LjQ6IFsxMDIyOjEyMDRdIHR5cGUg
MDAgY2xhc3MgMHgwNjAwMDANCiAgWyAgIDE3LjUwNjI1Nl0gcGNpIDAwMDA6MDA6MTguNDog
Y2FsbGluZyBxdWlya19tbWlvX2Fsd2F5c19vbisweDAvMHgxMA0KICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMDowOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQogWyAgIDE3LjU0
MDM1Nl0gcGNpX2J1cyAwMDAwOjAwOiBmaXh1cHMgZm9yIGJ1cw0KICBbICAgMTcuNTUyODkz
XSBwY2kgMDAwMDowMDowMi4wOiBzY2FubmluZyBbYnVzIDBjLTBjXSBiZWhpbmQgYnJpZGdl
LCBwYXNzIDANCiAgWyAgIDE3LjU3MzMwOV0gcGNpX2J1cyAwMDAwOjBjOiBzY2FubmluZyBi
dXMNCiAgWyAgIDE3LjU4NTM0MV0gcGNpIDAwMDA6MGM6MDAuMDogWzEwZGU6MDZlNF0gdHlw
ZSAwMCBjbGFzcyAweDAzMDAwMA0KICBbICAgMTcuNjAzNTQ1XSBwY2kgMDAwMDowYzowMC4w
OiByZWcgMTA6IFttZW0gMHhmZDAwMDAwMC0weGZkZmZmZmZmXQ0KICBbICAgMTcuNjIxOTkz
XSBwY2kgMDAwMDowYzowMC4wOiByZWcgMTQ6IFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZm
IDY0Yml0IHByZWZdDQogIFsgICAxNy42NDMzMjBdIHBjaSAwMDAwOjBjOjAwLjA6IHJlZyAx
YzogW21lbSAweGZhMDAwMDAwLTB4ZmJmZmZmZmYgNjRiaXRdDQogIFsgICAxNy42NjMzMjZd
IHBjaSAwMDAwOjBjOjAwLjA6IHJlZyAyNDogW2lvICAweGU4MDAtMHhlODdmXQ0KICBbICAg
MTcuNjc5NzEyXSBwY2kgMDAwMDowYzowMC4wOiByZWcgMzA6IFttZW0gMHhmZTllMDAwMC0w
eGZlOWZmZmZmIHByZWZdDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjBjOjAwLjANCiBbICAgMTcuNzIxMTg5XSBwY2lfYnVzIDAwMDA6MGM6
IGZpeHVwcyBmb3IgYnVzDQogIFsgICAxNy43MzM0NDhdIHBjaSAwMDAwOjAwOjAyLjA6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwY10NCiAgWyAgIDE3Ljc0ODU0Ml0gcGNpIDAwMDA6MDA6MDIu
MDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0NCiAgWyAgIDE3Ljc2Njk4
Nl0gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAwMC0w
eGZlOWZmZmZmXQ0KICBbICAgMTcuNzg3NTM1XSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRn
ZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0NCiAgWyAg
IDE3LjgxMDkyMV0gcGNpX2J1cyAwMDAwOjBjOiBidXMgc2NhbiByZXR1cm5pbmcgd2l0aCBt
YXg9MGMNCiAgWyAgIDE3LjgyNzgyMl0gcGNpIDAwMDA6MDA6MDMuMDogc2Nhbm5pbmcgW2J1
cyAwYS0wYl0gYmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAxNy44NDgzMjZdIHBjaV9i
dXMgMDAwMDowYTogc2Nhbm5pbmcgYnVzDQogIFsgICAxNy44NjAzNDldIHBjaSAwMDAwOjBh
OjAwLjA6IFsxMDRjOjgyMzFdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE3Ljg3
ODY3NV0gcGNpIDAwMDA6MGE6MDAuMDogc3VwcG9ydHMgRDEgRDINCiAgKFhFTikgWzIwMTMt
MDItMjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMA0KIFsgICAxNy45
MDY0NzBdIHBjaSAwMDAwOjBhOjAwLjA6IGRpc2FibGluZyBBU1BNIG9uIHByZS0xLjEgUENJ
ZSBkZXZpY2UuICBZb3UgY2FuIGVuYWJsZSBpdCB3aXRoICdwY2llX2FzcG09Zm9yY2UnDQog
IFsgICAxNy45MzY1MDBdIHBjaV9idXMgMDAwMDowYTogZml4dXBzIGZvciBidXMNCiAgWyAg
IDE3Ljk0OTI0Ml0gcGNpIDAwMDA6MDA6MDMuMDogUENJIGJyaWRnZSB0byBbYnVzIDBhLTBi
XQ0KICBbICAgMTcuOTY1MDk3XSBwY2kgMDAwMDowMDowMy4wOiAgIGJyaWRnZSB3aW5kb3cg
W21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQogIFsgICAxNy45ODU2NDRdIHBjaSAwMDAw
OjBhOjAwLjA6IHNjYW5uaW5nIFtidXMgMGItMGJdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0K
ICBbICAgMTguMDA2MTU2XSBwY2lfYnVzIDAwMDA6MGI6IHNjYW5uaW5nIGJ1cw0KICBbICAg
MTguMDE4MTUxXSBwY2kgMDAwMDowYjowMS4wOiBbMTAzMzowMDM1XSB0eXBlIDAwIGNsYXNz
IDB4MGMwMzEwDQogIFsgICAxOC4wMzYzNjRdIHBjaSAwMDAwOjBiOjAxLjA6IHJlZyAxMDog
W21lbSAweGY5ZmZkMDAwLTB4ZjlmZmRmZmZdDQogIFsgICAxOC4wNTQ5MzNdIHBjaSAwMDAw
OjBiOjAxLjA6IHN1cHBvcnRzIEQxIEQyDQogIFsgICAxOC4wNjc3ODRdIHBjaSAwMDAwOjBi
OjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNCiAgWyAgIDE4LjA4
NTk5NV0gcGNpIDAwMDA6MGI6MDEuMDogUE1FIyBkaXNhYmxlZA0KICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMDoxMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMS4wDQogWyAgIDE4LjEx
MzcxOF0gcGNpIDAwMDA6MGI6MDEuMTogWzEwMzM6MDAzNV0gdHlwZSAwMCBjbGFzcyAweDBj
MDMxMA0KICBbICAgMTguMTMxNzczXSBwY2kgMDAwMDowYjowMS4xOiByZWcgMTA6IFttZW0g
MHhmOWZmZTAwMC0weGY5ZmZlZmZmXQ0KICBbICAgMTguMTUwMzU1XSBwY2kgMDAwMDowYjow
MS4xOiBzdXBwb3J0cyBEMSBEMg0KICBbICAgMTguMTYzMTk5XSBwY2kgMDAwMDowYjowMS4x
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQogIFsgICAxOC4xODE0MTBd
IHBjaSAwMDAwOjBiOjAxLjE6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDItMjcg
MTE6MjA6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGI6MDEuMQ0KIFsgICAxOC4yMDkxMzBd
IHBjaSAwMDAwOjBiOjAxLjI6IFsxMDMzOjAwZTBdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMjAN
CiAgWyAgIDE4LjIyNzE4NV0gcGNpIDAwMDA6MGI6MDEuMjogcmVnIDEwOiBbbWVtIDB4Zjlm
ZmZjMDAtMHhmOWZmZmNmZl0NCiAgWyAgIDE4LjI0NTc2OV0gcGNpIDAwMDA6MGI6MDEuMjog
c3VwcG9ydHMgRDEgRDINCiAgWyAgIDE4LjI1ODYxM10gcGNpIDAwMDA6MGI6MDEuMjogUE1F
IyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KICBbICAgMTguMjc2ODI3XSBwY2kg
MDAwMDowYjowMS4yOiBQTUUjIGRpc2FibGVkDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIw
OjEwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBiOjAxLjINCiBbICAgMTguMzA0NjE4XSBwY2lf
YnVzIDAwMDA6MGI6IGZpeHVwcyBmb3IgYnVzDQogIFsgICAxOC4zMTcxMTFdIHBjaSAwMDAw
OjBhOjAwLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwYl0NCiAgWyAgIDE4LjMzMjIwOF0gcGNp
IDAwMDA6MGE6MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWYwMDAwMC0weGY5ZmZm
ZmZmXQ0KICBbICAgMTguMzUyNzM5XSBwY2lfYnVzIDAwMDA6MGI6IGJ1cyBzY2FuIHJldHVy
bmluZyB3aXRoIG1heD0wYg0KICBbICAgMTguMzY5NjM4XSBwY2kgMDAwMDowYTowMC4wOiBz
Y2FubmluZyBbYnVzIDBiLTBiXSBiZWhpbmQgYnJpZGdlLCBwYXNzIDENCiAgWyAgIDE4LjM4
OTkxMV0gcGNpX2J1cyAwMDAwOjBhOiBidXMgc2NhbiByZXR1cm5pbmcgd2l0aCBtYXg9MGIN
CiAgWyAgIDE4LjQwNjgwN10gcGNpIDAwMDA6MDA6MDUuMDogc2Nhbm5pbmcgW2J1cyAwOS0w
OV0gYmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAxOC40MjcyODRdIHBjaV9idXMgMDAw
MDowOTogc2Nhbm5pbmcgYnVzDQogIFsgICAxOC40MzkzMjddIHBjaSAwMDAwOjA5OjAwLjA6
IFsxMGVjOjgxNjhdIHR5cGUgMDAgY2xhc3MgMHgwMjAwMDANCiAgWyAgIDE4LjQ1NzUyN10g
cGNpIDAwMDA6MDk6MDAuMDogcmVnIDEwOiBbaW8gIDB4ZDgwMC0weGQ4ZmZdDQogIFsgICAx
OC40NzM5MTFdIHBjaSAwMDAwOjA5OjAwLjA6IHJlZyAxODogW21lbSAweGNmZmZmMDAwLTB4
Y2ZmZmZmZmYgNjRiaXQgcHJlZl0NCiAgWyAgIDE4LjQ5NTIyNV0gcGNpIDAwMDA6MDk6MDAu
MDogcmVnIDIwOiBbbWVtIDB4Y2ZmZjgwMDAtMHhjZmZmYmZmZiA2NGJpdCBwcmVmXQ0KICBb
ICAgMTguNTE2NTMwXSBwY2kgMDAwMDowOTowMC4wOiByZWcgMzA6IFttZW0gMHhmOWVlMDAw
MC0weGY5ZWZmZmZmIHByZWZdDQogIFsgICAxOC41MzYzNTFdIHBjaSAwMDAwOjA5OjAwLjA6
IHN1cHBvcnRzIEQxIEQyDQogIFsgICAxOC41NDkyNzNdIHBjaSAwMDAwOjA5OjAwLjA6IFBN
RSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QgRDNjb2xkDQogIFsgICAxOC41Njkz
MzBdIHBjaSAwMDAwOjA5OjAwLjA6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDk6MDAuMA0KIFsgICAxOC42MDM4
ODNdIHBjaV9idXMgMDAwMDowOTogZml4dXBzIGZvciBidXMNCiAgWyAgIDE4LjYxNjEzOV0g
cGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5XQ0KICBbICAgMTguNjMx
MjMxXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhk
ZmZmXQ0KICBbICAgMTguNjQ5Njc4XSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGY5ZTAwMDAwLTB4ZjllZmZmZmZdDQogIFsgICAxOC42NzAyMTddIHBjaSAw
MDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZm
ZiA2NGJpdCBwcmVmXQ0KICBbICAgMTguNjkzNjExXSBwY2lfYnVzIDAwMDA6MDk6IGJ1cyBz
Y2FuIHJldHVybmluZyB3aXRoIG1heD0wOQ0KICBbICAgMTguNzEwNTEyXSBwY2kgMDAwMDow
MDowNi4wOiBzY2FubmluZyBbYnVzIDA4LTA4XSBiZWhpbmQgYnJpZGdlLCBwYXNzIDANCiAg
WyAgIDE4LjczMTAwN10gcGNpX2J1cyAwMDAwOjA4OiBzY2FubmluZyBidXMNCiAgWyAgIDE4
Ljc0MzAzNF0gcGNpIDAwMDA6MDg6MDAuMDogWzEwZWM6ODE2OF0gdHlwZSAwMCBjbGFzcyAw
eDAyMDAwMA0KICBbICAgMTguNzYxMjM2XSBwY2kgMDAwMDowODowMC4wOiByZWcgMTA6IFtp
byAgMHhjODAwLTB4YzhmZl0NCiAgWyAgIDE4Ljc3NzYxOV0gcGNpIDAwMDA6MDg6MDAuMDog
cmVnIDE4OiBbbWVtIDB4Y2ZlZmYwMDAtMHhjZmVmZmZmZiA2NGJpdCBwcmVmXQ0KICBbICAg
MTguNzk4OTMxXSBwY2kgMDAwMDowODowMC4wOiByZWcgMjA6IFttZW0gMHhjZmVmODAwMC0w
eGNmZWZiZmZmIDY0Yml0IHByZWZdDQogIFsgICAxOC44MjAyMzRdIHBjaSAwMDAwOjA4OjAw
LjA6IHJlZyAzMDogW21lbSAweGY5ZGUwMDAwLTB4ZjlkZmZmZmYgcHJlZl0NCiAgWyAgIDE4
Ljg0MDA2M10gcGNpIDAwMDA6MDg6MDAuMDogc3VwcG9ydHMgRDEgRDINCiAgWyAgIDE4Ljg1
Mjk4MF0gcGNpIDAwMDA6MDg6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBE
M2hvdCBEM2NvbGQNCiAgWyAgIDE4Ljg3MzAwM10gcGNpIDAwMDA6MDg6MDAuMDogUE1FIyBk
aXNhYmxlZA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowODowMC4wDQogWyAgIDE4LjkwNzU2N10gcGNpX2J1cyAwMDAwOjA4OiBmaXh1cHMg
Zm9yIGJ1cw0KICBbICAgMTguOTE5ODI3XSBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDhdDQogIFsgICAxOC45MzQ5MTddIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNmZmZdDQogIFsgICAxOC45NTMzNjVdIHBjaSAw
MDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjlkMDAwMDAtMHhmOWRmZmZm
Zl0NCiAgWyAgIDE4Ljk3MzkwNV0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhjZmUwMDAwMC0weGNmZWZmZmZmIDY0Yml0IHByZWZdDQogIFsgICAxOC45OTcy
OTZdIHBjaV9idXMgMDAwMDowODogYnVzIHNjYW4gcmV0dXJuaW5nIHdpdGggbWF4PTA4DQog
IFsgICAxOS4wMTQyMDBdIHBjaSAwMDAwOjAwOjA5LjA6IHNjYW5uaW5nIFtidXMgMDctMDdd
IGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuMDM0Njg3XSBwY2lfYnVzIDAwMDA6
MDc6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuMDQ2NzIzXSBwY2kgMDAwMDowNzowMC4wOiBb
MTAzMzowMTk0XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzMwDQogIFsgICAxOS4wNjQ5MjddIHBj
aSAwMDAwOjA3OjAwLjA6IHJlZyAxMDogW21lbSAweGY5Y2ZlMDAwLTB4ZjljZmZmZmYgNjRi
aXRdDQogIFsgICAxOS4wODUwNDNdIHBjaSAwMDAwOjA3OjAwLjA6IFBNRSMgc3VwcG9ydGVk
IGZyb20gRDAgRDNob3QgRDNjb2xkDQogIFsgICAxOS4xMDMzODRdIHBjaSAwMDAwOjA3OjAw
LjA6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MTFdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDc6MDAuMA0KIFsgICAxOS4xMzc4MTFdIHBjaV9idXMgMDAwMDow
NzogZml4dXBzIGZvciBidXMNCiAgWyAgIDE5LjE1MDA2OF0gcGNpIDAwMDA6MDA6MDkuMDog
UENJIGJyaWRnZSB0byBbYnVzIDA3XQ0KICBbICAgMTkuMTY1MTYxXSBwY2kgMDAwMDowMDow
OS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YzAwMDAwLTB4ZjljZmZmZmZdDQogIFsg
ICAxOS4xODU2ODldIHBjaV9idXMgMDAwMDowNzogYnVzIHNjYW4gcmV0dXJuaW5nIHdpdGgg
bWF4PTA3DQogIFsgICAxOS4yMDI1ODVdIHBjaSAwMDAwOjAwOjBhLjA6IHNjYW5uaW5nIFti
dXMgMDYtMDZdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuMjIzMDc0XSBwY2lf
YnVzIDAwMDA6MDY6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuMjM1MTAyXSBwY2kgMDAwMDow
NjowMC4wOiBbMTRmMTo4MjEwXSB0eXBlIDAwIGNsYXNzIDB4MDQwMDAwDQogIFsgICAxOS4y
NTMzMTldIHBjaSAwMDAwOjA2OjAwLjA6IHJlZyAxMDogW21lbSAweGY5YTAwMDAwLTB4Zjli
ZmZmZmYgNjRiaXRdDQogIFsgICAxOS4yNzM0NjVdIHBjaSAwMDAwOjA2OjAwLjA6IHN1cHBv
cnRzIEQxIEQyDQogIFsgICAxOS4yODYzMDVdIHBjaSAwMDAwOjA2OjAwLjA6IFBNRSMgc3Vw
cG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNCiAgWyAgIDE5LjMwNDUwMl0gcGNpIDAwMDA6
MDY6MDAuMDogUE1FIyBkaXNhYmxlZA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wDQogWyAgIDE5LjMzOTA1NV0gcGNpX2J1cyAw
MDAwOjA2OiBmaXh1cHMgZm9yIGJ1cw0KICBbICAgMTkuMzUxMzIwXSBwY2kgMDAwMDowMDow
YS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDZdDQogIFsgICAxOS4zNjY0MTldIHBjaSAwMDAw
OjAwOjBhLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjlhMDAwMDAtMHhmOWJmZmZmZl0N
CiAgWyAgIDE5LjM4Njk0MV0gcGNpX2J1cyAwMDAwOjA2OiBidXMgc2NhbiByZXR1cm5pbmcg
d2l0aCBtYXg9MDYNCiAgWyAgIDE5LjQwMzgzOV0gcGNpIDAwMDA6MDA6MGIuMDogc2Nhbm5p
bmcgW2J1cyAwNS0wNV0gYmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAxOS40MjQzMjdd
IHBjaV9idXMgMDAwMDowNTogc2Nhbm5pbmcgYnVzDQogIFsgICAxOS40MzYzNTRdIHBjaSAw
MDAwOjA1OjAwLjA6IFsxMDAyOjY3NTldIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDANCiAgWyAg
IDE5LjQ1NDU2NF0gcGNpIDAwMDA6MDU6MDAuMDogcmVnIDEwOiBbbWVtIDB4YjAwMDAwMDAt
MHhiZmZmZmZmZiA2NGJpdCBwcmVmXQ0KICBbICAgMTkuNDc1ODcxXSBwY2kgMDAwMDowNTow
MC4wOiByZWcgMTg6IFttZW0gMHhmOTljMDAwMC0weGY5OWRmZmZmIDY0Yml0XQ0KICBbICAg
MTkuNDk1ODkwXSBwY2kgMDAwMDowNTowMC4wOiByZWcgMjA6IFtpbyAgMHhiMDAwLTB4YjBm
Zl0NCiAgWyAgIDE5LjUxMjI3M10gcGNpIDAwMDA6MDU6MDAuMDogcmVnIDMwOiBbbWVtIDB4
Zjk5YTAwMDAtMHhmOTliZmZmZiBwcmVmXQ0KICBbICAgMTkuNTMyMDY4XSBwY2kgMDAwMDow
NTowMC4wOiBzdXBwb3J0cyBEMSBEMg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQogWyAgIDE5LjU2MDE3NF0gcGNpIDAwMDA6
MDU6MDAuMTogWzEwMDI6YWE5MF0gdHlwZSAwMCBjbGFzcyAweDA0MDMwMA0KICBbICAgMTku
NTc4MDg2XSBwY2kgMDAwMDowNTowMC4xOiByZWcgMTA6IFttZW0gMHhmOTlmYzAwMC0weGY5
OWZmZmZmIDY0Yml0XQ0KICBbICAgMTkuNTk4MjAzXSBwY2kgMDAwMDowNTowMC4xOiBzdXBw
b3J0cyBEMSBEMg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMV0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNTowMC4xDQogWyAgIDE5LjYzMjg5M10gcGNpX2J1cyAwMDAwOjA1OiBmaXh1
cHMgZm9yIGJ1cw0KICBbICAgMTkuNjQ1MTQ4XSBwY2kgMDAwMDowMDowYi4wOiBQQ0kgYnJp
ZGdlIHRvIFtidXMgMDVdDQogIFsgICAxOS42NjAyMzldIHBjaSAwMDAwOjAwOjBiLjA6ICAg
YnJpZGdlIHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZdDQogIFsgICAxOS42Nzg2ODddIHBj
aSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Zjk5MDAwMDAtMHhmOTlm
ZmZmZl0NCiAgWyAgIDE5LjY5OTIyNl0gcGNpIDAwMDA6MDA6MGIuMDogICBicmlkZ2Ugd2lu
ZG93IFttZW0gMHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQogIFsgICAxOS43
MjI2MjFdIHBjaV9idXMgMDAwMDowNTogYnVzIHNjYW4gcmV0dXJuaW5nIHdpdGggbWF4PTA1
DQogIFsgICAxOS43Mzk1MjFdIHBjaSAwMDAwOjAwOjBkLjA6IHNjYW5uaW5nIFtidXMgMDQt
MDRdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuNzYwMDA4XSBwY2lfYnVzIDAw
MDA6MDQ6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuNzcyMDUwXSBwY2kgMDAwMDowNDowMC4w
OiBbMTAzMzowMTk0XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzMwDQogIFsgICAxOS43OTAyNDhd
IHBjaSAwMDAwOjA0OjAwLjA6IHJlZyAxMDogW21lbSAweGY5OGZlMDAwLTB4Zjk4ZmZmZmYg
NjRiaXRdDQogIFsgICAxOS44MTAzNjNdIHBjaSAwMDAwOjA0OjAwLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQogIFsgICAxOS44Mjg3MDddIHBjaSAwMDAwOjA0
OjAwLjA6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MTFdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMA0KIFsgICAxOS44NjMyNTFdIHBjaV9idXMgMDAw
MDowNDogZml4dXBzIGZvciBidXMNCiAgWyAgIDE5Ljg3NTUyMl0gcGNpIDAwMDA6MDA6MGQu
MDogUENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KICBbICAgMTkuODkwNjEzXSBwY2kgMDAwMDow
MDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5ODAwMDAwLTB4Zjk4ZmZmZmZdDQog
IFsgICAxOS45MTExNDJdIHBjaV9idXMgMDAwMDowNDogYnVzIHNjYW4gcmV0dXJuaW5nIHdp
dGggbWF4PTA0DQogIFsgICAxOS45MjgwMzhdIHBjaSAwMDAwOjAwOjE0LjQ6IHNjYW5uaW5n
IFtidXMgMDMtMDNdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuOTQ4NDg3XSBw
Y2lfYnVzIDAwMDA6MDM6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuOTYwNTY1XSBwY2kgMDAw
MDowMzowNi4wOiBbMTNmNjowMTExXSB0eXBlIDAwIGNsYXNzIDB4MDQwMTAwDQogIFsgICAx
OS45Nzg3NjhdIHBjaSAwMDAwOjAzOjA2LjA6IHJlZyAxMDogW2lvICAweGE4MDAtMHhhOGZm
XQ0KICBbICAgMTkuOTk1MjQ1XSBwY2kgMDAwMDowMzowNi4wOiBzdXBwb3J0cyBEMSBEMg0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzow
Ni4wDQogWyAgIDIwLjAyMzE1MF0gcGNpX2J1cyAwMDAwOjAzOiBmaXh1cHMgZm9yIGJ1cw0K
ICBbICAgMjAuMDM1NjcxXSBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDNdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQogIFsgICAyMC4wNTYyMjhdIHBjaSAwMDAwOjAw
OjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YTAwMC0weGFmZmZdDQogIFsgICAyMC4w
NzQ2NzRdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0w
eDBjZjddIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQogIFsgICAyMC4wOTg1OTRdIHBjaSAwMDAw
OjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdIChzdWJ0cmFj
dGl2ZSBkZWNvZGUpDQogIFsgICAyMC4xMjI1MDJdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJp
ZGdlIHdpbmRvdyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0gKHN1YnRyYWN0aXZlIGRl
Y29kZSkNCiAgWyAgIDIwLjE0ODQ5OV0gcGNpIDAwMDA6MDA6MTQuNDogICBicmlkZ2Ugd2lu
ZG93IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQ0K
ICBbICAgMjAuMTc0NDk4XSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5kb3cgW21l
bSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQogIFsgICAy
MC4yMDA0OTZdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjAw
MDAwMDAtMHhmZWJmZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkNCiAgWyAgIDIwLjIyNjQ5
NF0gcGNpX2J1cyAwMDAwOjAzOiBidXMgc2NhbiByZXR1cm5pbmcgd2l0aCBtYXg9MDMNCiAg
WyAgIDIwLjI0MzM5OF0gcGNpIDAwMDA6MDA6MTUuMDogc2Nhbm5pbmcgW2J1cyAwMi0wMl0g
YmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAyMC4yNjM4OTFdIHBjaV9idXMgMDAwMDow
Mjogc2Nhbm5pbmcgYnVzDQogIFsgICAyMC4yNzU4OTZdIHBjaV9idXMgMDAwMDowMjogZml4
dXBzIGZvciBidXMNCiAgWyAgIDIwLjI4ODY0MF0gcGNpIDAwMDA6MDA6MTUuMDogUENJIGJy
aWRnZSB0byBbYnVzIDAyXQ0KICBbICAgMjAuMzAzNzI3XSBwY2lfYnVzIDAwMDA6MDI6IGJ1
cyBzY2FuIHJldHVybmluZyB3aXRoIG1heD0wMg0KICBbICAgMjAuMzIwNjE0XSBwY2kgMDAw
MDowMDowMi4wOiBzY2FubmluZyBbYnVzIDBjLTBjXSBiZWhpbmQgYnJpZGdlLCBwYXNzIDEN
CiAgWyAgIDIwLjM0MDkwMV0gcGNpIDAwMDA6MDA6MDMuMDogc2Nhbm5pbmcgW2J1cyAwYS0w
Yl0gYmVoaW5kIGJyaWRnZSwgcGFzcyAxDQogIFsgICAyMC4zNjExNzNdIHBjaSAwMDAwOjAw
OjA1LjA6IHNjYW5uaW5nIFtidXMgMDktMDldIGJlaGluZCBicmlkZ2UsIHBhc3MgMQ0KICBb
ICAgMjAuMzgxNDUwXSBwY2kgMDAwMDowMDowNi4wOiBzY2FubmluZyBbYnVzIDA4LTA4XSBi
ZWhpbmQgYnJpZGdlLCBwYXNzIDENCiAgWyAgIDIwLjQwMTcyOF0gcGNpIDAwMDA6MDA6MDku
MDogc2Nhbm5pbmcgW2J1cyAwNy0wN10gYmVoaW5kIGJyaWRnZSwgcGFzcyAxDQogIFsgICAy
MC40MjIwMDldIHBjaSAwMDAwOjAwOjBhLjA6IHNjYW5uaW5nIFtidXMgMDYtMDZdIGJlaGlu
ZCBicmlkZ2UsIHBhc3MgMQ0KICBbICAgMjAuNDQyMjg3XSBwY2kgMDAwMDowMDowYi4wOiBz
Y2FubmluZyBbYnVzIDA1LTA1XSBiZWhpbmQgYnJpZGdlLCBwYXNzIDENCiAgWyAgIDIwLjQ2
MjU2Nl0gcGNpIDAwMDA6MDA6MGQuMDogc2Nhbm5pbmcgW2J1cyAwNC0wNF0gYmVoaW5kIGJy
aWRnZSwgcGFzcyAxDQogIFsgICAyMC40ODI4NDRdIHBjaSAwMDAwOjAwOjE0LjQ6IHNjYW5u
aW5nIFtidXMgMDMtMDNdIGJlaGluZCBicmlkZ2UsIHBhc3MgMQ0KICBbICAgMjAuNTAzMTI2
XSBwY2kgMDAwMDowMDoxNS4wOiBzY2FubmluZyBbYnVzIDAyLTAyXSBiZWhpbmQgYnJpZGdl
LCBwYXNzIDENCiAgWyAgIDIwLjUyMzQwMl0gcGNpX2J1cyAwMDAwOjAwOiBidXMgc2NhbiBy
ZXR1cm5pbmcgd2l0aCBtYXg9MGMNCiAgWyAgIDIwLjU0MjU5NV0gQUNQSTogUENJIEludGVy
cnVwdCBMaW5rIFtMTktBXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQ0KICBbICAgMjAuNTYx
MjIxXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDQgNyAxMCAqMTEg
MTQgMTUpDQogIFsgICAyMC41ODAyMDVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L
Q10gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkNCiAgWyAgIDIwLjU5OTE4NV0gQUNQSTogUENJ
IEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQ0KICBbICAg
MjAuNjE4MTQzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFzIDQgKjcg
MTAgMTEgMTQgMTUpDQogIFsgICAyMC42MzcxMDVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGlu
ayBbTE5LRl0gKElSUXMgNCA3IDEwICoxMSAxNCAxNSkNCiAgWyAgIDIwLjY1NjA4NF0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktHXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQ0K
ICBbICAgMjAuNjc1MDY3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFz
IDQgNyAqMTAgMTEgMTQgMTUpDQogIFsgICAyMC42OTQ5MTFdIGFjcGkgcm9vdDogXF9TQl8u
UENJMCBub3RpZnkgaGFuZGxlciBpcyBpbnN0YWxsZWQNCiAgWyAgIDIwLjcxMTk3OV0gRm91
bmQgMSBhY3BpIHJvb3QgZGV2aWNlcw0KICBbICAgMjAuNzIzNDgyXSB4ZW4vYmFsbG9vbjog
SW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyLg0KICBbICAgMjAuNzM4OTA0XSB4ZW4tYmFs
bG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyLg0KICBbICAgMjAuNzU0NDkzXSB2
Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MGM6MDAuMCxkZWNvZGVzPWlvK21lbSxv
d25zPWlvK21lbSxsb2Nrcz1ub25lDQogIFsgICAyMC43Nzg0NjhdIHZnYWFyYjogZGV2aWNl
IGFkZGVkOiBQQ0k6MDAwMDowNTowMC4wLGRlY29kZXM9aW8rbWVtLG93bnM9bm9uZSxsb2Nr
cz1ub25lDQogIFsgICAyMC44MDIzODddIHZnYWFyYjogbG9hZGVkDQogIFsgICAyMC44MTA2
OTBdIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowNTowMC4wDQogIFsg
ICAyMC44MjY4MTddIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowYzow
MC4wDQogIFsgICAyMC44NDMzNDJdIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkDQogIFsg
ICAyMC44NTQzNzBdIEFDUEk6IGJ1cyB0eXBlIHNjc2kgcmVnaXN0ZXJlZA0KICBbICAgMjAu
ODY3NDc1XSBsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4NCiAgWyAgIDIwLjg3OTMwNl0g
QUNQSTogYnVzIHR5cGUgdXNiIHJlZ2lzdGVyZWQNCiAgWyAgIDIwLjg5MTMwNF0gdXNiY29y
ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcw0KICBbICAgMjAuOTA3
OTYyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1Yg0KICBb
ICAgMjAuOTI0MTY3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVz
Yg0KICBbICAgMjAuOTM5NjExXSBMaW51eCB2aWRlbyBjYXB0dXJlIGludGVyZmFjZTogdjIu
MDANCiAgWyAgIDIwLjk1MzY2Ml0gcHBzX2NvcmU6IExpbnV4UFBTIEFQSSB2ZXIuIDEgcmVn
aXN0ZXJlZA0KICBbICAgMjAuOTY4Mjc3XSBwcHNfY29yZTogU29mdHdhcmUgdmVyLiA1LjMu
NiAtIENvcHlyaWdodCAyMDA1LTIwMDcgUm9kb2xmbyBHaW9tZXR0aSA8Z2lvbWV0dGlAbGlu
dXguaXQ+DQogIFsgICAyMC45OTYxOTJdIFBUUCBjbG9jayBzdXBwb3J0IHJlZ2lzdGVyZWQN
CiAgWyAgIDIxLjAwODUwN10gQWR2YW5jZWQgTGludXggU291bmQgQXJjaGl0ZWN0dXJlIERy
aXZlciBJbml0aWFsaXplZC4NCiAgWyAgIDIxLjAyNjQ5Ml0gUENJOiBVc2luZyBBQ1BJIGZv
ciBJUlEgcm91dGluZw0KICBbICAgMjEuMDQ5OTE3XSBQQ0k6IHBjaV9jYWNoZV9saW5lX3Np
emUgc2V0IHRvIDY0IGJ5dGVzDQogIFsgICAyMS4wNjQ1NDFdIHBjaSAwMDAwOjBjOjAwLjA6
IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGZkMDAwMDAwLTB4ZmRmZmZmZmYgZmxhZ3MgMHg0
MDIwMF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuMDkxODA0XSBwY2kgMDAwMDowYzowMC4wOiBC
QVIgMTogcmVzZXJ2aW5nIFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmIGZsYWdzIDB4MTQy
MjBjXSAoZD0wLCBwPTApDQogIFsgICAyMS4xMTkzNzldIHBjaSAwMDAwOjBjOjAwLjA6IEJB
UiAzOiByZXNlcnZpbmcgW21lbSAweGZhMDAwMDAwLTB4ZmJmZmZmZmYgZmxhZ3MgMHgxNDAy
MDRdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjE0NjkyM10gcGNpIDAwMDA6MGM6MDAuMDogQkFS
IDU6IHJlc2VydmluZyBbaW8gIDB4ZTgwMC0weGU4N2YgZmxhZ3MgMHg0MDEwMV0gKGQ9MCwg
cD0wKQ0KICBbICAgMjEuMTcyMTU2XSBwY2kgMDAwMDowYjowMS4wOiBCQVIgMDogcmVzZXJ2
aW5nIFttZW0gMHhmOWZmZDAwMC0weGY5ZmZkZmZmIGZsYWdzIDB4NDAyMDBdIChkPTAsIHA9
MCkNCiAgWyAgIDIxLjE5OTQ0OV0gcGNpIDAwMDA6MGI6MDEuMTogQkFSIDA6IHJlc2Vydmlu
ZyBbbWVtIDB4ZjlmZmUwMDAtMHhmOWZmZWZmZiBmbGFncyAweDQwMjAwXSAoZD0wLCBwPTAp
DQogIFsgICAyMS4yMjY3NDRdIHBjaSAwMDAwOjBiOjAxLjI6IEJBUiAwOiByZXNlcnZpbmcg
W21lbSAweGY5ZmZmYzAwLTB4ZjlmZmZjZmYgZmxhZ3MgMHg0MDIwMF0gKGQ9MCwgcD0wKQ0K
ICBbICAgMjEuMjU0MDQyXSBwY2kgMDAwMDowOTowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFtp
byAgMHhkODAwLTB4ZDhmZiBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTApDQogIFsgICAyMS4y
NzkyNTldIHBjaSAwMDAwOjA5OjAwLjA6IEJBUiAyOiByZXNlcnZpbmcgW21lbSAweGNmZmZm
MDAwLTB4Y2ZmZmZmZmYgZmxhZ3MgMHgxNDIyMGNdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjMw
NjgxOF0gcGNpIDAwMDA6MDk6MDAuMDogQkFSIDQ6IHJlc2VydmluZyBbbWVtIDB4Y2ZmZjgw
MDAtMHhjZmZmYmZmZiBmbGFncyAweDE0MjIwY10gKGQ9MCwgcD0wKQ0KICBbICAgMjEuMzM0
Mzc5XSBwY2kgMDAwMDowODowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFtpbyAgMHhjODAwLTB4
YzhmZiBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTApDQogIFsgICAyMS4zNTk2MDVdIHBjaSAw
MDAwOjA4OjAwLjA6IEJBUiAyOiByZXNlcnZpbmcgW21lbSAweGNmZWZmMDAwLTB4Y2ZlZmZm
ZmYgZmxhZ3MgMHgxNDIyMGNdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjM4NzE1M10gcGNpIDAw
MDA6MDg6MDAuMDogQkFSIDQ6IHJlc2VydmluZyBbbWVtIDB4Y2ZlZjgwMDAtMHhjZmVmYmZm
ZiBmbGFncyAweDE0MjIwY10gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNDE0NzA4XSBwY2kgMDAw
MDowNzowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOWNmZTAwMC0weGY5Y2ZmZmZm
IGZsYWdzIDB4MTQwMjA0XSAoZD0wLCBwPTApDQogIFsgICAyMS40NDIyNzNdIHBjaSAwMDAw
OjA2OjAwLjA6IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGY5YTAwMDAwLTB4ZjliZmZmZmYg
ZmxhZ3MgMHgxNDAyMDRdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjQ2OTgzM10gcGNpIDAwMDA6
MDU6MDAuMTogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk5ZmMwMDAtMHhmOTlmZmZmZiBm
bGFncyAweDE0MDIwNF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNDk3MzkwXSBwY2kgMDAwMDow
NDowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOThmZTAwMC0weGY5OGZmZmZmIGZs
YWdzIDB4MTQwMjA0XSAoZD0wLCBwPTApDQogIFsgICAyMS41MjQ5NDVdIHBjaSAwMDAwOjAw
OjExLjA6IEJBUiAwOiByZXNlcnZpbmcgW2lvICAweDcwMDAtMHg3MDA3IGZsYWdzIDB4NDAx
MDFdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjU1MDE2M10gcGNpIDAwMDA6MDA6MTEuMDogQkFS
IDE6IHJlc2VydmluZyBbaW8gIDB4NjAwMC0weDYwMDMgZmxhZ3MgMHg0MDEwMV0gKGQ9MCwg
cD0wKQ0KICBbICAgMjEuNTc1NDExXSBwY2kgMDAwMDowMDoxMS4wOiBCQVIgMjogcmVzZXJ2
aW5nIFtpbyAgMHg1MDAwLTB4NTAwNyBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTApDQogIFsg
ICAyMS42MDA2NDhdIHBjaSAwMDAwOjAwOjExLjA6IEJBUiAzOiByZXNlcnZpbmcgW2lvICAw
eDMwMDAtMHgzMDAzIGZsYWdzIDB4NDAxMDFdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjYyNTg0
OV0gcGNpIDAwMDA6MDA6MTEuMDogQkFSIDQ6IHJlc2VydmluZyBbaW8gIDB4MjAwMC0weDIw
MGYgZmxhZ3MgMHg0MDEwMV0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNjUxMDY5XSBwY2kgMDAw
MDowMDoxMS4wOiBCQVIgNTogcmVzZXJ2aW5nIFttZW0gMHhmOTZmZjAwMC0weGY5NmZmM2Zm
IGZsYWdzIDB4NDAyMDBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjY3ODM2OV0gcGNpIDAwMDA6
MDA6MTIuMDogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk2ZmIwMDAtMHhmOTZmYmZmZiBm
bGFncyAweDQwMjAwXSAoZD0wLCBwPTApDQogIFsgICAyMS43MDU2NjBdIHBjaSAwMDAwOjAw
OjEyLjI6IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGY5NmZmNDAwLTB4Zjk2ZmY0ZmYgZmxh
Z3MgMHg0MDIwMF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNzMyOTU4XSBwY2kgMDAwMDowMDox
My4wOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOTZmYzAwMC0weGY5NmZjZmZmIGZsYWdz
IDB4NDAyMDBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjc2MDI2NV0gcGNpIDAwMDA6MDA6MTMu
MjogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk2ZmY4MDAtMHhmOTZmZjhmZiBmbGFncyAw
eDQwMjAwXSAoZD0wLCBwPTApDQogIFsgICAyMS43ODc1NjNdIHBjaSAwMDAwOjAwOjE0LjE6
IEJBUiAwOiByZXNlcnZpbmcgW2lvICAweDAxZjAtMHgwMWY3IGZsYWdzIDB4MTEwXSAoZD0w
LCBwPTApDQogIFsgICAyMS44MTIyNThdIHBjaSAwMDAwOjAwOjE0LjE6IEJBUiAxOiByZXNl
cnZpbmcgW2lvICAweDAzZjYgZmxhZ3MgMHgxMTBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjgz
NTEzNl0gcGNpIDAwMDA6MDA6MTQuMTogQkFSIDI6IHJlc2VydmluZyBbaW8gIDB4MDE3MC0w
eDAxNzcgZmxhZ3MgMHgxMTBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjg1OTgzNF0gcGNpIDAw
MDA6MDA6MTQuMTogQkFSIDM6IHJlc2VydmluZyBbaW8gIDB4MDM3NiBmbGFncyAweDExMF0g
KGQ9MCwgcD0wKQ0KICBbICAgMjEuODgyNzA3XSBwY2kgMDAwMDowMDoxNC4xOiBCQVIgNDog
cmVzZXJ2aW5nIFtpbyAgMHhmZjAwLTB4ZmYwZiBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTAp
DQogIFsgICAyMS45MDc5MzldIHBjaSAwMDAwOjAzOjA2LjA6IEJBUiAwOiByZXNlcnZpbmcg
W2lvICAweGE4MDAtMHhhOGZmIGZsYWdzIDB4NDAxMDFdIChkPTAsIHA9MCkNCiAgWyAgIDIx
LjkzMzE1Ml0gcGNpIDAwMDA6MDA6MTQuNTogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk2
ZmQwMDAtMHhmOTZmZGZmZiBmbGFncyAweDQwMjAwXSAoZD0wLCBwPTApDQogIFsgICAyMS45
NjA0NTJdIHBjaSAwMDAwOjAwOjE2LjA6IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGY5NmZl
MDAwLTB4Zjk2ZmVmZmYgZmxhZ3MgMHg0MDIwMF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuOTg3
NzUyXSBwY2kgMDAwMDowMDoxNi4yOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOTZmZmMw
MC0weGY5NmZmY2ZmIGZsYWdzIDB4NDAyMDBdIChkPTAsIHA9MCkNCiAgWyAgIDIyLjAxNTA4
M10gcGNpIDAwMDA6MDU6MDAuMDogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4YjAwMDAwMDAt
MHhiZmZmZmZmZiBmbGFncyAweDE0MjIwY10gKGQ9MSwgcD0xKQ0KICBbICAgMjIuMDQyNjA0
XSBwY2kgMDAwMDowNTowMC4wOiBCQVIgMjogcmVzZXJ2aW5nIFttZW0gMHhmOTljMDAwMC0w
eGY5OWRmZmZmIGZsYWdzIDB4MTQwMjA0XSAoZD0xLCBwPTEpDQogIFsgICAyMi4wNzAxNjRd
IHBjaSAwMDAwOjA1OjAwLjA6IEJBUiA0OiByZXNlcnZpbmcgW2lvICAweGIwMDAtMHhiMGZm
IGZsYWdzIDB4NDAxMDFdIChkPTEsIHA9MSkNCiAgWyAgIDIyLjA5NTQxOV0gZTgyMDogcmVz
ZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwMDA5ZjAwMC0weDAwMDlmZmZmXQ0KICBbICAgMjIu
MTE0MzE2XSBCbHVldG9vdGg6IENvcmUgdmVyIDIuMTYNCiAgWyAgIDIyLjEyNTAzNl0gTkVU
OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAzMQ0KICBbICAgMjIuMTM4MjgzXSBCbHVl
dG9vdGg6IEhDSSBkZXZpY2UgYW5kIGNvbm5lY3Rpb24gbWFuYWdlciBpbml0aWFsaXplZA0K
ICBbICAgMjIuMTU3NTQwXSBCbHVldG9vdGg6IEhDSSBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6
ZWQNCiAgWyAgIDIyLjE3MjMzMV0gQmx1ZXRvb3RoOiBMMkNBUCBzb2NrZXQgbGF5ZXIgaW5p
dGlhbGl6ZWQNCiAgWyAgIDIyLjE4NzY5OV0gQmx1ZXRvb3RoOiBTQ08gc29ja2V0IGxheWVy
IGluaXRpYWxpemVkDQogIFsgICAyMi4yMDI2MzFdIFN3aXRjaGluZyB0byBjbG9ja3NvdXJj
ZSB4ZW4NCiAgWyAgIDIyLjIxNDgzMl0gRlMtQ2FjaGU6IExvYWRlZA0KICBbICAgMjIuMjIz
NjMxXSBwbnA6IFBuUCBBQ1BJIGluaXQNCiAgWyAgIDIyLjIzMjY4Nl0gQUNQSTogYnVzIHR5
cGUgcG5wIHJlZ2lzdGVyZWQNCiAgWyAgIDIyLjI0NTI3NF0gc3lzdGVtIDAwOjAwOiBbbWVt
IDB4ZmVjMjAwMDAtMHhmZWMyMDBmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQogIFsgICAy
Mi4yNjU5OTFdIHN5c3RlbSAwMDowMDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDBjMDIgKGFjdGl2ZSkNCiAgWyAgIDIyLjI4Njk0M10gc3lzdGVtIDAwOjAxOiBbbWVt
IDB4ZjYwMDAwMDAtMHhmNjAwM2ZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjMw
NjUxM10gc3lzdGVtIDAwOjAxOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5Q
MGMwMiAoYWN0aXZlKQ0KICBbICAgMjIuMzI3OTQ0XSBwbnAgMDA6MDI6IFtkbWEgNF0NCiAg
WyAgIDIyLjMzNzExM10gcG5wIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ
RHMgUE5QMDIwMCAoYWN0aXZlKQ0KICBbICAgMjIuMzU2NjE3XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSA4IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIwOjE0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04IC0+IDB4NTgg
LT4gSVJRIDggTW9kZTowIEFjdGl2ZTowKQ0KIFsgICAyMi4zOTk5MTBdIHBucCAwMDowMzog
UGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFjdGl2ZSkNCiAgWyAg
IDIyLjQxOTYzNl0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDgwMCAoYWN0aXZlKQ0KICBbICAgMjIuNDM5MDI5XSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSAxMyB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MDoxNF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTMgLT4gMHg4OCAt
PiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQ0KIFsgICAyMi40ODMxMTJdIHBucCAwMDowNTog
UGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDQgKGFjdGl2ZSkNCiAgWyAg
IDIyLjUwMjY0MF0geGVuOiByZWdpc3RlcmluZyBnc2kgNCB0cmlnZ2VyaW5nIDEgcG9sYXJp
dHkgMA0KICBbICAgMjIuNTE5MDkwXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjQNCiAgWyAg
IDIyLjUzMDAwMV0gcG5wIDAwOjA2OiBbZG1hIDAgZGlzYWJsZWRdDQogIFsgICAyMi41NDIx
MTBdIHBucCAwMDowNjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEg
KGFjdGl2ZSkNCiAgWyAgIDIyLjU2MTc5MF0gc3lzdGVtIDAwOjA3OiBbaW8gIDB4MDYwMC0w
eDA2ZGZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi41Nzk0MzFdIHN5c3RlbSAwMDow
NzogW2lvICAweDBhZTAtMHgwYWVmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuNTk3
MzgwXSBzeXN0ZW0gMDA6MDc6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAw
YzAyIChhY3RpdmUpDQogIFsgICAyMi42MTgyNzhdIHBucCAwMDowODogUGx1ZyBhbmQgUGxh
eSBBQ1BJIGRldmljZSwgSURzIFBOUDAxMDMgKGFjdGl2ZSkNCiAgWyAgIDIyLjYzODAwNF0g
c3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmVjMDAwMDAtMHhmZWMwMGZmZl0gY291bGQgbm90IGJl
IHJlc2VydmVkDQogIFsgICAyMi42NTg3MjVdIHN5c3RlbSAwMDowOTogW21lbSAweGZlZTAw
MDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi42Nzg3NDFdIHN5
c3RlbSAwMDowOTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFj
dGl2ZSkNCiAgWyAgIDIyLjY5OTY2NV0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDRkMC0weDA0
ZDFdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi43MTcyMjRdIHN5c3RlbSAwMDowYTog
W2lvICAweDA0MGJdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi43MzMzNjJdIHN5c3Rl
bSAwMDowYTogW2lvICAweDA0ZDZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi43NDk0
NTldIHN5c3RlbSAwMDowYTogW2lvICAweDBjMDAtMHgwYzAxXSBoYXMgYmVlbiByZXNlcnZl
ZA0KICBbICAgMjIuNzY3NDA0XSBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYzE0XSBoYXMgYmVl
biByZXNlcnZlZA0KICBbICAgMjIuNzgzNTE2XSBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYzUw
LTB4MGM1MV0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjgwMTQ2NV0gc3lzdGVtIDAw
OjBhOiBbaW8gIDB4MGM1Ml0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjgxNzU3NF0g
c3lzdGVtIDAwOjBhOiBbaW8gIDB4MGM2Y10gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIy
LjgzMzY5M10gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGM2Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQN
CiAgWyAgIDIyLjg0OTgxMl0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGNkMC0weDBjZDFdIGhh
cyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi44Njc3NTBdIHN5c3RlbSAwMDowYTogW2lvICAw
eDBjZDItMHgwY2QzXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuODg1Njg5XSBzeXN0
ZW0gMDA6MGE6IFtpbyAgMHgwY2Q0LTB4MGNkNV0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAg
IDIyLjkwMzYyN10gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGNkNi0weDBjZDddIGhhcyBiZWVu
IHJlc2VydmVkDQogIFsgICAyMi45MjE1NjZdIHN5c3RlbSAwMDowYTogW2lvICAweDBjZDgt
MHgwY2RmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuOTM5NTA4XSBzeXN0ZW0gMDA6
MGE6IFtpbyAgMHgwODAwLTB4MDg5Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjk1
NzQ0NV0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGIwMC0weDBiMWZdIGhhcyBiZWVuIHJlc2Vy
dmVkDQogIFsgICAyMi45NzUzODNdIHN5c3RlbSAwMDowYTogW2lvICAweDBiMjAtMHgwYjNm
XSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuOTkzMzIyXSBzeXN0ZW0gMDA6MGE6IFtp
byAgMHgwOTAwLTB4MDkwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIzLjAxMTI2MV0g
c3lzdGVtIDAwOjBhOiBbaW8gIDB4MDkxMC0weDA5MWZdIGhhcyBiZWVuIHJlc2VydmVkDQog
IFsgICAyMy4wMjkyMDFdIHN5c3RlbSAwMDowYTogW2lvICAweGZlMDAtMHhmZWZlXSBoYXMg
YmVlbiByZXNlcnZlZA0KICBbICAgMjMuMDQ3MTM5XSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhm
ZmI4MDAwMC0weGZmYmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjMuMDY3MTYw
XSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhmZWMxMDAwMC0weGZlYzEwMDFmXSBoYXMgYmVlbiBy
ZXNlcnZlZA0KICBbICAgMjMuMDg3MTc3XSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhmZWQ4MDAw
MC0weGZlZDgwZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjMuMTA3MTk4XSBzeXN0
ZW0gMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3Rp
dmUpDQogIFsgICAyMy4xMjgxNTldIHN5c3RlbSAwMDowYjogW21lbSAweGUwMDAwMDAwLTB4
ZWZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMy4xNDc3NjBdIHN5c3RlbSAw
MDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkN
CiAgWyAgIDIzLjE2ODY2OV0gc3lzdGVtIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5
ZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQogIFsgICAyMy4xODkzNTVdIHN5c3RlbSAw
MDowYzogW21lbSAweDAwMGMwMDAwLTB4MDAwY2ZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZl
ZA0KICBbICAgMjMuMjEwNDIyXSBzeXN0ZW0gMDA6MGM6IFttZW0gMHgwMDBlMDAwMC0weDAw
MGZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNCiAgWyAgIDIzLjIzMTQ2OV0gc3lzdGVt
IDAwOjBjOiBbbWVtIDB4MDAxMDAwMDAtMHhhZmZmZmZmZl0gY291bGQgbm90IGJlIHJlc2Vy
dmVkDQogIFsgICAyMy4yNTI1MzVdIHN5c3RlbSAwMDowYzogW21lbSAweGZlYzAwMDAwLTB4
ZmZmZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0KICBbICAgMjMuMjczNTg3XSBzeXN0
ZW0gMDA6MGM6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAxIChhY3Rp
dmUpDQogIFsgICAyMy4yOTQyNTldIHBucDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMN
CiAgWyAgIDIzLjMwNjg2NF0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVk
DQogIFsgICAyMy4zMzQwMDFdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAg
KDB4MHhmZmZmZmYpIC0gYWJvcnRpbmcuDQogIFsgICAyMy4zNTM2NjBdIHBjaSAwMDAwOjAw
OjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwY10NCiAgWyAgIDIzLjM2ODYzNl0gcGNpIDAw
MDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0NCiAgWyAg
IDIzLjM4NzA4Nl0gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhm
YTAwMDAwMC0weGZlOWZmZmZmXQ0KICBbICAgMjMuNDA3NjMzXSBwY2kgMDAwMDowMDowMi4w
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJl
Zl0NCiAgWyAgIDIzLjQzMTAyM10gcGNpIDAwMDA6MGE6MDAuMDogUENJIGJyaWRnZSB0byBb
YnVzIDBiXQ0KICBbICAgMjMuNDQ2MTEwXSBwY2kgMDAwMDowYTowMC4wOiAgIGJyaWRnZSB3
aW5kb3cgW21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQogIFsgICAyMy40NjY2NDldIHBj
aSAwMDAwOjAwOjAzLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwYS0wYl0NCiAgWyAgIDIzLjQ4
MjQ5Ml0gcGNpIDAwMDA6MDA6MDMuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWYwMDAw
MC0weGY5ZmZmZmZmXQ0KICBbICAgMjMuNTAzMDMzXSBwY2kgMDAwMDowMDowNS4wOiBQQ0kg
YnJpZGdlIHRvIFtidXMgMDldDQogIFsgICAyMy41MTgxMDZdIHBjaSAwMDAwOjAwOjA1LjA6
ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZDAwMC0weGRmZmZdDQogIFsgICAyMy41MzY1Njhd
IHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjllMDAwMDAtMHhm
OWVmZmZmZl0NCiAgWyAgIDIzLjU1NzEwNF0gcGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ug
d2luZG93IFttZW0gMHhjZmYwMDAwMC0weGNmZmZmZmZmIDY0Yml0IHByZWZdDQogIFsgICAy
My41ODA1NDJdIHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwOF0NCiAg
WyAgIDIzLjU5NTYxNl0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFtpbyAg
MHhjMDAwLTB4Y2ZmZl0NCiAgWyAgIDIzLjYxNDA3NF0gcGNpIDAwMDA6MDA6MDYuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmOWQwMDAwMC0weGY5ZGZmZmZmXQ0KICBbICAgMjMuNjM0
NjE1XSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZTAwMDAw
LTB4Y2ZlZmZmZmYgNjRiaXQgcHJlZl0NCiAgWyAgIDIzLjY1ODAxM10gcGNpIDAwMDA6MDA6
MDkuMDogUENJIGJyaWRnZSB0byBbYnVzIDA3XQ0KICBbICAgMjMuNjczMDkwXSBwY2kgMDAw
MDowMDowOS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YzAwMDAwLTB4ZjljZmZmZmZd
DQogIFsgICAyMy42OTM2MzJdIHBjaSAwMDAwOjAwOjBhLjA6IFBDSSBicmlkZ2UgdG8gW2J1
cyAwNl0NCiAgWyAgIDIzLjcwODcwOV0gcGNpIDAwMDA6MDA6MGEuMDogICBicmlkZ2Ugd2lu
ZG93IFttZW0gMHhmOWEwMDAwMC0weGY5YmZmZmZmXQ0KICBbICAgMjMuNzI5MjUzXSBwY2kg
MDAwMDowMDowYi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVdDQogIFsgICAyMy43NDQzMjdd
IHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZd
DQogIFsgICAyMy43NjI3ODVdIHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIDB4Zjk5MDAwMDAtMHhmOTlmZmZmZl0NCiAgWyAgIDIzLjc4MzMyOV0gcGNpIDAwMDA6
MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0
Yml0IHByZWZdDQogIFsgICAyMy44MDY3MzBdIHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwNF0NCiAgWyAgIDIzLjgyMTgwMl0gcGNpIDAwMDA6MDA6MGQuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmOTgwMDAwMC0weGY5OGZmZmZmXQ0KICBbICAgMjMuODQy
MzQ0XSBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNdDQogIFsgICAy
My44NTc0MjFdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YTAw
MC0weGFmZmZdDQogIFsgICAyMy44NzU4OTVdIHBjaSAwMDAwOjAwOjE1LjA6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwMl0NCiAgWyAgIDIzLjg5MTAxN10geGVuOiByZWdpc3RlcmluZyBnc2kg
NTIgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDIzLjkwNzg3MV0geGVuOiAtLT4g
cGlycT01MiAtPiBpcnE9NTIgKGdzaT01MikNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6
MTVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI4IC0+IDB4YjggLT4g
SVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjMuOTQ4NDU3XSB4ZW46IHJlZ2lzdGVy
aW5nIGdzaSA1MiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMjMuOTY1MzEzXSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjUyDQogIFsgICAyMy45NzY1MzFdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDUyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyMy45OTMzODld
IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NTINCiAgWyAgIDI0LjAwNDYwMF0geGVuOiByZWdp
c3RlcmluZyBnc2kgNTMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDI0LjAyMTQ3
Nl0geGVuOiAtLT4gcGlycT01MyAtPiBpcnE9NTMgKGdzaT01MykNCiAgKFhFTikgWzIwMTMt
MDItMjcgMTE6MjA6MTZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5
IC0+IDB4YzAgLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjQuMDYyMDY2XSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSA1MyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAg
MjQuMDc4OTIzXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUzDQogIFsgICAyNC4wOTAxMzVd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDU0IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsg
ICAyNC4xMDcwMTJdIHhlbjogLS0+IHBpcnE9NTQgLT4gaXJxPTU0IChnc2k9NTQpDQogIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIwOjE2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0zMCAtPiAweGM4IC0+IElSUSA1NCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI0
LjE0NzU5N10geGVuOiByZWdpc3RlcmluZyBnc2kgNTQgdHJpZ2dlcmluZyAwIHBvbGFyaXR5
IDENCiAgWyAgIDI0LjE2NDQ1N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo1NA0KICBbICAg
MjQuMTc1NjcwXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA1NCB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQ0KICBbICAgMjQuMTkyNTM1XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjU0DQogIFsg
ICAyNC4yMDM3NTldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQogIFsgICAyNC4yMjA2MjFdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChn
c2k9MTYpDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjE2XSBJT0FQSUNbMF06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNi0xNiAtPiAweGQwIC0+IElSUSAxNiBNb2RlOjEgQWN0aXZl
OjEpDQogWyAgIDI0LjI2MTE4Ml0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA0IFtpbyAg
MHgwMDAwLTB4MGNmN10NCiAgWyAgIDI0LjI3ODA3M10gcGNpX2J1cyAwMDAwOjAwOiByZXNv
dXJjZSA1IFtpbyAgMHgwZDAwLTB4ZmZmZl0NCiAgWyAgIDI0LjI5NDk3NF0gcGNpX2J1cyAw
MDAwOjAwOiByZXNvdXJjZSA2IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KICBbICAg
MjQuMzEzOTQ4XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDcgW21lbSAweDAwMGQwMDAw
LTB4MDAwZGZmZmZdDQogIFsgICAyNC4zMzI5MzBdIHBjaV9idXMgMDAwMDowMDogcmVzb3Vy
Y2UgOCBbbWVtIDB4YjAwMDAwMDAtMHhkZmZmZmZmZl0NCiAgWyAgIDI0LjM1MTkwOV0gcGNp
X2J1cyAwMDAwOjAwOiByZXNvdXJjZSA5IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0K
ICBbICAgMjQuMzcwODg1XSBwY2lfYnVzIDAwMDA6MGM6IHJlc291cmNlIDAgW2lvICAweGUw
MDAtMHhlZmZmXQ0KICBbICAgMjQuMzg3Nzg2XSBwY2lfYnVzIDAwMDA6MGM6IHJlc291cmNl
IDEgW21lbSAweGZhMDAwMDAwLTB4ZmU5ZmZmZmZdDQogIFsgICAyNC40MDY3NjJdIHBjaV9i
dXMgMDAwMDowYzogcmVzb3VyY2UgMiBbbWVtIDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiA2NGJp
dCBwcmVmXQ0KICBbICAgMjQuNDI4NjAxXSBwY2lfYnVzIDAwMDA6MGE6IHJlc291cmNlIDEg
W21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQogIFsgICAyNC40NDc1NzldIHBjaV9idXMg
MDAwMDowYjogcmVzb3VyY2UgMSBbbWVtIDB4ZjlmMDAwMDAtMHhmOWZmZmZmZl0NCiAgWyAg
IDI0LjQ2NjU1OV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAwIFtpbyAgMHhkMDAwLTB4
ZGZmZl0NCiAgWyAgIDI0LjQ4MzQ2MV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAxIFtt
ZW0gMHhmOWUwMDAwMC0weGY5ZWZmZmZmXQ0KICBbICAgMjQuNTAyNDM5XSBwY2lfYnVzIDAw
MDA6MDk6IHJlc291cmNlIDIgW21lbSAweGNmZjAwMDAwLTB4Y2ZmZmZmZmYgNjRiaXQgcHJl
Zl0NCiAgWyAgIDI0LjUyNDI3OF0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAwIFtpbyAg
MHhjMDAwLTB4Y2ZmZl0NCiAgWyAgIDI0LjU0MTE3NF0gcGNpX2J1cyAwMDAwOjA4OiByZXNv
dXJjZSAxIFttZW0gMHhmOWQwMDAwMC0weGY5ZGZmZmZmXQ0KICBbICAgMjQuNTYwMTU2XSBw
Y2lfYnVzIDAwMDA6MDg6IHJlc291cmNlIDIgW21lbSAweGNmZTAwMDAwLTB4Y2ZlZmZmZmYg
NjRiaXQgcHJlZl0NCiAgWyAgIDI0LjU4MjAyNF0gcGNpX2J1cyAwMDAwOjA3OiByZXNvdXJj
ZSAxIFttZW0gMHhmOWMwMDAwMC0weGY5Y2ZmZmZmXQ0KICBbICAgMjQuNjAxMDAyXSBwY2lf
YnVzIDAwMDA6MDY6IHJlc291cmNlIDEgW21lbSAweGY5YTAwMDAwLTB4ZjliZmZmZmZdDQog
IFsgICAyNC42MTk5ODJdIHBjaV9idXMgMDAwMDowNTogcmVzb3VyY2UgMCBbaW8gIDB4YjAw
MC0weGJmZmZdDQogIFsgICAyNC42MzY4ODNdIHBjaV9idXMgMDAwMDowNTogcmVzb3VyY2Ug
MSBbbWVtIDB4Zjk5MDAwMDAtMHhmOTlmZmZmZl0NCiAgWyAgIDI0LjY1NTg2NF0gcGNpX2J1
cyAwMDAwOjA1OiByZXNvdXJjZSAyIFttZW0gMHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0
IHByZWZdDQogIFsgICAyNC42Nzc2OTddIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgMSBb
bWVtIDB4Zjk4MDAwMDAtMHhmOThmZmZmZl0NCiAgWyAgIDI0LjY5NjY4MF0gcGNpX2J1cyAw
MDAwOjAzOiByZXNvdXJjZSAwIFtpbyAgMHhhMDAwLTB4YWZmZl0NCiAgWyAgIDI0LjcxMzU3
Nl0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MGNmN10NCiAg
WyAgIDI0LjczMDQ3Nl0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA1IFtpbyAgMHgwZDAw
LTB4ZmZmZl0NCiAgWyAgIDI0Ljc0NzM3M10gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA2
IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KICBbICAgMjQuNzY2MzU0XSBwY2lfYnVz
IDAwMDA6MDM6IHJlc291cmNlIDcgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdDQogIFsg
ICAyNC43ODUzMzJdIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2UgOCBbbWVtIDB4YjAwMDAw
MDAtMHhkZmZmZmZmZl0NCiAgWyAgIDI0LjgwNDMxMl0gcGNpX2J1cyAwMDAwOjAzOiByZXNv
dXJjZSA5IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0KICBbICAgMjQuODIzMzQwXSBO
RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINCiAgWyAgIDI0LjgzNjkzOF0gVENQ
IGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDUsIDEzMTA3
MiBieXRlcykNCiAgWyAgIDI0Ljg1ODI2Nl0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiA4MTkyIChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQ0KICBbICAgMjQuODc4MzAxXSBUQ1A6
IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDgxOTIgYmluZCA4MTkyKQ0K
ICBbICAgMjQuODk3MTgwXSBUQ1A6IHJlbm8gcmVnaXN0ZXJlZA0KICBbICAgMjQuOTA3MDI1
XSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiA0LCA4MTkyMCBieXRlcykN
CiAgWyAgIDI0LjkyNTAyM10gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9y
ZGVyOiA0LCA4MTkyMCBieXRlcykNCiAgWyAgIDI0Ljk0NDM1OF0gTkVUOiBSZWdpc3RlcmVk
IHByb3RvY29sIGZhbWlseSAxDQogIFsgICAyNC45NTc0ODFdIHBjaSAwMDAwOjAwOjExLjA6
IGNhbGxpbmcgcXVpcmtfbXNpX2ludHhfZGlzYWJsZV9hdGlfYnVnKzB4MC8weDUwDQogIFsg
ICAyNC45NzkwMzddIHBjaSAwMDAwOjAwOjEyLjA6IGNhbGxpbmcgcXVpcmtfdXNiX2Vhcmx5
X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNC45OTkwOTBdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyNS4wMTU5NDddIHhlbjog
LS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIwOjE3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweGQ4
IC0+IElSUSAxOCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI1Ljg3MTUzNl0gcGNpIDAwMDA6
MDA6MTIuMjogY2FsbGluZyBxdWlya191c2JfZWFybHlfaGFuZG9mZisweDAvMHg3MTANCiAg
WyAgIDI1Ljg5MTExM10geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENCiAgWyAgIDI1LjkwNzk4Ml0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcg
KGdzaT0xNykNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MTddIElPQVBJQ1swXTogU2V0
IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4MjEgLT4gSVJRIDE3IE1vZGU6MSBBY3Rp
dmU6MSkNCiBbICAgMjUuOTQ4NTkwXSBwY2kgMDAwMDowMDoxMy4wOiBjYWxsaW5nIHF1aXJr
X3VzYl9lYXJseV9oYW5kb2ZmKzB4MC8weDcxMA0KICBbICAgMjUuOTY4NTc4XSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMjUuOTg1
NDQ4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQogIFsgICAyNi4wNzE1NDZdIHBjaSAw
MDAwOjAwOjEzLjI6IGNhbGxpbmcgcXVpcmtfdXNiX2Vhcmx5X2hhbmRvZmYrMHgwLzB4NzEw
DQogIFsgICAyNi4wOTExMzFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQogIFsgICAyNi4xMDc5ODhdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTcNCiAgWyAgIDI2LjExOTIzMV0gcGNpIDAwMDA6MDA6MTQuNTogY2FsbGluZyBxdWlya191
c2JfZWFybHlfaGFuZG9mZisweDAvMHg3MTANCiAgWyAgIDI2LjEzOTIyMF0geGVuOiByZWdp
c3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDI2LjE1NjA4
N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KICBbICAgMjYuMjQxNTU4XSBwY2kgMDAw
MDowMDoxNi4wOiBjYWxsaW5nIHF1aXJrX3VzYl9lYXJseV9oYW5kb2ZmKzB4MC8weDcxMA0K
ICBbICAgMjYuMjYxMTMyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQ0KICBbICAgMjYuMjc3OTkyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4
DQogIFsgICAyNi4zNjQ4OThdIHBjaSAwMDAwOjAwOjE2LjI6IGNhbGxpbmcgcXVpcmtfdXNi
X2Vhcmx5X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNi4zODQ0NzBdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyNi40MDEzMjld
IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcNCiAgWyAgIDI2LjQxMjU2MV0gcGNpIDAwMDA6
MDA6MTguMDogY2FsbGluZyBxdWlya19hbWRfbmJfbm9kZSsweDAvMHg4MA0KICBbICAgMjYu
NDMwNzEzXSBwY2kgMDAwMDowMDoxOC4xOiBjYWxsaW5nIHF1aXJrX2FtZF9uYl9ub2RlKzB4
MC8weDgwDQogIFsgICAyNi40NDg5MTFdIHBjaSAwMDAwOjAwOjE4LjI6IGNhbGxpbmcgcXVp
cmtfYW1kX25iX25vZGUrMHgwLzB4ODANCiAgWyAgIDI2LjQ2NzExMF0gcGNpIDAwMDA6MDA6
MTguMzogY2FsbGluZyBxdWlya19hbWRfbmJfbm9kZSsweDAvMHg4MA0KICBbICAgMjYuNDg1
MzA4XSBwY2kgMDAwMDowMDoxOC40OiBjYWxsaW5nIHF1aXJrX2FtZF9uYl9ub2RlKzB4MC8w
eDgwDQogIFsgICAyNi41MDM1MDhdIHBjaSAwMDAwOjBjOjAwLjA6IGNhbGxpbmcgbnZfbXNp
X2h0X2NhcF9xdWlya19sZWFmKzB4MC8weDEwDQogIFsgICAyNi41MjM1MzhdIHBjaSAwMDAw
OjBjOjAwLjA6IGNhbGxpbmcgcGNpX2ZpeHVwX3ZpZGVvKzB4MC8weGQwDQogIFsgICAyNi41
NDEyMDZdIHBjaSAwMDAwOjBjOjAwLjA6IEJvb3QgdmlkZW8gZGV2aWNlDQogIFsgICAyNi41
NTQ5ODNdIHBjaSAwMDAwOjBhOjAwLjA6IGNhbGxpbmcgcXVpcmtfeGlvMjAwMGErMHgwLzB4
YTANCiAgWyAgIDI2LjU3MjM5N10gcGNpIDAwMDA6MGE6MDAuMDogVEkgWElPMjAwMGEgcXVp
cmsgZGV0ZWN0ZWQ7IHNlY29uZGFyeSBidXMgZmFzdCBiYWNrLXRvLWJhY2sgdHJhbnNmZXJz
IGRpc2FibGVkDQogIFsgICAyNi42MDIwNDZdIHBjaSAwMDAwOjBiOjAxLjA6IGNhbGxpbmcg
cXVpcmtfdXNiX2Vhcmx5X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNi42MjIwNzVdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDI5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAy
Ni42Mzg5NjZdIHhlbjogLS0+IHBpcnE9MjkgLT4gaXJxPTI5IChnc2k9MjkpDQogIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIwOjE4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy01IC0+IDB4MjkgLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjYuNjc5
MjkyXSBwY2kgMDAwMDowYjowMS4xOiBjYWxsaW5nIHF1aXJrX3VzYl9lYXJseV9oYW5kb2Zm
KzB4MC8weDcxMA0KICBbICAgMjYuNjk5MjkwXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMCB0
cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMjYuNzE2MTc3XSB4ZW46IC0tPiBwaXJx
PTMwIC0+IGlycT0zMCAoZ3NpPTMwKQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxOF0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDMxIC0+IElSUSAz
MCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI2Ljc1NjUxMF0gcGNpIDAwMDA6MGI6MDEuMjog
Y2FsbGluZyBxdWlya191c2JfZWFybHlfaGFuZG9mZisweDAvMHg3MTANCiAgWyAgIDI2Ljc3
NjUwNV0geGVuOiByZWdpc3RlcmluZyBnc2kgMzEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
CiAgWyAgIDI2Ljc5MzM5NV0geGVuOiAtLT4gcGlycT0zMSAtPiBpcnE9MzEgKGdzaT0zMSkN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MThdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTcgLT4gMHgzOSAtPiBJUlEgMzEgTW9kZToxIEFjdGl2ZToxKQ0KIFsg
ICAyNi44MzM3NjhdIHBjaSAwMDAwOjA3OjAwLjA6IGNhbGxpbmcgcXVpcmtfdXNiX2Vhcmx5
X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNi44NTM3NTRdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDQ4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyNi44NzA2NDBdIHhlbjog
LS0+IHBpcnE9NDggLT4gaXJxPTQ4IChnc2k9NDgpDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIwOjE4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yNCAtPiAweDQx
IC0+IElSUSA0OCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI2LjkxMTIzN10gcGNpIDAwMDA6
MDU6MDAuMDogY2FsbGluZyBwY2lfZml4dXBfdmlkZW8rMHgwLzB4ZDANCiAgWyAgIDI2Ljky
ODg3NV0gcGNpIDAwMDA6MDQ6MDAuMDogY2FsbGluZyBxdWlya191c2JfZWFybHlfaGFuZG9m
ZisweDAvMHg3MTANCiAgWyAgIDI2Ljk0ODkwOV0geGVuOiByZWdpc3RlcmluZyBnc2kgNDAg
dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDI2Ljk2NTc5OV0geGVuOiAtLT4gcGly
cT00MCAtPiBpcnE9NDAgKGdzaT00MCkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MThd
IElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+IDB4NDkgLT4gSVJR
IDQwIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjcuMDA2Mzg5XSBQQ0k6IENMUyA2NCBieXRl
cywgZGVmYXVsdCA2NA0KICBbICAgMjcuMDE4Njk2XSBUcnlpbmcgdG8gdW5wYWNrIHJvb3Rm
cyBpbWFnZSBhcyBpbml0cmFtZnMuLi4NCiAgWyAgIDI3LjA1NTg4NF0gRnJlZWluZyBpbml0
cmQgbWVtb3J5OiAxMjk3NmsgZnJlZWQNCiAgWyAgIDI3LjA3OTcxMV0gRE1BLUFQSTogcHJl
YWxsb2NhdGVkIDY1NTM2IGRlYnVnIGVudHJpZXMNCiAgWyAgIDI3LjA5NDY5Ml0gRE1BLUFQ
STogZGVidWdnaW5nIGVuYWJsZWQgYnkga2VybmVsIGNvbmZpZw0KICBbICAgMjcuMTEzNDQ5
XSBTY2FubmluZyBmb3IgbG93IG1lbW9yeSBjb3JydXB0aW9uIGV2ZXJ5IDYwIHNlY29uZHMN
CiAgWyAgIDI3LjEzMjk5OV0gc2hhMV9zc3NlMzogTmVpdGhlciBBVlggbm9yIFNTU0UzIGlz
IGF2YWlsYWJsZS91c2FibGUuDQogIFsgICAyNy4xNTIzMzBdIGF1ZGl0OiBpbml0aWFsaXpp
bmcgbmV0bGluayBzb2NrZXQgKGRpc2FibGVkKQ0KICBbICAgMjcuMTY4MjYwXSB0eXBlPTIw
MDAgYXVkaXQoMTM2MTk2NDAxMy42OTE6MSk6IGluaXRpYWxpemVkDQogIFsgICAyNy4xODYy
MzRdIGJvdW5jZSBwb29sIHNpemU6IDY0IHBhZ2VzDQogIFsgICAyNy4xOTcxOTddIEh1Z2VU
TEIgcmVnaXN0ZXJlZCAyIE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzDQog
IFsgICAyNy4yMjY1NzJdIFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjINCiAgWyAgIDI3
LjIzODQxM10gRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyIDAs
IDQwOTYgYnl0ZXMpDQogIFsgICAyNy4yNjAzMTVdIE5URlMgZHJpdmVyIDIuMS4zMCBbRmxh
Z3M6IFIvV10uDQogIFsgICAyNy4yNzM3MDFdIGZ1c2UgaW5pdCAoQVBJIHZlcnNpb24gNy4y
MSkNCiAgWyAgIDI3LjI4NjkzN10gQnRyZnMgbG9hZGVkDQogIFsgICAyNy4yOTU1MzRdIEdG
UzIgaW5zdGFsbGVkDQogIFsgICAyNy4zMDQxNDVdIGNlcGg6IGxvYWRlZCAobWRzIHByb3Rv
IDMyKQ0KICBbICAgMjcuMzE1MzgyXSBtc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDE4MjUNCiAg
WyAgIDI3LjMyOTMzNF0gQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2
ZXJzaW9uIDAuNCBsb2FkZWQgKG1ham9yIDI1MCkNCiAgWyAgIDI3LjM1MTI0Ml0gaW8gc2No
ZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZA0KICBbICAgMjcuMzYzMTkyXSBpbyBzY2hlZHVsZXIg
ZGVhZGxpbmUgcmVnaXN0ZXJlZA0KICBbICAgMjcuMzc2OTM5XSBpbyBzY2hlZHVsZXIgY2Zx
IHJlZ2lzdGVyZWQgKGRlZmF1bHQpDQogIFsgICAyNy4zOTE4NTZdIGNyYzMyOiBDUkNfTEVf
QklUUyA9IDY0LCBDUkNfQkUgQklUUyA9IDY0DQogIFsgICAyNy40MDY3NTRdIGNyYzMyOiBz
ZWxmIHRlc3RzIHBhc3NlZCwgcHJvY2Vzc2VkIDIyNTk0NCBieXRlcyBpbiA5ODQ5NCBuc2Vj
DQogIFsgICAyNy40Mjc2ODhdIGNyYzMyYzogQ1JDX0xFX0JJVFMgPSA2NA0KICBbICAgMjcu
NDM4NDcxXSBjcmMzMmM6IHNlbGYgdGVzdHMgcGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5
dGVzIGluIDU2OTM0IG5zZWMNCiAgWyAgIDI3LjQ2NzI1N10gcGNpX2hvdHBsdWc6IFBDSSBI
b3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUNCiAgWyAgIDI3LjQ4NDU3N10gcGNpZWhw
OiBQQ0kgRXhwcmVzcyBIb3QgUGx1ZyBDb250cm9sbGVyIERyaXZlciB2ZXJzaW9uOiAwLjQN
CiAgWyAgIDI3LjUwNDEyMl0gY3BjaWhwX3p0NTU1MDogWlQ1NTUwIENvbXBhY3RQQ0kgSG90
IFBsdWcgRHJpdmVyIHZlcnNpb246IDAuMg0KICBbICAgMjcuNTI0OTY4XSBjcGNpaHBfZ2Vu
ZXJpYzogR2VuZXJpYyBwb3J0IEkvTyBDb21wYWN0UENJIEhvdCBQbHVnIERyaXZlciB2ZXJz
aW9uOiAwLjENCiAgWyAgIDI3LjU0ODA2MF0gY3BjaWhwX2dlbmVyaWM6IG5vdCBjb25maWd1
cmVkLCBkaXNhYmxpbmcuDQogIFsgICAyNy41NjQxMjFdIHNocGNocDogU3RhbmRhcmQgSG90
IFBsdWcgUENJIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNA0KICBbICAgMjcuNTgz
OTUwXSBhY3BpcGhwOiBBQ1BJIEhvdCBQbHVnIFBDSSBDb250cm9sbGVyIERyaXZlciB2ZXJz
aW9uOiAwLjUNCiAgWyAgIDI3LjYyNTc5OV0gYWNwaXBocF9pYm06IGlibV9hY3BpcGhwX2lu
aXQ6IGFjcGlfd2Fsa19uYW1lc3BhY2UgZmFpbGVkDQogIFsgICAyNy42NDUzNTVdIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdWRsZmINCiAgWyAgIDI3LjY2
MTcxNl0gdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01MTIwLCBw
YWdlcz0wDQogIFsgICAyNy42ODAyNDBdIHZlc2FmYjogc2Nyb2xsaW5nOiByZWRyYXcNCiAg
WyAgIDI3LjY5MTQxOV0gdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9ODo4Ojg6OCwgc2hpZnQ9
MjQ6MTY6ODowDQogIFsgICAyNy43MTAyNDBdIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhm
YjAwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZmM5MDAxMDMwMDAwMCwgdXNpbmcgMTAyNDBrLCB0
b3RhbCAxNDMzNmsNCiAgWyAgIDI3Ljc1OTk5NV0gQ29uc29sZTogc3dpdGNoaW5nIHRvIGNv
bG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDE2MHg2NA0KICBbICAgMjcuNzk4NzcxXSBmYjA6
IFZFU0EgVkdBIGZyYW1lIGJ1ZmZlciBkZXZpY2UNCiAgWyAgIDI3LjgxMjY0N10gaW5wdXQ6
IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTWUJVUzowMC9QTlAw
QzBDOjAwL2lucHV0L2lucHV0MA0KICBbICAgMjcuODM3NjQwXSBBQ1BJOiBQb3dlciBCdXR0
b24gW1BXUkJdDQogIFsgICAyNy44NDg5NjZdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2Rl
dmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQxDQogIFsgICAyNy44
NzExMzldIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0NCiAgWyAgIDI3Ljg4ODMxN10gV2Fy
bmluZzogUHJvY2Vzc29yIFBsYXRmb3JtIExpbWl0IG5vdCBzdXBwb3J0ZWQuDQogIFsgICAy
Ny45MDYwNjFdIEV2ZW50LWNoYW5uZWwgZGV2aWNlIGluc3RhbGxlZC4NCiAgWyAgIDI3Ljkx
OTE4N10geGVuLXBjaWJhY2s6IGJhY2tlbmQgaXMgdnBjaQ0KICBbICAgMjcuOTMyNjg4XSBT
ZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVk
DQogIFsgICAyNy45NTMxNDZdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBp
biBfQ1JTDQogIFsgICAyNy45Njg4MzFdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEw
Mw0KICBbICAgMjcuOTgzNDYxXSBIYW5nY2hlY2s6IHN0YXJ0aW5nIGhhbmdjaGVjayB0aW1l
ciAwLjkuMSAodGljayBpcyAxODAgc2Vjb25kcywgbWFyZ2luIGlzIDYwIHNlY29uZHMpLg0K
ICBbICAgMjguMDEwMjM4XSBIYW5nY2hlY2s6IFVzaW5nIGdldHJhd21vbm90b25pYygpLg0K
ICBbICAgMjguMDI0MzQyXSBbZHJtXSBJbml0aWFsaXplZCBkcm0gMS4xLjAgMjAwNjA4MTAN
CiAgWyAgIDI4LjAzODU0Ml0gW2RybV0gcmFkZW9uIGtlcm5lbCBtb2Rlc2V0dGluZyBlbmFi
bGVkLg0KICBbICAgMjguMDUzNDI3XSBjaGVja2luZyBnZW5lcmljIChmYjAwMDAwMCBlMDAw
MDApIHZzIGh3IChiMDAwMDAwMCAxMDAwMDAwMCkNCiAgWyAgIDI4LjA3MzYwNl0gcmFkZW9u
IDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDMpDQogIFsgICAy
OC4wOTE1NzVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMyIHRyaWdnZXJpbmcgMCBwb2xhcml0
eSAxDQogIFsgICAyOC4xMDg0MzldIHhlbjogLS0+IHBpcnE9MzIgLT4gaXJxPTMyIChnc2k9
MzIpDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNy04IC0+IDB4OTkgLT4gSVJRIDMyIE1vZGU6MSBBY3RpdmU6MSkN
CiBbICAgMjguMTQ5NDg4XSBbZHJtXSBpbml0aWFsaXppbmcga2VybmVsIG1vZGVzZXR0aW5n
IChUVVJLUyAweDEwMDI6MHg2NzU5IDB4MTc0QjoweEUxOTMpLg0KICBbICAgMjguMTczMTc0
XSBbZHJtXSByZWdpc3RlciBtbWlvIGJhc2U6IDB4Rjk5QzAwMDANCiAgWyAgIDI4LjE4NzE3
NF0gW2RybV0gcmVnaXN0ZXIgbW1pbyBzaXplOiAxMzEwNzINCiAgWyAgIDI4LjMyMDE1N10g
QVRPTSBCSU9TOiBFTElYSVINCiAgWyAgIDI4LjMyODkzMl0gW2RybV0gR1BVIG5vdCBwb3N0
ZWQuIHBvc3Rpbmcgbm93Li4uDQogIFsgICAyOC4zNDU3ODZdIHJhZGVvbiAwMDAwOjA1OjAw
LjA6IFZSQU06IDEwMjRNIDB4MDAwMDAwMDAwMDAwMDAwMCAtIDB4MDAwMDAwMDAzRkZGRkZG
RiAoMTAyNE0gdXNlZCkNCiAgWyAgIDI4LjM3MjM1Ml0gcmFkZW9uIDAwMDA6MDU6MDAuMDog
R1RUOiA1MTJNIDB4MDAwMDAwMDA0MDAwMDAwMCAtIDB4MDAwMDAwMDA1RkZGRkZGRg0KICBb
ICAgMjguMzk1MjAyXSBbZHJtXSBEZXRlY3RlZCBWUkFNIFJBTT0xMDI0TSwgQkFSPTI1Nk0N
CiAgWyAgIDI4LjQxMDAxN10gW2RybV0gUkFNIHdpZHRoIDEyOGJpdHMgRERSDQogIFsgICAy
OC40MjE5MjRdIFtUVE1dIFpvbmUgIGtlcm5lbDogQXZhaWxhYmxlIGdyYXBoaWNzIG1lbW9y
eTogNDY3NDA2IGtpQg0KICBbICAgMjguNDQxMjE4XSBbVFRNXSBJbml0aWFsaXppbmcgcG9v
bCBhbGxvY2F0b3INCiAgWyAgIDI4LjQ1NDQ4Nl0gW1RUTV0gSW5pdGlhbGl6aW5nIERNQSBw
b29sIGFsbG9jYXRvcg0KICBbICAgMjguNDY5MDExXSBbZHJtXSByYWRlb246IDEwMjRNIG9m
IFZSQU0gbWVtb3J5IHJlYWR5DQogIFsgICAyOC40ODM4NTRdIFtkcm1dIHJhZGVvbjogNTEy
TSBvZiBHVFQgbWVtb3J5IHJlYWR5Lg0KICBbICAgMjguNDk4NzIxXSBbZHJtXSBTdXBwb3J0
cyB2YmxhbmsgdGltZXN0YW1wIGNhY2hpbmcgUmV2IDEgKDEwLjEwLjIwMTApLg0KICBbICAg
MjguNTI1MDA5XSBbZHJtXSBEcml2ZXIgc3VwcG9ydHMgcHJlY2lzZSB2YmxhbmsgdGltZXN0
YW1wIHF1ZXJ5Lg0KICBbICAgMjguNTQ5ODE1XSByYWRlb24gMDAwMDowNTowMC4wOiByYWRl
b246IHVzaW5nIE1TSS4NCiAgWyAgIDI4LjU3MDk1NF0gW2RybV0gcmFkZW9uOiBpcnEgaW5p
dGlhbGl6ZWQuDQogIFsgICAyOC41ODk3MzVdIFtkcm1dIEdBUlQ6IG51bSBjcHUgcGFnZXMg
MTMxMDcyLCBudW0gZ3B1IHBhZ2VzIDEzMTA3Mg0KICBbICAgMjguNjE1OTQ1XSBbZHJtXSBw
cm9iaW5nIGdlbiAyIGNhcHMgZm9yIGRldmljZSAxMDAyOjVhMWYgPSAzMWNkMDIvMA0KICBb
ICAgMjguNjQxNTcxXSBbZHJtXSBlbmFibGluZyBQQ0lFIGdlbiAyIGxpbmsgc3BlZWRzLCBk
aXNhYmxlIHdpdGggcmFkZW9uLnBjaWVfZ2VuMj0wDQogIFsgICAyOC42NzExMzNdIFtkcm1d
IExvYWRpbmcgVFVSS1MgTWljcm9jb2RlDQogIFsgICA4OC44MzU0NDddIG5pX2NwOiBGYWls
ZWQgdG8gbG9hZCBmaXJtd2FyZSAicmFkZW9uL1RVUktTX3BmcC5iaW4iDQogIFsgICA4OC44
NjAzMTVdIFtkcm06ZXZlcmdyZWVuX3N0YXJ0dXBdICpFUlJPUiogRmFpbGVkIHRvIGxvYWQg
ZmlybXdhcmUhDQogIFsgICA4OC44ODU5NzZdIHJhZGVvbiAwMDAwOjA1OjAwLjA6IGRpc2Fi
bGluZyBHUFUgYWNjZWxlcmF0aW9uDQogIFsgICA4OC45MTA1MzZdIHJhZGVvbiAwMDAwOjA1
OjAwLjA6IGZmZmY4ODAwMDJmZmQ0MDAgdW5waW4gbm90IG5lY2Vzc2FyeQ0KICBbICAgODgu
OTM2NDEzXSByYWRlb24gMDAwMDowNTowMC4wOiBmZmZmODgwMDAyZmZkNDAwIHVucGluIG5v
dCBuZWNlc3NhcnkNCiAgWyAgIDg4Ljk2MjY2NV0gW2RybTpldmVyZ3JlZW5faW5pdF0gKkVS
Uk9SKiByYWRlb246IE1DIHVjb2RlIHJlcXVpcmVkIGZvciBOSSsuDQogIFsgICA4OC45ODk5
OTVdIHJhZGVvbiAwMDAwOjA1OjAwLjA6IEZhdGFsIGVycm9yIGR1cmluZyBHUFUgaW5pdA0K
ICBbICAgODkuMDEzMzY5XSBbZHJtXSByYWRlb246IGZpbmlzaGluZyBkZXZpY2UuDQogIFsg
ICA4OS4wMzM0NTFdIFtUVE1dIEZpbmFsaXppbmcgcG9vbCBhbGxvY2F0b3INCiAgWyAgIDg5
LjA1MjQxMl0gW1RUTV0gRmluYWxpemluZyBETUEgcG9vbCBhbGxvY2F0b3INCiAgWyAgIDg5
LjA3MjY2OV0gW1RUTV0gWm9uZSAga2VybmVsOiBVc2VkIG1lbW9yeSBhdCBleGl0OiAwIGtp
Qg0KICBbICAgODkuMDk1MzYwXSBbZHJtXSByYWRlb246IHR0bSBmaW5hbGl6ZWQNCiAgWyAg
IDg5LjExMzg3MV0gcmFkZW9uOiBwcm9iZSBvZiAwMDAwOjA1OjAwLjAgZmFpbGVkIHdpdGgg
ZXJyb3IgLTIyDQogIFsgICA4OS4xNDMxMTJdIGJyZDogbW9kdWxlIGxvYWRlZA0KICBbICAg
ODkuMTcyMTYwXSBsb29wOiBtb2R1bGUgbG9hZGVkDQogIFsgICA4OS4xODk0MjhdIGFoY2kg
MDAwMDowMDoxMS4wOiB2ZXJzaW9uIDMuMA0KICBbICAgODkuMjA3ODcyXSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgODkuMjMwNjU2
XSB4ZW46IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQ0KICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMToyMV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkg
LT4gMHhhOSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KIFsgICA4OS4yNzcyMzFdIGFo
Y2kgMDAwMDowMDoxMS4wOiBBSENJIDAwMDEuMDIwMCAzMiBzbG90cyA0IHBvcnRzIDYgR2Jw
cyAweGYgaW1wbCBTQVRBIG1vZGUNCiAgWyAgIDg5LjMwNzUyOV0gYWhjaSAwMDAwOjAwOjEx
LjA6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gcG1wIHBpbyBzbHVt
IHBhcnQgDQogIFsgICA4OS4zMzg4MjddIGFoY2k6IHByb2JlIG9mIDAwMDA6MDA6MTEuMCBm
YWlsZWQgd2l0aCBlcnJvciAtMjINCiAgWyAgIDg5LjM2MjY3OV0gdHVuOiBVbml2ZXJzYWwg
VFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNCiAgWyAgIDg5LjM4MzcxMV0gdHVuOiAoQykg
MTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29tbS5jb20+DQogIFsgICA4
OS40MDg0NzFdIGUxMDAwOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZl
cnNpb24gNy4zLjIxLWs4LU5BUEkNCiAgWyAgIDg5LjQzNTU0N10gZTEwMDA6IENvcHlyaWdo
dCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KICBbICAgODkuNDU5MTUzXSBl
MTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyIC0gMi4yLjE0LWsNCiAg
WyAgIDg5LjQ4MjkzMl0gZTEwMDBlOiBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMTMgSW50ZWwg
Q29ycG9yYXRpb24uDQogIFsgICA4OS41MDcwMzFdIGlnYjogSW50ZWwoUikgR2lnYWJpdCBF
dGhlcm5ldCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNC4xLjItaw0KICBbICAgODkuNTM0
MDA4XSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDEzIEludGVsIENvcnBvcmF0aW9uLg0K
ICBbICAgODkuNTU3MDY1XSBpZ2J2ZjogSW50ZWwoUikgR2lnYWJpdCBWaXJ0dWFsIEZ1bmN0
aW9uIE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiAyLjAuMi1rDQogIFsgICA4OS41ODY2Mjhd
IGlnYnZmOiBDb3B5cmlnaHQgKGMpIDIwMDkgLSAyMDEyIEludGVsIENvcnBvcmF0aW9uLg0K
ICBbICAgODkuNjEwOTQ3XSByODE2OSBHaWdhYml0IEV0aGVybmV0IGRyaXZlciAyLjNMSy1O
QVBJIGxvYWRlZA0KICBbICAgODkuNjMzODI1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0NiB0
cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgODkuNjU2NjA4XSB4ZW46IC0tPiBwaXJx
PTQ2IC0+IGlycT00NiAoZ3NpPTQ2KQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMToyMV0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjIgLT4gMHhiOSAtPiBJUlEg
NDYgTW9kZToxIEFjdGl2ZToxKQ0KIFsgICA4OS43MDI5ODBdIHI4MTY5IDAwMDA6MDk6MDAu
MDogZW5hYmxpbmcgTWVtLVdyLUludmFsDQogIFsgICA4OS43MjQ5NTBdIHI4MTY5IDAwMDA6
MDk6MDAuMCBldGgwOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAxYmUwMDAsIDQw
OjYxOjg2OmY0OjY3OmQ5LCBYSUQgMDgxMDAwYzAgSVJRIDEyMQ0KICBbICAgODkuNzYyMTUz
XSByODE2OSAwMDAwOjA5OjAwLjAgZXRoMDoganVtYm8gZmVhdHVyZXMgW2ZyYW1lczogOTIw
MCBieXRlcywgdHggY2hlY2tzdW1taW5nOiBrb10NCiAgWyAgIDg5Ljc5Mzk2NF0gcjgxNjkg
R2lnYWJpdCBFdGhlcm5ldCBkcml2ZXIgMi4zTEstTkFQSSBsb2FkZWQNCiAgWyAgIDg5Ljgx
NjgwMV0geGVuOiByZWdpc3RlcmluZyBnc2kgNTEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
CiAgWyAgIDg5LjgzOTgyMV0geGVuOiAtLT4gcGlycT01MSAtPiBpcnE9NTEgKGdzaT01MSkN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjE6MjFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTI3IC0+IDB4YzkgLT4gSVJRIDUxIE1vZGU6MSBBY3RpdmU6MSkNCiBb
ICAgODkuODg2MzUyXSByODE2OSAwMDAwOjA4OjAwLjA6IGVuYWJsaW5nIE1lbS1Xci1JbnZh
bA0KICBbICAgODkuOTA4NjY3XSByODE2OSAwMDAwOjA4OjAwLjAgZXRoMTogUlRMODE2OGQv
ODExMWQgYXQgMHhmZmZmYzkwMDAwMWUyMDAwLCA0MDo2MTo4NjpmNDo2NzpkOCwgWElEIDA4
MTAwMGMwIElSUSAxMjINCiAgWyAgIDg5Ljk0NTk4Ml0gcjgxNjkgMDAwMDowODowMC4wIGV0
aDE6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6IDkyMDAgYnl0ZXMsIHR4IGNoZWNrc3VtbWlu
Zzoga29dDQogIFsgICA4OS45NzgzMTNdIEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhl
cm5ldCBkcml2ZXIuDQogIFsgICA5MC4wMDE0NzNdIGVoY2lfaGNkOiBVU0IgMi4wICdFbmhh
bmNlZCcgSG9zdCBDb250cm9sbGVyIChFSENJKSBEcml2ZXINCiAgWyAgIDkwLjAyNzM5OF0g
ZWhjaS1wY2k6IEVIQ0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KICBbICAgOTAuMDQ3MTEzXSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAg
OTAuMDcwMTM2XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3DQogIFsgICA5MC4wODc0NjVd
IGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KICBbICAg
OTAuMTEwMDMzXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVy
DQogIFsgICA5MC4xMzI1MTNdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogbmV3IFVTQiBidXMg
cmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQogIFsgICA5MC4xNjExNDldIFFV
SVJLOiBFbmFibGUgQU1EIFBMTCBmaXgNCiAgWyAgIDkwLjE3ODQ5M10gZWhjaS1wY2kgMDAw
MDowMDoxMi4yOiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1
bW15IHFoIHdvcmthcm91bmQNCiAgWyAgIDkwLjIxMTEwMl0gZWhjaS1wY2kgMDAwMDowMDox
Mi4yOiBkZWJ1ZyBwb3J0IDENCiAgWyAgIDkwLjIzMTI3Nl0gZWhjaS1wY2kgMDAwMDowMDox
Mi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNCiAgWyAgIDkwLjI1MzY2OV0gZWhjaS1wY2kg
MDAwMDowMDoxMi4yOiBpcnEgMTcsIGlvIG1lbSAweGY5NmZmNDAwDQogIFsgICA5MC4yODQ4
NDBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAN
CiAgWyAgIDkwLjMwODUyN10gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl
bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KICBbICAgOTAuMzM1MjEyXSB1c2IgdXNiMTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTENCiAgWyAgIDkwLjM2MzE4Nl0gdXNiIHVzYjE6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250
cm9sbGVyDQogIFsgICA5MC4zODQwNzZdIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4
IDMuOC4wLXJjMC0yMDEzMDIyNyBlaGNpX2hjZA0KICBbICAgOTAuNDA5NjU5XSB1c2IgdXNi
MTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEyLjINCiAgWyAgIDkwLjQzMDQ0MF0gaHViIDEt
MDoxLjA6IFVTQiBodWIgZm91bmQNCiAgWyAgIDkwLjQ0ODAzMl0gaHViIDEtMDoxLjA6IDUg
cG9ydHMgZGV0ZWN0ZWQNCiAgWyAgIDkwLjQ2NjcxMl0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDkwLjQ4OTY2Ml0gQWxyZWFkeSBz
ZXR1cCB0aGUgR1NJIDoxNw0KICBbICAgOTAuNTA2ODQxXSBlaGNpLXBjaSAwMDAwOjAwOjEz
LjI6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNCiAgWyAgIDkwLjUyOTI5Nl0gZWhjaS1wY2kg
MDAwMDowMDoxMy4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTAuNTUxNTYyXSBl
aGNpLXBjaSAwMDAwOjAwOjEzLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVk
IGJ1cyBudW1iZXIgMg0KICBbICAgOTAuNTgwMDgxXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6
IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29y
a2Fyb3VuZA0KICBbICAgOTAuNjEyNTU1XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGRlYnVn
IHBvcnQgMQ0KICBbICAgOTAuNjMyNTU3XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJs
aW5nIE1lbS1Xci1JbnZhbA0KICBbICAgOTAuNjU0Nzg1XSBlaGNpLXBjaSAwMDAwOjAwOjEz
LjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmY4MDANCiAgWyAgIDkwLjY4ODE1MF0gZWhjaS1w
Y2kgMDAwMDowMDoxMy4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KICBbICAgOTAu
NzExNzEzXSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAyDQogIFsgICA5MC43MzgzOTRdIHVzYiB1c2IyOiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KICBbICAg
OTAuNzY2Mzk0XSB1c2IgdXNiMjogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXINCiAg
WyAgIDkwLjc4NzI4NV0gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtcmMw
LTIwMTMwMjI3IGVoY2lfaGNkDQogIFsgICA5MC44MTI4NzRdIHVzYiB1c2IyOiBTZXJpYWxO
dW1iZXI6IDAwMDA6MDA6MTMuMg0KICBbICAgOTAuODMzNTYyXSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KICBbICAgOTAuODUxMDMzXSBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRl
Y3RlZA0KICBbICAgOTAuODY5NDM5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgOTAuODkyMzA5XSBBbHJlYWR5IHNldHVwIHRoZSBH
U0kgOjE3DQogIFsgICA5MC45MDkzMzBdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxp
bmcgYnVzIG1hc3RlcmluZw0KICBbICAgOTAuOTMxNjAwXSBlaGNpLXBjaSAwMDAwOjAwOjE2
LjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5MC45NTM0NjZdIGVoY2ktcGNpIDAw
MDA6MDA6MTYuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJl
ciAzDQogIFsgICA5MC45ODE2NzNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogYXBwbHlpbmcg
QU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQog
IFsgICA5MS4wMTM4MzNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZGVidWcgcG9ydCAxDQog
IFsgICA5MS4wMzM0ODNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxpbmcgTWVtLVdy
LUludmFsDQogIFsgICA5MS4wNTUyOTVdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogaXJxIDE3
LCBpbyBtZW0gMHhmOTZmZmMwMA0KICBbICAgOTEuMDk4MDQ4XSBlaGNpLXBjaSAwMDAwOjAw
OjE2LjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwDQogIFsgICA5MS4xMjExMTNdIHVz
YiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0
PTAwMDINCiAgWyAgIDkxLjE0NzMxMl0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmlu
Z3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQogIFsgICA5MS4xNzQ4MDld
IHVzYiB1c2IzOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTEuMTk1
MTkzXSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcg
ZWhjaV9oY2QNCiAgWyAgIDkxLjIyMDI0M10gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAw
MDowMDoxNi4yDQogIFsgICA5MS4yNDAxNjFdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5k
DQogIFsgICA5MS4yNTcwMTNdIGh1YiAzLTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQogIFsg
ICA5MS4yNzQ4MzldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMxIHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQogIFsgICA5MS4yOTcxNDZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzENCiAg
WyAgIDkxLjMxMzY0M10gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBlbmFibGluZyBidXMgbWFz
dGVyaW5nDQogIFsgICA5MS4zMzUzMDVdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogRUhDSSBI
b3N0IENvbnRyb2xsZXINCiAgWyAgIDkxLjM1NjUxNV0gZWhjaS1wY2kgMDAwMDowYjowMS4y
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDQNCiAgWyAg
IDkxLjM4NDI0N10gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBpcnEgMzEsIGlvIG1lbSAweGY5
ZmZmYzAwDQogIFsgICA5MS40MTQ3OTFdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogVVNCIDIu
MCBzdGFydGVkLCBFSENJIDEuMDANCiAgWyAgIDkxLjQzNzQyNV0gdXNiIHVzYjQ6IE5ldyBV
U0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KICBbICAg
OTEuNDYzMTA3XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy
b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAgWyAgIDkxLjQ5MDEwNV0gdXNiIHVzYjQ6IFBy
b2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5MS41MTAwODVdIHVzYiB1c2I0
OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEzMDIyNyBlaGNpX2hjZA0KICBb
ICAgOTEuNTM0Nzk2XSB1c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjBiOjAxLjINCiAg
WyAgIDkxLjU1NDQ1Nl0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQNCiAgWyAgIDkxLjU3
MDk3MF0gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNCiAgWyAgIDkxLjU4ODY3MV0g
b2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVy
DQogIFsgICA5MS42MTI2MTddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQogIFsgICA5MS42MzQ2MTJdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTgNCiAgWyAgIDkxLjY1MDg5OV0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBlbmFibGluZyBi
dXMgbWFzdGVyaW5nDQogIFsgICA5MS42NzIzNzRdIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDog
T0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkxLjY5MzQ2Ml0gb2hjaV9oY2QgMDAwMDow
MDoxMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUN
CiAgWyAgIDkxLjcyMDk5NV0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBpcnEgMTgsIGlvIG1l
bSAweGY5NmZiMDAwDQogIFsgICA5MS43OTg5NTRdIHVzYiB1c2I1OiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENCiAgWyAgIDkxLjgyNDU5
Nl0gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIs
IFNlcmlhbE51bWJlcj0xDQogIFsgICA5MS44NTE1NDVdIHVzYiB1c2I1OiBQcm9kdWN0OiBP
SENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTEuODcxNTEzXSB1c2IgdXNiNTogTWFudWZh
Y3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcgb2hjaV9oY2QNCiAgWyAgIDkxLjg5
NjE4MV0gdXNiIHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4wDQogIFsgICA5MS45
MTU3MTddIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQogIFsgICA5MS45MzIyMjRdIGh1
YiA1LTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkDQogIFsgICA5MS45NDk4MDVdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5MS45NzE4
MzhdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNCiAgWyAgIDkxLjk4ODA0OF0gb2hjaV9o
Y2QgMDAwMDowMDoxMy4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQogIFsgICA5Mi4wMDk0
ODZdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogT0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAg
IDkyLjAzMDU1M10gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl
cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDYNCiAgWyAgIDkyLjA1ODEzN10gb2hjaV9oY2Qg
MDAwMDowMDoxMy4wOiBpcnEgMTgsIGlvIG1lbSAweGY5NmZjMDAwDQogIFsgICA5Mi4xMzU1
NTRdIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQ
cm9kdWN0PTAwMDENCiAgWyAgIDkyLjE2MTI0N10gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNl
IHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQogIFsgICA5Mi4x
ODgyNjJdIHVzYiB1c2I2OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAg
OTIuMjA4MjAwXSB1c2IgdXNiNjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAx
MzAyMjcgb2hjaV9oY2QNCiAgWyAgIDkyLjIzMjg0N10gdXNiIHVzYjY6IFNlcmlhbE51bWJl
cjogMDAwMDowMDoxMy4wDQogIFsgICA5Mi4yNTI0OTBdIGh1YiA2LTA6MS4wOiBVU0IgaHVi
IGZvdW5kDQogIFsgICA5Mi4yNjkwMDddIGh1YiA2LTA6MS4wOiA1IHBvcnRzIGRldGVjdGVk
DQogIFsgICA5Mi4yODY2MDldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQogIFsgICA5Mi4zMDg2MzZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTgNCiAgWyAgIDkyLjMyNDkyNV0gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBlbmFibGluZyBi
dXMgbWFzdGVyaW5nDQogIFsgICA5Mi4zNDY0MTRdIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTog
T0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkyLjM2NzU0Nl0gb2hjaV9oY2QgMDAwMDow
MDoxNC41OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcN
CiAgWyAgIDkyLjM3ODAzN10gdXNiIDUtNTogbmV3IGZ1bGwtc3BlZWQgVVNCIGRldmljZSBu
dW1iZXIgMiB1c2luZyBvaGNpX2hjZA0KICBbICAgOTIuNDIwMjExXSBvaGNpX2hjZCAwMDAw
OjAwOjE0LjU6IGlycSAxOCwgaW8gbWVtIDB4Zjk2ZmQwMDANCiAgWyAgIDkyLjQ5ODc2Nl0g
dXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1
Y3Q9MDAwMQ0KICBbICAgOTIuNTI0NjA2XSB1c2IgdXNiNzogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAgWyAgIDkyLjU1MTc1
Ml0gdXNiIHVzYjc6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5Mi41
NzE4NTRdIHVzYiB1c2I3OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEzMDIy
NyBvaGNpX2hjZA0KICBbICAgOTIuNTk2NjMyXSB1c2IgdXNiNzogU2VyaWFsTnVtYmVyOiAw
MDAwOjAwOjE0LjUNCiAgWyAgIDkyLjYxNjUzMl0gaHViIDctMDoxLjA6IFVTQiBodWIgZm91
bmQNCiAgWyAgIDkyLjYzMzQyMF0gaHViIDctMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNCiAg
WyAgIDkyLjY1MDk5MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENCiAgWyAgIDkyLjY3MzA5N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0K
ICBbICAgOTIuNjg5NDMyXSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IGVuYWJsaW5nIGJ1cyBt
YXN0ZXJpbmcNCiAgWyAgIDkyLjcxMTEwMl0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBPSENJ
IEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTIuNzMyNjAyXSBvaGNpX2hjZCAwMDAwOjAwOjE2
LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgOA0KICBb
ICAgOTIuNzYwNDc4XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IGlycSAxOCwgaW8gbWVtIDB4
Zjk2ZmUwMDANCiAgWyAgIDkyLjgzODg4Ml0gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZv
dW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KICBbICAgOTIuODY0OTI0XSB1
c2IgdXNiODogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2Vy
aWFsTnVtYmVyPTENCiAgWyAgIDkyLjg5MjA5NV0gdXNiIHVzYjg6IFByb2R1Y3Q6IE9IQ0kg
SG9zdCBDb250cm9sbGVyDQogIFsgICA5Mi45MTIxOTBdIHVzYiB1c2I4OiBNYW51ZmFjdHVy
ZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEzMDIyNyBvaGNpX2hjZA0KICBbICAgOTIuOTM3MDMx
XSB1c2IgdXNiODogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjE2LjANCiAgWyAgIDkyLjk1NjQw
Nl0gdXNiIDUtNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTBhMTIsIGlkUHJv
ZHVjdD0wMDAxDQogIFsgICA5Mi45NTY5MzhdIGh1YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5k
DQogIFsgICA5Mi45NTY5NDddIGh1YiA4LTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQogIFsg
ICA5Mi45NTcyOTRdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI5IHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQogIFsgICA5Mi45NTcyOTZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjkNCiAg
WyAgIDkyLjk1NzMxNV0gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBlbmFibGluZyBidXMgbWFz
dGVyaW5nDQogIFsgICA5Mi45NTczMjNdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogT0hDSSBI
b3N0IENvbnRyb2xsZXINCiAgWyAgIDkyLjk1NzY1NF0gb2hjaV9oY2QgMDAwMDowYjowMS4w
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkNCiAgWyAg
IDkyLjk1NzczNV0gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBpcnEgMjksIGlvIG1lbSAweGY5
ZmZkMDAwDQogIFsgICA5My4wMzgwNjNdIHVzYiB1c2I5OiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENCiAgWyAgIDkzLjAzODA2NF0gdXNi
IHVzYjk6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh
bE51bWJlcj0xDQogIFsgICA5My4wMzgwNjVdIHVzYiB1c2I5OiBQcm9kdWN0OiBPSENJIEhv
c3QgQ29udHJvbGxlcg0KICBbICAgOTMuMDM4MDY5XSB1c2IgdXNiOTogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcgb2hjaV9oY2QNCiAgWyAgIDkzLjAzODA3MF0g
dXNiIHVzYjk6IFNlcmlhbE51bWJlcjogMDAwMDowYjowMS4wDQogIFsgICA5My4wMzg1NzVd
IGh1YiA5LTA6MS4wOiBVU0IgaHViIGZvdW5kDQogIFsgICA5My4wMzg1ODZdIGh1YiA5LTA6
MS4wOiAzIHBvcnRzIGRldGVjdGVkDQogIFsgICA5My4wMzg5NTFdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDMwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5My4wMzg5NTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6MzANCiAgWyAgIDkzLjAzODk3MF0gb2hjaV9oY2QgMDAw
MDowYjowMS4xOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQogIFsgICA5My4wMzg5NzldIG9o
Y2lfaGNkIDAwMDA6MGI6MDEuMTogT0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkzLjAz
OTMxMV0gb2hjaV9oY2QgMDAwMDowYjowMS4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDEwDQogIFsgICA5My4wMzkzOThdIG9oY2lfaGNkIDAwMDA6
MGI6MDEuMTogaXJxIDMwLCBpbyBtZW0gMHhmOWZmZTAwMA0KICBbICAgOTMuMTIxNDIxXSB1
c2IgdXNiMTA6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1
Y3Q9MDAwMQ0KICBbICAgOTMuMTIxNDIzXSB1c2IgdXNiMTA6IE5ldyBVU0IgZGV2aWNlIHN0
cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQogIFsgICA5My4xMjE0
MjRdIHVzYiB1c2IxMDogUHJvZHVjdDogT0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkz
LjEyMTQyNV0gdXNiIHVzYjEwOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEz
MDIyNyBvaGNpX2hjZA0KICBbICAgOTMuMTIxNDI2XSB1c2IgdXNiMTA6IFNlcmlhbE51bWJl
cjogMDAwMDowYjowMS4xDQogIFsgICA5My4xMjIyODRdIGh1YiAxMC0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KICBbICAgOTMuMTIyMjk2XSBodWIgMTAtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0
ZWQNCiAgWyAgIDkzLjEyMjgzMV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250
cm9sbGVyIEludGVyZmFjZSBkcml2ZXINCiAgWyAgIDkzLjEyMzA2Ml0geGVuOiByZWdpc3Rl
cmluZyBnc2kgNDggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDkzLjEyMzA2NV0g
QWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0OA0KICBbICAgOTMuMTIzMDg1XSB4aGNpX2hjZCAw
MDAwOjA3OjAwLjA6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNCiAgWyAgIDkzLjEyMzA5MF0g
eGhjaV9oY2QgMDAwMDowNzowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTMu
MTIzNTAyXSB4aGNpX2hjZCAwMDAwOjA3OjAwLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMTENCiAgWyAgIDkzLjEyNTMyMV0geGhjaV9oY2QgMDAw
MDowNzowMC4wOiBlbmFibGluZyBNZW0tV3ItSW52YWwNCiAgWyAgIDkzLjEyNTM3MV0geGhj
aV9oY2QgMDAwMDowNzowMC4wOiBpcnEgNDgsIGlvIG1lbSAweGY5Y2ZlMDAwDQogIFsgICA5
My4xMjYyNjddIHVzYiB1c2IxMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFk
NmIsIGlkUHJvZHVjdD0wMDAyDQogIFsgICA5My4xMjYyNjhdIHVzYiB1c2IxMTogTmV3IFVT
QiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAg
WyAgIDkzLjEyNjI2OV0gdXNiIHVzYjExOiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxl
cg0KICBbICAgOTMuMTI2MjcwXSB1c2IgdXNiMTE6IE1hbnVmYWN0dXJlcjogTGludXggMy44
LjAtcmMwLTIwMTMwMjI3IHhoY2lfaGNkDQogIFsgICA5My4xMjYyNzFdIHVzYiB1c2IxMTog
U2VyaWFsTnVtYmVyOiAwMDAwOjA3OjAwLjANCiAgWyAgIDkzLjEyNjY2Nl0geEhDSSB4aGNp
X2FkZF9lbmRwb2ludCBjYWxsZWQgZm9yIHJvb3QgaHViDQogIFsgICA5My4xMjY2NjhdIHhI
Q0kgeGhjaV9jaGVja19iYW5kd2lkdGggY2FsbGVkIGZvciByb290IGh1Yg0KICBbICAgOTMu
MTI2ODMwXSBodWIgMTEtMDoxLjA6IFVTQiBodWIgZm91bmQNCiAgWyAgIDkzLjEyNjg1MV0g
aHViIDExLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQogIFsgICA5My4xMjY5OTldIHhoY2lf
aGNkIDAwMDA6MDc6MDAuMDogeEhDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkzLjEyNzM4
Nl0geGhjaV9oY2QgMDAwMDowNzowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3Np
Z25lZCBidXMgbnVtYmVyIDEyDQogIFsgICA5My4xMjc0NTVdIHVzYiB1c2IxMjogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzDQogIFsgICA5
My4xMjc0NTZdIHVzYiB1c2IxMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy
b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAgWyAgIDkzLjEyNzQ1N10gdXNiIHVzYjEyOiBQ
cm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTMuMTI3NDU5XSB1c2IgdXNi
MTI6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtcmMwLTIwMTMwMjI3IHhoY2lfaGNkDQog
IFsgICA5My4xMjc0NjBdIHVzYiB1c2IxMjogU2VyaWFsTnVtYmVyOiAwMDAwOjA3OjAwLjAN
CiAgWyAgIDkzLjEyNzg0Ml0geEhDSSB4aGNpX2FkZF9lbmRwb2ludCBjYWxsZWQgZm9yIHJv
b3QgaHViDQogIFsgICA5My4xMjc4NDNdIHhIQ0kgeGhjaV9jaGVja19iYW5kd2lkdGggY2Fs
bGVkIGZvciByb290IGh1Yg0KICBbICAgOTMuMTI3OTk3XSBodWIgMTItMDoxLjA6IFVTQiBo
dWIgZm91bmQNCiAgWyAgIDkzLjEyODAxMF0gaHViIDEyLTA6MS4wOiAyIHBvcnRzIGRldGVj
dGVkDQogIFsgICA5NC4xOTQ4NTZdIHVzYiA1LTU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6
IE1mcj0wLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wDQogIFsgICA5NC4yMjE0OTVdIHVz
YiA1LTU6IFByb2R1Y3Q6IEVEUkNsYXNzb25lDQogIFsgICA5NC4yNDE3ODBdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDQwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5NC4yNjM4
NjFdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NDANCiAgWyAgIDk0LjI4MDEzNl0geGhjaV9o
Y2QgMDAwMDowNDowMC4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQogIFsgICA5NC4zMDE1
ODRdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuMDogeEhDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAg
IDk0LjMyMjcwMF0geGhjaV9oY2QgMDAwMDowNDowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl
cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEzDQogIFsgICA5NC4zNTA2MThdIHhoY2lfaGNk
IDAwMDA6MDQ6MDAuMDogZW5hYmxpbmcgTWVtLVdyLUludmFsDQogIFsgICA5NC4zNjgwMzdd
IHVzYiA4LTM6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBvaGNp
X2hjZA0KICBbICAgOTQuMzk2Njc0XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjA6IGlycSA0MCwg
aW8gbWVtIDB4Zjk4ZmUwMDANCiAgWyAgIDk0LjQxOTc2NV0gdXNiIHVzYjEzOiBOZXcgVVNC
IGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINCiAgWyAgIDk0
LjQ0NTgxMF0gdXNiIHVzYjEzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJv
ZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KICBbICAgOTQuNDczMDc5XSB1c2IgdXNiMTM6IFBy
b2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5NC40OTMyODhdIHVzYiB1c2Ix
MzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcgeGhjaV9oY2QNCiAg
WyAgIDk0LjUxODI1OV0gdXNiIHVzYjEzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDQ6MDAuMA0K
ICBbICAgOTQuNTM4MDc1XSB4SENJIHhoY2lfYWRkX2VuZHBvaW50IGNhbGxlZCBmb3Igcm9v
dCBodWINCiAgWyAgIDk0LjU1ODg5OF0geEhDSSB4aGNpX2NoZWNrX2JhbmR3aWR0aCBjYWxs
ZWQgZm9yIHJvb3QgaHViDQogIFsgICA5NC41ODA4MjZdIGh1YiAxMy0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KICBbICAgOTQuNTk3ODc2XSBodWIgMTMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0
ZWQNCiAgWyAgIDk0LjYxNTczOV0geGhjaV9oY2QgMDAwMDowNDowMC4wOiB4SENJIEhvc3Qg
Q29udHJvbGxlcg0KICBbICAgOTQuNjM3MTk0XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjA6IG5l
dyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMTQNCiAgWyAgIDk0
LjY2NTI4NF0gdXNiIHVzYjE0OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDMNCiAgWyAgIDk0LjY5MTYxMF0gdXNiIHVzYjE0OiBOZXcgVVNC
IGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KICBb
ICAgOTQuNzE5MjAwXSB1c2IgdXNiMTQ6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVy
DQogIFsgICA5NC43Mzk2NTJdIHVzYiB1c2IxNDogTWFudWZhY3R1cmVyOiBMaW51eCAzLjgu
MC1yYzAtMjAxMzAyMjcgeGhjaV9oY2QNCiAgWyAgIDk0Ljc2NDg2N10gdXNiIHVzYjE0OiBT
ZXJpYWxOdW1iZXI6IDAwMDA6MDQ6MDAuMA0KICBbICAgOTQuNzg0NTQ1XSB1c2IgOC0zOiBO
ZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDQ2ZCwgaWRQcm9kdWN0PWM1MTcNCiAg
WyAgIDk0Ljc4NDg3NF0geEhDSSB4aGNpX2FkZF9lbmRwb2ludCBjYWxsZWQgZm9yIHJvb3Qg
aHViDQogIFsgICA5NC43ODQ4NzRdIHhIQ0kgeGhjaV9jaGVja19iYW5kd2lkdGggY2FsbGVk
IGZvciByb290IGh1Yg0KICBbICAgOTQuNzg1MDA0XSBodWIgMTQtMDoxLjA6IFVTQiBodWIg
Zm91bmQNCiAgWyAgIDk0Ljc4NTAxNF0gaHViIDE0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVk
DQogIFsgICA5NC44ODc0NjRdIHVzYiA4LTM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wDQogIFsgICA5NC45MTQ0MjddIHVzYiA4
LTM6IFByb2R1Y3Q6IFVTQiBSZWNlaXZlcg0KICBbICAgOTQuOTMyMTkzXSB1c2IgOC0zOiBN
YW51ZmFjdHVyZXI6IExvZ2l0ZWNoDQogIFsgICA5NC45NTA3NTJdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHANCiAgWyAgIDk0Ljk3MjgwM10gSW5p
dGlhbGl6aW5nIFVTQiBNYXNzIFN0b3JhZ2UgZHJpdmVyLi4uDQogIFsgICA5NC45OTMyODhd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UN
CiAgWyAgIDk1LjAxNjg4OV0gVVNCIE1hc3MgU3RvcmFnZSBzdXBwb3J0IHJlZ2lzdGVyZWQu
DQogIFsgICA5NS4wMzY3MTJdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgdXNic2VyaWFsDQogIFsgICA5NS4wNTgwMzVdIHVzYiAxMy0yOiBuZXcgbG93LXNw
ZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcgeGhjaV9oY2QNCiAgWyAgIDk1LjA4NTI5
NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjcDIxMHgNCiAg
WyAgIDk1LjEwNDMxOF0gdXNiIDEzLTI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xMGNmLCBpZFByb2R1Y3Q9NTUwMA0KICBbICAgOTUuMTA0MzE5XSB1c2IgMTMtMjogTmV3
IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTAN
CiAgWyAgIDk1LjEwNDMyMF0gdXNiIDEzLTI6IFByb2R1Y3Q6IFVTQiBLODA1NQ0KICBbICAg
OTUuMTA0MzIxXSB1c2IgMTMtMjogTWFudWZhY3R1cmVyOiBWZWxsZW1hbiANCiAgWyAgIDk1
LjEwNDgwOF0gdXNiIDEzLTI6IGVwIDB4ODEgLSByb3VuZGluZyBpbnRlcnZhbCB0byA2NCBt
aWNyb2ZyYW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzDQogIFsgICA5NS4xMDc2
MTNdIHVzYiAxMy0yOiBlcCAweDEgLSByb3VuZGluZyBpbnRlcnZhbCB0byA2NCBtaWNyb2Zy
YW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzDQogIFsgICA5NS4yNjEzNDVdIHVz
YnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIGNwMjEweA0KICBb
ICAgOTUuMjg1MzI4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IGN5cHJlc3NfbTgNCiAgWyAgIDk1LjMwOTI5NV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgRGVMb3JtZSBFYXJ0aG1hdGUgVVNCDQogIFsgICA5NS4z
MzcyNDZdIHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJ
RC0+Q09NIFJTMjMyIEFkYXB0ZXINCiAgWyAgIDk1LjM2NTQxN10gdXNic2VyaWFsOiBVU0Ig
U2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcg0K
ICBbICAgOTUuMzkzNTU4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIG1vczc3MjANCiAgWyAgIDk1LjQxNjc4MF0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCAyIHBvcnQgYWRhcHRlcg0KICBbICAgOTUu
NDQ1MDM3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc4
NDANCiAgWyAgIDk1LjQ2ODI2Ml0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVn
aXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNCIFNlcmlhbCBEcml2ZXINCiAgWyAg
IDk1LjUwMDQ3MF0gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9i
aW5nIHBvcnRzIGRpcmVjdGx5Lg0KICBbICAgOTUuNTI3ODE1XSBzZXJpbzogaTgwNDIgS0JE
IHBvcnQgYXQgMHg2MCwweDY0IGlycSAxDQogIFsgICA5NS41NDkwNjVdIHNlcmlvOiBpODA0
MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQogIFsgICA5NS41NzA3MDVdIG1vdXNl
ZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlDQogIFsgICA5NS41
OTQ0ODJdIHJ0Y19jbW9zIDAwOjAzOiBSVEMgY2FuIHdha2UgZnJvbSBTNA0KICBbICAgOTUu
NjE0ODg2XSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJlZ2lzdGVyZWQgcnRjX2Ntb3Mg
YXMgcnRjMA0KICBbICAgOTUuNjM5MjA0XSBydGNfY21vcyAwMDowMzogYWxhcm1zIHVwIHRv
IG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NCiAgWyAgIDk1LjY2NjMxMl0gQUNQ
SSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDBiMDAtMHgwMDAwMDAwMDAwMDAwYjA3IFN5c3Rl
bUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcU09SMSAxICgyMDEzMDExNy91dGFkZHJlc3Mt
MjUxKQ0KICBbICAgOTUuNzA2NTQxXSBBQ1BJOiBJZiBhbiBBQ1BJIGRyaXZlciBpcyBhdmFp
bGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVzZSBpdCBpbnN0ZWFkIG9mIHRo
ZSBuYXRpdmUgZHJpdmVyDQogIFsgICA5NS43NDQ5ODBdIGxpcmNfZGV2OiBJUiBSZW1vdGUg
Q29udHJvbCBkcml2ZXIgcmVnaXN0ZXJlZCwgbWFqb3IgMjQ4IA0KICBbICAgOTUuNzcwNzAw
XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuNzkwNjU5
XSBJUiBSQzUoeCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuODEx
MzYwXSBJUiBSQzYgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuODMx
MjI0XSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuODUw
OTU5XSBJUiBTb255IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNCiAgWyAgIDk1Ljg3
MDk2Ml0gSVIgUkM1IChzdHJlYW16YXApIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQN
CiAgWyAgIDk1Ljg5MzgyOV0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXpl
ZA0KICBbICAgOTUuOTE0MDkyXSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuOTM3NzI3XSBJUiBMSVJDIGJyaWRnZSBoYW5k
bGVyIGluaXRpYWxpemVkDQogIFsgICA5NS45NTcyMzVdIGN4MjU4MjE6IGRyaXZlciB2ZXJz
aW9uIDAuMC4xMDYgbG9hZGVkDQogIFsgICA5NS45Nzc4NDRdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDQ3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5Ni4wMDA4MjZdIHhlbjog
LS0+IHBpcnE9NDcgLT4gaXJxPTQ3IChnc2k9NDcpDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIxOjI4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweDky
IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDk2LjA0NzQxMV0gY3gyNTgyMTog
QXRoZW5hIHBjaSBlbmFibGUgIQ0KICBbICAgOTYuMDY1MzM1XSBjeDI1ODIxOiANCiAgWyAg
IDk2LjA2NTMzNV0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgWyAg
IDk2LjA5ODMxM10gY3gyNTgyMTogY3gyNTgyMSBzZXQgdXANCiAgWyAgIDk2LjExNDc1N10g
Y3gyNTgyMTogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgWyAgIDk2
LjExNDc1N10gDQogIFsgICA5Ni4xNDc2MTJdIGN4MjU4MjE6IEF0aGVuYSBIYXJkd2FyZSBk
ZXZpY2UgPSAweDgyMTANCiAgWyAgIDk2LjE2ODgzN10gY3gyNTgyMTogY3gyNTgyMVsxXTog
c3Vic3lzdGVtOiAwMDAwOjAwMDAsIGJvYXJkOiBDWDI1ODIxIFtjYXJkPTEsYXV0b2RldGVj
dGVkXQ0KICBbICAgOTYuNDIwNzQ0XSBjeDI1ODIxOiAoMSk6IGkyYyByZWdpc3RlciEgYnVz
LT5pMmNfcmMgPSAwDQogIFsgICA5Ni41MTk4ODVdIGN4MjU4MjE6IGN4MjU4MjFfZGV2X2No
ZWNrcmV2aXNpb24oKTogSGFyZHdhcmUgcmV2aXNpb24gPSAweDAwDQogIFsgICA5Ni41NDY2
MzRdIGN4MjU4MjE6ICgxKTogc2V0dXAgZG9uZSENCiAgWyAgIDk2LjU2Mzc4MF0gY3gyNTgy
MTogY3gyNTgyMVsxXS8wOiBmb3VuZCBhdCAwMDAwOjA2OjAwLjAsIHJldjogMCwgaXJxOiA0
NywgbGF0ZW5jeTogMCwgbW1pbzogMHhmOWEwMDAwMA0KICBbICAgOTYuNTk4OTI4XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHB2cnVzYjINCiAgWyAgIDk2
LjYyMjE1Ml0gcHZydXNiMjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYt
UFZSLVVTQjIgTVBFRzIgRW5jb2Rlci9UdW5lcg0KICBbICAgOTYuNjUyMDI5XSBwdnJ1c2Iy
OiBEZWJ1ZyBtYXNrIGlzIDMxICgweDFmKQ0KICBbICAgOTYuNjcxNTMzXSBmNzE4MDVmOiBV
bnN1cHBvcnRlZCBGaW50ZWsgZGV2aWNlLCBza2lwcGluZw0KICBbICAgOTYuNjkzOTM0XSBm
NzE4ODJmZzogRm91bmQgZjcxODg5ZWQgY2hpcCBhdCAweDYwMCwgcmV2aXNpb24gMTYNCiAg
WyAgIDk2LjcxODM1NV0gQUNQSSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDA2MDAtMHgwMDAw
MDAwMDAwMDAwNjA3IFN5c3RlbUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcSE1PUiAxICgy
MDEzMDExNy91dGFkZHJlc3MtMjUxKQ0KICBbICAgOTYuNzU4ODg4XSBBQ1BJOiBJZiBhbiBB
Q1BJIGRyaXZlciBpcyBhdmFpbGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVz
ZSBpdCBpbnN0ZWFkIG9mIHRoZSBuYXRpdmUgZHJpdmVyDQogIFsgICA5Ni43OTczMTRdIHNw
NTEwMF90Y286IFNQNTEwMC9TQjgwMCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjAz
DQogIFsgICA5Ni44MjM3MzFdIHNwNTEwMF90Y286IFBDSSBSZXZpc2lvbiBJRDogMHg0MQ0K
ICBbICAgOTYuODQzNTc0XSBzcDUxMDBfdGNvOiBVc2luZyAweGZlZDgwYjAwIGZvciB3YXRj
aGRvZyBNTUlPIGFkZHJlc3MNCiAgWyAgIDk2Ljg2ODc4N10gc3A1MTAwX3RjbzogTGFzdCBy
ZWJvb3Qgd2FzIG5vdCB0cmlnZ2VyZWQgYnkgd2F0Y2hkb2cuDQogIFsgICA5Ni44OTQzMjdd
IHNwNTEwMF90Y286IGluaXRpYWxpemVkICgweGZmZmZjOTAwMTAyZWFiMDApLiBoZWFydGJl
YXQ9NjAgc2VjIChub3dheW91dD0wLCBmb3JjZV9hZGRyPW5vbmUpDQogIFsgICA5Ni45Mjk1
MTVdIHhlbl93ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENCiAgWyAgIDk2
Ljk1MTYzM10geGVuX3dkdDogY2Fubm90IHJlZ2lzdGVyIG1pc2NkZXYgb24gbWlub3I9MTMw
ICgtMTYpDQogIFsgICA5Ni45NzYxODRdIHdkdDogcHJvYmUgb2Ygd2R0IGZhaWxlZCB3aXRo
IGVycm9yIC0xNg0KICBbICAgOTYuOTk4MzgwXSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4y
My4xLWlvY3RsICgyMDEyLTEyLTE4KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNv
bQ0KICBbICAgOTcuMDMwODk0XSBCbHVldG9vdGg6IFZpcnR1YWwgSENJIGRyaXZlciB2ZXIg
MS4zDQogIFsgICA5Ny4wNTIxNDZdIEJsdWV0b290aDogSENJIFVBUlQgZHJpdmVyIHZlciAy
LjINCiAgWyAgIDk3LjA3MjIyOV0gQmx1ZXRvb3RoOiBIQ0kgSDQgcHJvdG9jb2wgaW5pdGlh
bGl6ZWQNCiAgWyAgIDk3LjA5MzM0NF0gQmx1ZXRvb3RoOiBIQ0kgQkNTUCBwcm90b2NvbCBp
bml0aWFsaXplZA0KICBbICAgOTcuMTE0OTg0XSBCbHVldG9vdGg6IEhDSUxMIHByb3RvY29s
IGluaXRpYWxpemVkDQogIFsgICA5Ny4xMzU3ODZdIEJsdWV0b290aDogSENJQVRIM0sgcHJv
dG9jb2wgaW5pdGlhbGl6ZWQNCiAgWyAgIDk3LjE1NzI2OV0gQmx1ZXRvb3RoOiBIQ0kgVGhy
ZWUtd2lyZSBVQVJUIChINSkgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNCiAgWyAgIDk3LjE4MzI1
NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiY20yMDN4DQog
IFsgICA5Ny4yMDcyMjhdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgYnBhMTB4DQogIFsgICA5Ny4yMzA4NTBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgYmZ1c2INCiAgWyAgIDk3LjI1NDUxNl0gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBidHVzYg0KICBbICAgOTcuMjc3NjQ1XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGF0aDNrDQogIFsgICA5Ny4z
MDExMjJdIGhpZHJhdzogcmF3IEhJRCBldmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQ0K
ICBbICAgOTcuMzI5NzE4XSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZp
Y2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNi4wL3VzYjgvOC0zLzgtMzoxLjAvaW5wdXQvaW5w
dXQyDQogIFsgICA5Ny4zNjU5ODRdIGxvZ2l0ZWNoIDAwMDM6MDQ2RDpDNTE3LjAwMDE6IGlu
cHV0LGhpZHJhdzA6IFVTQiBISUQgdjEuMTAgS2V5Ym9hcmQgW0xvZ2l0ZWNoIFVTQiBSZWNl
aXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0zL2lucHV0MA0KICBbICAgOTcuNDE2MDAwXSBs
b2dpdGVjaCAwMDAzOjA0NkQ6QzUxNy4wMDAyOiBmaXhpbmcgdXAgTG9naXRlY2gga2V5Ym9h
cmQgcmVwb3J0IGRlc2NyaXB0b3INCiAgWyAgIDk3LjQ0NzM1MF0gaW5wdXQ6IExvZ2l0ZWNo
IFVTQiBSZWNlaXZlciBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTYuMC91c2I4
LzgtMy84LTM6MS4xL2lucHV0L2lucHV0Mw0KICBbICAgOTcuNDgzNzQ0XSBsb2dpdGVjaCAw
MDAzOjA0NkQ6QzUxNy4wMDAyOiBpbnB1dCxoaWRkZXYwLGhpZHJhdzE6IFVTQiBISUQgdjEu
MTAgTW91c2UgW0xvZ2l0ZWNoIFVTQiBSZWNlaXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0z
L2lucHV0MQ0KICBbICAgOTcuNTI3Nzk1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIHVzYmhpZA0KICBbICAgOTcuNTUxMTUwXSB1c2JoaWQ6IFVTQiBISUQg
Y29yZSBkcml2ZXINCiAgWyAgIDk3LjU3NDAwOV0geGVuOiByZWdpc3RlcmluZyBnc2kgMjIg
dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDk3LjU5NzQ4MV0geGVuOiAtLT4gcGly
cT0yMiAtPiBpcnE9MjIgKGdzaT0yMikNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjE6Mjld
IElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4OWEgLT4gSVJR
IDIyIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgOTcuNjQ5NDk2XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAzMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgOTcuNjczMDk3XSB4ZW46
IC0tPiBwaXJxPTMzIC0+IGlycT0zMyAoZ3NpPTMzKQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMToyOV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweGEy
IC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDk3LjcyNTE3MV0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWF1ZGlvDQogIFsgICA5
Ny43NTA4MTddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25k
LXVhMTAxDQogIFsgICA5Ny43NzUzMzZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgc25kLXVzYi11c3gyeQ0KICBbICAgOTcuODAwODY2XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItY2FpYXENCiAgWyAgIDk3
LjgyNjM4OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQt
dXNiLTZmaXJlDQogIFsgICA5Ny44NTE0ODNdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVU
TElOSyB2MC4zMC4NCiAgWyAgIDk3Ljg3MjA2M10gbmZubF9hY2N0OiByZWdpc3RlcmluZyB3
aXRoIG5mbmV0bGluay4NCiAgWyAgIDk3Ljg5Mjk1MF0gbmZfY29ubnRyYWNrIHZlcnNpb24g
MC41LjAgKDczMDMgYnVja2V0cywgMjkyMTIgbWF4KQ0KICBbICAgOTcuOTE4NDUxXSBjdG5l
dGxpbmsgdjAuOTM6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KICBbICAgOTcuOTQx
Nzg5XSB4dF90aW1lOiBrZXJuZWwgdGltZXpvbmUgaXMgLTAwMDANCiAgWyAgIDk3Ljk2MTQ1
Nl0gaXBfc2V0OiBwcm90b2NvbCA2DQogIFsgICA5Ny45NzcxNjNdIElQVlM6IFJlZ2lzdGVy
ZWQgcHJvdG9jb2xzICgpDQogIFsgICA5Ny45OTYwNjFdIElQVlM6IENvbm5lY3Rpb24gaGFz
aCB0YWJsZSBjb25maWd1cmVkIChzaXplPTQwOTYsIG1lbW9yeT02NEtieXRlcykNCiAgWyAg
IDk4LjAyNDcwM10gSVBWUzogQ3JlYXRpbmcgbmV0bnMgc2l6ZT0xOTA0IGlkPTANCiAgWyAg
IDk4LjA0NDg4NF0gSVBWUzogaXB2cyBsb2FkZWQuDQogIFsgICA5OC4wNjA1OTldIGlwX3Rh
YmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtDQogIFsgICA5OC4wODMw
ODddIFRDUDogY3ViaWMgcmVnaXN0ZXJlZA0KICBbICAgOTguMDk5NDQ2XSBORVQ6IFJlZ2lz
dGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3DQogIFsgICA5OC4xMTkyMDNdIEJyaWRnZSBmaXJl
d2FsbGluZyByZWdpc3RlcmVkDQogIFsgICA5OC4xMzc0OTVdIEVidGFibGVzIHYyLjAgcmVn
aXN0ZXJlZA0KICBbICAgOTguMTU0NDg1XSBCbHVldG9vdGg6IFJGQ09NTSBUVFkgbGF5ZXIg
aW5pdGlhbGl6ZWQNCiAgWyAgIDk4LjE3NTIzOF0gQmx1ZXRvb3RoOiBSRkNPTU0gc29ja2V0
IGxheWVyIGluaXRpYWxpemVkDQogIFsgICA5OC4xOTY3MjhdIEJsdWV0b290aDogUkZDT01N
IHZlciAxLjExDQogIFsgICA5OC4yMTM5NzZdIEJsdWV0b290aDogQk5FUCAoRXRoZXJuZXQg
RW11bGF0aW9uKSB2ZXIgMS4zDQogIFsgICA5OC4yMzU4MDRdIEJsdWV0b290aDogQk5FUCBm
aWx0ZXJzOiBwcm90b2NvbCBtdWx0aWNhc3QNCiAgWyAgIDk4LjI1NzIwNF0gQmx1ZXRvb3Ro
OiBCTkVQIHNvY2tldCBsYXllciBpbml0aWFsaXplZA0KICBbICAgOTguMjc3Njc1XSBCbHVl
dG9vdGg6IEhJRFAgKEh1bWFuIEludGVyZmFjZSBFbXVsYXRpb24pIHZlciAxLjINCiAgWyAg
IDk4LjMwMTAyMl0gQmx1ZXRvb3RoOiBISURQIHNvY2tldCBsYXllciBpbml0aWFsaXplZA0K
ICBbICAgOTguMzIxNDk2XSBLZXkgdHlwZSBjZXBoIHJlZ2lzdGVyZWQNCiAgWyAgIDk4LjMz
Nzc0OF0gbGliY2VwaDogbG9hZGVkIChtb24vb3NkIHByb3RvIDE1LzI0LCBvc2RtYXAgNS82
IDUvNikNCiAgWyAgIDk4LjM2MzMzOF0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAx
DQogIFsgICA5OC4zODIyNDZdIGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQNCiAgWyAgIDk4
LjM5ODU5NV0gbmV0Y29uc29sZTogbmV0d29yayBsb2dnaW5nIHN0YXJ0ZWQNCiAgWyAgIDk4
LjQxNzY3Nl0gQUxTQSBkZXZpY2UgbGlzdDoNCiAgWyAgIDk4LjQzMTgyMV0gICAjMDogQy1N
ZWRpYSBDTUk4NzM4IChtb2RlbCA1NSkgYXQgMHhhODAwLCBpcnEgMjINCiAgWyAgIDk4LjQ1
NDUzM10gICAjMTogSEQtQXVkaW8gR2VuZXJpYyBhdCAweGY5OWZjMDAwIGlycSAxMzcNCiAg
WyAgIDk4LjQ3NjU5N10gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTA2OGsgZnJl
ZWQNCiAgWyAgIDk4LjQ5NzMyM10gV3JpdGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQt
b25seSBkYXRhOiAxNDMzNmsNCiAgWyAgIDk4LjUyNjgwN10gRnJlZWluZyB1bnVzZWQga2Vy
bmVsIG1lbW9yeTogMjY4ayBmcmVlZA0KICBbICAgOTguNTQ3MzA4XSBGcmVlaW5nIHVudXNl
ZCBrZXJuZWwgbWVtb3J5OiAyMjBrIGZyZWVkDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjEzXSAqKiogU2VyaWFsIGlucHV0IC0+IFhlbiAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1l
cyB0byBzd2l0Y2ggaW5wdXQgdG8gRE9NMCkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjox
NV0gR3Vlc3QgaW50ZXJydXB0IGluZm9ybWF0aW9uOg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE1XSAgICBJUlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAgdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjE1XSAgICBJUlE6ICAgMSBhZmZpbml0eTowMSB2ZWM6MzAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDE0IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6
ICAxKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAgMiBh
ZmZpbml0eTozZiB2ZWM6ZTIgdHlwZT1YVC1QSUMgICAgICAgICAgc3RhdHVzPTAwMDAwMDAw
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6
ICAgMyBhZmZpbml0eTowMSB2ZWM6MzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAg
ICBJUlE6ICAgNCBhZmZpbml0eTowMSB2ZWM6ZjEgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh
dHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE1XSAgICBJUlE6ICAgNSBhZmZpbml0eTowMSB2ZWM6NDAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE1XSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElD
LWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1J
Ty1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAgOCBhZmZpbml0eTowMSB2ZWM6NTgg
dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6ICA4KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJ
UlE6ICAgOSBhZmZpbml0eTowMSB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICA5KC0tLS0pLA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxMCBhZmZpbml0eTowMSB2ZWM6Njgg
dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxMSBhZmZpbml0eTowMSB2
ZWM6NzAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxMiBhZmZpbml0
eTowMSB2ZWM6NzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZs
aWdodD0wIGRvbWFpbi1saXN0PTA6IDEyKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE1XSAgICBJUlE6ICAxMyBhZmZpbml0eTozZiB2ZWM6ODggdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNSBhZmZpbml0eTowMSB2ZWM6OTggdHlw
ZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNiBhZmZpbml0eTozZiB2ZWM6
ZDAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNyBhZmZpbml0eTow
MSB2ZWM6MjEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdo
dD0wIGRvbWFpbi1saXN0PTA6IDE3KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE2XSAgICBJUlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6ZDggdHlwZT1JTy1BUElDLWxldmVs
ICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDE4KC0tLS0p
LA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAxOSBhZmZpbml0eToz
ZiB2ZWM6YTkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAyMiBhZmZp
bml0eTowMSB2ZWM6OWEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICAyOSBhZmZpbml0eTowMSB2ZWM6MjkgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDI5
KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAzMCBhZmZp
bml0eTowMSB2ZWM6MzEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDMwKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICAzMSBhZmZpbml0eTowMSB2ZWM6MzkgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDMx
KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAzMiBhZmZp
bml0eTozZiB2ZWM6OTkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAz
MyBhZmZpbml0eTozZiB2ZWM6YTIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJ
UlE6ICA0MCBhZmZpbml0eTowMSB2ZWM6NDkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2
XSAgICBJUlE6ICA0NiBhZmZpbml0eTozZiB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE2XSAgICBJUlE6ICA0NyBhZmZpbml0eTowMSB2ZWM6OTIgdHlwZT1JTy1BUElDLWxl
dmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDQ3KC0t
LS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA0OCBhZmZpbml0
eTowMSB2ZWM6NDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1MSBh
ZmZpbml0eTozZiB2ZWM6YzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6
ICA1MiBhZmZpbml0eTozZiB2ZWM6YjggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAg
ICBJUlE6ICA1MyBhZmZpbml0eTozZiB2ZWM6YzAgdHlwZT1JTy1BUElDLWxldmVsICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE2XSAgICBJUlE6ICA1NCBhZmZpbml0eTozZiB2ZWM6YzggdHlwZT1JTy1BUElDLWxldmVs
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9N
TVUtTVNJICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1NyBhZmZpbml0eTozZiB2ZWM6YTAgdHlwZT1I
UEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1OCBhZmZpbml0eTozZiB2ZWM6YTgg
dHlwZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1OSBhZmZpbml0eTozZiB2
ZWM6YjAgdHlwZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2MCBhZmZpbml0
eTozZiB2ZWM6NTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2MSBh
ZmZpbml0eTozZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6
ICA2MiBhZmZpbml0eTozZiB2ZWM6NjEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAg
ICBJUlE6ICA2MyBhZmZpbml0eTozZiB2ZWM6NjkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE2XSAgICBJUlE6ICA2NCBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1QQ0ktTVNJICAgICAg
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICA2NSBhZmZpbml0eTozZiB2ZWM6NzkgdHlwZT1QQ0ktTVNJ
ICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6ODEgdHlwZT1Q
Q0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2NyBhZmZpbml0eTozZiB2ZWM6ODkg
dHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2OCBhZmZpbml0eTozZiB2
ZWM6OTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2OSBhZmZpbml0
eTozZiB2ZWM6YzEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA3MCBh
ZmZpbml0eTozZiB2ZWM6ZDEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6
ICA3MSBhZmZpbml0eTowMSB2ZWM6ZDkgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MzAwKC0tLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA3MiBhZmZpbml0eTowMSB2ZWM6MjIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjk5KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3MyBhZmZpbml0eTowMSB2ZWM6MmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk4KC0tLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA3NCBhZmZpbml0eTowMSB2ZWM6MzIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjk3KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3NSBhZmZpbml0eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk2KC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA3NiBhZmZpbml0eTowMSB2ZWM6NDIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjk1KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3NyBhZmZpbml0eTowMSB2ZWM6NGEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk0KC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA3OCBhZmZpbml0eTowMSB2ZWM6NTIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6MjkzKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3OSBhZmZpbml0eTowMSB2ZWM6NWEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA4MCBhZmZpbml0eTowMSB2ZWM6NjIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6MjkxKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA4MSBhZmZpbml0eTowMSB2ZWM6NmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkwKC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA4MiBhZmZpbml0eTowMSB2ZWM6NzIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjg5KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA4MyBhZmZpbml0eTowMSB2ZWM6N2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg4KC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA4NCBhZmZpbml0eTowMSB2ZWM6OGEgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjg3KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA4NSBhZmZpbml0eTowMSB2ZWM6YWEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg2KC0tLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSBJTy1BUElDIGludGVycnVwdCBpbmZvcm1hdGlvbjoNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgMCBWZWMyNDA6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICAyOiB2ZWM9ZjAg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1F
IG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElS
USAgMSBWZWMgNDg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMg
MHgwMCwgUGluICAxOiB2ZWM9MzAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoxN10gICAgIElSUSAgMyBWZWMgNTY6DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICAzOiB2ZWM9MzggZGVsaXZlcnk9TG9Q
cmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0
X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgNCBWZWMyNDE6
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA0
OiB2ZWM9ZjEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJy
PTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjox
N10gICAgIElSUSAgNSBWZWMgNjQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAg
ICAgIEFwaWMgMHgwMCwgUGluICA1OiB2ZWM9NDAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgNiBWZWMgNzI6DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA2OiB2ZWM9NDggZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1h
c2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAg
NyBWZWMgODA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgw
MCwgUGluICA3OiB2ZWM9NTAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFy
aXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoxN10gICAgIElSUSAgOCBWZWMgODg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA4OiB2ZWM9NTggZGVsaXZlcnk9TG9Qcmkg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lk
OjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgOSBWZWMgOTY6DQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA5OiB2
ZWM9NjAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10g
ICAgIElSUSAxMCBWZWMxMDQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAg
IEFwaWMgMHgwMCwgUGluIDEwOiB2ZWM9NjggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1
cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAxMSBWZWMxMTI6DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluIDExOiB2ZWM9NzAgZGVsaXZl
cnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9
MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAxMiBW
ZWMxMjA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMCwg
UGluIDEyOiB2ZWM9NzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5
PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoxOF0gICAgIElSUSAxMyBWZWMxMzY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MThdICAgICAgIEFwaWMgMHgwMCwgUGluIDEzOiB2ZWM9ODggZGVsaXZlcnk9TG9QcmkgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MSBkZXN0X2lkOjYz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICBJUlEgMTQgVmVjMTQ0Og0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNDogdmVj
PTkwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRy
aWc9RSBtYXNrPTAgZGVzdF9pZDoxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAg
ICBJUlEgMTUgVmVjMTUyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgICBB
cGljIDB4MDAsIFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MThdICAgICBJUlEgMTYgVmVjMjA4Og0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjE4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNjogdmVjPWQwIGRlbGl2ZXJ5
PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEg
ZGVzdF9pZDo2Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDE3IFZl
YyAzMzoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAwLCBQ
aW4gMTc6IHZlYz0yMSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE4XSAgICAgSVJRIDE4IFZlYzIxNjoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjox
OF0gICAgICAgQXBpYyAweDAwLCBQaW4gMTg6IHZlYz1kOCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDE5IFZlYzE2OToNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAwLCBQaW4gMTk6IHZlYz1h
OSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAg
IElSUSAyMiBWZWMxNTQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFw
aWMgMHgwMCwgUGluIDIyOiB2ZWM9OWEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAyOSBWZWMgNDE6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGluICA1OiB2ZWM9MjkgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBk
ZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAzMCBWZWMg
NDk6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGlu
ICA2OiB2ZWM9MzEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoxOF0gICAgIElSUSAzMSBWZWMgNTc6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThd
ICAgICAgIEFwaWMgMHgwMSwgUGluICA3OiB2ZWM9MzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAzMiBWZWMxNTM6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGluICA4OiB2ZWM9OTkg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICBJ
UlEgMzMgVmVjMTYyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgICBBcGlj
IDB4MDEsIFBpbiAgOTogdmVjPWEyIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDQwIFZlYyA3MzoNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAxLCBQaW4gMTY6IHZlYz00OSBkZWxpdmVyeT1M
b1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRl
c3RfaWQ6MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDQ2IFZlYzE4
NToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAxLCBQaW4g
MjI6IHZlYz1iOSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBp
cnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoxOF0gICAgIElSUSA0NyBWZWMxNDY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThd
ICAgICAgIEFwaWMgMHgwMSwgUGluIDIzOiB2ZWM9OTIgZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSA0OCBWZWMgNjU6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9NDEg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElS
USA1MSBWZWMyMDE6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMg
MHgwMSwgUGluIDI3OiB2ZWM9YzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MThdICAgICBJUlEgNTIgVmVjMTg0Og0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE4XSAgICAgICBBcGljIDB4MDEsIFBpbiAyODogdmVjPWI4IGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVz
dF9pZDo2Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDUzIFZlYzE5
MjoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAxLCBQaW4g
Mjk6IHZlYz1jMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBp
cnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoxOF0gICAgIElSUSA1NCBWZWMyMDA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTld
ICAgICAgIEFwaWMgMHgwMSwgUGluIDMwOiB2ZWM9YzggZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICdoJyBwcmVzc2VkIC0+IHNob3dpbmcgaW5z
dGFsbGVkIGhhbmRsZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJyUn
IChhc2NpaSAnMjUnKSA9PiB0cmFwIHRvIHhlbmRiZw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjIwXSAga2V5ICcqJyAoYXNjaWkgJzJhJykgPT4gcHJpbnQgYWxsIGRpYWdub3N0aWNz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJzAnIChhc2NpaSAnMzAnKSA9
PiBkdW1wIERvbTAgcmVnaXN0ZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBr
ZXkgJ0EnIChhc2NpaSAnNDEnKSA9PiB0b2dnbGUgYWx0ZXJuYXRpdmUga2V5IGhhbmRsaW5n
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ0gnIChhc2NpaSAnNDgnKSA9
PiBkdW1wIGhlYXAgaW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdJ
JyAoYXNjaWkgJzQ5JykgPT4gZHVtcCBIVk0gaXJxIGluZm8NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoyMF0gIGtleSAnTScgKGFzY2lpICc0ZCcpID0+IGR1bXAgTVNJIHN0YXRlDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ04nIChhc2NpaSAnNGUnKSA9PiB0
cmlnZ2VyIGFuIE5NSQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdPJyAo
YXNjaWkgJzRmJykgPT4gdG9nZ2xlIHNoYWRvdyBhdWRpdHMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoyMF0gIGtleSAnUScgKGFzY2lpICc1MScpID0+IGR1bXAgUENJIGRldmljZXMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMF0gIGtleSAnUicgKGFzY2lpICc1MicpID0+
IHJlYm9vdCBtYWNoaW5lDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ1Mn
IChhc2NpaSAnNTMnKSA9PiByZXNldCBzaGFkb3cgcGFnZXRhYmxlcw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjIwXSAga2V5ICdhJyAoYXNjaWkgJzYxJykgPT4gZHVtcCB0aW1lciBx
dWV1ZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMF0gIGtleSAnYycgKGFzY2lpICc2
MycpID0+IGR1bXAgQUNQSSBDeCBzdHJ1Y3R1cmVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MjBdICBrZXkgJ2QnIChhc2NpaSAnNjQnKSA9PiBkdW1wIHJlZ2lzdGVycw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdlJyAoYXNjaWkgJzY1JykgPT4gZHVtcCBl
dnRjaG4gaW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdnJyAoYXNj
aWkgJzY3JykgPT4gcHJpbnQgZ3JhbnQgdGFibGUgdXNhZ2UNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoyMF0gIGtleSAnaCcgKGFzY2lpICc2OCcpID0+IHNob3cgdGhpcyBtZXNzYWdl
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ2knIChhc2NpaSAnNjknKSA9
PiBkdW1wIGludGVycnVwdCBiaW5kaW5ncw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIw
XSAga2V5ICdtJyAoYXNjaWkgJzZkJykgPT4gbWVtb3J5IGluZm8NCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMF0gIGtleSAnbicgKGFzY2lpICc2ZScpID0+IE5NSSBzdGF0aXN0aWNz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ28nIChhc2NpaSAnNmYnKSA9
PiBkdW1wIGlvbW11IHAybSB0YWJsZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAg
a2V5ICdxJyAoYXNjaWkgJzcxJykgPT4gZHVtcCBkb21haW4gKGFuZCBndWVzdCBkZWJ1Zykg
aW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdyJyAoYXNjaWkgJzcy
JykgPT4gZHVtcCBydW4gcXVldWVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBr
ZXkgJ3MnIChhc2NpaSAnNzMnKSA9PiBkdW1wIHNvZnR0c2Mgc3RhdHMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjoyMF0gIGtleSAndCcgKGFzY2lpICc3NCcpID0+IGRpc3BsYXkgbXVs
dGktY3B1IGNsb2NrIGluZm8NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMF0gIGtleSAn
dScgKGFzY2lpICc3NScpID0+IGR1bXAgbnVtYSBpbmZvDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MjBdICBrZXkgJ3YnIChhc2NpaSAnNzYnKSA9PiBkdW1wIEFNRC1WIFZNQ0JzDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ3cnIChhc2NpaSAnNzcnKSA9PiBz
eW5jaHJvbm91c2x5IGR1bXAgY29uc29sZSByaW5nIGJ1ZmZlciAoZG1lc2cpDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ3onIChhc2NpaSAnN2EnKSA9PiBwcmludCBp
b2FwaWMgaW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSBudW1iZXIgb2YgTVAg
SVJRIHNvdXJjZXM6IDE1Lg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSBudW1iZXIg
b2YgSU8tQVBJQyAjNiByZWdpc3RlcnM6IDI0Lg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjIyXSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3RlcnM6IDMyLg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjIyXSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gSU8gQVBJQyAjNi4uLi4uLg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSAuLi4uIHJlZ2lzdGVyICMwMDogMDYwMDAw
MDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gLi4uLi4uLiAgICA6IHBoeXNpY2Fs
IEFQSUMgaWQ6IDA2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4uLi4gICAg
OiBEZWxpdmVyeSBUeXBlOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJd
IC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjIyXSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDE3DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVk
OiAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4uLi4gICAgIDogSU8gQVBJ
QyB2ZXJzaW9uOiAwMDIxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4gcmVn
aXN0ZXIgIzAyOiAwNjAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSAuLi4u
Li4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIy
XSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyMl0gLi4uLi4uLiAgICAgOiBCb290IERUICAgIDogMA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjIyXSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0
IERlbGkgVmVjdDogICANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDAwIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgMzANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDAyIDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyMl0gIDAzIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
MzgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA0IDAwMSAwMSAgMCAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
Ml0gIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAw
ICAgMCAgICAxICAgIDEgICAgNDgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA3
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyMl0gIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgNTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA5IDAwMSAw
MSAgMCAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNjANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNjgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDBiIDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyMl0gIDBjIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NzgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDBkIDAzRiAwRiAgMSAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
Ml0gIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAw
ICAgMCAgICAxICAgIDEgICAgOTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDEw
IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgRDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyMl0gIDExIDAwMSAwMSAgMCAgICAxICAgIDAgICAxICAgMCAg
ICAxICAgIDEgICAgMjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDEyIDAwMSAw
MSAgMCAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgRDgNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIDEzIDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAg
IDEgICAgQTkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDE0IDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE2IDAwMSAwMSAgMCAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgOUENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gSU8gQVBJQyAjNy4uLi4uLg0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjIzXSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoyM10gLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA3DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgOiBEZWxpdmVy
eSBUeXBlOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgOiBM
VFMgICAgICAgICAgOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4gcmVn
aXN0ZXIgIzAxOiAwMDFGODAyMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIzXSAuLi4u
Li4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDFGDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9u
OiAwMDIxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4gcmVnaXN0ZXIgIzAy
OiAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIzXSAuLi4uLi4uICAgICA6
IGFyYml0cmF0aW9uOiAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIzXSAuLi4uIElS
USByZWRpcmVjdGlvbiB0YWJsZToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIE5S
IExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDAx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDAyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDAzIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDA1IDAwMSAwMSAgMCAg
ICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgMjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDA2IDAwMSAwMSAgMCAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAg
MzENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDA3IDAwMSAwMSAgMCAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgMzkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDA4IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgOTkNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDA5IDAzRiAwRiAgMSAgICAxICAgIDAgICAx
ICAgMCAgICAxICAgIDEgICAgQTINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDBh
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDBiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDBjIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDBlIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDEwIDAwMSAwMSAgMSAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgNDkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDEz
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE1IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDE2IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAg
IDEgICAgQjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE3IDAwMSAwMSAgMCAg
ICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgOTINCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDE4IDAwMSAwMSAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAg
NDENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE5IDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDFhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDFiIDAzRiAwRiAgMSAgICAxICAgIDAgICAx
ICAgMCAgICAxICAgIDEgICAgQzkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDFj
IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgQjgNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDFkIDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAg
ICAxICAgIDEgICAgQzANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDFlIDAzRiAw
RiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgQzgNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gVXNpbmcgdmVjdG9yLWJh
c2VkIGluZGV4aW5nDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIElSUSB0byBwaW4g
bWFwcGluZ3M6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIElSUTI0MCAtPiAwOjIN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gSVJRNDggLT4gMDoxDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MjNdIElSUTU2IC0+IDA6Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjIzXSBJUlEyNDEgLT4gMDo0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIElS
UTY0IC0+IDA6NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlE3MiAtPiAwOjYN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRODAgLT4gMDo3DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MjRdIElSUTg4IC0+IDA6OA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjI0XSBJUlE5NiAtPiAwOjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJR
MTA0IC0+IDA6MTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMTEyIC0+IDA6
MTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMTIwIC0+IDA6MTINCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMTM2IC0+IDA6MTMNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyNF0gSVJRMTQ0IC0+IDA6MTQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyNF0gSVJRMTUyIC0+IDA6MTUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJR
MjA4IC0+IDA6MTYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMzMgLT4gMDox
Nw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlEyMTYgLT4gMDoxOA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlExNjkgLT4gMDoxOQ0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjI0XSBJUlExNTQgLT4gMDoyMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjI0XSBJUlE0MSAtPiAxOjUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRNDkg
LT4gMTo2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjRdIElSUTU3IC0+IDE6Nw0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlExNTMgLT4gMTo4DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MjRdIElSUTE2MiAtPiAxOjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyNF0gSVJRNzMgLT4gMToxNg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlEx
ODUgLT4gMToyMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlExNDYgLT4gMToy
Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlE2NSAtPiAxOjI0DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MjRdIElSUTIwMSAtPiAxOjI3DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MjRdIElSUTE4NCAtPiAxOjI4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MjRdIElSUTE5MiAtPiAxOjI5DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjRdIElSUTIw
MCAtPiAxOjMwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjRdIC4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25lLg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjI2XSBnbnR0YWJfdXNhZ2VfcHJpbnRfYWxsIFsga2V5ICdnJyBwcmVzc2VkDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MjZdICAgICAgIC0tLS0tLS0tIGFjdGl2ZSAtLS0tLS0tLSAg
ICAgICAtLS0tLS0tLSBzaGFyZWQgLS0tLS0tLS0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyNl0gW3JlZl0gbG9jYWxkb20gbWZuICAgICAgcGluICAgICAgICAgIGxvY2FsZG9tIGdt
Zm4gICAgIGZsYWdzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjZdIGdyYW50LXRhYmxl
IGZvciByZW1vdGUgZG9tYWluOiAgICAwIC4uLiBubyBhY3RpdmUgZ3JhbnQgdGFibGUgZW50
cmllcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI2XSBnbnR0YWJfdXNhZ2VfcHJpbnRf
YWxsIF0gZG9uZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI5XSAqKioqKioqKioqKiBW
TUNCIEFyZWFzICoqKioqKioqKioqKioqDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6Mjld
ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzJdIFBoeXNpY2FsIG1lbW9yeSBpbmZvcm1hdGlvbjoNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjozMl0gICAgIFhlbiBoZWFwOiAwa0IgZnJlZQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsxNF06IDY0NTEya0IgZnJlZQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsxNV06IDEzMTA3MmtCIGZyZWUNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozMl0gICAgIGhlYXBbMTZdOiAyNjIxNDRrQiBmcmVl
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzJdICAgICBoZWFwWzE3XTogNTI0Mjg4a0Ig
ZnJlZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsxOF06IDEwNDg1
NzZrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzJdICAgICBoZWFwWzE5XTog
NzgzMjg4a0IgZnJlZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsy
MF06IDQxOTQzMDRrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzJdICAgICBo
ZWFwWzIxXTogMjMyNDE2a0IgZnJlZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjMyXSAg
ICAgRG9tIGhlYXA6IDcyNDA2MDBrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzRdICcqJyBwcmVzc2VkIC0+IGZpcmluZyBhbGwgZGlhZ25vc3RpYyBrZXloYW5kbGVycw0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM0XSBbZDogZHVtcCByZWdpc3RlcnNdDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzRdICdkJyBwcmVzc2VkIC0+IGR1bXBpbmcgcmVnaXN0
ZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdIA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM0XSAqKiogRHVtcGluZyBDUFUwIGhvc3Qgc3RhdGU6ICoqKg0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM0XSAtLS0tWyBYZW4tNC4zLXVuc3RhYmxlICB4ODZfNjQgIGRl
YnVnPXkgIFRhaW50ZWQ6ICAgIEMgXS0tLS0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
NF0gQ1BVOiAgICAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdIFJJUDogICAgZTAw
ODpbPGZmZmY4MmM0YzAxNTk1Njc+XSBkZWZhdWx0X2lkbGUrMHg4Ni8weDhiDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzRdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIENPTlRF
WFQ6IGh5cGVydmlzb3INCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNF0gcmF4OiBmZmZm
ODJjNGMwMzExMGYwICAgcmJ4OiBmZmZmODJjNGMwMmI4MDAwICAgcmN4OiAwMDAwMDAwMDAw
MDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdIHJkeDogMDAwMDAwMDAwMDAw
MDAwMCAgIHJzaTogZmZmZjgyYzRjMDMxMWI4MCAgIHJkaTogMDAwMDAwMDAwMDAwMDAwMA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM0XSByYnA6IGZmZmY4MmM0YzAyYmZlZTAgICBy
c3A6IGZmZmY4MmM0YzAyYmZlZTAgICByODogIGZmZmY4MzAyNDdiY2MwYjgNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjozNF0gcjk6ICBmZmZmODMwMGFmZjg5MDYwICAgcjEwOiBmZmZm
ODMwMjQ3YmNhMjQwICAgcjExOiAwMDAwMDAyNjBhMzA4MTY3DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzRdIHIxMjogZmZmZjgyYzRjMDI2MjE4MCAgIHIxMzogZmZmZjgyYzRjMDJi
ODAwMCAgIHIxNDogMDAwMDAwMDBmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM0XSByMTU6IGZmZmY4MmM0YzAzMTEwNDggICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBj
cjQ6IDAwMDAwMDAwMDAwMDA2ZjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNF0gY3Iz
OiAwMDAwMDAwMjQxZTBjMDAwICAgY3IyOiAwMDAwN2ZhZTBjNmY2MDAwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MzRdIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdz
OiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM0XSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgyYzRjMDJiZmVlMDoNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNF0gICAgZmZmZjgyYzRjMDJiZmYxMCBmZmZmODJjNGMw
MTVjMzE0IDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDBhZmFmZTAwMA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM0XSAgICBmZmZmODMwMGFmZjg5MDAwIDAwMDAwMDAwMDAwMDAwMDAg
ZmZmZjgyYzRjMDJiZmQ3OCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzRdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWY5YTBjMCBmZmZmZmZm
ZjgxZWRhMWQ4IGZmZmZmZmZmODFlMDFlNzgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
NF0gICAgZmZmZmZmZmY4MWUwMDAxMCAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM0XSAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYSAwMDAw
MDAwMDAwMDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdICAgIDAwMDAwMDAw
ZGVhZGJlZWYgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDEwMDAwMDAwMDAwIGZmZmZmZmZmODEw
MDEzYWENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgMDAwMDAwMDAwMDAwZTAz
MyAwMDAwMDAwMDAwMDAwMjQ2IGZmZmZmZmZmODFlMDFlNjAgMDAwMDAwMDAwMDAwZTAyYg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDBhZmFm
ZTAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjozNV0gWGVuIGNhbGwgdHJhY2U6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MzVdICAgIFs8ZmZmZjgyYzRjMDE1OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4OGIN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgWzxmZmZmODJjNGMwMTVjMzE0Pl0g
aWRsZV9sb29wKzB4NjUvMHg3Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gKioqIER1bXBpbmcgQ1BVMSBob3N0IHN0
YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gLS0tLVsgWGVuLTQuMy11
bnN0YWJsZSAgeDg2XzY0ICBkZWJ1Zz15ICBUYWludGVkOiAgICBDIF0tLS0tDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzVdIENQVTogICAgMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM1XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9pZGxl
KzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBSRkxBR1M6IDAwMDAw
MDAwMDAwMDAyNDYgICBDT05URVhUOiBoeXBlcnZpc29yDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzVdIHJheDogZmZmZjgyYzRjMDMxMTBmMCAgIHJieDogZmZmZjgzMDI0N2JmMDAw
MCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1
XSByZHg6IDAwMDAwMDNkODc4ZWQwMDAgICByc2k6IGZmZmY4MzAyNDdiZmViODAgICByZGk6
IDAwMDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gcmJwOiBm
ZmZmODMwMjQ3YmY3ZWUwICAgcnNwOiBmZmZmODMwMjQ3YmY3ZWUwICAgcjg6ICBmZmZmODMw
MjQ3YmQ1YmQ4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdIHI5OiAgZmZmZjgzMDBh
ZmY4ODA2MCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAwMDAwMDAwMDI0
Ng0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSByMTI6IGZmZmY4MmM0YzAyNjIxODAg
ICByMTM6IGZmZmY4MzAyNDdiZjAwMDAgICByMTQ6IDAwMDAwMDAwZmZmZmZmZmYNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNV0gcjE1OiBmZmZmODMwMjQ3YmZlMDQ4ICAgY3IwOiAw
MDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzVdIGNyMzogMDAwMDAwMDIzZDhjZTAwMCAgIGNyMjogMDAwMDdmN2Ey
NTZkZDgyMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBkczogMDAyYiAgIGVzOiAw
MDJiICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDEwICAgY3M6IGUwMDgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNV0gWGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4
MzAyNDdiZjdlZTA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIGZmZmY4MzAy
NDdiZjdmMTAgZmZmZjgyYzRjMDE1YzMxNCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAwYWZk
MTMwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgZmZmZjgzMDBhZmY4ODAw
MCAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4MzAyNDdiZjdkNzggMDAwMDAwMDAwMDAwMDAwMA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgZmZmZmZmZmY4MWVkYTFkOCBmZmZmODgwMDNhMjMxZjEwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIGZmZmY4ODAwM2EyMzAwMTAgMDAwMDAwMDAwMDAw
MDI0NiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjozNV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmZmZmZmODEwMDEzYWEgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM1XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAxMDAw
MDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVd
ICAgIDAwMDAwMDAwMDAwMGUwMzMgMDAwMDAwMDAwMDAwMDI0NiBmZmZmODgwMDNhMjMxZWY4
IDAwMDAwMDAwMDAwMGUwMmINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgMzgz
MjNhMzAzNDNhMzAzMSAzYTM1MzE0ZDU2NDgyMDVkIDYxNmY0YzIwNGQ1NjQ4MjAgNGU0NTU4
MjgwYTcyNjU2NA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAyZDMzMzEzMDAw
MDAwMDAxIGZmZmY4MzAwYWZkMTMwMDAgMDAwMDAwM2Q4NzhlZDAwMCA0NDIwM2EzNTMxNGQ1
NjQ4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdIFhlbiBjYWxsIHRyYWNlOg0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICBbPGZmZmY4MmM0YzAxNTk1Njc+XSBkZWZh
dWx0X2lkbGUrMHg4Ni8weDhiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIFs8
ZmZmZjgyYzRjMDE1YzMxND5dIGlkbGVfbG9vcCsweDY1LzB4NzMNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjozNV0gICAgDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdICoqKiBE
dW1waW5nIENQVTIgaG9zdCBzdGF0ZTogKioqDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzVdIC0tLS1bIFhlbi00LjMtdW5zdGFibGUgIHg4Nl82NCAgZGVidWc9eSAgVGFpbnRlZDog
ICAgQyBdLS0tLQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBDUFU6ICAgIDINCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzRjMDE1
OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4OGINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNV0gUkZMQUdTOiAwMDAwMDAwMDAwMDAwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSByYXg6IGZmZmY4MmM0YzAzMTEwZjAgICBy
Yng6IGZmZmY4MzAyNDdiZTAwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDINCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjozNV0gcmR4OiAwMDAwMDAzZDg3OGRlMDAwICAgcnNpOiBmZmZm
ODMwMjQ3YmVmYjgwICAgcmRpOiAwMDAwMDAwMDAwMDAwMDAyDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzVdIHJicDogZmZmZjgzMDI0N2JlN2VlMCAgIHJzcDogZmZmZjgzMDI0N2Jl
N2VlMCAgIHI4OiAgZmZmZjgzMDI0N2JlZTAyOA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM1XSByOTogIGZmZmY4MzAwYWZkMTcwNjAgICByMTA6IDAwMDAwMDAwZGVhZGJlZWYgICBy
MTE6IDAwMDAwMDAwMDAwMDAyNDYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gcjEy
OiBmZmZmODJjNGMwMjYyMTgwICAgcjEzOiBmZmZmODMwMjQ3YmUwMDAwICAgcjE0OiAwMDAw
MDAwMGZmZmZmZmZmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdIHIxNTogZmZmZjgz
MDI0N2JlZjA0OCAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAw
MDZmMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBjcjM6IDAwMDAwMDAyNDFlMGMw
MDAgICBjcjI6IDAwMDAwMDAwMDAyMGRiZjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
Nl0gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAx
MCAgIGNzOiBlMDA4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIFhlbiBzdGFjayB0
cmFjZSBmcm9tIHJzcD1mZmZmODMwMjQ3YmU3ZWUwOg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM2XSAgICBmZmZmODMwMjQ3YmU3ZjEwIGZmZmY4MmM0YzAxNWMzMTQgMDAwMDAwMDAw
MDAwMDAwMCBmZmZmODMwMGFmZDEyMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZd
ICAgIGZmZmY4MzAwYWZkMTcwMDAgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODMwMjQ3YmU3ZDc4
IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlZGExZDggZmZmZjg4
MDAzYTIzM2YxMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAgICBmZmZmODgwMDNh
MjMyMDEwIDAwMDAwMDAwMDAwMDAyNDYgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhIDAwMDAwMDAwMDAwMDAwMDENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDAw
MGRlYWRiZWVmIDAwMDAwMTAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM2XSAgICAwMDAwMDAwMDAwMDBlMDMzIDAwMDAwMDAwMDAwMDAy
NDYgZmZmZjg4MDAzYTIzM2VmOCAwMDAwMDAwMDAwMDBlMDJiDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDBiMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNl0gICAgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODMwMGFmZDEyMDAwIDAwMDAwMDNkODc4
ZGUwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSBY
ZW4gY2FsbCB0cmFjZToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgWzxmZmZm
ODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9pZGxlKzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjM2XSAgICBbPGZmZmY4MmM0YzAxNWMzMTQ+XSBpZGxlX2xvb3ArMHg2NS8w
eDczDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjM2XSAqKiogRHVtcGluZyBDUFUzIGhvc3Qgc3RhdGU6ICoqKg0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM2XSAtLS0tWyBYZW4tNC4zLXVuc3RhYmxlICB4ODZfNjQg
IGRlYnVnPXkgIFRhaW50ZWQ6ICAgIEMgXS0tLS0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNl0gQ1BVOiAgICAzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIFJJUDogICAg
ZTAwODpbPGZmZmY4MmM0YzAxNTk1Njc+XSBkZWZhdWx0X2lkbGUrMHg4Ni8weDhiDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIENP
TlRFWFQ6IGh5cGVydmlzb3INCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gcmF4OiBm
ZmZmODJjNGMwMzExMGYwICAgcmJ4OiBmZmZmODMwMjQ3Yjc4MDAwICAgcmN4OiAwMDAwMDAw
MDAwMDAwMDAzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIHJkeDogMDAwMDAwM2Q4
NzhkNzAwMCAgIHJzaTogZmZmZjgzMDI0N2JlOGI4MCAgIHJkaTogMDAwMDAwMDAwMDAwMDAw
Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSByYnA6IGZmZmY4MzAyNDdiN2ZlZTAg
ICByc3A6IGZmZmY4MzAyNDdiN2ZlZTAgICByODogIGZmZmY4MzAyNDdiZWU0MTgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNl0gcjk6ICBmZmZmODMwMGFmZDE2MDYwICAgcjEwOiAw
MDAwMDAwMGRlYWRiZWVmICAgcjExOiAwMDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzZdIHIxMjogZmZmZjgyYzRjMDI2MjE4MCAgIHIxMzogZmZmZjgzMDI0
N2I3ODAwMCAgIHIxNDogMDAwMDAwMDBmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM2XSByMTU6IGZmZmY4MzAyNDdiZTgwNDggICBjcjA6IDAwMDAwMDAwODAwNTAwM2Ig
ICBjcjQ6IDAwMDAwMDAwMDAwMDA2ZjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0g
Y3IzOiAwMDAwMDAwMjQxZTBjMDAwICAgY3IyOiAwMDAwN2ZhZTBjNmY2MDAwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzZdIGRzOiAwMDJiICAgZXM6IDAwMmIgICBmczogMDAwMCAg
IGdzOiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM2XSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDI0N2I3ZmVlMDoNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgZmZmZjgzMDI0N2I3ZmYxMCBmZmZmODJj
NGMwMTVjMzE0IDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDBhZmFmZDAwMA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM2XSAgICBmZmZmODMwMGFmZDE2MDAwIDAwMDAwMDAwMDAwMDAw
MDMgZmZmZjgzMDI0N2I3ZmQ3OCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZm
ZmZmZjgxZWRhMWQ4IGZmZmY4ODAwM2EyMzVmMTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNl0gICAgZmZmZjg4MDAzYTIzNDAxMCAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAg
ICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYSAw
MDAwMDAwMDAwMDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIDAwMDAw
MDAwZGVhZGJlZWYgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDEwMDAwMDAwMDAwIGZmZmZmZmZm
ODEwMDEzYWENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgMDAwMDAwMDAwMDAw
ZTAzMyAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4ODAwM2EyMzVlZjggMDAwMDAwMDAwMDAwZTAy
Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDMgZmZmZjgzMDBh
ZmFmZDAwMCAwMDAwMDAzZDg3OGQ3MDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozNl0gWGVuIGNhbGwgdHJhY2U6DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzZdICAgIFs8ZmZmZjgyYzRjMDE1OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4
OGINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgWzxmZmZmODJjNGMwMTVjMzE0
Pl0gaWRsZV9sb29wKzB4NjUvMHg3Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAg
ICANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gKioqIER1bXBpbmcgQ1BVNCBob3N0
IHN0YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gLS0tLVsgWGVuLTQu
My11bnN0YWJsZSAgeDg2XzY0ICBkZWJ1Zz15ICBUYWludGVkOiAgICBDIF0tLS0tDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIENQVTogICAgNA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM2XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9p
ZGxlKzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBSRkxBR1M6IDAw
MDAwMDAwMDAwMDAyNDYgICBDT05URVhUOiBoeXBlcnZpc29yDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzddIHJheDogZmZmZjgyYzRjMDMxMTBmMCAgIHJieDogZmZmZjgzMDI0N2I2
ODAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwNA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM3XSByZHg6IDAwMDAwMDNkODc4NjEwMDAgICByc2k6IGZmZmY4MzAyNDdiNzJiODAgICBy
ZGk6IDAwMDAwMDAwMDAwMDAwMDQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gcmJw
OiBmZmZmODMwMjQ3YjZmZWUwICAgcnNwOiBmZmZmODMwMjQ3YjZmZWUwICAgcjg6ICBmZmZm
ODMwMjQ3YmVlODQ4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIHI5OiAgZmZmZjgz
MDBhZmQxNTA2MCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAwMDAwMDAw
MDI0Ng0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSByMTI6IGZmZmY4MmM0YzAyNjIx
ODAgICByMTM6IGZmZmY4MzAyNDdiNjgwMDAgICByMTQ6IDAwMDAwMDAwZmZmZmZmZmYNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gcjE1OiBmZmZmODMwMjQ3YjcyMDQ4ICAgY3Iw
OiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MzddIGNyMzogMDAwMDAwMDI0MWUwYzAwMCAgIGNyMjogMDAwMDAw
MDAwMDIwZGJmMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBkczogMDAyYiAgIGVz
OiAwMDJiICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDEwICAgY3M6IGUwMDgNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gWGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZm
ZmY4MzAyNDdiNmZlZTA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAgIGZmZmY4
MzAyNDdiNmZmMTAgZmZmZjgyYzRjMDE1YzMxNCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAw
YWZhZmMwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAgZmZmZjgzMDBhZmQx
NTAwMCAwMDAwMDAwMDAwMDAwMDA0IGZmZmY4MzAyNDdiNmZkNzggMDAwMDAwMDAwMDAwMDAw
MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWVkYTFkOCBmZmZmODgwMDNhMjM3ZjEwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAgIGZmZmY4ODAwM2EyMzYwMTAgMDAwMDAwMDAw
MDAwMDI0NiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozN10gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IGZmZmZmZmZmODEwMDEzYWEgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM3XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAx
MDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzddICAgIDAwMDAwMDAwMDAwMGUwMzMgMDAwMDAwMDAwMDAwMDI0NiBmZmZmODgwMDNhMjM3
ZWY4IDAwMDAwMDAwMDAwMGUwMmINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICAwMDAwMDAw
MDAwMDAwMDA0IGZmZmY4MzAwYWZhZmMwMDAgMDAwMDAwM2Q4Nzg2MTAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIFhlbiBjYWxsIHRyYWNlOg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICBbPGZmZmY4MmM0YzAxNTk1Njc+XSBk
ZWZhdWx0X2lkbGUrMHg4Ni8weDhiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAg
IFs8ZmZmZjgyYzRjMDE1YzMxND5dIGlkbGVfbG9vcCsweDY1LzB4NzMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozN10gICAgDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICoq
KiBEdW1waW5nIENQVTUgaG9zdCBzdGF0ZTogKioqDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MzddIC0tLS1bIFhlbi00LjMtdW5zdGFibGUgIHg4Nl82NCAgZGVidWc9eSAgVGFpbnRl
ZDogICAgQyBdLS0tLQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBDUFU6ICAgIDUN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzRj
MDE1OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4OGINCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozN10gUkZMQUdTOiAwMDAwMDAwMDAwMDAwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNv
cg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSByYXg6IGZmZmY4MmM0YzAzMTEwZjAg
ICByYng6IGZmZmY4MzAyNDdiNTgwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDUNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozN10gcmR4OiAwMDAwMDAzZDg3ODUzMDAwICAgcnNpOiBm
ZmZmODMwMjQ3YjY0YjgwICAgcmRpOiAwMDAwMDAwMDAwMDAwMDA1DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzddIHJicDogZmZmZjgzMDI0N2I1ZmVlMCAgIHJzcDogZmZmZjgzMDI0
N2I1ZmVlMCAgIHI4OiAgZmZmZjgzMDI0N2JlZWM3OA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM3XSByOTogIGZmZmY4MzAwYWZkMTQwNjAgICByMTA6IDAwMDAwMDAwZGVhZGJlZWYg
ICByMTE6IDAwMDAwMDAwMDAwMDAyNDYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10g
cjEyOiBmZmZmODJjNGMwMjYyMTgwICAgcjEzOiBmZmZmODMwMjQ3YjU4MDAwICAgcjE0OiAw
MDAwMDAwMGZmZmZmZmZmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIHIxNTogZmZm
ZjgzMDI0N2I2NDA0OCAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAw
MDAwMDZmMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBjcjM6IDAwMDAwMDAyNGY1
YmUwMDAgICBjcjI6IGZmZmY4ODAwMzg0MGQ0NjgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozN10gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczog
ZTAxMCAgIGNzOiBlMDA4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIFhlbiBzdGFj
ayB0cmFjZSBmcm9tIHJzcD1mZmZmODMwMjQ3YjVmZWUwOg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM3XSAgICBmZmZmODMwMjQ3YjVmZjEwIGZmZmY4MmM0YzAxNWMzMTQgMDAwMDAw
MDAwMDAwMDAwMCBmZmZmODMwMGFmZjhiMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzddICAgIGZmZmY4MzAwYWZkMTQwMDAgMDAwMDAwMDAwMDAwMDAwNSBmZmZmODMwMjQ3YjVm
ZDc4IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlZGExZDggZmZm
Zjg4MDAzYTI0MWYxMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICBmZmZmODgw
MDNhMjQwMDEwIDAwMDAwMDAwMDAwMDAyNDYgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhIDAwMDAwMDAwMDAwMDAwMDEN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAgMDAwMDAwMDBkZWFkYmVlZiAwMDAw
MDAwMGRlYWRiZWVmIDAwMDAwMTAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICAwMDAwMDAwMDAwMDBlMDMzIDAwMDAwMDAwMDAw
MDAyNDYgZmZmZjg4MDAzYTI0MWVmOCAwMDAwMDAwMDAwMDBlMDJiDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzhdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOF0gICAgMDAwMDAwMDAwMDAwMDAwNSBmZmZmODMwMGFmZjhiMDAwIDAwMDAwMDNk
ODc4NTMwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4
XSBYZW4gY2FsbCB0cmFjZToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAgWzxm
ZmZmODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9pZGxlKzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM4XSAgICBbPGZmZmY4MmM0YzAxNWMzMTQ+XSBpZGxlX2xvb3ArMHg2
NS8weDczDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICAgIA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM4XSBbMDogZHVtcCBEb20wIHJlZ2lzdGVyc10NCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozOF0gJzAnIHByZXNzZWQgLT4gZHVtcGluZyBEb20wJ3MgcmVnaXN0
ZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICoqKiBEdW1waW5nIERvbTAgdmNw
dSMwIHN0YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gUklQOiAgICBl
MDMzOls8ZmZmZmZmZmY4MTAwMTNhYT5dDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6Mzhd
IFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIEVNOiAwICAgQ09OVEVYVDogcHYgZ3Vlc3QN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAg
cmJ4OiBmZmZmZmZmZjgxZTAwMDEwICAgcmN4OiBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzhdIHJkeDogMDAwMDAwMDAwMDAwMDAwMSAgIHJzaTogMDAw
MDAwMDBkZWFkYmVlZiAgIHJkaTogMDAwMDAwMDBkZWFkYmVlZg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjM4XSByYnA6IGZmZmZmZmZmODFlMDFlNzggICByc3A6IGZmZmZmZmZmODFl
MDFlNjAgICByODogIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozOF0gcjk6ICAwMDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAg
cjExOiAwMDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdIHIx
MjogZmZmZmZmZmY4MWVkYTFkOCAgIHIxMzogZmZmZmZmZmY4MWY5YTBjMCAgIHIxNDogMDAw
MDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSByMTU6IDAwMDAw
MDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwMDAwMDAwMDggICBjcjQ6IDAwMDAwMDAwMDAw
MDA2NjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gY3IzOiAwMDAwMDAwMjQxZTBj
MDAwICAgY3IyOiAwMDAwN2ZhZTBjNmY2MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzhdIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUw
MmIgICBjczogZTAzMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSBHdWVzdCBzdGFj
ayB0cmFjZSBmcm9tIHJzcD1mZmZmZmZmZjgxZTAxZTYwOg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM4XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MTAwOGNlMCBmZmZmZmZmZjgxZTAxZTg4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzhdICAgIGZmZmZmZmZmODEwMTZmOWIgZmZmZmZmZmY4MWUwMWVhOCBmZmZmZmZmZjgxMDE3
MzU2IDAwMDAwMDAwMDAwMDAwMDINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAg
ZmZmZmZmZmY4MWY5MTk0MCBmZmZmZmZmZjgxZTAxZWQ4IGZmZmZmZmZmODE5OWY1YWMgZmZm
ZmZmZmY4MTk5ZjRmMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICBmZmZmZmZm
ZjgxZjkxOTQwIGZmZmZmZmZmODFlMDFlZDggZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZjgx
ZTAxZjI4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICAgIGZmZmZmZmZmODFmMDEx
MWIgZmZmZmZmZmY4MWYwMGI3ZiBmZmZmZmZmZjgyOTU0MDAwIGZmZmZmZmZmODI5NTUwMDAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAgZmZmZmZmZmY4MWY5YTBjMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFl
MDFmMzggZmZmZmZmZmY4MWYwMDNkNyBmZmZmZmZmZjgxZTAxZmY4DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzhdICAgIGZmZmZmZmZmODFmMDNmMGEgMDMwMDAwMDEwMDAwMDAzMiAw
MDAwMDAwMDAwMDAwMDA1IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4
XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgODA4MDIwMDExNzg5
YzNmNQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICAwMDEwMGZhMDAwMDYwODAw
IDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICoqKiBEdW1waW5nIERvbTAgdmNwdSMxIHN0
YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gUklQOiAgICBlMDMzOls8
ZmZmZmZmZmY4MTAwMTNhYT5dDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdIFJGTEFH
UzogMDAwMDAwMDAwMDAwMDI0NiAgIEVNOiAwICAgQ09OVEVYVDogcHYgZ3Vlc3QNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozOF0gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiBm
ZmZmODgwMDNhMjMwMDEwICAgcmN4OiBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzhdIHJkeDogMDAwMDAwMDAwMDAwMDAwMSAgIHJzaTogMDAwMDAwMDBk
ZWFkYmVlZiAgIHJkaTogMDAwMDAwMDBkZWFkYmVlZg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM4XSByYnA6IGZmZmY4ODAwM2EyMzFmMTAgICByc3A6IGZmZmY4ODAwM2EyMzFlZjgg
ICByODogIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0g
cjk6ICAwMDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAgcjExOiAw
MDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdIHIxMjogZmZm
ZmZmZmY4MWVkYTFkOCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogMDAwMDAwMDAw
MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSByMTU6IDAwMDAwMDAwMDAw
MDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDA2NjAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gY3IzOiAwMDAwMDAwMjNkOGNlMDAwICAg
Y3IyOiAwMDAwN2Y3YTI1NmRkODIwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldIGRz
OiAwMDJiICAgZXM6IDAwMmIgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMmIgICBj
czogZTAzMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSBHdWVzdCBzdGFjayB0cmFj
ZSBmcm9tIHJzcD1mZmZmODgwMDNhMjMxZWY4Og0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM5XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAw
OGNlMCBmZmZmODgwMDNhMjMxZjIwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAg
IGZmZmZmZmZmODEwMTZmOWIgZmZmZjg4MDAzYTIzMWY0MCBmZmZmZmZmZjgxMDE3MzU2IDAw
MDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAw
MDAwMDAwMDAwMCBmZmZmODgwMDNhMjMxZjUwIGZmZmZmZmZmODE5YTRiZmEgMDAwMDAwMDAw
MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM5XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZmZmZmDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAxMCAwMDAwMDAw
MDAwMDAwMjAyIGZmZmY4ODAwM2EyMzFmNTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
OV0gICAgMDAwMDAwMDAwMDAwMDAxOA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSAq
KiogRHVtcGluZyBEb20wIHZjcHUjMiBzdGF0ZTogKioqDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzldIFJJUDogICAgZTAzMzpbPGZmZmZmZmZmODEwMDEzYWE+XQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM5XSBSRkxBR1M6IDAwMDAwMDAwMDAwMDAyNDYgICBFTTogMCAg
IENPTlRFWFQ6IHB2IGd1ZXN0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldIHJheDog
MDAwMDAwMDAwMDAwMDAwMCAgIHJieDogZmZmZjg4MDAzYTIzMjAxMCAgIHJjeDogZmZmZmZm
ZmY4MTAwMTNhYQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSByZHg6IDAwMDAwMDAw
MDAwMDAwMDEgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYgICByZGk6IDAwMDAwMDAwZGVhZGJl
ZWYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gcmJwOiBmZmZmODgwMDNhMjMzZjEw
ICAgcnNwOiBmZmZmODgwMDNhMjMzZWY4ICAgcjg6ICAwMDAwMDAwMDAwMDAwMDAwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzldIHI5OiAgMDAwMDAwMDAwMDAwMDAwMSAgIHIxMDog
MDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDI0Ng0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM5XSByMTI6IGZmZmZmZmZmODFlZGExZDggICByMTM6IDAwMDAwMDAw
MDAwMDAwMDAgICByMTQ6IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOV0gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNi
ICAgY3I0OiAwMDAwMDAwMDAwMDAwNjYwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6Mzld
IGNyMzogMDAwMDAwMDI0MWUwYzAwMCAgIGNyMjogMDAwMDAwMDAwMDIwZGJmMQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM5XSBkczogMDAyYiAgIGVzOiAwMDJiICAgZnM6IDAwMDAg
ICBnczogMDAwMCAgIHNzOiBlMDJiICAgY3M6IGUwMzMNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOV0gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjg4MDAzYTIzM2VmODoN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDhjZTAgZmZmZjg4MDAzYTIzM2YyMA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM5XSAgICBmZmZmZmZmZjgxMDE2ZjliIGZmZmY4ODAwM2Ey
MzNmNDAgZmZmZmZmZmY4MTAxNzM1NiAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAzYTIzM2Y1MCBm
ZmZmZmZmZjgxOWE0YmZhIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5
XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmZmZmZm
ZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMTAgMDAwMDAwMDAwMDAwMDIwMiBmZmZmODgwMDNhMjMzZjU4DQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMTgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozOV0gKioqIER1bXBpbmcgRG9tMCB2Y3B1IzMgc3RhdGU6
ICoqKg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSBSSVA6ICAgIGUwMzM6WzxmZmZm
ZmZmZjgxMDAxM2FhPl0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gUkZMQUdTOiAw
MDAwMDAwMDAwMDAwMjQ2ICAgRU06IDAgICBDT05URVhUOiBwdiBndWVzdA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM5XSByYXg6IDAwMDAwMDAwMDAwMDAwMDAgICByYng6IGZmZmY4
ODAwM2EyMzQwMTAgICByY3g6IGZmZmZmZmZmODEwMDEzYWENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjozOV0gcmR4OiAwMDAwMDAwMDAwMDAwMDAxICAgcnNpOiAwMDAwMDAwMGRlYWRi
ZWVmICAgcmRpOiAwMDAwMDAwMGRlYWRiZWVmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzldIHJicDogZmZmZjg4MDAzYTIzNWYxMCAgIHJzcDogZmZmZjg4MDAzYTIzNWVmOCAgIHI4
OiAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSByOTog
IDAwMDAwMDAwMDAwMDAwMDEgICByMTA6IDAwMDAwMDAwMDAwMDAwMDAgICByMTE6IDAwMDAw
MDAwMDAwMDAyNDYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gcjEyOiBmZmZmZmZm
ZjgxZWRhMWQ4ICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiAwMDAwMDAwMDAwMDAw
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldIHIxNTogMDAwMDAwMDAwMDAwMDAw
MCAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDY2MA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSBjcjM6IDAwMDAwMDAyNDFlMGMwMDAgICBjcjI6
IDAwMDA3ZmFlMGM2ZjYwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gZHM6IDAw
MmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAyYiAgIGNzOiBl
MDMzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIEd1ZXN0IHN0YWNrIHRyYWNlIGZy
b20gcnNwPWZmZmY4ODAwM2EyMzVlZjg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBd
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDA4Y2Uw
IGZmZmY4ODAwM2EyMzVmMjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgZmZm
ZmZmZmY4MTAxNmY5YiBmZmZmODgwMDNhMjM1ZjQwIGZmZmZmZmZmODEwMTczNTYgMDAwMDAw
MDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAw
MDAwMDAwIGZmZmY4ODAwM2EyMzVmNTAgZmZmZmZmZmY4MTlhNGJmYSAwMDAwMDAwMDAwMDAw
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDBdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmZmZmZmZmZmYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0MF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDEwIDAwMDAwMDAwMDAw
MDAyMDIgZmZmZjg4MDAzYTIzNWY1OA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAg
ICAwMDAwMDAwMDAwMDAwMDE4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICoqKiBE
dW1waW5nIERvbTAgdmNwdSM0IHN0YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0MF0gUklQOiAgICBlMDMzOls8ZmZmZmZmZmY4MTAwMTNhYT5dDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDBdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIEVNOiAwICAgQ09O
VEVYVDogcHYgZ3Vlc3QNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gcmF4OiAwMDAw
MDAwMDAwMDAwMDAwICAgcmJ4OiBmZmZmODgwMDNhMjM2MDEwICAgcmN4OiBmZmZmZmZmZjgx
MDAxM2FhDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIHJkeDogMDAwMDAwMDAwMDAw
MDAwMSAgIHJzaTogMDAwMDAwMDBkZWFkYmVlZiAgIHJkaTogMDAwMDAwMDBkZWFkYmVlZg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSByYnA6IGZmZmY4ODAwM2EyMzdmMTAgICBy
c3A6IGZmZmY4ODAwM2EyMzdlZjggICByODogIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0MF0gcjk6ICAwMDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAw
MDAwMDAwMDAwMDAwICAgcjExOiAwMDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDBdIHIxMjogZmZmZmZmZmY4MWVkYTFkOCAgIHIxMzogMDAwMDAwMDAwMDAw
MDAwMCAgIHIxNDogMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQwXSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBj
cjQ6IDAwMDAwMDAwMDAwMDA2NjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gY3Iz
OiAwMDAwMDAwMjQxZTBjMDAwICAgY3IyOiAwMDAwMDAwMDAwMjBkYmYxDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDBdIGRzOiAwMDJiICAgZXM6IDAwMmIgICBmczogMDAwMCAgIGdz
OiAwMDAwICAgc3M6IGUwMmIgICBjczogZTAzMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQwXSBHdWVzdCBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODgwMDNhMjM3ZWY4Og0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgZmZmZmZmZmY4MTAwOGNlMCBmZmZmODgwMDNhMjM3ZjIwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDBdICAgIGZmZmZmZmZmODEwMTZmOWIgZmZmZjg4MDAzYTIzN2Y0
MCBmZmZmZmZmZjgxMDE3MzU2IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0MF0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODgwMDNhMjM3ZjUwIGZmZmZm
ZmZmODE5YTRiZmEgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQwXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICAg
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZmZmZm
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAxMCAwMDAwMDAwMDAwMDAwMjAyIGZmZmY4ODAwM2EyMzdmNTgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgMDAwMDAwMDAwMDAwMDAxOA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQwXSAqKiogRHVtcGluZyBEb20wIHZjcHUjNSBzdGF0ZTogKioq
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIFJJUDogICAgZTAzMzpbPGZmZmZmZmZm
ODEwMDEzYWE+XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSBSRkxBR1M6IDAwMDAw
MDAwMDAwMDAyNDYgICBFTTogMCAgIENPTlRFWFQ6IHB2IGd1ZXN0DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDBdIHJheDogMDAwMDAwMDAwMDAwMDAwMCAgIHJieDogZmZmZjg4MDAz
YTI0MDAxMCAgIHJjeDogZmZmZmZmZmY4MTAwMTNhYQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQwXSByZHg6IDAwMDAwMDAwMDAwMDAwMDEgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYg
ICByZGk6IDAwMDAwMDAwZGVhZGJlZWYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0g
cmJwOiBmZmZmODgwMDNhMjQxZjEwICAgcnNwOiBmZmZmODgwMDNhMjQxZWY4ICAgcjg6ICAw
MDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIHI5OiAgMDAw
MDAwMDAwMDAwMDAwMSAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAw
MDAwMDI0Ng0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSByMTI6IGZmZmZmZmZmODFl
ZGExZDggICByMTM6IDAwMDAwMDAwMDAwMDAwMDAgICByMTQ6IDAwMDAwMDAwMDAwMDAwMDAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAg
Y3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNjYwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDBdIGNyMzogMDAwMDAwMDI0ZjViZTAwMCAgIGNyMjogMDAw
MDAwMDAwMTI4ZDA0MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSBkczogMDAyYiAg
IGVzOiAwMDJiICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDJiICAgY3M6IGUwMzMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSBy
c3A9ZmZmZjg4MDAzYTI0MWVmODoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDhjZTAgZmZm
Zjg4MDAzYTI0MWYyMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSAgICBmZmZmZmZm
ZjgxMDE2ZjliIGZmZmY4ODAwM2EyNDFmNDAgZmZmZmZmZmY4MTAxNzM1NiAwMDAwMDAwMDAw
MDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdICAgIDAwMDAwMDAwMDAwMDAw
MDAgZmZmZjg4MDAzYTI0MWY1MCBmZmZmZmZmZjgxOWE0YmZhIDAwMDAwMDAwMDAwMDAwMDAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQxXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0MV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgZmZmZmZmZmZmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQx
XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMTAgMDAwMDAwMDAwMDAwMDIw
MiBmZmZmODgwMDNhMjQxZjU4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdICAgIDAw
MDAwMDAwMDAwMDAwMTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gW0g6IGR1bXAg
aGVhcCBpbmZvXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSAnSCcgcHJlc3NlZCAt
PiBkdW1waW5nIGhlYXAgaW5mbyAobm93LTB4Mjc6NjhDNjY3RkIpDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTBdIC0+IDAgcGFnZXMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MV0gLT4gMCBwYWdl
cw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFwW25vZGU9MF1bem9uZT0yXSAt
PiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6
b25lPTNdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtu
b2RlPTBdW3pvbmU9NF0gLT4gMCBwYWdlcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQx
XSBoZWFwW25vZGU9MF1bem9uZT01XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTZdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9N10gLT4gMCBwYWdlcw0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFwW25vZGU9MF1bem9uZT04XSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTld
IC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBd
W3pvbmU9MTBdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVh
cFtub2RlPTBdW3pvbmU9MTFdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTJdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTNdIC0+IDAgcGFnZXMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTRdIC0+IDE2MTI4
IHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25l
PTE1XSAtPiAzMjc2OCBwYWdlcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFw
W25vZGU9MF1bem9uZT0xNl0gLT4gNjU1MzYgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTddIC0+IDEzMTA3MiBwYWdlcw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFwW25vZGU9MF1bem9uZT0xOF0gLT4gMjYyMTQ0
IHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25l
PTE5XSAtPiAxOTU4MjIgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVh
cFtub2RlPTBdW3pvbmU9MjBdIC0+IDEwNDg1NzYgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MjFdIC0+IDU4MTA0IHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTIyXSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTIz
XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0w
XVt6b25lPTI0XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhl
YXBbbm9kZT0wXVt6b25lPTI1XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI2XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI3XSAtPiAwIHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI4XSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI5
XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0w
XVt6b25lPTMwXSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhl
YXBbbm9kZT0wXVt6b25lPTMxXSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTMyXSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTMzXSAtPiAwIHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM0XSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM1
XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0w
XVt6b25lPTM2XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhl
YXBbbm9kZT0wXVt6b25lPTM3XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM4XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM5XSAtPiAwIHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIFtJOiBkdW1wIEhWTSBpcnEgaW5mb10NCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gJ0knIHByZXNzZWQgLT4gZHVtcGluZyBIVk0gaXJx
IGluZm8NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gW006IGR1bXAgTVNJIHN0YXRl
XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBNU0kgaW5mb3JtYXRpb246DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdICBNU0kgICAgIDU2IHZlYz0yOCAgZml4ZWQgIGVk
Z2UgZGVhc3NlcnQgcGh5cyAgICBjcHUgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMC8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBIUEVUICAgIDU3IHZlYz1hMCBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMC8/DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBIUEVUICAgIDU4IHZlYz1hOCBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMC8/DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBIUEVUICAgIDU5IHZlYz1iMCBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMC8/DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYwIHZlYz01MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYxIHZlYz01OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYyIHZlYz02MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYzIHZlYz02OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY0IHZlYz03MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY1IHZlYz03OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY2IHZlYz04MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY3IHZlYz04OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY4IHZlYz05MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY5IHZlYz1jMSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDcwIHZlYz1kMSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDcxIHZlYz1kOSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDcyIHZlYz0yMiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDczIHZlYz0yYSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc0IHZlYz0zMiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc1IHZlYz0zYSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc2IHZlYz00MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc3IHZlYz00YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc4IHZlYz01MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc5IHZlYz01YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgwIHZlYz02MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgxIHZlYz02YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgyIHZlYz03MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgzIHZlYz03YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDg0IHZlYz04YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDg1IHZlYz1hYSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdIFtROiBkdW1wIFBDSSBkZXZpY2VzXQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQyXSA9PT09IFBDSSBkZXZpY2VzID09PT0NCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0Ml0gPT09PSBzZWdtZW50IDAwMDAgPT09PQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQyXSAwMDAwOjBjOjAwLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Ml0gMDAwMDowYjowMS4yIC0gZG9tIDAgICAt
IE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDJdIDAwMDA6MGI6MDEuMSAt
IGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQyXSAwMDAw
OjBiOjAxLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0Ml0gMDAwMDowYTowMC4wIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDJdIDAwMDA6MDk6MDAuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjkgPg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQyXSAwMDAwOjA4OjAwLjAgLSBkb20gMCAgIC0g
TVNJcyA8IDcwID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Ml0gMDAwMDowNzowMC4w
IC0gZG9tIDAgICAtIE1TSXMgPCA3MSA3MiA3MyA3NCA3NSA3NiA3NyA+DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDY6MDAuMCAtIGRvbSAwICAgLSBNU0lzIDwgPg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjA1OjAwLjEgLSBkb20gMCAgIC0g
TVNJcyA8IDg1ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowNTowMC4w
IC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAw
MDA6MDQ6MDAuMCAtIGRvbSAwICAgLSBNU0lzIDwgNzggNzkgODAgODEgODIgODMgODQgPg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAzOjA2LjAgLSBkb20gMCAgIC0g
TVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDoxOC40IC0g
ZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6
MDA6MTguMyAtIGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQzXSAwMDAwOjAwOjE4LjIgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0M10gMDAwMDowMDoxOC4xIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MTguMCAtIGRvbSAwICAgLSBNU0lz
IDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjE2LjIgLSBkb20g
MCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDox
Ni4wIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNd
IDAwMDA6MDA6MTUuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjggPg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQzXSAwMDAwOjAwOjE0LjUgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDoxNC40IC0gZG9tIDAgICAtIE1TSXMg
PCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MTQuMyAtIGRvbSAw
ICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjE0
LjEgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10g
MDAwMDowMDoxNC4wIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDNdIDAwMDA6MDA6MTMuMiAtIGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjEzLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDoxMi4yIC0gZG9tIDAgICAt
IE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MTIuMCAt
IGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAw
OjAwOjExLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0M10gMDAwMDowMDowZC4wIC0gZG9tIDAgICAtIE1TSXMgPCA2NyA+DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MGIuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjYg
Pg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjBhLjAgLSBkb20gMCAg
IC0gTVNJcyA8IDY1ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDow
OS4wIC0gZG9tIDAgICAtIE1TSXMgPCA2NCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDNdIDAwMDA6MDA6MDYuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjMgPg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjA1LjAgLSBkb20gMCAgIC0gTVNJcyA8IDYyID4N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDowMy4wIC0gZG9tIDAgICAt
IE1TSXMgPCA2MSA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MDIu
MCAtIGRvbSAwICAgLSBNU0lzIDwgNjAgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQz
XSAwMDAwOjAwOjAwLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0M10gMDAwMDowMDowMC4yIC0gZG9tIDMyNzU0IC0gTVNJcyA8ID4NCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0M10gW2E6IGR1bXAgdGltZXIgcXVldWVzXQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQzXSBEdW1waW5nIHRpbWVyIHF1ZXVlczoNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0M10gQ1BVMDA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDNdICAgZXg9ICAgLTM1MjB1cyB0aW1lcj1mZmZmODMwMjQ3YmNjMGI4IGNiPWZmZmY4MmM0
YzAxMWEwYjQoMDAwMDAwMDAwMDAwMDAwMCkgY3NjaGVkX3RpY2srMC8weDM0YQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAgIDE2NDgwdXMgdGltZXI9ZmZmZjgzMDI0
N2JjYTI0MCBjYj1mZmZmODJjNGMwMTE5NTk4KGZmZmY4MzAyNDdiY2EyMjApIGNzY2hlZF9h
Y2N0KzAvMHg0YWMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gICBleD0xMzA3NDc4
MDh1cyB0aW1lcj1mZmZmODJjNGMwMzBkMDYwIGNiPWZmZmY4MmM0YzAxODBlMTAoMDAwMDAw
MDAwMDAwMDAwMCkgcGx0X292ZXJmbG93KzAvMHgxMmYNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0M10gICBleD0xMDc2NDg2OXVzIHRpbWVyPWZmZmY4MmM0YzAzMGViODAgY2I9ZmZm
ZjgyYzRjMDFhMzA2NSgwMDAwMDAwMDAwMDAwMDAwKSBtY2VfYW1kX3dvcmtfZm4rMC8weDFm
Nw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAgMjU0MTY0dXMgdGltZXI9
ZmZmZjgyYzRjMDMwY2ZlMCBjYj1mZmZmODJjNGMwMTgxMzY4KDAwMDAwMDAwMDAwMDAwMDAp
IHRpbWVfY2FsaWJyYXRpb24rMC8weDU1DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNd
IENQVTAxOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAgMTk5NzE0dXMg
dGltZXI9ZmZmZjgzMDI0N2JkNWJkOCBjYj1mZmZmODJjNGMwMTFhMGI0KDAwMDAwMDAwMDAw
MDAwMDEpIGNzY2hlZF90aWNrKzAvMHgzNGENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
M10gICBleD0gIDQ1NDUyMXVzIHRpbWVyPWZmZmY4MzAwYWZmODgwNjAgY2I9ZmZmZjgyYzRj
MDEyMjMxMChmZmZmODMwMGFmZjg4MDAwKSB2Y3B1X3NpbmdsZXNob3RfdGltZXJfZm4rMC8w
eGINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gQ1BVMDI6DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDNdICAgZXg9ICAyNzc5NTl1cyB0aW1lcj1mZmZmODMwMjQ3YmVlMDI4
IGNiPWZmZmY4MmM0YzAxMWEwYjQoMDAwMDAwMDAwMDAwMDAwMikgY3NjaGVkX3RpY2srMC8w
eDM0YQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAzNTcwODg0dXMgdGlt
ZXI9ZmZmZjgzMDBhZmQxNzA2MCBjYj1mZmZmODJjNGMwMTIyMzEwKGZmZmY4MzAwYWZkMTcw
MDApIHZjcHVfc2luZ2xlc2hvdF90aW1lcl9mbiswLzB4Yg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQzXSBDUFUwMzoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gICBleD0g
IDM1NjE2NHVzIHRpbWVyPWZmZmY4MzAyNDdiZWU0MTggY2I9ZmZmZjgyYzRjMDExYTBiNCgw
MDAwMDAwMDAwMDAwMDAzKSBjc2NoZWRfdGljayswLzB4MzRhDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDNdICAgZXg9IDM1NzQyMTl1cyB0aW1lcj1mZmZmODMwMGFmZDE2MDYwIGNi
PWZmZmY4MmM0YzAxMjIzMTAoZmZmZjgzMDBhZmQxNjAwMCkgdmNwdV9zaW5nbGVzaG90X3Rp
bWVyX2ZuKzAvMHhiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIENQVTA0Og0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgIGV4PSAgNDM0NDQzdXMgdGltZXI9ZmZmZjgz
MDI0N2JlZTg0OCBjYj1mZmZmODJjNGMwMTFhMGI0KDAwMDAwMDAwMDAwMDAwMDQpIGNzY2hl
ZF90aWNrKzAvMHgzNGENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gICBleD0gMzU3
NzU1NHVzIHRpbWVyPWZmZmY4MzAwYWZkMTUwNjAgY2I9ZmZmZjgyYzRjMDEyMjMxMChmZmZm
ODMwMGFmZDE1MDAwKSB2Y3B1X3NpbmdsZXNob3RfdGltZXJfZm4rMC8weGINCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0NF0gQ1BVMDU6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdICAgZXg9ICA1MTI2NTZ1cyB0aW1lcj1mZmZmODMwMjQ3YmVlYzc4IGNiPWZmZmY4MmM0
YzAxMWEwYjQoMDAwMDAwMDAwMDAwMDAwNSkgY3NjaGVkX3RpY2srMC8weDM0YQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgIGV4PSAzNTgwODg5dXMgdGltZXI9ZmZmZjgzMDBh
ZmQxNDA2MCBjYj1mZmZmODJjNGMwMTIyMzEwKGZmZmY4MzAwYWZkMTQwMDApIHZjcHVfc2lu
Z2xlc2hvdF90aW1lcl9mbiswLzB4Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBb
YzogZHVtcCBBQ1BJIEN4IHN0cnVjdHVyZXNdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdICdjJyBwcmVzc2VkIC0+IHByaW50aW5nIEFDUEkgQ3ggc3RydWN0dXJlcw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ0XSA9PWNwdTA9PQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ0XSBhY3RpdmUgc3RhdGU6CQlDMjU1DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdIG1heF9jc3RhdGU6CQlDNw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBzdGF0
ZXM6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdICAgICBDMToJdHlwZVtDMV0gbGF0
ZW5jeVswMDBdIHVzYWdlWzAwMDAwMDAwXSBtZXRob2RbIEhBTFRdIGR1cmF0aW9uWzBdDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdICAgICBDMDoJdXNhZ2VbMDAwMDAwMDBdIGR1
cmF0aW9uWzE3MjI2MDMwNzA5OV0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gUEMy
WzBdIFBDM1swXSBQQzZbMF0gUEM3WzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRd
IENDM1swXSBDQzZbMF0gQ0M3WzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdID09
Y3B1MT09DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIGFjdGl2ZSBzdGF0ZToJCUMy
NTUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gbWF4X2NzdGF0ZToJCUM3DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIHN0YXRlczoNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0NF0gICAgIEMxOgl0eXBlW0MxXSBsYXRlbmN5WzAwMF0gdXNhZ2VbMDAwMDAwMDBd
IG1ldGhvZFsgSEFMVF0gZHVyYXRpb25bMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
NF0gICAgIEMwOgl1c2FnZVswMDAwMDAwMF0gZHVyYXRpb25bMTcyMzc4MDc4Njc3XQ0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBQQzJbMF0gUEMzWzBdIFBDNlswXSBQQzdbMF0N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gQ0MzWzBdIENDNlswXSBDQzdbMF0NCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gPT1jcHUyPT0NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0NF0gYWN0aXZlIHN0YXRlOgkJQzI1NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ0XSBtYXhfY3N0YXRlOgkJQzcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0g
c3RhdGVzOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgICAgQzE6CXR5cGVbQzFd
IGxhdGVuY3lbMDAwXSB1c2FnZVswMDAwMDAwMF0gbWV0aG9kWyBIQUxUXSBkdXJhdGlvblsw
XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgICAgQzA6CXVzYWdlWzAwMDAwMDAw
XSBkdXJhdGlvblsxNzI0OTU4NTIzNDNdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRd
IFBDMlswXSBQQzNbMF0gUEM2WzBdIFBDN1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ0XSBDQzNbMF0gQ0M2WzBdIENDN1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0
XSA9PWNwdTM9PQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBhY3RpdmUgc3RhdGU6
CQlDMjU1DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIG1heF9jc3RhdGU6CQlDNw0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBzdGF0ZXM6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDRdICAgICBDMToJdHlwZVtDMV0gbGF0ZW5jeVswMDBdIHVzYWdlWzAwMDAw
MDAwXSBtZXRob2RbIEhBTFRdIGR1cmF0aW9uWzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDRdICAgICBDMDoJdXNhZ2VbMDAwMDAwMDBdIGR1cmF0aW9uWzE3MjYxMzYyNDI4OF0N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gUEMyWzBdIFBDM1swXSBQQzZbMF0gUEM3
WzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIENDM1swXSBDQzZbMF0gQ0M3WzBd
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdID09Y3B1ND09DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDRdIGFjdGl2ZSBzdGF0ZToJCUMyNTUNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0NF0gbWF4X2NzdGF0ZToJCUM3DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdIHN0YXRlczoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gICAgIEMxOgl0eXBl
W0MxXSBsYXRlbmN5WzAwMF0gdXNhZ2VbMDAwMDAwMDBdIG1ldGhvZFsgSEFMVF0gZHVyYXRp
b25bMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gICAgIEMwOgl1c2FnZVswMDAw
MDAwMF0gZHVyYXRpb25bMTcyNzMxMzk3NjU0XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ0XSBQQzJbMF0gUEMzWzBdIFBDNlswXSBQQzdbMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0NF0gQ0MzWzBdIENDNlswXSBDQzdbMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0NF0gPT1jcHU1PT0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gYWN0aXZlIHN0
YXRlOgkJQzI1NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBtYXhfY3N0YXRlOgkJ
QzcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gc3RhdGVzOg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ0XSAgICAgQzE6CXR5cGVbQzFdIGxhdGVuY3lbMDAwXSB1c2FnZVsw
MDAwMDAwMF0gbWV0aG9kWyBIQUxUXSBkdXJhdGlvblswXQ0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ0XSAgICAgQzA6CXVzYWdlWzAwMDAwMDAwXSBkdXJhdGlvblsxNzI4NDkxNzEy
ODFdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIFBDMlswXSBQQzNbMF0gUEM2WzBd
IFBDN1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBDQzNbMF0gQ0M2WzBdIEND
N1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBbZTogZHVtcCBldnRjaG4gaW5m
b10NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gJ2UnIHByZXNzZWQgLT4gZHVtcGlu
ZyBldmVudC1jaGFubmVsIGluZm8NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gRXZl
bnQgY2hhbm5lbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDA6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDRdIFBvbGxpbmcgdkNQVXM6IHt9DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDRdICAgICBwb3J0IFtwL21dDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdICAg
ICAgICAxIFsxLzBdOiBzPTUgbj0wIHg9MCB2PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0NF0gICAgICAgIDIgWzEvMF06IHM9NiBuPTAgeD0wDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDRdICAgICAgICAzIFswLzBdOiBzPTYgbj0wIHg9MA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ1XSAgICAgICAgNCBbMC8wXTogcz01IG49MCB4PTAgdj0xDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgICA1IFswLzBdOiBzPTYgbj0wIHg9MA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAgNiBbMC8wXTogcz02IG49MCB4PTAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgIDcgWzAvMF06IHM9NSBuPTEg
eD0wIHY9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAgOCBbMC8wXTog
cz02IG49MSB4PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgIDkgWzAv
MF06IHM9NiBuPTEgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDEw
IFswLzBdOiBzPTUgbj0xIHg9MCB2PTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0g
ICAgICAgMTEgWzAvMF06IHM9NiBuPTEgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDVdICAgICAgIDEyIFswLzBdOiBzPTYgbj0xIHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ1XSAgICAgICAxMyBbMC8wXTogcz01IG49MiB4PTAgdj0wDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDVdICAgICAgIDE0IFswLzBdOiBzPTYgbj0yIHg9MA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAxNSBbMC8wXTogcz02IG49MiB4PTANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMTYgWzAvMF06IHM9NSBuPTIgeD0wIHY9
MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAxNyBbMC8wXTogcz02IG49
MiB4PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMTggWzAvMF06IHM9
NiBuPTIgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDE5IFswLzBd
OiBzPTUgbj0zIHg9MCB2PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAg
MjAgWzAvMF06IHM9NiBuPTMgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAg
ICAgIDIxIFswLzBdOiBzPTYgbj0zIHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1
XSAgICAgICAyMiBbMC8wXTogcz01IG49MyB4PTAgdj0xDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDVdICAgICAgIDIzIFswLzBdOiBzPTYgbj0zIHg9MA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ1XSAgICAgICAyNCBbMC8wXTogcz02IG49MyB4PTANCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0NV0gICAgICAgMjUgWzAvMF06IHM9NSBuPTQgeD0wIHY9MA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAyNiBbMC8wXTogcz02IG49NCB4PTAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMjcgWzAvMF06IHM9NiBuPTQg
eD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDI4IFswLzBdOiBzPTUg
bj00IHg9MCB2PTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMjkgWzAv
MF06IHM9NiBuPTQgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDMw
IFswLzBdOiBzPTYgbj00IHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAg
ICAzMSBbMC8wXTogcz01IG49NSB4PTAgdj0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDVdICAgICAgIDMyIFswLzBdOiBzPTYgbj01IHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ1XSAgICAgICAzMyBbMC8wXTogcz02IG49NSB4PTANCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0NV0gICAgICAgMzQgWzAvMF06IHM9NSBuPTUgeD0wIHY9MQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAzNSBbMC8wXTogcz02IG49NSB4PTANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMzYgWzAvMF06IHM9NiBuPTUgeD0wDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDM3IFswLzBdOiBzPTIgbj0wIHg9
MCBkPTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMzggWzAvMF06IHM9
NSBuPTAgeD0wIHY9OQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAzOSBb
MC8wXTogcz00IG49MCB4PTAgcD05IGk9OQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1
XSAgICAgICA0MCBbMC8wXTogcz01IG49MCB4PTAgdj0xNg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ1XSAgICAgICA0MSBbMC8xXTogcz01IG49MCB4PTAgdj0yDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDQyIFswLzBdOiBzPTQgbj0wIHg9MCBwPTE3IGk9
MTcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgNDMgWzAvMF06IHM9NCBu
PTAgeD0wIHA9MzEgaT0zMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA0
NCBbMC8wXTogcz00IG49MCB4PTAgcD0xOCBpPTE4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDVdICAgICAgIDQ1IFswLzBdOiBzPTQgbj0wIHg9MCBwPTI5IGk9MjkNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgNDYgWzAvMF06IHM9NCBuPTAgeD0wIHA9MzAg
aT0zMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA0NyBbMC8wXTogcz00
IG49MCB4PTAgcD0zMDAgaT03MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAg
ICA0OCBbMC8wXTogcz00IG49MCB4PTAgcD0yOTkgaT03Mg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ1XSAgICAgICA0OSBbMC8wXTogcz00IG49MCB4PTAgcD0yOTggaT03Mw0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1MCBbMC8wXTogcz00IG49MCB4PTAg
cD0yOTcgaT03NA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1MSBbMC8w
XTogcz00IG49MCB4PTAgcD0yOTYgaT03NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1
XSAgICAgICA1MiBbMC8wXTogcz00IG49MCB4PTAgcD0yOTUgaT03Ng0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ1XSAgICAgICA1MyBbMC8wXTogcz00IG49MCB4PTAgcD0yOTQgaT03
Nw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1NCBbMC8wXTogcz00IG49
MCB4PTAgcD0yOTMgaT03OA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1
NSBbMC8wXTogcz00IG49MCB4PTAgcD0yOTIgaT03OQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ1XSAgICAgICA1NiBbMC8wXTogcz00IG49MCB4PTAgcD0yOTEgaT04MA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1NyBbMC8wXTogcz00IG49MCB4PTAgcD0y
OTAgaT04MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1OCBbMC8wXTog
cz00IG49MCB4PTAgcD0yODkgaT04Mg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAg
ICAgICA1OSBbMC8wXTogcz00IG49MCB4PTAgcD0yODggaT04Mw0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ1XSAgICAgICA2MCBbMC8wXTogcz00IG49MCB4PTAgcD0yODcgaT04NA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA2MSBbMC8wXTogcz00IG49MCB4
PTAgcD0xMiBpPTEyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDYyIFsw
LzBdOiBzPTQgbj0wIHg9MCBwPTEgaT0xDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVd
ICAgICAgIDYzIFswLzBdOiBzPTQgbj0wIHg9MCBwPTggaT04DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDVdICAgICAgIDY0IFswLzBdOiBzPTQgbj0wIHg9MCBwPTQ3IGk9NDcNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgNjUgWzAvMF06IHM9NCBuPTAgeD0w
IHA9MjIgaT0yMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICAgICA2NiBbMC8w
XTogcz00IG49MCB4PTAgcD0yODYgaT04NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSBbZzogcHJpbnQgZ3JhbnQgdGFibGUgdXNhZ2VdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDZdIGdudHRhYl91c2FnZV9wcmludF9hbGwgWyBrZXkgJ2cnIHByZXNzZWQNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0Nl0gICAgICAgLS0tLS0tLS0gYWN0aXZlIC0tLS0tLS0t
ICAgICAgIC0tLS0tLS0tIHNoYXJlZCAtLS0tLS0tLQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ2XSBbcmVmXSBsb2NhbGRvbSBtZm4gICAgICBwaW4gICAgICAgICAgbG9jYWxkb20g
Z21mbiAgICAgZmxhZ3MNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Nl0gZ3JhbnQtdGFi
bGUgZm9yIHJlbW90ZSBkb21haW46ICAgIDAgLi4uIG5vIGFjdGl2ZSBncmFudCB0YWJsZSBl
bnRyaWVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDZdIGdudHRhYl91c2FnZV9wcmlu
dF9hbGwgXSBkb25lDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDZdIFtpOiBkdW1wIGlu
dGVycnVwdCBiaW5kaW5nc10NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Nl0gR3Vlc3Qg
aW50ZXJydXB0IGluZm9ybWF0aW9uOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAg
ICBJUlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh
dHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ2XSAgICBJUlE6ICAgMSBhZmZpbml0eTowMSB2ZWM6MzAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDE0IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICAxKC1TLS0p
LA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgMiBhZmZpbml0eToz
ZiB2ZWM6ZTIgdHlwZT1YVC1QSUMgICAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgMyBhZmZp
bml0eTowMSB2ZWM6MzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAg
NCBhZmZpbml0eTowMSB2ZWM6ZjEgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAw
MDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJ
UlE6ICAgNSBhZmZpbml0eTowMSB2ZWM6NDAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElDLWVkZ2UgICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ2XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgOCBhZmZpbml0eTowMSB2ZWM6NTggdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6
ICA4KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgOSBh
ZmZpbml0eTowMSB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEw
IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICA5KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxMCBhZmZpbml0eTowMSB2ZWM6NjggdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxMSBhZmZpbml0eTowMSB2ZWM6NzAgdHlw
ZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxMiBhZmZpbml0eTowMSB2ZWM6
NzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRv
bWFpbi1saXN0PTA6IDEyKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAg
ICBJUlE6ICAxMyBhZmZpbml0eTozZiB2ZWM6ODggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ2XSAgICBJUlE6ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ2XSAgICBJUlE6ICAxNSBhZmZpbml0eTowMSB2ZWM6OTggdHlwZT1JTy1BUElD
LWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxNiBhZmZpbml0eTozZiB2ZWM6ZDAgdHlwZT1J
Ty1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxNyBhZmZpbml0eTowMSB2ZWM6MjEg
dHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDE3KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJ
UlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6ZDggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDE4KC1TLS0pLA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxOSBhZmZpbml0eTozZiB2ZWM6YTkg
dHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAyMiBhZmZpbml0eTowMSB2
ZWM6OWEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6IDIyKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSAgICBJUlE6ICAyOSBhZmZpbml0eTowMSB2ZWM6MjkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDI5KC1TLS0pLA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAzMCBhZmZpbml0eTowMSB2
ZWM6MzEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6IDMwKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSAgICBJUlE6ICAzMSBhZmZpbml0eTowMSB2ZWM6MzkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDMxKC1TLS0pLA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAzMiBhZmZpbml0eTozZiB2
ZWM6OTkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAzMyBhZmZpbml0
eTozZiB2ZWM6YTIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICA0MCBh
ZmZpbml0eTowMSB2ZWM6NDkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6
ICA0NiBhZmZpbml0eTozZiB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAg
ICBJUlE6ICA0NyBhZmZpbml0eTowMSB2ZWM6OTIgdHlwZT1JTy1BUElDLWxldmVsICAgc3Rh
dHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDQ3KC0tLS0pLA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA0OCBhZmZpbml0eTowMSB2ZWM6
NDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1MSBhZmZpbml0eToz
ZiB2ZWM6YzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1MiBhZmZp
bml0eTozZiB2ZWM6YjggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1
MyBhZmZpbml0eTozZiB2ZWM6YzAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJ
UlE6ICA1NCBhZmZpbml0eTozZiB2ZWM6YzggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3
XSAgICBJUlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9NTVUtTVNJICAg
c3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ3XSAgICBJUlE6ICA1NyBhZmZpbml0eTozZiB2ZWM6YTAgdHlwZT1IUEVULU1TSSAg
ICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1OCBhZmZpbml0eTozZiB2ZWM6YTggdHlwZT1IUEVU
LU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1OSBhZmZpbml0eTozZiB2ZWM6YjAgdHlw
ZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2MCBhZmZpbml0eTozZiB2ZWM6
NTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2MSBhZmZpbml0eToz
ZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2MiBhZmZp
bml0eTozZiB2ZWM6NjEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2
MyBhZmZpbml0eTozZiB2ZWM6NjkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJ
UlE6ICA2NCBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3
XSAgICBJUlE6ICA2NSBhZmZpbml0eTozZiB2ZWM6NzkgdHlwZT1QQ0ktTVNJICAgICAgICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ3XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6ODEgdHlwZT1QQ0ktTVNJICAg
ICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2NyBhZmZpbml0eTozZiB2ZWM6ODkgdHlwZT1QQ0kt
TVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2OCBhZmZpbml0eTozZiB2ZWM6OTEgdHlw
ZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2OSBhZmZpbml0eTozZiB2ZWM6
YzEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3MCBhZmZpbml0eToz
ZiB2ZWM6ZDEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3MSBhZmZp
bml0eTowMSB2ZWM6ZDkgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MzAwKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3MiBhZmZpbml0eTowMSB2ZWM6MjIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk5
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3MyBhZmZp
bml0eTowMSB2ZWM6MmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk4KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3NCBhZmZpbml0eTowMSB2ZWM6MzIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk3
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3NSBhZmZp
bml0eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk2KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3NiBhZmZpbml0eTowMSB2ZWM6NDIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk1
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3NyBhZmZp
bml0eTowMSB2ZWM6NGEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk0KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3OCBhZmZpbml0eTowMSB2ZWM6NTIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjkz
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3OSBhZmZp
bml0eTowMSB2ZWM6NWEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA4MCBhZmZpbml0eTowMSB2ZWM6NjIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjkx
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICBJUlE6ICA4MSBhZmZp
bml0eTowMSB2ZWM6NmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkwKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ4XSAgICBJUlE6ICA4MiBhZmZpbml0eTowMSB2ZWM6NzIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg5
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICBJUlE6ICA4MyBhZmZp
bml0eTowMSB2ZWM6N2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg4KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ4XSAgICBJUlE6ICA4NCBhZmZpbml0eTowMSB2ZWM6OGEgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg3
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICBJUlE6ICA4NSBhZmZp
bml0eTowMSB2ZWM6YWEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg2KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ4XSBJTy1BUElDIGludGVycnVwdCBpbmZvcm1hdGlvbjoNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgMCBWZWMyNDA6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICAyOiB2ZWM9ZjAgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBk
ZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgMSBWZWMg
NDg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGlu
ICAxOiB2ZWM9MzAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAg
aXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0OF0gICAgIElSUSAgMyBWZWMgNTY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhd
ICAgICAgIEFwaWMgMHgwMCwgUGluICAzOiB2ZWM9MzggZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgNCBWZWMyNDE6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA0OiB2ZWM9ZjEg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1F
IG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElS
USAgNSBWZWMgNjQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMg
MHgwMCwgUGluICA1OiB2ZWM9NDAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0OF0gICAgIElSUSAgNiBWZWMgNzI6DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA2OiB2ZWM9NDggZGVsaXZlcnk9TG9Q
cmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0
X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgNyBWZWMgODA6
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA3
OiB2ZWM9NTAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJy
PTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
OF0gICAgIElSUSAgOCBWZWMgODg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAg
ICAgIEFwaWMgMHgwMCwgUGluICA4OiB2ZWM9NTggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgOSBWZWMgOTY6DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA5OiB2ZWM9NjAgZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1h
c2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAx
MCBWZWMxMDQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgw
MCwgUGluIDEwOiB2ZWM9NjggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFy
aXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0OF0gICAgIElSUSAxMSBWZWMxMTI6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluIDExOiB2ZWM9NzAgZGVsaXZlcnk9TG9Qcmkg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lk
OjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAxMiBWZWMxMjA6DQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluIDEyOiB2
ZWM9NzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAg
dHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0g
ICAgIElSUSAxMyBWZWMxMzY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAg
IEFwaWMgMHgwMCwgUGluIDEzOiB2ZWM9ODggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1
cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICBJUlEgMTQgVmVjMTQ0Og0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNDogdmVjPTkwIGRlbGl2
ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNr
PTAgZGVzdF9pZDoxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICBJUlEgMTUg
VmVjMTUyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICAgICBBcGljIDB4MDAs
IFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDhdICAgICBJUlEgMTYgVmVjMjA4Og0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNjogdmVjPWQwIGRlbGl2ZXJ5PUxvUHJpIGRl
c3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2
Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICAgSVJRIDE3IFZlYyAzMzoNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZl
Yz0yMSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0
cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAg
ICAgSVJRIDE4IFZlYzIxNjoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgICAg
QXBpYyAweDAwLCBQaW4gMTg6IHZlYz1kOCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgSVJRIDE5IFZlYzE2OToNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0OV0gICAgICAgQXBpYyAweDAwLCBQaW4gMTk6IHZlYz1hOSBkZWxpdmVy
eT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0x
IGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIElSUSAyMiBW
ZWMxNTQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMCwg
UGluIDIyOiB2ZWM9OWEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5
PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0OV0gICAgIElSUSAyOSBWZWMgNDE6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDldICAgICAgIEFwaWMgMHgwMSwgUGluICA1OiB2ZWM9MjkgZGVsaXZlcnk9TG9QcmkgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIElSUSAzMCBWZWMgNDk6DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGluICA2OiB2ZWM9
MzEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJp
Zz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAg
IElSUSAzMSBWZWMgNTc6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFw
aWMgMHgwMSwgUGluICA3OiB2ZWM9MzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OV0gICAgIElSUSAzMiBWZWMxNTM6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGluICA4OiB2ZWM9OTkgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBk
ZXN0X2lkOjYzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBJUlEgMzMgVmVj
MTYyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgICBBcGljIDB4MDEsIFBp
biAgOTogdmVjPWEyIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0x
IGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ5XSAgICAgSVJRIDQwIFZlYyA3MzoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
OV0gICAgICAgQXBpYyAweDAxLCBQaW4gMTY6IHZlYz00OSBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6MQ0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgSVJRIDQ2IFZlYzE4NToNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgICAgQXBpYyAweDAxLCBQaW4gMjI6IHZlYz1i
OSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAg
IElSUSA0NyBWZWMxNDY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFw
aWMgMHgwMSwgUGluIDIzOiB2ZWM9OTIgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OV0gICAgIElSUSA0OCBWZWMgNjU6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9NDEgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBk
ZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIElSUSA1MSBWZWMy
MDE6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGlu
IDI3OiB2ZWM9YzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDldICAgICBJUlEgNTIgVmVjMTg0Og0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5
XSAgICAgICBBcGljIDB4MDEsIFBpbiAyODogdmVjPWI4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9
TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mw0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgSVJRIDUzIFZlYzE5MjoNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgICAgQXBpYyAweDAxLCBQaW4gMjk6IHZlYz1j
MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAg
IElSUSA1NCBWZWMyMDA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFw
aWMgMHgwMSwgUGluIDMwOiB2ZWM9YzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDldIFttOiBtZW1vcnkgaW5mb10NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0OV0gUGh5c2ljYWwgbWVtb3J5IGluZm9ybWF0aW9uOg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ5XSAgICAgWGVuIGhlYXA6IDBrQiBmcmVlDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDldICAgICBoZWFwWzE0XTogNjQ1MTJrQiBmcmVlDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDldICAgICBoZWFwWzE1XTogMTMxMDcya0IgZnJlZQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgaGVhcFsxNl06IDI2MjE0NGtCIGZyZWUNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIGhlYXBbMTddOiA1MjQyODhrQiBmcmVl
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBoZWFwWzE4XTogMTA0ODU3NmtC
IGZyZWUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIGhlYXBbMTldOiA3ODMy
ODhrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBoZWFwWzIwXTog
NDE5NDMwNGtCIGZyZWUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIGhlYXBb
MjFdOiAyMzI0MTZrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBE
b20gaGVhcDogNzI0MDYwMGtCIGZyZWUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0g
W246IE5NSSBzdGF0aXN0aWNzXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSBDUFUJ
Tk1JDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgMAkgIDANCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OV0gICAxCSAgMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5
XSAgIDIJICAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgMwkgIDANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICA0CSAgMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUwXSAgIDUJICAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdIGRvbTAgdmNw
dTA6IE5NSSBuZWl0aGVyIHBlbmRpbmcgbm9yIG1hc2tlZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUwXSBbcTogZHVtcCBkb21haW4gKGFuZCBndWVzdCBkZWJ1ZykgaW5mb10NCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gJ3EnIHByZXNzZWQgLT4gZHVtcGluZyBkb21h
aW4gaW5mbyAobm93PTB4Mjk6NzU1RURGMUQpDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTBdIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAwOg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUwXSAgICAgcmVmY250PTMgZHlpbmc9MCBwYXVzZV9jb3VudD0wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBucl9wYWdlcz0yNjIxNDQgeGVuaGVhcF9w
YWdlcz02IHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17MS01fSBt
YXhfcGFnZXM9MjYyMTQ0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBoYW5k
bGU9MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwIHZtX2Fzc2lzdD0wMDAw
MDAwZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBSYW5nZXNldHMgYmVsb25naW5n
IHRvIGRvbWFpbiAwOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgSS9PIFBv
cnRzICB7IDAtMWYsIDIyLTNmLCA0NC02MCwgNjItOWYsIGEyLTNmNywgNDAwLTgwNywgODBj
LWNmYiwgZDAwLWZmZmYgfQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgSW50
ZXJydXB0cyB7IDAtMzExIH0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIEkv
TyBNZW1vcnkgeyAwLWZlYmZmLCBmZWMwMS1mZWMxZiwgZmVjMjEtZmVkZmYsIGZlZTAxLWZm
ZmZmZmZmZmZmZmZmZmYgfQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBNZW1vcnkg
cGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAwOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUwXSAgICAgRG9tUGFnZSBsaXN0IHRvbyBsb25nIHRvIGRpc3BsYXkNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo1MF0gICAgIFhlblBhZ2UgMDAwMDAwMDAwMDI0N2IyYzogY2FmPWMw
MDAwMDAwMDAwMDAwMDIsIHRhZj03NDAwMDAwMDAwMDAwMDAyDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTBdICAgICBYZW5QYWdlIDAwMDAwMDAwMDAyNDdiMmI6IGNhZj1jMDAwMDAw
MDAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUwXSAgICAgWGVuUGFnZSAwMDAwMDAwMDAwMjQ3YjJhOiBjYWY9YzAwMDAwMDAwMDAw
MDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
MF0gICAgIFhlblBhZ2UgMDAwMDAwMDAwMDI0N2IyOTogY2FmPWMwMDAwMDAwMDAwMDAwMDEs
IHRhZj03NDAwMDAwMDAwMDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAg
ICBYZW5QYWdlIDAwMDAwMDAwMDAwYWZmOGE6IGNhZj1jMDAwMDAwMDAwMDAwMDAyLCB0YWY9
NzQwMDAwMDAwMDAwMDAwMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgWGVu
UGFnZSAwMDAwMDAwMDAwMjQwMGEwOiBjYWY9YzAwMDAwMDAwMDAwMDAwMiwgdGFmPTc0MDAw
MDAwMDAwMDAwMDINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gVkNQVSBpbmZvcm1h
dGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMDoNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1MF0gICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtNX0N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIHBhdXNlX2NvdW50PTAgcGF1c2Vf
ZmxhZ3M9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgTm8gcGVyaW9kaWMg
dGltZXINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIFZDUFUxOiBDUFUxIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17MX0gY3B1X2FmZmluaXR5PXswLTV9DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTBdICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MF0gICAgIE5vIHBlcmlvZGljIHRpbWVyDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NTBdICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9ezJ9IGNwdV9hZmZpbml0eT17MC01
fQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgcGF1c2VfY291bnQ9MCBwYXVz
ZV9mbGFncz0xDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBObyBwZXJpb2Rp
YyB0aW1lcg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgVkNQVTM6IENQVTMg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXszfSBjcHVfYWZmaW5pdHk9ezAtNX0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1MF0gICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MQ0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUwXSAgICAgTm8gcGVyaW9kaWMgdGltZXINCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MF0gICAgIFZDUFU0OiBDUFU0IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17NH0gY3B1X2FmZmluaXR5PXsw
LTV9DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBwYXVzZV9jb3VudD0wIHBh
dXNlX2ZsYWdzPTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIE5vIHBlcmlv
ZGljIHRpbWVyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBWQ1BVNTogQ1BV
NSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9ezV9IGNwdV9hZmZpbml0eT17MC01fQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUwXSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0xDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTBdICAgICBObyBwZXJpb2RpYyB0aW1lcg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUwXSBOb3RpZnlpbmcgZ3Vlc3QgMDowICh2aXJxIDEsIHBvcnQgNCwgc3Rh
dCAwLzAvLTEpDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdIE5vdGlmeWluZyBndWVz
dCAwOjEgKHZpcnEgMSwgcG9ydCAxMCwgc3RhdCAwLzAvMCkNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MF0gTm90aWZ5aW5nIGd1ZXN0IDA6MiAodmlycSAxLCBwb3J0IDE2LCBzdGF0
IDAvMC8wKQ0KIFsgIDE3OC44OTE0MzVdIA0KKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBd
IE5vdGlmeWluZyBndWVzdCAwOjMgKHZpcnEgMSwgcG9ydCAyMiwgc3RhdCAwLzAvMCkNCiAg
IHZjcHUgMQ0KICAgIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBOb3RpZnlpbmcgZ3Vl
c3QgMDo0ICh2aXJxIDEsIHBvcnQgMjgsIHN0YXQgMC8wLzApDQogMDogbWFza2VkPTAgcGVu
ZChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBOb3RpZnlpbmcgZ3Vlc3QgMDo1ICh2aXJx
IDEsIHBvcnQgMzQsIHN0YXQgMC8wLzApDQogaW5nPTEgZXZlbnRfc2VsIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUwXSBTaGFyZWQgZnJhbWVzIDAgLS0gU2F2ZWQgZnJhbWVzIDANCiAw
MDAwMDAwMDAwMDAwMDAxDQogICAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIFtyOiBk
dW1wIHJ1biBxdWV1ZXNdDQogMTogbWFza2VkPTAgcGVuZChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUxXSBzY2hlZF9zbXRfcG93ZXJfc2F2aW5nczogZGlzYWJsZWQNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo1MV0gTk9XPTB4MDAwMDAwMjlBRUFEOURBMw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUxXSBJZGxlIGNwdXBvb2w6DQogaW5nPTAgZXZlbnRfc2VsIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjUxXSBTY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVy
IChjcmVkaXQpDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUx
XSBpbmZvOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJbmNwdXMgICAgICAgICAg
ICAgID0gNg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJbWFzdGVyICAgICAgICAg
ICAgID0gMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJY3JlZGl0ICAgICAgICAg
ICAgID0gMTgwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJY3JlZGl0IGJhbGFu
Y2UgICAgID0gLTczMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJd2VpZ2h0ICAg
ICAgICAgICAgID0gMTI4MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJcnVucV9z
b3J0ICAgICAgICAgID0gOTgzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAlkZWZh
dWx0LXdlaWdodCAgICAgPSAyNTYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCXRz
bGljZSAgICAgICAgICAgICA9IDMwbXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0g
CXJhdGVsaW1pdCAgICAgICAgICA9IDEwMDB1cw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUxXSAJY3JlZGl0cyBwZXIgbXNlYyAgID0gMTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1MV0gCXRpY2tzIHBlciB0c2xpY2UgICA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1MV0gCW1pZ3JhdGlvbiBkZWxheSAgICA9IDB1cw0KICAgICAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTFdIGlkbGVyczogMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0g
YWN0aXZlIHZjcHVzOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJICAxOiAyOiBt
YXNrZWQ9MSBwZW5kWzAuNV0gcHJpPS0xIGZsYWdzPTAgY3B1PTVpbmc9MSBldmVudF9zZWwg
IGNyZWRpdD0tMjk5MiBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkg
IDI6IDAwMDAwMDAwMDAwMDAwMDFbMC40XSBwcmk9LTIgZmxhZ3M9MCBjcHU9NA0KICAgICBj
cmVkaXQ9LTM1NzcgW3c9MjU2XQ0KIDM6IG1hc2tlZD0xIHBlbmQoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MV0gCSAgMzogaW5nPTEgZXZlbnRfc2VsIFswLjNdIHByaT0tMiBmbGFncz0w
IGNwdT0zMDAwMDAwMDAwMDAwMDAwMSBjcmVkaXQ9LTM4NjIgW3c9MjU2XQ0KICAgICAgKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDQ6IDQ6IG1hc2tlZD0xIHBlbmRbMC4yXSBw
cmk9LTIgZmxhZ3M9MCBjcHU9MmluZz0xIGV2ZW50X3NlbCAgY3JlZGl0PS00MzAxIFt3PTI1
Nl0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCSAgNTogMDAwMDAwMDAwMDAwMDAw
MVswLjFdIHByaT0tMiBmbGFncz0wIGNwdT0xIGNyZWRpdD0tNDc1MyBbdz0yNTZdDQogICAg
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gQ3B1cG9vbCAwOg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUxXSBTY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVk
aXQpDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIGluZm86DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTFdIAluY3B1cyAgICAgICAgICAgICAgPSA2DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTFdIAltYXN0ZXIgICAgICAgICAgICAgPSAwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTFdIAljcmVkaXQgICAgICAgICAgICAgPSAxODAwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTFdIAljcmVkaXQgYmFsYW5jZSAgICAgPSAtNzMyDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTFdIAl3ZWlnaHQgICAgICAgICAgICAgPSAxMjgwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAlydW5xX3NvcnQgICAgICAgICAgPSA5ODMNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCWRlZmF1bHQtd2VpZ2h0ICAgICA9IDI1Ng0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJdHNsaWNlICAgICAgICAgICAgID0gMzBt
cw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJcmF0ZWxpbWl0ICAgICAgICAgID0g
MTAwMHVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAljcmVkaXRzIHBlciBtc2Vj
ICAgPSAxMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJdGlja3MgcGVyIHRzbGlj
ZSAgID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJbWlncmF0aW9uIGRlbGF5
ICAgID0gMHVzDQogNTogbWFza2VkPTEgcGVuZChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUx
XSBpZGxlcnM6IDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIGFjdGl2ZSB2Y3B1
czoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCSAgMTogaW5nPTEgZXZlbnRfc2Vs
IFswLjVdIHByaT0tMSBmbGFncz0wIGNwdT01MDAwMDAwMDAwMDAwMDAwMSBjcmVkaXQ9LTY3
OTAgW3c9MjU2XQ0KICAgICAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDI6IA0K
ICBwZW5kaW5nOg0KICAgICBbMC40XSBwcmk9LTIgZmxhZ3M9MCBjcHU9NDAwMDAwMDAwMDAw
MDAwMDAgY3JlZGl0PS03Mzk3IFt3PTI1Nl0NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTFdIAkgIDM6IDAwMDAwMDAwMDAwMDAwMDBbMC4zXSBwcmk9LTIgZmxhZ3M9MCBjcHU9MyAg
Y3JlZGl0PS03NzgzIFt3PTI1Nl0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCSAg
NDogMDAwMDAwMDAwMDAwMDAwMFswLjJdIHByaT0tMiBmbGFncz0wIGNwdT0yICBjcmVkaXQ9
LTgxMjAgW3c9MjU2XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJICA1OiAwMDAw
MDAwMDAwMDAwMDAwWzAuMV0gcHJpPS0yIGZsYWdzPTAgY3B1PTEgY3JlZGl0PS04NTEwIFt3
PTI1Nl0NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIENQVVswMF0gMDAwMDAwMDAw
MDAwMDAwMCBzb3J0PTk4Miwgc2libGluZz0wMSwgIGNvcmU9M2YNCiAwMDAwMDAwMDAwMDAw
MDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAlydW46IFszMjc2Ny4wXSBwcmk9MCBm
bGFncz0wIGNwdT0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDE6IFswLjBd
IHByaT0wIGZsYWdzPTAgY3B1PTAgY3JlZGl0PS0zNyBbdz0yNTZdDQogIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUxXSBDUFVbMDFdICBzb3J0PTk4Mywgc2libGluZz0wMiwgY29yZT0z
Zg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJcnVuOiBbMC4xXSBwcmk9LTIgZmxh
Z3M9MCBjcHU9MSBjcmVkaXQ9LTkyODIgW3c9MjU2XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUxXSAJICAxOiBbMzI3NjcuMV0gcHJpPS02NCBmbGFncz0wIGNwdT0xDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTFdIENQVVswMl0gMDAwMDAwMDAwMDAwMDAwMCBzb3J0PTk4
Mywgc2libGluZz0wNCwgIGNvcmU9M2YNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0g
CXJ1bjogMDAwMDAwMDAwMDAwMDAwMFswLjJdIHByaT0tMiBmbGFncz0wIGNwdT0yIGNyZWRp
dD0tOTgyOSBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDE6IA0K
ICAgICBbMzI3NjcuMl0gcHJpPS02NCBmbGFncz0wIGNwdT0yDQogMDAwMDAwMDAwMDAwMDAw
MChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBDUFVbMDNdICAgc29ydD05ODMsIHNpYmxp
bmc9MDgsIDAwMDAwMDAwMDAwMDAwMDBjb3JlPTNmDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUyXSAJcnVuOiAwMDAwMDAwMDAwMDAwMDAwWzAuM10gcHJpPS0yIGZsYWdzPTAgY3B1
PTMgY3JlZGl0PS0xMDI5NSBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJd
IAkgIDE6ICBbMzI3NjcuM10gcHJpPS02NCBmbGFncz0wIGNwdT0zDQogMDAwMDAwMDAwMDAw
MDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBDUFVbMDRdICAgc29ydD05ODMsIHNp
Ymxpbmc9MTAsIDAwMDAwMDAwMDAwMDAwMDBjb3JlPTNmDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSAJcnVuOiAwMDAwMDAwMDAwMDAwMDAwWzAuNF0gcHJpPS0yIGZsYWdzPTAg
Y3B1PTQgY3JlZGl0PS0xMTExNiBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTJdIAkgIDE6ICBbMzI3NjcuNF0gcHJpPS02NCBmbGFncz0wIGNwdT00DQogMDAwMDAwMDAw
MDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBDUFVbMDVdICAgc29ydD05ODMs
IHNpYmxpbmc9MjAsIDAwMDAwMDAwMDAwMDAwMDBjb3JlPTNmDQogICAgICAgKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTJdIAlydW46IDAwMDAwMDAwMDAwMDAwMDBbMC41XSBwcmk9LTEg
ZmxhZ3M9MCBjcHU9NSBjcmVkaXQ9LTExMzEzIFt3PTI1Nl0NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1Ml0gCSAgMTogIFszMjc2Ny41XSBwcmk9LTY0IGZsYWdzPTAgY3B1PTUNCiAw
MDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIFtzOiBkdW1wIHNv
ZnR0c2Mgc3RhdHNdDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBUU0MgbWFya2Vk
IGFzIHJlbGlhYmxlLCB3YXJwID0gMCAoY291bnQ9MikNCiAwMDAwMDAwMDAwMDAwMDAwKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIE5vIGRvbWFpbnMgaGF2ZSBlbXVsYXRlZCBUU0MN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIFt0OiBkaXNwbGF5IG11bHRpLWNwdSBj
bG9jayBpbmZvXQ0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
Ml0gU3luY2VkIHN0aW1lIHNrZXc6IG1heD00MTlucyBhdmc9NDE5bnMgc2FtcGxlcz0xIGN1
cnJlbnQ9NDE5bnMNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIFN5bmNlZCBjeWNs
ZXMgc2tldzogbWF4PTY4OCBhdmc9Njg4IHNhbXBsZXM9MSBjdXJyZW50PTY4OA0KIDAwMDAw
MDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gW3U6IGR1bXAgbnVtYSBp
bmZvXQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gJ3UnIHByZXNzZWQgLT4gZHVt
cGluZyBudW1hIGluZm8gKG5vdy0weDI5OkZGQUUyMEZDKQ0KIDAwMDAwMDAwMDAwMDAwMDAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gaWR4MCAtPiBOT0RFMCBzdGFydC0+MCBzaXpl
LT4yNDI0ODMyIGZyZWUtPjE4MTAxNTANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJd
IHBoeXNfdG9fbmlkKDAwMDAwMDAwMDAwMDEwMDApIC0+IDAgc2hvdWxkIGJlIDANCiAwMDAw
MDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIENQVTAgLT4gTk9ERTAN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIENQVTEgLT4gTk9ERTANCiAwMDAwMDAw
MDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIENQVTIgLT4gTk9ERTANCiAg
ICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gQ1BVMyAtPiBOT0RFMA0KIDAwMDAw
MDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gQ1BVNCAtPiBOT0RFMA0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gQ1BVNSAtPiBOT0RFMA0KIDAwMDAwMDAw
MDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gTWVtb3J5IGxvY2F0aW9uIG9m
IGVhY2ggZG9tYWluOg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gRG9tYWluIDAg
KHRvdGFsOiAyNjIxNDQpOg0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1Ml0gICAgIE5vZGUgMDogMjYyMTQ0DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUyXSBbdjogZHVtcCBBTUQtViBWTUNCc10NCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTJdICoqKioqKioqKioqIFZNQ0IgQXJlYXMgKioqKioqKioqKioq
KioNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdICoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSBbejogcHJpbnQgaW9hcGljIGluZm9dDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KIDAwMDAwMDAwMDAw
MDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gbnVtYmVyIG9mIElPLUFQSUMgIzYg
cmVnaXN0ZXJzOiAyNC4NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIG51bWJlciBv
ZiBJTy1BUElDICM3IHJlZ2lzdGVyczogMzIuDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjUyXSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIElPIEFQSUMgIzYuLi4u
Li4NCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KICAgICAgIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUyXSAuLi4uLi4uICAgIDogcGh5c2ljYWwgQVBJQyBpZDogMDYNCiAwMDAwMDAwMDAwMDAw
MDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBU
eXBlOiAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSAuLi4uLi4uICAgIDogTFRT
ICAgICAgICAgIDogMA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1Ml0gLi4uLiByZWdpc3RlciAjMDE6IDAwMTc4MDIxDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDE3
DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSAuLi4uLi4u
ICAgICA6IFBSUSBpbXBsZW1lbnRlZDogMQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
Ml0gLi4uLi4uLiAgICAgOiBJTyBBUElDIHZlcnNpb246IDAwMjENCiAwMDAwMDAwMDAwMDAw
MDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIC4uLi4gcmVnaXN0ZXIgIzAyOiAwNjAw
MDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gLi4uLi4uLiAgICAgOiBhcmJp
dHJhdGlvbjogMDYNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTJdIC4uLi4gcmVnaXN0ZXIgIzAzOiAwNzAwMDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1Ml0gLi4uLi4uLiAgICAgOiBCb290IERUICAgIDogMA0KIDAwMDAwMDAwMDAwMDAw
MDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFi
bGU6DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSAgTlIgTG9nIFBoeSBNYXNrIFRy
aWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KIDAwMDAwMDAwMDAwMDAwMDAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDAwIDAwMCAwMCAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUzXSAgMDEgMDAxIDAxICANCiAgICAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgMzANCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NTNdICAwMiAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBG
MA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDAzIDAw
MSAwMSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQogMDAwMDAwMDAw
MDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMDQgMDAxIDAxICAgMCAgICAw
ICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTNdICAwNSAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA0MA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1M10gIDA2IDAwMSAwMSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDQ4DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMDcg
MDAxIDAxICAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCiAwMDAwMDAw
MDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAwOCAwMDEgMDEgICAwICAg
IDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1OA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDA5IDAwMSAwMSAgDQogICAgIDAgICAgMSAgICAw
ICAgMSAgIDAgICAgMSAgICAxICAgIDYwDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUzXSAgMGEgMDAxIDAxICAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNjgNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTNdICAwYiAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA3MA0K
IDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDBjIDAwMSAw
MSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4DQogMDAwMDAwMDAwMDAw
MDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMGQgMDNGIDBGICAgMSAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTNdICAwZSAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA5MA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1M10gIDBmIDAwMSAwMSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4
DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMTAgMDNG
IDBGICAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgRDANCiAwMDAwMDAwMDAw
MDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAxMSAwMDEgMDEgIA0KICAgICAw
ICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICAyMQ0KIDAwMDAwMDAwMDAwMDAwMDAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDEyIDAwMSAwMSAgIDAgICAgMSAgICAwICAg
MSAgIDAgICAgMSAgICAxICAgIEQ4DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUzXSAgMTMgMDNGIDBGICAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAg
IDEgICAgQTkNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNd
ICAxNCAwMDAgMDAgICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIDAw
MDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDE1IDAwMCAwMCAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogMDAwMDAwMDAwMDAwMDAw
MChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMTYgMDAxIDAxICAgMCAgICAxICAgIDAg
ICAxICAgMCAgICAxICAgIDEgICAgOUENCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTNdICAxNyAwMDAgMDAgICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
M10gSU8gQVBJQyAjNy4uLi4uLg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gLi4u
LiByZWdpc3RlciAjMDA6IDA3MDAwMDAwDQogMDAwMDAwMDA4MjA4MjA5NihYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUzXSAuLi4uLi4uICAgIDogcGh5c2ljYWwgQVBJQyBpZDogMDcNCiAg
ICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gLi4uLi4uLiAgICA6IERlbGl2ZXJ5
IFR5cGU6IDANCiAgICBnbG9iYWwgbWFzazoNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTNdIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQogICAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTNdIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQ0KIGZmZmZmZmZmZmZm
ZmZmZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gLi4uLi4uLiAgICAgOiBtYXggcmVk
aXJlY3Rpb24gZW50cmllczogMDAxRg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10g
Li4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCiBmZmZmZmZmZmZmZmZmZmZmKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTNdIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9u
OiAwMDIxDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAuLi4uIHJlZ2lzdGVyICMw
MjogMDAwMDAwMDANCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTNdIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUzXSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCiBmZmZmZmZmZmZmZmZm
ZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJ
UlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUzXSAgMDAgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAwMSAw
MDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDAyIDAwMCAwMCAgZmZmZmZm
ZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMDMgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAgICAgICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo1M10gIDA0IDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUz
XSAgMDUgMDAxIDAxICBmZmZmZmZmZmZmZmZmZmZmMCAgICAxICAgIDAgICAxICAgMCAgICAx
ICAgIDEgICAgMjkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAwNiAwMDEgMDEg
IGZmZmZmZmZmZmZmZmZmZmYwICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICAzMQ0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDA3IDAwMSAwMSAgZmZmZmZmZmZmZmZm
ZmZmZjAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDM5DQogIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjU0XSAgMDggMDNGIDBGICBmZmZmZmZmZmZmZmZmZmZmMSAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgOTkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTRdICAwOSAwM0YgMEYgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDEgICAgMCAgIDEgICAwICAg
IDEgICAgMSAgICBBMg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDBhIDAwMCAw
MCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMGIgMDAwIDAwICBmZmZmZmZmZmZm
ZmZmZmZmMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAgICAgICAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDBjIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjU0XSAgMGQgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdICAw
ZSAwMDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDBmIDAwMCAwMCAgZmZm
ZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMTAgMDAxIDAxICBmZmZmZmZmZmZmZmZmZmZm
MSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNDkNCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTRdICAxMSAwMDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0g
IDEyIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMTMgMDAwIDAwICBm
ZmZmZmZmZmZmZmZmZmZmMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAg
ICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDE0IDAwMCAwMCAgZmZmZmZmZmZm
ZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjU0XSAgMTUgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NTRdICAxNiAwM0YgMEYgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDEgICAgMCAgIDEgICAw
ICAgIDEgICAgMSAgICBCOQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDE3IDAw
MSAwMSAgZmZmZmZmZmZmZmZmZmZmZjAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAg
IDkyDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMTggMDAxIDAxICBmZmZmZmZm
ZmZmZmZmZmZmMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNDENCiAgKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTRdICAxOSAwMDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1NF0gIDFhIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMWIg
MDNGIDBGICBmZmZmZmZmZmZmZmZmZmZmMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEg
ICAgQzkNCiAgICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDFjIDAzRiAwRiAg
ZmZmZmZmZmZmZmZmZmZmZjEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIEI4DQog
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMWQgMDNGIDBGICBmZmZmZmZmZmZmZmZm
ZmZmMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgQzANCiAgKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTRdICAxZSAwM0YgMEYgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDEgICAg
MCAgIDEgICAwICAgIDEgICAgMSAgICBDOA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
NF0gIDFmIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSBVc2luZyB2ZWN0
b3ItYmFzZWQgaW5kZXhpbmcNCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NTRdIElSUSB0byBwaW4gbWFwcGluZ3M6DQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjU0XSBJUlEyNDAgZmZmZmZmZmZmZmZmZmZmZi0+IDA6MiANCiBmZmZmZmZmZmZmZmZm
ZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTQ4ICAtPiAwOjENCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRNTYgZmZmZmZmZmZmZmZmZmZmZi0+IDA6Mw0KICAg
ICANCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTI0
MSAgLT4gMDo0ZmZmZmZmZmZmZmZmZmZmZg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
NF0gSVJRNjQgZmZmZmZmZmZmZmZmZmZmZi0+IDA6NSANCiBmZmZmZmZmZmZmZmZmZmZmKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTcyICAtPiAwOjZmZmZmZmZmZmZmZmZmZmZm
DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSBJUlE4MCBmZmZmZmZmZmZmZmZmZmZm
LT4gMDo3IA0KIGZmZmZmZmZmZmZmZmZmZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0g
SVJRODggIC0+IDA6OA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSBJUlE5NiBmZmZm
ZmZmZmZmZmZmZmZmLT4gMDo5DQogICAgIA0KIGZmZmZmZmZmZmZmZmZmZmYoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo1NF0gSVJRMTA0ICAtPiAwOjEwZmZmZmZmZmZmZmZmZmZmZg0KICAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMTEyIGZmZmZmZmZmZmZmZmZmZmYtPiAw
OjExIA0KIGZmZmZmZmZmZmZmZmZmZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJR
MTIwICAtPiAwOjEyZmZmZmZmZmZmZmZmZmZmZg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1NF0gSVJRMTM2IGZmZmZmZmZmZmZmZmZmZmYtPiAwOjEzIA0KIGZmZmZmZmZmZmZmZmZm
ZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMTQ0ICAtPiAwOjE0DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTE1MiBmZmZmZmZmZmZmZmZmZmZmLT4gMDoxNQ0K
ICAgICANCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElS
UTIwOCAgLT4gMDoxNmZmZmZmZmZmZmZmZmZmZmYNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NTRdIElSUTMzIGZmZmZmZmZmZmZmZmZmZmYtPiAwOjE3IA0KIGZmZmZmZmZmZmZmZmZm
ZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMjE2ICAtPiAwOjE4ZmZmZmZmZmZm
ZmZmZmZmZg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMTY5IGZmZmZmZmZm
ZmZmZmZmZmYtPiAwOjE5IA0KIGZmZmZmZmZmZmZmZmZmZjgoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1NF0gSVJRMTU0ICAtPiAwOjIyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRd
IElSUTQxIDAwMDAwMjAwMDAwMDAwMDEtPiAxOjUNCiAgICAgDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTVdIElSUTQ5IA0KICBnbG9iYWxseSB1bm1hcy0+IDE6NmtlZDoNCiAgICAg
DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU1XSBJUlE1NyAg
LT4gMTo3MDAwMDAwMDAwMDAwMDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0g
SVJRMTUzIDAwMDAwMDAwMDAwMDAwMDAtPiAxOjggDQogMDAwMDAwMDAwMDAwMDAwMChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjU1XSBJUlExNjIgIC0+IDE6OTAwMDAwMDAwMDAwMDAwMDAN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTVdIElSUTczIDAwMDAwMDAwMDAwMDAwMDAt
PiAxOjE2IA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0g
SVJRMTg1ICAtPiAxOjIyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTVdIElSUTE0NiAw
MDAwMDAwMDAwMDAwMDAwLT4gMToyMw0KICAgICANCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTVdIElSUTY1ICAtPiAxOjI0MDAwMDAwMDAwMDAwMDAwMA0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0gSVJRMjAxIDAwMDAwMDAwMDAwMDAwMDAt
PiAxOjI3IA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0g
SVJRMTg0ICAtPiAxOjI4MDAwMDAwMDAwMDAwMDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1NV0gSVJRMTkyIDAwMDAwMDAwMDAwMDAwMDAtPiAxOjI5IA0KIDAwMDAwMDAwMDAw
MDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0gSVJRMjAwICAtPiAxOjMwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTVdIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLiBkb25lLg0KIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwODIwODIwODINCiAgICAgDQogIGxvY2FsIGNwdTEgbWFzazoNCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMWY4MA0KICAg
ICANCiAgbG9jYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDA4MA0KICAgICANCiAgcGVuZGluZyBsaXN0Og0KICBb
ICAxODQuMTU5MzUxXSAgIDA6IGV2ZW50IDEgLT4gaXJxIDcyIGxvY2FsbHktbWFza2VkDQog
IFsgIDE4NC4xNzY1NjJdICAgMTogZXZlbnQgNyAtPiBpcnEgNzgNCiAgWyAgMTg0LjE4OTg1
OV0gICAyOiBldmVudCAxMyAtPiBpcnEgODQgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg0LjIw
NzQwMF0gICAzOiBldmVudCAxOSAtPiBpcnEgOTAgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg0
LjIyNDk1N10gICA0OiBldmVudCAyNSAtPiBpcnEgOTYgbG9jYWxseS1tYXNrZWQNCiAgWyAg
MTg0LjI0MjU1OV0gICA1OiBldmVudCAzMSAtPiBpcnEgMTAyIGxvY2FsbHktbWFza2VkDQog
IFsgIDE4NC4yNjA0ODddIA0KICB2Y3B1IDQNCiAgICAwOiBtYXNrZWQ9MSBwZW5kaW5nPTAg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDANCiAgICAxOiBtYXNrZWQ9MCBwZW5kaW5nPTAg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDANCiAgICAyOiBtYXNrZWQ9MSBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICAzOiBtYXNrZWQ9MSBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICA0OiBtYXNrZWQ9MCBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICA1OiBtYXNrZWQ9MSBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICANCiAgcGVuZGluZzoNCiAgICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA4MjA4MjAwMg0KICAgICAN
CiAgZ2xvYmFsIG1hc2s6DQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAg
ICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZm
ZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZm
ZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZm
ZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmY4
IDAwMDAwMjAwMDAwMDAwMDENCiAgICAgDQogIGdsb2JhbGx5IHVubWFza2VkOg0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDgyMDgyMDAyDQogICAg
IA0KICBsb2NhbCBjcHU0IG1hc2s6DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAg
ICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwN2UwMDAwMDANCiAgICAgDQogIGxvY2FsbHkgdW5tYXNrZWQ6DQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDIwMDAwMDAN
CiAgICAgDQogIHBlbmRpbmcgbGlzdDoNCiAgWyAgMTg2LjAyMjQyMV0gICAwOiBldmVudCAx
IC0+IGlycSA3MiBsb2NhbGx5LW1hc2tlZA0KICBbICAxODYuMDM5NjA5XSAgIDI6IGV2ZW50
IDEzIC0+IGlycSA4NCBsb2NhbGx5LW1hc2tlZA0KICBbICAxODYuMDU3MTA1XSAgIDM6IGV2
ZW50IDE5IC0+IGlycSA5MCBsb2NhbGx5LW1hc2tlZA0KICBbICAxODYuMDc0NjM5XSAgIDQ6
IGV2ZW50IDI1IC0+IGlycSA5Ng0KICBbICAxODYuMDg4MjYyXSAgIDU6IGV2ZW50IDMxIC0+
IGlycSAxMDIgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg2LjEwNjEzM10gDQogIHZjcHUgNQ0K
ICAgIDA6IG1hc2tlZD0xIHBlbmRpbmc9MCBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgIDE6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgIDI6IG1hc2tlZD0xIHBlbmRpbmc9MSBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMQ0K
ICAgIDM6IG1hc2tlZD0xIHBlbmRpbmc9MSBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMQ0K
ICAgIDQ6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgIDU6IG1hc2tlZD0wIHBlbmRpbmc9MSBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMQ0K
ICAgIA0KICBwZW5kaW5nOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDgwMDgyMDAyDQogICAgIA0KICBnbG9iYWwgbWFzazoNCiAgICAgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
Zg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAg
ICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZjggMDAwMDAyMDAwMDAwMDAwMQ0KICAgICANCiAg
Z2xvYmFsbHkgdW5tYXNrZWQ6DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwODAwODIwMDINCiAgICAgDQogIGxvY2FsIGNwdTUgbWFzazoNCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMWY4MDAwMDAwMA0KICAg
ICANCiAgbG9jYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDA4MDAwMDAwMA0KICAgICANCiAgcGVuZGluZyBsaXN0Og0KICBb
ICAxODcuODcwOTA5XSAgIDA6IGV2ZW50IDEgLT4gaXJxIDcyIGxvY2FsbHktbWFza2VkDQog
IFsgIDE4Ny44ODgxMThdICAgMjogZXZlbnQgMTMgLT4gaXJxIDg0IGxvY2FsbHktbWFza2Vk
DQogIFsgIDE4Ny45MDU2NTVdICAgMzogZXZlbnQgMTkgLT4gaXJxIDkwIGxvY2FsbHktbWFz
a2VkDQogIFsgIDE4Ny45MjMxNjRdICAgNTogZXZlbnQgMzEgLT4gaXJxIDEwMg0KICBbICAx
ODcuOTM3MDk1XSANCiAgdmNwdSAwDQogICAgMDogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMTogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMjogbWFza2VkPTEgcGVuZGluZz0xIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAxDQogICAgMzogbWFza2VkPTEgcGVuZGluZz0xIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAxDQogICAgNDogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgNTogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgDQogIHBlbmRpbmc6DQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAN
CiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwODIwMDINCiAgICAgDQogIGds
b2JhbCBtYXNrOg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0K
ICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmOCAwMDAw
MDIwMDAwMDAwMDAxDQogICAgIA0KICBnbG9iYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAg
ICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDA4MjAwMg0KICAgICANCiAg
bG9jYWwgY3B1MCBtYXNrOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
NyBmZmZmZmZlMDAwMDAwMDdmDQogICAgIA0KICBsb2NhbGx5IHVubWFza2VkOg0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAyDQogICAg
IA0KICBwZW5kaW5nIGxpc3Q6DQogIFsgIDE4OS43MDA4OTddICAgMDogZXZlbnQgMSAtPiBp
cnEgNzIgbDItY2xlYXINCiAgWyAgMTg5LjcxNjU2MV0gICAyOiBldmVudCAxMyAtPiBpcnEg
ODQgbDItY2xlYXIgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg5LjczNjQzOF0gICAzOiBldmVu
dCAxOSAtPiBpcnEgOTAgbDItY2xlYXIgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg5Ljc1NjMz
M10gDQogIHZjcHUgMw0KICAgIDA6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIDE6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIDI6IG1hc2tlZD0xIHBlbmRpbmc9MSBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMQ0KICAgIDM6IG1hc2tlZD0wIHBlbmRpbmc9MSBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMQ0KICAgIDQ6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIDU6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIA0KICBwZW5kaW5nOg0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAN
CiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDg2MDAwDQogICAgIA0KICBnbG9iYWwgbWFz
azoNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAg
ICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZjggMDAwMDAyMDAwMDAw
MDAwMQ0KICAgICANCiAgZ2xvYmFsbHkgdW5tYXNrZWQ6DQogICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwODYwMDANCiAgICAgDQogIGxvY2FsIGNw
dTMgbWFzazoNCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMWY4MDAwMA0KICAgICANCiAgbG9jYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDA4MDAwMA0KICAgICANCiAgcGVu
ZGluZyBsaXN0Og0KICBbICAxOTEuNTIyNDg2XSAgIDI6IGV2ZW50IDEzIC0+IGlycSA4NCBs
b2NhbGx5LW1hc2tlZA0KICBbICAxOTEuNTM5OTQzXSAgIDI6IGV2ZW50IDE0IC0+IGlycSA4
NSBsb2NhbGx5LW1hc2tlZA0KICBbICAxOTEuNTU3NDE3XSAgIDM6IGV2ZW50IDE5IC0+IGly
cSA5MA0KICBbICAxOTEuNTcxMDEwXSANCiAgdmNwdSAyDQogICAgMDogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMTogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMjogbWFza2VkPTAgcGVu
ZGluZz0xIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAxDQogICAgMzogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgNDogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgNTogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgDQogIHBlbmRpbmc6DQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDYwMDAN
CiAgICAgDQogIGdsb2JhbCBtYXNrOg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZm
ZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAg
ICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmOCAwMDAwMDIwMDAwMDAwMDAxDQogICAgIA0KICBnbG9iYWxseSB1bm1hc2tlZDoN
CiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwNjAw
MA0KICAgICANCiAgbG9jYWwgY3B1MiBtYXNrOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDdlMDAwDQogICAgIA0KICBsb2NhbGx5IHVubWFz
a2VkOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDA2MDAwDQogICAgIA0KICBwZW5kaW5nIGxpc3Q6DQogIFsgIDE5My4zMzIyNDddICAgMjog
ZXZlbnQgMTMgLT4gaXJxIDg0DQogIFsgIDE5My4zNDU3MjddICAgMjogZXZlbnQgMTQgLT4g
aXJxIDg1DQogIA==
------------0FB1ED1493275D29B
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0FB1ED1493275D29B--



From xen-devel-bounces@lists.xen.org Wed Feb 27 11:47:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAfTT-0001He-Ix; Wed, 27 Feb 2013 11:47:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAfTP-0001HZ-Vd
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:47:02 +0000
Received: from [85.158.137.99:25825] by server-14.bemta-3.messagelabs.com id
	2C/12-27076-332FD215; Wed, 27 Feb 2013 11:46:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-217.messagelabs.com!1361965614!18310278!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30312 invoked from network); 27 Feb 2013 11:46:54 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-14.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 11:46:54 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:50086 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 1UAfRD-0002UF-Jn; Wed, 27 Feb 2013 12:44:44 +0100
Date: Wed, 27 Feb 2013 12:46:48 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1769529756.20130227124648@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512DF6C702000078000C1708@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0FB1ED1493275D29B"
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0FB1ED1493275D29B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

=0D=0AWednesday, February 27, 2013, 12:06:31 PM, you wrote:

>>>> On 27.02.13 at 11:57, Sander Eikelenboom <linux@eikelenboom.it> wrote:

>> Tuesday, February 26, 2013, 9:41:53 AM, you wrote:
>>=20
>>>>>> On 25.02.13 at 23:18, Sander Eikelenboom <linux@eikelenboom.it> wrot=
e:
>>>> I can't get linux-3.9 rc0 to boot under xen-unstable.
>>>> It doesn't detect the s-ata controller, so it ends op with udev timing=
 and=20
>>>> bailing out to busybox.
>>>>=20
>>>> I don't see a obvious error in the logs.
>>=20
>>> Perhaps because the log is far from being complete? There's a huge
>>> gap right before the first pciback message, yet that's quite likely
>>> the relevant part.
>>=20
>> Hi Jan / Konrad,
>>=20
>> Tried bisecting, but that ended up no where, so back to the logs...
>>=20
>> With v3.9-rc0 + xen, it's indeed missing a part of the log:
>>   [    4.141328] Brought up 6 CPUs
>>   [    4.142654] Grant tables using version 2 layout.
>>   [    4.142676] Grant table initialized
>>   [    4.142813] NET: Registered protocol family 16
>>   [    4.145343] node 0 link 0: io port [1000, ffffff]
>>   [    4.145354] TOM: 00000000b0000000 aka 2816M
>>   [    4.145360] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
>>   [    4.145373] node 0 link 0: mmio [e0000000, efffffff] =3D=3D> none
>>   [    4.145381] node 0 link 0: mmio [f0000000, ffffffff]
>>   [    4.145388] node 0 link 0: mmio [a0000, bffff]
>>   [    4.145395] node 0 link 0: mmio [b0000000, dfffffff]
>>   [    4.145401] TOM2: 0000000250000000 aka 9472M
>>   [    4.145406] bus: [bus 00-07] on node 0 link 0
>>   [    4.145411] bus: 00 [io  0x0000-0xffff]
>>   [    4.145415] bus: 00 [mem 0xf0000000-0xffffffff]
>>   [    4.145420] bus: 00 [mem 0x000a0000-0x000bffff]
>>   [    4.145424] bus: 00 [mem 0xb0000000-0xdfffffff]
>>   [    4.145429] bus: 00 [mem 0x250000000-0xfcffffffff]
>>   [    4.145702] ACPI: bus type pci registered
>>   [    4.146801] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem=20
>> 0xe0000000-0xefffffff] (base 0xe0000000)
>>   [    4.146812] PCI: not using MMCONFIG
>>   [    4.146817] PCI: Using configuration type 1 for base access
>>   [    4.146822] PCI: Using configuration type 1 for extended access
>>   [    4.191935] bio: create slab <bio-0> at 0
>>   [    4.192623] ACPI: Added _OSI(Module Device)
>>   [    4.192630] ACPI: Added _OSI(Processor Device)
>>   [    4.192636] ACPI: Added _OSI(3.0 _SCP Extensions)
>>   [    4.192642] ACPI: Added _OSI(Processor Aggregator Device)
>>   [    4.195958] ACPI: EC: Look up EC in DSDT
>>   [    4.199659] ACPI: Executed 3 blocks of module-level executable AML =
code
>>   [    4.204162] ACPI: Interpreter enabled
>>   [    4.204170] ACPI: (supports S0 S5)
>>   [    4.204181] ACPI: Using IOAPIC for interrupt routing
>>   [    4.204219] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem=20
>> 0xe0000000-0xefffffff] (base 0xe0000000)
>>   [    4.205800] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved i=
n=20
>> ACPI motherboa[    7.107382] usb usb5: New USB device found, idVendor=3D=
1d6b,=20
>> idProduct=3D0001
>>=20
>>=20
>> The line in the serial-log also seems to be truncated somehow and the re=
st of=20
>> the info missing ..
>>=20
>> When booting v3.9-rc0 Baremetal the complete pci enumeration seems to be=
 in=20
>> between:
>> ...
>> Tried booting with pci=3Dnommconf,nocrs but to no avail.
>> Are there any other boot options i could try to narrow it down ?

> You first of all want to make sure you get a complete log.
> "sync_console" or "serial_tx_buffer=3D<size>" are your friends...

Ah that worked :-)

Complete serial log and lspci-v38 attached.

Sata device is: 00:11.0

From=20the log i see:

  [   16.132653] pci 0000:00:11.0: [1002:4390] type 00 class 0x01018f
  [   16.150679] pci 0000:00:11.0: calling quirk_no_ata_d3+0x0/0x10
  [   16.168365] pci 0000:00:11.0: reg 10: [io  0x7000-0x7007]
  [   16.184733] pci 0000:00:11.0: reg 14: [io  0x6000-0x6003]
  [   16.201116] pci 0000:00:11.0: reg 18: [io  0x5000-0x5007]
  [   16.217491] pci 0000:00:11.0: reg 1c: [io  0x3000-0x3003]
  [   16.233868] pci 0000:00:11.0: reg 20: [io  0x2000-0x200f]
  [   16.250249] pci 0000:00:11.0: reg 24: [mem 0xf96ff000-0xf96ff3ff]
  [   16.268714] pci 0000:00:11.0: calling quirk_amd_ide_mode+0x0/0xe0
  [   16.287163] pci 0000:00:11.0: set SATA to AHCI mode

<snip>

  [   21.524945] pci 0000:00:11.0: BAR 0: reserving [io  0x7000-0x7007 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.550163] pci 0000:00:11.0: BAR 1: reserving [io  0x6000-0x6003 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.575411] pci 0000:00:11.0: BAR 2: reserving [io  0x5000-0x5007 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.600648] pci 0000:00:11.0: BAR 3: reserving [io  0x3000-0x3003 flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.625849] pci 0000:00:11.0: BAR 4: reserving [io  0x2000-0x200f flag=
s 0x40101] (d=3D0, p=3D0)
  [   21.651069] pci 0000:00:11.0: BAR 5: reserving [mem 0xf96ff000-0xf96ff=
3ff flags 0x40200] (d=3D0, p=3D0)

<snip>

  [   24.957481] pci 0000:00:11.0: calling quirk_msi_intx_disable_ati_bug+0=
x0/0x50

<snip>

  [   89.189428] ahci 0000:00:11.0: version 3.0
  [   89.207872] xen: registering gsi 19 triggering 0 polarity 1
  [   89.230656] xen: --> pirq=3D19 -> irq=3D19 (gsi=3D19)
  (XEN) [2013-02-27 11:21:21] IOAPIC[0]: Set PCI routing entry (6-19 -> 0xa=
9 -> IRQ 19 Mode:1 Active:1)
  [   89.277231] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps =
0xf impl SATA mode
  [   89.307529] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo p=
mp pio slum part=20
  [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22


> But then again I would guess it's not bus enumeration related.
> Did the multiple-MSI-vectors suspicion lead nowhere?

> Jan


------------0FB1ED1493275D29B
Content-Type: text/plain;
 name="lspci-v38.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-v38.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikKCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4
OTAgTm9ydGhicmlkZ2Ugb25seSBzaW5nbGUgc2xvdCBQQ0ktZSBHRlggSHlkcmEgcGFydCBb
MTAwMjo1YTExXQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNF
TD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5UeC0K
CUNhcGFiaWxpdGllczogW2YwXSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsKCUNhcGFiaWxpdGllczogW2M0XSBIeXBlclRyYW5zcG9ydDogU2xhdmUgb3Ig
UHJpbWFyeSBJbnRlcmZhY2UKCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENudD0yMCBN
YXN0SG9zdC0gRGVmRGlyLSBEVUwtCgkJTGluayBDb250cm9sIDA6IENGbEUtIENTVC0gQ0ZF
LSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElzb2NFbi0gTFNFbi0gRXh0
Q1RMLSA2NGItCgkJTGluayBDb25maWcgMDogTUxXST0xNmJpdCBEd0ZjSW4tIE1MV089MTZi
aXQgRHdGY091dC0gTFdJPTE2Yml0IER3RmNJbkVuLSBMV089MTZiaXQgRHdGY091dEVuLQoJ
CUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5pdC0gRU9DKyBU
WE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQoJCUxpbmsgQ29uZmln
IDE6IE1MV0k9OGJpdCBEd0ZjSW4tIE1MV089OGJpdCBEd0ZjT3V0LSBMV0k9OGJpdCBEd0Zj
SW5Fbi0gTFdPPThiaXQgRHdGY091dEVuLQoJCVJldmlzaW9uIElEOiAzLjAwCgkJTGluayBG
cmVxdWVuY3kgMDogW2JdCgkJTGluayBFcnJvciAwOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQoJCUxpbmsgRnJlcXVlbmN5IENhcGFiaWxpdHkgMDogMjAwTUh6KyAzMDBNSHotIDQw
ME1IeisgNTAwTUh6LSA2MDBNSHorIDgwME1IeisgMS4wR0h6KyAxLjJHSHorIDEuNEdIei0g
MS42R0h6LSBWZW5kLQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNvY0ZDKyBMRFRTVE9QKyBD
UkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQoJCUxpbmsgRnJlcXVlbmN5IDE6IDIwME1IegoJ
CUxpbmsgRXJyb3IgMTogPFByb3QtIDxPdmZsLSA8RU9DLSBDVExUbS0KCQlMaW5rIEZyZXF1
ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0MDBNSHotIDUwME1Iei0gNjAw
TUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHotIDEuNkdIei0gVmVuZC0KCQlF
cnJvciBIYW5kbGluZzogUEZsRS0gT0ZsRS0gUEZFLSBPRkUtIEVPQ0ZFLSBSRkUtIENSQ0ZF
LSBTRVJSRkUtIENGLSBSRS0gUE5GRS0gT05GRS0gRU9DTkZFLSBSTkZFLSBDUkNORkUtIFNF
UlJORkUtCgkJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlIFVwcGVyOiAwMC0w
MAoJCUJ1cyBOdW1iZXI6IDAwCglDYXBhYmlsaXRpZXM6IFs0MF0gSHlwZXJUcmFuc3BvcnQ6
IFJldHJ5IE1vZGUKCUNhcGFiaWxpdGllczogWzU0XSBIeXBlclRyYW5zcG9ydDogVW5pdElE
IENsdW1waW5nCglDYXBhYmlsaXRpZXM6IFs5Y10gSHlwZXJUcmFuc3BvcnQ6ICMxYQoJQ2Fw
YWJpbGl0aWVzOiBbNzBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzQgTWFza2FibGUtIDY0Yml0
LQoJCUFkZHJlc3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCgowMDowMC4yIEdlbmVyaWMgc3lz
dGVtIHBlcmlwaGVyYWwgWzA4MDZdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDk5MCBJL08g
TWVtb3J5IE1hbmFnZW1lbnQgVW5pdCAoSU9NTVUpIFsxMDAyOjVhMjNdCglTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEOTkwIEkvTyBNZW1vcnkgTWFuYWdlbWVudCBVbml0
IChJT01NVSkgWzEwMDI6NWEyM10KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNw
ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh
c3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy
RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEg
MTAKCUNhcGFiaWxpdGllczogWzQwXSBTZWN1cmUgZGV2aWNlIDw/PgoJQ2FwYWJpbGl0aWVz
OiBbNTRdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJl
c3M6IDAwMDAwMDAwMDAwMDEwMDAgIERhdGE6IDAwMjgKCUNhcGFiaWxpdGllczogWzY0XSBI
eXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsKCjAwOjAyLjAgUENJ
IGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kg
YnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAw
MCBbTm9ybWFsIGRlY29kZV0pCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0
QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJS
LSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBw
cmltYXJ5PTAwLCBzZWNvbmRhcnk9MGMsIHN1Ym9yZGluYXRlPTBjLCBzZWMtbGF0ZW5jeT0w
CglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGUwMDAtMDAwMGVmZmYKCU1lbW9yeSBiZWhpbmQg
YnJpZGdlOiBmYTAwMDAwMC1mZTlmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQg
YnJpZGdlOiAwMDAwMDAwMGQwMDAwMDAwLTAwMDAwMDAwZGZmZmZmZmYKCVNlY29uZGFyeSBz
dGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJS
KyBOb0lTQS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBT
ZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCsp
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCsp
LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJ
RGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0g
VW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5v
U25vb3ArCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJ
CURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQ
d3ItIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4
OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBT
dXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xv
Y2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4OCwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210
KyBBQldNZ210LQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQ
d3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQoJCQlTbG90ICMxLCBQb3dlckxpbWl0IDI1LjAw
MFc7IEludGVybG9jay0gTm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdy
Rmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9s
OiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJ
CVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVz
RGV0KyBJbnRlcmxvY2stCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKwoJ
CVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJ
bnRFbmEtIENSU1Zpc2libGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQ
TUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJCURldkNhcDI6IENvbXBs
ZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKwoJCURldkN0
bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJ
RndkLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlh
bmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQgoJCQkgVHJh
bnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29t
cGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIKCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0K
CQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE1MQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1
YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdCglDYXBh
YmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4
ZWQrCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlv
bjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/PgoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBB
Y2Nlc3MgQ29udHJvbCBTZXJ2aWNlcwoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBS
ZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRy
YW5zKwoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWVwb3J0CgowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3Bw
IHBvcnQgQykgWzEwMDI6NWExN10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJQ29u
dHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9v
cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog
Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt
IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENh
Y2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTBh
LCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAw
MDBmMDAwLTAwMDAwZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZm
ZmYKCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAw
MC0wMDAwMDAwMDAwMGZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0g
PFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+
UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQt
IERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2
ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEg
UE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThd
IEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQ
YXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8
MXVzCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczog
Q29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEy
OCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29y
ckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2Fw
OglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5
IEwwIDwxdXMsIEwxIDw4dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05v
dCsKCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0
cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQt
IEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBU
cmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdC0gQUJXTWdtdC0KCQlTbHRDYXA6CUF0
dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlz
ZS0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwr
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJ
bmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0
bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFu
Z2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsKCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJs
ZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJv
b3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1
cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFC
Q0QsIFRpbWVvdXREaXMrIEFSSUZ3ZCsKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6
IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwyOiBUYXJnZXQg
TGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3Rh
YmxlIERlLWVtcGhhc2lzOiAtMy41ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9w
ZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1Mt
CgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBE
ZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFi
bGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxNTkKCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dp
ZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKwoJQ2FwYWJpbGl0aWVzOiBbMTAw
IHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAx
MCA8Pz4KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMK
CQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVw
c3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysKCQlBQ1NDdGw6CVNyY1ZhbGlk
KyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3ND
dHJsLSBEaXJlY3RUcmFucy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydAoKMDA6
MDUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJ
IHRvIFBDSSBicmlkZ2UgKFBDSSBleHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChw
cm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlIrIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIy
Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS
Ui0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
CglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wOSwgc3Vib3JkaW5hdGU9MDksIHNlYy1s
YXRlbmN5PTAKCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZDAwMC0wMDAwZGZmZgoJTWVtb3J5
IGJlaGluZCBicmlkZ2U6IGY5ZTAwMDAwLWY5ZWZmZmZmCglQcmVmZXRjaGFibGUgbWVtb3J5
IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwY2ZmMDAwMDAtMDAwMDAwMDBjZmZmZmZmZgoJU2Vj
b25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQoJQnJpZGdlQ3RsOiBQYXJp
dHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJCVByaURp
c2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCss
RDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0
IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWcrIFJCRSsgRkxS
ZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwt
IEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzCgkJCUNs
b2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZl
KyBCV01nbXQrIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0
dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzUsIFBvd2VyTGlt
aXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxlOiBBdHRu
QnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctCgkJ
CUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRl
cmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENw
bHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5r
U3RhdGUrCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0
YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQoJCVJv
b3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCgkJRGV2Q2Fw
MjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2Qr
CgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBUaW1lb3V0
RGlzLSBBUklGd2QtCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRl
ckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRC
CgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9k
aWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBo
YXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVk
QgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0LQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRhOiA0MTYxCglDYXBhYmlsaXRpZXM6
IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEx
MV0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5h
YmxlKyBGaXhlZCsKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIElu
Zm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglDYXBhYmlsaXRpZXM6IFsx
OTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrCgkJQUNTQ3RsOglTcmNWYWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBD
bXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMtCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4KwoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5j
eTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDgsIHN1Ym9yZGluYXRlPTA4LCBzZWMtbGF0ZW5jeT0wCglJL08gYmVoaW5kIGJy
aWRnZTogMDAwMGMwMDAtMDAwMGNmZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAw
MC1mOWRmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAw
MGNmZTAwMDAwLTAwMDAwMDAwY2ZlZmZmZmYKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt
IDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBN
QWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNj
VG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5h
Z2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJy
ZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRp
ZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZD
YXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0
bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJ
CVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0YToJQ29yckVy
ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0K
CQlMbmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEs
IExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RS
ZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2Fi
bGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBBQldNZ210LQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9jay0g
Tm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNE
ZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25v
d24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJU3RhdHVz
OiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2st
CgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKwoJCVJvb3RDdGw6IEVyckNv
cnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2li
bGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwg
UE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDog
UmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKwoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQoJCUxua0N0bDI6
IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0s
IFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQgoJCQkgVHJhbnNtaXQgTWFyZ2luOiBO
b3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxp
YW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBD
dXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIKCUNhcGFiaWxpdGllczogW2EwXSBN
U0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0KCQlBZGRyZXNzOiBmZWUz
ZjAwYyAgRGF0YTogNDE2OQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRl
Y2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdCglDYXBhYmlsaXRpZXM6IFtiOF0g
SHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9
MSBMZW49MDEwIDw/PgoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBT
ZXJ2aWNlcwoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRS
ZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKwoJCUFDU0N0bDoJ
U3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2Qr
IEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVw
b3J0CgowMDowOS4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBS
RDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgSCkgWzEwMDI6
NWExY10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURG
LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv
cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA3LCBzdWJvcmRpbmF0ZT0w
Nywgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZm
CglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjljMDAwMDAtZjljZmZmZmYKCVByZWZldGNoYWJs
ZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAwMDAwMGZm
ZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VD
dGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkIt
CgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4t
CglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFn
czogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDIt
LEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBS
b290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRl
cywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZysg
UkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50
RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVh
ZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnIt
IFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICM0LCBTcGVl
ZCA1R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4
dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsKCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysK
CQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxu
a1N0YToJU3BlZWQgNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBN
UkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzksIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxl
OiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtD
aGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwt
IENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0
KyBMaW5rU3RhdGUrCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0g
RXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxl
LQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCgkJ
RGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBB
UklGd2QrCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBU
aW1lb3V0RGlzLSBBUklGd2QtCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9z
LCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczog
LTMuNWRCCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVu
dGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBE
ZS1lbXBoYXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6
IC0zLjVkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFz
a2FibGUtIDY0Yml0LQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRhOiA0MTcxCglDYXBhYmls
aXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEw
MDI6NWExMV0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBp
bmcgRW5hYmxlKyBGaXhlZCsKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNp
ZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglDYXBhYmlsaXRp
ZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzCgkJQUNTQ2FwOglTcmNWYWxp
ZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNz
Q3RybC0gRGlyZWN0VHJhbnMrCgkJQUNTQ3RsOglTcmNWYWxpZCsgVHJhbnNCbGstIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMt
CglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjBhLjAgUENJIGJyaWRnZSBb
MDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChl
eHRlcm5hbCBnZngxIHBvcnQgQSkgWzEwMDI6NWExZF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5U
eCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh
dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGlu
ZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlh
MDAwMDAtZjliZmZmZmYKCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAw
MDAwMDBmZmYwMDAwMC0wMDAwMDAwMDAwMGZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1I
ei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZH
QS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0g
RGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIg
TWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4
Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czog
RDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJp
bGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJ
RGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBz
IDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNv
cnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1Bl
bmQtCgkJTG5rQ2FwOglQb3J0ICM1LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBM
MHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0g
TExBY3RSZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz
IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0
V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0
aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBBQldNZ210
LQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhv
dFBsdWctIFN1cnByaXNlLQoJCQlTbG90ICMyLCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVy
bG9jay0gTm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwt
IFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5k
IFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKwoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUgUmVxSUQg
MDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJCURldkNhcDI6IENvbXBsZXRpb24gVGlt
ZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKwoJCURldkN0bDI6IENvbXBs
ZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQoJCUxu
a0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNw
ZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQgoJCQkgVHJhbnNtaXQgTWFy
Z2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0g
Q29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtT
dGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCCglDYXBhYmlsaXRpZXM6IFth
MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczog
ZmVlM2YwMGMgIERhdGE6IDQxNzkKCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFU
SSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQoJQ2FwYWJpbGl0aWVzOiBb
YjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKwoJQ2FwYWJp
bGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEg
UmV2PTEgTGVuPTAxMCA8Pz4KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRy
b2wgU2VydmljZXMKCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysKCQlBQ1ND
dGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFt
RndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBw
Y2llcG9ydAoKMDA6MGIuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJ
bmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKE5CLVNCIGxpbmspIFsxMDAyOjVhMWZdIChw
cm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlIrIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIy
Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS
Ui0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
CglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1s
YXRlbmN5PTAKCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZgoJTWVtb3J5
IGJlaGluZCBicmlkZ2U6IGY5OTAwMDAwLWY5OWZmZmZmCglQcmVmZXRjaGFibGUgbWVtb3J5
IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwYjAwMDAwMDAtMDAwMDAwMDBiZmZmZmZmZgoJU2Vj
b25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQoJQnJpZGdlQ3RsOiBQYXJp
dHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJCVByaURp
c2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCss
RDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0
IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWcrIFJCRSsgRkxS
ZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwt
IEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0g
QXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0KCQkJU2xvdCAjNSwgUG93ZXJM
aW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0
dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0K
CQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93ZXItIElu
dGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21k
Q3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExp
bmtTdGF0ZSsKCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJG
YXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJ
Um9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZD
YXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3
ZCsKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVv
dXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVu
dGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41
ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJN
b2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVt
cGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMu
NWRCCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxODEKCUNhcGFiaWxpdGll
czogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1
YTExXQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBF
bmFibGUrIEZpeGVkKwoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMg
SW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4KCUNhcGFiaWxpdGllczog
WzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMKCQlBQ1NDYXA6CVNyY1ZhbGlkKyBU
cmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJs
LSBEaXJlY3RUcmFucysKCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIr
IENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydAoKMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVy
bmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4KwoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5j
eTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDQsIHN1Ym9yZGluYXRlPTA0LCBzZWMtbGF0ZW5jeT0wCglJL08gYmVoaW5kIGJy
aWRnZTogMDAwMGYwMDAtMDAwMDBmZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTgwMDAw
MC1mOThmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAw
MGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQr
IDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBN
QWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNj
VG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5h
Z2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJy
ZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRp
ZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZD
YXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0
bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJ
CVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0YToJQ29yckVy
ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0K
CQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEs
IExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cwoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RS
ZXArIEJ3Tm90KwoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2Fi
bGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCA1R1QvcywgV2lkdGggeDEsIFRy
RXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdCsKCQlTbHRD
YXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBT
dXJwcmlzZS0KCQkJU2xvdCAjNCwgUG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5v
Q29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0
LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3du
LCBQd3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czog
QXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJ
CQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsKCQlSb290Q3RsOiBFcnJDb3Jy
ZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxl
LQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJh
bmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZCsKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRp
bWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwyOiBU
YXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBT
ZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9y
bWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFu
Y2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3Vy
cmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJ
OiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlM2Yw
MGMgIERhdGE6IDQxODkKCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNo
bm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5
cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKwoJQ2FwYWJpbGl0aWVz
OiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEg
TGVuPTAxMCA8Pz4KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2Vy
dmljZXMKCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVk
aXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysKCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9y
dAoKMDA6MTEuMCBTQVRBIGNvbnRyb2xsZXIgWzAxMDZdOiBBVEkgVGVjaG5vbG9naWVzIElu
YyBTQjd4MC9TQjh4MC9TQjl4MCBTQVRBIENvbnRyb2xsZXIgW0lERSBtb2RlXSBbMTAwMjo0
MzkwXSAocmV2IDQwKSAocHJvZy1pZiAwMSBbQUhDSSAxLjBdKQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQoJQ29u
dHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9v
cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog
Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRv
IElSUSAxMjEKCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQoJUmVnaW9u
IDE6IEkvTyBwb3J0cyBhdCA2MDAwIFtzaXplPTRdCglSZWdpb24gMjogSS9PIHBvcnRzIGF0
IDUwMDAgW3NpemU9OF0KCVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQoJ
UmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCAyMDAwIFtzaXplPTE2XQoJUmVnaW9uIDU6IE1lbW9y
eSBhdCBmOTZmZjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xS10KCUNh
cGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS80IE1hc2thYmxlLSA2NGJp
dCsKCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAxMDBjICBEYXRhOiA0MWMxCglDYXBhYmlsaXRp
ZXM6IFs3MF0gU0FUQSBIQkEgdjEuMCBJbkNmZ1NwYWNlCglDYXBhYmlsaXRpZXM6IFthNF0g
UENJIEFkdmFuY2VkIEZlYXR1cmVzCgkJQUZDYXA6IFRQKyBGTFIrCgkJQUZDdHJsOiBGTFIt
CgkJQUZTdGF0dXM6IFRQLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGFoY2kKCjAwOjEyLjAg
VVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4
MC9TQjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBb
T0hDSV0pCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4g
RGV2aWNlIFsxNDYyOjc2NDBdCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0
QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtCglMYXRlbmN5OiA2NCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50
ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4CglSZWdpb24gMDogTWVtb3J5IGF0IGY5
NmZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IG9oY2lfaGNkCgowMDoxMi4yIFVTQiBjb250cm9sbGVyIFswYzAzXTog
QVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kgQ29udHJv
bGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pCglTdWJzeXN0ZW06IE1pY3Jv
LVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBD
YXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0
LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiA2NCwg
Q2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8g
SVJRIDE3CglSZWdpb24gMDogTWVtb3J5IGF0IGY5NmZmNDAwICgzMi1iaXQsIG5vbi1wcmVm
ZXRjaGFibGUpIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGllczogW2MwXSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50
PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCgkJQnJpZGdlOiBQTS0g
QjMrCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTAK
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpLXBjaQoKMDA6MTMuMCBVU0IgY29udHJvbGxl
ciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBP
SENJMCBDb250cm9sbGVyIFsxMDAyOjQzOTddIChwcm9nLWlmIDEwIFtPSENJXSkKCVN1YnN5
c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6
NzY0MF0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
VisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgt
CglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk
aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh
dGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgMTgKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk2ZmMwMDAgKDMyLWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdCglLZXJuZWwgZHJpdmVyIGluIHVzZTog
b2hjaV9oY2QKCjAwOjEzLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgRUhDSSBDb250cm9sbGVyIFsxMDAyOjQz
OTZdIChwcm9nLWlmIDIwIFtFSENJXSkKCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5h
dGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0KCUNvbnRyb2w6IEkvTy0gTWVt
KyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHorIFVE
Ri0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxN
QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNp
emU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMTcKCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk2ZmY4MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MjU2XQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAy
CgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCss
RDErLEQyKyxEM2hvdCssRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVu
YWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCQlCcmlkZ2U6IFBNLSBCMysKCUNhcGFiaWxp
dGllczogW2U0XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBlMAoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IGVoY2ktcGNpCgowMDoxNC4wIFNNQnVzIFswYzA1XTogQVRJIFRlY2hub2xv
Z2llcyBJbmMgU0J4MDAgU01CdXMgQ29udHJvbGxlciBbMTAwMjo0Mzg1XSAocmV2IDQxKQoJ
Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1
czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IHBpaXg0X3NtYnVzCgowMDoxNC4xIElERSBpbnRlcmZhY2UgWzAxMDFd
OiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBJREUgQ29udHJvbGxl
ciBbMTAwMjo0MzljXSAocmV2IDQwKSAocHJvZy1pZiA4YSBbTWFzdGVyIFNlY1AgUHJpUF0p
CglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNl
IFsxNDYyOjc2NDBdCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMAoJUmVn
aW9uIDA6IEkvTyBwb3J0cyBhdCAwMWYwIFtzaXplPThdCglSZWdpb24gMTogSS9PIHBvcnRz
IGF0IDAzZjQgW3NpemU9MV0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgMDE3MCBbc2l6ZT04
XQoJUmVnaW9uIDM6IEkvTyBwb3J0cyBhdCAwMzc0IFtzaXplPTFdCglSZWdpb24gNDogSS9P
IHBvcnRzIGF0IGZmMDAgW3NpemU9MTZdCgowMDoxNC4zIElTQSBicmlkZ2UgWzA2MDFdOiBB
VEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMgaG9zdCBjb250cm9s
bGVyIFsxMDAyOjQzOWRdIChyZXYgNDApCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJu
YXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdCglDb250cm9sOiBJL08rIE1l
bSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUrIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0
ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBV
REYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwCgowMDoxNC40IFBDSSBi
cmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQngwMCBQQ0kgdG8gUENJIEJy
aWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAwMSBbU3VidHJhY3RpdmUgZGVj
b2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgt
CglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk
aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh
dGVuY3k6IDY0CglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMywgc3Vib3JkaW5hdGU9
MDMsIHNlYy1sYXRlbmN5PTY0CglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGEwMDAtMDAwMGFm
ZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZgoJUHJlZmV0Y2hh
YmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZgoJU2Vjb25kYXJ5
IHN0YXR1czogNjZNSHotIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0
LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eSsg
U0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rt
ci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCgowMDoxNC41IFVT
QiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAv
U0I5eDAgVVNCIE9IQ0kyIENvbnRyb2xsZXIgWzEwMDI6NDM5OV0gKHByb2ctaWYgMTAgW09I
Q0ldKQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIy
Qi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnIt
IERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJS
LSBJTlR4LQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVy
cnVwdDogcGluIEMgcm91dGVkIHRvIElSUSAxOAoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTZm
ZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10KCUtlcm5lbCBkcml2
ZXIgaW4gdXNlOiBvaGNpX2hjZAoKMDA6MTUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRl
Y2hub2xvZ2llcyBJbmMgU0I3MDAvU0I4MDAvU0I5MDAgUENJIHRvIFBDSSBicmlkZ2UgKFBD
SUUgcG9ydCAwKSBbMTAwMjo0M2EwXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pCglD
b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwg
Q2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9
MDIsIHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wCglJL08gYmVoaW5kIGJyaWRnZTog
MDAwMGYwMDAtMDAwMDBmZmYKCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBm
ZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAwMGZmZjAw
MDAwLTAwMDAwMDAwMDAwZmZmZmYKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJC
LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJS
LSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQt
ID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3Rh
dC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50
IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBt
QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs1
OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx
IDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz
OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxvYWQg
MTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlMbmtD
YXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBM
YXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJl
cCsgQndOb3QrCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMt
IEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIHVua25vd24sIFdpZHRoIHgxNiwg
VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQoJCQlTbG90ICMzMiwgUG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVz
RGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtu
b3duLCBQd3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1
czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldC0gSW50ZXJsb2Nr
LQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQtIExpbmtTdGF0ZS0KCQlSb290Q3RsOiBFcnJD
b3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNp
YmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAs
IFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6
IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZC0KCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQgoJCQkgVHJhbnNtaXQgTWFyZ2lu
OiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29t
cGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEy
OiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCCglDYXBhYmlsaXRpZXM6IFthMF0g
TVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrCgkJQWRkcmVzczogMDAw
MDAwMDBmZWUzZjAwYyAgRGF0YTogNDE5MQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3Rl
bTogQVRJIFRlY2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjAwMDBdCglDYXBhYmlsaXRp
ZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/PgoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
CgowMDoxNi4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
U0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHBy
b2ctaWYgMTAgW09IQ0ldKQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwg
Q28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01h
c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0g
U0VSUisgRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQg
Ynl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxOAoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOTZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZAoKMDA6MTYuMiBVU0IgY29udHJvbGxl
ciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBF
SENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQoJU3Vic3lz
dGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3
NjQwXQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
KyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0K
CVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRp
dW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEIg
cm91dGVkIHRvIElSUSAxNwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTZmZmMwMCAoMzItYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdCglDYXBhYmlsaXRpZXM6IFtjMF0gUG93
ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisg
QXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQoJCVN0YXR1
czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJCUJy
aWRnZTogUE0tIEIzKwoJQ2FwYWJpbGl0aWVzOiBbZTRdIERlYnVnIHBvcnQ6IEJBUj0xIG9m
ZnNldD0wMGUwCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhjaS1wY2kKCjAwOjE4LjAgSG9z
dCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAx
MGggUHJvY2Vzc29yIEh5cGVyVHJhbnNwb3J0IENvbmZpZ3VyYXRpb24gWzEwMjI6MTIwMF0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglDYXBhYmlsaXRp
ZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3IgU2Vjb25kYXJ5IEludGVyZmFjZQoJ
CUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBIb3N0SGlk
ZSsgU2xhdmUtIDxFT0NFcnItIERVTC0KCQlMaW5rIENvbnRyb2w6IENGbEUtIENTVC0gQ0ZF
LSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElzb2NFbi0gTFNFbisgRXh0
Q1RMLSA2NGItCgkJTGluayBDb25maWc6IE1MV0k9MTZiaXQgRHdGY0luLSBNTFdPPTE2Yml0
IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0IER3RmNPdXRFbi0KCQlS
ZXZpc2lvbiBJRDogMy4wMAoJCUxpbmsgRnJlcXVlbmN5OiBbYl0KCQlMaW5rIEVycm9yOiA8
UHJvdC0gPE92ZmwtIDxFT0MtIENUTFRtLQoJCUxpbmsgRnJlcXVlbmN5IENhcGFiaWxpdHk6
IDIwME1IeisgMzAwTUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4MDBNSHorIDEuMEdI
eisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0gVmVuZC0KCQlGZWF0dXJlIENhcGFiaWxpdHk6
IElzb2NGQysgTERUU1RPUCsgQ1JDVE0tIEVDVExULSA2NGJBKyBVSURSRC0gRXh0UlMtIFVD
bmZFLQoKMDA6MTguMSBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERldmlj
ZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgQWRkcmVzcyBNYXAgWzEwMjI6MTIwMV0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0
dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCgowMDoxOC4yIEhv
c3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkg
MTBoIFByb2Nlc3NvciBEUkFNIENvbnRyb2xsZXIgWzEwMjI6MTIwMl0KCUNvbnRyb2w6IEkv
Ty0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVy
ci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcC0gNjZN
SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCgowMDoxOC4zIEhvc3QgYnJpZGdlIFsw
NjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3Nv
ciBNaXNjZWxsYW5lb3VzIENvbnRyb2wgWzEwMjI6MTIwM10KCUNvbnRyb2w6IEkvTy0gTWVt
LSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglDYXBhYmlsaXRpZXM6IFtmMF0gU2VjdXJlIGRl
dmljZSA8Pz4KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBrMTB0ZW1wCgowMDoxOC40IEhvc3Qg
YnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBo
IFByb2Nlc3NvciBMaW5rIENvbnRyb2wgWzEwMjI6MTIwNF0KCUNvbnRyb2w6IEkvTy0gTWVt
LSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl
cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcC0gNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCgowMzowNi4wIE11bHRpbWVkaWEgYXVkaW8gY29u
dHJvbGxlciBbMDQwMV06IEMtTWVkaWEgRWxlY3Ryb25pY3MgSW5jIENNODczOCBbMTNmNjow
MTExXSAocmV2IDEwKQoJU3Vic3lzdGVtOiBDLU1lZGlhIEVsZWN0cm9uaWNzIEluYyBDTUk4
NzM4L0MzRFggUENJIEF1ZGlvIERldmljZSBbMTNmNjowMTExXQoJQ29udHJvbDogSS9PKyBN
ZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0g
VURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQgKDUwMG5zIG1pbiwg
NjAwMG5zIG1heCkKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAyMgoJUmVnaW9u
IDA6IEkvTyBwb3J0cyBhdCBhODAwIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGllczogW2MwXSBQ
b3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQy
KyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3Rh
dHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglL
ZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoKMDQ6MDAuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IE5FQyBDb3Jwb3JhdGlvbiB1UEQ3MjAyMDAgVVNCIDMuMCBIb3N0IENvbnRyb2xs
ZXIgWzEwMzM6MDE5NF0gKHJldiAwMykgKHByb2ctaWYgMzAgW1hIQ0ldKQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo0MjU3
XQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6
IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVk
IHRvIElSUSA0MAoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOThmZTAwMCAoNjQtYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT04S10KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5h
Z2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJy
ZW50PTM3NW1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxp
dGllczogWzcwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsKCQlB
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs5
MF0gTVNJLVg6IEVuYWJsZSsgQ291bnQ9OCBNYXNrZWQtCgkJVmVjdG9yIHRhYmxlOiBCQVI9
MCBvZmZzZXQ9MDAwMDEwMDAKCQlQQkE6IEJBUj0wIG9mZnNldD0wMDAwMTA4MAoJQ2FwYWJp
bGl0aWVzOiBbYTBdIEV4cHJlc3MgKHYyKSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9u
LUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRG
dW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk
UmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0g
VW5zdXBwUmVxLSBBdXhQd3IrIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVk
IDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDR1cywgTDEgdW5s
aW1pdGVkCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCgkJTG5rQ3Rs
OglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D
bGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNKyBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0K
CQlMbmtTdGE6CVNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
KyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENvbXBsZXRpb24gVGlt
ZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcysKCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtDdGwyOiBUYXJnZXQg
TGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3Rh
YmxlIERlLWVtcGhhc2lzOiAtNmRCCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVy
YXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJ
CQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQgoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNl
ZCBFcnJvciBSZXBvcnRpbmcKCQlVRVN0YToJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRU
Ty0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEt
IEFDU1Zpb2wtCgkJVUVNc2s6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0
QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9s
LQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBV
bnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJQ0VT
dGE6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRh
bEVycisKCQlDRU1zazoJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVv
dXQtIE5vbkZhdGFsRXJyKwoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdl
bkNhcC0gQ0dlbkVuLSBDaGtDYXAtIENoa0VuLQoJQ2FwYWJpbGl0aWVzOiBbMTQwIHYxXSBE
ZXZpY2UgU2VyaWFsIE51bWJlciBmZi1mZi1mZi1mZi1mZi1mZi1mZi1mZgoJQ2FwYWJpbGl0
aWVzOiBbMTUwIHYxXSAjMTgKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrCgowNTow
MC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBBVEkgVGVjaG5vbG9naWVz
IEluYyBOSSBUdXJrcyBbQU1EIFJhZGVvbiBIRCA2NTAwXSBbMTAwMjo2NzU5XSAocHJvZy1p
ZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vic3lzdGVtOiBQQyBQYXJ0bmVyIExpbWl0ZWQg
RGV2aWNlIFsxNzRiOmUxOTNdCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJS
LSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50ZXJy
dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDMyCglSZWdpb24gMDogTWVtb3J5IGF0IGIwMDAw
MDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MjU2TV0KCVJlZ2lvbiAyOiBNZW1v
cnkgYXQgZjk5YzAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTI4S10K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYjAwMCBbc2l6ZT0yNTZdCglFeHBhbnNpb24gUk9N
IGF0IGY5OWEwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10KCUNhcGFiaWxpdGllczogWzUw
XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEr
IEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
CglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJ
IDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVu
Y3kgTDBzIDw0dXMsIEwxIHVubGltaXRlZAoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQt
IFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVj
dGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkKyBFeHRU
YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRl
cywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0g
RmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0
ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEww
IDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
CgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJh
aW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBB
dXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnItIFRy
YWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENv
bXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysKCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdpbjog
Tm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBs
aWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjog
Q3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1T
STogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAwMDAw
MDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9y
IFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglDYXBh
YmlsaXRpZXM6IFsxNTAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglE
TFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9G
LSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVT
LSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRM
UC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0g
RkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JD
LSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0g
Um9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFkVExQ
LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglG
aXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4t
CglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoKMDU6MDAuMSBBdWRpbyBkZXZpY2Ug
WzA0MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6YWE5MF0KCVN1YnN5
c3RlbTogUEMgUGFydG5lciBMaW1pdGVkIERldmljZSBbMTc0YjphYTkwXQoJQ29udHJvbDog
SS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUludGVycnVwdDogcGluIEIgcm91
dGVkIHRvIElSUSAzMwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTlmYzAwMCAoNjQtYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTE2S10KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0p
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwg
TVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIDw0dXMsIEwxIHVubGltaXRlZAoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5J
bmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29y
cmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkKyBF
eHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBi
eXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVy
ci0gRmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQ
b3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5
IEwwIDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndO
b3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50
LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnIt
IFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysKCQlEZXZDdGwy
OiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0KCQlMbmtD
dGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVl
ZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEIKCQkJIFRyYW5zbWl0IE1hcmdp
bjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENv
bXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQgoJQ2FwYWJpbGl0aWVzOiBbYTBd
IE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAw
MDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVu
ZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglD
YXBhYmlsaXRpZXM6IFsxNTAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3Rh
OglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBS
eE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBT
REVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFs
ZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRM
UC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBF
Q1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExM
UC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFk
VExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2Fw
OglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hr
RW4tCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjawoKMDY6MDAuMCBNdWx0aW1lZGlh
IHZpZGVvIGNvbnRyb2xsZXIgWzA0MDBdOiBDb25leGFudCBTeXN0ZW1zLCBJbmMuIERldmlj
ZSBbMTRmMTo4MjEwXQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDog
cGluIEEgcm91dGVkIHRvIElSUSA0NwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWEwMDAwMCAo
NjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yTV0KCUNhcGFiaWxpdGllczogWzQw
XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlF
eHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0
bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3Vw
cG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29w
KwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDJ1cywgTDEgPDR1cwoJCQlDbG9ja1BNLSBTdXJw
cmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0
IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9z
LCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBB
QldNZ210LQoJQ2FwYWJpbGl0aWVzOiBbODBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAz
CgkJRmxhZ3M6IFBNRUNsay0gRFNJKyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCss
RDErLEQyKyxEM2hvdCssRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVu
YWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzkwXSBWaXRhbCBQ
cm9kdWN0IERhdGEKCQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDIsIHdpbGwgbm90
IGRlY29kZSBtb3JlLgoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6
IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5n
CgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54
Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNr
OglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBS
eE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsg
U0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1h
bGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQ
LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4
RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisK
CQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hr
Q2FwLSBDaGtFbi0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBDaGFubmVsCgkJ
Q2FwczoJTFBFVkM9MSBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKCQlBcmI6CUZpeGVk
KyBXUlIzMisgV1JSNjQrIFdSUjEyOC0KCQlDdHJsOglBcmJTZWxlY3Q9V1JSNjQKCQlTdGF0
dXM6CUluUHJvZ3Jlc3MtCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQwXSA8Pz4KCQlW
QzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQoJ
CQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQoJ
CQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmCgkJCVN0YXR1
czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtCgkJVkMxOglDYXBzOglQQVRPZmZzZXQ9MDAg
TWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdS
UjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0KCQkJQ3RybDoJRW5hYmxlLSBJRD0xIEFy
YlNlbGVjdD1GaXhlZCBUQy9WQz0wMAoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dy
ZXNzLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sKCjA3OjAwLjAgVVNCIGNvbnRy
b2xsZXIgWzBjMDNdOiBORUMgQ29ycG9yYXRpb24gdVBENzIwMjAwIFVTQiAzLjAgSG9zdCBD
b250cm9sbGVyIFsxMDMzOjAxOTRdIChyZXYgMDMpIChwcm9nLWlmIDMwIFtYSENJXSkKCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgNDgKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjljZmUwMDAgKDY0LWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9OEtdCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93
ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0g
QXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3Rh
dHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglD
YXBhYmlsaXRpZXM6IFs3MF0gTVNJOiBFbmFibGUtIENvdW50PTEvOCBNYXNrYWJsZS0gNjRi
aXQrCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0
aWVzOiBbOTBdIE1TSS1YOiBFbmFibGUrIENvdW50PTggTWFza2VkLQoJCVZlY3RvciB0YWJs
ZTogQkFSPTAgb2Zmc2V0PTAwMDAxMDAwCgkJUEJBOiBCQVI9MCBvZmZzZXQ9MDAwMDEwODAK
CUNhcGFiaWxpdGllczogW2EwXSBFeHByZXNzICh2MikgRW5kcG9pbnQsIE1TSSAwMAoJCURl
dkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1
bmxpbWl0ZWQsIEwxIHVubGltaXRlZAoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3
ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFi
bGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRUYWct
IFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0gRmF0
YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyKyBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMw
LCBTcGVlZCA1R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw0dXMs
IEwxIHVubGltaXRlZAoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJ
CUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWlu
LSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQTSsgQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtCgkJTG5rU3RhOglTcGVlZCA1R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0g
U2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCQlEZXZDYXAyOiBDb21wbGV0
aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQsIFRpbWVvdXREaXMrCgkJRGV2Q3RsMjogQ29t
cGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtCgkJTG5rQ3RsMjog
VGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwg
U2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQgoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3Jt
YWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5j
ZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJy
ZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIKCUNhcGFiaWxpdGllczogWzEwMCB2MV0g
QWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1At
IENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVu
c3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRP
LSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0g
QUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0
QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9s
LQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0g
Tm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVy
LSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6
IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtFbi0KCUNhcGFiaWxpdGllczogWzE0
MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgZmYtZmYtZmYtZmYtZmYtZmYtZmYtZmYKCUNh
cGFiaWxpdGllczogWzE1MCB2MV0gIzE4CglLZXJuZWwgZHJpdmVyIGluIHVzZTogeGhjaV9o
Y2QKCjA4OjAwLjAgRXRoZXJuZXQgY29udHJvbGxlciBbMDIwMF06IFJlYWx0ZWsgU2VtaWNv
bmR1Y3RvciBDby4sIEx0ZC4gUlRMODExMS84MTY4QiBQQ0kgRXhwcmVzcyBHaWdhYml0IEV0
aGVybmV0IGNvbnRyb2xsZXIgWzEwZWM6ODE2OF0gKHJldiAwMykKCVN1YnN5c3RlbTogTWlj
cm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6
IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0
LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBD
YWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJ
UlEgMTIzCglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGM4MDAgW3NpemU9MjU2XQoJUmVnaW9u
IDI6IE1lbW9yeSBhdCBjZmVmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRL
XQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmVmODAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUp
IFtzaXplPTE2S10KCUV4cGFuc2lvbiBST00gYXQgZjlkZTAwMDAgW2Rpc2FibGVkXSBbc2l6
ZT0xMjhLXQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAz
CgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQw
KyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTog
RW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAwMDAwMDAw
ZmVlMDEwMGMgIERhdGE6IDQxMjIKCUNhcGFiaWxpdGllczogWzcwXSBFeHByZXNzICh2Mikg
RW5kcG9pbnQsIE1TSSAwMQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2NHVzCgkJCUV4dFRhZy0gQXR0bkJ0
bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJy
b3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3AtCgkJCU1heFBheWxv
YWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVycisg
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3IrIFRyYW5zUGVuZC0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwg
TGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFj
dFJlcC0gQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWRE
aXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtCgkJ
RGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlz
KwoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0
RGlzLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBs
aWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQgoJCQkgVHJh
bnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29t
cGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCCglDYXBhYmls
aXRpZXM6IFthY10gTVNJLVg6IEVuYWJsZS0gQ291bnQ9NCBNYXNrZWQtCgkJVmVjdG9yIHRh
YmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDAKCQlQQkE6IEJBUj00IG9mZnNldD0wMDAwMDgw
MAoJQ2FwYWJpbGl0aWVzOiBbY2NdIFZpdGFsIFByb2R1Y3QgRGF0YQoJCVVua25vd24gc21h
bGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2RlIG1vcmUuCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglETFAtIFNE
RVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxm
VExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAt
IEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNS
Qy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBD
bXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1
cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnIrIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92
ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRE
TExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJzdCBF
cnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tCglDYXBh
YmlsaXRpZXM6IFsxNDAgdjFdIFZpcnR1YWwgQ2hhbm5lbAoJCUNhcHM6CUxQRVZDPTAgUmVm
Q2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBX
UlIxMjgtCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkCgkJU3RhdHVzOglJblByb2dyZXNzLQoJ
CVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMt
CgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYt
CgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYKCQkJU3Rh
dHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0KCUNhcGFiaWxpdGllczogWzE2MCB2MV0g
RGV2aWNlIFNlcmlhbCBOdW1iZXIgMDMtMDAtMDAtMDAtNjgtNGMtZTAtMDAKCUtlcm5lbCBk
cml2ZXIgaW4gdXNlOiByODE2OQoKMDk6MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyIFswMjAw
XTogUmVhbHRlayBTZW1pY29uZHVjdG9yIENvLiwgTHRkLiBSVEw4MTExLzgxNjhCIFBDSSBF
eHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQgY29udHJvbGxlciBbMTBlYzo4MTY4XSAocmV2IDAz
KQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmlj
ZSBbMTQ2Mjo3NjQwXQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0g
RGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDog
cGluIEEgcm91dGVkIHRvIElSUSAxMjIKCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgZDgwMCBb
c2l6ZT0yNTZdCglSZWdpb24gMjogTWVtb3J5IGF0IGNmZmZmMDAwICg2NC1iaXQsIHByZWZl
dGNoYWJsZSkgW3NpemU9NEtdCglSZWdpb24gNDogTWVtb3J5IGF0IGNmZmY4MDAwICg2NC1i
aXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZLXQoJRXhwYW5zaW9uIFJPTSBhdCBmOWVlMDAw
MCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3Vy
cmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrCgkJ
QWRkcmVzczogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFkMQoJQ2FwYWJpbGl0aWVzOiBb
NzBdIEV4cHJlc3MgKHYyKSBFbmRwb2ludCwgTVNJIDAxCgkJRGV2Q2FwOglNYXhQYXlsb2Fk
IDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJucywgTDEgPDY0dXMK
CQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlE
ZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBV
bnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNDA5NiBieXRlcwoJ
CURldlN0YToJQ29yckVycisgVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQ
d3IrIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzCgkJCUNsb2Nr
UE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBC
V01nbXQtIEFCV01nbXQtCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3Vw
cG9ydGVkLCBUaW1lb3V0RGlzKwoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1
cyB0byA1MG1zLCBUaW1lb3V0RGlzLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAy
LjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBo
YXNpczogLTZkQgoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdl
LCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFu
Y2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExl
dmVsOiAtNmRCCglDYXBhYmlsaXRpZXM6IFthY10gTVNJLVg6IEVuYWJsZS0gQ291bnQ9NCBN
YXNrZWQtCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDAKCQlQQkE6IEJB
Uj00IG9mZnNldD0wMDAwMDgwMAoJQ2FwYWJpbGl0aWVzOiBbY2NdIFZpdGFsIFByb2R1Y3Qg
RGF0YQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2Rl
IG1vcmUuCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGlu
ZwoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVu
eENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1z
azoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0g
UnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFAr
IFNERVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBN
YWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnIrIEJhZFRM
UC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKwoJCUNFTXNrOglS
eEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIr
CgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENo
a0NhcCsgQ2hrRW4tCglDYXBhYmlsaXRpZXM6IFsxNDAgdjFdIFZpcnR1YWwgQ2hhbm5lbAoJ
CUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xCgkJQXJiOglGaXhl
ZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkCgkJU3Rh
dHVzOglJblByb2dyZXNzLQoJCVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90
cz0xIFJlalNub29wVHJhbnMtCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4
LSBUV1JSMTI4LSBXUlIyNTYtCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4
ZWQgVEMvVkM9ZmYKCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0KCUNhcGFi
aWxpdGllczogWzE2MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgMDQtMDAtMDAtMDAtNjgt
NGMtZTAtMDAKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQoKMGE6MDAuMCBQQ0kgYnJp
ZGdlIFswNjA0XTogVGV4YXMgSW5zdHJ1bWVudHMgWElPMjAwMChBKS9YSU8yMjAwQSBQQ0kg
RXhwcmVzcy10by1QQ0kgQnJpZGdlIFsxMDRjOjgyMzFdIChyZXYgMDMpIChwcm9nLWlmIDAw
IFtOb3JtYWwgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglCdXM6IHBy
aW1hcnk9MGEsIHNlY29uZGFyeT0wYiwgc3Vib3JkaW5hdGU9MGIsIHNlYy1sYXRlbmN5PTY0
CglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYKCU1lbW9yeSBiZWhpbmQg
YnJpZGdlOiBmOWYwMDAwMC1mOWZmZmZmZgoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQg
YnJpZGdlOiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYKCVNlY29uZGFyeSBz
dGF0dXM6IDY2TUh6LSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydCsgPFNFUlItIDxQRVJSLQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNF
UlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJCVByaURpc2NUbXIt
IFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2FwYWJpbGl0aWVz
OiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xk
LSkKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0KCQlCcmlkZ2U6IFBNLSBCMysKCUNhcGFiaWxpdGllczogWzYwXSBNU0k6IEVuYWJs
ZS0gQ291bnQ9MS8xNiBNYXNrYWJsZS0gNjRiaXQrCgkJQWRkcmVzczogMDAwMDAwMDAwMDAw
MDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVzOiBbODBdIFN1YnN5c3RlbTogR2FtbWFn
cmFwaHgsIEluYy4gKG9yIG1pc3NpbmcgSUQpIERldmljZSBbMDAwMDowMDAwXQoJQ2FwYWJp
bGl0aWVzOiBbOTBdIEV4cHJlc3MgKHYxKSBQQ0kvUENJLVggQnJpZGdlLCBNU0kgMDAKCQlE
ZXZDYXA6CU1heFBheWxvYWQgNTEyIGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDR1cywgTDEgPDY0dXMKCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJC
RS0gRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24t
RmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1
bmMtIEF1eFB3ci0gTm9Tbm9vcCsgQnJDb25mUnRyeS0KCQkJTWF4UGF5bG9hZCAxMjggYnl0
ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnIr
IEZhdGFsRXJyLSBVbnN1cHBSZXErIEF1eFB3cisgVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9y
dCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEww
IDwxdXMsIEwxIDwxNnVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
CgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0K
CQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxu
a1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg
RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2
YW5jZWQgRXJyb3IgUmVwb3J0aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENt
cGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3Vw
UmVxKyBBQ1NWaW9sLQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBD
bXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNT
VmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJy
dC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJ
CUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9u
RmF0YWxFcnItCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBU
aW1lb3V0LSBOb25GYXRhbEVyci0KCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDE0
LCBHZW5DYXArIENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0KCjBiOjAxLjAgVVNCIGNvbnRyb2xs
ZXIgWzBjMDNdOiBORUMgQ29ycG9yYXRpb24gVVNCIFsxMDMzOjAwMzVdIChyZXYgNDMpIChw
cm9nLWlmIDEwIFtPSENJXSkKCVN1YnN5c3RlbTogTkVDIENvcnBvcmF0aW9uIEhhbWEgVVNC
IDIuMCBDYXJkQnVzIFsxMDMzOjAwMzVdCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkIt
IFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS
Ui0gPFBFUlItIElOVHgtCglMYXRlbmN5OiA2NCAoMjUwbnMgbWluLCAxMDUwMG5zIG1heCks
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRv
IElSUSAyOQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZDAwMCAoMzItYml0LCBub24tcHJl
ZmV0Y2hhYmxlKSBbc2l6ZT00S10KCUNhcGFiaWxpdGllczogWzQwXSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50
PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogb2hjaV9oY2QKCjBiOjAxLjEgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBORUMg
Q29ycG9yYXRpb24gVVNCIFsxMDMzOjAwMzVdIChyZXYgNDMpIChwcm9nLWlmIDEwIFtPSENJ
XSkKCVN1YnN5c3RlbTogTkVDIENvcnBvcmF0aW9uIEhhbWEgVVNCIDIuMCBDYXJkQnVzIFsx
MDMzOjAwMzVdCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJ
TlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
CglMYXRlbmN5OiA2NCAoMjUwbnMgbWluLCAxMDUwMG5zIG1heCksIENhY2hlIExpbmUgU2l6
ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAzMAoJUmVnaW9u
IDA6IE1lbW9yeSBhdCBmOWZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6
ZT00S10KCUNhcGFiaWxpdGllczogWzQwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJ
CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFi
bGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9o
Y2QKCjBiOjAxLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBORUMgQ29ycG9yYXRpb24gVVNC
IDIuMCBbMTAzMzowMGUwXSAocmV2IDA0KSAocHJvZy1pZiAyMCBbRUhDSV0pCglTdWJzeXN0
ZW06IERldmljZSBbMTgzODoxMDc0XQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt
IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogNjQgKDQwMDBucyBtaW4sIDg1MDBucyBtYXgpLCBD
YWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJ
UlEgMzEKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZmZjMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9MjU2XQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1l
bnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9
MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkKCQlTdGF0dXM6IEQwIE5vU29m
dFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBlaGNpLXBjaQoKMGM6MDAuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVyIFsw
MzAwXTogblZpZGlhIENvcnBvcmF0aW9uIEc5OCBbR2VGb3JjZSA4NDAwIEdTXSBbMTBkZTow
NmU0XSAocmV2IGExKSAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vic3lzdGVt
OiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjgyNjZdCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2
TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9y
dC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGlu
ZSBTaXplOiA2NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEwCglS
ZWdpb24gMDogTWVtb3J5IGF0IGZkMDAwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp
IFtzaXplPTE2TV0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZDAwMDAwMDAgKDY0LWJpdCwgcHJl
ZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQoJUmVnaW9uIDM6IE1lbW9yeSBhdCBmYTAwMDAwMCAo
NjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dCglSZWdpb24gNTogSS9PIHBv
cnRzIGF0IGU4MDAgW3NpemU9MTI4XQoJRXhwYW5zaW9uIFJPTSBhdCBmZTllMDAwMCBbZGlz
YWJsZWRdIFtzaXplPTEyOEtdCglDYXBhYmlsaXRpZXM6IFs2MF0gUG93ZXIgTWFuYWdlbWVu
dCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0w
bUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0
UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBb
NjhdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6
IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzc4XSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0
ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw0dXMKCQkJRXh0VGFn
KyBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJ
TWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BN
IEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDwxdXMKCQkJQ2xvY2tQTS0gU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiAxMjgg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BN
LSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms
IFdpZHRoIHg4LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFC
V01nbXQtCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbAoJCUNhcHM6
CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xCgkJQXJiOglGaXhlZC0gV1JS
MzItIFdSUjY0LSBXUlIxMjgtCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkCgkJU3RhdHVzOglJ
blByb2dyZXNzLQoJCVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJl
alNub29wVHJhbnMtCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JS
MTI4LSBXUlIyNTYtCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMv
VkM9ZmYKCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0KCUNhcGFiaWxpdGll
czogWzEyOCB2MV0gUG93ZXIgQnVkZ2V0aW5nIDw/PgoJQ2FwYWJpbGl0aWVzOiBbNjAwIHYx
XSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAyNCA8
Pz4KCg==
------------0FB1ED1493275D29B
Content-Type: application/octet-stream;
 name="v39sync.log"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="v39sync.log"

ICBfXyAgX18gICAgICAgICAgICBfICBfICAgIF9fX19fICAgICAgICAgICAgICAgICAgICBf
ICAgICAgICBfICAgICBfICAgICAgDQogIFwgXC8gL19fXyBfIF9fICAgfCB8fCB8ICB8X19f
IC8gICAgXyAgIF8gXyBfXyAgX19ffCB8XyBfXyBffCB8X18gfCB8IF9fXyANCiAgIFwgIC8v
IF8gXCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8
ICdfIFx8IHwvIF8gXA0KICAgLyAgXCAgX18vIHwgfCB8IHxfXyAgIF98IF9fXykgfF9ffCB8
X3wgfCB8IHwgXF9fIFwgfHwgKF98IHwgfF8pIHwgfCAgX18vDQogIC9fL1xfXF9fX3xffCB8
X3wgICAgfF98KF8pX19fXy8gICAgXF9fLF98X3wgfF98X19fL1xfX1xfXyxffF8uX18vfF98
XF9fX3wNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIChYRU4pIFhlbiB2ZXJzaW9uIDQuMy11
bnN0YWJsZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40LjUtOCkgNC40LjUp
IGRlYnVnPXkgVHVlIEZlYiAyNiAxMTozMTowOSBDRVQgMjAxMw0KIChYRU4pIExhdGVzdCBD
aGFuZ2VTZXQ6IHVuYXZhaWxhYmxlDQogKFhFTikgQ29uc29sZSBvdXRwdXQgaXMgc3luY2hy
b25vdXMuDQogKFhFTikgQm9vdGxvYWRlcjogR1JVQiAxLjk4KzIwMTAwODA0LTE0K3NxdWVl
emUxDQogKFhFTikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9n
bHZsPWFsbCBsb2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyBzeW5jX2NvbnNv
bGUgdmdhPWdmeC0xMjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBk
ZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11
PW9uLHZlcmJvc2UsZGVidWcsYW1kLWlvbW11LWRlYnVnLG5vLWFtZC1pb21tdS1wZXJkZXYt
aW50cmVtYXAgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2EsY29tMQ0KIChYRU4pIFZpZGVv
IGluZm9ybWF0aW9uOg0KIChYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQs
IDMyIGJwcA0KIChYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRp
bWU6IDEgc2Vjb25kcw0KIChYRU4pIERpc2MgaW5mb3JtYXRpb246DQogKFhFTikgIEZvdW5k
IDIgTUJSIHNpZ25hdHVyZXMNCiAoWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3Ry
dWN0dXJlcw0KIChYRU4pIFhlbi1lODIwIFJBTSBtYXA6DQogKFhFTikgIDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDlmMDAwICh1c2FibGUpDQogKFhFTikgIDAwMDAwMDAwMDAw
OWYwMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZlZCkNCiAoWEVOKSAgMDAwMDAwMDAw
MDBlNDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KIChYRU4pICAwMDAwMDAw
MDAwMTAwMDAwIC0gMDAwMDAwMDBhZmY5MDAwMCAodXNhYmxlKQ0KIChYRU4pICAwMDAwMDAw
MGFmZjkwMDAwIC0gMDAwMDAwMDBhZmY5ZTAwMCAoQUNQSSBkYXRhKQ0KIChYRU4pICAwMDAw
MDAwMGFmZjllMDAwIC0gMDAwMDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQogKFhFTikgIDAw
MDAwMDAwYWZmZTAwMDAgLSAwMDAwMDAwMGIwMDAwMDAwIChyZXNlcnZlZCkNCiAoWEVOKSAg
MDAwMDAwMDBmZmUwMDAwMCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KIChYRU4p
ICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KIChYRU4p
IEFDUEk6IFJTRFAgMDAwRkIxMDAsIDAwMTQgKHIwIEFDUElBTSkNCiAoWEVOKSBBQ1BJOiBS
U0RUIEFGRjkwMDAwLCAwMDQ4IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAg
ICAgICA5NykNCiAoWEVOKSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMg
QTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCiAoWEVOKSBBQ1BJOiBEU0RUIEFG
RjkwNUUwLCA5NDI3IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAgSU5UTCAyMDA1MTEx
NykNCiAoWEVOKSBBQ1BJOiBGQUNTIEFGRjlFMDAwLCAwMDQwDQogKFhFTikgQUNQSTogQVBJ
QyBBRkY5MDM5MCwgMDA4OCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAg
ICAgOTcpDQogKFhFTikgQUNQSTogTUNGRyBBRkY5MDQyMCwgMDAzQyAocjEgNzY0ME1TIE9F
TU1DRkcgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQogKFhFTikgQUNQSTogU0xJQyBBRkY5
MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcp
DQogKFhFTikgQUNQSTogT0VNQiBBRkY5RTA0MCwgMDA3MiAocjEgNzY0ME1TIEE3NjQwMTAw
IDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQogKFhFTikgQUNQSTogU1JBVCBBRkY5QTVFMCwg
MDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEpDQogKFhF
TikgQUNQSTogSFBFVCBBRkY5QTZGMCwgMDAzOCAocjEgNzY0ME1TIE9FTUhQRVQgIDIwMTAw
OTEzIE1TRlQgICAgICAgOTcpDQogKFhFTikgQUNQSTogSVZSUyBBRkY5QTczMCwgMDEwMCAo
cjEgIEFNRCAgICAgUkQ4OTBTICAgMjAyMDMxIEFNRCAgICAgICAgIDApDQogKFhFTikgQUNQ
STogU1NEVCBBRkY5QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAxIEFN
RCAgICAgICAgIDEpDQogKFhFTikgU3lzdGVtIFJBTTogODE5MU1CICg4Mzg3Nzcya0IpDQog
KFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0KIChYRU4pIFNSQVQ6IFBY
TSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCiAoWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDIg
LT4gTm9kZSAwDQogKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+IE5vZGUgMA0KIChY
RU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCiAoWEVOKSBTUkFUOiBQWE0g
MCAtPiBBUElDIDUgLT4gTm9kZSAwDQogKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDAtYTAw
MDANCiAoWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWIwMDAwMDAwDQogKFhFTikg
U1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC0yNTAwMDAwMDANCiAoWEVOKSBOVU1BOiBB
bGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZDg4MjAwMCAtIDI0ZDg4NTAwMA0KIChYRU4p
IE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KIChYRU4pIERvbWFpbiBoZWFw
IGluaXRpYWxpc2VkDQogKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGZiMDAwMDAw
LCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDgxMDAwLCB1c2luZyA2MTQ0aywgdG90YWwgMTQz
MzZrDQogKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01
MTIwLCBmb250IDh4MTYNCiAoWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04Ojg6ODo4
LCBzaGlmdD0yNDoxNjo4OjANCiAoWEVOKSBmb3VuZCBTTVAgTVAtdGFibGUgYXQgMDAwZmY3
ODANCiAoWEVOKSBETUkgcHJlc2VudC4NCiAoWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMgJ3hh
cGljJw0KIChYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCiAoWEVOKSBBQ1BJOiBQ
TS1UaW1lciBJTyBQb3J0OiAweDgwOA0KIChYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhf
Y250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdDQogKFhFTikgQUNQSTogICAgICAgICAgICAg
d2FrZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KIChYRU4pIEFDUEk6IExvY2Fs
IEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQogKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCiAoWEVOKSBQcm9jZXNzb3IgIzAgMDox
MCBBUElDIHZlcnNpb24gMTYNCiAoWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBs
YXBpY19pZFsweDAxXSBlbmFibGVkKQ0KIChYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMg
dmVyc2lvbiAxNg0KIChYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lk
WzB4MDJdIGVuYWJsZWQpDQogKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQogKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10g
ZW5hYmxlZCkNCiAoWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCiAo
WEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVk
KQ0KIChYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KIChYRU4pIEFD
UEk6IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQogKFhF
TikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQogKFhFTikgQUNQSTogSU9B
UElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KIChYRU4p
IElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAs
IEdTSSAwLTIzDQogKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVj
MjAwMDBdIGdzaV9iYXNlWzI0XSkNCiAoWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVy
c2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNCiAoWEVOKSBBQ1BJOiBJ
TlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KIChY
RU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxv
dyBsZXZlbCkNCiAoWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQogKFhFTikg
QUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLg0KIChYRU4pIEFDUEk6IElSUTkgdXNlZCBi
eSBvdmVycmlkZS4NCiAoWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcg
MiBJL08gQVBJQ3MNCiAoWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQw
MDAwMA0KIChYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCiAoWEVOKSBVc2luZyBBQ1BJIChN
QURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCiAoWEVOKSBTTVA6IEFs
bG93aW5nIDYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQogKFhFTikgbWFwcGVkIEFQSUMgdG8g
ZmZmZjgyYzNmZmRmYjAwMCAoZmVlMDAwMDApDQogKFhFTikgbWFwcGVkIElPQVBJQyB0byBm
ZmZmODJjM2ZmZGZhMDAwIChmZWMwMDAwMCkNCiAoWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZm
ZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAwKQ0KIChYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwg
MTExMiBNU0kvTVNJLVgNCiAoWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2No
ZWR1bGVyIChjcmVkaXQpDQogKFhFTikgRGV0ZWN0ZWQgMzIwMC4xOTggTUh6IHByb2Nlc3Nv
ci4NCiAoWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KIChYRU4pIEFNRCBGYW0xMGgg
bWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KIChYRU4pIFBDSTogTUNGRyBjb25m
aWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYN
CiAoWEVOKSBQQ0k6IE5vdCB1c2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZm
DQogKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kgY2FwYWJpbGl0eSBibG9jayBhdCAweDU0DQog
KFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KIChYRU4pIEFNRC1WaTogIFNpZ25hdHVyZSBJ
VlJTDQogKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4MTAwDQogKFhFTikgQU1ELVZpOiAgUmV2
aXNpb24gMHgxDQogKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHg4OQ0KIChYRU4pIEFNRC1W
aTogIE9FTV9JZCBBTUQgIA0KIChYRU4pIEFNRC1WaTogIE9FTV9UYWJsZV9JZCBSRDg5MFMN
CiAoWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCiAoWEVOKSBBTUQtVmk6
ICBDcmVhdG9yX0lkIEFNRCANCiAoWEVOKSBBTUQtVmk6ICBDcmVhdG9yX1JldmlzaW9uIDAN
CiAoWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgxMCBmbGFncyAweDNlIGxlbiAw
eGQwIGlkIDB4Mg0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgz
IGlkIDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDIN
CiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDEwIGZs
YWdzIDANCiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAw
eGMwMCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHgxOCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhMDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHg0MyBpZCAweGIwOCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweGIwOCAtPiAweGJmZiBhbGlhcyAweGIwMA0KIChYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4MjggZmxhZ3MgMA0KIChYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4OTAwIGZsYWdzIDANCiAo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDMwIGZsYWdz
IDANCiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDgw
MCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIg
aWQgMHg0OCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlw
ZSAweDIgaWQgMHg3MDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6IHR5cGUgMHgyIGlkIDB4NTAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjAwIGZsYWdzIDANCiAoWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDU4IGZsYWdzIDANCiAoWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAweDUwMCBmbGFncyAwDQogKFhF
TikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDUwMCAtPiAweDUwMQ0KIChYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NjggZmxhZ3MgMA0KIChYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgyIGlkIDB4NDAwIGZsYWdzIDAN
CiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MiBpZCAweDg4IGZs
YWdzIDANCiAoWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5OiB0eXBlIDB4MyBpZCAw
eDkwIGZsYWdzIDANCiAoWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5
Mg0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OTgg
ZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQog
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhMCBmbGFn
cyAweGQ3DQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQg
MHhhMSBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAw
eDIgaWQgMHhhMyBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTog
dHlwZSAweDIgaWQgMHhhNCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6IHR5cGUgMHg0MyBpZCAweDMwMCBmbGFncyAwDQogKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDMwMCAtPiAweDNmZiBhbGlhcyAweGE0DQogKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhNSBmbGFncyAwDQogKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhOCBmbGFncyAwDQogKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHhhOSBmbGFncyAw
DQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAweDIgaWQgMHgxMDAg
ZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlk
IDB4YjAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhiMCAtPiAw
eGIyDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxh
Z3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAw
IGZsYWdzIDB4ZDcNCiAoWEVOKSBBTUQtVmk6IElWSEQgU3BlY2lhbDogMDAwMDowMDoxNC4w
IHZhcmlldHkgMHgyIGhhbmRsZSAwDQogKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMA0KIChYRU4pIEFNRC1WaTogSVZIRCBTcGVjaWFs
OiAwMDAwOjAwOjAwLjEgdmFyaWV0eSAweDEgaGFuZGxlIDB4Nw0KIChYRU4pIElWSEQgRXJy
b3I6IG5vIGluZm9ybWF0aW9uIGZvciBJTy1BUElDIDB4Ng0KIChYRU4pIEFNRC1WaTogSU9N
TVUgMCBFbmFibGVkLg0KIChYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFsIHZlY3RvciBt
YXANCiAoWEVOKSBBTUQtVmk6IFVzaW5nIGdsb2JhbCBpbnRlcnJ1cHQgcmVtYXAgdGFibGUg
aXMgbm90IHJlY29tbWVuZGVkIChzZWUgWFNBLTM2KSENCiAoWEVOKSBJL08gdmlydHVhbGlz
YXRpb24gZW5hYmxlZA0KIChYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KIChYRU4pIEdl
dHRpbmcgVkVSU0lPTjogODAwNTAwMTANCiAoWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUw
MDEwDQogKFhFTikgR2V0dGluZyBJRDogMA0KIChYRU4pIEdldHRpbmcgTFZUMDogNzAwDQog
KFhFTikgR2V0dGluZyBMVlQxOiA0MDANCiAoWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUj
MA0KIChYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAweDQgIGFmdGVy
OiAwDQogKFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzDQogKFhFTikgIC0+IFVzaW5nIG5l
dyBBQ0sgbWV0aG9kDQogKFhFTikgaW5pdCBJT19BUElDIElSUXMNCiAoWEVOKSAgSU8tQVBJ
QyAoYXBpY2lkLXBpbikgNi0wLCA2LTE2LCA2LTE3LCA2LTE4LCA2LTE5LCA2LTIwLCA2LTIx
LCA2LTIyLCA2LTIzLCA3LTAsIDctMSwgNy0yLCA3LTMsIDctNCwgNy01LCA3LTYsIDctNywg
Ny04LCA3LTksIDctMTAsIDctMTEsIDctMTIsIDctMTMsIDctMTQsIDctMTUsIDctMTYsIDct
MTcsIDctMTgsIDctMTksIDctMjAsIDctMjEsIDctMjIsIDctMjMsIDctMjQsIDctMjUsIDct
MjYsIDctMjcsIDctMjgsIDctMjksIDctMzAsIDctMzEgbm90IGNvbm5lY3RlZC4NCiAoWEVO
KSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0x
DQogKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCiAoWEVOKSBudW1iZXIg
b2YgSU8tQVBJQyAjNiByZWdpc3RlcnM6IDI0Lg0KIChYRU4pIG51bWJlciBvZiBJTy1BUElD
ICM3IHJlZ2lzdGVyczogMzIuDQogKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uDQogKFhFTikgSU8gQVBJQyAjNi4uLi4uLg0KIChYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBB
UElDIGlkOiAwNg0KIChYRU4pIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBUeXBlOiAwDQogKFhF
TikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCiAoWEVOKSAuLi4uIHJlZ2lzdGVy
ICMwMTogMDAxNzgwMjENCiAoWEVOKSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBl
bnRyaWVzOiAwMDE3DQogKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDEN
CiAoWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KIChYRU4pIC4u
Li4gcmVnaXN0ZXIgIzAyOiAwNjAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRy
YXRpb246IDA2DQogKFhFTikgLi4uLiByZWdpc3RlciAjMDM6IDA3MDAwMDAwDQogKFhFTikg
Li4uLi4uLiAgICAgOiBCb290IERUICAgIDogMA0KIChYRU4pIC4uLi4gSVJRIHJlZGlyZWN0
aW9uIHRhYmxlOg0KIChYRU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQg
RGVzdCBEZWxpIFZlY3Q6ICAgDQogKFhFTikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAg
IDAgICAwICAgIDEgICAgMSAgICAzMA0KIChYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAw
ICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQogKFhFTikgIDAzIDAwMSAwMSAgMCAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgMzgNCiAoWEVOKSAgMDQgMDAxIDAxICAwICAgIDAg
ICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KIChYRU4pICAwNSAwMDEgMDEgIDAgICAg
MCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQogKFhFTikgIDA2IDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDgNCiAoWEVOKSAgMDcgMDAxIDAxICAw
ICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KIChYRU4pICAwOCAwMDEgMDEg
IDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4DQogKFhFTikgIDA5IDAwMSAw
MSAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNjANCiAoWEVOKSAgMGEgMDAx
IDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0KIChYRU4pICAwYiAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwDQogKFhFTikgIDBj
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzgNCiAoWEVOKSAg
MGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4OA0KIChYRU4p
ICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwDQogKFhF
TikgIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTgNCiAo
WEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
IChYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KIChYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQogKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KIChYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQogKFhFTikgSU8gQVBJQyAjNy4uLi4uLg0KIChYRU4pIC4uLi4gcmVn
aXN0ZXIgIzAwOiAwNzAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElD
IGlkOiAwNw0KIChYRU4pIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBUeXBlOiAwDQogKFhFTikg
Li4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCiAoWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MTogMDAxRjgwMjENCiAoWEVOKSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRy
aWVzOiAwMDFGDQogKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCiAo
WEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KIChYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAyOiAwMDAwMDAwMA0KIChYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRp
b246IDAwDQogKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQogKFhFTikgIE5S
IExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCiAo
WEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
IChYRU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogKFhFTikgIDAyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KIChYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQogKFhFTikgIDA1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KIChYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQogKFhFTikgIDA4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDBiIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDBlIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMGYgMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAxMCAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDExIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMTIgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAxMyAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDE0IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAgMTUgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4pICAxNiAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhFTikgIDE3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSAg
MTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIChYRU4p
ICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogKFhF
TikgIDFhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
IChYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogKFhFTikgIDFkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KIChYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQogKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nDQogKFhFTikgSVJR
IHRvIHBpbiBtYXBwaW5nczoNCiAoWEVOKSBJUlEyNDAgLT4gMDoyDQogKFhFTikgSVJRNDgg
LT4gMDoxDQogKFhFTikgSVJRNTYgLT4gMDozDQogKFhFTikgSVJRMjQxIC0+IDA6NA0KIChY
RU4pIElSUTY0IC0+IDA6NQ0KIChYRU4pIElSUTcyIC0+IDA6Ng0KIChYRU4pIElSUTgwIC0+
IDA6Nw0KIChYRU4pIElSUTg4IC0+IDA6OA0KIChYRU4pIElSUTk2IC0+IDA6OQ0KIChYRU4p
IElSUTEwNCAtPiAwOjEwDQogKFhFTikgSVJRMTEyIC0+IDA6MTENCiAoWEVOKSBJUlExMjAg
LT4gMDoxMg0KIChYRU4pIElSUTEzNiAtPiAwOjEzDQogKFhFTikgSVJRMTQ0IC0+IDA6MTQN
CiAoWEVOKSBJUlExNTIgLT4gMDoxNQ0KIChYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLiBkb25lLg0KIChYRU4pIFVzaW5nIGxvY2FsIEFQSUMgdGltZXIgaW50
ZXJydXB0cy4NCiAoWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KIChYRU4pIC4u
Li4uIENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE2MjYgTUh6Lg0KIChYRU4pIC4uLi4uIGhv
c3QgYnVzIGNsb2NrIHNwZWVkIGlzIDIwMC4wMTAwIE1Iei4NCiAoWEVOKSAuLi4uLiBidXNf
c2NhbGUgPSAweGNjZDcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0gUGxhdGZvcm0g
dGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0g
QWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MTk6NTJdIEhWTTogQVNJRHMgZW5hYmxlZC4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Ml0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MTk6NTJdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjE5OjUyXSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExCUikgVmlydHVh
bGlzYXRpb24NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0gIC0gTmV4dC1SSVAgU2F2
ZWQgb24gI1ZNRVhJVA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUyXSAgLSBQYXVzZS1J
bnRlcmNlcHQgRmlsdGVyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTJdIEhWTTogU1ZN
IGVuYWJsZWQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Ml0gSFZNOiBIYXJkd2FyZSBB
c3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Ml0gSFZNOiBIQVAgcGFnZSBzaXplczogNGtCLCAyTUIsIDFHQg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjE5OjUxXSBtYXNrZWQgRXh0SU5UIG9uIENQVSMxDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MTk6NTNdIG1pY3JvY29kZTogQ1BVMSBjb2xsZWN0X2NwdV9pbmZvOiBwYXRj
aF9pZD0weDEwMDAwYmYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1MV0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUzXSBtaWNyb2NvZGU6
IENQVTIgY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MTk6NTFdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1M10gbWljcm9jb2RlOiBDUFUzIGNvbGxlY3RfY3B1X2luZm86IHBh
dGNoX2lkPTB4MTAwMDBiZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUxXSBtYXNrZWQg
RXh0SU5UIG9uIENQVSM0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIG1pY3JvY29k
ZTogQ1BVNCBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToxOTo1MV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjE5OjUzXSBCcm91Z2h0IHVwIDYgQ1BVcw0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjE5OjUzXSBtaWNyb2NvZGU6IENQVTUgY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hf
aWQ9MHgxMDAwMGJmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIEhQRVQ6IDMgdGlt
ZXJzICgzIHdpbGwgYmUgdXNlZCBmb3IgYnJvYWRjYXN0KQ0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjE5OjUzXSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjUzXSBNQ0E6IFVzZSBodyB0aHJlc2hvbGRpbmcgdG8gYWRqdXN0IHBvbGxpbmcgZnJl
cXVlbmN5DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIG1jaGVja19wb2xsOiBNYWNo
aW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToxOTo1M10gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJQlMgTFZUIG9mZnNldCwg
SUJTQ1RMID0gMHhmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUzXSAqKiog
TE9BRElORyBET01BSU4gMCAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1M10gZWxm
X3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZGM5MDAwDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBh
ZGRyPTB4MWUwMDAwMCBtZW1zej0weGVhMGYwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6
NTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVlYjAwMCBtZW1zej0weDE0
MDQwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBo
ZHI6IHBhZGRyPTB4MWYwMDAwMCBtZW1zej0weGU2YjAwMA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjE5OjUzXSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDJk
NmIwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1M10gZWxmX3hlbl9wYXJzZV9ub3Rl
OiBHVUVTVF9PUyA9ICJsaW51eCINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1M10gZWxm
X3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToxOTo1M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9ICJ4ZW4t
My4wIg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjUzXSBlbGZfeGVuX3BhcnNlX25vdGU6
IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjUzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxZjAwMWUw
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFlQ
RVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToxOTo1M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFn
ZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYiINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MTk6NTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVy
aWMiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdIGVsZl94ZW5fcGFyc2Vfbm90ZTog
dW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1
NF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjE5OjU0XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9
IDB4ZmZmZjgwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSBlbGZf
eGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjE5OjU0XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZm
ZmY4MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgZWxmX3BhZGRy
X29mZnNldCA9IDB4MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9v
ZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjU0XSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZm
ZmZmZmY4MmQ2YjAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgICAgdmlydF9l
bnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWYwMDFlMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjE5OjU0XSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBj
b21wYXQzMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgRG9tMCBrZXJuZWw6IDY0
LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJkNmIwMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToxOTo1NF0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDI0MDAw
MDAwMC0+MDAwMDAwMDI0NDAwMDAwMCAoMjQyNTE2IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAy
NGYzNTQwMDAtPjAwMDAwMDAyNGZmZmZjMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1
NF0gVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBMb2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgyZDZi
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBJbml0LiByYW1kaXNrOiBmZmZm
ZmZmZjgyZDZiMDAwLT5mZmZmZmZmZjgzYTE2YzAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgzYTE3MDAwLT5mZmZmZmZmZjgzYzE3
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBTdGFydCBpbmZvOiAgICBmZmZm
ZmZmZjgzYzE3MDAwLT5mZmZmZmZmZjgzYzE3NGI0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzYzE4MDAwLT5mZmZmZmZmZjgzYzNi
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBCb290IHN0YWNrOiAgICBmZmZm
ZmZmZjgzYzNiMDAwLT5mZmZmZmZmZjgzYzNjMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTRdICBUT1RBTDogICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjg0MDAw
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdICBFTlRSWSBBRERSRVNTOiBmZmZm
ZmZmZjgxZjAwMWUwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdIERvbTAgaGFzIG1h
eGltdW0gNiBWQ1BVcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU0XSBlbGZfbG9hZF9i
aW5hcnk6IHBoZHIgMCBhdCAweGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxZGM5
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTRdIGVsZl9sb2FkX2JpbmFyeTogcGhk
ciAxIGF0IDB4ZmZmZmZmZmY4MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZWEwZjANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToxOTo1NF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhm
ZmZmZmZmZjgxZWViMDAwIC0+IDB4ZmZmZmZmZmY4MWVmZjA0MA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjE5OjU0XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODFm
MDAwMDAgLT4gMHhmZmZmZmZmZjgxZmZlMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6
NTVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDAsIHJvb3Qg
dGFibGUgPSAweDI0N2IxZTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MTk6NTVdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4Miwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgxMCwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgxOCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyOCwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgzMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MCwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHg1OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg2OCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MCwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHg5Miwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1NV0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg5YSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMSwg
cm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHhhMywgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNCwgcm9vdCB0
YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHhhNSwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhOCwgcm9vdCB0YWJsZSA9
IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHhiMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMiwgcm9vdCB0YWJsZSA9IDB4MjQ3
YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToxOTo1Nl0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBzZXR1cCAwMDAwOjAwOjE4LjAgZm9yIGQw
IGZhaWxlZCAoLTE5KQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MTk6NTZdIHNldHVwIDAwMDA6MDA6MTguMSBmb3IgZDAgZmFpbGVkICgtMTkpDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MTk6NTZdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAw
OjAwOjE4LjINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gc2V0dXAgMDAwMDowMDox
OC4yIGZvciBkMCBmYWlsZWQgKC0xOSkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0g
QU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjE5OjU2XSBzZXR1cCAwMDAwOjAwOjE4LjMgZm9yIGQwIGZhaWxlZCAoLTE5
KQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBBTUQtVmk6IE5vIGlvbW11IGZvciBk
ZXZpY2UgMDAwMDowMDoxOC40DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTZdIHNldHVw
IDAwMDA6MDA6MTguNCBmb3IgZDAgZmFpbGVkICgtMTkpDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MTk6NTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
NDAwLCByb290IHRhYmxlID0gMHgyNDdiMWUwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDUwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MDEs
IHJvb3QgdGFibGUgPSAweDI0N2IxZTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4NjAwLCByb290IHRhYmxlID0gMHgyNDdiMWUwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU2
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDcwMCwgcm9v
dCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg4MDAsIHJvb3QgdGFibGUgPSAweDI0N2IxZTAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTddIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4OTAwLCByb290IHRh
YmxlID0gMHgyNDdiMWUwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjE5OjU3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweGEwMCwgcm9vdCB0YWJsZSA9IDB4MjQ3YjFlMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1N10gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMDAsIHJvb3QgdGFibGUg
PSAweDI0N2IxZTAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MTk6NTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4YzAwLCByb290IHRhYmxlID0gMHgyNDdiMWUwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU3XSBTY3J1YmJpbmcg
RnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4NCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToxOTo1OV0gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQw
MDAgcGFnZXMuDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTldIFN0ZC4gTG9nbGV2ZWw6
IEFsbA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU5XSBHdWVzdCBMb2dsZXZlbDogQWxs
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MTk6NTldICoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1OV0g
KioqKioqKiBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjE5OjU5XSAqKioqKioqIFRoaXMgb3B0aW9uIGlzIGludGVuZGVk
IHRvIGFpZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MTk6NTldICoqKioqKiogdGhhdCBhbGwgb3V0cHV0IGlzIHN5bmNocm9ub3VzbHkg
ZGVsaXZlcmVkIG9uIHRoZSBzZXJpYWwgbGluZS4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMTox
OTo1OV0gKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0
ZW5jaWVzIGFuZCBhZmZlY3QNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1OV0gKioqKioq
KiB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVkIGZvciBwcm9kdWN0aW9uIHVz
ZSENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToxOTo1OV0gKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjE5OjU5
XSAzLi4uIDIuLi4gMS4uLiANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDowMl0gWGVuIGlz
IHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6
MDJdICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1l
cyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjAy
XSBGcmVlZCAyNDhrQiBpbml0IG1lbW9yeS4NCiBtYXBwaW5nIGtlcm5lbCBpbnRvIHBoeXNp
Y2FsIG1lbW9yeQ0KIGFib3V0IHRvIGdldCBzdGFydGVkLi4uDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MDJdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4g
MHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQogWyAgICAwLjAwMDAwMF0gSW5pdGlh
bGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQogIFsgICAgMC4wMDAwMDBdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGNwdQ0KICBbICAgIDAuMDAwMDAwXSBMaW51eCB2ZXJzaW9u
IDMuOC4wLXJjMC0yMDEzMDIyNyAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdjYyB2ZXJzaW9u
IDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjMSBTTVAgUFJFRU1QVCBXZWQgRmViIDI3IDA5
OjQ5OjQ1IENFVCAyMDEzDQogIFsgICAgMC4wMDAwMDBdIENvbW1hbmQgbGluZTogcm9vdD0v
ZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJvIHZlcmJvc2UgbWVtPTEwMjRNIGNv
bnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT03OTQgdmlkZW89dmVzYWZi
IG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTANCiAgWyAg
ICAwLjAwMDAwMF0gRnJlZWluZyA5Zi0xMDAgcGZuIHJhbmdlOiA5NyBwYWdlcyBmcmVlZA0K
ICBbICAgIDAuMDAwMDAwXSAxLTEgbWFwcGluZyBvbiA5Zi0+MTAwDQogIFsgICAgMC4wMDAw
MDBdIDEtMSBtYXBwaW5nIG9uIGFmZjkwLT4xMDAwMDANCiAgWyAgICAwLjAwMDAwMF0gUmVs
ZWFzZWQgOTcgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQ0KICBbICAgIDAuMDAwMDAwXSBTZXQg
MzI3ODg5IHBhZ2UocykgdG8gMS0xIG1hcHBpbmcNCiAgWyAgICAwLjAwMDAwMF0gUG9wdWxh
dGluZyA0MDAwMC00MDA2MSBwZm4gcmFuZ2U6IDk3IHBhZ2VzIGFkZGVkDQogIFsgICAgMC4w
MDAwMDBdIGU4MjA6IEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoNCiAgWyAgICAw
LjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWVm
ZmZdIHVzYWJsZQ0KICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDlm
MDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNCiAgWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwNDAwNjBmZmZdIHVzYWJsZQ0K
ICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDQwMDYxMDAwLTB4MDAwMDAw
MDBhZmY4ZmZmZl0gdW51c2FibGUNCiAgWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAw
MDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZdIEFDUEkgZGF0YQ0KICBbICAgIDAu
MDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGFmZjllMDAwLTB4MDAwMDAwMDBhZmZkZmZm
Zl0gQUNQSSBOVlMNCiAgWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBhZmZl
MDAwMC0weDAwMDAwMDAwYWZmZmZmZmZdIHJlc2VydmVkDQogIFsgICAgMC4wMDAwMDBdIFhl
bjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZl
ZA0KICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlYzIwMDAwLTB4MDAw
MDAwMDBmZWMyMGZmZl0gcmVzZXJ2ZWQNCiAgWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4
MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJlc2VydmVkDQogIFsgICAg
MC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZm
ZmZmXSByZXNlcnZlZA0KICBbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMTAw
MDAwMDAwLTB4MDAwMDAwMDI0ZmZmZmZmZl0gdW51c2FibGUNCiAgWyAgICAwLjAwMDAwMF0g
ZTgyMDogcmVtb3ZlIFttZW0gMHg0MDAwMDAwMC0weGZmZmZmZmZmZmZmZmZmZmVdIHVzYWJs
ZQ0KICBbICAgIDAuMDAwMDAwXSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBh
Y3RpdmUNCiAgWyAgICAwLjAwMDAwMF0gZTgyMDogdXNlci1kZWZpbmVkIHBoeXNpY2FsIFJB
TSBtYXA6DQogIFsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAw
LTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNhYmxlDQogIFsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMDAwMDlmMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNCiAg
WyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAw
MDNmZmZmZmZmXSB1c2FibGUNCiAgWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAw
MDAwNDAwNjEwMDAtMHgwMDAwMDAwMGFmZjhmZmZmXSB1bnVzYWJsZQ0KICBbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5MDAwMC0weDAwMDAwMDAwYWZmOWRmZmZd
IEFDUEkgZGF0YQ0KICBbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDBhZmY5
ZTAwMC0weDAwMDAwMDAwYWZmZGZmZmZdIEFDUEkgTlZTDQogIFsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGFmZmUwMDAwLTB4MDAwMDAwMDBhZmZmZmZmZl0gcmVzZXJ2
ZWQNCiAgWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwZmVjMDAwMDAtMHgw
MDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KICBbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVt
IDB4MDAwMDAwMDBmZWMyMDAwMC0weDAwMDAwMDAwZmVjMjBmZmZdIHJlc2VydmVkDQogIFsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNCiAgWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAw
MDAwZmZlMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KICBbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDAyNGZmZmZmZmZd
IHVudXNhYmxlDQogIFsgICAgMC4wMDAwMDBdIFNNQklPUyAyLjUgcHJlc2VudC4NCiAgWyAg
ICAwLjAwMDAwMF0gRE1JOiBNU0kgTVMtNzY0MC84OTBGWEEtR0Q3MCAoTVMtNzY0MCkgICwg
QklPUyBWMS44QjEgMDkvMTMvMjAxMA0KICBbICAgIDAuMDAwMDAwXSBlODIwOiB1cGRhdGUg
W21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2ZWQNCiAgWyAg
ICAwLjAwMDAwMF0gZTgyMDogcmVtb3ZlIFttZW0gMHgwMDBhMDAwMC0weDAwMGZmZmZmXSB1
c2FibGUNCiAgWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZA0KICBbICAgIDAu
MDAwMDAwXSBlODIwOiBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZuID0gMHg0MDAw
MDAwMDANCiAgWyAgICAwLjAwMDAwMF0gU2Nhbm5pbmcgMSBhcmVhcyBmb3IgbG93IG1lbW9y
eSBjb3JydXB0aW9uDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBm
YjEwMCAwMDAxNCAodjAwIEFDUElBTSkNCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEVCAw
MDAwMDAwMGFmZjkwMDAwIDAwMDQ4ICh2MDEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1T
RlQgMDAwMDAwOTcpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAwMDAwMDBhZmY5
MDIwMCAwMDA4NCAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3
KQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAwMDAwYWZmOTA1ZTAgMDk0Mjcg
KHYwMSAgQTc2NDAgQTc2NDAxMDAgMDAwMDAxMDAgSU5UTCAyMDA1MTExNykNCiAgWyAgICAw
LjAwMDAwMF0gQUNQSTogRkFDUyAwMDAwMDAwMGFmZjllMDAwIDAwMDQwDQogIFsgICAgMC4w
MDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBhZmY5MDM5MCAwMDA4OCAodjAxIDc2NDBNUyBB
NzY0MDEwMCAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBNQ0ZHIDAwMDAwMDAwYWZmOTA0MjAgMDAwM0MgKHYwMSA3NjQwTVMgT0VNTUNGRyAgMjAx
MDA5MTMgTVNGVCAwMDAwMDA5NykNCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogU0xJQyAwMDAw
MDAwMGFmZjkwNDYwIDAwMTc2ICh2MDEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQg
MDAwMDAwOTcpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDBhZmY5ZTA0
MCAwMDA3MiAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUIDAwMDAwMDk3KQ0K
ICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBTUkFUIDAwMDAwMDAwYWZmOWE1ZTAgMDAxMDggKHYw
MyBBTUQgICAgRkFNX0ZfMTAgMDAwMDAwMDIgQU1EICAwMDAwMDAwMSkNCiAgWyAgICAwLjAw
MDAwMF0gQUNQSTogSFBFVCAwMDAwMDAwMGFmZjlhNmYwIDAwMDM4ICh2MDEgNzY0ME1TIE9F
TUhQRVQgIDIwMTAwOTEzIE1TRlQgMDAwMDAwOTcpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6
IElWUlMgMDAwMDAwMDBhZmY5YTczMCAwMDEwMCAodjAxICBBTUQgICAgIFJEODkwUyAwMDIw
MjAzMSBBTUQgIDAwMDAwMDAwKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBTU0RUIDAwMDAw
MDAwYWZmOWE4MzAgMDBEQTQgKHYwMSBBIE0gSSAgUE9XRVJOT1cgMDAwMDAwMDEgQU1EICAw
MDAwMDAwMSkNCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4
ZmVlMDAwMDANCiAgWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBb
ZmZmZjg4MDAwMDA5OTAwMF0gOTkwMDAgc2l6ZSAyNDU3Ng0KICBbICAgIDAuMDAwMDAwXSBp
bml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDBmZmZmZl0NCiAgWyAg
ICAwLjAwMDAwMF0gIFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZmXSBwYWdlIDRrDQogIFsg
ICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgzZmUwMDAwMC0weDNm
ZmZmZmZmXQ0KICBbICAgIDAuMDAwMDAwXSAgW21lbSAweDNmZTAwMDAwLTB4M2ZmZmZmZmZd
IHBhZ2UgNGsNCiAgWyAgICAwLjAwMDAwMF0gQlJLIFsweDAyOTVmMDAwLCAweDAyOTVmZmZm
XSBQR1RBQkxFDQogIFsgICAgMC4wMDAwMDBdIGluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0g
MHgzYzAwMDAwMC0weDNmZGZmZmZmXQ0KICBbICAgIDAuMDAwMDAwXSAgW21lbSAweDNjMDAw
MDAwLTB4M2ZkZmZmZmZdIHBhZ2UgNGsNCiAgWyAgICAwLjAwMDAwMF0gQlJLIFsweDAyOTYw
MDAwLCAweDAyOTYwZmZmXSBQR1RBQkxFDQogIFsgICAgMC4wMDAwMDBdIEJSSyBbMHgwMjk2
MTAwMCwgMHgwMjk2MWZmZl0gUEdUQUJMRQ0KICBbICAgIDAuMDAwMDAwXSBCUksgWzB4MDI5
NjIwMDAsIDB4MDI5NjJmZmZdIFBHVEFCTEUNCiAgWyAgICAwLjAwMDAwMF0gQlJLIFsweDAy
OTYzMDAwLCAweDAyOTYzZmZmXSBQR1RBQkxFDQogIFsgICAgMC4wMDAwMDBdIGluaXRfbWVt
b3J5X21hcHBpbmc6IFttZW0gMHgwMDEwMDAwMC0weDNiZmZmZmZmXQ0KICBbICAgIDAuMDAw
MDAwXSAgW21lbSAweDAwMTAwMDAwLTB4M2JmZmZmZmZdIHBhZ2UgNGsNCiAgWyAgICAwLjAw
MDAwMF0gUkFNRElTSzogW21lbSAweDAyZDZiMDAwLTB4MDNhMTZmZmZdDQogIFsgICAgMC4w
MDAwMDBdIE5VTUEgdHVybmVkIG9mZg0KICBbICAgIDAuMDAwMDAwXSBGYWtpbmcgYSBub2Rl
IGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAzZmZmZmZmZl0NCiAgWyAg
ICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAwMDAwLTB4M2Zm
ZmZmZmZdDQogIFsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgzZmUxYTAwMC0w
eDNmZTI0ZmZmXQ0KICBbICAgIDAuMDAwMDAwXSBab25lIHJhbmdlczoNCiAgWyAgICAwLjAw
MDAwMF0gICBETUEgICAgICBbbWVtIDB4MDAwMDEwMDAtMHgwMGZmZmZmZl0NCiAgWyAgICAw
LjAwMDAwMF0gICBETUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NCiAgWyAg
ICAwLjAwMDAwMF0gICBOb3JtYWwgICBlbXB0eQ0KICBbICAgIDAuMDAwMDAwXSBNb3ZhYmxl
IHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0KICBbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1v
cnkgbm9kZSByYW5nZXMNCiAgWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAw
MDAxMDAwLTB4MDAwOWVmZmZdDQogIFsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0g
MHgwMDEwMDAwMC0weDNmZmZmZmZmXQ0KICBbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90
YWxwYWdlczogMjYyMDQ2DQogIFsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2Vz
IHVzZWQgZm9yIG1lbW1hcA0KICBbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAyMSBwYWdl
cyByZXNlcnZlZA0KICBbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTk4IHBhZ2VzLCBM
SUZPIGJhdGNoOjANCiAgWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MDMyIHBhZ2Vz
IHVzZWQgZm9yIG1lbW1hcA0KICBbICAgIDAuMDAwMDAwXSAgIERNQTMyIHpvbmU6IDI1ODA0
OCBwYWdlcywgTElGTyBiYXRjaDozMQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBQTS1UaW1l
ciBJTyBQb3J0OiAweDgwOA0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFk
ZHJlc3MgMHhmZWUwMDAwMA0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KICBbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDAyXSBl
bmFibGVkKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBs
YXBpY19pZFsweDAzXSBlbmFibGVkKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAo
YWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KICBbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
ICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMw
MDAwMF0gZ3NpX2Jhc2VbMF0pDQogIFsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19p
ZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQogIFsgICAg
MC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBn
c2lfYmFzZVsyNF0pDQogIFsgICAgMC4wMDAwMDBdIElPQVBJQ1sxXTogYXBpY19pZCA3LCB2
ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC01NQ0KICBbICAgIDAuMDAw
MDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBk
ZmwgZGZsKQ0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVz
X2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQogIFsgICAgMC4wMDAwMDBdIEFDUEk6
IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCiAgWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMiB1
c2VkIGJ5IG92ZXJyaWRlLg0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlE5IHVzZWQgYnkg
b3ZlcnJpZGUuDQogIFsgICAgMC4wMDAwMDBdIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAg
Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KICBbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVU
IGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KICBbICAgIDAuMDAwMDAwXSBzbXBib290
OiBBbGxvd2luZyA2IENQVXMsIDAgaG90cGx1ZyBDUFVzDQogIFsgICAgMC4wMDAwMDBdIG5y
X2lycXNfZ3NpOiA3Mg0KICBbICAgIDAuMDAwMDAwXSBlODIwOiBbbWVtIDB4YjAwMDAwMDAt
MHhmZWJmZmZmZl0gYXZhaWxhYmxlIGZvciBQQ0kgZGV2aWNlcw0KICBbICAgIDAuMDAwMDAw
XSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVuDQogIFsgICAgMC4wMDAw
MDBdIFhlbiB2ZXJzaW9uOiA0LjMtdW5zdGFibGUgKHByZXNlcnZlLUFEKQ0KICBbICAgIDAu
MDAwMDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNrX2JpdHM6OCBucl9j
cHVfaWRzOjYgbnJfbm9kZV9pZHM6MQ0KICBbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVtYmVk
ZGVkIDI4IHBhZ2VzL2NwdSBAZmZmZjg4MDAzZjgwMDAwMCBzODE5ODQgcjgxOTIgZDI0NTEy
IHUyNjIxNDQNCiAgWyAgICAwLjAwMDAwMF0gcGNwdS1hbGxvYzogczgxOTg0IHI4MTkyIGQy
NDUxMiB1MjYyMTQ0IGFsbG9jPTEqMjA5NzE1Mg0KICBbICAgIDAuMDAwMDAwXSBwY3B1LWFs
bG9jOiBbMF0gMCAxIDIgMyA0IDUgLSAtIA0KICBbICAgMTAuNjI4NDM5XSBCdWlsdCAxIHpv
bmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBh
Z2VzOiAyNTc5MjkNCiAgWyAgIDEwLjYyODQ0MV0gUG9saWN5IHpvbmU6IERNQTMyDQogIFsg
ICAxMC42Mjg0NDhdIEtlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9tYXBwZXIvc2Vy
dmVlcnN0ZXJ0amUtcm9vdCBybyB2ZXJib3NlIG1lbT0xMDI0TSBjb25zb2xlPWh2YzAgY29u
c29sZT10dHkwIG5vbW9kZXNldCB2Z2E9Nzk0IHZpZGVvPXZlc2FmYiBtYXhfbG9vcD01MCBs
b29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xldmVsPTEwDQogIFsgICAxMC42Mjg1NzldIFBJ
RCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykNCiAg
WyAgIDEwLjYyODU4NV0gX19leF90YWJsZSBhbHJlYWR5IHNvcnRlZCwgc2tpcHBpbmcgc29y
dA0KICBbICAgMTAuNjcwODUwXSBzb2Z0d2FyZSBJTyBUTEIgW21lbSAweDNhNjAwMDAwLTB4
M2U2MDAwMDBdICg2NE1CKSBtYXBwZWQgYXQgW2ZmZmY4ODAwM2E2MDAwMDAtZmZmZjg4MDAz
ZTVmZmZmZl0NCiAgWyAgIDEwLjY3NTk4M10gTWVtb3J5OiA5MjE4MDRrLzEwNDg1NzZrIGF2
YWlsYWJsZSAoOTk1N2sga2VybmVsIGNvZGUsIDM5MmsgYWJzZW50LCAxMjYzODBrIHJlc2Vy
dmVkLCA1MzEwayBkYXRhLCAxMDY4ayBpbml0KQ0KICBbICAgMTAuNjc2Mjk1XSBTTFVCOiBH
ZW5zbGFicz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9
NiwgTm9kZXM9MQ0KICBbICAgMTAuNjc2NDA1XSBQcmVlbXB0aWJsZSBoaWVyYXJjaGljYWwg
UkNVIGltcGxlbWVudGF0aW9uLg0KICBbICAgMTAuNjc2NDA3XSAJUkNVIGR5bnRpY2staWRs
ZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVuYWJsZWQuDQogIFsgICAxMC42NzY0
MDhdIAlBZGRpdGlvbmFsIHBlci1DUFUgaW5mbyBwcmludGVkIHdpdGggc3RhbGxzLg0KICBb
ICAgMTAuNjc2NDA5XSAJUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8g
bnJfY3B1X2lkcz02Lg0KICBbICAgMTAuNjc2NDU2XSBOUl9JUlFTOjQzNTIgbnJfaXJxczox
MjcyIDE2DQogIFsgICAxMC42NzY1OTZdIHhlbjogc2NpIG92ZXJyaWRlOiBnbG9iYWxfaXJx
PTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENCiAgWyAgIDEwLjY3NjU5OF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMTAuNjc2NjMzXSB4
ZW46IC0tPiBwaXJxPTkgLT4gaXJxPTkgKGdzaT05KQ0KICBbICAgMTAuNzAyNDE4XSB4ZW46
IGFjcGkgc2NpIDkNCiAgWyAgIDEwLjcwMjQzMV0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0x
IChnc2k9MSkNCiAgWyAgIDEwLjcwMjQzN10geGVuOiAtLT4gcGlycT0yIC0+IGlycT0yIChn
c2k9MikNCiAgWyAgIDEwLjcwMjQ0M10geGVuOiAtLT4gcGlycT0zIC0+IGlycT0zIChnc2k9
MykNCiAgWyAgIDEwLjcwMjQ0OV0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkN
CiAgWyAgIDEwLjcwMjQ1NV0geGVuOiAtLT4gcGlycT01IC0+IGlycT01IChnc2k9NSkNCiAg
WyAgIDEwLjcwMjQ2Ml0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikNCiAgWyAg
IDEwLjcwMjQ2OF0geGVuOiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykNCiAgWyAgIDEw
LjcwMjQ3NF0geGVuOiAtLT4gcGlycT04IC0+IGlycT04IChnc2k9OCkNCiAgWyAgIDEwLjcw
MjQ4MF0geGVuOiAtLT4gcGlycT0xMCAtPiBpcnE9MTAgKGdzaT0xMCkNCiAgWyAgIDEwLjcw
MjQ4Nl0geGVuOiAtLT4gcGlycT0xMSAtPiBpcnE9MTEgKGdzaT0xMSkNCiAgWyAgIDEwLjcw
MjQ5Ml0geGVuOiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdzaT0xMikNCiAgWyAgIDEwLjcw
MjQ5OF0geGVuOiAtLT4gcGlycT0xMyAtPiBpcnE9MTMgKGdzaT0xMykNCiAgWyAgIDEwLjcw
MjUwNF0geGVuOiAtLT4gcGlycT0xNCAtPiBpcnE9MTQgKGdzaT0xNCkNCiAgWyAgIDEwLjcw
MjUxMF0geGVuOiAtLT4gcGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkNCiAgWyAgIDEwLjcw
MjYxNV0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQ0KICBbICAgMTAuNzA0
MDkxXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkDQogIFsgICAxMy4zNTg4OTJdIGNvbnNvbGUg
W2h2YzBdIGVuYWJsZWQNCiAgWyAgIDEzLjM2OTI5NF0gTG9jayBkZXBlbmRlbmN5IHZhbGlk
YXRvcjogQ29weXJpZ2h0IChjKSAyMDA2IFJlZCBIYXQsIEluYy4sIEluZ28gTW9sbmFyDQog
IFsgICAxMy4zOTI2ODldIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOA0KICBbICAg
MTMuNDA1MTY4XSAuLi4gTUFYX0xPQ0tfREVQVEg6ICAgICAgICAgIDQ4DQogIFsgICAxMy40
MTc5MDhdIC4uLiBNQVhfTE9DS0RFUF9LRVlTOiAgICAgICAgODE5MQ0KICBbICAgMTMuNDMx
MTY2XSAuLi4gQ0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYNCiAgWyAgIDEzLjQ0NDQy
NV0gLi4uIE1BWF9MT0NLREVQX0VOVFJJRVM6ICAgICAxNjM4NA0KICBbICAgMTMuNDU3OTQ0
XSAuLi4gTUFYX0xPQ0tERVBfQ0hBSU5TOiAgICAgIDMyNzY4DQogIFsgICAxMy40NzE0NjVd
IC4uLiBDSEFJTkhBU0hfU0laRTogICAgICAgICAgMTYzODQNCiAgWyAgIDEzLjQ4NDk4NF0g
IG1lbW9yeSB1c2VkIGJ5IGxvY2sgZGVwZW5kZW5jeSBpbmZvOiA1ODU1IGtCDQogIFsgICAx
My41MDEzNjJdICBwZXIgdGFzay1zdHJ1Y3QgbWVtb3J5IGZvb3RwcmludDogMTkyMCBieXRl
cw0KICBbICAgMTMuNTE3NzQyXSBrbWVtbGVhazogS2VybmVsIG1lbW9yeSBsZWFrIGRldGVj
dG9yIGRpc2FibGVkDQogIFsgICAxMy41MzQ0NDBdIFhlbjogdXNpbmcgdmNwdW9wIHRpbWVy
IGludGVyZmFjZQ0KICBbICAgMTMuNTQ3NjgwXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3Ig
Q1BVIDANCiAgWyAgIDEzLjU2MDIxMV0gdHNjOiBEZXRlY3RlZCAzMjAwLjE5OCBNSHogcHJv
Y2Vzc29yDQogIFsgICAxMy41NzQyNDZdIENhbGlicmF0aW5nIGRlbGF5IGxvb3AgKHNraXBw
ZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDY0MDIuMDcg
Qm9nb01JUFMgKGxwaj0xMDY2NzMyNikNCiAgWyAgIDEzLjYwNjQzMl0gcGlkX21heDogZGVm
YXVsdDogMzI3NjggbWluaW11bTogMzAxDQogIFsgICAxMy42MjA3NTFdIERlbnRyeSBjYWNo
ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMp
DQogIFsgICAxMy42NDIzODVdIElub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNjU1
MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMpDQogIFsgICAxMy42NjI5ODJdIE1vdW50LWNh
Y2hlIGhhc2ggdGFibGUgZW50cmllczogMjU2DQogIFsgICAxMy42NzcyNDNdIEluaXRpYWxp
emluZyBjZ3JvdXAgc3Vic3lzIGNwdWFjY3QNCiAgWyAgIDEzLjY5MDI4Nl0gSW5pdGlhbGl6
aW5nIGNncm91cCBzdWJzeXMgZnJlZXplcg0KICBbICAgMTMuNzAzODEwXSBJbml0aWFsaXpp
bmcgY2dyb3VwIHN1YnN5cyBibGtpbw0KICBbICAgMTMuNzE2ODYxXSB0c2VnOiAwMDAwMDAw
MDAwDQogIFsgICAxMy43MjU2NjddIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwDQog
IFsgICAxMy43Mzc4NTRdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDANCiAgWyAgIDEzLjc0
OTAzNV0gbWNlOiBDUFUgc3VwcG9ydHMgMiBNQ0UgYmFua3MNCiAgWyAgIDEzLjc2MTI2MV0g
TFZUIG9mZnNldCAwIGFzc2lnbmVkIGZvciB2ZWN0b3IgMHhmOQ0KICBbICAgMTMuNzc1NTUz
XSBbRmlybXdhcmUgQnVnXTogY3B1IDAsIHRyeSB0byB1c2UgQVBJQzUwMCAoTFZUIG9mZnNl
dCAwKSBmb3IgdmVjdG9yIDB4ZjksIGJ1dCB0aGUgcmVnaXN0ZXIgaXMgYWxyZWFkeSBpbiB1
c2UgZm9yIHZlY3RvciAweDAgb24gdGhpcyBjcHUNCiAgWyAgIDEzLjgxNTMzMF0gW0Zpcm13
YXJlIEJ1Z106IGNwdSAwLCBmYWlsZWQgdG8gc2V0dXAgdGhyZXNob2xkIGludGVycnVwdCBm
b3IgYmFuayA0LCBibG9jayAwIChNU1IwMDAwMDQxMz0weGMwMDgwMDAwMDEwMDAwMDApDQog
IFsgICAxMy44NDg4NzRdIExhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIg
MTYsIDRNQiA4DQogIFsgICAxMy44NDg4NzRdIExhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0
S0IgNTEyLCAyTUIgMTI4LCA0TUIgNjQNCiAgWyAgIDEzLjg0ODg3NF0gdGxiX2ZsdXNoYWxs
X3NoaWZ0OiA0DQogIFsgICAxMy44OTM0MTJdIEZyZWVpbmcgU01QIGFsdGVybmF0aXZlczog
MzJrIGZyZWVkDQogIFsgICAxMy45MDc3ODBdIEFDUEk6IENvcmUgcmV2aXNpb24gMjAxMzAx
MTcNCiAgWyAgIDEzLjkyMzA5NV0gQUNQSTogQWxsIEFDUEkgVGFibGVzIHN1Y2Nlc3NmdWxs
eSBhY3F1aXJlZA0KICBbICAgMTMuOTQwODk1XSBQZXJmb3JtYW5jZSBFdmVudHM6IChYRU4p
IFsyMDEzLTAyLTI3IDExOjIwOjA1XSB0cmFwcy5jOjI0OTU6ZDAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwMDAwMDAwMDAwMDAwIHRvIDB4
MDAwMDAwMDAwMDAwZmZmZi4NCiBCcm9rZW4gUE1VIGhhcmR3YXJlIGRldGVjdGVkLCB1c2lu
ZyBzb2Z0d2FyZSBldmVudHMgb25seS4NCiAgWyAgIDEzLjk5OTQyM10gRmFpbGVkIHRvIGFj
Y2VzcyBwZXJmY3RyIG1zciAoTVNSIGMwMDEwMDA0IGlzIDApDQogIFsgICAxNC4wMzA5MTRd
IE5NSSB3YXRjaGRvZzogZGlzYWJsZWQgKGNwdTApOiBoYXJkd2FyZSBldmVudHMgbm90IGVu
YWJsZWQNCiAgWyAgIDE0LjA1MDQyMF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAx
DQogIFsgICAxNC4wNjI3ODFdIFNNUCBhbHRlcm5hdGl2ZXM6IGxvY2tkZXA6IGZpeGluZyB1
cCBhbHRlcm5hdGl2ZXMNCiAgWyAgIDE0LjA4MDIxNl0gW0Zpcm13YXJlIEJ1Z106IGNwdSAx
LCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBvZmZzZXQgMCkgZm9yIHZlY3RvciAweGY5LCBi
dXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkgaW4gdXNlIGZvciB2ZWN0b3IgMHgwIG9uIHRo
aXMgY3B1DQogIFsgICAxNC4wODAyMThdIFtGaXJtd2FyZSBCdWddOiBjcHUgMSwgZmFpbGVk
IHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1cHQgZm9yIGJhbmsgNCwgYmxvY2sgMCAoTVNS
MDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAwKQ0KICBbICAgMTQuMDgwNTM1XSBpbnN0YWxs
aW5nIFhlbiB0aW1lciBmb3IgQ1BVIDINCiAgWyAgIDE0LjE2NjA2Nl0gW0Zpcm13YXJlIEJ1
Z106IGNwdSAyLCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBvZmZzZXQgMCkgZm9yIHZlY3Rv
ciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkgaW4gdXNlIGZvciB2ZWN0b3Ig
MHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC4xNjYwNjldIFtGaXJtd2FyZSBCdWddOiBjcHUg
MiwgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1cHQgZm9yIGJhbmsgNCwgYmxv
Y2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAwKQ0KICBbICAgMTQuMTY2MzM2
XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMNCiAgWyAgIDE0LjI1MTk0Nl0gW0Zp
cm13YXJlIEJ1Z106IGNwdSAzLCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBvZmZzZXQgMCkg
Zm9yIHZlY3RvciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkgaW4gdXNlIGZv
ciB2ZWN0b3IgMHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC4yNTE5NDhdIFtGaXJtd2FyZSBC
dWddOiBjcHUgMywgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1cHQgZm9yIGJh
bmsgNCwgYmxvY2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAwKQ0KICBbICAg
MTQuMjUyMTk2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDQNCiAgWyAgIDE0LjMz
Nzc3NF0gW0Zpcm13YXJlIEJ1Z106IGNwdSA0LCB0cnkgdG8gdXNlIEFQSUM1MDAgKExWVCBv
ZmZzZXQgMCkgZm9yIHZlY3RvciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlzIGFscmVhZHkg
aW4gdXNlIGZvciB2ZWN0b3IgMHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC4zMzc3NzddIFtG
aXJtd2FyZSBCdWddOiBjcHUgNCwgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9sZCBpbnRlcnJ1
cHQgZm9yIGJhbmsgNCwgYmxvY2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAwMDAxMDAwMDAw
KQ0KICBbICAgMTQuMzM4MDM4XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDUNCiAg
WyAgIDE0LjQyMzYyOF0gW0Zpcm13YXJlIEJ1Z106IGNwdSA1LCB0cnkgdG8gdXNlIEFQSUM1
MDAgKExWVCBvZmZzZXQgMCkgZm9yIHZlY3RvciAweGY5LCBidXQgdGhlIHJlZ2lzdGVyIGlz
IGFscmVhZHkgaW4gdXNlIGZvciB2ZWN0b3IgMHgwIG9uIHRoaXMgY3B1DQogIFsgICAxNC40
MjM2MzBdIFtGaXJtd2FyZSBCdWddOiBjcHUgNSwgZmFpbGVkIHRvIHNldHVwIHRocmVzaG9s
ZCBpbnRlcnJ1cHQgZm9yIGJhbmsgNCwgYmxvY2sgMCAoTVNSMDAwMDA0MTM9MHhjMDA4MDAw
MDAxMDAwMDAwKQ0KICBbICAgMTQuNDIzNjkzXSBCcm91Z2h0IHVwIDYgQ1BVcw0KICBbICAg
MTQuNTA3MTIxXSBHcmFudCB0YWJsZXMgdXNpbmcgdmVyc2lvbiAyIGxheW91dC4NCiAgWyAg
IDE0LjUyMDY5OF0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQNCiAgWyAgIDE0LjUzMTQ3OV0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNg0KICBbICAgMTQuNTQ3NDM3XSBu
b2RlIDAgbGluayAwOiBpbyBwb3J0IFsxMDAwLCBmZmZmZmZdDQogIFsgICAxNC41NjEyNzZd
IFRPTTogMDAwMDAwMDBiMDAwMDAwMCBha2EgMjgxNk0NCiAgWyAgIDE0LjU3NDAxMF0gRmFt
IDEwaCBtbWNvbmYgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdDQogIFsgICAxNC41ODk2
MDBdIG5vZGUgMCBsaW5rIDA6IG1taW8gW2UwMDAwMDAwLCBlZmZmZmZmZl0gPT0+IG5vbmUN
CiAgWyAgIDE0LjYwNzAxMV0gbm9kZSAwIGxpbmsgMDogbW1pbyBbZjAwMDAwMDAsIGZmZmZm
ZmZmXQ0KICBbICAgMTQuNjIyMDg5XSBub2RlIDAgbGluayAwOiBtbWlvIFthMDAwMCwgYmZm
ZmZdDQogIFsgICAxNC42MzU2MDddIG5vZGUgMCBsaW5rIDA6IG1taW8gW2IwMDAwMDAwLCBk
ZmZmZmZmZl0NCiAgWyAgIDE0LjY1MDY4Nl0gVE9NMjogMDAwMDAwMDI1MDAwMDAwMCBha2Eg
OTQ3Mk0NCiAgWyAgIDE0LjY2MzY5OF0gYnVzOiBbYnVzIDAwLTA3XSBvbiBub2RlIDAgbGlu
ayAwDQogIFsgICAxNC42NzY5NTBdIGJ1czogMDAgW2lvICAweDAwMDAtMHhmZmZmXQ0KICBb
ICAgMTQuNjg4NjQ5XSBidXM6IDAwIFttZW0gMHhmMDAwMDAwMC0weGZmZmZmZmZmXQ0KICBb
ICAgMTQuNzAyNDI3XSBidXM6IDAwIFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KICBb
ICAgMTQuNzE2MjA2XSBidXM6IDAwIFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0KICBb
ICAgMTQuNzI5OTg3XSBidXM6IDAwIFttZW0gMHgyNTAwMDAwMDAtMHhmY2ZmZmZmZmZmXQ0K
ICBbICAgMTQuNzQ0ODUyXSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZA0KICBbICAg
MTQuNzU3Nzc3XSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBh
dCBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkNCiAgWyAg
IDE0Ljc4NTM3OV0gUENJOiBub3QgdXNpbmcgTU1DT05GSUcNCiAgWyAgIDE0Ljc5NjAzNV0g
UENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MNCiAgWyAg
IDE0LjgxMjk0Ml0gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgZXh0ZW5k
ZWQgYWNjZXNzDQogIFsgICAxNC44NzU5NzhdIGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBh
dCAwDQogIFsgICAxNC44ODgzNDRdIEFDUEk6IEFkZGVkIF9PU0koTW9kdWxlIERldmljZSkN
CiAgWyAgIDE0LjkwMDYwNV0gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgRGV2aWNlKQ0K
ICBbICAgMTQuOTE0MTIyXSBBQ1BJOiBBZGRlZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMp
DQogIFsgICAxNC45Mjg0MjddIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIEFnZ3JlZ2F0
b3IgRGV2aWNlKQ0KICBbICAgMTQuOTQ4MTI5XSBBQ1BJOiBFQzogTG9vayB1cCBFQyBpbiBE
U0RUDQogIFsgICAxNC45NjMyMjVdIEFDUEk6IEV4ZWN1dGVkIDMgYmxvY2tzIG9mIG1vZHVs
ZS1sZXZlbCBleGVjdXRhYmxlIEFNTCBjb2RlDQogIFsgICAxNC45ODcyNDJdIEFDUEk6IElu
dGVycHJldGVyIGVuYWJsZWQNCiAgWyAgIDE0Ljk5Nzk0N10gQUNQSTogKHN1cHBvcnRzIFMw
IFM1KQ0KICBbICAgMTUuMDA4MzM1XSBBQ1BJOiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVw
dCByb3V0aW5nDQogIFsgICAxNS4wMjM0NTRdIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAw
MDAwIFtidXMgMDAtZmZdIGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAw
eGUwMDAwMDAwKQ0KICBbICAgMTUuMDUzMDc5XSBQQ0k6IE1NQ09ORklHIGF0IFttZW0gMHhl
MDAwMDAwMC0weGVmZmZmZmZmXSByZXNlcnZlZCBpbiBBQ1BJIG1vdGhlcmJvYXJkIHJlc291
cmNlcw0KICBbICAgMTUuMTE1MTA0XSBQQ0k6IFVzaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3Mg
ZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3JzIiBhbmQgcmVwb3J0IGEg
YnVnDQogIFsgICAxNS4xODA1ODJdIEFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJMF0gKGRv
bWFpbiAwMDAwIFtidXMgMDAtZmZdKQ0KICBbICAgMTUuMTk5MTAwXSBhY3BpIFBOUDBBMDM6
MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpDQogIFsgICAxNS4yMTcy
MTNdIGFjcGkgUE5QMEEwMzowMDogQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpIGdyYW50ZWQN
CiAgWyAgIDE1LjIzNDg1Nl0gUENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQogIFsg
ICAxNS4yNDY5MzBdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2J1cyAw
MC1mZl0NCiAgWyAgIDE1LjI2MzU3N10gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNv
dXJjZSBbaW8gIDB4MDAwMC0weDBjZjddDQogIFsgICAxNS4yODIyODRdIHBjaV9idXMgMDAw
MDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmXQ0KICBbICAgMTUu
MzAxMDExXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBh
MDAwMC0weDAwMGJmZmZmXQ0KICBbICAgMTUuMzIxODAxXSBwY2lfYnVzIDAwMDA6MDA6IHJv
b3QgYnVzIHJlc291cmNlIFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXQ0KICBbICAgMTUu
MzQyNjEwXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhiMDAw
MDAwMC0weGRmZmZmZmZmXQ0KICBbICAgMTUuMzYzNDA1XSBwY2lfYnVzIDAwMDA6MDA6IHJv
b3QgYnVzIHJlc291cmNlIFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0KICBbICAgMTUu
Mzg0MjE2XSBwY2lfYnVzIDAwMDA6MDA6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTUuMzk2NDU5
XSBwY2kgMDAwMDowMDowMC4wOiBbMTAwMjo1YTExXSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAw
DQogIFsgICAxNS40MTQ2MjFdIHBjaSAwMDAwOjAwOjAwLjA6IGNhbGxpbmcgcXVpcmtfbW1p
b19hbHdheXNfb24rMHgwLzB4MTANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMA0KIFsgICAxNS40NDg2MjJdIHBjaSAwMDAwOjAw
OjAwLjI6IFsxMDAyOjVhMjNdIHR5cGUgMDAgY2xhc3MgMHgwODA2MDANCiAgKFhFTikgWzIw
MTMtMDItMjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMg0KIFsgICAx
NS40ODE2MDldIHBjaSAwMDAwOjAwOjAyLjA6IFsxMDAyOjVhMTZdIHR5cGUgMDEgY2xhc3Mg
MHgwNjA0MDANCiAgWyAgIDE1LjQ5OTcyNV0gcGNpIDAwMDA6MDA6MDIuMDogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE1LjUxODEyNl0gcGNpIDAwMDA6
MDA6MDIuMDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTUuNTMwODgwXSBwY2kgMDAwMDowMDow
Mi4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMA0KIFsgICAxNS41NjI5
OTddIHBjaSAwMDAwOjAwOjAzLjA6IFsxMDAyOjVhMTddIHR5cGUgMDEgY2xhc3MgMHgwNjA0
MDANCiAgWyAgIDE1LjU4MTEzMV0gcGNpIDAwMDA6MDA6MDMuMDogUE1FIyBzdXBwb3J0ZWQg
ZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE1LjU5OTUwOV0gcGNpIDAwMDA6MDA6MDMu
MDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTUuNjEyMjgxXSBwY2kgMDAwMDowMDowMy4wOiBT
eXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6
MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDMuMA0KIFsgICAxNS42NDQzODVdIHBj
aSAwMDAwOjAwOjA1LjA6IFsxMDAyOjVhMTldIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAg
WyAgIDE1LjY2MjUwNF0gcGNpIDAwMDA6MDA6MDUuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE
MCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE1LjY4MDg4NF0gcGNpIDAwMDA6MDA6MDUuMDogUE1F
IyBkaXNhYmxlZA0KICBbICAgMTUuNjkzNjYxXSBwY2kgMDAwMDowMDowNS4wOiBTeXN0ZW0g
d2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDdd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDUuMA0KIFsgICAxNS43MjU3NDVdIHBjaSAwMDAw
OjAwOjA2LjA6IFsxMDAyOjVhMWFdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1
Ljc0Mzg4MF0gcGNpIDAwMDA6MDA6MDYuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQNCiAgWyAgIDE1Ljc2MjI1OF0gcGNpIDAwMDA6MDA6MDYuMDogUE1FIyBkaXNh
YmxlZA0KICBbICAgMTUuNzc1MDM5XSBwY2kgMDAwMDowMDowNi4wOiBTeXN0ZW0gd2FrZXVw
IGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MDYuMA0KIFsgICAxNS44MDcxMzddIHBjaSAwMDAwOjAwOjA5
LjA6IFsxMDAyOjVhMWNdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1LjgyNTI1
NF0gcGNpIDAwMDA6MDA6MDkuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2Nv
bGQNCiAgWyAgIDE1Ljg0MzYzM10gcGNpIDAwMDA6MDA6MDkuMDogUE1FIyBkaXNhYmxlZA0K
ICBbICAgMTUuODU2NDIzXSBwY2kgMDAwMDowMDowOS4wOiBTeXN0ZW0gd2FrZXVwIGRpc2Fi
bGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MDkuMA0KIFsgICAxNS44ODg0OTVdIHBjaSAwMDAwOjAwOjBhLjA6IFsx
MDAyOjVhMWRdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1LjkwNjYyOV0gcGNp
IDAwMDA6MDA6MGEuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAg
WyAgIDE1LjkyNTAwOV0gcGNpIDAwMDA6MDA6MGEuMDogUE1FIyBkaXNhYmxlZA0KICBbICAg
MTUuOTM3ODAxXSBwY2kgMDAwMDowMDowYS4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5
IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDddIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MGEuMA0KIFsgICAxNS45NzAwMDldIHBjaSAwMDAwOjAwOjBiLjA6IFsxMDAyOjVh
MWZdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE1Ljk4ODAxMl0gcGNpIDAwMDA6
MDA6MGIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE2
LjAwNjM5MF0gcGNpIDAwMDA6MDA6MGIuMDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTYuMDE5
MTgyXSBwY2kgMDAwMDowMDowYi4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MGIuMA0KIFsgICAxNi4wNTEyNjddIHBjaSAwMDAwOjAwOjBkLjA6IFsxMDAyOjVhMWVdIHR5
cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE2LjA2OTM3OV0gcGNpIDAwMDA6MDA6MGQu
MDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCiAgWyAgIDE2LjA4Nzc1
OF0gcGNpIDAwMDA6MDA6MGQuMDogUE1FIyBkaXNhYmxlZA0KICBbICAgMTYuMTAwNTU3XSBw
Y2kgMDAwMDowMDowZC4wOiBTeXN0ZW0gd2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhF
TikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGQuMA0K
IFsgICAxNi4xMzI2NTNdIHBjaSAwMDAwOjAwOjExLjA6IFsxMDAyOjQzOTBdIHR5cGUgMDAg
Y2xhc3MgMHgwMTAxOGYNCiAgWyAgIDE2LjE1MDY3OV0gcGNpIDAwMDA6MDA6MTEuMDogY2Fs
bGluZyBxdWlya19ub19hdGFfZDMrMHgwLzB4MTANCiAgWyAgIDE2LjE2ODM2NV0gcGNpIDAw
MDA6MDA6MTEuMDogcmVnIDEwOiBbaW8gIDB4NzAwMC0weDcwMDddDQogIFsgICAxNi4xODQ3
MzNdIHBjaSAwMDAwOjAwOjExLjA6IHJlZyAxNDogW2lvICAweDYwMDAtMHg2MDAzXQ0KICBb
ICAgMTYuMjAxMTE2XSBwY2kgMDAwMDowMDoxMS4wOiByZWcgMTg6IFtpbyAgMHg1MDAwLTB4
NTAwN10NCiAgWyAgIDE2LjIxNzQ5MV0gcGNpIDAwMDA6MDA6MTEuMDogcmVnIDFjOiBbaW8g
IDB4MzAwMC0weDMwMDNdDQogIFsgICAxNi4yMzM4NjhdIHBjaSAwMDAwOjAwOjExLjA6IHJl
ZyAyMDogW2lvICAweDIwMDAtMHgyMDBmXQ0KICBbICAgMTYuMjUwMjQ5XSBwY2kgMDAwMDow
MDoxMS4wOiByZWcgMjQ6IFttZW0gMHhmOTZmZjAwMC0weGY5NmZmM2ZmXQ0KICBbICAgMTYu
MjY4NzE0XSBwY2kgMDAwMDowMDoxMS4wOiBjYWxsaW5nIHF1aXJrX2FtZF9pZGVfbW9kZSsw
eDAvMHhlMA0KICBbICAgMTYuMjg3MTYzXSBwY2kgMDAwMDowMDoxMS4wOiBzZXQgU0FUQSB0
byBBSENJIG1vZGUNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTEuMA0KIFsgICAxNi4zMTY5NDRdIHBjaSAwMDAwOjAwOjEyLjA6IFsx
MDAyOjQzOTddIHR5cGUgMDAgY2xhc3MgMHgwYzAzMTANCiAgWyAgIDE2LjMzNTAxMl0gcGNp
IDAwMDA6MDA6MTIuMDogcmVnIDEwOiBbbWVtIDB4Zjk2ZmIwMDAtMHhmOTZmYmZmZl0NCiAg
WyAgIDE2LjM1MzYwN10gcGNpIDAwMDA6MDA6MTIuMDogU3lzdGVtIHdha2V1cCBkaXNhYmxl
ZCBieSBBQ1BJDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA4XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjEyLjANCiBbICAgMTYuMzg1NTkyXSBwY2kgMDAwMDowMDoxMi4yOiBbMTAw
Mjo0Mzk2XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzIwDQogIFsgICAxNi40MDM2NTNdIHBjaSAw
MDAwOjAwOjEyLjI6IHJlZyAxMDogW21lbSAweGY5NmZmNDAwLTB4Zjk2ZmY0ZmZdDQogIFsg
ICAxNi40MjIyMTJdIHBjaSAwMDAwOjAwOjEyLjI6IHN1cHBvcnRzIEQxIEQyDQogIFsgICAx
Ni40MzUwODVdIHBjaSAwMDAwOjAwOjEyLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEg
RDIgRDNob3QNCiAgWyAgIDE2LjQ1MzI5NV0gcGNpIDAwMDA6MDA6MTIuMjogUE1FIyBkaXNh
YmxlZA0KICBbICAgMTYuNDY2MTAzXSBwY2kgMDAwMDowMDoxMi4yOiBTeXN0ZW0gd2FrZXVw
IGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTIuMg0KIFsgICAxNi40OTgxNzJdIHBjaSAwMDAwOjAwOjEz
LjA6IFsxMDAyOjQzOTddIHR5cGUgMDAgY2xhc3MgMHgwYzAzMTANCiAgWyAgIDE2LjUxNjIx
OF0gcGNpIDAwMDA6MDA6MTMuMDogcmVnIDEwOiBbbWVtIDB4Zjk2ZmMwMDAtMHhmOTZmY2Zm
Zl0NCiAgWyAgIDE2LjUzNDgyMl0gcGNpIDAwMDA6MDA6MTMuMDogU3lzdGVtIHdha2V1cCBk
aXNhYmxlZCBieSBBQ1BJDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA4XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjEzLjANCiBbICAgMTYuNTY2ODMyXSBwY2kgMDAwMDowMDoxMy4y
OiBbMTAwMjo0Mzk2XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzIwDQogIFsgICAxNi41ODQ4OTVd
IHBjaSAwMDAwOjAwOjEzLjI6IHJlZyAxMDogW21lbSAweGY5NmZmODAwLTB4Zjk2ZmY4ZmZd
DQogIFsgICAxNi42MDM0NTNdIHBjaSAwMDAwOjAwOjEzLjI6IHN1cHBvcnRzIEQxIEQyDQog
IFsgICAxNi42MTYzMjddIHBjaSAwMDAwOjAwOjEzLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20g
RDAgRDEgRDIgRDNob3QNCiAgWyAgIDE2LjYzNDUzNV0gcGNpIDAwMDA6MDA6MTMuMjogUE1F
IyBkaXNhYmxlZA0KICBbICAgMTYuNjQ3MzQ5XSBwY2kgMDAwMDowMDoxMy4yOiBTeXN0ZW0g
d2FrZXVwIGRpc2FibGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDhd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMuMg0KIFsgICAxNi42Nzk0MTNdIHBjaSAwMDAw
OjAwOjE0LjA6IFsxMDAyOjQzODVdIHR5cGUgMDAgY2xhc3MgMHgwYzA1MDANCiAgWyAgIDE2
LjY5NzQ0N10gcGNpIDAwMDA6MDA6MTQuMDogY2FsbGluZyBzYjYwMF9kaXNhYmxlX2hwZXRf
YmFyKzB4MC8weDUwDQogIFsgICAxNi43MTcwMzRdIHBjaSAwMDAwOjAwOjE0LjA6IGNhbGxp
bmcgZm9yY2VfZGlzYWJsZV9ocGV0X21zaSsweDAvMHgxMA0KICAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMDowOF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wDQogWyAgIDE2Ljc1MTQw
MV0gcGNpIDAwMDA6MDA6MTQuMTogWzEwMDI6NDM5Y10gdHlwZSAwMCBjbGFzcyAweDAxMDE4
YQ0KICBbICAgMTYuNzY5NDYwXSBwY2kgMDAwMDowMDoxNC4xOiBjYWxsaW5nIHF1aXJrX25v
X2F0YV9kMysweDAvMHgxMA0KICBbICAgMTYuNzg3MTU5XSBwY2kgMDAwMDowMDoxNC4xOiBy
ZWcgMTA6IFtpbyAgMHgwMDAwLTB4MDAwN10NCiAgWyAgIDE2LjgwMzUyN10gcGNpIDAwMDA6
MDA6MTQuMTogcmVnIDE0OiBbaW8gIDB4MDAwMC0weDAwMDNdDQogIFsgICAxNi44MTk5MTRd
IHBjaSAwMDAwOjAwOjE0LjE6IHJlZyAxODogW2lvICAweDAwMDAtMHgwMDA3XQ0KICBbICAg
MTYuODM2Mjg0XSBwY2kgMDAwMDowMDoxNC4xOiByZWcgMWM6IFtpbyAgMHgwMDAwLTB4MDAw
M10NCiAgWyAgIDE2Ljg1MjY2M10gcGNpIDAwMDA6MDA6MTQuMTogcmVnIDIwOiBbaW8gIDB4
ZmYwMC0weGZmMGZdDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA4XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE0LjENCiBbICAgMTYuODg0MDA3XSBwY2kgMDAwMDowMDoxNC4zOiBb
MTAwMjo0MzlkXSB0eXBlIDAwIGNsYXNzIDB4MDYwMTAwDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIwOjA4XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMNCiBbICAgMTYuOTE3MDEz
XSBwY2kgMDAwMDowMDoxNC40OiBbMTAwMjo0Mzg0XSB0eXBlIDAxIGNsYXNzIDB4MDYwNDAx
DQogIFsgICAxNi45MzUxODRdIHBjaSAwMDAwOjAwOjE0LjQ6IFN5c3RlbSB3YWtldXAgZGlz
YWJsZWQgYnkgQUNQSQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDowOF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxNC40DQogWyAgIDE2Ljk2NzE5OF0gcGNpIDAwMDA6MDA6MTQuNTog
WzEwMDI6NDM5OV0gdHlwZSAwMCBjbGFzcyAweDBjMDMxMA0KICBbICAgMTYuOTg1MjY0XSBw
Y2kgMDAwMDowMDoxNC41OiByZWcgMTA6IFttZW0gMHhmOTZmZDAwMC0weGY5NmZkZmZmXQ0K
ICBbICAgMTcuMDAzODc4XSBwY2kgMDAwMDowMDoxNC41OiBTeXN0ZW0gd2FrZXVwIGRpc2Fi
bGVkIGJ5IEFDUEkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTQuNQ0KIFsgICAxNy4wMzU4NDZdIHBjaSAwMDAwOjAwOjE1LjA6IFsx
MDAyOjQzYTBdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE3LjA1Mzk5Nl0gcGNp
IDAwMDA6MDA6MTUuMDogc3VwcG9ydHMgRDEgRDINCiAgWyAgIDE3LjA2Njk5M10gcGNpIDAw
MDA6MDA6MTUuMDogU3lzdGVtIHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJDQogIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE1LjANCiBbICAg
MTcuMDk5MDI2XSBwY2kgMDAwMDowMDoxNi4wOiBbMTAwMjo0Mzk3XSB0eXBlIDAwIGNsYXNz
IDB4MGMwMzEwDQogIFsgICAxNy4xMTcwNzRdIHBjaSAwMDAwOjAwOjE2LjA6IHJlZyAxMDog
W21lbSAweGY5NmZlMDAwLTB4Zjk2ZmVmZmZdDQogIFsgICAxNy4xMzU2ODddIHBjaSAwMDAw
OjAwOjE2LjA6IFN5c3RlbSB3YWtldXAgZGlzYWJsZWQgYnkgQUNQSQ0KICAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMDowOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQogWyAgIDE3
LjE2NzY2OF0gcGNpIDAwMDA6MDA6MTYuMjogWzEwMDI6NDM5Nl0gdHlwZSAwMCBjbGFzcyAw
eDBjMDMyMA0KICBbICAgMTcuMTg1NzE4XSBwY2kgMDAwMDowMDoxNi4yOiByZWcgMTA6IFtt
ZW0gMHhmOTZmZmMwMC0weGY5NmZmY2ZmXQ0KICBbICAgMTcuMjA0Mjc3XSBwY2kgMDAwMDow
MDoxNi4yOiBzdXBwb3J0cyBEMSBEMg0KICBbICAgMTcuMjE3MTUwXSBwY2kgMDAwMDowMDox
Ni4yOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQogIFsgICAxNy4yMzUz
NTldIHBjaSAwMDAwOjAwOjE2LjI6IFBNRSMgZGlzYWJsZWQNCiAgWyAgIDE3LjI0ODE3OF0g
cGNpIDAwMDA6MDA6MTYuMjogU3lzdGVtIHdha2V1cCBkaXNhYmxlZCBieSBBQ1BJDQogIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjIN
CiBbICAgMTcuMjgwMjQxXSBwY2kgMDAwMDowMDoxOC4wOiBbMTAyMjoxMjAwXSB0eXBlIDAw
IGNsYXNzIDB4MDYwMDAwDQogIFsgICAxNy4yOTgyNjddIHBjaSAwMDAwOjAwOjE4LjA6IGNh
bGxpbmcgcXVpcmtfbW1pb19hbHdheXNfb24rMHgwLzB4MTANCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMA0KIFsgICAxNy4zMzIy
MTNdIHBjaSAwMDAwOjAwOjE4LjE6IFsxMDIyOjEyMDFdIHR5cGUgMDAgY2xhc3MgMHgwNjAw
MDANCiAgWyAgIDE3LjM1MDI2NF0gcGNpIDAwMDA6MDA6MTguMTogY2FsbGluZyBxdWlya19t
bWlvX2Fsd2F5c19vbisweDAvMHgxMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDowOV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xDQogWyAgIDE3LjM4NDIxMl0gcGNpIDAwMDA6
MDA6MTguMjogWzEwMjI6MTIwMl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMA0KICBbICAgMTcu
NDAyMjcwXSBwY2kgMDAwMDowMDoxOC4yOiBjYWxsaW5nIHF1aXJrX21taW9fYWx3YXlzX29u
KzB4MC8weDEwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE4LjINCiBbICAgMTcuNDM2MTk5XSBwY2kgMDAwMDowMDoxOC4zOiBbMTAy
MjoxMjAzXSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwDQogIFsgICAxNy40NTQyNTldIHBjaSAw
MDAwOjAwOjE4LjM6IGNhbGxpbmcgcXVpcmtfbW1pb19hbHdheXNfb24rMHgwLzB4MTANCiAg
KFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTgu
Mw0KIFsgICAxNy40ODgyMDRdIHBjaSAwMDAwOjAwOjE4LjQ6IFsxMDIyOjEyMDRdIHR5cGUg
MDAgY2xhc3MgMHgwNjAwMDANCiAgWyAgIDE3LjUwNjI1Nl0gcGNpIDAwMDA6MDA6MTguNDog
Y2FsbGluZyBxdWlya19tbWlvX2Fsd2F5c19vbisweDAvMHgxMA0KICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMDowOV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQogWyAgIDE3LjU0
MDM1Nl0gcGNpX2J1cyAwMDAwOjAwOiBmaXh1cHMgZm9yIGJ1cw0KICBbICAgMTcuNTUyODkz
XSBwY2kgMDAwMDowMDowMi4wOiBzY2FubmluZyBbYnVzIDBjLTBjXSBiZWhpbmQgYnJpZGdl
LCBwYXNzIDANCiAgWyAgIDE3LjU3MzMwOV0gcGNpX2J1cyAwMDAwOjBjOiBzY2FubmluZyBi
dXMNCiAgWyAgIDE3LjU4NTM0MV0gcGNpIDAwMDA6MGM6MDAuMDogWzEwZGU6MDZlNF0gdHlw
ZSAwMCBjbGFzcyAweDAzMDAwMA0KICBbICAgMTcuNjAzNTQ1XSBwY2kgMDAwMDowYzowMC4w
OiByZWcgMTA6IFttZW0gMHhmZDAwMDAwMC0weGZkZmZmZmZmXQ0KICBbICAgMTcuNjIxOTkz
XSBwY2kgMDAwMDowYzowMC4wOiByZWcgMTQ6IFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZm
IDY0Yml0IHByZWZdDQogIFsgICAxNy42NDMzMjBdIHBjaSAwMDAwOjBjOjAwLjA6IHJlZyAx
YzogW21lbSAweGZhMDAwMDAwLTB4ZmJmZmZmZmYgNjRiaXRdDQogIFsgICAxNy42NjMzMjZd
IHBjaSAwMDAwOjBjOjAwLjA6IHJlZyAyNDogW2lvICAweGU4MDAtMHhlODdmXQ0KICBbICAg
MTcuNjc5NzEyXSBwY2kgMDAwMDowYzowMC4wOiByZWcgMzA6IFttZW0gMHhmZTllMDAwMC0w
eGZlOWZmZmZmIHByZWZdDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjA5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjBjOjAwLjANCiBbICAgMTcuNzIxMTg5XSBwY2lfYnVzIDAwMDA6MGM6
IGZpeHVwcyBmb3IgYnVzDQogIFsgICAxNy43MzM0NDhdIHBjaSAwMDAwOjAwOjAyLjA6IFBD
SSBicmlkZ2UgdG8gW2J1cyAwY10NCiAgWyAgIDE3Ljc0ODU0Ml0gcGNpIDAwMDA6MDA6MDIu
MDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0NCiAgWyAgIDE3Ljc2Njk4
Nl0gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAwMC0w
eGZlOWZmZmZmXQ0KICBbICAgMTcuNzg3NTM1XSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRn
ZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0NCiAgWyAg
IDE3LjgxMDkyMV0gcGNpX2J1cyAwMDAwOjBjOiBidXMgc2NhbiByZXR1cm5pbmcgd2l0aCBt
YXg9MGMNCiAgWyAgIDE3LjgyNzgyMl0gcGNpIDAwMDA6MDA6MDMuMDogc2Nhbm5pbmcgW2J1
cyAwYS0wYl0gYmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAxNy44NDgzMjZdIHBjaV9i
dXMgMDAwMDowYTogc2Nhbm5pbmcgYnVzDQogIFsgICAxNy44NjAzNDldIHBjaSAwMDAwOjBh
OjAwLjA6IFsxMDRjOjgyMzFdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDANCiAgWyAgIDE3Ljg3
ODY3NV0gcGNpIDAwMDA6MGE6MDAuMDogc3VwcG9ydHMgRDEgRDINCiAgKFhFTikgWzIwMTMt
MDItMjcgMTE6MjA6MDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMA0KIFsgICAxNy45
MDY0NzBdIHBjaSAwMDAwOjBhOjAwLjA6IGRpc2FibGluZyBBU1BNIG9uIHByZS0xLjEgUENJ
ZSBkZXZpY2UuICBZb3UgY2FuIGVuYWJsZSBpdCB3aXRoICdwY2llX2FzcG09Zm9yY2UnDQog
IFsgICAxNy45MzY1MDBdIHBjaV9idXMgMDAwMDowYTogZml4dXBzIGZvciBidXMNCiAgWyAg
IDE3Ljk0OTI0Ml0gcGNpIDAwMDA6MDA6MDMuMDogUENJIGJyaWRnZSB0byBbYnVzIDBhLTBi
XQ0KICBbICAgMTcuOTY1MDk3XSBwY2kgMDAwMDowMDowMy4wOiAgIGJyaWRnZSB3aW5kb3cg
W21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQogIFsgICAxNy45ODU2NDRdIHBjaSAwMDAw
OjBhOjAwLjA6IHNjYW5uaW5nIFtidXMgMGItMGJdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0K
ICBbICAgMTguMDA2MTU2XSBwY2lfYnVzIDAwMDA6MGI6IHNjYW5uaW5nIGJ1cw0KICBbICAg
MTguMDE4MTUxXSBwY2kgMDAwMDowYjowMS4wOiBbMTAzMzowMDM1XSB0eXBlIDAwIGNsYXNz
IDB4MGMwMzEwDQogIFsgICAxOC4wMzYzNjRdIHBjaSAwMDAwOjBiOjAxLjA6IHJlZyAxMDog
W21lbSAweGY5ZmZkMDAwLTB4ZjlmZmRmZmZdDQogIFsgICAxOC4wNTQ5MzNdIHBjaSAwMDAw
OjBiOjAxLjA6IHN1cHBvcnRzIEQxIEQyDQogIFsgICAxOC4wNjc3ODRdIHBjaSAwMDAwOjBi
OjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNCiAgWyAgIDE4LjA4
NTk5NV0gcGNpIDAwMDA6MGI6MDEuMDogUE1FIyBkaXNhYmxlZA0KICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMDoxMF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMS4wDQogWyAgIDE4LjEx
MzcxOF0gcGNpIDAwMDA6MGI6MDEuMTogWzEwMzM6MDAzNV0gdHlwZSAwMCBjbGFzcyAweDBj
MDMxMA0KICBbICAgMTguMTMxNzczXSBwY2kgMDAwMDowYjowMS4xOiByZWcgMTA6IFttZW0g
MHhmOWZmZTAwMC0weGY5ZmZlZmZmXQ0KICBbICAgMTguMTUwMzU1XSBwY2kgMDAwMDowYjow
MS4xOiBzdXBwb3J0cyBEMSBEMg0KICBbICAgMTguMTYzMTk5XSBwY2kgMDAwMDowYjowMS4x
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQogIFsgICAxOC4xODE0MTBd
IHBjaSAwMDAwOjBiOjAxLjE6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDItMjcg
MTE6MjA6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGI6MDEuMQ0KIFsgICAxOC4yMDkxMzBd
IHBjaSAwMDAwOjBiOjAxLjI6IFsxMDMzOjAwZTBdIHR5cGUgMDAgY2xhc3MgMHgwYzAzMjAN
CiAgWyAgIDE4LjIyNzE4NV0gcGNpIDAwMDA6MGI6MDEuMjogcmVnIDEwOiBbbWVtIDB4Zjlm
ZmZjMDAtMHhmOWZmZmNmZl0NCiAgWyAgIDE4LjI0NTc2OV0gcGNpIDAwMDA6MGI6MDEuMjog
c3VwcG9ydHMgRDEgRDINCiAgWyAgIDE4LjI1ODYxM10gcGNpIDAwMDA6MGI6MDEuMjogUE1F
IyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KICBbICAgMTguMjc2ODI3XSBwY2kg
MDAwMDowYjowMS4yOiBQTUUjIGRpc2FibGVkDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIw
OjEwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjBiOjAxLjINCiBbICAgMTguMzA0NjE4XSBwY2lf
YnVzIDAwMDA6MGI6IGZpeHVwcyBmb3IgYnVzDQogIFsgICAxOC4zMTcxMTFdIHBjaSAwMDAw
OjBhOjAwLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwYl0NCiAgWyAgIDE4LjMzMjIwOF0gcGNp
IDAwMDA6MGE6MDAuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWYwMDAwMC0weGY5ZmZm
ZmZmXQ0KICBbICAgMTguMzUyNzM5XSBwY2lfYnVzIDAwMDA6MGI6IGJ1cyBzY2FuIHJldHVy
bmluZyB3aXRoIG1heD0wYg0KICBbICAgMTguMzY5NjM4XSBwY2kgMDAwMDowYTowMC4wOiBz
Y2FubmluZyBbYnVzIDBiLTBiXSBiZWhpbmQgYnJpZGdlLCBwYXNzIDENCiAgWyAgIDE4LjM4
OTkxMV0gcGNpX2J1cyAwMDAwOjBhOiBidXMgc2NhbiByZXR1cm5pbmcgd2l0aCBtYXg9MGIN
CiAgWyAgIDE4LjQwNjgwN10gcGNpIDAwMDA6MDA6MDUuMDogc2Nhbm5pbmcgW2J1cyAwOS0w
OV0gYmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAxOC40MjcyODRdIHBjaV9idXMgMDAw
MDowOTogc2Nhbm5pbmcgYnVzDQogIFsgICAxOC40MzkzMjddIHBjaSAwMDAwOjA5OjAwLjA6
IFsxMGVjOjgxNjhdIHR5cGUgMDAgY2xhc3MgMHgwMjAwMDANCiAgWyAgIDE4LjQ1NzUyN10g
cGNpIDAwMDA6MDk6MDAuMDogcmVnIDEwOiBbaW8gIDB4ZDgwMC0weGQ4ZmZdDQogIFsgICAx
OC40NzM5MTFdIHBjaSAwMDAwOjA5OjAwLjA6IHJlZyAxODogW21lbSAweGNmZmZmMDAwLTB4
Y2ZmZmZmZmYgNjRiaXQgcHJlZl0NCiAgWyAgIDE4LjQ5NTIyNV0gcGNpIDAwMDA6MDk6MDAu
MDogcmVnIDIwOiBbbWVtIDB4Y2ZmZjgwMDAtMHhjZmZmYmZmZiA2NGJpdCBwcmVmXQ0KICBb
ICAgMTguNTE2NTMwXSBwY2kgMDAwMDowOTowMC4wOiByZWcgMzA6IFttZW0gMHhmOWVlMDAw
MC0weGY5ZWZmZmZmIHByZWZdDQogIFsgICAxOC41MzYzNTFdIHBjaSAwMDAwOjA5OjAwLjA6
IHN1cHBvcnRzIEQxIEQyDQogIFsgICAxOC41NDkyNzNdIHBjaSAwMDAwOjA5OjAwLjA6IFBN
RSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QgRDNjb2xkDQogIFsgICAxOC41Njkz
MzBdIHBjaSAwMDAwOjA5OjAwLjA6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjA6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDk6MDAuMA0KIFsgICAxOC42MDM4
ODNdIHBjaV9idXMgMDAwMDowOTogZml4dXBzIGZvciBidXMNCiAgWyAgIDE4LjYxNjEzOV0g
cGNpIDAwMDA6MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5XQ0KICBbICAgMTguNjMx
MjMxXSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhk
ZmZmXQ0KICBbICAgMTguNjQ5Njc4XSBwY2kgMDAwMDowMDowNS4wOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGY5ZTAwMDAwLTB4ZjllZmZmZmZdDQogIFsgICAxOC42NzAyMTddIHBjaSAw
MDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZm
ZiA2NGJpdCBwcmVmXQ0KICBbICAgMTguNjkzNjExXSBwY2lfYnVzIDAwMDA6MDk6IGJ1cyBz
Y2FuIHJldHVybmluZyB3aXRoIG1heD0wOQ0KICBbICAgMTguNzEwNTEyXSBwY2kgMDAwMDow
MDowNi4wOiBzY2FubmluZyBbYnVzIDA4LTA4XSBiZWhpbmQgYnJpZGdlLCBwYXNzIDANCiAg
WyAgIDE4LjczMTAwN10gcGNpX2J1cyAwMDAwOjA4OiBzY2FubmluZyBidXMNCiAgWyAgIDE4
Ljc0MzAzNF0gcGNpIDAwMDA6MDg6MDAuMDogWzEwZWM6ODE2OF0gdHlwZSAwMCBjbGFzcyAw
eDAyMDAwMA0KICBbICAgMTguNzYxMjM2XSBwY2kgMDAwMDowODowMC4wOiByZWcgMTA6IFtp
byAgMHhjODAwLTB4YzhmZl0NCiAgWyAgIDE4Ljc3NzYxOV0gcGNpIDAwMDA6MDg6MDAuMDog
cmVnIDE4OiBbbWVtIDB4Y2ZlZmYwMDAtMHhjZmVmZmZmZiA2NGJpdCBwcmVmXQ0KICBbICAg
MTguNzk4OTMxXSBwY2kgMDAwMDowODowMC4wOiByZWcgMjA6IFttZW0gMHhjZmVmODAwMC0w
eGNmZWZiZmZmIDY0Yml0IHByZWZdDQogIFsgICAxOC44MjAyMzRdIHBjaSAwMDAwOjA4OjAw
LjA6IHJlZyAzMDogW21lbSAweGY5ZGUwMDAwLTB4ZjlkZmZmZmYgcHJlZl0NCiAgWyAgIDE4
Ljg0MDA2M10gcGNpIDAwMDA6MDg6MDAuMDogc3VwcG9ydHMgRDEgRDINCiAgWyAgIDE4Ljg1
Mjk4MF0gcGNpIDAwMDA6MDg6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBE
M2hvdCBEM2NvbGQNCiAgWyAgIDE4Ljg3MzAwM10gcGNpIDAwMDA6MDg6MDAuMDogUE1FIyBk
aXNhYmxlZA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowODowMC4wDQogWyAgIDE4LjkwNzU2N10gcGNpX2J1cyAwMDAwOjA4OiBmaXh1cHMg
Zm9yIGJ1cw0KICBbICAgMTguOTE5ODI3XSBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDhdDQogIFsgICAxOC45MzQ5MTddIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4YzAwMC0weGNmZmZdDQogIFsgICAxOC45NTMzNjVdIHBjaSAw
MDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjlkMDAwMDAtMHhmOWRmZmZm
Zl0NCiAgWyAgIDE4Ljk3MzkwNV0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhjZmUwMDAwMC0weGNmZWZmZmZmIDY0Yml0IHByZWZdDQogIFsgICAxOC45OTcy
OTZdIHBjaV9idXMgMDAwMDowODogYnVzIHNjYW4gcmV0dXJuaW5nIHdpdGggbWF4PTA4DQog
IFsgICAxOS4wMTQyMDBdIHBjaSAwMDAwOjAwOjA5LjA6IHNjYW5uaW5nIFtidXMgMDctMDdd
IGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuMDM0Njg3XSBwY2lfYnVzIDAwMDA6
MDc6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuMDQ2NzIzXSBwY2kgMDAwMDowNzowMC4wOiBb
MTAzMzowMTk0XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzMwDQogIFsgICAxOS4wNjQ5MjddIHBj
aSAwMDAwOjA3OjAwLjA6IHJlZyAxMDogW21lbSAweGY5Y2ZlMDAwLTB4ZjljZmZmZmYgNjRi
aXRdDQogIFsgICAxOS4wODUwNDNdIHBjaSAwMDAwOjA3OjAwLjA6IFBNRSMgc3VwcG9ydGVk
IGZyb20gRDAgRDNob3QgRDNjb2xkDQogIFsgICAxOS4xMDMzODRdIHBjaSAwMDAwOjA3OjAw
LjA6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MTFdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDc6MDAuMA0KIFsgICAxOS4xMzc4MTFdIHBjaV9idXMgMDAwMDow
NzogZml4dXBzIGZvciBidXMNCiAgWyAgIDE5LjE1MDA2OF0gcGNpIDAwMDA6MDA6MDkuMDog
UENJIGJyaWRnZSB0byBbYnVzIDA3XQ0KICBbICAgMTkuMTY1MTYxXSBwY2kgMDAwMDowMDow
OS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YzAwMDAwLTB4ZjljZmZmZmZdDQogIFsg
ICAxOS4xODU2ODldIHBjaV9idXMgMDAwMDowNzogYnVzIHNjYW4gcmV0dXJuaW5nIHdpdGgg
bWF4PTA3DQogIFsgICAxOS4yMDI1ODVdIHBjaSAwMDAwOjAwOjBhLjA6IHNjYW5uaW5nIFti
dXMgMDYtMDZdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuMjIzMDc0XSBwY2lf
YnVzIDAwMDA6MDY6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuMjM1MTAyXSBwY2kgMDAwMDow
NjowMC4wOiBbMTRmMTo4MjEwXSB0eXBlIDAwIGNsYXNzIDB4MDQwMDAwDQogIFsgICAxOS4y
NTMzMTldIHBjaSAwMDAwOjA2OjAwLjA6IHJlZyAxMDogW21lbSAweGY5YTAwMDAwLTB4Zjli
ZmZmZmYgNjRiaXRdDQogIFsgICAxOS4yNzM0NjVdIHBjaSAwMDAwOjA2OjAwLjA6IHN1cHBv
cnRzIEQxIEQyDQogIFsgICAxOS4yODYzMDVdIHBjaSAwMDAwOjA2OjAwLjA6IFBNRSMgc3Vw
cG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNCiAgWyAgIDE5LjMwNDUwMl0gcGNpIDAwMDA6
MDY6MDAuMDogUE1FIyBkaXNhYmxlZA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wDQogWyAgIDE5LjMzOTA1NV0gcGNpX2J1cyAw
MDAwOjA2OiBmaXh1cHMgZm9yIGJ1cw0KICBbICAgMTkuMzUxMzIwXSBwY2kgMDAwMDowMDow
YS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDZdDQogIFsgICAxOS4zNjY0MTldIHBjaSAwMDAw
OjAwOjBhLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjlhMDAwMDAtMHhmOWJmZmZmZl0N
CiAgWyAgIDE5LjM4Njk0MV0gcGNpX2J1cyAwMDAwOjA2OiBidXMgc2NhbiByZXR1cm5pbmcg
d2l0aCBtYXg9MDYNCiAgWyAgIDE5LjQwMzgzOV0gcGNpIDAwMDA6MDA6MGIuMDogc2Nhbm5p
bmcgW2J1cyAwNS0wNV0gYmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAxOS40MjQzMjdd
IHBjaV9idXMgMDAwMDowNTogc2Nhbm5pbmcgYnVzDQogIFsgICAxOS40MzYzNTRdIHBjaSAw
MDAwOjA1OjAwLjA6IFsxMDAyOjY3NTldIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDANCiAgWyAg
IDE5LjQ1NDU2NF0gcGNpIDAwMDA6MDU6MDAuMDogcmVnIDEwOiBbbWVtIDB4YjAwMDAwMDAt
MHhiZmZmZmZmZiA2NGJpdCBwcmVmXQ0KICBbICAgMTkuNDc1ODcxXSBwY2kgMDAwMDowNTow
MC4wOiByZWcgMTg6IFttZW0gMHhmOTljMDAwMC0weGY5OWRmZmZmIDY0Yml0XQ0KICBbICAg
MTkuNDk1ODkwXSBwY2kgMDAwMDowNTowMC4wOiByZWcgMjA6IFtpbyAgMHhiMDAwLTB4YjBm
Zl0NCiAgWyAgIDE5LjUxMjI3M10gcGNpIDAwMDA6MDU6MDAuMDogcmVnIDMwOiBbbWVtIDB4
Zjk5YTAwMDAtMHhmOTliZmZmZiBwcmVmXQ0KICBbICAgMTkuNTMyMDY4XSBwY2kgMDAwMDow
NTowMC4wOiBzdXBwb3J0cyBEMSBEMg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMV0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQogWyAgIDE5LjU2MDE3NF0gcGNpIDAwMDA6
MDU6MDAuMTogWzEwMDI6YWE5MF0gdHlwZSAwMCBjbGFzcyAweDA0MDMwMA0KICBbICAgMTku
NTc4MDg2XSBwY2kgMDAwMDowNTowMC4xOiByZWcgMTA6IFttZW0gMHhmOTlmYzAwMC0weGY5
OWZmZmZmIDY0Yml0XQ0KICBbICAgMTkuNTk4MjAzXSBwY2kgMDAwMDowNTowMC4xOiBzdXBw
b3J0cyBEMSBEMg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMV0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNTowMC4xDQogWyAgIDE5LjYzMjg5M10gcGNpX2J1cyAwMDAwOjA1OiBmaXh1
cHMgZm9yIGJ1cw0KICBbICAgMTkuNjQ1MTQ4XSBwY2kgMDAwMDowMDowYi4wOiBQQ0kgYnJp
ZGdlIHRvIFtidXMgMDVdDQogIFsgICAxOS42NjAyMzldIHBjaSAwMDAwOjAwOjBiLjA6ICAg
YnJpZGdlIHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZdDQogIFsgICAxOS42Nzg2ODddIHBj
aSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Zjk5MDAwMDAtMHhmOTlm
ZmZmZl0NCiAgWyAgIDE5LjY5OTIyNl0gcGNpIDAwMDA6MDA6MGIuMDogICBicmlkZ2Ugd2lu
ZG93IFttZW0gMHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQogIFsgICAxOS43
MjI2MjFdIHBjaV9idXMgMDAwMDowNTogYnVzIHNjYW4gcmV0dXJuaW5nIHdpdGggbWF4PTA1
DQogIFsgICAxOS43Mzk1MjFdIHBjaSAwMDAwOjAwOjBkLjA6IHNjYW5uaW5nIFtidXMgMDQt
MDRdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuNzYwMDA4XSBwY2lfYnVzIDAw
MDA6MDQ6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuNzcyMDUwXSBwY2kgMDAwMDowNDowMC4w
OiBbMTAzMzowMTk0XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzMwDQogIFsgICAxOS43OTAyNDhd
IHBjaSAwMDAwOjA0OjAwLjA6IHJlZyAxMDogW21lbSAweGY5OGZlMDAwLTB4Zjk4ZmZmZmYg
NjRiaXRdDQogIFsgICAxOS44MTAzNjNdIHBjaSAwMDAwOjA0OjAwLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQogIFsgICAxOS44Mjg3MDddIHBjaSAwMDAwOjA0
OjAwLjA6IFBNRSMgZGlzYWJsZWQNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MTFdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMA0KIFsgICAxOS44NjMyNTFdIHBjaV9idXMgMDAw
MDowNDogZml4dXBzIGZvciBidXMNCiAgWyAgIDE5Ljg3NTUyMl0gcGNpIDAwMDA6MDA6MGQu
MDogUENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KICBbICAgMTkuODkwNjEzXSBwY2kgMDAwMDow
MDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5ODAwMDAwLTB4Zjk4ZmZmZmZdDQog
IFsgICAxOS45MTExNDJdIHBjaV9idXMgMDAwMDowNDogYnVzIHNjYW4gcmV0dXJuaW5nIHdp
dGggbWF4PTA0DQogIFsgICAxOS45MjgwMzhdIHBjaSAwMDAwOjAwOjE0LjQ6IHNjYW5uaW5n
IFtidXMgMDMtMDNdIGJlaGluZCBicmlkZ2UsIHBhc3MgMA0KICBbICAgMTkuOTQ4NDg3XSBw
Y2lfYnVzIDAwMDA6MDM6IHNjYW5uaW5nIGJ1cw0KICBbICAgMTkuOTYwNTY1XSBwY2kgMDAw
MDowMzowNi4wOiBbMTNmNjowMTExXSB0eXBlIDAwIGNsYXNzIDB4MDQwMTAwDQogIFsgICAx
OS45Nzg3NjhdIHBjaSAwMDAwOjAzOjA2LjA6IHJlZyAxMDogW2lvICAweGE4MDAtMHhhOGZm
XQ0KICBbICAgMTkuOTk1MjQ1XSBwY2kgMDAwMDowMzowNi4wOiBzdXBwb3J0cyBEMSBEMg0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxMl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzow
Ni4wDQogWyAgIDIwLjAyMzE1MF0gcGNpX2J1cyAwMDAwOjAzOiBmaXh1cHMgZm9yIGJ1cw0K
ICBbICAgMjAuMDM1NjcxXSBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDNdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQogIFsgICAyMC4wNTYyMjhdIHBjaSAwMDAwOjAw
OjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YTAwMC0weGFmZmZdDQogIFsgICAyMC4w
NzQ2NzRdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0w
eDBjZjddIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQogIFsgICAyMC4wOTg1OTRdIHBjaSAwMDAw
OjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZmZmZdIChzdWJ0cmFj
dGl2ZSBkZWNvZGUpDQogIFsgICAyMC4xMjI1MDJdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJp
ZGdlIHdpbmRvdyBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0gKHN1YnRyYWN0aXZlIGRl
Y29kZSkNCiAgWyAgIDIwLjE0ODQ5OV0gcGNpIDAwMDA6MDA6MTQuNDogICBicmlkZ2Ugd2lu
ZG93IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQ0K
ICBbICAgMjAuMTc0NDk4XSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5kb3cgW21l
bSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQogIFsgICAy
MC4yMDA0OTZdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjAw
MDAwMDAtMHhmZWJmZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkNCiAgWyAgIDIwLjIyNjQ5
NF0gcGNpX2J1cyAwMDAwOjAzOiBidXMgc2NhbiByZXR1cm5pbmcgd2l0aCBtYXg9MDMNCiAg
WyAgIDIwLjI0MzM5OF0gcGNpIDAwMDA6MDA6MTUuMDogc2Nhbm5pbmcgW2J1cyAwMi0wMl0g
YmVoaW5kIGJyaWRnZSwgcGFzcyAwDQogIFsgICAyMC4yNjM4OTFdIHBjaV9idXMgMDAwMDow
Mjogc2Nhbm5pbmcgYnVzDQogIFsgICAyMC4yNzU4OTZdIHBjaV9idXMgMDAwMDowMjogZml4
dXBzIGZvciBidXMNCiAgWyAgIDIwLjI4ODY0MF0gcGNpIDAwMDA6MDA6MTUuMDogUENJIGJy
aWRnZSB0byBbYnVzIDAyXQ0KICBbICAgMjAuMzAzNzI3XSBwY2lfYnVzIDAwMDA6MDI6IGJ1
cyBzY2FuIHJldHVybmluZyB3aXRoIG1heD0wMg0KICBbICAgMjAuMzIwNjE0XSBwY2kgMDAw
MDowMDowMi4wOiBzY2FubmluZyBbYnVzIDBjLTBjXSBiZWhpbmQgYnJpZGdlLCBwYXNzIDEN
CiAgWyAgIDIwLjM0MDkwMV0gcGNpIDAwMDA6MDA6MDMuMDogc2Nhbm5pbmcgW2J1cyAwYS0w
Yl0gYmVoaW5kIGJyaWRnZSwgcGFzcyAxDQogIFsgICAyMC4zNjExNzNdIHBjaSAwMDAwOjAw
OjA1LjA6IHNjYW5uaW5nIFtidXMgMDktMDldIGJlaGluZCBicmlkZ2UsIHBhc3MgMQ0KICBb
ICAgMjAuMzgxNDUwXSBwY2kgMDAwMDowMDowNi4wOiBzY2FubmluZyBbYnVzIDA4LTA4XSBi
ZWhpbmQgYnJpZGdlLCBwYXNzIDENCiAgWyAgIDIwLjQwMTcyOF0gcGNpIDAwMDA6MDA6MDku
MDogc2Nhbm5pbmcgW2J1cyAwNy0wN10gYmVoaW5kIGJyaWRnZSwgcGFzcyAxDQogIFsgICAy
MC40MjIwMDldIHBjaSAwMDAwOjAwOjBhLjA6IHNjYW5uaW5nIFtidXMgMDYtMDZdIGJlaGlu
ZCBicmlkZ2UsIHBhc3MgMQ0KICBbICAgMjAuNDQyMjg3XSBwY2kgMDAwMDowMDowYi4wOiBz
Y2FubmluZyBbYnVzIDA1LTA1XSBiZWhpbmQgYnJpZGdlLCBwYXNzIDENCiAgWyAgIDIwLjQ2
MjU2Nl0gcGNpIDAwMDA6MDA6MGQuMDogc2Nhbm5pbmcgW2J1cyAwNC0wNF0gYmVoaW5kIGJy
aWRnZSwgcGFzcyAxDQogIFsgICAyMC40ODI4NDRdIHBjaSAwMDAwOjAwOjE0LjQ6IHNjYW5u
aW5nIFtidXMgMDMtMDNdIGJlaGluZCBicmlkZ2UsIHBhc3MgMQ0KICBbICAgMjAuNTAzMTI2
XSBwY2kgMDAwMDowMDoxNS4wOiBzY2FubmluZyBbYnVzIDAyLTAyXSBiZWhpbmQgYnJpZGdl
LCBwYXNzIDENCiAgWyAgIDIwLjUyMzQwMl0gcGNpX2J1cyAwMDAwOjAwOiBidXMgc2NhbiBy
ZXR1cm5pbmcgd2l0aCBtYXg9MGMNCiAgWyAgIDIwLjU0MjU5NV0gQUNQSTogUENJIEludGVy
cnVwdCBMaW5rIFtMTktBXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQ0KICBbICAgMjAuNTYx
MjIxXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFzIDQgNyAxMCAqMTEg
MTQgMTUpDQogIFsgICAyMC41ODAyMDVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L
Q10gKElSUXMgNCA3ICoxMCAxMSAxNCAxNSkNCiAgWyAgIDIwLjU5OTE4NV0gQUNQSTogUENJ
IEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQ0KICBbICAg
MjAuNjE4MTQzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFzIDQgKjcg
MTAgMTEgMTQgMTUpDQogIFsgICAyMC42MzcxMDVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGlu
ayBbTE5LRl0gKElSUXMgNCA3IDEwICoxMSAxNCAxNSkNCiAgWyAgIDIwLjY1NjA4NF0gQUNQ
STogUENJIEludGVycnVwdCBMaW5rIFtMTktHXSAoSVJRcyA0IDcgKjEwIDExIDE0IDE1KQ0K
ICBbICAgMjAuNjc1MDY3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFz
IDQgNyAqMTAgMTEgMTQgMTUpDQogIFsgICAyMC42OTQ5MTFdIGFjcGkgcm9vdDogXF9TQl8u
UENJMCBub3RpZnkgaGFuZGxlciBpcyBpbnN0YWxsZWQNCiAgWyAgIDIwLjcxMTk3OV0gRm91
bmQgMSBhY3BpIHJvb3QgZGV2aWNlcw0KICBbICAgMjAuNzIzNDgyXSB4ZW4vYmFsbG9vbjog
SW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyLg0KICBbICAgMjAuNzM4OTA0XSB4ZW4tYmFs
bG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyLg0KICBbICAgMjAuNzU0NDkzXSB2
Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MGM6MDAuMCxkZWNvZGVzPWlvK21lbSxv
d25zPWlvK21lbSxsb2Nrcz1ub25lDQogIFsgICAyMC43Nzg0NjhdIHZnYWFyYjogZGV2aWNl
IGFkZGVkOiBQQ0k6MDAwMDowNTowMC4wLGRlY29kZXM9aW8rbWVtLG93bnM9bm9uZSxsb2Nr
cz1ub25lDQogIFsgICAyMC44MDIzODddIHZnYWFyYjogbG9hZGVkDQogIFsgICAyMC44MTA2
OTBdIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowNTowMC4wDQogIFsg
ICAyMC44MjY4MTddIHZnYWFyYjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowYzow
MC4wDQogIFsgICAyMC44NDMzNDJdIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkDQogIFsg
ICAyMC44NTQzNzBdIEFDUEk6IGJ1cyB0eXBlIHNjc2kgcmVnaXN0ZXJlZA0KICBbICAgMjAu
ODY3NDc1XSBsaWJhdGEgdmVyc2lvbiAzLjAwIGxvYWRlZC4NCiAgWyAgIDIwLjg3OTMwNl0g
QUNQSTogYnVzIHR5cGUgdXNiIHJlZ2lzdGVyZWQNCiAgWyAgIDIwLjg5MTMwNF0gdXNiY29y
ZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcw0KICBbICAgMjAuOTA3
OTYyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1Yg0KICBb
ICAgMjAuOTI0MTY3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVz
Yg0KICBbICAgMjAuOTM5NjExXSBMaW51eCB2aWRlbyBjYXB0dXJlIGludGVyZmFjZTogdjIu
MDANCiAgWyAgIDIwLjk1MzY2Ml0gcHBzX2NvcmU6IExpbnV4UFBTIEFQSSB2ZXIuIDEgcmVn
aXN0ZXJlZA0KICBbICAgMjAuOTY4Mjc3XSBwcHNfY29yZTogU29mdHdhcmUgdmVyLiA1LjMu
NiAtIENvcHlyaWdodCAyMDA1LTIwMDcgUm9kb2xmbyBHaW9tZXR0aSA8Z2lvbWV0dGlAbGlu
dXguaXQ+DQogIFsgICAyMC45OTYxOTJdIFBUUCBjbG9jayBzdXBwb3J0IHJlZ2lzdGVyZWQN
CiAgWyAgIDIxLjAwODUwN10gQWR2YW5jZWQgTGludXggU291bmQgQXJjaGl0ZWN0dXJlIERy
aXZlciBJbml0aWFsaXplZC4NCiAgWyAgIDIxLjAyNjQ5Ml0gUENJOiBVc2luZyBBQ1BJIGZv
ciBJUlEgcm91dGluZw0KICBbICAgMjEuMDQ5OTE3XSBQQ0k6IHBjaV9jYWNoZV9saW5lX3Np
emUgc2V0IHRvIDY0IGJ5dGVzDQogIFsgICAyMS4wNjQ1NDFdIHBjaSAwMDAwOjBjOjAwLjA6
IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGZkMDAwMDAwLTB4ZmRmZmZmZmYgZmxhZ3MgMHg0
MDIwMF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuMDkxODA0XSBwY2kgMDAwMDowYzowMC4wOiBC
QVIgMTogcmVzZXJ2aW5nIFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmIGZsYWdzIDB4MTQy
MjBjXSAoZD0wLCBwPTApDQogIFsgICAyMS4xMTkzNzldIHBjaSAwMDAwOjBjOjAwLjA6IEJB
UiAzOiByZXNlcnZpbmcgW21lbSAweGZhMDAwMDAwLTB4ZmJmZmZmZmYgZmxhZ3MgMHgxNDAy
MDRdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjE0NjkyM10gcGNpIDAwMDA6MGM6MDAuMDogQkFS
IDU6IHJlc2VydmluZyBbaW8gIDB4ZTgwMC0weGU4N2YgZmxhZ3MgMHg0MDEwMV0gKGQ9MCwg
cD0wKQ0KICBbICAgMjEuMTcyMTU2XSBwY2kgMDAwMDowYjowMS4wOiBCQVIgMDogcmVzZXJ2
aW5nIFttZW0gMHhmOWZmZDAwMC0weGY5ZmZkZmZmIGZsYWdzIDB4NDAyMDBdIChkPTAsIHA9
MCkNCiAgWyAgIDIxLjE5OTQ0OV0gcGNpIDAwMDA6MGI6MDEuMTogQkFSIDA6IHJlc2Vydmlu
ZyBbbWVtIDB4ZjlmZmUwMDAtMHhmOWZmZWZmZiBmbGFncyAweDQwMjAwXSAoZD0wLCBwPTAp
DQogIFsgICAyMS4yMjY3NDRdIHBjaSAwMDAwOjBiOjAxLjI6IEJBUiAwOiByZXNlcnZpbmcg
W21lbSAweGY5ZmZmYzAwLTB4ZjlmZmZjZmYgZmxhZ3MgMHg0MDIwMF0gKGQ9MCwgcD0wKQ0K
ICBbICAgMjEuMjU0MDQyXSBwY2kgMDAwMDowOTowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFtp
byAgMHhkODAwLTB4ZDhmZiBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTApDQogIFsgICAyMS4y
NzkyNTldIHBjaSAwMDAwOjA5OjAwLjA6IEJBUiAyOiByZXNlcnZpbmcgW21lbSAweGNmZmZm
MDAwLTB4Y2ZmZmZmZmYgZmxhZ3MgMHgxNDIyMGNdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjMw
NjgxOF0gcGNpIDAwMDA6MDk6MDAuMDogQkFSIDQ6IHJlc2VydmluZyBbbWVtIDB4Y2ZmZjgw
MDAtMHhjZmZmYmZmZiBmbGFncyAweDE0MjIwY10gKGQ9MCwgcD0wKQ0KICBbICAgMjEuMzM0
Mzc5XSBwY2kgMDAwMDowODowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFtpbyAgMHhjODAwLTB4
YzhmZiBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTApDQogIFsgICAyMS4zNTk2MDVdIHBjaSAw
MDAwOjA4OjAwLjA6IEJBUiAyOiByZXNlcnZpbmcgW21lbSAweGNmZWZmMDAwLTB4Y2ZlZmZm
ZmYgZmxhZ3MgMHgxNDIyMGNdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjM4NzE1M10gcGNpIDAw
MDA6MDg6MDAuMDogQkFSIDQ6IHJlc2VydmluZyBbbWVtIDB4Y2ZlZjgwMDAtMHhjZmVmYmZm
ZiBmbGFncyAweDE0MjIwY10gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNDE0NzA4XSBwY2kgMDAw
MDowNzowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOWNmZTAwMC0weGY5Y2ZmZmZm
IGZsYWdzIDB4MTQwMjA0XSAoZD0wLCBwPTApDQogIFsgICAyMS40NDIyNzNdIHBjaSAwMDAw
OjA2OjAwLjA6IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGY5YTAwMDAwLTB4ZjliZmZmZmYg
ZmxhZ3MgMHgxNDAyMDRdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjQ2OTgzM10gcGNpIDAwMDA6
MDU6MDAuMTogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk5ZmMwMDAtMHhmOTlmZmZmZiBm
bGFncyAweDE0MDIwNF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNDk3MzkwXSBwY2kgMDAwMDow
NDowMC4wOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOThmZTAwMC0weGY5OGZmZmZmIGZs
YWdzIDB4MTQwMjA0XSAoZD0wLCBwPTApDQogIFsgICAyMS41MjQ5NDVdIHBjaSAwMDAwOjAw
OjExLjA6IEJBUiAwOiByZXNlcnZpbmcgW2lvICAweDcwMDAtMHg3MDA3IGZsYWdzIDB4NDAx
MDFdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjU1MDE2M10gcGNpIDAwMDA6MDA6MTEuMDogQkFS
IDE6IHJlc2VydmluZyBbaW8gIDB4NjAwMC0weDYwMDMgZmxhZ3MgMHg0MDEwMV0gKGQ9MCwg
cD0wKQ0KICBbICAgMjEuNTc1NDExXSBwY2kgMDAwMDowMDoxMS4wOiBCQVIgMjogcmVzZXJ2
aW5nIFtpbyAgMHg1MDAwLTB4NTAwNyBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTApDQogIFsg
ICAyMS42MDA2NDhdIHBjaSAwMDAwOjAwOjExLjA6IEJBUiAzOiByZXNlcnZpbmcgW2lvICAw
eDMwMDAtMHgzMDAzIGZsYWdzIDB4NDAxMDFdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjYyNTg0
OV0gcGNpIDAwMDA6MDA6MTEuMDogQkFSIDQ6IHJlc2VydmluZyBbaW8gIDB4MjAwMC0weDIw
MGYgZmxhZ3MgMHg0MDEwMV0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNjUxMDY5XSBwY2kgMDAw
MDowMDoxMS4wOiBCQVIgNTogcmVzZXJ2aW5nIFttZW0gMHhmOTZmZjAwMC0weGY5NmZmM2Zm
IGZsYWdzIDB4NDAyMDBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjY3ODM2OV0gcGNpIDAwMDA6
MDA6MTIuMDogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk2ZmIwMDAtMHhmOTZmYmZmZiBm
bGFncyAweDQwMjAwXSAoZD0wLCBwPTApDQogIFsgICAyMS43MDU2NjBdIHBjaSAwMDAwOjAw
OjEyLjI6IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGY5NmZmNDAwLTB4Zjk2ZmY0ZmYgZmxh
Z3MgMHg0MDIwMF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuNzMyOTU4XSBwY2kgMDAwMDowMDox
My4wOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOTZmYzAwMC0weGY5NmZjZmZmIGZsYWdz
IDB4NDAyMDBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjc2MDI2NV0gcGNpIDAwMDA6MDA6MTMu
MjogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk2ZmY4MDAtMHhmOTZmZjhmZiBmbGFncyAw
eDQwMjAwXSAoZD0wLCBwPTApDQogIFsgICAyMS43ODc1NjNdIHBjaSAwMDAwOjAwOjE0LjE6
IEJBUiAwOiByZXNlcnZpbmcgW2lvICAweDAxZjAtMHgwMWY3IGZsYWdzIDB4MTEwXSAoZD0w
LCBwPTApDQogIFsgICAyMS44MTIyNThdIHBjaSAwMDAwOjAwOjE0LjE6IEJBUiAxOiByZXNl
cnZpbmcgW2lvICAweDAzZjYgZmxhZ3MgMHgxMTBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjgz
NTEzNl0gcGNpIDAwMDA6MDA6MTQuMTogQkFSIDI6IHJlc2VydmluZyBbaW8gIDB4MDE3MC0w
eDAxNzcgZmxhZ3MgMHgxMTBdIChkPTAsIHA9MCkNCiAgWyAgIDIxLjg1OTgzNF0gcGNpIDAw
MDA6MDA6MTQuMTogQkFSIDM6IHJlc2VydmluZyBbaW8gIDB4MDM3NiBmbGFncyAweDExMF0g
KGQ9MCwgcD0wKQ0KICBbICAgMjEuODgyNzA3XSBwY2kgMDAwMDowMDoxNC4xOiBCQVIgNDog
cmVzZXJ2aW5nIFtpbyAgMHhmZjAwLTB4ZmYwZiBmbGFncyAweDQwMTAxXSAoZD0wLCBwPTAp
DQogIFsgICAyMS45MDc5MzldIHBjaSAwMDAwOjAzOjA2LjA6IEJBUiAwOiByZXNlcnZpbmcg
W2lvICAweGE4MDAtMHhhOGZmIGZsYWdzIDB4NDAxMDFdIChkPTAsIHA9MCkNCiAgWyAgIDIx
LjkzMzE1Ml0gcGNpIDAwMDA6MDA6MTQuNTogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4Zjk2
ZmQwMDAtMHhmOTZmZGZmZiBmbGFncyAweDQwMjAwXSAoZD0wLCBwPTApDQogIFsgICAyMS45
NjA0NTJdIHBjaSAwMDAwOjAwOjE2LjA6IEJBUiAwOiByZXNlcnZpbmcgW21lbSAweGY5NmZl
MDAwLTB4Zjk2ZmVmZmYgZmxhZ3MgMHg0MDIwMF0gKGQ9MCwgcD0wKQ0KICBbICAgMjEuOTg3
NzUyXSBwY2kgMDAwMDowMDoxNi4yOiBCQVIgMDogcmVzZXJ2aW5nIFttZW0gMHhmOTZmZmMw
MC0weGY5NmZmY2ZmIGZsYWdzIDB4NDAyMDBdIChkPTAsIHA9MCkNCiAgWyAgIDIyLjAxNTA4
M10gcGNpIDAwMDA6MDU6MDAuMDogQkFSIDA6IHJlc2VydmluZyBbbWVtIDB4YjAwMDAwMDAt
MHhiZmZmZmZmZiBmbGFncyAweDE0MjIwY10gKGQ9MSwgcD0xKQ0KICBbICAgMjIuMDQyNjA0
XSBwY2kgMDAwMDowNTowMC4wOiBCQVIgMjogcmVzZXJ2aW5nIFttZW0gMHhmOTljMDAwMC0w
eGY5OWRmZmZmIGZsYWdzIDB4MTQwMjA0XSAoZD0xLCBwPTEpDQogIFsgICAyMi4wNzAxNjRd
IHBjaSAwMDAwOjA1OjAwLjA6IEJBUiA0OiByZXNlcnZpbmcgW2lvICAweGIwMDAtMHhiMGZm
IGZsYWdzIDB4NDAxMDFdIChkPTEsIHA9MSkNCiAgWyAgIDIyLjA5NTQxOV0gZTgyMDogcmVz
ZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwMDA5ZjAwMC0weDAwMDlmZmZmXQ0KICBbICAgMjIu
MTE0MzE2XSBCbHVldG9vdGg6IENvcmUgdmVyIDIuMTYNCiAgWyAgIDIyLjEyNTAzNl0gTkVU
OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAzMQ0KICBbICAgMjIuMTM4MjgzXSBCbHVl
dG9vdGg6IEhDSSBkZXZpY2UgYW5kIGNvbm5lY3Rpb24gbWFuYWdlciBpbml0aWFsaXplZA0K
ICBbICAgMjIuMTU3NTQwXSBCbHVldG9vdGg6IEhDSSBzb2NrZXQgbGF5ZXIgaW5pdGlhbGl6
ZWQNCiAgWyAgIDIyLjE3MjMzMV0gQmx1ZXRvb3RoOiBMMkNBUCBzb2NrZXQgbGF5ZXIgaW5p
dGlhbGl6ZWQNCiAgWyAgIDIyLjE4NzY5OV0gQmx1ZXRvb3RoOiBTQ08gc29ja2V0IGxheWVy
IGluaXRpYWxpemVkDQogIFsgICAyMi4yMDI2MzFdIFN3aXRjaGluZyB0byBjbG9ja3NvdXJj
ZSB4ZW4NCiAgWyAgIDIyLjIxNDgzMl0gRlMtQ2FjaGU6IExvYWRlZA0KICBbICAgMjIuMjIz
NjMxXSBwbnA6IFBuUCBBQ1BJIGluaXQNCiAgWyAgIDIyLjIzMjY4Nl0gQUNQSTogYnVzIHR5
cGUgcG5wIHJlZ2lzdGVyZWQNCiAgWyAgIDIyLjI0NTI3NF0gc3lzdGVtIDAwOjAwOiBbbWVt
IDB4ZmVjMjAwMDAtMHhmZWMyMDBmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQogIFsgICAy
Mi4yNjU5OTFdIHN5c3RlbSAwMDowMDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURz
IFBOUDBjMDIgKGFjdGl2ZSkNCiAgWyAgIDIyLjI4Njk0M10gc3lzdGVtIDAwOjAxOiBbbWVt
IDB4ZjYwMDAwMDAtMHhmNjAwM2ZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjMw
NjUxM10gc3lzdGVtIDAwOjAxOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5Q
MGMwMiAoYWN0aXZlKQ0KICBbICAgMjIuMzI3OTQ0XSBwbnAgMDA6MDI6IFtkbWEgNF0NCiAg
WyAgIDIyLjMzNzExM10gcG5wIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJ
RHMgUE5QMDIwMCAoYWN0aXZlKQ0KICBbICAgMjIuMzU2NjE3XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSA4IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIwOjE0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04IC0+IDB4NTgg
LT4gSVJRIDggTW9kZTowIEFjdGl2ZTowKQ0KIFsgICAyMi4zOTk5MTBdIHBucCAwMDowMzog
UGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBiMDAgKGFjdGl2ZSkNCiAgWyAg
IDIyLjQxOTYzNl0gcG5wIDAwOjA0OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDgwMCAoYWN0aXZlKQ0KICBbICAgMjIuNDM5MDI5XSB4ZW46IHJlZ2lzdGVyaW5nIGdz
aSAxMyB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MDoxNF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTMgLT4gMHg4OCAt
PiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQ0KIFsgICAyMi40ODMxMTJdIHBucCAwMDowNTog
UGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDQgKGFjdGl2ZSkNCiAgWyAg
IDIyLjUwMjY0MF0geGVuOiByZWdpc3RlcmluZyBnc2kgNCB0cmlnZ2VyaW5nIDEgcG9sYXJp
dHkgMA0KICBbICAgMjIuNTE5MDkwXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjQNCiAgWyAg
IDIyLjUzMDAwMV0gcG5wIDAwOjA2OiBbZG1hIDAgZGlzYWJsZWRdDQogIFsgICAyMi41NDIx
MTBdIHBucCAwMDowNjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1MDEg
KGFjdGl2ZSkNCiAgWyAgIDIyLjU2MTc5MF0gc3lzdGVtIDAwOjA3OiBbaW8gIDB4MDYwMC0w
eDA2ZGZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi41Nzk0MzFdIHN5c3RlbSAwMDow
NzogW2lvICAweDBhZTAtMHgwYWVmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuNTk3
MzgwXSBzeXN0ZW0gMDA6MDc6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAw
YzAyIChhY3RpdmUpDQogIFsgICAyMi42MTgyNzhdIHBucCAwMDowODogUGx1ZyBhbmQgUGxh
eSBBQ1BJIGRldmljZSwgSURzIFBOUDAxMDMgKGFjdGl2ZSkNCiAgWyAgIDIyLjYzODAwNF0g
c3lzdGVtIDAwOjA5OiBbbWVtIDB4ZmVjMDAwMDAtMHhmZWMwMGZmZl0gY291bGQgbm90IGJl
IHJlc2VydmVkDQogIFsgICAyMi42NTg3MjVdIHN5c3RlbSAwMDowOTogW21lbSAweGZlZTAw
MDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi42Nzg3NDFdIHN5
c3RlbSAwMDowOTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFj
dGl2ZSkNCiAgWyAgIDIyLjY5OTY2NV0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MDRkMC0weDA0
ZDFdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi43MTcyMjRdIHN5c3RlbSAwMDowYTog
W2lvICAweDA0MGJdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi43MzMzNjJdIHN5c3Rl
bSAwMDowYTogW2lvICAweDA0ZDZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi43NDk0
NTldIHN5c3RlbSAwMDowYTogW2lvICAweDBjMDAtMHgwYzAxXSBoYXMgYmVlbiByZXNlcnZl
ZA0KICBbICAgMjIuNzY3NDA0XSBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYzE0XSBoYXMgYmVl
biByZXNlcnZlZA0KICBbICAgMjIuNzgzNTE2XSBzeXN0ZW0gMDA6MGE6IFtpbyAgMHgwYzUw
LTB4MGM1MV0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjgwMTQ2NV0gc3lzdGVtIDAw
OjBhOiBbaW8gIDB4MGM1Ml0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjgxNzU3NF0g
c3lzdGVtIDAwOjBhOiBbaW8gIDB4MGM2Y10gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIy
LjgzMzY5M10gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGM2Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQN
CiAgWyAgIDIyLjg0OTgxMl0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGNkMC0weDBjZDFdIGhh
cyBiZWVuIHJlc2VydmVkDQogIFsgICAyMi44Njc3NTBdIHN5c3RlbSAwMDowYTogW2lvICAw
eDBjZDItMHgwY2QzXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuODg1Njg5XSBzeXN0
ZW0gMDA6MGE6IFtpbyAgMHgwY2Q0LTB4MGNkNV0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAg
IDIyLjkwMzYyN10gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGNkNi0weDBjZDddIGhhcyBiZWVu
IHJlc2VydmVkDQogIFsgICAyMi45MjE1NjZdIHN5c3RlbSAwMDowYTogW2lvICAweDBjZDgt
MHgwY2RmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuOTM5NTA4XSBzeXN0ZW0gMDA6
MGE6IFtpbyAgMHgwODAwLTB4MDg5Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIyLjk1
NzQ0NV0gc3lzdGVtIDAwOjBhOiBbaW8gIDB4MGIwMC0weDBiMWZdIGhhcyBiZWVuIHJlc2Vy
dmVkDQogIFsgICAyMi45NzUzODNdIHN5c3RlbSAwMDowYTogW2lvICAweDBiMjAtMHgwYjNm
XSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjIuOTkzMzIyXSBzeXN0ZW0gMDA6MGE6IFtp
byAgMHgwOTAwLTB4MDkwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCiAgWyAgIDIzLjAxMTI2MV0g
c3lzdGVtIDAwOjBhOiBbaW8gIDB4MDkxMC0weDA5MWZdIGhhcyBiZWVuIHJlc2VydmVkDQog
IFsgICAyMy4wMjkyMDFdIHN5c3RlbSAwMDowYTogW2lvICAweGZlMDAtMHhmZWZlXSBoYXMg
YmVlbiByZXNlcnZlZA0KICBbICAgMjMuMDQ3MTM5XSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhm
ZmI4MDAwMC0weGZmYmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjMuMDY3MTYw
XSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhmZWMxMDAwMC0weGZlYzEwMDFmXSBoYXMgYmVlbiBy
ZXNlcnZlZA0KICBbICAgMjMuMDg3MTc3XSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhmZWQ4MDAw
MC0weGZlZDgwZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KICBbICAgMjMuMTA3MTk4XSBzeXN0
ZW0gMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3Rp
dmUpDQogIFsgICAyMy4xMjgxNTldIHN5c3RlbSAwMDowYjogW21lbSAweGUwMDAwMDAwLTB4
ZWZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQogIFsgICAyMy4xNDc3NjBdIHN5c3RlbSAw
MDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkN
CiAgWyAgIDIzLjE2ODY2OV0gc3lzdGVtIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5
ZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQogIFsgICAyMy4xODkzNTVdIHN5c3RlbSAw
MDowYzogW21lbSAweDAwMGMwMDAwLTB4MDAwY2ZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZl
ZA0KICBbICAgMjMuMjEwNDIyXSBzeXN0ZW0gMDA6MGM6IFttZW0gMHgwMDBlMDAwMC0weDAw
MGZmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNCiAgWyAgIDIzLjIzMTQ2OV0gc3lzdGVt
IDAwOjBjOiBbbWVtIDB4MDAxMDAwMDAtMHhhZmZmZmZmZl0gY291bGQgbm90IGJlIHJlc2Vy
dmVkDQogIFsgICAyMy4yNTI1MzVdIHN5c3RlbSAwMDowYzogW21lbSAweGZlYzAwMDAwLTB4
ZmZmZmZmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0KICBbICAgMjMuMjczNTg3XSBzeXN0
ZW0gMDA6MGM6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAxIChhY3Rp
dmUpDQogIFsgICAyMy4yOTQyNTldIHBucDogUG5QIEFDUEk6IGZvdW5kIDEzIGRldmljZXMN
CiAgWyAgIDIzLjMwNjg2NF0gQUNQSTogQUNQSSBidXMgdHlwZSBwbnAgdW5yZWdpc3RlcmVk
DQogIFsgICAyMy4zMzQwMDFdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAg
KDB4MHhmZmZmZmYpIC0gYWJvcnRpbmcuDQogIFsgICAyMy4zNTM2NjBdIHBjaSAwMDAwOjAw
OjAyLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwY10NCiAgWyAgIDIzLjM2ODYzNl0gcGNpIDAw
MDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhlMDAwLTB4ZWZmZl0NCiAgWyAg
IDIzLjM4NzA4Nl0gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhm
YTAwMDAwMC0weGZlOWZmZmZmXQ0KICBbICAgMjMuNDA3NjMzXSBwY2kgMDAwMDowMDowMi4w
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJl
Zl0NCiAgWyAgIDIzLjQzMTAyM10gcGNpIDAwMDA6MGE6MDAuMDogUENJIGJyaWRnZSB0byBb
YnVzIDBiXQ0KICBbICAgMjMuNDQ2MTEwXSBwY2kgMDAwMDowYTowMC4wOiAgIGJyaWRnZSB3
aW5kb3cgW21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQogIFsgICAyMy40NjY2NDldIHBj
aSAwMDAwOjAwOjAzLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwYS0wYl0NCiAgWyAgIDIzLjQ4
MjQ5Ml0gcGNpIDAwMDA6MDA6MDMuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWYwMDAw
MC0weGY5ZmZmZmZmXQ0KICBbICAgMjMuNTAzMDMzXSBwY2kgMDAwMDowMDowNS4wOiBQQ0kg
YnJpZGdlIHRvIFtidXMgMDldDQogIFsgICAyMy41MTgxMDZdIHBjaSAwMDAwOjAwOjA1LjA6
ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZDAwMC0weGRmZmZdDQogIFsgICAyMy41MzY1Njhd
IHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjllMDAwMDAtMHhm
OWVmZmZmZl0NCiAgWyAgIDIzLjU1NzEwNF0gcGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ug
d2luZG93IFttZW0gMHhjZmYwMDAwMC0weGNmZmZmZmZmIDY0Yml0IHByZWZdDQogIFsgICAy
My41ODA1NDJdIHBjaSAwMDAwOjAwOjA2LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwOF0NCiAg
WyAgIDIzLjU5NTYxNl0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFtpbyAg
MHhjMDAwLTB4Y2ZmZl0NCiAgWyAgIDIzLjYxNDA3NF0gcGNpIDAwMDA6MDA6MDYuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmOWQwMDAwMC0weGY5ZGZmZmZmXQ0KICBbICAgMjMuNjM0
NjE1XSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGNmZTAwMDAw
LTB4Y2ZlZmZmZmYgNjRiaXQgcHJlZl0NCiAgWyAgIDIzLjY1ODAxM10gcGNpIDAwMDA6MDA6
MDkuMDogUENJIGJyaWRnZSB0byBbYnVzIDA3XQ0KICBbICAgMjMuNjczMDkwXSBwY2kgMDAw
MDowMDowOS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YzAwMDAwLTB4ZjljZmZmZmZd
DQogIFsgICAyMy42OTM2MzJdIHBjaSAwMDAwOjAwOjBhLjA6IFBDSSBicmlkZ2UgdG8gW2J1
cyAwNl0NCiAgWyAgIDIzLjcwODcwOV0gcGNpIDAwMDA6MDA6MGEuMDogICBicmlkZ2Ugd2lu
ZG93IFttZW0gMHhmOWEwMDAwMC0weGY5YmZmZmZmXQ0KICBbICAgMjMuNzI5MjUzXSBwY2kg
MDAwMDowMDowYi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVdDQogIFsgICAyMy43NDQzMjdd
IHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YjAwMC0weGJmZmZd
DQogIFsgICAyMy43NjI3ODVdIHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIDB4Zjk5MDAwMDAtMHhmOTlmZmZmZl0NCiAgWyAgIDIzLjc4MzMyOV0gcGNpIDAwMDA6
MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0
Yml0IHByZWZdDQogIFsgICAyMy44MDY3MzBdIHBjaSAwMDAwOjAwOjBkLjA6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwNF0NCiAgWyAgIDIzLjgyMTgwMl0gcGNpIDAwMDA6MDA6MGQuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmOTgwMDAwMC0weGY5OGZmZmZmXQ0KICBbICAgMjMuODQy
MzQ0XSBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNdDQogIFsgICAy
My44NTc0MjFdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4YTAw
MC0weGFmZmZdDQogIFsgICAyMy44NzU4OTVdIHBjaSAwMDAwOjAwOjE1LjA6IFBDSSBicmlk
Z2UgdG8gW2J1cyAwMl0NCiAgWyAgIDIzLjg5MTAxN10geGVuOiByZWdpc3RlcmluZyBnc2kg
NTIgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDIzLjkwNzg3MV0geGVuOiAtLT4g
cGlycT01MiAtPiBpcnE9NTIgKGdzaT01MikNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6
MTVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI4IC0+IDB4YjggLT4g
SVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjMuOTQ4NDU3XSB4ZW46IHJlZ2lzdGVy
aW5nIGdzaSA1MiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMjMuOTY1MzEzXSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjUyDQogIFsgICAyMy45NzY1MzFdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDUyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyMy45OTMzODld
IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NTINCiAgWyAgIDI0LjAwNDYwMF0geGVuOiByZWdp
c3RlcmluZyBnc2kgNTMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDI0LjAyMTQ3
Nl0geGVuOiAtLT4gcGlycT01MyAtPiBpcnE9NTMgKGdzaT01MykNCiAgKFhFTikgWzIwMTMt
MDItMjcgMTE6MjA6MTZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5
IC0+IDB4YzAgLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjQuMDYyMDY2XSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSA1MyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAg
MjQuMDc4OTIzXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjUzDQogIFsgICAyNC4wOTAxMzVd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDU0IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsg
ICAyNC4xMDcwMTJdIHhlbjogLS0+IHBpcnE9NTQgLT4gaXJxPTU0IChnc2k9NTQpDQogIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIwOjE2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0zMCAtPiAweGM4IC0+IElSUSA1NCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI0
LjE0NzU5N10geGVuOiByZWdpc3RlcmluZyBnc2kgNTQgdHJpZ2dlcmluZyAwIHBvbGFyaXR5
IDENCiAgWyAgIDI0LjE2NDQ1N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo1NA0KICBbICAg
MjQuMTc1NjcwXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA1NCB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQ0KICBbICAgMjQuMTkyNTM1XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjU0DQogIFsg
ICAyNC4yMDM3NTldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQogIFsgICAyNC4yMjA2MjFdIHhlbjogLS0+IHBpcnE9MTYgLT4gaXJxPTE2IChn
c2k9MTYpDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjE2XSBJT0FQSUNbMF06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNi0xNiAtPiAweGQwIC0+IElSUSAxNiBNb2RlOjEgQWN0aXZl
OjEpDQogWyAgIDI0LjI2MTE4Ml0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA0IFtpbyAg
MHgwMDAwLTB4MGNmN10NCiAgWyAgIDI0LjI3ODA3M10gcGNpX2J1cyAwMDAwOjAwOiByZXNv
dXJjZSA1IFtpbyAgMHgwZDAwLTB4ZmZmZl0NCiAgWyAgIDI0LjI5NDk3NF0gcGNpX2J1cyAw
MDAwOjAwOiByZXNvdXJjZSA2IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KICBbICAg
MjQuMzEzOTQ4XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDcgW21lbSAweDAwMGQwMDAw
LTB4MDAwZGZmZmZdDQogIFsgICAyNC4zMzI5MzBdIHBjaV9idXMgMDAwMDowMDogcmVzb3Vy
Y2UgOCBbbWVtIDB4YjAwMDAwMDAtMHhkZmZmZmZmZl0NCiAgWyAgIDI0LjM1MTkwOV0gcGNp
X2J1cyAwMDAwOjAwOiByZXNvdXJjZSA5IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0K
ICBbICAgMjQuMzcwODg1XSBwY2lfYnVzIDAwMDA6MGM6IHJlc291cmNlIDAgW2lvICAweGUw
MDAtMHhlZmZmXQ0KICBbICAgMjQuMzg3Nzg2XSBwY2lfYnVzIDAwMDA6MGM6IHJlc291cmNl
IDEgW21lbSAweGZhMDAwMDAwLTB4ZmU5ZmZmZmZdDQogIFsgICAyNC40MDY3NjJdIHBjaV9i
dXMgMDAwMDowYzogcmVzb3VyY2UgMiBbbWVtIDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiA2NGJp
dCBwcmVmXQ0KICBbICAgMjQuNDI4NjAxXSBwY2lfYnVzIDAwMDA6MGE6IHJlc291cmNlIDEg
W21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQogIFsgICAyNC40NDc1NzldIHBjaV9idXMg
MDAwMDowYjogcmVzb3VyY2UgMSBbbWVtIDB4ZjlmMDAwMDAtMHhmOWZmZmZmZl0NCiAgWyAg
IDI0LjQ2NjU1OV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAwIFtpbyAgMHhkMDAwLTB4
ZGZmZl0NCiAgWyAgIDI0LjQ4MzQ2MV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAxIFtt
ZW0gMHhmOWUwMDAwMC0weGY5ZWZmZmZmXQ0KICBbICAgMjQuNTAyNDM5XSBwY2lfYnVzIDAw
MDA6MDk6IHJlc291cmNlIDIgW21lbSAweGNmZjAwMDAwLTB4Y2ZmZmZmZmYgNjRiaXQgcHJl
Zl0NCiAgWyAgIDI0LjUyNDI3OF0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAwIFtpbyAg
MHhjMDAwLTB4Y2ZmZl0NCiAgWyAgIDI0LjU0MTE3NF0gcGNpX2J1cyAwMDAwOjA4OiByZXNv
dXJjZSAxIFttZW0gMHhmOWQwMDAwMC0weGY5ZGZmZmZmXQ0KICBbICAgMjQuNTYwMTU2XSBw
Y2lfYnVzIDAwMDA6MDg6IHJlc291cmNlIDIgW21lbSAweGNmZTAwMDAwLTB4Y2ZlZmZmZmYg
NjRiaXQgcHJlZl0NCiAgWyAgIDI0LjU4MjAyNF0gcGNpX2J1cyAwMDAwOjA3OiByZXNvdXJj
ZSAxIFttZW0gMHhmOWMwMDAwMC0weGY5Y2ZmZmZmXQ0KICBbICAgMjQuNjAxMDAyXSBwY2lf
YnVzIDAwMDA6MDY6IHJlc291cmNlIDEgW21lbSAweGY5YTAwMDAwLTB4ZjliZmZmZmZdDQog
IFsgICAyNC42MTk5ODJdIHBjaV9idXMgMDAwMDowNTogcmVzb3VyY2UgMCBbaW8gIDB4YjAw
MC0weGJmZmZdDQogIFsgICAyNC42MzY4ODNdIHBjaV9idXMgMDAwMDowNTogcmVzb3VyY2Ug
MSBbbWVtIDB4Zjk5MDAwMDAtMHhmOTlmZmZmZl0NCiAgWyAgIDI0LjY1NTg2NF0gcGNpX2J1
cyAwMDAwOjA1OiByZXNvdXJjZSAyIFttZW0gMHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0
IHByZWZdDQogIFsgICAyNC42Nzc2OTddIHBjaV9idXMgMDAwMDowNDogcmVzb3VyY2UgMSBb
bWVtIDB4Zjk4MDAwMDAtMHhmOThmZmZmZl0NCiAgWyAgIDI0LjY5NjY4MF0gcGNpX2J1cyAw
MDAwOjAzOiByZXNvdXJjZSAwIFtpbyAgMHhhMDAwLTB4YWZmZl0NCiAgWyAgIDI0LjcxMzU3
Nl0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MGNmN10NCiAg
WyAgIDI0LjczMDQ3Nl0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA1IFtpbyAgMHgwZDAw
LTB4ZmZmZl0NCiAgWyAgIDI0Ljc0NzM3M10gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA2
IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KICBbICAgMjQuNzY2MzU0XSBwY2lfYnVz
IDAwMDA6MDM6IHJlc291cmNlIDcgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdDQogIFsg
ICAyNC43ODUzMzJdIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2UgOCBbbWVtIDB4YjAwMDAw
MDAtMHhkZmZmZmZmZl0NCiAgWyAgIDI0LjgwNDMxMl0gcGNpX2J1cyAwMDAwOjAzOiByZXNv
dXJjZSA5IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0KICBbICAgMjQuODIzMzQwXSBO
RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINCiAgWyAgIDI0LjgzNjkzOF0gVENQ
IGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDUsIDEzMTA3
MiBieXRlcykNCiAgWyAgIDI0Ljg1ODI2Nl0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiA4MTkyIChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQ0KICBbICAgMjQuODc4MzAxXSBUQ1A6
IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDgxOTIgYmluZCA4MTkyKQ0K
ICBbICAgMjQuODk3MTgwXSBUQ1A6IHJlbm8gcmVnaXN0ZXJlZA0KICBbICAgMjQuOTA3MDI1
XSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiA0LCA4MTkyMCBieXRlcykN
CiAgWyAgIDI0LjkyNTAyM10gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9y
ZGVyOiA0LCA4MTkyMCBieXRlcykNCiAgWyAgIDI0Ljk0NDM1OF0gTkVUOiBSZWdpc3RlcmVk
IHByb3RvY29sIGZhbWlseSAxDQogIFsgICAyNC45NTc0ODFdIHBjaSAwMDAwOjAwOjExLjA6
IGNhbGxpbmcgcXVpcmtfbXNpX2ludHhfZGlzYWJsZV9hdGlfYnVnKzB4MC8weDUwDQogIFsg
ICAyNC45NzkwMzddIHBjaSAwMDAwOjAwOjEyLjA6IGNhbGxpbmcgcXVpcmtfdXNiX2Vhcmx5
X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNC45OTkwOTBdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyNS4wMTU5NDddIHhlbjog
LS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIwOjE3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweGQ4
IC0+IElSUSAxOCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI1Ljg3MTUzNl0gcGNpIDAwMDA6
MDA6MTIuMjogY2FsbGluZyBxdWlya191c2JfZWFybHlfaGFuZG9mZisweDAvMHg3MTANCiAg
WyAgIDI1Ljg5MTExM10geGVuOiByZWdpc3RlcmluZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENCiAgWyAgIDI1LjkwNzk4Ml0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcg
KGdzaT0xNykNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MTddIElPQVBJQ1swXTogU2V0
IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4MjEgLT4gSVJRIDE3IE1vZGU6MSBBY3Rp
dmU6MSkNCiBbICAgMjUuOTQ4NTkwXSBwY2kgMDAwMDowMDoxMy4wOiBjYWxsaW5nIHF1aXJr
X3VzYl9lYXJseV9oYW5kb2ZmKzB4MC8weDcxMA0KICBbICAgMjUuOTY4NTc4XSB4ZW46IHJl
Z2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMjUuOTg1
NDQ4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQogIFsgICAyNi4wNzE1NDZdIHBjaSAw
MDAwOjAwOjEzLjI6IGNhbGxpbmcgcXVpcmtfdXNiX2Vhcmx5X2hhbmRvZmYrMHgwLzB4NzEw
DQogIFsgICAyNi4wOTExMzFdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQogIFsgICAyNi4xMDc5ODhdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTcNCiAgWyAgIDI2LjExOTIzMV0gcGNpIDAwMDA6MDA6MTQuNTogY2FsbGluZyBxdWlya191
c2JfZWFybHlfaGFuZG9mZisweDAvMHg3MTANCiAgWyAgIDI2LjEzOTIyMF0geGVuOiByZWdp
c3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDI2LjE1NjA4
N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KICBbICAgMjYuMjQxNTU4XSBwY2kgMDAw
MDowMDoxNi4wOiBjYWxsaW5nIHF1aXJrX3VzYl9lYXJseV9oYW5kb2ZmKzB4MC8weDcxMA0K
ICBbICAgMjYuMjYxMTMyXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAg
cG9sYXJpdHkgMQ0KICBbICAgMjYuMjc3OTkyXSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4
DQogIFsgICAyNi4zNjQ4OThdIHBjaSAwMDAwOjAwOjE2LjI6IGNhbGxpbmcgcXVpcmtfdXNi
X2Vhcmx5X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNi4zODQ0NzBdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDE3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyNi40MDEzMjld
IEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcNCiAgWyAgIDI2LjQxMjU2MV0gcGNpIDAwMDA6
MDA6MTguMDogY2FsbGluZyBxdWlya19hbWRfbmJfbm9kZSsweDAvMHg4MA0KICBbICAgMjYu
NDMwNzEzXSBwY2kgMDAwMDowMDoxOC4xOiBjYWxsaW5nIHF1aXJrX2FtZF9uYl9ub2RlKzB4
MC8weDgwDQogIFsgICAyNi40NDg5MTFdIHBjaSAwMDAwOjAwOjE4LjI6IGNhbGxpbmcgcXVp
cmtfYW1kX25iX25vZGUrMHgwLzB4ODANCiAgWyAgIDI2LjQ2NzExMF0gcGNpIDAwMDA6MDA6
MTguMzogY2FsbGluZyBxdWlya19hbWRfbmJfbm9kZSsweDAvMHg4MA0KICBbICAgMjYuNDg1
MzA4XSBwY2kgMDAwMDowMDoxOC40OiBjYWxsaW5nIHF1aXJrX2FtZF9uYl9ub2RlKzB4MC8w
eDgwDQogIFsgICAyNi41MDM1MDhdIHBjaSAwMDAwOjBjOjAwLjA6IGNhbGxpbmcgbnZfbXNp
X2h0X2NhcF9xdWlya19sZWFmKzB4MC8weDEwDQogIFsgICAyNi41MjM1MzhdIHBjaSAwMDAw
OjBjOjAwLjA6IGNhbGxpbmcgcGNpX2ZpeHVwX3ZpZGVvKzB4MC8weGQwDQogIFsgICAyNi41
NDEyMDZdIHBjaSAwMDAwOjBjOjAwLjA6IEJvb3QgdmlkZW8gZGV2aWNlDQogIFsgICAyNi41
NTQ5ODNdIHBjaSAwMDAwOjBhOjAwLjA6IGNhbGxpbmcgcXVpcmtfeGlvMjAwMGErMHgwLzB4
YTANCiAgWyAgIDI2LjU3MjM5N10gcGNpIDAwMDA6MGE6MDAuMDogVEkgWElPMjAwMGEgcXVp
cmsgZGV0ZWN0ZWQ7IHNlY29uZGFyeSBidXMgZmFzdCBiYWNrLXRvLWJhY2sgdHJhbnNmZXJz
IGRpc2FibGVkDQogIFsgICAyNi42MDIwNDZdIHBjaSAwMDAwOjBiOjAxLjA6IGNhbGxpbmcg
cXVpcmtfdXNiX2Vhcmx5X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNi42MjIwNzVdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDI5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAy
Ni42Mzg5NjZdIHhlbjogLS0+IHBpcnE9MjkgLT4gaXJxPTI5IChnc2k9MjkpDQogIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIwOjE4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy01IC0+IDB4MjkgLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjYuNjc5
MjkyXSBwY2kgMDAwMDowYjowMS4xOiBjYWxsaW5nIHF1aXJrX3VzYl9lYXJseV9oYW5kb2Zm
KzB4MC8weDcxMA0KICBbICAgMjYuNjk5MjkwXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMCB0
cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgMjYuNzE2MTc3XSB4ZW46IC0tPiBwaXJx
PTMwIC0+IGlycT0zMCAoZ3NpPTMwKQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMDoxOF0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDMxIC0+IElSUSAz
MCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI2Ljc1NjUxMF0gcGNpIDAwMDA6MGI6MDEuMjog
Y2FsbGluZyBxdWlya191c2JfZWFybHlfaGFuZG9mZisweDAvMHg3MTANCiAgWyAgIDI2Ljc3
NjUwNV0geGVuOiByZWdpc3RlcmluZyBnc2kgMzEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
CiAgWyAgIDI2Ljc5MzM5NV0geGVuOiAtLT4gcGlycT0zMSAtPiBpcnE9MzEgKGdzaT0zMSkN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MThdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTcgLT4gMHgzOSAtPiBJUlEgMzEgTW9kZToxIEFjdGl2ZToxKQ0KIFsg
ICAyNi44MzM3NjhdIHBjaSAwMDAwOjA3OjAwLjA6IGNhbGxpbmcgcXVpcmtfdXNiX2Vhcmx5
X2hhbmRvZmYrMHgwLzB4NzEwDQogIFsgICAyNi44NTM3NTRdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDQ4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICAyNi44NzA2NDBdIHhlbjog
LS0+IHBpcnE9NDggLT4gaXJxPTQ4IChnc2k9NDgpDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIwOjE4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yNCAtPiAweDQx
IC0+IElSUSA0OCBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDI2LjkxMTIzN10gcGNpIDAwMDA6
MDU6MDAuMDogY2FsbGluZyBwY2lfZml4dXBfdmlkZW8rMHgwLzB4ZDANCiAgWyAgIDI2Ljky
ODg3NV0gcGNpIDAwMDA6MDQ6MDAuMDogY2FsbGluZyBxdWlya191c2JfZWFybHlfaGFuZG9m
ZisweDAvMHg3MTANCiAgWyAgIDI2Ljk0ODkwOV0geGVuOiByZWdpc3RlcmluZyBnc2kgNDAg
dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDI2Ljk2NTc5OV0geGVuOiAtLT4gcGly
cT00MCAtPiBpcnE9NDAgKGdzaT00MCkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjA6MThd
IElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+IDB4NDkgLT4gSVJR
IDQwIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgMjcuMDA2Mzg5XSBQQ0k6IENMUyA2NCBieXRl
cywgZGVmYXVsdCA2NA0KICBbICAgMjcuMDE4Njk2XSBUcnlpbmcgdG8gdW5wYWNrIHJvb3Rm
cyBpbWFnZSBhcyBpbml0cmFtZnMuLi4NCiAgWyAgIDI3LjA1NTg4NF0gRnJlZWluZyBpbml0
cmQgbWVtb3J5OiAxMjk3NmsgZnJlZWQNCiAgWyAgIDI3LjA3OTcxMV0gRE1BLUFQSTogcHJl
YWxsb2NhdGVkIDY1NTM2IGRlYnVnIGVudHJpZXMNCiAgWyAgIDI3LjA5NDY5Ml0gRE1BLUFQ
STogZGVidWdnaW5nIGVuYWJsZWQgYnkga2VybmVsIGNvbmZpZw0KICBbICAgMjcuMTEzNDQ5
XSBTY2FubmluZyBmb3IgbG93IG1lbW9yeSBjb3JydXB0aW9uIGV2ZXJ5IDYwIHNlY29uZHMN
CiAgWyAgIDI3LjEzMjk5OV0gc2hhMV9zc3NlMzogTmVpdGhlciBBVlggbm9yIFNTU0UzIGlz
IGF2YWlsYWJsZS91c2FibGUuDQogIFsgICAyNy4xNTIzMzBdIGF1ZGl0OiBpbml0aWFsaXpp
bmcgbmV0bGluayBzb2NrZXQgKGRpc2FibGVkKQ0KICBbICAgMjcuMTY4MjYwXSB0eXBlPTIw
MDAgYXVkaXQoMTM2MTk2NDAxMy42OTE6MSk6IGluaXRpYWxpemVkDQogIFsgICAyNy4xODYy
MzRdIGJvdW5jZSBwb29sIHNpemU6IDY0IHBhZ2VzDQogIFsgICAyNy4xOTcxOTddIEh1Z2VU
TEIgcmVnaXN0ZXJlZCAyIE1CIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzDQog
IFsgICAyNy4yMjY1NzJdIFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjINCiAgWyAgIDI3
LjIzODQxM10gRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyIDAs
IDQwOTYgYnl0ZXMpDQogIFsgICAyNy4yNjAzMTVdIE5URlMgZHJpdmVyIDIuMS4zMCBbRmxh
Z3M6IFIvV10uDQogIFsgICAyNy4yNzM3MDFdIGZ1c2UgaW5pdCAoQVBJIHZlcnNpb24gNy4y
MSkNCiAgWyAgIDI3LjI4NjkzN10gQnRyZnMgbG9hZGVkDQogIFsgICAyNy4yOTU1MzRdIEdG
UzIgaW5zdGFsbGVkDQogIFsgICAyNy4zMDQxNDVdIGNlcGg6IGxvYWRlZCAobWRzIHByb3Rv
IDMyKQ0KICBbICAgMjcuMzE1MzgyXSBtc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDE4MjUNCiAg
WyAgIDI3LjMyOTMzNF0gQmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2
ZXJzaW9uIDAuNCBsb2FkZWQgKG1ham9yIDI1MCkNCiAgWyAgIDI3LjM1MTI0Ml0gaW8gc2No
ZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZA0KICBbICAgMjcuMzYzMTkyXSBpbyBzY2hlZHVsZXIg
ZGVhZGxpbmUgcmVnaXN0ZXJlZA0KICBbICAgMjcuMzc2OTM5XSBpbyBzY2hlZHVsZXIgY2Zx
IHJlZ2lzdGVyZWQgKGRlZmF1bHQpDQogIFsgICAyNy4zOTE4NTZdIGNyYzMyOiBDUkNfTEVf
QklUUyA9IDY0LCBDUkNfQkUgQklUUyA9IDY0DQogIFsgICAyNy40MDY3NTRdIGNyYzMyOiBz
ZWxmIHRlc3RzIHBhc3NlZCwgcHJvY2Vzc2VkIDIyNTk0NCBieXRlcyBpbiA5ODQ5NCBuc2Vj
DQogIFsgICAyNy40Mjc2ODhdIGNyYzMyYzogQ1JDX0xFX0JJVFMgPSA2NA0KICBbICAgMjcu
NDM4NDcxXSBjcmMzMmM6IHNlbGYgdGVzdHMgcGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5
dGVzIGluIDU2OTM0IG5zZWMNCiAgWyAgIDI3LjQ2NzI1N10gcGNpX2hvdHBsdWc6IFBDSSBI
b3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUNCiAgWyAgIDI3LjQ4NDU3N10gcGNpZWhw
OiBQQ0kgRXhwcmVzcyBIb3QgUGx1ZyBDb250cm9sbGVyIERyaXZlciB2ZXJzaW9uOiAwLjQN
CiAgWyAgIDI3LjUwNDEyMl0gY3BjaWhwX3p0NTU1MDogWlQ1NTUwIENvbXBhY3RQQ0kgSG90
IFBsdWcgRHJpdmVyIHZlcnNpb246IDAuMg0KICBbICAgMjcuNTI0OTY4XSBjcGNpaHBfZ2Vu
ZXJpYzogR2VuZXJpYyBwb3J0IEkvTyBDb21wYWN0UENJIEhvdCBQbHVnIERyaXZlciB2ZXJz
aW9uOiAwLjENCiAgWyAgIDI3LjU0ODA2MF0gY3BjaWhwX2dlbmVyaWM6IG5vdCBjb25maWd1
cmVkLCBkaXNhYmxpbmcuDQogIFsgICAyNy41NjQxMjFdIHNocGNocDogU3RhbmRhcmQgSG90
IFBsdWcgUENJIENvbnRyb2xsZXIgRHJpdmVyIHZlcnNpb246IDAuNA0KICBbICAgMjcuNTgz
OTUwXSBhY3BpcGhwOiBBQ1BJIEhvdCBQbHVnIFBDSSBDb250cm9sbGVyIERyaXZlciB2ZXJz
aW9uOiAwLjUNCiAgWyAgIDI3LjYyNTc5OV0gYWNwaXBocF9pYm06IGlibV9hY3BpcGhwX2lu
aXQ6IGFjcGlfd2Fsa19uYW1lc3BhY2UgZmFpbGVkDQogIFsgICAyNy42NDUzNTVdIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdWRsZmINCiAgWyAgIDI3LjY2
MTcxNl0gdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01MTIwLCBw
YWdlcz0wDQogIFsgICAyNy42ODAyNDBdIHZlc2FmYjogc2Nyb2xsaW5nOiByZWRyYXcNCiAg
WyAgIDI3LjY5MTQxOV0gdmVzYWZiOiBUcnVlY29sb3I6IHNpemU9ODo4Ojg6OCwgc2hpZnQ9
MjQ6MTY6ODowDQogIFsgICAyNy43MTAyNDBdIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhm
YjAwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZmM5MDAxMDMwMDAwMCwgdXNpbmcgMTAyNDBrLCB0
b3RhbCAxNDMzNmsNCiAgWyAgIDI3Ljc1OTk5NV0gQ29uc29sZTogc3dpdGNoaW5nIHRvIGNv
bG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDE2MHg2NA0KICBbICAgMjcuNzk4NzcxXSBmYjA6
IFZFU0EgVkdBIGZyYW1lIGJ1ZmZlciBkZXZpY2UNCiAgWyAgIDI3LjgxMjY0N10gaW5wdXQ6
IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTWUJVUzowMC9QTlAw
QzBDOjAwL2lucHV0L2lucHV0MA0KICBbICAgMjcuODM3NjQwXSBBQ1BJOiBQb3dlciBCdXR0
b24gW1BXUkJdDQogIFsgICAyNy44NDg5NjZdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2Rl
dmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQxDQogIFsgICAyNy44
NzExMzldIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0NCiAgWyAgIDI3Ljg4ODMxN10gV2Fy
bmluZzogUHJvY2Vzc29yIFBsYXRmb3JtIExpbWl0IG5vdCBzdXBwb3J0ZWQuDQogIFsgICAy
Ny45MDYwNjFdIEV2ZW50LWNoYW5uZWwgZGV2aWNlIGluc3RhbGxlZC4NCiAgWyAgIDI3Ljkx
OTE4N10geGVuLXBjaWJhY2s6IGJhY2tlbmQgaXMgdnBjaQ0KICBbICAgMjcuOTMyNjg4XSBT
ZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVk
DQogIFsgICAyNy45NTMxNDZdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBp
biBfQ1JTDQogIFsgICAyNy45Njg4MzFdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEw
Mw0KICBbICAgMjcuOTgzNDYxXSBIYW5nY2hlY2s6IHN0YXJ0aW5nIGhhbmdjaGVjayB0aW1l
ciAwLjkuMSAodGljayBpcyAxODAgc2Vjb25kcywgbWFyZ2luIGlzIDYwIHNlY29uZHMpLg0K
ICBbICAgMjguMDEwMjM4XSBIYW5nY2hlY2s6IFVzaW5nIGdldHJhd21vbm90b25pYygpLg0K
ICBbICAgMjguMDI0MzQyXSBbZHJtXSBJbml0aWFsaXplZCBkcm0gMS4xLjAgMjAwNjA4MTAN
CiAgWyAgIDI4LjAzODU0Ml0gW2RybV0gcmFkZW9uIGtlcm5lbCBtb2Rlc2V0dGluZyBlbmFi
bGVkLg0KICBbICAgMjguMDUzNDI3XSBjaGVja2luZyBnZW5lcmljIChmYjAwMDAwMCBlMDAw
MDApIHZzIGh3IChiMDAwMDAwMCAxMDAwMDAwMCkNCiAgWyAgIDI4LjA3MzYwNl0gcmFkZW9u
IDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDMpDQogIFsgICAy
OC4wOTE1NzVdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMyIHRyaWdnZXJpbmcgMCBwb2xhcml0
eSAxDQogIFsgICAyOC4xMDg0MzldIHhlbjogLS0+IHBpcnE9MzIgLT4gaXJxPTMyIChnc2k9
MzIpDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIwOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNy04IC0+IDB4OTkgLT4gSVJRIDMyIE1vZGU6MSBBY3RpdmU6MSkN
CiBbICAgMjguMTQ5NDg4XSBbZHJtXSBpbml0aWFsaXppbmcga2VybmVsIG1vZGVzZXR0aW5n
IChUVVJLUyAweDEwMDI6MHg2NzU5IDB4MTc0QjoweEUxOTMpLg0KICBbICAgMjguMTczMTc0
XSBbZHJtXSByZWdpc3RlciBtbWlvIGJhc2U6IDB4Rjk5QzAwMDANCiAgWyAgIDI4LjE4NzE3
NF0gW2RybV0gcmVnaXN0ZXIgbW1pbyBzaXplOiAxMzEwNzINCiAgWyAgIDI4LjMyMDE1N10g
QVRPTSBCSU9TOiBFTElYSVINCiAgWyAgIDI4LjMyODkzMl0gW2RybV0gR1BVIG5vdCBwb3N0
ZWQuIHBvc3Rpbmcgbm93Li4uDQogIFsgICAyOC4zNDU3ODZdIHJhZGVvbiAwMDAwOjA1OjAw
LjA6IFZSQU06IDEwMjRNIDB4MDAwMDAwMDAwMDAwMDAwMCAtIDB4MDAwMDAwMDAzRkZGRkZG
RiAoMTAyNE0gdXNlZCkNCiAgWyAgIDI4LjM3MjM1Ml0gcmFkZW9uIDAwMDA6MDU6MDAuMDog
R1RUOiA1MTJNIDB4MDAwMDAwMDA0MDAwMDAwMCAtIDB4MDAwMDAwMDA1RkZGRkZGRg0KICBb
ICAgMjguMzk1MjAyXSBbZHJtXSBEZXRlY3RlZCBWUkFNIFJBTT0xMDI0TSwgQkFSPTI1Nk0N
CiAgWyAgIDI4LjQxMDAxN10gW2RybV0gUkFNIHdpZHRoIDEyOGJpdHMgRERSDQogIFsgICAy
OC40MjE5MjRdIFtUVE1dIFpvbmUgIGtlcm5lbDogQXZhaWxhYmxlIGdyYXBoaWNzIG1lbW9y
eTogNDY3NDA2IGtpQg0KICBbICAgMjguNDQxMjE4XSBbVFRNXSBJbml0aWFsaXppbmcgcG9v
bCBhbGxvY2F0b3INCiAgWyAgIDI4LjQ1NDQ4Nl0gW1RUTV0gSW5pdGlhbGl6aW5nIERNQSBw
b29sIGFsbG9jYXRvcg0KICBbICAgMjguNDY5MDExXSBbZHJtXSByYWRlb246IDEwMjRNIG9m
IFZSQU0gbWVtb3J5IHJlYWR5DQogIFsgICAyOC40ODM4NTRdIFtkcm1dIHJhZGVvbjogNTEy
TSBvZiBHVFQgbWVtb3J5IHJlYWR5Lg0KICBbICAgMjguNDk4NzIxXSBbZHJtXSBTdXBwb3J0
cyB2YmxhbmsgdGltZXN0YW1wIGNhY2hpbmcgUmV2IDEgKDEwLjEwLjIwMTApLg0KICBbICAg
MjguNTI1MDA5XSBbZHJtXSBEcml2ZXIgc3VwcG9ydHMgcHJlY2lzZSB2YmxhbmsgdGltZXN0
YW1wIHF1ZXJ5Lg0KICBbICAgMjguNTQ5ODE1XSByYWRlb24gMDAwMDowNTowMC4wOiByYWRl
b246IHVzaW5nIE1TSS4NCiAgWyAgIDI4LjU3MDk1NF0gW2RybV0gcmFkZW9uOiBpcnEgaW5p
dGlhbGl6ZWQuDQogIFsgICAyOC41ODk3MzVdIFtkcm1dIEdBUlQ6IG51bSBjcHUgcGFnZXMg
MTMxMDcyLCBudW0gZ3B1IHBhZ2VzIDEzMTA3Mg0KICBbICAgMjguNjE1OTQ1XSBbZHJtXSBw
cm9iaW5nIGdlbiAyIGNhcHMgZm9yIGRldmljZSAxMDAyOjVhMWYgPSAzMWNkMDIvMA0KICBb
ICAgMjguNjQxNTcxXSBbZHJtXSBlbmFibGluZyBQQ0lFIGdlbiAyIGxpbmsgc3BlZWRzLCBk
aXNhYmxlIHdpdGggcmFkZW9uLnBjaWVfZ2VuMj0wDQogIFsgICAyOC42NzExMzNdIFtkcm1d
IExvYWRpbmcgVFVSS1MgTWljcm9jb2RlDQogIFsgICA4OC44MzU0NDddIG5pX2NwOiBGYWls
ZWQgdG8gbG9hZCBmaXJtd2FyZSAicmFkZW9uL1RVUktTX3BmcC5iaW4iDQogIFsgICA4OC44
NjAzMTVdIFtkcm06ZXZlcmdyZWVuX3N0YXJ0dXBdICpFUlJPUiogRmFpbGVkIHRvIGxvYWQg
ZmlybXdhcmUhDQogIFsgICA4OC44ODU5NzZdIHJhZGVvbiAwMDAwOjA1OjAwLjA6IGRpc2Fi
bGluZyBHUFUgYWNjZWxlcmF0aW9uDQogIFsgICA4OC45MTA1MzZdIHJhZGVvbiAwMDAwOjA1
OjAwLjA6IGZmZmY4ODAwMDJmZmQ0MDAgdW5waW4gbm90IG5lY2Vzc2FyeQ0KICBbICAgODgu
OTM2NDEzXSByYWRlb24gMDAwMDowNTowMC4wOiBmZmZmODgwMDAyZmZkNDAwIHVucGluIG5v
dCBuZWNlc3NhcnkNCiAgWyAgIDg4Ljk2MjY2NV0gW2RybTpldmVyZ3JlZW5faW5pdF0gKkVS
Uk9SKiByYWRlb246IE1DIHVjb2RlIHJlcXVpcmVkIGZvciBOSSsuDQogIFsgICA4OC45ODk5
OTVdIHJhZGVvbiAwMDAwOjA1OjAwLjA6IEZhdGFsIGVycm9yIGR1cmluZyBHUFUgaW5pdA0K
ICBbICAgODkuMDEzMzY5XSBbZHJtXSByYWRlb246IGZpbmlzaGluZyBkZXZpY2UuDQogIFsg
ICA4OS4wMzM0NTFdIFtUVE1dIEZpbmFsaXppbmcgcG9vbCBhbGxvY2F0b3INCiAgWyAgIDg5
LjA1MjQxMl0gW1RUTV0gRmluYWxpemluZyBETUEgcG9vbCBhbGxvY2F0b3INCiAgWyAgIDg5
LjA3MjY2OV0gW1RUTV0gWm9uZSAga2VybmVsOiBVc2VkIG1lbW9yeSBhdCBleGl0OiAwIGtp
Qg0KICBbICAgODkuMDk1MzYwXSBbZHJtXSByYWRlb246IHR0bSBmaW5hbGl6ZWQNCiAgWyAg
IDg5LjExMzg3MV0gcmFkZW9uOiBwcm9iZSBvZiAwMDAwOjA1OjAwLjAgZmFpbGVkIHdpdGgg
ZXJyb3IgLTIyDQogIFsgICA4OS4xNDMxMTJdIGJyZDogbW9kdWxlIGxvYWRlZA0KICBbICAg
ODkuMTcyMTYwXSBsb29wOiBtb2R1bGUgbG9hZGVkDQogIFsgICA4OS4xODk0MjhdIGFoY2kg
MDAwMDowMDoxMS4wOiB2ZXJzaW9uIDMuMA0KICBbICAgODkuMjA3ODcyXSB4ZW46IHJlZ2lz
dGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgODkuMjMwNjU2
XSB4ZW46IC0tPiBwaXJxPTE5IC0+IGlycT0xOSAoZ3NpPTE5KQ0KICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMToyMV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkg
LT4gMHhhOSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KIFsgICA4OS4yNzcyMzFdIGFo
Y2kgMDAwMDowMDoxMS4wOiBBSENJIDAwMDEuMDIwMCAzMiBzbG90cyA0IHBvcnRzIDYgR2Jw
cyAweGYgaW1wbCBTQVRBIG1vZGUNCiAgWyAgIDg5LjMwNzUyOV0gYWhjaSAwMDAwOjAwOjEx
LjA6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gcG1wIHBpbyBzbHVt
IHBhcnQgDQogIFsgICA4OS4zMzg4MjddIGFoY2k6IHByb2JlIG9mIDAwMDA6MDA6MTEuMCBm
YWlsZWQgd2l0aCBlcnJvciAtMjINCiAgWyAgIDg5LjM2MjY3OV0gdHVuOiBVbml2ZXJzYWwg
VFVOL1RBUCBkZXZpY2UgZHJpdmVyLCAxLjYNCiAgWyAgIDg5LjM4MzcxMV0gdHVuOiAoQykg
MTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0BxdWFsY29tbS5jb20+DQogIFsgICA4
OS40MDg0NzFdIGUxMDAwOiBJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZl
cnNpb24gNy4zLjIxLWs4LU5BUEkNCiAgWyAgIDg5LjQzNTU0N10gZTEwMDA6IENvcHlyaWdo
dCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KICBbICAgODkuNDU5MTUzXSBl
MTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyIC0gMi4yLjE0LWsNCiAg
WyAgIDg5LjQ4MjkzMl0gZTEwMDBlOiBDb3B5cmlnaHQoYykgMTk5OSAtIDIwMTMgSW50ZWwg
Q29ycG9yYXRpb24uDQogIFsgICA4OS41MDcwMzFdIGlnYjogSW50ZWwoUikgR2lnYWJpdCBF
dGhlcm5ldCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNC4xLjItaw0KICBbICAgODkuNTM0
MDA4XSBpZ2I6IENvcHlyaWdodCAoYykgMjAwNy0yMDEzIEludGVsIENvcnBvcmF0aW9uLg0K
ICBbICAgODkuNTU3MDY1XSBpZ2J2ZjogSW50ZWwoUikgR2lnYWJpdCBWaXJ0dWFsIEZ1bmN0
aW9uIE5ldHdvcmsgRHJpdmVyIC0gdmVyc2lvbiAyLjAuMi1rDQogIFsgICA4OS41ODY2Mjhd
IGlnYnZmOiBDb3B5cmlnaHQgKGMpIDIwMDkgLSAyMDEyIEludGVsIENvcnBvcmF0aW9uLg0K
ICBbICAgODkuNjEwOTQ3XSByODE2OSBHaWdhYml0IEV0aGVybmV0IGRyaXZlciAyLjNMSy1O
QVBJIGxvYWRlZA0KICBbICAgODkuNjMzODI1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0NiB0
cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgODkuNjU2NjA4XSB4ZW46IC0tPiBwaXJx
PTQ2IC0+IGlycT00NiAoZ3NpPTQ2KQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMToyMV0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjIgLT4gMHhiOSAtPiBJUlEg
NDYgTW9kZToxIEFjdGl2ZToxKQ0KIFsgICA4OS43MDI5ODBdIHI4MTY5IDAwMDA6MDk6MDAu
MDogZW5hYmxpbmcgTWVtLVdyLUludmFsDQogIFsgICA4OS43MjQ5NTBdIHI4MTY5IDAwMDA6
MDk6MDAuMCBldGgwOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAxYmUwMDAsIDQw
OjYxOjg2OmY0OjY3OmQ5LCBYSUQgMDgxMDAwYzAgSVJRIDEyMQ0KICBbICAgODkuNzYyMTUz
XSByODE2OSAwMDAwOjA5OjAwLjAgZXRoMDoganVtYm8gZmVhdHVyZXMgW2ZyYW1lczogOTIw
MCBieXRlcywgdHggY2hlY2tzdW1taW5nOiBrb10NCiAgWyAgIDg5Ljc5Mzk2NF0gcjgxNjkg
R2lnYWJpdCBFdGhlcm5ldCBkcml2ZXIgMi4zTEstTkFQSSBsb2FkZWQNCiAgWyAgIDg5Ljgx
NjgwMV0geGVuOiByZWdpc3RlcmluZyBnc2kgNTEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
CiAgWyAgIDg5LjgzOTgyMV0geGVuOiAtLT4gcGlycT01MSAtPiBpcnE9NTEgKGdzaT01MSkN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjE6MjFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTI3IC0+IDB4YzkgLT4gSVJRIDUxIE1vZGU6MSBBY3RpdmU6MSkNCiBb
ICAgODkuODg2MzUyXSByODE2OSAwMDAwOjA4OjAwLjA6IGVuYWJsaW5nIE1lbS1Xci1JbnZh
bA0KICBbICAgODkuOTA4NjY3XSByODE2OSAwMDAwOjA4OjAwLjAgZXRoMTogUlRMODE2OGQv
ODExMWQgYXQgMHhmZmZmYzkwMDAwMWUyMDAwLCA0MDo2MTo4NjpmNDo2NzpkOCwgWElEIDA4
MTAwMGMwIElSUSAxMjINCiAgWyAgIDg5Ljk0NTk4Ml0gcjgxNjkgMDAwMDowODowMC4wIGV0
aDE6IGp1bWJvIGZlYXR1cmVzIFtmcmFtZXM6IDkyMDAgYnl0ZXMsIHR4IGNoZWNrc3VtbWlu
Zzoga29dDQogIFsgICA4OS45NzgzMTNdIEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhl
cm5ldCBkcml2ZXIuDQogIFsgICA5MC4wMDE0NzNdIGVoY2lfaGNkOiBVU0IgMi4wICdFbmhh
bmNlZCcgSG9zdCBDb250cm9sbGVyIChFSENJKSBEcml2ZXINCiAgWyAgIDkwLjAyNzM5OF0g
ZWhjaS1wY2k6IEVIQ0kgUENJIHBsYXRmb3JtIGRyaXZlcg0KICBbICAgOTAuMDQ3MTEzXSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAg
OTAuMDcwMTM2XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE3DQogIFsgICA5MC4wODc0NjVd
IGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogZW5hYmxpbmcgYnVzIG1hc3RlcmluZw0KICBbICAg
OTAuMTEwMDMzXSBlaGNpLXBjaSAwMDAwOjAwOjEyLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVy
DQogIFsgICA5MC4xMzI1MTNdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogbmV3IFVTQiBidXMg
cmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQogIFsgICA5MC4xNjExNDldIFFV
SVJLOiBFbmFibGUgQU1EIFBMTCBmaXgNCiAgWyAgIDkwLjE3ODQ5M10gZWhjaS1wY2kgMDAw
MDowMDoxMi4yOiBhcHBseWluZyBBTUQgU0I3MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1
bW15IHFoIHdvcmthcm91bmQNCiAgWyAgIDkwLjIxMTEwMl0gZWhjaS1wY2kgMDAwMDowMDox
Mi4yOiBkZWJ1ZyBwb3J0IDENCiAgWyAgIDkwLjIzMTI3Nl0gZWhjaS1wY2kgMDAwMDowMDox
Mi4yOiBlbmFibGluZyBNZW0tV3ItSW52YWwNCiAgWyAgIDkwLjI1MzY2OV0gZWhjaS1wY2kg
MDAwMDowMDoxMi4yOiBpcnEgMTcsIGlvIG1lbSAweGY5NmZmNDAwDQogIFsgICA5MC4yODQ4
NDBdIGVoY2ktcGNpIDAwMDA6MDA6MTIuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAN
CiAgWyAgIDkwLjMwODUyN10gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZl
bmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KICBbICAgOTAuMzM1MjEyXSB1c2IgdXNiMTog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTENCiAgWyAgIDkwLjM2MzE4Nl0gdXNiIHVzYjE6IFByb2R1Y3Q6IEVIQ0kgSG9zdCBDb250
cm9sbGVyDQogIFsgICA5MC4zODQwNzZdIHVzYiB1c2IxOiBNYW51ZmFjdHVyZXI6IExpbnV4
IDMuOC4wLXJjMC0yMDEzMDIyNyBlaGNpX2hjZA0KICBbICAgOTAuNDA5NjU5XSB1c2IgdXNi
MTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjEyLjINCiAgWyAgIDkwLjQzMDQ0MF0gaHViIDEt
MDoxLjA6IFVTQiBodWIgZm91bmQNCiAgWyAgIDkwLjQ0ODAzMl0gaHViIDEtMDoxLjA6IDUg
cG9ydHMgZGV0ZWN0ZWQNCiAgWyAgIDkwLjQ2NjcxMl0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDkwLjQ4OTY2Ml0gQWxyZWFkeSBz
ZXR1cCB0aGUgR1NJIDoxNw0KICBbICAgOTAuNTA2ODQxXSBlaGNpLXBjaSAwMDAwOjAwOjEz
LjI6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNCiAgWyAgIDkwLjUyOTI5Nl0gZWhjaS1wY2kg
MDAwMDowMDoxMy4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTAuNTUxNTYyXSBl
aGNpLXBjaSAwMDAwOjAwOjEzLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVk
IGJ1cyBudW1iZXIgMg0KICBbICAgOTAuNTgwMDgxXSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6
IGFwcGx5aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29y
a2Fyb3VuZA0KICBbICAgOTAuNjEyNTU1XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGRlYnVn
IHBvcnQgMQ0KICBbICAgOTAuNjMyNTU3XSBlaGNpLXBjaSAwMDAwOjAwOjEzLjI6IGVuYWJs
aW5nIE1lbS1Xci1JbnZhbA0KICBbICAgOTAuNjU0Nzg1XSBlaGNpLXBjaSAwMDAwOjAwOjEz
LjI6IGlycSAxNywgaW8gbWVtIDB4Zjk2ZmY4MDANCiAgWyAgIDkwLjY4ODE1MF0gZWhjaS1w
Y2kgMDAwMDowMDoxMy4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KICBbICAgOTAu
NzExNzEzXSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAyDQogIFsgICA5MC43MzgzOTRdIHVzYiB1c2IyOiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KICBbICAg
OTAuNzY2Mzk0XSB1c2IgdXNiMjogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXINCiAg
WyAgIDkwLjc4NzI4NV0gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtcmMw
LTIwMTMwMjI3IGVoY2lfaGNkDQogIFsgICA5MC44MTI4NzRdIHVzYiB1c2IyOiBTZXJpYWxO
dW1iZXI6IDAwMDA6MDA6MTMuMg0KICBbICAgOTAuODMzNTYyXSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KICBbICAgOTAuODUxMDMzXSBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRl
Y3RlZA0KICBbICAgOTAuODY5NDM5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgOTAuODkyMzA5XSBBbHJlYWR5IHNldHVwIHRoZSBH
U0kgOjE3DQogIFsgICA5MC45MDkzMzBdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxp
bmcgYnVzIG1hc3RlcmluZw0KICBbICAgOTAuOTMxNjAwXSBlaGNpLXBjaSAwMDAwOjAwOjE2
LjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5MC45NTM0NjZdIGVoY2ktcGNpIDAw
MDA6MDA6MTYuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJl
ciAzDQogIFsgICA5MC45ODE2NzNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogYXBwbHlpbmcg
QU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQog
IFsgICA5MS4wMTM4MzNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZGVidWcgcG9ydCAxDQog
IFsgICA5MS4wMzM0ODNdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogZW5hYmxpbmcgTWVtLVdy
LUludmFsDQogIFsgICA5MS4wNTUyOTVdIGVoY2ktcGNpIDAwMDA6MDA6MTYuMjogaXJxIDE3
LCBpbyBtZW0gMHhmOTZmZmMwMA0KICBbICAgOTEuMDk4MDQ4XSBlaGNpLXBjaSAwMDAwOjAw
OjE2LjI6IFVTQiAyLjAgc3RhcnRlZCwgRUhDSSAxLjAwDQogIFsgICA5MS4xMjExMTNdIHVz
YiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0
PTAwMDINCiAgWyAgIDkxLjE0NzMxMl0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIHN0cmlu
Z3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQogIFsgICA5MS4xNzQ4MDld
IHVzYiB1c2IzOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTEuMTk1
MTkzXSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcg
ZWhjaV9oY2QNCiAgWyAgIDkxLjIyMDI0M10gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAw
MDowMDoxNi4yDQogIFsgICA5MS4yNDAxNjFdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5k
DQogIFsgICA5MS4yNTcwMTNdIGh1YiAzLTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQogIFsg
ICA5MS4yNzQ4MzldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDMxIHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQogIFsgICA5MS4yOTcxNDZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzENCiAg
WyAgIDkxLjMxMzY0M10gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBlbmFibGluZyBidXMgbWFz
dGVyaW5nDQogIFsgICA5MS4zMzUzMDVdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogRUhDSSBI
b3N0IENvbnRyb2xsZXINCiAgWyAgIDkxLjM1NjUxNV0gZWhjaS1wY2kgMDAwMDowYjowMS4y
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDQNCiAgWyAg
IDkxLjM4NDI0N10gZWhjaS1wY2kgMDAwMDowYjowMS4yOiBpcnEgMzEsIGlvIG1lbSAweGY5
ZmZmYzAwDQogIFsgICA5MS40MTQ3OTFdIGVoY2ktcGNpIDAwMDA6MGI6MDEuMjogVVNCIDIu
MCBzdGFydGVkLCBFSENJIDEuMDANCiAgWyAgIDkxLjQzNzQyNV0gdXNiIHVzYjQ6IE5ldyBV
U0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMg0KICBbICAg
OTEuNDYzMTA3XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy
b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAgWyAgIDkxLjQ5MDEwNV0gdXNiIHVzYjQ6IFBy
b2R1Y3Q6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5MS41MTAwODVdIHVzYiB1c2I0
OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEzMDIyNyBlaGNpX2hjZA0KICBb
ICAgOTEuNTM0Nzk2XSB1c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjBiOjAxLjINCiAg
WyAgIDkxLjU1NDQ1Nl0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQNCiAgWyAgIDkxLjU3
MDk3MF0gaHViIDQtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNCiAgWyAgIDkxLjU4ODY3MV0g
b2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVy
DQogIFsgICA5MS42MTI2MTddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQogIFsgICA5MS42MzQ2MTJdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTgNCiAgWyAgIDkxLjY1MDg5OV0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBlbmFibGluZyBi
dXMgbWFzdGVyaW5nDQogIFsgICA5MS42NzIzNzRdIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDog
T0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkxLjY5MzQ2Ml0gb2hjaV9oY2QgMDAwMDow
MDoxMi4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUN
CiAgWyAgIDkxLjcyMDk5NV0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBpcnEgMTgsIGlvIG1l
bSAweGY5NmZiMDAwDQogIFsgICA5MS43OTg5NTRdIHVzYiB1c2I1OiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENCiAgWyAgIDkxLjgyNDU5
Nl0gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIs
IFNlcmlhbE51bWJlcj0xDQogIFsgICA5MS44NTE1NDVdIHVzYiB1c2I1OiBQcm9kdWN0OiBP
SENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTEuODcxNTEzXSB1c2IgdXNiNTogTWFudWZh
Y3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcgb2hjaV9oY2QNCiAgWyAgIDkxLjg5
NjE4MV0gdXNiIHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4wDQogIFsgICA5MS45
MTU3MTddIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQogIFsgICA5MS45MzIyMjRdIGh1
YiA1LTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkDQogIFsgICA5MS45NDk4MDVdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5MS45NzE4
MzhdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNCiAgWyAgIDkxLjk4ODA0OF0gb2hjaV9o
Y2QgMDAwMDowMDoxMy4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQogIFsgICA5Mi4wMDk0
ODZdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogT0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAg
IDkyLjAzMDU1M10gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl
cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDYNCiAgWyAgIDkyLjA1ODEzN10gb2hjaV9oY2Qg
MDAwMDowMDoxMy4wOiBpcnEgMTgsIGlvIG1lbSAweGY5NmZjMDAwDQogIFsgICA5Mi4xMzU1
NTRdIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQ
cm9kdWN0PTAwMDENCiAgWyAgIDkyLjE2MTI0N10gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNl
IHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQogIFsgICA5Mi4x
ODgyNjJdIHVzYiB1c2I2OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAg
OTIuMjA4MjAwXSB1c2IgdXNiNjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAx
MzAyMjcgb2hjaV9oY2QNCiAgWyAgIDkyLjIzMjg0N10gdXNiIHVzYjY6IFNlcmlhbE51bWJl
cjogMDAwMDowMDoxMy4wDQogIFsgICA5Mi4yNTI0OTBdIGh1YiA2LTA6MS4wOiBVU0IgaHVi
IGZvdW5kDQogIFsgICA5Mi4yNjkwMDddIGh1YiA2LTA6MS4wOiA1IHBvcnRzIGRldGVjdGVk
DQogIFsgICA5Mi4yODY2MDldIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcg
MCBwb2xhcml0eSAxDQogIFsgICA5Mi4zMDg2MzZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6
MTgNCiAgWyAgIDkyLjMyNDkyNV0gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBlbmFibGluZyBi
dXMgbWFzdGVyaW5nDQogIFsgICA5Mi4zNDY0MTRdIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTog
T0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkyLjM2NzU0Nl0gb2hjaV9oY2QgMDAwMDow
MDoxNC41OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcN
CiAgWyAgIDkyLjM3ODAzN10gdXNiIDUtNTogbmV3IGZ1bGwtc3BlZWQgVVNCIGRldmljZSBu
dW1iZXIgMiB1c2luZyBvaGNpX2hjZA0KICBbICAgOTIuNDIwMjExXSBvaGNpX2hjZCAwMDAw
OjAwOjE0LjU6IGlycSAxOCwgaW8gbWVtIDB4Zjk2ZmQwMDANCiAgWyAgIDkyLjQ5ODc2Nl0g
dXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1
Y3Q9MDAwMQ0KICBbICAgOTIuNTI0NjA2XSB1c2IgdXNiNzogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAgWyAgIDkyLjU1MTc1
Ml0gdXNiIHVzYjc6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5Mi41
NzE4NTRdIHVzYiB1c2I3OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEzMDIy
NyBvaGNpX2hjZA0KICBbICAgOTIuNTk2NjMyXSB1c2IgdXNiNzogU2VyaWFsTnVtYmVyOiAw
MDAwOjAwOjE0LjUNCiAgWyAgIDkyLjYxNjUzMl0gaHViIDctMDoxLjA6IFVTQiBodWIgZm91
bmQNCiAgWyAgIDkyLjYzMzQyMF0gaHViIDctMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNCiAg
WyAgIDkyLjY1MDk5MF0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBv
bGFyaXR5IDENCiAgWyAgIDkyLjY3MzA5N10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0K
ICBbICAgOTIuNjg5NDMyXSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IGVuYWJsaW5nIGJ1cyBt
YXN0ZXJpbmcNCiAgWyAgIDkyLjcxMTEwMl0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBPSENJ
IEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTIuNzMyNjAyXSBvaGNpX2hjZCAwMDAwOjAwOjE2
LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgOA0KICBb
ICAgOTIuNzYwNDc4XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IGlycSAxOCwgaW8gbWVtIDB4
Zjk2ZmUwMDANCiAgWyAgIDkyLjgzODg4Ml0gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZv
dW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KICBbICAgOTIuODY0OTI0XSB1
c2IgdXNiODogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2Vy
aWFsTnVtYmVyPTENCiAgWyAgIDkyLjg5MjA5NV0gdXNiIHVzYjg6IFByb2R1Y3Q6IE9IQ0kg
SG9zdCBDb250cm9sbGVyDQogIFsgICA5Mi45MTIxOTBdIHVzYiB1c2I4OiBNYW51ZmFjdHVy
ZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEzMDIyNyBvaGNpX2hjZA0KICBbICAgOTIuOTM3MDMx
XSB1c2IgdXNiODogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjE2LjANCiAgWyAgIDkyLjk1NjQw
Nl0gdXNiIDUtNTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTBhMTIsIGlkUHJv
ZHVjdD0wMDAxDQogIFsgICA5Mi45NTY5MzhdIGh1YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5k
DQogIFsgICA5Mi45NTY5NDddIGh1YiA4LTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQogIFsg
ICA5Mi45NTcyOTRdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI5IHRyaWdnZXJpbmcgMCBwb2xh
cml0eSAxDQogIFsgICA5Mi45NTcyOTZdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjkNCiAg
WyAgIDkyLjk1NzMxNV0gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBlbmFibGluZyBidXMgbWFz
dGVyaW5nDQogIFsgICA5Mi45NTczMjNdIG9oY2lfaGNkIDAwMDA6MGI6MDEuMDogT0hDSSBI
b3N0IENvbnRyb2xsZXINCiAgWyAgIDkyLjk1NzY1NF0gb2hjaV9oY2QgMDAwMDowYjowMS4w
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDkNCiAgWyAg
IDkyLjk1NzczNV0gb2hjaV9oY2QgMDAwMDowYjowMS4wOiBpcnEgMjksIGlvIG1lbSAweGY5
ZmZkMDAwDQogIFsgICA5My4wMzgwNjNdIHVzYiB1c2I5OiBOZXcgVVNCIGRldmljZSBmb3Vu
ZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENCiAgWyAgIDkzLjAzODA2NF0gdXNi
IHVzYjk6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlh
bE51bWJlcj0xDQogIFsgICA5My4wMzgwNjVdIHVzYiB1c2I5OiBQcm9kdWN0OiBPSENJIEhv
c3QgQ29udHJvbGxlcg0KICBbICAgOTMuMDM4MDY5XSB1c2IgdXNiOTogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcgb2hjaV9oY2QNCiAgWyAgIDkzLjAzODA3MF0g
dXNiIHVzYjk6IFNlcmlhbE51bWJlcjogMDAwMDowYjowMS4wDQogIFsgICA5My4wMzg1NzVd
IGh1YiA5LTA6MS4wOiBVU0IgaHViIGZvdW5kDQogIFsgICA5My4wMzg1ODZdIGh1YiA5LTA6
MS4wOiAzIHBvcnRzIGRldGVjdGVkDQogIFsgICA5My4wMzg5NTFdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDMwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5My4wMzg5NTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6MzANCiAgWyAgIDkzLjAzODk3MF0gb2hjaV9oY2QgMDAw
MDowYjowMS4xOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQogIFsgICA5My4wMzg5NzldIG9o
Y2lfaGNkIDAwMDA6MGI6MDEuMTogT0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkzLjAz
OTMxMV0gb2hjaV9oY2QgMDAwMDowYjowMS4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDEwDQogIFsgICA5My4wMzkzOThdIG9oY2lfaGNkIDAwMDA6
MGI6MDEuMTogaXJxIDMwLCBpbyBtZW0gMHhmOWZmZTAwMA0KICBbICAgOTMuMTIxNDIxXSB1
c2IgdXNiMTA6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1
Y3Q9MDAwMQ0KICBbICAgOTMuMTIxNDIzXSB1c2IgdXNiMTA6IE5ldyBVU0IgZGV2aWNlIHN0
cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQogIFsgICA5My4xMjE0
MjRdIHVzYiB1c2IxMDogUHJvZHVjdDogT0hDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkz
LjEyMTQyNV0gdXNiIHVzYjEwOiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuOC4wLXJjMC0yMDEz
MDIyNyBvaGNpX2hjZA0KICBbICAgOTMuMTIxNDI2XSB1c2IgdXNiMTA6IFNlcmlhbE51bWJl
cjogMDAwMDowYjowMS4xDQogIFsgICA5My4xMjIyODRdIGh1YiAxMC0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KICBbICAgOTMuMTIyMjk2XSBodWIgMTAtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0
ZWQNCiAgWyAgIDkzLjEyMjgzMV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250
cm9sbGVyIEludGVyZmFjZSBkcml2ZXINCiAgWyAgIDkzLjEyMzA2Ml0geGVuOiByZWdpc3Rl
cmluZyBnc2kgNDggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDkzLjEyMzA2NV0g
QWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0OA0KICBbICAgOTMuMTIzMDg1XSB4aGNpX2hjZCAw
MDAwOjA3OjAwLjA6IGVuYWJsaW5nIGJ1cyBtYXN0ZXJpbmcNCiAgWyAgIDkzLjEyMzA5MF0g
eGhjaV9oY2QgMDAwMDowNzowMC4wOiB4SENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTMu
MTIzNTAyXSB4aGNpX2hjZCAwMDAwOjA3OjAwLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMTENCiAgWyAgIDkzLjEyNTMyMV0geGhjaV9oY2QgMDAw
MDowNzowMC4wOiBlbmFibGluZyBNZW0tV3ItSW52YWwNCiAgWyAgIDkzLjEyNTM3MV0geGhj
aV9oY2QgMDAwMDowNzowMC4wOiBpcnEgNDgsIGlvIG1lbSAweGY5Y2ZlMDAwDQogIFsgICA5
My4xMjYyNjddIHVzYiB1c2IxMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFk
NmIsIGlkUHJvZHVjdD0wMDAyDQogIFsgICA5My4xMjYyNjhdIHVzYiB1c2IxMTogTmV3IFVT
QiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAg
WyAgIDkzLjEyNjI2OV0gdXNiIHVzYjExOiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxl
cg0KICBbICAgOTMuMTI2MjcwXSB1c2IgdXNiMTE6IE1hbnVmYWN0dXJlcjogTGludXggMy44
LjAtcmMwLTIwMTMwMjI3IHhoY2lfaGNkDQogIFsgICA5My4xMjYyNzFdIHVzYiB1c2IxMTog
U2VyaWFsTnVtYmVyOiAwMDAwOjA3OjAwLjANCiAgWyAgIDkzLjEyNjY2Nl0geEhDSSB4aGNp
X2FkZF9lbmRwb2ludCBjYWxsZWQgZm9yIHJvb3QgaHViDQogIFsgICA5My4xMjY2NjhdIHhI
Q0kgeGhjaV9jaGVja19iYW5kd2lkdGggY2FsbGVkIGZvciByb290IGh1Yg0KICBbICAgOTMu
MTI2ODMwXSBodWIgMTEtMDoxLjA6IFVTQiBodWIgZm91bmQNCiAgWyAgIDkzLjEyNjg1MV0g
aHViIDExLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQogIFsgICA5My4xMjY5OTldIHhoY2lf
aGNkIDAwMDA6MDc6MDAuMDogeEhDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAgIDkzLjEyNzM4
Nl0geGhjaV9oY2QgMDAwMDowNzowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3Np
Z25lZCBidXMgbnVtYmVyIDEyDQogIFsgICA5My4xMjc0NTVdIHVzYiB1c2IxMjogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAzDQogIFsgICA5
My4xMjc0NTZdIHVzYiB1c2IxMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFBy
b2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCiAgWyAgIDkzLjEyNzQ1N10gdXNiIHVzYjEyOiBQ
cm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KICBbICAgOTMuMTI3NDU5XSB1c2IgdXNi
MTI6IE1hbnVmYWN0dXJlcjogTGludXggMy44LjAtcmMwLTIwMTMwMjI3IHhoY2lfaGNkDQog
IFsgICA5My4xMjc0NjBdIHVzYiB1c2IxMjogU2VyaWFsTnVtYmVyOiAwMDAwOjA3OjAwLjAN
CiAgWyAgIDkzLjEyNzg0Ml0geEhDSSB4aGNpX2FkZF9lbmRwb2ludCBjYWxsZWQgZm9yIHJv
b3QgaHViDQogIFsgICA5My4xMjc4NDNdIHhIQ0kgeGhjaV9jaGVja19iYW5kd2lkdGggY2Fs
bGVkIGZvciByb290IGh1Yg0KICBbICAgOTMuMTI3OTk3XSBodWIgMTItMDoxLjA6IFVTQiBo
dWIgZm91bmQNCiAgWyAgIDkzLjEyODAxMF0gaHViIDEyLTA6MS4wOiAyIHBvcnRzIGRldGVj
dGVkDQogIFsgICA5NC4xOTQ4NTZdIHVzYiA1LTU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6
IE1mcj0wLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wDQogIFsgICA5NC4yMjE0OTVdIHVz
YiA1LTU6IFByb2R1Y3Q6IEVEUkNsYXNzb25lDQogIFsgICA5NC4yNDE3ODBdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDQwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5NC4yNjM4
NjFdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NDANCiAgWyAgIDk0LjI4MDEzNl0geGhjaV9o
Y2QgMDAwMDowNDowMC4wOiBlbmFibGluZyBidXMgbWFzdGVyaW5nDQogIFsgICA5NC4zMDE1
ODRdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuMDogeEhDSSBIb3N0IENvbnRyb2xsZXINCiAgWyAg
IDk0LjMyMjcwMF0geGhjaV9oY2QgMDAwMDowNDowMC4wOiBuZXcgVVNCIGJ1cyByZWdpc3Rl
cmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDEzDQogIFsgICA5NC4zNTA2MThdIHhoY2lfaGNk
IDAwMDA6MDQ6MDAuMDogZW5hYmxpbmcgTWVtLVdyLUludmFsDQogIFsgICA5NC4zNjgwMzdd
IHVzYiA4LTM6IG5ldyBsb3ctc3BlZWQgVVNCIGRldmljZSBudW1iZXIgMiB1c2luZyBvaGNp
X2hjZA0KICBbICAgOTQuMzk2Njc0XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjA6IGlycSA0MCwg
aW8gbWVtIDB4Zjk4ZmUwMDANCiAgWyAgIDk0LjQxOTc2NV0gdXNiIHVzYjEzOiBOZXcgVVNC
IGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDINCiAgWyAgIDk0
LjQ0NTgxMF0gdXNiIHVzYjEzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJv
ZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KICBbICAgOTQuNDczMDc5XSB1c2IgdXNiMTM6IFBy
b2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyDQogIFsgICA5NC40OTMyODhdIHVzYiB1c2Ix
MzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjguMC1yYzAtMjAxMzAyMjcgeGhjaV9oY2QNCiAg
WyAgIDk0LjUxODI1OV0gdXNiIHVzYjEzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDQ6MDAuMA0K
ICBbICAgOTQuNTM4MDc1XSB4SENJIHhoY2lfYWRkX2VuZHBvaW50IGNhbGxlZCBmb3Igcm9v
dCBodWINCiAgWyAgIDk0LjU1ODg5OF0geEhDSSB4aGNpX2NoZWNrX2JhbmR3aWR0aCBjYWxs
ZWQgZm9yIHJvb3QgaHViDQogIFsgICA5NC41ODA4MjZdIGh1YiAxMy0wOjEuMDogVVNCIGh1
YiBmb3VuZA0KICBbICAgOTQuNTk3ODc2XSBodWIgMTMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0
ZWQNCiAgWyAgIDk0LjYxNTczOV0geGhjaV9oY2QgMDAwMDowNDowMC4wOiB4SENJIEhvc3Qg
Q29udHJvbGxlcg0KICBbICAgOTQuNjM3MTk0XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjA6IG5l
dyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMTQNCiAgWyAgIDk0
LjY2NTI4NF0gdXNiIHVzYjE0OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDMNCiAgWyAgIDk0LjY5MTYxMF0gdXNiIHVzYjE0OiBOZXcgVVNC
IGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KICBb
ICAgOTQuNzE5MjAwXSB1c2IgdXNiMTQ6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVy
DQogIFsgICA5NC43Mzk2NTJdIHVzYiB1c2IxNDogTWFudWZhY3R1cmVyOiBMaW51eCAzLjgu
MC1yYzAtMjAxMzAyMjcgeGhjaV9oY2QNCiAgWyAgIDk0Ljc2NDg2N10gdXNiIHVzYjE0OiBT
ZXJpYWxOdW1iZXI6IDAwMDA6MDQ6MDAuMA0KICBbICAgOTQuNzg0NTQ1XSB1c2IgOC0zOiBO
ZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MDQ2ZCwgaWRQcm9kdWN0PWM1MTcNCiAg
WyAgIDk0Ljc4NDg3NF0geEhDSSB4aGNpX2FkZF9lbmRwb2ludCBjYWxsZWQgZm9yIHJvb3Qg
aHViDQogIFsgICA5NC43ODQ4NzRdIHhIQ0kgeGhjaV9jaGVja19iYW5kd2lkdGggY2FsbGVk
IGZvciByb290IGh1Yg0KICBbICAgOTQuNzg1MDA0XSBodWIgMTQtMDoxLjA6IFVTQiBodWIg
Zm91bmQNCiAgWyAgIDk0Ljc4NTAxNF0gaHViIDE0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVk
DQogIFsgICA5NC44ODc0NjRdIHVzYiA4LTM6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wDQogIFsgICA5NC45MTQ0MjddIHVzYiA4
LTM6IFByb2R1Y3Q6IFVTQiBSZWNlaXZlcg0KICBbICAgOTQuOTMyMTkzXSB1c2IgOC0zOiBN
YW51ZmFjdHVyZXI6IExvZ2l0ZWNoDQogIFsgICA5NC45NTA3NTJdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHANCiAgWyAgIDk0Ljk3MjgwM10gSW5p
dGlhbGl6aW5nIFVTQiBNYXNzIFN0b3JhZ2UgZHJpdmVyLi4uDQogIFsgICA5NC45OTMyODhd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UN
CiAgWyAgIDk1LjAxNjg4OV0gVVNCIE1hc3MgU3RvcmFnZSBzdXBwb3J0IHJlZ2lzdGVyZWQu
DQogIFsgICA5NS4wMzY3MTJdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgdXNic2VyaWFsDQogIFsgICA5NS4wNTgwMzVdIHVzYiAxMy0yOiBuZXcgbG93LXNw
ZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIgdXNpbmcgeGhjaV9oY2QNCiAgWyAgIDk1LjA4NTI5
NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBjcDIxMHgNCiAg
WyAgIDk1LjEwNDMxOF0gdXNiIDEzLTI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xMGNmLCBpZFByb2R1Y3Q9NTUwMA0KICBbICAgOTUuMTA0MzE5XSB1c2IgMTMtMjogTmV3
IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTAN
CiAgWyAgIDk1LjEwNDMyMF0gdXNiIDEzLTI6IFByb2R1Y3Q6IFVTQiBLODA1NQ0KICBbICAg
OTUuMTA0MzIxXSB1c2IgMTMtMjogTWFudWZhY3R1cmVyOiBWZWxsZW1hbiANCiAgWyAgIDk1
LjEwNDgwOF0gdXNiIDEzLTI6IGVwIDB4ODEgLSByb3VuZGluZyBpbnRlcnZhbCB0byA2NCBt
aWNyb2ZyYW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzDQogIFsgICA5NS4xMDc2
MTNdIHVzYiAxMy0yOiBlcCAweDEgLSByb3VuZGluZyBpbnRlcnZhbCB0byA2NCBtaWNyb2Zy
YW1lcywgZXAgZGVzYyBzYXlzIDgwIG1pY3JvZnJhbWVzDQogIFsgICA5NS4yNjEzNDVdIHVz
YnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIGNwMjEweA0KICBb
ICAgOTUuMjg1MzI4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IGN5cHJlc3NfbTgNCiAgWyAgIDk1LjMwOTI5NV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgRGVMb3JtZSBFYXJ0aG1hdGUgVVNCDQogIFsgICA5NS4z
MzcyNDZdIHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJ
RC0+Q09NIFJTMjMyIEFkYXB0ZXINCiAgWyAgIDk1LjM2NTQxN10gdXNic2VyaWFsOiBVU0Ig
U2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcg0K
ICBbICAgOTUuMzkzNTU4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIG1vczc3MjANCiAgWyAgIDk1LjQxNjc4MF0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCAyIHBvcnQgYWRhcHRlcg0KICBbICAgOTUu
NDQ1MDM3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc4
NDANCiAgWyAgIDk1LjQ2ODI2Ml0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVn
aXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNCIFNlcmlhbCBEcml2ZXINCiAgWyAg
IDk1LjUwMDQ3MF0gaTgwNDI6IFBOUDogTm8gUFMvMiBjb250cm9sbGVyIGZvdW5kLiBQcm9i
aW5nIHBvcnRzIGRpcmVjdGx5Lg0KICBbICAgOTUuNTI3ODE1XSBzZXJpbzogaTgwNDIgS0JE
IHBvcnQgYXQgMHg2MCwweDY0IGlycSAxDQogIFsgICA5NS41NDkwNjVdIHNlcmlvOiBpODA0
MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQogIFsgICA5NS41NzA3MDVdIG1vdXNl
ZGV2OiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlDQogIFsgICA5NS41
OTQ0ODJdIHJ0Y19jbW9zIDAwOjAzOiBSVEMgY2FuIHdha2UgZnJvbSBTNA0KICBbICAgOTUu
NjE0ODg2XSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJlZ2lzdGVyZWQgcnRjX2Ntb3Mg
YXMgcnRjMA0KICBbICAgOTUuNjM5MjA0XSBydGNfY21vcyAwMDowMzogYWxhcm1zIHVwIHRv
IG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NCiAgWyAgIDk1LjY2NjMxMl0gQUNQ
SSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDBiMDAtMHgwMDAwMDAwMDAwMDAwYjA3IFN5c3Rl
bUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcU09SMSAxICgyMDEzMDExNy91dGFkZHJlc3Mt
MjUxKQ0KICBbICAgOTUuNzA2NTQxXSBBQ1BJOiBJZiBhbiBBQ1BJIGRyaXZlciBpcyBhdmFp
bGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVzZSBpdCBpbnN0ZWFkIG9mIHRo
ZSBuYXRpdmUgZHJpdmVyDQogIFsgICA5NS43NDQ5ODBdIGxpcmNfZGV2OiBJUiBSZW1vdGUg
Q29udHJvbCBkcml2ZXIgcmVnaXN0ZXJlZCwgbWFqb3IgMjQ4IA0KICBbICAgOTUuNzcwNzAw
XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuNzkwNjU5
XSBJUiBSQzUoeCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuODEx
MzYwXSBJUiBSQzYgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuODMx
MjI0XSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuODUw
OTU5XSBJUiBTb255IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNCiAgWyAgIDk1Ljg3
MDk2Ml0gSVIgUkM1IChzdHJlYW16YXApIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQN
CiAgWyAgIDk1Ljg5MzgyOV0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXpl
ZA0KICBbICAgOTUuOTE0MDkyXSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wgaGFu
ZGxlciBpbml0aWFsaXplZA0KICBbICAgOTUuOTM3NzI3XSBJUiBMSVJDIGJyaWRnZSBoYW5k
bGVyIGluaXRpYWxpemVkDQogIFsgICA5NS45NTcyMzVdIGN4MjU4MjE6IGRyaXZlciB2ZXJz
aW9uIDAuMC4xMDYgbG9hZGVkDQogIFsgICA5NS45Nzc4NDRdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDQ3IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQogIFsgICA5Ni4wMDA4MjZdIHhlbjog
LS0+IHBpcnE9NDcgLT4gaXJxPTQ3IChnc2k9NDcpDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIxOjI4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweDky
IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDk2LjA0NzQxMV0gY3gyNTgyMTog
QXRoZW5hIHBjaSBlbmFibGUgIQ0KICBbICAgOTYuMDY1MzM1XSBjeDI1ODIxOiANCiAgWyAg
IDk2LjA2NTMzNV0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgWyAg
IDk2LjA5ODMxM10gY3gyNTgyMTogY3gyNTgyMSBzZXQgdXANCiAgWyAgIDk2LjExNDc1N10g
Y3gyNTgyMTogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgWyAgIDk2
LjExNDc1N10gDQogIFsgICA5Ni4xNDc2MTJdIGN4MjU4MjE6IEF0aGVuYSBIYXJkd2FyZSBk
ZXZpY2UgPSAweDgyMTANCiAgWyAgIDk2LjE2ODgzN10gY3gyNTgyMTogY3gyNTgyMVsxXTog
c3Vic3lzdGVtOiAwMDAwOjAwMDAsIGJvYXJkOiBDWDI1ODIxIFtjYXJkPTEsYXV0b2RldGVj
dGVkXQ0KICBbICAgOTYuNDIwNzQ0XSBjeDI1ODIxOiAoMSk6IGkyYyByZWdpc3RlciEgYnVz
LT5pMmNfcmMgPSAwDQogIFsgICA5Ni41MTk4ODVdIGN4MjU4MjE6IGN4MjU4MjFfZGV2X2No
ZWNrcmV2aXNpb24oKTogSGFyZHdhcmUgcmV2aXNpb24gPSAweDAwDQogIFsgICA5Ni41NDY2
MzRdIGN4MjU4MjE6ICgxKTogc2V0dXAgZG9uZSENCiAgWyAgIDk2LjU2Mzc4MF0gY3gyNTgy
MTogY3gyNTgyMVsxXS8wOiBmb3VuZCBhdCAwMDAwOjA2OjAwLjAsIHJldjogMCwgaXJxOiA0
NywgbGF0ZW5jeTogMCwgbW1pbzogMHhmOWEwMDAwMA0KICBbICAgOTYuNTk4OTI4XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHB2cnVzYjINCiAgWyAgIDk2
LjYyMjE1Ml0gcHZydXNiMjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYt
UFZSLVVTQjIgTVBFRzIgRW5jb2Rlci9UdW5lcg0KICBbICAgOTYuNjUyMDI5XSBwdnJ1c2Iy
OiBEZWJ1ZyBtYXNrIGlzIDMxICgweDFmKQ0KICBbICAgOTYuNjcxNTMzXSBmNzE4MDVmOiBV
bnN1cHBvcnRlZCBGaW50ZWsgZGV2aWNlLCBza2lwcGluZw0KICBbICAgOTYuNjkzOTM0XSBm
NzE4ODJmZzogRm91bmQgZjcxODg5ZWQgY2hpcCBhdCAweDYwMCwgcmV2aXNpb24gMTYNCiAg
WyAgIDk2LjcxODM1NV0gQUNQSSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDA2MDAtMHgwMDAw
MDAwMDAwMDAwNjA3IFN5c3RlbUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcSE1PUiAxICgy
MDEzMDExNy91dGFkZHJlc3MtMjUxKQ0KICBbICAgOTYuNzU4ODg4XSBBQ1BJOiBJZiBhbiBB
Q1BJIGRyaXZlciBpcyBhdmFpbGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVz
ZSBpdCBpbnN0ZWFkIG9mIHRoZSBuYXRpdmUgZHJpdmVyDQogIFsgICA5Ni43OTczMTRdIHNw
NTEwMF90Y286IFNQNTEwMC9TQjgwMCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJpdmVyIHYwLjAz
DQogIFsgICA5Ni44MjM3MzFdIHNwNTEwMF90Y286IFBDSSBSZXZpc2lvbiBJRDogMHg0MQ0K
ICBbICAgOTYuODQzNTc0XSBzcDUxMDBfdGNvOiBVc2luZyAweGZlZDgwYjAwIGZvciB3YXRj
aGRvZyBNTUlPIGFkZHJlc3MNCiAgWyAgIDk2Ljg2ODc4N10gc3A1MTAwX3RjbzogTGFzdCBy
ZWJvb3Qgd2FzIG5vdCB0cmlnZ2VyZWQgYnkgd2F0Y2hkb2cuDQogIFsgICA5Ni44OTQzMjdd
IHNwNTEwMF90Y286IGluaXRpYWxpemVkICgweGZmZmZjOTAwMTAyZWFiMDApLiBoZWFydGJl
YXQ9NjAgc2VjIChub3dheW91dD0wLCBmb3JjZV9hZGRyPW5vbmUpDQogIFsgICA5Ni45Mjk1
MTVdIHhlbl93ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENCiAgWyAgIDk2
Ljk1MTYzM10geGVuX3dkdDogY2Fubm90IHJlZ2lzdGVyIG1pc2NkZXYgb24gbWlub3I9MTMw
ICgtMTYpDQogIFsgICA5Ni45NzYxODRdIHdkdDogcHJvYmUgb2Ygd2R0IGZhaWxlZCB3aXRo
IGVycm9yIC0xNg0KICBbICAgOTYuOTk4MzgwXSBkZXZpY2UtbWFwcGVyOiBpb2N0bDogNC4y
My4xLWlvY3RsICgyMDEyLTEyLTE4KSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAcmVkaGF0LmNv
bQ0KICBbICAgOTcuMDMwODk0XSBCbHVldG9vdGg6IFZpcnR1YWwgSENJIGRyaXZlciB2ZXIg
MS4zDQogIFsgICA5Ny4wNTIxNDZdIEJsdWV0b290aDogSENJIFVBUlQgZHJpdmVyIHZlciAy
LjINCiAgWyAgIDk3LjA3MjIyOV0gQmx1ZXRvb3RoOiBIQ0kgSDQgcHJvdG9jb2wgaW5pdGlh
bGl6ZWQNCiAgWyAgIDk3LjA5MzM0NF0gQmx1ZXRvb3RoOiBIQ0kgQkNTUCBwcm90b2NvbCBp
bml0aWFsaXplZA0KICBbICAgOTcuMTE0OTg0XSBCbHVldG9vdGg6IEhDSUxMIHByb3RvY29s
IGluaXRpYWxpemVkDQogIFsgICA5Ny4xMzU3ODZdIEJsdWV0b290aDogSENJQVRIM0sgcHJv
dG9jb2wgaW5pdGlhbGl6ZWQNCiAgWyAgIDk3LjE1NzI2OV0gQmx1ZXRvb3RoOiBIQ0kgVGhy
ZWUtd2lyZSBVQVJUIChINSkgcHJvdG9jb2wgaW5pdGlhbGl6ZWQNCiAgWyAgIDk3LjE4MzI1
NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiY20yMDN4DQog
IFsgICA5Ny4yMDcyMjhdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgYnBhMTB4DQogIFsgICA5Ny4yMzA4NTBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgYmZ1c2INCiAgWyAgIDk3LjI1NDUxNl0gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBidHVzYg0KICBbICAgOTcuMjc3NjQ1XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGF0aDNrDQogIFsgICA5Ny4z
MDExMjJdIGhpZHJhdzogcmF3IEhJRCBldmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQ0K
ICBbICAgOTcuMzI5NzE4XSBpbnB1dDogTG9naXRlY2ggVVNCIFJlY2VpdmVyIGFzIC9kZXZp
Y2VzL3BjaTAwMDA6MDAvMDAwMDowMDoxNi4wL3VzYjgvOC0zLzgtMzoxLjAvaW5wdXQvaW5w
dXQyDQogIFsgICA5Ny4zNjU5ODRdIGxvZ2l0ZWNoIDAwMDM6MDQ2RDpDNTE3LjAwMDE6IGlu
cHV0LGhpZHJhdzA6IFVTQiBISUQgdjEuMTAgS2V5Ym9hcmQgW0xvZ2l0ZWNoIFVTQiBSZWNl
aXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0zL2lucHV0MA0KICBbICAgOTcuNDE2MDAwXSBs
b2dpdGVjaCAwMDAzOjA0NkQ6QzUxNy4wMDAyOiBmaXhpbmcgdXAgTG9naXRlY2gga2V5Ym9h
cmQgcmVwb3J0IGRlc2NyaXB0b3INCiAgWyAgIDk3LjQ0NzM1MF0gaW5wdXQ6IExvZ2l0ZWNo
IFVTQiBSZWNlaXZlciBhcyAvZGV2aWNlcy9wY2kwMDAwOjAwLzAwMDA6MDA6MTYuMC91c2I4
LzgtMy84LTM6MS4xL2lucHV0L2lucHV0Mw0KICBbICAgOTcuNDgzNzQ0XSBsb2dpdGVjaCAw
MDAzOjA0NkQ6QzUxNy4wMDAyOiBpbnB1dCxoaWRkZXYwLGhpZHJhdzE6IFVTQiBISUQgdjEu
MTAgTW91c2UgW0xvZ2l0ZWNoIFVTQiBSZWNlaXZlcl0gb24gdXNiLTAwMDA6MDA6MTYuMC0z
L2lucHV0MQ0KICBbICAgOTcuNTI3Nzk1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIHVzYmhpZA0KICBbICAgOTcuNTUxMTUwXSB1c2JoaWQ6IFVTQiBISUQg
Y29yZSBkcml2ZXINCiAgWyAgIDk3LjU3NDAwOV0geGVuOiByZWdpc3RlcmluZyBnc2kgMjIg
dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENCiAgWyAgIDk3LjU5NzQ4MV0geGVuOiAtLT4gcGly
cT0yMiAtPiBpcnE9MjIgKGdzaT0yMikNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjE6Mjld
IElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4OWEgLT4gSVJR
IDIyIE1vZGU6MSBBY3RpdmU6MSkNCiBbICAgOTcuNjQ5NDk2XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAzMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KICBbICAgOTcuNjczMDk3XSB4ZW46
IC0tPiBwaXJxPTMzIC0+IGlycT0zMyAoZ3NpPTMzKQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMToyOV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweGEy
IC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQogWyAgIDk3LjcyNTE3MV0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWF1ZGlvDQogIFsgICA5
Ny43NTA4MTddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25k
LXVhMTAxDQogIFsgICA5Ny43NzUzMzZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgc25kLXVzYi11c3gyeQ0KICBbICAgOTcuODAwODY2XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItY2FpYXENCiAgWyAgIDk3
LjgyNjM4OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQt
dXNiLTZmaXJlDQogIFsgICA5Ny44NTE0ODNdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVU
TElOSyB2MC4zMC4NCiAgWyAgIDk3Ljg3MjA2M10gbmZubF9hY2N0OiByZWdpc3RlcmluZyB3
aXRoIG5mbmV0bGluay4NCiAgWyAgIDk3Ljg5Mjk1MF0gbmZfY29ubnRyYWNrIHZlcnNpb24g
MC41LjAgKDczMDMgYnVja2V0cywgMjkyMTIgbWF4KQ0KICBbICAgOTcuOTE4NDUxXSBjdG5l
dGxpbmsgdjAuOTM6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KICBbICAgOTcuOTQx
Nzg5XSB4dF90aW1lOiBrZXJuZWwgdGltZXpvbmUgaXMgLTAwMDANCiAgWyAgIDk3Ljk2MTQ1
Nl0gaXBfc2V0OiBwcm90b2NvbCA2DQogIFsgICA5Ny45NzcxNjNdIElQVlM6IFJlZ2lzdGVy
ZWQgcHJvdG9jb2xzICgpDQogIFsgICA5Ny45OTYwNjFdIElQVlM6IENvbm5lY3Rpb24gaGFz
aCB0YWJsZSBjb25maWd1cmVkIChzaXplPTQwOTYsIG1lbW9yeT02NEtieXRlcykNCiAgWyAg
IDk4LjAyNDcwM10gSVBWUzogQ3JlYXRpbmcgbmV0bnMgc2l6ZT0xOTA0IGlkPTANCiAgWyAg
IDk4LjA0NDg4NF0gSVBWUzogaXB2cyBsb2FkZWQuDQogIFsgICA5OC4wNjA1OTldIGlwX3Rh
YmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtDQogIFsgICA5OC4wODMw
ODddIFRDUDogY3ViaWMgcmVnaXN0ZXJlZA0KICBbICAgOTguMDk5NDQ2XSBORVQ6IFJlZ2lz
dGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3DQogIFsgICA5OC4xMTkyMDNdIEJyaWRnZSBmaXJl
d2FsbGluZyByZWdpc3RlcmVkDQogIFsgICA5OC4xMzc0OTVdIEVidGFibGVzIHYyLjAgcmVn
aXN0ZXJlZA0KICBbICAgOTguMTU0NDg1XSBCbHVldG9vdGg6IFJGQ09NTSBUVFkgbGF5ZXIg
aW5pdGlhbGl6ZWQNCiAgWyAgIDk4LjE3NTIzOF0gQmx1ZXRvb3RoOiBSRkNPTU0gc29ja2V0
IGxheWVyIGluaXRpYWxpemVkDQogIFsgICA5OC4xOTY3MjhdIEJsdWV0b290aDogUkZDT01N
IHZlciAxLjExDQogIFsgICA5OC4yMTM5NzZdIEJsdWV0b290aDogQk5FUCAoRXRoZXJuZXQg
RW11bGF0aW9uKSB2ZXIgMS4zDQogIFsgICA5OC4yMzU4MDRdIEJsdWV0b290aDogQk5FUCBm
aWx0ZXJzOiBwcm90b2NvbCBtdWx0aWNhc3QNCiAgWyAgIDk4LjI1NzIwNF0gQmx1ZXRvb3Ro
OiBCTkVQIHNvY2tldCBsYXllciBpbml0aWFsaXplZA0KICBbICAgOTguMjc3Njc1XSBCbHVl
dG9vdGg6IEhJRFAgKEh1bWFuIEludGVyZmFjZSBFbXVsYXRpb24pIHZlciAxLjINCiAgWyAg
IDk4LjMwMTAyMl0gQmx1ZXRvb3RoOiBISURQIHNvY2tldCBsYXllciBpbml0aWFsaXplZA0K
ICBbICAgOTguMzIxNDk2XSBLZXkgdHlwZSBjZXBoIHJlZ2lzdGVyZWQNCiAgWyAgIDk4LjMz
Nzc0OF0gbGliY2VwaDogbG9hZGVkIChtb24vb3NkIHByb3RvIDE1LzI0LCBvc2RtYXAgNS82
IDUvNikNCiAgWyAgIDk4LjM2MzMzOF0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAx
DQogIFsgICA5OC4zODIyNDZdIGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQNCiAgWyAgIDk4
LjM5ODU5NV0gbmV0Y29uc29sZTogbmV0d29yayBsb2dnaW5nIHN0YXJ0ZWQNCiAgWyAgIDk4
LjQxNzY3Nl0gQUxTQSBkZXZpY2UgbGlzdDoNCiAgWyAgIDk4LjQzMTgyMV0gICAjMDogQy1N
ZWRpYSBDTUk4NzM4IChtb2RlbCA1NSkgYXQgMHhhODAwLCBpcnEgMjINCiAgWyAgIDk4LjQ1
NDUzM10gICAjMTogSEQtQXVkaW8gR2VuZXJpYyBhdCAweGY5OWZjMDAwIGlycSAxMzcNCiAg
WyAgIDk4LjQ3NjU5N10gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTA2OGsgZnJl
ZWQNCiAgWyAgIDk4LjQ5NzMyM10gV3JpdGUgcHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQt
b25seSBkYXRhOiAxNDMzNmsNCiAgWyAgIDk4LjUyNjgwN10gRnJlZWluZyB1bnVzZWQga2Vy
bmVsIG1lbW9yeTogMjY4ayBmcmVlZA0KICBbICAgOTguNTQ3MzA4XSBGcmVlaW5nIHVudXNl
ZCBrZXJuZWwgbWVtb3J5OiAyMjBrIGZyZWVkDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjEzXSAqKiogU2VyaWFsIGlucHV0IC0+IFhlbiAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1l
cyB0byBzd2l0Y2ggaW5wdXQgdG8gRE9NMCkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjox
NV0gR3Vlc3QgaW50ZXJydXB0IGluZm9ybWF0aW9uOg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE1XSAgICBJUlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAgdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjE1XSAgICBJUlE6ICAgMSBhZmZpbml0eTowMSB2ZWM6MzAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDE0IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6
ICAxKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAgMiBh
ZmZpbml0eTozZiB2ZWM6ZTIgdHlwZT1YVC1QSUMgICAgICAgICAgc3RhdHVzPTAwMDAwMDAw
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6
ICAgMyBhZmZpbml0eTowMSB2ZWM6MzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAg
ICBJUlE6ICAgNCBhZmZpbml0eTowMSB2ZWM6ZjEgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh
dHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE1XSAgICBJUlE6ICAgNSBhZmZpbml0eTowMSB2ZWM6NDAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE1XSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElD
LWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1J
Ty1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAgOCBhZmZpbml0eTowMSB2ZWM6NTgg
dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6ICA4KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJ
UlE6ICAgOSBhZmZpbml0eTowMSB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICA5KC0tLS0pLA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxMCBhZmZpbml0eTowMSB2ZWM6Njgg
dHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxMSBhZmZpbml0eTowMSB2
ZWM6NzAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxMiBhZmZpbml0
eTowMSB2ZWM6NzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZs
aWdodD0wIGRvbWFpbi1saXN0PTA6IDEyKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE1XSAgICBJUlE6ICAxMyBhZmZpbml0eTozZiB2ZWM6ODggdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNSBhZmZpbml0eTowMSB2ZWM6OTggdHlw
ZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNiBhZmZpbml0eTozZiB2ZWM6
ZDAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE1XSAgICBJUlE6ICAxNyBhZmZpbml0eTow
MSB2ZWM6MjEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdo
dD0wIGRvbWFpbi1saXN0PTA6IDE3KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE2XSAgICBJUlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6ZDggdHlwZT1JTy1BUElDLWxldmVs
ICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDE4KC0tLS0p
LA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAxOSBhZmZpbml0eToz
ZiB2ZWM6YTkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAyMiBhZmZp
bml0eTowMSB2ZWM6OWEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDIyKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICAyOSBhZmZpbml0eTowMSB2ZWM6MjkgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDI5
KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAzMCBhZmZp
bml0eTowMSB2ZWM6MzEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDMwKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICAzMSBhZmZpbml0eTowMSB2ZWM6MzkgdHlwZT1JTy1BUElD
LWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDMx
KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAzMiBhZmZp
bml0eTozZiB2ZWM6OTkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICAz
MyBhZmZpbml0eTozZiB2ZWM6YTIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJ
UlE6ICA0MCBhZmZpbml0eTowMSB2ZWM6NDkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2
XSAgICBJUlE6ICA0NiBhZmZpbml0eTozZiB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE2XSAgICBJUlE6ICA0NyBhZmZpbml0eTowMSB2ZWM6OTIgdHlwZT1JTy1BUElDLWxl
dmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDQ3KC0t
LS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA0OCBhZmZpbml0
eTowMSB2ZWM6NDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1MSBh
ZmZpbml0eTozZiB2ZWM6YzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6
ICA1MiBhZmZpbml0eTozZiB2ZWM6YjggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAg
ICBJUlE6ICA1MyBhZmZpbml0eTozZiB2ZWM6YzAgdHlwZT1JTy1BUElDLWxldmVsICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE2XSAgICBJUlE6ICA1NCBhZmZpbml0eTozZiB2ZWM6YzggdHlwZT1JTy1BUElDLWxldmVs
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9N
TVUtTVNJICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1NyBhZmZpbml0eTozZiB2ZWM6YTAgdHlwZT1I
UEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1OCBhZmZpbml0eTozZiB2ZWM6YTgg
dHlwZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA1OSBhZmZpbml0eTozZiB2
ZWM6YjAgdHlwZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2MCBhZmZpbml0
eTozZiB2ZWM6NTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2MSBh
ZmZpbml0eTozZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6
ICA2MiBhZmZpbml0eTozZiB2ZWM6NjEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAg
ICBJUlE6ICA2MyBhZmZpbml0eTozZiB2ZWM6NjkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjE2XSAgICBJUlE6ICA2NCBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1QQ0ktTVNJICAgICAg
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE2XSAgICBJUlE6ICA2NSBhZmZpbml0eTozZiB2ZWM6NzkgdHlwZT1QQ0ktTVNJ
ICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6ODEgdHlwZT1Q
Q0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2NyBhZmZpbml0eTozZiB2ZWM6ODkg
dHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2OCBhZmZpbml0eTozZiB2
ZWM6OTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA2OSBhZmZpbml0
eTozZiB2ZWM6YzEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA3MCBh
ZmZpbml0eTozZiB2ZWM6ZDEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6
ICA3MSBhZmZpbml0eTowMSB2ZWM6ZDkgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MzAwKC0tLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE2XSAgICBJUlE6ICA3MiBhZmZpbml0eTowMSB2ZWM6MjIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjk5KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3MyBhZmZpbml0eTowMSB2ZWM6MmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk4KC0tLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA3NCBhZmZpbml0eTowMSB2ZWM6MzIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjk3KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3NSBhZmZpbml0eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk2KC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA3NiBhZmZpbml0eTowMSB2ZWM6NDIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjk1KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3NyBhZmZpbml0eTowMSB2ZWM6NGEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk0KC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA3OCBhZmZpbml0eTowMSB2ZWM6NTIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6MjkzKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA3OSBhZmZpbml0eTowMSB2ZWM6NWEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA4MCBhZmZpbml0eTowMSB2ZWM6NjIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6MjkxKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA4MSBhZmZpbml0eTowMSB2ZWM6NmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkwKC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA4MiBhZmZpbml0eTowMSB2ZWM6NzIgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjg5KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA4MyBhZmZpbml0eTowMSB2ZWM6N2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg4KC1TLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6ICA4NCBhZmZpbml0eTowMSB2ZWM6OGEgdHlw
ZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1s
aXN0PTA6Mjg3KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE3XSAgICBJUlE6
ICA4NSBhZmZpbml0eTowMSB2ZWM6YWEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAw
MDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg2KC0tLS0pLA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjE3XSBJTy1BUElDIGludGVycnVwdCBpbmZvcm1hdGlvbjoNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgMCBWZWMyNDA6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICAyOiB2ZWM9ZjAg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1F
IG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElS
USAgMSBWZWMgNDg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMg
MHgwMCwgUGluICAxOiB2ZWM9MzAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoxN10gICAgIElSUSAgMyBWZWMgNTY6DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICAzOiB2ZWM9MzggZGVsaXZlcnk9TG9Q
cmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0
X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgNCBWZWMyNDE6
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA0
OiB2ZWM9ZjEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJy
PTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjox
N10gICAgIElSUSAgNSBWZWMgNjQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAg
ICAgIEFwaWMgMHgwMCwgUGluICA1OiB2ZWM9NDAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgNiBWZWMgNzI6DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA2OiB2ZWM9NDggZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1h
c2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAg
NyBWZWMgODA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgw
MCwgUGluICA3OiB2ZWM9NTAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFy
aXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoxN10gICAgIElSUSAgOCBWZWMgODg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA4OiB2ZWM9NTggZGVsaXZlcnk9TG9Qcmkg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lk
OjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAgOSBWZWMgOTY6DQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluICA5OiB2
ZWM9NjAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAg
dHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxN10g
ICAgIElSUSAxMCBWZWMxMDQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTddICAgICAg
IEFwaWMgMHgwMCwgUGluIDEwOiB2ZWM9NjggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1
cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoxN10gICAgIElSUSAxMSBWZWMxMTI6DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MTddICAgICAgIEFwaWMgMHgwMCwgUGluIDExOiB2ZWM9NzAgZGVsaXZl
cnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9
MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAxMiBW
ZWMxMjA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMCwg
UGluIDEyOiB2ZWM9NzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5
PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoxOF0gICAgIElSUSAxMyBWZWMxMzY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MThdICAgICAgIEFwaWMgMHgwMCwgUGluIDEzOiB2ZWM9ODggZGVsaXZlcnk9TG9QcmkgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MSBkZXN0X2lkOjYz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICBJUlEgMTQgVmVjMTQ0Og0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNDogdmVj
PTkwIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRy
aWc9RSBtYXNrPTAgZGVzdF9pZDoxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAg
ICBJUlEgMTUgVmVjMTUyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgICBB
cGljIDB4MDAsIFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9
MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MThdICAgICBJUlEgMTYgVmVjMjA4Og0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjE4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNjogdmVjPWQwIGRlbGl2ZXJ5
PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEg
ZGVzdF9pZDo2Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDE3IFZl
YyAzMzoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAwLCBQ
aW4gMTc6IHZlYz0yMSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9
MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjE4XSAgICAgSVJRIDE4IFZlYzIxNjoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjox
OF0gICAgICAgQXBpYyAweDAwLCBQaW4gMTg6IHZlYz1kOCBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDE5IFZlYzE2OToNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAwLCBQaW4gMTk6IHZlYz1h
OSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAg
IElSUSAyMiBWZWMxNTQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFw
aWMgMHgwMCwgUGluIDIyOiB2ZWM9OWEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAyOSBWZWMgNDE6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGluICA1OiB2ZWM9MjkgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBk
ZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAzMCBWZWMg
NDk6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGlu
ICA2OiB2ZWM9MzEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoxOF0gICAgIElSUSAzMSBWZWMgNTc6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThd
ICAgICAgIEFwaWMgMHgwMSwgUGluICA3OiB2ZWM9MzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSAzMiBWZWMxNTM6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGluICA4OiB2ZWM9OTkg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICBJ
UlEgMzMgVmVjMTYyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgICBBcGlj
IDB4MDEsIFBpbiAgOTogdmVjPWEyIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBw
b2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDQwIFZlYyA3MzoNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAxLCBQaW4gMTY6IHZlYz00OSBkZWxpdmVyeT1M
b1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRl
c3RfaWQ6MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDQ2IFZlYzE4
NToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAxLCBQaW4g
MjI6IHZlYz1iOSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBp
cnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoxOF0gICAgIElSUSA0NyBWZWMxNDY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThd
ICAgICAgIEFwaWMgMHgwMSwgUGluIDIzOiB2ZWM9OTIgZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElSUSA0OCBWZWMgNjU6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9NDEg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1M
IG1hc2s9MSBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgIElS
USA1MSBWZWMyMDE6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MThdICAgICAgIEFwaWMg
MHgwMSwgUGluIDI3OiB2ZWM9YzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MThdICAgICBJUlEgNTIgVmVjMTg0Og0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjE4XSAgICAgICBBcGljIDB4MDEsIFBpbiAyODogdmVjPWI4IGRlbGl2ZXJ5PUxv
UHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVz
dF9pZDo2Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjE4XSAgICAgSVJRIDUzIFZlYzE5
MjoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoxOF0gICAgICAgQXBpYyAweDAxLCBQaW4g
Mjk6IHZlYz1jMCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBp
cnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoxOF0gICAgIElSUSA1NCBWZWMyMDA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MTld
ICAgICAgIEFwaWMgMHgwMSwgUGluIDMwOiB2ZWM9YzggZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICdoJyBwcmVzc2VkIC0+IHNob3dpbmcgaW5z
dGFsbGVkIGhhbmRsZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJyUn
IChhc2NpaSAnMjUnKSA9PiB0cmFwIHRvIHhlbmRiZw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjIwXSAga2V5ICcqJyAoYXNjaWkgJzJhJykgPT4gcHJpbnQgYWxsIGRpYWdub3N0aWNz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJzAnIChhc2NpaSAnMzAnKSA9
PiBkdW1wIERvbTAgcmVnaXN0ZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBr
ZXkgJ0EnIChhc2NpaSAnNDEnKSA9PiB0b2dnbGUgYWx0ZXJuYXRpdmUga2V5IGhhbmRsaW5n
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ0gnIChhc2NpaSAnNDgnKSA9
PiBkdW1wIGhlYXAgaW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdJ
JyAoYXNjaWkgJzQ5JykgPT4gZHVtcCBIVk0gaXJxIGluZm8NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoyMF0gIGtleSAnTScgKGFzY2lpICc0ZCcpID0+IGR1bXAgTVNJIHN0YXRlDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ04nIChhc2NpaSAnNGUnKSA9PiB0
cmlnZ2VyIGFuIE5NSQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdPJyAo
YXNjaWkgJzRmJykgPT4gdG9nZ2xlIHNoYWRvdyBhdWRpdHMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoyMF0gIGtleSAnUScgKGFzY2lpICc1MScpID0+IGR1bXAgUENJIGRldmljZXMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMF0gIGtleSAnUicgKGFzY2lpICc1MicpID0+
IHJlYm9vdCBtYWNoaW5lDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ1Mn
IChhc2NpaSAnNTMnKSA9PiByZXNldCBzaGFkb3cgcGFnZXRhYmxlcw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjIwXSAga2V5ICdhJyAoYXNjaWkgJzYxJykgPT4gZHVtcCB0aW1lciBx
dWV1ZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMF0gIGtleSAnYycgKGFzY2lpICc2
MycpID0+IGR1bXAgQUNQSSBDeCBzdHJ1Y3R1cmVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MjBdICBrZXkgJ2QnIChhc2NpaSAnNjQnKSA9PiBkdW1wIHJlZ2lzdGVycw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdlJyAoYXNjaWkgJzY1JykgPT4gZHVtcCBl
dnRjaG4gaW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdnJyAoYXNj
aWkgJzY3JykgPT4gcHJpbnQgZ3JhbnQgdGFibGUgdXNhZ2UNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjoyMF0gIGtleSAnaCcgKGFzY2lpICc2OCcpID0+IHNob3cgdGhpcyBtZXNzYWdl
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ2knIChhc2NpaSAnNjknKSA9
PiBkdW1wIGludGVycnVwdCBiaW5kaW5ncw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIw
XSAga2V5ICdtJyAoYXNjaWkgJzZkJykgPT4gbWVtb3J5IGluZm8NCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMF0gIGtleSAnbicgKGFzY2lpICc2ZScpID0+IE5NSSBzdGF0aXN0aWNz
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ28nIChhc2NpaSAnNmYnKSA9
PiBkdW1wIGlvbW11IHAybSB0YWJsZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAg
a2V5ICdxJyAoYXNjaWkgJzcxJykgPT4gZHVtcCBkb21haW4gKGFuZCBndWVzdCBkZWJ1Zykg
aW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIwXSAga2V5ICdyJyAoYXNjaWkgJzcy
JykgPT4gZHVtcCBydW4gcXVldWVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBr
ZXkgJ3MnIChhc2NpaSAnNzMnKSA9PiBkdW1wIHNvZnR0c2Mgc3RhdHMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjoyMF0gIGtleSAndCcgKGFzY2lpICc3NCcpID0+IGRpc3BsYXkgbXVs
dGktY3B1IGNsb2NrIGluZm8NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMF0gIGtleSAn
dScgKGFzY2lpICc3NScpID0+IGR1bXAgbnVtYSBpbmZvDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MjBdICBrZXkgJ3YnIChhc2NpaSAnNzYnKSA9PiBkdW1wIEFNRC1WIFZNQ0JzDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ3cnIChhc2NpaSAnNzcnKSA9PiBz
eW5jaHJvbm91c2x5IGR1bXAgY29uc29sZSByaW5nIGJ1ZmZlciAoZG1lc2cpDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MjBdICBrZXkgJ3onIChhc2NpaSAnN2EnKSA9PiBwcmludCBp
b2FwaWMgaW5mbw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSBudW1iZXIgb2YgTVAg
SVJRIHNvdXJjZXM6IDE1Lg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSBudW1iZXIg
b2YgSU8tQVBJQyAjNiByZWdpc3RlcnM6IDI0Lg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjIyXSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3RlcnM6IDMyLg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjIyXSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gSU8gQVBJQyAjNi4uLi4uLg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSAuLi4uIHJlZ2lzdGVyICMwMDogMDYwMDAw
MDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gLi4uLi4uLiAgICA6IHBoeXNpY2Fs
IEFQSUMgaWQ6IDA2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4uLi4gICAg
OiBEZWxpdmVyeSBUeXBlOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJd
IC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjIyXSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDE3DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVk
OiAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4uLi4gICAgIDogSU8gQVBJ
QyB2ZXJzaW9uOiAwMDIxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjJdIC4uLi4gcmVn
aXN0ZXIgIzAyOiAwNjAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIyXSAuLi4u
Li4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIy
XSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyMl0gLi4uLi4uLiAgICAgOiBCb290IERUICAgIDogMA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjIyXSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0
IERlbGkgVmVjdDogICANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDAwIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgMzANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDAyIDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyMl0gIDAzIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
MzgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA0IDAwMSAwMSAgMCAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
Ml0gIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAw
ICAgMCAgICAxICAgIDEgICAgNDgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA3
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyMl0gIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgNTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDA5IDAwMSAw
MSAgMCAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNjANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNjgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDBiIDAwMSAwMSAgMCAg
ICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyMl0gIDBjIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NzgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDBkIDAzRiAwRiAgMSAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
Ml0gIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgOTANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAw
ICAgMCAgICAxICAgIDEgICAgOTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDEw
IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgRDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyMl0gIDExIDAwMSAwMSAgMCAgICAxICAgIDAgICAxICAgMCAg
ICAxICAgIDEgICAgMjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDEyIDAwMSAw
MSAgMCAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgRDgNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyMl0gIDEzIDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAg
IDEgICAgQTkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyMl0gIDE0IDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE2IDAwMSAwMSAgMCAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgOUENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gSU8gQVBJQyAjNy4uLi4uLg0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjIzXSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoyM10gLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA3DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgOiBEZWxpdmVy
eSBUeXBlOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgOiBM
VFMgICAgICAgICAgOiAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4gcmVn
aXN0ZXIgIzAxOiAwMDFGODAyMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIzXSAuLi4u
Li4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDFGDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9u
OiAwMDIxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIC4uLi4gcmVnaXN0ZXIgIzAy
OiAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIzXSAuLi4uLi4uICAgICA6
IGFyYml0cmF0aW9uOiAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjIzXSAuLi4uIElS
USByZWRpcmVjdGlvbiB0YWJsZToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIE5S
IExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDAx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDAyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDAzIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDA1IDAwMSAwMSAgMCAg
ICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgMjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDA2IDAwMSAwMSAgMCAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAg
MzENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDA3IDAwMSAwMSAgMCAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgMzkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDA4IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgOTkNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDA5IDAzRiAwRiAgMSAgICAxICAgIDAgICAx
ICAgMCAgICAxICAgIDEgICAgQTINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDBh
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDBiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDBjIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDBlIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDEwIDAwMSAwMSAgMSAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgNDkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDEz
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE1IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDE2IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAg
IDEgICAgQjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE3IDAwMSAwMSAgMCAg
ICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgOTINCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjoyM10gIDE4IDAwMSAwMSAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAg
NDENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDE5IDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoy
M10gIDFhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDFiIDAzRiAwRiAgMSAgICAxICAgIDAgICAx
ICAgMCAgICAxICAgIDEgICAgQzkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDFj
IDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgQjgNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjoyM10gIDFkIDAzRiAwRiAgMSAgICAxICAgIDAgICAxICAgMCAg
ICAxICAgIDEgICAgQzANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gIDFlIDAzRiAw
RiAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgQzgNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyM10gIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gVXNpbmcgdmVjdG9yLWJh
c2VkIGluZGV4aW5nDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIElSUSB0byBwaW4g
bWFwcGluZ3M6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIElSUTI0MCAtPiAwOjIN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyM10gSVJRNDggLT4gMDoxDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MjNdIElSUTU2IC0+IDA6Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjIzXSBJUlEyNDEgLT4gMDo0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjNdIElS
UTY0IC0+IDA6NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlE3MiAtPiAwOjYN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRODAgLT4gMDo3DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MjRdIElSUTg4IC0+IDA6OA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjI0XSBJUlE5NiAtPiAwOjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJR
MTA0IC0+IDA6MTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMTEyIC0+IDA6
MTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMTIwIC0+IDA6MTINCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMTM2IC0+IDA6MTMNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjoyNF0gSVJRMTQ0IC0+IDA6MTQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyNF0gSVJRMTUyIC0+IDA6MTUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJR
MjA4IC0+IDA6MTYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRMzMgLT4gMDox
Nw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlEyMTYgLT4gMDoxOA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlExNjkgLT4gMDoxOQ0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjI0XSBJUlExNTQgLT4gMDoyMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjI0XSBJUlE0MSAtPiAxOjUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoyNF0gSVJRNDkg
LT4gMTo2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjRdIElSUTU3IC0+IDE6Nw0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlExNTMgLT4gMTo4DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MjRdIElSUTE2MiAtPiAxOjkNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyNF0gSVJRNzMgLT4gMToxNg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlEx
ODUgLT4gMToyMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlExNDYgLT4gMToy
Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI0XSBJUlE2NSAtPiAxOjI0DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MjRdIElSUTIwMSAtPiAxOjI3DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MjRdIElSUTE4NCAtPiAxOjI4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MjRdIElSUTE5MiAtPiAxOjI5DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjRdIElSUTIw
MCAtPiAxOjMwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjRdIC4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25lLg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjI2XSBnbnR0YWJfdXNhZ2VfcHJpbnRfYWxsIFsga2V5ICdnJyBwcmVzc2VkDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MjZdICAgICAgIC0tLS0tLS0tIGFjdGl2ZSAtLS0tLS0tLSAg
ICAgICAtLS0tLS0tLSBzaGFyZWQgLS0tLS0tLS0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjoyNl0gW3JlZl0gbG9jYWxkb20gbWZuICAgICAgcGluICAgICAgICAgIGxvY2FsZG9tIGdt
Zm4gICAgIGZsYWdzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MjZdIGdyYW50LXRhYmxl
IGZvciByZW1vdGUgZG9tYWluOiAgICAwIC4uLiBubyBhY3RpdmUgZ3JhbnQgdGFibGUgZW50
cmllcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI2XSBnbnR0YWJfdXNhZ2VfcHJpbnRf
YWxsIF0gZG9uZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjI5XSAqKioqKioqKioqKiBW
TUNCIEFyZWFzICoqKioqKioqKioqKioqDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6Mjld
ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzJdIFBoeXNpY2FsIG1lbW9yeSBpbmZvcm1hdGlvbjoNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjozMl0gICAgIFhlbiBoZWFwOiAwa0IgZnJlZQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsxNF06IDY0NTEya0IgZnJlZQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsxNV06IDEzMTA3MmtCIGZyZWUNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozMl0gICAgIGhlYXBbMTZdOiAyNjIxNDRrQiBmcmVl
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzJdICAgICBoZWFwWzE3XTogNTI0Mjg4a0Ig
ZnJlZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsxOF06IDEwNDg1
NzZrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzJdICAgICBoZWFwWzE5XTog
NzgzMjg4a0IgZnJlZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjMyXSAgICAgaGVhcFsy
MF06IDQxOTQzMDRrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzJdICAgICBo
ZWFwWzIxXTogMjMyNDE2a0IgZnJlZQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjMyXSAg
ICAgRG9tIGhlYXA6IDcyNDA2MDBrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzRdICcqJyBwcmVzc2VkIC0+IGZpcmluZyBhbGwgZGlhZ25vc3RpYyBrZXloYW5kbGVycw0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM0XSBbZDogZHVtcCByZWdpc3RlcnNdDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzRdICdkJyBwcmVzc2VkIC0+IGR1bXBpbmcgcmVnaXN0
ZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdIA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM0XSAqKiogRHVtcGluZyBDUFUwIGhvc3Qgc3RhdGU6ICoqKg0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM0XSAtLS0tWyBYZW4tNC4zLXVuc3RhYmxlICB4ODZfNjQgIGRl
YnVnPXkgIFRhaW50ZWQ6ICAgIEMgXS0tLS0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
NF0gQ1BVOiAgICAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdIFJJUDogICAgZTAw
ODpbPGZmZmY4MmM0YzAxNTk1Njc+XSBkZWZhdWx0X2lkbGUrMHg4Ni8weDhiDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzRdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIENPTlRF
WFQ6IGh5cGVydmlzb3INCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNF0gcmF4OiBmZmZm
ODJjNGMwMzExMGYwICAgcmJ4OiBmZmZmODJjNGMwMmI4MDAwICAgcmN4OiAwMDAwMDAwMDAw
MDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdIHJkeDogMDAwMDAwMDAwMDAw
MDAwMCAgIHJzaTogZmZmZjgyYzRjMDMxMWI4MCAgIHJkaTogMDAwMDAwMDAwMDAwMDAwMA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM0XSByYnA6IGZmZmY4MmM0YzAyYmZlZTAgICBy
c3A6IGZmZmY4MmM0YzAyYmZlZTAgICByODogIGZmZmY4MzAyNDdiY2MwYjgNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjozNF0gcjk6ICBmZmZmODMwMGFmZjg5MDYwICAgcjEwOiBmZmZm
ODMwMjQ3YmNhMjQwICAgcjExOiAwMDAwMDAyNjBhMzA4MTY3DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzRdIHIxMjogZmZmZjgyYzRjMDI2MjE4MCAgIHIxMzogZmZmZjgyYzRjMDJi
ODAwMCAgIHIxNDogMDAwMDAwMDBmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM0XSByMTU6IGZmZmY4MmM0YzAzMTEwNDggICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBj
cjQ6IDAwMDAwMDAwMDAwMDA2ZjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNF0gY3Iz
OiAwMDAwMDAwMjQxZTBjMDAwICAgY3IyOiAwMDAwN2ZhZTBjNmY2MDAwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MzRdIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdz
OiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM0XSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgyYzRjMDJiZmVlMDoNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNF0gICAgZmZmZjgyYzRjMDJiZmYxMCBmZmZmODJjNGMw
MTVjMzE0IDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDBhZmFmZTAwMA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM0XSAgICBmZmZmODMwMGFmZjg5MDAwIDAwMDAwMDAwMDAwMDAwMDAg
ZmZmZjgyYzRjMDJiZmQ3OCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzRdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWY5YTBjMCBmZmZmZmZm
ZjgxZWRhMWQ4IGZmZmZmZmZmODFlMDFlNzgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
NF0gICAgZmZmZmZmZmY4MWUwMDAxMCAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM0XSAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYSAwMDAw
MDAwMDAwMDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzRdICAgIDAwMDAwMDAw
ZGVhZGJlZWYgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDEwMDAwMDAwMDAwIGZmZmZmZmZmODEw
MDEzYWENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgMDAwMDAwMDAwMDAwZTAz
MyAwMDAwMDAwMDAwMDAwMjQ2IGZmZmZmZmZmODFlMDFlNjAgMDAwMDAwMDAwMDAwZTAyYg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDBhZmFm
ZTAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjozNV0gWGVuIGNhbGwgdHJhY2U6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MzVdICAgIFs8ZmZmZjgyYzRjMDE1OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4OGIN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgWzxmZmZmODJjNGMwMTVjMzE0Pl0g
aWRsZV9sb29wKzB4NjUvMHg3Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gKioqIER1bXBpbmcgQ1BVMSBob3N0IHN0
YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gLS0tLVsgWGVuLTQuMy11
bnN0YWJsZSAgeDg2XzY0ICBkZWJ1Zz15ICBUYWludGVkOiAgICBDIF0tLS0tDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzVdIENQVTogICAgMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM1XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9pZGxl
KzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBSRkxBR1M6IDAwMDAw
MDAwMDAwMDAyNDYgICBDT05URVhUOiBoeXBlcnZpc29yDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzVdIHJheDogZmZmZjgyYzRjMDMxMTBmMCAgIHJieDogZmZmZjgzMDI0N2JmMDAw
MCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1
XSByZHg6IDAwMDAwMDNkODc4ZWQwMDAgICByc2k6IGZmZmY4MzAyNDdiZmViODAgICByZGk6
IDAwMDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gcmJwOiBm
ZmZmODMwMjQ3YmY3ZWUwICAgcnNwOiBmZmZmODMwMjQ3YmY3ZWUwICAgcjg6ICBmZmZmODMw
MjQ3YmQ1YmQ4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdIHI5OiAgZmZmZjgzMDBh
ZmY4ODA2MCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAwMDAwMDAwMDI0
Ng0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSByMTI6IGZmZmY4MmM0YzAyNjIxODAg
ICByMTM6IGZmZmY4MzAyNDdiZjAwMDAgICByMTQ6IDAwMDAwMDAwZmZmZmZmZmYNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNV0gcjE1OiBmZmZmODMwMjQ3YmZlMDQ4ICAgY3IwOiAw
MDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzVdIGNyMzogMDAwMDAwMDIzZDhjZTAwMCAgIGNyMjogMDAwMDdmN2Ey
NTZkZDgyMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBkczogMDAyYiAgIGVzOiAw
MDJiICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDEwICAgY3M6IGUwMDgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNV0gWGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4
MzAyNDdiZjdlZTA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIGZmZmY4MzAy
NDdiZjdmMTAgZmZmZjgyYzRjMDE1YzMxNCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAwYWZk
MTMwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgZmZmZjgzMDBhZmY4ODAw
MCAwMDAwMDAwMDAwMDAwMDAxIGZmZmY4MzAyNDdiZjdkNzggMDAwMDAwMDAwMDAwMDAwMA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgZmZmZmZmZmY4MWVkYTFkOCBmZmZmODgwMDNhMjMxZjEwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIGZmZmY4ODAwM2EyMzAwMTAgMDAwMDAwMDAwMDAw
MDI0NiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjozNV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmZmZmZmODEwMDEzYWEgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM1XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAxMDAw
MDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVd
ICAgIDAwMDAwMDAwMDAwMGUwMzMgMDAwMDAwMDAwMDAwMDI0NiBmZmZmODgwMDNhMjMxZWY4
IDAwMDAwMDAwMDAwMGUwMmINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gICAgMzgz
MjNhMzAzNDNhMzAzMSAzYTM1MzE0ZDU2NDgyMDVkIDYxNmY0YzIwNGQ1NjQ4MjAgNGU0NTU4
MjgwYTcyNjU2NA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICAyZDMzMzEzMDAw
MDAwMDAxIGZmZmY4MzAwYWZkMTMwMDAgMDAwMDAwM2Q4NzhlZDAwMCA0NDIwM2EzNTMxNGQ1
NjQ4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdIFhlbiBjYWxsIHRyYWNlOg0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSAgICBbPGZmZmY4MmM0YzAxNTk1Njc+XSBkZWZh
dWx0X2lkbGUrMHg4Ni8weDhiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdICAgIFs8
ZmZmZjgyYzRjMDE1YzMxND5dIGlkbGVfbG9vcCsweDY1LzB4NzMNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjozNV0gICAgDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdICoqKiBE
dW1waW5nIENQVTIgaG9zdCBzdGF0ZTogKioqDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzVdIC0tLS1bIFhlbi00LjMtdW5zdGFibGUgIHg4Nl82NCAgZGVidWc9eSAgVGFpbnRlZDog
ICAgQyBdLS0tLQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBDUFU6ICAgIDINCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzRjMDE1
OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4OGINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNV0gUkZMQUdTOiAwMDAwMDAwMDAwMDAwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSByYXg6IGZmZmY4MmM0YzAzMTEwZjAgICBy
Yng6IGZmZmY4MzAyNDdiZTAwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDINCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjozNV0gcmR4OiAwMDAwMDAzZDg3OGRlMDAwICAgcnNpOiBmZmZm
ODMwMjQ3YmVmYjgwICAgcmRpOiAwMDAwMDAwMDAwMDAwMDAyDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzVdIHJicDogZmZmZjgzMDI0N2JlN2VlMCAgIHJzcDogZmZmZjgzMDI0N2Jl
N2VlMCAgIHI4OiAgZmZmZjgzMDI0N2JlZTAyOA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM1XSByOTogIGZmZmY4MzAwYWZkMTcwNjAgICByMTA6IDAwMDAwMDAwZGVhZGJlZWYgICBy
MTE6IDAwMDAwMDAwMDAwMDAyNDYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNV0gcjEy
OiBmZmZmODJjNGMwMjYyMTgwICAgcjEzOiBmZmZmODMwMjQ3YmUwMDAwICAgcjE0OiAwMDAw
MDAwMGZmZmZmZmZmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzVdIHIxNTogZmZmZjgz
MDI0N2JlZjA0OCAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAw
MDZmMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM1XSBjcjM6IDAwMDAwMDAyNDFlMGMw
MDAgICBjcjI6IDAwMDAwMDAwMDAyMGRiZjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
Nl0gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAx
MCAgIGNzOiBlMDA4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIFhlbiBzdGFjayB0
cmFjZSBmcm9tIHJzcD1mZmZmODMwMjQ3YmU3ZWUwOg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM2XSAgICBmZmZmODMwMjQ3YmU3ZjEwIGZmZmY4MmM0YzAxNWMzMTQgMDAwMDAwMDAw
MDAwMDAwMCBmZmZmODMwMGFmZDEyMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZd
ICAgIGZmZmY4MzAwYWZkMTcwMDAgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODMwMjQ3YmU3ZDc4
IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlZGExZDggZmZmZjg4
MDAzYTIzM2YxMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAgICBmZmZmODgwMDNh
MjMyMDEwIDAwMDAwMDAwMDAwMDAyNDYgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhIDAwMDAwMDAwMDAwMDAwMDENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDAw
MGRlYWRiZWVmIDAwMDAwMTAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM2XSAgICAwMDAwMDAwMDAwMDBlMDMzIDAwMDAwMDAwMDAwMDAy
NDYgZmZmZjg4MDAzYTIzM2VmOCAwMDAwMDAwMDAwMDBlMDJiDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDBiMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNl0gICAgMDAwMDAwMDAwMDAwMDAwMiBmZmZmODMwMGFmZDEyMDAwIDAwMDAwMDNkODc4
ZGUwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSBY
ZW4gY2FsbCB0cmFjZToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgWzxmZmZm
ODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9pZGxlKzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjM2XSAgICBbPGZmZmY4MmM0YzAxNWMzMTQ+XSBpZGxlX2xvb3ArMHg2NS8w
eDczDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjM2XSAqKiogRHVtcGluZyBDUFUzIGhvc3Qgc3RhdGU6ICoqKg0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM2XSAtLS0tWyBYZW4tNC4zLXVuc3RhYmxlICB4ODZfNjQg
IGRlYnVnPXkgIFRhaW50ZWQ6ICAgIEMgXS0tLS0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNl0gQ1BVOiAgICAzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIFJJUDogICAg
ZTAwODpbPGZmZmY4MmM0YzAxNTk1Njc+XSBkZWZhdWx0X2lkbGUrMHg4Ni8weDhiDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIENP
TlRFWFQ6IGh5cGVydmlzb3INCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gcmF4OiBm
ZmZmODJjNGMwMzExMGYwICAgcmJ4OiBmZmZmODMwMjQ3Yjc4MDAwICAgcmN4OiAwMDAwMDAw
MDAwMDAwMDAzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIHJkeDogMDAwMDAwM2Q4
NzhkNzAwMCAgIHJzaTogZmZmZjgzMDI0N2JlOGI4MCAgIHJkaTogMDAwMDAwMDAwMDAwMDAw
Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSByYnA6IGZmZmY4MzAyNDdiN2ZlZTAg
ICByc3A6IGZmZmY4MzAyNDdiN2ZlZTAgICByODogIGZmZmY4MzAyNDdiZWU0MTgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozNl0gcjk6ICBmZmZmODMwMGFmZDE2MDYwICAgcjEwOiAw
MDAwMDAwMGRlYWRiZWVmICAgcjExOiAwMDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzZdIHIxMjogZmZmZjgyYzRjMDI2MjE4MCAgIHIxMzogZmZmZjgzMDI0
N2I3ODAwMCAgIHIxNDogMDAwMDAwMDBmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM2XSByMTU6IGZmZmY4MzAyNDdiZTgwNDggICBjcjA6IDAwMDAwMDAwODAwNTAwM2Ig
ICBjcjQ6IDAwMDAwMDAwMDAwMDA2ZjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0g
Y3IzOiAwMDAwMDAwMjQxZTBjMDAwICAgY3IyOiAwMDAwN2ZhZTBjNmY2MDAwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzZdIGRzOiAwMDJiICAgZXM6IDAwMmIgICBmczogMDAwMCAg
IGdzOiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM2XSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDI0N2I3ZmVlMDoNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgZmZmZjgzMDI0N2I3ZmYxMCBmZmZmODJj
NGMwMTVjMzE0IDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDBhZmFmZDAwMA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM2XSAgICBmZmZmODMwMGFmZDE2MDAwIDAwMDAwMDAwMDAwMDAw
MDMgZmZmZjgzMDI0N2I3ZmQ3OCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZm
ZmZmZjgxZWRhMWQ4IGZmZmY4ODAwM2EyMzVmMTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozNl0gICAgZmZmZjg4MDAzYTIzNDAxMCAwMDAwMDAwMDAwMDAwMjQ2IDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAg
ICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYSAw
MDAwMDAwMDAwMDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIDAwMDAw
MDAwZGVhZGJlZWYgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDEwMDAwMDAwMDAwIGZmZmZmZmZm
ODEwMDEzYWENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgMDAwMDAwMDAwMDAw
ZTAzMyAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4ODAwM2EyMzVlZjggMDAwMDAwMDAwMDAwZTAy
Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzZdICAgIDAwMDAwMDAwMDAwMDAwMDMgZmZmZjgzMDBh
ZmFmZDAwMCAwMDAwMDAzZDg3OGQ3MDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozNl0gWGVuIGNhbGwgdHJhY2U6DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzZdICAgIFs8ZmZmZjgyYzRjMDE1OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4
OGINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gICAgWzxmZmZmODJjNGMwMTVjMzE0
Pl0gaWRsZV9sb29wKzB4NjUvMHg3Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM2XSAg
ICANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gKioqIER1bXBpbmcgQ1BVNCBob3N0
IHN0YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozNl0gLS0tLVsgWGVuLTQu
My11bnN0YWJsZSAgeDg2XzY0ICBkZWJ1Zz15ICBUYWludGVkOiAgICBDIF0tLS0tDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzZdIENQVTogICAgNA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM2XSBSSVA6ICAgIGUwMDg6WzxmZmZmODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9p
ZGxlKzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBSRkxBR1M6IDAw
MDAwMDAwMDAwMDAyNDYgICBDT05URVhUOiBoeXBlcnZpc29yDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6MzddIHJheDogZmZmZjgyYzRjMDMxMTBmMCAgIHJieDogZmZmZjgzMDI0N2I2
ODAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwNA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM3XSByZHg6IDAwMDAwMDNkODc4NjEwMDAgICByc2k6IGZmZmY4MzAyNDdiNzJiODAgICBy
ZGk6IDAwMDAwMDAwMDAwMDAwMDQNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gcmJw
OiBmZmZmODMwMjQ3YjZmZWUwICAgcnNwOiBmZmZmODMwMjQ3YjZmZWUwICAgcjg6ICBmZmZm
ODMwMjQ3YmVlODQ4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIHI5OiAgZmZmZjgz
MDBhZmQxNTA2MCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAwMDAwMDAw
MDI0Ng0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSByMTI6IGZmZmY4MmM0YzAyNjIx
ODAgICByMTM6IGZmZmY4MzAyNDdiNjgwMDAgICByMTQ6IDAwMDAwMDAwZmZmZmZmZmYNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gcjE1OiBmZmZmODMwMjQ3YjcyMDQ4ICAgY3Iw
OiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6MzddIGNyMzogMDAwMDAwMDI0MWUwYzAwMCAgIGNyMjogMDAwMDAw
MDAwMDIwZGJmMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBkczogMDAyYiAgIGVz
OiAwMDJiICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDEwICAgY3M6IGUwMDgNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gWGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZm
ZmY4MzAyNDdiNmZlZTA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAgIGZmZmY4
MzAyNDdiNmZmMTAgZmZmZjgyYzRjMDE1YzMxNCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAw
YWZhZmMwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAgZmZmZjgzMDBhZmQx
NTAwMCAwMDAwMDAwMDAwMDAwMDA0IGZmZmY4MzAyNDdiNmZkNzggMDAwMDAwMDAwMDAwMDAw
MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWVkYTFkOCBmZmZmODgwMDNhMjM3ZjEwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAgIGZmZmY4ODAwM2EyMzYwMTAgMDAwMDAwMDAw
MDAwMDI0NiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozN10gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IGZmZmZmZmZmODEwMDEzYWEgMDAwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM3XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAx
MDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzddICAgIDAwMDAwMDAwMDAwMGUwMzMgMDAwMDAwMDAwMDAwMDI0NiBmZmZmODgwMDNhMjM3
ZWY4IDAwMDAwMDAwMDAwMGUwMmINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICAwMDAwMDAw
MDAwMDAwMDA0IGZmZmY4MzAwYWZhZmMwMDAgMDAwMDAwM2Q4Nzg2MTAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIFhlbiBjYWxsIHRyYWNlOg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICBbPGZmZmY4MmM0YzAxNTk1Njc+XSBk
ZWZhdWx0X2lkbGUrMHg4Ni8weDhiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAg
IFs8ZmZmZjgyYzRjMDE1YzMxND5dIGlkbGVfbG9vcCsweDY1LzB4NzMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozN10gICAgDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICoq
KiBEdW1waW5nIENQVTUgaG9zdCBzdGF0ZTogKioqDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6MzddIC0tLS1bIFhlbi00LjMtdW5zdGFibGUgIHg4Nl82NCAgZGVidWc9eSAgVGFpbnRl
ZDogICAgQyBdLS0tLQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBDUFU6ICAgIDUN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzRj
MDE1OTU2Nz5dIGRlZmF1bHRfaWRsZSsweDg2LzB4OGINCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozN10gUkZMQUdTOiAwMDAwMDAwMDAwMDAwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNv
cg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSByYXg6IGZmZmY4MmM0YzAzMTEwZjAg
ICByYng6IGZmZmY4MzAyNDdiNTgwMDAgICByY3g6IDAwMDAwMDAwMDAwMDAwMDUNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozN10gcmR4OiAwMDAwMDAzZDg3ODUzMDAwICAgcnNpOiBm
ZmZmODMwMjQ3YjY0YjgwICAgcmRpOiAwMDAwMDAwMDAwMDAwMDA1DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzddIHJicDogZmZmZjgzMDI0N2I1ZmVlMCAgIHJzcDogZmZmZjgzMDI0
N2I1ZmVlMCAgIHI4OiAgZmZmZjgzMDI0N2JlZWM3OA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM3XSByOTogIGZmZmY4MzAwYWZkMTQwNjAgICByMTA6IDAwMDAwMDAwZGVhZGJlZWYg
ICByMTE6IDAwMDAwMDAwMDAwMDAyNDYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10g
cjEyOiBmZmZmODJjNGMwMjYyMTgwICAgcjEzOiBmZmZmODMwMjQ3YjU4MDAwICAgcjE0OiAw
MDAwMDAwMGZmZmZmZmZmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIHIxNTogZmZm
ZjgzMDI0N2I2NDA0OCAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAw
MDAwMDZmMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSBjcjM6IDAwMDAwMDAyNGY1
YmUwMDAgICBjcjI6IGZmZmY4ODAwMzg0MGQ0NjgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozN10gZHM6IDAwMmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczog
ZTAxMCAgIGNzOiBlMDA4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddIFhlbiBzdGFj
ayB0cmFjZSBmcm9tIHJzcD1mZmZmODMwMjQ3YjVmZWUwOg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM3XSAgICBmZmZmODMwMjQ3YjVmZjEwIGZmZmY4MmM0YzAxNWMzMTQgMDAwMDAw
MDAwMDAwMDAwMCBmZmZmODMwMGFmZjhiMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzddICAgIGZmZmY4MzAwYWZkMTQwMDAgMDAwMDAwMDAwMDAwMDAwNSBmZmZmODMwMjQ3YjVm
ZDc4IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlZGExZDggZmZm
Zjg4MDAzYTI0MWYxMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM3XSAgICBmZmZmODgw
MDNhMjQwMDEwIDAwMDAwMDAwMDAwMDAyNDYgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzddICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxM2FhIDAwMDAwMDAwMDAwMDAwMDEN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozN10gICAgMDAwMDAwMDBkZWFkYmVlZiAwMDAw
MDAwMGRlYWRiZWVmIDAwMDAwMTAwMDAwMDAwMDAgZmZmZmZmZmY4MTAwMTNhYQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICAwMDAwMDAwMDAwMDBlMDMzIDAwMDAwMDAwMDAw
MDAyNDYgZmZmZjg4MDAzYTI0MWVmOCAwMDAwMDAwMDAwMDBlMDJiDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzhdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOF0gICAgMDAwMDAwMDAwMDAwMDAwNSBmZmZmODMwMGFmZjhiMDAwIDAwMDAwMDNk
ODc4NTMwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4
XSBYZW4gY2FsbCB0cmFjZToNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAgWzxm
ZmZmODJjNGMwMTU5NTY3Pl0gZGVmYXVsdF9pZGxlKzB4ODYvMHg4Yg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM4XSAgICBbPGZmZmY4MmM0YzAxNWMzMTQ+XSBpZGxlX2xvb3ArMHg2
NS8weDczDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICAgIA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM4XSBbMDogZHVtcCBEb20wIHJlZ2lzdGVyc10NCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjozOF0gJzAnIHByZXNzZWQgLT4gZHVtcGluZyBEb20wJ3MgcmVnaXN0
ZXJzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICoqKiBEdW1waW5nIERvbTAgdmNw
dSMwIHN0YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gUklQOiAgICBl
MDMzOls8ZmZmZmZmZmY4MTAwMTNhYT5dDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6Mzhd
IFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIEVNOiAwICAgQ09OVEVYVDogcHYgZ3Vlc3QN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAg
cmJ4OiBmZmZmZmZmZjgxZTAwMDEwICAgcmN4OiBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6MzhdIHJkeDogMDAwMDAwMDAwMDAwMDAwMSAgIHJzaTogMDAw
MDAwMDBkZWFkYmVlZiAgIHJkaTogMDAwMDAwMDBkZWFkYmVlZg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjM4XSByYnA6IGZmZmZmZmZmODFlMDFlNzggICByc3A6IGZmZmZmZmZmODFl
MDFlNjAgICByODogIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
MjozOF0gcjk6ICAwMDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAg
cjExOiAwMDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdIHIx
MjogZmZmZmZmZmY4MWVkYTFkOCAgIHIxMzogZmZmZmZmZmY4MWY5YTBjMCAgIHIxNDogMDAw
MDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSByMTU6IDAwMDAw
MDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwMDAwMDAwMDggICBjcjQ6IDAwMDAwMDAwMDAw
MDA2NjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gY3IzOiAwMDAwMDAwMjQxZTBj
MDAwICAgY3IyOiAwMDAwN2ZhZTBjNmY2MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzhdIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUw
MmIgICBjczogZTAzMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSBHdWVzdCBzdGFj
ayB0cmFjZSBmcm9tIHJzcD1mZmZmZmZmZjgxZTAxZTYwOg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjM4XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MTAwOGNlMCBmZmZmZmZmZjgxZTAxZTg4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzhdICAgIGZmZmZmZmZmODEwMTZmOWIgZmZmZmZmZmY4MWUwMWVhOCBmZmZmZmZmZjgxMDE3
MzU2IDAwMDAwMDAwMDAwMDAwMDINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAg
ZmZmZmZmZmY4MWY5MTk0MCBmZmZmZmZmZjgxZTAxZWQ4IGZmZmZmZmZmODE5OWY1YWMgZmZm
ZmZmZmY4MTk5ZjRmMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICBmZmZmZmZm
ZjgxZjkxOTQwIGZmZmZmZmZmODFlMDFlZDggZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZjgx
ZTAxZjI4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICAgIGZmZmZmZmZmODFmMDEx
MWIgZmZmZmZmZmY4MWYwMGI3ZiBmZmZmZmZmZjgyOTU0MDAwIGZmZmZmZmZmODI5NTUwMDAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAgZmZmZmZmZmY4MWY5YTBjMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFl
MDFmMzggZmZmZmZmZmY4MWYwMDNkNyBmZmZmZmZmZjgxZTAxZmY4DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzhdICAgIGZmZmZmZmZmODFmMDNmMGEgMDMwMDAwMDEwMDAwMDAzMiAw
MDAwMDAwMDAwMDAwMDA1IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4
XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgODA4MDIwMDExNzg5
YzNmNQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSAgICAwMDEwMGZhMDAwMDYwODAw
IDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdICoqKiBEdW1waW5nIERvbTAgdmNwdSMxIHN0
YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gUklQOiAgICBlMDMzOls8
ZmZmZmZmZmY4MTAwMTNhYT5dDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdIFJGTEFH
UzogMDAwMDAwMDAwMDAwMDI0NiAgIEVNOiAwICAgQ09OVEVYVDogcHYgZ3Vlc3QNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozOF0gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiBm
ZmZmODgwMDNhMjMwMDEwICAgcmN4OiBmZmZmZmZmZjgxMDAxM2FhDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzhdIHJkeDogMDAwMDAwMDAwMDAwMDAwMSAgIHJzaTogMDAwMDAwMDBk
ZWFkYmVlZiAgIHJkaTogMDAwMDAwMDBkZWFkYmVlZg0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjM4XSByYnA6IGZmZmY4ODAwM2EyMzFmMTAgICByc3A6IGZmZmY4ODAwM2EyMzFlZjgg
ICByODogIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0g
cjk6ICAwMDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAgcjExOiAw
MDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzhdIHIxMjogZmZm
ZmZmZmY4MWVkYTFkOCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogMDAwMDAwMDAw
MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM4XSByMTU6IDAwMDAwMDAwMDAw
MDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDA2NjAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOF0gY3IzOiAwMDAwMDAwMjNkOGNlMDAwICAg
Y3IyOiAwMDAwN2Y3YTI1NmRkODIwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldIGRz
OiAwMDJiICAgZXM6IDAwMmIgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMmIgICBj
czogZTAzMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSBHdWVzdCBzdGFjayB0cmFj
ZSBmcm9tIHJzcD1mZmZmODgwMDNhMjMxZWY4Og0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjM5XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAw
OGNlMCBmZmZmODgwMDNhMjMxZjIwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAg
IGZmZmZmZmZmODEwMTZmOWIgZmZmZjg4MDAzYTIzMWY0MCBmZmZmZmZmZjgxMDE3MzU2IDAw
MDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAw
MDAwMDAwMDAwMCBmZmZmODgwMDNhMjMxZjUwIGZmZmZmZmZmODE5YTRiZmEgMDAwMDAwMDAw
MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM5XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZmZmZmDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAxMCAwMDAwMDAw
MDAwMDAwMjAyIGZmZmY4ODAwM2EyMzFmNTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjoz
OV0gICAgMDAwMDAwMDAwMDAwMDAxOA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSAq
KiogRHVtcGluZyBEb20wIHZjcHUjMiBzdGF0ZTogKioqDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6MzldIFJJUDogICAgZTAzMzpbPGZmZmZmZmZmODEwMDEzYWE+XQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM5XSBSRkxBR1M6IDAwMDAwMDAwMDAwMDAyNDYgICBFTTogMCAg
IENPTlRFWFQ6IHB2IGd1ZXN0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldIHJheDog
MDAwMDAwMDAwMDAwMDAwMCAgIHJieDogZmZmZjg4MDAzYTIzMjAxMCAgIHJjeDogZmZmZmZm
ZmY4MTAwMTNhYQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSByZHg6IDAwMDAwMDAw
MDAwMDAwMDEgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYgICByZGk6IDAwMDAwMDAwZGVhZGJl
ZWYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gcmJwOiBmZmZmODgwMDNhMjMzZjEw
ICAgcnNwOiBmZmZmODgwMDNhMjMzZWY4ICAgcjg6ICAwMDAwMDAwMDAwMDAwMDAwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6MzldIHI5OiAgMDAwMDAwMDAwMDAwMDAwMSAgIHIxMDog
MDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDI0Ng0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjM5XSByMTI6IGZmZmZmZmZmODFlZGExZDggICByMTM6IDAwMDAwMDAw
MDAwMDAwMDAgICByMTQ6IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOV0gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNi
ICAgY3I0OiAwMDAwMDAwMDAwMDAwNjYwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6Mzld
IGNyMzogMDAwMDAwMDI0MWUwYzAwMCAgIGNyMjogMDAwMDAwMDAwMDIwZGJmMQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM5XSBkczogMDAyYiAgIGVzOiAwMDJiICAgZnM6IDAwMDAg
ICBnczogMDAwMCAgIHNzOiBlMDJiICAgY3M6IGUwMzMNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOV0gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjg4MDAzYTIzM2VmODoN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDhjZTAgZmZmZjg4MDAzYTIzM2YyMA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjM5XSAgICBmZmZmZmZmZjgxMDE2ZjliIGZmZmY4ODAwM2Ey
MzNmNDAgZmZmZmZmZmY4MTAxNzM1NiAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAzYTIzM2Y1MCBm
ZmZmZmZmZjgxOWE0YmZhIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjozOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5
XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmZmZmZm
ZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMTAgMDAwMDAwMDAwMDAwMDIwMiBmZmZmODgwMDNhMjMzZjU4DQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldICAgIDAwMDAwMDAwMDAwMDAwMTgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjozOV0gKioqIER1bXBpbmcgRG9tMCB2Y3B1IzMgc3RhdGU6
ICoqKg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSBSSVA6ICAgIGUwMzM6WzxmZmZm
ZmZmZjgxMDAxM2FhPl0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gUkZMQUdTOiAw
MDAwMDAwMDAwMDAwMjQ2ICAgRU06IDAgICBDT05URVhUOiBwdiBndWVzdA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjM5XSByYXg6IDAwMDAwMDAwMDAwMDAwMDAgICByYng6IGZmZmY4
ODAwM2EyMzQwMTAgICByY3g6IGZmZmZmZmZmODEwMDEzYWENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjozOV0gcmR4OiAwMDAwMDAwMDAwMDAwMDAxICAgcnNpOiAwMDAwMDAwMGRlYWRi
ZWVmICAgcmRpOiAwMDAwMDAwMGRlYWRiZWVmDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
MzldIHJicDogZmZmZjg4MDAzYTIzNWYxMCAgIHJzcDogZmZmZjg4MDAzYTIzNWVmOCAgIHI4
OiAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSByOTog
IDAwMDAwMDAwMDAwMDAwMDEgICByMTA6IDAwMDAwMDAwMDAwMDAwMDAgICByMTE6IDAwMDAw
MDAwMDAwMDAyNDYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjozOV0gcjEyOiBmZmZmZmZm
ZjgxZWRhMWQ4ICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiAwMDAwMDAwMDAwMDAw
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6MzldIHIxNTogMDAwMDAwMDAwMDAwMDAw
MCAgIGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDY2MA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjM5XSBjcjM6IDAwMDAwMDAyNDFlMGMwMDAgICBjcjI6
IDAwMDA3ZmFlMGM2ZjYwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gZHM6IDAw
MmIgICBlczogMDAyYiAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAyYiAgIGNzOiBl
MDMzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIEd1ZXN0IHN0YWNrIHRyYWNlIGZy
b20gcnNwPWZmZmY4ODAwM2EyMzVlZjg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBd
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDA4Y2Uw
IGZmZmY4ODAwM2EyMzVmMjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgZmZm
ZmZmZmY4MTAxNmY5YiBmZmZmODgwMDNhMjM1ZjQwIGZmZmZmZmZmODEwMTczNTYgMDAwMDAw
MDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAw
MDAwMDAwIGZmZmY4ODAwM2EyMzVmNTAgZmZmZmZmZmY4MTlhNGJmYSAwMDAwMDAwMDAwMDAw
MDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDBdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmZmZmZmZmZmYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0MF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDEwIDAwMDAwMDAwMDAw
MDAyMDIgZmZmZjg4MDAzYTIzNWY1OA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAg
ICAwMDAwMDAwMDAwMDAwMDE4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICoqKiBE
dW1waW5nIERvbTAgdmNwdSM0IHN0YXRlOiAqKioNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0MF0gUklQOiAgICBlMDMzOls8ZmZmZmZmZmY4MTAwMTNhYT5dDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDBdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDI0NiAgIEVNOiAwICAgQ09O
VEVYVDogcHYgZ3Vlc3QNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gcmF4OiAwMDAw
MDAwMDAwMDAwMDAwICAgcmJ4OiBmZmZmODgwMDNhMjM2MDEwICAgcmN4OiBmZmZmZmZmZjgx
MDAxM2FhDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIHJkeDogMDAwMDAwMDAwMDAw
MDAwMSAgIHJzaTogMDAwMDAwMDBkZWFkYmVlZiAgIHJkaTogMDAwMDAwMDBkZWFkYmVlZg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSByYnA6IGZmZmY4ODAwM2EyMzdmMTAgICBy
c3A6IGZmZmY4ODAwM2EyMzdlZjggICByODogIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0MF0gcjk6ICAwMDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAw
MDAwMDAwMDAwMDAwICAgcjExOiAwMDAwMDAwMDAwMDAwMjQ2DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDBdIHIxMjogZmZmZmZmZmY4MWVkYTFkOCAgIHIxMzogMDAwMDAwMDAwMDAw
MDAwMCAgIHIxNDogMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQwXSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBj
cjQ6IDAwMDAwMDAwMDAwMDA2NjANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gY3Iz
OiAwMDAwMDAwMjQxZTBjMDAwICAgY3IyOiAwMDAwMDAwMDAwMjBkYmYxDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDBdIGRzOiAwMDJiICAgZXM6IDAwMmIgICBmczogMDAwMCAgIGdz
OiAwMDAwICAgc3M6IGUwMmIgICBjczogZTAzMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQwXSBHdWVzdCBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODgwMDNhMjM3ZWY4Og0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgZmZmZmZmZmY4MTAwOGNlMCBmZmZmODgwMDNhMjM3ZjIwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDBdICAgIGZmZmZmZmZmODEwMTZmOWIgZmZmZjg4MDAzYTIzN2Y0
MCBmZmZmZmZmZjgxMDE3MzU2IDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0MF0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODgwMDNhMjM3ZjUwIGZmZmZm
ZmZmODE5YTRiZmEgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQwXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICAg
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZmZmZmZmZmZm
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAxMCAwMDAwMDAwMDAwMDAwMjAyIGZmZmY4ODAwM2EyMzdmNTgNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gICAgMDAwMDAwMDAwMDAwMDAxOA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQwXSAqKiogRHVtcGluZyBEb20wIHZjcHUjNSBzdGF0ZTogKioq
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIFJJUDogICAgZTAzMzpbPGZmZmZmZmZm
ODEwMDEzYWE+XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSBSRkxBR1M6IDAwMDAw
MDAwMDAwMDAyNDYgICBFTTogMCAgIENPTlRFWFQ6IHB2IGd1ZXN0DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDBdIHJheDogMDAwMDAwMDAwMDAwMDAwMCAgIHJieDogZmZmZjg4MDAz
YTI0MDAxMCAgIHJjeDogZmZmZmZmZmY4MTAwMTNhYQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQwXSByZHg6IDAwMDAwMDAwMDAwMDAwMDEgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYg
ICByZGk6IDAwMDAwMDAwZGVhZGJlZWYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0g
cmJwOiBmZmZmODgwMDNhMjQxZjEwICAgcnNwOiBmZmZmODgwMDNhMjQxZWY4ICAgcjg6ICAw
MDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDBdIHI5OiAgMDAw
MDAwMDAwMDAwMDAwMSAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAw
MDAwMDI0Ng0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSByMTI6IGZmZmZmZmZmODFl
ZGExZDggICByMTM6IDAwMDAwMDAwMDAwMDAwMDAgICByMTQ6IDAwMDAwMDAwMDAwMDAwMDAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MF0gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAg
Y3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNjYwDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDBdIGNyMzogMDAwMDAwMDI0ZjViZTAwMCAgIGNyMjogMDAw
MDAwMDAwMTI4ZDA0MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQwXSBkczogMDAyYiAg
IGVzOiAwMDJiICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDJiICAgY3M6IGUwMzMN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSBy
c3A9ZmZmZjg4MDAzYTI0MWVmODoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDhjZTAgZmZm
Zjg4MDAzYTI0MWYyMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSAgICBmZmZmZmZm
ZjgxMDE2ZjliIGZmZmY4ODAwM2EyNDFmNDAgZmZmZmZmZmY4MTAxNzM1NiAwMDAwMDAwMDAw
MDAwMDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdICAgIDAwMDAwMDAwMDAwMDAw
MDAgZmZmZjg4MDAzYTI0MWY1MCBmZmZmZmZmZjgxOWE0YmZhIDAwMDAwMDAwMDAwMDAwMDAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQxXSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0MV0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgZmZmZmZmZmZmZmZmZmZmZg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQx
XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMTAgMDAwMDAwMDAwMDAwMDIw
MiBmZmZmODgwMDNhMjQxZjU4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdICAgIDAw
MDAwMDAwMDAwMDAwMTgNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gW0g6IGR1bXAg
aGVhcCBpbmZvXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSAnSCcgcHJlc3NlZCAt
PiBkdW1waW5nIGhlYXAgaW5mbyAobm93LTB4Mjc6NjhDNjY3RkIpDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTBdIC0+IDAgcGFnZXMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MV0gLT4gMCBwYWdl
cw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFwW25vZGU9MF1bem9uZT0yXSAt
PiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6
b25lPTNdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtu
b2RlPTBdW3pvbmU9NF0gLT4gMCBwYWdlcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQx
XSBoZWFwW25vZGU9MF1bem9uZT01XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTZdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9N10gLT4gMCBwYWdlcw0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFwW25vZGU9MF1bem9uZT04XSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTld
IC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBd
W3pvbmU9MTBdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVh
cFtub2RlPTBdW3pvbmU9MTFdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTJdIC0+IDAgcGFnZXMNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTNdIC0+IDAgcGFnZXMNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTRdIC0+IDE2MTI4
IHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25l
PTE1XSAtPiAzMjc2OCBwYWdlcw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFw
W25vZGU9MF1bem9uZT0xNl0gLT4gNjU1MzYgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MTddIC0+IDEzMTA3MiBwYWdlcw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQxXSBoZWFwW25vZGU9MF1bem9uZT0xOF0gLT4gMjYyMTQ0
IHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25l
PTE5XSAtPiAxOTU4MjIgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gaGVh
cFtub2RlPTBdW3pvbmU9MjBdIC0+IDEwNDg1NzYgcGFnZXMNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0MV0gaGVhcFtub2RlPTBdW3pvbmU9MjFdIC0+IDU4MTA0IHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTIyXSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTIz
XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0w
XVt6b25lPTI0XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhl
YXBbbm9kZT0wXVt6b25lPTI1XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI2XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI3XSAtPiAwIHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI4XSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTI5
XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0w
XVt6b25lPTMwXSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhl
YXBbbm9kZT0wXVt6b25lPTMxXSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTMyXSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTMzXSAtPiAwIHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM0XSAtPiAwIHBh
Z2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM1
XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0w
XVt6b25lPTM2XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIGhl
YXBbbm9kZT0wXVt6b25lPTM3XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM4XSAtPiAwIHBhZ2VzDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDFdIGhlYXBbbm9kZT0wXVt6b25lPTM5XSAtPiAwIHBhZ2VzDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdIFtJOiBkdW1wIEhWTSBpcnEgaW5mb10NCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gJ0knIHByZXNzZWQgLT4gZHVtcGluZyBIVk0gaXJx
IGluZm8NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0MV0gW006IGR1bXAgTVNJIHN0YXRl
XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQxXSBNU0kgaW5mb3JtYXRpb246DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDFdICBNU0kgICAgIDU2IHZlYz0yOCAgZml4ZWQgIGVk
Z2UgZGVhc3NlcnQgcGh5cyAgICBjcHUgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMC8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBIUEVUICAgIDU3IHZlYz1hMCBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMC8/DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBIUEVUICAgIDU4IHZlYz1hOCBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMC8/DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBIUEVUICAgIDU5IHZlYz1iMCBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTEvMC8/DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYwIHZlYz01MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYxIHZlYz01OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYyIHZlYz02MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDYzIHZlYz02OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY0IHZlYz03MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY1IHZlYz03OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY2IHZlYz04MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY3IHZlYz04OSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY4IHZlYz05MSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDY5IHZlYz1jMSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDcwIHZlYz1kMSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAzZiBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDcxIHZlYz1kOSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDcyIHZlYz0yMiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDczIHZlYz0yYSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc0IHZlYz0zMiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc1IHZlYz0zYSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc2IHZlYz00MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc3IHZlYz00YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc4IHZlYz01MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDc5IHZlYz01YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgwIHZlYz02MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgxIHZlYz02YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgyIHZlYz03MiBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDgzIHZlYz03YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0ktWCAgIDg0IHZlYz04YSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTEvMC8wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdICBNU0kgICAgIDg1IHZlYz1hYSBsb3dlc3QgIGVk
Z2UgICBhc3NlcnQgIGxvZyBsb3dlc3QgZGVzdD0wMDAwMDAwMSBtYXNrPTAvMS8xDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDJdIFtROiBkdW1wIFBDSSBkZXZpY2VzXQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQyXSA9PT09IFBDSSBkZXZpY2VzID09PT0NCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0Ml0gPT09PSBzZWdtZW50IDAwMDAgPT09PQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQyXSAwMDAwOjBjOjAwLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Ml0gMDAwMDowYjowMS4yIC0gZG9tIDAgICAt
IE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDJdIDAwMDA6MGI6MDEuMSAt
IGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQyXSAwMDAw
OjBiOjAxLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0Ml0gMDAwMDowYTowMC4wIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDJdIDAwMDA6MDk6MDAuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjkgPg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQyXSAwMDAwOjA4OjAwLjAgLSBkb20gMCAgIC0g
TVNJcyA8IDcwID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Ml0gMDAwMDowNzowMC4w
IC0gZG9tIDAgICAtIE1TSXMgPCA3MSA3MiA3MyA3NCA3NSA3NiA3NyA+DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDY6MDAuMCAtIGRvbSAwICAgLSBNU0lzIDwgPg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjA1OjAwLjEgLSBkb20gMCAgIC0g
TVNJcyA8IDg1ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowNTowMC4w
IC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAw
MDA6MDQ6MDAuMCAtIGRvbSAwICAgLSBNU0lzIDwgNzggNzkgODAgODEgODIgODMgODQgPg0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAzOjA2LjAgLSBkb20gMCAgIC0g
TVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDoxOC40IC0g
ZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6
MDA6MTguMyAtIGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQzXSAwMDAwOjAwOjE4LjIgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0M10gMDAwMDowMDoxOC4xIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MTguMCAtIGRvbSAwICAgLSBNU0lz
IDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjE2LjIgLSBkb20g
MCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDox
Ni4wIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNd
IDAwMDA6MDA6MTUuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjggPg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQzXSAwMDAwOjAwOjE0LjUgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDoxNC40IC0gZG9tIDAgICAtIE1TSXMg
PCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MTQuMyAtIGRvbSAw
ICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjE0
LjEgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10g
MDAwMDowMDoxNC4wIC0gZG9tIDAgICAtIE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDNdIDAwMDA6MDA6MTMuMiAtIGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjEzLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDoxMi4yIC0gZG9tIDAgICAt
IE1TSXMgPCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MTIuMCAt
IGRvbSAwICAgLSBNU0lzIDwgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAw
OjAwOjExLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0M10gMDAwMDowMDowZC4wIC0gZG9tIDAgICAtIE1TSXMgPCA2NyA+DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MGIuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjYg
Pg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjBhLjAgLSBkb20gMCAg
IC0gTVNJcyA8IDY1ID4NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDow
OS4wIC0gZG9tIDAgICAtIE1TSXMgPCA2NCA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDNdIDAwMDA6MDA6MDYuMCAtIGRvbSAwICAgLSBNU0lzIDwgNjMgPg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQzXSAwMDAwOjAwOjA1LjAgLSBkb20gMCAgIC0gTVNJcyA8IDYyID4N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gMDAwMDowMDowMy4wIC0gZG9tIDAgICAt
IE1TSXMgPCA2MSA+DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIDAwMDA6MDA6MDIu
MCAtIGRvbSAwICAgLSBNU0lzIDwgNjAgPg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQz
XSAwMDAwOjAwOjAwLjAgLSBkb20gMCAgIC0gTVNJcyA8ID4NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0M10gMDAwMDowMDowMC4yIC0gZG9tIDMyNzU0IC0gTVNJcyA8ID4NCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0M10gW2E6IGR1bXAgdGltZXIgcXVldWVzXQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQzXSBEdW1waW5nIHRpbWVyIHF1ZXVlczoNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0M10gQ1BVMDA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDNdICAgZXg9ICAgLTM1MjB1cyB0aW1lcj1mZmZmODMwMjQ3YmNjMGI4IGNiPWZmZmY4MmM0
YzAxMWEwYjQoMDAwMDAwMDAwMDAwMDAwMCkgY3NjaGVkX3RpY2srMC8weDM0YQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAgIDE2NDgwdXMgdGltZXI9ZmZmZjgzMDI0
N2JjYTI0MCBjYj1mZmZmODJjNGMwMTE5NTk4KGZmZmY4MzAyNDdiY2EyMjApIGNzY2hlZF9h
Y2N0KzAvMHg0YWMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gICBleD0xMzA3NDc4
MDh1cyB0aW1lcj1mZmZmODJjNGMwMzBkMDYwIGNiPWZmZmY4MmM0YzAxODBlMTAoMDAwMDAw
MDAwMDAwMDAwMCkgcGx0X292ZXJmbG93KzAvMHgxMmYNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0M10gICBleD0xMDc2NDg2OXVzIHRpbWVyPWZmZmY4MmM0YzAzMGViODAgY2I9ZmZm
ZjgyYzRjMDFhMzA2NSgwMDAwMDAwMDAwMDAwMDAwKSBtY2VfYW1kX3dvcmtfZm4rMC8weDFm
Nw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAgMjU0MTY0dXMgdGltZXI9
ZmZmZjgyYzRjMDMwY2ZlMCBjYj1mZmZmODJjNGMwMTgxMzY4KDAwMDAwMDAwMDAwMDAwMDAp
IHRpbWVfY2FsaWJyYXRpb24rMC8weDU1DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNd
IENQVTAxOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAgMTk5NzE0dXMg
dGltZXI9ZmZmZjgzMDI0N2JkNWJkOCBjYj1mZmZmODJjNGMwMTFhMGI0KDAwMDAwMDAwMDAw
MDAwMDEpIGNzY2hlZF90aWNrKzAvMHgzNGENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
M10gICBleD0gIDQ1NDUyMXVzIHRpbWVyPWZmZmY4MzAwYWZmODgwNjAgY2I9ZmZmZjgyYzRj
MDEyMjMxMChmZmZmODMwMGFmZjg4MDAwKSB2Y3B1X3NpbmdsZXNob3RfdGltZXJfZm4rMC8w
eGINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gQ1BVMDI6DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDNdICAgZXg9ICAyNzc5NTl1cyB0aW1lcj1mZmZmODMwMjQ3YmVlMDI4
IGNiPWZmZmY4MmM0YzAxMWEwYjQoMDAwMDAwMDAwMDAwMDAwMikgY3NjaGVkX3RpY2srMC8w
eDM0YQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQzXSAgIGV4PSAzNTcwODg0dXMgdGlt
ZXI9ZmZmZjgzMDBhZmQxNzA2MCBjYj1mZmZmODJjNGMwMTIyMzEwKGZmZmY4MzAwYWZkMTcw
MDApIHZjcHVfc2luZ2xlc2hvdF90aW1lcl9mbiswLzB4Yg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQzXSBDUFUwMzoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0M10gICBleD0g
IDM1NjE2NHVzIHRpbWVyPWZmZmY4MzAyNDdiZWU0MTggY2I9ZmZmZjgyYzRjMDExYTBiNCgw
MDAwMDAwMDAwMDAwMDAzKSBjc2NoZWRfdGljayswLzB4MzRhDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDNdICAgZXg9IDM1NzQyMTl1cyB0aW1lcj1mZmZmODMwMGFmZDE2MDYwIGNi
PWZmZmY4MmM0YzAxMjIzMTAoZmZmZjgzMDBhZmQxNjAwMCkgdmNwdV9zaW5nbGVzaG90X3Rp
bWVyX2ZuKzAvMHhiDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDNdIENQVTA0Og0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgIGV4PSAgNDM0NDQzdXMgdGltZXI9ZmZmZjgz
MDI0N2JlZTg0OCBjYj1mZmZmODJjNGMwMTFhMGI0KDAwMDAwMDAwMDAwMDAwMDQpIGNzY2hl
ZF90aWNrKzAvMHgzNGENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gICBleD0gMzU3
NzU1NHVzIHRpbWVyPWZmZmY4MzAwYWZkMTUwNjAgY2I9ZmZmZjgyYzRjMDEyMjMxMChmZmZm
ODMwMGFmZDE1MDAwKSB2Y3B1X3NpbmdsZXNob3RfdGltZXJfZm4rMC8weGINCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0NF0gQ1BVMDU6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdICAgZXg9ICA1MTI2NTZ1cyB0aW1lcj1mZmZmODMwMjQ3YmVlYzc4IGNiPWZmZmY4MmM0
YzAxMWEwYjQoMDAwMDAwMDAwMDAwMDAwNSkgY3NjaGVkX3RpY2srMC8weDM0YQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgIGV4PSAzNTgwODg5dXMgdGltZXI9ZmZmZjgzMDBh
ZmQxNDA2MCBjYj1mZmZmODJjNGMwMTIyMzEwKGZmZmY4MzAwYWZkMTQwMDApIHZjcHVfc2lu
Z2xlc2hvdF90aW1lcl9mbiswLzB4Yg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBb
YzogZHVtcCBBQ1BJIEN4IHN0cnVjdHVyZXNdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdICdjJyBwcmVzc2VkIC0+IHByaW50aW5nIEFDUEkgQ3ggc3RydWN0dXJlcw0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ0XSA9PWNwdTA9PQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ0XSBhY3RpdmUgc3RhdGU6CQlDMjU1DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdIG1heF9jc3RhdGU6CQlDNw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBzdGF0
ZXM6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdICAgICBDMToJdHlwZVtDMV0gbGF0
ZW5jeVswMDBdIHVzYWdlWzAwMDAwMDAwXSBtZXRob2RbIEhBTFRdIGR1cmF0aW9uWzBdDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdICAgICBDMDoJdXNhZ2VbMDAwMDAwMDBdIGR1
cmF0aW9uWzE3MjI2MDMwNzA5OV0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gUEMy
WzBdIFBDM1swXSBQQzZbMF0gUEM3WzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRd
IENDM1swXSBDQzZbMF0gQ0M3WzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdID09
Y3B1MT09DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIGFjdGl2ZSBzdGF0ZToJCUMy
NTUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gbWF4X2NzdGF0ZToJCUM3DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIHN0YXRlczoNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0NF0gICAgIEMxOgl0eXBlW0MxXSBsYXRlbmN5WzAwMF0gdXNhZ2VbMDAwMDAwMDBd
IG1ldGhvZFsgSEFMVF0gZHVyYXRpb25bMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
NF0gICAgIEMwOgl1c2FnZVswMDAwMDAwMF0gZHVyYXRpb25bMTcyMzc4MDc4Njc3XQ0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBQQzJbMF0gUEMzWzBdIFBDNlswXSBQQzdbMF0N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gQ0MzWzBdIENDNlswXSBDQzdbMF0NCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gPT1jcHUyPT0NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0NF0gYWN0aXZlIHN0YXRlOgkJQzI1NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ0XSBtYXhfY3N0YXRlOgkJQzcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0g
c3RhdGVzOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgICAgQzE6CXR5cGVbQzFd
IGxhdGVuY3lbMDAwXSB1c2FnZVswMDAwMDAwMF0gbWV0aG9kWyBIQUxUXSBkdXJhdGlvblsw
XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSAgICAgQzA6CXVzYWdlWzAwMDAwMDAw
XSBkdXJhdGlvblsxNzI0OTU4NTIzNDNdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRd
IFBDMlswXSBQQzNbMF0gUEM2WzBdIFBDN1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ0XSBDQzNbMF0gQ0M2WzBdIENDN1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0
XSA9PWNwdTM9PQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBhY3RpdmUgc3RhdGU6
CQlDMjU1DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIG1heF9jc3RhdGU6CQlDNw0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBzdGF0ZXM6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDRdICAgICBDMToJdHlwZVtDMV0gbGF0ZW5jeVswMDBdIHVzYWdlWzAwMDAw
MDAwXSBtZXRob2RbIEhBTFRdIGR1cmF0aW9uWzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDRdICAgICBDMDoJdXNhZ2VbMDAwMDAwMDBdIGR1cmF0aW9uWzE3MjYxMzYyNDI4OF0N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gUEMyWzBdIFBDM1swXSBQQzZbMF0gUEM3
WzBdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIENDM1swXSBDQzZbMF0gQ0M3WzBd
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdID09Y3B1ND09DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDRdIGFjdGl2ZSBzdGF0ZToJCUMyNTUNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0NF0gbWF4X2NzdGF0ZToJCUM3DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDRdIHN0YXRlczoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gICAgIEMxOgl0eXBl
W0MxXSBsYXRlbmN5WzAwMF0gdXNhZ2VbMDAwMDAwMDBdIG1ldGhvZFsgSEFMVF0gZHVyYXRp
b25bMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gICAgIEMwOgl1c2FnZVswMDAw
MDAwMF0gZHVyYXRpb25bMTcyNzMxMzk3NjU0XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ0XSBQQzJbMF0gUEMzWzBdIFBDNlswXSBQQzdbMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0NF0gQ0MzWzBdIENDNlswXSBDQzdbMF0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0NF0gPT1jcHU1PT0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gYWN0aXZlIHN0
YXRlOgkJQzI1NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBtYXhfY3N0YXRlOgkJ
QzcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gc3RhdGVzOg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ0XSAgICAgQzE6CXR5cGVbQzFdIGxhdGVuY3lbMDAwXSB1c2FnZVsw
MDAwMDAwMF0gbWV0aG9kWyBIQUxUXSBkdXJhdGlvblswXQ0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ0XSAgICAgQzA6CXVzYWdlWzAwMDAwMDAwXSBkdXJhdGlvblsxNzI4NDkxNzEy
ODFdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdIFBDMlswXSBQQzNbMF0gUEM2WzBd
IFBDN1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBDQzNbMF0gQ0M2WzBdIEND
N1swXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ0XSBbZTogZHVtcCBldnRjaG4gaW5m
b10NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gJ2UnIHByZXNzZWQgLT4gZHVtcGlu
ZyBldmVudC1jaGFubmVsIGluZm8NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NF0gRXZl
bnQgY2hhbm5lbCBpbmZvcm1hdGlvbiBmb3IgZG9tYWluIDA6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDRdIFBvbGxpbmcgdkNQVXM6IHt9DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDRdICAgICBwb3J0IFtwL21dDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDRdICAg
ICAgICAxIFsxLzBdOiBzPTUgbj0wIHg9MCB2PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0NF0gICAgICAgIDIgWzEvMF06IHM9NiBuPTAgeD0wDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDRdICAgICAgICAzIFswLzBdOiBzPTYgbj0wIHg9MA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ1XSAgICAgICAgNCBbMC8wXTogcz01IG49MCB4PTAgdj0xDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgICA1IFswLzBdOiBzPTYgbj0wIHg9MA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAgNiBbMC8wXTogcz02IG49MCB4PTAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgIDcgWzAvMF06IHM9NSBuPTEg
eD0wIHY9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAgOCBbMC8wXTog
cz02IG49MSB4PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgIDkgWzAv
MF06IHM9NiBuPTEgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDEw
IFswLzBdOiBzPTUgbj0xIHg9MCB2PTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0g
ICAgICAgMTEgWzAvMF06IHM9NiBuPTEgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDVdICAgICAgIDEyIFswLzBdOiBzPTYgbj0xIHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ1XSAgICAgICAxMyBbMC8wXTogcz01IG49MiB4PTAgdj0wDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDVdICAgICAgIDE0IFswLzBdOiBzPTYgbj0yIHg9MA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAxNSBbMC8wXTogcz02IG49MiB4PTANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMTYgWzAvMF06IHM9NSBuPTIgeD0wIHY9
MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAxNyBbMC8wXTogcz02IG49
MiB4PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMTggWzAvMF06IHM9
NiBuPTIgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDE5IFswLzBd
OiBzPTUgbj0zIHg9MCB2PTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAg
MjAgWzAvMF06IHM9NiBuPTMgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAg
ICAgIDIxIFswLzBdOiBzPTYgbj0zIHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1
XSAgICAgICAyMiBbMC8wXTogcz01IG49MyB4PTAgdj0xDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDVdICAgICAgIDIzIFswLzBdOiBzPTYgbj0zIHg9MA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ1XSAgICAgICAyNCBbMC8wXTogcz02IG49MyB4PTANCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0NV0gICAgICAgMjUgWzAvMF06IHM9NSBuPTQgeD0wIHY9MA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAyNiBbMC8wXTogcz02IG49NCB4PTAN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMjcgWzAvMF06IHM9NiBuPTQg
eD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDI4IFswLzBdOiBzPTUg
bj00IHg9MCB2PTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMjkgWzAv
MF06IHM9NiBuPTQgeD0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDMw
IFswLzBdOiBzPTYgbj00IHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAg
ICAzMSBbMC8wXTogcz01IG49NSB4PTAgdj0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDVdICAgICAgIDMyIFswLzBdOiBzPTYgbj01IHg9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ1XSAgICAgICAzMyBbMC8wXTogcz02IG49NSB4PTANCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0NV0gICAgICAgMzQgWzAvMF06IHM9NSBuPTUgeD0wIHY9MQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAzNSBbMC8wXTogcz02IG49NSB4PTANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMzYgWzAvMF06IHM9NiBuPTUgeD0wDQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDM3IFswLzBdOiBzPTIgbj0wIHg9
MCBkPTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgMzggWzAvMF06IHM9
NSBuPTAgeD0wIHY9OQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICAzOSBb
MC8wXTogcz00IG49MCB4PTAgcD05IGk9OQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1
XSAgICAgICA0MCBbMC8wXTogcz01IG49MCB4PTAgdj0xNg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ1XSAgICAgICA0MSBbMC8xXTogcz01IG49MCB4PTAgdj0yDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDQyIFswLzBdOiBzPTQgbj0wIHg9MCBwPTE3IGk9
MTcNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgNDMgWzAvMF06IHM9NCBu
PTAgeD0wIHA9MzEgaT0zMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA0
NCBbMC8wXTogcz00IG49MCB4PTAgcD0xOCBpPTE4DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDVdICAgICAgIDQ1IFswLzBdOiBzPTQgbj0wIHg9MCBwPTI5IGk9MjkNCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgNDYgWzAvMF06IHM9NCBuPTAgeD0wIHA9MzAg
aT0zMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA0NyBbMC8wXTogcz00
IG49MCB4PTAgcD0zMDAgaT03MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAg
ICA0OCBbMC8wXTogcz00IG49MCB4PTAgcD0yOTkgaT03Mg0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ1XSAgICAgICA0OSBbMC8wXTogcz00IG49MCB4PTAgcD0yOTggaT03Mw0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1MCBbMC8wXTogcz00IG49MCB4PTAg
cD0yOTcgaT03NA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1MSBbMC8w
XTogcz00IG49MCB4PTAgcD0yOTYgaT03NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1
XSAgICAgICA1MiBbMC8wXTogcz00IG49MCB4PTAgcD0yOTUgaT03Ng0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ1XSAgICAgICA1MyBbMC8wXTogcz00IG49MCB4PTAgcD0yOTQgaT03
Nw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1NCBbMC8wXTogcz00IG49
MCB4PTAgcD0yOTMgaT03OA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1
NSBbMC8wXTogcz00IG49MCB4PTAgcD0yOTIgaT03OQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ1XSAgICAgICA1NiBbMC8wXTogcz00IG49MCB4PTAgcD0yOTEgaT04MA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1NyBbMC8wXTogcz00IG49MCB4PTAgcD0y
OTAgaT04MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA1OCBbMC8wXTog
cz00IG49MCB4PTAgcD0yODkgaT04Mg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAg
ICAgICA1OSBbMC8wXTogcz00IG49MCB4PTAgcD0yODggaT04Mw0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ1XSAgICAgICA2MCBbMC8wXTogcz00IG49MCB4PTAgcD0yODcgaT04NA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ1XSAgICAgICA2MSBbMC8wXTogcz00IG49MCB4
PTAgcD0xMiBpPTEyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVdICAgICAgIDYyIFsw
LzBdOiBzPTQgbj0wIHg9MCBwPTEgaT0xDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDVd
ICAgICAgIDYzIFswLzBdOiBzPTQgbj0wIHg9MCBwPTggaT04DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDVdICAgICAgIDY0IFswLzBdOiBzPTQgbj0wIHg9MCBwPTQ3IGk9NDcNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0NV0gICAgICAgNjUgWzAvMF06IHM9NCBuPTAgeD0w
IHA9MjIgaT0yMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICAgICA2NiBbMC8w
XTogcz00IG49MCB4PTAgcD0yODYgaT04NQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSBbZzogcHJpbnQgZ3JhbnQgdGFibGUgdXNhZ2VdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDZdIGdudHRhYl91c2FnZV9wcmludF9hbGwgWyBrZXkgJ2cnIHByZXNzZWQNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0Nl0gICAgICAgLS0tLS0tLS0gYWN0aXZlIC0tLS0tLS0t
ICAgICAgIC0tLS0tLS0tIHNoYXJlZCAtLS0tLS0tLQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ2XSBbcmVmXSBsb2NhbGRvbSBtZm4gICAgICBwaW4gICAgICAgICAgbG9jYWxkb20g
Z21mbiAgICAgZmxhZ3MNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Nl0gZ3JhbnQtdGFi
bGUgZm9yIHJlbW90ZSBkb21haW46ICAgIDAgLi4uIG5vIGFjdGl2ZSBncmFudCB0YWJsZSBl
bnRyaWVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDZdIGdudHRhYl91c2FnZV9wcmlu
dF9hbGwgXSBkb25lDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDZdIFtpOiBkdW1wIGlu
dGVycnVwdCBiaW5kaW5nc10NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0Nl0gR3Vlc3Qg
aW50ZXJydXB0IGluZm9ybWF0aW9uOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAg
ICBJUlE6ICAgMCBhZmZpbml0eTowMSB2ZWM6ZjAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh
dHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ2XSAgICBJUlE6ICAgMSBhZmZpbml0eTowMSB2ZWM6MzAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDE0IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICAxKC1TLS0p
LA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgMiBhZmZpbml0eToz
ZiB2ZWM6ZTIgdHlwZT1YVC1QSUMgICAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgMyBhZmZp
bml0eTowMSB2ZWM6MzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAg
NCBhZmZpbml0eTowMSB2ZWM6ZjEgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAw
MDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJ
UlE6ICAgNSBhZmZpbml0eTowMSB2ZWM6NDAgdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSAgICBJUlE6ICAgNiBhZmZpbml0eTowMSB2ZWM6NDggdHlwZT1JTy1BUElDLWVkZ2UgICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ2XSAgICBJUlE6ICAgNyBhZmZpbml0eTowMSB2ZWM6NTAgdHlwZT1JTy1BUElDLWVk
Z2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgOCBhZmZpbml0eTowMSB2ZWM6NTggdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6
ICA4KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAgOSBh
ZmZpbml0eTowMSB2ZWM6NjAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEw
IGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6ICA5KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxMCBhZmZpbml0eTowMSB2ZWM6NjggdHlwZT1JTy1B
UElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxMSBhZmZpbml0eTowMSB2ZWM6NzAgdHlw
ZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxMiBhZmZpbml0eTowMSB2ZWM6
NzggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRv
bWFpbi1saXN0PTA6IDEyKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAg
ICBJUlE6ICAxMyBhZmZpbml0eTozZiB2ZWM6ODggdHlwZT1JTy1BUElDLWVkZ2UgICAgc3Rh
dHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ2XSAgICBJUlE6ICAxNCBhZmZpbml0eTowMSB2ZWM6OTAgdHlwZT1JTy1BUElDLWVkZ2Ug
ICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ2XSAgICBJUlE6ICAxNSBhZmZpbml0eTowMSB2ZWM6OTggdHlwZT1JTy1BUElD
LWVkZ2UgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxNiBhZmZpbml0eTozZiB2ZWM6ZDAgdHlwZT1J
Ty1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxNyBhZmZpbml0eTowMSB2ZWM6MjEg
dHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFp
bi1saXN0PTA6IDE3KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJ
UlE6ICAxOCBhZmZpbml0eTowMSB2ZWM6ZDggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDE4KC1TLS0pLA0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAxOSBhZmZpbml0eTozZiB2ZWM6YTkg
dHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAyMiBhZmZpbml0eTowMSB2
ZWM6OWEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6IDIyKC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSAgICBJUlE6ICAyOSBhZmZpbml0eTowMSB2ZWM6MjkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDI5KC1TLS0pLA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAzMCBhZmZpbml0eTowMSB2
ZWM6MzEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0w
IGRvbWFpbi1saXN0PTA6IDMwKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2
XSAgICBJUlE6ICAzMSBhZmZpbml0eTowMSB2ZWM6MzkgdHlwZT1JTy1BUElDLWxldmVsICAg
c3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDMxKC1TLS0pLA0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAzMiBhZmZpbml0eTozZiB2
ZWM6OTkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5i
b3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICAzMyBhZmZpbml0
eTozZiB2ZWM6YTIgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBl
ZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ2XSAgICBJUlE6ICA0MCBh
ZmZpbml0eTowMSB2ZWM6NDkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAy
IG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6
ICA0NiBhZmZpbml0eTozZiB2ZWM6YjkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAw
MDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAg
ICBJUlE6ICA0NyBhZmZpbml0eTowMSB2ZWM6OTIgdHlwZT1JTy1BUElDLWxldmVsICAgc3Rh
dHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6IDQ3KC0tLS0pLA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA0OCBhZmZpbml0eTowMSB2ZWM6
NDEgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1MSBhZmZpbml0eToz
ZiB2ZWM6YzkgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1MiBhZmZp
bml0eTozZiB2ZWM6YjggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1
MyBhZmZpbml0eTozZiB2ZWM6YzAgdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJ
UlE6ICA1NCBhZmZpbml0eTozZiB2ZWM6YzggdHlwZT1JTy1BUElDLWxldmVsICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3
XSAgICBJUlE6ICA1NiBhZmZpbml0eTowMSB2ZWM6MjggdHlwZT1BTUQtSU9NTVUtTVNJICAg
c3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ3XSAgICBJUlE6ICA1NyBhZmZpbml0eTozZiB2ZWM6YTAgdHlwZT1IUEVULU1TSSAg
ICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1OCBhZmZpbml0eTozZiB2ZWM6YTggdHlwZT1IUEVU
LU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA1OSBhZmZpbml0eTozZiB2ZWM6YjAgdHlw
ZT1IUEVULU1TSSAgICAgICAgc3RhdHVzPTAwMDAwMDAwIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2MCBhZmZpbml0eTozZiB2ZWM6
NTEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2MSBhZmZpbml0eToz
ZiB2ZWM6NTkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2MiBhZmZp
bml0eTozZiB2ZWM6NjEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1h
cHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2
MyBhZmZpbml0eTozZiB2ZWM6NjkgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAw
MDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJ
UlE6ICA2NCBhZmZpbml0eTozZiB2ZWM6NzEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVz
PTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3
XSAgICBJUlE6ICA2NSBhZmZpbml0eTozZiB2ZWM6NzkgdHlwZT1QQ0ktTVNJICAgICAgICAg
c3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ3XSAgICBJUlE6ICA2NiBhZmZpbml0eTozZiB2ZWM6ODEgdHlwZT1QQ0ktTVNJICAg
ICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2NyBhZmZpbml0eTozZiB2ZWM6ODkgdHlwZT1QQ0kt
TVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2OCBhZmZpbml0eTozZiB2ZWM6OTEgdHlw
ZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3VuZA0KIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA2OSBhZmZpbml0eTozZiB2ZWM6
YzEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwgdW5ib3Vu
ZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3MCBhZmZpbml0eToz
ZiB2ZWM6ZDEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDAyIG1hcHBlZCwg
dW5ib3VuZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3MSBhZmZp
bml0eTowMSB2ZWM6ZDkgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MzAwKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3MiBhZmZpbml0eTowMSB2ZWM6MjIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk5
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3MyBhZmZp
bml0eTowMSB2ZWM6MmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk4KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3NCBhZmZpbml0eTowMSB2ZWM6MzIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk3
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3NSBhZmZp
bml0eTowMSB2ZWM6M2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk2KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3NiBhZmZpbml0eTowMSB2ZWM6NDIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk1
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3NyBhZmZp
bml0eTowMSB2ZWM6NGEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjk0KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA3OCBhZmZpbml0eTowMSB2ZWM6NTIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjkz
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ3XSAgICBJUlE6ICA3OSBhZmZp
bml0eTowMSB2ZWM6NWEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkyKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ3XSAgICBJUlE6ICA4MCBhZmZpbml0eTowMSB2ZWM6NjIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjkx
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICBJUlE6ICA4MSBhZmZp
bml0eTowMSB2ZWM6NmEgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6MjkwKC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ4XSAgICBJUlE6ICA4MiBhZmZpbml0eTowMSB2ZWM6NzIgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg5
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICBJUlE6ICA4MyBhZmZp
bml0eTowMSB2ZWM6N2EgdHlwZT1QQ0ktTVNJLy1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg4KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ4XSAgICBJUlE6ICA4NCBhZmZpbml0eTowMSB2ZWM6OGEgdHlwZT1QQ0ktTVNJ
Ly1YICAgICAgc3RhdHVzPTAwMDAwMDEwIGluLWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg3
KC1TLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICBJUlE6ICA4NSBhZmZp
bml0eTowMSB2ZWM6YWEgdHlwZT1QQ0ktTVNJICAgICAgICAgc3RhdHVzPTAwMDAwMDEwIGlu
LWZsaWdodD0wIGRvbWFpbi1saXN0PTA6Mjg2KC0tLS0pLA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjQ4XSBJTy1BUElDIGludGVycnVwdCBpbmZvcm1hdGlvbjoNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgMCBWZWMyNDA6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICAyOiB2ZWM9ZjAgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBk
ZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgMSBWZWMg
NDg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGlu
ICAxOiB2ZWM9MzAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAg
aXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo0OF0gICAgIElSUSAgMyBWZWMgNTY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhd
ICAgICAgIEFwaWMgMHgwMCwgUGluICAzOiB2ZWM9MzggZGVsaXZlcnk9TG9QcmkgZGVzdD1M
IHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgNCBWZWMyNDE6DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA0OiB2ZWM9ZjEg
ZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1F
IG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElS
USAgNSBWZWMgNjQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMg
MHgwMCwgUGluICA1OiB2ZWM9NDAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBv
bGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0OF0gICAgIElSUSAgNiBWZWMgNzI6DQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA2OiB2ZWM9NDggZGVsaXZlcnk9TG9Q
cmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0
X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgNyBWZWMgODA6
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA3
OiB2ZWM9NTAgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJy
PTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
OF0gICAgIElSUSAgOCBWZWMgODg6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAg
ICAgIEFwaWMgMHgwMCwgUGluICA4OiB2ZWM9NTggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0
YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAgOSBWZWMgOTY6DQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluICA5OiB2ZWM9NjAgZGVs
aXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1h
c2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAx
MCBWZWMxMDQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgw
MCwgUGluIDEwOiB2ZWM9NjggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFy
aXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0OF0gICAgIElSUSAxMSBWZWMxMTI6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluIDExOiB2ZWM9NzAgZGVsaXZlcnk9TG9Qcmkg
ZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MCBkZXN0X2lk
OjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgIElSUSAxMiBWZWMxMjA6DQog
KFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAgIEFwaWMgMHgwMCwgUGluIDEyOiB2
ZWM9NzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTAgaXJyPTAg
dHJpZz1FIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0g
ICAgIElSUSAxMyBWZWMxMzY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICAg
IEFwaWMgMHgwMCwgUGluIDEzOiB2ZWM9ODggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1
cz0wIHBvbGFyaXR5PTAgaXJyPTAgdHJpZz1FIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICBJUlEgMTQgVmVjMTQ0Og0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNDogdmVjPTkwIGRlbGl2
ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0wIGlycj0wIHRyaWc9RSBtYXNr
PTAgZGVzdF9pZDoxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDhdICAgICBJUlEgMTUg
VmVjMTUyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICAgICBBcGljIDB4MDAs
IFBpbiAxNTogdmVjPTk4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0
eT0wIGlycj0wIHRyaWc9RSBtYXNrPTAgZGVzdF9pZDoxDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NDhdICAgICBJUlEgMTYgVmVjMjA4Og0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjQ4XSAgICAgICBBcGljIDB4MDAsIFBpbiAxNjogdmVjPWQwIGRlbGl2ZXJ5PUxvUHJpIGRl
c3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2
Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ4XSAgICAgSVJRIDE3IFZlYyAzMzoNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OF0gICAgICAgQXBpYyAweDAwLCBQaW4gMTc6IHZl
Yz0yMSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0
cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAg
ICAgSVJRIDE4IFZlYzIxNjoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgICAg
QXBpYyAweDAwLCBQaW4gMTg6IHZlYz1kOCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVz
PTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0wIGRlc3RfaWQ6MQ0KIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgSVJRIDE5IFZlYzE2OToNCiAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo0OV0gICAgICAgQXBpYyAweDAwLCBQaW4gMTk6IHZlYz1hOSBkZWxpdmVy
eT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0x
IGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIElSUSAyMiBW
ZWMxNTQ6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMCwg
UGluIDIyOiB2ZWM9OWEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5
PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo0OV0gICAgIElSUSAyOSBWZWMgNDE6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NDldICAgICAgIEFwaWMgMHgwMSwgUGluICA1OiB2ZWM9MjkgZGVsaXZlcnk9TG9QcmkgZGVz
dD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjEN
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIElSUSAzMCBWZWMgNDk6DQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGluICA2OiB2ZWM9
MzEgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJp
Zz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAg
IElSUSAzMSBWZWMgNTc6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFw
aWMgMHgwMSwgUGluICA3OiB2ZWM9MzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OV0gICAgIElSUSAzMiBWZWMxNTM6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGluICA4OiB2ZWM9OTkgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBk
ZXN0X2lkOjYzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBJUlEgMzMgVmVj
MTYyOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgICBBcGljIDB4MDEsIFBp
biAgOTogdmVjPWEyIGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9TCBzdGF0dXM9MCBwb2xhcml0eT0x
IGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mw0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjQ5XSAgICAgSVJRIDQwIFZlYyA3MzoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0
OV0gICAgICAgQXBpYyAweDAxLCBQaW4gMTY6IHZlYz00OSBkZWxpdmVyeT1Mb1ByaSBkZXN0
PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmlnPUwgbWFzaz0xIGRlc3RfaWQ6MQ0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgSVJRIDQ2IFZlYzE4NToNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgICAgQXBpYyAweDAxLCBQaW4gMjI6IHZlYz1i
OSBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAg
IElSUSA0NyBWZWMxNDY6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFw
aWMgMHgwMSwgUGluIDIzOiB2ZWM9OTIgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MCBkZXN0X2lkOjENCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OV0gICAgIElSUSA0OCBWZWMgNjU6DQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGluIDI0OiB2ZWM9NDEgZGVsaXZlcnk9
TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBk
ZXN0X2lkOjENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIElSUSA1MSBWZWMy
MDE6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFwaWMgMHgwMSwgUGlu
IDI3OiB2ZWM9YzkgZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0wIHBvbGFyaXR5PTEg
aXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NDldICAgICBJUlEgNTIgVmVjMTg0Og0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5
XSAgICAgICBBcGljIDB4MDEsIFBpbiAyODogdmVjPWI4IGRlbGl2ZXJ5PUxvUHJpIGRlc3Q9
TCBzdGF0dXM9MCBwb2xhcml0eT0xIGlycj0wIHRyaWc9TCBtYXNrPTEgZGVzdF9pZDo2Mw0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgSVJRIDUzIFZlYzE5MjoNCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgICAgQXBpYyAweDAxLCBQaW4gMjk6IHZlYz1j
MCBkZWxpdmVyeT1Mb1ByaSBkZXN0PUwgc3RhdHVzPTAgcG9sYXJpdHk9MSBpcnI9MCB0cmln
PUwgbWFzaz0xIGRlc3RfaWQ6NjMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAg
IElSUSA1NCBWZWMyMDA6DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICAgIEFw
aWMgMHgwMSwgUGluIDMwOiB2ZWM9YzggZGVsaXZlcnk9TG9QcmkgZGVzdD1MIHN0YXR1cz0w
IHBvbGFyaXR5PTEgaXJyPTAgdHJpZz1MIG1hc2s9MSBkZXN0X2lkOjYzDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDldIFttOiBtZW1vcnkgaW5mb10NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo0OV0gUGh5c2ljYWwgbWVtb3J5IGluZm9ybWF0aW9uOg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjQ5XSAgICAgWGVuIGhlYXA6IDBrQiBmcmVlDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NDldICAgICBoZWFwWzE0XTogNjQ1MTJrQiBmcmVlDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NDldICAgICBoZWFwWzE1XTogMTMxMDcya0IgZnJlZQ0KIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjQ5XSAgICAgaGVhcFsxNl06IDI2MjE0NGtCIGZyZWUNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIGhlYXBbMTddOiA1MjQyODhrQiBmcmVl
DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBoZWFwWzE4XTogMTA0ODU3NmtC
IGZyZWUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIGhlYXBbMTldOiA3ODMy
ODhrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBoZWFwWzIwXTog
NDE5NDMwNGtCIGZyZWUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0gICAgIGhlYXBb
MjFdOiAyMzI0MTZrQiBmcmVlDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgICBE
b20gaGVhcDogNzI0MDYwMGtCIGZyZWUNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo0OV0g
W246IE5NSSBzdGF0aXN0aWNzXQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5XSBDUFUJ
Tk1JDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgMAkgIDANCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo0OV0gICAxCSAgMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjQ5
XSAgIDIJICAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NDldICAgMwkgIDANCiAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICA0CSAgMA0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUwXSAgIDUJICAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdIGRvbTAgdmNw
dTA6IE5NSSBuZWl0aGVyIHBlbmRpbmcgbm9yIG1hc2tlZA0KIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUwXSBbcTogZHVtcCBkb21haW4gKGFuZCBndWVzdCBkZWJ1ZykgaW5mb10NCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gJ3EnIHByZXNzZWQgLT4gZHVtcGluZyBkb21h
aW4gaW5mbyAobm93PTB4Mjk6NzU1RURGMUQpDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTBdIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAwOg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUwXSAgICAgcmVmY250PTMgZHlpbmc9MCBwYXVzZV9jb3VudD0wDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBucl9wYWdlcz0yNjIxNDQgeGVuaGVhcF9w
YWdlcz02IHNoYXJlZF9wYWdlcz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17MS01fSBt
YXhfcGFnZXM9MjYyMTQ0DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBoYW5k
bGU9MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwIHZtX2Fzc2lzdD0wMDAw
MDAwZA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBSYW5nZXNldHMgYmVsb25naW5n
IHRvIGRvbWFpbiAwOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgSS9PIFBv
cnRzICB7IDAtMWYsIDIyLTNmLCA0NC02MCwgNjItOWYsIGEyLTNmNywgNDAwLTgwNywgODBj
LWNmYiwgZDAwLWZmZmYgfQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgSW50
ZXJydXB0cyB7IDAtMzExIH0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIEkv
TyBNZW1vcnkgeyAwLWZlYmZmLCBmZWMwMS1mZWMxZiwgZmVjMjEtZmVkZmYsIGZlZTAxLWZm
ZmZmZmZmZmZmZmZmZmYgfQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBNZW1vcnkg
cGFnZXMgYmVsb25naW5nIHRvIGRvbWFpbiAwOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUwXSAgICAgRG9tUGFnZSBsaXN0IHRvbyBsb25nIHRvIGRpc3BsYXkNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo1MF0gICAgIFhlblBhZ2UgMDAwMDAwMDAwMDI0N2IyYzogY2FmPWMw
MDAwMDAwMDAwMDAwMDIsIHRhZj03NDAwMDAwMDAwMDAwMDAyDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTBdICAgICBYZW5QYWdlIDAwMDAwMDAwMDAyNDdiMmI6IGNhZj1jMDAwMDAw
MDAwMDAwMDAxLCB0YWY9NzQwMDAwMDAwMDAwMDAwMQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUwXSAgICAgWGVuUGFnZSAwMDAwMDAwMDAwMjQ3YjJhOiBjYWY9YzAwMDAwMDAwMDAw
MDAwMSwgdGFmPTc0MDAwMDAwMDAwMDAwMDENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
MF0gICAgIFhlblBhZ2UgMDAwMDAwMDAwMDI0N2IyOTogY2FmPWMwMDAwMDAwMDAwMDAwMDEs
IHRhZj03NDAwMDAwMDAwMDAwMDAxDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAg
ICBYZW5QYWdlIDAwMDAwMDAwMDAwYWZmOGE6IGNhZj1jMDAwMDAwMDAwMDAwMDAyLCB0YWY9
NzQwMDAwMDAwMDAwMDAwMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgWGVu
UGFnZSAwMDAwMDAwMDAwMjQwMGEwOiBjYWY9YzAwMDAwMDAwMDAwMDAwMiwgdGFmPTc0MDAw
MDAwMDAwMDAwMDINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gVkNQVSBpbmZvcm1h
dGlvbiBhbmQgY2FsbGJhY2tzIGZvciBkb21haW4gMDoNCiAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1MF0gICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0g
MDEsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17fSBjcHVfYWZmaW5pdHk9ezAtNX0N
CiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIHBhdXNlX2NvdW50PTAgcGF1c2Vf
ZmxhZ3M9MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgTm8gcGVyaW9kaWMg
dGltZXINCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIFZDUFUxOiBDUFUxIFto
YXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5kID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlf
Y3B1cz17MX0gY3B1X2FmZmluaXR5PXswLTV9DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTBdICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTENCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MF0gICAgIE5vIHBlcmlvZGljIHRpbWVyDQogKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NTBdICAgICBWQ1BVMjogQ1BVMiBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9
IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRpcnR5X2NwdXM9ezJ9IGNwdV9hZmZpbml0eT17MC01
fQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgcGF1c2VfY291bnQ9MCBwYXVz
ZV9mbGFncz0xDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBObyBwZXJpb2Rp
YyB0aW1lcg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSAgICAgVkNQVTM6IENQVTMg
W2hhcz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQgPSAwMCwgdXBjYWxsX21hc2sgPSAwMCBkaXJ0
eV9jcHVzPXszfSBjcHVfYWZmaW5pdHk9ezAtNX0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1MF0gICAgIHBhdXNlX2NvdW50PTAgcGF1c2VfZmxhZ3M9MQ0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUwXSAgICAgTm8gcGVyaW9kaWMgdGltZXINCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MF0gICAgIFZDUFU0OiBDUFU0IFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9wZW5k
ID0gMDAsIHVwY2FsbF9tYXNrID0gMDAgZGlydHlfY3B1cz17NH0gY3B1X2FmZmluaXR5PXsw
LTV9DQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBwYXVzZV9jb3VudD0wIHBh
dXNlX2ZsYWdzPTENCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MF0gICAgIE5vIHBlcmlv
ZGljIHRpbWVyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdICAgICBWQ1BVNTogQ1BV
NSBbaGFzPUZdIHBvbGw9MCB1cGNhbGxfcGVuZCA9IDAwLCB1cGNhbGxfbWFzayA9IDAwIGRp
cnR5X2NwdXM9ezV9IGNwdV9hZmZpbml0eT17MC01fQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUwXSAgICAgcGF1c2VfY291bnQ9MCBwYXVzZV9mbGFncz0xDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTBdICAgICBObyBwZXJpb2RpYyB0aW1lcg0KIChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUwXSBOb3RpZnlpbmcgZ3Vlc3QgMDowICh2aXJxIDEsIHBvcnQgNCwgc3Rh
dCAwLzAvLTEpDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBdIE5vdGlmeWluZyBndWVz
dCAwOjEgKHZpcnEgMSwgcG9ydCAxMCwgc3RhdCAwLzAvMCkNCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MF0gTm90aWZ5aW5nIGd1ZXN0IDA6MiAodmlycSAxLCBwb3J0IDE2LCBzdGF0
IDAvMC8wKQ0KIFsgIDE3OC44OTE0MzVdIA0KKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTBd
IE5vdGlmeWluZyBndWVzdCAwOjMgKHZpcnEgMSwgcG9ydCAyMiwgc3RhdCAwLzAvMCkNCiAg
IHZjcHUgMQ0KICAgIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBOb3RpZnlpbmcgZ3Vl
c3QgMDo0ICh2aXJxIDEsIHBvcnQgMjgsIHN0YXQgMC8wLzApDQogMDogbWFza2VkPTAgcGVu
ZChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUwXSBOb3RpZnlpbmcgZ3Vlc3QgMDo1ICh2aXJx
IDEsIHBvcnQgMzQsIHN0YXQgMC8wLzApDQogaW5nPTEgZXZlbnRfc2VsIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUwXSBTaGFyZWQgZnJhbWVzIDAgLS0gU2F2ZWQgZnJhbWVzIDANCiAw
MDAwMDAwMDAwMDAwMDAxDQogICAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIFtyOiBk
dW1wIHJ1biBxdWV1ZXNdDQogMTogbWFza2VkPTAgcGVuZChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUxXSBzY2hlZF9zbXRfcG93ZXJfc2F2aW5nczogZGlzYWJsZWQNCiAoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo1MV0gTk9XPTB4MDAwMDAwMjlBRUFEOURBMw0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUxXSBJZGxlIGNwdXBvb2w6DQogaW5nPTAgZXZlbnRfc2VsIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjUxXSBTY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVy
IChjcmVkaXQpDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUx
XSBpbmZvOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJbmNwdXMgICAgICAgICAg
ICAgID0gNg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJbWFzdGVyICAgICAgICAg
ICAgID0gMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJY3JlZGl0ICAgICAgICAg
ICAgID0gMTgwMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJY3JlZGl0IGJhbGFu
Y2UgICAgID0gLTczMg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJd2VpZ2h0ICAg
ICAgICAgICAgID0gMTI4MA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJcnVucV9z
b3J0ICAgICAgICAgID0gOTgzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAlkZWZh
dWx0LXdlaWdodCAgICAgPSAyNTYNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCXRz
bGljZSAgICAgICAgICAgICA9IDMwbXMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0g
CXJhdGVsaW1pdCAgICAgICAgICA9IDEwMDB1cw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUxXSAJY3JlZGl0cyBwZXIgbXNlYyAgID0gMTANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1MV0gCXRpY2tzIHBlciB0c2xpY2UgICA9IDMNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1MV0gCW1pZ3JhdGlvbiBkZWxheSAgICA9IDB1cw0KICAgICAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTFdIGlkbGVyczogMDANCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0g
YWN0aXZlIHZjcHVzOg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJICAxOiAyOiBt
YXNrZWQ9MSBwZW5kWzAuNV0gcHJpPS0xIGZsYWdzPTAgY3B1PTVpbmc9MSBldmVudF9zZWwg
IGNyZWRpdD0tMjk5MiBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkg
IDI6IDAwMDAwMDAwMDAwMDAwMDFbMC40XSBwcmk9LTIgZmxhZ3M9MCBjcHU9NA0KICAgICBj
cmVkaXQ9LTM1NzcgW3c9MjU2XQ0KIDM6IG1hc2tlZD0xIHBlbmQoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1MV0gCSAgMzogaW5nPTEgZXZlbnRfc2VsIFswLjNdIHByaT0tMiBmbGFncz0w
IGNwdT0zMDAwMDAwMDAwMDAwMDAwMSBjcmVkaXQ9LTM4NjIgW3c9MjU2XQ0KICAgICAgKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDQ6IDQ6IG1hc2tlZD0xIHBlbmRbMC4yXSBw
cmk9LTIgZmxhZ3M9MCBjcHU9MmluZz0xIGV2ZW50X3NlbCAgY3JlZGl0PS00MzAxIFt3PTI1
Nl0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCSAgNTogMDAwMDAwMDAwMDAwMDAw
MVswLjFdIHByaT0tMiBmbGFncz0wIGNwdT0xIGNyZWRpdD0tNDc1MyBbdz0yNTZdDQogICAg
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gQ3B1cG9vbCAwOg0KIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUxXSBTY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVk
aXQpDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIGluZm86DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTFdIAluY3B1cyAgICAgICAgICAgICAgPSA2DQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTFdIAltYXN0ZXIgICAgICAgICAgICAgPSAwDQogKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTFdIAljcmVkaXQgICAgICAgICAgICAgPSAxODAwDQogKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTFdIAljcmVkaXQgYmFsYW5jZSAgICAgPSAtNzMyDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTFdIAl3ZWlnaHQgICAgICAgICAgICAgPSAxMjgwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAlydW5xX3NvcnQgICAgICAgICAgPSA5ODMNCiAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCWRlZmF1bHQtd2VpZ2h0ICAgICA9IDI1Ng0K
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJdHNsaWNlICAgICAgICAgICAgID0gMzBt
cw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJcmF0ZWxpbWl0ICAgICAgICAgID0g
MTAwMHVzDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAljcmVkaXRzIHBlciBtc2Vj
ICAgPSAxMA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJdGlja3MgcGVyIHRzbGlj
ZSAgID0gMw0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJbWlncmF0aW9uIGRlbGF5
ICAgID0gMHVzDQogNTogbWFza2VkPTEgcGVuZChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUx
XSBpZGxlcnM6IDAwDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIGFjdGl2ZSB2Y3B1
czoNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCSAgMTogaW5nPTEgZXZlbnRfc2Vs
IFswLjVdIHByaT0tMSBmbGFncz0wIGNwdT01MDAwMDAwMDAwMDAwMDAwMSBjcmVkaXQ9LTY3
OTAgW3c9MjU2XQ0KICAgICAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDI6IA0K
ICBwZW5kaW5nOg0KICAgICBbMC40XSBwcmk9LTIgZmxhZ3M9MCBjcHU9NDAwMDAwMDAwMDAw
MDAwMDAgY3JlZGl0PS03Mzk3IFt3PTI1Nl0NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTFdIAkgIDM6IDAwMDAwMDAwMDAwMDAwMDBbMC4zXSBwcmk9LTIgZmxhZ3M9MCBjcHU9MyAg
Y3JlZGl0PS03NzgzIFt3PTI1Nl0NCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0gCSAg
NDogMDAwMDAwMDAwMDAwMDAwMFswLjJdIHByaT0tMiBmbGFncz0wIGNwdT0yICBjcmVkaXQ9
LTgxMjAgW3c9MjU2XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJICA1OiAwMDAw
MDAwMDAwMDAwMDAwWzAuMV0gcHJpPS0yIGZsYWdzPTAgY3B1PTEgY3JlZGl0PS04NTEwIFt3
PTI1Nl0NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIENQVVswMF0gMDAwMDAwMDAw
MDAwMDAwMCBzb3J0PTk4Miwgc2libGluZz0wMSwgIGNvcmU9M2YNCiAwMDAwMDAwMDAwMDAw
MDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAlydW46IFszMjc2Ny4wXSBwcmk9MCBm
bGFncz0wIGNwdT0wDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDE6IFswLjBd
IHByaT0wIGZsYWdzPTAgY3B1PTAgY3JlZGl0PS0zNyBbdz0yNTZdDQogIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUxXSBDUFVbMDFdICBzb3J0PTk4Mywgc2libGluZz0wMiwgY29yZT0z
Zg0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUxXSAJcnVuOiBbMC4xXSBwcmk9LTIgZmxh
Z3M9MCBjcHU9MSBjcmVkaXQ9LTkyODIgW3c9MjU2XQ0KIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUxXSAJICAxOiBbMzI3NjcuMV0gcHJpPS02NCBmbGFncz0wIGNwdT0xDQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTFdIENQVVswMl0gMDAwMDAwMDAwMDAwMDAwMCBzb3J0PTk4
Mywgc2libGluZz0wNCwgIGNvcmU9M2YNCiAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1MV0g
CXJ1bjogMDAwMDAwMDAwMDAwMDAwMFswLjJdIHByaT0tMiBmbGFncz0wIGNwdT0yIGNyZWRp
dD0tOTgyOSBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTFdIAkgIDE6IA0K
ICAgICBbMzI3NjcuMl0gcHJpPS02NCBmbGFncz0wIGNwdT0yDQogMDAwMDAwMDAwMDAwMDAw
MChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBDUFVbMDNdICAgc29ydD05ODMsIHNpYmxp
bmc9MDgsIDAwMDAwMDAwMDAwMDAwMDBjb3JlPTNmDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUyXSAJcnVuOiAwMDAwMDAwMDAwMDAwMDAwWzAuM10gcHJpPS0yIGZsYWdzPTAgY3B1
PTMgY3JlZGl0PS0xMDI5NSBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJd
IAkgIDE6ICBbMzI3NjcuM10gcHJpPS02NCBmbGFncz0wIGNwdT0zDQogMDAwMDAwMDAwMDAw
MDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBDUFVbMDRdICAgc29ydD05ODMsIHNp
Ymxpbmc9MTAsIDAwMDAwMDAwMDAwMDAwMDBjb3JlPTNmDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSAJcnVuOiAwMDAwMDAwMDAwMDAwMDAwWzAuNF0gcHJpPS0yIGZsYWdzPTAg
Y3B1PTQgY3JlZGl0PS0xMTExNiBbdz0yNTZdDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTJdIAkgIDE6ICBbMzI3NjcuNF0gcHJpPS02NCBmbGFncz0wIGNwdT00DQogMDAwMDAwMDAw
MDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBDUFVbMDVdICAgc29ydD05ODMs
IHNpYmxpbmc9MjAsIDAwMDAwMDAwMDAwMDAwMDBjb3JlPTNmDQogICAgICAgKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTJdIAlydW46IDAwMDAwMDAwMDAwMDAwMDBbMC41XSBwcmk9LTEg
ZmxhZ3M9MCBjcHU9NSBjcmVkaXQ9LTExMzEzIFt3PTI1Nl0NCiAoWEVOKSBbMjAxMy0wMi0y
NyAxMToyMjo1Ml0gCSAgMTogIFszMjc2Ny41XSBwcmk9LTY0IGZsYWdzPTAgY3B1PTUNCiAw
MDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIFtzOiBkdW1wIHNv
ZnR0c2Mgc3RhdHNdDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSBUU0MgbWFya2Vk
IGFzIHJlbGlhYmxlLCB3YXJwID0gMCAoY291bnQ9MikNCiAwMDAwMDAwMDAwMDAwMDAwKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIE5vIGRvbWFpbnMgaGF2ZSBlbXVsYXRlZCBUU0MN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIFt0OiBkaXNwbGF5IG11bHRpLWNwdSBj
bG9jayBpbmZvXQ0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
Ml0gU3luY2VkIHN0aW1lIHNrZXc6IG1heD00MTlucyBhdmc9NDE5bnMgc2FtcGxlcz0xIGN1
cnJlbnQ9NDE5bnMNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIFN5bmNlZCBjeWNs
ZXMgc2tldzogbWF4PTY4OCBhdmc9Njg4IHNhbXBsZXM9MSBjdXJyZW50PTY4OA0KIDAwMDAw
MDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gW3U6IGR1bXAgbnVtYSBp
bmZvXQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gJ3UnIHByZXNzZWQgLT4gZHVt
cGluZyBudW1hIGluZm8gKG5vdy0weDI5OkZGQUUyMEZDKQ0KIDAwMDAwMDAwMDAwMDAwMDAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gaWR4MCAtPiBOT0RFMCBzdGFydC0+MCBzaXpl
LT4yNDI0ODMyIGZyZWUtPjE4MTAxNTANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJd
IHBoeXNfdG9fbmlkKDAwMDAwMDAwMDAwMDEwMDApIC0+IDAgc2hvdWxkIGJlIDANCiAwMDAw
MDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIENQVTAgLT4gTk9ERTAN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIENQVTEgLT4gTk9ERTANCiAwMDAwMDAw
MDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIENQVTIgLT4gTk9ERTANCiAg
ICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gQ1BVMyAtPiBOT0RFMA0KIDAwMDAw
MDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gQ1BVNCAtPiBOT0RFMA0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gQ1BVNSAtPiBOT0RFMA0KIDAwMDAwMDAw
MDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gTWVtb3J5IGxvY2F0aW9uIG9m
IGVhY2ggZG9tYWluOg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gRG9tYWluIDAg
KHRvdGFsOiAyNjIxNDQpOg0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1Ml0gICAgIE5vZGUgMDogMjYyMTQ0DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUyXSBbdjogZHVtcCBBTUQtViBWTUNCc10NCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTJdICoqKioqKioqKioqIFZNQ0IgQXJlYXMgKioqKioqKioqKioq
KioNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdICoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSBbejogcHJpbnQgaW9hcGljIGluZm9dDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KIDAwMDAwMDAwMDAw
MDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gbnVtYmVyIG9mIElPLUFQSUMgIzYg
cmVnaXN0ZXJzOiAyNC4NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIG51bWJlciBv
ZiBJTy1BUElDICM3IHJlZ2lzdGVyczogMzIuDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjUyXSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4NCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIElPIEFQSUMgIzYuLi4u
Li4NCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KICAgICAgIChYRU4pIFsyMDEzLTAyLTI3IDExOjIy
OjUyXSAuLi4uLi4uICAgIDogcGh5c2ljYWwgQVBJQyBpZDogMDYNCiAwMDAwMDAwMDAwMDAw
MDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIC4uLi4uLi4gICAgOiBEZWxpdmVyeSBU
eXBlOiAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSAuLi4uLi4uICAgIDogTFRT
ICAgICAgICAgIDogMA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1Ml0gLi4uLiByZWdpc3RlciAjMDE6IDAwMTc4MDIxDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUyXSAuLi4uLi4uICAgICA6IG1heCByZWRpcmVjdGlvbiBlbnRyaWVzOiAwMDE3
DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSAuLi4uLi4u
ICAgICA6IFBSUSBpbXBsZW1lbnRlZDogMQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
Ml0gLi4uLi4uLiAgICAgOiBJTyBBUElDIHZlcnNpb246IDAwMjENCiAwMDAwMDAwMDAwMDAw
MDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTJdIC4uLi4gcmVnaXN0ZXIgIzAyOiAwNjAw
MDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gLi4uLi4uLiAgICAgOiBhcmJp
dHJhdGlvbjogMDYNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTJdIC4uLi4gcmVnaXN0ZXIgIzAzOiAwNzAwMDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1Ml0gLi4uLi4uLiAgICAgOiBCb290IERUICAgIDogMA0KIDAwMDAwMDAwMDAwMDAw
MDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1Ml0gLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFi
bGU6DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUyXSAgTlIgTG9nIFBoeSBNYXNrIFRy
aWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KIDAwMDAwMDAwMDAwMDAwMDAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDAwIDAwMCAwMCAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUzXSAgMDEgMDAxIDAxICANCiAgICAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgMzANCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NTNdICAwMiAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBG
MA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDAzIDAw
MSAwMSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQogMDAwMDAwMDAw
MDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMDQgMDAxIDAxICAgMCAgICAw
ICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTNdICAwNSAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA0MA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1M10gIDA2IDAwMSAwMSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDQ4DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMDcg
MDAxIDAxICAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCiAwMDAwMDAw
MDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAwOCAwMDEgMDEgICAwICAg
IDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1OA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDA5IDAwMSAwMSAgDQogICAgIDAgICAgMSAgICAw
ICAgMSAgIDAgICAgMSAgICAxICAgIDYwDQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUzXSAgMGEgMDAxIDAxICAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNjgNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTNdICAwYiAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA3MA0K
IDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDBjIDAwMSAw
MSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4DQogMDAwMDAwMDAwMDAw
MDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMGQgMDNGIDBGICAgMSAgICAwICAg
IDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIw
MTMtMDItMjcgMTE6MjI6NTNdICAwZSAwMDEgMDEgICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA5MA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1M10gIDBmIDAwMSAwMSAgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDk4
DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMTAgMDNG
IDBGICAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgRDANCiAwMDAwMDAwMDAw
MDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAxMSAwMDEgMDEgIA0KICAgICAw
ICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICAyMQ0KIDAwMDAwMDAwMDAwMDAwMDAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDEyIDAwMSAwMSAgIDAgICAgMSAgICAwICAg
MSAgIDAgICAgMSAgICAxICAgIEQ4DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAy
LTI3IDExOjIyOjUzXSAgMTMgMDNGIDBGICAgMSAgICAxICAgIDAgICAxICAgMCAgICAxICAg
IDEgICAgQTkNCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNd
ICAxNCAwMDAgMDAgICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIDAw
MDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDE1IDAwMCAwMCAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogMDAwMDAwMDAwMDAwMDAw
MChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMTYgMDAxIDAxICAgMCAgICAxICAgIDAg
ICAxICAgMCAgICAxICAgIDEgICAgOUENCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTNdICAxNyAwMDAgMDAgICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
M10gSU8gQVBJQyAjNy4uLi4uLg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gLi4u
LiByZWdpc3RlciAjMDA6IDA3MDAwMDAwDQogMDAwMDAwMDA4MjA4MjA5NihYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjUzXSAuLi4uLi4uICAgIDogcGh5c2ljYWwgQVBJQyBpZDogMDcNCiAg
ICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gLi4uLi4uLiAgICA6IERlbGl2ZXJ5
IFR5cGU6IDANCiAgICBnbG9iYWwgbWFzazoNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTNdIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQogICAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTNdIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQ0KIGZmZmZmZmZmZmZm
ZmZmZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gLi4uLi4uLiAgICAgOiBtYXggcmVk
aXJlY3Rpb24gZW50cmllczogMDAxRg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10g
Li4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCiBmZmZmZmZmZmZmZmZmZmZmKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTNdIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9u
OiAwMDIxDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUzXSAuLi4uIHJlZ2lzdGVyICMw
MjogMDAwMDAwMDANCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTNdIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjUzXSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCiBmZmZmZmZmZmZmZmZm
ZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJ
UlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjUzXSAgMDAgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAwMSAw
MDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1M10gIDAyIDAwMCAwMCAgZmZmZmZm
ZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjUzXSAgMDMgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAgICAgICAoWEVOKSBbMjAxMy0w
Mi0yNyAxMToyMjo1M10gIDA0IDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjUz
XSAgMDUgMDAxIDAxICBmZmZmZmZmZmZmZmZmZmZmMCAgICAxICAgIDAgICAxICAgMCAgICAx
ICAgIDEgICAgMjkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTNdICAwNiAwMDEgMDEg
IGZmZmZmZmZmZmZmZmZmZmYwICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICAzMQ0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDA3IDAwMSAwMSAgZmZmZmZmZmZmZmZm
ZmZmZjAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDM5DQogIChYRU4pIFsyMDEz
LTAyLTI3IDExOjIyOjU0XSAgMDggMDNGIDBGICBmZmZmZmZmZmZmZmZmZmZmMSAgICAxICAg
IDAgICAxICAgMCAgICAxICAgIDEgICAgOTkNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6
NTRdICAwOSAwM0YgMEYgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDEgICAgMCAgIDEgICAwICAg
IDEgICAgMSAgICBBMg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDBhIDAwMCAw
MCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMGIgMDAwIDAwICBmZmZmZmZmZmZm
ZmZmZmZmMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAgICAgICAoWEVO
KSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDBjIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3
IDExOjIyOjU0XSAgMGQgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdICAw
ZSAwMDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDBmIDAwMCAwMCAgZmZm
ZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChY
RU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMTAgMDAxIDAxICBmZmZmZmZmZmZmZmZmZmZm
MSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNDkNCiAgKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTRdICAxMSAwMDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0g
IDEyIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMTMgMDAwIDAwICBm
ZmZmZmZmZmZmZmZmZmZmMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAg
ICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDE0IDAwMCAwMCAgZmZmZmZmZmZm
ZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsy
MDEzLTAyLTI3IDExOjIyOjU0XSAgMTUgMDAwIDAwICBmZmZmZmZmZmZmZmZmZmZmMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NTRdICAxNiAwM0YgMEYgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDEgICAgMCAgIDEgICAw
ICAgIDEgICAgMSAgICBCOQ0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDE3IDAw
MSAwMSAgZmZmZmZmZmZmZmZmZmZmZjAgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAg
IDkyDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMTggMDAxIDAxICBmZmZmZmZm
ZmZmZmZmZmZmMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgNDENCiAgKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTRdICAxOSAwMDAgMDAgIGZmZmZmZmZmZmZmZmZmZmYxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1NF0gIDFhIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMWIg
MDNGIDBGICBmZmZmZmZmZmZmZmZmZmZmMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEg
ICAgQzkNCiAgICAgICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gIDFjIDAzRiAwRiAg
ZmZmZmZmZmZmZmZmZmZmZjEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIEI4DQog
IChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSAgMWQgMDNGIDBGICBmZmZmZmZmZmZmZmZm
ZmZmMSAgICAxICAgIDAgICAxICAgMCAgICAxICAgIDEgICAgQzANCiAgKFhFTikgWzIwMTMt
MDItMjcgMTE6MjI6NTRdICAxZSAwM0YgMEYgIGZmZmZmZmZmZmZmZmZmZmYxICAgIDEgICAg
MCAgIDEgICAwICAgIDEgICAgMSAgICBDOA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
NF0gIDFmIDAwMCAwMCAgZmZmZmZmZmZmZmZmZmZmZjEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSBVc2luZyB2ZWN0
b3ItYmFzZWQgaW5kZXhpbmcNCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcg
MTE6MjI6NTRdIElSUSB0byBwaW4gbWFwcGluZ3M6DQogIChYRU4pIFsyMDEzLTAyLTI3IDEx
OjIyOjU0XSBJUlEyNDAgZmZmZmZmZmZmZmZmZmZmZi0+IDA6MiANCiBmZmZmZmZmZmZmZmZm
ZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTQ4ICAtPiAwOjENCiAoWEVOKSBb
MjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRNTYgZmZmZmZmZmZmZmZmZmZmZi0+IDA6Mw0KICAg
ICANCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTI0
MSAgLT4gMDo0ZmZmZmZmZmZmZmZmZmZmZg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1
NF0gSVJRNjQgZmZmZmZmZmZmZmZmZmZmZi0+IDA6NSANCiBmZmZmZmZmZmZmZmZmZmZmKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTcyICAtPiAwOjZmZmZmZmZmZmZmZmZmZmZm
DQogIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSBJUlE4MCBmZmZmZmZmZmZmZmZmZmZm
LT4gMDo3IA0KIGZmZmZmZmZmZmZmZmZmZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0g
SVJRODggIC0+IDA6OA0KIChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU0XSBJUlE5NiBmZmZm
ZmZmZmZmZmZmZmZmLT4gMDo5DQogICAgIA0KIGZmZmZmZmZmZmZmZmZmZmYoWEVOKSBbMjAx
My0wMi0yNyAxMToyMjo1NF0gSVJRMTA0ICAtPiAwOjEwZmZmZmZmZmZmZmZmZmZmZg0KICAo
WEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMTEyIGZmZmZmZmZmZmZmZmZmZmYtPiAw
OjExIA0KIGZmZmZmZmZmZmZmZmZmZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJR
MTIwICAtPiAwOjEyZmZmZmZmZmZmZmZmZmZmZg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToy
Mjo1NF0gSVJRMTM2IGZmZmZmZmZmZmZmZmZmZmYtPiAwOjEzIA0KIGZmZmZmZmZmZmZmZmZm
ZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMTQ0ICAtPiAwOjE0DQogKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTRdIElSUTE1MiBmZmZmZmZmZmZmZmZmZmZmLT4gMDoxNQ0K
ICAgICANCiBmZmZmZmZmZmZmZmZmZmZmKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRdIElS
UTIwOCAgLT4gMDoxNmZmZmZmZmZmZmZmZmZmZmYNCiAgKFhFTikgWzIwMTMtMDItMjcgMTE6
MjI6NTRdIElSUTMzIGZmZmZmZmZmZmZmZmZmZmYtPiAwOjE3IA0KIGZmZmZmZmZmZmZmZmZm
ZmYoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMjE2ICAtPiAwOjE4ZmZmZmZmZmZm
ZmZmZmZmZg0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NF0gSVJRMTY5IGZmZmZmZmZm
ZmZmZmZmZmYtPiAwOjE5IA0KIGZmZmZmZmZmZmZmZmZmZjgoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1NF0gSVJRMTU0ICAtPiAwOjIyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTRd
IElSUTQxIDAwMDAwMjAwMDAwMDAwMDEtPiAxOjUNCiAgICAgDQogKFhFTikgWzIwMTMtMDIt
MjcgMTE6MjI6NTVdIElSUTQ5IA0KICBnbG9iYWxseSB1bm1hcy0+IDE6NmtlZDoNCiAgICAg
DQogMDAwMDAwMDAwMDAwMDAwMChYRU4pIFsyMDEzLTAyLTI3IDExOjIyOjU1XSBJUlE1NyAg
LT4gMTo3MDAwMDAwMDAwMDAwMDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0g
SVJRMTUzIDAwMDAwMDAwMDAwMDAwMDAtPiAxOjggDQogMDAwMDAwMDAwMDAwMDAwMChYRU4p
IFsyMDEzLTAyLTI3IDExOjIyOjU1XSBJUlExNjIgIC0+IDE6OTAwMDAwMDAwMDAwMDAwMDAN
CiAgKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTVdIElSUTczIDAwMDAwMDAwMDAwMDAwMDAt
PiAxOjE2IA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0g
SVJRMTg1ICAtPiAxOjIyDQogKFhFTikgWzIwMTMtMDItMjcgMTE6MjI6NTVdIElSUTE0NiAw
MDAwMDAwMDAwMDAwMDAwLT4gMToyMw0KICAgICANCiAwMDAwMDAwMDAwMDAwMDAwKFhFTikg
WzIwMTMtMDItMjcgMTE6MjI6NTVdIElSUTY1ICAtPiAxOjI0MDAwMDAwMDAwMDAwMDAwMA0K
ICAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0gSVJRMjAxIDAwMDAwMDAwMDAwMDAwMDAt
PiAxOjI3IA0KIDAwMDAwMDAwMDAwMDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0g
SVJRMTg0ICAtPiAxOjI4MDAwMDAwMDAwMDAwMDAwMA0KICAoWEVOKSBbMjAxMy0wMi0yNyAx
MToyMjo1NV0gSVJRMTkyIDAwMDAwMDAwMDAwMDAwMDAtPiAxOjI5IA0KIDAwMDAwMDAwMDAw
MDAwMDAoWEVOKSBbMjAxMy0wMi0yNyAxMToyMjo1NV0gSVJRMjAwICAtPiAxOjMwDQogKFhF
TikgWzIwMTMtMDItMjcgMTE6MjI6NTVdIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLiBkb25lLg0KIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwODIwODIwODINCiAgICAgDQogIGxvY2FsIGNwdTEgbWFzazoNCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMWY4MA0KICAg
ICANCiAgbG9jYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDA4MA0KICAgICANCiAgcGVuZGluZyBsaXN0Og0KICBb
ICAxODQuMTU5MzUxXSAgIDA6IGV2ZW50IDEgLT4gaXJxIDcyIGxvY2FsbHktbWFza2VkDQog
IFsgIDE4NC4xNzY1NjJdICAgMTogZXZlbnQgNyAtPiBpcnEgNzgNCiAgWyAgMTg0LjE4OTg1
OV0gICAyOiBldmVudCAxMyAtPiBpcnEgODQgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg0LjIw
NzQwMF0gICAzOiBldmVudCAxOSAtPiBpcnEgOTAgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg0
LjIyNDk1N10gICA0OiBldmVudCAyNSAtPiBpcnEgOTYgbG9jYWxseS1tYXNrZWQNCiAgWyAg
MTg0LjI0MjU1OV0gICA1OiBldmVudCAzMSAtPiBpcnEgMTAyIGxvY2FsbHktbWFza2VkDQog
IFsgIDE4NC4yNjA0ODddIA0KICB2Y3B1IDQNCiAgICAwOiBtYXNrZWQ9MSBwZW5kaW5nPTAg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDANCiAgICAxOiBtYXNrZWQ9MCBwZW5kaW5nPTAg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDANCiAgICAyOiBtYXNrZWQ9MSBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICAzOiBtYXNrZWQ9MSBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICA0OiBtYXNrZWQ9MCBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICA1OiBtYXNrZWQ9MSBwZW5kaW5nPTEg
ZXZlbnRfc2VsIDAwMDAwMDAwMDAwMDAwMDENCiAgICANCiAgcGVuZGluZzoNCiAgICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA4MjA4MjAwMg0KICAgICAN
CiAgZ2xvYmFsIG1hc2s6DQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAg
ICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZm
ZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZm
ZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZm
ZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZm
ZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmY4
IDAwMDAwMjAwMDAwMDAwMDENCiAgICAgDQogIGdsb2JhbGx5IHVubWFza2VkOg0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDgyMDgyMDAyDQogICAg
IA0KICBsb2NhbCBjcHU0IG1hc2s6DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAg
ICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwN2UwMDAwMDANCiAgICAgDQogIGxvY2FsbHkgdW5tYXNrZWQ6DQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDIwMDAwMDAN
CiAgICAgDQogIHBlbmRpbmcgbGlzdDoNCiAgWyAgMTg2LjAyMjQyMV0gICAwOiBldmVudCAx
IC0+IGlycSA3MiBsb2NhbGx5LW1hc2tlZA0KICBbICAxODYuMDM5NjA5XSAgIDI6IGV2ZW50
IDEzIC0+IGlycSA4NCBsb2NhbGx5LW1hc2tlZA0KICBbICAxODYuMDU3MTA1XSAgIDM6IGV2
ZW50IDE5IC0+IGlycSA5MCBsb2NhbGx5LW1hc2tlZA0KICBbICAxODYuMDc0NjM5XSAgIDQ6
IGV2ZW50IDI1IC0+IGlycSA5Ng0KICBbICAxODYuMDg4MjYyXSAgIDU6IGV2ZW50IDMxIC0+
IGlycSAxMDIgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg2LjEwNjEzM10gDQogIHZjcHUgNQ0K
ICAgIDA6IG1hc2tlZD0xIHBlbmRpbmc9MCBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgIDE6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgIDI6IG1hc2tlZD0xIHBlbmRpbmc9MSBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMQ0K
ICAgIDM6IG1hc2tlZD0xIHBlbmRpbmc9MSBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMQ0K
ICAgIDQ6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgIDU6IG1hc2tlZD0wIHBlbmRpbmc9MSBldmVudF9zZWwgMDAwMDAwMDAwMDAwMDAwMQ0K
ICAgIA0KICBwZW5kaW5nOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDgwMDgyMDAyDQogICAgIA0KICBnbG9iYWwgbWFzazoNCiAgICAgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
Zg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0KICAg
ICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZm
ZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZm
ZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZjggMDAwMDAyMDAwMDAwMDAwMQ0KICAgICANCiAg
Z2xvYmFsbHkgdW5tYXNrZWQ6DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwODAwODIwMDINCiAgICAgDQogIGxvY2FsIGNwdTUgbWFzazoNCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMWY4MDAwMDAwMA0KICAg
ICANCiAgbG9jYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDA4MDAwMDAwMA0KICAgICANCiAgcGVuZGluZyBsaXN0Og0KICBb
ICAxODcuODcwOTA5XSAgIDA6IGV2ZW50IDEgLT4gaXJxIDcyIGxvY2FsbHktbWFza2VkDQog
IFsgIDE4Ny44ODgxMThdICAgMjogZXZlbnQgMTMgLT4gaXJxIDg0IGxvY2FsbHktbWFza2Vk
DQogIFsgIDE4Ny45MDU2NTVdICAgMzogZXZlbnQgMTkgLT4gaXJxIDkwIGxvY2FsbHktbWFz
a2VkDQogIFsgIDE4Ny45MjMxNjRdICAgNTogZXZlbnQgMzEgLT4gaXJxIDEwMg0KICBbICAx
ODcuOTM3MDk1XSANCiAgdmNwdSAwDQogICAgMDogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMTogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMjogbWFza2VkPTEgcGVuZGluZz0xIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAxDQogICAgMzogbWFza2VkPTEgcGVuZGluZz0xIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAxDQogICAgNDogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgNTogbWFza2VkPTAgcGVuZGluZz0wIGV2ZW50
X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgDQogIHBlbmRpbmc6DQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAN
CiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwODIwMDINCiAgICAgDQogIGds
b2JhbCBtYXNrOg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZg0K
ICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZm
ZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBm
ZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmOCAwMDAw
MDIwMDAwMDAwMDAxDQogICAgIA0KICBnbG9iYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAg
ICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDA4MjAwMg0KICAgICANCiAg
bG9jYWwgY3B1MCBtYXNrOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
NyBmZmZmZmZlMDAwMDAwMDdmDQogICAgIA0KICBsb2NhbGx5IHVubWFza2VkOg0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
DQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAyDQogICAg
IA0KICBwZW5kaW5nIGxpc3Q6DQogIFsgIDE4OS43MDA4OTddICAgMDogZXZlbnQgMSAtPiBp
cnEgNzIgbDItY2xlYXINCiAgWyAgMTg5LjcxNjU2MV0gICAyOiBldmVudCAxMyAtPiBpcnEg
ODQgbDItY2xlYXIgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg5LjczNjQzOF0gICAzOiBldmVu
dCAxOSAtPiBpcnEgOTAgbDItY2xlYXIgbG9jYWxseS1tYXNrZWQNCiAgWyAgMTg5Ljc1NjMz
M10gDQogIHZjcHUgMw0KICAgIDA6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIDE6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIDI6IG1hc2tlZD0xIHBlbmRpbmc9MSBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMQ0KICAgIDM6IG1hc2tlZD0wIHBlbmRpbmc9MSBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMQ0KICAgIDQ6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIDU6IG1hc2tlZD0wIHBlbmRpbmc9MCBldmVudF9zZWwgMDAw
MDAwMDAwMDAwMDAwMA0KICAgIA0KICBwZW5kaW5nOg0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAN
CiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDg2MDAwDQogICAgIA0KICBnbG9iYWwgbWFz
azoNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAg
ICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZjggMDAwMDAyMDAwMDAw
MDAwMQ0KICAgICANCiAgZ2xvYmFsbHkgdW5tYXNrZWQ6DQogICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwODYwMDANCiAgICAgDQogIGxvY2FsIGNw
dTMgbWFzazoNCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMWY4MDAwMA0KICAgICANCiAgbG9jYWxseSB1bm1hc2tlZDoNCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDA4MDAwMA0KICAgICANCiAgcGVu
ZGluZyBsaXN0Og0KICBbICAxOTEuNTIyNDg2XSAgIDI6IGV2ZW50IDEzIC0+IGlycSA4NCBs
b2NhbGx5LW1hc2tlZA0KICBbICAxOTEuNTM5OTQzXSAgIDI6IGV2ZW50IDE0IC0+IGlycSA4
NSBsb2NhbGx5LW1hc2tlZA0KICBbICAxOTEuNTU3NDE3XSAgIDM6IGV2ZW50IDE5IC0+IGly
cSA5MA0KICBbICAxOTEuNTcxMDEwXSANCiAgdmNwdSAyDQogICAgMDogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMTogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgMjogbWFza2VkPTAgcGVu
ZGluZz0xIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAxDQogICAgMzogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgNDogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgNTogbWFza2VkPTAgcGVu
ZGluZz0wIGV2ZW50X3NlbCAwMDAwMDAwMDAwMDAwMDAwDQogICAgDQogIHBlbmRpbmc6DQog
ICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAw
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDYwMDAN
CiAgICAgDQogIGdsb2JhbCBtYXNrOg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZm
ZmZmZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYNCiAgICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZm
ZmZmZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZm
ZmYgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAg
ICAgZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmDQogICAgIGZmZmZmZmZmZmZmZmZmZmYg
ZmZmZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZg0KICAgICBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYNCiAgICAgZmZm
ZmZmZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmZmZmZmZmZmZmZmZmIGZmZmZmZmZmZmZmZmZmZmYgZmZmZmZmZmZm
ZmZmZmZmOCAwMDAwMDIwMDAwMDAwMDAxDQogICAgIA0KICBnbG9iYWxseSB1bm1hc2tlZDoN
CiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwNjAw
MA0KICAgICANCiAgbG9jYWwgY3B1MiBtYXNrOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAw
MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAw
MDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAw
MDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMA0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAw
MDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAg
ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAg
MDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDdlMDAwDQogICAgIA0KICBsb2NhbGx5IHVubWFz
a2VkOg0KICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
ICAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwDQogICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KICAgICAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCiAgICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAw
MDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDA2MDAwDQogICAgIA0KICBwZW5kaW5nIGxpc3Q6DQogIFsgIDE5My4zMzIyNDddICAgMjog
ZXZlbnQgMTMgLT4gaXJxIDg0DQogIFsgIDE5My4zNDU3MjddICAgMjogZXZlbnQgMTQgLT4g
aXJxIDg1DQogIA==
------------0FB1ED1493275D29B
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0FB1ED1493275D29B--



From xen-devel-bounces@lists.xen.org Wed Feb 27 11:48:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAfUe-0001N6-PF; Wed, 27 Feb 2013 11:48: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 1UAfUd-0001My-T1
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:48:16 +0000
Received: from [193.109.254.147:8670] by server-6.bemta-14.messagelabs.com id
	AA/D6-12010-F72FD215; Wed, 27 Feb 2013 11:48:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361965663!9240362!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1120 invoked from network); 27 Feb 2013 11:47:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:47:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1949773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:47: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.297.1; Wed, 27 Feb 2013 11:47:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAfU7-000613-E3; Wed, 27 Feb 2013 11:47:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAfU7-0003KG-3i;
	Wed, 27 Feb 2013 11:47:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.62046.887326.863656@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 11:47:42 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512DD6EB02000078000C159C@nat28.tlf.novell.com>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
	<512DD6EB02000078000C159C@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xi Wang <xi@mit.edu>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir.xen@gmail.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86: fix
 null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich writes ("Hazardous memset/memcpy idiom (was Re: [Xen-devel] [PATCH] x86: fix null pointer dereference in intel_get_extended_msrs())"):
> Unfortunately that wouldn't be usable in all cases (arrays passed
> to functions),

 #define FILLZERO_ARRAY(arrayobj, num_elements) \
    (memset((arrayobj),0,sizeof((arrayobj)[0])*(num_elements)))

And the fact that a macro isn't universally applicable isn't a reason
not to replace an error-prone idiom in the very frequent cases where
the macro would be applicable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:48:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAfUe-0001N6-PF; Wed, 27 Feb 2013 11:48: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 1UAfUd-0001My-T1
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 11:48:16 +0000
Received: from [193.109.254.147:8670] by server-6.bemta-14.messagelabs.com id
	AA/D6-12010-F72FD215; Wed, 27 Feb 2013 11:48:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361965663!9240362!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1120 invoked from network); 27 Feb 2013 11:47:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 11:47:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1949773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 11:47: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.297.1; Wed, 27 Feb 2013 11:47:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAfU7-000613-E3; Wed, 27 Feb 2013 11:47:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAfU7-0003KG-3i;
	Wed, 27 Feb 2013 11:47:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.62046.887326.863656@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 11:47:42 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512DD6EB02000078000C159C@nat28.tlf.novell.com>
References: <1361598228-25041-1-git-send-email-xi@mit.edu>
	<20780.60434.402629.740920@mariner.uk.xensource.com>
	<512DD6EB02000078000C159C@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xi Wang <xi@mit.edu>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir.xen@gmail.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] Hazardous memset/memcpy idiom (was Re: [PATCH] x86: fix
 null pointer dereference in intel_get_extended_msrs())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich writes ("Hazardous memset/memcpy idiom (was Re: [Xen-devel] [PATCH] x86: fix null pointer dereference in intel_get_extended_msrs())"):
> Unfortunately that wouldn't be usable in all cases (arrays passed
> to functions),

 #define FILLZERO_ARRAY(arrayobj, num_elements) \
    (memset((arrayobj),0,sizeof((arrayobj)[0])*(num_elements)))

And the fact that a macro isn't universally applicable isn't a reason
not to replace an error-prone idiom in the very frequent cases where
the macro would be applicable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 11:59:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAffZ-0001hl-28; Wed, 27 Feb 2013 11:59: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 1UAffX-0001hg-P8
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:59:31 +0000
Received: from [193.109.254.147:13887] by server-4.bemta-14.messagelabs.com id
	2E/E9-20719-225FD215; Wed, 27 Feb 2013 11:59:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361966325!2645406!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3982 invoked from network); 27 Feb 2013 11:58:47 -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;
	27 Feb 2013 11:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9956989"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 11:58:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 06:58:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAfec-0000KX-8D;
	Wed, 27 Feb 2013 11:58:34 +0000
Date: Wed, 27 Feb 2013 11:58:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1279153555-1361966310=:5360"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1279153555-1361966310=:5360
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 27 Feb 2013, George Dunlap wrote:
> What about this: We obviously have users who are keen to have this functi=
onality, and in fact who have made local versions of
> such functionality to use themselves.=C2=A0 If one of them is willing to =
step up and officially maintain such functionality (which
> would include responding to bugs and updating things on a regular basis),=
 then I think we should consider accepting such a
> patch.=C2=A0 If it ever becomes unmaintained, then we'll take it out.=C2=
=A0 That way the core devs won't have to be involved in package
> management, but early-adopters will have the benefit of being able to use=
 Xen more easily.


I think that is the right way of thinking. After all we even have a
differentiation between maintainers and committers exactly for this sort
of cases (even though right now we aren't using it much).

So the question is, would anybody step up to maintain a proper deb build
target?
--1342847746-1279153555-1361966310=:5360
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1279153555-1361966310=:5360--


From xen-devel-bounces@lists.xen.org Wed Feb 27 11:59:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 11: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 1UAffZ-0001hl-28; Wed, 27 Feb 2013 11:59: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 1UAffX-0001hg-P8
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 11:59:31 +0000
Received: from [193.109.254.147:13887] by server-4.bemta-14.messagelabs.com id
	2E/E9-20719-225FD215; Wed, 27 Feb 2013 11:59:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1361966325!2645406!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3982 invoked from network); 27 Feb 2013 11:58:47 -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;
	27 Feb 2013 11:58:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9956989"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 11:58:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 06:58:34 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UAfec-0000KX-8D;
	Wed, 27 Feb 2013 11:58:34 +0000
Date: Wed, 27 Feb 2013 11:58:30 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1279153555-1361966310=:5360"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-1279153555-1361966310=:5360
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 27 Feb 2013, George Dunlap wrote:
> What about this: We obviously have users who are keen to have this functi=
onality, and in fact who have made local versions of
> such functionality to use themselves.=C2=A0 If one of them is willing to =
step up and officially maintain such functionality (which
> would include responding to bugs and updating things on a regular basis),=
 then I think we should consider accepting such a
> patch.=C2=A0 If it ever becomes unmaintained, then we'll take it out.=C2=
=A0 That way the core devs won't have to be involved in package
> management, but early-adopters will have the benefit of being able to use=
 Xen more easily.


I think that is the right way of thinking. After all we even have a
differentiation between maintainers and committers exactly for this sort
of cases (even though right now we aren't using it much).

So the question is, would anybody step up to maintain a proper deb build
target?
--1342847746-1279153555-1361966310=:5360
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-1279153555-1361966310=:5360--


From xen-devel-bounces@lists.xen.org Wed Feb 27 12:02:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAfhz-0001xe-2p; Wed, 27 Feb 2013 12:02: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 1UAfhx-0001xX-H8
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:02:01 +0000
Received: from [85.158.139.83:28448] by server-13.bemta-5.messagelabs.com id
	09/D3-16871-8B5FD215; Wed, 27 Feb 2013 12:02:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361966496!27427815!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 27 Feb 2013 12:01:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1950568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:01: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.297.1; Wed, 27 Feb 2013 12:01:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAfhU-00065B-JF	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:01:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAfhU-0003LV-94	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:01:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.62875.686221.389155@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:01:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-16754-mainreport@xen.org>
References: <osstest-16754-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 16754: 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

xen.org writes ("[xen-unstable test] 16754: regressions - FAIL"):
> flight 16754 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16754/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            4 xen-build            fail REGR. vs. 16226
>  build-i386-pvops              4 kernel-build         fail REGR. vs. 16226
>  build-i386                    4 xen-build            fail REGR. vs. 16226

The machine being used for the build here seems to have had some kind
of problem:

Feb 27 02:27:10.399056 bush-cricket login: [  360.428017] INFO: task kjournald:353 blocked for more than 120 seconds.
Feb 27 02:33:01.027104 [  360.434684] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 27 02:33:01.039052 [  360.442657] INFO: task resize2fs:15202 blocked for more than 120 seconds.
Feb 27 02:33:01.047033 [  360.449495] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 27 02:33:01.047083 [  360.457455] INFO: task git:16070 blocked for more than 120 seconds.
...

The failure resulted in the tester trying to collect logs and none of
the ssh commands to do that succeeded.

This looks like a bug in the i386 kernel in Debian squeeze.  Xen is
not involved at this point.  I guess the failure can't be very common
so we can just hope it doesn't do it again too soon.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:02:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAfhz-0001xe-2p; Wed, 27 Feb 2013 12:02: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 1UAfhx-0001xX-H8
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:02:01 +0000
Received: from [85.158.139.83:28448] by server-13.bemta-5.messagelabs.com id
	09/D3-16871-8B5FD215; Wed, 27 Feb 2013 12:02:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361966496!27427815!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 27 Feb 2013 12:01:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1950568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:01: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.297.1; Wed, 27 Feb 2013 12:01:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAfhU-00065B-JF	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:01:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAfhU-0003LV-94	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:01:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.62875.686221.389155@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:01:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-16754-mainreport@xen.org>
References: <osstest-16754-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 16754: 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

xen.org writes ("[xen-unstable test] 16754: regressions - FAIL"):
> flight 16754 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16754/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            4 xen-build            fail REGR. vs. 16226
>  build-i386-pvops              4 kernel-build         fail REGR. vs. 16226
>  build-i386                    4 xen-build            fail REGR. vs. 16226

The machine being used for the build here seems to have had some kind
of problem:

Feb 27 02:27:10.399056 bush-cricket login: [  360.428017] INFO: task kjournald:353 blocked for more than 120 seconds.
Feb 27 02:33:01.027104 [  360.434684] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 27 02:33:01.039052 [  360.442657] INFO: task resize2fs:15202 blocked for more than 120 seconds.
Feb 27 02:33:01.047033 [  360.449495] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 27 02:33:01.047083 [  360.457455] INFO: task git:16070 blocked for more than 120 seconds.
...

The failure resulted in the tester trying to collect logs and none of
the ssh commands to do that succeeded.

This looks like a bug in the i386 kernel in Debian squeeze.  Xen is
not involved at this point.  I guess the failure can't be very common
so we can just hope it doesn't do it again too soon.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:05:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:05: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 1UAflP-00028E-SG; Wed, 27 Feb 2013 12:05: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 1UAflO-000288-Kp
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:05:34 +0000
Received: from [85.158.137.99:46406] by server-3.bemta-3.messagelabs.com id
	DA/70-26934-D86FD215; Wed, 27 Feb 2013 12:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361966732!13231630!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5212 invoked from network); 27 Feb 2013 12:05:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1950710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12: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.297.1; Wed, 27 Feb 2013 12:05:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAflM-00066T-6d	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:05:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAflM-0003Lr-2i	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:05:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.63115.853719.513749@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:05:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-16753-mainreport@xen.org>
References: <osstest-16753-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.1-testing test] 16753: 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

xen.org writes ("[xen-4.1-testing test] 16753: regressions - FAIL"):
> flight 16753 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16753/
> 
> 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. 16678

This is the "connection reset by peer" problem cloning
linux-2.6.18.hg, again.  I have just tried this command in a shell
window and it did this, taking just under half an hour:

$ hg clone http://xenbits.xen.org/linux-2.6.18-xen.hg
destination directory: linux-2.6.18-xen.hg
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: Connection reset by peer
$

I attached strace to it just before it failed:

  Process 12756 attached - interrupt to quit
  recv(3, ^C <unfinished ...>
  Process 12756 detached

There is NAT between the build host (and my workstation) and xenbits.
So I think what is happening is that the transfer is stalling for some
reason and then eventually it falls out of the NAT table and one gets
ECONNRESET.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:05:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:05: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 1UAflP-00028E-SG; Wed, 27 Feb 2013 12:05: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 1UAflO-000288-Kp
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:05:34 +0000
Received: from [85.158.137.99:46406] by server-3.bemta-3.messagelabs.com id
	DA/70-26934-D86FD215; Wed, 27 Feb 2013 12:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1361966732!13231630!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5212 invoked from network); 27 Feb 2013 12:05:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:05:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1950710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12: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.297.1; Wed, 27 Feb 2013 12:05:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAflM-00066T-6d	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:05:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAflM-0003Lr-2i	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:05:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.63115.853719.513749@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:05:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-16753-mainreport@xen.org>
References: <osstest-16753-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.1-testing test] 16753: 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

xen.org writes ("[xen-4.1-testing test] 16753: regressions - FAIL"):
> flight 16753 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16753/
> 
> 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. 16678

This is the "connection reset by peer" problem cloning
linux-2.6.18.hg, again.  I have just tried this command in a shell
window and it did this, taking just under half an hour:

$ hg clone http://xenbits.xen.org/linux-2.6.18-xen.hg
destination directory: linux-2.6.18-xen.hg
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: Connection reset by peer
$

I attached strace to it just before it failed:

  Process 12756 attached - interrupt to quit
  recv(3, ^C <unfinished ...>
  Process 12756 detached

There is NAT between the build host (and my workstation) and xenbits.
So I think what is happening is that the transfer is stalling for some
reason and then eventually it falls out of the NAT table and one gets
ECONNRESET.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:17:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAfwd-0002V4-O8; Wed, 27 Feb 2013 12:17: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 1UAfwc-0002Uu-9t
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:17:10 +0000
Received: from [85.158.139.83:55067] by server-14.bemta-5.messagelabs.com id
	69/24-13158-549FD215; Wed, 27 Feb 2013 12:17:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361967428!22001951!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4819 invoked from network); 27 Feb 2013 12:17:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:17:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1951125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:17: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.297.1;
	Wed, 27 Feb 2013 12:17:08 +0000
Message-ID: <1361967427.26546.368.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Wed, 27 Feb 2013 12:17:07 +0000
In-Reply-To: <20130226223249.GD27098@waldi.eu.org>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
	<20130226223249.GD27098@waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 22:32 +0000, Bastian Blank wrote:
> Add trusted decompressors based on hypervisor code.
> This are used in mini-os by pv-grub.

I think this is a reasonably pragmatic way to arrange the build.

I'm not sure "trusted" is quite the right term though, these aren't
really any more trustworthy than the library supplied ones -- they are
just more suitable for a mini-os environment.

I can't think of a better term though...

> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> diff -r efdc4bbfdd20 stubdom/Makefile
> --- a/stubdom/Makefile	Tue Feb 26 19:42:36 2013 +0100
> +++ b/stubdom/Makefile	Tue Feb 26 23:20:22 2013 +0100
> @@ -328,7 +328,7 @@
>  .PHONY: libxc
>  libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a
>  libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib
> -	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH)
> +	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH)
>  
>   libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a
>  
> diff -r efdc4bbfdd20 tools/libxc/Makefile
> --- a/tools/libxc/Makefile	Tue Feb 26 19:42:36 2013 +0100
> +++ b/tools/libxc/Makefile	Tue Feb 26 23:20:22 2013 +0100
> @@ -58,7 +58,6 @@
>  GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
>  GUEST_SRCS-y                 += xc_dom_elfloader.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_dom_bzimageloader.c
> -GUEST_SRCS-$(CONFIG_X86)     += xc_dom_decompress.c
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
>  GUEST_SRCS-y                 += xc_dom_binloader.c
>  GUEST_SRCS-y                 += xc_dom_compat_linux.c
> @@ -69,6 +68,16 @@
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
>  
> +ifeq ($(CONFIG_LIBXC_MINIOS),y)
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_bzip2.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzma.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzo1x.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_xz.c
> +else
> +GUEST_SRCS-y                 += xc_dom_decompress.c
> +endif
> +
>  OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
>  
>  -include $(XEN_TARGET_ARCH)/Makefile
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,49 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +struct xc_dom_image *trusted_dom;
> +static unsigned char *output_blob;
> +static unsigned int output_size;
> +
> +static void trusted_error(const char *msg)
> +{
> +    xc_dom_panic(trusted_dom->xch, XC_INVALID_KERNEL, "%s", msg);
> +}
> +
> +static int trusted_flush(void *src, unsigned int size)
> +{
> +    void *n = realloc(output_blob, output_size + size);
> +    if (!n)
> +        return -1;
> +    output_blob = n;
> +
> +    memcpy(&output_blob[output_size], src, size);
> +    output_size += size;
> +    return size;
> +}
> +
> +int xc_dom_decompress_trusted_decompress(
> +    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    int ret;
> +
> +    trusted_dom = dom;
> +    output_blob = NULL;
> +    output_size = 0;
> +
> +    ret = fn(dom->kernel_blob, dom->kernel_size, NULL, trusted_flush, NULL, NULL, trusted_error);
> +
> +    if (ret)
> +        free(output_blob);
> +    else {
> +        *blob = output_blob;
> +        *size = output_size;
> +    }
> +
> +    return ret;
> +}
> +
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted.h	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,12 @@
> +#include "xc_dom.h"
> +
> +typedef int decompress_fn(unsigned char *inbuf, unsigned int len,
> +                          int (*fill)(void*, unsigned int),
> +                          int (*flush)(void*, unsigned int),
> +                          unsigned char *outbuf, unsigned int *posp,
> +                          void (*error)(const char *x));
> +
> +int xc_dom_decompress_trusted_decompress(
> +    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
> +    __attribute__((visibility("hidden")));
> +
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_bzip2.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_bzip2.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,14 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +#include "../../xen/common/bunzip2.c"
> +
> +int xc_try_bzip2_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(bunzip2, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzma.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_lzma.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,14 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +#include "../../xen/common/unlzma.c"
> +
> +int xc_try_lzma_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(unlzma, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzo1x.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_lzo1x.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,15 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +#include "../../xen/common/lzo.c"
> +#include "../../xen/common/unlzo.c"
> +
> +int xc_try_lzo1x_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(unlzo, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_xz.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_xz.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,17 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +// TODO
> +#define XZ_DEC_X86
> +
> +#include "../../xen/common/unxz.c"
> +
> +int xc_try_xz_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(unxz, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 xen/common/decompress.h
> --- a/xen/common/decompress.h	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/decompress.h	Tue Feb 26 23:20:22 2013 +0100
> @@ -1,3 +1,5 @@
> +#ifdef __XEN__
> +
>  #include <xen/config.h>
>  #include <xen/cache.h>
>  #include <xen/decompress.h>
> @@ -15,3 +17,14 @@
>  
>  #define large_malloc xmalloc_bytes
>  #define large_free xfree
> +
> +#else
> +
> +#define STATIC static
> +#define INIT
> +#define INITDATA
> +
> +#define large_malloc malloc
> +#define large_free free
> +
> +#endif
> diff -r efdc4bbfdd20 xen/common/lzo.c
> --- a/xen/common/lzo.c	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/lzo.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -68,7 +68,19 @@
>   *  Richard Purdie <rpurdie@openedhand.com>
>   */
>  
> +#ifndef __MINIOS__
>  #include <xen/types.h>
> +#else
> +#include <stdint.h>
> +
> +typedef uint32_t u32;
> +typedef uint16_t u16;
> +
> +#define likely(a) a
> +#define noinline
> +#define unlikely(a) a
> +#endif
> +
>  #include <xen/lzo.h>
>  #define get_unaligned(_p) (*(_p))
>  #define put_unaligned(_val,_p) (*(_p)=_val)
> diff -r efdc4bbfdd20 xen/common/unlzma.c
> --- a/xen/common/unlzma.c	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/unlzma.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -54,7 +54,9 @@
>   * Copyright (c) 1999-2005  Igor Pavlov
>   */
>  
> +#ifndef __MINIOS__
>  #include <xen/compiler.h>
> +#endif
>  
>  #define LZMA_IOBUF_SIZE	0x10000
>  
> diff -r efdc4bbfdd20 xen/common/unlzo.c
> --- a/xen/common/unlzo.c	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/unlzo.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -32,7 +32,43 @@
>  
>  #include "decompress.h"
>  #include <xen/lzo.h>
> +
> +#ifndef __MINIOS__
>  #include <asm/byteorder.h>
> +#else
> +#include <endian.h>
> +#include <stdint.h>
> +
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +
> +static inline u16 be16_to_cpup(const u16 *p)
> +{
> +	u16 v = *p;
> +#if BYTE_ORDER == LITTLE_ENDIAN
> +	return (((v & 0x00ffU) << 8) |
> +                ((v & 0xff00U) >> 8));
> +#else
> +	return v;
> +#endif
> +}
> +
> +static inline u32 be32_to_cpup(const u32 *p)
> +{
> +	u32 v = *p;
> +#if BYTE_ORDER == LITTLE_ENDIAN
> +	return (((v & 0x000000ffUL) << 24) |
> +                ((v & 0x0000ff00UL) <<  8) |
> +                ((v & 0x00ff0000UL) >>  8) |
> +                ((v & 0xff000000UL) >> 24));
> +#else
> +	return v;
> +#endif
> +}
> +
> +#define unlikely(a) a
> +#endif
>  
>  #if 1 /* ndef CONFIG_??? */
>  static inline u16 INIT get_unaligned_be16(void *p)
> diff -r efdc4bbfdd20 xen/common/xz/private.h
> --- a/xen/common/xz/private.h	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/xz/private.h	Tue Feb 26 23:20:22 2013 +0100
> @@ -10,8 +10,53 @@
>  #ifndef XZ_PRIVATE_H
>  #define XZ_PRIVATE_H
>  
> +#ifndef __MINIOS__
>  #include <xen/kernel.h>
>  #include <asm/byteorder.h>
> +#else
> +#include <endian.h>
> +#include <stddef.h>
> +#include <stdint.h>
> +
> +typedef char bool_t;
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +typedef uint32_t __le32;
> +
> +static inline u32 cpu_to_le32(const u32 v)
> +{
> +#if BYTE_ORDER == BIG_ENDIAN
> +	return (((v & 0x000000ffUL) << 24) |
> +	        ((v & 0x0000ff00UL) <<  8) |
> +	        ((v & 0x00ff0000UL) >>  8) |
> +	        ((v & 0xff000000UL) >> 24));
> +#else  
> +	return v;
> +#endif
> +}
> +
> +static inline u32 le32_to_cpup(const u32 *p)
> +{
> +	return cpu_to_le32(*p);
> +}
> +
> +#define min(x,y) ({ \
> +        const typeof(x) _x = (x);       \
> +        const typeof(y) _y = (y);       \
> +        (void) (&_x == &_y);            \
> +        _x < _y ? _x : _y; })
> +
> +#define min_t(type,x,y) \
> +        ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
> +#define max_t(type,x,y) \
> +        ({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
> +
> +#define __force
> +#define always_inline
> +
> +#endif
> +
>  #define get_le32(p) le32_to_cpup((const uint32_t *)(p))
>  
>  #if 1 /* ndef CONFIG_??? */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:17:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAfwd-0002V4-O8; Wed, 27 Feb 2013 12:17: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 1UAfwc-0002Uu-9t
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:17:10 +0000
Received: from [85.158.139.83:55067] by server-14.bemta-5.messagelabs.com id
	69/24-13158-549FD215; Wed, 27 Feb 2013 12:17:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361967428!22001951!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4819 invoked from network); 27 Feb 2013 12:17:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:17:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1951125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:17: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.297.1;
	Wed, 27 Feb 2013 12:17:08 +0000
Message-ID: <1361967427.26546.368.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Wed, 27 Feb 2013 12:17:07 +0000
In-Reply-To: <20130226223249.GD27098@waldi.eu.org>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
	<20130226223249.GD27098@waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2013-02-26 at 22:32 +0000, Bastian Blank wrote:
> Add trusted decompressors based on hypervisor code.
> This are used in mini-os by pv-grub.

I think this is a reasonably pragmatic way to arrange the build.

I'm not sure "trusted" is quite the right term though, these aren't
really any more trustworthy than the library supplied ones -- they are
just more suitable for a mini-os environment.

I can't think of a better term though...

> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> diff -r efdc4bbfdd20 stubdom/Makefile
> --- a/stubdom/Makefile	Tue Feb 26 19:42:36 2013 +0100
> +++ b/stubdom/Makefile	Tue Feb 26 23:20:22 2013 +0100
> @@ -328,7 +328,7 @@
>  .PHONY: libxc
>  libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a
>  libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib
> -	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH)
> +	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH)
>  
>   libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a
>  
> diff -r efdc4bbfdd20 tools/libxc/Makefile
> --- a/tools/libxc/Makefile	Tue Feb 26 19:42:36 2013 +0100
> +++ b/tools/libxc/Makefile	Tue Feb 26 23:20:22 2013 +0100
> @@ -58,7 +58,6 @@
>  GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
>  GUEST_SRCS-y                 += xc_dom_elfloader.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_dom_bzimageloader.c
> -GUEST_SRCS-$(CONFIG_X86)     += xc_dom_decompress.c
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
>  GUEST_SRCS-y                 += xc_dom_binloader.c
>  GUEST_SRCS-y                 += xc_dom_compat_linux.c
> @@ -69,6 +68,16 @@
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_hvm_build_arm.c
>  
> +ifeq ($(CONFIG_LIBXC_MINIOS),y)
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_bzip2.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzma.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_lzo1x.c
> +GUEST_SRCS-y                 += xc_dom_decompress_trusted_xz.c
> +else
> +GUEST_SRCS-y                 += xc_dom_decompress.c
> +endif
> +
>  OSDEP_SRCS-y                 += xenctrl_osdep_ENOSYS.c
>  
>  -include $(XEN_TARGET_ARCH)/Makefile
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,49 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +struct xc_dom_image *trusted_dom;
> +static unsigned char *output_blob;
> +static unsigned int output_size;
> +
> +static void trusted_error(const char *msg)
> +{
> +    xc_dom_panic(trusted_dom->xch, XC_INVALID_KERNEL, "%s", msg);
> +}
> +
> +static int trusted_flush(void *src, unsigned int size)
> +{
> +    void *n = realloc(output_blob, output_size + size);
> +    if (!n)
> +        return -1;
> +    output_blob = n;
> +
> +    memcpy(&output_blob[output_size], src, size);
> +    output_size += size;
> +    return size;
> +}
> +
> +int xc_dom_decompress_trusted_decompress(
> +    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    int ret;
> +
> +    trusted_dom = dom;
> +    output_blob = NULL;
> +    output_size = 0;
> +
> +    ret = fn(dom->kernel_blob, dom->kernel_size, NULL, trusted_flush, NULL, NULL, trusted_error);
> +
> +    if (ret)
> +        free(output_blob);
> +    else {
> +        *blob = output_blob;
> +        *size = output_size;
> +    }
> +
> +    return ret;
> +}
> +
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted.h	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,12 @@
> +#include "xc_dom.h"
> +
> +typedef int decompress_fn(unsigned char *inbuf, unsigned int len,
> +                          int (*fill)(void*, unsigned int),
> +                          int (*flush)(void*, unsigned int),
> +                          unsigned char *outbuf, unsigned int *posp,
> +                          void (*error)(const char *x));
> +
> +int xc_dom_decompress_trusted_decompress(
> +    decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size)
> +    __attribute__((visibility("hidden")));
> +
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_bzip2.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_bzip2.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,14 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +#include "../../xen/common/bunzip2.c"
> +
> +int xc_try_bzip2_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(bunzip2, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzma.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_lzma.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,14 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +#include "../../xen/common/unlzma.c"
> +
> +int xc_try_lzma_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(unlzma, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_lzo1x.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_lzo1x.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,15 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +#include "../../xen/common/lzo.c"
> +#include "../../xen/common/unlzo.c"
> +
> +int xc_try_lzo1x_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(unlzo, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 tools/libxc/xc_dom_decompress_trusted_xz.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxc/xc_dom_decompress_trusted_xz.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -0,0 +1,17 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <inttypes.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom_decompress_trusted.h"
> +
> +// TODO
> +#define XZ_DEC_X86
> +
> +#include "../../xen/common/unxz.c"
> +
> +int xc_try_xz_decode(
> +    struct xc_dom_image *dom, void **blob, size_t *size)
> +{
> +    return xc_dom_decompress_trusted_decompress(unxz, dom, blob, size);
> +}
> diff -r efdc4bbfdd20 xen/common/decompress.h
> --- a/xen/common/decompress.h	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/decompress.h	Tue Feb 26 23:20:22 2013 +0100
> @@ -1,3 +1,5 @@
> +#ifdef __XEN__
> +
>  #include <xen/config.h>
>  #include <xen/cache.h>
>  #include <xen/decompress.h>
> @@ -15,3 +17,14 @@
>  
>  #define large_malloc xmalloc_bytes
>  #define large_free xfree
> +
> +#else
> +
> +#define STATIC static
> +#define INIT
> +#define INITDATA
> +
> +#define large_malloc malloc
> +#define large_free free
> +
> +#endif
> diff -r efdc4bbfdd20 xen/common/lzo.c
> --- a/xen/common/lzo.c	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/lzo.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -68,7 +68,19 @@
>   *  Richard Purdie <rpurdie@openedhand.com>
>   */
>  
> +#ifndef __MINIOS__
>  #include <xen/types.h>
> +#else
> +#include <stdint.h>
> +
> +typedef uint32_t u32;
> +typedef uint16_t u16;
> +
> +#define likely(a) a
> +#define noinline
> +#define unlikely(a) a
> +#endif
> +
>  #include <xen/lzo.h>
>  #define get_unaligned(_p) (*(_p))
>  #define put_unaligned(_val,_p) (*(_p)=_val)
> diff -r efdc4bbfdd20 xen/common/unlzma.c
> --- a/xen/common/unlzma.c	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/unlzma.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -54,7 +54,9 @@
>   * Copyright (c) 1999-2005  Igor Pavlov
>   */
>  
> +#ifndef __MINIOS__
>  #include <xen/compiler.h>
> +#endif
>  
>  #define LZMA_IOBUF_SIZE	0x10000
>  
> diff -r efdc4bbfdd20 xen/common/unlzo.c
> --- a/xen/common/unlzo.c	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/unlzo.c	Tue Feb 26 23:20:22 2013 +0100
> @@ -32,7 +32,43 @@
>  
>  #include "decompress.h"
>  #include <xen/lzo.h>
> +
> +#ifndef __MINIOS__
>  #include <asm/byteorder.h>
> +#else
> +#include <endian.h>
> +#include <stdint.h>
> +
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +
> +static inline u16 be16_to_cpup(const u16 *p)
> +{
> +	u16 v = *p;
> +#if BYTE_ORDER == LITTLE_ENDIAN
> +	return (((v & 0x00ffU) << 8) |
> +                ((v & 0xff00U) >> 8));
> +#else
> +	return v;
> +#endif
> +}
> +
> +static inline u32 be32_to_cpup(const u32 *p)
> +{
> +	u32 v = *p;
> +#if BYTE_ORDER == LITTLE_ENDIAN
> +	return (((v & 0x000000ffUL) << 24) |
> +                ((v & 0x0000ff00UL) <<  8) |
> +                ((v & 0x00ff0000UL) >>  8) |
> +                ((v & 0xff000000UL) >> 24));
> +#else
> +	return v;
> +#endif
> +}
> +
> +#define unlikely(a) a
> +#endif
>  
>  #if 1 /* ndef CONFIG_??? */
>  static inline u16 INIT get_unaligned_be16(void *p)
> diff -r efdc4bbfdd20 xen/common/xz/private.h
> --- a/xen/common/xz/private.h	Tue Feb 26 19:42:36 2013 +0100
> +++ b/xen/common/xz/private.h	Tue Feb 26 23:20:22 2013 +0100
> @@ -10,8 +10,53 @@
>  #ifndef XZ_PRIVATE_H
>  #define XZ_PRIVATE_H
>  
> +#ifndef __MINIOS__
>  #include <xen/kernel.h>
>  #include <asm/byteorder.h>
> +#else
> +#include <endian.h>
> +#include <stddef.h>
> +#include <stdint.h>
> +
> +typedef char bool_t;
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +typedef uint32_t __le32;
> +
> +static inline u32 cpu_to_le32(const u32 v)
> +{
> +#if BYTE_ORDER == BIG_ENDIAN
> +	return (((v & 0x000000ffUL) << 24) |
> +	        ((v & 0x0000ff00UL) <<  8) |
> +	        ((v & 0x00ff0000UL) >>  8) |
> +	        ((v & 0xff000000UL) >> 24));
> +#else  
> +	return v;
> +#endif
> +}
> +
> +static inline u32 le32_to_cpup(const u32 *p)
> +{
> +	return cpu_to_le32(*p);
> +}
> +
> +#define min(x,y) ({ \
> +        const typeof(x) _x = (x);       \
> +        const typeof(y) _y = (y);       \
> +        (void) (&_x == &_y);            \
> +        _x < _y ? _x : _y; })
> +
> +#define min_t(type,x,y) \
> +        ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
> +#define max_t(type,x,y) \
> +        ({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
> +
> +#define __force
> +#define always_inline
> +
> +#endif
> +
>  #define get_le32(p) le32_to_cpup((const uint32_t *)(p))
>  
>  #if 1 /* ndef CONFIG_??? */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:19:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:19: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 1UAfyR-0002eS-3W; Wed, 27 Feb 2013 12:19: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 1UAfyP-0002eF-6C
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:19:01 +0000
Received: from [85.158.138.51:3386] by server-5.bemta-3.messagelabs.com id
	55/DA-30636-4B9FD215; Wed, 27 Feb 2013 12:19:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361967539!27692775!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21134 invoked from network); 27 Feb 2013 12:18:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:18:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1951196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:19: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.297.1;
	Wed, 27 Feb 2013 12:18:59 +0000
Message-ID: <1361967537.26546.369.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 12:18:57 +0000
In-Reply-To: <20781.62875.686221.389155@mariner.uk.xensource.com>
References: <osstest-16754-mainreport@xen.org>
	<20781.62875.686221.389155@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16754: 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 Wed, 2013-02-27 at 12:01 +0000, Ian Jackson wrote:
> This looks like a bug in the i386 kernel in Debian squeeze.

Suspicious that it happened right after a Debian point release -- would
we have automatically picked up the latest kernel etc?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:19:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:19: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 1UAfyR-0002eS-3W; Wed, 27 Feb 2013 12:19: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 1UAfyP-0002eF-6C
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:19:01 +0000
Received: from [85.158.138.51:3386] by server-5.bemta-3.messagelabs.com id
	55/DA-30636-4B9FD215; Wed, 27 Feb 2013 12:19:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1361967539!27692775!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21134 invoked from network); 27 Feb 2013 12:18:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:18:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1951196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:19: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.297.1;
	Wed, 27 Feb 2013 12:18:59 +0000
Message-ID: <1361967537.26546.369.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 12:18:57 +0000
In-Reply-To: <20781.62875.686221.389155@mariner.uk.xensource.com>
References: <osstest-16754-mainreport@xen.org>
	<20781.62875.686221.389155@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 16754: 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 Wed, 2013-02-27 at 12:01 +0000, Ian Jackson wrote:
> This looks like a bug in the i386 kernel in Debian squeeze.

Suspicious that it happened right after a Debian point release -- would
we have automatically picked up the latest kernel etc?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:20:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:20: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 1UAfzZ-0002l5-J6; Wed, 27 Feb 2013 12:20:13 +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 1UAfzY-0002kp-1k
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:20:12 +0000
Received: from [85.158.138.51:36260] by server-16.bemta-3.messagelabs.com id
	0E/03-20692-BF9FD215; Wed, 27 Feb 2013 12:20:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361967581!21711040!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1NjQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22510 invoked from network); 27 Feb 2013 12:19:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-174.messagelabs.com with SMTP;
	27 Feb 2013 12:19:42 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 27 Feb 2013 04:19:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="206854190"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 27 Feb 2013 04:19:39 -0800
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 04:19:39 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 04:19:39 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 20:19:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFN5kqZTiEd/FTjyR1sPJXJqZr5iNml7w
Date: Wed, 27 Feb 2013 12:19:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C792@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
	<512DFD5102000078000C1764@nat28.tlf.novell.com>
In-Reply-To: <512DFD5102000078000C1764@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 12:08, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>>>> 		recommended by Intel SDM: LOG MCA REGISTER:
>>>> 		SAVE IA32_MCi_STATUS;
>>>> 		If MISCV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SAVE IA32_MCi_MISC;
>>>> 		FI;
>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SAVE IA32_MCi_ADDR;
>>>> 		FI;
>>>> 		IF CLEAR_MC_BANK = TRUE
>>>> 		THEN
>>>> 			SET all 0 to IA32_MCi_STATUS;
>>>> 		If MISCV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SET all 0 to IA32_MCi_MISC;
>>>> 		FI;
>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SET all 0 to IA32_MCi_ADDR;
>>>> 		FI;
>>>> 
>>>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>>>> error occur (which indicated by MCi_STATUS), so only clear
>>>> MCi_STATUS at mce handler is an acceptable work around -- after
>>>> all, to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
>>> 
>>> So then what - revert your original patch (and ignore the SDM)?
>>> I'm not in favor of this...
>> 
>> Not revert entire 23327, but only use this patch to revert
>> MCi_ADDR/MISC clear. 
>> 
>> I also agree it's not good, but currently seems we don't have a
>> simple and clean way to fix it, except we spend much time to to
>> update xen-mceinj *tools* -- even so it's low-priority?
> 
> No, fixing the tool seems unnecessary for this problem, all we
> need is a way to avoid the problematic MSR writes when finishing
> an injected MCE. That's fully contained to the hypervisor.
> 
> Jan

The problem comes from xen-mceinj tools simulate *some* banks for *some* cpus (intpose_arr array). Tools sometimes access simulated value, sometimes access real hardware --> that's problematic syntax and what really need fix.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:20:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:20: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 1UAfzZ-0002l5-J6; Wed, 27 Feb 2013 12:20:13 +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 1UAfzY-0002kp-1k
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:20:12 +0000
Received: from [85.158.138.51:36260] by server-16.bemta-3.messagelabs.com id
	0E/03-20692-BF9FD215; Wed, 27 Feb 2013 12:20:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1361967581!21711040!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU1NjQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22510 invoked from network); 27 Feb 2013 12:19:42 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-174.messagelabs.com with SMTP;
	27 Feb 2013 12:19:42 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 27 Feb 2013 04:19:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="206854190"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 27 Feb 2013 04:19:39 -0800
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 04:19:39 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 04:19:39 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Wed, 27 Feb 2013 20:19:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFN5kqZTiEd/FTjyR1sPJXJqZr5iNml7w
Date: Wed, 27 Feb 2013 12:19:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540C792@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
	<512DFD5102000078000C1764@nat28.tlf.novell.com>
In-Reply-To: <512DFD5102000078000C1764@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 12:08, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>>>> 		recommended by Intel SDM: LOG MCA REGISTER:
>>>> 		SAVE IA32_MCi_STATUS;
>>>> 		If MISCV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SAVE IA32_MCi_MISC;
>>>> 		FI;
>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SAVE IA32_MCi_ADDR;
>>>> 		FI;
>>>> 		IF CLEAR_MC_BANK = TRUE
>>>> 		THEN
>>>> 			SET all 0 to IA32_MCi_STATUS;
>>>> 		If MISCV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SET all 0 to IA32_MCi_MISC;
>>>> 		FI;
>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>> 		THEN
>>>> 			SET all 0 to IA32_MCi_ADDR;
>>>> 		FI;
>>>> 
>>>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>>>> error occur (which indicated by MCi_STATUS), so only clear
>>>> MCi_STATUS at mce handler is an acceptable work around -- after
>>>> all, to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
>>> 
>>> So then what - revert your original patch (and ignore the SDM)?
>>> I'm not in favor of this...
>> 
>> Not revert entire 23327, but only use this patch to revert
>> MCi_ADDR/MISC clear. 
>> 
>> I also agree it's not good, but currently seems we don't have a
>> simple and clean way to fix it, except we spend much time to to
>> update xen-mceinj *tools* -- even so it's low-priority?
> 
> No, fixing the tool seems unnecessary for this problem, all we
> need is a way to avoid the problematic MSR writes when finishing
> an injected MCE. That's fully contained to the hypervisor.
> 
> Jan

The problem comes from xen-mceinj tools simulate *some* banks for *some* cpus (intpose_arr array). Tools sometimes access simulated value, sometimes access real hardware --> that's problematic syntax and what really need fix.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:27:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAg6s-0003Bl-Fv; Wed, 27 Feb 2013 12:27:46 +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 1UAg6r-0003Bg-Qq
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:27:45 +0000
Received: from [85.158.139.211:50709] by server-14.bemta-5.messagelabs.com id
	EC/EC-13158-1CBFD215; Wed, 27 Feb 2013 12:27:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361968064!18696242!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16414 invoked from network); 27 Feb 2013 12:27:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1951939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12: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.297.1; Wed, 27 Feb 2013 12:27:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAg6Y-0006Es-ME	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:27:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAg6Y-0003Nv-GP	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:27:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.64430.264680.681708@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:27:26 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1361967537.26546.369.camel@zakaz.uk.xensource.com>
References: <osstest-16754-mainreport@xen.org>
	<20781.62875.686221.389155@mariner.uk.xensource.com>
	<1361967537.26546.369.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 16754: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16754: regressions - FAIL"):
> On Wed, 2013-02-27 at 12:01 +0000, Ian Jackson wrote:
> > This looks like a bug in the i386 kernel in Debian squeeze.
> 
> Suspicious that it happened right after a Debian point release -- would
> we have automatically picked up the latest kernel etc?

No, that's a manual change (which goes through the tester's own push
gate).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:27:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAg6s-0003Bl-Fv; Wed, 27 Feb 2013 12:27:46 +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 1UAg6r-0003Bg-Qq
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:27:45 +0000
Received: from [85.158.139.211:50709] by server-14.bemta-5.messagelabs.com id
	EC/EC-13158-1CBFD215; Wed, 27 Feb 2013 12:27:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1361968064!18696242!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16414 invoked from network); 27 Feb 2013 12:27:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1951939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12: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.297.1; Wed, 27 Feb 2013 12:27:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAg6Y-0006Es-ME	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:27:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAg6Y-0003Nv-GP	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:27:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.64430.264680.681708@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:27:26 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <1361967537.26546.369.camel@zakaz.uk.xensource.com>
References: <osstest-16754-mainreport@xen.org>
	<20781.62875.686221.389155@mariner.uk.xensource.com>
	<1361967537.26546.369.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 16754: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16754: regressions - FAIL"):
> On Wed, 2013-02-27 at 12:01 +0000, Ian Jackson wrote:
> > This looks like a bug in the i386 kernel in Debian squeeze.
> 
> Suspicious that it happened right after a Debian point release -- would
> we have automatically picked up the latest kernel etc?

No, that's a manual change (which goes through the tester's own push
gate).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:30:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:30: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 1UAg8u-0003JD-6O; Wed, 27 Feb 2013 12:29:52 +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 1UAg8r-0003J7-TL
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:29:50 +0000
Received: from [85.158.137.99:57186] by server-7.bemta-3.messagelabs.com id
	C7/18-06591-D3CFD215; Wed, 27 Feb 2013 12:29:49 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361968187!299710!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4OTI2MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25675 invoked from network); 27 Feb 2013 12:29:48 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 12:29:48 -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:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=lwDtTTAHW7gt4lhCSh3Yhaf0ZZcX/+9H8kecqyBR+YTMT1DSqON8LCqD
	gmb2W5ubTCp1TayIRFKDImzJxrisVJSeV+mpivUJXgeuQYjHHNIjS6ADa
	H0Fox7oS4t8xM7cN+vx4uoeui37KjPwyVR3BavKwVGsejJDxUIai9sJEb
	6uRAaxfqqF/P9IUj+TDZcQAvUpZ3HGzY6eH2D7IsV8zx8wtBcXkUwveYs
	Iu0Ysg8LzPRwXU7zRHs+6O8OoxuZR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361968188; x=1393504188;
	h=mime-version:subject:message-id:date:from:to;
	bh=1wCQAB8skZhAlLSX5gnzqbFiMOsOoH2adYWYognYdNc=;
	b=kuwxuOn1wbpbwvz9fjatQF4jbmzhipkb2hK6hl+Ih0P907D4z+neVcXr
	GoWJCxLF+fKOb9LxdHgEww5VqjAmPu/evZ3xMpBQy1NyEIYTArVRZKixq
	CLXjP6qn+h+vyYRdJWP3qTTFkF/5pbev8jOOJk0n3MqVRAQdgBIcUjfZJ
	UlI04Tmy2GEAx4YkazNlEPvvY9cE34+i2g7L1GcuLHW196/9ZmJar2g0J
	9A1a4+YPJM3iHzmdgjQeY4F+Mp47B;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,747,1355094000"; d="scan'208";a="138206792"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Feb 2013 13:29:47 +0100
X-IronPort-AV: E=Sophos;i="4.84,747,1355094000"; 
   d="scan'208";a="5156260"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 13:29:47 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 055FE96A7E2;
	Wed, 27 Feb 2013 13:29:47 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7762778938496596388=="
MIME-Version: 1.0
X-Mercurial-Node: 550a413da1ac4333d4ecd8033d92893b96d5d853
Message-Id: <550a413da1ac4333d4ec.1361967571@nehalem1>
Date: Wed, 27 Feb 2013 13:19:31 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Rename credit2 names to csched2_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--===============7762778938496596388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Functions, variables, structures and macros in the credit2 scheduler had
partially the same names as in the credit scheduler. This makes it hard to
find the correct functions in backtraces or cscope.

Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


1 file changed, 223 insertions(+), 223 deletions(-)
xen/common/sched_credit2.c |  446 ++++++++++++++++++++++----------------------



--===============7762778938496596388==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1361967550 -3600
# Node ID 550a413da1ac4333d4ecd8033d92893b96d5d853
# Parent  1d8c65aee03eaf15ce8ee50deb781b4308302b77
Rename credit2 names to csched2_*

Functions, variables, structures and macros in the credit2 scheduler had
partially the same names as in the credit scheduler. This makes it hard to
find the correct functions in backtraces or cscope.

Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e -r 550a413da1ac xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/sched_credit2.c	Wed Feb 27 13:19:10 2013 +0100
@@ -3,7 +3,7 @@
  * (C) 2009 - George Dunlap - Citrix Systems R&D UK, Ltd
  ****************************************************************************
  *
- *        File: common/csched_credit2.c
+ *        File: common/sched_credit2.c
  *      Author: George Dunlap
  *
  * Description: Credit-based SMP CPU scheduler
@@ -108,29 +108,29 @@
  * Basic constants
  */
 /* Default weight: How much a new domain starts with */
-#define CSCHED_DEFAULT_WEIGHT       256
+#define CSCHED2_DEFAULT_WEIGHT       256
 /* Min timer: Minimum length a timer will be set, to
  * achieve efficiency */
-#define CSCHED_MIN_TIMER            MICROSECS(500)
+#define CSCHED2_MIN_TIMER            MICROSECS(500)
 /* Amount of credit VMs begin with, and are reset to.
  * ATM, set so that highest-weight VMs can only run for 10ms
  * before a reset event. */
-#define CSCHED_CREDIT_INIT          MILLISECS(10)
+#define CSCHED2_CREDIT_INIT          MILLISECS(10)
 /* Carryover: How much "extra" credit may be carried over after
  * a reset. */
-#define CSCHED_CARRYOVER_MAX        CSCHED_MIN_TIMER
+#define CSCHED2_CARRYOVER_MAX        CSCHED2_MIN_TIMER
 /* Stickiness: Cross-L2 migration resistance.  Should be less than
  * MIN_TIMER. */
-#define CSCHED_MIGRATE_RESIST       ((opt_migrate_resist)*MICROSECS(1))
+#define CSCHED2_MIGRATE_RESIST       ((opt_migrate_resist)*MICROSECS(1))
 /* How much to "compensate" a vcpu for L2 migration */
-#define CSCHED_MIGRATE_COMPENSATION MICROSECS(50)
+#define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
 /* Reset: Value below which credit will be reset. */
-#define CSCHED_CREDIT_RESET         0
+#define CSCHED2_CREDIT_RESET         0
 /* Max timer: Maximum time a guest can be run for. */
-#define CSCHED_MAX_TIMER            MILLISECS(2)
+#define CSCHED2_MAX_TIMER            MILLISECS(2)
 
 
-#define CSCHED_IDLE_CREDIT                 (-(1<<30))
+#define CSCHED2_IDLE_CREDIT                 (-(1<<30))
 
 /*
  * Flags
@@ -138,8 +138,8 @@
 /* CSFLAG_scheduled: Is this vcpu either running on, or context-switching off,
  * a physical cpu?
  * + Accessed only with runqueue lock held
- * + Set when chosen as next in csched_schedule().
- * + Cleared after context switch has been saved in csched_context_saved()
+ * + Set when chosen as next in csched2_schedule().
+ * + Cleared after context switch has been saved in csched2_context_saved()
  * + Checked in vcpu_wake to see if we can add to the runqueue, or if we should
  *   set CSFLAG_delayed_runq_add
  * + Checked to be false in runq_insert.
@@ -148,9 +148,9 @@
 #define CSFLAG_scheduled (1<<__CSFLAG_scheduled)
 /* CSFLAG_delayed_runq_add: Do we need to add this to the runqueue once it'd done
  * being context switched out?
- * + Set when scheduling out in csched_schedule() if prev is runnable
- * + Set in csched_vcpu_wake if it finds CSFLAG_scheduled set
- * + Read in csched_context_saved().  If set, it adds prev to the runqueue and
+ * + Set when scheduling out in csched2_schedule() if prev is runnable
+ * + Set in csched2_vcpu_wake if it finds CSFLAG_scheduled set
+ * + Read in csched2_context_saved().  If set, it adds prev to the runqueue and
  *   clears the bit.
  */
 #define __CSFLAG_delayed_runq_add 2
@@ -169,14 +169,14 @@ integer_param("sched_credit2_migrate_res
 /*
  * Useful macros
  */
-#define CSCHED_PRIV(_ops)   \
-    ((struct csched_private *)((_ops)->sched_data))
-#define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
-#define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
+#define CSCHED2_PRIV(_ops)   \
+    ((struct csched2_private *)((_ops)->sched_data))
+#define CSCHED2_VCPU(_vcpu)  ((struct csched2_vcpu *) (_vcpu)->sched_priv)
+#define CSCHED2_DOM(_dom)    ((struct csched2_dom *) (_dom)->sched_priv)
 /* CPU to runq_id macro */
-#define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
+#define c2r(_ops, _cpu)     (CSCHED2_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
-#define RQD(_ops, _cpu)     (&CSCHED_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
+#define RQD(_ops, _cpu)     (&CSCHED2_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
 
 /*
  * Shifts for load average.
@@ -197,7 +197,7 @@ integer_param("credit2_balance_over", op
 /*
  * Per-runqueue data
  */
-struct csched_runqueue_data {
+struct csched2_runqueue_data {
     int id;
 
     spinlock_t lock;      /* Lock for this runqueue. */
@@ -218,7 +218,7 @@ struct csched_runqueue_data {
 /*
  * System-wide private data
  */
-struct csched_private {
+struct csched2_private {
     spinlock_t lock;
     cpumask_t initialized; /* CPU is initialized for this pool */
     
@@ -226,7 +226,7 @@ struct csched_private {
 
     int runq_map[NR_CPUS];
     cpumask_t active_queues; /* Queues which may have active cpus */
-    struct csched_runqueue_data rqd[NR_CPUS];
+    struct csched2_runqueue_data rqd[NR_CPUS];
 
     int load_window_shift;
 };
@@ -234,14 +234,14 @@ struct csched_private {
 /*
  * Virtual CPU
  */
-struct csched_vcpu {
+struct csched2_vcpu {
     struct list_head rqd_elem;  /* On the runqueue data list */
     struct list_head sdom_elem; /* On the domain vcpu list */
     struct list_head runq_elem; /* On the runqueue         */
-    struct csched_runqueue_data *rqd; /* Up-pointer to the runqueue */
+    struct csched2_runqueue_data *rqd; /* Up-pointer to the runqueue */
 
     /* Up-pointers */
-    struct csched_dom *sdom;
+    struct csched2_dom *sdom;
     struct vcpu *vcpu;
 
     int weight;
@@ -254,13 +254,13 @@ struct csched_vcpu {
     s_time_t load_last_update;  /* Last time average was updated */
     s_time_t avgload;           /* Decaying queue load */
 
-    struct csched_runqueue_data *migrate_rqd; /* Pre-determined rqd to which to migrate */
+    struct csched2_runqueue_data *migrate_rqd; /* Pre-determined rqd to which to migrate */
 };
 
 /*
  * Domain
  */
-struct csched_dom {
+struct csched2_dom {
     struct list_head vcpu;
     struct list_head sdom_elem;
     struct domain *dom;
@@ -273,12 +273,12 @@ struct csched_dom {
  * Time-to-credit, credit-to-time.
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static s_time_t t2c(struct csched2_runqueue_data *rqd, s_time_t time, struct csched2_vcpu *svc)
 {
     return time * rqd->max_weight / svc->weight;
 }
 
-static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
+static s_time_t c2t(struct csched2_runqueue_data *rqd, s_time_t credit, struct csched2_vcpu *svc)
 {
     return credit * svc->weight / rqd->max_weight;
 }
@@ -288,22 +288,22 @@ static s_time_t c2t(struct csched_runque
  */
 
 static /*inline*/ int
-__vcpu_on_runq(struct csched_vcpu *svc)
+__vcpu_on_runq(struct csched2_vcpu *svc)
 {
     return !list_empty(&svc->runq_elem);
 }
 
-static /*inline*/ struct csched_vcpu *
+static /*inline*/ struct csched2_vcpu *
 __runq_elem(struct list_head *elem)
 {
-    return list_entry(elem, struct csched_vcpu, runq_elem);
+    return list_entry(elem, struct csched2_vcpu, runq_elem);
 }
 
 static void
 __update_runq_load(const struct scheduler *ops,
-                  struct csched_runqueue_data *rqd, int change, s_time_t now)
+                  struct csched2_runqueue_data *rqd, int change, s_time_t now)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     s_time_t delta=-1;
 
     now >>= LOADAVG_GRANULARITY_SHIFT;
@@ -345,9 +345,9 @@ __update_runq_load(const struct schedule
 
 static void
 __update_svc_load(const struct scheduler *ops,
-                  struct csched_vcpu *svc, int change, s_time_t now)
+                  struct csched2_vcpu *svc, int change, s_time_t now)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     s_time_t delta=-1;
     int vcpu_load;
 
@@ -390,8 +390,8 @@ __update_svc_load(const struct scheduler
 
 static void
 update_load(const struct scheduler *ops,
-            struct csched_runqueue_data *rqd,
-            struct csched_vcpu *svc, int change, s_time_t now)
+            struct csched2_runqueue_data *rqd,
+            struct csched2_vcpu *svc, int change, s_time_t now)
 {
     __update_runq_load(ops, rqd, change, now);
     if ( svc )
@@ -399,7 +399,7 @@ update_load(const struct scheduler *ops,
 }
 
 static int
-__runq_insert(struct list_head *runq, struct csched_vcpu *svc)
+__runq_insert(struct list_head *runq, struct csched2_vcpu *svc)
 {
     struct list_head *iter;
     int pos = 0;
@@ -416,7 +416,7 @@ __runq_insert(struct list_head *runq, st
 
     list_for_each( iter, runq )
     {
-        struct csched_vcpu * iter_svc = __runq_elem(iter);
+        struct csched2_vcpu * iter_svc = __runq_elem(iter);
 
         if ( svc->credit > iter_svc->credit )
         {
@@ -435,7 +435,7 @@ __runq_insert(struct list_head *runq, st
 }
 
 static void
-runq_insert(const struct scheduler *ops, unsigned int cpu, struct csched_vcpu *svc)
+runq_insert(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *svc)
 {
     struct list_head * runq = &RQD(ops, cpu)->runq;
     int pos = 0;
@@ -464,24 +464,24 @@ runq_insert(const struct scheduler *ops,
 }
 
 static inline void
-__runq_remove(struct csched_vcpu *svc)
+__runq_remove(struct csched2_vcpu *svc)
 {
     BUG_ON( !__vcpu_on_runq(svc) );
     list_del_init(&svc->runq_elem);
 }
 
-void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *, s_time_t);
+void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, s_time_t);
 
 /* Check to see if the item on the runqueue is higher priority than what's
  * currently running; if so, wake up the processor */
 static /*inline*/ void
-runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched_vcpu *new, s_time_t now)
+runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *new, s_time_t now)
 {
     int i, ipid=-1;
     s_time_t lowest=(1<<30);
-    struct csched_runqueue_data *rqd = RQD(ops, cpu);
+    struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     cpumask_t mask;
-    struct csched_vcpu * cur;
+    struct csched2_vcpu * cur;
 
     d2printk("rqt d%dv%d cd%dv%d\n",
              new->vcpu->domain->domain_id,
@@ -493,7 +493,7 @@ runq_tickle(const struct scheduler *ops,
     BUG_ON(new->rqd != rqd);
 
     /* Look at the cpu it's running on first */
-    cur = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
+    cur = CSCHED2_VCPU(per_cpu(schedule_data, cpu).curr);
     burn_credits(rqd, cur, now);
 
     if ( cur->credit < new->credit )
@@ -519,13 +519,13 @@ runq_tickle(const struct scheduler *ops,
 
     for_each_cpu(i, &mask)
     {
-        struct csched_vcpu * cur;
+        struct csched2_vcpu * cur;
 
         /* Already looked at this one above */
         if ( i == cpu )
             continue;
 
-        cur = CSCHED_VCPU(per_cpu(schedule_data, i).curr);
+        cur = CSCHED2_VCPU(per_cpu(schedule_data, i).curr);
 
         BUG_ON(is_idle_vcpu(cur->vcpu));
 
@@ -554,7 +554,7 @@ runq_tickle(const struct scheduler *ops,
 
     /* Only switch to another processor if the credit difference is greater
      * than the migrate resistance */
-    if ( ipid == -1 || lowest + CSCHED_MIGRATE_RESIST > new->credit )
+    if ( ipid == -1 || lowest + CSCHED2_MIGRATE_RESIST > new->credit )
         goto no_tickle;
 
 tickle:
@@ -581,12 +581,12 @@ no_tickle:
  */
 static void reset_credit(const struct scheduler *ops, int cpu, s_time_t now)
 {
-    struct csched_runqueue_data *rqd = RQD(ops, cpu);
+    struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *iter;
 
     list_for_each( iter, &rqd->svc )
     {
-        struct csched_vcpu * svc = list_entry(iter, struct csched_vcpu, rqd_elem);
+        struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, rqd_elem);
 
         int start_credit;
 
@@ -596,10 +596,10 @@ static void reset_credit(const struct sc
         start_credit = svc->credit;
 
         /* "Clip" credits to max carryover */
-        if ( svc->credit > CSCHED_CARRYOVER_MAX )
-            svc->credit = CSCHED_CARRYOVER_MAX;
+        if ( svc->credit > CSCHED2_CARRYOVER_MAX )
+            svc->credit = CSCHED2_CARRYOVER_MAX;
         /* And add INIT */
-        svc->credit += CSCHED_CREDIT_INIT;
+        svc->credit += CSCHED2_CREDIT_INIT;
         svc->start_time = now;
 
         /* TRACE */ {
@@ -620,16 +620,16 @@ static void reset_credit(const struct sc
     /* No need to resort runqueue, as everyone's order should be the same. */
 }
 
-void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_time_t now)
+void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
 
     /* Assert svc is current */
-    ASSERT(svc==CSCHED_VCPU(per_cpu(schedule_data, svc->vcpu->processor).curr));
+    ASSERT(svc==CSCHED2_VCPU(per_cpu(schedule_data, svc->vcpu->processor).curr));
 
     if ( is_idle_vcpu(svc->vcpu) )
     {
-        BUG_ON(svc->credit != CSCHED_IDLE_CREDIT);
+        BUG_ON(svc->credit != CSCHED2_IDLE_CREDIT);
         return;
     }
 
@@ -667,7 +667,7 @@ void burn_credits(struct csched_runqueue
 }
 
 /* Find the domain with the highest weight. */
-void update_max_weight(struct csched_runqueue_data *rqd, int new_weight, int old_weight)
+void update_max_weight(struct csched2_runqueue_data *rqd, int new_weight, int old_weight)
 {
     /* Try to avoid brute-force search:
      * - If new_weight is larger, max_weigth <- new_weight
@@ -687,7 +687,7 @@ void update_max_weight(struct csched_run
 
         list_for_each( iter, &rqd->svc )
         {
-            struct csched_vcpu * svc = list_entry(iter, struct csched_vcpu, rqd_elem);
+            struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, rqd_elem);
 
             if ( svc->weight > max_weight )
                 max_weight = svc->weight;
@@ -700,13 +700,13 @@ void update_max_weight(struct csched_run
 
 #ifndef NDEBUG
 static /*inline*/ void
-__csched_vcpu_check(struct vcpu *vc)
+__csched2_vcpu_check(struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-    struct csched_dom * const sdom = svc->sdom;
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
+    struct csched2_dom * const sdom = svc->sdom;
 
     BUG_ON( svc->vcpu != vc );
-    BUG_ON( sdom != CSCHED_DOM(vc->domain) );
+    BUG_ON( sdom != CSCHED2_DOM(vc->domain) );
     if ( sdom )
     {
         BUG_ON( is_idle_vcpu(vc) );
@@ -717,18 +717,18 @@ __csched_vcpu_check(struct vcpu *vc)
         BUG_ON( !is_idle_vcpu(vc) );
     }
 }
-#define CSCHED_VCPU_CHECK(_vc)  (__csched_vcpu_check(_vc))
+#define CSCHED2_VCPU_CHECK(_vc)  (__csched2_vcpu_check(_vc))
 #else
-#define CSCHED_VCPU_CHECK(_vc)
+#define CSCHED2_VCPU_CHECK(_vc)
 #endif
 
 static void *
-csched_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
+csched2_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
 {
-    struct csched_vcpu *svc;
+    struct csched2_vcpu *svc;
 
     /* Allocate per-VCPU info */
-    svc = xzalloc(struct csched_vcpu);
+    svc = xzalloc(struct csched2_vcpu);
     if ( svc == NULL )
         return NULL;
 
@@ -744,16 +744,16 @@ csched_alloc_vdata(const struct schedule
     {
         BUG_ON( svc->sdom == NULL );
 
-        svc->credit = CSCHED_CREDIT_INIT;
+        svc->credit = CSCHED2_CREDIT_INIT;
         svc->weight = svc->sdom->weight;
         /* Starting load of 50% */
-        svc->avgload = 1ULL << (CSCHED_PRIV(ops)->load_window_shift - 1);
+        svc->avgload = 1ULL << (CSCHED2_PRIV(ops)->load_window_shift - 1);
         svc->load_last_update = NOW();
     }
     else
     {
         BUG_ON( svc->sdom != NULL );
-        svc->credit = CSCHED_IDLE_CREDIT;
+        svc->credit = CSCHED2_IDLE_CREDIT;
         svc->weight = 0;
     }
 
@@ -764,7 +764,7 @@ csched_alloc_vdata(const struct schedule
 
 /* Add and remove from runqueue assignment (not active run queue) */
 static void
-__runq_assign(struct csched_vcpu *svc, struct csched_runqueue_data *rqd)
+__runq_assign(struct csched2_vcpu *svc, struct csched2_runqueue_data *rqd)
 {
 
     svc->rqd = rqd;
@@ -794,7 +794,7 @@ static void
 static void
 runq_assign(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu *svc = vc->sched_priv;
+    struct csched2_vcpu *svc = vc->sched_priv;
 
     BUG_ON(svc->rqd != NULL);
 
@@ -802,7 +802,7 @@ runq_assign(const struct scheduler *ops,
 }
 
 static void
-__runq_deassign(struct csched_vcpu *svc)
+__runq_deassign(struct csched2_vcpu *svc)
 {
     BUG_ON(__vcpu_on_runq(svc));
     BUG_ON(test_bit(__CSFLAG_scheduled, &svc->flags));
@@ -819,7 +819,7 @@ static void
 static void
 runq_deassign(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu *svc = vc->sched_priv;
+    struct csched2_vcpu *svc = vc->sched_priv;
 
     BUG_ON(svc->rqd != RQD(ops, vc->processor));
 
@@ -827,11 +827,11 @@ runq_deassign(const struct scheduler *op
 }
 
 static void
-csched_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu *svc = vc->sched_priv;
+    struct csched2_vcpu *svc = vc->sched_priv;
     struct domain * const dom = vc->domain;
-    struct csched_dom * const sdom = svc->sdom;
+    struct csched2_dom * const sdom = svc->sdom;
 
     printk("%s: Inserting d%dv%d\n",
            __func__, dom->domain_id, vc->vcpu_id);
@@ -854,22 +854,22 @@ csched_vcpu_insert(const struct schedule
         sdom->nr_vcpus++;
     }
 
-    CSCHED_VCPU_CHECK(vc);
+    CSCHED2_VCPU_CHECK(vc);
 }
 
 static void
-csched_free_vdata(const struct scheduler *ops, void *priv)
+csched2_free_vdata(const struct scheduler *ops, void *priv)
 {
-    struct csched_vcpu *svc = priv;
+    struct csched2_vcpu *svc = priv;
 
     xfree(svc);
 }
 
 static void
-csched_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-    struct csched_dom * const sdom = svc->sdom;
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
+    struct csched2_dom * const sdom = svc->sdom;
 
     BUG_ON( sdom == NULL );
     BUG_ON( !list_empty(&svc->runq_elem) );
@@ -894,9 +894,9 @@ csched_vcpu_remove(const struct schedule
 }
 
 static void
-csched_vcpu_sleep(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_sleep(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
 
     BUG_ON( is_idle_vcpu(vc) );
 
@@ -913,9 +913,9 @@ csched_vcpu_sleep(const struct scheduler
 }
 
 static void
-csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
     s_time_t now = 0;
 
     /* Schedule lock should be held at this point. */
@@ -966,9 +966,9 @@ out:
 }
 
 static void
-csched_context_saved(const struct scheduler *ops, struct vcpu *vc)
+csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
     s_time_t now = NOW();
 
     vcpu_schedule_lock_irq(vc);
@@ -1004,9 +1004,9 @@ static int
 static int
 choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, min_rqi = -1, new_cpu;
-    struct csched_vcpu *svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu *svc = CSCHED2_VCPU(vc);
     s_time_t min_avgload;
 
     BUG_ON(cpumask_empty(&prv->active_queues));
@@ -1063,7 +1063,7 @@ choose_cpu(const struct scheduler *ops, 
     /* Find the runqueue with the lowest instantaneous load */
     for_each_cpu(i, &prv->active_queues)
     {
-        struct csched_runqueue_data *rqd;
+        struct csched2_runqueue_data *rqd;
         s_time_t rqd_avgload;
 
         rqd = prv->rqd + i;
@@ -1112,15 +1112,15 @@ typedef struct {
 typedef struct {
     /* NB: Modified by consider() */
     s_time_t load_delta;
-    struct csched_vcpu * best_push_svc, *best_pull_svc;
+    struct csched2_vcpu * best_push_svc, *best_pull_svc;
     /* NB: Read by consider() */
-    struct csched_runqueue_data *lrqd;
-    struct csched_runqueue_data *orqd;                  
+    struct csched2_runqueue_data *lrqd;
+    struct csched2_runqueue_data *orqd;                  
 } balance_state_t;
 
 static void consider(balance_state_t *st, 
-                     struct csched_vcpu *push_svc,
-                     struct csched_vcpu *pull_svc)
+                     struct csched2_vcpu *push_svc,
+                     struct csched2_vcpu *pull_svc)
 {
     s_time_t l_load, o_load, delta;
 
@@ -1153,8 +1153,8 @@ static void consider(balance_state_t *st
 
 
 void migrate(const struct scheduler *ops,
-             struct csched_vcpu *svc, 
-             struct csched_runqueue_data *trqd, 
+             struct csched2_vcpu *svc, 
+             struct csched2_runqueue_data *trqd, 
              s_time_t now)
 {
     if ( test_bit(__CSFLAG_scheduled, &svc->flags) )
@@ -1193,7 +1193,7 @@ void migrate(const struct scheduler *ops
 
 static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, max_delta_rqi = -1;
     struct list_head *push_iter, *pull_iter;
 
@@ -1293,7 +1293,7 @@ retry:
     list_for_each( push_iter, &st.lrqd->svc )
     {
         int inner_load_updated = 0;
-        struct csched_vcpu * push_svc = list_entry(push_iter, struct csched_vcpu, rqd_elem);
+        struct csched2_vcpu * push_svc = list_entry(push_iter, struct csched2_vcpu, rqd_elem);
 
         __update_svc_load(ops, push_svc, 0, now);
 
@@ -1303,7 +1303,7 @@ retry:
 
         list_for_each( pull_iter, &st.orqd->svc )
         {
-            struct csched_vcpu * pull_svc = list_entry(pull_iter, struct csched_vcpu, rqd_elem);
+            struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
             
             if ( ! inner_load_updated )
             {
@@ -1325,7 +1325,7 @@ retry:
 
     list_for_each( pull_iter, &st.orqd->svc )
     {
-        struct csched_vcpu * pull_svc = list_entry(pull_iter, struct csched_vcpu, rqd_elem);
+        struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
         
         /* Skip this one if it's already been flagged to migrate */
         if ( test_bit(__CSFLAG_runq_migrate_request, &pull_svc->flags) )
@@ -1349,7 +1349,7 @@ out:
 }
 
 static int
-csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc)
+csched2_cpu_pick(const struct scheduler *ops, struct vcpu *vc)
 {
     int new_cpu;
 
@@ -1359,14 +1359,14 @@ csched_cpu_pick(const struct scheduler *
 }
 
 static void
-csched_vcpu_migrate(
+csched2_vcpu_migrate(
     const struct scheduler *ops, struct vcpu *vc, unsigned int new_cpu)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-    struct csched_runqueue_data *trqd;
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
+    struct csched2_runqueue_data *trqd;
 
     /* Check if new_cpu is valid */
-    BUG_ON(!cpumask_test_cpu(new_cpu, &CSCHED_PRIV(ops)->initialized));
+    BUG_ON(!cpumask_test_cpu(new_cpu, &CSCHED2_PRIV(ops)->initialized));
 
     trqd = RQD(ops, new_cpu);
 
@@ -1375,16 +1375,16 @@ csched_vcpu_migrate(
 }
 
 static int
-csched_dom_cntl(
+csched2_dom_cntl(
     const struct scheduler *ops,
     struct domain *d,
     struct xen_domctl_scheduler_op *op)
 {
-    struct csched_dom * const sdom = CSCHED_DOM(d);
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_dom * const sdom = CSCHED2_DOM(d);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     unsigned long flags;
 
-    /* Must hold csched_priv lock to read and update sdom,
+    /* Must hold csched2_priv lock to read and update sdom,
      * runq lock to update csvcs. */
     spin_lock_irqsave(&prv->lock, flags);
 
@@ -1408,10 +1408,10 @@ csched_dom_cntl(
             /* Update weights for vcpus, and max_weight for runqueues on which they reside */
             list_for_each ( iter, &sdom->vcpu )
             {
-                struct csched_vcpu *svc = list_entry(iter, struct csched_vcpu, sdom_elem);
+                struct csched2_vcpu *svc = list_entry(iter, struct csched2_vcpu, sdom_elem);
 
                 /* NB: Locking order is important here.  Because we grab this lock here, we
-                 * must never lock csched_priv.lock if we're holding a runqueue lock.
+                 * must never lock csched2_priv.lock if we're holding a runqueue lock.
                  * Also, calling vcpu_schedule_lock() is enough, since IRQs have already
                  * been disabled. */
                 vcpu_schedule_lock(svc->vcpu);
@@ -1432,12 +1432,12 @@ csched_dom_cntl(
 }
 
 static void *
-csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
+csched2_alloc_domdata(const struct scheduler *ops, struct domain *dom)
 {
-    struct csched_dom *sdom;
+    struct csched2_dom *sdom;
     int flags;
 
-    sdom = xzalloc(struct csched_dom);
+    sdom = xzalloc(struct csched2_dom);
     if ( sdom == NULL )
         return NULL;
 
@@ -1445,29 +1445,29 @@ csched_alloc_domdata(const struct schedu
     INIT_LIST_HEAD(&sdom->vcpu);
     INIT_LIST_HEAD(&sdom->sdom_elem);
     sdom->dom = dom;
-    sdom->weight = CSCHED_DEFAULT_WEIGHT;
+    sdom->weight = CSCHED2_DEFAULT_WEIGHT;
     sdom->nr_vcpus = 0;
 
-    spin_lock_irqsave(&CSCHED_PRIV(ops)->lock, flags);
+    spin_lock_irqsave(&CSCHED2_PRIV(ops)->lock, flags);
 
-    list_add_tail(&sdom->sdom_elem, &CSCHED_PRIV(ops)->sdom);
+    list_add_tail(&sdom->sdom_elem, &CSCHED2_PRIV(ops)->sdom);
 
-    spin_unlock_irqrestore(&CSCHED_PRIV(ops)->lock, flags);
+    spin_unlock_irqrestore(&CSCHED2_PRIV(ops)->lock, flags);
 
     return (void *)sdom;
 }
 
 static int
-csched_dom_init(const struct scheduler *ops, struct domain *dom)
+csched2_dom_init(const struct scheduler *ops, struct domain *dom)
 {
-    struct csched_dom *sdom;
+    struct csched2_dom *sdom;
 
     printk("%s: Initializing domain %d\n", __func__, dom->domain_id);
 
     if ( is_idle_domain(dom) )
         return 0;
 
-    sdom = csched_alloc_domdata(ops, dom);
+    sdom = csched2_alloc_domdata(ops, dom);
     if ( sdom == NULL )
         return -ENOMEM;
 
@@ -1477,40 +1477,40 @@ csched_dom_init(const struct scheduler *
 }
 
 static void
-csched_free_domdata(const struct scheduler *ops, void *data)
+csched2_free_domdata(const struct scheduler *ops, void *data)
 {
     int flags;
-    struct csched_dom *sdom = data;
+    struct csched2_dom *sdom = data;
 
-    spin_lock_irqsave(&CSCHED_PRIV(ops)->lock, flags);
+    spin_lock_irqsave(&CSCHED2_PRIV(ops)->lock, flags);
 
     list_del_init(&sdom->sdom_elem);
 
-    spin_unlock_irqrestore(&CSCHED_PRIV(ops)->lock, flags);
+    spin_unlock_irqrestore(&CSCHED2_PRIV(ops)->lock, flags);
 
     xfree(data);
 }
 
 static void
-csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
+csched2_dom_destroy(const struct scheduler *ops, struct domain *dom)
 {
-    struct csched_dom *sdom = CSCHED_DOM(dom);
+    struct csched2_dom *sdom = CSCHED2_DOM(dom);
 
     BUG_ON(!list_empty(&sdom->vcpu));
 
-    csched_free_domdata(ops, CSCHED_DOM(dom));
+    csched2_free_domdata(ops, CSCHED2_DOM(dom));
 }
 
 /* How long should we let this vcpu run for? */
 static s_time_t
-csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
+csched2_runtime(const struct scheduler *ops, int cpu, struct csched2_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
-    struct csched_runqueue_data *rqd = RQD(ops, cpu);
+    s_time_t time = CSCHED2_MAX_TIMER;
+    struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
-        return CSCHED_MAX_TIMER;
+        return CSCHED2_MAX_TIMER;
 
     /* Basic time */
     time = c2t(rqd, snext->credit, snext);
@@ -1518,7 +1518,7 @@ csched_runtime(const struct scheduler *o
     /* Next guy on runqueue */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
+        struct csched2_vcpu *svc = __runq_elem(runq->next);
         s_time_t ntime;
 
         if ( ! is_idle_vcpu(svc->vcpu) )
@@ -1531,10 +1531,10 @@ csched_runtime(const struct scheduler *o
     }
 
     /* Check limits */
-    if ( time < CSCHED_MIN_TIMER )
-        time = CSCHED_MIN_TIMER;
-    else if ( time > CSCHED_MAX_TIMER )
-        time = CSCHED_MAX_TIMER;
+    if ( time < CSCHED2_MIN_TIMER )
+        time = CSCHED2_MIN_TIMER;
+    else if ( time > CSCHED2_MAX_TIMER )
+        time = CSCHED2_MAX_TIMER;
 
     return time;
 }
@@ -1544,28 +1544,28 @@ void __dump_execstate(void *unused);
 /*
  * Find a candidate.
  */
-static struct csched_vcpu *
-runq_candidate(struct csched_runqueue_data *rqd,
-               struct csched_vcpu *scurr,
+static struct csched2_vcpu *
+runq_candidate(struct csched2_runqueue_data *rqd,
+               struct csched2_vcpu *scurr,
                int cpu, s_time_t now)
 {
     struct list_head *iter;
-    struct csched_vcpu *snext = NULL;
+    struct csched2_vcpu *snext = NULL;
 
     /* Default to current if runnable, idle otherwise */
     if ( vcpu_runnable(scurr->vcpu) )
         snext = scurr;
     else
-        snext = CSCHED_VCPU(idle_vcpu[cpu]);
+        snext = CSCHED2_VCPU(idle_vcpu[cpu]);
 
     list_for_each( iter, &rqd->runq )
     {
-        struct csched_vcpu * svc = list_entry(iter, struct csched_vcpu, runq_elem);
+        struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, runq_elem);
 
         /* If this is on a different processor, don't pull it unless
-         * its credit is at least CSCHED_MIGRATE_RESIST higher. */
+         * its credit is at least CSCHED2_MIGRATE_RESIST higher. */
         if ( svc->vcpu->processor != cpu
-             && snext->credit + CSCHED_MIGRATE_RESIST > svc->credit )
+             && snext->credit + CSCHED2_MIGRATE_RESIST > svc->credit )
             continue;
 
         /* If the next one on the list has more credit than current
@@ -1586,17 +1586,17 @@ runq_candidate(struct csched_runqueue_da
  * fast for the common case.
  */
 static struct task_slice
-csched_schedule(
+csched2_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_scheduled)
 {
     const int cpu = smp_processor_id();
-    struct csched_runqueue_data *rqd;
-    struct csched_vcpu * const scurr = CSCHED_VCPU(current);
-    struct csched_vcpu *snext = NULL;
+    struct csched2_runqueue_data *rqd;
+    struct csched2_vcpu * const scurr = CSCHED2_VCPU(current);
+    struct csched2_vcpu *snext = NULL;
     struct task_slice ret;
 
     SCHED_STAT_CRANK(schedule);
-    CSCHED_VCPU_CHECK(current);
+    CSCHED2_VCPU_CHECK(current);
 
     d2printk("sc p%d c d%dv%d now %"PRI_stime"\n",
              cpu,
@@ -1604,7 +1604,7 @@ csched_schedule(
              scurr->vcpu->vcpu_id,
              now);
 
-    BUG_ON(!cpumask_test_cpu(cpu, &CSCHED_PRIV(ops)->initialized));
+    BUG_ON(!cpumask_test_cpu(cpu, &CSCHED2_PRIV(ops)->initialized));
 
     rqd = RQD(ops, cpu);
     BUG_ON(!cpumask_test_cpu(cpu, &rqd->active));
@@ -1620,9 +1620,9 @@ csched_schedule(
         {
             int rq;
             other_rqi = -2;
-            for_each_cpu ( rq, &CSCHED_PRIV(ops)->active_queues )
+            for_each_cpu ( rq, &CSCHED2_PRIV(ops)->active_queues )
             {
-                if ( scurr->rqd == &CSCHED_PRIV(ops)->rqd[rq] )
+                if ( scurr->rqd == &CSCHED2_PRIV(ops)->rqd[rq] )
                 {
                     other_rqi = rq;
                     break;
@@ -1666,7 +1666,7 @@ csched_schedule(
     if ( tasklet_work_scheduled )
     {
         trace_var(TRC_CSCHED2_SCHED_TASKLET, 0, 0,  NULL);
-        snext = CSCHED_VCPU(idle_vcpu[cpu]);
+        snext = CSCHED2_VCPU(idle_vcpu[cpu]);
     }
     else
         snext=runq_candidate(rqd, scurr, cpu, now);
@@ -1703,7 +1703,7 @@ csched_schedule(
         }
 
         /* Check for the reset condition */
-        if ( snext->credit <= CSCHED_CREDIT_RESET )
+        if ( snext->credit <= CSCHED2_CREDIT_RESET )
         {
             reset_credit(ops, cpu, now);
             balance_load(ops, cpu, now);
@@ -1718,7 +1718,7 @@ csched_schedule(
         /* Safe because lock for old processor is held */
         if ( snext->vcpu->processor != cpu )
         {
-            snext->credit += CSCHED_MIGRATE_COMPENSATION;
+            snext->credit += CSCHED2_MIGRATE_COMPENSATION;
             snext->vcpu->processor = cpu;
             ret.migrated = 1;
         }
@@ -1736,15 +1736,15 @@ csched_schedule(
     /*
      * Return task to run next...
      */
-    ret.time = csched_runtime(ops, cpu, snext);
+    ret.time = csched2_runtime(ops, cpu, snext);
     ret.task = snext->vcpu;
 
-    CSCHED_VCPU_CHECK(ret.task);
+    CSCHED2_VCPU_CHECK(ret.task);
     return ret;
 }
 
 static void
-csched_dump_vcpu(struct csched_vcpu *svc)
+csched2_dump_vcpu(struct csched2_vcpu *svc)
 {
     printk("[%i.%i] flags=%x cpu=%i",
             svc->vcpu->domain->domain_id,
@@ -1758,10 +1758,10 @@ csched_dump_vcpu(struct csched_vcpu *svc
 }
 
 static void
-csched_dump_pcpu(const struct scheduler *ops, int cpu)
+csched2_dump_pcpu(const struct scheduler *ops, int cpu)
 {
     struct list_head *runq, *iter;
-    struct csched_vcpu *svc;
+    struct csched2_vcpu *svc;
     int loop;
     char cpustr[100];
 
@@ -1775,11 +1775,11 @@ csched_dump_pcpu(const struct scheduler 
     printk("core=%s\n", cpustr);
 
     /* current VCPU */
-    svc = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
+    svc = CSCHED2_VCPU(per_cpu(schedule_data, cpu).curr);
     if ( svc )
     {
         printk("\trun: ");
-        csched_dump_vcpu(svc);
+        csched2_dump_vcpu(svc);
     }
 
     loop = 0;
@@ -1789,22 +1789,22 @@ csched_dump_pcpu(const struct scheduler 
         if ( svc )
         {
             printk("\t%3d: ", ++loop);
-            csched_dump_vcpu(svc);
+            csched2_dump_vcpu(svc);
         }
     }
 }
 
 static void
-csched_dump(const struct scheduler *ops)
+csched2_dump(const struct scheduler *ops)
 {
     struct list_head *iter_sdom, *iter_svc;
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, loop;
 
     printk("Active queues: %d\n"
            "\tdefault-weight     = %d\n",
            cpumask_weight(&prv->active_queues),
-           CSCHED_DEFAULT_WEIGHT);
+           CSCHED2_DEFAULT_WEIGHT);
     for_each_cpu(i, &prv->active_queues)
     {
         s_time_t fraction;
@@ -1829,8 +1829,8 @@ csched_dump(const struct scheduler *ops)
     loop = 0;
     list_for_each( iter_sdom, &prv->sdom )
     {
-        struct csched_dom *sdom;
-        sdom = list_entry(iter_sdom, struct csched_dom, sdom_elem);
+        struct csched2_dom *sdom;
+        sdom = list_entry(iter_sdom, struct csched2_dom, sdom_elem);
 
        printk("\tDomain: %d w %d v %d\n\t", 
               sdom->dom->domain_id, 
@@ -1839,18 +1839,18 @@ csched_dump(const struct scheduler *ops)
 
         list_for_each( iter_svc, &sdom->vcpu )
         {
-            struct csched_vcpu *svc;
-            svc = list_entry(iter_svc, struct csched_vcpu, sdom_elem);
+            struct csched2_vcpu *svc;
+            svc = list_entry(iter_svc, struct csched2_vcpu, sdom_elem);
 
             printk("\t%3d: ", ++loop);
-            csched_dump_vcpu(svc);
+            csched2_dump_vcpu(svc);
         }
     }
 }
 
-static void activate_runqueue(struct csched_private *prv, int rqi)
+static void activate_runqueue(struct csched2_private *prv, int rqi)
 {
-    struct csched_runqueue_data *rqd;
+    struct csched2_runqueue_data *rqd;
 
     rqd = prv->rqd + rqi;
 
@@ -1865,9 +1865,9 @@ static void activate_runqueue(struct csc
     cpumask_set_cpu(rqi, &prv->active_queues);
 }
 
-static void deactivate_runqueue(struct csched_private *prv, int rqi)
+static void deactivate_runqueue(struct csched2_private *prv, int rqi)
 {
-    struct csched_runqueue_data *rqd;
+    struct csched2_runqueue_data *rqd;
 
     rqd = prv->rqd + rqi;
 
@@ -1881,8 +1881,8 @@ static void init_pcpu(const struct sched
 static void init_pcpu(const struct scheduler *ops, int cpu)
 {
     int rqi, flags;
-    struct csched_private *prv = CSCHED_PRIV(ops);
-    struct csched_runqueue_data *rqd;
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
+    struct csched2_runqueue_data *rqd;
     spinlock_t *old_lock;
 
     spin_lock_irqsave(&prv->lock, flags);
@@ -1942,7 +1942,7 @@ static void init_pcpu(const struct sched
 }
 
 static void *
-csched_alloc_pdata(const struct scheduler *ops, int cpu)
+csched2_alloc_pdata(const struct scheduler *ops, int cpu)
 {
     /* Check to see if the cpu is online yet */
     /* Note: cpu 0 doesn't get a STARTING callback */
@@ -1956,11 +1956,11 @@ csched_alloc_pdata(const struct schedule
 }
 
 static void
-csched_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
+csched2_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
 {
     unsigned long flags;
-    struct csched_private *prv = CSCHED_PRIV(ops);
-    struct csched_runqueue_data *rqd;
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
+    struct csched2_runqueue_data *rqd;
     struct schedule_data *sd = &per_cpu(schedule_data, cpu);
     int rqi;
 
@@ -2004,14 +2004,14 @@ csched_free_pdata(const struct scheduler
 }
 
 static int
-csched_cpu_starting(int cpu)
+csched2_cpu_starting(int cpu)
 {
     struct scheduler *ops;
 
     /* Hope this is safe from cpupools switching things around. :-) */
     ops = per_cpu(scheduler, cpu);
 
-    if ( ops->alloc_pdata == csched_alloc_pdata )
+    if ( ops->alloc_pdata == csched2_alloc_pdata )
         init_pcpu(ops, cpu);
 
     return NOTIFY_DONE;
@@ -2026,7 +2026,7 @@ static int cpu_credit2_callback(
     switch ( action )
     {
     case CPU_STARTING:
-        csched_cpu_starting(cpu);
+        csched2_cpu_starting(cpu);
         break;
     default:
         break;
@@ -2040,17 +2040,17 @@ static struct notifier_block cpu_credit2
 };
 
 static int
-csched_global_init(void)
+csched2_global_init(void)
 {
     register_cpu_notifier(&cpu_credit2_nfb);
     return 0;
 }
 
 static int
-csched_init(struct scheduler *ops)
+csched2_init(struct scheduler *ops)
 {
     int i;
-    struct csched_private *prv;
+    struct csched2_private *prv;
 
     printk("Initializing Credit2 scheduler\n" \
            " WARNING: This is experimental software in development.\n" \
@@ -2071,7 +2071,7 @@ csched_init(struct scheduler *ops)
      * set up basic structures, and a callback when the CPU info is
      * available. */
 
-    prv = xzalloc(struct csched_private);
+    prv = xzalloc(struct csched2_private);
     if ( prv == NULL )
         return -ENOMEM;
     ops->sched_data = prv;
@@ -2091,49 +2091,49 @@ csched_init(struct scheduler *ops)
 }
 
 static void
-csched_deinit(const struct scheduler *ops)
+csched2_deinit(const struct scheduler *ops)
 {
-    struct csched_private *prv;
+    struct csched2_private *prv;
 
-    prv = CSCHED_PRIV(ops);
+    prv = CSCHED2_PRIV(ops);
     if ( prv != NULL )
         xfree(prv);
 }
 
 
-static struct csched_private _csched_priv;
+static struct csched2_private _csched2_priv;
 
 const struct scheduler sched_credit2_def = {
     .name           = "SMP Credit Scheduler rev2",
     .opt_name       = "credit2",
     .sched_id       = XEN_SCHEDULER_CREDIT2,
-    .sched_data     = &_csched_priv,
+    .sched_data     = &_csched2_priv,
 
-    .init_domain    = csched_dom_init,
-    .destroy_domain = csched_dom_destroy,
+    .init_domain    = csched2_dom_init,
+    .destroy_domain = csched2_dom_destroy,
 
-    .insert_vcpu    = csched_vcpu_insert,
-    .remove_vcpu    = csched_vcpu_remove,
+    .insert_vcpu    = csched2_vcpu_insert,
+    .remove_vcpu    = csched2_vcpu_remove,
 
-    .sleep          = csched_vcpu_sleep,
-    .wake           = csched_vcpu_wake,
+    .sleep          = csched2_vcpu_sleep,
+    .wake           = csched2_vcpu_wake,
 
-    .adjust         = csched_dom_cntl,
+    .adjust         = csched2_dom_cntl,
 
-    .pick_cpu       = csched_cpu_pick,
-    .migrate        = csched_vcpu_migrate,
-    .do_schedule    = csched_schedule,
-    .context_saved  = csched_context_saved,
+    .pick_cpu       = csched2_cpu_pick,
+    .migrate        = csched2_vcpu_migrate,
+    .do_schedule    = csched2_schedule,
+    .context_saved  = csched2_context_saved,
 
-    .dump_cpu_state = csched_dump_pcpu,
-    .dump_settings  = csched_dump,
-    .global_init    = csched_global_init,
-    .init           = csched_init,
-    .deinit         = csched_deinit,
-    .alloc_vdata    = csched_alloc_vdata,
-    .free_vdata     = csched_free_vdata,
-    .alloc_pdata    = csched_alloc_pdata,
-    .free_pdata     = csched_free_pdata,
-    .alloc_domdata  = csched_alloc_domdata,
-    .free_domdata   = csched_free_domdata,
+    .dump_cpu_state = csched2_dump_pcpu,
+    .dump_settings  = csched2_dump,
+    .global_init    = csched2_global_init,
+    .init           = csched2_init,
+    .deinit         = csched2_deinit,
+    .alloc_vdata    = csched2_alloc_vdata,
+    .free_vdata     = csched2_free_vdata,
+    .alloc_pdata    = csched2_alloc_pdata,
+    .free_pdata     = csched2_free_pdata,
+    .alloc_domdata  = csched2_alloc_domdata,
+    .free_domdata   = csched2_free_domdata,
 };

--===============7762778938496596388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7762778938496596388==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 12:30:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:30: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 1UAg8u-0003JD-6O; Wed, 27 Feb 2013 12:29:52 +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 1UAg8r-0003J7-TL
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:29:50 +0000
Received: from [85.158.137.99:57186] by server-7.bemta-3.messagelabs.com id
	C7/18-06591-D3CFD215; Wed, 27 Feb 2013 12:29:49 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361968187!299710!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI4OTI2MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25675 invoked from network); 27 Feb 2013 12:29:48 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 12:29:48 -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:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=lwDtTTAHW7gt4lhCSh3Yhaf0ZZcX/+9H8kecqyBR+YTMT1DSqON8LCqD
	gmb2W5ubTCp1TayIRFKDImzJxrisVJSeV+mpivUJXgeuQYjHHNIjS6ADa
	H0Fox7oS4t8xM7cN+vx4uoeui37KjPwyVR3BavKwVGsejJDxUIai9sJEb
	6uRAaxfqqF/P9IUj+TDZcQAvUpZ3HGzY6eH2D7IsV8zx8wtBcXkUwveYs
	Iu0Ysg8LzPRwXU7zRHs+6O8OoxuZR;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1361968188; x=1393504188;
	h=mime-version:subject:message-id:date:from:to;
	bh=1wCQAB8skZhAlLSX5gnzqbFiMOsOoH2adYWYognYdNc=;
	b=kuwxuOn1wbpbwvz9fjatQF4jbmzhipkb2hK6hl+Ih0P907D4z+neVcXr
	GoWJCxLF+fKOb9LxdHgEww5VqjAmPu/evZ3xMpBQy1NyEIYTArVRZKixq
	CLXjP6qn+h+vyYRdJWP3qTTFkF/5pbev8jOOJk0n3MqVRAQdgBIcUjfZJ
	UlI04Tmy2GEAx4YkazNlEPvvY9cE34+i2g7L1GcuLHW196/9ZmJar2g0J
	9A1a4+YPJM3iHzmdgjQeY4F+Mp47B;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.84,747,1355094000"; d="scan'208";a="138206792"
Received: from unknown (HELO abgdate50u.abg.fsc.net) ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 27 Feb 2013 13:29:47 +0100
X-IronPort-AV: E=Sophos;i="4.84,747,1355094000"; 
   d="scan'208";a="5156260"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdate50u.abg.fsc.net with SMTP; 27 Feb 2013 13:29:47 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 055FE96A7E2;
	Wed, 27 Feb 2013 13:29:47 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7762778938496596388=="
MIME-Version: 1.0
X-Mercurial-Node: 550a413da1ac4333d4ecd8033d92893b96d5d853
Message-Id: <550a413da1ac4333d4ec.1361967571@nehalem1>
Date: Wed, 27 Feb 2013 13:19:31 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Rename credit2 names to csched2_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

--===============7762778938496596388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Functions, variables, structures and macros in the credit2 scheduler had
partially the same names as in the credit scheduler. This makes it hard to
find the correct functions in backtraces or cscope.

Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>


1 file changed, 223 insertions(+), 223 deletions(-)
xen/common/sched_credit2.c |  446 ++++++++++++++++++++++----------------------



--===============7762778938496596388==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1361967550 -3600
# Node ID 550a413da1ac4333d4ecd8033d92893b96d5d853
# Parent  1d8c65aee03eaf15ce8ee50deb781b4308302b77
Rename credit2 names to csched2_*

Functions, variables, structures and macros in the credit2 scheduler had
partially the same names as in the credit scheduler. This makes it hard to
find the correct functions in backtraces or cscope.

Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*

Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>

diff -r 1d8c65aee03e -r 550a413da1ac xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Tue Feb 26 10:12:46 2013 +0000
+++ b/xen/common/sched_credit2.c	Wed Feb 27 13:19:10 2013 +0100
@@ -3,7 +3,7 @@
  * (C) 2009 - George Dunlap - Citrix Systems R&D UK, Ltd
  ****************************************************************************
  *
- *        File: common/csched_credit2.c
+ *        File: common/sched_credit2.c
  *      Author: George Dunlap
  *
  * Description: Credit-based SMP CPU scheduler
@@ -108,29 +108,29 @@
  * Basic constants
  */
 /* Default weight: How much a new domain starts with */
-#define CSCHED_DEFAULT_WEIGHT       256
+#define CSCHED2_DEFAULT_WEIGHT       256
 /* Min timer: Minimum length a timer will be set, to
  * achieve efficiency */
-#define CSCHED_MIN_TIMER            MICROSECS(500)
+#define CSCHED2_MIN_TIMER            MICROSECS(500)
 /* Amount of credit VMs begin with, and are reset to.
  * ATM, set so that highest-weight VMs can only run for 10ms
  * before a reset event. */
-#define CSCHED_CREDIT_INIT          MILLISECS(10)
+#define CSCHED2_CREDIT_INIT          MILLISECS(10)
 /* Carryover: How much "extra" credit may be carried over after
  * a reset. */
-#define CSCHED_CARRYOVER_MAX        CSCHED_MIN_TIMER
+#define CSCHED2_CARRYOVER_MAX        CSCHED2_MIN_TIMER
 /* Stickiness: Cross-L2 migration resistance.  Should be less than
  * MIN_TIMER. */
-#define CSCHED_MIGRATE_RESIST       ((opt_migrate_resist)*MICROSECS(1))
+#define CSCHED2_MIGRATE_RESIST       ((opt_migrate_resist)*MICROSECS(1))
 /* How much to "compensate" a vcpu for L2 migration */
-#define CSCHED_MIGRATE_COMPENSATION MICROSECS(50)
+#define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
 /* Reset: Value below which credit will be reset. */
-#define CSCHED_CREDIT_RESET         0
+#define CSCHED2_CREDIT_RESET         0
 /* Max timer: Maximum time a guest can be run for. */
-#define CSCHED_MAX_TIMER            MILLISECS(2)
+#define CSCHED2_MAX_TIMER            MILLISECS(2)
 
 
-#define CSCHED_IDLE_CREDIT                 (-(1<<30))
+#define CSCHED2_IDLE_CREDIT                 (-(1<<30))
 
 /*
  * Flags
@@ -138,8 +138,8 @@
 /* CSFLAG_scheduled: Is this vcpu either running on, or context-switching off,
  * a physical cpu?
  * + Accessed only with runqueue lock held
- * + Set when chosen as next in csched_schedule().
- * + Cleared after context switch has been saved in csched_context_saved()
+ * + Set when chosen as next in csched2_schedule().
+ * + Cleared after context switch has been saved in csched2_context_saved()
  * + Checked in vcpu_wake to see if we can add to the runqueue, or if we should
  *   set CSFLAG_delayed_runq_add
  * + Checked to be false in runq_insert.
@@ -148,9 +148,9 @@
 #define CSFLAG_scheduled (1<<__CSFLAG_scheduled)
 /* CSFLAG_delayed_runq_add: Do we need to add this to the runqueue once it'd done
  * being context switched out?
- * + Set when scheduling out in csched_schedule() if prev is runnable
- * + Set in csched_vcpu_wake if it finds CSFLAG_scheduled set
- * + Read in csched_context_saved().  If set, it adds prev to the runqueue and
+ * + Set when scheduling out in csched2_schedule() if prev is runnable
+ * + Set in csched2_vcpu_wake if it finds CSFLAG_scheduled set
+ * + Read in csched2_context_saved().  If set, it adds prev to the runqueue and
  *   clears the bit.
  */
 #define __CSFLAG_delayed_runq_add 2
@@ -169,14 +169,14 @@ integer_param("sched_credit2_migrate_res
 /*
  * Useful macros
  */
-#define CSCHED_PRIV(_ops)   \
-    ((struct csched_private *)((_ops)->sched_data))
-#define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
-#define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
+#define CSCHED2_PRIV(_ops)   \
+    ((struct csched2_private *)((_ops)->sched_data))
+#define CSCHED2_VCPU(_vcpu)  ((struct csched2_vcpu *) (_vcpu)->sched_priv)
+#define CSCHED2_DOM(_dom)    ((struct csched2_dom *) (_dom)->sched_priv)
 /* CPU to runq_id macro */
-#define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
+#define c2r(_ops, _cpu)     (CSCHED2_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
-#define RQD(_ops, _cpu)     (&CSCHED_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
+#define RQD(_ops, _cpu)     (&CSCHED2_PRIV(_ops)->rqd[c2r(_ops, _cpu)])
 
 /*
  * Shifts for load average.
@@ -197,7 +197,7 @@ integer_param("credit2_balance_over", op
 /*
  * Per-runqueue data
  */
-struct csched_runqueue_data {
+struct csched2_runqueue_data {
     int id;
 
     spinlock_t lock;      /* Lock for this runqueue. */
@@ -218,7 +218,7 @@ struct csched_runqueue_data {
 /*
  * System-wide private data
  */
-struct csched_private {
+struct csched2_private {
     spinlock_t lock;
     cpumask_t initialized; /* CPU is initialized for this pool */
     
@@ -226,7 +226,7 @@ struct csched_private {
 
     int runq_map[NR_CPUS];
     cpumask_t active_queues; /* Queues which may have active cpus */
-    struct csched_runqueue_data rqd[NR_CPUS];
+    struct csched2_runqueue_data rqd[NR_CPUS];
 
     int load_window_shift;
 };
@@ -234,14 +234,14 @@ struct csched_private {
 /*
  * Virtual CPU
  */
-struct csched_vcpu {
+struct csched2_vcpu {
     struct list_head rqd_elem;  /* On the runqueue data list */
     struct list_head sdom_elem; /* On the domain vcpu list */
     struct list_head runq_elem; /* On the runqueue         */
-    struct csched_runqueue_data *rqd; /* Up-pointer to the runqueue */
+    struct csched2_runqueue_data *rqd; /* Up-pointer to the runqueue */
 
     /* Up-pointers */
-    struct csched_dom *sdom;
+    struct csched2_dom *sdom;
     struct vcpu *vcpu;
 
     int weight;
@@ -254,13 +254,13 @@ struct csched_vcpu {
     s_time_t load_last_update;  /* Last time average was updated */
     s_time_t avgload;           /* Decaying queue load */
 
-    struct csched_runqueue_data *migrate_rqd; /* Pre-determined rqd to which to migrate */
+    struct csched2_runqueue_data *migrate_rqd; /* Pre-determined rqd to which to migrate */
 };
 
 /*
  * Domain
  */
-struct csched_dom {
+struct csched2_dom {
     struct list_head vcpu;
     struct list_head sdom_elem;
     struct domain *dom;
@@ -273,12 +273,12 @@ struct csched_dom {
  * Time-to-credit, credit-to-time.
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static s_time_t t2c(struct csched2_runqueue_data *rqd, s_time_t time, struct csched2_vcpu *svc)
 {
     return time * rqd->max_weight / svc->weight;
 }
 
-static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
+static s_time_t c2t(struct csched2_runqueue_data *rqd, s_time_t credit, struct csched2_vcpu *svc)
 {
     return credit * svc->weight / rqd->max_weight;
 }
@@ -288,22 +288,22 @@ static s_time_t c2t(struct csched_runque
  */
 
 static /*inline*/ int
-__vcpu_on_runq(struct csched_vcpu *svc)
+__vcpu_on_runq(struct csched2_vcpu *svc)
 {
     return !list_empty(&svc->runq_elem);
 }
 
-static /*inline*/ struct csched_vcpu *
+static /*inline*/ struct csched2_vcpu *
 __runq_elem(struct list_head *elem)
 {
-    return list_entry(elem, struct csched_vcpu, runq_elem);
+    return list_entry(elem, struct csched2_vcpu, runq_elem);
 }
 
 static void
 __update_runq_load(const struct scheduler *ops,
-                  struct csched_runqueue_data *rqd, int change, s_time_t now)
+                  struct csched2_runqueue_data *rqd, int change, s_time_t now)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     s_time_t delta=-1;
 
     now >>= LOADAVG_GRANULARITY_SHIFT;
@@ -345,9 +345,9 @@ __update_runq_load(const struct schedule
 
 static void
 __update_svc_load(const struct scheduler *ops,
-                  struct csched_vcpu *svc, int change, s_time_t now)
+                  struct csched2_vcpu *svc, int change, s_time_t now)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     s_time_t delta=-1;
     int vcpu_load;
 
@@ -390,8 +390,8 @@ __update_svc_load(const struct scheduler
 
 static void
 update_load(const struct scheduler *ops,
-            struct csched_runqueue_data *rqd,
-            struct csched_vcpu *svc, int change, s_time_t now)
+            struct csched2_runqueue_data *rqd,
+            struct csched2_vcpu *svc, int change, s_time_t now)
 {
     __update_runq_load(ops, rqd, change, now);
     if ( svc )
@@ -399,7 +399,7 @@ update_load(const struct scheduler *ops,
 }
 
 static int
-__runq_insert(struct list_head *runq, struct csched_vcpu *svc)
+__runq_insert(struct list_head *runq, struct csched2_vcpu *svc)
 {
     struct list_head *iter;
     int pos = 0;
@@ -416,7 +416,7 @@ __runq_insert(struct list_head *runq, st
 
     list_for_each( iter, runq )
     {
-        struct csched_vcpu * iter_svc = __runq_elem(iter);
+        struct csched2_vcpu * iter_svc = __runq_elem(iter);
 
         if ( svc->credit > iter_svc->credit )
         {
@@ -435,7 +435,7 @@ __runq_insert(struct list_head *runq, st
 }
 
 static void
-runq_insert(const struct scheduler *ops, unsigned int cpu, struct csched_vcpu *svc)
+runq_insert(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *svc)
 {
     struct list_head * runq = &RQD(ops, cpu)->runq;
     int pos = 0;
@@ -464,24 +464,24 @@ runq_insert(const struct scheduler *ops,
 }
 
 static inline void
-__runq_remove(struct csched_vcpu *svc)
+__runq_remove(struct csched2_vcpu *svc)
 {
     BUG_ON( !__vcpu_on_runq(svc) );
     list_del_init(&svc->runq_elem);
 }
 
-void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *, s_time_t);
+void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, s_time_t);
 
 /* Check to see if the item on the runqueue is higher priority than what's
  * currently running; if so, wake up the processor */
 static /*inline*/ void
-runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched_vcpu *new, s_time_t now)
+runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *new, s_time_t now)
 {
     int i, ipid=-1;
     s_time_t lowest=(1<<30);
-    struct csched_runqueue_data *rqd = RQD(ops, cpu);
+    struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     cpumask_t mask;
-    struct csched_vcpu * cur;
+    struct csched2_vcpu * cur;
 
     d2printk("rqt d%dv%d cd%dv%d\n",
              new->vcpu->domain->domain_id,
@@ -493,7 +493,7 @@ runq_tickle(const struct scheduler *ops,
     BUG_ON(new->rqd != rqd);
 
     /* Look at the cpu it's running on first */
-    cur = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
+    cur = CSCHED2_VCPU(per_cpu(schedule_data, cpu).curr);
     burn_credits(rqd, cur, now);
 
     if ( cur->credit < new->credit )
@@ -519,13 +519,13 @@ runq_tickle(const struct scheduler *ops,
 
     for_each_cpu(i, &mask)
     {
-        struct csched_vcpu * cur;
+        struct csched2_vcpu * cur;
 
         /* Already looked at this one above */
         if ( i == cpu )
             continue;
 
-        cur = CSCHED_VCPU(per_cpu(schedule_data, i).curr);
+        cur = CSCHED2_VCPU(per_cpu(schedule_data, i).curr);
 
         BUG_ON(is_idle_vcpu(cur->vcpu));
 
@@ -554,7 +554,7 @@ runq_tickle(const struct scheduler *ops,
 
     /* Only switch to another processor if the credit difference is greater
      * than the migrate resistance */
-    if ( ipid == -1 || lowest + CSCHED_MIGRATE_RESIST > new->credit )
+    if ( ipid == -1 || lowest + CSCHED2_MIGRATE_RESIST > new->credit )
         goto no_tickle;
 
 tickle:
@@ -581,12 +581,12 @@ no_tickle:
  */
 static void reset_credit(const struct scheduler *ops, int cpu, s_time_t now)
 {
-    struct csched_runqueue_data *rqd = RQD(ops, cpu);
+    struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *iter;
 
     list_for_each( iter, &rqd->svc )
     {
-        struct csched_vcpu * svc = list_entry(iter, struct csched_vcpu, rqd_elem);
+        struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, rqd_elem);
 
         int start_credit;
 
@@ -596,10 +596,10 @@ static void reset_credit(const struct sc
         start_credit = svc->credit;
 
         /* "Clip" credits to max carryover */
-        if ( svc->credit > CSCHED_CARRYOVER_MAX )
-            svc->credit = CSCHED_CARRYOVER_MAX;
+        if ( svc->credit > CSCHED2_CARRYOVER_MAX )
+            svc->credit = CSCHED2_CARRYOVER_MAX;
         /* And add INIT */
-        svc->credit += CSCHED_CREDIT_INIT;
+        svc->credit += CSCHED2_CREDIT_INIT;
         svc->start_time = now;
 
         /* TRACE */ {
@@ -620,16 +620,16 @@ static void reset_credit(const struct sc
     /* No need to resort runqueue, as everyone's order should be the same. */
 }
 
-void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_time_t now)
+void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *svc, s_time_t now)
 {
     s_time_t delta;
 
     /* Assert svc is current */
-    ASSERT(svc==CSCHED_VCPU(per_cpu(schedule_data, svc->vcpu->processor).curr));
+    ASSERT(svc==CSCHED2_VCPU(per_cpu(schedule_data, svc->vcpu->processor).curr));
 
     if ( is_idle_vcpu(svc->vcpu) )
     {
-        BUG_ON(svc->credit != CSCHED_IDLE_CREDIT);
+        BUG_ON(svc->credit != CSCHED2_IDLE_CREDIT);
         return;
     }
 
@@ -667,7 +667,7 @@ void burn_credits(struct csched_runqueue
 }
 
 /* Find the domain with the highest weight. */
-void update_max_weight(struct csched_runqueue_data *rqd, int new_weight, int old_weight)
+void update_max_weight(struct csched2_runqueue_data *rqd, int new_weight, int old_weight)
 {
     /* Try to avoid brute-force search:
      * - If new_weight is larger, max_weigth <- new_weight
@@ -687,7 +687,7 @@ void update_max_weight(struct csched_run
 
         list_for_each( iter, &rqd->svc )
         {
-            struct csched_vcpu * svc = list_entry(iter, struct csched_vcpu, rqd_elem);
+            struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, rqd_elem);
 
             if ( svc->weight > max_weight )
                 max_weight = svc->weight;
@@ -700,13 +700,13 @@ void update_max_weight(struct csched_run
 
 #ifndef NDEBUG
 static /*inline*/ void
-__csched_vcpu_check(struct vcpu *vc)
+__csched2_vcpu_check(struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-    struct csched_dom * const sdom = svc->sdom;
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
+    struct csched2_dom * const sdom = svc->sdom;
 
     BUG_ON( svc->vcpu != vc );
-    BUG_ON( sdom != CSCHED_DOM(vc->domain) );
+    BUG_ON( sdom != CSCHED2_DOM(vc->domain) );
     if ( sdom )
     {
         BUG_ON( is_idle_vcpu(vc) );
@@ -717,18 +717,18 @@ __csched_vcpu_check(struct vcpu *vc)
         BUG_ON( !is_idle_vcpu(vc) );
     }
 }
-#define CSCHED_VCPU_CHECK(_vc)  (__csched_vcpu_check(_vc))
+#define CSCHED2_VCPU_CHECK(_vc)  (__csched2_vcpu_check(_vc))
 #else
-#define CSCHED_VCPU_CHECK(_vc)
+#define CSCHED2_VCPU_CHECK(_vc)
 #endif
 
 static void *
-csched_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
+csched2_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd)
 {
-    struct csched_vcpu *svc;
+    struct csched2_vcpu *svc;
 
     /* Allocate per-VCPU info */
-    svc = xzalloc(struct csched_vcpu);
+    svc = xzalloc(struct csched2_vcpu);
     if ( svc == NULL )
         return NULL;
 
@@ -744,16 +744,16 @@ csched_alloc_vdata(const struct schedule
     {
         BUG_ON( svc->sdom == NULL );
 
-        svc->credit = CSCHED_CREDIT_INIT;
+        svc->credit = CSCHED2_CREDIT_INIT;
         svc->weight = svc->sdom->weight;
         /* Starting load of 50% */
-        svc->avgload = 1ULL << (CSCHED_PRIV(ops)->load_window_shift - 1);
+        svc->avgload = 1ULL << (CSCHED2_PRIV(ops)->load_window_shift - 1);
         svc->load_last_update = NOW();
     }
     else
     {
         BUG_ON( svc->sdom != NULL );
-        svc->credit = CSCHED_IDLE_CREDIT;
+        svc->credit = CSCHED2_IDLE_CREDIT;
         svc->weight = 0;
     }
 
@@ -764,7 +764,7 @@ csched_alloc_vdata(const struct schedule
 
 /* Add and remove from runqueue assignment (not active run queue) */
 static void
-__runq_assign(struct csched_vcpu *svc, struct csched_runqueue_data *rqd)
+__runq_assign(struct csched2_vcpu *svc, struct csched2_runqueue_data *rqd)
 {
 
     svc->rqd = rqd;
@@ -794,7 +794,7 @@ static void
 static void
 runq_assign(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu *svc = vc->sched_priv;
+    struct csched2_vcpu *svc = vc->sched_priv;
 
     BUG_ON(svc->rqd != NULL);
 
@@ -802,7 +802,7 @@ runq_assign(const struct scheduler *ops,
 }
 
 static void
-__runq_deassign(struct csched_vcpu *svc)
+__runq_deassign(struct csched2_vcpu *svc)
 {
     BUG_ON(__vcpu_on_runq(svc));
     BUG_ON(test_bit(__CSFLAG_scheduled, &svc->flags));
@@ -819,7 +819,7 @@ static void
 static void
 runq_deassign(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu *svc = vc->sched_priv;
+    struct csched2_vcpu *svc = vc->sched_priv;
 
     BUG_ON(svc->rqd != RQD(ops, vc->processor));
 
@@ -827,11 +827,11 @@ runq_deassign(const struct scheduler *op
 }
 
 static void
-csched_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu *svc = vc->sched_priv;
+    struct csched2_vcpu *svc = vc->sched_priv;
     struct domain * const dom = vc->domain;
-    struct csched_dom * const sdom = svc->sdom;
+    struct csched2_dom * const sdom = svc->sdom;
 
     printk("%s: Inserting d%dv%d\n",
            __func__, dom->domain_id, vc->vcpu_id);
@@ -854,22 +854,22 @@ csched_vcpu_insert(const struct schedule
         sdom->nr_vcpus++;
     }
 
-    CSCHED_VCPU_CHECK(vc);
+    CSCHED2_VCPU_CHECK(vc);
 }
 
 static void
-csched_free_vdata(const struct scheduler *ops, void *priv)
+csched2_free_vdata(const struct scheduler *ops, void *priv)
 {
-    struct csched_vcpu *svc = priv;
+    struct csched2_vcpu *svc = priv;
 
     xfree(svc);
 }
 
 static void
-csched_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-    struct csched_dom * const sdom = svc->sdom;
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
+    struct csched2_dom * const sdom = svc->sdom;
 
     BUG_ON( sdom == NULL );
     BUG_ON( !list_empty(&svc->runq_elem) );
@@ -894,9 +894,9 @@ csched_vcpu_remove(const struct schedule
 }
 
 static void
-csched_vcpu_sleep(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_sleep(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
 
     BUG_ON( is_idle_vcpu(vc) );
 
@@ -913,9 +913,9 @@ csched_vcpu_sleep(const struct scheduler
 }
 
 static void
-csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
+csched2_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
     s_time_t now = 0;
 
     /* Schedule lock should be held at this point. */
@@ -966,9 +966,9 @@ out:
 }
 
 static void
-csched_context_saved(const struct scheduler *ops, struct vcpu *vc)
+csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
     s_time_t now = NOW();
 
     vcpu_schedule_lock_irq(vc);
@@ -1004,9 +1004,9 @@ static int
 static int
 choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, min_rqi = -1, new_cpu;
-    struct csched_vcpu *svc = CSCHED_VCPU(vc);
+    struct csched2_vcpu *svc = CSCHED2_VCPU(vc);
     s_time_t min_avgload;
 
     BUG_ON(cpumask_empty(&prv->active_queues));
@@ -1063,7 +1063,7 @@ choose_cpu(const struct scheduler *ops, 
     /* Find the runqueue with the lowest instantaneous load */
     for_each_cpu(i, &prv->active_queues)
     {
-        struct csched_runqueue_data *rqd;
+        struct csched2_runqueue_data *rqd;
         s_time_t rqd_avgload;
 
         rqd = prv->rqd + i;
@@ -1112,15 +1112,15 @@ typedef struct {
 typedef struct {
     /* NB: Modified by consider() */
     s_time_t load_delta;
-    struct csched_vcpu * best_push_svc, *best_pull_svc;
+    struct csched2_vcpu * best_push_svc, *best_pull_svc;
     /* NB: Read by consider() */
-    struct csched_runqueue_data *lrqd;
-    struct csched_runqueue_data *orqd;                  
+    struct csched2_runqueue_data *lrqd;
+    struct csched2_runqueue_data *orqd;                  
 } balance_state_t;
 
 static void consider(balance_state_t *st, 
-                     struct csched_vcpu *push_svc,
-                     struct csched_vcpu *pull_svc)
+                     struct csched2_vcpu *push_svc,
+                     struct csched2_vcpu *pull_svc)
 {
     s_time_t l_load, o_load, delta;
 
@@ -1153,8 +1153,8 @@ static void consider(balance_state_t *st
 
 
 void migrate(const struct scheduler *ops,
-             struct csched_vcpu *svc, 
-             struct csched_runqueue_data *trqd, 
+             struct csched2_vcpu *svc, 
+             struct csched2_runqueue_data *trqd, 
              s_time_t now)
 {
     if ( test_bit(__CSFLAG_scheduled, &svc->flags) )
@@ -1193,7 +1193,7 @@ void migrate(const struct scheduler *ops
 
 static void balance_load(const struct scheduler *ops, int cpu, s_time_t now)
 {
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, max_delta_rqi = -1;
     struct list_head *push_iter, *pull_iter;
 
@@ -1293,7 +1293,7 @@ retry:
     list_for_each( push_iter, &st.lrqd->svc )
     {
         int inner_load_updated = 0;
-        struct csched_vcpu * push_svc = list_entry(push_iter, struct csched_vcpu, rqd_elem);
+        struct csched2_vcpu * push_svc = list_entry(push_iter, struct csched2_vcpu, rqd_elem);
 
         __update_svc_load(ops, push_svc, 0, now);
 
@@ -1303,7 +1303,7 @@ retry:
 
         list_for_each( pull_iter, &st.orqd->svc )
         {
-            struct csched_vcpu * pull_svc = list_entry(pull_iter, struct csched_vcpu, rqd_elem);
+            struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
             
             if ( ! inner_load_updated )
             {
@@ -1325,7 +1325,7 @@ retry:
 
     list_for_each( pull_iter, &st.orqd->svc )
     {
-        struct csched_vcpu * pull_svc = list_entry(pull_iter, struct csched_vcpu, rqd_elem);
+        struct csched2_vcpu * pull_svc = list_entry(pull_iter, struct csched2_vcpu, rqd_elem);
         
         /* Skip this one if it's already been flagged to migrate */
         if ( test_bit(__CSFLAG_runq_migrate_request, &pull_svc->flags) )
@@ -1349,7 +1349,7 @@ out:
 }
 
 static int
-csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc)
+csched2_cpu_pick(const struct scheduler *ops, struct vcpu *vc)
 {
     int new_cpu;
 
@@ -1359,14 +1359,14 @@ csched_cpu_pick(const struct scheduler *
 }
 
 static void
-csched_vcpu_migrate(
+csched2_vcpu_migrate(
     const struct scheduler *ops, struct vcpu *vc, unsigned int new_cpu)
 {
-    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-    struct csched_runqueue_data *trqd;
+    struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
+    struct csched2_runqueue_data *trqd;
 
     /* Check if new_cpu is valid */
-    BUG_ON(!cpumask_test_cpu(new_cpu, &CSCHED_PRIV(ops)->initialized));
+    BUG_ON(!cpumask_test_cpu(new_cpu, &CSCHED2_PRIV(ops)->initialized));
 
     trqd = RQD(ops, new_cpu);
 
@@ -1375,16 +1375,16 @@ csched_vcpu_migrate(
 }
 
 static int
-csched_dom_cntl(
+csched2_dom_cntl(
     const struct scheduler *ops,
     struct domain *d,
     struct xen_domctl_scheduler_op *op)
 {
-    struct csched_dom * const sdom = CSCHED_DOM(d);
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_dom * const sdom = CSCHED2_DOM(d);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     unsigned long flags;
 
-    /* Must hold csched_priv lock to read and update sdom,
+    /* Must hold csched2_priv lock to read and update sdom,
      * runq lock to update csvcs. */
     spin_lock_irqsave(&prv->lock, flags);
 
@@ -1408,10 +1408,10 @@ csched_dom_cntl(
             /* Update weights for vcpus, and max_weight for runqueues on which they reside */
             list_for_each ( iter, &sdom->vcpu )
             {
-                struct csched_vcpu *svc = list_entry(iter, struct csched_vcpu, sdom_elem);
+                struct csched2_vcpu *svc = list_entry(iter, struct csched2_vcpu, sdom_elem);
 
                 /* NB: Locking order is important here.  Because we grab this lock here, we
-                 * must never lock csched_priv.lock if we're holding a runqueue lock.
+                 * must never lock csched2_priv.lock if we're holding a runqueue lock.
                  * Also, calling vcpu_schedule_lock() is enough, since IRQs have already
                  * been disabled. */
                 vcpu_schedule_lock(svc->vcpu);
@@ -1432,12 +1432,12 @@ csched_dom_cntl(
 }
 
 static void *
-csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
+csched2_alloc_domdata(const struct scheduler *ops, struct domain *dom)
 {
-    struct csched_dom *sdom;
+    struct csched2_dom *sdom;
     int flags;
 
-    sdom = xzalloc(struct csched_dom);
+    sdom = xzalloc(struct csched2_dom);
     if ( sdom == NULL )
         return NULL;
 
@@ -1445,29 +1445,29 @@ csched_alloc_domdata(const struct schedu
     INIT_LIST_HEAD(&sdom->vcpu);
     INIT_LIST_HEAD(&sdom->sdom_elem);
     sdom->dom = dom;
-    sdom->weight = CSCHED_DEFAULT_WEIGHT;
+    sdom->weight = CSCHED2_DEFAULT_WEIGHT;
     sdom->nr_vcpus = 0;
 
-    spin_lock_irqsave(&CSCHED_PRIV(ops)->lock, flags);
+    spin_lock_irqsave(&CSCHED2_PRIV(ops)->lock, flags);
 
-    list_add_tail(&sdom->sdom_elem, &CSCHED_PRIV(ops)->sdom);
+    list_add_tail(&sdom->sdom_elem, &CSCHED2_PRIV(ops)->sdom);
 
-    spin_unlock_irqrestore(&CSCHED_PRIV(ops)->lock, flags);
+    spin_unlock_irqrestore(&CSCHED2_PRIV(ops)->lock, flags);
 
     return (void *)sdom;
 }
 
 static int
-csched_dom_init(const struct scheduler *ops, struct domain *dom)
+csched2_dom_init(const struct scheduler *ops, struct domain *dom)
 {
-    struct csched_dom *sdom;
+    struct csched2_dom *sdom;
 
     printk("%s: Initializing domain %d\n", __func__, dom->domain_id);
 
     if ( is_idle_domain(dom) )
         return 0;
 
-    sdom = csched_alloc_domdata(ops, dom);
+    sdom = csched2_alloc_domdata(ops, dom);
     if ( sdom == NULL )
         return -ENOMEM;
 
@@ -1477,40 +1477,40 @@ csched_dom_init(const struct scheduler *
 }
 
 static void
-csched_free_domdata(const struct scheduler *ops, void *data)
+csched2_free_domdata(const struct scheduler *ops, void *data)
 {
     int flags;
-    struct csched_dom *sdom = data;
+    struct csched2_dom *sdom = data;
 
-    spin_lock_irqsave(&CSCHED_PRIV(ops)->lock, flags);
+    spin_lock_irqsave(&CSCHED2_PRIV(ops)->lock, flags);
 
     list_del_init(&sdom->sdom_elem);
 
-    spin_unlock_irqrestore(&CSCHED_PRIV(ops)->lock, flags);
+    spin_unlock_irqrestore(&CSCHED2_PRIV(ops)->lock, flags);
 
     xfree(data);
 }
 
 static void
-csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
+csched2_dom_destroy(const struct scheduler *ops, struct domain *dom)
 {
-    struct csched_dom *sdom = CSCHED_DOM(dom);
+    struct csched2_dom *sdom = CSCHED2_DOM(dom);
 
     BUG_ON(!list_empty(&sdom->vcpu));
 
-    csched_free_domdata(ops, CSCHED_DOM(dom));
+    csched2_free_domdata(ops, CSCHED2_DOM(dom));
 }
 
 /* How long should we let this vcpu run for? */
 static s_time_t
-csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
+csched2_runtime(const struct scheduler *ops, int cpu, struct csched2_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
-    struct csched_runqueue_data *rqd = RQD(ops, cpu);
+    s_time_t time = CSCHED2_MAX_TIMER;
+    struct csched2_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
-        return CSCHED_MAX_TIMER;
+        return CSCHED2_MAX_TIMER;
 
     /* Basic time */
     time = c2t(rqd, snext->credit, snext);
@@ -1518,7 +1518,7 @@ csched_runtime(const struct scheduler *o
     /* Next guy on runqueue */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
+        struct csched2_vcpu *svc = __runq_elem(runq->next);
         s_time_t ntime;
 
         if ( ! is_idle_vcpu(svc->vcpu) )
@@ -1531,10 +1531,10 @@ csched_runtime(const struct scheduler *o
     }
 
     /* Check limits */
-    if ( time < CSCHED_MIN_TIMER )
-        time = CSCHED_MIN_TIMER;
-    else if ( time > CSCHED_MAX_TIMER )
-        time = CSCHED_MAX_TIMER;
+    if ( time < CSCHED2_MIN_TIMER )
+        time = CSCHED2_MIN_TIMER;
+    else if ( time > CSCHED2_MAX_TIMER )
+        time = CSCHED2_MAX_TIMER;
 
     return time;
 }
@@ -1544,28 +1544,28 @@ void __dump_execstate(void *unused);
 /*
  * Find a candidate.
  */
-static struct csched_vcpu *
-runq_candidate(struct csched_runqueue_data *rqd,
-               struct csched_vcpu *scurr,
+static struct csched2_vcpu *
+runq_candidate(struct csched2_runqueue_data *rqd,
+               struct csched2_vcpu *scurr,
                int cpu, s_time_t now)
 {
     struct list_head *iter;
-    struct csched_vcpu *snext = NULL;
+    struct csched2_vcpu *snext = NULL;
 
     /* Default to current if runnable, idle otherwise */
     if ( vcpu_runnable(scurr->vcpu) )
         snext = scurr;
     else
-        snext = CSCHED_VCPU(idle_vcpu[cpu]);
+        snext = CSCHED2_VCPU(idle_vcpu[cpu]);
 
     list_for_each( iter, &rqd->runq )
     {
-        struct csched_vcpu * svc = list_entry(iter, struct csched_vcpu, runq_elem);
+        struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, runq_elem);
 
         /* If this is on a different processor, don't pull it unless
-         * its credit is at least CSCHED_MIGRATE_RESIST higher. */
+         * its credit is at least CSCHED2_MIGRATE_RESIST higher. */
         if ( svc->vcpu->processor != cpu
-             && snext->credit + CSCHED_MIGRATE_RESIST > svc->credit )
+             && snext->credit + CSCHED2_MIGRATE_RESIST > svc->credit )
             continue;
 
         /* If the next one on the list has more credit than current
@@ -1586,17 +1586,17 @@ runq_candidate(struct csched_runqueue_da
  * fast for the common case.
  */
 static struct task_slice
-csched_schedule(
+csched2_schedule(
     const struct scheduler *ops, s_time_t now, bool_t tasklet_work_scheduled)
 {
     const int cpu = smp_processor_id();
-    struct csched_runqueue_data *rqd;
-    struct csched_vcpu * const scurr = CSCHED_VCPU(current);
-    struct csched_vcpu *snext = NULL;
+    struct csched2_runqueue_data *rqd;
+    struct csched2_vcpu * const scurr = CSCHED2_VCPU(current);
+    struct csched2_vcpu *snext = NULL;
     struct task_slice ret;
 
     SCHED_STAT_CRANK(schedule);
-    CSCHED_VCPU_CHECK(current);
+    CSCHED2_VCPU_CHECK(current);
 
     d2printk("sc p%d c d%dv%d now %"PRI_stime"\n",
              cpu,
@@ -1604,7 +1604,7 @@ csched_schedule(
              scurr->vcpu->vcpu_id,
              now);
 
-    BUG_ON(!cpumask_test_cpu(cpu, &CSCHED_PRIV(ops)->initialized));
+    BUG_ON(!cpumask_test_cpu(cpu, &CSCHED2_PRIV(ops)->initialized));
 
     rqd = RQD(ops, cpu);
     BUG_ON(!cpumask_test_cpu(cpu, &rqd->active));
@@ -1620,9 +1620,9 @@ csched_schedule(
         {
             int rq;
             other_rqi = -2;
-            for_each_cpu ( rq, &CSCHED_PRIV(ops)->active_queues )
+            for_each_cpu ( rq, &CSCHED2_PRIV(ops)->active_queues )
             {
-                if ( scurr->rqd == &CSCHED_PRIV(ops)->rqd[rq] )
+                if ( scurr->rqd == &CSCHED2_PRIV(ops)->rqd[rq] )
                 {
                     other_rqi = rq;
                     break;
@@ -1666,7 +1666,7 @@ csched_schedule(
     if ( tasklet_work_scheduled )
     {
         trace_var(TRC_CSCHED2_SCHED_TASKLET, 0, 0,  NULL);
-        snext = CSCHED_VCPU(idle_vcpu[cpu]);
+        snext = CSCHED2_VCPU(idle_vcpu[cpu]);
     }
     else
         snext=runq_candidate(rqd, scurr, cpu, now);
@@ -1703,7 +1703,7 @@ csched_schedule(
         }
 
         /* Check for the reset condition */
-        if ( snext->credit <= CSCHED_CREDIT_RESET )
+        if ( snext->credit <= CSCHED2_CREDIT_RESET )
         {
             reset_credit(ops, cpu, now);
             balance_load(ops, cpu, now);
@@ -1718,7 +1718,7 @@ csched_schedule(
         /* Safe because lock for old processor is held */
         if ( snext->vcpu->processor != cpu )
         {
-            snext->credit += CSCHED_MIGRATE_COMPENSATION;
+            snext->credit += CSCHED2_MIGRATE_COMPENSATION;
             snext->vcpu->processor = cpu;
             ret.migrated = 1;
         }
@@ -1736,15 +1736,15 @@ csched_schedule(
     /*
      * Return task to run next...
      */
-    ret.time = csched_runtime(ops, cpu, snext);
+    ret.time = csched2_runtime(ops, cpu, snext);
     ret.task = snext->vcpu;
 
-    CSCHED_VCPU_CHECK(ret.task);
+    CSCHED2_VCPU_CHECK(ret.task);
     return ret;
 }
 
 static void
-csched_dump_vcpu(struct csched_vcpu *svc)
+csched2_dump_vcpu(struct csched2_vcpu *svc)
 {
     printk("[%i.%i] flags=%x cpu=%i",
             svc->vcpu->domain->domain_id,
@@ -1758,10 +1758,10 @@ csched_dump_vcpu(struct csched_vcpu *svc
 }
 
 static void
-csched_dump_pcpu(const struct scheduler *ops, int cpu)
+csched2_dump_pcpu(const struct scheduler *ops, int cpu)
 {
     struct list_head *runq, *iter;
-    struct csched_vcpu *svc;
+    struct csched2_vcpu *svc;
     int loop;
     char cpustr[100];
 
@@ -1775,11 +1775,11 @@ csched_dump_pcpu(const struct scheduler 
     printk("core=%s\n", cpustr);
 
     /* current VCPU */
-    svc = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
+    svc = CSCHED2_VCPU(per_cpu(schedule_data, cpu).curr);
     if ( svc )
     {
         printk("\trun: ");
-        csched_dump_vcpu(svc);
+        csched2_dump_vcpu(svc);
     }
 
     loop = 0;
@@ -1789,22 +1789,22 @@ csched_dump_pcpu(const struct scheduler 
         if ( svc )
         {
             printk("\t%3d: ", ++loop);
-            csched_dump_vcpu(svc);
+            csched2_dump_vcpu(svc);
         }
     }
 }
 
 static void
-csched_dump(const struct scheduler *ops)
+csched2_dump(const struct scheduler *ops)
 {
     struct list_head *iter_sdom, *iter_svc;
-    struct csched_private *prv = CSCHED_PRIV(ops);
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
     int i, loop;
 
     printk("Active queues: %d\n"
            "\tdefault-weight     = %d\n",
            cpumask_weight(&prv->active_queues),
-           CSCHED_DEFAULT_WEIGHT);
+           CSCHED2_DEFAULT_WEIGHT);
     for_each_cpu(i, &prv->active_queues)
     {
         s_time_t fraction;
@@ -1829,8 +1829,8 @@ csched_dump(const struct scheduler *ops)
     loop = 0;
     list_for_each( iter_sdom, &prv->sdom )
     {
-        struct csched_dom *sdom;
-        sdom = list_entry(iter_sdom, struct csched_dom, sdom_elem);
+        struct csched2_dom *sdom;
+        sdom = list_entry(iter_sdom, struct csched2_dom, sdom_elem);
 
        printk("\tDomain: %d w %d v %d\n\t", 
               sdom->dom->domain_id, 
@@ -1839,18 +1839,18 @@ csched_dump(const struct scheduler *ops)
 
         list_for_each( iter_svc, &sdom->vcpu )
         {
-            struct csched_vcpu *svc;
-            svc = list_entry(iter_svc, struct csched_vcpu, sdom_elem);
+            struct csched2_vcpu *svc;
+            svc = list_entry(iter_svc, struct csched2_vcpu, sdom_elem);
 
             printk("\t%3d: ", ++loop);
-            csched_dump_vcpu(svc);
+            csched2_dump_vcpu(svc);
         }
     }
 }
 
-static void activate_runqueue(struct csched_private *prv, int rqi)
+static void activate_runqueue(struct csched2_private *prv, int rqi)
 {
-    struct csched_runqueue_data *rqd;
+    struct csched2_runqueue_data *rqd;
 
     rqd = prv->rqd + rqi;
 
@@ -1865,9 +1865,9 @@ static void activate_runqueue(struct csc
     cpumask_set_cpu(rqi, &prv->active_queues);
 }
 
-static void deactivate_runqueue(struct csched_private *prv, int rqi)
+static void deactivate_runqueue(struct csched2_private *prv, int rqi)
 {
-    struct csched_runqueue_data *rqd;
+    struct csched2_runqueue_data *rqd;
 
     rqd = prv->rqd + rqi;
 
@@ -1881,8 +1881,8 @@ static void init_pcpu(const struct sched
 static void init_pcpu(const struct scheduler *ops, int cpu)
 {
     int rqi, flags;
-    struct csched_private *prv = CSCHED_PRIV(ops);
-    struct csched_runqueue_data *rqd;
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
+    struct csched2_runqueue_data *rqd;
     spinlock_t *old_lock;
 
     spin_lock_irqsave(&prv->lock, flags);
@@ -1942,7 +1942,7 @@ static void init_pcpu(const struct sched
 }
 
 static void *
-csched_alloc_pdata(const struct scheduler *ops, int cpu)
+csched2_alloc_pdata(const struct scheduler *ops, int cpu)
 {
     /* Check to see if the cpu is online yet */
     /* Note: cpu 0 doesn't get a STARTING callback */
@@ -1956,11 +1956,11 @@ csched_alloc_pdata(const struct schedule
 }
 
 static void
-csched_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
+csched2_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
 {
     unsigned long flags;
-    struct csched_private *prv = CSCHED_PRIV(ops);
-    struct csched_runqueue_data *rqd;
+    struct csched2_private *prv = CSCHED2_PRIV(ops);
+    struct csched2_runqueue_data *rqd;
     struct schedule_data *sd = &per_cpu(schedule_data, cpu);
     int rqi;
 
@@ -2004,14 +2004,14 @@ csched_free_pdata(const struct scheduler
 }
 
 static int
-csched_cpu_starting(int cpu)
+csched2_cpu_starting(int cpu)
 {
     struct scheduler *ops;
 
     /* Hope this is safe from cpupools switching things around. :-) */
     ops = per_cpu(scheduler, cpu);
 
-    if ( ops->alloc_pdata == csched_alloc_pdata )
+    if ( ops->alloc_pdata == csched2_alloc_pdata )
         init_pcpu(ops, cpu);
 
     return NOTIFY_DONE;
@@ -2026,7 +2026,7 @@ static int cpu_credit2_callback(
     switch ( action )
     {
     case CPU_STARTING:
-        csched_cpu_starting(cpu);
+        csched2_cpu_starting(cpu);
         break;
     default:
         break;
@@ -2040,17 +2040,17 @@ static struct notifier_block cpu_credit2
 };
 
 static int
-csched_global_init(void)
+csched2_global_init(void)
 {
     register_cpu_notifier(&cpu_credit2_nfb);
     return 0;
 }
 
 static int
-csched_init(struct scheduler *ops)
+csched2_init(struct scheduler *ops)
 {
     int i;
-    struct csched_private *prv;
+    struct csched2_private *prv;
 
     printk("Initializing Credit2 scheduler\n" \
            " WARNING: This is experimental software in development.\n" \
@@ -2071,7 +2071,7 @@ csched_init(struct scheduler *ops)
      * set up basic structures, and a callback when the CPU info is
      * available. */
 
-    prv = xzalloc(struct csched_private);
+    prv = xzalloc(struct csched2_private);
     if ( prv == NULL )
         return -ENOMEM;
     ops->sched_data = prv;
@@ -2091,49 +2091,49 @@ csched_init(struct scheduler *ops)
 }
 
 static void
-csched_deinit(const struct scheduler *ops)
+csched2_deinit(const struct scheduler *ops)
 {
-    struct csched_private *prv;
+    struct csched2_private *prv;
 
-    prv = CSCHED_PRIV(ops);
+    prv = CSCHED2_PRIV(ops);
     if ( prv != NULL )
         xfree(prv);
 }
 
 
-static struct csched_private _csched_priv;
+static struct csched2_private _csched2_priv;
 
 const struct scheduler sched_credit2_def = {
     .name           = "SMP Credit Scheduler rev2",
     .opt_name       = "credit2",
     .sched_id       = XEN_SCHEDULER_CREDIT2,
-    .sched_data     = &_csched_priv,
+    .sched_data     = &_csched2_priv,
 
-    .init_domain    = csched_dom_init,
-    .destroy_domain = csched_dom_destroy,
+    .init_domain    = csched2_dom_init,
+    .destroy_domain = csched2_dom_destroy,
 
-    .insert_vcpu    = csched_vcpu_insert,
-    .remove_vcpu    = csched_vcpu_remove,
+    .insert_vcpu    = csched2_vcpu_insert,
+    .remove_vcpu    = csched2_vcpu_remove,
 
-    .sleep          = csched_vcpu_sleep,
-    .wake           = csched_vcpu_wake,
+    .sleep          = csched2_vcpu_sleep,
+    .wake           = csched2_vcpu_wake,
 
-    .adjust         = csched_dom_cntl,
+    .adjust         = csched2_dom_cntl,
 
-    .pick_cpu       = csched_cpu_pick,
-    .migrate        = csched_vcpu_migrate,
-    .do_schedule    = csched_schedule,
-    .context_saved  = csched_context_saved,
+    .pick_cpu       = csched2_cpu_pick,
+    .migrate        = csched2_vcpu_migrate,
+    .do_schedule    = csched2_schedule,
+    .context_saved  = csched2_context_saved,
 
-    .dump_cpu_state = csched_dump_pcpu,
-    .dump_settings  = csched_dump,
-    .global_init    = csched_global_init,
-    .init           = csched_init,
-    .deinit         = csched_deinit,
-    .alloc_vdata    = csched_alloc_vdata,
-    .free_vdata     = csched_free_vdata,
-    .alloc_pdata    = csched_alloc_pdata,
-    .free_pdata     = csched_free_pdata,
-    .alloc_domdata  = csched_alloc_domdata,
-    .free_domdata   = csched_free_domdata,
+    .dump_cpu_state = csched2_dump_pcpu,
+    .dump_settings  = csched2_dump,
+    .global_init    = csched2_global_init,
+    .init           = csched2_init,
+    .deinit         = csched2_deinit,
+    .alloc_vdata    = csched2_alloc_vdata,
+    .free_vdata     = csched2_free_vdata,
+    .alloc_pdata    = csched2_alloc_pdata,
+    .free_pdata     = csched2_free_pdata,
+    .alloc_domdata  = csched2_alloc_domdata,
+    .free_domdata   = csched2_free_domdata,
 };

--===============7762778938496596388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7762778938496596388==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 12:37:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:37: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 1UAgFo-0003cC-Cl; Wed, 27 Feb 2013 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 <Ian.Jackson@eu.citrix.com>) id 1UAgFm-0003c5-CX
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:36:58 +0000
Received: from [85.158.143.99:53866] by server-1.bemta-4.messagelabs.com id
	A5/A7-06203-9EDFD215; Wed, 27 Feb 2013 12:36:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361968580!28990831!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30282 invoked from network); 27 Feb 2013 12:36:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1952570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:36: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.297.1; Wed, 27 Feb 2013 12:36:20 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAgFA-0006HW-AM;
	Wed, 27 Feb 2013 12:36:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAgFA-0004rp-9m;
	Wed, 27 Feb 2013 12:36:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16756-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 12:36:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16756: 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 16756 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16756/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 15122
 build-i386-pvops              4 kernel-build              fail REGR. vs. 15122
 build-i386                    4 xen-build                 fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  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 13 guest-stop               fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:37:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:37: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 1UAgFo-0003cC-Cl; Wed, 27 Feb 2013 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 <Ian.Jackson@eu.citrix.com>) id 1UAgFm-0003c5-CX
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:36:58 +0000
Received: from [85.158.143.99:53866] by server-1.bemta-4.messagelabs.com id
	A5/A7-06203-9EDFD215; Wed, 27 Feb 2013 12:36:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361968580!28990831!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30282 invoked from network); 27 Feb 2013 12:36:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1952570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:36: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.297.1; Wed, 27 Feb 2013 12:36:20 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAgFA-0006HW-AM;
	Wed, 27 Feb 2013 12:36:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAgFA-0004rp-9m;
	Wed, 27 Feb 2013 12:36:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16756-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 12:36:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16756: 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 16756 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16756/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 15122
 build-i386-pvops              4 kernel-build              fail REGR. vs. 15122
 build-i386                    4 xen-build                 fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  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-xl-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   fail  never pass
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  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 13 guest-stop               fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:41:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAgJv-0003lR-2L; Wed, 27 Feb 2013 12:41: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 1UAgJu-0003lL-8t
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:41:14 +0000
Received: from [85.158.139.211:39278] by server-15.bemta-5.messagelabs.com id
	AA/36-22815-9EEFD215; Wed, 27 Feb 2013 12:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361968867!19589975!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31048 invoked from network); 27 Feb 2013 12:41:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:41:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1952770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:41: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.297.1; Wed, 27 Feb 2013 12:41:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAgJm-0006J6-K0	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:41:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAgJm-0003Os-Ek	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:41:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.65250.342258.287556@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:41:06 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-16756-mainreport@xen.org>
References: <osstest-16756-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [qemu-upstream-4.2-testing test] 16756: 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

xen.org writes ("[qemu-upstream-4.2-testing test] 16756: regressions - FAIL"):
> flight 16756 qemu-upstream-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16756/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            4 xen-build             fail REGR. vs. 15122

This is the same incident with bush-cricket hanging.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:41:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12: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 1UAgJv-0003lR-2L; Wed, 27 Feb 2013 12:41: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 1UAgJu-0003lL-8t
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:41:14 +0000
Received: from [85.158.139.211:39278] by server-15.bemta-5.messagelabs.com id
	AA/36-22815-9EEFD215; Wed, 27 Feb 2013 12:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361968867!19589975!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31048 invoked from network); 27 Feb 2013 12:41:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 12:41:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1952770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 12:41: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.297.1; Wed, 27 Feb 2013 12:41:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAgJm-0006J6-K0	for xen-devel@lists.xensource.com;
	Wed, 27 Feb 2013 12:41:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAgJm-0003Os-Ek	for
	xen-devel@lists.xensource.com; Wed, 27 Feb 2013 12:41:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20781.65250.342258.287556@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 12:41:06 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-16756-mainreport@xen.org>
References: <osstest-16756-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [qemu-upstream-4.2-testing test] 16756: 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

xen.org writes ("[qemu-upstream-4.2-testing test] 16756: regressions - FAIL"):
> flight 16756 qemu-upstream-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16756/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            4 xen-build             fail REGR. vs. 15122

This is the same incident with bush-cricket hanging.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:44:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:44: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 1UAgMh-0003wI-LV; Wed, 27 Feb 2013 12:44: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 1UAgMg-0003w8-ME
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:44:06 +0000
Received: from [85.158.143.99:40913] by server-2.bemta-4.messagelabs.com id
	55/F1-12656-59FFD215; Wed, 27 Feb 2013 12:44:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361969039!29499985!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14747 invoked from network); 27 Feb 2013 12:43:59 -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 Feb 2013 12:43:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 12:43:59 +0000
Message-Id: <512E0D9A02000078000C17E2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 12:43:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <550a413da1ac4333d4ec.1361967571@nehalem1>
In-Reply-To: <550a413da1ac4333d4ec.1361967571@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Rename credit2 names to csched2_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:19, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> Functions, variables, structures and macros in the credit2 scheduler had
> partially the same names as in the credit scheduler. This makes it hard to
> find the correct functions in backtraces or cscope.
> 
> Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*

I don't think this is a suitable approach - if anything, we should aim
at having printed static symbols (in backtraces etc) prefixed with
their source file name. I would even question quite a few of the
csched_ prefixes in credit1...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:44:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:44: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 1UAgMh-0003wI-LV; Wed, 27 Feb 2013 12:44: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 1UAgMg-0003w8-ME
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:44:06 +0000
Received: from [85.158.143.99:40913] by server-2.bemta-4.messagelabs.com id
	55/F1-12656-59FFD215; Wed, 27 Feb 2013 12:44:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361969039!29499985!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14747 invoked from network); 27 Feb 2013 12:43:59 -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 Feb 2013 12:43:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 12:43:59 +0000
Message-Id: <512E0D9A02000078000C17E2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 12:43:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <550a413da1ac4333d4ec.1361967571@nehalem1>
In-Reply-To: <550a413da1ac4333d4ec.1361967571@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Rename credit2 names to csched2_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:19, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> Functions, variables, structures and macros in the credit2 scheduler had
> partially the same names as in the credit scheduler. This makes it hard to
> find the correct functions in backtraces or cscope.
> 
> Rename all names in credit2 from csched_*/CSCHED_* to csched2_*/CSCHED2_*

I don't think this is a suitable approach - if anything, we should aim
at having printed static symbols (in backtraces etc) prefixed with
their source file name. I would even question quite a few of the
csched_ prefixes in credit1...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:44:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:44: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 1UAgNN-0003zA-3b; Wed, 27 Feb 2013 12:44:49 +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 1UAgNL-0003yz-HY
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:44:47 +0000
Received: from [85.158.143.99:45824] by server-1.bemta-4.messagelabs.com id
	C7/CF-06203-EBFFD215; Wed, 27 Feb 2013 12:44:46 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361969085!28836394!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7377 invoked from network); 27 Feb 2013 12:44:45 -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; 27 Feb 2013 12:44:45 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 2C22D544F9; Wed, 27 Feb 2013 13:44:44 +0100 (CET)
Date: Wed, 27 Feb 2013 13:44:43 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130227124443.GA5582@waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
	<20130226223249.GD27098@waldi.eu.org>
	<1361967427.26546.368.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361967427.26546.368.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 12:17:07PM +0000, Ian Campbell wrote:
> On Tue, 2013-02-26 at 22:32 +0000, Bastian Blank wrote:
> > Add trusted decompressors based on hypervisor code.
> > This are used in mini-os by pv-grub.
> I think this is a reasonably pragmatic way to arrange the build.

What should be fixed later:
- Use standard types in the decompressors (this both extends compiler
  support and portability)
- Remove stuff like always_inline (the compiler almost always knows
  better these days)

What should be done now:
- Drop bzip2 and lzma decoders. I have never seen bzip2 used anywhere
  because it is slow and lzma is replaced entirely by xz.
- Fix the arch detection for the xz bcj decoders.

> I'm not sure "trusted" is quite the right term though, these aren't
> really any more trustworthy than the library supplied ones -- they are
> just more suitable for a mini-os environment.

I used the term "trusted" because it should not be fed with untrusted
input. So it should not be used in the normal libxenguest. In the case
of pv-grub, all input is trusted as it runs in the same security domain.

Bastian

-- 
I'm frequently appalled by the low regard you Earthmen have for life.
		-- Spock, "The Galileo Seven", stardate 2822.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:44:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:44: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 1UAgNN-0003zA-3b; Wed, 27 Feb 2013 12:44:49 +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 1UAgNL-0003yz-HY
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:44:47 +0000
Received: from [85.158.143.99:45824] by server-1.bemta-4.messagelabs.com id
	C7/CF-06203-EBFFD215; Wed, 27 Feb 2013 12:44:46 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1361969085!28836394!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7377 invoked from network); 27 Feb 2013 12:44:45 -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; 27 Feb 2013 12:44:45 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 2C22D544F9; Wed, 27 Feb 2013 13:44:44 +0100 (CET)
Date: Wed, 27 Feb 2013 13:44:43 +0100
From: Bastian Blank <waldi@debian.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130227124443.GA5582@waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
	<20130226223249.GD27098@waldi.eu.org>
	<1361967427.26546.368.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361967427.26546.368.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 12:17:07PM +0000, Ian Campbell wrote:
> On Tue, 2013-02-26 at 22:32 +0000, Bastian Blank wrote:
> > Add trusted decompressors based on hypervisor code.
> > This are used in mini-os by pv-grub.
> I think this is a reasonably pragmatic way to arrange the build.

What should be fixed later:
- Use standard types in the decompressors (this both extends compiler
  support and portability)
- Remove stuff like always_inline (the compiler almost always knows
  better these days)

What should be done now:
- Drop bzip2 and lzma decoders. I have never seen bzip2 used anywhere
  because it is slow and lzma is replaced entirely by xz.
- Fix the arch detection for the xz bcj decoders.

> I'm not sure "trusted" is quite the right term though, these aren't
> really any more trustworthy than the library supplied ones -- they are
> just more suitable for a mini-os environment.

I used the term "trusted" because it should not be fed with untrusted
input. So it should not be used in the normal libxenguest. In the case
of pv-grub, all input is trusted as it runs in the same security domain.

Bastian

-- 
I'm frequently appalled by the low regard you Earthmen have for life.
		-- Spock, "The Galileo Seven", stardate 2822.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:49:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:49: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 1UAgRV-0004Ez-QX; Wed, 27 Feb 2013 12:49:05 +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 1UAgRU-0004Eq-DQ
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:49:04 +0000
Received: from [85.158.143.99:12302] by server-3.bemta-4.messagelabs.com id
	3D/84-02186-FB00E215; Wed, 27 Feb 2013 12:49:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361969338!19697922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11500 invoked from network); 27 Feb 2013 12:48:58 -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; 27 Feb 2013 12:48:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 12:48:57 +0000
Message-Id: <512E0EC702000078000C17F4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 12:48:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
	<512DE2AF02000078000C15F0@nat28.tlf.novell.com>
	<CAFLBxZZBQvknu+Mfqz02d5ZeazVDUpVqDCP52CHr1nHR14tdQw@mail.gmail.com>
	<CAFLBxZa7xih+VMfso8JXGXyZWChTOT=E5=6Zna7pwoPYAFkiEw@mail.gmail.com>
In-Reply-To: <CAFLBxZa7xih+VMfso8JXGXyZWChTOT=E5=6Zna7pwoPYAFkiEw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:31, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Feb 27, 2013 at 11:35 AM, George Dunlap <George.Dunlap@eu.citrix.com 
>> wrote:
> 
>> On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 26.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com>
>>> wrote:
>>> > @@ -271,16 +272,24 @@ struct csched_dom {
>>> >
>>> >  /*
>>> >   * Time-to-credit, credit-to-time.
>>> > + *
>>> > + * We keep track of the "residual" time to make sure that frequent
>>> short
>>> > + * schedules still get accounted for in the end.
>>> > + *
>>> >   * FIXME: Do pre-calculated division?
>>> >   */
>>> > -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
>>> struct csched_vcpu *svc)
>>> > +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
>>> > +                          struct csched_vcpu *svc)
>>> >  {
>>> > -    return time * rqd->max_weight / svc->weight;
>>> > +    uint64_t val = time * rqd->max_weight + svc->residual;
>>> > +
>>> > +    svc->residual = do_div(val, svc->weight);
>>> > +    svc->credit -= val;
>>> >  }
>>> >
>>> >  static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
>>> struct csched_vcpu *svc)
>>> >  {
>>> > -    return credit * svc->weight / rqd->max_weight;
>>> > +    return (credit * svc->weight) / rqd->max_weight;
>>>
>>> So you dropped the subtraction of svc->residual here - why?
>>>
>>> And if indeed intended, the insertion of parentheses here could be
>>> dropped?
>>>
>>
>> Well for one I think the equation was wrong -- the residual is units of
>> "time", so you should have subtracted the residual after dividing by
>> max_weight.  (From a mathematical perspective, svc->weight /
>> rqd->max_weight is the ratio that changes units of "credit" into units of
>> "time; if we were using floating point ops I might put parentheses around
>> that ratio to make it more clear that's what's going on.)
>>
> 
> 
> Hmm, on further investigation, I think I've convinced myself that this
> reasoning is wrong, and your original equation was correct.
> 
> However, the difference will only ever end up to be one nanosecond, which
> (if used) will be subtracted from the credit after the reset; so I think we
> might as well do without the subtraction here.

Oh, I didn't realize this would only be a nanosecond - my
understanding was that it would be up to (but not including) a
credit unit.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:49:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:49: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 1UAgRV-0004Ez-QX; Wed, 27 Feb 2013 12:49:05 +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 1UAgRU-0004Eq-DQ
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:49:04 +0000
Received: from [85.158.143.99:12302] by server-3.bemta-4.messagelabs.com id
	3D/84-02186-FB00E215; Wed, 27 Feb 2013 12:49:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361969338!19697922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11500 invoked from network); 27 Feb 2013 12:48:58 -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; 27 Feb 2013 12:48:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 12:48:57 +0000
Message-Id: <512E0EC702000078000C17F4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 12:48:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
	<512DE2AF02000078000C15F0@nat28.tlf.novell.com>
	<CAFLBxZZBQvknu+Mfqz02d5ZeazVDUpVqDCP52CHr1nHR14tdQw@mail.gmail.com>
	<CAFLBxZa7xih+VMfso8JXGXyZWChTOT=E5=6Zna7pwoPYAFkiEw@mail.gmail.com>
In-Reply-To: <CAFLBxZa7xih+VMfso8JXGXyZWChTOT=E5=6Zna7pwoPYAFkiEw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:31, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Feb 27, 2013 at 11:35 AM, George Dunlap <George.Dunlap@eu.citrix.com 
>> wrote:
> 
>> On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 26.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com>
>>> wrote:
>>> > @@ -271,16 +272,24 @@ struct csched_dom {
>>> >
>>> >  /*
>>> >   * Time-to-credit, credit-to-time.
>>> > + *
>>> > + * We keep track of the "residual" time to make sure that frequent
>>> short
>>> > + * schedules still get accounted for in the end.
>>> > + *
>>> >   * FIXME: Do pre-calculated division?
>>> >   */
>>> > -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
>>> struct csched_vcpu *svc)
>>> > +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
>>> > +                          struct csched_vcpu *svc)
>>> >  {
>>> > -    return time * rqd->max_weight / svc->weight;
>>> > +    uint64_t val = time * rqd->max_weight + svc->residual;
>>> > +
>>> > +    svc->residual = do_div(val, svc->weight);
>>> > +    svc->credit -= val;
>>> >  }
>>> >
>>> >  static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
>>> struct csched_vcpu *svc)
>>> >  {
>>> > -    return credit * svc->weight / rqd->max_weight;
>>> > +    return (credit * svc->weight) / rqd->max_weight;
>>>
>>> So you dropped the subtraction of svc->residual here - why?
>>>
>>> And if indeed intended, the insertion of parentheses here could be
>>> dropped?
>>>
>>
>> Well for one I think the equation was wrong -- the residual is units of
>> "time", so you should have subtracted the residual after dividing by
>> max_weight.  (From a mathematical perspective, svc->weight /
>> rqd->max_weight is the ratio that changes units of "credit" into units of
>> "time; if we were using floating point ops I might put parentheses around
>> that ratio to make it more clear that's what's going on.)
>>
> 
> 
> Hmm, on further investigation, I think I've convinced myself that this
> reasoning is wrong, and your original equation was correct.
> 
> However, the difference will only ever end up to be one nanosecond, which
> (if used) will be subtracted from the credit after the reset; so I think we
> might as well do without the subtraction here.

Oh, I didn't realize this would only be a nanosecond - my
understanding was that it would be up to (but not including) a
credit unit.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:55:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:55: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 1UAgXt-0004UM-Lo; Wed, 27 Feb 2013 12:55:41 +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 1UAgXs-0004UH-HV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:55:40 +0000
Received: from [85.158.139.211:49270] by server-15.bemta-5.messagelabs.com id
	A4/27-22815-B420E215; Wed, 27 Feb 2013 12:55:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361969675!18876710!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17790 invoked from network); 27 Feb 2013 12:54:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 12:54:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 12:54:34 +0000
Message-Id: <512E101802000078000C17FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 12:54:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
In-Reply-To: <1769529756.20130227124648@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22

Which is -EINVAL. With nothing else printed, I'm afraid you need to
find the origin of this return value by instrumenting the involved
call tree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 12:55:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 12:55: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 1UAgXt-0004UM-Lo; Wed, 27 Feb 2013 12:55:41 +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 1UAgXs-0004UH-HV
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:55:40 +0000
Received: from [85.158.139.211:49270] by server-15.bemta-5.messagelabs.com id
	A4/27-22815-B420E215; Wed, 27 Feb 2013 12:55:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361969675!18876710!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17790 invoked from network); 27 Feb 2013 12:54:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 12:54:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 12:54:34 +0000
Message-Id: <512E101802000078000C17FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 12:54:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
In-Reply-To: <1769529756.20130227124648@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22

Which is -EINVAL. With nothing else printed, I'm afraid you need to
find the origin of this return value by instrumenting the involved
call tree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 13:16:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13: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 1UAgrv-0005I0-2x; Wed, 27 Feb 2013 13:16:23 +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 1UAgrt-0005Hr-8C
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:16:21 +0000
Received: from [85.158.139.211:49645] by server-8.bemta-5.messagelabs.com id
	C8/F9-05790-4270E215; Wed, 27 Feb 2013 13:16:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361970896!19457895!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31138 invoked from network); 27 Feb 2013 13:14:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 13:14:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9481388"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 13:14:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 08:14:54 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UAgqU-0001ZT-Bx;
	Wed, 27 Feb 2013 13:14:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 13:14:54 +0000
Message-ID: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: tim@xen.org, jbuelich@suse.com, keir@xen.org,
	Ian Campbell <ian.campbell@citrix.com>, stefano.stabellini@citrix.com
Subject: [Xen-devel] [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 always 64-bit on ARM, not BITS_PER_LONG

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
Cc: tim@xen.org
Cc: stefano.stabellini@citrix.com
Cc: jbuelich@suse.com
---
 xen/include/asm-arm/config.h |    3 +++
 xen/include/asm-x86/config.h |    2 ++
 xen/include/xen/sched.h      |    4 ++--
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 3910dd2..8be8563 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -22,6 +22,9 @@
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
 
+/* xen_ulong_t is always 64 bits */
+#define BITS_PER_XEN_ULONG 64
+
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 70f70b3..f68afd8 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -14,6 +14,8 @@
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
 #define BITS_PER_BYTE 8
 
+#define BITS_PER_XEN_ULONG BITS_PER_LONG
+
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e108436..ccd0496 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -46,9 +46,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 extern struct domain *dom0;
 
 #ifndef CONFIG_COMPAT
-#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
+#define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
 #else
-#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
+#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_XEN_ULONG)
 #endif
 #define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
 #define EVTCHNS_PER_BUCKET 128
-- 
1.7.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 Feb 27 13:16:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13: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 1UAgrv-0005I0-2x; Wed, 27 Feb 2013 13:16:23 +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 1UAgrt-0005Hr-8C
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:16:21 +0000
Received: from [85.158.139.211:49645] by server-8.bemta-5.messagelabs.com id
	C8/F9-05790-4270E215; Wed, 27 Feb 2013 13:16:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1361970896!19457895!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31138 invoked from network); 27 Feb 2013 13:14:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 13:14:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9481388"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 13:14:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 08:14:54 -0500
Received: from drall.uk.xensource.com ([10.80.16.71])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UAgqU-0001ZT-Bx;
	Wed, 27 Feb 2013 13:14:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 13:14:54 +0000
Message-ID: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: tim@xen.org, jbuelich@suse.com, keir@xen.org,
	Ian Campbell <ian.campbell@citrix.com>, stefano.stabellini@citrix.com
Subject: [Xen-devel] [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 always 64-bit on ARM, not BITS_PER_LONG

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: keir@xen.org
Cc: tim@xen.org
Cc: stefano.stabellini@citrix.com
Cc: jbuelich@suse.com
---
 xen/include/asm-arm/config.h |    3 +++
 xen/include/asm-x86/config.h |    2 ++
 xen/include/xen/sched.h      |    4 ++--
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 3910dd2..8be8563 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -22,6 +22,9 @@
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
 
+/* xen_ulong_t is always 64 bits */
+#define BITS_PER_XEN_ULONG 64
+
 #define CONFIG_PAGING_ASSISTANCE 1
 
 #define CONFIG_PAGING_LEVELS 3
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 70f70b3..f68afd8 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -14,6 +14,8 @@
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
 #define BITS_PER_BYTE 8
 
+#define BITS_PER_XEN_ULONG BITS_PER_LONG
+
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e108436..ccd0496 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -46,9 +46,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 extern struct domain *dom0;
 
 #ifndef CONFIG_COMPAT
-#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
+#define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
 #else
-#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
+#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_XEN_ULONG)
 #endif
 #define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
 #define EVTCHNS_PER_BUCKET 128
-- 
1.7.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 Feb 27 13:17:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13:17: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 1UAgsk-0005Lr-HE; Wed, 27 Feb 2013 13:17:14 +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 1UAgsi-0005Ld-5w
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:17:12 +0000
Received: from [193.109.254.147:24783] by server-1.bemta-14.messagelabs.com id
	22/43-29874-7570E215; Wed, 27 Feb 2013 13:17:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361970964!9749430!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 27 Feb 2013 13:16:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 13:16:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1954735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 13:16: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.297.1;
	Wed, 27 Feb 2013 13:16:04 +0000
Message-ID: <1361970962.26546.376.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 13:16:02 +0000
In-Reply-To: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
References: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	jbeulich@suse.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With Jan's correct address this time...

On Wed, 2013-02-27 at 13:14 +0000, Ian Campbell wrote:
> This is always 64-bit on ARM, not BITS_PER_LONG
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: keir@xen.org
> Cc: tim@xen.org
> Cc: stefano.stabellini@citrix.com
> Cc: jbuelich@suse.com
> ---
>  xen/include/asm-arm/config.h |    3 +++
>  xen/include/asm-x86/config.h |    2 ++
>  xen/include/xen/sched.h      |    4 ++--
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 3910dd2..8be8563 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -22,6 +22,9 @@
>  #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  
> +/* xen_ulong_t is always 64 bits */
> +#define BITS_PER_XEN_ULONG 64
> +
>  #define CONFIG_PAGING_ASSISTANCE 1
>  
>  #define CONFIG_PAGING_LEVELS 3
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 70f70b3..f68afd8 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -14,6 +14,8 @@
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  #define BITS_PER_BYTE 8
>  
> +#define BITS_PER_XEN_ULONG BITS_PER_LONG
> +
>  #define CONFIG_X86 1
>  #define CONFIG_X86_HT 1
>  #define CONFIG_PAGING_ASSISTANCE 1
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index e108436..ccd0496 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -46,9 +46,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>  extern struct domain *dom0;
>  
>  #ifndef CONFIG_COMPAT
> -#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
> +#define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
>  #else
> -#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
> +#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_XEN_ULONG)
>  #endif
>  #define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
>  #define EVTCHNS_PER_BUCKET 128



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 13:17:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13:17: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 1UAgsk-0005Lr-HE; Wed, 27 Feb 2013 13:17:14 +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 1UAgsi-0005Ld-5w
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:17:12 +0000
Received: from [193.109.254.147:24783] by server-1.bemta-14.messagelabs.com id
	22/43-29874-7570E215; Wed, 27 Feb 2013 13:17:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1361970964!9749430!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 27 Feb 2013 13:16:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 13:16:06 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1954735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 13:16: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.297.1;
	Wed, 27 Feb 2013 13:16:04 +0000
Message-ID: <1361970962.26546.376.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 13:16:02 +0000
In-Reply-To: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
References: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, "Keir \(Xen.org\)" <keir@xen.org>,
	jbeulich@suse.com, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With Jan's correct address this time...

On Wed, 2013-02-27 at 13:14 +0000, Ian Campbell wrote:
> This is always 64-bit on ARM, not BITS_PER_LONG
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: keir@xen.org
> Cc: tim@xen.org
> Cc: stefano.stabellini@citrix.com
> Cc: jbuelich@suse.com
> ---
>  xen/include/asm-arm/config.h |    3 +++
>  xen/include/asm-x86/config.h |    2 ++
>  xen/include/xen/sched.h      |    4 ++--
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 3910dd2..8be8563 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -22,6 +22,9 @@
>  #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  
> +/* xen_ulong_t is always 64 bits */
> +#define BITS_PER_XEN_ULONG 64
> +
>  #define CONFIG_PAGING_ASSISTANCE 1
>  
>  #define CONFIG_PAGING_LEVELS 3
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 70f70b3..f68afd8 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -14,6 +14,8 @@
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  #define BITS_PER_BYTE 8
>  
> +#define BITS_PER_XEN_ULONG BITS_PER_LONG
> +
>  #define CONFIG_X86 1
>  #define CONFIG_X86_HT 1
>  #define CONFIG_PAGING_ASSISTANCE 1
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index e108436..ccd0496 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -46,9 +46,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>  extern struct domain *dom0;
>  
>  #ifndef CONFIG_COMPAT
> -#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
> +#define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
>  #else
> -#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
> +#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_XEN_ULONG)
>  #endif
>  #define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
>  #define EVTCHNS_PER_BUCKET 128



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 13:17:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13:17: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 1UAgss-0005N3-3f; Wed, 27 Feb 2013 13:17: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 1UAgsq-0005Ml-Fw
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:17:20 +0000
Received: from [85.158.138.51:34856] by server-13.bemta-3.messagelabs.com id
	B5/45-25744-F570E215; Wed, 27 Feb 2013 13:17:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361971038!29534558!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4739 invoked from network); 27 Feb 2013 13:17:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 13:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1954883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 13:17: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.297.1;
	Wed, 27 Feb 2013 13:17:18 +0000
Message-ID: <1361971036.26546.377.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 13:17:16 +0000
In-Reply-To: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
> Use a list of pointers to simplify the handling of 32- vs 64-bit.
> 
> Also on ARM the section name is ".init_array" and not ".ctors".

Any comments/ack/nacks?

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
> Cc: keir@xen.org
> ---
> This applies independently of my 64-bit ARM series.
> ---
>  xen/arch/arm/xen.lds.S |   10 ++++------
>  xen/arch/x86/xen.lds.S |    6 ++----
>  xen/common/lib.c       |   13 +++++--------
>  3 files changed, 11 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 9043994..fd755d7 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -91,12 +91,10 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
>  
> -       . = ALIGN(4);
> -       __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> -       *(.ctors)
> -       LONG(0)
> -       __CTOR_END__ = .;
> +       . = ALIGN(8);
> +       __ctors_start = .;
> +       *(.init_array)
> +       __ctors_end = .;
>    } :text
>    . = ALIGN(32);
>    .init.setup : {
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 5570389..d959941 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -110,11 +110,9 @@ SECTIONS
>         __trampoline_seg_stop = .;
>  
>         . = ALIGN(8);
> -       __CTOR_LIST__ = .;
> -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> +       __ctors_start = .;
>         *(.ctors)
> -       QUAD(0)
> -       __CTOR_END__ = .;
> +       __ctors_end = .;
>    } :text
>    . = ALIGN(32);
>    .init.setup : {
> diff --git a/xen/common/lib.c b/xen/common/lib.c
> index e0c65cf..6b80601 100644
> --- a/xen/common/lib.c
> +++ b/xen/common/lib.c
> @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
>      return ret;
>  }
>  
> -extern const struct
> -{
> -    unsigned long count;
> -    void (*funcs[1])(void);
> -} __CTOR_LIST__;
> +typedef void (*ctor_func_t)(void);
> +extern const ctor_func_t __ctors_start[], __ctors_end[];
>  
>  void __init init_constructors(void)
>  {
> -    unsigned long n;
> -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> -        __CTOR_LIST__.funcs[n]();
> +    const ctor_func_t *f;
> +    for (f = __ctors_start; f < __ctors_end; ++f )
> +        (*f)();
>  }
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 13:17:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13:17: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 1UAgss-0005N3-3f; Wed, 27 Feb 2013 13:17: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 1UAgsq-0005Ml-Fw
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:17:20 +0000
Received: from [85.158.138.51:34856] by server-13.bemta-3.messagelabs.com id
	B5/45-25744-F570E215; Wed, 27 Feb 2013 13:17:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361971038!29534558!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4739 invoked from network); 27 Feb 2013 13:17:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 13:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1954883"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 13:17: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.297.1;
	Wed, 27 Feb 2013 13:17:18 +0000
Message-ID: <1361971036.26546.377.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 13:17:16 +0000
In-Reply-To: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
> Use a list of pointers to simplify the handling of 32- vs 64-bit.
> 
> Also on ARM the section name is ".init_array" and not ".ctors".

Any comments/ack/nacks?

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
> Cc: keir@xen.org
> ---
> This applies independently of my 64-bit ARM series.
> ---
>  xen/arch/arm/xen.lds.S |   10 ++++------
>  xen/arch/x86/xen.lds.S |    6 ++----
>  xen/common/lib.c       |   13 +++++--------
>  3 files changed, 11 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 9043994..fd755d7 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -91,12 +91,10 @@ SECTIONS
>         *(.init.data.rel)
>         *(.init.data.rel.*)
>  
> -       . = ALIGN(4);
> -       __CTOR_LIST__ = .;
> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> -       *(.ctors)
> -       LONG(0)
> -       __CTOR_END__ = .;
> +       . = ALIGN(8);
> +       __ctors_start = .;
> +       *(.init_array)
> +       __ctors_end = .;
>    } :text
>    . = ALIGN(32);
>    .init.setup : {
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 5570389..d959941 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -110,11 +110,9 @@ SECTIONS
>         __trampoline_seg_stop = .;
>  
>         . = ALIGN(8);
> -       __CTOR_LIST__ = .;
> -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> +       __ctors_start = .;
>         *(.ctors)
> -       QUAD(0)
> -       __CTOR_END__ = .;
> +       __ctors_end = .;
>    } :text
>    . = ALIGN(32);
>    .init.setup : {
> diff --git a/xen/common/lib.c b/xen/common/lib.c
> index e0c65cf..6b80601 100644
> --- a/xen/common/lib.c
> +++ b/xen/common/lib.c
> @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
>      return ret;
>  }
>  
> -extern const struct
> -{
> -    unsigned long count;
> -    void (*funcs[1])(void);
> -} __CTOR_LIST__;
> +typedef void (*ctor_func_t)(void);
> +extern const ctor_func_t __ctors_start[], __ctors_end[];
>  
>  void __init init_constructors(void)
>  {
> -    unsigned long n;
> -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> -        __CTOR_LIST__.funcs[n]();
> +    const ctor_func_t *f;
> +    for (f = __ctors_start; f < __ctors_end; ++f )
> +        (*f)();
>  }
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 13:38:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13: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 1UAhCa-000625-VI; Wed, 27 Feb 2013 13:37:44 +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 1UAhCZ-00061y-1G
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:37:43 +0000
Received: from [85.158.139.211:26617] by server-7.bemta-5.messagelabs.com id
	65/E8-12441-62C0E215; Wed, 27 Feb 2013 13:37:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361972261!18606012!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA2MDI4MjU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA2MDI4MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24600 invoked from network); 27 Feb 2013 13:37:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-206.messagelabs.com with SMTP;
	27 Feb 2013 13:37:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDWwcZZyw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-072-069.pools.arcor-ip.net [84.57.72.69])
	by smtp.strato.de (jorabe mo16) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L0413bp1RCd91M ;
	Wed, 27 Feb 2013 14:37:41 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 097101884C; Wed, 27 Feb 2013 14:37:40 +0100 (CET)
Date: Wed, 27 Feb 2013 14:37:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130227133740.GA1822@aepfle.de>
References: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
	<20780.62185.634588.412741@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.62185.634588.412741@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xc: update tty detection in
 stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/xc: update tty detection in stdiostream_progress"):
> > tools/xc: update tty detection in stdiostream_progress
> > 
> > As suggested by IanJ:
> > Check isatty only once to preserve the errno of ->progress users, and to
> > reduce the noice in strace output.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> Thanks.  But how did you test this ?  It doesn't compile.

I noticed that compiler error but forgot to do qrefresh before sending.

> Also I think it would be better to name the struct member something
> other than "isatty" since that's also the function name.  In theory it
> should be OK but in practice I worry about compiler warnings etc.
> 
> How about "tty" ?

Will rename the member to tty and resend.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 13:38:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 13: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 1UAhCa-000625-VI; Wed, 27 Feb 2013 13:37:44 +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 1UAhCZ-00061y-1G
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 13:37:43 +0000
Received: from [85.158.139.211:26617] by server-7.bemta-5.messagelabs.com id
	65/E8-12441-62C0E215; Wed, 27 Feb 2013 13:37:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361972261!18606012!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA2MDI4MjU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA2MDI4MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24600 invoked from network); 27 Feb 2013 13:37:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-206.messagelabs.com with SMTP;
	27 Feb 2013 13:37:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDWwcZZyw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-072-069.pools.arcor-ip.net [84.57.72.69])
	by smtp.strato.de (jorabe mo16) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L0413bp1RCd91M ;
	Wed, 27 Feb 2013 14:37:41 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 097101884C; Wed, 27 Feb 2013 14:37:40 +0100 (CET)
Date: Wed, 27 Feb 2013 14:37:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20130227133740.GA1822@aepfle.de>
References: <1b36a6c0a956cc94ddb0.1361563725@probook.site>
	<20780.62185.634588.412741@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20780.62185.634588.412741@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/xc: update tty detection in
 stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Feb 26, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] tools/xc: update tty detection in stdiostream_progress"):
> > tools/xc: update tty detection in stdiostream_progress
> > 
> > As suggested by IanJ:
> > Check isatty only once to preserve the errno of ->progress users, and to
> > reduce the noice in strace output.
> > 
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> Thanks.  But how did you test this ?  It doesn't compile.

I noticed that compiler error but forgot to do qrefresh before sending.

> Also I think it would be better to name the struct member something
> other than "isatty" since that's also the function name.  In theory it
> should be OK but in practice I worry about compiler warnings etc.
> 
> How about "tty" ?

Will rename the member to tty and resend.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:00:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:00: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 1UAhYZ-0006PN-98; Wed, 27 Feb 2013 14:00:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen@asianux.com>) id 1UAePK-0005ok-JF
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:38:42 +0000
Received: from [85.158.139.211:19741] by server-6.bemta-5.messagelabs.com id
	7F/EF-21466-132ED215; Wed, 27 Feb 2013 10:38:41 +0000
X-Env-Sender: gang.chen@asianux.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361961516!15524070!1
X-Originating-IP: [58.214.24.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9434 invoked from network); 27 Feb 2013 10:38:40 -0000
Received: from intranet.asianux.com (HELO intranet.asianux.com) (58.214.24.6)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:38:40 -0000
Received: by intranet.asianux.com (Postfix, from userid 103)
	id 8ED26184036A; Wed, 27 Feb 2013 18:38:32 +0800 (CST)
X-Spam-Score: -100.8
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on intranet.asianux.com
X-Spam-Level: 
X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,
	RATWARE_GECKO_BUILD,USER_IN_WHITELIST autolearn=no version=3.1.9
Received: from [10.1.0.143] (unknown [219.143.36.82])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by intranet.asianux.com (Postfix) with ESMTP id DD81C1840268;
	Wed, 27 Feb 2013 18:38:31 +0800 (CST)
Message-ID: <512DE213.3050001@asianux.com>
Date: Wed, 27 Feb 2013 18:38:11 +0800
From: Chen Gang <gang.chen@asianux.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
In-Reply-To: <512DE6B302000078000C1631@nat28.tlf.novell.com>
X-Mailman-Approved-At: Wed, 27 Feb 2013 14:00:25 +0000
Cc: stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
	without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

5LqOIDIwMTPlubQwMuaciDI35pelIDE3OjU3LCBKYW4gQmV1bGljaCDlhpnpgZM6Cj4gWW91IGFs
c28gY291bGQgaGF2ZSBtZW50aW9uZWQgdGhhdCBldmVuIGJlZm9yZSBjb21taXQgCj4gMDFjNjgx
ZDRjNzBkNjRjYjcyMTQyYTI4MjNmMjdjNDE0NmEwMmU2MyB0aGUgdmFsdWUgcHJpbnRlZAo+IGhl
cmUgd2FzIGJvZ3VzLCBhcyBpdCB3YXMgdGhlIGd1ZXN0IHByb3ZpZGVkIHZhbHVlIGZyb20KPiBy
ZXEtPnUucncuaGFuZGxlIHJhdGhlciB0aGFuIHRoZSBhY3R1YWwgZGV2aWNlLgoKICBwYXJkb24g
PwoKICBJIGd1ZXNzIHdoYXQgeW91IHNhaWQgaXMgOgogICAgbXkgcGF0Y2ggc2VlbXMgb2ssIGJ1
dCB0aGUgY29tbWVudHMgbmVlZCBpbXByb3ZpbmcuCiAgICBuZWVkIGFkZCAiYWRkaXRpb25hbCBp
bmZvIiBpbiBjb21tZW50czoKICAgICAgImJlZm9yZSBjb21taXQgMDFjNjgxZDRjNzBkNjRjYjcy
MTQyYTI4MjNmMjdjNDE0NmEwMmU2MwogICAgICAgdGhlIHZhbHVlIHByaW50ZWQgaGVyZSB3YXMg
Ym9ndXMsIGFzIGl0IHdhcyB0aGUgZ3Vlc3QKICAgICAgIHByb3ZpZGVkIHZhbHVlIGZyb20gcmVx
LT51LnJ3LmhhbmRsZSByYXRoZXIgdGhhbiB0aGUKICAgICAgIGFjdHVhbCBkZXZpY2UiLgoKICBp
cyBpdCBjb3JyZWN0ID8KCiAgdGhhbmtzLgoKLS0gCkNoZW4gR2FuZwoKQXNpYW51eCBDb3Jwb3Jh
dGlvbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:00:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:00: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 1UAhYZ-0006PN-98; Wed, 27 Feb 2013 14:00:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen@asianux.com>) id 1UAePK-0005ok-JF
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 10:38:42 +0000
Received: from [85.158.139.211:19741] by server-6.bemta-5.messagelabs.com id
	7F/EF-21466-132ED215; Wed, 27 Feb 2013 10:38:41 +0000
X-Env-Sender: gang.chen@asianux.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1361961516!15524070!1
X-Originating-IP: [58.214.24.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9434 invoked from network); 27 Feb 2013 10:38:40 -0000
Received: from intranet.asianux.com (HELO intranet.asianux.com) (58.214.24.6)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 10:38:40 -0000
Received: by intranet.asianux.com (Postfix, from userid 103)
	id 8ED26184036A; Wed, 27 Feb 2013 18:38:32 +0800 (CST)
X-Spam-Score: -100.8
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on intranet.asianux.com
X-Spam-Level: 
X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,
	RATWARE_GECKO_BUILD,USER_IN_WHITELIST autolearn=no version=3.1.9
Received: from [10.1.0.143] (unknown [219.143.36.82])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by intranet.asianux.com (Postfix) with ESMTP id DD81C1840268;
	Wed, 27 Feb 2013 18:38:31 +0800 (CST)
Message-ID: <512DE213.3050001@asianux.com>
Date: Wed, 27 Feb 2013 18:38:11 +0800
From: Chen Gang <gang.chen@asianux.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
In-Reply-To: <512DE6B302000078000C1631@nat28.tlf.novell.com>
X-Mailman-Approved-At: Wed, 27 Feb 2013 14:00:25 +0000
Cc: stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
	without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

5LqOIDIwMTPlubQwMuaciDI35pelIDE3OjU3LCBKYW4gQmV1bGljaCDlhpnpgZM6Cj4gWW91IGFs
c28gY291bGQgaGF2ZSBtZW50aW9uZWQgdGhhdCBldmVuIGJlZm9yZSBjb21taXQgCj4gMDFjNjgx
ZDRjNzBkNjRjYjcyMTQyYTI4MjNmMjdjNDE0NmEwMmU2MyB0aGUgdmFsdWUgcHJpbnRlZAo+IGhl
cmUgd2FzIGJvZ3VzLCBhcyBpdCB3YXMgdGhlIGd1ZXN0IHByb3ZpZGVkIHZhbHVlIGZyb20KPiBy
ZXEtPnUucncuaGFuZGxlIHJhdGhlciB0aGFuIHRoZSBhY3R1YWwgZGV2aWNlLgoKICBwYXJkb24g
PwoKICBJIGd1ZXNzIHdoYXQgeW91IHNhaWQgaXMgOgogICAgbXkgcGF0Y2ggc2VlbXMgb2ssIGJ1
dCB0aGUgY29tbWVudHMgbmVlZCBpbXByb3ZpbmcuCiAgICBuZWVkIGFkZCAiYWRkaXRpb25hbCBp
bmZvIiBpbiBjb21tZW50czoKICAgICAgImJlZm9yZSBjb21taXQgMDFjNjgxZDRjNzBkNjRjYjcy
MTQyYTI4MjNmMjdjNDE0NmEwMmU2MwogICAgICAgdGhlIHZhbHVlIHByaW50ZWQgaGVyZSB3YXMg
Ym9ndXMsIGFzIGl0IHdhcyB0aGUgZ3Vlc3QKICAgICAgIHByb3ZpZGVkIHZhbHVlIGZyb20gcmVx
LT51LnJ3LmhhbmRsZSByYXRoZXIgdGhhbiB0aGUKICAgICAgIGFjdHVhbCBkZXZpY2UiLgoKICBp
cyBpdCBjb3JyZWN0ID8KCiAgdGhhbmtzLgoKLS0gCkNoZW4gR2FuZwoKQXNpYW51eCBDb3Jwb3Jh
dGlvbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:00:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:00: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 1UAhYZ-0006PU-MY; Wed, 27 Feb 2013 14:00:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <11221079@zju.edu.cn>) id 1UAfiU-0001zf-2b
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:02:34 +0000
Received: from [85.158.138.51:40507] by server-5.bemta-3.messagelabs.com id
	45/61-30636-9D5FD215; Wed, 27 Feb 2013 12:02:33 +0000
X-Env-Sender: 11221079@zju.edu.cn
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361966550!29518273!1
X-Originating-IP: [210.32.2.5]
X-SpamReason: No, hits=-0.3 required=7.0 tests=FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS, MIME_BASE64_TEXT, ML_RADAR_FP_R_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2704 invoked from network); 27 Feb 2013 12:02:32 -0000
Received: from mail.zju.edu.cn (HELO zju.edu.cn) (210.32.2.5)
	by server-9.tower-174.messagelabs.com with SMTP;
	27 Feb 2013 12:02:32 -0000
Received: from PC2012081418yyn (unknown [202.101.186.186])
	by mailapp1 (Coremail) with SMTP id HwbKCpDLr+7R9S1RbZUAAA--.1576S2;
	Wed, 27 Feb 2013 20:02:26 +0800 (CST)
Date: Wed, 27 Feb 2013 20:02:25 +0800
From: "butian huang" <11221079@zju.edu.cn>
To: "xen-devel" <xen-devel@lists.xen.org>
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
X-CM-TRANSID: HwbKCpDLr+7R9S1RbZUAAA--.1576S2
X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73
	VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUot7k0a2IF6FyUM7kC6x804xWl14x267AK
	xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw
	A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY
	6xkF7I0E14v26F4UJVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aV
	CY1x0267AKxVW0oVCq3wAac4AC62xK8xCEY4vEwIxC4wAS0I0E0xvYzxvE52x082IY62kv
	0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z2
	80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48I
	cxkI7VAKI48G6xCjnVAKz4kxM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2
	IqxwACY4xI67k04243AVC20s0264xvF2IEb7IF0Fy264kE64k0F2IE4x8a64kEw2IEx4CE
	17CEb7AF67AKxVWUJVWUXwACY4xI67k04243AVC20s026xCjnVAKz4kI6I8E67AF67kF1V
	AFwI0_Jr0_Jrylw4CEF2IF47xS0VAv8wCY02Avz4vE14v_Xr1l42xK82IYc2Ij64vIr41l
	x2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14
	v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IY
	x2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I
	8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAx
	ZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5UMa5UUUUU==
Message-Id: <512DF5D2.000A6A.08288@zju.edu.cn>
X-CM-SenderInfo: qrrsjiaqxzq6lmxovvfxof0/
X-Mailman-Approved-At: Wed, 27 Feb 2013 14:00:25 +0000
Subject: [Xen-devel] About the CPU QoS and memory migratio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

eGVuLWRldmVsOg0KDQpIZWxsbw0KQ2FuIHlvdSBhbnN3ZXIgbXkgZm9sbG93aW5nIHF1ZXN0aW9u
cyBpbiBkZXRhaWyjvw0KRmlyc3QsSG93IHRvIGd1YXJhbnRlZSB0aGUgQ1BVIFFvUyh0aGUgQ1BV
IFFvUyBpbmNsdWRlcyB0aGUgbGltaXQscmVzZXJ2YXRpb24gYW5kIHNoYXJlcyk/DQpTZW5jb25k
bHksSG93IHRvIHJlZHVjZSB0aGUgdGltZXMgb2YgdGhlIFZNJ3MgYWNjZXNzaW5nIHJlbW90ZSBt
ZW1vcnk/IGFuZCBob3cgdG8gbWlncmF0ZSB0aGUgbWVtb3J5IGJldHdlZW4gdGhlIG5vZGVzPw0K
DQpBbmQgY2FuIHlvdSBwcm92aWRlIHRoZSBzb3VyY2UgY29kZT8gDQoNClRoYW5rcywNClJlZ2Fy
ZHMsDQpidXRpbmUNCjIwMTMtMDItMjcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:00:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:00: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 1UAhYZ-0006PU-MY; Wed, 27 Feb 2013 14:00:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <11221079@zju.edu.cn>) id 1UAfiU-0001zf-2b
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 12:02:34 +0000
Received: from [85.158.138.51:40507] by server-5.bemta-3.messagelabs.com id
	45/61-30636-9D5FD215; Wed, 27 Feb 2013 12:02:33 +0000
X-Env-Sender: 11221079@zju.edu.cn
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361966550!29518273!1
X-Originating-IP: [210.32.2.5]
X-SpamReason: No, hits=-0.3 required=7.0 tests=FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS, MIME_BASE64_TEXT, ML_RADAR_FP_R_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2704 invoked from network); 27 Feb 2013 12:02:32 -0000
Received: from mail.zju.edu.cn (HELO zju.edu.cn) (210.32.2.5)
	by server-9.tower-174.messagelabs.com with SMTP;
	27 Feb 2013 12:02:32 -0000
Received: from PC2012081418yyn (unknown [202.101.186.186])
	by mailapp1 (Coremail) with SMTP id HwbKCpDLr+7R9S1RbZUAAA--.1576S2;
	Wed, 27 Feb 2013 20:02:26 +0800 (CST)
Date: Wed, 27 Feb 2013 20:02:25 +0800
From: "butian huang" <11221079@zju.edu.cn>
To: "xen-devel" <xen-devel@lists.xen.org>
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
X-CM-TRANSID: HwbKCpDLr+7R9S1RbZUAAA--.1576S2
X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73
	VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUot7k0a2IF6FyUM7kC6x804xWl14x267AK
	xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw
	A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY
	6xkF7I0E14v26F4UJVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aV
	CY1x0267AKxVW0oVCq3wAac4AC62xK8xCEY4vEwIxC4wAS0I0E0xvYzxvE52x082IY62kv
	0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z2
	80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48I
	cxkI7VAKI48G6xCjnVAKz4kxM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2
	IqxwACY4xI67k04243AVC20s0264xvF2IEb7IF0Fy264kE64k0F2IE4x8a64kEw2IEx4CE
	17CEb7AF67AKxVWUJVWUXwACY4xI67k04243AVC20s026xCjnVAKz4kI6I8E67AF67kF1V
	AFwI0_Jr0_Jrylw4CEF2IF47xS0VAv8wCY02Avz4vE14v_Xr1l42xK82IYc2Ij64vIr41l
	x2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14
	v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IY
	x2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I
	8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAx
	ZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5UMa5UUUUU==
Message-Id: <512DF5D2.000A6A.08288@zju.edu.cn>
X-CM-SenderInfo: qrrsjiaqxzq6lmxovvfxof0/
X-Mailman-Approved-At: Wed, 27 Feb 2013 14:00:25 +0000
Subject: [Xen-devel] About the CPU QoS and memory migratio
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

eGVuLWRldmVsOg0KDQpIZWxsbw0KQ2FuIHlvdSBhbnN3ZXIgbXkgZm9sbG93aW5nIHF1ZXN0aW9u
cyBpbiBkZXRhaWyjvw0KRmlyc3QsSG93IHRvIGd1YXJhbnRlZSB0aGUgQ1BVIFFvUyh0aGUgQ1BV
IFFvUyBpbmNsdWRlcyB0aGUgbGltaXQscmVzZXJ2YXRpb24gYW5kIHNoYXJlcyk/DQpTZW5jb25k
bHksSG93IHRvIHJlZHVjZSB0aGUgdGltZXMgb2YgdGhlIFZNJ3MgYWNjZXNzaW5nIHJlbW90ZSBt
ZW1vcnk/IGFuZCBob3cgdG8gbWlncmF0ZSB0aGUgbWVtb3J5IGJldHdlZW4gdGhlIG5vZGVzPw0K
DQpBbmQgY2FuIHlvdSBwcm92aWRlIHRoZSBzb3VyY2UgY29kZT8gDQoNClRoYW5rcywNClJlZ2Fy
ZHMsDQpidXRpbmUNCjIwMTMtMDItMjcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:12:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14: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 1UAhja-0006pZ-UN; Wed, 27 Feb 2013 14:11:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1UAhjZ-0006pU-PY
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:11:49 +0000
Received: from [85.158.143.99:58446] by server-2.bemta-4.messagelabs.com id
	29/40-12656-5241E215; Wed, 27 Feb 2013 14:11:49 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361974306!19714498!1
X-Originating-IP: [209.85.220.175]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17706 invoked from network); 27 Feb 2013 14:11:47 -0000
Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com)
	(209.85.220.175)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:11:47 -0000
Received: by mail-vc0-f175.google.com with SMTP id fw7so397375vcb.6
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=OaGSlsry/G5RRsXrew+MoLNZgKA1n9C090IAqpOaTTQ=;
	b=lbBD04XrbvmnDL46QDR9fmpky6Y8fqPOU79V5BDmINxlRiqrHVuZQ3aWXItn0oUZZ6
	hv1QZEvPogfu98wt73gxVGYLsexOIdCAJchYzAp7XNdb4oDKkbI/SiKRVx8bAw1AaKcI
	KIlJSAklxDw9iLtc5PUHa7len0Aea/+Kk/Qxub/7qkyXf8ofEx6AGTAd+tLlC5FCeLVp
	Ev+EHwxRZ90lguF1atGiRaqCX+9gSnFh70MIfkWyvSif6maaUQnQBDolGntuSYgn0Nk1
	moAJiyNbA6+0xrQB/MgKfn/5tjTJ/SgR6+oh40fmtOQNALg+Z7REi4Mxe598zrjy8PcB
	wHiw==
X-Received: by 10.220.154.14 with SMTP id m14mr916007vcw.21.1361974305923;
	Wed, 27 Feb 2013 06:11:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.33.16 with HTTP; Wed, 27 Feb 2013 06:11:25 -0800 (PST)
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Wed, 27 Feb 2013 15:11:25 +0100
Message-ID: <CAJ75kXZKKPcaa_xSg-y8Gj+NaWEcZOf=dLOpLELVRyFgBwRvJw@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 13, 2013 at 6:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> The new git tree will be this one:
>   http://xenbits.xen.org/gitweb/?p=xen.git
>   git://xenbits.xen.org/xen.git

Is there a http access to clone the tree? (mostly to be able to
checkout the code behind a http proxy)

Thanks,

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:12:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14: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 1UAhja-0006pZ-UN; Wed, 27 Feb 2013 14:11:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1UAhjZ-0006pU-PY
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:11:49 +0000
Received: from [85.158.143.99:58446] by server-2.bemta-4.messagelabs.com id
	29/40-12656-5241E215; Wed, 27 Feb 2013 14:11:49 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361974306!19714498!1
X-Originating-IP: [209.85.220.175]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17706 invoked from network); 27 Feb 2013 14:11:47 -0000
Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com)
	(209.85.220.175)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:11:47 -0000
Received: by mail-vc0-f175.google.com with SMTP id fw7so397375vcb.6
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:11:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=OaGSlsry/G5RRsXrew+MoLNZgKA1n9C090IAqpOaTTQ=;
	b=lbBD04XrbvmnDL46QDR9fmpky6Y8fqPOU79V5BDmINxlRiqrHVuZQ3aWXItn0oUZZ6
	hv1QZEvPogfu98wt73gxVGYLsexOIdCAJchYzAp7XNdb4oDKkbI/SiKRVx8bAw1AaKcI
	KIlJSAklxDw9iLtc5PUHa7len0Aea/+Kk/Qxub/7qkyXf8ofEx6AGTAd+tLlC5FCeLVp
	Ev+EHwxRZ90lguF1atGiRaqCX+9gSnFh70MIfkWyvSif6maaUQnQBDolGntuSYgn0Nk1
	moAJiyNbA6+0xrQB/MgKfn/5tjTJ/SgR6+oh40fmtOQNALg+Z7REi4Mxe598zrjy8PcB
	wHiw==
X-Received: by 10.220.154.14 with SMTP id m14mr916007vcw.21.1361974305923;
	Wed, 27 Feb 2013 06:11:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.33.16 with HTTP; Wed, 27 Feb 2013 06:11:25 -0800 (PST)
In-Reply-To: <20763.51353.91324.851766@mariner.uk.xensource.com>
References: <20763.51353.91324.851766@mariner.uk.xensource.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Wed, 27 Feb 2013 15:11:25 +0100
Message-ID: <CAJ75kXZKKPcaa_xSg-y8Gj+NaWEcZOf=dLOpLELVRyFgBwRvJw@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Moving xen*.hg to git
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 13, 2013 at 6:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> The new git tree will be this one:
>   http://xenbits.xen.org/gitweb/?p=xen.git
>   git://xenbits.xen.org/xen.git

Is there a http access to clone the tree? (mostly to be able to
checkout the code behind a http proxy)

Thanks,

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:16:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:16: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 1UAhoG-0006y1-Rf; Wed, 27 Feb 2013 14:16:40 +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 1UAhoF-0006xw-D9
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:16:39 +0000
Received: from [85.158.143.99:36124] by server-3.bemta-4.messagelabs.com id
	95/49-02186-6451E215; Wed, 27 Feb 2013 14:16:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361974595!29519343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4539 invoked from network); 27 Feb 2013 14:16:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:16:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9986156"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:16:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:16:34 -0500
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 1UAhoA-0002Wd-A6;
	Wed, 27 Feb 2013 14:16:34 +0000
Message-ID: <512E136C.6060909@eu.citrix.com>
Date: Wed, 27 Feb 2013 14:08:44 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
	<512DE2AF02000078000C15F0@nat28.tlf.novell.com>
	<CAFLBxZZBQvknu+Mfqz02d5ZeazVDUpVqDCP52CHr1nHR14tdQw@mail.gmail.com>
	<CAFLBxZa7xih+VMfso8JXGXyZWChTOT=E5=6Zna7pwoPYAFkiEw@mail.gmail.com>
	<512E0EC702000078000C17F4@nat28.tlf.novell.com>
In-Reply-To: <512E0EC702000078000C17F4@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/02/13 12:48, Jan Beulich wrote:
>>>> On 27.02.13 at 13:31, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> On Wed, Feb 27, 2013 at 11:35 AM, George Dunlap <George.Dunlap@eu.citrix.com
>>> wrote:
>>> On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>
>>>>>>> On 26.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com>
>>>> wrote:
>>>>> @@ -271,16 +272,24 @@ struct csched_dom {
>>>>>
>>>>>   /*
>>>>>    * Time-to-credit, credit-to-time.
>>>>> + *
>>>>> + * We keep track of the "residual" time to make sure that frequent
>>>> short
>>>>> + * schedules still get accounted for in the end.
>>>>> + *
>>>>>    * FIXME: Do pre-calculated division?
>>>>>    */
>>>>> -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
>>>> struct csched_vcpu *svc)
>>>>> +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
>>>>> +                          struct csched_vcpu *svc)
>>>>>   {
>>>>> -    return time * rqd->max_weight / svc->weight;
>>>>> +    uint64_t val = time * rqd->max_weight + svc->residual;
>>>>> +
>>>>> +    svc->residual = do_div(val, svc->weight);
>>>>> +    svc->credit -= val;
>>>>>   }
>>>>>
>>>>>   static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
>>>> struct csched_vcpu *svc)
>>>>>   {
>>>>> -    return credit * svc->weight / rqd->max_weight;
>>>>> +    return (credit * svc->weight) / rqd->max_weight;
>>>> So you dropped the subtraction of svc->residual here - why?
>>>>
>>>> And if indeed intended, the insertion of parentheses here could be
>>>> dropped?
>>>>
>>> Well for one I think the equation was wrong -- the residual is units of
>>> "time", so you should have subtracted the residual after dividing by
>>> max_weight.  (From a mathematical perspective, svc->weight /
>>> rqd->max_weight is the ratio that changes units of "credit" into units of
>>> "time; if we were using floating point ops I might put parentheses around
>>> that ratio to make it more clear that's what's going on.)
>>>
>>
>> Hmm, on further investigation, I think I've convinced myself that this
>> reasoning is wrong, and your original equation was correct.
>>
>> However, the difference will only ever end up to be one nanosecond, which
>> (if used) will be subtracted from the credit after the reset; so I think we
>> might as well do without the subtraction here.
> Oh, I didn't realize this would only be a nanosecond - my
> understanding was that it would be up to (but not including) a
> credit unit.

The "residual" will always be less than the svc->weight, which will 
always be less than or equal to rqd->max_weight.  So adding it in to the 
equation before dividing by rqd->max_weight can at most increase the 
result by 1.

Empiraclly, I've been playing around with values in a spreadsheet to 
make sure the logic was behaving as one would expect, and the difference 
between the calculation of c2t with and without the residual was never 
more than 1.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:16:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:16: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 1UAhoG-0006y1-Rf; Wed, 27 Feb 2013 14:16:40 +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 1UAhoF-0006xw-D9
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:16:39 +0000
Received: from [85.158.143.99:36124] by server-3.bemta-4.messagelabs.com id
	95/49-02186-6451E215; Wed, 27 Feb 2013 14:16:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361974595!29519343!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4539 invoked from network); 27 Feb 2013 14:16:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:16:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9986156"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:16:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:16:34 -0500
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 1UAhoA-0002Wd-A6;
	Wed, 27 Feb 2013 14:16:34 +0000
Message-ID: <512E136C.6060909@eu.citrix.com>
Date: Wed, 27 Feb 2013 14:08:44 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1361898497-5719-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361898497-5719-2-git-send-email-george.dunlap@eu.citrix.com>
	<512DE2AF02000078000C15F0@nat28.tlf.novell.com>
	<CAFLBxZZBQvknu+Mfqz02d5ZeazVDUpVqDCP52CHr1nHR14tdQw@mail.gmail.com>
	<CAFLBxZa7xih+VMfso8JXGXyZWChTOT=E5=6Zna7pwoPYAFkiEw@mail.gmail.com>
	<512E0EC702000078000C17F4@nat28.tlf.novell.com>
In-Reply-To: <512E0EC702000078000C17F4@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/02/13 12:48, Jan Beulich wrote:
>>>> On 27.02.13 at 13:31, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> On Wed, Feb 27, 2013 at 11:35 AM, George Dunlap <George.Dunlap@eu.citrix.com
>>> wrote:
>>> On Wed, Feb 27, 2013 at 9:40 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>
>>>>>>> On 26.02.13 at 18:08, George Dunlap <george.dunlap@eu.citrix.com>
>>>> wrote:
>>>>> @@ -271,16 +272,24 @@ struct csched_dom {
>>>>>
>>>>>   /*
>>>>>    * Time-to-credit, credit-to-time.
>>>>> + *
>>>>> + * We keep track of the "residual" time to make sure that frequent
>>>> short
>>>>> + * schedules still get accounted for in the end.
>>>>> + *
>>>>>    * FIXME: Do pre-calculated division?
>>>>>    */
>>>>> -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
>>>> struct csched_vcpu *svc)
>>>>> +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
>>>>> +                          struct csched_vcpu *svc)
>>>>>   {
>>>>> -    return time * rqd->max_weight / svc->weight;
>>>>> +    uint64_t val = time * rqd->max_weight + svc->residual;
>>>>> +
>>>>> +    svc->residual = do_div(val, svc->weight);
>>>>> +    svc->credit -= val;
>>>>>   }
>>>>>
>>>>>   static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
>>>> struct csched_vcpu *svc)
>>>>>   {
>>>>> -    return credit * svc->weight / rqd->max_weight;
>>>>> +    return (credit * svc->weight) / rqd->max_weight;
>>>> So you dropped the subtraction of svc->residual here - why?
>>>>
>>>> And if indeed intended, the insertion of parentheses here could be
>>>> dropped?
>>>>
>>> Well for one I think the equation was wrong -- the residual is units of
>>> "time", so you should have subtracted the residual after dividing by
>>> max_weight.  (From a mathematical perspective, svc->weight /
>>> rqd->max_weight is the ratio that changes units of "credit" into units of
>>> "time; if we were using floating point ops I might put parentheses around
>>> that ratio to make it more clear that's what's going on.)
>>>
>>
>> Hmm, on further investigation, I think I've convinced myself that this
>> reasoning is wrong, and your original equation was correct.
>>
>> However, the difference will only ever end up to be one nanosecond, which
>> (if used) will be subtracted from the credit after the reset; so I think we
>> might as well do without the subtraction here.
> Oh, I didn't realize this would only be a nanosecond - my
> understanding was that it would be up to (but not including) a
> credit unit.

The "residual" will always be less than the svc->weight, which will 
always be less than or equal to rqd->max_weight.  So adding it in to the 
equation before dividing by rqd->max_weight can at most increase the 
result by 1.

Empiraclly, I've been playing around with values in a spreadsheet to 
make sure the logic was behaving as one would expect, and the difference 
between the calculation of c2t with and without the residual was never 
more than 1.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:17:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:17: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 1UAhoV-0006yv-8H; Wed, 27 Feb 2013 14:16:55 +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 1UAhoT-0006yh-AU
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:16:53 +0000
Received: from [85.158.143.99:37182] by server-3.bemta-4.messagelabs.com id
	2B/79-02186-4551E215; Wed, 27 Feb 2013 14:16:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361974597!29450990!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTYzMjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTYzMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9835 invoked from network); 27 Feb 2013 14:16:38 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 14:16:38 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDWwcZZyw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-072-069.pools.arcor-ip.net [84.57.72.69])
	by smtp.strato.de (jorabe mo41) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i047c3p1RDHQs7 ;
	Wed, 27 Feb 2013 15:16:37 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 159301863F;
	Wed, 27 Feb 2013 15:16:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c438c98e13163cdb3106917469e3b86226f96168
Message-Id: <c438c98e13163cdb3106.1361974596@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 27 Feb 2013 15:16:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] tools/xc: update tty detection in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1361974429 -3600
# Node ID c438c98e13163cdb3106917469e3b86226f96168
# Parent  dc086ced6b0c7ecf21e56155f42fb16dabe39097
tools/xc: update tty detection in stdiostream_progress

As suggested by IanJ:
Check isatty only once to preserve the errno of ->progress users, and to
reduce the noice in strace output.

v2:
 - fix compile error
 - rename ->isatty to ->tty

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dc086ced6b0c -r c438c98e1316 tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -35,6 +35,7 @@ struct xentoollog_logger_stdiostream {
     xentoollog_level min_level;
     unsigned flags;
     int progress_erase_len, progress_last_percent;
+    int tty;
 };
 
 static void progress_erase(xentoollog_logger_stdiostream *lg) {
@@ -118,7 +119,7 @@ static void stdiostream_progress(struct 
 
     lg->progress_last_percent = percent;
 
-    if (isatty(fileno(lg->f)) <= 0) {
+    if (!lg->tty) {
         stdiostream_message(logger_in, this_level, context,
                             "%s: %lu/%lu  %3d%%",
                             doing_what, done, total, percent);
@@ -166,6 +167,7 @@ xentoollog_logger_stdiostream *xtl_creat
     newlogger.f = f;
     newlogger.min_level = min_level;
     newlogger.flags = flags;
+    newlogger.tty = isatty(fileno(newlogger.f)) > 0;
 
     if (newlogger.flags & XTL_STDIOSTREAM_SHOW_DATE) tzset();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:17:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:17: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 1UAhoV-0006yv-8H; Wed, 27 Feb 2013 14:16:55 +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 1UAhoT-0006yh-AU
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:16:53 +0000
Received: from [85.158.143.99:37182] by server-3.bemta-4.messagelabs.com id
	2B/79-02186-4551E215; Wed, 27 Feb 2013 14:16:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1361974597!29450990!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTYzMjM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA1NTYzMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9835 invoked from network); 27 Feb 2013 14:16:38 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 14:16:38 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJ8KkvZ5rDWwcZZyw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-072-069.pools.arcor-ip.net [84.57.72.69])
	by smtp.strato.de (jorabe mo41) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i047c3p1RDHQs7 ;
	Wed, 27 Feb 2013 15:16:37 +0100 (CET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 159301863F;
	Wed, 27 Feb 2013 15:16:37 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c438c98e13163cdb3106917469e3b86226f96168
Message-Id: <c438c98e13163cdb3106.1361974596@probook.site>
User-Agent: Mercurial-patchbomb/2.5.1
Date: Wed, 27 Feb 2013 15:16:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] tools/xc: update tty detection in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1361974429 -3600
# Node ID c438c98e13163cdb3106917469e3b86226f96168
# Parent  dc086ced6b0c7ecf21e56155f42fb16dabe39097
tools/xc: update tty detection in stdiostream_progress

As suggested by IanJ:
Check isatty only once to preserve the errno of ->progress users, and to
reduce the noice in strace output.

v2:
 - fix compile error
 - rename ->isatty to ->tty

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dc086ced6b0c -r c438c98e1316 tools/libxc/xtl_logger_stdio.c
--- a/tools/libxc/xtl_logger_stdio.c
+++ b/tools/libxc/xtl_logger_stdio.c
@@ -35,6 +35,7 @@ struct xentoollog_logger_stdiostream {
     xentoollog_level min_level;
     unsigned flags;
     int progress_erase_len, progress_last_percent;
+    int tty;
 };
 
 static void progress_erase(xentoollog_logger_stdiostream *lg) {
@@ -118,7 +119,7 @@ static void stdiostream_progress(struct 
 
     lg->progress_last_percent = percent;
 
-    if (isatty(fileno(lg->f)) <= 0) {
+    if (!lg->tty) {
         stdiostream_message(logger_in, this_level, context,
                             "%s: %lu/%lu  %3d%%",
                             doing_what, done, total, percent);
@@ -166,6 +167,7 @@ xentoollog_logger_stdiostream *xtl_creat
     newlogger.f = f;
     newlogger.min_level = min_level;
     newlogger.flags = flags;
+    newlogger.tty = isatty(fileno(newlogger.f)) > 0;
 
     if (newlogger.flags & XTL_STDIOSTREAM_SHOW_DATE) tzset();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:19:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:19: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 1UAhqO-0007Cu-53; Wed, 27 Feb 2013 14:18: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 1UAhqL-0007CP-Nu
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:18:49 +0000
Received: from [85.158.143.99:21835] by server-3.bemta-4.messagelabs.com id
	D8/1C-02186-8C51E215; Wed, 27 Feb 2013 14:18:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361974724!19716238!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29874 invoked from network); 27 Feb 2013 14:18:47 -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;
	27 Feb 2013 14:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9495576"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:18:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:18:43 -0500
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 1UAhqF-0002Yt-8t;
	Wed, 27 Feb 2013 14:18:43 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:10:43 +0000
Message-ID: <1361974243-12446-2-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Don't bother subtracting the residual from the runtime, as it can only ever
add up to one nanosecond, and will end up being debited during the next
reset interval anyway.

Original-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 804049e..eb544db 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
 
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue */
-    int max_weight;
+    unsigned int max_weight;
 
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
 
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
 
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -271,14 +272,22 @@ struct csched_dom {
 
 /*
  * Time-to-credit, credit-to-time.
+ * 
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
+                          struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val = time * rqd->max_weight + svc->residual;
+
+    svc->residual = do_div(val, svc->weight);
+    svc->credit -= val;
 }
 
-static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
+static s_time_t c2t_adjusted(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
 {
     return credit * svc->weight / rqd->max_weight;
 }
@@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t
     delta = now - svc->start_time;
 
     if ( delta > 0 ) {
-        /* This will round down; should we consider rounding up...? */
-        svc->credit -= t2c(rqd, delta, svc);
+        t2c_update(rqd, delta, svc);
         svc->start_time = now;
 
         d2printk("b d%dv%d c%d\n",
-- 
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 Wed Feb 27 14:19:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:19: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 1UAhqO-0007Cu-53; Wed, 27 Feb 2013 14:18: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 1UAhqL-0007CP-Nu
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:18:49 +0000
Received: from [85.158.143.99:21835] by server-3.bemta-4.messagelabs.com id
	D8/1C-02186-8C51E215; Wed, 27 Feb 2013 14:18:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361974724!19716238!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29874 invoked from network); 27 Feb 2013 14:18:47 -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;
	27 Feb 2013 14:18:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9495576"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:18:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:18:43 -0500
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 1UAhqF-0002Yt-8t;
	Wed, 27 Feb 2013 14:18:43 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:10:43 +0000
Message-ID: <1361974243-12446-2-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Don't bother subtracting the residual from the runtime, as it can only ever
add up to one nanosecond, and will end up being debited during the next
reset interval anyway.

Original-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 804049e..eb544db 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
 
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue */
-    int max_weight;
+    unsigned int max_weight;
 
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
 
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
 
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -271,14 +272,22 @@ struct csched_dom {
 
 /*
  * Time-to-credit, credit-to-time.
+ * 
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
+                          struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val = time * rqd->max_weight + svc->residual;
+
+    svc->residual = do_div(val, svc->weight);
+    svc->credit -= val;
 }
 
-static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
+static s_time_t c2t_adjusted(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
 {
     return credit * svc->weight / rqd->max_weight;
 }
@@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t
     delta = now - svc->start_time;
 
     if ( delta > 0 ) {
-        /* This will round down; should we consider rounding up...? */
-        svc->credit -= t2c(rqd, delta, svc);
+        t2c_update(rqd, delta, svc);
         svc->start_time = now;
 
         d2printk("b d%dv%d c%d\n",
-- 
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 Wed Feb 27 14:19:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:19: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 1UAhqN-0007Ck-P4; Wed, 27 Feb 2013 14:18:51 +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 1UAhqL-0007CM-F1
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:18:49 +0000
Received: from [85.158.143.99:53257] by server-2.bemta-4.messagelabs.com id
	41/88-12656-7C51E215; Wed, 27 Feb 2013 14:18:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361974724!19716238!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29763 invoked from network); 27 Feb 2013 14:18:45 -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;
	27 Feb 2013 14:18:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9495575"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:18:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:18:43 -0500
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 1UAhqF-0002Yt-7C;
	Wed, 27 Feb 2013 14:18:43 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:10:42 +0000
Message-ID: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/2] xen,
	credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v3:
 - ASSERT that rt_credt >= 0, since there's a possibility for credits
   to be equal
v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b0af010..804049e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 static s_time_t
 csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
+    s_time_t time; 
+    int rt_credit; /* Proposed runtime measured in credits */
     struct csched_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
         return CSCHED_MAX_TIMER;
 
-    /* Basic time */
-    time = c2t(rqd, snext->credit, snext);
+    /* General algorithm:
+     * 1) Run until snext's credit will be 0
+     * 2) But if someone is waiting, run until snext's credit is equal
+     * to his
+     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
+     */
+
+    /* 1) Basic time: Run until credit is 0. */
+    rt_credit = snext->credit;
 
-    /* Next guy on runqueue */
+    /* 2) If there's someone waiting whose credit is positive,
+     * run until your credit ~= his */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
-        s_time_t ntime;
+        struct csched_vcpu *swait = __runq_elem(runq->next);
 
-        if ( ! is_idle_vcpu(svc->vcpu) )
+        if ( ! is_idle_vcpu(swait->vcpu)
+             && swait->credit > 0 )
         {
-            ntime = c2t(rqd, snext->credit - svc->credit, snext);
-
-            if ( time > ntime )
-                time = ntime;
+            rt_credit = snext->credit - swait->credit;
         }
     }
 
+    /*
+     * snext is about to be scheduled; so:
+     *
+     * 1. if snext->credit were less than 0 when it was taken off the
+     * runqueue, then csched_schedule() should have called
+     * reset_credit().  So at this point snext->credit must be greater
+     * than 0.
+     *
+     * 2. snext's credit must be greater than or equal to anyone else
+     * in the queue, so snext->credit - swait->credit must be greater
+     * than or equal to 0.
+     */
+    ASSERT(rt_credit >= 0);
+
+    /* FIXME: See if we can eliminate this conversion if we know time
+     * will be outside (MIN,MAX).  Probably requires pre-calculating
+     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
+     * at a different rate. */
+    time = c2t(rqd, rt_credit, snext);
+
     /* Check limits */
     if ( time < CSCHED_MIN_TIMER )
         time = CSCHED_MIN_TIMER;
-- 
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 Wed Feb 27 14:19:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:19: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 1UAhqN-0007Ck-P4; Wed, 27 Feb 2013 14:18:51 +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 1UAhqL-0007CM-F1
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:18:49 +0000
Received: from [85.158.143.99:53257] by server-2.bemta-4.messagelabs.com id
	41/88-12656-7C51E215; Wed, 27 Feb 2013 14:18:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361974724!19716238!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29763 invoked from network); 27 Feb 2013 14:18:45 -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;
	27 Feb 2013 14:18:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9495575"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:18:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:18:43 -0500
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 1UAhqF-0002Yt-7C;
	Wed, 27 Feb 2013 14:18:43 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:10:42 +0000
Message-ID: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/2] xen,
	credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v3:
 - ASSERT that rt_credt >= 0, since there's a possibility for credits
   to be equal
v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b0af010..804049e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 static s_time_t
 csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
+    s_time_t time; 
+    int rt_credit; /* Proposed runtime measured in credits */
     struct csched_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
         return CSCHED_MAX_TIMER;
 
-    /* Basic time */
-    time = c2t(rqd, snext->credit, snext);
+    /* General algorithm:
+     * 1) Run until snext's credit will be 0
+     * 2) But if someone is waiting, run until snext's credit is equal
+     * to his
+     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
+     */
+
+    /* 1) Basic time: Run until credit is 0. */
+    rt_credit = snext->credit;
 
-    /* Next guy on runqueue */
+    /* 2) If there's someone waiting whose credit is positive,
+     * run until your credit ~= his */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
-        s_time_t ntime;
+        struct csched_vcpu *swait = __runq_elem(runq->next);
 
-        if ( ! is_idle_vcpu(svc->vcpu) )
+        if ( ! is_idle_vcpu(swait->vcpu)
+             && swait->credit > 0 )
         {
-            ntime = c2t(rqd, snext->credit - svc->credit, snext);
-
-            if ( time > ntime )
-                time = ntime;
+            rt_credit = snext->credit - swait->credit;
         }
     }
 
+    /*
+     * snext is about to be scheduled; so:
+     *
+     * 1. if snext->credit were less than 0 when it was taken off the
+     * runqueue, then csched_schedule() should have called
+     * reset_credit().  So at this point snext->credit must be greater
+     * than 0.
+     *
+     * 2. snext's credit must be greater than or equal to anyone else
+     * in the queue, so snext->credit - swait->credit must be greater
+     * than or equal to 0.
+     */
+    ASSERT(rt_credit >= 0);
+
+    /* FIXME: See if we can eliminate this conversion if we know time
+     * will be outside (MIN,MAX).  Probably requires pre-calculating
+     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
+     * at a different rate. */
+    time = c2t(rqd, rt_credit, snext);
+
     /* Check limits */
     if ( time < CSCHED_MIN_TIMER )
         time = CSCHED_MIN_TIMER;
-- 
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 Wed Feb 27 14:28:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:28: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 1UAhzm-0007iU-D6; Wed, 27 Feb 2013 14:28: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 1UAhzl-0007iP-36
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:28:33 +0000
Received: from [85.158.143.99:26645] by server-2.bemta-4.messagelabs.com id
	2C/F3-12656-0181E215; Wed, 27 Feb 2013 14:28:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361975311!26148773!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31728 invoked from network); 27 Feb 2013 14:28:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1958401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 14:28: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.297.1;
	Wed, 27 Feb 2013 14:28:31 +0000
Message-ID: <1361975302.26546.384.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Wed, 27 Feb 2013 14:28:22 +0000
In-Reply-To: <20130227124443.GA5582@waldi.eu.org>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
	<20130226223249.GD27098@waldi.eu.org>
	<1361967427.26546.368.camel@zakaz.uk.xensource.com>
	<20130227124443.GA5582@waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 12:44 +0000, Bastian Blank wrote:

> > I'm not sure "trusted" is quite the right term though, these aren't
> > really any more trustworthy than the library supplied ones -- they are
> > just more suitable for a mini-os environment.
> 
> I used the term "trusted" because it should not be fed with untrusted
> input. So it should not be used in the normal libxenguest. In the case
> of pv-grub, all input is trusted as it runs in the same security domain.

That makes sense.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:28:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:28: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 1UAhzm-0007iU-D6; Wed, 27 Feb 2013 14:28: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 1UAhzl-0007iP-36
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:28:33 +0000
Received: from [85.158.143.99:26645] by server-2.bemta-4.messagelabs.com id
	2C/F3-12656-0181E215; Wed, 27 Feb 2013 14:28:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361975311!26148773!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31728 invoked from network); 27 Feb 2013 14:28:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1958401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 14:28: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.297.1;
	Wed, 27 Feb 2013 14:28:31 +0000
Message-ID: <1361975302.26546.384.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Wed, 27 Feb 2013 14:28:22 +0000
In-Reply-To: <20130227124443.GA5582@waldi.eu.org>
References: <1357300593-28685-1-git-send-email-ian.campbell@citrix.com>
	<20130104123307.GA1202@waldi.eu.org>
	<1357303220.14291.11.camel@zakaz.uk.xensource.com>
	<20130226222502.GB27098@waldi.eu.org>
	<20130226223249.GD27098@waldi.eu.org>
	<1361967427.26546.368.camel@zakaz.uk.xensource.com>
	<20130227124443.GA5582@waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC] libxc: Add trusted decompressors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 12:44 +0000, Bastian Blank wrote:

> > I'm not sure "trusted" is quite the right term though, these aren't
> > really any more trustworthy than the library supplied ones -- they are
> > just more suitable for a mini-os environment.
> 
> I used the term "trusted" because it should not be fed with untrusted
> input. So it should not be used in the normal libxenguest. In the case
> of pv-grub, all input is trusted as it runs in the same security domain.

That makes sense.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:34:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14: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 1UAi5G-0007ve-6T; Wed, 27 Feb 2013 14:34:14 +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 1UAi5F-0007vX-Ac
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:34:13 +0000
Received: from [193.109.254.147:36360] by server-6.bemta-14.messagelabs.com id
	E0/C2-12010-4691E215; Wed, 27 Feb 2013 14:34:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361975429!9516468!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20600 invoked from network); 27 Feb 2013 14:30:30 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:30:30 -0000
Received: by mail-wg0-f43.google.com with SMTP id e12so496509wge.34
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:30:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=fb3PWtWtaGt2QW20VbCoYhXTRSB9/pYcwsKC/fE44Bk=;
	b=IW/hUzCk+vFXSN4JVNi8HrobPtFboScStkybapsPgcPi1pmgy/D2jsOOyXN7GF+iJV
	OB4yMkY7H+E1/OoFuil9K0of/ugO1ckufos7HgqMYfbhM1/pka/Y1YF+z99aIMHnL8E2
	b/83b4eQuaWFiRJolzU5k0pgQ8Hl0HZqFsYZdfIQIIiJnA9VSs2GnXtRe3RvTPC9/VoJ
	USmUizgM//s0fORg3oj52ns7r6pa/AUum75hljFd9oYRi/82C+fnkjWishfGdOYcU5zF
	KVTGeLvz91QtlCeDVX0tAMG0dW1IhevzYEFlNJ5JoDJ6DTpjw0T8Cz2g45JMNYlArIH2
	7a0g==
MIME-Version: 1.0
X-Received: by 10.180.108.229 with SMTP id hn5mr26790859wib.28.1361975429584; 
	Wed, 27 Feb 2013 06:30:29 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 06:30:29 -0800 (PST)
In-Reply-To: <1361974243-12446-2-git-send-email-george.dunlap@eu.citrix.com>
References: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361974243-12446-2-git-send-email-george.dunlap@eu.citrix.com>
Date: Wed, 27 Feb 2013 14:30:29 +0000
X-Google-Sender-Auth: NgkFWoJC5BvdvnKEc-_qfEzWiaI
Message-ID: <CAFLBxZa9oYb3EZoCvwP5zb-G4L9DzaM_-xCTVgqOtT1mtB6ZMQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5469165089337171075=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5469165089337171075==
Content-Type: multipart/alternative; boundary=e89a8f3b9d9fac5fb104d6b59d93

--e89a8f3b9d9fac5fb104d6b59d93
Content-Type: text/plain; charset=ISO-8859-1

Gah, sorry -- ignore this one...


On Wed, Feb 27, 2013 at 2:10 PM, George Dunlap
<george.dunlap@eu.citrix.com>wrote:

> This should help with under-accounting of vCPU-s running for extremly
> short periods of time, but becoming runnable again at a high frequency.
>
> Don't bother subtracting the residual from the runtime, as it can only ever
> add up to one nanosecond, and will end up being debited during the next
> reset interval anyway.
>
> Original-patch-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  xen/common/sched_credit2.c |   24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 804049e..eb544db 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -21,7 +21,7 @@
>  #include <xen/perfc.h>
>  #include <xen/sched-if.h>
>  #include <xen/softirq.h>
> -#include <asm/atomic.h>
> +#include <asm/div64.h>
>  #include <xen/errno.h>
>  #include <xen/trace.h>
>  #include <xen/cpu.h>
> @@ -205,7 +205,7 @@ struct csched_runqueue_data {
>
>      struct list_head runq; /* Ordered list of runnable vms */
>      struct list_head svc;  /* List of all vcpus assigned to this runqueue
> */
> -    int max_weight;
> +    unsigned int max_weight;
>
>      cpumask_t idle,        /* Currently idle */
>          tickled;           /* Another cpu in the queue is already
> targeted for this one */
> @@ -244,7 +244,8 @@ struct csched_vcpu {
>      struct csched_dom *sdom;
>      struct vcpu *vcpu;
>
> -    int weight;
> +    unsigned int weight;
> +    unsigned int residual;
>
>      int credit;
>      s_time_t start_time; /* When we were scheduled (used for credit) */
> @@ -271,14 +272,22 @@ struct csched_dom {
>
>  /*
>   * Time-to-credit, credit-to-time.
> + *
> + * We keep track of the "residual" time to make sure that frequent short
> + * schedules still get accounted for in the end.
> + *
>   * FIXME: Do pre-calculated division?
>   */
> -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
> struct csched_vcpu *svc)
> +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
> +                          struct csched_vcpu *svc)
>  {
> -    return time * rqd->max_weight / svc->weight;
> +    uint64_t val = time * rqd->max_weight + svc->residual;
> +
> +    svc->residual = do_div(val, svc->weight);
> +    svc->credit -= val;
>  }
>
> -static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
> struct csched_vcpu *svc)
> +static s_time_t c2t_adjusted(struct csched_runqueue_data *rqd, s_time_t
> credit, struct csched_vcpu *svc)
>  {
>      return credit * svc->weight / rqd->max_weight;
>  }
> @@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd,
> struct csched_vcpu *svc, s_t
>      delta = now - svc->start_time;
>
>      if ( delta > 0 ) {
> -        /* This will round down; should we consider rounding up...? */
> -        svc->credit -= t2c(rqd, delta, svc);
> +        t2c_update(rqd, delta, svc);
>          svc->start_time = now;
>
>          d2printk("b d%dv%d c%d\n",
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--e89a8f3b9d9fac5fb104d6b59d93
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Gah, sorry -- ignore this one...<br></div><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Wed, Feb 27, 2013 at 2:10 =
PM, George Dunlap <span dir=3D"ltr">&lt;<a href=3D"mailto:george.dunlap@eu.=
citrix.com" target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span> wr=
ote:<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">This should help with unde=
r-accounting of vCPU-s running for extremly<br>
short periods of time, but becoming runnable again at a high frequency.<br>
<br>
</div>Don&#39;t bother subtracting the residual from the runtime, as it can=
 only ever<br>
add up to one nanosecond, and will end up being debited during the next<br>
reset interval anyway.<br>
<div class=3D"im"><br>
Original-patch-by: Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.com">jbe=
ulich@suse.com</a>&gt;<br>
Signed-off-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.=
com">george.dunlap@eu.citrix.com</a>&gt;<br>
---<br>
=A0xen/common/sched_credit2.c | =A0 24 ++++++++++++++++--------<br>
=A01 file changed, 16 insertions(+), 8 deletions(-)<br>
<br>
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c<br>
</div>index 804049e..eb544db 100644<br>
<div><div class=3D"h5">--- a/xen/common/sched_credit2.c<br>
+++ b/xen/common/sched_credit2.c<br>
@@ -21,7 +21,7 @@<br>
=A0#include &lt;xen/perfc.h&gt;<br>
=A0#include &lt;xen/sched-if.h&gt;<br>
=A0#include &lt;xen/softirq.h&gt;<br>
-#include &lt;asm/atomic.h&gt;<br>
+#include &lt;asm/div64.h&gt;<br>
=A0#include &lt;xen/errno.h&gt;<br>
=A0#include &lt;xen/trace.h&gt;<br>
=A0#include &lt;xen/cpu.h&gt;<br>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {<br>
<br>
=A0 =A0 =A0struct list_head runq; /* Ordered list of runnable vms */<br>
=A0 =A0 =A0struct list_head svc; =A0/* List of all vcpus assigned to this r=
unqueue */<br>
- =A0 =A0int max_weight;<br>
+ =A0 =A0unsigned int max_weight;<br>
<br>
=A0 =A0 =A0cpumask_t idle, =A0 =A0 =A0 =A0/* Currently idle */<br>
=A0 =A0 =A0 =A0 =A0tickled; =A0 =A0 =A0 =A0 =A0 /* Another cpu in the queue=
 is already targeted for this one */<br>
@@ -244,7 +244,8 @@ struct csched_vcpu {<br>
=A0 =A0 =A0struct csched_dom *sdom;<br>
=A0 =A0 =A0struct vcpu *vcpu;<br>
<br>
- =A0 =A0int weight;<br>
+ =A0 =A0unsigned int weight;<br>
+ =A0 =A0unsigned int residual;<br>
<br>
=A0 =A0 =A0int credit;<br>
=A0 =A0 =A0s_time_t start_time; /* When we were scheduled (used for credit)=
 */<br>
</div></div>@@ -271,14 +272,22 @@ struct csched_dom {<br>
<div class=3D"im"><br>
=A0/*<br>
=A0 * Time-to-credit, credit-to-time.<br>
+ *<br>
+ * We keep track of the &quot;residual&quot; time to make sure that freque=
nt short<br>
+ * schedules still get accounted for in the end.<br>
+ *<br>
=A0 * FIXME: Do pre-calculated division?<br>
=A0 */<br>
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struc=
t csched_vcpu *svc)<br>
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct csched_vcpu *sv=
c)<br>
=A0{<br>
- =A0 =A0return time * rqd-&gt;max_weight / svc-&gt;weight;<br>
+ =A0 =A0uint64_t val =3D time * rqd-&gt;max_weight + svc-&gt;residual;<br>
+<br>
+ =A0 =A0svc-&gt;residual =3D do_div(val, svc-&gt;weight);<br>
+ =A0 =A0svc-&gt;credit -=3D val;<br>
=A0}<br>
<br>
</div>-static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credi=
t, struct csched_vcpu *svc)<br>
+static s_time_t c2t_adjusted(struct csched_runqueue_data *rqd, s_time_t cr=
edit, struct csched_vcpu *svc)<br>
=A0{<br>
<div class=3D"im HOEnZb">=A0 =A0 =A0return credit * svc-&gt;weight / rqd-&g=
t;max_weight;<br>
=A0}<br>
</div><div class=3D"im HOEnZb">@@ -636,8 +645,7 @@ void burn_credits(struct=
 csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t<br>
=A0 =A0 =A0delta =3D now - svc-&gt;start_time;<br>
<br>
=A0 =A0 =A0if ( delta &gt; 0 ) {<br>
- =A0 =A0 =A0 =A0/* This will round down; should we consider rounding up...=
? */<br>
- =A0 =A0 =A0 =A0svc-&gt;credit -=3D t2c(rqd, delta, svc);<br>
+ =A0 =A0 =A0 =A0t2c_update(rqd, delta, svc);<br>
=A0 =A0 =A0 =A0 =A0svc-&gt;start_time =3D now;<br>
<br>
=A0 =A0 =A0 =A0 =A0d2printk(&quot;b d%dv%d c%d\n&quot;,<br>
--<br>
1.7.9.5<br>
<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<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.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div>

--e89a8f3b9d9fac5fb104d6b59d93--


--===============5469165089337171075==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5469165089337171075==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 14:34:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14: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 1UAi5G-0007ve-6T; Wed, 27 Feb 2013 14:34:14 +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 1UAi5F-0007vX-Ac
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:34:13 +0000
Received: from [193.109.254.147:36360] by server-6.bemta-14.messagelabs.com id
	E0/C2-12010-4691E215; Wed, 27 Feb 2013 14:34:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1361975429!9516468!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20600 invoked from network); 27 Feb 2013 14:30:30 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 14:30:30 -0000
Received: by mail-wg0-f43.google.com with SMTP id e12so496509wge.34
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 06:30:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=fb3PWtWtaGt2QW20VbCoYhXTRSB9/pYcwsKC/fE44Bk=;
	b=IW/hUzCk+vFXSN4JVNi8HrobPtFboScStkybapsPgcPi1pmgy/D2jsOOyXN7GF+iJV
	OB4yMkY7H+E1/OoFuil9K0of/ugO1ckufos7HgqMYfbhM1/pka/Y1YF+z99aIMHnL8E2
	b/83b4eQuaWFiRJolzU5k0pgQ8Hl0HZqFsYZdfIQIIiJnA9VSs2GnXtRe3RvTPC9/VoJ
	USmUizgM//s0fORg3oj52ns7r6pa/AUum75hljFd9oYRi/82C+fnkjWishfGdOYcU5zF
	KVTGeLvz91QtlCeDVX0tAMG0dW1IhevzYEFlNJ5JoDJ6DTpjw0T8Cz2g45JMNYlArIH2
	7a0g==
MIME-Version: 1.0
X-Received: by 10.180.108.229 with SMTP id hn5mr26790859wib.28.1361975429584; 
	Wed, 27 Feb 2013 06:30:29 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 06:30:29 -0800 (PST)
In-Reply-To: <1361974243-12446-2-git-send-email-george.dunlap@eu.citrix.com>
References: <1361974243-12446-1-git-send-email-george.dunlap@eu.citrix.com>
	<1361974243-12446-2-git-send-email-george.dunlap@eu.citrix.com>
Date: Wed, 27 Feb 2013 14:30:29 +0000
X-Google-Sender-Auth: NgkFWoJC5BvdvnKEc-_qfEzWiaI
Message-ID: <CAFLBxZa9oYb3EZoCvwP5zb-G4L9DzaM_-xCTVgqOtT1mtB6ZMQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions
 done during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============5469165089337171075=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5469165089337171075==
Content-Type: multipart/alternative; boundary=e89a8f3b9d9fac5fb104d6b59d93

--e89a8f3b9d9fac5fb104d6b59d93
Content-Type: text/plain; charset=ISO-8859-1

Gah, sorry -- ignore this one...


On Wed, Feb 27, 2013 at 2:10 PM, George Dunlap
<george.dunlap@eu.citrix.com>wrote:

> This should help with under-accounting of vCPU-s running for extremly
> short periods of time, but becoming runnable again at a high frequency.
>
> Don't bother subtracting the residual from the runtime, as it can only ever
> add up to one nanosecond, and will end up being debited during the next
> reset interval anyway.
>
> Original-patch-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> ---
>  xen/common/sched_credit2.c |   24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 804049e..eb544db 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -21,7 +21,7 @@
>  #include <xen/perfc.h>
>  #include <xen/sched-if.h>
>  #include <xen/softirq.h>
> -#include <asm/atomic.h>
> +#include <asm/div64.h>
>  #include <xen/errno.h>
>  #include <xen/trace.h>
>  #include <xen/cpu.h>
> @@ -205,7 +205,7 @@ struct csched_runqueue_data {
>
>      struct list_head runq; /* Ordered list of runnable vms */
>      struct list_head svc;  /* List of all vcpus assigned to this runqueue
> */
> -    int max_weight;
> +    unsigned int max_weight;
>
>      cpumask_t idle,        /* Currently idle */
>          tickled;           /* Another cpu in the queue is already
> targeted for this one */
> @@ -244,7 +244,8 @@ struct csched_vcpu {
>      struct csched_dom *sdom;
>      struct vcpu *vcpu;
>
> -    int weight;
> +    unsigned int weight;
> +    unsigned int residual;
>
>      int credit;
>      s_time_t start_time; /* When we were scheduled (used for credit) */
> @@ -271,14 +272,22 @@ struct csched_dom {
>
>  /*
>   * Time-to-credit, credit-to-time.
> + *
> + * We keep track of the "residual" time to make sure that frequent short
> + * schedules still get accounted for in the end.
> + *
>   * FIXME: Do pre-calculated division?
>   */
> -static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time,
> struct csched_vcpu *svc)
> +static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
> +                          struct csched_vcpu *svc)
>  {
> -    return time * rqd->max_weight / svc->weight;
> +    uint64_t val = time * rqd->max_weight + svc->residual;
> +
> +    svc->residual = do_div(val, svc->weight);
> +    svc->credit -= val;
>  }
>
> -static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit,
> struct csched_vcpu *svc)
> +static s_time_t c2t_adjusted(struct csched_runqueue_data *rqd, s_time_t
> credit, struct csched_vcpu *svc)
>  {
>      return credit * svc->weight / rqd->max_weight;
>  }
> @@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd,
> struct csched_vcpu *svc, s_t
>      delta = now - svc->start_time;
>
>      if ( delta > 0 ) {
> -        /* This will round down; should we consider rounding up...? */
> -        svc->credit -= t2c(rqd, delta, svc);
> +        t2c_update(rqd, delta, svc);
>          svc->start_time = now;
>
>          d2printk("b d%dv%d c%d\n",
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--e89a8f3b9d9fac5fb104d6b59d93
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Gah, sorry -- ignore this one...<br></div><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Wed, Feb 27, 2013 at 2:10 =
PM, George Dunlap <span dir=3D"ltr">&lt;<a href=3D"mailto:george.dunlap@eu.=
citrix.com" target=3D"_blank">george.dunlap@eu.citrix.com</a>&gt;</span> wr=
ote:<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">This should help with unde=
r-accounting of vCPU-s running for extremly<br>
short periods of time, but becoming runnable again at a high frequency.<br>
<br>
</div>Don&#39;t bother subtracting the residual from the runtime, as it can=
 only ever<br>
add up to one nanosecond, and will end up being debited during the next<br>
reset interval anyway.<br>
<div class=3D"im"><br>
Original-patch-by: Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.com">jbe=
ulich@suse.com</a>&gt;<br>
Signed-off-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.=
com">george.dunlap@eu.citrix.com</a>&gt;<br>
---<br>
=A0xen/common/sched_credit2.c | =A0 24 ++++++++++++++++--------<br>
=A01 file changed, 16 insertions(+), 8 deletions(-)<br>
<br>
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c<br>
</div>index 804049e..eb544db 100644<br>
<div><div class=3D"h5">--- a/xen/common/sched_credit2.c<br>
+++ b/xen/common/sched_credit2.c<br>
@@ -21,7 +21,7 @@<br>
=A0#include &lt;xen/perfc.h&gt;<br>
=A0#include &lt;xen/sched-if.h&gt;<br>
=A0#include &lt;xen/softirq.h&gt;<br>
-#include &lt;asm/atomic.h&gt;<br>
+#include &lt;asm/div64.h&gt;<br>
=A0#include &lt;xen/errno.h&gt;<br>
=A0#include &lt;xen/trace.h&gt;<br>
=A0#include &lt;xen/cpu.h&gt;<br>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {<br>
<br>
=A0 =A0 =A0struct list_head runq; /* Ordered list of runnable vms */<br>
=A0 =A0 =A0struct list_head svc; =A0/* List of all vcpus assigned to this r=
unqueue */<br>
- =A0 =A0int max_weight;<br>
+ =A0 =A0unsigned int max_weight;<br>
<br>
=A0 =A0 =A0cpumask_t idle, =A0 =A0 =A0 =A0/* Currently idle */<br>
=A0 =A0 =A0 =A0 =A0tickled; =A0 =A0 =A0 =A0 =A0 /* Another cpu in the queue=
 is already targeted for this one */<br>
@@ -244,7 +244,8 @@ struct csched_vcpu {<br>
=A0 =A0 =A0struct csched_dom *sdom;<br>
=A0 =A0 =A0struct vcpu *vcpu;<br>
<br>
- =A0 =A0int weight;<br>
+ =A0 =A0unsigned int weight;<br>
+ =A0 =A0unsigned int residual;<br>
<br>
=A0 =A0 =A0int credit;<br>
=A0 =A0 =A0s_time_t start_time; /* When we were scheduled (used for credit)=
 */<br>
</div></div>@@ -271,14 +272,22 @@ struct csched_dom {<br>
<div class=3D"im"><br>
=A0/*<br>
=A0 * Time-to-credit, credit-to-time.<br>
+ *<br>
+ * We keep track of the &quot;residual&quot; time to make sure that freque=
nt short<br>
+ * schedules still get accounted for in the end.<br>
+ *<br>
=A0 * FIXME: Do pre-calculated division?<br>
=A0 */<br>
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struc=
t csched_vcpu *svc)<br>
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct csched_vcpu *sv=
c)<br>
=A0{<br>
- =A0 =A0return time * rqd-&gt;max_weight / svc-&gt;weight;<br>
+ =A0 =A0uint64_t val =3D time * rqd-&gt;max_weight + svc-&gt;residual;<br>
+<br>
+ =A0 =A0svc-&gt;residual =3D do_div(val, svc-&gt;weight);<br>
+ =A0 =A0svc-&gt;credit -=3D val;<br>
=A0}<br>
<br>
</div>-static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credi=
t, struct csched_vcpu *svc)<br>
+static s_time_t c2t_adjusted(struct csched_runqueue_data *rqd, s_time_t cr=
edit, struct csched_vcpu *svc)<br>
=A0{<br>
<div class=3D"im HOEnZb">=A0 =A0 =A0return credit * svc-&gt;weight / rqd-&g=
t;max_weight;<br>
=A0}<br>
</div><div class=3D"im HOEnZb">@@ -636,8 +645,7 @@ void burn_credits(struct=
 csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t<br>
=A0 =A0 =A0delta =3D now - svc-&gt;start_time;<br>
<br>
=A0 =A0 =A0if ( delta &gt; 0 ) {<br>
- =A0 =A0 =A0 =A0/* This will round down; should we consider rounding up...=
? */<br>
- =A0 =A0 =A0 =A0svc-&gt;credit -=3D t2c(rqd, delta, svc);<br>
+ =A0 =A0 =A0 =A0t2c_update(rqd, delta, svc);<br>
=A0 =A0 =A0 =A0 =A0svc-&gt;start_time =3D now;<br>
<br>
=A0 =A0 =A0 =A0 =A0d2printk(&quot;b d%dv%d c%d\n&quot;,<br>
--<br>
1.7.9.5<br>
<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<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.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div>

--e89a8f3b9d9fac5fb104d6b59d93--


--===============5469165089337171075==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5469165089337171075==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFS-00089b-Ow; Wed, 27 Feb 2013 14:44:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFQ-00089P-QY
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:45 +0000
Received: from [85.158.138.51:15824] by server-11.bemta-3.messagelabs.com id
	92/14-01263-CDB1E215; Wed, 27 Feb 2013 14:44:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16579 invoked from network); 27 Feb 2013 14:44:42 -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;
	27 Feb 2013 14:44:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503695"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:41 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Mv;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:02 +0000
Message-ID: <1361975655-22295-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 09/22] Bump EVTCHNS_PER_BUCKET to 512
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 64 bit build and 3-level event channel and the original value of
EVTCHNS_PER_BUCKET (128), the space needed to accommodate d->evtchn
would be 4 pages (PAGE_SIZE = 4096). Given that not every domain needs
3-level event channel, this leads to waste of memory. Also we've
restricted d->evtchn to one page, if we move to 3-level event channel,
Xen cannot build.

Having EVTCHN_PER_BUCKETS to be 512 can occupy exact one page.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 2686960..68ce2ae 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -39,7 +39,7 @@ static inline unsigned int max_evtchns(struct domain *d)
     return ret;
 }
 
-#define EVTCHNS_PER_BUCKET 128
+#define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
 
 struct evtchn
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFS-00089b-Ow; Wed, 27 Feb 2013 14:44:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFQ-00089P-QY
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:45 +0000
Received: from [85.158.138.51:15824] by server-11.bemta-3.messagelabs.com id
	92/14-01263-CDB1E215; Wed, 27 Feb 2013 14:44:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16579 invoked from network); 27 Feb 2013 14:44:42 -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;
	27 Feb 2013 14:44:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503695"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:41 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Mv;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:02 +0000
Message-ID: <1361975655-22295-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 09/22] Bump EVTCHNS_PER_BUCKET to 512
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 64 bit build and 3-level event channel and the original value of
EVTCHNS_PER_BUCKET (128), the space needed to accommodate d->evtchn
would be 4 pages (PAGE_SIZE = 4096). Given that not every domain needs
3-level event channel, this leads to waste of memory. Also we've
restricted d->evtchn to one page, if we move to 3-level event channel,
Xen cannot build.

Having EVTCHN_PER_BUCKETS to be 512 can occupy exact one page.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 2686960..68ce2ae 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -39,7 +39,7 @@ static inline unsigned int max_evtchns(struct domain *d)
     return ret;
 }
 
-#define EVTCHNS_PER_BUCKET 128
+#define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
 
 struct evtchn
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFR-00089U-C4; Wed, 27 Feb 2013 14:44:45 +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 1UAiFP-00089I-OE
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:43 +0000
Received: from [85.158.138.51:57859] by server-8.bemta-3.messagelabs.com id
	5A/68-20604-BDB1E215; Wed, 27 Feb 2013 14:44:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16528 invoked from network); 27 Feb 2013 14:44:41 -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;
	27 Feb 2013 14:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503686"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:39 -0500
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 1UAi6C-0007HD-Kt;
	Wed, 27 Feb 2013 14:35:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:27:14 +0000
Message-ID: <1361975235-27701-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/2] xen,
	credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v3:
 - ASSERT that rt_credt >= 0, since there's a possibility for credits
   to be equal
v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b0af010..804049e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 static s_time_t
 csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
+    s_time_t time; 
+    int rt_credit; /* Proposed runtime measured in credits */
     struct csched_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
         return CSCHED_MAX_TIMER;
 
-    /* Basic time */
-    time = c2t(rqd, snext->credit, snext);
+    /* General algorithm:
+     * 1) Run until snext's credit will be 0
+     * 2) But if someone is waiting, run until snext's credit is equal
+     * to his
+     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
+     */
+
+    /* 1) Basic time: Run until credit is 0. */
+    rt_credit = snext->credit;
 
-    /* Next guy on runqueue */
+    /* 2) If there's someone waiting whose credit is positive,
+     * run until your credit ~= his */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
-        s_time_t ntime;
+        struct csched_vcpu *swait = __runq_elem(runq->next);
 
-        if ( ! is_idle_vcpu(svc->vcpu) )
+        if ( ! is_idle_vcpu(swait->vcpu)
+             && swait->credit > 0 )
         {
-            ntime = c2t(rqd, snext->credit - svc->credit, snext);
-
-            if ( time > ntime )
-                time = ntime;
+            rt_credit = snext->credit - swait->credit;
         }
     }
 
+    /*
+     * snext is about to be scheduled; so:
+     *
+     * 1. if snext->credit were less than 0 when it was taken off the
+     * runqueue, then csched_schedule() should have called
+     * reset_credit().  So at this point snext->credit must be greater
+     * than 0.
+     *
+     * 2. snext's credit must be greater than or equal to anyone else
+     * in the queue, so snext->credit - swait->credit must be greater
+     * than or equal to 0.
+     */
+    ASSERT(rt_credit >= 0);
+
+    /* FIXME: See if we can eliminate this conversion if we know time
+     * will be outside (MIN,MAX).  Probably requires pre-calculating
+     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
+     * at a different rate. */
+    time = c2t(rqd, rt_credit, snext);
+
     /* Check limits */
     if ( time < CSCHED_MIN_TIMER )
         time = CSCHED_MIN_TIMER;
-- 
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 Wed Feb 27 14:45:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFR-00089U-C4; Wed, 27 Feb 2013 14:44:45 +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 1UAiFP-00089I-OE
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:43 +0000
Received: from [85.158.138.51:57859] by server-8.bemta-3.messagelabs.com id
	5A/68-20604-BDB1E215; Wed, 27 Feb 2013 14:44:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16528 invoked from network); 27 Feb 2013 14:44:41 -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;
	27 Feb 2013 14:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503686"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:39 -0500
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 1UAi6C-0007HD-Kt;
	Wed, 27 Feb 2013 14:35:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:27:14 +0000
Message-ID: <1361975235-27701-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 1/2] xen,
	credit2: Avoid extra c2t calcuation in csched_runtime
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

csched_runtime() needs to call the ct2() function to change credits
into time.  The c2t() function, however, is expensive, as it requires
an integer division.

c2t() was being called twice, once for the main vcpu's credit and once
for the difference between its credit and the next in the queue.  But
this is unnecessary; by calculating in "credit" first, we can make it
so that we just do one conversion later in the algorithm.

This also adds more documentation describing the intended algorithm,
along with a relevant assertion..

The effect of the new code should be the same as the old code.

v3:
 - ASSERT that rt_credt >= 0, since there's a possibility for credits
   to be equal
v2:
 - Change rt_credit into an int
 - ASSERT() that rt_credit > 0, with explanation

Spotted-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   48 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b0af010..804049e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1505,31 +1505,57 @@ csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 static s_time_t
 csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu *snext)
 {
-    s_time_t time = CSCHED_MAX_TIMER;
+    s_time_t time; 
+    int rt_credit; /* Proposed runtime measured in credits */
     struct csched_runqueue_data *rqd = RQD(ops, cpu);
     struct list_head *runq = &rqd->runq;
 
     if ( is_idle_vcpu(snext->vcpu) )
         return CSCHED_MAX_TIMER;
 
-    /* Basic time */
-    time = c2t(rqd, snext->credit, snext);
+    /* General algorithm:
+     * 1) Run until snext's credit will be 0
+     * 2) But if someone is waiting, run until snext's credit is equal
+     * to his
+     * 3) But never run longer than MAX_TIMER or shorter than MIN_TIMER.
+     */
+
+    /* 1) Basic time: Run until credit is 0. */
+    rt_credit = snext->credit;
 
-    /* Next guy on runqueue */
+    /* 2) If there's someone waiting whose credit is positive,
+     * run until your credit ~= his */
     if ( ! list_empty(runq) )
     {
-        struct csched_vcpu *svc = __runq_elem(runq->next);
-        s_time_t ntime;
+        struct csched_vcpu *swait = __runq_elem(runq->next);
 
-        if ( ! is_idle_vcpu(svc->vcpu) )
+        if ( ! is_idle_vcpu(swait->vcpu)
+             && swait->credit > 0 )
         {
-            ntime = c2t(rqd, snext->credit - svc->credit, snext);
-
-            if ( time > ntime )
-                time = ntime;
+            rt_credit = snext->credit - swait->credit;
         }
     }
 
+    /*
+     * snext is about to be scheduled; so:
+     *
+     * 1. if snext->credit were less than 0 when it was taken off the
+     * runqueue, then csched_schedule() should have called
+     * reset_credit().  So at this point snext->credit must be greater
+     * than 0.
+     *
+     * 2. snext's credit must be greater than or equal to anyone else
+     * in the queue, so snext->credit - swait->credit must be greater
+     * than or equal to 0.
+     */
+    ASSERT(rt_credit >= 0);
+
+    /* FIXME: See if we can eliminate this conversion if we know time
+     * will be outside (MIN,MAX).  Probably requires pre-calculating
+     * credit values of MIN,MAX per vcpu, since each vcpu burns credit
+     * at a different rate. */
+    time = c2t(rqd, rt_credit, snext);
+
     /* Check limits */
     if ( time < CSCHED_MIN_TIMER )
         time = CSCHED_MIN_TIMER;
-- 
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 Wed Feb 27 14:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFZ-0008Aa-Oe; Wed, 27 Feb 2013 14:44:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFY-00089q-DI
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:52 +0000
Received: from [85.158.138.51:58851] by server-8.bemta-3.messagelabs.com id
	D9/A8-20604-4EB1E215; Wed, 27 Feb 2013 14:44:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17663 invoked from network); 27 Feb 2013 14:44:50 -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;
	27 Feb 2013 14:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503750"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:50 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Ff;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:58 +0000
Message-ID: <1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to
	max_evtchns inline 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

The calculation of max event channels depends on the actual ABI in use. Try to
avoid gcc-ism macro.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |    4 ++--
 xen/common/schedule.c      |    2 +-
 xen/include/xen/event.h    |    7 +++++--
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 3293f91..684a021 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -134,7 +134,7 @@ static int get_free_port(struct domain *d)
         if ( evtchn_from_port(d, port)->state == ECS_FREE )
             return port;
 
-    if ( port == MAX_EVTCHNS(d) )
+    if ( port == max_evtchns(d) )
         return -ENOSPC;
 
     chn = xzalloc_array(struct evtchn, EVTCHNS_PER_BUCKET);
@@ -1269,7 +1269,7 @@ static void domain_dump_evtchn_info(struct domain *d)
 
     spin_lock(&d->event_lock);
 
-    for ( port = 1; port < MAX_EVTCHNS(d); ++port )
+    for ( port = 1; port < max_evtchns(d); ++port )
     {
         const struct evtchn *chn;
         char *ssid;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e6a90d8..e59eb4d 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -689,7 +689,7 @@ static long do_poll(struct sched_poll *sched_poll)
             goto out;
 
         rc = -EINVAL;
-        if ( port >= MAX_EVTCHNS(d) )
+        if ( port >= max_evtchns(d) )
             goto out;
 
         rc = 0;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index a1574ea..f8de10b 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,10 @@
 #else
 #define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
 #endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+static inline unsigned int max_evtchns(struct domain *d)
+{
+    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
+}
 
 #define EVTCHNS_PER_BUCKET 128
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
@@ -119,7 +122,7 @@ void notify_via_xen_event_channel(struct domain *ld, int lport);
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
 #define port_is_valid(d,p)    \
-    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
+    (((p) >= 0) && ((p) < max_evtchns(d)) && \
      (bucket_from_port(d,p) != NULL))
 #define evtchn_from_port(d,p) \
     (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFZ-0008Aa-Oe; Wed, 27 Feb 2013 14:44:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFY-00089q-DI
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:52 +0000
Received: from [85.158.138.51:58851] by server-8.bemta-3.messagelabs.com id
	D9/A8-20604-4EB1E215; Wed, 27 Feb 2013 14:44:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17663 invoked from network); 27 Feb 2013 14:44:50 -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;
	27 Feb 2013 14:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503750"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:50 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Ff;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:58 +0000
Message-ID: <1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to
	max_evtchns inline 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

The calculation of max event channels depends on the actual ABI in use. Try to
avoid gcc-ism macro.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |    4 ++--
 xen/common/schedule.c      |    2 +-
 xen/include/xen/event.h    |    7 +++++--
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 3293f91..684a021 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -134,7 +134,7 @@ static int get_free_port(struct domain *d)
         if ( evtchn_from_port(d, port)->state == ECS_FREE )
             return port;
 
-    if ( port == MAX_EVTCHNS(d) )
+    if ( port == max_evtchns(d) )
         return -ENOSPC;
 
     chn = xzalloc_array(struct evtchn, EVTCHNS_PER_BUCKET);
@@ -1269,7 +1269,7 @@ static void domain_dump_evtchn_info(struct domain *d)
 
     spin_lock(&d->event_lock);
 
-    for ( port = 1; port < MAX_EVTCHNS(d); ++port )
+    for ( port = 1; port < max_evtchns(d); ++port )
     {
         const struct evtchn *chn;
         char *ssid;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e6a90d8..e59eb4d 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -689,7 +689,7 @@ static long do_poll(struct sched_poll *sched_poll)
             goto out;
 
         rc = -EINVAL;
-        if ( port >= MAX_EVTCHNS(d) )
+        if ( port >= max_evtchns(d) )
             goto out;
 
         rc = 0;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index a1574ea..f8de10b 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,10 @@
 #else
 #define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
 #endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+static inline unsigned int max_evtchns(struct domain *d)
+{
+    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
+}
 
 #define EVTCHNS_PER_BUCKET 128
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
@@ -119,7 +122,7 @@ void notify_via_xen_event_channel(struct domain *ld, int lport);
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
 #define port_is_valid(d,p)    \
-    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
+    (((p) >= 0) && ((p) < max_evtchns(d)) && \
      (bucket_from_port(d,p) != NULL))
 #define evtchn_from_port(d,p) \
     (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFY-0008A3-5z; Wed, 27 Feb 2013 14:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFV-00089q-PW
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:50 +0000
Received: from [85.158.138.51:20289] by server-8.bemta-3.messagelabs.com id
	34/98-20604-1EB1E215; Wed, 27 Feb 2013 14:44:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17026 invoked from network); 27 Feb 2013 14:44:47 -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;
	27 Feb 2013 14:44:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503730"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:46 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-J6;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:00 +0000
Message-ID: <1361975655-22295-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 07/22] Add evtchn_extended in struct
	domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 field is a bitmap of currently in use extended event channel ABI, which
can have 0 (no extended event channel in use) 1 bit set. It is manipulated by
hypervisor only, so if anything goes wrong it is a bug.

The default event channel ABI is EVTCHN_EXTENDED_NONE, which means no extended
event channel is used.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/xen/event.h    |   12 +++++++++++-
 xen/include/xen/sched.h    |    1 +
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 684a021..bd4b1e8 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1179,6 +1179,7 @@ int evtchn_init(struct domain *d)
         return -ENOMEM;
     clear_page(d->evtchn);
 
+    d->evtchn_extended = EVTCHN_EXTENDED_NONE;
     spin_lock_init(&d->event_lock);
     if ( get_free_port(d) != 0 ) {
         free_xenheap_page(d->evtchn);
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index f8de10b..240344b 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -14,6 +14,7 @@
 #include <xen/softirq.h>
 #include <asm/bitops.h>
 #include <asm/event.h>
+#include <public/event_channel.h>
 
 #ifndef CONFIG_COMPAT
 #define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
@@ -22,7 +23,16 @@
 #endif
 static inline unsigned int max_evtchns(struct domain *d)
 {
-    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
+    unsigned int ret = 0;
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
+        break;
+    default:
+        BUG();
+    }
+    return ret;
 }
 
 #define EVTCHNS_PER_BUCKET 128
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index bb65cbf..dd40444 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -217,6 +217,7 @@ struct domain
     /* Event channel information. */
     struct evtchn  **evtchn;
     spinlock_t       event_lock;
+    unsigned int     evtchn_extended;
 
     struct grant_table *grant_table;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFY-0008A3-5z; Wed, 27 Feb 2013 14:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFV-00089q-PW
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:50 +0000
Received: from [85.158.138.51:20289] by server-8.bemta-3.messagelabs.com id
	34/98-20604-1EB1E215; Wed, 27 Feb 2013 14:44:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17026 invoked from network); 27 Feb 2013 14:44:47 -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;
	27 Feb 2013 14:44:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503730"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:46 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-J6;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:00 +0000
Message-ID: <1361975655-22295-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 07/22] Add evtchn_extended in struct
	domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 field is a bitmap of currently in use extended event channel ABI, which
can have 0 (no extended event channel in use) 1 bit set. It is manipulated by
hypervisor only, so if anything goes wrong it is a bug.

The default event channel ABI is EVTCHN_EXTENDED_NONE, which means no extended
event channel is used.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |    1 +
 xen/include/xen/event.h    |   12 +++++++++++-
 xen/include/xen/sched.h    |    1 +
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 684a021..bd4b1e8 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1179,6 +1179,7 @@ int evtchn_init(struct domain *d)
         return -ENOMEM;
     clear_page(d->evtchn);
 
+    d->evtchn_extended = EVTCHN_EXTENDED_NONE;
     spin_lock_init(&d->event_lock);
     if ( get_free_port(d) != 0 ) {
         free_xenheap_page(d->evtchn);
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index f8de10b..240344b 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -14,6 +14,7 @@
 #include <xen/softirq.h>
 #include <asm/bitops.h>
 #include <asm/event.h>
+#include <public/event_channel.h>
 
 #ifndef CONFIG_COMPAT
 #define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
@@ -22,7 +23,16 @@
 #endif
 static inline unsigned int max_evtchns(struct domain *d)
 {
-    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
+    unsigned int ret = 0;
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
+        break;
+    default:
+        BUG();
+    }
+    return ret;
 }
 
 #define EVTCHNS_PER_BUCKET 128
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index bb65cbf..dd40444 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -217,6 +217,7 @@ struct domain
     /* Event channel information. */
     struct evtchn  **evtchn;
     spinlock_t       event_lock;
+    unsigned int     evtchn_extended;
 
     struct grant_table *grant_table;
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14: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 1UAiFd-0008BV-5n; Wed, 27 Feb 2013 14:44:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFb-0008As-6h
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:55 +0000
Received: from [85.158.138.51:20833] by server-11.bemta-3.messagelabs.com id
	9A/74-01263-6EB1E215; Wed, 27 Feb 2013 14:44:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4783 invoked from network); 27 Feb 2013 14:44:53 -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 Feb 2013 14:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994549"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-L5;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:01 +0000
Message-ID: <1361975655-22295-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 08/22] Calculate max event channels for
	EVTCHN_EXTENDED_L3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/xen/event.h |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 240344b..2686960 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -29,6 +29,10 @@ static inline unsigned int max_evtchns(struct domain *d)
     case EVTCHN_EXTENDED_NONE:
         ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
         break;
+    case EVTCHN_EXTENDED_L3:
+        ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d)
+              * BITS_PER_EVTCHN_WORD(d);
+        break;
     default:
         BUG();
     }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14: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 1UAiFd-0008BV-5n; Wed, 27 Feb 2013 14:44:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFb-0008As-6h
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:55 +0000
Received: from [85.158.138.51:20833] by server-11.bemta-3.messagelabs.com id
	9A/74-01263-6EB1E215; Wed, 27 Feb 2013 14:44:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4783 invoked from network); 27 Feb 2013 14:44:53 -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 Feb 2013 14:44:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994549"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-L5;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:01 +0000
Message-ID: <1361975655-22295-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 08/22] Calculate max event channels for
	EVTCHN_EXTENDED_L3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/xen/event.h |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 240344b..2686960 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -29,6 +29,10 @@ static inline unsigned int max_evtchns(struct domain *d)
     case EVTCHN_EXTENDED_NONE:
         ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
         break;
+    case EVTCHN_EXTENDED_L3:
+        ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d)
+              * BITS_PER_EVTCHN_WORD(d);
+        break;
     default:
         BUG();
     }
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFk-0008FI-Rs; Wed, 27 Feb 2013 14:45:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFh-0008D3-Nh
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:01 +0000
Received: from [85.158.138.51:21025] by server-13.bemta-3.messagelabs.com id
	43/F1-25744-8EB1E215; Wed, 27 Feb 2013 14:44:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18083 invoked from network); 27 Feb 2013 14:44:54 -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;
	27 Feb 2013 14:44:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503762"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:53 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Bu;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:56 +0000
Message-ID: <1361975655-22295-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 03/22] Move event channel macros / struct
	definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 remove reference to NR_EVTCHN_BUCKETS in struct domain, we can move
those macros / struct definitions to event.h.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/sched.h |   45 ---------------------------------------------
 2 files changed, 46 insertions(+), 45 deletions(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 65ac81a..a1574ea 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -15,6 +15,52 @@
 #include <asm/bitops.h>
 #include <asm/event.h>
 
+#ifndef CONFIG_COMPAT
+#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
+#else
+#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
+#endif
+#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+
+#define EVTCHNS_PER_BUCKET 128
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+
+struct evtchn
+{
+#define ECS_FREE         0 /* Channel is available for use.                  */
+#define ECS_RESERVED     1 /* Channel is reserved.                           */
+#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
+#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
+#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
+#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
+#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
+    u8  state;             /* ECS_* */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
+    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
+    union {
+        struct {
+            domid_t remote_domid;
+        } unbound;     /* state == ECS_UNBOUND */
+        struct {
+            u16            remote_port;
+            struct domain *remote_dom;
+        } interdomain; /* state == ECS_INTERDOMAIN */
+        struct {
+            u16            irq;
+            u16            next_port;
+            u16            prev_port;
+        } pirq;        /* state == ECS_PIRQ */
+        u16 virq;      /* state == ECS_VIRQ */
+    } u;
+#ifdef FLASK_ENABLE
+    void *ssid;
+#endif
+};
+
+int  evtchn_init(struct domain *d); /* from domain_create */
+void evtchn_destroy(struct domain *d); /* from domain_kill */
+void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
+
 /*
  * send_guest_vcpu_virq: Notify guest via a per-VCPU VIRQ.
  *  @v:        VCPU to which virtual IRQ should be sent
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 812bd87..bb65cbf 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -45,51 +45,6 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 /* A global pointer to the initial domain (DOM0). */
 extern struct domain *dom0;
 
-#ifndef CONFIG_COMPAT
-#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
-#else
-#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
-#endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
-#define EVTCHNS_PER_BUCKET 128
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
-
-struct evtchn
-{
-#define ECS_FREE         0 /* Channel is available for use.                  */
-#define ECS_RESERVED     1 /* Channel is reserved.                           */
-#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
-#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
-#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
-#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
-#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
-    u8  state;             /* ECS_* */
-    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
-    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
-    union {
-        struct {
-            domid_t remote_domid;
-        } unbound;     /* state == ECS_UNBOUND */
-        struct {
-            u16            remote_port;
-            struct domain *remote_dom;
-        } interdomain; /* state == ECS_INTERDOMAIN */
-        struct {
-            u16            irq;
-            u16            next_port;
-            u16            prev_port;
-        } pirq;        /* state == ECS_PIRQ */
-        u16 virq;      /* state == ECS_VIRQ */
-    } u;
-#ifdef FLASK_ENABLE
-    void *ssid;
-#endif
-};
-
-int  evtchn_init(struct domain *d); /* from domain_create */
-void evtchn_destroy(struct domain *d); /* from domain_kill */
-void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
-
 struct waitqueue_vcpu;
 
 struct vcpu
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFk-0008FI-Rs; Wed, 27 Feb 2013 14:45:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFh-0008D3-Nh
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:01 +0000
Received: from [85.158.138.51:21025] by server-13.bemta-3.messagelabs.com id
	43/F1-25744-8EB1E215; Wed, 27 Feb 2013 14:44:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18083 invoked from network); 27 Feb 2013 14:44:54 -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;
	27 Feb 2013 14:44:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503762"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:53 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Bu;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:56 +0000
Message-ID: <1361975655-22295-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 03/22] Move event channel macros / struct
	definition to proper place
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 remove reference to NR_EVTCHN_BUCKETS in struct domain, we can move
those macros / struct definitions to event.h.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/event.h |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/sched.h |   45 ---------------------------------------------
 2 files changed, 46 insertions(+), 45 deletions(-)

diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 65ac81a..a1574ea 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -15,6 +15,52 @@
 #include <asm/bitops.h>
 #include <asm/event.h>
 
+#ifndef CONFIG_COMPAT
+#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
+#else
+#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
+#endif
+#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
+
+#define EVTCHNS_PER_BUCKET 128
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+
+struct evtchn
+{
+#define ECS_FREE         0 /* Channel is available for use.                  */
+#define ECS_RESERVED     1 /* Channel is reserved.                           */
+#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
+#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
+#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
+#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
+#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
+    u8  state;             /* ECS_* */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
+    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
+    union {
+        struct {
+            domid_t remote_domid;
+        } unbound;     /* state == ECS_UNBOUND */
+        struct {
+            u16            remote_port;
+            struct domain *remote_dom;
+        } interdomain; /* state == ECS_INTERDOMAIN */
+        struct {
+            u16            irq;
+            u16            next_port;
+            u16            prev_port;
+        } pirq;        /* state == ECS_PIRQ */
+        u16 virq;      /* state == ECS_VIRQ */
+    } u;
+#ifdef FLASK_ENABLE
+    void *ssid;
+#endif
+};
+
+int  evtchn_init(struct domain *d); /* from domain_create */
+void evtchn_destroy(struct domain *d); /* from domain_kill */
+void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
+
 /*
  * send_guest_vcpu_virq: Notify guest via a per-VCPU VIRQ.
  *  @v:        VCPU to which virtual IRQ should be sent
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 812bd87..bb65cbf 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -45,51 +45,6 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 /* A global pointer to the initial domain (DOM0). */
 extern struct domain *dom0;
 
-#ifndef CONFIG_COMPAT
-#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
-#else
-#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
-#endif
-#define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
-#define EVTCHNS_PER_BUCKET 128
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
-
-struct evtchn
-{
-#define ECS_FREE         0 /* Channel is available for use.                  */
-#define ECS_RESERVED     1 /* Channel is reserved.                           */
-#define ECS_UNBOUND      2 /* Channel is waiting to bind to a remote domain. */
-#define ECS_INTERDOMAIN  3 /* Channel is bound to another domain.            */
-#define ECS_PIRQ         4 /* Channel is bound to a physical IRQ line.       */
-#define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
-#define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
-    u8  state;             /* ECS_* */
-    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
-    u16 notify_vcpu_id;    /* VCPU for local delivery notification */
-    union {
-        struct {
-            domid_t remote_domid;
-        } unbound;     /* state == ECS_UNBOUND */
-        struct {
-            u16            remote_port;
-            struct domain *remote_dom;
-        } interdomain; /* state == ECS_INTERDOMAIN */
-        struct {
-            u16            irq;
-            u16            next_port;
-            u16            prev_port;
-        } pirq;        /* state == ECS_PIRQ */
-        u16 virq;      /* state == ECS_VIRQ */
-    } u;
-#ifdef FLASK_ENABLE
-    void *ssid;
-#endif
-};
-
-int  evtchn_init(struct domain *d); /* from domain_create */
-void evtchn_destroy(struct domain *d); /* from domain_kill */
-void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
-
 struct waitqueue_vcpu;
 
 struct vcpu
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFe-0008Bv-Jn; Wed, 27 Feb 2013 14:44:58 +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 1UAiFd-0008BX-Mc
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:57 +0000
Received: from [85.158.138.51:58930] by server-15.bemta-3.messagelabs.com id
	80/60-23142-4EB1E215; Wed, 27 Feb 2013 14:44:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4631 invoked from network); 27 Feb 2013 14:44:51 -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 Feb 2013 14:44:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994509"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:29 -0500
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 1UAi8Z-0007JD-MG;
	Wed, 27 Feb 2013 14:37:39 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:29:36 +0000
Message-ID: <1361975376-27913-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] credit1: Use atomic bit operations for the
	flags structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 flags structure is not protected by locks (or more precisely,
it is protected using an inconsistent set of locks); we therefore need
to make sure that all accesses are atomic-safe.  This is particulary
important in the case of the PARKED flag, which if clobbered while
changing the YIELD bit will leave a vcpu wedged in an offline state.

Using the atomic bitops also requires us to change the size of the "flags"
element.

Spotted-by: Igor Pavlikevich <ipavlikevich@gmail.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit.c |   23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index df2d076..ecdbd76 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -46,8 +46,8 @@
 /*
  * Flags
  */
-#define CSCHED_FLAG_VCPU_PARKED    0x0001  /* VCPU over capped credits */
-#define CSCHED_FLAG_VCPU_YIELD     0x0002  /* VCPU yielding */
+#define CSCHED_FLAG_VCPU_PARKED    0x0  /* VCPU over capped credits */
+#define CSCHED_FLAG_VCPU_YIELD     0x1  /* VCPU yielding */
 
 
 /*
@@ -137,7 +137,7 @@ struct csched_vcpu {
     struct vcpu *vcpu;
     atomic_t credit;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
-    uint16_t flags;
+    unsigned flags;
     int16_t pri;
 #ifdef CSCHED_STATS
     struct {
@@ -220,7 +220,7 @@ __runq_insert(unsigned int cpu, struct csched_vcpu *svc)
     /* If the vcpu yielded, try to put it behind one lower-priority
      * runnable vcpu if we can.  The next runq_sort will bring it forward
      * within 30ms if the queue too long. */
-    if ( svc->flags & CSCHED_FLAG_VCPU_YIELD
+    if ( test_bit(CSCHED_FLAG_VCPU_YIELD, &svc->flags)
          && __runq_elem(iter)->pri > CSCHED_PRI_IDLE )
     {
         iter=iter->next;
@@ -811,7 +811,7 @@ csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
      * those.
      */
     if ( svc->pri == CSCHED_PRI_TS_UNDER &&
-         !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
+         !test_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
     {
         svc->pri = CSCHED_PRI_TS_BOOST;
     }
@@ -824,10 +824,10 @@ csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
 static void
 csched_vcpu_yield(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const sv = CSCHED_VCPU(vc);
+    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
 
     /* Let the scheduler know that this vcpu is trying to yield */
-    sv->flags |= CSCHED_FLAG_VCPU_YIELD;
+    set_bit(CSCHED_FLAG_VCPU_YIELD, &svc->flags);
 }
 
 static int
@@ -1151,11 +1151,10 @@ csched_acct(void* dummy)
                 /* Park running VCPUs of capped-out domains */
                 if ( sdom->cap != 0U &&
                      credit < -credit_cap &&
-                     !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
+                     !test_and_set_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
                 {
                     SCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
-                    svc->flags |= CSCHED_FLAG_VCPU_PARKED;
                 }
 
                 /* Lower bound on credits */
@@ -1171,7 +1170,7 @@ csched_acct(void* dummy)
                 svc->pri = CSCHED_PRI_TS_UNDER;
 
                 /* Unpark any capped domains whose credits go positive */
-                if ( svc->flags & CSCHED_FLAG_VCPU_PARKED)
+                if ( test_and_clear_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
                 {
                     /*
                      * It's important to unset the flag AFTER the unpause()
@@ -1180,7 +1179,6 @@ csched_acct(void* dummy)
                      */
                     SCHED_STAT_CRANK(vcpu_unpark);
                     vcpu_unpause(svc->vcpu);
-                    svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
                 }
 
                 /* Upper bound on credits means VCPU stops earning */
@@ -1442,8 +1440,7 @@ csched_schedule(
     /*
      * Clear YIELD flag before scheduling out
      */
-    if ( scurr->flags & CSCHED_FLAG_VCPU_YIELD )
-        scurr->flags &= ~(CSCHED_FLAG_VCPU_YIELD);
+    clear_bit(CSCHED_FLAG_VCPU_YIELD, &scurr->flags);
 
     /*
      * SMP Load balance:
-- 
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 Wed Feb 27 14:45:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFe-0008Bv-Jn; Wed, 27 Feb 2013 14:44:58 +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 1UAiFd-0008BX-Mc
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:44:57 +0000
Received: from [85.158.138.51:58930] by server-15.bemta-3.messagelabs.com id
	80/60-23142-4EB1E215; Wed, 27 Feb 2013 14:44:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4631 invoked from network); 27 Feb 2013 14:44:51 -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 Feb 2013 14:44:51 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994509"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:29 -0500
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 1UAi8Z-0007JD-MG;
	Wed, 27 Feb 2013 14:37:39 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:29:36 +0000
Message-ID: <1361975376-27913-1-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] credit1: Use atomic bit operations for the
	flags structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 flags structure is not protected by locks (or more precisely,
it is protected using an inconsistent set of locks); we therefore need
to make sure that all accesses are atomic-safe.  This is particulary
important in the case of the PARKED flag, which if clobbered while
changing the YIELD bit will leave a vcpu wedged in an offline state.

Using the atomic bitops also requires us to change the size of the "flags"
element.

Spotted-by: Igor Pavlikevich <ipavlikevich@gmail.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit.c |   23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index df2d076..ecdbd76 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -46,8 +46,8 @@
 /*
  * Flags
  */
-#define CSCHED_FLAG_VCPU_PARKED    0x0001  /* VCPU over capped credits */
-#define CSCHED_FLAG_VCPU_YIELD     0x0002  /* VCPU yielding */
+#define CSCHED_FLAG_VCPU_PARKED    0x0  /* VCPU over capped credits */
+#define CSCHED_FLAG_VCPU_YIELD     0x1  /* VCPU yielding */
 
 
 /*
@@ -137,7 +137,7 @@ struct csched_vcpu {
     struct vcpu *vcpu;
     atomic_t credit;
     s_time_t start_time;   /* When we were scheduled (used for credit) */
-    uint16_t flags;
+    unsigned flags;
     int16_t pri;
 #ifdef CSCHED_STATS
     struct {
@@ -220,7 +220,7 @@ __runq_insert(unsigned int cpu, struct csched_vcpu *svc)
     /* If the vcpu yielded, try to put it behind one lower-priority
      * runnable vcpu if we can.  The next runq_sort will bring it forward
      * within 30ms if the queue too long. */
-    if ( svc->flags & CSCHED_FLAG_VCPU_YIELD
+    if ( test_bit(CSCHED_FLAG_VCPU_YIELD, &svc->flags)
          && __runq_elem(iter)->pri > CSCHED_PRI_IDLE )
     {
         iter=iter->next;
@@ -811,7 +811,7 @@ csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
      * those.
      */
     if ( svc->pri == CSCHED_PRI_TS_UNDER &&
-         !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
+         !test_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
     {
         svc->pri = CSCHED_PRI_TS_BOOST;
     }
@@ -824,10 +824,10 @@ csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
 static void
 csched_vcpu_yield(const struct scheduler *ops, struct vcpu *vc)
 {
-    struct csched_vcpu * const sv = CSCHED_VCPU(vc);
+    struct csched_vcpu * const svc = CSCHED_VCPU(vc);
 
     /* Let the scheduler know that this vcpu is trying to yield */
-    sv->flags |= CSCHED_FLAG_VCPU_YIELD;
+    set_bit(CSCHED_FLAG_VCPU_YIELD, &svc->flags);
 }
 
 static int
@@ -1151,11 +1151,10 @@ csched_acct(void* dummy)
                 /* Park running VCPUs of capped-out domains */
                 if ( sdom->cap != 0U &&
                      credit < -credit_cap &&
-                     !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
+                     !test_and_set_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
                 {
                     SCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
-                    svc->flags |= CSCHED_FLAG_VCPU_PARKED;
                 }
 
                 /* Lower bound on credits */
@@ -1171,7 +1170,7 @@ csched_acct(void* dummy)
                 svc->pri = CSCHED_PRI_TS_UNDER;
 
                 /* Unpark any capped domains whose credits go positive */
-                if ( svc->flags & CSCHED_FLAG_VCPU_PARKED)
+                if ( test_and_clear_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
                 {
                     /*
                      * It's important to unset the flag AFTER the unpause()
@@ -1180,7 +1179,6 @@ csched_acct(void* dummy)
                      */
                     SCHED_STAT_CRANK(vcpu_unpark);
                     vcpu_unpause(svc->vcpu);
-                    svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
                 }
 
                 /* Upper bound on credits means VCPU stops earning */
@@ -1442,8 +1440,7 @@ csched_schedule(
     /*
      * Clear YIELD flag before scheduling out
      */
-    if ( scurr->flags & CSCHED_FLAG_VCPU_YIELD )
-        scurr->flags &= ~(CSCHED_FLAG_VCPU_YIELD);
+    clear_bit(CSCHED_FLAG_VCPU_YIELD, &scurr->flags);
 
     /*
      * SMP Load balance:
-- 
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 Wed Feb 27 14:45:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFh-0008Cj-0n; Wed, 27 Feb 2013 14:45:01 +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 1UAiFf-0008CF-V2
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:00 +0000
Received: from [85.158.138.51:59387] by server-9.bemta-3.messagelabs.com id
	10/50-32531-9EB1E215; Wed, 27 Feb 2013 14:44:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5046 invoked from network); 27 Feb 2013 14:44:56 -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 Feb 2013 14:44:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994537"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:37 -0500
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 1UAi6C-0007HD-Mq;
	Wed, 27 Feb 2013 14:35:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:27:15 +0000
Message-ID: <1361975235-27701-2-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361975235-27701-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1361975235-27701-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Don't bother subtracting the residual from the runtime, as it can only ever
add up to one nanosecond, and will end up being debited during the next
reset interval anyway.

Original-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 804049e..a7bd2ee 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
 
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue */
-    int max_weight;
+    unsigned int max_weight;
 
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
 
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
 
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -271,11 +272,19 @@ struct csched_dom {
 
 /*
  * Time-to-credit, credit-to-time.
+ * 
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
+                          struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val = time * rqd->max_weight + svc->residual;
+
+    svc->residual = do_div(val, svc->weight);
+    svc->credit -= val;
 }
 
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
@@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t
     delta = now - svc->start_time;
 
     if ( delta > 0 ) {
-        /* This will round down; should we consider rounding up...? */
-        svc->credit -= t2c(rqd, delta, svc);
+        t2c_update(rqd, delta, svc);
         svc->start_time = now;
 
         d2printk("b d%dv%d c%d\n",
-- 
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 Wed Feb 27 14:45:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFh-0008Cj-0n; Wed, 27 Feb 2013 14:45:01 +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 1UAiFf-0008CF-V2
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:00 +0000
Received: from [85.158.138.51:59387] by server-9.bemta-3.messagelabs.com id
	10/50-32531-9EB1E215; Wed, 27 Feb 2013 14:44:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5046 invoked from network); 27 Feb 2013 14:44:56 -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 Feb 2013 14:44:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994537"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:37 -0500
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 1UAi6C-0007HD-Mq;
	Wed, 27 Feb 2013 14:35:12 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 14:27:15 +0000
Message-ID: <1361975235-27701-2-git-send-email-george.dunlap@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1361975235-27701-1-git-send-email-george.dunlap@eu.citrix.com>
References: <1361975235-27701-1-git-send-email-george.dunlap@eu.citrix.com>
MIME-Version: 1.0
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 2/2] credit2: track residual from divisions done
	during accounting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 help with under-accounting of vCPU-s running for extremly
short periods of time, but becoming runnable again at a high frequency.

Don't bother subtracting the residual from the runtime, as it can only ever
add up to one nanosecond, and will end up being debited during the next
reset interval anyway.

Original-patch-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 xen/common/sched_credit2.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 804049e..a7bd2ee 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -21,7 +21,7 @@
 #include <xen/perfc.h>
 #include <xen/sched-if.h>
 #include <xen/softirq.h>
-#include <asm/atomic.h>
+#include <asm/div64.h>
 #include <xen/errno.h>
 #include <xen/trace.h>
 #include <xen/cpu.h>
@@ -205,7 +205,7 @@ struct csched_runqueue_data {
 
     struct list_head runq; /* Ordered list of runnable vms */
     struct list_head svc;  /* List of all vcpus assigned to this runqueue */
-    int max_weight;
+    unsigned int max_weight;
 
     cpumask_t idle,        /* Currently idle */
         tickled;           /* Another cpu in the queue is already targeted for this one */
@@ -244,7 +244,8 @@ struct csched_vcpu {
     struct csched_dom *sdom;
     struct vcpu *vcpu;
 
-    int weight;
+    unsigned int weight;
+    unsigned int residual;
 
     int credit;
     s_time_t start_time; /* When we were scheduled (used for credit) */
@@ -271,11 +272,19 @@ struct csched_dom {
 
 /*
  * Time-to-credit, credit-to-time.
+ * 
+ * We keep track of the "residual" time to make sure that frequent short
+ * schedules still get accounted for in the end.
+ *
  * FIXME: Do pre-calculated division?
  */
-static s_time_t t2c(struct csched_runqueue_data *rqd, s_time_t time, struct csched_vcpu *svc)
+static void t2c_update(struct csched_runqueue_data *rqd, s_time_t time,
+                          struct csched_vcpu *svc)
 {
-    return time * rqd->max_weight / svc->weight;
+    uint64_t val = time * rqd->max_weight + svc->residual;
+
+    svc->residual = do_div(val, svc->weight);
+    svc->credit -= val;
 }
 
 static s_time_t c2t(struct csched_runqueue_data *rqd, s_time_t credit, struct csched_vcpu *svc)
@@ -636,8 +645,7 @@ void burn_credits(struct csched_runqueue_data *rqd, struct csched_vcpu *svc, s_t
     delta = now - svc->start_time;
 
     if ( delta > 0 ) {
-        /* This will round down; should we consider rounding up...? */
-        svc->credit -= t2c(rqd, delta, svc);
+        t2c_update(rqd, delta, svc);
         svc->start_time = now;
 
         d2printk("b d%dv%d c%d\n",
-- 
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 Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFi-0008Dk-V8; Wed, 27 Feb 2013 14:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFg-0008CZ-VO
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:01 +0000
Received: from [85.158.138.51:59695] by server-4.bemta-3.messagelabs.com id
	07/D1-21470-BEB1E215; Wed, 27 Feb 2013 14:44:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18489 invoked from network); 27 Feb 2013 14:44:58 -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;
	27 Feb 2013 14:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503783"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:57 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-9E;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:54 +0000
Message-ID: <1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Affected files:
* event_channel.c
* sched.h
* event.h
* xen.h

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   16 ++++++++--------
 xen/include/public/xen.h   |   22 +++++++++++-----------
 xen/include/xen/event.h    |    4 ++--
 xen/include/xen/sched.h    |    6 +++---
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 2d7afc9..9231eb0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1,15 +1,15 @@
 /******************************************************************************
  * event_channel.c
- * 
+ *
  * Event notifications from VIRQs, PIRQs, and other domains.
- * 
+ *
  * Copyright (c) 2003-2006, K A Fraser.
- * 
+ *
  * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
@@ -238,7 +238,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
     lchn->u.interdomain.remote_dom  = rd;
     lchn->u.interdomain.remote_port = (u16)rport;
     lchn->state                     = ECS_INTERDOMAIN;
-    
+
     rchn->u.interdomain.remote_dom  = ld;
     rchn->u.interdomain.remote_port = (u16)lport;
     rchn->state                     = ECS_INTERDOMAIN;
@@ -255,7 +255,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
     spin_unlock(&ld->event_lock);
     if ( ld != rd )
         spin_unlock(&rd->event_lock);
-    
+
     rcu_unlock_domain(rd);
 
     return rc;
@@ -633,7 +633,7 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     {
         vcpu_mark_events_pending(v);
     }
-    
+
     /* Check if some VCPU might be polling for this event. */
     if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
         return;
@@ -930,7 +930,7 @@ int evtchn_unmask(unsigned int port)
 
     /*
      * These operations must happen in strict order. Based on
-     * include/xen/event.h:evtchn_set_pending(). 
+     * include/xen/event.h:evtchn_set_pending().
      */
     if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
          test_bit          (port, &shared_info(d, evtchn_pending)) &&
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 99c8212..87380e6 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -1,8 +1,8 @@
 /******************************************************************************
  * xen.h
- * 
+ *
  * Guest OS interface to Xen.
- * 
+ *
  * 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
@@ -137,11 +137,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_dom0_op __HYPERVISOR_platform_op
 #endif
 
-/* 
+/*
  * VIRTUAL INTERRUPTS
- * 
+ *
  * Virtual interrupts that a guest OS may receive from Xen.
- * 
+ *
  * In the side comments, 'V.' denotes a per-VCPU VIRQ while 'G.' denotes a
  * global VIRQ. The former can be bound once per VCPU and cannot be re-bound.
  * The latter can be allocated only once per guest: they must initially be
@@ -190,7 +190,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *                     (x) encodes the PFD as follows:
  *                     x == 0 => PFD == DOMID_SELF
  *                     x != 0 => PFD == x - 1
- * 
+ *
  * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
  * -------------
  * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
@@ -236,13 +236,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * To deallocate the pages, the operations are the reverse of the steps
  * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
  * pagetable MUST not be in use (meaning that the cr3 is not set to it).
- * 
+ *
  * ptr[1:0] == MMU_MACHPHYS_UPDATE:
  * Updates an entry in the machine->pseudo-physical mapping table.
  * ptr[:2]  -- Machine address within the frame whose mapping to modify.
  *             The frame must belong to the FD, if one is specified.
  * val      -- Value to write into the mapping entry.
- * 
+ *
  * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
@@ -588,7 +588,7 @@ typedef struct vcpu_time_info vcpu_time_info_t;
 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 
+     * 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
@@ -646,7 +646,7 @@ struct shared_info {
      *  3. Virtual interrupts ('events'). A domain can bind an event-channel
      *     port to a virtual interrupt source, such as the virtual-timer
      *     device or the emergency console.
-     * 
+     *
      * Event channels are addressed by a "port index". Each channel is
      * associated with two bits of information:
      *  1. PENDING -- notifies the domain that there is a pending notification
@@ -657,7 +657,7 @@ struct shared_info {
      *     becomes pending while the channel is masked then the 'edge' is lost
      *     (i.e., when the channel is unmasked, the guest must manually handle
      *     pending notifications as no upcall will be scheduled by Xen).
-     * 
+     *
      * To expedite scanning of pending notifications, any 0->1 pending
      * transition on an unmasked channel causes a corresponding bit in a
      * per-vcpu selector word to be set. Each bit in the selector covers a
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..65ac81a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -1,8 +1,8 @@
 /******************************************************************************
  * event.h
- * 
+ *
  * A nice interface for passing asynchronous events to guest OSes.
- * 
+ *
  * Copyright (c) 2002-2006, K A Fraser
  */
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ba0f2f8..f6846d4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -92,7 +92,7 @@ void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
 
 struct waitqueue_vcpu;
 
-struct vcpu 
+struct vcpu
 {
     int              vcpu_id;
 
@@ -453,7 +453,7 @@ struct domain *domain_create(
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
  * This is the preferred function if the returned domain reference
- * is short lived,  but it cannot be used if the domain reference needs 
+ * is short lived,  but it cannot be used if the domain reference needs
  * to be kept beyond the current scope (e.g., across a softirq).
  * The returned domain reference must be discarded using rcu_unlock_domain().
  */
@@ -574,7 +574,7 @@ void sync_local_execstate(void);
  * sync_vcpu_execstate() will switch and commit @prev's state.
  */
 void context_switch(
-    struct vcpu *prev, 
+    struct vcpu *prev,
     struct vcpu *next);
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFi-0008Dk-V8; Wed, 27 Feb 2013 14:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFg-0008CZ-VO
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:01 +0000
Received: from [85.158.138.51:59695] by server-4.bemta-3.messagelabs.com id
	07/D1-21470-BEB1E215; Wed, 27 Feb 2013 14:44:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361976280!29403880!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18489 invoked from network); 27 Feb 2013 14:44:58 -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;
	27 Feb 2013 14:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9503783"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:57 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-9E;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:54 +0000
Message-ID: <1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Affected files:
* event_channel.c
* sched.h
* event.h
* xen.h

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   16 ++++++++--------
 xen/include/public/xen.h   |   22 +++++++++++-----------
 xen/include/xen/event.h    |    4 ++--
 xen/include/xen/sched.h    |    6 +++---
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 2d7afc9..9231eb0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1,15 +1,15 @@
 /******************************************************************************
  * event_channel.c
- * 
+ *
  * Event notifications from VIRQs, PIRQs, and other domains.
- * 
+ *
  * Copyright (c) 2003-2006, K A Fraser.
- * 
+ *
  * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
@@ -238,7 +238,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
     lchn->u.interdomain.remote_dom  = rd;
     lchn->u.interdomain.remote_port = (u16)rport;
     lchn->state                     = ECS_INTERDOMAIN;
-    
+
     rchn->u.interdomain.remote_dom  = ld;
     rchn->u.interdomain.remote_port = (u16)lport;
     rchn->state                     = ECS_INTERDOMAIN;
@@ -255,7 +255,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
     spin_unlock(&ld->event_lock);
     if ( ld != rd )
         spin_unlock(&rd->event_lock);
-    
+
     rcu_unlock_domain(rd);
 
     return rc;
@@ -633,7 +633,7 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     {
         vcpu_mark_events_pending(v);
     }
-    
+
     /* Check if some VCPU might be polling for this event. */
     if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
         return;
@@ -930,7 +930,7 @@ int evtchn_unmask(unsigned int port)
 
     /*
      * These operations must happen in strict order. Based on
-     * include/xen/event.h:evtchn_set_pending(). 
+     * include/xen/event.h:evtchn_set_pending().
      */
     if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
          test_bit          (port, &shared_info(d, evtchn_pending)) &&
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 99c8212..87380e6 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -1,8 +1,8 @@
 /******************************************************************************
  * xen.h
- * 
+ *
  * Guest OS interface to Xen.
- * 
+ *
  * 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
@@ -137,11 +137,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_dom0_op __HYPERVISOR_platform_op
 #endif
 
-/* 
+/*
  * VIRTUAL INTERRUPTS
- * 
+ *
  * Virtual interrupts that a guest OS may receive from Xen.
- * 
+ *
  * In the side comments, 'V.' denotes a per-VCPU VIRQ while 'G.' denotes a
  * global VIRQ. The former can be bound once per VCPU and cannot be re-bound.
  * The latter can be allocated only once per guest: they must initially be
@@ -190,7 +190,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *                     (x) encodes the PFD as follows:
  *                     x == 0 => PFD == DOMID_SELF
  *                     x != 0 => PFD == x - 1
- * 
+ *
  * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
  * -------------
  * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
@@ -236,13 +236,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * To deallocate the pages, the operations are the reverse of the steps
  * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
  * pagetable MUST not be in use (meaning that the cr3 is not set to it).
- * 
+ *
  * ptr[1:0] == MMU_MACHPHYS_UPDATE:
  * Updates an entry in the machine->pseudo-physical mapping table.
  * ptr[:2]  -- Machine address within the frame whose mapping to modify.
  *             The frame must belong to the FD, if one is specified.
  * val      -- Value to write into the mapping entry.
- * 
+ *
  * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
@@ -588,7 +588,7 @@ typedef struct vcpu_time_info vcpu_time_info_t;
 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 
+     * 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
@@ -646,7 +646,7 @@ struct shared_info {
      *  3. Virtual interrupts ('events'). A domain can bind an event-channel
      *     port to a virtual interrupt source, such as the virtual-timer
      *     device or the emergency console.
-     * 
+     *
      * Event channels are addressed by a "port index". Each channel is
      * associated with two bits of information:
      *  1. PENDING -- notifies the domain that there is a pending notification
@@ -657,7 +657,7 @@ struct shared_info {
      *     becomes pending while the channel is masked then the 'edge' is lost
      *     (i.e., when the channel is unmasked, the guest must manually handle
      *     pending notifications as no upcall will be scheduled by Xen).
-     * 
+     *
      * To expedite scanning of pending notifications, any 0->1 pending
      * transition on an unmasked channel causes a corresponding bit in a
      * per-vcpu selector word to be set. Each bit in the selector covers a
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..65ac81a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -1,8 +1,8 @@
 /******************************************************************************
  * event.h
- * 
+ *
  * A nice interface for passing asynchronous events to guest OSes.
- * 
+ *
  * Copyright (c) 2002-2006, K A Fraser
  */
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ba0f2f8..f6846d4 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -92,7 +92,7 @@ void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
 
 struct waitqueue_vcpu;
 
-struct vcpu 
+struct vcpu
 {
     int              vcpu_id;
 
@@ -453,7 +453,7 @@ struct domain *domain_create(
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
  * This is the preferred function if the returned domain reference
- * is short lived,  but it cannot be used if the domain reference needs 
+ * is short lived,  but it cannot be used if the domain reference needs
  * to be kept beyond the current scope (e.g., across a softirq).
  * The returned domain reference must be discarded using rcu_unlock_domain().
  */
@@ -574,7 +574,7 @@ void sync_local_execstate(void);
  * sync_vcpu_execstate() will switch and commit @prev's state.
  */
 void context_switch(
-    struct vcpu *prev, 
+    struct vcpu *prev,
     struct vcpu *next);
 
 /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFo-0008HG-7l; Wed, 27 Feb 2013 14:45:08 +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 1UAiFl-0008Fa-Si
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:06 +0000
Received: from [85.158.139.83:6939] by server-1.bemta-5.messagelabs.com id
	9D/6C-14063-1FB1E215; Wed, 27 Feb 2013 14:45:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361976300!27463387!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8351 invoked from network); 27 Feb 2013 14:45:02 -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;
	27 Feb 2013 14:45:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994672"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:45:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:59 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-8f;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:53 +0000
Message-ID: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 all

This is another version of the patch series. Unfortunately the kernel side is
not available at the moment. :-(

Keir, Jan, Ian and David, are you happy with this design in general? I would
like to have explicit ACK / NACK on this if possible, as feature freeze for 4.3
is quite close now.

Changes since V2:
* new interface to register extended event channel ABI
* use vmap to simplify mapping
* replace MAX_EVTCHNS macro with inline function
* libxl: evtchn_l3 -> evtchn_extended

The most notable bit of this series is the interface change. In order to cope
with future ABIs, the interface is renamed to EVTCHNOP_register_extended. It
also provides supported ABI query, so that we can remove unused ABI in the
future.

The semantic meaning of EVTCHNOP_register_extended changes a bit. The `level'
in parameter now changes to `cmd', which means we should go down to specific
ABI routines. ABI-specific structures are still embedded in the union.

Changes since V1:
* move all evtchn related macros / struct definitions to event.h
* only allow 3-level evtchn for Dom0 and driver domains
* add evtchn_l3 flag in libxl


Wei.

Diffstat:
 tools/libxl/libxl_create.c         |    4 +
 tools/libxl/libxl_types.idl        |    1 +
 tools/libxl/xl_cmdimpl.c           |    2 +
 tools/libxl/xl_sxp.c               |    2 +
 xen/arch/arm/domain.c              |    1 +
 xen/arch/x86/domain.c              |    1 +
 xen/arch/x86/irq.c                 |    7 +-
 xen/common/domain.c                |    3 +
 xen/common/domctl.c                |    5 +-
 xen/common/event_channel.c         |  458 +++++++++++++++++++++++++++++++++---
 xen/common/keyhandler.c            |    6 +-
 xen/common/schedule.c              |    4 +-
 xen/include/asm-arm/types.h        |    7 +-
 xen/include/asm-x86/config.h       |    4 +-
 xen/include/public/domctl.h        |    3 +
 xen/include/public/event_channel.h |   44 ++++
 xen/include/public/xen.h           |   35 ++-
 xen/include/xen/event.h            |   85 ++++++-
 xen/include/xen/sched.h            |   65 ++---
 xen/xsm/flask/hooks.c              |    1 +
 20 files changed, 623 insertions(+), 115 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFl-0008FZ-B6; Wed, 27 Feb 2013 14:45:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFh-0008D2-OP
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:01 +0000
Received: from [85.158.138.51:59296] by server-6.bemta-3.messagelabs.com id
	ED/EB-11048-8EB1E215; Wed, 27 Feb 2013 14:44:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4952 invoked from network); 27 Feb 2013 14:44:55 -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 Feb 2013 14:44:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994567"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:48 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-HP;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:59 +0000
Message-ID: <1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
	registration 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

This interface allows user to query supported event channel types. If we need
to disable a specific ABI in the future, we just need to remove the dead code
and clear corresponding feature bit.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/public/event_channel.h |   44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
index 07ff321..dff3364 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -71,6 +71,7 @@
 #define EVTCHNOP_bind_vcpu        8
 #define EVTCHNOP_unmask           9
 #define EVTCHNOP_reset           10
+#define EVTCHNOP_register_extended 11
 /* ` } */
 
 typedef uint32_t evtchn_port_t;
@@ -258,6 +259,49 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
+ * EVTCHNOP_register_extended: Register extended event channel
+ * NOTES:
+ *  1. Currently only 3-level is supported.
+ *  2. Should fall back to 2-level if this call fails.
+ */
+/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
+ * 256k event channels while 32 bit ones only need 1 page for 32k
+ * event channels. */
+#define EVTCHN_MAX_L3_PAGES 8
+struct evtchn_register_3level {
+    /* IN parameters. */
+    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
+    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
+};
+typedef struct evtchn_register_3level evtchn_register_3level_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_3level_t);
+
+/* commands:
+ * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
+ *                _NONE      supported types are or'ed in return value of
+ *                           the hypercall.
+ * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
+ */
+#define EVTCHN_EXTENDED_QUERY 0
+/* supported extended event channel */
+#define EVTCHN_EXTENDED_NONE  0
+#define _EVTCHN_EXTENDED_L3   0
+#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
+struct evtchn_register_extended {
+    /* IN parameters. */
+    uint32_t cmd;
+    union {
+        evtchn_register_3level_t l3;
+    } u;
+};
+typedef struct evtchn_register_extended evtchn_register_extended_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_extended_t);
+
+/*
  * ` enum neg_errnoval
  * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
  * `
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFo-0008HG-7l; Wed, 27 Feb 2013 14:45:08 +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 1UAiFl-0008Fa-Si
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:06 +0000
Received: from [85.158.139.83:6939] by server-1.bemta-5.messagelabs.com id
	9D/6C-14063-1FB1E215; Wed, 27 Feb 2013 14:45:05 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1361976300!27463387!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8351 invoked from network); 27 Feb 2013 14:45:02 -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;
	27 Feb 2013 14:45:02 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994672"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:45:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:59 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-8f;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:53 +0000
Message-ID: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
MIME-Version: 1.0
Cc: david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 all

This is another version of the patch series. Unfortunately the kernel side is
not available at the moment. :-(

Keir, Jan, Ian and David, are you happy with this design in general? I would
like to have explicit ACK / NACK on this if possible, as feature freeze for 4.3
is quite close now.

Changes since V2:
* new interface to register extended event channel ABI
* use vmap to simplify mapping
* replace MAX_EVTCHNS macro with inline function
* libxl: evtchn_l3 -> evtchn_extended

The most notable bit of this series is the interface change. In order to cope
with future ABIs, the interface is renamed to EVTCHNOP_register_extended. It
also provides supported ABI query, so that we can remove unused ABI in the
future.

The semantic meaning of EVTCHNOP_register_extended changes a bit. The `level'
in parameter now changes to `cmd', which means we should go down to specific
ABI routines. ABI-specific structures are still embedded in the union.

Changes since V1:
* move all evtchn related macros / struct definitions to event.h
* only allow 3-level evtchn for Dom0 and driver domains
* add evtchn_l3 flag in libxl


Wei.

Diffstat:
 tools/libxl/libxl_create.c         |    4 +
 tools/libxl/libxl_types.idl        |    1 +
 tools/libxl/xl_cmdimpl.c           |    2 +
 tools/libxl/xl_sxp.c               |    2 +
 xen/arch/arm/domain.c              |    1 +
 xen/arch/x86/domain.c              |    1 +
 xen/arch/x86/irq.c                 |    7 +-
 xen/common/domain.c                |    3 +
 xen/common/domctl.c                |    5 +-
 xen/common/event_channel.c         |  458 +++++++++++++++++++++++++++++++++---
 xen/common/keyhandler.c            |    6 +-
 xen/common/schedule.c              |    4 +-
 xen/include/asm-arm/types.h        |    7 +-
 xen/include/asm-x86/config.h       |    4 +-
 xen/include/public/domctl.h        |    3 +
 xen/include/public/event_channel.h |   44 ++++
 xen/include/public/xen.h           |   35 ++-
 xen/include/xen/event.h            |   85 ++++++-
 xen/include/xen/sched.h            |   65 ++---
 xen/xsm/flask/hooks.c              |    1 +
 20 files changed, 623 insertions(+), 115 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFl-0008FZ-B6; Wed, 27 Feb 2013 14:45:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFh-0008D2-OP
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:01 +0000
Received: from [85.158.138.51:59296] by server-6.bemta-3.messagelabs.com id
	ED/EB-11048-8EB1E215; Wed, 27 Feb 2013 14:44:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4952 invoked from network); 27 Feb 2013 14:44:55 -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 Feb 2013 14:44:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994567"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:48 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-HP;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:59 +0000
Message-ID: <1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
	registration 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

This interface allows user to query supported event channel types. If we need
to disable a specific ABI in the future, we just need to remove the dead code
and clear corresponding feature bit.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/public/event_channel.h |   44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
index 07ff321..dff3364 100644
--- a/xen/include/public/event_channel.h
+++ b/xen/include/public/event_channel.h
@@ -71,6 +71,7 @@
 #define EVTCHNOP_bind_vcpu        8
 #define EVTCHNOP_unmask           9
 #define EVTCHNOP_reset           10
+#define EVTCHNOP_register_extended 11
 /* ` } */
 
 typedef uint32_t evtchn_port_t;
@@ -258,6 +259,49 @@ struct evtchn_reset {
 typedef struct evtchn_reset evtchn_reset_t;
 
 /*
+ * EVTCHNOP_register_extended: Register extended event channel
+ * NOTES:
+ *  1. Currently only 3-level is supported.
+ *  2. Should fall back to 2-level if this call fails.
+ */
+/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
+ * 256k event channels while 32 bit ones only need 1 page for 32k
+ * event channels. */
+#define EVTCHN_MAX_L3_PAGES 8
+struct evtchn_register_3level {
+    /* IN parameters. */
+    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
+    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
+    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
+    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
+};
+typedef struct evtchn_register_3level evtchn_register_3level_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_3level_t);
+
+/* commands:
+ * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
+ *                _NONE      supported types are or'ed in return value of
+ *                           the hypercall.
+ * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
+ */
+#define EVTCHN_EXTENDED_QUERY 0
+/* supported extended event channel */
+#define EVTCHN_EXTENDED_NONE  0
+#define _EVTCHN_EXTENDED_L3   0
+#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
+struct evtchn_register_extended {
+    /* IN parameters. */
+    uint32_t cmd;
+    union {
+        evtchn_register_3level_t l3;
+    } u;
+};
+typedef struct evtchn_register_extended evtchn_register_extended_t;
+DEFINE_XEN_GUEST_HANDLE(evtchn_register_extended_t);
+
+/*
  * ` enum neg_errnoval
  * ` HYPERVISOR_event_channel_op_compat(struct evtchn_op *op)
  * `
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFq-0008JQ-Lj; Wed, 27 Feb 2013 14:45:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFp-0008EX-4D
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:09 +0000
Received: from [85.158.138.51:21153] by server-12.bemta-3.messagelabs.com id
	F1/7F-01357-9EB1E215; Wed, 27 Feb 2013 14:44:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5109 invoked from network); 27 Feb 2013 14:44:57 -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 Feb 2013 14:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994611"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Dc;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:57 +0000
Message-ID: <1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 04/22] flask: include xen/event.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

Some definitions for event channel have been moved to new header file.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/xsm/flask/hooks.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 29a78dd..6d446ab 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -11,6 +11,7 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/sched.h>
+#include <xen/event.h>
 #include <xen/paging.h>
 #include <xen/xmalloc.h>
 #include <xsm/xsm.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFq-0008JQ-Lj; Wed, 27 Feb 2013 14:45:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFp-0008EX-4D
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:09 +0000
Received: from [85.158.138.51:21153] by server-12.bemta-3.messagelabs.com id
	F1/7F-01357-9EB1E215; Wed, 27 Feb 2013 14:44:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5109 invoked from network); 27 Feb 2013 14:44:57 -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 Feb 2013 14:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994611"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Dc;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:57 +0000
Message-ID: <1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 04/22] flask: include xen/event.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

Some definitions for event channel have been moved to new header file.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/xsm/flask/hooks.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 29a78dd..6d446ab 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -11,6 +11,7 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/sched.h>
+#include <xen/event.h>
 #include <xen/paging.h>
 #include <xen/xmalloc.h>
 #include <xsm/xsm.h>
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFl-0008Fr-Nl; Wed, 27 Feb 2013 14:45:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFk-0008EJ-0Y
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:04 +0000
Received: from [85.158.138.51:59557] by server-16.bemta-3.messagelabs.com id
	0E/BB-20692-AEB1E215; Wed, 27 Feb 2013 14:44:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5166 invoked from network); 27 Feb 2013 14:44:57 -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 Feb 2013 14:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994652"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:56 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-B9;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:55 +0000
Message-ID: <1361975655-22295-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 02/22] Dynamically allocate d->evtchn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 we move to N level evtchn we need bigger d->evtchn, as a result
this will bloat struct domain. So move this array out of struct domain
and allocate a dedicated page for it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   17 +++++++++++++++--
 xen/include/xen/sched.h    |    2 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9231eb0..3293f91 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1172,15 +1172,26 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
 
 int evtchn_init(struct domain *d)
 {
+    BUILD_BUG_ON(sizeof(struct evtchn *) * NR_EVTCHN_BUCKETS > PAGE_SIZE);
+    d->evtchn = alloc_xenheap_page();
+
+    if ( d->evtchn == NULL )
+        return -ENOMEM;
+    clear_page(d->evtchn);
+
     spin_lock_init(&d->event_lock);
-    if ( get_free_port(d) != 0 )
+    if ( get_free_port(d) != 0 ) {
+        free_xenheap_page(d->evtchn);
         return -EINVAL;
+    }
     evtchn_from_port(d, 0)->state = ECS_RESERVED;
 
 #if MAX_VIRT_CPUS > BITS_PER_LONG
     d->poll_mask = xmalloc_array(unsigned long, BITS_TO_LONGS(MAX_VIRT_CPUS));
-    if ( !d->poll_mask )
+    if ( !d->poll_mask ) {
+        free_xenheap_page(d->evtchn);
         return -ENOMEM;
+    }
     bitmap_zero(d->poll_mask, MAX_VIRT_CPUS);
 #endif
 
@@ -1214,6 +1225,8 @@ void evtchn_destroy(struct domain *d)
     spin_unlock(&d->event_lock);
 
     clear_global_virq_handlers(d);
+
+    free_xenheap_page(d->evtchn);
 }
 
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index f6846d4..812bd87 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -260,7 +260,7 @@ struct domain
     spinlock_t       rangesets_lock;
 
     /* Event channel information. */
-    struct evtchn   *evtchn[NR_EVTCHN_BUCKETS];
+    struct evtchn  **evtchn;
     spinlock_t       event_lock;
 
     struct grant_table *grant_table;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 14:45:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 14:45: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 1UAiFl-0008Fr-Nl; Wed, 27 Feb 2013 14:45:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiFk-0008EJ-0Y
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:45:04 +0000
Received: from [85.158.138.51:59557] by server-16.bemta-3.messagelabs.com id
	0E/BB-20692-AEB1E215; Wed, 27 Feb 2013 14:44:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1361976290!19737767!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5166 invoked from network); 27 Feb 2013 14:44:57 -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 Feb 2013 14:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9994652"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 14:44:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 09:44:56 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-B9;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:33:55 +0000
Message-ID: <1361975655-22295-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 02/22] Dynamically allocate d->evtchn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 we move to N level evtchn we need bigger d->evtchn, as a result
this will bloat struct domain. So move this array out of struct domain
and allocate a dedicated page for it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   17 +++++++++++++++--
 xen/include/xen/sched.h    |    2 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9231eb0..3293f91 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1172,15 +1172,26 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
 
 int evtchn_init(struct domain *d)
 {
+    BUILD_BUG_ON(sizeof(struct evtchn *) * NR_EVTCHN_BUCKETS > PAGE_SIZE);
+    d->evtchn = alloc_xenheap_page();
+
+    if ( d->evtchn == NULL )
+        return -ENOMEM;
+    clear_page(d->evtchn);
+
     spin_lock_init(&d->event_lock);
-    if ( get_free_port(d) != 0 )
+    if ( get_free_port(d) != 0 ) {
+        free_xenheap_page(d->evtchn);
         return -EINVAL;
+    }
     evtchn_from_port(d, 0)->state = ECS_RESERVED;
 
 #if MAX_VIRT_CPUS > BITS_PER_LONG
     d->poll_mask = xmalloc_array(unsigned long, BITS_TO_LONGS(MAX_VIRT_CPUS));
-    if ( !d->poll_mask )
+    if ( !d->poll_mask ) {
+        free_xenheap_page(d->evtchn);
         return -ENOMEM;
+    }
     bitmap_zero(d->poll_mask, MAX_VIRT_CPUS);
 #endif
 
@@ -1214,6 +1225,8 @@ void evtchn_destroy(struct domain *d)
     spin_unlock(&d->event_lock);
 
     clear_global_virq_handlers(d);
+
+    free_xenheap_page(d->evtchn);
 }
 
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index f6846d4..812bd87 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -260,7 +260,7 @@ struct domain
     spinlock_t       rangesets_lock;
 
     /* Event channel information. */
-    struct evtchn   *evtchn[NR_EVTCHN_BUCKETS];
+    struct evtchn  **evtchn;
     spinlock_t       event_lock;
 
     struct grant_table *grant_table;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:00:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAiUd-0001jJ-CX; Wed, 27 Feb 2013 15:00:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Sebastien.FREMAL@umons.ac.be>) id 1UAiRZ-0001gh-93
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:57:17 +0000
Received: from [85.158.139.83:64328] by server-1.bemta-5.messagelabs.com id
	97/13-14063-CCE1E215; Wed, 27 Feb 2013 14:57:16 +0000
X-Env-Sender: Sebastien.FREMAL@umons.ac.be
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361977035!22039824!1
X-Originating-IP: [193.190.208.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11810 invoked from network); 27 Feb 2013 14:57:15 -0000
Received: from mx2.umons.ac.be (HELO TMGM2.umons.ac.be) (193.190.208.48)
	by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Feb 2013 14:57:15 -0000
Received: from EXCHANGEHUB1.umons.ac.be (10.104.2.76) by TMGM2.umons.ac.be
	(10.104.2.75) with Microsoft SMTP Server (TLS) id 14.2.328.9;
	Wed, 27 Feb 2013 15:57:04 +0100
Received: from EXCHANGEDB4.umons.ac.be ([fe80::945c:e368:d98c:ffc3]) by
	EXCHANGEHUB1.umons.ac.be ([fe80::4560:2353:66a9:907f%13]) with mapi id
	14.02.0328.009; Wed, 27 Feb 2013 15:57:03 +0100
From: =?iso-8859-1?Q?S=E9bastien_FREMAL_=5B530784=5D?=
	<Sebastien.FREMAL@umons.ac.be>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Mapping granted pages in the user space of a domU
Thread-Index: Ac4U+rNhA2odNNBcQhaaDbwWLNFuig==
Date: Wed, 27 Feb 2013 14:57:02 +0000
Message-ID: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>
Accept-Language: fr-BE, en-US
Content-Language: fr-BE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.2.63]
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 27 Feb 2013 15:00:26 +0000
Subject: [Xen-devel] Mapping granted pages in the user space of a 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I'm creating a communication channel between an application running in the =
dom0 and applications running in domU's. I mapped several pages of the kern=
el space of the dom0 in its user space (and this part works fine) and I gra=
nted the access to these pages to a domU. The module running in this domU s=
uccessfuly retrieves these pages and their content but I don't find how to =
map the pages in the user space.

I already tried several possibilities I found on the web :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

The code of the module :

#undef __KERNEL__
#define __KERNEL__

#undef MODULE
#define MODULE

#include <xen/grant_table.h>
#include <xen/page.h>
#include <asm/xen/hypercall.h>
#include <linux/gfp.h>
#include <linux/module.h>
#include <linux/vmalloc.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <asm/page.h>
#include <linux/delay.h>
#include <linux/time.h>
#include <linux/fs.h>
#include <linux/cdev.h>

MODULE_LICENSE("GPL");

// internal data
// length of the two memory areas
enum{NUM_ALLOC =3D 1};
enum{PAGES_PER_ALLOC =3D 4};

struct gnttab_map_grant_ref ops[NUM_ALLOC*PAGES_PER_ALLOC];
struct gnttab_unmap_grant_ref unmap_ops[NUM_ALLOC*PAGES_PER_ALLOC];
struct vm_struct * v_start;

static dev_t mmap_dev;
static struct cdev mmap_cdev;

static int mmap_open(struct inode * inode, struct file *filp);
static int mmap_release(struct inode * inode, struct file * filp);
static int mmap_mmap(struct file * filp, struct vm_area_struct *vma);

static struct file_operations mmap_fops =3D {
        .open =3D mmap_open,
        .release =3D mmap_release,
        .mmap =3D mmap_mmap,
        .owner =3D THIS_MODULE,
};


static int mmap_open(struct inode *inode, struct file * filp){
        printk(KERN_INFO "MMap_open invoked\n");
        return 0;
}

static int mmap_release(struct inode * inode, struct file * filp){
        printk(KERN_INFO "MMap_release invoked\n");
        return 0;
}

struct mmap_info{
	char * data;
	int reference;
};

static int mmap_mmap(struct file * filp, struct vm_area_struct * vma){
        int ret;
        size_t length =3D vma->vm_end - vma->vm_start;
        size_t num_pages =3D length/PAGE_SIZE;
        size_t i=3D0;;

        printk(KERN_INFO "Length : %lu, pages : %lu \n", length, length/PAG=
E_SIZE);

        if(length > NUM_ALLOC * PAGES_PER_ALLOC * PAGE_SIZE){
                printk("Request for a chunk of memory bigger than the avail=
able memory\n");
                return -EIO;
        }
      	=

	for(i=3D0;i<num_pages;++i){

                //FIRST ATTEMPT
		if((ret =3D remap_pfn_range(vma, =

					vma->vm_start+i*PAGE_SIZE,
					page_to_pfn(vmalloc_to_page(v_start->addr+i*PAGE_SIZE)),
					PAGE_SIZE,
					vma->vm_page_prot))<0){
			printk(KERN_INFO "Error in remap_pfn_range");
        		return ret;
        	}

/*		=

                //SECOND ATTEMPT
		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
		if((ret=3Dm2p_add_override(mfn, virt_to_page(vma->vm_start+i*PAGE_SIZE), =
NULL))>0){
			printk(KERN_INFO "Overriding failed\n");
			return ret;
		}
	        =

                //THIRD ATTEMPT
		struct mmap_info * info =3D (struct mmap_info *) filp->private_data;
		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
                if((ret=3Dm2p_add_override(mfn, virt_to_page(info->data+i*P=
AGE_SIZE), NULL))>0){
                        printk(KERN_INFO "Overriding failed\n");
                        return ret;
                }
                =

                //FOURTH ATTEMPT
                if((ret =3D remap_vmalloc_range(vma, v_start->addr, 0))<0){
                       printk(KERN_INFO "Error in remap_vmalloc_range");
                       return ret;
                }
*/
                printk(KERN_INFO "Page %lu mapped\n", i);
                printk(KERN_INFO "Content : %d - %d\n", *((int *)ops[i].hos=
t_addr), *((int *) v_start->addr));

	}

        printk(KERN_INFO "MMaped\n");

        return 0;
}

static int __init mapped_init(void){
        int i, ret;
       =

	printk(KERN_INFO "Using shared memory in Xen \n");

        if((ret =3D alloc_chrdev_region(&mmap_dev,0,1,"mmap"))<0){
                printk(KERN_INFO "Could not allocate major number for mmap\=
n");
                return ret;
        }

        cdev_init(&mmap_cdev, &mmap_fops);
        if((ret=3Dcdev_add(&mmap_cdev, mmap_dev, 1))<0){
                printk(KERN_INFO "Could not allocate chrdev for mmap\n");
                unregister_chrdev_region(mmap_dev, 1);
        	return ret;
	}

	v_start =3D alloc_vm_area(PAGE_SIZE*NUM_ALLOC*PAGES_PER_ALLOC,NULL);
	=

        if(v_start=3D=3D0){
                printk(KERN_INFO "Problem allocating vm area\n");
                return -EFAULT;
        }

        for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
		ops[i].flags =3D GNTMAP_host_map;
        	ops[i].ref =3D 8+i;
        	ops[i].dom =3D 0;
        	ops[i].host_addr =3D (unsigned long)(((char*) v_start->addr)+i*PAG=
E_SIZE);
	}

        if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ops, NUM_ALLOC=
*PAGES_PER_ALLOC)){
               	printk(KERN_INFO "Hypervisor map grant failed\n");
               	free_vm_area(v_start);
               	return -EFAULT;
       	}


	for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
		if(ops[i].status){
			printk(KERN_INFO "Hyper map grant failed with status %d\n", ops[i].statu=
s);
			free_vm_area(v_start);
			return -EFAULT;
        	}

		unmap_ops[i].host_addr =3D ops[i].host_addr;
		unmap_ops[i].handle =3D ops[i].handle;
		=

		printk(KERN_INFO "Number : %d\n", *((int *)ops[i].host_addr));
	}

        return 0;
}

static int  __exit mapped_exit(void){
	if(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, NUM_ALLO=
C*PAGES_PER_ALLOC))
                	printk("Error in unmapping operation\n");
        free_vm_area(v_start);
	printk("Mapping module cleaned\n");
	return 0;
}

module_init(mapped_init)
module_exit(mapped_exit)


Mapping :

int main(void)
{
  int fd;
  int *vadr;

  unsigned long len =3D getpagesize(), i;

  if ((fd=3Dopen("node", O_RDWR|O_SYNC))<0)
  {
      perror("open");
      exit(-1);
  }

  vadr =3D mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

  if (vadr =3D=3D MAP_FAILED)
  {
          perror("mmap");
          exit(-1);
  }
  =

  for(i=3D0;i<len/sizeof(int);i+=3D(getpagesize()/sizeof(int))){
          printf("%d\n",*(vadr+i));
          vadr[i]=3Dvadr[i]+1;
  }

  close(fd);
  return(0);

}

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

The first attempt doesn't indicate any error but I don't get the good page =
(I put the value "3" in the page but the application read the value 0).

The second attempt gives an error in the module :
[   86.071090] WARNING: at /build/buildd/linux-3.2.0/arch/x86/xen/p2m.c:696=
 m2p_add_override+0x7b/0x3c0()
[   86.071093] m2p_add_override: pfn f73ed13ae not mapped
[   86.071095] Modules linked in: shm13(O) lp parport
[   86.071101] Pid: 1324, comm: fill Tainted: G           O 3.2.0-34-generi=
c #53-Ubuntu
[   86.071103] Call Trace:
[   86.071110]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
[   86.071113]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
[   86.071116]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
[   86.071121]  [<ffffffff8164328c>] ? printk+0x51/0x53
[   86.071126]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
[   86.071129]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
[   86.071134]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
[   86.071137]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
[   86.071140]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
[   86.071143]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
[   86.071148]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
[   86.071153]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
[   86.071155] ---[ end trace ea7792ae1c43717f ]---

The third attempt gives me the same error in the module :
[  105.337927] WARNING: at /build/buildd/linux-3.2.0/arch/x86/xen/p2m.c:696=
 m2p_add_override+0x7b/0x3c0()
[  105.337929] m2p_add_override: pfn f78bba24c not mapped
[  105.337931] Modules linked in: shm13(O) lp parport
[  105.337937] Pid: 1201, comm: fill Tainted: G           O 3.2.0-34-generi=
c #53-Ubuntu
[  105.337939] Call Trace:
[  105.337946]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
[  105.337949]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
[  105.337952]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
[  105.337958]  [<ffffffff8164328c>] ? printk+0x51/0x53
[  105.337962]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
[  105.337965]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
[  105.337970]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
[  105.337973]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
[  105.337976]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
[  105.337979]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
[  105.337984]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
[  105.337989]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
[  105.337991] ---[ end trace 33b54c96a0c2933b ]---

The fourth attempt results in an error in the function called by the module=
 :
[   96.621242] Error in remap_vmalloc_range

I don't really know what to do to make it works, but I know than such a com=
munication channel is possible as people have already done it before.

Does someone know what is my mistake and how to correct it please ?

Best regards,

S=E9bastien Fr=E9mal
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:00:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAiUd-0001jJ-CX; Wed, 27 Feb 2013 15:00:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Sebastien.FREMAL@umons.ac.be>) id 1UAiRZ-0001gh-93
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 14:57:17 +0000
Received: from [85.158.139.83:64328] by server-1.bemta-5.messagelabs.com id
	97/13-14063-CCE1E215; Wed, 27 Feb 2013 14:57:16 +0000
X-Env-Sender: Sebastien.FREMAL@umons.ac.be
X-Msg-Ref: server-11.tower-182.messagelabs.com!1361977035!22039824!1
X-Originating-IP: [193.190.208.48]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11810 invoked from network); 27 Feb 2013 14:57:15 -0000
Received: from mx2.umons.ac.be (HELO TMGM2.umons.ac.be) (193.190.208.48)
	by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Feb 2013 14:57:15 -0000
Received: from EXCHANGEHUB1.umons.ac.be (10.104.2.76) by TMGM2.umons.ac.be
	(10.104.2.75) with Microsoft SMTP Server (TLS) id 14.2.328.9;
	Wed, 27 Feb 2013 15:57:04 +0100
Received: from EXCHANGEDB4.umons.ac.be ([fe80::945c:e368:d98c:ffc3]) by
	EXCHANGEHUB1.umons.ac.be ([fe80::4560:2353:66a9:907f%13]) with mapi id
	14.02.0328.009; Wed, 27 Feb 2013 15:57:03 +0100
From: =?iso-8859-1?Q?S=E9bastien_FREMAL_=5B530784=5D?=
	<Sebastien.FREMAL@umons.ac.be>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Mapping granted pages in the user space of a domU
Thread-Index: Ac4U+rNhA2odNNBcQhaaDbwWLNFuig==
Date: Wed, 27 Feb 2013 14:57:02 +0000
Message-ID: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>
Accept-Language: fr-BE, en-US
Content-Language: fr-BE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.2.63]
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 27 Feb 2013 15:00:26 +0000
Subject: [Xen-devel] Mapping granted pages in the user space of a 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I'm creating a communication channel between an application running in the =
dom0 and applications running in domU's. I mapped several pages of the kern=
el space of the dom0 in its user space (and this part works fine) and I gra=
nted the access to these pages to a domU. The module running in this domU s=
uccessfuly retrieves these pages and their content but I don't find how to =
map the pages in the user space.

I already tried several possibilities I found on the web :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

The code of the module :

#undef __KERNEL__
#define __KERNEL__

#undef MODULE
#define MODULE

#include <xen/grant_table.h>
#include <xen/page.h>
#include <asm/xen/hypercall.h>
#include <linux/gfp.h>
#include <linux/module.h>
#include <linux/vmalloc.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <asm/page.h>
#include <linux/delay.h>
#include <linux/time.h>
#include <linux/fs.h>
#include <linux/cdev.h>

MODULE_LICENSE("GPL");

// internal data
// length of the two memory areas
enum{NUM_ALLOC =3D 1};
enum{PAGES_PER_ALLOC =3D 4};

struct gnttab_map_grant_ref ops[NUM_ALLOC*PAGES_PER_ALLOC];
struct gnttab_unmap_grant_ref unmap_ops[NUM_ALLOC*PAGES_PER_ALLOC];
struct vm_struct * v_start;

static dev_t mmap_dev;
static struct cdev mmap_cdev;

static int mmap_open(struct inode * inode, struct file *filp);
static int mmap_release(struct inode * inode, struct file * filp);
static int mmap_mmap(struct file * filp, struct vm_area_struct *vma);

static struct file_operations mmap_fops =3D {
        .open =3D mmap_open,
        .release =3D mmap_release,
        .mmap =3D mmap_mmap,
        .owner =3D THIS_MODULE,
};


static int mmap_open(struct inode *inode, struct file * filp){
        printk(KERN_INFO "MMap_open invoked\n");
        return 0;
}

static int mmap_release(struct inode * inode, struct file * filp){
        printk(KERN_INFO "MMap_release invoked\n");
        return 0;
}

struct mmap_info{
	char * data;
	int reference;
};

static int mmap_mmap(struct file * filp, struct vm_area_struct * vma){
        int ret;
        size_t length =3D vma->vm_end - vma->vm_start;
        size_t num_pages =3D length/PAGE_SIZE;
        size_t i=3D0;;

        printk(KERN_INFO "Length : %lu, pages : %lu \n", length, length/PAG=
E_SIZE);

        if(length > NUM_ALLOC * PAGES_PER_ALLOC * PAGE_SIZE){
                printk("Request for a chunk of memory bigger than the avail=
able memory\n");
                return -EIO;
        }
      	=

	for(i=3D0;i<num_pages;++i){

                //FIRST ATTEMPT
		if((ret =3D remap_pfn_range(vma, =

					vma->vm_start+i*PAGE_SIZE,
					page_to_pfn(vmalloc_to_page(v_start->addr+i*PAGE_SIZE)),
					PAGE_SIZE,
					vma->vm_page_prot))<0){
			printk(KERN_INFO "Error in remap_pfn_range");
        		return ret;
        	}

/*		=

                //SECOND ATTEMPT
		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
		if((ret=3Dm2p_add_override(mfn, virt_to_page(vma->vm_start+i*PAGE_SIZE), =
NULL))>0){
			printk(KERN_INFO "Overriding failed\n");
			return ret;
		}
	        =

                //THIRD ATTEMPT
		struct mmap_info * info =3D (struct mmap_info *) filp->private_data;
		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
                if((ret=3Dm2p_add_override(mfn, virt_to_page(info->data+i*P=
AGE_SIZE), NULL))>0){
                        printk(KERN_INFO "Overriding failed\n");
                        return ret;
                }
                =

                //FOURTH ATTEMPT
                if((ret =3D remap_vmalloc_range(vma, v_start->addr, 0))<0){
                       printk(KERN_INFO "Error in remap_vmalloc_range");
                       return ret;
                }
*/
                printk(KERN_INFO "Page %lu mapped\n", i);
                printk(KERN_INFO "Content : %d - %d\n", *((int *)ops[i].hos=
t_addr), *((int *) v_start->addr));

	}

        printk(KERN_INFO "MMaped\n");

        return 0;
}

static int __init mapped_init(void){
        int i, ret;
       =

	printk(KERN_INFO "Using shared memory in Xen \n");

        if((ret =3D alloc_chrdev_region(&mmap_dev,0,1,"mmap"))<0){
                printk(KERN_INFO "Could not allocate major number for mmap\=
n");
                return ret;
        }

        cdev_init(&mmap_cdev, &mmap_fops);
        if((ret=3Dcdev_add(&mmap_cdev, mmap_dev, 1))<0){
                printk(KERN_INFO "Could not allocate chrdev for mmap\n");
                unregister_chrdev_region(mmap_dev, 1);
        	return ret;
	}

	v_start =3D alloc_vm_area(PAGE_SIZE*NUM_ALLOC*PAGES_PER_ALLOC,NULL);
	=

        if(v_start=3D=3D0){
                printk(KERN_INFO "Problem allocating vm area\n");
                return -EFAULT;
        }

        for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
		ops[i].flags =3D GNTMAP_host_map;
        	ops[i].ref =3D 8+i;
        	ops[i].dom =3D 0;
        	ops[i].host_addr =3D (unsigned long)(((char*) v_start->addr)+i*PAG=
E_SIZE);
	}

        if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ops, NUM_ALLOC=
*PAGES_PER_ALLOC)){
               	printk(KERN_INFO "Hypervisor map grant failed\n");
               	free_vm_area(v_start);
               	return -EFAULT;
       	}


	for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
		if(ops[i].status){
			printk(KERN_INFO "Hyper map grant failed with status %d\n", ops[i].statu=
s);
			free_vm_area(v_start);
			return -EFAULT;
        	}

		unmap_ops[i].host_addr =3D ops[i].host_addr;
		unmap_ops[i].handle =3D ops[i].handle;
		=

		printk(KERN_INFO "Number : %d\n", *((int *)ops[i].host_addr));
	}

        return 0;
}

static int  __exit mapped_exit(void){
	if(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops, NUM_ALLO=
C*PAGES_PER_ALLOC))
                	printk("Error in unmapping operation\n");
        free_vm_area(v_start);
	printk("Mapping module cleaned\n");
	return 0;
}

module_init(mapped_init)
module_exit(mapped_exit)


Mapping :

int main(void)
{
  int fd;
  int *vadr;

  unsigned long len =3D getpagesize(), i;

  if ((fd=3Dopen("node", O_RDWR|O_SYNC))<0)
  {
      perror("open");
      exit(-1);
  }

  vadr =3D mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

  if (vadr =3D=3D MAP_FAILED)
  {
          perror("mmap");
          exit(-1);
  }
  =

  for(i=3D0;i<len/sizeof(int);i+=3D(getpagesize()/sizeof(int))){
          printf("%d\n",*(vadr+i));
          vadr[i]=3Dvadr[i]+1;
  }

  close(fd);
  return(0);

}

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

The first attempt doesn't indicate any error but I don't get the good page =
(I put the value "3" in the page but the application read the value 0).

The second attempt gives an error in the module :
[   86.071090] WARNING: at /build/buildd/linux-3.2.0/arch/x86/xen/p2m.c:696=
 m2p_add_override+0x7b/0x3c0()
[   86.071093] m2p_add_override: pfn f73ed13ae not mapped
[   86.071095] Modules linked in: shm13(O) lp parport
[   86.071101] Pid: 1324, comm: fill Tainted: G           O 3.2.0-34-generi=
c #53-Ubuntu
[   86.071103] Call Trace:
[   86.071110]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
[   86.071113]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
[   86.071116]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
[   86.071121]  [<ffffffff8164328c>] ? printk+0x51/0x53
[   86.071126]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
[   86.071129]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
[   86.071134]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
[   86.071137]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
[   86.071140]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
[   86.071143]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
[   86.071148]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
[   86.071153]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
[   86.071155] ---[ end trace ea7792ae1c43717f ]---

The third attempt gives me the same error in the module :
[  105.337927] WARNING: at /build/buildd/linux-3.2.0/arch/x86/xen/p2m.c:696=
 m2p_add_override+0x7b/0x3c0()
[  105.337929] m2p_add_override: pfn f78bba24c not mapped
[  105.337931] Modules linked in: shm13(O) lp parport
[  105.337937] Pid: 1201, comm: fill Tainted: G           O 3.2.0-34-generi=
c #53-Ubuntu
[  105.337939] Call Trace:
[  105.337946]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
[  105.337949]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
[  105.337952]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
[  105.337958]  [<ffffffff8164328c>] ? printk+0x51/0x53
[  105.337962]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
[  105.337965]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
[  105.337970]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
[  105.337973]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
[  105.337976]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
[  105.337979]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
[  105.337984]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
[  105.337989]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
[  105.337991] ---[ end trace 33b54c96a0c2933b ]---

The fourth attempt results in an error in the function called by the module=
 :
[   96.621242] Error in remap_vmalloc_range

I don't really know what to do to make it works, but I know than such a com=
munication channel is possible as people have already done it before.

Does someone know what is my mistake and how to correct it please ?

Best regards,

S=E9bastien Fr=E9mal
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:02:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiWn-0001tr-37; Wed, 27 Feb 2013 15:02:41 +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 1UAiWl-0001th-00
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:39 +0000
Received: from [85.158.143.99:17518] by server-1.bemta-4.messagelabs.com id
	79/E8-06203-E002E215; Wed, 27 Feb 2013 15:02:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361977353!28539341!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30677 invoked from network); 27 Feb 2013 15:02:34 -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;
	27 Feb 2013 15:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999474"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:32 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-SI;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:08 +0000
Message-ID: <1361975655-22295-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 15/22] Genneralized event channel
	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

Use pointer in struct domain to reference evtchn_pending and evtchn_mask
bitmaps.

When building a domain, the default operation set is 2-level operation
set.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/arm/domain.c      |    1 +
 xen/arch/x86/domain.c      |    1 +
 xen/common/event_channel.c |   57 +++++++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h    |    3 +++
 4 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..1c12c95 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -422,6 +422,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         goto fail;
 
     clear_page(d->shared_info);
+    evtchn_set_default_bitmap(d);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b7f6749..fba86b9 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -580,6 +580,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
 
         clear_page(d->shared_info);
+        evtchn_set_default_bitmap(d);
         share_xen_page_with_guest(
             virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index abed10d..807f05f 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -69,6 +69,9 @@ static inline const char * evtchn_abi_str(unsigned int abi)
 
 #define consumer_is_xen(e) (!!(e)->xen_consumer)
 
+static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
+
 /*
  * The function alloc_unbound_xen_event_channel() allows an arbitrary
  * notifier function to be specified. However, very few unique functions
@@ -112,9 +115,6 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 /* Get the notification function for a given Xen-bound event channel. */
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
-static void evtchn_set_pending(struct vcpu *v, int port);
-static void evtchn_clear_pending(struct domain *d, int port);
-
 static int virq_is_global(uint32_t virq)
 {
     int rc;
@@ -177,15 +177,14 @@ static int get_free_port(struct domain *d)
 
 int evtchn_is_pending(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_pending));
+    return test_bit(port, d->evtchn_pending);
 }
 
 int evtchn_is_masked(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_mask));
+    return test_bit(port, d->evtchn_mask);
 }
 
-
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
     struct evtchn *chn;
@@ -641,7 +640,7 @@ out:
     return ret;
 }
 
-static void evtchn_set_pending(struct vcpu *v, int port)
+static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
     int vcpuid;
@@ -682,9 +681,23 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_set_pending(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        evtchn_set_pending_l2(v, port);
+        break;
+    default:
+        BUG();
+    }
+}
+
 static void evtchn_clear_pending(struct domain *d, int port)
 {
-    clear_bit(port, &shared_info(d, evtchn_pending));
+    clear_bit(port, d->evtchn_pending);
 }
 
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
@@ -950,7 +963,7 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id)
 }
 
 
-int evtchn_unmask(unsigned int port)
+static int evtchn_unmask_l2(unsigned int port)
 {
     struct domain *d = current->domain;
     struct vcpu   *v;
@@ -966,8 +979,8 @@ int evtchn_unmask(unsigned int port)
      * These operations must happen in strict order. Based on
      * include/xen/event.h:evtchn_set_pending().
      */
-    if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
-         test_bit          (port, &shared_info(d, evtchn_pending)) &&
+    if ( test_and_clear_bit(port, d->evtchn_mask) &&
+         test_bit          (port, d->evtchn_pending) &&
          !test_and_set_bit (port / BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)) )
     {
@@ -977,6 +990,23 @@ int evtchn_unmask(unsigned int port)
     return 0;
 }
 
+int evtchn_unmask(unsigned int port)
+{
+    struct domain *d = current->domain;
+    int rc = 0;
+
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        rc = evtchn_unmask_l2(port);
+        break;
+    default:
+        BUG();
+    }
+
+    return rc;
+}
+
 
 static long evtchn_reset(evtchn_reset_t *r)
 {
@@ -1203,6 +1233,11 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
     spin_unlock(&ld->event_lock);
 }
 
+void evtchn_set_default_bitmap(struct domain *d)
+{
+    d->evtchn_pending = (unsigned long *)shared_info(d, evtchn_pending);
+    d->evtchn_mask = (unsigned long *)shared_info(d, evtchn_mask);
+}
 
 int evtchn_init(struct domain *d)
 {
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 6a2ee27..8a38a80 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -138,6 +138,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* This is called after domain's shared info page is setup */
+void evtchn_set_default_bitmap(struct domain *d);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:02:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiWn-0001tr-37; Wed, 27 Feb 2013 15:02:41 +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 1UAiWl-0001th-00
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:39 +0000
Received: from [85.158.143.99:17518] by server-1.bemta-4.messagelabs.com id
	79/E8-06203-E002E215; Wed, 27 Feb 2013 15:02:38 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361977353!28539341!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30677 invoked from network); 27 Feb 2013 15:02:34 -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;
	27 Feb 2013 15:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999474"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:32 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-SI;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:08 +0000
Message-ID: <1361975655-22295-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 15/22] Genneralized event channel
	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

Use pointer in struct domain to reference evtchn_pending and evtchn_mask
bitmaps.

When building a domain, the default operation set is 2-level operation
set.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/arm/domain.c      |    1 +
 xen/arch/x86/domain.c      |    1 +
 xen/common/event_channel.c |   57 +++++++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h    |    3 +++
 4 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e37ec54..1c12c95 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -422,6 +422,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
         goto fail;
 
     clear_page(d->shared_info);
+    evtchn_set_default_bitmap(d);
     share_xen_page_with_guest(
         virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b7f6749..fba86b9 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -580,6 +580,7 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
             goto fail;
 
         clear_page(d->shared_info);
+        evtchn_set_default_bitmap(d);
         share_xen_page_with_guest(
             virt_to_page(d->shared_info), d, XENSHARE_writable);
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index abed10d..807f05f 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -69,6 +69,9 @@ static inline const char * evtchn_abi_str(unsigned int abi)
 
 #define consumer_is_xen(e) (!!(e)->xen_consumer)
 
+static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
+
 /*
  * The function alloc_unbound_xen_event_channel() allows an arbitrary
  * notifier function to be specified. However, very few unique functions
@@ -112,9 +115,6 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 /* Get the notification function for a given Xen-bound event channel. */
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
-static void evtchn_set_pending(struct vcpu *v, int port);
-static void evtchn_clear_pending(struct domain *d, int port);
-
 static int virq_is_global(uint32_t virq)
 {
     int rc;
@@ -177,15 +177,14 @@ static int get_free_port(struct domain *d)
 
 int evtchn_is_pending(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_pending));
+    return test_bit(port, d->evtchn_pending);
 }
 
 int evtchn_is_masked(struct domain *d, int port)
 {
-    return test_bit(port, &shared_info(d, evtchn_mask));
+    return test_bit(port, d->evtchn_mask);
 }
 
-
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
     struct evtchn *chn;
@@ -641,7 +640,7 @@ out:
     return ret;
 }
 
-static void evtchn_set_pending(struct vcpu *v, int port)
+static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
     int vcpuid;
@@ -682,9 +681,23 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_set_pending(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        evtchn_set_pending_l2(v, port);
+        break;
+    default:
+        BUG();
+    }
+}
+
 static void evtchn_clear_pending(struct domain *d, int port)
 {
-    clear_bit(port, &shared_info(d, evtchn_pending));
+    clear_bit(port, d->evtchn_pending);
 }
 
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
@@ -950,7 +963,7 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id)
 }
 
 
-int evtchn_unmask(unsigned int port)
+static int evtchn_unmask_l2(unsigned int port)
 {
     struct domain *d = current->domain;
     struct vcpu   *v;
@@ -966,8 +979,8 @@ int evtchn_unmask(unsigned int port)
      * These operations must happen in strict order. Based on
      * include/xen/event.h:evtchn_set_pending().
      */
-    if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
-         test_bit          (port, &shared_info(d, evtchn_pending)) &&
+    if ( test_and_clear_bit(port, d->evtchn_mask) &&
+         test_bit          (port, d->evtchn_pending) &&
          !test_and_set_bit (port / BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)) )
     {
@@ -977,6 +990,23 @@ int evtchn_unmask(unsigned int port)
     return 0;
 }
 
+int evtchn_unmask(unsigned int port)
+{
+    struct domain *d = current->domain;
+    int rc = 0;
+
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        rc = evtchn_unmask_l2(port);
+        break;
+    default:
+        BUG();
+    }
+
+    return rc;
+}
+
 
 static long evtchn_reset(evtchn_reset_t *r)
 {
@@ -1203,6 +1233,11 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
     spin_unlock(&ld->event_lock);
 }
 
+void evtchn_set_default_bitmap(struct domain *d)
+{
+    d->evtchn_pending = (unsigned long *)shared_info(d, evtchn_pending);
+    d->evtchn_mask = (unsigned long *)shared_info(d, evtchn_mask);
+}
 
 int evtchn_init(struct domain *d)
 {
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 6a2ee27..8a38a80 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -138,6 +138,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* This is called after domain's shared info page is setup */
+void evtchn_set_default_bitmap(struct domain *d);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:02:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiWv-0001uY-G7; Wed, 27 Feb 2013 15:02:49 +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 1UAiWu-0001uP-7H
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:48 +0000
Received: from [85.158.143.99:18147] by server-1.bemta-4.messagelabs.com id
	BD/09-06203-7102E215; Wed, 27 Feb 2013 15:02:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361977365!24201839!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14465 invoked from network); 27 Feb 2013 15:02:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999526"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:44 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Qp;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:05 +0000
Message-ID: <1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 12/22] Add supported extended event
	channel ABI bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |    4 ++++
 xen/include/xen/event.h    |    1 +
 2 files changed, 5 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c73c709..470b8d2 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -32,6 +32,10 @@
 #include <public/event_channel.h>
 #include <xsm/xsm.h>
 
+/* A bitmap of supported extended event channel ABIs */
+uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
+                                   EVTCHN_EXTENDED_L3);
+
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index aea61eb..6a2ee27 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -171,4 +171,5 @@ void notify_via_xen_event_channel(struct domain *ld, int lport);
         mb(); /* set blocked status /then/ caller does his work */      \
     } while ( 0 )
 
+extern uint32_t extended_event_channel;
 #endif /* __XEN_EVENT_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:02:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiWv-0001uY-G7; Wed, 27 Feb 2013 15:02:49 +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 1UAiWu-0001uP-7H
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:48 +0000
Received: from [85.158.143.99:18147] by server-1.bemta-4.messagelabs.com id
	BD/09-06203-7102E215; Wed, 27 Feb 2013 15:02:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1361977365!24201839!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14465 invoked from network); 27 Feb 2013 15:02:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:46 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999526"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:44 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Qp;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:05 +0000
Message-ID: <1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 12/22] Add supported extended event
	channel ABI bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |    4 ++++
 xen/include/xen/event.h    |    1 +
 2 files changed, 5 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c73c709..470b8d2 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -32,6 +32,10 @@
 #include <public/event_channel.h>
 #include <xsm/xsm.h>
 
+/* A bitmap of supported extended event channel ABIs */
+uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
+                                   EVTCHN_EXTENDED_L3);
+
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index aea61eb..6a2ee27 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -171,4 +171,5 @@ void notify_via_xen_event_channel(struct domain *ld, int lport);
         mb(); /* set blocked status /then/ caller does his work */      \
     } while ( 0 )
 
+extern uint32_t extended_event_channel;
 #endif /* __XEN_EVENT_H__ */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:02:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:02: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 1UAiWx-0001uy-Sw; Wed, 27 Feb 2013 15:02:51 +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 1UAiWw-0001ue-9O
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:50 +0000
Received: from [85.158.139.211:4507] by server-6.bemta-5.messagelabs.com id
	D7/C6-21466-9102E215; Wed, 27 Feb 2013 15:02:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361977359!19384824!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29441 invoked from network); 27 Feb 2013 15:02:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508275"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:39 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Ro;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:07 +0000
Message-ID: <1361975655-22295-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 14/22] Add control structures for 3-level
	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

The references to shared bitmap pending / mask are embedded in struct domain.
And pointer to the second level selector is embedded in struct vcpu.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/sched.h |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index dd40444..4a3e51c 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -57,6 +57,9 @@ struct vcpu
 
     struct domain   *domain;
 
+    /* For 3-level event channels */
+    unsigned long   *evtchn_pending_sel_l2;
+
     struct vcpu     *next_in_list;
 
     s_time_t         periodic_period;
@@ -219,6 +222,9 @@ struct domain
     spinlock_t       event_lock;
     unsigned int     evtchn_extended;
 
+    unsigned long   *evtchn_pending;
+    unsigned long   *evtchn_mask;
+
     struct grant_table *grant_table;
 
     /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:02:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:02: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 1UAiWx-0001uy-Sw; Wed, 27 Feb 2013 15:02:51 +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 1UAiWw-0001ue-9O
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:50 +0000
Received: from [85.158.139.211:4507] by server-6.bemta-5.messagelabs.com id
	D7/C6-21466-9102E215; Wed, 27 Feb 2013 15:02:49 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361977359!19384824!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29441 invoked from network); 27 Feb 2013 15:02:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508275"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:39 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Ro;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:07 +0000
Message-ID: <1361975655-22295-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 14/22] Add control structures for 3-level
	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

The references to shared bitmap pending / mask are embedded in struct domain.
And pointer to the second level selector is embedded in struct vcpu.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/xen/sched.h |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index dd40444..4a3e51c 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -57,6 +57,9 @@ struct vcpu
 
     struct domain   *domain;
 
+    /* For 3-level event channels */
+    unsigned long   *evtchn_pending_sel_l2;
+
     struct vcpu     *next_in_list;
 
     s_time_t         periodic_period;
@@ -219,6 +222,9 @@ struct domain
     spinlock_t       event_lock;
     unsigned int     evtchn_extended;
 
+    unsigned long   *evtchn_pending;
+    unsigned long   *evtchn_mask;
+
     struct grant_table *grant_table;
 
     /*
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiX1-0001vz-AH; Wed, 27 Feb 2013 15:02:55 +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 1UAiWz-0001vM-3I
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:53 +0000
Received: from [85.158.139.211:4755] by server-16.bemta-5.messagelabs.com id
	26/CF-02543-C102E215; Wed, 27 Feb 2013 15:02:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361977359!19384824!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29880 invoked from network); 27 Feb 2013 15:02:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508294"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-PP;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:04 +0000
Message-ID: <1361975655-22295-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 11/22] Update Xen public header
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 need to update event.h so that this change won't break the build.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/public/xen.h |   13 ++++++++++++-
 xen/include/xen/event.h  |    2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 87380e6..6d6e319 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -554,9 +554,20 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
 
 /*
  * Event channel endpoints per domain:
+ * 2-level for x86:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
+ * 3-level for x86:
+ *  32k if a long is 32 bits; 256k if a long is 64 bits.
+ * 2-level for ARM:
+ *  4096 for both 32 bits and 64 bits.
+ * 3-level for ARM:
+ *  256k for both 32 bits and 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
+#define NR_EVENT_CHANNELS_L2 (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
+#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
+#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
+#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
+#endif
 
 struct vcpu_time_info {
     /*
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 6ad0745..aea61eb 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -40,7 +40,7 @@ static inline unsigned int max_evtchns(struct domain *d)
 }
 
 #define EVTCHNS_PER_BUCKET 512
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS_L3 / EVTCHNS_PER_BUCKET)
 
 struct evtchn
 {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiX1-0001vz-AH; Wed, 27 Feb 2013 15:02:55 +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 1UAiWz-0001vM-3I
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:53 +0000
Received: from [85.158.139.211:4755] by server-16.bemta-5.messagelabs.com id
	26/CF-02543-C102E215; Wed, 27 Feb 2013 15:02:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1361977359!19384824!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29880 invoked from network); 27 Feb 2013 15:02:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508294"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:43 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-PP;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:04 +0000
Message-ID: <1361975655-22295-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 11/22] Update Xen public header
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 need to update event.h so that this change won't break the build.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/public/xen.h |   13 ++++++++++++-
 xen/include/xen/event.h  |    2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 87380e6..6d6e319 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -554,9 +554,20 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
 
 /*
  * Event channel endpoints per domain:
+ * 2-level for x86:
  *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
+ * 3-level for x86:
+ *  32k if a long is 32 bits; 256k if a long is 64 bits.
+ * 2-level for ARM:
+ *  4096 for both 32 bits and 64 bits.
+ * 3-level for ARM:
+ *  256k for both 32 bits and 64 bits.
  */
-#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
+#define NR_EVENT_CHANNELS_L2 (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
+#define NR_EVENT_CHANNELS_L3 (NR_EVENT_CHANNELS_L2 * 64)
+#if !defined(__XEN__) && !defined(__XEN_TOOLS__)
+#define NR_EVENT_CHANNELS NR_EVENT_CHANNELS_L2 /* for compatibility */
+#endif
 
 struct vcpu_time_info {
     /*
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 6ad0745..aea61eb 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -40,7 +40,7 @@ static inline unsigned int max_evtchns(struct domain *d)
 }
 
 #define EVTCHNS_PER_BUCKET 512
-#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS / EVTCHNS_PER_BUCKET)
+#define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS_L3 / EVTCHNS_PER_BUCKET)
 
 struct evtchn
 {
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiX1-0001wB-O9; Wed, 27 Feb 2013 15:02:55 +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 1UAiX0-0001ue-6N
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:54 +0000
Received: from [85.158.139.211:15994] by server-6.bemta-5.messagelabs.com id
	FB/E6-21466-D102E215; Wed, 27 Feb 2013 15:02:53 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361977372!18623099!1
X-Originating-IP: [74.125.83.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21002 invoked from network); 27 Feb 2013 15:02:53 -0000
Received: from mail-ee0-f51.google.com (HELO mail-ee0-f51.google.com)
	(74.125.83.51)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:53 -0000
Received: by mail-ee0-f51.google.com with SMTP id d17so564973eek.38
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 07:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=p3EUtJBGo/tdBQNAKy8m6IIsPsI08RyC2FsfBXH0Vgk=;
	b=Y2lIVW7Mk5WaudGQTmr7GJthwsMBG7AJ8Zx3PtKnbH0FZXAm56zBoJrb10LIfIC4eF
	TRPqX+HnNfjBZWmpxuYGbz/wIGi5c53EgF4/T6EhsbHW21juqKan03/ipzM8+j+E+c+a
	rFZtZJQwoCFQkwxG73Ncip1+HpxnTz9ZRL5u49eZTGXtLTL9Nr3IDe4KDZCa3JFkC1o2
	pWfBVaPd2hPkdPznjuoKvMtVnfflwnImiAIN8TAyBS5azjPm8aATSCU8L9cfm6S3aX4P
	75QrCo3DV27cGyszzPjYk735K+FXU/7di027hFQSjOWPx2og6fyii4ahO9zl08+ozQQ7
	NsZw==
X-Received: by 10.14.182.137 with SMTP id o9mr6946562eem.13.1361977372776;
	Wed, 27 Feb 2013 07:02:52 -0800 (PST)
Received: from [172.16.26.11] ([151.225.0.38])
	by mx.google.com with ESMTPS id d47sm6866355eem.9.2013.02.27.07.02.50
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 07:02:51 -0800 (PST)
Message-ID: <512E2019.3010101@xen.org>
Date: Wed, 27 Feb 2013 15:02:49 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Minutes] Xen Maintainer,
 Committer and Developer Meeting / February 2013
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

http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/February_2013_Minutes 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAiX1-0001wB-O9; Wed, 27 Feb 2013 15:02:55 +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 1UAiX0-0001ue-6N
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:02:54 +0000
Received: from [85.158.139.211:15994] by server-6.bemta-5.messagelabs.com id
	FB/E6-21466-D102E215; Wed, 27 Feb 2013 15:02:53 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1361977372!18623099!1
X-Originating-IP: [74.125.83.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21002 invoked from network); 27 Feb 2013 15:02:53 -0000
Received: from mail-ee0-f51.google.com (HELO mail-ee0-f51.google.com)
	(74.125.83.51)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:53 -0000
Received: by mail-ee0-f51.google.com with SMTP id d17so564973eek.38
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 07:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=p3EUtJBGo/tdBQNAKy8m6IIsPsI08RyC2FsfBXH0Vgk=;
	b=Y2lIVW7Mk5WaudGQTmr7GJthwsMBG7AJ8Zx3PtKnbH0FZXAm56zBoJrb10LIfIC4eF
	TRPqX+HnNfjBZWmpxuYGbz/wIGi5c53EgF4/T6EhsbHW21juqKan03/ipzM8+j+E+c+a
	rFZtZJQwoCFQkwxG73Ncip1+HpxnTz9ZRL5u49eZTGXtLTL9Nr3IDe4KDZCa3JFkC1o2
	pWfBVaPd2hPkdPznjuoKvMtVnfflwnImiAIN8TAyBS5azjPm8aATSCU8L9cfm6S3aX4P
	75QrCo3DV27cGyszzPjYk735K+FXU/7di027hFQSjOWPx2og6fyii4ahO9zl08+ozQQ7
	NsZw==
X-Received: by 10.14.182.137 with SMTP id o9mr6946562eem.13.1361977372776;
	Wed, 27 Feb 2013 07:02:52 -0800 (PST)
Received: from [172.16.26.11] ([151.225.0.38])
	by mx.google.com with ESMTPS id d47sm6866355eem.9.2013.02.27.07.02.50
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 07:02:51 -0800 (PST)
Message-ID: <512E2019.3010101@xen.org>
Date: Wed, 27 Feb 2013 15:02:49 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Minutes] Xen Maintainer,
 Committer and Developer Meeting / February 2013
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

http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/February_2013_Minutes 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXG-000227-5R; Wed, 27 Feb 2013 15:03:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXE-00021V-Md
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:08 +0000
Received: from [85.158.137.99:26801] by server-6.bemta-3.messagelabs.com id
	6A/B8-11048-B202E215; Wed, 27 Feb 2013 15:03:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361977371!18402129!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12326 invoked from network); 27 Feb 2013 15:02:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999584"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:55 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Vl;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:12 +0000
Message-ID: <1361975655-22295-20-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 19/22] Enable exteneded event channel ABI
	query
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index bb6e5f9..88679d5 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1219,12 +1219,14 @@ static long evtchn_register_extended(struct evtchn_register_extended *reg)
 
     switch ( reg->cmd )
     {
-    case EVTCHN_EXTENDED_NONE:
-    default:
-        rc = -EINVAL;
+    case EVTCHN_EXTENDED_QUERY:
+        rc = extended_event_channel;
+        break;
     case EVTCHN_EXTENDED_L3:
         rc = evtchn_register_3level(&reg->u.l3);
         break;
+    default:
+        rc = -EINVAL;
     }
 
     spin_unlock(&d->event_lock);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXG-000227-5R; Wed, 27 Feb 2013 15:03:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXE-00021V-Md
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:08 +0000
Received: from [85.158.137.99:26801] by server-6.bemta-3.messagelabs.com id
	6A/B8-11048-B202E215; Wed, 27 Feb 2013 15:03:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361977371!18402129!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12326 invoked from network); 27 Feb 2013 15:02:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999584"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:55 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Vl;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:12 +0000
Message-ID: <1361975655-22295-20-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 19/22] Enable exteneded event channel ABI
	query
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index bb6e5f9..88679d5 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1219,12 +1219,14 @@ static long evtchn_register_extended(struct evtchn_register_extended *reg)
 
     switch ( reg->cmd )
     {
-    case EVTCHN_EXTENDED_NONE:
-    default:
-        rc = -EINVAL;
+    case EVTCHN_EXTENDED_QUERY:
+        rc = extended_event_channel;
+        break;
     case EVTCHN_EXTENDED_L3:
         rc = evtchn_register_3level(&reg->u.l3);
         break;
+    default:
+        rc = -EINVAL;
     }
 
     spin_unlock(&d->event_lock);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXG-00022F-HV; Wed, 27 Feb 2013 15:03:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXE-00021W-Kw
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:08 +0000
Received: from [85.158.137.99:52468] by server-15.bemta-3.messagelabs.com id
	DE/3A-23142-B202E215; Wed, 27 Feb 2013 15:03:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361977371!18402129!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11858 invoked from network); 27 Feb 2013 15:02:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999557"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:50 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-NU;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:03 +0000
Message-ID: <1361975655-22295-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 10/22] Add evtchn_is_{pending,
	masked} and evtchn_clear_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 code paths access the arrays in shared info directly. This only
works with 2-level event channel.

Add functions to abstract away implementation details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/irq.c         |    7 +++----
 xen/common/event_channel.c |   22 +++++++++++++++++++---
 xen/common/keyhandler.c    |    6 ++----
 xen/common/schedule.c      |    2 +-
 xen/include/xen/event.h    |    6 ++++++
 5 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index b98deb5..d070868 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1452,7 +1452,7 @@ int pirq_guest_unmask(struct domain *d)
         {
             pirq = pirqs[i]->pirq;
             if ( pirqs[i]->masked &&
-                 !test_bit(pirqs[i]->evtchn, &shared_info(d, evtchn_mask)) )
+                 !evtchn_is_masked(d, pirqs[i]->evtchn) )
                 pirq_guest_eoi(pirqs[i]);
         }
     } while ( ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
@@ -2090,13 +2090,12 @@ static void dump_irqs(unsigned char key)
                 info = pirq_info(d, pirq);
                 printk("%u:%3d(%c%c%c%c)",
                        d->domain_id, pirq,
-                       (test_bit(info->evtchn,
-                                 &shared_info(d, evtchn_pending)) ?
+                       (evtchn_is_pending(d, info->evtchn) ?
                         'P' : '-'),
                        (test_bit(info->evtchn / BITS_PER_EVTCHN_WORD(d),
                                  &vcpu_info(d->vcpu[0], evtchn_pending_sel)) ?
                         'S' : '-'),
-                       (test_bit(info->evtchn, &shared_info(d, evtchn_mask)) ?
+                       (evtchn_is_masked(d, info->evtchn) ?
                         'M' : '-'),
                        (info->masked ? 'M' : '-'));
                 if ( i != action->nr_guests )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index bd4b1e8..c73c709 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -95,6 +95,7 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
 static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
 
 static int virq_is_global(uint32_t virq)
 {
@@ -156,6 +157,16 @@ static int get_free_port(struct domain *d)
     return port;
 }
 
+int evtchn_is_pending(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_pending));
+}
+
+int evtchn_is_masked(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_mask));
+}
+
 
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
@@ -529,7 +540,7 @@ static long __evtchn_close(struct domain *d1, int port1)
     }
 
     /* Clear pending event to avoid unexpected behavior on re-bind. */
-    clear_bit(port1, &shared_info(d1, evtchn_pending));
+    evtchn_clear_pending(d1, port1);
 
     /* Reset binding to vcpu0 when the channel is freed. */
     chn1->state          = ECS_FREE;
@@ -653,6 +664,11 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_clear_pending(struct domain *d, int port)
+{
+    clear_bit(port, &shared_info(d, evtchn_pending));
+}
+
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
@@ -1283,8 +1299,8 @@ static void domain_dump_evtchn_info(struct domain *d)
 
         printk("    %4u [%d/%d]: s=%d n=%d x=%d",
                port,
-               !!test_bit(port, &shared_info(d, evtchn_pending)),
-               !!test_bit(port, &shared_info(d, evtchn_mask)),
+               !!evtchn_is_pending(d, port),
+               !!evtchn_is_masked(d, port),
                chn->state, chn->notify_vcpu_id, chn->xen_consumer);
 
         switch ( chn->state )
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 98a2c7f..1be3ca8 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -302,10 +302,8 @@ static void dump_domains(unsigned char key)
             printk("Notifying guest %d:%d (virq %d, port %d, stat %d/%d/%d)\n",
                    d->domain_id, v->vcpu_id,
                    VIRQ_DEBUG, v->virq_to_evtchn[VIRQ_DEBUG],
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_pending)),
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_mask)),
+                   evtchn_is_pending(d, v->virq_to_evtchn[VIRQ_DEBUG]),
+                   evtchn_is_masked(d, v->virq_to_evtchn[VIRQ_DEBUG]),
                    test_bit(v->virq_to_evtchn[VIRQ_DEBUG] /
                             BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)));
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e59eb4d..35f16cf 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -693,7 +693,7 @@ static long do_poll(struct sched_poll *sched_poll)
             goto out;
 
         rc = 0;
-        if ( test_bit(port, &shared_info(d, evtchn_pending)) )
+        if ( evtchn_is_pending(d, port) )
             goto out;
     }
 
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 68ce2ae..6ad0745 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -117,6 +117,12 @@ int evtchn_unmask(unsigned int port);
 /* Move all PIRQs after a vCPU was moved to another pCPU. */
 void evtchn_move_pirqs(struct vcpu *v);
 
+/* Tell a given event-channel port is pending or not */
+int evtchn_is_pending(struct domain *d, int port);
+
+/* Tell a given event-channel port is masked or not */
+int evtchn_is_masked(struct domain *d, int port);
+
 /* Allocate/free a Xen-attached event channel port. */
 typedef void (*xen_event_channel_notification_t)(
     struct vcpu *v, unsigned int port);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:14 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXG-00022F-HV; Wed, 27 Feb 2013 15:03:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXE-00021W-Kw
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:08 +0000
Received: from [85.158.137.99:52468] by server-15.bemta-3.messagelabs.com id
	DE/3A-23142-B202E215; Wed, 27 Feb 2013 15:03:07 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361977371!18402129!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11858 invoked from network); 27 Feb 2013 15:02:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999557"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:50 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-NU;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:03 +0000
Message-ID: <1361975655-22295-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 10/22] Add evtchn_is_{pending,
	masked} and evtchn_clear_pending
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 code paths access the arrays in shared info directly. This only
works with 2-level event channel.

Add functions to abstract away implementation details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/irq.c         |    7 +++----
 xen/common/event_channel.c |   22 +++++++++++++++++++---
 xen/common/keyhandler.c    |    6 ++----
 xen/common/schedule.c      |    2 +-
 xen/include/xen/event.h    |    6 ++++++
 5 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index b98deb5..d070868 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1452,7 +1452,7 @@ int pirq_guest_unmask(struct domain *d)
         {
             pirq = pirqs[i]->pirq;
             if ( pirqs[i]->masked &&
-                 !test_bit(pirqs[i]->evtchn, &shared_info(d, evtchn_mask)) )
+                 !evtchn_is_masked(d, pirqs[i]->evtchn) )
                 pirq_guest_eoi(pirqs[i]);
         }
     } while ( ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
@@ -2090,13 +2090,12 @@ static void dump_irqs(unsigned char key)
                 info = pirq_info(d, pirq);
                 printk("%u:%3d(%c%c%c%c)",
                        d->domain_id, pirq,
-                       (test_bit(info->evtchn,
-                                 &shared_info(d, evtchn_pending)) ?
+                       (evtchn_is_pending(d, info->evtchn) ?
                         'P' : '-'),
                        (test_bit(info->evtchn / BITS_PER_EVTCHN_WORD(d),
                                  &vcpu_info(d->vcpu[0], evtchn_pending_sel)) ?
                         'S' : '-'),
-                       (test_bit(info->evtchn, &shared_info(d, evtchn_mask)) ?
+                       (evtchn_is_masked(d, info->evtchn) ?
                         'M' : '-'),
                        (info->masked ? 'M' : '-'));
                 if ( i != action->nr_guests )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index bd4b1e8..c73c709 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -95,6 +95,7 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 #define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
 
 static void evtchn_set_pending(struct vcpu *v, int port);
+static void evtchn_clear_pending(struct domain *d, int port);
 
 static int virq_is_global(uint32_t virq)
 {
@@ -156,6 +157,16 @@ static int get_free_port(struct domain *d)
     return port;
 }
 
+int evtchn_is_pending(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_pending));
+}
+
+int evtchn_is_masked(struct domain *d, int port)
+{
+    return test_bit(port, &shared_info(d, evtchn_mask));
+}
+
 
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
@@ -529,7 +540,7 @@ static long __evtchn_close(struct domain *d1, int port1)
     }
 
     /* Clear pending event to avoid unexpected behavior on re-bind. */
-    clear_bit(port1, &shared_info(d1, evtchn_pending));
+    evtchn_clear_pending(d1, port1);
 
     /* Reset binding to vcpu0 when the channel is freed. */
     chn1->state          = ECS_FREE;
@@ -653,6 +664,11 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     }
 }
 
+static void evtchn_clear_pending(struct domain *d, int port)
+{
+    clear_bit(port, &shared_info(d, evtchn_pending));
+}
+
 int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
@@ -1283,8 +1299,8 @@ static void domain_dump_evtchn_info(struct domain *d)
 
         printk("    %4u [%d/%d]: s=%d n=%d x=%d",
                port,
-               !!test_bit(port, &shared_info(d, evtchn_pending)),
-               !!test_bit(port, &shared_info(d, evtchn_mask)),
+               !!evtchn_is_pending(d, port),
+               !!evtchn_is_masked(d, port),
                chn->state, chn->notify_vcpu_id, chn->xen_consumer);
 
         switch ( chn->state )
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 98a2c7f..1be3ca8 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -302,10 +302,8 @@ static void dump_domains(unsigned char key)
             printk("Notifying guest %d:%d (virq %d, port %d, stat %d/%d/%d)\n",
                    d->domain_id, v->vcpu_id,
                    VIRQ_DEBUG, v->virq_to_evtchn[VIRQ_DEBUG],
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_pending)),
-                   test_bit(v->virq_to_evtchn[VIRQ_DEBUG], 
-                            &shared_info(d, evtchn_mask)),
+                   evtchn_is_pending(d, v->virq_to_evtchn[VIRQ_DEBUG]),
+                   evtchn_is_masked(d, v->virq_to_evtchn[VIRQ_DEBUG]),
                    test_bit(v->virq_to_evtchn[VIRQ_DEBUG] /
                             BITS_PER_EVTCHN_WORD(d),
                             &vcpu_info(v, evtchn_pending_sel)));
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e59eb4d..35f16cf 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -693,7 +693,7 @@ static long do_poll(struct sched_poll *sched_poll)
             goto out;
 
         rc = 0;
-        if ( test_bit(port, &shared_info(d, evtchn_pending)) )
+        if ( evtchn_is_pending(d, port) )
             goto out;
     }
 
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 68ce2ae..6ad0745 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -117,6 +117,12 @@ int evtchn_unmask(unsigned int port);
 /* Move all PIRQs after a vCPU was moved to another pCPU. */
 void evtchn_move_pirqs(struct vcpu *v);
 
+/* Tell a given event-channel port is pending or not */
+int evtchn_is_pending(struct domain *d, int port);
+
+/* Tell a given event-channel port is masked or not */
+int evtchn_is_masked(struct domain *d, int port);
+
 /* Allocate/free a Xen-attached event channel port. */
 typedef void (*xen_event_channel_notification_t)(
     struct vcpu *v, unsigned int port);
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXR-00027g-IB; Wed, 27 Feb 2013 15:03:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXQ-00026P-0n
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:20 +0000
Received: from [85.158.138.51:6494] by server-5.bemta-3.messagelabs.com id
	26/22-30636-7302E215; Wed, 27 Feb 2013 15:03:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31580 invoked from network); 27 Feb 2013 15:03:18 -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;
	27 Feb 2013 15:03:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508319"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-U5;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:11 +0000
Message-ID: <1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 18/22] Implement
	EVTCHNOP_register_extended
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note: this call always fails as it is not yet completed.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   56 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 26daa7e..bb6e5f9 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1204,6 +1204,34 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
     return rc;
 }
 
+/*
+ * NOTE to extneded event channel users:
+ * extended channels are likely to consume lots large global mapping
+ * area in Xen. For example, 3-level event channel consumes 16 +
+ * nr_vcpus pages global mapping area.
+ */
+static long evtchn_register_extended(struct evtchn_register_extended *reg)
+{
+    struct domain *d = current->domain;
+    int rc;
+
+    spin_lock(&d->event_lock);
+
+    switch ( reg->cmd )
+    {
+    case EVTCHN_EXTENDED_NONE:
+    default:
+        rc = -EINVAL;
+    case EVTCHN_EXTENDED_L3:
+        rc = evtchn_register_3level(&reg->u.l3);
+        break;
+    }
+
+    spin_unlock(&d->event_lock);
+
+    return rc;
+}
+
 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
@@ -1312,6 +1340,19 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+    case EVTCHNOP_register_extended: {
+        struct evtchn_register_extended reg;
+
+        if ( copy_from_guest(&reg, arg, 1) != 0 )
+            return -EFAULT;
+        rc = evtchn_register_extended(&reg);
+
+        /* XXX always fails this call because it is not yet completed */
+        rc = -EINVAL;
+
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
@@ -1438,6 +1479,19 @@ int evtchn_init(struct domain *d)
     return 0;
 }
 
+static void evtchn_unmap_extended(struct domain *d)
+{
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+    default:
+        break;
+    case EVTCHN_EXTENDED_L3:
+        __evtchn_unmap_all_3level(d);
+        break;
+    }
+}
+
 
 void evtchn_destroy(struct domain *d)
 {
@@ -1466,6 +1520,8 @@ void evtchn_destroy(struct domain *d)
 
     clear_global_virq_handlers(d);
 
+    evtchn_unmap_extended(d);
+
     free_xenheap_page(d->evtchn);
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXR-00027g-IB; Wed, 27 Feb 2013 15:03:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXQ-00026P-0n
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:20 +0000
Received: from [85.158.138.51:6494] by server-5.bemta-3.messagelabs.com id
	26/22-30636-7302E215; Wed, 27 Feb 2013 15:03:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31580 invoked from network); 27 Feb 2013 15:03:18 -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;
	27 Feb 2013 15:03:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508319"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:52 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-U5;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:11 +0000
Message-ID: <1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 18/22] Implement
	EVTCHNOP_register_extended
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note: this call always fails as it is not yet completed.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |   56 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 26daa7e..bb6e5f9 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1204,6 +1204,34 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
     return rc;
 }
 
+/*
+ * NOTE to extneded event channel users:
+ * extended channels are likely to consume lots large global mapping
+ * area in Xen. For example, 3-level event channel consumes 16 +
+ * nr_vcpus pages global mapping area.
+ */
+static long evtchn_register_extended(struct evtchn_register_extended *reg)
+{
+    struct domain *d = current->domain;
+    int rc;
+
+    spin_lock(&d->event_lock);
+
+    switch ( reg->cmd )
+    {
+    case EVTCHN_EXTENDED_NONE:
+    default:
+        rc = -EINVAL;
+    case EVTCHN_EXTENDED_L3:
+        rc = evtchn_register_3level(&reg->u.l3);
+        break;
+    }
+
+    spin_unlock(&d->event_lock);
+
+    return rc;
+}
+
 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
@@ -1312,6 +1340,19 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
     }
 
+    case EVTCHNOP_register_extended: {
+        struct evtchn_register_extended reg;
+
+        if ( copy_from_guest(&reg, arg, 1) != 0 )
+            return -EFAULT;
+        rc = evtchn_register_extended(&reg);
+
+        /* XXX always fails this call because it is not yet completed */
+        rc = -EINVAL;
+
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
@@ -1438,6 +1479,19 @@ int evtchn_init(struct domain *d)
     return 0;
 }
 
+static void evtchn_unmap_extended(struct domain *d)
+{
+    switch ( d->evtchn_extended )
+    {
+    case EVTCHN_EXTENDED_NONE:
+    default:
+        break;
+    case EVTCHN_EXTENDED_L3:
+        __evtchn_unmap_all_3level(d);
+        break;
+    }
+}
+
 
 void evtchn_destroy(struct domain *d)
 {
@@ -1466,6 +1520,8 @@ void evtchn_destroy(struct domain *d)
 
     clear_global_virq_handlers(d);
 
+    evtchn_unmap_extended(d);
+
     free_xenheap_page(d->evtchn);
 }
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXR-00027O-5o; Wed, 27 Feb 2013 15:03:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXP-00026C-Fa
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:19 +0000
Received: from [85.158.138.51:6461] by server-9.bemta-3.messagelabs.com id
	79/6B-32531-6302E215; Wed, 27 Feb 2013 15:03:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31462 invoked from network); 27 Feb 2013 15:03:17 -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;
	27 Feb 2013 15:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508304"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:46 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Ta;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:10 +0000
Message-ID: <1361975655-22295-18-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 17/22] Infrastructure to manipulate
	3-level event channel 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |  170 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 170 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 807f05f..26daa7e 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1034,6 +1034,176 @@ out:
 }
 
 
+static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
+                            xen_pfn_t *mask, int nr_pages)
+{
+    int rc = -ENOMEM;
+    void *mapping;
+
+    mapping = vmap(pending, nr_pages);
+    if ( !mapping )
+        goto out;
+    d->evtchn_pending = mapping;
+
+    mapping = vmap(mask, nr_pages);
+    if ( !mapping )
+    {
+        vunmap(d->evtchn_pending);
+        d->evtchn_pending = NULL;
+        goto out;
+    }
+    d->evtchn_mask = mapping;
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static void __unmap_l3_arrays(struct domain *d)
+{
+    if ( d->evtchn_pending )
+    {
+        vunmap(d->evtchn_pending);
+        d->evtchn_pending = NULL;
+    }
+
+    if ( d->evtchn_mask )
+    {
+        vunmap(d->evtchn_mask);
+        d->evtchn_mask = NULL;
+    }
+}
+
+static long __map_l2_selector(struct vcpu *v, unsigned long gfn,
+                              unsigned long off)
+{
+    int rc = -ENOMEM;
+    void *mapping;
+
+    mapping = vmap(&gfn, 1);
+
+    if ( mapping == NULL )
+        goto out;
+
+    v->evtchn_pending_sel_l2 = mapping + off;
+    rc = 0;
+
+ out:
+    return rc;
+}
+
+static void __unmap_l2_selector(struct vcpu *v)
+{
+    if ( v->evtchn_pending_sel_l2 )
+    {
+        unsigned long addr =
+            (unsigned long)(v->evtchn_pending_sel_l2) & PAGE_MASK;
+        vunmap((void *)addr);
+        v->evtchn_pending_sel_l2 = NULL;
+    }
+}
+
+static void __evtchn_unmap_all_3level(struct domain *d)
+{
+    struct vcpu *v;
+    for_each_vcpu ( d, v )
+        __unmap_l2_selector(v);
+    __unmap_l3_arrays(d);
+}
+
+static void __evtchn_setup_bitmap_l3(struct domain *d)
+{
+    struct vcpu *v;
+
+    /* Easy way to setup 3-level bitmap, just move existing selector
+     * to next level then copy pending array and mask array */
+    for_each_vcpu ( d, v )
+    {
+        memcpy(&v->evtchn_pending_sel_l2[0],
+               &vcpu_info(v, evtchn_pending_sel),
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        memset(&vcpu_info(v, evtchn_pending_sel), 0,
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        set_bit(0, &vcpu_info(v, evtchn_pending_sel));
+    }
+
+    memcpy(d->evtchn_pending, &shared_info(d, evtchn_pending),
+           sizeof(shared_info(d, evtchn_pending)));
+    memcpy(d->evtchn_mask, &shared_info(d, evtchn_mask),
+           sizeof(shared_info(d, evtchn_mask)));
+}
+
+static long evtchn_register_3level(evtchn_register_3level_t *arg)
+{
+    struct domain *d = current->domain;
+    struct vcpu *v;
+    int rc = 0;
+    xen_pfn_t evtchn_pending[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t evtchn_mask[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t l2sel_mfn = 0;
+    xen_pfn_t l2sel_offset = 0;
+
+    if ( d->evtchn_extended )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    if ( arg->nr_vcpus > d->max_vcpus ||
+         arg->nr_pages > EVTCHN_MAX_L3_PAGES )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    memset(evtchn_pending, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+    memset(evtchn_mask, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+
+    rc = -EFAULT; /* common error code for following operations */
+    if ( copy_from_guest(evtchn_pending, arg->evtchn_pending, arg->nr_pages) )
+        goto out;
+    if ( copy_from_guest(evtchn_mask, arg->evtchn_mask, arg->nr_pages) )
+        goto out;
+
+    rc = __map_l3_arrays(d, evtchn_pending, evtchn_mask, arg->nr_pages);
+    if ( rc )
+        goto out;
+
+    for_each_vcpu ( d, v )
+    {
+        int vcpu_id = v->vcpu_id;
+
+        rc = -EFAULT; /* common error code for following operations */
+        if ( unlikely(copy_from_guest_offset(&l2sel_mfn, arg->l2sel_mfns,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+        if ( unlikely(copy_from_guest_offset(&l2sel_offset, arg->l2sel_offsets,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+
+        if ( (rc = __map_l2_selector(v, l2sel_mfn, l2sel_offset)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+    }
+
+    __evtchn_setup_bitmap_l3(d);
+
+    d->evtchn_extended = EVTCHN_EXTENDED_L3;
+
+    rc = 0;
+
+ out:
+    return rc;
+}
+
 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXR-00027O-5o; Wed, 27 Feb 2013 15:03:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXP-00026C-Fa
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:19 +0000
Received: from [85.158.138.51:6461] by server-9.bemta-3.messagelabs.com id
	79/6B-32531-6302E215; Wed, 27 Feb 2013 15:03:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31462 invoked from network); 27 Feb 2013 15:03:17 -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;
	27 Feb 2013 15:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508304"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:46 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Ta;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:10 +0000
Message-ID: <1361975655-22295-18-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 17/22] Infrastructure to manipulate
	3-level event channel 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

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/event_channel.c |  170 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 170 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 807f05f..26daa7e 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1034,6 +1034,176 @@ out:
 }
 
 
+static long __map_l3_arrays(struct domain *d, xen_pfn_t *pending,
+                            xen_pfn_t *mask, int nr_pages)
+{
+    int rc = -ENOMEM;
+    void *mapping;
+
+    mapping = vmap(pending, nr_pages);
+    if ( !mapping )
+        goto out;
+    d->evtchn_pending = mapping;
+
+    mapping = vmap(mask, nr_pages);
+    if ( !mapping )
+    {
+        vunmap(d->evtchn_pending);
+        d->evtchn_pending = NULL;
+        goto out;
+    }
+    d->evtchn_mask = mapping;
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+static void __unmap_l3_arrays(struct domain *d)
+{
+    if ( d->evtchn_pending )
+    {
+        vunmap(d->evtchn_pending);
+        d->evtchn_pending = NULL;
+    }
+
+    if ( d->evtchn_mask )
+    {
+        vunmap(d->evtchn_mask);
+        d->evtchn_mask = NULL;
+    }
+}
+
+static long __map_l2_selector(struct vcpu *v, unsigned long gfn,
+                              unsigned long off)
+{
+    int rc = -ENOMEM;
+    void *mapping;
+
+    mapping = vmap(&gfn, 1);
+
+    if ( mapping == NULL )
+        goto out;
+
+    v->evtchn_pending_sel_l2 = mapping + off;
+    rc = 0;
+
+ out:
+    return rc;
+}
+
+static void __unmap_l2_selector(struct vcpu *v)
+{
+    if ( v->evtchn_pending_sel_l2 )
+    {
+        unsigned long addr =
+            (unsigned long)(v->evtchn_pending_sel_l2) & PAGE_MASK;
+        vunmap((void *)addr);
+        v->evtchn_pending_sel_l2 = NULL;
+    }
+}
+
+static void __evtchn_unmap_all_3level(struct domain *d)
+{
+    struct vcpu *v;
+    for_each_vcpu ( d, v )
+        __unmap_l2_selector(v);
+    __unmap_l3_arrays(d);
+}
+
+static void __evtchn_setup_bitmap_l3(struct domain *d)
+{
+    struct vcpu *v;
+
+    /* Easy way to setup 3-level bitmap, just move existing selector
+     * to next level then copy pending array and mask array */
+    for_each_vcpu ( d, v )
+    {
+        memcpy(&v->evtchn_pending_sel_l2[0],
+               &vcpu_info(v, evtchn_pending_sel),
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        memset(&vcpu_info(v, evtchn_pending_sel), 0,
+               sizeof(vcpu_info(v, evtchn_pending_sel)));
+        set_bit(0, &vcpu_info(v, evtchn_pending_sel));
+    }
+
+    memcpy(d->evtchn_pending, &shared_info(d, evtchn_pending),
+           sizeof(shared_info(d, evtchn_pending)));
+    memcpy(d->evtchn_mask, &shared_info(d, evtchn_mask),
+           sizeof(shared_info(d, evtchn_mask)));
+}
+
+static long evtchn_register_3level(evtchn_register_3level_t *arg)
+{
+    struct domain *d = current->domain;
+    struct vcpu *v;
+    int rc = 0;
+    xen_pfn_t evtchn_pending[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t evtchn_mask[EVTCHN_MAX_L3_PAGES];
+    xen_pfn_t l2sel_mfn = 0;
+    xen_pfn_t l2sel_offset = 0;
+
+    if ( d->evtchn_extended )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    if ( arg->nr_vcpus > d->max_vcpus ||
+         arg->nr_pages > EVTCHN_MAX_L3_PAGES )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    memset(evtchn_pending, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+    memset(evtchn_mask, 0, sizeof(xen_pfn_t) * EVTCHN_MAX_L3_PAGES);
+
+    rc = -EFAULT; /* common error code for following operations */
+    if ( copy_from_guest(evtchn_pending, arg->evtchn_pending, arg->nr_pages) )
+        goto out;
+    if ( copy_from_guest(evtchn_mask, arg->evtchn_mask, arg->nr_pages) )
+        goto out;
+
+    rc = __map_l3_arrays(d, evtchn_pending, evtchn_mask, arg->nr_pages);
+    if ( rc )
+        goto out;
+
+    for_each_vcpu ( d, v )
+    {
+        int vcpu_id = v->vcpu_id;
+
+        rc = -EFAULT; /* common error code for following operations */
+        if ( unlikely(copy_from_guest_offset(&l2sel_mfn, arg->l2sel_mfns,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+        if ( unlikely(copy_from_guest_offset(&l2sel_offset, arg->l2sel_offsets,
+                                             vcpu_id, 1)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+
+        if ( (rc = __map_l2_selector(v, l2sel_mfn, l2sel_offset)) )
+        {
+            __evtchn_unmap_all_3level(d);
+            goto out;
+        }
+    }
+
+    __evtchn_setup_bitmap_l3(d);
+
+    d->evtchn_extended = EVTCHN_EXTENDED_L3;
+
+    rc = 0;
+
+ out:
+    return rc;
+}
+
 long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXT-00029L-Pv; Wed, 27 Feb 2013 15:03:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXS-00026o-Bw
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:22 +0000
Received: from [85.158.138.51:6865] by server-10.bemta-3.messagelabs.com id
	DE/6A-19664-A302E215; Wed, 27 Feb 2013 15:03:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31830 invoked from network); 27 Feb 2013 15:03:21 -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;
	27 Feb 2013 15:03:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508344"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:03:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:03:03 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5L-0007G7-2k;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:14 +0000
Message-ID: <1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event channel
	on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 non-Dom0 domains, add a flag to indicate whether it can use extended event
channel, admins can specify this flag when creating a driver domain.

The rationale behide this option is, a) extended event channel will
consume global mapping space in Xen, b) likely that only Dom0 and driver
domains need this.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/domain.c         |    3 +++
 xen/common/domctl.c         |    5 ++++-
 xen/common/event_channel.c  |    6 +++++-
 xen/include/public/domctl.h |    3 +++
 xen/include/xen/sched.h     |    5 +++++
 5 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 07f62b3..293e4b1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -250,6 +250,9 @@ struct domain *domain_create(
     if ( domcr_flags & DOMCRF_dummy )
         return d;
 
+    if ( domcr_flags & DOMCRF_evtchn_extended )
+        d->evtchn_extended_allowed = 1;
+
     if ( !is_idle_domain(d) )
     {
         if ( (err = xsm_domain_create(XSM_HOOK, d, ssidref)) != 0 )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a713ce6..09b9752 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -369,7 +369,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         if ( supervisor_mode_kernel ||
              (op->u.createdomain.flags &
              ~(XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap |
-               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off)) )
+               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
+               XEN_DOMCTL_CDF_evtchn_extended)) )
             break;
 
         dom = op->domain;
@@ -405,6 +406,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             domcr_flags |= DOMCRF_s3_integrity;
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
+        if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_evtchn_extended )
+            domcr_flags |= DOMCRF_evtchn_extended;
 
         d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
         if ( IS_ERR(d) )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index fac5dc9..56c4fb0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1291,7 +1291,11 @@ static long evtchn_register_extended(struct evtchn_register_extended *reg)
         rc = extended_event_channel;
         break;
     case EVTCHN_EXTENDED_L3:
-        rc = evtchn_register_3level(&reg->u.l3);
+        if ( d->domain_id != 0 &&
+             d->evtchn_extended_allowed == 0 )
+            rc = -EPERM;
+        else
+            rc = evtchn_register_3level(&reg->u.l3);
         break;
     default:
         rc = -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 74160b0..d5c468e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -59,6 +59,9 @@ struct xen_domctl_createdomain {
  /* Disable out-of-sync shadow page tables? */
 #define _XEN_DOMCTL_CDF_oos_off       3
 #define XEN_DOMCTL_CDF_oos_off        (1U<<_XEN_DOMCTL_CDF_oos_off)
+ /* Can this domain use extended event channel? */
+#define _XEN_DOMCTL_CDF_evtchn_extended 4
+#define XEN_DOMCTL_CDF_evtchn_extended  (1U<<_XEN_DOMCTL_CDF_evtchn_extended)
     uint32_t flags;
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 4a3e51c..d0aba9a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -224,6 +224,8 @@ struct domain
 
     unsigned long   *evtchn_pending;
     unsigned long   *evtchn_mask;
+    /* Can the domain use extended event channel (new ABI)? */
+    bool_t           evtchn_extended_allowed;
 
     struct grant_table *grant_table;
 
@@ -411,6 +413,9 @@ struct domain *domain_create(
  /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables */
 #define _DOMCRF_oos_off         4
 #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
+/* DOMCRF_evtchn_extended: this domain can use extended event channel */
+#define _DOMCRF_evtchn_extended 5
+#define DOMCRF_evtchn_extended  (1U<<_DOMCRF_evtchn_extended)
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXT-00029L-Pv; Wed, 27 Feb 2013 15:03:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXS-00026o-Bw
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:22 +0000
Received: from [85.158.138.51:6865] by server-10.bemta-3.messagelabs.com id
	DE/6A-19664-A302E215; Wed, 27 Feb 2013 15:03:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31830 invoked from network); 27 Feb 2013 15:03:21 -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;
	27 Feb 2013 15:03:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508344"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:03:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:03:03 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5L-0007G7-2k;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:14 +0000
Message-ID: <1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event channel
	on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 non-Dom0 domains, add a flag to indicate whether it can use extended event
channel, admins can specify this flag when creating a driver domain.

The rationale behide this option is, a) extended event channel will
consume global mapping space in Xen, b) likely that only Dom0 and driver
domains need this.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/domain.c         |    3 +++
 xen/common/domctl.c         |    5 ++++-
 xen/common/event_channel.c  |    6 +++++-
 xen/include/public/domctl.h |    3 +++
 xen/include/xen/sched.h     |    5 +++++
 5 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 07f62b3..293e4b1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -250,6 +250,9 @@ struct domain *domain_create(
     if ( domcr_flags & DOMCRF_dummy )
         return d;
 
+    if ( domcr_flags & DOMCRF_evtchn_extended )
+        d->evtchn_extended_allowed = 1;
+
     if ( !is_idle_domain(d) )
     {
         if ( (err = xsm_domain_create(XSM_HOOK, d, ssidref)) != 0 )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a713ce6..09b9752 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -369,7 +369,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         if ( supervisor_mode_kernel ||
              (op->u.createdomain.flags &
              ~(XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap |
-               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off)) )
+               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
+               XEN_DOMCTL_CDF_evtchn_extended)) )
             break;
 
         dom = op->domain;
@@ -405,6 +406,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
             domcr_flags |= DOMCRF_s3_integrity;
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
+        if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_evtchn_extended )
+            domcr_flags |= DOMCRF_evtchn_extended;
 
         d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
         if ( IS_ERR(d) )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index fac5dc9..56c4fb0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1291,7 +1291,11 @@ static long evtchn_register_extended(struct evtchn_register_extended *reg)
         rc = extended_event_channel;
         break;
     case EVTCHN_EXTENDED_L3:
-        rc = evtchn_register_3level(&reg->u.l3);
+        if ( d->domain_id != 0 &&
+             d->evtchn_extended_allowed == 0 )
+            rc = -EPERM;
+        else
+            rc = evtchn_register_3level(&reg->u.l3);
         break;
     default:
         rc = -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 74160b0..d5c468e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -59,6 +59,9 @@ struct xen_domctl_createdomain {
  /* Disable out-of-sync shadow page tables? */
 #define _XEN_DOMCTL_CDF_oos_off       3
 #define XEN_DOMCTL_CDF_oos_off        (1U<<_XEN_DOMCTL_CDF_oos_off)
+ /* Can this domain use extended event channel? */
+#define _XEN_DOMCTL_CDF_evtchn_extended 4
+#define XEN_DOMCTL_CDF_evtchn_extended  (1U<<_XEN_DOMCTL_CDF_evtchn_extended)
     uint32_t flags;
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 4a3e51c..d0aba9a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -224,6 +224,8 @@ struct domain
 
     unsigned long   *evtchn_pending;
     unsigned long   *evtchn_mask;
+    /* Can the domain use extended event channel (new ABI)? */
+    bool_t           evtchn_extended_allowed;
 
     struct grant_table *grant_table;
 
@@ -411,6 +413,9 @@ struct domain *domain_create(
  /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables */
 #define _DOMCRF_oos_off         4
 #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
+/* DOMCRF_evtchn_extended: this domain can use extended event channel */
+#define _DOMCRF_evtchn_extended 5
+#define DOMCRF_evtchn_extended  (1U<<_DOMCRF_evtchn_extended)
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXT-000294-EB; Wed, 27 Feb 2013 15:03:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXR-00027W-O3
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:21 +0000
Received: from [85.158.138.51:6718] by server-14.bemta-3.messagelabs.com id
	AF/B7-27076-8302E215; Wed, 27 Feb 2013 15:03:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31739 invoked from network); 27 Feb 2013 15:03:20 -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;
	27 Feb 2013 15:03:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508339"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:03:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:03:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-RJ;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:06 +0000
Message-ID: <1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 470b8d2..abed10d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -36,6 +36,20 @@
 uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
                                    EVTCHN_EXTENDED_L3);
 
+static inline const char * evtchn_abi_str(unsigned int abi)
+{
+    switch ( abi )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        return "2-level";
+    case EVTCHN_EXTENDED_L3:
+        return "3-level";
+    default:
+        BUG();
+    }
+    return ""; /* make compiler happy */
+}
+
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:27 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXT-000294-EB; Wed, 27 Feb 2013 15:03:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXR-00027W-O3
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:21 +0000
Received: from [85.158.138.51:6718] by server-14.bemta-3.messagelabs.com id
	AF/B7-27076-8302E215; Wed, 27 Feb 2013 15:03:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31739 invoked from network); 27 Feb 2013 15:03:20 -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;
	27 Feb 2013 15:03:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508339"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:03:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:03:01 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-RJ;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:06 +0000
Message-ID: <1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 470b8d2..abed10d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -36,6 +36,20 @@
 uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
                                    EVTCHN_EXTENDED_L3);
 
+static inline const char * evtchn_abi_str(unsigned int abi)
+{
+    switch ( abi )
+    {
+    case EVTCHN_EXTENDED_NONE:
+        return "2-level";
+    case EVTCHN_EXTENDED_L3:
+        return "3-level";
+    default:
+        BUG();
+    }
+    return ""; /* make compiler happy */
+}
+
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXT-00028a-0G; Wed, 27 Feb 2013 15:03:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXQ-00026o-M3
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:20 +0000
Received: from [85.158.138.51:6587] by server-10.bemta-3.messagelabs.com id
	9B/5A-19664-7302E215; Wed, 27 Feb 2013 15:03:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31660 invoked from network); 27 Feb 2013 15:03:19 -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;
	27 Feb 2013 15:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508328"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:57 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Sy;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:09 +0000
Message-ID: <1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for event
	channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/asm-arm/types.h  |    7 +++++--
 xen/include/asm-x86/config.h |    4 +++-
 xen/include/xen/event.h      |    6 ++++++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..65562b8 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,10 +41,13 @@ typedef char bool_t;
 #define test_and_clear_bool(b) xchg(&(b), 0)
 
 #endif /* __ASSEMBLY__ */
+#define BYTE_BITORDER  3
+#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
+#define BITS_PER_LONG  (1 << LONG_BITORDER)
 #define LONG_BYTEORDER 2
+#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 
 #endif /* __ARM_TYPES_H__ */
 /*
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 202fda1..a88461b 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -8,11 +8,13 @@
 #define __X86_CONFIG_H__
 
 #define LONG_BYTEORDER 3
+#define BYTE_BITORDER 3
+#define LONG_BITORDER (BYTE_BITORDER + LONG_BYTEORDER)
 #define CONFIG_PAGING_LEVELS 4
 
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
-#define BITS_PER_BYTE 8
+#define BITS_PER_BYTE (1 << BYTE_BITORDER)
 
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 8a38a80..e4fce73 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -42,6 +42,12 @@ static inline unsigned int max_evtchns(struct domain *d)
 #define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS_L3 / EVTCHNS_PER_BUCKET)
 
+#ifndef CONFIG_COMPAT
+#define EVTCHN_WORD_BITORDER(d) LONG_BITORDER
+#else
+#define EVTCHN_WORD_BITORDER(d) (has_32bit_shinfo(d) ? 5 : LONG_BITORDER)
+#endif
+
 struct evtchn
 {
 #define ECS_FREE         0 /* Channel is available for use.                  */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXT-00028a-0G; Wed, 27 Feb 2013 15:03:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXQ-00026o-M3
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:20 +0000
Received: from [85.158.138.51:6587] by server-10.bemta-3.messagelabs.com id
	9B/5A-19664-7302E215; Wed, 27 Feb 2013 15:03:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1361977396!29408121!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31660 invoked from network); 27 Feb 2013 15:03:19 -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;
	27 Feb 2013 15:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9508328"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:57 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5K-0007G7-Sy;
	Wed, 27 Feb 2013 14:34:18 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:09 +0000
Message-ID: <1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for event
	channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/include/asm-arm/types.h  |    7 +++++--
 xen/include/asm-x86/config.h |    4 +++-
 xen/include/xen/event.h      |    6 ++++++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/types.h b/xen/include/asm-arm/types.h
index 48864f9..65562b8 100644
--- a/xen/include/asm-arm/types.h
+++ b/xen/include/asm-arm/types.h
@@ -41,10 +41,13 @@ typedef char bool_t;
 #define test_and_clear_bool(b) xchg(&(b), 0)
 
 #endif /* __ASSEMBLY__ */
+#define BYTE_BITORDER  3
+#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
 
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
+#define BITS_PER_LONG  (1 << LONG_BITORDER)
 #define LONG_BYTEORDER 2
+#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 
 #endif /* __ARM_TYPES_H__ */
 /*
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 202fda1..a88461b 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -8,11 +8,13 @@
 #define __X86_CONFIG_H__
 
 #define LONG_BYTEORDER 3
+#define BYTE_BITORDER 3
+#define LONG_BITORDER (BYTE_BITORDER + LONG_BYTEORDER)
 #define CONFIG_PAGING_LEVELS 4
 
 #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
 #define BITS_PER_LONG (BYTES_PER_LONG << 3)
-#define BITS_PER_BYTE 8
+#define BITS_PER_BYTE (1 << BYTE_BITORDER)
 
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 8a38a80..e4fce73 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -42,6 +42,12 @@ static inline unsigned int max_evtchns(struct domain *d)
 #define EVTCHNS_PER_BUCKET 512
 #define NR_EVTCHN_BUCKETS  (NR_EVENT_CHANNELS_L3 / EVTCHNS_PER_BUCKET)
 
+#ifndef CONFIG_COMPAT
+#define EVTCHN_WORD_BITORDER(d) LONG_BITORDER
+#else
+#define EVTCHN_WORD_BITORDER(d) (has_32bit_shinfo(d) ? 5 : LONG_BITORDER)
+#endif
+
 struct evtchn
 {
 #define ECS_FREE         0 /* Channel is available for use.                  */
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXY-0002Cz-78; Wed, 27 Feb 2013 15:03:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXV-0002A1-Nf
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:26 +0000
Received: from [85.158.137.99:59856] by server-7.bemta-3.messagelabs.com id
	1B/0D-06591-C302E215; Wed, 27 Feb 2013 15:03:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361977371!18402129!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12890 invoked from network); 27 Feb 2013 15:03:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:03:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999599"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:59 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5L-0007G7-1B;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:13 +0000
Message-ID: <1361975655-22295-21-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 20/22] Implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |  107 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 88 insertions(+), 19 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 88679d5..fac5dc9 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -640,10 +640,33 @@ out:
     return ret;
 }
 
+static void __check_vcpu_polling(struct vcpu *v, int port)
+{
+    int vcpuid;
+    struct domain *d = v->domain;
+
+    /* Check if some VCPU might be polling for this event. */
+    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
+        return;
+
+    /* Wake any interested (or potentially interested) pollers. */
+    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
+          vcpuid < d->max_vcpus;
+          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+    {
+        v = d->vcpu[vcpuid];
+        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
+             test_and_clear_bit(vcpuid, d->poll_mask) )
+        {
+            v->poll_evtchn = 0;
+            vcpu_unblock(v);
+        }
+    }
+}
+
 static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
-    int vcpuid;
 
     /*
      * The following bit operations must happen in strict order.
@@ -662,23 +685,33 @@ static void evtchn_set_pending_l2(struct vcpu *v, int port)
         vcpu_mark_events_pending(v);
     }
 
-    /* Check if some VCPU might be polling for this event. */
-    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
-        return;
+    __check_vcpu_polling(v, port);
+}
 
-    /* Wake any interested (or potentially interested) pollers. */
-    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
-          vcpuid < d->max_vcpus;
-          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+static void evtchn_set_pending_l3(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    /*
+     * The following bit operations must happen in strict order.
+     * NB. On x86, the atomic bit operations also act as memory barriers.
+     * There is therefore sufficiently strict ordering for this architecture --
+     * others may require explicit memory barriers.
+     */
+
+    if ( test_and_set_bit(port, d->evtchn_pending) )
+         return;
+
+    if ( !test_bit(port, d->evtchn_mask) &&
+         !test_and_set_bit(l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit(l1bit, &vcpu_info(v, evtchn_pending_sel)) )
     {
-        v = d->vcpu[vcpuid];
-        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
-             test_and_clear_bit(vcpuid, d->poll_mask) )
-        {
-            v->poll_evtchn = 0;
-            vcpu_unblock(v);
-        }
+        vcpu_mark_events_pending(v);
     }
+
+    __check_vcpu_polling(v, port);
 }
 
 static void evtchn_set_pending(struct vcpu *v, int port)
@@ -690,6 +723,9 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     case EVTCHN_EXTENDED_NONE:
         evtchn_set_pending_l2(v, port);
         break;
+    case EVTCHN_EXTENDED_L3:
+        evtchn_set_pending_l3(v, port);
+        break;
     default:
         BUG();
     }
@@ -990,6 +1026,35 @@ static int evtchn_unmask_l2(unsigned int port)
     return 0;
 }
 
+static int evtchn_unmask_l3(unsigned int port)
+{
+    struct domain *d = current->domain;
+    struct vcpu   *v;
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    if ( unlikely(!port_is_valid(d, port)) )
+        return -EINVAL;
+
+    v = d->vcpu[evtchn_from_port(d, port)->notify_vcpu_id];
+
+    /*
+     * These operations must happen in strict order. Based on
+     * include/xen/event.h:evtchn_set_pending().
+     */
+    if ( test_and_clear_bit(port, d->evtchn_mask) &&
+         test_bit          (port, d->evtchn_pending) &&
+         !test_and_set_bit (l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit (l1bit, &vcpu_info(v, evtchn_pending_sel)) )
+    {
+        vcpu_mark_events_pending(v);
+    }
+
+    return 0;
+}
+
 int evtchn_unmask(unsigned int port)
 {
     struct domain *d = current->domain;
@@ -1000,6 +1065,9 @@ int evtchn_unmask(unsigned int port)
     case EVTCHN_EXTENDED_NONE:
         rc = evtchn_unmask_l2(port);
         break;
+    case EVTCHN_EXTENDED_L3:
+        rc = evtchn_unmask_l3(port);
+        break;
     default:
         BUG();
     }
@@ -1347,10 +1415,8 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         if ( copy_from_guest(&reg, arg, 1) != 0 )
             return -EFAULT;
-        rc = evtchn_register_extended(&reg);
 
-        /* XXX always fails this call because it is not yet completed */
-        rc = -EINVAL;
+        rc = evtchn_register_extended(&reg);
 
         break;
     }
@@ -1562,8 +1628,11 @@ static void domain_dump_evtchn_info(struct domain *d)
     bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
                          d->poll_mask, d->max_vcpus);
     printk("Event channel information for domain %d:\n"
+           "Using %s event channel ABI\n"
            "Polling vCPUs: {%s}\n"
-           "    port [p/m]\n", d->domain_id, keyhandler_scratch);
+           "    port [p/m]\n",
+           d->domain_id, evtchn_abi_str(d->evtchn_extended),
+           keyhandler_scratch);
 
     spin_lock(&d->event_lock);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:03:30 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:03: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 1UAiXY-0002Cz-78; Wed, 27 Feb 2013 15:03:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiXV-0002A1-Nf
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:26 +0000
Received: from [85.158.137.99:59856] by server-7.bemta-3.messagelabs.com id
	1B/0D-06591-C302E215; Wed, 27 Feb 2013 15:03:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361977371!18402129!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12890 invoked from network); 27 Feb 2013 15:03:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:03:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999599"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:59 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5L-0007G7-1B;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:13 +0000
Message-ID: <1361975655-22295-21-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 20/22] Implement 3-level event channel
	routines
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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>
---
 xen/common/event_channel.c |  107 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 88 insertions(+), 19 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 88679d5..fac5dc9 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -640,10 +640,33 @@ out:
     return ret;
 }
 
+static void __check_vcpu_polling(struct vcpu *v, int port)
+{
+    int vcpuid;
+    struct domain *d = v->domain;
+
+    /* Check if some VCPU might be polling for this event. */
+    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
+        return;
+
+    /* Wake any interested (or potentially interested) pollers. */
+    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
+          vcpuid < d->max_vcpus;
+          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+    {
+        v = d->vcpu[vcpuid];
+        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
+             test_and_clear_bit(vcpuid, d->poll_mask) )
+        {
+            v->poll_evtchn = 0;
+            vcpu_unblock(v);
+        }
+    }
+}
+
 static void evtchn_set_pending_l2(struct vcpu *v, int port)
 {
     struct domain *d = v->domain;
-    int vcpuid;
 
     /*
      * The following bit operations must happen in strict order.
@@ -662,23 +685,33 @@ static void evtchn_set_pending_l2(struct vcpu *v, int port)
         vcpu_mark_events_pending(v);
     }
 
-    /* Check if some VCPU might be polling for this event. */
-    if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
-        return;
+    __check_vcpu_polling(v, port);
+}
 
-    /* Wake any interested (or potentially interested) pollers. */
-    for ( vcpuid = find_first_bit(d->poll_mask, d->max_vcpus);
-          vcpuid < d->max_vcpus;
-          vcpuid = find_next_bit(d->poll_mask, d->max_vcpus, vcpuid+1) )
+static void evtchn_set_pending_l3(struct vcpu *v, int port)
+{
+    struct domain *d = v->domain;
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    /*
+     * The following bit operations must happen in strict order.
+     * NB. On x86, the atomic bit operations also act as memory barriers.
+     * There is therefore sufficiently strict ordering for this architecture --
+     * others may require explicit memory barriers.
+     */
+
+    if ( test_and_set_bit(port, d->evtchn_pending) )
+         return;
+
+    if ( !test_bit(port, d->evtchn_mask) &&
+         !test_and_set_bit(l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit(l1bit, &vcpu_info(v, evtchn_pending_sel)) )
     {
-        v = d->vcpu[vcpuid];
-        if ( ((v->poll_evtchn <= 0) || (v->poll_evtchn == port)) &&
-             test_and_clear_bit(vcpuid, d->poll_mask) )
-        {
-            v->poll_evtchn = 0;
-            vcpu_unblock(v);
-        }
+        vcpu_mark_events_pending(v);
     }
+
+    __check_vcpu_polling(v, port);
 }
 
 static void evtchn_set_pending(struct vcpu *v, int port)
@@ -690,6 +723,9 @@ static void evtchn_set_pending(struct vcpu *v, int port)
     case EVTCHN_EXTENDED_NONE:
         evtchn_set_pending_l2(v, port);
         break;
+    case EVTCHN_EXTENDED_L3:
+        evtchn_set_pending_l3(v, port);
+        break;
     default:
         BUG();
     }
@@ -990,6 +1026,35 @@ static int evtchn_unmask_l2(unsigned int port)
     return 0;
 }
 
+static int evtchn_unmask_l3(unsigned int port)
+{
+    struct domain *d = current->domain;
+    struct vcpu   *v;
+    unsigned int l1bit = port >> (EVTCHN_WORD_BITORDER(d) << 1);
+    unsigned int l2bit = port >> EVTCHN_WORD_BITORDER(d);
+
+    ASSERT(spin_is_locked(&d->event_lock));
+
+    if ( unlikely(!port_is_valid(d, port)) )
+        return -EINVAL;
+
+    v = d->vcpu[evtchn_from_port(d, port)->notify_vcpu_id];
+
+    /*
+     * These operations must happen in strict order. Based on
+     * include/xen/event.h:evtchn_set_pending().
+     */
+    if ( test_and_clear_bit(port, d->evtchn_mask) &&
+         test_bit          (port, d->evtchn_pending) &&
+         !test_and_set_bit (l2bit, v->evtchn_pending_sel_l2) &&
+         !test_and_set_bit (l1bit, &vcpu_info(v, evtchn_pending_sel)) )
+    {
+        vcpu_mark_events_pending(v);
+    }
+
+    return 0;
+}
+
 int evtchn_unmask(unsigned int port)
 {
     struct domain *d = current->domain;
@@ -1000,6 +1065,9 @@ int evtchn_unmask(unsigned int port)
     case EVTCHN_EXTENDED_NONE:
         rc = evtchn_unmask_l2(port);
         break;
+    case EVTCHN_EXTENDED_L3:
+        rc = evtchn_unmask_l3(port);
+        break;
     default:
         BUG();
     }
@@ -1347,10 +1415,8 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         if ( copy_from_guest(&reg, arg, 1) != 0 )
             return -EFAULT;
-        rc = evtchn_register_extended(&reg);
 
-        /* XXX always fails this call because it is not yet completed */
-        rc = -EINVAL;
+        rc = evtchn_register_extended(&reg);
 
         break;
     }
@@ -1562,8 +1628,11 @@ static void domain_dump_evtchn_info(struct domain *d)
     bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
                          d->poll_mask, d->max_vcpus);
     printk("Event channel information for domain %d:\n"
+           "Using %s event channel ABI\n"
            "Polling vCPUs: {%s}\n"
-           "    port [p/m]\n", d->domain_id, keyhandler_scratch);
+           "    port [p/m]\n",
+           d->domain_id, evtchn_abi_str(d->evtchn_extended),
+           keyhandler_scratch);
 
     spin_lock(&d->event_lock);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:04:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:04: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 1UAiY3-0002d7-Ii; Wed, 27 Feb 2013 15:03:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiY1-0002av-Dx
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:57 +0000
Received: from [85.158.138.51:27271] by server-7.bemta-3.messagelabs.com id
	88/1E-06591-C502E215; Wed, 27 Feb 2013 15:03:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361977361!23481024!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27143 invoked from network); 27 Feb 2013 15:02:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999514"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:41 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5L-0007G7-3L;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:15 +0000
Message-ID: <1361975655-22295-23-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 22/22] libxl: add evtchn_extended flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Admins can add "evtchn_extended = 1" in domain config file to enable extended
event channel ABI for a domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl_create.c  |    4 ++++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    2 ++
 tools/libxl/xl_sxp.c        |    2 ++
 4 files changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa81f88..724e038 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -35,6 +35,8 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&c_info->oos, true);
     }
 
+    libxl_defbool_setdefault(&c_info->evtchn_extended, false);
+
     libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
 
     return 0;
@@ -391,6 +393,8 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
         flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
         flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
+    flags |= libxl_defbool_val(info->evtchn_extended) ?
+             XEN_DOMCTL_CDF_evtchn_extended : 0;
     *domid = -1;
 
     /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 89a8030..37a20c4 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -236,6 +236,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
     ("hap",          libxl_defbool),
     ("oos",          libxl_defbool),
+    ("evtchn_extended",libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..9a1dd1b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -651,6 +651,8 @@ static void parse_config_data(const char *config_source,
 
     xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
+    xlu_cfg_get_defbool(config, "evtchn_extended", &c_info->evtchn_extended, 0);
+
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
diff --git a/tools/libxl/xl_sxp.c b/tools/libxl/xl_sxp.c
index a16a025..6d40e7a 100644
--- a/tools/libxl/xl_sxp.c
+++ b/tools/libxl/xl_sxp.c
@@ -44,6 +44,8 @@ void printf_info_sexp(int domid, libxl_domain_config *d_config)
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
     printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
     printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
+    printf("\t(evtchn_extended %s)\n",
+           libxl_defbool_to_string(c_info->evtchn_extended));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:04:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:04: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 1UAiY3-0002d7-Ii; Wed, 27 Feb 2013 15:03:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAiY1-0002av-Dx
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:03:57 +0000
Received: from [85.158.138.51:27271] by server-7.bemta-3.messagelabs.com id
	88/1E-06591-C502E215; Wed, 27 Feb 2013 15:03:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1361977361!23481024!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDA5MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27143 invoked from network); 27 Feb 2013 15:02:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9999514"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:02:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:02:41 -0500
Received: from dt47.uk.xensource.com ([10.80.229.47])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAi5L-0007G7-3L;
	Wed, 27 Feb 2013 14:34:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xen.org>, <jbeulich@suse.com>, <keir@xen.org>,
	<ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 14:34:15 +0000
Message-ID: <1361975655-22295-23-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.10.4
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, david.vrabel@citrix.com
Subject: [Xen-devel] [RFC PATCH V3 22/22] libxl: add evtchn_extended flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Admins can add "evtchn_extended = 1" in domain config file to enable extended
event channel ABI for a domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl_create.c  |    4 ++++
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/xl_cmdimpl.c    |    2 ++
 tools/libxl/xl_sxp.c        |    2 ++
 4 files changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fa81f88..724e038 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -35,6 +35,8 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
         libxl_defbool_setdefault(&c_info->oos, true);
     }
 
+    libxl_defbool_setdefault(&c_info->evtchn_extended, false);
+
     libxl_defbool_setdefault(&c_info->run_hotplug_scripts, true);
 
     return 0;
@@ -391,6 +393,8 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info,
         flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
         flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
+    flags |= libxl_defbool_val(info->evtchn_extended) ?
+             XEN_DOMCTL_CDF_evtchn_extended : 0;
     *domid = -1;
 
     /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 89a8030..37a20c4 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -236,6 +236,7 @@ libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
     ("hap",          libxl_defbool),
     ("oos",          libxl_defbool),
+    ("evtchn_extended",libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 003b129..9a1dd1b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -651,6 +651,8 @@ static void parse_config_data(const char *config_source,
 
     xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
+    xlu_cfg_get_defbool(config, "evtchn_extended", &c_info->evtchn_extended, 0);
+
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
diff --git a/tools/libxl/xl_sxp.c b/tools/libxl/xl_sxp.c
index a16a025..6d40e7a 100644
--- a/tools/libxl/xl_sxp.c
+++ b/tools/libxl/xl_sxp.c
@@ -44,6 +44,8 @@ void printf_info_sexp(int domid, libxl_domain_config *d_config)
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
     printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
     printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
+    printf("\t(evtchn_extended %s)\n",
+           libxl_defbool_to_string(c_info->evtchn_extended));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:40:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:40: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 1UAj7O-0004YQ-2T; Wed, 27 Feb 2013 15:40:30 +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 1UAj7N-0004YL-69
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:40:29 +0000
Received: from [85.158.139.83:5119] by server-8.bemta-5.messagelabs.com id
	F4/C3-05790-CE82E215; Wed, 27 Feb 2013 15:40:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361979617!24037394!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUyMTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13981 invoked from network); 27 Feb 2013 15:40:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 15:40:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RFe62c013366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 15:40:07 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
	r1RFe4al008714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 15:40:05 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
	r1RFe4J9023873; Wed, 27 Feb 2013 09:40:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 07:40:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4A29C1C3935; Wed, 27 Feb 2013 10:40:02 -0500 (EST)
Date: Wed, 27 Feb 2013 10:40:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130227154002.GE24932@phenom.dumpdata.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
	<512DE213.3050001@asianux.com>
	<512DF1DF02000078000C16A4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512DF1DF02000078000C16A4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: stefano.stabellini@eu.citrix.com, Chen Gang <gang.chen@asianux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCBGZWIgMjcsIDIwMTMgYXQgMTA6NDU6MzVBTSArMDAwMCwgSmFuIEJldWxpY2ggd3Jv
dGU6Cj4gPj4+IE9uIDI3LjAyLjEzIGF0IDExOjM4LCBDaGVuIEdhbmcgPGdhbmcuY2hlbkBhc2lh
bnV4LmNvbT4gd3JvdGU6Cj4gPiDkuo4gMjAxM+W5tDAy5pyIMjfml6UgMTc6NTcsIEphbiBCZXVs
aWNoIOWGmemBkzoKPiA+PiBZb3UgYWxzbyBjb3VsZCBoYXZlIG1lbnRpb25lZCB0aGF0IGV2ZW4g
YmVmb3JlIGNvbW1pdCAKPiA+PiAwMWM2ODFkNGM3MGQ2NGNiNzIxNDJhMjgyM2YyN2M0MTQ2YTAy
ZTYzIHRoZSB2YWx1ZSBwcmludGVkCj4gPj4gaGVyZSB3YXMgYm9ndXMsIGFzIGl0IHdhcyB0aGUg
Z3Vlc3QgcHJvdmlkZWQgdmFsdWUgZnJvbQo+ID4+IHJlcS0+dS5ydy5oYW5kbGUgcmF0aGVyIHRo
YW4gdGhlIGFjdHVhbCBkZXZpY2UuCj4gPiAKPiA+ICAgcGFyZG9uID8KPiA+IAo+ID4gICBJIGd1
ZXNzIHdoYXQgeW91IHNhaWQgaXMgOgo+ID4gICAgIG15IHBhdGNoIHNlZW1zIG9rLCBidXQgdGhl
IGNvbW1lbnRzIG5lZWQgaW1wcm92aW5nLgo+ID4gICAgIG5lZWQgYWRkICJhZGRpdGlvbmFsIGlu
Zm8iIGluIGNvbW1lbnRzOgo+ID4gICAgICAgImJlZm9yZSBjb21taXQgMDFjNjgxZDRjNzBkNjRj
YjcyMTQyYTI4MjNmMjdjNDE0NmEwMmU2Mwo+ID4gICAgICAgIHRoZSB2YWx1ZSBwcmludGVkIGhl
cmUgd2FzIGJvZ3VzLCBhcyBpdCB3YXMgdGhlIGd1ZXN0Cj4gPiAgICAgICAgcHJvdmlkZWQgdmFs
dWUgZnJvbSByZXEtPnUucncuaGFuZGxlIHJhdGhlciB0aGFuIHRoZQo+ID4gICAgICAgIGFjdHVh
bCBkZXZpY2UiLgo+ID4gCj4gPiAgIGlzIGl0IGNvcnJlY3QgPwo+IAo+IFllcyAoYW5kIHlvdSBt
aWdodCBoYXZlIG1pc3NlZCB0aGUgQUNLIHRoYXQgSSBoYWQgYWxyZWFkeSBzZW50Cj4gYmVmb3Jl
IHRoaXMgcmVwbHkgLSB0aGF0IG1haWwgZ290IGJvdW5jZWQgZm9yIHlvdXIgYWRkcmVzcykuCgpZ
dXAuIENoZW4sIGNvdWxkIHlvdSByZXNwaW4gdGhlIHBhdGNoIHdpdGggdGhlIGV4dHJhIGNvbW1l
bnQgYW5kCnRoZSBBY2sgZnJvbSBKYW4gcGxlYXNlPwoKVGhhbmsgeW91IQo+IAo+IEphbgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:40:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:40: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 1UAj7O-0004YQ-2T; Wed, 27 Feb 2013 15:40:30 +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 1UAj7N-0004YL-69
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:40:29 +0000
Received: from [85.158.139.83:5119] by server-8.bemta-5.messagelabs.com id
	F4/C3-05790-CE82E215; Wed, 27 Feb 2013 15:40:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361979617!24037394!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUyMTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13981 invoked from network); 27 Feb 2013 15:40:18 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 15:40:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RFe62c013366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 15:40:07 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
	r1RFe4al008714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 15:40:05 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
	r1RFe4J9023873; Wed, 27 Feb 2013 09:40:04 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 07:40:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4A29C1C3935; Wed, 27 Feb 2013 10:40:02 -0500 (EST)
Date: Wed, 27 Feb 2013 10:40:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130227154002.GE24932@phenom.dumpdata.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
	<512DE213.3050001@asianux.com>
	<512DF1DF02000078000C16A4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512DF1DF02000078000C16A4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: stefano.stabellini@eu.citrix.com, Chen Gang <gang.chen@asianux.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
 without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gV2VkLCBGZWIgMjcsIDIwMTMgYXQgMTA6NDU6MzVBTSArMDAwMCwgSmFuIEJldWxpY2ggd3Jv
dGU6Cj4gPj4+IE9uIDI3LjAyLjEzIGF0IDExOjM4LCBDaGVuIEdhbmcgPGdhbmcuY2hlbkBhc2lh
bnV4LmNvbT4gd3JvdGU6Cj4gPiDkuo4gMjAxM+W5tDAy5pyIMjfml6UgMTc6NTcsIEphbiBCZXVs
aWNoIOWGmemBkzoKPiA+PiBZb3UgYWxzbyBjb3VsZCBoYXZlIG1lbnRpb25lZCB0aGF0IGV2ZW4g
YmVmb3JlIGNvbW1pdCAKPiA+PiAwMWM2ODFkNGM3MGQ2NGNiNzIxNDJhMjgyM2YyN2M0MTQ2YTAy
ZTYzIHRoZSB2YWx1ZSBwcmludGVkCj4gPj4gaGVyZSB3YXMgYm9ndXMsIGFzIGl0IHdhcyB0aGUg
Z3Vlc3QgcHJvdmlkZWQgdmFsdWUgZnJvbQo+ID4+IHJlcS0+dS5ydy5oYW5kbGUgcmF0aGVyIHRo
YW4gdGhlIGFjdHVhbCBkZXZpY2UuCj4gPiAKPiA+ICAgcGFyZG9uID8KPiA+IAo+ID4gICBJIGd1
ZXNzIHdoYXQgeW91IHNhaWQgaXMgOgo+ID4gICAgIG15IHBhdGNoIHNlZW1zIG9rLCBidXQgdGhl
IGNvbW1lbnRzIG5lZWQgaW1wcm92aW5nLgo+ID4gICAgIG5lZWQgYWRkICJhZGRpdGlvbmFsIGlu
Zm8iIGluIGNvbW1lbnRzOgo+ID4gICAgICAgImJlZm9yZSBjb21taXQgMDFjNjgxZDRjNzBkNjRj
YjcyMTQyYTI4MjNmMjdjNDE0NmEwMmU2Mwo+ID4gICAgICAgIHRoZSB2YWx1ZSBwcmludGVkIGhl
cmUgd2FzIGJvZ3VzLCBhcyBpdCB3YXMgdGhlIGd1ZXN0Cj4gPiAgICAgICAgcHJvdmlkZWQgdmFs
dWUgZnJvbSByZXEtPnUucncuaGFuZGxlIHJhdGhlciB0aGFuIHRoZQo+ID4gICAgICAgIGFjdHVh
bCBkZXZpY2UiLgo+ID4gCj4gPiAgIGlzIGl0IGNvcnJlY3QgPwo+IAo+IFllcyAoYW5kIHlvdSBt
aWdodCBoYXZlIG1pc3NlZCB0aGUgQUNLIHRoYXQgSSBoYWQgYWxyZWFkeSBzZW50Cj4gYmVmb3Jl
IHRoaXMgcmVwbHkgLSB0aGF0IG1haWwgZ290IGJvdW5jZWQgZm9yIHlvdXIgYWRkcmVzcykuCgpZ
dXAuIENoZW4sIGNvdWxkIHlvdSByZXNwaW4gdGhlIHBhdGNoIHdpdGggdGhlIGV4dHJhIGNvbW1l
bnQgYW5kCnRoZSBBY2sgZnJvbSBKYW4gcGxlYXNlPwoKVGhhbmsgeW91IQo+IAo+IEphbgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:41:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:41: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 1UAj7z-0004ex-GN; Wed, 27 Feb 2013 15:41: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 1UAj7x-0004cx-TM
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 15:41:06 +0000
Received: from [85.158.143.99:41853] by server-3.bemta-4.messagelabs.com id
	EF/F9-02186-1192E215; Wed, 27 Feb 2013 15:41:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361979662!29029853!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 844 invoked from network); 27 Feb 2013 15:41:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1962713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 15:41: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.297.1; Wed, 27 Feb 2013 15:41:02 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAj7u-0007FF-3J;
	Wed, 27 Feb 2013 15:41:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAj7t-0005b2-O8;
	Wed, 27 Feb 2013 15:41:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16759-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 15:41:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16759: 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 16759 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16759/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16678

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemut-win  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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
baseline version:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Marek Marczykowski <marmarek@invisiblethingslab.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
+ branch=xen-4.1-testing
+ revision=1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.1-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.1-testing
+ xenversion=xen-4.1
+ xenversion=4.1
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 1f0ffb6d2deeb5c4f0744527da542dc6e46772cd:stable-4.1
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6743c50..1f0ffb6  1f0ffb6d2deeb5c4f0744527da542dc6e46772cd -> stable-4.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:41:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:41: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 1UAj7z-0004ex-GN; Wed, 27 Feb 2013 15:41: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 1UAj7x-0004cx-TM
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 15:41:06 +0000
Received: from [85.158.143.99:41853] by server-3.bemta-4.messagelabs.com id
	EF/F9-02186-1192E215; Wed, 27 Feb 2013 15:41:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1361979662!29029853!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 844 invoked from network); 27 Feb 2013 15:41:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1962713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 15:41: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.297.1; Wed, 27 Feb 2013 15:41:02 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAj7u-0007FF-3J;
	Wed, 27 Feb 2013 15:41:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAj7t-0005b2-O8;
	Wed, 27 Feb 2013 15:41:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16759-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 15:41:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 16759: 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 16759 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16759/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16678

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 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-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemut-win  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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-i386-i386-qemut-win     16 leak-check/check             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-qemut-win   16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
baseline version:
 xen                  6743c50ca91da63de23ad52f037bf9eadacfb492

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Marek Marczykowski <marmarek@invisiblethingslab.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-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-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-i386-i386-qemut-win                                     fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-i386-i386-xl-qemut-win                                  fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             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=1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
+ branch=xen-4.1-testing
+ revision=1f0ffb6d2deeb5c4f0744527da542dc6e46772cd
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ 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
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-4.1-testing.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ xenversion=xen-4.1-testing
+ xenversion=xen-4.1
+ xenversion=4.1
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 1f0ffb6d2deeb5c4f0744527da542dc6e46772cd:stable-4.1
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6743c50..1f0ffb6  1f0ffb6d2deeb5c4f0744527da542dc6e46772cd -> stable-4.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:41:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:41: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 1UAj8B-0004gG-Tl; Wed, 27 Feb 2013 15:41: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 1UAj89-0004g0-Ir
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:41:17 +0000
Received: from [85.158.139.211:64262] by server-5.bemta-5.messagelabs.com id
	E9/6D-02762-C192E215; Wed, 27 Feb 2013 15:41:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361979672!19577564!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUyMTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8645 invoked from network); 27 Feb 2013 15:41:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 15:41:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RFf9C0015047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 15:41: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
	r1RFf78Z021367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 15:41:08 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
	r1RFf7RR024864; Wed, 27 Feb 2013 09:41:07 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 07:41:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3AE161C3935; Wed, 27 Feb 2013 10:41:06 -0500 (EST)
Date: Wed, 27 Feb 2013 10:41:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Michal Fiala <fiala@mfiala.net>
Message-ID: <20130227154106.GF24932@phenom.dumpdata.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
	<20130226220100.GA22418@phenom.dumpdata.com>
	<512DD37102000078000C1569@nat28.tlf.novell.com>
	<512DDB13.5000105@mfiala.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512DDB13.5000105@mfiala.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 11:08:19AM +0100, Michal Fiala wrote:
> On 02/27/2013 09:35 AM, Jan Beulich wrote:
> >>>> On 26.02.13 at 23:01, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> The thing is is that native_machine_emergency_restart is not suppose
> >> to be called. The baremetal machine_ops has that, but we over-write
> >> it with our own and he should get:
> >>
> >>          .emergency_restart = xen_emergency_restart,
> >>
> >> ! So how did his .emergency_restart value get over-written by
> >> native_machine_emergency_restart?
> > 
> > Indeed. So perhaps the -hardened tag indicates some patching
> > having gone on that we're unaware of. Michal - without knowing
> > what your kernel does, I don't think we can really help. And
> > please remember that this is xen-devel, not xen-users, so we
> > expect you to be able to do at least a minimal share of the work
> > needed to find out what is going on. First step would probably
> > be to try plain 3.7.5 (or subsequent 3.7.x).
> > 
> > Jan
> > 
> 
> We are using gentoo hardened sources (kernel). Hardened-sources is based
> on the official Linux kernel and is targeted at our users running Gentoo
> on server systems. It provides patches for the various subprojects of
> Gentoo Hardened (such as support for LSM/SELinux and grsecurity),
> together with stability/security-enhancements.
> See http://www.gentoo.org/doc/en/gentoo-kernel.xml
> 
> I will try gentoo-sources (lightly patched to fix security problems,
> kernel bugs, and to increase compatibility with the more uncommon system
> architectures) and vanilla-sources (official kernel sources released on
> http://www.kernel.org/)

Excellent. Thanks.
> 
> Thanks
> 
> Michal
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 15:41:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:41: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 1UAj8B-0004gG-Tl; Wed, 27 Feb 2013 15:41: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 1UAj89-0004g0-Ir
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:41:17 +0000
Received: from [85.158.139.211:64262] by server-5.bemta-5.messagelabs.com id
	E9/6D-02762-C192E215; Wed, 27 Feb 2013 15:41:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1361979672!19577564!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjUyMTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8645 invoked from network); 27 Feb 2013 15:41:14 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 15:41:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RFf9C0015047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 15:41: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
	r1RFf78Z021367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 15:41:08 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
	r1RFf7RR024864; Wed, 27 Feb 2013 09:41:07 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 07:41:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3AE161C3935; Wed, 27 Feb 2013 10:41:06 -0500 (EST)
Date: Wed, 27 Feb 2013 10:41:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Michal Fiala <fiala@mfiala.net>
Message-ID: <20130227154106.GF24932@phenom.dumpdata.com>
References: <512CC78B.4080606@mfiala.net>
	<512CEB5C02000078000C1272@nat28.tlf.novell.com>
	<512CE2C6.3040907@mfiala.net>
	<512CF1E702000078000C12C7@nat28.tlf.novell.com>
	<512CE581.7020308@mfiala.net>
	<512CF62C02000078000C12F1@nat28.tlf.novell.com>
	<20130226220100.GA22418@phenom.dumpdata.com>
	<512DD37102000078000C1569@nat28.tlf.novell.com>
	<512DDB13.5000105@mfiala.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512DDB13.5000105@mfiala.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2.1, linux kernel 3.7.5 crashed while reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 11:08:19AM +0100, Michal Fiala wrote:
> On 02/27/2013 09:35 AM, Jan Beulich wrote:
> >>>> On 26.02.13 at 23:01, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> The thing is is that native_machine_emergency_restart is not suppose
> >> to be called. The baremetal machine_ops has that, but we over-write
> >> it with our own and he should get:
> >>
> >>          .emergency_restart = xen_emergency_restart,
> >>
> >> ! So how did his .emergency_restart value get over-written by
> >> native_machine_emergency_restart?
> > 
> > Indeed. So perhaps the -hardened tag indicates some patching
> > having gone on that we're unaware of. Michal - without knowing
> > what your kernel does, I don't think we can really help. And
> > please remember that this is xen-devel, not xen-users, so we
> > expect you to be able to do at least a minimal share of the work
> > needed to find out what is going on. First step would probably
> > be to try plain 3.7.5 (or subsequent 3.7.x).
> > 
> > Jan
> > 
> 
> We are using gentoo hardened sources (kernel). Hardened-sources is based
> on the official Linux kernel and is targeted at our users running Gentoo
> on server systems. It provides patches for the various subprojects of
> Gentoo Hardened (such as support for LSM/SELinux and grsecurity),
> together with stability/security-enhancements.
> See http://www.gentoo.org/doc/en/gentoo-kernel.xml
> 
> I will try gentoo-sources (lightly patched to fix security problems,
> kernel bugs, and to increase compatibility with the more uncommon system
> architectures) and vanilla-sources (official kernel sources released on
> http://www.kernel.org/)

Excellent. Thanks.
> 
> Thanks
> 
> Michal
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 15:50:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAjH8-0005AP-7V; Wed, 27 Feb 2013 15:50:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAjH7-0005AK-5B
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:50:33 +0000
Received: from [85.158.137.99:22196] by server-16.bemta-3.messagelabs.com id
	90/4A-20692-33B2E215; Wed, 27 Feb 2013 15:50:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361980207!17549518!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5506 invoked from network); 27 Feb 2013 15:50:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9523527"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:50:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:50:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAjFq-0008MQ-3I;
	Wed, 27 Feb 2013 15:49:14 +0000
Message-ID: <1361980154.2109.67.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 27 Feb 2013 15:49:14 +0000
In-Reply-To: <512DB83A.6050503@oracle.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
> 
> On 2013-2-26 20:35, Wei Liu wrote:
> > On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> >> On 2013-2-16 0:00, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> >>> ---
> >>>    drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
> >>>    1 file changed, 174 insertions(+), 72 deletions(-)
> >>>
> >>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>> index 8bd75a1..de73a71 100644
> >>> --- a/drivers/net/xen-netfront.c
> >>> +++ b/drivers/net/xen-netfront.c
> >>> @@ -67,9 +67,19 @@ struct netfront_cb {
> >>>
> >>>    #define GRANT_INVALID_REF   0
> >>>
> >>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> >>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> >>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> >>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> >>> +#define XENNET_MAX_RING_PAGES      (1U<<   XENNET_MAX_RING_PAGE_ORDER)
> >>> +
> >>> +
> >>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
> >>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> >>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
> >>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> >>> +
> >>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>> +
> >>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> >> Not using multi-page ring here?
> >> In xennet_create_dev, gnttab_alloc_grant_references allocates
> >> TX_MAX_TARGET number of grant reference for tx. In
> >> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> >> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> >> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> >> skb_entry_is_link helps to not release invalid grants, lots of null loop
> >> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> >> variableconnected with np->tx_ring_pages. Or you intended to use one
> >> page ring here?
> >>
> > Looking back my history, this limitation was introduced because if we
> > have a multi-page backend and single page frontend, the backend skb
> > processing could overlap.
> 
> I did not see the overlap you mentioned here in netback. Although 
> netback supports multi-page, netback->vif still uses single page if the 
> frontend only supports single page. Netfront and netback negotiate this 
> through xenstore in your 5/8 patch. The requests and response should not 
> have any overlap between netback and netfront. Am I missing something?
> 

I tried to dig up mail archive just now and realized that the bug report
was in private mail exchange with Konrad.

I don't really remember the details now since it is more than one year
old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
remember is that this bug was triggered by mixed old/new
frontend/backend.

I think this cap can be removed if we make all buffers in netfront
dynamically allocated.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:50:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15: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 1UAjH8-0005AP-7V; Wed, 27 Feb 2013 15:50:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UAjH7-0005AK-5B
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:50:33 +0000
Received: from [85.158.137.99:22196] by server-16.bemta-3.messagelabs.com id
	90/4A-20692-33B2E215; Wed, 27 Feb 2013 15:50:11 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1361980207!17549518!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5506 invoked from network); 27 Feb 2013 15:50:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9523527"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 15:50:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 10:50:06 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAjFq-0008MQ-3I;
	Wed, 27 Feb 2013 15:49:14 +0000
Message-ID: <1361980154.2109.67.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Wed, 27 Feb 2013 15:49:14 +0000
In-Reply-To: <512DB83A.6050503@oracle.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
> 
> On 2013-2-26 20:35, Wei Liu wrote:
> > On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> >> On 2013-2-16 0:00, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> >>> ---
> >>>    drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
> >>>    1 file changed, 174 insertions(+), 72 deletions(-)
> >>>
> >>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>> index 8bd75a1..de73a71 100644
> >>> --- a/drivers/net/xen-netfront.c
> >>> +++ b/drivers/net/xen-netfront.c
> >>> @@ -67,9 +67,19 @@ struct netfront_cb {
> >>>
> >>>    #define GRANT_INVALID_REF   0
> >>>
> >>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> >>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> >>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> >>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> >>> +#define XENNET_MAX_RING_PAGES      (1U<<   XENNET_MAX_RING_PAGE_ORDER)
> >>> +
> >>> +
> >>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
> >>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> >>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
> >>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> >>> +
> >>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>> +
> >>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> >> Not using multi-page ring here?
> >> In xennet_create_dev, gnttab_alloc_grant_references allocates
> >> TX_MAX_TARGET number of grant reference for tx. In
> >> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> >> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> >> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> >> skb_entry_is_link helps to not release invalid grants, lots of null loop
> >> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> >> variableconnected with np->tx_ring_pages. Or you intended to use one
> >> page ring here?
> >>
> > Looking back my history, this limitation was introduced because if we
> > have a multi-page backend and single page frontend, the backend skb
> > processing could overlap.
> 
> I did not see the overlap you mentioned here in netback. Although 
> netback supports multi-page, netback->vif still uses single page if the 
> frontend only supports single page. Netfront and netback negotiate this 
> through xenstore in your 5/8 patch. The requests and response should not 
> have any overlap between netback and netfront. Am I missing something?
> 

I tried to dig up mail archive just now and realized that the bug report
was in private mail exchange with Konrad.

I don't really remember the details now since it is more than one year
old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
remember is that this bug was triggered by mixed old/new
frontend/backend.

I think this cap can be removed if we make all buffers in netfront
dynamically allocated.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:54:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:54: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 1UAjKz-0005Oe-4P; Wed, 27 Feb 2013 15:54:33 +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 1UAjKw-0005OX-Qe
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:54:31 +0000
Received: from [85.158.137.99:33418] by server-5.bemta-3.messagelabs.com id
	35/F5-30636-13C2E215; Wed, 27 Feb 2013 15:54:25 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361980459!17011900!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8329 invoked from network); 27 Feb 2013 15:54:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9524835"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 15:54:14 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Wed, 27 Feb 2013
	10:54:14 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: =?iso-8859-1?Q?S=E9bastien_FREMAL_=5B530784=5D?=
	<Sebastien.FREMAL@umons.ac.be>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 10:54:17 -0500
Thread-Topic: Mapping granted pages in the user space of a domU
Thread-Index: Ac4U+rNhA2odNNBcQhaaDbwWLNFuigAB6hFg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A321646114@FTLPMAILBOX02.citrite.net>
References: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>
In-Reply-To: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>
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] Mapping granted pages in the user space of a 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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 S=E9bastien FREMAL [530784]
> Sent: Wednesday, February 27, 2013 9:57 AM
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Mapping granted pages in the user space of a domU
> =

> Hello,
> =

> I'm creating a communication channel between an application running in
> the dom0 and applications running in domU's. I mapped several pages of
> the kernel space of the dom0 in its user space (and this part works
> fine) and I granted the access to these pages to a domU. The module
> running in this domU successfuly retrieves these pages and their content
> but I don't find how to map the pages in the user space.
> =

> I already tried several possibilities I found on the web :
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> The code of the module :
> =

> #undef __KERNEL__
> #define __KERNEL__
> =

> #undef MODULE
> #define MODULE
> =

> #include <xen/grant_table.h>
> #include <xen/page.h>
> #include <asm/xen/hypercall.h>
> #include <linux/gfp.h>
> #include <linux/module.h>
> #include <linux/vmalloc.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/page.h>
> #include <linux/delay.h>
> #include <linux/time.h>
> #include <linux/fs.h>
> #include <linux/cdev.h>
> =

> MODULE_LICENSE("GPL");
> =

> // internal data
> // length of the two memory areas
> enum{NUM_ALLOC =3D 1};
> enum{PAGES_PER_ALLOC =3D 4};
> =

> struct gnttab_map_grant_ref ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct gnttab_unmap_grant_ref unmap_ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct vm_struct * v_start;
> =

> static dev_t mmap_dev;
> static struct cdev mmap_cdev;
> =

> static int mmap_open(struct inode * inode, struct file *filp);
> static int mmap_release(struct inode * inode, struct file * filp);
> static int mmap_mmap(struct file * filp, struct vm_area_struct *vma);
> =

> static struct file_operations mmap_fops =3D {
>         .open =3D mmap_open,
>         .release =3D mmap_release,
>         .mmap =3D mmap_mmap,
>         .owner =3D THIS_MODULE,
> };
> =

> =

> static int mmap_open(struct inode *inode, struct file * filp){
>         printk(KERN_INFO "MMap_open invoked\n");
>         return 0;
> }
> =

> static int mmap_release(struct inode * inode, struct file * filp){
>         printk(KERN_INFO "MMap_release invoked\n");
>         return 0;
> }
> =

> struct mmap_info{
> 	char * data;
> 	int reference;
> };
> =

> static int mmap_mmap(struct file * filp, struct vm_area_struct * vma){
>         int ret;
>         size_t length =3D vma->vm_end - vma->vm_start;
>         size_t num_pages =3D length/PAGE_SIZE;
>         size_t i=3D0;;
> =

>         printk(KERN_INFO "Length : %lu, pages : %lu \n", length,
> length/PAGE_SIZE);
> =

>         if(length > NUM_ALLOC * PAGES_PER_ALLOC * PAGE_SIZE){
>                 printk("Request for a chunk of memory bigger than the
> available memory\n");
>                 return -EIO;
>         }
> =

> 	for(i=3D0;i<num_pages;++i){
> =

>                 //FIRST ATTEMPT
> 		if((ret =3D remap_pfn_range(vma,
> 					vma->vm_start+i*PAGE_SIZE,
> 					page_to_pfn(vmalloc_to_page(v_start-
> >addr+i*PAGE_SIZE)),
> 					PAGE_SIZE,
> 					vma->vm_page_prot))<0){
> 			printk(KERN_INFO "Error in remap_pfn_range");
>         		return ret;
>         	}
> =

> /*
>                 //SECOND ATTEMPT
> 		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
> 		if((ret=3Dm2p_add_override(mfn, virt_to_page(vma-
> >vm_start+i*PAGE_SIZE), NULL))>0){
> 			printk(KERN_INFO "Overriding failed\n");
> 			return ret;
> 		}
> =

>                 //THIRD ATTEMPT
> 		struct mmap_info * info =3D (struct mmap_info *) filp-
> >private_data;
> 		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
>                 if((ret=3Dm2p_add_override(mfn, virt_to_page(info-
> >data+i*PAGE_SIZE), NULL))>0){
>                         printk(KERN_INFO "Overriding failed\n");
>                         return ret;
>                 }
> =

>                 //FOURTH ATTEMPT
>                 if((ret =3D remap_vmalloc_range(vma, v_start->addr,
> 0))<0){
>                        printk(KERN_INFO "Error in remap_vmalloc_range");
>                        return ret;
>                 }
> */
>                 printk(KERN_INFO "Page %lu mapped\n", i);
>                 printk(KERN_INFO "Content : %d - %d\n", *((int
> *)ops[i].host_addr), *((int *) v_start->addr));
> =

> 	}
> =

>         printk(KERN_INFO "MMaped\n");
> =

>         return 0;
> }
> =

> static int __init mapped_init(void){
>         int i, ret;
> =

> 	printk(KERN_INFO "Using shared memory in Xen \n");
> =

>         if((ret =3D alloc_chrdev_region(&mmap_dev,0,1,"mmap"))<0){
>                 printk(KERN_INFO "Could not allocate major number for
> mmap\n");
>                 return ret;
>         }
> =

>         cdev_init(&mmap_cdev, &mmap_fops);
>         if((ret=3Dcdev_add(&mmap_cdev, mmap_dev, 1))<0){
>                 printk(KERN_INFO "Could not allocate chrdev for
> mmap\n");
>                 unregister_chrdev_region(mmap_dev, 1);
>         	return ret;
> 	}
> =

> 	v_start =3D alloc_vm_area(PAGE_SIZE*NUM_ALLOC*PAGES_PER_ALLOC,NULL);
> =

>         if(v_start=3D=3D0){
>                 printk(KERN_INFO "Problem allocating vm area\n");
>                 return -EFAULT;
>         }
> =

>         for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
> 		ops[i].flags =3D GNTMAP_host_map;
>         	ops[i].ref =3D 8+i;
>         	ops[i].dom =3D 0;
>         	ops[i].host_addr =3D (unsigned long)(((char*) v_start-
> >addr)+i*PAGE_SIZE);
> 	}
> =

>         if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ops,
> NUM_ALLOC*PAGES_PER_ALLOC)){
>                	printk(KERN_INFO "Hypervisor map grant failed\n");
>                	free_vm_area(v_start);
>                	return -EFAULT;
>        	}
> =

> =

> 	for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
> 		if(ops[i].status){
> 			printk(KERN_INFO "Hyper map grant failed with status
> %d\n", ops[i].status);
> 			free_vm_area(v_start);
> 			return -EFAULT;
>         	}
> =

> 		unmap_ops[i].host_addr =3D ops[i].host_addr;
> 		unmap_ops[i].handle =3D ops[i].handle;
> =

> 		printk(KERN_INFO "Number : %d\n", *((int
> *)ops[i].host_addr));
> 	}
> =

>         return 0;
> }
> =

> static int  __exit mapped_exit(void){
> 	if(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops,
> NUM_ALLOC*PAGES_PER_ALLOC))
>                 	printk("Error in unmapping operation\n");
>         free_vm_area(v_start);
> 	printk("Mapping module cleaned\n");
> 	return 0;
> }
> =

> module_init(mapped_init)
> module_exit(mapped_exit)
> =

> =

> Mapping :
> =

> int main(void)
> {
>   int fd;
>   int *vadr;
> =

>   unsigned long len =3D getpagesize(), i;
> =

>   if ((fd=3Dopen("node", O_RDWR|O_SYNC))<0)
>   {
>       perror("open");
>       exit(-1);
>   }
> =

>   vadr =3D mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> =

>   if (vadr =3D=3D MAP_FAILED)
>   {
>           perror("mmap");
>           exit(-1);
>   }
> =

>   for(i=3D0;i<len/sizeof(int);i+=3D(getpagesize()/sizeof(int))){
>           printf("%d\n",*(vadr+i));
>           vadr[i]=3Dvadr[i]+1;
>   }
> =

>   close(fd);
>   return(0);
> =

> }
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> The first attempt doesn't indicate any error but I don't get the good
> page (I put the value "3" in the page but the application read the value
> 0).
> =

> The second attempt gives an error in the module :
> [   86.071090] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [   86.071093] m2p_add_override: pfn f73ed13ae not mapped
> [   86.071095] Modules linked in: shm13(O) lp parport
> [   86.071101] Pid: 1324, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [   86.071103] Call Trace:
> [   86.071110]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [   86.071113]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [   86.071116]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [   86.071121]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [   86.071126]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [   86.071129]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [   86.071134]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [   86.071137]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [   86.071140]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [   86.071143]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [   86.071148]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [   86.071153]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [   86.071155] ---[ end trace ea7792ae1c43717f ]---
> =

> The third attempt gives me the same error in the module :
> [  105.337927] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [  105.337929] m2p_add_override: pfn f78bba24c not mapped
> [  105.337931] Modules linked in: shm13(O) lp parport
> [  105.337937] Pid: 1201, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [  105.337939] Call Trace:
> [  105.337946]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [  105.337949]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [  105.337952]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [  105.337958]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [  105.337962]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [  105.337965]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [  105.337970]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [  105.337973]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [  105.337976]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [  105.337979]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [  105.337984]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [  105.337989]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [  105.337991] ---[ end trace 33b54c96a0c2933b ]---
> =

> The fourth attempt results in an error in the function called by the
> module :
> [   96.621242] Error in remap_vmalloc_range
> =

> I don't really know what to do to make it works, but I know than such a
> communication channel is possible as people have already done it before.
> =

> Does someone know what is my mistake and how to correct it please ?
> =

> Best regards,
> =

> S=E9bastien Fr=E9mal

It sounds like you are trying to do something like what libvchan already
does. You should take a look at that library - it is in the xen tree
under tools/libvchan

Ross

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 15:54:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 15:54: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 1UAjKz-0005Oe-4P; Wed, 27 Feb 2013 15:54:33 +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 1UAjKw-0005OX-Qe
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 15:54:31 +0000
Received: from [85.158.137.99:33418] by server-5.bemta-3.messagelabs.com id
	35/F5-30636-13C2E215; Wed, 27 Feb 2013 15:54:25 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361980459!17011900!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8329 invoked from network); 27 Feb 2013 15:54:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 15:54:20 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="9524835"
Received: from accessns.citrite.net (HELO FTLPMAILMX02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 15:54:14 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Wed, 27 Feb 2013
	10:54:14 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: =?iso-8859-1?Q?S=E9bastien_FREMAL_=5B530784=5D?=
	<Sebastien.FREMAL@umons.ac.be>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Wed, 27 Feb 2013 10:54:17 -0500
Thread-Topic: Mapping granted pages in the user space of a domU
Thread-Index: Ac4U+rNhA2odNNBcQhaaDbwWLNFuigAB6hFg
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A321646114@FTLPMAILBOX02.citrite.net>
References: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>
In-Reply-To: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>
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] Mapping granted pages in the user space of a 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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 S=E9bastien FREMAL [530784]
> Sent: Wednesday, February 27, 2013 9:57 AM
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Mapping granted pages in the user space of a domU
> =

> Hello,
> =

> I'm creating a communication channel between an application running in
> the dom0 and applications running in domU's. I mapped several pages of
> the kernel space of the dom0 in its user space (and this part works
> fine) and I granted the access to these pages to a domU. The module
> running in this domU successfuly retrieves these pages and their content
> but I don't find how to map the pages in the user space.
> =

> I already tried several possibilities I found on the web :
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> The code of the module :
> =

> #undef __KERNEL__
> #define __KERNEL__
> =

> #undef MODULE
> #define MODULE
> =

> #include <xen/grant_table.h>
> #include <xen/page.h>
> #include <asm/xen/hypercall.h>
> #include <linux/gfp.h>
> #include <linux/module.h>
> #include <linux/vmalloc.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/page.h>
> #include <linux/delay.h>
> #include <linux/time.h>
> #include <linux/fs.h>
> #include <linux/cdev.h>
> =

> MODULE_LICENSE("GPL");
> =

> // internal data
> // length of the two memory areas
> enum{NUM_ALLOC =3D 1};
> enum{PAGES_PER_ALLOC =3D 4};
> =

> struct gnttab_map_grant_ref ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct gnttab_unmap_grant_ref unmap_ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct vm_struct * v_start;
> =

> static dev_t mmap_dev;
> static struct cdev mmap_cdev;
> =

> static int mmap_open(struct inode * inode, struct file *filp);
> static int mmap_release(struct inode * inode, struct file * filp);
> static int mmap_mmap(struct file * filp, struct vm_area_struct *vma);
> =

> static struct file_operations mmap_fops =3D {
>         .open =3D mmap_open,
>         .release =3D mmap_release,
>         .mmap =3D mmap_mmap,
>         .owner =3D THIS_MODULE,
> };
> =

> =

> static int mmap_open(struct inode *inode, struct file * filp){
>         printk(KERN_INFO "MMap_open invoked\n");
>         return 0;
> }
> =

> static int mmap_release(struct inode * inode, struct file * filp){
>         printk(KERN_INFO "MMap_release invoked\n");
>         return 0;
> }
> =

> struct mmap_info{
> 	char * data;
> 	int reference;
> };
> =

> static int mmap_mmap(struct file * filp, struct vm_area_struct * vma){
>         int ret;
>         size_t length =3D vma->vm_end - vma->vm_start;
>         size_t num_pages =3D length/PAGE_SIZE;
>         size_t i=3D0;;
> =

>         printk(KERN_INFO "Length : %lu, pages : %lu \n", length,
> length/PAGE_SIZE);
> =

>         if(length > NUM_ALLOC * PAGES_PER_ALLOC * PAGE_SIZE){
>                 printk("Request for a chunk of memory bigger than the
> available memory\n");
>                 return -EIO;
>         }
> =

> 	for(i=3D0;i<num_pages;++i){
> =

>                 //FIRST ATTEMPT
> 		if((ret =3D remap_pfn_range(vma,
> 					vma->vm_start+i*PAGE_SIZE,
> 					page_to_pfn(vmalloc_to_page(v_start-
> >addr+i*PAGE_SIZE)),
> 					PAGE_SIZE,
> 					vma->vm_page_prot))<0){
> 			printk(KERN_INFO "Error in remap_pfn_range");
>         		return ret;
>         	}
> =

> /*
>                 //SECOND ATTEMPT
> 		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
> 		if((ret=3Dm2p_add_override(mfn, virt_to_page(vma-
> >vm_start+i*PAGE_SIZE), NULL))>0){
> 			printk(KERN_INFO "Overriding failed\n");
> 			return ret;
> 		}
> =

>                 //THIRD ATTEMPT
> 		struct mmap_info * info =3D (struct mmap_info *) filp-
> >private_data;
> 		unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
>                 if((ret=3Dm2p_add_override(mfn, virt_to_page(info-
> >data+i*PAGE_SIZE), NULL))>0){
>                         printk(KERN_INFO "Overriding failed\n");
>                         return ret;
>                 }
> =

>                 //FOURTH ATTEMPT
>                 if((ret =3D remap_vmalloc_range(vma, v_start->addr,
> 0))<0){
>                        printk(KERN_INFO "Error in remap_vmalloc_range");
>                        return ret;
>                 }
> */
>                 printk(KERN_INFO "Page %lu mapped\n", i);
>                 printk(KERN_INFO "Content : %d - %d\n", *((int
> *)ops[i].host_addr), *((int *) v_start->addr));
> =

> 	}
> =

>         printk(KERN_INFO "MMaped\n");
> =

>         return 0;
> }
> =

> static int __init mapped_init(void){
>         int i, ret;
> =

> 	printk(KERN_INFO "Using shared memory in Xen \n");
> =

>         if((ret =3D alloc_chrdev_region(&mmap_dev,0,1,"mmap"))<0){
>                 printk(KERN_INFO "Could not allocate major number for
> mmap\n");
>                 return ret;
>         }
> =

>         cdev_init(&mmap_cdev, &mmap_fops);
>         if((ret=3Dcdev_add(&mmap_cdev, mmap_dev, 1))<0){
>                 printk(KERN_INFO "Could not allocate chrdev for
> mmap\n");
>                 unregister_chrdev_region(mmap_dev, 1);
>         	return ret;
> 	}
> =

> 	v_start =3D alloc_vm_area(PAGE_SIZE*NUM_ALLOC*PAGES_PER_ALLOC,NULL);
> =

>         if(v_start=3D=3D0){
>                 printk(KERN_INFO "Problem allocating vm area\n");
>                 return -EFAULT;
>         }
> =

>         for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
> 		ops[i].flags =3D GNTMAP_host_map;
>         	ops[i].ref =3D 8+i;
>         	ops[i].dom =3D 0;
>         	ops[i].host_addr =3D (unsigned long)(((char*) v_start-
> >addr)+i*PAGE_SIZE);
> 	}
> =

>         if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ops,
> NUM_ALLOC*PAGES_PER_ALLOC)){
>                	printk(KERN_INFO "Hypervisor map grant failed\n");
>                	free_vm_area(v_start);
>                	return -EFAULT;
>        	}
> =

> =

> 	for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
> 		if(ops[i].status){
> 			printk(KERN_INFO "Hyper map grant failed with status
> %d\n", ops[i].status);
> 			free_vm_area(v_start);
> 			return -EFAULT;
>         	}
> =

> 		unmap_ops[i].host_addr =3D ops[i].host_addr;
> 		unmap_ops[i].handle =3D ops[i].handle;
> =

> 		printk(KERN_INFO "Number : %d\n", *((int
> *)ops[i].host_addr));
> 	}
> =

>         return 0;
> }
> =

> static int  __exit mapped_exit(void){
> 	if(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops,
> NUM_ALLOC*PAGES_PER_ALLOC))
>                 	printk("Error in unmapping operation\n");
>         free_vm_area(v_start);
> 	printk("Mapping module cleaned\n");
> 	return 0;
> }
> =

> module_init(mapped_init)
> module_exit(mapped_exit)
> =

> =

> Mapping :
> =

> int main(void)
> {
>   int fd;
>   int *vadr;
> =

>   unsigned long len =3D getpagesize(), i;
> =

>   if ((fd=3Dopen("node", O_RDWR|O_SYNC))<0)
>   {
>       perror("open");
>       exit(-1);
>   }
> =

>   vadr =3D mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> =

>   if (vadr =3D=3D MAP_FAILED)
>   {
>           perror("mmap");
>           exit(-1);
>   }
> =

>   for(i=3D0;i<len/sizeof(int);i+=3D(getpagesize()/sizeof(int))){
>           printf("%d\n",*(vadr+i));
>           vadr[i]=3Dvadr[i]+1;
>   }
> =

>   close(fd);
>   return(0);
> =

> }
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> The first attempt doesn't indicate any error but I don't get the good
> page (I put the value "3" in the page but the application read the value
> 0).
> =

> The second attempt gives an error in the module :
> [   86.071090] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [   86.071093] m2p_add_override: pfn f73ed13ae not mapped
> [   86.071095] Modules linked in: shm13(O) lp parport
> [   86.071101] Pid: 1324, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [   86.071103] Call Trace:
> [   86.071110]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [   86.071113]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [   86.071116]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [   86.071121]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [   86.071126]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [   86.071129]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [   86.071134]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [   86.071137]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [   86.071140]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [   86.071143]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [   86.071148]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [   86.071153]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [   86.071155] ---[ end trace ea7792ae1c43717f ]---
> =

> The third attempt gives me the same error in the module :
> [  105.337927] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [  105.337929] m2p_add_override: pfn f78bba24c not mapped
> [  105.337931] Modules linked in: shm13(O) lp parport
> [  105.337937] Pid: 1201, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [  105.337939] Call Trace:
> [  105.337946]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [  105.337949]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [  105.337952]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [  105.337958]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [  105.337962]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [  105.337965]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [  105.337970]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [  105.337973]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [  105.337976]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [  105.337979]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [  105.337984]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [  105.337989]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [  105.337991] ---[ end trace 33b54c96a0c2933b ]---
> =

> The fourth attempt results in an error in the function called by the
> module :
> [   96.621242] Error in remap_vmalloc_range
> =

> I don't really know what to do to make it works, but I know than such a
> communication channel is possible as people have already done it before.
> =

> Does someone know what is my mistake and how to correct it please ?
> =

> Best regards,
> =

> S=E9bastien Fr=E9mal

It sounds like you are trying to do something like what libvchan already
does. You should take a look at that library - it is in the xen tree
under tools/libvchan

Ross

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:13:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:13: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 1UAjcv-00069p-SC; Wed, 27 Feb 2013 16:13:05 +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 1UAjcu-00069k-Aa
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:13:04 +0000
Received: from [85.158.143.99:26914] by server-3.bemta-4.messagelabs.com id
	09/CA-02186-F803E215; Wed, 27 Feb 2013 16:13:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361981581!19081457!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19458 invoked from network); 27 Feb 2013 16:13: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; 27 Feb 2013 16:13:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:13:01 +0000
Message-Id: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:12:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] preparing for 4.2.2 and 4.1.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

Aiming at a release towards the end of March, I'd like to cut RC1-s
at the beginning of next week.

Please indicate any bug fixes that so far may have been missed
in the backports already done. Quite a few fixes are currently
stuck in master's staging branch - these don't need to be named
explicitly, I'm already planning to pull over the hypervisor ones
as soon as they get out of staging (and I'm sure Ian is planning
the same - if applicable at all - for the tools side).

Ian - one thing I think is still open for 4.1.5 is the xz kernel
decompression support that was explicitly requested on the list.
Can this be expected to go in for RC1?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:13:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:13: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 1UAjcv-00069p-SC; Wed, 27 Feb 2013 16:13:05 +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 1UAjcu-00069k-Aa
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:13:04 +0000
Received: from [85.158.143.99:26914] by server-3.bemta-4.messagelabs.com id
	09/CA-02186-F803E215; Wed, 27 Feb 2013 16:13:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1361981581!19081457!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19458 invoked from network); 27 Feb 2013 16:13: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; 27 Feb 2013 16:13:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:13:01 +0000
Message-Id: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:12:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] preparing for 4.2.2 and 4.1.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

Aiming at a release towards the end of March, I'd like to cut RC1-s
at the beginning of next week.

Please indicate any bug fixes that so far may have been missed
in the backports already done. Quite a few fixes are currently
stuck in master's staging branch - these don't need to be named
explicitly, I'm already planning to pull over the hypervisor ones
as soon as they get out of staging (and I'm sure Ian is planning
the same - if applicable at all - for the tools side).

Ian - one thing I think is still open for 4.1.5 is the xz kernel
decompression support that was explicitly requested on the list.
Can this be expected to go in for RC1?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:15:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjfD-0006FR-Dl; Wed, 27 Feb 2013 16:15:27 +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 1UAjfC-0006FM-8E
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:15:26 +0000
Received: from [85.158.139.211:59221] by server-11.bemta-5.messagelabs.com id
	64/29-27486-D113E215; Wed, 27 Feb 2013 16:15:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361981724!19635655!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19352 invoked from network); 27 Feb 2013 16:15:24 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:15:24 -0000
Received: by mail-wg0-f49.google.com with SMTP id 15so626382wgd.16
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 08:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=4DyavvsJITaOJZYc7HK3fD+7Qf7+gwTxz9ELeHwWVd8=;
	b=gidrKRr/alpmhqHT6/OG8v7PQtW/h2wj73elE/Y8mU5Sbayh4amhcCHLhfpf51O6Ut
	UPaGPSNLw7Eu+h9txeYtiQLAo29sJ79PO4t8oRgGIShzQMpZ6oaMzYEoK/3B5/a/UBPF
	Wut1GpcV0X9dM3Rvzu4TbA46KaQd8lEpoOZBwzK28nZ3bDXrrF0oRwGOt5v/mY120Hgg
	1BsMmOxVQS8JxrnoH4n8eEqQ/wNbvfrjoE1f1Hg3QsqEWenHXdpP7TEXDlFCP47P/Rfd
	e0FrcEZq/K3N+EekmGGoqZ/DxZupCWY9j3dWwtqg27chyeU5eS2nzmz8ce02VjtVukrh
	MnZQ==
X-Received: by 10.194.235.196 with SMTP id uo4mr5064321wjc.30.1361981724448;
	Wed, 27 Feb 2013 08:15:24 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id cf8sm9704521wib.1.2013.02.27.08.15.22
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 08:15:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 16:15:18 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CD53E196.5C949%keir@xen.org>
Thread-Topic: [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
Thread-Index: Ac4VBaIpJc9vUNaXSEmcBGKvkbI+NA==
In-Reply-To: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org, jbuelich@suse.com
Subject: Re: [Xen-devel] [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 13:14, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> This is always 64-bit on ARM, not BITS_PER_LONG
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: keir@xen.org
> Cc: tim@xen.org
> Cc: stefano.stabellini@citrix.com
> Cc: jbuelich@suse.com

Acked-by: Keir Fraser <keir@xen.org>

> ---
>  xen/include/asm-arm/config.h |    3 +++
>  xen/include/asm-x86/config.h |    2 ++
>  xen/include/xen/sched.h      |    4 ++--
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 3910dd2..8be8563 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -22,6 +22,9 @@
>  #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  
> +/* xen_ulong_t is always 64 bits */
> +#define BITS_PER_XEN_ULONG 64
> +
>  #define CONFIG_PAGING_ASSISTANCE 1
>  
>  #define CONFIG_PAGING_LEVELS 3
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 70f70b3..f68afd8 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -14,6 +14,8 @@
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  #define BITS_PER_BYTE 8
>  
> +#define BITS_PER_XEN_ULONG BITS_PER_LONG
> +
>  #define CONFIG_X86 1
>  #define CONFIG_X86_HT 1
>  #define CONFIG_PAGING_ASSISTANCE 1
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index e108436..ccd0496 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -46,9 +46,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>  extern struct domain *dom0;
>  
>  #ifndef CONFIG_COMPAT
> -#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
> +#define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
>  #else
> -#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
> +#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 :
> BITS_PER_XEN_ULONG)
>  #endif
>  #define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
>  #define EVTCHNS_PER_BUCKET 128



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:15:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjfD-0006FR-Dl; Wed, 27 Feb 2013 16:15:27 +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 1UAjfC-0006FM-8E
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:15:26 +0000
Received: from [85.158.139.211:59221] by server-11.bemta-5.messagelabs.com id
	64/29-27486-D113E215; Wed, 27 Feb 2013 16:15:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361981724!19635655!1
X-Originating-IP: [74.125.82.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19352 invoked from network); 27 Feb 2013 16:15:24 -0000
Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com)
	(74.125.82.49)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:15:24 -0000
Received: by mail-wg0-f49.google.com with SMTP id 15so626382wgd.16
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 08:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=4DyavvsJITaOJZYc7HK3fD+7Qf7+gwTxz9ELeHwWVd8=;
	b=gidrKRr/alpmhqHT6/OG8v7PQtW/h2wj73elE/Y8mU5Sbayh4amhcCHLhfpf51O6Ut
	UPaGPSNLw7Eu+h9txeYtiQLAo29sJ79PO4t8oRgGIShzQMpZ6oaMzYEoK/3B5/a/UBPF
	Wut1GpcV0X9dM3Rvzu4TbA46KaQd8lEpoOZBwzK28nZ3bDXrrF0oRwGOt5v/mY120Hgg
	1BsMmOxVQS8JxrnoH4n8eEqQ/wNbvfrjoE1f1Hg3QsqEWenHXdpP7TEXDlFCP47P/Rfd
	e0FrcEZq/K3N+EekmGGoqZ/DxZupCWY9j3dWwtqg27chyeU5eS2nzmz8ce02VjtVukrh
	MnZQ==
X-Received: by 10.194.235.196 with SMTP id uo4mr5064321wjc.30.1361981724448;
	Wed, 27 Feb 2013 08:15:24 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id cf8sm9704521wib.1.2013.02.27.08.15.22
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 08:15:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 16:15:18 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CD53E196.5C949%keir@xen.org>
Thread-Topic: [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
Thread-Index: Ac4VBaIpJc9vUNaXSEmcBGKvkbI+NA==
In-Reply-To: <1361970894-12965-1-git-send-email-ian.campbell@citrix.com>
Mime-version: 1.0
Cc: stefano.stabellini@citrix.com, tim@xen.org, jbuelich@suse.com
Subject: Re: [Xen-devel] [PATCH] xen: correct BITS_PER_EVTCHN_WORD on arm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 13:14, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> This is always 64-bit on ARM, not BITS_PER_LONG
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: keir@xen.org
> Cc: tim@xen.org
> Cc: stefano.stabellini@citrix.com
> Cc: jbuelich@suse.com

Acked-by: Keir Fraser <keir@xen.org>

> ---
>  xen/include/asm-arm/config.h |    3 +++
>  xen/include/asm-x86/config.h |    2 ++
>  xen/include/xen/sched.h      |    4 ++--
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 3910dd2..8be8563 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -22,6 +22,9 @@
>  #define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  
> +/* xen_ulong_t is always 64 bits */
> +#define BITS_PER_XEN_ULONG 64
> +
>  #define CONFIG_PAGING_ASSISTANCE 1
>  
>  #define CONFIG_PAGING_LEVELS 3
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 70f70b3..f68afd8 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -14,6 +14,8 @@
>  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
>  #define BITS_PER_BYTE 8
>  
> +#define BITS_PER_XEN_ULONG BITS_PER_LONG
> +
>  #define CONFIG_X86 1
>  #define CONFIG_X86_HT 1
>  #define CONFIG_PAGING_ASSISTANCE 1
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index e108436..ccd0496 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -46,9 +46,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>  extern struct domain *dom0;
>  
>  #ifndef CONFIG_COMPAT
> -#define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
> +#define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
>  #else
> -#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 : BITS_PER_LONG)
> +#define BITS_PER_EVTCHN_WORD(d) (has_32bit_shinfo(d) ? 32 :
> BITS_PER_XEN_ULONG)
>  #endif
>  #define MAX_EVTCHNS(d) (BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d))
>  #define EVTCHNS_PER_BUCKET 128



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:22:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjlx-0006XH-Bk; Wed, 27 Feb 2013 16:22: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 1UAjlv-0006XC-Hs
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 16:22:23 +0000
Received: from [85.158.137.99:3541] by server-2.bemta-3.messagelabs.com id
	16/09-05208-EB23E215; Wed, 27 Feb 2013 16:22:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361982141!353769!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 972 invoked from network); 27 Feb 2013 16:22:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1966116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 16:22: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.297.1; Wed, 27 Feb 2013 16:22:21 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAjlt-0007T9-BP;
	Wed, 27 Feb 2013 16:22:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAjlt-0005Yz-5H;
	Wed, 27 Feb 2013 16:22:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 16:22:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 16761: 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 16761 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16761/

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. 12557
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-win           5 xen-boot                     fail   like 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-qemut-win-vcpus1  5 xen-boot                   fail never pass
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot                fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1  5 xen-boot                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 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-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                d895cb1af15c04c522a25c79cc429076987c089b
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 d895cb1af15c04c522a25c79cc429076987c089b
Merge: 9626357... d3d009c...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Feb 26 20:16:07 2013 -0800

    Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
    
    Pull vfs pile (part one) from Al Viro:
     "Assorted stuff - cleaning namei.c up a bit, fixing ->d_name/->d_parent
      locking violations, etc.
    
      The most visible changes here are death of FS_REVAL_DOT (replaced with
      "has ->d_weak_revalidate()") and a new helper getting from struct file
      to inode.  Some bits of preparation to xattr method interface changes.
    
      Misc patches by various people sent this cycle *and* ocfs2 fixes from
      several cycles ago that should've been upstream right then.
    
      PS: the next vfs pile will be xattr stuff."
    
    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (46 commits)
      saner proc_get_inode() calling conventions
      proc: avoid extra pde_put() in proc_fill_super()
      fs: change return values from -EACCES to -EPERM
      fs/exec.c: make bprm_mm_init() static
      ocfs2/dlm: use GFP_ATOMIC inside a spin_lock
      ocfs2: fix possible use-after-free with AIO
      ocfs2: Fix oops in ocfs2_fast_symlink_readpage() code path
      get_empty_filp()/alloc_file() leave both ->f_pos and ->f_version zero
      target: writev() on single-element vector is pointless
      export kernel_write(), convert open-coded instances
      fs: encode_fh: return FILEID_INVALID if invalid fid_type
      kill f_vfsmnt
      vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op
      nfsd: handle vfs_getattr errors in acl protocol
      switch vfs_getattr() to struct path
      default SET_PERSONALITY() in linux/elf.h
      ceph: prepopulate inodes only when request is aborted
      d_hash_and_lookup(): export, switch open-coded instances
      9p: switch v9fs_set_create_acl() to inode+fid, do it before d_instantiate()
      9p: split dropping the acls from v9fs_set_create_acl()
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:22:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjlx-0006XH-Bk; Wed, 27 Feb 2013 16:22: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 1UAjlv-0006XC-Hs
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 16:22:23 +0000
Received: from [85.158.137.99:3541] by server-2.bemta-3.messagelabs.com id
	16/09-05208-EB23E215; Wed, 27 Feb 2013 16:22:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1361982141!353769!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 972 invoked from network); 27 Feb 2013 16:22:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; 
   d="scan'208";a="1966116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 16:22: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.297.1; Wed, 27 Feb 2013 16:22:21 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAjlt-0007T9-BP;
	Wed, 27 Feb 2013 16:22:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAjlt-0005Yz-5H;
	Wed, 27 Feb 2013 16:22:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 16:22:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 16761: 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 16761 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16761/

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. 12557
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-win           5 xen-boot                     fail   like 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  9 guest-start                  fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-qemut-win-vcpus1  5 xen-boot                   fail never pass
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot                fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1  5 xen-boot                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 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-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                d895cb1af15c04c522a25c79cc429076987c089b
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 d895cb1af15c04c522a25c79cc429076987c089b
Merge: 9626357... d3d009c...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Feb 26 20:16:07 2013 -0800

    Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
    
    Pull vfs pile (part one) from Al Viro:
     "Assorted stuff - cleaning namei.c up a bit, fixing ->d_name/->d_parent
      locking violations, etc.
    
      The most visible changes here are death of FS_REVAL_DOT (replaced with
      "has ->d_weak_revalidate()") and a new helper getting from struct file
      to inode.  Some bits of preparation to xattr method interface changes.
    
      Misc patches by various people sent this cycle *and* ocfs2 fixes from
      several cycles ago that should've been upstream right then.
    
      PS: the next vfs pile will be xattr stuff."
    
    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (46 commits)
      saner proc_get_inode() calling conventions
      proc: avoid extra pde_put() in proc_fill_super()
      fs: change return values from -EACCES to -EPERM
      fs/exec.c: make bprm_mm_init() static
      ocfs2/dlm: use GFP_ATOMIC inside a spin_lock
      ocfs2: fix possible use-after-free with AIO
      ocfs2: Fix oops in ocfs2_fast_symlink_readpage() code path
      get_empty_filp()/alloc_file() leave both ->f_pos and ->f_version zero
      target: writev() on single-element vector is pointless
      export kernel_write(), convert open-coded instances
      fs: encode_fh: return FILEID_INVALID if invalid fid_type
      kill f_vfsmnt
      vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op
      nfsd: handle vfs_getattr errors in acl protocol
      switch vfs_getattr() to struct path
      default SET_PERSONALITY() in linux/elf.h
      ceph: prepopulate inodes only when request is aborted
      d_hash_and_lookup(): export, switch open-coded instances
      9p: switch v9fs_set_create_acl() to inode+fid, do it before d_instantiate()
      9p: split dropping the acls from v9fs_set_create_acl()
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:29:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjsi-0006iT-E7; Wed, 27 Feb 2013 16:29:24 +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 1UAjsh-0006iO-5g
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:29:23 +0000
Received: from [193.109.254.147:45220] by server-8.bemta-14.messagelabs.com id
	09/B7-17325-2643E215; Wed, 27 Feb 2013 16:29:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361982539!9900900!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30263 invoked from network); 27 Feb 2013 16:28:59 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:28:59 -0000
Received: by mail-wg0-f47.google.com with SMTP id dr13so608018wgb.2
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 08:28:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=VeZbiDmZvN1VJSWlr+cU9/c09I4NSTw5IbiokOH1oqw=;
	b=tU2mRdiX4R6fRxuabh9Q32dRTkj63UZBE09LV7dld1+jwK7VvTagGt+YxgsAG7sWQX
	SLHS02J92df4Mc5U2BN9fPNFJL5vBHrU62aO9RmeDevZUkhL78ivWYX7f3M7uR1zjZee
	SPwo4XzdlGkaBfGhKIsTvhO7RsZ1TBeLZ2HQ4xMqaoTsh4yOyg1Tnjr/nXTVwMJcfDC3
	ZZwjwpeDv0CRjqI4ttKijBNqaFjU/v8Fbv3HYuMQ4QXENRUiu0pdL1atA/uVu1xnNhqP
	81MkaMS3PUjEdWSCoOYfPCwSiMPun1jglcGbE9j7I9Y8FfUGiME2ZjIqIX/3qxPfSzg0
	uPAg==
X-Received: by 10.180.84.8 with SMTP id u8mr3027192wiy.1.1361982539110;
	Wed, 27 Feb 2013 08:28:59 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id t7sm28268542wiy.2.2013.02.27.08.28.57
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 08:28:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 16:28:51 +0000
From: Keir Fraser <keir@xen.org>
To: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>,
	<jbeulich@suse.com>, <ian.campbell@citrix.com>
Message-ID: <CD53E4C3.5C96A%keir@xen.org>
Thread-Topic: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel in Xen
Thread-Index: Ac4VB4a//iBeUuqTZ0iJ+MDGTDRslA==
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
Mime-version: 1.0
Cc: david.vrabel@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27/02/2013 14:33, "Wei Liu" <wei.liu2@citrix.com> wrote:

> Hi all
> 
> This is another version of the patch series. Unfortunately the kernel side is
> not available at the moment. :-(
> 
> Keir, Jan, Ian and David, are you happy with this design in general? I would
> like to have explicit ACK / NACK on this if possible, as feature freeze for
> 4.3
> is quite close now.

I'm happy with the design, in that it solves a current need, and the
implementation exists. It seems this is something we really do need for 4.3.

 -- Keir

> Changes since V2:
> * new interface to register extended event channel ABI
> * use vmap to simplify mapping
> * replace MAX_EVTCHNS macro with inline function
> * libxl: evtchn_l3 -> evtchn_extended
> 
> The most notable bit of this series is the interface change. In order to cope
> with future ABIs, the interface is renamed to EVTCHNOP_register_extended. It
> also provides supported ABI query, so that we can remove unused ABI in the
> future.
> 
> The semantic meaning of EVTCHNOP_register_extended changes a bit. The `level'
> in parameter now changes to `cmd', which means we should go down to specific
> ABI routines. ABI-specific structures are still embedded in the union.
> 
> Changes since V1:
> * move all evtchn related macros / struct definitions to event.h
> * only allow 3-level evtchn for Dom0 and driver domains
> * add evtchn_l3 flag in libxl
> 
> 
> Wei.
> 
> Diffstat:
>  tools/libxl/libxl_create.c         |    4 +
>  tools/libxl/libxl_types.idl        |    1 +
>  tools/libxl/xl_cmdimpl.c           |    2 +
>  tools/libxl/xl_sxp.c               |    2 +
>  xen/arch/arm/domain.c              |    1 +
>  xen/arch/x86/domain.c              |    1 +
>  xen/arch/x86/irq.c                 |    7 +-
>  xen/common/domain.c                |    3 +
>  xen/common/domctl.c                |    5 +-
>  xen/common/event_channel.c         |  458
> +++++++++++++++++++++++++++++++++---
>  xen/common/keyhandler.c            |    6 +-
>  xen/common/schedule.c              |    4 +-
>  xen/include/asm-arm/types.h        |    7 +-
>  xen/include/asm-x86/config.h       |    4 +-
>  xen/include/public/domctl.h        |    3 +
>  xen/include/public/event_channel.h |   44 ++++
>  xen/include/public/xen.h           |   35 ++-
>  xen/include/xen/event.h            |   85 ++++++-
>  xen/include/xen/sched.h            |   65 ++---
>  xen/xsm/flask/hooks.c              |    1 +
>  20 files changed, 623 insertions(+), 115 deletions(-)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 16:29:41 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjsi-0006iT-E7; Wed, 27 Feb 2013 16:29:24 +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 1UAjsh-0006iO-5g
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:29:23 +0000
Received: from [193.109.254.147:45220] by server-8.bemta-14.messagelabs.com id
	09/B7-17325-2643E215; Wed, 27 Feb 2013 16:29:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361982539!9900900!1
X-Originating-IP: [74.125.82.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30263 invoked from network); 27 Feb 2013 16:28:59 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com)
	(74.125.82.47)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:28:59 -0000
Received: by mail-wg0-f47.google.com with SMTP id dr13so608018wgb.2
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 08:28:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=VeZbiDmZvN1VJSWlr+cU9/c09I4NSTw5IbiokOH1oqw=;
	b=tU2mRdiX4R6fRxuabh9Q32dRTkj63UZBE09LV7dld1+jwK7VvTagGt+YxgsAG7sWQX
	SLHS02J92df4Mc5U2BN9fPNFJL5vBHrU62aO9RmeDevZUkhL78ivWYX7f3M7uR1zjZee
	SPwo4XzdlGkaBfGhKIsTvhO7RsZ1TBeLZ2HQ4xMqaoTsh4yOyg1Tnjr/nXTVwMJcfDC3
	ZZwjwpeDv0CRjqI4ttKijBNqaFjU/v8Fbv3HYuMQ4QXENRUiu0pdL1atA/uVu1xnNhqP
	81MkaMS3PUjEdWSCoOYfPCwSiMPun1jglcGbE9j7I9Y8FfUGiME2ZjIqIX/3qxPfSzg0
	uPAg==
X-Received: by 10.180.84.8 with SMTP id u8mr3027192wiy.1.1361982539110;
	Wed, 27 Feb 2013 08:28:59 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id t7sm28268542wiy.2.2013.02.27.08.28.57
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 08:28:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 16:28:51 +0000
From: Keir Fraser <keir@xen.org>
To: Wei Liu <wei.liu2@citrix.com>, <xen-devel@lists.xen.org>,
	<jbeulich@suse.com>, <ian.campbell@citrix.com>
Message-ID: <CD53E4C3.5C96A%keir@xen.org>
Thread-Topic: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel in Xen
Thread-Index: Ac4VB4a//iBeUuqTZ0iJ+MDGTDRslA==
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
Mime-version: 1.0
Cc: david.vrabel@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27/02/2013 14:33, "Wei Liu" <wei.liu2@citrix.com> wrote:

> Hi all
> 
> This is another version of the patch series. Unfortunately the kernel side is
> not available at the moment. :-(
> 
> Keir, Jan, Ian and David, are you happy with this design in general? I would
> like to have explicit ACK / NACK on this if possible, as feature freeze for
> 4.3
> is quite close now.

I'm happy with the design, in that it solves a current need, and the
implementation exists. It seems this is something we really do need for 4.3.

 -- Keir

> Changes since V2:
> * new interface to register extended event channel ABI
> * use vmap to simplify mapping
> * replace MAX_EVTCHNS macro with inline function
> * libxl: evtchn_l3 -> evtchn_extended
> 
> The most notable bit of this series is the interface change. In order to cope
> with future ABIs, the interface is renamed to EVTCHNOP_register_extended. It
> also provides supported ABI query, so that we can remove unused ABI in the
> future.
> 
> The semantic meaning of EVTCHNOP_register_extended changes a bit. The `level'
> in parameter now changes to `cmd', which means we should go down to specific
> ABI routines. ABI-specific structures are still embedded in the union.
> 
> Changes since V1:
> * move all evtchn related macros / struct definitions to event.h
> * only allow 3-level evtchn for Dom0 and driver domains
> * add evtchn_l3 flag in libxl
> 
> 
> Wei.
> 
> Diffstat:
>  tools/libxl/libxl_create.c         |    4 +
>  tools/libxl/libxl_types.idl        |    1 +
>  tools/libxl/xl_cmdimpl.c           |    2 +
>  tools/libxl/xl_sxp.c               |    2 +
>  xen/arch/arm/domain.c              |    1 +
>  xen/arch/x86/domain.c              |    1 +
>  xen/arch/x86/irq.c                 |    7 +-
>  xen/common/domain.c                |    3 +
>  xen/common/domctl.c                |    5 +-
>  xen/common/event_channel.c         |  458
> +++++++++++++++++++++++++++++++++---
>  xen/common/keyhandler.c            |    6 +-
>  xen/common/schedule.c              |    4 +-
>  xen/include/asm-arm/types.h        |    7 +-
>  xen/include/asm-x86/config.h       |    4 +-
>  xen/include/public/domctl.h        |    3 +
>  xen/include/public/event_channel.h |   44 ++++
>  xen/include/public/xen.h           |   35 ++-
>  xen/include/xen/event.h            |   85 ++++++-
>  xen/include/xen/sched.h            |   65 ++---
>  xen/xsm/flask/hooks.c              |    1 +
>  20 files changed, 623 insertions(+), 115 deletions(-)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 27 16:36:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:36: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 1UAjyt-0006yP-IR; Wed, 27 Feb 2013 16:35:47 +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 1UAjyr-0006xs-1s; Wed, 27 Feb 2013 16:35:45 +0000
Received: from [85.158.137.99:43991] by server-13.bemta-3.messagelabs.com id
	C4/E4-25744-FD53E215; Wed, 27 Feb 2013 16:35:43 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361982942!18420677!1
X-Originating-IP: [74.125.83.51]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1320 invoked from network); 27 Feb 2013 16:35:43 -0000
Received: from mail-ee0-f51.google.com (HELO mail-ee0-f51.google.com)
	(74.125.83.51)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:35:43 -0000
Received: by mail-ee0-f51.google.com with SMTP id d17so661498eek.38
	for <multiple recipients>; Wed, 27 Feb 2013 08:35:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:cc:subject:references:in-reply-to:content-type;
	bh=t4cH5aMHeGDQhqW9KCopbnz6oQ68MKdnO9EDPIqkqEE=;
	b=heMwVYuXG6cDud0pIapZe/jhF71TYmN1qEWWzQlQAmYxmCIwx787xCmVNfKfYVuYdy
	8WvsnKMlOV0UVrEH5tlseZw6VbKXTOSettmLha3ykde0iBfXL4XcYdlHM9+zGxgtOw79
	pb4BC+Nic+63R6c4r59XtY2yxqtxm3r436gEmrVZAX1hgDQ0lU85v9jiCC33VJOKunFG
	ziQfxWn+1N70E4A/81IPJ71ab/ffEKNygu/kTfhpCSTT8osJbhIrXl1TUZ2Rq5H2LlGF
	GLJtQCd2Kbx5qEUgsX8u/8G1jCuwJC6sNCNuTXd/bJCBmCSZw4Ntz9SE/hHhzyk8cVMP
	biKQ==
X-Received: by 10.15.101.204 with SMTP id bp52mr7261169eeb.31.1361982942595;
	Wed, 27 Feb 2013 08:35:42 -0800 (PST)
Received: from [172.16.26.11] ([151.225.0.38])
	by mx.google.com with ESMTPS id q42sm7280638eem.14.2013.02.27.08.35.40
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 08:35:41 -0800 (PST)
Message-ID: <512E35DA.4030507@xen.org>
Date: Wed, 27 Feb 2013 16:35:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: lars.kurth@xen.org
References: <512984AE.2060400@xen.org>
In-Reply-To: <512984AE.2060400@xen.org>
Cc: "xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-arm@lists.xen.org,
	Amir M Chaudhry <amc79@cam.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [Vote] Results of formal vote for Mirage to be
 accepted as Xen.org Incubation Project - Correction
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="===============2848450748502928646=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2848450748502928646==
Content-Type: multipart/alternative;
 boundary="------------030006050307060205060201"

This is a multi-part message in MIME format.
--------------030006050307060205060201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I need to correct the results and apologize for a mistake I made : I 
should have double checked the process before sending out the request 
for voting.

http://www.xen.org/projects/governance.html says*"Voting:* The community 
manager arranges a timed private vote as outlined above (voting should 
be open for a minimum of a week). Any maintainer of a mature project and 
the Xen.org community manager is allowed to vote. Voting follows the 
conventions as laid out in 'Principle: Consensus Decision Making'."

This means that:
a) I miscommunicated who is elgible to vote : which are project leads, 
committers and maintainers of mature projects, as well as the community 
manager.
b) I tallied wrongly

I am summarizing the results again: the following people who fit the 
criteria in a) can vote. Note that XCP does not have a defined list of 
maintainers and committers, thus only the vote of the XCP's project lead 
- Mike McClurg - counts. Eligible votes came from:

Ian Campbell
Mike McClurg
Jan Beulich
Lars Kurth
Tim Deegan
Ian Jackson

5 in favour, 1 abstained.

If no committer challenges by Friday, the vote will carry.

Regards
Lars

On 24/02/2013 03:10, Lars Kurth wrote:
> Hi everybody,
>
> sorry for the delay in posting the vote results for 
> http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal.
>
> The vote breakdown:
> - 6 out of 7 Xen committers voted (including project leads)
> - 5 were in favour
> - 1 abstained due to the "choice of the ISC licence rather than a 
> copyleft licence such as LGPLv2+"
>
> So overall the vote carries.
>
> We also several other community members voting in support of the 
> proposal. We also discussed the proposal at the last Xen Maintainer, 
> Committer and Developer Meeting, which expressed support for the 
> proposal.
>
> What happens next?
> I will work with the Mirage project lead on a detailed plan for the 
> Incubation phase.
>
> Best Regards
> Lars


--------------030006050307060205060201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      I need to correct the results and apologize for a mistake I made :
      I should have double checked the process before sending out the
      request for voting. <br>
      <br>
      <a class="moz-txt-link-freetext" href="http://www.xen.org/projects/governance.html">http://www.xen.org/projects/governance.html</a> says<b> "Voting:</b>
      The community manager arranges a timed private vote as outlined
      above (voting should be open for a minimum of a week). Any
      maintainer of a mature project and the Xen.org community manager
      is allowed to vote. Voting follows the conventions as laid out in
      'Principle: Consensus Decision Making'."<br>
      <br>
      This means that:<br>
      a) I miscommunicated who is elgible to vote : which are project
      leads, committers and maintainers of mature projects, as well as
      the community manager. <br>
      b) I tallied wrongly<br>
      <br>
      I am summarizing the results again: the following people who fit
      the criteria in a) can vote. Note that XCP does not have a defined
      list of maintainers and committers, thus only the vote of the
      XCP's project lead - Mike McClurg - counts. Eligible votes came
      from:<br>
      <br>
      Ian Campbell<br>
      Mike McClurg<br>
      Jan Beulich<br>
      Lars Kurth<br>
      Tim Deegan<br>
      Ian Jackson<br>
      <br>
      5 in favour, 1 abstained.<br>
      <br>
      If no committer challenges by Friday, the vote will carry.<br>
      <br>
      Regards<br>
      Lars<br>
      <br>
      On 24/02/2013 03:10, Lars Kurth wrote:<br>
    </div>
    <blockquote cite="mid:512984AE.2060400@xen.org" type="cite">Hi
      everybody,
      <br>
      <br>
      sorry for the delay in posting the vote results for
      <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal">http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal</a>.
      <br>
      <br>
      The vote breakdown:
      <br>
      - 6 out of 7 Xen committers voted (including project leads)
      <br>
      - 5 were in favour
      <br>
      - 1 abstained due to the "choice of the ISC licence rather than a
      copyleft licence such as LGPLv2+"
      <br>
      <br>
      So overall the vote carries.
      <br>
      <br>
      We also several other community members voting in support of the
      proposal. We also discussed the proposal at the last Xen
      Maintainer, Committer and Developer Meeting, which expressed
      support for the proposal.
      <br>
      <br>
      What happens next?
      <br>
      I will work with the Mirage project lead on a detailed plan for
      the Incubation phase.
      <br>
      <br>
      Best Regards
      <br>
      Lars
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------030006050307060205060201--


--===============2848450748502928646==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2848450748502928646==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 16:36:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:36: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 1UAjyt-0006yP-IR; Wed, 27 Feb 2013 16:35:47 +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 1UAjyr-0006xs-1s; Wed, 27 Feb 2013 16:35:45 +0000
Received: from [85.158.137.99:43991] by server-13.bemta-3.messagelabs.com id
	C4/E4-25744-FD53E215; Wed, 27 Feb 2013 16:35:43 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1361982942!18420677!1
X-Originating-IP: [74.125.83.51]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1320 invoked from network); 27 Feb 2013 16:35:43 -0000
Received: from mail-ee0-f51.google.com (HELO mail-ee0-f51.google.com)
	(74.125.83.51)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 16:35:43 -0000
Received: by mail-ee0-f51.google.com with SMTP id d17so661498eek.38
	for <multiple recipients>; Wed, 27 Feb 2013 08:35:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:sender:message-id:date:from:reply-to:user-agent
	:mime-version:to:cc:subject:references:in-reply-to:content-type;
	bh=t4cH5aMHeGDQhqW9KCopbnz6oQ68MKdnO9EDPIqkqEE=;
	b=heMwVYuXG6cDud0pIapZe/jhF71TYmN1qEWWzQlQAmYxmCIwx787xCmVNfKfYVuYdy
	8WvsnKMlOV0UVrEH5tlseZw6VbKXTOSettmLha3ykde0iBfXL4XcYdlHM9+zGxgtOw79
	pb4BC+Nic+63R6c4r59XtY2yxqtxm3r436gEmrVZAX1hgDQ0lU85v9jiCC33VJOKunFG
	ziQfxWn+1N70E4A/81IPJ71ab/ffEKNygu/kTfhpCSTT8osJbhIrXl1TUZ2Rq5H2LlGF
	GLJtQCd2Kbx5qEUgsX8u/8G1jCuwJC6sNCNuTXd/bJCBmCSZw4Ntz9SE/hHhzyk8cVMP
	biKQ==
X-Received: by 10.15.101.204 with SMTP id bp52mr7261169eeb.31.1361982942595;
	Wed, 27 Feb 2013 08:35:42 -0800 (PST)
Received: from [172.16.26.11] ([151.225.0.38])
	by mx.google.com with ESMTPS id q42sm7280638eem.14.2013.02.27.08.35.40
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 08:35:41 -0800 (PST)
Message-ID: <512E35DA.4030507@xen.org>
Date: Wed, 27 Feb 2013 16:35:38 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: lars.kurth@xen.org
References: <512984AE.2060400@xen.org>
In-Reply-To: <512984AE.2060400@xen.org>
Cc: "xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-arm@lists.xen.org,
	Amir M Chaudhry <amc79@cam.ac.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [Vote] Results of formal vote for Mirage to be
 accepted as Xen.org Incubation Project - Correction
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="===============2848450748502928646=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2848450748502928646==
Content-Type: multipart/alternative;
 boundary="------------030006050307060205060201"

This is a multi-part message in MIME format.
--------------030006050307060205060201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I need to correct the results and apologize for a mistake I made : I 
should have double checked the process before sending out the request 
for voting.

http://www.xen.org/projects/governance.html says*"Voting:* The community 
manager arranges a timed private vote as outlined above (voting should 
be open for a minimum of a week). Any maintainer of a mature project and 
the Xen.org community manager is allowed to vote. Voting follows the 
conventions as laid out in 'Principle: Consensus Decision Making'."

This means that:
a) I miscommunicated who is elgible to vote : which are project leads, 
committers and maintainers of mature projects, as well as the community 
manager.
b) I tallied wrongly

I am summarizing the results again: the following people who fit the 
criteria in a) can vote. Note that XCP does not have a defined list of 
maintainers and committers, thus only the vote of the XCP's project lead 
- Mike McClurg - counts. Eligible votes came from:

Ian Campbell
Mike McClurg
Jan Beulich
Lars Kurth
Tim Deegan
Ian Jackson

5 in favour, 1 abstained.

If no committer challenges by Friday, the vote will carry.

Regards
Lars

On 24/02/2013 03:10, Lars Kurth wrote:
> Hi everybody,
>
> sorry for the delay in posting the vote results for 
> http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal.
>
> The vote breakdown:
> - 6 out of 7 Xen committers voted (including project leads)
> - 5 were in favour
> - 1 abstained due to the "choice of the ISC licence rather than a 
> copyleft licence such as LGPLv2+"
>
> So overall the vote carries.
>
> We also several other community members voting in support of the 
> proposal. We also discussed the proposal at the last Xen Maintainer, 
> Committer and Developer Meeting, which expressed support for the 
> proposal.
>
> What happens next?
> I will work with the Mirage project lead on a detailed plan for the 
> Incubation phase.
>
> Best Regards
> Lars


--------------030006050307060205060201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      I need to correct the results and apologize for a mistake I made :
      I should have double checked the process before sending out the
      request for voting. <br>
      <br>
      <a class="moz-txt-link-freetext" href="http://www.xen.org/projects/governance.html">http://www.xen.org/projects/governance.html</a> says<b> "Voting:</b>
      The community manager arranges a timed private vote as outlined
      above (voting should be open for a minimum of a week). Any
      maintainer of a mature project and the Xen.org community manager
      is allowed to vote. Voting follows the conventions as laid out in
      'Principle: Consensus Decision Making'."<br>
      <br>
      This means that:<br>
      a) I miscommunicated who is elgible to vote : which are project
      leads, committers and maintainers of mature projects, as well as
      the community manager. <br>
      b) I tallied wrongly<br>
      <br>
      I am summarizing the results again: the following people who fit
      the criteria in a) can vote. Note that XCP does not have a defined
      list of maintainers and committers, thus only the vote of the
      XCP's project lead - Mike McClurg - counts. Eligible votes came
      from:<br>
      <br>
      Ian Campbell<br>
      Mike McClurg<br>
      Jan Beulich<br>
      Lars Kurth<br>
      Tim Deegan<br>
      Ian Jackson<br>
      <br>
      5 in favour, 1 abstained.<br>
      <br>
      If no committer challenges by Friday, the vote will carry.<br>
      <br>
      Regards<br>
      Lars<br>
      <br>
      On 24/02/2013 03:10, Lars Kurth wrote:<br>
    </div>
    <blockquote cite="mid:512984AE.2060400@xen.org" type="cite">Hi
      everybody,
      <br>
      <br>
      sorry for the delay in posting the vote results for
      <a class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal">http://wiki.xen.org/wiki/Mirage_Incubation_Project_Proposal</a>.
      <br>
      <br>
      The vote breakdown:
      <br>
      - 6 out of 7 Xen committers voted (including project leads)
      <br>
      - 5 were in favour
      <br>
      - 1 abstained due to the "choice of the ISC licence rather than a
      copyleft licence such as LGPLv2+"
      <br>
      <br>
      So overall the vote carries.
      <br>
      <br>
      We also several other community members voting in support of the
      proposal. We also discussed the proposal at the last Xen
      Maintainer, Committer and Developer Meeting, which expressed
      support for the proposal.
      <br>
      <br>
      What happens next?
      <br>
      I will work with the Mirage project lead on a detailed plan for
      the Incubation phase.
      <br>
      <br>
      Best Regards
      <br>
      Lars
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------030006050307060205060201--


--===============2848450748502928646==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2848450748502928646==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 16:36:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjz1-0006zD-0V; Wed, 27 Feb 2013 16:35:55 +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 1UAjyz-0006z4-JP
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:35:53 +0000
Received: from [85.158.139.83:5567] by server-10.bemta-5.messagelabs.com id
	7D/EC-23714-8E53E215; Wed, 27 Feb 2013 16:35:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361982938!29518988!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24479 invoked from network); 27 Feb 2013 16:35:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 16:35:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:35:38 +0000
Message-Id: <512E43E802000078000C1A21@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:35:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-3-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 02/22] Dynamically allocate d->evtchn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1172,15 +1172,26 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
>  
>  int evtchn_init(struct domain *d)
>  {
> +    BUILD_BUG_ON(sizeof(struct evtchn *) * NR_EVTCHN_BUCKETS > PAGE_SIZE);
> +    d->evtchn = alloc_xenheap_page();

You may not have monitored other changes that were done
meanwhile. With fb034f42648ecac835a1666def468f673edd2725,
please use xmalloc_array() here (but keep the BUILD_BUG_ON()).

> +
> +    if ( d->evtchn == NULL )
> +        return -ENOMEM;
> +    clear_page(d->evtchn);
> +
>      spin_lock_init(&d->event_lock);
> -    if ( get_free_port(d) != 0 )
> +    if ( get_free_port(d) != 0 ) {

The opening brace belongs on its own line.

> +        free_xenheap_page(d->evtchn);
>          return -EINVAL;
> +    }
>      evtchn_from_port(d, 0)->state = ECS_RESERVED;
>  
>  #if MAX_VIRT_CPUS > BITS_PER_LONG
>      d->poll_mask = xmalloc_array(unsigned long, BITS_TO_LONGS(MAX_VIRT_CPUS));
> -    if ( !d->poll_mask )
> +    if ( !d->poll_mask ) {

And here again. Please also check your other patches whether
there are further instances of this.

Jan

> +        free_xenheap_page(d->evtchn);
>          return -ENOMEM;
> +    }
>      bitmap_zero(d->poll_mask, MAX_VIRT_CPUS);
>  #endif
>  
> @@ -1214,6 +1225,8 @@ void evtchn_destroy(struct domain *d)
>      spin_unlock(&d->event_lock);
>  
>      clear_global_virq_handlers(d);
> +
> +    free_xenheap_page(d->evtchn);
>  }
>  
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index f6846d4..812bd87 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -260,7 +260,7 @@ struct domain
>      spinlock_t       rangesets_lock;
>  
>      /* Event channel information. */
> -    struct evtchn   *evtchn[NR_EVTCHN_BUCKETS];
> +    struct evtchn  **evtchn;
>      spinlock_t       event_lock;
>  
>      struct grant_table *grant_table;
> -- 
> 1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:36:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16: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 1UAjz1-0006zD-0V; Wed, 27 Feb 2013 16:35:55 +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 1UAjyz-0006z4-JP
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:35:53 +0000
Received: from [85.158.139.83:5567] by server-10.bemta-5.messagelabs.com id
	7D/EC-23714-8E53E215; Wed, 27 Feb 2013 16:35:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361982938!29518988!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24479 invoked from network); 27 Feb 2013 16:35:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 16:35:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:35:38 +0000
Message-Id: <512E43E802000078000C1A21@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:35:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-3-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 02/22] Dynamically allocate d->evtchn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1172,15 +1172,26 @@ void notify_via_xen_event_channel(struct domain *ld, int lport)
>  
>  int evtchn_init(struct domain *d)
>  {
> +    BUILD_BUG_ON(sizeof(struct evtchn *) * NR_EVTCHN_BUCKETS > PAGE_SIZE);
> +    d->evtchn = alloc_xenheap_page();

You may not have monitored other changes that were done
meanwhile. With fb034f42648ecac835a1666def468f673edd2725,
please use xmalloc_array() here (but keep the BUILD_BUG_ON()).

> +
> +    if ( d->evtchn == NULL )
> +        return -ENOMEM;
> +    clear_page(d->evtchn);
> +
>      spin_lock_init(&d->event_lock);
> -    if ( get_free_port(d) != 0 )
> +    if ( get_free_port(d) != 0 ) {

The opening brace belongs on its own line.

> +        free_xenheap_page(d->evtchn);
>          return -EINVAL;
> +    }
>      evtchn_from_port(d, 0)->state = ECS_RESERVED;
>  
>  #if MAX_VIRT_CPUS > BITS_PER_LONG
>      d->poll_mask = xmalloc_array(unsigned long, BITS_TO_LONGS(MAX_VIRT_CPUS));
> -    if ( !d->poll_mask )
> +    if ( !d->poll_mask ) {

And here again. Please also check your other patches whether
there are further instances of this.

Jan

> +        free_xenheap_page(d->evtchn);
>          return -ENOMEM;
> +    }
>      bitmap_zero(d->poll_mask, MAX_VIRT_CPUS);
>  #endif
>  
> @@ -1214,6 +1225,8 @@ void evtchn_destroy(struct domain *d)
>      spin_unlock(&d->event_lock);
>  
>      clear_global_virq_handlers(d);
> +
> +    free_xenheap_page(d->evtchn);
>  }
>  
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index f6846d4..812bd87 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -260,7 +260,7 @@ struct domain
>      spinlock_t       rangesets_lock;
>  
>      /* Event channel information. */
> -    struct evtchn   *evtchn[NR_EVTCHN_BUCKETS];
> +    struct evtchn  **evtchn;
>      spinlock_t       event_lock;
>  
>      struct grant_table *grant_table;
> -- 
> 1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:41:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:41: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 1UAk4a-0007S2-QN; Wed, 27 Feb 2013 16:41:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAk4Z-0007Rx-Pt
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:41:40 +0000
Received: from [85.158.139.83:13116] by server-15.bemta-5.messagelabs.com id
	6F/BF-22815-3473E215; Wed, 27 Feb 2013 16:41:39 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361983297!21933056!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MjM2NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15196 invoked from network); 27 Feb 2013 16:41:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-182.messagelabs.com with SMTP;
	27 Feb 2013 16:41:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 27 Feb 2013 08:41:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="296684393"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 27 Feb 2013 08:41:29 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:41:29 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:41:28 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 00:41:27 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFN5kqZTiEd/FTjyR1sPJXJqZr5iNml7wgABN1fA=
Date: Wed, 27 Feb 2013 16:41:25 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540CD75@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
	<512DFD5102000078000C1764@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C792@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C792@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> On 27.02.13 at 12:08, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>> wrote: 
>>> Jan Beulich wrote:
>>>>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>>>>> 		recommended by Intel SDM: LOG MCA REGISTER:
>>>>> 		SAVE IA32_MCi_STATUS;
>>>>> 		If MISCV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SAVE IA32_MCi_MISC;
>>>>> 		FI;
>>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SAVE IA32_MCi_ADDR;
>>>>> 		FI;
>>>>> 		IF CLEAR_MC_BANK = TRUE
>>>>> 		THEN
>>>>> 			SET all 0 to IA32_MCi_STATUS;
>>>>> 		If MISCV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SET all 0 to IA32_MCi_MISC;
>>>>> 		FI;
>>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SET all 0 to IA32_MCi_ADDR;
>>>>> 		FI;
>>>>> 
>>>>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>>>>> error occur (which indicated by MCi_STATUS), so only clear
>>>>> MCi_STATUS at mce handler is an acceptable work around -- after
>>>>> all, to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
>>>> 
>>>> So then what - revert your original patch (and ignore the SDM)?
>>>> I'm not in favor of this...
>>> 
>>> Not revert entire 23327, but only use this patch to revert
>>> MCi_ADDR/MISC clear. 
>>> 
>>> I also agree it's not good, but currently seems we don't have a
>>> simple and clean way to fix it, except we spend much time to to
>>> update xen-mceinj *tools* -- even so it's low-priority?
>> 
>> No, fixing the tool seems unnecessary for this problem, all we
>> need is a way to avoid the problematic MSR writes when finishing
>> an injected MCE. That's fully contained to the hypervisor.
>> 
>> Jan
> 
> The problem comes from xen-mceinj tools simulate *some* banks for
> *some* cpus (intpose_arr array). Tools sometimes access simulated
> value, sometimes access real hardware --> that's problematic syntax
> and what really need fix.   
> 
> Thanks,
> Jinsong

OK, update bugfix patch, better than drop clear MCi_ADDR/MISC in this patch, will send out later.

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:41:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:41: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 1UAk4a-0007S2-QN; Wed, 27 Feb 2013 16:41:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAk4Z-0007Rx-Pt
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:41:40 +0000
Received: from [85.158.139.83:13116] by server-15.bemta-5.messagelabs.com id
	6F/BF-22815-3473E215; Wed, 27 Feb 2013 16:41:39 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1361983297!21933056!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3MjM2NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15196 invoked from network); 27 Feb 2013 16:41:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-182.messagelabs.com with SMTP;
	27 Feb 2013 16:41:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 27 Feb 2013 08:41:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="296684393"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 27 Feb 2013 08:41:29 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:41:29 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:41:28 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 00:41:27 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: Xen mce bugfix
Thread-Index: AQHOFN5kqZTiEd/FTjyR1sPJXJqZr5iNml7wgABN1fA=
Date: Wed, 27 Feb 2013 16:41:25 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540CD75@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540C458@SHSMSX101.ccr.corp.intel.com>
	<512DE7C202000078000C164D@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C5B6@SHSMSX101.ccr.corp.intel.com>
	<512DF4F602000078000C16E3@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C69F@SHSMSX101.ccr.corp.intel.com>
	<512DFD5102000078000C1764@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540C792@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540C792@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen mce bugfix
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> On 27.02.13 at 12:08, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>> wrote: 
>>> Jan Beulich wrote:
>>>>>>> On 27.02.13 at 11:37, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> The reason of the former patch to clear MCi_ADDR/MISC is that it's
>>>>> 		recommended by Intel SDM: LOG MCA REGISTER:
>>>>> 		SAVE IA32_MCi_STATUS;
>>>>> 		If MISCV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SAVE IA32_MCi_MISC;
>>>>> 		FI;
>>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SAVE IA32_MCi_ADDR;
>>>>> 		FI;
>>>>> 		IF CLEAR_MC_BANK = TRUE
>>>>> 		THEN
>>>>> 			SET all 0 to IA32_MCi_STATUS;
>>>>> 		If MISCV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SET all 0 to IA32_MCi_MISC;
>>>>> 		FI;
>>>>> 		IF ADDRV in IA32_MCi_STATUS
>>>>> 		THEN
>>>>> 			SET all 0 to IA32_MCi_ADDR;
>>>>> 		FI;
>>>>> 
>>>>> For Xen mce, it's meaningful to read MCi_ADDR/MISC only when real
>>>>> error occur (which indicated by MCi_STATUS), so only clear
>>>>> MCi_STATUS at mce handler is an acceptable work around -- after
>>>>> all, to read MCi_ADDR/MISC is pointless if MCi_STATUS is 0.
>>>> 
>>>> So then what - revert your original patch (and ignore the SDM)?
>>>> I'm not in favor of this...
>>> 
>>> Not revert entire 23327, but only use this patch to revert
>>> MCi_ADDR/MISC clear. 
>>> 
>>> I also agree it's not good, but currently seems we don't have a
>>> simple and clean way to fix it, except we spend much time to to
>>> update xen-mceinj *tools* -- even so it's low-priority?
>> 
>> No, fixing the tool seems unnecessary for this problem, all we
>> need is a way to avoid the problematic MSR writes when finishing
>> an injected MCE. That's fully contained to the hypervisor.
>> 
>> Jan
> 
> The problem comes from xen-mceinj tools simulate *some* banks for
> *some* cpus (intpose_arr array). Tools sometimes access simulated
> value, sometimes access real hardware --> that's problematic syntax
> and what really need fix.   
> 
> Thanks,
> Jinsong

OK, update bugfix patch, better than drop clear MCi_ADDR/MISC in this patch, will send out later.

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:43:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:43: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 1UAk5w-0007WE-AZ; Wed, 27 Feb 2013 16:43:04 +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 1UAk5t-0007W3-L5
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:43:02 +0000
Received: from [85.158.138.51:34189] by server-13.bemta-3.messagelabs.com id
	94/42-25744-4973E215; Wed, 27 Feb 2013 16:43:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361983380!29566786!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7066 invoked from network); 27 Feb 2013 16:43:00 -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; 27 Feb 2013 16:43:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:42:59 +0000
Message-Id: <512E45A002000078000C1A46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:42:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> +/* commands:
> + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> + *                _NONE      supported types are or'ed in return value of
> + *                           the hypercall.
> + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> + */
> +#define EVTCHN_EXTENDED_QUERY 0
> +/* supported extended event channel */
> +#define EVTCHN_EXTENDED_NONE  0
> +#define _EVTCHN_EXTENDED_L3   0
> +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> +struct evtchn_register_extended {
> +    /* IN parameters. */
> +    uint32_t cmd;

Looking at patch 18 you seem to indeed plan on passing a bit mask
with a single bit set as command. Is that really reasonable? I can
see the need for the query to return a bit mask, but that's it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:43:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:43: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 1UAk5w-0007WE-AZ; Wed, 27 Feb 2013 16:43:04 +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 1UAk5t-0007W3-L5
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:43:02 +0000
Received: from [85.158.138.51:34189] by server-13.bemta-3.messagelabs.com id
	94/42-25744-4973E215; Wed, 27 Feb 2013 16:43:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1361983380!29566786!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7066 invoked from network); 27 Feb 2013 16:43:00 -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; 27 Feb 2013 16:43:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:42:59 +0000
Message-Id: <512E45A002000078000C1A46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:42:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> +/* commands:
> + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> + *                _NONE      supported types are or'ed in return value of
> + *                           the hypercall.
> + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> + */
> +#define EVTCHN_EXTENDED_QUERY 0
> +/* supported extended event channel */
> +#define EVTCHN_EXTENDED_NONE  0
> +#define _EVTCHN_EXTENDED_L3   0
> +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> +struct evtchn_register_extended {
> +    /* IN parameters. */
> +    uint32_t cmd;

Looking at patch 18 you seem to indeed plan on passing a bit mask
with a single bit set as command. Is that really reasonable? I can
see the need for the query to return a bit mask, but that's it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:45:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:45: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 1UAk7s-0007ee-UE; Wed, 27 Feb 2013 16:45:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAk7r-0007eR-CI
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:45:03 +0000
Received: from [85.158.139.211:2609] by server-14.bemta-5.messagelabs.com id
	15/8D-13158-E083E215; Wed, 27 Feb 2013 16:45:02 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361983500!19640778!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg5Njk3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28494 invoked from network); 27 Feb 2013 16:45:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-206.messagelabs.com with SMTP;
	27 Feb 2013 16:45:01 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Feb 2013 08:43:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="268594752"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2013 08:44:59 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:44:59 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:44:58 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 00:44:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
Thread-Index: Ac4VCcX3XArdsC0/T2GFEhh+i5sJSQ==
Date: Wed, 27 Feb 2013 16:44:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540CD9B@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_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>
Subject: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCA: bugfix for mca bank clear

mcabank_clear() is common code for real h/w mca and s/w simulated mca.
Under s/w simulated case, getting status via mca_rdmsr may trigger #GP
if MCx_ADDR/MISC not supported by real h/w.

This patch fix the bug. It always invalidates intpose for s/w simulated
mca case, and do check real h/w status ADDRV/MISCV to avoid #GP when
clear MCx_ADDR/MISC for h/w mca case.

Reported-by: Ren Yongjie <yongjie.ren@intel.com>
Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>

diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 08:05:15 2013 +0800
@@ -138,17 +138,28 @@
     xfree(banks);
 }
=20
+/*
+ * Common code for real h/w mca and s/w simulated mca.
+ * Always invalidate intpose for s/w simulated mca case, and do check
+ * real h/w status ADDRV/MISCV to avoid #GP when clear MCx_ADDR/MISC
+ * for h/w mca case.
+ */
 static void mcabank_clear(int banknum)
 {
-    uint64_t status;
+    uint64_t hw_status;
=20
-    status =3D mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
+    /* For s/w simulated mca case */
+    intpose_inval(smp_processor_id(), MSR_IA32_MCx_ADDR(banknum));
+    intpose_inval(smp_processor_id(), MSR_IA32_MCx_MISC(banknum));
=20
-    if (status & MCi_STATUS_ADDRV)
-        mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
-    if (status & MCi_STATUS_MISCV)
-        mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
+    /* For real h/w mca case */
+    rdmsrl(MSR_IA32_MCx_STATUS(banknum), hw_status);
+    if (hw_status & MCi_STATUS_ADDRV)
+        wrmsrl(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
+    if (hw_status & MCi_STATUS_MISCV)
+        wrmsrl(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
=20
+    /* For both cases */
     mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
 }
 =

--_002_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="mca-bank-clear-bugfix.patch"
Content-Description: mca-bank-clear-bugfix.patch
Content-Disposition: attachment; filename="mca-bank-clear-bugfix.patch";
	size=1828; creation-date="Wed, 27 Feb 2013 16:37:45 GMT";
	modification-date="Thu, 28 Feb 2013 00:26:38 GMT"
Content-Transfer-Encoding: base64

WGVuL01DQTogYnVnZml4IGZvciBtY2EgYmFuayBjbGVhcgoKbWNhYmFua19jbGVhcigpIGlzIGNv
bW1vbiBjb2RlIGZvciByZWFsIGgvdyBtY2EgYW5kIHMvdyBzaW11bGF0ZWQgbWNhLgpVbmRlciBz
L3cgc2ltdWxhdGVkIGNhc2UsIGdldHRpbmcgc3RhdHVzIHZpYSBtY2FfcmRtc3IgbWF5IHRyaWdn
ZXIgI0dQCmlmIE1DeF9BRERSL01JU0Mgbm90IHN1cHBvcnRlZCBieSByZWFsIGgvdy4KClRoaXMg
cGF0Y2ggZml4IHRoZSBidWcuIEl0IGFsd2F5cyBpbnZhbGlkYXRlcyBpbnRwb3NlIGZvciBzL3cg
c2ltdWxhdGVkCm1jYSBjYXNlLCBhbmQgZG8gY2hlY2sgcmVhbCBoL3cgc3RhdHVzIEFERFJWL01J
U0NWIHRvIGF2b2lkICNHUCB3aGVuCmNsZWFyIE1DeF9BRERSL01JU0MgZm9yIGgvdyBtY2EgY2Fz
ZS4KClJlcG9ydGVkLWJ5OiBSZW4gWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50ZWwuY29tPgpTaW5n
ZWQtb2ZmLWJ5OiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciBl
ODRhNzlkMTFkN2EgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmMKLS0tIGEveGVuL2FyY2gv
eDg2L2NwdS9tY2hlY2svbWNlLmMJVGh1IE5vdiAwMSAwMTo0MTowMyAyMDEyICswODAwCisrKyBi
L3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZS5jCVRodSBGZWIgMjggMDg6MDU6MTUgMjAxMyAr
MDgwMApAQCAtMTM4LDE3ICsxMzgsMjggQEAKICAgICB4ZnJlZShiYW5rcyk7CiB9CiAKKy8qCisg
KiBDb21tb24gY29kZSBmb3IgcmVhbCBoL3cgbWNhIGFuZCBzL3cgc2ltdWxhdGVkIG1jYS4KKyAq
IEFsd2F5cyBpbnZhbGlkYXRlIGludHBvc2UgZm9yIHMvdyBzaW11bGF0ZWQgbWNhIGNhc2UsIGFu
ZCBkbyBjaGVjaworICogcmVhbCBoL3cgc3RhdHVzIEFERFJWL01JU0NWIHRvIGF2b2lkICNHUCB3
aGVuIGNsZWFyIE1DeF9BRERSL01JU0MKKyAqIGZvciBoL3cgbWNhIGNhc2UuCisgKi8KIHN0YXRp
YyB2b2lkIG1jYWJhbmtfY2xlYXIoaW50IGJhbmtudW0pCiB7Ci0gICAgdWludDY0X3Qgc3RhdHVz
OworICAgIHVpbnQ2NF90IGh3X3N0YXR1czsKIAotICAgIHN0YXR1cyA9IG1jYV9yZG1zcihNU1Jf
SUEzMl9NQ3hfU1RBVFVTKGJhbmtudW0pKTsKKyAgICAvKiBGb3Igcy93IHNpbXVsYXRlZCBtY2Eg
Y2FzZSAqLworICAgIGludHBvc2VfaW52YWwoc21wX3Byb2Nlc3Nvcl9pZCgpLCBNU1JfSUEzMl9N
Q3hfQUREUihiYW5rbnVtKSk7CisgICAgaW50cG9zZV9pbnZhbChzbXBfcHJvY2Vzc29yX2lkKCks
IE1TUl9JQTMyX01DeF9NSVNDKGJhbmtudW0pKTsKIAotICAgIGlmIChzdGF0dXMgJiBNQ2lfU1RB
VFVTX0FERFJWKQotICAgICAgICBtY2Ffd3Jtc3IoTVNSX0lBMzJfTUN4X0FERFIoYmFua251bSks
IDB4MFVMTCk7Ci0gICAgaWYgKHN0YXR1cyAmIE1DaV9TVEFUVVNfTUlTQ1YpCi0gICAgICAgIG1j
YV93cm1zcihNU1JfSUEzMl9NQ3hfTUlTQyhiYW5rbnVtKSwgMHgwVUxMKTsKKyAgICAvKiBGb3Ig
cmVhbCBoL3cgbWNhIGNhc2UgKi8KKyAgICByZG1zcmwoTVNSX0lBMzJfTUN4X1NUQVRVUyhiYW5r
bnVtKSwgaHdfc3RhdHVzKTsKKyAgICBpZiAoaHdfc3RhdHVzICYgTUNpX1NUQVRVU19BRERSVikK
KyAgICAgICAgd3Jtc3JsKE1TUl9JQTMyX01DeF9BRERSKGJhbmtudW0pLCAweDBVTEwpOworICAg
IGlmIChod19zdGF0dXMgJiBNQ2lfU1RBVFVTX01JU0NWKQorICAgICAgICB3cm1zcmwoTVNSX0lB
MzJfTUN4X01JU0MoYmFua251bSksIDB4MFVMTCk7CiAKKyAgICAvKiBGb3IgYm90aCBjYXNlcyAq
LwogICAgIG1jYV93cm1zcihNU1JfSUEzMl9NQ3hfU1RBVFVTKGJhbmtudW0pLCAweDBVTEwpOwog
fQogCg==

--_002_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 27 16:45:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:45: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 1UAk7s-0007ee-UE; Wed, 27 Feb 2013 16:45:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAk7r-0007eR-CI
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:45:03 +0000
Received: from [85.158.139.211:2609] by server-14.bemta-5.messagelabs.com id
	15/8D-13158-E083E215; Wed, 27 Feb 2013 16:45:02 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1361983500!19640778!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg5Njk3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28494 invoked from network); 27 Feb 2013 16:45:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-206.messagelabs.com with SMTP;
	27 Feb 2013 16:45:01 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 27 Feb 2013 08:43:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="268594752"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2013 08:44:59 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:44:59 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:44:58 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 00:44:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
Thread-Index: Ac4VCcX3XArdsC0/T2GFEhh+i5sJSQ==
Date: Wed, 27 Feb 2013 16:44:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540CD9B@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_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>
Subject: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCA: bugfix for mca bank clear

mcabank_clear() is common code for real h/w mca and s/w simulated mca.
Under s/w simulated case, getting status via mca_rdmsr may trigger #GP
if MCx_ADDR/MISC not supported by real h/w.

This patch fix the bug. It always invalidates intpose for s/w simulated
mca case, and do check real h/w status ADDRV/MISCV to avoid #GP when
clear MCx_ADDR/MISC for h/w mca case.

Reported-by: Ren Yongjie <yongjie.ren@intel.com>
Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>

diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 08:05:15 2013 +0800
@@ -138,17 +138,28 @@
     xfree(banks);
 }
=20
+/*
+ * Common code for real h/w mca and s/w simulated mca.
+ * Always invalidate intpose for s/w simulated mca case, and do check
+ * real h/w status ADDRV/MISCV to avoid #GP when clear MCx_ADDR/MISC
+ * for h/w mca case.
+ */
 static void mcabank_clear(int banknum)
 {
-    uint64_t status;
+    uint64_t hw_status;
=20
-    status =3D mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
+    /* For s/w simulated mca case */
+    intpose_inval(smp_processor_id(), MSR_IA32_MCx_ADDR(banknum));
+    intpose_inval(smp_processor_id(), MSR_IA32_MCx_MISC(banknum));
=20
-    if (status & MCi_STATUS_ADDRV)
-        mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
-    if (status & MCi_STATUS_MISCV)
-        mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
+    /* For real h/w mca case */
+    rdmsrl(MSR_IA32_MCx_STATUS(banknum), hw_status);
+    if (hw_status & MCi_STATUS_ADDRV)
+        wrmsrl(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
+    if (hw_status & MCi_STATUS_MISCV)
+        wrmsrl(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
=20
+    /* For both cases */
     mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
 }
 =

--_002_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="mca-bank-clear-bugfix.patch"
Content-Description: mca-bank-clear-bugfix.patch
Content-Disposition: attachment; filename="mca-bank-clear-bugfix.patch";
	size=1828; creation-date="Wed, 27 Feb 2013 16:37:45 GMT";
	modification-date="Thu, 28 Feb 2013 00:26:38 GMT"
Content-Transfer-Encoding: base64

WGVuL01DQTogYnVnZml4IGZvciBtY2EgYmFuayBjbGVhcgoKbWNhYmFua19jbGVhcigpIGlzIGNv
bW1vbiBjb2RlIGZvciByZWFsIGgvdyBtY2EgYW5kIHMvdyBzaW11bGF0ZWQgbWNhLgpVbmRlciBz
L3cgc2ltdWxhdGVkIGNhc2UsIGdldHRpbmcgc3RhdHVzIHZpYSBtY2FfcmRtc3IgbWF5IHRyaWdn
ZXIgI0dQCmlmIE1DeF9BRERSL01JU0Mgbm90IHN1cHBvcnRlZCBieSByZWFsIGgvdy4KClRoaXMg
cGF0Y2ggZml4IHRoZSBidWcuIEl0IGFsd2F5cyBpbnZhbGlkYXRlcyBpbnRwb3NlIGZvciBzL3cg
c2ltdWxhdGVkCm1jYSBjYXNlLCBhbmQgZG8gY2hlY2sgcmVhbCBoL3cgc3RhdHVzIEFERFJWL01J
U0NWIHRvIGF2b2lkICNHUCB3aGVuCmNsZWFyIE1DeF9BRERSL01JU0MgZm9yIGgvdyBtY2EgY2Fz
ZS4KClJlcG9ydGVkLWJ5OiBSZW4gWW9uZ2ppZSA8eW9uZ2ppZS5yZW5AaW50ZWwuY29tPgpTaW5n
ZWQtb2ZmLWJ5OiBMaXUgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciBl
ODRhNzlkMTFkN2EgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmMKLS0tIGEveGVuL2FyY2gv
eDg2L2NwdS9tY2hlY2svbWNlLmMJVGh1IE5vdiAwMSAwMTo0MTowMyAyMDEyICswODAwCisrKyBi
L3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZS5jCVRodSBGZWIgMjggMDg6MDU6MTUgMjAxMyAr
MDgwMApAQCAtMTM4LDE3ICsxMzgsMjggQEAKICAgICB4ZnJlZShiYW5rcyk7CiB9CiAKKy8qCisg
KiBDb21tb24gY29kZSBmb3IgcmVhbCBoL3cgbWNhIGFuZCBzL3cgc2ltdWxhdGVkIG1jYS4KKyAq
IEFsd2F5cyBpbnZhbGlkYXRlIGludHBvc2UgZm9yIHMvdyBzaW11bGF0ZWQgbWNhIGNhc2UsIGFu
ZCBkbyBjaGVjaworICogcmVhbCBoL3cgc3RhdHVzIEFERFJWL01JU0NWIHRvIGF2b2lkICNHUCB3
aGVuIGNsZWFyIE1DeF9BRERSL01JU0MKKyAqIGZvciBoL3cgbWNhIGNhc2UuCisgKi8KIHN0YXRp
YyB2b2lkIG1jYWJhbmtfY2xlYXIoaW50IGJhbmtudW0pCiB7Ci0gICAgdWludDY0X3Qgc3RhdHVz
OworICAgIHVpbnQ2NF90IGh3X3N0YXR1czsKIAotICAgIHN0YXR1cyA9IG1jYV9yZG1zcihNU1Jf
SUEzMl9NQ3hfU1RBVFVTKGJhbmtudW0pKTsKKyAgICAvKiBGb3Igcy93IHNpbXVsYXRlZCBtY2Eg
Y2FzZSAqLworICAgIGludHBvc2VfaW52YWwoc21wX3Byb2Nlc3Nvcl9pZCgpLCBNU1JfSUEzMl9N
Q3hfQUREUihiYW5rbnVtKSk7CisgICAgaW50cG9zZV9pbnZhbChzbXBfcHJvY2Vzc29yX2lkKCks
IE1TUl9JQTMyX01DeF9NSVNDKGJhbmtudW0pKTsKIAotICAgIGlmIChzdGF0dXMgJiBNQ2lfU1RB
VFVTX0FERFJWKQotICAgICAgICBtY2Ffd3Jtc3IoTVNSX0lBMzJfTUN4X0FERFIoYmFua251bSks
IDB4MFVMTCk7Ci0gICAgaWYgKHN0YXR1cyAmIE1DaV9TVEFUVVNfTUlTQ1YpCi0gICAgICAgIG1j
YV93cm1zcihNU1JfSUEzMl9NQ3hfTUlTQyhiYW5rbnVtKSwgMHgwVUxMKTsKKyAgICAvKiBGb3Ig
cmVhbCBoL3cgbWNhIGNhc2UgKi8KKyAgICByZG1zcmwoTVNSX0lBMzJfTUN4X1NUQVRVUyhiYW5r
bnVtKSwgaHdfc3RhdHVzKTsKKyAgICBpZiAoaHdfc3RhdHVzICYgTUNpX1NUQVRVU19BRERSVikK
KyAgICAgICAgd3Jtc3JsKE1TUl9JQTMyX01DeF9BRERSKGJhbmtudW0pLCAweDBVTEwpOworICAg
IGlmIChod19zdGF0dXMgJiBNQ2lfU1RBVFVTX01JU0NWKQorICAgICAgICB3cm1zcmwoTVNSX0lB
MzJfTUN4X01JU0MoYmFua251bSksIDB4MFVMTCk7CiAKKyAgICAvKiBGb3IgYm90aCBjYXNlcyAq
LwogICAgIG1jYV93cm1zcihNU1JfSUEzMl9NQ3hfU1RBVFVTKGJhbmtudW0pLCAweDBVTEwpOwog
fQogCg==

--_002_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233540CD9BSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 27 16:47:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:47: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 1UAk9j-0007ou-Kr; Wed, 27 Feb 2013 16:46:59 +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 1UAk9h-0007oi-S6
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:46:58 +0000
Received: from [85.158.138.51:44341] by server-14.bemta-3.messagelabs.com id
	5C/12-27076-1883E215; Wed, 27 Feb 2013 16:46:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361983615!29433931!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzUyOTkx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21603 invoked from network); 27 Feb 2013 16:46:56 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-174.messagelabs.com with SMTP;
	27 Feb 2013 16:46:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Feb 2013 08:46:54 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="268595939"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2013 08:46:49 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:46:47 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 00:46:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 2/2] Minor fix for rdmsrl
Thread-Index: Ac4VCgYgaDPIeN3VQXC+k/Nn+vsjXQ==
Date: Wed, 27 Feb 2013 16:46:44 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540CDAA@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_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>
Subject: [Xen-devel] [PATCH 2/2] Minor fix for rdmsrl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Minor fix for rdmsrl

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>

diff -r d3ee3732acf3 xen/include/asm-x86/msr.h
--- a/xen/include/asm-x86/msr.h	Thu Feb 28 08:05:15 2013 +0800
+++ b/xen/include/asm-x86/msr.h	Thu Feb 28 08:15:17 2013 +0800
@@ -20,7 +20,7 @@
 			    : "=3Da" (a__), "=3Dd" (b__) \
 			    : "c" (msr)); \
        val =3D a__ | ((u64)b__<<32); \
-} while(0);
+} while(0)
=20
 #define wrmsr(msr,val1,val2) \
      __asm__ __volatile__("wrmsr" \=

--_002_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="rdmsrl-minor-fix.patch"
Content-Description: rdmsrl-minor-fix.patch
Content-Disposition: attachment; filename="rdmsrl-minor-fix.patch"; size=458;
	creation-date="Wed, 27 Feb 2013 16:37:50 GMT";
	modification-date="Thu, 28 Feb 2013 00:25:50 GMT"
Content-Transfer-Encoding: base64

TWlub3IgZml4IGZvciByZG1zcmwKClNpZ25lZC1vZmYtYnk6IExpdSBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGQzZWUzNzMyYWNmMyB4ZW4vaW5jbHVkZS9hc20teDg2
L21zci5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLmgJVGh1IEZlYiAyOCAwODowNTox
NSAyMDEzICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLmgJVGh1IEZlYiAyOCAw
ODoxNToxNyAyMDEzICswODAwCkBAIC0yMCw3ICsyMCw3IEBACiAJCQkgICAgOiAiPWEiIChhX18p
LCAiPWQiIChiX18pIFwKIAkJCSAgICA6ICJjIiAobXNyKSk7IFwKICAgICAgICB2YWwgPSBhX18g
fCAoKHU2NCliX188PDMyKTsgXAotfSB3aGlsZSgwKTsKK30gd2hpbGUoMCkKIAogI2RlZmluZSB3
cm1zcihtc3IsdmFsMSx2YWwyKSBcCiAgICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCJ3cm1zciIg
XAo=

--_002_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 27 16:47:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:47: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 1UAk9j-0007ou-Kr; Wed, 27 Feb 2013 16:46:59 +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 1UAk9h-0007oi-S6
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:46:58 +0000
Received: from [85.158.138.51:44341] by server-14.bemta-3.messagelabs.com id
	5C/12-27076-1883E215; Wed, 27 Feb 2013 16:46:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1361983615!29433931!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzUyOTkx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21603 invoked from network); 27 Feb 2013 16:46:56 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-174.messagelabs.com with SMTP;
	27 Feb 2013 16:46:56 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 27 Feb 2013 08:46:54 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,747,1355126400"; d="scan'208";a="268595939"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 27 Feb 2013 08:46:49 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 27 Feb 2013 08:46:47 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 00:46:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 2/2] Minor fix for rdmsrl
Thread-Index: Ac4VCgYgaDPIeN3VQXC+k/Nn+vsjXQ==
Date: Wed, 27 Feb 2013 16:46:44 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540CDAA@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_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>
Subject: [Xen-devel] [PATCH 2/2] Minor fix for rdmsrl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Minor fix for rdmsrl

Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>

diff -r d3ee3732acf3 xen/include/asm-x86/msr.h
--- a/xen/include/asm-x86/msr.h	Thu Feb 28 08:05:15 2013 +0800
+++ b/xen/include/asm-x86/msr.h	Thu Feb 28 08:15:17 2013 +0800
@@ -20,7 +20,7 @@
 			    : "=3Da" (a__), "=3Dd" (b__) \
 			    : "c" (msr)); \
        val =3D a__ | ((u64)b__<<32); \
-} while(0);
+} while(0)
=20
 #define wrmsr(msr,val1,val2) \
      __asm__ __volatile__("wrmsr" \=

--_002_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="rdmsrl-minor-fix.patch"
Content-Description: rdmsrl-minor-fix.patch
Content-Disposition: attachment; filename="rdmsrl-minor-fix.patch"; size=458;
	creation-date="Wed, 27 Feb 2013 16:37:50 GMT";
	modification-date="Thu, 28 Feb 2013 00:25:50 GMT"
Content-Transfer-Encoding: base64

TWlub3IgZml4IGZvciByZG1zcmwKClNpZ25lZC1vZmYtYnk6IExpdSBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGQzZWUzNzMyYWNmMyB4ZW4vaW5jbHVkZS9hc20teDg2
L21zci5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLmgJVGh1IEZlYiAyOCAwODowNTox
NSAyMDEzICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLmgJVGh1IEZlYiAyOCAw
ODoxNToxNyAyMDEzICswODAwCkBAIC0yMCw3ICsyMCw3IEBACiAJCQkgICAgOiAiPWEiIChhX18p
LCAiPWQiIChiX18pIFwKIAkJCSAgICA6ICJjIiAobXNyKSk7IFwKICAgICAgICB2YWwgPSBhX18g
fCAoKHU2NCliX188PDMyKTsgXAotfSB3aGlsZSgwKTsKK30gd2hpbGUoMCkKIAogI2RlZmluZSB3
cm1zcihtc3IsdmFsMSx2YWwyKSBcCiAgICAgIF9fYXNtX18gX192b2xhdGlsZV9fKCJ3cm1zciIg
XAo=

--_002_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233540CDAASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Feb 27 16:48:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:48: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 1UAkAY-0007tP-3R; Wed, 27 Feb 2013 16:47:50 +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 1UAkAW-0007t9-Dy
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:47:48 +0000
Received: from [85.158.143.99:24838] by server-1.bemta-4.messagelabs.com id
	7F/F6-06203-3B83E215; Wed, 27 Feb 2013 16:47:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361983667!29551103!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9709 invoked from network); 27 Feb 2013 16:47:47 -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 Feb 2013 16:47:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:47:47 +0000
Message-Id: <512E46C002000078000C1A71@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:47:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 12/22] Add supported extended event
 channel ABI bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |    4 ++++
>  xen/include/xen/event.h    |    1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index c73c709..470b8d2 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -32,6 +32,10 @@
>  #include <public/event_channel.h>
>  #include <xsm/xsm.h>
>  
> +/* A bitmap of supported extended event channel ABIs */
> +uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |

This should be just EVTCHN_EXTENDED_NONE until the last
patch that fully implements 3-level event channels.

Jan

> +                                   EVTCHN_EXTENDED_L3);
> +
>  #define ERROR_EXIT(_errno)                                          \
>      do {                                                            \
>          gdprintk(XENLOG_WARNING,                                    \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:48:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:48: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 1UAkAY-0007tP-3R; Wed, 27 Feb 2013 16:47:50 +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 1UAkAW-0007t9-Dy
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:47:48 +0000
Received: from [85.158.143.99:24838] by server-1.bemta-4.messagelabs.com id
	7F/F6-06203-3B83E215; Wed, 27 Feb 2013 16:47:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1361983667!29551103!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9709 invoked from network); 27 Feb 2013 16:47:47 -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 Feb 2013 16:47:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:47:47 +0000
Message-Id: <512E46C002000078000C1A71@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:47:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 12/22] Add supported extended event
 channel ABI bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |    4 ++++
>  xen/include/xen/event.h    |    1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index c73c709..470b8d2 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -32,6 +32,10 @@
>  #include <public/event_channel.h>
>  #include <xsm/xsm.h>
>  
> +/* A bitmap of supported extended event channel ABIs */
> +uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |

This should be just EVTCHN_EXTENDED_NONE until the last
patch that fully implements 3-level event channels.

Jan

> +                                   EVTCHN_EXTENDED_L3);
> +
>  #define ERROR_EXIT(_errno)                                          \
>      do {                                                            \
>          gdprintk(XENLOG_WARNING,                                    \



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:52:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:52: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 1UAkF6-0008Gk-US; Wed, 27 Feb 2013 16:52:32 +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 1UAkF5-0008Gd-LB
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:52:31 +0000
Received: from [85.158.143.99:49348] by server-3.bemta-4.messagelabs.com id
	B0/A1-02186-EC93E215; Wed, 27 Feb 2013 16:52:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361983906!28560455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1667 invoked from network); 27 Feb 2013 16:51:47 -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; 27 Feb 2013 16:51:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:51:46 +0000
Message-Id: <512E47B102000078000C1A74@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:51:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -36,6 +36,20 @@
>  uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
>                                     EVTCHN_EXTENDED_L3);
>  
> +static inline const char * evtchn_abi_str(unsigned int abi)
> +{
> +    switch ( abi )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +        return "2-level";
> +    case EVTCHN_EXTENDED_L3:
> +        return "3-level";
> +    default:
> +        BUG();
> +    }
> +    return ""; /* make compiler happy */
> +}
> +

This is the sort of change that looks completely bogus - even the
next few patches don't seem to make use of this. Why can't this
be added when the first user of it appears? It surely won't make
reviewing that patch more difficult...

And that's a general problem (for me at least) with how you break
up patches: Having looked ahead at 18 and 19, the latter undoes
quite a significant portion of what the former did. Both being far
from huge and unreviewable, why don't you fold them so things
actually make sense to the reader?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:52:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:52: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 1UAkF6-0008Gk-US; Wed, 27 Feb 2013 16:52:32 +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 1UAkF5-0008Gd-LB
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:52:31 +0000
Received: from [85.158.143.99:49348] by server-3.bemta-4.messagelabs.com id
	B0/A1-02186-EC93E215; Wed, 27 Feb 2013 16:52:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1361983906!28560455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1667 invoked from network); 27 Feb 2013 16:51:47 -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; 27 Feb 2013 16:51:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:51:46 +0000
Message-Id: <512E47B102000078000C1A74@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:51:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -36,6 +36,20 @@
>  uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
>                                     EVTCHN_EXTENDED_L3);
>  
> +static inline const char * evtchn_abi_str(unsigned int abi)
> +{
> +    switch ( abi )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +        return "2-level";
> +    case EVTCHN_EXTENDED_L3:
> +        return "3-level";
> +    default:
> +        BUG();
> +    }
> +    return ""; /* make compiler happy */
> +}
> +

This is the sort of change that looks completely bogus - even the
next few patches don't seem to make use of this. Why can't this
be added when the first user of it appears? It surely won't make
reviewing that patch more difficult...

And that's a general problem (for me at least) with how you break
up patches: Having looked ahead at 18 and 19, the latter undoes
quite a significant portion of what the former did. Both being far
from huge and unreviewable, why don't you fold them so things
actually make sense to the reader?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:53:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:53: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 1UAkGL-0008MJ-Ix; Wed, 27 Feb 2013 16:53:49 +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 1UAkGK-0008MC-MH
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:53:48 +0000
Received: from [85.158.139.211:61296] by server-13.bemta-5.messagelabs.com id
	B1/BB-16871-B1A3E215; Wed, 27 Feb 2013 16:53:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361984026!18633641!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12980 invoked from network); 27 Feb 2013 16:53:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 16:53:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:53:46 +0000
Message-Id: <512E482802000078000C1A98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:53:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
 event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/include/asm-arm/types.h
> +++ b/xen/include/asm-arm/types.h
> @@ -41,10 +41,13 @@ typedef char bool_t;
>  #define test_and_clear_bool(b) xchg(&(b), 0)
>  
>  #endif /* __ASSEMBLY__ */
> +#define BYTE_BITORDER  3
> +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
>  
> -#define BITS_PER_LONG 32
> -#define BYTES_PER_LONG 4
> +#define BITS_PER_LONG  (1 << LONG_BITORDER)
>  #define LONG_BYTEORDER 2
> +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)

Is that all really correct and complete in the context of arm64 and
an ABI-long not being 32 bits on arm32?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:53:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:53: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 1UAkGL-0008MJ-Ix; Wed, 27 Feb 2013 16:53:49 +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 1UAkGK-0008MC-MH
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:53:48 +0000
Received: from [85.158.139.211:61296] by server-13.bemta-5.messagelabs.com id
	B1/BB-16871-B1A3E215; Wed, 27 Feb 2013 16:53:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1361984026!18633641!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12980 invoked from network); 27 Feb 2013 16:53:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 16:53:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:53:46 +0000
Message-Id: <512E482802000078000C1A98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:53:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
 event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/include/asm-arm/types.h
> +++ b/xen/include/asm-arm/types.h
> @@ -41,10 +41,13 @@ typedef char bool_t;
>  #define test_and_clear_bool(b) xchg(&(b), 0)
>  
>  #endif /* __ASSEMBLY__ */
> +#define BYTE_BITORDER  3
> +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
>  
> -#define BITS_PER_LONG 32
> -#define BYTES_PER_LONG 4
> +#define BITS_PER_LONG  (1 << LONG_BITORDER)
>  #define LONG_BYTEORDER 2
> +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)

Is that all really correct and complete in the context of arm64 and
an ABI-long not being 32 bits on arm32?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:59:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:59: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 1UAkLD-0000Df-CS; Wed, 27 Feb 2013 16:58:51 +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 1UAkLC-0000DZ-1M
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:58:50 +0000
Received: from [193.109.254.147:19221] by server-14.bemta-14.messagelabs.com
	id 80/19-02031-94B3E215; Wed, 27 Feb 2013 16:58:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361984328!9905164!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6969 invoked from network); 27 Feb 2013 16:58:48 -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; 27 Feb 2013 16:58:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:58:47 +0000
Message-Id: <512E495602000078000C1AA8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:58:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -224,6 +224,8 @@ struct domain
>  
>      unsigned long   *evtchn_pending;
>      unsigned long   *evtchn_mask;
> +    /* Can the domain use extended event channel (new ABI)? */
> +    bool_t           evtchn_extended_allowed;
>  
>      struct grant_table *grant_table;
>  

Please find a better place for this - putting a 1-byte variable
between two pointers adds unnecessary 7-byte padding. And
there's already a bunch of bool_t-s in struct domain...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 16:59:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 16:59: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 1UAkLD-0000Df-CS; Wed, 27 Feb 2013 16:58:51 +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 1UAkLC-0000DZ-1M
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 16:58:50 +0000
Received: from [193.109.254.147:19221] by server-14.bemta-14.messagelabs.com
	id 80/19-02031-94B3E215; Wed, 27 Feb 2013 16:58:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1361984328!9905164!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6969 invoked from network); 27 Feb 2013 16:58:48 -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; 27 Feb 2013 16:58:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 16:58:47 +0000
Message-Id: <512E495602000078000C1AA8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 16:58:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -224,6 +224,8 @@ struct domain
>  
>      unsigned long   *evtchn_pending;
>      unsigned long   *evtchn_mask;
> +    /* Can the domain use extended event channel (new ABI)? */
> +    bool_t           evtchn_extended_allowed;
>  
>      struct grant_table *grant_table;
>  

Please find a better place for this - putting a 1-byte variable
between two pointers adds unnecessary 7-byte padding. And
there's already a bunch of bool_t-s in struct domain...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:01:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17: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 1UAkNs-0000QC-Vm; Wed, 27 Feb 2013 17:01:36 +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 1UAkNr-0000Pe-DJ
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 17:01:35 +0000
Received: from [193.109.254.147:9742] by server-5.bemta-14.messagelabs.com id
	A7/14-21539-EEB3E215; Wed, 27 Feb 2013 17:01:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361984493!9290052!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17712 invoked from network); 27 Feb 2013 17:01:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 17:01:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 17:01:33 +0000
Message-Id: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 17:01:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> Keir, Jan, Ian and David, are you happy with this design in general? I would
> like to have explicit ACK / NACK on this if possible, as feature freeze for 
> 4.3 is quite close now.

The patches look reasonable (apart from the comments I just gave
on some of them), but other than Keir I'm not that eager to see this
one go in for 4.3 in order to then likely be replaced by an
implementation of David's design in the 4.4 cycle.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:01:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17: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 1UAkNs-0000QC-Vm; Wed, 27 Feb 2013 17:01:36 +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 1UAkNr-0000Pe-DJ
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 17:01:35 +0000
Received: from [193.109.254.147:9742] by server-5.bemta-14.messagelabs.com id
	A7/14-21539-EEB3E215; Wed, 27 Feb 2013 17:01:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361984493!9290052!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17712 invoked from network); 27 Feb 2013 17:01:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 17:01:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 27 Feb 2013 17:01:33 +0000
Message-Id: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Wed, 27 Feb 2013 17:01:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> Keir, Jan, Ian and David, are you happy with this design in general? I would
> like to have explicit ACK / NACK on this if possible, as feature freeze for 
> 4.3 is quite close now.

The patches look reasonable (apart from the comments I just gave
on some of them), but other than Keir I'm not that eager to see this
one go in for 4.3 in order to then likely be replaced by an
implementation of David's design in the 4.4 cycle.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:04:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:04: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 1UAkQJ-0000Zx-NL; Wed, 27 Feb 2013 17:04:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1UAkQI-0000Zl-Lp
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 17:04:06 +0000
Received: from [85.158.143.99:8632] by server-3.bemta-4.messagelabs.com id
	83/3C-02186-68C3E215; Wed, 27 Feb 2013 17:04:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361984644!26177764!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20215 invoked from network); 27 Feb 2013 17:04:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 17:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,749,1355097600"; 
   d="scan'208";a="1968718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 17: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.297.1;
	Wed, 27 Feb 2013 17:04:04 +0000
Message-ID: <1361984642.26546.400.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Feb 2013 17:04:02 +0000
In-Reply-To: <512E482802000078000C1A98@nat28.tlf.novell.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
	event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/asm-arm/types.h
> > +++ b/xen/include/asm-arm/types.h
> > @@ -41,10 +41,13 @@ typedef char bool_t;
> >  #define test_and_clear_bool(b) xchg(&(b), 0)
> >  
> >  #endif /* __ASSEMBLY__ */
> > +#define BYTE_BITORDER  3
> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
> >  
> > -#define BITS_PER_LONG 32
> > -#define BYTES_PER_LONG 4
> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
> >  #define LONG_BYTEORDER 2
> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> 
> Is that all really correct and complete in the context of arm64 and
> an ABI-long not being 32 bits on arm32?

This header is about the internal types, I think, and so should
represent the compiler's idea of what the actual long type is for the
benefit of common code.

Of course if these are also being used for ABI things, this is a bug on
ARM. I fixed the use of BITS_PER_LONG in the evtchn interface in a patch
this morning. I couldn't see any others.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:04:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:04: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 1UAkQJ-0000Zx-NL; Wed, 27 Feb 2013 17:04:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1UAkQI-0000Zl-Lp
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 17:04:06 +0000
Received: from [85.158.143.99:8632] by server-3.bemta-4.messagelabs.com id
	83/3C-02186-68C3E215; Wed, 27 Feb 2013 17:04:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361984644!26177764!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20215 invoked from network); 27 Feb 2013 17:04:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 17:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,749,1355097600"; 
   d="scan'208";a="1968718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 17: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.297.1;
	Wed, 27 Feb 2013 17:04:04 +0000
Message-ID: <1361984642.26546.400.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 27 Feb 2013 17:04:02 +0000
In-Reply-To: <512E482802000078000C1A98@nat28.tlf.novell.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
	event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/asm-arm/types.h
> > +++ b/xen/include/asm-arm/types.h
> > @@ -41,10 +41,13 @@ typedef char bool_t;
> >  #define test_and_clear_bool(b) xchg(&(b), 0)
> >  
> >  #endif /* __ASSEMBLY__ */
> > +#define BYTE_BITORDER  3
> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
> >  
> > -#define BITS_PER_LONG 32
> > -#define BYTES_PER_LONG 4
> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
> >  #define LONG_BYTEORDER 2
> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> 
> Is that all really correct and complete in the context of arm64 and
> an ABI-long not being 32 bits on arm32?

This header is about the internal types, I think, and so should
represent the compiler's idea of what the actual long type is for the
benefit of common code.

Of course if these are also being used for ABI things, this is a bug on
ARM. I fixed the use of BITS_PER_LONG in the evtchn interface in a patch
this morning. I couldn't see any others.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:12:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:12: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 1UAkYM-0000wH-2y; Wed, 27 Feb 2013 17:12: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 1UAkYL-0000wC-KC
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 17:12:25 +0000
Received: from [193.109.254.147:55430] by server-2.bemta-14.messagelabs.com id
	7F/B4-16277-97E3E215; Wed, 27 Feb 2013 17:12:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361985144!9291392!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29914 invoked from network); 27 Feb 2013 17:12:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 17:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,749,1355097600"; 
   d="scan'208";a="1969113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 17:12: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.297.1; Wed, 27 Feb 2013 17:12:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAkYJ-0007lz-RL; Wed, 27 Feb 2013 17:12:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAkYJ-0003mp-Mn;
	Wed, 27 Feb 2013 17:12:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20782.15991.578007.837646@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 17:12:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361963955.26546.354.camel@zakaz.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
	<1361963955.26546.354.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>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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 v2] tools: Improve make deb"):
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 27 Feb 2013 11:16:47 +0000
> Subject: [PATCH] build: rename deb target as debball
> 
> "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> target in the comment.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I won't apply it just yet as we're maybe still arguing ...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:12:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:12: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 1UAkYM-0000wH-2y; Wed, 27 Feb 2013 17:12: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 1UAkYL-0000wC-KC
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 17:12:25 +0000
Received: from [193.109.254.147:55430] by server-2.bemta-14.messagelabs.com id
	7F/B4-16277-97E3E215; Wed, 27 Feb 2013 17:12:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1361985144!9291392!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29914 invoked from network); 27 Feb 2013 17:12:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 17:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.84,749,1355097600"; 
   d="scan'208";a="1969113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 17:12: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.297.1; Wed, 27 Feb 2013 17:12:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UAkYJ-0007lz-RL; Wed, 27 Feb 2013 17:12:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UAkYJ-0003mp-Mn;
	Wed, 27 Feb 2013 17:12:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20782.15991.578007.837646@mariner.uk.xensource.com>
Date: Wed, 27 Feb 2013 17:12:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361963955.26546.354.camel@zakaz.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
	<1361963955.26546.354.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>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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 v2] tools: Improve make deb"):
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 27 Feb 2013 11:16:47 +0000
> Subject: [PATCH] build: rename deb target as debball
> 
> "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> target in the comment.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I won't apply it just yet as we're maybe still arguing ...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:17:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:17: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 1UAkdU-000187-Up; Wed, 27 Feb 2013 17:17:44 +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 1UAkdT-000180-EQ
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 17:17:43 +0000
Received: from [85.158.137.99:9066] by server-2.bemta-3.messagelabs.com id
	1A/BE-05208-6BF3E215; Wed, 27 Feb 2013 17:17:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361985461!17028267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30373 invoked from network); 27 Feb 2013 17:17:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 17:17:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAkd8-00036c-OE; Wed, 27 Feb 2013 17:17:22 +0000
Date: Wed, 27 Feb 2013 17:17:22 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130227171722.GB7166@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
	<1361963955.26546.354.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361963955.26546.354.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 11:19 +0000 on 27 Feb (1361963955), Ian Campbell wrote:
> On Tue, 2013-02-26 at 17:57 +0000, Stefano Stabellini wrote:
> > 
> > > I think we can engage in better expectations management.  Perhaps we
> > > could rename the target.
> > 
> > Right, that would be a step forward. Something that make it clear that
> > it isn't a proper deb. 
> 
> 
> 8<------
> 
> From 9ca6f044bae834ec991e7a8c83623344f4701f87 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 27 Feb 2013 11:16:47 +0000
> Subject: [PATCH] build: rename deb target as debball
> 
> "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> target in the comment.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  Makefile |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 2d3ed82..32efb70 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -137,9 +137,11 @@ world:
>  	$(MAKE) kdelete
>  	$(MAKE) dist
>  
> -# Package a build in a .deb file
> -.PHONY: deb
> -deb: dist
> +# Package a build in a debball file, that is inside a .deb format
> +# container to allow for easy and clean removal. This is not intended
> +# to be a full featured policy compliant .deb package.
> +.PHONY: debball
> +debball: dist
>  	fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen xenversion | grep -v :)
>  
>  # clean doesn't do a kclean
> -- 
> 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 Feb 27 17:17:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:17: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 1UAkdU-000187-Up; Wed, 27 Feb 2013 17:17:44 +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 1UAkdT-000180-EQ
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 17:17:43 +0000
Received: from [85.158.137.99:9066] by server-2.bemta-3.messagelabs.com id
	1A/BE-05208-6BF3E215; Wed, 27 Feb 2013 17:17:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1361985461!17028267!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30373 invoked from network); 27 Feb 2013 17:17:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 17:17:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UAkd8-00036c-OE; Wed, 27 Feb 2013 17:17:22 +0000
Date: Wed, 27 Feb 2013 17:17:22 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20130227171722.GB7166@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
	<1361963955.26546.354.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1361963955.26546.354.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] 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

At 11:19 +0000 on 27 Feb (1361963955), Ian Campbell wrote:
> On Tue, 2013-02-26 at 17:57 +0000, Stefano Stabellini wrote:
> > 
> > > I think we can engage in better expectations management.  Perhaps we
> > > could rename the target.
> > 
> > Right, that would be a step forward. Something that make it clear that
> > it isn't a proper deb. 
> 
> 
> 8<------
> 
> From 9ca6f044bae834ec991e7a8c83623344f4701f87 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 27 Feb 2013 11:16:47 +0000
> Subject: [PATCH] build: rename deb target as debball
> 
> "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> target in the comment.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  Makefile |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 2d3ed82..32efb70 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -137,9 +137,11 @@ world:
>  	$(MAKE) kdelete
>  	$(MAKE) dist
>  
> -# Package a build in a .deb file
> -.PHONY: deb
> -deb: dist
> +# Package a build in a debball file, that is inside a .deb format
> +# container to allow for easy and clean removal. This is not intended
> +# to be a full featured policy compliant .deb package.
> +.PHONY: debball
> +debball: dist
>  	fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen xenversion | grep -v :)
>  
>  # clean doesn't do a kclean
> -- 
> 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 Feb 27 17:51:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:51: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 1UAlAI-0001nO-3S; Wed, 27 Feb 2013 17:51:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAlAG-0001nE-8f
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 17:51:36 +0000
Received: from [85.158.143.99:43113] by server-3.bemta-4.messagelabs.com id
	DB/2F-02186-7A74E215; Wed, 27 Feb 2013 17:51:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361987464!24268285!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15897 invoked from network); 27 Feb 2013 17:51:04 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 17:51:04 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51038 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 1UAl7c-0004E4-IT; Wed, 27 Feb 2013 18:48:52 +0100
Date: Wed, 27 Feb 2013 18:50:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1336583579.20130227185059@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512E101802000078000C17FE@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 1:54:31 PM, you wrote:

>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22

> Which is -EINVAL. With nothing else printed, I'm afraid you need to
> find the origin of this return value by instrumenting the involved
> call tree.

Just wondering, is multiple msi's per device actually supported by xen ?

--
Sander

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 17:51:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 17:51: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 1UAlAI-0001nO-3S; Wed, 27 Feb 2013 17:51:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAlAG-0001nE-8f
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 17:51:36 +0000
Received: from [85.158.143.99:43113] by server-3.bemta-4.messagelabs.com id
	DB/2F-02186-7A74E215; Wed, 27 Feb 2013 17:51:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1361987464!24268285!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15897 invoked from network); 27 Feb 2013 17:51:04 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 17:51:04 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51038 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 1UAl7c-0004E4-IT; Wed, 27 Feb 2013 18:48:52 +0100
Date: Wed, 27 Feb 2013 18:50:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1336583579.20130227185059@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512E101802000078000C17FE@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 1:54:31 PM, you wrote:

>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22

> Which is -EINVAL. With nothing else printed, I'm afraid you need to
> find the origin of this return value by instrumenting the involved
> call tree.

Just wondering, is multiple msi's per device actually supported by xen ?

--
Sander

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 18:20:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 18:20: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 1UAlbk-0002Dl-GB; Wed, 27 Feb 2013 18:20:00 +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 1UAlbi-0002Dg-Eu
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 18:19:58 +0000
Received: from [85.158.138.51:49544] by server-2.bemta-3.messagelabs.com id
	63/65-05208-D4E4E215; Wed, 27 Feb 2013 18:19:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361989194!29589325!1
X-Originating-IP: [74.125.82.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8619 invoked from network); 27 Feb 2013 18:19:54 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 18:19:54 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so745730wey.26
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 10:19:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oLhhgcfmgIXkESSpIUjyw9b32ZmaJ/XgXDNV3GmC2b8=;
	b=B9VIJOvgNWvAuQUEM634ifJBNXfK1HdjmrlCyCcp6MmVFT2Hzc+l5efonUTMFHkbjb
	DtpztjwVXRElluYQCEIny3WUrEgtyOJV9yyFIf7IWVbCVpHWLHRmyG7BlBRC9As2vlJC
	2bqHnI6p8dAQ8kTwn9eWcuX9GKAZL1YoBcUATFhzywBSk2bBoonlusdH2bIyvYgmUWE0
	YX2uDmY5I657MnMzTwrJgtAvpiaXdDz3K61/Ecv9ZYMu89nIPxTCoZnn3ednMSnIwniD
	klQg9NcfGs/NShvTRCsL1pHe9dGw2FpwZU2xZAQntjqkWpaKNSn6IhlOZebm7CbjCPpy
	aabA==
X-Received: by 10.194.93.97 with SMTP id ct1mr5615265wjb.48.1361989194488;
	Wed, 27 Feb 2013 10:19:54 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id bj9sm28857218wib.4.2013.02.27.10.19.50
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 10:19:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 18:19:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD53FEC4.4CD47%keir.xen@gmail.com>
Thread-Topic: [PATCH] coverage: fix on ARM
Thread-Index: Ac4VFwahQqiK4CIjg0CEzl+awX7NPQ==
In-Reply-To: <1361971036.26546.377.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 13:17, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
>> Use a list of pointers to simplify the handling of 32- vs 64-bit.
>> 
>> Also on ARM the section name is ".init_array" and not ".ctors".
> 
> Any comments/ack/nacks?

If it works, it's good by me ;)

 -- Keir

>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
>> Cc: keir@xen.org
>> ---
>> This applies independently of my 64-bit ARM series.
>> ---
>>  xen/arch/arm/xen.lds.S |   10 ++++------
>>  xen/arch/x86/xen.lds.S |    6 ++----
>>  xen/common/lib.c       |   13 +++++--------
>>  3 files changed, 11 insertions(+), 18 deletions(-)
>> 
>> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
>> index 9043994..fd755d7 100644
>> --- a/xen/arch/arm/xen.lds.S
>> +++ b/xen/arch/arm/xen.lds.S
>> @@ -91,12 +91,10 @@ SECTIONS
>>         *(.init.data.rel)
>>         *(.init.data.rel.*)
>>  
>> -       . = ALIGN(4);
>> -       __CTOR_LIST__ = .;
>> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
>> -       *(.ctors)
>> -       LONG(0)
>> -       __CTOR_END__ = .;
>> +       . = ALIGN(8);
>> +       __ctors_start = .;
>> +       *(.init_array)
>> +       __ctors_end = .;
>>    } :text
>>    . = ALIGN(32);
>>    .init.setup : {
>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>> index 5570389..d959941 100644
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -110,11 +110,9 @@ SECTIONS
>>         __trampoline_seg_stop = .;
>>  
>>         . = ALIGN(8);
>> -       __CTOR_LIST__ = .;
>> -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
>> +       __ctors_start = .;
>>         *(.ctors)
>> -       QUAD(0)
>> -       __CTOR_END__ = .;
>> +       __ctors_end = .;
>>    } :text
>>    . = ALIGN(32);
>>    .init.setup : {
>> diff --git a/xen/common/lib.c b/xen/common/lib.c
>> index e0c65cf..6b80601 100644
>> --- a/xen/common/lib.c
>> +++ b/xen/common/lib.c
>> @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s,
>> const char **ps)
>>      return ret;
>>  }
>>  
>> -extern const struct
>> -{
>> -    unsigned long count;
>> -    void (*funcs[1])(void);
>> -} __CTOR_LIST__;
>> +typedef void (*ctor_func_t)(void);
>> +extern const ctor_func_t __ctors_start[], __ctors_end[];
>>  
>>  void __init init_constructors(void)
>>  {
>> -    unsigned long n;
>> -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
>> -        __CTOR_LIST__.funcs[n]();
>> +    const ctor_func_t *f;
>> +    for (f = __ctors_start; f < __ctors_end; ++f )
>> +        (*f)();
>>  }
>>  
>>  /*
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 18:20:28 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 18:20: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 1UAlbk-0002Dl-GB; Wed, 27 Feb 2013 18:20:00 +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 1UAlbi-0002Dg-Eu
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 18:19:58 +0000
Received: from [85.158.138.51:49544] by server-2.bemta-3.messagelabs.com id
	63/65-05208-D4E4E215; Wed, 27 Feb 2013 18:19:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1361989194!29589325!1
X-Originating-IP: [74.125.82.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8619 invoked from network); 27 Feb 2013 18:19:54 -0000
Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com)
	(74.125.82.181)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 18:19:54 -0000
Received: by mail-we0-f181.google.com with SMTP id t44so745730wey.26
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 10:19:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=oLhhgcfmgIXkESSpIUjyw9b32ZmaJ/XgXDNV3GmC2b8=;
	b=B9VIJOvgNWvAuQUEM634ifJBNXfK1HdjmrlCyCcp6MmVFT2Hzc+l5efonUTMFHkbjb
	DtpztjwVXRElluYQCEIny3WUrEgtyOJV9yyFIf7IWVbCVpHWLHRmyG7BlBRC9As2vlJC
	2bqHnI6p8dAQ8kTwn9eWcuX9GKAZL1YoBcUATFhzywBSk2bBoonlusdH2bIyvYgmUWE0
	YX2uDmY5I657MnMzTwrJgtAvpiaXdDz3K61/Ecv9ZYMu89nIPxTCoZnn3ednMSnIwniD
	klQg9NcfGs/NShvTRCsL1pHe9dGw2FpwZU2xZAQntjqkWpaKNSn6IhlOZebm7CbjCPpy
	aabA==
X-Received: by 10.194.93.97 with SMTP id ct1mr5615265wjb.48.1361989194488;
	Wed, 27 Feb 2013 10:19:54 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id bj9sm28857218wib.4.2013.02.27.10.19.50
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 10:19:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 18:19:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CD53FEC4.4CD47%keir.xen@gmail.com>
Thread-Topic: [PATCH] coverage: fix on ARM
Thread-Index: Ac4VFwahQqiK4CIjg0CEzl+awX7NPQ==
In-Reply-To: <1361971036.26546.377.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/2013 13:17, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
>> Use a list of pointers to simplify the handling of 32- vs 64-bit.
>> 
>> Also on ARM the section name is ".init_array" and not ".ctors".
> 
> Any comments/ack/nacks?

If it works, it's good by me ;)

 -- Keir

>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
>> Cc: keir@xen.org
>> ---
>> This applies independently of my 64-bit ARM series.
>> ---
>>  xen/arch/arm/xen.lds.S |   10 ++++------
>>  xen/arch/x86/xen.lds.S |    6 ++----
>>  xen/common/lib.c       |   13 +++++--------
>>  3 files changed, 11 insertions(+), 18 deletions(-)
>> 
>> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
>> index 9043994..fd755d7 100644
>> --- a/xen/arch/arm/xen.lds.S
>> +++ b/xen/arch/arm/xen.lds.S
>> @@ -91,12 +91,10 @@ SECTIONS
>>         *(.init.data.rel)
>>         *(.init.data.rel.*)
>>  
>> -       . = ALIGN(4);
>> -       __CTOR_LIST__ = .;
>> -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
>> -       *(.ctors)
>> -       LONG(0)
>> -       __CTOR_END__ = .;
>> +       . = ALIGN(8);
>> +       __ctors_start = .;
>> +       *(.init_array)
>> +       __ctors_end = .;
>>    } :text
>>    . = ALIGN(32);
>>    .init.setup : {
>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>> index 5570389..d959941 100644
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -110,11 +110,9 @@ SECTIONS
>>         __trampoline_seg_stop = .;
>>  
>>         . = ALIGN(8);
>> -       __CTOR_LIST__ = .;
>> -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
>> +       __ctors_start = .;
>>         *(.ctors)
>> -       QUAD(0)
>> -       __CTOR_END__ = .;
>> +       __ctors_end = .;
>>    } :text
>>    . = ALIGN(32);
>>    .init.setup : {
>> diff --git a/xen/common/lib.c b/xen/common/lib.c
>> index e0c65cf..6b80601 100644
>> --- a/xen/common/lib.c
>> +++ b/xen/common/lib.c
>> @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s,
>> const char **ps)
>>      return ret;
>>  }
>>  
>> -extern const struct
>> -{
>> -    unsigned long count;
>> -    void (*funcs[1])(void);
>> -} __CTOR_LIST__;
>> +typedef void (*ctor_func_t)(void);
>> +extern const ctor_func_t __ctors_start[], __ctors_end[];
>>  
>>  void __init init_constructors(void)
>>  {
>> -    unsigned long n;
>> -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
>> -        __CTOR_LIST__.funcs[n]();
>> +    const ctor_func_t *f;
>> +    for (f = __ctors_start; f < __ctors_end; ++f )
>> +        (*f)();
>>  }
>>  
>>  /*
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 18:44:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 18:44: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 1UAlzR-0002fv-NQ; Wed, 27 Feb 2013 18:44:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAlzQ-0002fq-No
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 18:44:28 +0000
Received: from [85.158.143.99:29203] by server-1.bemta-4.messagelabs.com id
	C3/32-06203-B045E215; Wed, 27 Feb 2013 18:44:27 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361990667!26190297!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32359 invoked from network); 27 Feb 2013 18:44:27 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 18:44:27 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 05939C56194;
	Wed, 27 Feb 2013 18:44:15 +0000 (GMT)
Date: Wed, 27 Feb 2013 18:44:15 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Message-ID: <6C6293A03011B5A6516EBD48@Ximines.local>
In-Reply-To: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote:

> Aiming at a release towards the end of March, I'd like to cut RC1-s
> at the beginning of next week.

I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
a blktrace.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 18:44:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 18:44: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 1UAlzR-0002fv-NQ; Wed, 27 Feb 2013 18:44:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAlzQ-0002fq-No
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 18:44:28 +0000
Received: from [85.158.143.99:29203] by server-1.bemta-4.messagelabs.com id
	C3/32-06203-B045E215; Wed, 27 Feb 2013 18:44:27 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-7.tower-216.messagelabs.com!1361990667!26190297!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32359 invoked from network); 27 Feb 2013 18:44:27 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-7.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 18:44:27 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 05939C56194;
	Wed, 27 Feb 2013 18:44:15 +0000 (GMT)
Date: Wed, 27 Feb 2013 18:44:15 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Message-ID: <6C6293A03011B5A6516EBD48@Ximines.local>
In-Reply-To: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote:

> Aiming at a release towards the end of March, I'd like to cut RC1-s
> at the beginning of next week.

I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
a blktrace.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 19:01:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19:01: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 1UAmFM-0002xp-Ap; Wed, 27 Feb 2013 19:00: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 1UAmFK-0002xk-VK
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:00:55 +0000
Received: from [193.109.254.147:14835] by server-13.bemta-14.messagelabs.com
	id 43/9E-30639-6E75E215; Wed, 27 Feb 2013 19:00:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361991624!2224149!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6962 invoked from network); 27 Feb 2013 19:00:25 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 19:00:25 -0000
Received: by mail-wi0-f181.google.com with SMTP id hm6so1126801wib.2
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 11:00:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=jxhDPyrJeCXJ6LYcoEbhwBBv71tHH3rTu4NWY+1Qjf8=;
	b=dS7crqs+hynJbtcniyVIXdI/KYVYEEIj+AzGzFgrUmb0J/S3XbzvvH+8e3z1bqsQcV
	fD51apXN1fXUV/wynypmxFKa8jhRGemF5BlZolYnTI2PD3Vz4UKoslrwY0YQxMAPv9MK
	1xUUrhRQU8VZr82ijcfj6eUCHxJDznWDI/h22nkZCh5raBA1N57FekrkuYrG2OJTf4E5
	79peLHhgVxybw80KfkWzV47ZdayBVZmBIEpUKMhXlm4eqGlM3NRWQVB4MpnHB4g+p+jS
	7IXqDnrJYtXsD+8HqxcrN72hmPuNcgyeqywWhcfIQswX6d55bK565f/sZumGYv8KuOn6
	hiUw==
MIME-Version: 1.0
X-Received: by 10.180.78.35 with SMTP id y3mr5976662wiw.22.1361991623939; Wed,
	27 Feb 2013 11:00:23 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 11:00:23 -0800 (PST)
In-Reply-To: <7b30913e753c4f0a2396.1359716474@Solace>
References: <patchbomb.1359716470@Solace>
	<7b30913e753c4f0a2396.1359716474@Solace>
Date: Wed, 27 Feb 2013 19:00:23 +0000
X-Google-Sender-Auth: kwt09MBVynEH5Y07UDXpAZ-hmeI
Message-ID: <CAFLBxZaoZoAHi-CLwWbiWr9xJO410UxO=JkTi=OgJdoOxckyMQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 04 of 11 v3] xen: 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="===============4290388516933556992=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4290388516933556992==
Content-Type: multipart/alternative; boundary=f46d043c7b84eea18004d6b9623c

--f46d043c7b84eea18004d6b9623c
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> As vcpu-affinity tells where VCPUs must run, node-affinity tells
> where they should or, better, prefer. While respecting vcpu-affinity
> remains mandatory, node-affinity is not that strict, it only expresses
> a preference, although honouring it is almost always true that will
> bring significant performances benefit (especially as compared to
> not having any affinity at all).
>
> This change modifies the VCPU load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferable
> for the domain to run. If that fails in finding a valid PCPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>

OK, sorry it took so long.  This looks a lot better just a couple of
comments below.


> +
> +/*
> + * vcpu-affinity balancing is always necessary and must never be skipped.
> + * OTOH, if a domain has affinity with all the nodes, we can tell the
> caller
> + * that he can safely skip the node-affinity balancing step.
> + */
> +#define __vcpu_has_valuable_node_affinity(vc) \
> +    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
>

Something about the name of this one just doesn't strike me right.  I might
be tempted just to go with "__vcpu_has_node_affinity", and let the comment
above it explain what it means for the curious.


> +
> +static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
> +{
> +    if ( step == CSCHED_BALANCE_NODE_AFFINITY
> +         && !__vcpu_has_valuable_node_affinity(vc) )
> +        return 1;
> +    return 0;
> +}
>

I'm not a fan of this kind of encapsulation, but I'll let it be I guess.
You missed a place to use it however -- in csched_runq_steal() you have the
if() statement.

(I prefer just having the duplicated if statements, as I think it's easier
to read; but you should go all one way or the other.)

>
>
> @@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,
>              if ( speer->pri <= pri )
>                  break;
>
> -            /* Is this VCPU is runnable on our PCPU? */
> +            /* Is this VCPU runnable on our PCPU? */
>              vc = speer->vcpu;
>              BUG_ON( is_idle_vcpu(vc) );
>
> -            if (__csched_vcpu_is_migrateable(vc, cpu))
> +            /*
> +             * If the vcpu has no valuable node-affinity, skip this vcpu.
> +             * In fact, what we want is to check if we have any
> node-affine
> +             * work to steal, before starting to look at vcpu-affine work.
> +             */
> +            if ( balance_step == CSCHED_BALANCE_NODE_AFFINITY
> +                 && !__vcpu_has_valuable_node_affinity(vc) )
> +                continue;
>

This is where you missed the "csched_balance_step_skippable" replacement.

Just an observation -- I think this will penalize systems that do not have
node affinity enabled, in that if no one is using node affinities, then
what will happen is the load balancing code will go through and check each
vcpu on each processor, determine that there are no node affinities, and
then go through again looking at vcpu affinities.  Going through twice for
a single vcpu when doing placement is probably OK; but going all the way
through all vcpus once could be pretty expensive.

I think we should take this patch now (with the other minor changes
mentioned above) so we can get it tested properly.  But we should probably
try to do something to address this issue before the release -- maybe
something like keeping a bitmask for each runqueue, saying whether any
vcpus running on them have node affinity?  That way the first round we'll
only check runqueues where we might conceivably steal something.

Other than that, looks good -- thanks for the good work.

 -George

--f46d043c7b84eea18004d6b9623c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank"=
>dario.faggioli@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">As vcpu-affinity tells where VCPUs must run,=
 node-affinity tells<br>
where they should or, better, prefer. While respecting vcpu-affinity<br>
remains mandatory, node-affinity is not that strict, it only expresses<br>
a preference, although honouring it is almost always true that will<br>
bring significant performances benefit (especially as compared to<br>
not having any affinity at all).<br>
<br>
This change modifies the VCPU load balancing algorithm (for the<br>
credit scheduler only), introducing a two steps logic.<br>
During the first step, we use the node-affinity mask. The aim is<br>
giving precedence to the CPUs where it is known to be preferable<br>
for the domain to run. If that fails in finding a valid PCPU, the<br>
node-affinity is just ignored and, in the second step, we fall<br>
back to using cpu-affinity only.<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br></blockquote><div><br></div><div>O=
K, sorry it took so long.=A0 This looks a lot better just a couple of comme=
nts below.<br>
</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>
+/*<br>
+ * vcpu-affinity balancing is always necessary and must never be skipped.<=
br>
+ * OTOH, if a domain has affinity with all the nodes, we can tell the call=
er<br>
+ * that he can safely skip the node-affinity balancing step.<br>
+ */<br>
+#define __vcpu_has_valuable_node_affinity(vc) \<br>
+ =A0 =A0( !cpumask_full(CSCHED_DOM(vc-&gt;domain)-&gt;node_affinity_cpumas=
k) )<br></blockquote><div><br></div><div>Something about the name of this o=
ne just doesn&#39;t strike me right.=A0 I might be tempted just to go with =
&quot;__vcpu_has_node_affinity&quot;, and let the comment above it explain =
what it means for the curious.<br>
</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>
+static inline int csched_balance_step_skippable(int step, struct vcpu *vc)=
<br>
+{<br>
+ =A0 =A0if ( step =3D=3D CSCHED_BALANCE_NODE_AFFINITY<br>
+ =A0 =A0 =A0 =A0 &amp;&amp; !__vcpu_has_valuable_node_affinity(vc) )<br>
+ =A0 =A0 =A0 =A0return 1;<br>
+ =A0 =A0return 0;<br>
+}<br></blockquote><div><br></div>I&#39;m not a fan of this kind of encapsu=
lation, but I&#39;ll let it be I guess.=A0 You missed a place to use it how=
ever -- in csched_runq_steal() you have the if() statement.<br><br></div>
<div class=3D"gmail_quote">(I prefer just having the duplicated if statemen=
ts, as I think it&#39;s easier to read; but you should go all one way or th=
e other.)<br></div><div class=3D"gmail_quote">=A0<blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<br>
@@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0if ( speer-&gt;pri &lt;=3D pri )<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;<br>
<br>
- =A0 =A0 =A0 =A0 =A0 =A0/* Is this VCPU is runnable on our PCPU? */<br>
+ =A0 =A0 =A0 =A0 =A0 =A0/* Is this VCPU runnable on our PCPU? */<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0vc =3D speer-&gt;vcpu;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON( is_idle_vcpu(vc) );<br>
<br>
- =A0 =A0 =A0 =A0 =A0 =A0if (__csched_vcpu_is_migrateable(vc, cpu))<br>
+ =A0 =A0 =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 * If the vcpu has no valuable node-affinity, skip=
 this vcpu.<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 * In fact, what we want is to check if we have an=
y node-affine<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 * work to steal, before starting to look at vcpu-=
affine work.<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( balance_step =3D=3D CSCHED_BALANCE_NODE_AFFIN=
ITY<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;&amp; !__vcpu_has_valuable_node_affi=
nity(vc) )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;<br></blockquote><div><br></div><=
div>This is where you missed the &quot;csched_balance_step_skippable&quot; =
replacement.<br><br></div><div>Just an observation -- I think this will pen=
alize systems that do not have node affinity enabled, in that if no one is =
using node affinities, then what will happen is the load balancing code wil=
l go through and check each vcpu on each processor, determine that there ar=
e no node affinities, and then go through again looking at vcpu affinities.=
=A0 Going through twice for a single vcpu when doing placement is probably =
OK; but going all the way through all vcpus once could be pretty expensive.=
<br>
<br></div><div>I think we should take this patch now (with the other minor =
changes mentioned above) so we can get it tested properly.=A0 But we should=
 probably try to do something to address this issue before the release -- m=
aybe something like keeping a bitmask for each runqueue, saying whether any=
 vcpus running on them have node affinity?=A0 That way the first round we&#=
39;ll only check runqueues where we might conceivably steal something.</div=
>
<br></div>Other than that, looks good -- thanks for the good work.<br><br><=
/div><div class=3D"gmail_extra">=A0-George<br></div></div>

--f46d043c7b84eea18004d6b9623c--


--===============4290388516933556992==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4290388516933556992==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 19:01:20 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19:01: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 1UAmFM-0002xp-Ap; Wed, 27 Feb 2013 19:00: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 1UAmFK-0002xk-VK
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:00:55 +0000
Received: from [193.109.254.147:14835] by server-13.bemta-14.messagelabs.com
	id 43/9E-30639-6E75E215; Wed, 27 Feb 2013 19:00:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1361991624!2224149!1
X-Originating-IP: [209.85.212.181]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6962 invoked from network); 27 Feb 2013 19:00:25 -0000
Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com)
	(209.85.212.181)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 19:00:25 -0000
Received: by mail-wi0-f181.google.com with SMTP id hm6so1126801wib.2
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 11:00:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=jxhDPyrJeCXJ6LYcoEbhwBBv71tHH3rTu4NWY+1Qjf8=;
	b=dS7crqs+hynJbtcniyVIXdI/KYVYEEIj+AzGzFgrUmb0J/S3XbzvvH+8e3z1bqsQcV
	fD51apXN1fXUV/wynypmxFKa8jhRGemF5BlZolYnTI2PD3Vz4UKoslrwY0YQxMAPv9MK
	1xUUrhRQU8VZr82ijcfj6eUCHxJDznWDI/h22nkZCh5raBA1N57FekrkuYrG2OJTf4E5
	79peLHhgVxybw80KfkWzV47ZdayBVZmBIEpUKMhXlm4eqGlM3NRWQVB4MpnHB4g+p+jS
	7IXqDnrJYtXsD+8HqxcrN72hmPuNcgyeqywWhcfIQswX6d55bK565f/sZumGYv8KuOn6
	hiUw==
MIME-Version: 1.0
X-Received: by 10.180.78.35 with SMTP id y3mr5976662wiw.22.1361991623939; Wed,
	27 Feb 2013 11:00:23 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Wed, 27 Feb 2013 11:00:23 -0800 (PST)
In-Reply-To: <7b30913e753c4f0a2396.1359716474@Solace>
References: <patchbomb.1359716470@Solace>
	<7b30913e753c4f0a2396.1359716474@Solace>
Date: Wed, 27 Feb 2013 19:00:23 +0000
X-Google-Sender-Auth: kwt09MBVynEH5Y07UDXpAZ-hmeI
Message-ID: <CAFLBxZaoZoAHi-CLwWbiWr9xJO410UxO=JkTi=OgJdoOxckyMQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 04 of 11 v3] xen: 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="===============4290388516933556992=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4290388516933556992==
Content-Type: multipart/alternative; boundary=f46d043c7b84eea18004d6b9623c

--f46d043c7b84eea18004d6b9623c
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> As vcpu-affinity tells where VCPUs must run, node-affinity tells
> where they should or, better, prefer. While respecting vcpu-affinity
> remains mandatory, node-affinity is not that strict, it only expresses
> a preference, although honouring it is almost always true that will
> bring significant performances benefit (especially as compared to
> not having any affinity at all).
>
> This change modifies the VCPU load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferable
> for the domain to run. If that fails in finding a valid PCPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>

OK, sorry it took so long.  This looks a lot better just a couple of
comments below.


> +
> +/*
> + * vcpu-affinity balancing is always necessary and must never be skipped.
> + * OTOH, if a domain has affinity with all the nodes, we can tell the
> caller
> + * that he can safely skip the node-affinity balancing step.
> + */
> +#define __vcpu_has_valuable_node_affinity(vc) \
> +    ( !cpumask_full(CSCHED_DOM(vc->domain)->node_affinity_cpumask) )
>

Something about the name of this one just doesn't strike me right.  I might
be tempted just to go with "__vcpu_has_node_affinity", and let the comment
above it explain what it means for the curious.


> +
> +static inline int csched_balance_step_skippable(int step, struct vcpu *vc)
> +{
> +    if ( step == CSCHED_BALANCE_NODE_AFFINITY
> +         && !__vcpu_has_valuable_node_affinity(vc) )
> +        return 1;
> +    return 0;
> +}
>

I'm not a fan of this kind of encapsulation, but I'll let it be I guess.
You missed a place to use it however -- in csched_runq_steal() you have the
if() statement.

(I prefer just having the duplicated if statements, as I think it's easier
to read; but you should go all one way or the other.)

>
>
> @@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,
>              if ( speer->pri <= pri )
>                  break;
>
> -            /* Is this VCPU is runnable on our PCPU? */
> +            /* Is this VCPU runnable on our PCPU? */
>              vc = speer->vcpu;
>              BUG_ON( is_idle_vcpu(vc) );
>
> -            if (__csched_vcpu_is_migrateable(vc, cpu))
> +            /*
> +             * If the vcpu has no valuable node-affinity, skip this vcpu.
> +             * In fact, what we want is to check if we have any
> node-affine
> +             * work to steal, before starting to look at vcpu-affine work.
> +             */
> +            if ( balance_step == CSCHED_BALANCE_NODE_AFFINITY
> +                 && !__vcpu_has_valuable_node_affinity(vc) )
> +                continue;
>

This is where you missed the "csched_balance_step_skippable" replacement.

Just an observation -- I think this will penalize systems that do not have
node affinity enabled, in that if no one is using node affinities, then
what will happen is the load balancing code will go through and check each
vcpu on each processor, determine that there are no node affinities, and
then go through again looking at vcpu affinities.  Going through twice for
a single vcpu when doing placement is probably OK; but going all the way
through all vcpus once could be pretty expensive.

I think we should take this patch now (with the other minor changes
mentioned above) so we can get it tested properly.  But we should probably
try to do something to address this issue before the release -- maybe
something like keeping a bitmask for each runqueue, saying whether any
vcpus running on them have node affinity?  That way the first round we'll
only check runqueues where we might conceivably steal something.

Other than that, looks good -- thanks for the good work.

 -George

--f46d043c7b84eea18004d6b9623c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank"=
>dario.faggioli@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">As vcpu-affinity tells where VCPUs must run,=
 node-affinity tells<br>
where they should or, better, prefer. While respecting vcpu-affinity<br>
remains mandatory, node-affinity is not that strict, it only expresses<br>
a preference, although honouring it is almost always true that will<br>
bring significant performances benefit (especially as compared to<br>
not having any affinity at all).<br>
<br>
This change modifies the VCPU load balancing algorithm (for the<br>
credit scheduler only), introducing a two steps logic.<br>
During the first step, we use the node-affinity mask. The aim is<br>
giving precedence to the CPUs where it is known to be preferable<br>
for the domain to run. If that fails in finding a valid PCPU, the<br>
node-affinity is just ignored and, in the second step, we fall<br>
back to using cpu-affinity only.<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br></blockquote><div><br></div><div>O=
K, sorry it took so long.=A0 This looks a lot better just a couple of comme=
nts below.<br>
</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>
+/*<br>
+ * vcpu-affinity balancing is always necessary and must never be skipped.<=
br>
+ * OTOH, if a domain has affinity with all the nodes, we can tell the call=
er<br>
+ * that he can safely skip the node-affinity balancing step.<br>
+ */<br>
+#define __vcpu_has_valuable_node_affinity(vc) \<br>
+ =A0 =A0( !cpumask_full(CSCHED_DOM(vc-&gt;domain)-&gt;node_affinity_cpumas=
k) )<br></blockquote><div><br></div><div>Something about the name of this o=
ne just doesn&#39;t strike me right.=A0 I might be tempted just to go with =
&quot;__vcpu_has_node_affinity&quot;, and let the comment above it explain =
what it means for the curious.<br>
</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>
+static inline int csched_balance_step_skippable(int step, struct vcpu *vc)=
<br>
+{<br>
+ =A0 =A0if ( step =3D=3D CSCHED_BALANCE_NODE_AFFINITY<br>
+ =A0 =A0 =A0 =A0 &amp;&amp; !__vcpu_has_valuable_node_affinity(vc) )<br>
+ =A0 =A0 =A0 =A0return 1;<br>
+ =A0 =A0return 0;<br>
+}<br></blockquote><div><br></div>I&#39;m not a fan of this kind of encapsu=
lation, but I&#39;ll let it be I guess.=A0 You missed a place to use it how=
ever -- in csched_runq_steal() you have the if() statement.<br><br></div>
<div class=3D"gmail_quote">(I prefer just having the duplicated if statemen=
ts, as I think it&#39;s easier to read; but you should go all one way or th=
e other.)<br></div><div class=3D"gmail_quote">=A0<blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<br>
@@ -1277,11 +1391,21 @@ csched_runq_steal(int peer_cpu, int cpu,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0if ( speer-&gt;pri &lt;=3D pri )<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;<br>
<br>
- =A0 =A0 =A0 =A0 =A0 =A0/* Is this VCPU is runnable on our PCPU? */<br>
+ =A0 =A0 =A0 =A0 =A0 =A0/* Is this VCPU runnable on our PCPU? */<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0vc =3D speer-&gt;vcpu;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0BUG_ON( is_idle_vcpu(vc) );<br>
<br>
- =A0 =A0 =A0 =A0 =A0 =A0if (__csched_vcpu_is_migrateable(vc, cpu))<br>
+ =A0 =A0 =A0 =A0 =A0 =A0/*<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 * If the vcpu has no valuable node-affinity, skip=
 this vcpu.<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 * In fact, what we want is to check if we have an=
y node-affine<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 * work to steal, before starting to look at vcpu-=
affine work.<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 */<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( balance_step =3D=3D CSCHED_BALANCE_NODE_AFFIN=
ITY<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;&amp; !__vcpu_has_valuable_node_affi=
nity(vc) )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue;<br></blockquote><div><br></div><=
div>This is where you missed the &quot;csched_balance_step_skippable&quot; =
replacement.<br><br></div><div>Just an observation -- I think this will pen=
alize systems that do not have node affinity enabled, in that if no one is =
using node affinities, then what will happen is the load balancing code wil=
l go through and check each vcpu on each processor, determine that there ar=
e no node affinities, and then go through again looking at vcpu affinities.=
=A0 Going through twice for a single vcpu when doing placement is probably =
OK; but going all the way through all vcpus once could be pretty expensive.=
<br>
<br></div><div>I think we should take this patch now (with the other minor =
changes mentioned above) so we can get it tested properly.=A0 But we should=
 probably try to do something to address this issue before the release -- m=
aybe something like keeping a bitmask for each runqueue, saying whether any=
 vcpus running on them have node affinity?=A0 That way the first round we&#=
39;ll only check runqueues where we might conceivably steal something.</div=
>
<br></div>Other than that, looks good -- thanks for the good work.<br><br><=
/div><div class=3D"gmail_extra">=A0-George<br></div></div>

--f46d043c7b84eea18004d6b9623c--


--===============4290388516933556992==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4290388516933556992==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 19:28:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19: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 1UAmfv-0003Pg-MU; Wed, 27 Feb 2013 19:28: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 1UAmft-0003Pb-PP
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:28:21 +0000
Received: from [85.158.139.83:9314] by server-14.bemta-5.messagelabs.com id
	46/1C-13158-55E5E215; Wed, 27 Feb 2013 19:28:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361993299!29545641!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjMyMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20973 invoked from network); 27 Feb 2013 19:28:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 19:28:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RJSEgh016492
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 19:28:15 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
	r1RJSCnS028436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 19:28:13 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
	r1RJSCaS015688; Wed, 27 Feb 2013 13:28:12 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 11:28:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F2F7D1C3935; Wed, 27 Feb 2013 14:28:10 -0500 (EST)
Date: Wed, 27 Feb 2013 14:28:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130227192810.GA30169@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1336583579.20130227185059@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
> 
> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> 
> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
> > find the origin of this return value by instrumenting the involved
> > call tree.
> 
> Just wondering, is multiple msi's per device actually supported by xen ?

That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
use them and they work great with Xen.

BTW, this is merge:
ommit 5800700f66678ea5c85e7d62b138416070bf7f60
Merge: 266d7ad af8d102
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Feb 19 19:07:27 2013 -0800

    Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    
    Pull x86/apic changes from Ingo Molnar:
     "Main changes:
    
       - Multiple MSI support added to the APIC, PCI and AHCI code - acked
         by all relevant maintainers, by Alexander Gordeev.
    
         The advantage is that multiple AHCI ports can have multiple MSI
         irqs assigned, and can thus spread to multiple CPUs.
    
         [ Drivers can make use of this new facility via the
           pci_enable_msi_block_auto() method ]



With MSI per device, the hypercall that ends up happening is:
PHYSDEVOP_map_pirq with:

   map_irq.domid = domid;
   map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
   map_irq.index = -1;
   map_irq.pirq = -1;
   map_irq.bus = dev->bus->number |
                 (pci_domain_nr(dev->bus) << 16);
   map_irq.devfn = dev->devfn;

Which would imply that we are doing this call multiple times?
(This is xen_initdom_setup_msi_irqs).

It looks like pci_enable_msi_block_auto is the multiple MSI one
and it should perculate down to xen_initdom_setup_msi_irqs.
Granted the xen_init.. does not do anything with the 'nvec' call.

So could I ask you try out your hunch by doing three things:
 1). Instrument xen_initdom_setup_msi_irqs to see if the
     nvec has anything but 1 and in its loop instrument to
     see if it has more than on MSI attribute?

 2). The ahci driver has ahci_init_interrupts which only does
   the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
    If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
    to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
    seperatly from 1).
 3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
    and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab? 
> 
> --
> Sander
> 
> > 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 Feb 27 19:28:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19: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 1UAmfv-0003Pg-MU; Wed, 27 Feb 2013 19:28: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 1UAmft-0003Pb-PP
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:28:21 +0000
Received: from [85.158.139.83:9314] by server-14.bemta-5.messagelabs.com id
	46/1C-13158-55E5E215; Wed, 27 Feb 2013 19:28:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1361993299!29545641!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjMyMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20973 invoked from network); 27 Feb 2013 19:28:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 19:28:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RJSEgh016492
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 19:28:15 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
	r1RJSCnS028436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 19:28:13 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
	r1RJSCaS015688; Wed, 27 Feb 2013 13:28:12 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 11:28:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F2F7D1C3935; Wed, 27 Feb 2013 14:28:10 -0500 (EST)
Date: Wed, 27 Feb 2013 14:28:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130227192810.GA30169@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1336583579.20130227185059@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
> 
> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> 
> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
> > find the origin of this return value by instrumenting the involved
> > call tree.
> 
> Just wondering, is multiple msi's per device actually supported by xen ?

That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
use them and they work great with Xen.

BTW, this is merge:
ommit 5800700f66678ea5c85e7d62b138416070bf7f60
Merge: 266d7ad af8d102
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Feb 19 19:07:27 2013 -0800

    Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    
    Pull x86/apic changes from Ingo Molnar:
     "Main changes:
    
       - Multiple MSI support added to the APIC, PCI and AHCI code - acked
         by all relevant maintainers, by Alexander Gordeev.
    
         The advantage is that multiple AHCI ports can have multiple MSI
         irqs assigned, and can thus spread to multiple CPUs.
    
         [ Drivers can make use of this new facility via the
           pci_enable_msi_block_auto() method ]



With MSI per device, the hypercall that ends up happening is:
PHYSDEVOP_map_pirq with:

   map_irq.domid = domid;
   map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
   map_irq.index = -1;
   map_irq.pirq = -1;
   map_irq.bus = dev->bus->number |
                 (pci_domain_nr(dev->bus) << 16);
   map_irq.devfn = dev->devfn;

Which would imply that we are doing this call multiple times?
(This is xen_initdom_setup_msi_irqs).

It looks like pci_enable_msi_block_auto is the multiple MSI one
and it should perculate down to xen_initdom_setup_msi_irqs.
Granted the xen_init.. does not do anything with the 'nvec' call.

So could I ask you try out your hunch by doing three things:
 1). Instrument xen_initdom_setup_msi_irqs to see if the
     nvec has anything but 1 and in its loop instrument to
     see if it has more than on MSI attribute?

 2). The ahci driver has ahci_init_interrupts which only does
   the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
    If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
    to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
    seperatly from 1).
 3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
    and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab? 
> 
> --
> Sander
> 
> > 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 Feb 27 19:50:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19:50: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 1UAn0Z-0004E0-2j; Wed, 27 Feb 2013 19:49:43 +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 1UAn0Y-0004Dv-6s
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:49:42 +0000
Received: from [85.158.139.83:50104] by server-1.bemta-5.messagelabs.com id
	FD/D5-14063-5536E215; Wed, 27 Feb 2013 19:49:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361994580!26549662!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15020 invoked from network); 27 Feb 2013 19:49:40 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 19:49:40 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so6794702wie.2
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 11:49:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HT5tBbJ/1J6HxyUp34S6EAzwFNd+kAEFRQweRBloRpo=;
	b=Ajt36lAX0xFxggkZ8ljIT1mZc7GhbhBFNKL6tHZESrmEysrr3Nkex1wK1V30fz/Y/8
	EUBtZSjdWb+1vsGwgNf3mVtXKpmprHLndEI63o4l2V0mkYbilzs/yDWCz2X5suSjmLsm
	B9cJG5PWJaj5KnLfMQgYN0OFrYkHQXwcM5WkFbaUpEmCw477rFuazwNbzq/ICd1wSgU5
	7hobwgrKDJ1/3CCLbGv+fJVdxt5UkqG/8gtJQnQVD64JisH6hk/YVM+1o7XJDXmGSqUx
	pViDBEv2mz4jqhuGskYfaVpfygEUFX02Kz5JRAOUZ0tHyMIJQQfOUn3AYsfRAwc5vSRf
	haOg==
X-Received: by 10.194.10.202 with SMTP id k10mr6283578wjb.53.1361994580644;
	Wed, 27 Feb 2013 11:49:40 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ay10sm29360434wib.3.2013.02.27.11.49.38
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 11:49:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 19:49:34 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Wei Liu <wei.liu2@citrix.com>
Message-ID: <CD5413CE.4CD6E%keir.xen@gmail.com>
Thread-Topic: [RFC PATCH V3] Implement 3-level event channel in Xen
Thread-Index: Ac4VI5DvJXIxo3pjg0OpqJFKZGZyqw==
In-Reply-To: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>> Keir, Jan, Ian and David, are you happy with this design in general? I would
>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>> 4.3 is quite close now.
> 
> The patches look reasonable (apart from the comments I just gave
> on some of them), but other than Keir I'm not that eager to see this
> one go in for 4.3 in order to then likely be replaced by an
> implementation of David's design in the 4.4 cycle.

If this went in for 4.3, a re-design would really have to be implemented and
measurably prove its worth to make it in as another replacement.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 19:50:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19:50: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 1UAn0Z-0004E0-2j; Wed, 27 Feb 2013 19:49:43 +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 1UAn0Y-0004Dv-6s
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:49:42 +0000
Received: from [85.158.139.83:50104] by server-1.bemta-5.messagelabs.com id
	FD/D5-14063-5536E215; Wed, 27 Feb 2013 19:49:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1361994580!26549662!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15020 invoked from network); 27 Feb 2013 19:49:40 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 19:49:40 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so6794702wie.2
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 11:49:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HT5tBbJ/1J6HxyUp34S6EAzwFNd+kAEFRQweRBloRpo=;
	b=Ajt36lAX0xFxggkZ8ljIT1mZc7GhbhBFNKL6tHZESrmEysrr3Nkex1wK1V30fz/Y/8
	EUBtZSjdWb+1vsGwgNf3mVtXKpmprHLndEI63o4l2V0mkYbilzs/yDWCz2X5suSjmLsm
	B9cJG5PWJaj5KnLfMQgYN0OFrYkHQXwcM5WkFbaUpEmCw477rFuazwNbzq/ICd1wSgU5
	7hobwgrKDJ1/3CCLbGv+fJVdxt5UkqG/8gtJQnQVD64JisH6hk/YVM+1o7XJDXmGSqUx
	pViDBEv2mz4jqhuGskYfaVpfygEUFX02Kz5JRAOUZ0tHyMIJQQfOUn3AYsfRAwc5vSRf
	haOg==
X-Received: by 10.194.10.202 with SMTP id k10mr6283578wjb.53.1361994580644;
	Wed, 27 Feb 2013 11:49:40 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ay10sm29360434wib.3.2013.02.27.11.49.38
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 11:49:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Wed, 27 Feb 2013 19:49:34 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Wei Liu <wei.liu2@citrix.com>
Message-ID: <CD5413CE.4CD6E%keir.xen@gmail.com>
Thread-Topic: [RFC PATCH V3] Implement 3-level event channel in Xen
Thread-Index: Ac4VI5DvJXIxo3pjg0OpqJFKZGZyqw==
In-Reply-To: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org, keir@xen.org, david.vrabel@citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>> Keir, Jan, Ian and David, are you happy with this design in general? I would
>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>> 4.3 is quite close now.
> 
> The patches look reasonable (apart from the comments I just gave
> on some of them), but other than Keir I'm not that eager to see this
> one go in for 4.3 in order to then likely be replaced by an
> implementation of David's design in the 4.4 cycle.

If this went in for 4.3, a re-design would really have to be implemented and
measurably prove its worth to make it in as another replacement.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 19:56:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19: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 1UAn6u-0004av-US; Wed, 27 Feb 2013 19:56:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAn6s-0004an-Ux
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:56:15 +0000
Received: from [85.158.139.211:43645] by server-6.bemta-5.messagelabs.com id
	E9/36-21466-ED46E215; Wed, 27 Feb 2013 19:56:14 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361994972!18945345!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20031 invoked from network); 27 Feb 2013 19:56:12 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 19:56:12 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51417 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 1UAn4i-0004t1-4a; Wed, 27 Feb 2013 20:54:00 +0100
Date: Wed, 27 Feb 2013 20:56:07 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <374661137.20130227205607@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130227192810.GA30169@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 8:28:10 PM, you wrote:

> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>> 
>> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> 
>> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> > find the origin of this return value by instrumenting the involved
>> > call tree.
>> 
>> Just wondering, is multiple msi's per device actually supported by xen ?

> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> use them and they work great with Xen.

> BTW, this is merge:
> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> Merge: 266d7ad af8d102
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Tue Feb 19 19:07:27 2013 -0800

>     Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     
>     Pull x86/apic changes from Ingo Molnar:
>      "Main changes:
>     
>        - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>          by all relevant maintainers, by Alexander Gordeev.
>     
>          The advantage is that multiple AHCI ports can have multiple MSI
>          irqs assigned, and can thus spread to multiple CPUs.
>     
>          [ Drivers can make use of this new facility via the
>            pci_enable_msi_block_auto() method ]


Ahh yes, i have added some debug info to ahci.c:

  [   36.778395] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
  [   36.809777] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
  [   36.835136] ahci 0000:00:11.0: SE | ahci_init_one start 
  [   36.858284] ahci 0000:00:11.0: version 3.0
  [   36.877840] xen: registering gsi 19 triggering 0 polarity 1
  [   36.901791] xen: --> pirq=19 -> irq=19 (gsi=19)
  (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
 [   36.949293] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
  [   36.974714] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
  [   37.010706] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:4
  [   37.039878] ahci 0000:00:11.0: SE | n_msis: 4
  [   37.060115] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
  [   37.094135] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
  [   37.121658] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
  [   37.153118] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
  [   37.184265] ahci 0000:00:11.0: SE | me here 1 
  [   37.204568] ahci 0000:00:11.0: SE | n_msis(4) host->n_ports(4) irq:121
  [   37.231748] ahci 0000:00:11.0: SE | ata_host_start(host) rc:0
  [   37.256222] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:0  rc:0
  [   37.283023] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:1  rc:-22
  [   37.310344] really_probe: dev->bus->probe(0000:00:11.0) ret: -22
  [   37.335467] ahci: probe of 0000:00:11.0 failed with error -22
  [   37.359552] really_probe: 0000:00:11.0 done ret: 0

So it bails out at the second devm_request_threaded_irq in:

int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis)
{
        int i, rc;

        dev_err(host->dev, "SE | n_msis(%d) host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
        /* Sharing Last Message among several ports is not supported */
        if (n_msis < host->n_ports){
                dev_err(host->dev, "SE | uhoh n_msis(%d) < host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
                return -EINVAL;
        }
        rc = ata_host_start(host);
        dev_err(host->dev, "SE | ata_host_start(host) rc:%d\n",rc);
        if (rc)
                return rc;

        for (i = 0; i < host->n_ports; i++) {
                rc = devm_request_threaded_irq(host->dev,
                        irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
                        dev_driver_string(host->dev), host->ports[i]);
                dev_err(host->dev, "SE | devm_request_threaded_irq i:%d  rc:%d\n",i,rc);
                if (rc)
                        goto out_free_irqs;
        }




> With MSI per device, the hypercall that ends up happening is:
> PHYSDEVOP_map_pirq with:

>    map_irq.domid = domid;
>    map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>    map_irq.index = -1;
>    map_irq.pirq = -1;
>    map_irq.bus = dev->bus->number |
>                  (pci_domain_nr(dev->bus) << 16);
>    map_irq.devfn = dev->devfn;

> Which would imply that we are doing this call multiple times?
> (This is xen_initdom_setup_msi_irqs).

> It looks like pci_enable_msi_block_auto is the multiple MSI one
> and it should perculate down to xen_initdom_setup_msi_irqs.
> Granted the xen_init.. does not do anything with the 'nvec' call.

> So could I ask you try out your hunch by doing three things:
>  1). Instrument xen_initdom_setup_msi_irqs to see if the
>      nvec has anything but 1 and in its loop instrument to
>      see if it has more than on MSI attribute?

>  2). The ahci driver has ahci_init_interrupts which only does
>    the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>     If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>     to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>     seperatly from 1).
>  3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>     and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab? 
>> 
>> --
>> Sander
>> 
>> > 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 Feb 27 19:56:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 19: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 1UAn6u-0004av-US; Wed, 27 Feb 2013 19:56:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAn6s-0004an-Ux
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 19:56:15 +0000
Received: from [85.158.139.211:43645] by server-6.bemta-5.messagelabs.com id
	E9/36-21466-ED46E215; Wed, 27 Feb 2013 19:56:14 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-206.messagelabs.com!1361994972!18945345!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20031 invoked from network); 27 Feb 2013 19:56:12 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 19:56:12 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51417 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 1UAn4i-0004t1-4a; Wed, 27 Feb 2013 20:54:00 +0100
Date: Wed, 27 Feb 2013 20:56:07 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <374661137.20130227205607@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130227192810.GA30169@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 8:28:10 PM, you wrote:

> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>> 
>> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> 
>> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> > find the origin of this return value by instrumenting the involved
>> > call tree.
>> 
>> Just wondering, is multiple msi's per device actually supported by xen ?

> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> use them and they work great with Xen.

> BTW, this is merge:
> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> Merge: 266d7ad af8d102
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Tue Feb 19 19:07:27 2013 -0800

>     Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     
>     Pull x86/apic changes from Ingo Molnar:
>      "Main changes:
>     
>        - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>          by all relevant maintainers, by Alexander Gordeev.
>     
>          The advantage is that multiple AHCI ports can have multiple MSI
>          irqs assigned, and can thus spread to multiple CPUs.
>     
>          [ Drivers can make use of this new facility via the
>            pci_enable_msi_block_auto() method ]


Ahh yes, i have added some debug info to ahci.c:

  [   36.778395] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
  [   36.809777] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
  [   36.835136] ahci 0000:00:11.0: SE | ahci_init_one start 
  [   36.858284] ahci 0000:00:11.0: version 3.0
  [   36.877840] xen: registering gsi 19 triggering 0 polarity 1
  [   36.901791] xen: --> pirq=19 -> irq=19 (gsi=19)
  (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
 [   36.949293] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
  [   36.974714] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
  [   37.010706] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:4
  [   37.039878] ahci 0000:00:11.0: SE | n_msis: 4
  [   37.060115] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
  [   37.094135] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
  [   37.121658] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
  [   37.153118] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
  [   37.184265] ahci 0000:00:11.0: SE | me here 1 
  [   37.204568] ahci 0000:00:11.0: SE | n_msis(4) host->n_ports(4) irq:121
  [   37.231748] ahci 0000:00:11.0: SE | ata_host_start(host) rc:0
  [   37.256222] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:0  rc:0
  [   37.283023] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:1  rc:-22
  [   37.310344] really_probe: dev->bus->probe(0000:00:11.0) ret: -22
  [   37.335467] ahci: probe of 0000:00:11.0 failed with error -22
  [   37.359552] really_probe: 0000:00:11.0 done ret: 0

So it bails out at the second devm_request_threaded_irq in:

int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis)
{
        int i, rc;

        dev_err(host->dev, "SE | n_msis(%d) host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
        /* Sharing Last Message among several ports is not supported */
        if (n_msis < host->n_ports){
                dev_err(host->dev, "SE | uhoh n_msis(%d) < host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
                return -EINVAL;
        }
        rc = ata_host_start(host);
        dev_err(host->dev, "SE | ata_host_start(host) rc:%d\n",rc);
        if (rc)
                return rc;

        for (i = 0; i < host->n_ports; i++) {
                rc = devm_request_threaded_irq(host->dev,
                        irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
                        dev_driver_string(host->dev), host->ports[i]);
                dev_err(host->dev, "SE | devm_request_threaded_irq i:%d  rc:%d\n",i,rc);
                if (rc)
                        goto out_free_irqs;
        }




> With MSI per device, the hypercall that ends up happening is:
> PHYSDEVOP_map_pirq with:

>    map_irq.domid = domid;
>    map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>    map_irq.index = -1;
>    map_irq.pirq = -1;
>    map_irq.bus = dev->bus->number |
>                  (pci_domain_nr(dev->bus) << 16);
>    map_irq.devfn = dev->devfn;

> Which would imply that we are doing this call multiple times?
> (This is xen_initdom_setup_msi_irqs).

> It looks like pci_enable_msi_block_auto is the multiple MSI one
> and it should perculate down to xen_initdom_setup_msi_irqs.
> Granted the xen_init.. does not do anything with the 'nvec' call.

> So could I ask you try out your hunch by doing three things:
>  1). Instrument xen_initdom_setup_msi_irqs to see if the
>      nvec has anything but 1 and in its loop instrument to
>      see if it has more than on MSI attribute?

>  2). The ahci driver has ahci_init_interrupts which only does
>    the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>     If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>     to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>     seperatly from 1).
>  3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>     and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab? 
>> 
>> --
>> Sander
>> 
>> > 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 Feb 27 20:01:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 20:01: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 1UAnBf-0004sD-OT; Wed, 27 Feb 2013 20:01:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAnBd-0004s1-KJ
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 20:01:09 +0000
Received: from [85.158.143.99:17308] by server-3.bemta-4.messagelabs.com id
	E0/1A-02186-5066E215; Wed, 27 Feb 2013 20:01:09 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361995268!19768339!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7601 invoked from network); 27 Feb 2013 20:01:08 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 20:01:08 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C6058C5619B;
	Wed, 27 Feb 2013 20:00:55 +0000 (GMT)
Date: Wed, 27 Feb 2013 20:00:54 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <714AB68E783E2AC7DEB51045@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, fantonifabio@tiscali.it, "Tim
	\(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefan Bader <stefan.bader@canonical.com>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 February 2013 11:58:30 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I think that is the right way of thinking. After all we even have a
> differentiation between maintainers and committers exactly for this sort
> of cases (even though right now we aren't using it much).
>
> So the question is, would anybody step up to maintain a proper deb build
> target?

If 'proper deb build target' means one like ubuntu (or debian which
I believe to be very similar) but without any custom code patches, yes,
I'll stick up my hand for that one. Note this makes more than one
package:

http://packages.ubuntu.com/search?keywords=xen-&searchon=names&suite=raring&section=all

which may or may not make it suitable as a 'tarball replacement'.

My approach would in essence be to borrow the Ubuntu/Debian packaging
and make it build with a proper debian/ directory, rather than using
a 'make deb' build target.

Bringing debian packaging upstream is (I believe) considered 'no bad
thing'.

I would however point out that there are others infinitely more
qualified than me to do this (Stefan Bader for instance - copied),
and such a person wants to do it I have no objection whatsoever.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 20:01:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 20:01: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 1UAnBf-0004sD-OT; Wed, 27 Feb 2013 20:01:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAnBd-0004s1-KJ
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 20:01:09 +0000
Received: from [85.158.143.99:17308] by server-3.bemta-4.messagelabs.com id
	E0/1A-02186-5066E215; Wed, 27 Feb 2013 20:01:09 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-8.tower-216.messagelabs.com!1361995268!19768339!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7601 invoked from network); 27 Feb 2013 20:01:08 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-8.tower-216.messagelabs.com with SMTP;
	27 Feb 2013 20:01:08 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id C6058C5619B;
	Wed, 27 Feb 2013 20:00:55 +0000 (GMT)
Date: Wed, 27 Feb 2013 20:00:54 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <714AB68E783E2AC7DEB51045@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, fantonifabio@tiscali.it, "Tim
	\(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefan Bader <stefan.bader@canonical.com>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 February 2013 11:58:30 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I think that is the right way of thinking. After all we even have a
> differentiation between maintainers and committers exactly for this sort
> of cases (even though right now we aren't using it much).
>
> So the question is, would anybody step up to maintain a proper deb build
> target?

If 'proper deb build target' means one like ubuntu (or debian which
I believe to be very similar) but without any custom code patches, yes,
I'll stick up my hand for that one. Note this makes more than one
package:

http://packages.ubuntu.com/search?keywords=xen-&searchon=names&suite=raring&section=all

which may or may not make it suitable as a 'tarball replacement'.

My approach would in essence be to borrow the Ubuntu/Debian packaging
and make it build with a proper debian/ directory, rather than using
a 'make deb' build target.

Bringing debian packaging upstream is (I believe) considered 'no bad
thing'.

I would however point out that there are others infinitely more
qualified than me to do this (Stefan Bader for instance - copied),
and such a person wants to do it I have no objection whatsoever.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 20:08:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 20: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 1UAnI1-00056i-L8; Wed, 27 Feb 2013 20:07:45 +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 1UAnI0-00056c-Qq
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 20:07:45 +0000
Received: from [85.158.139.83:18707] by server-11.bemta-5.messagelabs.com id
	22/EB-27486-0976E215; Wed, 27 Feb 2013 20:07:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361995663!24078278!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 27 Feb 2013 20:07:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 20:07:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; 
   d="scan'208";a="1976358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 20: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.297.1;
	Wed, 27 Feb 2013 20:07:43 +0000
Message-ID: <1361995662.23384.0.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Wed, 27 Feb 2013 20:07:42 +0000
In-Reply-To: <714AB68E783E2AC7DEB51045@Ximines.local>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] [PATCH v2] 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 Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
> 
> Bringing debian packaging upstream is (I believe) considered 'no bad
> thing'. 

On the contrary, Debian discourages upstreams from including a debian/
directory in their releases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 20:08:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 20: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 1UAnI1-00056i-L8; Wed, 27 Feb 2013 20:07:45 +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 1UAnI0-00056c-Qq
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 20:07:45 +0000
Received: from [85.158.139.83:18707] by server-11.bemta-5.messagelabs.com id
	22/EB-27486-0976E215; Wed, 27 Feb 2013 20:07:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1361995663!24078278!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27104 invoked from network); 27 Feb 2013 20:07:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 20:07:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; 
   d="scan'208";a="1976358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 20: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.297.1;
	Wed, 27 Feb 2013 20:07:43 +0000
Message-ID: <1361995662.23384.0.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Wed, 27 Feb 2013 20:07:42 +0000
In-Reply-To: <714AB68E783E2AC7DEB51045@Ximines.local>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [Xen-devel] [PATCH v2] 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 Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
> 
> Bringing debian packaging upstream is (I believe) considered 'no bad
> thing'. 

On the contrary, Debian discourages upstreams from including a debian/
directory in their releases.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 20:42:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 20:42: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 1UAnpA-0005zM-E1; Wed, 27 Feb 2013 20:42:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAnp8-0005zE-Te
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 20:41:59 +0000
Received: from [85.158.137.99:25562] by server-9.bemta-3.messagelabs.com id
	E5/EA-32531-69F6E215; Wed, 27 Feb 2013 20:41:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361997717!13322981!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16050 invoked from network); 27 Feb 2013 20:41:57 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 20:41:57 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51584 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 1UAnmz-00055t-Bc; Wed, 27 Feb 2013 21:39:45 +0100
Date: Wed, 27 Feb 2013 21:41:53 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <171656525.20130227214153@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130227192810.GA30169@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 8:28:10 PM, you wrote:

> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>> 
>> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> 
>> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> > find the origin of this return value by instrumenting the involved
>> > call tree.
>> 
>> Just wondering, is multiple msi's per device actually supported by xen ?

> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> use them and they work great with Xen.

> BTW, this is merge:
> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> Merge: 266d7ad af8d102
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Tue Feb 19 19:07:27 2013 -0800

>     Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     
>     Pull x86/apic changes from Ingo Molnar:
>      "Main changes:
>     
>        - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>          by all relevant maintainers, by Alexander Gordeev.
>     
>          The advantage is that multiple AHCI ports can have multiple MSI
>          irqs assigned, and can thus spread to multiple CPUs.
>     
>          [ Drivers can make use of this new facility via the
>            pci_enable_msi_block_auto() method ]



> With MSI per device, the hypercall that ends up happening is:
> PHYSDEVOP_map_pirq with:

>    map_irq.domid = domid;
>    map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>    map_irq.index = -1;
>    map_irq.pirq = -1;
>    map_irq.bus = dev->bus->number |
>                  (pci_domain_nr(dev->bus) << 16);
>    map_irq.devfn = dev->devfn;

> Which would imply that we are doing this call multiple times?
> (This is xen_initdom_setup_msi_irqs).

> It looks like pci_enable_msi_block_auto is the multiple MSI one
> and it should perculate down to xen_initdom_setup_msi_irqs.
> Granted the xen_init.. does not do anything with the 'nvec' call.

> So could I ask you try out your hunch by doing three things:
>  1). Instrument xen_initdom_setup_msi_irqs to see if the
>      nvec has anything but 1 and in its loop instrument to
>      see if it has more than on MSI attribute?

>  2). The ahci driver has ahci_init_interrupts which only does
>    the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>     If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>     to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>     seperatly from 1).
>  3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>     and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab? 


So of interest are commits:
- 5ca72c4f7c412c2002363218901eba5516c476b1
- 08261d87f7d1b6253ab3223756625a5c74532293
- 51906e779f2b13b38f8153774c4c7163d412ffd9

Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:

x86/MSI: Support multiple MSIs in presense of IRQ remapping

The MSI specification has several constraints in comparison with
MSI-X, most notable of them is the inability to configure MSIs
independently. As a result, it is impossible to dispatch
interrupts from different queues to different CPUs. This is
largely devalues the support of multiple MSIs in SMP systems.

Also, a necessity to allocate a contiguous block of vector
numbers for devices capable of multiple MSIs might cause a
considerable pressure on x86 interrupt vector allocator and
could lead to fragmentation of the interrupt vectors space.

This patch overcomes both drawbacks in presense of IRQ remapping
and lets devices take advantage of multiple queues and per-IRQ
affinity assignments.

At least makes clear why baremetal does boot and xen doesn't:

Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.

So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail

--
Sander




>> 
>> --
>> Sander
>> 
>> > 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 Feb 27 20:42:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 20:42: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 1UAnpA-0005zM-E1; Wed, 27 Feb 2013 20:42:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAnp8-0005zE-Te
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 20:41:59 +0000
Received: from [85.158.137.99:25562] by server-9.bemta-3.messagelabs.com id
	E5/EA-32531-69F6E215; Wed, 27 Feb 2013 20:41:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-217.messagelabs.com!1361997717!13322981!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16050 invoked from network); 27 Feb 2013 20:41:57 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 20:41:57 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51584 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 1UAnmz-00055t-Bc; Wed, 27 Feb 2013 21:39:45 +0100
Date: Wed, 27 Feb 2013 21:41:53 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <171656525.20130227214153@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130227192810.GA30169@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 8:28:10 PM, you wrote:

> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>> 
>> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> 
>> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> > find the origin of this return value by instrumenting the involved
>> > call tree.
>> 
>> Just wondering, is multiple msi's per device actually supported by xen ?

> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> use them and they work great with Xen.

> BTW, this is merge:
> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> Merge: 266d7ad af8d102
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Tue Feb 19 19:07:27 2013 -0800

>     Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     
>     Pull x86/apic changes from Ingo Molnar:
>      "Main changes:
>     
>        - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>          by all relevant maintainers, by Alexander Gordeev.
>     
>          The advantage is that multiple AHCI ports can have multiple MSI
>          irqs assigned, and can thus spread to multiple CPUs.
>     
>          [ Drivers can make use of this new facility via the
>            pci_enable_msi_block_auto() method ]



> With MSI per device, the hypercall that ends up happening is:
> PHYSDEVOP_map_pirq with:

>    map_irq.domid = domid;
>    map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>    map_irq.index = -1;
>    map_irq.pirq = -1;
>    map_irq.bus = dev->bus->number |
>                  (pci_domain_nr(dev->bus) << 16);
>    map_irq.devfn = dev->devfn;

> Which would imply that we are doing this call multiple times?
> (This is xen_initdom_setup_msi_irqs).

> It looks like pci_enable_msi_block_auto is the multiple MSI one
> and it should perculate down to xen_initdom_setup_msi_irqs.
> Granted the xen_init.. does not do anything with the 'nvec' call.

> So could I ask you try out your hunch by doing three things:
>  1). Instrument xen_initdom_setup_msi_irqs to see if the
>      nvec has anything but 1 and in its loop instrument to
>      see if it has more than on MSI attribute?

>  2). The ahci driver has ahci_init_interrupts which only does
>    the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>     If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>     to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>     seperatly from 1).
>  3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>     and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab? 


So of interest are commits:
- 5ca72c4f7c412c2002363218901eba5516c476b1
- 08261d87f7d1b6253ab3223756625a5c74532293
- 51906e779f2b13b38f8153774c4c7163d412ffd9

Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:

x86/MSI: Support multiple MSIs in presense of IRQ remapping

The MSI specification has several constraints in comparison with
MSI-X, most notable of them is the inability to configure MSIs
independently. As a result, it is impossible to dispatch
interrupts from different queues to different CPUs. This is
largely devalues the support of multiple MSIs in SMP systems.

Also, a necessity to allocate a contiguous block of vector
numbers for devices capable of multiple MSIs might cause a
considerable pressure on x86 interrupt vector allocator and
could lead to fragmentation of the interrupt vectors space.

This patch overcomes both drawbacks in presense of IRQ remapping
and lets devices take advantage of multiple queues and per-IRQ
affinity assignments.

At least makes clear why baremetal does boot and xen doesn't:

Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.

So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail

--
Sander




>> 
>> --
>> Sander
>> 
>> > 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 Feb 27 21:57:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAozZ-0007Hg-1O; Wed, 27 Feb 2013 21:56:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UAozX-0007HW-9O
	for Xen-devel@lists.xen.org; Wed, 27 Feb 2013 21:56:47 +0000
Received: from [85.158.139.83:52453] by server-3.bemta-5.messagelabs.com id
	B6/99-17256-E118E215; Wed, 27 Feb 2013 21:56:46 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1362002205!29301264!1
X-Originating-IP: [74.125.82.180]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20423 invoked from network); 27 Feb 2013 21:56:46 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 21:56:46 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so910915wer.25
	for <Xen-devel@lists.xen.org>; Wed, 27 Feb 2013 13:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=uAlk4lDPRJg8KzNNeE2kG9F8hMEZUM905hvUbUwt4ko=;
	b=X9WvMEny7rE/CnFbJ2Hx2/NRqd6Mnvk4oXfWOC9XyfXQNyzPN685mQzvbWvz56B9ge
	z8+CuqoF48+ot4aHNTP/x7VQGcFei9FuRHMYBjftxPI/nauVOim5OqB0Az4IDxefLHZR
	xr1j12Eb/WS/SbNEoMbsNBg4KkgOKhL0gH/+HkxZPgLUSZY560g7dBWk4e9xqxcLmPpS
	2ySXV85EOd7Aj7G6dapDDwqGqD94GwullkKpNosd0lWPNvJ2fYn0JkXwmHuIhRcxkJwr
	DHlg0J220rR8dxlLxyw4WioKaHjmFpnolwrYdnHGpk3gENe4QPxLv3BNOxwQCDBR4WbN
	5wLg==
MIME-Version: 1.0
X-Received: by 10.180.14.233 with SMTP id s9mr6711445wic.25.1362002205854;
	Wed, 27 Feb 2013 13:56:45 -0800 (PST)
Received: by 10.216.94.74 with HTTP; Wed, 27 Feb 2013 13:56:45 -0800 (PST)
Date: Wed, 27 Feb 2013 13:56:45 -0800
Message-ID: <CAJJWZcxvWtQJJY1JUDgCoCKzQmJ6R4XNiMGPNXzqvTi4PzBs1w@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] What is the purpose of ASSERT(!in_irq())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2925551677748479735=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2925551677748479735==
Content-Type: multipart/alternative; boundary=f46d040fa03ca9d21e04d6bbd9b9

--f46d040fa03ca9d21e04d6bbd9b9
Content-Type: text/plain; charset=ISO-8859-1

Hi all, I see many functions' entry points have this assertion:
 ASSERT(!in_irq()). What is the intuition behind this function? In which
condition the function should not called in ISR ?
Thanks,
-- 
Xinxin

--f46d040fa03ca9d21e04d6bbd9b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all, I see many functions&#39; entry points have this assertion: =A0ASSE=
RT(!in_irq()). What is the intuition behind this function? In which conditi=
on the function should not called in ISR ?<br clear=3D"all"><div>Thanks,</d=
iv>
-- <br>Xinxin


--f46d040fa03ca9d21e04d6bbd9b9--


--===============2925551677748479735==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2925551677748479735==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 21:57:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 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 1UAozZ-0007Hg-1O; Wed, 27 Feb 2013 21:56:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1UAozX-0007HW-9O
	for Xen-devel@lists.xen.org; Wed, 27 Feb 2013 21:56:47 +0000
Received: from [85.158.139.83:52453] by server-3.bemta-5.messagelabs.com id
	B6/99-17256-E118E215; Wed, 27 Feb 2013 21:56:46 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1362002205!29301264!1
X-Originating-IP: [74.125.82.180]
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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20423 invoked from network); 27 Feb 2013 21:56:46 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com)
	(74.125.82.180)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 21:56:46 -0000
Received: by mail-we0-f180.google.com with SMTP id k14so910915wer.25
	for <Xen-devel@lists.xen.org>; Wed, 27 Feb 2013 13:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:date:message-id:subject:from:to
	:content-type; bh=uAlk4lDPRJg8KzNNeE2kG9F8hMEZUM905hvUbUwt4ko=;
	b=X9WvMEny7rE/CnFbJ2Hx2/NRqd6Mnvk4oXfWOC9XyfXQNyzPN685mQzvbWvz56B9ge
	z8+CuqoF48+ot4aHNTP/x7VQGcFei9FuRHMYBjftxPI/nauVOim5OqB0Az4IDxefLHZR
	xr1j12Eb/WS/SbNEoMbsNBg4KkgOKhL0gH/+HkxZPgLUSZY560g7dBWk4e9xqxcLmPpS
	2ySXV85EOd7Aj7G6dapDDwqGqD94GwullkKpNosd0lWPNvJ2fYn0JkXwmHuIhRcxkJwr
	DHlg0J220rR8dxlLxyw4WioKaHjmFpnolwrYdnHGpk3gENe4QPxLv3BNOxwQCDBR4WbN
	5wLg==
MIME-Version: 1.0
X-Received: by 10.180.14.233 with SMTP id s9mr6711445wic.25.1362002205854;
	Wed, 27 Feb 2013 13:56:45 -0800 (PST)
Received: by 10.216.94.74 with HTTP; Wed, 27 Feb 2013 13:56:45 -0800 (PST)
Date: Wed, 27 Feb 2013 13:56:45 -0800
Message-ID: <CAJJWZcxvWtQJJY1JUDgCoCKzQmJ6R4XNiMGPNXzqvTi4PzBs1w@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] What is the purpose of ASSERT(!in_irq())
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============2925551677748479735=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2925551677748479735==
Content-Type: multipart/alternative; boundary=f46d040fa03ca9d21e04d6bbd9b9

--f46d040fa03ca9d21e04d6bbd9b9
Content-Type: text/plain; charset=ISO-8859-1

Hi all, I see many functions' entry points have this assertion:
 ASSERT(!in_irq()). What is the intuition behind this function? In which
condition the function should not called in ISR ?
Thanks,
-- 
Xinxin

--f46d040fa03ca9d21e04d6bbd9b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all, I see many functions&#39; entry points have this assertion: =A0ASSE=
RT(!in_irq()). What is the intuition behind this function? In which conditi=
on the function should not called in ISR ?<br clear=3D"all"><div>Thanks,</d=
iv>
-- <br>Xinxin


--f46d040fa03ca9d21e04d6bbd9b9--


--===============2925551677748479735==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2925551677748479735==--


From xen-devel-bounces@lists.xen.org Wed Feb 27 22:10:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22: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 1UApC0-0007b1-Gv; Wed, 27 Feb 2013 22:09:40 +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 1UApBy-0007aw-AU
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 22:09:38 +0000
Received: from [85.158.138.51:54765] by server-9.bemta-3.messagelabs.com id
	D5/64-32531-1248E215; Wed, 27 Feb 2013 22:09:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362002976!28477515!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19294 invoked from network); 27 Feb 2013 22:09:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 22:09:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; 
   d="scan'208";a="1980679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 22:09: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.297.1; Wed, 27 Feb 2013 22:09:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UApBt-0000qB-IY;
	Wed, 27 Feb 2013 22:09:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UApBt-0003e5-3p;
	Wed, 27 Feb 2013 22:09:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 22:09:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 16764: 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 16764 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16764/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12678
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12678
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   like 12678

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-credit2   15 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemut-win  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 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-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-qemut-win     7 windows-install              fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemut-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

version targeted for testing:
 linux                9f6584a8bd729f61c01bed1bb4e0a010bf1a643f
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 27 22:10:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22: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 1UApC0-0007b1-Gv; Wed, 27 Feb 2013 22:09:40 +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 1UApBy-0007aw-AU
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 22:09:38 +0000
Received: from [85.158.138.51:54765] by server-9.bemta-3.messagelabs.com id
	D5/64-32531-1248E215; Wed, 27 Feb 2013 22:09:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362002976!28477515!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19294 invoked from network); 27 Feb 2013 22:09:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 22:09:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; 
   d="scan'208";a="1980679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 22:09: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.297.1; Wed, 27 Feb 2013 22:09:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UApBt-0000qB-IY;
	Wed, 27 Feb 2013 22:09:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UApBt-0003e5-3p;
	Wed, 27 Feb 2013 22:09:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 22:09:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 16764: 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 16764 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16764/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12678
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12678
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-xl-multivcpu  7 debian-install               fail   like 12678

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-credit2   15 guest-stop                   fail   never pass
 test-amd64-amd64-qemut-win    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemut-win  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 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-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install         fail never pass
 test-amd64-i386-qemut-win     7 windows-install              fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install         fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemut-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

version targeted for testing:
 linux                9f6584a8bd729f61c01bed1bb4e0a010bf1a643f
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 27 22:14:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22:14: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 1UApGT-0007on-6s; Wed, 27 Feb 2013 22:14: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 1UApGR-0007og-2m
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 22:14:15 +0000
Received: from [85.158.139.83:4423] by server-11.bemta-5.messagelabs.com id
	E4/7D-27486-5358E215; Wed, 27 Feb 2013 22:14:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1362003252!25401119!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20684 invoked from network); 27 Feb 2013 22:14:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 22:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; 
   d="scan'208";a="1980787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 22:14: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.297.1; Wed, 27 Feb 2013 22:14:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UApGN-0000rr-Jn;
	Wed, 27 Feb 2013 22:14:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UApGN-0001xm-HL;
	Wed, 27 Feb 2013 22:14:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 22:14:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16762: 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 16762 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16762/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10   fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-win-vcpus1 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-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 6c7bb5a198de5cfd3f720e2376c7aa184d61329e
Author: Keir Fraser <keir@xen.org>
Date:   Tue Feb 26 16:51:28 2013 +0000

    MAINTAINERS: Remove Jeremy from pv_ops maintainer list.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 22:14:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22:14: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 1UApGT-0007on-6s; Wed, 27 Feb 2013 22:14: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 1UApGR-0007og-2m
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 22:14:15 +0000
Received: from [85.158.139.83:4423] by server-11.bemta-5.messagelabs.com id
	E4/7D-27486-5358E215; Wed, 27 Feb 2013 22:14:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1362003252!25401119!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NTI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20684 invoked from network); 27 Feb 2013 22:14:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 22:14:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; 
   d="scan'208";a="1980787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Feb 2013 22:14: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.297.1; Wed, 27 Feb 2013 22:14:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UApGN-0000rr-Jn;
	Wed, 27 Feb 2013 22:14:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UApGN-0001xm-HL;
	Wed, 27 Feb 2013 22:14:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 27 Feb 2013 22:14:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16762: 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 16762 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16762/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10   fail REGR. vs. 16226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-win-vcpus1 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-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 6c7bb5a198de5cfd3f720e2376c7aa184d61329e
Author: Keir Fraser <keir@xen.org>
Date:   Tue Feb 26 16:51:28 2013 +0000

    MAINTAINERS: Remove Jeremy from pv_ops maintainer list.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 22:22:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22: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 1UApOV-00085v-6c; Wed, 27 Feb 2013 22:22:35 +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 1UApOT-00085q-H1
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 22:22:33 +0000
Received: from [85.158.139.83:3239] by server-15.bemta-5.messagelabs.com id
	0F/5D-22815-8278E215; Wed, 27 Feb 2013 22:22:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1362003750!27535654!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjQ2MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22176 invoked from network); 27 Feb 2013 22:22:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 22:22:31 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RMMPw2019044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 22:22:26 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
	r1RMMO4J012316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 22:22:24 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
	r1RMMO8v021747; Wed, 27 Feb 2013 16:22:24 -0600
Received: from [10.154.120.173] (/10.154.120.173)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 14:22:23 -0800
Message-ID: <512E871A.20706@oracle.com>
Date: Wed, 27 Feb 2013 17:22:18 -0500
From: konrad wilk <konrad.wilk@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
In-Reply-To: <171656525.20130227214153@eikelenboom.it>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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-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 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
>
>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>
>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>>>> find the origin of this return value by instrumenting the involved
>>>> call tree.
>>> Just wondering, is multiple msi's per device actually supported by xen ?
>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
>> use them and they work great with Xen.
>> BTW, this is merge:
>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
>> Merge: 266d7ad af8d102
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Tue Feb 19 19:07:27 2013 -0800
>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>      
>>      Pull x86/apic changes from Ingo Molnar:
>>       "Main changes:
>>      
>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>>           by all relevant maintainers, by Alexander Gordeev.
>>      
>>           The advantage is that multiple AHCI ports can have multiple MSI
>>           irqs assigned, and can thus spread to multiple CPUs.
>>      
>>           [ Drivers can make use of this new facility via the
>>             pci_enable_msi_block_auto() method ]
>
>
>> With MSI per device, the hypercall that ends up happening is:
>> PHYSDEVOP_map_pirq with:
>>     map_irq.domid = domid;
>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>>     map_irq.index = -1;
>>     map_irq.pirq = -1;
>>     map_irq.bus = dev->bus->number |
>>                   (pci_domain_nr(dev->bus) << 16);
>>     map_irq.devfn = dev->devfn;
>> Which would imply that we are doing this call multiple times?
>> (This is xen_initdom_setup_msi_irqs).
>> It looks like pci_enable_msi_block_auto is the multiple MSI one
>> and it should perculate down to xen_initdom_setup_msi_irqs.
>> Granted the xen_init.. does not do anything with the 'nvec' call.
>> So could I ask you try out your hunch by doing three things:
>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
>>       nvec has anything but 1 and in its loop instrument to
>>       see if it has more than on MSI attribute?
>>   2). The ahci driver has ahci_init_interrupts which only does
>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>>      seperatly from 1).
>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
>
> So of interest are commits:
> - 5ca72c4f7c412c2002363218901eba5516c476b1
> - 08261d87f7d1b6253ab3223756625a5c74532293
> - 51906e779f2b13b38f8153774c4c7163d412ffd9
>
> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
>
> x86/MSI: Support multiple MSIs in presense of IRQ remapping
>
> The MSI specification has several constraints in comparison with
> MSI-X, most notable of them is the inability to configure MSIs
> independently. As a result, it is impossible to dispatch
> interrupts from different queues to different CPUs. This is
> largely devalues the support of multiple MSIs in SMP systems.
>
> Also, a necessity to allocate a contiguous block of vector
> numbers for devices capable of multiple MSIs might cause a
> considerable pressure on x86 interrupt vector allocator and
> could lead to fragmentation of the interrupt vectors space.
>
> This patch overcomes both drawbacks in presense of IRQ remapping
> and lets devices take advantage of multiple queues and per-IRQ
> affinity assignments.
>
> At least makes clear why baremetal does boot and xen doesn't:
>
> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
>
> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
Except that function in Xen is not run. that is b/c 
x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.

So a fix like this:
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 56ab749..47f8cca 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
*dev, int nvec, int type)
         int ret = 0;
         struct msi_desc *msidesc;

+       if (type == PCI_CAP_ID_MSI && nvec > 1)
+               return 1;
+
         list_for_each_entry(msidesc, &dev->msi_list, list) {
                 struct physdev_map_pirq map_irq;
                 domid_t domid;


(sorry about the paste getting messed up here) - ought to do it? As for 
example on one of my AMD machines there is no IOMMU, and this is where 
AHCI does work under baremetal but not under Xen.

We can future wise implement a better version of this to deal with 
multiple MSIs, but lets make sure to first get it booting.
> --
> Sander
>
>
>
>
>>> --
>>> Sander
>>>
>>>> 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 Feb 27 22:22:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22: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 1UApOV-00085v-6c; Wed, 27 Feb 2013 22:22:35 +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 1UApOT-00085q-H1
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 22:22:33 +0000
Received: from [85.158.139.83:3239] by server-15.bemta-5.messagelabs.com id
	0F/5D-22815-8278E215; Wed, 27 Feb 2013 22:22:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1362003750!27535654!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjQ2MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22176 invoked from network); 27 Feb 2013 22:22:31 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Feb 2013 22:22:31 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1RMMPw2019044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 27 Feb 2013 22:22:26 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
	r1RMMO4J012316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 22:22:24 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
	r1RMMO8v021747; Wed, 27 Feb 2013 16:22:24 -0600
Received: from [10.154.120.173] (/10.154.120.173)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 14:22:23 -0800
Message-ID: <512E871A.20706@oracle.com>
Date: Wed, 27 Feb 2013 17:22:18 -0500
From: konrad wilk <konrad.wilk@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
In-Reply-To: <171656525.20130227214153@eikelenboom.it>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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-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 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
>
>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>
>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>>>> find the origin of this return value by instrumenting the involved
>>>> call tree.
>>> Just wondering, is multiple msi's per device actually supported by xen ?
>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
>> use them and they work great with Xen.
>> BTW, this is merge:
>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
>> Merge: 266d7ad af8d102
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Tue Feb 19 19:07:27 2013 -0800
>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>      
>>      Pull x86/apic changes from Ingo Molnar:
>>       "Main changes:
>>      
>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>>           by all relevant maintainers, by Alexander Gordeev.
>>      
>>           The advantage is that multiple AHCI ports can have multiple MSI
>>           irqs assigned, and can thus spread to multiple CPUs.
>>      
>>           [ Drivers can make use of this new facility via the
>>             pci_enable_msi_block_auto() method ]
>
>
>> With MSI per device, the hypercall that ends up happening is:
>> PHYSDEVOP_map_pirq with:
>>     map_irq.domid = domid;
>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>>     map_irq.index = -1;
>>     map_irq.pirq = -1;
>>     map_irq.bus = dev->bus->number |
>>                   (pci_domain_nr(dev->bus) << 16);
>>     map_irq.devfn = dev->devfn;
>> Which would imply that we are doing this call multiple times?
>> (This is xen_initdom_setup_msi_irqs).
>> It looks like pci_enable_msi_block_auto is the multiple MSI one
>> and it should perculate down to xen_initdom_setup_msi_irqs.
>> Granted the xen_init.. does not do anything with the 'nvec' call.
>> So could I ask you try out your hunch by doing three things:
>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
>>       nvec has anything but 1 and in its loop instrument to
>>       see if it has more than on MSI attribute?
>>   2). The ahci driver has ahci_init_interrupts which only does
>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>>      seperatly from 1).
>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
>
> So of interest are commits:
> - 5ca72c4f7c412c2002363218901eba5516c476b1
> - 08261d87f7d1b6253ab3223756625a5c74532293
> - 51906e779f2b13b38f8153774c4c7163d412ffd9
>
> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
>
> x86/MSI: Support multiple MSIs in presense of IRQ remapping
>
> The MSI specification has several constraints in comparison with
> MSI-X, most notable of them is the inability to configure MSIs
> independently. As a result, it is impossible to dispatch
> interrupts from different queues to different CPUs. This is
> largely devalues the support of multiple MSIs in SMP systems.
>
> Also, a necessity to allocate a contiguous block of vector
> numbers for devices capable of multiple MSIs might cause a
> considerable pressure on x86 interrupt vector allocator and
> could lead to fragmentation of the interrupt vectors space.
>
> This patch overcomes both drawbacks in presense of IRQ remapping
> and lets devices take advantage of multiple queues and per-IRQ
> affinity assignments.
>
> At least makes clear why baremetal does boot and xen doesn't:
>
> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
>
> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
Except that function in Xen is not run. that is b/c 
x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.

So a fix like this:
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 56ab749..47f8cca 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
*dev, int nvec, int type)
         int ret = 0;
         struct msi_desc *msidesc;

+       if (type == PCI_CAP_ID_MSI && nvec > 1)
+               return 1;
+
         list_for_each_entry(msidesc, &dev->msi_list, list) {
                 struct physdev_map_pirq map_irq;
                 domid_t domid;


(sorry about the paste getting messed up here) - ought to do it? As for 
example on one of my AMD machines there is no IOMMU, and this is where 
AHCI does work under baremetal but not under Xen.

We can future wise implement a better version of this to deal with 
multiple MSIs, but lets make sure to first get it booting.
> --
> Sander
>
>
>
>
>>> --
>>> Sander
>>>
>>>> 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 Feb 27 22:41:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22:41: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 1UApgh-0008OH-VX; Wed, 27 Feb 2013 22:41:23 +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 1UApgg-0008OC-5E
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 22:41:22 +0000
Received: from [193.109.254.147:7624] by server-5.bemta-14.messagelabs.com id
	08/8C-21539-19B8E215; Wed, 27 Feb 2013 22:41:21 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1362004877!9319004!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16897 invoked from network); 27 Feb 2013 22:41:19 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 22:41:19 -0000
Received: from anacreon.sc.intel.com (fmdmzpr03-ext.fm.intel.com
	[192.55.54.38]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1RMe67K011542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 14:40:06 -0800
Message-ID: <512E8B41.8000504@zytor.com>
Date: Wed, 27 Feb 2013 14:40:01 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
In-Reply-To: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
X-Enigmail-Version: 1.5
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, mingo@redhat.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Greg, policy opinion?

	-hpa

On 02/26/2013 03:57 PM, Boris Ostrovsky wrote:
> 
> ----- hpa@zytor.com wrote:
> 
>> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
>>> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
>>> kernel_map_pages() are not made visible (via TLB flush) immediately
>> if lazy
>>> MMU is on. In environments that support lazy MMU (e.g. Xen) this may
>> lead to
>>> fatal page faults, for example, when zap_pte_range() needs to
>> allocate pages
>>> in __tlb_remove_page() -> tlb_next_batch().
>>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> ---
>>>  arch/x86/mm/pageattr.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
>>> index ca1f1c2..7b3216e 100644
>>> --- a/arch/x86/mm/pageattr.c
>>> +++ b/arch/x86/mm/pageattr.c
>>> @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int
>> numpages, int enable)
>>>  	 * but that can deadlock->flush only current cpu:
>>>  	 */
>>>  	__flush_tlb_all();
>>> +
>>> +	arch_flush_lazy_mmu_mode();
>>>  }
>>>  
>>>  #ifdef CONFIG_HIBERNATION
>>>
>>
>> This sounds like a critical fix, i.e. a -stable candidate.  Am I
>> correct?
> 
> I considered copying stable but then I decided that this is a debugging feature
> --- kernel_map_pages() is only defined if CONFIG_DEBUG_PAGEALLOC is set and my
> thinking was that stable kernels usually don't do this.
> 
> 
> -boris
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 22:41:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 22:41: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 1UApgh-0008OH-VX; Wed, 27 Feb 2013 22:41:23 +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 1UApgg-0008OC-5E
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 22:41:22 +0000
Received: from [193.109.254.147:7624] by server-5.bemta-14.messagelabs.com id
	08/8C-21539-19B8E215; Wed, 27 Feb 2013 22:41:21 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1362004877!9319004!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16897 invoked from network); 27 Feb 2013 22:41:19 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 22:41:19 -0000
Received: from anacreon.sc.intel.com (fmdmzpr03-ext.fm.intel.com
	[192.55.54.38]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1RMe67K011542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 14:40:06 -0800
Message-ID: <512E8B41.8000504@zytor.com>
Date: Wed, 27 Feb 2013 14:40:01 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
In-Reply-To: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
X-Enigmail-Version: 1.5
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, mingo@redhat.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Greg, policy opinion?

	-hpa

On 02/26/2013 03:57 PM, Boris Ostrovsky wrote:
> 
> ----- hpa@zytor.com wrote:
> 
>> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
>>> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
>>> kernel_map_pages() are not made visible (via TLB flush) immediately
>> if lazy
>>> MMU is on. In environments that support lazy MMU (e.g. Xen) this may
>> lead to
>>> fatal page faults, for example, when zap_pte_range() needs to
>> allocate pages
>>> in __tlb_remove_page() -> tlb_next_batch().
>>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> ---
>>>  arch/x86/mm/pageattr.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
>>> index ca1f1c2..7b3216e 100644
>>> --- a/arch/x86/mm/pageattr.c
>>> +++ b/arch/x86/mm/pageattr.c
>>> @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int
>> numpages, int enable)
>>>  	 * but that can deadlock->flush only current cpu:
>>>  	 */
>>>  	__flush_tlb_all();
>>> +
>>> +	arch_flush_lazy_mmu_mode();
>>>  }
>>>  
>>>  #ifdef CONFIG_HIBERNATION
>>>
>>
>> This sounds like a critical fix, i.e. a -stable candidate.  Am I
>> correct?
> 
> I considered copying stable but then I decided that this is a debugging feature
> --- kernel_map_pages() is only defined if CONFIG_DEBUG_PAGEALLOC is set and my
> thinking was that stable kernels usually don't do this.
> 
> 
> -boris
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:00:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:00: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 1UApz2-0000MK-6c; Wed, 27 Feb 2013 23:00:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1UApz0-0000MF-Oc
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:00:18 +0000
Received: from [85.158.143.99:18634] by server-2.bemta-4.messagelabs.com id
	3E/B3-12656-1009E215; Wed, 27 Feb 2013 23:00:17 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1362006013!21945963!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8674 invoked from network); 27 Feb 2013 23:00:14 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 23:00:14 -0000
Received: by mail-pa0-f50.google.com with SMTP id fa11so729435pad.9
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 15:00:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=krgGtjzxk5Pkb6ZyzK9IbykqZilq/75/nrTujeRcdYk=;
	b=Foc+/BD7A1PXsFu0hHIkozIB8F1KRpCB4Mo+/XooO0/wRRr29y+6wzEwK3CTTgi8k6
	B11C99LJObc2KDTY7ActmlZxkn6Fa1WpY44aYoBtT0tCj/9kh2SLjfYc7KN/02EhVjf3
	4UEjc1rjhzrWrHWW6PMsYMtdW2weVr0QOIkxs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-gm-message-state;
	bh=krgGtjzxk5Pkb6ZyzK9IbykqZilq/75/nrTujeRcdYk=;
	b=Wlt668+aiMwh8z83NN9hZ5a7ZWAb7nNkUmKnAHgDs2IPJWDPV54l9K52Lkef70FuJb
	wUpgbwp7PJIxjakwsWpvjgz9sj1Cgq1vCcHRA7OGZrPZ+tv4S87FIOL+f9CwMdZjNbzc
	SwifboOwDM5jAdIBgIW0+suUk4qSVp9zkDxmB5GXkja/VKWV32KsTPe8fkCDUx7fT5he
	WkpdbX8GsIyxW3Epe5bLHjm8IzrZHgnR5N7ON3NFiueqbnWL6ceeKa3T/DAzWfa4Ck/8
	jEe9UaXFIYt+0xsuNIq+m1Qdr6Bv6qDb+YHL6aAnCBZvHLH7HXEEsE6t2lKQkpkkyaX+
	+gjA==
X-Received: by 10.67.5.168 with SMTP id cn8mr9971603pad.12.1362006012609;
	Wed, 27 Feb 2013 15:00:12 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id f9sm6791968paz.12.2013.02.27.15.00.10
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 15:00:11 -0800 (PST)
Date: Wed, 27 Feb 2013 15:00:09 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130227230009.GA32465@kroah.com>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E8B41.8000504@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmoqLE1jfWycERqZWmnEfEUhuoxTVWh0qPNAjAPj1FlyP01FMoMAQ6gwswmWjkHbT+oyvOd
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, mingo@redhat.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 02:40:01PM -0800, H. Peter Anvin wrote:
> Greg, policy opinion?
> 
> 	-hpa
> 
> On 02/26/2013 03:57 PM, Boris Ostrovsky wrote:
> > 
> > ----- hpa@zytor.com wrote:
> > 
> >> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> >>> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> >>> kernel_map_pages() are not made visible (via TLB flush) immediately
> >> if lazy
> >>> MMU is on. In environments that support lazy MMU (e.g. Xen) this may
> >> lead to
> >>> fatal page faults, for example, when zap_pte_range() needs to
> >> allocate pages
> >>> in __tlb_remove_page() -> tlb_next_batch().
> >>>
> >>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >>> ---
> >>>  arch/x86/mm/pageattr.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> >>> index ca1f1c2..7b3216e 100644
> >>> --- a/arch/x86/mm/pageattr.c
> >>> +++ b/arch/x86/mm/pageattr.c
> >>> @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int
> >> numpages, int enable)
> >>>  	 * but that can deadlock->flush only current cpu:
> >>>  	 */
> >>>  	__flush_tlb_all();
> >>> +
> >>> +	arch_flush_lazy_mmu_mode();
> >>>  }
> >>>  
> >>>  #ifdef CONFIG_HIBERNATION
> >>>
> >>
> >> This sounds like a critical fix, i.e. a -stable candidate.  Am I
> >> correct?
> > 
> > I considered copying stable but then I decided that this is a debugging feature
> > --- kernel_map_pages() is only defined if CONFIG_DEBUG_PAGEALLOC is set and my
> > thinking was that stable kernels usually don't do this.

"Stable" kernels are used all over the place, like in distros, which
might enable this.

I have no objection to taking this patch in a stable release, as it does
fix a real problem.

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:00:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:00: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 1UApz2-0000MK-6c; Wed, 27 Feb 2013 23:00:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1UApz0-0000MF-Oc
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:00:18 +0000
Received: from [85.158.143.99:18634] by server-2.bemta-4.messagelabs.com id
	3E/B3-12656-1009E215; Wed, 27 Feb 2013 23:00:17 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1362006013!21945963!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8674 invoked from network); 27 Feb 2013 23:00:14 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Feb 2013 23:00:14 -0000
Received: by mail-pa0-f50.google.com with SMTP id fa11so729435pad.9
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 15:00:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linuxfoundation.org; s=google;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent; bh=krgGtjzxk5Pkb6ZyzK9IbykqZilq/75/nrTujeRcdYk=;
	b=Foc+/BD7A1PXsFu0hHIkozIB8F1KRpCB4Mo+/XooO0/wRRr29y+6wzEwK3CTTgi8k6
	B11C99LJObc2KDTY7ActmlZxkn6Fa1WpY44aYoBtT0tCj/9kh2SLjfYc7KN/02EhVjf3
	4UEjc1rjhzrWrHWW6PMsYMtdW2weVr0QOIkxs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent:x-gm-message-state;
	bh=krgGtjzxk5Pkb6ZyzK9IbykqZilq/75/nrTujeRcdYk=;
	b=Wlt668+aiMwh8z83NN9hZ5a7ZWAb7nNkUmKnAHgDs2IPJWDPV54l9K52Lkef70FuJb
	wUpgbwp7PJIxjakwsWpvjgz9sj1Cgq1vCcHRA7OGZrPZ+tv4S87FIOL+f9CwMdZjNbzc
	SwifboOwDM5jAdIBgIW0+suUk4qSVp9zkDxmB5GXkja/VKWV32KsTPe8fkCDUx7fT5he
	WkpdbX8GsIyxW3Epe5bLHjm8IzrZHgnR5N7ON3NFiueqbnWL6ceeKa3T/DAzWfa4Ck/8
	jEe9UaXFIYt+0xsuNIq+m1Qdr6Bv6qDb+YHL6aAnCBZvHLH7HXEEsE6t2lKQkpkkyaX+
	+gjA==
X-Received: by 10.67.5.168 with SMTP id cn8mr9971603pad.12.1362006012609;
	Wed, 27 Feb 2013 15:00:12 -0800 (PST)
Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net. [76.28.172.123])
	by mx.google.com with ESMTPS id f9sm6791968paz.12.2013.02.27.15.00.10
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 15:00:11 -0800 (PST)
Date: Wed, 27 Feb 2013 15:00:09 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130227230009.GA32465@kroah.com>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E8B41.8000504@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmoqLE1jfWycERqZWmnEfEUhuoxTVWh0qPNAjAPj1FlyP01FMoMAQ6gwswmWjkHbT+oyvOd
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, mingo@redhat.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 02:40:01PM -0800, H. Peter Anvin wrote:
> Greg, policy opinion?
> 
> 	-hpa
> 
> On 02/26/2013 03:57 PM, Boris Ostrovsky wrote:
> > 
> > ----- hpa@zytor.com wrote:
> > 
> >> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> >>> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> >>> kernel_map_pages() are not made visible (via TLB flush) immediately
> >> if lazy
> >>> MMU is on. In environments that support lazy MMU (e.g. Xen) this may
> >> lead to
> >>> fatal page faults, for example, when zap_pte_range() needs to
> >> allocate pages
> >>> in __tlb_remove_page() -> tlb_next_batch().
> >>>
> >>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >>> ---
> >>>  arch/x86/mm/pageattr.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> >>> index ca1f1c2..7b3216e 100644
> >>> --- a/arch/x86/mm/pageattr.c
> >>> +++ b/arch/x86/mm/pageattr.c
> >>> @@ -1369,6 +1369,8 @@ void kernel_map_pages(struct page *page, int
> >> numpages, int enable)
> >>>  	 * but that can deadlock->flush only current cpu:
> >>>  	 */
> >>>  	__flush_tlb_all();
> >>> +
> >>> +	arch_flush_lazy_mmu_mode();
> >>>  }
> >>>  
> >>>  #ifdef CONFIG_HIBERNATION
> >>>
> >>
> >> This sounds like a critical fix, i.e. a -stable candidate.  Am I
> >> correct?
> > 
> > I considered copying stable but then I decided that this is a debugging feature
> > --- kernel_map_pages() is only defined if CONFIG_DEBUG_PAGEALLOC is set and my
> > thinking was that stable kernels usually don't do this.

"Stable" kernels are used all over the place, like in distros, which
might enable this.

I have no objection to taking this patch in a stable release, as it does
fix a real problem.

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23: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 1UAq7I-0000cC-73; Wed, 27 Feb 2013 23:08:52 +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 1UAq7H-0000c7-HR
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:08:51 +0000
Received: from [85.158.139.83:6950] by server-5.bemta-5.messagelabs.com id
	0B/B9-02762-2029E215; Wed, 27 Feb 2013 23:08:50 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1362006528!27612170!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16405 invoked from network); 27 Feb 2013 23:08:50 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 23:08:50 -0000
Received: from anacreon.sc.intel.com (jfdmzpr04-ext.jf.intel.com
	[134.134.137.73]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1RN7e4n019572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 15:07:41 -0800
Message-ID: <512E91B7.6060102@zytor.com>
Date: Wed, 27 Feb 2013 15:07:35 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
In-Reply-To: <20130227230009.GA32465@kroah.com>
X-Enigmail-Version: 1.5
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, mingo@redhat.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/27/2013 03:00 PM, Greg KH wrote:
> 
> "Stable" kernels are used all over the place, like in distros, which
> might enable this.
> 
> I have no objection to taking this patch in a stable release, as it does
> fix a real problem.
> 

OK.  I will queue it up in the next fixes (tip:x86/urgent) batch to Linus.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:09:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23: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 1UAq7I-0000cC-73; Wed, 27 Feb 2013 23:08:52 +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 1UAq7H-0000c7-HR
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:08:51 +0000
Received: from [85.158.139.83:6950] by server-5.bemta-5.messagelabs.com id
	0B/B9-02762-2029E215; Wed, 27 Feb 2013 23:08:50 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1362006528!27612170!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16405 invoked from network); 27 Feb 2013 23:08:50 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Feb 2013 23:08:50 -0000
Received: from anacreon.sc.intel.com (jfdmzpr04-ext.jf.intel.com
	[134.134.137.73]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1RN7e4n019572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Wed, 27 Feb 2013 15:07:41 -0800
Message-ID: <512E91B7.6060102@zytor.com>
Date: Wed, 27 Feb 2013 15:07:35 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Greg KH <gregkh@linuxfoundation.org>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
In-Reply-To: <20130227230009.GA32465@kroah.com>
X-Enigmail-Version: 1.5
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org, mingo@redhat.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, tglx@linutronix.de
Subject: Re: [Xen-devel] [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC
	is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/27/2013 03:00 PM, Greg KH wrote:
> 
> "Stable" kernels are used all over the place, like in distros, which
> might enable this.
> 
> I have no objection to taking this patch in a stable release, as it does
> fix a real problem.
> 

OK.  I will queue it up in the next fixes (tip:x86/urgent) batch to Linus.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:19:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:19: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 1UAqHd-0000s6-BS; Wed, 27 Feb 2013 23:19:33 +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 1UAqHb-0000s1-OS
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:19:31 +0000
Received: from [193.109.254.147:60955] by server-8.bemta-14.messagelabs.com id
	99/12-17325-3849E215; Wed, 27 Feb 2013 23:19:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1362007169!9321790!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ4NDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24044 invoked from network); 27 Feb 2013 23:19:30 -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;
	27 Feb 2013 23:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,751,1355097600"; 
   d="scan'208";a="9642877"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 23:19:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 18:19:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAqHY-0006AW-1R;
	Wed, 27 Feb 2013 23:19:28 +0000
Date: Wed, 27 Feb 2013 23:19:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20130227231927.GA13549@zion.uk.xensource.com>
References: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
	<CD5413CE.4CD6E%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CD5413CE.4CD6E%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 Wed, Feb 27, 2013 at 07:49:34PM +0000, Keir Fraser wrote:
> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> >>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> >> Keir, Jan, Ian and David, are you happy with this design in general? I would
> >> like to have explicit ACK / NACK on this if possible, as feature freeze for
> >> 4.3 is quite close now.
> > 
> > The patches look reasonable (apart from the comments I just gave
> > on some of them), but other than Keir I'm not that eager to see this
> > one go in for 4.3 in order to then likely be replaced by an
> > implementation of David's design in the 4.4 cycle.
> 
> If this went in for 4.3, a re-design would really have to be implemented and
> measurably prove its worth to make it in as another replacement.
> 

Even this design does not go in for 4.3, any new design will still have
to be implemented and measurable prove its worth, as with this design.

The value of this design lies in that a) it's straight forward, easy to
prove its correctness (or wrongness), b) it meets our need for now, c)
a new interface will always be necessary, be it this design or any other
design, d) it buys time for any better designs to become mature.

I understand your (and Jan's) concern for burdens of maintaining
different ABIs, that's why the interface has been made to allow user to
query enabled / supported ABIs. If we need to add / remove ABIs, it's
just a matter of setting some feature bits.

I don't mean to push this design to get merged, it's up to maintainers
to decide. Actually I'm fine with any decision. Explicit Ack / Nack will
help me arrange my future work better.


Wei.

>  -- Keir
> 
> > Jan
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:19:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:19: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 1UAqHd-0000s6-BS; Wed, 27 Feb 2013 23:19:33 +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 1UAqHb-0000s1-OS
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:19:31 +0000
Received: from [193.109.254.147:60955] by server-8.bemta-14.messagelabs.com id
	99/12-17325-3849E215; Wed, 27 Feb 2013 23:19:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1362007169!9321790!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ4NDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24044 invoked from network); 27 Feb 2013 23:19:30 -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;
	27 Feb 2013 23:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,751,1355097600"; 
   d="scan'208";a="9642877"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	27 Feb 2013 23:19:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 27 Feb 2013 18:19:28 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UAqHY-0006AW-1R;
	Wed, 27 Feb 2013 23:19:28 +0000
Date: Wed, 27 Feb 2013 23:19:28 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20130227231927.GA13549@zion.uk.xensource.com>
References: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
	<CD5413CE.4CD6E%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CD5413CE.4CD6E%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 Wed, Feb 27, 2013 at 07:49:34PM +0000, Keir Fraser wrote:
> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> >>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> >> Keir, Jan, Ian and David, are you happy with this design in general? I would
> >> like to have explicit ACK / NACK on this if possible, as feature freeze for
> >> 4.3 is quite close now.
> > 
> > The patches look reasonable (apart from the comments I just gave
> > on some of them), but other than Keir I'm not that eager to see this
> > one go in for 4.3 in order to then likely be replaced by an
> > implementation of David's design in the 4.4 cycle.
> 
> If this went in for 4.3, a re-design would really have to be implemented and
> measurably prove its worth to make it in as another replacement.
> 

Even this design does not go in for 4.3, any new design will still have
to be implemented and measurable prove its worth, as with this design.

The value of this design lies in that a) it's straight forward, easy to
prove its correctness (or wrongness), b) it meets our need for now, c)
a new interface will always be necessary, be it this design or any other
design, d) it buys time for any better designs to become mature.

I understand your (and Jan's) concern for burdens of maintaining
different ABIs, that's why the interface has been made to allow user to
query enabled / supported ABIs. If we need to add / remove ABIs, it's
just a matter of setting some feature bits.

I don't mean to push this design to get merged, it's up to maintainers
to decide. Actually I'm fine with any decision. Explicit Ack / Nack will
help me arrange my future work better.


Wei.

>  -- Keir
> 
> > Jan
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Feb 27 23:47:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:47: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 1UAqhx-0001Mi-O2; Wed, 27 Feb 2013 23:46:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UAqhv-0001Mb-Hy
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 23:46:43 +0000
Received: from [85.158.137.99:56675] by server-16.bemta-3.messagelabs.com id
	A6/BF-20692-2EA9E215; Wed, 27 Feb 2013 23:46:42 +0000
X-Env-Sender: sahilsuneja@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1362008800!13714203!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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31929 invoked from network); 27 Feb 2013 23:46:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 23:46:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UAqhr-0003cx-LI
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 15:46:39 -0800
Date: Wed, 27 Feb 2013 15:46:39 -0800 (PST)
From: sahilsuneja <sahilsuneja@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1362008799652-5714493.post@n5.nabble.com>
In-Reply-To: <1361840672591-5714431.post@n5.nabble.com>
References: <1361840672591-5714431.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Issues with Xenpaging in Xen-4.2.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

sahilsuneja wrote
> Hi,
> 
> I know Xenpaging is still at an experimental stage, but I still wanted to
> test it out. Sadly, I could not get it to work reliably.
> 
> I have an AMD RVI enabled linux 3.2 host, and I am using linux 2.6.35-22
> HVM guests. After booting a few guests normally upto the host RAM limit, I
> do the following to enable paging for a few guests:
/
>>/usr/lib/xen/bin/xenpaging -f /var/lib/xen/xenpaging/pagefile-hvm-guest -d
1 &
>>xenstore-write /local/domain/1/memory/target-tot_pages $((1024*512))
/
> 
> (here '1' is the dom_id and pagefile-hvm-guest is the backing paging file
> for the hvm guest)
> 
> I am then able to boot more VMs and I can see the corresponding pagefiles
> increase in size for the xenpaging enabled guests.
> 
> The problem is when I go back to the guests on which I enabled xenpaging,
> I see the following errors when I run any basic commands like vim, top,
> less /proc/meminfo:
/
> xc: error: Error populating page 100: Internal error
> xc: error: Error loading 100 during page-in (22 = Invalid argument):
> Internal error
/
> 
> This happens even when there is paged-out memory from other guests to be
> had, and the system is not out of RAM for paging in guest's memory.
> 
> It seems like a page-in error on gfn 100, but that is strange as, from I
> what I gathered from the xenpaging code, policy_default.c starts paging
> only after half of the guest's gfns : current_gfn = max_pages / 2 (inside
> policy_default.c: policy_init())
> 
> I was expecting there to be other stability issues rather that this kind
> of an error.
> 
> Could someone please help me understand this and let me know if I am doing
> something incorrectly. 
> 
> Also, there do not seem to be any interesting messages in xm dmesg or in
> /var/log/xen*.
> 
> Thanks,
> 
> Sahil Suneja
> Ph.D. Student
> University of Toronto





--
View this message in context: http://xen.1045712.n5.nabble.com/Issues-with-Xenpaging-in-Xen-4-2-1-tp5714431p5714493.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 Feb 27 23:47:11 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:47: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 1UAqhx-0001Mi-O2; Wed, 27 Feb 2013 23:46:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UAqhv-0001Mb-Hy
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 23:46:43 +0000
Received: from [85.158.137.99:56675] by server-16.bemta-3.messagelabs.com id
	A6/BF-20692-2EA9E215; Wed, 27 Feb 2013 23:46:42 +0000
X-Env-Sender: sahilsuneja@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1362008800!13714203!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-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31929 invoked from network); 27 Feb 2013 23:46:41 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-5.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 23:46:41 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UAqhr-0003cx-LI
	for xen-devel@lists.xensource.com; Wed, 27 Feb 2013 15:46:39 -0800
Date: Wed, 27 Feb 2013 15:46:39 -0800 (PST)
From: sahilsuneja <sahilsuneja@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1362008799652-5714493.post@n5.nabble.com>
In-Reply-To: <1361840672591-5714431.post@n5.nabble.com>
References: <1361840672591-5714431.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Issues with Xenpaging in Xen-4.2.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

sahilsuneja wrote
> Hi,
> 
> I know Xenpaging is still at an experimental stage, but I still wanted to
> test it out. Sadly, I could not get it to work reliably.
> 
> I have an AMD RVI enabled linux 3.2 host, and I am using linux 2.6.35-22
> HVM guests. After booting a few guests normally upto the host RAM limit, I
> do the following to enable paging for a few guests:
/
>>/usr/lib/xen/bin/xenpaging -f /var/lib/xen/xenpaging/pagefile-hvm-guest -d
1 &
>>xenstore-write /local/domain/1/memory/target-tot_pages $((1024*512))
/
> 
> (here '1' is the dom_id and pagefile-hvm-guest is the backing paging file
> for the hvm guest)
> 
> I am then able to boot more VMs and I can see the corresponding pagefiles
> increase in size for the xenpaging enabled guests.
> 
> The problem is when I go back to the guests on which I enabled xenpaging,
> I see the following errors when I run any basic commands like vim, top,
> less /proc/meminfo:
/
> xc: error: Error populating page 100: Internal error
> xc: error: Error loading 100 during page-in (22 = Invalid argument):
> Internal error
/
> 
> This happens even when there is paged-out memory from other guests to be
> had, and the system is not out of RAM for paging in guest's memory.
> 
> It seems like a page-in error on gfn 100, but that is strange as, from I
> what I gathered from the xenpaging code, policy_default.c starts paging
> only after half of the guest's gfns : current_gfn = max_pages / 2 (inside
> policy_default.c: policy_init())
> 
> I was expecting there to be other stability issues rather that this kind
> of an error.
> 
> Could someone please help me understand this and let me know if I am doing
> something incorrectly. 
> 
> Also, there do not seem to be any interesting messages in xm dmesg or in
> /var/log/xen*.
> 
> Thanks,
> 
> Sahil Suneja
> Ph.D. Student
> University of Toronto





--
View this message in context: http://xen.1045712.n5.nabble.com/Issues-with-Xenpaging-in-Xen-4-2-1-tp5714431p5714493.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 Feb 27 23:58:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:58: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 1UAqsc-0001cq-U6; Wed, 27 Feb 2013 23:57:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAqsb-0001cl-PC
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:57:46 +0000
Received: from [85.158.137.99:23768] by server-2.bemta-3.messagelabs.com id
	DB/24-05208-A6D9E215; Wed, 27 Feb 2013 23:57:30 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-217.messagelabs.com!1362009448!15298548!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18722 invoked from network); 27 Feb 2013 23:57:28 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-9.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 23:57:28 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:52211 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 1UAqqB-0005yP-Tt; Thu, 28 Feb 2013 00:55:15 +0100
Date: Thu, 28 Feb 2013 00:57:24 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <123964736.20130228005724@eikelenboom.it>
To: konrad wilk <konrad.wilk@oracle.com>
In-Reply-To: <512E871A.20706@oracle.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
	<512E871A.20706@oracle.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 11:22:18 PM, you wrote:


> On 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
>> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
>>
>>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>>
>>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>>>>> find the origin of this return value by instrumenting the involved
>>>>> call tree.
>>>> Just wondering, is multiple msi's per device actually supported by xen ?
>>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
>>> use them and they work great with Xen.
>>> BTW, this is merge:
>>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
>>> Merge: 266d7ad af8d102
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date:   Tue Feb 19 19:07:27 2013 -0800
>>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>>      
>>>      Pull x86/apic changes from Ingo Molnar:
>>>       "Main changes:
>>>      
>>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>>>           by all relevant maintainers, by Alexander Gordeev.
>>>      
>>>           The advantage is that multiple AHCI ports can have multiple MSI
>>>           irqs assigned, and can thus spread to multiple CPUs.
>>>      
>>>           [ Drivers can make use of this new facility via the
>>>             pci_enable_msi_block_auto() method ]
>>
>>
>>> With MSI per device, the hypercall that ends up happening is:
>>> PHYSDEVOP_map_pirq with:
>>>     map_irq.domid = domid;
>>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>>>     map_irq.index = -1;
>>>     map_irq.pirq = -1;
>>>     map_irq.bus = dev->bus->number |
>>>                   (pci_domain_nr(dev->bus) << 16);
>>>     map_irq.devfn = dev->devfn;
>>> Which would imply that we are doing this call multiple times?
>>> (This is xen_initdom_setup_msi_irqs).
>>> It looks like pci_enable_msi_block_auto is the multiple MSI one
>>> and it should perculate down to xen_initdom_setup_msi_irqs.
>>> Granted the xen_init.. does not do anything with the 'nvec' call.
>>> So could I ask you try out your hunch by doing three things:
>>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
>>>       nvec has anything but 1 and in its loop instrument to
>>>       see if it has more than on MSI attribute?
>>>   2). The ahci driver has ahci_init_interrupts which only does
>>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>>>      seperatly from 1).
>>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
>>
>> So of interest are commits:
>> - 5ca72c4f7c412c2002363218901eba5516c476b1
>> - 08261d87f7d1b6253ab3223756625a5c74532293
>> - 51906e779f2b13b38f8153774c4c7163d412ffd9
>>
>> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
>>
>> x86/MSI: Support multiple MSIs in presense of IRQ remapping
>>
>> The MSI specification has several constraints in comparison with
>> MSI-X, most notable of them is the inability to configure MSIs
>> independently. As a result, it is impossible to dispatch
>> interrupts from different queues to different CPUs. This is
>> largely devalues the support of multiple MSIs in SMP systems.
>>
>> Also, a necessity to allocate a contiguous block of vector
>> numbers for devices capable of multiple MSIs might cause a
>> considerable pressure on x86 interrupt vector allocator and
>> could lead to fragmentation of the interrupt vectors space.
>>
>> This patch overcomes both drawbacks in presense of IRQ remapping
>> and lets devices take advantage of multiple queues and per-IRQ
>> affinity assignments.
>>
>> At least makes clear why baremetal does boot and xen doesn't:
>>
>> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
>>
>> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
>> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
> Except that function in Xen is not run. that is b/c 
> x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
> While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.

> So a fix like this:
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 56ab749..47f8cca 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
> *dev, int nvec, int type)
>          int ret = 0;
>          struct msi_desc *msidesc;

> +       if (type == PCI_CAP_ID_MSI && nvec > 1)
> +               return 1;
> +
>          list_for_each_entry(msidesc, &dev->msi_list, list) {
>                  struct physdev_map_pirq map_irq;
>                  domid_t domid;


> (sorry about the paste getting messed up here) - ought to do it? As for 
> example on one of my AMD machines there is no IOMMU, and this is where 
> AHCI does work under baremetal but not under Xen.

Yes it boots again :-)

[   37.742109] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
[   37.773491] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
[   37.798862] ahci 0000:00:11.0: SE | ahci_init_one start
[   37.822040] ahci 0000:00:11.0: version 3.0
[   37.841606] xen: registering gsi 19 triggering 0 polarity 1
[   37.865577] xen: --> pirq=19 -> irq=19 (gsi=19)
[   37.913087] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
[   37.938519] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
[   37.974447] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 4 type:5
[   38.001806] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 1 type:5
[   38.029026] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:1
[   38.057960] ahci 0000:00:11.0: SE | n_msis: 1
[   38.078065] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
[   38.112045] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
[   38.139426] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
[   38.170664] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
[   38.201684] ahci 0000:00:11.0: SE | me here 1
[   38.221977] ahci 0000:00:11.0: SE | me here 2
[   38.244756] scsi0 : ahci
[   38.259700] scsi1 : ahci
[   38.274411] scsi2 : ahci
[   38.289278] scsi3 : ahci
[   38.303718] ata1: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff100 irq 121
[   38.332566] ata2: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff180 irq 121
[   38.361366] ata3: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff200 irq 121
[   38.390080] ata4: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff280 irq 121
[   38.418787] really_probe: dev->bus->probe(0000:00:11.0) ret: 0
[   38.442420] really_probe: 0000:00:11.0 done ret: 1


> We can future wise implement a better version of this to deal with 
> multiple MSIs, but lets make sure to first get it booting.
>> --
>> Sander
>>
>>
>>
>>
>>>> --
>>>> Sander
>>>>
>>>>> 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 Feb 27 23:58:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 27 Feb 2013 23:58: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 1UAqsc-0001cq-U6; Wed, 27 Feb 2013 23:57:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAqsb-0001cl-PC
	for xen-devel@lists.xen.org; Wed, 27 Feb 2013 23:57:46 +0000
Received: from [85.158.137.99:23768] by server-2.bemta-3.messagelabs.com id
	DB/24-05208-A6D9E215; Wed, 27 Feb 2013 23:57:30 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-217.messagelabs.com!1362009448!15298548!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18722 invoked from network); 27 Feb 2013 23:57:28 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-9.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Feb 2013 23:57:28 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:52211 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 1UAqqB-0005yP-Tt; Thu, 28 Feb 2013 00:55:15 +0100
Date: Thu, 28 Feb 2013 00:57:24 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <123964736.20130228005724@eikelenboom.it>
To: konrad wilk <konrad.wilk@oracle.com>
In-Reply-To: <512E871A.20706@oracle.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
	<512E871A.20706@oracle.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Wednesday, February 27, 2013, 11:22:18 PM, you wrote:


> On 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
>> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
>>
>>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>>
>>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>>>>> find the origin of this return value by instrumenting the involved
>>>>> call tree.
>>>> Just wondering, is multiple msi's per device actually supported by xen ?
>>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
>>> use them and they work great with Xen.
>>> BTW, this is merge:
>>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
>>> Merge: 266d7ad af8d102
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date:   Tue Feb 19 19:07:27 2013 -0800
>>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>>      
>>>      Pull x86/apic changes from Ingo Molnar:
>>>       "Main changes:
>>>      
>>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>>>           by all relevant maintainers, by Alexander Gordeev.
>>>      
>>>           The advantage is that multiple AHCI ports can have multiple MSI
>>>           irqs assigned, and can thus spread to multiple CPUs.
>>>      
>>>           [ Drivers can make use of this new facility via the
>>>             pci_enable_msi_block_auto() method ]
>>
>>
>>> With MSI per device, the hypercall that ends up happening is:
>>> PHYSDEVOP_map_pirq with:
>>>     map_irq.domid = domid;
>>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>>>     map_irq.index = -1;
>>>     map_irq.pirq = -1;
>>>     map_irq.bus = dev->bus->number |
>>>                   (pci_domain_nr(dev->bus) << 16);
>>>     map_irq.devfn = dev->devfn;
>>> Which would imply that we are doing this call multiple times?
>>> (This is xen_initdom_setup_msi_irqs).
>>> It looks like pci_enable_msi_block_auto is the multiple MSI one
>>> and it should perculate down to xen_initdom_setup_msi_irqs.
>>> Granted the xen_init.. does not do anything with the 'nvec' call.
>>> So could I ask you try out your hunch by doing three things:
>>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
>>>       nvec has anything but 1 and in its loop instrument to
>>>       see if it has more than on MSI attribute?
>>>   2). The ahci driver has ahci_init_interrupts which only does
>>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>>>      seperatly from 1).
>>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
>>
>> So of interest are commits:
>> - 5ca72c4f7c412c2002363218901eba5516c476b1
>> - 08261d87f7d1b6253ab3223756625a5c74532293
>> - 51906e779f2b13b38f8153774c4c7163d412ffd9
>>
>> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
>>
>> x86/MSI: Support multiple MSIs in presense of IRQ remapping
>>
>> The MSI specification has several constraints in comparison with
>> MSI-X, most notable of them is the inability to configure MSIs
>> independently. As a result, it is impossible to dispatch
>> interrupts from different queues to different CPUs. This is
>> largely devalues the support of multiple MSIs in SMP systems.
>>
>> Also, a necessity to allocate a contiguous block of vector
>> numbers for devices capable of multiple MSIs might cause a
>> considerable pressure on x86 interrupt vector allocator and
>> could lead to fragmentation of the interrupt vectors space.
>>
>> This patch overcomes both drawbacks in presense of IRQ remapping
>> and lets devices take advantage of multiple queues and per-IRQ
>> affinity assignments.
>>
>> At least makes clear why baremetal does boot and xen doesn't:
>>
>> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
>>
>> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
>> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
> Except that function in Xen is not run. that is b/c 
> x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
> While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.

> So a fix like this:
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 56ab749..47f8cca 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
> *dev, int nvec, int type)
>          int ret = 0;
>          struct msi_desc *msidesc;

> +       if (type == PCI_CAP_ID_MSI && nvec > 1)
> +               return 1;
> +
>          list_for_each_entry(msidesc, &dev->msi_list, list) {
>                  struct physdev_map_pirq map_irq;
>                  domid_t domid;


> (sorry about the paste getting messed up here) - ought to do it? As for 
> example on one of my AMD machines there is no IOMMU, and this is where 
> AHCI does work under baremetal but not under Xen.

Yes it boots again :-)

[   37.742109] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
[   37.773491] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
[   37.798862] ahci 0000:00:11.0: SE | ahci_init_one start
[   37.822040] ahci 0000:00:11.0: version 3.0
[   37.841606] xen: registering gsi 19 triggering 0 polarity 1
[   37.865577] xen: --> pirq=19 -> irq=19 (gsi=19)
[   37.913087] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
[   37.938519] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
[   37.974447] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 4 type:5
[   38.001806] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 1 type:5
[   38.029026] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:1
[   38.057960] ahci 0000:00:11.0: SE | n_msis: 1
[   38.078065] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
[   38.112045] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
[   38.139426] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
[   38.170664] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
[   38.201684] ahci 0000:00:11.0: SE | me here 1
[   38.221977] ahci 0000:00:11.0: SE | me here 2
[   38.244756] scsi0 : ahci
[   38.259700] scsi1 : ahci
[   38.274411] scsi2 : ahci
[   38.289278] scsi3 : ahci
[   38.303718] ata1: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff100 irq 121
[   38.332566] ata2: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff180 irq 121
[   38.361366] ata3: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff200 irq 121
[   38.390080] ata4: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff280 irq 121
[   38.418787] really_probe: dev->bus->probe(0000:00:11.0) ret: 0
[   38.442420] really_probe: 0000:00:11.0 done ret: 1


> We can future wise implement a better version of this to deal with 
> multiple MSIs, but lets make sure to first get it booting.
>> --
>> Sander
>>
>>
>>
>>
>>>> --
>>>> Sander
>>>>
>>>>> 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 Thu Feb 28 00:08:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 00: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 1UAr29-0002K1-4h; Thu, 28 Feb 2013 00:07:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UAr28-0002Jw-AY
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 00:07:36 +0000
Received: from [193.109.254.147:10629] by server-13.bemta-14.messagelabs.com
	id 82/44-30639-7CF9E215; Thu, 28 Feb 2013 00:07:35 +0000
X-Env-Sender: sahilsuneja@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1362010054!2246743!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22919 invoked from network); 28 Feb 2013 00:07:35 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 00:07:35 -0000
Received: by mail-wi0-f178.google.com with SMTP id hq4so1425140wib.17
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 16:07:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:content-type;
	bh=1NGkPbxRY89ozhMYS267V4WX78dmV+URgxxxoBs2jqk=;
	b=Kw4Jkbuo6enYxBYAym/LVkj3hmHSnAB0kbqhz2WPfDigl86iSRlDAFM8X+cyd8eaka
	J+rswEr9HOWTvmFLG6yzTC3SwFW1i5257bHsSE8tqUoH1ssFqzIZHAgIRkyD/dN9Iz4d
	0uu475EVMjcrhbRZu82Dlzj1NMgiN7AERzRZVcshjr0VbQVqFRvwd0Sor1MbAmYIysP7
	jp1KaipZ6N1UXEEhv8Vsf2G6HNCdFkVTIUzFUcd0Rol3xEOicG5CTD2Lp0U2Yy9NKIKh
	kAR7TICvMkzfOqWjEl7l/M25jmzyKxo7f68e7jScmkTfZwq7VVW2rW/95g5ZJeYam2Bm
	9FMg==
X-Received: by 10.194.123.130 with SMTP id ma2mr7313546wjb.46.1362010054662;
	Wed, 27 Feb 2013 16:07:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.42.194 with HTTP; Wed, 27 Feb 2013 16:07:14 -0800 (PST)
In-Reply-To: <CALOK3vdqwj-ZNOi_0uvarEorsZ1JaB+bfNXkbfGGLFB8gxFUuw@mail.gmail.com>
References: <CALOK3vdqwj-ZNOi_0uvarEorsZ1JaB+bfNXkbfGGLFB8gxFUuw@mail.gmail.com>
From: Sahil Suneja <sahilsuneja@gmail.com>
Date: Wed, 27 Feb 2013 19:07:14 -0500
Message-ID: <CALOK3vd4dQLAhmQDKc=oJJ58G=98WMyYL+6q3R=Mrohtjbz2Dg@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issues with Xenpaging in Xen-4.2.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

> The pvops kernel may not have all required changes to run xenpaging in
> dom0. Maybe 3.8 already has these changes. If in doubt try the
> SLES/openSuSE kernels as dom0, their backend drivers can deal with
> paged granttable entries.

Thanks a lot Olaf!
Confirming that linux 3.8 as dom0 still has the same xenpaging page-in
error wrt gfn #100, but opensuse 12.3 rc1 kernel (linux 3.7.9-1.4-xen)
has a much more stable xenpaging, and a much more rich xen-config
kernel build option set.
Although, I am still not clear what the error meant to begin with.

Best,
Sahil

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 00:08:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 00: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 1UAr29-0002K1-4h; Thu, 28 Feb 2013 00:07:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sahilsuneja@gmail.com>) id 1UAr28-0002Jw-AY
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 00:07:36 +0000
Received: from [193.109.254.147:10629] by server-13.bemta-14.messagelabs.com
	id 82/44-30639-7CF9E215; Thu, 28 Feb 2013 00:07:35 +0000
X-Env-Sender: sahilsuneja@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1362010054!2246743!1
X-Originating-IP: [209.85.212.178]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22919 invoked from network); 28 Feb 2013 00:07:35 -0000
Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com)
	(209.85.212.178)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 00:07:35 -0000
Received: by mail-wi0-f178.google.com with SMTP id hq4so1425140wib.17
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 16:07:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:content-type;
	bh=1NGkPbxRY89ozhMYS267V4WX78dmV+URgxxxoBs2jqk=;
	b=Kw4Jkbuo6enYxBYAym/LVkj3hmHSnAB0kbqhz2WPfDigl86iSRlDAFM8X+cyd8eaka
	J+rswEr9HOWTvmFLG6yzTC3SwFW1i5257bHsSE8tqUoH1ssFqzIZHAgIRkyD/dN9Iz4d
	0uu475EVMjcrhbRZu82Dlzj1NMgiN7AERzRZVcshjr0VbQVqFRvwd0Sor1MbAmYIysP7
	jp1KaipZ6N1UXEEhv8Vsf2G6HNCdFkVTIUzFUcd0Rol3xEOicG5CTD2Lp0U2Yy9NKIKh
	kAR7TICvMkzfOqWjEl7l/M25jmzyKxo7f68e7jScmkTfZwq7VVW2rW/95g5ZJeYam2Bm
	9FMg==
X-Received: by 10.194.123.130 with SMTP id ma2mr7313546wjb.46.1362010054662;
	Wed, 27 Feb 2013 16:07:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.42.194 with HTTP; Wed, 27 Feb 2013 16:07:14 -0800 (PST)
In-Reply-To: <CALOK3vdqwj-ZNOi_0uvarEorsZ1JaB+bfNXkbfGGLFB8gxFUuw@mail.gmail.com>
References: <CALOK3vdqwj-ZNOi_0uvarEorsZ1JaB+bfNXkbfGGLFB8gxFUuw@mail.gmail.com>
From: Sahil Suneja <sahilsuneja@gmail.com>
Date: Wed, 27 Feb 2013 19:07:14 -0500
Message-ID: <CALOK3vd4dQLAhmQDKc=oJJ58G=98WMyYL+6q3R=Mrohtjbz2Dg@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Issues with Xenpaging in Xen-4.2.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

> The pvops kernel may not have all required changes to run xenpaging in
> dom0. Maybe 3.8 already has these changes. If in doubt try the
> SLES/openSuSE kernels as dom0, their backend drivers can deal with
> paged granttable entries.

Thanks a lot Olaf!
Confirming that linux 3.8 as dom0 still has the same xenpaging page-in
error wrt gfn #100, but opensuse 12.3 rc1 kernel (linux 3.7.9-1.4-xen)
has a much more stable xenpaging, and a much more rich xen-config
kernel build option set.
Although, I am still not clear what the error meant to begin with.

Best,
Sahil

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 00:56:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 00:56: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 1UArnV-00037P-Ft; Thu, 28 Feb 2013 00:56: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 1UArnT-00037K-Ld
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 00:56:31 +0000
Received: from [85.158.139.83:39445] by server-16.bemta-5.messagelabs.com id
	D2/A9-02543-E3BAE215; Thu, 28 Feb 2013 00:56:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1362012990!24117000!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22063 invoked from network); 28 Feb 2013 00:56:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 00:56:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,752,1355097600"; 
   d="scan'208";a="1984854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 00:56: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.297.1; Thu, 28 Feb 2013 00:56:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UArnR-0001iL-CJ;
	Thu, 28 Feb 2013 00:56:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UArnR-0004k5-7b;
	Thu, 28 Feb 2013 00:56:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16766-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 00:56:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16766: 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 16766 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16766/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122
 build-i386-oldkern            4 xen-build        fail in 16756 REGR. vs. 15122
 build-i386-pvops              4 kernel-build     fail in 16756 REGR. vs. 15122
 build-i386                    4 xen-build        fail in 16756 REGR. vs. 15122

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-win   15 guest-destroy               fail pass in 16756

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   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-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)  blocked in 16756 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)    blocked in 16756 n/a
 test-i386-i386-qemuu-win      1 xen-build-check(1)        blocked in 16756 n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)        blocked in 16756 n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 16756 n/a
 test-i386-i386-xl-qemuu-win   1 xen-build-check(1)        blocked in 16756 n/a
 test-amd64-amd64-qemuu-win   16 leak-check/check      fail in 16756 never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)    blocked in 16756 n/a

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 00:56:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 00:56: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 1UArnV-00037P-Ft; Thu, 28 Feb 2013 00:56: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 1UArnT-00037K-Ld
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 00:56:31 +0000
Received: from [85.158.139.83:39445] by server-16.bemta-5.messagelabs.com id
	D2/A9-02543-E3BAE215; Thu, 28 Feb 2013 00:56:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1362012990!24117000!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22063 invoked from network); 28 Feb 2013 00:56:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 00:56:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,752,1355097600"; 
   d="scan'208";a="1984854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 00:56: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.297.1; Thu, 28 Feb 2013 00:56:29 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UArnR-0001iL-CJ;
	Thu, 28 Feb 2013 00:56:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UArnR-0004k5-7b;
	Thu, 28 Feb 2013 00:56:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16766-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 00:56:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16766: 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 16766 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16766/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122
 build-i386-oldkern            4 xen-build        fail in 16756 REGR. vs. 15122
 build-i386-pvops              4 kernel-build     fail in 16756 REGR. vs. 15122
 build-i386                    4 xen-build        fail in 16756 REGR. vs. 15122

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-win   15 guest-destroy               fail pass in 16756

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   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-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)  blocked in 16756 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-qemuu-win-vcpus1  1 xen-build-check(1)    blocked in 16756 n/a
 test-i386-i386-qemuu-win      1 xen-build-check(1)        blocked in 16756 n/a
 test-amd64-i386-qemuu-win     1 xen-build-check(1)        blocked in 16756 n/a
 test-amd64-i386-xl-qemuu-win-vcpus1  1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 xen-build-check(1) blocked in 16756 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 xen-build-check(1) blocked in 16756 n/a
 test-i386-i386-xl-qemuu-win   1 xen-build-check(1)        blocked in 16756 n/a
 test-amd64-amd64-qemuu-win   16 leak-check/check      fail in 16756 never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)    blocked in 16756 n/a

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 02:04:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 02: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 1UAsr8-0008Sd-Qc; Thu, 28 Feb 2013 02:04:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mattjd@gmail.com>) id 1UAsr7-0008SX-7W
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 02:04:21 +0000
Received: from [85.158.139.211:47446] by server-6.bemta-5.messagelabs.com id
	70/C3-21466-42BBE215; Thu, 28 Feb 2013 02:04:20 +0000
X-Env-Sender: mattjd@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1362017057!19641330!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16129 invoked from network); 28 Feb 2013 02:04:19 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 02:04:19 -0000
Received: by mail-pa0-f50.google.com with SMTP id fa11so804566pad.23
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 18:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:from:to:cc:subject:date:message-id:x-mailer;
	bh=v+dg3T3vbC7mzYf9UCi/j02IWbKgPegC+M21XcEVGJE=;
	b=UItvdltVzvsRx1pf19KkaKvCuRgXNcEfeDLY1ix0zmpzTlZ/4LV1CtedYb+V7n/h0H
	awczpEWRo5HVrBkS9JzCpuNU7kIPaJBI4BYfaWiqT+4V24n1+1OP8hxcV3rpIiqshpo0
	CL6B8ho8VC+5E1dhtCQb3BiivFVVVjrBMReP1QR6MO/8ttIxEImnZI3jz86LYE7Vjwdj
	XXNNNMie6omZhu2+z5eeXpzmrBGJl3kgZMqq71thF582bpe85nlNi1S1F7ahdMHtbs4Y
	vkg2CxVr8ErsPYPrT7wcsLAZFrD0FJIwgYRR6Bb+n+eLxITzgSPg8NQOs23J5rlgLyzw
	WCvg==
X-Received: by 10.68.134.3 with SMTP id pg3mr6688738pbb.51.1362016998073;
	Wed, 27 Feb 2013 18:03:18 -0800 (PST)
Received: from morphism.xen.prgmr.com (morphism.xen.prgmr.com. [71.19.145.114])
	by mx.google.com with ESMTPS id kb3sm6483484pbc.21.2013.02.27.18.03.15
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 18:03:16 -0800 (PST)
From: Matthew Daley <mattjd@gmail.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Feb 2013 15:05:45 +1300
Message-Id: <1362017145-8046-1-git-send-email-mattjd@gmail.com>
X-Mailer: git-send-email 1.7.10.4
Cc: Matthew Daley <mattjd@gmail.com>
Subject: [Xen-devel] [PATCH] xen: fix domain unlocking in some xsm error
	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>
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

A couple of xsm error/access-denied code paths in hypercalls neglect to
unlock a previously locked domain. Fix by ensuring the domains are
unlocked correctly.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
 xen/arch/x86/physdev.c   |    2 +-
 xen/common/grant_table.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index d9ed5df..3006266 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 
     ret = xsm_map_domain_pirq(XSM_TARGET, d);
     if ( ret )
-        return ret;
+        goto free_domain;
 
     /* Verify or get irq. */
     switch ( type )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f85adb4..5bd99b8 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2283,7 +2283,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
     rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
     if ( rc ) {
         op.status = GNTST_permission_denied;
-        goto out1;
+        goto out2;
     }
 
     gt = d->grant_table;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 02:04:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 02: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 1UAsr8-0008Sd-Qc; Thu, 28 Feb 2013 02:04:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mattjd@gmail.com>) id 1UAsr7-0008SX-7W
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 02:04:21 +0000
Received: from [85.158.139.211:47446] by server-6.bemta-5.messagelabs.com id
	70/C3-21466-42BBE215; Thu, 28 Feb 2013 02:04:20 +0000
X-Env-Sender: mattjd@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1362017057!19641330!1
X-Originating-IP: [209.85.220.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16129 invoked from network); 28 Feb 2013 02:04:19 -0000
Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com)
	(209.85.220.50)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 02:04:19 -0000
Received: by mail-pa0-f50.google.com with SMTP id fa11so804566pad.23
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 18:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:from:to:cc:subject:date:message-id:x-mailer;
	bh=v+dg3T3vbC7mzYf9UCi/j02IWbKgPegC+M21XcEVGJE=;
	b=UItvdltVzvsRx1pf19KkaKvCuRgXNcEfeDLY1ix0zmpzTlZ/4LV1CtedYb+V7n/h0H
	awczpEWRo5HVrBkS9JzCpuNU7kIPaJBI4BYfaWiqT+4V24n1+1OP8hxcV3rpIiqshpo0
	CL6B8ho8VC+5E1dhtCQb3BiivFVVVjrBMReP1QR6MO/8ttIxEImnZI3jz86LYE7Vjwdj
	XXNNNMie6omZhu2+z5eeXpzmrBGJl3kgZMqq71thF582bpe85nlNi1S1F7ahdMHtbs4Y
	vkg2CxVr8ErsPYPrT7wcsLAZFrD0FJIwgYRR6Bb+n+eLxITzgSPg8NQOs23J5rlgLyzw
	WCvg==
X-Received: by 10.68.134.3 with SMTP id pg3mr6688738pbb.51.1362016998073;
	Wed, 27 Feb 2013 18:03:18 -0800 (PST)
Received: from morphism.xen.prgmr.com (morphism.xen.prgmr.com. [71.19.145.114])
	by mx.google.com with ESMTPS id kb3sm6483484pbc.21.2013.02.27.18.03.15
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 18:03:16 -0800 (PST)
From: Matthew Daley <mattjd@gmail.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Feb 2013 15:05:45 +1300
Message-Id: <1362017145-8046-1-git-send-email-mattjd@gmail.com>
X-Mailer: git-send-email 1.7.10.4
Cc: Matthew Daley <mattjd@gmail.com>
Subject: [Xen-devel] [PATCH] xen: fix domain unlocking in some xsm error
	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>
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

A couple of xsm error/access-denied code paths in hypercalls neglect to
unlock a previously locked domain. Fix by ensuring the domains are
unlocked correctly.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
 xen/arch/x86/physdev.c   |    2 +-
 xen/common/grant_table.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index d9ed5df..3006266 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 
     ret = xsm_map_domain_pirq(XSM_TARGET, d);
     if ( ret )
-        return ret;
+        goto free_domain;
 
     /* Verify or get irq. */
     switch ( type )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f85adb4..5bd99b8 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2283,7 +2283,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
     rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
     if ( rc ) {
         op.status = GNTST_permission_denied;
-        goto out1;
+        goto out2;
     }
 
     gt = d->grant_table;
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 04:58:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 04: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 1UAvYv-0002A2-Bo; Thu, 28 Feb 2013 04:57:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1UAvYt-00029u-Ix
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 04:57:43 +0000
Received: from [85.158.137.99:55090] by server-1.bemta-3.messagelabs.com id
	BB/D9-13706-6C3EE215; Thu, 28 Feb 2013 04:57:42 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1362027460!18487170!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjQ2MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21089 invoked from network); 28 Feb 2013 04:57:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 04:57:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1S4vXWY013298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 04:57:34 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
	r1S4vXbQ006347
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 04:57:33 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
	r1S4vWmD025189; Wed, 27 Feb 2013 22:57:33 -0600
Received: from [192.168.1.101] (/106.3.103.130)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 20:57:32 -0800
Message-ID: <512EE3C5.9090208@oracle.com>
Date: Thu, 28 Feb 2013 12:57:41 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512C78D2.8030903@oracle.com>
	<512C979E02000078000C105F@nat28.tlf.novell.com>
	<512D9E86.1080907@oracle.com>
	<512DD3AD02000078000C156C@nat28.tlf.novell.com>
In-Reply-To: <512DD3AD02000078000C156C@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.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 2013-02-27 16:36, Jan Beulich wrote:
>>>> On 27.02.13 at 06:49, Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:
>> On 2013-02-26 18:08, Jan Beulich wrote:
>>>>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>>> (fee00000 -> fee02000)
>>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>>> (00004059 -> 00004071)
>>> If you look at the code issuing this message, the situation is
>>> pretty clear (and I think it as described already in the past,
>>> albeit I have no link at hand): qemu lacks proper emulation of
>>> the mask bit. pci_msix_write() looks at the physical one, yet
>>> when the guest sets the virtual mask bit, nothing is being
>>> done at all to make the hypervisor also mask the physical
>>> entry:
>>>
>>>       if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
>>>           if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>>>               xen_pt_msix_update_one(s, entry_nr);
>>>           }
>>>       }
>>>
>>> There's probably quite a bit of code to be written to make this
>>> work.
>> Is there plan of fixing it?
> I'm not aware of anyone working on this, or having planned to.
> Want to take a shot?
I'm looking at it.
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 04:58:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 04: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 1UAvYv-0002A2-Bo; Thu, 28 Feb 2013 04:57:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1UAvYt-00029u-Ix
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 04:57:43 +0000
Received: from [85.158.137.99:55090] by server-1.bemta-3.messagelabs.com id
	BB/D9-13706-6C3EE215; Thu, 28 Feb 2013 04:57:42 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1362027460!18487170!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjQ2MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21089 invoked from network); 28 Feb 2013 04:57:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 04:57:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1S4vXWY013298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 04:57:34 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
	r1S4vXbQ006347
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 04:57:33 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
	r1S4vWmD025189; Wed, 27 Feb 2013 22:57:33 -0600
Received: from [192.168.1.101] (/106.3.103.130)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 20:57:32 -0800
Message-ID: <512EE3C5.9090208@oracle.com>
Date: Thu, 28 Feb 2013 12:57:41 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <512C78D2.8030903@oracle.com>
	<512C979E02000078000C105F@nat28.tlf.novell.com>
	<512D9E86.1080907@oracle.com>
	<512DD3AD02000078000C156C@nat28.tlf.novell.com>
In-Reply-To: <512DD3AD02000078000C156C@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Joe Jin <joe.jin@oracle.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] passthroughed msix device
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.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 2013-02-27 16:36, Jan Beulich wrote:
>>>> On 27.02.13 at 06:49, Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:
>> On 2013-02-26 18:08, Jan Beulich wrote:
>>>>>> On 26.02.13 at 09:56, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>>> (fee00000 -> fee02000)
>>>> pci_msix_writel: Can't update entry 0 since MSI-X is already enabled
>>>> (00004059 -> 00004071)
>>> If you look at the code issuing this message, the situation is
>>> pretty clear (and I think it as described already in the past,
>>> albeit I have no link at hand): qemu lacks proper emulation of
>>> the mask bit. pci_msix_write() looks at the physical one, yet
>>> when the guest sets the virtual mask bit, nothing is being
>>> done at all to make the hypervisor also mask the physical
>>> entry:
>>>
>>>       if (offset == PCI_MSIX_ENTRY_VECTOR_CTRL) {
>>>           if (msix->enabled && !(val & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
>>>               xen_pt_msix_update_one(s, entry_nr);
>>>           }
>>>       }
>>>
>>> There's probably quite a bit of code to be written to make this
>>> work.
>> Is there plan of fixing it?
> I'm not aware of anyone working on this, or having planned to.
> Want to take a shot?
I'm looking at it.
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 05:14:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 05:14: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 1UAvoG-0002gv-RW; Thu, 28 Feb 2013 05:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mattjd@gmail.com>) id 1UAvoF-0002gq-KC
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 05:13:35 +0000
Received: from [85.158.137.99:34297] by server-10.bemta-3.messagelabs.com id
	E7/CB-19664-E77EE215; Thu, 28 Feb 2013 05:13:34 +0000
X-Env-Sender: mattjd@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1362028402!12846719!1
X-Originating-IP: [209.85.160.51]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7802 invoked from network); 28 Feb 2013 05:13:24 -0000
Received: from mail-pb0-f51.google.com (HELO mail-pb0-f51.google.com)
	(209.85.160.51)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 05:13:24 -0000
Received: by mail-pb0-f51.google.com with SMTP id un15so838511pbc.38
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 21:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:from:to:cc:subject:date:message-id:x-mailer;
	bh=3CJQ9fBeNhtUli3e508yKsBvGQpnHxyV4JCl8GvOWjA=;
	b=FMKVn9HwBOATjSqQdyU47B+tYrEhw1KbMnC708er2SySVjCyOTQwATj0Gxe+9oawdg
	pteCC2XIZHysayNd0mScufMu5Pd5xta0DegLkQuyFAVX9yO4Jy1rhpJt/+amsXQFkxaE
	vijN10F3hl/c4DjdYoBB0t6tPpkHLpoJv6usBu2bWrlQQ9EIvG7DpzaEoOBMbvFlPJfP
	sRr2RUwhomYktkj1GtmUh193m66B1VUUudfxFtEBtQ1EkXrF0jRTiSQuoxaX/7oVsgQ0
	Y9Cj50Jbg+lUHX/zRwAj9oqLTk1HWYu+VNEpgXUAOTuUnkfmlPoVZ2HWy8bAucvGxBtr
	ZwvA==
X-Received: by 10.66.160.98 with SMTP id xj2mr11187861pab.125.1362028401909;
	Wed, 27 Feb 2013 21:13:21 -0800 (PST)
Received: from morphism.xen.prgmr.com (morphism.xen.prgmr.com. [71.19.145.114])
	by mx.google.com with ESMTPS id hp7sm7050401pbc.8.2013.02.27.21.13.19
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 21:13:20 -0800 (PST)
From: Matthew Daley <mattjd@gmail.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Feb 2013 18:16:04 +1300
Message-Id: <1362028564-8627-1-git-send-email-mattjd@gmail.com>
X-Mailer: git-send-email 1.7.10.4
Cc: Matthew Daley <mattjd@gmail.com>
Subject: [Xen-devel] [PATCH] x86/mm: fix invalid unlinking of nested p2m
	tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Commit 90805dc (c/s 26387:4056e5a3d815) ("EPT: Make ept data stucture or
operations neutral") makes nested p2m tables be unlinked from the host
p2m table before their destruction (in p2m_teardown_nestedp2m).
However, by this time the host p2m table has already been torn down,
leading to a possible race condition where another allocation between
the two kinds of table being torn down can lead to a linked list
assertion with debug=y builds or memory corruption on debug=n ones.

Fix by swapping the order the two kinds of table are torn down in. While
at it, remove the condition in p2m_final_teardown, as it is already
checked identically in p2m_teardown_hostp2m itself.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
 xen/arch/x86/mm/p2m.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index de1dd82..ad1f676 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -490,15 +490,13 @@ void p2m_teardown(struct p2m_domain *p2m)
 
 void p2m_final_teardown(struct domain *d)
 {
-    /* Iterate over all p2m tables per domain */
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    if ( p2m )
-        p2m_teardown_hostp2m(d);
-
     /* We must teardown unconditionally because
      * we initialise them unconditionally.
      */
     p2m_teardown_nestedp2m(d);
+
+    /* Iterate over all p2m tables per domain */
+    p2m_teardown_hostp2m(d);
 }
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 05:14:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 05:14: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 1UAvoG-0002gv-RW; Thu, 28 Feb 2013 05:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mattjd@gmail.com>) id 1UAvoF-0002gq-KC
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 05:13:35 +0000
Received: from [85.158.137.99:34297] by server-10.bemta-3.messagelabs.com id
	E7/CB-19664-E77EE215; Thu, 28 Feb 2013 05:13:34 +0000
X-Env-Sender: mattjd@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1362028402!12846719!1
X-Originating-IP: [209.85.160.51]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7802 invoked from network); 28 Feb 2013 05:13:24 -0000
Received: from mail-pb0-f51.google.com (HELO mail-pb0-f51.google.com)
	(209.85.160.51)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 05:13:24 -0000
Received: by mail-pb0-f51.google.com with SMTP id un15so838511pbc.38
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 21:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:from:to:cc:subject:date:message-id:x-mailer;
	bh=3CJQ9fBeNhtUli3e508yKsBvGQpnHxyV4JCl8GvOWjA=;
	b=FMKVn9HwBOATjSqQdyU47B+tYrEhw1KbMnC708er2SySVjCyOTQwATj0Gxe+9oawdg
	pteCC2XIZHysayNd0mScufMu5Pd5xta0DegLkQuyFAVX9yO4Jy1rhpJt/+amsXQFkxaE
	vijN10F3hl/c4DjdYoBB0t6tPpkHLpoJv6usBu2bWrlQQ9EIvG7DpzaEoOBMbvFlPJfP
	sRr2RUwhomYktkj1GtmUh193m66B1VUUudfxFtEBtQ1EkXrF0jRTiSQuoxaX/7oVsgQ0
	Y9Cj50Jbg+lUHX/zRwAj9oqLTk1HWYu+VNEpgXUAOTuUnkfmlPoVZ2HWy8bAucvGxBtr
	ZwvA==
X-Received: by 10.66.160.98 with SMTP id xj2mr11187861pab.125.1362028401909;
	Wed, 27 Feb 2013 21:13:21 -0800 (PST)
Received: from morphism.xen.prgmr.com (morphism.xen.prgmr.com. [71.19.145.114])
	by mx.google.com with ESMTPS id hp7sm7050401pbc.8.2013.02.27.21.13.19
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 21:13:20 -0800 (PST)
From: Matthew Daley <mattjd@gmail.com>
To: xen-devel@lists.xen.org
Date: Thu, 28 Feb 2013 18:16:04 +1300
Message-Id: <1362028564-8627-1-git-send-email-mattjd@gmail.com>
X-Mailer: git-send-email 1.7.10.4
Cc: Matthew Daley <mattjd@gmail.com>
Subject: [Xen-devel] [PATCH] x86/mm: fix invalid unlinking of nested p2m
	tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Commit 90805dc (c/s 26387:4056e5a3d815) ("EPT: Make ept data stucture or
operations neutral") makes nested p2m tables be unlinked from the host
p2m table before their destruction (in p2m_teardown_nestedp2m).
However, by this time the host p2m table has already been torn down,
leading to a possible race condition where another allocation between
the two kinds of table being torn down can lead to a linked list
assertion with debug=y builds or memory corruption on debug=n ones.

Fix by swapping the order the two kinds of table are torn down in. While
at it, remove the condition in p2m_final_teardown, as it is already
checked identically in p2m_teardown_hostp2m itself.

Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
 xen/arch/x86/mm/p2m.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index de1dd82..ad1f676 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -490,15 +490,13 @@ void p2m_teardown(struct p2m_domain *p2m)
 
 void p2m_final_teardown(struct domain *d)
 {
-    /* Iterate over all p2m tables per domain */
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    if ( p2m )
-        p2m_teardown_hostp2m(d);
-
     /* We must teardown unconditionally because
      * we initialise them unconditionally.
      */
     p2m_teardown_nestedp2m(d);
+
+    /* Iterate over all p2m tables per domain */
+    p2m_teardown_hostp2m(d);
 }
 
 
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 05:19:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 05:19: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 1UAvtw-0002pT-LW; Thu, 28 Feb 2013 05:19:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAvtv-0002pM-0z
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 05:19:27 +0000
Received: from [85.158.137.99:57483] by server-7.bemta-3.messagelabs.com id
	D0/03-06591-ED8EE215; Thu, 28 Feb 2013 05:19:26 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1362028763!16130425!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjQ2MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16365 invoked from network); 28 Feb 2013 05:19:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 05:19:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1S5JLcS031943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 05:19:22 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
	r1S5JKcD016592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 05:19:20 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
	r1S5JJrG017108; Wed, 27 Feb 2013 23:19:20 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 21:19:19 -0800
Message-ID: <512EE8EF.30200@oracle.com>
Date: Thu, 28 Feb 2013 13:19:43 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
	<1361980154.2109.67.camel@zion.uk.xensource.com>
In-Reply-To: <1361980154.2109.67.camel@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-27 23:49, Wei Liu wrote:
> On Wed, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
>> On 2013-2-26 20:35, Wei Liu wrote:
>>> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
>>>> On 2013-2-16 0:00, Wei Liu wrote:
>>>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
>>>>> ---
>>>>>     drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
>>>>>     1 file changed, 174 insertions(+), 72 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>>>> index 8bd75a1..de73a71 100644
>>>>> --- a/drivers/net/xen-netfront.c
>>>>> +++ b/drivers/net/xen-netfront.c
>>>>> @@ -67,9 +67,19 @@ struct netfront_cb {
>>>>>
>>>>>     #define GRANT_INVALID_REF   0
>>>>>
>>>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
>>>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
>>>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
>>>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
>>>>> +#define XENNET_MAX_RING_PAGES      (1U<<    XENNET_MAX_RING_PAGE_ORDER)
>>>>> +
>>>>> +
>>>>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
>>>>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
>>>>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
>>>>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
>>>>> +
>>>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>>>> +
>>>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
>>>> Not using multi-page ring here?
>>>> In xennet_create_dev, gnttab_alloc_grant_references allocates
>>>> TX_MAX_TARGET number of grant reference for tx. In
>>>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
>>>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
>>>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
>>>> skb_entry_is_link helps to not release invalid grants, lots of null loop
>>>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
>>>> variableconnected with np->tx_ring_pages. Or you intended to use one
>>>> page ring here?
>>>>
>>> Looking back my history, this limitation was introduced because if we
>>> have a multi-page backend and single page frontend, the backend skb
>>> processing could overlap.
>> I did not see the overlap you mentioned here in netback. Although
>> netback supports multi-page, netback->vif still uses single page if the
>> frontend only supports single page. Netfront and netback negotiate this
>> through xenstore in your 5/8 patch. The requests and response should not
>> have any overlap between netback and netfront. Am I missing something?
>>
> I tried to dig up mail archive just now and realized that the bug report
> was in private mail exchange with Konrad.
>
> I don't really remember the details now since it is more than one year
> old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
> remember is that this bug was triggered by mixed old/new
> frontend/backend.

I checked the code in Konrad's tree and am thinking this overlap issue 
you mentioned existing in original netback(without multi-ring) and newer 
netfront. Original netback does not support multi-ring, and your newer 
netfront before this bug fix used "#define TX_MAX_TARGET 
XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when 
netfront allocating rx skbs.
"#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the 
netfront to single ring, it fixed the overlap issue, but not enough.

>
> I think this cap can be removed if we make all buffers in netfront
> dynamically allocated.

Yes, making TX_MAX_TARGET dynamically would fix this issue.

Thanks
Annie
>
>
> Wei.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 05:19:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 05:19: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 1UAvtw-0002pT-LW; Thu, 28 Feb 2013 05:19:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UAvtv-0002pM-0z
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 05:19:27 +0000
Received: from [85.158.137.99:57483] by server-7.bemta-3.messagelabs.com id
	D0/03-06591-ED8EE215; Thu, 28 Feb 2013 05:19:26 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1362028763!16130425!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjQ2MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16365 invoked from network); 28 Feb 2013 05:19:25 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 05:19:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1S5JLcS031943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 05:19:22 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
	r1S5JKcD016592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 05:19:20 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
	r1S5JJrG017108; Wed, 27 Feb 2013 23:19:20 -0600
Received: from [10.182.39.161] (/10.182.39.161)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 27 Feb 2013 21:19:19 -0800
Message-ID: <512EE8EF.30200@oracle.com>
Date: Thu, 28 Feb 2013 13:19:43 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
	<1361980154.2109.67.camel@zion.uk.xensource.com>
In-Reply-To: <1361980154.2109.67.camel@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-27 23:49, Wei Liu wrote:
> On Wed, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
>> On 2013-2-26 20:35, Wei Liu wrote:
>>> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
>>>> On 2013-2-16 0:00, Wei Liu wrote:
>>>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
>>>>> ---
>>>>>     drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
>>>>>     1 file changed, 174 insertions(+), 72 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>>>> index 8bd75a1..de73a71 100644
>>>>> --- a/drivers/net/xen-netfront.c
>>>>> +++ b/drivers/net/xen-netfront.c
>>>>> @@ -67,9 +67,19 @@ struct netfront_cb {
>>>>>
>>>>>     #define GRANT_INVALID_REF   0
>>>>>
>>>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
>>>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
>>>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
>>>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
>>>>> +#define XENNET_MAX_RING_PAGES      (1U<<    XENNET_MAX_RING_PAGE_ORDER)
>>>>> +
>>>>> +
>>>>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
>>>>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
>>>>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
>>>>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
>>>>> +
>>>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
>>>>> +
>>>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
>>>> Not using multi-page ring here?
>>>> In xennet_create_dev, gnttab_alloc_grant_references allocates
>>>> TX_MAX_TARGET number of grant reference for tx. In
>>>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
>>>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
>>>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
>>>> skb_entry_is_link helps to not release invalid grants, lots of null loop
>>>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
>>>> variableconnected with np->tx_ring_pages. Or you intended to use one
>>>> page ring here?
>>>>
>>> Looking back my history, this limitation was introduced because if we
>>> have a multi-page backend and single page frontend, the backend skb
>>> processing could overlap.
>> I did not see the overlap you mentioned here in netback. Although
>> netback supports multi-page, netback->vif still uses single page if the
>> frontend only supports single page. Netfront and netback negotiate this
>> through xenstore in your 5/8 patch. The requests and response should not
>> have any overlap between netback and netfront. Am I missing something?
>>
> I tried to dig up mail archive just now and realized that the bug report
> was in private mail exchange with Konrad.
>
> I don't really remember the details now since it is more than one year
> old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
> remember is that this bug was triggered by mixed old/new
> frontend/backend.

I checked the code in Konrad's tree and am thinking this overlap issue 
you mentioned existing in original netback(without multi-ring) and newer 
netfront. Original netback does not support multi-ring, and your newer 
netfront before this bug fix used "#define TX_MAX_TARGET 
XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when 
netfront allocating rx skbs.
"#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the 
netfront to single ring, it fixed the overlap issue, but not enough.

>
> I think this cap can be removed if we make all buffers in netfront
> dynamically allocated.

Yes, making TX_MAX_TARGET dynamically would fix this issue.

Thanks
Annie
>
>
> Wei.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 05:59:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 05:59: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 1UAwW1-0003HH-06; Thu, 28 Feb 2013 05:58:49 +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 1UAwW0-0003HC-4o
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 05:58:48 +0000
Received: from [85.158.143.99:11996] by server-2.bemta-4.messagelabs.com id
	39/F6-12656-712FE215; Thu, 28 Feb 2013 05:58:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1362031126!18109876!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28603 invoked from network); 28 Feb 2013 05:58:46 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 05:58:46 -0000
Received: by mail-wi0-f169.google.com with SMTP id l13so8575475wie.0
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 21:58:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=qTUZOKKjTEwv8pYvE47ZnLG2Q27l9ECATcnfD7qbdik=;
	b=uYU/J96Gcd5nE9HAUXY/hdsPMzjSle/uXszr766EvdvqWXAMqbYLavctlYf2uIUSXw
	+e39iz9QwnsglT8uSPdpd88X1Kcl5MiIArsdq1B2tnXtdzfEl87ypD8gCROnPFO+8ICX
	U+Gc0f/ziBZPsp4EGs0j8L4ayf4rH4Me6sN3/WMm8VexlQl5FfPFtbyIoFr1mVVLbT9L
	vRmWX74B+EIS9emU1cag53u8H4xMGFwjdhyqVfdgxShO/DWGnC4yMOYO12pgXV0rtKdE
	VG3zoIKPSuhgzpl6gRxZ5IHCNmEAh89hpcUPT5CIWa9QP5x7N6J20iKmS4qnMEMgoLRY
	CFgw==
X-Received: by 10.181.12.5 with SMTP id em5mr8148983wid.24.1362031126437;
	Wed, 27 Feb 2013 21:58:46 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id t7sm31185092wiy.2.2013.02.27.21.58.43
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 21:58:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 28 Feb 2013 05:58:39 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <CD54A28F.4CD9C%keir.xen@gmail.com>
Thread-Topic: [RFC PATCH V3] Implement 3-level event channel in Xen
Thread-Index: Ac4VeKd0jt8PMtIY90qmNzGlVGYQ5A==
In-Reply-To: <20130227231927.GA13549@zion.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27/02/2013 23:19, "Wei Liu" <wei.liu2@citrix.com> wrote:

> On Wed, Feb 27, 2013 at 07:49:34PM +0000, Keir Fraser wrote:
>> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>>>> Keir, Jan, Ian and David, are you happy with this design in general? I
>>>> would
>>>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>>>> 4.3 is quite close now.
>>> 
>>> The patches look reasonable (apart from the comments I just gave
>>> on some of them), but other than Keir I'm not that eager to see this
>>> one go in for 4.3 in order to then likely be replaced by an
>>> implementation of David's design in the 4.4 cycle.
>> 
>> If this went in for 4.3, a re-design would really have to be implemented and
>> measurably prove its worth to make it in as another replacement.
> 
> Even this design does not go in for 4.3, any new design will still have
> to be implemented and measurable prove its worth, as with this design.

I believe there's a requirement to solve the dom0 event-channel limit for
4.3. Either of the proposed designs obviously solves that, without need for
implement and test. Of course, we need to do that to test for correctness
and performance regressions anyway. But I mean with that primary requirement
satisfied, yet another evtchn ABI really then has to have some compelling
advantages to get committed.

 -- Keir

> The value of this design lies in that a) it's straight forward, easy to
> prove its correctness (or wrongness), b) it meets our need for now, c)
> a new interface will always be necessary, be it this design or any other
> design, d) it buys time for any better designs to become mature.
> 
> I understand your (and Jan's) concern for burdens of maintaining
> different ABIs, that's why the interface has been made to allow user to
> query enabled / supported ABIs. If we need to add / remove ABIs, it's
> just a matter of setting some feature bits.
> 
> I don't mean to push this design to get merged, it's up to maintainers
> to decide. Actually I'm fine with any decision. Explicit Ack / Nack will
> help me arrange my future work better.
> 
> 
> Wei.
> 
>>  -- Keir
>> 
>>> Jan
>>> 
>> 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 05:59:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 05:59: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 1UAwW1-0003HH-06; Thu, 28 Feb 2013 05:58:49 +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 1UAwW0-0003HC-4o
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 05:58:48 +0000
Received: from [85.158.143.99:11996] by server-2.bemta-4.messagelabs.com id
	39/F6-12656-712FE215; Thu, 28 Feb 2013 05:58:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1362031126!18109876!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28603 invoked from network); 28 Feb 2013 05:58:46 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 05:58:46 -0000
Received: by mail-wi0-f169.google.com with SMTP id l13so8575475wie.0
	for <xen-devel@lists.xen.org>; Wed, 27 Feb 2013 21:58:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=qTUZOKKjTEwv8pYvE47ZnLG2Q27l9ECATcnfD7qbdik=;
	b=uYU/J96Gcd5nE9HAUXY/hdsPMzjSle/uXszr766EvdvqWXAMqbYLavctlYf2uIUSXw
	+e39iz9QwnsglT8uSPdpd88X1Kcl5MiIArsdq1B2tnXtdzfEl87ypD8gCROnPFO+8ICX
	U+Gc0f/ziBZPsp4EGs0j8L4ayf4rH4Me6sN3/WMm8VexlQl5FfPFtbyIoFr1mVVLbT9L
	vRmWX74B+EIS9emU1cag53u8H4xMGFwjdhyqVfdgxShO/DWGnC4yMOYO12pgXV0rtKdE
	VG3zoIKPSuhgzpl6gRxZ5IHCNmEAh89hpcUPT5CIWa9QP5x7N6J20iKmS4qnMEMgoLRY
	CFgw==
X-Received: by 10.181.12.5 with SMTP id em5mr8148983wid.24.1362031126437;
	Wed, 27 Feb 2013 21:58:46 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id t7sm31185092wiy.2.2013.02.27.21.58.43
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 21:58:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 28 Feb 2013 05:58:39 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <CD54A28F.4CD9C%keir.xen@gmail.com>
Thread-Topic: [RFC PATCH V3] Implement 3-level event channel in Xen
Thread-Index: Ac4VeKd0jt8PMtIY90qmNzGlVGYQ5A==
In-Reply-To: <20130227231927.GA13549@zion.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27/02/2013 23:19, "Wei Liu" <wei.liu2@citrix.com> wrote:

> On Wed, Feb 27, 2013 at 07:49:34PM +0000, Keir Fraser wrote:
>> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>>>> Keir, Jan, Ian and David, are you happy with this design in general? I
>>>> would
>>>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>>>> 4.3 is quite close now.
>>> 
>>> The patches look reasonable (apart from the comments I just gave
>>> on some of them), but other than Keir I'm not that eager to see this
>>> one go in for 4.3 in order to then likely be replaced by an
>>> implementation of David's design in the 4.4 cycle.
>> 
>> If this went in for 4.3, a re-design would really have to be implemented and
>> measurably prove its worth to make it in as another replacement.
> 
> Even this design does not go in for 4.3, any new design will still have
> to be implemented and measurable prove its worth, as with this design.

I believe there's a requirement to solve the dom0 event-channel limit for
4.3. Either of the proposed designs obviously solves that, without need for
implement and test. Of course, we need to do that to test for correctness
and performance regressions anyway. But I mean with that primary requirement
satisfied, yet another evtchn ABI really then has to have some compelling
advantages to get committed.

 -- Keir

> The value of this design lies in that a) it's straight forward, easy to
> prove its correctness (or wrongness), b) it meets our need for now, c)
> a new interface will always be necessary, be it this design or any other
> design, d) it buys time for any better designs to become mature.
> 
> I understand your (and Jan's) concern for burdens of maintaining
> different ABIs, that's why the interface has been made to allow user to
> query enabled / supported ABIs. If we need to add / remove ABIs, it's
> just a matter of setting some feature bits.
> 
> I don't mean to push this design to get merged, it's up to maintainers
> to decide. Actually I'm fine with any decision. Explicit Ack / Nack will
> help me arrange my future work better.
> 
> 
> Wei.
> 
>>  -- Keir
>> 
>>> Jan
>>> 
>> 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 06:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 06:31: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 1UAx0o-0003iZ-Sa; Thu, 28 Feb 2013 06:30:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen@asianux.com>) id 1UAsAh-0007JB-QY
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 01:20:32 +0000
Received: from [85.158.138.51:16494] by server-8.bemta-3.messagelabs.com id
	A2/3F-20604-AD0BE215; Thu, 28 Feb 2013 01:20:26 +0000
X-Env-Sender: gang.chen@asianux.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362014421!27810704!1
X-Originating-IP: [58.214.24.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5204 invoked from network); 28 Feb 2013 01:20:25 -0000
Received: from intranet.asianux.com (HELO intranet.asianux.com) (58.214.24.6)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 01:20:25 -0000
Received: by intranet.asianux.com (Postfix, from userid 103)
	id 7B43B1840382; Thu, 28 Feb 2013 09:20:20 +0800 (CST)
X-Spam-Score: -100.8
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on intranet.asianux.com
X-Spam-Level: 
X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,
	RATWARE_GECKO_BUILD,USER_IN_WHITELIST autolearn=no version=3.1.9
Received: from [10.1.0.143] (unknown [219.143.36.82])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by intranet.asianux.com (Postfix) with ESMTP id 1723A1840247;
	Thu, 28 Feb 2013 09:20:20 +0800 (CST)
Message-ID: <512EB0C2.6080301@asianux.com>
Date: Thu, 28 Feb 2013 09:20:02 +0800
From: Chen Gang <gang.chen@asianux.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
	<512DE213.3050001@asianux.com>
	<512DF1DF02000078000C16A4@nat28.tlf.novell.com>
	<20130227154002.GE24932@phenom.dumpdata.com>
In-Reply-To: <20130227154002.GE24932@phenom.dumpdata.com>
X-Mailman-Approved-At: Thu, 28 Feb 2013 06:30:37 +0000
Cc: stefano.stabellini@eu.citrix.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
	without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

09ogMjAxM8TqMDLUwjI3yNUgMjM6NDAsIEtvbnJhZCBSemVzenV0ZWsgV2lsayDQtLXAOgo+IE9u
IFdlZCwgRmViIDI3LCAyMDEzIGF0IDEwOjQ1OjM1QU0gKzAwMDAsIEphbiBCZXVsaWNoIHdyb3Rl
Ogo+PiA+IAo+PiA+IFllcyAoYW5kIHlvdSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgQUNLIHRoYXQg
SSBoYWQgYWxyZWFkeSBzZW50Cj4+ID4gYmVmb3JlIHRoaXMgcmVwbHkgLSB0aGF0IG1haWwgZ290
IGJvdW5jZWQgZm9yIHlvdXIgYWRkcmVzcykuCj4gWXVwLiBDaGVuLCBjb3VsZCB5b3UgcmVzcGlu
IHRoZSBwYXRjaCB3aXRoIHRoZSBleHRyYSBjb21tZW50IGFuZAo+IHRoZSBBY2sgZnJvbSBKYW4g
cGxlYXNlPwoKICBvaywgSSB3aWxsIHNlbmQgcGF0Y2ggdjIuCgogIDotKQoKLS0gCkNoZW4gR2Fu
ZwoKQXNpYW51eCBDb3Jwb3JhdGlvbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 28 06:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 06:31: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 1UAx0o-0003iZ-Sa; Thu, 28 Feb 2013 06:30:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen@asianux.com>) id 1UAsAh-0007JB-QY
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 01:20:32 +0000
Received: from [85.158.138.51:16494] by server-8.bemta-3.messagelabs.com id
	A2/3F-20604-AD0BE215; Thu, 28 Feb 2013 01:20:26 +0000
X-Env-Sender: gang.chen@asianux.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362014421!27810704!1
X-Originating-IP: [58.214.24.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5204 invoked from network); 28 Feb 2013 01:20:25 -0000
Received: from intranet.asianux.com (HELO intranet.asianux.com) (58.214.24.6)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 01:20:25 -0000
Received: by intranet.asianux.com (Postfix, from userid 103)
	id 7B43B1840382; Thu, 28 Feb 2013 09:20:20 +0800 (CST)
X-Spam-Score: -100.8
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on intranet.asianux.com
X-Spam-Level: 
X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,
	RATWARE_GECKO_BUILD,USER_IN_WHITELIST autolearn=no version=3.1.9
Received: from [10.1.0.143] (unknown [219.143.36.82])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by intranet.asianux.com (Postfix) with ESMTP id 1723A1840247;
	Thu, 28 Feb 2013 09:20:20 +0800 (CST)
Message-ID: <512EB0C2.6080301@asianux.com>
Date: Thu, 28 Feb 2013 09:20:02 +0800
From: Chen Gang <gang.chen@asianux.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <512D90F2.9070200@asianux.com>
	<512DE6B302000078000C1631@nat28.tlf.novell.com>
	<512DE213.3050001@asianux.com>
	<512DF1DF02000078000C16A4@nat28.tlf.novell.com>
	<20130227154002.GE24932@phenom.dumpdata.com>
In-Reply-To: <20130227154002.GE24932@phenom.dumpdata.com>
X-Mailman-Approved-At: Thu, 28 Feb 2013 06:30:37 +0000
Cc: stefano.stabellini@eu.citrix.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, dgdegra@tycho.nsa.gov,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH] drivers/block/xen-blkback: preq.dev is used
	without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

09ogMjAxM8TqMDLUwjI3yNUgMjM6NDAsIEtvbnJhZCBSemVzenV0ZWsgV2lsayDQtLXAOgo+IE9u
IFdlZCwgRmViIDI3LCAyMDEzIGF0IDEwOjQ1OjM1QU0gKzAwMDAsIEphbiBCZXVsaWNoIHdyb3Rl
Ogo+PiA+IAo+PiA+IFllcyAoYW5kIHlvdSBtaWdodCBoYXZlIG1pc3NlZCB0aGUgQUNLIHRoYXQg
SSBoYWQgYWxyZWFkeSBzZW50Cj4+ID4gYmVmb3JlIHRoaXMgcmVwbHkgLSB0aGF0IG1haWwgZ290
IGJvdW5jZWQgZm9yIHlvdXIgYWRkcmVzcykuCj4gWXVwLiBDaGVuLCBjb3VsZCB5b3UgcmVzcGlu
IHRoZSBwYXRjaCB3aXRoIHRoZSBleHRyYSBjb21tZW50IGFuZAo+IHRoZSBBY2sgZnJvbSBKYW4g
cGxlYXNlPwoKICBvaywgSSB3aWxsIHNlbmQgcGF0Y2ggdjIuCgogIDotKQoKLS0gCkNoZW4gR2Fu
ZwoKQXNpYW51eCBDb3Jwb3JhdGlvbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 28 06:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 06:31: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 1UAx0p-0003ig-8H; Thu, 28 Feb 2013 06:30:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen@asianux.com>) id 1UAtKZ-0000b9-8V
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 02:34:47 +0000
Received: from [85.158.143.99:60836] by server-1.bemta-4.messagelabs.com id
	07/BE-06203-642CE215; Thu, 28 Feb 2013 02:34:46 +0000
X-Env-Sender: gang.chen@asianux.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1362018882!26229436!1
X-Originating-IP: [58.214.24.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16336 invoked from network); 28 Feb 2013 02:34:45 -0000
Received: from intranet.asianux.com (HELO intranet.asianux.com) (58.214.24.6)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 02:34:45 -0000
Received: by intranet.asianux.com (Postfix, from userid 103)
	id 32EE0184028C; Thu, 28 Feb 2013 10:34:41 +0800 (CST)
X-Spam-Score: -100.8
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on intranet.asianux.com
X-Spam-Level: 
X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,
	RATWARE_GECKO_BUILD, TW_VB, USER_IN_WHITELIST autolearn=no version=3.1.9
Received: from [10.1.0.143] (unknown [219.143.36.82])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by intranet.asianux.com (Postfix) with ESMTP id B3A8E1840247;
	Thu, 28 Feb 2013 10:34:40 +0800 (CST)
Message-ID: <512EC22F.5020404@asianux.com>
Date: Thu, 28 Feb 2013 10:34:23 +0800
From: Chen Gang <gang.chen@asianux.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Jan Beulich <JBeulich@suse.com>,
	roger.pau@citrix.com, stefano.stabellini@eu.citrix.com, 
	dgdegra@tycho.nsa.gov
X-Mailman-Approved-At: Thu, 28 Feb 2013 06:30:37 +0000
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] drivers/block/xen-blkback: preq.dev is used
	without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 call xen_vbd_translate failed, the preq.dev will be not initialized.
  so use blkif->vbd.pdevice instead (still better to print relative info).

additional information:
  before commit 01c681d4c70d64cb72142a2823f27c4146a02e63, the value printed
  here was bogus, as it was the guest provided value from req->u.rw.handle
  rather than the actual device.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/block/xen-blkback/blkback.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index de1f319..6d1cc3d 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -904,7 +904,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on dev=%04x\n",
 			 operation == READ ? "read" : "write",
 			 preq.sector_number,
-			 preq.sector_number + preq.nr_sects, preq.dev);
+			 preq.sector_number + preq.nr_sects,
+			 blkif->vbd.pdevice);
 		goto fail_response;
 	}
 
-- 
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 Thu Feb 28 06:31:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 06:31: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 1UAx0p-0003ig-8H; Thu, 28 Feb 2013 06:30:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gang.chen@asianux.com>) id 1UAtKZ-0000b9-8V
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 02:34:47 +0000
Received: from [85.158.143.99:60836] by server-1.bemta-4.messagelabs.com id
	07/BE-06203-642CE215; Thu, 28 Feb 2013 02:34:46 +0000
X-Env-Sender: gang.chen@asianux.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1362018882!26229436!1
X-Originating-IP: [58.214.24.6]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16336 invoked from network); 28 Feb 2013 02:34:45 -0000
Received: from intranet.asianux.com (HELO intranet.asianux.com) (58.214.24.6)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 02:34:45 -0000
Received: by intranet.asianux.com (Postfix, from userid 103)
	id 32EE0184028C; Thu, 28 Feb 2013 10:34:41 +0800 (CST)
X-Spam-Score: -100.8
X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on intranet.asianux.com
X-Spam-Level: 
X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,
	RATWARE_GECKO_BUILD, TW_VB, USER_IN_WHITELIST autolearn=no version=3.1.9
Received: from [10.1.0.143] (unknown [219.143.36.82])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by intranet.asianux.com (Postfix) with ESMTP id B3A8E1840247;
	Thu, 28 Feb 2013 10:34:40 +0800 (CST)
Message-ID: <512EC22F.5020404@asianux.com>
Date: Thu, 28 Feb 2013 10:34:23 +0800
From: Chen Gang <gang.chen@asianux.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
	Jan Beulich <JBeulich@suse.com>,
	roger.pau@citrix.com, stefano.stabellini@eu.citrix.com, 
	dgdegra@tycho.nsa.gov
X-Mailman-Approved-At: Thu, 28 Feb 2013 06:30:37 +0000
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] drivers/block/xen-blkback: preq.dev is used
	without initialized
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 call xen_vbd_translate failed, the preq.dev will be not initialized.
  so use blkif->vbd.pdevice instead (still better to print relative info).

additional information:
  before commit 01c681d4c70d64cb72142a2823f27c4146a02e63, the value printed
  here was bogus, as it was the guest provided value from req->u.rw.handle
  rather than the actual device.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 drivers/block/xen-blkback/blkback.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index de1f319..6d1cc3d 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -904,7 +904,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on dev=%04x\n",
 			 operation == READ ? "read" : "write",
 			 preq.sector_number,
-			 preq.sector_number + preq.nr_sects, preq.dev);
+			 preq.sector_number + preq.nr_sects,
+			 blkif->vbd.pdevice);
 		goto fail_response;
 	}
 
-- 
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 Thu Feb 28 07:23:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07:23: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 1UAxpm-0004qR-Of; Thu, 28 Feb 2013 07:23:18 +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 1UAxpl-0004qM-00
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:23:17 +0000
Received: from [85.158.138.51:25568] by server-11.bemta-3.messagelabs.com id
	8E/AE-01263-4E50F215; Thu, 28 Feb 2013 07:23:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362036194!10922122!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13659 invoked from network); 28 Feb 2013 07:23:14 -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; 28 Feb 2013 07:23:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:23:13 +0000
Message-Id: <512F13EF02000078000C1C76@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:23:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
	<CD5413CE.4CD6E%keir.xen@gmail.com>
In-Reply-To: <CD5413CE.4CD6E%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27.02.13 at 20:49, Keir Fraser <keir.xen@gmail.com> wrote:
> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>>> Keir, Jan, Ian and David, are you happy with this design in general? I would
>>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>>> 4.3 is quite close now.
>> 
>> The patches look reasonable (apart from the comments I just gave
>> on some of them), but other than Keir I'm not that eager to see this
>> one go in for 4.3 in order to then likely be replaced by an
>> implementation of David's design in the 4.4 cycle.
> 
> If this went in for 4.3, a re-design would really have to be implemented and
> measurably prove its worth to make it in as another replacement.

Or be easier to maintain and/or extend further (which I expect
would both apply to David's alternative).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:23:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07:23: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 1UAxpm-0004qR-Of; Thu, 28 Feb 2013 07:23:18 +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 1UAxpl-0004qM-00
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:23:17 +0000
Received: from [85.158.138.51:25568] by server-11.bemta-3.messagelabs.com id
	8E/AE-01263-4E50F215; Thu, 28 Feb 2013 07:23:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362036194!10922122!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13659 invoked from network); 28 Feb 2013 07:23:14 -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; 28 Feb 2013 07:23:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:23:13 +0000
Message-Id: <512F13EF02000078000C1C76@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:23:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <512E49FB02000078000C1AAB@nat28.tlf.novell.com>
	<CD5413CE.4CD6E%keir.xen@gmail.com>
In-Reply-To: <CD5413CE.4CD6E%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel 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 27.02.13 at 20:49, Keir Fraser <keir.xen@gmail.com> wrote:
> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>>> Keir, Jan, Ian and David, are you happy with this design in general? I would
>>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>>> 4.3 is quite close now.
>> 
>> The patches look reasonable (apart from the comments I just gave
>> on some of them), but other than Keir I'm not that eager to see this
>> one go in for 4.3 in order to then likely be replaced by an
>> implementation of David's design in the 4.4 cycle.
> 
> If this went in for 4.3, a re-design would really have to be implemented and
> measurably prove its worth to make it in as another replacement.

Or be easier to maintain and/or extend further (which I expect
would both apply to David's alternative).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:32:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07: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 1UAxxq-0005FE-C4; Thu, 28 Feb 2013 07:31:38 +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 1UAxxo-0005F7-OF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:31:36 +0000
Received: from [85.158.138.51:20063] by server-2.bemta-3.messagelabs.com id
	B5/01-05208-6D70F215; Thu, 28 Feb 2013 07:31:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362036693!27841118!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29198 invoked from network); 28 Feb 2013 07:31:34 -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; 28 Feb 2013 07:31:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:31:33 +0000
Message-Id: <512F15E402000078000C1C87@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:31:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Bligh" <alex@alex.org.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
In-Reply-To: <6C6293A03011B5A6516EBD48@Ximines.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote:
>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>> at the beginning of next week.
> 
> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
> a blktrace.

To me, the title you mention means nothing. It being on the tools
side, it would be Ian anyway to take care of this, but can't you be
a bit more specific and indicate which changeset/commit you're
talking of? As well as reasoning why it would be needed (or at
least desirable) to have on either or both trees?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:32:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07: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 1UAxxq-0005FE-C4; Thu, 28 Feb 2013 07:31:38 +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 1UAxxo-0005F7-OF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:31:36 +0000
Received: from [85.158.138.51:20063] by server-2.bemta-3.messagelabs.com id
	B5/01-05208-6D70F215; Thu, 28 Feb 2013 07:31:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362036693!27841118!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29198 invoked from network); 28 Feb 2013 07:31:34 -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; 28 Feb 2013 07:31:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:31:33 +0000
Message-Id: <512F15E402000078000C1C87@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:31:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Bligh" <alex@alex.org.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
In-Reply-To: <6C6293A03011B5A6516EBD48@Ximines.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote:
>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>> at the beginning of next week.
> 
> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
> a blktrace.

To me, the title you mention means nothing. It being on the tools
side, it would be Ian anyway to take care of this, but can't you be
a bit more specific and indicate which changeset/commit you're
talking of? As well as reasoning why it would be needed (or at
least desirable) to have on either or both trees?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:52:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07:52: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 1UAyHX-0005eU-7b; Thu, 28 Feb 2013 07:51: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 1UAyHV-0005eP-5r
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:51:57 +0000
Received: from [85.158.139.211:48434] by server-4.bemta-5.messagelabs.com id
	0E/7B-01980-C9C0F215; Thu, 28 Feb 2013 07:51:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362037915!18043776!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20538 invoked from network); 28 Feb 2013 07:51:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 07:51:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:51:54 +0000
Message-Id: <512F1AA802000078000C1C9D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:51:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
In-Reply-To: <1336583579.20130227185059@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 27.02.13 at 18:50, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> 
>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> find the origin of this return value by instrumenting the involved
>> call tree.
> 
> Just wondering, is multiple msi's per device actually supported by xen ?

No, it isn't; only MSI-X is. But that should be irrelevant to your
case, as iirc one of the quirk related messages your logs had said
something about disabling MSI mode for this controller (or even a
wider part of the system).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:52:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07:52: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 1UAyHX-0005eU-7b; Thu, 28 Feb 2013 07:51: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 1UAyHV-0005eP-5r
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:51:57 +0000
Received: from [85.158.139.211:48434] by server-4.bemta-5.messagelabs.com id
	0E/7B-01980-C9C0F215; Thu, 28 Feb 2013 07:51:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362037915!18043776!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20538 invoked from network); 28 Feb 2013 07:51:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 07:51:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:51:54 +0000
Message-Id: <512F1AA802000078000C1C9D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:51:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
In-Reply-To: <1336583579.20130227185059@eikelenboom.it>
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] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 27.02.13 at 18:50, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> 
>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> find the origin of this return value by instrumenting the involved
>> call tree.
> 
> Just wondering, is multiple msi's per device actually supported by xen ?

No, it isn't; only MSI-X is. But that should be irrelevant to your
case, as iirc one of the quirk related messages your logs had said
something about disabling MSI mode for this controller (or even a
wider part of the system).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:54:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07: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 1UAyK2-0005m1-Pj; Thu, 28 Feb 2013 07:54: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 1UAyK1-0005lw-Up
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:54:34 +0000
Received: from [85.158.143.99:60436] by server-1.bemta-4.messagelabs.com id
	C7/C4-06203-93D0F215; Thu, 28 Feb 2013 07:54:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1362038070!28970079!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5996 invoked from network); 28 Feb 2013 07:54:30 -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; 28 Feb 2013 07:54:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:54:29 +0000
Message-Id: <512F1B4202000078000C1CA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:54:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
	<1361984642.26546.400.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361984642.26546.400.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
 event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
>> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
>> > --- a/xen/include/asm-arm/types.h
>> > +++ b/xen/include/asm-arm/types.h
>> > @@ -41,10 +41,13 @@ typedef char bool_t;
>> >  #define test_and_clear_bool(b) xchg(&(b), 0)
>> >  
>> >  #endif /* __ASSEMBLY__ */
>> > +#define BYTE_BITORDER  3
>> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
>> >  
>> > -#define BITS_PER_LONG 32
>> > -#define BYTES_PER_LONG 4
>> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
>> >  #define LONG_BYTEORDER 2
>> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
>> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>> 
>> Is that all really correct and complete in the context of arm64 and
>> an ABI-long not being 32 bits on arm32?
> 
> This header is about the internal types, I think, and so should
> represent the compiler's idea of what the actual long type is for the
> benefit of common code.
> 
> Of course if these are also being used for ABI things, this is a bug on
> ARM.

Wei - could you please clarify/double check? I was under the
impression that these were used e.g. for thing like the event
channel bit maps and selector words, and those are clearly
xen_ulong_t, not unsigned long.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 07:54:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 07: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 1UAyK2-0005m1-Pj; Thu, 28 Feb 2013 07:54: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 1UAyK1-0005lw-Up
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 07:54:34 +0000
Received: from [85.158.143.99:60436] by server-1.bemta-4.messagelabs.com id
	C7/C4-06203-93D0F215; Thu, 28 Feb 2013 07:54:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1362038070!28970079!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5996 invoked from network); 28 Feb 2013 07:54:30 -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; 28 Feb 2013 07:54:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 07:54:29 +0000
Message-Id: <512F1B4202000078000C1CA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 07:54:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
	<1361984642.26546.400.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361984642.26546.400.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
 event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 18:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
>> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
>> > --- a/xen/include/asm-arm/types.h
>> > +++ b/xen/include/asm-arm/types.h
>> > @@ -41,10 +41,13 @@ typedef char bool_t;
>> >  #define test_and_clear_bool(b) xchg(&(b), 0)
>> >  
>> >  #endif /* __ASSEMBLY__ */
>> > +#define BYTE_BITORDER  3
>> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
>> >  
>> > -#define BITS_PER_LONG 32
>> > -#define BYTES_PER_LONG 4
>> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
>> >  #define LONG_BYTEORDER 2
>> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
>> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
>> 
>> Is that all really correct and complete in the context of arm64 and
>> an ABI-long not being 32 bits on arm32?
> 
> This header is about the internal types, I think, and so should
> represent the compiler's idea of what the actual long type is for the
> benefit of common code.
> 
> Of course if these are also being used for ABI things, this is a bug on
> ARM.

Wei - could you please clarify/double check? I was under the
impression that these were used e.g. for thing like the event
channel bit maps and selector words, and those are clearly
xen_ulong_t, not unsigned long.

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:06:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:06: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 1UAyUz-0006Ty-L6; Thu, 28 Feb 2013 08:05:53 +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 1UAyUy-0006Tt-AQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:05:52 +0000
Received: from [85.158.139.211:22980] by server-16.bemta-5.messagelabs.com id
	A2/92-02543-FDF0F215; Thu, 28 Feb 2013 08:05:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1362038750!19708908!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5178 invoked from network); 28 Feb 2013 08:05:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 08:05:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 08:05:50 +0000
Message-Id: <512F1DE202000078000C1CB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 08:05:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Xen/MCA: bugfix for mca bank clear
> 
> mcabank_clear() is common code for real h/w mca and s/w simulated mca.
> Under s/w simulated case, getting status via mca_rdmsr may trigger #GP
> if MCx_ADDR/MISC not supported by real h/w.
> 
> This patch fix the bug. It always invalidates intpose for s/w simulated
> mca case, and do check real h/w status ADDRV/MISCV to avoid #GP when
> clear MCx_ADDR/MISC for h/w mca case.
> 
> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> 
> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 08:05:15 2013 +0800
> @@ -138,17 +138,28 @@
>      xfree(banks);
>  }
>  
> +/*
> + * Common code for real h/w mca and s/w simulated mca.
> + * Always invalidate intpose for s/w simulated mca case, and do check
> + * real h/w status ADDRV/MISCV to avoid #GP when clear MCx_ADDR/MISC
> + * for h/w mca case.
> + */
>  static void mcabank_clear(int banknum)
>  {
> -    uint64_t status;
> +    uint64_t hw_status;
>  
> -    status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
> +    /* For s/w simulated mca case */
> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_ADDR(banknum));
> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_MISC(banknum));

And no invalidation of MSR_IA32_MCx_STATUS(banknum)?

>  
> -    if (status & MCi_STATUS_ADDRV)
> -        mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
> -    if (status & MCi_STATUS_MISCV)
> -        mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
> +    /* For real h/w mca case */
> +    rdmsrl(MSR_IA32_MCx_STATUS(banknum), hw_status);
> +    if (hw_status & MCi_STATUS_ADDRV)
> +        wrmsrl(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
> +    if (hw_status & MCi_STATUS_MISCV)
> +        wrmsrl(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
>  
> +    /* For both cases */
>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);

Oh, that happens as a side effect of this one. Not really obvious,
so likely worth a comment.

>  }
>  

But anyway, I don't think that's quite right either: For one, I'm not
sure the ordering of the MSR writes can be freely exchanged
(originally you cleared STATUS first, while now it's done last).

And then I don't see why you would do physical MSR accesses in
the injection case at all. It should really be mca_wrmsr() to take
care of this, it just needs to have a way to know it got called in
the context of an injection. One fundamental question here is
why the invalidation of the interposed data is being done
before the MSR write rather than after. One thing we surely
don't care much about in the injection logic is interference with
a real #MC.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:06:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:06: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 1UAyUz-0006Ty-L6; Thu, 28 Feb 2013 08:05:53 +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 1UAyUy-0006Tt-AQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:05:52 +0000
Received: from [85.158.139.211:22980] by server-16.bemta-5.messagelabs.com id
	A2/92-02543-FDF0F215; Thu, 28 Feb 2013 08:05:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1362038750!19708908!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5178 invoked from network); 28 Feb 2013 08:05:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 08:05:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 08:05:50 +0000
Message-Id: <512F1DE202000078000C1CB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 08:05:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Xen/MCA: bugfix for mca bank clear
> 
> mcabank_clear() is common code for real h/w mca and s/w simulated mca.
> Under s/w simulated case, getting status via mca_rdmsr may trigger #GP
> if MCx_ADDR/MISC not supported by real h/w.
> 
> This patch fix the bug. It always invalidates intpose for s/w simulated
> mca case, and do check real h/w status ADDRV/MISCV to avoid #GP when
> clear MCx_ADDR/MISC for h/w mca case.
> 
> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> 
> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 08:05:15 2013 +0800
> @@ -138,17 +138,28 @@
>      xfree(banks);
>  }
>  
> +/*
> + * Common code for real h/w mca and s/w simulated mca.
> + * Always invalidate intpose for s/w simulated mca case, and do check
> + * real h/w status ADDRV/MISCV to avoid #GP when clear MCx_ADDR/MISC
> + * for h/w mca case.
> + */
>  static void mcabank_clear(int banknum)
>  {
> -    uint64_t status;
> +    uint64_t hw_status;
>  
> -    status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
> +    /* For s/w simulated mca case */
> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_ADDR(banknum));
> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_MISC(banknum));

And no invalidation of MSR_IA32_MCx_STATUS(banknum)?

>  
> -    if (status & MCi_STATUS_ADDRV)
> -        mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
> -    if (status & MCi_STATUS_MISCV)
> -        mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
> +    /* For real h/w mca case */
> +    rdmsrl(MSR_IA32_MCx_STATUS(banknum), hw_status);
> +    if (hw_status & MCi_STATUS_ADDRV)
> +        wrmsrl(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
> +    if (hw_status & MCi_STATUS_MISCV)
> +        wrmsrl(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
>  
> +    /* For both cases */
>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);

Oh, that happens as a side effect of this one. Not really obvious,
so likely worth a comment.

>  }
>  

But anyway, I don't think that's quite right either: For one, I'm not
sure the ordering of the MSR writes can be freely exchanged
(originally you cleared STATUS first, while now it's done last).

And then I don't see why you would do physical MSR accesses in
the injection case at all. It should really be mca_wrmsr() to take
care of this, it just needs to have a way to know it got called in
the context of an injection. One fundamental question here is
why the invalidation of the interposed data is being done
before the MSR write rather than after. One thing we surely
don't care much about in the injection logic is interference with
a real #MC.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:16:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:16: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 1UAyef-0006hI-Vi; Thu, 28 Feb 2013 08:15:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAyef-0006hD-1O
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:15:53 +0000
Received: from [85.158.137.99:15679] by server-6.bemta-3.messagelabs.com id
	03/36-11048-8321F215; Thu, 28 Feb 2013 08:15:52 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-217.messagelabs.com!1362039351!13382704!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18432 invoked from network); 28 Feb 2013 08:15:51 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-7.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2013 08:15:51 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:49268 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 1UAycT-0005rs-Ab; Thu, 28 Feb 2013 09:13:37 +0100
Date: Thu, 28 Feb 2013 09:15:45 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1304487778.20130228091545@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512F1AA802000078000C1C9D@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<512F1AA802000078000C1C9D@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Thursday, February 28, 2013, 8:51:52 AM, you wrote:

>>>> On 27.02.13 at 18:50, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> 
>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>>> find the origin of this return value by instrumenting the involved
>>> call tree.
>> 
>> Just wondering, is multiple msi's per device actually supported by xen ?

> No, it isn't; only MSI-X is. But that should be irrelevant to your
> case, as iirc one of the quirk related messages your logs had said
> something about disabling MSI mode for this controller (or even a
> wider part of the system).

Ah you seem to refer to the line:   [   24.957481] pci 0000:00:11.0: calling quirk_msi_intx_disable_ati_bug+0x0/0x50
That one threw me off as well, but it seems it's only "Calling" the quirk, comments in the code make it clear it's only for the SB700, i have a SB850.

And the "no it isn't" seems to be quite relevant in my case and in general, see later mails and the associated commits .. (all merged very earlier in this merge window and the ahci changes not via the ahci tree ...)

--
Sander

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:16:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:16: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 1UAyef-0006hI-Vi; Thu, 28 Feb 2013 08:15:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1UAyef-0006hD-1O
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:15:53 +0000
Received: from [85.158.137.99:15679] by server-6.bemta-3.messagelabs.com id
	03/36-11048-8321F215; Thu, 28 Feb 2013 08:15:52 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-217.messagelabs.com!1362039351!13382704!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18432 invoked from network); 28 Feb 2013 08:15:51 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-7.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2013 08:15:51 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:49268 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 1UAycT-0005rs-Ab; Thu, 28 Feb 2013 09:13:37 +0100
Date: Thu, 28 Feb 2013 09:15:45 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1304487778.20130228091545@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <512F1AA802000078000C1C9D@nat28.tlf.novell.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<512F1AA802000078000C1C9D@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Thursday, February 28, 2013, 8:51:52 AM, you wrote:

>>>> On 27.02.13 at 18:50, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> 
>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>>> find the origin of this return value by instrumenting the involved
>>> call tree.
>> 
>> Just wondering, is multiple msi's per device actually supported by xen ?

> No, it isn't; only MSI-X is. But that should be irrelevant to your
> case, as iirc one of the quirk related messages your logs had said
> something about disabling MSI mode for this controller (or even a
> wider part of the system).

Ah you seem to refer to the line:   [   24.957481] pci 0000:00:11.0: calling quirk_msi_intx_disable_ati_bug+0x0/0x50
That one threw me off as well, but it seems it's only "Calling" the quirk, comments in the code make it clear it's only for the SB700, i have a SB850.

And the "no it isn't" seems to be quite relevant in my case and in general, see later mails and the associated commits .. (all merged very earlier in this merge window and the ahci changes not via the ahci tree ...)

--
Sander

> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:26:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:26: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 1UAyoi-0006uW-A6; Thu, 28 Feb 2013 08:26:16 +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 1UAyog-0006uR-O1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:26:14 +0000
Received: from [85.158.139.83:26778] by server-2.bemta-5.messagelabs.com id
	80/1F-23989-5A41F215; Thu, 28 Feb 2013 08:26:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1362039972!27679222!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18396 invoked from network); 28 Feb 2013 08:26:13 -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; 28 Feb 2013 08:26:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 08:26:12 +0000
Message-Id: <512F22B202000078000C1CC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 08:26:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CDAA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540CDAA@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Minor fix for rdmsrl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:46, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Minor fix for rdmsrl
> 
> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>

I applied this one, but could you clarify whether the stray
semicolon caused any actual problem? I'm mainly asking to
determine whether this needs backporting.

Jan

> --- a/xen/include/asm-x86/msr.h	Thu Feb 28 08:05:15 2013 +0800
> +++ b/xen/include/asm-x86/msr.h	Thu Feb 28 08:15:17 2013 +0800
> @@ -20,7 +20,7 @@
>  			    : "=a" (a__), "=d" (b__) \
>  			    : "c" (msr)); \
>         val = a__ | ((u64)b__<<32); \
> -} while(0);
> +} while(0)
>  
>  #define wrmsr(msr,val1,val2) \
>       __asm__ __volatile__("wrmsr" \




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:26:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:26: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 1UAyoi-0006uW-A6; Thu, 28 Feb 2013 08:26:16 +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 1UAyog-0006uR-O1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:26:14 +0000
Received: from [85.158.139.83:26778] by server-2.bemta-5.messagelabs.com id
	80/1F-23989-5A41F215; Thu, 28 Feb 2013 08:26:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1362039972!27679222!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18396 invoked from network); 28 Feb 2013 08:26:13 -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; 28 Feb 2013 08:26:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 08:26:12 +0000
Message-Id: <512F22B202000078000C1CC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 08:26:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CDAA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540CDAA@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Minor fix for rdmsrl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:46, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Minor fix for rdmsrl
> 
> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>

I applied this one, but could you clarify whether the stray
semicolon caused any actual problem? I'm mainly asking to
determine whether this needs backporting.

Jan

> --- a/xen/include/asm-x86/msr.h	Thu Feb 28 08:05:15 2013 +0800
> +++ b/xen/include/asm-x86/msr.h	Thu Feb 28 08:15:17 2013 +0800
> @@ -20,7 +20,7 @@
>  			    : "=a" (a__), "=d" (b__) \
>  			    : "c" (msr)); \
>         val = a__ | ((u64)b__<<32); \
> -} while(0);
> +} while(0)
>  
>  #define wrmsr(msr,val1,val2) \
>       __asm__ __volatile__("wrmsr" \




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:39:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:39: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 1UAz1O-00079e-Sx; Thu, 28 Feb 2013 08:39: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 1UAz1N-00079Z-Ib
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:39:21 +0000
Received: from [193.109.254.147:11025] by server-14.bemta-14.messagelabs.com
	id E6/ED-02031-8B71F215; Thu, 28 Feb 2013 08:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1362040604!2286395!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7504 invoked from network); 28 Feb 2013 08:36:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 08:36:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2002438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 08:35:41 +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.297.1;
	Thu, 28 Feb 2013 08:35:39 +0000
Message-ID: <1362040538.23384.12.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 28 Feb 2013 08:35:38 +0000
In-Reply-To: <512F1B4202000078000C1CA0@nat28.tlf.novell.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
	<1361984642.26546.400.camel@zakaz.uk.xensource.com>
	<512F1B4202000078000C1CA0@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
	event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 07:54 +0000, Jan Beulich wrote:
> Wei - could you please clarify/double check? I was under the
> impression that these were used e.g. for thing like the event
> channel bit maps and selector words, and those are clearly
> xen_ulong_t, not unsigned long.

This is fixed by
<1361970894-12965-1-git-send-email-ian.campbell@citrix.com> "xen:
correct BITS_PER_EVTCHN_WORD on arm" which is not yet applied only
because I'm supposed to be packing for my trip to Linaro Connect and not
checking email ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:39:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:39: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 1UAz1O-00079e-Sx; Thu, 28 Feb 2013 08:39: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 1UAz1N-00079Z-Ib
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:39:21 +0000
Received: from [193.109.254.147:11025] by server-14.bemta-14.messagelabs.com
	id E6/ED-02031-8B71F215; Thu, 28 Feb 2013 08:39:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1362040604!2286395!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7504 invoked from network); 28 Feb 2013 08:36:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 08:36:45 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2002438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 08:35:41 +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.297.1;
	Thu, 28 Feb 2013 08:35:39 +0000
Message-ID: <1362040538.23384.12.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 28 Feb 2013 08:35:38 +0000
In-Reply-To: <512F1B4202000078000C1CA0@nat28.tlf.novell.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
	<1361984642.26546.400.camel@zakaz.uk.xensource.com>
	<512F1B4202000078000C1CA0@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
	event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 07:54 +0000, Jan Beulich wrote:
> Wei - could you please clarify/double check? I was under the
> impression that these were used e.g. for thing like the event
> channel bit maps and selector words, and those are clearly
> xen_ulong_t, not unsigned long.

This is fixed by
<1361970894-12965-1-git-send-email-ian.campbell@citrix.com> "xen:
correct BITS_PER_EVTCHN_WORD on arm" which is not yet applied only
because I'm supposed to be packing for my trip to Linaro Connect and not
checking email ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:47:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:47: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 1UAz9F-0007MY-RW; Thu, 28 Feb 2013 08:47:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAz9E-0007MT-Lw
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:47:28 +0000
Received: from [85.158.139.83:34211] by server-9.bemta-5.messagelabs.com id
	84/6A-08547-F991F215; Thu, 28 Feb 2013 08:47:27 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1362041241!29642402!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyMDgyMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2148 invoked from network); 28 Feb 2013 08:47:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 08:47:23 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 28 Feb 2013 00:47:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,754,1355126400"; d="scan'208";a="297071868"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 28 Feb 2013 00:41:03 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 00:41:01 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 16:40:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 2/2] Minor fix for rdmsrl
Thread-Index: AQHOFY1DaDPIeN3VQXC+k/Nn+vsjXZiO8zqg
Date: Thu, 28 Feb 2013 08:40:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540D7A8@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CDAA@SHSMSX101.ccr.corp.intel.com>
	<512F22B202000078000C1CC6@nat28.tlf.novell.com>
In-Reply-To: <512F22B202000078000C1CC6@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Minor fix for rdmsrl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 17:46, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>> wrote: Minor fix for rdmsrl 
>> 
>> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> 
> I applied this one, but could you clarify whether the stray
> semicolon caused any actual problem? I'm mainly asking to
> determine whether this needs backporting.
> 
> Jan

No need backporting, just minor cleanup to drop unnecessary ';'

Thanks,
Jinsong

> 
>> --- a/xen/include/asm-x86/msr.h	Thu Feb 28 08:05:15 2013 +0800
>> +++ b/xen/include/asm-x86/msr.h	Thu Feb 28 08:15:17 2013 +0800 @@
>>  			    -20,7 +20,7 @@ : "=a" (a__), "=d" (b__) \
>>  			    : "c" (msr)); \
>>         val = a__ | ((u64)b__<<32); \
>> -} while(0);
>> +} while(0)
>> 
>>  #define wrmsr(msr,val1,val2) \
>>       __asm__ __volatile__("wrmsr" \


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:47:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:47: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 1UAz9F-0007MY-RW; Thu, 28 Feb 2013 08:47:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAz9E-0007MT-Lw
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:47:28 +0000
Received: from [85.158.139.83:34211] by server-9.bemta-5.messagelabs.com id
	84/6A-08547-F991F215; Thu, 28 Feb 2013 08:47:27 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1362041241!29642402!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyMDgyMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2148 invoked from network); 28 Feb 2013 08:47:23 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 08:47:23 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 28 Feb 2013 00:47:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,754,1355126400"; d="scan'208";a="297071868"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 28 Feb 2013 00:41:03 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 00:41:01 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 16:40:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 2/2] Minor fix for rdmsrl
Thread-Index: AQHOFY1DaDPIeN3VQXC+k/Nn+vsjXZiO8zqg
Date: Thu, 28 Feb 2013 08:40:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540D7A8@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CDAA@SHSMSX101.ccr.corp.intel.com>
	<512F22B202000078000C1CC6@nat28.tlf.novell.com>
In-Reply-To: <512F22B202000078000C1CC6@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] Minor fix for rdmsrl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 17:46, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>> wrote: Minor fix for rdmsrl 
>> 
>> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
> 
> I applied this one, but could you clarify whether the stray
> semicolon caused any actual problem? I'm mainly asking to
> determine whether this needs backporting.
> 
> Jan

No need backporting, just minor cleanup to drop unnecessary ';'

Thanks,
Jinsong

> 
>> --- a/xen/include/asm-x86/msr.h	Thu Feb 28 08:05:15 2013 +0800
>> +++ b/xen/include/asm-x86/msr.h	Thu Feb 28 08:15:17 2013 +0800 @@
>>  			    -20,7 +20,7 @@ : "=a" (a__), "=d" (b__) \
>>  			    : "c" (msr)); \
>>         val = a__ | ((u64)b__<<32); \
>> -} while(0);
>> +} while(0)
>> 
>>  #define wrmsr(msr,val1,val2) \
>>       __asm__ __volatile__("wrmsr" \


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:50:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:50: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 1UAzC0-0007Sj-F4; Thu, 28 Feb 2013 08:50:20 +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 1UAzBy-0007Sb-Nw
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:50:18 +0000
Received: from [85.158.137.99:29484] by server-11.bemta-3.messagelabs.com id
	0D/2D-01263-54A1F215; Thu, 28 Feb 2013 08:50:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1362041410!15103541!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17740 invoked from network); 28 Feb 2013 08:50:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 08:50:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 08:50:10 +0000
Message-Id: <512F285102000078000C1CE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 08:50:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Matthew Daley" <mattjd@gmail.com>
References: <1362017145-8046-1-git-send-email-mattjd@gmail.com>
In-Reply-To: <1362017145-8046-1-git-send-email-mattjd@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: fix domain unlocking in some xsm error
 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

>>> On 28.02.13 at 03:05, Matthew Daley <mattjd@gmail.com> wrote:
> A couple of xsm error/access-denied code paths in hypercalls neglect to
> unlock a previously locked domain. Fix by ensuring the domains are
> unlocked correctly.
> 
> Signed-off-by: Matthew Daley <mattjd@gmail.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
>  
>      ret = xsm_map_domain_pirq(XSM_TARGET, d);
>      if ( ret )
> -        return ret;
> +        goto free_domain;
>  
>      /* Verify or get irq. */
>      switch ( type )

So it looks like this is a regression from Daniel's recent XSM rework.

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2283,7 +2283,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
>      rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
>      if ( rc ) {
>          op.status = GNTST_permission_denied;
> -        goto out1;
> +        goto out2;
>      }
>  
>      gt = d->grant_table;

Whereas this is something that is broken already in 4.2 (but not in
4.1). I'll try to remember to pick this up for 4.2 once it got applied
and came out of staging.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:50:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:50: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 1UAzC0-0007Sj-F4; Thu, 28 Feb 2013 08:50:20 +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 1UAzBy-0007Sb-Nw
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:50:18 +0000
Received: from [85.158.137.99:29484] by server-11.bemta-3.messagelabs.com id
	0D/2D-01263-54A1F215; Thu, 28 Feb 2013 08:50:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1362041410!15103541!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17740 invoked from network); 28 Feb 2013 08:50:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 08:50:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 08:50:10 +0000
Message-Id: <512F285102000078000C1CE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 08:50:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Matthew Daley" <mattjd@gmail.com>
References: <1362017145-8046-1-git-send-email-mattjd@gmail.com>
In-Reply-To: <1362017145-8046-1-git-send-email-mattjd@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: fix domain unlocking in some xsm error
 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

>>> On 28.02.13 at 03:05, Matthew Daley <mattjd@gmail.com> wrote:
> A couple of xsm error/access-denied code paths in hypercalls neglect to
> unlock a previously locked domain. Fix by ensuring the domains are
> unlocked correctly.
> 
> Signed-off-by: Matthew Daley <mattjd@gmail.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -111,7 +111,7 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
>  
>      ret = xsm_map_domain_pirq(XSM_TARGET, d);
>      if ( ret )
> -        return ret;
> +        goto free_domain;
>  
>      /* Verify or get irq. */
>      switch ( type )

So it looks like this is a regression from Daniel's recent XSM rework.

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2283,7 +2283,7 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
>      rc = xsm_grant_setup(XSM_TARGET, current->domain, d);
>      if ( rc ) {
>          op.status = GNTST_permission_denied;
> -        goto out1;
> +        goto out2;
>      }
>  
>      gt = d->grant_table;

Whereas this is something that is broken already in 4.2 (but not in
4.1). I'll try to remember to pick this up for 4.2 once it got applied
and came out of staging.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:51:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:51: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 1UAzDF-0007ZT-UZ; Thu, 28 Feb 2013 08: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 1UAzDE-0007ZG-P2
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 08:51:37 +0000
Received: from [85.158.139.211:47403] by server-4.bemta-5.messagelabs.com id
	A1/A7-01980-89A1F215; Thu, 28 Feb 2013 08:51:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362041472!18054236!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6745 invoked from network); 28 Feb 2013 08:51:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 08:51:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2003588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 08:51: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.297.1; Thu, 28 Feb 2013 08:51:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAzCp-0004H6-N1;
	Thu, 28 Feb 2013 08:51:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAzCp-0002vZ-Av;
	Thu, 28 Feb 2013 08:51:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16767-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 08:51:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16767: 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 16767 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16767/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel 10 guest-destroy             fail pass in 16762
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16762 pass in 16767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 16762 like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-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-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=6c7bb5a198de5cfd3f720e2376c7aa184d61329e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6c7bb5a198de5cfd3f720e2376c7aa184d61329e
+ branch=xen-unstable
+ revision=6c7bb5a198de5cfd3f720e2376c7aa184d61329e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 6c7bb5a198de5cfd3f720e2376c7aa184d61329e:master
Counting objects: 1   
Counting objects: 3   
Counting objects: 5   
Counting objects: 9   
Counting objects: 19   
Counting objects: 28   
Counting objects: 38   
Counting objects: 65   
Counting objects: 171   
Counting objects: 416   
Counting objects: 693   
Counting objects: 940   
Counting objects: 1662, done.
Compressing objects:   0% (1/607)   
Compressing objects:   1% (7/607)   
Compressing objects:   2% (13/607)   
Compressing objects:   3% (19/607)   
Compressing objects:   4% (25/607)   
Compressing objects:   5% (31/607)   
Compressing objects:   6% (37/607)   
Compressing objects:   7% (43/607)   
Compressing objects:   8% (49/607)   
Compressing objects:   9% (55/607)   
Compressing objects:  10% (61/607)   
Compressing objects:  11% (67/607)   
Compressing objects:  12% (73/607)   
Compressing objects:  13% (79/607)   
Compressing objects:  14% (85/607)   
Compressing objects:  15% (92/607)   
Compressing objects:  16% (98/607)   
Compressing objects:  17% (104/607)   
Compressing objects:  18% (110/607)   
Compressing objects:  19% (116/607)   
Compressing objects:  20% (122/607)   
Compressing objects:  21% (128/607)   
Compressing objects:  22% (134/607)   
Compressing objects:  23% (140/607)   
Compressing objects:  24% (146/607)   
Compressing objects:  25% (152/607)   
Compressing objects:  26% (158/607)   
Compressing objects:  27% (164/607)   
Compressing objects:  28% (170/607)   
Compressing objects:  29% (177/607)   
Compressing objects:  30% (183/607)   
Compressing objects:  31% (189/607)   
Compressing objects:  32% (195/607)   
Compressing objects:  33% (201/607)   
Compressing objects:  34% (207/607)   
Compressing objects:  35% (213/607)   
Compressing objects:  36% (219/607)   
Compressing objects:  37% (225/607)   
Compressing objects:  38% (231/607)   
Compressing objects:  39% (237/607)   
Compressing objects:  40% (243/607)   
Compressing objects:  41% (249/607)   
Compressing objects:  42% (255/607)   
Compressing objects:  43% (262/607)   
Compressing objects:  44% (268/607)   
Compressing objects:  45% (274/607)   
Compressing objects:  46% (280/607)   
Compressing objects:  47% (286/607)   
Compressing objects:  48% (292/607)   
Compressing objects:  49% (298/607)   
Compressing objects:  50% (304/607)   
Compressing objects:  51% (310/607)   
Compressing objects:  52% (316/607)   
Compressing objects:  53% (322/607)   
Compressing objects:  54% (328/607)   
Compressing objects:  55% (334/607)   
Compressing objects:  56% (340/607)   
Compressing objects:  57% (346/607)   
Compressing objects:  58% (353/607)   
Compressing objects:  59% (359/607)   
Compressing objects:  60% (365/607)   
Compressing objects:  61% (371/607)   
Compressing objects:  62% (377/607)   
Compressing objects:  63% (383/607)   
Compressing objects:  64% (389/607)   
Compressing objects:  65% (395/607)   
Compressing objects:  66% (401/607)   
Compressing objects:  67% (407/607)   
Compressing objects:  68% (413/607)   
Compressing objects:  69% (419/607)   
Compressing objects:  70% (425/607)   
Compressing objects:  71% (431/607)   
Compressing objects:  72% (438/607)   
Compressing objects:  73% (444/607)   
Compressing objects:  74% (450/607)   
Compressing objects:  75% (456/607)   
Compressing objects:  76% (462/607)   
Compressing objects:  77% (468/607)   
Compressing objects:  78% (474/607)   
Compressing objects:  79% (480/607)   
Compressing objects:  80% (486/607)   
Compressing objects:  81% (492/607)   
Compressing objects:  82% (498/607)   
Compressing objects:  83% (504/607)   
Compressing objects:  84% (510/607)   
Compressing objects:  85% (516/607)   
Compressing objects:  86% (523/607)   
Compressing objects:  87% (529/607)   
Compressing objects:  88% (535/607)   
Compressing objects:  89% (541/607)   
Compressing objects:  90% (547/607)   
Compressing objects:  91% (553/607)   
Compressing objects:  92% (559/607)   
Compressing objects:  93% (565/607)   
Compressing objects:  94% (571/607)   
Compressing objects:  95% (577/607)   
Compressing objects:  96% (583/607)   
Compressing objects:  97% (589/607)   
Compressing objects:  98% (595/607)   
Compressing objects:  99% (601/607)   
Compressing objects: 100% (607/607)   
Compressing objects: 100% (607/607), done.
Writing objects:   0% (1/1184)   
Writing objects:   1% (12/1184)   
Writing objects:   2% (24/1184)   
Writing objects:   3% (36/1184)   
Writing objects:   4% (48/1184)   
Writing objects:   5% (60/1184)   
Writing objects:   6% (72/1184)   
Writing objects:   7% (83/1184)   
Writing objects:   8% (95/1184)   
Writing objects:   9% (107/1184)   
Writing objects:  10% (120/1184)   
Writing objects:  11% (131/1184)   
Writing objects:  12% (143/1184)   
Writing objects:  13% (154/1184)   
Writing objects:  14% (166/1184)   
Writing objects:  15% (179/1184)   
Writing objects:  16% (190/1184)   
Writing objects:  17% (202/1184)   
Writing objects:  18% (214/1184)   
Writing objects:  19% (225/1184)   
Writing objects:  20% (237/1184)   
Writing objects:  21% (249/1184)   
Writing objects:  22% (262/1184)   
Writing objects:  23% (273/1184)   
Writing objects:  24% (286/1184)   
Writing objects:  25% (296/1184)   
Writing objects:  26% (308/1184)   
Writing objects:  27% (321/1184)   
Writing objects:  28% (332/1184)   
Writing objects:  29% (344/1184)   
Writing objects:  30% (356/1184)   
Writing objects:  31% (368/1184)   
Writing objects:  32% (379/1184)   
Writing objects:  33% (391/1184)   
Writing objects:  34% (403/1184)   
Writing objects:  35% (415/1184)   
Writing objects:  36% (427/1184)   
Writing objects:  37% (439/1184)   
Writing objects:  38% (450/1184)   
Writing objects:  39% (462/1184)   
Writing objects:  40% (474/1184)   
Writing objects:  41% (487/1184)   
Writing objects:  42% (498/1184)   
Writing objects:  43% (510/1184)   
Writing objects:  44% (521/1184)   
Writing objects:  45% (533/1184)   
Writing objects:  46% (545/1184)   
Writing objects:  47% (557/1184)   
Writing objects:  48% (569/1184)   
Writing objects:  49% (581/1184)   
Writing objects:  50% (592/1184)   
Writing objects:  51% (604/1184)   
Writing objects:  52% (617/1184)   
Writing objects:  53% (628/1184)   
Writing objects:  54% (640/1184)   
Writing objects:  55% (652/1184)   
Writing objects:  56% (664/1184)   
Writing objects:  57% (675/1184)   
Writing objects:  58% (687/1184)   
Writing objects:  59% (699/1184)   
Writing objects:  60% (711/1184)   
Writing objects:  61% (723/1184)   
Writing objects:  62% (735/1184)   
Writing objects:  63% (746/1184)   
Writing objects:  64% (758/1184)   
Writing objects:  65% (770/1184)   
Writing objects:  66% (782/1184)   
Writing objects:  67% (794/1184)   
Writing objects:  68% (806/1184)   
Writing objects:  69% (817/1184)   
Writing objects:  70% (829/1184)   
Writing objects:  71% (841/1184)   
Writing objects:  72% (853/1184)   
Writing objects:  73% (865/1184)   
Writing objects:  74% (877/1184)   
Writing objects:  75% (888/1184)   
Writing objects:  76% (900/1184)   
Writing objects:  77% (912/1184)   
Writing objects:  78% (924/1184)   
Writing objects:  79% (936/1184)   
Writing objects:  80% (948/1184)   
Writing objects:  81% (960/1184)   
Writing objects:  82% (971/1184)   
Writing objects:  83% (983/1184)   
Writing objects:  84% (995/1184)   
Writing objects:  85% (1007/1184)   
Writing objects:  86% (1019/1184)   
Writing objects:  87% (1031/1184)   
Writing objects:  88% (1042/1184)   
Writing objects:  89% (1054/1184)   
Writing objects:  90% (1066/1184)   
Writing objects:  91% (1078/1184)   
Writing objects:  92% (1090/1184)   
Writing objects:  93% (1102/1184)   
Writing objects:  94% (1113/1184)   
Writing objects:  95% (1125/1184)   
Writing objects:  96% (1137/1184)   
Writing objects:  97% (1149/1184)   
Writing objects:  98% (1161/1184)   
Writing objects:  99% (1173/1184)   
Writing objects: 100% (1184/1184)   
Writing objects: 100% (1184/1184), 673.17 KiB, done.
Total 1184 (delta 797), reused 953 (delta 566)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   fb034f4..6c7bb5a  6c7bb5a198de5cfd3f720e2376c7aa184d61329e -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:51:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:51: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 1UAzDF-0007ZT-UZ; Thu, 28 Feb 2013 08: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 1UAzDE-0007ZG-P2
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 08:51:37 +0000
Received: from [85.158.139.211:47403] by server-4.bemta-5.messagelabs.com id
	A1/A7-01980-89A1F215; Thu, 28 Feb 2013 08:51:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362041472!18054236!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6745 invoked from network); 28 Feb 2013 08:51:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 08:51:12 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2003588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 08:51: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.297.1; Thu, 28 Feb 2013 08:51:11 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UAzCp-0004H6-N1;
	Thu, 28 Feb 2013 08:51:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UAzCp-0002vZ-Av;
	Thu, 28 Feb 2013 08:51:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16767-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 08:51:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16767: 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 16767 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16767/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel 10 guest-destroy             fail pass in 16762
 test-amd64-i386-xl-win7-amd64 12 guest-localmigrate/x10 fail in 16762 pass in 16767

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16226
 test-amd64-amd64-xl-sedf-pin  7 debian-install           fail blocked in 16226
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16226
 test-amd64-amd64-xl-sedf-pin  5 xen-boot              fail in 16762 like 16226

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-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-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e
baseline version:
 xen                  fb034f42648ecac835a1666def468f673edd2725

------------------------------------------------------------
People who touched revisions under test:
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=6c7bb5a198de5cfd3f720e2376c7aa184d61329e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 6c7bb5a198de5cfd3f720e2376c7aa184d61329e
+ branch=xen-unstable
+ revision=6c7bb5a198de5cfd3f720e2376c7aa184d61329e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git 6c7bb5a198de5cfd3f720e2376c7aa184d61329e:master
Counting objects: 1   
Counting objects: 3   
Counting objects: 5   
Counting objects: 9   
Counting objects: 19   
Counting objects: 28   
Counting objects: 38   
Counting objects: 65   
Counting objects: 171   
Counting objects: 416   
Counting objects: 693   
Counting objects: 940   
Counting objects: 1662, done.
Compressing objects:   0% (1/607)   
Compressing objects:   1% (7/607)   
Compressing objects:   2% (13/607)   
Compressing objects:   3% (19/607)   
Compressing objects:   4% (25/607)   
Compressing objects:   5% (31/607)   
Compressing objects:   6% (37/607)   
Compressing objects:   7% (43/607)   
Compressing objects:   8% (49/607)   
Compressing objects:   9% (55/607)   
Compressing objects:  10% (61/607)   
Compressing objects:  11% (67/607)   
Compressing objects:  12% (73/607)   
Compressing objects:  13% (79/607)   
Compressing objects:  14% (85/607)   
Compressing objects:  15% (92/607)   
Compressing objects:  16% (98/607)   
Compressing objects:  17% (104/607)   
Compressing objects:  18% (110/607)   
Compressing objects:  19% (116/607)   
Compressing objects:  20% (122/607)   
Compressing objects:  21% (128/607)   
Compressing objects:  22% (134/607)   
Compressing objects:  23% (140/607)   
Compressing objects:  24% (146/607)   
Compressing objects:  25% (152/607)   
Compressing objects:  26% (158/607)   
Compressing objects:  27% (164/607)   
Compressing objects:  28% (170/607)   
Compressing objects:  29% (177/607)   
Compressing objects:  30% (183/607)   
Compressing objects:  31% (189/607)   
Compressing objects:  32% (195/607)   
Compressing objects:  33% (201/607)   
Compressing objects:  34% (207/607)   
Compressing objects:  35% (213/607)   
Compressing objects:  36% (219/607)   
Compressing objects:  37% (225/607)   
Compressing objects:  38% (231/607)   
Compressing objects:  39% (237/607)   
Compressing objects:  40% (243/607)   
Compressing objects:  41% (249/607)   
Compressing objects:  42% (255/607)   
Compressing objects:  43% (262/607)   
Compressing objects:  44% (268/607)   
Compressing objects:  45% (274/607)   
Compressing objects:  46% (280/607)   
Compressing objects:  47% (286/607)   
Compressing objects:  48% (292/607)   
Compressing objects:  49% (298/607)   
Compressing objects:  50% (304/607)   
Compressing objects:  51% (310/607)   
Compressing objects:  52% (316/607)   
Compressing objects:  53% (322/607)   
Compressing objects:  54% (328/607)   
Compressing objects:  55% (334/607)   
Compressing objects:  56% (340/607)   
Compressing objects:  57% (346/607)   
Compressing objects:  58% (353/607)   
Compressing objects:  59% (359/607)   
Compressing objects:  60% (365/607)   
Compressing objects:  61% (371/607)   
Compressing objects:  62% (377/607)   
Compressing objects:  63% (383/607)   
Compressing objects:  64% (389/607)   
Compressing objects:  65% (395/607)   
Compressing objects:  66% (401/607)   
Compressing objects:  67% (407/607)   
Compressing objects:  68% (413/607)   
Compressing objects:  69% (419/607)   
Compressing objects:  70% (425/607)   
Compressing objects:  71% (431/607)   
Compressing objects:  72% (438/607)   
Compressing objects:  73% (444/607)   
Compressing objects:  74% (450/607)   
Compressing objects:  75% (456/607)   
Compressing objects:  76% (462/607)   
Compressing objects:  77% (468/607)   
Compressing objects:  78% (474/607)   
Compressing objects:  79% (480/607)   
Compressing objects:  80% (486/607)   
Compressing objects:  81% (492/607)   
Compressing objects:  82% (498/607)   
Compressing objects:  83% (504/607)   
Compressing objects:  84% (510/607)   
Compressing objects:  85% (516/607)   
Compressing objects:  86% (523/607)   
Compressing objects:  87% (529/607)   
Compressing objects:  88% (535/607)   
Compressing objects:  89% (541/607)   
Compressing objects:  90% (547/607)   
Compressing objects:  91% (553/607)   
Compressing objects:  92% (559/607)   
Compressing objects:  93% (565/607)   
Compressing objects:  94% (571/607)   
Compressing objects:  95% (577/607)   
Compressing objects:  96% (583/607)   
Compressing objects:  97% (589/607)   
Compressing objects:  98% (595/607)   
Compressing objects:  99% (601/607)   
Compressing objects: 100% (607/607)   
Compressing objects: 100% (607/607), done.
Writing objects:   0% (1/1184)   
Writing objects:   1% (12/1184)   
Writing objects:   2% (24/1184)   
Writing objects:   3% (36/1184)   
Writing objects:   4% (48/1184)   
Writing objects:   5% (60/1184)   
Writing objects:   6% (72/1184)   
Writing objects:   7% (83/1184)   
Writing objects:   8% (95/1184)   
Writing objects:   9% (107/1184)   
Writing objects:  10% (120/1184)   
Writing objects:  11% (131/1184)   
Writing objects:  12% (143/1184)   
Writing objects:  13% (154/1184)   
Writing objects:  14% (166/1184)   
Writing objects:  15% (179/1184)   
Writing objects:  16% (190/1184)   
Writing objects:  17% (202/1184)   
Writing objects:  18% (214/1184)   
Writing objects:  19% (225/1184)   
Writing objects:  20% (237/1184)   
Writing objects:  21% (249/1184)   
Writing objects:  22% (262/1184)   
Writing objects:  23% (273/1184)   
Writing objects:  24% (286/1184)   
Writing objects:  25% (296/1184)   
Writing objects:  26% (308/1184)   
Writing objects:  27% (321/1184)   
Writing objects:  28% (332/1184)   
Writing objects:  29% (344/1184)   
Writing objects:  30% (356/1184)   
Writing objects:  31% (368/1184)   
Writing objects:  32% (379/1184)   
Writing objects:  33% (391/1184)   
Writing objects:  34% (403/1184)   
Writing objects:  35% (415/1184)   
Writing objects:  36% (427/1184)   
Writing objects:  37% (439/1184)   
Writing objects:  38% (450/1184)   
Writing objects:  39% (462/1184)   
Writing objects:  40% (474/1184)   
Writing objects:  41% (487/1184)   
Writing objects:  42% (498/1184)   
Writing objects:  43% (510/1184)   
Writing objects:  44% (521/1184)   
Writing objects:  45% (533/1184)   
Writing objects:  46% (545/1184)   
Writing objects:  47% (557/1184)   
Writing objects:  48% (569/1184)   
Writing objects:  49% (581/1184)   
Writing objects:  50% (592/1184)   
Writing objects:  51% (604/1184)   
Writing objects:  52% (617/1184)   
Writing objects:  53% (628/1184)   
Writing objects:  54% (640/1184)   
Writing objects:  55% (652/1184)   
Writing objects:  56% (664/1184)   
Writing objects:  57% (675/1184)   
Writing objects:  58% (687/1184)   
Writing objects:  59% (699/1184)   
Writing objects:  60% (711/1184)   
Writing objects:  61% (723/1184)   
Writing objects:  62% (735/1184)   
Writing objects:  63% (746/1184)   
Writing objects:  64% (758/1184)   
Writing objects:  65% (770/1184)   
Writing objects:  66% (782/1184)   
Writing objects:  67% (794/1184)   
Writing objects:  68% (806/1184)   
Writing objects:  69% (817/1184)   
Writing objects:  70% (829/1184)   
Writing objects:  71% (841/1184)   
Writing objects:  72% (853/1184)   
Writing objects:  73% (865/1184)   
Writing objects:  74% (877/1184)   
Writing objects:  75% (888/1184)   
Writing objects:  76% (900/1184)   
Writing objects:  77% (912/1184)   
Writing objects:  78% (924/1184)   
Writing objects:  79% (936/1184)   
Writing objects:  80% (948/1184)   
Writing objects:  81% (960/1184)   
Writing objects:  82% (971/1184)   
Writing objects:  83% (983/1184)   
Writing objects:  84% (995/1184)   
Writing objects:  85% (1007/1184)   
Writing objects:  86% (1019/1184)   
Writing objects:  87% (1031/1184)   
Writing objects:  88% (1042/1184)   
Writing objects:  89% (1054/1184)   
Writing objects:  90% (1066/1184)   
Writing objects:  91% (1078/1184)   
Writing objects:  92% (1090/1184)   
Writing objects:  93% (1102/1184)   
Writing objects:  94% (1113/1184)   
Writing objects:  95% (1125/1184)   
Writing objects:  96% (1137/1184)   
Writing objects:  97% (1149/1184)   
Writing objects:  98% (1161/1184)   
Writing objects:  99% (1173/1184)   
Writing objects: 100% (1184/1184)   
Writing objects: 100% (1184/1184), 673.17 KiB, done.
Total 1184 (delta 797), reused 953 (delta 566)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   fb034f4..6c7bb5a  6c7bb5a198de5cfd3f720e2376c7aa184d61329e -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 08:57:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:57: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 1UAzIf-00083E-6t; Thu, 28 Feb 2013 08:57:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAzId-00082j-HW
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:57:11 +0000
Received: from [85.158.139.83:58875] by server-15.bemta-5.messagelabs.com id
	10/B4-22815-6EB1F215; Thu, 28 Feb 2013 08:57:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362041829!22189609!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg5OTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20668 invoked from network); 28 Feb 2013 08:57:10 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 08:57:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 28 Feb 2013 00:55:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,754,1355126400"; d="scan'208";a="268961124"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga001.jf.intel.com with ESMTP; 28 Feb 2013 00:57:04 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 00:57:04 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 00:57:04 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 16:57:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
Thread-Index: AQHOFYpkXArdsC0/T2GFEhh+i5sJSZiO87bQ
Date: Thu, 28 Feb 2013 08:57:01 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540D803@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
In-Reply-To: <512F1DE202000078000C1CB4@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 17:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Xen/MCA: bugfix for mca bank clear
>> 
>> mcabank_clear() is common code for real h/w mca and s/w simulated
>> mca. Under s/w simulated case, getting status via mca_rdmsr may
>> trigger #GP if MCx_ADDR/MISC not supported by real h/w.
>> 
>> This patch fix the bug. It always invalidates intpose for s/w
>> simulated mca case, and do check real h/w status ADDRV/MISCV to
>> avoid #GP when clear MCx_ADDR/MISC for h/w mca case.
>> 
>> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
>> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
>> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 08:05:15 2013 +0800
>>      @@ -138,17 +138,28 @@ xfree(banks);
>>  }
>> 
>> +/*
>> + * Common code for real h/w mca and s/w simulated mca.
>> + * Always invalidate intpose for s/w simulated mca case, and do
>> check + * real h/w status ADDRV/MISCV to avoid #GP when clear
>> MCx_ADDR/MISC + * for h/w mca case. + */
>>  static void mcabank_clear(int banknum)
>>  {
>> -    uint64_t status;
>> +    uint64_t hw_status;
>> 
>> -    status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
>> +    /* For s/w simulated mca case */
>> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_ADDR(banknum));
>> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_MISC(banknum));
> 
> And no invalidation of MSR_IA32_MCx_STATUS(banknum)?
> 
>> 
>> -    if (status & MCi_STATUS_ADDRV)
>> -        mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>> -    if (status & MCi_STATUS_MISCV)
>> -        mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
>> +    /* For real h/w mca case */
>> +    rdmsrl(MSR_IA32_MCx_STATUS(banknum), hw_status);
>> +    if (hw_status & MCi_STATUS_ADDRV)
>> +        wrmsrl(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>> +    if (hw_status & MCi_STATUS_MISCV)
>> +        wrmsrl(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
>> 
>> +    /* For both cases */
>>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
> 
> Oh, that happens as a side effect of this one. Not really obvious,
> so likely worth a comment.

OK.

> 
>>  }
>> 
> 
> But anyway, I don't think that's quite right either: For one, I'm not
> sure the ordering of the MSR writes can be freely exchanged
> (originally you cleared STATUS first, while now it's done last).

OK, adjust sequence strictly according to SDM.

> 
> And then I don't see why you would do physical MSR accesses in
> the injection case at all. It should really be mca_wrmsr() to take
> care of this, it just needs to have a way to know it got called in
> the context of an injection. One fundamental question here is
> why the invalidation of the interposed data is being done
> before the MSR write rather than after. One thing we surely
> don't care much about in the injection logic is interference with
> a real #MC.
> 
> Jan

A way (say, a global bool flag) could be used to indicate s/w injection.
Our concern here is, if s/w inject occur while real h/w mce, it may be race condition.
But if you think it's OK to tolerate it, it's OK for me.

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 Feb 28 08:57:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 08:57: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 1UAzIf-00083E-6t; Thu, 28 Feb 2013 08:57:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1UAzId-00082j-HW
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 08:57:11 +0000
Received: from [85.158.139.83:58875] by server-15.bemta-5.messagelabs.com id
	10/B4-22815-6EB1F215; Thu, 28 Feb 2013 08:57:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362041829!22189609!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzg5OTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20668 invoked from network); 28 Feb 2013 08:57:10 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 08:57:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 28 Feb 2013 00:55:44 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,754,1355126400"; d="scan'208";a="268961124"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga001.jf.intel.com with ESMTP; 28 Feb 2013 00:57:04 -0800
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 00:57:04 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 00:57:04 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 16:57:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
Thread-Index: AQHOFYpkXArdsC0/T2GFEhh+i5sJSZiO87bQ
Date: Thu, 28 Feb 2013 08:57:01 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540D803@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
In-Reply-To: <512F1DE202000078000C1CB4@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 27.02.13 at 17:44, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Xen/MCA: bugfix for mca bank clear
>> 
>> mcabank_clear() is common code for real h/w mca and s/w simulated
>> mca. Under s/w simulated case, getting status via mca_rdmsr may
>> trigger #GP if MCx_ADDR/MISC not supported by real h/w.
>> 
>> This patch fix the bug. It always invalidates intpose for s/w
>> simulated mca case, and do check real h/w status ADDRV/MISCV to
>> avoid #GP when clear MCx_ADDR/MISC for h/w mca case.
>> 
>> Reported-by: Ren Yongjie <yongjie.ren@intel.com>
>> Singed-off-by: Liu Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r e84a79d11d7a xen/arch/x86/cpu/mcheck/mce.c
>> --- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Nov 01 01:41:03 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Feb 28 08:05:15 2013 +0800
>>      @@ -138,17 +138,28 @@ xfree(banks);
>>  }
>> 
>> +/*
>> + * Common code for real h/w mca and s/w simulated mca.
>> + * Always invalidate intpose for s/w simulated mca case, and do
>> check + * real h/w status ADDRV/MISCV to avoid #GP when clear
>> MCx_ADDR/MISC + * for h/w mca case. + */
>>  static void mcabank_clear(int banknum)
>>  {
>> -    uint64_t status;
>> +    uint64_t hw_status;
>> 
>> -    status = mca_rdmsr(MSR_IA32_MCx_STATUS(banknum));
>> +    /* For s/w simulated mca case */
>> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_ADDR(banknum));
>> +    intpose_inval(smp_processor_id(), MSR_IA32_MCx_MISC(banknum));
> 
> And no invalidation of MSR_IA32_MCx_STATUS(banknum)?
> 
>> 
>> -    if (status & MCi_STATUS_ADDRV)
>> -        mca_wrmsr(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>> -    if (status & MCi_STATUS_MISCV)
>> -        mca_wrmsr(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
>> +    /* For real h/w mca case */
>> +    rdmsrl(MSR_IA32_MCx_STATUS(banknum), hw_status);
>> +    if (hw_status & MCi_STATUS_ADDRV)
>> +        wrmsrl(MSR_IA32_MCx_ADDR(banknum), 0x0ULL);
>> +    if (hw_status & MCi_STATUS_MISCV)
>> +        wrmsrl(MSR_IA32_MCx_MISC(banknum), 0x0ULL);
>> 
>> +    /* For both cases */
>>      mca_wrmsr(MSR_IA32_MCx_STATUS(banknum), 0x0ULL);
> 
> Oh, that happens as a side effect of this one. Not really obvious,
> so likely worth a comment.

OK.

> 
>>  }
>> 
> 
> But anyway, I don't think that's quite right either: For one, I'm not
> sure the ordering of the MSR writes can be freely exchanged
> (originally you cleared STATUS first, while now it's done last).

OK, adjust sequence strictly according to SDM.

> 
> And then I don't see why you would do physical MSR accesses in
> the injection case at all. It should really be mca_wrmsr() to take
> care of this, it just needs to have a way to know it got called in
> the context of an injection. One fundamental question here is
> why the invalidation of the interposed data is being done
> before the MSR write rather than after. One thing we surely
> don't care much about in the injection logic is interference with
> a real #MC.
> 
> Jan

A way (say, a global bool flag) could be used to indicate s/w injection.
Our concern here is, if s/w inject occur while real h/w mce, it may be race condition.
But if you think it's OK to tolerate it, it's OK for me.

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 Feb 28 09:08:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09: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 1UAzTj-0001wf-UL; Thu, 28 Feb 2013 09:08:39 +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 1UAzTh-0001vq-Tp
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:08:38 +0000
Received: from [85.158.139.83:54835] by server-13.bemta-5.messagelabs.com id
	61/F4-16871-59E1F215; Thu, 28 Feb 2013 09:08:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1362042512!24175035!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21886 invoked from network); 28 Feb 2013 09:08:33 -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; 28 Feb 2013 09:08:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:08:32 +0000
Message-Id: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:08:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bjorn Helgaas" <bhelgaas@google.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] time periods of no resource re-assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bjorn,

in the context of dealing with the final part of a long known security
issue on Xen, I'd appreciate if you could help me understand
under what conditions (or at which times) MMIO resources for PCI
devices can get re-assigned in Linux. Or really I'm in need to know
under what conditions there won't be any resource re-assignment
(i.e. we particularly need the BARs to be stable that cover the
MSI-X table and the Pending Bit Array).

Right now I'm intending to send the hypervisor a respective
notification in the context of xen-pciback's probe function, after
having called pci_enable_device(). Can you confirm that at this
point, and until the driver lets go of the device again, resources
won't get re-assigned? Or if not, can you suggest a better point
in time for sending such a notification, or additional steps we
may need to take in order to ensure resource stability?

Thanks a lot, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:08:52 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09: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 1UAzTj-0001wf-UL; Thu, 28 Feb 2013 09:08:39 +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 1UAzTh-0001vq-Tp
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:08:38 +0000
Received: from [85.158.139.83:54835] by server-13.bemta-5.messagelabs.com id
	61/F4-16871-59E1F215; Thu, 28 Feb 2013 09:08:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1362042512!24175035!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUyNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21886 invoked from network); 28 Feb 2013 09:08:33 -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; 28 Feb 2013 09:08:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:08:32 +0000
Message-Id: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:08:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bjorn Helgaas" <bhelgaas@google.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] time periods of no resource re-assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Bjorn,

in the context of dealing with the final part of a long known security
issue on Xen, I'd appreciate if you could help me understand
under what conditions (or at which times) MMIO resources for PCI
devices can get re-assigned in Linux. Or really I'm in need to know
under what conditions there won't be any resource re-assignment
(i.e. we particularly need the BARs to be stable that cover the
MSI-X table and the Pending Bit Array).

Right now I'm intending to send the hypervisor a respective
notification in the context of xen-pciback's probe function, after
having called pci_enable_device(). Can you confirm that at this
point, and until the driver lets go of the device again, resources
won't get re-assigned? Or if not, can you suggest a better point
in time for sending such a notification, or additional steps we
may need to take in order to ensure resource stability?

Thanks a lot, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:20:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09: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 1UAzf0-0002s6-7D; Thu, 28 Feb 2013 09:20:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hossam.taqi@telepin.com>) id 1UAxoj-0004pz-P5
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 07:22:14 +0000
Received: from [85.158.139.83:21004] by server-14.bemta-5.messagelabs.com id
	FE/6D-13158-5A50F215; Thu, 28 Feb 2013 07:22:13 +0000
X-Env-Sender: hossam.taqi@telepin.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362036131!22173977!1
X-Originating-IP: [74.125.82.177]
X-SpamReason: No, hits=1.8 required=7.0 tests=RATWARE_GECKO_BUILD
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12944 invoked from network); 28 Feb 2013 07:22:11 -0000
Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com)
	(74.125.82.177)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 07:22:11 -0000
Received: by mail-we0-f177.google.com with SMTP id d7so1218855wer.8
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Feb 2013 23:22:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=m10aRJ3z/z+Ip55i/cPDmC44wAv3hAB2PhxEUbf91+0=;
	b=O/1k5hDuL4AYOoH0hIXCEHB2ors75Xz5wrkXuZ/n29ZdFDrsCCMwBW8wAQSxBesFlq
	nQBtD6EI8F0rJozpE4fMAvU22/5uTZvjZC6d6xoQ23mjEUOmCGtAgBC8dp64XOsoxG/4
	5kpeKsDWB/Y34D63ZPLCE3eysIfQzhrY+1KFCBA4jy4j8HHDK2WRVhrfti/tEIbz++af
	CbrfeGgV/LAx6kMJWTuUah9gy8Qgg8QSTr+0OeyLhNquUt2QK2iLklvOWwzFutcaJXmm
	pnf8VfBaeY7FKYQgA3fxPDq1wAlobqe0zo6uCG+FAd2ISeRnYBe15LuYtN3Q+m26MmIQ
	xLRg==
X-Received: by 10.180.78.135 with SMTP id b7mr30677854wix.14.1362036131138;
	Wed, 27 Feb 2013 23:22:11 -0800 (PST)
Received: from [10.20.0.59] ([41.65.129.190])
	by mx.google.com with ESMTPS id fx5sm13366283wib.11.2013.02.27.23.22.09
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 23:22:10 -0800 (PST)
Message-ID: <512F058C.7030206@telepin.com>
Date: Thu, 28 Feb 2013 09:21:48 +0200
From: Hossam <hossam.taqi@telepin.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQka0pv7nDBnLJBORi/cgM9gjW/zZfmtElC1fbzCFy5M28XU9bUk+iRCxqVAPrI1EVN1BRJt
X-Mailman-Approved-At: Thu, 28 Feb 2013 09:20:17 +0000
Subject: [Xen-devel] ImportError: No module named lxml
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Dears  ,

i need  you support  as    i got  the  following error :

  #xm new -f 
/OVS/Repositories/0004fb0000030000505b685a936d0faf/VirtualMachines/0004fb00000600001dfb6cf4b6258355/vm.cfg
Unexpected error: exceptions.ImportError

Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
   File "/usr/sbin/xm", line 7, in ?
     main.main(sys.argv)
   File "/usr/lib64/python2.4/site-packages/xen/xm/main.py", line 3983, 
in main
     _, rc = _run_cmd(cmd, cmd_name, args)
   File "/usr/lib64/python2.4/site-packages/xen/xm/main.py", line 4007, 
in _run_cmd
     return True, cmd(args)
   File "<string>", line 1, in <lambda>
   File "/usr/lib64/python2.4/site-packages/xen/xm/main.py", line 1518, 
in xm_importcommand
     cmd = __import__(command, globals(), locals(), 'xen.xm')
   File "/usr/lib64/python2.4/site-packages/xen/xm/new.py", line 26, in ?
     from xen.xm.xenapi_create import *
   File "/usr/lib64/python2.4/site-packages/xen/xm/xenapi_create.py", 
line 25, in ?
     from lxml import etree
ImportError: No module named lxml


Thank you in advance ,
Regards,
Hossam

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:20:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09: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 1UAzf0-0002s6-7D; Thu, 28 Feb 2013 09:20:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hossam.taqi@telepin.com>) id 1UAxoj-0004pz-P5
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 07:22:14 +0000
Received: from [85.158.139.83:21004] by server-14.bemta-5.messagelabs.com id
	FE/6D-13158-5A50F215; Thu, 28 Feb 2013 07:22:13 +0000
X-Env-Sender: hossam.taqi@telepin.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362036131!22173977!1
X-Originating-IP: [74.125.82.177]
X-SpamReason: No, hits=1.8 required=7.0 tests=RATWARE_GECKO_BUILD
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12944 invoked from network); 28 Feb 2013 07:22:11 -0000
Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com)
	(74.125.82.177)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 07:22:11 -0000
Received: by mail-we0-f177.google.com with SMTP id d7so1218855wer.8
	for <xen-devel@lists.xensource.com>;
	Wed, 27 Feb 2013 23:22:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=m10aRJ3z/z+Ip55i/cPDmC44wAv3hAB2PhxEUbf91+0=;
	b=O/1k5hDuL4AYOoH0hIXCEHB2ors75Xz5wrkXuZ/n29ZdFDrsCCMwBW8wAQSxBesFlq
	nQBtD6EI8F0rJozpE4fMAvU22/5uTZvjZC6d6xoQ23mjEUOmCGtAgBC8dp64XOsoxG/4
	5kpeKsDWB/Y34D63ZPLCE3eysIfQzhrY+1KFCBA4jy4j8HHDK2WRVhrfti/tEIbz++af
	CbrfeGgV/LAx6kMJWTuUah9gy8Qgg8QSTr+0OeyLhNquUt2QK2iLklvOWwzFutcaJXmm
	pnf8VfBaeY7FKYQgA3fxPDq1wAlobqe0zo6uCG+FAd2ISeRnYBe15LuYtN3Q+m26MmIQ
	xLRg==
X-Received: by 10.180.78.135 with SMTP id b7mr30677854wix.14.1362036131138;
	Wed, 27 Feb 2013 23:22:11 -0800 (PST)
Received: from [10.20.0.59] ([41.65.129.190])
	by mx.google.com with ESMTPS id fx5sm13366283wib.11.2013.02.27.23.22.09
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 27 Feb 2013 23:22:10 -0800 (PST)
Message-ID: <512F058C.7030206@telepin.com>
Date: Thu, 28 Feb 2013 09:21:48 +0200
From: Hossam <hossam.taqi@telepin.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQka0pv7nDBnLJBORi/cgM9gjW/zZfmtElC1fbzCFy5M28XU9bUk+iRCxqVAPrI1EVN1BRJt
X-Mailman-Approved-At: Thu, 28 Feb 2013 09:20:17 +0000
Subject: [Xen-devel] ImportError: No module named lxml
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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

Dears  ,

i need  you support  as    i got  the  following error :

  #xm new -f 
/OVS/Repositories/0004fb0000030000505b685a936d0faf/VirtualMachines/0004fb00000600001dfb6cf4b6258355/vm.cfg
Unexpected error: exceptions.ImportError

Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
   File "/usr/sbin/xm", line 7, in ?
     main.main(sys.argv)
   File "/usr/lib64/python2.4/site-packages/xen/xm/main.py", line 3983, 
in main
     _, rc = _run_cmd(cmd, cmd_name, args)
   File "/usr/lib64/python2.4/site-packages/xen/xm/main.py", line 4007, 
in _run_cmd
     return True, cmd(args)
   File "<string>", line 1, in <lambda>
   File "/usr/lib64/python2.4/site-packages/xen/xm/main.py", line 1518, 
in xm_importcommand
     cmd = __import__(command, globals(), locals(), 'xen.xm')
   File "/usr/lib64/python2.4/site-packages/xen/xm/new.py", line 26, in ?
     from xen.xm.xenapi_create import *
   File "/usr/lib64/python2.4/site-packages/xen/xm/xenapi_create.py", 
line 25, in ?
     from lxml import etree
ImportError: No module named lxml


Thank you in advance ,
Regards,
Hossam

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:22:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:22: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 1UAzhJ-00034P-P0; Thu, 28 Feb 2013 09:22:41 +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 1UAzhH-00034C-Sv
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:22:40 +0000
Received: from [85.158.139.211:4116] by server-13.bemta-5.messagelabs.com id
	14/2A-16871-FD12F215; Thu, 28 Feb 2013 09:22:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1362043357!19688535!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2096 invoked from network); 28 Feb 2013 09:22:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 09:22:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:22:36 +0000
Message-Id: <512F2FEA02000078000C1D17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:22:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Haitao Shan" <haitao.shan@intel.com>,<xiantao.zhang@intel.com>,
	"Keir Fraser" <keir@xen.org>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
In-Reply-To: <5113776602000078000BCB8F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 07.02.13 at 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>> This adds two new physdev operations for Dom0 to invoke when resource
>> allocation for devices is known to be complete, so that the hypervisor
>> can arrange for the respective MMIO ranges to be marked read-only
>> before an eventual guest getting such a device assigned even gets
>> started, such that it won't be able to set up writable mappings for
>> these MMIO ranges before Xen has a chance to protect them.
> 
> I should probably mention the alternatives:
> 
> 1) Brute force scan of the (PV) guest's L1 page tables, locating
> eventual mappings of the questionable MMIO pages, and
> converting those mappings to R/O ones.
> 
> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
> guest_io_write(), taking note of which BAR(s) are relevant at the
> point where the device gets first detected/reported), perhaps
> along with snoops of the PCI_COMMAND_MEMORY bit.

So I just now sent a mail to Linux'es PCI subsystem maintainer,
assuming that we'll go with the approach the patch presented at
the start of this thread. The outcome of this, however, is not
really relevant for the hypervisor side change to go in, as it
would only affect the placement of the new hypercall within
pciback or the core PCI subsystem.

That assumption is largely because no-one really voiced an opinion
towards a preference of one of the alternatives described above.

Unless I'll receive an explicit NAK or further comments moving this
discussion forward, I'm intending to commit the patch without
anyone's ACK in a few days time _and_ backport it to the stable
trees (4.2 at least, not sure how well it will backport to 4.1).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:22:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:22: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 1UAzhJ-00034P-P0; Thu, 28 Feb 2013 09:22:41 +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 1UAzhH-00034C-Sv
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:22:40 +0000
Received: from [85.158.139.211:4116] by server-13.bemta-5.messagelabs.com id
	14/2A-16871-FD12F215; Thu, 28 Feb 2013 09:22:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1362043357!19688535!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2096 invoked from network); 28 Feb 2013 09:22:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 09:22:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:22:36 +0000
Message-Id: <512F2FEA02000078000C1D17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:22:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Haitao Shan" <haitao.shan@intel.com>,<xiantao.zhang@intel.com>,
	"Keir Fraser" <keir@xen.org>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
In-Reply-To: <5113776602000078000BCB8F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: [PATCH] x86/MSI: add mechanism to protect MSI-X
 table from PV guest 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 07.02.13 at 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>> This adds two new physdev operations for Dom0 to invoke when resource
>> allocation for devices is known to be complete, so that the hypervisor
>> can arrange for the respective MMIO ranges to be marked read-only
>> before an eventual guest getting such a device assigned even gets
>> started, such that it won't be able to set up writable mappings for
>> these MMIO ranges before Xen has a chance to protect them.
> 
> I should probably mention the alternatives:
> 
> 1) Brute force scan of the (PV) guest's L1 page tables, locating
> eventual mappings of the questionable MMIO pages, and
> converting those mappings to R/O ones.
> 
> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
> guest_io_write(), taking note of which BAR(s) are relevant at the
> point where the device gets first detected/reported), perhaps
> along with snoops of the PCI_COMMAND_MEMORY bit.

So I just now sent a mail to Linux'es PCI subsystem maintainer,
assuming that we'll go with the approach the patch presented at
the start of this thread. The outcome of this, however, is not
really relevant for the hypervisor side change to go in, as it
would only affect the placement of the new hypercall within
pciback or the core PCI subsystem.

That assumption is largely because no-one really voiced an opinion
towards a preference of one of the alternatives described above.

Unless I'll receive an explicit NAK or further comments moving this
discussion forward, I'm intending to commit the patch without
anyone's ACK in a few days time _and_ backport it to the stable
trees (4.2 at least, not sure how well it will backport to 4.1).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:23:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:23: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 1UAzhn-00037y-68; Thu, 28 Feb 2013 09:23:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAzhm-00037m-DZ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:23:10 +0000
Received: from [85.158.139.83:15446] by server-2.bemta-5.messagelabs.com id
	E1/A5-23989-DF12F215; Thu, 28 Feb 2013 09:23:09 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-182.messagelabs.com!1362043319!28710220!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22816 invoked from network); 28 Feb 2013 09:21:59 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 09:21:59 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 00252C5619C;
	Thu, 28 Feb 2013 09:21:26 +0000 (GMT)
Date: Thu, 28 Feb 2013 09:21:25 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <3018F0D4E05C1D04A1B3A166@nimrod.local>
In-Reply-To: <512F15E402000078000C1C87@nat28.tlf.novell.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Jan,

--On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com>
>> wrote:
>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>>> at the beginning of next week.
>>
>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
>> a blktrace.
>
> To me, the title you mention means nothing. It being on the tools
> side, it would be Ian anyway to take care of this, but can't you be
> a bit more specific and indicate which changeset/commit you're
> talking of? As well as reasoning why it would be needed (or at
> least desirable) to have on either or both trees?

See this message and the surrounding thread:
  http://markmail.org/message/iy32akdzmbjo7uiz

In essence any domU PV disk usage backended onto something that uses TCP
(e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
this 100%. The root cause is a very-hard-to-fix skb refcount problem
in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
xendisk driver. People seemed generally happy with this provided the
barriers get through (which I need to demonstrate).

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:23:21 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:23: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 1UAzhn-00037y-68; Thu, 28 Feb 2013 09:23:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UAzhm-00037m-DZ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:23:10 +0000
Received: from [85.158.139.83:15446] by server-2.bemta-5.messagelabs.com id
	E1/A5-23989-DF12F215; Thu, 28 Feb 2013 09:23:09 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-9.tower-182.messagelabs.com!1362043319!28710220!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22816 invoked from network); 28 Feb 2013 09:21:59 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-9.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 09:21:59 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 00252C5619C;
	Thu, 28 Feb 2013 09:21:26 +0000 (GMT)
Date: Thu, 28 Feb 2013 09:21:25 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <3018F0D4E05C1D04A1B3A166@nimrod.local>
In-Reply-To: <512F15E402000078000C1C87@nat28.tlf.novell.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Jan,

--On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com>
>> wrote:
>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>>> at the beginning of next week.
>>
>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
>> a blktrace.
>
> To me, the title you mention means nothing. It being on the tools
> side, it would be Ian anyway to take care of this, but can't you be
> a bit more specific and indicate which changeset/commit you're
> talking of? As well as reasoning why it would be needed (or at
> least desirable) to have on either or both trees?

See this message and the surrounding thread:
  http://markmail.org/message/iy32akdzmbjo7uiz

In essence any domU PV disk usage backended onto something that uses TCP
(e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
this 100%. The root cause is a very-hard-to-fix skb refcount problem
in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
xendisk driver. People seemed generally happy with this provided the
barriers get through (which I need to demonstrate).

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:33:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:33: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 1UAzrK-0003Zx-BU; Thu, 28 Feb 2013 09:33:02 +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 1UAzrI-0003Zq-F9
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:33:00 +0000
Received: from [85.158.139.211:9775] by server-9.bemta-5.messagelabs.com id
	23/42-08547-B442F215; Thu, 28 Feb 2013 09:32:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362043956!19506578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20179 invoked from network); 28 Feb 2013 09:32:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 09:32:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:32:35 +0000
Message-Id: <512F324202000078000C1D37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:32:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Bligh" <alex@alex.org.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
	<3018F0D4E05C1D04A1B3A166@nimrod.local>
In-Reply-To: <3018F0D4E05C1D04A1B3A166@nimrod.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 28.02.13 at 10:21, Alex Bligh <alex@alex.org.uk> wrote:
> Jan,
> 
> --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
>>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com>
>>> wrote:
>>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>>>> at the beginning of next week.
>>>
>>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
>>> a blktrace.
>>
>> To me, the title you mention means nothing. It being on the tools
>> side, it would be Ian anyway to take care of this, but can't you be
>> a bit more specific and indicate which changeset/commit you're
>> talking of? As well as reasoning why it would be needed (or at
>> least desirable) to have on either or both trees?
> 
> See this message and the surrounding thread:
>   http://markmail.org/message/iy32akdzmbjo7uiz 
> 
> In essence any domU PV disk usage backended onto something that uses TCP
> (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
> this 100%. The root cause is a very-hard-to-fix skb refcount problem
> in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
> xendisk driver. People seemed generally happy with this provided the
> barriers get through (which I need to demonstrate).

Oh, that would actually be Stefano, not Ian then.

And it doesn't look like you're asking for a backport - neither
upstream qemu nor either of our trees appears to have the
suggested change yet. If the change doesn't go into any of
these, there's no way for it to go into a stable release.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:33:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:33: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 1UAzrK-0003Zx-BU; Thu, 28 Feb 2013 09:33:02 +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 1UAzrI-0003Zq-F9
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:33:00 +0000
Received: from [85.158.139.211:9775] by server-9.bemta-5.messagelabs.com id
	23/42-08547-B442F215; Thu, 28 Feb 2013 09:32:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362043956!19506578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20179 invoked from network); 28 Feb 2013 09:32:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 09:32:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:32:35 +0000
Message-Id: <512F324202000078000C1D37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:32:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alex Bligh" <alex@alex.org.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
	<3018F0D4E05C1D04A1B3A166@nimrod.local>
In-Reply-To: <3018F0D4E05C1D04A1B3A166@nimrod.local>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 28.02.13 at 10:21, Alex Bligh <alex@alex.org.uk> wrote:
> Jan,
> 
> --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
>>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com>
>>> wrote:
>>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>>>> at the beginning of next week.
>>>
>>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
>>> a blktrace.
>>
>> To me, the title you mention means nothing. It being on the tools
>> side, it would be Ian anyway to take care of this, but can't you be
>> a bit more specific and indicate which changeset/commit you're
>> talking of? As well as reasoning why it would be needed (or at
>> least desirable) to have on either or both trees?
> 
> See this message and the surrounding thread:
>   http://markmail.org/message/iy32akdzmbjo7uiz 
> 
> In essence any domU PV disk usage backended onto something that uses TCP
> (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
> this 100%. The root cause is a very-hard-to-fix skb refcount problem
> in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
> xendisk driver. People seemed generally happy with this provided the
> barriers get through (which I need to demonstrate).

Oh, that would actually be Stefano, not Ian then.

And it doesn't look like you're asking for a backport - neither
upstream qemu nor either of our trees appears to have the
suggested change yet. If the change doesn't go into any of
these, there's no way for it to go into a stable release.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:39:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UAzxV-0003kk-5x; Thu, 28 Feb 2013 09:39:25 +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 1UAzxT-0003kf-Sk
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 09:39:23 +0000
Received: from [85.158.139.83:62668] by server-15.bemta-5.messagelabs.com id
	43/79-22815-BC52F215; Thu, 28 Feb 2013 09:39:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1362044362!29441564!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10998 invoked from network); 28 Feb 2013 09:39:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 09:39:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalLlLc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-158.pools.arcor-ip.net [88.65.85.158])
	by smtp.strato.de (jorabe mo47) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K048b0p1S8UfIZ ;
	Thu, 28 Feb 2013 10:39:21 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D4DAD1884C; Thu, 28 Feb 2013 10:39:20 +0100 (CET)
Date: Thu, 28 Feb 2013 10:39:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hossam <hossam.taqi@telepin.com>
Message-ID: <20130228093920.GA25380@aepfle.de>
References: <512F058C.7030206@telepin.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F058C.7030206@telepin.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ImportError: No module named lxml
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: xen-devel@lists.xensource.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, Feb 28, Hossam wrote:

> ImportError: No module named lxml

Install python-lxml, this is usually enforced by package dependencies.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:39:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UAzxV-0003kk-5x; Thu, 28 Feb 2013 09:39:25 +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 1UAzxT-0003kf-Sk
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 09:39:23 +0000
Received: from [85.158.139.83:62668] by server-15.bemta-5.messagelabs.com id
	43/79-22815-BC52F215; Thu, 28 Feb 2013 09:39:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1362044362!29441564!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10998 invoked from network); 28 Feb 2013 09:39:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 09:39:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalLlLc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-158.pools.arcor-ip.net [88.65.85.158])
	by smtp.strato.de (jorabe mo47) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K048b0p1S8UfIZ ;
	Thu, 28 Feb 2013 10:39:21 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D4DAD1884C; Thu, 28 Feb 2013 10:39:20 +0100 (CET)
Date: Thu, 28 Feb 2013 10:39:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hossam <hossam.taqi@telepin.com>
Message-ID: <20130228093920.GA25380@aepfle.de>
References: <512F058C.7030206@telepin.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F058C.7030206@telepin.com>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ImportError: No module named lxml
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: xen-devel@lists.xensource.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, Feb 28, Hossam wrote:

> ImportError: No module named lxml

Install python-lxml, this is usually enforced by package dependencies.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:41:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:41: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 1UAzz6-0003wr-Lt; Thu, 28 Feb 2013 09:41:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1UAzz5-0003vA-Pc
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 09:41:03 +0000
Received: from [85.158.139.211:39226] by server-3.bemta-5.messagelabs.com id
	F1/3B-17256-F262F215; Thu, 28 Feb 2013 09:41:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362044461!18066148!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27757 invoked from network); 28 Feb 2013 09:41:01 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 09:41:01 -0000
Received: from p5b2e47de.dip.t-dialin.net ([91.46.71.222] 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 1UAzys-0001Qg-OA; Thu, 28 Feb 2013 09:40:50 +0000
Message-ID: <512F2615.3000007@canonical.com>
Date: Thu, 28 Feb 2013 10:40:37 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
In-Reply-To: <1361995662.23384.0.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.6
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] 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="===============1019629563283131912=="
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)
--===============1019629563283131912==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigBD233EE5489933CEAD7F8C8F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBD233EE5489933CEAD7F8C8F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 27.02.2013 21:07, Ian Campbell wrote:
> On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
>>
>> Bringing debian packaging upstream is (I believe) considered 'no bad
>> thing'.=20
>=20
> On the contrary, Debian discourages upstreams from including a debian/
> directory in their releases.
>=20
> Ian.
>=20
I would agree with Ian here. I am sorry, I have not read anything of the
previous discussion but if it is about having a simple way of getting a t=
est
package for deb (and rpm) based systems, the make target approach which i=
s not
using a debian directory sounds better. For testing you likely want just =
one
package and that does not necessarily need any documentation. And if that=
 was
done in debian/ it would make the Debian maintainers job a pain because t=
he
whole packaging is based on the orig tarball not having that directory. (=
And
FWIW Ubuntu derives from Debian, there are only changes if we really real=
ly have
to).

The kernel has a "make deb-pkg" approach as well. Though there things are=
 a
little more simple as there are less locations which can be different to =
the
normal packages. That might be much harder to achieve for the Xen (not on=
ly but
anything with a mix of binaries and libraries to be put somewhere in para=
llel
but not interfering if not wanted).

-Stefan


--------------enigBD233EE5489933CEAD7F8C8F
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLyYdAAoJEOhnXe7L7s6jYosP/2OQQWn3wIfjAhafCGAJopc1
wFy4Nyj1a/HofNdLW75FTdQc9NyhPInZ2x8ayJSWpsHGu7yF7idLdL9nqpAs6Tqh
xkkIpWXNrevPiBm6L+x++lmZaOKz/ybBGT6rSMmffawJrHHnBbZfy509VMpa2eRh
/ZE/6ql3QUVRq0GrcJ4PQBvXSFqjxSkOyNVLMhSvlDJaIWvNJOQy/OqzyJH2BejK
67vilbbiiNGUIOUelZwb59aYCEPo4veQpzpLThs0AtS/HBNgykzo0LHihyBPqvXb
F0iqAGPGB4rETxBR/9yloRKnI8Cf4KTvYa5tY+gHgFAf73cFwFatycYPMTWQs+eO
YKhO9IRuIjv0vW0JG+xW6U+7Udq/R7NWOm9QEJmGZfxiGx10riVEpGh9uzLvwNmb
HBGSgFZdx+bTDImdV8KWzt0HP5eY3EAm9dpPz8BM3k+UgHgEw5+VZ5VXOTsGyNmn
ZKQcgXthpemWo30m9lbvjjzO5F1lofdO8q8hh9Wj1pN3Ur7tPYuYzI2vIwWUDknF
ZC0eQksdZme4H0V6Wgmox5/Ch7/Z5rbQmh4wDwXlXDZ6Cm6IEcFULdfgSdB1Gl3r
LNxoU3aFPTzWnbxMUTERcx3667Y9esuVTJqchoYO+SyPKcrc9jZ0YmVyinySD58s
kTyj1XYJnkZIWiFE6Ii5
=Jcdh
-----END PGP SIGNATURE-----

--------------enigBD233EE5489933CEAD7F8C8F--


--===============1019629563283131912==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1019629563283131912==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 09:41:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:41: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 1UAzz6-0003wr-Lt; Thu, 28 Feb 2013 09:41:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1UAzz5-0003vA-Pc
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 09:41:03 +0000
Received: from [85.158.139.211:39226] by server-3.bemta-5.messagelabs.com id
	F1/3B-17256-F262F215; Thu, 28 Feb 2013 09:41:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362044461!18066148!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27757 invoked from network); 28 Feb 2013 09:41:01 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 09:41:01 -0000
Received: from p5b2e47de.dip.t-dialin.net ([91.46.71.222] 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 1UAzys-0001Qg-OA; Thu, 28 Feb 2013 09:40:50 +0000
Message-ID: <512F2615.3000007@canonical.com>
Date: Thu, 28 Feb 2013 10:40:37 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
In-Reply-To: <1361995662.23384.0.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.6
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] 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="===============1019629563283131912=="
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)
--===============1019629563283131912==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigBD233EE5489933CEAD7F8C8F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBD233EE5489933CEAD7F8C8F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 27.02.2013 21:07, Ian Campbell wrote:
> On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
>>
>> Bringing debian packaging upstream is (I believe) considered 'no bad
>> thing'.=20
>=20
> On the contrary, Debian discourages upstreams from including a debian/
> directory in their releases.
>=20
> Ian.
>=20
I would agree with Ian here. I am sorry, I have not read anything of the
previous discussion but if it is about having a simple way of getting a t=
est
package for deb (and rpm) based systems, the make target approach which i=
s not
using a debian directory sounds better. For testing you likely want just =
one
package and that does not necessarily need any documentation. And if that=
 was
done in debian/ it would make the Debian maintainers job a pain because t=
he
whole packaging is based on the orig tarball not having that directory. (=
And
FWIW Ubuntu derives from Debian, there are only changes if we really real=
ly have
to).

The kernel has a "make deb-pkg" approach as well. Though there things are=
 a
little more simple as there are less locations which can be different to =
the
normal packages. That might be much harder to achieve for the Xen (not on=
ly but
anything with a mix of binaries and libraries to be put somewhere in para=
llel
but not interfering if not wanted).

-Stefan


--------------enigBD233EE5489933CEAD7F8C8F
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 undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLyYdAAoJEOhnXe7L7s6jYosP/2OQQWn3wIfjAhafCGAJopc1
wFy4Nyj1a/HofNdLW75FTdQc9NyhPInZ2x8ayJSWpsHGu7yF7idLdL9nqpAs6Tqh
xkkIpWXNrevPiBm6L+x++lmZaOKz/ybBGT6rSMmffawJrHHnBbZfy509VMpa2eRh
/ZE/6ql3QUVRq0GrcJ4PQBvXSFqjxSkOyNVLMhSvlDJaIWvNJOQy/OqzyJH2BejK
67vilbbiiNGUIOUelZwb59aYCEPo4veQpzpLThs0AtS/HBNgykzo0LHihyBPqvXb
F0iqAGPGB4rETxBR/9yloRKnI8Cf4KTvYa5tY+gHgFAf73cFwFatycYPMTWQs+eO
YKhO9IRuIjv0vW0JG+xW6U+7Udq/R7NWOm9QEJmGZfxiGx10riVEpGh9uzLvwNmb
HBGSgFZdx+bTDImdV8KWzt0HP5eY3EAm9dpPz8BM3k+UgHgEw5+VZ5VXOTsGyNmn
ZKQcgXthpemWo30m9lbvjjzO5F1lofdO8q8hh9Wj1pN3Ur7tPYuYzI2vIwWUDknF
ZC0eQksdZme4H0V6Wgmox5/Ch7/Z5rbQmh4wDwXlXDZ6Cm6IEcFULdfgSdB1Gl3r
LNxoU3aFPTzWnbxMUTERcx3667Y9esuVTJqchoYO+SyPKcrc9jZ0YmVyinySD58s
kTyj1XYJnkZIWiFE6Ii5
=Jcdh
-----END PGP SIGNATURE-----

--------------enigBD233EE5489933CEAD7F8C8F--


--===============1019629563283131912==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1019629563283131912==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 09:58:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:58: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 1UB0Fo-0004Fd-E8; Thu, 28 Feb 2013 09:58:20 +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 1UB0Fn-0004FY-Bj
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:58:19 +0000
Received: from [85.158.138.51:17234] by server-8.bemta-3.messagelabs.com id
	D6/DB-20604-A3A2F215; Thu, 28 Feb 2013 09:58:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1362045497!29672526!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23576 invoked from network); 28 Feb 2013 09:58:17 -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; 28 Feb 2013 09:58:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:58:17 +0000
Message-Id: <512F384602000078000C1D5B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:58:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 22.11.12 at 17:12, Jan Beulich wrote:
>>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 22/11/12 15:55, Jan Beulich wrote:
> >>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> A quick solution would be to execute a noop function with
> >>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
> >>> so which does an inline iret to itself.  Which of these would you prefer?
> >> I would actually consider avoiding to run softirqs altogether in that
> >> case, just like native Linux doesn't do any event or scheduler
> >> processing in that case.
> > 
> > That would probably be the easiest solution.
> > 
> > I was already going to do the same for the rentrant NMI and MCE handling
> > case (and also the process pending upcalls checking), due to the
> > complexities of fixing the race condition at the end of the handler.
> > 
> > Unfortunately, I don't think I have time to look at this issue
> > immediately, but if it is ok to wait till the beginning of next week, I
> 
> That's fine of course.

So that was 3 months ago, and we're likely going to need to do
further unfixed releases if this won't move forward. Can you
estimate whether you'll be able to get back to this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 09:58:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 09:58: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 1UB0Fo-0004Fd-E8; Thu, 28 Feb 2013 09:58:20 +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 1UB0Fn-0004FY-Bj
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 09:58:19 +0000
Received: from [85.158.138.51:17234] by server-8.bemta-3.messagelabs.com id
	D6/DB-20604-A3A2F215; Thu, 28 Feb 2013 09:58:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1362045497!29672526!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23576 invoked from network); 28 Feb 2013 09:58:17 -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; 28 Feb 2013 09:58:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 09:58:17 +0000
Message-Id: <512F384602000078000C1D5B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 09:58:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 22.11.12 at 17:12, Jan Beulich wrote:
>>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 22/11/12 15:55, Jan Beulich wrote:
> >>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> A quick solution would be to execute a noop function with
> >>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
> >>> so which does an inline iret to itself.  Which of these would you prefer?
> >> I would actually consider avoiding to run softirqs altogether in that
> >> case, just like native Linux doesn't do any event or scheduler
> >> processing in that case.
> > 
> > That would probably be the easiest solution.
> > 
> > I was already going to do the same for the rentrant NMI and MCE handling
> > case (and also the process pending upcalls checking), due to the
> > complexities of fixing the race condition at the end of the handler.
> > 
> > Unfortunately, I don't think I have time to look at this issue
> > immediately, but if it is ok to wait till the beginning of next week, I
> 
> That's fine of course.

So that was 3 months ago, and we're likely going to need to do
further unfixed releases if this won't move forward. Can you
estimate whether you'll be able to get back to this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:00:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0Hn-0004QC-3K; Thu, 28 Feb 2013 10:00:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1UB0Hl-0004Q6-FP
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:00:21 +0000
Received: from [85.158.139.83:12613] by server-10.bemta-5.messagelabs.com id
	2C/32-23714-4BA2F215; Thu, 28 Feb 2013 10:00:20 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1362045604!25055028!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21193 invoked from network); 28 Feb 2013 10:00:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:00:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2009668"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:00:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 28 Feb 2013
	10:00:04 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 28 Feb 2013 10:00:03 +0000
Thread-Topic: [PATCH] coverage: fix on ARM
Thread-Index: Ac4VmmDugI2YHT2STm2YUtqvhs87yg==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC20105C1F7978A@LONPMAILBOX01.citrite.net>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<1361971036.26546.377.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361971036.26546.377.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: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 13:17 +0000, Ian Campbell wrote:
> On Fri, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
> > Use a list of pointers to simplify the handling of 32- vs 64-bit.
> > 
> > Also on ARM the section name is ".init_array" and not ".ctors".
> 
> Any comments/ack/nacks?
> 

Looks fine to me. Did you test it? Actually the way I test is:
- compile with coverage
- run xencov to extract information (more or less for x64 is 500k)
- check file content to see if counters increase while taking multiple
snapshot (xencov read - | hexdump -C | tail -100, counters are after
0CTX string which means "Xen Test Coverage count 0")
- reset counters (but this has nothing to do with constructors)

I actually cannot test for Arm.

Oh.. there is a missing space after a "for("

Frediano

> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
> > Cc: keir@xen.org
> > ---
> > This applies independently of my 64-bit ARM series.
> > ---
> >  xen/arch/arm/xen.lds.S |   10 ++++------
> >  xen/arch/x86/xen.lds.S |    6 ++----
> >  xen/common/lib.c       |   13 +++++--------
> >  3 files changed, 11 insertions(+), 18 deletions(-)
> > 
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 9043994..fd755d7 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -91,12 +91,10 @@ SECTIONS
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> >  
> > -       . = ALIGN(4);
> > -       __CTOR_LIST__ = .;
> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > -       *(.ctors)
> > -       LONG(0)
> > -       __CTOR_END__ = .;
> > +       . = ALIGN(8);
> > +       __ctors_start = .;
> > +       *(.init_array)
> > +       __ctors_end = .;
> >    } :text
> >    . = ALIGN(32);
> >    .init.setup : {
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index 5570389..d959941 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -110,11 +110,9 @@ SECTIONS
> >         __trampoline_seg_stop = .;
> >  
> >         . = ALIGN(8);
> > -       __CTOR_LIST__ = .;
> > -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> > +       __ctors_start = .;
> >         *(.ctors)
> > -       QUAD(0)
> > -       __CTOR_END__ = .;
> > +       __ctors_end = .;
> >    } :text
> >    . = ALIGN(32);
> >    .init.setup : {
> > diff --git a/xen/common/lib.c b/xen/common/lib.c
> > index e0c65cf..6b80601 100644
> > --- a/xen/common/lib.c
> > +++ b/xen/common/lib.c
> > @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
> >      return ret;
> >  }
> >  
> > -extern const struct
> > -{
> > -    unsigned long count;
> > -    void (*funcs[1])(void);
> > -} __CTOR_LIST__;
> > +typedef void (*ctor_func_t)(void);
> > +extern const ctor_func_t __ctors_start[], __ctors_end[];
> >  
> >  void __init init_constructors(void)
> >  {
> > -    unsigned long n;
> > -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> > -        __CTOR_LIST__.funcs[n]();
> > +    const ctor_func_t *f;
> > +    for (f = __ctors_start; f < __ctors_end; ++f )
> > +        (*f)();
> >  }
> >  
> >  /*
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:00:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0Hn-0004QC-3K; Thu, 28 Feb 2013 10:00:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <frediano.ziglio@citrix.com>) id 1UB0Hl-0004Q6-FP
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:00:21 +0000
Received: from [85.158.139.83:12613] by server-10.bemta-5.messagelabs.com id
	2C/32-23714-4BA2F215; Thu, 28 Feb 2013 10:00:20 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1362045604!25055028!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21193 invoked from network); 28 Feb 2013 10:00:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:00:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2009668"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:00:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 28 Feb 2013
	10:00:04 +0000
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 28 Feb 2013 10:00:03 +0000
Thread-Topic: [PATCH] coverage: fix on ARM
Thread-Index: Ac4VmmDugI2YHT2STm2YUtqvhs87yg==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC20105C1F7978A@LONPMAILBOX01.citrite.net>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<1361971036.26546.377.camel@zakaz.uk.xensource.com>
In-Reply-To: <1361971036.26546.377.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: Frediano Ziglio <frediano.ziglio@citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-27 at 13:17 +0000, Ian Campbell wrote:
> On Fri, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
> > Use a list of pointers to simplify the handling of 32- vs 64-bit.
> > 
> > Also on ARM the section name is ".init_array" and not ".ctors".
> 
> Any comments/ack/nacks?
> 

Looks fine to me. Did you test it? Actually the way I test is:
- compile with coverage
- run xencov to extract information (more or less for x64 is 500k)
- check file content to see if counters increase while taking multiple
snapshot (xencov read - | hexdump -C | tail -100, counters are after
0CTX string which means "Xen Test Coverage count 0")
- reset counters (but this has nothing to do with constructors)

I actually cannot test for Arm.

Oh.. there is a missing space after a "for("

Frediano

> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
> > Cc: keir@xen.org
> > ---
> > This applies independently of my 64-bit ARM series.
> > ---
> >  xen/arch/arm/xen.lds.S |   10 ++++------
> >  xen/arch/x86/xen.lds.S |    6 ++----
> >  xen/common/lib.c       |   13 +++++--------
> >  3 files changed, 11 insertions(+), 18 deletions(-)
> > 
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 9043994..fd755d7 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -91,12 +91,10 @@ SECTIONS
> >         *(.init.data.rel)
> >         *(.init.data.rel.*)
> >  
> > -       . = ALIGN(4);
> > -       __CTOR_LIST__ = .;
> > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > -       *(.ctors)
> > -       LONG(0)
> > -       __CTOR_END__ = .;
> > +       . = ALIGN(8);
> > +       __ctors_start = .;
> > +       *(.init_array)
> > +       __ctors_end = .;
> >    } :text
> >    . = ALIGN(32);
> >    .init.setup : {
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index 5570389..d959941 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -110,11 +110,9 @@ SECTIONS
> >         __trampoline_seg_stop = .;
> >  
> >         . = ALIGN(8);
> > -       __CTOR_LIST__ = .;
> > -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> > +       __ctors_start = .;
> >         *(.ctors)
> > -       QUAD(0)
> > -       __CTOR_END__ = .;
> > +       __ctors_end = .;
> >    } :text
> >    . = ALIGN(32);
> >    .init.setup : {
> > diff --git a/xen/common/lib.c b/xen/common/lib.c
> > index e0c65cf..6b80601 100644
> > --- a/xen/common/lib.c
> > +++ b/xen/common/lib.c
> > @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
> >      return ret;
> >  }
> >  
> > -extern const struct
> > -{
> > -    unsigned long count;
> > -    void (*funcs[1])(void);
> > -} __CTOR_LIST__;
> > +typedef void (*ctor_func_t)(void);
> > +extern const ctor_func_t __ctors_start[], __ctors_end[];
> >  
> >  void __init init_constructors(void)
> >  {
> > -    unsigned long n;
> > -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> > -        __CTOR_LIST__.funcs[n]();
> > +    const ctor_func_t *f;
> > +    for (f = __ctors_start; f < __ctors_end; ++f )
> > +        (*f)();
> >  }
> >  
> >  /*
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:14:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0Uu-00052U-3U; Thu, 28 Feb 2013 10:13:56 +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 1UB0Us-00052N-3s
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:13:54 +0000
Received: from [85.158.139.211:17466] by server-5.bemta-5.messagelabs.com id
	C9/CB-02762-1ED2F215; Thu, 28 Feb 2013 10:13:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1362046432!19716595!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12753 invoked from network); 28 Feb 2013 10:13:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:13:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB0Up-0007Hd-Ij; Thu, 28 Feb 2013 10:13:51 +0000
Date: Thu, 28 Feb 2013 10:13:51 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228101351.GA27704@ocelot.phlegethon.org>
References: <512DF39A02000078000C16CC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512DF39A02000078000C16CC@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: make certain memory sub-ops return
	valid values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 +0000 on 27 Feb (1361962378), Jan Beulich wrote:
> When a domain's shared info field "max_pfn" is zero,
> domain_get_maximum_gpfn() so far returned ULONG_MAX, which
> do_memory_op() in turn converted to -1 (i.e. -EPERM). Make the former
> always return a sensible number (i.e. zero if the field was zero) and
> have the latter no longer truncate return values.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Tim Deegan <tim@xen.org> 
(To the extent that this is an interface to x86/mm/ things).

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -433,7 +433,7 @@ unsigned long domain_get_maximum_gpfn(st
>      if ( is_hvm_domain(d) )
>          return p2m_get_hostp2m(d)->max_mapped_pfn;
>      /* NB. PV guests specify nr_pfns rather than max_pfn so we adjust here. */
> -    return arch_get_max_pfn(d) - 1;
> +    return (arch_get_max_pfn(d) ?: 1) - 1;
>  }
>  
>  void share_xen_page_with_guest(
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -15,7 +15,8 @@ CHECK_TYPE(domid);
>  
>  int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  {
> -    int rc, split, op = cmd & MEMOP_CMD_MASK;
> +    int split, op = cmd & MEMOP_CMD_MASK;
> +    long rc;
>      unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT;
>  
>      do
> @@ -204,7 +205,7 @@ int compat_memory_op(unsigned int cmd, X
>  
>          rc = do_memory_op(cmd, nat.hnd);
>          if ( rc < 0 )
> -            return rc;
> +            break;
>  
>          cmd = 0;
>          if ( hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )
> @@ -326,5 +327,11 @@ int compat_memory_op(unsigned int cmd, X
>                  __HYPERVISOR_memory_op, "ih", cmd, compat);
>      } while ( split > 0 );
>  
> +    if ( unlikely(rc > INT_MAX) )
> +        return INT_MAX;
> +
> +    if ( unlikely(rc < INT_MIN) )
> +        return INT_MIN;
> +
>      return rc;
>  }
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> -    int rc, op;
> +    long rc;
>      unsigned int address_bits;
>      unsigned long start_extent;
>      struct xen_memory_reservation reservation;
>      struct memop_args args;
>      domid_t domid;
> -
> -    op = cmd & MEMOP_CMD_MASK;
> +    int op = cmd & MEMOP_CMD_MASK;
>  
>      switch ( op )
>      {
> 
> 
> 

> x86: make certain memory sub-ops return valid values
> 
> When a domain's shared info field "max_pfn" is zero,
> domain_get_maximum_gpfn() so far returned ULONG_MAX, which
> do_memory_op() in turn converted to -1 (i.e. -EPERM). Make the former
> always return a sensible number (i.e. zero if the field was zero) and
> have the latter no longer truncate return values.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -433,7 +433,7 @@ unsigned long domain_get_maximum_gpfn(st
>      if ( is_hvm_domain(d) )
>          return p2m_get_hostp2m(d)->max_mapped_pfn;
>      /* NB. PV guests specify nr_pfns rather than max_pfn so we adjust here. */
> -    return arch_get_max_pfn(d) - 1;
> +    return (arch_get_max_pfn(d) ?: 1) - 1;
>  }
>  
>  void share_xen_page_with_guest(
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -15,7 +15,8 @@ CHECK_TYPE(domid);
>  
>  int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  {
> -    int rc, split, op = cmd & MEMOP_CMD_MASK;
> +    int split, op = cmd & MEMOP_CMD_MASK;
> +    long rc;
>      unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT;
>  
>      do
> @@ -204,7 +205,7 @@ int compat_memory_op(unsigned int cmd, X
>  
>          rc = do_memory_op(cmd, nat.hnd);
>          if ( rc < 0 )
> -            return rc;
> +            break;
>  
>          cmd = 0;
>          if ( hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )
> @@ -326,5 +327,11 @@ int compat_memory_op(unsigned int cmd, X
>                  __HYPERVISOR_memory_op, "ih", cmd, compat);
>      } while ( split > 0 );
>  
> +    if ( unlikely(rc > INT_MAX) )
> +        return INT_MAX;
> +
> +    if ( unlikely(rc < INT_MIN) )
> +        return INT_MIN;
> +
>      return rc;
>  }
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> -    int rc, op;
> +    long rc;
>      unsigned int address_bits;
>      unsigned long start_extent;
>      struct xen_memory_reservation reservation;
>      struct memop_args args;
>      domid_t domid;
> -
> -    op = cmd & MEMOP_CMD_MASK;
> +    int op = cmd & MEMOP_CMD_MASK;
>  
>      switch ( op )
>      {

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 28 10:14:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0Uu-00052U-3U; Thu, 28 Feb 2013 10:13:56 +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 1UB0Us-00052N-3s
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:13:54 +0000
Received: from [85.158.139.211:17466] by server-5.bemta-5.messagelabs.com id
	C9/CB-02762-1ED2F215; Thu, 28 Feb 2013 10:13:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-206.messagelabs.com!1362046432!19716595!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12753 invoked from network); 28 Feb 2013 10:13:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:13:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB0Up-0007Hd-Ij; Thu, 28 Feb 2013 10:13:51 +0000
Date: Thu, 28 Feb 2013 10:13:51 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228101351.GA27704@ocelot.phlegethon.org>
References: <512DF39A02000078000C16CC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512DF39A02000078000C16CC@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: make certain memory sub-ops return
	valid values
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 +0000 on 27 Feb (1361962378), Jan Beulich wrote:
> When a domain's shared info field "max_pfn" is zero,
> domain_get_maximum_gpfn() so far returned ULONG_MAX, which
> do_memory_op() in turn converted to -1 (i.e. -EPERM). Make the former
> always return a sensible number (i.e. zero if the field was zero) and
> have the latter no longer truncate return values.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Tim Deegan <tim@xen.org> 
(To the extent that this is an interface to x86/mm/ things).

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -433,7 +433,7 @@ unsigned long domain_get_maximum_gpfn(st
>      if ( is_hvm_domain(d) )
>          return p2m_get_hostp2m(d)->max_mapped_pfn;
>      /* NB. PV guests specify nr_pfns rather than max_pfn so we adjust here. */
> -    return arch_get_max_pfn(d) - 1;
> +    return (arch_get_max_pfn(d) ?: 1) - 1;
>  }
>  
>  void share_xen_page_with_guest(
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -15,7 +15,8 @@ CHECK_TYPE(domid);
>  
>  int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  {
> -    int rc, split, op = cmd & MEMOP_CMD_MASK;
> +    int split, op = cmd & MEMOP_CMD_MASK;
> +    long rc;
>      unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT;
>  
>      do
> @@ -204,7 +205,7 @@ int compat_memory_op(unsigned int cmd, X
>  
>          rc = do_memory_op(cmd, nat.hnd);
>          if ( rc < 0 )
> -            return rc;
> +            break;
>  
>          cmd = 0;
>          if ( hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )
> @@ -326,5 +327,11 @@ int compat_memory_op(unsigned int cmd, X
>                  __HYPERVISOR_memory_op, "ih", cmd, compat);
>      } while ( split > 0 );
>  
> +    if ( unlikely(rc > INT_MAX) )
> +        return INT_MAX;
> +
> +    if ( unlikely(rc < INT_MIN) )
> +        return INT_MIN;
> +
>      return rc;
>  }
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> -    int rc, op;
> +    long rc;
>      unsigned int address_bits;
>      unsigned long start_extent;
>      struct xen_memory_reservation reservation;
>      struct memop_args args;
>      domid_t domid;
> -
> -    op = cmd & MEMOP_CMD_MASK;
> +    int op = cmd & MEMOP_CMD_MASK;
>  
>      switch ( op )
>      {
> 
> 
> 

> x86: make certain memory sub-ops return valid values
> 
> When a domain's shared info field "max_pfn" is zero,
> domain_get_maximum_gpfn() so far returned ULONG_MAX, which
> do_memory_op() in turn converted to -1 (i.e. -EPERM). Make the former
> always return a sensible number (i.e. zero if the field was zero) and
> have the latter no longer truncate return values.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -433,7 +433,7 @@ unsigned long domain_get_maximum_gpfn(st
>      if ( is_hvm_domain(d) )
>          return p2m_get_hostp2m(d)->max_mapped_pfn;
>      /* NB. PV guests specify nr_pfns rather than max_pfn so we adjust here. */
> -    return arch_get_max_pfn(d) - 1;
> +    return (arch_get_max_pfn(d) ?: 1) - 1;
>  }
>  
>  void share_xen_page_with_guest(
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -15,7 +15,8 @@ CHECK_TYPE(domid);
>  
>  int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
>  {
> -    int rc, split, op = cmd & MEMOP_CMD_MASK;
> +    int split, op = cmd & MEMOP_CMD_MASK;
> +    long rc;
>      unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT;
>  
>      do
> @@ -204,7 +205,7 @@ int compat_memory_op(unsigned int cmd, X
>  
>          rc = do_memory_op(cmd, nat.hnd);
>          if ( rc < 0 )
> -            return rc;
> +            break;
>  
>          cmd = 0;
>          if ( hypercall_xlat_continuation(&cmd, 0x02, nat.hnd, compat) )
> @@ -326,5 +327,11 @@ int compat_memory_op(unsigned int cmd, X
>                  __HYPERVISOR_memory_op, "ih", cmd, compat);
>      } while ( split > 0 );
>  
> +    if ( unlikely(rc > INT_MAX) )
> +        return INT_MAX;
> +
> +    if ( unlikely(rc < INT_MIN) )
> +        return INT_MIN;
> +
>      return rc;
>  }
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -545,14 +545,13 @@ static long memory_exchange(XEN_GUEST_HA
>  long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct domain *d;
> -    int rc, op;
> +    long rc;
>      unsigned int address_bits;
>      unsigned long start_extent;
>      struct xen_memory_reservation reservation;
>      struct memop_args args;
>      domid_t domid;
> -
> -    op = cmd & MEMOP_CMD_MASK;
> +    int op = cmd & MEMOP_CMD_MASK;
>  
>      switch ( op )
>      {

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 28 10:17:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:17: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 1UB0YI-0005Aw-N2; Thu, 28 Feb 2013 10:17: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 1UB0YH-0005Ao-Q0
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:17:26 +0000
Received: from [85.158.139.211:43708] by server-2.bemta-5.messagelabs.com id
	8D/F4-23989-3BE2F215; Thu, 28 Feb 2013 10:17:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1362046642!18757661!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28554 invoked from network); 28 Feb 2013 10:17:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2011302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:17:23 +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.297.1;
	Thu, 28 Feb 2013 10:17:22 +0000
Message-ID: <1362046641.23384.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Thu, 28 Feb 2013 10:17:21 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC20105C1F7978A@LONPMAILBOX01.citrite.net>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<1361971036.26546.377.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC20105C1F7978A@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 10:00 +0000, Frediano Ziglio wrote:
> On Wed, 2013-02-27 at 13:17 +0000, Ian Campbell wrote:
> > On Fri, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
> > > Use a list of pointers to simplify the handling of 32- vs 64-bit.
> > > 
> > > Also on ARM the section name is ".init_array" and not ".ctors".
> > 
> > Any comments/ack/nacks?
> > 
> 
> Looks fine to me. Did you test it?

I tested on x86_64 and arm32/64 by annotating the init function to print
the function names as it called them and observing that a) a bunch of
functions were called (on x86 it looked similar before and after this
change) and b) it didn't crash.

>  Actually the way I test is:
> - compile with coverage
> - run xencov to extract information (more or less for x64 is 500k)
> - check file content to see if counters increase while taking multiple
> snapshot (xencov read - | hexdump -C | tail -100, counters are after
> 0CTX string which means "Xen Test Coverage count 0")
> - reset counters (but this has nothing to do with constructors)
> 
> I actually cannot test for Arm.
> 
> Oh.. there is a missing space after a "for("

So there is, thanks for spotting. A resend will have to wait until after
my flight to Hong Kong or else whoever applies, which may end up being
me, can fix it as they go.

Cheers,
Ian.

> 
> Frediano
> 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
> > > Cc: keir@xen.org
> > > ---
> > > This applies independently of my 64-bit ARM series.
> > > ---
> > >  xen/arch/arm/xen.lds.S |   10 ++++------
> > >  xen/arch/x86/xen.lds.S |    6 ++----
> > >  xen/common/lib.c       |   13 +++++--------
> > >  3 files changed, 11 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > > index 9043994..fd755d7 100644
> > > --- a/xen/arch/arm/xen.lds.S
> > > +++ b/xen/arch/arm/xen.lds.S
> > > @@ -91,12 +91,10 @@ SECTIONS
> > >         *(.init.data.rel)
> > >         *(.init.data.rel.*)
> > >  
> > > -       . = ALIGN(4);
> > > -       __CTOR_LIST__ = .;
> > > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > > -       *(.ctors)
> > > -       LONG(0)
> > > -       __CTOR_END__ = .;
> > > +       . = ALIGN(8);
> > > +       __ctors_start = .;
> > > +       *(.init_array)
> > > +       __ctors_end = .;
> > >    } :text
> > >    . = ALIGN(32);
> > >    .init.setup : {
> > > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > > index 5570389..d959941 100644
> > > --- a/xen/arch/x86/xen.lds.S
> > > +++ b/xen/arch/x86/xen.lds.S
> > > @@ -110,11 +110,9 @@ SECTIONS
> > >         __trampoline_seg_stop = .;
> > >  
> > >         . = ALIGN(8);
> > > -       __CTOR_LIST__ = .;
> > > -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> > > +       __ctors_start = .;
> > >         *(.ctors)
> > > -       QUAD(0)
> > > -       __CTOR_END__ = .;
> > > +       __ctors_end = .;
> > >    } :text
> > >    . = ALIGN(32);
> > >    .init.setup : {
> > > diff --git a/xen/common/lib.c b/xen/common/lib.c
> > > index e0c65cf..6b80601 100644
> > > --- a/xen/common/lib.c
> > > +++ b/xen/common/lib.c
> > > @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
> > >      return ret;
> > >  }
> > >  
> > > -extern const struct
> > > -{
> > > -    unsigned long count;
> > > -    void (*funcs[1])(void);
> > > -} __CTOR_LIST__;
> > > +typedef void (*ctor_func_t)(void);
> > > +extern const ctor_func_t __ctors_start[], __ctors_end[];
> > >  
> > >  void __init init_constructors(void)
> > >  {
> > > -    unsigned long n;
> > > -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> > > -        __CTOR_LIST__.funcs[n]();
> > > +    const ctor_func_t *f;
> > > +    for (f = __ctors_start; f < __ctors_end; ++f )
> > > +        (*f)();
> > >  }
> > >  
> > >  /*
> > 
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:17:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:17: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 1UB0YI-0005Aw-N2; Thu, 28 Feb 2013 10:17: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 1UB0YH-0005Ao-Q0
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:17:26 +0000
Received: from [85.158.139.211:43708] by server-2.bemta-5.messagelabs.com id
	8D/F4-23989-3BE2F215; Thu, 28 Feb 2013 10:17:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1362046642!18757661!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28554 invoked from network); 28 Feb 2013 10:17:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2011302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:17:23 +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.297.1;
	Thu, 28 Feb 2013 10:17:22 +0000
Message-ID: <1362046641.23384.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Date: Thu, 28 Feb 2013 10:17:21 +0000
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC20105C1F7978A@LONPMAILBOX01.citrite.net>
References: <1361530660-626-1-git-send-email-ian.campbell@citrix.com>
	<1361971036.26546.377.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC20105C1F7978A@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] coverage: fix on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 10:00 +0000, Frediano Ziglio wrote:
> On Wed, 2013-02-27 at 13:17 +0000, Ian Campbell wrote:
> > On Fri, 2013-02-22 at 10:57 +0000, Ian Campbell wrote:
> > > Use a list of pointers to simplify the handling of 32- vs 64-bit.
> > > 
> > > Also on ARM the section name is ".init_array" and not ".ctors".
> > 
> > Any comments/ack/nacks?
> > 
> 
> Looks fine to me. Did you test it?

I tested on x86_64 and arm32/64 by annotating the init function to print
the function names as it called them and observing that a) a bunch of
functions were called (on x86 it looked similar before and after this
change) and b) it didn't crash.

>  Actually the way I test is:
> - compile with coverage
> - run xencov to extract information (more or less for x64 is 500k)
> - check file content to see if counters increase while taking multiple
> snapshot (xencov read - | hexdump -C | tail -100, counters are after
> 0CTX string which means "Xen Test Coverage count 0")
> - reset counters (but this has nothing to do with constructors)
> 
> I actually cannot test for Arm.
> 
> Oh.. there is a missing space after a "for("

So there is, thanks for spotting. A resend will have to wait until after
my flight to Hong Kong or else whoever applies, which may end up being
me, can fix it as they go.

Cheers,
Ian.

> 
> Frediano
> 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Frediano Ziglio <frediano.ziglio@citrix.com>
> > > Cc: keir@xen.org
> > > ---
> > > This applies independently of my 64-bit ARM series.
> > > ---
> > >  xen/arch/arm/xen.lds.S |   10 ++++------
> > >  xen/arch/x86/xen.lds.S |    6 ++----
> > >  xen/common/lib.c       |   13 +++++--------
> > >  3 files changed, 11 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > > index 9043994..fd755d7 100644
> > > --- a/xen/arch/arm/xen.lds.S
> > > +++ b/xen/arch/arm/xen.lds.S
> > > @@ -91,12 +91,10 @@ SECTIONS
> > >         *(.init.data.rel)
> > >         *(.init.data.rel.*)
> > >  
> > > -       . = ALIGN(4);
> > > -       __CTOR_LIST__ = .;
> > > -       LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
> > > -       *(.ctors)
> > > -       LONG(0)
> > > -       __CTOR_END__ = .;
> > > +       . = ALIGN(8);
> > > +       __ctors_start = .;
> > > +       *(.init_array)
> > > +       __ctors_end = .;
> > >    } :text
> > >    . = ALIGN(32);
> > >    .init.setup : {
> > > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > > index 5570389..d959941 100644
> > > --- a/xen/arch/x86/xen.lds.S
> > > +++ b/xen/arch/x86/xen.lds.S
> > > @@ -110,11 +110,9 @@ SECTIONS
> > >         __trampoline_seg_stop = .;
> > >  
> > >         . = ALIGN(8);
> > > -       __CTOR_LIST__ = .;
> > > -       QUAD((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> > > +       __ctors_start = .;
> > >         *(.ctors)
> > > -       QUAD(0)
> > > -       __CTOR_END__ = .;
> > > +       __ctors_end = .;
> > >    } :text
> > >    . = ALIGN(32);
> > >    .init.setup : {
> > > diff --git a/xen/common/lib.c b/xen/common/lib.c
> > > index e0c65cf..6b80601 100644
> > > --- a/xen/common/lib.c
> > > +++ b/xen/common/lib.c
> > > @@ -479,17 +479,14 @@ unsigned long long parse_size_and_unit(const char *s, const char **ps)
> > >      return ret;
> > >  }
> > >  
> > > -extern const struct
> > > -{
> > > -    unsigned long count;
> > > -    void (*funcs[1])(void);
> > > -} __CTOR_LIST__;
> > > +typedef void (*ctor_func_t)(void);
> > > +extern const ctor_func_t __ctors_start[], __ctors_end[];
> > >  
> > >  void __init init_constructors(void)
> > >  {
> > > -    unsigned long n;
> > > -    for ( n = 0; n < __CTOR_LIST__.count; ++n )
> > > -        __CTOR_LIST__.funcs[n]();
> > > +    const ctor_func_t *f;
> > > +    for (f = __ctors_start; f < __ctors_end; ++f )
> > > +        (*f)();
> > >  }
> > >  
> > >  /*
> > 
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:20:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB0aZ-0005Hw-8p; Thu, 28 Feb 2013 10:19:47 +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 1UB0aY-0005Hk-F1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:19:46 +0000
Received: from [85.158.137.99:32726] by server-16.bemta-3.messagelabs.com id
	A5/BF-20692-14F2F215; Thu, 28 Feb 2013 10:19:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362046749!13046706!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjE3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31603 invoked from network); 28 Feb 2013 10:19:10 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 10:19:10 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1SAIkaN027749;
	Thu, 28 Feb 2013 10:18:50 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1SAIh6s000622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 10:18:43 GMT
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 r1SAIhrX014717;
	Thu, 28 Feb 2013 10:18:43 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	r1SAIgG7014714; Thu, 28 Feb 2013 10:18:42 GMT
Date: Thu, 28 Feb 2013 10:18:42 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
Message-ID: <alpine.GSO.2.00.1302281007290.14532@algedi.dur.ac.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.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: r1SAIkaN027749
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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-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, 27 Feb 2013, Jan Beulich wrote:

> Please indicate any bug fixes that so far may have been missed
> in the backports already done. Quite a few fixes are currently
> stuck in master's staging branch - these don't need to be named
> explicitly, I'm already planning to pull over the hypervisor ones
> as soon as they get out of staging (and I'm sure Ian is planning
> the same - if applicable at all - for the tools side).

The patch "tools: Fix memset(&p,0,sizeof(p)) idiom in several places." 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=d119301b5816b39b5ba722a2f8b301b37e8e34bd
may be worth backporting. It should apply cleanly to 4.2. For 4.1 it 
should apply with the tools/libxl/libxl_qmp.c piece removed.

 	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 Feb 28 10:20:07 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB0aZ-0005Hw-8p; Thu, 28 Feb 2013 10:19:47 +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 1UB0aY-0005Hk-F1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:19:46 +0000
Received: from [85.158.137.99:32726] by server-16.bemta-3.messagelabs.com id
	A5/BF-20692-14F2F215; Thu, 28 Feb 2013 10:19:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362046749!13046706!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMjE3MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31603 invoked from network); 28 Feb 2013 10:19:10 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 10:19:10 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1SAIkaN027749;
	Thu, 28 Feb 2013 10:18:50 GMT
Received: from algedi.dur.ac.uk (algedi.dur.ac.uk [129.234.2.28])
	by smtphost1.dur.ac.uk (8.14.4/8.14.4) with ESMTP id r1SAIh6s000622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 10:18:43 GMT
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 r1SAIhrX014717;
	Thu, 28 Feb 2013 10:18:43 GMT
Received: from localhost (dcl0may@localhost)
	by algedi.dur.ac.uk (8.14.4+Sun/8.14.4/Submit) with ESMTP id
	r1SAIgG7014714; Thu, 28 Feb 2013 10:18:42 GMT
Date: Thu, 28 Feb 2013 10:18:42 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
Message-ID: <alpine.GSO.2.00.1302281007290.14532@algedi.dur.ac.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.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: r1SAIkaN027749
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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-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, 27 Feb 2013, Jan Beulich wrote:

> Please indicate any bug fixes that so far may have been missed
> in the backports already done. Quite a few fixes are currently
> stuck in master's staging branch - these don't need to be named
> explicitly, I'm already planning to pull over the hypervisor ones
> as soon as they get out of staging (and I'm sure Ian is planning
> the same - if applicable at all - for the tools side).

The patch "tools: Fix memset(&p,0,sizeof(p)) idiom in several places." 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=d119301b5816b39b5ba722a2f8b301b37e8e34bd
may be worth backporting. It should apply cleanly to 4.2. For 4.1 it 
should apply with the tools/libxl/libxl_qmp.c piece removed.

 	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 Feb 28 10:25:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0fz-0005bO-6M; Thu, 28 Feb 2013 10:25: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 1UB0fx-0005bG-7P
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 10:25:21 +0000
Received: from [85.158.137.99:49677] by server-15.bemta-3.messagelabs.com id
	4F/60-23142-0903F215; Thu, 28 Feb 2013 10:25:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1362047107!18424219!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29819 invoked from network); 28 Feb 2013 10:25:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:25:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2011760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:25: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.297.1;
	Thu, 28 Feb 2013 10:25:07 +0000
Message-ID: <1362047106.23384.65.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Thu, 28 Feb 2013 10:25:06 +0000
In-Reply-To: <512F2615.3000007@canonical.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] 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 Thu, 2013-02-28 at 09:40 +0000, Stefan Bader wrote:
> The kernel has a "make deb-pkg" approach as well. Though there things are a
> little more simple as there are less locations which can be different to the
> normal packages. That might be much harder to achieve for the Xen (not only but
> anything with a mix of binaries and libraries to be put somewhere in parallel
> but not interfering if not wanted).

Yes, I think the presence of numerous bits of userspace stuff which
cannot be coinstalled is what mainly makes this different to the kernel
situation.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:25:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0fz-0005bO-6M; Thu, 28 Feb 2013 10:25: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 1UB0fx-0005bG-7P
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 10:25:21 +0000
Received: from [85.158.137.99:49677] by server-15.bemta-3.messagelabs.com id
	4F/60-23142-0903F215; Thu, 28 Feb 2013 10:25:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1362047107!18424219!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29819 invoked from network); 28 Feb 2013 10:25:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:25:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2011760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:25: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.297.1;
	Thu, 28 Feb 2013 10:25:07 +0000
Message-ID: <1362047106.23384.65.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Thu, 28 Feb 2013 10:25:06 +0000
In-Reply-To: <512F2615.3000007@canonical.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.4-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] 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 Thu, 2013-02-28 at 09:40 +0000, Stefan Bader wrote:
> The kernel has a "make deb-pkg" approach as well. Though there things are a
> little more simple as there are less locations which can be different to the
> normal packages. That might be much harder to achieve for the Xen (not only but
> anything with a mix of binaries and libraries to be put somewhere in parallel
> but not interfering if not wanted).

Yes, I think the presence of numerous bits of userspace stuff which
cannot be coinstalled is what mainly makes this different to the kernel
situation.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0jL-0005iq-SY; Thu, 28 Feb 2013 10:28:51 +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 1UB0jJ-0005ij-Q3
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:28:49 +0000
Received: from [193.109.254.147:28307] by server-3.bemta-14.messagelabs.com id
	2D/BA-22141-1613F215; Thu, 28 Feb 2013 10:28:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1362047327!3226263!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20940 invoked from network); 28 Feb 2013 10:28:47 -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; 28 Feb 2013 10:28:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 10:28:47 +0000
Message-Id: <512F3F6D02000078000C1DA8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 10:28:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
In-Reply-To: <512F1DE202000078000C1CB4@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:05, "Jan Beulich" <JBeulich@suse.com> wrote:
> And then I don't see why you would do physical MSR accesses in
> the injection case at all. It should really be mca_wrmsr() to take
> care of this, it just needs to have a way to know it got called in
> the context of an injection. One fundamental question here is
> why the invalidation of the interposed data is being done
> before the MSR write rather than after. One thing we surely
> don't care much about in the injection logic is interference with
> a real #MC.

Like this (RFC only, untested so far), based on having gone through
all call sites of mca_wrmsr():

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1065,13 +1065,15 @@ static void intpose_add(unsigned int cpu
     printk("intpose_add: interpose array full - request dropped\n");
 }
 
-void intpose_inval(unsigned int cpu_nr, uint64_t msr)
+bool_t intpose_inval(unsigned int cpu_nr, uint64_t msr)
 {
-    struct intpose_ent *ent;
+    struct intpose_ent *ent = intpose_lookup(cpu_nr, msr, NULL);
 
-    if ((ent = intpose_lookup(cpu_nr, msr, NULL)) != NULL) {
-        ent->cpu_nr = -1;
-    }
+    if ( !ent )
+        return 0;
+
+    ent->cpu_nr = -1;
+    return 1;
 }
 
 #define IS_MCA_BANKREG(r) \
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -77,7 +77,7 @@ extern void mce_recoverable_register(mce
 /* Read an MSR, checking for an interposed value first */
 extern struct intpose_ent *intpose_lookup(unsigned int, uint64_t,
     uint64_t *);
-extern void intpose_inval(unsigned int, uint64_t);
+extern bool_t intpose_inval(unsigned int, uint64_t);
 
 static inline uint64_t mca_rdmsr(unsigned int msr)
 {
@@ -89,9 +89,9 @@ static inline uint64_t mca_rdmsr(unsigne
 
 /* Write an MSR, invalidating any interposed value */
 #define mca_wrmsr(msr, val) do { \
-       intpose_inval(smp_processor_id(), msr); \
-       wrmsrl(msr, val); \
-} while (0)
+    if ( !intpose_inval(smp_processor_id(), msr) ) \
+        wrmsrl(msr, val); \
+} while ( 0 )
 
 
 /* Utility function to "logout" all architectural MCA telemetry from the MCA



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB0jL-0005iq-SY; Thu, 28 Feb 2013 10:28:51 +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 1UB0jJ-0005ij-Q3
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:28:49 +0000
Received: from [193.109.254.147:28307] by server-3.bemta-14.messagelabs.com id
	2D/BA-22141-1613F215; Thu, 28 Feb 2013 10:28:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1362047327!3226263!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20940 invoked from network); 28 Feb 2013 10:28:47 -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; 28 Feb 2013 10:28:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 10:28:47 +0000
Message-Id: <512F3F6D02000078000C1DA8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 10:28:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
In-Reply-To: <512F1DE202000078000C1CB4@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 09:05, "Jan Beulich" <JBeulich@suse.com> wrote:
> And then I don't see why you would do physical MSR accesses in
> the injection case at all. It should really be mca_wrmsr() to take
> care of this, it just needs to have a way to know it got called in
> the context of an injection. One fundamental question here is
> why the invalidation of the interposed data is being done
> before the MSR write rather than after. One thing we surely
> don't care much about in the injection logic is interference with
> a real #MC.

Like this (RFC only, untested so far), based on having gone through
all call sites of mca_wrmsr():

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1065,13 +1065,15 @@ static void intpose_add(unsigned int cpu
     printk("intpose_add: interpose array full - request dropped\n");
 }
 
-void intpose_inval(unsigned int cpu_nr, uint64_t msr)
+bool_t intpose_inval(unsigned int cpu_nr, uint64_t msr)
 {
-    struct intpose_ent *ent;
+    struct intpose_ent *ent = intpose_lookup(cpu_nr, msr, NULL);
 
-    if ((ent = intpose_lookup(cpu_nr, msr, NULL)) != NULL) {
-        ent->cpu_nr = -1;
-    }
+    if ( !ent )
+        return 0;
+
+    ent->cpu_nr = -1;
+    return 1;
 }
 
 #define IS_MCA_BANKREG(r) \
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -77,7 +77,7 @@ extern void mce_recoverable_register(mce
 /* Read an MSR, checking for an interposed value first */
 extern struct intpose_ent *intpose_lookup(unsigned int, uint64_t,
     uint64_t *);
-extern void intpose_inval(unsigned int, uint64_t);
+extern bool_t intpose_inval(unsigned int, uint64_t);
 
 static inline uint64_t mca_rdmsr(unsigned int msr)
 {
@@ -89,9 +89,9 @@ static inline uint64_t mca_rdmsr(unsigne
 
 /* Write an MSR, invalidating any interposed value */
 #define mca_wrmsr(msr, val) do { \
-       intpose_inval(smp_processor_id(), msr); \
-       wrmsrl(msr, val); \
-} while (0)
+    if ( !intpose_inval(smp_processor_id(), msr) ) \
+        wrmsrl(msr, val); \
+} while ( 0 )
 
 
 /* Utility function to "logout" all architectural MCA telemetry from the MCA



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k4-0005mr-F1; Thu, 28 Feb 2013 10:29: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 1UB0k3-0005mY-Gz
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:35 +0000
Received: from [193.109.254.147:36315] by server-2.bemta-14.messagelabs.com id
	6B/56-16277-E813F215; Thu, 28 Feb 2013 10:29:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1280 invoked from network); 28 Feb 2013 10:29:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:35 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:34 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:43 +0100
Message-ID: <1362047335-26402-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 RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 contains the initial implementation of indirect 
descriptors for Linux blkback/blkfront.

Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.

Patch 6 contains a LRU implementation for blkback that will be needed 
when using indirect descriptors (since we are no longer able to map 
all possible grants blkfront might use).

Patch 7 is an addition to the print stats function in blkback in order 
to print information regarding persistent grant usage.

Patches 8, 9, 10 and 11 are preparatory work for indirect descriptors 
implementation, mainly make blkback use dynamic memory and remove the 
shared blkbk structure, so each blkback instance has it's own list of 
free requests, pages, handles and so on.

Finally patch 12 contains the indirect descriptors implementation.

I've also pushed this series to the following git repository:

git://xenbits.xen.org/people/royger/linux.git xen-block-indirect

Performance benefit of this series can be seen in the following graph:

http://xenbits.xen.org/people/royger/plot_indirect.png

Thanks for the review, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k5-0005nI-Rt; Thu, 28 Feb 2013 10:29: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 1UB0k3-0005ma-Ud
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:36 +0000
Received: from [193.109.254.147:36328] by server-1.bemta-14.messagelabs.com id
	A3/77-29874-F813F215; Thu, 28 Feb 2013 10:29:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1301 invoked from network); 28 Feb 2013 10:29:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:35 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:34 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:44 +0100
Message-ID: <1362047335-26402-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 01/12] xen-blkback: don't store dev_bus_addr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

ZGV2X2J1c19hZGRyIHJldHVybmVkIGluIHRoZSBncmFudCByZWYgbWFwIG9wZXJhdGlvbiBpcyB0
aGUgbWZuIG9mIHRoZQpwYXNzZWQgcGFnZSwgdGhlcmUncyBubyBuZWVkIHRvIHN0b3JlIGl0IGlu
IHRoZSBwZXJzaXN0ZW50IGdyYW50CmVudHJ5LCBzaW5jZSB3ZSBjYW4gYWx3YXlzIGdldCBpdCBw
cm92aWRlZCB0aGF0IHdlIGhhdmUgdGhlIHBhZ2UuCgpUaGlzIHJlZHVjZXMgdGhlIG1lbW9yeSBv
dmVyaGVhZCBvZiBwZXJzaXN0ZW50IGdyYW50cyBpbiBibGtiYWNrLgoKU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25yYWQgUnplc3p1
dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgICAgNyArKyst
LS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oICB8ICAgIDEgLQogMiBmaWxl
cyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1i
bGtiYWNrL2Jsa2JhY2suYwppbmRleCBkZTFmMzE5Li5kNDBiZWIzIDEwMDY0NAotLS0gYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1i
bGtiYWNrL2Jsa2JhY2suYwpAQCAtNjIxLDkgKzYyMSw3IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2Jr
X21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJCSAqIElmIHRoaXMgaXMgYSBuZXcg
cGVyc2lzdGVudCBncmFudAogCQkJCSAqIHNhdmUgdGhlIGhhbmRsZXIKIAkJCQkgKi8KLQkJCQlw
ZXJzaXN0ZW50X2dudHNbaV0tPmhhbmRsZSA9IG1hcFtqXS5oYW5kbGU7Ci0JCQkJcGVyc2lzdGVu
dF9nbnRzW2ldLT5kZXZfYnVzX2FkZHIgPQotCQkJCQltYXBbaisrXS5kZXZfYnVzX2FkZHI7CisJ
CQkJcGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGUgPSBtYXBbaisrXS5oYW5kbGU7CiAJCQl9CiAJ
CQlwZW5kaW5nX2hhbmRsZShwZW5kaW5nX3JlcSwgaSkgPQogCQkJCXBlcnNpc3RlbnRfZ250c1tp
XS0+aGFuZGxlOwpAQCAtNjMxLDcgKzYyOSw4IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChz
dHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJaWYgKHJldCkKIAkJCQljb250aW51ZTsKIAot
CQkJc2VnW2ldLmJ1ZiA9IHBlcnNpc3RlbnRfZ250c1tpXS0+ZGV2X2J1c19hZGRyIHwKKwkJCXNl
Z1tpXS5idWYgPSBwZm5fdG9fbWZuKHBhZ2VfdG9fcGZuKAorCQkJCXBlcnNpc3RlbnRfZ250c1tp
XS0+cGFnZSkpIDw8IFBBR0VfU0hJRlQgfAogCQkJCShyZXEtPnUucncuc2VnW2ldLmZpcnN0X3Nl
Y3QgPDwgOSk7CiAJCX0gZWxzZSB7CiAJCQlwZW5kaW5nX2hhbmRsZShwZW5kaW5nX3JlcSwgaSkg
PSBtYXBbal0uaGFuZGxlOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9j
b21tb24uaCBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9uLmgKaW5kZXggNjA3MjM5
MC4uZjMzOGY4YSAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9jb21tb24u
aAorKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCkBAIC0xNzIsNyArMTcy
LDYgQEAgc3RydWN0IHBlcnNpc3RlbnRfZ250IHsKIAlzdHJ1Y3QgcGFnZSAqcGFnZTsKIAlncmFu
dF9yZWZfdCBnbnQ7CiAJZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOwotCXVpbnQ2NF90IGRldl9idXNf
YWRkcjsKIAlzdHJ1Y3QgcmJfbm9kZSBub2RlOwogfTsKIAotLSAKMS43LjcuNSAoQXBwbGUgR2l0
LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k6-0005nq-Kv; Thu, 28 Feb 2013 10:29: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 1UB0k4-0005ml-Mi
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:36 +0000
Received: from [193.109.254.147:32414] by server-13.bemta-14.messagelabs.com
	id 6C/1B-30639-0913F215; Thu, 28 Feb 2013 10:29:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!4
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1383 invoked from network); 28 Feb 2013 10:29:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:36 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:35 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:46 +0100
Message-ID: <1362047335-26402-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 03/12] xen-blkfront: switch from llist to
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVwbGFjZSB0aGUgdXNlIG9mIGxsaXN0IHdpdGggbGlzdC4KCmxsaXN0X2Zvcl9lYWNoX2VudHJ5
X3NhZmUgY2FuIHRyaWdnZXIgYSBidWcgaW4gR0NDIDQuMSwgc28gaXQncyBiZXN0CnRvIHJlbW92
ZSBpdCBhbmQgdXNlIGEgZG91Ymx5IGxpbmtlZCBsaXN0LCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2
ZWx5CmluIHRoZSBrZXJuZWwgYWxyZWFkeS4KClNwZWNpZmljYWxseSB0aGlzIGJ1ZyBjYW4gYmUg
dHJpZ2dlcmVkIGJ5IGhvdC11bnBsdWdnaW5nIGEgZGlzaywKZWl0aGVyIGJ5IGRvaW5nIHhtIGJs
b2NrLWRldGFjaCBvciBieSBzYXZlL3Jlc3RvcmUgY3ljbGUuCgpCVUc6IHVuYWJsZSB0byBoYW5k
bGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZmZmZmZmZmZmZmZjAKSVA6IFs8ZmZmZmZm
ZmZhMDA0NzIyMz5dIGJsa2lmX2ZyZWUrMHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpUaGUgY3Jh
c2ggY2FsbCB0cmFjZSBpczoKCS4uLgpiYWRfYXJlYV9ub3NlbWFwaG9yZSsweDEzLzB4MjAKZG9f
cGFnZV9mYXVsdCsweDI1ZS8weDRiMApwYWdlX2ZhdWx0KzB4MjUvMHgzMAo/IGJsa2lmX2ZyZWUr
MHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpibGtmcm9udF9yZXN1bWUrMHg0Ni8weGEwIFt4ZW5f
YmxrZnJvbnRdCnhlbmJ1c19kZXZfcmVzdW1lKzB4NmMvMHgxNDAKcG1fb3ArMHgxOTIvMHgxYjAK
ZGV2aWNlX3Jlc3VtZSsweDgyLzB4MWUwCmRwbV9yZXN1bWUrMHhjOS8weDFhMApkcG1fcmVzdW1l
X2VuZCsweDE1LzB4MzAKZG9fc3VzcGVuZCsweDExNy8weDFlMAoKV2hlbiBkcmlsbGluZyBkb3du
IHRvIHRoZSBhc3NlbWJsZXIgY29kZSwgb24gbmV3ZXIgR0NDIGl0IGRvZXMKLkwyOToKICAgICAg
ICBjbXBxICAgICQtMTYsICVyMTIgICAgICAjLCBwZXJzaXN0ZW50X2dudCBjaGVjawogICAgICAg
IGplICAgICAgLkwzMCAgICAJIywgb3V0IG9mIHRoZSBsb29wCi5MMjU6CgkuLi4gY29kZSBpbiB0
aGUgbG9vcAogICAgICAgIHRlc3RxICAgJXIxMywgJXIxMyAgICAgICMgbgogICAgICAgIGplICAg
ICAgLkwyOSAgICAJIywgYmFjayB0byB0aGUgdG9wIG9mIHRoZSBsb29wCiAgICAgICAgY21wcSAg
ICAkLTE2LCAlcjEyICAgICAgIywgcGVyc2lzdGVudF9nbnQgY2hlY2sKICAgICAgICBtb3ZxICAg
IDE2KCVyMTIpLCAlcjEzICAjIDx2YXJpYWJsZT4ubm9kZS5uZXh0LCBuCiAgICAgICAgam5lICAg
ICAuTDI1ICAgIAkjLAliYWNrIHRvIHRoZSB0b3Agb2YgdGhlIGxvb3AKLkwzMDoKCldoaWxlIG9u
IEdDQyA0LjEsIGl0IGlzOgpMNzg6CgkuLi4gY29kZSBpbiB0aGUgbG9vcAoJdGVzdHEgICAlcjEz
LCAlcjEzICAgICAgIyBuCiAgICAgICAgamUgICAgICAuTDc4ICAgICMsCWJhY2sgdG8gdGhlIHRv
cCBvZiB0aGUgbG9vcAogICAgICAgIG1vdnEgICAgMTYoJXJieCksICVyMTMgICMgPHZhcmlhYmxl
Pi5ub2RlLm5leHQsIG4KICAgICAgICBqbXAgICAgIC5MNzggICAgIywJYmFjayB0byB0aGUgdG9w
IG9mIHRoZSBsb29wCgpXaGljaCBiYXNpY2FsbHkgbWVhbnMgdGhhdCB0aGUgZXhpdCBsb29wIGNv
bmRpdGlvbiBpbnN0ZWFkIG9mCmJlaW5nOgoKCSYocG9zKS0+bWVtYmVyICE9IE5VTEw7CgppczoK
CTsKCndoaWNoIG1ha2VzIHRoZSBsb29wIHVuYm91bmQuCgpTaW5jZSB3ZSBhbHdheXMgbWFuaXB1
bGF0ZSB0aGUgbGlzdCB3aGlsZSBob2xkaW5nIHRoZSBpb19sb2NrLCB0aGVyZSdzCm5vIG5lZWQg
Zm9yIGFkZGl0aW9uYWwgbG9ja2luZyAobGxpc3QgdXNlZCBwcmV2aW91c2x5IGlzIHNhZmUgdG8g
dXNlCmNvbmN1cnJlbnRseSB3aXRob3V0IGFkZGl0aW9uYWwgbG9ja2luZykuCgpTaG91bGQgYmUg
YmFja3BvcnRlZCB0byAzLjggc3RhYmxlLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CltQYXJ0IG9mIHRoZSBkZXNjcmlwdGlvbl0KU2lnbmVk
LW9mZi1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpD
YzogeGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9u
dC5jIHwgICA0MSArKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogMSBm
aWxlcyBjaGFuZ2VkLCAxOCBpbnNlcnRpb25zKCspLCAyMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1n
aXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9jay94ZW4tYmxr
ZnJvbnQuYwppbmRleCBjM2RhZTJlLi4yZTM5ZWFmIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2Nr
L3hlbi1ibGtmcm9udC5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKQEAgLTQ0
LDcgKzQ0LDcgQEAKICNpbmNsdWRlIDxsaW51eC9tdXRleC5oPgogI2luY2x1ZGUgPGxpbnV4L3Nj
YXR0ZXJsaXN0Lmg+CiAjaW5jbHVkZSA8bGludXgvYml0bWFwLmg+Ci0jaW5jbHVkZSA8bGludXgv
bGxpc3QuaD4KKyNpbmNsdWRlIDxsaW51eC9saXN0Lmg+CiAKICNpbmNsdWRlIDx4ZW4veGVuLmg+
CiAjaW5jbHVkZSA8eGVuL3hlbmJ1cy5oPgpAQCAtNjgsNyArNjgsNyBAQCBlbnVtIGJsa2lmX3N0
YXRlIHsKIHN0cnVjdCBncmFudCB7CiAJZ3JhbnRfcmVmX3QgZ3JlZjsKIAl1bnNpZ25lZCBsb25n
IHBmbjsKLQlzdHJ1Y3QgbGxpc3Rfbm9kZSBub2RlOworCXN0cnVjdCBsaXN0X2hlYWQgbm9kZTsK
IH07CiAKIHN0cnVjdCBibGtfc2hhZG93IHsKQEAgLTEwNSw3ICsxMDUsNyBAQCBzdHJ1Y3QgYmxr
ZnJvbnRfaW5mbwogCXN0cnVjdCB3b3JrX3N0cnVjdCB3b3JrOwogCXN0cnVjdCBnbnR0YWJfZnJl
ZV9jYWxsYmFjayBjYWxsYmFjazsKIAlzdHJ1Y3QgYmxrX3NoYWRvdyBzaGFkb3dbQkxLX1JJTkdf
U0laRV07Ci0Jc3RydWN0IGxsaXN0X2hlYWQgcGVyc2lzdGVudF9nbnRzOworCXN0cnVjdCBsaXN0
X2hlYWQgcGVyc2lzdGVudF9nbnRzOwogCXVuc2lnbmVkIGludCBwZXJzaXN0ZW50X2dudHNfYzsK
IAl1bnNpZ25lZCBsb25nIHNoYWRvd19mcmVlOwogCXVuc2lnbmVkIGludCBmZWF0dXJlX2ZsdXNo
OwpAQCAtMzcxLDEwICszNzEsMTEgQEAgc3RhdGljIGludCBibGtpZl9xdWV1ZV9yZXF1ZXN0KHN0
cnVjdCByZXF1ZXN0ICpyZXEpCiAJCQlsc2VjdCA9IGZzZWN0ICsgKHNnLT5sZW5ndGggPj4gOSkg
LSAxOwogCiAJCQlpZiAoaW5mby0+cGVyc2lzdGVudF9nbnRzX2MpIHsKLQkJCQlCVUdfT04obGxp
c3RfZW1wdHkoJmluZm8tPnBlcnNpc3RlbnRfZ250cykpOwotCQkJCWdudF9saXN0X2VudHJ5ID0g
bGxpc3RfZW50cnkoCi0JCQkJCWxsaXN0X2RlbF9maXJzdCgmaW5mby0+cGVyc2lzdGVudF9nbnRz
KSwKLQkJCQkJc3RydWN0IGdyYW50LCBub2RlKTsKKwkJCQlCVUdfT04obGlzdF9lbXB0eSgmaW5m
by0+cGVyc2lzdGVudF9nbnRzKSk7CisJCQkJZ250X2xpc3RfZW50cnkgPSBsaXN0X2ZpcnN0X2Vu
dHJ5KAorCQkJCSAgICAgICAgICAgICAgICAgICAgICAmaW5mby0+cGVyc2lzdGVudF9nbnRzLAor
CQkJCSAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgZ3JhbnQsIG5vZGUpOworCQkJCWxpc3Rf
ZGVsKCZnbnRfbGlzdF9lbnRyeS0+bm9kZSk7CiAKIAkJCQlyZWYgPSBnbnRfbGlzdF9lbnRyeS0+
Z3JlZjsKIAkJCQlidWZmZXJfbWZuID0gcGZuX3RvX21mbihnbnRfbGlzdF9lbnRyeS0+cGZuKTsK
QEAgLTc5MCw5ICs3OTEsOCBAQCBzdGF0aWMgdm9pZCBibGtpZl9yZXN0YXJ0X3F1ZXVlKHN0cnVj
dCB3b3JrX3N0cnVjdCAqd29yaykKIAogc3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxr
ZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiB7Ci0Jc3RydWN0IGxsaXN0X25vZGUgKmFs
bF9nbnRzOwotCXN0cnVjdCBncmFudCAqcGVyc2lzdGVudF9nbnQsICp0bXA7Ci0Jc3RydWN0IGxs
aXN0X25vZGUgKm47CisJc3RydWN0IGdyYW50ICpwZXJzaXN0ZW50X2dudDsKKwlzdHJ1Y3QgZ3Jh
bnQgKm47CiAKIAkvKiBQcmV2ZW50IG5ldyByZXF1ZXN0cyBiZWluZyBpc3N1ZWQgdW50aWwgd2Ug
Zml4IHRoaW5ncyB1cC4gKi8KIAlzcGluX2xvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKQEAgLTgw
NCwyMCArODA0LDE1IEBAIHN0YXRpYyB2b2lkIGJsa2lmX2ZyZWUoc3RydWN0IGJsa2Zyb250X2lu
Zm8gKmluZm8sIGludCBzdXNwZW5kKQogCiAJLyogUmVtb3ZlIGFsbCBwZXJzaXN0ZW50IGdyYW50
cyAqLwogCWlmIChpbmZvLT5wZXJzaXN0ZW50X2dudHNfYykgewotCQlhbGxfZ250cyA9IGxsaXN0
X2RlbF9hbGwoJmluZm8tPnBlcnNpc3RlbnRfZ250cyk7Ci0JCXBlcnNpc3RlbnRfZ250ID0gbGxp
c3RfZW50cnkoYWxsX2dudHMsIHR5cGVvZigqKHBlcnNpc3RlbnRfZ250KSksIG5vZGUpOwotCQl3
aGlsZSAocGVyc2lzdGVudF9nbnQpIHsKKwkJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBlcnNp
c3RlbnRfZ250LCBuLAorCQkgICAgICAgICAgICAgICAgICAgICAgICAgJmluZm8tPnBlcnNpc3Rl
bnRfZ250cywgbm9kZSkgeworCQkJbGlzdF9kZWwoJnBlcnNpc3RlbnRfZ250LT5ub2RlKTsKIAkJ
CWdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3MocGVyc2lzdGVudF9nbnQtPmdyZWYsIDAsIDBVTCk7
CiAJCQlfX2ZyZWVfcGFnZShwZm5fdG9fcGFnZShwZXJzaXN0ZW50X2dudC0+cGZuKSk7Ci0JCQl0
bXAgPSBwZXJzaXN0ZW50X2dudDsKLQkJCW4gPSBwZXJzaXN0ZW50X2dudC0+bm9kZS5uZXh0Owot
CQkJaWYgKG4pCi0JCQkJcGVyc2lzdGVudF9nbnQgPSBsbGlzdF9lbnRyeShuLCB0eXBlb2YoKihw
ZXJzaXN0ZW50X2dudCkpLCBub2RlKTsKLQkJCWVsc2UKLQkJCQlwZXJzaXN0ZW50X2dudCA9IE5V
TEw7Ci0JCQlrZnJlZSh0bXApOworCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOworCQkJaW5mby0+
cGVyc2lzdGVudF9nbnRzX2MtLTsKIAkJfQotCQlpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyA9IDA7
CisJCUJVR19PTihpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyAhPSAwKTsKIAl9CiAKIAkvKiBObyBt
b3JlIGdudHRhYiBjYWxsYmFjayB3b3JrLiAqLwpAQCAtODc1LDcgKzg3MCw3IEBAIHN0YXRpYyB2
b2lkIGJsa2lmX2NvbXBsZXRpb24oc3RydWN0IGJsa19zaGFkb3cgKnMsIHN0cnVjdCBibGtmcm9u
dF9pbmZvICppbmZvLAogCX0KIAkvKiBBZGQgdGhlIHBlcnNpc3RlbnQgZ3JhbnQgaW50byB0aGUg
bGlzdCBvZiBmcmVlIGdyYW50cyAqLwogCWZvciAoaSA9IDA7IGkgPCBzLT5yZXEudS5ydy5ucl9z
ZWdtZW50czsgaSsrKSB7Ci0JCWxsaXN0X2FkZCgmcy0+Z3JhbnRzX3VzZWRbaV0tPm5vZGUsICZp
bmZvLT5wZXJzaXN0ZW50X2dudHMpOworCQlsaXN0X2FkZCgmcy0+Z3JhbnRzX3VzZWRbaV0tPm5v
ZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCQlpbmZvLT5wZXJzaXN0ZW50X2dudHNfYysr
OwogCX0KIH0KQEAgLTExNzEsNyArMTE2Niw3IEBAIHN0YXRpYyBpbnQgYmxrZnJvbnRfcHJvYmUo
c3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwKIAlzcGluX2xvY2tfaW5pdCgmaW5mby0+aW9fbG9j
ayk7CiAJaW5mby0+eGJkZXYgPSBkZXY7CiAJaW5mby0+dmRldmljZSA9IHZkZXZpY2U7Ci0JaW5p
dF9sbGlzdF9oZWFkKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOworCUlOSVRfTElTVF9IRUFEKCZp
bmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCWluZm8tPnBlcnNpc3RlbnRfZ250c19jID0gMDsKIAlp
bmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFURV9ESVNDT05ORUNURUQ7CiAJSU5JVF9XT1JLKCZp
bmZvLT53b3JrLCBibGtpZl9yZXN0YXJ0X3F1ZXVlKTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0y
NikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k7-0005o3-3H; Thu, 28 Feb 2013 10:29:39 +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 1UB0k5-0005ma-8m
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:37 +0000
Received: from [193.109.254.147:32506] by server-1.bemta-14.messagelabs.com id
	5A/87-29874-1913F215; Thu, 28 Feb 2013 10:29:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!6
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1467 invoked from network); 28 Feb 2013 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:37 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:36 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:48 +0100
Message-ID: <1362047335-26402-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 05/12] xen-blkfront: remove frame list from
	blk_shadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

V2UgYWxyZWFkeSBoYXZlIHRoZSBmcmFtZSAocGZuIG9mIHRoZSBncmFudCBwYWdlKSBzdG9yZWQg
aW5zaWRlIHN0cnVjdApncmFudCwgc28gdGhlcmUncyBubyBuZWVkIHRvIGtlZXAgYW4gYWRpdGlv
bmFsIGxpc3Qgb2YgbWFwcGVkIGZyYW1lcwpmb3IgYSBzcGVjaWZpYyByZXF1ZXN0LiBUaGlzIHJl
ZHVjZXMgbWVtb3J5IHVzYWdlIGluIGJsa2Zyb250LgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1
IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsg
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwotLS0K
IGRyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMgfCAgICA2ICstLS0tLQogMSBmaWxlcyBjaGFu
Z2VkLCAxIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9ibG9jay94ZW4tYmxrZnJvbnQuYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKaW5k
ZXggNWJhNmI4Ny4uNGQ4MWZjYyAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJv
bnQuYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jCkBAIC03NCw3ICs3NCw2IEBA
IHN0cnVjdCBncmFudCB7CiBzdHJ1Y3QgYmxrX3NoYWRvdyB7CiAJc3RydWN0IGJsa2lmX3JlcXVl
c3QgcmVxOwogCXN0cnVjdCByZXF1ZXN0ICpyZXF1ZXN0OwotCXVuc2lnbmVkIGxvbmcgZnJhbWVb
QkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIAlzdHJ1Y3QgZ3JhbnQgKmdyYW50c191
c2VkW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiB9OwogCkBAIC0zNTYsNyArMzU1
LDYgQEAgc3RhdGljIGludCBibGtpZl9pb2N0bChzdHJ1Y3QgYmxvY2tfZGV2aWNlICpiZGV2LCBm
bW9kZV90IG1vZGUsCiBzdGF0aWMgaW50IGJsa2lmX3F1ZXVlX3JlcXVlc3Qoc3RydWN0IHJlcXVl
c3QgKnJlcSkKIHsKIAlzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbyA9IHJlcS0+cnFfZGlzay0+
cHJpdmF0ZV9kYXRhOwotCXVuc2lnbmVkIGxvbmcgYnVmZmVyX21mbjsKIAlzdHJ1Y3QgYmxraWZf
cmVxdWVzdCAqcmluZ19yZXE7CiAJdW5zaWduZWQgbG9uZyBpZDsKIAl1bnNpZ25lZCBpbnQgZnNl
Y3QsIGxzZWN0OwpAQCAtNDM0LDcgKzQzMiw2IEBAIHN0YXRpYyBpbnQgYmxraWZfcXVldWVfcmVx
dWVzdChzdHJ1Y3QgcmVxdWVzdCAqcmVxKQogCiAJCQlnbnRfbGlzdF9lbnRyeSA9IGdldF9ncmFu
dCgmZ3JlZl9oZWFkLCBpbmZvKTsKIAkJCXJlZiA9IGdudF9saXN0X2VudHJ5LT5ncmVmOwotCQkJ
YnVmZmVyX21mbiA9IHBmbl90b19tZm4oZ250X2xpc3RfZW50cnktPnBmbik7CiAKIAkJCWluZm8t
PnNoYWRvd1tpZF0uZ3JhbnRzX3VzZWRbaV0gPSBnbnRfbGlzdF9lbnRyeTsKIApAQCAtNDY1LDcg
KzQ2Miw2IEBAIHN0YXRpYyBpbnQgYmxraWZfcXVldWVfcmVxdWVzdChzdHJ1Y3QgcmVxdWVzdCAq
cmVxKQogCQkJCWt1bm1hcF9hdG9taWMoc2hhcmVkX2RhdGEpOwogCQkJfQogCi0JCQlpbmZvLT5z
aGFkb3dbaWRdLmZyYW1lW2ldID0gbWZuX3RvX3BmbihidWZmZXJfbWZuKTsKIAkJCXJpbmdfcmVx
LT51LnJ3LnNlZ1tpXSA9CiAJCQkJCShzdHJ1Y3QgYmxraWZfcmVxdWVzdF9zZWdtZW50KSB7CiAJ
CQkJCQkuZ3JlZiAgICAgICA9IHJlZiwKQEAgLTEyNjksNyArMTI2NSw3IEBAIHN0YXRpYyBpbnQg
YmxraWZfcmVjb3ZlcihzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbykKIAkJCQlnbnR0YWJfZ3Jh
bnRfZm9yZWlnbl9hY2Nlc3NfcmVmKAogCQkJCQlyZXEtPnUucncuc2VnW2pdLmdyZWYsCiAJCQkJ
CWluZm8tPnhiZGV2LT5vdGhlcmVuZF9pZCwKLQkJCQkJcGZuX3RvX21mbihpbmZvLT5zaGFkb3db
cmVxLT51LnJ3LmlkXS5mcmFtZVtqXSksCisJCQkJCXBmbl90b19tZm4oY29weVtpXS5ncmFudHNf
dXNlZFtqXS0+cGZuKSwKIAkJCQkJMCk7CiAJCX0KIAkJaW5mby0+c2hhZG93W3JlcS0+dS5ydy5p
ZF0ucmVxID0gKnJlcTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k7-0005od-Sc; Thu, 28 Feb 2013 10:29:39 +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 1UB0k5-0005ml-Ok
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:38 +0000
Received: from [193.109.254.147:32559] by server-13.bemta-14.messagelabs.com
	id 72/3B-30639-1913F215; Thu, 28 Feb 2013 10:29:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!7
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1521 invoked from network); 28 Feb 2013 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012285"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:37 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:36 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:49 +0100
Message-ID: <1362047335-26402-7-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 06/12] xen-blkback: implement LRU mechanism
	for persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBtZWNoYW5pc20gYWxsb3dzIGJsa2JhY2sgdG8gY2hhbmdlIHRoZSBudW1iZXIgb2YgZ3Jh
bnRzCnBlcnNpc3RlbnRseSBtYXBwZWQgYXQgcnVuIHRpbWUuCgpUaGUgYWxnb3JpdGhtIHVzZXMg
YSBzaW1wbGUgTFJVIG1lY2hhbmlzbSB0aGF0IHJlbW92ZXMgKGlmIG5lZWRlZCkgdGhlCnBlcnNp
c3RlbnQgZ3JhbnRzIHRoYXQgaGF2ZSBub3QgYmVlbiB1c2VkIHNpbmNlIHRoZSBsYXN0IExSVSBy
dW4sIG9yCmlmIGFsbCBncmFudHMgaGF2ZSBiZWVuIHVzZWQgaXQgcmVtb3ZlcyB0aGUgZmlyc3Qg
Z3JhbnRzIGluIHRoZSBsaXN0Cih0aGF0IGFyZSBub3QgaW4gdXNlKS4KClRoZSBhbGdvcml0aG0g
aGFzIHNldmVyYWwgcGFyYW1ldGVycyB0aGF0IGNhbiBiZSB0dW5lZCBieSB0aGUgdXNlcgpmcm9t
IHN5c2ZzOgoKICogbWF4X3BlcnNpc3RlbnRfZ3JhbnRzOiBtYXhpbXVtIG51bWJlciBvZiBncmFu
dHMgdGhhdCB3aWxsIGJlCiAgIHBlcnNpc3RlbnRseSBtYXBwZWQuCiAqIGxydV9pbnRlcnZhbDog
bWluaW11bSBpbnRlcnZhbCAoaW4gbXMpIGF0IHdoaWNoIHRoZSBMUlUgc2hvdWxkIGJlCiAgIHJ1
bgogKiBscnVfbnVtX2NsZWFuOiBudW1iZXIgb2YgcGVyc2lzdGVudCBncmFudHMgdG8gcmVtb3Zl
IHdoZW4gZXhlY3V0aW5nCiAgIHRoZSBMUlUuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCi0tLQogZHJp
dmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgfCAgMjA3ICsrKysrKysrKysrKysrKysr
KysrKysrKysrKy0tLS0tLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oICB8
ICAgIDQgKwogZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyAgfCAgICAxICsKIDMg
ZmlsZXMgY2hhbmdlZCwgMTY2IGluc2VydGlvbnMoKyksIDQ2IGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIGIvZHJpdmVycy9ibG9j
ay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKaW5kZXggNDE1YTBjNy4uYzE0YjczNiAxMDA2NDQKLS0t
IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKKysrIGIvZHJpdmVycy9ibG9j
ay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKQEAgLTYzLDYgKzYzLDQ0IEBAIHN0YXRpYyBpbnQgeGVu
X2Jsa2lmX3JlcXMgPSA2NDsKIG1vZHVsZV9wYXJhbV9uYW1lZChyZXFzLCB4ZW5fYmxraWZfcmVx
cywgaW50LCAwKTsKIE1PRFVMRV9QQVJNX0RFU0MocmVxcywgIk51bWJlciBvZiBibGtiYWNrIHJl
cXVlc3RzIHRvIGFsbG9jYXRlIik7CiAKKy8qCisgKiBNYXhpbXVtIG51bWJlciBvZiBncmFudHMg
dG8gbWFwIHBlcnNpc3RlbnRseSBpbiBibGtiYWNrLiBGb3IgbWF4aW11bQorICogcGVyZm9ybWFu
Y2UgdGhpcyBzaG91bGQgYmUgdGhlIHRvdGFsIG51bWJlcnMgb2YgZ3JhbnRzIHRoYXQgY2FuIGJl
IHVzZWQKKyAqIHRvIGZpbGwgdGhlIHJpbmcsIGJ1dCBzaW5jZSB0aGlzIG1pZ2h0IGJlY29tZSB0
b28gaGlnaCwgc3BlY2lhbGx5IHdpdGgKKyAqIHRoZSB1c2Ugb2YgaW5kaXJlY3QgZGVzY3JpcHRv
cnMsIHdlIHNldCBpdCB0byBhIHZhbHVlIHRoYXQgcHJvdmlkZXMgZ29vZAorICogcGVyZm9ybWFu
Y2Ugd2l0aG91dCB1c2luZyB0b28gbXVjaCBtZW1vcnkuCisgKgorICogV2hlbiB0aGUgbGlzdCBv
ZiBwZXJzaXN0ZW50IGdyYW50cyBpcyBmdWxsIHdlIGNsZWFuIGl0IHVzaW5nIGEgTFJVCisgKiBh
bGdvcml0aG0uCisgKi8KKworc3RhdGljIGludCB4ZW5fYmxraWZfbWF4X3BncmFudHMgPSAzNTI7
Cittb2R1bGVfcGFyYW1fbmFtZWQobWF4X3BlcnNpc3RlbnRfZ3JhbnRzLCB4ZW5fYmxraWZfbWF4
X3BncmFudHMsIGludCwgMDY0NCk7CitNT0RVTEVfUEFSTV9ERVNDKG1heF9wZXJzaXN0ZW50X2dy
YW50cywKKyAgICAgICAgICAgICAgICAgIk1heGltdW0gbnVtYmVyIG9mIGdyYW50cyB0byBtYXAg
cGVyc2lzdGVudGx5Iik7CisKKy8qCisgKiBUaGUgTFJVIG1lY2hhbmlzbSB0byBjbGVhbiB0aGUg
bGlzdHMgb2YgcGVyc2lzdGVudCBncmFudHMgbmVlZHMgdG8KKyAqIGJlIGV4ZWN1dGVkIHBlcmlv
ZGljYWxseS4gVGhlIHRpbWUgaW50ZXJ2YWwgYmV0d2VlbiBjb25zZWN1dGl2ZSBleGVjdXRpb25z
CisgKiBvZiB0aGUgcHVyZ2UgbWVjaGFuaXNtIGlzIHNldCBpbiBtcy4KKyAqLworCitzdGF0aWMg
aW50IHhlbl9ibGtpZl9scnVfaW50ZXJ2YWwgPSAxMDA7Cittb2R1bGVfcGFyYW1fbmFtZWQobHJ1
X2ludGVydmFsLCB4ZW5fYmxraWZfbHJ1X2ludGVydmFsLCBpbnQsIDA2NDQpOworTU9EVUxFX1BB
Uk1fREVTQyhscnVfaW50ZXJ2YWwsCisiRXhlY3V0aW9uIGludGVydmFsIChpbiBtcykgb2YgdGhl
IExSVSBtZWNoYW5pc20gdG8gY2xlYW4gdGhlIGxpc3Qgb2YgcGVyc2lzdGVudCBncmFudHMiKTsK
KworLyoKKyAqIFdoZW4gdGhlIHBlcnNpc3RlbnQgZ3JhbnRzIGxpc3QgaXMgZnVsbCB3ZSB3aWxs
IHJlbW92ZSB1bnVzZWQgZ3JhbnRzCisgKiBmcm9tIHRoZSBsaXN0LiBUaGUgbnVtYmVyIG9mIGdy
YW50cyB0byBiZSByZW1vdmVkIGF0IGVhY2ggTFJVIGV4ZWN1dGlvbgorICogY2FuIGJlIHNldCBk
eW5hbWljYWxseS4KKyAqLworCitzdGF0aWMgaW50IHhlbl9ibGtpZl9scnVfbnVtX2NsZWFuID0g
QkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOworbW9kdWxlX3BhcmFtX25hbWVkKGxydV9u
dW1fY2xlYW4sIHhlbl9ibGtpZl9scnVfbnVtX2NsZWFuLCBpbnQsIDA2NDQpOworTU9EVUxFX1BB
Uk1fREVTQyhscnVfbnVtX2NsZWFuLAorIk51bWJlciBvZiBwZXJzaXN0ZW50IGdyYW50cyB0byB1
bm1hcCB3aGVuIHRoZSBsaXN0IGlzIGZ1bGwiKTsKKwogLyogUnVuLXRpbWUgc3dpdGNoYWJsZTog
L3N5cy9tb2R1bGUvYmxrYmFjay9wYXJhbWV0ZXJzLyAqLwogc3RhdGljIHVuc2lnbmVkIGludCBs
b2dfc3RhdHM7CiBtb2R1bGVfcGFyYW0obG9nX3N0YXRzLCBpbnQsIDA2NDQpOwpAQCAtODEsNyAr
MTE5LDcgQEAgc3RydWN0IHBlbmRpbmdfcmVxIHsKIAl1bnNpZ25lZCBzaG9ydAkJb3BlcmF0aW9u
OwogCWludAkJCXN0YXR1czsKIAlzdHJ1Y3QgbGlzdF9oZWFkCWZyZWVfbGlzdDsKLQlERUNMQVJF
X0JJVE1BUCh1bm1hcF9zZWcsIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCk7CisJc3Ry
dWN0IHBlcnNpc3RlbnRfZ250CSpwZXJzaXN0ZW50X2dudHNbQkxLSUZfTUFYX1NFR01FTlRTX1BF
Ul9SRVFVRVNUXTsKIH07CiAKICNkZWZpbmUgQkxLQkFDS19JTlZBTElEX0hBTkRMRSAofjApCkBA
IC0xMDIsMzYgKzE0MCw2IEBAIHN0cnVjdCB4ZW5fYmxrYmsgewogc3RhdGljIHN0cnVjdCB4ZW5f
YmxrYmsgKmJsa2JrOwogCiAvKgotICogTWF4aW11bSBudW1iZXIgb2YgZ3JhbnQgcGFnZXMgdGhh
dCBjYW4gYmUgbWFwcGVkIGluIGJsa2JhY2suCi0gKiBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JF
UVVFU1QgKiBSSU5HX1NJWkUgaXMgdGhlIG1heGltdW0gbnVtYmVyIG9mCi0gKiBwYWdlcyB0aGF0
IGJsa2JhY2sgd2lsbCBwZXJzaXN0ZW50bHkgbWFwLgotICogQ3VycmVudGx5LCB0aGlzIGlzOgot
ICogUklOR19TSVpFID0gMzIgKGZvciBhbGwga25vd24gcmluZyB0eXBlcykKLSAqIEJMS0lGX01B
WF9TRUdNRU5UU19QRVJfUkVRVUVTVCA9IDExCi0gKiBzaXplb2Yoc3RydWN0IHBlcnNpc3RlbnRf
Z250KSA9IDQ4Ci0gKiBTbyB0aGUgbWF4aW11bSBtZW1vcnkgdXNlZCB0byBzdG9yZSB0aGUgZ3Jh
bnRzIGlzOgotICogMzIgKiAxMSAqIDQ4ID0gMTY4OTYgYnl0ZXMKLSAqLwotc3RhdGljIGlubGlu
ZSB1bnNpZ25lZCBpbnQgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhlbnVtIGJsa2lmX3Byb3RvY29s
IHByb3RvY29sKQotewotCXN3aXRjaCAocHJvdG9jb2wpIHsKLQljYXNlIEJMS0lGX1BST1RPQ09M
X05BVElWRToKLQkJcmV0dXJuIF9fQ09OU1RfUklOR19TSVpFKGJsa2lmLCBQQUdFX1NJWkUpICoK
LQkJCSAgIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVDsKLQljYXNlIEJMS0lGX1BST1RP
Q09MX1g4Nl8zMjoKLQkJcmV0dXJuIF9fQ09OU1RfUklOR19TSVpFKGJsa2lmX3g4Nl8zMiwgUEFH
RV9TSVpFKSAqCi0JCQkgICBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1Q7Ci0JY2FzZSBC
TEtJRl9QUk9UT0NPTF9YODZfNjQ6Ci0JCXJldHVybiBfX0NPTlNUX1JJTkdfU0laRShibGtpZl94
ODZfNjQsIFBBR0VfU0laRSkgKgotCQkJICAgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNU
OwotCWRlZmF1bHQ6Ci0JCUJVRygpOwotCX0KLQlyZXR1cm4gMDsKLX0KLQotCi0vKgogICogTGl0
dGxlIGhlbHBmdWwgbWFjcm8gdG8gZmlndXJlIG91dCB0aGUgaW5kZXggYW5kIHZpcnR1YWwgYWRk
cmVzcyBvZiB0aGUKICAqIHBlbmRpbmdfcGFnZXNbLi5dLiBGb3IgZWFjaCAncGVuZGluZ19yZXEn
IHdlIGhhdmUgaGF2ZSB1cCB0bwogICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUICgx
MSkgcGFnZXMuIFRoZSBzZWcgd291bGQgYmUgZnJvbSAwIHRocm91Z2gKQEAgLTI1MSw2ICsyNTks
NzYgQEAgc3RhdGljIHZvaWQgZnJlZV9wZXJzaXN0ZW50X2dudHMoc3RydWN0IHJiX3Jvb3QgKnJv
b3QsIHVuc2lnbmVkIGludCBudW0pCiAJQlVHX09OKG51bSAhPSAwKTsKIH0KIAorc3RhdGljIGlu
dCBwdXJnZV9wZXJzaXN0ZW50X2dudChzdHJ1Y3QgcmJfcm9vdCAqcm9vdCwgaW50IG51bSkKK3sK
KwlzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiB1bm1hcFtCTEtJRl9NQVhfU0VHTUVOVFNf
UEVSX1JFUVVFU1RdOworCXN0cnVjdCBwYWdlICpwYWdlc1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVS
X1JFUVVFU1RdOworCXN0cnVjdCBwZXJzaXN0ZW50X2dudCAqcGVyc2lzdGVudF9nbnQ7CisJc3Ry
dWN0IHJiX25vZGUgKm47CisJaW50IHJldCwgc2Vnc190b191bm1hcCA9IDA7CisJaW50IHJlcXVl
c3RlZF9udW0gPSBudW07CisJaW50IHByZXNlcnZlX3VzZWQgPSAxOworCisJcHJfZGVidWcoIlJl
cXVlc3RlZCB0aGUgcHVyZ2Ugb2YgJWQgcGVyc2lzdGVudCBncmFudHNcbiIsIG51bSk7CisKK3B1
cmdlX2xpc3Q6CisJZm9yZWFjaF9ncmFudF9zYWZlKHBlcnNpc3RlbnRfZ250LCBuLCByb290LCBu
b2RlKSB7CisJCUJVR19PTihwZXJzaXN0ZW50X2dudC0+aGFuZGxlID09CisJCQlCTEtCQUNLX0lO
VkFMSURfSEFORExFKTsKKworCQlpZiAocGVyc2lzdGVudF9nbnQtPmZsYWdzICYgUEVSU0lTVEVO
VF9HTlRfQUNUSVZFKQorCQkJY29udGludWU7CisJCWlmIChwcmVzZXJ2ZV91c2VkICYmCisJCSAg
ICAocGVyc2lzdGVudF9nbnQtPmZsYWdzICYgUEVSU0lTVEVOVF9HTlRfVVNFRCkpCisJCQljb250
aW51ZTsKKworCQlnbnR0YWJfc2V0X3VubWFwX29wKCZ1bm1hcFtzZWdzX3RvX3VubWFwXSwKKwkJ
CSh1bnNpZ25lZCBsb25nKSBwZm5fdG9fa2FkZHIocGFnZV90b19wZm4oCisJCQkJcGVyc2lzdGVu
dF9nbnQtPnBhZ2UpKSwKKwkJCUdOVE1BUF9ob3N0X21hcCwKKwkJCXBlcnNpc3RlbnRfZ250LT5o
YW5kbGUpOworCisJCXBhZ2VzW3NlZ3NfdG9fdW5tYXBdID0gcGVyc2lzdGVudF9nbnQtPnBhZ2U7
CisKKwkJaWYgKCsrc2Vnc190b191bm1hcCA9PSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVF
U1QpIHsKKwkJCXJldCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxMLCBwYWdlcywKKwkJ
CQlzZWdzX3RvX3VubWFwKTsKKwkJCUJVR19PTihyZXQpOworCQkJZnJlZV94ZW5iYWxsb29uZWRf
cGFnZXMoc2Vnc190b191bm1hcCwgcGFnZXMpOworCQkJc2Vnc190b191bm1hcCA9IDA7CisJCX0K
KworCQlyYl9lcmFzZSgmcGVyc2lzdGVudF9nbnQtPm5vZGUsIHJvb3QpOworCQlrZnJlZShwZXJz
aXN0ZW50X2dudCk7CisJCWlmICgtLW51bSA9PSAwKQorCQkJZ290byBmaW5pc2hlZDsKKwl9CisJ
LyoKKwkgKiBJZiB3ZSBnZXQgaGVyZSBpdCBtZWFucyB3ZSBhbHNvIG5lZWQgdG8gc3RhcnQgY2xl
YW5pbmcKKwkgKiBncmFudHMgdGhhdCB3ZXJlIHVzZWQgc2luY2UgbGFzdCBwdXJnZSBpbiBvcmRl
ciB0byBjb3BlCisJICogd2l0aCB0aGUgcmVxdWVzdGVkIG51bQorCSAqLworCWlmIChwcmVzZXJ2
ZV91c2VkKSB7CisJCXByX2RlYnVnKCJTdGlsbCBtaXNzaW5nICVkIHB1cmdlZCBmcmFtZXNcbiIs
IG51bSk7CisJCXByZXNlcnZlX3VzZWQgPSAwOworCQlnb3RvIHB1cmdlX2xpc3Q7CisJfQorZmlu
aXNoZWQ6CisJaWYgKHNlZ3NfdG9fdW5tYXAgPiAwKSB7CisJCXJldCA9IGdudHRhYl91bm1hcF9y
ZWZzKHVubWFwLCBOVUxMLCBwYWdlcywgc2Vnc190b191bm1hcCk7CisJCUJVR19PTihyZXQpOwor
CQlmcmVlX3hlbmJhbGxvb25lZF9wYWdlcyhzZWdzX3RvX3VubWFwLCBwYWdlcyk7CisJfQorCS8q
IEZpbmFsbHkgcmVtb3ZlIHRoZSAidXNlZCIgZmxhZyBmcm9tIGFsbCB0aGUgcGVyc2lzdGVudCBn
cmFudHMgKi8KKwlmb3JlYWNoX2dyYW50X3NhZmUocGVyc2lzdGVudF9nbnQsIG4sIHJvb3QsIG5v
ZGUpIHsKKwkJQlVHX09OKHBlcnNpc3RlbnRfZ250LT5oYW5kbGUgPT0KKwkJCUJMS0JBQ0tfSU5W
QUxJRF9IQU5ETEUpOworCQlwZXJzaXN0ZW50X2dudC0+ZmxhZ3MgJj0gflBFUlNJU1RFTlRfR05U
X1VTRUQ7CisJfQorCXByX2RlYnVnKCJQdXJnZWQgJWQvJWRcbiIsIChyZXF1ZXN0ZWRfbnVtIC0g
bnVtKSwgcmVxdWVzdGVkX251bSk7CisJcmV0dXJuIChyZXF1ZXN0ZWRfbnVtIC0gbnVtKTsKK30K
KwogLyoKICAqIFJldHJpZXZlIGZyb20gdGhlICdwZW5kaW5nX3JlcXMnIGEgZnJlZSBwZW5kaW5n
X3JlcSBzdHJ1Y3R1cmUgdG8gYmUgdXNlZC4KICAqLwpAQCAtMzk3LDYgKzQ3NSw4IEBAIGludCB4
ZW5fYmxraWZfc2NoZWR1bGUodm9pZCAqYXJnKQogewogCXN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
ID0gYXJnOwogCXN0cnVjdCB4ZW5fdmJkICp2YmQgPSAmYmxraWYtPnZiZDsKKwlpbnQgcnFfcHVy
Z2UsIHB1cmdlZDsKKwl1bnNpZ25lZCBsb25nIHRpbWVvdXQ7CiAKIAl4ZW5fYmxraWZfZ2V0KGJs
a2lmKTsKIApAQCAtNDA2LDEzICs0ODYsMjEgQEAgaW50IHhlbl9ibGtpZl9zY2hlZHVsZSh2b2lk
ICphcmcpCiAJCWlmICh1bmxpa2VseSh2YmQtPnNpemUgIT0gdmJkX3N6KHZiZCkpKQogCQkJeGVu
X3ZiZF9yZXNpemUoYmxraWYpOwogCi0JCXdhaXRfZXZlbnRfaW50ZXJydXB0aWJsZSgKKwkJdGlt
ZW91dCA9IG1zZWNzX3RvX2ppZmZpZXMoeGVuX2Jsa2lmX2xydV9pbnRlcnZhbCk7CisKKwkJdGlt
ZW91dCA9IHdhaXRfZXZlbnRfaW50ZXJydXB0aWJsZV90aW1lb3V0KAogCQkJYmxraWYtPndxLAot
CQkJYmxraWYtPndhaXRpbmdfcmVxcyB8fCBrdGhyZWFkX3Nob3VsZF9zdG9wKCkpOwotCQl3YWl0
X2V2ZW50X2ludGVycnVwdGlibGUoCisJCQlibGtpZi0+d2FpdGluZ19yZXFzIHx8IGt0aHJlYWRf
c2hvdWxkX3N0b3AoKSwKKwkJCXRpbWVvdXQpOworCQlpZiAodGltZW91dCA9PSAwKQorCQkJZ290
byBwdXJnZV9nbnRfbGlzdDsKKwkJdGltZW91dCA9IHdhaXRfZXZlbnRfaW50ZXJydXB0aWJsZV90
aW1lb3V0KAogCQkJYmxrYmstPnBlbmRpbmdfZnJlZV93cSwKIAkJCSFsaXN0X2VtcHR5KCZibGti
ay0+cGVuZGluZ19mcmVlKSB8fAotCQkJa3RocmVhZF9zaG91bGRfc3RvcCgpKTsKKwkJCWt0aHJl
YWRfc2hvdWxkX3N0b3AoKSwKKwkJCXRpbWVvdXQpOworCQlpZiAodGltZW91dCA9PSAwKQorCQkJ
Z290byBwdXJnZV9nbnRfbGlzdDsKIAogCQlibGtpZi0+d2FpdGluZ19yZXFzID0gMDsKIAkJc21w
X21iKCk7IC8qIGNsZWFyIGZsYWcgKmJlZm9yZSogY2hlY2tpbmcgZm9yIHdvcmsgKi8KQEAgLTQy
MCw2ICs1MDgsMzIgQEAgaW50IHhlbl9ibGtpZl9zY2hlZHVsZSh2b2lkICphcmcpCiAJCWlmIChk
b19ibG9ja19pb19vcChibGtpZikpCiAJCQlibGtpZi0+d2FpdGluZ19yZXFzID0gMTsKIAorcHVy
Z2VfZ250X2xpc3Q6CisJCWlmIChibGtpZi0+dmJkLmZlYXR1cmVfZ250X3BlcnNpc3RlbnQgJiYK
KwkJICAgIHRpbWVfYWZ0ZXIoamlmZmllcywgYmxraWYtPm5leHRfbHJ1KSkgeworCQkJLyogQ2xl
YW4gdGhlIGxpc3Qgb2YgcGVyc2lzdGVudCBncmFudHMgKi8KKwkJCWlmIChibGtpZi0+cGVyc2lz
dGVudF9nbnRfYyA+IHhlbl9ibGtpZl9tYXhfcGdyYW50cyB8fAorCQkJICAgIChibGtpZi0+cGVy
c2lzdGVudF9nbnRfYyA9PSB4ZW5fYmxraWZfbWF4X3BncmFudHMgJiYKKwkJCSAgICAgYmxraWYt
PnZiZC5vdmVyZmxvd19tYXhfZ3JhbnRzKSkgeworCQkJCXJxX3B1cmdlID0gYmxraWYtPnBlcnNp
c3RlbnRfZ250X2MgLQorCQkJCSAgICAgICAgICAgeGVuX2Jsa2lmX21heF9wZ3JhbnRzICsKKwkJ
CQkgICAgICAgICAgIHhlbl9ibGtpZl9scnVfbnVtX2NsZWFuOworCQkJCXJxX3B1cmdlID0gcnFf
cHVyZ2UgPiBibGtpZi0+cGVyc2lzdGVudF9nbnRfYyA/CisJCQkJICAgICAgICAgICBibGtpZi0+
cGVyc2lzdGVudF9nbnRfYyA6IHJxX3B1cmdlOworCQkJCXB1cmdlZCA9IHB1cmdlX3BlcnNpc3Rl
bnRfZ250KAorCQkJCQkgICZibGtpZi0+cGVyc2lzdGVudF9nbnRzLCBycV9wdXJnZSk7CisJCQkJ
aWYgKHB1cmdlZCAhPSBycV9wdXJnZSkKKwkJCQkJcHJfZGVidWcoRFJWX1BGWCAiIHVuYWJsZSB0
byBtZWV0IHBlcnNpc3RlbnQgZ3JhbnRzIHB1cmdlIHJlcXVpcmVtZW50cyBmb3IgZGV2aWNlICUj
eCwgZG9tYWluICV1LCByZXF1ZXN0ZWQgJWQgZG9uZSAlZFxuIiwKKwkJCQkJICAgICAgICAgYmxr
aWYtPmRvbWlkLAorCQkJCQkgICAgICAgICBibGtpZi0+dmJkLmhhbmRsZSwKKwkJCQkJICAgICAg
ICAgcnFfcHVyZ2UsIHB1cmdlZCk7CisJCQkJYmxraWYtPnBlcnNpc3RlbnRfZ250X2MgLT0gcHVy
Z2VkOworCQkJCWJsa2lmLT52YmQub3ZlcmZsb3dfbWF4X2dyYW50cyA9IDA7CisJCQl9CisJCQli
bGtpZi0+bmV4dF9scnUgPSBqaWZmaWVzICsKKwkJCSAgICAgICAgbXNlY3NfdG9famlmZmllcyh4
ZW5fYmxraWZfbHJ1X2ludGVydmFsKTsKKwkJfQorCiAJCWlmIChsb2dfc3RhdHMgJiYgdGltZV9h
ZnRlcihqaWZmaWVzLCBibGtpZi0+c3RfcHJpbnQpKQogCQkJcHJpbnRfc3RhdHMoYmxraWYpOwog
CX0KQEAgLTQ1MywxMyArNTY3LDE4IEBAIHN0YXRpYyB2b2lkIHhlbl9ibGtia191bm1hcChzdHJ1
Y3QgcGVuZGluZ19yZXEgKnJlcSkKIHsKIAlzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiB1
bm1hcFtCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwogCXN0cnVjdCBwYWdlICpwYWdl
c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOworCXN0cnVjdCBwZXJzaXN0ZW50X2du
dCAqcGVyc2lzdGVudF9nbnQ7CiAJdW5zaWduZWQgaW50IGksIGludmNvdW50ID0gMDsKIAlncmFu
dF9oYW5kbGVfdCBoYW5kbGU7CiAJaW50IHJldDsKIAogCWZvciAoaSA9IDA7IGkgPCByZXEtPm5y
X3BhZ2VzOyBpKyspIHsKLQkJaWYgKCF0ZXN0X2JpdChpLCByZXEtPnVubWFwX3NlZykpCisJCWlm
IChyZXEtPnBlcnNpc3RlbnRfZ250c1tpXSAhPSBOVUxMKSB7CisJCQlwZXJzaXN0ZW50X2dudCA9
IHJlcS0+cGVyc2lzdGVudF9nbnRzW2ldOworCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzIHw9IFBF
UlNJU1RFTlRfR05UX1VTRUQ7CisJCQlwZXJzaXN0ZW50X2dudC0+ZmxhZ3MgJj0gflBFUlNJU1RF
TlRfR05UX0FDVElWRTsKIAkJCWNvbnRpbnVlOworCQl9CiAJCWhhbmRsZSA9IHBlbmRpbmdfaGFu
ZGxlKHJlcSwgaSk7CiAJCWlmIChoYW5kbGUgPT0gQkxLQkFDS19JTlZBTElEX0hBTkRMRSkKIAkJ
CWNvbnRpbnVlOwpAQCAtNDgwLDggKzU5OSw4IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChz
dHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJIHN0cnVjdCBwYWdlICpwYWdlc1tdKQogewog
CXN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiBtYXBbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUXTsKLQlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKnBlcnNpc3RlbnRfZ250c1tCTEtJRl9N
QVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwogCXN0cnVjdCBwYWdlICpwYWdlc190b19nbnRbQkxL
SUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKipw
ZXJzaXN0ZW50X2dudHMgPSBwZW5kaW5nX3JlcS0+cGVyc2lzdGVudF9nbnRzOwogCXN0cnVjdCBw
ZXJzaXN0ZW50X2dudCAqcGVyc2lzdGVudF9nbnQgPSBOVUxMOwogCXN0cnVjdCB4ZW5fYmxraWYg
KmJsa2lmID0gcGVuZGluZ19yZXEtPmJsa2lmOwogCXBoeXNfYWRkcl90IGFkZHIgPSAwOwpAQCAt
NDk0LDkgKzYxMyw2IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVx
dWVzdCAqcmVxLAogCiAJdXNlX3BlcnNpc3RlbnRfZ250cyA9IChibGtpZi0+dmJkLmZlYXR1cmVf
Z250X3BlcnNpc3RlbnQpOwogCi0JQlVHX09OKGJsa2lmLT5wZXJzaXN0ZW50X2dudF9jID4KLQkJ
ICAgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhwZW5kaW5nX3JlcS0+YmxraWYtPmJsa19wcm90b2Nv
bCkpOwotCiAJLyoKIAkgKiBGaWxsIG91dCBwcmVxLm5yX3NlY3RzIHdpdGggcHJvcGVyIGFtb3Vu
dCBvZiBzZWN0b3JzLCBhbmQgc2V0dXAKIAkgKiBhc3NpZ24gbWFwWy4uXSB3aXRoIHRoZSBQRk4g
b2YgdGhlIHBhZ2UgaW4gb3VyIGRvbWFpbiB3aXRoIHRoZQpAQCAtNTE2LDkgKzYzMiw5IEBAIHN0
YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJICog
dGhlIGdyYW50IGlzIGFscmVhZHkgbWFwcGVkCiAJCQkgKi8KIAkJCW5ld19tYXAgPSBmYWxzZTsK
KwkJCXBlcnNpc3RlbnRfZ250LT5mbGFncyB8PSBQRVJTSVNURU5UX0dOVF9BQ1RJVkU7CiAJCX0g
ZWxzZSBpZiAodXNlX3BlcnNpc3RlbnRfZ250cyAmJgotCQkJICAgYmxraWYtPnBlcnNpc3RlbnRf
Z250X2MgPAotCQkJICAgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhibGtpZi0+YmxrX3Byb3RvY29s
KSkgeworCQkJICAgYmxraWYtPnBlcnNpc3RlbnRfZ250X2MgPCB4ZW5fYmxraWZfbWF4X3BncmFu
dHMpIHsKIAkJCS8qCiAJCQkgKiBXZSBhcmUgdXNpbmcgcGVyc2lzdGVudCBncmFudHMsIHRoZSBn
cmFudCBpcwogCQkJICogbm90IG1hcHBlZCBidXQgd2UgaGF2ZSByb29tIGZvciBpdApAQCAtNTM2
LDYgKzY1Miw3IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVz
dCAqcmVxLAogCQkJfQogCQkJcGVyc2lzdGVudF9nbnQtPmdudCA9IHJlcS0+dS5ydy5zZWdbaV0u
Z3JlZjsKIAkJCXBlcnNpc3RlbnRfZ250LT5oYW5kbGUgPSBCTEtCQUNLX0lOVkFMSURfSEFORExF
OworCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzID0gUEVSU0lTVEVOVF9HTlRfQUNUSVZFOwogCiAJ
CQlwYWdlc190b19nbnRbc2Vnc190b19tYXBdID0KIAkJCQlwZXJzaXN0ZW50X2dudC0+cGFnZTsK
QEAgLTU0Nyw3ICs2NjQsNyBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKnJlcSwKIAkJCWJsa2lmLT5wZXJzaXN0ZW50X2dudF9jKys7CiAJCQlwcl9kZWJ1
ZyhEUlZfUEZYICIgZ3JhbnQgJXUgYWRkZWQgdG8gdGhlIHRyZWUgb2YgcGVyc2lzdGVudCBncmFu
dHMsIHVzaW5nICV1LyV1XG4iLAogCQkJCSBwZXJzaXN0ZW50X2dudC0+Z250LCBibGtpZi0+cGVy
c2lzdGVudF9nbnRfYywKLQkJCQkgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhibGtpZi0+YmxrX3By
b3RvY29sKSk7CisJCQkJIHhlbl9ibGtpZl9tYXhfcGdyYW50cyk7CiAJCX0gZWxzZSB7CiAJCQkv
KgogCQkJICogV2UgYXJlIGVpdGhlciB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQKQEAgLTU1
Nyw3ICs2NzQsNyBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lmX3JlcXVl
c3QgKnJlcSwKIAkJCWlmICh1c2VfcGVyc2lzdGVudF9nbnRzICYmCiAJCQkJIWJsa2lmLT52YmQu
b3ZlcmZsb3dfbWF4X2dyYW50cykgewogCQkJCWJsa2lmLT52YmQub3ZlcmZsb3dfbWF4X2dyYW50
cyA9IDE7Ci0JCQkJcHJfYWxlcnQoRFJWX1BGWCAiIGRvbWFpbiAldSwgZGV2aWNlICUjeCBpcyB1
c2luZyBtYXhpbXVtIG51bWJlciBvZiBwZXJzaXN0ZW50IGdyYW50c1xuIiwKKwkJCQlwcl9kZWJ1
ZyhEUlZfUEZYICIgZG9tYWluICV1LCBkZXZpY2UgJSN4IGlzIHVzaW5nIG1heGltdW0gbnVtYmVy
IG9mIHBlcnNpc3RlbnQgZ3JhbnRzXG4iLAogCQkJCQkgYmxraWYtPmRvbWlkLCBibGtpZi0+dmJk
LmhhbmRsZSk7CiAJCQl9CiAJCQluZXdfbWFwID0gdHJ1ZTsKQEAgLTU5NSw3ICs3MTIsNiBAQCBz
dGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lmX3JlcXVlc3QgKnJlcSwKIAkgKiBz
byB0aGF0IHdoZW4gd2UgYWNjZXNzIHZhZGRyKHBlbmRpbmdfcmVxLGkpIGl0IGhhcyB0aGUgY29u
dGVudHMgb2YKIAkgKiB0aGUgcGFnZSBmcm9tIHRoZSBvdGhlciBkb21haW4uCiAJICovCi0JYml0
bWFwX3plcm8ocGVuZGluZ19yZXEtPnVubWFwX3NlZywgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUKTsKIAlmb3IgKGkgPSAwLCBqID0gMDsgaSA8IG5zZWc7IGkrKykgewogCQlpZiAoIXBl
cnNpc3RlbnRfZ250c1tpXSB8fAogCQkgICAgcGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGUgPT0g
QkxLQkFDS19JTlZBTElEX0hBTkRMRSkgewpAQCAtNjM0LDcgKzc1MCw2IEBAIHN0YXRpYyBpbnQg
eGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJCShyZXEtPnUucncu
c2VnW2ldLmZpcnN0X3NlY3QgPDwgOSk7CiAJCX0gZWxzZSB7CiAJCQlwZW5kaW5nX2hhbmRsZShw
ZW5kaW5nX3JlcSwgaSkgPSBtYXBbal0uaGFuZGxlOwotCQkJYml0bWFwX3NldChwZW5kaW5nX3Jl
cS0+dW5tYXBfc2VnLCBpLCAxKTsKIAogCQkJaWYgKHJldCkgewogCQkJCWorKzsKZGlmZiAtLWdp
dCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9uLmggYi9kcml2ZXJzL2Jsb2NrL3hl
bi1ibGtiYWNrL2NvbW1vbi5oCmluZGV4IGYzMzhmOGEuLmJkNDRkNzUgMTAwNjQ0Ci0tLSBhL2Ry
aXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9uLmgKKysrIGIvZHJpdmVycy9ibG9jay94ZW4t
YmxrYmFjay9jb21tb24uaApAQCAtMTY3LDExICsxNjcsMTQgQEAgc3RydWN0IHhlbl92YmQgewog
CiBzdHJ1Y3QgYmFja2VuZF9pbmZvOwogCisjZGVmaW5lIFBFUlNJU1RFTlRfR05UX0FDVElWRQkw
eDEKKyNkZWZpbmUgUEVSU0lTVEVOVF9HTlRfVVNFRAkJMHgyCiAKIHN0cnVjdCBwZXJzaXN0ZW50
X2dudCB7CiAJc3RydWN0IHBhZ2UgKnBhZ2U7CiAJZ3JhbnRfcmVmX3QgZ250OwogCWdyYW50X2hh
bmRsZV90IGhhbmRsZTsKKwl1aW50OF90IGZsYWdzOwogCXN0cnVjdCByYl9ub2RlIG5vZGU7CiB9
OwogCkBAIC0yMDQsNiArMjA3LDcgQEAgc3RydWN0IHhlbl9ibGtpZiB7CiAJLyogdHJlZSB0byBz
dG9yZSBwZXJzaXN0ZW50IGdyYW50cyAqLwogCXN0cnVjdCByYl9yb290CQlwZXJzaXN0ZW50X2du
dHM7CiAJdW5zaWduZWQgaW50CQlwZXJzaXN0ZW50X2dudF9jOworCXVuc2lnbmVkIGxvbmcJCW5l
eHRfbHJ1OwogCiAJLyogc3RhdGlzdGljcyAqLwogCXVuc2lnbmVkIGxvbmcJCXN0X3ByaW50Owpk
aWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyBiL2RyaXZlcnMv
YmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKaW5kZXggNWUyMzdmNi4uYWJiMzk5YSAxMDA2NDQK
LS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYworKysgYi9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCkBAIC0xMTYsNiArMTE2LDcgQEAgc3RhdGljIHN0cnVj
dCB4ZW5fYmxraWYgKnhlbl9ibGtpZl9hbGxvYyhkb21pZF90IGRvbWlkKQogCWluaXRfY29tcGxl
dGlvbigmYmxraWYtPmRyYWluX2NvbXBsZXRlKTsKIAlhdG9taWNfc2V0KCZibGtpZi0+ZHJhaW4s
IDApOwogCWJsa2lmLT5zdF9wcmludCA9IGppZmZpZXM7CisJYmxraWYtPm5leHRfbHJ1ID0gamlm
ZmllczsKIAlpbml0X3dhaXRxdWV1ZV9oZWFkKCZibGtpZi0+d2FpdGluZ190b19mcmVlKTsKIAli
bGtpZi0+cGVyc2lzdGVudF9nbnRzLnJiX25vZGUgPSBOVUxMOwogCi0tIAoxLjcuNy41IChBcHBs
ZSBHaXQtMjYpCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k7-0005oJ-Go; Thu, 28 Feb 2013 10:29:39 +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 1UB0k5-0005mz-C4
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:37 +0000
Received: from [193.109.254.147:58045] by server-6.bemta-14.messagelabs.com id
	5A/02-12010-0913F215; Thu, 28 Feb 2013 10:29:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!5
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1435 invoked from network); 28 Feb 2013 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:36 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:35 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:47 +0100
Message-ID: <1362047335-26402-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 04/12] xen-blkfront: pre-allocate pages for
	requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBwcmV2ZW50cyB1cyBmcm9tIGhhdmluZyB0byBjYWxsIGFsbG9jX3BhZ2Ugd2hpbGUgd2Ug
YXJlIHByZXBhcmluZwp0aGUgcmVxdWVzdC4gU2luY2UgYmxrZnJvbnQgd2FzIGNhbGxpbmcgYWxs
b2NfcGFnZSB3aXRoIGEgc3BpbmxvY2sKaGVsZCB3ZSB1c2VkIEdGUF9BVE9NSUMsIHdoaWNoIGNh
biBmYWlsIGlmIHdlIGFyZSByZXF1ZXN0aW5nIGEgbG90IG9mCnBhZ2VzIHNpbmNlIGl0IGlzIHVz
aW5nIHRoZSBlbWVyZ2VuY3kgbWVtb3J5IHBvb2xzLgoKQWxsb2NhdGluZyBhbGwgdGhlIHBhZ2Vz
IGF0IGluaXQgcHJldmVudHMgdXMgZnJvbSBoYXZpbmcgdG8gY2FsbAphbGxvY19wYWdlLCB0aHVz
IHByZXZlbnRpbmcgcG9zc2libGUgZmFpbHVyZXMuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg
TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8
a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCi0tLQog
ZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYyB8ICAxMjAgKysrKysrKysrKysrKysrKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgNzkgaW5zZXJ0aW9ucygrKSwg
NDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQu
YyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKaW5kZXggMmUzOWVhZi4uNWJhNmI4NyAx
MDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYworKysgYi9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtmcm9udC5jCkBAIC0xNjUsNiArMTY1LDY5IEBAIHN0YXRpYyBpbnQgYWRkX2lk
X3RvX2ZyZWVsaXN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvLAogCXJldHVybiAwOwogfQog
CitzdGF0aWMgaW50IGZpbGxfZ3JhbnRfYnVmZmVyKHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZv
LCBpbnQgbnVtKQoreworCXN0cnVjdCBwYWdlICpncmFudGVkX3BhZ2U7CisJc3RydWN0IGdyYW50
ICpnbnRfbGlzdF9lbnRyeSwgKm47CisJaW50IGkgPSAwOworCisJd2hpbGUoaSA8IG51bSkgewor
CQlnbnRfbGlzdF9lbnRyeSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBncmFudCksIEdGUF9OT0lP
KTsKKwkJaWYgKCFnbnRfbGlzdF9lbnRyeSkKKwkJCWdvdG8gb3V0X29mX21lbW9yeTsKKworCQln
cmFudGVkX3BhZ2UgPSBhbGxvY19wYWdlKEdGUF9OT0lPKTsKKwkJaWYgKCFncmFudGVkX3BhZ2Up
IHsKKwkJCWtmcmVlKGdudF9saXN0X2VudHJ5KTsKKwkJCWdvdG8gb3V0X29mX21lbW9yeTsKKwkJ
fQorCisJCWdudF9saXN0X2VudHJ5LT5wZm4gPSBwYWdlX3RvX3BmbihncmFudGVkX3BhZ2UpOwor
CQlnbnRfbGlzdF9lbnRyeS0+Z3JlZiA9IEdSQU5UX0lOVkFMSURfUkVGOworCQlsaXN0X2FkZCgm
Z250X2xpc3RfZW50cnktPm5vZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOworCQlpKys7CisJ
fQorCisJcmV0dXJuIDA7CisKK291dF9vZl9tZW1vcnk6CisJbGlzdF9mb3JfZWFjaF9lbnRyeV9z
YWZlKGdudF9saXN0X2VudHJ5LCBuLAorCSAgICAgICAgICAgICAgICAgICAgICAgICAmaW5mby0+
cGVyc2lzdGVudF9nbnRzLCBub2RlKSB7CisJCWxpc3RfZGVsKCZnbnRfbGlzdF9lbnRyeS0+bm9k
ZSk7CisJCV9fZnJlZV9wYWdlKHBmbl90b19wYWdlKGdudF9saXN0X2VudHJ5LT5wZm4pKTsKKwkJ
a2ZyZWUoZ250X2xpc3RfZW50cnkpOworCQlpLS07CisJfQorCUJVR19PTihpICE9IDApOworCXJl
dHVybiAtRU5PTUVNOworfQorCitzdGF0aWMgc3RydWN0IGdyYW50ICpnZXRfZ3JhbnQoZ3JhbnRf
cmVmX3QgKmdyZWZfaGVhZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qg
YmxrZnJvbnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgZ3JhbnQgKmdudF9saXN0X2VudHJ5Owor
CXVuc2lnbmVkIGxvbmcgYnVmZmVyX21mbjsKKworCUJVR19PTihsaXN0X2VtcHR5KCZpbmZvLT5w
ZXJzaXN0ZW50X2dudHMpKTsKKwlnbnRfbGlzdF9lbnRyeSA9IGxpc3RfZmlyc3RfZW50cnkoJmlu
Zm8tPnBlcnNpc3RlbnRfZ250cywgc3RydWN0IGdyYW50LAorCSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBub2RlKTsKKwlsaXN0X2RlbCgmZ250X2xpc3RfZW50cnktPm5vZGUpOwor
CisJaWYgKGdudF9saXN0X2VudHJ5LT5ncmVmICE9IEdSQU5UX0lOVkFMSURfUkVGKSB7CisJCWlu
Zm8tPnBlcnNpc3RlbnRfZ250c19jLS07CisJCXJldHVybiBnbnRfbGlzdF9lbnRyeTsKKwl9CisK
KwkvKiBBc3NpZ24gYSBncmVmIHRvIHRoaXMgcGFnZSAqLworCWdudF9saXN0X2VudHJ5LT5ncmVm
ID0gZ250dGFiX2NsYWltX2dyYW50X3JlZmVyZW5jZShncmVmX2hlYWQpOworCUJVR19PTihnbnRf
bGlzdF9lbnRyeS0+Z3JlZiA9PSAtRU5PU1BDKTsKKwlidWZmZXJfbWZuID0gcGZuX3RvX21mbihn
bnRfbGlzdF9lbnRyeS0+cGZuKTsKKwlnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3NfcmVmKGdu
dF9saXN0X2VudHJ5LT5ncmVmLAorCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5m
by0+eGJkZXYtPm90aGVyZW5kX2lkLAorCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YnVmZmVyX21mbiwgMCk7CisJcmV0dXJuIGdudF9saXN0X2VudHJ5OworfQorCiBzdGF0aWMgY29u
c3QgY2hhciAqb3BfbmFtZShpbnQgb3ApCiB7CiAJc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IG5h
bWVzW10gPSB7CkBAIC0zMDYsNyArMzY5LDYgQEAgc3RhdGljIGludCBibGtpZl9xdWV1ZV9yZXF1
ZXN0KHN0cnVjdCByZXF1ZXN0ICpyZXEpCiAJICovCiAJYm9vbCBuZXdfcGVyc2lzdGVudF9nbnRz
OwogCWdyYW50X3JlZl90IGdyZWZfaGVhZDsKLQlzdHJ1Y3QgcGFnZSAqZ3JhbnRlZF9wYWdlOwog
CXN0cnVjdCBncmFudCAqZ250X2xpc3RfZW50cnkgPSBOVUxMOwogCXN0cnVjdCBzY2F0dGVybGlz
dCAqc2c7CiAKQEAgLTM3MCw0MiArNDMyLDkgQEAgc3RhdGljIGludCBibGtpZl9xdWV1ZV9yZXF1
ZXN0KHN0cnVjdCByZXF1ZXN0ICpyZXEpCiAJCQlmc2VjdCA9IHNnLT5vZmZzZXQgPj4gOTsKIAkJ
CWxzZWN0ID0gZnNlY3QgKyAoc2ctPmxlbmd0aCA+PiA5KSAtIDE7CiAKLQkJCWlmIChpbmZvLT5w
ZXJzaXN0ZW50X2dudHNfYykgewotCQkJCUJVR19PTihsaXN0X2VtcHR5KCZpbmZvLT5wZXJzaXN0
ZW50X2dudHMpKTsKLQkJCQlnbnRfbGlzdF9lbnRyeSA9IGxpc3RfZmlyc3RfZW50cnkoCi0JCQkJ
ICAgICAgICAgICAgICAgICAgICAgICZpbmZvLT5wZXJzaXN0ZW50X2dudHMsCi0JCQkJICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBncmFudCwgbm9kZSk7Ci0JCQkJbGlzdF9kZWwoJmdudF9s
aXN0X2VudHJ5LT5ub2RlKTsKLQotCQkJCXJlZiA9IGdudF9saXN0X2VudHJ5LT5ncmVmOwotCQkJ
CWJ1ZmZlcl9tZm4gPSBwZm5fdG9fbWZuKGdudF9saXN0X2VudHJ5LT5wZm4pOwotCQkJCWluZm8t
PnBlcnNpc3RlbnRfZ250c19jLS07Ci0JCQl9IGVsc2UgewotCQkJCXJlZiA9IGdudHRhYl9jbGFp
bV9ncmFudF9yZWZlcmVuY2UoJmdyZWZfaGVhZCk7Ci0JCQkJQlVHX09OKHJlZiA9PSAtRU5PU1BD
KTsKLQotCQkJCWdudF9saXN0X2VudHJ5ID0KLQkJCQkJa21hbGxvYyhzaXplb2Yoc3RydWN0IGdy
YW50KSwKLQkJCQkJCQkgR0ZQX0FUT01JQyk7Ci0JCQkJaWYgKCFnbnRfbGlzdF9lbnRyeSkKLQkJ
CQkJcmV0dXJuIC1FTk9NRU07Ci0KLQkJCQlncmFudGVkX3BhZ2UgPSBhbGxvY19wYWdlKEdGUF9B
VE9NSUMpOwotCQkJCWlmICghZ3JhbnRlZF9wYWdlKSB7Ci0JCQkJCWtmcmVlKGdudF9saXN0X2Vu
dHJ5KTsKLQkJCQkJcmV0dXJuIC1FTk9NRU07Ci0JCQkJfQotCi0JCQkJZ250X2xpc3RfZW50cnkt
PnBmbiA9Ci0JCQkJCXBhZ2VfdG9fcGZuKGdyYW50ZWRfcGFnZSk7Ci0JCQkJZ250X2xpc3RfZW50
cnktPmdyZWYgPSByZWY7Ci0KLQkJCQlidWZmZXJfbWZuID0gcGZuX3RvX21mbihwYWdlX3RvX3Bm
bigKLQkJCQkJCQkJZ3JhbnRlZF9wYWdlKSk7Ci0JCQkJZ250dGFiX2dyYW50X2ZvcmVpZ25fYWNj
ZXNzX3JlZihyZWYsCi0JCQkJCWluZm8tPnhiZGV2LT5vdGhlcmVuZF9pZCwKLQkJCQkJYnVmZmVy
X21mbiwgMCk7Ci0JCQl9CisJCQlnbnRfbGlzdF9lbnRyeSA9IGdldF9ncmFudCgmZ3JlZl9oZWFk
LCBpbmZvKTsKKwkJCXJlZiA9IGdudF9saXN0X2VudHJ5LT5ncmVmOworCQkJYnVmZmVyX21mbiA9
IHBmbl90b19tZm4oZ250X2xpc3RfZW50cnktPnBmbik7CiAKIAkJCWluZm8tPnNoYWRvd1tpZF0u
Z3JhbnRzX3VzZWRbaV0gPSBnbnRfbGlzdF9lbnRyeTsKIApAQCAtODAzLDE3ICs4MzIsMjAgQEAg
c3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1
c3BlbmQpCiAJCWJsa19zdG9wX3F1ZXVlKGluZm8tPnJxKTsKIAogCS8qIFJlbW92ZSBhbGwgcGVy
c2lzdGVudCBncmFudHMgKi8KLQlpZiAoaW5mby0+cGVyc2lzdGVudF9nbnRzX2MpIHsKKwlpZiAo
IWxpc3RfZW1wdHkoJmluZm8tPnBlcnNpc3RlbnRfZ250cykpIHsKIAkJbGlzdF9mb3JfZWFjaF9l
bnRyeV9zYWZlKHBlcnNpc3RlbnRfZ250LCBuLAogCQkgICAgICAgICAgICAgICAgICAgICAgICAg
JmluZm8tPnBlcnNpc3RlbnRfZ250cywgbm9kZSkgewogCQkJbGlzdF9kZWwoJnBlcnNpc3RlbnRf
Z250LT5ub2RlKTsKLQkJCWdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3MocGVyc2lzdGVudF9nbnQt
PmdyZWYsIDAsIDBVTCk7CisJCQlpZiAocGVyc2lzdGVudF9nbnQtPmdyZWYgIT0gR1JBTlRfSU5W
QUxJRF9SRUYpIHsKKwkJCQlnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzKHBlcnNpc3RlbnRfZ250
LT5ncmVmLAorCQkJCSAgICAgICAgICAgICAgICAgICAgICAgICAgMCwgMFVMKTsKKwkJCQlpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYy0tOworCQkJfQogCQkJX19mcmVlX3BhZ2UocGZuX3RvX3BhZ2Uo
cGVyc2lzdGVudF9nbnQtPnBmbikpOwogCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOwotCQkJaW5m
by0+cGVyc2lzdGVudF9nbnRzX2MtLTsKIAkJfQotCQlCVUdfT04oaW5mby0+cGVyc2lzdGVudF9n
bnRzX2MgIT0gMCk7CiAJfQorCUJVR19PTihpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyAhPSAwKTsK
IAogCS8qIE5vIG1vcmUgZ250dGFiIGNhbGxiYWNrIHdvcmsuICovCiAJZ250dGFiX2NhbmNlbF9m
cmVlX2NhbGxiYWNrKCZpbmZvLT5jYWxsYmFjayk7CkBAIC0xMDg4LDYgKzExMjAsMTIgQEAgYWdh
aW46CiAJCWdvdG8gZGVzdHJveV9ibGtyaW5nOwogCX0KIAorCS8qIEFsbG9jYXRlIG1lbW9yeSBm
b3IgZ3JhbnRzICovCisJZXJyID0gZmlsbF9ncmFudF9idWZmZXIoaW5mbywgQkxLX1JJTkdfU0la
RSAqCisJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkxLSUZfTUFYX1NFR01FTlRTX1BF
Ul9SRVFVRVNUKTsKKwlpZiAoZXJyKQorCQlnb3RvIG91dDsKKwogCXhlbmJ1c19zd2l0Y2hfc3Rh
dGUoZGV2LCBYZW5idXNTdGF0ZUluaXRpYWxpc2VkKTsKIAogCXJldHVybiAwOwotLSAKMS43Ljcu
NSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k6-0005nd-8D; Thu, 28 Feb 2013 10:29: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 1UB0k4-0005mb-3I
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:36 +0000
Received: from [193.109.254.147:32346] by server-7.bemta-14.messagelabs.com id
	DB/18-13581-F813F215; Thu, 28 Feb 2013 10:29:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!3
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1333 invoked from network); 28 Feb 2013 10:29:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:36 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:35 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:45 +0100
Message-ID: <1362047335-26402-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 02/12] xen-blkback: fix foreach_grant_safe
	to handle empty lists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

V2UgbWF5IHVzZSBmb3JlYWNoX2dyYW50X3NhZmUgaW4gdGhlIGZ1dHVyZSB3aXRoIGVtcHR5IGxp
c3RzLCBzbyBtYWtlCnN1cmUgd2UgY2FuIGhhbmRsZSB0aGVtLgoKU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29t
PgotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgICAgMiArLQogMSBm
aWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hl
bi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBkNDBiZWIzLi40MTVhMGM3IDEwMDY0NAotLS0gYS9k
cml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hl
bi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtMTY0LDcgKzE2NCw3IEBAIHN0YXRpYyB2b2lkIG1ha2Vf
cmVzcG9uc2Uoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIHU2NCBpZCwKIAogI2RlZmluZSBmb3Jl
YWNoX2dyYW50X3NhZmUocG9zLCBuLCByYnRyZWUsIG5vZGUpIFwKIAlmb3IgKChwb3MpID0gY29u
dGFpbmVyX29mKHJiX2ZpcnN0KChyYnRyZWUpKSwgdHlwZW9mKCoocG9zKSksIG5vZGUpLCBcCi0J
ICAgICAobikgPSByYl9uZXh0KCYocG9zKS0+bm9kZSk7IFwKKwkgICAgIChuKSA9ICgmKHBvcykt
Pm5vZGUgIT0gTlVMTCkgPyByYl9uZXh0KCYocG9zKS0+bm9kZSkgOiBOVUxMOyBcCiAJICAgICAm
KHBvcyktPm5vZGUgIT0gTlVMTDsgXAogCSAgICAgKHBvcykgPSBjb250YWluZXJfb2YobiwgdHlw
ZW9mKCoocG9zKSksIG5vZGUpLCBcCiAJICAgICAobikgPSAoJihwb3MpLT5ub2RlICE9IE5VTEwp
ID8gcmJfbmV4dCgmKHBvcyktPm5vZGUpIDogTlVMTCkKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0y
NikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k9-0005pr-78; Thu, 28 Feb 2013 10:29:41 +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 1UB0k7-0005nw-8J
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:39 +0000
Received: from [193.109.254.147:58181] by server-12.bemta-14.messagelabs.com
	id A3/86-32582-2913F215; Thu, 28 Feb 2013 10:29:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!10
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1676 invoked from network); 28 Feb 2013 10:29:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:39 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:38 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:52 +0100
Message-ID: <1362047335-26402-10-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 09/12] xen-blkback: move pending handles
	list from blkbk to pending_req
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

TW92aW5nIGdyYW50IHJlZiBoYW5kbGVzIGZyb20gYmxrYmsgdG8gcGVuZGluZ19yZXEgd2lsbCBh
bGxvdyB1cyB0bwpnZXQgcmlkIG9mIHRoZSBzaGFyZWQgYmxrYmsgc3RydWN0dXJlLgoKU2lnbmVk
LW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25y
YWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwg
ICAxNiArKysrLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwg
MTIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9i
bGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBiYTI3
ZmMzLi5jNDNkZThhIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2Jh
Y2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtMTM2LDYg
KzEzNiw3IEBAIHN0cnVjdCBwZW5kaW5nX3JlcSB7CiAJc3RydWN0IGxpc3RfaGVhZAlmcmVlX2xp
c3Q7CiAJc3RydWN0IHBlcnNpc3RlbnRfZ250CSpwZXJzaXN0ZW50X2dudHNbQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUXTsKIAlzdHJ1Y3QgcGFnZQkJKnBhZ2VzW0JMS0lGX01BWF9TRUdN
RU5UU19QRVJfUkVRVUVTVF07CisJZ3JhbnRfaGFuZGxlX3QJCWdyYW50X2hhbmRsZXNbQkxLSUZf
TUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIH07CiAKICNkZWZpbmUgQkxLQkFDS19JTlZBTElE
X0hBTkRMRSAofjApCkBAIC0xNDcsOCArMTQ4LDYgQEAgc3RydWN0IHhlbl9ibGtiayB7CiAJLyog
QW5kIGl0cyBzcGlubG9jay4gKi8KIAlzcGlubG9ja190CQlwZW5kaW5nX2ZyZWVfbG9jazsKIAl3
YWl0X3F1ZXVlX2hlYWRfdAlwZW5kaW5nX2ZyZWVfd3E7Ci0JLyogQW5kIHRoZSBncmFudCBoYW5k
bGVzIHRoYXQgYXJlIGF2YWlsYWJsZS4gKi8KLQlncmFudF9oYW5kbGVfdAkJKnBlbmRpbmdfZ3Jh
bnRfaGFuZGxlczsKIH07CiAKIHN0YXRpYyBzdHJ1Y3QgeGVuX2Jsa2JrICpibGtiazsKQEAgLTIy
Niw3ICsyMjUsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgcmVtb3ZlX2ZyZWVfcGFnZXMoc3RydWN0
IHhlbl9ibGtpZiAqYmxraWYsIGludCBudW0pCiAjZGVmaW5lIHZhZGRyKHBhZ2UpICgodW5zaWdu
ZWQgbG9uZylwZm5fdG9fa2FkZHIocGFnZV90b19wZm4ocGFnZSkpKQogCiAjZGVmaW5lIHBlbmRp
bmdfaGFuZGxlKF9yZXEsIF9zZWcpIFwKLQkoYmxrYmstPnBlbmRpbmdfZ3JhbnRfaGFuZGxlc1t2
YWRkcl9wYWdlbnIoX3JlcSwgX3NlZyldKQorCShfcmVxLT5ncmFudF9oYW5kbGVzW19zZWddKQog
CiAKIHN0YXRpYyBpbnQgZG9fYmxvY2tfaW9fb3Aoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYpOwpA
QCAtMTIxNCw3ICsxMjEzLDcgQEAgc3RhdGljIHZvaWQgbWFrZV9yZXNwb25zZShzdHJ1Y3QgeGVu
X2Jsa2lmICpibGtpZiwgdTY0IGlkLAogCiBzdGF0aWMgaW50IF9faW5pdCB4ZW5fYmxraWZfaW5p
dCh2b2lkKQogewotCWludCBpLCBtbWFwX3BhZ2VzOworCWludCBpOwogCWludCByYyA9IDA7CiAK
IAlpZiAoIXhlbl9kb21haW4oKSkKQEAgLTEyMjYsMjEgKzEyMjUsMTUgQEAgc3RhdGljIGludCBf
X2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIAkJcmV0dXJuIC1FTk9NRU07CiAJfQogCi0JbW1h
cF9wYWdlcyA9IHhlbl9ibGtpZl9yZXFzICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNU
OwogCiAJYmxrYmstPnBlbmRpbmdfcmVxcyAgICAgICAgICA9IGt6YWxsb2Moc2l6ZW9mKGJsa2Jr
LT5wZW5kaW5nX3JlcXNbMF0pICoKIAkJCQkJeGVuX2Jsa2lmX3JlcXMsIEdGUF9LRVJORUwpOwot
CWJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMgPSBrbWFsbG9jKHNpemVvZihibGtiay0+cGVu
ZGluZ19ncmFudF9oYW5kbGVzWzBdKSAqCi0JCQkJCW1tYXBfcGFnZXMsIEdGUF9LRVJORUwpOwog
Ci0JaWYgKCFibGtiay0+cGVuZGluZ19yZXFzIHx8ICFibGtiay0+cGVuZGluZ19ncmFudF9oYW5k
bGVzKSB7CisJaWYgKCFibGtiay0+cGVuZGluZ19yZXFzKSB7CiAJCXJjID0gLUVOT01FTTsKIAkJ
Z290byBvdXRfb2ZfbWVtb3J5OwogCX0KIAotCWZvciAoaSA9IDA7IGkgPCBtbWFwX3BhZ2VzOyBp
KyspIHsKLQkJYmxrYmstPnBlbmRpbmdfZ3JhbnRfaGFuZGxlc1tpXSA9IEJMS0JBQ0tfSU5WQUxJ
RF9IQU5ETEU7Ci0JfQogCXJjID0geGVuX2Jsa2lmX2ludGVyZmFjZV9pbml0KCk7CiAJaWYgKHJj
KQogCQlnb3RvIGZhaWxlZF9pbml0OwpAQCAtMTI2Myw3ICsxMjU2LDYgQEAgc3RhdGljIGludCBf
X2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIAlwcl9hbGVydChEUlZfUEZYICIlczogb3V0IG9m
IG1lbW9yeVxuIiwgX19mdW5jX18pOwogIGZhaWxlZF9pbml0OgogCWtmcmVlKGJsa2JrLT5wZW5k
aW5nX3JlcXMpOwotCWtmcmVlKGJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMpOwogCWtmcmVl
KGJsa2JrKTsKIAlibGtiayA9IE5VTEw7CiAJcmV0dXJuIHJjOwotLSAKMS43LjcuNSAoQXBwbGUg
R2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0kA-0005qr-9F; Thu, 28 Feb 2013 10:29:42 +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 1UB0k8-0005oU-5x
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:40 +0000
Received: from [193.109.254.147:32750] by server-16.bemta-14.messagelabs.com
	id BE/15-25906-3913F215; Thu, 28 Feb 2013 10:29:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!12
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1784 invoked from network); 28 Feb 2013 10:29:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:39 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:38 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:54 +0100
Message-ID: <1362047335-26402-12-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 11/12] xen-blkback: expand map/unmap
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UHJlcGFyYXRvcnkgY2hhbmdlIGZvciBpbXBsZW1lbnRpbmcgaW5kaXJlY3QgZGVzY3JpcHRvcnMu
IENoYW5nZQp4ZW5fYmxrYmtfe21hcC91bm1hcH0gaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBtYXAv
dW5tYXAgYSByYW5kb20gYW1vdW50Cm9mIGdyYW50cyAocHJldmlvdXNseSBpdCB3YXMgbGltaXRl
ZCB0bwpCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QpLiBBbHNvLCByZW1vdmUgdGhlIHVz
YWdlIG9mIHBlbmRpbmdfcmVxCmluIHRoZSBtYXAvdW5tYXAgZnVuY3Rpb25zLCBzbyB3ZSBjYW4g
bWFwL3VubWFwIGdyYW50cyB3aXRob3V0IG5lZWRpbmcKdG8gcGFzcyBhIHBlbmRpbmdfcmVxLgoK
U2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNj
OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFj
ay5jIHwgIDEzNCArKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLQogMSBmaWxlcyBj
aGFuZ2VkLCA4NSBpbnNlcnRpb25zKCspLCA0OSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9k
cml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJs
a2JhY2svYmxrYmFjay5jCmluZGV4IDA0YWQyYWEuLjBmYTMwZGIgMTAwNjQ0Ci0tLSBhL2RyaXZl
cnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJs
a2JhY2svYmxrYmFjay5jCkBAIC0xNzgsMTAgKzE3OCw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBy
ZW1vdmVfZnJlZV9wYWdlcyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwgaW50IG51bSkKIAogI2Rl
ZmluZSB2YWRkcihwYWdlKSAoKHVuc2lnbmVkIGxvbmcpcGZuX3RvX2thZGRyKHBhZ2VfdG9fcGZu
KHBhZ2UpKSkKIAotI2RlZmluZSBwZW5kaW5nX2hhbmRsZShfcmVxLCBfc2VnKSBcCi0JKF9yZXEt
PmdyYW50X2hhbmRsZXNbX3NlZ10pCi0KLQogc3RhdGljIGludCBkb19ibG9ja19pb19vcChzdHJ1
Y3QgeGVuX2Jsa2lmICpibGtpZik7CiBzdGF0aWMgaW50IGRpc3BhdGNoX3J3X2Jsb2NrX2lvKHN0
cnVjdCB4ZW5fYmxraWYgKmJsa2lmLAogCQkJCXN0cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCkBA
IC01OTAsNTMgKzU4Niw2MCBAQCBzdHJ1Y3Qgc2VnX2J1ZiB7CiAgKiBVbm1hcCB0aGUgZ3JhbnQg
cmVmZXJlbmNlcywgYW5kIGFsc28gcmVtb3ZlIHRoZSBNMlAgb3Zlci1yaWRlcwogICogdXNlZCBp
biB0aGUgJ3BlbmRpbmdfcmVxJy4KICAqLwotc3RhdGljIHZvaWQgeGVuX2Jsa2JrX3VubWFwKHN0
cnVjdCBwZW5kaW5nX3JlcSAqcmVxKQorc3RhdGljIHZvaWQgeGVuX2Jsa2JrX3VubWFwKHN0cnVj
dCB4ZW5fYmxraWYgKmJsa2lmLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdyYW50X2hh
bmRsZV90IGhhbmRsZXNbXSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcGFn
ZSAqcGFnZXNbXSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcGVyc2lzdGVu
dF9nbnQgKnBlcnNpc3RlbnRfZ250c1tdLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu
dCBudW0pCiB7CiAJc3RydWN0IGdudHRhYl91bm1hcF9ncmFudF9yZWYgdW5tYXBbQkxLSUZfTUFY
X1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKLQlzdHJ1Y3QgcGFnZSAqcGFnZXNbQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGFnZSAqdW5tYXBfcGFnZXNbQkxLSUZfTUFY
X1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIAlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKnBlcnNpc3Rl
bnRfZ250OwogCXVuc2lnbmVkIGludCBpLCBpbnZjb3VudCA9IDA7Ci0JZ3JhbnRfaGFuZGxlX3Qg
aGFuZGxlOwotCXN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmID0gcmVxLT5ibGtpZjsKIAlpbnQgcmV0
OwogCi0JZm9yIChpID0gMDsgaSA8IHJlcS0+bnJfcGFnZXM7IGkrKykgewotCQlpZiAocmVxLT5w
ZXJzaXN0ZW50X2dudHNbaV0gIT0gTlVMTCkgewotCQkJcGVyc2lzdGVudF9nbnQgPSByZXEtPnBl
cnNpc3RlbnRfZ250c1tpXTsKKwlmb3IgKGkgPSAwOyBpIDwgbnVtOyBpKyspIHsKKwkJaWYgKHBl
cnNpc3RlbnRfZ250c1tpXSAhPSBOVUxMKSB7CisJCQlwZXJzaXN0ZW50X2dudCA9IHBlcnNpc3Rl
bnRfZ250c1tpXTsKIAkJCXBlcnNpc3RlbnRfZ250LT5mbGFncyB8PSBQRVJTSVNURU5UX0dOVF9V
U0VEOwogCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzICY9IH5QRVJTSVNURU5UX0dOVF9BQ1RJVkU7
CiAJCQljb250aW51ZTsKIAkJfQotCQloYW5kbGUgPSBwZW5kaW5nX2hhbmRsZShyZXEsIGkpOwot
CQlwYWdlc1tpbnZjb3VudF0gPSByZXEtPnBhZ2VzW2ldOwotCQlpZiAoaGFuZGxlID09IEJMS0JB
Q0tfSU5WQUxJRF9IQU5ETEUpCisJCWlmIChoYW5kbGVzW2ldID09IEJMS0JBQ0tfSU5WQUxJRF9I
QU5ETEUpCiAJCQljb250aW51ZTsKLQkJZ250dGFiX3NldF91bm1hcF9vcCgmdW5tYXBbaW52Y291
bnRdLCB2YWRkcihwYWdlc1tpbnZjb3VudF0pLAotCQkJCSAgICBHTlRNQVBfaG9zdF9tYXAsIGhh
bmRsZSk7Ci0JCXBlbmRpbmdfaGFuZGxlKHJlcSwgaSkgPSBCTEtCQUNLX0lOVkFMSURfSEFORExF
OwotCQlpbnZjb3VudCsrOworCQl1bm1hcF9wYWdlc1tpbnZjb3VudF0gPSBwYWdlc1tpXTsKKwkJ
Z250dGFiX3NldF91bm1hcF9vcCgmdW5tYXBbaW52Y291bnRdLCB2YWRkcihwYWdlc1tpXSksCisJ
CQkJICAgIEdOVE1BUF9ob3N0X21hcCwgaGFuZGxlc1tpXSk7CisJCWhhbmRsZXNbaV0gPSBCTEtC
QUNLX0lOVkFMSURfSEFORExFOworCQlpZiAoKytpbnZjb3VudCA9PSBCTEtJRl9NQVhfU0VHTUVO
VFNfUEVSX1JFUVVFU1QpIHsKKwkJCXJldCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxM
LCB1bm1hcF9wYWdlcywKKwkJCSAgICAgICAgICAgICAgICAgICAgICAgIGludmNvdW50KTsKKwkJ
CUJVR19PTihyZXQpOworCQkJcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHVubWFwX3BhZ2VzLCBpbnZj
b3VudCk7CisJCQlpbnZjb3VudCA9IDA7CisJCX0KKwl9CisJaWYgKGludmNvdW50KSB7CisJCXJl
dCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxMLCB1bm1hcF9wYWdlcywgaW52Y291bnQp
OworCQlCVUdfT04ocmV0KTsKKwkJcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHVubWFwX3BhZ2VzLCBp
bnZjb3VudCk7CiAJfQotCi0JcmV0ID0gZ250dGFiX3VubWFwX3JlZnModW5tYXAsIE5VTEwsIHBh
Z2VzLCBpbnZjb3VudCk7Ci0JQlVHX09OKHJldCk7Ci0JcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHBh
Z2VzLCBpbnZjb3VudCk7CiB9CiAKLXN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxr
aWZfcmVxdWVzdCAqcmVxLAotCQkJIHN0cnVjdCBwZW5kaW5nX3JlcSAqcGVuZGluZ19yZXEsCi0J
CQkgc3RydWN0IHNlZ19idWYgc2VnW10sCi0JCQkgc3RydWN0IHBhZ2UgKnBhZ2VzW10pCitzdGF0
aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIGdyYW50X3JlZl90
IGdyZWZzW10sCisJCQkgc3RydWN0IHBlcnNpc3RlbnRfZ250ICpwZXJzaXN0ZW50X2dudHNbXSwK
KwkJCSBncmFudF9oYW5kbGVfdCBoYW5kbGVzW10sCisJCQkgc3RydWN0IHBhZ2UgKnBhZ2VzW10s
CisJCQkgaW50IG51bSwgYm9vbCBybykKIHsKIAlzdHJ1Y3QgZ250dGFiX21hcF9ncmFudF9yZWYg
bWFwW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAJc3RydWN0IHBhZ2UgKnBhZ2Vz
X3RvX2dudFtCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwotCXN0cnVjdCBwZXJzaXN0
ZW50X2dudCAqKnBlcnNpc3RlbnRfZ250cyA9IHBlbmRpbmdfcmVxLT5wZXJzaXN0ZW50X2dudHM7
CiAJc3RydWN0IHBlcnNpc3RlbnRfZ250ICpwZXJzaXN0ZW50X2dudCA9IE5VTEw7Ci0Jc3RydWN0
IHhlbl9ibGtpZiAqYmxraWYgPSBwZW5kaW5nX3JlcS0+YmxraWY7CiAJcGh5c19hZGRyX3QgYWRk
ciA9IDA7CiAJaW50IGksIGo7Ci0JaW50IG5zZWcgPSByZXEtPnUucncubnJfc2VnbWVudHM7CiAJ
aW50IHNlZ3NfdG9fbWFwID0gMDsKIAlpbnQgcmV0ID0gMDsKKwlpbnQgbGFzdF9tYXAgPSAwLCBt
YXBfdW50aWwgPSAwOwogCWludCB1c2VfcGVyc2lzdGVudF9nbnRzOwogCiAJdXNlX3BlcnNpc3Rl
bnRfZ250cyA9IChibGtpZi0+dmJkLmZlYXR1cmVfZ250X3BlcnNpc3RlbnQpOwpAQCAtNjQ2LDEz
ICs2NDksMTQgQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0
ICpyZXEsCiAJICogYXNzaWduIG1hcFsuLl0gd2l0aCB0aGUgUEZOIG9mIHRoZSBwYWdlIGluIG91
ciBkb21haW4gd2l0aCB0aGUKIAkgKiBjb3JyZXNwb25kaW5nIGdyYW50IHJlZmVyZW5jZSBmb3Ig
ZWFjaCBwYWdlLgogCSAqLwotCWZvciAoaSA9IDA7IGkgPCBuc2VnOyBpKyspIHsKK2FnYWluOgor
CWZvciAoaSA9IG1hcF91bnRpbDsgaSA8IG51bTsgaSsrKSB7CiAJCXVpbnQzMl90IGZsYWdzOwog
CiAJCWlmICh1c2VfcGVyc2lzdGVudF9nbnRzKQogCQkJcGVyc2lzdGVudF9nbnQgPSBnZXRfcGVy
c2lzdGVudF9nbnQoCiAJCQkJJmJsa2lmLT5wZXJzaXN0ZW50X2dudHMsCi0JCQkJcmVxLT51LnJ3
LnNlZ1tpXS5ncmVmKTsKKwkJCQlncmVmc1tpXSk7CiAKIAkJaWYgKHBlcnNpc3RlbnRfZ250KSB7
CiAJCQkvKgpAQCAtNjY5LDEzICs2NzMsMTUgQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0
cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCiAJCQlwYWdlc190b19nbnRbc2Vnc190b19tYXBdID0g
cGFnZXNbaV07CiAJCQlwZXJzaXN0ZW50X2dudHNbaV0gPSBOVUxMOwogCQkJZmxhZ3MgPSBHTlRN
QVBfaG9zdF9tYXA7Ci0JCQlpZiAoIXVzZV9wZXJzaXN0ZW50X2dudHMgJiYKLQkJCSAgICAocGVu
ZGluZ19yZXEtPm9wZXJhdGlvbiAhPSBCTEtJRl9PUF9SRUFEKSkKKwkJCWlmICghdXNlX3BlcnNp
c3RlbnRfZ250cyAmJiBybykKIAkJCQlmbGFncyB8PSBHTlRNQVBfcmVhZG9ubHk7CiAJCQlnbnR0
YWJfc2V0X21hcF9vcCgmbWFwW3NlZ3NfdG9fbWFwKytdLCBhZGRyLAotCQkJCQkgIGZsYWdzLCBy
ZXEtPnUucncuc2VnW2ldLmdyZWYsCisJCQkJCSAgZmxhZ3MsIGdyZWZzW2ldLAogCQkJCQkgIGJs
a2lmLT5kb21pZCk7CiAJCX0KKwkJbWFwX3VudGlsID0gaSArIDE7CisJCWlmIChzZWdzX3RvX21h
cCA9PSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QpCisJCQlicmVhazsKIAl9CiAKIAlp
ZiAoc2Vnc190b19tYXApIHsKQEAgLTY4OCwyMiArNjk0LDIwIEBAIHN0YXRpYyBpbnQgeGVuX2Js
a2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCSAqIHNvIHRoYXQgd2hlbiB3ZSBh
Y2Nlc3MgdmFkZHIocGVuZGluZ19yZXEsaSkgaXQgaGFzIHRoZSBjb250ZW50cyBvZgogCSAqIHRo
ZSBwYWdlIGZyb20gdGhlIG90aGVyIGRvbWFpbi4KIAkgKi8KLQlmb3IgKGkgPSAwLCBqID0gMDsg
aSA8IG5zZWc7IGkrKykgeworCWZvciAoaSA9IGxhc3RfbWFwLCBqID0gMDsgaSA8IG1hcF91bnRp
bDsgaSsrKSB7CiAJCWlmICghcGVyc2lzdGVudF9nbnRzW2ldKSB7CiAJCQkvKiBUaGlzIGlzIGEg
bmV3bHkgbWFwcGVkIGdyYW50ICovCiAJCQlCVUdfT04oaiA+PSBzZWdzX3RvX21hcCk7CiAJCQlp
ZiAodW5saWtlbHkobWFwW2pdLnN0YXR1cyAhPSAwKSkgewogCQkJCXByX2RlYnVnKERSVl9QRlgg
ImludmFsaWQgYnVmZmVyIC0tIGNvdWxkIG5vdCByZW1hcCBpdFxuIik7Ci0JCQkJcGVuZGluZ19o
YW5kbGUocGVuZGluZ19yZXEsIGkpID0KLQkJCQkJQkxLQkFDS19JTlZBTElEX0hBTkRMRTsKKwkJ
CQloYW5kbGVzW2ldID0gQkxLQkFDS19JTlZBTElEX0hBTkRMRTsKIAkJCQlyZXQgfD0gMTsKLQkJ
CQlqKys7Ci0JCQkJY29udGludWU7CisJCQkJZ290byBuZXh0OwogCQkJfQotCQkJcGVuZGluZ19o
YW5kbGUocGVuZGluZ19yZXEsIGkpID0gbWFwW2pdLmhhbmRsZTsKKwkJCWhhbmRsZXNbaV0gPSBt
YXBbal0uaGFuZGxlOwogCQl9CiAJCWlmIChwZXJzaXN0ZW50X2dudHNbaV0pCi0JCQlnb3RvIG5l
eHQ7CisJCQljb250aW51ZTsKIAkJaWYgKHVzZV9wZXJzaXN0ZW50X2dudHMgJiYKIAkJICAgIGJs
a2lmLT5wZXJzaXN0ZW50X2dudF9jIDwgeGVuX2Jsa2lmX21heF9wZ3JhbnRzKSB7CiAJCQkvKgpA
QCAtNzE4LDcgKzcyMiw2IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZf
cmVxdWVzdCAqcmVxLAogCQkJCSAqIGFsbG9jYXRlIHRoZSBwZXJzaXN0ZW50X2dudCBzdHJ1Y3QK
IAkJCQkgKiBtYXAgdGhpcyBncmFudCBub24tcGVyc2lzdGVubHkKIAkJCQkgKi8KLQkJCQlqKys7
CiAJCQkJZ290byBuZXh0OwogCQkJfQogCQkJcGVyc2lzdGVudF9nbnQtPmdudCA9IG1hcFtqXS5y
ZWY7CkBAIC03MzUsNyArNzM4LDYgQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBi
bGtpZl9yZXF1ZXN0ICpyZXEsCiAJCQlwcl9kZWJ1ZyhEUlZfUEZYICIgZ3JhbnQgJXUgYWRkZWQg
dG8gdGhlIHRyZWUgb2YgcGVyc2lzdGVudCBncmFudHMsIHVzaW5nICV1LyV1XG4iLAogCQkJCSBw
ZXJzaXN0ZW50X2dudC0+Z250LCBibGtpZi0+cGVyc2lzdGVudF9nbnRfYywKIAkJCQkgeGVuX2Js
a2lmX21heF9wZ3JhbnRzKTsKLQkJCWorKzsKIAkJCWdvdG8gbmV4dDsKIAkJfQogCQlpZiAodXNl
X3BlcnNpc3RlbnRfZ250cyAmJiAhYmxraWYtPnZiZC5vdmVyZmxvd19tYXhfZ3JhbnRzKSB7CkBA
IC03NDMsMTEgKzc0NSwxNCBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKnJlcSwKIAkJCXByX2RlYnVnKERSVl9QRlggIiBkb21haW4gJXUsIGRldmljZSAl
I3ggaXMgdXNpbmcgbWF4aW11bSBudW1iZXIgb2YgcGVyc2lzdGVudCBncmFudHNcbiIsCiAJCQkg
ICAgICAgICBibGtpZi0+ZG9taWQsIGJsa2lmLT52YmQuaGFuZGxlKTsKIAkJfQotCQlqKys7CiBu
ZXh0OgotCQlzZWdbaV0uYnVmID0gcGZuX3RvX21mbihwYWdlX3RvX3BmbihwYWdlc1tpXSkpIDw8
IFBBR0VfU0hJRlQgfAotCQkgICAgICAgICAgICAgKHJlcS0+dS5ydy5zZWdbaV0uZmlyc3Rfc2Vj
dCA8PCA5KTsKKwkJaisrOwogCX0KKwlzZWdzX3RvX21hcCA9IDA7CisJbGFzdF9tYXAgPSBtYXBf
dW50aWw7CisJaWYgKG1hcF91bnRpbCAhPSBudW0pCisJCWdvdG8gYWdhaW47CisKIAlyZXR1cm4g
cmV0OwogCiBvdXRfb2ZfbWVtb3J5OgpAQCAtNzU2LDYgKzc2MSwzMiBAQCBvdXRfb2ZfbWVtb3J5
OgogCXJldHVybiAtRU5PTUVNOwogfQogCitzdGF0aWMgaW50IHhlbl9ibGtia19tYXBfc2VnKHN0
cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCisJCQkgICAgIHN0cnVjdCBwZW5kaW5nX3JlcSAqcGVu
ZGluZ19yZXEsCisJCQkgICAgIHN0cnVjdCBzZWdfYnVmIHNlZ1tdLAorCQkJICAgICBzdHJ1Y3Qg
cGFnZSAqcGFnZXNbXSkKK3sKKwlpbnQgaSwgcmM7CisJZ3JhbnRfcmVmX3QgZ3JlZnNbQkxLSUZf
TUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKworCWZvciAoaSA9IDA7IGkgPCByZXEtPnUucncu
bnJfc2VnbWVudHM7IGkrKykKKwkJZ3JlZnNbaV0gPSByZXEtPnUucncuc2VnW2ldLmdyZWY7CisK
KwlyYyA9IHhlbl9ibGtia19tYXAocGVuZGluZ19yZXEtPmJsa2lmLCBncmVmcywKKwkgICAgICAg
ICAgICAgICAgICAgcGVuZGluZ19yZXEtPnBlcnNpc3RlbnRfZ250cywKKwkgICAgICAgICAgICAg
ICAgICAgcGVuZGluZ19yZXEtPmdyYW50X2hhbmRsZXMsIHBlbmRpbmdfcmVxLT5wYWdlcywKKwkg
ICAgICAgICAgICAgICAgICAgcmVxLT51LnJ3Lm5yX3NlZ21lbnRzLAorCSAgICAgICAgICAgICAg
ICAgICAocGVuZGluZ19yZXEtPm9wZXJhdGlvbiAhPSBCTEtJRl9PUF9SRUFEKSk7CisJaWYgKHJj
KQorCQlyZXR1cm4gcmM7CisKKwlmb3IgKGkgPSAwOyBpIDwgcmVxLT51LnJ3Lm5yX3NlZ21lbnRz
OyBpKyspCisJCXNlZ1tpXS5idWYgPSBwZm5fdG9fbWZuKHBhZ2VfdG9fcGZuKHBlbmRpbmdfcmVx
LT5wYWdlc1tpXSkpCisJCSAgICAgICAgICAgICA8PCBQQUdFX1NISUZUIHwgKHJlcS0+dS5ydy5z
ZWdbaV0uZmlyc3Rfc2VjdCA8PCA5KTsKKworCXJldHVybiAwOworfQorCiBzdGF0aWMgaW50IGRp
c3BhdGNoX2Rpc2NhcmRfaW8oc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsCiAJCQkJc3RydWN0IGJs
a2lmX3JlcXVlc3QgKnJlcSkKIHsKQEAgLTgzMiw3ICs4NjMsMTAgQEAgc3RhdGljIHZvaWQgX19l
bmRfYmxvY2tfaW9fb3Aoc3RydWN0IHBlbmRpbmdfcmVxICpwZW5kaW5nX3JlcSwgaW50IGVycm9y
KQogCSAqIHRoZSBwcm9wZXIgcmVzcG9uc2Ugb24gdGhlIHJpbmcuCiAJICovCiAJaWYgKGF0b21p
Y19kZWNfYW5kX3Rlc3QoJnBlbmRpbmdfcmVxLT5wZW5kY250KSkgewotCQl4ZW5fYmxrYmtfdW5t
YXAocGVuZGluZ19yZXEpOworCQl4ZW5fYmxrYmtfdW5tYXAocGVuZGluZ19yZXEtPmJsa2lmLCBw
ZW5kaW5nX3JlcS0+Z3JhbnRfaGFuZGxlcywKKwkJICAgICAgICAgICAgICAgIHBlbmRpbmdfcmVx
LT5wYWdlcywKKwkJICAgICAgICAgICAgICAgIHBlbmRpbmdfcmVxLT5wZXJzaXN0ZW50X2dudHMs
CisJCSAgICAgICAgICAgICAgICBwZW5kaW5nX3JlcS0+bnJfcGFnZXMpOwogCQltYWtlX3Jlc3Bv
bnNlKHBlbmRpbmdfcmVxLT5ibGtpZiwgcGVuZGluZ19yZXEtPmlkLAogCQkJICAgICAgcGVuZGlu
Z19yZXEtPm9wZXJhdGlvbiwgcGVuZGluZ19yZXEtPnN0YXR1cyk7CiAJCXhlbl9ibGtpZl9wdXQo
cGVuZGluZ19yZXEtPmJsa2lmKTsKQEAgLTEwNDAsNyArMTA3NCw3IEBAIHN0YXRpYyBpbnQgZGlz
cGF0Y2hfcndfYmxvY2tfaW8oc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsCiAJICogdGhlIGh5cGVy
Y2FsbCB0byB1bm1hcCB0aGUgZ3JhbnRzIC0gdGhhdCBpcyBhbGwgZG9uZSBpbgogCSAqIHhlbl9i
bGtia191bm1hcC4KIAkgKi8KLQlpZiAoeGVuX2Jsa2JrX21hcChyZXEsIHBlbmRpbmdfcmVxLCBz
ZWcsIHBhZ2VzKSkKKwlpZiAoeGVuX2Jsa2JrX21hcF9zZWcocmVxLCBwZW5kaW5nX3JlcSwgc2Vn
LCBwYWdlcykpCiAJCWdvdG8gZmFpbF9mbHVzaDsKIAogCS8qCkBAIC0xMTA3LDcgKzExNDEsOSBA
QCBzdGF0aWMgaW50IGRpc3BhdGNoX3J3X2Jsb2NrX2lvKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
LAogCXJldHVybiAwOwogCiAgZmFpbF9mbHVzaDoKLQl4ZW5fYmxrYmtfdW5tYXAocGVuZGluZ19y
ZXEpOworCXhlbl9ibGtia191bm1hcChibGtpZiwgcGVuZGluZ19yZXEtPmdyYW50X2hhbmRsZXMs
CisJICAgICAgICAgICAgICAgIHBlbmRpbmdfcmVxLT5wYWdlcywgcGVuZGluZ19yZXEtPnBlcnNp
c3RlbnRfZ250cywKKwkgICAgICAgICAgICAgICAgcGVuZGluZ19yZXEtPm5yX3BhZ2VzKTsKICBm
YWlsX3Jlc3BvbnNlOgogCS8qIEhhdmVuJ3Qgc3VibWl0dGVkIGFueSBiaW8ncyB5ZXQuICovCiAJ
bWFrZV9yZXNwb25zZShibGtpZiwgcmVxLT51LnJ3LmlkLCByZXEtPm9wZXJhdGlvbiwgQkxLSUZf
UlNQX0VSUk9SKTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k9-0005qN-P7; Thu, 28 Feb 2013 10:29:41 +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 1UB0k7-0005ml-Ei
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:39 +0000
Received: from [193.109.254.147:36688] by server-13.bemta-14.messagelabs.com
	id 5D/3B-30639-3913F215; Thu, 28 Feb 2013 10:29:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!11
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1709 invoked from network); 28 Feb 2013 10:29:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:39 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:38 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:53 +0100
Message-ID: <1362047335-26402-11-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 10/12] xen-blkback: make the queue of free
	requests per backend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

UmVtb3ZlIHRoZSBsYXN0IGRlcGVuZGVuY3kgZnJvbSBibGtiayBieSBtb3ZpbmcgdGhlIGxpc3Qg
b2YgZnJlZQpyZXF1ZXN0cyB0byBibGtpZi4gVGhpcyBjaGFuZ2UgcmVkdWNlcyB0aGUgY29udGVu
dGlvbiBvbiB0aGUgbGlzdCBvZgphdmFpbGFibGUgcmVxdWVzdHMuCgpTaWduZWQtb2ZmLWJ5OiBS
b2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0
ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCi0tLQogZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgfCAgMTIzICsrKysr
KystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNr
L2NvbW1vbi5oICB8ICAgMjcgKysrKysrKysKIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVu
YnVzLmMgIHwgICAxNyArKysrKwogMyBmaWxlcyBjaGFuZ2VkLCA2NyBpbnNlcnRpb25zKCspLCAx
MDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9i
bGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBjNDNk
ZThhLi4wNGFkMmFhIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2Jh
Y2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtNTAsMTgg
KzUwLDE0IEBACiAjaW5jbHVkZSAiY29tbW9uLmgiCiAKIC8qCi0gKiBUaGVzZSBhcmUgcmF0aGVy
IGFyYml0cmFyeS4gVGhleSBhcmUgZmFpcmx5IGxhcmdlIGJlY2F1c2UgYWRqYWNlbnQgcmVxdWVz
dHMKLSAqIHB1bGxlZCBmcm9tIGEgY29tbXVuaWNhdGlvbiByaW5nIGFyZSBxdWl0ZSBsaWtlbHkg
dG8gZW5kIHVwIGJlaW5nIHBhcnQgb2YKLSAqIHRoZSBzYW1lIHNjYXR0ZXIvZ2F0aGVyIHJlcXVl
c3QgYXQgdGhlIGRpc2MuCi0gKgotICogKiogVFJZIElOQ1JFQVNJTkcgJ3hlbl9ibGtpZl9yZXFz
JyBJRiBXUklURSBTUEVFRFMgU0VFTSBUT08gTE9XICoqCi0gKgotICogVGhpcyB3aWxsIGluY3Jl
YXNlIHRoZSBjaGFuY2VzIG9mIGJlaW5nIGFibGUgdG8gd3JpdGUgd2hvbGUgdHJhY2tzLgotICog
NjQgc2hvdWxkIGJlIGVub3VnaCB0byBrZWVwIHVzIGNvbXBldGl0aXZlIHdpdGggTGludXguCisg
KiBUaGlzIGlzIHRoZSBudW1iZXIgb2YgcmVxdWVzdHMgdGhhdCB3aWxsIGJlIHByZS1hbGxvY2F0
ZWQgZm9yIGVhY2ggYmFja2VuZC4KKyAqIEZvciBiZXR0ZXIgcGVyZm9ybWFuY2UgdGhpcyBpcyBz
ZXQgdG8gUklOR19TSVpFICgzMiksIHNvIHJlcXVlc3RzCisgKiBpbiB0aGUgcmluZyB3aWxsIG5l
dmVyIGhhdmUgdG8gd2FpdCBmb3IgYSBmcmVlIHBlbmRpbmdfcmVxLgogICovCi1zdGF0aWMgaW50
IHhlbl9ibGtpZl9yZXFzID0gNjQ7CisKK2ludCB4ZW5fYmxraWZfcmVxcyA9IDMyOwogbW9kdWxl
X3BhcmFtX25hbWVkKHJlcXMsIHhlbl9ibGtpZl9yZXFzLCBpbnQsIDApOwotTU9EVUxFX1BBUk1f
REVTQyhyZXFzLCAiTnVtYmVyIG9mIGJsa2JhY2sgcmVxdWVzdHMgdG8gYWxsb2NhdGUiKTsKK01P
RFVMRV9QQVJNX0RFU0MocmVxcywgIk51bWJlciBvZiBibGtiYWNrIHJlcXVlc3RzIHRvIGFsbG9j
YXRlIHBlciBiYWNrZW5kIik7CiAKIC8qCiAgKiBNYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8g
bWFwIHBlcnNpc3RlbnRseSBpbiBibGtiYWNrLiBGb3IgbWF4aW11bQpAQCAtMTIwLDUwICsxMTYs
OCBAQCBNT0RVTEVfUEFSTV9ERVNDKG1heF9idWZmZXJfcGFnZXMsCiBzdGF0aWMgdW5zaWduZWQg
aW50IGxvZ19zdGF0czsKIG1vZHVsZV9wYXJhbShsb2dfc3RhdHMsIGludCwgMDY0NCk7CiAKLS8q
Ci0gKiBFYWNoIG91dHN0YW5kaW5nIHJlcXVlc3QgdGhhdCB3ZSd2ZSBwYXNzZWQgdG8gdGhlIGxv
d2VyIGRldmljZSBsYXllcnMgaGFzIGEKLSAqICdwZW5kaW5nX3JlcScgYWxsb2NhdGVkIHRvIGl0
LiBFYWNoIGJ1ZmZlcl9oZWFkIHRoYXQgY29tcGxldGVzIGRlY3JlbWVudHMKLSAqIHRoZSBwZW5k
Y250IHRvd2FyZHMgemVyby4gV2hlbiBpdCBoaXRzIHplcm8sIHRoZSBzcGVjaWZpZWQgZG9tYWlu
IGhhcyBhCi0gKiByZXNwb25zZSBxdWV1ZWQgZm9yIGl0LCB3aXRoIHRoZSBzYXZlZCAnaWQnIHBh
c3NlZCBiYWNrLgotICovCi1zdHJ1Y3QgcGVuZGluZ19yZXEgewotCXN0cnVjdCB4ZW5fYmxraWYJ
KmJsa2lmOwotCXU2NAkJCWlkOwotCWludAkJCW5yX3BhZ2VzOwotCWF0b21pY190CQlwZW5kY250
OwotCXVuc2lnbmVkIHNob3J0CQlvcGVyYXRpb247Ci0JaW50CQkJc3RhdHVzOwotCXN0cnVjdCBs
aXN0X2hlYWQJZnJlZV9saXN0OwotCXN0cnVjdCBwZXJzaXN0ZW50X2dudAkqcGVyc2lzdGVudF9n
bnRzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07Ci0Jc3RydWN0IHBhZ2UJCSpwYWdl
c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwotCWdyYW50X2hhbmRsZV90CQlncmFu
dF9oYW5kbGVzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07Ci19OwotCiAjZGVmaW5l
IEJMS0JBQ0tfSU5WQUxJRF9IQU5ETEUgKH4wKQogCi1zdHJ1Y3QgeGVuX2Jsa2JrIHsKLQlzdHJ1
Y3QgcGVuZGluZ19yZXEJKnBlbmRpbmdfcmVxczsKLQkvKiBMaXN0IG9mIGFsbCAncGVuZGluZ19y
ZXEnIGF2YWlsYWJsZSAqLwotCXN0cnVjdCBsaXN0X2hlYWQJcGVuZGluZ19mcmVlOwotCS8qIEFu
ZCBpdHMgc3BpbmxvY2suICovCi0Jc3BpbmxvY2tfdAkJcGVuZGluZ19mcmVlX2xvY2s7Ci0Jd2Fp
dF9xdWV1ZV9oZWFkX3QJcGVuZGluZ19mcmVlX3dxOwotfTsKLQotc3RhdGljIHN0cnVjdCB4ZW5f
YmxrYmsgKmJsa2JrOwotCi0vKgotICogTGl0dGxlIGhlbHBmdWwgbWFjcm8gdG8gZmlndXJlIG91
dCB0aGUgaW5kZXggYW5kIHZpcnR1YWwgYWRkcmVzcyBvZiB0aGUKLSAqIHBlbmRpbmdfcGFnZXNb
Li5dLiBGb3IgZWFjaCAncGVuZGluZ19yZXEnIHdlIGhhdmUgaGF2ZSB1cCB0bwotICogQkxLSUZf
TUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUICgxMSkgcGFnZXMuIFRoZSBzZWcgd291bGQgYmUgZnJv
bSAwIHRocm91Z2gKLSAqIDEwIGFuZCB3b3VsZCBpbmRleCBpbiB0aGUgcGVuZGluZ19wYWdlc1su
Ll0uCi0gKi8KLXN0YXRpYyBpbmxpbmUgaW50IHZhZGRyX3BhZ2VucihzdHJ1Y3QgcGVuZGluZ19y
ZXEgKnJlcSwgaW50IHNlZykKLXsKLQlyZXR1cm4gKHJlcSAtIGJsa2JrLT5wZW5kaW5nX3JlcXMp
ICoKLQkJQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUICsgc2VnOwotfQotCiBzdGF0aWMg
aW5saW5lIGludCBnZXRfZnJlZV9wYWdlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmLCBzdHJ1Y3Qg
cGFnZSAqKnBhZ2UpCiB7CiAJdW5zaWduZWQgbG9uZyBmbGFnczsKQEAgLTQwMCwxOCArMzU0LDE4
IEBAIGZpbmlzaGVkOgogLyoKICAqIFJldHJpZXZlIGZyb20gdGhlICdwZW5kaW5nX3JlcXMnIGEg
ZnJlZSBwZW5kaW5nX3JlcSBzdHJ1Y3R1cmUgdG8gYmUgdXNlZC4KICAqLwotc3RhdGljIHN0cnVj
dCBwZW5kaW5nX3JlcSAqYWxsb2NfcmVxKHZvaWQpCitzdGF0aWMgc3RydWN0IHBlbmRpbmdfcmVx
ICphbGxvY19yZXEoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYpCiB7CiAJc3RydWN0IHBlbmRpbmdf
cmVxICpyZXEgPSBOVUxMOwogCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CiAKLQlzcGluX2xvY2tfaXJx
c2F2ZSgmYmxrYmstPnBlbmRpbmdfZnJlZV9sb2NrLCBmbGFncyk7Ci0JaWYgKCFsaXN0X2VtcHR5
KCZibGtiay0+cGVuZGluZ19mcmVlKSkgewotCQlyZXEgPSBsaXN0X2VudHJ5KGJsa2JrLT5wZW5k
aW5nX2ZyZWUubmV4dCwgc3RydWN0IHBlbmRpbmdfcmVxLAorCXNwaW5fbG9ja19pcnFzYXZlKCZi
bGtpZi0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwlpZiAoIWxpc3RfZW1wdHkoJmJsa2lm
LT5wZW5kaW5nX2ZyZWUpKSB7CisJCXJlcSA9IGxpc3RfZW50cnkoYmxraWYtPnBlbmRpbmdfZnJl
ZS5uZXh0LCBzdHJ1Y3QgcGVuZGluZ19yZXEsCiAJCQkJIGZyZWVfbGlzdCk7CiAJCWxpc3RfZGVs
KCZyZXEtPmZyZWVfbGlzdCk7CiAJfQotCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmJsa2JrLT5w
ZW5kaW5nX2ZyZWVfbG9jaywgZmxhZ3MpOworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmJsa2lm
LT5wZW5kaW5nX2ZyZWVfbG9jaywgZmxhZ3MpOwogCXJldHVybiByZXE7CiB9CiAKQEAgLTQxOSwx
NyArMzczLDE3IEBAIHN0YXRpYyBzdHJ1Y3QgcGVuZGluZ19yZXEgKmFsbG9jX3JlcSh2b2lkKQog
ICogUmV0dXJuIHRoZSAncGVuZGluZ19yZXEnIHN0cnVjdHVyZSBiYWNrIHRvIHRoZSBmcmVlcG9v
bC4gV2UgYWxzbwogICogd2FrZSB1cCB0aGUgdGhyZWFkIGlmIGl0IHdhcyB3YWl0aW5nIGZvciBh
IGZyZWUgcGFnZS4KICAqLwotc3RhdGljIHZvaWQgZnJlZV9yZXEoc3RydWN0IHBlbmRpbmdfcmVx
ICpyZXEpCitzdGF0aWMgdm9pZCBmcmVlX3JlcShzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwgc3Ry
dWN0IHBlbmRpbmdfcmVxICpyZXEpCiB7CiAJdW5zaWduZWQgbG9uZyBmbGFnczsKIAlpbnQgd2Fz
X2VtcHR5OwogCi0Jc3Bpbl9sb2NrX2lycXNhdmUoJmJsa2JrLT5wZW5kaW5nX2ZyZWVfbG9jaywg
ZmxhZ3MpOwotCXdhc19lbXB0eSA9IGxpc3RfZW1wdHkoJmJsa2JrLT5wZW5kaW5nX2ZyZWUpOwot
CWxpc3RfYWRkKCZyZXEtPmZyZWVfbGlzdCwgJmJsa2JrLT5wZW5kaW5nX2ZyZWUpOwotCXNwaW5f
dW5sb2NrX2lycXJlc3RvcmUoJmJsa2JrLT5wZW5kaW5nX2ZyZWVfbG9jaywgZmxhZ3MpOworCXNw
aW5fbG9ja19pcnFzYXZlKCZibGtpZi0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwl3YXNf
ZW1wdHkgPSBsaXN0X2VtcHR5KCZibGtpZi0+cGVuZGluZ19mcmVlKTsKKwlsaXN0X2FkZCgmcmVx
LT5mcmVlX2xpc3QsICZibGtpZi0+cGVuZGluZ19mcmVlKTsKKwlzcGluX3VubG9ja19pcnFyZXN0
b3JlKCZibGtpZi0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKIAlpZiAod2FzX2VtcHR5KQot
CQl3YWtlX3VwKCZibGtiay0+cGVuZGluZ19mcmVlX3dxKTsKKwkJd2FrZV91cCgmYmxraWYtPnBl
bmRpbmdfZnJlZV93cSk7CiB9CiAKIC8qCkBAIC01NjQsOCArNTE4LDggQEAgaW50IHhlbl9ibGtp
Zl9zY2hlZHVsZSh2b2lkICphcmcpCiAJCWlmICh0aW1lb3V0ID09IDApCiAJCQlnb3RvIHB1cmdl
X2dudF9saXN0OwogCQl0aW1lb3V0ID0gd2FpdF9ldmVudF9pbnRlcnJ1cHRpYmxlX3RpbWVvdXQo
Ci0JCQlibGtiay0+cGVuZGluZ19mcmVlX3dxLAotCQkJIWxpc3RfZW1wdHkoJmJsa2JrLT5wZW5k
aW5nX2ZyZWUpIHx8CisJCQlibGtpZi0+cGVuZGluZ19mcmVlX3dxLAorCQkJIWxpc3RfZW1wdHko
JmJsa2lmLT5wZW5kaW5nX2ZyZWUpIHx8CiAJCQlrdGhyZWFkX3Nob3VsZF9zdG9wKCksCiAJCQl0
aW1lb3V0KTsKIAkJaWYgKHRpbWVvdXQgPT0gMCkKQEAgLTg4Niw3ICs4NDAsNyBAQCBzdGF0aWMg
dm9pZCBfX2VuZF9ibG9ja19pb19vcChzdHJ1Y3QgcGVuZGluZ19yZXEgKnBlbmRpbmdfcmVxLCBp
bnQgZXJyb3IpCiAJCQlpZiAoYXRvbWljX3JlYWQoJnBlbmRpbmdfcmVxLT5ibGtpZi0+ZHJhaW4p
KQogCQkJCWNvbXBsZXRlKCZwZW5kaW5nX3JlcS0+YmxraWYtPmRyYWluX2NvbXBsZXRlKTsKIAkJ
fQotCQlmcmVlX3JlcShwZW5kaW5nX3JlcSk7CisJCWZyZWVfcmVxKHBlbmRpbmdfcmVxLT5ibGtp
ZiwgcGVuZGluZ19yZXEpOwogCX0KIH0KIApAQCAtOTI5LDcgKzg4Myw3IEBAIF9fZG9fYmxvY2tf
aW9fb3Aoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYpCiAJCQlicmVhazsKIAkJfQogCi0JCXBlbmRp
bmdfcmVxID0gYWxsb2NfcmVxKCk7CisJCXBlbmRpbmdfcmVxID0gYWxsb2NfcmVxKGJsa2lmKTsK
IAkJaWYgKE5VTEwgPT0gcGVuZGluZ19yZXEpIHsKIAkJCWJsa2lmLT5zdF9vb19yZXErKzsKIAkJ
CW1vcmVfdG9fZG8gPSAxOwpAQCAtOTU0LDcgKzkwOCw3IEBAIF9fZG9fYmxvY2tfaW9fb3Aoc3Ry
dWN0IHhlbl9ibGtpZiAqYmxraWYpCiAJCS8qIEFwcGx5IGFsbCBzYW5pdHkgY2hlY2tzIHRvIC9w
cml2YXRlIGNvcHkvIG9mIHJlcXVlc3QuICovCiAJCWJhcnJpZXIoKTsKIAkJaWYgKHVubGlrZWx5
KHJlcS5vcGVyYXRpb24gPT0gQkxLSUZfT1BfRElTQ0FSRCkpIHsKLQkJCWZyZWVfcmVxKHBlbmRp
bmdfcmVxKTsKKwkJCWZyZWVfcmVxKGJsa2lmLCBwZW5kaW5nX3JlcSk7CiAJCQlpZiAoZGlzcGF0
Y2hfZGlzY2FyZF9pbyhibGtpZiwgJnJlcSkpCiAJCQkJYnJlYWs7CiAJCX0gZWxzZSBpZiAoZGlz
cGF0Y2hfcndfYmxvY2tfaW8oYmxraWYsICZyZXEsIHBlbmRpbmdfcmVxKSkKQEAgLTExNTcsNyAr
MTExMSw3IEBAIHN0YXRpYyBpbnQgZGlzcGF0Y2hfcndfYmxvY2tfaW8oc3RydWN0IHhlbl9ibGtp
ZiAqYmxraWYsCiAgZmFpbF9yZXNwb25zZToKIAkvKiBIYXZlbid0IHN1Ym1pdHRlZCBhbnkgYmlv
J3MgeWV0LiAqLwogCW1ha2VfcmVzcG9uc2UoYmxraWYsIHJlcS0+dS5ydy5pZCwgcmVxLT5vcGVy
YXRpb24sIEJMS0lGX1JTUF9FUlJPUik7Ci0JZnJlZV9yZXEocGVuZGluZ19yZXEpOworCWZyZWVf
cmVxKGJsa2lmLCBwZW5kaW5nX3JlcSk7CiAJbXNsZWVwKDEpOyAvKiBiYWNrIG9mZiBhIGJpdCAq
LwogCXJldHVybiAtRUlPOwogCkBAIC0xMjEzLDUxICsxMTY3LDIwIEBAIHN0YXRpYyB2b2lkIG1h
a2VfcmVzcG9uc2Uoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIHU2NCBpZCwKIAogc3RhdGljIGlu
dCBfX2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIHsKLQlpbnQgaTsKIAlpbnQgcmMgPSAwOwog
CiAJaWYgKCF4ZW5fZG9tYWluKCkpCiAJCXJldHVybiAtRU5PREVWOwogCi0JYmxrYmsgPSBremFs
bG9jKHNpemVvZihzdHJ1Y3QgeGVuX2Jsa2JrKSwgR0ZQX0tFUk5FTCk7Ci0JaWYgKCFibGtiaykg
ewotCQlwcl9hbGVydChEUlZfUEZYICIlczogb3V0IG9mIG1lbW9yeSFcbiIsIF9fZnVuY19fKTsK
LQkJcmV0dXJuIC1FTk9NRU07Ci0JfQotCi0KLQlibGtiay0+cGVuZGluZ19yZXFzICAgICAgICAg
ID0ga3phbGxvYyhzaXplb2YoYmxrYmstPnBlbmRpbmdfcmVxc1swXSkgKgotCQkJCQl4ZW5fYmxr
aWZfcmVxcywgR0ZQX0tFUk5FTCk7Ci0KLQlpZiAoIWJsa2JrLT5wZW5kaW5nX3JlcXMpIHsKLQkJ
cmMgPSAtRU5PTUVNOwotCQlnb3RvIG91dF9vZl9tZW1vcnk7Ci0JfQotCiAJcmMgPSB4ZW5fYmxr
aWZfaW50ZXJmYWNlX2luaXQoKTsKIAlpZiAocmMpCiAJCWdvdG8gZmFpbGVkX2luaXQ7CiAKLQlJ
TklUX0xJU1RfSEVBRCgmYmxrYmstPnBlbmRpbmdfZnJlZSk7Ci0Jc3Bpbl9sb2NrX2luaXQoJmJs
a2JrLT5wZW5kaW5nX2ZyZWVfbG9jayk7Ci0JaW5pdF93YWl0cXVldWVfaGVhZCgmYmxrYmstPnBl
bmRpbmdfZnJlZV93cSk7Ci0KLQlmb3IgKGkgPSAwOyBpIDwgeGVuX2Jsa2lmX3JlcXM7IGkrKykK
LQkJbGlzdF9hZGRfdGFpbCgmYmxrYmstPnBlbmRpbmdfcmVxc1tpXS5mcmVlX2xpc3QsCi0JCQkg
ICAgICAmYmxrYmstPnBlbmRpbmdfZnJlZSk7Ci0KIAlyYyA9IHhlbl9ibGtpZl94ZW5idXNfaW5p
dCgpOwogCWlmIChyYykKIAkJZ290byBmYWlsZWRfaW5pdDsKIAotCXJldHVybiAwOwotCi0gb3V0
X29mX21lbW9yeToKLQlwcl9hbGVydChEUlZfUEZYICIlczogb3V0IG9mIG1lbW9yeVxuIiwgX19m
dW5jX18pOwogIGZhaWxlZF9pbml0OgotCWtmcmVlKGJsa2JrLT5wZW5kaW5nX3JlcXMpOwotCWtm
cmVlKGJsa2JrKTsKLQlibGtiayA9IE5VTEw7CiAJcmV0dXJuIHJjOwogfQogCmRpZmYgLS1naXQg
YS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oIGIvZHJpdmVycy9ibG9jay94ZW4t
YmxrYmFjay9jb21tb24uaAppbmRleCA2MDRiZDMwLi4wYjBhZDNmIDEwMDY0NAotLS0gYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJs
a2JhY2svY29tbW9uLmgKQEAgLTIxNCw2ICsyMTQsMTQgQEAgc3RydWN0IHhlbl9ibGtpZiB7CiAJ
aW50CQkJZnJlZV9wYWdlc19udW07CiAJc3RydWN0IGxpc3RfaGVhZAlmcmVlX3BhZ2VzOwogCisJ
LyogQWxsb2NhdGlvbiBvZiBwZW5kaW5nX3JlcXMgKi8KKwlzdHJ1Y3QgcGVuZGluZ19yZXEJKnBl
bmRpbmdfcmVxczsKKwkvKiBMaXN0IG9mIGFsbCAncGVuZGluZ19yZXEnIGF2YWlsYWJsZSAqLwor
CXN0cnVjdCBsaXN0X2hlYWQJcGVuZGluZ19mcmVlOworCS8qIEFuZCBpdHMgc3BpbmxvY2suICov
CisJc3BpbmxvY2tfdAkJcGVuZGluZ19mcmVlX2xvY2s7CisJd2FpdF9xdWV1ZV9oZWFkX3QJcGVu
ZGluZ19mcmVlX3dxOworCiAJLyogc3RhdGlzdGljcyAqLwogCXVuc2lnbmVkIGxvbmcJCXN0X3By
aW50OwogCWludAkJCXN0X3JkX3JlcTsKQEAgLTIyNyw2ICsyMzUsMjUgQEAgc3RydWN0IHhlbl9i
bGtpZiB7CiAJd2FpdF9xdWV1ZV9oZWFkX3QJd2FpdGluZ190b19mcmVlOwogfTsKIAorLyoKKyAq
IEVhY2ggb3V0c3RhbmRpbmcgcmVxdWVzdCB0aGF0IHdlJ3ZlIHBhc3NlZCB0byB0aGUgbG93ZXIg
ZGV2aWNlIGxheWVycyBoYXMgYQorICogJ3BlbmRpbmdfcmVxJyBhbGxvY2F0ZWQgdG8gaXQuIEVh
Y2ggYnVmZmVyX2hlYWQgdGhhdCBjb21wbGV0ZXMgZGVjcmVtZW50cworICogdGhlIHBlbmRjbnQg
dG93YXJkcyB6ZXJvLiBXaGVuIGl0IGhpdHMgemVybywgdGhlIHNwZWNpZmllZCBkb21haW4gaGFz
IGEKKyAqIHJlc3BvbnNlIHF1ZXVlZCBmb3IgaXQsIHdpdGggdGhlIHNhdmVkICdpZCcgcGFzc2Vk
IGJhY2suCisgKi8KK3N0cnVjdCBwZW5kaW5nX3JlcSB7CisJc3RydWN0IHhlbl9ibGtpZgkqYmxr
aWY7CisJdTY0CQkJaWQ7CisJaW50CQkJbnJfcGFnZXM7CisJYXRvbWljX3QJCXBlbmRjbnQ7CisJ
dW5zaWduZWQgc2hvcnQJCW9wZXJhdGlvbjsKKwlpbnQJCQlzdGF0dXM7CisJc3RydWN0IGxpc3Rf
aGVhZAlmcmVlX2xpc3Q7CisJc3RydWN0IHBlcnNpc3RlbnRfZ250CSpwZXJzaXN0ZW50X2dudHNb
QkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGFnZQkJKnBhZ2VzW0JM
S0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CisJZ3JhbnRfaGFuZGxlX3QJCWdyYW50X2hh
bmRsZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKK307CisKIAogI2RlZmluZSB2
YmRfc3ooX3YpCSgoX3YpLT5iZGV2LT5iZF9wYXJ0ID8gXAogCQkJIChfdiktPmJkZXYtPmJkX3Bh
cnQtPm5yX3NlY3RzIDogXApkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94
ZW5idXMuYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKaW5kZXggZDc5MjZl
Yy4uOGY5MjljYiAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMu
YworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCkBAIC0zMCw2ICszMCw4
IEBAIHN0cnVjdCBiYWNrZW5kX2luZm8gewogCWNoYXIJCQkqbW9kZTsKIH07CiAKK2V4dGVybiBp
bnQgeGVuX2Jsa2lmX3JlcXM7CisKIHN0YXRpYyBzdHJ1Y3Qga21lbV9jYWNoZSAqeGVuX2Jsa2lm
X2NhY2hlcDsKIHN0YXRpYyB2b2lkIGNvbm5lY3Qoc3RydWN0IGJhY2tlbmRfaW5mbyAqKTsKIHN0
YXRpYyBpbnQgY29ubmVjdF9yaW5nKHN0cnVjdCBiYWNrZW5kX2luZm8gKik7CkBAIC0xMDQsNiAr
MTA2LDcgQEAgc3RhdGljIHZvaWQgeGVuX3VwZGF0ZV9ibGtpZl9zdGF0dXMoc3RydWN0IHhlbl9i
bGtpZiAqYmxraWYpCiBzdGF0aWMgc3RydWN0IHhlbl9ibGtpZiAqeGVuX2Jsa2lmX2FsbG9jKGRv
bWlkX3QgZG9taWQpCiB7CiAJc3RydWN0IHhlbl9ibGtpZiAqYmxraWY7CisJaW50IGk7CiAKIAli
bGtpZiA9IGttZW1fY2FjaGVfemFsbG9jKHhlbl9ibGtpZl9jYWNoZXAsIEdGUF9LRVJORUwpOwog
CWlmICghYmxraWYpCkBAIC0xMjIsNiArMTI1LDE5IEBAIHN0YXRpYyBzdHJ1Y3QgeGVuX2Jsa2lm
ICp4ZW5fYmxraWZfYWxsb2MoZG9taWRfdCBkb21pZCkKIAlzcGluX2xvY2tfaW5pdCgmYmxraWYt
PmZyZWVfcGFnZXNfbG9jayk7CiAJSU5JVF9MSVNUX0hFQUQoJmJsa2lmLT5mcmVlX3BhZ2VzKTsK
IAlibGtpZi0+ZnJlZV9wYWdlc19udW0gPSAwOworCWJsa2lmLT5wZW5kaW5nX3JlcXMgPSBremFs
bG9jKHNpemVvZihibGtpZi0+cGVuZGluZ19yZXFzWzBdKSAqCisJICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgeGVuX2Jsa2lmX3JlcXMsIEdGUF9LRVJORUwpOworCWlmICghYmxraWYtPnBl
bmRpbmdfcmVxcykgeworCQlrbWVtX2NhY2hlX2ZyZWUoeGVuX2Jsa2lmX2NhY2hlcCwgYmxraWYp
OworCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKwl9CisJSU5JVF9MSVNUX0hFQUQoJmJsa2lm
LT5wZW5kaW5nX2ZyZWUpOworCXNwaW5fbG9ja19pbml0KCZibGtpZi0+cGVuZGluZ19mcmVlX2xv
Y2spOworCWluaXRfd2FpdHF1ZXVlX2hlYWQoJmJsa2lmLT5wZW5kaW5nX2ZyZWVfd3EpOworCisJ
Zm9yIChpID0gMDsgaSA8IHhlbl9ibGtpZl9yZXFzOyBpKyspCisJCWxpc3RfYWRkX3RhaWwoJmJs
a2lmLT5wZW5kaW5nX3JlcXNbaV0uZnJlZV9saXN0LAorCQkJICAgICAgJmJsa2lmLT5wZW5kaW5n
X2ZyZWUpOwogCiAJcmV0dXJuIGJsa2lmOwogfQpAQCAtMjA0LDYgKzIyMCw3IEBAIHN0YXRpYyB2
b2lkIHhlbl9ibGtpZl9mcmVlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmKQogewogCWlmICghYXRv
bWljX2RlY19hbmRfdGVzdCgmYmxraWYtPnJlZmNudCkpCiAJCUJVRygpOworCWtmcmVlKGJsa2lm
LT5wZW5kaW5nX3JlcXMpOwogCWttZW1fY2FjaGVfZnJlZSh4ZW5fYmxraWZfY2FjaGVwLCBibGtp
Zik7CiB9CiAKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0kA-0005rS-Qs; Thu, 28 Feb 2013 10:29:42 +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 1UB0k8-0005pF-Vy
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:41 +0000
Received: from [193.109.254.147:32830] by server-15.bemta-14.messagelabs.com
	id 50/0E-24599-4913F215; Thu, 28 Feb 2013 10:29:40 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!13
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1828 invoked from network); 28 Feb 2013 10:29:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:40 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:39 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:55 +0100
Message-ID: <1362047335-26402-13-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
	descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SW5kaXJlY3QgZGVzY3JpcHRvcnMgaW50cm9kdWNlIGEgbmV3IGJsb2NrIG9wZXJhdGlvbgooQkxL
SUZfT1BfSU5ESVJFQ1QpIHRoYXQgcGFzc2VzIGdyYW50IHJlZmVyZW5jZXMgaW5zdGVhZCBvZiBz
ZWdtZW50cwppbiB0aGUgcmVxdWVzdC4gVGhpcyBncmFudCByZWZlcmVuY2VzIGFyZSBmaWxsZWQg
d2l0aCBhcnJheXMgb2YKYmxraWZfcmVxdWVzdF9zZWdtZW50X2FsaWduZWQsIHRoaXMgd2F5IHdl
IGNhbiBzZW5kIG1vcmUgc2VnbWVudHMgaW4gYQpyZXF1ZXN0LgoKVGhlIHByb3Bvc2VkIGltcGxl
bWVudGF0aW9uIHNldHMgdGhlIG1heGltdW0gbnVtYmVyIG9mIGluZGlyZWN0IGdyZWZzCihmcmFt
ZXMgZmlsbGVkIHdpdGggYmxraWZfcmVxdWVzdF9zZWdtZW50X2FsaWduZWQpIHRvIDI1NiBpbiB0
aGUKYmFja2VuZCBhbmQgNjQgaW4gdGhlIGZyb250ZW5kLiBUaGUgdmFsdWUgaW4gdGhlIGZyb250
ZW5kIGhhcyBiZWVuCmNob3NlbiBleHBlcmltZW50YWxseSwgYW5kIHRoZSBiYWNrZW5kIHZhbHVl
IGhhcyBiZWVuIHNldCB0byBhIHNhbmUKdmFsdWUgdGhhdCBhbGxvd3MgZXhwYW5kaW5nIHRoZSBt
YXhpbXVtIG51bWJlciBvZiBpbmRpcmVjdCBkZXNjcmlwdG9ycwppbiB0aGUgZnJvbnRlbmQgaWYg
bmVlZGVkLgoKVGhlIG1pZ3JhdGlvbiBjb2RlIGhhcyBjaGFuZ2VkIGZyb20gdGhlIHByZXZpb3Vz
IGltcGxlbWVudGF0aW9uLCBpbgp3aGljaCB3ZSBzaW1wbHkgcmVtYXBwZWQgdGhlIHNlZ21lbnRz
IG9uIHRoZSBzaGFyZWQgcmluZy4gTm93IHRoZQptYXhpbXVtIG51bWJlciBvZiBzZWdtZW50cyBh
bGxvd2VkIGluIGEgcmVxdWVzdCBjYW4gY2hhbmdlIGRlcGVuZGluZwpvbiB0aGUgYmFja2VuZCwg
c28gd2UgaGF2ZSB0byByZXF1ZXVlIGFsbCB0aGUgcmVxdWVzdHMgaW4gdGhlIHJpbmcgYW5kCmlu
IHRoZSBxdWV1ZSBhbmQgc3BsaXQgdGhlIGJpb3MgaW4gdGhlbSBpZiB0aGV5IGFyZSBiaWdnZXIg
dGhhbiB0aGUKbmV3IG1heGltdW0gbnVtYmVyIG9mIHNlZ21lbnRzLgoKU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25yYWQgUnplc3p1
dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgIDEyOSArKysr
KysrLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oICB8ICAgODAgKysrKysr
LQogZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyAgfCAgICA4ICsKIGRyaXZlcnMv
YmxvY2sveGVuLWJsa2Zyb250LmMgICAgICAgIHwgIDQ5OCArKysrKysrKysrKysrKysrKysrKysr
KysrKysrKy0tLS0tLQogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2lvL2Jsa2lmLmggICAgfCAgIDI1
ICsrCiA1IGZpbGVzIGNoYW5nZWQsIDYyMiBpbnNlcnRpb25zKCspLCAxMTggZGVsZXRpb25zKC0p
CgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgYi9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCAwZmEzMGRiLi45OGViMTZiIDEw
MDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYworKysgYi9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtNzAsNyArNzAsNyBAQCBNT0RVTEVf
UEFSTV9ERVNDKHJlcXMsICJOdW1iZXIgb2YgYmxrYmFjayByZXF1ZXN0cyB0byBhbGxvY2F0ZSBw
ZXIgYmFja2VuZCIpOwogICogYWxnb3JpdGhtLgogICovCiAKLXN0YXRpYyBpbnQgeGVuX2Jsa2lm
X21heF9wZ3JhbnRzID0gMzUyOworc3RhdGljIGludCB4ZW5fYmxraWZfbWF4X3BncmFudHMgPSAx
MDI0OwogbW9kdWxlX3BhcmFtX25hbWVkKG1heF9wZXJzaXN0ZW50X2dyYW50cywgeGVuX2Jsa2lm
X21heF9wZ3JhbnRzLCBpbnQsIDA2NDQpOwogTU9EVUxFX1BBUk1fREVTQyhtYXhfcGVyc2lzdGVu
dF9ncmFudHMsCiAgICAgICAgICAgICAgICAgICJNYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8g
bWFwIHBlcnNpc3RlbnRseSIpOwpAQCAtNTc4LDEwICs1NzgsNiBAQCBwdXJnZV9nbnRfbGlzdDoK
IAlyZXR1cm4gMDsKIH0KIAotc3RydWN0IHNlZ19idWYgewotCXVuc2lnbmVkIGxvbmcgYnVmOwot
CXVuc2lnbmVkIGludCBuc2VjOwotfTsKIC8qCiAgKiBVbm1hcCB0aGUgZ3JhbnQgcmVmZXJlbmNl
cywgYW5kIGFsc28gcmVtb3ZlIHRoZSBNMlAgb3Zlci1yaWRlcwogICogdXNlZCBpbiB0aGUgJ3Bl
bmRpbmdfcmVxJy4KQEAgLTc2MSwzMiArNzU3LDc5IEBAIG91dF9vZl9tZW1vcnk6CiAJcmV0dXJu
IC1FTk9NRU07CiB9CiAKLXN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcF9zZWcoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKnJlcSwKLQkJCSAgICAgc3RydWN0IHBlbmRpbmdfcmVxICpwZW5kaW5nX3JlcSwK
K3N0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcF9zZWcoc3RydWN0IHBlbmRpbmdfcmVxICpwZW5kaW5n
X3JlcSwKIAkJCSAgICAgc3RydWN0IHNlZ19idWYgc2VnW10sCiAJCQkgICAgIHN0cnVjdCBwYWdl
ICpwYWdlc1tdKQogewogCWludCBpLCByYzsKLQlncmFudF9yZWZfdCBncmVmc1tCTEtJRl9NQVhf
U0VHTUVOVFNfUEVSX1JFUVVFU1RdOwogCi0JZm9yIChpID0gMDsgaSA8IHJlcS0+dS5ydy5ucl9z
ZWdtZW50czsgaSsrKQotCQlncmVmc1tpXSA9IHJlcS0+dS5ydy5zZWdbaV0uZ3JlZjsKLQotCXJj
ID0geGVuX2Jsa2JrX21hcChwZW5kaW5nX3JlcS0+YmxraWYsIGdyZWZzLAorCXJjID0geGVuX2Js
a2JrX21hcChwZW5kaW5nX3JlcS0+YmxraWYsIHBlbmRpbmdfcmVxLT5ncmVmcywKIAkgICAgICAg
ICAgICAgICAgICAgcGVuZGluZ19yZXEtPnBlcnNpc3RlbnRfZ250cywKIAkgICAgICAgICAgICAg
ICAgICAgcGVuZGluZ19yZXEtPmdyYW50X2hhbmRsZXMsIHBlbmRpbmdfcmVxLT5wYWdlcywKLQkg
ICAgICAgICAgICAgICAgICAgcmVxLT51LnJ3Lm5yX3NlZ21lbnRzLAorCSAgICAgICAgICAgICAg
ICAgICBwZW5kaW5nX3JlcS0+bnJfcGFnZXMsCiAJICAgICAgICAgICAgICAgICAgIChwZW5kaW5n
X3JlcS0+b3BlcmF0aW9uICE9IEJMS0lGX09QX1JFQUQpKTsKIAlpZiAocmMpCiAJCXJldHVybiBy
YzsKIAotCWZvciAoaSA9IDA7IGkgPCByZXEtPnUucncubnJfc2VnbWVudHM7IGkrKykKLQkJc2Vn
W2ldLmJ1ZiA9IHBmbl90b19tZm4ocGFnZV90b19wZm4ocGVuZGluZ19yZXEtPnBhZ2VzW2ldKSkK
LQkJICAgICAgICAgICAgIDw8IFBBR0VfU0hJRlQgfCAocmVxLT51LnJ3LnNlZ1tpXS5maXJzdF9z
ZWN0IDw8IDkpOworCWZvciAoaSA9IDA7IGkgPCBwZW5kaW5nX3JlcS0+bnJfcGFnZXM7IGkrKykK
KwkJc2VnW2ldLmJ1ZiB8PSBwZm5fdG9fbWZuKHBhZ2VfdG9fcGZuKHBlbmRpbmdfcmVxLT5wYWdl
c1tpXSkpCisJCSAgICAgICAgICAgICA8PCBQQUdFX1NISUZUOwogCiAJcmV0dXJuIDA7CiB9CiAK
K3N0YXRpYyBpbnQgeGVuX2Jsa2JrX3BhcnNlX2luZGlyZWN0KHN0cnVjdCBibGtpZl9yZXF1ZXN0
ICpyZXEsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcGVuZGlu
Z19yZXEgKnBlbmRpbmdfcmVxLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
c3RydWN0IHNlZ19idWYgc2VnW10sCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdHJ1Y3QgcGh5c19yZXEgKnByZXEpCit7CisJc3RydWN0IHBlcnNpc3RlbnRfZ250ICoqcGVy
c2lzdGVudCA9CisJCXBlbmRpbmdfcmVxLT5pbmRpcmVjdF9wZXJzaXN0ZW50X2dudHM7CisJc3Ry
dWN0IHBhZ2UgKipwYWdlcyA9IHBlbmRpbmdfcmVxLT5pbmRpcmVjdF9wYWdlczsKKwlzdHJ1Y3Qg
eGVuX2Jsa2lmICpibGtpZiA9IHBlbmRpbmdfcmVxLT5ibGtpZjsKKwlpbnQgaW5kaXJlY3RfZ3Jl
ZnMsIHJjLCBuLCBuc2VnLCBpOworCXN0cnVjdCBibGtpZl9yZXF1ZXN0X3NlZ21lbnRfYWxpZ25l
ZCAqc2VnbWVudHMgPSBOVUxMOworCisJbnNlZyA9IHBlbmRpbmdfcmVxLT5ucl9wYWdlczsKKwlp
bmRpcmVjdF9ncmVmcyA9IChuc2VnICsgU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgLSAxKSAvCisJ
CSAgICAgICAgIFNFR1NfUEVSX0lORElSRUNUX0ZSQU1FOworCisJcmMgPSB4ZW5fYmxrYmtfbWFw
KGJsa2lmLCByZXEtPnUuaW5kaXJlY3QuaW5kaXJlY3RfZ3JlZnMsCisJICAgICAgICAgICAgICAg
ICAgIHBlcnNpc3RlbnQsIHBlbmRpbmdfcmVxLT5pbmRpcmVjdF9oYW5kbGVzLAorCSAgICAgICAg
ICAgICAgICAgICBwYWdlcywgaW5kaXJlY3RfZ3JlZnMsIHRydWUpOworCWlmIChyYykKKwkJZ290
byB1bm1hcDsKKworCWZvciAobiA9IDAsIGkgPSAwOyBuIDwgbnNlZzsgbisrKSB7CisJCWlmICgo
biAlIFNFR1NfUEVSX0lORElSRUNUX0ZSQU1FKSA9PSAwKSB7CisJCQkvKiBNYXAgaW5kaXJlY3Qg
c2VnbWVudHMgKi8KKwkJCWlmIChzZWdtZW50cykKKwkJCQlrdW5tYXBfYXRvbWljKHNlZ21lbnRz
KTsKKwkJCXNlZ21lbnRzID0KKwkJCQlrbWFwX2F0b21pYyhwYWdlc1tuL1NFR1NfUEVSX0lORElS
RUNUX0ZSQU1FXSk7CisJCX0KKwkJaSA9IG4gJSBTRUdTX1BFUl9JTkRJUkVDVF9GUkFNRTsKKwkJ
cGVuZGluZ19yZXEtPmdyZWZzW25dID0gc2VnbWVudHNbaV0uZ3JlZjsKKwkJc2VnW25dLm5zZWMg
PSBzZWdtZW50c1tpXS5sYXN0X3NlY3QgLQorCQkJc2VnbWVudHNbaV0uZmlyc3Rfc2VjdCArIDE7
CisJCXNlZ1tuXS5idWYgPSBzZWdtZW50c1tpXS5maXJzdF9zZWN0IDw8IDk7CisJCWlmICgoc2Vn
bWVudHNbaV0ubGFzdF9zZWN0ID49IChQQUdFX1NJWkUgPj4gOSkpIHx8CisJICAgIAkgICAgKHNl
Z21lbnRzW2ldLmxhc3Rfc2VjdCA8CisJICAgIAkgICAgIHNlZ21lbnRzW2ldLmZpcnN0X3NlY3Qp
KSB7CisJCQlyYyA9IC1FSU5WQUw7CisJCQlnb3RvIHVubWFwOworCQl9CisJCXByZXEtPm5yX3Nl
Y3RzICs9IHNlZ1tuXS5uc2VjOworCX0KKwordW5tYXA6CisJaWYgKHNlZ21lbnRzKQorCQlrdW5t
YXBfYXRvbWljKHNlZ21lbnRzKTsKKwl4ZW5fYmxrYmtfdW5tYXAoYmxraWYsIHBlbmRpbmdfcmVx
LT5pbmRpcmVjdF9oYW5kbGVzLAorICAgICAgICAgICAgICAgICAgICAgICAgcGFnZXMsIHBlcnNp
c3RlbnQsIGluZGlyZWN0X2dyZWZzKTsKKwlyZXR1cm4gcmM7Cit9CisKIHN0YXRpYyBpbnQgZGlz
cGF0Y2hfZGlzY2FyZF9pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAkJCQlzdHJ1Y3QgYmxr
aWZfcmVxdWVzdCAqcmVxKQogewpAQCAtOTgwLDE3ICsxMDIzLDIxIEBAIHN0YXRpYyBpbnQgZGlz
cGF0Y2hfcndfYmxvY2tfaW8oc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsCiAJCQkJc3RydWN0IHBl
bmRpbmdfcmVxICpwZW5kaW5nX3JlcSkKIHsKIAlzdHJ1Y3QgcGh5c19yZXEgcHJlcTsKLQlzdHJ1
Y3Qgc2VnX2J1ZiBzZWdbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3Qg
c2VnX2J1ZiAqc2VnID0gcGVuZGluZ19yZXEtPnNlZzsKIAl1bnNpZ25lZCBpbnQgbnNlZzsKIAlz
dHJ1Y3QgYmlvICpiaW8gPSBOVUxMOwotCXN0cnVjdCBiaW8gKmJpb2xpc3RbQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgYmlvICoqYmlvbGlzdCA9IHBlbmRpbmdfcmVx
LT5iaW9saXN0OwogCWludCBpLCBuYmlvID0gMDsKIAlpbnQgb3BlcmF0aW9uOwogCXN0cnVjdCBi
bGtfcGx1ZyBwbHVnOwogCWJvb2wgZHJhaW4gPSBmYWxzZTsKIAlzdHJ1Y3QgcGFnZSAqKnBhZ2Vz
ID0gcGVuZGluZ19yZXEtPnBhZ2VzOworCXVuc2lnbmVkIHNob3J0IHJlcV9vcGVyYXRpb247CisK
KwlyZXFfb3BlcmF0aW9uID0gcmVxLT5vcGVyYXRpb24gPT0gQkxLSUZfT1BfSU5ESVJFQ1QgPwor
CSAgICAgICAgICAgICAgICByZXEtPnUuaW5kaXJlY3QuaW5kaXJlY3Rfb3AgOiByZXEtPm9wZXJh
dGlvbjsKIAotCXN3aXRjaCAocmVxLT5vcGVyYXRpb24pIHsKKwlzd2l0Y2ggKHJlcV9vcGVyYXRp
b24pIHsKIAljYXNlIEJMS0lGX09QX1JFQUQ6CiAJCWJsa2lmLT5zdF9yZF9yZXErKzsKIAkJb3Bl
cmF0aW9uID0gUkVBRDsKQEAgLTEwMTIsMzMgKzEwNTksNDkgQEAgc3RhdGljIGludCBkaXNwYXRj
aF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAl9CiAKIAkvKiBDaGVjayB0
aGF0IHRoZSBudW1iZXIgb2Ygc2VnbWVudHMgaXMgc2FuZS4gKi8KLQluc2VnID0gcmVxLT51LnJ3
Lm5yX3NlZ21lbnRzOworCW5zZWcgPSByZXEtPm9wZXJhdGlvbiA9PSBCTEtJRl9PUF9JTkRJUkVD
VCA/CisJICAgICAgIHJlcS0+dS5pbmRpcmVjdC5ucl9zZWdtZW50cyA6IHJlcS0+dS5ydy5ucl9z
ZWdtZW50czsKIAogCWlmICh1bmxpa2VseShuc2VnID09IDAgJiYgb3BlcmF0aW9uICE9IFdSSVRF
X0ZMVVNIKSB8fAotCSAgICB1bmxpa2VseShuc2VnID4gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUKSkgeworCSAgICB1bmxpa2VseSgocmVxLT5vcGVyYXRpb24gIT0gQkxLSUZfT1BfSU5E
SVJFQ1QpICYmCisJICAgICAgICAgICAgIChuc2VnID4gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUKSkgfHwKKwkgICAgdW5saWtlbHkoKHJlcS0+b3BlcmF0aW9uID09IEJMS0lGX09QX0lO
RElSRUNUKSAmJgorCSAgICAgICAgICAgICAobnNlZyA+IE1BWF9JTkRJUkVDVF9TRUdNRU5UUykp
KSB7CiAJCXByX2RlYnVnKERSVl9QRlggIkJhZCBudW1iZXIgb2Ygc2VnbWVudHMgaW4gcmVxdWVz
dCAoJWQpXG4iLAogCQkJIG5zZWcpOwogCQkvKiBIYXZlbid0IHN1Ym1pdHRlZCBhbnkgYmlvJ3Mg
eWV0LiAqLwogCQlnb3RvIGZhaWxfcmVzcG9uc2U7CiAJfQogCi0JcHJlcS5zZWN0b3JfbnVtYmVy
ID0gcmVxLT51LnJ3LnNlY3Rvcl9udW1iZXI7CiAJcHJlcS5ucl9zZWN0cyAgICAgID0gMDsKIAog
CXBlbmRpbmdfcmVxLT5ibGtpZiAgICAgPSBibGtpZjsKLQlwZW5kaW5nX3JlcS0+aWQgICAgICAg
ID0gcmVxLT51LnJ3LmlkOwotCXBlbmRpbmdfcmVxLT5vcGVyYXRpb24gPSByZXEtPm9wZXJhdGlv
bjsKIAlwZW5kaW5nX3JlcS0+c3RhdHVzICAgID0gQkxLSUZfUlNQX09LQVk7CiAJcGVuZGluZ19y
ZXEtPm5yX3BhZ2VzICA9IG5zZWc7CiAKLQlmb3IgKGkgPSAwOyBpIDwgbnNlZzsgaSsrKSB7Ci0J
CXNlZ1tpXS5uc2VjID0gcmVxLT51LnJ3LnNlZ1tpXS5sYXN0X3NlY3QgLQotCQkJcmVxLT51LnJ3
LnNlZ1tpXS5maXJzdF9zZWN0ICsgMTsKLQkJaWYgKChyZXEtPnUucncuc2VnW2ldLmxhc3Rfc2Vj
dCA+PSAoUEFHRV9TSVpFID4+IDkpKSB8fAotCQkgICAgKHJlcS0+dS5ydy5zZWdbaV0ubGFzdF9z
ZWN0IDwgcmVxLT51LnJ3LnNlZ1tpXS5maXJzdF9zZWN0KSkKKwlpZiAocmVxLT5vcGVyYXRpb24g
IT0gQkxLSUZfT1BfSU5ESVJFQ1QpIHsKKwkJcHJlcS5kZXYgICAgICAgICAgICAgICA9IHJlcS0+
dS5ydy5oYW5kbGU7CisJCXByZXEuc2VjdG9yX251bWJlciAgICAgPSByZXEtPnUucncuc2VjdG9y
X251bWJlcjsKKwkJcGVuZGluZ19yZXEtPmlkICAgICAgICA9IHJlcS0+dS5ydy5pZDsKKwkJcGVu
ZGluZ19yZXEtPm9wZXJhdGlvbiA9IHJlcS0+b3BlcmF0aW9uOworCQlmb3IgKGkgPSAwOyBpIDwg
bnNlZzsgaSsrKSB7CisJCQlwZW5kaW5nX3JlcS0+Z3JlZnNbaV0gPSByZXEtPnUucncuc2VnW2ld
LmdyZWY7CisJCQlzZWdbaV0ubnNlYyA9IHJlcS0+dS5ydy5zZWdbaV0ubGFzdF9zZWN0IC0KKwkJ
CQlyZXEtPnUucncuc2VnW2ldLmZpcnN0X3NlY3QgKyAxOworCQkJc2VnW2ldLmJ1ZiA9IHJlcS0+
dS5ydy5zZWdbaV0uZmlyc3Rfc2VjdCA8PCA5OworCQkJaWYgKChyZXEtPnUucncuc2VnW2ldLmxh
c3Rfc2VjdCA+PSAoUEFHRV9TSVpFID4+IDkpKSB8fAorCQkgICAgCSAgICAocmVxLT51LnJ3LnNl
Z1tpXS5sYXN0X3NlY3QgPAorCQkgICAgCSAgICAgcmVxLT51LnJ3LnNlZ1tpXS5maXJzdF9zZWN0
KSkKKwkJCQlnb3RvIGZhaWxfcmVzcG9uc2U7CisJCQlwcmVxLm5yX3NlY3RzICs9IHNlZ1tpXS5u
c2VjOworCQl9CisJfSBlbHNlIHsKKwkJcHJlcS5kZXYgICAgICAgICAgICAgICA9IHJlcS0+dS5p
bmRpcmVjdC5oYW5kbGU7CisJCXByZXEuc2VjdG9yX251bWJlciAgICAgPSByZXEtPnUuaW5kaXJl
Y3Quc2VjdG9yX251bWJlcjsKKwkJcGVuZGluZ19yZXEtPmlkICAgICAgICA9IHJlcS0+dS5pbmRp
cmVjdC5pZDsKKwkJcGVuZGluZ19yZXEtPm9wZXJhdGlvbiA9IHJlcS0+dS5pbmRpcmVjdC5pbmRp
cmVjdF9vcDsKKwkJaWYgKHhlbl9ibGtia19wYXJzZV9pbmRpcmVjdChyZXEsIHBlbmRpbmdfcmVx
LCBzZWcsICZwcmVxKSkKIAkJCWdvdG8gZmFpbF9yZXNwb25zZTsKLQkJcHJlcS5ucl9zZWN0cyAr
PSBzZWdbaV0ubnNlYzsKLQogCX0KIAogCWlmICh4ZW5fdmJkX3RyYW5zbGF0ZSgmcHJlcSwgYmxr
aWYsIG9wZXJhdGlvbikgIT0gMCkgewpAQCAtMTA3NCw3ICsxMTM3LDcgQEAgc3RhdGljIGludCBk
aXNwYXRjaF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAkgKiB0aGUgaHlw
ZXJjYWxsIHRvIHVubWFwIHRoZSBncmFudHMgLSB0aGF0IGlzIGFsbCBkb25lIGluCiAJICogeGVu
X2Jsa2JrX3VubWFwLgogCSAqLwotCWlmICh4ZW5fYmxrYmtfbWFwX3NlZyhyZXEsIHBlbmRpbmdf
cmVxLCBzZWcsIHBhZ2VzKSkKKwlpZiAoeGVuX2Jsa2JrX21hcF9zZWcocGVuZGluZ19yZXEsIHNl
ZywgcGFnZXMpKQogCQlnb3RvIGZhaWxfZmx1c2g7CiAKIAkvKgpAQCAtMTE0Niw3ICsxMjA5LDcg
QEAgc3RhdGljIGludCBkaXNwYXRjaF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtp
ZiwKIAkgICAgICAgICAgICAgICAgcGVuZGluZ19yZXEtPm5yX3BhZ2VzKTsKICBmYWlsX3Jlc3Bv
bnNlOgogCS8qIEhhdmVuJ3Qgc3VibWl0dGVkIGFueSBiaW8ncyB5ZXQuICovCi0JbWFrZV9yZXNw
b25zZShibGtpZiwgcmVxLT51LnJ3LmlkLCByZXEtPm9wZXJhdGlvbiwgQkxLSUZfUlNQX0VSUk9S
KTsKKwltYWtlX3Jlc3BvbnNlKGJsa2lmLCByZXEtPnUucncuaWQsIHJlcV9vcGVyYXRpb24sIEJM
S0lGX1JTUF9FUlJPUik7CiAJZnJlZV9yZXEoYmxraWYsIHBlbmRpbmdfcmVxKTsKIAltc2xlZXAo
MSk7IC8qIGJhY2sgb2ZmIGEgYml0ICovCiAJcmV0dXJuIC1FSU87CmRpZmYgLS1naXQgYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oIGIvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFj
ay9jb21tb24uaAppbmRleCAwYjBhZDNmLi5kMzY1NmQyIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
Y29tbW9uLmgKQEAgLTUwLDYgKzUwLDE3IEBACiAJCSBfX2Z1bmNfXywgX19MSU5FX18sICMjYXJn
cykKIAogCisvKgorICogVGhpcyBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygc2VnbWVudHMgdGhh
dCB3b3VsZCBiZSBhbGxvd2VkIGluIGluZGlyZWN0CisgKiByZXF1ZXN0cy4gVGhpcyB2YWx1ZSB3
aWxsIGFsc28gYmUgcGFzc2VkIHRvIHRoZSBmcm9udGVuZC4KKyAqLworI2RlZmluZSBNQVhfSU5E
SVJFQ1RfU0VHTUVOVFMgMjU2CisKKyNkZWZpbmUgU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgXAor
KFBBR0VfU0laRS9zaXplb2Yoc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudF9hbGlnbmVkKSkK
KyNkZWZpbmUgTUFYX0lORElSRUNUX0dSRUZTIFwKKygoTUFYX0lORElSRUNUX1NFR01FTlRTICsg
U0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgLSAxKS9TRUdTX1BFUl9JTkRJUkVDVF9GUkFNRSkKKwog
LyogTm90IGEgcmVhbCBwcm90b2NvbC4gIFVzZWQgdG8gZ2VuZXJhdGUgcmluZyBzdHJ1Y3RzIHdo
aWNoIGNvbnRhaW4KICAqIHRoZSBlbGVtZW50cyBjb21tb24gdG8gYWxsIHByb3RvY29scyBvbmx5
LiAgVGhpcyB3YXkgd2UgZ2V0IGEKICAqIGNvbXBpbGVyLWNoZWNrYWJsZSB3YXkgdG8gdXNlIGNv
bW1vbiBzdHJ1Y3QgZWxlbWVudHMsIHNvIHdlIGNhbgpAQCAtNzcsMTEgKzg4LDIxIEBAIHN0cnVj
dCBibGtpZl94ODZfMzJfcmVxdWVzdF9kaXNjYXJkIHsKIAl1aW50NjRfdCAgICAgICBucl9zZWN0
b3JzOwogfSBfX2F0dHJpYnV0ZV9fKChfX3BhY2tlZF9fKSk7CiAKK3N0cnVjdCBibGtpZl94ODZf
MzJfcmVxdWVzdF9pbmRpcmVjdCB7CisJdWludDhfdCAgICAgICAgaW5kaXJlY3Rfb3A7CisJdWlu
dDE2X3QgICAgICAgbnJfc2VnbWVudHM7CisJdWludDY0X3QgICAgICAgaWQ7CisJYmxraWZfdmRl
dl90ICAgaGFuZGxlOworCWJsa2lmX3NlY3Rvcl90IHNlY3Rvcl9udW1iZXI7CisJZ3JhbnRfcmVm
X3QgICAgaW5kaXJlY3RfZ3JlZnNbQkxLSUZfTUFYX0lORElSRUNUX0dSRUZTX1BFUl9SRVFVRVNU
XTsKK30gX19hdHRyaWJ1dGVfXygoX19wYWNrZWRfXykpOworCiBzdHJ1Y3QgYmxraWZfeDg2XzMy
X3JlcXVlc3QgewogCXVpbnQ4X3QgICAgICAgIG9wZXJhdGlvbjsgICAgLyogQkxLSUZfT1BfPz8/
ICAgICAgICAgICAgICAgICAgICAgICAgICovCiAJdW5pb24gewogCQlzdHJ1Y3QgYmxraWZfeDg2
XzMyX3JlcXVlc3Rfcncgcnc7CiAJCXN0cnVjdCBibGtpZl94ODZfMzJfcmVxdWVzdF9kaXNjYXJk
IGRpc2NhcmQ7CisJCXN0cnVjdCBibGtpZl94ODZfMzJfcmVxdWVzdF9pbmRpcmVjdCBpbmRpcmVj
dDsKIAl9IHU7CiB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKIApAQCAtMTEzLDExICsx
MzQsMjIgQEAgc3RydWN0IGJsa2lmX3g4Nl82NF9yZXF1ZXN0X2Rpc2NhcmQgewogCXVpbnQ2NF90
ICAgICAgIG5yX3NlY3RvcnM7CiB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKIAorc3Ry
dWN0IGJsa2lmX3g4Nl82NF9yZXF1ZXN0X2luZGlyZWN0IHsKKwl1aW50OF90ICAgICAgICBpbmRp
cmVjdF9vcDsKKwl1aW50MTZfdCAgICAgICBucl9zZWdtZW50czsKKwl1aW50MzJfdCAgICAgICBf
cGFkMTsgICAgICAgIC8qIG9mZnNldG9mKGJsa2lmXy4uLHUuaW5kaXJlY3QuaWQpPT04ICAgKi8K
Kwl1aW50NjRfdCAgICAgICBpZDsKKwlibGtpZl92ZGV2X3QgICBoYW5kbGU7CisJYmxraWZfc2Vj
dG9yX3Qgc2VjdG9yX251bWJlcjsKKwlncmFudF9yZWZfdCAgICBpbmRpcmVjdF9ncmVmc1tCTEtJ
Rl9NQVhfSU5ESVJFQ1RfR1JFRlNfUEVSX1JFUVVFU1RdOworfSBfX2F0dHJpYnV0ZV9fKChfX3Bh
Y2tlZF9fKSk7CisKIHN0cnVjdCBibGtpZl94ODZfNjRfcmVxdWVzdCB7CiAJdWludDhfdCAgICAg
ICAgb3BlcmF0aW9uOyAgICAvKiBCTEtJRl9PUF8/Pz8gICAgICAgICAgICAgICAgICAgICAgICAg
Ki8KIAl1bmlvbiB7CiAJCXN0cnVjdCBibGtpZl94ODZfNjRfcmVxdWVzdF9ydyBydzsKIAkJc3Ry
dWN0IGJsa2lmX3g4Nl82NF9yZXF1ZXN0X2Rpc2NhcmQgZGlzY2FyZDsKKwkJc3RydWN0IGJsa2lm
X3g4Nl82NF9yZXF1ZXN0X2luZGlyZWN0IGluZGlyZWN0OwogCX0gdTsKIH0gX19hdHRyaWJ1dGVf
XygoX19wYWNrZWRfXykpOwogCkBAIC0yMzUsNiArMjY3LDExIEBAIHN0cnVjdCB4ZW5fYmxraWYg
ewogCXdhaXRfcXVldWVfaGVhZF90CXdhaXRpbmdfdG9fZnJlZTsKIH07CiAKK3N0cnVjdCBzZWdf
YnVmIHsKKwl1bnNpZ25lZCBsb25nIGJ1ZjsKKwl1bnNpZ25lZCBpbnQgbnNlYzsKK307CisKIC8q
CiAgKiBFYWNoIG91dHN0YW5kaW5nIHJlcXVlc3QgdGhhdCB3ZSd2ZSBwYXNzZWQgdG8gdGhlIGxv
d2VyIGRldmljZSBsYXllcnMgaGFzIGEKICAqICdwZW5kaW5nX3JlcScgYWxsb2NhdGVkIHRvIGl0
LiBFYWNoIGJ1ZmZlcl9oZWFkIHRoYXQgY29tcGxldGVzIGRlY3JlbWVudHMKQEAgLTI0OSw5ICsy
ODYsMTYgQEAgc3RydWN0IHBlbmRpbmdfcmVxIHsKIAl1bnNpZ25lZCBzaG9ydAkJb3BlcmF0aW9u
OwogCWludAkJCXN0YXR1czsKIAlzdHJ1Y3QgbGlzdF9oZWFkCWZyZWVfbGlzdDsKLQlzdHJ1Y3Qg
cGVyc2lzdGVudF9nbnQJKnBlcnNpc3RlbnRfZ250c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JF
UVVFU1RdOwotCXN0cnVjdCBwYWdlCQkqcGFnZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFV
RVNUXTsKLQlncmFudF9oYW5kbGVfdAkJZ3JhbnRfaGFuZGxlc1tCTEtJRl9NQVhfU0VHTUVOVFNf
UEVSX1JFUVVFU1RdOworCXN0cnVjdCBwZXJzaXN0ZW50X2dudAkqcGVyc2lzdGVudF9nbnRzW01B
WF9JTkRJUkVDVF9TRUdNRU5UU107CisJc3RydWN0IHBhZ2UJCSpwYWdlc1tNQVhfSU5ESVJFQ1Rf
U0VHTUVOVFNdOworCWdyYW50X2hhbmRsZV90CQlncmFudF9oYW5kbGVzW01BWF9JTkRJUkVDVF9T
RUdNRU5UU107CisJZ3JhbnRfcmVmX3QJCWdyZWZzW01BWF9JTkRJUkVDVF9TRUdNRU5UU107CisJ
LyogSW5kaXJlY3QgZGVzY3JpcHRvcnMgKi8KKwlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQJKmluZGly
ZWN0X3BlcnNpc3RlbnRfZ250c1tNQVhfSU5ESVJFQ1RfR1JFRlNdOworCXN0cnVjdCBwYWdlCQkq
aW5kaXJlY3RfcGFnZXNbTUFYX0lORElSRUNUX0dSRUZTXTsKKwlncmFudF9oYW5kbGVfdAkJaW5k
aXJlY3RfaGFuZGxlc1tNQVhfSU5ESVJFQ1RfR1JFRlNdOworCXN0cnVjdCBzZWdfYnVmCQlzZWdb
TUFYX0lORElSRUNUX1NFR01FTlRTXTsKKwlzdHJ1Y3QgYmlvCQkqYmlvbGlzdFtNQVhfSU5ESVJF
Q1RfU0VHTUVOVFNdOwogfTsKIAogCkBAIC0yODksNyArMzMzLDcgQEAgc3RydWN0IHhlbmJ1c19k
ZXZpY2UgKnhlbl9ibGtia194ZW5idXMoc3RydWN0IGJhY2tlbmRfaW5mbyAqYmUpOwogc3RhdGlj
IGlubGluZSB2b2lkIGJsa2lmX2dldF94ODZfMzJfcmVxKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpk
c3QsCiAJCQkJCXN0cnVjdCBibGtpZl94ODZfMzJfcmVxdWVzdCAqc3JjKQogewotCWludCBpLCBu
ID0gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOworCWludCBpLCBuID0gQkxLSUZfTUFY
X1NFR01FTlRTX1BFUl9SRVFVRVNULCBqID0gTUFYX0lORElSRUNUX0dSRUZTOwogCWRzdC0+b3Bl
cmF0aW9uID0gc3JjLT5vcGVyYXRpb247CiAJc3dpdGNoIChzcmMtPm9wZXJhdGlvbikgewogCWNh
c2UgQkxLSUZfT1BfUkVBRDoKQEAgLTMxMiw2ICszNTYsMTkgQEAgc3RhdGljIGlubGluZSB2b2lk
IGJsa2lmX2dldF94ODZfMzJfcmVxKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpkc3QsCiAJCWRzdC0+
dS5kaXNjYXJkLnNlY3Rvcl9udW1iZXIgPSBzcmMtPnUuZGlzY2FyZC5zZWN0b3JfbnVtYmVyOwog
CQlkc3QtPnUuZGlzY2FyZC5ucl9zZWN0b3JzID0gc3JjLT51LmRpc2NhcmQubnJfc2VjdG9yczsK
IAkJYnJlYWs7CisJY2FzZSBCTEtJRl9PUF9JTkRJUkVDVDoKKwkJZHN0LT51LmluZGlyZWN0Lmlu
ZGlyZWN0X29wID0gc3JjLT51LmluZGlyZWN0LmluZGlyZWN0X29wOworCQlkc3QtPnUuaW5kaXJl
Y3QubnJfc2VnbWVudHMgPSBzcmMtPnUuaW5kaXJlY3QubnJfc2VnbWVudHM7CisJCWRzdC0+dS5p
bmRpcmVjdC5oYW5kbGUgPSBzcmMtPnUuaW5kaXJlY3QuaGFuZGxlOworCQlkc3QtPnUuaW5kaXJl
Y3QuaWQgPSBzcmMtPnUuaW5kaXJlY3QuaWQ7CisJCWRzdC0+dS5pbmRpcmVjdC5zZWN0b3JfbnVt
YmVyID0gc3JjLT51LmluZGlyZWN0LnNlY3Rvcl9udW1iZXI7CisJCWJhcnJpZXIoKTsKKwkJaWYg
KGogPiBkc3QtPnUuaW5kaXJlY3QubnJfc2VnbWVudHMpCisJCQlqID0gZHN0LT51LmluZGlyZWN0
Lm5yX3NlZ21lbnRzOworCQlmb3IgKGkgPSAwOyBpIDwgajsgaSsrKQorCQkJZHN0LT51LmluZGly
ZWN0LmluZGlyZWN0X2dyZWZzW2ldID0KKwkJCQlzcmMtPnUuaW5kaXJlY3QuaW5kaXJlY3RfZ3Jl
ZnNbaV07CisJCWJyZWFrOwogCWRlZmF1bHQ6CiAJCWJyZWFrOwogCX0KQEAgLTMyMCw3ICszNzcs
NyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgYmxraWZfZ2V0X3g4Nl8zMl9yZXEoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKmRzdCwKIHN0YXRpYyBpbmxpbmUgdm9pZCBibGtpZl9nZXRfeDg2XzY0X3JlcShz
dHJ1Y3QgYmxraWZfcmVxdWVzdCAqZHN0LAogCQkJCQlzdHJ1Y3QgYmxraWZfeDg2XzY0X3JlcXVl
c3QgKnNyYykKIHsKLQlpbnQgaSwgbiA9IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVDsK
KwlpbnQgaSwgbiA9IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCwgaiA9IE1BWF9JTkRJ
UkVDVF9HUkVGUzsKIAlkc3QtPm9wZXJhdGlvbiA9IHNyYy0+b3BlcmF0aW9uOwogCXN3aXRjaCAo
c3JjLT5vcGVyYXRpb24pIHsKIAljYXNlIEJMS0lGX09QX1JFQUQ6CkBAIC0zNDMsNiArNDAwLDE5
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBibGtpZl9nZXRfeDg2XzY0X3JlcShzdHJ1Y3QgYmxraWZf
cmVxdWVzdCAqZHN0LAogCQlkc3QtPnUuZGlzY2FyZC5zZWN0b3JfbnVtYmVyID0gc3JjLT51LmRp
c2NhcmQuc2VjdG9yX251bWJlcjsKIAkJZHN0LT51LmRpc2NhcmQubnJfc2VjdG9ycyA9IHNyYy0+
dS5kaXNjYXJkLm5yX3NlY3RvcnM7CiAJCWJyZWFrOworCWNhc2UgQkxLSUZfT1BfSU5ESVJFQ1Q6
CisJCWRzdC0+dS5pbmRpcmVjdC5pbmRpcmVjdF9vcCA9IHNyYy0+dS5pbmRpcmVjdC5pbmRpcmVj
dF9vcDsKKwkJZHN0LT51LmluZGlyZWN0Lm5yX3NlZ21lbnRzID0gc3JjLT51LmluZGlyZWN0Lm5y
X3NlZ21lbnRzOworCQlkc3QtPnUuaW5kaXJlY3QuaGFuZGxlID0gc3JjLT51LmluZGlyZWN0Lmhh
bmRsZTsKKwkJZHN0LT51LmluZGlyZWN0LmlkID0gc3JjLT51LmluZGlyZWN0LmlkOworCQlkc3Qt
PnUuaW5kaXJlY3Quc2VjdG9yX251bWJlciA9IHNyYy0+dS5pbmRpcmVjdC5zZWN0b3JfbnVtYmVy
OworCQliYXJyaWVyKCk7CisJCWlmIChqID4gZHN0LT51LmluZGlyZWN0Lm5yX3NlZ21lbnRzKQor
CQkJaiA9IGRzdC0+dS5pbmRpcmVjdC5ucl9zZWdtZW50czsKKwkJZm9yIChpID0gMDsgaSA8IGo7
IGkrKykKKwkJCWRzdC0+dS5pbmRpcmVjdC5pbmRpcmVjdF9ncmVmc1tpXSA9CisJCQkJc3JjLT51
LmluZGlyZWN0LmluZGlyZWN0X2dyZWZzW2ldOworCQlicmVhazsKIAlkZWZhdWx0OgogCQlicmVh
azsKIAl9CmRpZmYgLS1naXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jIGIv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYwppbmRleCA4ZjkyOWNiLi45ZTE2YWJi
IDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCisrKyBiL2Ry
aXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKQEAgLTcwMCw2ICs3MDAsMTQgQEAgYWdh
aW46CiAJCWdvdG8gYWJvcnQ7CiAJfQogCisJZXJyID0geGVuYnVzX3ByaW50Zih4YnQsIGRldi0+
bm9kZW5hbWUsICJtYXgtaW5kaXJlY3Qtc2VnbWVudHMiLCAiJXUiLAorCSAgICAgICAgICAgICAg
ICAgICAgTUFYX0lORElSRUNUX1NFR01FTlRTKTsKKwlpZiAoZXJyKSB7CisJCXhlbmJ1c19kZXZf
ZmF0YWwoZGV2LCBlcnIsICJ3cml0aW5nICVzL21heC1pbmRpcmVjdC1zZWdtZW50cyIsCisJCQkJ
IGRldi0+bm9kZW5hbWUpOworCQlnb3RvIGFib3J0OworCX0KKwogCWVyciA9IHhlbmJ1c19wcmlu
dGYoeGJ0LCBkZXYtPm5vZGVuYW1lLCAic2VjdG9ycyIsICIlbGx1IiwKIAkJCSAgICAodW5zaWdu
ZWQgbG9uZyBsb25nKXZiZF9zeigmYmUtPmJsa2lmLT52YmQpKTsKIAlpZiAoZXJyKSB7CmRpZmYg
LS1naXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9jay94ZW4t
YmxrZnJvbnQuYwppbmRleCA0ZDgxZmNjLi4wNzRkMzAyIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtmcm9udC5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKQEAg
LTc0LDEyICs3NCwzMCBAQCBzdHJ1Y3QgZ3JhbnQgewogc3RydWN0IGJsa19zaGFkb3cgewogCXN0
cnVjdCBibGtpZl9yZXF1ZXN0IHJlcTsKIAlzdHJ1Y3QgcmVxdWVzdCAqcmVxdWVzdDsKLQlzdHJ1
Y3QgZ3JhbnQgKmdyYW50c191c2VkW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CisJ
c3RydWN0IGdyYW50ICoqZ3JhbnRzX3VzZWQ7CisJc3RydWN0IGdyYW50ICoqaW5kaXJlY3RfZ3Jh
bnRzOworfTsKKworc3RydWN0IHNwbGl0X2JpbyB7CisJc3RydWN0IGJpbyAqYmlvOworCWF0b21p
Y190IHBlbmRpbmc7CisJaW50IGVycjsKIH07CiAKIHN0YXRpYyBERUZJTkVfTVVURVgoYmxrZnJv
bnRfbXV0ZXgpOwogc3RhdGljIGNvbnN0IHN0cnVjdCBibG9ja19kZXZpY2Vfb3BlcmF0aW9ucyB4
bHZiZF9ibG9ja19mb3BzOwogCisvKgorICogTWF4aW11bSBudW1iZXIgb2Ygc2VnbWVudHMgaW4g
aW5kaXJlY3QgcmVxdWVzdHMsIHRoZSBhY3R1YWwgdmFsdWUgdXNlZCBieQorICogdGhlIGZyb250
ZW5kIGRyaXZlciBpcyB0aGUgbWluaW11bSBvZiB0aGlzIHZhbHVlIGFuZCB0aGUgdmFsdWUgcHJv
dmlkZWQKKyAqIGJ5IHRoZSBiYWNrZW5kIGRyaXZlci4KKyAqLworCitzdGF0aWMgaW50IHhlbl9i
bGtpZl9tYXhfc2VnbWVudHMgPSA2NDsKK21vZHVsZV9wYXJhbV9uYW1lZChtYXhfc2VnbWVudHMs
IHhlbl9ibGtpZl9tYXhfc2VnbWVudHMsIGludCwgMCk7CitNT0RVTEVfUEFSTV9ERVNDKG1heF9z
ZWdtZW50cywKKyJNYXhpbXVtIG51bWJlciBvZiBzZWdtZW50cyBpbiBpbmRpcmVjdCByZXF1ZXN0
cyIpOworCiAjZGVmaW5lIEJMS19SSU5HX1NJWkUgX19DT05TVF9SSU5HX1NJWkUoYmxraWYsIFBB
R0VfU0laRSkKIAogLyoKQEAgLTk4LDcgKzExNiw3IEBAIHN0cnVjdCBibGtmcm9udF9pbmZvCiAJ
ZW51bSBibGtpZl9zdGF0ZSBjb25uZWN0ZWQ7CiAJaW50IHJpbmdfcmVmOwogCXN0cnVjdCBibGtp
Zl9mcm9udF9yaW5nIHJpbmc7Ci0Jc3RydWN0IHNjYXR0ZXJsaXN0IHNnW0JMS0lGX01BWF9TRUdN
RU5UU19QRVJfUkVRVUVTVF07CisJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsKIAl1bnNpZ25lZCBp
bnQgZXZ0Y2huLCBpcnE7CiAJc3RydWN0IHJlcXVlc3RfcXVldWUgKnJxOwogCXN0cnVjdCB3b3Jr
X3N0cnVjdCB3b3JrOwpAQCAtMTE0LDYgKzEzMiw4IEBAIHN0cnVjdCBibGtmcm9udF9pbmZvCiAJ
dW5zaWduZWQgaW50IGRpc2NhcmRfZ3JhbnVsYXJpdHk7CiAJdW5zaWduZWQgaW50IGRpc2NhcmRf
YWxpZ25tZW50OwogCXVuc2lnbmVkIGludCBmZWF0dXJlX3BlcnNpc3RlbnQ6MTsKKwl1bnNpZ25l
ZCBpbnQgbWF4X2luZGlyZWN0X3NlZ21lbnRzOworCXVuc2lnbmVkIGludCBzZWN0b3Jfc2l6ZTsK
IAlpbnQgaXNfcmVhZHk7CiB9OwogCkBAIC0xNDIsNiArMTYyLDE0IEBAIHN0YXRpYyBERUZJTkVf
U1BJTkxPQ0sobWlub3JfbG9jayk7CiAKICNkZWZpbmUgREVWX05BTUUJInh2ZCIJLyogbmFtZSBp
biAvZGV2ICovCiAKKyNkZWZpbmUgU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgXAorCShQQUdFX1NJ
WkUvc2l6ZW9mKHN0cnVjdCBibGtpZl9yZXF1ZXN0X3NlZ21lbnRfYWxpZ25lZCkpCisjZGVmaW5l
IElORElSRUNUX0dSRUZTKF9zZWdzKSBcCisJKChfc2VncyArIFNFR1NfUEVSX0lORElSRUNUX0ZS
QU1FIC0gMSkvU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUpCisjZGVmaW5lIE1JTihfYSwgX2IpICgo
X2EpIDwgKF9iKSA/IChfYSkgOiAoX2IpKQorCitzdGF0aWMgaW50IGJsa2Zyb250X3NldHVwX2lu
ZGlyZWN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKTsKKwogc3RhdGljIGludCBnZXRfaWRf
ZnJvbV9mcmVlbGlzdChzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbykKIHsKIAl1bnNpZ25lZCBs
b25nIGZyZWUgPSBpbmZvLT5zaGFkb3dfZnJlZTsKQEAgLTM1OCw3ICszODYsOCBAQCBzdGF0aWMg
aW50IGJsa2lmX3F1ZXVlX3JlcXVlc3Qoc3RydWN0IHJlcXVlc3QgKnJlcSkKIAlzdHJ1Y3QgYmxr
aWZfcmVxdWVzdCAqcmluZ19yZXE7CiAJdW5zaWduZWQgbG9uZyBpZDsKIAl1bnNpZ25lZCBpbnQg
ZnNlY3QsIGxzZWN0OwotCWludCBpLCByZWY7CisJaW50IGksIHJlZiwgbjsKKwlzdHJ1Y3QgYmxr
aWZfcmVxdWVzdF9zZWdtZW50X2FsaWduZWQgKnNlZ21lbnRzID0gTlVMTDsKIAogCS8qCiAJICog
VXNlZCB0byBzdG9yZSBpZiB3ZSBhcmUgYWJsZSB0byBxdWV1ZSB0aGUgcmVxdWVzdCBieSBqdXN0
IHVzaW5nCkBAIC0zNjksMjEgKzM5OCwyNyBAQCBzdGF0aWMgaW50IGJsa2lmX3F1ZXVlX3JlcXVl
c3Qoc3RydWN0IHJlcXVlc3QgKnJlcSkKIAlncmFudF9yZWZfdCBncmVmX2hlYWQ7CiAJc3RydWN0
IGdyYW50ICpnbnRfbGlzdF9lbnRyeSA9IE5VTEw7CiAJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsK
KwlpbnQgbnNlZywgbWF4X2dyZWZzOwogCiAJaWYgKHVubGlrZWx5KGluZm8tPmNvbm5lY3RlZCAh
PSBCTEtJRl9TVEFURV9DT05ORUNURUQpKQogCQlyZXR1cm4gMTsKIAotCS8qIENoZWNrIGlmIHdl
IGhhdmUgZW5vdWdodCBncmFudHMgdG8gYWxsb2NhdGUgYSByZXF1ZXN0cyAqLwotCWlmIChpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYyA8IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCkgewor
CW1heF9ncmVmcyA9IGluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyA/CisJICAgICAgICAgICAg
aW5mby0+bWF4X2luZGlyZWN0X3NlZ21lbnRzICsKKwkgICAgICAgICAgICBJTkRJUkVDVF9HUkVG
UyhpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMpIDoKKwkgICAgICAgICAgICBCTEtJRl9NQVhf
U0VHTUVOVFNfUEVSX1JFUVVFU1Q7CisKKwkvKiBDaGVjayBpZiB3ZSBoYXZlIGVub3VnaCBncmFu
dHMgdG8gYWxsb2NhdGUgYSByZXF1ZXN0cyAqLworCWlmIChpbmZvLT5wZXJzaXN0ZW50X2dudHNf
YyA8IG1heF9ncmVmcykgewogCQluZXdfcGVyc2lzdGVudF9nbnRzID0gMTsKIAkJaWYgKGdudHRh
Yl9hbGxvY19ncmFudF9yZWZlcmVuY2VzKAotCQkgICAgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUIC0gaW5mby0+cGVyc2lzdGVudF9nbnRzX2MsCisJCSAgICBtYXhfZ3JlZnMgLSBpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYywKIAkJICAgICZncmVmX2hlYWQpIDwgMCkgewogCQkJZ250dGFi
X3JlcXVlc3RfZnJlZV9jYWxsYmFjaygKIAkJCQkmaW5mby0+Y2FsbGJhY2ssCiAJCQkJYmxraWZf
cmVzdGFydF9xdWV1ZV9jYWxsYmFjaywKIAkJCQlpbmZvLAotCQkJCUJMS0lGX01BWF9TRUdNRU5U
U19QRVJfUkVRVUVTVCk7CisJCQkJbWF4X2dyZWZzKTsKIAkJCXJldHVybiAxOwogCQl9CiAJfSBl
bHNlCkBAIC0zOTQsNDIgKzQyOSw4MiBAQCBzdGF0aWMgaW50IGJsa2lmX3F1ZXVlX3JlcXVlc3Qo
c3RydWN0IHJlcXVlc3QgKnJlcSkKIAlpZCA9IGdldF9pZF9mcm9tX2ZyZWVsaXN0KGluZm8pOwog
CWluZm8tPnNoYWRvd1tpZF0ucmVxdWVzdCA9IHJlcTsKIAotCXJpbmdfcmVxLT51LnJ3LmlkID0g
aWQ7Ci0JcmluZ19yZXEtPnUucncuc2VjdG9yX251bWJlciA9IChibGtpZl9zZWN0b3JfdClibGtf
cnFfcG9zKHJlcSk7Ci0JcmluZ19yZXEtPnUucncuaGFuZGxlID0gaW5mby0+aGFuZGxlOwotCi0J
cmluZ19yZXEtPm9wZXJhdGlvbiA9IHJxX2RhdGFfZGlyKHJlcSkgPwotCQlCTEtJRl9PUF9XUklU
RSA6IEJMS0lGX09QX1JFQUQ7Ci0KLQlpZiAocmVxLT5jbWRfZmxhZ3MgJiAoUkVRX0ZMVVNIIHwg
UkVRX0ZVQSkpIHsKLQkJLyoKLQkJICogSWRlYWxseSB3ZSBjYW4gZG8gYW4gdW5vcmRlcmVkIGZs
dXNoLXRvLWRpc2suIEluIGNhc2UgdGhlCi0JCSAqIGJhY2tlbmQgb25seXN1cHBvcnRzIGJhcnJp
ZXJzLCB1c2UgdGhhdC4gQSBiYXJyaWVyIHJlcXVlc3QKLQkJICogYSBzdXBlcnNldCBvZiBGVUEs
IHNvIHdlIGNhbiBpbXBsZW1lbnQgaXQgdGhlIHNhbWUKLQkJICogd2F5LiAgKEl0J3MgYWxzbyBh
IEZMVVNIK0ZVQSwgc2luY2UgaXQgaXMKLQkJICogZ3VhcmFudGVlZCBvcmRlcmVkIFdSVCBwcmV2
aW91cyB3cml0ZXMuKQotCQkgKi8KLQkJcmluZ19yZXEtPm9wZXJhdGlvbiA9IGluZm8tPmZsdXNo
X29wOwotCX0KLQogCWlmICh1bmxpa2VseShyZXEtPmNtZF9mbGFncyAmIChSRVFfRElTQ0FSRCB8
IFJFUV9TRUNVUkUpKSkgewogCQkvKiBpZCwgc2VjdG9yX251bWJlciBhbmQgaGFuZGxlIGFyZSBz
ZXQgYWJvdmUuICovCiAJCXJpbmdfcmVxLT5vcGVyYXRpb24gPSBCTEtJRl9PUF9ESVNDQVJEOwog
CQlyaW5nX3JlcS0+dS5kaXNjYXJkLm5yX3NlY3RvcnMgPSBibGtfcnFfc2VjdG9ycyhyZXEpOwor
CQlyaW5nX3JlcS0+dS5kaXNjYXJkLmlkID0gaWQ7CisJCXJpbmdfcmVxLT51LmRpc2NhcmQuc2Vj
dG9yX251bWJlciA9CisJCQkoYmxraWZfc2VjdG9yX3QpYmxrX3JxX3BvcyhyZXEpOwogCQlpZiAo
KHJlcS0+Y21kX2ZsYWdzICYgUkVRX1NFQ1VSRSkgJiYgaW5mby0+ZmVhdHVyZV9zZWNkaXNjYXJk
KQogCQkJcmluZ19yZXEtPnUuZGlzY2FyZC5mbGFnID0gQkxLSUZfRElTQ0FSRF9TRUNVUkU7CiAJ
CWVsc2UKIAkJCXJpbmdfcmVxLT51LmRpc2NhcmQuZmxhZyA9IDA7CiAJfSBlbHNlIHsKLQkJcmlu
Z19yZXEtPnUucncubnJfc2VnbWVudHMgPSBibGtfcnFfbWFwX3NnKHJlcS0+cSwgcmVxLAotCQkJ
CQkJCSAgIGluZm8tPnNnKTsKLQkJQlVHX09OKHJpbmdfcmVxLT51LnJ3Lm5yX3NlZ21lbnRzID4K
LQkJICAgICAgIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCk7Ci0KLQkJZm9yX2VhY2hf
c2coaW5mby0+c2csIHNnLCByaW5nX3JlcS0+dS5ydy5ucl9zZWdtZW50cywgaSkgeworCQlCVUdf
T04oaW5mby0+bWF4X2luZGlyZWN0X3NlZ21lbnRzID09IDAgJiYKKwkJICAgICAgIHJlcS0+bnJf
cGh5c19zZWdtZW50cyA+IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCk7CisJCUJVR19P
TihpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMgJiYKKwkJICAgICAgIHJlcS0+bnJfcGh5c19z
ZWdtZW50cyA+IGluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyk7CisJCW5zZWcgPSBibGtfcnFf
bWFwX3NnKHJlcS0+cSwgcmVxLCBpbmZvLT5zZyk7CisJCWlmIChuc2VnID4gQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUKSB7CisJCQkvKiBJbmRpcmVjdCBPUCAqLworCQkJcmluZ19yZXEt
Pm9wZXJhdGlvbiA9IEJMS0lGX09QX0lORElSRUNUOworCQkJcmluZ19yZXEtPnUuaW5kaXJlY3Qu
aW5kaXJlY3Rfb3AgPSBycV9kYXRhX2RpcihyZXEpID8KKwkJCQlCTEtJRl9PUF9XUklURSA6IEJM
S0lGX09QX1JFQUQ7CisJCQlyaW5nX3JlcS0+dS5pbmRpcmVjdC5pZCA9IGlkOworCQkJcmluZ19y
ZXEtPnUuaW5kaXJlY3Quc2VjdG9yX251bWJlciA9CisJCQkJKGJsa2lmX3NlY3Rvcl90KWJsa19y
cV9wb3MocmVxKTsKKwkJCXJpbmdfcmVxLT51LmluZGlyZWN0LmhhbmRsZSA9IGluZm8tPmhhbmRs
ZTsKKwkJCWlmIChyZXEtPmNtZF9mbGFncyAmIChSRVFfRkxVU0ggfCBSRVFfRlVBKSkgeworCQkv
KgorCQkgKiBJZGVhbGx5IHdlIGNhbiBkbyBhbiB1bm9yZGVyZWQgZmx1c2gtdG8tZGlzay4gSW4g
Y2FzZSB0aGUKKwkJICogYmFja2VuZCBvbmx5c3VwcG9ydHMgYmFycmllcnMsIHVzZSB0aGF0LiBB
IGJhcnJpZXIgcmVxdWVzdAorCQkgKiBhIHN1cGVyc2V0IG9mIEZVQSwgc28gd2UgY2FuIGltcGxl
bWVudCBpdCB0aGUgc2FtZQorCQkgKiB3YXkuICAoSXQncyBhbHNvIGEgRkxVU0grRlVBLCBzaW5j
ZSBpdCBpcworCQkgKiBndWFyYW50ZWVkIG9yZGVyZWQgV1JUIHByZXZpb3VzIHdyaXRlcy4pCisJ
CSAqLworCQkJCXJpbmdfcmVxLT51LmluZGlyZWN0LmluZGlyZWN0X29wID0KKwkJCQkJaW5mby0+
Zmx1c2hfb3A7CisJCQl9CisJCQlyaW5nX3JlcS0+dS5pbmRpcmVjdC5ucl9zZWdtZW50cyA9IG5z
ZWc7CisJCX0gZWxzZSB7CisJCQlyaW5nX3JlcS0+dS5ydy5pZCA9IGlkOworCQkJcmluZ19yZXEt
PnUucncuc2VjdG9yX251bWJlciA9CisJCQkJKGJsa2lmX3NlY3Rvcl90KWJsa19ycV9wb3MocmVx
KTsKKwkJCXJpbmdfcmVxLT51LnJ3LmhhbmRsZSA9IGluZm8tPmhhbmRsZTsKKwkJCXJpbmdfcmVx
LT5vcGVyYXRpb24gPSBycV9kYXRhX2RpcihyZXEpID8KKwkJCQlCTEtJRl9PUF9XUklURSA6IEJM
S0lGX09QX1JFQUQ7CisJCQlpZiAocmVxLT5jbWRfZmxhZ3MgJiAoUkVRX0ZMVVNIIHwgUkVRX0ZV
QSkpIHsKKwkJLyoKKwkJICogSWRlYWxseSB3ZSBjYW4gZG8gYW4gdW5vcmRlcmVkIGZsdXNoLXRv
LWRpc2suIEluIGNhc2UgdGhlCisJCSAqIGJhY2tlbmQgb25seXN1cHBvcnRzIGJhcnJpZXJzLCB1
c2UgdGhhdC4gQSBiYXJyaWVyIHJlcXVlc3QKKwkJICogYSBzdXBlcnNldCBvZiBGVUEsIHNvIHdl
IGNhbiBpbXBsZW1lbnQgaXQgdGhlIHNhbWUKKwkJICogd2F5LiAgKEl0J3MgYWxzbyBhIEZMVVNI
K0ZVQSwgc2luY2UgaXQgaXMKKwkJICogZ3VhcmFudGVlZCBvcmRlcmVkIFdSVCBwcmV2aW91cyB3
cml0ZXMuKQorCQkgKi8KKwkJCQlyaW5nX3JlcS0+b3BlcmF0aW9uID0gaW5mby0+Zmx1c2hfb3A7
CisJCQl9CisJCQlyaW5nX3JlcS0+dS5ydy5ucl9zZWdtZW50cyA9IG5zZWc7CisJCX0KKwkJZm9y
X2VhY2hfc2coaW5mby0+c2csIHNnLCBuc2VnLCBpKSB7CiAJCQlmc2VjdCA9IHNnLT5vZmZzZXQg
Pj4gOTsKIAkJCWxzZWN0ID0gZnNlY3QgKyAoc2ctPmxlbmd0aCA+PiA5KSAtIDE7CiAKKwkJCWlm
ICgocmluZ19yZXEtPm9wZXJhdGlvbiA9PSBCTEtJRl9PUF9JTkRJUkVDVCkgJiYKKwkJCSAgICAo
aSAlIFNFR1NfUEVSX0lORElSRUNUX0ZSQU1FID09IDApKSB7CisJCQkJaWYgKHNlZ21lbnRzKQor
CQkJCQlrdW5tYXBfYXRvbWljKHNlZ21lbnRzKTsKKworCQkJCW4gPSBpIC8gU0VHU19QRVJfSU5E
SVJFQ1RfRlJBTUU7CisJCQkJZ250X2xpc3RfZW50cnkgPSBnZXRfZ3JhbnQoJmdyZWZfaGVhZCwg
aW5mbyk7CisJCQkJaW5mby0+c2hhZG93W2lkXS5pbmRpcmVjdF9ncmFudHNbbl0gPQorCQkJCQln
bnRfbGlzdF9lbnRyeTsKKwkJCQlzZWdtZW50cyA9IGttYXBfYXRvbWljKAorCQkJCQlwZm5fdG9f
cGFnZShnbnRfbGlzdF9lbnRyeS0+cGZuKSk7CisJCQkJcmluZ19yZXEtPnUuaW5kaXJlY3QuaW5k
aXJlY3RfZ3JlZnNbbl0gPQorCQkJCQlnbnRfbGlzdF9lbnRyeS0+Z3JlZjsKKwkJCX0KKwogCQkJ
Z250X2xpc3RfZW50cnkgPSBnZXRfZ3JhbnQoJmdyZWZfaGVhZCwgaW5mbyk7CiAJCQlyZWYgPSBn
bnRfbGlzdF9lbnRyeS0+Z3JlZjsKIApAQCAtNDYxLDEzICs1MzYsMjMgQEAgc3RhdGljIGludCBi
bGtpZl9xdWV1ZV9yZXF1ZXN0KHN0cnVjdCByZXF1ZXN0ICpyZXEpCiAJCQkJa3VubWFwX2F0b21p
YyhidmVjX2RhdGEpOwogCQkJCWt1bm1hcF9hdG9taWMoc2hhcmVkX2RhdGEpOwogCQkJfQotCi0J
CQlyaW5nX3JlcS0+dS5ydy5zZWdbaV0gPQotCQkJCQkoc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2Vn
bWVudCkgewotCQkJCQkJLmdyZWYgICAgICAgPSByZWYsCi0JCQkJCQkuZmlyc3Rfc2VjdCA9IGZz
ZWN0LAotCQkJCQkJLmxhc3Rfc2VjdCAgPSBsc2VjdCB9OworCQkJaWYgKHJpbmdfcmVxLT5vcGVy
YXRpb24gIT0gQkxLSUZfT1BfSU5ESVJFQ1QpIHsKKwkJCQlyaW5nX3JlcS0+dS5ydy5zZWdbaV0g
PQorCQkJCQkJKHN0cnVjdCBibGtpZl9yZXF1ZXN0X3NlZ21lbnQpIHsKKwkJCQkJCQkuZ3JlZiAg
ICAgICA9IHJlZiwKKwkJCQkJCQkuZmlyc3Rfc2VjdCA9IGZzZWN0LAorCQkJCQkJCS5sYXN0X3Nl
Y3QgID0gbHNlY3QgfTsKKwkJCX0gZWxzZSB7CisJCQkJbiA9IGkgJSBTRUdTX1BFUl9JTkRJUkVD
VF9GUkFNRTsKKwkJCQlzZWdtZW50c1tuXSA9CisJCQkJCShzdHJ1Y3QgYmxraWZfcmVxdWVzdF9z
ZWdtZW50X2FsaWduZWQpIHsKKwkJCQkJCQkuZ3JlZiAgICAgICA9IHJlZiwKKwkJCQkJCQkuZmly
c3Rfc2VjdCA9IGZzZWN0LAorCQkJCQkJCS5sYXN0X3NlY3QgID0gbHNlY3QgfTsKKwkJCX0KIAkJ
fQorCQlpZiAoc2VnbWVudHMpCisJCQlrdW5tYXBfYXRvbWljKHNlZ21lbnRzKTsKIAl9CiAKIAlp
bmZvLT5yaW5nLnJlcV9wcm9kX3B2dCsrOwpAQCAtNTQyLDcgKzYyNyw4IEBAIHdhaXQ6CiAJCWZs
dXNoX3JlcXVlc3RzKGluZm8pOwogfQogCi1zdGF0aWMgaW50IHhsdmJkX2luaXRfYmxrX3F1ZXVl
KHN0cnVjdCBnZW5kaXNrICpnZCwgdTE2IHNlY3Rvcl9zaXplKQorc3RhdGljIGludCB4bHZiZF9p
bml0X2Jsa19xdWV1ZShzdHJ1Y3QgZ2VuZGlzayAqZ2QsIHUxNiBzZWN0b3Jfc2l6ZSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHNlZ21lbnRzKQogewogCXN0
cnVjdCByZXF1ZXN0X3F1ZXVlICpycTsKIAlzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbyA9IGdk
LT5wcml2YXRlX2RhdGE7CkBAIC01NzEsNyArNjU3LDcgQEAgc3RhdGljIGludCB4bHZiZF9pbml0
X2Jsa19xdWV1ZShzdHJ1Y3QgZ2VuZGlzayAqZ2QsIHUxNiBzZWN0b3Jfc2l6ZSkKIAlibGtfcXVl
dWVfbWF4X3NlZ21lbnRfc2l6ZShycSwgUEFHRV9TSVpFKTsKIAogCS8qIEVuc3VyZSBhIG1lcmdl
ZCByZXF1ZXN0IHdpbGwgZml0IGluIGEgc2luZ2xlIEkvTyByaW5nIHNsb3QuICovCi0JYmxrX3F1
ZXVlX21heF9zZWdtZW50cyhycSwgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUKTsKKwli
bGtfcXVldWVfbWF4X3NlZ21lbnRzKHJxLCBzZWdtZW50cyk7CiAKIAkvKiBNYWtlIHN1cmUgYnVm
ZmVyIGFkZHJlc3NlcyBhcmUgc2VjdG9yLWFsaWduZWQuICovCiAJYmxrX3F1ZXVlX2RtYV9hbGln
bm1lbnQocnEsIDUxMSk7CkBAIC01ODgsMTMgKzY3NCwxNCBAQCBzdGF0aWMgaW50IHhsdmJkX2lu
aXRfYmxrX3F1ZXVlKHN0cnVjdCBnZW5kaXNrICpnZCwgdTE2IHNlY3Rvcl9zaXplKQogc3RhdGlj
IHZvaWQgeGx2YmRfZmx1c2goc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiB7CiAJYmxrX3F1
ZXVlX2ZsdXNoKGluZm8tPnJxLCBpbmZvLT5mZWF0dXJlX2ZsdXNoKTsKLQlwcmludGsoS0VSTl9J
TkZPICJibGtmcm9udDogJXM6ICVzOiAlcyAlc1xuIiwKKwlwcmludGsoS0VSTl9JTkZPICJibGtm
cm9udDogJXM6ICVzOiAlcyAlcyAlc1xuIiwKIAkgICAgICAgaW5mby0+Z2QtPmRpc2tfbmFtZSwK
IAkgICAgICAgaW5mby0+Zmx1c2hfb3AgPT0gQkxLSUZfT1BfV1JJVEVfQkFSUklFUiA/CiAJCSJi
YXJyaWVyIiA6IChpbmZvLT5mbHVzaF9vcCA9PSBCTEtJRl9PUF9GTFVTSF9ESVNLQ0FDSEUgPwog
CQkiZmx1c2ggZGlza2NhY2hlIiA6ICJiYXJyaWVyIG9yIGZsdXNoIiksCiAJICAgICAgIGluZm8t
PmZlYXR1cmVfZmx1c2ggPyAiZW5hYmxlZCIgOiAiZGlzYWJsZWQiLAotCSAgICAgICBpbmZvLT5m
ZWF0dXJlX3BlcnNpc3RlbnQgPyAidXNpbmcgcGVyc2lzdGVudCBncmFudHMiIDogIiIpOworCSAg
ICAgICBpbmZvLT5mZWF0dXJlX3BlcnNpc3RlbnQgPyAidXNpbmcgcGVyc2lzdGVudCBncmFudHMi
IDogIiIsCisJICAgICAgIGluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyA/ICJ1c2luZyBpbmRp
cmVjdCBkZXNjcmlwdG9ycyIgOiAiIik7CiB9CiAKIHN0YXRpYyBpbnQgeGVuX3RyYW5zbGF0ZV92
ZGV2KGludCB2ZGV2aWNlLCBpbnQgKm1pbm9yLCB1bnNpZ25lZCBpbnQgKm9mZnNldCkKQEAgLTcz
NCw3ICs4MjEsOSBAQCBzdGF0aWMgaW50IHhsdmJkX2FsbG9jX2dlbmRpc2soYmxraWZfc2VjdG9y
X3QgY2FwYWNpdHksCiAJZ2QtPmRyaXZlcmZzX2RldiA9ICYoaW5mby0+eGJkZXYtPmRldik7CiAJ
c2V0X2NhcGFjaXR5KGdkLCBjYXBhY2l0eSk7CiAKLQlpZiAoeGx2YmRfaW5pdF9ibGtfcXVldWUo
Z2QsIHNlY3Rvcl9zaXplKSkgeworCWlmICh4bHZiZF9pbml0X2Jsa19xdWV1ZShnZCwgc2VjdG9y
X3NpemUsCisJICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8tPm1heF9pbmRpcmVjdF9zZWdt
ZW50cyA/IDoKKwkgICAgICAgICAgICAgICAgICAgICAgICAgQkxLSUZfTUFYX1NFR01FTlRTX1BF
Ul9SRVFVRVNUKSkgewogCQlkZWxfZ2VuZGlzayhnZCk7CiAJCWdvdG8gcmVsZWFzZTsKIAl9CkBA
IC04MTgsNiArOTA3LDcgQEAgc3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRf
aW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiB7CiAJc3RydWN0IGdyYW50ICpwZXJzaXN0ZW50X2du
dDsKIAlzdHJ1Y3QgZ3JhbnQgKm47CisJaW50IGksIGosIHNlZ3M7CiAKIAkvKiBQcmV2ZW50IG5l
dyByZXF1ZXN0cyBiZWluZyBpc3N1ZWQgdW50aWwgd2UgZml4IHRoaW5ncyB1cC4gKi8KIAlzcGlu
X2xvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKQEAgLTg0Myw2ICs5MzMsNDcgQEAgc3RhdGljIHZv
aWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiAJ
fQogCUJVR19PTihpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyAhPSAwKTsKIAorCWtmcmVlKGluZm8t
PnNnKTsKKwlpbmZvLT5zZyA9IE5VTEw7CisJZm9yIChpID0gMDsgaSA8IEJMS19SSU5HX1NJWkU7
IGkrKykgeworCQkvKgorCQkgKiBDbGVhciBwZXJzaXN0ZW50IGdyYW50cyBwcmVzZW50IGluIHJl
cXVlc3RzIGFscmVhZHkKKwkJICogb24gdGhlIHNoYXJlZCByaW5nCisJCSAqLworCQlpZiAoIWlu
Zm8tPnNoYWRvd1tpXS5yZXF1ZXN0KQorCQkJZ290byBmcmVlX3NoYWRvdzsKKworCQlzZWdzID0g
aW5mby0+c2hhZG93W2ldLnJlcS5vcGVyYXRpb24gPT0gQkxLSUZfT1BfSU5ESVJFQ1QgPworCQkg
ICAgICAgaW5mby0+c2hhZG93W2ldLnJlcS51LmluZGlyZWN0Lm5yX3NlZ21lbnRzIDoKKwkJICAg
ICAgIGluZm8tPnNoYWRvd1tpXS5yZXEudS5ydy5ucl9zZWdtZW50czsKKwkJZm9yIChqID0gMDsg
aiA8IHNlZ3M7IGorKykgeworCQkJcGVyc2lzdGVudF9nbnQgPSBpbmZvLT5zaGFkb3dbaV0uZ3Jh
bnRzX3VzZWRbal07CisJCQlnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzKHBlcnNpc3RlbnRfZ250
LT5ncmVmLCAwLCAwVUwpOworCQkJX19mcmVlX3BhZ2UocGZuX3RvX3BhZ2UocGVyc2lzdGVudF9n
bnQtPnBmbikpOworCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOworCQl9CisKKwkJaWYgKGluZm8t
PnNoYWRvd1tpXS5yZXEub3BlcmF0aW9uICE9IEJMS0lGX09QX0lORElSRUNUKQorCQkJLyoKKwkJ
CSAqIElmIHRoaXMgaXMgbm90IGFuIGluZGlyZWN0IG9wZXJhdGlvbiBkb24ndCB0cnkgdG8KKwkJ
CSAqIGZyZWUgaW5kaXJlY3Qgc2VnbWVudHMKKwkJCSAqLworCQkJZ290byBmcmVlX3NoYWRvdzsK
KworCQlmb3IgKGogPSAwOyBqIDwgSU5ESVJFQ1RfR1JFRlMoc2Vncyk7IGorKykgeworCQkJcGVy
c2lzdGVudF9nbnQgPSBpbmZvLT5zaGFkb3dbaV0uaW5kaXJlY3RfZ3JhbnRzW2pdOworCQkJZ250
dGFiX2VuZF9mb3JlaWduX2FjY2VzcyhwZXJzaXN0ZW50X2dudC0+Z3JlZiwgMCwgMFVMKTsKKwkJ
CV9fZnJlZV9wYWdlKHBmbl90b19wYWdlKHBlcnNpc3RlbnRfZ250LT5wZm4pKTsKKwkJCWtmcmVl
KHBlcnNpc3RlbnRfZ250KTsKKwkJfQorCitmcmVlX3NoYWRvdzoKKwkJa2ZyZWUoaW5mby0+c2hh
ZG93W2ldLmdyYW50c191c2VkKTsKKwkJaW5mby0+c2hhZG93W2ldLmdyYW50c191c2VkID0gTlVM
TDsKKwkJa2ZyZWUoaW5mby0+c2hhZG93W2ldLmluZGlyZWN0X2dyYW50cyk7CisJCWluZm8tPnNo
YWRvd1tpXS5pbmRpcmVjdF9ncmFudHMgPSBOVUxMOworCX0KKwogCS8qIE5vIG1vcmUgZ250dGFi
IGNhbGxiYWNrIHdvcmsuICovCiAJZ250dGFiX2NhbmNlbF9mcmVlX2NhbGxiYWNrKCZpbmZvLT5j
YWxsYmFjayk7CiAJc3Bpbl91bmxvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKQEAgLTg3Myw2ICsx
MDA0LDEwIEBAIHN0YXRpYyB2b2lkIGJsa2lmX2NvbXBsZXRpb24oc3RydWN0IGJsa19zaGFkb3cg
KnMsIHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvLAogCWNoYXIgKmJ2ZWNfZGF0YTsKIAl2b2lk
ICpzaGFyZWRfZGF0YTsKIAl1bnNpZ25lZCBpbnQgb2Zmc2V0ID0gMDsKKwlpbnQgbnNlZzsKKwor
CW5zZWcgPSBzLT5yZXEub3BlcmF0aW9uID09IEJMS0lGX09QX0lORElSRUNUID8KKwkJcy0+cmVx
LnUuaW5kaXJlY3QubnJfc2VnbWVudHMgOiBzLT5yZXEudS5ydy5ucl9zZWdtZW50czsKIAogCWlm
IChicmV0LT5vcGVyYXRpb24gPT0gQkxLSUZfT1BfUkVBRCkgewogCQkvKgpAQCAtODg1LDcgKzEw
MjAsNyBAQCBzdGF0aWMgdm9pZCBibGtpZl9jb21wbGV0aW9uKHN0cnVjdCBibGtfc2hhZG93ICpz
LCBzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywKIAkJCUJVR19PTigoYnZlYy0+YnZfb2Zmc2V0
ICsgYnZlYy0+YnZfbGVuKSA+IFBBR0VfU0laRSk7CiAJCQlpZiAoYnZlYy0+YnZfb2Zmc2V0IDwg
b2Zmc2V0KQogCQkJCWkrKzsKLQkJCUJVR19PTihpID49IHMtPnJlcS51LnJ3Lm5yX3NlZ21lbnRz
KTsKKwkJCUJVR19PTihpID49IG5zZWcpOwogCQkJc2hhcmVkX2RhdGEgPSBrbWFwX2F0b21pYygK
IAkJCQlwZm5fdG9fcGFnZShzLT5ncmFudHNfdXNlZFtpXS0+cGZuKSk7CiAJCQlidmVjX2RhdGEg
PSBidmVjX2ttYXBfaXJxKGJ2ZWMsICZmbGFncyk7CkBAIC04OTcsMTAgKzEwMzIsMTcgQEAgc3Rh
dGljIHZvaWQgYmxraWZfY29tcGxldGlvbihzdHJ1Y3QgYmxrX3NoYWRvdyAqcywgc3RydWN0IGJs
a2Zyb250X2luZm8gKmluZm8sCiAJCX0KIAl9CiAJLyogQWRkIHRoZSBwZXJzaXN0ZW50IGdyYW50
IGludG8gdGhlIGxpc3Qgb2YgZnJlZSBncmFudHMgKi8KLQlmb3IgKGkgPSAwOyBpIDwgcy0+cmVx
LnUucncubnJfc2VnbWVudHM7IGkrKykgeworCWZvciAoaSA9IDA7IGkgPCBuc2VnOyBpKyspIHsK
IAkJbGlzdF9hZGQoJnMtPmdyYW50c191c2VkW2ldLT5ub2RlLCAmaW5mby0+cGVyc2lzdGVudF9n
bnRzKTsKIAkJaW5mby0+cGVyc2lzdGVudF9nbnRzX2MrKzsKIAl9CisJaWYgKHMtPnJlcS5vcGVy
YXRpb24gPT0gQkxLSUZfT1BfSU5ESVJFQ1QpIHsKKwkJZm9yIChpID0gMDsgaSA8IElORElSRUNU
X0dSRUZTKG5zZWcpOyBpKyspIHsKKwkJCWxpc3RfYWRkKCZzLT5pbmRpcmVjdF9ncmFudHNbaV0t
Pm5vZGUsCisJCQkgICAgICAgICAmaW5mby0+cGVyc2lzdGVudF9nbnRzKTsKKwkJCWluZm8tPnBl
cnNpc3RlbnRfZ250c19jKys7CisJCX0KKwl9CiB9CiAKIHN0YXRpYyBpcnFyZXR1cm5fdCBibGtp
Zl9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQpAQCAtMTAzNCw4ICsxMTc2LDYgQEAg
c3RhdGljIGludCBzZXR1cF9ibGtyaW5nKHN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYsCiAJU0hB
UkVEX1JJTkdfSU5JVChzcmluZyk7CiAJRlJPTlRfUklOR19JTklUKCZpbmZvLT5yaW5nLCBzcmlu
ZywgUEFHRV9TSVpFKTsKIAotCXNnX2luaXRfdGFibGUoaW5mby0+c2csIEJMS0lGX01BWF9TRUdN
RU5UU19QRVJfUkVRVUVTVCk7Ci0KIAllcnIgPSB4ZW5idXNfZ3JhbnRfcmluZyhkZXYsIHZpcnRf
dG9fbWZuKGluZm8tPnJpbmcuc3JpbmcpKTsKIAlpZiAoZXJyIDwgMCkgewogCQlmcmVlX3BhZ2Uo
KHVuc2lnbmVkIGxvbmcpc3JpbmcpOwpAQCAtMTExNiwxMiArMTI1Niw2IEBAIGFnYWluOgogCQln
b3RvIGRlc3Ryb3lfYmxrcmluZzsKIAl9CiAKLQkvKiBBbGxvY2F0ZSBtZW1vcnkgZm9yIGdyYW50
cyAqLwotCWVyciA9IGZpbGxfZ3JhbnRfYnVmZmVyKGluZm8sIEJMS19SSU5HX1NJWkUgKgotCSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVT
VCk7Ci0JaWYgKGVycikKLQkJZ290byBvdXQ7Ci0KIAl4ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwg
WGVuYnVzU3RhdGVJbml0aWFsaXNlZCk7CiAKIAlyZXR1cm4gMDsKQEAgLTEyMjMsMTMgKzEzNTcs
ODQgQEAgc3RhdGljIGludCBibGtmcm9udF9wcm9iZShzdHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2
LAogCXJldHVybiAwOwogfQogCisvKgorICogVGhpcyBpcyBhIGNsb25lIG9mIG1kX3RyaW1fYmlv
LCB1c2VkIHRvIHNwbGl0IGEgYmlvIGludG8gc21hbGxlciBvbmVzCisgKi8KK3N0YXRpYyB2b2lk
IHRyaW1fYmlvKHN0cnVjdCBiaW8gKmJpbywgaW50IG9mZnNldCwgaW50IHNpemUpCit7CisJLyog
J2JpbycgaXMgYSBjbG9uZWQgYmlvIHdoaWNoIHdlIG5lZWQgdG8gdHJpbSB0byBtYXRjaAorCSAq
IHRoZSBnaXZlbiBvZmZzZXQgYW5kIHNpemUuCisJICogVGhpcyByZXF1aXJlcyBhZGp1c3Rpbmcg
Ymlfc2VjdG9yLCBiaV9zaXplLCBhbmQgYmlfaW9fdmVjCisJICovCisJaW50IGk7CisJc3RydWN0
IGJpb192ZWMgKmJ2ZWM7CisJaW50IHNvZmFyID0gMDsKKworCXNpemUgPDw9IDk7CisJaWYgKG9m
ZnNldCA9PSAwICYmIHNpemUgPT0gYmlvLT5iaV9zaXplKQorCQlyZXR1cm47CisKKwliaW8tPmJp
X3NlY3RvciArPSBvZmZzZXQ7CisJYmlvLT5iaV9zaXplID0gc2l6ZTsKKwlvZmZzZXQgPDw9IDk7
CisJY2xlYXJfYml0KEJJT19TRUdfVkFMSUQsICZiaW8tPmJpX2ZsYWdzKTsKKworCXdoaWxlIChi
aW8tPmJpX2lkeCA8IGJpby0+YmlfdmNudCAmJgorCSAgICAgICBiaW8tPmJpX2lvX3ZlY1tiaW8t
PmJpX2lkeF0uYnZfbGVuIDw9IG9mZnNldCkgeworCQkvKiByZW1vdmUgdGhpcyB3aG9sZSBiaW9f
dmVjICovCisJCW9mZnNldCAtPSBiaW8tPmJpX2lvX3ZlY1tiaW8tPmJpX2lkeF0uYnZfbGVuOwor
CQliaW8tPmJpX2lkeCsrOworCX0KKwlpZiAoYmlvLT5iaV9pZHggPCBiaW8tPmJpX3ZjbnQpIHsK
KwkJYmlvLT5iaV9pb192ZWNbYmlvLT5iaV9pZHhdLmJ2X29mZnNldCArPSBvZmZzZXQ7CisJCWJp
by0+YmlfaW9fdmVjW2Jpby0+YmlfaWR4XS5idl9sZW4gLT0gb2Zmc2V0OworCX0KKwkvKiBhdm9p
ZCBhbnkgY29tcGxpY2F0aW9ucyB3aXRoIGJpX2lkeCBiZWluZyBub24temVybyovCisJaWYgKGJp
by0+YmlfaWR4KSB7CisJCW1lbW1vdmUoYmlvLT5iaV9pb192ZWMsIGJpby0+YmlfaW9fdmVjK2Jp
by0+YmlfaWR4LAorCQkJKGJpby0+YmlfdmNudCAtIGJpby0+YmlfaWR4KSAqIHNpemVvZihzdHJ1
Y3QgYmlvX3ZlYykpOworCQliaW8tPmJpX3ZjbnQgLT0gYmlvLT5iaV9pZHg7CisJCWJpby0+Ymlf
aWR4ID0gMDsKKwl9CisJLyogTWFrZSBzdXJlIHZjbnQgYW5kIGxhc3QgYnYgYXJlIG5vdCB0b28g
YmlnICovCisJYmlvX2Zvcl9lYWNoX3NlZ21lbnQoYnZlYywgYmlvLCBpKSB7CisJCWlmIChzb2Zh
ciArIGJ2ZWMtPmJ2X2xlbiA+IHNpemUpCisJCQlidmVjLT5idl9sZW4gPSBzaXplIC0gc29mYXI7
CisJCWlmIChidmVjLT5idl9sZW4gPT0gMCkgeworCQkJYmlvLT5iaV92Y250ID0gaTsKKwkJCWJy
ZWFrOworCQl9CisJCXNvZmFyICs9IGJ2ZWMtPmJ2X2xlbjsKKwl9Cit9CisKK3N0YXRpYyB2b2lk
IHNwbGl0X2Jpb19lbmQoc3RydWN0IGJpbyAqYmlvLCBpbnQgZXJyb3IpCit7CisJc3RydWN0IHNw
bGl0X2JpbyAqc3BsaXRfYmlvID0gYmlvLT5iaV9wcml2YXRlOworCisJaWYgKGVycm9yKQorCQlz
cGxpdF9iaW8tPmVyciA9IGVycm9yOworCisJaWYgKGF0b21pY19kZWNfYW5kX3Rlc3QoJnNwbGl0
X2Jpby0+cGVuZGluZykpIHsKKwkJc3BsaXRfYmlvLT5iaW8tPmJpX3BoeXNfc2VnbWVudHMgPSAw
OworCQliaW9fZW5kaW8oc3BsaXRfYmlvLT5iaW8sIHNwbGl0X2Jpby0+ZXJyKTsKKwkJa2ZyZWUo
c3BsaXRfYmlvKTsKKwl9CisJYmlvX3B1dChiaW8pOworfQogCiBzdGF0aWMgaW50IGJsa2lmX3Jl
Y292ZXIoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiB7CiAJaW50IGk7Ci0Jc3RydWN0IGJs
a2lmX3JlcXVlc3QgKnJlcTsKKwlzdHJ1Y3QgcmVxdWVzdCAqcmVxLCAqbjsKIAlzdHJ1Y3QgYmxr
X3NoYWRvdyAqY29weTsKLQlpbnQgajsKKwlpbnQgcmM7CisJc3RydWN0IGJpbyAqYmlvLCAqY2xv
bmVkX2JpbzsKKwlzdHJ1Y3QgYmlvX2xpc3QgYmlvX2xpc3QsIG1lcmdlX2JpbzsKKwl1bnNpZ25l
ZCBpbnQgc2VnczsKKwlpbnQgcGVuZGluZywgb2Zmc2V0LCBzaXplOworCXN0cnVjdCBzcGxpdF9i
aW8gKnNwbGl0X2JpbzsKKwlzdHJ1Y3QgbGlzdF9oZWFkIHJlcXVlc3RzOwogCiAJLyogU3RhZ2Ug
MTogTWFrZSBhIHNhZmUgY29weSBvZiB0aGUgc2hhZG93IHN0YXRlLiAqLwogCWNvcHkgPSBrbWFs
bG9jKHNpemVvZihpbmZvLT5zaGFkb3cpLApAQCAtMTI0NSwzNiArMTQ1MCw2NCBAQCBzdGF0aWMg
aW50IGJsa2lmX3JlY292ZXIoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiAJaW5mby0+c2hh
ZG93X2ZyZWUgPSBpbmZvLT5yaW5nLnJlcV9wcm9kX3B2dDsKIAlpbmZvLT5zaGFkb3dbQkxLX1JJ
TkdfU0laRS0xXS5yZXEudS5ydy5pZCA9IDB4MGZmZmZmZmY7CiAKLQkvKiBTdGFnZSAzOiBGaW5k
IHBlbmRpbmcgcmVxdWVzdHMgYW5kIHJlcXVldWUgdGhlbS4gKi8KKwlyYyA9IGJsa2Zyb250X3Nl
dHVwX2luZGlyZWN0KGluZm8pOworCWlmIChyYykgeworCQlrZnJlZShjb3B5KTsKKwkJcmV0dXJu
IHJjOworCX0KKworCXNlZ3MgPSBpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMgPyA6IEJMS0lG
X01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVDsKKwlibGtfcXVldWVfbWF4X3NlZ21lbnRzKGluZm8t
PnJxLCBzZWdzKTsKKwliaW9fbGlzdF9pbml0KCZiaW9fbGlzdCk7CisJSU5JVF9MSVNUX0hFQUQo
JnJlcXVlc3RzKTsKIAlmb3IgKGkgPSAwOyBpIDwgQkxLX1JJTkdfU0laRTsgaSsrKSB7CiAJCS8q
IE5vdCBpbiB1c2U/ICovCiAJCWlmICghY29weVtpXS5yZXF1ZXN0KQogCQkJY29udGludWU7CiAK
LQkJLyogR3JhYiBhIHJlcXVlc3Qgc2xvdCBhbmQgY29weSBzaGFkb3cgc3RhdGUgaW50byBpdC4g
Ki8KLQkJcmVxID0gUklOR19HRVRfUkVRVUVTVCgmaW5mby0+cmluZywgaW5mby0+cmluZy5yZXFf
cHJvZF9wdnQpOwotCQkqcmVxID0gY29weVtpXS5yZXE7Ci0KLQkJLyogV2UgZ2V0IGEgbmV3IHJl
cXVlc3QgaWQsIGFuZCBtdXN0IHJlc2V0IHRoZSBzaGFkb3cgc3RhdGUuICovCi0JCXJlcS0+dS5y
dy5pZCA9IGdldF9pZF9mcm9tX2ZyZWVsaXN0KGluZm8pOwotCQltZW1jcHkoJmluZm8tPnNoYWRv
d1tyZXEtPnUucncuaWRdLCAmY29weVtpXSwgc2l6ZW9mKGNvcHlbaV0pKTsKLQotCQlpZiAocmVx
LT5vcGVyYXRpb24gIT0gQkxLSUZfT1BfRElTQ0FSRCkgewotCQkvKiBSZXdyaXRlIGFueSBncmFu
dCByZWZlcmVuY2VzIGludmFsaWRhdGVkIGJ5IHN1c3AvcmVzdW1lLiAqLwotCQkJZm9yIChqID0g
MDsgaiA8IHJlcS0+dS5ydy5ucl9zZWdtZW50czsgaisrKQotCQkJCWdudHRhYl9ncmFudF9mb3Jl
aWduX2FjY2Vzc19yZWYoCi0JCQkJCXJlcS0+dS5ydy5zZWdbal0uZ3JlZiwKLQkJCQkJaW5mby0+
eGJkZXYtPm90aGVyZW5kX2lkLAotCQkJCQlwZm5fdG9fbWZuKGNvcHlbaV0uZ3JhbnRzX3VzZWRb
al0tPnBmbiksCi0JCQkJCTApOworCQkvKgorCQkgKiBHZXQgdGhlIGJpb3MgaW4gdGhlIHJlcXVl
c3Qgc28gd2UgY2FuIHJlLXF1ZXVlIHRoZW0uCisJCSAqLworCQlpZiAoY29weVtpXS5yZXF1ZXN0
LT5jbWRfZmxhZ3MgJgorCQkgICAgKFJFUV9GTFVTSCB8IFJFUV9GVUEgfCBSRVFfRElTQ0FSRCB8
IFJFUV9TRUNVUkUpKSB7CisJCQkvKgorCQkJICogRmx1c2ggb3BlcmF0aW9ucyBkb24ndCBjb250
YWluIGJpb3MsIHNvCisJCQkgKiB3ZSBuZWVkIHRvIHJlcXVldWUgdGhlIHdob2xlIHJlcXVlc3QK
KwkJCSAqLworCQkJbGlzdF9hZGQoJmNvcHlbaV0ucmVxdWVzdC0+cXVldWVsaXN0LCAmcmVxdWVz
dHMpOworCQkJY29udGludWU7CiAJCX0KLQkJaW5mby0+c2hhZG93W3JlcS0+dS5ydy5pZF0ucmVx
ID0gKnJlcTsKLQotCQlpbmZvLT5yaW5nLnJlcV9wcm9kX3B2dCsrOworCQltZXJnZV9iaW8uaGVh
ZCA9IGNvcHlbaV0ucmVxdWVzdC0+YmlvOworCQltZXJnZV9iaW8udGFpbCA9IGNvcHlbaV0ucmVx
dWVzdC0+YmlvdGFpbDsKKwkJYmlvX2xpc3RfbWVyZ2UoJmJpb19saXN0LCAmbWVyZ2VfYmlvKTsK
KwkJY29weVtpXS5yZXF1ZXN0LT5iaW8gPSBOVUxMOworCQlibGtfcHV0X3JlcXVlc3QoY29weVtp
XS5yZXF1ZXN0KTsKIAl9CiAKIAlrZnJlZShjb3B5KTsKIAorCS8qCisJICogRW1wdHkgdGhlIHF1
ZXVlLCB0aGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIHdlIG1pZ2h0IGhhdmUKKwkgKiByZXF1ZXN0
cyBpbiB0aGUgcXVldWUgd2l0aCBtb3JlIHNlZ21lbnRzIHRoYW4gd2hhdCB3ZQorCSAqIGNhbiBo
YW5kbGUgbm93LgorCSAqLworCXNwaW5fbG9ja19pcnEoJmluZm8tPmlvX2xvY2spOworCXdoaWxl
ICgocmVxID0gYmxrX2ZldGNoX3JlcXVlc3QoaW5mby0+cnEpKSAhPSBOVUxMKSB7CisJCWlmIChy
ZXEtPmNtZF9mbGFncyAmCisJCSAgICAoUkVRX0ZMVVNIIHwgUkVRX0ZVQSB8IFJFUV9ESVNDQVJE
IHwgUkVRX1NFQ1VSRSkpIHsKKwkJCWxpc3RfYWRkKCZyZXEtPnF1ZXVlbGlzdCwgJnJlcXVlc3Rz
KTsKKwkJCWNvbnRpbnVlOworCQl9CisJCW1lcmdlX2Jpby5oZWFkID0gcmVxLT5iaW87CisJCW1l
cmdlX2Jpby50YWlsID0gcmVxLT5iaW90YWlsOworCQliaW9fbGlzdF9tZXJnZSgmYmlvX2xpc3Qs
ICZtZXJnZV9iaW8pOworCQlyZXEtPmJpbyA9IE5VTEw7CisJCWlmIChyZXEtPmNtZF9mbGFncyAm
IChSRVFfRkxVU0ggfCBSRVFfRlVBKSkKKwkJCXByX2FsZXJ0KCJkaXNrY2FjaGUgZmx1c2ggcmVx
dWVzdCBmb3VuZCFcbiIpOworCQlfX2Jsa19wdXRfcmVxdWVzdChpbmZvLT5ycSwgcmVxKTsKKwl9
CisJc3Bpbl91bmxvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKKwogCXhlbmJ1c19zd2l0Y2hfc3Rh
dGUoaW5mby0+eGJkZXYsIFhlbmJ1c1N0YXRlQ29ubmVjdGVkKTsKIAogCXNwaW5fbG9ja19pcnEo
JmluZm8tPmlvX2xvY2spOwpAQCAtMTI4MiwxNCArMTUxNSw1MCBAQCBzdGF0aWMgaW50IGJsa2lm
X3JlY292ZXIoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiAJLyogTm93IHNhZmUgZm9yIHVz
IHRvIHVzZSB0aGUgc2hhcmVkIHJpbmcgKi8KIAlpbmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFU
RV9DT05ORUNURUQ7CiAKLQkvKiBTZW5kIG9mZiByZXF1ZXVlZCByZXF1ZXN0cyAqLwotCWZsdXNo
X3JlcXVlc3RzKGluZm8pOwotCiAJLyogS2ljayBhbnkgb3RoZXIgbmV3IHJlcXVlc3RzIHF1ZXVl
ZCBzaW5jZSB3ZSByZXN1bWVkICovCiAJa2lja19wZW5kaW5nX3JlcXVlc3RfcXVldWVzKGluZm8p
OwogCisJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHJlcSwgbiwgJnJlcXVlc3RzLCBxdWV1ZWxp
c3QpIHsKKwkJLyogUmVxdWV1ZSBwZW5kaW5nIHJlcXVlc3RzIChmbHVzaCBvciBkaXNjYXJkKSAq
LworCQlsaXN0X2RlbF9pbml0KCZyZXEtPnF1ZXVlbGlzdCk7CisJCUJVR19PTihyZXEtPm5yX3Bo
eXNfc2VnbWVudHMgPiBzZWdzKTsKKwkJYmxrX3JlcXVldWVfcmVxdWVzdChpbmZvLT5ycSwgcmVx
KTsKKwl9CiAJc3Bpbl91bmxvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKIAorCXdoaWxlICgoYmlv
ID0gYmlvX2xpc3RfcG9wKCZiaW9fbGlzdCkpICE9IE5VTEwpIHsKKwkJLyogVHJhdmVyc2UgdGhl
IGxpc3Qgb2YgcGVuZGluZyBiaW9zIGFuZCByZS1xdWV1ZSB0aGVtICovCisJCWlmIChiaW9fc2Vn
bWVudHMoYmlvKSA+IHNlZ3MpIHsKKwkJCS8qCisJCQkgKiBUaGlzIGJpbyBoYXMgbW9yZSBzZWdt
ZW50cyB0aGFuIHdoYXQgd2UgY2FuCisJCQkgKiBoYW5kbGUsIHdlIGhhdmUgdG8gc3BsaXQgaXQu
CisJCQkgKi8KKwkJCXBlbmRpbmcgPSAoYmlvX3NlZ21lbnRzKGJpbykgKyBzZWdzIC0gMSkgLyBz
ZWdzOworCQkJc3BsaXRfYmlvID0ga3phbGxvYyhzaXplb2YoKnNwbGl0X2JpbyksIEdGUF9OT0lP
KTsKKwkJCUJVR19PTihzcGxpdF9iaW8gPT0gTlVMTCk7CisJCQlhdG9taWNfc2V0KCZzcGxpdF9i
aW8tPnBlbmRpbmcsIHBlbmRpbmcpOworCQkJc3BsaXRfYmlvLT5iaW8gPSBiaW87CisJCQlmb3Ig
KGkgPSAwOyBpIDwgcGVuZGluZzsgaSsrKSB7CisJCQkJb2Zmc2V0ID0gKGkgKiBzZWdzICogUEFH
RV9TSVpFKSA+PiA5OworCQkJCXNpemUgPSBNSU4oKHNlZ3MgKiBQQUdFX1NJWkUpID4+IDksCisJ
CQkJICAgICAgICAgICAoYmlvLT5iaV9zaXplID4+IDkpIC0gb2Zmc2V0KTsKKwkJCQljbG9uZWRf
YmlvID0gYmlvX2Nsb25lKGJpbywgR0ZQX05PSU8pOworCQkJCUJVR19PTihjbG9uZWRfYmlvID09
IE5VTEwpOworCQkJCXRyaW1fYmlvKGNsb25lZF9iaW8sIG9mZnNldCwgc2l6ZSk7CisJCQkJY2xv
bmVkX2Jpby0+YmlfcHJpdmF0ZSA9IHNwbGl0X2JpbzsKKwkJCQljbG9uZWRfYmlvLT5iaV9lbmRf
aW8gPSBzcGxpdF9iaW9fZW5kOworCQkJCXN1Ym1pdF9iaW8oY2xvbmVkX2Jpby0+YmlfcncsIGNs
b25lZF9iaW8pOworCQkJfQorCQkJLyoKKwkJCSAqIE5vdyB3ZSBoYXZlIHRvIHdhaXQgZm9yIGFs
bCB0aG9zZSBzbWFsbGVyIGJpb3MgdG8KKwkJCSAqIGVuZCwgc28gd2UgY2FuIGFsc28gZW5kIHRo
ZSAicGFyZW50IiBiaW8uCisJCQkgKi8KKwkJCWNvbnRpbnVlOworCQl9CisJCS8qIFdlIGRvbid0
IG5lZWQgdG8gc3BsaXQgdGhpcyBiaW8gKi8KKwkJc3VibWl0X2JpbyhiaW8tPmJpX3J3LCBiaW8p
OworCX0KKwogCXJldHVybiAwOwogfQogCkBAIC0xMzA5LDggKzE1NzgsMTIgQEAgc3RhdGljIGlu
dCBibGtmcm9udF9yZXN1bWUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldikKIAlibGtpZl9mcmVl
KGluZm8sIGluZm8tPmNvbm5lY3RlZCA9PSBCTEtJRl9TVEFURV9DT05ORUNURUQpOwogCiAJZXJy
ID0gdGFsa190b19ibGtiYWNrKGRldiwgaW5mbyk7Ci0JaWYgKGluZm8tPmNvbm5lY3RlZCA9PSBC
TEtJRl9TVEFURV9TVVNQRU5ERUQgJiYgIWVycikKLQkJZXJyID0gYmxraWZfcmVjb3ZlcihpbmZv
KTsKKworCS8qCisJICogV2UgaGF2ZSB0byB3YWl0IGZvciB0aGUgYmFja2VuZCB0byBzd2l0Y2gg
dG8KKwkgKiBjb25uZWN0ZWQgc3RhdGUsIHNpbmNlIHdlIHdhbnQgdG8gcmVhZCB3aGljaAorCSAq
IGZlYXR1cmVzIGl0IHN1cHBvcnRzLgorCSAqLwogCiAJcmV0dXJuIGVycjsKIH0KQEAgLTEzODgs
NiArMTY2MSw2MiBAQCBzdGF0aWMgdm9pZCBibGtmcm9udF9zZXR1cF9kaXNjYXJkKHN0cnVjdCBi
bGtmcm9udF9pbmZvICppbmZvKQogCWtmcmVlKHR5cGUpOwogfQogCitzdGF0aWMgaW50IGJsa2Zy
b250X3NldHVwX2luZGlyZWN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKQoreworCXVuc2ln
bmVkIGludCBpbmRpcmVjdF9zZWdtZW50cywgc2VnczsKKwlpbnQgZXJyLCBpOworCisJZXJyID0g
eGVuYnVzX2dhdGhlcihYQlRfTklMLCBpbmZvLT54YmRldi0+b3RoZXJlbmQsCisJCQkgICAgIm1h
eC1pbmRpcmVjdC1zZWdtZW50cyIsICIldSIsICZpbmRpcmVjdF9zZWdtZW50cywKKwkJCSAgICBO
VUxMKTsKKwlpZiAoZXJyKSB7CisJCWluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyA9IDA7CisJ
CXNlZ3MgPSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1Q7CisJfSBlbHNlIHsKKwkJaW5m
by0+bWF4X2luZGlyZWN0X3NlZ21lbnRzID0gTUlOKGluZGlyZWN0X3NlZ21lbnRzLAorCQkgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeGVuX2Jsa2lmX21heF9zZWdtZW50cyk7CisJ
CXNlZ3MgPSBpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHM7CisJfQorCWluZm8tPnNnID0ga3ph
bGxvYyhzaXplb2YoaW5mby0+c2dbMF0pICogc2VncywgR0ZQX0tFUk5FTCk7CisJaWYgKGluZm8t
PnNnID09IE5VTEwpCisJCWdvdG8gb3V0X29mX21lbW9yeTsKKwlzZ19pbml0X3RhYmxlKGluZm8t
PnNnLCBzZWdzKTsKKworCWVyciA9IGZpbGxfZ3JhbnRfYnVmZmVyKGluZm8sCisJICAgICAgICAg
ICAgICAgICAgICAgICAgKHNlZ3MgKyBJTkRJUkVDVF9HUkVGUyhzZWdzKSkgKiBCTEtfUklOR19T
SVpFKTsKKwlpZiAoZXJyKQorCQlnb3RvIG91dF9vZl9tZW1vcnk7CisKKwlmb3IgKGkgPSAwOyBp
IDwgQkxLX1JJTkdfU0laRTsgaSsrKSB7CisJCWluZm8tPnNoYWRvd1tpXS5ncmFudHNfdXNlZCA9
IGt6YWxsb2MoCisJCQlzaXplb2YoaW5mby0+c2hhZG93W2ldLmdyYW50c191c2VkWzBdKSAqIHNl
Z3MsCisJCQlHRlBfTk9JTyk7CisJCWlmIChpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMpCisJ
CQlpbmZvLT5zaGFkb3dbaV0uaW5kaXJlY3RfZ3JhbnRzID0ga3phbGxvYygKKwkJCQlzaXplb2Yo
aW5mby0+c2hhZG93W2ldLmluZGlyZWN0X2dyYW50c1swXSkgKgorCQkJCUlORElSRUNUX0dSRUZT
KHNlZ3MpLAorCQkJCUdGUF9OT0lPKTsKKwkJaWYgKChpbmZvLT5zaGFkb3dbaV0uZ3JhbnRzX3Vz
ZWQgPT0gTlVMTCkgfHwKKwkJICAgICAoaW5mby0+bWF4X2luZGlyZWN0X3NlZ21lbnRzICYmCisJ
CSAgICAgKGluZm8tPnNoYWRvd1tpXS5pbmRpcmVjdF9ncmFudHMgPT0gTlVMTCkpKQorCQkJZ290
byBvdXRfb2ZfbWVtb3J5OworCX0KKworCisJcmV0dXJuIDA7CisKK291dF9vZl9tZW1vcnk6CisJ
a2ZyZWUoaW5mby0+c2cpOworCWluZm8tPnNnID0gTlVMTDsKKwlmb3IgKGkgPSAwOyBpIDwgQkxL
X1JJTkdfU0laRTsgaSsrKSB7CisJCWtmcmVlKGluZm8tPnNoYWRvd1tpXS5ncmFudHNfdXNlZCk7
CisJCWluZm8tPnNoYWRvd1tpXS5ncmFudHNfdXNlZCA9IE5VTEw7CisJCWtmcmVlKGluZm8tPnNo
YWRvd1tpXS5pbmRpcmVjdF9ncmFudHMpOworCQlpbmZvLT5zaGFkb3dbaV0uaW5kaXJlY3RfZ3Jh
bnRzID0gTlVMTDsKKwl9CisJcmV0dXJuIC1FTk9NRU07Cit9CisKIC8qCiAgKiBJbnZva2VkIHdo
ZW4gdGhlIGJhY2tlbmQgaXMgZmluYWxseSAncmVhZHknIChhbmQgaGFzIHRvbGQgcHJvZHVjZWQK
ICAqIHRoZSBkZXRhaWxzIGFib3V0IHRoZSBwaHlzaWNhbCBkZXZpY2UgLSAjc2VjdG9ycywgc2l6
ZSwgZXRjKS4KQEAgLTE0MTUsOCArMTc0NCw5IEBAIHN0YXRpYyB2b2lkIGJsa2Zyb250X2Nvbm5l
Y3Qoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiAJCXNldF9jYXBhY2l0eShpbmZvLT5nZCwg
c2VjdG9ycyk7CiAJCXJldmFsaWRhdGVfZGlzayhpbmZvLT5nZCk7CiAKLQkJLyogZmFsbCB0aHJv
dWdoICovCisJCXJldHVybjsKIAljYXNlIEJMS0lGX1NUQVRFX1NVU1BFTkRFRDoKKwkJYmxraWZf
cmVjb3ZlcihpbmZvKTsKIAkJcmV0dXJuOwogCiAJZGVmYXVsdDoKQEAgLTE0MzcsNiArMTc2Nyw3
IEBAIHN0YXRpYyB2b2lkIGJsa2Zyb250X2Nvbm5lY3Qoc3RydWN0IGJsa2Zyb250X2luZm8gKmlu
Zm8pCiAJCQkJIGluZm8tPnhiZGV2LT5vdGhlcmVuZCk7CiAJCXJldHVybjsKIAl9CisJaW5mby0+
c2VjdG9yX3NpemUgPSBzZWN0b3Jfc2l6ZTsKIAogCWluZm8tPmZlYXR1cmVfZmx1c2ggPSAwOwog
CWluZm8tPmZsdXNoX29wID0gMDsKQEAgLTE0ODQsNiArMTgxNSwxMyBAQCBzdGF0aWMgdm9pZCBi
bGtmcm9udF9jb25uZWN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKQogCWVsc2UKIAkJaW5m
by0+ZmVhdHVyZV9wZXJzaXN0ZW50ID0gcGVyc2lzdGVudDsKIAorCWVyciA9IGJsa2Zyb250X3Nl
dHVwX2luZGlyZWN0KGluZm8pOworCWlmIChlcnIpIHsKKwkJeGVuYnVzX2Rldl9mYXRhbChpbmZv
LT54YmRldiwgZXJyLCAic2V0dXBfaW5kaXJlY3QgYXQgJXMiLAorCQkJCSBpbmZvLT54YmRldi0+
b3RoZXJlbmQpOworCQlyZXR1cm47CisJfQorCiAJZXJyID0geGx2YmRfYWxsb2NfZ2VuZGlzayhz
ZWN0b3JzLCBpbmZvLCBiaW5mbywgc2VjdG9yX3NpemUpOwogCWlmIChlcnIpIHsKIAkJeGVuYnVz
X2Rldl9mYXRhbChpbmZvLT54YmRldiwgZXJyLCAieGx2YmRfYWRkIGF0ICVzIiwKZGlmZiAtLWdp
dCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9pby9ibGtpZi5oIGIvaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL2lvL2Jsa2lmLmgKaW5kZXggMDFjM2Q2Mi4uNmQ5OTg0OSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL2lvL2Jsa2lmLmgKKysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2lv
L2Jsa2lmLmgKQEAgLTEwMiw2ICsxMDIsOCBAQCB0eXBlZGVmIHVpbnQ2NF90IGJsa2lmX3NlY3Rv
cl90OwogICovCiAjZGVmaW5lIEJMS0lGX09QX0RJU0NBUkQgICAgICAgICAgIDUKIAorI2RlZmlu
ZSBCTEtJRl9PUF9JTkRJUkVDVCAgICAgICAgICA2CisKIC8qCiAgKiBNYXhpbXVtIHNjYXR0ZXIv
Z2F0aGVyIHNlZ21lbnRzIHBlciByZXF1ZXN0LgogICogVGhpcyBpcyBjYXJlZnVsbHkgY2hvc2Vu
IHNvIHRoYXQgc2l6ZW9mKHN0cnVjdCBibGtpZl9yaW5nKSA8PSBQQUdFX1NJWkUuCkBAIC0xMDks
NiArMTExLDE2IEBAIHR5cGVkZWYgdWludDY0X3QgYmxraWZfc2VjdG9yX3Q7CiAgKi8KICNkZWZp
bmUgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUIDExCiAKKyNkZWZpbmUgQkxLSUZfTUFY
X0lORElSRUNUX0dSRUZTX1BFUl9SRVFVRVNUIDgKKworc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2Vn
bWVudF9hbGlnbmVkIHsKKwlncmFudF9yZWZfdCBncmVmOyAgICAgICAgLyogcmVmZXJlbmNlIHRv
IEkvTyBidWZmZXIgZnJhbWUgICAgICAgICovCisJLyogQGZpcnN0X3NlY3Q6IGZpcnN0IHNlY3Rv
ciBpbiBmcmFtZSB0byB0cmFuc2ZlciAoaW5jbHVzaXZlKS4gICAqLworCS8qIEBsYXN0X3NlY3Q6
IGxhc3Qgc2VjdG9yIGluIGZyYW1lIHRvIHRyYW5zZmVyIChpbmNsdXNpdmUpLiAgICAgKi8KKwl1
aW50OF90ICAgICBmaXJzdF9zZWN0LCBsYXN0X3NlY3Q7CisJdWludDE2X3QgICAgX3BhZDsgLyog
cGFkZGluZyB0byBtYWtlIGl0IDggYnl0ZXMsIHNvIGl0J3MgY2FjaGUtYWxpZ25lZCAqLworfSBf
X2F0dHJpYnV0ZV9fKChfX3BhY2tlZF9fKSk7CisKIHN0cnVjdCBibGtpZl9yZXF1ZXN0X3J3IHsK
IAl1aW50OF90ICAgICAgICBucl9zZWdtZW50czsgIC8qIG51bWJlciBvZiBzZWdtZW50cyAgICAg
ICAgICAgICAgICAgICAqLwogCWJsa2lmX3ZkZXZfdCAgIGhhbmRsZTsgICAgICAgLyogb25seSBm
b3IgcmVhZC93cml0ZSByZXF1ZXN0cyAgICAgICAgICovCkBAIC0xMzgsMTEgKzE1MCwyNCBAQCBz
dHJ1Y3QgYmxraWZfcmVxdWVzdF9kaXNjYXJkIHsKIAl1aW50OF90ICAgICAgICBfcGFkMzsKIH0g
X19hdHRyaWJ1dGVfXygoX19wYWNrZWRfXykpOwogCitzdHJ1Y3QgYmxraWZfcmVxdWVzdF9pbmRp
cmVjdCB7CisJdWludDhfdCAgICAgICAgaW5kaXJlY3Rfb3A7CisJdWludDE2X3QgICAgICAgbnJf
c2VnbWVudHM7CisjaWZkZWYgQ09ORklHX1g4Nl82NAorCXVpbnQzMl90ICAgICAgIF9wYWQxOyAg
ICAgICAgLyogb2Zmc2V0b2YoYmxraWZfLi4uLHUuaW5kaXJlY3QuaWQpID09IDggKi8KKyNlbmRp
ZgorCXVpbnQ2NF90ICAgICAgIGlkOworCWJsa2lmX3ZkZXZfdCAgIGhhbmRsZTsKKwlibGtpZl9z
ZWN0b3JfdCBzZWN0b3JfbnVtYmVyOworCWdyYW50X3JlZl90ICAgIGluZGlyZWN0X2dyZWZzW0JM
S0lGX01BWF9JTkRJUkVDVF9HUkVGU19QRVJfUkVRVUVTVF07Cit9IF9fYXR0cmlidXRlX18oKF9f
cGFja2VkX18pKTsKKwogc3RydWN0IGJsa2lmX3JlcXVlc3QgewogCXVpbnQ4X3QgICAgICAgIG9w
ZXJhdGlvbjsgICAgLyogQkxLSUZfT1BfPz8/ICAgICAgICAgICAgICAgICAgICAgICAgICovCiAJ
dW5pb24gewogCQlzdHJ1Y3QgYmxraWZfcmVxdWVzdF9ydyBydzsKIAkJc3RydWN0IGJsa2lmX3Jl
cXVlc3RfZGlzY2FyZCBkaXNjYXJkOworCQlzdHJ1Y3QgYmxraWZfcmVxdWVzdF9pbmRpcmVjdCBp
bmRpcmVjdDsKIAl9IHU7CiB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKIAotLSAKMS43
LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k7-0005od-Sc; Thu, 28 Feb 2013 10:29:39 +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 1UB0k5-0005ml-Ok
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:38 +0000
Received: from [193.109.254.147:32559] by server-13.bemta-14.messagelabs.com
	id 72/3B-30639-1913F215; Thu, 28 Feb 2013 10:29:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!7
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1521 invoked from network); 28 Feb 2013 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012285"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:37 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:36 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:49 +0100
Message-ID: <1362047335-26402-7-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 06/12] xen-blkback: implement LRU mechanism
	for persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBtZWNoYW5pc20gYWxsb3dzIGJsa2JhY2sgdG8gY2hhbmdlIHRoZSBudW1iZXIgb2YgZ3Jh
bnRzCnBlcnNpc3RlbnRseSBtYXBwZWQgYXQgcnVuIHRpbWUuCgpUaGUgYWxnb3JpdGhtIHVzZXMg
YSBzaW1wbGUgTFJVIG1lY2hhbmlzbSB0aGF0IHJlbW92ZXMgKGlmIG5lZWRlZCkgdGhlCnBlcnNp
c3RlbnQgZ3JhbnRzIHRoYXQgaGF2ZSBub3QgYmVlbiB1c2VkIHNpbmNlIHRoZSBsYXN0IExSVSBy
dW4sIG9yCmlmIGFsbCBncmFudHMgaGF2ZSBiZWVuIHVzZWQgaXQgcmVtb3ZlcyB0aGUgZmlyc3Qg
Z3JhbnRzIGluIHRoZSBsaXN0Cih0aGF0IGFyZSBub3QgaW4gdXNlKS4KClRoZSBhbGdvcml0aG0g
aGFzIHNldmVyYWwgcGFyYW1ldGVycyB0aGF0IGNhbiBiZSB0dW5lZCBieSB0aGUgdXNlcgpmcm9t
IHN5c2ZzOgoKICogbWF4X3BlcnNpc3RlbnRfZ3JhbnRzOiBtYXhpbXVtIG51bWJlciBvZiBncmFu
dHMgdGhhdCB3aWxsIGJlCiAgIHBlcnNpc3RlbnRseSBtYXBwZWQuCiAqIGxydV9pbnRlcnZhbDog
bWluaW11bSBpbnRlcnZhbCAoaW4gbXMpIGF0IHdoaWNoIHRoZSBMUlUgc2hvdWxkIGJlCiAgIHJ1
bgogKiBscnVfbnVtX2NsZWFuOiBudW1iZXIgb2YgcGVyc2lzdGVudCBncmFudHMgdG8gcmVtb3Zl
IHdoZW4gZXhlY3V0aW5nCiAgIHRoZSBMUlUuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCi0tLQogZHJp
dmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgfCAgMjA3ICsrKysrKysrKysrKysrKysr
KysrKysrKysrKy0tLS0tLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oICB8
ICAgIDQgKwogZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyAgfCAgICAxICsKIDMg
ZmlsZXMgY2hhbmdlZCwgMTY2IGluc2VydGlvbnMoKyksIDQ2IGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIGIvZHJpdmVycy9ibG9j
ay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKaW5kZXggNDE1YTBjNy4uYzE0YjczNiAxMDA2NDQKLS0t
IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKKysrIGIvZHJpdmVycy9ibG9j
ay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKQEAgLTYzLDYgKzYzLDQ0IEBAIHN0YXRpYyBpbnQgeGVu
X2Jsa2lmX3JlcXMgPSA2NDsKIG1vZHVsZV9wYXJhbV9uYW1lZChyZXFzLCB4ZW5fYmxraWZfcmVx
cywgaW50LCAwKTsKIE1PRFVMRV9QQVJNX0RFU0MocmVxcywgIk51bWJlciBvZiBibGtiYWNrIHJl
cXVlc3RzIHRvIGFsbG9jYXRlIik7CiAKKy8qCisgKiBNYXhpbXVtIG51bWJlciBvZiBncmFudHMg
dG8gbWFwIHBlcnNpc3RlbnRseSBpbiBibGtiYWNrLiBGb3IgbWF4aW11bQorICogcGVyZm9ybWFu
Y2UgdGhpcyBzaG91bGQgYmUgdGhlIHRvdGFsIG51bWJlcnMgb2YgZ3JhbnRzIHRoYXQgY2FuIGJl
IHVzZWQKKyAqIHRvIGZpbGwgdGhlIHJpbmcsIGJ1dCBzaW5jZSB0aGlzIG1pZ2h0IGJlY29tZSB0
b28gaGlnaCwgc3BlY2lhbGx5IHdpdGgKKyAqIHRoZSB1c2Ugb2YgaW5kaXJlY3QgZGVzY3JpcHRv
cnMsIHdlIHNldCBpdCB0byBhIHZhbHVlIHRoYXQgcHJvdmlkZXMgZ29vZAorICogcGVyZm9ybWFu
Y2Ugd2l0aG91dCB1c2luZyB0b28gbXVjaCBtZW1vcnkuCisgKgorICogV2hlbiB0aGUgbGlzdCBv
ZiBwZXJzaXN0ZW50IGdyYW50cyBpcyBmdWxsIHdlIGNsZWFuIGl0IHVzaW5nIGEgTFJVCisgKiBh
bGdvcml0aG0uCisgKi8KKworc3RhdGljIGludCB4ZW5fYmxraWZfbWF4X3BncmFudHMgPSAzNTI7
Cittb2R1bGVfcGFyYW1fbmFtZWQobWF4X3BlcnNpc3RlbnRfZ3JhbnRzLCB4ZW5fYmxraWZfbWF4
X3BncmFudHMsIGludCwgMDY0NCk7CitNT0RVTEVfUEFSTV9ERVNDKG1heF9wZXJzaXN0ZW50X2dy
YW50cywKKyAgICAgICAgICAgICAgICAgIk1heGltdW0gbnVtYmVyIG9mIGdyYW50cyB0byBtYXAg
cGVyc2lzdGVudGx5Iik7CisKKy8qCisgKiBUaGUgTFJVIG1lY2hhbmlzbSB0byBjbGVhbiB0aGUg
bGlzdHMgb2YgcGVyc2lzdGVudCBncmFudHMgbmVlZHMgdG8KKyAqIGJlIGV4ZWN1dGVkIHBlcmlv
ZGljYWxseS4gVGhlIHRpbWUgaW50ZXJ2YWwgYmV0d2VlbiBjb25zZWN1dGl2ZSBleGVjdXRpb25z
CisgKiBvZiB0aGUgcHVyZ2UgbWVjaGFuaXNtIGlzIHNldCBpbiBtcy4KKyAqLworCitzdGF0aWMg
aW50IHhlbl9ibGtpZl9scnVfaW50ZXJ2YWwgPSAxMDA7Cittb2R1bGVfcGFyYW1fbmFtZWQobHJ1
X2ludGVydmFsLCB4ZW5fYmxraWZfbHJ1X2ludGVydmFsLCBpbnQsIDA2NDQpOworTU9EVUxFX1BB
Uk1fREVTQyhscnVfaW50ZXJ2YWwsCisiRXhlY3V0aW9uIGludGVydmFsIChpbiBtcykgb2YgdGhl
IExSVSBtZWNoYW5pc20gdG8gY2xlYW4gdGhlIGxpc3Qgb2YgcGVyc2lzdGVudCBncmFudHMiKTsK
KworLyoKKyAqIFdoZW4gdGhlIHBlcnNpc3RlbnQgZ3JhbnRzIGxpc3QgaXMgZnVsbCB3ZSB3aWxs
IHJlbW92ZSB1bnVzZWQgZ3JhbnRzCisgKiBmcm9tIHRoZSBsaXN0LiBUaGUgbnVtYmVyIG9mIGdy
YW50cyB0byBiZSByZW1vdmVkIGF0IGVhY2ggTFJVIGV4ZWN1dGlvbgorICogY2FuIGJlIHNldCBk
eW5hbWljYWxseS4KKyAqLworCitzdGF0aWMgaW50IHhlbl9ibGtpZl9scnVfbnVtX2NsZWFuID0g
QkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOworbW9kdWxlX3BhcmFtX25hbWVkKGxydV9u
dW1fY2xlYW4sIHhlbl9ibGtpZl9scnVfbnVtX2NsZWFuLCBpbnQsIDA2NDQpOworTU9EVUxFX1BB
Uk1fREVTQyhscnVfbnVtX2NsZWFuLAorIk51bWJlciBvZiBwZXJzaXN0ZW50IGdyYW50cyB0byB1
bm1hcCB3aGVuIHRoZSBsaXN0IGlzIGZ1bGwiKTsKKwogLyogUnVuLXRpbWUgc3dpdGNoYWJsZTog
L3N5cy9tb2R1bGUvYmxrYmFjay9wYXJhbWV0ZXJzLyAqLwogc3RhdGljIHVuc2lnbmVkIGludCBs
b2dfc3RhdHM7CiBtb2R1bGVfcGFyYW0obG9nX3N0YXRzLCBpbnQsIDA2NDQpOwpAQCAtODEsNyAr
MTE5LDcgQEAgc3RydWN0IHBlbmRpbmdfcmVxIHsKIAl1bnNpZ25lZCBzaG9ydAkJb3BlcmF0aW9u
OwogCWludAkJCXN0YXR1czsKIAlzdHJ1Y3QgbGlzdF9oZWFkCWZyZWVfbGlzdDsKLQlERUNMQVJF
X0JJVE1BUCh1bm1hcF9zZWcsIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCk7CisJc3Ry
dWN0IHBlcnNpc3RlbnRfZ250CSpwZXJzaXN0ZW50X2dudHNbQkxLSUZfTUFYX1NFR01FTlRTX1BF
Ul9SRVFVRVNUXTsKIH07CiAKICNkZWZpbmUgQkxLQkFDS19JTlZBTElEX0hBTkRMRSAofjApCkBA
IC0xMDIsMzYgKzE0MCw2IEBAIHN0cnVjdCB4ZW5fYmxrYmsgewogc3RhdGljIHN0cnVjdCB4ZW5f
YmxrYmsgKmJsa2JrOwogCiAvKgotICogTWF4aW11bSBudW1iZXIgb2YgZ3JhbnQgcGFnZXMgdGhh
dCBjYW4gYmUgbWFwcGVkIGluIGJsa2JhY2suCi0gKiBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JF
UVVFU1QgKiBSSU5HX1NJWkUgaXMgdGhlIG1heGltdW0gbnVtYmVyIG9mCi0gKiBwYWdlcyB0aGF0
IGJsa2JhY2sgd2lsbCBwZXJzaXN0ZW50bHkgbWFwLgotICogQ3VycmVudGx5LCB0aGlzIGlzOgot
ICogUklOR19TSVpFID0gMzIgKGZvciBhbGwga25vd24gcmluZyB0eXBlcykKLSAqIEJMS0lGX01B
WF9TRUdNRU5UU19QRVJfUkVRVUVTVCA9IDExCi0gKiBzaXplb2Yoc3RydWN0IHBlcnNpc3RlbnRf
Z250KSA9IDQ4Ci0gKiBTbyB0aGUgbWF4aW11bSBtZW1vcnkgdXNlZCB0byBzdG9yZSB0aGUgZ3Jh
bnRzIGlzOgotICogMzIgKiAxMSAqIDQ4ID0gMTY4OTYgYnl0ZXMKLSAqLwotc3RhdGljIGlubGlu
ZSB1bnNpZ25lZCBpbnQgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhlbnVtIGJsa2lmX3Byb3RvY29s
IHByb3RvY29sKQotewotCXN3aXRjaCAocHJvdG9jb2wpIHsKLQljYXNlIEJMS0lGX1BST1RPQ09M
X05BVElWRToKLQkJcmV0dXJuIF9fQ09OU1RfUklOR19TSVpFKGJsa2lmLCBQQUdFX1NJWkUpICoK
LQkJCSAgIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVDsKLQljYXNlIEJMS0lGX1BST1RP
Q09MX1g4Nl8zMjoKLQkJcmV0dXJuIF9fQ09OU1RfUklOR19TSVpFKGJsa2lmX3g4Nl8zMiwgUEFH
RV9TSVpFKSAqCi0JCQkgICBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1Q7Ci0JY2FzZSBC
TEtJRl9QUk9UT0NPTF9YODZfNjQ6Ci0JCXJldHVybiBfX0NPTlNUX1JJTkdfU0laRShibGtpZl94
ODZfNjQsIFBBR0VfU0laRSkgKgotCQkJICAgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNU
OwotCWRlZmF1bHQ6Ci0JCUJVRygpOwotCX0KLQlyZXR1cm4gMDsKLX0KLQotCi0vKgogICogTGl0
dGxlIGhlbHBmdWwgbWFjcm8gdG8gZmlndXJlIG91dCB0aGUgaW5kZXggYW5kIHZpcnR1YWwgYWRk
cmVzcyBvZiB0aGUKICAqIHBlbmRpbmdfcGFnZXNbLi5dLiBGb3IgZWFjaCAncGVuZGluZ19yZXEn
IHdlIGhhdmUgaGF2ZSB1cCB0bwogICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUICgx
MSkgcGFnZXMuIFRoZSBzZWcgd291bGQgYmUgZnJvbSAwIHRocm91Z2gKQEAgLTI1MSw2ICsyNTks
NzYgQEAgc3RhdGljIHZvaWQgZnJlZV9wZXJzaXN0ZW50X2dudHMoc3RydWN0IHJiX3Jvb3QgKnJv
b3QsIHVuc2lnbmVkIGludCBudW0pCiAJQlVHX09OKG51bSAhPSAwKTsKIH0KIAorc3RhdGljIGlu
dCBwdXJnZV9wZXJzaXN0ZW50X2dudChzdHJ1Y3QgcmJfcm9vdCAqcm9vdCwgaW50IG51bSkKK3sK
KwlzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiB1bm1hcFtCTEtJRl9NQVhfU0VHTUVOVFNf
UEVSX1JFUVVFU1RdOworCXN0cnVjdCBwYWdlICpwYWdlc1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVS
X1JFUVVFU1RdOworCXN0cnVjdCBwZXJzaXN0ZW50X2dudCAqcGVyc2lzdGVudF9nbnQ7CisJc3Ry
dWN0IHJiX25vZGUgKm47CisJaW50IHJldCwgc2Vnc190b191bm1hcCA9IDA7CisJaW50IHJlcXVl
c3RlZF9udW0gPSBudW07CisJaW50IHByZXNlcnZlX3VzZWQgPSAxOworCisJcHJfZGVidWcoIlJl
cXVlc3RlZCB0aGUgcHVyZ2Ugb2YgJWQgcGVyc2lzdGVudCBncmFudHNcbiIsIG51bSk7CisKK3B1
cmdlX2xpc3Q6CisJZm9yZWFjaF9ncmFudF9zYWZlKHBlcnNpc3RlbnRfZ250LCBuLCByb290LCBu
b2RlKSB7CisJCUJVR19PTihwZXJzaXN0ZW50X2dudC0+aGFuZGxlID09CisJCQlCTEtCQUNLX0lO
VkFMSURfSEFORExFKTsKKworCQlpZiAocGVyc2lzdGVudF9nbnQtPmZsYWdzICYgUEVSU0lTVEVO
VF9HTlRfQUNUSVZFKQorCQkJY29udGludWU7CisJCWlmIChwcmVzZXJ2ZV91c2VkICYmCisJCSAg
ICAocGVyc2lzdGVudF9nbnQtPmZsYWdzICYgUEVSU0lTVEVOVF9HTlRfVVNFRCkpCisJCQljb250
aW51ZTsKKworCQlnbnR0YWJfc2V0X3VubWFwX29wKCZ1bm1hcFtzZWdzX3RvX3VubWFwXSwKKwkJ
CSh1bnNpZ25lZCBsb25nKSBwZm5fdG9fa2FkZHIocGFnZV90b19wZm4oCisJCQkJcGVyc2lzdGVu
dF9nbnQtPnBhZ2UpKSwKKwkJCUdOVE1BUF9ob3N0X21hcCwKKwkJCXBlcnNpc3RlbnRfZ250LT5o
YW5kbGUpOworCisJCXBhZ2VzW3NlZ3NfdG9fdW5tYXBdID0gcGVyc2lzdGVudF9nbnQtPnBhZ2U7
CisKKwkJaWYgKCsrc2Vnc190b191bm1hcCA9PSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVF
U1QpIHsKKwkJCXJldCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxMLCBwYWdlcywKKwkJ
CQlzZWdzX3RvX3VubWFwKTsKKwkJCUJVR19PTihyZXQpOworCQkJZnJlZV94ZW5iYWxsb29uZWRf
cGFnZXMoc2Vnc190b191bm1hcCwgcGFnZXMpOworCQkJc2Vnc190b191bm1hcCA9IDA7CisJCX0K
KworCQlyYl9lcmFzZSgmcGVyc2lzdGVudF9nbnQtPm5vZGUsIHJvb3QpOworCQlrZnJlZShwZXJz
aXN0ZW50X2dudCk7CisJCWlmICgtLW51bSA9PSAwKQorCQkJZ290byBmaW5pc2hlZDsKKwl9CisJ
LyoKKwkgKiBJZiB3ZSBnZXQgaGVyZSBpdCBtZWFucyB3ZSBhbHNvIG5lZWQgdG8gc3RhcnQgY2xl
YW5pbmcKKwkgKiBncmFudHMgdGhhdCB3ZXJlIHVzZWQgc2luY2UgbGFzdCBwdXJnZSBpbiBvcmRl
ciB0byBjb3BlCisJICogd2l0aCB0aGUgcmVxdWVzdGVkIG51bQorCSAqLworCWlmIChwcmVzZXJ2
ZV91c2VkKSB7CisJCXByX2RlYnVnKCJTdGlsbCBtaXNzaW5nICVkIHB1cmdlZCBmcmFtZXNcbiIs
IG51bSk7CisJCXByZXNlcnZlX3VzZWQgPSAwOworCQlnb3RvIHB1cmdlX2xpc3Q7CisJfQorZmlu
aXNoZWQ6CisJaWYgKHNlZ3NfdG9fdW5tYXAgPiAwKSB7CisJCXJldCA9IGdudHRhYl91bm1hcF9y
ZWZzKHVubWFwLCBOVUxMLCBwYWdlcywgc2Vnc190b191bm1hcCk7CisJCUJVR19PTihyZXQpOwor
CQlmcmVlX3hlbmJhbGxvb25lZF9wYWdlcyhzZWdzX3RvX3VubWFwLCBwYWdlcyk7CisJfQorCS8q
IEZpbmFsbHkgcmVtb3ZlIHRoZSAidXNlZCIgZmxhZyBmcm9tIGFsbCB0aGUgcGVyc2lzdGVudCBn
cmFudHMgKi8KKwlmb3JlYWNoX2dyYW50X3NhZmUocGVyc2lzdGVudF9nbnQsIG4sIHJvb3QsIG5v
ZGUpIHsKKwkJQlVHX09OKHBlcnNpc3RlbnRfZ250LT5oYW5kbGUgPT0KKwkJCUJMS0JBQ0tfSU5W
QUxJRF9IQU5ETEUpOworCQlwZXJzaXN0ZW50X2dudC0+ZmxhZ3MgJj0gflBFUlNJU1RFTlRfR05U
X1VTRUQ7CisJfQorCXByX2RlYnVnKCJQdXJnZWQgJWQvJWRcbiIsIChyZXF1ZXN0ZWRfbnVtIC0g
bnVtKSwgcmVxdWVzdGVkX251bSk7CisJcmV0dXJuIChyZXF1ZXN0ZWRfbnVtIC0gbnVtKTsKK30K
KwogLyoKICAqIFJldHJpZXZlIGZyb20gdGhlICdwZW5kaW5nX3JlcXMnIGEgZnJlZSBwZW5kaW5n
X3JlcSBzdHJ1Y3R1cmUgdG8gYmUgdXNlZC4KICAqLwpAQCAtMzk3LDYgKzQ3NSw4IEBAIGludCB4
ZW5fYmxraWZfc2NoZWR1bGUodm9pZCAqYXJnKQogewogCXN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
ID0gYXJnOwogCXN0cnVjdCB4ZW5fdmJkICp2YmQgPSAmYmxraWYtPnZiZDsKKwlpbnQgcnFfcHVy
Z2UsIHB1cmdlZDsKKwl1bnNpZ25lZCBsb25nIHRpbWVvdXQ7CiAKIAl4ZW5fYmxraWZfZ2V0KGJs
a2lmKTsKIApAQCAtNDA2LDEzICs0ODYsMjEgQEAgaW50IHhlbl9ibGtpZl9zY2hlZHVsZSh2b2lk
ICphcmcpCiAJCWlmICh1bmxpa2VseSh2YmQtPnNpemUgIT0gdmJkX3N6KHZiZCkpKQogCQkJeGVu
X3ZiZF9yZXNpemUoYmxraWYpOwogCi0JCXdhaXRfZXZlbnRfaW50ZXJydXB0aWJsZSgKKwkJdGlt
ZW91dCA9IG1zZWNzX3RvX2ppZmZpZXMoeGVuX2Jsa2lmX2xydV9pbnRlcnZhbCk7CisKKwkJdGlt
ZW91dCA9IHdhaXRfZXZlbnRfaW50ZXJydXB0aWJsZV90aW1lb3V0KAogCQkJYmxraWYtPndxLAot
CQkJYmxraWYtPndhaXRpbmdfcmVxcyB8fCBrdGhyZWFkX3Nob3VsZF9zdG9wKCkpOwotCQl3YWl0
X2V2ZW50X2ludGVycnVwdGlibGUoCisJCQlibGtpZi0+d2FpdGluZ19yZXFzIHx8IGt0aHJlYWRf
c2hvdWxkX3N0b3AoKSwKKwkJCXRpbWVvdXQpOworCQlpZiAodGltZW91dCA9PSAwKQorCQkJZ290
byBwdXJnZV9nbnRfbGlzdDsKKwkJdGltZW91dCA9IHdhaXRfZXZlbnRfaW50ZXJydXB0aWJsZV90
aW1lb3V0KAogCQkJYmxrYmstPnBlbmRpbmdfZnJlZV93cSwKIAkJCSFsaXN0X2VtcHR5KCZibGti
ay0+cGVuZGluZ19mcmVlKSB8fAotCQkJa3RocmVhZF9zaG91bGRfc3RvcCgpKTsKKwkJCWt0aHJl
YWRfc2hvdWxkX3N0b3AoKSwKKwkJCXRpbWVvdXQpOworCQlpZiAodGltZW91dCA9PSAwKQorCQkJ
Z290byBwdXJnZV9nbnRfbGlzdDsKIAogCQlibGtpZi0+d2FpdGluZ19yZXFzID0gMDsKIAkJc21w
X21iKCk7IC8qIGNsZWFyIGZsYWcgKmJlZm9yZSogY2hlY2tpbmcgZm9yIHdvcmsgKi8KQEAgLTQy
MCw2ICs1MDgsMzIgQEAgaW50IHhlbl9ibGtpZl9zY2hlZHVsZSh2b2lkICphcmcpCiAJCWlmIChk
b19ibG9ja19pb19vcChibGtpZikpCiAJCQlibGtpZi0+d2FpdGluZ19yZXFzID0gMTsKIAorcHVy
Z2VfZ250X2xpc3Q6CisJCWlmIChibGtpZi0+dmJkLmZlYXR1cmVfZ250X3BlcnNpc3RlbnQgJiYK
KwkJICAgIHRpbWVfYWZ0ZXIoamlmZmllcywgYmxraWYtPm5leHRfbHJ1KSkgeworCQkJLyogQ2xl
YW4gdGhlIGxpc3Qgb2YgcGVyc2lzdGVudCBncmFudHMgKi8KKwkJCWlmIChibGtpZi0+cGVyc2lz
dGVudF9nbnRfYyA+IHhlbl9ibGtpZl9tYXhfcGdyYW50cyB8fAorCQkJICAgIChibGtpZi0+cGVy
c2lzdGVudF9nbnRfYyA9PSB4ZW5fYmxraWZfbWF4X3BncmFudHMgJiYKKwkJCSAgICAgYmxraWYt
PnZiZC5vdmVyZmxvd19tYXhfZ3JhbnRzKSkgeworCQkJCXJxX3B1cmdlID0gYmxraWYtPnBlcnNp
c3RlbnRfZ250X2MgLQorCQkJCSAgICAgICAgICAgeGVuX2Jsa2lmX21heF9wZ3JhbnRzICsKKwkJ
CQkgICAgICAgICAgIHhlbl9ibGtpZl9scnVfbnVtX2NsZWFuOworCQkJCXJxX3B1cmdlID0gcnFf
cHVyZ2UgPiBibGtpZi0+cGVyc2lzdGVudF9nbnRfYyA/CisJCQkJICAgICAgICAgICBibGtpZi0+
cGVyc2lzdGVudF9nbnRfYyA6IHJxX3B1cmdlOworCQkJCXB1cmdlZCA9IHB1cmdlX3BlcnNpc3Rl
bnRfZ250KAorCQkJCQkgICZibGtpZi0+cGVyc2lzdGVudF9nbnRzLCBycV9wdXJnZSk7CisJCQkJ
aWYgKHB1cmdlZCAhPSBycV9wdXJnZSkKKwkJCQkJcHJfZGVidWcoRFJWX1BGWCAiIHVuYWJsZSB0
byBtZWV0IHBlcnNpc3RlbnQgZ3JhbnRzIHB1cmdlIHJlcXVpcmVtZW50cyBmb3IgZGV2aWNlICUj
eCwgZG9tYWluICV1LCByZXF1ZXN0ZWQgJWQgZG9uZSAlZFxuIiwKKwkJCQkJICAgICAgICAgYmxr
aWYtPmRvbWlkLAorCQkJCQkgICAgICAgICBibGtpZi0+dmJkLmhhbmRsZSwKKwkJCQkJICAgICAg
ICAgcnFfcHVyZ2UsIHB1cmdlZCk7CisJCQkJYmxraWYtPnBlcnNpc3RlbnRfZ250X2MgLT0gcHVy
Z2VkOworCQkJCWJsa2lmLT52YmQub3ZlcmZsb3dfbWF4X2dyYW50cyA9IDA7CisJCQl9CisJCQli
bGtpZi0+bmV4dF9scnUgPSBqaWZmaWVzICsKKwkJCSAgICAgICAgbXNlY3NfdG9famlmZmllcyh4
ZW5fYmxraWZfbHJ1X2ludGVydmFsKTsKKwkJfQorCiAJCWlmIChsb2dfc3RhdHMgJiYgdGltZV9h
ZnRlcihqaWZmaWVzLCBibGtpZi0+c3RfcHJpbnQpKQogCQkJcHJpbnRfc3RhdHMoYmxraWYpOwog
CX0KQEAgLTQ1MywxMyArNTY3LDE4IEBAIHN0YXRpYyB2b2lkIHhlbl9ibGtia191bm1hcChzdHJ1
Y3QgcGVuZGluZ19yZXEgKnJlcSkKIHsKIAlzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiB1
bm1hcFtCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwogCXN0cnVjdCBwYWdlICpwYWdl
c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOworCXN0cnVjdCBwZXJzaXN0ZW50X2du
dCAqcGVyc2lzdGVudF9nbnQ7CiAJdW5zaWduZWQgaW50IGksIGludmNvdW50ID0gMDsKIAlncmFu
dF9oYW5kbGVfdCBoYW5kbGU7CiAJaW50IHJldDsKIAogCWZvciAoaSA9IDA7IGkgPCByZXEtPm5y
X3BhZ2VzOyBpKyspIHsKLQkJaWYgKCF0ZXN0X2JpdChpLCByZXEtPnVubWFwX3NlZykpCisJCWlm
IChyZXEtPnBlcnNpc3RlbnRfZ250c1tpXSAhPSBOVUxMKSB7CisJCQlwZXJzaXN0ZW50X2dudCA9
IHJlcS0+cGVyc2lzdGVudF9nbnRzW2ldOworCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzIHw9IFBF
UlNJU1RFTlRfR05UX1VTRUQ7CisJCQlwZXJzaXN0ZW50X2dudC0+ZmxhZ3MgJj0gflBFUlNJU1RF
TlRfR05UX0FDVElWRTsKIAkJCWNvbnRpbnVlOworCQl9CiAJCWhhbmRsZSA9IHBlbmRpbmdfaGFu
ZGxlKHJlcSwgaSk7CiAJCWlmIChoYW5kbGUgPT0gQkxLQkFDS19JTlZBTElEX0hBTkRMRSkKIAkJ
CWNvbnRpbnVlOwpAQCAtNDgwLDggKzU5OSw4IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChz
dHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJIHN0cnVjdCBwYWdlICpwYWdlc1tdKQogewog
CXN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiBtYXBbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUXTsKLQlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKnBlcnNpc3RlbnRfZ250c1tCTEtJRl9N
QVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwogCXN0cnVjdCBwYWdlICpwYWdlc190b19nbnRbQkxL
SUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKipw
ZXJzaXN0ZW50X2dudHMgPSBwZW5kaW5nX3JlcS0+cGVyc2lzdGVudF9nbnRzOwogCXN0cnVjdCBw
ZXJzaXN0ZW50X2dudCAqcGVyc2lzdGVudF9nbnQgPSBOVUxMOwogCXN0cnVjdCB4ZW5fYmxraWYg
KmJsa2lmID0gcGVuZGluZ19yZXEtPmJsa2lmOwogCXBoeXNfYWRkcl90IGFkZHIgPSAwOwpAQCAt
NDk0LDkgKzYxMyw2IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVx
dWVzdCAqcmVxLAogCiAJdXNlX3BlcnNpc3RlbnRfZ250cyA9IChibGtpZi0+dmJkLmZlYXR1cmVf
Z250X3BlcnNpc3RlbnQpOwogCi0JQlVHX09OKGJsa2lmLT5wZXJzaXN0ZW50X2dudF9jID4KLQkJ
ICAgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhwZW5kaW5nX3JlcS0+YmxraWYtPmJsa19wcm90b2Nv
bCkpOwotCiAJLyoKIAkgKiBGaWxsIG91dCBwcmVxLm5yX3NlY3RzIHdpdGggcHJvcGVyIGFtb3Vu
dCBvZiBzZWN0b3JzLCBhbmQgc2V0dXAKIAkgKiBhc3NpZ24gbWFwWy4uXSB3aXRoIHRoZSBQRk4g
b2YgdGhlIHBhZ2UgaW4gb3VyIGRvbWFpbiB3aXRoIHRoZQpAQCAtNTE2LDkgKzYzMiw5IEBAIHN0
YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJICog
dGhlIGdyYW50IGlzIGFscmVhZHkgbWFwcGVkCiAJCQkgKi8KIAkJCW5ld19tYXAgPSBmYWxzZTsK
KwkJCXBlcnNpc3RlbnRfZ250LT5mbGFncyB8PSBQRVJTSVNURU5UX0dOVF9BQ1RJVkU7CiAJCX0g
ZWxzZSBpZiAodXNlX3BlcnNpc3RlbnRfZ250cyAmJgotCQkJICAgYmxraWYtPnBlcnNpc3RlbnRf
Z250X2MgPAotCQkJICAgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhibGtpZi0+YmxrX3Byb3RvY29s
KSkgeworCQkJICAgYmxraWYtPnBlcnNpc3RlbnRfZ250X2MgPCB4ZW5fYmxraWZfbWF4X3BncmFu
dHMpIHsKIAkJCS8qCiAJCQkgKiBXZSBhcmUgdXNpbmcgcGVyc2lzdGVudCBncmFudHMsIHRoZSBn
cmFudCBpcwogCQkJICogbm90IG1hcHBlZCBidXQgd2UgaGF2ZSByb29tIGZvciBpdApAQCAtNTM2
LDYgKzY1Miw3IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVz
dCAqcmVxLAogCQkJfQogCQkJcGVyc2lzdGVudF9nbnQtPmdudCA9IHJlcS0+dS5ydy5zZWdbaV0u
Z3JlZjsKIAkJCXBlcnNpc3RlbnRfZ250LT5oYW5kbGUgPSBCTEtCQUNLX0lOVkFMSURfSEFORExF
OworCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzID0gUEVSU0lTVEVOVF9HTlRfQUNUSVZFOwogCiAJ
CQlwYWdlc190b19nbnRbc2Vnc190b19tYXBdID0KIAkJCQlwZXJzaXN0ZW50X2dudC0+cGFnZTsK
QEAgLTU0Nyw3ICs2NjQsNyBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKnJlcSwKIAkJCWJsa2lmLT5wZXJzaXN0ZW50X2dudF9jKys7CiAJCQlwcl9kZWJ1
ZyhEUlZfUEZYICIgZ3JhbnQgJXUgYWRkZWQgdG8gdGhlIHRyZWUgb2YgcGVyc2lzdGVudCBncmFu
dHMsIHVzaW5nICV1LyV1XG4iLAogCQkJCSBwZXJzaXN0ZW50X2dudC0+Z250LCBibGtpZi0+cGVy
c2lzdGVudF9nbnRfYywKLQkJCQkgbWF4X21hcHBlZF9ncmFudF9wYWdlcyhibGtpZi0+YmxrX3By
b3RvY29sKSk7CisJCQkJIHhlbl9ibGtpZl9tYXhfcGdyYW50cyk7CiAJCX0gZWxzZSB7CiAJCQkv
KgogCQkJICogV2UgYXJlIGVpdGhlciB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQKQEAgLTU1
Nyw3ICs2NzQsNyBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lmX3JlcXVl
c3QgKnJlcSwKIAkJCWlmICh1c2VfcGVyc2lzdGVudF9nbnRzICYmCiAJCQkJIWJsa2lmLT52YmQu
b3ZlcmZsb3dfbWF4X2dyYW50cykgewogCQkJCWJsa2lmLT52YmQub3ZlcmZsb3dfbWF4X2dyYW50
cyA9IDE7Ci0JCQkJcHJfYWxlcnQoRFJWX1BGWCAiIGRvbWFpbiAldSwgZGV2aWNlICUjeCBpcyB1
c2luZyBtYXhpbXVtIG51bWJlciBvZiBwZXJzaXN0ZW50IGdyYW50c1xuIiwKKwkJCQlwcl9kZWJ1
ZyhEUlZfUEZYICIgZG9tYWluICV1LCBkZXZpY2UgJSN4IGlzIHVzaW5nIG1heGltdW0gbnVtYmVy
IG9mIHBlcnNpc3RlbnQgZ3JhbnRzXG4iLAogCQkJCQkgYmxraWYtPmRvbWlkLCBibGtpZi0+dmJk
LmhhbmRsZSk7CiAJCQl9CiAJCQluZXdfbWFwID0gdHJ1ZTsKQEAgLTU5NSw3ICs3MTIsNiBAQCBz
dGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lmX3JlcXVlc3QgKnJlcSwKIAkgKiBz
byB0aGF0IHdoZW4gd2UgYWNjZXNzIHZhZGRyKHBlbmRpbmdfcmVxLGkpIGl0IGhhcyB0aGUgY29u
dGVudHMgb2YKIAkgKiB0aGUgcGFnZSBmcm9tIHRoZSBvdGhlciBkb21haW4uCiAJICovCi0JYml0
bWFwX3plcm8ocGVuZGluZ19yZXEtPnVubWFwX3NlZywgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUKTsKIAlmb3IgKGkgPSAwLCBqID0gMDsgaSA8IG5zZWc7IGkrKykgewogCQlpZiAoIXBl
cnNpc3RlbnRfZ250c1tpXSB8fAogCQkgICAgcGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGUgPT0g
QkxLQkFDS19JTlZBTElEX0hBTkRMRSkgewpAQCAtNjM0LDcgKzc1MCw2IEBAIHN0YXRpYyBpbnQg
eGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJCShyZXEtPnUucncu
c2VnW2ldLmZpcnN0X3NlY3QgPDwgOSk7CiAJCX0gZWxzZSB7CiAJCQlwZW5kaW5nX2hhbmRsZShw
ZW5kaW5nX3JlcSwgaSkgPSBtYXBbal0uaGFuZGxlOwotCQkJYml0bWFwX3NldChwZW5kaW5nX3Jl
cS0+dW5tYXBfc2VnLCBpLCAxKTsKIAogCQkJaWYgKHJldCkgewogCQkJCWorKzsKZGlmZiAtLWdp
dCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9uLmggYi9kcml2ZXJzL2Jsb2NrL3hl
bi1ibGtiYWNrL2NvbW1vbi5oCmluZGV4IGYzMzhmOGEuLmJkNDRkNzUgMTAwNjQ0Ci0tLSBhL2Ry
aXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9uLmgKKysrIGIvZHJpdmVycy9ibG9jay94ZW4t
YmxrYmFjay9jb21tb24uaApAQCAtMTY3LDExICsxNjcsMTQgQEAgc3RydWN0IHhlbl92YmQgewog
CiBzdHJ1Y3QgYmFja2VuZF9pbmZvOwogCisjZGVmaW5lIFBFUlNJU1RFTlRfR05UX0FDVElWRQkw
eDEKKyNkZWZpbmUgUEVSU0lTVEVOVF9HTlRfVVNFRAkJMHgyCiAKIHN0cnVjdCBwZXJzaXN0ZW50
X2dudCB7CiAJc3RydWN0IHBhZ2UgKnBhZ2U7CiAJZ3JhbnRfcmVmX3QgZ250OwogCWdyYW50X2hh
bmRsZV90IGhhbmRsZTsKKwl1aW50OF90IGZsYWdzOwogCXN0cnVjdCByYl9ub2RlIG5vZGU7CiB9
OwogCkBAIC0yMDQsNiArMjA3LDcgQEAgc3RydWN0IHhlbl9ibGtpZiB7CiAJLyogdHJlZSB0byBz
dG9yZSBwZXJzaXN0ZW50IGdyYW50cyAqLwogCXN0cnVjdCByYl9yb290CQlwZXJzaXN0ZW50X2du
dHM7CiAJdW5zaWduZWQgaW50CQlwZXJzaXN0ZW50X2dudF9jOworCXVuc2lnbmVkIGxvbmcJCW5l
eHRfbHJ1OwogCiAJLyogc3RhdGlzdGljcyAqLwogCXVuc2lnbmVkIGxvbmcJCXN0X3ByaW50Owpk
aWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyBiL2RyaXZlcnMv
YmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKaW5kZXggNWUyMzdmNi4uYWJiMzk5YSAxMDA2NDQK
LS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYworKysgYi9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCkBAIC0xMTYsNiArMTE2LDcgQEAgc3RhdGljIHN0cnVj
dCB4ZW5fYmxraWYgKnhlbl9ibGtpZl9hbGxvYyhkb21pZF90IGRvbWlkKQogCWluaXRfY29tcGxl
dGlvbigmYmxraWYtPmRyYWluX2NvbXBsZXRlKTsKIAlhdG9taWNfc2V0KCZibGtpZi0+ZHJhaW4s
IDApOwogCWJsa2lmLT5zdF9wcmludCA9IGppZmZpZXM7CisJYmxraWYtPm5leHRfbHJ1ID0gamlm
ZmllczsKIAlpbml0X3dhaXRxdWV1ZV9oZWFkKCZibGtpZi0+d2FpdGluZ190b19mcmVlKTsKIAli
bGtpZi0+cGVyc2lzdGVudF9nbnRzLnJiX25vZGUgPSBOVUxMOwogCi0tIAoxLjcuNy41IChBcHBs
ZSBHaXQtMjYpCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8v
bGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k4-0005mr-F1; Thu, 28 Feb 2013 10:29: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 1UB0k3-0005mY-Gz
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:35 +0000
Received: from [193.109.254.147:36315] by server-2.bemta-14.messagelabs.com id
	6B/56-16277-E813F215; Thu, 28 Feb 2013 10:29:34 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1280 invoked from network); 28 Feb 2013 10:29:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:35 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:34 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:43 +0100
Message-ID: <1362047335-26402-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 RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 contains the initial implementation of indirect 
descriptors for Linux blkback/blkfront.

Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.

Patch 6 contains a LRU implementation for blkback that will be needed 
when using indirect descriptors (since we are no longer able to map 
all possible grants blkfront might use).

Patch 7 is an addition to the print stats function in blkback in order 
to print information regarding persistent grant usage.

Patches 8, 9, 10 and 11 are preparatory work for indirect descriptors 
implementation, mainly make blkback use dynamic memory and remove the 
shared blkbk structure, so each blkback instance has it's own list of 
free requests, pages, handles and so on.

Finally patch 12 contains the indirect descriptors implementation.

I've also pushed this series to the following git repository:

git://xenbits.xen.org/people/royger/linux.git xen-block-indirect

Performance benefit of this series can be seen in the following graph:

http://xenbits.xen.org/people/royger/plot_indirect.png

Thanks for the review, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k6-0005nq-Kv; Thu, 28 Feb 2013 10:29: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 1UB0k4-0005ml-Mi
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:36 +0000
Received: from [193.109.254.147:32414] by server-13.bemta-14.messagelabs.com
	id 6C/1B-30639-0913F215; Thu, 28 Feb 2013 10:29:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!4
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1383 invoked from network); 28 Feb 2013 10:29:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:36 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:35 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:46 +0100
Message-ID: <1362047335-26402-4-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 03/12] xen-blkfront: switch from llist to
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UmVwbGFjZSB0aGUgdXNlIG9mIGxsaXN0IHdpdGggbGlzdC4KCmxsaXN0X2Zvcl9lYWNoX2VudHJ5
X3NhZmUgY2FuIHRyaWdnZXIgYSBidWcgaW4gR0NDIDQuMSwgc28gaXQncyBiZXN0CnRvIHJlbW92
ZSBpdCBhbmQgdXNlIGEgZG91Ymx5IGxpbmtlZCBsaXN0LCB3aGljaCBpcyB1c2VkIGV4dGVuc2l2
ZWx5CmluIHRoZSBrZXJuZWwgYWxyZWFkeS4KClNwZWNpZmljYWxseSB0aGlzIGJ1ZyBjYW4gYmUg
dHJpZ2dlcmVkIGJ5IGhvdC11bnBsdWdnaW5nIGEgZGlzaywKZWl0aGVyIGJ5IGRvaW5nIHhtIGJs
b2NrLWRldGFjaCBvciBieSBzYXZlL3Jlc3RvcmUgY3ljbGUuCgpCVUc6IHVuYWJsZSB0byBoYW5k
bGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZmZmZmZmZmZmZmZjAKSVA6IFs8ZmZmZmZm
ZmZhMDA0NzIyMz5dIGJsa2lmX2ZyZWUrMHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpUaGUgY3Jh
c2ggY2FsbCB0cmFjZSBpczoKCS4uLgpiYWRfYXJlYV9ub3NlbWFwaG9yZSsweDEzLzB4MjAKZG9f
cGFnZV9mYXVsdCsweDI1ZS8weDRiMApwYWdlX2ZhdWx0KzB4MjUvMHgzMAo/IGJsa2lmX2ZyZWUr
MHg2My8weDEzMCBbeGVuX2Jsa2Zyb250XQpibGtmcm9udF9yZXN1bWUrMHg0Ni8weGEwIFt4ZW5f
YmxrZnJvbnRdCnhlbmJ1c19kZXZfcmVzdW1lKzB4NmMvMHgxNDAKcG1fb3ArMHgxOTIvMHgxYjAK
ZGV2aWNlX3Jlc3VtZSsweDgyLzB4MWUwCmRwbV9yZXN1bWUrMHhjOS8weDFhMApkcG1fcmVzdW1l
X2VuZCsweDE1LzB4MzAKZG9fc3VzcGVuZCsweDExNy8weDFlMAoKV2hlbiBkcmlsbGluZyBkb3du
IHRvIHRoZSBhc3NlbWJsZXIgY29kZSwgb24gbmV3ZXIgR0NDIGl0IGRvZXMKLkwyOToKICAgICAg
ICBjbXBxICAgICQtMTYsICVyMTIgICAgICAjLCBwZXJzaXN0ZW50X2dudCBjaGVjawogICAgICAg
IGplICAgICAgLkwzMCAgICAJIywgb3V0IG9mIHRoZSBsb29wCi5MMjU6CgkuLi4gY29kZSBpbiB0
aGUgbG9vcAogICAgICAgIHRlc3RxICAgJXIxMywgJXIxMyAgICAgICMgbgogICAgICAgIGplICAg
ICAgLkwyOSAgICAJIywgYmFjayB0byB0aGUgdG9wIG9mIHRoZSBsb29wCiAgICAgICAgY21wcSAg
ICAkLTE2LCAlcjEyICAgICAgIywgcGVyc2lzdGVudF9nbnQgY2hlY2sKICAgICAgICBtb3ZxICAg
IDE2KCVyMTIpLCAlcjEzICAjIDx2YXJpYWJsZT4ubm9kZS5uZXh0LCBuCiAgICAgICAgam5lICAg
ICAuTDI1ICAgIAkjLAliYWNrIHRvIHRoZSB0b3Agb2YgdGhlIGxvb3AKLkwzMDoKCldoaWxlIG9u
IEdDQyA0LjEsIGl0IGlzOgpMNzg6CgkuLi4gY29kZSBpbiB0aGUgbG9vcAoJdGVzdHEgICAlcjEz
LCAlcjEzICAgICAgIyBuCiAgICAgICAgamUgICAgICAuTDc4ICAgICMsCWJhY2sgdG8gdGhlIHRv
cCBvZiB0aGUgbG9vcAogICAgICAgIG1vdnEgICAgMTYoJXJieCksICVyMTMgICMgPHZhcmlhYmxl
Pi5ub2RlLm5leHQsIG4KICAgICAgICBqbXAgICAgIC5MNzggICAgIywJYmFjayB0byB0aGUgdG9w
IG9mIHRoZSBsb29wCgpXaGljaCBiYXNpY2FsbHkgbWVhbnMgdGhhdCB0aGUgZXhpdCBsb29wIGNv
bmRpdGlvbiBpbnN0ZWFkIG9mCmJlaW5nOgoKCSYocG9zKS0+bWVtYmVyICE9IE5VTEw7CgppczoK
CTsKCndoaWNoIG1ha2VzIHRoZSBsb29wIHVuYm91bmQuCgpTaW5jZSB3ZSBhbHdheXMgbWFuaXB1
bGF0ZSB0aGUgbGlzdCB3aGlsZSBob2xkaW5nIHRoZSBpb19sb2NrLCB0aGVyZSdzCm5vIG5lZWQg
Zm9yIGFkZGl0aW9uYWwgbG9ja2luZyAobGxpc3QgdXNlZCBwcmV2aW91c2x5IGlzIHNhZmUgdG8g
dXNlCmNvbmN1cnJlbnRseSB3aXRob3V0IGFkZGl0aW9uYWwgbG9ja2luZykuCgpTaG91bGQgYmUg
YmFja3BvcnRlZCB0byAzLjggc3RhYmxlLgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7D
qSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CltQYXJ0IG9mIHRoZSBkZXNjcmlwdGlvbl0KU2lnbmVk
LW9mZi1ieTogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgpD
YzogeGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9u
dC5jIHwgICA0MSArKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogMSBm
aWxlcyBjaGFuZ2VkLCAxOCBpbnNlcnRpb25zKCspLCAyMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1n
aXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9jay94ZW4tYmxr
ZnJvbnQuYwppbmRleCBjM2RhZTJlLi4yZTM5ZWFmIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2Nr
L3hlbi1ibGtmcm9udC5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKQEAgLTQ0
LDcgKzQ0LDcgQEAKICNpbmNsdWRlIDxsaW51eC9tdXRleC5oPgogI2luY2x1ZGUgPGxpbnV4L3Nj
YXR0ZXJsaXN0Lmg+CiAjaW5jbHVkZSA8bGludXgvYml0bWFwLmg+Ci0jaW5jbHVkZSA8bGludXgv
bGxpc3QuaD4KKyNpbmNsdWRlIDxsaW51eC9saXN0Lmg+CiAKICNpbmNsdWRlIDx4ZW4veGVuLmg+
CiAjaW5jbHVkZSA8eGVuL3hlbmJ1cy5oPgpAQCAtNjgsNyArNjgsNyBAQCBlbnVtIGJsa2lmX3N0
YXRlIHsKIHN0cnVjdCBncmFudCB7CiAJZ3JhbnRfcmVmX3QgZ3JlZjsKIAl1bnNpZ25lZCBsb25n
IHBmbjsKLQlzdHJ1Y3QgbGxpc3Rfbm9kZSBub2RlOworCXN0cnVjdCBsaXN0X2hlYWQgbm9kZTsK
IH07CiAKIHN0cnVjdCBibGtfc2hhZG93IHsKQEAgLTEwNSw3ICsxMDUsNyBAQCBzdHJ1Y3QgYmxr
ZnJvbnRfaW5mbwogCXN0cnVjdCB3b3JrX3N0cnVjdCB3b3JrOwogCXN0cnVjdCBnbnR0YWJfZnJl
ZV9jYWxsYmFjayBjYWxsYmFjazsKIAlzdHJ1Y3QgYmxrX3NoYWRvdyBzaGFkb3dbQkxLX1JJTkdf
U0laRV07Ci0Jc3RydWN0IGxsaXN0X2hlYWQgcGVyc2lzdGVudF9nbnRzOworCXN0cnVjdCBsaXN0
X2hlYWQgcGVyc2lzdGVudF9nbnRzOwogCXVuc2lnbmVkIGludCBwZXJzaXN0ZW50X2dudHNfYzsK
IAl1bnNpZ25lZCBsb25nIHNoYWRvd19mcmVlOwogCXVuc2lnbmVkIGludCBmZWF0dXJlX2ZsdXNo
OwpAQCAtMzcxLDEwICszNzEsMTEgQEAgc3RhdGljIGludCBibGtpZl9xdWV1ZV9yZXF1ZXN0KHN0
cnVjdCByZXF1ZXN0ICpyZXEpCiAJCQlsc2VjdCA9IGZzZWN0ICsgKHNnLT5sZW5ndGggPj4gOSkg
LSAxOwogCiAJCQlpZiAoaW5mby0+cGVyc2lzdGVudF9nbnRzX2MpIHsKLQkJCQlCVUdfT04obGxp
c3RfZW1wdHkoJmluZm8tPnBlcnNpc3RlbnRfZ250cykpOwotCQkJCWdudF9saXN0X2VudHJ5ID0g
bGxpc3RfZW50cnkoCi0JCQkJCWxsaXN0X2RlbF9maXJzdCgmaW5mby0+cGVyc2lzdGVudF9nbnRz
KSwKLQkJCQkJc3RydWN0IGdyYW50LCBub2RlKTsKKwkJCQlCVUdfT04obGlzdF9lbXB0eSgmaW5m
by0+cGVyc2lzdGVudF9nbnRzKSk7CisJCQkJZ250X2xpc3RfZW50cnkgPSBsaXN0X2ZpcnN0X2Vu
dHJ5KAorCQkJCSAgICAgICAgICAgICAgICAgICAgICAmaW5mby0+cGVyc2lzdGVudF9nbnRzLAor
CQkJCSAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgZ3JhbnQsIG5vZGUpOworCQkJCWxpc3Rf
ZGVsKCZnbnRfbGlzdF9lbnRyeS0+bm9kZSk7CiAKIAkJCQlyZWYgPSBnbnRfbGlzdF9lbnRyeS0+
Z3JlZjsKIAkJCQlidWZmZXJfbWZuID0gcGZuX3RvX21mbihnbnRfbGlzdF9lbnRyeS0+cGZuKTsK
QEAgLTc5MCw5ICs3OTEsOCBAQCBzdGF0aWMgdm9pZCBibGtpZl9yZXN0YXJ0X3F1ZXVlKHN0cnVj
dCB3b3JrX3N0cnVjdCAqd29yaykKIAogc3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxr
ZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiB7Ci0Jc3RydWN0IGxsaXN0X25vZGUgKmFs
bF9nbnRzOwotCXN0cnVjdCBncmFudCAqcGVyc2lzdGVudF9nbnQsICp0bXA7Ci0Jc3RydWN0IGxs
aXN0X25vZGUgKm47CisJc3RydWN0IGdyYW50ICpwZXJzaXN0ZW50X2dudDsKKwlzdHJ1Y3QgZ3Jh
bnQgKm47CiAKIAkvKiBQcmV2ZW50IG5ldyByZXF1ZXN0cyBiZWluZyBpc3N1ZWQgdW50aWwgd2Ug
Zml4IHRoaW5ncyB1cC4gKi8KIAlzcGluX2xvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKQEAgLTgw
NCwyMCArODA0LDE1IEBAIHN0YXRpYyB2b2lkIGJsa2lmX2ZyZWUoc3RydWN0IGJsa2Zyb250X2lu
Zm8gKmluZm8sIGludCBzdXNwZW5kKQogCiAJLyogUmVtb3ZlIGFsbCBwZXJzaXN0ZW50IGdyYW50
cyAqLwogCWlmIChpbmZvLT5wZXJzaXN0ZW50X2dudHNfYykgewotCQlhbGxfZ250cyA9IGxsaXN0
X2RlbF9hbGwoJmluZm8tPnBlcnNpc3RlbnRfZ250cyk7Ci0JCXBlcnNpc3RlbnRfZ250ID0gbGxp
c3RfZW50cnkoYWxsX2dudHMsIHR5cGVvZigqKHBlcnNpc3RlbnRfZ250KSksIG5vZGUpOwotCQl3
aGlsZSAocGVyc2lzdGVudF9nbnQpIHsKKwkJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHBlcnNp
c3RlbnRfZ250LCBuLAorCQkgICAgICAgICAgICAgICAgICAgICAgICAgJmluZm8tPnBlcnNpc3Rl
bnRfZ250cywgbm9kZSkgeworCQkJbGlzdF9kZWwoJnBlcnNpc3RlbnRfZ250LT5ub2RlKTsKIAkJ
CWdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3MocGVyc2lzdGVudF9nbnQtPmdyZWYsIDAsIDBVTCk7
CiAJCQlfX2ZyZWVfcGFnZShwZm5fdG9fcGFnZShwZXJzaXN0ZW50X2dudC0+cGZuKSk7Ci0JCQl0
bXAgPSBwZXJzaXN0ZW50X2dudDsKLQkJCW4gPSBwZXJzaXN0ZW50X2dudC0+bm9kZS5uZXh0Owot
CQkJaWYgKG4pCi0JCQkJcGVyc2lzdGVudF9nbnQgPSBsbGlzdF9lbnRyeShuLCB0eXBlb2YoKihw
ZXJzaXN0ZW50X2dudCkpLCBub2RlKTsKLQkJCWVsc2UKLQkJCQlwZXJzaXN0ZW50X2dudCA9IE5V
TEw7Ci0JCQlrZnJlZSh0bXApOworCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOworCQkJaW5mby0+
cGVyc2lzdGVudF9nbnRzX2MtLTsKIAkJfQotCQlpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyA9IDA7
CisJCUJVR19PTihpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyAhPSAwKTsKIAl9CiAKIAkvKiBObyBt
b3JlIGdudHRhYiBjYWxsYmFjayB3b3JrLiAqLwpAQCAtODc1LDcgKzg3MCw3IEBAIHN0YXRpYyB2
b2lkIGJsa2lmX2NvbXBsZXRpb24oc3RydWN0IGJsa19zaGFkb3cgKnMsIHN0cnVjdCBibGtmcm9u
dF9pbmZvICppbmZvLAogCX0KIAkvKiBBZGQgdGhlIHBlcnNpc3RlbnQgZ3JhbnQgaW50byB0aGUg
bGlzdCBvZiBmcmVlIGdyYW50cyAqLwogCWZvciAoaSA9IDA7IGkgPCBzLT5yZXEudS5ydy5ucl9z
ZWdtZW50czsgaSsrKSB7Ci0JCWxsaXN0X2FkZCgmcy0+Z3JhbnRzX3VzZWRbaV0tPm5vZGUsICZp
bmZvLT5wZXJzaXN0ZW50X2dudHMpOworCQlsaXN0X2FkZCgmcy0+Z3JhbnRzX3VzZWRbaV0tPm5v
ZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCQlpbmZvLT5wZXJzaXN0ZW50X2dudHNfYysr
OwogCX0KIH0KQEAgLTExNzEsNyArMTE2Niw3IEBAIHN0YXRpYyBpbnQgYmxrZnJvbnRfcHJvYmUo
c3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwKIAlzcGluX2xvY2tfaW5pdCgmaW5mby0+aW9fbG9j
ayk7CiAJaW5mby0+eGJkZXYgPSBkZXY7CiAJaW5mby0+dmRldmljZSA9IHZkZXZpY2U7Ci0JaW5p
dF9sbGlzdF9oZWFkKCZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOworCUlOSVRfTElTVF9IRUFEKCZp
bmZvLT5wZXJzaXN0ZW50X2dudHMpOwogCWluZm8tPnBlcnNpc3RlbnRfZ250c19jID0gMDsKIAlp
bmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFURV9ESVNDT05ORUNURUQ7CiAJSU5JVF9XT1JLKCZp
bmZvLT53b3JrLCBibGtpZl9yZXN0YXJ0X3F1ZXVlKTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0y
NikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k5-0005nI-Rt; Thu, 28 Feb 2013 10:29: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 1UB0k3-0005ma-Ud
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:36 +0000
Received: from [193.109.254.147:36328] by server-1.bemta-14.messagelabs.com id
	A3/77-29874-F813F215; Thu, 28 Feb 2013 10:29:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!2
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1301 invoked from network); 28 Feb 2013 10:29:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:34 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:35 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:34 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:44 +0100
Message-ID: <1362047335-26402-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 01/12] xen-blkback: don't store dev_bus_addr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

ZGV2X2J1c19hZGRyIHJldHVybmVkIGluIHRoZSBncmFudCByZWYgbWFwIG9wZXJhdGlvbiBpcyB0
aGUgbWZuIG9mIHRoZQpwYXNzZWQgcGFnZSwgdGhlcmUncyBubyBuZWVkIHRvIHN0b3JlIGl0IGlu
IHRoZSBwZXJzaXN0ZW50IGdyYW50CmVudHJ5LCBzaW5jZSB3ZSBjYW4gYWx3YXlzIGdldCBpdCBw
cm92aWRlZCB0aGF0IHdlIGhhdmUgdGhlIHBhZ2UuCgpUaGlzIHJlZHVjZXMgdGhlIG1lbW9yeSBv
dmVyaGVhZCBvZiBwZXJzaXN0ZW50IGdyYW50cyBpbiBibGtiYWNrLgoKU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25yYWQgUnplc3p1
dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgICAgNyArKyst
LS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oICB8ICAgIDEgLQogMiBmaWxl
cyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1i
bGtiYWNrL2Jsa2JhY2suYwppbmRleCBkZTFmMzE5Li5kNDBiZWIzIDEwMDY0NAotLS0gYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1i
bGtiYWNrL2Jsa2JhY2suYwpAQCAtNjIxLDkgKzYyMSw3IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2Jr
X21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJCSAqIElmIHRoaXMgaXMgYSBuZXcg
cGVyc2lzdGVudCBncmFudAogCQkJCSAqIHNhdmUgdGhlIGhhbmRsZXIKIAkJCQkgKi8KLQkJCQlw
ZXJzaXN0ZW50X2dudHNbaV0tPmhhbmRsZSA9IG1hcFtqXS5oYW5kbGU7Ci0JCQkJcGVyc2lzdGVu
dF9nbnRzW2ldLT5kZXZfYnVzX2FkZHIgPQotCQkJCQltYXBbaisrXS5kZXZfYnVzX2FkZHI7CisJ
CQkJcGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGUgPSBtYXBbaisrXS5oYW5kbGU7CiAJCQl9CiAJ
CQlwZW5kaW5nX2hhbmRsZShwZW5kaW5nX3JlcSwgaSkgPQogCQkJCXBlcnNpc3RlbnRfZ250c1tp
XS0+aGFuZGxlOwpAQCAtNjMxLDcgKzYyOSw4IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChz
dHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCQkJaWYgKHJldCkKIAkJCQljb250aW51ZTsKIAot
CQkJc2VnW2ldLmJ1ZiA9IHBlcnNpc3RlbnRfZ250c1tpXS0+ZGV2X2J1c19hZGRyIHwKKwkJCXNl
Z1tpXS5idWYgPSBwZm5fdG9fbWZuKHBhZ2VfdG9fcGZuKAorCQkJCXBlcnNpc3RlbnRfZ250c1tp
XS0+cGFnZSkpIDw8IFBBR0VfU0hJRlQgfAogCQkJCShyZXEtPnUucncuc2VnW2ldLmZpcnN0X3Nl
Y3QgPDwgOSk7CiAJCX0gZWxzZSB7CiAJCQlwZW5kaW5nX2hhbmRsZShwZW5kaW5nX3JlcSwgaSkg
PSBtYXBbal0uaGFuZGxlOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9j
b21tb24uaCBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9uLmgKaW5kZXggNjA3MjM5
MC4uZjMzOGY4YSAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9jb21tb24u
aAorKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCkBAIC0xNzIsNyArMTcy
LDYgQEAgc3RydWN0IHBlcnNpc3RlbnRfZ250IHsKIAlzdHJ1Y3QgcGFnZSAqcGFnZTsKIAlncmFu
dF9yZWZfdCBnbnQ7CiAJZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOwotCXVpbnQ2NF90IGRldl9idXNf
YWRkcjsKIAlzdHJ1Y3QgcmJfbm9kZSBub2RlOwogfTsKIAotLSAKMS43LjcuNSAoQXBwbGUgR2l0
LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k8-0005pB-Dg; Thu, 28 Feb 2013 10:29:40 +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 1UB0k6-0005nO-DU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:38 +0000
Received: from [193.109.254.147:32586] by server-9.bemta-14.messagelabs.com id
	EF/CE-30867-1913F215; Thu, 28 Feb 2013 10:29:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!8
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1572 invoked from network); 28 Feb 2013 10:29:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:38 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:37 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:50 +0100
Message-ID: <1362047335-26402-8-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 07/12] xen-blkback: print stats about
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

U2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNj
OiB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25y
YWQud2lsa0BvcmFjbGUuY29tPgotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFj
ay5jIHwgICAgNSArKystLQogMSBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDIgZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNr
LmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBjMTRiNzM2Li5i
NWU3NDk1IDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwor
KysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtNDYwLDEwICs0NjAs
MTEgQEAgaXJxcmV0dXJuX3QgeGVuX2Jsa2lmX2JlX2ludChpbnQgaXJxLCB2b2lkICpkZXZfaWQp
CiBzdGF0aWMgdm9pZCBwcmludF9zdGF0cyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZikKIHsKIAlw
cl9pbmZvKCJ4ZW4tYmxrYmFjayAoJXMpOiBvbyAlM2QgIHwgIHJkICU0ZCAgfCAgd3IgJTRkICB8
ICBmICU0ZCIKLQkJICIgIHwgIGRzICU0ZFxuIiwKKwkJICIgIHwgIGRzICU0ZCB8IHBnOiAlNGQv
JTRkXG4iLAogCQkgY3VycmVudC0+Y29tbSwgYmxraWYtPnN0X29vX3JlcSwKIAkJIGJsa2lmLT5z
dF9yZF9yZXEsIGJsa2lmLT5zdF93cl9yZXEsCi0JCSBibGtpZi0+c3RfZl9yZXEsIGJsa2lmLT5z
dF9kc19yZXEpOworCQkgYmxraWYtPnN0X2ZfcmVxLCBibGtpZi0+c3RfZHNfcmVxLAorCQkgYmxr
aWYtPnBlcnNpc3RlbnRfZ250X2MsIHhlbl9ibGtpZl9tYXhfcGdyYW50cyk7CiAJYmxraWYtPnN0
X3ByaW50ID0gamlmZmllcyArIG1zZWNzX3RvX2ppZmZpZXMoMTAgKiAxMDAwKTsKIAlibGtpZi0+
c3RfcmRfcmVxID0gMDsKIAlibGtpZi0+c3Rfd3JfcmVxID0gMDsKLS0gCjEuNy43LjUgKEFwcGxl
IEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k9-0005pr-78; Thu, 28 Feb 2013 10:29:41 +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 1UB0k7-0005nw-8J
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:39 +0000
Received: from [193.109.254.147:58181] by server-12.bemta-14.messagelabs.com
	id A3/86-32582-2913F215; Thu, 28 Feb 2013 10:29:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!10
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1676 invoked from network); 28 Feb 2013 10:29:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:39 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:38 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:52 +0100
Message-ID: <1362047335-26402-10-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 09/12] xen-blkback: move pending handles
	list from blkbk to pending_req
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

TW92aW5nIGdyYW50IHJlZiBoYW5kbGVzIGZyb20gYmxrYmsgdG8gcGVuZGluZ19yZXEgd2lsbCBh
bGxvdyB1cyB0bwpnZXQgcmlkIG9mIHRoZSBzaGFyZWQgYmxrYmsgc3RydWN0dXJlLgoKU2lnbmVk
LW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25y
YWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxA
bGlzdHMueGVuLm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwg
ICAxNiArKysrLS0tLS0tLS0tLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwg
MTIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9i
bGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBiYTI3
ZmMzLi5jNDNkZThhIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2Jh
Y2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtMTM2LDYg
KzEzNiw3IEBAIHN0cnVjdCBwZW5kaW5nX3JlcSB7CiAJc3RydWN0IGxpc3RfaGVhZAlmcmVlX2xp
c3Q7CiAJc3RydWN0IHBlcnNpc3RlbnRfZ250CSpwZXJzaXN0ZW50X2dudHNbQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUXTsKIAlzdHJ1Y3QgcGFnZQkJKnBhZ2VzW0JMS0lGX01BWF9TRUdN
RU5UU19QRVJfUkVRVUVTVF07CisJZ3JhbnRfaGFuZGxlX3QJCWdyYW50X2hhbmRsZXNbQkxLSUZf
TUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIH07CiAKICNkZWZpbmUgQkxLQkFDS19JTlZBTElE
X0hBTkRMRSAofjApCkBAIC0xNDcsOCArMTQ4LDYgQEAgc3RydWN0IHhlbl9ibGtiayB7CiAJLyog
QW5kIGl0cyBzcGlubG9jay4gKi8KIAlzcGlubG9ja190CQlwZW5kaW5nX2ZyZWVfbG9jazsKIAl3
YWl0X3F1ZXVlX2hlYWRfdAlwZW5kaW5nX2ZyZWVfd3E7Ci0JLyogQW5kIHRoZSBncmFudCBoYW5k
bGVzIHRoYXQgYXJlIGF2YWlsYWJsZS4gKi8KLQlncmFudF9oYW5kbGVfdAkJKnBlbmRpbmdfZ3Jh
bnRfaGFuZGxlczsKIH07CiAKIHN0YXRpYyBzdHJ1Y3QgeGVuX2Jsa2JrICpibGtiazsKQEAgLTIy
Niw3ICsyMjUsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgcmVtb3ZlX2ZyZWVfcGFnZXMoc3RydWN0
IHhlbl9ibGtpZiAqYmxraWYsIGludCBudW0pCiAjZGVmaW5lIHZhZGRyKHBhZ2UpICgodW5zaWdu
ZWQgbG9uZylwZm5fdG9fa2FkZHIocGFnZV90b19wZm4ocGFnZSkpKQogCiAjZGVmaW5lIHBlbmRp
bmdfaGFuZGxlKF9yZXEsIF9zZWcpIFwKLQkoYmxrYmstPnBlbmRpbmdfZ3JhbnRfaGFuZGxlc1t2
YWRkcl9wYWdlbnIoX3JlcSwgX3NlZyldKQorCShfcmVxLT5ncmFudF9oYW5kbGVzW19zZWddKQog
CiAKIHN0YXRpYyBpbnQgZG9fYmxvY2tfaW9fb3Aoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYpOwpA
QCAtMTIxNCw3ICsxMjEzLDcgQEAgc3RhdGljIHZvaWQgbWFrZV9yZXNwb25zZShzdHJ1Y3QgeGVu
X2Jsa2lmICpibGtpZiwgdTY0IGlkLAogCiBzdGF0aWMgaW50IF9faW5pdCB4ZW5fYmxraWZfaW5p
dCh2b2lkKQogewotCWludCBpLCBtbWFwX3BhZ2VzOworCWludCBpOwogCWludCByYyA9IDA7CiAK
IAlpZiAoIXhlbl9kb21haW4oKSkKQEAgLTEyMjYsMjEgKzEyMjUsMTUgQEAgc3RhdGljIGludCBf
X2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIAkJcmV0dXJuIC1FTk9NRU07CiAJfQogCi0JbW1h
cF9wYWdlcyA9IHhlbl9ibGtpZl9yZXFzICogQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNU
OwogCiAJYmxrYmstPnBlbmRpbmdfcmVxcyAgICAgICAgICA9IGt6YWxsb2Moc2l6ZW9mKGJsa2Jr
LT5wZW5kaW5nX3JlcXNbMF0pICoKIAkJCQkJeGVuX2Jsa2lmX3JlcXMsIEdGUF9LRVJORUwpOwot
CWJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMgPSBrbWFsbG9jKHNpemVvZihibGtiay0+cGVu
ZGluZ19ncmFudF9oYW5kbGVzWzBdKSAqCi0JCQkJCW1tYXBfcGFnZXMsIEdGUF9LRVJORUwpOwog
Ci0JaWYgKCFibGtiay0+cGVuZGluZ19yZXFzIHx8ICFibGtiay0+cGVuZGluZ19ncmFudF9oYW5k
bGVzKSB7CisJaWYgKCFibGtiay0+cGVuZGluZ19yZXFzKSB7CiAJCXJjID0gLUVOT01FTTsKIAkJ
Z290byBvdXRfb2ZfbWVtb3J5OwogCX0KIAotCWZvciAoaSA9IDA7IGkgPCBtbWFwX3BhZ2VzOyBp
KyspIHsKLQkJYmxrYmstPnBlbmRpbmdfZ3JhbnRfaGFuZGxlc1tpXSA9IEJMS0JBQ0tfSU5WQUxJ
RF9IQU5ETEU7Ci0JfQogCXJjID0geGVuX2Jsa2lmX2ludGVyZmFjZV9pbml0KCk7CiAJaWYgKHJj
KQogCQlnb3RvIGZhaWxlZF9pbml0OwpAQCAtMTI2Myw3ICsxMjU2LDYgQEAgc3RhdGljIGludCBf
X2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIAlwcl9hbGVydChEUlZfUEZYICIlczogb3V0IG9m
IG1lbW9yeVxuIiwgX19mdW5jX18pOwogIGZhaWxlZF9pbml0OgogCWtmcmVlKGJsa2JrLT5wZW5k
aW5nX3JlcXMpOwotCWtmcmVlKGJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMpOwogCWtmcmVl
KGJsa2JrKTsKIAlibGtiayA9IE5VTEw7CiAJcmV0dXJuIHJjOwotLSAKMS43LjcuNSAoQXBwbGUg
R2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k6-0005nd-8D; Thu, 28 Feb 2013 10:29: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 1UB0k4-0005mb-3I
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:36 +0000
Received: from [193.109.254.147:32346] by server-7.bemta-14.messagelabs.com id
	DB/18-13581-F813F215; Thu, 28 Feb 2013 10:29:35 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!3
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1333 invoked from network); 28 Feb 2013 10:29:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:36 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:35 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:45 +0100
Message-ID: <1362047335-26402-3-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 02/12] xen-blkback: fix foreach_grant_safe
	to handle empty lists
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

V2UgbWF5IHVzZSBmb3JlYWNoX2dyYW50X3NhZmUgaW4gdGhlIGZ1dHVyZSB3aXRoIGVtcHR5IGxp
c3RzLCBzbyBtYWtlCnN1cmUgd2UgY2FuIGhhbmRsZSB0aGVtLgoKU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29t
PgotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgICAgMiArLQogMSBm
aWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hl
bi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBkNDBiZWIzLi40MTVhMGM3IDEwMDY0NAotLS0gYS9k
cml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hl
bi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtMTY0LDcgKzE2NCw3IEBAIHN0YXRpYyB2b2lkIG1ha2Vf
cmVzcG9uc2Uoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIHU2NCBpZCwKIAogI2RlZmluZSBmb3Jl
YWNoX2dyYW50X3NhZmUocG9zLCBuLCByYnRyZWUsIG5vZGUpIFwKIAlmb3IgKChwb3MpID0gY29u
dGFpbmVyX29mKHJiX2ZpcnN0KChyYnRyZWUpKSwgdHlwZW9mKCoocG9zKSksIG5vZGUpLCBcCi0J
ICAgICAobikgPSByYl9uZXh0KCYocG9zKS0+bm9kZSk7IFwKKwkgICAgIChuKSA9ICgmKHBvcykt
Pm5vZGUgIT0gTlVMTCkgPyByYl9uZXh0KCYocG9zKS0+bm9kZSkgOiBOVUxMOyBcCiAJICAgICAm
KHBvcyktPm5vZGUgIT0gTlVMTDsgXAogCSAgICAgKHBvcykgPSBjb250YWluZXJfb2YobiwgdHlw
ZW9mKCoocG9zKSksIG5vZGUpLCBcCiAJICAgICAobikgPSAoJihwb3MpLT5ub2RlICE9IE5VTEwp
ID8gcmJfbmV4dCgmKHBvcyktPm5vZGUpIDogTlVMTCkKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0y
NikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k7-0005o3-3H; Thu, 28 Feb 2013 10:29:39 +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 1UB0k5-0005ma-8m
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:37 +0000
Received: from [193.109.254.147:32506] by server-1.bemta-14.messagelabs.com id
	5A/87-29874-1913F215; Thu, 28 Feb 2013 10:29:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!6
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1467 invoked from network); 28 Feb 2013 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:37 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:36 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:48 +0100
Message-ID: <1362047335-26402-6-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 05/12] xen-blkfront: remove frame list from
	blk_shadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

V2UgYWxyZWFkeSBoYXZlIHRoZSBmcmFtZSAocGZuIG9mIHRoZSBncmFudCBwYWdlKSBzdG9yZWQg
aW5zaWRlIHN0cnVjdApncmFudCwgc28gdGhlcmUncyBubyBuZWVkIHRvIGtlZXAgYW4gYWRpdGlv
bmFsIGxpc3Qgb2YgbWFwcGVkIGZyYW1lcwpmb3IgYSBzcGVjaWZpYyByZXF1ZXN0LiBUaGlzIHJl
ZHVjZXMgbWVtb3J5IHVzYWdlIGluIGJsa2Zyb250LgoKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1
IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsg
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwotLS0K
IGRyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMgfCAgICA2ICstLS0tLQogMSBmaWxlcyBjaGFu
Z2VkLCAxIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9ibG9jay94ZW4tYmxrZnJvbnQuYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKaW5k
ZXggNWJhNmI4Ny4uNGQ4MWZjYyAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJv
bnQuYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jCkBAIC03NCw3ICs3NCw2IEBA
IHN0cnVjdCBncmFudCB7CiBzdHJ1Y3QgYmxrX3NoYWRvdyB7CiAJc3RydWN0IGJsa2lmX3JlcXVl
c3QgcmVxOwogCXN0cnVjdCByZXF1ZXN0ICpyZXF1ZXN0OwotCXVuc2lnbmVkIGxvbmcgZnJhbWVb
QkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIAlzdHJ1Y3QgZ3JhbnQgKmdyYW50c191
c2VkW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiB9OwogCkBAIC0zNTYsNyArMzU1
LDYgQEAgc3RhdGljIGludCBibGtpZl9pb2N0bChzdHJ1Y3QgYmxvY2tfZGV2aWNlICpiZGV2LCBm
bW9kZV90IG1vZGUsCiBzdGF0aWMgaW50IGJsa2lmX3F1ZXVlX3JlcXVlc3Qoc3RydWN0IHJlcXVl
c3QgKnJlcSkKIHsKIAlzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbyA9IHJlcS0+cnFfZGlzay0+
cHJpdmF0ZV9kYXRhOwotCXVuc2lnbmVkIGxvbmcgYnVmZmVyX21mbjsKIAlzdHJ1Y3QgYmxraWZf
cmVxdWVzdCAqcmluZ19yZXE7CiAJdW5zaWduZWQgbG9uZyBpZDsKIAl1bnNpZ25lZCBpbnQgZnNl
Y3QsIGxzZWN0OwpAQCAtNDM0LDcgKzQzMiw2IEBAIHN0YXRpYyBpbnQgYmxraWZfcXVldWVfcmVx
dWVzdChzdHJ1Y3QgcmVxdWVzdCAqcmVxKQogCiAJCQlnbnRfbGlzdF9lbnRyeSA9IGdldF9ncmFu
dCgmZ3JlZl9oZWFkLCBpbmZvKTsKIAkJCXJlZiA9IGdudF9saXN0X2VudHJ5LT5ncmVmOwotCQkJ
YnVmZmVyX21mbiA9IHBmbl90b19tZm4oZ250X2xpc3RfZW50cnktPnBmbik7CiAKIAkJCWluZm8t
PnNoYWRvd1tpZF0uZ3JhbnRzX3VzZWRbaV0gPSBnbnRfbGlzdF9lbnRyeTsKIApAQCAtNDY1LDcg
KzQ2Miw2IEBAIHN0YXRpYyBpbnQgYmxraWZfcXVldWVfcmVxdWVzdChzdHJ1Y3QgcmVxdWVzdCAq
cmVxKQogCQkJCWt1bm1hcF9hdG9taWMoc2hhcmVkX2RhdGEpOwogCQkJfQogCi0JCQlpbmZvLT5z
aGFkb3dbaWRdLmZyYW1lW2ldID0gbWZuX3RvX3BmbihidWZmZXJfbWZuKTsKIAkJCXJpbmdfcmVx
LT51LnJ3LnNlZ1tpXSA9CiAJCQkJCShzdHJ1Y3QgYmxraWZfcmVxdWVzdF9zZWdtZW50KSB7CiAJ
CQkJCQkuZ3JlZiAgICAgICA9IHJlZiwKQEAgLTEyNjksNyArMTI2NSw3IEBAIHN0YXRpYyBpbnQg
YmxraWZfcmVjb3ZlcihzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbykKIAkJCQlnbnR0YWJfZ3Jh
bnRfZm9yZWlnbl9hY2Nlc3NfcmVmKAogCQkJCQlyZXEtPnUucncuc2VnW2pdLmdyZWYsCiAJCQkJ
CWluZm8tPnhiZGV2LT5vdGhlcmVuZF9pZCwKLQkJCQkJcGZuX3RvX21mbihpbmZvLT5zaGFkb3db
cmVxLT51LnJ3LmlkXS5mcmFtZVtqXSksCisJCQkJCXBmbl90b19tZm4oY29weVtpXS5ncmFudHNf
dXNlZFtqXS0+cGZuKSwKIAkJCQkJMCk7CiAJCX0KIAkJaW5mby0+c2hhZG93W3JlcS0+dS5ydy5p
ZF0ucmVxID0gKnJlcTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k9-0005qN-P7; Thu, 28 Feb 2013 10:29:41 +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 1UB0k7-0005ml-Ei
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:39 +0000
Received: from [193.109.254.147:36688] by server-13.bemta-14.messagelabs.com
	id 5D/3B-30639-3913F215; Thu, 28 Feb 2013 10:29:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!11
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1709 invoked from network); 28 Feb 2013 10:29:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:39 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:38 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:53 +0100
Message-ID: <1362047335-26402-11-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 10/12] xen-blkback: make the queue of free
	requests per backend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

UmVtb3ZlIHRoZSBsYXN0IGRlcGVuZGVuY3kgZnJvbSBibGtiayBieSBtb3ZpbmcgdGhlIGxpc3Qg
b2YgZnJlZQpyZXF1ZXN0cyB0byBibGtpZi4gVGhpcyBjaGFuZ2UgcmVkdWNlcyB0aGUgY29udGVu
dGlvbiBvbiB0aGUgbGlzdCBvZgphdmFpbGFibGUgcmVxdWVzdHMuCgpTaWduZWQtb2ZmLWJ5OiBS
b2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0
ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCi0tLQogZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgfCAgMTIzICsrKysr
KystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNr
L2NvbW1vbi5oICB8ICAgMjcgKysrKysrKysKIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVu
YnVzLmMgIHwgICAxNyArKysrKwogMyBmaWxlcyBjaGFuZ2VkLCA2NyBpbnNlcnRpb25zKCspLCAx
MDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9i
bGtiYWNrLmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBjNDNk
ZThhLi4wNGFkMmFhIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2Jh
Y2suYworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtNTAsMTgg
KzUwLDE0IEBACiAjaW5jbHVkZSAiY29tbW9uLmgiCiAKIC8qCi0gKiBUaGVzZSBhcmUgcmF0aGVy
IGFyYml0cmFyeS4gVGhleSBhcmUgZmFpcmx5IGxhcmdlIGJlY2F1c2UgYWRqYWNlbnQgcmVxdWVz
dHMKLSAqIHB1bGxlZCBmcm9tIGEgY29tbXVuaWNhdGlvbiByaW5nIGFyZSBxdWl0ZSBsaWtlbHkg
dG8gZW5kIHVwIGJlaW5nIHBhcnQgb2YKLSAqIHRoZSBzYW1lIHNjYXR0ZXIvZ2F0aGVyIHJlcXVl
c3QgYXQgdGhlIGRpc2MuCi0gKgotICogKiogVFJZIElOQ1JFQVNJTkcgJ3hlbl9ibGtpZl9yZXFz
JyBJRiBXUklURSBTUEVFRFMgU0VFTSBUT08gTE9XICoqCi0gKgotICogVGhpcyB3aWxsIGluY3Jl
YXNlIHRoZSBjaGFuY2VzIG9mIGJlaW5nIGFibGUgdG8gd3JpdGUgd2hvbGUgdHJhY2tzLgotICog
NjQgc2hvdWxkIGJlIGVub3VnaCB0byBrZWVwIHVzIGNvbXBldGl0aXZlIHdpdGggTGludXguCisg
KiBUaGlzIGlzIHRoZSBudW1iZXIgb2YgcmVxdWVzdHMgdGhhdCB3aWxsIGJlIHByZS1hbGxvY2F0
ZWQgZm9yIGVhY2ggYmFja2VuZC4KKyAqIEZvciBiZXR0ZXIgcGVyZm9ybWFuY2UgdGhpcyBpcyBz
ZXQgdG8gUklOR19TSVpFICgzMiksIHNvIHJlcXVlc3RzCisgKiBpbiB0aGUgcmluZyB3aWxsIG5l
dmVyIGhhdmUgdG8gd2FpdCBmb3IgYSBmcmVlIHBlbmRpbmdfcmVxLgogICovCi1zdGF0aWMgaW50
IHhlbl9ibGtpZl9yZXFzID0gNjQ7CisKK2ludCB4ZW5fYmxraWZfcmVxcyA9IDMyOwogbW9kdWxl
X3BhcmFtX25hbWVkKHJlcXMsIHhlbl9ibGtpZl9yZXFzLCBpbnQsIDApOwotTU9EVUxFX1BBUk1f
REVTQyhyZXFzLCAiTnVtYmVyIG9mIGJsa2JhY2sgcmVxdWVzdHMgdG8gYWxsb2NhdGUiKTsKK01P
RFVMRV9QQVJNX0RFU0MocmVxcywgIk51bWJlciBvZiBibGtiYWNrIHJlcXVlc3RzIHRvIGFsbG9j
YXRlIHBlciBiYWNrZW5kIik7CiAKIC8qCiAgKiBNYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8g
bWFwIHBlcnNpc3RlbnRseSBpbiBibGtiYWNrLiBGb3IgbWF4aW11bQpAQCAtMTIwLDUwICsxMTYs
OCBAQCBNT0RVTEVfUEFSTV9ERVNDKG1heF9idWZmZXJfcGFnZXMsCiBzdGF0aWMgdW5zaWduZWQg
aW50IGxvZ19zdGF0czsKIG1vZHVsZV9wYXJhbShsb2dfc3RhdHMsIGludCwgMDY0NCk7CiAKLS8q
Ci0gKiBFYWNoIG91dHN0YW5kaW5nIHJlcXVlc3QgdGhhdCB3ZSd2ZSBwYXNzZWQgdG8gdGhlIGxv
d2VyIGRldmljZSBsYXllcnMgaGFzIGEKLSAqICdwZW5kaW5nX3JlcScgYWxsb2NhdGVkIHRvIGl0
LiBFYWNoIGJ1ZmZlcl9oZWFkIHRoYXQgY29tcGxldGVzIGRlY3JlbWVudHMKLSAqIHRoZSBwZW5k
Y250IHRvd2FyZHMgemVyby4gV2hlbiBpdCBoaXRzIHplcm8sIHRoZSBzcGVjaWZpZWQgZG9tYWlu
IGhhcyBhCi0gKiByZXNwb25zZSBxdWV1ZWQgZm9yIGl0LCB3aXRoIHRoZSBzYXZlZCAnaWQnIHBh
c3NlZCBiYWNrLgotICovCi1zdHJ1Y3QgcGVuZGluZ19yZXEgewotCXN0cnVjdCB4ZW5fYmxraWYJ
KmJsa2lmOwotCXU2NAkJCWlkOwotCWludAkJCW5yX3BhZ2VzOwotCWF0b21pY190CQlwZW5kY250
OwotCXVuc2lnbmVkIHNob3J0CQlvcGVyYXRpb247Ci0JaW50CQkJc3RhdHVzOwotCXN0cnVjdCBs
aXN0X2hlYWQJZnJlZV9saXN0OwotCXN0cnVjdCBwZXJzaXN0ZW50X2dudAkqcGVyc2lzdGVudF9n
bnRzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07Ci0Jc3RydWN0IHBhZ2UJCSpwYWdl
c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwotCWdyYW50X2hhbmRsZV90CQlncmFu
dF9oYW5kbGVzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07Ci19OwotCiAjZGVmaW5l
IEJMS0JBQ0tfSU5WQUxJRF9IQU5ETEUgKH4wKQogCi1zdHJ1Y3QgeGVuX2Jsa2JrIHsKLQlzdHJ1
Y3QgcGVuZGluZ19yZXEJKnBlbmRpbmdfcmVxczsKLQkvKiBMaXN0IG9mIGFsbCAncGVuZGluZ19y
ZXEnIGF2YWlsYWJsZSAqLwotCXN0cnVjdCBsaXN0X2hlYWQJcGVuZGluZ19mcmVlOwotCS8qIEFu
ZCBpdHMgc3BpbmxvY2suICovCi0Jc3BpbmxvY2tfdAkJcGVuZGluZ19mcmVlX2xvY2s7Ci0Jd2Fp
dF9xdWV1ZV9oZWFkX3QJcGVuZGluZ19mcmVlX3dxOwotfTsKLQotc3RhdGljIHN0cnVjdCB4ZW5f
YmxrYmsgKmJsa2JrOwotCi0vKgotICogTGl0dGxlIGhlbHBmdWwgbWFjcm8gdG8gZmlndXJlIG91
dCB0aGUgaW5kZXggYW5kIHZpcnR1YWwgYWRkcmVzcyBvZiB0aGUKLSAqIHBlbmRpbmdfcGFnZXNb
Li5dLiBGb3IgZWFjaCAncGVuZGluZ19yZXEnIHdlIGhhdmUgaGF2ZSB1cCB0bwotICogQkxLSUZf
TUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUICgxMSkgcGFnZXMuIFRoZSBzZWcgd291bGQgYmUgZnJv
bSAwIHRocm91Z2gKLSAqIDEwIGFuZCB3b3VsZCBpbmRleCBpbiB0aGUgcGVuZGluZ19wYWdlc1su
Ll0uCi0gKi8KLXN0YXRpYyBpbmxpbmUgaW50IHZhZGRyX3BhZ2VucihzdHJ1Y3QgcGVuZGluZ19y
ZXEgKnJlcSwgaW50IHNlZykKLXsKLQlyZXR1cm4gKHJlcSAtIGJsa2JrLT5wZW5kaW5nX3JlcXMp
ICoKLQkJQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUICsgc2VnOwotfQotCiBzdGF0aWMg
aW5saW5lIGludCBnZXRfZnJlZV9wYWdlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmLCBzdHJ1Y3Qg
cGFnZSAqKnBhZ2UpCiB7CiAJdW5zaWduZWQgbG9uZyBmbGFnczsKQEAgLTQwMCwxOCArMzU0LDE4
IEBAIGZpbmlzaGVkOgogLyoKICAqIFJldHJpZXZlIGZyb20gdGhlICdwZW5kaW5nX3JlcXMnIGEg
ZnJlZSBwZW5kaW5nX3JlcSBzdHJ1Y3R1cmUgdG8gYmUgdXNlZC4KICAqLwotc3RhdGljIHN0cnVj
dCBwZW5kaW5nX3JlcSAqYWxsb2NfcmVxKHZvaWQpCitzdGF0aWMgc3RydWN0IHBlbmRpbmdfcmVx
ICphbGxvY19yZXEoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYpCiB7CiAJc3RydWN0IHBlbmRpbmdf
cmVxICpyZXEgPSBOVUxMOwogCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CiAKLQlzcGluX2xvY2tfaXJx
c2F2ZSgmYmxrYmstPnBlbmRpbmdfZnJlZV9sb2NrLCBmbGFncyk7Ci0JaWYgKCFsaXN0X2VtcHR5
KCZibGtiay0+cGVuZGluZ19mcmVlKSkgewotCQlyZXEgPSBsaXN0X2VudHJ5KGJsa2JrLT5wZW5k
aW5nX2ZyZWUubmV4dCwgc3RydWN0IHBlbmRpbmdfcmVxLAorCXNwaW5fbG9ja19pcnFzYXZlKCZi
bGtpZi0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwlpZiAoIWxpc3RfZW1wdHkoJmJsa2lm
LT5wZW5kaW5nX2ZyZWUpKSB7CisJCXJlcSA9IGxpc3RfZW50cnkoYmxraWYtPnBlbmRpbmdfZnJl
ZS5uZXh0LCBzdHJ1Y3QgcGVuZGluZ19yZXEsCiAJCQkJIGZyZWVfbGlzdCk7CiAJCWxpc3RfZGVs
KCZyZXEtPmZyZWVfbGlzdCk7CiAJfQotCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmJsa2JrLT5w
ZW5kaW5nX2ZyZWVfbG9jaywgZmxhZ3MpOworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmJsa2lm
LT5wZW5kaW5nX2ZyZWVfbG9jaywgZmxhZ3MpOwogCXJldHVybiByZXE7CiB9CiAKQEAgLTQxOSwx
NyArMzczLDE3IEBAIHN0YXRpYyBzdHJ1Y3QgcGVuZGluZ19yZXEgKmFsbG9jX3JlcSh2b2lkKQog
ICogUmV0dXJuIHRoZSAncGVuZGluZ19yZXEnIHN0cnVjdHVyZSBiYWNrIHRvIHRoZSBmcmVlcG9v
bC4gV2UgYWxzbwogICogd2FrZSB1cCB0aGUgdGhyZWFkIGlmIGl0IHdhcyB3YWl0aW5nIGZvciBh
IGZyZWUgcGFnZS4KICAqLwotc3RhdGljIHZvaWQgZnJlZV9yZXEoc3RydWN0IHBlbmRpbmdfcmVx
ICpyZXEpCitzdGF0aWMgdm9pZCBmcmVlX3JlcShzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwgc3Ry
dWN0IHBlbmRpbmdfcmVxICpyZXEpCiB7CiAJdW5zaWduZWQgbG9uZyBmbGFnczsKIAlpbnQgd2Fz
X2VtcHR5OwogCi0Jc3Bpbl9sb2NrX2lycXNhdmUoJmJsa2JrLT5wZW5kaW5nX2ZyZWVfbG9jaywg
ZmxhZ3MpOwotCXdhc19lbXB0eSA9IGxpc3RfZW1wdHkoJmJsa2JrLT5wZW5kaW5nX2ZyZWUpOwot
CWxpc3RfYWRkKCZyZXEtPmZyZWVfbGlzdCwgJmJsa2JrLT5wZW5kaW5nX2ZyZWUpOwotCXNwaW5f
dW5sb2NrX2lycXJlc3RvcmUoJmJsa2JrLT5wZW5kaW5nX2ZyZWVfbG9jaywgZmxhZ3MpOworCXNw
aW5fbG9ja19pcnFzYXZlKCZibGtpZi0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKKwl3YXNf
ZW1wdHkgPSBsaXN0X2VtcHR5KCZibGtpZi0+cGVuZGluZ19mcmVlKTsKKwlsaXN0X2FkZCgmcmVx
LT5mcmVlX2xpc3QsICZibGtpZi0+cGVuZGluZ19mcmVlKTsKKwlzcGluX3VubG9ja19pcnFyZXN0
b3JlKCZibGtpZi0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKIAlpZiAod2FzX2VtcHR5KQot
CQl3YWtlX3VwKCZibGtiay0+cGVuZGluZ19mcmVlX3dxKTsKKwkJd2FrZV91cCgmYmxraWYtPnBl
bmRpbmdfZnJlZV93cSk7CiB9CiAKIC8qCkBAIC01NjQsOCArNTE4LDggQEAgaW50IHhlbl9ibGtp
Zl9zY2hlZHVsZSh2b2lkICphcmcpCiAJCWlmICh0aW1lb3V0ID09IDApCiAJCQlnb3RvIHB1cmdl
X2dudF9saXN0OwogCQl0aW1lb3V0ID0gd2FpdF9ldmVudF9pbnRlcnJ1cHRpYmxlX3RpbWVvdXQo
Ci0JCQlibGtiay0+cGVuZGluZ19mcmVlX3dxLAotCQkJIWxpc3RfZW1wdHkoJmJsa2JrLT5wZW5k
aW5nX2ZyZWUpIHx8CisJCQlibGtpZi0+cGVuZGluZ19mcmVlX3dxLAorCQkJIWxpc3RfZW1wdHko
JmJsa2lmLT5wZW5kaW5nX2ZyZWUpIHx8CiAJCQlrdGhyZWFkX3Nob3VsZF9zdG9wKCksCiAJCQl0
aW1lb3V0KTsKIAkJaWYgKHRpbWVvdXQgPT0gMCkKQEAgLTg4Niw3ICs4NDAsNyBAQCBzdGF0aWMg
dm9pZCBfX2VuZF9ibG9ja19pb19vcChzdHJ1Y3QgcGVuZGluZ19yZXEgKnBlbmRpbmdfcmVxLCBp
bnQgZXJyb3IpCiAJCQlpZiAoYXRvbWljX3JlYWQoJnBlbmRpbmdfcmVxLT5ibGtpZi0+ZHJhaW4p
KQogCQkJCWNvbXBsZXRlKCZwZW5kaW5nX3JlcS0+YmxraWYtPmRyYWluX2NvbXBsZXRlKTsKIAkJ
fQotCQlmcmVlX3JlcShwZW5kaW5nX3JlcSk7CisJCWZyZWVfcmVxKHBlbmRpbmdfcmVxLT5ibGtp
ZiwgcGVuZGluZ19yZXEpOwogCX0KIH0KIApAQCAtOTI5LDcgKzg4Myw3IEBAIF9fZG9fYmxvY2tf
aW9fb3Aoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYpCiAJCQlicmVhazsKIAkJfQogCi0JCXBlbmRp
bmdfcmVxID0gYWxsb2NfcmVxKCk7CisJCXBlbmRpbmdfcmVxID0gYWxsb2NfcmVxKGJsa2lmKTsK
IAkJaWYgKE5VTEwgPT0gcGVuZGluZ19yZXEpIHsKIAkJCWJsa2lmLT5zdF9vb19yZXErKzsKIAkJ
CW1vcmVfdG9fZG8gPSAxOwpAQCAtOTU0LDcgKzkwOCw3IEBAIF9fZG9fYmxvY2tfaW9fb3Aoc3Ry
dWN0IHhlbl9ibGtpZiAqYmxraWYpCiAJCS8qIEFwcGx5IGFsbCBzYW5pdHkgY2hlY2tzIHRvIC9w
cml2YXRlIGNvcHkvIG9mIHJlcXVlc3QuICovCiAJCWJhcnJpZXIoKTsKIAkJaWYgKHVubGlrZWx5
KHJlcS5vcGVyYXRpb24gPT0gQkxLSUZfT1BfRElTQ0FSRCkpIHsKLQkJCWZyZWVfcmVxKHBlbmRp
bmdfcmVxKTsKKwkJCWZyZWVfcmVxKGJsa2lmLCBwZW5kaW5nX3JlcSk7CiAJCQlpZiAoZGlzcGF0
Y2hfZGlzY2FyZF9pbyhibGtpZiwgJnJlcSkpCiAJCQkJYnJlYWs7CiAJCX0gZWxzZSBpZiAoZGlz
cGF0Y2hfcndfYmxvY2tfaW8oYmxraWYsICZyZXEsIHBlbmRpbmdfcmVxKSkKQEAgLTExNTcsNyAr
MTExMSw3IEBAIHN0YXRpYyBpbnQgZGlzcGF0Y2hfcndfYmxvY2tfaW8oc3RydWN0IHhlbl9ibGtp
ZiAqYmxraWYsCiAgZmFpbF9yZXNwb25zZToKIAkvKiBIYXZlbid0IHN1Ym1pdHRlZCBhbnkgYmlv
J3MgeWV0LiAqLwogCW1ha2VfcmVzcG9uc2UoYmxraWYsIHJlcS0+dS5ydy5pZCwgcmVxLT5vcGVy
YXRpb24sIEJMS0lGX1JTUF9FUlJPUik7Ci0JZnJlZV9yZXEocGVuZGluZ19yZXEpOworCWZyZWVf
cmVxKGJsa2lmLCBwZW5kaW5nX3JlcSk7CiAJbXNsZWVwKDEpOyAvKiBiYWNrIG9mZiBhIGJpdCAq
LwogCXJldHVybiAtRUlPOwogCkBAIC0xMjEzLDUxICsxMTY3LDIwIEBAIHN0YXRpYyB2b2lkIG1h
a2VfcmVzcG9uc2Uoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIHU2NCBpZCwKIAogc3RhdGljIGlu
dCBfX2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIHsKLQlpbnQgaTsKIAlpbnQgcmMgPSAwOwog
CiAJaWYgKCF4ZW5fZG9tYWluKCkpCiAJCXJldHVybiAtRU5PREVWOwogCi0JYmxrYmsgPSBremFs
bG9jKHNpemVvZihzdHJ1Y3QgeGVuX2Jsa2JrKSwgR0ZQX0tFUk5FTCk7Ci0JaWYgKCFibGtiaykg
ewotCQlwcl9hbGVydChEUlZfUEZYICIlczogb3V0IG9mIG1lbW9yeSFcbiIsIF9fZnVuY19fKTsK
LQkJcmV0dXJuIC1FTk9NRU07Ci0JfQotCi0KLQlibGtiay0+cGVuZGluZ19yZXFzICAgICAgICAg
ID0ga3phbGxvYyhzaXplb2YoYmxrYmstPnBlbmRpbmdfcmVxc1swXSkgKgotCQkJCQl4ZW5fYmxr
aWZfcmVxcywgR0ZQX0tFUk5FTCk7Ci0KLQlpZiAoIWJsa2JrLT5wZW5kaW5nX3JlcXMpIHsKLQkJ
cmMgPSAtRU5PTUVNOwotCQlnb3RvIG91dF9vZl9tZW1vcnk7Ci0JfQotCiAJcmMgPSB4ZW5fYmxr
aWZfaW50ZXJmYWNlX2luaXQoKTsKIAlpZiAocmMpCiAJCWdvdG8gZmFpbGVkX2luaXQ7CiAKLQlJ
TklUX0xJU1RfSEVBRCgmYmxrYmstPnBlbmRpbmdfZnJlZSk7Ci0Jc3Bpbl9sb2NrX2luaXQoJmJs
a2JrLT5wZW5kaW5nX2ZyZWVfbG9jayk7Ci0JaW5pdF93YWl0cXVldWVfaGVhZCgmYmxrYmstPnBl
bmRpbmdfZnJlZV93cSk7Ci0KLQlmb3IgKGkgPSAwOyBpIDwgeGVuX2Jsa2lmX3JlcXM7IGkrKykK
LQkJbGlzdF9hZGRfdGFpbCgmYmxrYmstPnBlbmRpbmdfcmVxc1tpXS5mcmVlX2xpc3QsCi0JCQkg
ICAgICAmYmxrYmstPnBlbmRpbmdfZnJlZSk7Ci0KIAlyYyA9IHhlbl9ibGtpZl94ZW5idXNfaW5p
dCgpOwogCWlmIChyYykKIAkJZ290byBmYWlsZWRfaW5pdDsKIAotCXJldHVybiAwOwotCi0gb3V0
X29mX21lbW9yeToKLQlwcl9hbGVydChEUlZfUEZYICIlczogb3V0IG9mIG1lbW9yeVxuIiwgX19m
dW5jX18pOwogIGZhaWxlZF9pbml0OgotCWtmcmVlKGJsa2JrLT5wZW5kaW5nX3JlcXMpOwotCWtm
cmVlKGJsa2JrKTsKLQlibGtiayA9IE5VTEw7CiAJcmV0dXJuIHJjOwogfQogCmRpZmYgLS1naXQg
YS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oIGIvZHJpdmVycy9ibG9jay94ZW4t
YmxrYmFjay9jb21tb24uaAppbmRleCA2MDRiZDMwLi4wYjBhZDNmIDEwMDY0NAotLS0gYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJs
a2JhY2svY29tbW9uLmgKQEAgLTIxNCw2ICsyMTQsMTQgQEAgc3RydWN0IHhlbl9ibGtpZiB7CiAJ
aW50CQkJZnJlZV9wYWdlc19udW07CiAJc3RydWN0IGxpc3RfaGVhZAlmcmVlX3BhZ2VzOwogCisJ
LyogQWxsb2NhdGlvbiBvZiBwZW5kaW5nX3JlcXMgKi8KKwlzdHJ1Y3QgcGVuZGluZ19yZXEJKnBl
bmRpbmdfcmVxczsKKwkvKiBMaXN0IG9mIGFsbCAncGVuZGluZ19yZXEnIGF2YWlsYWJsZSAqLwor
CXN0cnVjdCBsaXN0X2hlYWQJcGVuZGluZ19mcmVlOworCS8qIEFuZCBpdHMgc3BpbmxvY2suICov
CisJc3BpbmxvY2tfdAkJcGVuZGluZ19mcmVlX2xvY2s7CisJd2FpdF9xdWV1ZV9oZWFkX3QJcGVu
ZGluZ19mcmVlX3dxOworCiAJLyogc3RhdGlzdGljcyAqLwogCXVuc2lnbmVkIGxvbmcJCXN0X3By
aW50OwogCWludAkJCXN0X3JkX3JlcTsKQEAgLTIyNyw2ICsyMzUsMjUgQEAgc3RydWN0IHhlbl9i
bGtpZiB7CiAJd2FpdF9xdWV1ZV9oZWFkX3QJd2FpdGluZ190b19mcmVlOwogfTsKIAorLyoKKyAq
IEVhY2ggb3V0c3RhbmRpbmcgcmVxdWVzdCB0aGF0IHdlJ3ZlIHBhc3NlZCB0byB0aGUgbG93ZXIg
ZGV2aWNlIGxheWVycyBoYXMgYQorICogJ3BlbmRpbmdfcmVxJyBhbGxvY2F0ZWQgdG8gaXQuIEVh
Y2ggYnVmZmVyX2hlYWQgdGhhdCBjb21wbGV0ZXMgZGVjcmVtZW50cworICogdGhlIHBlbmRjbnQg
dG93YXJkcyB6ZXJvLiBXaGVuIGl0IGhpdHMgemVybywgdGhlIHNwZWNpZmllZCBkb21haW4gaGFz
IGEKKyAqIHJlc3BvbnNlIHF1ZXVlZCBmb3IgaXQsIHdpdGggdGhlIHNhdmVkICdpZCcgcGFzc2Vk
IGJhY2suCisgKi8KK3N0cnVjdCBwZW5kaW5nX3JlcSB7CisJc3RydWN0IHhlbl9ibGtpZgkqYmxr
aWY7CisJdTY0CQkJaWQ7CisJaW50CQkJbnJfcGFnZXM7CisJYXRvbWljX3QJCXBlbmRjbnQ7CisJ
dW5zaWduZWQgc2hvcnQJCW9wZXJhdGlvbjsKKwlpbnQJCQlzdGF0dXM7CisJc3RydWN0IGxpc3Rf
aGVhZAlmcmVlX2xpc3Q7CisJc3RydWN0IHBlcnNpc3RlbnRfZ250CSpwZXJzaXN0ZW50X2dudHNb
QkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGFnZQkJKnBhZ2VzW0JM
S0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CisJZ3JhbnRfaGFuZGxlX3QJCWdyYW50X2hh
bmRsZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKK307CisKIAogI2RlZmluZSB2
YmRfc3ooX3YpCSgoX3YpLT5iZGV2LT5iZF9wYXJ0ID8gXAogCQkJIChfdiktPmJkZXYtPmJkX3Bh
cnQtPm5yX3NlY3RzIDogXApkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94
ZW5idXMuYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKaW5kZXggZDc5MjZl
Yy4uOGY5MjljYiAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMu
YworKysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCkBAIC0zMCw2ICszMCw4
IEBAIHN0cnVjdCBiYWNrZW5kX2luZm8gewogCWNoYXIJCQkqbW9kZTsKIH07CiAKK2V4dGVybiBp
bnQgeGVuX2Jsa2lmX3JlcXM7CisKIHN0YXRpYyBzdHJ1Y3Qga21lbV9jYWNoZSAqeGVuX2Jsa2lm
X2NhY2hlcDsKIHN0YXRpYyB2b2lkIGNvbm5lY3Qoc3RydWN0IGJhY2tlbmRfaW5mbyAqKTsKIHN0
YXRpYyBpbnQgY29ubmVjdF9yaW5nKHN0cnVjdCBiYWNrZW5kX2luZm8gKik7CkBAIC0xMDQsNiAr
MTA2LDcgQEAgc3RhdGljIHZvaWQgeGVuX3VwZGF0ZV9ibGtpZl9zdGF0dXMoc3RydWN0IHhlbl9i
bGtpZiAqYmxraWYpCiBzdGF0aWMgc3RydWN0IHhlbl9ibGtpZiAqeGVuX2Jsa2lmX2FsbG9jKGRv
bWlkX3QgZG9taWQpCiB7CiAJc3RydWN0IHhlbl9ibGtpZiAqYmxraWY7CisJaW50IGk7CiAKIAli
bGtpZiA9IGttZW1fY2FjaGVfemFsbG9jKHhlbl9ibGtpZl9jYWNoZXAsIEdGUF9LRVJORUwpOwog
CWlmICghYmxraWYpCkBAIC0xMjIsNiArMTI1LDE5IEBAIHN0YXRpYyBzdHJ1Y3QgeGVuX2Jsa2lm
ICp4ZW5fYmxraWZfYWxsb2MoZG9taWRfdCBkb21pZCkKIAlzcGluX2xvY2tfaW5pdCgmYmxraWYt
PmZyZWVfcGFnZXNfbG9jayk7CiAJSU5JVF9MSVNUX0hFQUQoJmJsa2lmLT5mcmVlX3BhZ2VzKTsK
IAlibGtpZi0+ZnJlZV9wYWdlc19udW0gPSAwOworCWJsa2lmLT5wZW5kaW5nX3JlcXMgPSBremFs
bG9jKHNpemVvZihibGtpZi0+cGVuZGluZ19yZXFzWzBdKSAqCisJICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgeGVuX2Jsa2lmX3JlcXMsIEdGUF9LRVJORUwpOworCWlmICghYmxraWYtPnBl
bmRpbmdfcmVxcykgeworCQlrbWVtX2NhY2hlX2ZyZWUoeGVuX2Jsa2lmX2NhY2hlcCwgYmxraWYp
OworCQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsKKwl9CisJSU5JVF9MSVNUX0hFQUQoJmJsa2lm
LT5wZW5kaW5nX2ZyZWUpOworCXNwaW5fbG9ja19pbml0KCZibGtpZi0+cGVuZGluZ19mcmVlX2xv
Y2spOworCWluaXRfd2FpdHF1ZXVlX2hlYWQoJmJsa2lmLT5wZW5kaW5nX2ZyZWVfd3EpOworCisJ
Zm9yIChpID0gMDsgaSA8IHhlbl9ibGtpZl9yZXFzOyBpKyspCisJCWxpc3RfYWRkX3RhaWwoJmJs
a2lmLT5wZW5kaW5nX3JlcXNbaV0uZnJlZV9saXN0LAorCQkJICAgICAgJmJsa2lmLT5wZW5kaW5n
X2ZyZWUpOwogCiAJcmV0dXJuIGJsa2lmOwogfQpAQCAtMjA0LDYgKzIyMCw3IEBAIHN0YXRpYyB2
b2lkIHhlbl9ibGtpZl9mcmVlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmKQogewogCWlmICghYXRv
bWljX2RlY19hbmRfdGVzdCgmYmxraWYtPnJlZmNudCkpCiAJCUJVRygpOworCWtmcmVlKGJsa2lm
LT5wZW5kaW5nX3JlcXMpOwogCWttZW1fY2FjaGVfZnJlZSh4ZW5fYmxraWZfY2FjaGVwLCBibGtp
Zik7CiB9CiAKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0kA-0005rS-Qs; Thu, 28 Feb 2013 10:29:42 +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 1UB0k8-0005pF-Vy
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:41 +0000
Received: from [193.109.254.147:32830] by server-15.bemta-14.messagelabs.com
	id 50/0E-24599-4913F215; Thu, 28 Feb 2013 10:29:40 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!13
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1828 invoked from network); 28 Feb 2013 10:29:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:40 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:39 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:55 +0100
Message-ID: <1362047335-26402-13-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
	descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

SW5kaXJlY3QgZGVzY3JpcHRvcnMgaW50cm9kdWNlIGEgbmV3IGJsb2NrIG9wZXJhdGlvbgooQkxL
SUZfT1BfSU5ESVJFQ1QpIHRoYXQgcGFzc2VzIGdyYW50IHJlZmVyZW5jZXMgaW5zdGVhZCBvZiBz
ZWdtZW50cwppbiB0aGUgcmVxdWVzdC4gVGhpcyBncmFudCByZWZlcmVuY2VzIGFyZSBmaWxsZWQg
d2l0aCBhcnJheXMgb2YKYmxraWZfcmVxdWVzdF9zZWdtZW50X2FsaWduZWQsIHRoaXMgd2F5IHdl
IGNhbiBzZW5kIG1vcmUgc2VnbWVudHMgaW4gYQpyZXF1ZXN0LgoKVGhlIHByb3Bvc2VkIGltcGxl
bWVudGF0aW9uIHNldHMgdGhlIG1heGltdW0gbnVtYmVyIG9mIGluZGlyZWN0IGdyZWZzCihmcmFt
ZXMgZmlsbGVkIHdpdGggYmxraWZfcmVxdWVzdF9zZWdtZW50X2FsaWduZWQpIHRvIDI1NiBpbiB0
aGUKYmFja2VuZCBhbmQgNjQgaW4gdGhlIGZyb250ZW5kLiBUaGUgdmFsdWUgaW4gdGhlIGZyb250
ZW5kIGhhcyBiZWVuCmNob3NlbiBleHBlcmltZW50YWxseSwgYW5kIHRoZSBiYWNrZW5kIHZhbHVl
IGhhcyBiZWVuIHNldCB0byBhIHNhbmUKdmFsdWUgdGhhdCBhbGxvd3MgZXhwYW5kaW5nIHRoZSBt
YXhpbXVtIG51bWJlciBvZiBpbmRpcmVjdCBkZXNjcmlwdG9ycwppbiB0aGUgZnJvbnRlbmQgaWYg
bmVlZGVkLgoKVGhlIG1pZ3JhdGlvbiBjb2RlIGhhcyBjaGFuZ2VkIGZyb20gdGhlIHByZXZpb3Vz
IGltcGxlbWVudGF0aW9uLCBpbgp3aGljaCB3ZSBzaW1wbHkgcmVtYXBwZWQgdGhlIHNlZ21lbnRz
IG9uIHRoZSBzaGFyZWQgcmluZy4gTm93IHRoZQptYXhpbXVtIG51bWJlciBvZiBzZWdtZW50cyBh
bGxvd2VkIGluIGEgcmVxdWVzdCBjYW4gY2hhbmdlIGRlcGVuZGluZwpvbiB0aGUgYmFja2VuZCwg
c28gd2UgaGF2ZSB0byByZXF1ZXVlIGFsbCB0aGUgcmVxdWVzdHMgaW4gdGhlIHJpbmcgYW5kCmlu
IHRoZSBxdWV1ZSBhbmQgc3BsaXQgdGhlIGJpb3MgaW4gdGhlbSBpZiB0aGV5IGFyZSBiaWdnZXIg
dGhhbiB0aGUKbmV3IG1heGltdW0gbnVtYmVyIG9mIHNlZ21lbnRzLgoKU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNjOiBLb25yYWQgUnplc3p1
dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4tZGV2ZWxAbGlzdHMueGVu
Lm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIHwgIDEyOSArKysr
KysrLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oICB8ICAgODAgKysrKysr
LQogZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyAgfCAgICA4ICsKIGRyaXZlcnMv
YmxvY2sveGVuLWJsa2Zyb250LmMgICAgICAgIHwgIDQ5OCArKysrKysrKysrKysrKysrKysrKysr
KysrKysrKy0tLS0tLQogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2lvL2Jsa2lmLmggICAgfCAgIDI1
ICsrCiA1IGZpbGVzIGNoYW5nZWQsIDYyMiBpbnNlcnRpb25zKCspLCAxMTggZGVsZXRpb25zKC0p
CgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMgYi9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCAwZmEzMGRiLi45OGViMTZiIDEw
MDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYworKysgYi9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtNzAsNyArNzAsNyBAQCBNT0RVTEVf
UEFSTV9ERVNDKHJlcXMsICJOdW1iZXIgb2YgYmxrYmFjayByZXF1ZXN0cyB0byBhbGxvY2F0ZSBw
ZXIgYmFja2VuZCIpOwogICogYWxnb3JpdGhtLgogICovCiAKLXN0YXRpYyBpbnQgeGVuX2Jsa2lm
X21heF9wZ3JhbnRzID0gMzUyOworc3RhdGljIGludCB4ZW5fYmxraWZfbWF4X3BncmFudHMgPSAx
MDI0OwogbW9kdWxlX3BhcmFtX25hbWVkKG1heF9wZXJzaXN0ZW50X2dyYW50cywgeGVuX2Jsa2lm
X21heF9wZ3JhbnRzLCBpbnQsIDA2NDQpOwogTU9EVUxFX1BBUk1fREVTQyhtYXhfcGVyc2lzdGVu
dF9ncmFudHMsCiAgICAgICAgICAgICAgICAgICJNYXhpbXVtIG51bWJlciBvZiBncmFudHMgdG8g
bWFwIHBlcnNpc3RlbnRseSIpOwpAQCAtNTc4LDEwICs1NzgsNiBAQCBwdXJnZV9nbnRfbGlzdDoK
IAlyZXR1cm4gMDsKIH0KIAotc3RydWN0IHNlZ19idWYgewotCXVuc2lnbmVkIGxvbmcgYnVmOwot
CXVuc2lnbmVkIGludCBuc2VjOwotfTsKIC8qCiAgKiBVbm1hcCB0aGUgZ3JhbnQgcmVmZXJlbmNl
cywgYW5kIGFsc28gcmVtb3ZlIHRoZSBNMlAgb3Zlci1yaWRlcwogICogdXNlZCBpbiB0aGUgJ3Bl
bmRpbmdfcmVxJy4KQEAgLTc2MSwzMiArNzU3LDc5IEBAIG91dF9vZl9tZW1vcnk6CiAJcmV0dXJu
IC1FTk9NRU07CiB9CiAKLXN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcF9zZWcoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKnJlcSwKLQkJCSAgICAgc3RydWN0IHBlbmRpbmdfcmVxICpwZW5kaW5nX3JlcSwK
K3N0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcF9zZWcoc3RydWN0IHBlbmRpbmdfcmVxICpwZW5kaW5n
X3JlcSwKIAkJCSAgICAgc3RydWN0IHNlZ19idWYgc2VnW10sCiAJCQkgICAgIHN0cnVjdCBwYWdl
ICpwYWdlc1tdKQogewogCWludCBpLCByYzsKLQlncmFudF9yZWZfdCBncmVmc1tCTEtJRl9NQVhf
U0VHTUVOVFNfUEVSX1JFUVVFU1RdOwogCi0JZm9yIChpID0gMDsgaSA8IHJlcS0+dS5ydy5ucl9z
ZWdtZW50czsgaSsrKQotCQlncmVmc1tpXSA9IHJlcS0+dS5ydy5zZWdbaV0uZ3JlZjsKLQotCXJj
ID0geGVuX2Jsa2JrX21hcChwZW5kaW5nX3JlcS0+YmxraWYsIGdyZWZzLAorCXJjID0geGVuX2Js
a2JrX21hcChwZW5kaW5nX3JlcS0+YmxraWYsIHBlbmRpbmdfcmVxLT5ncmVmcywKIAkgICAgICAg
ICAgICAgICAgICAgcGVuZGluZ19yZXEtPnBlcnNpc3RlbnRfZ250cywKIAkgICAgICAgICAgICAg
ICAgICAgcGVuZGluZ19yZXEtPmdyYW50X2hhbmRsZXMsIHBlbmRpbmdfcmVxLT5wYWdlcywKLQkg
ICAgICAgICAgICAgICAgICAgcmVxLT51LnJ3Lm5yX3NlZ21lbnRzLAorCSAgICAgICAgICAgICAg
ICAgICBwZW5kaW5nX3JlcS0+bnJfcGFnZXMsCiAJICAgICAgICAgICAgICAgICAgIChwZW5kaW5n
X3JlcS0+b3BlcmF0aW9uICE9IEJMS0lGX09QX1JFQUQpKTsKIAlpZiAocmMpCiAJCXJldHVybiBy
YzsKIAotCWZvciAoaSA9IDA7IGkgPCByZXEtPnUucncubnJfc2VnbWVudHM7IGkrKykKLQkJc2Vn
W2ldLmJ1ZiA9IHBmbl90b19tZm4ocGFnZV90b19wZm4ocGVuZGluZ19yZXEtPnBhZ2VzW2ldKSkK
LQkJICAgICAgICAgICAgIDw8IFBBR0VfU0hJRlQgfCAocmVxLT51LnJ3LnNlZ1tpXS5maXJzdF9z
ZWN0IDw8IDkpOworCWZvciAoaSA9IDA7IGkgPCBwZW5kaW5nX3JlcS0+bnJfcGFnZXM7IGkrKykK
KwkJc2VnW2ldLmJ1ZiB8PSBwZm5fdG9fbWZuKHBhZ2VfdG9fcGZuKHBlbmRpbmdfcmVxLT5wYWdl
c1tpXSkpCisJCSAgICAgICAgICAgICA8PCBQQUdFX1NISUZUOwogCiAJcmV0dXJuIDA7CiB9CiAK
K3N0YXRpYyBpbnQgeGVuX2Jsa2JrX3BhcnNlX2luZGlyZWN0KHN0cnVjdCBibGtpZl9yZXF1ZXN0
ICpyZXEsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcGVuZGlu
Z19yZXEgKnBlbmRpbmdfcmVxLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
c3RydWN0IHNlZ19idWYgc2VnW10sCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdHJ1Y3QgcGh5c19yZXEgKnByZXEpCit7CisJc3RydWN0IHBlcnNpc3RlbnRfZ250ICoqcGVy
c2lzdGVudCA9CisJCXBlbmRpbmdfcmVxLT5pbmRpcmVjdF9wZXJzaXN0ZW50X2dudHM7CisJc3Ry
dWN0IHBhZ2UgKipwYWdlcyA9IHBlbmRpbmdfcmVxLT5pbmRpcmVjdF9wYWdlczsKKwlzdHJ1Y3Qg
eGVuX2Jsa2lmICpibGtpZiA9IHBlbmRpbmdfcmVxLT5ibGtpZjsKKwlpbnQgaW5kaXJlY3RfZ3Jl
ZnMsIHJjLCBuLCBuc2VnLCBpOworCXN0cnVjdCBibGtpZl9yZXF1ZXN0X3NlZ21lbnRfYWxpZ25l
ZCAqc2VnbWVudHMgPSBOVUxMOworCisJbnNlZyA9IHBlbmRpbmdfcmVxLT5ucl9wYWdlczsKKwlp
bmRpcmVjdF9ncmVmcyA9IChuc2VnICsgU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgLSAxKSAvCisJ
CSAgICAgICAgIFNFR1NfUEVSX0lORElSRUNUX0ZSQU1FOworCisJcmMgPSB4ZW5fYmxrYmtfbWFw
KGJsa2lmLCByZXEtPnUuaW5kaXJlY3QuaW5kaXJlY3RfZ3JlZnMsCisJICAgICAgICAgICAgICAg
ICAgIHBlcnNpc3RlbnQsIHBlbmRpbmdfcmVxLT5pbmRpcmVjdF9oYW5kbGVzLAorCSAgICAgICAg
ICAgICAgICAgICBwYWdlcywgaW5kaXJlY3RfZ3JlZnMsIHRydWUpOworCWlmIChyYykKKwkJZ290
byB1bm1hcDsKKworCWZvciAobiA9IDAsIGkgPSAwOyBuIDwgbnNlZzsgbisrKSB7CisJCWlmICgo
biAlIFNFR1NfUEVSX0lORElSRUNUX0ZSQU1FKSA9PSAwKSB7CisJCQkvKiBNYXAgaW5kaXJlY3Qg
c2VnbWVudHMgKi8KKwkJCWlmIChzZWdtZW50cykKKwkJCQlrdW5tYXBfYXRvbWljKHNlZ21lbnRz
KTsKKwkJCXNlZ21lbnRzID0KKwkJCQlrbWFwX2F0b21pYyhwYWdlc1tuL1NFR1NfUEVSX0lORElS
RUNUX0ZSQU1FXSk7CisJCX0KKwkJaSA9IG4gJSBTRUdTX1BFUl9JTkRJUkVDVF9GUkFNRTsKKwkJ
cGVuZGluZ19yZXEtPmdyZWZzW25dID0gc2VnbWVudHNbaV0uZ3JlZjsKKwkJc2VnW25dLm5zZWMg
PSBzZWdtZW50c1tpXS5sYXN0X3NlY3QgLQorCQkJc2VnbWVudHNbaV0uZmlyc3Rfc2VjdCArIDE7
CisJCXNlZ1tuXS5idWYgPSBzZWdtZW50c1tpXS5maXJzdF9zZWN0IDw8IDk7CisJCWlmICgoc2Vn
bWVudHNbaV0ubGFzdF9zZWN0ID49IChQQUdFX1NJWkUgPj4gOSkpIHx8CisJICAgIAkgICAgKHNl
Z21lbnRzW2ldLmxhc3Rfc2VjdCA8CisJICAgIAkgICAgIHNlZ21lbnRzW2ldLmZpcnN0X3NlY3Qp
KSB7CisJCQlyYyA9IC1FSU5WQUw7CisJCQlnb3RvIHVubWFwOworCQl9CisJCXByZXEtPm5yX3Nl
Y3RzICs9IHNlZ1tuXS5uc2VjOworCX0KKwordW5tYXA6CisJaWYgKHNlZ21lbnRzKQorCQlrdW5t
YXBfYXRvbWljKHNlZ21lbnRzKTsKKwl4ZW5fYmxrYmtfdW5tYXAoYmxraWYsIHBlbmRpbmdfcmVx
LT5pbmRpcmVjdF9oYW5kbGVzLAorICAgICAgICAgICAgICAgICAgICAgICAgcGFnZXMsIHBlcnNp
c3RlbnQsIGluZGlyZWN0X2dyZWZzKTsKKwlyZXR1cm4gcmM7Cit9CisKIHN0YXRpYyBpbnQgZGlz
cGF0Y2hfZGlzY2FyZF9pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAkJCQlzdHJ1Y3QgYmxr
aWZfcmVxdWVzdCAqcmVxKQogewpAQCAtOTgwLDE3ICsxMDIzLDIxIEBAIHN0YXRpYyBpbnQgZGlz
cGF0Y2hfcndfYmxvY2tfaW8oc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsCiAJCQkJc3RydWN0IHBl
bmRpbmdfcmVxICpwZW5kaW5nX3JlcSkKIHsKIAlzdHJ1Y3QgcGh5c19yZXEgcHJlcTsKLQlzdHJ1
Y3Qgc2VnX2J1ZiBzZWdbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3Qg
c2VnX2J1ZiAqc2VnID0gcGVuZGluZ19yZXEtPnNlZzsKIAl1bnNpZ25lZCBpbnQgbnNlZzsKIAlz
dHJ1Y3QgYmlvICpiaW8gPSBOVUxMOwotCXN0cnVjdCBiaW8gKmJpb2xpc3RbQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgYmlvICoqYmlvbGlzdCA9IHBlbmRpbmdfcmVx
LT5iaW9saXN0OwogCWludCBpLCBuYmlvID0gMDsKIAlpbnQgb3BlcmF0aW9uOwogCXN0cnVjdCBi
bGtfcGx1ZyBwbHVnOwogCWJvb2wgZHJhaW4gPSBmYWxzZTsKIAlzdHJ1Y3QgcGFnZSAqKnBhZ2Vz
ID0gcGVuZGluZ19yZXEtPnBhZ2VzOworCXVuc2lnbmVkIHNob3J0IHJlcV9vcGVyYXRpb247CisK
KwlyZXFfb3BlcmF0aW9uID0gcmVxLT5vcGVyYXRpb24gPT0gQkxLSUZfT1BfSU5ESVJFQ1QgPwor
CSAgICAgICAgICAgICAgICByZXEtPnUuaW5kaXJlY3QuaW5kaXJlY3Rfb3AgOiByZXEtPm9wZXJh
dGlvbjsKIAotCXN3aXRjaCAocmVxLT5vcGVyYXRpb24pIHsKKwlzd2l0Y2ggKHJlcV9vcGVyYXRp
b24pIHsKIAljYXNlIEJMS0lGX09QX1JFQUQ6CiAJCWJsa2lmLT5zdF9yZF9yZXErKzsKIAkJb3Bl
cmF0aW9uID0gUkVBRDsKQEAgLTEwMTIsMzMgKzEwNTksNDkgQEAgc3RhdGljIGludCBkaXNwYXRj
aF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAl9CiAKIAkvKiBDaGVjayB0
aGF0IHRoZSBudW1iZXIgb2Ygc2VnbWVudHMgaXMgc2FuZS4gKi8KLQluc2VnID0gcmVxLT51LnJ3
Lm5yX3NlZ21lbnRzOworCW5zZWcgPSByZXEtPm9wZXJhdGlvbiA9PSBCTEtJRl9PUF9JTkRJUkVD
VCA/CisJICAgICAgIHJlcS0+dS5pbmRpcmVjdC5ucl9zZWdtZW50cyA6IHJlcS0+dS5ydy5ucl9z
ZWdtZW50czsKIAogCWlmICh1bmxpa2VseShuc2VnID09IDAgJiYgb3BlcmF0aW9uICE9IFdSSVRF
X0ZMVVNIKSB8fAotCSAgICB1bmxpa2VseShuc2VnID4gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUKSkgeworCSAgICB1bmxpa2VseSgocmVxLT5vcGVyYXRpb24gIT0gQkxLSUZfT1BfSU5E
SVJFQ1QpICYmCisJICAgICAgICAgICAgIChuc2VnID4gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUKSkgfHwKKwkgICAgdW5saWtlbHkoKHJlcS0+b3BlcmF0aW9uID09IEJMS0lGX09QX0lO
RElSRUNUKSAmJgorCSAgICAgICAgICAgICAobnNlZyA+IE1BWF9JTkRJUkVDVF9TRUdNRU5UUykp
KSB7CiAJCXByX2RlYnVnKERSVl9QRlggIkJhZCBudW1iZXIgb2Ygc2VnbWVudHMgaW4gcmVxdWVz
dCAoJWQpXG4iLAogCQkJIG5zZWcpOwogCQkvKiBIYXZlbid0IHN1Ym1pdHRlZCBhbnkgYmlvJ3Mg
eWV0LiAqLwogCQlnb3RvIGZhaWxfcmVzcG9uc2U7CiAJfQogCi0JcHJlcS5zZWN0b3JfbnVtYmVy
ID0gcmVxLT51LnJ3LnNlY3Rvcl9udW1iZXI7CiAJcHJlcS5ucl9zZWN0cyAgICAgID0gMDsKIAog
CXBlbmRpbmdfcmVxLT5ibGtpZiAgICAgPSBibGtpZjsKLQlwZW5kaW5nX3JlcS0+aWQgICAgICAg
ID0gcmVxLT51LnJ3LmlkOwotCXBlbmRpbmdfcmVxLT5vcGVyYXRpb24gPSByZXEtPm9wZXJhdGlv
bjsKIAlwZW5kaW5nX3JlcS0+c3RhdHVzICAgID0gQkxLSUZfUlNQX09LQVk7CiAJcGVuZGluZ19y
ZXEtPm5yX3BhZ2VzICA9IG5zZWc7CiAKLQlmb3IgKGkgPSAwOyBpIDwgbnNlZzsgaSsrKSB7Ci0J
CXNlZ1tpXS5uc2VjID0gcmVxLT51LnJ3LnNlZ1tpXS5sYXN0X3NlY3QgLQotCQkJcmVxLT51LnJ3
LnNlZ1tpXS5maXJzdF9zZWN0ICsgMTsKLQkJaWYgKChyZXEtPnUucncuc2VnW2ldLmxhc3Rfc2Vj
dCA+PSAoUEFHRV9TSVpFID4+IDkpKSB8fAotCQkgICAgKHJlcS0+dS5ydy5zZWdbaV0ubGFzdF9z
ZWN0IDwgcmVxLT51LnJ3LnNlZ1tpXS5maXJzdF9zZWN0KSkKKwlpZiAocmVxLT5vcGVyYXRpb24g
IT0gQkxLSUZfT1BfSU5ESVJFQ1QpIHsKKwkJcHJlcS5kZXYgICAgICAgICAgICAgICA9IHJlcS0+
dS5ydy5oYW5kbGU7CisJCXByZXEuc2VjdG9yX251bWJlciAgICAgPSByZXEtPnUucncuc2VjdG9y
X251bWJlcjsKKwkJcGVuZGluZ19yZXEtPmlkICAgICAgICA9IHJlcS0+dS5ydy5pZDsKKwkJcGVu
ZGluZ19yZXEtPm9wZXJhdGlvbiA9IHJlcS0+b3BlcmF0aW9uOworCQlmb3IgKGkgPSAwOyBpIDwg
bnNlZzsgaSsrKSB7CisJCQlwZW5kaW5nX3JlcS0+Z3JlZnNbaV0gPSByZXEtPnUucncuc2VnW2ld
LmdyZWY7CisJCQlzZWdbaV0ubnNlYyA9IHJlcS0+dS5ydy5zZWdbaV0ubGFzdF9zZWN0IC0KKwkJ
CQlyZXEtPnUucncuc2VnW2ldLmZpcnN0X3NlY3QgKyAxOworCQkJc2VnW2ldLmJ1ZiA9IHJlcS0+
dS5ydy5zZWdbaV0uZmlyc3Rfc2VjdCA8PCA5OworCQkJaWYgKChyZXEtPnUucncuc2VnW2ldLmxh
c3Rfc2VjdCA+PSAoUEFHRV9TSVpFID4+IDkpKSB8fAorCQkgICAgCSAgICAocmVxLT51LnJ3LnNl
Z1tpXS5sYXN0X3NlY3QgPAorCQkgICAgCSAgICAgcmVxLT51LnJ3LnNlZ1tpXS5maXJzdF9zZWN0
KSkKKwkJCQlnb3RvIGZhaWxfcmVzcG9uc2U7CisJCQlwcmVxLm5yX3NlY3RzICs9IHNlZ1tpXS5u
c2VjOworCQl9CisJfSBlbHNlIHsKKwkJcHJlcS5kZXYgICAgICAgICAgICAgICA9IHJlcS0+dS5p
bmRpcmVjdC5oYW5kbGU7CisJCXByZXEuc2VjdG9yX251bWJlciAgICAgPSByZXEtPnUuaW5kaXJl
Y3Quc2VjdG9yX251bWJlcjsKKwkJcGVuZGluZ19yZXEtPmlkICAgICAgICA9IHJlcS0+dS5pbmRp
cmVjdC5pZDsKKwkJcGVuZGluZ19yZXEtPm9wZXJhdGlvbiA9IHJlcS0+dS5pbmRpcmVjdC5pbmRp
cmVjdF9vcDsKKwkJaWYgKHhlbl9ibGtia19wYXJzZV9pbmRpcmVjdChyZXEsIHBlbmRpbmdfcmVx
LCBzZWcsICZwcmVxKSkKIAkJCWdvdG8gZmFpbF9yZXNwb25zZTsKLQkJcHJlcS5ucl9zZWN0cyAr
PSBzZWdbaV0ubnNlYzsKLQogCX0KIAogCWlmICh4ZW5fdmJkX3RyYW5zbGF0ZSgmcHJlcSwgYmxr
aWYsIG9wZXJhdGlvbikgIT0gMCkgewpAQCAtMTA3NCw3ICsxMTM3LDcgQEAgc3RhdGljIGludCBk
aXNwYXRjaF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAkgKiB0aGUgaHlw
ZXJjYWxsIHRvIHVubWFwIHRoZSBncmFudHMgLSB0aGF0IGlzIGFsbCBkb25lIGluCiAJICogeGVu
X2Jsa2JrX3VubWFwLgogCSAqLwotCWlmICh4ZW5fYmxrYmtfbWFwX3NlZyhyZXEsIHBlbmRpbmdf
cmVxLCBzZWcsIHBhZ2VzKSkKKwlpZiAoeGVuX2Jsa2JrX21hcF9zZWcocGVuZGluZ19yZXEsIHNl
ZywgcGFnZXMpKQogCQlnb3RvIGZhaWxfZmx1c2g7CiAKIAkvKgpAQCAtMTE0Niw3ICsxMjA5LDcg
QEAgc3RhdGljIGludCBkaXNwYXRjaF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtp
ZiwKIAkgICAgICAgICAgICAgICAgcGVuZGluZ19yZXEtPm5yX3BhZ2VzKTsKICBmYWlsX3Jlc3Bv
bnNlOgogCS8qIEhhdmVuJ3Qgc3VibWl0dGVkIGFueSBiaW8ncyB5ZXQuICovCi0JbWFrZV9yZXNw
b25zZShibGtpZiwgcmVxLT51LnJ3LmlkLCByZXEtPm9wZXJhdGlvbiwgQkxLSUZfUlNQX0VSUk9S
KTsKKwltYWtlX3Jlc3BvbnNlKGJsa2lmLCByZXEtPnUucncuaWQsIHJlcV9vcGVyYXRpb24sIEJM
S0lGX1JTUF9FUlJPUik7CiAJZnJlZV9yZXEoYmxraWYsIHBlbmRpbmdfcmVxKTsKIAltc2xlZXAo
MSk7IC8qIGJhY2sgb2ZmIGEgYml0ICovCiAJcmV0dXJuIC1FSU87CmRpZmYgLS1naXQgYS9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oIGIvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFj
ay9jb21tb24uaAppbmRleCAwYjBhZDNmLi5kMzY1NmQyIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
Y29tbW9uLmgKQEAgLTUwLDYgKzUwLDE3IEBACiAJCSBfX2Z1bmNfXywgX19MSU5FX18sICMjYXJn
cykKIAogCisvKgorICogVGhpcyBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygc2VnbWVudHMgdGhh
dCB3b3VsZCBiZSBhbGxvd2VkIGluIGluZGlyZWN0CisgKiByZXF1ZXN0cy4gVGhpcyB2YWx1ZSB3
aWxsIGFsc28gYmUgcGFzc2VkIHRvIHRoZSBmcm9udGVuZC4KKyAqLworI2RlZmluZSBNQVhfSU5E
SVJFQ1RfU0VHTUVOVFMgMjU2CisKKyNkZWZpbmUgU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgXAor
KFBBR0VfU0laRS9zaXplb2Yoc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudF9hbGlnbmVkKSkK
KyNkZWZpbmUgTUFYX0lORElSRUNUX0dSRUZTIFwKKygoTUFYX0lORElSRUNUX1NFR01FTlRTICsg
U0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgLSAxKS9TRUdTX1BFUl9JTkRJUkVDVF9GUkFNRSkKKwog
LyogTm90IGEgcmVhbCBwcm90b2NvbC4gIFVzZWQgdG8gZ2VuZXJhdGUgcmluZyBzdHJ1Y3RzIHdo
aWNoIGNvbnRhaW4KICAqIHRoZSBlbGVtZW50cyBjb21tb24gdG8gYWxsIHByb3RvY29scyBvbmx5
LiAgVGhpcyB3YXkgd2UgZ2V0IGEKICAqIGNvbXBpbGVyLWNoZWNrYWJsZSB3YXkgdG8gdXNlIGNv
bW1vbiBzdHJ1Y3QgZWxlbWVudHMsIHNvIHdlIGNhbgpAQCAtNzcsMTEgKzg4LDIxIEBAIHN0cnVj
dCBibGtpZl94ODZfMzJfcmVxdWVzdF9kaXNjYXJkIHsKIAl1aW50NjRfdCAgICAgICBucl9zZWN0
b3JzOwogfSBfX2F0dHJpYnV0ZV9fKChfX3BhY2tlZF9fKSk7CiAKK3N0cnVjdCBibGtpZl94ODZf
MzJfcmVxdWVzdF9pbmRpcmVjdCB7CisJdWludDhfdCAgICAgICAgaW5kaXJlY3Rfb3A7CisJdWlu
dDE2X3QgICAgICAgbnJfc2VnbWVudHM7CisJdWludDY0X3QgICAgICAgaWQ7CisJYmxraWZfdmRl
dl90ICAgaGFuZGxlOworCWJsa2lmX3NlY3Rvcl90IHNlY3Rvcl9udW1iZXI7CisJZ3JhbnRfcmVm
X3QgICAgaW5kaXJlY3RfZ3JlZnNbQkxLSUZfTUFYX0lORElSRUNUX0dSRUZTX1BFUl9SRVFVRVNU
XTsKK30gX19hdHRyaWJ1dGVfXygoX19wYWNrZWRfXykpOworCiBzdHJ1Y3QgYmxraWZfeDg2XzMy
X3JlcXVlc3QgewogCXVpbnQ4X3QgICAgICAgIG9wZXJhdGlvbjsgICAgLyogQkxLSUZfT1BfPz8/
ICAgICAgICAgICAgICAgICAgICAgICAgICovCiAJdW5pb24gewogCQlzdHJ1Y3QgYmxraWZfeDg2
XzMyX3JlcXVlc3Rfcncgcnc7CiAJCXN0cnVjdCBibGtpZl94ODZfMzJfcmVxdWVzdF9kaXNjYXJk
IGRpc2NhcmQ7CisJCXN0cnVjdCBibGtpZl94ODZfMzJfcmVxdWVzdF9pbmRpcmVjdCBpbmRpcmVj
dDsKIAl9IHU7CiB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKIApAQCAtMTEzLDExICsx
MzQsMjIgQEAgc3RydWN0IGJsa2lmX3g4Nl82NF9yZXF1ZXN0X2Rpc2NhcmQgewogCXVpbnQ2NF90
ICAgICAgIG5yX3NlY3RvcnM7CiB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKIAorc3Ry
dWN0IGJsa2lmX3g4Nl82NF9yZXF1ZXN0X2luZGlyZWN0IHsKKwl1aW50OF90ICAgICAgICBpbmRp
cmVjdF9vcDsKKwl1aW50MTZfdCAgICAgICBucl9zZWdtZW50czsKKwl1aW50MzJfdCAgICAgICBf
cGFkMTsgICAgICAgIC8qIG9mZnNldG9mKGJsa2lmXy4uLHUuaW5kaXJlY3QuaWQpPT04ICAgKi8K
Kwl1aW50NjRfdCAgICAgICBpZDsKKwlibGtpZl92ZGV2X3QgICBoYW5kbGU7CisJYmxraWZfc2Vj
dG9yX3Qgc2VjdG9yX251bWJlcjsKKwlncmFudF9yZWZfdCAgICBpbmRpcmVjdF9ncmVmc1tCTEtJ
Rl9NQVhfSU5ESVJFQ1RfR1JFRlNfUEVSX1JFUVVFU1RdOworfSBfX2F0dHJpYnV0ZV9fKChfX3Bh
Y2tlZF9fKSk7CisKIHN0cnVjdCBibGtpZl94ODZfNjRfcmVxdWVzdCB7CiAJdWludDhfdCAgICAg
ICAgb3BlcmF0aW9uOyAgICAvKiBCTEtJRl9PUF8/Pz8gICAgICAgICAgICAgICAgICAgICAgICAg
Ki8KIAl1bmlvbiB7CiAJCXN0cnVjdCBibGtpZl94ODZfNjRfcmVxdWVzdF9ydyBydzsKIAkJc3Ry
dWN0IGJsa2lmX3g4Nl82NF9yZXF1ZXN0X2Rpc2NhcmQgZGlzY2FyZDsKKwkJc3RydWN0IGJsa2lm
X3g4Nl82NF9yZXF1ZXN0X2luZGlyZWN0IGluZGlyZWN0OwogCX0gdTsKIH0gX19hdHRyaWJ1dGVf
XygoX19wYWNrZWRfXykpOwogCkBAIC0yMzUsNiArMjY3LDExIEBAIHN0cnVjdCB4ZW5fYmxraWYg
ewogCXdhaXRfcXVldWVfaGVhZF90CXdhaXRpbmdfdG9fZnJlZTsKIH07CiAKK3N0cnVjdCBzZWdf
YnVmIHsKKwl1bnNpZ25lZCBsb25nIGJ1ZjsKKwl1bnNpZ25lZCBpbnQgbnNlYzsKK307CisKIC8q
CiAgKiBFYWNoIG91dHN0YW5kaW5nIHJlcXVlc3QgdGhhdCB3ZSd2ZSBwYXNzZWQgdG8gdGhlIGxv
d2VyIGRldmljZSBsYXllcnMgaGFzIGEKICAqICdwZW5kaW5nX3JlcScgYWxsb2NhdGVkIHRvIGl0
LiBFYWNoIGJ1ZmZlcl9oZWFkIHRoYXQgY29tcGxldGVzIGRlY3JlbWVudHMKQEAgLTI0OSw5ICsy
ODYsMTYgQEAgc3RydWN0IHBlbmRpbmdfcmVxIHsKIAl1bnNpZ25lZCBzaG9ydAkJb3BlcmF0aW9u
OwogCWludAkJCXN0YXR1czsKIAlzdHJ1Y3QgbGlzdF9oZWFkCWZyZWVfbGlzdDsKLQlzdHJ1Y3Qg
cGVyc2lzdGVudF9nbnQJKnBlcnNpc3RlbnRfZ250c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JF
UVVFU1RdOwotCXN0cnVjdCBwYWdlCQkqcGFnZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFV
RVNUXTsKLQlncmFudF9oYW5kbGVfdAkJZ3JhbnRfaGFuZGxlc1tCTEtJRl9NQVhfU0VHTUVOVFNf
UEVSX1JFUVVFU1RdOworCXN0cnVjdCBwZXJzaXN0ZW50X2dudAkqcGVyc2lzdGVudF9nbnRzW01B
WF9JTkRJUkVDVF9TRUdNRU5UU107CisJc3RydWN0IHBhZ2UJCSpwYWdlc1tNQVhfSU5ESVJFQ1Rf
U0VHTUVOVFNdOworCWdyYW50X2hhbmRsZV90CQlncmFudF9oYW5kbGVzW01BWF9JTkRJUkVDVF9T
RUdNRU5UU107CisJZ3JhbnRfcmVmX3QJCWdyZWZzW01BWF9JTkRJUkVDVF9TRUdNRU5UU107CisJ
LyogSW5kaXJlY3QgZGVzY3JpcHRvcnMgKi8KKwlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQJKmluZGly
ZWN0X3BlcnNpc3RlbnRfZ250c1tNQVhfSU5ESVJFQ1RfR1JFRlNdOworCXN0cnVjdCBwYWdlCQkq
aW5kaXJlY3RfcGFnZXNbTUFYX0lORElSRUNUX0dSRUZTXTsKKwlncmFudF9oYW5kbGVfdAkJaW5k
aXJlY3RfaGFuZGxlc1tNQVhfSU5ESVJFQ1RfR1JFRlNdOworCXN0cnVjdCBzZWdfYnVmCQlzZWdb
TUFYX0lORElSRUNUX1NFR01FTlRTXTsKKwlzdHJ1Y3QgYmlvCQkqYmlvbGlzdFtNQVhfSU5ESVJF
Q1RfU0VHTUVOVFNdOwogfTsKIAogCkBAIC0yODksNyArMzMzLDcgQEAgc3RydWN0IHhlbmJ1c19k
ZXZpY2UgKnhlbl9ibGtia194ZW5idXMoc3RydWN0IGJhY2tlbmRfaW5mbyAqYmUpOwogc3RhdGlj
IGlubGluZSB2b2lkIGJsa2lmX2dldF94ODZfMzJfcmVxKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpk
c3QsCiAJCQkJCXN0cnVjdCBibGtpZl94ODZfMzJfcmVxdWVzdCAqc3JjKQogewotCWludCBpLCBu
ID0gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUOworCWludCBpLCBuID0gQkxLSUZfTUFY
X1NFR01FTlRTX1BFUl9SRVFVRVNULCBqID0gTUFYX0lORElSRUNUX0dSRUZTOwogCWRzdC0+b3Bl
cmF0aW9uID0gc3JjLT5vcGVyYXRpb247CiAJc3dpdGNoIChzcmMtPm9wZXJhdGlvbikgewogCWNh
c2UgQkxLSUZfT1BfUkVBRDoKQEAgLTMxMiw2ICszNTYsMTkgQEAgc3RhdGljIGlubGluZSB2b2lk
IGJsa2lmX2dldF94ODZfMzJfcmVxKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpkc3QsCiAJCWRzdC0+
dS5kaXNjYXJkLnNlY3Rvcl9udW1iZXIgPSBzcmMtPnUuZGlzY2FyZC5zZWN0b3JfbnVtYmVyOwog
CQlkc3QtPnUuZGlzY2FyZC5ucl9zZWN0b3JzID0gc3JjLT51LmRpc2NhcmQubnJfc2VjdG9yczsK
IAkJYnJlYWs7CisJY2FzZSBCTEtJRl9PUF9JTkRJUkVDVDoKKwkJZHN0LT51LmluZGlyZWN0Lmlu
ZGlyZWN0X29wID0gc3JjLT51LmluZGlyZWN0LmluZGlyZWN0X29wOworCQlkc3QtPnUuaW5kaXJl
Y3QubnJfc2VnbWVudHMgPSBzcmMtPnUuaW5kaXJlY3QubnJfc2VnbWVudHM7CisJCWRzdC0+dS5p
bmRpcmVjdC5oYW5kbGUgPSBzcmMtPnUuaW5kaXJlY3QuaGFuZGxlOworCQlkc3QtPnUuaW5kaXJl
Y3QuaWQgPSBzcmMtPnUuaW5kaXJlY3QuaWQ7CisJCWRzdC0+dS5pbmRpcmVjdC5zZWN0b3JfbnVt
YmVyID0gc3JjLT51LmluZGlyZWN0LnNlY3Rvcl9udW1iZXI7CisJCWJhcnJpZXIoKTsKKwkJaWYg
KGogPiBkc3QtPnUuaW5kaXJlY3QubnJfc2VnbWVudHMpCisJCQlqID0gZHN0LT51LmluZGlyZWN0
Lm5yX3NlZ21lbnRzOworCQlmb3IgKGkgPSAwOyBpIDwgajsgaSsrKQorCQkJZHN0LT51LmluZGly
ZWN0LmluZGlyZWN0X2dyZWZzW2ldID0KKwkJCQlzcmMtPnUuaW5kaXJlY3QuaW5kaXJlY3RfZ3Jl
ZnNbaV07CisJCWJyZWFrOwogCWRlZmF1bHQ6CiAJCWJyZWFrOwogCX0KQEAgLTMyMCw3ICszNzcs
NyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgYmxraWZfZ2V0X3g4Nl8zMl9yZXEoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKmRzdCwKIHN0YXRpYyBpbmxpbmUgdm9pZCBibGtpZl9nZXRfeDg2XzY0X3JlcShz
dHJ1Y3QgYmxraWZfcmVxdWVzdCAqZHN0LAogCQkJCQlzdHJ1Y3QgYmxraWZfeDg2XzY0X3JlcXVl
c3QgKnNyYykKIHsKLQlpbnQgaSwgbiA9IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVDsK
KwlpbnQgaSwgbiA9IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCwgaiA9IE1BWF9JTkRJ
UkVDVF9HUkVGUzsKIAlkc3QtPm9wZXJhdGlvbiA9IHNyYy0+b3BlcmF0aW9uOwogCXN3aXRjaCAo
c3JjLT5vcGVyYXRpb24pIHsKIAljYXNlIEJMS0lGX09QX1JFQUQ6CkBAIC0zNDMsNiArNDAwLDE5
IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBibGtpZl9nZXRfeDg2XzY0X3JlcShzdHJ1Y3QgYmxraWZf
cmVxdWVzdCAqZHN0LAogCQlkc3QtPnUuZGlzY2FyZC5zZWN0b3JfbnVtYmVyID0gc3JjLT51LmRp
c2NhcmQuc2VjdG9yX251bWJlcjsKIAkJZHN0LT51LmRpc2NhcmQubnJfc2VjdG9ycyA9IHNyYy0+
dS5kaXNjYXJkLm5yX3NlY3RvcnM7CiAJCWJyZWFrOworCWNhc2UgQkxLSUZfT1BfSU5ESVJFQ1Q6
CisJCWRzdC0+dS5pbmRpcmVjdC5pbmRpcmVjdF9vcCA9IHNyYy0+dS5pbmRpcmVjdC5pbmRpcmVj
dF9vcDsKKwkJZHN0LT51LmluZGlyZWN0Lm5yX3NlZ21lbnRzID0gc3JjLT51LmluZGlyZWN0Lm5y
X3NlZ21lbnRzOworCQlkc3QtPnUuaW5kaXJlY3QuaGFuZGxlID0gc3JjLT51LmluZGlyZWN0Lmhh
bmRsZTsKKwkJZHN0LT51LmluZGlyZWN0LmlkID0gc3JjLT51LmluZGlyZWN0LmlkOworCQlkc3Qt
PnUuaW5kaXJlY3Quc2VjdG9yX251bWJlciA9IHNyYy0+dS5pbmRpcmVjdC5zZWN0b3JfbnVtYmVy
OworCQliYXJyaWVyKCk7CisJCWlmIChqID4gZHN0LT51LmluZGlyZWN0Lm5yX3NlZ21lbnRzKQor
CQkJaiA9IGRzdC0+dS5pbmRpcmVjdC5ucl9zZWdtZW50czsKKwkJZm9yIChpID0gMDsgaSA8IGo7
IGkrKykKKwkJCWRzdC0+dS5pbmRpcmVjdC5pbmRpcmVjdF9ncmVmc1tpXSA9CisJCQkJc3JjLT51
LmluZGlyZWN0LmluZGlyZWN0X2dyZWZzW2ldOworCQlicmVhazsKIAlkZWZhdWx0OgogCQlicmVh
azsKIAl9CmRpZmYgLS1naXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jIGIv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYwppbmRleCA4ZjkyOWNiLi45ZTE2YWJi
IDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCisrKyBiL2Ry
aXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKQEAgLTcwMCw2ICs3MDAsMTQgQEAgYWdh
aW46CiAJCWdvdG8gYWJvcnQ7CiAJfQogCisJZXJyID0geGVuYnVzX3ByaW50Zih4YnQsIGRldi0+
bm9kZW5hbWUsICJtYXgtaW5kaXJlY3Qtc2VnbWVudHMiLCAiJXUiLAorCSAgICAgICAgICAgICAg
ICAgICAgTUFYX0lORElSRUNUX1NFR01FTlRTKTsKKwlpZiAoZXJyKSB7CisJCXhlbmJ1c19kZXZf
ZmF0YWwoZGV2LCBlcnIsICJ3cml0aW5nICVzL21heC1pbmRpcmVjdC1zZWdtZW50cyIsCisJCQkJ
IGRldi0+bm9kZW5hbWUpOworCQlnb3RvIGFib3J0OworCX0KKwogCWVyciA9IHhlbmJ1c19wcmlu
dGYoeGJ0LCBkZXYtPm5vZGVuYW1lLCAic2VjdG9ycyIsICIlbGx1IiwKIAkJCSAgICAodW5zaWdu
ZWQgbG9uZyBsb25nKXZiZF9zeigmYmUtPmJsa2lmLT52YmQpKTsKIAlpZiAoZXJyKSB7CmRpZmYg
LS1naXQgYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9jay94ZW4t
YmxrZnJvbnQuYwppbmRleCA0ZDgxZmNjLi4wNzRkMzAyIDEwMDY0NAotLS0gYS9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtmcm9udC5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKQEAg
LTc0LDEyICs3NCwzMCBAQCBzdHJ1Y3QgZ3JhbnQgewogc3RydWN0IGJsa19zaGFkb3cgewogCXN0
cnVjdCBibGtpZl9yZXF1ZXN0IHJlcTsKIAlzdHJ1Y3QgcmVxdWVzdCAqcmVxdWVzdDsKLQlzdHJ1
Y3QgZ3JhbnQgKmdyYW50c191c2VkW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CisJ
c3RydWN0IGdyYW50ICoqZ3JhbnRzX3VzZWQ7CisJc3RydWN0IGdyYW50ICoqaW5kaXJlY3RfZ3Jh
bnRzOworfTsKKworc3RydWN0IHNwbGl0X2JpbyB7CisJc3RydWN0IGJpbyAqYmlvOworCWF0b21p
Y190IHBlbmRpbmc7CisJaW50IGVycjsKIH07CiAKIHN0YXRpYyBERUZJTkVfTVVURVgoYmxrZnJv
bnRfbXV0ZXgpOwogc3RhdGljIGNvbnN0IHN0cnVjdCBibG9ja19kZXZpY2Vfb3BlcmF0aW9ucyB4
bHZiZF9ibG9ja19mb3BzOwogCisvKgorICogTWF4aW11bSBudW1iZXIgb2Ygc2VnbWVudHMgaW4g
aW5kaXJlY3QgcmVxdWVzdHMsIHRoZSBhY3R1YWwgdmFsdWUgdXNlZCBieQorICogdGhlIGZyb250
ZW5kIGRyaXZlciBpcyB0aGUgbWluaW11bSBvZiB0aGlzIHZhbHVlIGFuZCB0aGUgdmFsdWUgcHJv
dmlkZWQKKyAqIGJ5IHRoZSBiYWNrZW5kIGRyaXZlci4KKyAqLworCitzdGF0aWMgaW50IHhlbl9i
bGtpZl9tYXhfc2VnbWVudHMgPSA2NDsKK21vZHVsZV9wYXJhbV9uYW1lZChtYXhfc2VnbWVudHMs
IHhlbl9ibGtpZl9tYXhfc2VnbWVudHMsIGludCwgMCk7CitNT0RVTEVfUEFSTV9ERVNDKG1heF9z
ZWdtZW50cywKKyJNYXhpbXVtIG51bWJlciBvZiBzZWdtZW50cyBpbiBpbmRpcmVjdCByZXF1ZXN0
cyIpOworCiAjZGVmaW5lIEJMS19SSU5HX1NJWkUgX19DT05TVF9SSU5HX1NJWkUoYmxraWYsIFBB
R0VfU0laRSkKIAogLyoKQEAgLTk4LDcgKzExNiw3IEBAIHN0cnVjdCBibGtmcm9udF9pbmZvCiAJ
ZW51bSBibGtpZl9zdGF0ZSBjb25uZWN0ZWQ7CiAJaW50IHJpbmdfcmVmOwogCXN0cnVjdCBibGtp
Zl9mcm9udF9yaW5nIHJpbmc7Ci0Jc3RydWN0IHNjYXR0ZXJsaXN0IHNnW0JMS0lGX01BWF9TRUdN
RU5UU19QRVJfUkVRVUVTVF07CisJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsKIAl1bnNpZ25lZCBp
bnQgZXZ0Y2huLCBpcnE7CiAJc3RydWN0IHJlcXVlc3RfcXVldWUgKnJxOwogCXN0cnVjdCB3b3Jr
X3N0cnVjdCB3b3JrOwpAQCAtMTE0LDYgKzEzMiw4IEBAIHN0cnVjdCBibGtmcm9udF9pbmZvCiAJ
dW5zaWduZWQgaW50IGRpc2NhcmRfZ3JhbnVsYXJpdHk7CiAJdW5zaWduZWQgaW50IGRpc2NhcmRf
YWxpZ25tZW50OwogCXVuc2lnbmVkIGludCBmZWF0dXJlX3BlcnNpc3RlbnQ6MTsKKwl1bnNpZ25l
ZCBpbnQgbWF4X2luZGlyZWN0X3NlZ21lbnRzOworCXVuc2lnbmVkIGludCBzZWN0b3Jfc2l6ZTsK
IAlpbnQgaXNfcmVhZHk7CiB9OwogCkBAIC0xNDIsNiArMTYyLDE0IEBAIHN0YXRpYyBERUZJTkVf
U1BJTkxPQ0sobWlub3JfbG9jayk7CiAKICNkZWZpbmUgREVWX05BTUUJInh2ZCIJLyogbmFtZSBp
biAvZGV2ICovCiAKKyNkZWZpbmUgU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUgXAorCShQQUdFX1NJ
WkUvc2l6ZW9mKHN0cnVjdCBibGtpZl9yZXF1ZXN0X3NlZ21lbnRfYWxpZ25lZCkpCisjZGVmaW5l
IElORElSRUNUX0dSRUZTKF9zZWdzKSBcCisJKChfc2VncyArIFNFR1NfUEVSX0lORElSRUNUX0ZS
QU1FIC0gMSkvU0VHU19QRVJfSU5ESVJFQ1RfRlJBTUUpCisjZGVmaW5lIE1JTihfYSwgX2IpICgo
X2EpIDwgKF9iKSA/IChfYSkgOiAoX2IpKQorCitzdGF0aWMgaW50IGJsa2Zyb250X3NldHVwX2lu
ZGlyZWN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKTsKKwogc3RhdGljIGludCBnZXRfaWRf
ZnJvbV9mcmVlbGlzdChzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbykKIHsKIAl1bnNpZ25lZCBs
b25nIGZyZWUgPSBpbmZvLT5zaGFkb3dfZnJlZTsKQEAgLTM1OCw3ICszODYsOCBAQCBzdGF0aWMg
aW50IGJsa2lmX3F1ZXVlX3JlcXVlc3Qoc3RydWN0IHJlcXVlc3QgKnJlcSkKIAlzdHJ1Y3QgYmxr
aWZfcmVxdWVzdCAqcmluZ19yZXE7CiAJdW5zaWduZWQgbG9uZyBpZDsKIAl1bnNpZ25lZCBpbnQg
ZnNlY3QsIGxzZWN0OwotCWludCBpLCByZWY7CisJaW50IGksIHJlZiwgbjsKKwlzdHJ1Y3QgYmxr
aWZfcmVxdWVzdF9zZWdtZW50X2FsaWduZWQgKnNlZ21lbnRzID0gTlVMTDsKIAogCS8qCiAJICog
VXNlZCB0byBzdG9yZSBpZiB3ZSBhcmUgYWJsZSB0byBxdWV1ZSB0aGUgcmVxdWVzdCBieSBqdXN0
IHVzaW5nCkBAIC0zNjksMjEgKzM5OCwyNyBAQCBzdGF0aWMgaW50IGJsa2lmX3F1ZXVlX3JlcXVl
c3Qoc3RydWN0IHJlcXVlc3QgKnJlcSkKIAlncmFudF9yZWZfdCBncmVmX2hlYWQ7CiAJc3RydWN0
IGdyYW50ICpnbnRfbGlzdF9lbnRyeSA9IE5VTEw7CiAJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZzsK
KwlpbnQgbnNlZywgbWF4X2dyZWZzOwogCiAJaWYgKHVubGlrZWx5KGluZm8tPmNvbm5lY3RlZCAh
PSBCTEtJRl9TVEFURV9DT05ORUNURUQpKQogCQlyZXR1cm4gMTsKIAotCS8qIENoZWNrIGlmIHdl
IGhhdmUgZW5vdWdodCBncmFudHMgdG8gYWxsb2NhdGUgYSByZXF1ZXN0cyAqLwotCWlmIChpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYyA8IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCkgewor
CW1heF9ncmVmcyA9IGluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyA/CisJICAgICAgICAgICAg
aW5mby0+bWF4X2luZGlyZWN0X3NlZ21lbnRzICsKKwkgICAgICAgICAgICBJTkRJUkVDVF9HUkVG
UyhpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMpIDoKKwkgICAgICAgICAgICBCTEtJRl9NQVhf
U0VHTUVOVFNfUEVSX1JFUVVFU1Q7CisKKwkvKiBDaGVjayBpZiB3ZSBoYXZlIGVub3VnaCBncmFu
dHMgdG8gYWxsb2NhdGUgYSByZXF1ZXN0cyAqLworCWlmIChpbmZvLT5wZXJzaXN0ZW50X2dudHNf
YyA8IG1heF9ncmVmcykgewogCQluZXdfcGVyc2lzdGVudF9nbnRzID0gMTsKIAkJaWYgKGdudHRh
Yl9hbGxvY19ncmFudF9yZWZlcmVuY2VzKAotCQkgICAgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9S
RVFVRVNUIC0gaW5mby0+cGVyc2lzdGVudF9nbnRzX2MsCisJCSAgICBtYXhfZ3JlZnMgLSBpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYywKIAkJICAgICZncmVmX2hlYWQpIDwgMCkgewogCQkJZ250dGFi
X3JlcXVlc3RfZnJlZV9jYWxsYmFjaygKIAkJCQkmaW5mby0+Y2FsbGJhY2ssCiAJCQkJYmxraWZf
cmVzdGFydF9xdWV1ZV9jYWxsYmFjaywKIAkJCQlpbmZvLAotCQkJCUJMS0lGX01BWF9TRUdNRU5U
U19QRVJfUkVRVUVTVCk7CisJCQkJbWF4X2dyZWZzKTsKIAkJCXJldHVybiAxOwogCQl9CiAJfSBl
bHNlCkBAIC0zOTQsNDIgKzQyOSw4MiBAQCBzdGF0aWMgaW50IGJsa2lmX3F1ZXVlX3JlcXVlc3Qo
c3RydWN0IHJlcXVlc3QgKnJlcSkKIAlpZCA9IGdldF9pZF9mcm9tX2ZyZWVsaXN0KGluZm8pOwog
CWluZm8tPnNoYWRvd1tpZF0ucmVxdWVzdCA9IHJlcTsKIAotCXJpbmdfcmVxLT51LnJ3LmlkID0g
aWQ7Ci0JcmluZ19yZXEtPnUucncuc2VjdG9yX251bWJlciA9IChibGtpZl9zZWN0b3JfdClibGtf
cnFfcG9zKHJlcSk7Ci0JcmluZ19yZXEtPnUucncuaGFuZGxlID0gaW5mby0+aGFuZGxlOwotCi0J
cmluZ19yZXEtPm9wZXJhdGlvbiA9IHJxX2RhdGFfZGlyKHJlcSkgPwotCQlCTEtJRl9PUF9XUklU
RSA6IEJMS0lGX09QX1JFQUQ7Ci0KLQlpZiAocmVxLT5jbWRfZmxhZ3MgJiAoUkVRX0ZMVVNIIHwg
UkVRX0ZVQSkpIHsKLQkJLyoKLQkJICogSWRlYWxseSB3ZSBjYW4gZG8gYW4gdW5vcmRlcmVkIGZs
dXNoLXRvLWRpc2suIEluIGNhc2UgdGhlCi0JCSAqIGJhY2tlbmQgb25seXN1cHBvcnRzIGJhcnJp
ZXJzLCB1c2UgdGhhdC4gQSBiYXJyaWVyIHJlcXVlc3QKLQkJICogYSBzdXBlcnNldCBvZiBGVUEs
IHNvIHdlIGNhbiBpbXBsZW1lbnQgaXQgdGhlIHNhbWUKLQkJICogd2F5LiAgKEl0J3MgYWxzbyBh
IEZMVVNIK0ZVQSwgc2luY2UgaXQgaXMKLQkJICogZ3VhcmFudGVlZCBvcmRlcmVkIFdSVCBwcmV2
aW91cyB3cml0ZXMuKQotCQkgKi8KLQkJcmluZ19yZXEtPm9wZXJhdGlvbiA9IGluZm8tPmZsdXNo
X29wOwotCX0KLQogCWlmICh1bmxpa2VseShyZXEtPmNtZF9mbGFncyAmIChSRVFfRElTQ0FSRCB8
IFJFUV9TRUNVUkUpKSkgewogCQkvKiBpZCwgc2VjdG9yX251bWJlciBhbmQgaGFuZGxlIGFyZSBz
ZXQgYWJvdmUuICovCiAJCXJpbmdfcmVxLT5vcGVyYXRpb24gPSBCTEtJRl9PUF9ESVNDQVJEOwog
CQlyaW5nX3JlcS0+dS5kaXNjYXJkLm5yX3NlY3RvcnMgPSBibGtfcnFfc2VjdG9ycyhyZXEpOwor
CQlyaW5nX3JlcS0+dS5kaXNjYXJkLmlkID0gaWQ7CisJCXJpbmdfcmVxLT51LmRpc2NhcmQuc2Vj
dG9yX251bWJlciA9CisJCQkoYmxraWZfc2VjdG9yX3QpYmxrX3JxX3BvcyhyZXEpOwogCQlpZiAo
KHJlcS0+Y21kX2ZsYWdzICYgUkVRX1NFQ1VSRSkgJiYgaW5mby0+ZmVhdHVyZV9zZWNkaXNjYXJk
KQogCQkJcmluZ19yZXEtPnUuZGlzY2FyZC5mbGFnID0gQkxLSUZfRElTQ0FSRF9TRUNVUkU7CiAJ
CWVsc2UKIAkJCXJpbmdfcmVxLT51LmRpc2NhcmQuZmxhZyA9IDA7CiAJfSBlbHNlIHsKLQkJcmlu
Z19yZXEtPnUucncubnJfc2VnbWVudHMgPSBibGtfcnFfbWFwX3NnKHJlcS0+cSwgcmVxLAotCQkJ
CQkJCSAgIGluZm8tPnNnKTsKLQkJQlVHX09OKHJpbmdfcmVxLT51LnJ3Lm5yX3NlZ21lbnRzID4K
LQkJICAgICAgIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCk7Ci0KLQkJZm9yX2VhY2hf
c2coaW5mby0+c2csIHNnLCByaW5nX3JlcS0+dS5ydy5ucl9zZWdtZW50cywgaSkgeworCQlCVUdf
T04oaW5mby0+bWF4X2luZGlyZWN0X3NlZ21lbnRzID09IDAgJiYKKwkJICAgICAgIHJlcS0+bnJf
cGh5c19zZWdtZW50cyA+IEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVCk7CisJCUJVR19P
TihpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMgJiYKKwkJICAgICAgIHJlcS0+bnJfcGh5c19z
ZWdtZW50cyA+IGluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyk7CisJCW5zZWcgPSBibGtfcnFf
bWFwX3NnKHJlcS0+cSwgcmVxLCBpbmZvLT5zZyk7CisJCWlmIChuc2VnID4gQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUKSB7CisJCQkvKiBJbmRpcmVjdCBPUCAqLworCQkJcmluZ19yZXEt
Pm9wZXJhdGlvbiA9IEJMS0lGX09QX0lORElSRUNUOworCQkJcmluZ19yZXEtPnUuaW5kaXJlY3Qu
aW5kaXJlY3Rfb3AgPSBycV9kYXRhX2RpcihyZXEpID8KKwkJCQlCTEtJRl9PUF9XUklURSA6IEJM
S0lGX09QX1JFQUQ7CisJCQlyaW5nX3JlcS0+dS5pbmRpcmVjdC5pZCA9IGlkOworCQkJcmluZ19y
ZXEtPnUuaW5kaXJlY3Quc2VjdG9yX251bWJlciA9CisJCQkJKGJsa2lmX3NlY3Rvcl90KWJsa19y
cV9wb3MocmVxKTsKKwkJCXJpbmdfcmVxLT51LmluZGlyZWN0LmhhbmRsZSA9IGluZm8tPmhhbmRs
ZTsKKwkJCWlmIChyZXEtPmNtZF9mbGFncyAmIChSRVFfRkxVU0ggfCBSRVFfRlVBKSkgeworCQkv
KgorCQkgKiBJZGVhbGx5IHdlIGNhbiBkbyBhbiB1bm9yZGVyZWQgZmx1c2gtdG8tZGlzay4gSW4g
Y2FzZSB0aGUKKwkJICogYmFja2VuZCBvbmx5c3VwcG9ydHMgYmFycmllcnMsIHVzZSB0aGF0LiBB
IGJhcnJpZXIgcmVxdWVzdAorCQkgKiBhIHN1cGVyc2V0IG9mIEZVQSwgc28gd2UgY2FuIGltcGxl
bWVudCBpdCB0aGUgc2FtZQorCQkgKiB3YXkuICAoSXQncyBhbHNvIGEgRkxVU0grRlVBLCBzaW5j
ZSBpdCBpcworCQkgKiBndWFyYW50ZWVkIG9yZGVyZWQgV1JUIHByZXZpb3VzIHdyaXRlcy4pCisJ
CSAqLworCQkJCXJpbmdfcmVxLT51LmluZGlyZWN0LmluZGlyZWN0X29wID0KKwkJCQkJaW5mby0+
Zmx1c2hfb3A7CisJCQl9CisJCQlyaW5nX3JlcS0+dS5pbmRpcmVjdC5ucl9zZWdtZW50cyA9IG5z
ZWc7CisJCX0gZWxzZSB7CisJCQlyaW5nX3JlcS0+dS5ydy5pZCA9IGlkOworCQkJcmluZ19yZXEt
PnUucncuc2VjdG9yX251bWJlciA9CisJCQkJKGJsa2lmX3NlY3Rvcl90KWJsa19ycV9wb3MocmVx
KTsKKwkJCXJpbmdfcmVxLT51LnJ3LmhhbmRsZSA9IGluZm8tPmhhbmRsZTsKKwkJCXJpbmdfcmVx
LT5vcGVyYXRpb24gPSBycV9kYXRhX2RpcihyZXEpID8KKwkJCQlCTEtJRl9PUF9XUklURSA6IEJM
S0lGX09QX1JFQUQ7CisJCQlpZiAocmVxLT5jbWRfZmxhZ3MgJiAoUkVRX0ZMVVNIIHwgUkVRX0ZV
QSkpIHsKKwkJLyoKKwkJICogSWRlYWxseSB3ZSBjYW4gZG8gYW4gdW5vcmRlcmVkIGZsdXNoLXRv
LWRpc2suIEluIGNhc2UgdGhlCisJCSAqIGJhY2tlbmQgb25seXN1cHBvcnRzIGJhcnJpZXJzLCB1
c2UgdGhhdC4gQSBiYXJyaWVyIHJlcXVlc3QKKwkJICogYSBzdXBlcnNldCBvZiBGVUEsIHNvIHdl
IGNhbiBpbXBsZW1lbnQgaXQgdGhlIHNhbWUKKwkJICogd2F5LiAgKEl0J3MgYWxzbyBhIEZMVVNI
K0ZVQSwgc2luY2UgaXQgaXMKKwkJICogZ3VhcmFudGVlZCBvcmRlcmVkIFdSVCBwcmV2aW91cyB3
cml0ZXMuKQorCQkgKi8KKwkJCQlyaW5nX3JlcS0+b3BlcmF0aW9uID0gaW5mby0+Zmx1c2hfb3A7
CisJCQl9CisJCQlyaW5nX3JlcS0+dS5ydy5ucl9zZWdtZW50cyA9IG5zZWc7CisJCX0KKwkJZm9y
X2VhY2hfc2coaW5mby0+c2csIHNnLCBuc2VnLCBpKSB7CiAJCQlmc2VjdCA9IHNnLT5vZmZzZXQg
Pj4gOTsKIAkJCWxzZWN0ID0gZnNlY3QgKyAoc2ctPmxlbmd0aCA+PiA5KSAtIDE7CiAKKwkJCWlm
ICgocmluZ19yZXEtPm9wZXJhdGlvbiA9PSBCTEtJRl9PUF9JTkRJUkVDVCkgJiYKKwkJCSAgICAo
aSAlIFNFR1NfUEVSX0lORElSRUNUX0ZSQU1FID09IDApKSB7CisJCQkJaWYgKHNlZ21lbnRzKQor
CQkJCQlrdW5tYXBfYXRvbWljKHNlZ21lbnRzKTsKKworCQkJCW4gPSBpIC8gU0VHU19QRVJfSU5E
SVJFQ1RfRlJBTUU7CisJCQkJZ250X2xpc3RfZW50cnkgPSBnZXRfZ3JhbnQoJmdyZWZfaGVhZCwg
aW5mbyk7CisJCQkJaW5mby0+c2hhZG93W2lkXS5pbmRpcmVjdF9ncmFudHNbbl0gPQorCQkJCQln
bnRfbGlzdF9lbnRyeTsKKwkJCQlzZWdtZW50cyA9IGttYXBfYXRvbWljKAorCQkJCQlwZm5fdG9f
cGFnZShnbnRfbGlzdF9lbnRyeS0+cGZuKSk7CisJCQkJcmluZ19yZXEtPnUuaW5kaXJlY3QuaW5k
aXJlY3RfZ3JlZnNbbl0gPQorCQkJCQlnbnRfbGlzdF9lbnRyeS0+Z3JlZjsKKwkJCX0KKwogCQkJ
Z250X2xpc3RfZW50cnkgPSBnZXRfZ3JhbnQoJmdyZWZfaGVhZCwgaW5mbyk7CiAJCQlyZWYgPSBn
bnRfbGlzdF9lbnRyeS0+Z3JlZjsKIApAQCAtNDYxLDEzICs1MzYsMjMgQEAgc3RhdGljIGludCBi
bGtpZl9xdWV1ZV9yZXF1ZXN0KHN0cnVjdCByZXF1ZXN0ICpyZXEpCiAJCQkJa3VubWFwX2F0b21p
YyhidmVjX2RhdGEpOwogCQkJCWt1bm1hcF9hdG9taWMoc2hhcmVkX2RhdGEpOwogCQkJfQotCi0J
CQlyaW5nX3JlcS0+dS5ydy5zZWdbaV0gPQotCQkJCQkoc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2Vn
bWVudCkgewotCQkJCQkJLmdyZWYgICAgICAgPSByZWYsCi0JCQkJCQkuZmlyc3Rfc2VjdCA9IGZz
ZWN0LAotCQkJCQkJLmxhc3Rfc2VjdCAgPSBsc2VjdCB9OworCQkJaWYgKHJpbmdfcmVxLT5vcGVy
YXRpb24gIT0gQkxLSUZfT1BfSU5ESVJFQ1QpIHsKKwkJCQlyaW5nX3JlcS0+dS5ydy5zZWdbaV0g
PQorCQkJCQkJKHN0cnVjdCBibGtpZl9yZXF1ZXN0X3NlZ21lbnQpIHsKKwkJCQkJCQkuZ3JlZiAg
ICAgICA9IHJlZiwKKwkJCQkJCQkuZmlyc3Rfc2VjdCA9IGZzZWN0LAorCQkJCQkJCS5sYXN0X3Nl
Y3QgID0gbHNlY3QgfTsKKwkJCX0gZWxzZSB7CisJCQkJbiA9IGkgJSBTRUdTX1BFUl9JTkRJUkVD
VF9GUkFNRTsKKwkJCQlzZWdtZW50c1tuXSA9CisJCQkJCShzdHJ1Y3QgYmxraWZfcmVxdWVzdF9z
ZWdtZW50X2FsaWduZWQpIHsKKwkJCQkJCQkuZ3JlZiAgICAgICA9IHJlZiwKKwkJCQkJCQkuZmly
c3Rfc2VjdCA9IGZzZWN0LAorCQkJCQkJCS5sYXN0X3NlY3QgID0gbHNlY3QgfTsKKwkJCX0KIAkJ
fQorCQlpZiAoc2VnbWVudHMpCisJCQlrdW5tYXBfYXRvbWljKHNlZ21lbnRzKTsKIAl9CiAKIAlp
bmZvLT5yaW5nLnJlcV9wcm9kX3B2dCsrOwpAQCAtNTQyLDcgKzYyNyw4IEBAIHdhaXQ6CiAJCWZs
dXNoX3JlcXVlc3RzKGluZm8pOwogfQogCi1zdGF0aWMgaW50IHhsdmJkX2luaXRfYmxrX3F1ZXVl
KHN0cnVjdCBnZW5kaXNrICpnZCwgdTE2IHNlY3Rvcl9zaXplKQorc3RhdGljIGludCB4bHZiZF9p
bml0X2Jsa19xdWV1ZShzdHJ1Y3QgZ2VuZGlzayAqZ2QsIHUxNiBzZWN0b3Jfc2l6ZSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHNlZ21lbnRzKQogewogCXN0
cnVjdCByZXF1ZXN0X3F1ZXVlICpycTsKIAlzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbyA9IGdk
LT5wcml2YXRlX2RhdGE7CkBAIC01NzEsNyArNjU3LDcgQEAgc3RhdGljIGludCB4bHZiZF9pbml0
X2Jsa19xdWV1ZShzdHJ1Y3QgZ2VuZGlzayAqZ2QsIHUxNiBzZWN0b3Jfc2l6ZSkKIAlibGtfcXVl
dWVfbWF4X3NlZ21lbnRfc2l6ZShycSwgUEFHRV9TSVpFKTsKIAogCS8qIEVuc3VyZSBhIG1lcmdl
ZCByZXF1ZXN0IHdpbGwgZml0IGluIGEgc2luZ2xlIEkvTyByaW5nIHNsb3QuICovCi0JYmxrX3F1
ZXVlX21heF9zZWdtZW50cyhycSwgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUKTsKKwli
bGtfcXVldWVfbWF4X3NlZ21lbnRzKHJxLCBzZWdtZW50cyk7CiAKIAkvKiBNYWtlIHN1cmUgYnVm
ZmVyIGFkZHJlc3NlcyBhcmUgc2VjdG9yLWFsaWduZWQuICovCiAJYmxrX3F1ZXVlX2RtYV9hbGln
bm1lbnQocnEsIDUxMSk7CkBAIC01ODgsMTMgKzY3NCwxNCBAQCBzdGF0aWMgaW50IHhsdmJkX2lu
aXRfYmxrX3F1ZXVlKHN0cnVjdCBnZW5kaXNrICpnZCwgdTE2IHNlY3Rvcl9zaXplKQogc3RhdGlj
IHZvaWQgeGx2YmRfZmx1c2goc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiB7CiAJYmxrX3F1
ZXVlX2ZsdXNoKGluZm8tPnJxLCBpbmZvLT5mZWF0dXJlX2ZsdXNoKTsKLQlwcmludGsoS0VSTl9J
TkZPICJibGtmcm9udDogJXM6ICVzOiAlcyAlc1xuIiwKKwlwcmludGsoS0VSTl9JTkZPICJibGtm
cm9udDogJXM6ICVzOiAlcyAlcyAlc1xuIiwKIAkgICAgICAgaW5mby0+Z2QtPmRpc2tfbmFtZSwK
IAkgICAgICAgaW5mby0+Zmx1c2hfb3AgPT0gQkxLSUZfT1BfV1JJVEVfQkFSUklFUiA/CiAJCSJi
YXJyaWVyIiA6IChpbmZvLT5mbHVzaF9vcCA9PSBCTEtJRl9PUF9GTFVTSF9ESVNLQ0FDSEUgPwog
CQkiZmx1c2ggZGlza2NhY2hlIiA6ICJiYXJyaWVyIG9yIGZsdXNoIiksCiAJICAgICAgIGluZm8t
PmZlYXR1cmVfZmx1c2ggPyAiZW5hYmxlZCIgOiAiZGlzYWJsZWQiLAotCSAgICAgICBpbmZvLT5m
ZWF0dXJlX3BlcnNpc3RlbnQgPyAidXNpbmcgcGVyc2lzdGVudCBncmFudHMiIDogIiIpOworCSAg
ICAgICBpbmZvLT5mZWF0dXJlX3BlcnNpc3RlbnQgPyAidXNpbmcgcGVyc2lzdGVudCBncmFudHMi
IDogIiIsCisJICAgICAgIGluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyA/ICJ1c2luZyBpbmRp
cmVjdCBkZXNjcmlwdG9ycyIgOiAiIik7CiB9CiAKIHN0YXRpYyBpbnQgeGVuX3RyYW5zbGF0ZV92
ZGV2KGludCB2ZGV2aWNlLCBpbnQgKm1pbm9yLCB1bnNpZ25lZCBpbnQgKm9mZnNldCkKQEAgLTcz
NCw3ICs4MjEsOSBAQCBzdGF0aWMgaW50IHhsdmJkX2FsbG9jX2dlbmRpc2soYmxraWZfc2VjdG9y
X3QgY2FwYWNpdHksCiAJZ2QtPmRyaXZlcmZzX2RldiA9ICYoaW5mby0+eGJkZXYtPmRldik7CiAJ
c2V0X2NhcGFjaXR5KGdkLCBjYXBhY2l0eSk7CiAKLQlpZiAoeGx2YmRfaW5pdF9ibGtfcXVldWUo
Z2QsIHNlY3Rvcl9zaXplKSkgeworCWlmICh4bHZiZF9pbml0X2Jsa19xdWV1ZShnZCwgc2VjdG9y
X3NpemUsCisJICAgICAgICAgICAgICAgICAgICAgICAgIGluZm8tPm1heF9pbmRpcmVjdF9zZWdt
ZW50cyA/IDoKKwkgICAgICAgICAgICAgICAgICAgICAgICAgQkxLSUZfTUFYX1NFR01FTlRTX1BF
Ul9SRVFVRVNUKSkgewogCQlkZWxfZ2VuZGlzayhnZCk7CiAJCWdvdG8gcmVsZWFzZTsKIAl9CkBA
IC04MTgsNiArOTA3LDcgQEAgc3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRf
aW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiB7CiAJc3RydWN0IGdyYW50ICpwZXJzaXN0ZW50X2du
dDsKIAlzdHJ1Y3QgZ3JhbnQgKm47CisJaW50IGksIGosIHNlZ3M7CiAKIAkvKiBQcmV2ZW50IG5l
dyByZXF1ZXN0cyBiZWluZyBpc3N1ZWQgdW50aWwgd2UgZml4IHRoaW5ncyB1cC4gKi8KIAlzcGlu
X2xvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKQEAgLTg0Myw2ICs5MzMsNDcgQEAgc3RhdGljIHZv
aWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpCiAJ
fQogCUJVR19PTihpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyAhPSAwKTsKIAorCWtmcmVlKGluZm8t
PnNnKTsKKwlpbmZvLT5zZyA9IE5VTEw7CisJZm9yIChpID0gMDsgaSA8IEJMS19SSU5HX1NJWkU7
IGkrKykgeworCQkvKgorCQkgKiBDbGVhciBwZXJzaXN0ZW50IGdyYW50cyBwcmVzZW50IGluIHJl
cXVlc3RzIGFscmVhZHkKKwkJICogb24gdGhlIHNoYXJlZCByaW5nCisJCSAqLworCQlpZiAoIWlu
Zm8tPnNoYWRvd1tpXS5yZXF1ZXN0KQorCQkJZ290byBmcmVlX3NoYWRvdzsKKworCQlzZWdzID0g
aW5mby0+c2hhZG93W2ldLnJlcS5vcGVyYXRpb24gPT0gQkxLSUZfT1BfSU5ESVJFQ1QgPworCQkg
ICAgICAgaW5mby0+c2hhZG93W2ldLnJlcS51LmluZGlyZWN0Lm5yX3NlZ21lbnRzIDoKKwkJICAg
ICAgIGluZm8tPnNoYWRvd1tpXS5yZXEudS5ydy5ucl9zZWdtZW50czsKKwkJZm9yIChqID0gMDsg
aiA8IHNlZ3M7IGorKykgeworCQkJcGVyc2lzdGVudF9nbnQgPSBpbmZvLT5zaGFkb3dbaV0uZ3Jh
bnRzX3VzZWRbal07CisJCQlnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzKHBlcnNpc3RlbnRfZ250
LT5ncmVmLCAwLCAwVUwpOworCQkJX19mcmVlX3BhZ2UocGZuX3RvX3BhZ2UocGVyc2lzdGVudF9n
bnQtPnBmbikpOworCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOworCQl9CisKKwkJaWYgKGluZm8t
PnNoYWRvd1tpXS5yZXEub3BlcmF0aW9uICE9IEJMS0lGX09QX0lORElSRUNUKQorCQkJLyoKKwkJ
CSAqIElmIHRoaXMgaXMgbm90IGFuIGluZGlyZWN0IG9wZXJhdGlvbiBkb24ndCB0cnkgdG8KKwkJ
CSAqIGZyZWUgaW5kaXJlY3Qgc2VnbWVudHMKKwkJCSAqLworCQkJZ290byBmcmVlX3NoYWRvdzsK
KworCQlmb3IgKGogPSAwOyBqIDwgSU5ESVJFQ1RfR1JFRlMoc2Vncyk7IGorKykgeworCQkJcGVy
c2lzdGVudF9nbnQgPSBpbmZvLT5zaGFkb3dbaV0uaW5kaXJlY3RfZ3JhbnRzW2pdOworCQkJZ250
dGFiX2VuZF9mb3JlaWduX2FjY2VzcyhwZXJzaXN0ZW50X2dudC0+Z3JlZiwgMCwgMFVMKTsKKwkJ
CV9fZnJlZV9wYWdlKHBmbl90b19wYWdlKHBlcnNpc3RlbnRfZ250LT5wZm4pKTsKKwkJCWtmcmVl
KHBlcnNpc3RlbnRfZ250KTsKKwkJfQorCitmcmVlX3NoYWRvdzoKKwkJa2ZyZWUoaW5mby0+c2hh
ZG93W2ldLmdyYW50c191c2VkKTsKKwkJaW5mby0+c2hhZG93W2ldLmdyYW50c191c2VkID0gTlVM
TDsKKwkJa2ZyZWUoaW5mby0+c2hhZG93W2ldLmluZGlyZWN0X2dyYW50cyk7CisJCWluZm8tPnNo
YWRvd1tpXS5pbmRpcmVjdF9ncmFudHMgPSBOVUxMOworCX0KKwogCS8qIE5vIG1vcmUgZ250dGFi
IGNhbGxiYWNrIHdvcmsuICovCiAJZ250dGFiX2NhbmNlbF9mcmVlX2NhbGxiYWNrKCZpbmZvLT5j
YWxsYmFjayk7CiAJc3Bpbl91bmxvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKQEAgLTg3Myw2ICsx
MDA0LDEwIEBAIHN0YXRpYyB2b2lkIGJsa2lmX2NvbXBsZXRpb24oc3RydWN0IGJsa19zaGFkb3cg
KnMsIHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvLAogCWNoYXIgKmJ2ZWNfZGF0YTsKIAl2b2lk
ICpzaGFyZWRfZGF0YTsKIAl1bnNpZ25lZCBpbnQgb2Zmc2V0ID0gMDsKKwlpbnQgbnNlZzsKKwor
CW5zZWcgPSBzLT5yZXEub3BlcmF0aW9uID09IEJMS0lGX09QX0lORElSRUNUID8KKwkJcy0+cmVx
LnUuaW5kaXJlY3QubnJfc2VnbWVudHMgOiBzLT5yZXEudS5ydy5ucl9zZWdtZW50czsKIAogCWlm
IChicmV0LT5vcGVyYXRpb24gPT0gQkxLSUZfT1BfUkVBRCkgewogCQkvKgpAQCAtODg1LDcgKzEw
MjAsNyBAQCBzdGF0aWMgdm9pZCBibGtpZl9jb21wbGV0aW9uKHN0cnVjdCBibGtfc2hhZG93ICpz
LCBzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywKIAkJCUJVR19PTigoYnZlYy0+YnZfb2Zmc2V0
ICsgYnZlYy0+YnZfbGVuKSA+IFBBR0VfU0laRSk7CiAJCQlpZiAoYnZlYy0+YnZfb2Zmc2V0IDwg
b2Zmc2V0KQogCQkJCWkrKzsKLQkJCUJVR19PTihpID49IHMtPnJlcS51LnJ3Lm5yX3NlZ21lbnRz
KTsKKwkJCUJVR19PTihpID49IG5zZWcpOwogCQkJc2hhcmVkX2RhdGEgPSBrbWFwX2F0b21pYygK
IAkJCQlwZm5fdG9fcGFnZShzLT5ncmFudHNfdXNlZFtpXS0+cGZuKSk7CiAJCQlidmVjX2RhdGEg
PSBidmVjX2ttYXBfaXJxKGJ2ZWMsICZmbGFncyk7CkBAIC04OTcsMTAgKzEwMzIsMTcgQEAgc3Rh
dGljIHZvaWQgYmxraWZfY29tcGxldGlvbihzdHJ1Y3QgYmxrX3NoYWRvdyAqcywgc3RydWN0IGJs
a2Zyb250X2luZm8gKmluZm8sCiAJCX0KIAl9CiAJLyogQWRkIHRoZSBwZXJzaXN0ZW50IGdyYW50
IGludG8gdGhlIGxpc3Qgb2YgZnJlZSBncmFudHMgKi8KLQlmb3IgKGkgPSAwOyBpIDwgcy0+cmVx
LnUucncubnJfc2VnbWVudHM7IGkrKykgeworCWZvciAoaSA9IDA7IGkgPCBuc2VnOyBpKyspIHsK
IAkJbGlzdF9hZGQoJnMtPmdyYW50c191c2VkW2ldLT5ub2RlLCAmaW5mby0+cGVyc2lzdGVudF9n
bnRzKTsKIAkJaW5mby0+cGVyc2lzdGVudF9nbnRzX2MrKzsKIAl9CisJaWYgKHMtPnJlcS5vcGVy
YXRpb24gPT0gQkxLSUZfT1BfSU5ESVJFQ1QpIHsKKwkJZm9yIChpID0gMDsgaSA8IElORElSRUNU
X0dSRUZTKG5zZWcpOyBpKyspIHsKKwkJCWxpc3RfYWRkKCZzLT5pbmRpcmVjdF9ncmFudHNbaV0t
Pm5vZGUsCisJCQkgICAgICAgICAmaW5mby0+cGVyc2lzdGVudF9nbnRzKTsKKwkJCWluZm8tPnBl
cnNpc3RlbnRfZ250c19jKys7CisJCX0KKwl9CiB9CiAKIHN0YXRpYyBpcnFyZXR1cm5fdCBibGtp
Zl9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQpAQCAtMTAzNCw4ICsxMTc2LDYgQEAg
c3RhdGljIGludCBzZXR1cF9ibGtyaW5nKHN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYsCiAJU0hB
UkVEX1JJTkdfSU5JVChzcmluZyk7CiAJRlJPTlRfUklOR19JTklUKCZpbmZvLT5yaW5nLCBzcmlu
ZywgUEFHRV9TSVpFKTsKIAotCXNnX2luaXRfdGFibGUoaW5mby0+c2csIEJMS0lGX01BWF9TRUdN
RU5UU19QRVJfUkVRVUVTVCk7Ci0KIAllcnIgPSB4ZW5idXNfZ3JhbnRfcmluZyhkZXYsIHZpcnRf
dG9fbWZuKGluZm8tPnJpbmcuc3JpbmcpKTsKIAlpZiAoZXJyIDwgMCkgewogCQlmcmVlX3BhZ2Uo
KHVuc2lnbmVkIGxvbmcpc3JpbmcpOwpAQCAtMTExNiwxMiArMTI1Niw2IEBAIGFnYWluOgogCQln
b3RvIGRlc3Ryb3lfYmxrcmluZzsKIAl9CiAKLQkvKiBBbGxvY2F0ZSBtZW1vcnkgZm9yIGdyYW50
cyAqLwotCWVyciA9IGZpbGxfZ3JhbnRfYnVmZmVyKGluZm8sIEJMS19SSU5HX1NJWkUgKgotCSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVT
VCk7Ci0JaWYgKGVycikKLQkJZ290byBvdXQ7Ci0KIAl4ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwg
WGVuYnVzU3RhdGVJbml0aWFsaXNlZCk7CiAKIAlyZXR1cm4gMDsKQEAgLTEyMjMsMTMgKzEzNTcs
ODQgQEAgc3RhdGljIGludCBibGtmcm9udF9wcm9iZShzdHJ1Y3QgeGVuYnVzX2RldmljZSAqZGV2
LAogCXJldHVybiAwOwogfQogCisvKgorICogVGhpcyBpcyBhIGNsb25lIG9mIG1kX3RyaW1fYmlv
LCB1c2VkIHRvIHNwbGl0IGEgYmlvIGludG8gc21hbGxlciBvbmVzCisgKi8KK3N0YXRpYyB2b2lk
IHRyaW1fYmlvKHN0cnVjdCBiaW8gKmJpbywgaW50IG9mZnNldCwgaW50IHNpemUpCit7CisJLyog
J2JpbycgaXMgYSBjbG9uZWQgYmlvIHdoaWNoIHdlIG5lZWQgdG8gdHJpbSB0byBtYXRjaAorCSAq
IHRoZSBnaXZlbiBvZmZzZXQgYW5kIHNpemUuCisJICogVGhpcyByZXF1aXJlcyBhZGp1c3Rpbmcg
Ymlfc2VjdG9yLCBiaV9zaXplLCBhbmQgYmlfaW9fdmVjCisJICovCisJaW50IGk7CisJc3RydWN0
IGJpb192ZWMgKmJ2ZWM7CisJaW50IHNvZmFyID0gMDsKKworCXNpemUgPDw9IDk7CisJaWYgKG9m
ZnNldCA9PSAwICYmIHNpemUgPT0gYmlvLT5iaV9zaXplKQorCQlyZXR1cm47CisKKwliaW8tPmJp
X3NlY3RvciArPSBvZmZzZXQ7CisJYmlvLT5iaV9zaXplID0gc2l6ZTsKKwlvZmZzZXQgPDw9IDk7
CisJY2xlYXJfYml0KEJJT19TRUdfVkFMSUQsICZiaW8tPmJpX2ZsYWdzKTsKKworCXdoaWxlIChi
aW8tPmJpX2lkeCA8IGJpby0+YmlfdmNudCAmJgorCSAgICAgICBiaW8tPmJpX2lvX3ZlY1tiaW8t
PmJpX2lkeF0uYnZfbGVuIDw9IG9mZnNldCkgeworCQkvKiByZW1vdmUgdGhpcyB3aG9sZSBiaW9f
dmVjICovCisJCW9mZnNldCAtPSBiaW8tPmJpX2lvX3ZlY1tiaW8tPmJpX2lkeF0uYnZfbGVuOwor
CQliaW8tPmJpX2lkeCsrOworCX0KKwlpZiAoYmlvLT5iaV9pZHggPCBiaW8tPmJpX3ZjbnQpIHsK
KwkJYmlvLT5iaV9pb192ZWNbYmlvLT5iaV9pZHhdLmJ2X29mZnNldCArPSBvZmZzZXQ7CisJCWJp
by0+YmlfaW9fdmVjW2Jpby0+YmlfaWR4XS5idl9sZW4gLT0gb2Zmc2V0OworCX0KKwkvKiBhdm9p
ZCBhbnkgY29tcGxpY2F0aW9ucyB3aXRoIGJpX2lkeCBiZWluZyBub24temVybyovCisJaWYgKGJp
by0+YmlfaWR4KSB7CisJCW1lbW1vdmUoYmlvLT5iaV9pb192ZWMsIGJpby0+YmlfaW9fdmVjK2Jp
by0+YmlfaWR4LAorCQkJKGJpby0+YmlfdmNudCAtIGJpby0+YmlfaWR4KSAqIHNpemVvZihzdHJ1
Y3QgYmlvX3ZlYykpOworCQliaW8tPmJpX3ZjbnQgLT0gYmlvLT5iaV9pZHg7CisJCWJpby0+Ymlf
aWR4ID0gMDsKKwl9CisJLyogTWFrZSBzdXJlIHZjbnQgYW5kIGxhc3QgYnYgYXJlIG5vdCB0b28g
YmlnICovCisJYmlvX2Zvcl9lYWNoX3NlZ21lbnQoYnZlYywgYmlvLCBpKSB7CisJCWlmIChzb2Zh
ciArIGJ2ZWMtPmJ2X2xlbiA+IHNpemUpCisJCQlidmVjLT5idl9sZW4gPSBzaXplIC0gc29mYXI7
CisJCWlmIChidmVjLT5idl9sZW4gPT0gMCkgeworCQkJYmlvLT5iaV92Y250ID0gaTsKKwkJCWJy
ZWFrOworCQl9CisJCXNvZmFyICs9IGJ2ZWMtPmJ2X2xlbjsKKwl9Cit9CisKK3N0YXRpYyB2b2lk
IHNwbGl0X2Jpb19lbmQoc3RydWN0IGJpbyAqYmlvLCBpbnQgZXJyb3IpCit7CisJc3RydWN0IHNw
bGl0X2JpbyAqc3BsaXRfYmlvID0gYmlvLT5iaV9wcml2YXRlOworCisJaWYgKGVycm9yKQorCQlz
cGxpdF9iaW8tPmVyciA9IGVycm9yOworCisJaWYgKGF0b21pY19kZWNfYW5kX3Rlc3QoJnNwbGl0
X2Jpby0+cGVuZGluZykpIHsKKwkJc3BsaXRfYmlvLT5iaW8tPmJpX3BoeXNfc2VnbWVudHMgPSAw
OworCQliaW9fZW5kaW8oc3BsaXRfYmlvLT5iaW8sIHNwbGl0X2Jpby0+ZXJyKTsKKwkJa2ZyZWUo
c3BsaXRfYmlvKTsKKwl9CisJYmlvX3B1dChiaW8pOworfQogCiBzdGF0aWMgaW50IGJsa2lmX3Jl
Y292ZXIoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiB7CiAJaW50IGk7Ci0Jc3RydWN0IGJs
a2lmX3JlcXVlc3QgKnJlcTsKKwlzdHJ1Y3QgcmVxdWVzdCAqcmVxLCAqbjsKIAlzdHJ1Y3QgYmxr
X3NoYWRvdyAqY29weTsKLQlpbnQgajsKKwlpbnQgcmM7CisJc3RydWN0IGJpbyAqYmlvLCAqY2xv
bmVkX2JpbzsKKwlzdHJ1Y3QgYmlvX2xpc3QgYmlvX2xpc3QsIG1lcmdlX2JpbzsKKwl1bnNpZ25l
ZCBpbnQgc2VnczsKKwlpbnQgcGVuZGluZywgb2Zmc2V0LCBzaXplOworCXN0cnVjdCBzcGxpdF9i
aW8gKnNwbGl0X2JpbzsKKwlzdHJ1Y3QgbGlzdF9oZWFkIHJlcXVlc3RzOwogCiAJLyogU3RhZ2Ug
MTogTWFrZSBhIHNhZmUgY29weSBvZiB0aGUgc2hhZG93IHN0YXRlLiAqLwogCWNvcHkgPSBrbWFs
bG9jKHNpemVvZihpbmZvLT5zaGFkb3cpLApAQCAtMTI0NSwzNiArMTQ1MCw2NCBAQCBzdGF0aWMg
aW50IGJsa2lmX3JlY292ZXIoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiAJaW5mby0+c2hh
ZG93X2ZyZWUgPSBpbmZvLT5yaW5nLnJlcV9wcm9kX3B2dDsKIAlpbmZvLT5zaGFkb3dbQkxLX1JJ
TkdfU0laRS0xXS5yZXEudS5ydy5pZCA9IDB4MGZmZmZmZmY7CiAKLQkvKiBTdGFnZSAzOiBGaW5k
IHBlbmRpbmcgcmVxdWVzdHMgYW5kIHJlcXVldWUgdGhlbS4gKi8KKwlyYyA9IGJsa2Zyb250X3Nl
dHVwX2luZGlyZWN0KGluZm8pOworCWlmIChyYykgeworCQlrZnJlZShjb3B5KTsKKwkJcmV0dXJu
IHJjOworCX0KKworCXNlZ3MgPSBpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMgPyA6IEJMS0lG
X01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVDsKKwlibGtfcXVldWVfbWF4X3NlZ21lbnRzKGluZm8t
PnJxLCBzZWdzKTsKKwliaW9fbGlzdF9pbml0KCZiaW9fbGlzdCk7CisJSU5JVF9MSVNUX0hFQUQo
JnJlcXVlc3RzKTsKIAlmb3IgKGkgPSAwOyBpIDwgQkxLX1JJTkdfU0laRTsgaSsrKSB7CiAJCS8q
IE5vdCBpbiB1c2U/ICovCiAJCWlmICghY29weVtpXS5yZXF1ZXN0KQogCQkJY29udGludWU7CiAK
LQkJLyogR3JhYiBhIHJlcXVlc3Qgc2xvdCBhbmQgY29weSBzaGFkb3cgc3RhdGUgaW50byBpdC4g
Ki8KLQkJcmVxID0gUklOR19HRVRfUkVRVUVTVCgmaW5mby0+cmluZywgaW5mby0+cmluZy5yZXFf
cHJvZF9wdnQpOwotCQkqcmVxID0gY29weVtpXS5yZXE7Ci0KLQkJLyogV2UgZ2V0IGEgbmV3IHJl
cXVlc3QgaWQsIGFuZCBtdXN0IHJlc2V0IHRoZSBzaGFkb3cgc3RhdGUuICovCi0JCXJlcS0+dS5y
dy5pZCA9IGdldF9pZF9mcm9tX2ZyZWVsaXN0KGluZm8pOwotCQltZW1jcHkoJmluZm8tPnNoYWRv
d1tyZXEtPnUucncuaWRdLCAmY29weVtpXSwgc2l6ZW9mKGNvcHlbaV0pKTsKLQotCQlpZiAocmVx
LT5vcGVyYXRpb24gIT0gQkxLSUZfT1BfRElTQ0FSRCkgewotCQkvKiBSZXdyaXRlIGFueSBncmFu
dCByZWZlcmVuY2VzIGludmFsaWRhdGVkIGJ5IHN1c3AvcmVzdW1lLiAqLwotCQkJZm9yIChqID0g
MDsgaiA8IHJlcS0+dS5ydy5ucl9zZWdtZW50czsgaisrKQotCQkJCWdudHRhYl9ncmFudF9mb3Jl
aWduX2FjY2Vzc19yZWYoCi0JCQkJCXJlcS0+dS5ydy5zZWdbal0uZ3JlZiwKLQkJCQkJaW5mby0+
eGJkZXYtPm90aGVyZW5kX2lkLAotCQkJCQlwZm5fdG9fbWZuKGNvcHlbaV0uZ3JhbnRzX3VzZWRb
al0tPnBmbiksCi0JCQkJCTApOworCQkvKgorCQkgKiBHZXQgdGhlIGJpb3MgaW4gdGhlIHJlcXVl
c3Qgc28gd2UgY2FuIHJlLXF1ZXVlIHRoZW0uCisJCSAqLworCQlpZiAoY29weVtpXS5yZXF1ZXN0
LT5jbWRfZmxhZ3MgJgorCQkgICAgKFJFUV9GTFVTSCB8IFJFUV9GVUEgfCBSRVFfRElTQ0FSRCB8
IFJFUV9TRUNVUkUpKSB7CisJCQkvKgorCQkJICogRmx1c2ggb3BlcmF0aW9ucyBkb24ndCBjb250
YWluIGJpb3MsIHNvCisJCQkgKiB3ZSBuZWVkIHRvIHJlcXVldWUgdGhlIHdob2xlIHJlcXVlc3QK
KwkJCSAqLworCQkJbGlzdF9hZGQoJmNvcHlbaV0ucmVxdWVzdC0+cXVldWVsaXN0LCAmcmVxdWVz
dHMpOworCQkJY29udGludWU7CiAJCX0KLQkJaW5mby0+c2hhZG93W3JlcS0+dS5ydy5pZF0ucmVx
ID0gKnJlcTsKLQotCQlpbmZvLT5yaW5nLnJlcV9wcm9kX3B2dCsrOworCQltZXJnZV9iaW8uaGVh
ZCA9IGNvcHlbaV0ucmVxdWVzdC0+YmlvOworCQltZXJnZV9iaW8udGFpbCA9IGNvcHlbaV0ucmVx
dWVzdC0+YmlvdGFpbDsKKwkJYmlvX2xpc3RfbWVyZ2UoJmJpb19saXN0LCAmbWVyZ2VfYmlvKTsK
KwkJY29weVtpXS5yZXF1ZXN0LT5iaW8gPSBOVUxMOworCQlibGtfcHV0X3JlcXVlc3QoY29weVtp
XS5yZXF1ZXN0KTsKIAl9CiAKIAlrZnJlZShjb3B5KTsKIAorCS8qCisJICogRW1wdHkgdGhlIHF1
ZXVlLCB0aGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIHdlIG1pZ2h0IGhhdmUKKwkgKiByZXF1ZXN0
cyBpbiB0aGUgcXVldWUgd2l0aCBtb3JlIHNlZ21lbnRzIHRoYW4gd2hhdCB3ZQorCSAqIGNhbiBo
YW5kbGUgbm93LgorCSAqLworCXNwaW5fbG9ja19pcnEoJmluZm8tPmlvX2xvY2spOworCXdoaWxl
ICgocmVxID0gYmxrX2ZldGNoX3JlcXVlc3QoaW5mby0+cnEpKSAhPSBOVUxMKSB7CisJCWlmIChy
ZXEtPmNtZF9mbGFncyAmCisJCSAgICAoUkVRX0ZMVVNIIHwgUkVRX0ZVQSB8IFJFUV9ESVNDQVJE
IHwgUkVRX1NFQ1VSRSkpIHsKKwkJCWxpc3RfYWRkKCZyZXEtPnF1ZXVlbGlzdCwgJnJlcXVlc3Rz
KTsKKwkJCWNvbnRpbnVlOworCQl9CisJCW1lcmdlX2Jpby5oZWFkID0gcmVxLT5iaW87CisJCW1l
cmdlX2Jpby50YWlsID0gcmVxLT5iaW90YWlsOworCQliaW9fbGlzdF9tZXJnZSgmYmlvX2xpc3Qs
ICZtZXJnZV9iaW8pOworCQlyZXEtPmJpbyA9IE5VTEw7CisJCWlmIChyZXEtPmNtZF9mbGFncyAm
IChSRVFfRkxVU0ggfCBSRVFfRlVBKSkKKwkJCXByX2FsZXJ0KCJkaXNrY2FjaGUgZmx1c2ggcmVx
dWVzdCBmb3VuZCFcbiIpOworCQlfX2Jsa19wdXRfcmVxdWVzdChpbmZvLT5ycSwgcmVxKTsKKwl9
CisJc3Bpbl91bmxvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKKwogCXhlbmJ1c19zd2l0Y2hfc3Rh
dGUoaW5mby0+eGJkZXYsIFhlbmJ1c1N0YXRlQ29ubmVjdGVkKTsKIAogCXNwaW5fbG9ja19pcnEo
JmluZm8tPmlvX2xvY2spOwpAQCAtMTI4MiwxNCArMTUxNSw1MCBAQCBzdGF0aWMgaW50IGJsa2lm
X3JlY292ZXIoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiAJLyogTm93IHNhZmUgZm9yIHVz
IHRvIHVzZSB0aGUgc2hhcmVkIHJpbmcgKi8KIAlpbmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFU
RV9DT05ORUNURUQ7CiAKLQkvKiBTZW5kIG9mZiByZXF1ZXVlZCByZXF1ZXN0cyAqLwotCWZsdXNo
X3JlcXVlc3RzKGluZm8pOwotCiAJLyogS2ljayBhbnkgb3RoZXIgbmV3IHJlcXVlc3RzIHF1ZXVl
ZCBzaW5jZSB3ZSByZXN1bWVkICovCiAJa2lja19wZW5kaW5nX3JlcXVlc3RfcXVldWVzKGluZm8p
OwogCisJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHJlcSwgbiwgJnJlcXVlc3RzLCBxdWV1ZWxp
c3QpIHsKKwkJLyogUmVxdWV1ZSBwZW5kaW5nIHJlcXVlc3RzIChmbHVzaCBvciBkaXNjYXJkKSAq
LworCQlsaXN0X2RlbF9pbml0KCZyZXEtPnF1ZXVlbGlzdCk7CisJCUJVR19PTihyZXEtPm5yX3Bo
eXNfc2VnbWVudHMgPiBzZWdzKTsKKwkJYmxrX3JlcXVldWVfcmVxdWVzdChpbmZvLT5ycSwgcmVx
KTsKKwl9CiAJc3Bpbl91bmxvY2tfaXJxKCZpbmZvLT5pb19sb2NrKTsKIAorCXdoaWxlICgoYmlv
ID0gYmlvX2xpc3RfcG9wKCZiaW9fbGlzdCkpICE9IE5VTEwpIHsKKwkJLyogVHJhdmVyc2UgdGhl
IGxpc3Qgb2YgcGVuZGluZyBiaW9zIGFuZCByZS1xdWV1ZSB0aGVtICovCisJCWlmIChiaW9fc2Vn
bWVudHMoYmlvKSA+IHNlZ3MpIHsKKwkJCS8qCisJCQkgKiBUaGlzIGJpbyBoYXMgbW9yZSBzZWdt
ZW50cyB0aGFuIHdoYXQgd2UgY2FuCisJCQkgKiBoYW5kbGUsIHdlIGhhdmUgdG8gc3BsaXQgaXQu
CisJCQkgKi8KKwkJCXBlbmRpbmcgPSAoYmlvX3NlZ21lbnRzKGJpbykgKyBzZWdzIC0gMSkgLyBz
ZWdzOworCQkJc3BsaXRfYmlvID0ga3phbGxvYyhzaXplb2YoKnNwbGl0X2JpbyksIEdGUF9OT0lP
KTsKKwkJCUJVR19PTihzcGxpdF9iaW8gPT0gTlVMTCk7CisJCQlhdG9taWNfc2V0KCZzcGxpdF9i
aW8tPnBlbmRpbmcsIHBlbmRpbmcpOworCQkJc3BsaXRfYmlvLT5iaW8gPSBiaW87CisJCQlmb3Ig
KGkgPSAwOyBpIDwgcGVuZGluZzsgaSsrKSB7CisJCQkJb2Zmc2V0ID0gKGkgKiBzZWdzICogUEFH
RV9TSVpFKSA+PiA5OworCQkJCXNpemUgPSBNSU4oKHNlZ3MgKiBQQUdFX1NJWkUpID4+IDksCisJ
CQkJICAgICAgICAgICAoYmlvLT5iaV9zaXplID4+IDkpIC0gb2Zmc2V0KTsKKwkJCQljbG9uZWRf
YmlvID0gYmlvX2Nsb25lKGJpbywgR0ZQX05PSU8pOworCQkJCUJVR19PTihjbG9uZWRfYmlvID09
IE5VTEwpOworCQkJCXRyaW1fYmlvKGNsb25lZF9iaW8sIG9mZnNldCwgc2l6ZSk7CisJCQkJY2xv
bmVkX2Jpby0+YmlfcHJpdmF0ZSA9IHNwbGl0X2JpbzsKKwkJCQljbG9uZWRfYmlvLT5iaV9lbmRf
aW8gPSBzcGxpdF9iaW9fZW5kOworCQkJCXN1Ym1pdF9iaW8oY2xvbmVkX2Jpby0+YmlfcncsIGNs
b25lZF9iaW8pOworCQkJfQorCQkJLyoKKwkJCSAqIE5vdyB3ZSBoYXZlIHRvIHdhaXQgZm9yIGFs
bCB0aG9zZSBzbWFsbGVyIGJpb3MgdG8KKwkJCSAqIGVuZCwgc28gd2UgY2FuIGFsc28gZW5kIHRo
ZSAicGFyZW50IiBiaW8uCisJCQkgKi8KKwkJCWNvbnRpbnVlOworCQl9CisJCS8qIFdlIGRvbid0
IG5lZWQgdG8gc3BsaXQgdGhpcyBiaW8gKi8KKwkJc3VibWl0X2JpbyhiaW8tPmJpX3J3LCBiaW8p
OworCX0KKwogCXJldHVybiAwOwogfQogCkBAIC0xMzA5LDggKzE1NzgsMTIgQEAgc3RhdGljIGlu
dCBibGtmcm9udF9yZXN1bWUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldikKIAlibGtpZl9mcmVl
KGluZm8sIGluZm8tPmNvbm5lY3RlZCA9PSBCTEtJRl9TVEFURV9DT05ORUNURUQpOwogCiAJZXJy
ID0gdGFsa190b19ibGtiYWNrKGRldiwgaW5mbyk7Ci0JaWYgKGluZm8tPmNvbm5lY3RlZCA9PSBC
TEtJRl9TVEFURV9TVVNQRU5ERUQgJiYgIWVycikKLQkJZXJyID0gYmxraWZfcmVjb3ZlcihpbmZv
KTsKKworCS8qCisJICogV2UgaGF2ZSB0byB3YWl0IGZvciB0aGUgYmFja2VuZCB0byBzd2l0Y2gg
dG8KKwkgKiBjb25uZWN0ZWQgc3RhdGUsIHNpbmNlIHdlIHdhbnQgdG8gcmVhZCB3aGljaAorCSAq
IGZlYXR1cmVzIGl0IHN1cHBvcnRzLgorCSAqLwogCiAJcmV0dXJuIGVycjsKIH0KQEAgLTEzODgs
NiArMTY2MSw2MiBAQCBzdGF0aWMgdm9pZCBibGtmcm9udF9zZXR1cF9kaXNjYXJkKHN0cnVjdCBi
bGtmcm9udF9pbmZvICppbmZvKQogCWtmcmVlKHR5cGUpOwogfQogCitzdGF0aWMgaW50IGJsa2Zy
b250X3NldHVwX2luZGlyZWN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKQoreworCXVuc2ln
bmVkIGludCBpbmRpcmVjdF9zZWdtZW50cywgc2VnczsKKwlpbnQgZXJyLCBpOworCisJZXJyID0g
eGVuYnVzX2dhdGhlcihYQlRfTklMLCBpbmZvLT54YmRldi0+b3RoZXJlbmQsCisJCQkgICAgIm1h
eC1pbmRpcmVjdC1zZWdtZW50cyIsICIldSIsICZpbmRpcmVjdF9zZWdtZW50cywKKwkJCSAgICBO
VUxMKTsKKwlpZiAoZXJyKSB7CisJCWluZm8tPm1heF9pbmRpcmVjdF9zZWdtZW50cyA9IDA7CisJ
CXNlZ3MgPSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1Q7CisJfSBlbHNlIHsKKwkJaW5m
by0+bWF4X2luZGlyZWN0X3NlZ21lbnRzID0gTUlOKGluZGlyZWN0X3NlZ21lbnRzLAorCQkgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeGVuX2Jsa2lmX21heF9zZWdtZW50cyk7CisJ
CXNlZ3MgPSBpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHM7CisJfQorCWluZm8tPnNnID0ga3ph
bGxvYyhzaXplb2YoaW5mby0+c2dbMF0pICogc2VncywgR0ZQX0tFUk5FTCk7CisJaWYgKGluZm8t
PnNnID09IE5VTEwpCisJCWdvdG8gb3V0X29mX21lbW9yeTsKKwlzZ19pbml0X3RhYmxlKGluZm8t
PnNnLCBzZWdzKTsKKworCWVyciA9IGZpbGxfZ3JhbnRfYnVmZmVyKGluZm8sCisJICAgICAgICAg
ICAgICAgICAgICAgICAgKHNlZ3MgKyBJTkRJUkVDVF9HUkVGUyhzZWdzKSkgKiBCTEtfUklOR19T
SVpFKTsKKwlpZiAoZXJyKQorCQlnb3RvIG91dF9vZl9tZW1vcnk7CisKKwlmb3IgKGkgPSAwOyBp
IDwgQkxLX1JJTkdfU0laRTsgaSsrKSB7CisJCWluZm8tPnNoYWRvd1tpXS5ncmFudHNfdXNlZCA9
IGt6YWxsb2MoCisJCQlzaXplb2YoaW5mby0+c2hhZG93W2ldLmdyYW50c191c2VkWzBdKSAqIHNl
Z3MsCisJCQlHRlBfTk9JTyk7CisJCWlmIChpbmZvLT5tYXhfaW5kaXJlY3Rfc2VnbWVudHMpCisJ
CQlpbmZvLT5zaGFkb3dbaV0uaW5kaXJlY3RfZ3JhbnRzID0ga3phbGxvYygKKwkJCQlzaXplb2Yo
aW5mby0+c2hhZG93W2ldLmluZGlyZWN0X2dyYW50c1swXSkgKgorCQkJCUlORElSRUNUX0dSRUZT
KHNlZ3MpLAorCQkJCUdGUF9OT0lPKTsKKwkJaWYgKChpbmZvLT5zaGFkb3dbaV0uZ3JhbnRzX3Vz
ZWQgPT0gTlVMTCkgfHwKKwkJICAgICAoaW5mby0+bWF4X2luZGlyZWN0X3NlZ21lbnRzICYmCisJ
CSAgICAgKGluZm8tPnNoYWRvd1tpXS5pbmRpcmVjdF9ncmFudHMgPT0gTlVMTCkpKQorCQkJZ290
byBvdXRfb2ZfbWVtb3J5OworCX0KKworCisJcmV0dXJuIDA7CisKK291dF9vZl9tZW1vcnk6CisJ
a2ZyZWUoaW5mby0+c2cpOworCWluZm8tPnNnID0gTlVMTDsKKwlmb3IgKGkgPSAwOyBpIDwgQkxL
X1JJTkdfU0laRTsgaSsrKSB7CisJCWtmcmVlKGluZm8tPnNoYWRvd1tpXS5ncmFudHNfdXNlZCk7
CisJCWluZm8tPnNoYWRvd1tpXS5ncmFudHNfdXNlZCA9IE5VTEw7CisJCWtmcmVlKGluZm8tPnNo
YWRvd1tpXS5pbmRpcmVjdF9ncmFudHMpOworCQlpbmZvLT5zaGFkb3dbaV0uaW5kaXJlY3RfZ3Jh
bnRzID0gTlVMTDsKKwl9CisJcmV0dXJuIC1FTk9NRU07Cit9CisKIC8qCiAgKiBJbnZva2VkIHdo
ZW4gdGhlIGJhY2tlbmQgaXMgZmluYWxseSAncmVhZHknIChhbmQgaGFzIHRvbGQgcHJvZHVjZWQK
ICAqIHRoZSBkZXRhaWxzIGFib3V0IHRoZSBwaHlzaWNhbCBkZXZpY2UgLSAjc2VjdG9ycywgc2l6
ZSwgZXRjKS4KQEAgLTE0MTUsOCArMTc0NCw5IEBAIHN0YXRpYyB2b2lkIGJsa2Zyb250X2Nvbm5l
Y3Qoc3RydWN0IGJsa2Zyb250X2luZm8gKmluZm8pCiAJCXNldF9jYXBhY2l0eShpbmZvLT5nZCwg
c2VjdG9ycyk7CiAJCXJldmFsaWRhdGVfZGlzayhpbmZvLT5nZCk7CiAKLQkJLyogZmFsbCB0aHJv
dWdoICovCisJCXJldHVybjsKIAljYXNlIEJMS0lGX1NUQVRFX1NVU1BFTkRFRDoKKwkJYmxraWZf
cmVjb3ZlcihpbmZvKTsKIAkJcmV0dXJuOwogCiAJZGVmYXVsdDoKQEAgLTE0MzcsNiArMTc2Nyw3
IEBAIHN0YXRpYyB2b2lkIGJsa2Zyb250X2Nvbm5lY3Qoc3RydWN0IGJsa2Zyb250X2luZm8gKmlu
Zm8pCiAJCQkJIGluZm8tPnhiZGV2LT5vdGhlcmVuZCk7CiAJCXJldHVybjsKIAl9CisJaW5mby0+
c2VjdG9yX3NpemUgPSBzZWN0b3Jfc2l6ZTsKIAogCWluZm8tPmZlYXR1cmVfZmx1c2ggPSAwOwog
CWluZm8tPmZsdXNoX29wID0gMDsKQEAgLTE0ODQsNiArMTgxNSwxMyBAQCBzdGF0aWMgdm9pZCBi
bGtmcm9udF9jb25uZWN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKQogCWVsc2UKIAkJaW5m
by0+ZmVhdHVyZV9wZXJzaXN0ZW50ID0gcGVyc2lzdGVudDsKIAorCWVyciA9IGJsa2Zyb250X3Nl
dHVwX2luZGlyZWN0KGluZm8pOworCWlmIChlcnIpIHsKKwkJeGVuYnVzX2Rldl9mYXRhbChpbmZv
LT54YmRldiwgZXJyLCAic2V0dXBfaW5kaXJlY3QgYXQgJXMiLAorCQkJCSBpbmZvLT54YmRldi0+
b3RoZXJlbmQpOworCQlyZXR1cm47CisJfQorCiAJZXJyID0geGx2YmRfYWxsb2NfZ2VuZGlzayhz
ZWN0b3JzLCBpbmZvLCBiaW5mbywgc2VjdG9yX3NpemUpOwogCWlmIChlcnIpIHsKIAkJeGVuYnVz
X2Rldl9mYXRhbChpbmZvLT54YmRldiwgZXJyLCAieGx2YmRfYWRkIGF0ICVzIiwKZGlmZiAtLWdp
dCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9pby9ibGtpZi5oIGIvaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL2lvL2Jsa2lmLmgKaW5kZXggMDFjM2Q2Mi4uNmQ5OTg0OSAxMDA2NDQKLS0tIGEvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL2lvL2Jsa2lmLmgKKysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL2lv
L2Jsa2lmLmgKQEAgLTEwMiw2ICsxMDIsOCBAQCB0eXBlZGVmIHVpbnQ2NF90IGJsa2lmX3NlY3Rv
cl90OwogICovCiAjZGVmaW5lIEJMS0lGX09QX0RJU0NBUkQgICAgICAgICAgIDUKIAorI2RlZmlu
ZSBCTEtJRl9PUF9JTkRJUkVDVCAgICAgICAgICA2CisKIC8qCiAgKiBNYXhpbXVtIHNjYXR0ZXIv
Z2F0aGVyIHNlZ21lbnRzIHBlciByZXF1ZXN0LgogICogVGhpcyBpcyBjYXJlZnVsbHkgY2hvc2Vu
IHNvIHRoYXQgc2l6ZW9mKHN0cnVjdCBibGtpZl9yaW5nKSA8PSBQQUdFX1NJWkUuCkBAIC0xMDks
NiArMTExLDE2IEBAIHR5cGVkZWYgdWludDY0X3QgYmxraWZfc2VjdG9yX3Q7CiAgKi8KICNkZWZp
bmUgQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUIDExCiAKKyNkZWZpbmUgQkxLSUZfTUFY
X0lORElSRUNUX0dSRUZTX1BFUl9SRVFVRVNUIDgKKworc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2Vn
bWVudF9hbGlnbmVkIHsKKwlncmFudF9yZWZfdCBncmVmOyAgICAgICAgLyogcmVmZXJlbmNlIHRv
IEkvTyBidWZmZXIgZnJhbWUgICAgICAgICovCisJLyogQGZpcnN0X3NlY3Q6IGZpcnN0IHNlY3Rv
ciBpbiBmcmFtZSB0byB0cmFuc2ZlciAoaW5jbHVzaXZlKS4gICAqLworCS8qIEBsYXN0X3NlY3Q6
IGxhc3Qgc2VjdG9yIGluIGZyYW1lIHRvIHRyYW5zZmVyIChpbmNsdXNpdmUpLiAgICAgKi8KKwl1
aW50OF90ICAgICBmaXJzdF9zZWN0LCBsYXN0X3NlY3Q7CisJdWludDE2X3QgICAgX3BhZDsgLyog
cGFkZGluZyB0byBtYWtlIGl0IDggYnl0ZXMsIHNvIGl0J3MgY2FjaGUtYWxpZ25lZCAqLworfSBf
X2F0dHJpYnV0ZV9fKChfX3BhY2tlZF9fKSk7CisKIHN0cnVjdCBibGtpZl9yZXF1ZXN0X3J3IHsK
IAl1aW50OF90ICAgICAgICBucl9zZWdtZW50czsgIC8qIG51bWJlciBvZiBzZWdtZW50cyAgICAg
ICAgICAgICAgICAgICAqLwogCWJsa2lmX3ZkZXZfdCAgIGhhbmRsZTsgICAgICAgLyogb25seSBm
b3IgcmVhZC93cml0ZSByZXF1ZXN0cyAgICAgICAgICovCkBAIC0xMzgsMTEgKzE1MCwyNCBAQCBz
dHJ1Y3QgYmxraWZfcmVxdWVzdF9kaXNjYXJkIHsKIAl1aW50OF90ICAgICAgICBfcGFkMzsKIH0g
X19hdHRyaWJ1dGVfXygoX19wYWNrZWRfXykpOwogCitzdHJ1Y3QgYmxraWZfcmVxdWVzdF9pbmRp
cmVjdCB7CisJdWludDhfdCAgICAgICAgaW5kaXJlY3Rfb3A7CisJdWludDE2X3QgICAgICAgbnJf
c2VnbWVudHM7CisjaWZkZWYgQ09ORklHX1g4Nl82NAorCXVpbnQzMl90ICAgICAgIF9wYWQxOyAg
ICAgICAgLyogb2Zmc2V0b2YoYmxraWZfLi4uLHUuaW5kaXJlY3QuaWQpID09IDggKi8KKyNlbmRp
ZgorCXVpbnQ2NF90ICAgICAgIGlkOworCWJsa2lmX3ZkZXZfdCAgIGhhbmRsZTsKKwlibGtpZl9z
ZWN0b3JfdCBzZWN0b3JfbnVtYmVyOworCWdyYW50X3JlZl90ICAgIGluZGlyZWN0X2dyZWZzW0JM
S0lGX01BWF9JTkRJUkVDVF9HUkVGU19QRVJfUkVRVUVTVF07Cit9IF9fYXR0cmlidXRlX18oKF9f
cGFja2VkX18pKTsKKwogc3RydWN0IGJsa2lmX3JlcXVlc3QgewogCXVpbnQ4X3QgICAgICAgIG9w
ZXJhdGlvbjsgICAgLyogQkxLSUZfT1BfPz8/ICAgICAgICAgICAgICAgICAgICAgICAgICovCiAJ
dW5pb24gewogCQlzdHJ1Y3QgYmxraWZfcmVxdWVzdF9ydyBydzsKIAkJc3RydWN0IGJsa2lmX3Jl
cXVlc3RfZGlzY2FyZCBkaXNjYXJkOworCQlzdHJ1Y3QgYmxraWZfcmVxdWVzdF9pbmRpcmVjdCBp
bmRpcmVjdDsKIAl9IHU7CiB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKIAotLSAKMS43
LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0kA-0005qr-9F; Thu, 28 Feb 2013 10:29:42 +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 1UB0k8-0005oU-5x
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:40 +0000
Received: from [193.109.254.147:32750] by server-16.bemta-14.messagelabs.com
	id BE/15-25906-3913F215; Thu, 28 Feb 2013 10:29:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!12
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1784 invoked from network); 28 Feb 2013 10:29:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:39 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:39 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:38 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:54 +0100
Message-ID: <1362047335-26402-12-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 11/12] xen-blkback: expand map/unmap
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

UHJlcGFyYXRvcnkgY2hhbmdlIGZvciBpbXBsZW1lbnRpbmcgaW5kaXJlY3QgZGVzY3JpcHRvcnMu
IENoYW5nZQp4ZW5fYmxrYmtfe21hcC91bm1hcH0gaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBtYXAv
dW5tYXAgYSByYW5kb20gYW1vdW50Cm9mIGdyYW50cyAocHJldmlvdXNseSBpdCB3YXMgbGltaXRl
ZCB0bwpCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QpLiBBbHNvLCByZW1vdmUgdGhlIHVz
YWdlIG9mIHBlbmRpbmdfcmVxCmluIHRoZSBtYXAvdW5tYXAgZnVuY3Rpb25zLCBzbyB3ZSBjYW4g
bWFwL3VubWFwIGdyYW50cyB3aXRob3V0IG5lZWRpbmcKdG8gcGFzcyBhIHBlbmRpbmdfcmVxLgoK
U2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNj
OiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNsZS5jb20+CkNjOiB4ZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFj
ay5jIHwgIDEzNCArKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLQogMSBmaWxlcyBj
aGFuZ2VkLCA4NSBpbnNlcnRpb25zKCspLCA0OSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9k
cml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJs
a2JhY2svYmxrYmFjay5jCmluZGV4IDA0YWQyYWEuLjBmYTMwZGIgMTAwNjQ0Ci0tLSBhL2RyaXZl
cnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJs
a2JhY2svYmxrYmFjay5jCkBAIC0xNzgsMTAgKzE3OCw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBy
ZW1vdmVfZnJlZV9wYWdlcyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwgaW50IG51bSkKIAogI2Rl
ZmluZSB2YWRkcihwYWdlKSAoKHVuc2lnbmVkIGxvbmcpcGZuX3RvX2thZGRyKHBhZ2VfdG9fcGZu
KHBhZ2UpKSkKIAotI2RlZmluZSBwZW5kaW5nX2hhbmRsZShfcmVxLCBfc2VnKSBcCi0JKF9yZXEt
PmdyYW50X2hhbmRsZXNbX3NlZ10pCi0KLQogc3RhdGljIGludCBkb19ibG9ja19pb19vcChzdHJ1
Y3QgeGVuX2Jsa2lmICpibGtpZik7CiBzdGF0aWMgaW50IGRpc3BhdGNoX3J3X2Jsb2NrX2lvKHN0
cnVjdCB4ZW5fYmxraWYgKmJsa2lmLAogCQkJCXN0cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCkBA
IC01OTAsNTMgKzU4Niw2MCBAQCBzdHJ1Y3Qgc2VnX2J1ZiB7CiAgKiBVbm1hcCB0aGUgZ3JhbnQg
cmVmZXJlbmNlcywgYW5kIGFsc28gcmVtb3ZlIHRoZSBNMlAgb3Zlci1yaWRlcwogICogdXNlZCBp
biB0aGUgJ3BlbmRpbmdfcmVxJy4KICAqLwotc3RhdGljIHZvaWQgeGVuX2Jsa2JrX3VubWFwKHN0
cnVjdCBwZW5kaW5nX3JlcSAqcmVxKQorc3RhdGljIHZvaWQgeGVuX2Jsa2JrX3VubWFwKHN0cnVj
dCB4ZW5fYmxraWYgKmJsa2lmLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdyYW50X2hh
bmRsZV90IGhhbmRsZXNbXSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcGFn
ZSAqcGFnZXNbXSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcGVyc2lzdGVu
dF9nbnQgKnBlcnNpc3RlbnRfZ250c1tdLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu
dCBudW0pCiB7CiAJc3RydWN0IGdudHRhYl91bm1hcF9ncmFudF9yZWYgdW5tYXBbQkxLSUZfTUFY
X1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKLQlzdHJ1Y3QgcGFnZSAqcGFnZXNbQkxLSUZfTUFYX1NF
R01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGFnZSAqdW5tYXBfcGFnZXNbQkxLSUZfTUFY
X1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIAlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKnBlcnNpc3Rl
bnRfZ250OwogCXVuc2lnbmVkIGludCBpLCBpbnZjb3VudCA9IDA7Ci0JZ3JhbnRfaGFuZGxlX3Qg
aGFuZGxlOwotCXN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmID0gcmVxLT5ibGtpZjsKIAlpbnQgcmV0
OwogCi0JZm9yIChpID0gMDsgaSA8IHJlcS0+bnJfcGFnZXM7IGkrKykgewotCQlpZiAocmVxLT5w
ZXJzaXN0ZW50X2dudHNbaV0gIT0gTlVMTCkgewotCQkJcGVyc2lzdGVudF9nbnQgPSByZXEtPnBl
cnNpc3RlbnRfZ250c1tpXTsKKwlmb3IgKGkgPSAwOyBpIDwgbnVtOyBpKyspIHsKKwkJaWYgKHBl
cnNpc3RlbnRfZ250c1tpXSAhPSBOVUxMKSB7CisJCQlwZXJzaXN0ZW50X2dudCA9IHBlcnNpc3Rl
bnRfZ250c1tpXTsKIAkJCXBlcnNpc3RlbnRfZ250LT5mbGFncyB8PSBQRVJTSVNURU5UX0dOVF9V
U0VEOwogCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzICY9IH5QRVJTSVNURU5UX0dOVF9BQ1RJVkU7
CiAJCQljb250aW51ZTsKIAkJfQotCQloYW5kbGUgPSBwZW5kaW5nX2hhbmRsZShyZXEsIGkpOwot
CQlwYWdlc1tpbnZjb3VudF0gPSByZXEtPnBhZ2VzW2ldOwotCQlpZiAoaGFuZGxlID09IEJMS0JB
Q0tfSU5WQUxJRF9IQU5ETEUpCisJCWlmIChoYW5kbGVzW2ldID09IEJMS0JBQ0tfSU5WQUxJRF9I
QU5ETEUpCiAJCQljb250aW51ZTsKLQkJZ250dGFiX3NldF91bm1hcF9vcCgmdW5tYXBbaW52Y291
bnRdLCB2YWRkcihwYWdlc1tpbnZjb3VudF0pLAotCQkJCSAgICBHTlRNQVBfaG9zdF9tYXAsIGhh
bmRsZSk7Ci0JCXBlbmRpbmdfaGFuZGxlKHJlcSwgaSkgPSBCTEtCQUNLX0lOVkFMSURfSEFORExF
OwotCQlpbnZjb3VudCsrOworCQl1bm1hcF9wYWdlc1tpbnZjb3VudF0gPSBwYWdlc1tpXTsKKwkJ
Z250dGFiX3NldF91bm1hcF9vcCgmdW5tYXBbaW52Y291bnRdLCB2YWRkcihwYWdlc1tpXSksCisJ
CQkJICAgIEdOVE1BUF9ob3N0X21hcCwgaGFuZGxlc1tpXSk7CisJCWhhbmRsZXNbaV0gPSBCTEtC
QUNLX0lOVkFMSURfSEFORExFOworCQlpZiAoKytpbnZjb3VudCA9PSBCTEtJRl9NQVhfU0VHTUVO
VFNfUEVSX1JFUVVFU1QpIHsKKwkJCXJldCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxM
LCB1bm1hcF9wYWdlcywKKwkJCSAgICAgICAgICAgICAgICAgICAgICAgIGludmNvdW50KTsKKwkJ
CUJVR19PTihyZXQpOworCQkJcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHVubWFwX3BhZ2VzLCBpbnZj
b3VudCk7CisJCQlpbnZjb3VudCA9IDA7CisJCX0KKwl9CisJaWYgKGludmNvdW50KSB7CisJCXJl
dCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxMLCB1bm1hcF9wYWdlcywgaW52Y291bnQp
OworCQlCVUdfT04ocmV0KTsKKwkJcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHVubWFwX3BhZ2VzLCBp
bnZjb3VudCk7CiAJfQotCi0JcmV0ID0gZ250dGFiX3VubWFwX3JlZnModW5tYXAsIE5VTEwsIHBh
Z2VzLCBpbnZjb3VudCk7Ci0JQlVHX09OKHJldCk7Ci0JcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHBh
Z2VzLCBpbnZjb3VudCk7CiB9CiAKLXN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxr
aWZfcmVxdWVzdCAqcmVxLAotCQkJIHN0cnVjdCBwZW5kaW5nX3JlcSAqcGVuZGluZ19yZXEsCi0J
CQkgc3RydWN0IHNlZ19idWYgc2VnW10sCi0JCQkgc3RydWN0IHBhZ2UgKnBhZ2VzW10pCitzdGF0
aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIGdyYW50X3JlZl90
IGdyZWZzW10sCisJCQkgc3RydWN0IHBlcnNpc3RlbnRfZ250ICpwZXJzaXN0ZW50X2dudHNbXSwK
KwkJCSBncmFudF9oYW5kbGVfdCBoYW5kbGVzW10sCisJCQkgc3RydWN0IHBhZ2UgKnBhZ2VzW10s
CisJCQkgaW50IG51bSwgYm9vbCBybykKIHsKIAlzdHJ1Y3QgZ250dGFiX21hcF9ncmFudF9yZWYg
bWFwW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAJc3RydWN0IHBhZ2UgKnBhZ2Vz
X3RvX2dudFtCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOwotCXN0cnVjdCBwZXJzaXN0
ZW50X2dudCAqKnBlcnNpc3RlbnRfZ250cyA9IHBlbmRpbmdfcmVxLT5wZXJzaXN0ZW50X2dudHM7
CiAJc3RydWN0IHBlcnNpc3RlbnRfZ250ICpwZXJzaXN0ZW50X2dudCA9IE5VTEw7Ci0Jc3RydWN0
IHhlbl9ibGtpZiAqYmxraWYgPSBwZW5kaW5nX3JlcS0+YmxraWY7CiAJcGh5c19hZGRyX3QgYWRk
ciA9IDA7CiAJaW50IGksIGo7Ci0JaW50IG5zZWcgPSByZXEtPnUucncubnJfc2VnbWVudHM7CiAJ
aW50IHNlZ3NfdG9fbWFwID0gMDsKIAlpbnQgcmV0ID0gMDsKKwlpbnQgbGFzdF9tYXAgPSAwLCBt
YXBfdW50aWwgPSAwOwogCWludCB1c2VfcGVyc2lzdGVudF9nbnRzOwogCiAJdXNlX3BlcnNpc3Rl
bnRfZ250cyA9IChibGtpZi0+dmJkLmZlYXR1cmVfZ250X3BlcnNpc3RlbnQpOwpAQCAtNjQ2LDEz
ICs2NDksMTQgQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0
ICpyZXEsCiAJICogYXNzaWduIG1hcFsuLl0gd2l0aCB0aGUgUEZOIG9mIHRoZSBwYWdlIGluIG91
ciBkb21haW4gd2l0aCB0aGUKIAkgKiBjb3JyZXNwb25kaW5nIGdyYW50IHJlZmVyZW5jZSBmb3Ig
ZWFjaCBwYWdlLgogCSAqLwotCWZvciAoaSA9IDA7IGkgPCBuc2VnOyBpKyspIHsKK2FnYWluOgor
CWZvciAoaSA9IG1hcF91bnRpbDsgaSA8IG51bTsgaSsrKSB7CiAJCXVpbnQzMl90IGZsYWdzOwog
CiAJCWlmICh1c2VfcGVyc2lzdGVudF9nbnRzKQogCQkJcGVyc2lzdGVudF9nbnQgPSBnZXRfcGVy
c2lzdGVudF9nbnQoCiAJCQkJJmJsa2lmLT5wZXJzaXN0ZW50X2dudHMsCi0JCQkJcmVxLT51LnJ3
LnNlZ1tpXS5ncmVmKTsKKwkJCQlncmVmc1tpXSk7CiAKIAkJaWYgKHBlcnNpc3RlbnRfZ250KSB7
CiAJCQkvKgpAQCAtNjY5LDEzICs2NzMsMTUgQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0
cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCiAJCQlwYWdlc190b19nbnRbc2Vnc190b19tYXBdID0g
cGFnZXNbaV07CiAJCQlwZXJzaXN0ZW50X2dudHNbaV0gPSBOVUxMOwogCQkJZmxhZ3MgPSBHTlRN
QVBfaG9zdF9tYXA7Ci0JCQlpZiAoIXVzZV9wZXJzaXN0ZW50X2dudHMgJiYKLQkJCSAgICAocGVu
ZGluZ19yZXEtPm9wZXJhdGlvbiAhPSBCTEtJRl9PUF9SRUFEKSkKKwkJCWlmICghdXNlX3BlcnNp
c3RlbnRfZ250cyAmJiBybykKIAkJCQlmbGFncyB8PSBHTlRNQVBfcmVhZG9ubHk7CiAJCQlnbnR0
YWJfc2V0X21hcF9vcCgmbWFwW3NlZ3NfdG9fbWFwKytdLCBhZGRyLAotCQkJCQkgIGZsYWdzLCBy
ZXEtPnUucncuc2VnW2ldLmdyZWYsCisJCQkJCSAgZmxhZ3MsIGdyZWZzW2ldLAogCQkJCQkgIGJs
a2lmLT5kb21pZCk7CiAJCX0KKwkJbWFwX3VudGlsID0gaSArIDE7CisJCWlmIChzZWdzX3RvX21h
cCA9PSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QpCisJCQlicmVhazsKIAl9CiAKIAlp
ZiAoc2Vnc190b19tYXApIHsKQEAgLTY4OCwyMiArNjk0LDIwIEBAIHN0YXRpYyBpbnQgeGVuX2Js
a2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCSAqIHNvIHRoYXQgd2hlbiB3ZSBh
Y2Nlc3MgdmFkZHIocGVuZGluZ19yZXEsaSkgaXQgaGFzIHRoZSBjb250ZW50cyBvZgogCSAqIHRo
ZSBwYWdlIGZyb20gdGhlIG90aGVyIGRvbWFpbi4KIAkgKi8KLQlmb3IgKGkgPSAwLCBqID0gMDsg
aSA8IG5zZWc7IGkrKykgeworCWZvciAoaSA9IGxhc3RfbWFwLCBqID0gMDsgaSA8IG1hcF91bnRp
bDsgaSsrKSB7CiAJCWlmICghcGVyc2lzdGVudF9nbnRzW2ldKSB7CiAJCQkvKiBUaGlzIGlzIGEg
bmV3bHkgbWFwcGVkIGdyYW50ICovCiAJCQlCVUdfT04oaiA+PSBzZWdzX3RvX21hcCk7CiAJCQlp
ZiAodW5saWtlbHkobWFwW2pdLnN0YXR1cyAhPSAwKSkgewogCQkJCXByX2RlYnVnKERSVl9QRlgg
ImludmFsaWQgYnVmZmVyIC0tIGNvdWxkIG5vdCByZW1hcCBpdFxuIik7Ci0JCQkJcGVuZGluZ19o
YW5kbGUocGVuZGluZ19yZXEsIGkpID0KLQkJCQkJQkxLQkFDS19JTlZBTElEX0hBTkRMRTsKKwkJ
CQloYW5kbGVzW2ldID0gQkxLQkFDS19JTlZBTElEX0hBTkRMRTsKIAkJCQlyZXQgfD0gMTsKLQkJ
CQlqKys7Ci0JCQkJY29udGludWU7CisJCQkJZ290byBuZXh0OwogCQkJfQotCQkJcGVuZGluZ19o
YW5kbGUocGVuZGluZ19yZXEsIGkpID0gbWFwW2pdLmhhbmRsZTsKKwkJCWhhbmRsZXNbaV0gPSBt
YXBbal0uaGFuZGxlOwogCQl9CiAJCWlmIChwZXJzaXN0ZW50X2dudHNbaV0pCi0JCQlnb3RvIG5l
eHQ7CisJCQljb250aW51ZTsKIAkJaWYgKHVzZV9wZXJzaXN0ZW50X2dudHMgJiYKIAkJICAgIGJs
a2lmLT5wZXJzaXN0ZW50X2dudF9jIDwgeGVuX2Jsa2lmX21heF9wZ3JhbnRzKSB7CiAJCQkvKgpA
QCAtNzE4LDcgKzcyMiw2IEBAIHN0YXRpYyBpbnQgeGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZf
cmVxdWVzdCAqcmVxLAogCQkJCSAqIGFsbG9jYXRlIHRoZSBwZXJzaXN0ZW50X2dudCBzdHJ1Y3QK
IAkJCQkgKiBtYXAgdGhpcyBncmFudCBub24tcGVyc2lzdGVubHkKIAkJCQkgKi8KLQkJCQlqKys7
CiAJCQkJZ290byBuZXh0OwogCQkJfQogCQkJcGVyc2lzdGVudF9nbnQtPmdudCA9IG1hcFtqXS5y
ZWY7CkBAIC03MzUsNyArNzM4LDYgQEAgc3RhdGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBi
bGtpZl9yZXF1ZXN0ICpyZXEsCiAJCQlwcl9kZWJ1ZyhEUlZfUEZYICIgZ3JhbnQgJXUgYWRkZWQg
dG8gdGhlIHRyZWUgb2YgcGVyc2lzdGVudCBncmFudHMsIHVzaW5nICV1LyV1XG4iLAogCQkJCSBw
ZXJzaXN0ZW50X2dudC0+Z250LCBibGtpZi0+cGVyc2lzdGVudF9nbnRfYywKIAkJCQkgeGVuX2Js
a2lmX21heF9wZ3JhbnRzKTsKLQkJCWorKzsKIAkJCWdvdG8gbmV4dDsKIAkJfQogCQlpZiAodXNl
X3BlcnNpc3RlbnRfZ250cyAmJiAhYmxraWYtPnZiZC5vdmVyZmxvd19tYXhfZ3JhbnRzKSB7CkBA
IC03NDMsMTEgKzc0NSwxNCBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lm
X3JlcXVlc3QgKnJlcSwKIAkJCXByX2RlYnVnKERSVl9QRlggIiBkb21haW4gJXUsIGRldmljZSAl
I3ggaXMgdXNpbmcgbWF4aW11bSBudW1iZXIgb2YgcGVyc2lzdGVudCBncmFudHNcbiIsCiAJCQkg
ICAgICAgICBibGtpZi0+ZG9taWQsIGJsa2lmLT52YmQuaGFuZGxlKTsKIAkJfQotCQlqKys7CiBu
ZXh0OgotCQlzZWdbaV0uYnVmID0gcGZuX3RvX21mbihwYWdlX3RvX3BmbihwYWdlc1tpXSkpIDw8
IFBBR0VfU0hJRlQgfAotCQkgICAgICAgICAgICAgKHJlcS0+dS5ydy5zZWdbaV0uZmlyc3Rfc2Vj
dCA8PCA5KTsKKwkJaisrOwogCX0KKwlzZWdzX3RvX21hcCA9IDA7CisJbGFzdF9tYXAgPSBtYXBf
dW50aWw7CisJaWYgKG1hcF91bnRpbCAhPSBudW0pCisJCWdvdG8gYWdhaW47CisKIAlyZXR1cm4g
cmV0OwogCiBvdXRfb2ZfbWVtb3J5OgpAQCAtNzU2LDYgKzc2MSwzMiBAQCBvdXRfb2ZfbWVtb3J5
OgogCXJldHVybiAtRU5PTUVNOwogfQogCitzdGF0aWMgaW50IHhlbl9ibGtia19tYXBfc2VnKHN0
cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCisJCQkgICAgIHN0cnVjdCBwZW5kaW5nX3JlcSAqcGVu
ZGluZ19yZXEsCisJCQkgICAgIHN0cnVjdCBzZWdfYnVmIHNlZ1tdLAorCQkJICAgICBzdHJ1Y3Qg
cGFnZSAqcGFnZXNbXSkKK3sKKwlpbnQgaSwgcmM7CisJZ3JhbnRfcmVmX3QgZ3JlZnNbQkxLSUZf
TUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKworCWZvciAoaSA9IDA7IGkgPCByZXEtPnUucncu
bnJfc2VnbWVudHM7IGkrKykKKwkJZ3JlZnNbaV0gPSByZXEtPnUucncuc2VnW2ldLmdyZWY7CisK
KwlyYyA9IHhlbl9ibGtia19tYXAocGVuZGluZ19yZXEtPmJsa2lmLCBncmVmcywKKwkgICAgICAg
ICAgICAgICAgICAgcGVuZGluZ19yZXEtPnBlcnNpc3RlbnRfZ250cywKKwkgICAgICAgICAgICAg
ICAgICAgcGVuZGluZ19yZXEtPmdyYW50X2hhbmRsZXMsIHBlbmRpbmdfcmVxLT5wYWdlcywKKwkg
ICAgICAgICAgICAgICAgICAgcmVxLT51LnJ3Lm5yX3NlZ21lbnRzLAorCSAgICAgICAgICAgICAg
ICAgICAocGVuZGluZ19yZXEtPm9wZXJhdGlvbiAhPSBCTEtJRl9PUF9SRUFEKSk7CisJaWYgKHJj
KQorCQlyZXR1cm4gcmM7CisKKwlmb3IgKGkgPSAwOyBpIDwgcmVxLT51LnJ3Lm5yX3NlZ21lbnRz
OyBpKyspCisJCXNlZ1tpXS5idWYgPSBwZm5fdG9fbWZuKHBhZ2VfdG9fcGZuKHBlbmRpbmdfcmVx
LT5wYWdlc1tpXSkpCisJCSAgICAgICAgICAgICA8PCBQQUdFX1NISUZUIHwgKHJlcS0+dS5ydy5z
ZWdbaV0uZmlyc3Rfc2VjdCA8PCA5KTsKKworCXJldHVybiAwOworfQorCiBzdGF0aWMgaW50IGRp
c3BhdGNoX2Rpc2NhcmRfaW8oc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsCiAJCQkJc3RydWN0IGJs
a2lmX3JlcXVlc3QgKnJlcSkKIHsKQEAgLTgzMiw3ICs4NjMsMTAgQEAgc3RhdGljIHZvaWQgX19l
bmRfYmxvY2tfaW9fb3Aoc3RydWN0IHBlbmRpbmdfcmVxICpwZW5kaW5nX3JlcSwgaW50IGVycm9y
KQogCSAqIHRoZSBwcm9wZXIgcmVzcG9uc2Ugb24gdGhlIHJpbmcuCiAJICovCiAJaWYgKGF0b21p
Y19kZWNfYW5kX3Rlc3QoJnBlbmRpbmdfcmVxLT5wZW5kY250KSkgewotCQl4ZW5fYmxrYmtfdW5t
YXAocGVuZGluZ19yZXEpOworCQl4ZW5fYmxrYmtfdW5tYXAocGVuZGluZ19yZXEtPmJsa2lmLCBw
ZW5kaW5nX3JlcS0+Z3JhbnRfaGFuZGxlcywKKwkJICAgICAgICAgICAgICAgIHBlbmRpbmdfcmVx
LT5wYWdlcywKKwkJICAgICAgICAgICAgICAgIHBlbmRpbmdfcmVxLT5wZXJzaXN0ZW50X2dudHMs
CisJCSAgICAgICAgICAgICAgICBwZW5kaW5nX3JlcS0+bnJfcGFnZXMpOwogCQltYWtlX3Jlc3Bv
bnNlKHBlbmRpbmdfcmVxLT5ibGtpZiwgcGVuZGluZ19yZXEtPmlkLAogCQkJICAgICAgcGVuZGlu
Z19yZXEtPm9wZXJhdGlvbiwgcGVuZGluZ19yZXEtPnN0YXR1cyk7CiAJCXhlbl9ibGtpZl9wdXQo
cGVuZGluZ19yZXEtPmJsa2lmKTsKQEAgLTEwNDAsNyArMTA3NCw3IEBAIHN0YXRpYyBpbnQgZGlz
cGF0Y2hfcndfYmxvY2tfaW8oc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsCiAJICogdGhlIGh5cGVy
Y2FsbCB0byB1bm1hcCB0aGUgZ3JhbnRzIC0gdGhhdCBpcyBhbGwgZG9uZSBpbgogCSAqIHhlbl9i
bGtia191bm1hcC4KIAkgKi8KLQlpZiAoeGVuX2Jsa2JrX21hcChyZXEsIHBlbmRpbmdfcmVxLCBz
ZWcsIHBhZ2VzKSkKKwlpZiAoeGVuX2Jsa2JrX21hcF9zZWcocmVxLCBwZW5kaW5nX3JlcSwgc2Vn
LCBwYWdlcykpCiAJCWdvdG8gZmFpbF9mbHVzaDsKIAogCS8qCkBAIC0xMTA3LDcgKzExNDEsOSBA
QCBzdGF0aWMgaW50IGRpc3BhdGNoX3J3X2Jsb2NrX2lvKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
LAogCXJldHVybiAwOwogCiAgZmFpbF9mbHVzaDoKLQl4ZW5fYmxrYmtfdW5tYXAocGVuZGluZ19y
ZXEpOworCXhlbl9ibGtia191bm1hcChibGtpZiwgcGVuZGluZ19yZXEtPmdyYW50X2hhbmRsZXMs
CisJICAgICAgICAgICAgICAgIHBlbmRpbmdfcmVxLT5wYWdlcywgcGVuZGluZ19yZXEtPnBlcnNp
c3RlbnRfZ250cywKKwkgICAgICAgICAgICAgICAgcGVuZGluZ19yZXEtPm5yX3BhZ2VzKTsKICBm
YWlsX3Jlc3BvbnNlOgogCS8qIEhhdmVuJ3Qgc3VibWl0dGVkIGFueSBiaW8ncyB5ZXQuICovCiAJ
bWFrZV9yZXNwb25zZShibGtpZiwgcmVxLT51LnJ3LmlkLCByZXEtPm9wZXJhdGlvbiwgQkxLSUZf
UlNQX0VSUk9SKTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k7-0005oJ-Go; Thu, 28 Feb 2013 10:29:39 +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 1UB0k5-0005mz-C4
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:37 +0000
Received: from [193.109.254.147:58045] by server-6.bemta-14.messagelabs.com id
	5A/02-12010-0913F215; Thu, 28 Feb 2013 10:29:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!5
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1435 invoked from network); 28 Feb 2013 10:29:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:36 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:35 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:47 +0100
Message-ID: <1362047335-26402-5-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 04/12] xen-blkfront: pre-allocate pages for
	requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VGhpcyBwcmV2ZW50cyB1cyBmcm9tIGhhdmluZyB0byBjYWxsIGFsbG9jX3BhZ2Ugd2hpbGUgd2Ug
YXJlIHByZXBhcmluZwp0aGUgcmVxdWVzdC4gU2luY2UgYmxrZnJvbnQgd2FzIGNhbGxpbmcgYWxs
b2NfcGFnZSB3aXRoIGEgc3BpbmxvY2sKaGVsZCB3ZSB1c2VkIEdGUF9BVE9NSUMsIHdoaWNoIGNh
biBmYWlsIGlmIHdlIGFyZSByZXF1ZXN0aW5nIGEgbG90IG9mCnBhZ2VzIHNpbmNlIGl0IGlzIHVz
aW5nIHRoZSBlbWVyZ2VuY3kgbWVtb3J5IHBvb2xzLgoKQWxsb2NhdGluZyBhbGwgdGhlIHBhZ2Vz
IGF0IGluaXQgcHJldmVudHMgdXMgZnJvbSBoYXZpbmcgdG8gY2FsbAphbGxvY19wYWdlLCB0aHVz
IHByZXZlbnRpbmcgcG9zc2libGUgZmFpbHVyZXMuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg
TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8
a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KQ2M6IHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCi0tLQog
ZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYyB8ICAxMjAgKysrKysrKysrKysrKysrKysrKysr
KysrKysrLS0tLS0tLS0tLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgNzkgaW5zZXJ0aW9ucygrKSwg
NDEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQu
YyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMKaW5kZXggMmUzOWVhZi4uNWJhNmI4NyAx
MDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJvbnQuYworKysgYi9kcml2ZXJzL2Js
b2NrL3hlbi1ibGtmcm9udC5jCkBAIC0xNjUsNiArMTY1LDY5IEBAIHN0YXRpYyBpbnQgYWRkX2lk
X3RvX2ZyZWVsaXN0KHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvLAogCXJldHVybiAwOwogfQog
CitzdGF0aWMgaW50IGZpbGxfZ3JhbnRfYnVmZmVyKHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZv
LCBpbnQgbnVtKQoreworCXN0cnVjdCBwYWdlICpncmFudGVkX3BhZ2U7CisJc3RydWN0IGdyYW50
ICpnbnRfbGlzdF9lbnRyeSwgKm47CisJaW50IGkgPSAwOworCisJd2hpbGUoaSA8IG51bSkgewor
CQlnbnRfbGlzdF9lbnRyeSA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBncmFudCksIEdGUF9OT0lP
KTsKKwkJaWYgKCFnbnRfbGlzdF9lbnRyeSkKKwkJCWdvdG8gb3V0X29mX21lbW9yeTsKKworCQln
cmFudGVkX3BhZ2UgPSBhbGxvY19wYWdlKEdGUF9OT0lPKTsKKwkJaWYgKCFncmFudGVkX3BhZ2Up
IHsKKwkJCWtmcmVlKGdudF9saXN0X2VudHJ5KTsKKwkJCWdvdG8gb3V0X29mX21lbW9yeTsKKwkJ
fQorCisJCWdudF9saXN0X2VudHJ5LT5wZm4gPSBwYWdlX3RvX3BmbihncmFudGVkX3BhZ2UpOwor
CQlnbnRfbGlzdF9lbnRyeS0+Z3JlZiA9IEdSQU5UX0lOVkFMSURfUkVGOworCQlsaXN0X2FkZCgm
Z250X2xpc3RfZW50cnktPm5vZGUsICZpbmZvLT5wZXJzaXN0ZW50X2dudHMpOworCQlpKys7CisJ
fQorCisJcmV0dXJuIDA7CisKK291dF9vZl9tZW1vcnk6CisJbGlzdF9mb3JfZWFjaF9lbnRyeV9z
YWZlKGdudF9saXN0X2VudHJ5LCBuLAorCSAgICAgICAgICAgICAgICAgICAgICAgICAmaW5mby0+
cGVyc2lzdGVudF9nbnRzLCBub2RlKSB7CisJCWxpc3RfZGVsKCZnbnRfbGlzdF9lbnRyeS0+bm9k
ZSk7CisJCV9fZnJlZV9wYWdlKHBmbl90b19wYWdlKGdudF9saXN0X2VudHJ5LT5wZm4pKTsKKwkJ
a2ZyZWUoZ250X2xpc3RfZW50cnkpOworCQlpLS07CisJfQorCUJVR19PTihpICE9IDApOworCXJl
dHVybiAtRU5PTUVNOworfQorCitzdGF0aWMgc3RydWN0IGdyYW50ICpnZXRfZ3JhbnQoZ3JhbnRf
cmVmX3QgKmdyZWZfaGVhZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qg
YmxrZnJvbnRfaW5mbyAqaW5mbykKK3sKKwlzdHJ1Y3QgZ3JhbnQgKmdudF9saXN0X2VudHJ5Owor
CXVuc2lnbmVkIGxvbmcgYnVmZmVyX21mbjsKKworCUJVR19PTihsaXN0X2VtcHR5KCZpbmZvLT5w
ZXJzaXN0ZW50X2dudHMpKTsKKwlnbnRfbGlzdF9lbnRyeSA9IGxpc3RfZmlyc3RfZW50cnkoJmlu
Zm8tPnBlcnNpc3RlbnRfZ250cywgc3RydWN0IGdyYW50LAorCSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBub2RlKTsKKwlsaXN0X2RlbCgmZ250X2xpc3RfZW50cnktPm5vZGUpOwor
CisJaWYgKGdudF9saXN0X2VudHJ5LT5ncmVmICE9IEdSQU5UX0lOVkFMSURfUkVGKSB7CisJCWlu
Zm8tPnBlcnNpc3RlbnRfZ250c19jLS07CisJCXJldHVybiBnbnRfbGlzdF9lbnRyeTsKKwl9CisK
KwkvKiBBc3NpZ24gYSBncmVmIHRvIHRoaXMgcGFnZSAqLworCWdudF9saXN0X2VudHJ5LT5ncmVm
ID0gZ250dGFiX2NsYWltX2dyYW50X3JlZmVyZW5jZShncmVmX2hlYWQpOworCUJVR19PTihnbnRf
bGlzdF9lbnRyeS0+Z3JlZiA9PSAtRU5PU1BDKTsKKwlidWZmZXJfbWZuID0gcGZuX3RvX21mbihn
bnRfbGlzdF9lbnRyeS0+cGZuKTsKKwlnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3NfcmVmKGdu
dF9saXN0X2VudHJ5LT5ncmVmLAorCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5m
by0+eGJkZXYtPm90aGVyZW5kX2lkLAorCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YnVmZmVyX21mbiwgMCk7CisJcmV0dXJuIGdudF9saXN0X2VudHJ5OworfQorCiBzdGF0aWMgY29u
c3QgY2hhciAqb3BfbmFtZShpbnQgb3ApCiB7CiAJc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0IG5h
bWVzW10gPSB7CkBAIC0zMDYsNyArMzY5LDYgQEAgc3RhdGljIGludCBibGtpZl9xdWV1ZV9yZXF1
ZXN0KHN0cnVjdCByZXF1ZXN0ICpyZXEpCiAJICovCiAJYm9vbCBuZXdfcGVyc2lzdGVudF9nbnRz
OwogCWdyYW50X3JlZl90IGdyZWZfaGVhZDsKLQlzdHJ1Y3QgcGFnZSAqZ3JhbnRlZF9wYWdlOwog
CXN0cnVjdCBncmFudCAqZ250X2xpc3RfZW50cnkgPSBOVUxMOwogCXN0cnVjdCBzY2F0dGVybGlz
dCAqc2c7CiAKQEAgLTM3MCw0MiArNDMyLDkgQEAgc3RhdGljIGludCBibGtpZl9xdWV1ZV9yZXF1
ZXN0KHN0cnVjdCByZXF1ZXN0ICpyZXEpCiAJCQlmc2VjdCA9IHNnLT5vZmZzZXQgPj4gOTsKIAkJ
CWxzZWN0ID0gZnNlY3QgKyAoc2ctPmxlbmd0aCA+PiA5KSAtIDE7CiAKLQkJCWlmIChpbmZvLT5w
ZXJzaXN0ZW50X2dudHNfYykgewotCQkJCUJVR19PTihsaXN0X2VtcHR5KCZpbmZvLT5wZXJzaXN0
ZW50X2dudHMpKTsKLQkJCQlnbnRfbGlzdF9lbnRyeSA9IGxpc3RfZmlyc3RfZW50cnkoCi0JCQkJ
ICAgICAgICAgICAgICAgICAgICAgICZpbmZvLT5wZXJzaXN0ZW50X2dudHMsCi0JCQkJICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBncmFudCwgbm9kZSk7Ci0JCQkJbGlzdF9kZWwoJmdudF9s
aXN0X2VudHJ5LT5ub2RlKTsKLQotCQkJCXJlZiA9IGdudF9saXN0X2VudHJ5LT5ncmVmOwotCQkJ
CWJ1ZmZlcl9tZm4gPSBwZm5fdG9fbWZuKGdudF9saXN0X2VudHJ5LT5wZm4pOwotCQkJCWluZm8t
PnBlcnNpc3RlbnRfZ250c19jLS07Ci0JCQl9IGVsc2UgewotCQkJCXJlZiA9IGdudHRhYl9jbGFp
bV9ncmFudF9yZWZlcmVuY2UoJmdyZWZfaGVhZCk7Ci0JCQkJQlVHX09OKHJlZiA9PSAtRU5PU1BD
KTsKLQotCQkJCWdudF9saXN0X2VudHJ5ID0KLQkJCQkJa21hbGxvYyhzaXplb2Yoc3RydWN0IGdy
YW50KSwKLQkJCQkJCQkgR0ZQX0FUT01JQyk7Ci0JCQkJaWYgKCFnbnRfbGlzdF9lbnRyeSkKLQkJ
CQkJcmV0dXJuIC1FTk9NRU07Ci0KLQkJCQlncmFudGVkX3BhZ2UgPSBhbGxvY19wYWdlKEdGUF9B
VE9NSUMpOwotCQkJCWlmICghZ3JhbnRlZF9wYWdlKSB7Ci0JCQkJCWtmcmVlKGdudF9saXN0X2Vu
dHJ5KTsKLQkJCQkJcmV0dXJuIC1FTk9NRU07Ci0JCQkJfQotCi0JCQkJZ250X2xpc3RfZW50cnkt
PnBmbiA9Ci0JCQkJCXBhZ2VfdG9fcGZuKGdyYW50ZWRfcGFnZSk7Ci0JCQkJZ250X2xpc3RfZW50
cnktPmdyZWYgPSByZWY7Ci0KLQkJCQlidWZmZXJfbWZuID0gcGZuX3RvX21mbihwYWdlX3RvX3Bm
bigKLQkJCQkJCQkJZ3JhbnRlZF9wYWdlKSk7Ci0JCQkJZ250dGFiX2dyYW50X2ZvcmVpZ25fYWNj
ZXNzX3JlZihyZWYsCi0JCQkJCWluZm8tPnhiZGV2LT5vdGhlcmVuZF9pZCwKLQkJCQkJYnVmZmVy
X21mbiwgMCk7Ci0JCQl9CisJCQlnbnRfbGlzdF9lbnRyeSA9IGdldF9ncmFudCgmZ3JlZl9oZWFk
LCBpbmZvKTsKKwkJCXJlZiA9IGdudF9saXN0X2VudHJ5LT5ncmVmOworCQkJYnVmZmVyX21mbiA9
IHBmbl90b19tZm4oZ250X2xpc3RfZW50cnktPnBmbik7CiAKIAkJCWluZm8tPnNoYWRvd1tpZF0u
Z3JhbnRzX3VzZWRbaV0gPSBnbnRfbGlzdF9lbnRyeTsKIApAQCAtODAzLDE3ICs4MzIsMjAgQEAg
c3RhdGljIHZvaWQgYmxraWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1
c3BlbmQpCiAJCWJsa19zdG9wX3F1ZXVlKGluZm8tPnJxKTsKIAogCS8qIFJlbW92ZSBhbGwgcGVy
c2lzdGVudCBncmFudHMgKi8KLQlpZiAoaW5mby0+cGVyc2lzdGVudF9nbnRzX2MpIHsKKwlpZiAo
IWxpc3RfZW1wdHkoJmluZm8tPnBlcnNpc3RlbnRfZ250cykpIHsKIAkJbGlzdF9mb3JfZWFjaF9l
bnRyeV9zYWZlKHBlcnNpc3RlbnRfZ250LCBuLAogCQkgICAgICAgICAgICAgICAgICAgICAgICAg
JmluZm8tPnBlcnNpc3RlbnRfZ250cywgbm9kZSkgewogCQkJbGlzdF9kZWwoJnBlcnNpc3RlbnRf
Z250LT5ub2RlKTsKLQkJCWdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3MocGVyc2lzdGVudF9nbnQt
PmdyZWYsIDAsIDBVTCk7CisJCQlpZiAocGVyc2lzdGVudF9nbnQtPmdyZWYgIT0gR1JBTlRfSU5W
QUxJRF9SRUYpIHsKKwkJCQlnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzKHBlcnNpc3RlbnRfZ250
LT5ncmVmLAorCQkJCSAgICAgICAgICAgICAgICAgICAgICAgICAgMCwgMFVMKTsKKwkJCQlpbmZv
LT5wZXJzaXN0ZW50X2dudHNfYy0tOworCQkJfQogCQkJX19mcmVlX3BhZ2UocGZuX3RvX3BhZ2Uo
cGVyc2lzdGVudF9nbnQtPnBmbikpOwogCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOwotCQkJaW5m
by0+cGVyc2lzdGVudF9nbnRzX2MtLTsKIAkJfQotCQlCVUdfT04oaW5mby0+cGVyc2lzdGVudF9n
bnRzX2MgIT0gMCk7CiAJfQorCUJVR19PTihpbmZvLT5wZXJzaXN0ZW50X2dudHNfYyAhPSAwKTsK
IAogCS8qIE5vIG1vcmUgZ250dGFiIGNhbGxiYWNrIHdvcmsuICovCiAJZ250dGFiX2NhbmNlbF9m
cmVlX2NhbGxiYWNrKCZpbmZvLT5jYWxsYmFjayk7CkBAIC0xMDg4LDYgKzExMjAsMTIgQEAgYWdh
aW46CiAJCWdvdG8gZGVzdHJveV9ibGtyaW5nOwogCX0KIAorCS8qIEFsbG9jYXRlIG1lbW9yeSBm
b3IgZ3JhbnRzICovCisJZXJyID0gZmlsbF9ncmFudF9idWZmZXIoaW5mbywgQkxLX1JJTkdfU0la
RSAqCisJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkxLSUZfTUFYX1NFR01FTlRTX1BF
Ul9SRVFVRVNUKTsKKwlpZiAoZXJyKQorCQlnb3RvIG91dDsKKwogCXhlbmJ1c19zd2l0Y2hfc3Rh
dGUoZGV2LCBYZW5idXNTdGF0ZUluaXRpYWxpc2VkKTsKIAogCXJldHVybiAwOwotLSAKMS43Ljcu
NSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k8-0005pB-Dg; Thu, 28 Feb 2013 10:29:40 +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 1UB0k6-0005nO-DU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:38 +0000
Received: from [193.109.254.147:32586] by server-9.bemta-14.messagelabs.com id
	EF/CE-30867-1913F215; Thu, 28 Feb 2013 10:29:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!8
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1572 invoked from network); 28 Feb 2013 10:29:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:38 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:37 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:50 +0100
Message-ID: <1362047335-26402-8-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 07/12] xen-blkback: print stats about
	persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

U2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CkNj
OiB4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpDYzogS29ucmFkIFJ6ZXN6dXRlayBXaWxrIDxrb25y
YWQud2lsa0BvcmFjbGUuY29tPgotLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFj
ay5jIHwgICAgNSArKystLQogMSBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDIgZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNr
LmMgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwppbmRleCBjMTRiNzM2Li5i
NWU3NDk1IDEwMDY0NAotLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwor
KysgYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwpAQCAtNDYwLDEwICs0NjAs
MTEgQEAgaXJxcmV0dXJuX3QgeGVuX2Jsa2lmX2JlX2ludChpbnQgaXJxLCB2b2lkICpkZXZfaWQp
CiBzdGF0aWMgdm9pZCBwcmludF9zdGF0cyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZikKIHsKIAlw
cl9pbmZvKCJ4ZW4tYmxrYmFjayAoJXMpOiBvbyAlM2QgIHwgIHJkICU0ZCAgfCAgd3IgJTRkICB8
ICBmICU0ZCIKLQkJICIgIHwgIGRzICU0ZFxuIiwKKwkJICIgIHwgIGRzICU0ZCB8IHBnOiAlNGQv
JTRkXG4iLAogCQkgY3VycmVudC0+Y29tbSwgYmxraWYtPnN0X29vX3JlcSwKIAkJIGJsa2lmLT5z
dF9yZF9yZXEsIGJsa2lmLT5zdF93cl9yZXEsCi0JCSBibGtpZi0+c3RfZl9yZXEsIGJsa2lmLT5z
dF9kc19yZXEpOworCQkgYmxraWYtPnN0X2ZfcmVxLCBibGtpZi0+c3RfZHNfcmVxLAorCQkgYmxr
aWYtPnBlcnNpc3RlbnRfZ250X2MsIHhlbl9ibGtpZl9tYXhfcGdyYW50cyk7CiAJYmxraWYtPnN0
X3ByaW50ID0gamlmZmllcyArIG1zZWNzX3RvX2ppZmZpZXMoMTAgKiAxMDAwKTsKIAlibGtpZi0+
c3RfcmRfcmVxID0gMDsKIAlibGtpZi0+c3Rfd3JfcmVxID0gMDsKLS0gCjEuNy43LjUgKEFwcGxl
IEdpdC0yNikKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k8-0005pW-R8; Thu, 28 Feb 2013 10:29:40 +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 1UB0k6-0005nk-Vn
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:39 +0000
Received: from [193.109.254.147:36608] by server-10.bemta-14.messagelabs.com
	id B3/47-12679-2913F215; Thu, 28 Feb 2013 10:29:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!9
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1627 invoked from network); 28 Feb 2013 10:29:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:38 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:37 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:51 +0100
Message-ID: <1362047335-26402-9-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 08/12] xen-blkback: use balloon pages for
	all mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VXNpbmcgYmFsbG9vbiBwYWdlcyBmb3IgYWxsIGdyYW50ZWQgcGFnZXMgYWxsb3dzIHVzIHRvIHNp
bXBsaWZ5IHRoZQpsb2dpYyBpbiBibGtiYWNrLCBzcGVjaWFsbHkgaW4gdGhlIHhlbl9ibGtia19t
YXAgZnVuY3Rpb24sIHNpbmNlIG5vdwp3ZSBjYW4gZGVjaWRlIGlmIHdlIHdhbnQgdG8gbWFwIGEg
Z3JhbnQgcGVyc2lzdGVudGx5IG9yIG5vdCBhZnRlciB3ZQpoYXZlIGFjdHVhbGx5IG1hcHBlZCBp
dC4gVGhpcyBjb3VsZCBub3QgYmUgZG9uZSBiZWZvcmUgYmVjYXVzZQpwZXJzaXN0ZW50IGdyYW50
cyB1c2VkIGJhbGxvb25lZCBwYWdlcywgYW5kIG5vbi1wZXJzaXN0ZW50IGdyYW50cyB1c2VkCnBh
Z2VzIGZyb20gdGhlIGtlcm5lbC4KClRoaXMgcGF0Y2ggYWxzbyBpbnRyb2R1Y2VzIHNldmVyYWwg
Y2hhbmdlcywgdGhlIGZpcnN0IG9uZSBpcyB0aGF0IHRoZQpsaXN0IG9mIGZyZWUgcGFnZXMgaXMg
bm8gbG9uZ2VyIGdsb2JhbCwgbm93IGVhY2ggYmxrYmFjayBpbnN0YW5jZSBoYXMKaXQncyBvd24g
bGlzdCBvZiBmcmVlIHBhZ2VzIHRoYXQgY2FuIGJlIHVzZWQgdG8gbWFwIGdyYW50cy4gQWxzbywg
YQpydW4gdGltZSBwYXJhbWV0ZXIgKG1heF9idWZmZXJfcGFnZXMpIGhhcyBiZWVuIGFkZGVkIGlu
IG9yZGVyIHRvIHR1bmUKdGhlIG1heGltdW0gbnVtYmVyIG9mIGZyZWUgcGFnZXMgZWFjaCBibGti
YWNrIGluc3RhbmNlIHdpbGwga2VlcCBpbgppdCdzIGJ1ZmZlci4KClNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpDYzogeGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNv
bT4KLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYyB8ICAyNzggKysrKysr
KysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
Y29tbW9uLmggIHwgICAgNSArCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jICB8
ICAgIDMgKwogMyBmaWxlcyBjaGFuZ2VkLCAxNTkgaW5zZXJ0aW9ucygrKSwgMTI3IGRlbGV0aW9u
cygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIGIv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKaW5kZXggYjVlNzQ5NS4uYmEyN2Zj
MyAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKKysrIGIv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKQEAgLTEwMSw2ICsxMDEsMjEgQEAg
bW9kdWxlX3BhcmFtX25hbWVkKGxydV9udW1fY2xlYW4sIHhlbl9ibGtpZl9scnVfbnVtX2NsZWFu
LCBpbnQsIDA2NDQpOwogTU9EVUxFX1BBUk1fREVTQyhscnVfbnVtX2NsZWFuLAogIk51bWJlciBv
ZiBwZXJzaXN0ZW50IGdyYW50cyB0byB1bm1hcCB3aGVuIHRoZSBsaXN0IGlzIGZ1bGwiKTsKIAor
LyoKKyAqIE1heGltdW0gbnVtYmVyIG9mIHVudXNlZCBmcmVlIHBhZ2VzIHRvIGtlZXAgaW4gdGhl
IGludGVybmFsIGJ1ZmZlci4KKyAqIFNldHRpbmcgdGhpcyB0byBhIHZhbHVlIHRvbyBsb3cgd2ls
bCByZWR1Y2UgbWVtb3J5IHVzZWQgaW4gZWFjaCBiYWNrZW5kLAorICogYnV0IGNhbiBoYXZlIGEg
cGVyZm9ybWFuY2UgcGVuYWx0eS4KKyAqCisgKiBBIHNhbmUgdmFsdWUgaXMgeGVuX2Jsa2lmX3Jl
cXMgKiBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QsIGJ1dCBjYW4KKyAqIGJlIHNldCB0
byBhIGxvd2VyIHZhbHVlIHRoYXQgbWlnaHQgZGVncmFkZSBwZXJmb3JtYW5jZSBvbiBzb21lIGlu
dGVuc2l2ZQorICogSU8gd29ya2xvYWRzLgorICovCisKK3N0YXRpYyBpbnQgeGVuX2Jsa2lmX21h
eF9idWZmZXJfcGFnZXMgPSAxMDI0OworbW9kdWxlX3BhcmFtX25hbWVkKG1heF9idWZmZXJfcGFn
ZXMsIHhlbl9ibGtpZl9tYXhfYnVmZmVyX3BhZ2VzLCBpbnQsIDA2NDQpOworTU9EVUxFX1BBUk1f
REVTQyhtYXhfYnVmZmVyX3BhZ2VzLAorIk1heGltdW0gbnVtYmVyIG9mIGZyZWUgcGFnZXMgdG8g
a2VlcCBpbiBlYWNoIGJsb2NrIGJhY2tlbmQgYnVmZmVyIik7CisKIC8qIFJ1bi10aW1lIHN3aXRj
aGFibGU6IC9zeXMvbW9kdWxlL2Jsa2JhY2svcGFyYW1ldGVycy8gKi8KIHN0YXRpYyB1bnNpZ25l
ZCBpbnQgbG9nX3N0YXRzOwogbW9kdWxlX3BhcmFtKGxvZ19zdGF0cywgaW50LCAwNjQ0KTsKQEAg
LTEyMCw2ICsxMzUsNyBAQCBzdHJ1Y3QgcGVuZGluZ19yZXEgewogCWludAkJCXN0YXR1czsKIAlz
dHJ1Y3QgbGlzdF9oZWFkCWZyZWVfbGlzdDsKIAlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQJKnBlcnNp
c3RlbnRfZ250c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOworCXN0cnVjdCBwYWdl
CQkqcGFnZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIH07CiAKICNkZWZpbmUg
QkxLQkFDS19JTlZBTElEX0hBTkRMRSAofjApCkBAIC0xMzEsOCArMTQ3LDYgQEAgc3RydWN0IHhl
bl9ibGtiayB7CiAJLyogQW5kIGl0cyBzcGlubG9jay4gKi8KIAlzcGlubG9ja190CQlwZW5kaW5n
X2ZyZWVfbG9jazsKIAl3YWl0X3F1ZXVlX2hlYWRfdAlwZW5kaW5nX2ZyZWVfd3E7Ci0JLyogVGhl
IGxpc3Qgb2YgYWxsIHBhZ2VzIHRoYXQgYXJlIGF2YWlsYWJsZS4gKi8KLQlzdHJ1Y3QgcGFnZQkJ
KipwZW5kaW5nX3BhZ2VzOwogCS8qIEFuZCB0aGUgZ3JhbnQgaGFuZGxlcyB0aGF0IGFyZSBhdmFp
bGFibGUuICovCiAJZ3JhbnRfaGFuZGxlX3QJCSpwZW5kaW5nX2dyYW50X2hhbmRsZXM7CiB9OwpA
QCAtMTUxLDE0ICsxNjUsNjYgQEAgc3RhdGljIGlubGluZSBpbnQgdmFkZHJfcGFnZW5yKHN0cnVj
dCBwZW5kaW5nX3JlcSAqcmVxLCBpbnQgc2VnKQogCQlCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JF
UVVFU1QgKyBzZWc7CiB9CiAKLSNkZWZpbmUgcGVuZGluZ19wYWdlKHJlcSwgc2VnKSBwZW5kaW5n
X3BhZ2VzW3ZhZGRyX3BhZ2VucihyZXEsIHNlZyldCitzdGF0aWMgaW5saW5lIGludCBnZXRfZnJl
ZV9wYWdlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmLCBzdHJ1Y3QgcGFnZSAqKnBhZ2UpCit7CisJ
dW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19pcnFzYXZlKCZibGtpZi0+ZnJlZV9w
YWdlc19sb2NrLCBmbGFncyk7CisJaWYgKGxpc3RfZW1wdHkoJmJsa2lmLT5mcmVlX3BhZ2VzKSkg
eworCQlCVUdfT04oYmxraWYtPmZyZWVfcGFnZXNfbnVtICE9IDApOworCQlzcGluX3VubG9ja19p
cnFyZXN0b3JlKCZibGtpZi0+ZnJlZV9wYWdlc19sb2NrLCBmbGFncyk7CisJCXJldHVybiBhbGxv
Y194ZW5iYWxsb29uZWRfcGFnZXMoMSwgcGFnZSwgZmFsc2UpOworCX0KKwlCVUdfT04oYmxraWYt
PmZyZWVfcGFnZXNfbnVtID09IDApOworCXBhZ2VbMF0gPSBsaXN0X2ZpcnN0X2VudHJ5KCZibGtp
Zi0+ZnJlZV9wYWdlcywgc3RydWN0IHBhZ2UsIGxydSk7CisJbGlzdF9kZWwoJnBhZ2VbMF0tPmxy
dSk7CisJYmxraWYtPmZyZWVfcGFnZXNfbnVtLS07CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgm
YmxraWYtPmZyZWVfcGFnZXNfbG9jaywgZmxhZ3MpOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRp
YyBpbmxpbmUgdm9pZCBwdXRfZnJlZV9wYWdlcyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwgc3Ry
dWN0IHBhZ2UgKipwYWdlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBu
dW0pCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwlpbnQgaTsKKworCXNwaW5fbG9ja19pcnFz
YXZlKCZibGtpZi0+ZnJlZV9wYWdlc19sb2NrLCBmbGFncyk7CisJZm9yIChpID0gMDsgaSA8IG51
bTsgaSsrKQorCQlsaXN0X2FkZCgmcGFnZVtpXS0+bHJ1LCAmYmxraWYtPmZyZWVfcGFnZXMpOwor
CWJsa2lmLT5mcmVlX3BhZ2VzX251bSArPSBudW07CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgm
YmxraWYtPmZyZWVfcGFnZXNfbG9jaywgZmxhZ3MpOworfQogCi1zdGF0aWMgaW5saW5lIHVuc2ln
bmVkIGxvbmcgdmFkZHIoc3RydWN0IHBlbmRpbmdfcmVxICpyZXEsIGludCBzZWcpCitzdGF0aWMg
aW5saW5lIHZvaWQgcmVtb3ZlX2ZyZWVfcGFnZXMoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIGlu
dCBudW0pCiB7Ci0JdW5zaWduZWQgbG9uZyBwZm4gPSBwYWdlX3RvX3BmbihibGtiay0+cGVuZGlu
Z19wYWdlKHJlcSwgc2VnKSk7Ci0JcmV0dXJuICh1bnNpZ25lZCBsb25nKXBmbl90b19rYWRkcihw
Zm4pOworCS8qIFJlbW92ZSByZXF1ZXN0ZWQgcGFnZXMgaW4gYmF0Y2hlcyBvZiAxMCAqLworCXN0
cnVjdCBwYWdlICpwYWdlWzEwXTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCBudW1fcGFn
ZXMgPSAwOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmJsa2lmLT5mcmVlX3BhZ2VzX2xvY2ssIGZs
YWdzKTsKKwl3aGlsZSAoYmxraWYtPmZyZWVfcGFnZXNfbnVtID4gbnVtKSB7CisJCUJVR19PTihs
aXN0X2VtcHR5KCZibGtpZi0+ZnJlZV9wYWdlcykpOworCQlwYWdlW251bV9wYWdlc10gPSBsaXN0
X2ZpcnN0X2VudHJ5KCZibGtpZi0+ZnJlZV9wYWdlcywKKwkJICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBzdHJ1Y3QgcGFnZSwgbHJ1KTsKKwkJbGlzdF9kZWwoJnBhZ2VbbnVtX3Bh
Z2VzXS0+bHJ1KTsKKwkJYmxraWYtPmZyZWVfcGFnZXNfbnVtLS07CisJCWlmICgrK251bV9wYWdl
cyA9PSAxMCkgeworCQkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYmxraWYtPmZyZWVfcGFnZXNf
bG9jaywgZmxhZ3MpOworCQkJZnJlZV94ZW5iYWxsb29uZWRfcGFnZXMobnVtX3BhZ2VzLCBwYWdl
KTsKKwkJCXNwaW5fbG9ja19pcnFzYXZlKCZibGtpZi0+ZnJlZV9wYWdlc19sb2NrLCBmbGFncyk7
CisJCQludW1fcGFnZXMgPSAwOworCQl9CisJfQorCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmJs
a2lmLT5mcmVlX3BhZ2VzX2xvY2ssIGZsYWdzKTsKKwlpZiAobnVtX3BhZ2VzICE9IDApCisJCWZy
ZWVfeGVuYmFsbG9vbmVkX3BhZ2VzKG51bV9wYWdlcywgcGFnZSk7CiB9CiAKKyNkZWZpbmUgdmFk
ZHIocGFnZSkgKCh1bnNpZ25lZCBsb25nKXBmbl90b19rYWRkcihwYWdlX3RvX3BmbihwYWdlKSkp
CisKICNkZWZpbmUgcGVuZGluZ19oYW5kbGUoX3JlcSwgX3NlZykgXAogCShibGtiay0+cGVuZGlu
Z19ncmFudF9oYW5kbGVzW3ZhZGRyX3BhZ2VucihfcmVxLCBfc2VnKV0pCiAKQEAgLTE3OCw3ICsy
NDQsNyBAQCBzdGF0aWMgdm9pZCBtYWtlX3Jlc3BvbnNlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
LCB1NjQgaWQsCiAJICAgICAobikgPSAoJihwb3MpLT5ub2RlICE9IE5VTEwpID8gcmJfbmV4dCgm
KHBvcyktPm5vZGUpIDogTlVMTCkKIAogCi1zdGF0aWMgdm9pZCBhZGRfcGVyc2lzdGVudF9nbnQo
c3RydWN0IHJiX3Jvb3QgKnJvb3QsCitzdGF0aWMgaW50IGFkZF9wZXJzaXN0ZW50X2dudChzdHJ1
Y3QgcmJfcm9vdCAqcm9vdCwKIAkJCSAgICAgICBzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKnBlcnNp
c3RlbnRfZ250KQogewogCXN0cnVjdCByYl9ub2RlICoqbmV3ID0gJihyb290LT5yYl9ub2RlKSwg
KnBhcmVudCA9IE5VTEw7CkBAIC0xOTQsMTQgKzI2MCwxNSBAQCBzdGF0aWMgdm9pZCBhZGRfcGVy
c2lzdGVudF9nbnQoc3RydWN0IHJiX3Jvb3QgKnJvb3QsCiAJCWVsc2UgaWYgKHBlcnNpc3RlbnRf
Z250LT5nbnQgPiB0aGlzLT5nbnQpCiAJCQluZXcgPSAmKCgqbmV3KS0+cmJfcmlnaHQpOwogCQll
bHNlIHsKLQkJCXByX2FsZXJ0KERSVl9QRlggIiB0cnlpbmcgdG8gYWRkIGEgZ3JlZiB0aGF0J3Mg
YWxyZWFkeSBpbiB0aGUgdHJlZVxuIik7Ci0JCQlCVUcoKTsKKwkJCXByX2FsZXJ0X3JhdGVsaW1p
dGVkKERSVl9QRlggIiB0cnlpbmcgdG8gYWRkIGEgZ3JlZiB0aGF0J3MgYWxyZWFkeSBpbiB0aGUg
dHJlZVxuIik7CisJCQlyZXR1cm4gLUVJTlZBTDsKIAkJfQogCX0KIAogCS8qIEFkZCBuZXcgbm9k
ZSBhbmQgcmViYWxhbmNlIHRyZWUuICovCiAJcmJfbGlua19ub2RlKCYocGVyc2lzdGVudF9nbnQt
Pm5vZGUpLCBwYXJlbnQsIG5ldyk7CiAJcmJfaW5zZXJ0X2NvbG9yKCYocGVyc2lzdGVudF9nbnQt
Pm5vZGUpLCByb290KTsKKwlyZXR1cm4gMDsKIH0KIAogc3RhdGljIHN0cnVjdCBwZXJzaXN0ZW50
X2dudCAqZ2V0X3BlcnNpc3RlbnRfZ250KHN0cnVjdCByYl9yb290ICpyb290LApAQCAtMjIzLDcg
KzI5MCw4IEBAIHN0YXRpYyBzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKmdldF9wZXJzaXN0ZW50X2du
dChzdHJ1Y3QgcmJfcm9vdCAqcm9vdCwKIAlyZXR1cm4gTlVMTDsKIH0KIAotc3RhdGljIHZvaWQg
ZnJlZV9wZXJzaXN0ZW50X2dudHMoc3RydWN0IHJiX3Jvb3QgKnJvb3QsIHVuc2lnbmVkIGludCBu
dW0pCitzdGF0aWMgdm9pZCBmcmVlX3BlcnNpc3RlbnRfZ250cyhzdHJ1Y3QgeGVuX2Jsa2lmICpi
bGtpZiwgc3RydWN0IHJiX3Jvb3QgKnJvb3QsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB1bnNpZ25lZCBpbnQgbnVtKQogewogCXN0cnVjdCBnbnR0YWJfdW5tYXBfZ3JhbnRfcmVm
IHVubWFwW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAJc3RydWN0IHBhZ2UgKnBh
Z2VzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CkBAIC0yNDgsNyArMzE2LDcgQEAg
c3RhdGljIHZvaWQgZnJlZV9wZXJzaXN0ZW50X2dudHMoc3RydWN0IHJiX3Jvb3QgKnJvb3QsIHVu
c2lnbmVkIGludCBudW0pCiAJCQlyZXQgPSBnbnR0YWJfdW5tYXBfcmVmcyh1bm1hcCwgTlVMTCwg
cGFnZXMsCiAJCQkJc2Vnc190b191bm1hcCk7CiAJCQlCVUdfT04ocmV0KTsKLQkJCWZyZWVfeGVu
YmFsbG9vbmVkX3BhZ2VzKHNlZ3NfdG9fdW5tYXAsIHBhZ2VzKTsKKwkJCXB1dF9mcmVlX3BhZ2Vz
KGJsa2lmLCBwYWdlcywgc2Vnc190b191bm1hcCk7CiAJCQlzZWdzX3RvX3VubWFwID0gMDsKIAkJ
fQogCkBAIC0yNTksNyArMzI3LDggQEAgc3RhdGljIHZvaWQgZnJlZV9wZXJzaXN0ZW50X2dudHMo
c3RydWN0IHJiX3Jvb3QgKnJvb3QsIHVuc2lnbmVkIGludCBudW0pCiAJQlVHX09OKG51bSAhPSAw
KTsKIH0KIAotc3RhdGljIGludCBwdXJnZV9wZXJzaXN0ZW50X2dudChzdHJ1Y3QgcmJfcm9vdCAq
cm9vdCwgaW50IG51bSkKK3N0YXRpYyBpbnQgcHVyZ2VfcGVyc2lzdGVudF9nbnQoc3RydWN0IHhl
bl9ibGtpZiAqYmxraWYsIHN0cnVjdCByYl9yb290ICpyb290LAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBpbnQgbnVtKQogewogCXN0cnVjdCBnbnR0YWJfdW5tYXBfZ3JhbnRfcmVm
IHVubWFwW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAJc3RydWN0IHBhZ2UgKnBh
Z2VzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CkBAIC0yOTQsNyArMzYzLDcgQEAg
cHVyZ2VfbGlzdDoKIAkJCXJldCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxMLCBwYWdl
cywKIAkJCQlzZWdzX3RvX3VubWFwKTsKIAkJCUJVR19PTihyZXQpOwotCQkJZnJlZV94ZW5iYWxs
b29uZWRfcGFnZXMoc2Vnc190b191bm1hcCwgcGFnZXMpOworCQkJcHV0X2ZyZWVfcGFnZXMoYmxr
aWYsIHBhZ2VzLCBzZWdzX3RvX3VubWFwKTsKIAkJCXNlZ3NfdG9fdW5tYXAgPSAwOwogCQl9CiAK
QEAgLTMxNyw3ICszODYsNyBAQCBmaW5pc2hlZDoKIAlpZiAoc2Vnc190b191bm1hcCA+IDApIHsK
IAkJcmV0ID0gZ250dGFiX3VubWFwX3JlZnModW5tYXAsIE5VTEwsIHBhZ2VzLCBzZWdzX3RvX3Vu
bWFwKTsKIAkJQlVHX09OKHJldCk7Ci0JCWZyZWVfeGVuYmFsbG9vbmVkX3BhZ2VzKHNlZ3NfdG9f
dW5tYXAsIHBhZ2VzKTsKKwkJcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHBhZ2VzLCBzZWdzX3RvX3Vu
bWFwKTsKIAl9CiAJLyogRmluYWxseSByZW1vdmUgdGhlICJ1c2VkIiBmbGFnIGZyb20gYWxsIHRo
ZSBwZXJzaXN0ZW50IGdyYW50cyAqLwogCWZvcmVhY2hfZ3JhbnRfc2FmZShwZXJzaXN0ZW50X2du
dCwgbiwgcm9vdCwgbm9kZSkgewpAQCAtNTIxLDcgKzU5MCw3IEBAIHB1cmdlX2dudF9saXN0Ogog
CQkJCSAgICAgICAgICAgeGVuX2Jsa2lmX2xydV9udW1fY2xlYW47CiAJCQkJcnFfcHVyZ2UgPSBy
cV9wdXJnZSA+IGJsa2lmLT5wZXJzaXN0ZW50X2dudF9jID8KIAkJCQkgICAgICAgICAgIGJsa2lm
LT5wZXJzaXN0ZW50X2dudF9jIDogcnFfcHVyZ2U7Ci0JCQkJcHVyZ2VkID0gcHVyZ2VfcGVyc2lz
dGVudF9nbnQoCisJCQkJcHVyZ2VkID0gcHVyZ2VfcGVyc2lzdGVudF9nbnQoYmxraWYsCiAJCQkJ
CSAgJmJsa2lmLT5wZXJzaXN0ZW50X2dudHMsIHJxX3B1cmdlKTsKIAkJCQlpZiAocHVyZ2VkICE9
IHJxX3B1cmdlKQogCQkJCQlwcl9kZWJ1ZyhEUlZfUEZYICIgdW5hYmxlIHRvIG1lZXQgcGVyc2lz
dGVudCBncmFudHMgcHVyZ2UgcmVxdWlyZW1lbnRzIGZvciBkZXZpY2UgJSN4LCBkb21haW4gJXUs
IHJlcXVlc3RlZCAlZCBkb25lICVkXG4iLApAQCAtNTM1LDEzICs2MDQsMTcgQEAgcHVyZ2VfZ250
X2xpc3Q6CiAJCQkgICAgICAgIG1zZWNzX3RvX2ppZmZpZXMoeGVuX2Jsa2lmX2xydV9pbnRlcnZh
bCk7CiAJCX0KIAorCQlyZW1vdmVfZnJlZV9wYWdlcyhibGtpZiwgeGVuX2Jsa2lmX21heF9idWZm
ZXJfcGFnZXMpOworCiAJCWlmIChsb2dfc3RhdHMgJiYgdGltZV9hZnRlcihqaWZmaWVzLCBibGtp
Zi0+c3RfcHJpbnQpKQogCQkJcHJpbnRfc3RhdHMoYmxraWYpOwogCX0KIAorCXJlbW92ZV9mcmVl
X3BhZ2VzKGJsa2lmLCAwKTsKKwogCS8qIEZyZWUgYWxsIHBlcnNpc3RlbnQgZ3JhbnQgcGFnZXMg
Ki8KIAlpZiAoIVJCX0VNUFRZX1JPT1QoJmJsa2lmLT5wZXJzaXN0ZW50X2dudHMpKQotCQlmcmVl
X3BlcnNpc3RlbnRfZ250cygmYmxraWYtPnBlcnNpc3RlbnRfZ250cywKKwkJZnJlZV9wZXJzaXN0
ZW50X2dudHMoYmxraWYsICZibGtpZi0+cGVyc2lzdGVudF9nbnRzLAogCQkJYmxraWYtPnBlcnNp
c3RlbnRfZ250X2MpOwogCiAJQlVHX09OKCFSQl9FTVBUWV9ST09UKCZibGtpZi0+cGVyc2lzdGVu
dF9nbnRzKSk7CkBAIC01NzEsNiArNjQ0LDcgQEAgc3RhdGljIHZvaWQgeGVuX2Jsa2JrX3VubWFw
KHN0cnVjdCBwZW5kaW5nX3JlcSAqcmVxKQogCXN0cnVjdCBwZXJzaXN0ZW50X2dudCAqcGVyc2lz
dGVudF9nbnQ7CiAJdW5zaWduZWQgaW50IGksIGludmNvdW50ID0gMDsKIAlncmFudF9oYW5kbGVf
dCBoYW5kbGU7CisJc3RydWN0IHhlbl9ibGtpZiAqYmxraWYgPSByZXEtPmJsa2lmOwogCWludCBy
ZXQ7CiAKIAlmb3IgKGkgPSAwOyBpIDwgcmVxLT5ucl9wYWdlczsgaSsrKSB7CkBAIC01ODEsMTcg
KzY1NSwxOCBAQCBzdGF0aWMgdm9pZCB4ZW5fYmxrYmtfdW5tYXAoc3RydWN0IHBlbmRpbmdfcmVx
ICpyZXEpCiAJCQljb250aW51ZTsKIAkJfQogCQloYW5kbGUgPSBwZW5kaW5nX2hhbmRsZShyZXEs
IGkpOworCQlwYWdlc1tpbnZjb3VudF0gPSByZXEtPnBhZ2VzW2ldOwogCQlpZiAoaGFuZGxlID09
IEJMS0JBQ0tfSU5WQUxJRF9IQU5ETEUpCiAJCQljb250aW51ZTsKLQkJZ250dGFiX3NldF91bm1h
cF9vcCgmdW5tYXBbaW52Y291bnRdLCB2YWRkcihyZXEsIGkpLAorCQlnbnR0YWJfc2V0X3VubWFw
X29wKCZ1bm1hcFtpbnZjb3VudF0sIHZhZGRyKHBhZ2VzW2ludmNvdW50XSksCiAJCQkJICAgIEdO
VE1BUF9ob3N0X21hcCwgaGFuZGxlKTsKIAkJcGVuZGluZ19oYW5kbGUocmVxLCBpKSA9IEJMS0JB
Q0tfSU5WQUxJRF9IQU5ETEU7Ci0JCXBhZ2VzW2ludmNvdW50XSA9IHZpcnRfdG9fcGFnZSh2YWRk
cihyZXEsIGkpKTsKIAkJaW52Y291bnQrKzsKIAl9CiAKIAlyZXQgPSBnbnR0YWJfdW5tYXBfcmVm
cyh1bm1hcCwgTlVMTCwgcGFnZXMsIGludmNvdW50KTsKIAlCVUdfT04ocmV0KTsKKwlwdXRfZnJl
ZV9wYWdlcyhibGtpZiwgcGFnZXMsIGludmNvdW50KTsKIH0KIAogc3RhdGljIGludCB4ZW5fYmxr
YmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCkBAIC02MDYsNyArNjgxLDYgQEAgc3Rh
dGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCiAJc3RydWN0
IHhlbl9ibGtpZiAqYmxraWYgPSBwZW5kaW5nX3JlcS0+YmxraWY7CiAJcGh5c19hZGRyX3QgYWRk
ciA9IDA7CiAJaW50IGksIGo7Ci0JYm9vbCBuZXdfbWFwOwogCWludCBuc2VnID0gcmVxLT51LnJ3
Lm5yX3NlZ21lbnRzOwogCWludCBzZWdzX3RvX21hcCA9IDA7CiAJaW50IHJldCA9IDA7CkBAIC02
MzIsNjkgKzcwNiwxNyBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lmX3Jl
cXVlc3QgKnJlcSwKIAkJCSAqIFdlIGFyZSB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQKIAkJ
CSAqIHRoZSBncmFudCBpcyBhbHJlYWR5IG1hcHBlZAogCQkJICovCi0JCQluZXdfbWFwID0gZmFs
c2U7CiAJCQlwZXJzaXN0ZW50X2dudC0+ZmxhZ3MgfD0gUEVSU0lTVEVOVF9HTlRfQUNUSVZFOwot
CQl9IGVsc2UgaWYgKHVzZV9wZXJzaXN0ZW50X2dudHMgJiYKLQkJCSAgIGJsa2lmLT5wZXJzaXN0
ZW50X2dudF9jIDwgeGVuX2Jsa2lmX21heF9wZ3JhbnRzKSB7Ci0JCQkvKgotCQkJICogV2UgYXJl
IHVzaW5nIHBlcnNpc3RlbnQgZ3JhbnRzLCB0aGUgZ3JhbnQgaXMKLQkJCSAqIG5vdCBtYXBwZWQg
YnV0IHdlIGhhdmUgcm9vbSBmb3IgaXQKLQkJCSAqLwotCQkJbmV3X21hcCA9IHRydWU7Ci0JCQlw
ZXJzaXN0ZW50X2dudCA9IGttYWxsb2MoCi0JCQkJc2l6ZW9mKHN0cnVjdCBwZXJzaXN0ZW50X2du
dCksCi0JCQkJR0ZQX0tFUk5FTCk7Ci0JCQlpZiAoIXBlcnNpc3RlbnRfZ250KQotCQkJCXJldHVy
biAtRU5PTUVNOwotCQkJaWYgKGFsbG9jX3hlbmJhbGxvb25lZF9wYWdlcygxLCAmcGVyc2lzdGVu
dF9nbnQtPnBhZ2UsCi0JCQkgICAgZmFsc2UpKSB7Ci0JCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQp
OwotCQkJCXJldHVybiAtRU5PTUVNOwotCQkJfQotCQkJcGVyc2lzdGVudF9nbnQtPmdudCA9IHJl
cS0+dS5ydy5zZWdbaV0uZ3JlZjsKLQkJCXBlcnNpc3RlbnRfZ250LT5oYW5kbGUgPSBCTEtCQUNL
X0lOVkFMSURfSEFORExFOwotCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzID0gUEVSU0lTVEVOVF9H
TlRfQUNUSVZFOwotCi0JCQlwYWdlc190b19nbnRbc2Vnc190b19tYXBdID0KLQkJCQlwZXJzaXN0
ZW50X2dudC0+cGFnZTsKLQkJCWFkZHIgPSAodW5zaWduZWQgbG9uZykgcGZuX3RvX2thZGRyKAot
CQkJCXBhZ2VfdG9fcGZuKHBlcnNpc3RlbnRfZ250LT5wYWdlKSk7Ci0KLQkJCWFkZF9wZXJzaXN0
ZW50X2dudCgmYmxraWYtPnBlcnNpc3RlbnRfZ250cywKLQkJCQlwZXJzaXN0ZW50X2dudCk7Ci0J
CQlibGtpZi0+cGVyc2lzdGVudF9nbnRfYysrOwotCQkJcHJfZGVidWcoRFJWX1BGWCAiIGdyYW50
ICV1IGFkZGVkIHRvIHRoZSB0cmVlIG9mIHBlcnNpc3RlbnQgZ3JhbnRzLCB1c2luZyAldS8ldVxu
IiwKLQkJCQkgcGVyc2lzdGVudF9nbnQtPmdudCwgYmxraWYtPnBlcnNpc3RlbnRfZ250X2MsCi0J
CQkJIHhlbl9ibGtpZl9tYXhfcGdyYW50cyk7Ci0JCX0gZWxzZSB7Ci0JCQkvKgotCQkJICogV2Ug
YXJlIGVpdGhlciB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQKLQkJCSAqIGhpdCB0aGUgbWF4
aW11bSBsaW1pdCBvZiBncmFudHMgbWFwcGVkLAotCQkJICogb3Igd2UgYXJlIG5vdCB1c2luZyBw
ZXJzaXN0ZW50IGdyYW50cy4KLQkJCSAqLwotCQkJaWYgKHVzZV9wZXJzaXN0ZW50X2dudHMgJiYK
LQkJCQkhYmxraWYtPnZiZC5vdmVyZmxvd19tYXhfZ3JhbnRzKSB7Ci0JCQkJYmxraWYtPnZiZC5v
dmVyZmxvd19tYXhfZ3JhbnRzID0gMTsKLQkJCQlwcl9kZWJ1ZyhEUlZfUEZYICIgZG9tYWluICV1
LCBkZXZpY2UgJSN4IGlzIHVzaW5nIG1heGltdW0gbnVtYmVyIG9mIHBlcnNpc3RlbnQgZ3JhbnRz
XG4iLAotCQkJCQkgYmxraWYtPmRvbWlkLCBibGtpZi0+dmJkLmhhbmRsZSk7Ci0JCQl9Ci0JCQlu
ZXdfbWFwID0gdHJ1ZTsKLQkJCXBhZ2VzW2ldID0gYmxrYmstPnBlbmRpbmdfcGFnZShwZW5kaW5n
X3JlcSwgaSk7Ci0JCQlhZGRyID0gdmFkZHIocGVuZGluZ19yZXEsIGkpOwotCQkJcGFnZXNfdG9f
Z250W3NlZ3NfdG9fbWFwXSA9Ci0JCQkJYmxrYmstPnBlbmRpbmdfcGFnZShwZW5kaW5nX3JlcSwg
aSk7Ci0JCX0KLQotCQlpZiAocGVyc2lzdGVudF9nbnQpIHsKIAkJCXBhZ2VzW2ldID0gcGVyc2lz
dGVudF9nbnQtPnBhZ2U7CiAJCQlwZXJzaXN0ZW50X2dudHNbaV0gPSBwZXJzaXN0ZW50X2dudDsK
IAkJfSBlbHNlIHsKKwkJCWlmIChnZXRfZnJlZV9wYWdlKGJsa2lmLCAmcGFnZXNbaV0pKQorCQkJ
CWdvdG8gb3V0X29mX21lbW9yeTsKKwkJCWFkZHIgPSB2YWRkcihwYWdlc1tpXSk7CisJCQlwYWdl
c190b19nbnRbc2Vnc190b19tYXBdID0gcGFnZXNbaV07CiAJCQlwZXJzaXN0ZW50X2dudHNbaV0g
PSBOVUxMOwotCQl9Ci0KLQkJaWYgKG5ld19tYXApIHsKIAkJCWZsYWdzID0gR05UTUFQX2hvc3Rf
bWFwOwotCQkJaWYgKCFwZXJzaXN0ZW50X2dudCAmJgorCQkJaWYgKCF1c2VfcGVyc2lzdGVudF9n
bnRzICYmCiAJCQkgICAgKHBlbmRpbmdfcmVxLT5vcGVyYXRpb24gIT0gQkxLSUZfT1BfUkVBRCkp
CiAJCQkJZmxhZ3MgfD0gR05UTUFQX3JlYWRvbmx5OwogCQkJZ250dGFiX3NldF9tYXBfb3AoJm1h
cFtzZWdzX3RvX21hcCsrXSwgYWRkciwKQEAgLTcxNCw1NCArNzM2LDcxIEBAIHN0YXRpYyBpbnQg
eGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCSAqIHRoZSBwYWdlIGZy
b20gdGhlIG90aGVyIGRvbWFpbi4KIAkgKi8KIAlmb3IgKGkgPSAwLCBqID0gMDsgaSA8IG5zZWc7
IGkrKykgewotCQlpZiAoIXBlcnNpc3RlbnRfZ250c1tpXSB8fAotCQkgICAgcGVyc2lzdGVudF9n
bnRzW2ldLT5oYW5kbGUgPT0gQkxLQkFDS19JTlZBTElEX0hBTkRMRSkgeworCQlpZiAoIXBlcnNp
c3RlbnRfZ250c1tpXSkgewogCQkJLyogVGhpcyBpcyBhIG5ld2x5IG1hcHBlZCBncmFudCAqLwog
CQkJQlVHX09OKGogPj0gc2Vnc190b19tYXApOwogCQkJaWYgKHVubGlrZWx5KG1hcFtqXS5zdGF0
dXMgIT0gMCkpIHsKIAkJCQlwcl9kZWJ1ZyhEUlZfUEZYICJpbnZhbGlkIGJ1ZmZlciAtLSBjb3Vs
ZCBub3QgcmVtYXAgaXRcbiIpOwotCQkJCW1hcFtqXS5oYW5kbGUgPSBCTEtCQUNLX0lOVkFMSURf
SEFORExFOworCQkJCXBlbmRpbmdfaGFuZGxlKHBlbmRpbmdfcmVxLCBpKSA9CisJCQkJCUJMS0JB
Q0tfSU5WQUxJRF9IQU5ETEU7CiAJCQkJcmV0IHw9IDE7Ci0JCQkJaWYgKHBlcnNpc3RlbnRfZ250
c1tpXSkgewotCQkJCQlyYl9lcmFzZSgmcGVyc2lzdGVudF9nbnRzW2ldLT5ub2RlLAotCQkJCQkJ
ICZibGtpZi0+cGVyc2lzdGVudF9nbnRzKTsKLQkJCQkJYmxraWYtPnBlcnNpc3RlbnRfZ250X2Mt
LTsKLQkJCQkJa2ZyZWUocGVyc2lzdGVudF9nbnRzW2ldKTsKLQkJCQkJcGVyc2lzdGVudF9nbnRz
W2ldID0gTlVMTDsKLQkJCQl9CisJCQkJaisrOworCQkJCWNvbnRpbnVlOwogCQkJfQorCQkJcGVu
ZGluZ19oYW5kbGUocGVuZGluZ19yZXEsIGkpID0gbWFwW2pdLmhhbmRsZTsKIAkJfQotCQlpZiAo
cGVyc2lzdGVudF9nbnRzW2ldKSB7Ci0JCQlpZiAocGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGUg
PT0KLQkJCSAgICBCTEtCQUNLX0lOVkFMSURfSEFORExFKSB7CisJCWlmIChwZXJzaXN0ZW50X2du
dHNbaV0pCisJCQlnb3RvIG5leHQ7CisJCWlmICh1c2VfcGVyc2lzdGVudF9nbnRzICYmCisJCSAg
ICBibGtpZi0+cGVyc2lzdGVudF9nbnRfYyA8IHhlbl9ibGtpZl9tYXhfcGdyYW50cykgeworCQkJ
LyoKKwkJCSAqIFdlIGFyZSB1c2luZyBwZXJzaXN0ZW50IGdyYW50cywgdGhlIGdyYW50IGlzCisJ
CQkgKiBub3QgbWFwcGVkIGJ1dCB3ZSBoYXZlIHJvb20gZm9yIGl0CisJCQkgKi8KKwkJCXBlcnNp
c3RlbnRfZ250ID0ga21hbGxvYyhzaXplb2Yoc3RydWN0IHBlcnNpc3RlbnRfZ250KSwKKwkJCQkg
ICAgICAgICAgICAgICAgIEdGUF9LRVJORUwpOworCQkJaWYgKCFwZXJzaXN0ZW50X2dudCkgewog
CQkJCS8qCi0JCQkJICogSWYgdGhpcyBpcyBhIG5ldyBwZXJzaXN0ZW50IGdyYW50Ci0JCQkJICog
c2F2ZSB0aGUgaGFuZGxlcgorCQkJCSAqIElmIHdlIGRvbid0IGhhdmUgZW5vdWdoIG1lbW9yeSB0
bworCQkJCSAqIGFsbG9jYXRlIHRoZSBwZXJzaXN0ZW50X2dudCBzdHJ1Y3QKKwkJCQkgKiBtYXAg
dGhpcyBncmFudCBub24tcGVyc2lzdGVubHkKIAkJCQkgKi8KLQkJCQlwZXJzaXN0ZW50X2dudHNb
aV0tPmhhbmRsZSA9IG1hcFtqKytdLmhhbmRsZTsKLQkJCX0KLQkJCXBlbmRpbmdfaGFuZGxlKHBl
bmRpbmdfcmVxLCBpKSA9Ci0JCQkJcGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGU7Ci0KLQkJCWlm
IChyZXQpCi0JCQkJY29udGludWU7Ci0KLQkJCXNlZ1tpXS5idWYgPSBwZm5fdG9fbWZuKHBhZ2Vf
dG9fcGZuKAotCQkJCXBlcnNpc3RlbnRfZ250c1tpXS0+cGFnZSkpIDw8IFBBR0VfU0hJRlQgfAot
CQkJCShyZXEtPnUucncuc2VnW2ldLmZpcnN0X3NlY3QgPDwgOSk7Ci0JCX0gZWxzZSB7Ci0JCQlw
ZW5kaW5nX2hhbmRsZShwZW5kaW5nX3JlcSwgaSkgPSBtYXBbal0uaGFuZGxlOwotCi0JCQlpZiAo
cmV0KSB7CiAJCQkJaisrOwotCQkJCWNvbnRpbnVlOworCQkJCWdvdG8gbmV4dDsKIAkJCX0KLQot
CQkJc2VnW2ldLmJ1ZiA9IG1hcFtqKytdLmRldl9idXNfYWRkciB8Ci0JCQkJKHJlcS0+dS5ydy5z
ZWdbaV0uZmlyc3Rfc2VjdCA8PCA5KTsKKwkJCXBlcnNpc3RlbnRfZ250LT5nbnQgPSBtYXBbal0u
cmVmOworCQkJcGVyc2lzdGVudF9nbnQtPmhhbmRsZSA9IG1hcFtqXS5oYW5kbGU7CisJCQlwZXJz
aXN0ZW50X2dudC0+ZmxhZ3MgPSBQRVJTSVNURU5UX0dOVF9BQ1RJVkU7CisJCQlwZXJzaXN0ZW50
X2dudC0+cGFnZSA9IHBhZ2VzW2ldOworCQkJaWYgKGFkZF9wZXJzaXN0ZW50X2dudCgmYmxraWYt
PnBlcnNpc3RlbnRfZ250cywKKwkJCSAgICAgICAgICAgICAgICAgICAgICAgcGVyc2lzdGVudF9n
bnQpKSB7CisJCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOworCQkJCWdvdG8gbmV4dDsKKwkJCX0K
KwkJCWJsa2lmLT5wZXJzaXN0ZW50X2dudF9jKys7CisJCQlwZXJzaXN0ZW50X2dudHNbaV0gPSBw
ZXJzaXN0ZW50X2dudDsKKwkJCXByX2RlYnVnKERSVl9QRlggIiBncmFudCAldSBhZGRlZCB0byB0
aGUgdHJlZSBvZiBwZXJzaXN0ZW50IGdyYW50cywgdXNpbmcgJXUvJXVcbiIsCisJCQkJIHBlcnNp
c3RlbnRfZ250LT5nbnQsIGJsa2lmLT5wZXJzaXN0ZW50X2dudF9jLAorCQkJCSB4ZW5fYmxraWZf
bWF4X3BncmFudHMpOworCQkJaisrOworCQkJZ290byBuZXh0OworCQl9CisJCWlmICh1c2VfcGVy
c2lzdGVudF9nbnRzICYmICFibGtpZi0+dmJkLm92ZXJmbG93X21heF9ncmFudHMpIHsKKwkJCWJs
a2lmLT52YmQub3ZlcmZsb3dfbWF4X2dyYW50cyA9IDE7CisJCQlwcl9kZWJ1ZyhEUlZfUEZYICIg
ZG9tYWluICV1LCBkZXZpY2UgJSN4IGlzIHVzaW5nIG1heGltdW0gbnVtYmVyIG9mIHBlcnNpc3Rl
bnQgZ3JhbnRzXG4iLAorCQkJICAgICAgICAgYmxraWYtPmRvbWlkLCBibGtpZi0+dmJkLmhhbmRs
ZSk7CiAJCX0KKwkJaisrOworbmV4dDoKKwkJc2VnW2ldLmJ1ZiA9IHBmbl90b19tZm4ocGFnZV90
b19wZm4ocGFnZXNbaV0pKSA8PCBQQUdFX1NISUZUIHwKKwkJICAgICAgICAgICAgIChyZXEtPnUu
cncuc2VnW2ldLmZpcnN0X3NlY3QgPDwgOSk7CiAJfQogCXJldHVybiByZXQ7CisKK291dF9vZl9t
ZW1vcnk6CisJcHJfYWxlcnQoRFJWX1BGWCAiJXM6IG91dCBvZiBtZW1vcnlcbiIsIF9fZnVuY19f
KTsKKwlwdXRfZnJlZV9wYWdlcyhibGtpZiwgcGFnZXNfdG9fZ250LCBzZWdzX3RvX21hcCk7CisJ
cmV0dXJuIC1FTk9NRU07CiB9CiAKIHN0YXRpYyBpbnQgZGlzcGF0Y2hfZGlzY2FyZF9pbyhzdHJ1
Y3QgeGVuX2Jsa2lmICpibGtpZiwKQEAgLTk2Miw3ICsxMDAxLDcgQEAgc3RhdGljIGludCBkaXNw
YXRjaF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAlpbnQgb3BlcmF0aW9u
OwogCXN0cnVjdCBibGtfcGx1ZyBwbHVnOwogCWJvb2wgZHJhaW4gPSBmYWxzZTsKLQlzdHJ1Y3Qg
cGFnZSAqcGFnZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGFn
ZSAqKnBhZ2VzID0gcGVuZGluZ19yZXEtPnBhZ2VzOwogCiAJc3dpdGNoIChyZXEtPm9wZXJhdGlv
bikgewogCWNhc2UgQkxLSUZfT1BfUkVBRDoKQEAgLTExOTMsMjIgKzEyMzIsMTQgQEAgc3RhdGlj
IGludCBfX2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIAkJCQkJeGVuX2Jsa2lmX3JlcXMsIEdG
UF9LRVJORUwpOwogCWJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMgPSBrbWFsbG9jKHNpemVv
ZihibGtiay0+cGVuZGluZ19ncmFudF9oYW5kbGVzWzBdKSAqCiAJCQkJCW1tYXBfcGFnZXMsIEdG
UF9LRVJORUwpOwotCWJsa2JrLT5wZW5kaW5nX3BhZ2VzICAgICAgICAgPSBremFsbG9jKHNpemVv
ZihibGtiay0+cGVuZGluZ19wYWdlc1swXSkgKgotCQkJCQltbWFwX3BhZ2VzLCBHRlBfS0VSTkVM
KTsKIAotCWlmICghYmxrYmstPnBlbmRpbmdfcmVxcyB8fCAhYmxrYmstPnBlbmRpbmdfZ3JhbnRf
aGFuZGxlcyB8fAotCSAgICAhYmxrYmstPnBlbmRpbmdfcGFnZXMpIHsKKwlpZiAoIWJsa2JrLT5w
ZW5kaW5nX3JlcXMgfHwgIWJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMpIHsKIAkJcmMgPSAt
RU5PTUVNOwogCQlnb3RvIG91dF9vZl9tZW1vcnk7CiAJfQogCiAJZm9yIChpID0gMDsgaSA8IG1t
YXBfcGFnZXM7IGkrKykgewogCQlibGtiay0+cGVuZGluZ19ncmFudF9oYW5kbGVzW2ldID0gQkxL
QkFDS19JTlZBTElEX0hBTkRMRTsKLQkJYmxrYmstPnBlbmRpbmdfcGFnZXNbaV0gPSBhbGxvY19w
YWdlKEdGUF9LRVJORUwpOwotCQlpZiAoYmxrYmstPnBlbmRpbmdfcGFnZXNbaV0gPT0gTlVMTCkg
ewotCQkJcmMgPSAtRU5PTUVNOwotCQkJZ290byBvdXRfb2ZfbWVtb3J5OwotCQl9CiAJfQogCXJj
ID0geGVuX2Jsa2lmX2ludGVyZmFjZV9pbml0KCk7CiAJaWYgKHJjKQpAQCAtMTIzMywxMyArMTI2
NCw2IEBAIHN0YXRpYyBpbnQgX19pbml0IHhlbl9ibGtpZl9pbml0KHZvaWQpCiAgZmFpbGVkX2lu
aXQ6CiAJa2ZyZWUoYmxrYmstPnBlbmRpbmdfcmVxcyk7CiAJa2ZyZWUoYmxrYmstPnBlbmRpbmdf
Z3JhbnRfaGFuZGxlcyk7Ci0JaWYgKGJsa2JrLT5wZW5kaW5nX3BhZ2VzKSB7Ci0JCWZvciAoaSA9
IDA7IGkgPCBtbWFwX3BhZ2VzOyBpKyspIHsKLQkJCWlmIChibGtiay0+cGVuZGluZ19wYWdlc1tp
XSkKLQkJCQlfX2ZyZWVfcGFnZShibGtiay0+cGVuZGluZ19wYWdlc1tpXSk7Ci0JCX0KLQkJa2Zy
ZWUoYmxrYmstPnBlbmRpbmdfcGFnZXMpOwotCX0KIAlrZnJlZShibGtiayk7CiAJYmxrYmsgPSBO
VUxMOwogCXJldHVybiByYzsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
Y29tbW9uLmggYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCmluZGV4IGJkNDRk
NzUuLjYwNGJkMzAgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9u
LmgKKysrIGIvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9jb21tb24uaApAQCAtMjA5LDYgKzIw
OSwxMSBAQCBzdHJ1Y3QgeGVuX2Jsa2lmIHsKIAl1bnNpZ25lZCBpbnQJCXBlcnNpc3RlbnRfZ250
X2M7CiAJdW5zaWduZWQgbG9uZwkJbmV4dF9scnU7CiAKKwkvKiBidWZmZXIgb2YgZnJlZSBwYWdl
cyB0byBtYXAgZ3JhbnQgcmVmcyAqLworCXNwaW5sb2NrX3QJCWZyZWVfcGFnZXNfbG9jazsKKwlp
bnQJCQlmcmVlX3BhZ2VzX251bTsKKwlzdHJ1Y3QgbGlzdF9oZWFkCWZyZWVfcGFnZXM7CisKIAkv
KiBzdGF0aXN0aWNzICovCiAJdW5zaWduZWQgbG9uZwkJc3RfcHJpbnQ7CiAJaW50CQkJc3RfcmRf
cmVxOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyBiL2Ry
aXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKaW5kZXggYWJiMzk5YS4uZDc5MjZlYyAx
MDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYworKysgYi9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCkBAIC0xMTksNiArMTE5LDkgQEAgc3RhdGlj
IHN0cnVjdCB4ZW5fYmxraWYgKnhlbl9ibGtpZl9hbGxvYyhkb21pZF90IGRvbWlkKQogCWJsa2lm
LT5uZXh0X2xydSA9IGppZmZpZXM7CiAJaW5pdF93YWl0cXVldWVfaGVhZCgmYmxraWYtPndhaXRp
bmdfdG9fZnJlZSk7CiAJYmxraWYtPnBlcnNpc3RlbnRfZ250cy5yYl9ub2RlID0gTlVMTDsKKwlz
cGluX2xvY2tfaW5pdCgmYmxraWYtPmZyZWVfcGFnZXNfbG9jayk7CisJSU5JVF9MSVNUX0hFQUQo
JmJsa2lmLT5mcmVlX3BhZ2VzKTsKKwlibGtpZi0+ZnJlZV9wYWdlc19udW0gPSAwOwogCiAJcmV0
dXJuIGJsa2lmOwogfQotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:29:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:29: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 1UB0k8-0005pW-R8; Thu, 28 Feb 2013 10:29:40 +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 1UB0k6-0005nk-Vn
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:29:39 +0000
Received: from [193.109.254.147:36608] by server-10.bemta-14.messagelabs.com
	id B3/47-12679-2913F215; Thu, 28 Feb 2013 10:29:38 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362047374!6337123!9
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1627 invoked from network); 28 Feb 2013 10:29:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:29:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2012289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:29:38 +0000
Received: from localhost.localdomain (10.30.249.242) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.297.1; Thu, 28 Feb 2013 10:29:37 +0000
From: Roger Pau Monne <roger.pau@citrix.com>
To: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 11:28:51 +0100
Message-ID: <1362047335-26402-9-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH RFC 08/12] xen-blkback: use balloon pages for
	all mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

VXNpbmcgYmFsbG9vbiBwYWdlcyBmb3IgYWxsIGdyYW50ZWQgcGFnZXMgYWxsb3dzIHVzIHRvIHNp
bXBsaWZ5IHRoZQpsb2dpYyBpbiBibGtiYWNrLCBzcGVjaWFsbHkgaW4gdGhlIHhlbl9ibGtia19t
YXAgZnVuY3Rpb24sIHNpbmNlIG5vdwp3ZSBjYW4gZGVjaWRlIGlmIHdlIHdhbnQgdG8gbWFwIGEg
Z3JhbnQgcGVyc2lzdGVudGx5IG9yIG5vdCBhZnRlciB3ZQpoYXZlIGFjdHVhbGx5IG1hcHBlZCBp
dC4gVGhpcyBjb3VsZCBub3QgYmUgZG9uZSBiZWZvcmUgYmVjYXVzZQpwZXJzaXN0ZW50IGdyYW50
cyB1c2VkIGJhbGxvb25lZCBwYWdlcywgYW5kIG5vbi1wZXJzaXN0ZW50IGdyYW50cyB1c2VkCnBh
Z2VzIGZyb20gdGhlIGtlcm5lbC4KClRoaXMgcGF0Y2ggYWxzbyBpbnRyb2R1Y2VzIHNldmVyYWwg
Y2hhbmdlcywgdGhlIGZpcnN0IG9uZSBpcyB0aGF0IHRoZQpsaXN0IG9mIGZyZWUgcGFnZXMgaXMg
bm8gbG9uZ2VyIGdsb2JhbCwgbm93IGVhY2ggYmxrYmFjayBpbnN0YW5jZSBoYXMKaXQncyBvd24g
bGlzdCBvZiBmcmVlIHBhZ2VzIHRoYXQgY2FuIGJlIHVzZWQgdG8gbWFwIGdyYW50cy4gQWxzbywg
YQpydW4gdGltZSBwYXJhbWV0ZXIgKG1heF9idWZmZXJfcGFnZXMpIGhhcyBiZWVuIGFkZGVkIGlu
IG9yZGVyIHRvIHR1bmUKdGhlIG1heGltdW0gbnVtYmVyIG9mIGZyZWUgcGFnZXMgZWFjaCBibGti
YWNrIGluc3RhbmNlIHdpbGwga2VlcCBpbgppdCdzIGJ1ZmZlci4KClNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPgpDYzogeGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKQ2M6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNv
bT4KLS0tCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYyB8ICAyNzggKysrKysr
KysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0KIGRyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
Y29tbW9uLmggIHwgICAgNSArCiBkcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jICB8
ICAgIDMgKwogMyBmaWxlcyBjaGFuZ2VkLCAxNTkgaW5zZXJ0aW9ucygrKSwgMTI3IGRlbGV0aW9u
cygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jIGIv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKaW5kZXggYjVlNzQ5NS4uYmEyN2Zj
MyAxMDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKKysrIGIv
ZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9ibGtiYWNrLmMKQEAgLTEwMSw2ICsxMDEsMjEgQEAg
bW9kdWxlX3BhcmFtX25hbWVkKGxydV9udW1fY2xlYW4sIHhlbl9ibGtpZl9scnVfbnVtX2NsZWFu
LCBpbnQsIDA2NDQpOwogTU9EVUxFX1BBUk1fREVTQyhscnVfbnVtX2NsZWFuLAogIk51bWJlciBv
ZiBwZXJzaXN0ZW50IGdyYW50cyB0byB1bm1hcCB3aGVuIHRoZSBsaXN0IGlzIGZ1bGwiKTsKIAor
LyoKKyAqIE1heGltdW0gbnVtYmVyIG9mIHVudXNlZCBmcmVlIHBhZ2VzIHRvIGtlZXAgaW4gdGhl
IGludGVybmFsIGJ1ZmZlci4KKyAqIFNldHRpbmcgdGhpcyB0byBhIHZhbHVlIHRvbyBsb3cgd2ls
bCByZWR1Y2UgbWVtb3J5IHVzZWQgaW4gZWFjaCBiYWNrZW5kLAorICogYnV0IGNhbiBoYXZlIGEg
cGVyZm9ybWFuY2UgcGVuYWx0eS4KKyAqCisgKiBBIHNhbmUgdmFsdWUgaXMgeGVuX2Jsa2lmX3Jl
cXMgKiBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QsIGJ1dCBjYW4KKyAqIGJlIHNldCB0
byBhIGxvd2VyIHZhbHVlIHRoYXQgbWlnaHQgZGVncmFkZSBwZXJmb3JtYW5jZSBvbiBzb21lIGlu
dGVuc2l2ZQorICogSU8gd29ya2xvYWRzLgorICovCisKK3N0YXRpYyBpbnQgeGVuX2Jsa2lmX21h
eF9idWZmZXJfcGFnZXMgPSAxMDI0OworbW9kdWxlX3BhcmFtX25hbWVkKG1heF9idWZmZXJfcGFn
ZXMsIHhlbl9ibGtpZl9tYXhfYnVmZmVyX3BhZ2VzLCBpbnQsIDA2NDQpOworTU9EVUxFX1BBUk1f
REVTQyhtYXhfYnVmZmVyX3BhZ2VzLAorIk1heGltdW0gbnVtYmVyIG9mIGZyZWUgcGFnZXMgdG8g
a2VlcCBpbiBlYWNoIGJsb2NrIGJhY2tlbmQgYnVmZmVyIik7CisKIC8qIFJ1bi10aW1lIHN3aXRj
aGFibGU6IC9zeXMvbW9kdWxlL2Jsa2JhY2svcGFyYW1ldGVycy8gKi8KIHN0YXRpYyB1bnNpZ25l
ZCBpbnQgbG9nX3N0YXRzOwogbW9kdWxlX3BhcmFtKGxvZ19zdGF0cywgaW50LCAwNjQ0KTsKQEAg
LTEyMCw2ICsxMzUsNyBAQCBzdHJ1Y3QgcGVuZGluZ19yZXEgewogCWludAkJCXN0YXR1czsKIAlz
dHJ1Y3QgbGlzdF9oZWFkCWZyZWVfbGlzdDsKIAlzdHJ1Y3QgcGVyc2lzdGVudF9nbnQJKnBlcnNp
c3RlbnRfZ250c1tCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1RdOworCXN0cnVjdCBwYWdl
CQkqcGFnZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKIH07CiAKICNkZWZpbmUg
QkxLQkFDS19JTlZBTElEX0hBTkRMRSAofjApCkBAIC0xMzEsOCArMTQ3LDYgQEAgc3RydWN0IHhl
bl9ibGtiayB7CiAJLyogQW5kIGl0cyBzcGlubG9jay4gKi8KIAlzcGlubG9ja190CQlwZW5kaW5n
X2ZyZWVfbG9jazsKIAl3YWl0X3F1ZXVlX2hlYWRfdAlwZW5kaW5nX2ZyZWVfd3E7Ci0JLyogVGhl
IGxpc3Qgb2YgYWxsIHBhZ2VzIHRoYXQgYXJlIGF2YWlsYWJsZS4gKi8KLQlzdHJ1Y3QgcGFnZQkJ
KipwZW5kaW5nX3BhZ2VzOwogCS8qIEFuZCB0aGUgZ3JhbnQgaGFuZGxlcyB0aGF0IGFyZSBhdmFp
bGFibGUuICovCiAJZ3JhbnRfaGFuZGxlX3QJCSpwZW5kaW5nX2dyYW50X2hhbmRsZXM7CiB9OwpA
QCAtMTUxLDE0ICsxNjUsNjYgQEAgc3RhdGljIGlubGluZSBpbnQgdmFkZHJfcGFnZW5yKHN0cnVj
dCBwZW5kaW5nX3JlcSAqcmVxLCBpbnQgc2VnKQogCQlCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JF
UVVFU1QgKyBzZWc7CiB9CiAKLSNkZWZpbmUgcGVuZGluZ19wYWdlKHJlcSwgc2VnKSBwZW5kaW5n
X3BhZ2VzW3ZhZGRyX3BhZ2VucihyZXEsIHNlZyldCitzdGF0aWMgaW5saW5lIGludCBnZXRfZnJl
ZV9wYWdlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lmLCBzdHJ1Y3QgcGFnZSAqKnBhZ2UpCit7CisJ
dW5zaWduZWQgbG9uZyBmbGFnczsKKworCXNwaW5fbG9ja19pcnFzYXZlKCZibGtpZi0+ZnJlZV9w
YWdlc19sb2NrLCBmbGFncyk7CisJaWYgKGxpc3RfZW1wdHkoJmJsa2lmLT5mcmVlX3BhZ2VzKSkg
eworCQlCVUdfT04oYmxraWYtPmZyZWVfcGFnZXNfbnVtICE9IDApOworCQlzcGluX3VubG9ja19p
cnFyZXN0b3JlKCZibGtpZi0+ZnJlZV9wYWdlc19sb2NrLCBmbGFncyk7CisJCXJldHVybiBhbGxv
Y194ZW5iYWxsb29uZWRfcGFnZXMoMSwgcGFnZSwgZmFsc2UpOworCX0KKwlCVUdfT04oYmxraWYt
PmZyZWVfcGFnZXNfbnVtID09IDApOworCXBhZ2VbMF0gPSBsaXN0X2ZpcnN0X2VudHJ5KCZibGtp
Zi0+ZnJlZV9wYWdlcywgc3RydWN0IHBhZ2UsIGxydSk7CisJbGlzdF9kZWwoJnBhZ2VbMF0tPmxy
dSk7CisJYmxraWYtPmZyZWVfcGFnZXNfbnVtLS07CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgm
YmxraWYtPmZyZWVfcGFnZXNfbG9jaywgZmxhZ3MpOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRp
YyBpbmxpbmUgdm9pZCBwdXRfZnJlZV9wYWdlcyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwgc3Ry
dWN0IHBhZ2UgKipwYWdlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCBu
dW0pCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwlpbnQgaTsKKworCXNwaW5fbG9ja19pcnFz
YXZlKCZibGtpZi0+ZnJlZV9wYWdlc19sb2NrLCBmbGFncyk7CisJZm9yIChpID0gMDsgaSA8IG51
bTsgaSsrKQorCQlsaXN0X2FkZCgmcGFnZVtpXS0+bHJ1LCAmYmxraWYtPmZyZWVfcGFnZXMpOwor
CWJsa2lmLT5mcmVlX3BhZ2VzX251bSArPSBudW07CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgm
YmxraWYtPmZyZWVfcGFnZXNfbG9jaywgZmxhZ3MpOworfQogCi1zdGF0aWMgaW5saW5lIHVuc2ln
bmVkIGxvbmcgdmFkZHIoc3RydWN0IHBlbmRpbmdfcmVxICpyZXEsIGludCBzZWcpCitzdGF0aWMg
aW5saW5lIHZvaWQgcmVtb3ZlX2ZyZWVfcGFnZXMoc3RydWN0IHhlbl9ibGtpZiAqYmxraWYsIGlu
dCBudW0pCiB7Ci0JdW5zaWduZWQgbG9uZyBwZm4gPSBwYWdlX3RvX3BmbihibGtiay0+cGVuZGlu
Z19wYWdlKHJlcSwgc2VnKSk7Ci0JcmV0dXJuICh1bnNpZ25lZCBsb25nKXBmbl90b19rYWRkcihw
Zm4pOworCS8qIFJlbW92ZSByZXF1ZXN0ZWQgcGFnZXMgaW4gYmF0Y2hlcyBvZiAxMCAqLworCXN0
cnVjdCBwYWdlICpwYWdlWzEwXTsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCBudW1fcGFn
ZXMgPSAwOworCisJc3Bpbl9sb2NrX2lycXNhdmUoJmJsa2lmLT5mcmVlX3BhZ2VzX2xvY2ssIGZs
YWdzKTsKKwl3aGlsZSAoYmxraWYtPmZyZWVfcGFnZXNfbnVtID4gbnVtKSB7CisJCUJVR19PTihs
aXN0X2VtcHR5KCZibGtpZi0+ZnJlZV9wYWdlcykpOworCQlwYWdlW251bV9wYWdlc10gPSBsaXN0
X2ZpcnN0X2VudHJ5KCZibGtpZi0+ZnJlZV9wYWdlcywKKwkJICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBzdHJ1Y3QgcGFnZSwgbHJ1KTsKKwkJbGlzdF9kZWwoJnBhZ2VbbnVtX3Bh
Z2VzXS0+bHJ1KTsKKwkJYmxraWYtPmZyZWVfcGFnZXNfbnVtLS07CisJCWlmICgrK251bV9wYWdl
cyA9PSAxMCkgeworCQkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYmxraWYtPmZyZWVfcGFnZXNf
bG9jaywgZmxhZ3MpOworCQkJZnJlZV94ZW5iYWxsb29uZWRfcGFnZXMobnVtX3BhZ2VzLCBwYWdl
KTsKKwkJCXNwaW5fbG9ja19pcnFzYXZlKCZibGtpZi0+ZnJlZV9wYWdlc19sb2NrLCBmbGFncyk7
CisJCQludW1fcGFnZXMgPSAwOworCQl9CisJfQorCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmJs
a2lmLT5mcmVlX3BhZ2VzX2xvY2ssIGZsYWdzKTsKKwlpZiAobnVtX3BhZ2VzICE9IDApCisJCWZy
ZWVfeGVuYmFsbG9vbmVkX3BhZ2VzKG51bV9wYWdlcywgcGFnZSk7CiB9CiAKKyNkZWZpbmUgdmFk
ZHIocGFnZSkgKCh1bnNpZ25lZCBsb25nKXBmbl90b19rYWRkcihwYWdlX3RvX3BmbihwYWdlKSkp
CisKICNkZWZpbmUgcGVuZGluZ19oYW5kbGUoX3JlcSwgX3NlZykgXAogCShibGtiay0+cGVuZGlu
Z19ncmFudF9oYW5kbGVzW3ZhZGRyX3BhZ2VucihfcmVxLCBfc2VnKV0pCiAKQEAgLTE3OCw3ICsy
NDQsNyBAQCBzdGF0aWMgdm9pZCBtYWtlX3Jlc3BvbnNlKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
LCB1NjQgaWQsCiAJICAgICAobikgPSAoJihwb3MpLT5ub2RlICE9IE5VTEwpID8gcmJfbmV4dCgm
KHBvcyktPm5vZGUpIDogTlVMTCkKIAogCi1zdGF0aWMgdm9pZCBhZGRfcGVyc2lzdGVudF9nbnQo
c3RydWN0IHJiX3Jvb3QgKnJvb3QsCitzdGF0aWMgaW50IGFkZF9wZXJzaXN0ZW50X2dudChzdHJ1
Y3QgcmJfcm9vdCAqcm9vdCwKIAkJCSAgICAgICBzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKnBlcnNp
c3RlbnRfZ250KQogewogCXN0cnVjdCByYl9ub2RlICoqbmV3ID0gJihyb290LT5yYl9ub2RlKSwg
KnBhcmVudCA9IE5VTEw7CkBAIC0xOTQsMTQgKzI2MCwxNSBAQCBzdGF0aWMgdm9pZCBhZGRfcGVy
c2lzdGVudF9nbnQoc3RydWN0IHJiX3Jvb3QgKnJvb3QsCiAJCWVsc2UgaWYgKHBlcnNpc3RlbnRf
Z250LT5nbnQgPiB0aGlzLT5nbnQpCiAJCQluZXcgPSAmKCgqbmV3KS0+cmJfcmlnaHQpOwogCQll
bHNlIHsKLQkJCXByX2FsZXJ0KERSVl9QRlggIiB0cnlpbmcgdG8gYWRkIGEgZ3JlZiB0aGF0J3Mg
YWxyZWFkeSBpbiB0aGUgdHJlZVxuIik7Ci0JCQlCVUcoKTsKKwkJCXByX2FsZXJ0X3JhdGVsaW1p
dGVkKERSVl9QRlggIiB0cnlpbmcgdG8gYWRkIGEgZ3JlZiB0aGF0J3MgYWxyZWFkeSBpbiB0aGUg
dHJlZVxuIik7CisJCQlyZXR1cm4gLUVJTlZBTDsKIAkJfQogCX0KIAogCS8qIEFkZCBuZXcgbm9k
ZSBhbmQgcmViYWxhbmNlIHRyZWUuICovCiAJcmJfbGlua19ub2RlKCYocGVyc2lzdGVudF9nbnQt
Pm5vZGUpLCBwYXJlbnQsIG5ldyk7CiAJcmJfaW5zZXJ0X2NvbG9yKCYocGVyc2lzdGVudF9nbnQt
Pm5vZGUpLCByb290KTsKKwlyZXR1cm4gMDsKIH0KIAogc3RhdGljIHN0cnVjdCBwZXJzaXN0ZW50
X2dudCAqZ2V0X3BlcnNpc3RlbnRfZ250KHN0cnVjdCByYl9yb290ICpyb290LApAQCAtMjIzLDcg
KzI5MCw4IEBAIHN0YXRpYyBzdHJ1Y3QgcGVyc2lzdGVudF9nbnQgKmdldF9wZXJzaXN0ZW50X2du
dChzdHJ1Y3QgcmJfcm9vdCAqcm9vdCwKIAlyZXR1cm4gTlVMTDsKIH0KIAotc3RhdGljIHZvaWQg
ZnJlZV9wZXJzaXN0ZW50X2dudHMoc3RydWN0IHJiX3Jvb3QgKnJvb3QsIHVuc2lnbmVkIGludCBu
dW0pCitzdGF0aWMgdm9pZCBmcmVlX3BlcnNpc3RlbnRfZ250cyhzdHJ1Y3QgeGVuX2Jsa2lmICpi
bGtpZiwgc3RydWN0IHJiX3Jvb3QgKnJvb3QsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB1bnNpZ25lZCBpbnQgbnVtKQogewogCXN0cnVjdCBnbnR0YWJfdW5tYXBfZ3JhbnRfcmVm
IHVubWFwW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAJc3RydWN0IHBhZ2UgKnBh
Z2VzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CkBAIC0yNDgsNyArMzE2LDcgQEAg
c3RhdGljIHZvaWQgZnJlZV9wZXJzaXN0ZW50X2dudHMoc3RydWN0IHJiX3Jvb3QgKnJvb3QsIHVu
c2lnbmVkIGludCBudW0pCiAJCQlyZXQgPSBnbnR0YWJfdW5tYXBfcmVmcyh1bm1hcCwgTlVMTCwg
cGFnZXMsCiAJCQkJc2Vnc190b191bm1hcCk7CiAJCQlCVUdfT04ocmV0KTsKLQkJCWZyZWVfeGVu
YmFsbG9vbmVkX3BhZ2VzKHNlZ3NfdG9fdW5tYXAsIHBhZ2VzKTsKKwkJCXB1dF9mcmVlX3BhZ2Vz
KGJsa2lmLCBwYWdlcywgc2Vnc190b191bm1hcCk7CiAJCQlzZWdzX3RvX3VubWFwID0gMDsKIAkJ
fQogCkBAIC0yNTksNyArMzI3LDggQEAgc3RhdGljIHZvaWQgZnJlZV9wZXJzaXN0ZW50X2dudHMo
c3RydWN0IHJiX3Jvb3QgKnJvb3QsIHVuc2lnbmVkIGludCBudW0pCiAJQlVHX09OKG51bSAhPSAw
KTsKIH0KIAotc3RhdGljIGludCBwdXJnZV9wZXJzaXN0ZW50X2dudChzdHJ1Y3QgcmJfcm9vdCAq
cm9vdCwgaW50IG51bSkKK3N0YXRpYyBpbnQgcHVyZ2VfcGVyc2lzdGVudF9nbnQoc3RydWN0IHhl
bl9ibGtpZiAqYmxraWYsIHN0cnVjdCByYl9yb290ICpyb290LAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBpbnQgbnVtKQogewogCXN0cnVjdCBnbnR0YWJfdW5tYXBfZ3JhbnRfcmVm
IHVubWFwW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAJc3RydWN0IHBhZ2UgKnBh
Z2VzW0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CkBAIC0yOTQsNyArMzYzLDcgQEAg
cHVyZ2VfbGlzdDoKIAkJCXJldCA9IGdudHRhYl91bm1hcF9yZWZzKHVubWFwLCBOVUxMLCBwYWdl
cywKIAkJCQlzZWdzX3RvX3VubWFwKTsKIAkJCUJVR19PTihyZXQpOwotCQkJZnJlZV94ZW5iYWxs
b29uZWRfcGFnZXMoc2Vnc190b191bm1hcCwgcGFnZXMpOworCQkJcHV0X2ZyZWVfcGFnZXMoYmxr
aWYsIHBhZ2VzLCBzZWdzX3RvX3VubWFwKTsKIAkJCXNlZ3NfdG9fdW5tYXAgPSAwOwogCQl9CiAK
QEAgLTMxNyw3ICszODYsNyBAQCBmaW5pc2hlZDoKIAlpZiAoc2Vnc190b191bm1hcCA+IDApIHsK
IAkJcmV0ID0gZ250dGFiX3VubWFwX3JlZnModW5tYXAsIE5VTEwsIHBhZ2VzLCBzZWdzX3RvX3Vu
bWFwKTsKIAkJQlVHX09OKHJldCk7Ci0JCWZyZWVfeGVuYmFsbG9vbmVkX3BhZ2VzKHNlZ3NfdG9f
dW5tYXAsIHBhZ2VzKTsKKwkJcHV0X2ZyZWVfcGFnZXMoYmxraWYsIHBhZ2VzLCBzZWdzX3RvX3Vu
bWFwKTsKIAl9CiAJLyogRmluYWxseSByZW1vdmUgdGhlICJ1c2VkIiBmbGFnIGZyb20gYWxsIHRo
ZSBwZXJzaXN0ZW50IGdyYW50cyAqLwogCWZvcmVhY2hfZ3JhbnRfc2FmZShwZXJzaXN0ZW50X2du
dCwgbiwgcm9vdCwgbm9kZSkgewpAQCAtNTIxLDcgKzU5MCw3IEBAIHB1cmdlX2dudF9saXN0Ogog
CQkJCSAgICAgICAgICAgeGVuX2Jsa2lmX2xydV9udW1fY2xlYW47CiAJCQkJcnFfcHVyZ2UgPSBy
cV9wdXJnZSA+IGJsa2lmLT5wZXJzaXN0ZW50X2dudF9jID8KIAkJCQkgICAgICAgICAgIGJsa2lm
LT5wZXJzaXN0ZW50X2dudF9jIDogcnFfcHVyZ2U7Ci0JCQkJcHVyZ2VkID0gcHVyZ2VfcGVyc2lz
dGVudF9nbnQoCisJCQkJcHVyZ2VkID0gcHVyZ2VfcGVyc2lzdGVudF9nbnQoYmxraWYsCiAJCQkJ
CSAgJmJsa2lmLT5wZXJzaXN0ZW50X2dudHMsIHJxX3B1cmdlKTsKIAkJCQlpZiAocHVyZ2VkICE9
IHJxX3B1cmdlKQogCQkJCQlwcl9kZWJ1ZyhEUlZfUEZYICIgdW5hYmxlIHRvIG1lZXQgcGVyc2lz
dGVudCBncmFudHMgcHVyZ2UgcmVxdWlyZW1lbnRzIGZvciBkZXZpY2UgJSN4LCBkb21haW4gJXUs
IHJlcXVlc3RlZCAlZCBkb25lICVkXG4iLApAQCAtNTM1LDEzICs2MDQsMTcgQEAgcHVyZ2VfZ250
X2xpc3Q6CiAJCQkgICAgICAgIG1zZWNzX3RvX2ppZmZpZXMoeGVuX2Jsa2lmX2xydV9pbnRlcnZh
bCk7CiAJCX0KIAorCQlyZW1vdmVfZnJlZV9wYWdlcyhibGtpZiwgeGVuX2Jsa2lmX21heF9idWZm
ZXJfcGFnZXMpOworCiAJCWlmIChsb2dfc3RhdHMgJiYgdGltZV9hZnRlcihqaWZmaWVzLCBibGtp
Zi0+c3RfcHJpbnQpKQogCQkJcHJpbnRfc3RhdHMoYmxraWYpOwogCX0KIAorCXJlbW92ZV9mcmVl
X3BhZ2VzKGJsa2lmLCAwKTsKKwogCS8qIEZyZWUgYWxsIHBlcnNpc3RlbnQgZ3JhbnQgcGFnZXMg
Ki8KIAlpZiAoIVJCX0VNUFRZX1JPT1QoJmJsa2lmLT5wZXJzaXN0ZW50X2dudHMpKQotCQlmcmVl
X3BlcnNpc3RlbnRfZ250cygmYmxraWYtPnBlcnNpc3RlbnRfZ250cywKKwkJZnJlZV9wZXJzaXN0
ZW50X2dudHMoYmxraWYsICZibGtpZi0+cGVyc2lzdGVudF9nbnRzLAogCQkJYmxraWYtPnBlcnNp
c3RlbnRfZ250X2MpOwogCiAJQlVHX09OKCFSQl9FTVBUWV9ST09UKCZibGtpZi0+cGVyc2lzdGVu
dF9nbnRzKSk7CkBAIC01NzEsNiArNjQ0LDcgQEAgc3RhdGljIHZvaWQgeGVuX2Jsa2JrX3VubWFw
KHN0cnVjdCBwZW5kaW5nX3JlcSAqcmVxKQogCXN0cnVjdCBwZXJzaXN0ZW50X2dudCAqcGVyc2lz
dGVudF9nbnQ7CiAJdW5zaWduZWQgaW50IGksIGludmNvdW50ID0gMDsKIAlncmFudF9oYW5kbGVf
dCBoYW5kbGU7CisJc3RydWN0IHhlbl9ibGtpZiAqYmxraWYgPSByZXEtPmJsa2lmOwogCWludCBy
ZXQ7CiAKIAlmb3IgKGkgPSAwOyBpIDwgcmVxLT5ucl9wYWdlczsgaSsrKSB7CkBAIC01ODEsMTcg
KzY1NSwxOCBAQCBzdGF0aWMgdm9pZCB4ZW5fYmxrYmtfdW5tYXAoc3RydWN0IHBlbmRpbmdfcmVx
ICpyZXEpCiAJCQljb250aW51ZTsKIAkJfQogCQloYW5kbGUgPSBwZW5kaW5nX2hhbmRsZShyZXEs
IGkpOworCQlwYWdlc1tpbnZjb3VudF0gPSByZXEtPnBhZ2VzW2ldOwogCQlpZiAoaGFuZGxlID09
IEJMS0JBQ0tfSU5WQUxJRF9IQU5ETEUpCiAJCQljb250aW51ZTsKLQkJZ250dGFiX3NldF91bm1h
cF9vcCgmdW5tYXBbaW52Y291bnRdLCB2YWRkcihyZXEsIGkpLAorCQlnbnR0YWJfc2V0X3VubWFw
X29wKCZ1bm1hcFtpbnZjb3VudF0sIHZhZGRyKHBhZ2VzW2ludmNvdW50XSksCiAJCQkJICAgIEdO
VE1BUF9ob3N0X21hcCwgaGFuZGxlKTsKIAkJcGVuZGluZ19oYW5kbGUocmVxLCBpKSA9IEJMS0JB
Q0tfSU5WQUxJRF9IQU5ETEU7Ci0JCXBhZ2VzW2ludmNvdW50XSA9IHZpcnRfdG9fcGFnZSh2YWRk
cihyZXEsIGkpKTsKIAkJaW52Y291bnQrKzsKIAl9CiAKIAlyZXQgPSBnbnR0YWJfdW5tYXBfcmVm
cyh1bm1hcCwgTlVMTCwgcGFnZXMsIGludmNvdW50KTsKIAlCVUdfT04ocmV0KTsKKwlwdXRfZnJl
ZV9wYWdlcyhibGtpZiwgcGFnZXMsIGludmNvdW50KTsKIH0KIAogc3RhdGljIGludCB4ZW5fYmxr
YmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCkBAIC02MDYsNyArNjgxLDYgQEAgc3Rh
dGljIGludCB4ZW5fYmxrYmtfbWFwKHN0cnVjdCBibGtpZl9yZXF1ZXN0ICpyZXEsCiAJc3RydWN0
IHhlbl9ibGtpZiAqYmxraWYgPSBwZW5kaW5nX3JlcS0+YmxraWY7CiAJcGh5c19hZGRyX3QgYWRk
ciA9IDA7CiAJaW50IGksIGo7Ci0JYm9vbCBuZXdfbWFwOwogCWludCBuc2VnID0gcmVxLT51LnJ3
Lm5yX3NlZ21lbnRzOwogCWludCBzZWdzX3RvX21hcCA9IDA7CiAJaW50IHJldCA9IDA7CkBAIC02
MzIsNjkgKzcwNiwxNyBAQCBzdGF0aWMgaW50IHhlbl9ibGtia19tYXAoc3RydWN0IGJsa2lmX3Jl
cXVlc3QgKnJlcSwKIAkJCSAqIFdlIGFyZSB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQKIAkJ
CSAqIHRoZSBncmFudCBpcyBhbHJlYWR5IG1hcHBlZAogCQkJICovCi0JCQluZXdfbWFwID0gZmFs
c2U7CiAJCQlwZXJzaXN0ZW50X2dudC0+ZmxhZ3MgfD0gUEVSU0lTVEVOVF9HTlRfQUNUSVZFOwot
CQl9IGVsc2UgaWYgKHVzZV9wZXJzaXN0ZW50X2dudHMgJiYKLQkJCSAgIGJsa2lmLT5wZXJzaXN0
ZW50X2dudF9jIDwgeGVuX2Jsa2lmX21heF9wZ3JhbnRzKSB7Ci0JCQkvKgotCQkJICogV2UgYXJl
IHVzaW5nIHBlcnNpc3RlbnQgZ3JhbnRzLCB0aGUgZ3JhbnQgaXMKLQkJCSAqIG5vdCBtYXBwZWQg
YnV0IHdlIGhhdmUgcm9vbSBmb3IgaXQKLQkJCSAqLwotCQkJbmV3X21hcCA9IHRydWU7Ci0JCQlw
ZXJzaXN0ZW50X2dudCA9IGttYWxsb2MoCi0JCQkJc2l6ZW9mKHN0cnVjdCBwZXJzaXN0ZW50X2du
dCksCi0JCQkJR0ZQX0tFUk5FTCk7Ci0JCQlpZiAoIXBlcnNpc3RlbnRfZ250KQotCQkJCXJldHVy
biAtRU5PTUVNOwotCQkJaWYgKGFsbG9jX3hlbmJhbGxvb25lZF9wYWdlcygxLCAmcGVyc2lzdGVu
dF9nbnQtPnBhZ2UsCi0JCQkgICAgZmFsc2UpKSB7Ci0JCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQp
OwotCQkJCXJldHVybiAtRU5PTUVNOwotCQkJfQotCQkJcGVyc2lzdGVudF9nbnQtPmdudCA9IHJl
cS0+dS5ydy5zZWdbaV0uZ3JlZjsKLQkJCXBlcnNpc3RlbnRfZ250LT5oYW5kbGUgPSBCTEtCQUNL
X0lOVkFMSURfSEFORExFOwotCQkJcGVyc2lzdGVudF9nbnQtPmZsYWdzID0gUEVSU0lTVEVOVF9H
TlRfQUNUSVZFOwotCi0JCQlwYWdlc190b19nbnRbc2Vnc190b19tYXBdID0KLQkJCQlwZXJzaXN0
ZW50X2dudC0+cGFnZTsKLQkJCWFkZHIgPSAodW5zaWduZWQgbG9uZykgcGZuX3RvX2thZGRyKAot
CQkJCXBhZ2VfdG9fcGZuKHBlcnNpc3RlbnRfZ250LT5wYWdlKSk7Ci0KLQkJCWFkZF9wZXJzaXN0
ZW50X2dudCgmYmxraWYtPnBlcnNpc3RlbnRfZ250cywKLQkJCQlwZXJzaXN0ZW50X2dudCk7Ci0J
CQlibGtpZi0+cGVyc2lzdGVudF9nbnRfYysrOwotCQkJcHJfZGVidWcoRFJWX1BGWCAiIGdyYW50
ICV1IGFkZGVkIHRvIHRoZSB0cmVlIG9mIHBlcnNpc3RlbnQgZ3JhbnRzLCB1c2luZyAldS8ldVxu
IiwKLQkJCQkgcGVyc2lzdGVudF9nbnQtPmdudCwgYmxraWYtPnBlcnNpc3RlbnRfZ250X2MsCi0J
CQkJIHhlbl9ibGtpZl9tYXhfcGdyYW50cyk7Ci0JCX0gZWxzZSB7Ci0JCQkvKgotCQkJICogV2Ug
YXJlIGVpdGhlciB1c2luZyBwZXJzaXN0ZW50IGdyYW50cyBhbmQKLQkJCSAqIGhpdCB0aGUgbWF4
aW11bSBsaW1pdCBvZiBncmFudHMgbWFwcGVkLAotCQkJICogb3Igd2UgYXJlIG5vdCB1c2luZyBw
ZXJzaXN0ZW50IGdyYW50cy4KLQkJCSAqLwotCQkJaWYgKHVzZV9wZXJzaXN0ZW50X2dudHMgJiYK
LQkJCQkhYmxraWYtPnZiZC5vdmVyZmxvd19tYXhfZ3JhbnRzKSB7Ci0JCQkJYmxraWYtPnZiZC5v
dmVyZmxvd19tYXhfZ3JhbnRzID0gMTsKLQkJCQlwcl9kZWJ1ZyhEUlZfUEZYICIgZG9tYWluICV1
LCBkZXZpY2UgJSN4IGlzIHVzaW5nIG1heGltdW0gbnVtYmVyIG9mIHBlcnNpc3RlbnQgZ3JhbnRz
XG4iLAotCQkJCQkgYmxraWYtPmRvbWlkLCBibGtpZi0+dmJkLmhhbmRsZSk7Ci0JCQl9Ci0JCQlu
ZXdfbWFwID0gdHJ1ZTsKLQkJCXBhZ2VzW2ldID0gYmxrYmstPnBlbmRpbmdfcGFnZShwZW5kaW5n
X3JlcSwgaSk7Ci0JCQlhZGRyID0gdmFkZHIocGVuZGluZ19yZXEsIGkpOwotCQkJcGFnZXNfdG9f
Z250W3NlZ3NfdG9fbWFwXSA9Ci0JCQkJYmxrYmstPnBlbmRpbmdfcGFnZShwZW5kaW5nX3JlcSwg
aSk7Ci0JCX0KLQotCQlpZiAocGVyc2lzdGVudF9nbnQpIHsKIAkJCXBhZ2VzW2ldID0gcGVyc2lz
dGVudF9nbnQtPnBhZ2U7CiAJCQlwZXJzaXN0ZW50X2dudHNbaV0gPSBwZXJzaXN0ZW50X2dudDsK
IAkJfSBlbHNlIHsKKwkJCWlmIChnZXRfZnJlZV9wYWdlKGJsa2lmLCAmcGFnZXNbaV0pKQorCQkJ
CWdvdG8gb3V0X29mX21lbW9yeTsKKwkJCWFkZHIgPSB2YWRkcihwYWdlc1tpXSk7CisJCQlwYWdl
c190b19nbnRbc2Vnc190b19tYXBdID0gcGFnZXNbaV07CiAJCQlwZXJzaXN0ZW50X2dudHNbaV0g
PSBOVUxMOwotCQl9Ci0KLQkJaWYgKG5ld19tYXApIHsKIAkJCWZsYWdzID0gR05UTUFQX2hvc3Rf
bWFwOwotCQkJaWYgKCFwZXJzaXN0ZW50X2dudCAmJgorCQkJaWYgKCF1c2VfcGVyc2lzdGVudF9n
bnRzICYmCiAJCQkgICAgKHBlbmRpbmdfcmVxLT5vcGVyYXRpb24gIT0gQkxLSUZfT1BfUkVBRCkp
CiAJCQkJZmxhZ3MgfD0gR05UTUFQX3JlYWRvbmx5OwogCQkJZ250dGFiX3NldF9tYXBfb3AoJm1h
cFtzZWdzX3RvX21hcCsrXSwgYWRkciwKQEAgLTcxNCw1NCArNzM2LDcxIEBAIHN0YXRpYyBpbnQg
eGVuX2Jsa2JrX21hcChzdHJ1Y3QgYmxraWZfcmVxdWVzdCAqcmVxLAogCSAqIHRoZSBwYWdlIGZy
b20gdGhlIG90aGVyIGRvbWFpbi4KIAkgKi8KIAlmb3IgKGkgPSAwLCBqID0gMDsgaSA8IG5zZWc7
IGkrKykgewotCQlpZiAoIXBlcnNpc3RlbnRfZ250c1tpXSB8fAotCQkgICAgcGVyc2lzdGVudF9n
bnRzW2ldLT5oYW5kbGUgPT0gQkxLQkFDS19JTlZBTElEX0hBTkRMRSkgeworCQlpZiAoIXBlcnNp
c3RlbnRfZ250c1tpXSkgewogCQkJLyogVGhpcyBpcyBhIG5ld2x5IG1hcHBlZCBncmFudCAqLwog
CQkJQlVHX09OKGogPj0gc2Vnc190b19tYXApOwogCQkJaWYgKHVubGlrZWx5KG1hcFtqXS5zdGF0
dXMgIT0gMCkpIHsKIAkJCQlwcl9kZWJ1ZyhEUlZfUEZYICJpbnZhbGlkIGJ1ZmZlciAtLSBjb3Vs
ZCBub3QgcmVtYXAgaXRcbiIpOwotCQkJCW1hcFtqXS5oYW5kbGUgPSBCTEtCQUNLX0lOVkFMSURf
SEFORExFOworCQkJCXBlbmRpbmdfaGFuZGxlKHBlbmRpbmdfcmVxLCBpKSA9CisJCQkJCUJMS0JB
Q0tfSU5WQUxJRF9IQU5ETEU7CiAJCQkJcmV0IHw9IDE7Ci0JCQkJaWYgKHBlcnNpc3RlbnRfZ250
c1tpXSkgewotCQkJCQlyYl9lcmFzZSgmcGVyc2lzdGVudF9nbnRzW2ldLT5ub2RlLAotCQkJCQkJ
ICZibGtpZi0+cGVyc2lzdGVudF9nbnRzKTsKLQkJCQkJYmxraWYtPnBlcnNpc3RlbnRfZ250X2Mt
LTsKLQkJCQkJa2ZyZWUocGVyc2lzdGVudF9nbnRzW2ldKTsKLQkJCQkJcGVyc2lzdGVudF9nbnRz
W2ldID0gTlVMTDsKLQkJCQl9CisJCQkJaisrOworCQkJCWNvbnRpbnVlOwogCQkJfQorCQkJcGVu
ZGluZ19oYW5kbGUocGVuZGluZ19yZXEsIGkpID0gbWFwW2pdLmhhbmRsZTsKIAkJfQotCQlpZiAo
cGVyc2lzdGVudF9nbnRzW2ldKSB7Ci0JCQlpZiAocGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGUg
PT0KLQkJCSAgICBCTEtCQUNLX0lOVkFMSURfSEFORExFKSB7CisJCWlmIChwZXJzaXN0ZW50X2du
dHNbaV0pCisJCQlnb3RvIG5leHQ7CisJCWlmICh1c2VfcGVyc2lzdGVudF9nbnRzICYmCisJCSAg
ICBibGtpZi0+cGVyc2lzdGVudF9nbnRfYyA8IHhlbl9ibGtpZl9tYXhfcGdyYW50cykgeworCQkJ
LyoKKwkJCSAqIFdlIGFyZSB1c2luZyBwZXJzaXN0ZW50IGdyYW50cywgdGhlIGdyYW50IGlzCisJ
CQkgKiBub3QgbWFwcGVkIGJ1dCB3ZSBoYXZlIHJvb20gZm9yIGl0CisJCQkgKi8KKwkJCXBlcnNp
c3RlbnRfZ250ID0ga21hbGxvYyhzaXplb2Yoc3RydWN0IHBlcnNpc3RlbnRfZ250KSwKKwkJCQkg
ICAgICAgICAgICAgICAgIEdGUF9LRVJORUwpOworCQkJaWYgKCFwZXJzaXN0ZW50X2dudCkgewog
CQkJCS8qCi0JCQkJICogSWYgdGhpcyBpcyBhIG5ldyBwZXJzaXN0ZW50IGdyYW50Ci0JCQkJICog
c2F2ZSB0aGUgaGFuZGxlcgorCQkJCSAqIElmIHdlIGRvbid0IGhhdmUgZW5vdWdoIG1lbW9yeSB0
bworCQkJCSAqIGFsbG9jYXRlIHRoZSBwZXJzaXN0ZW50X2dudCBzdHJ1Y3QKKwkJCQkgKiBtYXAg
dGhpcyBncmFudCBub24tcGVyc2lzdGVubHkKIAkJCQkgKi8KLQkJCQlwZXJzaXN0ZW50X2dudHNb
aV0tPmhhbmRsZSA9IG1hcFtqKytdLmhhbmRsZTsKLQkJCX0KLQkJCXBlbmRpbmdfaGFuZGxlKHBl
bmRpbmdfcmVxLCBpKSA9Ci0JCQkJcGVyc2lzdGVudF9nbnRzW2ldLT5oYW5kbGU7Ci0KLQkJCWlm
IChyZXQpCi0JCQkJY29udGludWU7Ci0KLQkJCXNlZ1tpXS5idWYgPSBwZm5fdG9fbWZuKHBhZ2Vf
dG9fcGZuKAotCQkJCXBlcnNpc3RlbnRfZ250c1tpXS0+cGFnZSkpIDw8IFBBR0VfU0hJRlQgfAot
CQkJCShyZXEtPnUucncuc2VnW2ldLmZpcnN0X3NlY3QgPDwgOSk7Ci0JCX0gZWxzZSB7Ci0JCQlw
ZW5kaW5nX2hhbmRsZShwZW5kaW5nX3JlcSwgaSkgPSBtYXBbal0uaGFuZGxlOwotCi0JCQlpZiAo
cmV0KSB7CiAJCQkJaisrOwotCQkJCWNvbnRpbnVlOworCQkJCWdvdG8gbmV4dDsKIAkJCX0KLQot
CQkJc2VnW2ldLmJ1ZiA9IG1hcFtqKytdLmRldl9idXNfYWRkciB8Ci0JCQkJKHJlcS0+dS5ydy5z
ZWdbaV0uZmlyc3Rfc2VjdCA8PCA5KTsKKwkJCXBlcnNpc3RlbnRfZ250LT5nbnQgPSBtYXBbal0u
cmVmOworCQkJcGVyc2lzdGVudF9nbnQtPmhhbmRsZSA9IG1hcFtqXS5oYW5kbGU7CisJCQlwZXJz
aXN0ZW50X2dudC0+ZmxhZ3MgPSBQRVJTSVNURU5UX0dOVF9BQ1RJVkU7CisJCQlwZXJzaXN0ZW50
X2dudC0+cGFnZSA9IHBhZ2VzW2ldOworCQkJaWYgKGFkZF9wZXJzaXN0ZW50X2dudCgmYmxraWYt
PnBlcnNpc3RlbnRfZ250cywKKwkJCSAgICAgICAgICAgICAgICAgICAgICAgcGVyc2lzdGVudF9n
bnQpKSB7CisJCQkJa2ZyZWUocGVyc2lzdGVudF9nbnQpOworCQkJCWdvdG8gbmV4dDsKKwkJCX0K
KwkJCWJsa2lmLT5wZXJzaXN0ZW50X2dudF9jKys7CisJCQlwZXJzaXN0ZW50X2dudHNbaV0gPSBw
ZXJzaXN0ZW50X2dudDsKKwkJCXByX2RlYnVnKERSVl9QRlggIiBncmFudCAldSBhZGRlZCB0byB0
aGUgdHJlZSBvZiBwZXJzaXN0ZW50IGdyYW50cywgdXNpbmcgJXUvJXVcbiIsCisJCQkJIHBlcnNp
c3RlbnRfZ250LT5nbnQsIGJsa2lmLT5wZXJzaXN0ZW50X2dudF9jLAorCQkJCSB4ZW5fYmxraWZf
bWF4X3BncmFudHMpOworCQkJaisrOworCQkJZ290byBuZXh0OworCQl9CisJCWlmICh1c2VfcGVy
c2lzdGVudF9nbnRzICYmICFibGtpZi0+dmJkLm92ZXJmbG93X21heF9ncmFudHMpIHsKKwkJCWJs
a2lmLT52YmQub3ZlcmZsb3dfbWF4X2dyYW50cyA9IDE7CisJCQlwcl9kZWJ1ZyhEUlZfUEZYICIg
ZG9tYWluICV1LCBkZXZpY2UgJSN4IGlzIHVzaW5nIG1heGltdW0gbnVtYmVyIG9mIHBlcnNpc3Rl
bnQgZ3JhbnRzXG4iLAorCQkJICAgICAgICAgYmxraWYtPmRvbWlkLCBibGtpZi0+dmJkLmhhbmRs
ZSk7CiAJCX0KKwkJaisrOworbmV4dDoKKwkJc2VnW2ldLmJ1ZiA9IHBmbl90b19tZm4ocGFnZV90
b19wZm4ocGFnZXNbaV0pKSA8PCBQQUdFX1NISUZUIHwKKwkJICAgICAgICAgICAgIChyZXEtPnUu
cncuc2VnW2ldLmZpcnN0X3NlY3QgPDwgOSk7CiAJfQogCXJldHVybiByZXQ7CisKK291dF9vZl9t
ZW1vcnk6CisJcHJfYWxlcnQoRFJWX1BGWCAiJXM6IG91dCBvZiBtZW1vcnlcbiIsIF9fZnVuY19f
KTsKKwlwdXRfZnJlZV9wYWdlcyhibGtpZiwgcGFnZXNfdG9fZ250LCBzZWdzX3RvX21hcCk7CisJ
cmV0dXJuIC1FTk9NRU07CiB9CiAKIHN0YXRpYyBpbnQgZGlzcGF0Y2hfZGlzY2FyZF9pbyhzdHJ1
Y3QgeGVuX2Jsa2lmICpibGtpZiwKQEAgLTk2Miw3ICsxMDAxLDcgQEAgc3RhdGljIGludCBkaXNw
YXRjaF9yd19ibG9ja19pbyhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZiwKIAlpbnQgb3BlcmF0aW9u
OwogCXN0cnVjdCBibGtfcGx1ZyBwbHVnOwogCWJvb2wgZHJhaW4gPSBmYWxzZTsKLQlzdHJ1Y3Qg
cGFnZSAqcGFnZXNbQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKwlzdHJ1Y3QgcGFn
ZSAqKnBhZ2VzID0gcGVuZGluZ19yZXEtPnBhZ2VzOwogCiAJc3dpdGNoIChyZXEtPm9wZXJhdGlv
bikgewogCWNhc2UgQkxLSUZfT1BfUkVBRDoKQEAgLTExOTMsMjIgKzEyMzIsMTQgQEAgc3RhdGlj
IGludCBfX2luaXQgeGVuX2Jsa2lmX2luaXQodm9pZCkKIAkJCQkJeGVuX2Jsa2lmX3JlcXMsIEdG
UF9LRVJORUwpOwogCWJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMgPSBrbWFsbG9jKHNpemVv
ZihibGtiay0+cGVuZGluZ19ncmFudF9oYW5kbGVzWzBdKSAqCiAJCQkJCW1tYXBfcGFnZXMsIEdG
UF9LRVJORUwpOwotCWJsa2JrLT5wZW5kaW5nX3BhZ2VzICAgICAgICAgPSBremFsbG9jKHNpemVv
ZihibGtiay0+cGVuZGluZ19wYWdlc1swXSkgKgotCQkJCQltbWFwX3BhZ2VzLCBHRlBfS0VSTkVM
KTsKIAotCWlmICghYmxrYmstPnBlbmRpbmdfcmVxcyB8fCAhYmxrYmstPnBlbmRpbmdfZ3JhbnRf
aGFuZGxlcyB8fAotCSAgICAhYmxrYmstPnBlbmRpbmdfcGFnZXMpIHsKKwlpZiAoIWJsa2JrLT5w
ZW5kaW5nX3JlcXMgfHwgIWJsa2JrLT5wZW5kaW5nX2dyYW50X2hhbmRsZXMpIHsKIAkJcmMgPSAt
RU5PTUVNOwogCQlnb3RvIG91dF9vZl9tZW1vcnk7CiAJfQogCiAJZm9yIChpID0gMDsgaSA8IG1t
YXBfcGFnZXM7IGkrKykgewogCQlibGtiay0+cGVuZGluZ19ncmFudF9oYW5kbGVzW2ldID0gQkxL
QkFDS19JTlZBTElEX0hBTkRMRTsKLQkJYmxrYmstPnBlbmRpbmdfcGFnZXNbaV0gPSBhbGxvY19w
YWdlKEdGUF9LRVJORUwpOwotCQlpZiAoYmxrYmstPnBlbmRpbmdfcGFnZXNbaV0gPT0gTlVMTCkg
ewotCQkJcmMgPSAtRU5PTUVNOwotCQkJZ290byBvdXRfb2ZfbWVtb3J5OwotCQl9CiAJfQogCXJj
ID0geGVuX2Jsa2lmX2ludGVyZmFjZV9pbml0KCk7CiAJaWYgKHJjKQpAQCAtMTIzMywxMyArMTI2
NCw2IEBAIHN0YXRpYyBpbnQgX19pbml0IHhlbl9ibGtpZl9pbml0KHZvaWQpCiAgZmFpbGVkX2lu
aXQ6CiAJa2ZyZWUoYmxrYmstPnBlbmRpbmdfcmVxcyk7CiAJa2ZyZWUoYmxrYmstPnBlbmRpbmdf
Z3JhbnRfaGFuZGxlcyk7Ci0JaWYgKGJsa2JrLT5wZW5kaW5nX3BhZ2VzKSB7Ci0JCWZvciAoaSA9
IDA7IGkgPCBtbWFwX3BhZ2VzOyBpKyspIHsKLQkJCWlmIChibGtiay0+cGVuZGluZ19wYWdlc1tp
XSkKLQkJCQlfX2ZyZWVfcGFnZShibGtiay0+cGVuZGluZ19wYWdlc1tpXSk7Ci0JCX0KLQkJa2Zy
ZWUoYmxrYmstPnBlbmRpbmdfcGFnZXMpOwotCX0KIAlrZnJlZShibGtiayk7CiAJYmxrYmsgPSBO
VUxMOwogCXJldHVybiByYzsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
Y29tbW9uLmggYi9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2NvbW1vbi5oCmluZGV4IGJkNDRk
NzUuLjYwNGJkMzAgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svY29tbW9u
LmgKKysrIGIvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay9jb21tb24uaApAQCAtMjA5LDYgKzIw
OSwxMSBAQCBzdHJ1Y3QgeGVuX2Jsa2lmIHsKIAl1bnNpZ25lZCBpbnQJCXBlcnNpc3RlbnRfZ250
X2M7CiAJdW5zaWduZWQgbG9uZwkJbmV4dF9scnU7CiAKKwkvKiBidWZmZXIgb2YgZnJlZSBwYWdl
cyB0byBtYXAgZ3JhbnQgcmVmcyAqLworCXNwaW5sb2NrX3QJCWZyZWVfcGFnZXNfbG9jazsKKwlp
bnQJCQlmcmVlX3BhZ2VzX251bTsKKwlzdHJ1Y3QgbGlzdF9oZWFkCWZyZWVfcGFnZXM7CisKIAkv
KiBzdGF0aXN0aWNzICovCiAJdW5zaWduZWQgbG9uZwkJc3RfcHJpbnQ7CiAJaW50CQkJc3RfcmRf
cmVxOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYyBiL2Ry
aXZlcnMvYmxvY2sveGVuLWJsa2JhY2sveGVuYnVzLmMKaW5kZXggYWJiMzk5YS4uZDc5MjZlYyAx
MDA2NDQKLS0tIGEvZHJpdmVycy9ibG9jay94ZW4tYmxrYmFjay94ZW5idXMuYworKysgYi9kcml2
ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL3hlbmJ1cy5jCkBAIC0xMTksNiArMTE5LDkgQEAgc3RhdGlj
IHN0cnVjdCB4ZW5fYmxraWYgKnhlbl9ibGtpZl9hbGxvYyhkb21pZF90IGRvbWlkKQogCWJsa2lm
LT5uZXh0X2xydSA9IGppZmZpZXM7CiAJaW5pdF93YWl0cXVldWVfaGVhZCgmYmxraWYtPndhaXRp
bmdfdG9fZnJlZSk7CiAJYmxraWYtPnBlcnNpc3RlbnRfZ250cy5yYl9ub2RlID0gTlVMTDsKKwlz
cGluX2xvY2tfaW5pdCgmYmxraWYtPmZyZWVfcGFnZXNfbG9jayk7CisJSU5JVF9MSVNUX0hFQUQo
JmJsa2lmLT5mcmVlX3BhZ2VzKTsKKwlibGtpZi0+ZnJlZV9wYWdlc19udW0gPSAwOwogCiAJcmV0
dXJuIGJsa2lmOwogfQotLSAKMS43LjcuNSAoQXBwbGUgR2l0LTI2KQoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:49:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB136-00086B-VU; Thu, 28 Feb 2013 10:49:16 +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 1UB135-000866-0q
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:49:15 +0000
Received: from [85.158.139.211:60248] by server-14.bemta-5.messagelabs.com id
	58/F8-13158-A263F215; Thu, 28 Feb 2013 10:49:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1362048553!15721876!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1950 invoked from network); 28 Feb 2013 10:49:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:49:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 10:49:13 +0000
Message-Id: <512F443702000078000C1DF7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 10:49:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> This series contains the initial implementation of indirect 
> descriptors for Linux blkback/blkfront.
> 
> Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.
> 
> Patch 6 contains a LRU implementation for blkback that will be needed 
> when using indirect descriptors (since we are no longer able to map 
> all possible grants blkfront might use).

Considering this, ...

> Patch 7 is an addition to the print stats function in blkback in order 
> to print information regarding persistent grant usage.
> 
> Patches 8, 9, 10 and 11 are preparatory work for indirect descriptors 
> implementation, mainly make blkback use dynamic memory and remove the 
> shared blkbk structure, so each blkback instance has it's own list of 
> free requests, pages, handles and so on.
> 
> Finally patch 12 contains the indirect descriptors implementation.
> 
> I've also pushed this series to the following git repository:
> 
> git://xenbits.xen.org/people/royger/linux.git xen-block-indirect
> 
> Performance benefit of this series can be seen in the following graph:
> 
> http://xenbits.xen.org/people/royger/plot_indirect.png 

... would you happen to also have a comparison with using
indirect descriptors but not persistent grants? IOW I'm
wondering about the hit rate on the persistently mapped
grants, especially when blkfront really saturates the added
bandwidth.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:49:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB136-00086B-VU; Thu, 28 Feb 2013 10:49:16 +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 1UB135-000866-0q
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:49:15 +0000
Received: from [85.158.139.211:60248] by server-14.bemta-5.messagelabs.com id
	58/F8-13158-A263F215; Thu, 28 Feb 2013 10:49:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1362048553!15721876!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1950 invoked from network); 28 Feb 2013 10:49:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:49:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 10:49:13 +0000
Message-Id: <512F443702000078000C1DF7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 10:49:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> This series contains the initial implementation of indirect 
> descriptors for Linux blkback/blkfront.
> 
> Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.
> 
> Patch 6 contains a LRU implementation for blkback that will be needed 
> when using indirect descriptors (since we are no longer able to map 
> all possible grants blkfront might use).

Considering this, ...

> Patch 7 is an addition to the print stats function in blkback in order 
> to print information regarding persistent grant usage.
> 
> Patches 8, 9, 10 and 11 are preparatory work for indirect descriptors 
> implementation, mainly make blkback use dynamic memory and remove the 
> shared blkbk structure, so each blkback instance has it's own list of 
> free requests, pages, handles and so on.
> 
> Finally patch 12 contains the indirect descriptors implementation.
> 
> I've also pushed this series to the following git repository:
> 
> git://xenbits.xen.org/people/royger/linux.git xen-block-indirect
> 
> Performance benefit of this series can be seen in the following graph:
> 
> http://xenbits.xen.org/people/royger/plot_indirect.png 

... would you happen to also have a comparison with using
indirect descriptors but not persistent grants? IOW I'm
wondering about the hit rate on the persistently mapped
grants, especially when blkfront really saturates the added
bandwidth.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:55:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:55: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 1UB19J-0008I5-Qd; Thu, 28 Feb 2013 10:55:41 +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 1UB19I-0008Hy-KU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:55:40 +0000
Received: from [85.158.138.51:61453] by server-6.bemta-3.messagelabs.com id
	17/6D-11048-BA73F215; Thu, 28 Feb 2013 10:55:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1362048932!23623943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21454 invoked from network); 28 Feb 2013 10:55:32 -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; 28 Feb 2013 10:55:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB199-0007Oj-Fj; Thu, 28 Feb 2013 10:55:31 +0000
Date: Thu, 28 Feb 2013 10:55:31 +0000
From: Tim Deegan <tim@xen.org>
To: Kai Luo <luokain@gmail.com>
Message-ID: <20130228105531.GB27704@ocelot.phlegethon.org>
References: <CAN71wUJfN3bj4avk0Ggc9myarow7G=vxyz5wQDwgrvsxO-cJQQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN71wUJfN3bj4avk0Ggc9myarow7G=vxyz5wQDwgrvsxO-cJQQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] A question about VM's access 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

At 09:35 +0800 on 27 Feb (1361957749), Kai Luo wrote:
> Hi:
>      For a HVM I kown the Xen Hypervisor  maintains a set of shadow
> pages,may be 2 levels or 4 levels.Under normal conditions ,without xen,a
> process wants to  access memory,the system will read CR3 to find the
> physical address of the page tables,then find the physical address of the
> next level,then the next,that will be multiple memory access(ignoring the
> TLB).My question is,when the system runs as a domain of xen, whether it is
> needed to triger a VM-EXIT when the system wants to find the physical
> address of next level of page table,if so when a guest want to access
> memory there will be VM-EXIT many times,if not how the system knows the
> address of next level of page tables ?

If the domain is using shadow pagetables, the MMU walks the _shadow_
pagetables, so it doesn't need to VMEXIT unless the virtual address is
not mapped in the shadow pagetables (or mapped with insufficient access
rights).

In that case it will VMEXIT once and the sh_page_fault() handler will
fix up the shadow pagetables by looking at the guest pagetables and the
p2m.  So there ought to be at most one VMEXIT. 

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 Feb 28 10:55:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:55: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 1UB19J-0008I5-Qd; Thu, 28 Feb 2013 10:55:41 +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 1UB19I-0008Hy-KU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:55:40 +0000
Received: from [85.158.138.51:61453] by server-6.bemta-3.messagelabs.com id
	17/6D-11048-BA73F215; Thu, 28 Feb 2013 10:55:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1362048932!23623943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21454 invoked from network); 28 Feb 2013 10:55:32 -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; 28 Feb 2013 10:55:32 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB199-0007Oj-Fj; Thu, 28 Feb 2013 10:55:31 +0000
Date: Thu, 28 Feb 2013 10:55:31 +0000
From: Tim Deegan <tim@xen.org>
To: Kai Luo <luokain@gmail.com>
Message-ID: <20130228105531.GB27704@ocelot.phlegethon.org>
References: <CAN71wUJfN3bj4avk0Ggc9myarow7G=vxyz5wQDwgrvsxO-cJQQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAN71wUJfN3bj4avk0Ggc9myarow7G=vxyz5wQDwgrvsxO-cJQQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] A question about VM's access 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

At 09:35 +0800 on 27 Feb (1361957749), Kai Luo wrote:
> Hi:
>      For a HVM I kown the Xen Hypervisor  maintains a set of shadow
> pages,may be 2 levels or 4 levels.Under normal conditions ,without xen,a
> process wants to  access memory,the system will read CR3 to find the
> physical address of the page tables,then find the physical address of the
> next level,then the next,that will be multiple memory access(ignoring the
> TLB).My question is,when the system runs as a domain of xen, whether it is
> needed to triger a VM-EXIT when the system wants to find the physical
> address of next level of page table,if so when a guest want to access
> memory there will be VM-EXIT many times,if not how the system knows the
> address of next level of page tables ?

If the domain is using shadow pagetables, the MMU walks the _shadow_
pagetables, so it doesn't need to VMEXIT unless the virtual address is
not mapped in the shadow pagetables (or mapped with insufficient access
rights).

In that case it will VMEXIT once and the sh_page_fault() handler will
fix up the shadow pagetables by looking at the guest pagetables and the
p2m.  So there ought to be at most one VMEXIT. 

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 Feb 28 10:56:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB19y-0008KU-8l; Thu, 28 Feb 2013 10:56:22 +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 1UB19w-0008KM-N5
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 10:56:21 +0000
Received: from [85.158.137.99:52432] by server-9.bemta-3.messagelabs.com id
	75/47-32531-3D73F215; Thu, 28 Feb 2013 10:56:19 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-217.messagelabs.com!1362048910!17687184!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13991 invoked from network); 28 Feb 2013 10:55:11 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:55:11 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id A5D48400754;
	Thu, 28 Feb 2013 11:55:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id OMJk3XN0IzHC; Thu, 28 Feb 2013 11:55:10 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 685324000C3;
	Thu, 28 Feb 2013 11:55:09 +0100 (CET)
Message-ID: <512F378A.9080003@tiscali.it>
Date: Thu, 28 Feb 2013 11:55:06 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Fabio Fantoni <fabio.fantoni@heliman.it>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
	<1360936015.31407.67.camel@zakaz.uk.xensource.com>
	<511F9E44.1020702@heliman.it>
In-Reply-To: <511F9E44.1020702@heliman.it>
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 v6] tools/libxl: Improve videoram setting
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="===============6892568697287798214=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============6892568697287798214==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090800090204070804000504"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090800090204070804000504
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 16/02/2013 15:57, Fabio Fantoni ha scritto:
> Il 15/02/2013 14:46, Ian Campbell ha scritto:
>> On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
>>> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
>>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>>
>>>> - If videoram setting is less than 8 mb shows error and exit.
>>>> - Added videoram setting for qemu upstream with cirrus (added in=20
>>>> qemu 1.3).
>>>> - Updated xl.cfg man.
>>>> - Default and minimal videoram changed to 16 mb if stdvga is set=20
>>>> and upstream
>>>>    qemu is being used. This is required by qemu 1.4 to avoid a xen=20
>>>> memory error
>>>>    (qemu 1.3 doesn't complain about it, probably buggy).
>>>>
>>>> Changes from v5:
>>>> - Default and minimal videoram changed to 16 mb if stdvga is set=20
>>>> and upstream
>>>>    qemu is being used.
>>>>
>>>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Applied, thanks.
>>

> This patch should be backported to xen 4.2.x for fix crash of qemu 1.4 =

> with stdvga (tested with debian experimental package)

Sorry for another mail about this, I see that 4.2.2 is near to be=20
released but this patch is not backported.


--------------ms090800090204070804000504
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyODEwNTUwNlowIwYJKoZIhvcNAQkEMRYEFHOH6xwQ45wZARX5M+eK1dXV
1KFfMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEATTXZ+ISp6btLrchJFZLc5G+E
orR5QBT+KaBDDT4qBaFfXrNsULN6VCHAZF6Mph6TLaIeLR4y7eJEk1qbCvVK2oO6eLhUvhoQ
gVUz7Q2MQtU7xuivPiz2eddiPd+7ip1qCW7tAnxMSmHFKUovBVt+9vMoLbnLxP8/TJtxyKRL
LdPuMdml6h0s5KnpMczpBUisvRdBWOuxlc50aMouQ18EwisZdJ/c/IjD3iu1ccFK+zZ133L8
LAo/fgPAE6/v8qYgI8EXxCtUQKyqoP3eeHmQIhzu8RkSOprYlhiIelwwh8a2jAp1iApW7e23
K2MNNRIbOQKDQ+uJwGTe06W5l7l0EAAAAAAAAA==
--------------ms090800090204070804000504--


--===============6892568697287798214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6892568697287798214==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 10:56:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10: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 1UB19y-0008KU-8l; Thu, 28 Feb 2013 10:56:22 +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 1UB19w-0008KM-N5
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 10:56:21 +0000
Received: from [85.158.137.99:52432] by server-9.bemta-3.messagelabs.com id
	75/47-32531-3D73F215; Thu, 28 Feb 2013 10:56:19 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-217.messagelabs.com!1362048910!17687184!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13991 invoked from network); 28 Feb 2013 10:55:11 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:55:11 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id A5D48400754;
	Thu, 28 Feb 2013 11:55:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id OMJk3XN0IzHC; Thu, 28 Feb 2013 11:55:10 +0100 (CET)
Received: from [192.168.178.50]
	(host231-79-dynamic.4-87-r.retail.telecomitalia.it [87.4.79.231])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 685324000C3;
	Thu, 28 Feb 2013 11:55:09 +0100 (CET)
Message-ID: <512F378A.9080003@tiscali.it>
Date: Thu, 28 Feb 2013 11:55:06 +0100
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Fabio Fantoni <fabio.fantoni@heliman.it>
References: <1360591652-6538-1-git-send-email-fantonifabio@tiscali.it>
	<alpine.DEB.2.02.1302151227170.8231@kaball.uk.xensource.com>
	<1360936015.31407.67.camel@zakaz.uk.xensource.com>
	<511F9E44.1020702@heliman.it>
In-Reply-To: <511F9E44.1020702@heliman.it>
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 v6] tools/libxl: Improve videoram setting
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="===============6892568697287798214=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============6892568697287798214==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090800090204070804000504"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090800090204070804000504
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 16/02/2013 15:57, Fabio Fantoni ha scritto:
> Il 15/02/2013 14:46, Ian Campbell ha scritto:
>> On Fri, 2013-02-15 at 12:27 +0000, Stefano Stabellini wrote:
>>> On Mon, 11 Feb 2013, fantonifabio@tiscali.it wrote:
>>>> From: Fabio Fantoni <fabio.fantoni@heliman.it>
>>>>
>>>> - If videoram setting is less than 8 mb shows error and exit.
>>>> - Added videoram setting for qemu upstream with cirrus (added in=20
>>>> qemu 1.3).
>>>> - Updated xl.cfg man.
>>>> - Default and minimal videoram changed to 16 mb if stdvga is set=20
>>>> and upstream
>>>>    qemu is being used. This is required by qemu 1.4 to avoid a xen=20
>>>> memory error
>>>>    (qemu 1.3 doesn't complain about it, probably buggy).
>>>>
>>>> Changes from v5:
>>>> - Default and minimal videoram changed to 16 mb if stdvga is set=20
>>>> and upstream
>>>>    qemu is being used.
>>>>
>>>> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
>>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Applied, thanks.
>>

> This patch should be backported to xen 4.2.x for fix crash of qemu 1.4 =

> with stdvga (tested with debian experimental package)

Sorry for another mail about this, I see that 4.2.2 is near to be=20
released but this patch is not backported.


--------------ms090800090204070804000504
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
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMDIyODEwNTUwNlowIwYJKoZIhvcNAQkEMRYEFHOH6xwQ45wZARX5M+eK1dXV
1KFfMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEATTXZ+ISp6btLrchJFZLc5G+E
orR5QBT+KaBDDT4qBaFfXrNsULN6VCHAZF6Mph6TLaIeLR4y7eJEk1qbCvVK2oO6eLhUvhoQ
gVUz7Q2MQtU7xuivPiz2eddiPd+7ip1qCW7tAnxMSmHFKUovBVt+9vMoLbnLxP8/TJtxyKRL
LdPuMdml6h0s5KnpMczpBUisvRdBWOuxlc50aMouQ18EwisZdJ/c/IjD3iu1ccFK+zZ133L8
LAo/fgPAE6/v8qYgI8EXxCtUQKyqoP3eeHmQIhzu8RkSOprYlhiIelwwh8a2jAp1iApW7e23
K2MNNRIbOQKDQ+uJwGTe06W5l7l0EAAAAAAAAA==
--------------ms090800090204070804000504--


--===============6892568697287798214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6892568697287798214==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 10:57:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:57: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 1UB1Ae-0008QG-NS; Thu, 28 Feb 2013 10:57: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 1UB1Ac-0008Pp-P1
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 10:57:03 +0000
Received: from [85.158.137.99:5520] by server-15.bemta-3.messagelabs.com id
	6A/62-23142-9F73F215; Thu, 28 Feb 2013 10:56:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1362048982!13422432!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10124 invoked from network); 28 Feb 2013 10:56:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:56:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2015061"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:56: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.297.1; Thu, 28 Feb 2013 10:56:21 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UB19x-0004td-M4;
	Thu, 28 Feb 2013 10:56:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UB19x-0000pv-AD;
	Thu, 28 Feb 2013 10:56:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16770-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 10:56:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16770: 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 16770 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16770/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 16766
 test-amd64-amd64-qemuu-win   15 guest-destroy      fail in 16766 pass in 16770

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   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-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 16766 never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:57:13 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:57: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 1UB1Ae-0008QG-NS; Thu, 28 Feb 2013 10:57: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 1UB1Ac-0008Pp-P1
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 10:57:03 +0000
Received: from [85.158.137.99:5520] by server-15.bemta-3.messagelabs.com id
	6A/62-23142-9F73F215; Thu, 28 Feb 2013 10:56:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1362048982!13422432!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10124 invoked from network); 28 Feb 2013 10:56:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 10:56:23 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="2015061"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 10:56: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.297.1; Thu, 28 Feb 2013 10:56:21 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UB19x-0004td-M4;
	Thu, 28 Feb 2013 10:56:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UB19x-0000pv-AD;
	Thu, 28 Feb 2013 10:56:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16770-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 10:56:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16770: 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 16770 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16770/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install      fail pass in 16766
 test-amd64-amd64-qemuu-win   15 guest-destroy      fail in 16766 pass in 16770

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   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-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 16766 never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:59:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:59: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 1UB1CQ-0000AN-8l; Thu, 28 Feb 2013 10:58:54 +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 1UB1CP-0000AD-4E
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:58:53 +0000
Received: from [85.158.137.99:9903] by server-14.bemta-3.messagelabs.com id
	C1/06-27076-C683F215; Thu, 28 Feb 2013 10:58:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1362049128!17687654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5929 invoked from network); 28 Feb 2013 10:58:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:58:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 10:58:48 +0000
Message-Id: <512F467602000078000C1E0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 10:58:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-2-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-2-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 01/12] xen-blkback: don't store
 dev_bus_addr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> dev_bus_addr returned in the grant ref map operation is the mfn of the
> passed page, there's no need to store it in the persistent grant
> entry, since we can always get it provided that we have the page.

Interesting that you come up with this, as I have a similar patch
pending (not posted yet), aiming at reducing the stack usage in
dispatch_rw_block_io(): seg[].buf is really unnecessary with the
dev_bus_addr storing removed, as the only reader of that field
can equally well use req->u.rw.seg[i].first_sect.

And then the biolist[] array really can be folded into a union
with the remaining seg[] one, as their usage scopes are easily
separable.

> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -621,9 +621,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				 * If this is a new persistent grant
>  				 * save the handler
>  				 */
> -				persistent_gnts[i]->handle = map[j].handle;
> -				persistent_gnts[i]->dev_bus_addr =
> -					map[j++].dev_bus_addr;
> +				persistent_gnts[i]->handle = map[j++].handle;
>  			}
>  			pending_handle(pending_req, i) =
>  				persistent_gnts[i]->handle;
> @@ -631,7 +629,8 @@ static int xen_blkbk_map(struct blkif_request *req,
>  			if (ret)
>  				continue;
>  
> -			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
> +			seg[i].buf = pfn_to_mfn(page_to_pfn(
> +				persistent_gnts[i]->page)) << PAGE_SHIFT |

So why do you do this? The only reader masks the field with
~PAGE_MASK anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:59:04 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:59: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 1UB1CQ-0000AN-8l; Thu, 28 Feb 2013 10:58:54 +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 1UB1CP-0000AD-4E
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:58:53 +0000
Received: from [85.158.137.99:9903] by server-14.bemta-3.messagelabs.com id
	C1/06-27076-C683F215; Thu, 28 Feb 2013 10:58:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1362049128!17687654!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5929 invoked from network); 28 Feb 2013 10:58:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 10:58:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 10:58:48 +0000
Message-Id: <512F467602000078000C1E0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 10:58:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-2-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-2-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 01/12] xen-blkback: don't store
 dev_bus_addr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> dev_bus_addr returned in the grant ref map operation is the mfn of the
> passed page, there's no need to store it in the persistent grant
> entry, since we can always get it provided that we have the page.

Interesting that you come up with this, as I have a similar patch
pending (not posted yet), aiming at reducing the stack usage in
dispatch_rw_block_io(): seg[].buf is really unnecessary with the
dev_bus_addr storing removed, as the only reader of that field
can equally well use req->u.rw.seg[i].first_sect.

And then the biolist[] array really can be folded into a union
with the remaining seg[] one, as their usage scopes are easily
separable.

> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -621,9 +621,7 @@ static int xen_blkbk_map(struct blkif_request *req,
>  				 * If this is a new persistent grant
>  				 * save the handler
>  				 */
> -				persistent_gnts[i]->handle = map[j].handle;
> -				persistent_gnts[i]->dev_bus_addr =
> -					map[j++].dev_bus_addr;
> +				persistent_gnts[i]->handle = map[j++].handle;
>  			}
>  			pending_handle(pending_req, i) =
>  				persistent_gnts[i]->handle;
> @@ -631,7 +629,8 @@ static int xen_blkbk_map(struct blkif_request *req,
>  			if (ret)
>  				continue;
>  
> -			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
> +			seg[i].buf = pfn_to_mfn(page_to_pfn(
> +				persistent_gnts[i]->page)) << PAGE_SHIFT |

So why do you do this? The only reader masks the field with
~PAGE_MASK anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 10:59:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:59: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 1UB1D7-0000G0-OL; Thu, 28 Feb 2013 10:59:37 +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 1UB1D6-0000Fg-Dc
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:59:36 +0000
Received: from [85.158.139.83:53157] by server-15.bemta-5.messagelabs.com id
	A7/06-22815-7983F215; Thu, 28 Feb 2013 10:59:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362049174!22220117!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16326 invoked from network); 28 Feb 2013 10:59:34 -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; 28 Feb 2013 10:59:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB1D4-0007PV-4z; Thu, 28 Feb 2013 10:59:34 +0000
Date: Thu, 28 Feb 2013 10:59:34 +0000
From: Tim Deegan <tim@xen.org>
To: Matthew Daley <mattjd@gmail.com>
Message-ID: <20130228105934.GC27704@ocelot.phlegethon.org>
References: <1362028564-8627-1-git-send-email-mattjd@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1362028564-8627-1-git-send-email-mattjd@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: fix invalid unlinking of nested p2m
	tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:16 +1300 on 28 Feb (1362075364), Matthew Daley wrote:
> Commit 90805dc (c/s 26387:4056e5a3d815) ("EPT: Make ept data stucture or
> operations neutral") makes nested p2m tables be unlinked from the host
> p2m table before their destruction (in p2m_teardown_nestedp2m).
> However, by this time the host p2m table has already been torn down,
> leading to a possible race condition where another allocation between
> the two kinds of table being torn down can lead to a linked list
> assertion with debug=y builds or memory corruption on debug=n ones.
> 
> Fix by swapping the order the two kinds of table are torn down in. While
> at it, remove the condition in p2m_final_teardown, as it is already
> checked identically in p2m_teardown_hostp2m itself.
> 
> Signed-off-by: Matthew Daley <mattjd@gmail.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 Thu Feb 28 10:59:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 10:59: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 1UB1D7-0000G0-OL; Thu, 28 Feb 2013 10:59:37 +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 1UB1D6-0000Fg-Dc
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 10:59:36 +0000
Received: from [85.158.139.83:53157] by server-15.bemta-5.messagelabs.com id
	A7/06-22815-7983F215; Thu, 28 Feb 2013 10:59:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362049174!22220117!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16326 invoked from network); 28 Feb 2013 10:59:34 -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; 28 Feb 2013 10:59:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB1D4-0007PV-4z; Thu, 28 Feb 2013 10:59:34 +0000
Date: Thu, 28 Feb 2013 10:59:34 +0000
From: Tim Deegan <tim@xen.org>
To: Matthew Daley <mattjd@gmail.com>
Message-ID: <20130228105934.GC27704@ocelot.phlegethon.org>
References: <1362028564-8627-1-git-send-email-mattjd@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1362028564-8627-1-git-send-email-mattjd@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: fix invalid unlinking of nested p2m
	tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:16 +1300 on 28 Feb (1362075364), Matthew Daley wrote:
> Commit 90805dc (c/s 26387:4056e5a3d815) ("EPT: Make ept data stucture or
> operations neutral") makes nested p2m tables be unlinked from the host
> p2m table before their destruction (in p2m_teardown_nestedp2m).
> However, by this time the host p2m table has already been torn down,
> leading to a possible race condition where another allocation between
> the two kinds of table being torn down can lead to a linked list
> assertion with debug=y builds or memory corruption on debug=n ones.
> 
> Fix by swapping the order the two kinds of table are torn down in. While
> at it, remove the condition in p2m_final_teardown, as it is already
> checked identically in p2m_teardown_hostp2m itself.
> 
> Signed-off-by: Matthew Daley <mattjd@gmail.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 Thu Feb 28 11:03:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:03: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 1UB1Gg-0000hF-98; Thu, 28 Feb 2013 11:03:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1Ge-0000h7-La
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:03:16 +0000
Received: from [85.158.138.51:15001] by server-3.bemta-3.messagelabs.com id
	43/4F-26934-3793F215; Thu, 28 Feb 2013 11:03:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362049383!27886200!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12860 invoked from network); 28 Feb 2013 11:03:05 -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;
	28 Feb 2013 11:03:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="9731197"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:02:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:02:37 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1G1-0007PU-79;
	Thu, 28 Feb 2013 11:02:37 +0000
Date: Thu, 28 Feb 2013 11:02:37 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20130228110237.GA23777@zion.uk.xensource.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
	<1361980154.2109.67.camel@zion.uk.xensource.com>
	<512EE8EF.30200@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512EE8EF.30200@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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, Feb 28, 2013 at 05:19:43AM +0000, ANNIE LI wrote:
> 
> 
> On 2013-2-27 23:49, Wei Liu wrote:
> > On Wed, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
> >> On 2013-2-26 20:35, Wei Liu wrote:
> >>> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> >>>> On 2013-2-16 0:00, Wei Liu wrote:
> >>>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> >>>>> ---
> >>>>>     drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
> >>>>>     1 file changed, 174 insertions(+), 72 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>>>> index 8bd75a1..de73a71 100644
> >>>>> --- a/drivers/net/xen-netfront.c
> >>>>> +++ b/drivers/net/xen-netfront.c
> >>>>> @@ -67,9 +67,19 @@ struct netfront_cb {
> >>>>>
> >>>>>     #define GRANT_INVALID_REF   0
> >>>>>
> >>>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> >>>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> >>>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> >>>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> >>>>> +#define XENNET_MAX_RING_PAGES      (1U<<    XENNET_MAX_RING_PAGE_ORDER)
> >>>>> +
> >>>>> +
> >>>>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
> >>>>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> >>>>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
> >>>>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> >>>>> +
> >>>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>>>> +
> >>>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> >>>> Not using multi-page ring here?
> >>>> In xennet_create_dev, gnttab_alloc_grant_references allocates
> >>>> TX_MAX_TARGET number of grant reference for tx. In
> >>>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> >>>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> >>>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> >>>> skb_entry_is_link helps to not release invalid grants, lots of null loop
> >>>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> >>>> variableconnected with np->tx_ring_pages. Or you intended to use one
> >>>> page ring here?
> >>>>
> >>> Looking back my history, this limitation was introduced because if we
> >>> have a multi-page backend and single page frontend, the backend skb
> >>> processing could overlap.
> >> I did not see the overlap you mentioned here in netback. Although
> >> netback supports multi-page, netback->vif still uses single page if the
> >> frontend only supports single page. Netfront and netback negotiate this
> >> through xenstore in your 5/8 patch. The requests and response should not
> >> have any overlap between netback and netfront. Am I missing something?
> >>
> > I tried to dig up mail archive just now and realized that the bug report
> > was in private mail exchange with Konrad.
> >
> > I don't really remember the details now since it is more than one year
> > old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
> > remember is that this bug was triggered by mixed old/new
> > frontend/backend.
> 
> I checked the code in Konrad's tree and am thinking this overlap issue 
> you mentioned existing in original netback(without multi-ring) and newer 
> netfront. Original netback does not support multi-ring, and your newer 
> netfront before this bug fix used "#define TX_MAX_TARGET 
> XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when 
> netfront allocating rx skbs.
> "#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the 
> netfront to single ring, it fixed the overlap issue, but not enough.
> 

Yes. I just saw a bug report from Xen-user list yesterday for the same
issue in original netback (1 page ring), so the overlap issue is not
introduced by multi-page ring implementation. If your team also sees that
issue, do you have patch to fix that?


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:03:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:03: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 1UB1Gg-0000hF-98; Thu, 28 Feb 2013 11:03:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1Ge-0000h7-La
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:03:16 +0000
Received: from [85.158.138.51:15001] by server-3.bemta-3.messagelabs.com id
	43/4F-26934-3793F215; Thu, 28 Feb 2013 11:03:15 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362049383!27886200!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12860 invoked from network); 28 Feb 2013 11:03:05 -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;
	28 Feb 2013 11:03:05 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; 
   d="scan'208";a="9731197"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:02:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:02:37 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1G1-0007PU-79;
	Thu, 28 Feb 2013 11:02:37 +0000
Date: Thu, 28 Feb 2013 11:02:37 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20130228110237.GA23777@zion.uk.xensource.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
	<1361980154.2109.67.camel@zion.uk.xensource.com>
	<512EE8EF.30200@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512EE8EF.30200@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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, Feb 28, 2013 at 05:19:43AM +0000, ANNIE LI wrote:
> 
> 
> On 2013-2-27 23:49, Wei Liu wrote:
> > On Wed, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
> >> On 2013-2-26 20:35, Wei Liu wrote:
> >>> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> >>>> On 2013-2-16 0:00, Wei Liu wrote:
> >>>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> >>>>> ---
> >>>>>     drivers/net/xen-netfront.c |  246 +++++++++++++++++++++++++++++++-------------
> >>>>>     1 file changed, 174 insertions(+), 72 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>>>> index 8bd75a1..de73a71 100644
> >>>>> --- a/drivers/net/xen-netfront.c
> >>>>> +++ b/drivers/net/xen-netfront.c
> >>>>> @@ -67,9 +67,19 @@ struct netfront_cb {
> >>>>>
> >>>>>     #define GRANT_INVALID_REF   0
> >>>>>
> >>>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> >>>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> >>>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> >>>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> >>>>> +#define XENNET_MAX_RING_PAGES      (1U<<    XENNET_MAX_RING_PAGE_ORDER)
> >>>>> +
> >>>>> +
> >>>>> +#define NET_TX_RING_SIZE(_nr_pages)                  \
> >>>>> +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> >>>>> +#define NET_RX_RING_SIZE(_nr_pages)                  \
> >>>>> +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> >>>>> +
> >>>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>>>> +
> >>>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> >>>> Not using multi-page ring here?
> >>>> In xennet_create_dev, gnttab_alloc_grant_references allocates
> >>>> TX_MAX_TARGET number of grant reference for tx. In
> >>>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> >>>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> >>>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> >>>> skb_entry_is_link helps to not release invalid grants, lots of null loop
> >>>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> >>>> variableconnected with np->tx_ring_pages. Or you intended to use one
> >>>> page ring here?
> >>>>
> >>> Looking back my history, this limitation was introduced because if we
> >>> have a multi-page backend and single page frontend, the backend skb
> >>> processing could overlap.
> >> I did not see the overlap you mentioned here in netback. Although
> >> netback supports multi-page, netback->vif still uses single page if the
> >> frontend only supports single page. Netfront and netback negotiate this
> >> through xenstore in your 5/8 patch. The requests and response should not
> >> have any overlap between netback and netfront. Am I missing something?
> >>
> > I tried to dig up mail archive just now and realized that the bug report
> > was in private mail exchange with Konrad.
> >
> > I don't really remember the details now since it is more than one year
> > old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
> > remember is that this bug was triggered by mixed old/new
> > frontend/backend.
> 
> I checked the code in Konrad's tree and am thinking this overlap issue 
> you mentioned existing in original netback(without multi-ring) and newer 
> netfront. Original netback does not support multi-ring, and your newer 
> netfront before this bug fix used "#define TX_MAX_TARGET 
> XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when 
> netfront allocating rx skbs.
> "#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the 
> netfront to single ring, it fixed the overlap issue, but not enough.
> 

Yes. I just saw a bug report from Xen-user list yesterday for the same
issue in original netback (1 page ring), so the overlap issue is not
introduced by multi-page ring implementation. If your team also sees that
issue, do you have patch to fix that?


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:06:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:06: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 1UB1Jf-0000vf-0D; Thu, 28 Feb 2013 11:06:23 +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 1UB1Jd-0000vI-3Y
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 11:06:21 +0000
Received: from [85.158.139.83:32848] by server-6.bemta-5.messagelabs.com id
	C7/9D-21466-C2A3F215; Thu, 28 Feb 2013 11:06:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1362049234!18143808!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9679 invoked from network); 28 Feb 2013 11:00:35 -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;
	28 Feb 2013 11:00:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; d="scan'208";a="10233489"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 10:59:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 05:59:29 -0500
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 1UB1Cz-0007MN-KD;
	Thu, 28 Feb 2013 10:59:29 +0000
Message-ID: <512F36BA.4070101@eu.citrix.com>
Date: Thu, 28 Feb 2013 10:51:38 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com>
In-Reply-To: <512F2615.3000007@canonical.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] 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-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 28/02/13 09:40, Stefan Bader wrote:
> On 27.02.2013 21:07, Ian Campbell wrote:
>> On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
>>> Bringing debian packaging upstream is (I believe) considered 'no bad
>>> thing'.
>> On the contrary, Debian discourages upstreams from including a debian/
>> directory in their releases.
>>
>> Ian.
>>
> I would agree with Ian here. I am sorry, I have not read anything of the
> previous discussion but if it is about having a simple way of getting a test
> package for deb (and rpm) based systems, the make target approach which is not
> using a debian directory sounds better. For testing you likely want just one
> package and that does not necessarily need any documentation. And if that was
> done in debian/ it would make the Debian maintainers job a pain because the
> whole packaging is based on the orig tarball not having that directory. (And
> FWIW Ubuntu derives from Debian, there are only changes if we really really have
> to).

Just to catch you up Stefan, the discussion isn't about having a simple 
way to get a test package.  We already have that target: "make deb" will 
create a .deb that when installed will have very similar effects to 
"make install" -- i.e., just copy a bunch of files into place.  The 
advantage of course being that the .deb keeps track of all the files 
which need to be *removed* as well, making it easier for developers.

What's being discussed is a more fully-featured .deb target.  The 
current output of "make deb" isn't really suitable for users -- it 
doesn't do anything with regard to setup, it doesn't test any 
dependencies, &c -- in other words, it doesn't do anything one normally 
expects from a mature package management system.

Generally speaking the Xen developers want to encourage users to use the 
packages available in their distro.  That's the best option for the 
majority of users.  However, there are "early-adopter" users who need to 
/ enjoy being on the bleeding edge -- meaning typically, on the very 
latest point release, as well as able and willing to test RCs before a 
release.  These users perform a very important role in the project, and 
so it is important (I think) to make it easy for them to download and 
install these versions.

Alex, what do you think about Ian's suggestion -- i.e., rather than 
integrate a full-featured .deb package into the Xen build system, 
intermittently use the Debian Xen target to create a set of .debs and 
make them available publicly somewhere?  If this was done once only for 
every new release, and then maybe once for each RC (or every other RC) 
before a release, it shouldn't be too much work I don't think.  I think 
we should probably be able to make space on the xen.org website 
somewhere to keep them.

Would that be useful for you, or do I misunderstand what it is you need?

(Also, I think that's what Ian was suggesting -- please correct me if 
I'm wrong, Ian!)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:06:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:06: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 1UB1Jf-0000vf-0D; Thu, 28 Feb 2013 11:06:23 +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 1UB1Jd-0000vI-3Y
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 11:06:21 +0000
Received: from [85.158.139.83:32848] by server-6.bemta-5.messagelabs.com id
	C7/9D-21466-C2A3F215; Thu, 28 Feb 2013 11:06:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1362049234!18143808!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9679 invoked from network); 28 Feb 2013 11:00:35 -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;
	28 Feb 2013 11:00:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; d="scan'208";a="10233489"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 10:59:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 05:59:29 -0500
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 1UB1Cz-0007MN-KD;
	Thu, 28 Feb 2013 10:59:29 +0000
Message-ID: <512F36BA.4070101@eu.citrix.com>
Date: Thu, 28 Feb 2013 10:51:38 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com>
In-Reply-To: <512F2615.3000007@canonical.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Fabio Fantoni <fabio.fantoni@heliman.it>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] 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-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 28/02/13 09:40, Stefan Bader wrote:
> On 27.02.2013 21:07, Ian Campbell wrote:
>> On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
>>> Bringing debian packaging upstream is (I believe) considered 'no bad
>>> thing'.
>> On the contrary, Debian discourages upstreams from including a debian/
>> directory in their releases.
>>
>> Ian.
>>
> I would agree with Ian here. I am sorry, I have not read anything of the
> previous discussion but if it is about having a simple way of getting a test
> package for deb (and rpm) based systems, the make target approach which is not
> using a debian directory sounds better. For testing you likely want just one
> package and that does not necessarily need any documentation. And if that was
> done in debian/ it would make the Debian maintainers job a pain because the
> whole packaging is based on the orig tarball not having that directory. (And
> FWIW Ubuntu derives from Debian, there are only changes if we really really have
> to).

Just to catch you up Stefan, the discussion isn't about having a simple 
way to get a test package.  We already have that target: "make deb" will 
create a .deb that when installed will have very similar effects to 
"make install" -- i.e., just copy a bunch of files into place.  The 
advantage of course being that the .deb keeps track of all the files 
which need to be *removed* as well, making it easier for developers.

What's being discussed is a more fully-featured .deb target.  The 
current output of "make deb" isn't really suitable for users -- it 
doesn't do anything with regard to setup, it doesn't test any 
dependencies, &c -- in other words, it doesn't do anything one normally 
expects from a mature package management system.

Generally speaking the Xen developers want to encourage users to use the 
packages available in their distro.  That's the best option for the 
majority of users.  However, there are "early-adopter" users who need to 
/ enjoy being on the bleeding edge -- meaning typically, on the very 
latest point release, as well as able and willing to test RCs before a 
release.  These users perform a very important role in the project, and 
so it is important (I think) to make it easy for them to download and 
install these versions.

Alex, what do you think about Ian's suggestion -- i.e., rather than 
integrate a full-featured .deb package into the Xen build system, 
intermittently use the Debian Xen target to create a set of .debs and 
make them available publicly somewhere?  If this was done once only for 
every new release, and then maybe once for each RC (or every other RC) 
before a release, it shouldn't be too much work I don't think.  I think 
we should probably be able to make space on the xen.org website 
somewhere to keep them.

Would that be useful for you, or do I misunderstand what it is you need?

(Also, I think that's what Ian was suggesting -- please correct me if 
I'm wrong, Ian!)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:09:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:09: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 1UB1Mf-00015y-K8; Thu, 28 Feb 2013 11:09:29 +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 1UB1Me-00015t-UF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:09:29 +0000
Received: from [85.158.137.99:38446] by server-2.bemta-3.messagelabs.com id
	27/17-05208-3EA3F215; Thu, 28 Feb 2013 11:09:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1362049732!12911067!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5885 invoked from network); 28 Feb 2013 11:08:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:08:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:08:52 +0000
Message-Id: <512F48D302000078000C1E33@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:08:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-11-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-11-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 10/12] xen-blkback: make the queue of
 free requests per backend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> @@ -122,6 +125,19 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	spin_lock_init(&blkif->free_pages_lock);
>  	INIT_LIST_HEAD(&blkif->free_pages);
>  	blkif->free_pages_num = 0;
> +	blkif->pending_reqs = kzalloc(sizeof(blkif->pending_reqs[0]) *
> +	                              xen_blkif_reqs, GFP_KERNEL);

kcalloc() is preferred in cases like this, I believe.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:09:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:09: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 1UB1Mf-00015y-K8; Thu, 28 Feb 2013 11:09:29 +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 1UB1Me-00015t-UF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:09:29 +0000
Received: from [85.158.137.99:38446] by server-2.bemta-3.messagelabs.com id
	27/17-05208-3EA3F215; Thu, 28 Feb 2013 11:09:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1362049732!12911067!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5885 invoked from network); 28 Feb 2013 11:08:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:08:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:08:52 +0000
Message-Id: <512F48D302000078000C1E33@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:08:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-11-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-11-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 10/12] xen-blkback: make the queue of
 free requests per backend
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> @@ -122,6 +125,19 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	spin_lock_init(&blkif->free_pages_lock);
>  	INIT_LIST_HEAD(&blkif->free_pages);
>  	blkif->free_pages_num = 0;
> +	blkif->pending_reqs = kzalloc(sizeof(blkif->pending_reqs[0]) *
> +	                              xen_blkif_reqs, GFP_KERNEL);

kcalloc() is preferred in cases like this, I believe.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:10:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:10: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 1UB1Nv-0001C4-53; Thu, 28 Feb 2013 11:10: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 1UB1Nu-0001Bx-97
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:10:46 +0000
Received: from [193.109.254.147:12788] by server-7.bemta-14.messagelabs.com id
	A5/B1-13581-53B3F215; Thu, 28 Feb 2013 11:10:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1362049647!9628581!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4077 invoked from network); 28 Feb 2013 11:07:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:07:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:07:27 +0000
Message-Id: <512F487D02000078000C1E30@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:07:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-10-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-10-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 09/12] xen-blkback: move pending handles
 list from blkbk to pending_req
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> Moving grant ref handles from blkbk to pending_req will allow us to
> get rid of the shared blkbk structure.

At the expense of (slightly?) higher memory requirements?

> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -136,6 +136,7 @@ struct pending_req {
>  	struct list_head	free_list;
>  	struct persistent_gnt	*persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  	struct page		*pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	grant_handle_t		grant_handles[BLKIF_MAX_SEGMENTS_PER_REQUEST];

Adding yet another array here makes it even more desirable to
switch from multiple arrays to a singly array of a structure, thus
improving locality of the memory accesses involved in processing
an individual segment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:10:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:10: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 1UB1Nv-0001C4-53; Thu, 28 Feb 2013 11:10: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 1UB1Nu-0001Bx-97
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:10:46 +0000
Received: from [193.109.254.147:12788] by server-7.bemta-14.messagelabs.com id
	A5/B1-13581-53B3F215; Thu, 28 Feb 2013 11:10:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1362049647!9628581!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4077 invoked from network); 28 Feb 2013 11:07:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:07:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:07:27 +0000
Message-Id: <512F487D02000078000C1E30@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:07:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-10-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-10-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 09/12] xen-blkback: move pending handles
 list from blkbk to pending_req
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> Moving grant ref handles from blkbk to pending_req will allow us to
> get rid of the shared blkbk structure.

At the expense of (slightly?) higher memory requirements?

> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -136,6 +136,7 @@ struct pending_req {
>  	struct list_head	free_list;
>  	struct persistent_gnt	*persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  	struct page		*pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	grant_handle_t		grant_handles[BLKIF_MAX_SEGMENTS_PER_REQUEST];

Adding yet another array here makes it even more desirable to
switch from multiple arrays to a singly array of a structure, thus
improving locality of the memory accesses involved in processing
an individual segment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:11:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1Os-0001Io-KE; Thu, 28 Feb 2013 11:11:46 +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 1UB1Or-0001IU-5N
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:11:45 +0000
Received: from [193.109.254.147:21564] by server-5.bemta-14.messagelabs.com id
	C2/97-21539-07B3F215; Thu, 28 Feb 2013 11:11:44 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1362049902!10001585!1
X-Originating-IP: [209.85.210.182]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 28 Feb 2013 11:11:43 -0000
Received: from mail-ia0-f182.google.com (HELO mail-ia0-f182.google.com)
	(209.85.210.182)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:11:43 -0000
Received: by mail-ia0-f182.google.com with SMTP id k38so1383910iah.41
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 03:11:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=MdWiW79BzrhPk9c71Byyzcn+plRd5Hw/q5itsj0KqgE=;
	b=Z0aYC7K3TocFWxrq6nGzM0sWmIw32YN4IgWQmToLQ7Z7+krvoqhbhcvpynG9XWfcQJ
	ix5jPfqOem8dsMhx+pZqOb4fDy5cyTzLoB3be1KrBm8NuE9ErD8WIKaQ2U9gbL87O1GR
	vKaqq5kKmn7ZLPz3OfT+mIu7BJxMpsE2kj5ADqt3SUCVknduB6goVuWsNB1RBVQ7rYPc
	RN5ojMIvjgYvh3+SDWA65myU25uq6lbzgLzZ+6RUO5iNZG4OBdWCA7ipkzOtMOp+B/cY
	Q4bR2ugNP+GNOhB+ZkDrM6qI8TTIinJ1vmCqmMrRl5A/zfw6bMfBnhXvvI549HKFZOyB
	Ua6A==
MIME-Version: 1.0
X-Received: by 10.50.40.162 with SMTP id y2mr3323710igk.65.1362049901948; Thu,
	28 Feb 2013 03:11:41 -0800 (PST)
Received: by 10.64.39.194 with HTTP; Thu, 28 Feb 2013 03:11:41 -0800 (PST)
In-Reply-To: <512DE91A02000078000C1667@nat28.tlf.novell.com>
References: <04071eb1f2d29de3497f.1361958220@nehalem1>
	<512DE91A02000078000C1667@nat28.tlf.novell.com>
Date: Thu, 28 Feb 2013 11:11:41 +0000
X-Google-Sender-Auth: kgVw2X-WQDZxOx6ITj-dUgcaxPo
Message-ID: <CAFLBxZY=uz=8XN0=2MQv1D5ahZ+3+qzM8Squv03QXdNrdux4UA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] (V2) Avoid stale pointer when moving domain
 to another cpupool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8823904864835057792=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8823904864835057792==
Content-Type: multipart/alternative; boundary=14dae93412839276c404d6c6f47e

--14dae93412839276c404d6c6f47e
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 27, 2013 at 10:08 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 27.02.13 at 10:43, Juergen Gross <juergen.gross@ts.fujitsu.com>
> wrote:
> > When a domain is moved to another cpupool the scheduler private data
> pointers
> > in vcpu and domain structures must never point to an already freed memory
> > area.
> >
> > While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.
> >
> > Changes since V1:
> > - don't use an an own loop for freeing vcpu_data
> > - free old domain data after unpausing the domain
> > - simplify sched_init_vcpu (DOM2OP instead VCPU2OP)
> >
> > Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>
> Looks good to me now, but will want to be ack-ed by George.
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks Juergen.

 -George

--14dae93412839276c404d6c6f47e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Feb 27, 2013 at 10:08 AM, Jan Beulich <span dir=3D=
"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@s=
use.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<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">&gt;&gt;&gt; On 27.02.13 a=
t 10:43, Juergen Gross &lt;<a href=3D"mailto:juergen.gross@ts.fujitsu.com">=
juergen.gross@ts.fujitsu.com</a>&gt; wrote:<br>

&gt; When a domain is moved to another cpupool the scheduler private data p=
ointers<br>
&gt; in vcpu and domain structures must never point to an already freed mem=
ory<br>
&gt; area.<br>
&gt;<br>
&gt; While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2O=
P.<br>
&gt;<br>
&gt; Changes since V1:<br>
&gt; - don&#39;t use an an own loop for freeing vcpu_data<br>
&gt; - free old domain data after unpausing the domain<br>
&gt; - simplify sched_init_vcpu (DOM2OP instead VCPU2OP)<br>
&gt;<br>
&gt; Signed-off-by: Juergen Gross &lt;<a href=3D"mailto:juergen.gross@ts.fu=
jitsu.com">juergen.gross@ts.fujitsu.com</a>&gt;<br>
<br>
</div>Looks good to me now, but will want to be ack-ed by George.<br></bloc=
kquote><div><br></div><div>Acked-by: George Dunlap &lt;<a href=3D"mailto:ge=
orge.dunlap@eu.citrix.com">george.dunlap@eu.citrix.com</a>&gt;<br><br></div=
>
<div>Thanks Juergen.<br><br></div><div>=A0-George<br></div><div>=A0<br></di=
v></div><br></div></div>

--14dae93412839276c404d6c6f47e--


--===============8823904864835057792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8823904864835057792==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 11:11:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1Os-0001Io-KE; Thu, 28 Feb 2013 11:11:46 +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 1UB1Or-0001IU-5N
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:11:45 +0000
Received: from [193.109.254.147:21564] by server-5.bemta-14.messagelabs.com id
	C2/97-21539-07B3F215; Thu, 28 Feb 2013 11:11:44 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1362049902!10001585!1
X-Originating-IP: [209.85.210.182]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31272 invoked from network); 28 Feb 2013 11:11:43 -0000
Received: from mail-ia0-f182.google.com (HELO mail-ia0-f182.google.com)
	(209.85.210.182)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:11:43 -0000
Received: by mail-ia0-f182.google.com with SMTP id k38so1383910iah.41
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 03:11:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=MdWiW79BzrhPk9c71Byyzcn+plRd5Hw/q5itsj0KqgE=;
	b=Z0aYC7K3TocFWxrq6nGzM0sWmIw32YN4IgWQmToLQ7Z7+krvoqhbhcvpynG9XWfcQJ
	ix5jPfqOem8dsMhx+pZqOb4fDy5cyTzLoB3be1KrBm8NuE9ErD8WIKaQ2U9gbL87O1GR
	vKaqq5kKmn7ZLPz3OfT+mIu7BJxMpsE2kj5ADqt3SUCVknduB6goVuWsNB1RBVQ7rYPc
	RN5ojMIvjgYvh3+SDWA65myU25uq6lbzgLzZ+6RUO5iNZG4OBdWCA7ipkzOtMOp+B/cY
	Q4bR2ugNP+GNOhB+ZkDrM6qI8TTIinJ1vmCqmMrRl5A/zfw6bMfBnhXvvI549HKFZOyB
	Ua6A==
MIME-Version: 1.0
X-Received: by 10.50.40.162 with SMTP id y2mr3323710igk.65.1362049901948; Thu,
	28 Feb 2013 03:11:41 -0800 (PST)
Received: by 10.64.39.194 with HTTP; Thu, 28 Feb 2013 03:11:41 -0800 (PST)
In-Reply-To: <512DE91A02000078000C1667@nat28.tlf.novell.com>
References: <04071eb1f2d29de3497f.1361958220@nehalem1>
	<512DE91A02000078000C1667@nat28.tlf.novell.com>
Date: Thu, 28 Feb 2013 11:11:41 +0000
X-Google-Sender-Auth: kgVw2X-WQDZxOx6ITj-dUgcaxPo
Message-ID: <CAFLBxZY=uz=8XN0=2MQv1D5ahZ+3+qzM8Squv03QXdNrdux4UA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] (V2) Avoid stale pointer when moving domain
 to another cpupool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============8823904864835057792=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8823904864835057792==
Content-Type: multipart/alternative; boundary=14dae93412839276c404d6c6f47e

--14dae93412839276c404d6c6f47e
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 27, 2013 at 10:08 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 27.02.13 at 10:43, Juergen Gross <juergen.gross@ts.fujitsu.com>
> wrote:
> > When a domain is moved to another cpupool the scheduler private data
> pointers
> > in vcpu and domain structures must never point to an already freed memory
> > area.
> >
> > While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP.
> >
> > Changes since V1:
> > - don't use an an own loop for freeing vcpu_data
> > - free old domain data after unpausing the domain
> > - simplify sched_init_vcpu (DOM2OP instead VCPU2OP)
> >
> > Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>
> Looks good to me now, but will want to be ack-ed by George.
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks Juergen.

 -George

--14dae93412839276c404d6c6f47e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Feb 27, 2013 at 10:08 AM, Jan Beulich <span dir=3D=
"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@s=
use.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<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">&gt;&gt;&gt; On 27.02.13 a=
t 10:43, Juergen Gross &lt;<a href=3D"mailto:juergen.gross@ts.fujitsu.com">=
juergen.gross@ts.fujitsu.com</a>&gt; wrote:<br>

&gt; When a domain is moved to another cpupool the scheduler private data p=
ointers<br>
&gt; in vcpu and domain structures must never point to an already freed mem=
ory<br>
&gt; area.<br>
&gt;<br>
&gt; While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2O=
P.<br>
&gt;<br>
&gt; Changes since V1:<br>
&gt; - don&#39;t use an an own loop for freeing vcpu_data<br>
&gt; - free old domain data after unpausing the domain<br>
&gt; - simplify sched_init_vcpu (DOM2OP instead VCPU2OP)<br>
&gt;<br>
&gt; Signed-off-by: Juergen Gross &lt;<a href=3D"mailto:juergen.gross@ts.fu=
jitsu.com">juergen.gross@ts.fujitsu.com</a>&gt;<br>
<br>
</div>Looks good to me now, but will want to be ack-ed by George.<br></bloc=
kquote><div><br></div><div>Acked-by: George Dunlap &lt;<a href=3D"mailto:ge=
orge.dunlap@eu.citrix.com">george.dunlap@eu.citrix.com</a>&gt;<br><br></div=
>
<div>Thanks Juergen.<br><br></div><div>=A0-George<br></div><div>=A0<br></di=
v></div><br></div></div>

--14dae93412839276c404d6c6f47e--


--===============8823904864835057792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8823904864835057792==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 11:17:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1Ug-0001eq-Ej; Thu, 28 Feb 2013 11:17:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1Ue-0001ei-73
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:17:44 +0000
Received: from [85.158.138.51:64325] by server-8.bemta-3.messagelabs.com id
	C4/D2-20604-7DC3F215; Thu, 28 Feb 2013 11:17:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1362050259!29704902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25111 invoked from network); 28 Feb 2013 11:17:40 -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;
	28 Feb 2013 11:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; d="scan'208";a="10237032"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:17:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:17:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1UY-0007cx-Dk;
	Thu, 28 Feb 2013 11:17:38 +0000
Date: Thu, 28 Feb 2013 11:17:38 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228111738.GA24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
	<1361984642.26546.400.camel@zakaz.uk.xensource.com>
	<512F1B4202000078000C1CA0@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F1B4202000078000C1CA0@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
	event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 07:54:26AM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 18:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
> >> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > --- a/xen/include/asm-arm/types.h
> >> > +++ b/xen/include/asm-arm/types.h
> >> > @@ -41,10 +41,13 @@ typedef char bool_t;
> >> >  #define test_and_clear_bool(b) xchg(&(b), 0)
> >> >  
> >> >  #endif /* __ASSEMBLY__ */
> >> > +#define BYTE_BITORDER  3
> >> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
> >> >  
> >> > -#define BITS_PER_LONG 32
> >> > -#define BYTES_PER_LONG 4
> >> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
> >> >  #define LONG_BYTEORDER 2
> >> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> >> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> >> 
> >> Is that all really correct and complete in the context of arm64 and
> >> an ABI-long not being 32 bits on arm32?
> > 
> > This header is about the internal types, I think, and so should
> > represent the compiler's idea of what the actual long type is for the
> > benefit of common code.
> > 
> > Of course if these are also being used for ABI things, this is a bug on
> > ARM.
> 
> Wei - could you please clarify/double check? I was under the
> impression that these were used e.g. for thing like the event
> channel bit maps and selector words, and those are clearly
> xen_ulong_t, not unsigned long.
> 

Yes, this one needs to be fixed. The whole series was built on top of
Ian's xen_ulong_t patch, but I missed this one. :-(

Also I need to pick up his latest patch.


Wei.

> Thanks, Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:17:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1Ug-0001eq-Ej; Thu, 28 Feb 2013 11:17:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1Ue-0001ei-73
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:17:44 +0000
Received: from [85.158.138.51:64325] by server-8.bemta-3.messagelabs.com id
	C4/D2-20604-7DC3F215; Thu, 28 Feb 2013 11:17:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1362050259!29704902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25111 invoked from network); 28 Feb 2013 11:17:40 -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;
	28 Feb 2013 11:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.84,754,1355097600"; d="scan'208";a="10237032"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:17:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:17:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1UY-0007cx-Dk;
	Thu, 28 Feb 2013 11:17:38 +0000
Date: Thu, 28 Feb 2013 11:17:38 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228111738.GA24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-17-git-send-email-wei.liu2@citrix.com>
	<512E482802000078000C1A98@nat28.tlf.novell.com>
	<1361984642.26546.400.camel@zakaz.uk.xensource.com>
	<512F1B4202000078000C1CA0@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F1B4202000078000C1CA0@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 16/22] Introduce some macros for
	event channels
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 07:54:26AM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 18:04, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2013-02-27 at 16:53 +0000, Jan Beulich wrote:
> >> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > --- a/xen/include/asm-arm/types.h
> >> > +++ b/xen/include/asm-arm/types.h
> >> > @@ -41,10 +41,13 @@ typedef char bool_t;
> >> >  #define test_and_clear_bool(b) xchg(&(b), 0)
> >> >  
> >> >  #endif /* __ASSEMBLY__ */
> >> > +#define BYTE_BITORDER  3
> >> > +#define BITS_PER_BYTE  (1 << BYTE_BITORDER)
> >> >  
> >> > -#define BITS_PER_LONG 32
> >> > -#define BYTES_PER_LONG 4
> >> > +#define BITS_PER_LONG  (1 << LONG_BITORDER)
> >> >  #define LONG_BYTEORDER 2
> >> > +#define LONG_BITORDER  (LONG_BYTEORDER + BYTE_BITORDER)
> >> > +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> >> 
> >> Is that all really correct and complete in the context of arm64 and
> >> an ABI-long not being 32 bits on arm32?
> > 
> > This header is about the internal types, I think, and so should
> > represent the compiler's idea of what the actual long type is for the
> > benefit of common code.
> > 
> > Of course if these are also being used for ABI things, this is a bug on
> > ARM.
> 
> Wei - could you please clarify/double check? I was under the
> impression that these were used e.g. for thing like the event
> channel bit maps and selector words, and those are clearly
> xen_ulong_t, not unsigned long.
> 

Yes, this one needs to be fixed. The whole series was built on top of
Ian's xen_ulong_t patch, but I missed this one. :-(

Also I need to pick up his latest patch.


Wei.

> Thanks, Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:19:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1WC-0001jy-UW; Thu, 28 Feb 2013 11:19: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 1UB1WB-0001jp-B6
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:19:19 +0000
Received: from [85.158.143.99:14096] by server-2.bemta-4.messagelabs.com id
	42/62-12656-63D3F215; Thu, 28 Feb 2013 11:19:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1362050357!19211676!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18424 invoked from network); 28 Feb 2013 11:19:18 -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; 28 Feb 2013 11:19:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:19:17 +0000
Message-Id: <512F4B4402000078000C1E5B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:19:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-13-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-13-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
 descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t;
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> +#define BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST 8
> +
> +struct blkif_request_segment_aligned {
> +	grant_ref_t gref;        /* reference to I/O buffer frame        */
> +	/* @first_sect: first sector in frame to transfer (inclusive).   */
> +	/* @last_sect: last sector in frame to transfer (inclusive).     */
> +	uint8_t     first_sect, last_sect;
> +	uint16_t    _pad; /* padding to make it 8 bytes, so it's cache-aligned */
> +} __attribute__((__packed__));

What's the __packed__ for here?

> +
>  struct blkif_request_rw {
>  	uint8_t        nr_segments;  /* number of segments                   */
>  	blkif_vdev_t   handle;       /* only for read/write requests         */
> @@ -138,11 +150,24 @@ struct blkif_request_discard {
>  	uint8_t        _pad3;
>  } __attribute__((__packed__));
>  
> +struct blkif_request_indirect {
> +	uint8_t        indirect_op;
> +	uint16_t       nr_segments;
> +#ifdef CONFIG_X86_64
> +	uint32_t       _pad1;        /* offsetof(blkif_...,u.indirect.id) == 8 */
> +#endif

Either you want the structure be packed tightly (and you don't care
about misaligned fields), in which case you shouldn't need a padding
field. That's even more so as there's no padding between indirect_op
and nr_segments, so everything is misaligned anyway, and the
comment above is wrong too (offsetof() really ought to yield 7 in
that case).

Or you want the structure fields aligned, in which case you again
ought to drop the use of the __packed__ attribute and introduce
_all_ necessary padding fields.

> +	uint64_t       id;
> +	blkif_vdev_t   handle;
> +	blkif_sector_t sector_number;
> +	grant_ref_t    indirect_grefs[BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST];
> +} __attribute__((__packed__));

And then it would be quite nice for new features to no longer
require translation between a 32- and a 64-bit layout at all.

Plus, rather than introducing uninitialized padding fields, I'd
suggest using fields that are required to be zero initialized, to
allow giving them a meaning later.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:19:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1WC-0001jy-UW; Thu, 28 Feb 2013 11:19: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 1UB1WB-0001jp-B6
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:19:19 +0000
Received: from [85.158.143.99:14096] by server-2.bemta-4.messagelabs.com id
	42/62-12656-63D3F215; Thu, 28 Feb 2013 11:19:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1362050357!19211676!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18424 invoked from network); 28 Feb 2013 11:19:18 -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; 28 Feb 2013 11:19:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:19:17 +0000
Message-Id: <512F4B4402000078000C1E5B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:19:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-13-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1362047335-26402-13-git-send-email-roger.pau@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
 descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
> @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t;
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> +#define BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST 8
> +
> +struct blkif_request_segment_aligned {
> +	grant_ref_t gref;        /* reference to I/O buffer frame        */
> +	/* @first_sect: first sector in frame to transfer (inclusive).   */
> +	/* @last_sect: last sector in frame to transfer (inclusive).     */
> +	uint8_t     first_sect, last_sect;
> +	uint16_t    _pad; /* padding to make it 8 bytes, so it's cache-aligned */
> +} __attribute__((__packed__));

What's the __packed__ for here?

> +
>  struct blkif_request_rw {
>  	uint8_t        nr_segments;  /* number of segments                   */
>  	blkif_vdev_t   handle;       /* only for read/write requests         */
> @@ -138,11 +150,24 @@ struct blkif_request_discard {
>  	uint8_t        _pad3;
>  } __attribute__((__packed__));
>  
> +struct blkif_request_indirect {
> +	uint8_t        indirect_op;
> +	uint16_t       nr_segments;
> +#ifdef CONFIG_X86_64
> +	uint32_t       _pad1;        /* offsetof(blkif_...,u.indirect.id) == 8 */
> +#endif

Either you want the structure be packed tightly (and you don't care
about misaligned fields), in which case you shouldn't need a padding
field. That's even more so as there's no padding between indirect_op
and nr_segments, so everything is misaligned anyway, and the
comment above is wrong too (offsetof() really ought to yield 7 in
that case).

Or you want the structure fields aligned, in which case you again
ought to drop the use of the __packed__ attribute and introduce
_all_ necessary padding fields.

> +	uint64_t       id;
> +	blkif_vdev_t   handle;
> +	blkif_sector_t sector_number;
> +	grant_ref_t    indirect_grefs[BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST];
> +} __attribute__((__packed__));

And then it would be quite nice for new features to no longer
require translation between a 32- and a 64-bit layout at all.

Plus, rather than introducing uninitialized padding fields, I'd
suggest using fields that are required to be zero initialized, to
allow giving them a meaning later.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:21:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1Xg-0001sQ-LM; Thu, 28 Feb 2013 11:20:52 +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 1UB1Xe-0001sA-OT
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:20:50 +0000
Received: from [85.158.138.51:36027] by server-13.bemta-3.messagelabs.com id
	0D/EF-25744-D8D3F215; Thu, 28 Feb 2013 11:20:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1362050442!28252149!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8501 invoked from network); 28 Feb 2013 11:20:44 -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;
	28 Feb 2013 11:20:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9734600"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:20:42 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:20:41 -0500
Message-ID: <512F3D88.8060100@citrix.com>
Date: Thu, 28 Feb 2013 11:20:40 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 04/22] flask: include xen/event.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 27/02/13 14:33, Wei Liu wrote:
> Some definitions for event channel have been moved to new header file.

This suggests the previous patch broke the build.  Fold 3 and 4 together
or you will break bisection.

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/xsm/flask/hooks.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 29a78dd..6d446ab 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -11,6 +11,7 @@
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/sched.h>
> +#include <xen/event.h>
>  #include <xen/paging.h>
>  #include <xen/xmalloc.h>
>  #include <xsm/xsm.h>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:21:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1Xg-0001sQ-LM; Thu, 28 Feb 2013 11:20:52 +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 1UB1Xe-0001sA-OT
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:20:50 +0000
Received: from [85.158.138.51:36027] by server-13.bemta-3.messagelabs.com id
	0D/EF-25744-D8D3F215; Thu, 28 Feb 2013 11:20:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1362050442!28252149!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8501 invoked from network); 28 Feb 2013 11:20:44 -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;
	28 Feb 2013 11:20:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9734600"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:20:42 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:20:41 -0500
Message-ID: <512F3D88.8060100@citrix.com>
Date: Thu, 28 Feb 2013 11:20:40 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 04/22] flask: include xen/event.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 27/02/13 14:33, Wei Liu wrote:
> Some definitions for event channel have been moved to new header file.

This suggests the previous patch broke the build.  Fold 3 and 4 together
or you will break bisection.

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/xsm/flask/hooks.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 29a78dd..6d446ab 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -11,6 +11,7 @@
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/sched.h>
> +#include <xen/event.h>
>  #include <xen/paging.h>
>  #include <xen/xmalloc.h>
>  #include <xsm/xsm.h>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:21:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:21: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 1UB1Xk-0001sy-1G; Thu, 28 Feb 2013 11:20:56 +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 1UB1Xi-0001sh-QE
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:20:55 +0000
Received: from [85.158.139.211:31364] by server-2.bemta-5.messagelabs.com id
	A1/C5-23989-69D3F215; Thu, 28 Feb 2013 11:20:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1362050391!19623749!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16047 invoked from network); 28 Feb 2013 11:19:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237287"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:19:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:19:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1Wg-0007ed-O0;
	Thu, 28 Feb 2013 11:19:50 +0000
Date: Thu, 28 Feb 2013 11:19:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228111950.GB24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
	<512E495602000078000C1AA8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E495602000078000C1AA8@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 04:58:46PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -224,6 +224,8 @@ struct domain
> >  
> >      unsigned long   *evtchn_pending;
> >      unsigned long   *evtchn_mask;
> > +    /* Can the domain use extended event channel (new ABI)? */
> > +    bool_t           evtchn_extended_allowed;
> >  
> >      struct grant_table *grant_table;
> >  
> 
> Please find a better place for this - putting a 1-byte variable
> between two pointers adds unnecessary 7-byte padding. And
> there's already a bunch of bool_t-s in struct domain...
> 

Sure.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:21:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:21: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 1UB1Xk-0001sy-1G; Thu, 28 Feb 2013 11:20:56 +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 1UB1Xi-0001sh-QE
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:20:55 +0000
Received: from [85.158.139.211:31364] by server-2.bemta-5.messagelabs.com id
	A1/C5-23989-69D3F215; Thu, 28 Feb 2013 11:20:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1362050391!19623749!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16047 invoked from network); 28 Feb 2013 11:19:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237287"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:19:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:19:51 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1Wg-0007ed-O0;
	Thu, 28 Feb 2013 11:19:50 +0000
Date: Thu, 28 Feb 2013 11:19:50 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228111950.GB24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
	<512E495602000078000C1AA8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E495602000078000C1AA8@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 04:58:46PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -224,6 +224,8 @@ struct domain
> >  
> >      unsigned long   *evtchn_pending;
> >      unsigned long   *evtchn_mask;
> > +    /* Can the domain use extended event channel (new ABI)? */
> > +    bool_t           evtchn_extended_allowed;
> >  
> >      struct grant_table *grant_table;
> >  
> 
> Please find a better place for this - putting a 1-byte variable
> between two pointers adds unnecessary 7-byte padding. And
> there's already a bunch of bool_t-s in struct domain...
> 

Sure.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:21:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:21: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 1UB1YV-00021u-HO; Thu, 28 Feb 2013 11:21:43 +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 1UB1YT-00021Z-VS
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:21:42 +0000
Received: from [193.109.254.147:19865] by server-3.bemta-14.messagelabs.com id
	27/75-22141-5CD3F215; Thu, 28 Feb 2013 11:21:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1362050486!10003638!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24233 invoked from network); 28 Feb 2013 11:21:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237545"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:21:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:21:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1YD-0007gQ-81;
	Thu, 28 Feb 2013 11:21:25 +0000
Date: Thu, 28 Feb 2013 11:21:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228112125.GC24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
	<512E46C002000078000C1A71@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E46C002000078000C1A71@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/22] Add supported extended event
 channel ABI bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 04:47:44PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/common/event_channel.c |    4 ++++
> >  xen/include/xen/event.h    |    1 +
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> > index c73c709..470b8d2 100644
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -32,6 +32,10 @@
> >  #include <public/event_channel.h>
> >  #include <xsm/xsm.h>
> >  
> > +/* A bitmap of supported extended event channel ABIs */
> > +uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
> 
> This should be just EVTCHN_EXTENDED_NONE until the last
> patch that fully implements 3-level event channels.
> 

No problem.


Wei.

> Jan
> 
> > +                                   EVTCHN_EXTENDED_L3);
> > +
> >  #define ERROR_EXIT(_errno)                                          \
> >      do {                                                            \
> >          gdprintk(XENLOG_WARNING,                                    \
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:21:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:21: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 1UB1YV-00021u-HO; Thu, 28 Feb 2013 11:21:43 +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 1UB1YT-00021Z-VS
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:21:42 +0000
Received: from [193.109.254.147:19865] by server-3.bemta-14.messagelabs.com id
	27/75-22141-5CD3F215; Thu, 28 Feb 2013 11:21:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1362050486!10003638!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24233 invoked from network); 28 Feb 2013 11:21:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237545"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:21:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:21:25 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1YD-0007gQ-81;
	Thu, 28 Feb 2013 11:21:25 +0000
Date: Thu, 28 Feb 2013 11:21:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228112125.GC24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-13-git-send-email-wei.liu2@citrix.com>
	<512E46C002000078000C1A71@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E46C002000078000C1A71@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/22] Add supported extended event
 channel ABI bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 04:47:44PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/common/event_channel.c |    4 ++++
> >  xen/include/xen/event.h    |    1 +
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> > index c73c709..470b8d2 100644
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -32,6 +32,10 @@
> >  #include <public/event_channel.h>
> >  #include <xsm/xsm.h>
> >  
> > +/* A bitmap of supported extended event channel ABIs */
> > +uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
> 
> This should be just EVTCHN_EXTENDED_NONE until the last
> patch that fully implements 3-level event channels.
> 

No problem.


Wei.

> Jan
> 
> > +                                   EVTCHN_EXTENDED_L3);
> > +
> >  #define ERROR_EXIT(_errno)                                          \
> >      do {                                                            \
> >          gdprintk(XENLOG_WARNING,                                    \
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:22:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:22: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 1UB1ZG-00029x-04; Thu, 28 Feb 2013 11:22:30 +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 1UB1ZE-00029W-3r
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:22:28 +0000
Received: from [85.158.139.83:59484] by server-1.bemta-5.messagelabs.com id
	66/B1-14063-3FD3F215; Thu, 28 Feb 2013 11:22:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1362050543!25513987!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22308 invoked from network); 28 Feb 2013 11:22:25 -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;
	28 Feb 2013 11:22:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237665"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:22:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:22:23 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1Z8-0007hW-QD;
	Thu, 28 Feb 2013 11:22:22 +0000
Date: Thu, 28 Feb 2013 11:22:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130228112222.GD24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
	<512F3D88.8060100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F3D88.8060100@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 04/22] flask: include xen/event.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 Thu, Feb 28, 2013 at 11:20:40AM +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > Some definitions for event channel have been moved to new header file.
> 
> This suggests the previous patch broke the build.  Fold 3 and 4 together
> or you will break bisection.

OK, thanks.

Wei.

> 
> David
> 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/xsm/flask/hooks.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> > index 29a78dd..6d446ab 100644
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -11,6 +11,7 @@
> >  #include <xen/init.h>
> >  #include <xen/lib.h>
> >  #include <xen/sched.h>
> > +#include <xen/event.h>
> >  #include <xen/paging.h>
> >  #include <xen/xmalloc.h>
> >  #include <xsm/xsm.h>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:22:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:22: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 1UB1ZG-00029x-04; Thu, 28 Feb 2013 11:22:30 +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 1UB1ZE-00029W-3r
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:22:28 +0000
Received: from [85.158.139.83:59484] by server-1.bemta-5.messagelabs.com id
	66/B1-14063-3FD3F215; Thu, 28 Feb 2013 11:22:27 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1362050543!25513987!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22308 invoked from network); 28 Feb 2013 11:22:25 -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;
	28 Feb 2013 11:22:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237665"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:22:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:22:23 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1Z8-0007hW-QD;
	Thu, 28 Feb 2013 11:22:22 +0000
Date: Thu, 28 Feb 2013 11:22:22 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130228112222.GD24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-5-git-send-email-wei.liu2@citrix.com>
	<512F3D88.8060100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F3D88.8060100@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 04/22] flask: include xen/event.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 Thu, Feb 28, 2013 at 11:20:40AM +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > Some definitions for event channel have been moved to new header file.
> 
> This suggests the previous patch broke the build.  Fold 3 and 4 together
> or you will break bisection.

OK, thanks.

Wei.

> 
> David
> 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/xsm/flask/hooks.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> > index 29a78dd..6d446ab 100644
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -11,6 +11,7 @@
> >  #include <xen/init.h>
> >  #include <xen/lib.h>
> >  #include <xen/sched.h>
> > +#include <xen/event.h>
> >  #include <xen/paging.h>
> >  #include <xen/xmalloc.h>
> >  #include <xsm/xsm.h>
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:25:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1cB-0002Uq-Kp; Thu, 28 Feb 2013 11:25:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1cA-0002Uh-RP
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:25:31 +0000
Received: from [85.158.137.99:35788] by server-12.bemta-3.messagelabs.com id
	A8/A5-01357-4AE3F215; Thu, 28 Feb 2013 11:25:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1362050720!16197516!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7972 invoked from network); 28 Feb 2013 11:25:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:25:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237951"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:25:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:25:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1bz-0007js-Kw;
	Thu, 28 Feb 2013 11:25:19 +0000
Date: Thu, 28 Feb 2013 11:25:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228112519.GE24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512E45A002000078000C1A46@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E45A002000078000C1A46@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> > +/* commands:
> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> > + *                _NONE      supported types are or'ed in return value of
> > + *                           the hypercall.
> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> > + */
> > +#define EVTCHN_EXTENDED_QUERY 0
> > +/* supported extended event channel */
> > +#define EVTCHN_EXTENDED_NONE  0
> > +#define _EVTCHN_EXTENDED_L3   0
> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> > +struct evtchn_register_extended {
> > +    /* IN parameters. */
> > +    uint32_t cmd;
> 
> Looking at patch 18 you seem to indeed plan on passing a bit mask
> with a single bit set as command. Is that really reasonable? I can
> see the need for the query to return a bit mask, but that's it.
> 

When passing as command, the cmd field is not a bit mask. It is just
that I reuse the numeric representation of the bit mask, saving the need
to assign different numbers to commands.


Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:25:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1cB-0002Uq-Kp; Thu, 28 Feb 2013 11:25:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1cA-0002Uh-RP
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:25:31 +0000
Received: from [85.158.137.99:35788] by server-12.bemta-3.messagelabs.com id
	A8/A5-01357-4AE3F215; Thu, 28 Feb 2013 11:25:24 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1362050720!16197516!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7972 invoked from network); 28 Feb 2013 11:25:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:25:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10237951"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:25:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:25:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1bz-0007js-Kw;
	Thu, 28 Feb 2013 11:25:19 +0000
Date: Thu, 28 Feb 2013 11:25:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228112519.GE24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512E45A002000078000C1A46@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E45A002000078000C1A46@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> > +/* commands:
> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> > + *                _NONE      supported types are or'ed in return value of
> > + *                           the hypercall.
> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> > + */
> > +#define EVTCHN_EXTENDED_QUERY 0
> > +/* supported extended event channel */
> > +#define EVTCHN_EXTENDED_NONE  0
> > +#define _EVTCHN_EXTENDED_L3   0
> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> > +struct evtchn_register_extended {
> > +    /* IN parameters. */
> > +    uint32_t cmd;
> 
> Looking at patch 18 you seem to indeed plan on passing a bit mask
> with a single bit set as command. Is that really reasonable? I can
> see the need for the query to return a bit mask, but that's it.
> 

When passing as command, the cmd field is not a bit mask. It is just
that I reuse the numeric representation of the bit mask, saving the need
to assign different numbers to commands.


Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:28: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 1UB1f7-0002ir-8p; Thu, 28 Feb 2013 11:28:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1f6-0002ij-FK
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:28:32 +0000
Received: from [85.158.138.51:51621] by server-13.bemta-3.messagelabs.com id
	2B/92-25744-E5F3F215; Thu, 28 Feb 2013 11:28:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1362050898!20749474!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12849 invoked from network); 28 Feb 2013 11:28:19 -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;
	28 Feb 2013 11:28:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10238486"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:28:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:28:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1er-0007mb-1J;
	Thu, 28 Feb 2013 11:28:17 +0000
Date: Thu, 28 Feb 2013 11:28:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228112816.GF24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
	<512E47B102000078000C1A74@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E47B102000078000C1A74@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 04:51:45PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -36,6 +36,20 @@
> >  uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
> >                                     EVTCHN_EXTENDED_L3);
> >  
> > +static inline const char * evtchn_abi_str(unsigned int abi)
> > +{
> > +    switch ( abi )
> > +    {
> > +    case EVTCHN_EXTENDED_NONE:
> > +        return "2-level";
> > +    case EVTCHN_EXTENDED_L3:
> > +        return "3-level";
> > +    default:
> > +        BUG();
> > +    }
> > +    return ""; /* make compiler happy */
> > +}
> > +
> 
> This is the sort of change that looks completely bogus - even the
> next few patches don't seem to make use of this. Why can't this
> be added when the first user of it appears? It surely won't make
> reviewing that patch more difficult...
> 

Do you mean the implementation is bogus or the way I break my patches?

> And that's a general problem (for me at least) with how you break
> up patches: Having looked ahead at 18 and 19, the latter undoes
> quite a significant portion of what the former did. Both being far
> from huge and unreviewable, why don't you fold them so things
> actually make sense to the reader?
> 

Sure, this can be done.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:28: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 1UB1f7-0002ir-8p; Thu, 28 Feb 2013 11:28:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB1f6-0002ij-FK
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:28:32 +0000
Received: from [85.158.138.51:51621] by server-13.bemta-3.messagelabs.com id
	2B/92-25744-E5F3F215; Thu, 28 Feb 2013 11:28:30 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1362050898!20749474!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12849 invoked from network); 28 Feb 2013 11:28:19 -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;
	28 Feb 2013 11:28:19 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10238486"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:28:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:28:17 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1er-0007mb-1J;
	Thu, 28 Feb 2013 11:28:17 +0000
Date: Thu, 28 Feb 2013 11:28:17 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228112816.GF24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
	<512E47B102000078000C1A74@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E47B102000078000C1A74@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 04:51:45PM +0000, Jan Beulich wrote:
> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -36,6 +36,20 @@
> >  uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
> >                                     EVTCHN_EXTENDED_L3);
> >  
> > +static inline const char * evtchn_abi_str(unsigned int abi)
> > +{
> > +    switch ( abi )
> > +    {
> > +    case EVTCHN_EXTENDED_NONE:
> > +        return "2-level";
> > +    case EVTCHN_EXTENDED_L3:
> > +        return "3-level";
> > +    default:
> > +        BUG();
> > +    }
> > +    return ""; /* make compiler happy */
> > +}
> > +
> 
> This is the sort of change that looks completely bogus - even the
> next few patches don't seem to make use of this. Why can't this
> be added when the first user of it appears? It surely won't make
> reviewing that patch more difficult...
> 

Do you mean the implementation is bogus or the way I break my patches?

> And that's a general problem (for me at least) with how you break
> up patches: Having looked ahead at 18 and 19, the latter undoes
> quite a significant portion of what the former did. Both being far
> from huge and unreviewable, why don't you fold them so things
> actually make sense to the reader?
> 

Sure, this can be done.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:28: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 1UB1f9-0002jC-M8; Thu, 28 Feb 2013 11:28:35 +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 1UB1f7-0002iq-NE
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:28:33 +0000
Received: from [85.158.139.83:32287] by server-11.bemta-5.messagelabs.com id
	34/E1-27486-06F3F215; Thu, 28 Feb 2013 11:28:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1362050730!29430915!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29647 invoked from network); 28 Feb 2013 11:25:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2017938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:25:31 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 28 Feb 2013 11:25:30 +0000
Message-ID: <512F3EA9.1070704@citrix.com>
Date: Thu, 28 Feb 2013 12:25:29 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<512F443702000078000C1DF7@nat28.tlf.novell.com>
In-Reply-To: <512F443702000078000C1DF7@nat28.tlf.novell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 11:49, Jan Beulich wrote:
>>>> On 28.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
>> This series contains the initial implementation of indirect 
>> descriptors for Linux blkback/blkfront.
>>
>> Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.
>>
>> Patch 6 contains a LRU implementation for blkback that will be needed 
>> when using indirect descriptors (since we are no longer able to map 
>> all possible grants blkfront might use).
> 
> Considering this, ...
> 
>> Patch 7 is an addition to the print stats function in blkback in order 
>> to print information regarding persistent grant usage.
>>
>> Patches 8, 9, 10 and 11 are preparatory work for indirect descriptors 
>> implementation, mainly make blkback use dynamic memory and remove the 
>> shared blkbk structure, so each blkback instance has it's own list of 
>> free requests, pages, handles and so on.
>>
>> Finally patch 12 contains the indirect descriptors implementation.
>>
>> I've also pushed this series to the following git repository:
>>
>> git://xenbits.xen.org/people/royger/linux.git xen-block-indirect
>>
>> Performance benefit of this series can be seen in the following graph:
>>
>> http://xenbits.xen.org/people/royger/plot_indirect.png 
> 
> ... would you happen to also have a comparison with using
> indirect descriptors but not persistent grants? IOW I'm
> wondering about the hit rate on the persistently mapped
> grants, especially when blkfront really saturates the added
> bandwidth.

This is the expanded graph that also contains indirect descriptors
without persistent grants:

http://xenbits.xen.org/people/royger/plot_indirect_nopers.png


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:28:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:28: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 1UB1f9-0002jC-M8; Thu, 28 Feb 2013 11:28:35 +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 1UB1f7-0002iq-NE
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:28:33 +0000
Received: from [85.158.139.83:32287] by server-11.bemta-5.messagelabs.com id
	34/E1-27486-06F3F215; Thu, 28 Feb 2013 11:28:32 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1362050730!29430915!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29647 invoked from network); 28 Feb 2013 11:25:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2017938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:25:31 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 28 Feb 2013 11:25:30 +0000
Message-ID: <512F3EA9.1070704@citrix.com>
Date: Thu, 28 Feb 2013 12:25:29 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<512F443702000078000C1DF7@nat28.tlf.novell.com>
In-Reply-To: <512F443702000078000C1DF7@nat28.tlf.novell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 11:49, Jan Beulich wrote:
>>>> On 28.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
>> This series contains the initial implementation of indirect 
>> descriptors for Linux blkback/blkfront.
>>
>> Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.
>>
>> Patch 6 contains a LRU implementation for blkback that will be needed 
>> when using indirect descriptors (since we are no longer able to map 
>> all possible grants blkfront might use).
> 
> Considering this, ...
> 
>> Patch 7 is an addition to the print stats function in blkback in order 
>> to print information regarding persistent grant usage.
>>
>> Patches 8, 9, 10 and 11 are preparatory work for indirect descriptors 
>> implementation, mainly make blkback use dynamic memory and remove the 
>> shared blkbk structure, so each blkback instance has it's own list of 
>> free requests, pages, handles and so on.
>>
>> Finally patch 12 contains the indirect descriptors implementation.
>>
>> I've also pushed this series to the following git repository:
>>
>> git://xenbits.xen.org/people/royger/linux.git xen-block-indirect
>>
>> Performance benefit of this series can be seen in the following graph:
>>
>> http://xenbits.xen.org/people/royger/plot_indirect.png 
> 
> ... would you happen to also have a comparison with using
> indirect descriptors but not persistent grants? IOW I'm
> wondering about the hit rate on the persistently mapped
> grants, especially when blkfront really saturates the added
> bandwidth.

This is the expanded graph that also contains indirect descriptors
without persistent grants:

http://xenbits.xen.org/people/royger/plot_indirect_nopers.png


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:31:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1hr-00030B-Ak; Thu, 28 Feb 2013 11:31:23 +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 1UB1ho-0002zs-NN
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:31:21 +0000
Received: from [85.158.139.211:65010] by server-12.bemta-5.messagelabs.com id
	DE/06-11486-8004F215; Thu, 28 Feb 2013 11:31:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362051066!19534730!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16211 invoked from network); 28 Feb 2013 11:31:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:31:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9736222"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:30:58 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:30:58 -0500
Message-ID: <512F3FF0.4060607@citrix.com>
Date: Thu, 28 Feb 2013 11:30:56 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:33, Wei Liu wrote:
> Affected files:
> * event_channel.c
> * sched.h
> * event.h
> * xen.h

Is this sort of white space patch useful?

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |   16 ++++++++--------
>  xen/include/public/xen.h   |   22 +++++++++++-----------
>  xen/include/xen/event.h    |    4 ++--
>  xen/include/xen/sched.h    |    6 +++---
>  4 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 2d7afc9..9231eb0 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1,15 +1,15 @@
>  /******************************************************************************
>   * event_channel.c
> - * 
> + *
>   * Event notifications from VIRQs, PIRQs, and other domains.
> - * 
> + *
>   * Copyright (c) 2003-2006, K A Fraser.
> - * 
> + *
>   * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> @@ -238,7 +238,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>      lchn->u.interdomain.remote_dom  = rd;
>      lchn->u.interdomain.remote_port = (u16)rport;
>      lchn->state                     = ECS_INTERDOMAIN;
> -    
> +
>      rchn->u.interdomain.remote_dom  = ld;
>      rchn->u.interdomain.remote_port = (u16)lport;
>      rchn->state                     = ECS_INTERDOMAIN;
> @@ -255,7 +255,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>      spin_unlock(&ld->event_lock);
>      if ( ld != rd )
>          spin_unlock(&rd->event_lock);
> -    
> +
>      rcu_unlock_domain(rd);
>  
>      return rc;
> @@ -633,7 +633,7 @@ static void evtchn_set_pending(struct vcpu *v, int port)
>      {
>          vcpu_mark_events_pending(v);
>      }
> -    
> +
>      /* Check if some VCPU might be polling for this event. */
>      if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
>          return;
> @@ -930,7 +930,7 @@ int evtchn_unmask(unsigned int port)
>  
>      /*
>       * These operations must happen in strict order. Based on
> -     * include/xen/event.h:evtchn_set_pending(). 
> +     * include/xen/event.h:evtchn_set_pending().
>       */
>      if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
>           test_bit          (port, &shared_info(d, evtchn_pending)) &&
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 99c8212..87380e6 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * xen.h
> - * 
> + *
>   * Guest OS interface to Xen.
> - * 
> + *
>   * 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
> @@ -137,11 +137,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #define __HYPERVISOR_dom0_op __HYPERVISOR_platform_op
>  #endif
>  
> -/* 
> +/*
>   * VIRTUAL INTERRUPTS
> - * 
> + *
>   * Virtual interrupts that a guest OS may receive from Xen.
> - * 
> + *
>   * In the side comments, 'V.' denotes a per-VCPU VIRQ while 'G.' denotes a
>   * global VIRQ. The former can be bound once per VCPU and cannot be re-bound.
>   * The latter can be allocated only once per guest: they must initially be
> @@ -190,7 +190,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   *                     (x) encodes the PFD as follows:
>   *                     x == 0 => PFD == DOMID_SELF
>   *                     x != 0 => PFD == x - 1
> - * 
> + *
>   * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
>   * -------------
>   * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
> @@ -236,13 +236,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   * To deallocate the pages, the operations are the reverse of the steps
>   * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
>   * pagetable MUST not be in use (meaning that the cr3 is not set to it).
> - * 
> + *
>   * ptr[1:0] == MMU_MACHPHYS_UPDATE:
>   * Updates an entry in the machine->pseudo-physical mapping table.
>   * ptr[:2]  -- Machine address within the frame whose mapping to modify.
>   *             The frame must belong to the FD, if one is specified.
>   * val      -- Value to write into the mapping entry.
> - * 
> + *
>   * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
>   * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
>   * with those in @val.
> @@ -588,7 +588,7 @@ typedef struct vcpu_time_info vcpu_time_info_t;
>  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 
> +     * 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
> @@ -646,7 +646,7 @@ struct shared_info {
>       *  3. Virtual interrupts ('events'). A domain can bind an event-channel
>       *     port to a virtual interrupt source, such as the virtual-timer
>       *     device or the emergency console.
> -     * 
> +     *
>       * Event channels are addressed by a "port index". Each channel is
>       * associated with two bits of information:
>       *  1. PENDING -- notifies the domain that there is a pending notification
> @@ -657,7 +657,7 @@ struct shared_info {
>       *     becomes pending while the channel is masked then the 'edge' is lost
>       *     (i.e., when the channel is unmasked, the guest must manually handle
>       *     pending notifications as no upcall will be scheduled by Xen).
> -     * 
> +     *
>       * To expedite scanning of pending notifications, any 0->1 pending
>       * transition on an unmasked channel causes a corresponding bit in a
>       * per-vcpu selector word to be set. Each bit in the selector covers a
> diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
> index 71c3e92..65ac81a 100644
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * event.h
> - * 
> + *
>   * A nice interface for passing asynchronous events to guest OSes.
> - * 
> + *
>   * Copyright (c) 2002-2006, K A Fraser
>   */
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index ba0f2f8..f6846d4 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -92,7 +92,7 @@ void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
>  
>  struct waitqueue_vcpu;
>  
> -struct vcpu 
> +struct vcpu
>  {
>      int              vcpu_id;
>  
> @@ -453,7 +453,7 @@ struct domain *domain_create(
>  /*
>   * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
>   * This is the preferred function if the returned domain reference
> - * is short lived,  but it cannot be used if the domain reference needs 
> + * is short lived,  but it cannot be used if the domain reference needs
>   * to be kept beyond the current scope (e.g., across a softirq).
>   * The returned domain reference must be discarded using rcu_unlock_domain().
>   */
> @@ -574,7 +574,7 @@ void sync_local_execstate(void);
>   * sync_vcpu_execstate() will switch and commit @prev's state.
>   */
>  void context_switch(
> -    struct vcpu *prev, 
> +    struct vcpu *prev,
>      struct vcpu *next);
>  
>  /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:31:36 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1hr-00030B-Ak; Thu, 28 Feb 2013 11:31:23 +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 1UB1ho-0002zs-NN
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:31:21 +0000
Received: from [85.158.139.211:65010] by server-12.bemta-5.messagelabs.com id
	DE/06-11486-8004F215; Thu, 28 Feb 2013 11:31:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362051066!19534730!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16211 invoked from network); 28 Feb 2013 11:31:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:31:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9736222"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:30:58 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL01.citrite.net
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:30:58 -0500
Message-ID: <512F3FF0.4060607@citrix.com>
Date: Thu, 28 Feb 2013 11:30:56 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:33, Wei Liu wrote:
> Affected files:
> * event_channel.c
> * sched.h
> * event.h
> * xen.h

Is this sort of white space patch useful?

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |   16 ++++++++--------
>  xen/include/public/xen.h   |   22 +++++++++++-----------
>  xen/include/xen/event.h    |    4 ++--
>  xen/include/xen/sched.h    |    6 +++---
>  4 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 2d7afc9..9231eb0 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1,15 +1,15 @@
>  /******************************************************************************
>   * event_channel.c
> - * 
> + *
>   * Event notifications from VIRQs, PIRQs, and other domains.
> - * 
> + *
>   * Copyright (c) 2003-2006, K A Fraser.
> - * 
> + *
>   * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> @@ -238,7 +238,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>      lchn->u.interdomain.remote_dom  = rd;
>      lchn->u.interdomain.remote_port = (u16)rport;
>      lchn->state                     = ECS_INTERDOMAIN;
> -    
> +
>      rchn->u.interdomain.remote_dom  = ld;
>      rchn->u.interdomain.remote_port = (u16)lport;
>      rchn->state                     = ECS_INTERDOMAIN;
> @@ -255,7 +255,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>      spin_unlock(&ld->event_lock);
>      if ( ld != rd )
>          spin_unlock(&rd->event_lock);
> -    
> +
>      rcu_unlock_domain(rd);
>  
>      return rc;
> @@ -633,7 +633,7 @@ static void evtchn_set_pending(struct vcpu *v, int port)
>      {
>          vcpu_mark_events_pending(v);
>      }
> -    
> +
>      /* Check if some VCPU might be polling for this event. */
>      if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
>          return;
> @@ -930,7 +930,7 @@ int evtchn_unmask(unsigned int port)
>  
>      /*
>       * These operations must happen in strict order. Based on
> -     * include/xen/event.h:evtchn_set_pending(). 
> +     * include/xen/event.h:evtchn_set_pending().
>       */
>      if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
>           test_bit          (port, &shared_info(d, evtchn_pending)) &&
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 99c8212..87380e6 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * xen.h
> - * 
> + *
>   * Guest OS interface to Xen.
> - * 
> + *
>   * 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
> @@ -137,11 +137,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #define __HYPERVISOR_dom0_op __HYPERVISOR_platform_op
>  #endif
>  
> -/* 
> +/*
>   * VIRTUAL INTERRUPTS
> - * 
> + *
>   * Virtual interrupts that a guest OS may receive from Xen.
> - * 
> + *
>   * In the side comments, 'V.' denotes a per-VCPU VIRQ while 'G.' denotes a
>   * global VIRQ. The former can be bound once per VCPU and cannot be re-bound.
>   * The latter can be allocated only once per guest: they must initially be
> @@ -190,7 +190,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   *                     (x) encodes the PFD as follows:
>   *                     x == 0 => PFD == DOMID_SELF
>   *                     x != 0 => PFD == x - 1
> - * 
> + *
>   * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
>   * -------------
>   * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
> @@ -236,13 +236,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   * To deallocate the pages, the operations are the reverse of the steps
>   * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
>   * pagetable MUST not be in use (meaning that the cr3 is not set to it).
> - * 
> + *
>   * ptr[1:0] == MMU_MACHPHYS_UPDATE:
>   * Updates an entry in the machine->pseudo-physical mapping table.
>   * ptr[:2]  -- Machine address within the frame whose mapping to modify.
>   *             The frame must belong to the FD, if one is specified.
>   * val      -- Value to write into the mapping entry.
> - * 
> + *
>   * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
>   * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
>   * with those in @val.
> @@ -588,7 +588,7 @@ typedef struct vcpu_time_info vcpu_time_info_t;
>  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 
> +     * 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
> @@ -646,7 +646,7 @@ struct shared_info {
>       *  3. Virtual interrupts ('events'). A domain can bind an event-channel
>       *     port to a virtual interrupt source, such as the virtual-timer
>       *     device or the emergency console.
> -     * 
> +     *
>       * Event channels are addressed by a "port index". Each channel is
>       * associated with two bits of information:
>       *  1. PENDING -- notifies the domain that there is a pending notification
> @@ -657,7 +657,7 @@ struct shared_info {
>       *     becomes pending while the channel is masked then the 'edge' is lost
>       *     (i.e., when the channel is unmasked, the guest must manually handle
>       *     pending notifications as no upcall will be scheduled by Xen).
> -     * 
> +     *
>       * To expedite scanning of pending notifications, any 0->1 pending
>       * transition on an unmasked channel causes a corresponding bit in a
>       * per-vcpu selector word to be set. Each bit in the selector covers a
> diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
> index 71c3e92..65ac81a 100644
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * event.h
> - * 
> + *
>   * A nice interface for passing asynchronous events to guest OSes.
> - * 
> + *
>   * Copyright (c) 2002-2006, K A Fraser
>   */
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index ba0f2f8..f6846d4 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -92,7 +92,7 @@ void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
>  
>  struct waitqueue_vcpu;
>  
> -struct vcpu 
> +struct vcpu
>  {
>      int              vcpu_id;
>  
> @@ -453,7 +453,7 @@ struct domain *domain_create(
>  /*
>   * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
>   * This is the preferred function if the returned domain reference
> - * is short lived,  but it cannot be used if the domain reference needs 
> + * is short lived,  but it cannot be used if the domain reference needs
>   * to be kept beyond the current scope (e.g., across a softirq).
>   * The returned domain reference must be discarded using rcu_unlock_domain().
>   */
> @@ -574,7 +574,7 @@ void sync_local_execstate(void);
>   * sync_vcpu_execstate() will switch and commit @prev's state.
>   */
>  void context_switch(
> -    struct vcpu *prev, 
> +    struct vcpu *prev,
>      struct vcpu *next);
>  
>  /*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:32:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1j3-0003EW-6e; Thu, 28 Feb 2013 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 1UB1j2-0003E2-5V
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:32:36 +0000
Received: from [85.158.143.99:54662] by server-1.bemta-4.messagelabs.com id
	74/AC-06203-3504F215; Thu, 28 Feb 2013 11:32:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1362051145!29166247!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4387 invoked from network); 28 Feb 2013 11:32:25 -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; 28 Feb 2013 11:32:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:32:25 +0000
Message-Id: <512F4E5802000078000C1EB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:32:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512E45A002000078000C1A46@nat28.tlf.novell.com>
	<20130228112519.GE24002@zion.uk.xensource.com>
In-Reply-To: <20130228112519.GE24002@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 28.02.13 at 12:25, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
>> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>> > +/* commands:
>> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
>> > + *                _NONE      supported types are or'ed in return value of
>> > + *                           the hypercall.
>> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
>> > + */
>> > +#define EVTCHN_EXTENDED_QUERY 0
>> > +/* supported extended event channel */
>> > +#define EVTCHN_EXTENDED_NONE  0
>> > +#define _EVTCHN_EXTENDED_L3   0
>> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
>> > +struct evtchn_register_extended {
>> > +    /* IN parameters. */
>> > +    uint32_t cmd;
>> 
>> Looking at patch 18 you seem to indeed plan on passing a bit mask
>> with a single bit set as command. Is that really reasonable? I can
>> see the need for the query to return a bit mask, but that's it.
>> 
> 
> When passing as command, the cmd field is not a bit mask. It is just
> that I reuse the numeric representation of the bit mask, saving the need
> to assign different numbers to commands.

I understand that, but this will limit you to 32 commands (plus
zero for the query).

I'd instead suggest to set _EVTCHN_EXTENDED_L3 to 1, and
pass this as command. Bit 0 of the mask returned by the query
will then remain unused, allowing it to become a meaning when
e.g. the 31 bits don't suffice anymore. Which isn't to say that
I expect 31 or even more different implementations here - I
merely like to have interfaces be extensible from an abstract
perspective, even if one can't foresee the need for extensions
(which might turn out necessary tens of years later).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:32:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB1j3-0003EW-6e; Thu, 28 Feb 2013 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 1UB1j2-0003E2-5V
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:32:36 +0000
Received: from [85.158.143.99:54662] by server-1.bemta-4.messagelabs.com id
	74/AC-06203-3504F215; Thu, 28 Feb 2013 11:32:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1362051145!29166247!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4387 invoked from network); 28 Feb 2013 11:32:25 -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; 28 Feb 2013 11:32:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:32:25 +0000
Message-Id: <512F4E5802000078000C1EB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:32:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512E45A002000078000C1A46@nat28.tlf.novell.com>
	<20130228112519.GE24002@zion.uk.xensource.com>
In-Reply-To: <20130228112519.GE24002@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 28.02.13 at 12:25, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
>> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
>> > +/* commands:
>> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
>> > + *                _NONE      supported types are or'ed in return value of
>> > + *                           the hypercall.
>> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
>> > + */
>> > +#define EVTCHN_EXTENDED_QUERY 0
>> > +/* supported extended event channel */
>> > +#define EVTCHN_EXTENDED_NONE  0
>> > +#define _EVTCHN_EXTENDED_L3   0
>> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
>> > +struct evtchn_register_extended {
>> > +    /* IN parameters. */
>> > +    uint32_t cmd;
>> 
>> Looking at patch 18 you seem to indeed plan on passing a bit mask
>> with a single bit set as command. Is that really reasonable? I can
>> see the need for the query to return a bit mask, but that's it.
>> 
> 
> When passing as command, the cmd field is not a bit mask. It is just
> that I reuse the numeric representation of the bit mask, saving the need
> to assign different numbers to commands.

I understand that, but this will limit you to 32 commands (plus
zero for the query).

I'd instead suggest to set _EVTCHN_EXTENDED_L3 to 1, and
pass this as command. Bit 0 of the mask returned by the query
will then remain unused, allowing it to become a meaning when
e.g. the 31 bits don't suffice anymore. Which isn't to say that
I expect 31 or even more different implementations here - I
merely like to have interfaces be extensible from an abstract
perspective, even if one can't foresee the need for extensions
(which might turn out necessary tens of years later).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:33:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:33: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 1UB1kD-0003TW-Ml; Thu, 28 Feb 2013 11:33:49 +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 1UB1kC-0003T7-CR
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:33:48 +0000
Received: from [85.158.139.211:48858] by server-3.bemta-5.messagelabs.com id
	38/FC-17256-B904F215; Thu, 28 Feb 2013 11:33:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1362051226!15732378!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21270 invoked from network); 28 Feb 2013 11:33:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:33:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:33:46 +0000
Message-Id: <512F4EA802000078000C1EB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:33:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
	<512E47B102000078000C1A74@nat28.tlf.novell.com>
	<20130228112816.GF24002@zion.uk.xensource.com>
In-Reply-To: <20130228112816.GF24002@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:28, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Feb 27, 2013 at 04:51:45PM +0000, Jan Beulich wrote:
>> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
>> > --- a/xen/common/event_channel.c
>> > +++ b/xen/common/event_channel.c
>> > @@ -36,6 +36,20 @@
>> >  uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
>> >                                     EVTCHN_EXTENDED_L3);
>> >  
>> > +static inline const char * evtchn_abi_str(unsigned int abi)
>> > +{
>> > +    switch ( abi )
>> > +    {
>> > +    case EVTCHN_EXTENDED_NONE:
>> > +        return "2-level";
>> > +    case EVTCHN_EXTENDED_L3:
>> > +        return "3-level";
>> > +    default:
>> > +        BUG();
>> > +    }
>> > +    return ""; /* make compiler happy */
>> > +}
>> > +
>> 
>> This is the sort of change that looks completely bogus - even the
>> next few patches don't seem to make use of this. Why can't this
>> be added when the first user of it appears? It surely won't make
>> reviewing that patch more difficult...
>> 
> 
> Do you mean the implementation is bogus or the way I break
> my patches?

The latter - the need for this function, as said, doesn't even become
visible looking at the next few patches.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:33:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:33: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 1UB1kD-0003TW-Ml; Thu, 28 Feb 2013 11:33:49 +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 1UB1kC-0003T7-CR
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:33:48 +0000
Received: from [85.158.139.211:48858] by server-3.bemta-5.messagelabs.com id
	38/FC-17256-B904F215; Thu, 28 Feb 2013 11:33:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1362051226!15732378!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21270 invoked from network); 28 Feb 2013 11:33:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:33:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:33:46 +0000
Message-Id: <512F4EA802000078000C1EB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:33:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-14-git-send-email-wei.liu2@citrix.com>
	<512E47B102000078000C1A74@nat28.tlf.novell.com>
	<20130228112816.GF24002@zion.uk.xensource.com>
In-Reply-To: <20130228112816.GF24002@zion.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:28, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Feb 27, 2013 at 04:51:45PM +0000, Jan Beulich wrote:
>> >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@citrix.com> wrote:
>> > --- a/xen/common/event_channel.c
>> > +++ b/xen/common/event_channel.c
>> > @@ -36,6 +36,20 @@
>> >  uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE |
>> >                                     EVTCHN_EXTENDED_L3);
>> >  
>> > +static inline const char * evtchn_abi_str(unsigned int abi)
>> > +{
>> > +    switch ( abi )
>> > +    {
>> > +    case EVTCHN_EXTENDED_NONE:
>> > +        return "2-level";
>> > +    case EVTCHN_EXTENDED_L3:
>> > +        return "3-level";
>> > +    default:
>> > +        BUG();
>> > +    }
>> > +    return ""; /* make compiler happy */
>> > +}
>> > +
>> 
>> This is the sort of change that looks completely bogus - even the
>> next few patches don't seem to make use of this. Why can't this
>> be added when the first user of it appears? It surely won't make
>> reviewing that patch more difficult...
>> 
> 
> Do you mean the implementation is bogus or the way I break
> my patches?

The latter - the need for this function, as said, doesn't even become
visible looking at the next few patches.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:36:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:36: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 1UB1mR-0003kT-AT; Thu, 28 Feb 2013 11:36:07 +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 1UB1mP-0003kD-V5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:36:06 +0000
Received: from [85.158.139.211:50157] by server-16.bemta-5.messagelabs.com id
	6E/68-02543-5214F215; Thu, 28 Feb 2013 11:36:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362051345!18093466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21973 invoked from network); 28 Feb 2013 11:35:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:35:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:35:15 +0000
Message-Id: <512F4F0102000078000C1EB8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:35:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<512F443702000078000C1DF7@nat28.tlf.novell.com>
	<512F3EA9.1070704@citrix.com>
In-Reply-To: <512F3EA9.1070704@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI4LjAyLjEzIGF0IDEyOjI1LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRy
aXguY29tPiB3cm90ZToKPiBUaGlzIGlzIHRoZSBleHBhbmRlZCBncmFwaCB0aGF0IGFsc28gY29u
dGFpbnMgaW5kaXJlY3QgZGVzY3JpcHRvcnMKPiB3aXRob3V0IHBlcnNpc3RlbnQgZ3JhbnRzOgo+
IAo+IGh0dHA6Ly94ZW5iaXRzLnhlbi5vcmcvcGVvcGxlL3JveWdlci9wbG90X2luZGlyZWN0X25v
cGVycy5wbmcgCgpUaGFua3MuIEludGVyZXN0aW5nIC0gdGhpcyBzdWdnZXN0cyBhbiB1bmV4cGVj
dGVkbHkgaGlnaCBoaXQgcmF0ZS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:36:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:36: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 1UB1mR-0003kT-AT; Thu, 28 Feb 2013 11:36:07 +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 1UB1mP-0003kD-V5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:36:06 +0000
Received: from [85.158.139.211:50157] by server-16.bemta-5.messagelabs.com id
	6E/68-02543-5214F215; Thu, 28 Feb 2013 11:36:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362051345!18093466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21973 invoked from network); 28 Feb 2013 11:35:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:35:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:35:15 +0000
Message-Id: <512F4F0102000078000C1EB8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:35:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<512F443702000078000C1DF7@nat28.tlf.novell.com>
	<512F3EA9.1070704@citrix.com>
In-Reply-To: <512F3EA9.1070704@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI4LjAyLjEzIGF0IDEyOjI1LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRy
aXguY29tPiB3cm90ZToKPiBUaGlzIGlzIHRoZSBleHBhbmRlZCBncmFwaCB0aGF0IGFsc28gY29u
dGFpbnMgaW5kaXJlY3QgZGVzY3JpcHRvcnMKPiB3aXRob3V0IHBlcnNpc3RlbnQgZ3JhbnRzOgo+
IAo+IGh0dHA6Ly94ZW5iaXRzLnhlbi5vcmcvcGVvcGxlL3JveWdlci9wbG90X2luZGlyZWN0X25v
cGVycy5wbmcgCgpUaGFua3MuIEludGVyZXN0aW5nIC0gdGhpcyBzdWdnZXN0cyBhbiB1bmV4cGVj
dGVkbHkgaGlnaCBoaXQgcmF0ZS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:36:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:36: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 1UB1ml-0003ni-OZ; Thu, 28 Feb 2013 11:36:27 +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 1UB1ml-0003nU-3x
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:36:27 +0000
Received: from [85.158.139.83:13577] by server-15.bemta-5.messagelabs.com id
	E5/AE-22815-A314F215; Thu, 28 Feb 2013 11:36:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1362051375!24207976!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24335 invoked from network); 28 Feb 2013 11:36:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9737163"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:36:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:36:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1mX-0007tf-Ud;
	Thu, 28 Feb 2013 11:36:13 +0000
Date: Thu, 28 Feb 2013 11:36:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130228113613.GG24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F3FF0.4060607@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:30:56AM +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > Affected files:
> > * event_channel.c
> > * sched.h
> > * event.h
> > * xen.h
> 
> Is this sort of white space patch useful?
> 

Not really. But people who have their editors configured to eliminate
white spaces automatically will trip over this and introduce stray white
spaces changes in their patches. Feel free to drop this.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:36:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:36: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 1UB1ml-0003ni-OZ; Thu, 28 Feb 2013 11:36:27 +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 1UB1ml-0003nU-3x
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:36:27 +0000
Received: from [85.158.139.83:13577] by server-15.bemta-5.messagelabs.com id
	E5/AE-22815-A314F215; Thu, 28 Feb 2013 11:36:26 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1362051375!24207976!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24335 invoked from network); 28 Feb 2013 11:36:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9737163"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:36:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:36:14 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1mX-0007tf-Ud;
	Thu, 28 Feb 2013 11:36:13 +0000
Date: Thu, 28 Feb 2013 11:36:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20130228113613.GG24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F3FF0.4060607@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:30:56AM +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > Affected files:
> > * event_channel.c
> > * sched.h
> > * event.h
> > * xen.h
> 
> Is this sort of white space patch useful?
> 

Not really. But people who have their editors configured to eliminate
white spaces automatically will trip over this and introduce stray white
spaces changes in their patches. Feel free to drop this.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:38:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:38: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 1UB1oo-00045K-Dq; Thu, 28 Feb 2013 11:38:34 +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 1UB1on-000459-0C
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:38:33 +0000
Received: from [85.158.139.211:43237] by server-3.bemta-5.messagelabs.com id
	09/06-17256-8B14F215; Thu, 28 Feb 2013 11:38:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362051485!19536307!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21826 invoked from network); 28 Feb 2013 11:38:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:38:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:38:05 +0000
Message-Id: <512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:38:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
In-Reply-To: <512F3FF0.4060607@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> On 27/02/13 14:33, Wei Liu wrote:
>> Affected files:
>> * event_channel.c
>> * sched.h
>> * event.h
>> * xen.h
> 
> Is this sort of white space patch useful?

I think so. It seems we still don't have an in-tree coding style
document, and I don't recall where the out-of-tree one lives, but
even if it doesn't state the "no trailing white space" rule, I think it
should.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:38:43 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:38: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 1UB1oo-00045K-Dq; Thu, 28 Feb 2013 11:38:34 +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 1UB1on-000459-0C
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:38:33 +0000
Received: from [85.158.139.211:43237] by server-3.bemta-5.messagelabs.com id
	09/06-17256-8B14F215; Thu, 28 Feb 2013 11:38:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362051485!19536307!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21826 invoked from network); 28 Feb 2013 11:38:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:38:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 11:38:05 +0000
Message-Id: <512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 11:38:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>, "Wei Liu" <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
In-Reply-To: <512F3FF0.4060607@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> On 27/02/13 14:33, Wei Liu wrote:
>> Affected files:
>> * event_channel.c
>> * sched.h
>> * event.h
>> * xen.h
> 
> Is this sort of white space patch useful?

I think so. It seems we still don't have an in-tree coding style
document, and I don't recall where the out-of-tree one lives, but
even if it doesn't state the "no trailing white space" rule, I think it
should.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:41:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:41: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 1UB1rY-0004J4-9R; Thu, 28 Feb 2013 11:41:24 +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 1UB1rW-0004Iy-QM
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:41:23 +0000
Received: from [85.158.139.83:49817] by server-8.bemta-5.messagelabs.com id
	E1/94-05790-1624F215; Thu, 28 Feb 2013 11:41:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1362051680!28741587!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12183 invoked from network); 28 Feb 2013 11:41:21 -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;
	28 Feb 2013 11:41:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9738005"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:41:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:41:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1rT-0007y6-13;
	Thu, 28 Feb 2013 11:41:19 +0000
Date: Thu, 28 Feb 2013 11:41:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228114118.GH24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512E45A002000078000C1A46@nat28.tlf.novell.com>
	<20130228112519.GE24002@zion.uk.xensource.com>
	<512F4E5802000078000C1EB2@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F4E5802000078000C1EB2@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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, Feb 28, 2013 at 11:32:24AM +0000, Jan Beulich wrote:
> >>> On 28.02.13 at 12:25, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
> >> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > +/* commands:
> >> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> >> > + *                _NONE      supported types are or'ed in return value of
> >> > + *                           the hypercall.
> >> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> >> > + */
> >> > +#define EVTCHN_EXTENDED_QUERY 0
> >> > +/* supported extended event channel */
> >> > +#define EVTCHN_EXTENDED_NONE  0
> >> > +#define _EVTCHN_EXTENDED_L3   0
> >> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> >> > +struct evtchn_register_extended {
> >> > +    /* IN parameters. */
> >> > +    uint32_t cmd;
> >> 
> >> Looking at patch 18 you seem to indeed plan on passing a bit mask
> >> with a single bit set as command. Is that really reasonable? I can
> >> see the need for the query to return a bit mask, but that's it.
> >> 
> > 
> > When passing as command, the cmd field is not a bit mask. It is just
> > that I reuse the numeric representation of the bit mask, saving the need
> > to assign different numbers to commands.
> 
> I understand that, but this will limit you to 32 commands (plus
> zero for the query).
> 
> I'd instead suggest to set _EVTCHN_EXTENDED_L3 to 1, and
> pass this as command. Bit 0 of the mask returned by the query
> will then remain unused, allowing it to become a meaning when
> e.g. the 31 bits don't suffice anymore. Which isn't to say that
> I expect 31 or even more different implementations here - I
> merely like to have interfaces be extensible from an abstract
> perspective, even if one can't foresee the need for extensions
> (which might turn out necessary tens of years later).
> 

Sounds reasonable, I'll make it that way.


Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:41:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:41: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 1UB1rY-0004J4-9R; Thu, 28 Feb 2013 11:41:24 +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 1UB1rW-0004Iy-QM
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:41:23 +0000
Received: from [85.158.139.83:49817] by server-8.bemta-5.messagelabs.com id
	E1/94-05790-1624F215; Thu, 28 Feb 2013 11:41:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1362051680!28741587!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12183 invoked from network); 28 Feb 2013 11:41:21 -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;
	28 Feb 2013 11:41:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9738005"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:41:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:41:19 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB1rT-0007y6-13;
	Thu, 28 Feb 2013 11:41:19 +0000
Date: Thu, 28 Feb 2013 11:41:19 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228114118.GH24002@zion.uk.xensource.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512E45A002000078000C1A46@nat28.tlf.novell.com>
	<20130228112519.GE24002@zion.uk.xensource.com>
	<512F4E5802000078000C1EB2@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F4E5802000078000C1EB2@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Keir \(Xen.org\)" <keir@xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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, Feb 28, 2013 at 11:32:24AM +0000, Jan Beulich wrote:
> >>> On 28.02.13 at 12:25, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Wed, Feb 27, 2013 at 04:42:56PM +0000, Jan Beulich wrote:
> >> >>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > +/* commands:
> >> > + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> >> > + *                _NONE      supported types are or'ed in return value of
> >> > + *                           the hypercall.
> >> > + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.
> >> > + */
> >> > +#define EVTCHN_EXTENDED_QUERY 0
> >> > +/* supported extended event channel */
> >> > +#define EVTCHN_EXTENDED_NONE  0
> >> > +#define _EVTCHN_EXTENDED_L3   0
> >> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> >> > +struct evtchn_register_extended {
> >> > +    /* IN parameters. */
> >> > +    uint32_t cmd;
> >> 
> >> Looking at patch 18 you seem to indeed plan on passing a bit mask
> >> with a single bit set as command. Is that really reasonable? I can
> >> see the need for the query to return a bit mask, but that's it.
> >> 
> > 
> > When passing as command, the cmd field is not a bit mask. It is just
> > that I reuse the numeric representation of the bit mask, saving the need
> > to assign different numbers to commands.
> 
> I understand that, but this will limit you to 32 commands (plus
> zero for the query).
> 
> I'd instead suggest to set _EVTCHN_EXTENDED_L3 to 1, and
> pass this as command. Bit 0 of the mask returned by the query
> will then remain unused, allowing it to become a meaning when
> e.g. the 31 bits don't suffice anymore. Which isn't to say that
> I expect 31 or even more different implementations here - I
> merely like to have interfaces be extensible from an abstract
> perspective, even if one can't foresee the need for extensions
> (which might turn out necessary tens of years later).
> 

Sounds reasonable, I'll make it that way.


Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:44:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:44: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 1UB1uk-0004R2-VW; Thu, 28 Feb 2013 11:44:42 +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 1UB1uk-0004Qu-64
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:44:42 +0000
Received: from [85.158.138.51:25783] by server-2.bemta-3.messagelabs.com id
	A2/40-05208-9234F215; Thu, 28 Feb 2013 11:44:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1362051877!27880422!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1257 invoked from network); 28 Feb 2013 11:44:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2019290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:44:36 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 28 Feb 2013 11:44:36 +0000
Message-ID: <512F4323.50607@citrix.com>
Date: Thu, 28 Feb 2013 12:44:35 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<512F443702000078000C1DF7@nat28.tlf.novell.com>
	<512F3EA9.1070704@citrix.com>
	<512F4F0102000078000C1EB8@nat28.tlf.novell.com>
In-Reply-To: <512F4F0102000078000C1EB8@nat28.tlf.novell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMjgvMDIvMTMgMTI6MzUsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDI4LjAyLjEzIGF0
IDEyOjI1LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRyaXguY29tPiB3cm90ZToKPj4g
VGhpcyBpcyB0aGUgZXhwYW5kZWQgZ3JhcGggdGhhdCBhbHNvIGNvbnRhaW5zIGluZGlyZWN0IGRl
c2NyaXB0b3JzCj4+IHdpdGhvdXQgcGVyc2lzdGVudCBncmFudHM6Cj4+Cj4+IGh0dHA6Ly94ZW5i
aXRzLnhlbi5vcmcvcGVvcGxlL3JveWdlci9wbG90X2luZGlyZWN0X25vcGVycy5wbmcgCj4gCj4g
VGhhbmtzLiBJbnRlcmVzdGluZyAtIHRoaXMgc3VnZ2VzdHMgYW4gdW5leHBlY3RlZGx5IGhpZ2gg
aGl0IHJhdGUuCgpUaGlzIGdyYXBoIGlzIHVzaW5nIHRoZSBkZWZhdWx0IHZhbHVlcywgc28gd2Ug
YXJlIHBlcnNpc3RlbnRseSBtYXBwaW5nCjEwMjQgZ3JhbnRzIG9mIHRoZSBwb3NzaWJsZSAyMDgw
IHRoYXQgY291bGQgYmUgdXNlZCBieSBibGtmcm9udCAoKDY0CnNlZ21lbnRzICsgMSBpbmRpcmVj
dCBncmVmKSAqIDMyID0gMjA4MCkuCgpibGtmcm9udCBzdG9yZXMgZ3JhbnRzIHVzaW5nIGEgc3Rh
Y2ssIHNvIGl0IHNob3VsZCB0cnkgdG8gcmV1c2UgdGhlIHNhbWUKZ3JhbnRzIGFzIG11Y2ggYXMg
cG9zc2libGUuIE9uIHRoZSBvdGhlciBoYW5kLCBibGtiYWNrIGNsZWFucyB1bnVzZWQKZ3JhbnRz
IHBlcmlvZGljYWxseSwgdG8gdHJ5IHRvIGhhdmUgdGhlIG1vc3QgY29tbW9ubHkgdXNlZCBibGtm
cm9udApncmFudHMgbWFwcGVkLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:44:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:44: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 1UB1uk-0004R2-VW; Thu, 28 Feb 2013 11:44:42 +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 1UB1uk-0004Qu-64
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:44:42 +0000
Received: from [85.158.138.51:25783] by server-2.bemta-3.messagelabs.com id
	A2/40-05208-9234F215; Thu, 28 Feb 2013 11:44:41 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1362051877!27880422!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1257 invoked from network); 28 Feb 2013 11:44:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2019290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:44:36 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 28 Feb 2013 11:44:36 +0000
Message-ID: <512F4323.50607@citrix.com>
Date: Thu, 28 Feb 2013 12:44:35 +0100
From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<512F443702000078000C1DF7@nat28.tlf.novell.com>
	<512F3EA9.1070704@citrix.com>
	<512F4F0102000078000C1EB8@nat28.tlf.novell.com>
In-Reply-To: <512F4F0102000078000C1EB8@nat28.tlf.novell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 00/12] xen-block: indirect descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

T24gMjgvMDIvMTMgMTI6MzUsIEphbiBCZXVsaWNoIHdyb3RlOgo+Pj4+IE9uIDI4LjAyLjEzIGF0
IDEyOjI1LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRyaXguY29tPiB3cm90ZToKPj4g
VGhpcyBpcyB0aGUgZXhwYW5kZWQgZ3JhcGggdGhhdCBhbHNvIGNvbnRhaW5zIGluZGlyZWN0IGRl
c2NyaXB0b3JzCj4+IHdpdGhvdXQgcGVyc2lzdGVudCBncmFudHM6Cj4+Cj4+IGh0dHA6Ly94ZW5i
aXRzLnhlbi5vcmcvcGVvcGxlL3JveWdlci9wbG90X2luZGlyZWN0X25vcGVycy5wbmcgCj4gCj4g
VGhhbmtzLiBJbnRlcmVzdGluZyAtIHRoaXMgc3VnZ2VzdHMgYW4gdW5leHBlY3RlZGx5IGhpZ2gg
aGl0IHJhdGUuCgpUaGlzIGdyYXBoIGlzIHVzaW5nIHRoZSBkZWZhdWx0IHZhbHVlcywgc28gd2Ug
YXJlIHBlcnNpc3RlbnRseSBtYXBwaW5nCjEwMjQgZ3JhbnRzIG9mIHRoZSBwb3NzaWJsZSAyMDgw
IHRoYXQgY291bGQgYmUgdXNlZCBieSBibGtmcm9udCAoKDY0CnNlZ21lbnRzICsgMSBpbmRpcmVj
dCBncmVmKSAqIDMyID0gMjA4MCkuCgpibGtmcm9udCBzdG9yZXMgZ3JhbnRzIHVzaW5nIGEgc3Rh
Y2ssIHNvIGl0IHNob3VsZCB0cnkgdG8gcmV1c2UgdGhlIHNhbWUKZ3JhbnRzIGFzIG11Y2ggYXMg
cG9zc2libGUuIE9uIHRoZSBvdGhlciBoYW5kLCBibGtiYWNrIGNsZWFucyB1bnVzZWQKZ3JhbnRz
IHBlcmlvZGljYWxseSwgdG8gdHJ5IHRvIGhhdmUgdGhlIG1vc3QgY29tbW9ubHkgdXNlZCBibGtm
cm9udApncmFudHMgbWFwcGVkLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:49:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:49: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 1UB1zI-0004nH-Ma; Thu, 28 Feb 2013 11:49: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 1UB1zH-0004nB-P5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:49:23 +0000
Received: from [85.158.139.211:10325] by server-11.bemta-5.messagelabs.com id
	C7/DB-27486-2444F215; Thu, 28 Feb 2013 11:49:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362052162!18881656!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9279 invoked from network); 28 Feb 2013 11:49:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:49:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2019636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:49: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.297.1; Thu, 28 Feb 2013 11:49:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB1zG-0005Fb-1E; Thu, 28 Feb 2013 11:49:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB1zF-0004WI-RV;
	Thu, 28 Feb 2013 11:49:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.17473.702340.430234@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 11:49:21 +0000
To: M A Young <m.a.young@durham.ac.uk>
In-Reply-To: <alpine.GSO.2.00.1302281007290.14532@algedi.dur.ac.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<alpine.GSO.2.00.1302281007290.14532@algedi.dur.ac.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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

M A Young writes ("Re: [Xen-devel] preparing for 4.2.2 and 4.1.5"):
> On Wed, 27 Feb 2013, Jan Beulich wrote:
> > Please indicate any bug fixes that so far may have been missed
> > in the backports already done. Quite a few fixes are currently
> > stuck in master's staging branch - these don't need to be named
> > explicitly, I'm already planning to pull over the hypervisor ones
> > as soon as they get out of staging (and I'm sure Ian is planning
> > the same - if applicable at all - for the tools side).
> 
> The patch "tools: Fix memset(&p,0,sizeof(p)) idiom in several places." 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=d119301b5816b39b5ba722a2f8b301b37e8e34bd
> may be worth backporting. It should apply cleanly to 4.2. For 4.1 it 
> should apply with the tools/libxl/libxl_qmp.c piece removed.

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 Thu Feb 28 11:49:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:49: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 1UB1zI-0004nH-Ma; Thu, 28 Feb 2013 11:49: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 1UB1zH-0004nB-P5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:49:23 +0000
Received: from [85.158.139.211:10325] by server-11.bemta-5.messagelabs.com id
	C7/DB-27486-2444F215; Thu, 28 Feb 2013 11:49:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362052162!18881656!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9279 invoked from network); 28 Feb 2013 11:49:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:49:22 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2019636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:49: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.297.1; Thu, 28 Feb 2013 11:49:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB1zG-0005Fb-1E; Thu, 28 Feb 2013 11:49:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB1zF-0004WI-RV;
	Thu, 28 Feb 2013 11:49:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.17473.702340.430234@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 11:49:21 +0000
To: M A Young <m.a.young@durham.ac.uk>
In-Reply-To: <alpine.GSO.2.00.1302281007290.14532@algedi.dur.ac.uk>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<alpine.GSO.2.00.1302281007290.14532@algedi.dur.ac.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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

M A Young writes ("Re: [Xen-devel] preparing for 4.2.2 and 4.1.5"):
> On Wed, 27 Feb 2013, Jan Beulich wrote:
> > Please indicate any bug fixes that so far may have been missed
> > in the backports already done. Quite a few fixes are currently
> > stuck in master's staging branch - these don't need to be named
> > explicitly, I'm already planning to pull over the hypervisor ones
> > as soon as they get out of staging (and I'm sure Ian is planning
> > the same - if applicable at all - for the tools side).
> 
> The patch "tools: Fix memset(&p,0,sizeof(p)) idiom in several places." 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=d119301b5816b39b5ba722a2f8b301b37e8e34bd
> may be worth backporting. It should apply cleanly to 4.2. For 4.1 it 
> should apply with the tools/libxl/libxl_qmp.c piece removed.

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 Thu Feb 28 11:52:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB22N-00057x-LV; Thu, 28 Feb 2013 11:52: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 1UB22L-00057o-MN
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 11:52:34 +0000
Received: from [85.158.137.99:2469] by server-4.bemta-3.messagelabs.com id
	F7/6A-21470-0054F215; Thu, 28 Feb 2013 11:52:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362052345!13066578!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32052 invoked from network); 28 Feb 2013 11:52:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:52:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2019743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11: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.297.1; Thu, 28 Feb 2013 11:51:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB21E-0005GE-LZ; Thu, 28 Feb 2013 11:51:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB21E-0004Wq-G2;
	Thu, 28 Feb 2013 11:51:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.17596.210245.887390@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 11:51:24 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [Xen 4.1 PATCH] Add .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

commit 8b5e82064759e5fdc5bd41e8b5a1aca92c6527df
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Feb 28 11:50:08 2013 +0000

    Add .gitignore
    
    Copy .gitignore from staging-4.2 current tip
    (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e).
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..776e4b2
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,394 @@
+.hg
+*.orig
+*.rej
+*~
+*.o
+*.d
+*.opic
+*.a
+*.so
+*.so.[0-9]*
+*.bin
+*.bak
+*.tmp
+*.spot
+*.spit
+TAGS
+cscope.files
+cscope.in.out
+cscope.out
+cscope.po.out
+.config
+
+dist
+stubdom/*.tar.gz
+
+build-*
+dist/*
+docs/*.aux
+docs/*.dvi
+docs/*.log
+docs/*.pdf
+docs/*.ps
+docs/*.toc
+docs/api/*
+docs/figs/xenserver.eps
+docs/html/*
+docs/interface/WARNINGS
+docs/interface/images.pl
+docs/interface/images.tex
+docs/interface/img1.png
+docs/interface/index.html
+docs/interface/interface.css
+docs/interface/interface.html
+docs/interface/labels.pl
+docs/man1/
+docs/man5/
+docs/pdf/*
+docs/ps/*
+docs/user/WARNINGS
+docs/user/images.pl
+docs/user/images.tex
+docs/user/img1.png
+docs/user/img2.png
+docs/user/img3.png
+docs/user/index.html
+docs/user/internals.pl
+docs/user/labels.pl
+docs/user/user.css
+docs/user/user.html
+docs/xen-api/vm_lifecycle.eps
+docs/xen-api/xenapi-datamodel-graph.eps
+docs/xen-api/xenapi.out
+docs/xen-api/xenapi.dvi
+docs/xen-api/xenapi.pdf
+docs/xen-api/xenapi.ps
+docs/xen-api/xenapi.toc
+extras/mini-os/arch/ia64/gen_off.s
+extras/mini-os/include/mini-os
+extras/mini-os/include/ia64/mini-os
+extras/mini-os/include/ia64/offsets.h
+extras/mini-os/include/x86/mini-os
+extras/mini-os/include/xen
+extras/mini-os/include/list.h
+extras/mini-os/mini-os*
+install/*
+linux-[^/]*-paravirt/*
+linux-2.6[^/]*/*
+linux-[^/]*-rc/*
+linux-[^/]*-tip/*
+linux-[^/]*-git/*
+linux-[^/]*.patch
+mkddbxen
+netbsd-[^/]*-tools/*
+netbsd-[^/]*-xen0/*
+netbsd-[^/]*-xenU/*
+netbsd-[^/]*.patch
+patches/*/.makedep
+patches/ebtables-brnf-5_vs_2.4.25.diff
+patches/ebtables.diff
+patches/tmp/*
+pristine-*
+ref-*
+tmp-*
+stubdom/binutils-*
+stubdom/cross-root-*
+stubdom/gcc-*
+stubdom/include
+stubdom/ioemu
+stubdom/xenstore
+stubdom/libxc-*
+stubdom/lwip-*
+stubdom/mini-os-*
+stubdom/mk-headers-*
+stubdom/newlib-1.*
+stubdom/newlib-x86*
+stubdom/pciutils-*
+stubdom/zlib-*
+stubdom/grub-*
+stubdom/ocaml-*
+stubdom/lwip/
+stubdom/ioemu/
+stubdom/stubdompath.sh
+tools/*/build/lib*/*.py
+tools/autom4te.cache
+tools/config.h
+tools/config.log
+tools/config.status
+tools/config.cache
+config/Tools.mk
+tools/blktap2/daemon/blktapctrl
+tools/blktap2/drivers/img2qcow
+tools/blktap2/drivers/lock-util
+tools/blktap2/drivers/qcow-create
+tools/blktap2/drivers/qcow2raw
+tools/blktap2/drivers/tapdisk
+tools/blktap2/drivers/tapdisk-client
+tools/blktap2/drivers/tapdisk-diff
+tools/blktap2/drivers/tapdisk-stream
+tools/blktap2/drivers/tapdisk2
+tools/blktap2/drivers/td-util
+tools/blktap2/vhd/vhd-update
+tools/blktap2/vhd/vhd-util
+tools/blktap/drivers/blktapctrl
+tools/blktap/drivers/img2qcow
+tools/blktap/drivers/qcow-create
+tools/blktap/drivers/qcow2raw
+tools/blktap/drivers/tapdisk
+tools/check/.*
+tools/console/xenconsole
+tools/console/xenconsoled
+tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
+tools/debugger/gdb/gdb-6.2.1/*
+tools/debugger/gdb/gdb-6.2.1.tar.bz2
+tools/debugger/gdbsx/gdbsx
+tools/debugger/xenitp/xenitp
+tools/firmware/*/biossums
+tools/firmware/*.bin
+tools/firmware/*.sym
+tools/firmware/*bios/*bios*.txt
+tools/firmware/etherboot/gpxe/*
+tools/firmware/extboot/extboot.img
+tools/firmware/extboot/signrom
+tools/firmware/hvmloader/acpi/mk_dsdt
+tools/firmware/hvmloader/acpi/dsdt*.c
+tools/firmware/hvmloader/acpi/dsdt*.asl
+tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/roms.h
+tools/firmware/hvmloader/roms.inc
+tools/firmware/rombios/BIOS-bochs-[^/]*
+tools/firmware/rombios/_rombios[^/]*_.c
+tools/firmware/rombios/rombios[^/]*.s
+tools/firmware/rombios/32bit/32bitbios_flat.h
+tools/firmware/vgabios/vbetables-gen
+tools/firmware/vgabios/vbetables.h
+tools/flask/utils/flask-getenforce
+tools/flask/utils/flask-get-bool
+tools/flask/utils/flask-loadpolicy
+tools/flask/utils/flask-setenforce
+tools/flask/utils/flask-set-bool
+tools/flask/utils/flask-label-pci
+tools/fs-back/fs-backend
+tools/hotplug/common/hotplugpath.sh
+tools/include/xen/*
+tools/include/xen-foreign/*.(c|h|size)
+tools/include/xen-foreign/checker
+tools/libxc/ia64/asm/*.h
+tools/libxc/ia64/acpi/*.h
+tools/libxc/ia64/acpi/platform/*.h
+tools/libxc/ia64/dom_fw_asm.S
+tools/libxc/ia64/dom_fw_common.c
+tools/libxc/ia64/dom_fw_domu.c
+tools/libxc/ia64/xen/*.h
+tools/libxen/libxenapi-
+tools/libxen/test/test_bindings
+tools/libxen/test/test_event_handling
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/xl
+tools/libxl/testenum
+tools/libxl/testenum.c
+tools/libxl/tmp.*
+tools/libxl/_libxl.api-for-check
+tools/libxl/*.api-ok
+tools/libaio/src/*.ol
+tools/libaio/src/*.os
+tools/misc/cpuperf/cpuperf-perfcntr
+tools/misc/cpuperf/cpuperf-xen
+tools/misc/lomount/lomount
+tools/misc/mbootpack/bin2c
+tools/misc/mbootpack/bootsect
+tools/misc/mbootpack/bzimage_header.c
+tools/misc/mbootpack/mbootpack
+tools/misc/mbootpack/setup
+tools/misc/miniterm/miniterm
+tools/misc/xc_shadow
+tools/misc/xen_cpuperf
+tools/misc/xen-detect
+tools/misc/xen-tmem-list-parse
+tools/misc/xenperf
+tools/misc/xenpm
+tools/misc/xen-hvmctx
+tools/misc/gtraceview
+tools/misc/gtracestat
+tools/misc/xenlockprof
+tools/misc/lowmemd
+tools/pygrub/build/*
+tools/python/build/*
+tools/python/xen/util/path.py
+tools/remus/imqebt/imqebt
+tools/remus/kmod/*(.cmd|.mod|.ko|.mod.c|.symvers|.xen)
+tools/security/secpol_tool
+tools/security/xen/*
+tools/security/xensec_tool
+tools/tests/blowfish.bin
+tools/tests/blowfish.h
+tools/tests/test_x86_emulator
+tools/tests/x86_emulate
+tools/tests/regression/installed/*
+tools/tests/regression/build/*
+tools/tests/regression/downloads/*
+tools/tests/mem-sharing/memshrtool
+tools/tests/mce-test/tools/xen-mceinj
+tools/vnet/Make.local
+tools/vnet/build/*
+tools/vnet/gc
+tools/vnet/gc*/*
+tools/vnet/vnet-module/*.ko
+tools/vnet/vnet-module/.*.cmd
+tools/vnet/vnet-module/.tmp_versions/*
+tools/vnet/vnet-module/vnet_module.mod.*
+tools/vnet/vnetd/vnetd
+tools/vtpm/tpm_emulator-*.tar.gz
+tools/vtpm/tpm_emulator/*
+tools/vtpm/vtpm/*
+tools/vtpm_manager/manager/vtpm_managerd
+tools/xcutils/lsevtchn
+tools/xcutils/xc_restore
+tools/xcutils/xc_save
+tools/xcutils/readnotes
+tools/xenfb/sdlfb
+tools/xenfb/vncfb
+tools/xenmon/xentrace_setmask
+tools/xenmon/xenbaked
+tools/xenpaging/xenpaging
+tools/xenpmd/xenpmd
+tools/xenstat/xentop/xentop
+tools/xenstore/testsuite/tmp/*
+tools/xenstore/init-xenstore-domain
+tools/xenstore/xen
+tools/xenstore/xenstore
+tools/xenstore/xenstore-chmod
+tools/xenstore/xenstore-exists
+tools/xenstore/xenstore-list
+tools/xenstore/xenstore-read
+tools/xenstore/xenstore-rm
+tools/xenstore/xenstore-write
+tools/xenstore/xenstore-control
+tools/xenstore/xenstore-ls
+tools/xenstore/xenstored
+tools/xenstore/xenstored_test
+tools/xenstore/xs_crashme
+tools/xenstore/xs_random
+tools/xenstore/xs_stress
+tools/xenstore/xs_tdb_dump
+tools/xenstore/xs_test
+tools/xenstore/xs_watch_stress
+tools/xentrace/xentrace_setsize
+tools/xentrace/tbctl
+tools/xentrace/xenctx
+tools/xentrace/xentrace
+tools/xm-test/ramdisk/buildroot
+tools/xm-test/aclocal.m4
+tools/xm-test/autom4te
+tools/xm-test/install-sh
+tools/xm-test/mkinstalldirs
+tools/xm-test/missing
+tools/xm-test/config(ure|.log|.status|.guess|.sub)
+tools/xm-test/Makefile(.in)*
+tools/xm-test/*/Makefile(.in)*
+tools/xm-test/lib/XmTestLib/config.py
+tools/xm-test/lib/XmTestReport/xmtest.py
+tools/xm-test/tests/*.test
+tools/ocaml-xenstored*
+xen/.banner*
+xen/BLOG
+xen/System.map
+xen/arch/arm/asm-offsets.s
+xen/arch/arm/xen.lds
+xen/arch/x86/asm-offsets.s
+xen/arch/x86/boot/mkelf32
+xen/arch/x86/xen.lds
+xen/arch/x86/boot/reloc.S
+xen/arch/x86/boot/reloc.bin
+xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/efi.lds
+xen/arch/x86/efi/disabled
+xen/arch/x86/efi/mkreloc
+xen/ddb/*
+xen/include/headers.chk
+xen/include/asm
+xen/include/asm-*/asm-offsets.h
+xen/include/asm-ia64/asm-xsi-offsets.h
+xen/include/asm-ia64/.offsets.h.stamp
+xen/include/asm-ia64/xen
+xen/include/compat/*
+xen/include/hypervisor-ifs/arch
+xen/include/linux
+xen/include/public/public
+xen/include/xen/*.new
+xen/include/xen/acm_policy.h
+xen/include/xen/banner.h
+xen/include/xen/compile.h
+xen/tools/figlet/figlet
+xen/tools/symbols
+xen/xen
+xen/xen-syms
+xen/xen.*
+xen/arch/ia64/asm-offsets.s
+xen/arch/ia64/asm-xsi-offsets.s
+xen/arch/ia64/map.out
+xen/arch/ia64/xen.lds.s
+unmodified_drivers/linux-2.6/.tmp_versions
+unmodified_drivers/linux-2.6/*.cmd
+unmodified_drivers/linux-2.6/*.ko
+unmodified_drivers/linux-2.6/*.mod.c
+LibVNCServer*
+
+tools/qemu-xen-dir-remote
+tools/qemu-xen-dir
+
+tools/qemu-xen-traditional-dir-remote
+tools/qemu-xen-traditional-dir
+
+tools/firmware/seabios-dir-remote
+tools/firmware/seabios-dir
+
+tools/firmware/rombios/_rombios_.c
+tools/firmware/rombios/rombios.s
+tools/firmware/rombios/rombios.sym
+tools/include/xen-foreign/checker.c
+tools/include/xen-foreign/ia64.h
+tools/include/xen-foreign/structs.pyc
+tools/include/xen-foreign/x86_32.h
+tools/include/xen-foreign/x86_64.h
+
+.git
+tools/misc/xen-hptool
+tools/libxl/_*.[ch]
+tools/libxl/testidl
+tools/libxl/testidl.c
+tools/libxl/*.pyc
+tools/libxl/libxl-save-helper
+tools/blktap2/control/tap-ctl
+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]
+tools/ocaml/*/*.cmxa
+tools/ocaml/*/*.annot
+tools/ocaml/*/*/.ocamldep.make
+tools/ocaml/*/*/*.cm[ixao]
+tools/ocaml/*/*/*.cmxa
+tools/ocaml/*/*/*.annot
+tools/ocaml/*/*/META
+tools/ocaml/libs/xl/_libxl_types.inc
+tools/ocaml/libs/xl/_libxl_types.ml.in
+tools/ocaml/libs/xl/_libxl_types.mli.in
+tools/ocaml/libs/xl/xenlight.ml
+tools/ocaml/libs/xl/xenlight.mli
+tools/ocaml/xenstored/oxenstored
+
+tools/debugger/kdd/kdd
+tools/firmware/etherboot/ipxe.tar.gz
+tools/firmware/etherboot/ipxe/
+tools/python/xen/lowlevel/xl/_pyxl_types.c
+tools/python/xen/lowlevel/xl/_pyxl_types.h
+tools/xenstore/xenstore-watch
+
+docs/txt/misc/*.txt
+docs/txt/man/*.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:52:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB22N-00057x-LV; Thu, 28 Feb 2013 11:52: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 1UB22L-00057o-MN
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 11:52:34 +0000
Received: from [85.158.137.99:2469] by server-4.bemta-3.messagelabs.com id
	F7/6A-21470-0054F215; Thu, 28 Feb 2013 11:52:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362052345!13066578!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32052 invoked from network); 28 Feb 2013 11:52:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:52:25 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2019743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11: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.297.1; Thu, 28 Feb 2013 11:51:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB21E-0005GE-LZ; Thu, 28 Feb 2013 11:51:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB21E-0004Wq-G2;
	Thu, 28 Feb 2013 11:51:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.17596.210245.887390@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 11:51:24 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [Xen 4.1 PATCH] Add .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

commit 8b5e82064759e5fdc5bd41e8b5a1aca92c6527df
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Feb 28 11:50:08 2013 +0000

    Add .gitignore
    
    Copy .gitignore from staging-4.2 current tip
    (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e).
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..776e4b2
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,394 @@
+.hg
+*.orig
+*.rej
+*~
+*.o
+*.d
+*.opic
+*.a
+*.so
+*.so.[0-9]*
+*.bin
+*.bak
+*.tmp
+*.spot
+*.spit
+TAGS
+cscope.files
+cscope.in.out
+cscope.out
+cscope.po.out
+.config
+
+dist
+stubdom/*.tar.gz
+
+build-*
+dist/*
+docs/*.aux
+docs/*.dvi
+docs/*.log
+docs/*.pdf
+docs/*.ps
+docs/*.toc
+docs/api/*
+docs/figs/xenserver.eps
+docs/html/*
+docs/interface/WARNINGS
+docs/interface/images.pl
+docs/interface/images.tex
+docs/interface/img1.png
+docs/interface/index.html
+docs/interface/interface.css
+docs/interface/interface.html
+docs/interface/labels.pl
+docs/man1/
+docs/man5/
+docs/pdf/*
+docs/ps/*
+docs/user/WARNINGS
+docs/user/images.pl
+docs/user/images.tex
+docs/user/img1.png
+docs/user/img2.png
+docs/user/img3.png
+docs/user/index.html
+docs/user/internals.pl
+docs/user/labels.pl
+docs/user/user.css
+docs/user/user.html
+docs/xen-api/vm_lifecycle.eps
+docs/xen-api/xenapi-datamodel-graph.eps
+docs/xen-api/xenapi.out
+docs/xen-api/xenapi.dvi
+docs/xen-api/xenapi.pdf
+docs/xen-api/xenapi.ps
+docs/xen-api/xenapi.toc
+extras/mini-os/arch/ia64/gen_off.s
+extras/mini-os/include/mini-os
+extras/mini-os/include/ia64/mini-os
+extras/mini-os/include/ia64/offsets.h
+extras/mini-os/include/x86/mini-os
+extras/mini-os/include/xen
+extras/mini-os/include/list.h
+extras/mini-os/mini-os*
+install/*
+linux-[^/]*-paravirt/*
+linux-2.6[^/]*/*
+linux-[^/]*-rc/*
+linux-[^/]*-tip/*
+linux-[^/]*-git/*
+linux-[^/]*.patch
+mkddbxen
+netbsd-[^/]*-tools/*
+netbsd-[^/]*-xen0/*
+netbsd-[^/]*-xenU/*
+netbsd-[^/]*.patch
+patches/*/.makedep
+patches/ebtables-brnf-5_vs_2.4.25.diff
+patches/ebtables.diff
+patches/tmp/*
+pristine-*
+ref-*
+tmp-*
+stubdom/binutils-*
+stubdom/cross-root-*
+stubdom/gcc-*
+stubdom/include
+stubdom/ioemu
+stubdom/xenstore
+stubdom/libxc-*
+stubdom/lwip-*
+stubdom/mini-os-*
+stubdom/mk-headers-*
+stubdom/newlib-1.*
+stubdom/newlib-x86*
+stubdom/pciutils-*
+stubdom/zlib-*
+stubdom/grub-*
+stubdom/ocaml-*
+stubdom/lwip/
+stubdom/ioemu/
+stubdom/stubdompath.sh
+tools/*/build/lib*/*.py
+tools/autom4te.cache
+tools/config.h
+tools/config.log
+tools/config.status
+tools/config.cache
+config/Tools.mk
+tools/blktap2/daemon/blktapctrl
+tools/blktap2/drivers/img2qcow
+tools/blktap2/drivers/lock-util
+tools/blktap2/drivers/qcow-create
+tools/blktap2/drivers/qcow2raw
+tools/blktap2/drivers/tapdisk
+tools/blktap2/drivers/tapdisk-client
+tools/blktap2/drivers/tapdisk-diff
+tools/blktap2/drivers/tapdisk-stream
+tools/blktap2/drivers/tapdisk2
+tools/blktap2/drivers/td-util
+tools/blktap2/vhd/vhd-update
+tools/blktap2/vhd/vhd-util
+tools/blktap/drivers/blktapctrl
+tools/blktap/drivers/img2qcow
+tools/blktap/drivers/qcow-create
+tools/blktap/drivers/qcow2raw
+tools/blktap/drivers/tapdisk
+tools/check/.*
+tools/console/xenconsole
+tools/console/xenconsoled
+tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
+tools/debugger/gdb/gdb-6.2.1/*
+tools/debugger/gdb/gdb-6.2.1.tar.bz2
+tools/debugger/gdbsx/gdbsx
+tools/debugger/xenitp/xenitp
+tools/firmware/*/biossums
+tools/firmware/*.bin
+tools/firmware/*.sym
+tools/firmware/*bios/*bios*.txt
+tools/firmware/etherboot/gpxe/*
+tools/firmware/extboot/extboot.img
+tools/firmware/extboot/signrom
+tools/firmware/hvmloader/acpi/mk_dsdt
+tools/firmware/hvmloader/acpi/dsdt*.c
+tools/firmware/hvmloader/acpi/dsdt*.asl
+tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/roms.h
+tools/firmware/hvmloader/roms.inc
+tools/firmware/rombios/BIOS-bochs-[^/]*
+tools/firmware/rombios/_rombios[^/]*_.c
+tools/firmware/rombios/rombios[^/]*.s
+tools/firmware/rombios/32bit/32bitbios_flat.h
+tools/firmware/vgabios/vbetables-gen
+tools/firmware/vgabios/vbetables.h
+tools/flask/utils/flask-getenforce
+tools/flask/utils/flask-get-bool
+tools/flask/utils/flask-loadpolicy
+tools/flask/utils/flask-setenforce
+tools/flask/utils/flask-set-bool
+tools/flask/utils/flask-label-pci
+tools/fs-back/fs-backend
+tools/hotplug/common/hotplugpath.sh
+tools/include/xen/*
+tools/include/xen-foreign/*.(c|h|size)
+tools/include/xen-foreign/checker
+tools/libxc/ia64/asm/*.h
+tools/libxc/ia64/acpi/*.h
+tools/libxc/ia64/acpi/platform/*.h
+tools/libxc/ia64/dom_fw_asm.S
+tools/libxc/ia64/dom_fw_common.c
+tools/libxc/ia64/dom_fw_domu.c
+tools/libxc/ia64/xen/*.h
+tools/libxen/libxenapi-
+tools/libxen/test/test_bindings
+tools/libxen/test/test_event_handling
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/xl
+tools/libxl/testenum
+tools/libxl/testenum.c
+tools/libxl/tmp.*
+tools/libxl/_libxl.api-for-check
+tools/libxl/*.api-ok
+tools/libaio/src/*.ol
+tools/libaio/src/*.os
+tools/misc/cpuperf/cpuperf-perfcntr
+tools/misc/cpuperf/cpuperf-xen
+tools/misc/lomount/lomount
+tools/misc/mbootpack/bin2c
+tools/misc/mbootpack/bootsect
+tools/misc/mbootpack/bzimage_header.c
+tools/misc/mbootpack/mbootpack
+tools/misc/mbootpack/setup
+tools/misc/miniterm/miniterm
+tools/misc/xc_shadow
+tools/misc/xen_cpuperf
+tools/misc/xen-detect
+tools/misc/xen-tmem-list-parse
+tools/misc/xenperf
+tools/misc/xenpm
+tools/misc/xen-hvmctx
+tools/misc/gtraceview
+tools/misc/gtracestat
+tools/misc/xenlockprof
+tools/misc/lowmemd
+tools/pygrub/build/*
+tools/python/build/*
+tools/python/xen/util/path.py
+tools/remus/imqebt/imqebt
+tools/remus/kmod/*(.cmd|.mod|.ko|.mod.c|.symvers|.xen)
+tools/security/secpol_tool
+tools/security/xen/*
+tools/security/xensec_tool
+tools/tests/blowfish.bin
+tools/tests/blowfish.h
+tools/tests/test_x86_emulator
+tools/tests/x86_emulate
+tools/tests/regression/installed/*
+tools/tests/regression/build/*
+tools/tests/regression/downloads/*
+tools/tests/mem-sharing/memshrtool
+tools/tests/mce-test/tools/xen-mceinj
+tools/vnet/Make.local
+tools/vnet/build/*
+tools/vnet/gc
+tools/vnet/gc*/*
+tools/vnet/vnet-module/*.ko
+tools/vnet/vnet-module/.*.cmd
+tools/vnet/vnet-module/.tmp_versions/*
+tools/vnet/vnet-module/vnet_module.mod.*
+tools/vnet/vnetd/vnetd
+tools/vtpm/tpm_emulator-*.tar.gz
+tools/vtpm/tpm_emulator/*
+tools/vtpm/vtpm/*
+tools/vtpm_manager/manager/vtpm_managerd
+tools/xcutils/lsevtchn
+tools/xcutils/xc_restore
+tools/xcutils/xc_save
+tools/xcutils/readnotes
+tools/xenfb/sdlfb
+tools/xenfb/vncfb
+tools/xenmon/xentrace_setmask
+tools/xenmon/xenbaked
+tools/xenpaging/xenpaging
+tools/xenpmd/xenpmd
+tools/xenstat/xentop/xentop
+tools/xenstore/testsuite/tmp/*
+tools/xenstore/init-xenstore-domain
+tools/xenstore/xen
+tools/xenstore/xenstore
+tools/xenstore/xenstore-chmod
+tools/xenstore/xenstore-exists
+tools/xenstore/xenstore-list
+tools/xenstore/xenstore-read
+tools/xenstore/xenstore-rm
+tools/xenstore/xenstore-write
+tools/xenstore/xenstore-control
+tools/xenstore/xenstore-ls
+tools/xenstore/xenstored
+tools/xenstore/xenstored_test
+tools/xenstore/xs_crashme
+tools/xenstore/xs_random
+tools/xenstore/xs_stress
+tools/xenstore/xs_tdb_dump
+tools/xenstore/xs_test
+tools/xenstore/xs_watch_stress
+tools/xentrace/xentrace_setsize
+tools/xentrace/tbctl
+tools/xentrace/xenctx
+tools/xentrace/xentrace
+tools/xm-test/ramdisk/buildroot
+tools/xm-test/aclocal.m4
+tools/xm-test/autom4te
+tools/xm-test/install-sh
+tools/xm-test/mkinstalldirs
+tools/xm-test/missing
+tools/xm-test/config(ure|.log|.status|.guess|.sub)
+tools/xm-test/Makefile(.in)*
+tools/xm-test/*/Makefile(.in)*
+tools/xm-test/lib/XmTestLib/config.py
+tools/xm-test/lib/XmTestReport/xmtest.py
+tools/xm-test/tests/*.test
+tools/ocaml-xenstored*
+xen/.banner*
+xen/BLOG
+xen/System.map
+xen/arch/arm/asm-offsets.s
+xen/arch/arm/xen.lds
+xen/arch/x86/asm-offsets.s
+xen/arch/x86/boot/mkelf32
+xen/arch/x86/xen.lds
+xen/arch/x86/boot/reloc.S
+xen/arch/x86/boot/reloc.bin
+xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/efi.lds
+xen/arch/x86/efi/disabled
+xen/arch/x86/efi/mkreloc
+xen/ddb/*
+xen/include/headers.chk
+xen/include/asm
+xen/include/asm-*/asm-offsets.h
+xen/include/asm-ia64/asm-xsi-offsets.h
+xen/include/asm-ia64/.offsets.h.stamp
+xen/include/asm-ia64/xen
+xen/include/compat/*
+xen/include/hypervisor-ifs/arch
+xen/include/linux
+xen/include/public/public
+xen/include/xen/*.new
+xen/include/xen/acm_policy.h
+xen/include/xen/banner.h
+xen/include/xen/compile.h
+xen/tools/figlet/figlet
+xen/tools/symbols
+xen/xen
+xen/xen-syms
+xen/xen.*
+xen/arch/ia64/asm-offsets.s
+xen/arch/ia64/asm-xsi-offsets.s
+xen/arch/ia64/map.out
+xen/arch/ia64/xen.lds.s
+unmodified_drivers/linux-2.6/.tmp_versions
+unmodified_drivers/linux-2.6/*.cmd
+unmodified_drivers/linux-2.6/*.ko
+unmodified_drivers/linux-2.6/*.mod.c
+LibVNCServer*
+
+tools/qemu-xen-dir-remote
+tools/qemu-xen-dir
+
+tools/qemu-xen-traditional-dir-remote
+tools/qemu-xen-traditional-dir
+
+tools/firmware/seabios-dir-remote
+tools/firmware/seabios-dir
+
+tools/firmware/rombios/_rombios_.c
+tools/firmware/rombios/rombios.s
+tools/firmware/rombios/rombios.sym
+tools/include/xen-foreign/checker.c
+tools/include/xen-foreign/ia64.h
+tools/include/xen-foreign/structs.pyc
+tools/include/xen-foreign/x86_32.h
+tools/include/xen-foreign/x86_64.h
+
+.git
+tools/misc/xen-hptool
+tools/libxl/_*.[ch]
+tools/libxl/testidl
+tools/libxl/testidl.c
+tools/libxl/*.pyc
+tools/libxl/libxl-save-helper
+tools/blktap2/control/tap-ctl
+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]
+tools/ocaml/*/*.cmxa
+tools/ocaml/*/*.annot
+tools/ocaml/*/*/.ocamldep.make
+tools/ocaml/*/*/*.cm[ixao]
+tools/ocaml/*/*/*.cmxa
+tools/ocaml/*/*/*.annot
+tools/ocaml/*/*/META
+tools/ocaml/libs/xl/_libxl_types.inc
+tools/ocaml/libs/xl/_libxl_types.ml.in
+tools/ocaml/libs/xl/_libxl_types.mli.in
+tools/ocaml/libs/xl/xenlight.ml
+tools/ocaml/libs/xl/xenlight.mli
+tools/ocaml/xenstored/oxenstored
+
+tools/debugger/kdd/kdd
+tools/firmware/etherboot/ipxe.tar.gz
+tools/firmware/etherboot/ipxe/
+tools/python/xen/lowlevel/xl/_pyxl_types.c
+tools/python/xen/lowlevel/xl/_pyxl_types.h
+tools/xenstore/xenstore-watch
+
+docs/txt/misc/*.txt
+docs/txt/man/*.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:53:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB23a-0005Fd-Az; Thu, 28 Feb 2013 11:53: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 1UB23Y-0005FR-Sx
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 11:53:49 +0000
Received: from [85.158.139.83:59767] by server-12.bemta-5.messagelabs.com id
	11/D4-11486-C454F215; Thu, 28 Feb 2013 11:53:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362052427!22232580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2706 invoked from network); 28 Feb 2013 11:53:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:53:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2020181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:53: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.297.1; Thu, 28 Feb 2013 11:53:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB23X-0005Gy-0H; Thu, 28 Feb 2013 11:53:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB23W-0004XA-S8;
	Thu, 28 Feb 2013 11:53:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.17738.662582.446216@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 11:53:46 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <512F36BA.4070101@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com> <512F36BA.4070101@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>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Stefan Bader <stefan.bader@canonical.com>,
	Alex Bligh <alex@alex.org.uk>, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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 v2] tools: Improve make deb"):
> Alex, what do you think about Ian's suggestion -- i.e., rather than 
> integrate a full-featured .deb package into the Xen build system, 
> intermittently use the Debian Xen target to create a set of .debs and 
> make them available publicly somewhere?

I think this is a good idea and should perhaps even be done nightly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:53:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB23a-0005Fd-Az; Thu, 28 Feb 2013 11:53: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 1UB23Y-0005FR-Sx
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 11:53:49 +0000
Received: from [85.158.139.83:59767] by server-12.bemta-5.messagelabs.com id
	11/D4-11486-C454F215; Thu, 28 Feb 2013 11:53:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362052427!22232580!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2706 invoked from network); 28 Feb 2013 11:53:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 11:53:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2020181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 11:53: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.297.1; Thu, 28 Feb 2013 11:53:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB23X-0005Gy-0H; Thu, 28 Feb 2013 11:53:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB23W-0004XA-S8;
	Thu, 28 Feb 2013 11:53:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.17738.662582.446216@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 11:53:46 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <512F36BA.4070101@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com> <512F36BA.4070101@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>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Stefan Bader <stefan.bader@canonical.com>,
	Alex Bligh <alex@alex.org.uk>, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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 v2] tools: Improve make deb"):
> Alex, what do you think about Ian's suggestion -- i.e., rather than 
> integrate a full-featured .deb package into the Xen build system, 
> intermittently use the Debian Xen target to create a set of .debs and 
> make them available publicly somewhere?

I think this is a good idea and should perhaps even be done nightly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:55:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:55: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 1UB25R-0005Pn-S9; Thu, 28 Feb 2013 11:55:45 +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 1UB25Q-0005Pe-JQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:55:44 +0000
Received: from [85.158.143.99:30726] by server-2.bemta-4.messagelabs.com id
	8B/DD-12656-FB54F215; Thu, 28 Feb 2013 11:55:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1362052533!18170463!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13295 invoked from network); 28 Feb 2013 11:55:35 -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;
	28 Feb 2013 11:55:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9740229"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:55:33 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:55:32 -0500
Message-ID: <512F45B4.2000105@citrix.com>
Date: Thu, 28 Feb 2013 11:55:32 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-8-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-8-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 07/22] Add evtchn_extended in struct
	domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> This field is a bitmap of currently in use extended event channel ABI, which
> can have 0 (no extended event channel in use) 1 bit set. It is manipulated by
> hypervisor only, so if anything goes wrong it is a bug.
> 
> The default event channel ABI is EVTCHN_EXTENDED_NONE, which means no extended
> event channel is used.
[...]
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -14,6 +14,7 @@
>  #include <xen/softirq.h>
>  #include <asm/bitops.h>
>  #include <asm/event.h>
> +#include <public/event_channel.h>
>  
>  #ifndef CONFIG_COMPAT
>  #define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
> @@ -22,7 +23,16 @@
>  #endif
>  static inline unsigned int max_evtchns(struct domain *d)
>  {
> -    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> +    unsigned int ret = 0;
> +    switch ( d->evtchn_extended )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +        ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> +        break;
> +    default:
> +        BUG();
> +    }

BUG'ing in every switch that uses d->evtchn_extended doesn't seem useful
and may add extra overhead in hot paths.

Perhaps an ASSERT() but this this field is written in such a limited set
of places this doesn't seem useful.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:55:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11:55: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 1UB25R-0005Pn-S9; Thu, 28 Feb 2013 11:55:45 +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 1UB25Q-0005Pe-JQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:55:44 +0000
Received: from [85.158.143.99:30726] by server-2.bemta-4.messagelabs.com id
	8B/DD-12656-FB54F215; Thu, 28 Feb 2013 11:55:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1362052533!18170463!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13295 invoked from network); 28 Feb 2013 11:55:35 -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;
	28 Feb 2013 11:55:35 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9740229"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:55:33 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:55:32 -0500
Message-ID: <512F45B4.2000105@citrix.com>
Date: Thu, 28 Feb 2013 11:55:32 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-8-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-8-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 07/22] Add evtchn_extended in struct
	domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> This field is a bitmap of currently in use extended event channel ABI, which
> can have 0 (no extended event channel in use) 1 bit set. It is manipulated by
> hypervisor only, so if anything goes wrong it is a bug.
> 
> The default event channel ABI is EVTCHN_EXTENDED_NONE, which means no extended
> event channel is used.
[...]
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -14,6 +14,7 @@
>  #include <xen/softirq.h>
>  #include <asm/bitops.h>
>  #include <asm/event.h>
> +#include <public/event_channel.h>
>  
>  #ifndef CONFIG_COMPAT
>  #define BITS_PER_EVTCHN_WORD(d) BITS_PER_LONG
> @@ -22,7 +23,16 @@
>  #endif
>  static inline unsigned int max_evtchns(struct domain *d)
>  {
> -    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> +    unsigned int ret = 0;
> +    switch ( d->evtchn_extended )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +        ret = BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> +        break;
> +    default:
> +        BUG();
> +    }

BUG'ing in every switch that uses d->evtchn_extended doesn't seem useful
and may add extra overhead in hot paths.

Perhaps an ASSERT() but this this field is written in such a limited set
of places this doesn't seem useful.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:56:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB25u-0005Sn-Au; Thu, 28 Feb 2013 11:56:14 +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 1UB25s-0005SY-C3
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:56:12 +0000
Received: from [85.158.138.51:24590] by server-3.bemta-3.messagelabs.com id
	ED/F1-26934-BD54F215; Thu, 28 Feb 2013 11:56:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362052569!10977788!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14204 invoked from network); 28 Feb 2013 11:56:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:56:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB25m-0007Yw-92; Thu, 28 Feb 2013 11:56:06 +0000
Date: Thu, 28 Feb 2013 11:56:06 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20130228115606.GD27704@ocelot.phlegethon.org>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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

At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
> >>>> On 22.02.13 at 21:07, Olaf Hering <olaf@aepfle.de> wrote:
> >> On Fri, Feb 22, Jan Beulich wrote:
> >> 
> >>>>>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> >>>> It did not happen with xl.
> >>> 
> >>> But the same guest and Dom0 kernel, and the same hypervisor?
> >> 
> >> Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.
> >> 
> >>>> Here is the output while doing xm migrate:
> >>>> 
> >>>> (XEN) HVM2 restore: VMCE_VCPU 0
> >>>> (XEN) HVM2 restore: VMCE_VCPU 1
> >>>> (XEN) HVM2 restore: TSC_ADJUST 0
> >>>> (XEN) HVM2 restore: TSC_ADJUST 1
> >>>> (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, 
> >> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> >>> 
> >>> Didn't even notice yesterday that this is apparently after restore
> >>> has already started. Which makes me curious whether the domain
> >>> that is being referenced with rd= is the old or the new one (would
> >>> require printing the domain ID; honestly I never understood what
> >>> use printing of the domain pointer is).
> >>> 
> >>> I'm also confused by the domain pointer always being the same;
> >>> I would expect it to at least toggle between two values, but
> >>> probably even be different between every instance of the guest.
> >>> But you're not having a stubdom configured for the guest either,
> >>> according to the config you sent earlier...
> >> 
> >> The rd->domain_id is DOMID_COW in both cases.
> > 
> > Which suggests that memory sharing is in use. At least I'm unaware
> > of other uses of that pseudo domain.
> 
> There are none.
> 
> There seems to be something else amiss though. Unless I am parsing
> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
> | PCD? Looks like a very unlikely combination

By my reading, 

taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
caf = 0x0180000000000000 = refcount 0, PGC_state_free

iow this is a free page but somehow has ended up with a typecount (which
explains why the get_page() failed).  And presumably this is one of the
various get_page[_and_type](page, dom_cow) calls in mem_sharing.c.

Since free_domheap_pages() has a BUG_ON(typecount != 0), it seems like
something's gone badly off the rails here. 

One place I can see that tinkers with typecount without holding a
ref is share_xen_page_with_guest(), which sets exactly this typecount,
but then calls page_set_owner(page, d).

There's some hairy code in __gnttab_map_grant_ref() too, but I _think_
it can't end up taking typecounts without refcounts.

__acquire_grant_for_copy() looks pretty hairy too, in particular this:
        (void)page_get_owner_and_reference(*page);
 but presumably the matching put_page() would have crashed if that was
the problem.  Does anyone understand the grant code well enough to get
into that?

If you can repro this, it might be worth tracing all the refcount ops
into a large buffer and dumping the history of this MFN on failure.

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 Feb 28 11:56:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 11: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 1UB25u-0005Sn-Au; Thu, 28 Feb 2013 11:56:14 +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 1UB25s-0005SY-C3
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:56:12 +0000
Received: from [85.158.138.51:24590] by server-3.bemta-3.messagelabs.com id
	ED/F1-26934-BD54F215; Thu, 28 Feb 2013 11:56:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362052569!10977788!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14204 invoked from network); 28 Feb 2013 11:56:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 11:56:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB25m-0007Yw-92; Thu, 28 Feb 2013 11:56:06 +0000
Date: Thu, 28 Feb 2013 11:56:06 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20130228115606.GD27704@ocelot.phlegethon.org>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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

At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
> >>>> On 22.02.13 at 21:07, Olaf Hering <olaf@aepfle.de> wrote:
> >> On Fri, Feb 22, Jan Beulich wrote:
> >> 
> >>>>>> On 21.02.13 at 18:31, Olaf Hering <olaf@aepfle.de> wrote:
> >>>> It did not happen with xl.
> >>> 
> >>> But the same guest and Dom0 kernel, and the same hypervisor?
> >> 
> >> Yes, same sles11sp2 dom0, and 3.7.9 pvops guest.
> >> 
> >>>> Here is the output while doing xm migrate:
> >>>> 
> >>>> (XEN) HVM2 restore: VMCE_VCPU 0
> >>>> (XEN) HVM2 restore: VMCE_VCPU 1
> >>>> (XEN) HVM2 restore: TSC_ADJUST 0
> >>>> (XEN) HVM2 restore: TSC_ADJUST 1
> >>>> (XEN) mm.c:1983:d0 Error pfn 4112c5: rd=ffff83036ffef000, 
> >> od=0000000000000000, caf=180000000000000, taf=7400000000000001
> >>> 
> >>> Didn't even notice yesterday that this is apparently after restore
> >>> has already started. Which makes me curious whether the domain
> >>> that is being referenced with rd= is the old or the new one (would
> >>> require printing the domain ID; honestly I never understood what
> >>> use printing of the domain pointer is).
> >>> 
> >>> I'm also confused by the domain pointer always being the same;
> >>> I would expect it to at least toggle between two values, but
> >>> probably even be different between every instance of the guest.
> >>> But you're not having a stubdom configured for the guest either,
> >>> according to the config you sent earlier...
> >> 
> >> The rd->domain_id is DOMID_COW in both cases.
> > 
> > Which suggests that memory sharing is in use. At least I'm unaware
> > of other uses of that pseudo domain.
> 
> There are none.
> 
> There seems to be something else amiss though. Unless I am parsing
> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
> | PCD? Looks like a very unlikely combination

By my reading, 

taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
caf = 0x0180000000000000 = refcount 0, PGC_state_free

iow this is a free page but somehow has ended up with a typecount (which
explains why the get_page() failed).  And presumably this is one of the
various get_page[_and_type](page, dom_cow) calls in mem_sharing.c.

Since free_domheap_pages() has a BUG_ON(typecount != 0), it seems like
something's gone badly off the rails here. 

One place I can see that tinkers with typecount without holding a
ref is share_xen_page_with_guest(), which sets exactly this typecount,
but then calls page_set_owner(page, d).

There's some hairy code in __gnttab_map_grant_ref() too, but I _think_
it can't end up taking typecounts without refcounts.

__acquire_grant_for_copy() looks pretty hairy too, in particular this:
        (void)page_get_owner_and_reference(*page);
 but presumably the matching put_page() would have crashed if that was
the problem.  Does anyone understand the grant code well enough to get
into that?

If you can repro this, it might be worth tracing all the refcount ops
into a large buffer and dumping the history of this MFN on failure.

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 Feb 28 11:59:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB28W-0005j3-Uq; Thu, 28 Feb 2013 11:58:56 +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 1UB28W-0005ix-B0
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:58:56 +0000
Received: from [193.109.254.147:8478] by server-7.bemta-14.messagelabs.com id
	62/C1-13581-F764F215; Thu, 28 Feb 2013 11:58:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362052682!6349061!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13603 invoked from network); 28 Feb 2013 11:58:04 -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;
	28 Feb 2013 11:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10242961"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:58:02 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:58:01 -0500
Message-ID: <512F4648.3020800@citrix.com>
Date: Thu, 28 Feb 2013 11:58:00 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to
 max_evtchns inline 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

On 27/02/13 14:33, Wei Liu wrote:
> The calculation of max event channels depends on the actual ABI in use. Try to
> avoid gcc-ism macro.
[...]
> +static inline unsigned int max_evtchns(struct domain *d)
> +{
> +    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> +}

This value doesn't change over the life of the domain. Calculate it once
and save it in a new d->max_evtchns field?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 11:59:06 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB28W-0005j3-Uq; Thu, 28 Feb 2013 11:58:56 +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 1UB28W-0005ix-B0
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 11:58:56 +0000
Received: from [193.109.254.147:8478] by server-7.bemta-14.messagelabs.com id
	62/C1-13581-F764F215; Thu, 28 Feb 2013 11:58:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362052682!6349061!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13603 invoked from network); 28 Feb 2013 11:58:04 -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;
	28 Feb 2013 11:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10242961"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 11:58:02 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 06:58:01 -0500
Message-ID: <512F4648.3020800@citrix.com>
Date: Thu, 28 Feb 2013 11:58:00 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to
 max_evtchns inline 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

On 27/02/13 14:33, Wei Liu wrote:
> The calculation of max event channels depends on the actual ABI in use. Try to
> avoid gcc-ism macro.
[...]
> +static inline unsigned int max_evtchns(struct domain *d)
> +{
> +    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> +}

This value doesn't change over the life of the domain. Calculate it once
and save it in a new d->max_evtchns field?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:00:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:00: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 1UB29u-0005sY-CG; Thu, 28 Feb 2013 12:00:22 +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 1UB29s-0005sC-Rs
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:00:20 +0000
Received: from [85.158.139.211:27253] by server-10.bemta-5.messagelabs.com id
	3B/3F-23714-3D64F215; Thu, 28 Feb 2013 12:00:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362052814!18883970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5291 invoked from network); 28 Feb 2013 12:00:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10243307"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:00:14 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:00:13 -0500
Message-ID: <512F46CC.50306@citrix.com>
Date: Thu, 28 Feb 2013 12:00:12 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-12-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-12-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 11/22] Update Xen public header
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:

"Update Xen public header"

Which header?  Updated how and why?  This subject and commit message
needs to be more descriptive.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:00:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:00: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 1UB29u-0005sY-CG; Thu, 28 Feb 2013 12:00:22 +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 1UB29s-0005sC-Rs
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:00:20 +0000
Received: from [85.158.139.211:27253] by server-10.bemta-5.messagelabs.com id
	3B/3F-23714-3D64F215; Thu, 28 Feb 2013 12:00:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362052814!18883970!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5291 invoked from network); 28 Feb 2013 12:00:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10243307"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:00:14 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:00:13 -0500
Message-ID: <512F46CC.50306@citrix.com>
Date: Thu, 28 Feb 2013 12:00:12 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-12-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-12-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 11/22] Update Xen public header
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:

"Update Xen public header"

Which header?  Updated how and why?  This subject and commit message
needs to be more descriptive.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:01:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2Av-00060e-RI; Thu, 28 Feb 2013 12:01:25 +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 1UB2At-00060D-QC
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:01:24 +0000
Received: from [85.158.139.83:12237] by server-4.bemta-5.messagelabs.com id
	C2/F0-01980-1174F215; Thu, 28 Feb 2013 12:01:21 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362052854!22234117!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11524 invoked from network); 28 Feb 2013 12:00:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2020738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 12:00:54 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 28 Feb 2013 12:00:54 +0000
Message-ID: <512F46F5.5040105@citrix.com>
Date: Thu, 28 Feb 2013 13:00:53 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-13-git-send-email-roger.pau@citrix.com>
	<512F4B4402000078000C1E5B@nat28.tlf.novell.com>
In-Reply-To: <512F4B4402000078000C1E5B@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
	descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 12:19, Jan Beulich wrote:
>>>> On 28.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
>> @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t;
>>   */
>>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>>  
>> +#define BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST 8
>> +
>> +struct blkif_request_segment_aligned {
>> +	grant_ref_t gref;        /* reference to I/O buffer frame        */
>> +	/* @first_sect: first sector in frame to transfer (inclusive).   */
>> +	/* @last_sect: last sector in frame to transfer (inclusive).     */
>> +	uint8_t     first_sect, last_sect;
>> +	uint16_t    _pad; /* padding to make it 8 bytes, so it's cache-aligned */
>> +} __attribute__((__packed__));
> 
> What's the __packed__ for here?

Yes, that's not needed.

> 
>> +
>>  struct blkif_request_rw {
>>  	uint8_t        nr_segments;  /* number of segments                   */
>>  	blkif_vdev_t   handle;       /* only for read/write requests         */
>> @@ -138,11 +150,24 @@ struct blkif_request_discard {
>>  	uint8_t        _pad3;
>>  } __attribute__((__packed__));
>>  
>> +struct blkif_request_indirect {
>> +	uint8_t        indirect_op;
>> +	uint16_t       nr_segments;
>> +#ifdef CONFIG_X86_64
>> +	uint32_t       _pad1;        /* offsetof(blkif_...,u.indirect.id) == 8 */
>> +#endif
> 
> Either you want the structure be packed tightly (and you don't care
> about misaligned fields), in which case you shouldn't need a padding
> field. That's even more so as there's no padding between indirect_op
> and nr_segments, so everything is misaligned anyway, and the
> comment above is wrong too (offsetof() really ought to yield 7 in
> that case).

This padding is because we want to have the "id" field at the same
position as blkif_request_rw, so we need to add the padding for it to
match 32 & 64 bit blkif_request_rw structures, this prevents adding some
"if (req.op == BLKIF_OP_INDIRECT)..." if we only need to get the id of
the request.

The comment is indeed wrong, I've copied it from blkif_request_discard
and forgot to change the offset

> 
> Or you want the structure fields aligned, in which case you again
> ought to drop the use of the __packed__ attribute and introduce
> _all_ necessary padding fields.
> 
>> +	uint64_t       id;
>> +	blkif_vdev_t   handle;
>> +	blkif_sector_t sector_number;
>> +	grant_ref_t    indirect_grefs[BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST];
>> +} __attribute__((__packed__));
> 
> And then it would be quite nice for new features to no longer
> require translation between a 32- and a 64-bit layout at all.

The translation is caused by the id issue described above.

> Plus, rather than introducing uninitialized padding fields, I'd
> suggest using fields that are required to be zero initialized, to
> allow giving them a meaning later.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:01:35 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2Av-00060e-RI; Thu, 28 Feb 2013 12:01:25 +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 1UB2At-00060D-QC
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:01:24 +0000
Received: from [85.158.139.83:12237] by server-4.bemta-5.messagelabs.com id
	C2/F0-01980-1174F215; Thu, 28 Feb 2013 12:01:21 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362052854!22234117!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11524 invoked from network); 28 Feb 2013 12:00:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2020738"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 12:00:54 +0000
Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.297.1;
	Thu, 28 Feb 2013 12:00:54 +0000
Message-ID: <512F46F5.5040105@citrix.com>
Date: Thu, 28 Feb 2013 13:00:53 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-13-git-send-email-roger.pau@citrix.com>
	<512F4B4402000078000C1E5B@nat28.tlf.novell.com>
In-Reply-To: <512F4B4402000078000C1E5B@nat28.tlf.novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
	descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 12:19, Jan Beulich wrote:
>>>> On 28.02.13 at 11:28, Roger Pau Monne <roger.pau@citrix.com> wrote:
>> @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t;
>>   */
>>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>>  
>> +#define BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST 8
>> +
>> +struct blkif_request_segment_aligned {
>> +	grant_ref_t gref;        /* reference to I/O buffer frame        */
>> +	/* @first_sect: first sector in frame to transfer (inclusive).   */
>> +	/* @last_sect: last sector in frame to transfer (inclusive).     */
>> +	uint8_t     first_sect, last_sect;
>> +	uint16_t    _pad; /* padding to make it 8 bytes, so it's cache-aligned */
>> +} __attribute__((__packed__));
> 
> What's the __packed__ for here?

Yes, that's not needed.

> 
>> +
>>  struct blkif_request_rw {
>>  	uint8_t        nr_segments;  /* number of segments                   */
>>  	blkif_vdev_t   handle;       /* only for read/write requests         */
>> @@ -138,11 +150,24 @@ struct blkif_request_discard {
>>  	uint8_t        _pad3;
>>  } __attribute__((__packed__));
>>  
>> +struct blkif_request_indirect {
>> +	uint8_t        indirect_op;
>> +	uint16_t       nr_segments;
>> +#ifdef CONFIG_X86_64
>> +	uint32_t       _pad1;        /* offsetof(blkif_...,u.indirect.id) == 8 */
>> +#endif
> 
> Either you want the structure be packed tightly (and you don't care
> about misaligned fields), in which case you shouldn't need a padding
> field. That's even more so as there's no padding between indirect_op
> and nr_segments, so everything is misaligned anyway, and the
> comment above is wrong too (offsetof() really ought to yield 7 in
> that case).

This padding is because we want to have the "id" field at the same
position as blkif_request_rw, so we need to add the padding for it to
match 32 & 64 bit blkif_request_rw structures, this prevents adding some
"if (req.op == BLKIF_OP_INDIRECT)..." if we only need to get the id of
the request.

The comment is indeed wrong, I've copied it from blkif_request_discard
and forgot to change the offset

> 
> Or you want the structure fields aligned, in which case you again
> ought to drop the use of the __packed__ attribute and introduce
> _all_ necessary padding fields.
> 
>> +	uint64_t       id;
>> +	blkif_vdev_t   handle;
>> +	blkif_sector_t sector_number;
>> +	grant_ref_t    indirect_grefs[BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST];
>> +} __attribute__((__packed__));
> 
> And then it would be quite nice for new features to no longer
> require translation between a 32- and a 64-bit layout at all.

The translation is caused by the id issue described above.

> Plus, rather than introducing uninitialized padding fields, I'd
> suggest using fields that are required to be zero initialized, to
> allow giving them a meaning later.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:11:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2Kj-0006Tb-1f; Thu, 28 Feb 2013 12:11: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 1UB2Kh-0006TW-93
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 12:11:31 +0000
Received: from [85.158.143.99:25347] by server-2.bemta-4.messagelabs.com id
	38/21-12656-2794F215; Thu, 28 Feb 2013 12:11:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1362053488!19863479!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5085 invoked from network); 28 Feb 2013 12:11:29 -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;
	28 Feb 2013 12:11:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9743633"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:11:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:11:28 -0500
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 1UB2Kd-0008SG-Mz;
	Thu, 28 Feb 2013 12:11:27 +0000
Message-ID: <512F4798.6040305@eu.citrix.com>
Date: Thu, 28 Feb 2013 12:03:36 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com>	<512F36BA.4070101@eu.citrix.com>
	<20783.17738.662582.446216@mariner.uk.xensource.com>
In-Reply-To: <20783.17738.662582.446216@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Stefan Bader <stefan.bader@canonical.com>,
	Alex Bligh <alex@alex.org.uk>, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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-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 28/02/13 11:53, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
>> Alex, what do you think about Ian's suggestion -- i.e., rather than
>> integrate a full-featured .deb package into the Xen build system,
>> intermittently use the Debian Xen target to create a set of .debs and
>> make them available publicly somewhere?
> I think this is a good idea and should perhaps even be done nightly.

You're suggesting integrating it into the automated build system, I presume?

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:11:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2Kj-0006Tb-1f; Thu, 28 Feb 2013 12:11: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 1UB2Kh-0006TW-93
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 12:11:31 +0000
Received: from [85.158.143.99:25347] by server-2.bemta-4.messagelabs.com id
	38/21-12656-2794F215; Thu, 28 Feb 2013 12:11:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1362053488!19863479!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5085 invoked from network); 28 Feb 2013 12:11:29 -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;
	28 Feb 2013 12:11:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9743633"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:11:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:11:28 -0500
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 1UB2Kd-0008SG-Mz;
	Thu, 28 Feb 2013 12:11:27 +0000
Message-ID: <512F4798.6040305@eu.citrix.com>
Date: Thu, 28 Feb 2013 12:03:36 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com>	<512F36BA.4070101@eu.citrix.com>
	<20783.17738.662582.446216@mariner.uk.xensource.com>
In-Reply-To: <20783.17738.662582.446216@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Stefan Bader <stefan.bader@canonical.com>,
	Alex Bligh <alex@alex.org.uk>, Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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-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 28/02/13 11:53, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
>> Alex, what do you think about Ian's suggestion -- i.e., rather than
>> integrate a full-featured .deb package into the Xen build system,
>> intermittently use the Debian Xen target to create a set of .debs and
>> make them available publicly somewhere?
> I think this is a good idea and should perhaps even be done nightly.

You're suggesting integrating it into the automated build system, I presume?

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:16:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:16: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 1UB2Pd-0006m9-Q8; Thu, 28 Feb 2013 12:16:37 +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 1UB2Pc-0006m3-Qv
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:16:37 +0000
Received: from [85.158.138.51:45956] by server-13.bemta-3.messagelabs.com id
	C6/D1-25744-E9A4F215; Thu, 28 Feb 2013 12:16:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362053781!27902654!1
X-Originating-IP: [209.85.210.169]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19689 invoked from network); 28 Feb 2013 12:16:22 -0000
Received: from mail-ia0-f169.google.com (HELO mail-ia0-f169.google.com)
	(209.85.210.169)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:16:22 -0000
Received: by mail-ia0-f169.google.com with SMTP id j5so1451657iaf.14
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 04:16:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cl0g7HGOjBwVJ2gzbCshpb/8J8DSfZYyhY2cBvgIRQ0=;
	b=OXfUKcdO1zRPG3+BKuZ9cqQOmTy2QJmMXZRKZuBN0Tfk4C8BwE+p4WSWpGBSR1lNJg
	Usp5El8Ly7Eq5YZOT8rwMT/jgiXGvUflrtbZfwyZSzVcJE2uHNmKVdq2q1Nj7kzv8Lzc
	siGG3GP4a/x5F52rtzHp+u48PoxUPhOwnmKfdtCmfc7IYwbsjXSSpeloLk7K99rcLVZJ
	v257AJ71Wtlnk8cDo3Pk49759V6bfbyAPbbOvMJEs7SSgnu31QJpBif25xLH9WqnIwS/
	BV/dyNsphhsV3uusaoTCeoHGZYokAeqOK9wv7ijY38fp4gvR9intRvabkg7xGqDGAQsH
	1I5Q==
MIME-Version: 1.0
X-Received: by 10.43.9.137 with SMTP id ow9mr3033934icb.32.1362053780782; Thu,
	28 Feb 2013 04:16:20 -0800 (PST)
Received: by 10.64.39.194 with HTTP; Thu, 28 Feb 2013 04:16:20 -0800 (PST)
In-Reply-To: <01689b3f7939895e949a.1359716477@Solace>
References: <patchbomb.1359716470@Solace>
	<01689b3f7939895e949a.1359716477@Solace>
Date: Thu, 28 Feb 2013 12:16:20 +0000
X-Google-Sender-Auth: Q0tMg1VrrPt3Eip0fl4YM5jxpLY
Message-ID: <CAFLBxZaHXKop-9mF5RoG8dyoUFF1S-Orne43ecRXHgMePna9wQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 07 of 11 v3] libxl: allow for explicitly
 specifying 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="===============4580192324506614968=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4580192324506614968==
Content-Type: multipart/alternative; boundary=bcaec5161fcdc4cdd404d6c7dbab

--bcaec5161fcdc4cdd404d6c7dbab
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> By introducing a nodemap in libxl_domain_build_info and
> providing the get/set methods to deal with it.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4161,6 +4161,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
>      return rc;
>  }
>
> +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap)
> +{
> +    if (xc_domain_node_setaffinity(ctx->xch, domid, nodemap->map)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
> +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap)
> +{
> +    if (xc_domain_node_getaffinity(ctx->xch, domid, nodemap->map)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting node affinity");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap
> *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
> @@ -266,6 +266,10 @@
>  #endif
>  #endif
>
> +/* For the 'nodemap' field (of libxl_bitmap type) in
> + * libxl_domain_build_info, containing the node-affinity of the domain. */
> +#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
> +
>  /* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be
>   * called from within libxl itself. Callers outside libxl, who
>   * do not #include libxl_internal.h, are fine. */
> @@ -861,6 +865,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>                             libxl_bitmap *cpumap);
>  int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
>                                 unsigned int max_vcpus, libxl_bitmap
> *cpumap);
> +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap);
> +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap);
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap
> *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
> @@ -184,6 +184,12 @@ int libxl__domain_build_info_setdefault(
>
>      libxl_defbool_setdefault(&b_info->numa_placement, true);
>
> +    if (!b_info->nodemap.size) {
> +        if (libxl_node_bitmap_alloc(CTX, &b_info->nodemap, 0))
> +            return ERROR_FAIL;
> +        libxl_bitmap_set_any(&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
> @@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>          if (rc)
>              return rc;
>      }
> +    libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap);
>      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,
> &info->cpumap);
>
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT);
> 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
> @@ -261,6 +261,7 @@ libxl_domain_build_info = Struct("domain
>      ("max_vcpus",       integer),
>      ("avail_vcpus",     libxl_bitmap),
>      ("cpumap",          libxl_bitmap),
> +    ("nodemap",         libxl_bitmap),
>      ("numa_placement",  libxl_defbool),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       MemKB),
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--bcaec5161fcdc4cdd404d6c7dbab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=3D"ltr">&lt;<a href=
=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank">dario.faggioli@citr=
ix.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">By introducing a nodemap in libxl_domain_bui=
ld_info and<br>
providing the get/set methods to deal with it.<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br>
Acked-by: Juergen Gross &lt;<a href=3D"mailto:juergen.gross@ts.fujitsu.com"=
>juergen.gross@ts.fujitsu.com</a>&gt;<br></blockquote><div><br></div><div>A=
cked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt;<br>
</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>
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c<br>
--- a/tools/libxl/libxl.c<br>
+++ b/tools/libxl/libxl.c<br>
@@ -4161,6 +4161,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx<br>
=A0 =A0 =A0return rc;<br>
=A0}<br>
<br>
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap)<br>
+{<br>
+ =A0 =A0if (xc_domain_node_setaffinity(ctx-&gt;xch, domid, nodemap-&gt;map=
)) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;setting node=
 affinity&quot;);<br>
+ =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
+ =A0 =A0}<br>
+ =A0 =A0return 0;<br>
+}<br>
+<br>
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap)<br>
+{<br>
+ =A0 =A0if (xc_domain_node_getaffinity(ctx-&gt;xch, domid, nodemap-&gt;map=
)) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;getting node=
 affinity&quot;);<br>
+ =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
+ =A0 =A0}<br>
+ =A0 =A0return 0;<br>
+}<br>
+<br>
=A0int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *c=
pumap)<br>
=A0{<br>
=A0 =A0 =A0GC_INIT(ctx);<br>
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h<br>
--- a/tools/libxl/libxl.h<br>
+++ b/tools/libxl/libxl.h<br>
@@ -266,6 +266,10 @@<br>
=A0#endif<br>
=A0#endif<br>
<br>
+/* For the &#39;nodemap&#39; field (of libxl_bitmap type) in<br>
+ * libxl_domain_build_info, containing the node-affinity of the domain. */=
<br>
+#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1<br>
+<br>
=A0/* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be<br>
=A0 * called from within libxl itself. Callers outside libxl, who<br>
=A0 * do not #include libxl_internal.h, are fine. */<br>
@@ -861,6 +865,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_bitmap *cpuma=
p);<br>
=A0int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned in=
t max_vcpus, libxl_bitmap *cpumap);<br>
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap);<br>
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap);<br>
=A0int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *c=
pumap);<br>
<br>
=A0libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);<br>
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c<br>
--- a/tools/libxl/libxl_create.c<br>
+++ b/tools/libxl/libxl_create.c<br>
@@ -184,6 +184,12 @@ int libxl__domain_build_info_setdefault(<br>
<br>
=A0 =A0 =A0libxl_defbool_setdefault(&amp;b_info-&gt;numa_placement, true);<=
br>
<br>
+ =A0 =A0if (!b_info-&gt;nodemap.size) {<br>
+ =A0 =A0 =A0 =A0if (libxl_node_bitmap_alloc(CTX, &amp;b_info-&gt;nodemap, =
0))<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
+ =A0 =A0 =A0 =A0libxl_bitmap_set_any(&amp;b_info-&gt;nodemap);<br>
+ =A0 =A0}<br>
+<br>
=A0 =A0 =A0if (b_info-&gt;max_memkb =3D=3D LIBXL_MEMKB_DEFAULT)<br>
=A0 =A0 =A0 =A0 =A0b_info-&gt;max_memkb =3D 32 * 1024;<br>
=A0 =A0 =A0if (b_info-&gt;target_memkb =3D=3D LIBXL_MEMKB_DEFAULT)<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint<br>
=A0 =A0 =A0 =A0 =A0if (rc)<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0return rc;<br>
=A0 =A0 =A0}<br>
+ =A0 =A0libxl_domain_set_nodeaffinity(ctx, domid, &amp;info-&gt;nodemap);<=
br>
=A0 =A0 =A0libxl_set_vcpuaffinity_all(ctx, domid, info-&gt;max_vcpus, &amp;=
info-&gt;cpumap);<br>
<br>
=A0 =A0 =A0xc_domain_setmaxmem(ctx-&gt;xch, domid, info-&gt;target_memkb + =
LIBXL_MAXMEM_CONSTANT);<br>
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl<br>
--- a/tools/libxl/libxl_types.idl<br>
+++ b/tools/libxl/libxl_types.idl<br>
@@ -261,6 +261,7 @@ libxl_domain_build_info =3D Struct(&quot;domain<br>
=A0 =A0 =A0(&quot;max_vcpus&quot;, =A0 =A0 =A0 integer),<br>
=A0 =A0 =A0(&quot;avail_vcpus&quot;, =A0 =A0 libxl_bitmap),<br>
=A0 =A0 =A0(&quot;cpumap&quot;, =A0 =A0 =A0 =A0 =A0libxl_bitmap),<br>
+ =A0 =A0(&quot;nodemap&quot;, =A0 =A0 =A0 =A0 libxl_bitmap),<br>
=A0 =A0 =A0(&quot;numa_placement&quot;, =A0libxl_defbool),<br>
=A0 =A0 =A0(&quot;tsc_mode&quot;, =A0 =A0 =A0 =A0libxl_tsc_mode),<br>
=A0 =A0 =A0(&quot;max_memkb&quot;, =A0 =A0 =A0 MemKB),<br>
<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.x=
en.org/xen-devel</a><br>
</blockquote></div><br></div></div>

--bcaec5161fcdc4cdd404d6c7dbab--


--===============4580192324506614968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4580192324506614968==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 12:16:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:16: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 1UB2Pd-0006m9-Q8; Thu, 28 Feb 2013 12:16:37 +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 1UB2Pc-0006m3-Qv
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:16:37 +0000
Received: from [85.158.138.51:45956] by server-13.bemta-3.messagelabs.com id
	C6/D1-25744-E9A4F215; Thu, 28 Feb 2013 12:16:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362053781!27902654!1
X-Originating-IP: [209.85.210.169]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19689 invoked from network); 28 Feb 2013 12:16:22 -0000
Received: from mail-ia0-f169.google.com (HELO mail-ia0-f169.google.com)
	(209.85.210.169)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:16:22 -0000
Received: by mail-ia0-f169.google.com with SMTP id j5so1451657iaf.14
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 04:16:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=cl0g7HGOjBwVJ2gzbCshpb/8J8DSfZYyhY2cBvgIRQ0=;
	b=OXfUKcdO1zRPG3+BKuZ9cqQOmTy2QJmMXZRKZuBN0Tfk4C8BwE+p4WSWpGBSR1lNJg
	Usp5El8Ly7Eq5YZOT8rwMT/jgiXGvUflrtbZfwyZSzVcJE2uHNmKVdq2q1Nj7kzv8Lzc
	siGG3GP4a/x5F52rtzHp+u48PoxUPhOwnmKfdtCmfc7IYwbsjXSSpeloLk7K99rcLVZJ
	v257AJ71Wtlnk8cDo3Pk49759V6bfbyAPbbOvMJEs7SSgnu31QJpBif25xLH9WqnIwS/
	BV/dyNsphhsV3uusaoTCeoHGZYokAeqOK9wv7ijY38fp4gvR9intRvabkg7xGqDGAQsH
	1I5Q==
MIME-Version: 1.0
X-Received: by 10.43.9.137 with SMTP id ow9mr3033934icb.32.1362053780782; Thu,
	28 Feb 2013 04:16:20 -0800 (PST)
Received: by 10.64.39.194 with HTTP; Thu, 28 Feb 2013 04:16:20 -0800 (PST)
In-Reply-To: <01689b3f7939895e949a.1359716477@Solace>
References: <patchbomb.1359716470@Solace>
	<01689b3f7939895e949a.1359716477@Solace>
Date: Thu, 28 Feb 2013 12:16:20 +0000
X-Google-Sender-Auth: Q0tMg1VrrPt3Eip0fl4YM5jxpLY
Message-ID: <CAFLBxZaHXKop-9mF5RoG8dyoUFF1S-Orne43ecRXHgMePna9wQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 07 of 11 v3] libxl: allow for explicitly
 specifying 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="===============4580192324506614968=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4580192324506614968==
Content-Type: multipart/alternative; boundary=bcaec5161fcdc4cdd404d6c7dbab

--bcaec5161fcdc4cdd404d6c7dbab
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> By introducing a nodemap in libxl_domain_build_info and
> providing the get/set methods to deal with it.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4161,6 +4161,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx
>      return rc;
>  }
>
> +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap)
> +{
> +    if (xc_domain_node_setaffinity(ctx->xch, domid, nodemap->map)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
> +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap)
> +{
> +    if (xc_domain_node_getaffinity(ctx->xch, domid, nodemap->map)) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting node affinity");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap
> *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
> @@ -266,6 +266,10 @@
>  #endif
>  #endif
>
> +/* For the 'nodemap' field (of libxl_bitmap type) in
> + * libxl_domain_build_info, containing the node-affinity of the domain. */
> +#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
> +
>  /* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be
>   * called from within libxl itself. Callers outside libxl, who
>   * do not #include libxl_internal.h, are fine. */
> @@ -861,6 +865,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>                             libxl_bitmap *cpumap);
>  int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
>                                 unsigned int max_vcpus, libxl_bitmap
> *cpumap);
> +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap);
> +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
> +                                  libxl_bitmap *nodemap);
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap
> *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
> @@ -184,6 +184,12 @@ int libxl__domain_build_info_setdefault(
>
>      libxl_defbool_setdefault(&b_info->numa_placement, true);
>
> +    if (!b_info->nodemap.size) {
> +        if (libxl_node_bitmap_alloc(CTX, &b_info->nodemap, 0))
> +            return ERROR_FAIL;
> +        libxl_bitmap_set_any(&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
> @@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>          if (rc)
>              return rc;
>      }
> +    libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap);
>      libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus,
> &info->cpumap);
>
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> LIBXL_MAXMEM_CONSTANT);
> 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
> @@ -261,6 +261,7 @@ libxl_domain_build_info = Struct("domain
>      ("max_vcpus",       integer),
>      ("avail_vcpus",     libxl_bitmap),
>      ("cpumap",          libxl_bitmap),
> +    ("nodemap",         libxl_bitmap),
>      ("numa_placement",  libxl_defbool),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       MemKB),
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--bcaec5161fcdc4cdd404d6c7dbab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=3D"ltr">&lt;<a href=
=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank">dario.faggioli@citr=
ix.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">By introducing a nodemap in libxl_domain_bui=
ld_info and<br>
providing the get/set methods to deal with it.<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br>
Acked-by: Juergen Gross &lt;<a href=3D"mailto:juergen.gross@ts.fujitsu.com"=
>juergen.gross@ts.fujitsu.com</a>&gt;<br></blockquote><div><br></div><div>A=
cked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt;<br>
</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>
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c<br>
--- a/tools/libxl/libxl.c<br>
+++ b/tools/libxl/libxl.c<br>
@@ -4161,6 +4161,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx<br>
=A0 =A0 =A0return rc;<br>
=A0}<br>
<br>
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap)<br>
+{<br>
+ =A0 =A0if (xc_domain_node_setaffinity(ctx-&gt;xch, domid, nodemap-&gt;map=
)) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;setting node=
 affinity&quot;);<br>
+ =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
+ =A0 =A0}<br>
+ =A0 =A0return 0;<br>
+}<br>
+<br>
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap)<br>
+{<br>
+ =A0 =A0if (xc_domain_node_getaffinity(ctx-&gt;xch, domid, nodemap-&gt;map=
)) {<br>
+ =A0 =A0 =A0 =A0LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, &quot;getting node=
 affinity&quot;);<br>
+ =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
+ =A0 =A0}<br>
+ =A0 =A0return 0;<br>
+}<br>
+<br>
=A0int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *c=
pumap)<br>
=A0{<br>
=A0 =A0 =A0GC_INIT(ctx);<br>
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h<br>
--- a/tools/libxl/libxl.h<br>
+++ b/tools/libxl/libxl.h<br>
@@ -266,6 +266,10 @@<br>
=A0#endif<br>
=A0#endif<br>
<br>
+/* For the &#39;nodemap&#39; field (of libxl_bitmap type) in<br>
+ * libxl_domain_build_info, containing the node-affinity of the domain. */=
<br>
+#define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1<br>
+<br>
=A0/* Functions annotated with LIBXL_EXTERNAL_CALLERS_ONLY may not be<br>
=A0 * called from within libxl itself. Callers outside libxl, who<br>
=A0 * do not #include libxl_internal.h, are fine. */<br>
@@ -861,6 +865,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 libxl_bitmap *cpuma=
p);<br>
=A0int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned in=
t max_vcpus, libxl_bitmap *cpumap);<br>
+int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap);<br>
+int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_=
bitmap *nodemap);<br>
=A0int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *c=
pumap);<br>
<br>
=A0libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx);<br>
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c<br>
--- a/tools/libxl/libxl_create.c<br>
+++ b/tools/libxl/libxl_create.c<br>
@@ -184,6 +184,12 @@ int libxl__domain_build_info_setdefault(<br>
<br>
=A0 =A0 =A0libxl_defbool_setdefault(&amp;b_info-&gt;numa_placement, true);<=
br>
<br>
+ =A0 =A0if (!b_info-&gt;nodemap.size) {<br>
+ =A0 =A0 =A0 =A0if (libxl_node_bitmap_alloc(CTX, &amp;b_info-&gt;nodemap, =
0))<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
+ =A0 =A0 =A0 =A0libxl_bitmap_set_any(&amp;b_info-&gt;nodemap);<br>
+ =A0 =A0}<br>
+<br>
=A0 =A0 =A0if (b_info-&gt;max_memkb =3D=3D LIBXL_MEMKB_DEFAULT)<br>
=A0 =A0 =A0 =A0 =A0b_info-&gt;max_memkb =3D 32 * 1024;<br>
=A0 =A0 =A0if (b_info-&gt;target_memkb =3D=3D LIBXL_MEMKB_DEFAULT)<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint<br>
=A0 =A0 =A0 =A0 =A0if (rc)<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0return rc;<br>
=A0 =A0 =A0}<br>
+ =A0 =A0libxl_domain_set_nodeaffinity(ctx, domid, &amp;info-&gt;nodemap);<=
br>
=A0 =A0 =A0libxl_set_vcpuaffinity_all(ctx, domid, info-&gt;max_vcpus, &amp;=
info-&gt;cpumap);<br>
<br>
=A0 =A0 =A0xc_domain_setmaxmem(ctx-&gt;xch, domid, info-&gt;target_memkb + =
LIBXL_MAXMEM_CONSTANT);<br>
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl<br>
--- a/tools/libxl/libxl_types.idl<br>
+++ b/tools/libxl/libxl_types.idl<br>
@@ -261,6 +261,7 @@ libxl_domain_build_info =3D Struct(&quot;domain<br>
=A0 =A0 =A0(&quot;max_vcpus&quot;, =A0 =A0 =A0 integer),<br>
=A0 =A0 =A0(&quot;avail_vcpus&quot;, =A0 =A0 libxl_bitmap),<br>
=A0 =A0 =A0(&quot;cpumap&quot;, =A0 =A0 =A0 =A0 =A0libxl_bitmap),<br>
+ =A0 =A0(&quot;nodemap&quot;, =A0 =A0 =A0 =A0 libxl_bitmap),<br>
=A0 =A0 =A0(&quot;numa_placement&quot;, =A0libxl_defbool),<br>
=A0 =A0 =A0(&quot;tsc_mode&quot;, =A0 =A0 =A0 =A0libxl_tsc_mode),<br>
=A0 =A0 =A0(&quot;max_memkb&quot;, =A0 =A0 =A0 MemKB),<br>
<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.x=
en.org/xen-devel</a><br>
</blockquote></div><br></div></div>

--bcaec5161fcdc4cdd404d6c7dbab--


--===============4580192324506614968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4580192324506614968==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 12:18:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2R1-0006s0-AC; Thu, 28 Feb 2013 12:18: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 1UB2R0-0006rt-BL
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:18:02 +0000
Received: from [85.158.137.99:7728] by server-14.bemta-3.messagelabs.com id
	04/9F-27076-9FA4F215; Thu, 28 Feb 2013 12:18:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362053879!13073086!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25036 invoked from network); 28 Feb 2013 12:18:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:18:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9744582"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:17:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:16:59 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UB2Pz-00004v-I4;
	Thu, 28 Feb 2013 12:16:59 +0000
Message-ID: <1362053664.16613.2.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 28 Feb 2013 12:14:24 +0000
In-Reply-To: <512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
	<512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 11:38 +0000, Jan Beulich wrote:
> >>> On 28.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> > On 27/02/13 14:33, Wei Liu wrote:
> >> Affected files:
> >> * event_channel.c
> >> * sched.h
> >> * event.h
> >> * xen.h
> > 
> > Is this sort of white space patch useful?
> 
> I think so. It seems we still don't have an in-tree coding style
> document,

We have CODING_STYLE at the top-level now. I did'nt hceck what it says
about whitespace...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:18:15 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2R1-0006s0-AC; Thu, 28 Feb 2013 12:18: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 1UB2R0-0006rt-BL
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:18:02 +0000
Received: from [85.158.137.99:7728] by server-14.bemta-3.messagelabs.com id
	04/9F-27076-9FA4F215; Thu, 28 Feb 2013 12:18:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362053879!13073086!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25036 invoked from network); 28 Feb 2013 12:18:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:18:00 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9744582"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:17:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:16:59 -0500
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1UB2Pz-00004v-I4;
	Thu, 28 Feb 2013 12:16:59 +0000
Message-ID: <1362053664.16613.2.camel@hastur.hellion.org.uk>
From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 28 Feb 2013 12:14:24 +0000
In-Reply-To: <512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
	<512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4-2 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 11:38 +0000, Jan Beulich wrote:
> >>> On 28.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> > On 27/02/13 14:33, Wei Liu wrote:
> >> Affected files:
> >> * event_channel.c
> >> * sched.h
> >> * event.h
> >> * xen.h
> > 
> > Is this sort of white space patch useful?
> 
> I think so. It seems we still don't have an in-tree coding style
> document,

We have CODING_STYLE at the top-level now. I did'nt hceck what it says
about whitespace...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:24:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2Wk-0007Bq-Fu; Thu, 28 Feb 2013 12:23:58 +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 1UB2Wi-0007Bi-LK
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:23:57 +0000
Received: from [85.158.139.211:4440] by server-2.bemta-5.messagelabs.com id
	57/9E-23989-B5C4F215; Thu, 28 Feb 2013 12:23:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1362054234!19745107!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28799 invoked from network); 28 Feb 2013 12:23:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:23:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9745667"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:23:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:23:53 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB2Wf-0000BE-87;
	Thu, 28 Feb 2013 12:23:53 +0000
Message-ID: <1362054233.2109.90.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Olsen <david.olsen@isprime.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 12:23:53 +0000
In-Reply-To: <20130227193752.GA641@isprime.com>
References: <20130227193752.GA641@isprime.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: annie li <annie.li@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: [Xen-devel] kernel BUG at drivers/net/xen-netfront.c:305
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Drop Xen-user, add Xen-devel

Annie, this is the bug report I talked about. Have you encountered this
before?


Wei.

On Wed, 2013-02-27 at 19:37 +0000, David Olsen wrote:
> Hello,
> 
> I've been having an issue with a particular DomU on a server. The Dom0 runs
> other instances just fine, this particular instance will run just fine for a
> few hours to a few days, then it will just die out with the following error:
> 
> ---
> kernel BUG at drivers/net/xen-netfront.c:305!
> invalid opcode: 0000 [#1] SMP 
> Modules linked in:
> CPU 0 
> Pid: 0, comm: swapper/0 Not tainted 3.6.6-gentoo #1  
> RIP: e030:[<ffffffff812c14ad>]  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
> RSP: e02b:ffff88006da03d80  EFLAGS: 00010286
> RAX: 00000000000001ff RBX: ffff880066f88000 RCX: 0000000000000001
> RDX: 0000000000000057 RSI: 0000000000000000 RDI: 0000000000004fc0
> RBP: 000000000cc1323f R08: 0000000000000000 R09: 00000000000038df
> R10: 00000000000004f1 R11: 0000000000003431 R12: 000000000cc13257
> R13: ffff8800669c0600 R14: 00000000000004fc R15: 0000000000000057
> FS:  00007fcb35820740(0000) GS:ffff88006da00000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007fcb3052e260 CR3: 000000005aa3a000 CR4: 0000000000042660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/0 (pid: 0, threadinfo ffffffff81586000, task ffffffff81599410)
> Stack:
>  0000000000000056 0000001864b24900 ffff880066f89430 ffff880066f89c80
>  ffff880066f88000 0000000000000001 ffff880066f88758 ffff88006da18d30
>  ffff880066f88000 0000000000000000 ffff88006da03e28 ffffffff812c2a61
> Call Trace:
>  <IRQ> 
>  [<ffffffff812c2a61>] ? xennet_poll+0xa0a/0xa98
>  [<ffffffff8104e45d>] ? hrtimer_interrupt+0x112/0x1c9
>  [<ffffffff81326920>] ? net_rx_action+0x6e/0x139
>  [<ffffffff8103a91a>] ? __do_softirq+0x9c/0x145
>  [<ffffffff81281e9d>] ? __xen_evtchn_do_upcall+0x1b0/0x1ed
>  [<ffffffff8141973c>] ? call_softirq+0x1c/0x30
>  [<ffffffff8100be36>] ? do_softirq+0x3c/0x7a
>  [<ffffffff8103ab82>] ? irq_exit+0x42/0x9a
>  [<ffffffff812838cb>] ? xen_evtchn_do_upcall+0x27/0x32
>  [<ffffffff8141978e>] ? xen_do_hypervisor_callback+0x1e/0x30
>  <EOI> 
>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>  [<ffffffff81006836>] ? xen_safe_halt+0xc/0x13
>  [<ffffffff81011003>] ? default_idle+0x23/0x3f
>  [<ffffffff8101182c>] ? cpu_idle+0x60/0xa2
>  [<ffffffff8161baca>] ? start_kernel+0x32e/0x339
>  [<ffffffff8161b5b5>] ? repair_env_string+0x54/0x54
>  [<ffffffff8161e2b2>] ? xen_start_kernel+0x465/0x46b
> Code: 45 08 49 c7 45 08 00 00 00 00 48 89 42 08 48 89 10 41 0f b6 d7 49 89 5d 20 48 8d 82 a8 01 00 00 48 83 bc c3 40 07 00 00 00 74 02 <0f> 0b 48 8b 7c 24 18 4c 89 ac c3 40 07 00 00 48 89 14 24 e8 e2 
> RIP  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
>  RSP <ffff88006da03d80>
> ---[ end trace 77f364e88037c131 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> ---
> 
> Here's the config for that instance:
> kernel = "/xen/kernels/kernel-linux-3.6.11-domU"
> memory = 6144
> maxmem = 16384
> maxvcpus = 24
> vcpus = 2
> name   = "REDACTED"
> disk   = ['phy:/dev/vg/REDACTED-root,sda1,w','phy:/dev/swap/REDACTED-swap,sdb1,w']
> root   = "/dev/xvda1 ro"
> extra  = "console=hvc0 xencons=tty"
> vif    = [ 'bridge=eth0,mac=00:16:3e:52:ca:47', 'bridge=eth1,mac=00:16:3e:d4:b7:d8' ]
> 
> It's just a basic LAMP setup, with the MySQL being external to the instance.
> 
> Running xen version 4.2.0 on a Gentoo Linux box.
> 
> Let me know if the error looks familiar to anyone, or if there is any more
> information I can provide.
> 
> -d
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:24:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2Wk-0007Bq-Fu; Thu, 28 Feb 2013 12:23:58 +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 1UB2Wi-0007Bi-LK
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:23:57 +0000
Received: from [85.158.139.211:4440] by server-2.bemta-5.messagelabs.com id
	57/9E-23989-B5C4F215; Thu, 28 Feb 2013 12:23:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1362054234!19745107!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28799 invoked from network); 28 Feb 2013 12:23:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:23:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9745667"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:23:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:23:53 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB2Wf-0000BE-87;
	Thu, 28 Feb 2013 12:23:53 +0000
Message-ID: <1362054233.2109.90.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Olsen <david.olsen@isprime.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Thu, 28 Feb 2013 12:23:53 +0000
In-Reply-To: <20130227193752.GA641@isprime.com>
References: <20130227193752.GA641@isprime.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: annie li <annie.li@oracle.com>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: [Xen-devel] kernel BUG at drivers/net/xen-netfront.c:305
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Drop Xen-user, add Xen-devel

Annie, this is the bug report I talked about. Have you encountered this
before?


Wei.

On Wed, 2013-02-27 at 19:37 +0000, David Olsen wrote:
> Hello,
> 
> I've been having an issue with a particular DomU on a server. The Dom0 runs
> other instances just fine, this particular instance will run just fine for a
> few hours to a few days, then it will just die out with the following error:
> 
> ---
> kernel BUG at drivers/net/xen-netfront.c:305!
> invalid opcode: 0000 [#1] SMP 
> Modules linked in:
> CPU 0 
> Pid: 0, comm: swapper/0 Not tainted 3.6.6-gentoo #1  
> RIP: e030:[<ffffffff812c14ad>]  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
> RSP: e02b:ffff88006da03d80  EFLAGS: 00010286
> RAX: 00000000000001ff RBX: ffff880066f88000 RCX: 0000000000000001
> RDX: 0000000000000057 RSI: 0000000000000000 RDI: 0000000000004fc0
> RBP: 000000000cc1323f R08: 0000000000000000 R09: 00000000000038df
> R10: 00000000000004f1 R11: 0000000000003431 R12: 000000000cc13257
> R13: ffff8800669c0600 R14: 00000000000004fc R15: 0000000000000057
> FS:  00007fcb35820740(0000) GS:ffff88006da00000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007fcb3052e260 CR3: 000000005aa3a000 CR4: 0000000000042660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper/0 (pid: 0, threadinfo ffffffff81586000, task ffffffff81599410)
> Stack:
>  0000000000000056 0000001864b24900 ffff880066f89430 ffff880066f89c80
>  ffff880066f88000 0000000000000001 ffff880066f88758 ffff88006da18d30
>  ffff880066f88000 0000000000000000 ffff88006da03e28 ffffffff812c2a61
> Call Trace:
>  <IRQ> 
>  [<ffffffff812c2a61>] ? xennet_poll+0xa0a/0xa98
>  [<ffffffff8104e45d>] ? hrtimer_interrupt+0x112/0x1c9
>  [<ffffffff81326920>] ? net_rx_action+0x6e/0x139
>  [<ffffffff8103a91a>] ? __do_softirq+0x9c/0x145
>  [<ffffffff81281e9d>] ? __xen_evtchn_do_upcall+0x1b0/0x1ed
>  [<ffffffff8141973c>] ? call_softirq+0x1c/0x30
>  [<ffffffff8100be36>] ? do_softirq+0x3c/0x7a
>  [<ffffffff8103ab82>] ? irq_exit+0x42/0x9a
>  [<ffffffff812838cb>] ? xen_evtchn_do_upcall+0x27/0x32
>  [<ffffffff8141978e>] ? xen_do_hypervisor_callback+0x1e/0x30
>  <EOI> 
>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>  [<ffffffff81006836>] ? xen_safe_halt+0xc/0x13
>  [<ffffffff81011003>] ? default_idle+0x23/0x3f
>  [<ffffffff8101182c>] ? cpu_idle+0x60/0xa2
>  [<ffffffff8161baca>] ? start_kernel+0x32e/0x339
>  [<ffffffff8161b5b5>] ? repair_env_string+0x54/0x54
>  [<ffffffff8161e2b2>] ? xen_start_kernel+0x465/0x46b
> Code: 45 08 49 c7 45 08 00 00 00 00 48 89 42 08 48 89 10 41 0f b6 d7 49 89 5d 20 48 8d 82 a8 01 00 00 48 83 bc c3 40 07 00 00 00 74 02 <0f> 0b 48 8b 7c 24 18 4c 89 ac c3 40 07 00 00 48 89 14 24 e8 e2 
> RIP  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
>  RSP <ffff88006da03d80>
> ---[ end trace 77f364e88037c131 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> ---
> 
> Here's the config for that instance:
> kernel = "/xen/kernels/kernel-linux-3.6.11-domU"
> memory = 6144
> maxmem = 16384
> maxvcpus = 24
> vcpus = 2
> name   = "REDACTED"
> disk   = ['phy:/dev/vg/REDACTED-root,sda1,w','phy:/dev/swap/REDACTED-swap,sdb1,w']
> root   = "/dev/xvda1 ro"
> extra  = "console=hvc0 xencons=tty"
> vif    = [ 'bridge=eth0,mac=00:16:3e:52:ca:47', 'bridge=eth1,mac=00:16:3e:d4:b7:d8' ]
> 
> It's just a basic LAMP setup, with the MySQL being external to the instance.
> 
> Running xen version 4.2.0 on a Gentoo Linux box.
> 
> Let me know if the error looks familiar to anyone, or if there is any more
> information I can provide.
> 
> -d
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:29:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB2cK-0007eQ-5c; Thu, 28 Feb 2013 12:29:44 +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 1UB2cI-0007eF-Oq
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:29:42 +0000
Received: from [85.158.139.211:55375] by server-2.bemta-5.messagelabs.com id
	AA/29-23989-6BD4F215; Thu, 28 Feb 2013 12:29:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362054579!18890122!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6361 invoked from network); 28 Feb 2013 12:29:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10248848"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:29:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:29:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB2cE-0000GQ-HP;
	Thu, 28 Feb 2013 12:29:38 +0000
Message-ID: <1362054578.2109.92.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 28 Feb 2013 12:29:38 +0000
In-Reply-To: <1362053664.16613.2.camel@hastur.hellion.org.uk>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
	<512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
	<1362053664.16613.2.camel@hastur.hellion.org.uk>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 12:14 +0000, Ian Campbell wrote:
> On Thu, 2013-02-28 at 11:38 +0000, Jan Beulich wrote:
> > >>> On 28.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> > > On 27/02/13 14:33, Wei Liu wrote:
> > >> Affected files:
> > >> * event_channel.c
> > >> * sched.h
> > >> * event.h
> > >> * xen.h
> > > 
> > > Is this sort of white space patch useful?
> > 
> > I think so. It seems we still don't have an in-tree coding style
> > document,
> 
> We have CODING_STYLE at the top-level now. I did'nt hceck what it says
> about whitespace...
> 
> 

Oh yes there is a CODING_STYLE now. And it says:

There should be no trailing white space at the end of lines (including
after the opening /* of a comment block).

So this patch makes sense now...


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:29:58 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB2cK-0007eQ-5c; Thu, 28 Feb 2013 12:29:44 +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 1UB2cI-0007eF-Oq
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:29:42 +0000
Received: from [85.158.139.211:55375] by server-2.bemta-5.messagelabs.com id
	AA/29-23989-6BD4F215; Thu, 28 Feb 2013 12:29:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362054579!18890122!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6361 invoked from network); 28 Feb 2013 12:29:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10248848"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:29:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:29:38 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB2cE-0000GQ-HP;
	Thu, 28 Feb 2013 12:29:38 +0000
Message-ID: <1362054578.2109.92.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 28 Feb 2013 12:29:38 +0000
In-Reply-To: <1362053664.16613.2.camel@hastur.hellion.org.uk>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
	<512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
	<1362053664.16613.2.camel@hastur.hellion.org.uk>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 12:14 +0000, Ian Campbell wrote:
> On Thu, 2013-02-28 at 11:38 +0000, Jan Beulich wrote:
> > >>> On 28.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> > > On 27/02/13 14:33, Wei Liu wrote:
> > >> Affected files:
> > >> * event_channel.c
> > >> * sched.h
> > >> * event.h
> > >> * xen.h
> > > 
> > > Is this sort of white space patch useful?
> > 
> > I think so. It seems we still don't have an in-tree coding style
> > document,
> 
> We have CODING_STYLE at the top-level now. I did'nt hceck what it says
> about whitespace...
> 
> 

Oh yes there is a CODING_STYLE now. And it says:

There should be no trailing white space at the end of lines (including
after the opening /* of a comment block).

So this patch makes sense now...


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:30:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:30: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 1UB2dM-0007is-Kc; Thu, 28 Feb 2013 12:30:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB2dL-0007ii-Vp
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:30:48 +0000
Received: from [193.109.254.147:42861] by server-10.bemta-14.messagelabs.com
	id 21/6F-12679-7FD4F215; Thu, 28 Feb 2013 12:30:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1362054630!9890555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9180 invoked from network); 28 Feb 2013 12:30:33 -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;
	28 Feb 2013 12:30:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9746940"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:30:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:30:30 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB2d3-0000HQ-My;
	Thu, 28 Feb 2013 12:30:29 +0000
Message-ID: <512F4DE5.306@citrix.com>
Date: Thu, 28 Feb 2013 12:30:29 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
	<512F2FEA02000078000C1D17@nat28.tlf.novell.com>
In-Reply-To: <512F2FEA02000078000C1D17@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xen-devel <xen-devel@lists.xen.org>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Ping: [PATCH] x86/MSI: add mechanism to protect
 MSI-X table from PV guest 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 28/02/13 09:22, Jan Beulich wrote:
>>>> On 07.02.13 at 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> This adds two new physdev operations for Dom0 to invoke when resource
>>> allocation for devices is known to be complete, so that the hypervisor
>>> can arrange for the respective MMIO ranges to be marked read-only
>>> before an eventual guest getting such a device assigned even gets
>>> started, such that it won't be able to set up writable mappings for
>>> these MMIO ranges before Xen has a chance to protect them.
>> I should probably mention the alternatives:
>>
>> 1) Brute force scan of the (PV) guest's L1 page tables, locating
>> eventual mappings of the questionable MMIO pages, and
>> converting those mappings to R/O ones.
>>
>> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
>> guest_io_write(), taking note of which BAR(s) are relevant at the
>> point where the device gets first detected/reported), perhaps
>> along with snoops of the PCI_COMMAND_MEMORY bit.
> So I just now sent a mail to Linux'es PCI subsystem maintainer,
> assuming that we'll go with the approach the patch presented at
> the start of this thread. The outcome of this, however, is not
> really relevant for the hypervisor side change to go in, as it
> would only affect the placement of the new hypercall within
> pciback or the core PCI subsystem.
>
> That assumption is largely because no-one really voiced an opinion
> towards a preference of one of the alternatives described above.
>
> Unless I'll receive an explicit NAK or further comments moving this
> discussion forward, I'm intending to commit the patch without
> anyone's ACK in a few days time _and_ backport it to the stable
> trees (4.2 at least, not sure how well it will backport to 4.1).
>
> Jan

For what it is worth, I think the principle is good.  One query I have
is whether it is sensible to restrict this to dom0, as the comments
indicate, or whether it should be permitted to be used by any domain
with appropriate permissions to manage PCI passthrough.

How do you see dom0 attempting to use these hypercalls in an example of
passing a PCI device through to an untrusted domain?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:30:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:30: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 1UB2dM-0007is-Kc; Thu, 28 Feb 2013 12:30:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB2dL-0007ii-Vp
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:30:48 +0000
Received: from [193.109.254.147:42861] by server-10.bemta-14.messagelabs.com
	id 21/6F-12679-7FD4F215; Thu, 28 Feb 2013 12:30:47 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1362054630!9890555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9180 invoked from network); 28 Feb 2013 12:30:33 -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;
	28 Feb 2013 12:30:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9746940"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:30:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:30:30 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB2d3-0000HQ-My;
	Thu, 28 Feb 2013 12:30:29 +0000
Message-ID: <512F4DE5.306@citrix.com>
Date: Thu, 28 Feb 2013 12:30:29 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
	<512F2FEA02000078000C1D17@nat28.tlf.novell.com>
In-Reply-To: <512F2FEA02000078000C1D17@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xen-devel <xen-devel@lists.xen.org>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Ping: [PATCH] x86/MSI: add mechanism to protect
 MSI-X table from PV guest 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 28/02/13 09:22, Jan Beulich wrote:
>>>> On 07.02.13 at 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> This adds two new physdev operations for Dom0 to invoke when resource
>>> allocation for devices is known to be complete, so that the hypervisor
>>> can arrange for the respective MMIO ranges to be marked read-only
>>> before an eventual guest getting such a device assigned even gets
>>> started, such that it won't be able to set up writable mappings for
>>> these MMIO ranges before Xen has a chance to protect them.
>> I should probably mention the alternatives:
>>
>> 1) Brute force scan of the (PV) guest's L1 page tables, locating
>> eventual mappings of the questionable MMIO pages, and
>> converting those mappings to R/O ones.
>>
>> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
>> guest_io_write(), taking note of which BAR(s) are relevant at the
>> point where the device gets first detected/reported), perhaps
>> along with snoops of the PCI_COMMAND_MEMORY bit.
> So I just now sent a mail to Linux'es PCI subsystem maintainer,
> assuming that we'll go with the approach the patch presented at
> the start of this thread. The outcome of this, however, is not
> really relevant for the hypervisor side change to go in, as it
> would only affect the placement of the new hypercall within
> pciback or the core PCI subsystem.
>
> That assumption is largely because no-one really voiced an opinion
> towards a preference of one of the alternatives described above.
>
> Unless I'll receive an explicit NAK or further comments moving this
> discussion forward, I'm intending to commit the patch without
> anyone's ACK in a few days time _and_ backport it to the stable
> trees (4.2 at least, not sure how well it will backport to 4.1).
>
> Jan

For what it is worth, I think the principle is good.  One query I have
is whether it is sensible to restrict this to dom0, as the comments
indicate, or whether it should be permitted to be used by any domain
with appropriate permissions to manage PCI passthrough.

How do you see dom0 attempting to use these hypercalls in an example of
passing a PCI device through to an untrusted domain?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:32:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2f4-00080O-7Q; Thu, 28 Feb 2013 12:32:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB2f2-00080E-FP
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:32:32 +0000
Received: from [85.158.139.211:59844] by server-9.bemta-5.messagelabs.com id
	8A/9E-08547-F5E4F215; Thu, 28 Feb 2013 12:32:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1362054749!18073280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13559 invoked from network); 28 Feb 2013 12:32:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:32:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10249635"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:32:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:32:28 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB2ey-0000JJ-FW;
	Thu, 28 Feb 2013 12:32:28 +0000
Message-ID: <512F4E5C.8090308@citrix.com>
Date: Thu, 28 Feb 2013 12:32:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
In-Reply-To: <512F384602000078000C1D5B@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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 28/02/13 09:58, Jan Beulich wrote:
>>>> On 22.11.12 at 17:12, Jan Beulich wrote:
>>>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 22/11/12 15:55, Jan Beulich wrote:
>>>>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>> A quick solution would be to execute a noop function with
>>>>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
>>>>> so which does an inline iret to itself.  Which of these would you prefer?
>>>> I would actually consider avoiding to run softirqs altogether in that
>>>> case, just like native Linux doesn't do any event or scheduler
>>>> processing in that case.
>>> That would probably be the easiest solution.
>>>
>>> I was already going to do the same for the rentrant NMI and MCE handling
>>> case (and also the process pending upcalls checking), due to the
>>> complexities of fixing the race condition at the end of the handler.
>>>
>>> Unfortunately, I don't think I have time to look at this issue
>>> immediately, but if it is ok to wait till the beginning of next week, I
>> That's fine of course.
> So that was 3 months ago, and we're likely going to need to do
> further unfixed releases if this won't move forward. Can you
> estimate whether you'll be able to get back to this?
>
> Jan
>

With the new enable_nmi() function, I can spin a workaround patch quite
quickly, and will try to get that done this week.  The remainder of the
reentrant tangle is still happening very slowly.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:32:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB2f4-00080O-7Q; Thu, 28 Feb 2013 12:32:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB2f2-00080E-FP
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:32:32 +0000
Received: from [85.158.139.211:59844] by server-9.bemta-5.messagelabs.com id
	8A/9E-08547-F5E4F215; Thu, 28 Feb 2013 12:32:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1362054749!18073280!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13559 invoked from network); 28 Feb 2013 12:32:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:32:30 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10249635"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:32:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:32:28 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB2ey-0000JJ-FW;
	Thu, 28 Feb 2013 12:32:28 +0000
Message-ID: <512F4E5C.8090308@citrix.com>
Date: Thu, 28 Feb 2013 12:32:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
In-Reply-To: <512F384602000078000C1D5B@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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 28/02/13 09:58, Jan Beulich wrote:
>>>> On 22.11.12 at 17:12, Jan Beulich wrote:
>>>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 22/11/12 15:55, Jan Beulich wrote:
>>>>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>> A quick solution would be to execute a noop function with
>>>>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
>>>>> so which does an inline iret to itself.  Which of these would you prefer?
>>>> I would actually consider avoiding to run softirqs altogether in that
>>>> case, just like native Linux doesn't do any event or scheduler
>>>> processing in that case.
>>> That would probably be the easiest solution.
>>>
>>> I was already going to do the same for the rentrant NMI and MCE handling
>>> case (and also the process pending upcalls checking), due to the
>>> complexities of fixing the race condition at the end of the handler.
>>>
>>> Unfortunately, I don't think I have time to look at this issue
>>> immediately, but if it is ok to wait till the beginning of next week, I
>> That's fine of course.
> So that was 3 months ago, and we're likely going to need to do
> further unfixed releases if this won't move forward. Can you
> estimate whether you'll be able to get back to this?
>
> Jan
>

With the new enable_nmi() function, I can spin a workaround patch quite
quickly, and will try to get that done this week.  The remainder of the
reentrant tangle is still happening very slowly.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:32: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 1UB2fH-000828-Kt; Thu, 28 Feb 2013 12:32:47 +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 1UB2fF-00081b-OR
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:32:45 +0000
Received: from [85.158.139.211:60972] by server-13.bemta-5.messagelabs.com id
	E7/88-16871-D6E4F215; Thu, 28 Feb 2013 12:32:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362054762!18104991!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12660 invoked from network); 28 Feb 2013 12:32:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:32:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9747573"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:32:42 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:32:42 -0500
Message-ID: <512F4E68.2000707@citrix.com>
Date: Thu, 28 Feb 2013 12:32:40 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 27/02/13 14:33, Wei Liu wrote:
> This interface allows user to query supported event channel types. If we need
> to disable a specific ABI in the future, we just need to remove the dead code
> and clear corresponding feature bit.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/include/public/event_channel.h |   44 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
> index 07ff321..dff3364 100644
> --- a/xen/include/public/event_channel.h
> +++ b/xen/include/public/event_channel.h
> @@ -71,6 +71,7 @@
>  #define EVTCHNOP_bind_vcpu        8
>  #define EVTCHNOP_unmask           9
>  #define EVTCHNOP_reset           10
> +#define EVTCHNOP_register_extended 11
>  /* ` } */
>  
>  typedef uint32_t evtchn_port_t;
> @@ -258,6 +259,49 @@ struct evtchn_reset {
>  typedef struct evtchn_reset evtchn_reset_t;
>  
>  /*
> + * EVTCHNOP_register_extended: Register extended event channel
> + * NOTES:
> + *  1. Currently only 3-level is supported.
> + *  2. Should fall back to 2-level if this call fails.
> + */
> +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> + * 256k event channels while 32 bit ones only need 1 page for 32k
> + * event channels. */
> +#define EVTCHN_MAX_L3_PAGES 8
> +struct evtchn_register_3level {
> +    /* IN parameters. */
> +    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
> +    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
> +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
> +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
> +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
> +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
> +};

Registering per-VCPU resources at start-of-day doesn't seem like the
right thing to do here.  Why waste resources for VCPUs that are never
going to be used?  And I don't think we want to constraint how VCPU
hotplug works by requiring resource for all possible VCPUs to be
allocated up-front.

If there isn't enough resource for all VCPUs to all use the 3-level ABI
then I think the preferred trade off is to offline the VCPUs that cannot
get resources and not fallback to the 2-level ABI.

The event channel limit is a hard scalability limit, number of VCPUs is
a soft limit, so a guest is more likely to gracefully degrade in
usefulness if it loses VCPUs instead of available event channels.

Obviously, if 3-level is requested and the boot VCPUs fails to enable
it, then it should fallback to 2-level because this is better than just
panicking.

> +typedef struct evtchn_register_3level evtchn_register_3level_t;
> +DEFINE_XEN_GUEST_HANDLE(evtchn_register_3level_t);
> +
> +/* commands:
> + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> + *                _NONE      supported types are or'ed in return value of
> + *                           the hypercall.
> + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.

Combining query and register makes no sense.

> + */
> +#define EVTCHN_EXTENDED_QUERY 0
> +/* supported extended event channel */
> +#define EVTCHN_EXTENDED_NONE  0
> +#define _EVTCHN_EXTENDED_L3   0
> +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> +struct evtchn_register_extended {
> +    /* IN parameters. */
> +    uint32_t cmd;
> +    union {
> +        evtchn_register_3level_t l3;
> +    } u;
> +};

Adding new members to this union as new event channels ABI are
implemented are going to change its size and potentially the alignment
of the union member.  This seems a potential for future ABI
compatibility problems.  See also by comment to patch 18.

There doesn't seem to be any value in having a single register sub-op
for all possible future ABIs.  Just add a new sub-op for each new ABI.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:32:56 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:32: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 1UB2fH-000828-Kt; Thu, 28 Feb 2013 12:32:47 +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 1UB2fF-00081b-OR
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:32:45 +0000
Received: from [85.158.139.211:60972] by server-13.bemta-5.messagelabs.com id
	E7/88-16871-D6E4F215; Thu, 28 Feb 2013 12:32:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362054762!18104991!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12660 invoked from network); 28 Feb 2013 12:32:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:32:43 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9747573"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:32:42 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:32:42 -0500
Message-ID: <512F4E68.2000707@citrix.com>
Date: Thu, 28 Feb 2013 12:32:40 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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 27/02/13 14:33, Wei Liu wrote:
> This interface allows user to query supported event channel types. If we need
> to disable a specific ABI in the future, we just need to remove the dead code
> and clear corresponding feature bit.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/include/public/event_channel.h |   44 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
> index 07ff321..dff3364 100644
> --- a/xen/include/public/event_channel.h
> +++ b/xen/include/public/event_channel.h
> @@ -71,6 +71,7 @@
>  #define EVTCHNOP_bind_vcpu        8
>  #define EVTCHNOP_unmask           9
>  #define EVTCHNOP_reset           10
> +#define EVTCHNOP_register_extended 11
>  /* ` } */
>  
>  typedef uint32_t evtchn_port_t;
> @@ -258,6 +259,49 @@ struct evtchn_reset {
>  typedef struct evtchn_reset evtchn_reset_t;
>  
>  /*
> + * EVTCHNOP_register_extended: Register extended event channel
> + * NOTES:
> + *  1. Currently only 3-level is supported.
> + *  2. Should fall back to 2-level if this call fails.
> + */
> +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> + * 256k event channels while 32 bit ones only need 1 page for 32k
> + * event channels. */
> +#define EVTCHN_MAX_L3_PAGES 8
> +struct evtchn_register_3level {
> +    /* IN parameters. */
> +    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
> +    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
> +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
> +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
> +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
> +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
> +};

Registering per-VCPU resources at start-of-day doesn't seem like the
right thing to do here.  Why waste resources for VCPUs that are never
going to be used?  And I don't think we want to constraint how VCPU
hotplug works by requiring resource for all possible VCPUs to be
allocated up-front.

If there isn't enough resource for all VCPUs to all use the 3-level ABI
then I think the preferred trade off is to offline the VCPUs that cannot
get resources and not fallback to the 2-level ABI.

The event channel limit is a hard scalability limit, number of VCPUs is
a soft limit, so a guest is more likely to gracefully degrade in
usefulness if it loses VCPUs instead of available event channels.

Obviously, if 3-level is requested and the boot VCPUs fails to enable
it, then it should fallback to 2-level because this is better than just
panicking.

> +typedef struct evtchn_register_3level evtchn_register_3level_t;
> +DEFINE_XEN_GUEST_HANDLE(evtchn_register_3level_t);
> +
> +/* commands:
> + * EVTCHN_EXTENDED_QUERY(0): query supported extended event channel types,
> + *                _NONE      supported types are or'ed in return value of
> + *                           the hypercall.
> + * EVTCHN_EXTENDED_*:        specific extended event channel subcommand.

Combining query and register makes no sense.

> + */
> +#define EVTCHN_EXTENDED_QUERY 0
> +/* supported extended event channel */
> +#define EVTCHN_EXTENDED_NONE  0
> +#define _EVTCHN_EXTENDED_L3   0
> +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> +struct evtchn_register_extended {
> +    /* IN parameters. */
> +    uint32_t cmd;
> +    union {
> +        evtchn_register_3level_t l3;
> +    } u;
> +};

Adding new members to this union as new event channels ABI are
implemented are going to change its size and potentially the alignment
of the union member.  This seems a potential for future ABI
compatibility problems.  See also by comment to patch 18.

There doesn't seem to be any value in having a single register sub-op
for all possible future ABIs.  Just add a new sub-op for each new ABI.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:34:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:34: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 1UB2gl-0008EL-6K; Thu, 28 Feb 2013 12:34:19 +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 1UB2gk-0008EF-HI
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:34:18 +0000
Received: from [85.158.139.211:62070] by server-11.bemta-5.messagelabs.com id
	56/82-27486-9CE4F215; Thu, 28 Feb 2013 12:34:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362054830!18891166!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31588 invoked from network); 28 Feb 2013 12:33:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:33:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10249958"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:33:50 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:33:50 -0500
Message-ID: <512F4EAD.6000502@citrix.com>
Date: Thu, 28 Feb 2013 12:33:49 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 18/22] Implement
	EVTCHNOP_register_extended
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> Note: this call always fails as it is not yet completed.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |   56 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 26daa7e..bb6e5f9 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1204,6 +1204,34 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
>      return rc;
>  }
>  
> +/*
> + * NOTE to extneded event channel users:
> + * extended channels are likely to consume lots large global mapping
> + * area in Xen. For example, 3-level event channel consumes 16 +
> + * nr_vcpus pages global mapping area.
> + */
> +static long evtchn_register_extended(struct evtchn_register_extended *reg)
> +{
> +    struct domain *d = current->domain;
> +    int rc;
> +
> +    spin_lock(&d->event_lock);
> +
> +    switch ( reg->cmd )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +    default:
> +        rc = -EINVAL;
> +    case EVTCHN_EXTENDED_L3:
> +        rc = evtchn_register_3level(&reg->u.l3);
> +        break;
> +    }
> +
> +    spin_unlock(&d->event_lock);
> +
> +    return rc;
> +}
> +
>  long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      long rc;
> @@ -1312,6 +1340,19 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>      }
>  
> +    case EVTCHNOP_register_extended: {
> +        struct evtchn_register_extended reg;
> +
> +        if ( copy_from_guest(&reg, arg, 1) != 0 )
> +            return -EFAULT;

If the guest's idea of the size of struct evtchn_register_extended is
smaller than Xen's, then Xen may try to copy more data that is actually
available.  This may then return -EFAULT unexpectedly if the guest
allocated the structure at the end of a page and the following page is
not mapped.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:34:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:34: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 1UB2gl-0008EL-6K; Thu, 28 Feb 2013 12:34:19 +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 1UB2gk-0008EF-HI
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:34:18 +0000
Received: from [85.158.139.211:62070] by server-11.bemta-5.messagelabs.com id
	56/82-27486-9CE4F215; Thu, 28 Feb 2013 12:34:17 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1362054830!18891166!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31588 invoked from network); 28 Feb 2013 12:33:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:33:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10249958"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:33:50 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:33:50 -0500
Message-ID: <512F4EAD.6000502@citrix.com>
Date: Thu, 28 Feb 2013 12:33:49 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 18/22] Implement
	EVTCHNOP_register_extended
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> Note: this call always fails as it is not yet completed.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |   56 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 26daa7e..bb6e5f9 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1204,6 +1204,34 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
>      return rc;
>  }
>  
> +/*
> + * NOTE to extneded event channel users:
> + * extended channels are likely to consume lots large global mapping
> + * area in Xen. For example, 3-level event channel consumes 16 +
> + * nr_vcpus pages global mapping area.
> + */
> +static long evtchn_register_extended(struct evtchn_register_extended *reg)
> +{
> +    struct domain *d = current->domain;
> +    int rc;
> +
> +    spin_lock(&d->event_lock);
> +
> +    switch ( reg->cmd )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +    default:
> +        rc = -EINVAL;
> +    case EVTCHN_EXTENDED_L3:
> +        rc = evtchn_register_3level(&reg->u.l3);
> +        break;
> +    }
> +
> +    spin_unlock(&d->event_lock);
> +
> +    return rc;
> +}
> +
>  long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      long rc;
> @@ -1312,6 +1340,19 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>      }
>  
> +    case EVTCHNOP_register_extended: {
> +        struct evtchn_register_extended reg;
> +
> +        if ( copy_from_guest(&reg, arg, 1) != 0 )
> +            return -EFAULT;

If the guest's idea of the size of struct evtchn_register_extended is
smaller than Xen's, then Xen may try to copy more data that is actually
available.  This may then return -EFAULT unexpectedly if the guest
allocated the structure at the end of a page and the following page is
not mapped.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:36:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:36: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 1UB2j7-0008SX-P9; Thu, 28 Feb 2013 12:36:45 +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 1UB2j6-0008SK-2K
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:36:44 +0000
Received: from [85.158.139.211:53256] by server-15.bemta-5.messagelabs.com id
	28/1D-22815-B5F4F215; Thu, 28 Feb 2013 12:36:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1362055001!19285152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14972 invoked from network); 28 Feb 2013 12:36:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:36:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10250515"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:36:40 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:36:40 -0500
Message-ID: <512F4F57.4020101@citrix.com>
Date: Thu, 28 Feb 2013 12:36:39 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-20-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-20-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 19/22] Enable exteneded event channel
	ABI query
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1219,12 +1219,14 @@ static long evtchn_register_extended(struct evtchn_register_extended *reg)
>  
>      switch ( reg->cmd )
>      {
> -    case EVTCHN_EXTENDED_NONE:
> -    default:
> -        rc = -EINVAL;
> +    case EVTCHN_EXTENDED_QUERY:
> +        rc = extended_event_channel;
> +        break;

I don't like overloading the return value with both success/failure and
the data.

Can this info be returned in a parameter?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:36:57 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:36: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 1UB2j7-0008SX-P9; Thu, 28 Feb 2013 12:36:45 +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 1UB2j6-0008SK-2K
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:36:44 +0000
Received: from [85.158.139.211:53256] by server-15.bemta-5.messagelabs.com id
	28/1D-22815-B5F4F215; Thu, 28 Feb 2013 12:36:43 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1362055001!19285152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14972 invoked from network); 28 Feb 2013 12:36:42 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:36:42 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10250515"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:36:40 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:36:40 -0500
Message-ID: <512F4F57.4020101@citrix.com>
Date: Thu, 28 Feb 2013 12:36:39 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-20-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-20-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 19/22] Enable exteneded event channel
	ABI query
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1219,12 +1219,14 @@ static long evtchn_register_extended(struct evtchn_register_extended *reg)
>  
>      switch ( reg->cmd )
>      {
> -    case EVTCHN_EXTENDED_NONE:
> -    default:
> -        rc = -EINVAL;
> +    case EVTCHN_EXTENDED_QUERY:
> +        rc = extended_event_channel;
> +        break;

I don't like overloading the return value with both success/failure and
the data.

Can this info be returned in a parameter?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:42:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:42: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 1UB2o2-0000Kh-Hx; Thu, 28 Feb 2013 12:41: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 1UB2o0-0000K9-Q5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:41:49 +0000
Received: from [85.158.138.51:55304] by server-10.bemta-3.messagelabs.com id
	3F/61-19664-7805F215; Thu, 28 Feb 2013 12:41:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362055258!28581946!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30050 invoked from network); 28 Feb 2013 12:41:08 -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;
	28 Feb 2013 12:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10251248"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:40:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:40:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UB2nB-0000Qu-Fa;
	Thu, 28 Feb 2013 12:40:57 +0000
Date: Thu, 28 Feb 2013 12:40:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512F324202000078000C1D37@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1302281237470.5360@kaball.uk.xensource.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
	<3018F0D4E05C1D04A1B3A166@nimrod.local>
	<512F324202000078000C1D37@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 Thu, 28 Feb 2013, Jan Beulich wrote:
> >>> On 28.02.13 at 10:21, Alex Bligh <alex@alex.org.uk> wrote:
> > Jan,
> > 
> > --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:
> > 
> >>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
> >>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com>
> >>> wrote:
> >>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
> >>>> at the beginning of next week.
> >>>
> >>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
> >>> a blktrace.
> >>
> >> To me, the title you mention means nothing. It being on the tools
> >> side, it would be Ian anyway to take care of this, but can't you be
> >> a bit more specific and indicate which changeset/commit you're
> >> talking of? As well as reasoning why it would be needed (or at
> >> least desirable) to have on either or both trees?
> > 
> > See this message and the surrounding thread:
> >   http://markmail.org/message/iy32akdzmbjo7uiz 
> > 
> > In essence any domU PV disk usage backended onto something that uses TCP
> > (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
> > this 100%. The root cause is a very-hard-to-fix skb refcount problem
> > in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
> > xendisk driver. People seemed generally happy with this provided the
> > barriers get through (which I need to demonstrate).
> 
> Oh, that would actually be Stefano, not Ian then.
> 
> And it doesn't look like you're asking for a backport - neither
> upstream qemu nor either of our trees appears to have the
> suggested change yet. If the change doesn't go into any of
> these, there's no way for it to go into a stable release.

Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I
agree that we should disable O_DIRECT, once you have proven that the
barriers and flushes are handled correctly (henceforth we wouldn't
cause data corruptions).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:42:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:42: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 1UB2o2-0000Kh-Hx; Thu, 28 Feb 2013 12:41: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 1UB2o0-0000K9-Q5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:41:49 +0000
Received: from [85.158.138.51:55304] by server-10.bemta-3.messagelabs.com id
	3F/61-19664-7805F215; Thu, 28 Feb 2013 12:41:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362055258!28581946!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30050 invoked from network); 28 Feb 2013 12:41:08 -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;
	28 Feb 2013 12:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10251248"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:40:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:40:57 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UB2nB-0000Qu-Fa;
	Thu, 28 Feb 2013 12:40:57 +0000
Date: Thu, 28 Feb 2013 12:40:52 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512F324202000078000C1D37@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1302281237470.5360@kaball.uk.xensource.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
	<3018F0D4E05C1D04A1B3A166@nimrod.local>
	<512F324202000078000C1D37@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 Thu, 28 Feb 2013, Jan Beulich wrote:
> >>> On 28.02.13 at 10:21, Alex Bligh <alex@alex.org.uk> wrote:
> > Jan,
> > 
> > --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:
> > 
> >>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote:
> >>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com>
> >>> wrote:
> >>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
> >>>> at the beginning of next week.
> >>>
> >>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
> >>> a blktrace.
> >>
> >> To me, the title you mention means nothing. It being on the tools
> >> side, it would be Ian anyway to take care of this, but can't you be
> >> a bit more specific and indicate which changeset/commit you're
> >> talking of? As well as reasoning why it would be needed (or at
> >> least desirable) to have on either or both trees?
> > 
> > See this message and the surrounding thread:
> >   http://markmail.org/message/iy32akdzmbjo7uiz 
> > 
> > In essence any domU PV disk usage backended onto something that uses TCP
> > (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
> > this 100%. The root cause is a very-hard-to-fix skb refcount problem
> > in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
> > xendisk driver. People seemed generally happy with this provided the
> > barriers get through (which I need to demonstrate).
> 
> Oh, that would actually be Stefano, not Ian then.
> 
> And it doesn't look like you're asking for a backport - neither
> upstream qemu nor either of our trees appears to have the
> suggested change yet. If the change doesn't go into any of
> these, there's no way for it to go into a stable release.

Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I
agree that we should disable O_DIRECT, once you have proven that the
barriers and flushes are handled correctly (henceforth we wouldn't
cause data corruptions).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:44:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:44: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 1UB2qX-0000bL-A5; Thu, 28 Feb 2013 12:44: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 1UB2qW-0000bD-G5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:44:24 +0000
Received: from [193.109.254.147:39186] by server-15.bemta-14.messagelabs.com
	id E3/7C-24599-7215F215; Thu, 28 Feb 2013 12:44:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1362055457!2317342!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 587 invoked from network); 28 Feb 2013 12:44:18 -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;
	28 Feb 2013 12:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9749469"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:43:18 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:43:17 -0500
Message-ID: <512F50E4.6020201@citrix.com>
Date: Thu, 28 Feb 2013 12:43:16 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> For non-Dom0 domains, add a flag to indicate whether it can use extended event
> channel, admins can specify this flag when creating a driver domain.
> 
> The rationale behide this option is, a) extended event channel will
> consume global mapping space in Xen, b) likely that only Dom0 and driver
> domains need this.

I would prefer the toolstack to limit the max port that the guest can
use (see the EVTCHNOP_set_limit sub-op I proposed), than this single bit
(which isn't useful for the FIFO-based proposal).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:44:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:44: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 1UB2qX-0000bL-A5; Thu, 28 Feb 2013 12:44: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 1UB2qW-0000bD-G5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:44:24 +0000
Received: from [193.109.254.147:39186] by server-15.bemta-14.messagelabs.com
	id E3/7C-24599-7215F215; Thu, 28 Feb 2013 12:44:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1362055457!2317342!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 587 invoked from network); 28 Feb 2013 12:44:18 -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;
	28 Feb 2013 12:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9749469"
Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:43:18 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL03.citrite.net
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:43:17 -0500
Message-ID: <512F50E4.6020201@citrix.com>
Date: Thu, 28 Feb 2013 12:43:16 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> For non-Dom0 domains, add a flag to indicate whether it can use extended event
> channel, admins can specify this flag when creating a driver domain.
> 
> The rationale behide this option is, a) extended event channel will
> consume global mapping space in Xen, b) likely that only Dom0 and driver
> domains need this.

I would prefer the toolstack to limit the max port that the guest can
use (see the EVTCHNOP_set_limit sub-op I proposed), than this single bit
(which isn't useful for the FIFO-based proposal).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:48:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:48: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 1UB2uQ-0000mN-9k; Thu, 28 Feb 2013 12:48:26 +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 1UB2uO-0000mF-5Y
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:48:24 +0000
Received: from [85.158.137.99:18209] by server-16.bemta-3.messagelabs.com id
	88/6D-20692-7125F215; Thu, 28 Feb 2013 12:48:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1362055700!17175839!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6253 invoked from network); 28 Feb 2013 12:48:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:48:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10252514"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:48:19 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:48:19 -0500
Message-ID: <512F5211.3020900@citrix.com>
Date: Thu, 28 Feb 2013 12:48:17 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-23-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-23-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 22/22] libxl: add evtchn_extended flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> Admins can add "evtchn_extended = 1" in domain config file to enable extended
> event channel ABI for a domain.

You haven't added any documentation for this new option.

I think an option to limit the number of event channels is more
intuitive for the guest administrator.  See also my comment on patch 21.

When you come to write documentation that is useful for a host
administrator or toolstack author for what "evtchn_extended" actually
means you'll see what I mean.  Particularly when you have to say it
means slightly different things depending on whether you're on ARM or on
32 or 64-bit x86.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:48:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12:48: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 1UB2uQ-0000mN-9k; Thu, 28 Feb 2013 12:48:26 +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 1UB2uO-0000mF-5Y
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:48:24 +0000
Received: from [85.158.137.99:18209] by server-16.bemta-3.messagelabs.com id
	88/6D-20692-7125F215; Thu, 28 Feb 2013 12:48:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1362055700!17175839!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6253 invoked from network); 28 Feb 2013 12:48:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 12:48:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10252514"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 12:48:19 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 07:48:19 -0500
Message-ID: <512F5211.3020900@citrix.com>
Date: Thu, 28 Feb 2013 12:48:17 +0000
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/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-23-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1361975655-22295-23-git-send-email-wei.liu2@citrix.com>
X-Originating-IP: [10.80.2.76]
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 22/22] libxl: add evtchn_extended flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/02/13 14:34, Wei Liu wrote:
> Admins can add "evtchn_extended = 1" in domain config file to enable extended
> event channel ABI for a domain.

You haven't added any documentation for this new option.

I think an option to limit the number of event channels is more
intuitive for the guest administrator.  See also my comment on patch 21.

When you come to write documentation that is useful for a host
administrator or toolstack author for what "evtchn_extended" actually
means you'll see what I mean.  Particularly when you have to say it
means slightly different things depending on whether you're on ARM or on
32 or 64-bit x86.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:56:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB327-0001D4-AV; Thu, 28 Feb 2013 12:56:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UB326-0001Cz-9d
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:56:22 +0000
Received: from [85.158.137.99:4092] by server-16.bemta-3.messagelabs.com id
	91/7D-20692-5F35F215; Thu, 28 Feb 2013 12:56:21 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1362056170!18521310!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjYzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6618 invoked from network); 28 Feb 2013 12:56:11 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 12:56:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SCtefi001779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 12:55:41 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
	r1SCtdjW021092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 12:55:39 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
	r1SCtdMb007855; Thu, 28 Feb 2013 06:55:39 -0600
Received: from [192.168.1.101] (/124.68.9.66)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 04:55:39 -0800
Message-ID: <512F53A6.4000401@oracle.com>
Date: Thu, 28 Feb 2013 20:55:02 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
	<1361980154.2109.67.camel@zion.uk.xensource.com>
	<512EE8EF.30200@oracle.com>
	<20130228110237.GA23777@zion.uk.xensource.com>
In-Reply-To: <20130228110237.GA23777@zion.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-28 19:02, Wei Liu wrote:
> On Thu, Feb 28, 2013 at 05:19:43AM +0000, ANNIE LI wrote:
>> I checked the code in Konrad's tree and am thinking this overlap issue
>> you mentioned existing in original netback(without multi-ring) and newer
>> netfront. Original netback does not support multi-ring, and your newer
>> netfront before this bug fix used "#define TX_MAX_TARGET
>> XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when
>> netfront allocating rx skbs.
>> "#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the
>> netfront to single ring, it fixed the overlap issue, but not enough.
>>
> Yes. I just saw a bug report from Xen-user list yesterday for the same
> issue in original netback (1 page ring), so the overlap issue is not
> introduced by multi-page ring implementation. If your team also sees that
> issue, do you have patch to fix that?

No. We thought your patch fixed it, and I did not check it further at 
that time.
Are you sure they are same? What is the thread title in Xen-user?
The overlap issue here exists in netfront when netfront allocates skb 
greedily. In Konrad's tree merged with your patch, netfront with 
"#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE" should hit this overlap 
issue when it runs with single ring netback.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 12:56:37 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 12: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 1UB327-0001D4-AV; Thu, 28 Feb 2013 12:56:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UB326-0001Cz-9d
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 12:56:22 +0000
Received: from [85.158.137.99:4092] by server-16.bemta-3.messagelabs.com id
	91/7D-20692-5F35F215; Thu, 28 Feb 2013 12:56:21 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1362056170!18521310!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjYzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6618 invoked from network); 28 Feb 2013 12:56:11 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 12:56:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SCtefi001779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 12:55:41 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
	r1SCtdjW021092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 12:55:39 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
	r1SCtdMb007855; Thu, 28 Feb 2013 06:55:39 -0600
Received: from [192.168.1.101] (/124.68.9.66)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 04:55:39 -0800
Message-ID: <512F53A6.4000401@oracle.com>
Date: Thu, 28 Feb 2013 20:55:02 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
	<1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
	<512C5B96.10204@oracle.com>
	<1361882139.2109.52.camel@zion.uk.xensource.com>
	<512DB83A.6050503@oracle.com>
	<1361980154.2109.67.camel@zion.uk.xensource.com>
	<512EE8EF.30200@oracle.com>
	<20130228110237.GA23777@zion.uk.xensource.com>
In-Reply-To: <20130228110237.GA23777@zion.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] netfront: multi-page ring 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-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 2013-2-28 19:02, Wei Liu wrote:
> On Thu, Feb 28, 2013 at 05:19:43AM +0000, ANNIE LI wrote:
>> I checked the code in Konrad's tree and am thinking this overlap issue
>> you mentioned existing in original netback(without multi-ring) and newer
>> netfront. Original netback does not support multi-ring, and your newer
>> netfront before this bug fix used "#define TX_MAX_TARGET
>> XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when
>> netfront allocating rx skbs.
>> "#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the
>> netfront to single ring, it fixed the overlap issue, but not enough.
>>
> Yes. I just saw a bug report from Xen-user list yesterday for the same
> issue in original netback (1 page ring), so the overlap issue is not
> introduced by multi-page ring implementation. If your team also sees that
> issue, do you have patch to fix that?

No. We thought your patch fixed it, and I did not check it further at 
that time.
Are you sure they are same? What is the thread title in Xen-user?
The overlap issue here exists in netfront when netfront allocates skb 
greedily. In Konrad's tree merged with your patch, netfront with 
"#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE" should hit this overlap 
issue when it runs with single ring netback.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:00:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:00: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 1UB35u-0001MM-Vc; Thu, 28 Feb 2013 13:00:18 +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 1UB35t-0001MF-Ca
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:00:17 +0000
Received: from [85.158.143.99:44149] by server-1.bemta-4.messagelabs.com id
	D6/5F-06203-0E45F215; Thu, 28 Feb 2013 13:00:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1362056414!26321240!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5140 invoked from network); 28 Feb 2013 13:00:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:00:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB35k-0007j7-VM; Thu, 28 Feb 2013 13:00:08 +0000
Date: Thu, 28 Feb 2013 13:00:08 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228130008.GE27704@ocelot.phlegethon.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F384602000078000C1D5B@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 09:58 +0000 on 28 Feb (1362045494), Jan Beulich wrote:
> >>> On 22.11.12 at 17:12, Jan Beulich wrote:
> >>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > On 22/11/12 15:55, Jan Beulich wrote:
> > >>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > >>> A quick solution would be to execute a noop function with
> > >>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
> > >>> so which does an inline iret to itself.  Which of these would you prefer?
> > >> I would actually consider avoiding to run softirqs altogether in that
> > >> case, just like native Linux doesn't do any event or scheduler
> > >> processing in that case.
> > > 
> > > That would probably be the easiest solution.
> > > 
> > > I was already going to do the same for the rentrant NMI and MCE handling
> > > case (and also the process pending upcalls checking), due to the
> > > complexities of fixing the race condition at the end of the handler.
> > > 
> > > Unfortunately, I don't think I have time to look at this issue
> > > immediately, but if it is ok to wait till the beginning of next week, I
> > 
> > That's fine of course.
> 
> So that was 3 months ago, and we're likely going to need to do
> further unfixed releases if this won't move forward. Can you
> estimate whether you'll be able to get back to this?

Let's make a step in the right direction before 4.3, at least:

commit d278beed1df2d226911dce92295411018c9bba2f
Author: Tim Deegan <tim@xen.org>
Date:   Thu Feb 28 12:42:15 2013 +0000

    vmx: handle NMIs before re-enabling interrupts.
    
    Also, switch to calling do_nmi() and explicitly re-enabling NMIs
    rather than raising a fake NMI and relying on the NMI processing to
    IRET, since that handling code is likely to change a fair amount in
    future.
    
    Signed-off-by: Tim Deegan <tim@xen.org>

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5378928..462bb0f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         vector = intr_info & INTR_INFO_VECTOR_MASK;
         if ( vector == TRAP_machine_check )
             do_machine_check(regs);
+        if ( vector == TRAP_machine_check
+             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
+                 (X86_EVENTTYPE_NMI << 8)) )
+        {
+            do_nmi(regs);
+            enable_nmis();
+        }
         break;
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
@@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
                  (X86_EVENTTYPE_NMI << 8) )
                 goto exit_and_crash;
             HVMTRACE_0D(NMI);
-            self_nmi(); /* Real NMI, vector 2: normal processing. */
+            /* Already handled above. */
             break;
         case TRAP_machine_check:
             HVMTRACE_0D(MCE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:00:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:00: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 1UB35u-0001MM-Vc; Thu, 28 Feb 2013 13:00:18 +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 1UB35t-0001MF-Ca
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:00:17 +0000
Received: from [85.158.143.99:44149] by server-1.bemta-4.messagelabs.com id
	D6/5F-06203-0E45F215; Thu, 28 Feb 2013 13:00:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1362056414!26321240!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5140 invoked from network); 28 Feb 2013 13:00:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:00:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB35k-0007j7-VM; Thu, 28 Feb 2013 13:00:08 +0000
Date: Thu, 28 Feb 2013 13:00:08 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228130008.GE27704@ocelot.phlegethon.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F384602000078000C1D5B@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 09:58 +0000 on 28 Feb (1362045494), Jan Beulich wrote:
> >>> On 22.11.12 at 17:12, Jan Beulich wrote:
> >>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > On 22/11/12 15:55, Jan Beulich wrote:
> > >>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > >>> A quick solution would be to execute a noop function with
> > >>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
> > >>> so which does an inline iret to itself.  Which of these would you prefer?
> > >> I would actually consider avoiding to run softirqs altogether in that
> > >> case, just like native Linux doesn't do any event or scheduler
> > >> processing in that case.
> > > 
> > > That would probably be the easiest solution.
> > > 
> > > I was already going to do the same for the rentrant NMI and MCE handling
> > > case (and also the process pending upcalls checking), due to the
> > > complexities of fixing the race condition at the end of the handler.
> > > 
> > > Unfortunately, I don't think I have time to look at this issue
> > > immediately, but if it is ok to wait till the beginning of next week, I
> > 
> > That's fine of course.
> 
> So that was 3 months ago, and we're likely going to need to do
> further unfixed releases if this won't move forward. Can you
> estimate whether you'll be able to get back to this?

Let's make a step in the right direction before 4.3, at least:

commit d278beed1df2d226911dce92295411018c9bba2f
Author: Tim Deegan <tim@xen.org>
Date:   Thu Feb 28 12:42:15 2013 +0000

    vmx: handle NMIs before re-enabling interrupts.
    
    Also, switch to calling do_nmi() and explicitly re-enabling NMIs
    rather than raising a fake NMI and relying on the NMI processing to
    IRET, since that handling code is likely to change a fair amount in
    future.
    
    Signed-off-by: Tim Deegan <tim@xen.org>

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5378928..462bb0f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         vector = intr_info & INTR_INFO_VECTOR_MASK;
         if ( vector == TRAP_machine_check )
             do_machine_check(regs);
+        if ( vector == TRAP_machine_check
+             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
+                 (X86_EVENTTYPE_NMI << 8)) )
+        {
+            do_nmi(regs);
+            enable_nmis();
+        }
         break;
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
@@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
                  (X86_EVENTTYPE_NMI << 8) )
                 goto exit_and_crash;
             HVMTRACE_0D(NMI);
-            self_nmi(); /* Real NMI, vector 2: normal processing. */
+            /* Already handled above. */
             break;
         case TRAP_machine_check:
             HVMTRACE_0D(MCE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:09:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3EK-0001h4-W1; Thu, 28 Feb 2013 13:09:00 +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 1UB3EJ-0001gz-89
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:08:59 +0000
Received: from [85.158.139.83:17105] by server-3.bemta-5.messagelabs.com id
	AA/90-17256-AE65F215; Thu, 28 Feb 2013 13:08:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1362056937!25534613!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 28 Feb 2013 13:08:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:08:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:08:57 +0000
Message-Id: <512F64F602000078000C1FEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:08:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
	<512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
	<1362053664.16613.2.camel@hastur.hellion.org.uk>
In-Reply-To: <1362053664.16613.2.camel@hastur.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:14, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Thu, 2013-02-28 at 11:38 +0000, Jan Beulich wrote:
>> >>> On 28.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
>> > On 27/02/13 14:33, Wei Liu wrote:
>> >> Affected files:
>> >> * event_channel.c
>> >> * sched.h
>> >> * event.h
>> >> * xen.h
>> > 
>> > Is this sort of white space patch useful?
>> 
>> I think so. It seems we still don't have an in-tree coding style
>> document,
> 
> We have CODING_STYLE at the top-level now. I did'nt hceck what it says
> about whitespace...

Oh, and I checked under docs/.

It says "There should be no trailing white space at the end of lines
(including after the opening /* of a comment block)", so a patch like
the one here ought to be welcome.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:09:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3EK-0001h4-W1; Thu, 28 Feb 2013 13:09:00 +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 1UB3EJ-0001gz-89
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:08:59 +0000
Received: from [85.158.139.83:17105] by server-3.bemta-5.messagelabs.com id
	AA/90-17256-AE65F215; Thu, 28 Feb 2013 13:08:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1362056937!25534613!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 28 Feb 2013 13:08:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:08:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:08:57 +0000
Message-Id: <512F64F602000078000C1FEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:08:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-2-git-send-email-wei.liu2@citrix.com>
	<512F3FF0.4060607@citrix.com>
	<512F4FAB02000078000C1EDB@nat28.tlf.novell.com>
	<1362053664.16613.2.camel@hastur.hellion.org.uk>
In-Reply-To: <1362053664.16613.2.camel@hastur.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 01/22] Clean up trailing whitespaces
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 13:14, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Thu, 2013-02-28 at 11:38 +0000, Jan Beulich wrote:
>> >>> On 28.02.13 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
>> > On 27/02/13 14:33, Wei Liu wrote:
>> >> Affected files:
>> >> * event_channel.c
>> >> * sched.h
>> >> * event.h
>> >> * xen.h
>> > 
>> > Is this sort of white space patch useful?
>> 
>> I think so. It seems we still don't have an in-tree coding style
>> document,
> 
> We have CODING_STYLE at the top-level now. I did'nt hceck what it says
> about whitespace...

Oh, and I checked under docs/.

It says "There should be no trailing white space at the end of lines
(including after the opening /* of a comment block)", so a patch like
the one here ought to be welcome.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:13:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:13: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 1UB3I0-0001rI-KU; Thu, 28 Feb 2013 13:12:48 +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 1UB3Hy-0001qx-9M
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:12:46 +0000
Received: from [85.158.143.99:30958] by server-2.bemta-4.messagelabs.com id
	E0/74-12656-DC75F215; Thu, 28 Feb 2013 13:12:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1362057162!24376406!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7496 invoked from network); 28 Feb 2013 13:12:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 13:12:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10257430"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 13:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 08:12:42 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB3Ht-0000ww-U8;
	Thu, 28 Feb 2013 13:12:41 +0000
Message-ID: <512F57C9.8070805@citrix.com>
Date: Thu, 28 Feb 2013 13:12:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/13 13:00, Tim Deegan wrote:
> At 09:58 +0000 on 28 Feb (1362045494), Jan Beulich wrote:
>>>>> On 22.11.12 at 17:12, Jan Beulich wrote:
>>>>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> On 22/11/12 15:55, Jan Beulich wrote:
>>>>>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>>> A quick solution would be to execute a noop function with
>>>>>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
>>>>>> so which does an inline iret to itself.  Which of these would you prefer?
>>>>> I would actually consider avoiding to run softirqs altogether in that
>>>>> case, just like native Linux doesn't do any event or scheduler
>>>>> processing in that case.
>>>> That would probably be the easiest solution.
>>>>
>>>> I was already going to do the same for the rentrant NMI and MCE handling
>>>> case (and also the process pending upcalls checking), due to the
>>>> complexities of fixing the race condition at the end of the handler.
>>>>
>>>> Unfortunately, I don't think I have time to look at this issue
>>>> immediately, but if it is ok to wait till the beginning of next week, I
>>> That's fine of course.
>> So that was 3 months ago, and we're likely going to need to do
>> further unfixed releases if this won't move forward. Can you
>> estimate whether you'll be able to get back to this?
> Let's make a step in the right direction before 4.3, at least:
>
> commit d278beed1df2d226911dce92295411018c9bba2f
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 28 12:42:15 2013 +0000
>
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

As this is functionally equivalent to the patch I was just testing.

>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 5378928..462bb0f 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          vector = intr_info & INTR_INFO_VECTOR_MASK;
>          if ( vector == TRAP_machine_check )
>              do_machine_check(regs);
> +        if ( vector == TRAP_machine_check
> +             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> +                 (X86_EVENTTYPE_NMI << 8)) )
> +        {
> +            do_nmi(regs);
> +            enable_nmis();
> +        }
>          break;
>      case EXIT_REASON_MCE_DURING_VMENTRY:
>          do_machine_check(regs);
> @@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>                   (X86_EVENTTYPE_NMI << 8) )
>                  goto exit_and_crash;
>              HVMTRACE_0D(NMI);
> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
> +            /* Already handled above. */
>              break;
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:13:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:13: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 1UB3I0-0001rI-KU; Thu, 28 Feb 2013 13:12:48 +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 1UB3Hy-0001qx-9M
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:12:46 +0000
Received: from [85.158.143.99:30958] by server-2.bemta-4.messagelabs.com id
	E0/74-12656-DC75F215; Thu, 28 Feb 2013 13:12:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1362057162!24376406!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7496 invoked from network); 28 Feb 2013 13:12:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 13:12:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10257430"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 13:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 08:12:42 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB3Ht-0000ww-U8;
	Thu, 28 Feb 2013 13:12:41 +0000
Message-ID: <512F57C9.8070805@citrix.com>
Date: Thu, 28 Feb 2013 13:12:41 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/13 13:00, Tim Deegan wrote:
> At 09:58 +0000 on 28 Feb (1362045494), Jan Beulich wrote:
>>>>> On 22.11.12 at 17:12, Jan Beulich wrote:
>>>>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> On 22/11/12 15:55, Jan Beulich wrote:
>>>>>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>>> A quick solution would be to execute a noop function with
>>>>>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
>>>>>> so which does an inline iret to itself.  Which of these would you prefer?
>>>>> I would actually consider avoiding to run softirqs altogether in that
>>>>> case, just like native Linux doesn't do any event or scheduler
>>>>> processing in that case.
>>>> That would probably be the easiest solution.
>>>>
>>>> I was already going to do the same for the rentrant NMI and MCE handling
>>>> case (and also the process pending upcalls checking), due to the
>>>> complexities of fixing the race condition at the end of the handler.
>>>>
>>>> Unfortunately, I don't think I have time to look at this issue
>>>> immediately, but if it is ok to wait till the beginning of next week, I
>>> That's fine of course.
>> So that was 3 months ago, and we're likely going to need to do
>> further unfixed releases if this won't move forward. Can you
>> estimate whether you'll be able to get back to this?
> Let's make a step in the right direction before 4.3, at least:
>
> commit d278beed1df2d226911dce92295411018c9bba2f
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 28 12:42:15 2013 +0000
>
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

As this is functionally equivalent to the patch I was just testing.

>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 5378928..462bb0f 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          vector = intr_info & INTR_INFO_VECTOR_MASK;
>          if ( vector == TRAP_machine_check )
>              do_machine_check(regs);
> +        if ( vector == TRAP_machine_check
> +             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> +                 (X86_EVENTTYPE_NMI << 8)) )
> +        {
> +            do_nmi(regs);
> +            enable_nmis();
> +        }
>          break;
>      case EXIT_REASON_MCE_DURING_VMENTRY:
>          do_machine_check(regs);
> @@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>                   (X86_EVENTTYPE_NMI << 8) )
>                  goto exit_and_crash;
>              HVMTRACE_0D(NMI);
> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
> +            /* Already handled above. */
>              break;
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:14:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:14: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 1UB3JK-00020b-3v; Thu, 28 Feb 2013 13:14:10 +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 1UB3JI-00020O-NU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:14:08 +0000
Received: from [85.158.137.99:30280] by server-7.bemta-3.messagelabs.com id
	E7/65-06591-B185F215; Thu, 28 Feb 2013 13:14:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362057143!13085203!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28483 invoked from network); 28 Feb 2013 13:12:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-217.messagelabs.com with SMTP;
	28 Feb 2013 13:12:23 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalLlLc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-158.pools.arcor-ip.net [88.65.85.158])
	by smtp.strato.de (josoe mo4) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h004a9p1SC51g7 ;
	Thu, 28 Feb 2013 14:12:08 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 2846E1884C; Thu, 28 Feb 2013 14:12:08 +0100 (CET)
Date: Thu, 28 Feb 2013 14:12:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130228131207.GA29586@aepfle.de>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130228115606.GD27704@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 Thu, Feb 28, Tim Deegan wrote:

> If you can repro this, it might be worth tracing all the refcount ops
> into a large buffer and dumping the history of this MFN on failure.

I can reproduce it with xend, will have a look next week.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:14:23 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:14: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 1UB3JK-00020b-3v; Thu, 28 Feb 2013 13:14:10 +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 1UB3JI-00020O-NU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:14:08 +0000
Received: from [85.158.137.99:30280] by server-7.bemta-3.messagelabs.com id
	E7/65-06591-B185F215; Thu, 28 Feb 2013 13:14:03 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-217.messagelabs.com!1362057143!13085203!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA1ODYxOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28483 invoked from network); 28 Feb 2013 13:12:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-217.messagelabs.com with SMTP;
	28 Feb 2013 13:12:23 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWJwKkjb5r/RwalLlLc=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-085-158.pools.arcor-ip.net [88.65.85.158])
	by smtp.strato.de (josoe mo4) (RZmta 31.18 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h004a9p1SC51g7 ;
	Thu, 28 Feb 2013 14:12:08 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 2846E1884C; Thu, 28 Feb 2013 14:12:08 +0100 (CET)
Date: Thu, 28 Feb 2013 14:12:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130228131207.GA29586@aepfle.de>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130228115606.GD27704@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5638 (2013-02-08)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 Thu, Feb 28, Tim Deegan wrote:

> If you can repro this, it might be worth tracing all the refcount ops
> into a large buffer and dumping the history of this MFN on failure.

I can reproduce it with xend, will have a look next week.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:22:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:22: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 1UB3Qj-0002Rj-7t; Thu, 28 Feb 2013 13:21:49 +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 1UB3Qh-0002Re-6u
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:21:47 +0000
Received: from [85.158.143.99:2943] by server-1.bemta-4.messagelabs.com id
	E4/57-06203-AE95F215; Thu, 28 Feb 2013 13:21:46 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1362057703!22872134!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU2MDY4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14261 invoked from network); 28 Feb 2013 13:21:44 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-216.messagelabs.com with SMTP;
	28 Feb 2013 13:21:44 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 28 Feb 2013 05:21:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,755,1355126400"; d="scan'208";a="262612991"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 28 Feb 2013 05:21:19 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 05:21:19 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 21:21:17 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
Thread-Index: AQHOFZ6Ko3AgTDHj00CkpRCMA8skS5iPQT4w
Date: Thu, 28 Feb 2013 13:21:16 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540DDD3@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
	<512F3F6D02000078000C1DA8@nat28.tlf.novell.com>
In-Reply-To: <512F3F6D02000078000C1DA8@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 28.02.13 at 09:05, "Jan Beulich" <JBeulich@suse.com> wrote:
>> And then I don't see why you would do physical MSR accesses in
>> the injection case at all. It should really be mca_wrmsr() to take
>> care of this, it just needs to have a way to know it got called in
>> the context of an injection. One fundamental question here is
>> why the invalidation of the interposed data is being done
>> before the MSR write rather than after. One thing we surely
>> don't care much about in the injection logic is interference with
>> a real #MC.
> 
> Like this (RFC only, untested so far), based on having gone through
> all call sites of mca_wrmsr():
> 
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1065,13 +1065,15 @@ static void intpose_add(unsigned int cpu
>      printk("intpose_add: interpose array full - request dropped\n");
>  }
> 
> -void intpose_inval(unsigned int cpu_nr, uint64_t msr)
> +bool_t intpose_inval(unsigned int cpu_nr, uint64_t msr)
>  {
> -    struct intpose_ent *ent;
> +    struct intpose_ent *ent = intpose_lookup(cpu_nr, msr, NULL);
> 
> -    if ((ent = intpose_lookup(cpu_nr, msr, NULL)) != NULL) {
> -        ent->cpu_nr = -1;
> -    }
> +    if ( !ent )
> +        return 0;
> +
> +    ent->cpu_nr = -1;
> +    return 1;
>  }
> 
>  #define IS_MCA_BANKREG(r) \
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -77,7 +77,7 @@ extern void mce_recoverable_register(mce
>  /* Read an MSR, checking for an interposed value first */
>  extern struct intpose_ent *intpose_lookup(unsigned int, uint64_t,
>      uint64_t *);
> -extern void intpose_inval(unsigned int, uint64_t);
> +extern bool_t intpose_inval(unsigned int, uint64_t);
> 
>  static inline uint64_t mca_rdmsr(unsigned int msr)
>  {
> @@ -89,9 +89,9 @@ static inline uint64_t mca_rdmsr(unsigne
> 
>  /* Write an MSR, invalidating any interposed value */
>  #define mca_wrmsr(msr, val) do { \
> -       intpose_inval(smp_processor_id(), msr); \
> -       wrmsrl(msr, val); \
> -} while (0)
> +    if ( !intpose_inval(smp_processor_id(), msr) ) \
> +        wrmsrl(msr, val); \
> +} while ( 0 )
> 
> 
>  /* Utility function to "logout" all architectural MCA telemetry from
> the MCA 

No, it doesn't work, considering mce broadcast to all cpus, while s/w only simulate 1 cpu.

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 Feb 28 13:22:02 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:22: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 1UB3Qj-0002Rj-7t; Thu, 28 Feb 2013 13:21:49 +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 1UB3Qh-0002Re-6u
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:21:47 +0000
Received: from [85.158.143.99:2943] by server-1.bemta-4.messagelabs.com id
	E4/57-06203-AE95F215; Thu, 28 Feb 2013 13:21:46 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1362057703!22872134!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjU2MDY4\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14261 invoked from network); 28 Feb 2013 13:21:44 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-2.tower-216.messagelabs.com with SMTP;
	28 Feb 2013 13:21:44 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 28 Feb 2013 05:21:20 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.84,755,1355126400"; d="scan'208";a="262612991"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 28 Feb 2013 05:21:19 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 28 Feb 2013 05:21:19 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.236]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.51]) with mapi id
	14.01.0355.002; Thu, 28 Feb 2013 21:21:17 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
Thread-Index: AQHOFZ6Ko3AgTDHj00CkpRCMA8skS5iPQT4w
Date: Thu, 28 Feb 2013 13:21:16 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233540DDD3@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
	<512F3F6D02000078000C1DA8@nat28.tlf.novell.com>
In-Reply-To: <512F3F6D02000078000C1DA8@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: "Ren, Yongjie" <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich wrote:
>>>> On 28.02.13 at 09:05, "Jan Beulich" <JBeulich@suse.com> wrote:
>> And then I don't see why you would do physical MSR accesses in
>> the injection case at all. It should really be mca_wrmsr() to take
>> care of this, it just needs to have a way to know it got called in
>> the context of an injection. One fundamental question here is
>> why the invalidation of the interposed data is being done
>> before the MSR write rather than after. One thing we surely
>> don't care much about in the injection logic is interference with
>> a real #MC.
> 
> Like this (RFC only, untested so far), based on having gone through
> all call sites of mca_wrmsr():
> 
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1065,13 +1065,15 @@ static void intpose_add(unsigned int cpu
>      printk("intpose_add: interpose array full - request dropped\n");
>  }
> 
> -void intpose_inval(unsigned int cpu_nr, uint64_t msr)
> +bool_t intpose_inval(unsigned int cpu_nr, uint64_t msr)
>  {
> -    struct intpose_ent *ent;
> +    struct intpose_ent *ent = intpose_lookup(cpu_nr, msr, NULL);
> 
> -    if ((ent = intpose_lookup(cpu_nr, msr, NULL)) != NULL) {
> -        ent->cpu_nr = -1;
> -    }
> +    if ( !ent )
> +        return 0;
> +
> +    ent->cpu_nr = -1;
> +    return 1;
>  }
> 
>  #define IS_MCA_BANKREG(r) \
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -77,7 +77,7 @@ extern void mce_recoverable_register(mce
>  /* Read an MSR, checking for an interposed value first */
>  extern struct intpose_ent *intpose_lookup(unsigned int, uint64_t,
>      uint64_t *);
> -extern void intpose_inval(unsigned int, uint64_t);
> +extern bool_t intpose_inval(unsigned int, uint64_t);
> 
>  static inline uint64_t mca_rdmsr(unsigned int msr)
>  {
> @@ -89,9 +89,9 @@ static inline uint64_t mca_rdmsr(unsigne
> 
>  /* Write an MSR, invalidating any interposed value */
>  #define mca_wrmsr(msr, val) do { \
> -       intpose_inval(smp_processor_id(), msr); \
> -       wrmsrl(msr, val); \
> -} while (0)
> +    if ( !intpose_inval(smp_processor_id(), msr) ) \
> +        wrmsrl(msr, val); \
> +} while ( 0 )
> 
> 
>  /* Utility function to "logout" all architectural MCA telemetry from
> the MCA 

No, it doesn't work, considering mce broadcast to all cpus, while s/w only simulate 1 cpu.

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 Feb 28 13:23:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3Ro-0002WF-Sa; Thu, 28 Feb 2013 13:22:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UB3Rn-0002W1-VW
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:22:56 +0000
Received: from [85.158.137.99:46090] by server-5.bemta-3.messagelabs.com id
	01/44-30636-F2A5F215; Thu, 28 Feb 2013 13:22:55 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1362057773!527335!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5108 invoked from network); 28 Feb 2013 13:22:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:22:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SDLDca014432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 13:21:14 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
	r1SDLC6G008348
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 13:21:13 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
	r1SDLBOK013141; Thu, 28 Feb 2013 07:21:11 -0600
Received: from [192.168.1.101] (/124.68.9.66)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 05:21:11 -0800
Message-ID: <512F59AD.2010004@oracle.com>
Date: Thu, 28 Feb 2013 21:20:45 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <20130227193752.GA641@isprime.com>
	<1362054233.2109.90.camel@zion.uk.xensource.com>
In-Reply-To: <1362054233.2109.90.camel@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: David Olsen <david.olsen@isprime.com>,
	"konrad.wilk@oracle.com" <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 BUG at drivers/net/xen-netfront.c:305
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 2013-2-28 20:23, Wei Liu wrote:
> Drop Xen-user, add Xen-devel
>
> Annie, this is the bug report I talked about. Have you encountered this
> before?

No, I didn't.
Probably it is what Konrad hit when he run netperf test with bunch of 
your patches? I did not check the issue you fixed in Konrad's tree at 
that time.

Thanks
Annie
>
>
> Wei.
>
> On Wed, 2013-02-27 at 19:37 +0000, David Olsen wrote:
>> Hello,
>>
>> I've been having an issue with a particular DomU on a server. The Dom0 runs
>> other instances just fine, this particular instance will run just fine for a
>> few hours to a few days, then it will just die out with the following error:
>>
>> ---
>> kernel BUG at drivers/net/xen-netfront.c:305!
>> invalid opcode: 0000 [#1] SMP
>> Modules linked in:
>> CPU 0
>> Pid: 0, comm: swapper/0 Not tainted 3.6.6-gentoo #1
>> RIP: e030:[<ffffffff812c14ad>]  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
>> RSP: e02b:ffff88006da03d80  EFLAGS: 00010286
>> RAX: 00000000000001ff RBX: ffff880066f88000 RCX: 0000000000000001
>> RDX: 0000000000000057 RSI: 0000000000000000 RDI: 0000000000004fc0
>> RBP: 000000000cc1323f R08: 0000000000000000 R09: 00000000000038df
>> R10: 00000000000004f1 R11: 0000000000003431 R12: 000000000cc13257
>> R13: ffff8800669c0600 R14: 00000000000004fc R15: 0000000000000057
>> FS:  00007fcb35820740(0000) GS:ffff88006da00000(0000) knlGS:0000000000000000
>> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00007fcb3052e260 CR3: 000000005aa3a000 CR4: 0000000000042660
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process swapper/0 (pid: 0, threadinfo ffffffff81586000, task ffffffff81599410)
>> Stack:
>>   0000000000000056 0000001864b24900 ffff880066f89430 ffff880066f89c80
>>   ffff880066f88000 0000000000000001 ffff880066f88758 ffff88006da18d30
>>   ffff880066f88000 0000000000000000 ffff88006da03e28 ffffffff812c2a61
>> Call Trace:
>>   <IRQ>
>>   [<ffffffff812c2a61>] ? xennet_poll+0xa0a/0xa98
>>   [<ffffffff8104e45d>] ? hrtimer_interrupt+0x112/0x1c9
>>   [<ffffffff81326920>] ? net_rx_action+0x6e/0x139
>>   [<ffffffff8103a91a>] ? __do_softirq+0x9c/0x145
>>   [<ffffffff81281e9d>] ? __xen_evtchn_do_upcall+0x1b0/0x1ed
>>   [<ffffffff8141973c>] ? call_softirq+0x1c/0x30
>>   [<ffffffff8100be36>] ? do_softirq+0x3c/0x7a
>>   [<ffffffff8103ab82>] ? irq_exit+0x42/0x9a
>>   [<ffffffff812838cb>] ? xen_evtchn_do_upcall+0x27/0x32
>>   [<ffffffff8141978e>] ? xen_do_hypervisor_callback+0x1e/0x30
>>   <EOI>
>>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>>   [<ffffffff81006836>] ? xen_safe_halt+0xc/0x13
>>   [<ffffffff81011003>] ? default_idle+0x23/0x3f
>>   [<ffffffff8101182c>] ? cpu_idle+0x60/0xa2
>>   [<ffffffff8161baca>] ? start_kernel+0x32e/0x339
>>   [<ffffffff8161b5b5>] ? repair_env_string+0x54/0x54
>>   [<ffffffff8161e2b2>] ? xen_start_kernel+0x465/0x46b
>> Code: 45 08 49 c7 45 08 00 00 00 00 48 89 42 08 48 89 10 41 0f b6 d7 49 89 5d 20 48 8d 82 a8 01 00 00 48 83 bc c3 40 07 00 00 00 74 02 <0f> 0b 48 8b 7c 24 18 4c 89 ac c3 40 07 00 00 48 89 14 24 e8 e2
>> RIP  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
>>   RSP <ffff88006da03d80>
>> ---[ end trace 77f364e88037c131 ]---
>> Kernel panic - not syncing: Fatal exception in interrupt
>> ---
>>
>> Here's the config for that instance:
>> kernel = "/xen/kernels/kernel-linux-3.6.11-domU"
>> memory = 6144
>> maxmem = 16384
>> maxvcpus = 24
>> vcpus = 2
>> name   = "REDACTED"
>> disk   = ['phy:/dev/vg/REDACTED-root,sda1,w','phy:/dev/swap/REDACTED-swap,sdb1,w']
>> root   = "/dev/xvda1 ro"
>> extra  = "console=hvc0 xencons=tty"
>> vif    = [ 'bridge=eth0,mac=00:16:3e:52:ca:47', 'bridge=eth1,mac=00:16:3e:d4:b7:d8' ]
>>
>> It's just a basic LAMP setup, with the MySQL being external to the instance.
>>
>> Running xen version 4.2.0 on a Gentoo Linux box.
>>
>> Let me know if the error looks familiar to anyone, or if there is any more
>> information I can provide.
>>
>> -d
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org
>> http://lists.xen.org/xen-users
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:23:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3Ro-0002WF-Sa; Thu, 28 Feb 2013 13:22:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1UB3Rn-0002W1-VW
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:22:56 +0000
Received: from [85.158.137.99:46090] by server-5.bemta-3.messagelabs.com id
	01/44-30636-F2A5F215; Thu, 28 Feb 2013 13:22:55 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1362057773!527335!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5108 invoked from network); 28 Feb 2013 13:22:54 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:22:54 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SDLDca014432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 13:21:14 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
	r1SDLC6G008348
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 13:21:13 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
	r1SDLBOK013141; Thu, 28 Feb 2013 07:21:11 -0600
Received: from [192.168.1.101] (/124.68.9.66)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 05:21:11 -0800
Message-ID: <512F59AD.2010004@oracle.com>
Date: Thu, 28 Feb 2013 21:20:45 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <20130227193752.GA641@isprime.com>
	<1362054233.2109.90.camel@zion.uk.xensource.com>
In-Reply-To: <1362054233.2109.90.camel@zion.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: David Olsen <david.olsen@isprime.com>,
	"konrad.wilk@oracle.com" <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 BUG at drivers/net/xen-netfront.c:305
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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 2013-2-28 20:23, Wei Liu wrote:
> Drop Xen-user, add Xen-devel
>
> Annie, this is the bug report I talked about. Have you encountered this
> before?

No, I didn't.
Probably it is what Konrad hit when he run netperf test with bunch of 
your patches? I did not check the issue you fixed in Konrad's tree at 
that time.

Thanks
Annie
>
>
> Wei.
>
> On Wed, 2013-02-27 at 19:37 +0000, David Olsen wrote:
>> Hello,
>>
>> I've been having an issue with a particular DomU on a server. The Dom0 runs
>> other instances just fine, this particular instance will run just fine for a
>> few hours to a few days, then it will just die out with the following error:
>>
>> ---
>> kernel BUG at drivers/net/xen-netfront.c:305!
>> invalid opcode: 0000 [#1] SMP
>> Modules linked in:
>> CPU 0
>> Pid: 0, comm: swapper/0 Not tainted 3.6.6-gentoo #1
>> RIP: e030:[<ffffffff812c14ad>]  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
>> RSP: e02b:ffff88006da03d80  EFLAGS: 00010286
>> RAX: 00000000000001ff RBX: ffff880066f88000 RCX: 0000000000000001
>> RDX: 0000000000000057 RSI: 0000000000000000 RDI: 0000000000004fc0
>> RBP: 000000000cc1323f R08: 0000000000000000 R09: 00000000000038df
>> R10: 00000000000004f1 R11: 0000000000003431 R12: 000000000cc13257
>> R13: ffff8800669c0600 R14: 00000000000004fc R15: 0000000000000057
>> FS:  00007fcb35820740(0000) GS:ffff88006da00000(0000) knlGS:0000000000000000
>> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00007fcb3052e260 CR3: 000000005aa3a000 CR4: 0000000000042660
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process swapper/0 (pid: 0, threadinfo ffffffff81586000, task ffffffff81599410)
>> Stack:
>>   0000000000000056 0000001864b24900 ffff880066f89430 ffff880066f89c80
>>   ffff880066f88000 0000000000000001 ffff880066f88758 ffff88006da18d30
>>   ffff880066f88000 0000000000000000 ffff88006da03e28 ffffffff812c2a61
>> Call Trace:
>>   <IRQ>
>>   [<ffffffff812c2a61>] ? xennet_poll+0xa0a/0xa98
>>   [<ffffffff8104e45d>] ? hrtimer_interrupt+0x112/0x1c9
>>   [<ffffffff81326920>] ? net_rx_action+0x6e/0x139
>>   [<ffffffff8103a91a>] ? __do_softirq+0x9c/0x145
>>   [<ffffffff81281e9d>] ? __xen_evtchn_do_upcall+0x1b0/0x1ed
>>   [<ffffffff8141973c>] ? call_softirq+0x1c/0x30
>>   [<ffffffff8100be36>] ? do_softirq+0x3c/0x7a
>>   [<ffffffff8103ab82>] ? irq_exit+0x42/0x9a
>>   [<ffffffff812838cb>] ? xen_evtchn_do_upcall+0x27/0x32
>>   [<ffffffff8141978e>] ? xen_do_hypervisor_callback+0x1e/0x30
>>   <EOI>
>>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
>>   [<ffffffff81006836>] ? xen_safe_halt+0xc/0x13
>>   [<ffffffff81011003>] ? default_idle+0x23/0x3f
>>   [<ffffffff8101182c>] ? cpu_idle+0x60/0xa2
>>   [<ffffffff8161baca>] ? start_kernel+0x32e/0x339
>>   [<ffffffff8161b5b5>] ? repair_env_string+0x54/0x54
>>   [<ffffffff8161e2b2>] ? xen_start_kernel+0x465/0x46b
>> Code: 45 08 49 c7 45 08 00 00 00 00 48 89 42 08 48 89 10 41 0f b6 d7 49 89 5d 20 48 8d 82 a8 01 00 00 48 83 bc c3 40 07 00 00 00 74 02 <0f> 0b 48 8b 7c 24 18 4c 89 ac c3 40 07 00 00 48 89 14 24 e8 e2
>> RIP  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
>>   RSP <ffff88006da03d80>
>> ---[ end trace 77f364e88037c131 ]---
>> Kernel panic - not syncing: Fatal exception in interrupt
>> ---
>>
>> Here's the config for that instance:
>> kernel = "/xen/kernels/kernel-linux-3.6.11-domU"
>> memory = 6144
>> maxmem = 16384
>> maxvcpus = 24
>> vcpus = 2
>> name   = "REDACTED"
>> disk   = ['phy:/dev/vg/REDACTED-root,sda1,w','phy:/dev/swap/REDACTED-swap,sdb1,w']
>> root   = "/dev/xvda1 ro"
>> extra  = "console=hvc0 xencons=tty"
>> vif    = [ 'bridge=eth0,mac=00:16:3e:52:ca:47', 'bridge=eth1,mac=00:16:3e:d4:b7:d8' ]
>>
>> It's just a basic LAMP setup, with the MySQL being external to the instance.
>>
>> Running xen version 4.2.0 on a Gentoo Linux box.
>>
>> Let me know if the error looks familiar to anyone, or if there is any more
>> information I can provide.
>>
>> -d
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org
>> http://lists.xen.org/xen-users
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:29:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3Xe-0002pR-N6; Thu, 28 Feb 2013 13:28:58 +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 1UB3Xd-0002pM-Er
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:28:57 +0000
Received: from [85.158.139.83:33151] by server-12.bemta-5.messagelabs.com id
	DB/B8-11486-89B5F215; Thu, 28 Feb 2013 13:28:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1362058129!27676463!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32279 invoked from network); 28 Feb 2013 13:28:50 -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; 28 Feb 2013 13:28:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:28:48 +0000
Message-Id: <512F69A002000078000C2020@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:28:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-13-git-send-email-roger.pau@citrix.com>
	<512F4B4402000078000C1E5B@nat28.tlf.novell.com>
	<512F46F5.5040105@citrix.com>
In-Reply-To: <512F46F5.5040105@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
 descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI4LjAyLjEzIGF0IDEzOjAwLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRy
aXguY29tPiB3cm90ZToKPiBPbiAyOC8wMi8xMyAxMjoxOSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+
Pj4+IE9uIDI4LjAyLjEzIGF0IDExOjI4LCBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPiB3cm90ZToKPj4+IEBAIC0xMDksNiArMTExLDE2IEBAIHR5cGVkZWYgdWludDY0X3Qg
YmxraWZfc2VjdG9yX3Q7Cj4+PiAgICovCj4+PiAgI2RlZmluZSBCTEtJRl9NQVhfU0VHTUVOVFNf
UEVSX1JFUVVFU1QgMTEKPj4+ICAKPj4+ICsjZGVmaW5lIEJMS0lGX01BWF9JTkRJUkVDVF9HUkVG
U19QRVJfUkVRVUVTVCA4Cj4+PiArCj4+PiArc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudF9h
bGlnbmVkIHsKPj4+ICsJZ3JhbnRfcmVmX3QgZ3JlZjsgICAgICAgIC8qIHJlZmVyZW5jZSB0byBJ
L08gYnVmZmVyIGZyYW1lICAgICAgICAqLwo+Pj4gKwkvKiBAZmlyc3Rfc2VjdDogZmlyc3Qgc2Vj
dG9yIGluIGZyYW1lIHRvIHRyYW5zZmVyIChpbmNsdXNpdmUpLiAgICovCj4+PiArCS8qIEBsYXN0
X3NlY3Q6IGxhc3Qgc2VjdG9yIGluIGZyYW1lIHRvIHRyYW5zZmVyIChpbmNsdXNpdmUpLiAgICAg
Ki8KPj4+ICsJdWludDhfdCAgICAgZmlyc3Rfc2VjdCwgbGFzdF9zZWN0Owo+Pj4gKwl1aW50MTZf
dCAgICBfcGFkOyAvKiBwYWRkaW5nIHRvIG1ha2UgaXQgOCBieXRlcywgc28gaXQncyBjYWNoZS1h
bGlnbmVkICovCj4+PiArfSBfX2F0dHJpYnV0ZV9fKChfX3BhY2tlZF9fKSk7Cj4+IAo+PiBXaGF0
J3MgdGhlIF9fcGFja2VkX18gZm9yIGhlcmU/Cj4gCj4gWWVzLCB0aGF0J3Mgbm90IG5lZWRlZC4K
PiAKPj4gCj4+PiArCj4+PiAgc3RydWN0IGJsa2lmX3JlcXVlc3Rfcncgewo+Pj4gIAl1aW50OF90
ICAgICAgICBucl9zZWdtZW50czsgIC8qIG51bWJlciBvZiBzZWdtZW50cyAgICAgICAgICAgICAg
ICAgICAqLwo+Pj4gIAlibGtpZl92ZGV2X3QgICBoYW5kbGU7ICAgICAgIC8qIG9ubHkgZm9yIHJl
YWQvd3JpdGUgcmVxdWVzdHMgICAgICAgICAqLwo+Pj4gQEAgLTEzOCwxMSArMTUwLDI0IEBAIHN0
cnVjdCBibGtpZl9yZXF1ZXN0X2Rpc2NhcmQgewo+Pj4gIAl1aW50OF90ICAgICAgICBfcGFkMzsK
Pj4+ICB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKPj4+ICAKPj4+ICtzdHJ1Y3QgYmxr
aWZfcmVxdWVzdF9pbmRpcmVjdCB7Cj4+PiArCXVpbnQ4X3QgICAgICAgIGluZGlyZWN0X29wOwo+
Pj4gKwl1aW50MTZfdCAgICAgICBucl9zZWdtZW50czsKPj4+ICsjaWZkZWYgQ09ORklHX1g4Nl82
NAo+Pj4gKwl1aW50MzJfdCAgICAgICBfcGFkMTsgICAgICAgIC8qIG9mZnNldG9mKGJsa2lmXy4u
Lix1LmluZGlyZWN0LmlkKSA9PSA4ICovCj4+PiArI2VuZGlmCj4+IAo+PiBFaXRoZXIgeW91IHdh
bnQgdGhlIHN0cnVjdHVyZSBiZSBwYWNrZWQgdGlnaHRseSAoYW5kIHlvdSBkb24ndCBjYXJlCj4+
IGFib3V0IG1pc2FsaWduZWQgZmllbGRzKSwgaW4gd2hpY2ggY2FzZSB5b3Ugc2hvdWxkbid0IG5l
ZWQgYSBwYWRkaW5nCj4+IGZpZWxkLiBUaGF0J3MgZXZlbiBtb3JlIHNvIGFzIHRoZXJlJ3Mgbm8g
cGFkZGluZyBiZXR3ZWVuIGluZGlyZWN0X29wCj4+IGFuZCBucl9zZWdtZW50cywgc28gZXZlcnl0
aGluZyBpcyBtaXNhbGlnbmVkIGFueXdheSwgYW5kIHRoZQo+PiBjb21tZW50IGFib3ZlIGlzIHdy
b25nIHRvbyAob2Zmc2V0b2YoKSByZWFsbHkgb3VnaHQgdG8geWllbGQgNyBpbgo+PiB0aGF0IGNh
c2UpLgo+IAo+IFRoaXMgcGFkZGluZyBpcyBiZWNhdXNlIHdlIHdhbnQgdG8gaGF2ZSB0aGUgImlk
IiBmaWVsZCBhdCB0aGUgc2FtZQo+IHBvc2l0aW9uIGFzIGJsa2lmX3JlcXVlc3RfcncsIHNvIHdl
IG5lZWQgdG8gYWRkIHRoZSBwYWRkaW5nIGZvciBpdCB0bwo+IG1hdGNoIDMyICYgNjQgYml0IGJs
a2lmX3JlcXVlc3Rfcncgc3RydWN0dXJlcywgdGhpcyBwcmV2ZW50cyBhZGRpbmcgc29tZQo+ICJp
ZiAocmVxLm9wID09IEJMS0lGX09QX0lORElSRUNUKS4uLiIgaWYgd2Ugb25seSBuZWVkIHRvIGdl
dCB0aGUgaWQgb2YKPiB0aGUgcmVxdWVzdC4KCk9oLCByaWdodCwgdGhhdCdzIGRlc2lyYWJsZSBv
ZiBjb3Vyc2UuCgo+IFRoZSBjb21tZW50IGlzIGluZGVlZCB3cm9uZywgSSd2ZSBjb3BpZWQgaXQg
ZnJvbSBibGtpZl9yZXF1ZXN0X2Rpc2NhcmQKPiBhbmQgZm9yZ290IHRvIGNoYW5nZSB0aGUgb2Zm
c2V0CgpCdXQgdGhlIG9mZnNldCBzdGF0ZWQgdGhlcmUgdGhlbiBpcyByaWdodCBhZnRlciBhbGwg
LSBJIGZvcmdvdCB0aGF0CnRoZXJlIGlzIGEgMS1ieXRlIGZpZWxkIG91dHNpZGUgdGhlIHVuaW9u
ICh0aGUgd2F5IHRoaXMgaXMgYmVpbmcgZG9uZQppbiB0aGUgdXBzdHJlYW0gTGludXggaGVhZGVy
IGlzIHJlYWxseSB1Z2x5IGltbywgYnV0IEkgZ3Vlc3MgSmVyZW15CmFuZC9vciBLb25yYWQgbGlr
ZWQgaXQgdGhhdCB3YXkpLiBUaGF0J3MgYWxzbyB3aHkgdGhlIHBhY2tlZAphdHRyaWJ1dGUgaXMg
bmVlZGVkIGhlcmUuCgpCdXQgeW91IHdpbGwgcHJvYmFibHkgd2FudCB0byBzd2l0Y2ggc2VjdG9y
X251bWJlciBhbmQgaGFuZGxlLCBzbwp0aGF0IHNlY3Rvcl9udW1iZXIgYmVjb21lcyBhbGlnbmVk
LCBhbmQgYWRkIGFub3RoZXIgMTYtYml0CnBhZGRpbmcgZmllbGQgYmV0d2VlbiBoYW5kbGUgYW5k
IGluZGlyZWN0X2dyZWZzW10uCgpJIGFsc28gd29uZGVyIHdoZXRoZXIgImluZGlyZWN0X29wIiB3
b3VsZG4ndCBiZXR0ZXIgYmUgbmFtZWQKImFjdHVhbF9vcCIgb3IganVzdCAib3AiLgoKSmFuCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:29:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3Xe-0002pR-N6; Thu, 28 Feb 2013 13:28:58 +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 1UB3Xd-0002pM-Er
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:28:57 +0000
Received: from [85.158.139.83:33151] by server-12.bemta-5.messagelabs.com id
	DB/B8-11486-89B5F215; Thu, 28 Feb 2013 13:28:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1362058129!27676463!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32279 invoked from network); 28 Feb 2013 13:28:50 -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; 28 Feb 2013 13:28:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:28:48 +0000
Message-Id: <512F69A002000078000C2020@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:28:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@citrix.com>
References: <1362047335-26402-1-git-send-email-roger.pau@citrix.com>
	<1362047335-26402-13-git-send-email-roger.pau@citrix.com>
	<512F4B4402000078000C1E5B@nat28.tlf.novell.com>
	<512F46F5.5040105@citrix.com>
In-Reply-To: <512F46F5.5040105@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect
 descriptors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

Pj4+IE9uIDI4LjAyLjEzIGF0IDEzOjAwLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBjaXRy
aXguY29tPiB3cm90ZToKPiBPbiAyOC8wMi8xMyAxMjoxOSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+
Pj4+IE9uIDI4LjAyLjEzIGF0IDExOjI4LCBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPiB3cm90ZToKPj4+IEBAIC0xMDksNiArMTExLDE2IEBAIHR5cGVkZWYgdWludDY0X3Qg
YmxraWZfc2VjdG9yX3Q7Cj4+PiAgICovCj4+PiAgI2RlZmluZSBCTEtJRl9NQVhfU0VHTUVOVFNf
UEVSX1JFUVVFU1QgMTEKPj4+ICAKPj4+ICsjZGVmaW5lIEJMS0lGX01BWF9JTkRJUkVDVF9HUkVG
U19QRVJfUkVRVUVTVCA4Cj4+PiArCj4+PiArc3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudF9h
bGlnbmVkIHsKPj4+ICsJZ3JhbnRfcmVmX3QgZ3JlZjsgICAgICAgIC8qIHJlZmVyZW5jZSB0byBJ
L08gYnVmZmVyIGZyYW1lICAgICAgICAqLwo+Pj4gKwkvKiBAZmlyc3Rfc2VjdDogZmlyc3Qgc2Vj
dG9yIGluIGZyYW1lIHRvIHRyYW5zZmVyIChpbmNsdXNpdmUpLiAgICovCj4+PiArCS8qIEBsYXN0
X3NlY3Q6IGxhc3Qgc2VjdG9yIGluIGZyYW1lIHRvIHRyYW5zZmVyIChpbmNsdXNpdmUpLiAgICAg
Ki8KPj4+ICsJdWludDhfdCAgICAgZmlyc3Rfc2VjdCwgbGFzdF9zZWN0Owo+Pj4gKwl1aW50MTZf
dCAgICBfcGFkOyAvKiBwYWRkaW5nIHRvIG1ha2UgaXQgOCBieXRlcywgc28gaXQncyBjYWNoZS1h
bGlnbmVkICovCj4+PiArfSBfX2F0dHJpYnV0ZV9fKChfX3BhY2tlZF9fKSk7Cj4+IAo+PiBXaGF0
J3MgdGhlIF9fcGFja2VkX18gZm9yIGhlcmU/Cj4gCj4gWWVzLCB0aGF0J3Mgbm90IG5lZWRlZC4K
PiAKPj4gCj4+PiArCj4+PiAgc3RydWN0IGJsa2lmX3JlcXVlc3Rfcncgewo+Pj4gIAl1aW50OF90
ICAgICAgICBucl9zZWdtZW50czsgIC8qIG51bWJlciBvZiBzZWdtZW50cyAgICAgICAgICAgICAg
ICAgICAqLwo+Pj4gIAlibGtpZl92ZGV2X3QgICBoYW5kbGU7ICAgICAgIC8qIG9ubHkgZm9yIHJl
YWQvd3JpdGUgcmVxdWVzdHMgICAgICAgICAqLwo+Pj4gQEAgLTEzOCwxMSArMTUwLDI0IEBAIHN0
cnVjdCBibGtpZl9yZXF1ZXN0X2Rpc2NhcmQgewo+Pj4gIAl1aW50OF90ICAgICAgICBfcGFkMzsK
Pj4+ICB9IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsKPj4+ICAKPj4+ICtzdHJ1Y3QgYmxr
aWZfcmVxdWVzdF9pbmRpcmVjdCB7Cj4+PiArCXVpbnQ4X3QgICAgICAgIGluZGlyZWN0X29wOwo+
Pj4gKwl1aW50MTZfdCAgICAgICBucl9zZWdtZW50czsKPj4+ICsjaWZkZWYgQ09ORklHX1g4Nl82
NAo+Pj4gKwl1aW50MzJfdCAgICAgICBfcGFkMTsgICAgICAgIC8qIG9mZnNldG9mKGJsa2lmXy4u
Lix1LmluZGlyZWN0LmlkKSA9PSA4ICovCj4+PiArI2VuZGlmCj4+IAo+PiBFaXRoZXIgeW91IHdh
bnQgdGhlIHN0cnVjdHVyZSBiZSBwYWNrZWQgdGlnaHRseSAoYW5kIHlvdSBkb24ndCBjYXJlCj4+
IGFib3V0IG1pc2FsaWduZWQgZmllbGRzKSwgaW4gd2hpY2ggY2FzZSB5b3Ugc2hvdWxkbid0IG5l
ZWQgYSBwYWRkaW5nCj4+IGZpZWxkLiBUaGF0J3MgZXZlbiBtb3JlIHNvIGFzIHRoZXJlJ3Mgbm8g
cGFkZGluZyBiZXR3ZWVuIGluZGlyZWN0X29wCj4+IGFuZCBucl9zZWdtZW50cywgc28gZXZlcnl0
aGluZyBpcyBtaXNhbGlnbmVkIGFueXdheSwgYW5kIHRoZQo+PiBjb21tZW50IGFib3ZlIGlzIHdy
b25nIHRvbyAob2Zmc2V0b2YoKSByZWFsbHkgb3VnaHQgdG8geWllbGQgNyBpbgo+PiB0aGF0IGNh
c2UpLgo+IAo+IFRoaXMgcGFkZGluZyBpcyBiZWNhdXNlIHdlIHdhbnQgdG8gaGF2ZSB0aGUgImlk
IiBmaWVsZCBhdCB0aGUgc2FtZQo+IHBvc2l0aW9uIGFzIGJsa2lmX3JlcXVlc3RfcncsIHNvIHdl
IG5lZWQgdG8gYWRkIHRoZSBwYWRkaW5nIGZvciBpdCB0bwo+IG1hdGNoIDMyICYgNjQgYml0IGJs
a2lmX3JlcXVlc3Rfcncgc3RydWN0dXJlcywgdGhpcyBwcmV2ZW50cyBhZGRpbmcgc29tZQo+ICJp
ZiAocmVxLm9wID09IEJMS0lGX09QX0lORElSRUNUKS4uLiIgaWYgd2Ugb25seSBuZWVkIHRvIGdl
dCB0aGUgaWQgb2YKPiB0aGUgcmVxdWVzdC4KCk9oLCByaWdodCwgdGhhdCdzIGRlc2lyYWJsZSBv
ZiBjb3Vyc2UuCgo+IFRoZSBjb21tZW50IGlzIGluZGVlZCB3cm9uZywgSSd2ZSBjb3BpZWQgaXQg
ZnJvbSBibGtpZl9yZXF1ZXN0X2Rpc2NhcmQKPiBhbmQgZm9yZ290IHRvIGNoYW5nZSB0aGUgb2Zm
c2V0CgpCdXQgdGhlIG9mZnNldCBzdGF0ZWQgdGhlcmUgdGhlbiBpcyByaWdodCBhZnRlciBhbGwg
LSBJIGZvcmdvdCB0aGF0CnRoZXJlIGlzIGEgMS1ieXRlIGZpZWxkIG91dHNpZGUgdGhlIHVuaW9u
ICh0aGUgd2F5IHRoaXMgaXMgYmVpbmcgZG9uZQppbiB0aGUgdXBzdHJlYW0gTGludXggaGVhZGVy
IGlzIHJlYWxseSB1Z2x5IGltbywgYnV0IEkgZ3Vlc3MgSmVyZW15CmFuZC9vciBLb25yYWQgbGlr
ZWQgaXQgdGhhdCB3YXkpLiBUaGF0J3MgYWxzbyB3aHkgdGhlIHBhY2tlZAphdHRyaWJ1dGUgaXMg
bmVlZGVkIGhlcmUuCgpCdXQgeW91IHdpbGwgcHJvYmFibHkgd2FudCB0byBzd2l0Y2ggc2VjdG9y
X251bWJlciBhbmQgaGFuZGxlLCBzbwp0aGF0IHNlY3Rvcl9udW1iZXIgYmVjb21lcyBhbGlnbmVk
LCBhbmQgYWRkIGFub3RoZXIgMTYtYml0CnBhZGRpbmcgZmllbGQgYmV0d2VlbiBoYW5kbGUgYW5k
IGluZGlyZWN0X2dyZWZzW10uCgpJIGFsc28gd29uZGVyIHdoZXRoZXIgImluZGlyZWN0X29wIiB3
b3VsZG4ndCBiZXR0ZXIgYmUgbmFtZWQKImFjdHVhbF9vcCIgb3IganVzdCAib3AiLgoKSmFuCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:31:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:31: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 1UB3Zl-0002uz-7T; Thu, 28 Feb 2013 13:31:09 +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 1UB3Zk-0002up-1R
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:31:08 +0000
Received: from [85.158.139.83:5526] by server-9.bemta-5.messagelabs.com id
	4C/9E-08547-B1C5F215; Thu, 28 Feb 2013 13:31:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1362058263!27677019!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14146 invoked from network); 28 Feb 2013 13:31:03 -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; 28 Feb 2013 13:31:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:31:02 +0000
Message-Id: <512F6A2302000078000C2023@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:30:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
	<512F3F6D02000078000C1DA8@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540DDD3@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540DDD3@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:21, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 28.02.13 at 09:05, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> And then I don't see why you would do physical MSR accesses in
>>> the injection case at all. It should really be mca_wrmsr() to take
>>> care of this, it just needs to have a way to know it got called in
>>> the context of an injection. One fundamental question here is
>>> why the invalidation of the interposed data is being done
>>> before the MSR write rather than after. One thing we surely
>>> don't care much about in the injection logic is interference with
>>> a real #MC.
>> 
>> Like this (RFC only, untested so far), based on having gone through
>> all call sites of mca_wrmsr():
>> 
>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>> @@ -1065,13 +1065,15 @@ static void intpose_add(unsigned int cpu
>>      printk("intpose_add: interpose array full - request dropped\n");
>>  }
>> 
>> -void intpose_inval(unsigned int cpu_nr, uint64_t msr)
>> +bool_t intpose_inval(unsigned int cpu_nr, uint64_t msr)
>>  {
>> -    struct intpose_ent *ent;
>> +    struct intpose_ent *ent = intpose_lookup(cpu_nr, msr, NULL);
>> 
>> -    if ((ent = intpose_lookup(cpu_nr, msr, NULL)) != NULL) {
>> -        ent->cpu_nr = -1;
>> -    }
>> +    if ( !ent )
>> +        return 0;
>> +
>> +    ent->cpu_nr = -1;
>> +    return 1;
>>  }
>> 
>>  #define IS_MCA_BANKREG(r) \
>> --- a/xen/arch/x86/cpu/mcheck/mce.h
>> +++ b/xen/arch/x86/cpu/mcheck/mce.h
>> @@ -77,7 +77,7 @@ extern void mce_recoverable_register(mce
>>  /* Read an MSR, checking for an interposed value first */
>>  extern struct intpose_ent *intpose_lookup(unsigned int, uint64_t,
>>      uint64_t *);
>> -extern void intpose_inval(unsigned int, uint64_t);
>> +extern bool_t intpose_inval(unsigned int, uint64_t);
>> 
>>  static inline uint64_t mca_rdmsr(unsigned int msr)
>>  {
>> @@ -89,9 +89,9 @@ static inline uint64_t mca_rdmsr(unsigne
>> 
>>  /* Write an MSR, invalidating any interposed value */
>>  #define mca_wrmsr(msr, val) do { \
>> -       intpose_inval(smp_processor_id(), msr); \
>> -       wrmsrl(msr, val); \
>> -} while (0)
>> +    if ( !intpose_inval(smp_processor_id(), msr) ) \
>> +        wrmsrl(msr, val); \
>> +} while ( 0 )
>> 
>> 
>>  /* Utility function to "logout" all architectural MCA telemetry from
>> the MCA 
> 
> No, it doesn't work, considering mce broadcast to all cpus, while s/w only 
> simulate 1 cpu.

I don't see how that case would be handled any better with the
invalidation happening before the MSR write (as is the case now).

Please explain, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:31:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:31: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 1UB3Zl-0002uz-7T; Thu, 28 Feb 2013 13:31:09 +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 1UB3Zk-0002up-1R
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:31:08 +0000
Received: from [85.158.139.83:5526] by server-9.bemta-5.messagelabs.com id
	4C/9E-08547-B1C5F215; Thu, 28 Feb 2013 13:31:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1362058263!27677019!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14146 invoked from network); 28 Feb 2013 13:31:03 -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; 28 Feb 2013 13:31:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:31:02 +0000
Message-Id: <512F6A2302000078000C2023@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:30:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233540CD9B@SHSMSX101.ccr.corp.intel.com>
	<512F1DE202000078000C1CB4@nat28.tlf.novell.com>
	<512F3F6D02000078000C1DA8@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233540DDD3@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233540DDD3@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yongjie Ren <yongjie.ren@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Xen/MCA: bugfix for mca bank clear
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 14:21, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 28.02.13 at 09:05, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> And then I don't see why you would do physical MSR accesses in
>>> the injection case at all. It should really be mca_wrmsr() to take
>>> care of this, it just needs to have a way to know it got called in
>>> the context of an injection. One fundamental question here is
>>> why the invalidation of the interposed data is being done
>>> before the MSR write rather than after. One thing we surely
>>> don't care much about in the injection logic is interference with
>>> a real #MC.
>> 
>> Like this (RFC only, untested so far), based on having gone through
>> all call sites of mca_wrmsr():
>> 
>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>> @@ -1065,13 +1065,15 @@ static void intpose_add(unsigned int cpu
>>      printk("intpose_add: interpose array full - request dropped\n");
>>  }
>> 
>> -void intpose_inval(unsigned int cpu_nr, uint64_t msr)
>> +bool_t intpose_inval(unsigned int cpu_nr, uint64_t msr)
>>  {
>> -    struct intpose_ent *ent;
>> +    struct intpose_ent *ent = intpose_lookup(cpu_nr, msr, NULL);
>> 
>> -    if ((ent = intpose_lookup(cpu_nr, msr, NULL)) != NULL) {
>> -        ent->cpu_nr = -1;
>> -    }
>> +    if ( !ent )
>> +        return 0;
>> +
>> +    ent->cpu_nr = -1;
>> +    return 1;
>>  }
>> 
>>  #define IS_MCA_BANKREG(r) \
>> --- a/xen/arch/x86/cpu/mcheck/mce.h
>> +++ b/xen/arch/x86/cpu/mcheck/mce.h
>> @@ -77,7 +77,7 @@ extern void mce_recoverable_register(mce
>>  /* Read an MSR, checking for an interposed value first */
>>  extern struct intpose_ent *intpose_lookup(unsigned int, uint64_t,
>>      uint64_t *);
>> -extern void intpose_inval(unsigned int, uint64_t);
>> +extern bool_t intpose_inval(unsigned int, uint64_t);
>> 
>>  static inline uint64_t mca_rdmsr(unsigned int msr)
>>  {
>> @@ -89,9 +89,9 @@ static inline uint64_t mca_rdmsr(unsigne
>> 
>>  /* Write an MSR, invalidating any interposed value */
>>  #define mca_wrmsr(msr, val) do { \
>> -       intpose_inval(smp_processor_id(), msr); \
>> -       wrmsrl(msr, val); \
>> -} while (0)
>> +    if ( !intpose_inval(smp_processor_id(), msr) ) \
>> +        wrmsrl(msr, val); \
>> +} while ( 0 )
>> 
>> 
>>  /* Utility function to "logout" all architectural MCA telemetry from
>> the MCA 
> 
> No, it doesn't work, considering mce broadcast to all cpus, while s/w only 
> simulate 1 cpu.

I don't see how that case would be handled any better with the
invalidation happening before the MSR write (as is the case now).

Please explain, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:34:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB3cq-0003B0-TK; Thu, 28 Feb 2013 13:34:20 +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 1UB3cp-0003Aj-8N
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:34:19 +0000
Received: from [85.158.139.83:18602] by server-10.bemta-5.messagelabs.com id
	2C/AC-23714-ADC5F215; Thu, 28 Feb 2013 13:34:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1362058456!27748063!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6258 invoked from network); 28 Feb 2013 13:34:17 -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; 28 Feb 2013 13:34:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:34:03 +0000
Message-Id: <512F6AD902000078000C2038@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:34:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20783.17596.210245.887390@mariner.uk.xensource.com>
In-Reply-To: <20783.17596.210245.887390@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen 4.1 PATCH] Add .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:51, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> commit 8b5e82064759e5fdc5bd41e8b5a1aca92c6527df
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Thu Feb 28 11:50:08 2013 +0000
> 
>     Add .gitignore
>     
>     Copy .gitignore from staging-4.2 current tip
>     (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e).
>     
>     Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Oh yes, please. I don't think there's any need to wait for any
ack on an obvious infrastructural change like this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:34:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB3cq-0003B0-TK; Thu, 28 Feb 2013 13:34:20 +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 1UB3cp-0003Aj-8N
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:34:19 +0000
Received: from [85.158.139.83:18602] by server-10.bemta-5.messagelabs.com id
	2C/AC-23714-ADC5F215; Thu, 28 Feb 2013 13:34:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1362058456!27748063!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6258 invoked from network); 28 Feb 2013 13:34:17 -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; 28 Feb 2013 13:34:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:34:03 +0000
Message-Id: <512F6AD902000078000C2038@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:34:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20783.17596.210245.887390@mariner.uk.xensource.com>
In-Reply-To: <20783.17596.210245.887390@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen 4.1 PATCH] Add .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 12:51, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> commit 8b5e82064759e5fdc5bd41e8b5a1aca92c6527df
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Thu Feb 28 11:50:08 2013 +0000
> 
>     Add .gitignore
>     
>     Copy .gitignore from staging-4.2 current tip
>     (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e).
>     
>     Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Oh yes, please. I don't think there's any need to wait for any
ack on an obvious infrastructural change like this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:42:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:42: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 1UB3ka-0003VL-SJ; Thu, 28 Feb 2013 13:42:20 +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 1UB3kZ-0003VG-DQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:42:19 +0000
Received: from [85.158.139.211:30320] by server-15.bemta-5.messagelabs.com id
	AE/AE-22815-ABE5F215; Thu, 28 Feb 2013 13:42:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1362058927!19650311!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9033 invoked from network); 28 Feb 2013 13:42:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:42:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:42:07 +0000
Message-Id: <512F6CBD02000078000C2045@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:42:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>

Sorry, my Acked-by just sent requires one change to be done first:

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          vector = intr_info & INTR_INFO_VECTOR_MASK;
>          if ( vector == TRAP_machine_check )
>              do_machine_check(regs);
> +        if ( vector == TRAP_machine_check

This almost certainly needs to be TRAP_nmi.

Jan

> +             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> +                 (X86_EVENTTYPE_NMI << 8)) )
> +        {
> +            do_nmi(regs);
> +            enable_nmis();
> +        }
>          break;
>      case EXIT_REASON_MCE_DURING_VMENTRY:
>          do_machine_check(regs);
> @@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>                   (X86_EVENTTYPE_NMI << 8) )
>                  goto exit_and_crash;
>              HVMTRACE_0D(NMI);
> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
> +            /* Already handled above. */
>              break;
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:42:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:42: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 1UB3ka-0003VL-SJ; Thu, 28 Feb 2013 13:42:20 +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 1UB3kZ-0003VG-DQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:42:19 +0000
Received: from [85.158.139.211:30320] by server-15.bemta-5.messagelabs.com id
	AE/AE-22815-ABE5F215; Thu, 28 Feb 2013 13:42:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1362058927!19650311!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9033 invoked from network); 28 Feb 2013 13:42:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:42:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:42:07 +0000
Message-Id: <512F6CBD02000078000C2045@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:42:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>

Sorry, my Acked-by just sent requires one change to be done first:

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          vector = intr_info & INTR_INFO_VECTOR_MASK;
>          if ( vector == TRAP_machine_check )
>              do_machine_check(regs);
> +        if ( vector == TRAP_machine_check

This almost certainly needs to be TRAP_nmi.

Jan

> +             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> +                 (X86_EVENTTYPE_NMI << 8)) )
> +        {
> +            do_nmi(regs);
> +            enable_nmis();
> +        }
>          break;
>      case EXIT_REASON_MCE_DURING_VMENTRY:
>          do_machine_check(regs);
> @@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>                   (X86_EVENTTYPE_NMI << 8) )
>                  goto exit_and_crash;
>              HVMTRACE_0D(NMI);
> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
> +            /* Already handled above. */
>              break;
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:45:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3ni-0003c3-Fe; Thu, 28 Feb 2013 13:45:34 +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 1UB3ng-0003by-Jj
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 13:45:32 +0000
Received: from [85.158.137.99:7056] by server-13.bemta-3.messagelabs.com id
	04/EA-25744-57F5F215; Thu, 28 Feb 2013 13:45:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1362059121!17478752!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjYzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16367 invoked from network); 28 Feb 2013 13:45:23 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:45:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SDjH7P029022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 13:45:18 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
	r1SDjG9p008576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 13:45:17 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
	r1SDjGbY014441; Thu, 28 Feb 2013 07:45:16 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 05:45:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 206EC1C3935; Thu, 28 Feb 2013 08:45:15 -0500 (EST)
Date: Thu, 28 Feb 2013 08:45:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20130228134515.GA31719@phenom.dumpdata.com>
References: <osstest-16764-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-16764-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 16764: 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 Wed, Feb 27, 2013 at 10:09:33PM +0000, xen.org wrote:
> flight 16764 linux-mingo-tip-master real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16764/

So how do I find out what the serial console had?
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12678
>  test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12678
>  test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12678
>  test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-i386-win           7 windows-install           fail REGR. vs. 12678
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
>  test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-i386-xl-multivcpu  7 debian-install               fail   like 12678
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-xl-credit2   15 guest-stop                   fail   never pass
>  test-amd64-amd64-qemut-win    5 xen-boot                     fail   never pass
>  test-amd64-amd64-xl-qemut-win  5 xen-boot                     fail  never pass
>  test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot               fail never pass
>  test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
>  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-xl-win-vcpus1  5 xen-boot                     fail  never pass
>  test-amd64-i386-xl-qemut-win7-amd64  7 windows-install         fail never pass
>  test-amd64-i386-qemut-win     7 windows-install              fail   never pass
>  test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install         fail never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
>  test-amd64-i386-qemut-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
> 
> version targeted for testing:
>  linux                9f6584a8bd729f61c01bed1bb4e0a010bf1a643f
> baseline version:
>  linux                d935d0f77650fea53986811ca8a2f8c726fd9857
> 
> jobs:
>  build-amd64                                                  pass    
>  build-armhf                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          fail    
>  test-amd64-i386-xl                                           fail    
>  test-amd64-i386-rhel6hvm-amd                                 pass    
>  test-amd64-i386-qemut-rhel6hvm-amd                           pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemut-win7-amd64                         fail    
>  test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  test-amd64-i386-xl-multivcpu                                 fail    
>  test-amd64-amd64-pair                                        fail    
>  test-amd64-i386-pair                                         pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          fail    
>  test-amd64-i386-pv                                           pass    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-qemut-win-vcpus1                             fail    
>  test-amd64-i386-xl-qemut-win-vcpus1                          fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-amd64-amd64-qemut-win                                   fail    
>  test-amd64-i386-qemut-win                                    fail    
>  test-amd64-amd64-xl-qemut-win                                fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-amd64-i386-xend-qemut-winxpsp3                          fail    
>  test-amd64-amd64-xl-qemut-winxpsp3                           fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-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 Feb 28 13:45:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3ni-0003c3-Fe; Thu, 28 Feb 2013 13:45:34 +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 1UB3ng-0003by-Jj
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 13:45:32 +0000
Received: from [85.158.137.99:7056] by server-13.bemta-3.messagelabs.com id
	04/EA-25744-57F5F215; Thu, 28 Feb 2013 13:45:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1362059121!17478752!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjYzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16367 invoked from network); 28 Feb 2013 13:45:23 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:45:23 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SDjH7P029022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 13:45:18 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
	r1SDjG9p008576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 13:45:17 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
	r1SDjGbY014441; Thu, 28 Feb 2013 07:45:16 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 05:45:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 206EC1C3935; Thu, 28 Feb 2013 08:45:15 -0500 (EST)
Date: Thu, 28 Feb 2013 08:45:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20130228134515.GA31719@phenom.dumpdata.com>
References: <osstest-16764-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-16764-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 16764: 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 Wed, Feb 27, 2013 at 10:09:33PM +0000, xen.org wrote:
> flight 16764 linux-mingo-tip-master real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/16764/

So how do I find out what the serial console had?
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12678
>  test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12678
>  test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12678
>  test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-i386-win           7 windows-install           fail REGR. vs. 12678
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
>  test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-i386-xl-multivcpu  7 debian-install               fail   like 12678
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-xl-credit2   15 guest-stop                   fail   never pass
>  test-amd64-amd64-qemut-win    5 xen-boot                     fail   never pass
>  test-amd64-amd64-xl-qemut-win  5 xen-boot                     fail  never pass
>  test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot               fail never pass
>  test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
>  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-xl-win-vcpus1  5 xen-boot                     fail  never pass
>  test-amd64-i386-xl-qemut-win7-amd64  7 windows-install         fail never pass
>  test-amd64-i386-qemut-win     7 windows-install              fail   never pass
>  test-amd64-i386-xl-qemut-win-vcpus1  7 windows-install         fail never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
>  test-amd64-i386-qemut-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
> 
> version targeted for testing:
>  linux                9f6584a8bd729f61c01bed1bb4e0a010bf1a643f
> baseline version:
>  linux                d935d0f77650fea53986811ca8a2f8c726fd9857
> 
> jobs:
>  build-amd64                                                  pass    
>  build-armhf                                                  pass    
>  build-i386                                                   pass    
>  build-amd64-pvops                                            pass    
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          fail    
>  test-amd64-i386-xl                                           fail    
>  test-amd64-i386-rhel6hvm-amd                                 pass    
>  test-amd64-i386-qemut-rhel6hvm-amd                           pass    
>  test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
>  test-amd64-amd64-xl-qemut-win7-amd64                         fail    
>  test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
>  test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
>  test-amd64-i386-xl-multivcpu                                 fail    
>  test-amd64-amd64-pair                                        fail    
>  test-amd64-i386-pair                                         pass    
>  test-amd64-amd64-xl-sedf-pin                                 fail    
>  test-amd64-amd64-pv                                          fail    
>  test-amd64-i386-pv                                           pass    
>  test-amd64-amd64-xl-sedf                                     fail    
>  test-amd64-i386-win-vcpus1                                   fail    
>  test-amd64-i386-qemut-win-vcpus1                             fail    
>  test-amd64-i386-xl-qemut-win-vcpus1                          fail    
>  test-amd64-i386-xl-win-vcpus1                                fail    
>  test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
>  test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
>  test-amd64-amd64-win                                         fail    
>  test-amd64-i386-win                                          fail    
>  test-amd64-amd64-qemut-win                                   fail    
>  test-amd64-i386-qemut-win                                    fail    
>  test-amd64-amd64-xl-qemut-win                                fail    
>  test-amd64-amd64-xl-win                                      fail    
>  test-amd64-i386-xend-qemut-winxpsp3                          fail    
>  test-amd64-amd64-xl-qemut-winxpsp3                           fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-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 Feb 28 13:45:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:45: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 1UB3nw-0003dM-1E; Thu, 28 Feb 2013 13:45:48 +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 1UB3nt-0003d6-PC
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:45:45 +0000
Received: from [85.158.138.51:28416] by server-10.bemta-3.messagelabs.com id
	44/F7-19664-48F5F215; Thu, 28 Feb 2013 13:45:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362058777!28592371!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26947 invoked from network); 28 Feb 2013 13:39:37 -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; 28 Feb 2013 13:39:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:39:36 +0000
Message-Id: <512F6C2502000078000C2042@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:39:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
> commit d278beed1df2d226911dce92295411018c9bba2f
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 28 12:42:15 2013 +0000
> 
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.

Isn't that a gross understatement, considering that you or Malcolm
had found that the use of self_nmi() here was actively broken?

>     Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

(realizing that dealing with the PV side of the issue will be left to
me in the end)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:45:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:45: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 1UB3nw-0003dM-1E; Thu, 28 Feb 2013 13:45:48 +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 1UB3nt-0003d6-PC
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:45:45 +0000
Received: from [85.158.138.51:28416] by server-10.bemta-3.messagelabs.com id
	44/F7-19664-48F5F215; Thu, 28 Feb 2013 13:45:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362058777!28592371!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26947 invoked from network); 28 Feb 2013 13:39:37 -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; 28 Feb 2013 13:39:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:39:36 +0000
Message-Id: <512F6C2502000078000C2042@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:39:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
> commit d278beed1df2d226911dce92295411018c9bba2f
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 28 12:42:15 2013 +0000
> 
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.

Isn't that a gross understatement, considering that you or Malcolm
had found that the use of self_nmi() here was actively broken?

>     Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Jan Beulich <jbeulich@suse.com>

(realizing that dealing with the PV side of the issue will be left to
me in the end)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:49:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:49: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 1UB3r0-0003s9-Lp; Thu, 28 Feb 2013 13:48:58 +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 1UB3qz-0003s3-8L
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:48:57 +0000
Received: from [85.158.139.211:27701] by server-1.bemta-5.messagelabs.com id
	18/1E-14063-8406F215; Thu, 28 Feb 2013 13:48:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1362059196!19651160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26394 invoked from network); 28 Feb 2013 13:46:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:46:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:46:36 +0000
Message-Id: <512F6DCB02000078000C2052@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:46:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
	<512F2FEA02000078000C1D17@nat28.tlf.novell.com>
	<512F4DE5.306@citrix.com>
In-Reply-To: <512F4DE5.306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xen-devel <xen-devel@lists.xen.org>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Ping: [PATCH] x86/MSI: add mechanism to protect
 MSI-X table from PV guest 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 28.02.13 at 13:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> For what it is worth, I think the principle is good.  One query I have
> is whether it is sensible to restrict this to dom0, as the comments
> indicate, or whether it should be permitted to be used by any domain
> with appropriate permissions to manage PCI passthrough.

No, I think this indeed ought to be restricted to Dom0 as the
original owner of all devices. If Dom0 decides to had some
devices for management to a second domain, the resource
assignment nevertheless needs to be coordinated by Dom0,
and hence the notification should also come from there.

> How do you see dom0 attempting to use these hypercalls in an example of
> passing a PCI device through to an untrusted domain?

Right now my plan is to have pciback issue the hypercall right
after having called pci_enable_device(), pending confirmation
that resources won't change after that point anymore (see
the mail I sent to Bjorn Helgaas earlier today, xen-devel Cc-ed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:49:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:49: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 1UB3r0-0003s9-Lp; Thu, 28 Feb 2013 13:48:58 +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 1UB3qz-0003s3-8L
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:48:57 +0000
Received: from [85.158.139.211:27701] by server-1.bemta-5.messagelabs.com id
	18/1E-14063-8406F215; Thu, 28 Feb 2013 13:48:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1362059196!19651160!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26394 invoked from network); 28 Feb 2013 13:46:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 13:46:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 13:46:36 +0000
Message-Id: <512F6DCB02000078000C2052@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 13:46:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <511297F502000078000BC935@nat28.tlf.novell.com>
	<5113776602000078000BCB8F@nat28.tlf.novell.com>
	<512F2FEA02000078000C1D17@nat28.tlf.novell.com>
	<512F4DE5.306@citrix.com>
In-Reply-To: <512F4DE5.306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	xen-devel <xen-devel@lists.xen.org>,
	"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] Ping: [PATCH] x86/MSI: add mechanism to protect
 MSI-X table from PV guest 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 28.02.13 at 13:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> For what it is worth, I think the principle is good.  One query I have
> is whether it is sensible to restrict this to dom0, as the comments
> indicate, or whether it should be permitted to be used by any domain
> with appropriate permissions to manage PCI passthrough.

No, I think this indeed ought to be restricted to Dom0 as the
original owner of all devices. If Dom0 decides to had some
devices for management to a second domain, the resource
assignment nevertheless needs to be coordinated by Dom0,
and hence the notification should also come from there.

> How do you see dom0 attempting to use these hypercalls in an example of
> passing a PCI device through to an untrusted domain?

Right now my plan is to have pciback issue the hypercall right
after having called pci_enable_device(), pending confirmation
that resources won't change after that point anymore (see
the mail I sent to Bjorn Helgaas earlier today, xen-devel Cc-ed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:52:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:52: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 1UB3uU-0004Ce-AW; Thu, 28 Feb 2013 13:52:34 +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 1UB3uS-0004CY-AZ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:52:32 +0000
Received: from [85.158.139.211:35537] by server-9.bemta-5.messagelabs.com id
	6B/D4-08547-F116F215; Thu, 28 Feb 2013 13:52:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1362059547!19751318!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12669 invoked from network); 28 Feb 2013 13:52:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 13:52:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SDqN22019670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 13:52:24 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
	r1SDqMjJ023452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 13:52:23 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
	r1SDqLNP022262; Thu, 28 Feb 2013 07:52:21 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 05:52:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9DC891C3935; Thu, 28 Feb 2013 08:52:20 -0500 (EST)
Date: Thu, 28 Feb 2013 08:52:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130228135220.GB31719@phenom.dumpdata.com>
References: <512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
	<512E871A.20706@oracle.com>
	<123964736.20130228005724@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <123964736.20130228005724@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Thu, Feb 28, 2013 at 12:57:24AM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, February 27, 2013, 11:22:18 PM, you wrote:
> 
> 
> > On 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
> >> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
> >>
> >>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
> >>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
> >>>>
> >>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> >>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
> >>>>> find the origin of this return value by instrumenting the involved
> >>>>> call tree.
> >>>> Just wondering, is multiple msi's per device actually supported by xen ?
> >>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> >>> use them and they work great with Xen.
> >>> BTW, this is merge:
> >>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> >>> Merge: 266d7ad af8d102
> >>> Author: Linus Torvalds <torvalds@linux-foundation.org>
> >>> Date:   Tue Feb 19 19:07:27 2013 -0800
> >>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> >>>      
> >>>      Pull x86/apic changes from Ingo Molnar:
> >>>       "Main changes:
> >>>      
> >>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
> >>>           by all relevant maintainers, by Alexander Gordeev.
> >>>      
> >>>           The advantage is that multiple AHCI ports can have multiple MSI
> >>>           irqs assigned, and can thus spread to multiple CPUs.
> >>>      
> >>>           [ Drivers can make use of this new facility via the
> >>>             pci_enable_msi_block_auto() method ]
> >>
> >>
> >>> With MSI per device, the hypercall that ends up happening is:
> >>> PHYSDEVOP_map_pirq with:
> >>>     map_irq.domid = domid;
> >>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
> >>>     map_irq.index = -1;
> >>>     map_irq.pirq = -1;
> >>>     map_irq.bus = dev->bus->number |
> >>>                   (pci_domain_nr(dev->bus) << 16);
> >>>     map_irq.devfn = dev->devfn;
> >>> Which would imply that we are doing this call multiple times?
> >>> (This is xen_initdom_setup_msi_irqs).
> >>> It looks like pci_enable_msi_block_auto is the multiple MSI one
> >>> and it should perculate down to xen_initdom_setup_msi_irqs.
> >>> Granted the xen_init.. does not do anything with the 'nvec' call.
> >>> So could I ask you try out your hunch by doing three things:
> >>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
> >>>       nvec has anything but 1 and in its loop instrument to
> >>>       see if it has more than on MSI attribute?
> >>>   2). The ahci driver has ahci_init_interrupts which only does
> >>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
> >>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
> >>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
> >>>      seperatly from 1).
> >>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
> >>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
> >>
> >> So of interest are commits:
> >> - 5ca72c4f7c412c2002363218901eba5516c476b1
> >> - 08261d87f7d1b6253ab3223756625a5c74532293
> >> - 51906e779f2b13b38f8153774c4c7163d412ffd9
> >>
> >> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
> >>
> >> x86/MSI: Support multiple MSIs in presense of IRQ remapping
> >>
> >> The MSI specification has several constraints in comparison with
> >> MSI-X, most notable of them is the inability to configure MSIs
> >> independently. As a result, it is impossible to dispatch
> >> interrupts from different queues to different CPUs. This is
> >> largely devalues the support of multiple MSIs in SMP systems.
> >>
> >> Also, a necessity to allocate a contiguous block of vector
> >> numbers for devices capable of multiple MSIs might cause a
> >> considerable pressure on x86 interrupt vector allocator and
> >> could lead to fragmentation of the interrupt vectors space.
> >>
> >> This patch overcomes both drawbacks in presense of IRQ remapping
> >> and lets devices take advantage of multiple queues and per-IRQ
> >> affinity assignments.
> >>
> >> At least makes clear why baremetal does boot and xen doesn't:
> >>
> >> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
> >>
> >> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
> >> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
> > Except that function in Xen is not run. that is b/c 
> > x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
> > While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.
> 
> > So a fix like this:
> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > index 56ab749..47f8cca 100644
> > --- a/arch/x86/pci/xen.c
> > +++ b/arch/x86/pci/xen.c
> > @@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
> > *dev, int nvec, int type)
> >          int ret = 0;
> >          struct msi_desc *msidesc;
> 
> > +       if (type == PCI_CAP_ID_MSI && nvec > 1)
> > +               return 1;
> > +
> >          list_for_each_entry(msidesc, &dev->msi_list, list) {
> >                  struct physdev_map_pirq map_irq;
> >                  domid_t domid;
> 
> 
> > (sorry about the paste getting messed up here) - ought to do it? As for 
> > example on one of my AMD machines there is no IOMMU, and this is where 
> > AHCI does work under baremetal but not under Xen.
> 
> Yes it boots again :-)

Great! Are you OK if I put 'Reported-and-Tested-by:" tag on the patch with your
name for the above quick fix?

Thanks!
> 
> [   37.742109] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
> [   37.773491] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
> [   37.798862] ahci 0000:00:11.0: SE | ahci_init_one start
> [   37.822040] ahci 0000:00:11.0: version 3.0
> [   37.841606] xen: registering gsi 19 triggering 0 polarity 1
> [   37.865577] xen: --> pirq=19 -> irq=19 (gsi=19)
> [   37.913087] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
> [   37.938519] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
> [   37.974447] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 4 type:5
> [   38.001806] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 1 type:5
> [   38.029026] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:1
> [   38.057960] ahci 0000:00:11.0: SE | n_msis: 1
> [   38.078065] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
> [   38.112045] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
> [   38.139426] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
> [   38.170664] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   38.201684] ahci 0000:00:11.0: SE | me here 1
> [   38.221977] ahci 0000:00:11.0: SE | me here 2
> [   38.244756] scsi0 : ahci
> [   38.259700] scsi1 : ahci
> [   38.274411] scsi2 : ahci
> [   38.289278] scsi3 : ahci
> [   38.303718] ata1: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff100 irq 121
> [   38.332566] ata2: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff180 irq 121
> [   38.361366] ata3: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff200 irq 121
> [   38.390080] ata4: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff280 irq 121
> [   38.418787] really_probe: dev->bus->probe(0000:00:11.0) ret: 0
> [   38.442420] really_probe: 0000:00:11.0 done ret: 1
> 
> 
> > We can future wise implement a better version of this to deal with 
> > multiple MSIs, but lets make sure to first get it booting.
> >> --
> >> Sander
> >>
> >>
> >>
> >>
> >>>> --
> >>>> Sander
> >>>>
> >>>>> 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
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:52:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13:52: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 1UB3uU-0004Ce-AW; Thu, 28 Feb 2013 13:52:34 +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 1UB3uS-0004CY-AZ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:52:32 +0000
Received: from [85.158.139.211:35537] by server-9.bemta-5.messagelabs.com id
	6B/D4-08547-F116F215; Thu, 28 Feb 2013 13:52:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1362059547!19751318!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12669 invoked from network); 28 Feb 2013 13:52:29 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 13:52:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SDqN22019670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 13:52:24 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
	r1SDqMjJ023452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 13:52:23 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
	r1SDqLNP022262; Thu, 28 Feb 2013 07:52:21 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 05:52:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9DC891C3935; Thu, 28 Feb 2013 08:52:20 -0500 (EST)
Date: Thu, 28 Feb 2013 08:52:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130228135220.GB31719@phenom.dumpdata.com>
References: <512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
	<512E871A.20706@oracle.com>
	<123964736.20130228005724@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <123964736.20130228005724@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Thu, Feb 28, 2013 at 12:57:24AM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, February 27, 2013, 11:22:18 PM, you wrote:
> 
> 
> > On 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
> >> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
> >>
> >>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
> >>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
> >>>>
> >>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> >>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
> >>>>> find the origin of this return value by instrumenting the involved
> >>>>> call tree.
> >>>> Just wondering, is multiple msi's per device actually supported by xen ?
> >>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> >>> use them and they work great with Xen.
> >>> BTW, this is merge:
> >>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> >>> Merge: 266d7ad af8d102
> >>> Author: Linus Torvalds <torvalds@linux-foundation.org>
> >>> Date:   Tue Feb 19 19:07:27 2013 -0800
> >>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> >>>      
> >>>      Pull x86/apic changes from Ingo Molnar:
> >>>       "Main changes:
> >>>      
> >>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
> >>>           by all relevant maintainers, by Alexander Gordeev.
> >>>      
> >>>           The advantage is that multiple AHCI ports can have multiple MSI
> >>>           irqs assigned, and can thus spread to multiple CPUs.
> >>>      
> >>>           [ Drivers can make use of this new facility via the
> >>>             pci_enable_msi_block_auto() method ]
> >>
> >>
> >>> With MSI per device, the hypercall that ends up happening is:
> >>> PHYSDEVOP_map_pirq with:
> >>>     map_irq.domid = domid;
> >>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
> >>>     map_irq.index = -1;
> >>>     map_irq.pirq = -1;
> >>>     map_irq.bus = dev->bus->number |
> >>>                   (pci_domain_nr(dev->bus) << 16);
> >>>     map_irq.devfn = dev->devfn;
> >>> Which would imply that we are doing this call multiple times?
> >>> (This is xen_initdom_setup_msi_irqs).
> >>> It looks like pci_enable_msi_block_auto is the multiple MSI one
> >>> and it should perculate down to xen_initdom_setup_msi_irqs.
> >>> Granted the xen_init.. does not do anything with the 'nvec' call.
> >>> So could I ask you try out your hunch by doing three things:
> >>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
> >>>       nvec has anything but 1 and in its loop instrument to
> >>>       see if it has more than on MSI attribute?
> >>>   2). The ahci driver has ahci_init_interrupts which only does
> >>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
> >>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
> >>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
> >>>      seperatly from 1).
> >>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
> >>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
> >>
> >> So of interest are commits:
> >> - 5ca72c4f7c412c2002363218901eba5516c476b1
> >> - 08261d87f7d1b6253ab3223756625a5c74532293
> >> - 51906e779f2b13b38f8153774c4c7163d412ffd9
> >>
> >> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
> >>
> >> x86/MSI: Support multiple MSIs in presense of IRQ remapping
> >>
> >> The MSI specification has several constraints in comparison with
> >> MSI-X, most notable of them is the inability to configure MSIs
> >> independently. As a result, it is impossible to dispatch
> >> interrupts from different queues to different CPUs. This is
> >> largely devalues the support of multiple MSIs in SMP systems.
> >>
> >> Also, a necessity to allocate a contiguous block of vector
> >> numbers for devices capable of multiple MSIs might cause a
> >> considerable pressure on x86 interrupt vector allocator and
> >> could lead to fragmentation of the interrupt vectors space.
> >>
> >> This patch overcomes both drawbacks in presense of IRQ remapping
> >> and lets devices take advantage of multiple queues and per-IRQ
> >> affinity assignments.
> >>
> >> At least makes clear why baremetal does boot and xen doesn't:
> >>
> >> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
> >>
> >> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
> >> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
> > Except that function in Xen is not run. that is b/c 
> > x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
> > While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.
> 
> > So a fix like this:
> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> > index 56ab749..47f8cca 100644
> > --- a/arch/x86/pci/xen.c
> > +++ b/arch/x86/pci/xen.c
> > @@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
> > *dev, int nvec, int type)
> >          int ret = 0;
> >          struct msi_desc *msidesc;
> 
> > +       if (type == PCI_CAP_ID_MSI && nvec > 1)
> > +               return 1;
> > +
> >          list_for_each_entry(msidesc, &dev->msi_list, list) {
> >                  struct physdev_map_pirq map_irq;
> >                  domid_t domid;
> 
> 
> > (sorry about the paste getting messed up here) - ought to do it? As for 
> > example on one of my AMD machines there is no IOMMU, and this is where 
> > AHCI does work under baremetal but not under Xen.
> 
> Yes it boots again :-)

Great! Are you OK if I put 'Reported-and-Tested-by:" tag on the patch with your
name for the above quick fix?

Thanks!
> 
> [   37.742109] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
> [   37.773491] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
> [   37.798862] ahci 0000:00:11.0: SE | ahci_init_one start
> [   37.822040] ahci 0000:00:11.0: version 3.0
> [   37.841606] xen: registering gsi 19 triggering 0 polarity 1
> [   37.865577] xen: --> pirq=19 -> irq=19 (gsi=19)
> [   37.913087] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
> [   37.938519] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
> [   37.974447] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 4 type:5
> [   38.001806] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 1 type:5
> [   38.029026] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:1
> [   38.057960] ahci 0000:00:11.0: SE | n_msis: 1
> [   38.078065] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
> [   38.112045] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
> [   38.139426] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
> [   38.170664] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [   38.201684] ahci 0000:00:11.0: SE | me here 1
> [   38.221977] ahci 0000:00:11.0: SE | me here 2
> [   38.244756] scsi0 : ahci
> [   38.259700] scsi1 : ahci
> [   38.274411] scsi2 : ahci
> [   38.289278] scsi3 : ahci
> [   38.303718] ata1: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff100 irq 121
> [   38.332566] ata2: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff180 irq 121
> [   38.361366] ata3: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff200 irq 121
> [   38.390080] ata4: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff280 irq 121
> [   38.418787] really_probe: dev->bus->probe(0000:00:11.0) ret: 0
> [   38.442420] really_probe: 0000:00:11.0 done ret: 1
> 
> 
> > We can future wise implement a better version of this to deal with 
> > multiple MSIs, but lets make sure to first get it booting.
> >> --
> >> Sander
> >>
> >>
> >>
> >>
> >>>> --
> >>>> Sander
> >>>>
> >>>>> 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
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:57:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3zA-0004NQ-45; Thu, 28 Feb 2013 13:57:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB3z8-0004NL-7r
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:57:22 +0000
Received: from [85.158.138.51:19549] by server-12.bemta-3.messagelabs.com id
	84/9A-01357-F326F215; Thu, 28 Feb 2013 13:57:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362059829!27923352!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29220 invoked from network); 28 Feb 2013 13:57:13 -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;
	28 Feb 2013 13:57:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9765952"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 13:57:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 08:57:08 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB3yu-0001d1-69;
	Thu, 28 Feb 2013 13:57:08 +0000
Message-ID: <1362059828.2109.97.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Thu, 28 Feb 2013 13:57:08 +0000
In-Reply-To: <512F59AD.2010004@oracle.com>
References: <20130227193752.GA641@isprime.com>
	<1362054233.2109.90.camel@zion.uk.xensource.com>
	<512F59AD.2010004@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: David Olsen <david.olsen@isprime.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] kernel BUG at drivers/net/xen-netfront.c:305
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 13:20 +0000, annie li wrote:
> On 2013-2-28 20:23, Wei Liu wrote:
> > Drop Xen-user, add Xen-devel
> >
> > Annie, this is the bug report I talked about. Have you encountered this
> > before?
> 
> No, I didn't.
> Probably it is what Konrad hit when he run netperf test with bunch of 
> your patches? I did not check the issue you fixed in Konrad's tree at 
> that time.
> 

Could be. But this is a kernel without my patches, so I'm suspecting it
is a vanilla bug.


Wei.

> Thanks
> Annie
> >
> >
> > Wei.
> >
> > On Wed, 2013-02-27 at 19:37 +0000, David Olsen wrote:
> >> Hello,
> >>
> >> I've been having an issue with a particular DomU on a server. The Dom0 runs
> >> other instances just fine, this particular instance will run just fine for a
> >> few hours to a few days, then it will just die out with the following error:
> >>
> >> ---
> >> kernel BUG at drivers/net/xen-netfront.c:305!
> >> invalid opcode: 0000 [#1] SMP
> >> Modules linked in:
> >> CPU 0
> >> Pid: 0, comm: swapper/0 Not tainted 3.6.6-gentoo #1
> >> RIP: e030:[<ffffffff812c14ad>]  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
> >> RSP: e02b:ffff88006da03d80  EFLAGS: 00010286
> >> RAX: 00000000000001ff RBX: ffff880066f88000 RCX: 0000000000000001
> >> RDX: 0000000000000057 RSI: 0000000000000000 RDI: 0000000000004fc0
> >> RBP: 000000000cc1323f R08: 0000000000000000 R09: 00000000000038df
> >> R10: 00000000000004f1 R11: 0000000000003431 R12: 000000000cc13257
> >> R13: ffff8800669c0600 R14: 00000000000004fc R15: 0000000000000057
> >> FS:  00007fcb35820740(0000) GS:ffff88006da00000(0000) knlGS:0000000000000000
> >> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> CR2: 00007fcb3052e260 CR3: 000000005aa3a000 CR4: 0000000000042660
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process swapper/0 (pid: 0, threadinfo ffffffff81586000, task ffffffff81599410)
> >> Stack:
> >>   0000000000000056 0000001864b24900 ffff880066f89430 ffff880066f89c80
> >>   ffff880066f88000 0000000000000001 ffff880066f88758 ffff88006da18d30
> >>   ffff880066f88000 0000000000000000 ffff88006da03e28 ffffffff812c2a61
> >> Call Trace:
> >>   <IRQ>
> >>   [<ffffffff812c2a61>] ? xennet_poll+0xa0a/0xa98
> >>   [<ffffffff8104e45d>] ? hrtimer_interrupt+0x112/0x1c9
> >>   [<ffffffff81326920>] ? net_rx_action+0x6e/0x139
> >>   [<ffffffff8103a91a>] ? __do_softirq+0x9c/0x145
> >>   [<ffffffff81281e9d>] ? __xen_evtchn_do_upcall+0x1b0/0x1ed
> >>   [<ffffffff8141973c>] ? call_softirq+0x1c/0x30
> >>   [<ffffffff8100be36>] ? do_softirq+0x3c/0x7a
> >>   [<ffffffff8103ab82>] ? irq_exit+0x42/0x9a
> >>   [<ffffffff812838cb>] ? xen_evtchn_do_upcall+0x27/0x32
> >>   [<ffffffff8141978e>] ? xen_do_hypervisor_callback+0x1e/0x30
> >>   <EOI>
> >>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >>   [<ffffffff81006836>] ? xen_safe_halt+0xc/0x13
> >>   [<ffffffff81011003>] ? default_idle+0x23/0x3f
> >>   [<ffffffff8101182c>] ? cpu_idle+0x60/0xa2
> >>   [<ffffffff8161baca>] ? start_kernel+0x32e/0x339
> >>   [<ffffffff8161b5b5>] ? repair_env_string+0x54/0x54
> >>   [<ffffffff8161e2b2>] ? xen_start_kernel+0x465/0x46b
> >> Code: 45 08 49 c7 45 08 00 00 00 00 48 89 42 08 48 89 10 41 0f b6 d7 49 89 5d 20 48 8d 82 a8 01 00 00 48 83 bc c3 40 07 00 00 00 74 02 <0f> 0b 48 8b 7c 24 18 4c 89 ac c3 40 07 00 00 48 89 14 24 e8 e2
> >> RIP  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
> >>   RSP <ffff88006da03d80>
> >> ---[ end trace 77f364e88037c131 ]---
> >> Kernel panic - not syncing: Fatal exception in interrupt
> >> ---
> >>
> >> Here's the config for that instance:
> >> kernel = "/xen/kernels/kernel-linux-3.6.11-domU"
> >> memory = 6144
> >> maxmem = 16384
> >> maxvcpus = 24
> >> vcpus = 2
> >> name   = "REDACTED"
> >> disk   = ['phy:/dev/vg/REDACTED-root,sda1,w','phy:/dev/swap/REDACTED-swap,sdb1,w']
> >> root   = "/dev/xvda1 ro"
> >> extra  = "console=hvc0 xencons=tty"
> >> vif    = [ 'bridge=eth0,mac=00:16:3e:52:ca:47', 'bridge=eth1,mac=00:16:3e:d4:b7:d8' ]
> >>
> >> It's just a basic LAMP setup, with the MySQL being external to the instance.
> >>
> >> Running xen version 4.2.0 on a Gentoo Linux box.
> >>
> >> Let me know if the error looks familiar to anyone, or if there is any more
> >> information I can provide.
> >>
> >> -d
> >>
> >>
> >> _______________________________________________
> >> Xen-users mailing list
> >> Xen-users@lists.xen.org
> >> http://lists.xen.org/xen-users
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:57:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB3zA-0004NQ-45; Thu, 28 Feb 2013 13:57:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB3z8-0004NL-7r
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:57:22 +0000
Received: from [85.158.138.51:19549] by server-12.bemta-3.messagelabs.com id
	84/9A-01357-F326F215; Thu, 28 Feb 2013 13:57:19 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362059829!27923352!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29220 invoked from network); 28 Feb 2013 13:57:13 -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;
	28 Feb 2013 13:57:13 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9765952"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 13:57:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 08:57:08 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB3yu-0001d1-69;
	Thu, 28 Feb 2013 13:57:08 +0000
Message-ID: <1362059828.2109.97.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Thu, 28 Feb 2013 13:57:08 +0000
In-Reply-To: <512F59AD.2010004@oracle.com>
References: <20130227193752.GA641@isprime.com>
	<1362054233.2109.90.camel@zion.uk.xensource.com>
	<512F59AD.2010004@oracle.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: David Olsen <david.olsen@isprime.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] kernel BUG at drivers/net/xen-netfront.c:305
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 13:20 +0000, annie li wrote:
> On 2013-2-28 20:23, Wei Liu wrote:
> > Drop Xen-user, add Xen-devel
> >
> > Annie, this is the bug report I talked about. Have you encountered this
> > before?
> 
> No, I didn't.
> Probably it is what Konrad hit when he run netperf test with bunch of 
> your patches? I did not check the issue you fixed in Konrad's tree at 
> that time.
> 

Could be. But this is a kernel without my patches, so I'm suspecting it
is a vanilla bug.


Wei.

> Thanks
> Annie
> >
> >
> > Wei.
> >
> > On Wed, 2013-02-27 at 19:37 +0000, David Olsen wrote:
> >> Hello,
> >>
> >> I've been having an issue with a particular DomU on a server. The Dom0 runs
> >> other instances just fine, this particular instance will run just fine for a
> >> few hours to a few days, then it will just die out with the following error:
> >>
> >> ---
> >> kernel BUG at drivers/net/xen-netfront.c:305!
> >> invalid opcode: 0000 [#1] SMP
> >> Modules linked in:
> >> CPU 0
> >> Pid: 0, comm: swapper/0 Not tainted 3.6.6-gentoo #1
> >> RIP: e030:[<ffffffff812c14ad>]  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
> >> RSP: e02b:ffff88006da03d80  EFLAGS: 00010286
> >> RAX: 00000000000001ff RBX: ffff880066f88000 RCX: 0000000000000001
> >> RDX: 0000000000000057 RSI: 0000000000000000 RDI: 0000000000004fc0
> >> RBP: 000000000cc1323f R08: 0000000000000000 R09: 00000000000038df
> >> R10: 00000000000004f1 R11: 0000000000003431 R12: 000000000cc13257
> >> R13: ffff8800669c0600 R14: 00000000000004fc R15: 0000000000000057
> >> FS:  00007fcb35820740(0000) GS:ffff88006da00000(0000) knlGS:0000000000000000
> >> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> CR2: 00007fcb3052e260 CR3: 000000005aa3a000 CR4: 0000000000042660
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process swapper/0 (pid: 0, threadinfo ffffffff81586000, task ffffffff81599410)
> >> Stack:
> >>   0000000000000056 0000001864b24900 ffff880066f89430 ffff880066f89c80
> >>   ffff880066f88000 0000000000000001 ffff880066f88758 ffff88006da18d30
> >>   ffff880066f88000 0000000000000000 ffff88006da03e28 ffffffff812c2a61
> >> Call Trace:
> >>   <IRQ>
> >>   [<ffffffff812c2a61>] ? xennet_poll+0xa0a/0xa98
> >>   [<ffffffff8104e45d>] ? hrtimer_interrupt+0x112/0x1c9
> >>   [<ffffffff81326920>] ? net_rx_action+0x6e/0x139
> >>   [<ffffffff8103a91a>] ? __do_softirq+0x9c/0x145
> >>   [<ffffffff81281e9d>] ? __xen_evtchn_do_upcall+0x1b0/0x1ed
> >>   [<ffffffff8141973c>] ? call_softirq+0x1c/0x30
> >>   [<ffffffff8100be36>] ? do_softirq+0x3c/0x7a
> >>   [<ffffffff8103ab82>] ? irq_exit+0x42/0x9a
> >>   [<ffffffff812838cb>] ? xen_evtchn_do_upcall+0x27/0x32
> >>   [<ffffffff8141978e>] ? xen_do_hypervisor_callback+0x1e/0x30
> >>   <EOI>
> >>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >>   [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> >>   [<ffffffff81006836>] ? xen_safe_halt+0xc/0x13
> >>   [<ffffffff81011003>] ? default_idle+0x23/0x3f
> >>   [<ffffffff8101182c>] ? cpu_idle+0x60/0xa2
> >>   [<ffffffff8161baca>] ? start_kernel+0x32e/0x339
> >>   [<ffffffff8161b5b5>] ? repair_env_string+0x54/0x54
> >>   [<ffffffff8161e2b2>] ? xen_start_kernel+0x465/0x46b
> >> Code: 45 08 49 c7 45 08 00 00 00 00 48 89 42 08 48 89 10 41 0f b6 d7 49 89 5d 20 48 8d 82 a8 01 00 00 48 83 bc c3 40 07 00 00 00 74 02 <0f> 0b 48 8b 7c 24 18 4c 89 ac c3 40 07 00 00 48 89 14 24 e8 e2
> >> RIP  [<ffffffff812c14ad>] xennet_alloc_rx_buffers+0x1d7/0x2fe
> >>   RSP <ffff88006da03d80>
> >> ---[ end trace 77f364e88037c131 ]---
> >> Kernel panic - not syncing: Fatal exception in interrupt
> >> ---
> >>
> >> Here's the config for that instance:
> >> kernel = "/xen/kernels/kernel-linux-3.6.11-domU"
> >> memory = 6144
> >> maxmem = 16384
> >> maxvcpus = 24
> >> vcpus = 2
> >> name   = "REDACTED"
> >> disk   = ['phy:/dev/vg/REDACTED-root,sda1,w','phy:/dev/swap/REDACTED-swap,sdb1,w']
> >> root   = "/dev/xvda1 ro"
> >> extra  = "console=hvc0 xencons=tty"
> >> vif    = [ 'bridge=eth0,mac=00:16:3e:52:ca:47', 'bridge=eth1,mac=00:16:3e:d4:b7:d8' ]
> >>
> >> It's just a basic LAMP setup, with the MySQL being external to the instance.
> >>
> >> Running xen version 4.2.0 on a Gentoo Linux box.
> >>
> >> Let me know if the error looks familiar to anyone, or if there is any more
> >> information I can provide.
> >>
> >> -d
> >>
> >>
> >> _______________________________________________
> >> Xen-users mailing list
> >> Xen-users@lists.xen.org
> >> http://lists.xen.org/xen-users
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:59:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB40y-0004TD-Kj; Thu, 28 Feb 2013 13:59:16 +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 1UB40x-0004T5-Rd
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:59:15 +0000
Received: from [85.158.143.99:22793] by server-1.bemta-4.messagelabs.com id
	A6/B1-06203-2B26F215; Thu, 28 Feb 2013 13:59:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1362059952!29195086!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8304 invoked from network); 28 Feb 2013 13:59:14 -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;
	28 Feb 2013 13:59:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9766436"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 13:59:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 08:59:12 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB40t-0001ec-OW;
	Thu, 28 Feb 2013 13:59:11 +0000
Message-ID: <1362059951.2109.99.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 28 Feb 2013 13:59:11 +0000
In-Reply-To: <512F4648.3020800@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
	<512F4648.3020800@citrix.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to
 max_evtchns inline 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

On Thu, 2013-02-28 at 11:58 +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > The calculation of max event channels depends on the actual ABI in use. Try to
> > avoid gcc-ism macro.
> [...]
> > +static inline unsigned int max_evtchns(struct domain *d)
> > +{
> > +    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> > +}
> 
> This value doesn't change over the life of the domain. Calculate it once
> and save it in a new d->max_evtchns field?
> 

This can change during domain life cycle. But it is doable to save it in
d->max_evtchns and change it when necessary.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 13:59:29 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 13: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 1UB40y-0004TD-Kj; Thu, 28 Feb 2013 13:59:16 +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 1UB40x-0004T5-Rd
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 13:59:15 +0000
Received: from [85.158.143.99:22793] by server-1.bemta-4.messagelabs.com id
	A6/B1-06203-2B26F215; Thu, 28 Feb 2013 13:59:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1362059952!29195086!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUwMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8304 invoked from network); 28 Feb 2013 13:59:14 -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;
	28 Feb 2013 13:59:14 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="9766436"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 13:59:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 08:59:12 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB40t-0001ec-OW;
	Thu, 28 Feb 2013 13:59:11 +0000
Message-ID: <1362059951.2109.99.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 28 Feb 2013 13:59:11 +0000
In-Reply-To: <512F4648.3020800@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-6-git-send-email-wei.liu2@citrix.com>
	<512F4648.3020800@citrix.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to
 max_evtchns inline 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

On Thu, 2013-02-28 at 11:58 +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > The calculation of max event channels depends on the actual ABI in use. Try to
> > avoid gcc-ism macro.
> [...]
> > +static inline unsigned int max_evtchns(struct domain *d)
> > +{
> > +    return BITS_PER_EVTCHN_WORD(d) * BITS_PER_EVTCHN_WORD(d);
> > +}
> 
> This value doesn't change over the life of the domain. Calculate it once
> and save it in a new d->max_evtchns field?
> 

This can change during domain life cycle. But it is doable to save it in
d->max_evtchns and change it when necessary.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:01:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB42y-0004n2-5f; Thu, 28 Feb 2013 14:01:20 +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 1UB42w-0004lL-MS
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:01:18 +0000
Received: from [85.158.139.83:59543] by server-2.bemta-5.messagelabs.com id
	06/E2-23989-D236F215; Thu, 28 Feb 2013 14:01:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1362060076!25107279!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 833 invoked from network); 28 Feb 2013 14:01:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:01:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 14:00:27 +0000
Message-Id: <512F710A02000078000C2081@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 14:00:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <osstest-16764-mainreport@xen.org>
	<20130228134515.GA31719@phenom.dumpdata.com>
In-Reply-To: <20130228134515.GA31719@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen.org" <ian.jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 16764: 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 28.02.13 at 14:45, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Feb 27, 2013 at 10:09:33PM +0000, xen.org wrote:
>> flight 16764 linux-mingo-tip-master real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16764/ 
> 
> So how do I find out what the serial console had?

Use the link above, click the head of the column having the
regression, and you'll see a list of log files, the serial ones
among them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:01:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB42y-0004n2-5f; Thu, 28 Feb 2013 14:01:20 +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 1UB42w-0004lL-MS
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:01:18 +0000
Received: from [85.158.139.83:59543] by server-2.bemta-5.messagelabs.com id
	06/E2-23989-D236F215; Thu, 28 Feb 2013 14:01:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1362060076!25107279!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 833 invoked from network); 28 Feb 2013 14:01:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:01:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 14:00:27 +0000
Message-Id: <512F710A02000078000C2081@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 14:00:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <osstest-16764-mainreport@xen.org>
	<20130228134515.GA31719@phenom.dumpdata.com>
In-Reply-To: <20130228134515.GA31719@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen.org" <ian.jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 16764: 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 28.02.13 at 14:45, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Feb 27, 2013 at 10:09:33PM +0000, xen.org wrote:
>> flight 16764 linux-mingo-tip-master real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/16764/ 
> 
> So how do I find out what the serial console had?

Use the link above, click the head of the column having the
regression, and you'll see a list of log files, the serial ones
among them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:05:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB46N-000514-AC; Thu, 28 Feb 2013 14:04:51 +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 1UB46L-00050z-LN
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:04:49 +0000
Received: from [193.109.254.147:60300] by server-9.bemta-14.messagelabs.com id
	24/98-30867-0046F215; Thu, 28 Feb 2013 14:04:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1362059839!10028261!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12554 invoked from network); 28 Feb 2013 13:57:28 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2013 13:57:28 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51304 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 1UB3wu-0007Rf-Gw; Thu, 28 Feb 2013 14:55:04 +0100
Date: Thu, 28 Feb 2013 14:57:14 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1407215117.20130228145714@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130228135220.GB31719@phenom.dumpdata.com>
References: <512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
	<512E871A.20706@oracle.com>
	<123964736.20130228005724@eikelenboom.it>
	<20130228135220.GB31719@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Thursday, February 28, 2013, 2:52:20 PM, you wrote:

> On Thu, Feb 28, 2013 at 12:57:24AM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, February 27, 2013, 11:22:18 PM, you wrote:
>> 
>> 
>> > On 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
>> >> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
>> >>
>> >>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>> >>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>> >>>>
>> >>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> >>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> >>>>> find the origin of this return value by instrumenting the involved
>> >>>>> call tree.
>> >>>> Just wondering, is multiple msi's per device actually supported by xen ?
>> >>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
>> >>> use them and they work great with Xen.
>> >>> BTW, this is merge:
>> >>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
>> >>> Merge: 266d7ad af8d102
>> >>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> >>> Date:   Tue Feb 19 19:07:27 2013 -0800
>> >>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> >>>      
>> >>>      Pull x86/apic changes from Ingo Molnar:
>> >>>       "Main changes:
>> >>>      
>> >>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>> >>>           by all relevant maintainers, by Alexander Gordeev.
>> >>>      
>> >>>           The advantage is that multiple AHCI ports can have multiple MSI
>> >>>           irqs assigned, and can thus spread to multiple CPUs.
>> >>>      
>> >>>           [ Drivers can make use of this new facility via the
>> >>>             pci_enable_msi_block_auto() method ]
>> >>
>> >>
>> >>> With MSI per device, the hypercall that ends up happening is:
>> >>> PHYSDEVOP_map_pirq with:
>> >>>     map_irq.domid = domid;
>> >>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>> >>>     map_irq.index = -1;
>> >>>     map_irq.pirq = -1;
>> >>>     map_irq.bus = dev->bus->number |
>> >>>                   (pci_domain_nr(dev->bus) << 16);
>> >>>     map_irq.devfn = dev->devfn;
>> >>> Which would imply that we are doing this call multiple times?
>> >>> (This is xen_initdom_setup_msi_irqs).
>> >>> It looks like pci_enable_msi_block_auto is the multiple MSI one
>> >>> and it should perculate down to xen_initdom_setup_msi_irqs.
>> >>> Granted the xen_init.. does not do anything with the 'nvec' call.
>> >>> So could I ask you try out your hunch by doing three things:
>> >>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
>> >>>       nvec has anything but 1 and in its loop instrument to
>> >>>       see if it has more than on MSI attribute?
>> >>>   2). The ahci driver has ahci_init_interrupts which only does
>> >>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>> >>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>> >>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>> >>>      seperatly from 1).
>> >>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>> >>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
>> >>
>> >> So of interest are commits:
>> >> - 5ca72c4f7c412c2002363218901eba5516c476b1
>> >> - 08261d87f7d1b6253ab3223756625a5c74532293
>> >> - 51906e779f2b13b38f8153774c4c7163d412ffd9
>> >>
>> >> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
>> >>
>> >> x86/MSI: Support multiple MSIs in presense of IRQ remapping
>> >>
>> >> The MSI specification has several constraints in comparison with
>> >> MSI-X, most notable of them is the inability to configure MSIs
>> >> independently. As a result, it is impossible to dispatch
>> >> interrupts from different queues to different CPUs. This is
>> >> largely devalues the support of multiple MSIs in SMP systems.
>> >>
>> >> Also, a necessity to allocate a contiguous block of vector
>> >> numbers for devices capable of multiple MSIs might cause a
>> >> considerable pressure on x86 interrupt vector allocator and
>> >> could lead to fragmentation of the interrupt vectors space.
>> >>
>> >> This patch overcomes both drawbacks in presense of IRQ remapping
>> >> and lets devices take advantage of multiple queues and per-IRQ
>> >> affinity assignments.
>> >>
>> >> At least makes clear why baremetal does boot and xen doesn't:
>> >>
>> >> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
>> >>
>> >> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
>> >> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
>> > Except that function in Xen is not run. that is b/c 
>> > x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
>> > While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.
>> 
>> > So a fix like this:
>> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> > index 56ab749..47f8cca 100644
>> > --- a/arch/x86/pci/xen.c
>> > +++ b/arch/x86/pci/xen.c
>> > @@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
>> > *dev, int nvec, int type)
>> >          int ret = 0;
>> >          struct msi_desc *msidesc;
>> 
>> > +       if (type == PCI_CAP_ID_MSI && nvec > 1)
>> > +               return 1;
>> > +
>> >          list_for_each_entry(msidesc, &dev->msi_list, list) {
>> >                  struct physdev_map_pirq map_irq;
>> >                  domid_t domid;
>> 
>> 
>> > (sorry about the paste getting messed up here) - ought to do it? As for 
>> > example on one of my AMD machines there is no IOMMU, and this is where 
>> > AHCI does work under baremetal but not under Xen.
>> 
>> Yes it boots again :-)

> Great! Are you OK if I put 'Reported-and-Tested-by:" tag on the patch with your
> name for the above quick fix?

Sure !

> Thanks!
>> 
>> [   37.742109] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
>> [   37.773491] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
>> [   37.798862] ahci 0000:00:11.0: SE | ahci_init_one start
>> [   37.822040] ahci 0000:00:11.0: version 3.0
>> [   37.841606] xen: registering gsi 19 triggering 0 polarity 1
>> [   37.865577] xen: --> pirq=19 -> irq=19 (gsi=19)
>> [   37.913087] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
>> [   37.938519] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
>> [   37.974447] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 4 type:5
>> [   38.001806] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 1 type:5
>> [   38.029026] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:1
>> [   38.057960] ahci 0000:00:11.0: SE | n_msis: 1
>> [   38.078065] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
>> [   38.112045] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
>> [   38.139426] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
>> [   38.170664] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
>> [   38.201684] ahci 0000:00:11.0: SE | me here 1
>> [   38.221977] ahci 0000:00:11.0: SE | me here 2
>> [   38.244756] scsi0 : ahci
>> [   38.259700] scsi1 : ahci
>> [   38.274411] scsi2 : ahci
>> [   38.289278] scsi3 : ahci
>> [   38.303718] ata1: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff100 irq 121
>> [   38.332566] ata2: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff180 irq 121
>> [   38.361366] ata3: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff200 irq 121
>> [   38.390080] ata4: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff280 irq 121
>> [   38.418787] really_probe: dev->bus->probe(0000:00:11.0) ret: 0
>> [   38.442420] really_probe: 0000:00:11.0 done ret: 1
>> 
>> 
>> > We can future wise implement a better version of this to deal with 
>> > multiple MSIs, but lets make sure to first get it booting.
>> >> --
>> >> Sander
>> >>
>> >>
>> >>
>> >>
>> >>>> --
>> >>>> Sander
>> >>>>
>> >>>>> 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
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:05:08 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB46N-000514-AC; Thu, 28 Feb 2013 14:04:51 +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 1UB46L-00050z-LN
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:04:49 +0000
Received: from [193.109.254.147:60300] by server-9.bemta-14.messagelabs.com id
	24/98-30867-0046F215; Thu, 28 Feb 2013 14:04:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1362059839!10028261!1
X-Originating-IP: [84.200.39.61]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12554 invoked from network); 28 Feb 2013 13:57:28 -0000
Received: from unknown (HELO smtp.eikelenboom.it) (84.200.39.61)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Feb 2013 13:57:28 -0000
Received: from 224-66-ftth.on.nl ([88.159.66.224]:51304 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 1UB3wu-0007Rf-Gw; Thu, 28 Feb 2013 14:55:04 +0100
Date: Thu, 28 Feb 2013 14:57:14 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1407215117.20130228145714@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20130228135220.GB31719@phenom.dumpdata.com>
References: <512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<171656525.20130227214153@eikelenboom.it>
	<512E871A.20706@oracle.com>
	<123964736.20130228005724@eikelenboom.it>
	<20130228135220.GB31719@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
	not detected 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


Thursday, February 28, 2013, 2:52:20 PM, you wrote:

> On Thu, Feb 28, 2013 at 12:57:24AM +0100, Sander Eikelenboom wrote:
>> 
>> Wednesday, February 27, 2013, 11:22:18 PM, you wrote:
>> 
>> 
>> > On 2/27/2013 3:41 PM, Sander Eikelenboom wrote:
>> >> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
>> >>
>> >>> On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
>> >>>> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
>> >>>>
>> >>>>>>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>>>>>    [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
>> >>>>> Which is -EINVAL. With nothing else printed, I'm afraid you need to
>> >>>>> find the origin of this return value by instrumenting the involved
>> >>>>> call tree.
>> >>>> Just wondering, is multiple msi's per device actually supported by xen ?
>> >>> That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
>> >>> use them and they work great with Xen.
>> >>> BTW, this is merge:
>> >>> ommit 5800700f66678ea5c85e7d62b138416070bf7f60
>> >>> Merge: 266d7ad af8d102
>> >>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> >>> Date:   Tue Feb 19 19:07:27 2013 -0800
>> >>>      Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> >>>      
>> >>>      Pull x86/apic changes from Ingo Molnar:
>> >>>       "Main changes:
>> >>>      
>> >>>         - Multiple MSI support added to the APIC, PCI and AHCI code - acked
>> >>>           by all relevant maintainers, by Alexander Gordeev.
>> >>>      
>> >>>           The advantage is that multiple AHCI ports can have multiple MSI
>> >>>           irqs assigned, and can thus spread to multiple CPUs.
>> >>>      
>> >>>           [ Drivers can make use of this new facility via the
>> >>>             pci_enable_msi_block_auto() method ]
>> >>
>> >>
>> >>> With MSI per device, the hypercall that ends up happening is:
>> >>> PHYSDEVOP_map_pirq with:
>> >>>     map_irq.domid = domid;
>> >>>     map_irq.type = MAP_PIRQ_TYPE_MSI_SEG;
>> >>>     map_irq.index = -1;
>> >>>     map_irq.pirq = -1;
>> >>>     map_irq.bus = dev->bus->number |
>> >>>                   (pci_domain_nr(dev->bus) << 16);
>> >>>     map_irq.devfn = dev->devfn;
>> >>> Which would imply that we are doing this call multiple times?
>> >>> (This is xen_initdom_setup_msi_irqs).
>> >>> It looks like pci_enable_msi_block_auto is the multiple MSI one
>> >>> and it should perculate down to xen_initdom_setup_msi_irqs.
>> >>> Granted the xen_init.. does not do anything with the 'nvec' call.
>> >>> So could I ask you try out your hunch by doing three things:
>> >>>   1). Instrument xen_initdom_setup_msi_irqs to see if the
>> >>>       nvec has anything but 1 and in its loop instrument to
>> >>>       see if it has more than on MSI attribute?
>> >>>   2). The ahci driver has ahci_init_interrupts which only does
>> >>>     the multiple MSI thing if AHCI_HFLAG_NO_MSI is not set.
>> >>>      If you edit drivers/ata/ahci ahci_port_info for the SB600 (or 700?)
>> >>>      to have AHCI_HFLAG_NO_MSI flag (you probably want to do this
>> >>>      seperatly from 1).
>> >>>   3). Checkout before merge 5800700f66678ea5c85e7d62b138416070bf7f60
>> >>>      and try 266d7ad7f4fe2f44b91561f5b812115c1b3018ab?
>> >>
>> >> So of interest are commits:
>> >> - 5ca72c4f7c412c2002363218901eba5516c476b1
>> >> - 08261d87f7d1b6253ab3223756625a5c74532293
>> >> - 51906e779f2b13b38f8153774c4c7163d412ffd9
>> >>
>> >> Hmmm reading the commit message of 51906e779f2b13b38f8153774c4c7163d412ffd9:
>> >>
>> >> x86/MSI: Support multiple MSIs in presense of IRQ remapping
>> >>
>> >> The MSI specification has several constraints in comparison with
>> >> MSI-X, most notable of them is the inability to configure MSIs
>> >> independently. As a result, it is impossible to dispatch
>> >> interrupts from different queues to different CPUs. This is
>> >> largely devalues the support of multiple MSIs in SMP systems.
>> >>
>> >> Also, a necessity to allocate a contiguous block of vector
>> >> numbers for devices capable of multiple MSIs might cause a
>> >> considerable pressure on x86 interrupt vector allocator and
>> >> could lead to fragmentation of the interrupt vectors space.
>> >>
>> >> This patch overcomes both drawbacks in presense of IRQ remapping
>> >> and lets devices take advantage of multiple queues and per-IRQ
>> >> affinity assignments.
>> >>
>> >> At least makes clear why baremetal does boot and xen doesn't:
>> >>
>> >> Baremetal behaves differently and thus boots because interrupt remapping gets disabled on boot by the kernel iommu code due to the buggy bios iommu errata, so according to the commit message above it doesn't even try the multiple MSI per device scenario.
>> >>
>> >> So the question is if it can be enabled in Xen (and if it actually could be beneficial because the commit messages seems to indicate that could be questionable).
>> >> If not, the check in arch/x86/kernel/apic/io_apic.c:setup_msi_irqs should fail
>> > Except that function in Xen is not run. that is b/c 
>> > x86_msi_ops.setup_msi_irqs end up pointing to xen_initdom_setup_irqs. 
>> > While if IOMMU is enabled it gets set to irq_remapping_setup_msi_irqs.
>> 
>> > So a fix like this:
>> > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> > index 56ab749..47f8cca 100644
>> > --- a/arch/x86/pci/xen.c
>> > +++ b/arch/x86/pci/xen.c
>> > @@ -263,6 +263,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev 
>> > *dev, int nvec, int type)
>> >          int ret = 0;
>> >          struct msi_desc *msidesc;
>> 
>> > +       if (type == PCI_CAP_ID_MSI && nvec > 1)
>> > +               return 1;
>> > +
>> >          list_for_each_entry(msidesc, &dev->msi_list, list) {
>> >                  struct physdev_map_pirq map_irq;
>> >                  domid_t domid;
>> 
>> 
>> > (sorry about the paste getting messed up here) - ought to do it? As for 
>> > example on one of my AMD machines there is no IOMMU, and this is where 
>> > AHCI does work under baremetal but not under Xen.
>> 
>> Yes it boots again :-)

> Great! Are you OK if I put 'Reported-and-Tested-by:" tag on the patch with your
> name for the above quick fix?

Sure !

> Thanks!
>> 
>> [   37.742109] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
>> [   37.773491] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
>> [   37.798862] ahci 0000:00:11.0: SE | ahci_init_one start
>> [   37.822040] ahci 0000:00:11.0: version 3.0
>> [   37.841606] xen: registering gsi 19 triggering 0 polarity 1
>> [   37.865577] xen: --> pirq=19 -> irq=19 (gsi=19)
>> [   37.913087] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
>> [   37.938519] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
>> [   37.974447] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 4 type:5
>> [   38.001806] ahci 0000:00:11.0: xen_initdom_setup_msi_irqs nvec: 1 type:5
>> [   38.029026] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:1
>> [   38.057960] ahci 0000:00:11.0: SE | n_msis: 1
>> [   38.078065] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
>> [   38.112045] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
>> [   38.139426] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
>> [   38.170664] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
>> [   38.201684] ahci 0000:00:11.0: SE | me here 1
>> [   38.221977] ahci 0000:00:11.0: SE | me here 2
>> [   38.244756] scsi0 : ahci
>> [   38.259700] scsi1 : ahci
>> [   38.274411] scsi2 : ahci
>> [   38.289278] scsi3 : ahci
>> [   38.303718] ata1: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff100 irq 121
>> [   38.332566] ata2: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff180 irq 121
>> [   38.361366] ata3: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff200 irq 121
>> [   38.390080] ata4: SATA max UDMA/133 abar m1024@0xf96ff000 port 0xf96ff280 irq 121
>> [   38.418787] really_probe: dev->bus->probe(0000:00:11.0) ret: 0
>> [   38.442420] really_probe: 0000:00:11.0 done ret: 1
>> 
>> 
>> > We can future wise implement a better version of this to deal with 
>> > multiple MSIs, but lets make sure to first get it booting.
>> >> --
>> >> Sander
>> >>
>> >>
>> >>
>> >>
>> >>>> --
>> >>>> Sander
>> >>>>
>> >>>>> 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
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:06:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:06: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 1UB47p-00056Q-Pf; Thu, 28 Feb 2013 14:06:21 +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 1UB47o-00056G-PX
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:06:21 +0000
Received: from [85.158.138.51:6532] by server-9.bemta-3.messagelabs.com id
	F8/22-32531-B546F215; Thu, 28 Feb 2013 14:06:19 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362060369!27925405!1
X-Originating-IP: [74.125.82.174]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17531 invoked from network); 28 Feb 2013 14:06:10 -0000
Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com)
	(74.125.82.174)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 14:06:10 -0000
Received: by mail-we0-f174.google.com with SMTP id r6so1530335wey.5
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 06:06:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TxAybs3fqj6WBZZRAuw1VSzzxd15VbeRO/u0kW6Jeaw=;
	b=QQBJMspGlji0WzMhk5D3wV2A6luj5BDuxDPd8paRmY42jrT9NgnYNP7vLjz6XNNvF8
	z52JI8WivCT5Eu80YTgyhpwnjFaEvWTGEH2OIwZjNwso+O7HHcb+x9pqOZ3hHjUjklZN
	dimcxf52FVBlBsY/S2mecmi3NmaMA92xuNVDL2GjC4LtDv1his1uN1NcVlK1m5qLwZq2
	34SaGECxKmpa/AFSy0SUsPlEssKebimEFF3bvmCNtqa6Q3RkcLQp1jFK2/sBlfkxVELx
	sRTGVnfeLdAsGwa83PlbOmBlvvgcyAqwAZBKKPAZQ2f+t24eHzhAE95vQpgdTnyxAdpq
	dd1Q==
MIME-Version: 1.0
X-Received: by 10.180.81.42 with SMTP id w10mr10849347wix.28.1362060341744;
	Thu, 28 Feb 2013 06:05:41 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Thu, 28 Feb 2013 06:05:41 -0800 (PST)
In-Reply-To: <4e5a5f4ba12771415995.1359716478@Solace>
References: <patchbomb.1359716470@Solace>
	<4e5a5f4ba12771415995.1359716478@Solace>
Date: Thu, 28 Feb 2013 14:05:41 +0000
X-Google-Sender-Auth: wFASRgL_YDOwnsBmW8PEeOrTCFQ
Message-ID: <CAFLBxZbwtwF-4WAGd_zRQL2TNEhx5rmsDmu28zb16p9_cLPnNA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 08 of 11 v3] libxl: optimize the calculation
 of how many VCPUs can run on a candidate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9005915303401478837=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9005915303401478837==
Content-Type: multipart/alternative; boundary=bcaec555503ed522b304d6c962dc

--bcaec555503ed522b304d6c962dc
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> For choosing the best NUMA placement candidate, we need to figure out
> how many VCPUs are runnable on each of them. That requires going through
> all the VCPUs of all the domains and check their affinities.
>
> With this change, instead of doing the above for each candidate, we
> do it once for all, populating an array while counting. This way, when
> we later are evaluating candidates, all we need is summing up the right
> elements of the array itself.
>
> This reduces the complexity of the overall algorithm, as it moves a
> potentially expensive operation (for_each_vcpu_of_each_domain {})
> outside from the core placement loop, so that it is performed only
> once instead of (potentially) tens or hundreds of times. More
> specifically, we go from a worst case computation time complaxity of:
>
>  O(2^n_nodes) * O(n_domains*n_domain_vcpus)
>
> To, with this change:
>
>  O(n_domains*n_domains_vcpus) + O(2^n_nodes) = O(2^n_nodes)
>
> (with n_nodes<=16, otherwise the algorithm suggests partitioning with
> cpupools and does not even start.)
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

--bcaec555503ed522b304d6c962dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank"=
>dario.faggioli@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">For choosing the best NUMA placement candida=
te, we need to figure out<br>
how many VCPUs are runnable on each of them. That requires going through<br=
>
all the VCPUs of all the domains and check their affinities.<br>
<br>
With this change, instead of doing the above for each candidate, we<br>
do it once for all, populating an array while counting. This way, when<br>
we later are evaluating candidates, all we need is summing up the right<br>
elements of the array itself.<br>
<br>
This reduces the complexity of the overall algorithm, as it moves a<br>
potentially expensive operation (for_each_vcpu_of_each_domain {})<br>
outside from the core placement loop, so that it is performed only<br>
once instead of (potentially) tens or hundreds of times. More<br>
specifically, we go from a worst case computation time complaxity of:<br>
<br>
=A0O(2^n_nodes) * O(n_domains*n_domain_vcpus)<br>
<br>
To, with this change:<br>
<br>
=A0O(n_domains*n_domains_vcpus) + O(2^n_nodes) =3D O(2^n_nodes)<br>
<br>
(with n_nodes&lt;=3D16, otherwise the algorithm suggests partitioning with<=
br>
cpupools and does not even start.)<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br></blockquote><div><br></div><div>A=
cked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt;<br>
</div><div>=A0<br></div></div><br></div></div>

--bcaec555503ed522b304d6c962dc--


--===============9005915303401478837==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9005915303401478837==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 14:06:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:06: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 1UB47p-00056Q-Pf; Thu, 28 Feb 2013 14:06:21 +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 1UB47o-00056G-PX
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:06:21 +0000
Received: from [85.158.138.51:6532] by server-9.bemta-3.messagelabs.com id
	F8/22-32531-B546F215; Thu, 28 Feb 2013 14:06:19 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1362060369!27925405!1
X-Originating-IP: [74.125.82.174]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17531 invoked from network); 28 Feb 2013 14:06:10 -0000
Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com)
	(74.125.82.174)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 14:06:10 -0000
Received: by mail-we0-f174.google.com with SMTP id r6so1530335wey.5
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 06:06:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TxAybs3fqj6WBZZRAuw1VSzzxd15VbeRO/u0kW6Jeaw=;
	b=QQBJMspGlji0WzMhk5D3wV2A6luj5BDuxDPd8paRmY42jrT9NgnYNP7vLjz6XNNvF8
	z52JI8WivCT5Eu80YTgyhpwnjFaEvWTGEH2OIwZjNwso+O7HHcb+x9pqOZ3hHjUjklZN
	dimcxf52FVBlBsY/S2mecmi3NmaMA92xuNVDL2GjC4LtDv1his1uN1NcVlK1m5qLwZq2
	34SaGECxKmpa/AFSy0SUsPlEssKebimEFF3bvmCNtqa6Q3RkcLQp1jFK2/sBlfkxVELx
	sRTGVnfeLdAsGwa83PlbOmBlvvgcyAqwAZBKKPAZQ2f+t24eHzhAE95vQpgdTnyxAdpq
	dd1Q==
MIME-Version: 1.0
X-Received: by 10.180.81.42 with SMTP id w10mr10849347wix.28.1362060341744;
	Thu, 28 Feb 2013 06:05:41 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Thu, 28 Feb 2013 06:05:41 -0800 (PST)
In-Reply-To: <4e5a5f4ba12771415995.1359716478@Solace>
References: <patchbomb.1359716470@Solace>
	<4e5a5f4ba12771415995.1359716478@Solace>
Date: Thu, 28 Feb 2013 14:05:41 +0000
X-Google-Sender-Auth: wFASRgL_YDOwnsBmW8PEeOrTCFQ
Message-ID: <CAFLBxZbwtwF-4WAGd_zRQL2TNEhx5rmsDmu28zb16p9_cLPnNA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 08 of 11 v3] libxl: optimize the calculation
 of how many VCPUs can run on a candidate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=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="===============9005915303401478837=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9005915303401478837==
Content-Type: multipart/alternative; boundary=bcaec555503ed522b304d6c962dc

--bcaec555503ed522b304d6c962dc
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> For choosing the best NUMA placement candidate, we need to figure out
> how many VCPUs are runnable on each of them. That requires going through
> all the VCPUs of all the domains and check their affinities.
>
> With this change, instead of doing the above for each candidate, we
> do it once for all, populating an array while counting. This way, when
> we later are evaluating candidates, all we need is summing up the right
> elements of the array itself.
>
> This reduces the complexity of the overall algorithm, as it moves a
> potentially expensive operation (for_each_vcpu_of_each_domain {})
> outside from the core placement loop, so that it is performed only
> once instead of (potentially) tens or hundreds of times. More
> specifically, we go from a worst case computation time complaxity of:
>
>  O(2^n_nodes) * O(n_domains*n_domain_vcpus)
>
> To, with this change:
>
>  O(n_domains*n_domains_vcpus) + O(2^n_nodes) = O(2^n_nodes)
>
> (with n_nodes<=16, otherwise the algorithm suggests partitioning with
> cpupools and does not even start.)
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

--bcaec555503ed522b304d6c962dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank"=
>dario.faggioli@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">For choosing the best NUMA placement candida=
te, we need to figure out<br>
how many VCPUs are runnable on each of them. That requires going through<br=
>
all the VCPUs of all the domains and check their affinities.<br>
<br>
With this change, instead of doing the above for each candidate, we<br>
do it once for all, populating an array while counting. This way, when<br>
we later are evaluating candidates, all we need is summing up the right<br>
elements of the array itself.<br>
<br>
This reduces the complexity of the overall algorithm, as it moves a<br>
potentially expensive operation (for_each_vcpu_of_each_domain {})<br>
outside from the core placement loop, so that it is performed only<br>
once instead of (potentially) tens or hundreds of times. More<br>
specifically, we go from a worst case computation time complaxity of:<br>
<br>
=A0O(2^n_nodes) * O(n_domains*n_domain_vcpus)<br>
<br>
To, with this change:<br>
<br>
=A0O(n_domains*n_domains_vcpus) + O(2^n_nodes) =3D O(2^n_nodes)<br>
<br>
(with n_nodes&lt;=3D16, otherwise the algorithm suggests partitioning with<=
br>
cpupools and does not even start.)<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br></blockquote><div><br></div><div>A=
cked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">g=
eorge.dunlap@eu.citrix.com</a>&gt;<br>
</div><div>=A0<br></div></div><br></div></div>

--bcaec555503ed522b304d6c962dc--


--===============9005915303401478837==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9005915303401478837==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 14:07:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:07: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 1UB48d-0005Ap-8k; Thu, 28 Feb 2013 14:07:11 +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 1UB48b-0005AY-Lo
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:07:09 +0000
Received: from [85.158.139.211:14276] by server-8.bemta-5.messagelabs.com id
	14/D4-05790-C846F215; Thu, 28 Feb 2013 14:07:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362060426!19569133!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10547 invoked from network); 28 Feb 2013 14:07:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:07:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 14:06:52 +0000
Message-Id: <512F728B02000078000C20B5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 14:06:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>,
	"Tim Deegan" <tim@xen.org>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
In-Reply-To: <20130228115606.GD27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 28.02.13 at 12:56, Tim Deegan <tim@xen.org> wrote:
> At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
>> There seems to be something else amiss though. Unless I am parsing
>> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
>> | PCD? Looks like a very unlikely combination
> 
> By my reading, 
> 
> taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
> caf = 0x0180000000000000 = refcount 0, PGC_state_free

Right.

> iow this is a free page but somehow has ended up with a typecount (which
> explains why the get_page() failed).  And presumably this is one of the
> various get_page[_and_type](page, dom_cow) calls in mem_sharing.c.
> 
> Since free_domheap_pages() has a BUG_ON(typecount != 0), it seems like
> something's gone badly off the rails here. 
> 
> One place I can see that tinkers with typecount without holding a
> ref is share_xen_page_with_guest(), which sets exactly this typecount,
> but then calls page_set_owner(page, d).
> 
> There's some hairy code in __gnttab_map_grant_ref() too, but I _think_
> it can't end up taking typecounts without refcounts.
> 
> __acquire_grant_for_copy() looks pretty hairy too, in particular this:
>         (void)page_get_owner_and_reference(*page);
>  but presumably the matching put_page() would have crashed if that was
> the problem.  Does anyone understand the grant code well enough to get
> into that?

Problem is that the domain reported in the message is DOM_COW
according to Olaf, yet he's not knowingly using page sharing. But
that fact pretty much excluded the grant table or any other of the
"usual" code paths for me (and I never looked at the sharing code,
so hoped one of you two would).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:07:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:07: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 1UB48d-0005Ap-8k; Thu, 28 Feb 2013 14:07:11 +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 1UB48b-0005AY-Lo
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:07:09 +0000
Received: from [85.158.139.211:14276] by server-8.bemta-5.messagelabs.com id
	14/D4-05790-C846F215; Thu, 28 Feb 2013 14:07:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362060426!19569133!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10547 invoked from network); 28 Feb 2013 14:07:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:07:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 14:06:52 +0000
Message-Id: <512F728B02000078000C20B5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 14:06:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>,
	"Tim Deegan" <tim@xen.org>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
In-Reply-To: <20130228115606.GD27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 28.02.13 at 12:56, Tim Deegan <tim@xen.org> wrote:
> At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
>> There seems to be something else amiss though. Unless I am parsing
>> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
>> | PCD? Looks like a very unlikely combination
> 
> By my reading, 
> 
> taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
> caf = 0x0180000000000000 = refcount 0, PGC_state_free

Right.

> iow this is a free page but somehow has ended up with a typecount (which
> explains why the get_page() failed).  And presumably this is one of the
> various get_page[_and_type](page, dom_cow) calls in mem_sharing.c.
> 
> Since free_domheap_pages() has a BUG_ON(typecount != 0), it seems like
> something's gone badly off the rails here. 
> 
> One place I can see that tinkers with typecount without holding a
> ref is share_xen_page_with_guest(), which sets exactly this typecount,
> but then calls page_set_owner(page, d).
> 
> There's some hairy code in __gnttab_map_grant_ref() too, but I _think_
> it can't end up taking typecounts without refcounts.
> 
> __acquire_grant_for_copy() looks pretty hairy too, in particular this:
>         (void)page_get_owner_and_reference(*page);
>  but presumably the matching put_page() would have crashed if that was
> the problem.  Does anyone understand the grant code well enough to get
> into that?

Problem is that the domain reported in the message is DOM_COW
according to Olaf, yet he's not knowingly using page sharing. But
that fact pretty much excluded the grant table or any other of the
"usual" code paths for me (and I never looked at the sharing code,
so hoped one of you two would).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:10:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:10: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 1UB4Bj-0005QQ-SZ; Thu, 28 Feb 2013 14:10:23 +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 1UB4Bi-0005QC-1F
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:10:22 +0000
Received: from [85.158.143.99:20780] by server-1.bemta-4.messagelabs.com id
	42/12-06203-D456F215; Thu, 28 Feb 2013 14:10:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1362060370!19885695!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22433 invoked from network); 28 Feb 2013 14:06:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:06:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB46K-0007ur-IL; Thu, 28 Feb 2013 14:04:48 +0000
Date: Thu, 28 Feb 2013 14:04:48 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228140448.GF27704@ocelot.phlegethon.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6CBD02000078000C2045@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F6CBD02000078000C2045@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 13:42 +0000 on 28 Feb (1362058925), Jan Beulich wrote:
> >>> On 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
> >     vmx: handle NMIs before re-enabling interrupts.
> >     
> >     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
> >     rather than raising a fake NMI and relying on the NMI processing to
> >     IRET, since that handling code is likely to change a fair amount in
> >     future.
> >     
> >     Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Sorry, my Acked-by just sent requires one change to be done first:
> 
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> >          vector = intr_info & INTR_INFO_VECTOR_MASK;
> >          if ( vector == TRAP_machine_check )
> >              do_machine_check(regs);
> > +        if ( vector == TRAP_machine_check
> 
> This almost certainly needs to be TRAP_nmi.

!

I was foolishly using the watchdog for testing, and of course losing
NMIs doesn't cause the watchdog to trigger. :|

Here's v2, with that fixed and updating the description:


commit 7dd3b06ff031c9a8c727df16c5def2afb382101c
Author: Tim Deegan <tim@xen.org>
Date:   Thu Feb 28 12:42:15 2013 +0000

    vmx: fix handling of NMI VMEXIT.
    
    Call do_nmi() directly and explicitly re-enable NMIs rather than
    raising an NMI through the APIC. Since NMIs are disabled after the
    VMEXIT, the raised NMI would be blocked until the next IRET
    instruction (i.e. the next real interrupt, or after scheduling a PV
    guest) and in the meantime the guest will spin taking NMI VMEXITS.
    
    Also, handle NMIs before re-enabling interrupts, since if we handle an
    interrupt (and therefore IRET) before calling do_nmi(), we may end up
    running the NMI handler with NMIs enabled.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5378928..04dbefb 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         vector = intr_info & INTR_INFO_VECTOR_MASK;
         if ( vector == TRAP_machine_check )
             do_machine_check(regs);
+        if ( vector == TRAP_nmi
+             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
+                 (X86_EVENTTYPE_NMI << 8)) )
+        {
+            do_nmi(regs);
+            enable_nmis();
+        }
         break;
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
@@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
                  (X86_EVENTTYPE_NMI << 8) )
                 goto exit_and_crash;
             HVMTRACE_0D(NMI);
-            self_nmi(); /* Real NMI, vector 2: normal processing. */
+            /* Already handled above. */
             break;
         case TRAP_machine_check:
             HVMTRACE_0D(MCE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:10:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:10: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 1UB4Bj-0005QQ-SZ; Thu, 28 Feb 2013 14:10:23 +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 1UB4Bi-0005QC-1F
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:10:22 +0000
Received: from [85.158.143.99:20780] by server-1.bemta-4.messagelabs.com id
	42/12-06203-D456F215; Thu, 28 Feb 2013 14:10:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1362060370!19885695!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22433 invoked from network); 28 Feb 2013 14:06:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:06:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB46K-0007ur-IL; Thu, 28 Feb 2013 14:04:48 +0000
Date: Thu, 28 Feb 2013 14:04:48 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228140448.GF27704@ocelot.phlegethon.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6CBD02000078000C2045@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F6CBD02000078000C2045@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 13:42 +0000 on 28 Feb (1362058925), Jan Beulich wrote:
> >>> On 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
> >     vmx: handle NMIs before re-enabling interrupts.
> >     
> >     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
> >     rather than raising a fake NMI and relying on the NMI processing to
> >     IRET, since that handling code is likely to change a fair amount in
> >     future.
> >     
> >     Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Sorry, my Acked-by just sent requires one change to be done first:
> 
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> >          vector = intr_info & INTR_INFO_VECTOR_MASK;
> >          if ( vector == TRAP_machine_check )
> >              do_machine_check(regs);
> > +        if ( vector == TRAP_machine_check
> 
> This almost certainly needs to be TRAP_nmi.

!

I was foolishly using the watchdog for testing, and of course losing
NMIs doesn't cause the watchdog to trigger. :|

Here's v2, with that fixed and updating the description:


commit 7dd3b06ff031c9a8c727df16c5def2afb382101c
Author: Tim Deegan <tim@xen.org>
Date:   Thu Feb 28 12:42:15 2013 +0000

    vmx: fix handling of NMI VMEXIT.
    
    Call do_nmi() directly and explicitly re-enable NMIs rather than
    raising an NMI through the APIC. Since NMIs are disabled after the
    VMEXIT, the raised NMI would be blocked until the next IRET
    instruction (i.e. the next real interrupt, or after scheduling a PV
    guest) and in the meantime the guest will spin taking NMI VMEXITS.
    
    Also, handle NMIs before re-enabling interrupts, since if we handle an
    interrupt (and therefore IRET) before calling do_nmi(), we may end up
    running the NMI handler with NMIs enabled.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5378928..04dbefb 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         vector = intr_info & INTR_INFO_VECTOR_MASK;
         if ( vector == TRAP_machine_check )
             do_machine_check(regs);
+        if ( vector == TRAP_nmi
+             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
+                 (X86_EVENTTYPE_NMI << 8)) )
+        {
+            do_nmi(regs);
+            enable_nmis();
+        }
         break;
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
@@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
                  (X86_EVENTTYPE_NMI << 8) )
                 goto exit_and_crash;
             HVMTRACE_0D(NMI);
-            self_nmi(); /* Real NMI, vector 2: normal processing. */
+            /* Already handled above. */
             break;
         case TRAP_machine_check:
             HVMTRACE_0D(MCE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:11:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:11: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 1UB4D0-0005f3-CT; Thu, 28 Feb 2013 14:11:42 +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 1UB4Cy-0005eo-3Z
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:11:40 +0000
Received: from [85.158.143.99:43728] by server-3.bemta-4.messagelabs.com id
	A1/5B-02186-B956F215; Thu, 28 Feb 2013 14:11:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1362060698!18199448!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15136 invoked from network); 28 Feb 2013 14:11:38 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 14:11:38 -0000
Received: by mail-wg0-f45.google.com with SMTP id dq12so1497708wgb.12
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 06:11:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=z9nhdltPWUl7GfgecJMk8Jcq61uMwl0qwJEIsotY6I4=;
	b=MQIt5tk5Y2xcnIZOytTq9//lUtVFMK1jIyLwCAttjMWOrI+mwsr3KrOvd/SxSgqiQI
	89+IrdRn9KFtjH74VPiWrtqQi1072quEJlr5PJynYEldZ/cEnG33831FfWR4uB8ofp3f
	ik8tdhH4ope26U2jp6iCr7vuxkanPmzmkJ0rs8hx54WfLNV47jc68fLmiMBCt2fo4dkv
	87TFfL3Cn9IxwZ4JKuFBD33GK/B1TvMpj2S2Qd1Q5/FX0uUfyIps0DvS6EdIUe2qus2a
	Lkakcr9R+9OKxKvNK9Z2ijZ0Gpww9eWAZvcFnNAIFI79zU9BaYiomcIX2z45sUG+7Diz
	Mb7A==
MIME-Version: 1.0
X-Received: by 10.180.105.67 with SMTP id gk3mr10766493wib.31.1362060698477;
	Thu, 28 Feb 2013 06:11:38 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Thu, 28 Feb 2013 06:11:38 -0800 (PST)
In-Reply-To: <f05ac3f656309bc71d43.1359716481@Solace>
References: <patchbomb.1359716470@Solace>
	<f05ac3f656309bc71d43.1359716481@Solace>
Date: Thu, 28 Feb 2013 14:11:38 +0000
X-Google-Sender-Auth: HV4OJZZOMj-758SqHox2Mvv3dHM
Message-ID: <CAFLBxZZGRD7G6fb_mVmNM-n6ebq8wVH81+wGKtoK0bBBimB9uA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 11 of 11 v3] docs: rearrange and update 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="===============4657150570619499239=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4657150570619499239==
Content-Type: multipart/alternative; boundary=f46d04426a22186c8604d6c9788e

--f46d04426a22186c8604d6c9788e
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> To include the new concept of NUMA aware scheduling and
> describe its impact.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

--f46d04426a22186c8604d6c9788e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank"=
>dario.faggioli@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">To include the new concept of NUMA aware sch=
eduling and<br>
describe its impact.<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br></blockquote><div><br></div></div>=
Acked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">=
george.dunlap@eu.citrix.com</a>&gt;<br>
</div></div>

--f46d04426a22186c8604d6c9788e--


--===============4657150570619499239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4657150570619499239==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 14:11:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:11: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 1UB4D0-0005f3-CT; Thu, 28 Feb 2013 14:11:42 +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 1UB4Cy-0005eo-3Z
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:11:40 +0000
Received: from [85.158.143.99:43728] by server-3.bemta-4.messagelabs.com id
	A1/5B-02186-B956F215; Thu, 28 Feb 2013 14:11:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1362060698!18199448!1
X-Originating-IP: [74.125.82.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15136 invoked from network); 28 Feb 2013 14:11:38 -0000
Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com)
	(74.125.82.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 14:11:38 -0000
Received: by mail-wg0-f45.google.com with SMTP id dq12so1497708wgb.12
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 06:11:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=z9nhdltPWUl7GfgecJMk8Jcq61uMwl0qwJEIsotY6I4=;
	b=MQIt5tk5Y2xcnIZOytTq9//lUtVFMK1jIyLwCAttjMWOrI+mwsr3KrOvd/SxSgqiQI
	89+IrdRn9KFtjH74VPiWrtqQi1072quEJlr5PJynYEldZ/cEnG33831FfWR4uB8ofp3f
	ik8tdhH4ope26U2jp6iCr7vuxkanPmzmkJ0rs8hx54WfLNV47jc68fLmiMBCt2fo4dkv
	87TFfL3Cn9IxwZ4JKuFBD33GK/B1TvMpj2S2Qd1Q5/FX0uUfyIps0DvS6EdIUe2qus2a
	Lkakcr9R+9OKxKvNK9Z2ijZ0Gpww9eWAZvcFnNAIFI79zU9BaYiomcIX2z45sUG+7Diz
	Mb7A==
MIME-Version: 1.0
X-Received: by 10.180.105.67 with SMTP id gk3mr10766493wib.31.1362060698477;
	Thu, 28 Feb 2013 06:11:38 -0800 (PST)
Received: by 10.194.20.163 with HTTP; Thu, 28 Feb 2013 06:11:38 -0800 (PST)
In-Reply-To: <f05ac3f656309bc71d43.1359716481@Solace>
References: <patchbomb.1359716470@Solace>
	<f05ac3f656309bc71d43.1359716481@Solace>
Date: Thu, 28 Feb 2013 14:11:38 +0000
X-Google-Sender-Auth: HV4OJZZOMj-758SqHox2Mvv3dHM
Message-ID: <CAFLBxZZGRD7G6fb_mVmNM-n6ebq8wVH81+wGKtoK0bBBimB9uA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>,
	Andrew Cooper <Andrew.Cooper3@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>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH 11 of 11 v3] docs: rearrange and update 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="===============4657150570619499239=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4657150570619499239==
Content-Type: multipart/alternative; boundary=f46d04426a22186c8604d6c9788e

--f46d04426a22186c8604d6c9788e
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> To include the new concept of NUMA aware scheduling and
> describe its impact.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

--f46d04426a22186c8604d6c9788e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Feb 1, 2013 at 11:01 AM, Dario Faggioli <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dario.faggioli@citrix.com" target=3D"_blank"=
>dario.faggioli@citrix.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">To include the new concept of NUMA aware sch=
eduling and<br>
describe its impact.<br>
<br>
Signed-off-by: Dario Faggioli &lt;<a href=3D"mailto:dario.faggioli@citrix.c=
om">dario.faggioli@citrix.com</a>&gt;<br></blockquote><div><br></div></div>=
Acked-by: George Dunlap &lt;<a href=3D"mailto:george.dunlap@eu.citrix.com">=
george.dunlap@eu.citrix.com</a>&gt;<br>
</div></div>

--f46d04426a22186c8604d6c9788e--


--===============4657150570619499239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4657150570619499239==--


From xen-devel-bounces@lists.xen.org Thu Feb 28 14:13:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB4ES-0005oB-29; Thu, 28 Feb 2013 14:13:12 +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 1UB4EQ-0005o3-SS
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:13:10 +0000
Received: from [85.158.138.51:28348] by server-8.bemta-3.messagelabs.com id
	C9/77-20604-1F56F215; Thu, 28 Feb 2013 14:13:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1362060784!21586444!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1140 invoked from network); 28 Feb 2013 14:13:04 -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; 28 Feb 2013 14:13:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB4EI-0007wm-Sy; Thu, 28 Feb 2013 14:13:02 +0000
Date: Thu, 28 Feb 2013 14:13:02 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228141302.GG27704@ocelot.phlegethon.org>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
	<512F728B02000078000C20B5@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F728B02000078000C20B5@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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

At 14:06 +0000 on 28 Feb (1362060411), Jan Beulich wrote:
> Problem is that the domain reported in the message is DOM_COW
> according to Olaf, yet he's not knowingly using page sharing.

Oh.  In that case, a backtrace (e.g. from WARN()) in the offending call
would be enlightening. 

> But that fact pretty much excluded the grant table or any other of the
> "usual" code paths for me (and I never looked at the sharing code, so
> hoped one of you two would).

I just looked thorough it for unguarded typecount modifications and
didn't find one.  But presumably something else is wrong if we're
trying to unshare a page with no sharing enabled.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:13:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB4ES-0005oB-29; Thu, 28 Feb 2013 14:13:12 +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 1UB4EQ-0005o3-SS
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:13:10 +0000
Received: from [85.158.138.51:28348] by server-8.bemta-3.messagelabs.com id
	C9/77-20604-1F56F215; Thu, 28 Feb 2013 14:13:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1362060784!21586444!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1140 invoked from network); 28 Feb 2013 14:13:04 -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; 28 Feb 2013 14:13:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB4EI-0007wm-Sy; Thu, 28 Feb 2013 14:13:02 +0000
Date: Thu, 28 Feb 2013 14:13:02 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228141302.GG27704@ocelot.phlegethon.org>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
	<512F728B02000078000C20B5@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F728B02000078000C20B5@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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

At 14:06 +0000 on 28 Feb (1362060411), Jan Beulich wrote:
> Problem is that the domain reported in the message is DOM_COW
> according to Olaf, yet he's not knowingly using page sharing.

Oh.  In that case, a backtrace (e.g. from WARN()) in the offending call
would be enlightening. 

> But that fact pretty much excluded the grant table or any other of the
> "usual" code paths for me (and I never looked at the sharing code, so
> hoped one of you two would).

I just looked thorough it for unguarded typecount modifications and
didn't find one.  But presumably something else is wrong if we're
trying to unshare a page with no sharing enabled.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:22:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB4NC-0006FD-71; Thu, 28 Feb 2013 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 <konrad.wilk@oracle.com>) id 1UB4NA-0006F8-FU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:22:12 +0000
Received: from [193.109.254.147:44564] by server-10.bemta-14.messagelabs.com
	id E6/9B-12679-3186F215; Thu, 28 Feb 2013 14:22:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1362061242!9234786!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3842 invoked from network); 28 Feb 2013 14:20:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 14:20:43 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SEKbDM023464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 14:20:38 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
	r1SEKblI021250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 14:20:37 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
	r1SEKaGN011849; Thu, 28 Feb 2013 08:20:36 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 06:20:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 469141C3935; Thu, 28 Feb 2013 09:20:35 -0500 (EST)
Date: Thu, 28 Feb 2013 09:20:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130228142035.GA31907@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<374661137.20130227205607@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <374661137.20130227205607@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Wed, Feb 27, 2013 at 08:56:07PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
> 
> > On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
> >> 
> >> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> >> 
> >> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
> >> > find the origin of this return value by instrumenting the involved
> >> > call tree.
> >> 
> >> Just wondering, is multiple msi's per device actually supported by xen ?
> 
> > That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> > use them and they work great with Xen.
> 
> > BTW, this is merge:
> > ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> > Merge: 266d7ad af8d102
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Tue Feb 19 19:07:27 2013 -0800
> 
> >     Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> >     
> >     Pull x86/apic changes from Ingo Molnar:
> >      "Main changes:
> >     
> >        - Multiple MSI support added to the APIC, PCI and AHCI code - acked
> >          by all relevant maintainers, by Alexander Gordeev.
> >     
> >          The advantage is that multiple AHCI ports can have multiple MSI
> >          irqs assigned, and can thus spread to multiple CPUs.
> >     
> >          [ Drivers can make use of this new facility via the
> >            pci_enable_msi_block_auto() method ]
> 
> 
> Ahh yes, i have added some debug info to ahci.c:
> 
>   [   36.778395] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
>   [   36.809777] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
>   [   36.835136] ahci 0000:00:11.0: SE | ahci_init_one start 
>   [   36.858284] ahci 0000:00:11.0: version 3.0
>   [   36.877840] xen: registering gsi 19 triggering 0 polarity 1
>   [   36.901791] xen: --> pirq=19 -> irq=19 (gsi=19)
>   (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
>  [   36.949293] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
>   [   36.974714] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
>   [   37.010706] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:4
>   [   37.039878] ahci 0000:00:11.0: SE | n_msis: 4
>   [   37.060115] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
>   [   37.094135] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
>   [   37.121658] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
>   [   37.153118] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
>   [   37.184265] ahci 0000:00:11.0: SE | me here 1 
>   [   37.204568] ahci 0000:00:11.0: SE | n_msis(4) host->n_ports(4) irq:121
>   [   37.231748] ahci 0000:00:11.0: SE | ata_host_start(host) rc:0
>   [   37.256222] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:0  rc:0
>   [   37.283023] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:1  rc:-22
>   [   37.310344] really_probe: dev->bus->probe(0000:00:11.0) ret: -22
>   [   37.335467] ahci: probe of 0000:00:11.0 failed with error -22
>   [   37.359552] really_probe: 0000:00:11.0 done ret: 0
> 
> So it bails out at the second devm_request_threaded_irq in:
> 
> int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis)
> {
>         int i, rc;
> 
>         dev_err(host->dev, "SE | n_msis(%d) host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
>         /* Sharing Last Message among several ports is not supported */
>         if (n_msis < host->n_ports){
>                 dev_err(host->dev, "SE | uhoh n_msis(%d) < host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
>                 return -EINVAL;
>         }
>         rc = ata_host_start(host);
>         dev_err(host->dev, "SE | ata_host_start(host) rc:%d\n",rc);
>         if (rc)
>                 return rc;
> 
>         for (i = 0; i < host->n_ports; i++) {
>                 rc = devm_request_threaded_irq(host->dev,
>                         irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
>                         dev_driver_string(host->dev), host->ports[i]);
>                 dev_err(host->dev, "SE | devm_request_threaded_irq i:%d  rc:%d\n",i,rc);
>                 if (rc)
>                         goto out_free_irqs;
>         }
> 
This is what I have for the patch, OK with me sending it tomorrow to Linus?

>From f4dce2c2114ef623dc6d931b5ea950a08e80057b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 28 Feb 2013 09:05:41 -0500
Subject: [PATCH] xen/pci: We don't do multiple MSI's.

There is no hypercall to setup multiple MSI per PCI device.
As such with these two new commits:
-  08261d87f7d1b6253ab3223756625a5c74532293
   PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto()
- 5ca72c4f7c412c2002363218901eba5516c476b1
   AHCI: Support multiple MSIs

we would call the PHYSDEVOP_map_pirq 'nvec' times with the same
contents of the PCI device. Sander discovered that we would get
the same PIRQ value 'nvec' times and return said values to the
caller. That of course meant that the device was configured only
with one MSI and AHCI would fail with:

ahci 0000:00:11.0: version 3.0
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
(XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
ahci: probe of 0000:00:11.0 failed with error -22

That is b/c in ahci_host_activate the second call to
devm_request_threaded_irq  would return -EINVAL as we passed in
(on the second run) an IRQ value that was never initialized.

Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/pci/xen.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 56ab749..94e7662 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -162,6 +162,9 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	struct msi_desc *msidesc;
 	int *v;
 
+	if (type == PCI_CAP_ID_MSI && nvec > 1)
+		return 1;
+
 	v = kzalloc(sizeof(int) * max(1, nvec), GFP_KERNEL);
 	if (!v)
 		return -ENOMEM;
@@ -220,6 +223,9 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	struct msi_desc *msidesc;
 	struct msi_msg msg;
 
+	if (type == PCI_CAP_ID_MSI && nvec > 1)
+		return 1;
+
 	list_for_each_entry(msidesc, &dev->msi_list, list) {
 		__read_msi_msg(msidesc, &msg);
 		pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
@@ -263,6 +269,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	int ret = 0;
 	struct msi_desc *msidesc;
 
+	if (type == PCI_CAP_ID_MSI && nvec > 1)
+		return 1;
+
 	list_for_each_entry(msidesc, &dev->msi_list, list) {
 		struct physdev_map_pirq map_irq;
 		domid_t domid;
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:22:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14: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 1UB4NC-0006FD-71; Thu, 28 Feb 2013 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 <konrad.wilk@oracle.com>) id 1UB4NA-0006F8-FU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:22:12 +0000
Received: from [193.109.254.147:44564] by server-10.bemta-14.messagelabs.com
	id E6/9B-12679-3186F215; Thu, 28 Feb 2013 14:22:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1362061242!9234786!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3842 invoked from network); 28 Feb 2013 14:20:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 14:20:43 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SEKbDM023464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 14:20:38 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
	r1SEKblI021250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 14:20:37 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
	r1SEKaGN011849; Thu, 28 Feb 2013 08:20:36 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 06:20:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 469141C3935; Thu, 28 Feb 2013 09:20:35 -0500 (EST)
Date: Thu, 28 Feb 2013 09:20:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20130228142035.GA31907@phenom.dumpdata.com>
References: <312569942.20130225231830@eikelenboom.it>
	<512C836102000078000C0FD7@nat28.tlf.novell.com>
	<38125304.20130227115733@eikelenboom.it>
	<512DF6C702000078000C1708@nat28.tlf.novell.com>
	<1769529756.20130227124648@eikelenboom.it>
	<512E101802000078000C17FE@nat28.tlf.novell.com>
	<1336583579.20130227185059@eikelenboom.it>
	<20130227192810.GA30169@phenom.dumpdata.com>
	<374661137.20130227205607@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <374661137.20130227205607@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] linux-3.9-rc0 regression from 3.8 SATA controller
 not detected 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 Wed, Feb 27, 2013 at 08:56:07PM +0100, Sander Eikelenboom wrote:
> 
> Wednesday, February 27, 2013, 8:28:10 PM, you wrote:
> 
> > On Wed, Feb 27, 2013 at 06:50:59PM +0100, Sander Eikelenboom wrote:
> >> 
> >> Wednesday, February 27, 2013, 1:54:31 PM, you wrote:
> >> 
> >> >>>> On 27.02.13 at 12:46, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >> >>   [   89.338827] ahci: probe of 0000:00:11.0 failed with error -22
> >> 
> >> > Which is -EINVAL. With nothing else printed, I'm afraid you need to
> >> > find the origin of this return value by instrumenting the involved
> >> > call tree.
> >> 
> >> Just wondering, is multiple msi's per device actually supported by xen ?
> 
> > That is very good question. I know we support MSI-X b/c 1GB or 10GB NICs
> > use them and they work great with Xen.
> 
> > BTW, this is merge:
> > ommit 5800700f66678ea5c85e7d62b138416070bf7f60
> > Merge: 266d7ad af8d102
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Tue Feb 19 19:07:27 2013 -0800
> 
> >     Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> >     
> >     Pull x86/apic changes from Ingo Molnar:
> >      "Main changes:
> >     
> >        - Multiple MSI support added to the APIC, PCI and AHCI code - acked
> >          by all relevant maintainers, by Alexander Gordeev.
> >     
> >          The advantage is that multiple AHCI ports can have multiple MSI
> >          irqs assigned, and can thus spread to multiple CPUs.
> >     
> >          [ Drivers can make use of this new facility via the
> >            pci_enable_msi_block_auto() method ]
> 
> 
> Ahh yes, i have added some debug info to ahci.c:
> 
>   [   36.778395] SE | bus: 'pci': really_probe: probing driver ahci with device 0000:00:11.0
>   [   36.809777] really_probe: pinctrl_bind_pins(0000:00:11.0) ret: 0
>   [   36.835136] ahci 0000:00:11.0: SE | ahci_init_one start 
>   [   36.858284] ahci 0000:00:11.0: version 3.0
>   [   36.877840] xen: registering gsi 19 triggering 0 polarity 1
>   [   36.901791] xen: --> pirq=19 -> irq=19 (gsi=19)
>   (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
>  [   36.949293] ahci 0000:00:11.0: SE | pcim_enable_device(pdev) rc:0
>   [   36.974714] ahci 0000:00:11.0: SE pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME)  rc:0
>   [   37.010706] ahci 0000:00:11.0: SE pci_enable_msi_block_auto(pdev, &maxvec) rc:4
>   [   37.039878] ahci 0000:00:11.0: SE | n_msis: 4
>   [   37.060115] ahci 0000:00:11.0: SE | ahci_configure_dma_masks(pdev, hpriv->cap & HOST_CAP_64)  rc:0
>   [   37.094135] ahci 0000:00:11.0: SE | ahci_pci_reset_controller(host)  rc:0
>   [   37.121658] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
>   [   37.153118] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
>   [   37.184265] ahci 0000:00:11.0: SE | me here 1 
>   [   37.204568] ahci 0000:00:11.0: SE | n_msis(4) host->n_ports(4) irq:121
>   [   37.231748] ahci 0000:00:11.0: SE | ata_host_start(host) rc:0
>   [   37.256222] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:0  rc:0
>   [   37.283023] ahci 0000:00:11.0: SE | devm_request_threaded_irq i:1  rc:-22
>   [   37.310344] really_probe: dev->bus->probe(0000:00:11.0) ret: -22
>   [   37.335467] ahci: probe of 0000:00:11.0 failed with error -22
>   [   37.359552] really_probe: 0000:00:11.0 done ret: 0
> 
> So it bails out at the second devm_request_threaded_irq in:
> 
> int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis)
> {
>         int i, rc;
> 
>         dev_err(host->dev, "SE | n_msis(%d) host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
>         /* Sharing Last Message among several ports is not supported */
>         if (n_msis < host->n_ports){
>                 dev_err(host->dev, "SE | uhoh n_msis(%d) < host->n_ports(%d) irq:%d\n",n_msis , host->n_ports,irq);
>                 return -EINVAL;
>         }
>         rc = ata_host_start(host);
>         dev_err(host->dev, "SE | ata_host_start(host) rc:%d\n",rc);
>         if (rc)
>                 return rc;
> 
>         for (i = 0; i < host->n_ports; i++) {
>                 rc = devm_request_threaded_irq(host->dev,
>                         irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
>                         dev_driver_string(host->dev), host->ports[i]);
>                 dev_err(host->dev, "SE | devm_request_threaded_irq i:%d  rc:%d\n",i,rc);
>                 if (rc)
>                         goto out_free_irqs;
>         }
> 
This is what I have for the patch, OK with me sending it tomorrow to Linus?

>From f4dce2c2114ef623dc6d931b5ea950a08e80057b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 28 Feb 2013 09:05:41 -0500
Subject: [PATCH] xen/pci: We don't do multiple MSI's.

There is no hypercall to setup multiple MSI per PCI device.
As such with these two new commits:
-  08261d87f7d1b6253ab3223756625a5c74532293
   PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto()
- 5ca72c4f7c412c2002363218901eba5516c476b1
   AHCI: Support multiple MSIs

we would call the PHYSDEVOP_map_pirq 'nvec' times with the same
contents of the PCI device. Sander discovered that we would get
the same PIRQ value 'nvec' times and return said values to the
caller. That of course meant that the device was configured only
with one MSI and AHCI would fail with:

ahci 0000:00:11.0: version 3.0
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
(XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
ahci: probe of 0000:00:11.0 failed with error -22

That is b/c in ahci_host_activate the second call to
devm_request_threaded_irq  would return -EINVAL as we passed in
(on the second run) an IRQ value that was never initialized.

Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/pci/xen.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 56ab749..94e7662 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -162,6 +162,9 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	struct msi_desc *msidesc;
 	int *v;
 
+	if (type == PCI_CAP_ID_MSI && nvec > 1)
+		return 1;
+
 	v = kzalloc(sizeof(int) * max(1, nvec), GFP_KERNEL);
 	if (!v)
 		return -ENOMEM;
@@ -220,6 +223,9 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	struct msi_desc *msidesc;
 	struct msi_msg msg;
 
+	if (type == PCI_CAP_ID_MSI && nvec > 1)
+		return 1;
+
 	list_for_each_entry(msidesc, &dev->msi_list, list) {
 		__read_msi_msg(msidesc, &msg);
 		pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
@@ -263,6 +269,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	int ret = 0;
 	struct msi_desc *msidesc;
 
+	if (type == PCI_CAP_ID_MSI && nvec > 1)
+		return 1;
+
 	list_for_each_entry(msidesc, &dev->msi_list, list) {
 		struct physdev_map_pirq map_irq;
 		domid_t domid;
-- 
1.8.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:25:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:25: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 1UB4Q5-0006Ll-Qi; Thu, 28 Feb 2013 14:25:13 +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 1UB4Q4-0006Lf-Ei
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:25:12 +0000
Received: from [85.158.143.99:58952] by server-3.bemta-4.messagelabs.com id
	FA/0C-02186-7C86F215; Thu, 28 Feb 2013 14:25:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1362061509!22053054!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3504 invoked from network); 28 Feb 2013 14:25:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:25:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB4Pw-0007yd-1P; Thu, 28 Feb 2013 14:25:04 +0000
Date: Thu, 28 Feb 2013 14:25:03 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228142503.GH27704@ocelot.phlegethon.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F6C2502000078000C2042@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 13:39 +0000 on 28 Feb (1362058773), Jan Beulich wrote:
> >>> On 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
> > commit d278beed1df2d226911dce92295411018c9bba2f
> > Author: Tim Deegan <tim@xen.org>
> > Date:   Thu Feb 28 12:42:15 2013 +0000
> > 
> >     vmx: handle NMIs before re-enabling interrupts.
> >     
> >     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
> >     rather than raising a fake NMI and relying on the NMI processing to
> >     IRET, since that handling code is likely to change a fair amount in
> >     future.
> 
> Isn't that a gross understatement, considering that you or Malcolm
> had found that the use of self_nmi() here was actively broken?
> 
> >     Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> (realizing that dealing with the PV side of the issue will be left to
> me in the end)

For PV, would you be happy with something like this, or do you want to
avoid the extra IRET in cases where we would be returning with IRET
anyway?

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 04dbefb..598a5b5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2316,10 +2316,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         if ( vector == TRAP_nmi
              && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
                  (X86_EVENTTYPE_NMI << 8)) )
-        {
             do_nmi(regs);
-            enable_nmis();
-        }
         break;
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d36eddd..2a66080 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3211,7 +3211,7 @@ void do_nmi(struct cpu_user_regs *regs)
     ++nmi_count(cpu);
 
     if ( nmi_callback(regs, cpu) )
-        return;
+        goto out;
 
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
@@ -3227,6 +3227,9 @@ void do_nmi(struct cpu_user_regs *regs)
         if ( !(reason & 0xc0) && !nmi_watchdog )
             unknown_nmi_error(regs, reason);
     }
+
+out:
+    enable_nmis();
 }
 
 void set_nmi_callback(nmi_callback_t callback)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:25:26 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:25: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 1UB4Q5-0006Ll-Qi; Thu, 28 Feb 2013 14:25:13 +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 1UB4Q4-0006Lf-Ei
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:25:12 +0000
Received: from [85.158.143.99:58952] by server-3.bemta-4.messagelabs.com id
	FA/0C-02186-7C86F215; Thu, 28 Feb 2013 14:25:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1362061509!22053054!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3504 invoked from network); 28 Feb 2013 14:25:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:25:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB4Pw-0007yd-1P; Thu, 28 Feb 2013 14:25:04 +0000
Date: Thu, 28 Feb 2013 14:25:03 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228142503.GH27704@ocelot.phlegethon.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F6C2502000078000C2042@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 13:39 +0000 on 28 Feb (1362058773), Jan Beulich wrote:
> >>> On 28.02.13 at 14:00, Tim Deegan <tim@xen.org> wrote:
> > commit d278beed1df2d226911dce92295411018c9bba2f
> > Author: Tim Deegan <tim@xen.org>
> > Date:   Thu Feb 28 12:42:15 2013 +0000
> > 
> >     vmx: handle NMIs before re-enabling interrupts.
> >     
> >     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
> >     rather than raising a fake NMI and relying on the NMI processing to
> >     IRET, since that handling code is likely to change a fair amount in
> >     future.
> 
> Isn't that a gross understatement, considering that you or Malcolm
> had found that the use of self_nmi() here was actively broken?
> 
> >     Signed-off-by: Tim Deegan <tim@xen.org>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> (realizing that dealing with the PV side of the issue will be left to
> me in the end)

For PV, would you be happy with something like this, or do you want to
avoid the extra IRET in cases where we would be returning with IRET
anyway?

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 04dbefb..598a5b5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2316,10 +2316,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
         if ( vector == TRAP_nmi
              && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
                  (X86_EVENTTYPE_NMI << 8)) )
-        {
             do_nmi(regs);
-            enable_nmis();
-        }
         break;
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d36eddd..2a66080 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3211,7 +3211,7 @@ void do_nmi(struct cpu_user_regs *regs)
     ++nmi_count(cpu);
 
     if ( nmi_callback(regs, cpu) )
-        return;
+        goto out;
 
     if ( nmi_watchdog )
         nmi_watchdog_tick(regs);
@@ -3227,6 +3227,9 @@ void do_nmi(struct cpu_user_regs *regs)
         if ( !(reason & 0xc0) && !nmi_watchdog )
             unknown_nmi_error(regs, reason);
     }
+
+out:
+    enable_nmis();
 }
 
 void set_nmi_callback(nmi_callback_t callback)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:29:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:29: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 1UB4UE-0006WG-H1; Thu, 28 Feb 2013 14:29: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 1UB4UD-0006WB-N1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:29:29 +0000
Received: from [85.158.137.99:55114] by server-16.bemta-3.messagelabs.com id
	FE/81-20692-8C96F215; Thu, 28 Feb 2013 14:29:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1362061766!13460405!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1995 invoked from network); 28 Feb 2013 14:29:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 14:29:27 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SETD3S002285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 14:29:14 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
	r1SETCI1019917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 14:29:13 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
	r1SETBeK018554; Thu, 28 Feb 2013 08:29:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 06:29:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1EA9F1C3935; Thu, 28 Feb 2013 09:29:10 -0500 (EST)
Date: Thu, 28 Feb 2013 09:29:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130228142910.GA32354@phenom.dumpdata.com>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E91B7.6060102@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: jwboyer@redhat.com, Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	samu.kallio@aberdeencloud.com, kraman@redhat.com, tglx@linutronix.de
Subject: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 03:07:35PM -0800, H. Peter Anvin wrote:
> On 02/27/2013 03:00 PM, Greg KH wrote:
> > 
> > "Stable" kernels are used all over the place, like in distros, which
> > might enable this.
> > 
> > I have no objection to taking this patch in a stable release, as it does
> > fix a real problem.
> > 
> 
> OK.  I will queue it up in the next fixes (tip:x86/urgent) batch to Linus.

Thank you.

Could you also consider this one (I CC-ed Ingo on it but never got any
response):


>From a6ed4a88eff4f6329bb4acae3372cccc8a8367d5 Mon Sep 17 00:00:00 2001
From: Samu Kallio <samu.kallio@aberdeencloud.com>
Date: Sun, 17 Feb 2013 02:35:52 +0000
Subject: [PATCH] x86: mm: Fix vmalloc_fault oops during lazy MMU updates.

In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.

One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:

- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
  which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
  PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries

The OOPs usually looks as so:

------------[ cut here ]------------
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: 0000 [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[<ffffffff816271bf>]  [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
 [<ffffffff81627759>] do_page_fault+0x399/0x4b0
 [<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110
 [<ffffffff81624065>] page_fault+0x25/0x30
 [<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
 [<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350
 [<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60
 [<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150
 [<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80
 [<ffffffff81153e61>] unmap_single_vma+0x531/0x870
 [<ffffffff81154962>] unmap_vmas+0x52/0xa0
 [<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100
 [<ffffffff8115c8f8>] exit_mmap+0x98/0x170
 [<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [<ffffffff81059ce3>] mmput+0x83/0xf0
 [<ffffffff810624c4>] exit_mm+0x104/0x130
 [<ffffffff8106264a>] do_exit+0x15a/0x8c0
 [<ffffffff810630ff>] do_group_exit+0x3f/0xa0
 [<ffffffff81063177>] sys_exit_group+0x17/0x20
 [<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b

Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.

RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Reported-and-Tested-by: Krishna Raman <kraman@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Samu Kallio <samu.kallio@aberdeencloud.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/mm/fault.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fb674fd..4f7d793 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
 	if (pgd_none(*pgd_ref))
 		return -1;
 
-	if (pgd_none(*pgd))
+	if (pgd_none(*pgd)) {
 		set_pgd(pgd, *pgd_ref);
-	else
+		arch_flush_lazy_mmu_mode();
+	} else {
 		BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+	}
 
 	/*
 	 * Below here mismatches are bugs because these lower tables
-- 
1.8.0.2

> 
> 	-hpa
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:29:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:29: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 1UB4UE-0006WG-H1; Thu, 28 Feb 2013 14:29: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 1UB4UD-0006WB-N1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:29:29 +0000
Received: from [85.158.137.99:55114] by server-16.bemta-3.messagelabs.com id
	FE/81-20692-8C96F215; Thu, 28 Feb 2013 14:29:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1362061766!13460405!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1995 invoked from network); 28 Feb 2013 14:29:27 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 14:29:27 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SETD3S002285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 14:29:14 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
	r1SETCI1019917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 14:29:13 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
	r1SETBeK018554; Thu, 28 Feb 2013 08:29:11 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 06:29:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1EA9F1C3935; Thu, 28 Feb 2013 09:29:10 -0500 (EST)
Date: Thu, 28 Feb 2013 09:29:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130228142910.GA32354@phenom.dumpdata.com>
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512E91B7.6060102@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: jwboyer@redhat.com, Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	samu.kallio@aberdeencloud.com, kraman@redhat.com, tglx@linutronix.de
Subject: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 27, 2013 at 03:07:35PM -0800, H. Peter Anvin wrote:
> On 02/27/2013 03:00 PM, Greg KH wrote:
> > 
> > "Stable" kernels are used all over the place, like in distros, which
> > might enable this.
> > 
> > I have no objection to taking this patch in a stable release, as it does
> > fix a real problem.
> > 
> 
> OK.  I will queue it up in the next fixes (tip:x86/urgent) batch to Linus.

Thank you.

Could you also consider this one (I CC-ed Ingo on it but never got any
response):


>From a6ed4a88eff4f6329bb4acae3372cccc8a8367d5 Mon Sep 17 00:00:00 2001
From: Samu Kallio <samu.kallio@aberdeencloud.com>
Date: Sun, 17 Feb 2013 02:35:52 +0000
Subject: [PATCH] x86: mm: Fix vmalloc_fault oops during lazy MMU updates.

In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.

One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:

- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
  which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
  PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries

The OOPs usually looks as so:

------------[ cut here ]------------
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: 0000 [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[<ffffffff816271bf>]  [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
 [<ffffffff81627759>] do_page_fault+0x399/0x4b0
 [<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110
 [<ffffffff81624065>] page_fault+0x25/0x30
 [<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
 [<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350
 [<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60
 [<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150
 [<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80
 [<ffffffff81153e61>] unmap_single_vma+0x531/0x870
 [<ffffffff81154962>] unmap_vmas+0x52/0xa0
 [<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100
 [<ffffffff8115c8f8>] exit_mmap+0x98/0x170
 [<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [<ffffffff81059ce3>] mmput+0x83/0xf0
 [<ffffffff810624c4>] exit_mm+0x104/0x130
 [<ffffffff8106264a>] do_exit+0x15a/0x8c0
 [<ffffffff810630ff>] do_group_exit+0x3f/0xa0
 [<ffffffff81063177>] sys_exit_group+0x17/0x20
 [<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b

Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.

RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Reported-and-Tested-by: Krishna Raman <kraman@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Samu Kallio <samu.kallio@aberdeencloud.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/mm/fault.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fb674fd..4f7d793 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
 	if (pgd_none(*pgd_ref))
 		return -1;
 
-	if (pgd_none(*pgd))
+	if (pgd_none(*pgd)) {
 		set_pgd(pgd, *pgd_ref);
-	else
+		arch_flush_lazy_mmu_mode();
+	} else {
 		BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+	}
 
 	/*
 	 * Below here mismatches are bugs because these lower tables
-- 
1.8.0.2

> 
> 	-hpa
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:42:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:42: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 1UB4gl-00070x-TS; Thu, 28 Feb 2013 14:42:27 +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 1UB4gk-00070s-6K
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:42:26 +0000
Received: from [85.158.138.51:14721] by server-15.bemta-3.messagelabs.com id
	4B/00-23142-1DC6F215; Thu, 28 Feb 2013 14:42:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362062543!11012688!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1216 invoked from network); 28 Feb 2013 14:42:24 -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; 28 Feb 2013 14:42:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 14:42:23 +0000
Message-Id: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 14:42:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
In-Reply-To: <20130228142503.GH27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 15:25, Tim Deegan <tim@xen.org> wrote:
> At 13:39 +0000 on 28 Feb (1362058773), Jan Beulich wrote:
>> (realizing that dealing with the PV side of the issue will be left to
>> me in the end)
> 
> For PV, would you be happy with something like this, or do you want to
> avoid the extra IRET in cases where we would be returning with IRET
> anyway?

No, and not so much because of the redundant IRET, but
because ...

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3211,7 +3211,7 @@ void do_nmi(struct cpu_user_regs *regs)
>      ++nmi_count(cpu);
>  
>      if ( nmi_callback(regs, cpu) )
> -        return;
> +        goto out;
>  
>      if ( nmi_watchdog )
>          nmi_watchdog_tick(regs);
> @@ -3227,6 +3227,9 @@ void do_nmi(struct cpu_user_regs *regs)
>          if ( !(reason & 0xc0) && !nmi_watchdog )
>              unknown_nmi_error(regs, reason);
>      }
> +
> +out:
> +    enable_nmis();

... this must not be done when on the NMI stack (i.e. when the
NMI was raised while in hypervisor context). Checking for this
here would be strait forward, but I was really considering to do
all of this in the assembly exit path, and I was still undecided
whether we shouldn't follow Linux in skipping softirq processing
(and hence scheduling) on the way out from an NMI (I don't
think we'd need to do the same for MCE).

Jan

>  }
>  
>  void set_nmi_callback(nmi_callback_t callback)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:42:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:42: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 1UB4gl-00070x-TS; Thu, 28 Feb 2013 14:42:27 +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 1UB4gk-00070s-6K
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:42:26 +0000
Received: from [85.158.138.51:14721] by server-15.bemta-3.messagelabs.com id
	4B/00-23142-1DC6F215; Thu, 28 Feb 2013 14:42:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362062543!11012688!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1216 invoked from network); 28 Feb 2013 14:42:24 -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; 28 Feb 2013 14:42:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 14:42:23 +0000
Message-Id: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 14:42:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
In-Reply-To: <20130228142503.GH27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 15:25, Tim Deegan <tim@xen.org> wrote:
> At 13:39 +0000 on 28 Feb (1362058773), Jan Beulich wrote:
>> (realizing that dealing with the PV side of the issue will be left to
>> me in the end)
> 
> For PV, would you be happy with something like this, or do you want to
> avoid the extra IRET in cases where we would be returning with IRET
> anyway?

No, and not so much because of the redundant IRET, but
because ...

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3211,7 +3211,7 @@ void do_nmi(struct cpu_user_regs *regs)
>      ++nmi_count(cpu);
>  
>      if ( nmi_callback(regs, cpu) )
> -        return;
> +        goto out;
>  
>      if ( nmi_watchdog )
>          nmi_watchdog_tick(regs);
> @@ -3227,6 +3227,9 @@ void do_nmi(struct cpu_user_regs *regs)
>          if ( !(reason & 0xc0) && !nmi_watchdog )
>              unknown_nmi_error(regs, reason);
>      }
> +
> +out:
> +    enable_nmis();

... this must not be done when on the NMI stack (i.e. when the
NMI was raised while in hypervisor context). Checking for this
here would be strait forward, but I was really considering to do
all of this in the assembly exit path, and I was still undecided
whether we shouldn't follow Linux in skipping softirq processing
(and hence scheduling) on the way out from an NMI (I don't
think we'd need to do the same for MCE).

Jan

>  }
>  
>  void set_nmi_callback(nmi_callback_t callback)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:46:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:46: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 1UB4kA-000785-Jj; Thu, 28 Feb 2013 14:45:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB4k8-00077y-RM
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:45:57 +0000
Received: from [85.158.139.83:14640] by server-16.bemta-5.messagelabs.com id
	15/47-02543-3AD6F215; Thu, 28 Feb 2013 14:45:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1362062738!29461124!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16263 invoked from network); 28 Feb 2013 14:45:44 -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;
	28 Feb 2013 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10280053"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 14:45:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 09:45:37 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB4jp-0002LV-JA;
	Thu, 28 Feb 2013 14:45:37 +0000
Message-ID: <512F6D91.2070309@citrix.com>
Date: Thu, 28 Feb 2013 14:45:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
In-Reply-To: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/13 14:42, Jan Beulich wrote:
>>>> On 28.02.13 at 15:25, Tim Deegan <tim@xen.org> wrote:
>> At 13:39 +0000 on 28 Feb (1362058773), Jan Beulich wrote:
>>> (realizing that dealing with the PV side of the issue will be left to
>>> me in the end)
>> For PV, would you be happy with something like this, or do you want to
>> avoid the extra IRET in cases where we would be returning with IRET
>> anyway?
> No, and not so much because of the redundant IRET, but
> because ...
>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -3211,7 +3211,7 @@ void do_nmi(struct cpu_user_regs *regs)
>>      ++nmi_count(cpu);
>>  
>>      if ( nmi_callback(regs, cpu) )
>> -        return;
>> +        goto out;
>>  
>>      if ( nmi_watchdog )
>>          nmi_watchdog_tick(regs);
>> @@ -3227,6 +3227,9 @@ void do_nmi(struct cpu_user_regs *regs)
>>          if ( !(reason & 0xc0) && !nmi_watchdog )
>>              unknown_nmi_error(regs, reason);
>>      }
>> +
>> +out:
>> +    enable_nmis();
> ... this must not be done when on the NMI stack (i.e. when the
> NMI was raised while in hypervisor context). Checking for this
> here would be strait forward, but I was really considering to do
> all of this in the assembly exit path, and I was still undecided
> whether we shouldn't follow Linux in skipping softirq processing
> (and hence scheduling) on the way out from an NMI (I don't
> think we'd need to do the same for MCE).
>
> Jan

It is furthermore pointless.  If we interrupted a guest with the NMI, we
would have moved onto the main stack.  We would only be on the NMI stack
at this point if we interrupted Xen with the NMI, at which point we will
be iret'ing back anyway.

~Andrew

>
>>  }
>>  
>>  void set_nmi_callback(nmi_callback_t callback)
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:46:12 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:46: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 1UB4kA-000785-Jj; Thu, 28 Feb 2013 14:45:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB4k8-00077y-RM
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:45:57 +0000
Received: from [85.158.139.83:14640] by server-16.bemta-5.messagelabs.com id
	15/47-02543-3AD6F215; Thu, 28 Feb 2013 14:45:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1362062738!29461124!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16263 invoked from network); 28 Feb 2013 14:45:44 -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;
	28 Feb 2013 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10280053"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 14:45:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 09:45:37 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB4jp-0002LV-JA;
	Thu, 28 Feb 2013 14:45:37 +0000
Message-ID: <512F6D91.2070309@citrix.com>
Date: Thu, 28 Feb 2013 14:45:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
In-Reply-To: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/13 14:42, Jan Beulich wrote:
>>>> On 28.02.13 at 15:25, Tim Deegan <tim@xen.org> wrote:
>> At 13:39 +0000 on 28 Feb (1362058773), Jan Beulich wrote:
>>> (realizing that dealing with the PV side of the issue will be left to
>>> me in the end)
>> For PV, would you be happy with something like this, or do you want to
>> avoid the extra IRET in cases where we would be returning with IRET
>> anyway?
> No, and not so much because of the redundant IRET, but
> because ...
>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -3211,7 +3211,7 @@ void do_nmi(struct cpu_user_regs *regs)
>>      ++nmi_count(cpu);
>>  
>>      if ( nmi_callback(regs, cpu) )
>> -        return;
>> +        goto out;
>>  
>>      if ( nmi_watchdog )
>>          nmi_watchdog_tick(regs);
>> @@ -3227,6 +3227,9 @@ void do_nmi(struct cpu_user_regs *regs)
>>          if ( !(reason & 0xc0) && !nmi_watchdog )
>>              unknown_nmi_error(regs, reason);
>>      }
>> +
>> +out:
>> +    enable_nmis();
> ... this must not be done when on the NMI stack (i.e. when the
> NMI was raised while in hypervisor context). Checking for this
> here would be strait forward, but I was really considering to do
> all of this in the assembly exit path, and I was still undecided
> whether we shouldn't follow Linux in skipping softirq processing
> (and hence scheduling) on the way out from an NMI (I don't
> think we'd need to do the same for MCE).
>
> Jan

It is furthermore pointless.  If we interrupted a guest with the NMI, we
would have moved onto the main stack.  We would only be on the NMI stack
at this point if we interrupted Xen with the NMI, at which point we will
be iret'ing back anyway.

~Andrew

>
>>  }
>>  
>>  void set_nmi_callback(nmi_callback_t callback)
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 14:49:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB4nd-0007Il-DO; Thu, 28 Feb 2013 14:49:33 +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 1UB4nc-0007If-GI
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:49:32 +0000
Received: from [85.158.139.211:22860] by server-16.bemta-5.messagelabs.com id
	CB/B1-02543-B7E6F215; Thu, 28 Feb 2013 14:49:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362062958!19578624!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1975 invoked from network); 28 Feb 2013 14:49:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:49:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB4nJ-00082A-4N; Thu, 28 Feb 2013 14:49:13 +0000
Date: Thu, 28 Feb 2013 14:49:13 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228144913.GI27704@ocelot.phlegethon.org>
References: <50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 14:42 +0000 on 28 Feb (1362062542), Jan Beulich wrote:
> > +out:
> > +    enable_nmis();
> 
> ... this must not be done when on the NMI stack (i.e. when the
> NMI was raised while in hypervisor context).

Right; I had forgotten that we didn't switch stacks in that case. 

> Checking for this
> here would be strait forward, but I was really considering to do
> all of this in the assembly exit path, and I was still undecided
> whether we shouldn't follow Linux in skipping softirq processing
> (and hence scheduling) on the way out from an NMI (I don't
> think we'd need to do the same for MCE).

That sounds sensible, if it simplifies the logic (i.e. if it avoids
needing an extra IRET just to re-enable NMIs when we might as well IRET
to the guest).  Or is there any other reason to avoid 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 Feb 28 14:49:47 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB4nd-0007Il-DO; Thu, 28 Feb 2013 14:49:33 +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 1UB4nc-0007If-GI
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:49:32 +0000
Received: from [85.158.139.211:22860] by server-16.bemta-5.messagelabs.com id
	CB/B1-02543-B7E6F215; Thu, 28 Feb 2013 14:49:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1362062958!19578624!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1975 invoked from network); 28 Feb 2013 14:49:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:49:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB4nJ-00082A-4N; Thu, 28 Feb 2013 14:49:13 +0000
Date: Thu, 28 Feb 2013 14:49:13 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228144913.GI27704@ocelot.phlegethon.org>
References: <50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 14:42 +0000 on 28 Feb (1362062542), Jan Beulich wrote:
> > +out:
> > +    enable_nmis();
> 
> ... this must not be done when on the NMI stack (i.e. when the
> NMI was raised while in hypervisor context).

Right; I had forgotten that we didn't switch stacks in that case. 

> Checking for this
> here would be strait forward, but I was really considering to do
> all of this in the assembly exit path, and I was still undecided
> whether we shouldn't follow Linux in skipping softirq processing
> (and hence scheduling) on the way out from an NMI (I don't
> think we'd need to do the same for MCE).

That sounds sensible, if it simplifies the logic (i.e. if it avoids
needing an extra IRET just to re-enable NMIs when we might as well IRET
to the guest).  Or is there any other reason to avoid 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 Feb 28 14:51:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:51: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 1UB4pY-0007Wl-UD; Thu, 28 Feb 2013 14:51:32 +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 1UB4pX-0007W1-IU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:51:31 +0000
Received: from [85.158.139.83:40261] by server-15.bemta-5.messagelabs.com id
	FC/29-22815-2FE6F215; Thu, 28 Feb 2013 14:51:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362063086!22270951!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjYzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7564 invoked from network); 28 Feb 2013 14:51:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:51:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SEpNui018793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 14:51:24 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
	r1SEpMwu013292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 14:51:23 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
	r1SEpMRq001715; Thu, 28 Feb 2013 08:51:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 06:51:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D18AA1C3935; Thu, 28 Feb 2013 09:51:20 -0500 (EST)
Date: Thu, 28 Feb 2013 09:51:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130228145120.GD580@phenom.dumpdata.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
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>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	boris.ostrovsky@oracle.com, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 Thu, Feb 28, 2013 at 01:00:08PM +0000, Tim Deegan wrote:
> At 09:58 +0000 on 28 Feb (1362045494), Jan Beulich wrote:
> > >>> On 22.11.12 at 17:12, Jan Beulich wrote:
> > >>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > > On 22/11/12 15:55, Jan Beulich wrote:
> > > >>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > >>> A quick solution would be to execute a noop function with
> > > >>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
> > > >>> so which does an inline iret to itself.  Which of these would you prefer?
> > > >> I would actually consider avoiding to run softirqs altogether in that
> > > >> case, just like native Linux doesn't do any event or scheduler
> > > >> processing in that case.
> > > > 
> > > > That would probably be the easiest solution.
> > > > 
> > > > I was already going to do the same for the rentrant NMI and MCE handling
> > > > case (and also the process pending upcalls checking), due to the
> > > > complexities of fixing the race condition at the end of the handler.
> > > > 
> > > > Unfortunately, I don't think I have time to look at this issue
> > > > immediately, but if it is ok to wait till the beginning of next week, I
> > > 
> > > That's fine of course.
> > 
> > So that was 3 months ago, and we're likely going to need to do
> > further unfixed releases if this won't move forward. Can you
> > estimate whether you'll be able to get back to this?
> 
> Let's make a step in the right direction before 4.3, at least:

FYI, this also fixes oprofile being able to collect HVM guest
data.

> 
> commit d278beed1df2d226911dce92295411018c9bba2f
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 28 12:42:15 2013 +0000
> 
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 5378928..462bb0f 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          vector = intr_info & INTR_INFO_VECTOR_MASK;
>          if ( vector == TRAP_machine_check )
>              do_machine_check(regs);
> +        if ( vector == TRAP_machine_check
> +             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> +                 (X86_EVENTTYPE_NMI << 8)) )
> +        {
> +            do_nmi(regs);
> +            enable_nmis();
> +        }
>          break;
>      case EXIT_REASON_MCE_DURING_VMENTRY:
>          do_machine_check(regs);
> @@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>                   (X86_EVENTTYPE_NMI << 8) )
>                  goto exit_and_crash;
>              HVMTRACE_0D(NMI);
> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
> +            /* Already handled above. */
>              break;
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 28 14:51:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 14:51: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 1UB4pY-0007Wl-UD; Thu, 28 Feb 2013 14:51:32 +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 1UB4pX-0007W1-IU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 14:51:31 +0000
Received: from [85.158.139.83:40261] by server-15.bemta-5.messagelabs.com id
	FC/29-22815-2FE6F215; Thu, 28 Feb 2013 14:51:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362063086!22270951!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNjYzODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7564 invoked from network); 28 Feb 2013 14:51:28 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 14:51:28 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SEpNui018793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 14:51:24 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
	r1SEpMwu013292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 14:51:23 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
	r1SEpMRq001715; Thu, 28 Feb 2013 08:51:22 -0600
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 06:51:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D18AA1C3935; Thu, 28 Feb 2013 09:51:20 -0500 (EST)
Date: Thu, 28 Feb 2013 09:51:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <20130228145120.GD580@phenom.dumpdata.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130228130008.GE27704@ocelot.phlegethon.org>
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>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	boris.ostrovsky@oracle.com, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 Thu, Feb 28, 2013 at 01:00:08PM +0000, Tim Deegan wrote:
> At 09:58 +0000 on 28 Feb (1362045494), Jan Beulich wrote:
> > >>> On 22.11.12 at 17:12, Jan Beulich wrote:
> > >>>> On 22.11.12 at 17:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > > On 22/11/12 15:55, Jan Beulich wrote:
> > > >>>>> On 22.11.12 at 16:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > >>> A quick solution would be to execute a noop function with
> > > >>> run_in_exception_handler().  Alternatively, I can code enable_nmi() or
> > > >>> so which does an inline iret to itself.  Which of these would you prefer?
> > > >> I would actually consider avoiding to run softirqs altogether in that
> > > >> case, just like native Linux doesn't do any event or scheduler
> > > >> processing in that case.
> > > > 
> > > > That would probably be the easiest solution.
> > > > 
> > > > I was already going to do the same for the rentrant NMI and MCE handling
> > > > case (and also the process pending upcalls checking), due to the
> > > > complexities of fixing the race condition at the end of the handler.
> > > > 
> > > > Unfortunately, I don't think I have time to look at this issue
> > > > immediately, but if it is ok to wait till the beginning of next week, I
> > > 
> > > That's fine of course.
> > 
> > So that was 3 months ago, and we're likely going to need to do
> > further unfixed releases if this won't move forward. Can you
> > estimate whether you'll be able to get back to this?
> 
> Let's make a step in the right direction before 4.3, at least:

FYI, this also fixes oprofile being able to collect HVM guest
data.

> 
> commit d278beed1df2d226911dce92295411018c9bba2f
> Author: Tim Deegan <tim@xen.org>
> Date:   Thu Feb 28 12:42:15 2013 +0000
> 
>     vmx: handle NMIs before re-enabling interrupts.
>     
>     Also, switch to calling do_nmi() and explicitly re-enabling NMIs
>     rather than raising a fake NMI and relying on the NMI processing to
>     IRET, since that handling code is likely to change a fair amount in
>     future.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 5378928..462bb0f 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2313,6 +2313,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          vector = intr_info & INTR_INFO_VECTOR_MASK;
>          if ( vector == TRAP_machine_check )
>              do_machine_check(regs);
> +        if ( vector == TRAP_machine_check
> +             && ((intr_info & INTR_INFO_INTR_TYPE_MASK) ==
> +                 (X86_EVENTTYPE_NMI << 8)) )
> +        {
> +            do_nmi(regs);
> +            enable_nmis();
> +        }
>          break;
>      case EXIT_REASON_MCE_DURING_VMENTRY:
>          do_machine_check(regs);
> @@ -2486,7 +2493,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>                   (X86_EVENTTYPE_NMI << 8) )
>                  goto exit_and_crash;
>              HVMTRACE_0D(NMI);
> -            self_nmi(); /* Real NMI, vector 2: normal processing. */
> +            /* Already handled above. */
>              break;
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Feb 28 15:00:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB4xn-0007xH-JL; Thu, 28 Feb 2013 15:00:03 +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 1UB4xl-0007vH-Lb
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:00:01 +0000
Received: from [85.158.138.51:62495] by server-9.bemta-3.messagelabs.com id
	C7/9A-32531-0F07F215; Thu, 28 Feb 2013 15:00:00 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362063582!28608216!1
X-Originating-IP: [209.85.223.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10362 invoked from network); 28 Feb 2013 14:59:44 -0000
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com)
	(209.85.223.170)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 14:59:44 -0000
Received: by mail-ie0-f170.google.com with SMTP id c11so2212684ieb.29
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 06:59:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=1pMMrb8fOPGG3C/yBe2biHsWRYPzXKaaaMiiUj4VJtA=;
	b=pA48cLQav9K5U/jdNiIJaYb0V2lBh0TMgoUo9asWKU2Aps5S2gu15+4zY5T5SZI9DQ
	aF9gaMJjaaG7vnsl53ucDv3WzH9X53racou5G31BOdtFdWK6a9gUGKrDCoUytiX4f7Tt
	8z202qlvZuLaYKxE/idS/+vNw1EA1BNmOflWV7ur3DTxHMZdlIXLIIesfFFls/qAl2hq
	rxo5UbJ2DHVjGZw/FcRq3lrKazH1Nzh1GGFoGFUi3kKYxITR9KS7Y3zclXbWI7xqzq8U
	v+4dLouOa8QN4mRZRkgzdBy/0Rj0fbrSu3wE6Lou/eep3sr7cQg6M7Gq1rB4tlrbfVCa
	v1ZA==
X-Received: by 10.50.153.198 with SMTP id vi6mr10290046igb.112.1362063582426; 
	Thu, 28 Feb 2013 06:59:42 -0800 (PST)
Received: from [192.168.15.1] ([206.223.182.18])
	by mx.google.com with ESMTPS id ip8sm9790180igc.4.2013.02.28.06.59.39
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 28 Feb 2013 06:59:41 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <512F728B02000078000C20B5@nat28.tlf.novell.com>
Date: Thu, 28 Feb 2013 09:59:40 -0500
Message-Id: <AE87D7B7-2D99-4EB8-BD32-A5AEB1EE781B@gridcentric.ca>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
	<512F728B02000078000C20B5@nat28.tlf.novell.com>
To: "Jan Beulich" <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkDTiL2Xi/l2ONRIBLUeVQpxf3gHDqZ+WXSbp+9a0X6+yf7VBwg36D2yJAQurEX8S7/E578
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 Feb 28, 2013, at 9:06 AM, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.02.13 at 12:56, Tim Deegan <tim@xen.org> wrote:
>> At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
>>> There seems to be something else amiss though. Unless I am parsing
>>> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
>>> | PCD? Looks like a very unlikely combination
>> 
>> By my reading, 
>> 
>> taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
>> caf = 0x0180000000000000 = refcount 0, PGC_state_free
> 
> Right.
D'oh :)

Sharing code never sets PGT_writable, only sets/clears PGT_shared. I tend to think the dom_cow rd belies a different problem. To use dom_cow, the domain has to have an explicit domctl that enables memory sharing.

Andres
> 
>> iow this is a free page but somehow has ended up with a typecount (which
>> explains why the get_page() failed).  And presumably this is one of the
>> various get_page[_and_type](page, dom_cow) calls in mem_sharing.c.
>> 
>> Since free_domheap_pages() has a BUG_ON(typecount != 0), it seems like
>> something's gone badly off the rails here. 
>> 
>> One place I can see that tinkers with typecount without holding a
>> ref is share_xen_page_with_guest(), which sets exactly this typecount,
>> but then calls page_set_owner(page, d).
>> 
>> There's some hairy code in __gnttab_map_grant_ref() too, but I _think_
>> it can't end up taking typecounts without refcounts.
>> 
>> __acquire_grant_for_copy() looks pretty hairy too, in particular this:
>>        (void)page_get_owner_and_reference(*page);
>> but presumably the matching put_page() would have crashed if that was
>> the problem.  Does anyone understand the grant code well enough to get
>> into that?
> 
> Problem is that the domain reported in the message is DOM_COW
> according to Olaf, yet he's not knowingly using page sharing. But
> that fact pretty much excluded the grant table or any other of the
> "usual" code paths for me (and I never looked at the sharing code,
> so hoped one of you two would).
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:00:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB4xn-0007xH-JL; Thu, 28 Feb 2013 15:00:03 +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 1UB4xl-0007vH-Lb
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:00:01 +0000
Received: from [85.158.138.51:62495] by server-9.bemta-3.messagelabs.com id
	C7/9A-32531-0F07F215; Thu, 28 Feb 2013 15:00:00 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362063582!28608216!1
X-Originating-IP: [209.85.223.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10362 invoked from network); 28 Feb 2013 14:59:44 -0000
Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com)
	(209.85.223.170)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 14:59:44 -0000
Received: by mail-ie0-f170.google.com with SMTP id c11so2212684ieb.29
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 06:59:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:content-type:mime-version:subject:from:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=1pMMrb8fOPGG3C/yBe2biHsWRYPzXKaaaMiiUj4VJtA=;
	b=pA48cLQav9K5U/jdNiIJaYb0V2lBh0TMgoUo9asWKU2Aps5S2gu15+4zY5T5SZI9DQ
	aF9gaMJjaaG7vnsl53ucDv3WzH9X53racou5G31BOdtFdWK6a9gUGKrDCoUytiX4f7Tt
	8z202qlvZuLaYKxE/idS/+vNw1EA1BNmOflWV7ur3DTxHMZdlIXLIIesfFFls/qAl2hq
	rxo5UbJ2DHVjGZw/FcRq3lrKazH1Nzh1GGFoGFUi3kKYxITR9KS7Y3zclXbWI7xqzq8U
	v+4dLouOa8QN4mRZRkgzdBy/0Rj0fbrSu3wE6Lou/eep3sr7cQg6M7Gq1rB4tlrbfVCa
	v1ZA==
X-Received: by 10.50.153.198 with SMTP id vi6mr10290046igb.112.1362063582426; 
	Thu, 28 Feb 2013 06:59:42 -0800 (PST)
Received: from [192.168.15.1] ([206.223.182.18])
	by mx.google.com with ESMTPS id ip8sm9790180igc.4.2013.02.28.06.59.39
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 28 Feb 2013 06:59:41 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <512F728B02000078000C20B5@nat28.tlf.novell.com>
Date: Thu, 28 Feb 2013 09:59:40 -0500
Message-Id: <AE87D7B7-2D99-4EB8-BD32-A5AEB1EE781B@gridcentric.ca>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
	<512F728B02000078000C20B5@nat28.tlf.novell.com>
To: "Jan Beulich" <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkDTiL2Xi/l2ONRIBLUeVQpxf3gHDqZ+WXSbp+9a0X6+yf7VBwg36D2yJAQurEX8S7/E578
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 Feb 28, 2013, at 9:06 AM, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.02.13 at 12:56, Tim Deegan <tim@xen.org> wrote:
>> At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
>>> There seems to be something else amiss though. Unless I am parsing
>>> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
>>> | PCD? Looks like a very unlikely combination
>> 
>> By my reading, 
>> 
>> taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
>> caf = 0x0180000000000000 = refcount 0, PGC_state_free
> 
> Right.
D'oh :)

Sharing code never sets PGT_writable, only sets/clears PGT_shared. I tend to think the dom_cow rd belies a different problem. To use dom_cow, the domain has to have an explicit domctl that enables memory sharing.

Andres
> 
>> iow this is a free page but somehow has ended up with a typecount (which
>> explains why the get_page() failed).  And presumably this is one of the
>> various get_page[_and_type](page, dom_cow) calls in mem_sharing.c.
>> 
>> Since free_domheap_pages() has a BUG_ON(typecount != 0), it seems like
>> something's gone badly off the rails here. 
>> 
>> One place I can see that tinkers with typecount without holding a
>> ref is share_xen_page_with_guest(), which sets exactly this typecount,
>> but then calls page_set_owner(page, d).
>> 
>> There's some hairy code in __gnttab_map_grant_ref() too, but I _think_
>> it can't end up taking typecounts without refcounts.
>> 
>> __acquire_grant_for_copy() looks pretty hairy too, in particular this:
>>        (void)page_get_owner_and_reference(*page);
>> but presumably the matching put_page() would have crashed if that was
>> the problem.  Does anyone understand the grant code well enough to get
>> into that?
> 
> Problem is that the domain reported in the message is DOM_COW
> according to Olaf, yet he's not knowingly using page sharing. But
> that fact pretty much excluded the grant table or any other of the
> "usual" code paths for me (and I never looked at the sharing code,
> so hoped one of you two would).
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:01:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB4zF-000848-3T; Thu, 28 Feb 2013 15:01: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 1UB4zD-00083m-Be
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:01:31 +0000
Received: from [85.158.143.99:30890] by server-2.bemta-4.messagelabs.com id
	3D/22-12656-A417F215; Thu, 28 Feb 2013 15:01:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1362063689!26350827!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29138 invoked from network); 28 Feb 2013 15:01:29 -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; 28 Feb 2013 15:01:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:01:29 +0000
Message-Id: <512F7F5702000078000C214D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:01:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<20130228144913.GI27704@ocelot.phlegethon.org>
In-Reply-To: <20130228144913.GI27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 15:49, Tim Deegan <tim@xen.org> wrote:
> At 14:42 +0000 on 28 Feb (1362062542), Jan Beulich wrote:
>> Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> 
> That sounds sensible, if it simplifies the logic (i.e. if it avoids
> needing an extra IRET just to re-enable NMIs when we might as well IRET
> to the guest).  Or is there any other reason to avoid it?

No, I don't think so. We only need to make sure we don't execute
one as long as we're on the NMI stack.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:01:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB4zF-000848-3T; Thu, 28 Feb 2013 15:01: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 1UB4zD-00083m-Be
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:01:31 +0000
Received: from [85.158.143.99:30890] by server-2.bemta-4.messagelabs.com id
	3D/22-12656-A417F215; Thu, 28 Feb 2013 15:01:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1362063689!26350827!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29138 invoked from network); 28 Feb 2013 15:01:29 -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; 28 Feb 2013 15:01:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:01:29 +0000
Message-Id: <512F7F5702000078000C214D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:01:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<20130228144913.GI27704@ocelot.phlegethon.org>
In-Reply-To: <20130228144913.GI27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 15:49, Tim Deegan <tim@xen.org> wrote:
> At 14:42 +0000 on 28 Feb (1362062542), Jan Beulich wrote:
>> Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> 
> That sounds sensible, if it simplifies the logic (i.e. if it avoids
> needing an extra IRET just to re-enable NMIs when we might as well IRET
> to the guest).  Or is there any other reason to avoid it?

No, I don't think so. We only need to make sure we don't execute
one as long as we're on the NMI stack.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:04:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB52K-0008NR-NR; Thu, 28 Feb 2013 15:04:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB52J-0008NL-9R
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:04:43 +0000
Received: from [85.158.138.51:25444] by server-8.bemta-3.messagelabs.com id
	F7/4D-20604-A027F215; Thu, 28 Feb 2013 15:04:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362063880!11017821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13958 invoked from network); 28 Feb 2013 15:04:41 -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;
	28 Feb 2013 15:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10289738"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 15:04:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 10:04:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB52F-0002co-7V;
	Thu, 28 Feb 2013 15:04:39 +0000
Message-ID: <1362063879.2109.120.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 28 Feb 2013 15:04:39 +0000
In-Reply-To: <512F4E68.2000707@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512F4E68.2000707@citrix.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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, 2013-02-28 at 12:32 +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > This interface allows user to query supported event channel types. If we need
> > to disable a specific ABI in the future, we just need to remove the dead code
> > and clear corresponding feature bit.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/include/public/event_channel.h |   44 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
> > index 07ff321..dff3364 100644
> > --- a/xen/include/public/event_channel.h
> > +++ b/xen/include/public/event_channel.h
> > @@ -71,6 +71,7 @@
> >  #define EVTCHNOP_bind_vcpu        8
> >  #define EVTCHNOP_unmask           9
> >  #define EVTCHNOP_reset           10
> > +#define EVTCHNOP_register_extended 11
> >  /* ` } */
> >  
> >  typedef uint32_t evtchn_port_t;
> > @@ -258,6 +259,49 @@ struct evtchn_reset {
> >  typedef struct evtchn_reset evtchn_reset_t;
> >  
> >  /*
> > + * EVTCHNOP_register_extended: Register extended event channel
> > + * NOTES:
> > + *  1. Currently only 3-level is supported.
> > + *  2. Should fall back to 2-level if this call fails.
> > + */
> > +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> > + * 256k event channels while 32 bit ones only need 1 page for 32k
> > + * event channels. */
> > +#define EVTCHN_MAX_L3_PAGES 8
> > +struct evtchn_register_3level {
> > +    /* IN parameters. */
> > +    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
> > +    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
> > +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
> > +};
> 
> Registering per-VCPU resources at start-of-day doesn't seem like the
> right thing to do here.  Why waste resources for VCPUs that are never
> going to be used?  And I don't think we want to constraint how VCPU
> hotplug works by requiring resource for all possible VCPUs to be
> allocated up-front.
> 

My first thought was that it is important for Dom0 or driver domains to
get what they want otherwise the whole system suffers from performance
degradation.

I'm considering per-cpu registration call now, for the reason of saving
resources.

> 
> > + */
> > +#define EVTCHN_EXTENDED_QUERY 0
> > +/* supported extended event channel */
> > +#define EVTCHN_EXTENDED_NONE  0
> > +#define _EVTCHN_EXTENDED_L3   0
> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> > +struct evtchn_register_extended {
> > +    /* IN parameters. */
> > +    uint32_t cmd;
> > +    union {
> > +        evtchn_register_3level_t l3;
> > +    } u;
> > +};
> 
> Adding new members to this union as new event channels ABI are
> implemented are going to change its size and potentially the alignment
> of the union member.  This seems a potential for future ABI
> compatibility problems.  See also by comment to patch 18.
> 

One way to solve this is to have that union contain pointers to specific
structures, but as you suggested, just add sub-op for each new ABI is
Ok.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:04:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB52K-0008NR-NR; Thu, 28 Feb 2013 15:04:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1UB52J-0008NL-9R
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:04:43 +0000
Received: from [85.158.138.51:25444] by server-8.bemta-3.messagelabs.com id
	F7/4D-20604-A027F215; Thu, 28 Feb 2013 15:04:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1362063880!11017821!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13958 invoked from network); 28 Feb 2013 15:04:41 -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;
	28 Feb 2013 15:04:41 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10289738"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 15:04:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 10:04:39 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB52F-0002co-7V;
	Thu, 28 Feb 2013 15:04:39 +0000
Message-ID: <1362063879.2109.120.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 28 Feb 2013 15:04:39 +0000
In-Reply-To: <512F4E68.2000707@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-7-git-send-email-wei.liu2@citrix.com>
	<512F4E68.2000707@citrix.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 06/22] Define extended event channel
 registration 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, 2013-02-28 at 12:32 +0000, David Vrabel wrote:
> On 27/02/13 14:33, Wei Liu wrote:
> > This interface allows user to query supported event channel types. If we need
> > to disable a specific ABI in the future, we just need to remove the dead code
> > and clear corresponding feature bit.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/include/public/event_channel.h |   44 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/xen/include/public/event_channel.h b/xen/include/public/event_channel.h
> > index 07ff321..dff3364 100644
> > --- a/xen/include/public/event_channel.h
> > +++ b/xen/include/public/event_channel.h
> > @@ -71,6 +71,7 @@
> >  #define EVTCHNOP_bind_vcpu        8
> >  #define EVTCHNOP_unmask           9
> >  #define EVTCHNOP_reset           10
> > +#define EVTCHNOP_register_extended 11
> >  /* ` } */
> >  
> >  typedef uint32_t evtchn_port_t;
> > @@ -258,6 +259,49 @@ struct evtchn_reset {
> >  typedef struct evtchn_reset evtchn_reset_t;
> >  
> >  /*
> > + * EVTCHNOP_register_extended: Register extended event channel
> > + * NOTES:
> > + *  1. Currently only 3-level is supported.
> > + *  2. Should fall back to 2-level if this call fails.
> > + */
> > +/* 64 bit guests need 8 pages for evtchn_pending and evtchn_mask for
> > + * 256k event channels while 32 bit ones only need 1 page for 32k
> > + * event channels. */
> > +#define EVTCHN_MAX_L3_PAGES 8
> > +struct evtchn_register_3level {
> > +    /* IN parameters. */
> > +    uint32_t nr_pages;          /* for evtchn_{pending,mask} */
> > +    uint32_t nr_vcpus;          /* for l2sel_{mfns,offsets} */
> > +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_pending;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) evtchn_mask;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_mfns;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) l2sel_offsets;
> > +};
> 
> Registering per-VCPU resources at start-of-day doesn't seem like the
> right thing to do here.  Why waste resources for VCPUs that are never
> going to be used?  And I don't think we want to constraint how VCPU
> hotplug works by requiring resource for all possible VCPUs to be
> allocated up-front.
> 

My first thought was that it is important for Dom0 or driver domains to
get what they want otherwise the whole system suffers from performance
degradation.

I'm considering per-cpu registration call now, for the reason of saving
resources.

> 
> > + */
> > +#define EVTCHN_EXTENDED_QUERY 0
> > +/* supported extended event channel */
> > +#define EVTCHN_EXTENDED_NONE  0
> > +#define _EVTCHN_EXTENDED_L3   0
> > +#define EVTCHN_EXTENDED_L3    (1U << _EVTCHN_EXTENDED_L3)
> > +struct evtchn_register_extended {
> > +    /* IN parameters. */
> > +    uint32_t cmd;
> > +    union {
> > +        evtchn_register_3level_t l3;
> > +    } u;
> > +};
> 
> Adding new members to this union as new event channels ABI are
> implemented are going to change its size and potentially the alignment
> of the union member.  This seems a potential for future ABI
> compatibility problems.  See also by comment to patch 18.
> 

One way to solve this is to have that union contain pointers to specific
structures, but as you suggested, just add sub-op for each new ABI is
Ok.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:12:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB598-0000Kz-Lg; Thu, 28 Feb 2013 15:11: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 1UB597-0000Kt-FL
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 15:11:45 +0000
Received: from [85.158.143.99:50311] by server-2.bemta-4.messagelabs.com id
	58/1F-12656-0B37F215; Thu, 28 Feb 2013 15:11:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1362064304!19259935!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7278 invoked from network); 28 Feb 2013 15:11:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:11:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2036233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 15:11: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.297.1; Thu, 28 Feb 2013 15:11:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB595-0006Mt-MI; Thu, 28 Feb 2013 15:11:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB595-0004rh-EY;
	Thu, 28 Feb 2013 15:11:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.29615.238852.82943@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 15:11:43 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <512F4798.6040305@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com> <512F36BA.4070101@eu.citrix.com>
	<20783.17738.662582.446216@mariner.uk.xensource.com>
	<512F4798.6040305@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>, Alex Bligh <alex@alex.org.uk>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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 v2] tools: Improve make deb"):
> On 28/02/13 11:53, Ian Jackson wrote:
> > I think this is a good idea and should perhaps even be done nightly.
> 
> You're suggesting integrating it into the automated build system, I presume?

That would be best.  You'd end up with packages for master but not
staging.  And you'd end up with ones for the stable branches too.

What's needed is an automated production recipe which I don't think we
have.  It would probably also need a push gate for the Debian
packaging from Debian, to stop our tests being gummed up if the Debian
packaging changes incompatibly, and a commitment to maintain whatever
local changes we have that make it all work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:12:01 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB598-0000Kz-Lg; Thu, 28 Feb 2013 15:11: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 1UB597-0000Kt-FL
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 15:11:45 +0000
Received: from [85.158.143.99:50311] by server-2.bemta-4.messagelabs.com id
	58/1F-12656-0B37F215; Thu, 28 Feb 2013 15:11:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1362064304!19259935!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7278 invoked from network); 28 Feb 2013 15:11:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:11:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2036233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 15:11: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.297.1; Thu, 28 Feb 2013 15:11:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB595-0006Mt-MI; Thu, 28 Feb 2013 15:11:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB595-0004rh-EY;
	Thu, 28 Feb 2013 15:11:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.29615.238852.82943@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 15:11:43 +0000
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <512F4798.6040305@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<1361900393.26546.319.camel@zakaz.uk.xensource.com>
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com>
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com>
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com> <512F36BA.4070101@eu.citrix.com>
	<20783.17738.662582.446216@mariner.uk.xensource.com>
	<512F4798.6040305@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>, Alex Bligh <alex@alex.org.uk>,
	Fabio Fantoni <fabio.fantoni@heliman.it>
Subject: Re: [Xen-devel] [PATCH v2] 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 v2] tools: Improve make deb"):
> On 28/02/13 11:53, Ian Jackson wrote:
> > I think this is a good idea and should perhaps even be done nightly.
> 
> You're suggesting integrating it into the automated build system, I presume?

That would be best.  You'd end up with packages for master but not
staging.  And you'd end up with ones for the stable branches too.

What's needed is an automated production recipe which I don't think we
have.  It would probably also need a push gate for the Debian
packaging from Debian, to stop our tests being gummed up if the Debian
packaging changes incompatibly, and a commitment to maintain whatever
local changes we have that make it all work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:13:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:13: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 1UB5AY-0000Pm-4y; Thu, 28 Feb 2013 15:13: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 1UB5AW-0000Pe-QM
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:13:12 +0000
Received: from [85.158.137.99:59707] by server-11.bemta-3.messagelabs.com id
	BA/D3-01263-3047F215; Thu, 28 Feb 2013 15:13:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1362064387!18606175!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22675 invoked from network); 28 Feb 2013 15:13:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2036342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 15:13: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.297.1; Thu, 28 Feb 2013 15:13:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB5AQ-0006NL-9L; Thu, 28 Feb 2013 15:13:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB5AQ-0004t5-39;
	Thu, 28 Feb 2013 15:13:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.29697.855144.666857@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 15:13:05 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512F6AD902000078000C2038@nat28.tlf.novell.com>
References: <20783.17596.210245.887390@mariner.uk.xensource.com>
	<512F6AD902000078000C2038@nat28.tlf.novell.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.1 PATCH] Add .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich writes ("Re: [Xen 4.1 PATCH] Add .gitignore"):
> >     Add .gitignore
> >     
> >     Copy .gitignore from staging-4.2 current tip
> >     (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e).
> >     
> >     Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Oh yes, please. I don't think there's any need to wait for any
> ack on an obvious infrastructural change like this.

OK, good :-).  Pushed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:13:31 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:13: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 1UB5AY-0000Pm-4y; Thu, 28 Feb 2013 15:13: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 1UB5AW-0000Pe-QM
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:13:12 +0000
Received: from [85.158.137.99:59707] by server-11.bemta-3.messagelabs.com id
	BA/D3-01263-3047F215; Thu, 28 Feb 2013 15:13:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1362064387!18606175!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22675 invoked from network); 28 Feb 2013 15:13:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2036342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 15:13: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.297.1; Thu, 28 Feb 2013 15:13:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB5AQ-0006NL-9L; Thu, 28 Feb 2013 15:13:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB5AQ-0004t5-39;
	Thu, 28 Feb 2013 15:13:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.29697.855144.666857@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 15:13:05 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <512F6AD902000078000C2038@nat28.tlf.novell.com>
References: <20783.17596.210245.887390@mariner.uk.xensource.com>
	<512F6AD902000078000C2038@nat28.tlf.novell.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.1 PATCH] Add .gitignore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Beulich writes ("Re: [Xen 4.1 PATCH] Add .gitignore"):
> >     Add .gitignore
> >     
> >     Copy .gitignore from staging-4.2 current tip
> >     (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e).
> >     
> >     Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Oh yes, please. I don't think there's any need to wait for any
> ack on an obvious infrastructural change like this.

OK, good :-).  Pushed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:15:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:15: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 1UB5CT-0000ZZ-Se; Thu, 28 Feb 2013 15:15:13 +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 1UB5CT-0000ZP-2z
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:15:13 +0000
Received: from [85.158.139.211:2633] by server-7.bemta-5.messagelabs.com id
	11/CE-12441-0847F215; Thu, 28 Feb 2013 15:15:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1362064502!19316996!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11946 invoked from network); 28 Feb 2013 15:15:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 15:15:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:15:02 +0000
Message-Id: <512F828402000078000C2171@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:15:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>,
	"Andres Lagar-Cavilla" <andreslc@gridcentric.ca>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
	<512F728B02000078000C20B5@nat28.tlf.novell.com>
	<AE87D7B7-2D99-4EB8-BD32-A5AEB1EE781B@gridcentric.ca>
In-Reply-To: <AE87D7B7-2D99-4EB8-BD32-A5AEB1EE781B@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 28.02.13 at 15:59, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
> On Feb 28, 2013, at 9:06 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 28.02.13 at 12:56, Tim Deegan <tim@xen.org> wrote:
>>> At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
>>>> There seems to be something else amiss though. Unless I am parsing
>>>> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
>>>> | PCD? Looks like a very unlikely combination
>>> 
>>> By my reading, 
>>> 
>>> taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
>>> caf = 0x0180000000000000 = refcount 0, PGC_state_free
>> 
>> Right.
> D'oh :)
> 
> Sharing code never sets PGT_writable, only sets/clears PGT_shared. I tend to 
> think the dom_cow rd belies a different problem. To use dom_cow, the domain 
> has to have an explicit domctl that enables memory sharing.

In that case, Olaf, could you simply set dom_cow to some invalid
pointer right after it got set up through domain_create(), so that
any dereference of it would blow up? That might be the faster path
towards finding the first bogus use.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:15:24 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:15: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 1UB5CT-0000ZZ-Se; Thu, 28 Feb 2013 15:15:13 +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 1UB5CT-0000ZP-2z
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:15:13 +0000
Received: from [85.158.139.211:2633] by server-7.bemta-5.messagelabs.com id
	11/CE-12441-0847F215; Thu, 28 Feb 2013 15:15:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1362064502!19316996!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11946 invoked from network); 28 Feb 2013 15:15:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 15:15:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:15:02 +0000
Message-Id: <512F828402000078000C2171@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:15:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>,
	"Andres Lagar-Cavilla" <andreslc@gridcentric.ca>
References: <mailman.24679.1361784883.1399.xen-devel@lists.xen.org>
	<0DB93BA9-027D-427D-8D3A-8F708558E607@gridcentric.ca>
	<20130228115606.GD27704@ocelot.phlegethon.org>
	<512F728B02000078000C20B5@nat28.tlf.novell.com>
	<AE87D7B7-2D99-4EB8-BD32-A5AEB1EE781B@gridcentric.ca>
In-Reply-To: <AE87D7B7-2D99-4EB8-BD32-A5AEB1EE781B@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] error in xen/arch/x86/mm.c:get_page during 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 28.02.13 at 15:59, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
> On Feb 28, 2013, at 9:06 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 28.02.13 at 12:56, Tim Deegan <tim@xen.org> wrote:
>>> At 09:52 -0500 on 25 Feb (1361785966), Andres Lagar-Cavilla wrote:
>>>> There seems to be something else amiss though. Unless I am parsing
>>>> this incorrectly, taf == PGT_writable | PGT_pae_xen_l2? And caf == PAT
>>>> | PCD? Looks like a very unlikely combination
>>> 
>>> By my reading, 
>>> 
>>> taf = 0x7400000000000001 = typecount 1, PGT_writable_page | PGT_validated
>>> caf = 0x0180000000000000 = refcount 0, PGC_state_free
>> 
>> Right.
> D'oh :)
> 
> Sharing code never sets PGT_writable, only sets/clears PGT_shared. I tend to 
> think the dom_cow rd belies a different problem. To use dom_cow, the domain 
> has to have an explicit domctl that enables memory sharing.

In that case, Olaf, could you simply set dom_cow to some invalid
pointer right after it got set up through domain_create(), so that
any dereference of it would blow up? That might be the faster path
towards finding the first bogus use.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:32:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:32: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 1UB5Sp-00013n-0G; Thu, 28 Feb 2013 15:32:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=764dbd6cd=chegger@amazon.de>)
	id 1UB5Sn-00013X-Ge
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:32:05 +0000
Received: from [85.158.138.51:57662] by server-11.bemta-3.messagelabs.com id
	C7/1F-01263-4787F215; Thu, 28 Feb 2013 15:32:04 +0000
X-Env-Sender: prvs=764dbd6cd=chegger@amazon.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1362065506!27926305!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE2OTk0MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8470 invoked from network); 28 Feb 2013 15:31:47 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:31:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="540376621"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2013 15:31:45 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	r1SFViHR023285
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK)
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 15:31:44 GMT
Received: from a8206654c64f.ant.amazon.com (172.17.1.118) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Thu, 28 Feb 2013 07:31:30 -0800
Message-ID: <512F7851.8020809@amazon.de>
Date: Thu, 28 Feb 2013 16:31:29 +0100
From: Egger Christoph <chegger@amazon.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
In-Reply-To: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 27.02.13 17:12, Jan Beulich wrote:
> Aiming at a release towards the end of March, I'd like to cut RC1-s
> at the beginning of next week.
> 
> Please indicate any bug fixes that so far may have been missed
> in the backports already done. Quite a few fixes are currently
> stuck in master's staging branch - these don't need to be named
> explicitly, I'm already planning to pull over the hypervisor ones
> as soon as they get out of staging (and I'm sure Ian is planning
> the same - if applicable at all - for the tools side).
> 
> Ian - one thing I think is still open for 4.1.5 is the xz kernel
> decompression support that was explicitly requested on the list.
> Can this be expected to go in for RC1?
> 
> Jan

Hi Jan,

I request the backport of
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59dd9b8ca890be08b0b874
to Xen 4.2.

Christoph


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:32:22 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:32: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 1UB5Sp-00013n-0G; Thu, 28 Feb 2013 15:32:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=764dbd6cd=chegger@amazon.de>)
	id 1UB5Sn-00013X-Ge
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:32:05 +0000
Received: from [85.158.138.51:57662] by server-11.bemta-3.messagelabs.com id
	C7/1F-01263-4787F215; Thu, 28 Feb 2013 15:32:04 +0000
X-Env-Sender: prvs=764dbd6cd=chegger@amazon.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1362065506!27926305!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE2OTk0MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8470 invoked from network); 28 Feb 2013 15:31:47 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:31:47 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="540376621"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2013 15:31:45 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	r1SFViHR023285
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK)
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 15:31:44 GMT
Received: from a8206654c64f.ant.amazon.com (172.17.1.118) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Thu, 28 Feb 2013 07:31:30 -0800
Message-ID: <512F7851.8020809@amazon.de>
Date: Thu, 28 Feb 2013 16:31:29 +0100
From: Egger Christoph <chegger@amazon.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
In-Reply-To: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 27.02.13 17:12, Jan Beulich wrote:
> Aiming at a release towards the end of March, I'd like to cut RC1-s
> at the beginning of next week.
> 
> Please indicate any bug fixes that so far may have been missed
> in the backports already done. Quite a few fixes are currently
> stuck in master's staging branch - these don't need to be named
> explicitly, I'm already planning to pull over the hypervisor ones
> as soon as they get out of staging (and I'm sure Ian is planning
> the same - if applicable at all - for the tools side).
> 
> Ian - one thing I think is still open for 4.1.5 is the xz kernel
> decompression support that was explicitly requested on the list.
> Can this be expected to go in for RC1?
> 
> Jan

Hi Jan,

I request the backport of
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59dd9b8ca890be08b0b874
to Xen 4.2.

Christoph


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:42:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:42: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 1UB5cG-0001Wt-4j; Thu, 28 Feb 2013 15:41:52 +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 1UB5cE-0001Wo-5M
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:41:50 +0000
Received: from [85.158.143.99:44129] by server-3.bemta-4.messagelabs.com id
	E9/67-02186-CBA7F215; Thu, 28 Feb 2013 15:41:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1362066081!19905492!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8449 invoked from network); 28 Feb 2013 15:41:26 -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; 28 Feb 2013 15:41:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:41:21 +0000
Message-Id: <512F88B002000078000C21AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:41:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
In-Reply-To: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
> ... this must not be done when on the NMI stack (i.e. when the
> NMI was raised while in hypervisor context). Checking for this
> here would be strait forward, but I was really considering to do
> all of this in the assembly exit path, and I was still undecided
> whether we shouldn't follow Linux in skipping softirq processing
> (and hence scheduling) on the way out from an NMI (I don't
> think we'd need to do the same for MCE).

Like this:

x86: skip processing events on the NMI exit path

Otherwise, we may end up in the scheduler, keeping NMIs masked for a
possibly unbounded time (until whenever the next IRET gets executed).

Of course it's open for discussion whether to always use the strait
exit path from handle_ist_exception.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -171,7 +171,7 @@ compat_bad_hypercall:
         jmp  compat_test_all_events
 
 /* %rbx: struct vcpu, interrupts disabled */
-compat_restore_all_guest:
+ENTRY(compat_restore_all_guest)
         ASSERT_INTERRUPTS_DISABLED
         RESTORE_ALL adj=8 compat=1
 .Lft0:  iretq
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -635,6 +635,9 @@ ENTRY(early_page_fault)
         jmp   restore_all_xen
         .popsection
 
+ENTRY(nmi)
+        pushq $0
+        movl  $TRAP_nmi,4(%rsp)
 handle_ist_exception:
         SAVE_ALL
         testb $3,UREGS_cs(%rsp)
@@ -649,12 +652,17 @@ handle_ist_exception:
         movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
         callq *(%rdx,%rax,8)
-        jmp   ret_from_intr
+        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
+        jne   ret_from_intr
 
-ENTRY(nmi)
-        pushq $0
-        movl  $TRAP_nmi,4(%rsp)
-        jmp   handle_ist_exception
+        /* We want to get strait to the IRET in the NMI exit path. */
+        testb $3,UREGS_cs(%rsp)
+        GET_CURRENT(%rbx)
+        jz    restore_all_xen
+        movq  VCPU_domain(%rbx),%rax
+        testb $1,DOMAIN_is_32bit_pv(%rax)
+        jz    restore_all_guest
+        jmp   compat_restore_all_guest
 
 ENTRY(nmi_crash)
         pushq $0




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:42:05 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15:42: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 1UB5cG-0001Wt-4j; Thu, 28 Feb 2013 15:41:52 +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 1UB5cE-0001Wo-5M
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:41:50 +0000
Received: from [85.158.143.99:44129] by server-3.bemta-4.messagelabs.com id
	E9/67-02186-CBA7F215; Thu, 28 Feb 2013 15:41:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1362066081!19905492!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8449 invoked from network); 28 Feb 2013 15:41:26 -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; 28 Feb 2013 15:41:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:41:21 +0000
Message-Id: <512F88B002000078000C21AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:41:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
In-Reply-To: <512F7ADE02000078000C211A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
> ... this must not be done when on the NMI stack (i.e. when the
> NMI was raised while in hypervisor context). Checking for this
> here would be strait forward, but I was really considering to do
> all of this in the assembly exit path, and I was still undecided
> whether we shouldn't follow Linux in skipping softirq processing
> (and hence scheduling) on the way out from an NMI (I don't
> think we'd need to do the same for MCE).

Like this:

x86: skip processing events on the NMI exit path

Otherwise, we may end up in the scheduler, keeping NMIs masked for a
possibly unbounded time (until whenever the next IRET gets executed).

Of course it's open for discussion whether to always use the strait
exit path from handle_ist_exception.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -171,7 +171,7 @@ compat_bad_hypercall:
         jmp  compat_test_all_events
 
 /* %rbx: struct vcpu, interrupts disabled */
-compat_restore_all_guest:
+ENTRY(compat_restore_all_guest)
         ASSERT_INTERRUPTS_DISABLED
         RESTORE_ALL adj=8 compat=1
 .Lft0:  iretq
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -635,6 +635,9 @@ ENTRY(early_page_fault)
         jmp   restore_all_xen
         .popsection
 
+ENTRY(nmi)
+        pushq $0
+        movl  $TRAP_nmi,4(%rsp)
 handle_ist_exception:
         SAVE_ALL
         testb $3,UREGS_cs(%rsp)
@@ -649,12 +652,17 @@ handle_ist_exception:
         movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
         callq *(%rdx,%rax,8)
-        jmp   ret_from_intr
+        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
+        jne   ret_from_intr
 
-ENTRY(nmi)
-        pushq $0
-        movl  $TRAP_nmi,4(%rsp)
-        jmp   handle_ist_exception
+        /* We want to get strait to the IRET in the NMI exit path. */
+        testb $3,UREGS_cs(%rsp)
+        GET_CURRENT(%rbx)
+        jz    restore_all_xen
+        movq  VCPU_domain(%rbx),%rax
+        testb $1,DOMAIN_is_32bit_pv(%rax)
+        jz    restore_all_guest
+        jmp   compat_restore_all_guest
 
 ENTRY(nmi_crash)
         pushq $0




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:44:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5e5-0001bm-Lr; Thu, 28 Feb 2013 15:43:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB5e4-0001be-SD
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:43:45 +0000
Received: from [193.109.254.147:29912] by server-5.bemta-14.messagelabs.com id
	C0/43-21539-03B7F215; Thu, 28 Feb 2013 15:43:44 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-16.tower-27.messagelabs.com!1362065935!9914882!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13269 invoked from network); 28 Feb 2013 15:38:55 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-16.tower-27.messagelabs.com with SMTP;
	28 Feb 2013 15:38:55 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362065934; bh=0A541K7YGbFV05EgGrW90QmtkH2MVzjp+eov0tx3+X8=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=rbpCyjj4VzgXdH+vQIW1PYjjQtwUIqyQZG90kE
	6TvNCcmgxaHX1IoC0GAQSNhmAd2YDU4c6XQ41as474awhvO8rw77V1Rvx9ArrirQ1Zf
	HdIQQO3xT8N/JGVMeJy9xAloMKkSs766fQwvRKEY4ZnoGGXGobBTqWi69WraSrqhyU=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id VF74MdnGxDMM; Thu, 28 Feb 2013 16:38:54 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	7DDD81D9DC9; Thu, 28 Feb 2013 16:38:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362065934; bh=0A541K7YGbFV05EgGrW90QmtkH2MVzjp+eov0tx3+X8=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=rbpCyjj4VzgXdH+vQIW1PYjjQtwUIqyQZG90kE
	6TvNCcmgxaHX1IoC0GAQSNhmAd2YDU4c6XQ41as474awhvO8rw77V1Rvx9ArrirQ1Zf
	HdIQQO3xT8N/JGVMeJy9xAloMKkSs766fQwvRKEY4ZnoGGXGobBTqWi69WraSrqhyU=
Received: by liondog.tnic (Postfix, from userid 1000)
	id 01547100A74; Thu, 28 Feb 2013 16:38:46 +0100 (CET)
Date: Thu, 28 Feb 2013 16:38:46 +0100
From: Borislav Petkov <bp@alien8.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130228153846.GA9782@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130228142910.GA32354@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: jwboyer@redhat.com, Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	samu.kallio@aberdeencloud.com, kraman@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index fb674fd..4f7d793 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
>  	if (pgd_none(*pgd_ref))
>  		return -1;
>  
> -	if (pgd_none(*pgd))
> +	if (pgd_none(*pgd)) {
>  		set_pgd(pgd, *pgd_ref);
> -	else
> +		arch_flush_lazy_mmu_mode();

Do I understand it correctly that this would cost us a
"preempt_disable(); preempt_enable()" needlessly on baremetal when
running with CONFIG_PARAVIRT enabled?

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:44:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5e5-0001bm-Lr; Thu, 28 Feb 2013 15:43:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB5e4-0001be-SD
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:43:45 +0000
Received: from [193.109.254.147:29912] by server-5.bemta-14.messagelabs.com id
	C0/43-21539-03B7F215; Thu, 28 Feb 2013 15:43:44 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-16.tower-27.messagelabs.com!1362065935!9914882!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13269 invoked from network); 28 Feb 2013 15:38:55 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-16.tower-27.messagelabs.com with SMTP;
	28 Feb 2013 15:38:55 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362065934; bh=0A541K7YGbFV05EgGrW90QmtkH2MVzjp+eov0tx3+X8=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=rbpCyjj4VzgXdH+vQIW1PYjjQtwUIqyQZG90kE
	6TvNCcmgxaHX1IoC0GAQSNhmAd2YDU4c6XQ41as474awhvO8rw77V1Rvx9ArrirQ1Zf
	HdIQQO3xT8N/JGVMeJy9xAloMKkSs766fQwvRKEY4ZnoGGXGobBTqWi69WraSrqhyU=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id VF74MdnGxDMM; Thu, 28 Feb 2013 16:38:54 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	7DDD81D9DC9; Thu, 28 Feb 2013 16:38:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362065934; bh=0A541K7YGbFV05EgGrW90QmtkH2MVzjp+eov0tx3+X8=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=rbpCyjj4VzgXdH+vQIW1PYjjQtwUIqyQZG90kE
	6TvNCcmgxaHX1IoC0GAQSNhmAd2YDU4c6XQ41as474awhvO8rw77V1Rvx9ArrirQ1Zf
	HdIQQO3xT8N/JGVMeJy9xAloMKkSs766fQwvRKEY4ZnoGGXGobBTqWi69WraSrqhyU=
Received: by liondog.tnic (Postfix, from userid 1000)
	id 01547100A74; Thu, 28 Feb 2013 16:38:46 +0100 (CET)
Date: Thu, 28 Feb 2013 16:38:46 +0100
From: Borislav Petkov <bp@alien8.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20130228153846.GA9782@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20130228142910.GA32354@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: jwboyer@redhat.com, Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	samu.kallio@aberdeencloud.com, kraman@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index fb674fd..4f7d793 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
>  	if (pgd_none(*pgd_ref))
>  		return -1;
>  
> -	if (pgd_none(*pgd))
> +	if (pgd_none(*pgd)) {
>  		set_pgd(pgd, *pgd_ref);
> -	else
> +		arch_flush_lazy_mmu_mode();

Do I understand it correctly that this would cost us a
"preempt_disable(); preempt_enable()" needlessly on baremetal when
running with CONFIG_PARAVIRT enabled?

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:45:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5fg-0001it-7a; Thu, 28 Feb 2013 15:45:24 +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 1UB5fe-0001im-Nj
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:45:22 +0000
Received: from [193.109.254.147:59871] by server-9.bemta-14.messagelabs.com id
	FC/F2-30867-19B7F215; Thu, 28 Feb 2013 15:45:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1362066260!9426610!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15311 invoked from network); 28 Feb 2013 15:44:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 15:44:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:44:20 +0000
Message-Id: <512F896102000078000C21C1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:44:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Egger Christoph" <chegger@amazon.de>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<512F7851.8020809@amazon.de>
In-Reply-To: <512F7851.8020809@amazon.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 28.02.13 at 16:31, Egger Christoph <chegger@amazon.de> wrote:
> On 27.02.13 17:12, Jan Beulich wrote:
>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>> at the beginning of next week.
>> 
>> Please indicate any bug fixes that so far may have been missed
>> in the backports already done. Quite a few fixes are currently
>> stuck in master's staging branch - these don't need to be named
>> explicitly, I'm already planning to pull over the hypervisor ones
>> as soon as they get out of staging (and I'm sure Ian is planning
>> the same - if applicable at all - for the tools side).
>
> I request the backport of
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59 
> dd9b8ca890be08b0b874
> to Xen 4.2.

That's among the ones mentioned above (which meanwhile came
out of staging, but I didn't get around to make all of them apply
to 4.2 [and 4.1 where necessary] yet).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:45:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5fg-0001it-7a; Thu, 28 Feb 2013 15:45:24 +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 1UB5fe-0001im-Nj
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:45:22 +0000
Received: from [193.109.254.147:59871] by server-9.bemta-14.messagelabs.com id
	FC/F2-30867-19B7F215; Thu, 28 Feb 2013 15:45:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1362066260!9426610!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15311 invoked from network); 28 Feb 2013 15:44:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 15:44:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 15:44:20 +0000
Message-Id: <512F896102000078000C21C1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 15:44:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Egger Christoph" <chegger@amazon.de>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<512F7851.8020809@amazon.de>
In-Reply-To: <512F7851.8020809@amazon.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.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 28.02.13 at 16:31, Egger Christoph <chegger@amazon.de> wrote:
> On 27.02.13 17:12, Jan Beulich wrote:
>> Aiming at a release towards the end of March, I'd like to cut RC1-s
>> at the beginning of next week.
>> 
>> Please indicate any bug fixes that so far may have been missed
>> in the backports already done. Quite a few fixes are currently
>> stuck in master's staging branch - these don't need to be named
>> explicitly, I'm already planning to pull over the hypervisor ones
>> as soon as they get out of staging (and I'm sure Ian is planning
>> the same - if applicable at all - for the tools side).
>
> I request the backport of
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59 
> dd9b8ca890be08b0b874
> to Xen 4.2.

That's among the ones mentioned above (which meanwhile came
out of staging, but I didn't get around to make all of them apply
to 4.2 [and 4.1 where necessary] yet).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:52:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5me-00024l-4P; Thu, 28 Feb 2013 15:52:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB5mc-00024g-Kc
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:52:34 +0000
Received: from [85.158.139.211:16587] by server-15.bemta-5.messagelabs.com id
	9C/3F-22815-14D7F215; Thu, 28 Feb 2013 15:52:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1362066751!15786028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29020 invoked from network); 28 Feb 2013 15:52:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10305415"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 15:52:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 10:52:31 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB5mY-0003OP-TN;
	Thu, 28 Feb 2013 15:52:30 +0000
Message-ID: <512F7D3E.9070300@citrix.com>
Date: Thu, 28 Feb 2013 15:52:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<512F88B002000078000C21AA@nat28.tlf.novell.com>
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/13 15:41, Jan Beulich wrote:
>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>> ... this must not be done when on the NMI stack (i.e. when the
>> NMI was raised while in hypervisor context). Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> Like this:
>
> x86: skip processing events on the NMI exit path
>
> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
> possibly unbounded time (until whenever the next IRET gets executed).
>
> Of course it's open for discussion whether to always use the strait
> exit path from handle_ist_exception.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The logic looks good to me.  As for the other IST exceptions, we will
never return from a double fault, and will rarely return from an MCE, so
I would say it doesn't really matter at the moment.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

~Andrew

>
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -171,7 +171,7 @@ compat_bad_hypercall:
>          jmp  compat_test_all_events
>  
>  /* %rbx: struct vcpu, interrupts disabled */
> -compat_restore_all_guest:
> +ENTRY(compat_restore_all_guest)
>          ASSERT_INTERRUPTS_DISABLED
>          RESTORE_ALL adj=8 compat=1
>  .Lft0:  iretq
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */
> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen
> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $0
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:52:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5me-00024l-4P; Thu, 28 Feb 2013 15:52:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1UB5mc-00024g-Kc
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:52:34 +0000
Received: from [85.158.139.211:16587] by server-15.bemta-5.messagelabs.com id
	9C/3F-22815-14D7F215; Thu, 28 Feb 2013 15:52:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1362066751!15786028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29020 invoked from network); 28 Feb 2013 15:52:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 15:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="10305415"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 15:52:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 10:52:31 -0500
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1UB5mY-0003OP-TN;
	Thu, 28 Feb 2013 15:52:30 +0000
Message-ID: <512F7D3E.9070300@citrix.com>
Date: Thu, 28 Feb 2013 15:52:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.12) Gecko/20130119 Icedove/10.0.12
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <d7ea938044ac0212ce31.1353596446@andrewcoop.uk.xensource.com>
	<50AE4F8402000078000AAA02@nat28.tlf.novell.com>
	<50AE41DD.2030703@citrix.com>
	<50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<512F88B002000078000C21AA@nat28.tlf.novell.com>
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/13 15:41, Jan Beulich wrote:
>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>> ... this must not be done when on the NMI stack (i.e. when the
>> NMI was raised while in hypervisor context). Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> Like this:
>
> x86: skip processing events on the NMI exit path
>
> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
> possibly unbounded time (until whenever the next IRET gets executed).
>
> Of course it's open for discussion whether to always use the strait
> exit path from handle_ist_exception.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

The logic looks good to me.  As for the other IST exceptions, we will
never return from a double fault, and will rarely return from an MCE, so
I would say it doesn't really matter at the moment.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

~Andrew

>
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -171,7 +171,7 @@ compat_bad_hypercall:
>          jmp  compat_test_all_events
>  
>  /* %rbx: struct vcpu, interrupts disabled */
> -compat_restore_all_guest:
> +ENTRY(compat_restore_all_guest)
>          ASSERT_INTERRUPTS_DISABLED
>          RESTORE_ALL adj=8 compat=1
>  .Lft0:  iretq
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */
> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen
> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $0
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:56:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB5q1-0002K0-Cv; Thu, 28 Feb 2013 15:56:05 +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 1UB5pz-0002Jr-L1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:56:03 +0000
Received: from [85.158.138.51:41182] by server-4.bemta-3.messagelabs.com id
	42/B5-21470-21E7F215; Thu, 28 Feb 2013 15:56:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362066946!28619840!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25441 invoked from network); 28 Feb 2013 15:55:47 -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; 28 Feb 2013 15:55:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB5pd-0008E3-CS; Thu, 28 Feb 2013 15:55:41 +0000
Date: Thu, 28 Feb 2013 15:55:41 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228155541.GJ27704@ocelot.phlegethon.org>
References: <50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<512F88B002000078000C21AA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 15:41 +0000 on 28 Feb (1362066080), Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */

Language nit: 'straight', meaning linear or directly, is suitable here. 
'strait' means narrow or constrained (as in strait-jacket).

> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen

GET_CURRENT() contains an addq, which updates ZF.  Swap it with the
testb?

Otherwise, looks good to me. 

Reviewed-by: Tim Deegan <tim@xen.org>

> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $0
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:56:18 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB5q1-0002K0-Cv; Thu, 28 Feb 2013 15:56:05 +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 1UB5pz-0002Jr-L1
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:56:03 +0000
Received: from [85.158.138.51:41182] by server-4.bemta-3.messagelabs.com id
	42/B5-21470-21E7F215; Thu, 28 Feb 2013 15:56:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1362066946!28619840!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25441 invoked from network); 28 Feb 2013 15:55:47 -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; 28 Feb 2013 15:55:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1UB5pd-0008E3-CS; Thu, 28 Feb 2013 15:55:41 +0000
Date: Thu, 28 Feb 2013 15:55:41 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20130228155541.GJ27704@ocelot.phlegethon.org>
References: <50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<512F88B002000078000C21AA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	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

At 15:41 +0000 on 28 Feb (1362066080), Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */

Language nit: 'straight', meaning linear or directly, is suitable here. 
'strait' means narrow or constrained (as in strait-jacket).

> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen

GET_CURRENT() contains an addq, which updates ZF.  Swap it with the
testb?

Otherwise, looks good to me. 

Reviewed-by: Tim Deegan <tim@xen.org>

> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $0
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 15:57:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5rS-0002U6-2U; Thu, 28 Feb 2013 15:57:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1UB5rQ-0002Tt-G5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:57:32 +0000
Received: from [85.158.143.99:31898] by server-3.bemta-4.messagelabs.com id
	0E/18-02186-B6E7F215; Thu, 28 Feb 2013 15:57:31 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1362066917!29055798!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5216 invoked from network); 28 Feb 2013 15:55:19 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 15:55:19 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1SFrnmp013171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 07:53:50 -0800
Message-ID: <512F7D88.4090703@zytor.com>
Date: Thu, 28 Feb 2013 07:53:44 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic>
In-Reply-To: <20130228153846.GA9782@pd.tnic>
X-Enigmail-Version: 1.5
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/28/2013 07:38 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index fb674fd..4f7d793 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
>>  	if (pgd_none(*pgd_ref))
>>  		return -1;
>>  
>> -	if (pgd_none(*pgd))
>> +	if (pgd_none(*pgd)) {
>>  		set_pgd(pgd, *pgd_ref);
>> -	else
>> +		arch_flush_lazy_mmu_mode();
> 
> Do I understand it correctly that this would cost us a
> "preempt_disable(); preempt_enable()" needlessly on baremetal when
> running with CONFIG_PARAVIRT enabled?
> 

OK, this is mind-boggingly crazy and these things that just drives me
batty about PV.

arch_flush_lazy_mmu_mode() involves a function call and preemption off
*before it even tests for being a noop*.  On bare metal this function
doesn't do anything, and cannot do anything.

At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.

	-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 Thu Feb 28 15:57:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 15: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 1UB5rS-0002U6-2U; Thu, 28 Feb 2013 15:57:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hpa@zytor.com>) id 1UB5rQ-0002Tt-G5
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 15:57:32 +0000
Received: from [85.158.143.99:31898] by server-3.bemta-4.messagelabs.com id
	0E/18-02186-B6E7F215; Thu, 28 Feb 2013 15:57:31 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1362066917!29055798!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5216 invoked from network); 28 Feb 2013 15:55:19 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 15:55:19 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1SFrnmp013171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 07:53:50 -0800
Message-ID: <512F7D88.4090703@zytor.com>
Date: Thu, 28 Feb 2013 07:53:44 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic>
In-Reply-To: <20130228153846.GA9782@pd.tnic>
X-Enigmail-Version: 1.5
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/28/2013 07:38 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index fb674fd..4f7d793 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
>>  	if (pgd_none(*pgd_ref))
>>  		return -1;
>>  
>> -	if (pgd_none(*pgd))
>> +	if (pgd_none(*pgd)) {
>>  		set_pgd(pgd, *pgd_ref);
>> -	else
>> +		arch_flush_lazy_mmu_mode();
> 
> Do I understand it correctly that this would cost us a
> "preempt_disable(); preempt_enable()" needlessly on baremetal when
> running with CONFIG_PARAVIRT enabled?
> 

OK, this is mind-boggingly crazy and these things that just drives me
batty about PV.

arch_flush_lazy_mmu_mode() involves a function call and preemption off
*before it even tests for being a noop*.  On bare metal this function
doesn't do anything, and cannot do anything.

At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.

	-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 Thu Feb 28 16:01:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:01: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 1UB5v6-0003BA-Nm; Thu, 28 Feb 2013 16:01:20 +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 1UB5v5-0003B3-V2
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:01:20 +0000
Received: from [85.158.139.83:3834] by server-12.bemta-5.messagelabs.com id
	B2/1B-11486-F4F7F215; Thu, 28 Feb 2013 16:01:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1362067278!29528394!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26560 invoked from network); 28 Feb 2013 16:01:18 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:01:18 -0000
Received: by mail-wi0-f169.google.com with SMTP id l13so9230131wie.4
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 08:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=VRgK62Bp8biSfUOt+FyMYuBbKU+CF/i4uvtxxo9a2jY=;
	b=WnDE7CM3eG/pYCueW558wyennO+HX3h1gKC1AR5/sokzk6yH6L4TjMvmxUEipGjQtX
	Y5gyGUTxwPtuPF67hLvBJVKcFBtuLSQTCLxKMnnUMjVPGyZ3ZHcgrbmbObV4NV/MEXq9
	ezHuK0x/xwzkJsTjA9ml6sI099WDytXFfegNzTN03DD+fL//4PvNwk0+oKL6tWjpAWHY
	AQHFnWb3ibouqX/0w2zBAuYYvdSTyz2Bgxxq3neQvyvhS3v9ONm4RsEvbdMs0a2+gCft
	49mQZxEVhDOwsCLPa01nGK4q9IU9QbyBEEAMAO9tQB/AVCoB+atMKx872226UVoN2ISZ
	GL1w==
X-Received: by 10.194.84.8 with SMTP id u8mr12007812wjy.29.1362067277256;
	Thu, 28 Feb 2013 08:01:17 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ej8sm34204576wib.9.2013.02.28.08.01.15
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 28 Feb 2013 08:01:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 28 Feb 2013 16:01:09 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD552FC5.5D0ED%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	handler
Thread-Index: Ac4VzNKITi0vsW4icESL32k5xvtQ9Q==
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/2013 15:41, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>> ... this must not be done when on the NMI stack (i.e. when the
>> NMI was raised while in hypervisor context). Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> 
> Like this:
> 
> x86: skip processing events on the NMI exit path
> 
> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
> possibly unbounded time (until whenever the next IRET gets executed).

Is this alternative that we might not process events for an unbounded time?
No, I guess not -- either we would interrupt the notifying IPI and we will
be IRETing into that IPI's handler, or the notifying IPI is delayed until
the NMI handler's IRET.

What about if the NMI handler itself raises an event (eg softirq)? Perhaps
there are no very essential ones of those?

> Of course it's open for discussion whether to always use the strait
> exit path from handle_ist_exception.

s/strait/straight (and below in the code comment that you add).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -171,7 +171,7 @@ compat_bad_hypercall:
>          jmp  compat_test_all_events
>  
>  /* %rbx: struct vcpu, interrupts disabled */
> -compat_restore_all_guest:
> +ENTRY(compat_restore_all_guest)
>          ASSERT_INTERRUPTS_DISABLED
>          RESTORE_ALL adj=8 compat=1
>  .Lft0:  iretq
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */
> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen
> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $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 Thu Feb 28 16:01:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:01: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 1UB5v6-0003BA-Nm; Thu, 28 Feb 2013 16:01:20 +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 1UB5v5-0003B3-V2
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:01:20 +0000
Received: from [85.158.139.83:3834] by server-12.bemta-5.messagelabs.com id
	B2/1B-11486-F4F7F215; Thu, 28 Feb 2013 16:01:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1362067278!29528394!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26560 invoked from network); 28 Feb 2013 16:01:18 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:01:18 -0000
Received: by mail-wi0-f169.google.com with SMTP id l13so9230131wie.4
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 08:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received: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=VRgK62Bp8biSfUOt+FyMYuBbKU+CF/i4uvtxxo9a2jY=;
	b=WnDE7CM3eG/pYCueW558wyennO+HX3h1gKC1AR5/sokzk6yH6L4TjMvmxUEipGjQtX
	Y5gyGUTxwPtuPF67hLvBJVKcFBtuLSQTCLxKMnnUMjVPGyZ3ZHcgrbmbObV4NV/MEXq9
	ezHuK0x/xwzkJsTjA9ml6sI099WDytXFfegNzTN03DD+fL//4PvNwk0+oKL6tWjpAWHY
	AQHFnWb3ibouqX/0w2zBAuYYvdSTyz2Bgxxq3neQvyvhS3v9ONm4RsEvbdMs0a2+gCft
	49mQZxEVhDOwsCLPa01nGK4q9IU9QbyBEEAMAO9tQB/AVCoB+atMKx872226UVoN2ISZ
	GL1w==
X-Received: by 10.194.84.8 with SMTP id u8mr12007812wjy.29.1362067277256;
	Thu, 28 Feb 2013 08:01:17 -0800 (PST)
Received: from [192.168.1.3] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id ej8sm34204576wib.9.2013.02.28.08.01.15
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 28 Feb 2013 08:01:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 28 Feb 2013 16:01:09 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD552FC5.5D0ED%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	handler
Thread-Index: Ac4VzNKITi0vsW4icESL32k5xvtQ9Q==
In-Reply-To: <512F88B002000078000C21AA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/2013 15:41, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>> ... this must not be done when on the NMI stack (i.e. when the
>> NMI was raised while in hypervisor context). Checking for this
>> here would be strait forward, but I was really considering to do
>> all of this in the assembly exit path, and I was still undecided
>> whether we shouldn't follow Linux in skipping softirq processing
>> (and hence scheduling) on the way out from an NMI (I don't
>> think we'd need to do the same for MCE).
> 
> Like this:
> 
> x86: skip processing events on the NMI exit path
> 
> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
> possibly unbounded time (until whenever the next IRET gets executed).

Is this alternative that we might not process events for an unbounded time?
No, I guess not -- either we would interrupt the notifying IPI and we will
be IRETing into that IPI's handler, or the notifying IPI is delayed until
the NMI handler's IRET.

What about if the NMI handler itself raises an event (eg softirq)? Perhaps
there are no very essential ones of those?

> Of course it's open for discussion whether to always use the strait
> exit path from handle_ist_exception.

s/strait/straight (and below in the code comment that you add).

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -171,7 +171,7 @@ compat_bad_hypercall:
>          jmp  compat_test_all_events
>  
>  /* %rbx: struct vcpu, interrupts disabled */
> -compat_restore_all_guest:
> +ENTRY(compat_restore_all_guest)
>          ASSERT_INTERRUPTS_DISABLED
>          RESTORE_ALL adj=8 compat=1
>  .Lft0:  iretq
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -635,6 +635,9 @@ ENTRY(early_page_fault)
>          jmp   restore_all_xen
>          .popsection
>  
> +ENTRY(nmi)
> +        pushq $0
> +        movl  $TRAP_nmi,4(%rsp)
>  handle_ist_exception:
>          SAVE_ALL
>          testb $3,UREGS_cs(%rsp)
> @@ -649,12 +652,17 @@ handle_ist_exception:
>          movzbl UREGS_entry_vector(%rsp),%eax
>          leaq  exception_table(%rip),%rdx
>          callq *(%rdx,%rax,8)
> -        jmp   ret_from_intr
> +        cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
> +        jne   ret_from_intr
>  
> -ENTRY(nmi)
> -        pushq $0
> -        movl  $TRAP_nmi,4(%rsp)
> -        jmp   handle_ist_exception
> +        /* We want to get strait to the IRET in the NMI exit path. */
> +        testb $3,UREGS_cs(%rsp)
> +        GET_CURRENT(%rbx)
> +        jz    restore_all_xen
> +        movq  VCPU_domain(%rbx),%rax
> +        testb $1,DOMAIN_is_32bit_pv(%rax)
> +        jz    restore_all_guest
> +        jmp   compat_restore_all_guest
>  
>  ENTRY(nmi_crash)
>          pushq $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 Thu Feb 28 16:09:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:09: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 1UB62q-0003WC-N4; Thu, 28 Feb 2013 16:09:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1UB62o-0003W6-Vd
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:09:19 +0000
Received: from [193.109.254.147:4712] by server-15.bemta-14.messagelabs.com id
	77/CE-24599-E218F215; Thu, 28 Feb 2013 16:09:18 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1362067593!9251232!1
X-Originating-IP: [209.85.219.47]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16402 invoked from network); 28 Feb 2013 16:06:34 -0000
Received: from mail-oa0-f47.google.com (HELO mail-oa0-f47.google.com)
	(209.85.219.47)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:06:34 -0000
Received: by mail-oa0-f47.google.com with SMTP id o17so3848435oag.6
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 08:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=+l8Bodj+5cjZsL13hMJr8x4D1F8NLzlZAsxsVpjjig0=;
	b=OH703Egsgng1dOsxFDB3varhQPA6LuCzIjTXKw1VXTuH2Sazq327NiojUNC7SPwcEQ
	7SO1DiPTtazv5ZLVnn9KYptrCTGoudg54U0BlF/GSvxxLebLStjupL7MAQXOCECl88mM
	QG1Vn7TYrQR+pXcUxkQBtHB10GuVWRipGzyqeQ5JpHdyr4D2+Degr38hqX/Gv3OErCbb
	RJpvGs/X2IsWIe9vFXRj9ZSE5cr/ySU4uG2NKfAfjN40UjZfcz9B0/8OB9riuQEr79S/
	HNmiHCy49cLglbV6Nco5pUuLVOWJm3XKp/Ibo0nIM48yTz7S+d9lNY7N8qqK9ax8cBb6
	zPFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=+l8Bodj+5cjZsL13hMJr8x4D1F8NLzlZAsxsVpjjig0=;
	b=ACPJ68W0DCstChYhpr+X9nFE/O8H6l08WXOlMt4bKb/Et10LXUiqlqcotv1VjI2+WN
	6LJyWGvpp6dwqQqVcLiTuBf56PVVsObimWsFqv116I1rHUlYkP4sJibU+QeruCpjSBGM
	ld7XcAeXL1qXxUcdEDZAU1u0GmrNpOEOuSg1vnZvHAYc4e2JdLQ8zgRfLW7CKbEB5NVl
	yN8K4mw0XZpx1vKfSG7rg+GujPvesWZVlqn1kwKJSFzWDXux9TvuXNZEW6HEMQ0I0eWw
	9hIM0mHfOWfUCVDIa05mAO69qXF8Jf4YKRYIe/WWVc8G2FObZElpYtYDPmCHGs9F6Jin
	kj9Q==
X-Received: by 10.182.139.37 with SMTP id qv5mr5778117obb.92.1362067592986;
	Thu, 28 Feb 2013 08:06:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.104.104 with HTTP; Thu, 28 Feb 2013 08:06:12 -0800 (PST)
In-Reply-To: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
References: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Thu, 28 Feb 2013 09:06:12 -0700
Message-ID: <CAErSpo6+bHeNkP9rc6NUGweGfLa0CRw6H=Nny9cV-FL2xOGKeA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQn1ZKQJ4K3h0d7nfnR4fdMufYcjqxvDOSFEq1Vd9W1BqMwIVRVshCJOBg5LPkjwjh8ruinyUX2KTS4G/aTtR7i3CfqX4WHjjoq1XCQtiuM7ERo3hYfrsxi05jZu8V71IMyLnEZHL3FxIKiAvbjlSi7ihBy2CEliF2E2RQzQClDWPXLye20D3ZQa8fUxQztO08vgpsvj
Cc: linux-pci@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] time periods of no resource re-assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 2:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> Bjorn,
>
> in the context of dealing with the final part of a long known security
> issue on Xen, I'd appreciate if you could help me understand
> under what conditions (or at which times) MMIO resources for PCI
> devices can get re-assigned in Linux. Or really I'm in need to know
> under what conditions there won't be any resource re-assignment
> (i.e. we particularly need the BARs to be stable that cover the
> MSI-X table and the Pending Bit Array).
>
> Right now I'm intending to send the hypervisor a respective
> notification in the context of xen-pciback's probe function, after
> having called pci_enable_device(). Can you confirm that at this
> point, and until the driver lets go of the device again, resources
> won't get re-assigned? Or if not, can you suggest a better point
> in time for sending such a notification, or additional steps we
> may need to take in order to ensure resource stability?

Hi Jan,

There is currently no mechanism for the PCI core to tell a driver that
we're changing any device resources (IRQ, MMIO, I/O).  Since there's
no way to tell a driver to refresh its idea of device resources, the
core can not change anything after we call a driver's .probe()
method.

This could change in the future if we support dynamic resource
reassignment, but I think that would require adding some sort of
notification infrastructure so we could essentially suspend a driver,
reassign device resources, and tell the driver "things might have
changed" when we resume it.

Bjorn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:09:34 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:09: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 1UB62q-0003WC-N4; Thu, 28 Feb 2013 16:09:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bhelgaas@google.com>) id 1UB62o-0003W6-Vd
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:09:19 +0000
Received: from [193.109.254.147:4712] by server-15.bemta-14.messagelabs.com id
	77/CE-24599-E218F215; Thu, 28 Feb 2013 16:09:18 +0000
X-Env-Sender: bhelgaas@google.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1362067593!9251232!1
X-Originating-IP: [209.85.219.47]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16402 invoked from network); 28 Feb 2013 16:06:34 -0000
Received: from mail-oa0-f47.google.com (HELO mail-oa0-f47.google.com)
	(209.85.219.47)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:06:34 -0000
Received: by mail-oa0-f47.google.com with SMTP id o17so3848435oag.6
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 08:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=+l8Bodj+5cjZsL13hMJr8x4D1F8NLzlZAsxsVpjjig0=;
	b=OH703Egsgng1dOsxFDB3varhQPA6LuCzIjTXKw1VXTuH2Sazq327NiojUNC7SPwcEQ
	7SO1DiPTtazv5ZLVnn9KYptrCTGoudg54U0BlF/GSvxxLebLStjupL7MAQXOCECl88mM
	QG1Vn7TYrQR+pXcUxkQBtHB10GuVWRipGzyqeQ5JpHdyr4D2+Degr38hqX/Gv3OErCbb
	RJpvGs/X2IsWIe9vFXRj9ZSE5cr/ySU4uG2NKfAfjN40UjZfcz9B0/8OB9riuQEr79S/
	HNmiHCy49cLglbV6Nco5pUuLVOWJm3XKp/Ibo0nIM48yTz7S+d9lNY7N8qqK9ax8cBb6
	zPFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:x-gm-message-state;
	bh=+l8Bodj+5cjZsL13hMJr8x4D1F8NLzlZAsxsVpjjig0=;
	b=ACPJ68W0DCstChYhpr+X9nFE/O8H6l08WXOlMt4bKb/Et10LXUiqlqcotv1VjI2+WN
	6LJyWGvpp6dwqQqVcLiTuBf56PVVsObimWsFqv116I1rHUlYkP4sJibU+QeruCpjSBGM
	ld7XcAeXL1qXxUcdEDZAU1u0GmrNpOEOuSg1vnZvHAYc4e2JdLQ8zgRfLW7CKbEB5NVl
	yN8K4mw0XZpx1vKfSG7rg+GujPvesWZVlqn1kwKJSFzWDXux9TvuXNZEW6HEMQ0I0eWw
	9hIM0mHfOWfUCVDIa05mAO69qXF8Jf4YKRYIe/WWVc8G2FObZElpYtYDPmCHGs9F6Jin
	kj9Q==
X-Received: by 10.182.139.37 with SMTP id qv5mr5778117obb.92.1362067592986;
	Thu, 28 Feb 2013 08:06:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.104.104 with HTTP; Thu, 28 Feb 2013 08:06:12 -0800 (PST)
In-Reply-To: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
References: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Thu, 28 Feb 2013 09:06:12 -0700
Message-ID: <CAErSpo6+bHeNkP9rc6NUGweGfLa0CRw6H=Nny9cV-FL2xOGKeA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Gm-Message-State: ALoCoQn1ZKQJ4K3h0d7nfnR4fdMufYcjqxvDOSFEq1Vd9W1BqMwIVRVshCJOBg5LPkjwjh8ruinyUX2KTS4G/aTtR7i3CfqX4WHjjoq1XCQtiuM7ERo3hYfrsxi05jZu8V71IMyLnEZHL3FxIKiAvbjlSi7ihBy2CEliF2E2RQzQClDWPXLye20D3ZQa8fUxQztO08vgpsvj
Cc: linux-pci@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] time periods of no resource re-assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 2:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> Bjorn,
>
> in the context of dealing with the final part of a long known security
> issue on Xen, I'd appreciate if you could help me understand
> under what conditions (or at which times) MMIO resources for PCI
> devices can get re-assigned in Linux. Or really I'm in need to know
> under what conditions there won't be any resource re-assignment
> (i.e. we particularly need the BARs to be stable that cover the
> MSI-X table and the Pending Bit Array).
>
> Right now I'm intending to send the hypervisor a respective
> notification in the context of xen-pciback's probe function, after
> having called pci_enable_device(). Can you confirm that at this
> point, and until the driver lets go of the device again, resources
> won't get re-assigned? Or if not, can you suggest a better point
> in time for sending such a notification, or additional steps we
> may need to take in order to ensure resource stability?

Hi Jan,

There is currently no mechanism for the PCI core to tell a driver that
we're changing any device resources (IRQ, MMIO, I/O).  Since there's
no way to tell a driver to refresh its idea of device resources, the
core can not change anything after we call a driver's .probe()
method.

This could change in the future if we support dynamic resource
reassignment, but I think that would require adding some sort of
notification infrastructure so we could essentially suspend a driver,
reassign device resources, and tell the driver "things might have
changed" when we resume it.

Bjorn

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:11:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB64s-0003gw-7U; Thu, 28 Feb 2013 16:11:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB64q-0003gn-MJ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:11:24 +0000
Received: from [85.158.139.211:41078] by server-6.bemta-5.messagelabs.com id
	4D/90-21466-BA18F215; Thu, 28 Feb 2013 16:11:23 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362067865!18153808!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16642 invoked from network); 28 Feb 2013 16:11:06 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-15.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 16:11:06 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362067865; bh=52IVjllHvSh2M46w1+GGrRheV8M/t1npYSLUNFkCMGA=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=CAeCetnP74rQOGdfm3KfLH6s/Yj07tB9zFzywY
	q0+eYtX6hZzSAcsPGRv4lXXO7uSDMFdS7GwkK9+n1Zz3oWGzRDfuu/6VOlD8aV+QqWv
	UbXiMLoHw7zWKNC2kdkPlq8Zi9DsSuZgA19gfVclrOACxfmNMlIfv5DqkMDAp/QKWY=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id QwDQY0Xd5OW3; Thu, 28 Feb 2013 17:11:05 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	36EC81D9DC9; Thu, 28 Feb 2013 17:11:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362067865; bh=52IVjllHvSh2M46w1+GGrRheV8M/t1npYSLUNFkCMGA=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=CAeCetnP74rQOGdfm3KfLH6s/Yj07tB9zFzywY
	q0+eYtX6hZzSAcsPGRv4lXXO7uSDMFdS7GwkK9+n1Zz3oWGzRDfuu/6VOlD8aV+QqWv
	UbXiMLoHw7zWKNC2kdkPlq8Zi9DsSuZgA19gfVclrOACxfmNMlIfv5DqkMDAp/QKWY=
Received: by liondog.tnic (Postfix, from userid 1000)
	id B5D8D100A74; Thu, 28 Feb 2013 17:10:57 +0100 (CET)
Date: Thu, 28 Feb 2013 17:10:57 +0100
From: Borislav Petkov <bp@alien8.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130228161057.GC9767@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F7D88.4090703@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	samu.kallio@aberdeencloud.com, kraman@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> At the very least we should have an early filter for the **COMMON!**
> case that we are not on a PV platform.

... or, patch it out with the alternatives on baremetal, as Steven
suggested.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:11:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB64s-0003gw-7U; Thu, 28 Feb 2013 16:11:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB64q-0003gn-MJ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:11:24 +0000
Received: from [85.158.139.211:41078] by server-6.bemta-5.messagelabs.com id
	4D/90-21466-BA18F215; Thu, 28 Feb 2013 16:11:23 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-15.tower-206.messagelabs.com!1362067865!18153808!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16642 invoked from network); 28 Feb 2013 16:11:06 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-15.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 16:11:06 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362067865; bh=52IVjllHvSh2M46w1+GGrRheV8M/t1npYSLUNFkCMGA=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=CAeCetnP74rQOGdfm3KfLH6s/Yj07tB9zFzywY
	q0+eYtX6hZzSAcsPGRv4lXXO7uSDMFdS7GwkK9+n1Zz3oWGzRDfuu/6VOlD8aV+QqWv
	UbXiMLoHw7zWKNC2kdkPlq8Zi9DsSuZgA19gfVclrOACxfmNMlIfv5DqkMDAp/QKWY=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id QwDQY0Xd5OW3; Thu, 28 Feb 2013 17:11:05 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	36EC81D9DC9; Thu, 28 Feb 2013 17:11:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362067865; bh=52IVjllHvSh2M46w1+GGrRheV8M/t1npYSLUNFkCMGA=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=CAeCetnP74rQOGdfm3KfLH6s/Yj07tB9zFzywY
	q0+eYtX6hZzSAcsPGRv4lXXO7uSDMFdS7GwkK9+n1Zz3oWGzRDfuu/6VOlD8aV+QqWv
	UbXiMLoHw7zWKNC2kdkPlq8Zi9DsSuZgA19gfVclrOACxfmNMlIfv5DqkMDAp/QKWY=
Received: by liondog.tnic (Postfix, from userid 1000)
	id B5D8D100A74; Thu, 28 Feb 2013 17:10:57 +0100 (CET)
Date: Thu, 28 Feb 2013 17:10:57 +0100
From: Borislav Petkov <bp@alien8.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20130228161057.GC9767@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F7D88.4090703@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	samu.kallio@aberdeencloud.com, kraman@redhat.com, tglx@linutronix.de
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> At the very least we should have an early filter for the **COMMON!**
> case that we are not on a PV platform.

... or, patch it out with the alternatives on baremetal, as Steven
suggested.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:12:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:12: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 1UB66B-0003qh-Mi; Thu, 28 Feb 2013 16:12: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 1UB66A-0003qR-Im
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:12:46 +0000
Received: from [85.158.143.99:65214] by server-1.bemta-4.messagelabs.com id
	41/3F-06203-DF18F215; Thu, 28 Feb 2013 16:12:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1362067964!26977736!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24785 invoked from network); 28 Feb 2013 16:12:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:12:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2039392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:12: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.297.1; Thu, 28 Feb 2013 16:12:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB668-0006fK-1X; Thu, 28 Feb 2013 16:12:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB667-0004yl-TV;
	Thu, 28 Feb 2013 16:12:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.33275.751076.529851@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:12:43 +0000
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20782.15991.578007.837646@mariner.uk.xensource.com>,
	<20130227171722.GB7166@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
	<1361963955.26546.354.camel@zakaz.uk.xensource.com>
	<20130227171722.GB7166@ocelot.phlegethon.org>
	<1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<20782.15991.578007.837646@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb [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 Jackson writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 27 Feb 2013 11:16:47 +0000
> > Subject: [PATCH] build: rename deb target as debball
> > 
> > "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> > target in the comment.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Acked-by: Tim Deegan <tim@xen.org>

Applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:12:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:12: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 1UB66B-0003qh-Mi; Thu, 28 Feb 2013 16:12: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 1UB66A-0003qR-Im
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:12:46 +0000
Received: from [85.158.143.99:65214] by server-1.bemta-4.messagelabs.com id
	41/3F-06203-DF18F215; Thu, 28 Feb 2013 16:12:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1362067964!26977736!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24785 invoked from network); 28 Feb 2013 16:12:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:12:44 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2039392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:12: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.297.1; Thu, 28 Feb 2013 16:12:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB668-0006fK-1X; Thu, 28 Feb 2013 16:12:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB667-0004yl-TV;
	Thu, 28 Feb 2013 16:12:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.33275.751076.529851@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:12:43 +0000
To: Tim Deegan <tim@xen.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20782.15991.578007.837646@mariner.uk.xensource.com>,
	<20130227171722.GB7166@ocelot.phlegethon.org>
References: <alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com>
	<20130226170948.GE93966@ocelot.phlegethon.org>
	<20780.60663.630676.707241@mariner.uk.xensource.com>
	<20130226172009.GF93966@ocelot.phlegethon.org>
	<20780.61241.624841.117585@mariner.uk.xensource.com>
	<20130226172525.GG93966@ocelot.phlegethon.org>
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com>
	<20780.62363.486434.797437@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1302261753390.5360@kaball.uk.xensource.com>
	<1361963955.26546.354.camel@zakaz.uk.xensource.com>
	<20130227171722.GB7166@ocelot.phlegethon.org>
	<1361870886-3485-1-git-send-email-fantonifabio@tiscali.it>
	<20780.57998.10366.750860@mariner.uk.xensource.com>
	<20782.15991.578007.837646@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"fantonifabio@tiscali.it" <fantonifabio@tiscali.it>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb [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 Jackson writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 27 Feb 2013 11:16:47 +0000
> > Subject: [PATCH] build: rename deb target as debball
> > 
> > "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> > target in the comment.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Acked-by: Tim Deegan <tim@xen.org>

Applied.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:13:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB66M-0003ri-37; Thu, 28 Feb 2013 16: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 1UB66L-0003ra-4k
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:12:57 +0000
Received: from [85.158.137.99:20864] by server-15.bemta-3.messagelabs.com id
	20/84-23142-8028F215; Thu, 28 Feb 2013 16:12:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1362067761!13857387!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28534 invoked from network); 28 Feb 2013 16:09:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:09:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2039179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:09: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.297.1; Thu, 28 Feb 2013 16:09:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB62q-0006e7-VP; Thu, 28 Feb 2013 16:09:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB62q-0004wu-Nb;
	Thu, 28 Feb 2013 16:09:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.33072.466463.251749@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:09:20 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361963183.26546.347.camel@zakaz.uk.xensource.com>
References: <E1UAQgp-0004rV-FS@xenbits.xen.org>
	<CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
	<1361963183.26546.347.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>,
	Teck Choon Giam <giamteckchoon@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Xen-changelog] [xen stable-4.2]
 QEMU_UPSTREAM_REVISION update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-changelog] [xen stable-4.2] QEMU_UPSTREAM_REVISION update"):
> On Tue, 2013-02-26 at 20:50 +0000, Teck Choon Giam wrote:
> > Is the above commit id updated in
> > git://xenbits.xen.org/qemu-upstream-4.2-testing.git ?  From
> > http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=summary
> > I can't see any git commit id related to
> > eccc68722696864fc4823f048c7be58d11281b97 or I am wrong about it?
> 
> Commits are made to the staging tree
> http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.2-testing.git;a=summary
> and should be pushed when automated testing has passed. However this
> seems to have not happened here. CCing Ian.

Thanks for the question.  The problem is that the automated test is
failing on the 32-bit Windows XP install.

http://www.chiark.greenend.org.uk/~xensrcts/logs/16224/test-i386-i386-xl-qemuu-winxpsp3/info.html

Looking at the logs shows this:

Feb 22 13:26:56 field-cricket kernel: [   79.320638]
qemu-system-i38[2477]: segfault at b92a6ed8 ip b76e9b3e sp bf8bf810
error 6 in qemu-system-i386[b748a000+2a5000]

CCing Jan (stable trees maintainer) and Stefano (qemu upstream
maintainer).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:13:10 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB66M-0003ri-37; Thu, 28 Feb 2013 16: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 1UB66L-0003ra-4k
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:12:57 +0000
Received: from [85.158.137.99:20864] by server-15.bemta-3.messagelabs.com id
	20/84-23142-8028F215; Thu, 28 Feb 2013 16:12:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1362067761!13857387!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28534 invoked from network); 28 Feb 2013 16:09:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:09:21 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2039179"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:09: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.297.1; Thu, 28 Feb 2013 16:09:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB62q-0006e7-VP; Thu, 28 Feb 2013 16:09:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB62q-0004wu-Nb;
	Thu, 28 Feb 2013 16:09:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.33072.466463.251749@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:09:20 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1361963183.26546.347.camel@zakaz.uk.xensource.com>
References: <E1UAQgp-0004rV-FS@xenbits.xen.org>
	<CAEwRVpNX+pMnjx__WUXir0DSKNmF=LfLwj8rk9P-nM1XD7g=VQ@mail.gmail.com>
	<1361963183.26546.347.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>,
	Teck Choon Giam <giamteckchoon@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Xen-changelog] [xen stable-4.2]
 QEMU_UPSTREAM_REVISION update
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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-changelog] [xen stable-4.2] QEMU_UPSTREAM_REVISION update"):
> On Tue, 2013-02-26 at 20:50 +0000, Teck Choon Giam wrote:
> > Is the above commit id updated in
> > git://xenbits.xen.org/qemu-upstream-4.2-testing.git ?  From
> > http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.2-testing.git;a=summary
> > I can't see any git commit id related to
> > eccc68722696864fc4823f048c7be58d11281b97 or I am wrong about it?
> 
> Commits are made to the staging tree
> http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-4.2-testing.git;a=summary
> and should be pushed when automated testing has passed. However this
> seems to have not happened here. CCing Ian.

Thanks for the question.  The problem is that the automated test is
failing on the 32-bit Windows XP install.

http://www.chiark.greenend.org.uk/~xensrcts/logs/16224/test-i386-i386-xl-qemuu-winxpsp3/info.html

Looking at the logs shows this:

Feb 22 13:26:56 field-cricket kernel: [   79.320638]
qemu-system-i38[2477]: segfault at b92a6ed8 ip b76e9b3e sp bf8bf810
error 6 in qemu-system-i386[b748a000+2a5000]

CCing Jan (stable trees maintainer) and Stefano (qemu upstream
maintainer).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:13:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:13: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 1UB678-0003zD-HY; Thu, 28 Feb 2013 16:13:46 +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 1UB677-0003yq-4H
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:13:45 +0000
Received: from [85.158.139.83:50335] by server-14.bemta-5.messagelabs.com id
	7E/B4-13158-8328F215; Thu, 28 Feb 2013 16:13:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362067986!22287949!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22943 invoked from network); 28 Feb 2013 16:13:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:13:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:12:04 +0000
Message-Id: <512F8FE302000078000C220E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:12:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<512F88B002000078000C21AA@nat28.tlf.novell.com>
	<20130228155541.GJ27704@ocelot.phlegethon.org>
In-Reply-To: <20130228155541.GJ27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 16:55, Tim Deegan <tim@xen.org> wrote:
> At 15:41 +0000 on 28 Feb (1362066080), Jan Beulich wrote:
>> +        testb $3,UREGS_cs(%rsp)
>> +        GET_CURRENT(%rbx)
>> +        jz    restore_all_xen
> 
> GET_CURRENT() contains an addq, which updates ZF.  Swap it with the
> testb?

I'm glad you spotted that - thanks. I moved the GET_CURRENT()
down though instead of up.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:13:55 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:13: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 1UB678-0003zD-HY; Thu, 28 Feb 2013 16:13:46 +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 1UB677-0003yq-4H
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:13:45 +0000
Received: from [85.158.139.83:50335] by server-14.bemta-5.messagelabs.com id
	7E/B4-13158-8328F215; Thu, 28 Feb 2013 16:13:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362067986!22287949!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22943 invoked from network); 28 Feb 2013 16:13:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:13:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:12:04 +0000
Message-Id: <512F8FE302000078000C220E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:12:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <50AE511302000078000AAA14@nat28.tlf.novell.com>
	<50AE46B0.6010807@citrix.com>
	<50AE590502000078000AAA48@nat28.tlf.novell.com>
	<50AE4D2C.1040104@citrix.com>
	<512F384602000078000C1D5B@nat28.tlf.novell.com>
	<20130228130008.GE27704@ocelot.phlegethon.org>
	<512F6C2502000078000C2042@nat28.tlf.novell.com>
	<20130228142503.GH27704@ocelot.phlegethon.org>
	<512F7ADE02000078000C211A@nat28.tlf.novell.com>
	<512F88B002000078000C21AA@nat28.tlf.novell.com>
	<20130228155541.GJ27704@ocelot.phlegethon.org>
In-Reply-To: <20130228155541.GJ27704@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 16:55, Tim Deegan <tim@xen.org> wrote:
> At 15:41 +0000 on 28 Feb (1362066080), Jan Beulich wrote:
>> +        testb $3,UREGS_cs(%rsp)
>> +        GET_CURRENT(%rbx)
>> +        jz    restore_all_xen
> 
> GET_CURRENT() contains an addq, which updates ZF.  Swap it with the
> testb?

I'm glad you spotted that - thanks. I moved the GET_CURRENT()
down though instead of up.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:14:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:14: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 1UB681-00048c-60; Thu, 28 Feb 2013 16:14:41 +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 1UB680-00048J-Lq
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:14:40 +0000
Received: from [85.158.139.211:31879] by server-4.bemta-5.messagelabs.com id
	D9/63-01980-0728F215; Thu, 28 Feb 2013 16:14:40 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-206.messagelabs.com!1362068079!18120602!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDU0ODk=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17598 invoked from network); 28 Feb 2013 16:14:39 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-9.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 16:14:39 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 7B80A14DD2A;
	Thu, 28 Feb 2013 17:14:38 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Thu, 28 Feb 2013 17:14:35 +0100
Message-Id: <1362068075-4389-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3] 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

- Remove version from installed package name for correct update
- Add conffiles to manage main config files on package update
- Add/remove/stop of main services (xencommons, xendomains)
- Added on description that this make a build for testing only.

Changes from v2:
- Improved description.
- Improved add/remove of main service and added the stop.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/misc/mkdeb |   39 +++++++++++++++++++++++++++++++++------
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 2e40747..839179d 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -33,7 +33,7 @@ fi
 # 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
@@ -41,15 +41,42 @@ Maintainer: Unmaintained snapshot
 Section: admin
 Priority: optional
 Installed-Size: $(du -ks deb | cut -f1)
-Description: Xen hypervisor and tools, version $version
- This package contains the Xen hypervisor and associated tools, built
- from a source tree.  It is not a fully packaged and supported Xen, just
- the output of a xen "make dist" wrapped in a .deb to make it easy to
- uninstall.
+Description: Xen upstream testing build snapshot
+ Warning: This is a custom testing build of Xen; it is not an
+ officially supported Debian package. Please not distribute.
+ It is just the output of a xen "make dist" wrapped in a .deb
+ to make it easy to update and 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
+set -e
+update-rc.d xencommons defaults >/dev/null
+update-rc.d xendomains defaults >/dev/null
+EOF
+cat >deb/DEBIAN/prerm <<EOF
+#!/bin/bash
+set -e
+invoke-rc.d xendomains stop || exit $?
+invoke-rc.d xencommons stop || exit $?
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash
+set -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/prerm
+chmod +x deb/DEBIAN/postrm
 dpkg --build deb xen-upstream-$version.deb
 
 # Tidy up after ourselves
-- 
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 Thu Feb 28 16:14:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:14: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 1UB681-00048c-60; Thu, 28 Feb 2013 16:14:41 +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 1UB680-00048J-Lq
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:14:40 +0000
Received: from [85.158.139.211:31879] by server-4.bemta-5.messagelabs.com id
	D9/63-01980-0728F215; Thu, 28 Feb 2013 16:14:40 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-206.messagelabs.com!1362068079!18120602!1
X-Originating-IP: [62.94.10.165]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuOTQuMTAuMTY1ID0+IDU0ODk=\n, ML_RADAR_SPEW_LINKS_14, 
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17598 invoked from network); 28 Feb 2013 16:14:39 -0000
Received: from mp1-smtp-5.eutelia.it (HELO smtp.eutelia.it) (62.94.10.165)
	by server-9.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 16:14:39 -0000
Received: from FantuNB.heliman.local (ip-124-113.sn2.eutelia.it
	[83.211.124.113])
	by smtp.eutelia.it (Eutelia) with ESMTP id 7B80A14DD2A;
	Thu, 28 Feb 2013 17:14:38 +0100 (CET)
From: fantonifabio@tiscali.it
To: xen-devel@lists.xensource.com
Date: Thu, 28 Feb 2013 17:14:35 +0100
Message-Id: <1362068075-4389-1-git-send-email-fantonifabio@tiscali.it>
X-Mailer: git-send-email 1.7.9.5
Cc: Fabio Fantoni <fabio.fantoni@heliman.it>, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v3] 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>
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: Fabio Fantoni <fabio.fantoni@heliman.it>

- Remove version from installed package name for correct update
- Add conffiles to manage main config files on package update
- Add/remove/stop of main services (xencommons, xendomains)
- Added on description that this make a build for testing only.

Changes from v2:
- Improved description.
- Improved add/remove of main service and added the stop.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/misc/mkdeb |   39 +++++++++++++++++++++++++++++++++------
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 2e40747..839179d 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -33,7 +33,7 @@ fi
 # 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
@@ -41,15 +41,42 @@ Maintainer: Unmaintained snapshot
 Section: admin
 Priority: optional
 Installed-Size: $(du -ks deb | cut -f1)
-Description: Xen hypervisor and tools, version $version
- This package contains the Xen hypervisor and associated tools, built
- from a source tree.  It is not a fully packaged and supported Xen, just
- the output of a xen "make dist" wrapped in a .deb to make it easy to
- uninstall.
+Description: Xen upstream testing build snapshot
+ Warning: This is a custom testing build of Xen; it is not an
+ officially supported Debian package. Please not distribute.
+ It is just the output of a xen "make dist" wrapped in a .deb
+ to make it easy to update and 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
+set -e
+update-rc.d xencommons defaults >/dev/null
+update-rc.d xendomains defaults >/dev/null
+EOF
+cat >deb/DEBIAN/prerm <<EOF
+#!/bin/bash
+set -e
+invoke-rc.d xendomains stop || exit $?
+invoke-rc.d xencommons stop || exit $?
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash
+set -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/prerm
+chmod +x deb/DEBIAN/postrm
 dpkg --build deb xen-upstream-$version.deb
 
 # Tidy up after ourselves
-- 
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 Thu Feb 28 16:14:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB68A-0004AT-JB; Thu, 28 Feb 2013 16:14: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 1UB689-0004AH-Mw
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:14:49 +0000
Received: from [85.158.143.99:18557] by server-3.bemta-4.messagelabs.com id
	D8/2B-02186-9728F215; Thu, 28 Feb 2013 16:14:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1362068088!22911923!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16576 invoked from network); 28 Feb 2013 16:14:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:14:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2039487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:14: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.297.1; Thu, 28 Feb 2013 16:14:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB688-0006fz-8J; Thu, 28 Feb 2013 16:14:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB688-00058S-2z;
	Thu, 28 Feb 2013 16:14:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.33399.942626.437795@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:14:47 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <c438c98e13163cdb3106.1361974596@probook.site>
References: <c438c98e13163cdb3106.1361974596@probook.site>
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] tools/xc: update tty detection in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v2] tools/xc: update tty detection in stdiostream_progress"):
> tools/xc: update tty detection in stdiostream_progress
> 
> As suggested by IanJ:
> Check isatty only once to preserve the errno of ->progress users, and to
> reduce the noice in strace output.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-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 Thu Feb 28 16:14:59 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB68A-0004AT-JB; Thu, 28 Feb 2013 16:14: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 1UB689-0004AH-Mw
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:14:49 +0000
Received: from [85.158.143.99:18557] by server-3.bemta-4.messagelabs.com id
	D8/2B-02186-9728F215; Thu, 28 Feb 2013 16:14:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1362068088!22911923!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16576 invoked from network); 28 Feb 2013 16:14:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:14:48 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2039487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:14: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.297.1; Thu, 28 Feb 2013 16:14:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB688-0006fz-8J; Thu, 28 Feb 2013 16:14:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB688-00058S-2z;
	Thu, 28 Feb 2013 16:14:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.33399.942626.437795@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:14:47 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <c438c98e13163cdb3106.1361974596@probook.site>
References: <c438c98e13163cdb3106.1361974596@probook.site>
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] tools/xc: update tty detection in
	stdiostream_progress
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v2] tools/xc: update tty detection in stdiostream_progress"):
> tools/xc: update tty detection in stdiostream_progress
> 
> As suggested by IanJ:
> Check isatty only once to preserve the errno of ->progress users, and to
> reduce the noice in strace output.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-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 Thu Feb 28 16:19:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:19: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 1UB6CK-0004e0-9w; Thu, 28 Feb 2013 16:19:08 +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 1UB6CI-0004do-Fi
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:19:06 +0000
Received: from [85.158.143.99:42637] by server-3.bemta-4.messagelabs.com id
	F6/7F-02186-9738F215; Thu, 28 Feb 2013 16:19:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1362068327!22076281!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19771 invoked from network); 28 Feb 2013 16:18:52 -0000
Received: from unknown (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:18:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:17:45 +0000
Message-Id: <512F913902000078000C222A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:17:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>,"Tim Deegan" <tim@xen.org>
References: <512F88B002000078000C21AA@nat28.tlf.novell.com>
	<CD552FC5.5D0ED%keir@xen.org>
In-Reply-To: <CD552FC5.5D0ED%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 17:01, Keir Fraser <keir@xen.org> wrote:
> On 28/02/2013 15:41, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> ... this must not be done when on the NMI stack (i.e. when the
>>> NMI was raised while in hypervisor context). Checking for this
>>> here would be strait forward, but I was really considering to do
>>> all of this in the assembly exit path, and I was still undecided
>>> whether we shouldn't follow Linux in skipping softirq processing
>>> (and hence scheduling) on the way out from an NMI (I don't
>>> think we'd need to do the same for MCE).
>> 
>> Like this:
>> 
>> x86: skip processing events on the NMI exit path
>> 
>> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
>> possibly unbounded time (until whenever the next IRET gets executed).
> 
> Is this alternative that we might not process events for an unbounded time?
> No, I guess not -- either we would interrupt the notifying IPI and we will
> be IRETing into that IPI's handler, or the notifying IPI is delayed until
> the NMI handler's IRET.
> 
> What about if the NMI handler itself raises an event (eg softirq)? Perhaps
> there are no very essential ones of those?

We do raise PCI_SERR_SOFTIRQ, and the possibly injected NMI
(to Dom0) might get slightly deferred too. The latter seems of
little concern (Dom0 will get the event eventually). For the
former, we might want to explicitly send a self-IPI with
EVENT_CHECK_VECTOR following the raise_softirq()?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:19:16 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:19: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 1UB6CK-0004e0-9w; Thu, 28 Feb 2013 16:19:08 +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 1UB6CI-0004do-Fi
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:19:06 +0000
Received: from [85.158.143.99:42637] by server-3.bemta-4.messagelabs.com id
	F6/7F-02186-9738F215; Thu, 28 Feb 2013 16:19:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1362068327!22076281!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19771 invoked from network); 28 Feb 2013 16:18:52 -0000
Received: from unknown (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:18:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:17:45 +0000
Message-Id: <512F913902000078000C222A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:17:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>,"Tim Deegan" <tim@xen.org>
References: <512F88B002000078000C21AA@nat28.tlf.novell.com>
	<CD552FC5.5D0ED%keir@xen.org>
In-Reply-To: <CD552FC5.5D0ED%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28.02.13 at 17:01, Keir Fraser <keir@xen.org> wrote:
> On 28/02/2013 15:41, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 28.02.13 at 15:42, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> ... this must not be done when on the NMI stack (i.e. when the
>>> NMI was raised while in hypervisor context). Checking for this
>>> here would be strait forward, but I was really considering to do
>>> all of this in the assembly exit path, and I was still undecided
>>> whether we shouldn't follow Linux in skipping softirq processing
>>> (and hence scheduling) on the way out from an NMI (I don't
>>> think we'd need to do the same for MCE).
>> 
>> Like this:
>> 
>> x86: skip processing events on the NMI exit path
>> 
>> Otherwise, we may end up in the scheduler, keeping NMIs masked for a
>> possibly unbounded time (until whenever the next IRET gets executed).
> 
> Is this alternative that we might not process events for an unbounded time?
> No, I guess not -- either we would interrupt the notifying IPI and we will
> be IRETing into that IPI's handler, or the notifying IPI is delayed until
> the NMI handler's IRET.
> 
> What about if the NMI handler itself raises an event (eg softirq)? Perhaps
> there are no very essential ones of those?

We do raise PCI_SERR_SOFTIRQ, and the possibly injected NMI
(to Dom0) might get slightly deferred too. The latter seems of
little concern (Dom0 will get the event eventually). For the
former, we might want to explicitly send a self-IPI with
EVENT_CHECK_VECTOR following the raise_softirq()?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:22:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB6Fk-0004xW-3n; Thu, 28 Feb 2013 16:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB6Fi-0004xP-Ah
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:22:38 +0000
Received: from [85.158.139.83:48734] by server-10.bemta-5.messagelabs.com id
	1C/10-23714-D448F215; Thu, 28 Feb 2013 16:22:37 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1362068555!29531465!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21345 invoked from network); 28 Feb 2013 16:22:35 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-3.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 16:22:35 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362068555; bh=6GpXg4IW076HRUUiALY6YLbN0LF8N5e0kCdvzJA3WIY=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=ssZi41cjsoB5jjKclH1BJpCEG84mpX2nJfGIlT
	G9Yr7GIuZpYphxK2pS+jWByYd+hRs8qKRrNUmLS/+sqXDLR5lYfQ8g+eQjpHqaSjf4Y
	1gsUCcslOrZcegVxKFfSbwfhLVUTrXK8WgG6tzLeS4CU6qowKUXgPGbuzrPsveZlJg=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id Hyqfe4cpFsDq; Thu, 28 Feb 2013 17:22:34 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	A70571D9DC9; Thu, 28 Feb 2013 17:22:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362068554; bh=6GpXg4IW076HRUUiALY6YLbN0LF8N5e0kCdvzJA3WIY=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=CBVQtlb47GHbPElrBSDxQmVAq9Ys54DXbapy+a
	qA7wxE+urWPrG4F5mC1RVxOQTN1l5+gbZ3xSmUubzIdRL/D2DVxfwqT62w92eyG/sCO
	nuZOKoChNodwXpxyu4OgOad6GhbFcLOgCLJ3XXQ/D6+w0uswH5TzdVoqIximcYB6iY=
Received: by liondog.tnic (Postfix, from userid 1000)
	id 1C599100A74; Thu, 28 Feb 2013 17:22:27 +0100 (CET)
Date: Thu, 28 Feb 2013 17:22:27 +0100
From: Borislav Petkov <bp@alien8.de>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228162227.GD9767@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F83C4.6080904@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
	tglx@linutronix.de, samu.kallio@aberdeencloud.com, kraman@redhat.com
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> >>At the very least we should have an early filter for the **COMMON!**
> >>case that we are not on a PV platform.
> >... or, patch it out with the alternatives on baremetal, as Steven
> >suggested.
> >
> I think making a check for paravirt_enabled() is safe enough. I'll
> send a patch shortly.

Why not make it absolutely for free?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:22:50 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 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 1UB6Fk-0004xW-3n; Thu, 28 Feb 2013 16:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB6Fi-0004xP-Ah
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:22:38 +0000
Received: from [85.158.139.83:48734] by server-10.bemta-5.messagelabs.com id
	1C/10-23714-D448F215; Thu, 28 Feb 2013 16:22:37 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1362068555!29531465!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21345 invoked from network); 28 Feb 2013 16:22:35 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-3.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 16:22:35 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362068555; bh=6GpXg4IW076HRUUiALY6YLbN0LF8N5e0kCdvzJA3WIY=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=ssZi41cjsoB5jjKclH1BJpCEG84mpX2nJfGIlT
	G9Yr7GIuZpYphxK2pS+jWByYd+hRs8qKRrNUmLS/+sqXDLR5lYfQ8g+eQjpHqaSjf4Y
	1gsUCcslOrZcegVxKFfSbwfhLVUTrXK8WgG6tzLeS4CU6qowKUXgPGbuzrPsveZlJg=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id Hyqfe4cpFsDq; Thu, 28 Feb 2013 17:22:34 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	A70571D9DC9; Thu, 28 Feb 2013 17:22:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362068554; bh=6GpXg4IW076HRUUiALY6YLbN0LF8N5e0kCdvzJA3WIY=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=CBVQtlb47GHbPElrBSDxQmVAq9Ys54DXbapy+a
	qA7wxE+urWPrG4F5mC1RVxOQTN1l5+gbZ3xSmUubzIdRL/D2DVxfwqT62w92eyG/sCO
	nuZOKoChNodwXpxyu4OgOad6GhbFcLOgCLJ3XXQ/D6+w0uswH5TzdVoqIximcYB6iY=
Received: by liondog.tnic (Postfix, from userid 1000)
	id 1C599100A74; Thu, 28 Feb 2013 17:22:27 +0100 (CET)
Date: Thu, 28 Feb 2013 17:22:27 +0100
From: Borislav Petkov <bp@alien8.de>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228162227.GD9767@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F83C4.6080904@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
	tglx@linutronix.de, samu.kallio@aberdeencloud.com, kraman@redhat.com
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> >>At the very least we should have an early filter for the **COMMON!**
> >>case that we are not on a PV platform.
> >... or, patch it out with the alternatives on baremetal, as Steven
> >suggested.
> >
> I think making a check for paravirt_enabled() is safe enough. I'll
> send a patch shortly.

Why not make it absolutely for free?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:24:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:24: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 1UB6H0-00052e-Jq; Thu, 28 Feb 2013 16:23:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UB6Gz-00052W-QF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:23:58 +0000
Received: from [85.158.139.211:51931] by server-13.bemta-5.messagelabs.com id
	74/91-16871-D948F215; Thu, 28 Feb 2013 16:23:57 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1362068442!18821434!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6113 invoked from network); 28 Feb 2013 16:20:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:20:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SGKKjd026262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 16:20:21 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
	r1SGKJia025793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 16:20:19 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1SGKIWj012263; Thu, 28 Feb 2013 10:20:18 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 08:20:18 -0800
Message-ID: <512F83C4.6080904@oracle.com>
Date: Thu, 28 Feb 2013 11:20:20 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic>
In-Reply-To: <20130228161057.GC9767@pd.tnic>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/28/2013 11:10 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
>> At the very least we should have an early filter for the **COMMON!**
>> case that we are not on a PV platform.
> ... or, patch it out with the alternatives on baremetal, as Steven
> suggested.
>

I think making a check for paravirt_enabled() is safe enough. I'll send 
a patch shortly.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:24:09 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:24: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 1UB6H0-00052e-Jq; Thu, 28 Feb 2013 16:23:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UB6Gz-00052W-QF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:23:58 +0000
Received: from [85.158.139.211:51931] by server-13.bemta-5.messagelabs.com id
	74/91-16871-D948F215; Thu, 28 Feb 2013 16:23:57 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1362068442!18821434!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6113 invoked from network); 28 Feb 2013 16:20:43 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:20:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SGKKjd026262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 16:20:21 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
	r1SGKJia025793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 16:20:19 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	r1SGKIWj012263; Thu, 28 Feb 2013 10:20:18 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 08:20:18 -0800
Message-ID: <512F83C4.6080904@oracle.com>
Date: Thu, 28 Feb 2013 11:20:20 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic>
In-Reply-To: <20130228161057.GC9767@pd.tnic>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/28/2013 11:10 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
>> At the very least we should have an early filter for the **COMMON!**
>> case that we are not on a PV platform.
> ... or, patch it out with the alternatives on baremetal, as Steven
> suggested.
>

I think making a check for paravirt_enabled() is safe enough. I'll send 
a patch shortly.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:25:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB6Ig-0005B2-4M; Thu, 28 Feb 2013 16:25:42 +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 1UB6Ie-0005An-IU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:25:40 +0000
Received: from [193.109.254.147:44019] by server-11.bemta-14.messagelabs.com
	id B4/82-30685-3058F215; Thu, 28 Feb 2013 16:25:39 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1362068737!9253569!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32226 invoked from network); 28 Feb 2013 16:25:38 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 16:25:38 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1SGOHb9023034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 08:24:19 -0800
Message-ID: <512F84AC.503@zytor.com>
Date: Thu, 28 Feb 2013 08:24:12 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic>
In-Reply-To: <20130228162227.GD9767@pd.tnic>
X-Enigmail-Version: 1.5
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/28/2013 08:22 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
>> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
>>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
>>>> At the very least we should have an early filter for the **COMMON!**
>>>> case that we are not on a PV platform.
>>> ... or, patch it out with the alternatives on baremetal, as Steven
>>> suggested.
>>>
>> I think making a check for paravirt_enabled() is safe enough. I'll
>> send a patch shortly.
> 
> Why not make it absolutely for free?

That makes more sense, I think... although of course, there is a cost in
complexity.

	-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 Thu Feb 28 16:25:53 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB6Ig-0005B2-4M; Thu, 28 Feb 2013 16:25:42 +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 1UB6Ie-0005An-IU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:25:40 +0000
Received: from [193.109.254.147:44019] by server-11.bemta-14.messagelabs.com
	id B4/82-30685-3058F215; Thu, 28 Feb 2013 16:25:39 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1362068737!9253569!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32226 invoked from network); 28 Feb 2013 16:25:38 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 16:25:38 -0000
Received: from tazenda.hos.anvin.org
	([IPv6:2601:9:3340:26:e269:95ff:fe35:9f3c]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id r1SGOHb9023034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 08:24:19 -0800
Message-ID: <512F84AC.503@zytor.com>
Date: Thu, 28 Feb 2013 08:24:12 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic>
In-Reply-To: <20130228162227.GD9767@pd.tnic>
X-Enigmail-Version: 1.5
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/28/2013 08:22 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
>> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
>>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
>>>> At the very least we should have an early filter for the **COMMON!**
>>>> case that we are not on a PV platform.
>>> ... or, patch it out with the alternatives on baremetal, as Steven
>>> suggested.
>>>
>> I think making a check for paravirt_enabled() is safe enough. I'll
>> send a patch shortly.
> 
> Why not make it absolutely for free?

That makes more sense, I think... although of course, there is a cost in
complexity.

	-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 Thu Feb 28 16:26:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:26: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 1UB6JN-0005FG-Jo; Thu, 28 Feb 2013 16:26:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Sebastien.FREMAL@umons.ac.be>) id 1UB6E0-0004kA-LG
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:20:52 +0000
Received: from [85.158.143.99:54206] by server-3.bemta-4.messagelabs.com id
	2E/61-02186-4E38F215; Thu, 28 Feb 2013 16:20:52 +0000
X-Env-Sender: Sebastien.FREMAL@umons.ac.be
X-Msg-Ref: server-15.tower-216.messagelabs.com!1362068450!29671053!1
X-Originating-IP: [193.190.208.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12603 invoked from network); 28 Feb 2013 16:20:50 -0000
Received: from mx1.umons.ac.be (HELO TMGM1.umons.ac.be) (193.190.208.47)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Feb 2013 16:20:50 -0000
Received: from EXCHANGEHUB1.umons.ac.be (10.104.2.76) by TMGM1.umons.ac.be
	(10.104.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9;
	Thu, 28 Feb 2013 17:20:44 +0100
Received: from EXCHANGEDB4.umons.ac.be ([fe80::945c:e368:d98c:ffc3]) by
	EXCHANGEHUB1.umons.ac.be ([fe80::4560:2353:66a9:907f%13]) with mapi id
	14.02.0328.009; Thu, 28 Feb 2013 17:20:43 +0100
From: =?iso-8859-1?Q?S=E9bastien_FREMAL_=5B530784=5D?=
	<Sebastien.FREMAL@umons.ac.be>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Mapping granted pages in the user space of a domU
Thread-Index: Ac4U+rNhA2odNNBcQhaaDbwWLNFuigAB6hFgADNIzhU=
Date: Thu, 28 Feb 2013 16:20:42 +0000
Message-ID: <516805340C166044B9B4F7A5953679AF204965AC@EXCHANGEDB4.umons.ac.be>
References: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>,
	<831D55AF5A11D64C9B4B43F59EEBF720A321646114@FTLPMAILBOX02.citrite.net>
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A321646114@FTLPMAILBOX02.citrite.net>
Accept-Language: fr-BE, en-US
Content-Language: fr-BE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.2.63]
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 28 Feb 2013 16:26:24 +0000
Subject: [Xen-devel] RE : Mapping granted pages in the user space of a 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="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'm studying this tool. It doesn't do exactly what I=
 want to do, but it uses mechanisms I want to use. I'm looking how to arran=
ge them so it does what I want.

Best regards,

S. Fremal
________________________________________
De : Ross Philipson [Ross.Philipson@citrix.com]
Date d'envoi : mercredi 27 f=E9vrier 2013 16:54
=C0 : S=E9bastien FREMAL [530784]; xen-devel@lists.xen.org
Objet : RE: Mapping granted pages in the user space of a domU

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of S=E9bastien FREMAL [530784]
> Sent: Wednesday, February 27, 2013 9:57 AM
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Mapping granted pages in the user space of a domU
>
> Hello,
>
> I'm creating a communication channel between an application running in
> the dom0 and applications running in domU's. I mapped several pages of
> the kernel space of the dom0 in its user space (and this part works
> fine) and I granted the access to these pages to a domU. The module
> running in this domU successfuly retrieves these pages and their content
> but I don't find how to map the pages in the user space.
>
> I already tried several possibilities I found on the web :
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The code of the module :
>
> #undef __KERNEL__
> #define __KERNEL__
>
> #undef MODULE
> #define MODULE
>
> #include <xen/grant_table.h>
> #include <xen/page.h>
> #include <asm/xen/hypercall.h>
> #include <linux/gfp.h>
> #include <linux/module.h>
> #include <linux/vmalloc.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/page.h>
> #include <linux/delay.h>
> #include <linux/time.h>
> #include <linux/fs.h>
> #include <linux/cdev.h>
>
> MODULE_LICENSE("GPL");
>
> // internal data
> // length of the two memory areas
> enum{NUM_ALLOC =3D 1};
> enum{PAGES_PER_ALLOC =3D 4};
>
> struct gnttab_map_grant_ref ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct gnttab_unmap_grant_ref unmap_ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct vm_struct * v_start;
>
> static dev_t mmap_dev;
> static struct cdev mmap_cdev;
>
> static int mmap_open(struct inode * inode, struct file *filp);
> static int mmap_release(struct inode * inode, struct file * filp);
> static int mmap_mmap(struct file * filp, struct vm_area_struct *vma);
>
> static struct file_operations mmap_fops =3D {
>         .open =3D mmap_open,
>         .release =3D mmap_release,
>         .mmap =3D mmap_mmap,
>         .owner =3D THIS_MODULE,
> };
>
>
> static int mmap_open(struct inode *inode, struct file * filp){
>         printk(KERN_INFO "MMap_open invoked\n");
>         return 0;
> }
>
> static int mmap_release(struct inode * inode, struct file * filp){
>         printk(KERN_INFO "MMap_release invoked\n");
>         return 0;
> }
>
> struct mmap_info{
>       char * data;
>       int reference;
> };
>
> static int mmap_mmap(struct file * filp, struct vm_area_struct * vma){
>         int ret;
>         size_t length =3D vma->vm_end - vma->vm_start;
>         size_t num_pages =3D length/PAGE_SIZE;
>         size_t i=3D0;;
>
>         printk(KERN_INFO "Length : %lu, pages : %lu \n", length,
> length/PAGE_SIZE);
>
>         if(length > NUM_ALLOC * PAGES_PER_ALLOC * PAGE_SIZE){
>                 printk("Request for a chunk of memory bigger than the
> available memory\n");
>                 return -EIO;
>         }
>
>       for(i=3D0;i<num_pages;++i){
>
>                 //FIRST ATTEMPT
>               if((ret =3D remap_pfn_range(vma,
>                                       vma->vm_start+i*PAGE_SIZE,
>                                       page_to_pfn(vmalloc_to_page(v_start-
> >addr+i*PAGE_SIZE)),
>                                       PAGE_SIZE,
>                                       vma->vm_page_prot))<0){
>                       printk(KERN_INFO "Error in remap_pfn_range");
>                       return ret;
>               }
>
> /*
>                 //SECOND ATTEMPT
>               unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
>               if((ret=3Dm2p_add_override(mfn, virt_to_page(vma-
> >vm_start+i*PAGE_SIZE), NULL))>0){
>                       printk(KERN_INFO "Overriding failed\n");
>                       return ret;
>               }
>
>                 //THIRD ATTEMPT
>               struct mmap_info * info =3D (struct mmap_info *) filp-
> >private_data;
>               unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
>                 if((ret=3Dm2p_add_override(mfn, virt_to_page(info-
> >data+i*PAGE_SIZE), NULL))>0){
>                         printk(KERN_INFO "Overriding failed\n");
>                         return ret;
>                 }
>
>                 //FOURTH ATTEMPT
>                 if((ret =3D remap_vmalloc_range(vma, v_start->addr,
> 0))<0){
>                        printk(KERN_INFO "Error in remap_vmalloc_range");
>                        return ret;
>                 }
> */
>                 printk(KERN_INFO "Page %lu mapped\n", i);
>                 printk(KERN_INFO "Content : %d - %d\n", *((int
> *)ops[i].host_addr), *((int *) v_start->addr));
>
>       }
>
>         printk(KERN_INFO "MMaped\n");
>
>         return 0;
> }
>
> static int __init mapped_init(void){
>         int i, ret;
>
>       printk(KERN_INFO "Using shared memory in Xen \n");
>
>         if((ret =3D alloc_chrdev_region(&mmap_dev,0,1,"mmap"))<0){
>                 printk(KERN_INFO "Could not allocate major number for
> mmap\n");
>                 return ret;
>         }
>
>         cdev_init(&mmap_cdev, &mmap_fops);
>         if((ret=3Dcdev_add(&mmap_cdev, mmap_dev, 1))<0){
>                 printk(KERN_INFO "Could not allocate chrdev for
> mmap\n");
>                 unregister_chrdev_region(mmap_dev, 1);
>               return ret;
>       }
>
>       v_start =3D alloc_vm_area(PAGE_SIZE*NUM_ALLOC*PAGES_PER_ALLOC,NULL);
>
>         if(v_start=3D=3D0){
>                 printk(KERN_INFO "Problem allocating vm area\n");
>                 return -EFAULT;
>         }
>
>         for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
>               ops[i].flags =3D GNTMAP_host_map;
>               ops[i].ref =3D 8+i;
>               ops[i].dom =3D 0;
>               ops[i].host_addr =3D (unsigned long)(((char*) v_start-
> >addr)+i*PAGE_SIZE);
>       }
>
>         if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ops,
> NUM_ALLOC*PAGES_PER_ALLOC)){
>                       printk(KERN_INFO "Hypervisor map grant failed\n");
>                       free_vm_area(v_start);
>                       return -EFAULT;
>               }
>
>
>       for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
>               if(ops[i].status){
>                       printk(KERN_INFO "Hyper map grant failed with status
> %d\n", ops[i].status);
>                       free_vm_area(v_start);
>                       return -EFAULT;
>               }
>
>               unmap_ops[i].host_addr =3D ops[i].host_addr;
>               unmap_ops[i].handle =3D ops[i].handle;
>
>               printk(KERN_INFO "Number : %d\n", *((int
> *)ops[i].host_addr));
>       }
>
>         return 0;
> }
>
> static int  __exit mapped_exit(void){
>       if(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops,
> NUM_ALLOC*PAGES_PER_ALLOC))
>                       printk("Error in unmapping operation\n");
>         free_vm_area(v_start);
>       printk("Mapping module cleaned\n");
>       return 0;
> }
>
> module_init(mapped_init)
> module_exit(mapped_exit)
>
>
> Mapping :
>
> int main(void)
> {
>   int fd;
>   int *vadr;
>
>   unsigned long len =3D getpagesize(), i;
>
>   if ((fd=3Dopen("node", O_RDWR|O_SYNC))<0)
>   {
>       perror("open");
>       exit(-1);
>   }
>
>   vadr =3D mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
>
>   if (vadr =3D=3D MAP_FAILED)
>   {
>           perror("mmap");
>           exit(-1);
>   }
>
>   for(i=3D0;i<len/sizeof(int);i+=3D(getpagesize()/sizeof(int))){
>           printf("%d\n",*(vadr+i));
>           vadr[i]=3Dvadr[i]+1;
>   }
>
>   close(fd);
>   return(0);
>
> }
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The first attempt doesn't indicate any error but I don't get the good
> page (I put the value "3" in the page but the application read the value
> 0).
>
> The second attempt gives an error in the module :
> [   86.071090] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [   86.071093] m2p_add_override: pfn f73ed13ae not mapped
> [   86.071095] Modules linked in: shm13(O) lp parport
> [   86.071101] Pid: 1324, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [   86.071103] Call Trace:
> [   86.071110]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [   86.071113]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [   86.071116]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [   86.071121]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [   86.071126]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [   86.071129]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [   86.071134]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [   86.071137]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [   86.071140]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [   86.071143]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [   86.071148]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [   86.071153]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [   86.071155] ---[ end trace ea7792ae1c43717f ]---
>
> The third attempt gives me the same error in the module :
> [  105.337927] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [  105.337929] m2p_add_override: pfn f78bba24c not mapped
> [  105.337931] Modules linked in: shm13(O) lp parport
> [  105.337937] Pid: 1201, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [  105.337939] Call Trace:
> [  105.337946]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [  105.337949]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [  105.337952]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [  105.337958]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [  105.337962]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [  105.337965]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [  105.337970]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [  105.337973]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [  105.337976]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [  105.337979]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [  105.337984]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [  105.337989]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [  105.337991] ---[ end trace 33b54c96a0c2933b ]---
>
> The fourth attempt results in an error in the function called by the
> module :
> [   96.621242] Error in remap_vmalloc_range
>
> I don't really know what to do to make it works, but I know than such a
> communication channel is possible as people have already done it before.
>
> Does someone know what is my mistake and how to correct it please ?
>
> Best regards,
>
> S=E9bastien Fr=E9mal

It sounds like you are trying to do something like what libvchan already
does. You should take a look at that library - it is in the xen tree
under tools/libvchan

Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:26:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:26: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 1UB6JN-0005FG-Jo; Thu, 28 Feb 2013 16:26:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Sebastien.FREMAL@umons.ac.be>) id 1UB6E0-0004kA-LG
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:20:52 +0000
Received: from [85.158.143.99:54206] by server-3.bemta-4.messagelabs.com id
	2E/61-02186-4E38F215; Thu, 28 Feb 2013 16:20:52 +0000
X-Env-Sender: Sebastien.FREMAL@umons.ac.be
X-Msg-Ref: server-15.tower-216.messagelabs.com!1362068450!29671053!1
X-Originating-IP: [193.190.208.47]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12603 invoked from network); 28 Feb 2013 16:20:50 -0000
Received: from mx1.umons.ac.be (HELO TMGM1.umons.ac.be) (193.190.208.47)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Feb 2013 16:20:50 -0000
Received: from EXCHANGEHUB1.umons.ac.be (10.104.2.76) by TMGM1.umons.ac.be
	(10.104.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9;
	Thu, 28 Feb 2013 17:20:44 +0100
Received: from EXCHANGEDB4.umons.ac.be ([fe80::945c:e368:d98c:ffc3]) by
	EXCHANGEHUB1.umons.ac.be ([fe80::4560:2353:66a9:907f%13]) with mapi id
	14.02.0328.009; Thu, 28 Feb 2013 17:20:43 +0100
From: =?iso-8859-1?Q?S=E9bastien_FREMAL_=5B530784=5D?=
	<Sebastien.FREMAL@umons.ac.be>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: Mapping granted pages in the user space of a domU
Thread-Index: Ac4U+rNhA2odNNBcQhaaDbwWLNFuigAB6hFgADNIzhU=
Date: Thu, 28 Feb 2013 16:20:42 +0000
Message-ID: <516805340C166044B9B4F7A5953679AF204965AC@EXCHANGEDB4.umons.ac.be>
References: <516805340C166044B9B4F7A5953679AF20494543@EXCHANGEDB4.umons.ac.be>,
	<831D55AF5A11D64C9B4B43F59EEBF720A321646114@FTLPMAILBOX02.citrite.net>
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A321646114@FTLPMAILBOX02.citrite.net>
Accept-Language: fr-BE, en-US
Content-Language: fr-BE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.2.63]
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 28 Feb 2013 16:26:24 +0000
Subject: [Xen-devel] RE : Mapping granted pages in the user space of a 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="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'm studying this tool. It doesn't do exactly what I=
 want to do, but it uses mechanisms I want to use. I'm looking how to arran=
ge them so it does what I want.

Best regards,

S. Fremal
________________________________________
De : Ross Philipson [Ross.Philipson@citrix.com]
Date d'envoi : mercredi 27 f=E9vrier 2013 16:54
=C0 : S=E9bastien FREMAL [530784]; xen-devel@lists.xen.org
Objet : RE: Mapping granted pages in the user space of a domU

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of S=E9bastien FREMAL [530784]
> Sent: Wednesday, February 27, 2013 9:57 AM
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Mapping granted pages in the user space of a domU
>
> Hello,
>
> I'm creating a communication channel between an application running in
> the dom0 and applications running in domU's. I mapped several pages of
> the kernel space of the dom0 in its user space (and this part works
> fine) and I granted the access to these pages to a domU. The module
> running in this domU successfuly retrieves these pages and their content
> but I don't find how to map the pages in the user space.
>
> I already tried several possibilities I found on the web :
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The code of the module :
>
> #undef __KERNEL__
> #define __KERNEL__
>
> #undef MODULE
> #define MODULE
>
> #include <xen/grant_table.h>
> #include <xen/page.h>
> #include <asm/xen/hypercall.h>
> #include <linux/gfp.h>
> #include <linux/module.h>
> #include <linux/vmalloc.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/page.h>
> #include <linux/delay.h>
> #include <linux/time.h>
> #include <linux/fs.h>
> #include <linux/cdev.h>
>
> MODULE_LICENSE("GPL");
>
> // internal data
> // length of the two memory areas
> enum{NUM_ALLOC =3D 1};
> enum{PAGES_PER_ALLOC =3D 4};
>
> struct gnttab_map_grant_ref ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct gnttab_unmap_grant_ref unmap_ops[NUM_ALLOC*PAGES_PER_ALLOC];
> struct vm_struct * v_start;
>
> static dev_t mmap_dev;
> static struct cdev mmap_cdev;
>
> static int mmap_open(struct inode * inode, struct file *filp);
> static int mmap_release(struct inode * inode, struct file * filp);
> static int mmap_mmap(struct file * filp, struct vm_area_struct *vma);
>
> static struct file_operations mmap_fops =3D {
>         .open =3D mmap_open,
>         .release =3D mmap_release,
>         .mmap =3D mmap_mmap,
>         .owner =3D THIS_MODULE,
> };
>
>
> static int mmap_open(struct inode *inode, struct file * filp){
>         printk(KERN_INFO "MMap_open invoked\n");
>         return 0;
> }
>
> static int mmap_release(struct inode * inode, struct file * filp){
>         printk(KERN_INFO "MMap_release invoked\n");
>         return 0;
> }
>
> struct mmap_info{
>       char * data;
>       int reference;
> };
>
> static int mmap_mmap(struct file * filp, struct vm_area_struct * vma){
>         int ret;
>         size_t length =3D vma->vm_end - vma->vm_start;
>         size_t num_pages =3D length/PAGE_SIZE;
>         size_t i=3D0;;
>
>         printk(KERN_INFO "Length : %lu, pages : %lu \n", length,
> length/PAGE_SIZE);
>
>         if(length > NUM_ALLOC * PAGES_PER_ALLOC * PAGE_SIZE){
>                 printk("Request for a chunk of memory bigger than the
> available memory\n");
>                 return -EIO;
>         }
>
>       for(i=3D0;i<num_pages;++i){
>
>                 //FIRST ATTEMPT
>               if((ret =3D remap_pfn_range(vma,
>                                       vma->vm_start+i*PAGE_SIZE,
>                                       page_to_pfn(vmalloc_to_page(v_start-
> >addr+i*PAGE_SIZE)),
>                                       PAGE_SIZE,
>                                       vma->vm_page_prot))<0){
>                       printk(KERN_INFO "Error in remap_pfn_range");
>                       return ret;
>               }
>
> /*
>                 //SECOND ATTEMPT
>               unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
>               if((ret=3Dm2p_add_override(mfn, virt_to_page(vma-
> >vm_start+i*PAGE_SIZE), NULL))>0){
>                       printk(KERN_INFO "Overriding failed\n");
>                       return ret;
>               }
>
>                 //THIRD ATTEMPT
>               struct mmap_info * info =3D (struct mmap_info *) filp-
> >private_data;
>               unsigned long mfn =3D PFN_DOWN(ops[i].dev_bus_addr);
>                 if((ret=3Dm2p_add_override(mfn, virt_to_page(info-
> >data+i*PAGE_SIZE), NULL))>0){
>                         printk(KERN_INFO "Overriding failed\n");
>                         return ret;
>                 }
>
>                 //FOURTH ATTEMPT
>                 if((ret =3D remap_vmalloc_range(vma, v_start->addr,
> 0))<0){
>                        printk(KERN_INFO "Error in remap_vmalloc_range");
>                        return ret;
>                 }
> */
>                 printk(KERN_INFO "Page %lu mapped\n", i);
>                 printk(KERN_INFO "Content : %d - %d\n", *((int
> *)ops[i].host_addr), *((int *) v_start->addr));
>
>       }
>
>         printk(KERN_INFO "MMaped\n");
>
>         return 0;
> }
>
> static int __init mapped_init(void){
>         int i, ret;
>
>       printk(KERN_INFO "Using shared memory in Xen \n");
>
>         if((ret =3D alloc_chrdev_region(&mmap_dev,0,1,"mmap"))<0){
>                 printk(KERN_INFO "Could not allocate major number for
> mmap\n");
>                 return ret;
>         }
>
>         cdev_init(&mmap_cdev, &mmap_fops);
>         if((ret=3Dcdev_add(&mmap_cdev, mmap_dev, 1))<0){
>                 printk(KERN_INFO "Could not allocate chrdev for
> mmap\n");
>                 unregister_chrdev_region(mmap_dev, 1);
>               return ret;
>       }
>
>       v_start =3D alloc_vm_area(PAGE_SIZE*NUM_ALLOC*PAGES_PER_ALLOC,NULL);
>
>         if(v_start=3D=3D0){
>                 printk(KERN_INFO "Problem allocating vm area\n");
>                 return -EFAULT;
>         }
>
>         for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
>               ops[i].flags =3D GNTMAP_host_map;
>               ops[i].ref =3D 8+i;
>               ops[i].dom =3D 0;
>               ops[i].host_addr =3D (unsigned long)(((char*) v_start-
> >addr)+i*PAGE_SIZE);
>       }
>
>         if(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ops,
> NUM_ALLOC*PAGES_PER_ALLOC)){
>                       printk(KERN_INFO "Hypervisor map grant failed\n");
>                       free_vm_area(v_start);
>                       return -EFAULT;
>               }
>
>
>       for(i=3D0;i<NUM_ALLOC*PAGES_PER_ALLOC;++i){
>               if(ops[i].status){
>                       printk(KERN_INFO "Hyper map grant failed with status
> %d\n", ops[i].status);
>                       free_vm_area(v_start);
>                       return -EFAULT;
>               }
>
>               unmap_ops[i].host_addr =3D ops[i].host_addr;
>               unmap_ops[i].handle =3D ops[i].handle;
>
>               printk(KERN_INFO "Number : %d\n", *((int
> *)ops[i].host_addr));
>       }
>
>         return 0;
> }
>
> static int  __exit mapped_exit(void){
>       if(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap_ops,
> NUM_ALLOC*PAGES_PER_ALLOC))
>                       printk("Error in unmapping operation\n");
>         free_vm_area(v_start);
>       printk("Mapping module cleaned\n");
>       return 0;
> }
>
> module_init(mapped_init)
> module_exit(mapped_exit)
>
>
> Mapping :
>
> int main(void)
> {
>   int fd;
>   int *vadr;
>
>   unsigned long len =3D getpagesize(), i;
>
>   if ((fd=3Dopen("node", O_RDWR|O_SYNC))<0)
>   {
>       perror("open");
>       exit(-1);
>   }
>
>   vadr =3D mmap(0, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
>
>   if (vadr =3D=3D MAP_FAILED)
>   {
>           perror("mmap");
>           exit(-1);
>   }
>
>   for(i=3D0;i<len/sizeof(int);i+=3D(getpagesize()/sizeof(int))){
>           printf("%d\n",*(vadr+i));
>           vadr[i]=3Dvadr[i]+1;
>   }
>
>   close(fd);
>   return(0);
>
> }
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The first attempt doesn't indicate any error but I don't get the good
> page (I put the value "3" in the page but the application read the value
> 0).
>
> The second attempt gives an error in the module :
> [   86.071090] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [   86.071093] m2p_add_override: pfn f73ed13ae not mapped
> [   86.071095] Modules linked in: shm13(O) lp parport
> [   86.071101] Pid: 1324, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [   86.071103] Call Trace:
> [   86.071110]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [   86.071113]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [   86.071116]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [   86.071121]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [   86.071126]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [   86.071129]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [   86.071134]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [   86.071137]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [   86.071140]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [   86.071143]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [   86.071148]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [   86.071153]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [   86.071155] ---[ end trace ea7792ae1c43717f ]---
>
> The third attempt gives me the same error in the module :
> [  105.337927] WARNING: at /build/buildd/linux-
> 3.2.0/arch/x86/xen/p2m.c:696 m2p_add_override+0x7b/0x3c0()
> [  105.337929] m2p_add_override: pfn f78bba24c not mapped
> [  105.337931] Modules linked in: shm13(O) lp parport
> [  105.337937] Pid: 1201, comm: fill Tainted: G           O 3.2.0-34-
> generic #53-Ubuntu
> [  105.337939] Call Trace:
> [  105.337946]  [<ffffffff81066f0f>] warn_slowpath_common+0x7f/0xc0
> [  105.337949]  [<ffffffff81067006>] warn_slowpath_fmt+0x46/0x50
> [  105.337952]  [<ffffffff8100b62b>] m2p_add_override+0x7b/0x3c0
> [  105.337958]  [<ffffffff8164328c>] ? printk+0x51/0x53
> [  105.337962]  [<ffffffffa0019116>] mmap_mmap+0xd6/0x128 [shm13]
> [  105.337965]  [<ffffffff810064fe>] ? xen_pmd_val+0xe/0x10
> [  105.337970]  [<ffffffff811437e9>] mmap_region+0x369/0x4f0
> [  105.337973]  [<ffffffff8113dde8>] ? handle_mm_fault+0x1f8/0x350
> [  105.337976]  [<ffffffff81143cb8>] do_mmap_pgoff+0x348/0x360
> [  105.337979]  [<ffffffff81143d96>] sys_mmap_pgoff+0xc6/0x230
> [  105.337984]  [<ffffffff81017b12>] sys_mmap+0x22/0x30
> [  105.337989]  [<ffffffff816643c2>] system_call_fastpath+0x16/0x1b
> [  105.337991] ---[ end trace 33b54c96a0c2933b ]---
>
> The fourth attempt results in an error in the function called by the
> module :
> [   96.621242] Error in remap_vmalloc_range
>
> I don't really know what to do to make it works, but I know than such a
> communication channel is possible as people have already done it before.
>
> Does someone know what is my mistake and how to correct it please ?
>
> Best regards,
>
> S=E9bastien Fr=E9mal

It sounds like you are trying to do something like what libvchan already
does. You should take a look at that library - it is in the xen tree
under tools/libvchan

Ross
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:27:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB6Kg-0005QG-BU; Thu, 28 Feb 2013 16:27:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UB6Ke-0005Q5-Vr
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:27:45 +0000
Received: from [193.109.254.147:6252] by server-10.bemta-14.messagelabs.com id
	6D/54-12679-0858F215; Thu, 28 Feb 2013 16:27:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1362068861!1941193!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29702 invoked from network); 28 Feb 2013 16:27:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 16:27:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SGRMXY002885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 16:27:23 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
	r1SGRLZL008449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 16:27:22 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
	r1SGRLTD020565; Thu, 28 Feb 2013 10:27:21 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 08:27:21 -0800
Message-ID: <512F856B.5090801@oracle.com>
Date: Thu, 28 Feb 2013 11:27:23 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic>
In-Reply-To: <20130228162227.GD9767@pd.tnic>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/28/2013 11:22 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
>> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
>>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
>>>> At the very least we should have an early filter for the **COMMON!**
>>>> case that we are not on a PV platform.
>>> ... or, patch it out with the alternatives on baremetal, as Steven
>>> suggested.

What was the suggestion exactly? I don't remember seeing that message.

-boris

>>>
>> I think making a check for paravirt_enabled() is safe enough. I'll
>> send a patch shortly.
> Why not make it absolutely for free?
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:27:54 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB6Kg-0005QG-BU; Thu, 28 Feb 2013 16:27:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UB6Ke-0005Q5-Vr
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:27:45 +0000
Received: from [193.109.254.147:6252] by server-10.bemta-14.messagelabs.com id
	6D/54-12679-0858F215; Thu, 28 Feb 2013 16:27:44 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1362068861!1941193!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU1Mjcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29702 invoked from network); 28 Feb 2013 16:27:42 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 16:27:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SGRMXY002885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 16:27:23 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
	r1SGRLZL008449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 16:27:22 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
	r1SGRLTD020565; Thu, 28 Feb 2013 10:27:21 -0600
Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com
	(/10.152.55.112) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 08:27:21 -0800
Message-ID: <512F856B.5090801@oracle.com>
Date: Thu, 28 Feb 2013 11:27:23 -0500
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default>
	<512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic>
In-Reply-To: <20130228162227.GD9767@pd.tnic>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?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/28/2013 11:22 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
>> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
>>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
>>>> At the very least we should have an early filter for the **COMMON!**
>>>> case that we are not on a PV platform.
>>> ... or, patch it out with the alternatives on baremetal, as Steven
>>> suggested.

What was the suggestion exactly? I don't remember seeing that message.

-boris

>>>
>> I think making a check for paravirt_enabled() is safe enough. I'll
>> send a patch shortly.
> Why not make it absolutely for free?
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:33:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:33: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 1UB6Pb-0005o7-8g; Thu, 28 Feb 2013 16:32:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB6PZ-0005o1-Ui
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:32:50 +0000
Received: from [85.158.143.99:38102] by server-3.bemta-4.messagelabs.com id
	7F/1E-02186-1B68F215; Thu, 28 Feb 2013 16:32:49 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1362069168!20632543!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23822 invoked from network); 28 Feb 2013 16:32:48 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-6.tower-216.messagelabs.com with SMTP;
	28 Feb 2013 16:32:48 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362069167; bh=3I89UXoT1Sumt6taRCFer6pqFHRalHLv0eDJgEHe9kw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=IJ/zGu2p9OmaZCkxvXhs9YEC7gHSVpy8DC6fk9
	rhfY1ay5ZEuvCdM25uXgz2OyeboBxe4rezF7f35rV2/f7NlJlXN2XY+M8m0scysxb1F
	TBDWK9w88DeJz03OE7damZsLhjcM/cmGg+QbLWcEHtvKbSPJ2qZgxzYkj+1f/JpYQM=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 5MfIdD638GYj; Thu, 28 Feb 2013 17:32:47 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	652F51DA229; Thu, 28 Feb 2013 17:32:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362069167; bh=3I89UXoT1Sumt6taRCFer6pqFHRalHLv0eDJgEHe9kw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=IJ/zGu2p9OmaZCkxvXhs9YEC7gHSVpy8DC6fk9
	rhfY1ay5ZEuvCdM25uXgz2OyeboBxe4rezF7f35rV2/f7NlJlXN2XY+M8m0scysxb1F
	TBDWK9w88DeJz03OE7damZsLhjcM/cmGg+QbLWcEHtvKbSPJ2qZgxzYkj+1f/JpYQM=
Received: by liondog.tnic (Postfix, from userid 1000)
	id CB43A100A74; Thu, 28 Feb 2013 17:32:39 +0100 (CET)
Date: Thu, 28 Feb 2013 17:32:39 +0100
From: Borislav Petkov <bp@alien8.de>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228163239.GE9767@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic> <512F856B.5090801@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F856B.5090801@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
	tglx@linutronix.de, samu.kallio@aberdeencloud.com, kraman@redhat.com
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> What was the suggestion exactly? I don't remember seeing that message.

Use the paravirt patching facility to replace arch_flush_lazy_mmu_mode()
with a nop when running on baremetal. I.e., the whole functionality
around apply_paravirt() et al.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:33:25 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:33: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 1UB6Pb-0005o7-8g; Thu, 28 Feb 2013 16:32:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UB6PZ-0005o1-Ui
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:32:50 +0000
Received: from [85.158.143.99:38102] by server-3.bemta-4.messagelabs.com id
	7F/1E-02186-1B68F215; Thu, 28 Feb 2013 16:32:49 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1362069168!20632543!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23822 invoked from network); 28 Feb 2013 16:32:48 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-6.tower-216.messagelabs.com with SMTP;
	28 Feb 2013 16:32:48 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362069167; bh=3I89UXoT1Sumt6taRCFer6pqFHRalHLv0eDJgEHe9kw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=IJ/zGu2p9OmaZCkxvXhs9YEC7gHSVpy8DC6fk9
	rhfY1ay5ZEuvCdM25uXgz2OyeboBxe4rezF7f35rV2/f7NlJlXN2XY+M8m0scysxb1F
	TBDWK9w88DeJz03OE7damZsLhjcM/cmGg+QbLWcEHtvKbSPJ2qZgxzYkj+1f/JpYQM=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 5MfIdD638GYj; Thu, 28 Feb 2013 17:32:47 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	652F51DA229; Thu, 28 Feb 2013 17:32:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362069167; bh=3I89UXoT1Sumt6taRCFer6pqFHRalHLv0eDJgEHe9kw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=IJ/zGu2p9OmaZCkxvXhs9YEC7gHSVpy8DC6fk9
	rhfY1ay5ZEuvCdM25uXgz2OyeboBxe4rezF7f35rV2/f7NlJlXN2XY+M8m0scysxb1F
	TBDWK9w88DeJz03OE7damZsLhjcM/cmGg+QbLWcEHtvKbSPJ2qZgxzYkj+1f/JpYQM=
Received: by liondog.tnic (Postfix, from userid 1000)
	id CB43A100A74; Thu, 28 Feb 2013 17:32:39 +0100 (CET)
Date: Thu, 28 Feb 2013 17:32:39 +0100
From: Borislav Petkov <bp@alien8.de>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228163239.GE9767@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com,
	kraman@redhat.com, jwboyer@redhat.com
References: <512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic> <512F856B.5090801@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F856B.5090801@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
	tglx@linutronix.de, samu.kallio@aberdeencloud.com, kraman@redhat.com
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> What was the suggestion exactly? I don't remember seeing that message.

Use the paravirt patching facility to replace arch_flush_lazy_mmu_mode()
with a nop when running on baremetal. I.e., the whole functionality
around apply_paravirt() et al.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:33:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:33: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 1UB6QD-0005qQ-Oj; Thu, 28 Feb 2013 16:33:29 +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 1UB6QD-0005qJ-3i
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:33:29 +0000
Received: from [85.158.139.83:16168] by server-2.bemta-5.messagelabs.com id
	90/2A-23989-8D68F215; Thu, 28 Feb 2013 16:33:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1362069192!18214249!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15761 invoked from network); 28 Feb 2013 16:33:13 -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; 28 Feb 2013 16:33:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:33:07 +0000
Message-Id: <512F94D202000078000C2284@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:33:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bjorn Helgaas" <bhelgaas@google.com>
References: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
	<CAErSpo6+bHeNkP9rc6NUGweGfLa0CRw6H=Nny9cV-FL2xOGKeA@mail.gmail.com>
In-Reply-To: <CAErSpo6+bHeNkP9rc6NUGweGfLa0CRw6H=Nny9cV-FL2xOGKeA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] time periods of no resource re-assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:06, Bjorn Helgaas <bhelgaas@google.com> wrote:
> There is currently no mechanism for the PCI core to tell a driver that
> we're changing any device resources (IRQ, MMIO, I/O).  Since there's
> no way to tell a driver to refresh its idea of device resources, the
> core can not change anything after we call a driver's .probe()
> method.
> 
> This could change in the future if we support dynamic resource
> reassignment, but I think that would require adding some sort of
> notification infrastructure so we could essentially suspend a driver,
> reassign device resources, and tell the driver "things might have
> changed" when we resume it.

Thanks Bjorn! That should allow us to get things working for now
the way I have coded them up already, and I assume eventual
changes in this area (as you outlined) would imply cooperation by
the driver (i.e. if a device is assigned to a guest, it ought to be
possible to deny the re-assignment attempt if there's no way to
let the guest know of the change).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:33:38 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:33: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 1UB6QD-0005qQ-Oj; Thu, 28 Feb 2013 16:33:29 +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 1UB6QD-0005qJ-3i
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:33:29 +0000
Received: from [85.158.139.83:16168] by server-2.bemta-5.messagelabs.com id
	90/2A-23989-8D68F215; Thu, 28 Feb 2013 16:33:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1362069192!18214249!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15761 invoked from network); 28 Feb 2013 16:33:13 -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; 28 Feb 2013 16:33:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:33:07 +0000
Message-Id: <512F94D202000078000C2284@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:33:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Bjorn Helgaas" <bhelgaas@google.com>
References: <512F2C9E02000078000C1D07@nat28.tlf.novell.com>
	<CAErSpo6+bHeNkP9rc6NUGweGfLa0CRw6H=Nny9cV-FL2xOGKeA@mail.gmail.com>
In-Reply-To: <CAErSpo6+bHeNkP9rc6NUGweGfLa0CRw6H=Nny9cV-FL2xOGKeA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] time periods of no resource re-assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.02.13 at 17:06, Bjorn Helgaas <bhelgaas@google.com> wrote:
> There is currently no mechanism for the PCI core to tell a driver that
> we're changing any device resources (IRQ, MMIO, I/O).  Since there's
> no way to tell a driver to refresh its idea of device resources, the
> core can not change anything after we call a driver's .probe()
> method.
> 
> This could change in the future if we support dynamic resource
> reassignment, but I think that would require adding some sort of
> notification infrastructure so we could essentially suspend a driver,
> reassign device resources, and tell the driver "things might have
> changed" when we resume it.

Thanks Bjorn! That should allow us to get things working for now
the way I have coded them up already, and I assume eventual
changes in this area (as you outlined) would imply cooperation by
the driver (i.e. if a device is assigned to a guest, it ought to be
possible to deny the re-assignment attempt if there's no way to
let the guest know of the change).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:44:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:44: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 1UB6aq-0006NA-It; Thu, 28 Feb 2013 16:44: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 1UB6ap-0006N2-0K
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:44:27 +0000
Received: from [85.158.143.99:18341] by server-2.bemta-4.messagelabs.com id
	88/13-12656-A698F215; Thu, 28 Feb 2013 16:44:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1362069865!22917421!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2843 invoked from network); 28 Feb 2013 16:44:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:44:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:44:24 +0000
Message-Id: <512F977702000078000C22A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:44:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
	<512CEA0F02000078000C1261@nat28.tlf.novell.com>
	<30A36F55D047B4489EC149857F230F426DAF5A19@Quimby.dw.local>
In-Reply-To: <30A36F55D047B4489EC149857F230F426DAF5A19@Quimby.dw.local>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE8D89B77.1__="
Cc: Robert VanVossen <Robert.VanVossen@dornerworks.com>
Subject: [Xen-devel] [PATCH v2] change arguments of do_kexec_op and
 compat_set_timer_op prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartE8D89B77.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... to match the actual functions.

Signed-off-by: Robbie VanVossen <robert.vanvossen@dornerworks.com>

Also make sure the source files defining these symbols include the
header declaring them (had we done so, the problem would have been
noticed long ago).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -15,6 +15,7 @@
 #include <xen/nmi.h>
 #include <xen/sched.h>
 #include <xen/types.h>
+#include <xen/hypercall.h>
 #include <xen/kexec.h>
 #include <xen/keyhandler.h>
 #include <public/kexec.h>
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -30,6 +30,7 @@
 #include <xen/mm.h>
 #include <xen/err.h>
 #include <xen/guest_access.h>
+#include <xen/hypercall.h>
 #include <xen/multicall.h>
 #include <xen/cpu.h>
 #include <xen/preempt.h>
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -126,8 +126,7 @@ do_hvm_op(
 extern long
 do_kexec_op(
     unsigned long op,
-    int arg1,
-    XEN_GUEST_HANDLE_PARAM(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) uarg);
=20
 extern long
 do_xsm_op(
@@ -174,7 +173,8 @@ compat_sched_op(
=20
 extern int
 compat_set_timer_op(
-    s_time_t timeout);
+    u32 lo,
+    s32 hi);
=20
 #endif
=20




--=__PartE8D89B77.1__=
Content-Type: text/plain; name="hypercall-prototypes.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hypercall-prototypes.patch"

change arguments of do_kexec_op and compat_set_timer_op prototypes=0A=0A...=
 to match the actual functions.=0A=0ASigned-off-by: Robbie VanVossen =
<robert.vanvossen@dornerworks.com>=0A=0AAlso make sure the source files =
defining these symbols include the=0Aheader declaring them (had we done =
so, the problem would have been=0Anoticed long ago).=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/kexec.c=0A+++ =
b/xen/common/kexec.c=0A@@ -15,6 +15,7 @@=0A #include <xen/nmi.h>=0A =
#include <xen/sched.h>=0A #include <xen/types.h>=0A+#include <xen/hypercall=
.h>=0A #include <xen/kexec.h>=0A #include <xen/keyhandler.h>=0A #include =
<public/kexec.h>=0A--- a/xen/common/schedule.c=0A+++ b/xen/common/schedule.=
c=0A@@ -30,6 +30,7 @@=0A #include <xen/mm.h>=0A #include <xen/err.h>=0A =
#include <xen/guest_access.h>=0A+#include <xen/hypercall.h>=0A #include =
<xen/multicall.h>=0A #include <xen/cpu.h>=0A #include <xen/preempt.h>=0A---=
 a/xen/include/xen/hypercall.h=0A+++ b/xen/include/xen/hypercall.h=0A@@ =
-126,8 +126,7 @@ do_hvm_op(=0A extern long=0A do_kexec_op(=0A     unsigned =
long op,=0A-    int arg1,=0A-    XEN_GUEST_HANDLE_PARAM(void) arg);=0A+    =
XEN_GUEST_HANDLE_PARAM(void) uarg);=0A =0A extern long=0A do_xsm_op(=0A@@ =
-174,7 +173,8 @@ compat_sched_op(=0A =0A extern int=0A compat_set_timer_op(=
=0A-    s_time_t timeout);=0A+    u32 lo,=0A+    s32 hi);=0A =0A #endif=0A =
=0A
--=__PartE8D89B77.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

--=__PartE8D89B77.1__=--


From xen-devel-bounces@lists.xen.org Thu Feb 28 16:44:40 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:44: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 1UB6aq-0006NA-It; Thu, 28 Feb 2013 16:44: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 1UB6ap-0006N2-0K
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 16:44:27 +0000
Received: from [85.158.143.99:18341] by server-2.bemta-4.messagelabs.com id
	88/13-12656-A698F215; Thu, 28 Feb 2013 16:44:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1362069865!22917421!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDUxNTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2843 invoked from network); 28 Feb 2013 16:44:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Feb 2013 16:44:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 28 Feb 2013 16:44:24 +0000
Message-Id: <512F977702000078000C22A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 28 Feb 2013 16:44:23 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <30A36F55D047B4489EC149857F230F426DAF57CB@Quimby.dw.local>
	<512CEA0F02000078000C1261@nat28.tlf.novell.com>
	<30A36F55D047B4489EC149857F230F426DAF5A19@Quimby.dw.local>
In-Reply-To: <30A36F55D047B4489EC149857F230F426DAF5A19@Quimby.dw.local>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE8D89B77.1__="
Cc: Robert VanVossen <Robert.VanVossen@dornerworks.com>
Subject: [Xen-devel] [PATCH v2] change arguments of do_kexec_op and
 compat_set_timer_op prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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.

--=__PartE8D89B77.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... to match the actual functions.

Signed-off-by: Robbie VanVossen <robert.vanvossen@dornerworks.com>

Also make sure the source files defining these symbols include the
header declaring them (had we done so, the problem would have been
noticed long ago).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -15,6 +15,7 @@
 #include <xen/nmi.h>
 #include <xen/sched.h>
 #include <xen/types.h>
+#include <xen/hypercall.h>
 #include <xen/kexec.h>
 #include <xen/keyhandler.h>
 #include <public/kexec.h>
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -30,6 +30,7 @@
 #include <xen/mm.h>
 #include <xen/err.h>
 #include <xen/guest_access.h>
+#include <xen/hypercall.h>
 #include <xen/multicall.h>
 #include <xen/cpu.h>
 #include <xen/preempt.h>
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -126,8 +126,7 @@ do_hvm_op(
 extern long
 do_kexec_op(
     unsigned long op,
-    int arg1,
-    XEN_GUEST_HANDLE_PARAM(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) uarg);
=20
 extern long
 do_xsm_op(
@@ -174,7 +173,8 @@ compat_sched_op(
=20
 extern int
 compat_set_timer_op(
-    s_time_t timeout);
+    u32 lo,
+    s32 hi);
=20
 #endif
=20




--=__PartE8D89B77.1__=
Content-Type: text/plain; name="hypercall-prototypes.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hypercall-prototypes.patch"

change arguments of do_kexec_op and compat_set_timer_op prototypes=0A=0A...=
 to match the actual functions.=0A=0ASigned-off-by: Robbie VanVossen =
<robert.vanvossen@dornerworks.com>=0A=0AAlso make sure the source files =
defining these symbols include the=0Aheader declaring them (had we done =
so, the problem would have been=0Anoticed long ago).=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/kexec.c=0A+++ =
b/xen/common/kexec.c=0A@@ -15,6 +15,7 @@=0A #include <xen/nmi.h>=0A =
#include <xen/sched.h>=0A #include <xen/types.h>=0A+#include <xen/hypercall=
.h>=0A #include <xen/kexec.h>=0A #include <xen/keyhandler.h>=0A #include =
<public/kexec.h>=0A--- a/xen/common/schedule.c=0A+++ b/xen/common/schedule.=
c=0A@@ -30,6 +30,7 @@=0A #include <xen/mm.h>=0A #include <xen/err.h>=0A =
#include <xen/guest_access.h>=0A+#include <xen/hypercall.h>=0A #include =
<xen/multicall.h>=0A #include <xen/cpu.h>=0A #include <xen/preempt.h>=0A---=
 a/xen/include/xen/hypercall.h=0A+++ b/xen/include/xen/hypercall.h=0A@@ =
-126,8 +126,7 @@ do_hvm_op(=0A extern long=0A do_kexec_op(=0A     unsigned =
long op,=0A-    int arg1,=0A-    XEN_GUEST_HANDLE_PARAM(void) arg);=0A+    =
XEN_GUEST_HANDLE_PARAM(void) uarg);=0A =0A extern long=0A do_xsm_op(=0A@@ =
-174,7 +173,8 @@ compat_sched_op(=0A =0A extern int=0A compat_set_timer_op(=
=0A-    s_time_t timeout);=0A+    u32 lo,=0A+    s32 hi);=0A =0A #endif=0A =
=0A
--=__PartE8D89B77.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

--=__PartE8D89B77.1__=--


From xen-devel-bounces@lists.xen.org Thu Feb 28 16:45:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB6bs-0006TG-25; Thu, 28 Feb 2013 16:45:32 +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 1UB6bq-0006T5-Kw
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:45:30 +0000
Received: from [193.109.254.147:19137] by server-15.bemta-14.messagelabs.com
	id 1B/42-24599-9A98F215; Thu, 28 Feb 2013 16:45:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1362069929!9923931!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14909 invoked from network); 28 Feb 2013 16:45:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:45:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2040736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16: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.297.1; Thu, 28 Feb 2013 16:45:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB6bo-0006pI-NG; Thu, 28 Feb 2013 16:45:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB6bo-0005Ax-Hs;
	Thu, 28 Feb 2013 16:45:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.35240.386442.892962@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:45:28 +0000
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1362068075-4389-1-git-send-email-fantonifabio@tiscali.it>
References: <1362068075-4389-1-git-send-email-fantonifabio@tiscali.it>
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>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] 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

fantonifabio@tiscali.it writes ("[PATCH v3] tools: Improve make deb"):
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> - Remove version from installed package name for correct update
> - Add conffiles to manage main config files on package update
> - Add/remove/stop of main services (xencommons, xendomains)
> - Added on description that this make a build for testing only.
> 
> Changes from v2:
> - Improved description.
> - Improved add/remove of main service and added the stop.

Um,

Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>

We're still discussing this, but I think we have rough agreement that
this isn't the right way forward.  We certainly don't want our debball
target to start and stop daemons.

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 Feb 28 16:45:44 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16: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 1UB6bs-0006TG-25; Thu, 28 Feb 2013 16:45:32 +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 1UB6bq-0006T5-Kw
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:45:30 +0000
Received: from [193.109.254.147:19137] by server-15.bemta-14.messagelabs.com
	id 1B/42-24599-9A98F215; Thu, 28 Feb 2013 16:45:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1362069929!9923931!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14909 invoked from network); 28 Feb 2013 16:45:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:45:29 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2040736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16: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.297.1; Thu, 28 Feb 2013 16:45:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1UB6bo-0006pI-NG; Thu, 28 Feb 2013 16:45:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1UB6bo-0005Ax-Hs;
	Thu, 28 Feb 2013 16:45:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20783.35240.386442.892962@mariner.uk.xensource.com>
Date: Thu, 28 Feb 2013 16:45:28 +0000
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
In-Reply-To: <1362068075-4389-1-git-send-email-fantonifabio@tiscali.it>
References: <1362068075-4389-1-git-send-email-fantonifabio@tiscali.it>
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>,
	Fabio Fantoni <fabio.fantoni@heliman.it>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] 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

fantonifabio@tiscali.it writes ("[PATCH v3] tools: Improve make deb"):
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> - Remove version from installed package name for correct update
> - Add conffiles to manage main config files on package update
> - Add/remove/stop of main services (xencommons, xendomains)
> - Added on description that this make a build for testing only.
> 
> Changes from v2:
> - Improved description.
> - Improved add/remove of main service and added the stop.

Um,

Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>

We're still discussing this, but I think we have rough agreement that
this isn't the right way forward.  We certainly don't want our debball
target to start and stop daemons.

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 Feb 28 16:55:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:55: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 1UB6lW-00074D-8P; Thu, 28 Feb 2013 16:55: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 1UB6lV-000743-9Z
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:55:29 +0000
Received: from [85.158.138.51:61091] by server-4.bemta-3.messagelabs.com id
	74/95-21470-00C8F215; Thu, 28 Feb 2013 16:55:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1362070525!27941464!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25552 invoked from network); 28 Feb 2013 16:55:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:55:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2041039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:55: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.297.1; Thu, 28 Feb 2013 16:55:25 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UB6lR-0006sc-Bf;
	Thu, 28 Feb 2013 16:55:25 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UB6lQ-0002VN-R4;
	Thu, 28 Feb 2013 16:55:25 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16772-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 16:55:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16772: 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 16772 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16772/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16767
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16762
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16767

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-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-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
baseline version:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e

------------------------------------------------------------
People who touched revisions under test:
  Liu Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
+ branch=xen-unstable
+ revision=ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc:master
Counting objects: 1   
Counting objects: 9   
Counting objects: 11, done.
Compressing objects:  20% (1/5)   
Compressing objects:  40% (2/5)   
Compressing objects:  60% (3/5)   
Compressing objects:  80% (4/5)   
Compressing objects: 100% (5/5)   
Compressing objects: 100% (5/5), done.
Writing objects:  16% (1/6)   
Writing objects:  33% (2/6)   
Writing objects:  50% (3/6)   
Writing objects:  66% (4/6)   
Writing objects:  83% (5/6)   
Writing objects: 100% (6/6)   
Writing objects: 100% (6/6), 526 bytes, done.
Total 6 (delta 5), reused 2 (delta 1)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6c7bb5a..ba9ef87  ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 16:55:45 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 16:55: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 1UB6lW-00074D-8P; Thu, 28 Feb 2013 16:55: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 1UB6lV-000743-9Z
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 16:55:29 +0000
Received: from [85.158.138.51:61091] by server-4.bemta-3.messagelabs.com id
	74/95-21470-00C8F215; Thu, 28 Feb 2013 16:55:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1362070525!27941464!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25552 invoked from network); 28 Feb 2013 16:55:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 16:55:26 -0000
X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; 
   d="scan'208";a="2041039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 16:55: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.297.1; Thu, 28 Feb 2013 16:55:25 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UB6lR-0006sc-Bf;
	Thu, 28 Feb 2013 16:55:25 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UB6lQ-0002VN-R4;
	Thu, 28 Feb 2013 16:55:25 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16772-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 16:55:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 16772: 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 16772 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16772/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 16767
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 16762
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 16767

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemut-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-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
baseline version:
 xen                  6c7bb5a198de5cfd3f720e2376c7aa184d61329e

------------------------------------------------------------
People who touched revisions under test:
  Liu Jinsong <jinsong.liu@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  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-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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=ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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 ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
+ branch=xen-unstable
+ revision=ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readglobalconfig();
                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
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : 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
++ : osstest@xenbits.xensource.com:/home/xen/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
++ : 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=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc:master
Counting objects: 1   
Counting objects: 9   
Counting objects: 11, done.
Compressing objects:  20% (1/5)   
Compressing objects:  40% (2/5)   
Compressing objects:  60% (3/5)   
Compressing objects:  80% (4/5)   
Compressing objects: 100% (5/5)   
Compressing objects: 100% (5/5), done.
Writing objects:  16% (1/6)   
Writing objects:  33% (2/6)   
Writing objects:  50% (3/6)   
Writing objects:  66% (4/6)   
Writing objects:  83% (5/6)   
Writing objects: 100% (6/6)   
Writing objects: 100% (6/6), 526 bytes, done.
Total 6 (delta 5), reused 2 (delta 1)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
   6c7bb5a..ba9ef87  ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 18:14:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 18: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 1UB7zm-0008Rs-QH; Thu, 28 Feb 2013 18:14:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rostedt@home.goodmis.org>) id 1UB7zk-0008Rn-W8
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 18:14:17 +0000
Received: from [85.158.137.99:18365] by server-7.bemta-3.messagelabs.com id
	0A/82-06591-77E9F215; Thu, 28 Feb 2013 18:14:15 +0000
X-Env-Sender: rostedt@home.goodmis.org
X-Msg-Ref: server-12.tower-217.messagelabs.com!1362075253!15215588!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gNDE5OTM2\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gNDE5OTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11678 invoked from network); 28 Feb 2013 18:14:14 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-12.tower-217.messagelabs.com with SMTP;
	28 Feb 2013 18:14:14 -0000
X-Authority-Analysis: v=2.0 cv=UN5f7Vjy c=1 sm=0 a=rXTBtCOcEpjy1lPqhTCpEQ==:17
	a=mNMOxpOpBa8A:10 a=wom5GMh1gUkA:10 a=QjT1mVhjSf4A:10
	a=5SG0PmZfjMsA:10 a=kj9zAlcOel0A:10 a=meVymXHHAAAA:8
	a=ev9wIl1RTScA:10 a=zbbTrqVcxftZtKoRw0QA:9 a=CjuIK1q_8ugA:10
	a=rXTBtCOcEpjy1lPqhTCpEQ==:117
X-Cloudmark-Score: 0
X-Authenticated-User: 
X-Originating-IP: 74.67.115.198
Received: from [74.67.115.198] ([74.67.115.198:53698] helo=goliath)
	by hrndva-oedge04.mail.rr.com (envelope-from
	<rostedt@home.goodmis.org>) (ecelerity 2.2.3.46 r()) with ESMTP
	id 10/4C-20480-47E9F215; Thu, 28 Feb 2013 18:14:13 +0000
Received: by goliath (Postfix, from userid 5657)
	id D242D3E179; Thu, 28 Feb 2013 13:14:11 -0500 (EST)
Date: Thu, 28 Feb 2013 13:14:11 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228181411.GD9161@home.goodmis.org>
References: <512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic> <512F856B.5090801@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F856B.5090801@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>, tglx@linutronix.de,
	samu.kallio@aberdeencloud.com, kraman@redhat.com
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:22 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> >>On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >>>On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> >>>>At the very least we should have an early filter for the **COMMON!**
> >>>>case that we are not on a PV platform.
> >>>... or, patch it out with the alternatives on baremetal, as Steven
> >>>suggested.
> 
> What was the suggestion exactly? I don't remember seeing that message.

Yeah, Borislav talked to me privately on IRC about this and I pointed
him to the apply_paravirt() function in arch/x86/kernel/alternative.c
where things that apply only to paravirt get patched out on baremetal.

It may add complexity, but there's a method for doing it and I rather
not burden baremetal for pravirt nonsense. I know adding a simple call
to preempt_count() can show a noticable impact to function tracing. It
requires referencing the gs segment register and doing some offset
games (as it's stored as a per cpu pointer) to find the stack.

I was actually a bit amazed that it had as big of an impact as it did. I
can understand why Christoph Lameter tried hard not to add a
preempt_disable() in his code for just a tiny location.

-- Steve

> 
> -boris
> 
> >>>
> >>I think making a check for paravirt_enabled() is safe enough. I'll
> >>send a patch shortly.
> >Why not make it absolutely for free?
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 18:14:42 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 18: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 1UB7zm-0008Rs-QH; Thu, 28 Feb 2013 18:14:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rostedt@home.goodmis.org>) id 1UB7zk-0008Rn-W8
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 18:14:17 +0000
Received: from [85.158.137.99:18365] by server-7.bemta-3.messagelabs.com id
	0A/82-06591-77E9F215; Thu, 28 Feb 2013 18:14:15 +0000
X-Env-Sender: rostedt@home.goodmis.org
X-Msg-Ref: server-12.tower-217.messagelabs.com!1362075253!15215588!1
X-Originating-IP: [71.74.56.122]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gNDE5OTM2\n,sa_preprocessor: 
	QmFkIElQOiA3MS43NC41Ni4xMjIgPT4gNDE5OTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11678 invoked from network); 28 Feb 2013 18:14:14 -0000
Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com)
	(71.74.56.122) by server-12.tower-217.messagelabs.com with SMTP;
	28 Feb 2013 18:14:14 -0000
X-Authority-Analysis: v=2.0 cv=UN5f7Vjy c=1 sm=0 a=rXTBtCOcEpjy1lPqhTCpEQ==:17
	a=mNMOxpOpBa8A:10 a=wom5GMh1gUkA:10 a=QjT1mVhjSf4A:10
	a=5SG0PmZfjMsA:10 a=kj9zAlcOel0A:10 a=meVymXHHAAAA:8
	a=ev9wIl1RTScA:10 a=zbbTrqVcxftZtKoRw0QA:9 a=CjuIK1q_8ugA:10
	a=rXTBtCOcEpjy1lPqhTCpEQ==:117
X-Cloudmark-Score: 0
X-Authenticated-User: 
X-Originating-IP: 74.67.115.198
Received: from [74.67.115.198] ([74.67.115.198:53698] helo=goliath)
	by hrndva-oedge04.mail.rr.com (envelope-from
	<rostedt@home.goodmis.org>) (ecelerity 2.2.3.46 r()) with ESMTP
	id 10/4C-20480-47E9F215; Thu, 28 Feb 2013 18:14:13 +0000
Received: by goliath (Postfix, from userid 5657)
	id D242D3E179; Thu, 28 Feb 2013 13:14:11 -0500 (EST)
Date: Thu, 28 Feb 2013 13:14:11 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228181411.GD9161@home.goodmis.org>
References: <512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com>
	<512E91B7.6060102@zytor.com>
	<20130228142910.GA32354@phenom.dumpdata.com>
	<20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com>
	<20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com>
	<20130228162227.GD9767@pd.tnic> <512F856B.5090801@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <512F856B.5090801@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg KH <gregkh@linuxfoundation.org>, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org,
	mingo@redhat.com, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>, tglx@linutronix.de,
	samu.kallio@aberdeencloud.com, kraman@redhat.com
Subject: Re: [Xen-devel] Is: x86: mm: Fix vmalloc_fault oops during lazy MMU
 updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:22 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> >>On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >>>On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> >>>>At the very least we should have an early filter for the **COMMON!**
> >>>>case that we are not on a PV platform.
> >>>... or, patch it out with the alternatives on baremetal, as Steven
> >>>suggested.
> 
> What was the suggestion exactly? I don't remember seeing that message.

Yeah, Borislav talked to me privately on IRC about this and I pointed
him to the apply_paravirt() function in arch/x86/kernel/alternative.c
where things that apply only to paravirt get patched out on baremetal.

It may add complexity, but there's a method for doing it and I rather
not burden baremetal for pravirt nonsense. I know adding a simple call
to preempt_count() can show a noticable impact to function tracing. It
requires referencing the gs segment register and doing some offset
games (as it's stored as a per cpu pointer) to find the stack.

I was actually a bit amazed that it had as big of an impact as it did. I
can understand why Christoph Lameter tried hard not to add a
preempt_disable() in his code for just a tiny location.

-- Steve

> 
> -boris
> 
> >>>
> >>I think making a check for paravirt_enabled() is safe enough. I'll
> >>send a patch shortly.
> >Why not make it absolutely for free?
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 18:32:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 18:32: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 1UB8H2-0000T5-ID; Thu, 28 Feb 2013 18:32:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UB8H1-0000Sx-4a
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 18:32:07 +0000
Received: from [85.158.139.211:59069] by server-12.bemta-5.messagelabs.com id
	03/CA-11486-6A2AF215; Thu, 28 Feb 2013 18:32:06 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-206.messagelabs.com!1362076325!18840128!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15240 invoked from network); 28 Feb 2013 18:32:05 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 18:32:05 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 22D8C32A6001;
	Thu, 28 Feb 2013 18:31:49 +0000 (GMT)
Date: Thu, 28 Feb 2013 18:31:48 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <769F832A22DA438461237466@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302281237470.5360@kaball.uk.xensource.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
	<3018F0D4E05C1D04A1B3A166@nimrod.local>
	<512F324202000078000C1D37@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1302281237470.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 28 February 2013 12:40:52 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I
> agree that we should disable O_DIRECT, once you have proven that the
> barriers and flushes are handled correctly (henceforth we wouldn't
> cause data corruptions).

Indeed. That's what I meant by I owe you a blktrace.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 18:32:33 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 18:32: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 1UB8H2-0000T5-ID; Thu, 28 Feb 2013 18:32:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UB8H1-0000Sx-4a
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 18:32:07 +0000
Received: from [85.158.139.211:59069] by server-12.bemta-5.messagelabs.com id
	03/CA-11486-6A2AF215; Thu, 28 Feb 2013 18:32:06 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-10.tower-206.messagelabs.com!1362076325!18840128!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15240 invoked from network); 28 Feb 2013 18:32:05 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-10.tower-206.messagelabs.com with SMTP;
	28 Feb 2013 18:32:05 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id 22D8C32A6001;
	Thu, 28 Feb 2013 18:31:49 +0000 (GMT)
Date: Thu, 28 Feb 2013 18:31:48 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <769F832A22DA438461237466@Ximines.local>
In-Reply-To: <alpine.DEB.2.02.1302281237470.5360@kaball.uk.xensource.com>
References: <512E3E9902000078000C19F7@nat28.tlf.novell.com>
	<6C6293A03011B5A6516EBD48@Ximines.local>
	<512F15E402000078000C1C87@nat28.tlf.novell.com>
	<3018F0D4E05C1D04A1B3A166@nimrod.local>
	<512F324202000078000C1D37@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1302281237470.5360@kaball.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Alex Bligh <alex@alex.org.uk>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] preparing for 4.2.2 and 4.1.5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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

Stefano,

--On 28 February 2013 12:40:52 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I
> agree that we should disable O_DIRECT, once you have proven that the
> barriers and flushes are handled correctly (henceforth we wouldn't
> cause data corruptions).

Indeed. That's what I meant by I owe you a blktrace.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 18:33:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 18: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 1UB8IJ-0000Ve-2S; Thu, 28 Feb 2013 18:33:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UB8IH-0000VX-Q5
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 18:33:26 +0000
Received: from [85.158.139.83:4843] by server-9.bemta-5.messagelabs.com id
	1F/82-08547-5F2AF215; Thu, 28 Feb 2013 18:33:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362076404!22310510!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9905 invoked from network); 28 Feb 2013 18:33:24 -0000
Received: from unknown (HELO mail.avalus.com) (89.16.176.221)
	by server-11.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 18:33:24 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id A5392C56194;
	Thu, 28 Feb 2013 18:31:13 +0000 (GMT)
Date: Thu, 28 Feb 2013 18:31:12 +0000
From: Alex Bligh <alex@alex.org.uk>
To: George Dunlap <george.dunlap@eu.citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>
Message-ID: <62360CE09BBA23E5567FCC64@Ximines.local>
In-Reply-To: <512F36BA.4070101@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it> 
	<20780.57998.10366.750860@mariner.uk.xensource.com> 
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com> 
	<20130226170948.GE93966@ocelot.phlegethon.org> 
	<20780.60663.630676.707241@mariner.uk.xensource.com> 
	<20130226172009.GF93966@ocelot.phlegethon.org> 
	<20780.61241.624841.117585@mariner.uk.xensource.com> 
	<20130226172525.GG93966@ocelot.phlegethon.org> 
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com> 
	<1361900393.26546.319.camel@zakaz.uk.xensource.com> 
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com> 
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com> 
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com> <512F36BA.4070101@eu.citrix.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	fantonifabio@tiscali.it, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 28 February 2013 10:51:38 +0000 George Dunlap 
<george.dunlap@eu.citrix.com> wrote:

> Alex, what do you think about Ian's suggestion -- i.e., rather than
> integrate a full-featured .deb package into the Xen build system,
> intermittently use the Debian Xen target to create a set of .debs and
> make them available publicly somewhere?  If this was done once only for
> every new release, and then maybe once for each RC (or every other RC)
> before a release, it shouldn't be too much work I don't think.  I think
> we should probably be able to make space on the xen.org website somewhere
> to keep them.

Well, that wouldn't do me any harm or any good. What I want to do is
produce a .deb of the code I have fiddled with.

I think there are at least 3 use cases here:

1. Providing some sort of debian packaging allowing the unstable build
   to be used and installed in a normal way, to encourage testing of
   unstable. This needs init scripts etc. in it, but typically the
   user isn't making his own changes. This should be debuild thing
   with a debian directory (in my opinion), and might not want to be
   upstream in a conventional way.

2. Providing a .deb for the developer, with a bit more functionality
   than the .tgz (e.g. not stomping on configuration files), and
   arguably some init files, but essentially to let the developer
   install his own stuff. A make target is better here, partly because
   make from clean (which is what debuild does) takes ages.

3. Providing a minimalist install (e.g. without header files) of a
   development build - i.e. a small 'package' to take over to another
   machine to install for the purposes of testing - that's what
   my minideb target did. Again a make target is better here.


Task (1) is essentially making the debian or ubuntu packaging easily
available in unstable. I don't know the politically correct way to
do that. It could also be build periodically and made available
somewhere but that would be hard without taking at least an element
of the packaging upstream somewhere (else how it be built).

Task (2) could be done by fixing up the deb target a small amount.

Task (3) is what my minideb target did (see 'Xen 4.2 debian packaging'
thread), and I'm guessing is too arcane for most people, and I'm only
too happy to maintain it on a private branch.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 18:33:48 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 18: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 1UB8IJ-0000Ve-2S; Thu, 28 Feb 2013 18:33:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1UB8IH-0000VX-Q5
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 18:33:26 +0000
Received: from [85.158.139.83:4843] by server-9.bemta-5.messagelabs.com id
	1F/82-08547-5F2AF215; Thu, 28 Feb 2013 18:33:25 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-11.tower-182.messagelabs.com!1362076404!22310510!1
X-Originating-IP: [89.16.176.221]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9905 invoked from network); 28 Feb 2013 18:33:24 -0000
Received: from unknown (HELO mail.avalus.com) (89.16.176.221)
	by server-11.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 18:33:24 -0000
Received: by mail.avalus.com (Postfix) with ESMTPSA id A5392C56194;
	Thu, 28 Feb 2013 18:31:13 +0000 (GMT)
Date: Thu, 28 Feb 2013 18:31:12 +0000
From: Alex Bligh <alex@alex.org.uk>
To: George Dunlap <george.dunlap@eu.citrix.com>,
	Stefan Bader <stefan.bader@canonical.com>
Message-ID: <62360CE09BBA23E5567FCC64@Ximines.local>
In-Reply-To: <512F36BA.4070101@eu.citrix.com>
References: <1361870886-3485-1-git-send-email-fantonifabio@tiscali.it> 
	<20780.57998.10366.750860@mariner.uk.xensource.com> 
	<alpine.DEB.2.02.1302261635180.5360@kaball.uk.xensource.com> 
	<20130226170948.GE93966@ocelot.phlegethon.org> 
	<20780.60663.630676.707241@mariner.uk.xensource.com> 
	<20130226172009.GF93966@ocelot.phlegethon.org> 
	<20780.61241.624841.117585@mariner.uk.xensource.com> 
	<20130226172525.GG93966@ocelot.phlegethon.org> 
	<alpine.DEB.2.02.1302261729050.5360@kaball.uk.xensource.com> 
	<1361900393.26546.319.camel@zakaz.uk.xensource.com> 
	<CAFLBxZYn7jTB2B54zssXhMZ+z25JzH=c279MXgwTjyL4gH21vA@mail.gmail.com> 
	<alpine.DEB.2.02.1302271155390.5360@kaball.uk.xensource.com> 
	<714AB68E783E2AC7DEB51045@Ximines.local>
	<1361995662.23384.0.camel@dagon.hellion.org.uk>
	<512F2615.3000007@canonical.com> <512F36BA.4070101@eu.citrix.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	fantonifabio@tiscali.it, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Fabio Fantoni <fabio.fantoni@heliman.it>,
	Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] [PATCH v2] tools: Improve make deb
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.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-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 28 February 2013 10:51:38 +0000 George Dunlap 
<george.dunlap@eu.citrix.com> wrote:

> Alex, what do you think about Ian's suggestion -- i.e., rather than
> integrate a full-featured .deb package into the Xen build system,
> intermittently use the Debian Xen target to create a set of .debs and
> make them available publicly somewhere?  If this was done once only for
> every new release, and then maybe once for each RC (or every other RC)
> before a release, it shouldn't be too much work I don't think.  I think
> we should probably be able to make space on the xen.org website somewhere
> to keep them.

Well, that wouldn't do me any harm or any good. What I want to do is
produce a .deb of the code I have fiddled with.

I think there are at least 3 use cases here:

1. Providing some sort of debian packaging allowing the unstable build
   to be used and installed in a normal way, to encourage testing of
   unstable. This needs init scripts etc. in it, but typically the
   user isn't making his own changes. This should be debuild thing
   with a debian directory (in my opinion), and might not want to be
   upstream in a conventional way.

2. Providing a .deb for the developer, with a bit more functionality
   than the .tgz (e.g. not stomping on configuration files), and
   arguably some init files, but essentially to let the developer
   install his own stuff. A make target is better here, partly because
   make from clean (which is what debuild does) takes ages.

3. Providing a minimalist install (e.g. without header files) of a
   development build - i.e. a small 'package' to take over to another
   machine to install for the purposes of testing - that's what
   my minideb target did. Again a make target is better here.


Task (1) is essentially making the debian or ubuntu packaging easily
available in unstable. I don't know the politically correct way to
do that. It could also be build periodically and made available
somewhere but that would be hard without taking at least an element
of the packaging upstream somewhere (else how it be built).

Task (2) could be done by fixing up the deb target a small amount.

Task (3) is what my minideb target did (see 'Xen 4.2 debian packaging'
thread), and I'm guessing is too arcane for most people, and I'm only
too happy to maintain it on a private branch.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 19:02:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 19: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 1UB8kF-0001Bc-JY; Thu, 28 Feb 2013 19:02:19 +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 1UB8kD-0001BX-Uq
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 19:02:18 +0000
Received: from [85.158.138.51:19187] by server-5.bemta-3.messagelabs.com id
	8B/A5-30636-4B9AF215; Thu, 28 Feb 2013 19:02:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1362078131!29647576!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21818 invoked from network); 28 Feb 2013 19:02:11 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 19:02:11 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so8144412wie.8
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 11:02:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kuvIJD96ZOXqPwYQ+j6DUU7FsFnHwg+ioKrWszOk1DI=;
	b=c9Mq0UGS2CYD+HbqVHv6t8qHrhJ8tv53c197bUcqfu2uq0h+aL4TT+dG4EQro3y1bq
	l5lOKrxRHZpz+EVm+dslpwg4iHItI1TpMlYQVUDb+oOG9M7f7mcFZVe4OhldYskbMuZ+
	ZDPf/tJpN9uX4QemviJKi1L3OAy9z8rMHz+pvpAA+hG08+bmGJ0h8lvM04Y1BwS3VJra
	d8ATDa6eQHySGnyZ6jH2z8Awz/381rAb2acT5bkEyoMmp5Con8jRm0eRLPNUQNYcCJ2q
	agFh1lx/uO8Jw6hruoB8MYBOfk8ZmY8TSfGoTM5OcKCTX0fpSm+z4IHwDi+h6L/i0ibO
	iF0Q==
X-Received: by 10.180.83.137 with SMTP id q9mr35099696wiy.4.1362078131503;
	Thu, 28 Feb 2013 11:02:11 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id n2sm35207680wiy.6.2013.02.28.11.02.07
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 28 Feb 2013 11:02:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 28 Feb 2013 19:02:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD555A2C.4CE31%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	handler
Thread-Index: Ac4V5hieTPtxlPRsyE2IYmK5HfjSNA==
In-Reply-To: <512F913902000078000C222A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/2013 16:17, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Is this alternative that we might not process events for an unbounded time?
>> No, I guess not -- either we would interrupt the notifying IPI and we will
>> be IRETing into that IPI's handler, or the notifying IPI is delayed until
>> the NMI handler's IRET.
>> 
>> What about if the NMI handler itself raises an event (eg softirq)? Perhaps
>> there are no very essential ones of those?
> 
> We do raise PCI_SERR_SOFTIRQ, and the possibly injected NMI
> (to Dom0) might get slightly deferred too. The latter seems of
> little concern (Dom0 will get the event eventually). For the
> former, we might want to explicitly send a self-IPI with
> EVENT_CHECK_VECTOR following the raise_softirq()?

Or perhaps self-IPI on the NMI exit path if softirq_pending is non-zero?
Conservative but more generic.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 19:02:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 19: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 1UB8kF-0001Bc-JY; Thu, 28 Feb 2013 19:02:19 +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 1UB8kD-0001BX-Uq
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 19:02:18 +0000
Received: from [85.158.138.51:19187] by server-5.bemta-3.messagelabs.com id
	8B/A5-30636-4B9AF215; Thu, 28 Feb 2013 19:02:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1362078131!29647576!1
X-Originating-IP: [209.85.212.175]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21818 invoked from network); 28 Feb 2013 19:02:11 -0000
Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com)
	(209.85.212.175)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 19:02:11 -0000
Received: by mail-wi0-f175.google.com with SMTP id l13so8144412wie.8
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 11:02:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-received:user-agent:date:subject:from:to:cc:message-id
	:thread-topic:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kuvIJD96ZOXqPwYQ+j6DUU7FsFnHwg+ioKrWszOk1DI=;
	b=c9Mq0UGS2CYD+HbqVHv6t8qHrhJ8tv53c197bUcqfu2uq0h+aL4TT+dG4EQro3y1bq
	l5lOKrxRHZpz+EVm+dslpwg4iHItI1TpMlYQVUDb+oOG9M7f7mcFZVe4OhldYskbMuZ+
	ZDPf/tJpN9uX4QemviJKi1L3OAy9z8rMHz+pvpAA+hG08+bmGJ0h8lvM04Y1BwS3VJra
	d8ATDa6eQHySGnyZ6jH2z8Awz/381rAb2acT5bkEyoMmp5Con8jRm0eRLPNUQNYcCJ2q
	agFh1lx/uO8Jw6hruoB8MYBOfk8ZmY8TSfGoTM5OcKCTX0fpSm+z4IHwDi+h6L/i0ibO
	iF0Q==
X-Received: by 10.180.83.137 with SMTP id q9mr35099696wiy.4.1362078131503;
	Thu, 28 Feb 2013 11:02:11 -0800 (PST)
Received: from [192.168.1.94] (host86-151-20-129.range86-151.btcentralplus.com.
	[86.151.20.129])
	by mx.google.com with ESMTPS id n2sm35207680wiy.6.2013.02.28.11.02.07
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Thu, 28 Feb 2013 11:02:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.35.0.121009
Date: Thu, 28 Feb 2013 19:02:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CD555A2C.4CE31%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
	handler
Thread-Index: Ac4V5hieTPtxlPRsyE2IYmK5HfjSNA==
In-Reply-To: <512F913902000078000C222A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Malcolm Crossley <malcolm.crossley@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT
 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 28/02/2013 16:17, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Is this alternative that we might not process events for an unbounded time?
>> No, I guess not -- either we would interrupt the notifying IPI and we will
>> be IRETing into that IPI's handler, or the notifying IPI is delayed until
>> the NMI handler's IRET.
>> 
>> What about if the NMI handler itself raises an event (eg softirq)? Perhaps
>> there are no very essential ones of those?
> 
> We do raise PCI_SERR_SOFTIRQ, and the possibly injected NMI
> (to Dom0) might get slightly deferred too. The latter seems of
> little concern (Dom0 will get the event eventually). For the
> former, we might want to explicitly send a self-IPI with
> EVENT_CHECK_VECTOR following the raise_softirq()?

Or perhaps self-IPI on the NMI exit path if softirq_pending is non-zero?
Conservative but more generic.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 19:31:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 19: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 1UB9Bj-0001uf-Ru; Thu, 28 Feb 2013 19:30:43 +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 1UB9Bi-0001uW-FF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 19:30:42 +0000
Received: from [85.158.143.99:49932] by server-1.bemta-4.messagelabs.com id
	98/0A-06203-160BF215; Thu, 28 Feb 2013 19:30:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1362079835!29085443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6342 invoked from network); 28 Feb 2013 19:30:36 -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;
	28 Feb 2013 19:30:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,756,1355097600"; d="scan'208";a="10379609"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 19:29:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 14:29:34 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB9Ad-0006Vc-14;
	Thu, 28 Feb 2013 19:29:35 +0000
Message-ID: <1362079775.2109.141.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 28 Feb 2013 19:29:35 +0000
In-Reply-To: <512F50E4.6020201@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
	<512F50E4.6020201@citrix.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 12:43 +0000, David Vrabel wrote:
> On 27/02/13 14:34, Wei Liu wrote:
> > For non-Dom0 domains, add a flag to indicate whether it can use extended event
> > channel, admins can specify this flag when creating a driver domain.
> > 
> > The rationale behide this option is, a) extended event channel will
> > consume global mapping space in Xen, b) likely that only Dom0 and driver
> > domains need this.
> 
> I would prefer the toolstack to limit the max port that the guest can
> use (see the EVTCHNOP_set_limit sub-op I proposed), than this single bit
> (which isn't useful for the FIFO-based proposal).
> 

I'm not very keen on adding that EVTCHNOP_set_limit now, because:

      * limiting number of event channels in 2/3-level brings no
        significant improvement.
      * you would need to way to notify guest kernel its limit (be
        another OP or via Xenstore), because in any case a guest uses
        user space evtchn driver it would need to know the limit.

In any case, the purpose of this option is to indicate whether the guest
can use *any* of the extended ABIs. A better naming should be
evtchn_extended_allowed, which should default to 1 in FIFO-based ABIs.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 19:31:03 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 19: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 1UB9Bj-0001uf-Ru; Thu, 28 Feb 2013 19:30:43 +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 1UB9Bi-0001uW-FF
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 19:30:42 +0000
Received: from [85.158.143.99:49932] by server-1.bemta-4.messagelabs.com id
	98/0A-06203-160BF215; Thu, 28 Feb 2013 19:30:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1362079835!29085443!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDEzMzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6342 invoked from network); 28 Feb 2013 19:30:36 -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;
	28 Feb 2013 19:30:36 -0000
X-IronPort-AV: E=Sophos;i="4.84,756,1355097600"; d="scan'208";a="10379609"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
	([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 19:29:35 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 14:29:34 -0500
Received: from zion.uk.xensource.com ([10.80.2.73])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<wei.liu2@citrix.com>)	id 1UB9Ad-0006Vc-14;
	Thu, 28 Feb 2013 19:29:35 +0000
Message-ID: <1362079775.2109.141.camel@zion.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 28 Feb 2013 19:29:35 +0000
In-Reply-To: <512F50E4.6020201@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-22-git-send-email-wei.liu2@citrix.com>
	<512F50E4.6020201@citrix.com>
X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, wei.liu2@citrix.com,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC PATCH V3 21/22] Only allow extended event
 channel on Dom0 and driver domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 2013-02-28 at 12:43 +0000, David Vrabel wrote:
> On 27/02/13 14:34, Wei Liu wrote:
> > For non-Dom0 domains, add a flag to indicate whether it can use extended event
> > channel, admins can specify this flag when creating a driver domain.
> > 
> > The rationale behide this option is, a) extended event channel will
> > consume global mapping space in Xen, b) likely that only Dom0 and driver
> > domains need this.
> 
> I would prefer the toolstack to limit the max port that the guest can
> use (see the EVTCHNOP_set_limit sub-op I proposed), than this single bit
> (which isn't useful for the FIFO-based proposal).
> 

I'm not very keen on adding that EVTCHNOP_set_limit now, because:

      * limiting number of event channels in 2/3-level brings no
        significant improvement.
      * you would need to way to notify guest kernel its limit (be
        another OP or via Xenstore), because in any case a guest uses
        user space evtchn driver it would need to know the limit.

In any case, the purpose of this option is to indicate whether the guest
can use *any* of the extended ABIs. A better naming should be
evtchn_extended_allowed, which should default to 1 in FIFO-based ABIs.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 20:36:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 20: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 1UBADI-0003Qr-VN; Thu, 28 Feb 2013 20:36:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <npegg@linode.com>) id 1UBADG-0003Qm-VU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 20:36:23 +0000
Received: from [85.158.137.99:61726] by server-8.bemta-3.messagelabs.com id
	A9/A2-20604-1CFBF215; Thu, 28 Feb 2013 20:36:17 +0000
X-Env-Sender: npegg@linode.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1362083775!17792244!1
X-Originating-IP: [96.126.108.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11041 invoked from network); 28 Feb 2013 20:36:16 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-11.tower-217.messagelabs.com with SMTP;
	28 Feb 2013 20:36:16 -0000
Received: from imap-newark.linode.com (imap-newark.linode.com [69.164.208.11])
	by mail1.linode.com (Postfix) with ESMTP id 787FC266C1
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 15:36:15 -0500 (EST)
Received: from coffeecake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 6CAD6AA4A
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 15:36:15 -0500 (EST)
Message-ID: <512FBFBF.7090408@linode.com>
Date: Thu, 28 Feb 2013 15:36:15 -0500
From: Nick Pegg <npegg@linode.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Subject: [Xen-devel] Questions about XSA39
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen developers,

I had some questions regarding XSA39, and I hope you all can answer them.

We've been rolling out some hosts with the XSA39 patch applied and have
come across a problem where a few of our customer DomUs keep hitting the
conditions which call netbk_fatal_tx_err(), mostly "Frag is bigger than
frame." These specific DomUs hit it repeatedly, between once every few
hours to every few days, and the customers say that they're sending
legitimate traffic (which I'm inclined to believe is true).

If the XSA39 protection is this easy to hit under normal circumstances,
should the solution really be as harsh as disconnecting the vif? Would
it be possible to just drop the packet(s) without causing netback to
spin while processing them?

FWIW, I have gotten a pcap dump from one of the customers facing this
problem. Wireshark does complain about a UDP packet in the sample being
too large (65538 bytes, over the max of 65535). Could this packet
possibly be the culprit? Unfortunately Wireshark refuses to load in the
packet, so I have not yet been able to dissect it.


Thanks in advance,

-Nick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 20:36:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 20: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 1UBADI-0003Qr-VN; Thu, 28 Feb 2013 20:36:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <npegg@linode.com>) id 1UBADG-0003Qm-VU
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 20:36:23 +0000
Received: from [85.158.137.99:61726] by server-8.bemta-3.messagelabs.com id
	A9/A2-20604-1CFBF215; Thu, 28 Feb 2013 20:36:17 +0000
X-Env-Sender: npegg@linode.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1362083775!17792244!1
X-Originating-IP: [96.126.108.55]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11041 invoked from network); 28 Feb 2013 20:36:16 -0000
Received: from mail1.linode.com (HELO mail1.linode.com) (96.126.108.55)
	by server-11.tower-217.messagelabs.com with SMTP;
	28 Feb 2013 20:36:16 -0000
Received: from imap-newark.linode.com (imap-newark.linode.com [69.164.208.11])
	by mail1.linode.com (Postfix) with ESMTP id 787FC266C1
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 15:36:15 -0500 (EST)
Received: from coffeecake.linlan
	(173-161-199-49-Philadelphia.hfc.comcastbusiness.net
	[173.161.199.49])
	by imap-newark.linode.com (Postfix) with ESMTPSA id 6CAD6AA4A
	for <xen-devel@lists.xen.org>; Thu, 28 Feb 2013 15:36:15 -0500 (EST)
Message-ID: <512FBFBF.7090408@linode.com>
Date: Thu, 28 Feb 2013 15:36:15 -0500
From: Nick Pegg <npegg@linode.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.5
Subject: [Xen-devel] Questions about XSA39
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Xen developers,

I had some questions regarding XSA39, and I hope you all can answer them.

We've been rolling out some hosts with the XSA39 patch applied and have
come across a problem where a few of our customer DomUs keep hitting the
conditions which call netbk_fatal_tx_err(), mostly "Frag is bigger than
frame." These specific DomUs hit it repeatedly, between once every few
hours to every few days, and the customers say that they're sending
legitimate traffic (which I'm inclined to believe is true).

If the XSA39 protection is this easy to hit under normal circumstances,
should the solution really be as harsh as disconnecting the vif? Would
it be possible to just drop the packet(s) without causing netback to
spin while processing them?

FWIW, I have gotten a pcap dump from one of the customers facing this
problem. Wireshark does complain about a UDP packet in the sample being
too large (65538 bytes, over the max of 65535). Could this packet
possibly be the culprit? Unfortunately Wireshark refuses to load in the
packet, so I have not yet been able to dissect it.


Thanks in advance,

-Nick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 20:56:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 20:56: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 1UBAWb-00047g-Ha; Thu, 28 Feb 2013 20:56: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 1UBAWZ-00047Z-QX
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 20:56:20 +0000
Received: from [193.109.254.147:13796] by server-3.bemta-14.messagelabs.com id
	8B/FC-22141-274CF215; Thu, 28 Feb 2013 20:56:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1362084978!4847134!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27015 invoked from network); 28 Feb 2013 20:56:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 20:56:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="2050243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 20:56: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.297.1; Thu, 28 Feb 2013 20:56:17 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UBAWX-00085P-F2;
	Thu, 28 Feb 2013 20:56:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UBAWW-0001aN-V8;
	Thu, 28 Feb 2013 20:56:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16773-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 20:56:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 16773: 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 16773 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16773/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 12557
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                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-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-win           5 xen-boot                     fail   like 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemut-win-vcpus1  5 xen-boot                   fail never pass
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1  5 xen-boot                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                2a7d2b96d5cba7568139d9ab157a0e97ab32440f
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 2a7d2b96d5cba7568139d9ab157a0e97ab32440f
Merge: e3c4877... b67bfe0...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Feb 27 20:58:09 2013 -0800

    Merge branch 'akpm' (final batch from Andrew)
    
    Merge third patch-bumb from Andrew Morton:
     "This wraps me up for -rc1.
       - Lots of misc stuff and things which were deferred/missed from
         patchbombings 1 & 2.
       - ocfs2 things
       - lib/scatterlist
       - hfsplus
       - fatfs
       - documentation
       - signals
       - procfs
       - lockdep
       - coredump
       - seqfile core
       - kexec
       - Tejun's large IDR tree reworkings
       - ipmi
       - partitions
       - nbd
       - random() things
       - kfifo
       - tools/testing/selftests updates
       - Sasha's large and pointless hlist cleanup"
    
    * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (163 commits)
      hlist: drop the node parameter from iterators
      kcmp: make it depend on CHECKPOINT_RESTORE
      selftests: add a simple doc
      tools/testing/selftests/Makefile: rearrange targets
      selftests/efivarfs: add create-read test
      selftests/efivarfs: add empty file creation test
      selftests: add tests for efivarfs
      kfifo: fix kfifo_alloc() and kfifo_init()
      kfifo: move kfifo.c from kernel/ to lib/
      arch Kconfig: centralise CONFIG_ARCH_NO_VIRT_TO_BUS
      w1: add support for DS2413 Dual Channel Addressable Switch
      memstick: move the dereference below the NULL test
      drivers/pps/clients/pps-gpio.c: use devm_kzalloc
      Documentation/DMA-API-HOWTO.txt: fix typo
      include/linux/eventfd.h: fix incorrect filename is a comment
      mtd: mtd_stresstest: use prandom_bytes()
      mtd: mtd_subpagetest: convert to use prandom library
      mtd: mtd_speedtest: use prandom_bytes
      mtd: mtd_pagetest: convert to use prandom library
      mtd: mtd_oobtest: convert to use prandom library
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 20:56:49 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 20:56: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 1UBAWb-00047g-Ha; Thu, 28 Feb 2013 20:56: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 1UBAWZ-00047Z-QX
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 20:56:20 +0000
Received: from [193.109.254.147:13796] by server-3.bemta-14.messagelabs.com id
	8B/FC-22141-274CF215; Thu, 28 Feb 2013 20:56:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1362084978!4847134!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27015 invoked from network); 28 Feb 2013 20:56:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 20:56:18 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="2050243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 20:56: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.297.1; Thu, 28 Feb 2013 20:56:17 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UBAWX-00085P-F2;
	Thu, 28 Feb 2013 20:56:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UBAWW-0001aN-V8;
	Thu, 28 Feb 2013 20:56:17 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16773-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 20:56:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 16773: 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 16773 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16773/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 12557
 test-amd64-amd64-xl           9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 12557
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                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-pair         8 xen-boot/dst_host         fail REGR. vs. 12557
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  9 guest-start               fail REGR. vs. 12557
 test-amd64-i386-win           5 xen-boot                     fail   like 12557
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemut-win-vcpus1  5 xen-boot                   fail never pass
 test-amd64-i386-qemut-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3  5 xen-boot                fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1  5 xen-boot                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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-amd64-xl-qemut-win 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 linux                2a7d2b96d5cba7568139d9ab157a0e97ab32440f
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 2a7d2b96d5cba7568139d9ab157a0e97ab32440f
Merge: e3c4877... b67bfe0...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Feb 27 20:58:09 2013 -0800

    Merge branch 'akpm' (final batch from Andrew)
    
    Merge third patch-bumb from Andrew Morton:
     "This wraps me up for -rc1.
       - Lots of misc stuff and things which were deferred/missed from
         patchbombings 1 & 2.
       - ocfs2 things
       - lib/scatterlist
       - hfsplus
       - fatfs
       - documentation
       - signals
       - procfs
       - lockdep
       - coredump
       - seqfile core
       - kexec
       - Tejun's large IDR tree reworkings
       - ipmi
       - partitions
       - nbd
       - random() things
       - kfifo
       - tools/testing/selftests updates
       - Sasha's large and pointless hlist cleanup"
    
    * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (163 commits)
      hlist: drop the node parameter from iterators
      kcmp: make it depend on CHECKPOINT_RESTORE
      selftests: add a simple doc
      tools/testing/selftests/Makefile: rearrange targets
      selftests/efivarfs: add create-read test
      selftests/efivarfs: add empty file creation test
      selftests: add tests for efivarfs
      kfifo: fix kfifo_alloc() and kfifo_init()
      kfifo: move kfifo.c from kernel/ to lib/
      arch Kconfig: centralise CONFIG_ARCH_NO_VIRT_TO_BUS
      w1: add support for DS2413 Dual Channel Addressable Switch
      memstick: move the dereference below the NULL test
      drivers/pps/clients/pps-gpio.c: use devm_kzalloc
      Documentation/DMA-API-HOWTO.txt: fix typo
      include/linux/eventfd.h: fix incorrect filename is a comment
      mtd: mtd_stresstest: use prandom_bytes()
      mtd: mtd_subpagetest: convert to use prandom library
      mtd: mtd_speedtest: use prandom_bytes
      mtd: mtd_pagetest: convert to use prandom library
      mtd: mtd_oobtest: convert to use prandom library
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 21:58:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 21: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 1UBBUb-0005pS-As; Thu, 28 Feb 2013 21:58:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@www.outflux.net>) id 1UBBUa-0005pJ-2x
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 21:58:20 +0000
Received: from [193.109.254.147:12115] by server-3.bemta-14.messagelabs.com id
	AD/D8-22141-AF2DF215; Thu, 28 Feb 2013 21:58:18 +0000
X-Env-Sender: keescook@www.outflux.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1362088678!9424167!1
X-Originating-IP: [198.145.64.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31893 invoked from network); 28 Feb 2013 21:58:00 -0000
Received: from smtp.outflux.net (HELO smtp.outflux.net) (198.145.64.163)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 21:58:00 -0000
Received: from www.outflux.net (serenity-end.outflux.net [10.2.0.2])
	by vinyl.outflux.net (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id
	r1SLueZi022654; Thu, 28 Feb 2013 13:56:42 -0800
Date: Thu, 28 Feb 2013 13:56:40 -0800
From: Kees Cook <keescook@chromium.org>
To: linux-kernel@vger.kernel.org
Message-ID: <20130228215640.GA3136@www.outflux.net>
MIME-Version: 1.0
Content-Disposition: inline
X-MIMEDefang-Filter: outflux$Revision: 1.316 $
X-HELO: www.outflux.net
X-Scanned-By: MIMEDefang 2.71 on 10.2.0.1
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---

v2:
 - drop EXPERIMENTAL from bool and help text too.

---
 arch/x86/xen/Kconfig |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 93ff4e1..6c5802f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -52,12 +52,10 @@ config XEN_DEBUG_FS
 	  Enabling this option may incur a significant performance overhead.
 
 config XEN_X86_PVH
-	bool "Support for running as a PVH guest (EXPERIMENTAL)"
-	depends on X86_64 && XEN && EXPERIMENTAL
+	bool "Support for running as a PVH guest"
+	depends on X86_64 && XEN
 	default n
 	help
 	   This option enables support for running as a PVH guest (PV guest
 	   using hardware extensions) under a suitably capable hypervisor.
-	   This option is EXPERIMENTAL because the hypervisor interfaces
-	   which it uses is not yet considered stable therefore backwards and
-	   forwards compatibility is not yet guaranteed.  If unsure, say N.
+	   If unsure, say N.
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 21:58:46 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 21: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 1UBBUb-0005pS-As; Thu, 28 Feb 2013 21:58:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@www.outflux.net>) id 1UBBUa-0005pJ-2x
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 21:58:20 +0000
Received: from [193.109.254.147:12115] by server-3.bemta-14.messagelabs.com id
	AD/D8-22141-AF2DF215; Thu, 28 Feb 2013 21:58:18 +0000
X-Env-Sender: keescook@www.outflux.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1362088678!9424167!1
X-Originating-IP: [198.145.64.163]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31893 invoked from network); 28 Feb 2013 21:58:00 -0000
Received: from smtp.outflux.net (HELO smtp.outflux.net) (198.145.64.163)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 21:58:00 -0000
Received: from www.outflux.net (serenity-end.outflux.net [10.2.0.2])
	by vinyl.outflux.net (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id
	r1SLueZi022654; Thu, 28 Feb 2013 13:56:42 -0800
Date: Thu, 28 Feb 2013 13:56:40 -0800
From: Kees Cook <keescook@chromium.org>
To: linux-kernel@vger.kernel.org
Message-ID: <20130228215640.GA3136@www.outflux.net>
MIME-Version: 1.0
Content-Disposition: inline
X-MIMEDefang-Filter: outflux$Revision: 1.316 $
X-HELO: www.outflux.net
X-Scanned-By: MIMEDefang 2.71 on 10.2.0.1
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	virtualization@lists.linux-foundation.org,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---

v2:
 - drop EXPERIMENTAL from bool and help text too.

---
 arch/x86/xen/Kconfig |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 93ff4e1..6c5802f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -52,12 +52,10 @@ config XEN_DEBUG_FS
 	  Enabling this option may incur a significant performance overhead.
 
 config XEN_X86_PVH
-	bool "Support for running as a PVH guest (EXPERIMENTAL)"
-	depends on X86_64 && XEN && EXPERIMENTAL
+	bool "Support for running as a PVH guest"
+	depends on X86_64 && XEN
 	default n
 	help
 	   This option enables support for running as a PVH guest (PV guest
 	   using hardware extensions) under a suitably capable hypervisor.
-	   This option is EXPERIMENTAL because the hypervisor interfaces
-	   which it uses is not yet considered stable therefore backwards and
-	   forwards compatibility is not yet guaranteed.  If unsure, say N.
+	   If unsure, say N.
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 22:46:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 22:46: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 1UBCEd-00076P-U5; Thu, 28 Feb 2013 22: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.Jackson@eu.citrix.com>) id 1UBCEc-00076K-PF
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 22:45:55 +0000
Received: from [85.158.143.99:51991] by server-3.bemta-4.messagelabs.com id
	87/5B-02186-12EDF215; Thu, 28 Feb 2013 22:45:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1362091553!20674518!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28339 invoked from network); 28 Feb 2013 22:45:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 22:45:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="2053120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 22:45: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.297.1; Thu, 28 Feb 2013 22:45:53 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UBCEa-0000DI-GY;
	Thu, 28 Feb 2013 22:45:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UBCEa-0001YO-5c;
	Thu, 28 Feb 2013 22:45:52 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16775-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 22:45:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 16775: 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 16775 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12678
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12678
 test-amd64-i386-xl-multivcpu  6 leak-check/basis(6)       fail REGR. vs. 12678
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    9 guest-start              fail blocked in 12678
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-xl-qemut-win7-amd64 6 leak-check/basis(6) fail blocked in 12678
 test-amd64-i386-xl-qemut-win-vcpus1  5 xen-boot          fail blocked in 12678
 test-amd64-i386-xl-win7-amd64  7 windows-install         fail blocked in 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemut-win    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-qemut-win  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-qemut-win     7 windows-install              fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemut-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

version targeted for testing:
 linux                1083c5379a9b63055372325f9fbc4bf853f901df
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 28 22:46:17 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 22:46: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 1UBCEd-00076P-U5; Thu, 28 Feb 2013 22: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.Jackson@eu.citrix.com>) id 1UBCEc-00076K-PF
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 22:45:55 +0000
Received: from [85.158.143.99:51991] by server-3.bemta-4.messagelabs.com id
	87/5B-02186-12EDF215; Thu, 28 Feb 2013 22:45:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1362091553!20674518!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0NzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28339 invoked from network); 28 Feb 2013 22:45:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 22:45:53 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="2053120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 22:45: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.297.1; Thu, 28 Feb 2013 22:45:53 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UBCEa-0000DI-GY;
	Thu, 28 Feb 2013 22:45:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UBCEa-0001YO-5c;
	Thu, 28 Feb 2013 22:45:52 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16775-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 22:45:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 16775: 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 16775 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 12678
 test-amd64-amd64-xl-qemuu-winxpsp3  5 xen-boot            fail REGR. vs. 12678
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 12678
 test-amd64-i386-xl-multivcpu  6 leak-check/basis(6)       fail REGR. vs. 12678
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    9 guest-start              fail blocked in 12678
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 12678
 test-amd64-i386-xl-qemut-win7-amd64 6 leak-check/basis(6) fail blocked in 12678
 test-amd64-i386-xl-qemut-win-vcpus1  5 xen-boot          fail blocked in 12678
 test-amd64-i386-xl-win7-amd64  7 windows-install         fail blocked in 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemut-win    5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64  5 xen-boot               fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3  5 xen-boot                 fail never pass
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-qemut-win  5 xen-boot                     fail  never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-i386-qemut-win     7 windows-install              fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-qemut-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

version targeted for testing:
 linux                1083c5379a9b63055372325f9fbc4bf853f901df
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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 Feb 28 22:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 22: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 1UBCNZ-0007OE-0C; Thu, 28 Feb 2013 22:55:09 +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 1UBCNY-0007O6-2U
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 22:55:08 +0000
Received: from [193.109.254.147:52004] by server-15.bemta-14.messagelabs.com
	id 3E/11-24599-B40EF215; Thu, 28 Feb 2013 22:55:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362092085!6422415!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22366 invoked from network); 28 Feb 2013 22:54:56 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 22:54:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="9922485"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 22:53:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 17:53:22 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UBCLp-00011c-Ns;
	Thu, 28 Feb 2013 22:53:21 +0000
Date: Thu, 28 Feb 2013 22:53:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Kees Cook <keescook@chromium.org>
In-Reply-To: <20130228215640.GA3136@www.outflux.net>
Message-ID: <alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
References: <20130228215640.GA3136@www.outflux.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 28 Feb 2013, Kees Cook wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> 
> v2:
>  - drop EXPERIMENTAL from bool and help text too.
> 
> ---
>  arch/x86/xen/Kconfig |    8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 93ff4e1..6c5802f 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
>  	  Enabling this option may incur a significant performance overhead.
>  
>  config XEN_X86_PVH
> -	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> -	depends on X86_64 && XEN && EXPERIMENTAL
> +	bool "Support for running as a PVH guest"
> +	depends on X86_64 && XEN
>  	default n
>  	help
>  	   This option enables support for running as a PVH guest (PV guest
>  	   using hardware extensions) under a suitably capable hypervisor.
> -	   This option is EXPERIMENTAL because the hypervisor interfaces
> -	   which it uses is not yet considered stable therefore backwards and
> -	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> +	   If unsure, say N.

Please do not change the text this way.
The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
fact that this feature is experimental.
Maybe you want to replace EXPERIMENTAL with experimental, or if
experimental has become as taboo word, I am sure you can find a suitable
synonym.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 22:55:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 22: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 1UBCNZ-0007OE-0C; Thu, 28 Feb 2013 22:55:09 +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 1UBCNY-0007O6-2U
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 22:55:08 +0000
Received: from [193.109.254.147:52004] by server-15.bemta-14.messagelabs.com
	id 3E/11-24599-B40EF215; Thu, 28 Feb 2013 22:55:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1362092085!6422415!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22366 invoked from network); 28 Feb 2013 22:54:56 -0000
Received: from unknown (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 22:54:56 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="9922485"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 22:53:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 17:53:22 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UBCLp-00011c-Ns;
	Thu, 28 Feb 2013 22:53:21 +0000
Date: Thu, 28 Feb 2013 22:53:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Kees Cook <keescook@chromium.org>
In-Reply-To: <20130228215640.GA3136@www.outflux.net>
Message-ID: <alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
References: <20130228215640.GA3136@www.outflux.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 28 Feb 2013, Kees Cook wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> 
> v2:
>  - drop EXPERIMENTAL from bool and help text too.
> 
> ---
>  arch/x86/xen/Kconfig |    8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 93ff4e1..6c5802f 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
>  	  Enabling this option may incur a significant performance overhead.
>  
>  config XEN_X86_PVH
> -	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> -	depends on X86_64 && XEN && EXPERIMENTAL
> +	bool "Support for running as a PVH guest"
> +	depends on X86_64 && XEN
>  	default n
>  	help
>  	   This option enables support for running as a PVH guest (PV guest
>  	   using hardware extensions) under a suitably capable hypervisor.
> -	   This option is EXPERIMENTAL because the hypervisor interfaces
> -	   which it uses is not yet considered stable therefore backwards and
> -	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> +	   If unsure, say N.

Please do not change the text this way.
The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
fact that this feature is experimental.
Maybe you want to replace EXPERIMENTAL with experimental, or if
experimental has become as taboo word, I am sure you can find a suitable
synonym.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 22:57:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 22: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 1UBCPb-0007Ti-Jk; Thu, 28 Feb 2013 22:57:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UBCPZ-0007TY-SQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 22:57:14 +0000
Received: from [85.158.137.99:62698] by server-5.bemta-3.messagelabs.com id
	36/60-30636-4C0EF215; Thu, 28 Feb 2013 22:57:08 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1362092225!13027107!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU2NzAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26837 invoked from network); 28 Feb 2013 22:57:07 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 22:57:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SMucdd019841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 22:56:39 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
	r1SMub0n019977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 22:56:37 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
	r1SMuaVx018385; Thu, 28 Feb 2013 16:56:36 -0600
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-157.usdhcp.oraclecorp.com.com
	(/10.152.55.156) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 14:56:35 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: hpa@zytor.com, bp@alien8.de
Date: Thu, 28 Feb 2013 17:55:49 -0500
Message-Id: <1362092149-32381-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.2
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: konrad.wilk@oracle.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	gregkh@linuxfoundation.org, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	samu.kallio@aberdeencloud.com, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org, kraman@redhat.com,
	stable@kernel.org
Subject: [Xen-devel] [PATCH] mm/x86: Patch out arch_flush_lazy_mmu_mode()
	when running on bare metal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.

Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/include/asm/paravirt.h       |  5 ++++-
 arch/x86/include/asm/paravirt_types.h |  2 ++
 arch/x86/kernel/paravirt.c            | 25 +++++++++++++------------
 arch/x86/lguest/boot.c                |  1 +
 arch/x86/xen/mmu.c                    |  1 +
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 5edd174..7361e47 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -703,7 +703,10 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
 }
 
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+	PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
 
 static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 				phys_addr_t phys, pgprot_t flags)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 142236e..b3b0ec1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
 	/* Set deferred update mode, used for batching operations. */
 	void (*enter)(void);
 	void (*leave)(void);
+	void (*flush)(void);
 };
 
 struct pv_time_ops {
@@ -679,6 +680,7 @@ void paravirt_end_context_switch(struct task_struct *next);
 
 void paravirt_enter_lazy_mmu(void);
 void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
 
 void _paravirt_nop(void);
 u32 _paravirt_ident_32(u32);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..8bfb335 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
 	leave_lazy(PARAVIRT_LAZY_MMU);
 }
 
+void paravirt_flush_lazy_mmu(void)
+{
+	preempt_disable();
+
+	if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+		arch_leave_lazy_mmu_mode();
+		arch_enter_lazy_mmu_mode();
+	}
+
+	preempt_enable();
+}
+
 void paravirt_start_context_switch(struct task_struct *prev)
 {
 	BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return this_cpu_read(paravirt_lazy_mode);
 }
 
-void arch_flush_lazy_mmu_mode(void)
-{
-	preempt_disable();
-
-	if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
-		arch_enter_lazy_mmu_mode();
-	}
-
-	preempt_enable();
-}
-
 struct pv_info pv_info = {
 	.name = "bare hardware",
 	.paravirt_enabled = 0,
@@ -475,6 +475,7 @@ struct pv_mmu_ops pv_mmu_ops = {
 	.lazy_mode = {
 		.enter = paravirt_nop,
 		.leave = paravirt_nop,
+		.flush = paravirt_nop,
 	},
 
 	.set_fixmap = native_set_fixmap,
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 1cbd89c..7114c63 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1334,6 +1334,7 @@ __init void lguest_init(void)
 	pv_mmu_ops.read_cr3 = lguest_read_cr3;
 	pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
 	pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+	pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
 	pv_mmu_ops.pte_update = lguest_pte_update;
 	pv_mmu_ops.pte_update_defer = lguest_pte_update;
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index e8e3493..f4f4105 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2197,6 +2197,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 	.lazy_mode = {
 		.enter = paravirt_enter_lazy_mmu,
 		.leave = xen_leave_lazy_mmu,
+		.flush = paravirt_flush_lazy_mmu,
 	},
 
 	.set_fixmap = xen_set_fixmap,
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 22:57:39 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 22: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 1UBCPb-0007Ti-Jk; Thu, 28 Feb 2013 22:57:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1UBCPZ-0007TY-SQ
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 22:57:14 +0000
Received: from [85.158.137.99:62698] by server-5.bemta-3.messagelabs.com id
	36/60-30636-4C0EF215; Thu, 28 Feb 2013 22:57:08 +0000
X-Env-Sender: boris.ostrovsky@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1362092225!13027107!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjU2NzAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26837 invoked from network); 28 Feb 2013 22:57:07 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Feb 2013 22:57:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with
	ESMTP id r1SMucdd019841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 28 Feb 2013 22:56:39 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
	r1SMub0n019977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 28 Feb 2013 22:56:37 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
	r1SMuaVx018385; Thu, 28 Feb 2013 16:56:36 -0600
Received: from
	dhcp-burlington7-2nd-B-east-10-152-55-157.usdhcp.oraclecorp.com.com
	(/10.152.55.156) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 28 Feb 2013 14:56:35 -0800
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: hpa@zytor.com, bp@alien8.de
Date: Thu, 28 Feb 2013 17:55:49 -0500
Message-Id: <1362092149-32381-1-git-send-email-boris.ostrovsky@oracle.com>
X-Mailer: git-send-email 1.8.1.2
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: konrad.wilk@oracle.com, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	gregkh@linuxfoundation.org, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	samu.kallio@aberdeencloud.com, mingo@redhat.com,
	tglx@linutronix.de, xen-devel@lists.xen.org, kraman@redhat.com,
	stable@kernel.org
Subject: [Xen-devel] [PATCH] mm/x86: Patch out arch_flush_lazy_mmu_mode()
	when running on bare metal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.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

Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.

Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/include/asm/paravirt.h       |  5 ++++-
 arch/x86/include/asm/paravirt_types.h |  2 ++
 arch/x86/kernel/paravirt.c            | 25 +++++++++++++------------
 arch/x86/lguest/boot.c                |  1 +
 arch/x86/xen/mmu.c                    |  1 +
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 5edd174..7361e47 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -703,7 +703,10 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
 }
 
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+	PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
 
 static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 				phys_addr_t phys, pgprot_t flags)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 142236e..b3b0ec1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
 	/* Set deferred update mode, used for batching operations. */
 	void (*enter)(void);
 	void (*leave)(void);
+	void (*flush)(void);
 };
 
 struct pv_time_ops {
@@ -679,6 +680,7 @@ void paravirt_end_context_switch(struct task_struct *next);
 
 void paravirt_enter_lazy_mmu(void);
 void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
 
 void _paravirt_nop(void);
 u32 _paravirt_ident_32(u32);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..8bfb335 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
 	leave_lazy(PARAVIRT_LAZY_MMU);
 }
 
+void paravirt_flush_lazy_mmu(void)
+{
+	preempt_disable();
+
+	if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+		arch_leave_lazy_mmu_mode();
+		arch_enter_lazy_mmu_mode();
+	}
+
+	preempt_enable();
+}
+
 void paravirt_start_context_switch(struct task_struct *prev)
 {
 	BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return this_cpu_read(paravirt_lazy_mode);
 }
 
-void arch_flush_lazy_mmu_mode(void)
-{
-	preempt_disable();
-
-	if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
-		arch_enter_lazy_mmu_mode();
-	}
-
-	preempt_enable();
-}
-
 struct pv_info pv_info = {
 	.name = "bare hardware",
 	.paravirt_enabled = 0,
@@ -475,6 +475,7 @@ struct pv_mmu_ops pv_mmu_ops = {
 	.lazy_mode = {
 		.enter = paravirt_nop,
 		.leave = paravirt_nop,
+		.flush = paravirt_nop,
 	},
 
 	.set_fixmap = native_set_fixmap,
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 1cbd89c..7114c63 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1334,6 +1334,7 @@ __init void lguest_init(void)
 	pv_mmu_ops.read_cr3 = lguest_read_cr3;
 	pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
 	pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+	pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
 	pv_mmu_ops.pte_update = lguest_pte_update;
 	pv_mmu_ops.pte_update_defer = lguest_pte_update;
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index e8e3493..f4f4105 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2197,6 +2197,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 	.lazy_mode = {
 		.enter = paravirt_enter_lazy_mmu,
 		.leave = xen_leave_lazy_mmu,
+		.flush = paravirt_flush_lazy_mmu,
 	},
 
 	.set_fixmap = xen_set_fixmap,
-- 
1.8.1.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:03:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23: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 1UBCUl-0007q1-C8; Thu, 28 Feb 2013 23:02:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@google.com>) id 1UBCUj-0007pv-1F
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 23:02:33 +0000
Received: from [85.158.137.99:37096] by server-7.bemta-3.messagelabs.com id
	0D/F6-06591-802EF215; Thu, 28 Feb 2013 23:02:32 +0000
X-Env-Sender: keescook@google.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1362092550!16307608!1
X-Originating-IP: [209.85.219.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1542 invoked from network); 28 Feb 2013 23:02:31 -0000
Received: from mail-oa0-f41.google.com (HELO mail-oa0-f41.google.com)
	(209.85.219.41)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 23:02:31 -0000
Received: by mail-oa0-f41.google.com with SMTP id i10so4663669oag.28
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Feb 2013 15:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=0UQtpZZOgylCqIT8G+uhLyDcWiBW8NRdpV6wxLh50Mk=;
	b=ZNRLR6wGRTkkDtgHixO9c9/Q8HuqM++3hcbPRobRg/xvBwPlzlFqCQB4VuM9Pxl6b4
	XxsHp6QC7c7l46DCSYmBFBhkTFLliyoqaoo9WoVKGP0FaRn3P/PAxnSQ2KItdoeQ4TvP
	fr8qVHwfb1QffxnpnDL8Cp2szWCtPXSxkkdrOYOCj7EXPJn+dAqXLGfEBu9EmoIfgdgL
	byyOYmpZwtnD+mE+mguaxmaTcpZItou7op6AaDjH0aAS4AGsg09w8wmqYa5Wn2OON3gd
	S/zlu1lDT1zfXu+bngtAB6+C2PErkCzmIlVUBdAlaUK54MsT8qLOTYYmuTWV7tPaX53/
	F3EA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=0UQtpZZOgylCqIT8G+uhLyDcWiBW8NRdpV6wxLh50Mk=;
	b=d3+dkT3oIPeeHDTPoynyqXUHqownvSrfadtj1AI5V+xIeXfKKv72DyBssPoDpuTljf
	KOYl0gISmNGBraTEKl5ZB6kWFYX2u2wzq356/bPFcOCzJcxOkkuLNvTucnJZLcegN156
	w+lmGqV9R4/oPJoNkJ5GLmhQunOo3POVba6TQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=0UQtpZZOgylCqIT8G+uhLyDcWiBW8NRdpV6wxLh50Mk=;
	b=Ppo/tGQOabWExi06A3ZOOOGeR9m6k7U0eXkEnECcWP5g2GnaBQSmnHDjmb+6QphNPJ
	Tg6leFn1itnKmzmQZSDwzJZ4PDUHWo/p6W13zHtUoOLnQYMD+I+ajJnuqn5mP9IGV2rx
	VmP/IWoGqO53NHAqjZEY68Ho+8wQ9rYk86MxXTmLnT6owvvIrhV6CdCvV1F7RNLhLhgK
	mBSHs45+FSqH9yHSJydBJ0Hk3NUdpwK3zjX7MEdtEw1BFdmI1P1moRHd1+9CCMu6IfX1
	/WFX1mPEfwAVtlUv4sVO/p9xvqSs0l5dkkIUAjkOK+vPAjmY/exJF6NlUj4NdvGzEUg5
	ywDA==
MIME-Version: 1.0
X-Received: by 10.60.31.135 with SMTP id a7mr6780712oei.132.1362092549605;
	Thu, 28 Feb 2013 15:02:29 -0800 (PST)
Received: by 10.182.135.131 with HTTP; Thu, 28 Feb 2013 15:02:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
References: <20130228215640.GA3136@www.outflux.net>
	<alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
Date: Thu, 28 Feb 2013 15:02:29 -0800
X-Google-Sender-Auth: N-_U0EZNNlcdpoYRZ547gA4EYx8
Message-ID: <CAGXu5jKHR+bnx7jc0vC15sJL1rradGt0g230MVOaDLj5NqCBhQ@mail.gmail.com>
From: Kees Cook <keescook@chromium.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQn0jk6QFBi7mtx4eCHL+ELEJ6fH4YxUzhxiTc1DH2zcPKabnju6iFYxGHOHy/A+Frm2+vC8FvW28Jz3tz53s2E6hToqB/m9tOqrsTtIdf2PEcjZorFPpXBlFEejCuoGEvWR/zd7jZhUHkfd3BZaayx9uvDUOkkjlA5yVkNtvj+J3xizfxcpNcjpXtd/zYhEc5eEC8kRqq/uMseD8wmCsMdDlg6WTA==
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 2:53 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 28 Feb 2013, Kees Cook wrote:
>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
>> while now and is almost always enabled by default. As agreed during the
>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>
>> v2:
>>  - drop EXPERIMENTAL from bool and help text too.
>>
>> ---
>>  arch/x86/xen/Kconfig |    8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index 93ff4e1..6c5802f 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
>>         Enabling this option may incur a significant performance overhead.
>>
>>  config XEN_X86_PVH
>> -     bool "Support for running as a PVH guest (EXPERIMENTAL)"
>> -     depends on X86_64 && XEN && EXPERIMENTAL
>> +     bool "Support for running as a PVH guest"
>> +     depends on X86_64 && XEN
>>       default n
>>       help
>>          This option enables support for running as a PVH guest (PV guest
>>          using hardware extensions) under a suitably capable hypervisor.
>> -        This option is EXPERIMENTAL because the hypervisor interfaces
>> -        which it uses is not yet considered stable therefore backwards and
>> -        forwards compatibility is not yet guaranteed.  If unsure, say N.
>> +        If unsure, say N.
>
> Please do not change the text this way.
> The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
> fact that this feature is experimental.
> Maybe you want to replace EXPERIMENTAL with experimental, or if
> experimental has become as taboo word, I am sure you can find a suitable
> synonym.

Ah, sorry, I misunderstood what was being recommended from the other
thread (quoting below...)

On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> It certainly is unstable right now (which is why it was unstaged from
> the v3.9 train). I hope that by v3.10 it won't be - at which
> point this patch (and the EXPERIMENTAL) makes sense.

Only "depends on EXPERIMENTAL" must go away. Did you want either the
bool or help text to go away too? If neither, my original patch should
work. If you only want the bool text gone, I can send that version
instead.

-Kees

--
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:03:00 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23: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 1UBCUl-0007q1-C8; Thu, 28 Feb 2013 23:02:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keescook@google.com>) id 1UBCUj-0007pv-1F
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 23:02:33 +0000
Received: from [85.158.137.99:37096] by server-7.bemta-3.messagelabs.com id
	0D/F6-06591-802EF215; Thu, 28 Feb 2013 23:02:32 +0000
X-Env-Sender: keescook@google.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1362092550!16307608!1
X-Originating-IP: [209.85.219.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1542 invoked from network); 28 Feb 2013 23:02:31 -0000
Received: from mail-oa0-f41.google.com (HELO mail-oa0-f41.google.com)
	(209.85.219.41)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 23:02:31 -0000
Received: by mail-oa0-f41.google.com with SMTP id i10so4663669oag.28
	for <xen-devel@lists.xensource.com>;
	Thu, 28 Feb 2013 15:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=0UQtpZZOgylCqIT8G+uhLyDcWiBW8NRdpV6wxLh50Mk=;
	b=ZNRLR6wGRTkkDtgHixO9c9/Q8HuqM++3hcbPRobRg/xvBwPlzlFqCQB4VuM9Pxl6b4
	XxsHp6QC7c7l46DCSYmBFBhkTFLliyoqaoo9WoVKGP0FaRn3P/PAxnSQ2KItdoeQ4TvP
	fr8qVHwfb1QffxnpnDL8Cp2szWCtPXSxkkdrOYOCj7EXPJn+dAqXLGfEBu9EmoIfgdgL
	byyOYmpZwtnD+mE+mguaxmaTcpZItou7op6AaDjH0aAS4AGsg09w8wmqYa5Wn2OON3gd
	S/zlu1lDT1zfXu+bngtAB6+C2PErkCzmIlVUBdAlaUK54MsT8qLOTYYmuTWV7tPaX53/
	F3EA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=0UQtpZZOgylCqIT8G+uhLyDcWiBW8NRdpV6wxLh50Mk=;
	b=d3+dkT3oIPeeHDTPoynyqXUHqownvSrfadtj1AI5V+xIeXfKKv72DyBssPoDpuTljf
	KOYl0gISmNGBraTEKl5ZB6kWFYX2u2wzq356/bPFcOCzJcxOkkuLNvTucnJZLcegN156
	w+lmGqV9R4/oPJoNkJ5GLmhQunOo3POVba6TQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-received:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=0UQtpZZOgylCqIT8G+uhLyDcWiBW8NRdpV6wxLh50Mk=;
	b=Ppo/tGQOabWExi06A3ZOOOGeR9m6k7U0eXkEnECcWP5g2GnaBQSmnHDjmb+6QphNPJ
	Tg6leFn1itnKmzmQZSDwzJZ4PDUHWo/p6W13zHtUoOLnQYMD+I+ajJnuqn5mP9IGV2rx
	VmP/IWoGqO53NHAqjZEY68Ho+8wQ9rYk86MxXTmLnT6owvvIrhV6CdCvV1F7RNLhLhgK
	mBSHs45+FSqH9yHSJydBJ0Hk3NUdpwK3zjX7MEdtEw1BFdmI1P1moRHd1+9CCMu6IfX1
	/WFX1mPEfwAVtlUv4sVO/p9xvqSs0l5dkkIUAjkOK+vPAjmY/exJF6NlUj4NdvGzEUg5
	ywDA==
MIME-Version: 1.0
X-Received: by 10.60.31.135 with SMTP id a7mr6780712oei.132.1362092549605;
	Thu, 28 Feb 2013 15:02:29 -0800 (PST)
Received: by 10.182.135.131 with HTTP; Thu, 28 Feb 2013 15:02:29 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
References: <20130228215640.GA3136@www.outflux.net>
	<alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
Date: Thu, 28 Feb 2013 15:02:29 -0800
X-Google-Sender-Auth: N-_U0EZNNlcdpoYRZ547gA4EYx8
Message-ID: <CAGXu5jKHR+bnx7jc0vC15sJL1rradGt0g230MVOaDLj5NqCBhQ@mail.gmail.com>
From: Kees Cook <keescook@chromium.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQn0jk6QFBi7mtx4eCHL+ELEJ6fH4YxUzhxiTc1DH2zcPKabnju6iFYxGHOHy/A+Frm2+vC8FvW28Jz3tz53s2E6hToqB/m9tOqrsTtIdf2PEcjZorFPpXBlFEejCuoGEvWR/zd7jZhUHkfd3BZaayx9uvDUOkkjlA5yVkNtvj+J3xizfxcpNcjpXtd/zYhEc5eEC8kRqq/uMseD8wmCsMdDlg6WTA==
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 2:53 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 28 Feb 2013, Kees Cook wrote:
>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
>> while now and is almost always enabled by default. As agreed during the
>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>
>> v2:
>>  - drop EXPERIMENTAL from bool and help text too.
>>
>> ---
>>  arch/x86/xen/Kconfig |    8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index 93ff4e1..6c5802f 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
>>         Enabling this option may incur a significant performance overhead.
>>
>>  config XEN_X86_PVH
>> -     bool "Support for running as a PVH guest (EXPERIMENTAL)"
>> -     depends on X86_64 && XEN && EXPERIMENTAL
>> +     bool "Support for running as a PVH guest"
>> +     depends on X86_64 && XEN
>>       default n
>>       help
>>          This option enables support for running as a PVH guest (PV guest
>>          using hardware extensions) under a suitably capable hypervisor.
>> -        This option is EXPERIMENTAL because the hypervisor interfaces
>> -        which it uses is not yet considered stable therefore backwards and
>> -        forwards compatibility is not yet guaranteed.  If unsure, say N.
>> +        If unsure, say N.
>
> Please do not change the text this way.
> The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
> fact that this feature is experimental.
> Maybe you want to replace EXPERIMENTAL with experimental, or if
> experimental has become as taboo word, I am sure you can find a suitable
> synonym.

Ah, sorry, I misunderstood what was being recommended from the other
thread (quoting below...)

On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> It certainly is unstable right now (which is why it was unstaged from
> the v3.9 train). I hope that by v3.10 it won't be - at which
> point this patch (and the EXPERIMENTAL) makes sense.

Only "depends on EXPERIMENTAL" must go away. Did you want either the
bool or help text to go away too? If neither, my original patch should
work. If you only want the bool text gone, I can send that version
instead.

-Kees

--
Kees Cook
Chrome OS Security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:03:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23:03: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 1UBCV8-0007rg-Us; Thu, 28 Feb 2013 23:02: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 1UBCV7-0007rV-AM
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 23:02:57 +0000
Received: from [85.158.139.211:63883] by server-15.bemta-5.messagelabs.com id
	10/84-22815-022EF215; Thu, 28 Feb 2013 23:02:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1362092575!18882346!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0OTIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9942 invoked from network); 28 Feb 2013 23:02:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 23:02:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="2053303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 23:02: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.297.1; Thu, 28 Feb 2013 23:02:55 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UBCV5-0000J4-88;
	Thu, 28 Feb 2013 23:02:55 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UBCV4-0006ZD-Tw;
	Thu, 28 Feb 2013 23:02:55 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16774-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 23:02:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16774: 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 16774 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16774/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 15122
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   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-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:03:19 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23:03: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 1UBCV8-0007rg-Us; Thu, 28 Feb 2013 23:02: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 1UBCV7-0007rV-AM
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 23:02:57 +0000
Received: from [85.158.139.211:63883] by server-15.bemta-5.messagelabs.com id
	10/84-22815-022EF215; Thu, 28 Feb 2013 23:02:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1362092575!18882346!1
X-Originating-IP: [46.33.159.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI0OTIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9942 invoked from network); 28 Feb 2013 23:02:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Feb 2013 23:02:55 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="2053303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Feb 2013 23:02: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.297.1; Thu, 28 Feb 2013 23:02:55 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1UBCV5-0000J4-88;
	Thu, 28 Feb 2013 23:02:55 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1UBCV4-0006ZD-Tw;
	Thu, 28 Feb 2013 23:02:55 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-16774-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 28 Feb 2013 23:02:55 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 16774: 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 16774 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16774/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 15122
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 15122

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win 13 guest-stop                   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-xl-qemuu-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-qemuu-win  12 guest-localmigrate/x10       fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass

version targeted for testing:
 qemuu                eccc68722696864fc4823f048c7be58d11281b97
baseline version:
 qemuu                70454385eeee6f0b3f7a9eddca9f7340b5060824

------------------------------------------------------------
People who touched revisions under test:
  Alex Bligh <alex@alex.org.uk>
  Anthony PERARD <anthony.perard@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 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.

------------------------------------------------------------
commit eccc68722696864fc4823f048c7be58d11281b97
Author: Anthony PERARD <anthony.perard@citrix.com>
Date:   Thu Feb 21 12:16:42 2013 +0000

    xen: Set the vram dirty when an error occurs.
    
    If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
    video ram. This case happens during migration.
    
    Backport of 8aba7dc02d5660df7e7d8651304b3079908358be
    
    This backport is less clean that it might be because there is no
    memory_region_set_dirty that copes with more than one page in 4.2,
    and the case where the call to xc_hvm_track_dirty_vram is
    successful also needs to ensure xen_modified_memory is
    called (which would on unstable have been done within
    memory_region_set_dirty).
    
    Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Alex Bligh <alex@alex.org.uk>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:11:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23:11: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 1UBCd7-0008Ce-Us; Thu, 28 Feb 2013 23:11:13 +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 1UBCd6-0008CZ-3R
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 23:11:12 +0000
Received: from [193.109.254.147:61340] by server-2.bemta-14.messagelabs.com id
	BB/F3-16277-F04EF215; Thu, 28 Feb 2013 23:11:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1362093056!4856813!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3500 invoked from network); 28 Feb 2013 23:10:59 -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;
	28 Feb 2013 23:10:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="9925613"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 23:10:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 18:10:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UBCcq-0001Gv-0A;
	Thu, 28 Feb 2013 23:10:56 +0000
Date: Thu, 28 Feb 2013 23:10:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Kees Cook <keescook@chromium.org>
In-Reply-To: <CAGXu5jKHR+bnx7jc0vC15sJL1rradGt0g230MVOaDLj5NqCBhQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302282309510.5210@kaball.uk.xensource.com>
References: <20130228215640.GA3136@www.outflux.net>
	<alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
	<CAGXu5jKHR+bnx7jc0vC15sJL1rradGt0g230MVOaDLj5NqCBhQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "x86@kernel.org" <x86@kernel.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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 28 Feb 2013, Kees Cook wrote:
> On Thu, Feb 28, 2013 at 2:53 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 28 Feb 2013, Kees Cook wrote:
> >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >> while now and is almost always enabled by default. As agreed during the
> >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> ---
> >>
> >> v2:
> >>  - drop EXPERIMENTAL from bool and help text too.
> >>
> >> ---
> >>  arch/x86/xen/Kconfig |    8 +++-----
> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >> index 93ff4e1..6c5802f 100644
> >> --- a/arch/x86/xen/Kconfig
> >> +++ b/arch/x86/xen/Kconfig
> >> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
> >>         Enabling this option may incur a significant performance overhead.
> >>
> >>  config XEN_X86_PVH
> >> -     bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >> -     depends on X86_64 && XEN && EXPERIMENTAL
> >> +     bool "Support for running as a PVH guest"
> >> +     depends on X86_64 && XEN
> >>       default n
> >>       help
> >>          This option enables support for running as a PVH guest (PV guest
> >>          using hardware extensions) under a suitably capable hypervisor.
> >> -        This option is EXPERIMENTAL because the hypervisor interfaces
> >> -        which it uses is not yet considered stable therefore backwards and
> >> -        forwards compatibility is not yet guaranteed.  If unsure, say N.
> >> +        If unsure, say N.
> >
> > Please do not change the text this way.
> > The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
> > fact that this feature is experimental.
> > Maybe you want to replace EXPERIMENTAL with experimental, or if
> > experimental has become as taboo word, I am sure you can find a suitable
> > synonym.
> 
> Ah, sorry, I misunderstood what was being recommended from the other
> thread (quoting below...)
> 
> On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > It certainly is unstable right now (which is why it was unstaged from
> > the v3.9 train). I hope that by v3.10 it won't be - at which
> > point this patch (and the EXPERIMENTAL) makes sense.
> 
> Only "depends on EXPERIMENTAL" must go away. Did you want either the
> bool or help text to go away too? If neither, my original patch should
> work. If you only want the bool text gone, I can send that version
> instead.

I think your original patch is good, but I'll let Konrad decide.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:11:32 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23:11: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 1UBCd7-0008Ce-Us; Thu, 28 Feb 2013 23:11:13 +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 1UBCd6-0008CZ-3R
	for xen-devel@lists.xensource.com; Thu, 28 Feb 2013 23:11:12 +0000
Received: from [193.109.254.147:61340] by server-2.bemta-14.messagelabs.com id
	BB/F3-16277-F04EF215; Thu, 28 Feb 2013 23:11:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1362093056!4856813!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDUxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3500 invoked from network); 28 Feb 2013 23:10:59 -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;
	28 Feb 2013 23:10:59 -0000
X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; 
   d="scan'208";a="9925613"
Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net)
	([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	28 Feb 2013 23:10:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Thu, 28 Feb 2013 18:10:56 -0500
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<stefano.stabellini@eu.citrix.com>)	id 1UBCcq-0001Gv-0A;
	Thu, 28 Feb 2013 23:10:56 +0000
Date: Thu, 28 Feb 2013 23:10:55 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Kees Cook <keescook@chromium.org>
In-Reply-To: <CAGXu5jKHR+bnx7jc0vC15sJL1rradGt0g230MVOaDLj5NqCBhQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1302282309510.5210@kaball.uk.xensource.com>
References: <20130228215640.GA3136@www.outflux.net>
	<alpine.DEB.2.02.1302282251200.5210@kaball.uk.xensource.com>
	<CAGXu5jKHR+bnx7jc0vC15sJL1rradGt0g230MVOaDLj5NqCBhQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "x86@kernel.org" <x86@kernel.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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] arch/x86/xen: remove depends on
	CONFIG_EXPERIMENTAL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, 28 Feb 2013, Kees Cook wrote:
> On Thu, Feb 28, 2013 at 2:53 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 28 Feb 2013, Kees Cook wrote:
> >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >> while now and is almost always enabled by default. As agreed during the
> >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> ---
> >>
> >> v2:
> >>  - drop EXPERIMENTAL from bool and help text too.
> >>
> >> ---
> >>  arch/x86/xen/Kconfig |    8 +++-----
> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >> index 93ff4e1..6c5802f 100644
> >> --- a/arch/x86/xen/Kconfig
> >> +++ b/arch/x86/xen/Kconfig
> >> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
> >>         Enabling this option may incur a significant performance overhead.
> >>
> >>  config XEN_X86_PVH
> >> -     bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >> -     depends on X86_64 && XEN && EXPERIMENTAL
> >> +     bool "Support for running as a PVH guest"
> >> +     depends on X86_64 && XEN
> >>       default n
> >>       help
> >>          This option enables support for running as a PVH guest (PV guest
> >>          using hardware extensions) under a suitably capable hypervisor.
> >> -        This option is EXPERIMENTAL because the hypervisor interfaces
> >> -        which it uses is not yet considered stable therefore backwards and
> >> -        forwards compatibility is not yet guaranteed.  If unsure, say N.
> >> +        If unsure, say N.
> >
> > Please do not change the text this way.
> > The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
> > fact that this feature is experimental.
> > Maybe you want to replace EXPERIMENTAL with experimental, or if
> > experimental has become as taboo word, I am sure you can find a suitable
> > synonym.
> 
> Ah, sorry, I misunderstood what was being recommended from the other
> thread (quoting below...)
> 
> On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > It certainly is unstable right now (which is why it was unstaged from
> > the v3.9 train). I hope that by v3.10 it won't be - at which
> > point this patch (and the EXPERIMENTAL) makes sense.
> 
> Only "depends on EXPERIMENTAL" must go away. Did you want either the
> bool or help text to go away too? If neither, my original patch should
> work. If you only want the bool text gone, I can send that version
> instead.

I think your original patch is good, but I'll let Konrad decide.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:37:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23:37: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 1UBD2b-0000JP-7o; Thu, 28 Feb 2013 23:37:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UBD2Z-0000JK-FD
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 23:37:31 +0000
Received: from [85.158.139.83:34139] by server-4.bemta-5.messagelabs.com id
	CD/82-01980-A3AEF215; Thu, 28 Feb 2013 23:37:30 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1362094650!29527598!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5016 invoked from network); 28 Feb 2013 23:37:30 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-2.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 23:37:30 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362094649; bh=kX1xiL4F4xUKtV/mgsjmxzMJqmllkT6DCE67FT/jlyM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=X7y1AheezDZEem+oYb9Mp52vyOSP82xYF2VI28
	sa0mcluMfHqGZ0lWWD94/VU5vuQUxXJGu0leydG917e2zTrf/vbA/JuFQagrs6x+gq3
	W+UWNC4S+YnjJ5wYCeJWC0S8FeB3/kOpr5uYzVYS4oDm3mjhEhXO9ZqM6adD04toDw=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id di-1fRvJRb06; Fri,  1 Mar 2013 00:37:29 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	D9A5E1DA22C; Fri,  1 Mar 2013 00:37:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362094649; bh=kX1xiL4F4xUKtV/mgsjmxzMJqmllkT6DCE67FT/jlyM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=X7y1AheezDZEem+oYb9Mp52vyOSP82xYF2VI28
	sa0mcluMfHqGZ0lWWD94/VU5vuQUxXJGu0leydG917e2zTrf/vbA/JuFQagrs6x+gq3
	W+UWNC4S+YnjJ5wYCeJWC0S8FeB3/kOpr5uYzVYS4oDm3mjhEhXO9ZqM6adD04toDw=
Received: by liondog.tnic (Postfix, from userid 1000)
	id DE829100A74; Fri,  1 Mar 2013 00:37:20 +0100 (CET)
Date: Fri, 1 Mar 2013 00:37:20 +0100
From: Borislav Petkov <bp@alien8.de>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228233720.GB17468@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, hpa@zytor.com,
	mingo@redhat.com, tglx@linutronix.de, konrad.wilk@oracle.com,
	rostedt@goodmis.org, gregkh@linuxfoundation.org,
	samu.kallio@aberdeencloud.com, kraman@redhat.com,
	jwboyer@redhat.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, stable@kernel.org
References: <1362092149-32381-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1362092149-32381-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: konrad.wilk@oracle.com, gregkh@linuxfoundation.org, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	samu.kallio@aberdeencloud.com, mingo@redhat.com, hpa@zytor.com,
	tglx@linutronix.de, xen-devel@lists.xen.org, kraman@redhat.com,
	stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] mm/x86: Patch out
 arch_flush_lazy_mmu_mode() when running on bare metal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 05:55:49PM -0500, Boris Ostrovsky wrote:
> Invoking arch_flush_lazy_mmu_mode() results in calls to
> preempt_enable()/disable() which may have performance impact.
> 
> Since lazy MMU is not used on bare metal we can patch away
> arch_flush_lazy_mmu_mode() so that it is never called in such
> environment.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Looks straight-forward enough to me.

Acked-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Feb 28 23:37:51 2013
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 28 Feb 2013 23:37: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 1UBD2b-0000JP-7o; Thu, 28 Feb 2013 23:37:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bp@alien8.de>) id 1UBD2Z-0000JK-FD
	for xen-devel@lists.xen.org; Thu, 28 Feb 2013 23:37:31 +0000
Received: from [85.158.139.83:34139] by server-4.bemta-5.messagelabs.com id
	CD/82-01980-A3AEF215; Thu, 28 Feb 2013 23:37:30 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1362094650!29527598!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5016 invoked from network); 28 Feb 2013 23:37:30 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-2.tower-182.messagelabs.com with SMTP;
	28 Feb 2013 23:37:30 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362094649; bh=kX1xiL4F4xUKtV/mgsjmxzMJqmllkT6DCE67FT/jlyM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=X7y1AheezDZEem+oYb9Mp52vyOSP82xYF2VI28
	sa0mcluMfHqGZ0lWWD94/VU5vuQUxXJGu0leydG917e2zTrf/vbA/JuFQagrs6x+gq3
	W+UWNC4S+YnjJ5wYCeJWC0S8FeB3/kOpr5uYzVYS4oDm3mjhEhXO9ZqM6adD04toDw=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id di-1fRvJRb06; Fri,  1 Mar 2013 00:37:29 +0100 (CET)
Received: from liondog.tnic (p5B32D3A3.dip.t-dialin.net [91.50.211.163])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	D9A5E1DA22C; Fri,  1 Mar 2013 00:37:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1362094649; bh=kX1xiL4F4xUKtV/mgsjmxzMJqmllkT6DCE67FT/jlyM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=X7y1AheezDZEem+oYb9Mp52vyOSP82xYF2VI28
	sa0mcluMfHqGZ0lWWD94/VU5vuQUxXJGu0leydG917e2zTrf/vbA/JuFQagrs6x+gq3
	W+UWNC4S+YnjJ5wYCeJWC0S8FeB3/kOpr5uYzVYS4oDm3mjhEhXO9ZqM6adD04toDw=
Received: by liondog.tnic (Postfix, from userid 1000)
	id DE829100A74; Fri,  1 Mar 2013 00:37:20 +0100 (CET)
Date: Fri, 1 Mar 2013 00:37:20 +0100
From: Borislav Petkov <bp@alien8.de>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <20130228233720.GB17468@pd.tnic>
Mail-Followup-To: Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, hpa@zytor.com,
	mingo@redhat.com, tglx@linutronix.de, konrad.wilk@oracle.com,
	rostedt@goodmis.org, gregkh@linuxfoundation.org,
	samu.kallio@aberdeencloud.com, kraman@redhat.com,
	jwboyer@redhat.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, stable@kernel.org
References: <1362092149-32381-1-git-send-email-boris.ostrovsky@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1362092149-32381-1-git-send-email-boris.ostrovsky@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: konrad.wilk@oracle.com, gregkh@linuxfoundation.org, jwboyer@redhat.com,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	samu.kallio@aberdeencloud.com, mingo@redhat.com, hpa@zytor.com,
	tglx@linutronix.de, xen-devel@lists.xen.org, kraman@redhat.com,
	stable@kernel.org
Subject: Re: [Xen-devel] [PATCH] mm/x86: Patch out
 arch_flush_lazy_mmu_mode() when running on bare metal
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Feb 28, 2013 at 05:55:49PM -0500, Boris Ostrovsky wrote:
> Invoking arch_flush_lazy_mmu_mode() results in calls to
> preempt_enable()/disable() which may have performance impact.
> 
> Since lazy MMU is not used on bare metal we can patch away
> arch_flush_lazy_mmu_mode() so that it is never called in such
> environment.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Looks straight-forward enough to me.

Acked-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel